> From: Ian Jackson <[email protected]> > > Why do we want selection-time configuration ? > > It seems to me that this has been much-touted, but isn't actually all > > that useful. > > This is required for "push" network installs and batch workgroup > installs of multiple systems. To support these in general, it's > necessary to configure as much as possible in one session, move the > configuration to a workstation as a piece, and then perform the install > in non-interactive mode, changing only the workstation-individual > parameters such as host name and IP address. The way we install the system > now just is not practical if you are installing 30 systems all the same. > > Ian, I really do think it is necessary. I'm managing 4 debian machines right now (soon to be five). I upgrade my development system (using unstable) weekly, and the other ones whenever a new stable release comes out. For maintaining my production machines, the current way of doing things is very time consuming -- and doesn't scale well when you have multiple machines to upgrade. We really do need a way of doing "fire and forget" installs. When you are upgrading to a new stable release, there are typically dozens of packages to upgrade. Unfortunately, the poor sysadmin has no idea whether any particular package is going to be an easy upgrade, or it's going to break somewhere. For example, when I upgraded inn to 1.5 - it didn't work. Because I was upgrading many packages, I was too busy fighting fires to be able to quickly fix the problem. If we had selection-time configuration, I would have had a bit of a chance to decide that the inn upgrade was too difficult, so I could put it on hold. There are lots of packages that ask really difficult questions during configuration (ie. sendmail, apache). The result is substantial system downtime as the user scrambles to find the proper documentation. My dream dselect-replacement is a web based scheme that would help the user step-by-step through the selection and configuration phase -- with the ability to do multiple machines at a time. At each step of the configuration, the user would be able to see the system configuration and access all of the pertinent documentation via hyperlinks and search engines. Once the upgrade was "designed", the sysadmin could then just launch the installation phase, and everything would just work - 100% guaranteed. I'd like to be able to upgrade a 1000 machine network that was geographically distributed around the world by just "designing an upgrade", and then start it running. Cheers, - Jim
Attachment:
pgp0ViMausa9z.pgp
Description: PGP signature