On 2019-08-07 at 04:26, Russell Stuart wrote: > On Wed, 2019-08-07 at 09:34 +0200, Marc Haber wrote: > >> I am using Debian for two decades now, and I realized that >> necessity two days ago. > > Ditto - except for me it was a few seconds ago.
In my case, it was when I read this thread last night. (After more like ~1.5 decades of Debian, for what that's worth.) This isn't the first time I've discovered that some aspect of a Debian system would actually need to be cleared and re-generated when that system is cloned, well after the point where it would have been easy for me to address that need. (Fortunately, although I've moved in the direction of cloned Debian systems multiple times in the past, so far all of those have petered out before reaching production. I still want to change that at some point, however.) Cloning isn't the only example of a case where some machine-specific configuration detail may need to be updated, without that being obvious in advance. I've been bitten by attempting to change the name of a computer running off of LVM on mdraid, and discovering that the hostname entered during the original install process when those two things were configured had actually been encoded into the definition of one of the two, such that the machine could no longer automatically find its filesystems at boot until some action to update the hostname in that definition was taken; the original hostname was effectively a critical ID for that filesystem. (I *still* haven't been able to pin down with certainty what action would do that update safely.) Since cloning a machine often involves specifying a new hostname for the clone, I'd expect to encounter the same issue there - although it's probably not all that common to want to clone a machine running from RAID, so if the mdraid is where the hostname is needed, the issue may not tend to come up in that context. I wouldn't be even slightly surprised if there were other examples, as well, somewhere in the package ecosystem. I've begun to wonder whether it might be worth the overhead to set up some type of mechanism to let packages which define such machine-specific IDs A: declare the fact, in a central location which the sysadmin of a machine where that package is installed can easily check, and B: define an automated way of performing the appropriate update / regenerate step in a way which covers all known places where the ID needs to be updated. Maybe a mechanism vaguely similar to /etc/init.d/ | /etc/rc*.d/ ? Say, one directory (name bikeshedding welcome) to contain package-installed scripts which will generate and apply the new GUID (or replace an existing ID with a specified new one in all relevant places, for cases such as the hostname one given above), and another directory to contain symlinks to scripts in the first directory. Then either a flag file to tell the system to run the symlinked scripts (and clear the flag) on the next boot, or just let the presence of any such symlinks be the flag indicating to run that script and remove the symlink at boot time. That way, rather than needing to research to find out what elements of the installed system need to be updated at clone time, the sysadmin could just check the relevant directory, run any scripts whose effects need to be applied pre-clone (if any), create appropriate symlinks for whichever others the sysadmin wants to have run in this case, create the flag file if applicable, shut down, and clone. ...this would be arguably reminiscent of the Sysprep tool on the Windows side of things, although probably all of more general, more flexible, and less heavy-weight. I'm sad at there being any need for such a thing in the Linux world, but as long as there are machine-specific IDs which need to be updated for effective cloning, I'd rather have such a mechanism than need to do all the work (or do the research, and write the necessary automation scripts) myself in every case. I'm not particularly attached to that exact solution; it's just the first one I came up with that seemed as if it could work with sufficient generality. If people think the idea is worth pursuing but that solution is not ideal, I would be more than happy to defer to those with more expertise. -- The Wanderer (will, statistically, probably regret posting this) The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Description: OpenPGP digital signature