automated installations (8)

Part 8 !

Yesterday I played around in the postinst script to get a decent network configurator. If you think that it's hard using only bash and netcat to test a network, you are correct. But inside the Debian installer initrd, its far worse. Netcat doesn't have all the options I'm used to and there is no decent debugging infrastructure.

I got the network configurator working in the sense that it can scan all network interfaces and find out which one can be used to connect to the outside world. I made a complicated scripted system with all kinds of ropes and pullies that would make Daffy Duck proud.

Basically, I go over all network interfaces and for each network interface, I bring up the interface, test if I can connect to some IP on some port and then bring down the interface. At the end of this loop, I have a collection of usable interfaces.

The hard part is how to test the network. The netcat inside D-I (Debian Installer) doesn't have a timeout option or anything else I can use. I've considered using ulimit -t, which limits processor time, but netcat doesn't use much of that. The connect call is mostly waiting in kernelspace.

The only workable alternative is to have a script running in the background that waits for 3 seconds or so, and then kills any netcats that are running. That way, if netcat can't connect, it will get killed. If it can connect, that's a nice thing. In any case, I have the result after 3 seconds.

I've attached the current set of scripts.
There are 4 scripts:


This is the script that is run after netcfg is installed. This will actually ask the questions to the user and call all other scripts. This is also the script that used to call the netcfg binary program, but I got rid of that call since I want my own code to be executed instead.


The obfuscated name of this script stands for NetCat TeST. This is the main script to test a network configuration. It accepts a few arguments on the commandline, and then brings up an interface, does a netcat and brings down the interface


This is the NetCat Killer. It doesn't kill netcat though. I kills nctst. In fact, it just sends a SIGNAL to nctst, not killing it. What's the reason behind this ? Well, right before the postinst script calls nctst, nck is started in the background. Nck waits for 3 seconds and then kills all nctst scripts with the signal SIGHUP. Inside nctst, there is a signal handler that will report that the currently tested interface is no good for connecting to the outside, and then exits the nctst script cleanly.


This is the nck killer or NetCat Killer Killer. So, we started a nck in the background which will wait 3 seconds and then kill off nctst. Then we start nctst in parallel. Now if nctst returns fast (in case of a good network connection on the current interface), we don't want nck to keep running in the background. So when nctst returns (either with OK or NOK), we kill of any nck's running in the background to make sure they are gone and won't interfere in the future.

In addition, I also added some debconf templates (also attached).

Everything works nicely. So the whole netcfg story is probably behind me.

I've changed the post-installation script to remove some packages and install some other.
I've also added code in the script to generate /etc/environment and set the timezone.
The ugliest patch in the script is the one to get rid of lpd: When removing lpd, it asks if it should remove /var/spool/lpd. This question is not preseedable. So I just deleted the postrm script of lpd (actually, emptied it) and performed its tasks myself.

The next thing to do, is install postfix instead of exim4.
The correct way to install postfix on our servers would be in "satellite system" mode. This means the server receive no mail themselves, but send all mail out to a central mailhub.
Also very important is to have only "localhost" in the mydestinations setting, because otherwise it will accept mail locally that you are trying to send out through the mailhub.

Since postfix doesn't seem to like being installed automatically and with preseeded values (I can't even install postfix as a dependency of another package, because exim is installed and debian bitches about it)
I will probably create a kulnet-postfix package that does the configuration of postfix in a postinst script. I might also make a kulnet-postfix-cav package or similar that will have the configuration for our mail cluster.