Simplifying the LFS Bootscripts
spyro at f2s.com
Sun Jan 9 10:37:44 PST 2005
> On Sun, Jan 09, 2005 at 05:41:48PM +0000, Ian Molton wrote:
>>I recon the /etc/sysconfig/network-devices/eth1 file should contain:
>>ADDR=192.168.0.101/24 broadcast 192.168.0.255
>>ADDR=192.168.0.102/24 broadcast 192.168.0.255
>>Or something similar.
> With that, you may as well be typing in the commandline, which IMO is
> more educational. How about up() and down() doing something like:
> ip link set $DEV up
> ip addr add $IP/$PREFIX broadcast $BCAST dev $DEV
How is that different from alexanders suggestion? all you did was make
the changeable parts environment variables. I dont see how that helps.
We're talking about configuration files here, not boot scripts.
configuration files *describe* things (in this case the interface
configuration scripts [can] read in configuration files and process them
in order to work out what to do.
the current method (or something similar) has many advantages
1) The files are clearly named and its obvious what they are for.
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
3) They are all parsed by a common script and as such share a certain
level of error rejection.
Alexanders proposal potentially throws away all three of those benefits
(the name of the file no longer [necessarily] reflects the interface,
the content is a mishmash of commands with differing parameters, and the
y have NO immunity to common types of error (cutnpaste being a common
error wether you like it or not, and everyone does it)
> Name the config files numerically so that all you have to do is call all
> the files in that dir in numeric order.
At present there is no need to order interface startup, so all that
would do would be to obfuscate the filenames.
> If ONBOOT=yes, run the up() or
> down () function on it. I say forget naming the files based on their
> device. Why introduce code to parse the filename when a simple
> declaration of the device can be made in the file?
What do you suggest we name the file then? why take away a meaningful
name? Assuming the file remains named after the device, why specify the
information twice, once in the name and once in the file itself?
also, if each file tests its own copy of ONBOOT, why not do away with
ONBOOT and just hard code it?
in fact, why not go all the way and hardcode the whole lot into a single
>>and the up and downing process shouldnt be part of the configuration
>>file, it should be part of the script that interprets the file.
In which case, whats left? you cant agree with that and leave a valid
case open for add/del-ing the addresses in the config file.
>>Also your proposal leaves open a wide margin for sut-n-paste errors in
>>that people will copy the 'add' lines and use them for the 'del' lines
>>too, just changing the add to a del (or more likely, forgetting to).
> Not to sound harse, but that is their problem. The whole book implies
> the ability of the user to correctly transfer the text in the book to a
> commandline somehow.
Yes but its also a teaching tool, and a tool that makes it hard to
pinpoint an error (eg. 'why does my eth2 vanish when I switch runlevel
or something) due to cut-n-paste isnt going to teach much other than
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
make it -2 actally ;-)
More information about the lfs-dev