Subject: Re: history, design, or both?
To: NetBSD Networking Technical Discussion List <email@example.com>
From: Seth Kurtzberg <firstname.lastname@example.org>
Date: 11/04/2001 11:45:53
-----BEGIN PGP SIGNED MESSAGE-----
Rather than change the conf file formats themselves, I'd rather build a small
parser that generates the required information mapping, as you suggest,
addresses to devices. It is possible that you could modify the conf format
in a backward compatible way, but it isn't clear to me that this is the case.
It would be straightforward to run a tool that generates the configuration
files, and then to run the ipnat and ipf utilitiies based on the generated
configurations. If a change is required to rc.conf, then this is obviously
more difficult; I don't usually change rc.conf, though.
In a twist on this same theme, I had a user replace a broken NIC card with a
new one from a different manufacturer (not an unusual situation). Originally
the box had rtk0 and rtk1; after the board swap, it had rtk0 and fxp0. This
meant that another configuration file change was needed, although in this
case it was a simple name change from ifconfig.rtk1 to ifconfig.fxp0.
Obviously not a problem for people who understand the configuration of the
system; but my user wanted to know why the green light wasn't coming on. (I
know, but we have to deal with this type of user.) This case would be easy
to automate, as there was no longer an rtk1 device and there was a xxx0
device not referenced in the configuration. Other cases would be more
difficult to deal with.
Still, I'd prefer not to change the current configuration method, but to use
a preprocessor approach. In addition to the obvious reasons, adding
indirection to the configuration files would make troubleshooting more
difficult, especially from a distance. Hiding physical configuration
information that is currently available (by parsing the config files in this
case) would also break some tools that I've written, and very likely other
people's tools as well. In this case, backward compatibility, even if
achievable, would still cause problems and make tool modifications necessary.
On Sunday 04 November 2001 10:56, you wrote:
> [ On Sunday, November 4, 2001 at 00:20:59 (-0500), Mike Pelley wrote: ]
> > Subject: Re: history, design, or both?
> > There is often more than one file to edit or rename. On my machine, for
> > instance, there would be three, and it is just a home machine. In many
> > circumstances it would be advantageous to avoid editing any files
> > (say, in a remote 3rd party data centre).
> Same here. On my home router, with three physical interfaces and at
> least one virtual interface, the three files to edit are rc.conf,
> ipf.conf, and ipnat.conf
> I'd really like it if I could use some form of indirection in ipf.conf
> to avoid having to muck in it.... Perhaps something along the lines of
> "use the interface with this address".....
> > It would be disconcerting to have higher numbered interfaces slide down
> > when a card is removed (although this parallels hard drives). Often
> > replacing a defective ethernet card is time-critical, whereas removing
> > an ethernet card rarely is. I would rather see the shell access
> > required for the less urgent situations.
> This is a problem more related to hardware architecture and how device
> drivers detect and attach to the desired device(s) than how devices are
> named.... If your hardware is capable enough, and if you've wired down
> your devices in your kernel configuration, then your interfaces won't
> renumber when you pull a card or whatever.
Machine Independent Software
Office: (480) 661-1849
Fax: (480) 614-8909
pager: 888-605-9296 or email email@example.com
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8
-----END PGP SIGNATURE-----