gdm

Dagmar d'Surreal dagmar.wants at nospam.com
Wed Jun 18 01:22:52 PDT 2003


On Tue, 2003-06-17 at 23:41, Michael A. Peters wrote:
> On Tue, 2003-06-17 at 17:35, Dagmar d'Surreal wrote:
> 
> > 
> > First off I want to mention for those in the peanut gallery that this
> > has zero impact on probably 99% of the installations out there, since
> > not all that many places are using full thin-clients on their desktops.
> 
> Ok. Said.

I wasn't being pedantic, I just wanted to be sure that newbie lurkers
wouldn't get the idea that this remote GDM problem might somehow affect
them and their home PC running Linux.

> > Secondly, if you accidentally tell X to restart pretty much the same
> > thing will happen.
> 
> I have never seen a gui admin took where it's possible to accidentally
> restart X. However - if you make the display manager an init script, now
> every gui admin tool that lets you start/stop/restart init scripts
> serves that capacity (effectively)
> 
> >   The same thing will also happen if you accidentally
> > tell the machine to reboot.  Worse will happen if you accidentally tell
> > the machine to change to runlevel 3 because the poor thin-client users
> > won't be able to log back in and will wander around the office like
> > zombies looking for support staff to eat until things are made better.
> 
> Reboot is on a totally different panel of every gui admin tool I've seen
> for UNIX. Not mixed in with the services.
> 
> Switching to run level 3 - that exists as a possible mistake wether or
> not xdm is an init script. That makes it irrelevent - that is going to
> exist as an issue of any tool that allows you to switch the current
> runlevel.

You're making architecture decisions resulting from assumptions based on
the UI design of an GUI administration tool.  Nuff said.
 
> > It is a fool's game to try to protect the system from the
> > administrator.
> 
> Then why do alias rm -i to rm ?

You might... I don't.  That having been said, many do it because of past
mistakes where they've deleted say, /.  By my reckoning those are about 
25% typos and 75% people who shouldn't have been screwing around doing
inessential things while logged in as root.

> >   The system is supposed to do what the administrator asks
> > without trying to contradict or second-guess them.  The administrator
> > for his part is supposed to be competent and not prone to such poor
> > motor control that they mis-click and destroy things using a GUI.  If
> > you want sassback from your systems, run Windows.
> 
> You could apply that identical argument to the case for having gdm start
> from an init script.

Using a script to perform some quick sanity checks and do things
differently if they fail IS the result of applying that logic.  Init
will not start anything else if GDM fails entering runlevel 4/5.  It is
up to the system architect to ensure that whatever init is told to do
will execute gracefully in all but the most extreme of circumstances.

> A system administrator should be competent enough when meddling with the
> X11 configuration file that he or she shouldn't need to run it as an
> init script to "protect themselves from a fury of respawns"

Once again, it's about being sure GDM can start, not about being sure
XFree86 can start.  I erred the first time (late posting) but I
definitely corrected and clarified my point.  _GDM_ handles issues where
XFree86 won't start properly.  The init _script_ is to handle instances
where it can be predicted in advance that GDM isn't going to start (test
-x failure, config file gone missing, etc).  All it really takes is for
something like an unexpected powerfail or brutalized NFS mount to have
blown away parts of /usr, or someone to have upgraded the wrong thing. 
A _script_ for runlevel 4 can call XDM as a fallback or take other steps
and life can *maybe* go on without immediate operator intervention or
having to shell in from elsewhere to fish things out of lost+found.

I'm going to skip your other two emails because you're arguing the wrong
cause, but I will point out that USB mice in the way hotplugd and some
system configurations handle them are only an _apparent_ exception.  You
can forget to plug in USB mice and provided the system loaded up the
input, hid, and mousedev modules, /dev/input/mice will not return an
error and X can not tell there's anything wrong.  If you're using a PS/2
mouse, /dev/psaux will definitely emit an error if there's nothing
plugged in.  I just got a new motherboard and have recently been popping
from place to place with it using other people's mice and keyboards and
finally settled on changing the core pointer to USB and force-loading
those modules in all cases so I wouldn't have to keep changing the
configs so I'm _very_ sure of this.

> editing that file should be done in run level 3 where you can start
> XFree86 independent of your display manager and see that it is properly
> set.

