Previous Table of Contents Next


Joe User

If your operating system doesn’t provide user templates, you really should create a Joe User. (In fact, you might have to create several for different departments.) You create his login, his group associations, and his home directory, and you populate his home directory with the various configuration files he might need. For example, different groups of UNIX users might need certain startup files, including but not limited to .xdefaults, .xinitrc, .pinerc, and so on. Similarly, some Windows applications also need user-specific files for terminal emulation settings, Lotus 1-2-3 settings, and so on.

You can copy Joe every time you need to create a new user. Copy his home directory contents to the new user’s home directory, and you can rest assured that the new user has everything she needs to get her job done. Think of this as making a boilerplate document in your word processor for a letter you send out every week or so—all you need to do is copy the document, change a few specifics, and you’ve saved yourself a good deal of time and energy.

User-Level Login Scripts

Every server has the capability to run login scripts for all users. These login scripts perform common tasks for all users. Here are a few examples:

  Show a message of the day
  Set environment variables needed by application programs
  Update workstation software
  Synchronize workstation time to the network
  Set up dumb terminal environments (in the case of UNIX)

You should avoid user-specific login scripts as much as possible, because it’s time consuming to configure every workstation one at a time. Instead, do as much as you possibly can in the system login script and the group-oriented login scripts.

Organizational/Group-Level Login Scripts

System-wide login scripts include /etc/profile in UNIX and the system login script in NetWare 3.x. These allow administrators to have certain things happen for everyone in the system, which is neat. Of course, you might want certain other things to happen on a departmental level—not on a system-wide basis.

However, until the advent of NDS, administrators haven’t had the ability to write a script for users on a departmental basis. This, of course, increases the number of scripts to keep track of, although it also does separate and organize your scripts pretty nicely.

So, are departmental or group-level scripts a blessing or a curse? Well, it depends on whether you need them. If everybody at your company uses the same applications and requires the exact same settings, system-level scripts are your best bet. However, if certain departments in your organization need different settings from others, group-level scripts are almost a necessity.

Tricky Scripts

This is all good and well for NDS users, but what about those without NDS? Fret not—there are tricks that allow you to specify group-level operations from your system login script.


Windows NT’s logon scripts are usually .BAT or .CMD files—which, of course, are regular old batch files.

For example, under Windows NT, for each user in your Finance department, a workaround to enable group-level logon scripts would be to specify each user’s logon script as FINANCE.BAT, which will run all the commands needed for the Finance department.

But what about users who really do need their own stuff? If certain users really do need their own login scripts (and you should think long and hard about this, because it’s much harder to maintain), you can have a line such as the following as the last line of FINANCE.BAT:

if exist %USERNAME%.bat %USERNAME%.bat

This will run a user-oriented script if such a file exists in the login directory.

In UNIX, if you use the standard ksh or sh shell, you can perform a group test in the /etc/profile script and then execute a particular set of instructions if a person turns out to be in that group:

groups | grep -q -w finance && {
  echo “You’re in the Finance group, no party for you!”
  cat /finance/message-of-the-day
  PARTY=”false”
}

    groups | grep -q -w network && {
        echo “Hello network person, party on!”
        cat /network/message-of-the-day
        PARTY=”true”
    }

The potential gotcha behind group-level scripts is that some single users may be in multiple groups. For example, let’s consider a user in the previous example who’s both in the Finance group and the Network group. She would end up with a PARTY variable of “TRUE”. Is this what you want? If it isn’t, you’ll need to change this so that the Network group is tested for first.

Oh, all right. If you insist on running NetWare 3.x, you can use SYSCON to edit the system login script to perform group-specific tasks as well. Just go to Supervisor Options|System login script and do something like this:

if member of “Finance” then begin
 write “Hi, Finance Person! Parties prohibited!”
 display f:\public\finance\message.txt
 dos set PARTY=”false”
end


Don’t get overly excited about the ability to affect large numbers of users at once. When treating mass quantities, a slip of your electronic knife has the potential of making a lot of people very unhappy all at once.

You should always pilot-test as far away from spectators as possible. If you have a test server, you should use it; in any event, you should use a test group and a test user when testing out a new script or a new way of doing something.



Previous Table of Contents Next