Dave's Adventures in Qubeland; shells and boot configuration

Isn't chkconfig a good idea. The first time I came across it, it seemed to be just a status and service requirment function. (See also what I said last time here...). I used it via GNOME and Red Hat's service manager,and Red Hat's documents are here.... While working on my Qube I have been pointed at it again by ddclient (see also my blog here... about DDNS), I've come to the conclusion that its really rather good. Here is Linux About's link and here is the SGI link.

This works with rc start|stop scripts. Actually they encourage a "status" branch, and also a restart branch aka "stop; start". All you need is a configuration line and a description line in the script. Immediately below is the code from ddclient, the first line states the run levels for which this program is required , the start level priority and the stop level priority. (This contrasts with Solaris SMF, which does not state priority as scalar but as relative).

# chkconfig: 2345 65 35
# description: ddclient provides support for updating dynamic DNS services.

Copy the rc file to the /etc/rc.d/init.d directory, make the directory current and then issue the chkconfig -add command and the rc.d links will be created for you. i.e. the first string on the chkconfig: line defines the run levels at which the program will run

I have added the following (final two) lines to the opensshd script to permit chkconfig to work with it.

#!/bin/sh
# Donated code that was put under PD license.
#
# Stripped PRNGd out of it for the time being.
# Inserted by Dave Levy
# chkconfig: 2345 92 95
# description: This is the secureshell daemon

Running chkconfig --add ${opensshd_script_name} ensure that the links in the rc.d directory structure are created. This is neat; I've forgotten where to put it, and I don't have to muck around with remembering. Frankly I added the last two lines from the above to my rc script using vi, but it would be nice to automate it.

An additional problem however, is that the openssh project distributes the rc script with an incorrect directory for the shell. For Cobalt (and maybe other) Linux(es), you'll need to substiture the first line with #!/bin/sh, the code string below fixes this,

cat ${opensshd_script_name} | sed -e "s?\\#\\!/sbin/sh?\\#\\!/bin/sh?g" \\
    >> ${opensshd_script_name}.${script_ver}

We might want some version control code. The code above assumes that ${opensshd_script_name} and ${script_ver} have been set appropriately. I have considered using ls -t, head -1 and cut to create a version control semantic but the original script file has no version control suffix, and I am expecting to create a Linux variant. So

if [ `unname` -eq 'Linux' ]
then
  script_ver=Linux
# Change the shell interpreter
  cat ${opensshd_script_name} | sed -e "s?\\#\\!/sbin/sh?\\#\\!/bin/sh?g" \\
    >> ${opensshd_script_name}.${script_ver}
fi

This will create a file called opensshd.init.in.Linux. However, once you get started, there are so many ways to do this.-

exec_shell=`which sh`

and use ${exec_shell} as the substitution string in the sed command or maybe best of all; this works for all UNIXes without a /sbin/sh, and tightly aligns the implemented execution shell with its existence

if [ ! -x /sbin/sh ]&& [ -x /bin/sh ]
then
# Change the shell interpreter
  cat ${opensshd_script_name} | sed -e "s?\\#\\!/sbin/sh?\\#\\!/bin/sh?g" \\
    >> ${opensshd_script_name}.${script_ver}
fi

Maybe this is all too complicated, why they've selected /sbin/sh as the execution shell I have no idea, surely all the UNIXes on the port list have a /bin/sh and its guaranteed to be available at run level 1. Perhaps, they should just change the shell interpreter in the rc script source (, and add the chkconfig comment controls at the same time).

I've copied this article to the opensshd developer list, although while I hope they take notice of the shell issue, chkconfig is a Linux thing and hence many other UNIXes will have problems with it. So writing an if Linux test is a bit more complex than I have suggested above and they may feel that this is not a porting issue.

tags:

Comments:

A couple of guesses as to why they uses /sbin/sh: 1. It used to be A Good Idea to have /usr as a separate filesystem so that it could be mounted readonly. Using something in /sbin as the main shell meant that you were guaranteed not to have a dependency on some library in a filesystem that hadn't been mounted at the time. 2. Also Way Back When, there were some security attacks which worked by subverting the shared libs, rather than the shells themselves, to include backdoor code and the like. Using a statically-linked shell would stop attacks trying to use this vector. It's interesting that the contents of Solaris 10's /sbin aren't, in fact, statically linked any more. Ergo, don't try doing the separate-/usr-for-readonly thing.

Posted by Dave Walker on January 08, 2006 at 07:03 PM PST #

Post a Comment:
Comments are closed for this entry.
About

DaveLevy

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today