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
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.
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.
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
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.
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://email@example.com://usr/ work/sync
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
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.
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.
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.
blog comments powered by Disqus