Weblog entry #11 for lters
See all weblog entries made by lters.
Since I use svn, I added a hidden folder with some standard aliases, customized vimrc, muttrc and etc to it.
Than I setup svn to store and make it all accessable from other servers.
Some of the issues that I am not sure about:
o I don't like svn user/pass stored on all boxes I access. This can be fixed with the --no-auth-cache but than I need to login to it every time I update. o I still need to remember to manually call my svn update to get the updates in. o Some boxes don't have all the same access to the svn services. o And some boxes it would be nice to have the some of the etc stuff sync'd as well.
It would be interesting to hear what you do with your home folder on servers, and how you keep it consistent between a variety of servers/workstations/laptops or whatever.
Comments on this Entry
For users' files? NFS.
For root and system files? Puppet.
Laptops are a non-issue for me at the moment, but one could definitely manage the root and system files with Puppet, and even users' settings, but it's not built for syncing huge file trees. For that, I'd use unison.
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
I guess if you've seen my files then you've have seen this already - but for new people...
The way I handle updates is quite simple via this in ~/.bashrc:
#
# If we don't have checked out copies of our dotfiles then get them,
# if we do then update them.
#
if [ -d ~/.dotfiles/ ]; then
#
# Update once a week from our CVS repository.
#
if [ ! -e ~/.dotfiles/updated.`date +%U` ]; then
rm -f ~/.dotfiles/updated.* 2>/dev/null
touch ~/.dotfiles/updated.`date +%U`
pushd ~/.dotfiles
make update
popd
fi
This makes sure that if I login to a machine and that hasn't been updated in the past week then the command "make update" is executed in the ~/.dotfiles directory.
The Makefile basically runs "hg pull --update" to refresh the files from my remote repository, and then runs ./fixup.sh to create the symlinks from (for example) ~/.bash_profile to ~/.dotfiles/_bash_profile.
In theory this has the same drawback as your current solution does - if you can't access the remote repository from the current host it will fail. However in my case I access my revision control system (mercurial) over plain HTTP. (As these are public checkouts there is not username/password stored as in your case.)
There might be systems I wish to have my files upon which don't allow HTTP access to the outside world, but I've not yet found one.
I think that this manual solution is probably about the best you can do - unless you want to use a cronjob instead..?
As for alternative distribution mechanisms I do have something different at work. Using CFEngine I have a system which will add or remove local users upon all managed machines.
This user-management system also allows per-user files to be copied into place. In my case the file cfmaster:/users/steve.tar is copied to ~steve and untarred. That contains both ~/bin/ and all shell files I care about.
For my home machines I also use CFEngine, but I copy ~/.dotfiles, ~/bin, and ~/.dotfiles-private as described here.
[ Parent | Reply to this comment ]
As said in a comment below, I have too started a Mercurial repository to manage ~/bin and conf files. The only thing I have not done for the moment is automate the copy/update of the files. I have looked at your solution:
- ~/.bashrc is executed at login so it check if an update has been done recently. If not
- it calls make update
- the make update calls fixup.sh
Ok for .bashrc, it automates updates. But why do you need both a Makefile and a shell script? I don't really understand the point to have two files, I think one shell script can done all the job, am I wrong?
For the rest, your method seems good :) and I think I will use if for inspiration...
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
That is basically a historical artifact, it didn't exist previously.
I think I have an alias defined too dotfiles='cd ~/.dotfiles; make update; ./fixup.sh', or similar to allow manual updates if I know I've just committed and pushed..
[ Parent | Reply to this comment ]
System config and stuff: well, I use RCS, in situ, on my boxen. For newly commissioned machines, I have another CVS module: newboxes (I'm really good on this naming lark!) which contains things I find useful:
* configs for exim/apache/nagios/samhain/spamassassin/firewall,
* logrotate stanzas,
* 'useful' scripts
and the things I use a lot and on most newly commissioned machines. A simple check-out, and that's things on the machine, for config'ing, and moving into the right places: I don't always want everything, so it's a manual process: unless I'm building a cluster, in which case I'll whack-up a script to do it for me.
[ Parent | Reply to this comment ]
I too have looked to Steve repository and started my own Mercurial one (I was quite ignorant about SCM, so why not start with this one, after checking pros and cons) for some little projects and for my own bin and conf files.
Using an SCM and in particular a distributed one like Mercurial is quite disturbing at first, but now I've some reflexes :) The only problem is I need a central repository (like a virtual server with Mercurial installed) to have a simple way to access my files. For the moment, I use an ext3 fs on a loop file on an usb stick.
[ Parent | Reply to this comment ]