-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At some point hitherto, Paul Lussier hath spake thusly: > >When this happens, often the only way you can fix the > >problem (because of X constantly respawning) is to log in remotely and > >reboot to a runlevel that doesn't use X. Then, to test, you use a > >fairly basic startx, and make incremental changes until you figure out > >what's broken. > > That's a fairly complex and convoluted way of debugging X, especially > if the problems are specific your config files. Why not just use the > built-in failsafe log in, or, with Linux, a virtual terminal?
Well either you didn't read what I wrote (what, Paul not read a post completely?), or you've never experienced what I'm talking about, which I find hard to believe, since I'm pretty sure I've watched you do it. ;-) Periodically, when making changes (like upgrading X, or upgrading your kernel if you're using DRI) you will find that when X starts via your favorite display manager (xdm, gdm, kdm, whatever), it dies as soon as it starts. But it's set to respawn in /etc/inittab, so it goes into a loop that's nearly impossible to break out of, and the console becomes completely useless. The only way to break the cycle is to log in remotely, and change runlevels to one that does not start [xgk]dm. Then, to test to see if it's working, you run startx. Because if it isn't fixed, you end up in the same annoying loop. and AFA the failsafe login goes, if [xgk]dm never gives you a login box, it ain't gonna happen. =8^) > >There are potentially other uses for having different sessions too. > > I don't disagree with that, I just don't see why one needs separate > .xinitrc and .xsession files. Under the above circumstances, you may want to start different programs than those you normally start from your .xsession. I personally don't generally do this, but I have in the past, and someone else might want to. As it happens, on all of my systems here at home, both .xsession and .xinitrc are symlinks to .Xclients. :) > >Well, there's also the .Xauthority file, but well-configured systems deal > >with that automatically, because dealing with X-MIT-MAGIC-COOKIEs is too > >esoteric for most typical computer users (and perhaps even most atypical computer > >users). > > Yeah, I'll agree with that. That crap is too esoteric for *ME*, and > I usually thrive on esoteric :) Well, unfortunately, a lot of systems aren't terribly well configured. Most don't bother with security at all, or do an xhost + in their .xsession file. But if you find that security is important at your site, or you have annoying neighbors who keep popping Xeyes up full-screen on your display [ =8^) ] then you'd better learn how to use X-MIT-MAGIC-COOKIEs. FWIW, Red Hat does this the Right Way(TM) by default. I believe Debian does too, but I'm not sure about any of the other Linux distros, and commercial Unix vendors are notoriously lax in this department (though with the focus on security being what it has been lately, this too may have changed in more recent vendor offerings). A quick test shows I can't display a client on my HP-UX 10.20 display without doing something about it. SSH deals PROPERLY with xauth for you, so you don't need to know much about X-MIT-MAGIC-COOKIEs (that name so amuses me). :) Which is another great reason to use it. Of course, if your home directory is NFS mounted, and people have root access to their machines, then by default anyone who understands how X-MIT-MAGIC-COOKIE authentication works can get access to your display pretty trivially. In most cases this is more of an annoyance than anything else (like the xeyes example), but if you're working on sensitive information (such as say, a business proposal, or employee reviews, or for those who work in government shops, top secret documents), then it becomes trivial for someone to watch what you're doing, almost in real time on a 100Mb network. And yes, even if your NFS directories are mounted with root_squash. - -- Derek Martin [EMAIL PROTECTED] - --------------------------------------------- I prefer mail encrypted with PGP/GPG! GnuPG Key ID: 0x81CFE75D Retrieve my public key at http://pgp.mit.edu Learn more about it at http://www.gnupg.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8nsx1djdlQoHP510RArsAAKCIuyqFxGk++NoToOgHRWib4aDXfwCgkt3D ls2K/pwWZxyp27xOwuS/IyU= =kFR7 -----END PGP SIGNATURE----- ***************************************************************** To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *****************************************************************
