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

More Hacks for the User Environment in BSD

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.

TABLE OF CONTENTS:
  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
SEARCH DEV SHED

TOOLS YOU CAN USE

advertisement

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.



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

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort
   

SITE ADMINISTRATION ARTICLES

- 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: