On Fri, 9 Mar 2007, Alexandre Magaz Graça wrote:
Helmut Lichtenberg escribió:
On Thu, Mar 08, 2007 at 05:23:17PM +0100, Alexandre Magaz Graça wrote:
Thanks for the advice with svn. I'll try to find out more about it.
Maybe we try it this way, though the Xen solution Chris Fanning proposed
has its own special charme :-)
Some time ago I found an article about using svk to manage /etc like
this. It doesn't put .svn directories around like svn does.
Although slightly going OT, can someone point me to an arcticle or HOWTO
about putting /etc under version control and how to set up the repository
for a whole bunch of servers?
Thanks
Helmut
Well, here is it. Very simple :)
http://www.enricozini.org/2005/tips/etc-under-svk.html
Very simple but moderately risky. Remember that they REALLY MEAN IT
when they say to remove ld.so.cache from version control. Then there
are security issues (see below). If you ever attempt to overwrite this
file or touch it in any significant way on a running system You Will Be
Sorry.
Been there, done that...;-)
I'd actually personally recommend NOT keeping all of /etc under any sort
of version control. Most of it is simply a waste of time -- it will get
rebuilt and upgraded if/when you upgrade the base distribution.
Preserving some of it is actively counterproductive, as it SHOULD get
upgraded when the system is upgraded -- the last thing you want to do is
lock in and overwrite some file that has changed its basic format or has
some nifty new features that you are overwriting out of existence.
Tools like rpm that upgrade objects with configuration files in /etc
have to be very, very careful about this and "do the right thing" and if
you are setting up version control as a form of backup you have to be
just as careful.
Instead, determine the absolute minimum number of files that you
actually need to preserve in order to restore a system to functional on
top of a basic configuration or install, and preserve them only. On
many systems this will be just:
/etc/passwd
/etc/group
/etc/shadow
/etc/ssh/
/etc/hosts
and maybe
/etc/cups/
/etc/X11/xorg.conf
although there you're again running into problems -- if you casually
restore these from version control post upgrade, you risk breaking
things horribly as cups and X11 change as new features are added and old
ones deprecated. On the other hand, if you've sweated to get your
monitor resolution etc set up "just right" you don't want to lose it,
you just don't want to casually overwrite the new config as you may want
to overlay only a single section.
Ultimately, only the sysadmin who runs the LAN and determines the config
can really tell what has been customized and needs to be preserved
period for immediate replacement and what has been customized but should
generally NOT be carelessly tossed back in on top of an upgrade or
reinstall.
Don't forget that if you are trying to set up a truly scalable LAN, you
may well want to preserve even fewer /etc files and use LAN-wide tools
like LDAP or NIS to provide system databases. This reduces your
preserved /etc component in many cases to whatever is needed to turn on
NIS (nsswitch.conf, yp.conf) plus maybe /etc/ssh/.
A final note is that when preserving /etc one has to exercise a certain
amount of caution. The contents of /etc/shadow, for example, are
generally and deliberately 600 root. A version control system, however,
may well take this file and save it as an entry into a 644 database or
file -- they aren't always designed to preserve perms in such a way as
to prevent unauthorized access. A clever user on your system who has
access to the actual version control directory for a given system (which
can be in very different formats for the different version control
mechanisms) MAY be able to just copy it into their own home directory,
check out your /etc/shadow into a private directory, and spend the next
umpty hours running crack on it. Or worse, open /etc/ssh and take your
system's private ssh key. Be sure to set perms on ANY version repo you
set up so that they are at least as conservative as those on the /etc
files they contain, or you might be sorry.
rgb
Cheers,
Alex
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net
--
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:[EMAIL PROTECTED]
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net
