SEO

A colleague of mine is connecting to a SunOs 5.9 server from a local SunOs
5.9 SunBlade. (I forget the name for this kind of login/window session;
XDMCP?)

When she leaves the local host unattended, the screensaver comes up.
Eventually it locks the screen.

When she tries to log back in, her password doesn't work. Searching the web
and USENET, I thought maybe the root password would work, but that doesn't
work either.

Any solution? I'm not even sure how to diagnose the problem; all I've found
so far by internet research is that the process probably responsible for
locking the screen is dtsession.

TIA,

S

In article <QG9cd.737$5l3.63@trnddc02>,
"sinister" <sinister@nospam.invalid> wrote:

> A colleague of mine is connecting to a SunOs 5.9 server from a local SunOs
> 5.9 SunBlade. (I forget the name for this kind of login/window session;
> XDMCP?)
>
> When she leaves the local host unattended, the screensaver comes up.
> Eventually it locks the screen.
>
> When she tries to log back in, her password doesn't work. Searching the web
> and USENET, I thought maybe the root password would work, but that doesn't
> work either.
>
> Any solution? I'm not even sure how to diagnose the problem; all I've found
> so far by internet research is that the process probably responsible for
> locking the screen is dtsession.

Is the caps lock key pressed when you enter either password?

Can you telnet or ssh into the box, su to root and kill the screen saver?

--
DeeDee, don't press that button! DeeDee! NO! Dee...

Honestly, I am not sure if its a good idea, but when my session gets locked
up because of multiple instances of the screensaver running, I just pkill my
ttsession remotely and then log in again. Perhaps there are more intelligent
ways to do so without losing your session.

regards, veni


"sinister" <sinister@nospam.invalid> wrote in message
news:QG9cd.737$5l3.63@trnddc02...
> A colleague of mine is connecting to a SunOs 5.9 server from a local SunOs
> 5.9 SunBlade. (I forget the name for this kind of login/window session;
> XDMCP?)
>
> When she leaves the local host unattended, the screensaver comes up.
> Eventually it locks the screen.
>
> When she tries to log back in, her password doesn't work. Searching the
web
> and USENET, I thought maybe the root password would work, but that doesn't
> work either.
>
> Any solution? I'm not even sure how to diagnose the problem; all I've
found
> so far by internet research is that the process probably responsible for
> locking the screen is dtsession.
>
> TIA,
>
> S
>
>

<Michael Vilain <vilain@spamcop.net>> wrote in message
news:vilain-393414.11085616102004@comcast.dca.giganews.com...
> In article <QG9cd.737$5l3.63@trnddc02>,
> "sinister" <sinister@nospam.invalid> wrote:
>
>> A colleague of mine is connecting to a SunOs 5.9 server from a local
>> SunOs
>> 5.9 SunBlade. (I forget the name for this kind of login/window session;
>> XDMCP?)
>>
>> When she leaves the local host unattended, the screensaver comes up.
>> Eventually it locks the screen.
>>
>> When she tries to log back in, her password doesn't work. Searching the
>> web
>> and USENET, I thought maybe the root password would work, but that
>> doesn't
>> work either.
>>
>> Any solution? I'm not even sure how to diagnose the problem; all I've
>> found
>> so far by internet research is that the process probably responsible for
>> locking the screen is dtsession.
>
> Is the caps lock key pressed when you enter either password?

AFAICT, no.

> Can you telnet or ssh into the box, su to root and kill the screen saver?

There's no separate screensaver program; it's dtsession, I think. Last time
I did it by killing Xsun on the local machine; there were too many processes
on the remote machine for me to choose which one to kill, and the user had
(unfortunately) logged on the remote machine using the account of someone
she works with, so it'd be hard to know which to kill.

I want to know how to prevent it from locking in this manner in the future
so I don't have to go in and kill an entire session.

> --
> DeeDee, don't press that button! DeeDee! NO! Dee...
>
>
>

On Sat, 16 Oct 2004 13:50:40 +0000, sinister wrote:

> A colleague of mine is connecting to a SunOs 5.9 server from a local SunOs
> 5.9 SunBlade. (I forget the name for this kind of login/window session;
> XDMCP?)
>
> When she leaves the local host unattended, the screensaver comes up.
> Eventually it locks the screen.
>
> When she tries to log back in, her password doesn't work. Searching the
> web and USENET, I thought maybe the root password would work, but that
> doesn't work either.
>
> Any solution? I'm not even sure how to diagnose the problem; all I've
> found so far by internet research is that the process probably responsible
> for locking the screen is dtsession.

It's probably due to an incorrectly configured /etc/pam.conf.
First, make sure you have all the latest patches in place.
Second, I found I had to put in an explicit dtsession "trap" to account
for just this problem. dtlogin covers the user logging in, but dtsession
covers the screenlock problem. You've configured dtlogin to allow the
user to login, but you haven't configured dtsession, so whatever "other"
does is what transpires as the user tries to unlock the screen.

