Simplifying the LFS Bootscripts

Ian Molton spyro at f2s.com
Sun Jan 9 16:25:24 PST 2005


Archaic wrote:
> On Sun, Jan 09, 2005 at 06:37:44PM +0000, Ian Molton wrote:
> 
>>How is that different from alexanders suggestion? all you did was make 
>>the changeable parts environment variables. I dont see how that helps.
> 
> Which is exactly what you did, except you strung them together.

I dont follow. what I proposed (and is currently the case) is a script 
(or pair of scripts) to read and process a set of configuration files 
(multiple) in a given directory.

you seem to be advocating a set of configuration files which are 
themselves executable which are called directly by a script which 
executed them sequentially.

> That's what I'm talking about. Apparently that isn't what you read,
> though. I'll be more pedantic. The network script has the up/down
> functions. It then proceeds to parse the configuration files in numeric
> order. For each file it processes, it looks at ONBOOT to see if it
> should be brought up or not. If not, skip it. If yes call up() with the
> variables contained in the configuration file. On shutdown, reverse the
> order in which the files are read (reverse-numeric).

Actually, in the first instance, there is probably very little point in 
bringing network interfaces up in any given order, given their 
asynchronous nature anyway.

what is important is that any routing / firewalling be in place *before* 
interfaces are brought up.

ideally, we need the scripts to:

1) Configure interface addresses and parameters.
2) Configure routing / firewalling.
3) bring up all ONBOOT interfaces.

In that order.

 > Again, there needn't be code to parse
> the filename for what could easily be a declared variable in the file
> itself.

Leading to formerly impossible errors such as a file with one name 
bringing up an entirely unrelated interface.

>>2) The content is clearly layed out and as such makes setting up an 
>>interface easy without needing to know what all the underlying tools are 
>>up to.
> 
> 
> It is good to know what ip is up to. That is a very good way of
> learning.

No. This ios a good way of teaching people to write cock-eyed, error 
prone bootscripts.

I think a __REALLY__ __GOOD__ way to let people learn would be to create 
a script that 'dry-runs' the bootscripts so that users can see exactly 
what the commands being run are, and actually SEE where things are going 
wrong.

Sadly, this may become a difficult task once things move over (and they 
will, unless we like windows users trouncing our boot times more than 
they laready do in some cases) to parallel / event driven bootscripts.

>>3) They are all parsed by a common script and as such share a certain 
>>level of error rejection.
> 
> My proposal also parsed the conf files with a single script, but
> apparently I wasn't pedantic enough the first time around. :)

Yes, howeevr your proposal doesnt really parse them so much as execute 
them, which allows for a whole range of new errors.

>>At present there is no need to order interface startup, so all that 
>>would do would be to obfuscate the filenames.
> 
> You may not have the need, but some people do,

Example?

 > and I don't see how
> 00-eth0 01-eth1 obfuscates things. In fact, it makes it more clear
> because you can also see order with an ls of the conf dir.

00-eth{0,1,2} etc. themselves dont obfustcate, however your proposal 
allowed for the interface brought up to be independant of the filename. 
that CAN obfuscate. and as I said before - network stuff is 99.9% 
asynchronous anyway - serialising interface bringup is pointless.

>>why specify the information twice, once in the name and once in the
>>file itself?
> 
> 
> You were worried about obfuscating the filenames, but I'm more
> interested in de-obfuscating the code.

You do that by centralising common code and breaking it up into neat 
modules. not by duplicating it abdly in multiple similar files.

 > We aren't trying to teach super
> advanded scripting.

If someone cant follow the network bootscripts they shouldnt BE writing 
bootscripts.

> One file tests ONBOOT. It just tests it each time for each interface
> since some may not be appropriate to bring up at boot.

I see what you mean there, my bad. but all my other criticisms still stand.

>>in fact, why not go all the way and hardcode the whole lot into a single 
>>script?
> 
> yeehaaaa! :) Cat all bootscripts into one and call it init. :)

;-)

> I vehemently disagree here. If someone does that, they will definately
> learn from it.

That it causes hours of frustration tracking down an error that only 
occurs in rare circumstances.

>>its much better to have common up/downing code parse some well defined 
>>data than to clone the up/downing code along with the data in every 
>>config file.
> 
> That is what I was saying. :)

Didnt look like it to me.



More information about the lfs-dev mailing list