NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/os/linux/20221

Internet Message Format | 1992-12-13 | 3.5 KB

Path: sparky!uunet!gatech!pitt.edu!drycas.club.cc.cmu.edu!ghod
From: [e-mail]
Newsgroups: comp.os.linux
Subject: Re: [Q] What's wrong with xdm ?
Message-ID: <[e-mail]>
Date: 13 Dec 92 22:05:49 GMT
References: <[e-mail]>
Organization: Carnegie Mellon Computer Club
Lines: 58

In article <[e-mail]>, [e-mail] writes:
> Hello,
> just the following question:
> What's wrong with XDM ? After calling it a login prompt appears, but
> XDM doesn't react on any key or mouse movement (the virtual screen
> seems to work). It's standard SLS installation (0.98p5), so I ask
> You, how to configure XDM ...
> Thanx,
>        Thomas Mueller ([e-mail])

I've noticed some strangeness with xdm as well, although I've gotten it up and
running. Sort of. The first problem, that of not responding to the keyboard,
seems to have to do with xdm remaining bound to whatever virtual console it's
started from. I started it up by logging in as root, then just typing xdm.
When it comes up, it's still attached to console /dev/tty1 (or a1 as it appears
in the ps listing) and /dev/tty1 and xdm seem to be fighting for posession
of the keyboard. The cure for this is so start it in non-daemon mode, as in
"xdm -nodaemon". xdm then responds correctly to the keyboard, and all seems
well. BUT, there's a second problem which stems from the new shadow password
stuff. xdm (my copy anyway, which is on the current SLS distribution 98pl5)
doesn't know to read the shadow password file apparently, as it refuses to
allow any logins whatsoever. You can force it to work by editing /etc/passwd
and nulling out the password entry for a selected account. In other words,
get rid of the * from the password field and leave the field empty. xdm
will then permit that user to log in without a password on the console,
although the regular login program will still read only from /etc/shadow when
it verifies passwords. The xlock program suffers from the same problem: once
you lock the screen, you can't unlock it again unless you clear the password
field in /etc/passwd. For giggles, I tried copying the encrypted password
from /etc/shadow to /etc/passwd to see if that would fix things temporarily,
but it didn't work. BTW, none of this nonsense affected my mouse: it still
worked correctly under all circumstances, not that that helped any. :)

My question is, are there new versions of xdm and xlock out there that use
the shadow password system correctly?

Also, while I'm at it, I received a couple of replies to my question about
my mouse flaking out whenever I used kermit with my internal modem. The
problem is that my mouse is on /dev/ttys1 amd kermit defaults to /dev/ttys1
when it starts up. I then tries to initialize /dev/ttys1 as a modem device
and hoses the mouse. The cure (sort of) is to make sure to put a 'set line'
command in your .kermrc file so that it defaults to the correct serial line,
as in 'set line /dev/ttys0'. I'm using kermit with X now, and all seems well.

Lastly, I'd be much obliged if someone could point me in the direction of some
decent documentation for lilo. The README in SLS 98pl5 is wonderfully cryptic
and does little except tell you that there's better documentation available
in LaTeX format, which doesn't do squat for me since I haven't the room to
install LaTeX, nor do I want to install it anyway.

-Bill Paul

Assistant System Administrator
New Windsor Associates L.P.

[e-mail]   -or-  [e-mail]