In which case you're not going to be doing people logged in remotely any
favors by having X downed and your argument about haphazard GUI use
becomes moot.

> > Allow me to introduce you to a concept apropos to critical production
> > services called a "maintenance window".  If there's a risk the admin can
> > crash the main X server and shut down everyone's desktop in the office,
> > then the admins are simply not supposed to be screwing around with that
> > equipment during working hours, and instead _only_ during a pre-declared
> > time period when the entire office knows that all bets are off,
> 
> Exactly!
> But an admin DOES need to ability to shut a service down or restart a
> service at any given point in time. Thus - to apply your concept, start
> gdm from the init script - admins should NEVER need to use a tool that
> switches runlevel during normal work hours - whereas they do need to be
> able to use tools that stop/start/restart services during normal work
> hours.

And this has what to do with failing to catch that GDM can't properly
start?

> [quote]
> 
> > 
> > Probably less often than someone with parkinson's does trying to restart
> > services with a GUI, but considering that when it _does_ happen (for
> > reasons like sticking a USB mouse in when XFree86 is expecting a PS/2
> > mouse, which will tank it) you wind up with a madly cycling XFree86 or a
> > missing mouse and/or keyboard, 
> 
> which is why modifications require testing XFree86 from run level 3.
> And again - I'm not sure that would affect gdm. I'll try tonight -
> unplug my mouse and boot and see what happens.

If you're in a runlevel 3 that bears resemblance to other unices, you
shouldn't have GDM running.  In any case, modifications and testing
aren't to be taking place in the problem time you cited--when remote
users are logged in through GDM.

> > it's worth taking that extra moment to
> > make sure it'll behave properly.  More to the point, anything someone's
> > doing devel work on (which I think LFS-based machines would be included
> > in by default) is at risk of shared library breakage which could keep
> > gdm from running at all.
> 
> That's a possibility - it's less likely to affect me as I have an
> automated system to check dependencies when upgrading software, but some
> people have a disdain for rpm and rpm isn't part of LFS.
> 
> It seems, though, that a timout of failed attempts is already built into
> respawn because when I was using xdm (before gdm) I first set up with
> the path incorrect - very quickly I got a message that it was respawning
> too quickly - and it stopped respawning. So the respawn loop issue may
> not even be existing with current version of init.

Yank out libcrypto or something else that GDM links to and try it, as in
fatally break GDM.  (I mention libcrypto because I know the 0.9.6 to
0.9.7 change caught a lot of people who were actually deleting obsolete
libraries off guard)

> > Not "someone", me.  If you have in your config file a mouse device
> > specified as CorePointer and it doesn't exist when XFree86 starts, you
> > can be very sure that XFree86 will complain about it and exit.  You may
> > only assign one CorePointer device in the config for 4.3.x, although you
> > may merrily have mutliple devices sending signals to it, the CorePointer
> > designated pointing device _must_ be there unless you've pre-configured
> > XFree86 not to need a pointer at all.
> > 
> > As to the business about running GDM on a headless server... put down
> > the crack pipe and step away from the keyboard.  GDM does not care
> > whether or not there is a mouse or keyboard present.  XFree86 is what
> > depends on those, and yes, while it can merrily operate without them, it
> > has to be specially configured in advance to not be bothered by the lack
> > of them. 
> 
> I'll find that out tonight when I have the ability to make my system
> unbootable for awhile.
> 
> I suspect if there is an issue - there won't be, because I believe a
> sane check is already in place within init to prevent such loops.

Init has rudimentary functions for detecting loops, however, its
"response" is just to "stop doing that".  This is not what I would
consider to be a particularly flexible or useful behaviour, especially
if you didn't already start sshd or some hidden agettys so an admin can
try to fix things.  There is no downside to starting GDM through a
script, dude, _certainly_ no ways to "accidentally" interrupt them
unless your system is tragically misconfigured, and plenty of reasons
_for_ invoking shell scripts through init.

-- 
The email address above is just as phony as it looks, and for obvious reasons.
Instant messaging contact nfo: AIM: evilDagmar  Jabber: evilDagmar at jabber.org

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-dev' in the subject header of the message



More information about the blfs-dev mailing list