Re: /etc in git?

Adam Hunt [off-list ref] writes:

Do you have any more details by chance?  Does it work?  Does it work
well?  How does one do it?

I personally feel it is a horrible and stupid thing to do, if by
"version control /etc" you mean to have /.git which controls
/etc/hosts and stuff in place.  It would work (git does not
refuse to run as root).  But being a *source* control system, we
deliberately refuse to store the full permission bits, so if
your /etc/shadow is mode 0600 while /etc/hosts is mode 0644, you
have to make sure they stay that way after checking things out.

You are much better off to keep /usr/src/rootstuff/.git (and
working tree files are /usr/src/rootstuff/etc/hosts and
friends), have a build procedure (read: Makefile) there, and
version control that source directory.  I usually have 'install'
and 'diff' target in that Makefile, so that I can do this:

	$ cd /usr/src/rootstuff
        $ make diff ;# to see if somebody edited any targets by hand
	$ edit etc/hosts
	$ git diff ;# to see the source change
        $ make diff ;# to see the change I am going to install
        $ su
        # make install; exit
        $ git commit -a -m 'Add a new host.'

Being able to run "diff" before actually doing it is very handy
and useful safety/sanity measure.

Obviously, /usr/src/rootstuff/ should be mode 0770 or stricter,
owned by the operator group; it would contain some sensitive
information.

Junio C Hamano wrote:

Adam Hunt [off-list ref] writes:

quoted

Do you have any more details by chance?  Does it work?  Does it work
well?  How does one do it?

I personally feel it is a horrible and stupid thing to do, if by
"version control /etc" you mean to have /.git which controls
/etc/hosts and stuff in place.  It would work (git does not
refuse to run as root).  But being a *source* control system, we
deliberately refuse to store the full permission bits, so if
your /etc/shadow is mode 0600 while /etc/hosts is mode 0644, you
have to make sure they stay that way after checking things out.

This is, admittedly, a major problem.

If you instead take the viewpoint that the /etc/.git/ repository is for
tracking textual diffs and not for serving as a backup, it should be an
acceptable tool however.  In my opinion, to be truly useful, it would
need to also automatically commit changes during package installation,
upgrade, and removal.  (To be incredibly useful, it would 3-way merge
changes.  That, I think, is a fantasy at this time.)

You are much better off to keep /usr/src/rootstuff/.git (and
working tree files are /usr/src/rootstuff/etc/hosts and
friends), have a build procedure (read: Makefile) there, and
version control that source directory.  I usually have 'install'
and 'diff' target in that Makefile, so that I can do this:

	$ cd /usr/src/rootstuff
        $ make diff ;# to see if somebody edited any targets by hand
	$ edit etc/hosts
	$ git diff ;# to see the source change
        $ make diff ;# to see the change I am going to install
        $ su
        # make install; exit
        $ git commit -a -m 'Add a new host.'

Being able to run "diff" before actually doing it is very handy
and useful safety/sanity measure.

Obviously, /usr/src/rootstuff/ should be mode 0770 or stricter,
owned by the operator group; it would contain some sensitive
information.

If you're doing this, especially if you're doing this on multiple
machines, creating a package is probably a worthwhile thing to
contemplate as well.

On Wed, Jan 18, 2006 at 09:05:01PM -0800, Junio C Hamano wrote:

You are much better off to keep /usr/src/rootstuff/.git (and
working tree files are /usr/src/rootstuff/etc/hosts and
friends), have a build procedure (read: Makefile) there, and
version control that source directory.  I usually have 'install'
and 'diff' target in that Makefile, so that I can do this:

	A while back I wrote CVSMan, which tries to be berkeley sup(8)
with CVS as the transport.  I think git would work well here, but I
haven't yet generalized the code to support non-CVS SCMs (I certainly
have wanted to, it's the only thing I use CVS for anymore).
	Like GIT, CVS doesn't do perms well.  However, CVSMan handles
the perms via .cvsperms files.

Joel

-- 

"What does it say about a society's priorities when the time you
 spend in meetings on Monday is greater than the total number of
 hours you spent sleeping over the weekend?"
	- Nat Friedman

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

On Wed, 18 Jan 2006, Junio C Hamano wrote:

Adam Hunt [off-list ref] writes:

quoted

Do you have any more details by chance?  Does it work?  Does it work
well?  How does one do it?

I personally feel it is a horrible and stupid thing to do, if by
"version control /etc" you mean to have /.git which controls
/etc/hosts and stuff in place.  It would work (git does not
refuse to run as root).  But being a *source* control system, we
deliberately refuse to store the full permission bits, so if
your /etc/shadow is mode 0600 while /etc/hosts is mode 0644, you
have to make sure they stay that way after checking things out.

At some point, people considered setting up an object type that would have 
all of the bits. That is, if you want a directory to come out literally 
the same as it went in, uid/gid/sticky-bit and all, you'd do something 
special to make this happen.

I think you could do some nifty stuff where you have git take care of 
/etc, and make all your changes to clones of the repository, push them, 
and check them out. I bet you could even have three-way merge on package 
installs this way; install the package into a fake root that has the /etc 
generated by the install of the previous version of the package (i.e., 
without your changes), commit that head, then merge that head into your 
master branch etc (in a non-real working tree, of course), check over the 
result, commit, push to the real repository, and check out. For that 
matter, you could probably generate the "package added replacing previous 
package" commit without using a working tree, directly from the package.

(Sure, it's currently set up for source control only, but the original 
theory was general content, and it should be good at producing exactly the 
right directory structure if it had a type to represent exact stuff like 
that)

	-Daniel
*This .sig left intentionally blank*