FWIW, my traps are as follows:
login auth requisite pam_authtok_get.so.1
login auth required pam_unix_auth.so.1
login auth required pam_dial_auth.so.1
login auth sufficient /usr/lib/security/pam_afs.so.1 setenv_password_e
xpires try_first_pass ignore_root
#
# 28-Jul-2004 SEP: Providing explicit dtsession because when screen locks
# I can't unlock it and it seems to be related to dissimilar nis/afs
# passwords.
#
dtsession auth requisite pam_authtok_get.so.1
dtsession auth sufficient /usr/lib/security/pam_afs.so.1 try_first_pass setenv_password_expires ignore_root
dtsession auth sufficient pam_unix_auth.so.1 try_first_pass
#
dtlogin auth requisite pam_authtok_get.so.1
dtlogin auth sufficient /usr/lib/security/pam_afs.so.1 try_first_pass setenv_password_expires ignore_root
dtlogin auth sufficient pam_unix_auth.so.1 try_first_pass
#
su auth requisite pam_authtok_get.so.1
su auth sufficient /usr/lib/security/pam_afs.so.1 setenv_password_expires try_first_pass ignore_root
su auth sufficient pam_unix_auth.so.1 try_first_pass
:


I have at least one other to account for sshd, but that's unrelated to
your problem. I mention it only so you'll set it up in yours iff you
use ssh with PAM.

The last thing to ponder is: Why didn't I just use "other" as a general
trap, like the manual says? Answer: I remember trying to take that
course in the beginning, but OpenSSH didn't really get with PAM until
very recently so I had to break it out of the other. I think it was my
messing with OpenSSH and a general lack of knowledge of PAM[1] that
caused me to do things this way. PAM has dramatically changed in the
last few years, and it is a pain to get PAM, TCP Wrappers[2], and other
things to work with each other.

Regards, Scott

[1] General Google info on PAM usually covers Linux versions, or is
just plain obsolete with respect to Solaris.

[2] TCP Wrappers /etc/hosts.allow and /etc/hosts.deny can behave
differently depending on how the source code was built. OpenSSH
also behaves in its own way, and is not documented anywhere.

"Scott Packard" <scottp@%hash%.usenet.us.com> wrote in message
newsan.2004.10.18.18.10.30.813826@%hash%.usenet. us.com...
> On Sat, 16 Oct 2004 13:50:40 +0000, sinister wrote:

Scott---thanks for your response. It's a little beyond the scope of my
knowledge, but I appreciate the insight and effort.

Cheers.

>> A colleague of mine is connecting to a SunOs 5.9 server from a local
>> SunOs
>> 5.9 SunBlade. (I forget the name for this kind of login/window session;
>> XDMCP?)
>>
>> When she leaves the local host unattended, the screensaver comes up.
>> Eventually it locks the screen.
>>
>> When she tries to log back in, her password doesn't work. Searching the
>> web and USENET, I thought maybe the root password would work, but that
>> doesn't work either.
>>
>> Any solution? I'm not even sure how to diagnose the problem; all I've
>> found so far by internet research is that the process probably
>> responsible
>> for locking the screen is dtsession.
>
> It's probably due to an incorrectly configured /etc/pam.conf.
> First, make sure you have all the latest patches in place.
> Second, I found I had to put in an explicit dtsession "trap" to account
> for just this problem. dtlogin covers the user logging in, but dtsession
> covers the screenlock problem. You've configured dtlogin to allow the
> user to login, but you haven't configured dtsession, so whatever "other"
> does is what transpires as the user tries to unlock the screen.
>
> FWIW, my traps are as follows:
> login auth requisite pam_authtok_get.so.1
> login auth required pam_unix_auth.so.1
> login auth required pam_dial_auth.so.1
> login auth sufficient /usr/lib/security/pam_afs.so.1
> setenv_password_e
> xpires try_first_pass ignore_root
> #
> # 28-Jul-2004 SEP: Providing explicit dtsession because when screen locks
> # I can't unlock it and it seems to be related to dissimilar nis/afs
> # passwords.
> #
> dtsession auth requisite pam_authtok_get.so.1
> dtsession auth sufficient /usr/lib/security/pam_afs.so.1
> try_first_pass setenv_password_expires ignore_root
> dtsession auth sufficient pam_unix_auth.so.1 try_first_pass
> #
> dtlogin auth requisite pam_authtok_get.so.1
> dtlogin auth sufficient /usr/lib/security/pam_afs.so.1
> try_first_pass setenv_password_expires ignore_root
> dtlogin auth sufficient pam_unix_auth.so.1 try_first_pass
> #
> su auth requisite pam_authtok_get.so.1
> su auth sufficient /usr/lib/security/pam_afs.so.1
> setenv_password_expires try_first_pass ignore_root
> su auth sufficient pam_unix_auth.so.1 try_first_pass
> :
>
>
> I have at least one other to account for sshd, but that's unrelated to
> your problem. I mention it only so you'll set it up in yours iff you
> use ssh with PAM.
>
> The last thing to ponder is: Why didn't I just use "other" as a general
> trap, like the manual says? Answer: I remember trying to take that
> course in the beginning, but OpenSSH didn't really get with PAM until
> very recently so I had to break it out of the other. I think it was my
> messing with OpenSSH and a general lack of knowledge of PAM[1] that
> caused me to do things this way. PAM has dramatically changed in the
> last few years, and it is a pain to get PAM, TCP Wrappers[2], and other
> things to work with each other.
>
> Regards, Scott
>
> [1] General Google info on PAM usually covers Linux versions, or is
> just plain obsolete with respect to Solaris.
>
> [2] TCP Wrappers /etc/hosts.allow and /etc/hosts.deny can behave
> differently depending on how the source code was built. OpenSSH
> also behaves in its own way, and is not documented anywhere.