Bridge config in /etc/rc (patch)

[Doug Barton]

On Tue, 6 May 2003, Sean Hamilton wrote:

> Doug Barton wrote:
> | On Mon, 5 May 2003, Sean Hamilton wrote:
> |
> || Greetings,
> ||
> || As I manage three FreeBSD bridges, I found it somewhat irritating
> || that there was no convenient way of doing so.
> |
> | I have to disagree with this. /etc/rc.local has always existed to
> | handle these kind of edge cases. I'm not even sure we want to have
> | something like this in /etc/rc.conf, because we already get
> | complaints that there are too many options, and it's too hard to
>
> The settings are there to be set, regardless of whether or not they are in
> rc.conf, no?

True, but that's another step down the road of "How do we deal with the
issue of $BIGNUM conf options in a way that users can handle?" Our current
solution for that is to include them all in /etc/defaults/rc.conf, and
mostly in rc.conf.5. I'm not sure that solution scales, but I'm equally
uncomfortable with the idea of UNdocumented options.

We currently have a situation with /etc/start_if.INT where users don't
know that this mechanism exists, and therefore they don't take advantage
of it. BTW, I forgot to mention that this is another valid way of dealing
with the issue of setting up bridge's, although I'm not sure it's ideal.

> | configure. On the other hand, we have
> | the line of reasoning that says there should only be one
> | place/method of configuring boot time parameters.
>
> As for /etc/rc.local, normally I wouldn't mind, but I was experiencing
> issues earlier where if I placed the bridge configuration in
> /etc/sysctl.conf, I had to do my ifconfigs in /etc/rc.local... or
> something... I don't remember exactly what the arrangement was, but the
> "obvious" way of doing it was doing things out of order, and causing things
> to break. So this became necessary. It will at the very least make life easy
> for myself, as I plan to use it.

Well that's certainly the right attitude to have. :) I agree that the
ordering is a problem sometimes. The sysctl ordering problem should be
fixed now, since we added back the 'late' sysctl setting run into rcNG.
However, since (as your script demonstrates), it's sometimes necessary to
kldload bridge, I think it makes more sense to do this in /etc/rc.local,
which means that it gets run pretty close to last.

> || Configuration goes like this:
> ||
> || bridge_enable="YES"
> || bridge_ifaces="fxp0,fxp1,fxp2"
> |
> | I would prefer that this variable match the argument to sysctl. This
> | not only makes the conf file easier for people to configure (because
> | there are examples in the man page), but it also makes your code
> | easier, since you don't have to sed out the commas.
>
> I completely disagree with you here. Programmer laziness is the source of
> seemingly endless badly designed software. The syntax of the sysctl is
> stubborn because you don't want to be doing fancy text parsing in the
> kernel.

Ok, I agree with you up to this point.

> But the human side of things ought to be as flexible as possible.

I semi-agree with this, which is why the rc scripts aren't case sensitive
for things like YES/yes/Yes, etc.

> And, the same thing is done elsewhere in rc... the whole point of rc, as I
> take it, is to hide the nitty-gritty internals from the user and provide a
> clean interface to the functionality of the system. Right?

To a certain extent, yes. However, there is no reason to complicate the
code by A) making the simple syntax used in the sysctl more complicated,
and B) therefore making the rc parsing code more complicated too.

> The alternative is the approach taken by static routes:
>
> bridges="jim dan bob"
> bridge_bob="...
>
> But, this requires extra work for the user to get it up and running in the
> first place, especially if they only have one bridge, which is going to be
> most people.

Right, you've essentially hit on the problem here. :) Rather than making
more things look like the alias code, we're currently looking at ways to
make the alias code better, and more flexible. I have some ideas in this
area, and so does Mike.

> There are a number of other sysctls which I'd like to see moved to the rc
> scripts, and would be happy to do so myself. The argument that they're busy
> enough, or that people are better off learning the sysctl syntax, seems null
> to me... it's not like I'm removing sysctl, I'm just exposing it.

If you're really interested in this area, I think the first step would be
to help with the documentation, especially the man page'ification of the
sysctl tree. Second on that list (in my mind) would be more examples in
/etc/sysctl.conf.

In addition to the problems of user overload, ordering (and other
problems) get more complex in rc.d the more scripts you add.  That's why
I'm currently favoring more generalized structures like devd.conf, and
devfs.conf rather than individual scripts for every little thing. But,
this is still evolving as we get more experience with the new system.

Doug

-- 

    This .signature sanitized for your protection