More Hacks for the User Environment in BSD - Hack 10: Maintain Your Environment on Multiple Systems (Page 2 of 4 )
It’s especially important to use a separate location if you usecvsupto keep your system up-to-date. Otherwise, your next update will notice your modifiedsrcand happily replace those missing original source files. But don’t worry; it won’t touch your new
/usr/share/skel.
Of course, sometimes this is a very useful trick in itself. If you ever mess up a file located somewhere within/usr/src, a quickcvsup will put everything back the way it was. See “Automate Updates” [Hack #80] for details on automatingcvsup.
The Other BSDs
The preceding discussion is based on FreeBSD, but it also applies to NetBSD and OpenBSD systems, save for a few tiny differences outlined here.
NetBSD.NetBSD administrators will find the skeleton home directory in /etc/skel. Specify a different location by passing the-koption touseradd.
OpenBSD.OpenBSD systems store the skeleton home directory in /etc/skel. Specify a different skeleton directory location by passing the-dotdiroption toadduser.
See Also
The sign of a true Unix guru is the ability to perform a task quickly when confronted with an unfamiliar shell, keyboard, terminal, window manager, or operating system.
A large part of using Unix systems effectively involves configuring a comfortable environment using familiar tools available from the Unix shell prompt. It’s much easier to perform a task quickly when all of the shortcuts your fingers have learned work on the first try.
Even something as simple as setting up your prompt the way you like it can steal significant time from your productivity if you need to do it on several hosts. If you’re going to spend significant time in a Unix shell, it’s worth getting organized. A bit of onetime effort will reward you later, every time you sit down at the keyboard.
Enter unison
unisonis a tool for maintaining synchronized copies of directories. I’ve used it to maintain a central repository of all of my dot files, shell scripts, signatures file, SpamAssassin configuration—basically any file I’d like to have available, regardless of which host I happen to be logged into.
You can installunisonfrom the NetBSD pkgsrc collection:
# cd /usr/pkgsrc/net/unison
# make install clean
FreeBSD and OpenBSD ports also include net/unison.
Even better, this utility is available for most Unix and Windows platforms. See the mainunisonweb site for details.
Using unison
Whenever I configure a new Unix host or get a shell on another system, I installunison. Then, I create a directory to receive the files I’ve stored in the /usr/work/sync directory at host.example.com. I call the local directory ~/sync.
To synchronize those two directories:
% unison ~/sync ssh://username@host.example.com://usr/ work/sync
p = /home/david/.unison; bn = .unison
Contacting server...
p = /home/david/sync; bn = sync
username@host.example.com's password:
Aftersshprompts for a password or pass phrase, theunisonexchange begins. On a first-time synchronization,unison will ask only one question: whether you wish to copy the remote directory to the local host.
Looking for changes
Warning: No archive files were found for these roots. This can happen
either because this is the first time you have synchronized these roots,
or because you have upgraded Unison to a new version with a different
archive format.
Update detection may take a while on this run if the replicas are large.
unison will assume that the last synchronized state of both replicas was completely empty. This means that any files that are different will be reported as conflicts, and any files that exist only on one replica will be judged as new and propagated to the other replica. If the two replicas are identical, thenunison will report no changes:
Press return to continue.
Waiting for changes from server
Reconciling changes
local host.example.com
<---- dir / [f]
Proceed with propagating updates? [] y
Propagating updates
UNISON started propagating changes at 11:44:39 on 02 Feb 2004
[BGN] Copying
from //host.example.com//usr/work/sync
to /home/david/sync
bin
dotfiles
spamassassin
bin/randomsig2.pl
bin/sy
bin/testaspam
dotfiles/.c
dotfiles/.cshrc
dotfiles/.login
dotfiles/.muttrc
dotfiles/.profile
dotfiles/.tcshrc
dotfiles/.xinitrc
spamassassin/user_prefs
[...]
[END] Copying
UNISON finished propagating changes at 11:44:41 on 02 Feb 2004
Saving synchronizer state
Synchronization complete
I now have a populated ~/sync directory on the new system, organized into subdirectories. Each subdirectory contains the files I find useful to carry around with my various accounts on multiple Unix machines.
Notice also that although my preferred shell istcsh, I maintain a .cshrc and .profile for use on systems wheretcshis not available.
Automating the Process
I’ve automated the process with a simple shell script calledsy in my bin directory.syruns theunisoncommand to synchronize the ~/sync directory.
#!/bin/sh
unison ~/sync ssh://username@host. example.com://usr/work/ sync
Creating Portable Files
Making good use of the sync directory requires some discipline. It’s one thing to be able to copy files easily; it’s another thing to be able to use them without modification on several hosts.
To take advantage of this hack, when you copy the dot files to your home directory and notice that something doesn’t work exactly the way you like it to, make sure you don’t simply change it for the local host.
Instead, update the dot files so that they use conditional if statements, shell backticks (e.g.,`hostname`), or environment variables, to make them behave correctly on the new hosts without breaking them on the systems where you already use them. Then, copy the dot file back into your ~/sync directory and run thesyscript.unisonwill prompt for a password or passphrase for thesshconnection, then ask you to verify that you want to update your files back to the main server.
The first few times you do this, you may introduce breakage when the new dot file is used on another host. With a bit of practice you’ll learn how to avoid that. The most important trick is to test. Open a shell to the host and update the dot file, and then open a second shell to the host without closing the first one. If you broke anything that affects your ability to log in, you can fix it with the first shell and test again.
There’s no need to resynchronize every other host you use for each file you change. I generally wait until I’m logged onto a given host and need a newer script, or need to make some additional changes to the local copy of the dot file. Then I synchronize, make the changes in the sync directory, test them locally, and resync them back to the main host.
Using this approach means that I don’t have to reinvent the wheel every time I want to perform a procedure I’ve done before. Any process useful enough to be done a couple of times becomes a script in my toolkit, and is conveniently available anywhere I have a shell. Withunison, I don’t have to keep track of which files were modified on which end of the connection since my last update.
Keep in mind that using a tool likeunison can provide a mechanism for someone to attempt to feed updates into your central file repository. When you log into a host and run the update, be conscious of whetherunisonasks for approval to send back changes. If you don’t remember making those changes, you might be helping an attacker feed a Trojan horse into your .login, which could end up giving the attacker access to every system you use that script on.unisonwill ask for confirmation for every file change. Presumably, your central host is secure, but you need to be particularly conscious when permitting file uploads.
See Also
Next: Hack 11: Use an Interactive Shell >>
More Administration Articles
More By O'Reilly Media
|
 This article is excerpted from chapter one of the book BSD Hacks, written by Dru Lavigne (O'Reilly, 2005; ISBN: 0596006799). Check it out today at your favorite bookstore. Buy this book now.
|
|
