-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

- -- 
Seth Kurtzberg
Machine Independent Software
Office:  (480) 661-1849
Fax: (480) 614-8909
email:  seth@cql.com
pager:  888-605-9296 or email 6059296@skytel.com

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUBO+WM4XhkmRgYZUCaEQLkuACfZUcEt1cON0asmiLsyZJx2i6x4L4An0PR
o92gnqkFJDMDOfrSy8wbH2LP
=Wa33
-----END PGP SIGNATURE-----