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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to