Home arrow Site Administration arrow Page 2 - More Hacks for the User Environment in BSD

Hack 10: Maintain Your Environment on Multiple Systems - Administration

In this article, the third and last of a series, you'll learn how to customize a BSD environment for other users; maintain your chosen environment on multiple machines; and more. It is excerpted from chapter one of the book BSD Hacks, written by Dru Lavigne (O'Reilly, 2005; ISBN: 0596006799), Copyright © 2005 O'Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O'Reilly Media.

  1. More Hacks for the User Environment in BSD
  2. Hack 10: Maintain Your Environment on Multiple Systems
  3. Hack 11: Use an Interactive Shell
  4. Hack 12: Use Multiple Screens on One Terminal
By: O'Reilly Media
Rating: starstarstarstarstar / 1
December 21, 2006

print this article



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.

See Also

  • man adduser 
  • The manpages returned byapropos user


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
  [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.

  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

  • Theunisonhome page (http://www.cis.upenn.edu/~bcpierce/ unison/)

>>> More Site Administration Articles          >>> More By O'Reilly Media

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Coding: Not Just for Developers
- To Support or Not Support IE?
- Administration: Networking OSX and Win 7
- DotNetNuke Gets Social
- Integrating MailChimp with Joomla: Creating ...
- Integrating MailChimp with Joomla: List Mana...
- Integrating MailChimp with Joomla: Building ...
- Integrating MailChimp with Joomla
- More Top WordPress Plugins for Social Media
- Optimizing Security: SSH Public Key Authenti...
- Patches and Rejects in Software Configuratio...
- Configuring a CVS Server
- Managing Code and Teams for Cross-Platform S...
- Software Configuration Management
- Back Up a Joomla Site with Akeeba Backup

Developer Shed Affiliates


Dev Shed Tutorial Topics: