[gentoo-desktop] more kde-sunset upgrade notes

[Brent Busby]

Recently, I've updated to Gnome 2.32.1 on the same system that is also 
running KDE 3 from sunset.  Keeping the two together on a machine that 
uses KDM 3.5.10 as a login manager is getting interesting.

Here are some notes for those who may be in a similar situation:

Recently, Gentoo decided to phase out Hal completely.  Hal has been 
deprecated for some time, but now that pretty much all software that's 
officially supported from Gentoo's main package pool has been migrated 
to use Udev-based mechanisms, Gentoo decided to pull the plug on Hal. 
(Watching 2001 for the nth time might have caused them some anxiety 
about keeping Hal around any longer too...)  Currently, Hal is still in 
Portage, but probably won't be much longer.  I think someone mentioned 
pulling it into the kde-sunset overlay if it becomes necessary for KDE's 
sake.

I've run into some issues on both the KDE 3 and the Gnome sides, which 
I'll mention separately.


KDE 3 issues:

The first trouble you'll have is that when Gentoo deprecated Hal, they 
also got rid of its USE flag, which means even from the kde-sunset 
overlay, KDE will build without Hal support, even if Hal is installed, 
and even if you have it enabled in your own USE flags.  This will make 
removable media detection not work, even if hald is running.

As it turns out, you can contradict the profile yourself by doing "-hal" 
again yourself in /etc/portage/profile/package.use.mask.  The "-hal" 
from Gentoo and your own "-hal" cancel eachother out to effectively 
equal "hal" enabled.  It's goofy, but it works.  There are two packages 
in KDE that need it, so put this in that file:

kde-base/kdebase-kioslaves -hal
app-cdr/k3b -hal

You should be able to keep your media detection in KDE now.


Gnome issues:

It should be mentioned at the start that 90% (if not all) of the issues 
below are caused by not using GDM as a login manager.  Probably KDM 4 
would work too, since it is receiving current support.

However, XDM, KDM (3.x), and Slim will all have issues running Gnome 
now.  Details follow...

Recent versions of Gnome introduced us to PolicyKit, ConsoleKit, and 
lots of other assorted "kits" that run daemons we never had before, 
create lots of really ugly messages in syslog about DBus events nobody 
wants to know about (even on fully working systems that have only Gnome 
and no deviances), and provide services that nobody I know was asking 
for.  In other words, desktop Linux evolution as usual...

In the current version of Gnome though, PolicyKit and ConsoleKit have 
become serious.  It's now necessary for PAM to run a module on every 
login called pam_ck_connector.so.  This lets console-kit-daemon know 
you're logged in.  Normally (for systems using GDM or KDM 4), the line 
in /etc/pam.d/system-login that does this contains the "nox11" 
parameter, because GDM is itself fully ConsoleKit-aware, and will 
provide its own plug to the console-kit-daemon without help from PAM. 
Thus, the "nox11" parameter inhibits the PAM plugin from working for 
cases of X logins, and makes it cover only TTY's:

session		optional	pam_ck_connector.so nox11

(You probably got this line in your PAM config as part of an update, so 
it's probably already there.  It's not necessary to do anything with it 
yourself, at least for normal systems.)  However, the assumption that 
we're running a login manager that plugs into console-kit-daemon itself 
is false if we're running anything but GDM.  (It's a Gnome world!)

First, take the "nox11" part out of that line in 
/etc/pam.d/system-login.  Then, since KDM has its own PAM config that 
doesn't source the system-login file at all (and thus is missing two 
needed lines), add the following to the bottom of /etc/pam.d/kde:

session    optional     pam_loginuid.so
session    optional     pam_ck_connector.so

