Bootscript reorganization

Bruce Dubbs bruce.dubbs at gmail.com
Thu Jul 7 12:53:48 PDT 2011


Nathan Coulson wrote:

>> 2. Â Remove /etc/sysconfig/network-devices
>>
>> Move the scripts ifdown, iftest, and ifup to /sbin. Â Integrate
>> ipv4-static* into the if* commands.
> 
> I did not like how ifup/down was getting complicated, but would this
> not lock us into ipv4/static support only?
> 
> ipv6 is around the corner, and there is Bridging/DHCP/Wireless to
> consider.  (also hotplug support, but I dont recall us having that
> now)
> 
> What would replace ifconfig.{$IF} file/directory?

The file I have in mind is /etc/sysconfig/network.  I think we can use 
variables like

eth0_onboot=yes
eth0_ip=1.2.3.4
etc

Alternatively we could use something like:

#TYPE:IP:PREFIX:MASK:GATEWAY:BOOT
eth0=static:192.168.1.1:24:192.168.1.255:192.168.1.1:onboot

> Slimming down ifup/down to skeletons, and putting the checks into the
> network-devices scripts, as well as moving the network-devices to
> /lib/something. is one option in my mind, but that does not solve
> everything.  [I have a few ideas, I can put together an example]
> 
> 
> I have not looked into gnome's network manager, but I wonder what it
> needs from the bootscripts to work,  What we have is LFS Specific (and
> at the time, there did not seem to be a cross distro solution to
> this).  [Note: Not sure if I would ever suggest using the network
> manager, but at the very least

I think most distros are network specific.  Trying to be compatible 
would require picking one.  I would be more interested in having the LFS 
user understand what the parameters mean.  The format is somewhat 
secondary.

Also, the large distros want to be able to drop a file into a directory. 
   We don't do that and I don't see where that is a requirement for us. 
  It makes a lot more sense to me for an LFS user to edit a single file, 
somewhat like the configuration file for Apache or php, but a lot 
smaller.

> Whatever solution we have, I would like to see the following
> 
> - ifup/down should be simple,  Anything interface/protocol specific
> should not be in these files
> - Should be possible to use with IPV4/IPV6/DHCP.

Aren't these two contradictory?

> - Would be nice if it can be used for Bridging/Wireless.

I think that's more of a BLFS issue, as is DHCP, but putting the 
configuration is one file does not rule against those issues.  A script 
just ignores variables it doesn't use.  Using wpa_supplicant is a little 
tricky because it does need a configuration file of it's own.

> - Should work with 3rd party configuration tools such as gnome network
> manager.  (wish I knew a commandline example...)

Well we do have the source...   Gnome Network Manager does claim to be 
cross platform and have a command line interface, but it also requires 
some prerequisite packages that are not really needed for LFS (e.g. 
d-bus).  I'm not sure it works without a daemon running.  It seems to be 
a lot of overhead for something like a server that never (or rarely) 
changes it's network configuration.  I haven't changed the network 
configuration on my desktop in over five years.

> - Hotplug support possible, possibly with 3rd party tool post lfs.

Hotpug of what?  A wireless card?   That seems to be a udev issue that 
is only peripherally related to the bootscripts.

> Solutions:
> - A modular solution, would allow us to use any protocol/setup w/o
> ifup/down knowing anything about it. [currently in lfs]

> - ifup/down last I dealt with had checks to determine if the interface
> existed or not.  This file can be a lot simpler, and these details can
> be pushed down into the modules.
> 
> I'll update this, once I find out what is out there for non lfs
> network configuration programs.  (I personally had no plans to ever
> install network-manager [unless I will be supporting it])
> 
>> 3. Â Place all configuration parameters for the network into
>> /etc/sysconfig/network.
>>
>> This would include the HOSTNAME as well as any information in
>> /etc/sysconfig/network-devices/ifconfig.*/*

   -- Bruce



More information about the lfs-dev mailing list