hostname-based customization of software configurations

slacker1337 · 06-11-2018, 08:57 PM

How do you manage configuration of ntp.conf on your systems? To elaborate with just one example, I have a few physical servers that synchronize time with the ntp pool and all of my other machines sync time with those two physical servers. This leaves me with essentially two versions of ntp.conf to manage, a -server and -client version. I recently created a SlackBuild script that delivers the files and creates a symlink to ntp.conf based on hostname. The problem is that I have to reinstall that custom package every time (not that it happens very often) ntp receives an upgrade.
To make a long story short, how do you more experienced Slackers manage software packages to lessen manually performed changes?

upnort · 06-11-2018, 11:21 PM

With respect to syncing /etc, I wrote my own sync script about 10 years ago. Runs from cron and manually. The script uses rsync. The home LAN server is the master source. I created rsync exclusion files to skip syncing certain files. I store the exclusion files in /usr/local/etc and the script sources the files. The sync script uses /etc/slackware-version to check the Slackware version. If the version is different, for example, syncing a 14.1 system from the server's 14.2 system, then the script syncs a limited number of /etc files. That way I don't clobber rc.d scripts. The script contains a lot of specific hard-coding that satisfies only my use cases. I never tried to tune the script for a global audience.

I use a modified version of Alien Bob's repo sync scripts to maintain a local Slackware mirror. That way all Slackware systems on the LAN update from my local mirror. For work, where we use Debian, Ubuntu, and CentOS, I configured apt-cacher-ng to reduce bandwidth when updating systems.

With respect to time sync, I run ntp on the primary server in my home LAN. I run an hourly cron job on other systems that runs a script wrapper to ntpdate with the server being the time source. The script uses ntp when the server is unavailable, such as using a laptop away from home. I am not running time sync critical projects, so an hourly sync is good enough for me. I disable all time sync tools in any virtual machine.

GazL · 06-12-2018, 05:00 AM

In your situation I would use ntpd's -c option to specify different config file names for sever and client and specify it in rc.ntpd. rc.ntpd does the ".new" dance when it's upgraded so your changes shouldn't get overwritten.

Having said that, I much prefer the BSDs approach of having a rc.conf/rc.conf.local for passing flags to daemons as it's much easier to have per-host configurations using just a rc.conf.local and it separates out configuration from implementation.

allend · 06-12-2018, 09:48 AM

Quote:

Having said that, I much prefer the BSDs approach of having a rc.conf/rc.conf.local for passing flags to daemons as it's much easier to have per-host configurations using just a rc.conf.local and it separates out configuration from implementation.

I can see that as useful if the configuration options do not change. But I consider ntpd a case in point for the weakness of this. There have been multiple changes in the default /etc/ntp.conf over recent years. This approach adds a level of difficulty if the configuration needs to be updated. If you use slackpkg, you will be prompted about the incoming .new file. I find the use of the vimdiff option in the latest slackpkg in -current to be useful for pushing local customisations into the incoming .new file.

PS - My suggestion for an update in /etc/ntpd.conf

Code:

diff a/ntp.conf b/ntp.conf
4,9c4,10
< # Undisciplined Local Clock. This is a fake driver intended for backup
< # and when no outside source of synchronized time is available. The
< # default stratum is usually 3, but in this case we elect to use stratum
< # 0. Since the server line does not have the prefer keyword, this driver
< # is never used for synchronization, unless no other other
< # synchronization source is available. In case the local host is
---
> # Undisciplined Local Clock. This is a fallback intended for
> # when no outside source of synchronized time is available. The
> # default stratum is usually 3, but in this case we elect to use stratum 10.
> # Since the server line does not have the prefer keyword,
> # and other contactable servers will be at a lower stratum, this 
> # server will never be used for synchronization, unless no other
> # synchronization source is available. In the case where local host is

slacker1337 · 06-12-2018, 06:12 PM

I appreciate the feedback, but ntp was just an example of the problem I'm trying to overcome. I currently have custom packages to manage the configuration of the following services/applications:
conky, fluxbox, http, iptables, named, ntp, slackpkg, slackpkg+, and xorg (although this is just the list of the packages I've actually created)

For various reasons, I have configurations that are host specific for each of the above packages and just wanted advice on how fellow Slackers do the same (assuming you do)..

Richard Cranium · 06-12-2018, 11:31 PM

Quote:

Originally Posted by slacker1337

How do you manage configuration of ntp.conf on your systems? To elaborate with just one example, I have a few physical servers that synchronize time with the ntp pool and all of my other machines sync time with those two physical servers. This leaves me with essentially two versions of ntp.conf to manage, a -server and -client version. I recently created a SlackBuild script that delivers the files and creates a symlink to ntp.conf based on hostname. The problem is that I have to reinstall that custom package every time (not that it happens very often) ntp receives an upgrade.
To make a long story short, how do you more experienced Slackers manage software packages to lessen manually performed changes?

That's what dhcpd (and perhaps dhcpcd) is for, assuming that you are running a dhcp daemon to configure your network's IP addresses.

In /etc/dhcpd.conf...

Code:

subnet 172.16.1.0 netmask 255.255.255.0 {
  range 172.16.1.2 172.16.1.249;
  option broadcast-address 172.16.1.255;
  option routers 172.16.1.1;
  option ntp-servers 172.16.1.1;
}

(ntp-servers is actually a list)

In /etc/dhcpcd.conf, option ntp_servers will do the right thing.

Having written the above, there used to be a gnu program that would allow you to centrally configure a network of machines.

Ah, it's still there. Hasn't been updated since 2003, but it may have been simple enough to continue to work (looking closer, I'm starting to doubt that to be true). I've never used it, but was mildly interested in it at one time.