More Hacks for the User Environment in BSD

Hack 9: Customize User Configurations

Now that you know how to set up a useful environment for yourself, it’s time to share the wealth.

It’s very easy for a system administrator to ensure that each newly created user starts out with the same configuration files. For example, every user can receive the same customized prompt, shell variables, or hotkeys.

Whenever you create a new user, several default (and hidden, or dot, files) are copied into the new user’s home directory. In FreeBSD, the source of these files is /usr/share/skel/. Any customizations you make to these files will be seen by all subsequently created users. Do note that you’ll have to manually copy over any modified files to existing users.

It’s useful to understand these files, as they apply to every user you create. Depending upon your needs, you’ll probably end up removing some of the defaults, customizing others, and even adding a few of your own.

Default Files

Let’s take a quick tour of the default files:

  % ls -l /usr/share/skel
  total 24
  drwxr-xr-x  2 root wheel 512 Jul 28 16:09 ./
  drwxr-xr-x 27 root wheel 512 Jul 28 16:06 ../
  -rw-r--r--  1 root wheel 921 Jul 28 16:09 dot.cshrc
  -rw-r--r--  1 root wheel 248 Jul 28 16:09 dot.login
  -rw-r--r--  1 root wheel 158 Jul 28 16:09 dot.login_conf
  -rw-------  1 root wheel 371 Jul 28 16:09 dot.mail_aliases
  -rw-r--r--  1 root wheel 331 Jul 28 16:09 dot.mailrc
  -rw-r--r--  1 root wheel 797 Jul 28 16:09 dot.profile
  -rw-------  1 root wheel 276 Jul 28 16:09 dot.rhosts
  -rw-r--r--  1 root wheel 975 Jul 28 16:09 dot.shrc

Note that each starts with the worddot. However, when the files are copied into a user’s home directory, thedots turn into literal dots (.). Also, the files in this directory are owned byroot, but when a new user is created, the copied over files will change ownership as they are placed in that user’s home directory.

