From: "Michael J. Cohen" <mjc@ispvip.biz>
To: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] Proposal: networking startup script rewrite
Date: Mon, 13 Oct 2003 22:17:02 -0400 [thread overview]
Message-ID: <200310132217.02407.mjc@ispvip.biz> (raw)
In-Reply-To: <D1EAAB31-FDC9-11D7-BA49-000A95795F3E@stellar.eclipse.co.uk>
> I'm not really sure what you regard as the failings of the current
> /init.d/net configuration. I have to say that I spent a couple of days
> struggling with it myself, and although I did whine about it at the
> time (see my postings <http://tinyurl.com/qsjh>) the upshot is that I
> rather like it the way it is.
Having /etc/init.d/net.eth[1,2,..] installed by the user does not mean that it
is automagically updated with a new install or with etc-update.
only basic configuration is achieved with the current setup.
etc-updating 99 files is a pain, but it often happens when upgrading
baselayout, etc. If a user wipes out his configs for iptables etc by
overwriting accidentally, he is in a bind. However if we do not provide a /
etc/conf.d/net and only a /etc/conf.d/net.sample; this is allievated.
> I'd agree that if a script to call `brctl` appropriately was installed
> by net-misc/bridge-utils then it would make configuration a lot easier,
> but this is a simple addition to a single package, rather than a
> rewrite of the whole framework. I really would like to see such an
> inclusion, considering that the bridging code is, I believe,
> incorporated into the upcoming 2.6.
Currently, there are several unrelated scripts for each userspace networking
tool. iptables, (your proposed bridge-utils), ipsec...
This is a bit backwards, and it relies on the initscripts' ability to order
correctly. If we load net as one script, we know exactly what is going on
and in what order and thus might be able to speed up booting by backgrounding
processes that are known to potentially take time.
The new system would most likely call the related /etc/init.d/bridge script or
similar in order to set things up, rather than invoking brctl directly. This
would save some headaches with updating the script every time we package up
some new network tool.
> Bridging works fine here & fairly seamlessly with the current
> framework. I found that everything fell into place once I moved
> /etc/conf.d/net to /etc/conf.d/net.eth0 & /etc/conf.d/net.eth1, so that
> it's contents (particularly with respect to gateways) are ignored by my
> /etc/conf.d/net.br0 script. Not much in addition is required to get
> everything up & running - I would have been glad to provide my scripts,
> if I had seen your posting to -user.
What about wireless + roaming, advanced routing/bridging, ipsec, vpns, vlans,
pppoe... all of these things either are not supported or are broken up into
tiny bits of configuration files everywhere. It would be much easier if we
had one manual with plenty of examples and one configuration file for people
to edit. Not only is it easier on the developers, but it is easier on the
user for updates and for configuration. The user no longer needs to hunt
down where he made what change to what interface in what file.
> I don't know much (erm... well, anything) about VLANs, so I'm probably
> missing some of your reasoning against the current system. Actually, I
> don't know much about anything, so maybe you could explain (like an RFC
> or a GLEP, maybe?), listing the problems of the current system & how
> your solution would resolve them..?
It was mentioned to me that it was quite challenging to add VLAN suport into
the current net scripts.
> I'm sorry if I seem biased or antagonistic, but really don't like the
> idea of uniting the network scripts in anyway like you describe. I may
> have struggled with them myself, but that's only because I'm so
> incompetent - I got there in the end. I once tried parsing one of
> Mandrake's network initialisation scripts, but floundered wildly - with
> Gentoo you know intuitively to look for iptables stuff in
> /etc/conf.d/iptables and so on.
Seems like it would make more sense to me if /etc/conf.d/net was your one stop
shop for all your networking needs.
> The only improvements I'd no ask for in the init scripts are more
> commenting - I'm firmly of the school that believes in 2 lines of
> comments for every line of code. I'd like to see all code
> human-readable for a newbie to the language.
Agreed. sometimes 5 or 6 is warranted for things like sed. :)
------
Michael
--
gentoo-dev@gentoo.org mailing list
next prev parent reply other threads:[~2003-10-14 2:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-13 18:56 [gentoo-dev] Proposal: networking startup script rewrite Michael J. Cohen
2003-10-13 22:09 ` Stroller
[not found] ` <D1EAAB31-FDC9-11D7-BA49-000A95795F3E@stellar.eclipse.co.uk>
2003-10-14 2:17 ` Michael J. Cohen [this message]
2003-10-14 14:09 ` Stroller
2003-10-14 15:21 ` William Hubbs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200310132217.02407.mjc@ispvip.biz \
--to=mjc@ispvip.biz \
--cc=gentoo-dev@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox