Bootscript reorganization

Bryan Kadzban bryan at kadzban.is-a-geek.net
Thu Jul 7 20:19:49 PDT 2011


Bruce Dubbs wrote:
> Nathan Coulson wrote:
> 
>>> 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.
> 
> I'm not sure about that.  :)

Adding extra fields for each new service seems ... really suboptimal.
(Like the "printip" and "printall" fields for the dhcpcd service.
Though that may not be too bad, since you'd change the first "word" as
well.  Worse would be the wol script I have; you can add it to any other
interface setup, and it'll run ethtool to enable WoL in whatever mode
you configure it for.)

>> [ipv6 uses : for deliminators if I recall]
> 
> Yes, of course.  I forgot about that.  Setting up a ipv6
> configuration shouldn't be any more complicated than ipv4.  The same
> entries, ip, mask, broadcast, network, default router are all the
> same concepts.  The actual stack is more complicated of course and
> the format of the numbers is different, but the principles are the
> same.

Yes, but if we change the file format to something that *explicitly*
only works with static, everyone will have to do a fair bit more work.
Rather than just having the BLFS dhcpcd page say "drop this file in
ifconfig.<nic>, and edit it if you need to", it'll have to reengineer
the service parsing at least.  And multiple configs per interface would
*seem* (at least I think) to be impossible?

And so on my own machine, instead of adding another service named "wol"
that runs "ethtool -s <interface> wol <method>" (where <method> comes
from the config, and is usually "p", but can be one of about ten
different values IIRC), I now have to complicate the parsing of any
other service I use.

I am *strongly* in favor of BLFS just being able to drop files into a
directory and make it work (mostly because I also want to be able to do
that outside BLFS).

Parsing of a format like the above also seems rather too complicated
(IMO) for shell...

>> [not sure how static routes would work, does anyone actually use
>> that on LFS though?]

I don't, but only because I don't have a box that needs strange routing
anymore.  I used to administer one (needed a static route to get through
a couple of other subnets), although I set up the static routes in a new
static bootscript, and it wasn't actually LFS either.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20110707/313f771f/attachment.sig>


More information about the lfs-dev mailing list