dot.cshrc.Let’s examine each default file, starting with dot.cshrc. (“Useful tcsh Shell Configuration File Options” [Hack #2] introduced several .cshrc

hacks.) If you’d like new users to receive your customizations, simply replace /usr/share/skel/dot.cshrc with your hacked version of .cshrc. Don’t forget to rename the file as you copy it:

# cp /root/.cshrc /usr/share/skel/dot. cshrc

Here, I overwrote the default dot.cshrc by copying over the superuser’s customized version of .cshrc. Although you could edit /usr/share/skel/dot.cshrc directly, you may find it more convenient to have a customized copy stored elsewhere.

All isn’t lost if you already have existing users whom you’d like to receive this file. First, find out what users already exist and have home directories. This is a quick way to do so:

  # ls /usr/home
  dru     test

Since this system has only two existing users, it’s an easy matter to copy over my customized .cshrc. I’m also a lazy typist, so I use~instead of typing out/usr/home. Also note that I have to remember to manually change ownership:

  # cp /root/.cshrc ~dru/
  # chown dru ~dru/.cshrc
  # cp /root/.cshrc ~test/
  # chown test ~test/.cshrc

If your system already contains many users, you’ll probably prefer to write a script. Here is an example:

  #!/usr/bin/perl -w
  # copydotfiles.pl
  #    - copy default files to user directories
  #    - change ownership of those files
  # You may wish to change these constants for your system:
  use constant HOMEDIR => '/usr/home';
  use constant SKELDIR => '/usr/share/skel';
  use constant PREFIX => 'dot';
  use strict;
  use File::Copy;
  use File::Spec::Functions;
  die "Usage: $0 <files> <to> <copy>\n" unless @ARGV;
  for my $user ( get_users() )
  {
      for my $dotfile (@ARGV)
      {
        my $source = catfile( SKELDIR(), PREFIX() . $dotfile );
        my $dest = catfile( $user->{homedir}, $dotfile );
        if (-e $dest)
        {
           warn "Skipping existing dotfile $dest...\n";
           next;
        }
        copy( $source,      $dest )
            or die "Cannot copy $source to $dest: $!\n";
        chown( $user->{uid}, $dest );
     }
  }
  sub get_users
  {
     local *DIRHANDLE;
     opendir( DIRHANDLE, HOMEDIR() )
         or die "Cannot open home directory: $!\n";
     my @users;
     while (my $directory = readdir( DIRHANDLE ))
     {
         next if $directory =~ /^\./;
         my $path = File::Spec->catdir( HOMEDIR(), $directory );
         my $uid = getpwnam( $directory );
         next unless -d $path;
         next unless $uid;
         push @users, { homedir => $path, uid => $uid };
     }
     return @users;
  }

This script first examines all of the users with home directories, returning a list of those directories and the user IDs. It loops through that list, copying each dot file you provided on the command line to that user’s home directory and changing the ownership to the user.

If you run it as:

  # copydotfiles.pl .cshrc

all users will receive a new .cshrc file, unless one already exists.

dot.login.The next file, dot.login, is used only by thecshandtcshshells. If your users don’t plan on using these shells, you can safely remove this file from /usr/share/skel. If your users do use those shells, consider whether there are any commands you would like to run when users log in. Note that this file is read after .cshrc.

By default, the only uncommented line in this file is:

  % grep -v '#' /usr/share/skel/dot.login
  [ -x /usr/games/fortune ] && /usr/games/fortune freebsd-tips

Here, I used the reverse filter switch -v to the grep search utility to look for all the lines that do not begin with the # comment symbol.

The resulting line tells the shell to run thefortuneprogram. If you chose to install the games distribution when you installed FreeBSD, yourfortuneappears just before theMOTD whenever you login. Have you ever noticed that you don’t receive a fortune when you usesu? That’s because .login is only read when you log in, and the default invocation ofsudoes not actually log you in.

Instead, it opens what is known as a nonlogin shell. You also get one of those every time you open anxterm. Basically, the only time you get a real login shell is when you type in your username and password at aloginprompt.

Herein lies the difference between .cshrc and .login. Place what you would like to happen only when you log in into .login, and place what you would like to happen whenever you use thecshshell, even if it isn’t a login shell, into .cshrc. If you don’t see the need for a difference, you don’t need /usr/share/skel/ dot.login.

dot.login_conf.Reading the default contents of dot.login_conf will give you an idea of its purpose and where to go for additional information:

  % more /usr/share/skel/dot.login_conf 
  # $FreeBSD: src/share/skel/dot.login_conf,v 1.3 2001/06/10 17:08:53 ache Exp $
  #
  # see login.conf(5)
  #
  #me:\
  #        :charset=iso-8859-1:\ 
  #        :lang=de_DE.ISO8859-1:

Note that this file is commented by default, but shows the syntax a user can use to create a customized  .login.conf. Usually such settings are set in the globally administrated /etc/login.conf file, and individual users can override only some of those settings. If your users don’t have a need or the know-how to configure those settings, you can safely remove this file from /usr/share/skel.

dot.mail_aliases and dot.mailrc.The next two files work hand in hand and customize the behavior ofman mail. Since it is quite rare to find users who still rely on the originalmail program, you can safely remove those files.

dot.profile.The dot.profile file is read by the Bourne,bash, and Korn shells. It is the only file read when a user logs into a Bourne shell, the first file read when a user logs into the Korn shell, and is optional forbashusers.

If your users don’t use the Bourne or Korn shells, there’s not much sense populating their home directories with this file. Depending upon your slant, you may wish to keep this file in order to place path statements and environment variables for use with Bourne shell scripts. However, most users tend to place those directly into the script itself to allow for portability.

If your users wish to use thebashshell, which isn’t installed by default, keep in mind that .profile allows a user to override the settings found in the global /etc/profile file. You may find it easier to make your edits to the global file and then remove  /usr/share/skel/dot.profile. More sophisticated users can always create their own ~/.profile. However, mostbash users tend to make their modifications to ~/.bash_profile.

dot.rhosts.Did you happen to notice in the earlier long listing that this file has different permissions from most of the other files? If you readman rhosts, you’ll see that this file is ignored if it is writable by any user other than the owner of the file.

So, when is this file used? It’s used when a user types one of ther*commands:rsh,rcp, orrlogin. I won’t show you how to set up this file or use those commands, as they were designed for use back in the days when networks were considered trusted. They’ve pretty well been replaced bysshandscp, which provide a much safer way to log into remote systems and to transfer files. For this reason, I always remove /usr/share/skel/dot.rhosts from my systems.

dot.shrc.The last default file is dot.shrc. As you may have guessed, it is the rcfile for sh, the Bourne shell. Again, if your users don’t log into that shell, they won’t miss this file.

Missing (but Useful) Dot Files

Now that we’ve had the opportunity to look at the default files, it’s time to consider any useful missing files.

dot.logout.We’ve already seen that ~/.login is read when a user logs into thecshortcshshells. Not surprisingly, ~/.logout is read when a user logs out of their login shell. This is an excellent place to put commands you would like to execute as a user logs out. It could be something as simple as:

  # more dot.logout
  # this line clears your screen when you logout
  clear
  # add your own commands or scripts, one line at a time,
  # which you would like to execute
  # whenever you logout and leave your terminal

This dot.logout will clear the user’s terminal, making it much neater for the next person who logs in. Notice that I commented this file, so the user is aware of its use. When creating your own dot files, use lots of comments. If you intend for your users to customize their own dot files, use comments that explain the syntax they can use when they do their modifications.

dot.logout can run any command or script that suits a user’s needs. Here are some ideas to get your imagination rolling:

• A script that backs up the user’s home directory
  
• A script that shows how much time the user spent online
  
• A script that displays other statistics, such as available disk space

dot.xinitrc.I also find it very useful to create a custom dot.xinitrc. By default, users receive the extremely lightweighttwmwindow manager. Since I usually install KDE, this line ensures that each user will receive that window manager instead:

  # more dot.xinitrc
  exec startkde

You can also specify which programs you would like to launch when a user typesstartxand their ~/.xinitrc file kicks in. For example, this is a popular line to add:

  # more dot.xinitrc
  exec xterm &
  exec startkde

This starts anxtermin the background. Notice the&at the end of its line—this is to ensure that oncexterm loads, it doesn’t interfere with any other programs that are still loading. When you’re creating your own dot.xinitrc, you can start any program you like. However, start your window manager last. Start your other programs, one line at a time, putting an&at the end of each line. The only line that does not have an&will be the very last line, the one that loads your window manager.

Since I prefer to start my browser instead of anxterm, here is my customized dot.xinitrc:

  #to start another program when you "startx", type:
  #exec path_to_program &
  #before these lines 
  exec /usr/X11R6/bin/mozilla &
  exec startkde

There are dozens of possibilities for customized dot files. Take stock of your own systems, and ask yourself: “What programs do my users use?” For example, if your users usebash,vim,screen,procmail, orfetchmail, why not start them off with a customized configuration file that contains comments on how to add their own customizations and URLs of where to go for further ideas? A little homework and creativity on your part can help your users get the most out of the utilities they use on a daily basis.

Editing /usr/src/share/skel/Makefile

Let’s end this hack by examining where the default dot files in /usr/share/skel came from in the first place. You’ll find the answer here:

  % ls /usr/src/share/skel
  ./         dot.login         dot.profile
  ../        dot.login_conf    dot.rhosts 
  Makefile   dot.mail_aliases  dot.shrc 
  dot.cshrc  dot.mailrc

That Makefile controls the installation of those files:

  # more /usr/src/share/skel/Makefile
  #        @(#)Makefile     8.1 (Berkeley) 6/8/93
  # $FreeBSD: src/share/skel/Makefile,v 1.8 2002/07/29 09:40:13 ru Exp $
  FILES1= dot.cshrc dot.login dot.login_conf dot.mailrc dot.profile dot.shrc
  FILES2=        dot.mail_aliases dot.rhosts
  MODE1=        0644
  MODE2=        0600
  NOOBJ=        noobj
  all clean cleandir depend lint tags:
  install:
         ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m ${MODE1} ${FILES1} \  
             ${DESTDIR}${BINDIR}/skel 
         ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m ${MODE2} ${FILES2} \
             ${DESTDIR}${BINDIR}/skel
  .include <bsd.prog.mk>

Even if you’ve never read a Makefile before, you’ll find it’s not too hard to figure out what’s going on if you already know which results to expect. In this Makefile,FILES=1is simply a list of files to install. Take a look atMODE1; it tells thechmod command what permissions to set on those files.

Similarly,FILES=2is another list of files. Those two files had different permissions, which were defined byMODE2.

Move down to theinstallsection. Don’t worry so much about the syntax; rather, notice the pattern. The first set of files are installed and their mode is applied. Then the second set of files are installed with their mode.

It’s an easy matter to customize this file to reflect the dot files you’d like to see installed. In this example, I only want to install my custom versions of dot.cshrc, dot.login, and dot.xinitrc. Since they all require the first mode, I’ll remove any references to the second set of files:

  # cd /usr/src/share/skel
  # cp Makefile Makefile.orig
  # vi Makefile
  #        @(#)Makefile      8.1 (Berkeley) 6/8/93
  # my customized dot files to be installed into /usr/share/skel

  FILES1= dot.cshrc dot.login dot.xinitrc 
  MODE1=       0644
  NOOBJ=       noobj
  all clean cleandir depend lint tags: 
  install:
         ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m ${MODE1} ${FILES1} \
            ${DESTDIR}${BINDIR}/skel
  .include <bsd.prog.mk>

Now let’s try a test run. I’ll replace the default dot files found in /usr/src/share/skel with my customized versions. I’ll then remove the contents of /usr/ share/skel and see what happens when I run my customized Makefile:

  # cd /usr/src/share/skel
  # rm dot.*
  # cp ~/mystuff/dot.* .
  # rm /usr/share/skel/*
  # ls /usr/share/skel
  # make install
  install -o root -g wheel -m 0644 dot.cshrc dot.login dot.xinitrc
     /usr/share/skel
  # ls /usr/share/skel
  dot.cshrc     dot.login   dot.xinitr

I find it very handy to keep a copy of my customized Makefile and dot files in a separate directory, in this case ~/mystuff. This ensures they are backed up. It’s easy for me to grab those files whenever I want to customize a particular system.