Summary: some suggestions to have a cleaner and easier setup
Keywords: plugins, compatibility, init, SysV, simpleinit, configuration, sh-scripts


r2d2 is a newly developed boot-concept. It combines the ease of
"simpleinit" known from slackware with the power and flexibility of
"init" known from RedHat, Debian or S.u.S.E. etc. It is fully
compatible to SysV init.

Usally the setup of runlevels is expressed with hundred of links
somewhere under /etc. This scheme is neither intuitive, nor effective
and the reason for that is simple: the root-filesystem is not designed
to store complex structures efficiently. Well, symbolic links do not
hold own content, so they are equal to lines in file. (Remember that a
directory is nothing more than a special file.)

r2d2 reads a single, simple structured file to perform it's task of
starting and stopping services. Example excerpt:

	#<sort> <off->  <on-levels>     <command>
	20      0,1,6   2,3,4,5         /etc/init.d/ssh

Since the first public release in August 1997 not much has changed
regarding the core functionality. Only the feature "searchpath" was
added, which allows relative names for commands. In effect, it makes
configuration files of different Linux distributions compatible to
each other. The rest was bug-fixing.

The main difference, which rectifies a new announcement, is bunch of
sample init-scripts added to the package. These can be classified into
two main groups:

	(1) networking plugins
	(2) hardware setup using configuration files

Let's start with the second type of scripts. There are some utilities
on my system which can't read a configuration file themselves. For
example: ifconfig, setserial, arp, hdparm, ipfwadm, isdnctrl, etc. As
shell-scripts are good at rapid prototype development, I wrote some
wrappers to emulate the missing functionality. Example:

	#<device>  <owner> <group> <permissions> <setserial options>
	/dev/ttyS0 root    dialout rw-rw----     auto_irq skip_test autoconfig

This is an excerpt from my file "serial.cfg", you can compare it
to your /etc/rc.boot/0setserial. Now, you will ask for the advantage
of such an approach, because the information is now in one (big)
configuration file plus one small shell-script instead of just one big
shell-script. The answer is easy: by seperating configuration and
code, the scripts become truely upgradeable and the configuration is
easier to survey. The first is a big plus for distribution maintainers
and the second is a plus for the system administrator.

Let's have a quick look at another example: ifconfig. You may want to
compare the script installed on your system with the following
configuration file, which also handles IP-aliases for virtual domains:

	#<if>   <ip-address>    <broadcast>     <netmask>
	lo      127.0.0.1       127.0.0.255     255.255.255.0
	eth0    192.168.1.2     192.168.1.255   255.255.255.0
	eth0:0  192.168.1.3     192.168.1.255   255.255.255.0

That should be enough regarding the hardware setup. Now about the
network plugins. The existance of /etc/inetd.conf is somewhat
unsatisfying, because it introduces another type of configuration
compared to the networking services that run in standalone mode. The
only argument for this file is that one would loose the survey over
everything if it was not there.

This argument is non existant when using r2d2 because you have an
instant survey over all your init-scripts. Therefore /etc/inetd.conf
must only be kept for the internal services of inetd (and temporary
reasons). My file /etc/init.d/runlevel.cfg looks as follows:

	#<sort> <off-> <on-levels>     <command>
	30a     0,1,6   2,3,4,5         net/telnetd
	30b     0,1,6   2,3,4,5         net/ftpd
	30c     0,1,6   2,3,4,5         net/smtpd
	30d     0,1,6   2,3,4,5         net/pop3d_192.168.1.1
	30e     0,1,6   2,3,4,5         net/pop3d_192.168.2.1

That means I can execute the command /etc/init.d/net/telnetd stop
to stop the telnet service. The script communicates with (x)inetd
to give him the responsibility of maintaing the telnet-service.
And - the scheme can be used with inetd or xinetd. The strongest
argument against xinetd, the non-standard format of the configuration
file, vanishes because the file itself does. :-)
The code of the net/telnetd script is so short that I can print
it here:

	ENTRY="telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd"

	case "$1" in
	    start)  inetd_plugin add service $ENTRY ;;
	    stop)   inetd_plugin remove service $ENTRY ;;

You can imagine that it's very easy to generate such a script
automatically from an existing /etc/inetd.conf.
