Re: [Gnu-arch-users] arch with 'special files'

[Josh England]

On Mon, 2005-03-28 at 20:09 -0600, John Arbash Meinel wrote:

> Probably you don't want to use arch, because you really don't want to do
> revision control. Unless you are trying to patch/merge the changes, you
> should look into more of a backup system (like Amanda.)

No, I don't want backups...I really do want revision control.  Here's
the scenario:  I've got software (http://onesis.org) that enables a
single root filesystem to be used without any change on many
functionally different machines (diskless clusters in my case).
Consider the (very real) situation where there are many admins all
making changes to this one root filesystem.  I'm want documented
changes, the ability to incorporate only particular changesets, and the
ability to roll back to any previous revision.  I want revision control.

I've looked at several SCM systems (including Subversion and Bitkeeper),
and I think Arch sounds very close to the solution I'm looking for.  The
problem is I need to retain permissions on all files, and be able to
archive special files (mainly device files).

> I think the problem is how do you do a diff of a FIFO with another FIFO?
> Is it just presence/absence?
>
> You *really* don't want arch to consider /dev/hda as a file that it
> would diff against some other /dev/hda.
> Maybe for block items you would want to just record what their block
> numbers. If you can come up with a reasonable definition, maybe it would
> make sense.

You're right.  These kinds of files would need special handling, but it
wouldn't be very difficult.  The code snippet you referred to could be
extended to handle 'special' files as well.

I'm not familiar with all the internals of arch, but all of this is
conceivable and should be fairly straight-forward since tar is the
file-store.  Tar is fully capable of storing device files and retaining
permissions.  The 'special' file diff for a FIFO would just check
existence.  A 'special' file diff on a char/block device would just look
at the major/minor numbers of the device.  Sockets would still be
ignored.

Changesets of 'special' files would simply invoke 'mkfifo' or 'mknod' as
appropriate instead of 'patch' (or whatever).  This is, of course, very
UNIX-centric, but all the code could be #ifdef'd out for other
platforms.

> But really that would be easier to do by having a script that you run
> which takes inventory of whatever you want, and then puts that into a
> text file. Then you use arch to manage the text file.

Certainly do-able, but not ideal.  Like I said, I want to stuff an
entire distribution into an archive.  I don't just want to synchronize
machines...rsync is suitable for that.  I want to allow any remote
machine (administrator) to 'check out' a fully configured OS image, make
any changes to it (that could be committed back to a main archive), and
then boot their cluster into that image (that part I've got covered).
They could make changesets for their own particular needs and they could
commit any fixes/updates back into the main archive.

I've already got several 'repositories' of pre-configured OS images
(RedHat, Fedora, Suse, Debian, Gentoo, etc.).  However, anytime I copy
an image to a remote machine, it is effectively gone.  I never see any
updates to it or any fixes to the configuration.  I want to be able to
roll those fixes back in to a main archive and share them with all the
other machines that use that image.

> Arch also doesn't maintain owner/group. Again because that doesn't make
> sense in standard revctl. Because if you put your source somewhere, I
> download it, it shouldn't have you as the owner, it should have me.
> Otherwise I might not even be able to read it.

Yes, but retaining permissions would be necessary in my case.  Again,
this is something that tar does well.  A simple flag could tell the tar
back-end to retain permissions on the archive.  Of course only a
privileged user (ie: root) could ever check out an archive, but that is
fine.

Revision control doesn't apply only to source code anymore.  I've found
several instances of people doing exactly what I'm looking for by
hacking all kinds of scripts around a CVS repository.  That sounds far
to gruesome to me.  I'd like a clean, fully revision-controlled, linux
root filesystem.  Conceptually, I think this doesn't sound too hard.  Of
course the devil is in the details.  What do you think?

-JE