Previous | Table of Contents | Next |
Joe User
If your operating system doesnt 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 users 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 soall you need to do is copy the document, change a few specifics, and youve saved yourself a good deal of time and energy. |
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:
You should avoid user-specific login scripts as much as possible, because its 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.
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 levelnot on a system-wide basis.
However, until the advent of NDS, administrators havent 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.
This is all good and well for NDS users, but what about those without NDS? Fret notthere are tricks that allow you to specify group-level operations from your system login script.
Windows NTs logon scripts are usually .BAT or .CMD fileswhich, 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 users 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 its 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 Youre 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, lets consider a user in the previous example whos 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 isnt, youll 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
Dont 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 |