Sams Teach Yourself Samba in 24 Hours		ContentsIndex
Hour 10: Server-Side Automation		Previous HourNext Hour
Sections in this Chapter: What Is Server-Side Automation? %d preexec and postexec Scripts Summary %U and %u, %G and %g Q&A %L, %m, and the include Parameters New Terms		Previous SectionNext Section

preexec and postexec Scripts

preexec and postexec
root preexec and root postexec

Four parameters enable you to specify commands to be executed on the server when a client connects or disconnects to a service:

• preexec



• postexec



• root preexec



• root postexec

preexec and postexec

First, look at preexec and postexec parameters. Both parameters take a series of commands or a script name that is executed on the server using the uid of %u. If you remember from Hour 5, %u is the username of the current service. I can better explain exactly when the script executes by using output from the net use command on a Windows box:

C:\users\jerry>net use s: \\bilbo\src
The command was completed successfully.

The preexec command executes between the time that the net use command runs and the time that Windows reports that The command was completed successfully. The same is true for postexec commands. The Windows client sends the disconnect request (net use s: /d). Samba then executes the postexec command and tells the Windows machine that the service was disconnected:

C:\users\jerry>net use s: /d
The command was completed successfully.

What kinds of things can you do with these preexec and postexec commands? Here is a practical example. More often than once, I have had a user call to report that his UNIX shell account didn't seem to be working correctly. After a few questions, it became clear that the user had accessed his home directory from a PC and deleted several files that didn't seem important. A friend of mine jokingly refers these to as "Those pesky dot files!" By now, you can probably imagine which files the user deleted. Here is an example that will help alleviate some of the help desk calls for this particular problem:

[homes]
      preexec = /usr/local/bin/fix_dot_files.sh %H

The script itself is very simple.

#!/bin/sh

SKELDIR=/usr/local/etc/skel
EXPORT SKELDIR
home=$1

if [ ! -f $home/.login ]; then
   cp -p $SKELDIR/.login $home
fi

if [ ! -f $home/.logout ]; then
   cp -p $SKELDIR/.logout $home
fi

if [ ! -f $home/.profile ]; then
   cp -p $SKELDIR/.profile $home
fi

if [ ! -f $home/.cahrc ]; then

   cp -p $SKELDIR/.cshrc $home
fi

This tells Samba to run the fix_dot_files.sh shell script when a user connects to her home directory. This particular script will copy default versions of "those pesky dot files!" such as .cshrc, .profile, .login, and .logout.

This next example might be a little silly and could get to be annoying for the user. The preexec command sends a copy of the ~/todo file to the user on connection using a WinPopup message. It would probably be better to wrap this command in a script that first checks for the existence of the file:

[homes]
     preexec = cat %H/todo | smbclient -M %m

The postexec parameter is similar to the preexec parameter, except that the value executes when the user closes a connection to the service. Here's an example that removes all files in the user's ~/tmp/ directory.

[homes]
      postexec = /bin/rm -r %H/tmp/*

In this way, a user can store all the temporary files needed during a session in his home directory, thus slightly increasing security in an environment where many people use a machine, such as a student computer lab. I'll leave it up to you whether it is a good idea to delete these files automatically on your server.

root preexec and root postexec

The only difference between the root preexec and root postexec parameters and the normal preexec and postexec parameters is that the former ones specify commands that run as root on the server. This can be very helpful for things such as creating directories, setting ownership of files, logging connections to a central file such as /var/adm/wtmpx, or mounting and unmounting file devices such as CD-ROMs or floppy disks.

One of my responsibilities at my current place of employment is to set up, update, and maintain several student-accessible Windows 9x/NT labs. We decided to build the labs as self-sufficient as possible so that we could keep service disruptions to a minimum and localize SMB traffic. All students are issued UNIX accounts that the lab server obtains information about via NIS+ tables. All students have home directory space reserved for their UNIX accounts. The home directory that the students use for the lab, however, is separate from their UNIX home space and local to the lab's server.

Rather than bothering to create a home directory for each user on the lab server at the time of account creation, we chose to create it the first time the user logged into a machine in the lab. Here's how it worked:

[homes]
     comment = PC Lab home directories
      root preexec = /usr/local/samba/bin/buildhome %U %G
     path = /export/home/%U
     valid user = %S
     create mode = 0600
     directory mode = 0700

You will notice that the path is not the user's home directory from /etc/passwd (that is, %H). The path is set to a local disk, /export/home, and each user has a directory there. Initially the disk is empty.

Now the root preexec script comes into play. The script checks for the existence of the directory name /export/home/username and creates it if it doesn't exist. Here is the source for a simple buildhome script:

#!/bin/sh
umask 077
user=$1
group=$2
 
# Does the user's home directory exist ( export/home/$user )?
if [ ! -d /export/home/$user ]; then
   mkdir /export/home/$user
   chown $user /export/home/$user
   chgrp $group /export/home/$user
fi

Here's another fun example of something you can do with postexec scripts. At work, I have access to an older NCD WinCenter server. If you're unfamiliar with the Cytrix WinFrame multiuser version of Windows NT, it enables users to access an NT desktop remotely much in the same way that XDM enables users to network X terminals. Figure 10.1 shows a WinCenter 2.0 desktop side by side with other X applications running on a Solaris 2.6 machine.

Figure 10.1
NCD WinCenter Windows NT desktop displayed on a Sun Sparc 10 running Solaris 2.6.

I needed a method to access the SCSI CD-ROM on my Sun workstation from the WinCenter session, so I set up Samba locally to share the CD-ROM. Here is the smb.conf service entry:

[cdrom]
        comment = 12X CD-Rom
        path = /cdrom/cdrom0
        root postexec = /usr/bin/eject cd
        read only = yes
        public = yes

The root preexec is not strictly necessary because I am logged into the console, but it will basically make no difference.

Now I can insert a CD-ROM (which will be mounted by the Solaris volume manager daemon, vold) and execute

net use f: \\mymachine\cdrom

in the WinCenter session to make the CD-ROM available. When I disconnect from the CD-ROM

net use f: /d

the CD-ROM ejects automatically.

Sams Teach Yourself Samba in 24 Hours		ContentsIndex
Hour 10: Server-Side Automation		Previous HourNext Hour
Sections in this Chapter: What Is Server-Side Automation? %d preexec and postexec Scripts Summary %U and %u, %G and %g Q&A %L, %m, and the include Parameters New Terms		Previous SectionNext Section

© Copyright Macmillan USA. All rights reserved.