CDE login hangs at startup screen

[Low Han Ming]

Hi,

I've recently include a script in /etc/profile so that it can be execute when user login using telnet.

However, after adding in the line to execute the script, users that exist before the system is connect to the NIS server could login using CDE. Telnet is fine.

For example, before NIS is up I have user A in my system.
After setting up the system as part of a NIS network, I add user B to the NIS server.
User B can do a CDE login without problem and a telnet login will successful run the script.
User A can telnet to the system and run the script, but when doing a CDE login, the login hangs at the CDE login screen.

Any advice is greatly appreciated.

Thanks.


Han Ming

[Carol Garrett]

You need to be very careful about adding anything into /etc/profile, especially calls to other scripts. For example, if you add in a call to another script and someone removes or changes the permission of that script you could easily end up with the situation where nobody can login! be very careful. Ensure things like you check the script exists before you call it, and thats its executable etc.

If you want to only catch telnet connections and not CDE logins then use the who -u command to test if the user logging in is coming from telnet or dtremote. Any CDE login user shows up in who -u as dtremote. Then for CDE logins dont run this script and that should fix it. But more importantly, whats wrong with your script that it stops CDE logins from working ?? Maybe your catching CDE logins as telnet logins and killing them off, thus hanging the CDE login ?

[Alex Glennie]

If it were me I'd let us know if the user(s) is/are able to login with the script removed from /etc/profile : if yes post your script so we can see what its doing ?

also add set -x to your $HOME/.dtprofile, reproduce the problem and then check $HOME/.dt/startlog for clues.

Whats the effect of either running the script from the users $HOME/.profile as opposed to /etc/profile ?

[Stefan Farrelly]

I agree completely with what Carol has said. Be very careful adding stuff to /etc/profile. You shoud be making changes to local user login scripts, not system wide ones, eg. $HOME/.profile or .kshrc or .dtprofile. To make it easier symlink everyones $HOME/.dtprofiles to one in say /usr/local/bin so its easier to maintain. If you go modifying system scripts like /etc/profile how do you know HP wont come along with a patch/replacement for /etc/profile which will overwrite the changes you made ? But HP patches wont overwrite the login scripts in users home directories so thats where you should be making changes.

[Carol Garrett]

Your script is rather large to be called from /etc/profile. Too many things that could go wrong.

If you make your change instead to /etc/skel/.profile then when you create a new user using the useradd command it will automatically copy over the .profile from /etc/skel to the new users home directory. This way you dont have to copy around your customised .profile when adding new users.

[Low Han Ming]

Hi,

Thanks for all the reply.

I've tried to switch the script to .profile just.
Those new users remain fine, and old user (actually it's only the root) that doesn't require the script to be call can do a CDE login as well.
But my problem now is that the old user which was in the system all the while (before NIS is setup) still experience the CDE login problem as the script is called in .profile.

Is that a way to get around this problem.

Thanks again for all the kind suggestion.
I'll bear them in mind especially the /etc/skel/.profile suggestion.

Cheers.


Han Ming

[Stefan Farrelly]

I think you have to add in a test in .profile to see if your user is logging in via CDE or not. Use who -u | grep dtremote. If they are logging in via CDE (dtremote) then dont run your extra script stuff, then they shouldnt hang.

[Alex Glennie]

Yes Stefan is correct ... have a read of $HOME/.dtprofile ... it gives you examples of the test syntax etc etc .... to use.

[Kenneth Platz · Accepted solution]

Low,

I believe the problem centers around the fact that you are inserting "read" statements into a script which is read during CDE startup. If you have configured DTSOURCEPROFILE=true in your $HOME/.dtprofile, then the /etc/profile will be sourced at a time when the user cannot interact with the script, and therefore the script will hang indefinitely while waiting for a user to respond.

If you intend on inserting interactive scripts like this one into your startup sequence, you should be sure to 'protect' them from CDE with the following syntax:

if [ ! "$DT" ] ; then
# insert interactive commands here
:
fi

This also applies to any commands to query or modify the tty settings (such as stty, tset, and so on), since at this point in time the process has no controlling terminal.

[Low Han Ming]

Hi,

Thanks for all the advice.

The real problem in my case is as described by Kenneth that my DTSORUCEPROFILE is set to true for those old accounts. Thus, prevent a successful CDE login.

In addition, I've taken in the other advice as well by using a .profile instead and check with a if
[ ! "$DT" ]

I've benefit from all suggestions!

Thanks again for all the kind help.

Cheers.


Han Ming