Bootscript reorganization

Nathan Coulson conathan at gmail.com
Thu Jul 7 14:28:07 PDT 2011


On Thu, Jul 7, 2011 at 12:53 PM, Bruce Dubbs <bruce.dubbs at gmail.com> wrote:
> 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

that, is beautiful.

[ipv6 uses : for deliminators if I recall]
[not sure how static routes would work, does anyone actually use that
on LFS though?]
[dhcp, should work great.]

Still wouldn't mind something like
/lib/boot/services/{static,dhcp,bridge}  [with only static existing on
a lfs build].  and pass the parameters to the service script.


>> 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

Only way I could think to facilitate both goals, is having it modular.
 (ideally,  ifup/down should have no clue what ipv4, ipv6, or DHCP
means)

speaking of, I never dug into ipv6 yet, wonder what it's going to require.

>> - 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.

yeah, DHCP should probably be moved to the "not needed but nice" list
as well.  DHCP should remain BLFS, but able to be started from our LFS
network scripts.

wireless never really fit well into what the ifup/down scripts wanted,
and I cannot think of that ever changing.  (I suppose a static config
would be fine).

actually have myself a bridge service script

>> - 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.

perfect world,  would have it so Network Manager can use our network
tools,  but we don't actually need Network Manager in LFS.  [again,
never read up on it yet].

(Note: If this dream requires bloating/complicating ifup/down, then
it's not worth it in my eyes.  I have a hunch this is the case).

>> - 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.

When I was revising ifup/down for the bootscripts,  there was some
interest in bringing up the network when it was probed by udev.  (I
never used it myself, nor did I really have a use for it...).  At the
time ifup/down were written, I thought what we had was a bit cludgy,
as well as allowing a network interface to come up even if you ran
/etc/rc.d/init.d/network stop.

(just to clarify,  I have nothing really to offer in terms of why we
need this, and I would not use it for my own purposes.  It makes
things more complicated).

>> 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
> --
> http://linuxfromscratch.org/mailman/listinfo/lfs-dev
> FAQ: http://www.linuxfromscratch.org/faq/
> Unsubscribe: See the above information page





-- 
Nathan Coulson (conathan)
------
Location: British Columbia, Canada
Timezone: PST (-8)
Webpage: http://www.nathancoulson.com



More information about the lfs-dev mailing list