Novell Home

Managing Login Scripts

Novell Cool Solutions: Trench
By Tom Hogevoll

Digg This - Slashdot This

Posted: 13 Mar 2001
 

Tom Hogevoll thogevoll@aarp.org says: After seeing the login script maintenance tool prompted me to relate what I do to help manage login scripts.

At my company's HQ site we have many slightly different login scripts unique to each container, but most of each script is exactly the same so we used profile objects located in a convienient place in the tree as holders of login scripts and then we call them like sub-routines using the include command in the scripts. Some profile scripts even call others in the same way.

We have nested these sub-scripts as many as four deep with no problem. If I need to affect the same change to all login scripts I just edit one that is called by all.

The only problem and its minor is that some of these scripts cannot be changed very easily during the morning or afternoon because someone somewhere is logging in and running part of the script making it impossible to update the script. I just make changes after CoB.

The basic script that each container has is very clean and easy to read and understand and each has an include to call a profile script that actually does most of the work. To make this profile easier to manage it inturn calls other profile scripts.

If a part of a script needs to be disabled we just comment out the include line where we need to cut it out or go into the sub-script and disable something there to affect everyone.

More from Paul Segal:

Expanding on Toms' thoughts what I did was place the master LoginScript in a root level replicated OU, which is where we tend to keep most of our ZEN apps various catalogs etc.

I was pretty much a rank beginner at Login Scripts at the time and was caught out by that little gotchya that Tom noted, twice. The one about the login script being held open by people logging in. This happens especially when you have over looked something and Users wind up with an error in the login script. Sometimes they don't close the box and the script is held open, for a long time! Of course it is possible to find them by looking for open DS files.

The best solution is test all the possibilities but sometimes when you're new at a site you don't know them all.

In the absence of being able to edit open DS stream files (?) which is what stores the Profile Login Script what I wound up doing was to create an empty text file called by an Include statement at the end my master LoginScript. I called it ScrptFix.

I put a ScrptFix on all servers, SYS:SYSTEM${BS}Public. Both the LoginScript and ScrptFix internally document what it's for, how and when to use it. Basically it can be used to undo or modify anything done by the LoginScript, MAP DEL this, MAP that, maybe add a new hex IP range urgently etc. It also politely asks for these changes to be removed when the situation is resolved.

Having a ScrptFix on each server on each site is a little cumbersome however in most circumstances it is necessary to edit only one of them, the one users are attaching to.

We are moving to DS 8.5 very soon so this might remove the need for ScrptFix and at least one of the catalogs.


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell