I wrote an rc.ntpd, RFC and question

jamesf · 08-06-2006, 11:51 PM

I'm running slackware 10.0, kernel 2.4.26, ntp package ntp-4.2.0-i486-1 and wanted to make it a bit more like other services.

Here's what I did:

First, I put together a /etc/ntp.conf file, with servers for the USA

Code:

#
# /etc/ntp.conf
#restrict default noquery notrust nomodify
# next two lines restrict localhost and my domain from providing other time servers
restrict 127.0.0.1
restrict 192.168.42.0 mask 255.255.255.0
# next 2 lines is how ntpd queries locally attached time devices
#server 127.127.1.0
#fudge 127.127.1.0 stratum 3
driftfile /etc/ntpd.drift
logfile /var/log/ntp.log
pidfile /var/run/ntp.pid
# The following servers round-robin the actual time server returned
# It helps balance load for upper level servers
# see http://www.ntp.org for others
server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org

Then I built a file for logrotate that would rotate the ntp logs. It goes in /etc/logrotate.d/ntp

Code:

# /etc/logrotate.d/ntp
# logrotate configuration file for ntpd
# slackware default logrotate.conf causes new log files to be created and ntpd keeps the
# file open, so we can't just switch logs underneath it.  Stopping and re-starting ntpd
# is an option, but there's many minutes of re-sync involved so we use the copytruncate
# command.  See man logrotate for details.
#
/var/log/ntp.log {
    nocreate
    copytruncate
}

Then I built a /etc/rc.d/rc.ntpd with the usual start/stop/restart commands and added a status command.

Code:

#!/bin/sh
#
# /etc/rc.d/rc.ntpd
# Author:  James Franklin
# Date:    08/05/2006
#
# Start/stop/restart the Network Time Protocol Daemon
#
# Should be called in rc.local
#

case "$1" in
   'start')
      /usr/sbin/ntpd
      ;;
   'stop')
      /bin/killall --quiet -HUP ntpd
      ;;
   'restart')
      /bin/killall --quiet --wait  -HUP ntpd
      /usr/sbin/ntpd
      ;;
   'status')
      ps -C ntpd
      echo
      echo Recent entries in /var/log/ntp.log
      grep `cat /var/run/ntp.pid` /var/log/ntp.log | tail -20
      ;;
   *)
      echo "usage $0 start|stop|restart|status" ;;
esac

After I set it to have the same permissions that the other rc.d scripts have using chmod +x /etc/rc.d/rc.ntpd I called it from /etc/rc.d/rc.local

Code:

# Start the Network Time Protocol daemon
if [ -x /etc/rc.d/rc.ntpd ]; then
   /etc/rc.d/rc.ntpd start
fi

EDIT 08/12/2006
By default /etc/rc.d/rc.inet1 calls dhcpcd in a way that causes dhcpcd to overwrite /etc/ntp.conf and destroy our changes each time dhcpcd is run. This is at least every boot. Disable that behavior by adding a -N switch to all of the dhcpcd lines. You can skip adding it to the 'dhcpcd -k' lines if you want.

And it all works. Testing logrotate was easy with logrotate --force /etc/logrotate.conf

I have only one problem. If I restart with /etc/rc.d/rc.ntpd restart from a non-root user I get a message in /var/log/syslog that says that a non-root user can't terminate ntpd. So, would you remove execute permissions from group and world, or modify the script to check for the user root, or what?

Other than that, what do you all think? Is it helpful in and of itself or just as a springboard for greater things done by others? I'm a windows programmer using slackware at home so I was curious how real sysadmins would do it.

Thanks for reading!

gilead · 08-07-2006, 01:21 AM

I've removed permissions with chmod go-rwx /etc/rc.d/rc.ntpd on my boxes, but that's just me

evilDagmar · 08-07-2006, 02:04 AM

Well, it really doesn't much matter whether or not the script is world-executeable. You'll note that PV doesn't much bother with stripping the world-executeable bit off the init scripts, either.

This is because even though the script might *run*, the commands it will try to run to terminate/restart/stop services are still going to be subject to the normal security model of Linux. Specifically, you're not allowed to send signals to any process you don't own, so it doesn't much matter if normal users can execute rc.ntpd or not. They're not going to be able to start ntpd in a useful fashion, and they're not going to be able to stop the one that the system started up (unless, on both cases of course, you're running as root at the time you try it).\

I'd suggest looking the rc.sysvinit script for a different way to go about invoking the startup. The one problem with the BSD-style init sequence Slackware has traditionally used is that it is not extensible in a modular fashion. Someone can install a package, and it will never be normally called on during startup unless they also go and add a line or two to rc.M or rc.local. This actually complicates things where they don't really need to be complicated. rc.local gets started last but one might easily argue that since it can change the system time abrubtly, it should be started as soon as the network is available, so rc.local isn't a great place for it. rc.M isn't an optimal place to put it because if Patrick releases an update that fixes something in rc.M, the update will make the start hook disappear.

