Example LINUX init Script

From time to time, people want me to create LINUX init scripts for them. I usually just take an existing one for another service and change it up to work for my new application, but most of them have become so long these days that I end up having to hack out a ton of code just to reduce them down to the very basic script I need. I decided to create this very simple template so I wouldn’t have to keep trimming down the more complex scripts that one tends to find in /etc/init.d these days.

This script is chkconfig compatible, so call it the name of your new service and put it in /etc/init.d

The chkconfig: 235 section indicates the the default runlevels. For instance, if we called this script /etc/init.d/new-service and ran chkconfig new-service on, it would be active in runlevels 2,3 and 5.

The 98 and 55 numbers indicate the order of startup and kill. This means that using this tag, the startup symbolic link would be named S98new-service and the symbolic link to kill the process would be named K55new-service.

#### SNIP ####

#! /bin/sh
# Basic support for IRIX style chkconfig
###
# chkconfig: 235 98 55
# description: Manages the services you are controlling with the chkconfig command
###

case "$1" in
  start)
        echo -n "Starting new-service"
        #To run it as root:
        /path/to/command/to/start/new-service
        #Or to run it as some other user:
        /bin/su - username -c /path/to/command/to/start/new-service
        echo "."
        ;;
  stop)
        echo -n "Stopping new-service"
        #To run it as root:
        /path/to/command/to/stop/new-service
        #Or to run it as some other user:
        /bin/su - username -c /path/to/command/to/stop/new-service
        echo "."
        ;;

  *)
        echo "Usage: /sbin/service new-service {start|stop}"
        exit 1
esac

exit 0


#### /SNIP ####

Obviously change all instances of “new-service” to the name of your actual service… Enjoy!

Horde / IMP on RHEL 4 From RPM HOWTO

Whenever you go to install applications and services on registered RHEL servers, it’s always nice to use the RPMs because up2date will keep everything current for you. Managing upgrades gets a whole lot easier when you can bring your system up to current with one simple command. Because of this, I decided that I would try to use as many RPMs as I could when I set up our latest Horde / IMP installation.

Unfortunately, RedHat does not supply RPMs for the Horde applications, but luckily CentOS does. You should be able to download them from here. Get the latest version, which at the time of this writing was horde-3.1.3-1 and imp-h3-4.1.3-1.

Don’t install them yet though because Horde and IMP have always had a lot of dependancies which must be installed and enabled first. Installing the following RPMs should take care of them.

  • mysql-4.1.20-1.RHEL4.1.i386.rpm
  • mysqlclient10-3.23.58-4.RHEL4.1.i386.rpm
  • mysqlclient10-devel-3.23.58-4.RHEL4.1.i386.rpm
  • mysql-devel-4.1.20-1.RHEL4.1.i386.rpm
  • mysql-server-4.1.20-1.RHEL4.1.i386.rpm
  • perl-DBD-MySQL-2.9004-3.1.i386.rpm
  • php-4.3.9-3.15.i386.rpm
  • php-devel-4.3.9-3.15.i386.rpm
  • php-domxml-4.3.9-3.15.i386.rpm
  • php-imap-4.3.9-3.15.i386.rpm
  • php-ldap-4.3.9-3.15.i386.rpm
  • php-mysql-4.3.9-3.15.i386.rpm
  • php-pear-4.3.9-3.15.i386.rpm

Assuming you will want up2date to handle upgrades of these packages, it is very important that you either use “up2date” to install them, or download them from correct channel at the RedHat website. You could also simply get them from the CD distribution that you used to install the system itself.

Once PEAR is installed, you will have to upgrade it, and install the PEAR::Log module.

[root@server]# pear upgrade -a PEAR-1.3.6
[root@server]# pear upgrade PEAR

Ok, now let’s make sure the web server is configured to start when the system comes up:

[root@server /]# /sbin/chkconfig --list httpd

You should see this:

httpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off

But if you see 5:off, simply run:

[root@server /]# /sbin/chkconfig httpd on

Now we enable and start up our new MySQL database server:

[root@server /]# /sbin/chkconfig mysqld on
[root@server /]# /sbin/service mysqld start

