Bridge config in /etc/rc (patch)

[Sean Hamilton]

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?

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

|| 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. But the human side of things ought to be as flexible as possible.
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?

|| or, for multiple bridges
||
|| bridge_enable="YES"
|| bridge0_ifaces="fxp3,fxp4,fxp5"
|| bridge1_ifaces="rl0,rl1,dc0"
|
| I'm also not thrilled about this, although I assume that you copied
| the interface alias code, so it was reasonable for you to write it
| this way.
| The problem is, I'm not sure what the best way to replace this is.
| The problem btw is that if a user has 3 things (aliases, bridges,
| whatever), and they want to comment out the first or second, the
| subsequent entries must be renumbered, or the existing code misses
| them. That's not too hard when you have only three entries, but when
| you have hundreds, it's a big pita.

Yes, I agree. The obvious end user solution is to change the final entry to
match the number of the missing one, but that's still pretty bad. I didn't
so much copy the interface alias code as I did the interface alias design. I
don't really like it much either, but I wanted to keep it consistent -- for
instance, it would be no good if one counted from zero and the other from
one. I gave the option to have no number at all for a little flexibility,
especially if there is only one bridge, it makes no sense to index them.

In the end, I have used a small heuristic: the end user is very unlikely to
have more than three bridges, so this route is, in my mind, acceptable.

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.

|| I've also added an option, "ip_any_interface=YES" which sets
|| net.inet.ip.check_interface to 0. This felt more natural than
|| having the option, "ip_check_interface=NO".
|
| Err... have to give this some thought.

I know. It's a tough call, but I think it makes sense to try to keep
everything in the file no by default. At least, my submissions will be as
such. Otherwise it's unclear whether a line is redundant. I think you ought
to be specifying what you want, not what you don't want. Right now you have
to check /etc/defaults/rc.conf if you want to know if a line is actually
doing anything. It's like working with a person you can't really trust,
constantly checking what they're doing just to be sure.

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.

sh