The answer to all this is really for things to finally start migrating towards using SysV init, especially in the case of third-party packages. Basically, you drop your startup script in /etc/rc.d as usual, and then in /etc/rc.d/rc.${runlevel}d you make two symlinks back to it. One named Snn${servicename} and one named Knn${servicename}. Replacing nn with a two digit-number from 00 to 99, of course. The K-link might as well be optional at this point because of some issues in rc.sysvinit (and because it would kinda slow things down) so leave it out if you like, but basically when the machine enters a given runlevel, rc.sysvinit will run all the things linked that start with 'S' for 'start' in numeric order, like `/etc/rc.d/rc.3d/S91hal start`.

You can still mark your scripts non-executeable to prevent them from being run immediately after installation as per usual. I would actually recommend having them marked non-executeable at first, unless you're installing a very restrictive and minimal configuration that doesn't do anything like accept incoming connections from the Internet. If the default for your package is just to keep the local host's clock synched up and not service other clients, it seems somewhat reasonable to me to have it doing that immediately upon startup.

jamesf · 08-07-2006, 05:58 PM

Quote:

Originally Posted by evilDagmar

snip...
This is because even though the script might *run*, the commands it will try to run to terminate/restart/stop services are still going to be subject to the normal security model of Linux.
snip...
I'd suggest looking the rc.sysvinit script for a different way to go about invoking the startup. The one problem with the BSD-style init sequence Slackware has traditionally used is that it is not extensible in a modular fashion. Someone can install a package, and it will never be normally called on during startup unless they also go and add a line or two to rc.M or rc.local. This actually complicates things where they don't really need to be complicated. rc.local gets started last but one might easily argue that since it can change the system time abrubtly, it should be started as soon as the network is available, so rc.local isn't a great place for it. rc.M isn't an optimal place to put it because if Patrick releases an update that fixes something in rc.M, the update will make the start hook disappear.

I left so much in because it carried a lot of ideas. Middle first, ntpd will slew the system time (slightly faster or slower clock) unless specifically told not to (from my reading). I do see your point, though, and acknowledge the validity. I agree re: rc.M too. The discussion continues below.

Quote:

Originally Posted by evilDagmar

The answer to all this is really for things to finally start migrating towards using SysV init, especially in the case of third-party packages. Basically, you drop your startup script in /etc/rc.d as usual, and then in /etc/rc.d/rc.${runlevel}d you make two symlinks back to it. One named Snn${servicename} and one named Knn${servicename}. Replacing nn with a two digit-number from 00 to 99, of course. The K-link might as well be optional at this point because of some issues in rc.sysvinit (and because it would kinda slow things down) so leave it out if you like, but basically when the machine enters a given runlevel, rc.sysvinit will run all the things linked that start with 'S' for 'start' in numeric order, like `/etc/rc.d/rc.3d/S91hal start`.

I'm really not seeing the superiority of sysvinit stuff here. BSD: add a script to rc.d, add a line to rc.local. SysV: add a script to rc.d, add a couple of symlinks in other directories. And, you'll note, numbered in startup order. My rejoinder: at that point you're using a directory structure like a line-numbered text file (the S0-99 business) with specific slots that can fill up (the 0-99). If I have S49 and S50 and want something between them I get to rename, right? If I just put the new script's filename in a text file (rc.local, for example) then I can place it where I want with a fair degree of freedom. Comments?

snip...

Quote:

Originally Posted by evilDagmar

If the default for your package is just to keep the local host's clock synched up and not service other clients, it seems somewhat reasonable to me to have it doing that immediately upon startup.

Well, I'm serving the rest of my house's domain's machines, but that is pretty inconsequential, I'll agree.

Both of you had good ideas, I chose not to go the chmod go-x route because Pat has a distro and I don't. ;v)

Slim Backwater · 08-11-2006, 07:33 PM

I like your script. I wrote something similar but not the status option, (nor the log rotate) however I have a suggestion for an addition to the status: `ntpq -pn` or similar.

As for the issue of restarting as a regular user, I don't think a regular user can kill a root process. I would do a `sudo /etc/rc.d/rc.ntpd restart` to bounce it.

As for to comments about using sysvinit, isn't the BSD style init one of main differentiating characteristics of Slackware? Not that I'm saying there's anything wrong with sysvinit, but the suggestion is akin to suggesting that Redhat change their corporate colour to blue.

._.

jamesf · 08-12-2006, 01:48 AM

Thanks for the nice comments. Regarding the 'ntpq -pn', I considered it, but concluded that ntpd's algorithm for detecting problem servers and dropping them probably didn't need any help from me. ;v) I'm likely to try to 'optimize' things to the point of not working.

I did forget something extremely important, though. By default the calls to dhcpcd in /etc/rc.inet1 re-write /etc/ntp.conf. Override that behavior by adding a -N option to the dhcpcd calls. This applies to slackware 10.0, the only one I have. Check /etc/rc.d/rc.inet1.conf for other versions.

Everyone was right about the Linux security/restarting as a regular user problem. Thanks for the help, everyone.