Sebastien Roy wrote:
> While it could be considered, I think it would be too risky a change
> even for a Minor release, and maybe even for a Major release. I don't
> think it would be acceptable to require 3rd party software to be
> modified to undo unwanted persistent configuration.
Do we have examples of 3rd party software which invokes ifconfig to
change the IP configuration?
Doesn't such software need to be able to undo the ifconfig that it did
in order to tare it down?
The only difference is what happens on a reboot. For a normal reboot it
is possible to have that 3rd party software clean up, but they might not
do that today.
I just think we should not optimize the system for handling kernel
panics, so let's make sure that isn't the only real-world concern out there.
> On a related note, if ipadm is the preferred way to configure a system,
> what is the programmatic model for IP configuration from shell scripts
> in this new world order? Surely, knowing that there exists software
> that dynamically configures IP interfaces on the fly with no need (nor
> want) for persistent configuration (think VPN server), then a
> persistent-only ipadm by itself won't be very friendly.
Se above; it needs to be able to undo to restore things on a system
which never reboots.
> If we want such software to migrate to ipadm and not use ifconfig for
> perpetuity, then what is the story for such software? One obvious
> answer is that ipadm needs to support temporary configuration. There
> may be other answers.
I'm far from convinced that temporary is the answer; persistent&missing
might be a much more tractable approach. With that approach you avoid
worrying about persistent objects that directly or indirectly depend on
temporary object. You can have a persistent object (the IP address
1.2.3.4 on tun17, which depends on the IP interface "tun17" which
depends on the datalink "tun17", etc) and one or more of its
dependencies might be missing, which means that it doesn't get activated
until those objects appear.
Erik
