RE: RFC: new network config (was: Re: network configuration)
Craig Sanders writes:
> maybe the simplest thing to do would be to count the number of alias
> interfaces defined in /etc/interfaces, and start creating them from
> n+1...but this doesn't correctly cover the situation when a new alias
> has been added to /etc/interfaces AFTER virtual-services has been run.
This is exactly the problem with allowing these interfaces to be defined in two places using two methods, but this is necessary.
> hmmm. maybe the "correct" (safest) way to do it is for
> /etc/init.d/interfaces to call my virtual-services interface creation
> script if it exists. then the Right Way<tm> for a system admin to create
> *ALL* of the interfaces is always to run /etc/init.d/interfaces - that
> way, all interfaces, including aliases, will always be created in the
> correct order.
I don't see how this will automatically do the right thing if I manually set up an alias. Disallowing something in a debian policy that is do-able techncially (perhaps inadvertently) is a bad idea. There needs to be away to keep track of which interfaces were used for what last time the interfaces were set up by these scripts. Clashes in the manual settings and the previous auto settings need to be resolved somehow. Clashes between current manual settings and previous manual settings obviously don't. I think the correct behavior should be for the interfaces to be tracked in a state file (or config db) that gets checked when these scripts set them up and the previous auto behaviour should prevail. e.g. if I had manually configured
eth0:1 ip=1.2.3.4
eth0:2 ip=1.2.3.5
one day and 30 virtual hosts setup in virtul services after that and then decided I needed another alias for myself so added it in manually as eth0:3, the scripts that set these up should either not configure my interface or configure my interface but as eth0:33, or configure my interface as eth0:3 and configure the previous eth0:3 alias as either eth0:4 (bumping everything up one, which would be the simplest way) or as eth0:33 (which could ptoentially lead to a confusing mess if this happened a lot).
The only reason I can see this causing problems is for tracking traffic by interface, or monitoring interfaces, etc. Otherwise, the address assigned would still be the same, and I would think nothing else would break. I have no idea how this affects arp entries or routing, etc.
Perhaps the safe thing to do is to provide behavior that rejects a manually configured interface that conflicts with a previously autoconfigured alias, but this behavior could be overridden (or optionally not employed) in which case the virtual service aliases all get bumped up. The behavior should be consistent though, e.g. if I manually configure eth0:1 and then eth0:11, the first interface alias defined should be eth0:12, etc.
I don't believe the auto-install tool we've been discussing is intended to be useful for this sort of thing, but it would be good to have a generic way of snapshotting config data (especailly for more dynamic, or potentially dynamic data) for later reference.
Rich
Reply to: