Hack 9 Customize User Configurations


figs/expert.gif figs/hack9.gif

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.

1.10.1 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 word dot. However, when the files are copied into a user's home directory, the dots turn into literal dots (.). Also, the files in this directory are owned by root, but when a new user is created, the copied over files will change ownership as they are placed in that user's home directory.

1.10.1.1 dot.cshrc

Let's examine each default file, starting with dot.cshrc. ( [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.

1.10.1.2 dot.login

The next file, dot.login, is used only by the csh and tcsh shells. 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 the fortune program. If you chose to install the games distribution when you installed FreeBSD, your fortune appears just before the MOTD whenever you login. Have you ever noticed that you don't receive a fortune when you use su? That's because .login is only read when you log in, and the default invocation of su does 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 an xterm. Basically, the only time you get a real login shell is when you type in your username and password at a login prompt.

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 the csh shell, 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.

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

1.10.1.4 dot.mail_aliases and dot.mailrc

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

1.10.1.5 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 for bash users.

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 the bash shell, 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, most bash users tend to make their modifications to ~/.bash_profile.

1.10.1.6 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 read man 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 the r* commands: rsh, rcp, or rlogin. 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 by ssh and scp, 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.

1.10.1.7 dot.shrc

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

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

1.10.2.1 dot.logout

We've already seen that ~/.login is read when a user logs into the csh or tcsh shells. 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

1.10.2.2 dot.xinitrc

I also find it very useful to create a custom dot.xinitrc. By default, users receive the extremely lightweight twm window 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 types startx and their ~/.xinitrc file kicks in. For example, this is a popular line to add:

# more dot.xinitrc  exec xterm & exec startkde

This starts an xterm in the background. Notice the & at the end of its line this is to ensure that once xterm 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 an xterm, 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 use bash, vim, screen, procmail, or fetchmail, 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.

1.10.3 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=1 is simply a list of files to install. Take a look at MODE1; it tells the chmod command what permissions to set on those files.

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

Move down to the install section. 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.xinitrc

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.

It's especially important to use a separate location if you use cvsup to keep your system up-to-date. Otherwise, your next update will notice your modified src and 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 quick cvsup will put everything back the way it was. See [Hack #80] for details on automating cvsup.

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

1.10.4.1 NetBSD

NetBSD administrators will find the skeleton home directory in /etc/skel. Specify a different location by passing the -k option to useradd.

1.10.4.2 OpenBSD

OpenBSD systems store the skeleton home directory in /etc/skel. Specify a different skeleton directory location by passing the -dotdir option to adduser.

1.10.5 See Also

  • man adduser

  • The manpages returned by apropos user



BSD Hacks
BSD Hacks
ISBN: 0596006799
EAN: 2147483647
Year: 2006
Pages: 160
Authors: Lavigne

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net