And we’re ready to install Horde and IMP. Install the following RPM’s, which will put everything in /usr/share/horde and creates a file called horde.conf in /etc/httpd/conf.d/

  • horde-3.1.3-1.c4.noarch.rpm
  • imp-h3-4.1.3-1.c4.noarch.rpm

This will install the HORDE and IMP packages in /usr/share, and /usr/share/horde respectively.

Finally, we start or restart apache:

[root@server /]# /sbin/service httpd start

Grab a browser and go to the following URL to proceed with the Horde and IMP configuration.

http://server.example.com/horde/

Getting ntpd to work correctly on RHEL

When many new servers are delivered from the factory, the system clock is way off. Most UNIX systems run “ntpd” to keep the time in sync with internet time servers, which are, in turn synchronized against an atomic clock. This results in a system time that is very very close to the “actual” time of day. The downside, however, is that even a properly configured “ntpd” will not synchronize the system clock if it is too far out of sync with the time server. To remedy this, we first have to run “ntpdate” to get the system clock close to the correct time, and then enable “ntpd” to keep it there.

The first thing we have to do is “ntpd” to free up the port for “ntpdate”:

[root@server /]# /sbin/service ntpd stop
Shutting down ntpd:                                        [  OK  ]

This frees up the port for ntpdate. Next we run:

[root@server /]# /usr/sbin/ntpdate time.apple.com

Now the time should be set correctly. We then change the default time servers to something like the following in /etc/ntp.conf:

# --- OUR TIMESERVERS -----
time-a.timefreq.bldrdoc.gov
time-b.timefreq.bldrdoc.gov
time-c.timefreq.bldrdoc.gov

We can use any time server we want, but I like these and find them to be reliable.

Finally, start backup up your “ntpd” service, and your all set to go.

[root@server /]# /sbin/service ntpd start
Starting ntpd:                                        [  OK  ]

Remember to use “chkconfig” to make sure “ntpd” is enabled to come up when the system starts.

Setting Up The Automounter Service on RHEL

Mounting filesystems in RHEL is pretty straightforward and easy. Occasionally, however, you will not want the filesystem to remain mounted all the time, but rather to automatically mount for a set period of time only when it is needed. Because of networking overhead, and the general unreliability of networks, NFS mounts are a good example of when this can be especially useful.

In order to manage the automatic mounting and unmounting of filesystems on RHEL, we use the Automounter service. Here is how.

First, The main configuration file is “/etc/auto.master”. It should look something like this:

#
# $Id: auto.master,v 1.3 2003/09/29 08:22:35 raven Exp $
#
# Sample auto.master file
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# For details of the format look at autofs(5).
#/misc  /etc/auto.misc --timeout=60
#/misc  /etc/auto.misc
#/net   /etc/auto.net


Let’s assume that we want to set up an NFS mount on “/misc/backups”. We would first create an entry in this file that looks something like this:

/misc   /etc/auto.misc --timeout=120


This tells the autofs service that we want to use it to manage mounts from within “/misc”, that the configuration file is “/etc/auto.misc”, and that it should disconnect after 2 minuets of inactivity.

Now, let’s edit the “/etc/auto.misc” file. The file has three columns: the mount point from within the /misc directory, the options for mounting the filesystem, and the filesystem to be mounted. It also includes the remote server’s name since we are using NFS. It should look something like this when you are done:

#
# $Id: auto.misc,v 1.2 2003/09/29 08:22:35 raven Exp $
#
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# Details may be found in the autofs(5) manpage

cd              -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom
backups         -rw,soft,intr remoteservername:/path/to/nfs/export

# the following entries are samples to pique your imagination
#linux          -ro,soft,intr           ftp.example.org:/pub/linux
#boot           -fstype=ext2            :/dev/hda1
#floppy         -fstype=auto            :/dev/fd0
#floppy         -fstype=ext2            :/dev/fd0
#e2floppy       -fstype=ext2            :/dev/fd0
#jaz            -fstype=ext2            :/dev/sdc1
#removable      -fstype=ext2            :/dev/hdd


Next, we create the directory for the mount point in /misc:

# mkdir /misc/backups

And finally we restart the autofs service:

# service autofs restart

That should pretty much do it. If you don’t have autofs configured to start up, you can use chkconfig to enable it. “/misc/backups” will now be mounted whenever a user or process attempts to access data on it, and it will be automatically disconnected after 120 seconds of inactivity. Last, but not least, you can always confirm that it is running with the “service” command:

# service autofs status

As always, change the details to match your own requirements.

Controlling Services With chkconfig

Many system 5 UNIX variants use scripts in the /etc/rcN.d/ directories to control which services should be started in the various runlevels. If, for instance, you wanted the secure shell daemon to run in runlevel 4, you would put a script named something like “S55sshd” in “/etc/rc4.d”. This script would usually accept the “start” “stop” and “restart” arguments, as well as the commands to perform these functions. When the system came up, it would execute “/etc/rc4.d/S55sshd start” when it transitioned into runlevel 4. On the way down, it would execute “/etc/rc4.d/S55sshd stop” as the system passed from runlevel 4 to runlevel 3. If you had made some changes to the sshd configuration file, and wanted to restart the service, you could manually execute “/etc/rc3.d/sshd restart” to kill and then restart the daemon.

Since this model involved having multiple copies of the same script in many different directories, Linux and others have adopted the standard of putting all service control scripts in “/etc/init.d/”, and using symbolic links to these scripts in the various “/etc/rcN.d/” directories. This allowed for the SGI IRIX innovation of the “chkconfig” command, which is command line tool that manages the symbolic links for you.

How to use “chkconfig” in Red Hat Enterprise Linux:

First, all your service control scripts need to be in the “/etc/init.d/” directory. They should reflect the name of the service they control. In our example, the file is named /etc/init.d/sshd”.

Secondly, they have a tag at the head of the script that looks something like this so that “chkconfig” understands that it can controll it:

# Basic support for IRIX style chkconfig
###
# chkconfig: 2345 55 25
# description: Manages the services you are controlling with the chkconfig command
###

The first set of numbers “2345” is are the default runlevels for the service, and “55” and “25” represent the name of the “S” and “K” symbolic links, and the order in which the service will be started and stopped in the respective runlevel. You will need to change these last two numbers, making them unique.

Once these requirements are met, using the command is fairly simple. When we go into /etc/rc3.d, we see a file called “S55sshd”.

[root@calvin rc2.d]# cd /etc/rc3.d
[root@calvin rc2.d]# ls -al S55sshd
lrwxrwxrwx 1 root root 14 Nov 15 15:10 S55sshd -> ../init.d/sshd

We see this file is a symbolic link to “../init.d/sshd”. Let’s run the “chkconfig” command to turn sshd off.

[root@calvin init.d]# /sbin/chkconfig sshd off
[root@calvin init.d]# /sbin/chkconfig --list sshd
sshd 0:off 1:off 2:off 3:off 4:off 5:off 6:off

chkconfig --list sshd confirms that sshd has been disabled in all runlevels, and the symbolic link has been removed from all “/etc/rcN.d/” directories.

Let’s turn sshd back on:

[root@calvin init.d]# /sbin/chkconfig sshd on
[root@calvin rc2.d]# /sbin/chkconfig --list sshd
sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off

chkconfig --list sshd confirms that sshd has now been enabled in runlevels 2, 3, 4 and 5, and we see s symbolic link to “/etc/init.d/sshd” named “S55sshd” in “/etc/rc2.d/”, “/etc/rc3.d/”, “/etc/rc4.d/” and “/etc/rc5.d/”.

Let’s imagine now that we only want sshd to be enabled in runlevel 5. We run the following command to accomplish this:

[root@calvin rc2.d]# /sbin/chkconfig sshd --level 234 off
cd /etc/[root@calvin rc2.d]# /sbin/chkconfig --list sshd
sshd 0:off 1:off 2:off 3:off 4:off 5:on 6:off

chkconfig --list sshd confirms that sshd has been disabled in all runlevels except 5, and the “S55sshd” has been removed from “/etc/rc2.d/”, “/etc/rc3.d/” and “/etc/rc4.d/”.

There is, of course, more to it, but this should get you well on your way to happily managing your system services with “chkconfig”.