From: michael.auria@philips.com
Date: Thu Mar 27 2003 - 00:12:49 EST
Not sure if I already sent this ...
Looks like the issue of the bizarre login behavior is the method the account
was created. I assume if the account was created w/useradd or admintool then
the script that produces the account would be OK. However the script is
piping echo commands into
ed to insert passwd & shadow entries.
2 things:
The fact that ed was used on the files was observed, but is this really the
root cause (I'm thinking that there's still an issue w/dtlogin) ? While
unorthodox, it seems that inserting the appropriate lines into the
passwd/shadow files should be OK
(updating NIS afterwards). Why does dtlogin authenticate a login name that
was entered with a space prior to the name ? Maybe I'm being paranoid but I'm
not crazy about inconsistencies involving password authentication (potential
security hole).
Going forward, I'll hopefully get engineering to use useradd instead of ed in
their account creation script. But it's the accounts that are out in the
field that I'm worried about. Was able to userdel the account away but when I
try to useradd it back
in, I get a message about it being in use. What's up w/that ?
Will definately summarize the solution ...
Michael H.
Auria
800-232-2123 / option 3
Senior Technical Support
Engineer
fax: 408-965-2974
Philips Radiology Oncology Systems (formerly RTP) email:
pros.support@philips.com
Have you registered at the Customer Connection yet?
http://apps1.medical.philips.com
Countless, unseen details are often the only difference between mediocre and
magnificent ...
To: "Harrington, David B.
(Contractor) (DSCR)" <David.Harrington@dla.mil>
sunmanager@sunmanagers.org
cc:
Subject: RE: bizarre
behavior in Login Manager (Welcome to `hostname`)](Document
Michael Auria link: Michael Auria)
03/24/03 08:00 AM Classification:
Unclassified
No David, it's not you; it's me. My apologies to the list ...
We sell turnkey systems, the "default" user account is p3rtp. The application
runs in CDE. For the past few years, they have been running Solaris 2.5.1.
The newer units we've been shipping are running Solaris 8. We are hearing
about this from some of
these Solaris 8 machines (usually Blade 2000's).
The bizarre behavior is seen as follows:
Occasionally, a user will call in complaining that they logged in and got into
an xterm rather than CDE. And sometimes when they type, the see ascii
garbage. If they can type normally, typing exit returns them to the Welcome
Screen (dtlogin I beleive),
they use the Options / Sesions menu to select CDE and they're working as
normal. Sounds like occasionaly, they are getting dumped into Open Windows
however sometimes typing is screwed up (tried stty sane but no go).
Found that if I type a <space> before the login name of p3rtp, the login
session would change to Open Windows. I understand that this is "normal" when
" p3rtp" isn't found in the passwd file (does the same w/" p3" but not "p").
Now in Solaris 2.5.1, the
password is entered and the system says bad password but it seems in Solaris
8, the login is authenticated and the user is logged into the selected session
(Open Windows due to the space) presumably w/no home directory or login files
(may explain ascii
garbage when typing).
In other words, in 2.5.1, it seems that when a <space> is inserted prior to
the login name, Open Windows is selected but the login isn't authenticated
(this is a good thing) But in Sol 8, the space triggers Open Windows (unknown
user?) *but* then
authenticates the login and dumps the user into a foreign Open Windows
environment.
2 questions. One, this appears to be a bug in dtlogin; has anyone heard of it
? Two, I think I can disable Open Windows with the info below but I'd like
to get the root cause fixed (authenticating a login name with a space in front
of it).:
"The OpenWindows Desktop can be disable by creating an empty
"/etc/dt/config/C/Xresources.d/Xresources.ow" file"
(quote from some Sun doc)
I hope I haven't rambled here but seems like I was faulty for not being clear
the 1'st time around <insert sheepish grin here> ...
Michael H.
Auria
800-232-2123 / option 3
Senior Technical Support
Engineer
fax: 408-965-2974
Philips Radiology Oncology Systems (formerly RTP) email:
pros.support@philips.com
Have you registered at the Customer Connection yet?
http://apps1.medical.philips.com
Countless, unseen details are often the only difference between mediocre and
magnificent ...
To: Michael
Auria/MLS/MS/PHILIPS@AMEC
sunmanagers@sunmanagers.o
rg
cc:
Subject: RE: bizarre
behavior in Login Manager (Welcome to `hostname`)]
"Harrington, David B.
(Contractor) (DSCR)" Classification:
<David.Harrington@dla.mi
l>
03/24/03 05:02 AM
Michael;
It may be me, but I am not sure I know what your problem is. Is your problem
what's in your subject line? A little more info might be helpful. Can you log
in? Are you in a windows screen, or an ASCII screen? Or can you not log in?
I'd guess that, for some reason, the system is unable to read one of several
files found in /etc (e.g. /etc/hosts, /etc/nodename). Or if it can, then
there's no data there.
-----Original Message-----
From: michael.auria@philips.com [mailto:michael.auria@philips.com]
Sent: Monday, March 24, 2003 02:12
To: sunmanagers@sunmanagers.org
Subject: bizarre behavior in Login Manager (Welcome to `hostname`)]
I have seen this on "plain jane" stand-alone servers (not NIS login
client) in both Solaris 2.5.1 & Solaris (thinking it may be a dtlogin
issue). I've looked at available patches and sunmanagers archives but
it's not there or I missed it.
In any event, I'm gonna cry uncle on this one and give one of my fellow
managers the chance to embarass me (it's usually the dumb things that
bite the hardest).
Anyone out there game ? Hit me w/it, I'm ready :-) ...
mha
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:26:04 EDT