Ah, but we're not done.  Now you need to modify the file that provides 
the login profile in KDM's session menu to choose Gnome.  Normally, it 
just runs "gnome-session", but we need it to run "ck-launch-session 
gnome-session", so the Gnome launch gets connected to the session in 
ConsoleKit.  (Isn't this nice?)  This is not needed for any other window 
manager I use besides Gnome, so that's the only profile you'll need to 
adjust this way.  Here's my adjusted /usr/share/xsessions/gnome.desktop:

[Desktop Entry]
Name=GNOME
Comment=This session logs you into GNOME
Exec=ck-launch-session gnome-session
TryExec=ck-launch-session
Icon=
Type=Application

If you do all of this, you should be able to type "ck-list-sessions" in 
Gnome and see your login listed as an x11 session, and most importantly, 
flagged as "active".  Mounting removable media should work, though now 
via udev and udisks-daemon rather than hald.  Oddly though, there still 
must be some magic that GDM would give me that KDM is not providing, 
because gnome-screensaver now cannot ever detect when the display has 
been idle long enough to start the screensaver on its own.  If I lock 
the display myself, it works.  The display even falls asleep on its own 
if left idle long enough, so power management is working -- although 
unlocked, and with no screensaver.  It just turns off.  A different 
system which also runs KDE 3 (from sunset) alongside modern Gnome does 
not have this problem.  The difference between them is that it uses GDM 
for its login manager.  GDM seems to do more here than meets the eye.

The telltale error in syslog is:

gnome-session[14487]: WARNING: GSIdleMonitor: Unable to initialize Sync 
extension

There is nothing in Google about this other than a reference to the 
actual line in the code that generates the message.  Basically, 
gnome-session is not able to connect to the X11 extension that tells how 
long the display has been idle.  I have no idea why, or what GDM would 
ordinarily do that sets up this connection.  The result though is that 
the screensaver will never kick in on its own, only under user control.


PARTING THOUGHTS:

Gnome is getting too complicated for its own good, and about to jump the 
shark that KDE just fell off of when 4.x came out.  Obviously, the 
intent of all of this is to tie services to the user who is actually at 
the console.  But why?

Is it really a problem if my removable media is mounted by a remote 
user?  Who says it is?  Many times, I have left a DVD in my drive only 
to access the files on it from somewhere else, logged in on a shell via 
SSH.  It's nice to not have to su to root to access that DVD.  It's also 
nice to not assume I'm on a Gnome desktop using udev, 
pam_ck_connector.so, console-kit-daemon, ck-launch-session, and Nautilus 
to see that DVD.  It used to be as simple as putting a line in 
/etc/fstab that allows that mount by regular users.

Oh!  But that was before they made it so that udev would not be able to 
automatically provide desktop icons or automounting in Gnome if you had 
such lines in your fstab.  For awhile now, it's been necessary to remove 
lines for DVD's or USB flashdrives if you want Gnome desktop 
automounting to work.  So we've gone from being able to mount a DVD from 
a bare shell as a regular user, to needing to be on a Gnome desktop, and 
from there to needing to be on a Gnome desktop that was launched in a 
ConsoleKit environment with a PAM connector module.  Otherwise, you need 
to be root to mount a DVD.

It's long been practice of the GNU Project to make versions of 
historically standard UNIX tools that have more features than the 
original did.  Their tar is a super-tar, their ps is a super-ps, and so 
on.  If we really needed more functionality for detecting who is logged 
in and from where, couldn't we have just revamped /var/log/wtmp, 'who', 
'last', and related commands and programs to provide whatever was 
missing at the UNIX level, to benefit the whole system?  Rather than 
just making more obtuse daemons that seem to be trying to make the whole 
system into one big platform to run Gnome?  And if we need finer 
permissions to control mounting of media, here's a novel idea: Posix 
groups!  Whoo!  Why not just control who can mount with a group, and 
have the users who can do that controlled by some kind of group policy? 
Nah, too simple.

You know, one of the big things that always stood in the way of FreeBSD 
being a decent desktop platform (even for technically oriented users) 
was that its fstab syntax has no equivalent to Linux's "users" option. 
There is only one even approaching-decent way to allow non-root users to 
mount media in FreeBSD, and that's to set up the Berkeley automounter 
("amd" daemon) to do it for you with an automounter map.  And as anyone 
who's ever dealt with the automounter knows, that's a fickle and 
tempermental solution sure to drive anyone crazy.  You don't want to do 
that?  Drop to a shell, and mount your disc as root!  That's removable 
media in the world of FreeBSD on the desktop.

Now, in Linux, thanks to the fact that Gnome/udev will not automount 
discs unless the fstab entry is *missing*, and thanks to the fact that 
Gnome further requires a PolicyKit/ConsoleKit environment to automount 
media also, even Linux machines with Gnome now have no option to mount 
removable media without resorting to some form of root access, via su, 
sudo, or hell why don't we just do what the BSD people do and run an 
automounter daemon?  It's all taken care of if you're in Gnome or modern 
KDE (4.x), but that's now become an assumption.  You can't even be just 
running a console anymore.

It'd be nice if the people working on all these desktop technologies 
would remember that most things always were provided with basic UNIX 
tools, and if those tools aren't doing what's needed, they can usually 
just be given new features, like the GNU Project did with most of the 
standard userland.  We don't need more daemons to interact with the 
other new daemons that we got because we needed to run more daemons.

-- 
+ Brent A. Busby	 +
+ Sr. UNIX Systems Admin +	Vote for Cthulhu.
+ University of Chicago	 +
+ James Franck Institute +	Why settle for the lesser evil?