kde-workspace/kdm/README
2014-11-13 19:30:51 +02:00

292 lines
11 KiB
Text

This is the KDE Display Manager (KDM), a replacement for the
X Display Manager (XDM).
Enter help:kdm into Konqueror's location bar to view the manual.
Semi-official home page: http://developer.kde.org/~ossi/sw/kdm.html
cmake options that affect KDM
-----------------------------
-DKDE4_COMMON_PAM_SERVICE:STRING=service
-DKDE4_KDM_PAM_SERVICE:STRING=service
Set the PAM service used by all of kdebase resp. specifically by KDM.
Whether PAM should be used in the first place is auto-detected.
-DKDE4_KERBEROS4:BOOL=ON
Compile KDM (and the LDAP KIO slave) with KTH Kerberos 4 support. Note
that this does not work with the Kerberos 4 compatibility layer found in
MIT Kerberos 5. This affects KDM only if PAM is not used.
-DKDE4_AFS:BOOL=ON
Compile KDM with AFS support. Depends on KDE4_KERBEROS4.
-DKDE4_KRB5AUTH:BOOL=ON
-DKDE4_RPCAUTH:BOOL=ON
Compile KDM with Kerberos 5 resp. secure RPC support for X authorization
cookies. It's pretty pointless to enable this if you don't use an X server
that supports it.
If you want user authentication against a Kerberos realm, compile KDM with
PAM support and use the appropriate module.
-DKDE4_XDMCP:BOOL=OFF
Compile KDM without XDMCP support.
-DKDE4_KDM_XCONSOLE:BOOL=ON
Compile KDM with a builtin "xconsole" replacement in the greeter. I don't
consider this too useful, but SuSE wanted it, so it's there. ;)
KDM's file system layout
------------------------
${kde_confdir} is usually ${prefix}/share/config
${kde_datadir} is usually ${prefix}/share/apps
The indented locations are envisioned for a configuration shared with GDM.
${kde_confdir}/kdm/{kdmrc,Xaccess,Xwilling,...}
${kde_datadir}/kdm/sessions/*.desktop
/etc/X11/sessions/,/usr/share/xsessions/
${kde_datadir}/kdm/pics/users/
${kde_datadir}/kdm/pics/
${kde_datadir}/kdm/faces/*.face{,.icon}
/usr/share/faces/
/var/run/xauth/A*
/var/run/xdmctl/xdmctl*
/var/run/kdm.pid
/var/lib/kdm/kdmsts
<site-specific>/*.dmrc
$HOME/.face{,.icon}
$HOME/.dmrc
How to setup KDM
----------------
KDM's config files are all located in ${kde_confdir}/kdm.
"make install" will create a probably working configuration, either by
deriving it from an already present KDM/XDM installation or by using
defaults if no previous installation is found.
You can change the configuration from the KDE Control Center. You will
find the "Login Manager" module in the "System Administration" group.
Have a look at README.pam in the kdebase top level directory if your
system uses PAM.
Running KDM from init
---------------------
NOTE, that this description applies to RedHat 5.x and must be adapted for
other distributions/systems. Generally I'd advise _against_ starting KDM
directly from init - better use a proper init script, possibly by slightly
modifying the XDM init script shipped by your distribution.
Edit (as root) /etc/inittab.
Look for the line:
x:5:respawn:/usr/X11/bin/xdm -nodaemon
Replace it with:
x:5:respawn:/opt/kde/bin/kdm
This tells init(8) to respawn KDM, the KDE display manager, when
the system is in run level 5.
Note that KDM does not need the -nodaemon option.
To start KDM, either run (as root) /sbin/telinit 5 (to switch to
run level 5), or (this is risky! don't do it until you _know_ you
want the system to boot into this every time!) edit /etc/inittab
and change the line:
id:3:initdefault:
to
id:5:initdefault:
If you do the latter step, then every time your system boots
successfully it will go into run level 5 and run KDM,
presenting you the exceedingly cute KDE login screen.
Running KDM from Upstart
------------------------
NOTE, this description applies to K/Ubuntu 9.10, however it should be
almost the same for other debian-based distros running Upstart.
Edit ( as root ) /etc/init/kdm.conf
Look for the line:
[ ! -f /etc/X11/default-display-manager -o "$(cat /etc/X11/default-display-manager 2>/dev/null)" = "/usr/bin/kdm" ]
and:
exec /usr/bin/kdm
Then, replace the kdm paths in order to point your new executable.
For example, if your executable is located under /opt/kde4/bin,
the updated version of the previous lines will look like this:
[ ! -f /etc/X11/default-display-manager -o "$(cat /etc/X11/default-display-manager 2>/dev/null)" = "/opt/kde4/bin/kdm" ]
and this:
exec /opt/kde4/bin/kdm
This will tell Upstart where the new kdm file il located. Now,
you have to enable your new kdm as default display manager, so
edit ( as root ) /etc/X11/default-display-manager
And change the line:
/usr/bin/kdm
to
/opt/kde4/bin/kdm
That's all! now simply start/stop kdm by typing, as root,
start/stop kdm
and you are done!
"It doesn't work!!"
-------------------
More input! ;-)
KDM accepts two command line options related to logging:
-debug <n>
<n> is a decimal or hexadecimal (prefix 0x) number.
The number is a bitfield, i.e., it is formed by summing up the
required values from this table:
1 (0x1) - core debugging. Probably the most useful one.
2 (0x2) - config reader debugging.
4 (0x4) - greeter debugging.
8 (0x8) - IPC debugging. This logs _all_ communication between the
core, the config reader and the greeter - including the
passwords you type, so edit the log before showing it to
somebody.
This attempts to synchronize the processes to interleave the
log messages optimally, but will probably fail unless you use
-debug 0x80 as well.
16 (0x10) - wait after forking session sub-daemon.
32 (0x20) - wait after starting config reader.
64 (0x40) - wait after starting greeter.
The wait options are only useful if you need to attach a debugger
to a process, but it crashes before you are able to do so without
the delay. See below.
128 (0x80) - don't use syslog for internally generated messages.
256 (0x100) - core Xauth debugging.
1024 (0x400) - run config reader and greeter through valgrind.
2048 (0x800) - run config reader and greeter through strace.
Logs from "-debug 7" are usually a good start.
-logfile <file>
<file> is the file to log various messages to. The default log file is
/var/log/kdm.log. For internal reasons there is no option in kdmrc to
permanently specify the log file location. If you redirect KDM's
standard error output to a file, KDM will log there.
If KDM is configured to use syslog (and it _very_ probably is on any
modern system), all internally generated messages are logged to the
"daemon" facility. The log usually can be found in /var/log/debug.log
and /var/log/daemon.log; make sure that daemon.* is logged (look at
/etc/syslog.conf).
If you have problems logging in and your system uses PAM (also quite
probable on modern systems), the "auth" and "authpriv" syslog facilities
are interesting, too. This is not relevant for Linux-PAM starting with
version 0.99.
Before reproducing the problem for log submission, truncate the old logs -
I'm really not interested in a month's worth of your system's history.
Send me all the logs together with a detailed description of what you did
and what happened. If your problem is related to a specific configuration,
you should also attach a tar.gz archive of your KDM config directory.
If I request a backtrace from you and KDM didn't create one yet via the
usual DrKonqi procedure, you'll need to do that yourself. The keyphrase
is "attaching gdb". How exactly this is done depends on the part that
crashes:
- master daemon. Actually you should never need to attach to it, as
you can start it within the debugger already:
# gdb --args kdm -nodaemon -debug 7
(gdb) run
- display subdaemon. Find (using ps) the process with a name like
"-:0" (where :0 is actually the display this process is for). This
process' PPID is the master daemon. Attach to it this way:
# gdb kdm <the PID you found>
(gdb) cont
If the subdaemon crashes before you can attach, add 16 to the debug flags
when you start KDM.
- config reader. You will need to add 32 to the debug flags almost certainly.
The PPID will be the master daemon as well.
# gdb kdm_config $(pidof kdm_config)
(gdb) cont
- greeter. If it's too fast, add 64 to -debug. The PPID will be the subdaemon.
# gdb kdm_greet $(pidof kdm_greet)
(gdb) cont
The simplification with "pidof" works only if you have only one display,
otherwise you need to find the PID manually (by using ps -fx).
Once you got gdb attached to the offending process, do whatever is needed
to make it crash (probably nothing, if you had to use a delay parameter).
Once it crashed, gdb will tell you a signal name, like SIGSEGV - that's the
first interesting part for me. Then you need to create the actual backtrace:
(gdb) where full
The output of this command is interesting for me. If it fails, use "bt"
instead.
I might request a backtrace even if nothing crashes, but instead hangs. In
this case don't use "cont" after attaching, but use "bt" right away. If the
process is already running, interrupt it with ctrl-c.
For obvious reasons you need to run gdb on a different virtual terminal than
the X server. To get there, press alt-ctrl-f1 and log in as root. To
switch to the X server's VT, press alt-ctrl-f7 (the exact function key may
be different on your system). You may also use a remote login from a
second machine. In any case it is advantageous to have mouse support on the
debugging console for copying the backtrace.
Note that a backtrace is usually _much_ more useful if the binary contains
debugging info, so unless your distribution provides debug symbol packages,
you should install from source with the -DCMAKE_BUILD_TYPE:STRING=debugfull
cmake flag if at all possible.
Random rambings and license information
---------------------------------------
Version 0.1 of KDM is copyright
Matthias Ettrich <ettrich@trolltech.com>
All later versions copyright:
(C) 1997-2000 Steffen Hansen <hansen@kde.org>
Since version 0.90 (KDE 2.1) copyright:
(C) 2000-2007 Oswald Buddenhagen <ossi@kde.org>
The files in the backend directory are licensed under the X licence
(see http://en.wikipedia.org/wiki/X_Licence#License_terms for more info).
The files in the kfrontend directory are licensed under the GNU GPL.
Thanks to (in no particular order):
Michael Bach Jensen and Torsten Rahn for drawing icons.
Duncan Haldane for investigation of PAM issues.
Stephan Kulow for helping with the autoconf stuff.
Martin Baehr for intensive testing and writing the sample Xsession scripts.
Harald Hoyer <Harald.Hoyer@redhat.de> for the (now obsoleted) chooser.
SuSE for employing me (ossi) for three months to work on kdm.
BasysKom for sponsoring my (ossi's) work on the conversation plugin stuff.
... and _many_ others ...
--
Have fun with it (and feel free to comment),
Oswald Buddenhagen <ossi@kde.org>