Student Login Script Processing

Normal Operation

Layout of Accounts All student workstations are configured to process login scripts. The normal login sequence starts by processing the login script property of the profile object referred to by the users profile property. Each account can accommodate only one profile. In the student system this property has been assigned the purpose of indicating the accounts usage status. In most cases this is blank, indicating no profile and no special processing. The next script to be executed is the container login script of the container in which the account exists. Student accounts are placed in twenty-six alphabetic containers corresponding to the leading alphabetic character of the account name. For example, the account asmi3 is in the "a" container, which gives it the DN of: .CN=asmi3.OU=a.OU=user.O=monash This means that our contextless login does not initiate any LDAP network traffic requiring the server to respond, but can directly derive where an account should be from the account name.  The login script for each alphabetic OU has one simple reference to include the login script of one of four profiles within the .OU=user container.

Profile Login Script Each of the four profiles is identical, but each is notionally assigned to the users of a particular shared and home directory server. This allows some flexibility in emergency or maintenance circumstances.  The login script does the essential drive mappings on the basis of the success or failure of mapping the users home directory. This means that the workstation only has to test once if the target server is up or down. If the home directory server is down the drive mappings will connect to any fileserver. Normally this will be on the first fileserver to which the workstation connects. If as expected the home directory maps normally, all drives are mapped to directory map objects.

Directory Maps

The contents of an alphabetic user sub-container consists of the user objects for the accounts that start with that letter, a template for the creation of new accounts, and the directory map objects relevant to those accounts. Four of the directory maps are referred to in the user login script; the other is used as across reference in the account creation process. All directory map objects within a single container normally refer to the same fileserver, but do not have to.  These values can be redirected to another server if the current host server is scheduled for maintenance. The Dir-Home value is used by the account creation process to direct where new account home directories should be created. Part of that process sets the value for the new account home directory property. The login script (as seen in the previous section) refers to the home directory property of the user account logging in, rather that the current value of the directory map, and attempts to map the U:drive accordingly.

Special Profile Processing The special profiles that indicate the account state are stored in the .netadmin.resource.monash container. When a new special profile is created, the root of the tree must be give Read and Compare to all its attributes. Each profile has a corresponding text file stored in the SYS:LOGIN directory of every server in the tree. Profile Text Pro-Suspend excluded.txt Pro-Encumber encumber.txt Pro-Pending pending.txt Pro-Offered offered.txt Pro-Dereg dereg.txt Pro-Special special.txt

When Things Go Wrong

During such an outage the login scripts themselves can become locked out from changes. The workstations trying to execute the login script keep the scripts open while timeouts to resources are in progress.

The directory maps are not subject to such lock outs and can be altered to refer to a resource that is still on-line. This is part of the service continuity plan for just such occasions. Care must be taken to set the new temporary value to not cause undue loading on the alternate resource.

That only leaves the possibility of the %HOME_DIRECTORY property pointing to a server that is down. As the users' home directory is not replicated to another area, there is no useful location that the U: drive can be mapped. To provide for this eventuality, a dummy home directory has been created on the SYS: volume of each of the fileservers in the STUDENT-AU tree. All users have Read and Filescan rights to this directory, but no write rights. It contains a single file stating that the users home directory is currently unavailable. This helps in two ways. Programs that refer blindly to the user's U: drive will resolve to a file not found error quickly, and the user will see the warning file even if they miss the warning message in the login script results that flash past users at login time.

The mapping of the dummy home directory is achieved without changing the login script for the affected containers or the profile login script to which they refer. The remainder of the drive letter assignments are then achieved by mapping to the equivalent directory on the server to which the user is already connected. The test required is immediately after the success or failure of mapping the home directory in the user container profile scripts and done only once.