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.
Letís take a quick tour of the default files:
% ls -l /usr/share/skel
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
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/
If your system already contains many users, youíll probably prefer to write a script. Here is an example:
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
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
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 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:
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
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
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:
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.
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
That Makefile controls the installation of those files:
# more /usr/src/share/skel/Makefile
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
FILES1= dot.cshrc dot.login dot.xinitrc
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
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.
blog comments powered by Disqus