Novell Home

Of Login Scripts and Latency

Novell Cool Solutions: Tip
By David Stagg

Digg This - Slashdot This

Posted: 4 Apr 2002
 

David Stagg responded to a reader who was experiencing problems with slow login scripts. It sounded like a common problem with a solution that should be shared.

The Situation:
One of my clients uses a login script at both the root of the tree and in the local containers. However, they have had problems with their WAN on occasion (September 11 being the most notable) when local users could not connect to some of their resources because they could not run the Organization login script.

Local container login scipt:

SET HOME="HOME"
INCLUDE .MY-ORG
IF <HOME>="HOME" THEN
INCLUDE sys:\public\ORGSCRIP.TXT
END

Root login script:

SET NWSRVR="%FILE_SERVER"
SET APPS="%FILE_SERVER"
SET SYSPUB=<APPS>;"\SYS:PUBLIC"
SET APPS=<APPS>;"\VOL1:APPS"
SET DEPT=<DEPT>;"\VOL1:DEPT"

IF MEMBER OF ".THE-GRP.MY-ORG" THEN
SET HOME="%HOME_DIRECTORY" >>7
ELSE
SET HOME="%HOME_DIRECTORY" >>8
END

MAP ROOT N:=%<DEPT>
MAP ROOT H:=%<HOME>
MAP ROOT S:=%<APPS>

MAP INS S1:=%<SYSPUB>

They have been able to get the script to work, but it is taking up to six (6) minutes for it to execute; for the most part this is because the PC is waiting for the script to time-out when it is looking for the login script in the Organization object at the top of the tree "INCLUDE .MY-ORG". Another issue is that they have to use the server's IP address instead of the server name.

The Questions:

  • Is there a timeout feature that could be configured to shorten the amount of time being spent looking for the Organization object? If there is no timeout feature, is there some command available that would do that?
  • Is this the right way of going about this? Is there a different way to approach this problem?
  • Am I assuming correctly that their inability to access the servers using the name is a problem w/DNS? Or could it be something with their SLP configuration?

The Answers:
Any design requires a balance between user functionality and ease of administration. Sometimes the balance is obvious, other times it is not. By placing a "common" login script in the Organization object, Administration is much easier and system-wide changes can be implemented with a single change. This appears to be what was done here. The trade off is user functionality and network performance. In every login that occurs each and every user must walk the Tree to get to the Org Login Script and then process it. Even with Fast WAN links this will cause delays, first by walking the Tree, second by crossing WAN links and third by getting extraneous connections to servers holding copies of the Organization object "MY-ORG". In this scenario, users have server connections across the WAN as well as local. This can impact other processes with additional WAN/Tree walking that is not required.

As a basic design guideline, you should try to have all resources that users access available locally. This includes login scripts and Group Memberships. In the login script you have provided there appears to be a Global Group "THE-GRP" that is being checked by every login attempt. This further delays/complicates the login process since this Group has to be resolved, walked to and checked for membership as well as getting the Organization Login Script.

Use of the Server's IP addresses in login scripts will greatly speed up the normal process as the Resolve Name process is no longer required. Although faster in general, it does complicate Administration as server IP addresses must be known. Server changes also require Login Script updates. I have seen and used this method mostly for NW 5.1 Cluster servers to improve access and avoid some early Cluster problems.

Problems accessing servers without the use of IP addresses will need LAN traces to identify exactly where the problem may be. It could be due to poorly implemented SLP or something else. The trace would allow identification of what Name Resolution process is being attempted and then failing. There are a number of things possible in this space.

In general I would strongly recommend against the use of "Global" login scripts and groups. This would require a redesign of the login and membership testing that appears to have been implemented in this case. By bringing the login script local, as well as Groups, you will improve the User experience although you'll slightly increase the Administration Management processes. This I believe is a better balance than what has been currently implemented.


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

© 2014 Novell