On Mon, 2009-01-26 at 21:12 -0800, Erik Nordmark wrote: > 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?
Our punchin client and server are an example. > Doesn't such software need to be able to undo the ifconfig that it did > in order to tare it down? Yes, but it doesn't get to do that when someone types "reboot" or the system crashes. In that case, its temporary configuration goes away for free. If its configuration were to be persistent, someone would need to know to clean up on the way back up. > 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. Right. > 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. Panics and manually triggered reboots are two of my concerns. > > 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. I wonder if SMF can provide some infrastructure to help with this. For example, I wonder if one could activate some sort of SMF profile in which all changes made to all or a subset of SMF services are not persisted... -Seb
