LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

achived/removed

This commit is contained in:
gferg 2006-05-29 21:35:36 +00:00
parent 39e911a3f4
commit 078b7fcdd4
2 changed files with 0 additions and 820 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

467
LDP/howto/linuxdoc/Bridge+Firewall+DSL.sgml
View File

@ -1,467 +0,0 @@
<!doctype linuxdoc system>
<article>
<title>Bridge + Firewall + DSL Mini-HOWTO
</title>
<author>Derek Ney <tt><url url="mailto:derek@hipgraphics.com" name="derek@hipgraphics.com"></tt>
</author>
<date>Nov 9, 2000
</date>
<abstract>Configuring a Linux system to act as a firewall and bridge with a DSL network connection
</abstract>
<toc>
<sect>Introduction<label id="Introduction" >
<sect1>History<label id="History" >
<p>This document was started on December 10, 1999 by Derek Ney <url url="mailto:derek@hipgraphics.com" name="derek@hipgraphics.com"> after
three day's worth of frustration with bridging and firewalling after switching from a PPP network
link to a DSL link.
</p>
<sect1>New versions
<p>The newest version may be found in different formats at the LDP homepage <url url="http://www.linuxdoc.org/" name="http://www.linuxdoc.org/">.
</p>
<sect2>Version History
<p>v0.04 (Nov 9, 2000)</p>
<p><itemize>
<item>Updated for newer bridge configuration utility bridgex
</itemize></p>
<p>v0.03 (Mar 24, 2000)</p>
<p><itemize>
<item>Fixed up URL for BRCFG.tgz
</itemize></p>
<p>v0.02 (Dec 13, 1999)</p>
<p><itemize>
<item>Incorporate revisions from Leonard Dickens (thanks Leonard!)
</itemize></p>
<p>v0.01 (Dec 10, 1999)</p>
<p><itemize>
<item>Initial version
</itemize></p>
<sect1>Copyrights
<p>(c) 1999,2000 Derek R. Ney
</p>
<p>This document may be distributed under the terms set forth in the LDP license
at <url url="http://www.linuxdoc.org/COPYRIGHT.html" name="http://www.linuxdoc.org/COPYRIGHT.html">.
</p>
<sect>Bridging, Firewalls, and DSL connections
<p>Until recently, our local network was hooked into the global net
via PPP over a modem. I had installed a firewall using IPChains
(<url url="http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html" name="http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html">)
with this setup and it worked nicely. We recently upgraded to a DSL connection.
I thought it would be trivial to simply switch my firewall to insulate me
from the larger net coming in via the DSL connection. I was wrong.
It took three days of work to finally get it up and running. I found a lot
of suspect information on the net that caused a good deal of confusion.
This mini-HOWTO was written because I suspected that our setup will be a quite
common configuration in the future when DSL becomes more widespread and I wanted to
help people avoid massive frustration.
</p>
<p> I guess this is applicable to a cable modem setup, but YMMV as I know nothing
about cable modem hookups.
</p>
<sect1>The Problem
<p>The problem I am trying to solve is to configure the system such
that the firewall code in the kernel (that is manipulated with
ipchains) can be used to filter the packets that travel back and
forth between the outside world and the local network. I also needed
some of the local machines to be "seen" on the global net (though always
filtered through the firewall). This ruled out IP masquerading (see
<url url="http://www.linuxdoc.org/HOWTO/IP-Masquerade-HOWTO.html"
name="IP Masquerade HOWTO">) which would otherwise probably be
a simpler solution. This is not as simple as it seems.
</p>
<p>
<sect1>The Solution
<p>To accomplish our goal of insulating a local net from the global
net (over DSL) by using our Linux box, we will use two ethernet (NIC) cards.
One card is hooked up to the local net and one to the global net. The only
machine that can directly talk to the outside world is the Linux box. All
other machines in our local net must go through the Linux box (firewall).
</p>
<p>Configuring the software really consists of two problems:
</p>
<p>
<itemize>
<item>Route packets between the local and global net (bridging)
<item>Filter the packets to stop some from traversing the firewall
</itemize></p>
<p>The <url url="http://www.linuxdoc.org/HOWTO/mini/Bridge.html" name="Bridging mini-Howto">
gives detailed instructions that solves the first problem by routing packets
between the two sides of the network (local and global). This works by putting
both NIC's into "promiscuous" mode such that they sniff all the packets on
each NIC and transfer packets over when they belong on the other side.
This is done transparently; the other computers on the net do not even see
the bridge, because it does not even have an IP address. But this does not
totally solve the problem. I wanted the firewall to have an IP address
(for administration via the network, if nothing else) and more importantly,
the bridge code in the kernel intercepts and bridges packets BEFORE they get
to the firewall code, so the firewall will have no effect.
</p>
<p>It turns out you can assign your NIC's IP addresses and still use them as a
bridge. Although the <url url="http://www.linuxdoc.org/HOWTO/mini/Bridge.html" name="Bridging mini-Howto">
does not do this (well actually, it uses loopback addresses), it works fine.
That solves one problem. For the firewall problem, we turn to a fine kernel patch
at <url url="http://ac2i.tzo.com/bridge_filter/" name="http://ac2i.tzo.com/bridge_filter/">
that causes the firewall rules to be invoked for packets that are being
bridged with a special new rule "bridgein".
</p>
<sect1>Setup Overview
<p>This mini-HOWTO is meant to handle the situation where you have a Linux
box configured as a gateway/firewall. The system has 2 NIC cards installed.
One of the NIC cards is connected to the outside world (in our case a DSL
modem) and nothing else. The other NIC is connected to our local network.
</p>
<p>Note that I have only had one experience with this and it was on my
i386 (ABIT BP6 MOBO, w/2 celery) box with RedHat 6.0 with the 2.2.13
kernel, and a DSL modem going to a router, and two Netgear FA310TX
NIC cards. Your mileage may vary.
</p>
<p>Also note that the steps here will leave your network open to potential
attack during setup (before the firewall is turned on). If you are very
paranoid you will want to take extra steps to avoid this.
</p>
<sect1>References
<p>I found a good deal of information on the net that I used to finally
get things working. Some of the information was useful, but inaccurate.
</p>
<p>The <url url="http://www.linuxdoc.org/HOWTO/mini/Bridge.html" name="Bridging mini-Howto">
was instrumental in getting things up. Unfortunately using it alone does not
implement a firewall.
</p>
<p>The <url url="http://www.linuxdoc.org/HOWTO/mini/Bridge+Firewall.html" name="Linux Bridge+Firewall mini-HOWTO">
at first looked like just what I needed. However, it turns out that I think
it is inaccurate. I got things sort-of working with it, but in the end I
realized that it was not necessary to split your sub-net in two like it
directs and did not use that method. If you look at this document, take
it with a grain of salt.
</p>
<p>The <url url="http://ac2i.tzo.com/bridge_filter/" name="Bridge Filter Patch"> is
the key to getting the whole thing to work. Oddly enough, the information on
the web page directs you to the Bridge+Firewall mini-HOWTO. You do not need
to use the information in Bridge+Firewall mini-HOWTO to get things to work.
You will need this patch.
</p>
<p>The <url url="http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html" name="IPCHAINS HOWTO">
is invaluable in setting up the firewall itself. I do not attempt to cover the details
of firewall setup in this document; only issues which are different because
of the bridging setup are mentioned here.
</p>
<sect>Procedure
<p>The basic procedure is as follows:
</p>
<p>
<itemize>
<item>Setup your hardware (and verify that it works)
<item>Patch and configure the kernel
<item>Configure your network (ifconfig, route, bridging)
<item>Configure the firewall
</itemize></p>
<sect1>Example Setup
<p>Throughout this procedure, I will assume a setup with two ethernet (NIC)
cards, an outside link via DSL (where a DSL modem connects to one of the NIC's),
and a local net that connects to the other NIC. I will arbitrarily call
the NIC to the DSL modem "eth1" and the local net NIC "eth0". The device naming
by the kernel of the NIC's depends on what slot they are in.
</p>
<p>I will assume that you have been assigned a subnet of IP addresses
at 192.168.2.128-191, i.e. a netmask of 255.255.255.192, and the router
provided by the DSL company is at 192.168.2.129. These are all arbitrary
fictional examples to illustrate the setup. I will use the address
192.168.2.130 for the firewall machine (both NIC's), though it turns
out you can also use distinct IP addresses for each NIC if you want.
</p>
<sect1>Hardware Setup
<label id="Hardware Setup">
<p>You will need two ethernet cards to make this work. The biggest problem
I had was that I randomly picked a slot in my motherboard for the second
NIC and it turned out that that slot (PCI) shared an interrupt with the
first NIC. I did not know that this was a problem (in fact there is little
information about this, and I thought it should work fine). It caused both
cards to shut down quietly (no error indication) and stop sending and
receiving packets. Naturally when you are doing all sort of configuration
changes, this is the last thing you need. I do not know if this is a problem
with all PCI NIC cards or just ours, but I would advise against sharing interrupts.
The tulip driver, which we use, reports the IRQ for each NIC in syslog when you boot.
There is a bunch of information out there
(see the <url url="http://www.linuxdoc.org/HOWTO/Ethernet-HOWTO.html" name="Ethernet-HOWTO">
section <url url="http://www.linuxdoc.org/HOWTO/Ethernet-HOWTO-3.html#ss3.2"
name="Using More than one Ethernet Card per Machine">) about making the kernel recognize two
ethernet cards using boot arguments; however, I did not need this (my kernel
recognized both cards with no arguments).
</p>
<p>Next, you need to hook the second NIC to the DSL modem
(or whatever links you to the outside world) and make sure that it is working.
You should be able to ifconfig the second ethernet card to a proper IP
address and ping the router on the other end of your outside link.
This verifies that you can send and receive packets over the DSL link.
For instance, for the sample net you would do:
</p>
<p><verb>
ifconfig eth1 192.168.2.130 netmask 255.255.255.192 broadcast 192.168.2.191
</verb></p>
<p>to configure the NIC. And then
</p>
<p><verb>
ifconfig eth0 down # just to make sure it does not interfere with things
ping 192.168.2.129
</verb></p>
<p>to test that you can get to the router. For good measure, you should also
test that you can get to the machines on your local network through the other
NIC:
</p>
<p><verb>
ifconfig eth1 down # just to make sure it does not interfere with things
ifconfig eth0 up
ping 192.168.2.x # where x is the address for a machine on your local net
</verb></p>
<p>At this point, you have verified that all the hardware is working.
</p>
<sect1>Bridge Config
<p> Depending upon your kernel version you will need either the
<url url="ftp://ftp.tux.org/people/alan-cox/BRCFG.tgz" name="old bridge configuration utility (BRCFG)"> for kernels before 2.2.14, or the <url url="http://lrp.plain.co.nz/tarballs/bridgex_0.30.tar.gz" name="new bridge configuration utility (bridgex)"> for later kernels; these utilities
allow you to control the bridging in your kernel when CONFIG_BRIDGE is turned on. <bf>BRCFG</bf> is distributed
as source with pre-compiled executables. I do not know what kernel the executable was compiled with, but I got
different results after I recompiled it with my kernel (2.2.13) include files. Unfortunately, to do this I had
to patch them slightly. Here are the patches:
</p>
<p><verb>
diff -C 3 -r /tmp/BRCFG/brcfg.c ./brcfg.c
*** /tmp/BRCFG/brcfg.c Wed Feb 21 19:11:59 1996
--- ./brcfg.c Wed Dec 8 12:52:23 1999
***************
*** 1,6 ****
! #include <sys/types.h>
! #include <sys/socket.h>
#include <skbuff.h>
#include "br.h"
--- 1,6 ----
! #include <types.h>
! #include <socket.h>
#include <skbuff.h>
#include "br.h"
</verb></p>
<p>Apply the patch, recompile <bf>brcfg</bf> and install it somewhere appropriate
(I chose <bf>/usr/sbin</bf>).
</p>
<p>For kernels later than 2.2.13 you definitely want to use the newer bridge
configuration utility
<url url="http://lrp.plain.co.nz/tarballs/bridgex_0.30.tar.gz" name="bridgex">.
I am not sure if it works with earlier kernels or not. Not that the URL for this
utility is found in the kernel configuration help file
<bf>/usr/src/linux/Documentation/Configure.help</bf>, so if the URL mentioned
here is not correct, look in the help file (it is the help for the
<bf>CONFIG_BRIDGE</bf> kernel configuration item. The bridgex tarball contains
an already compiled executable, but you should probably remake it using
the included Makefile. Note that the bridgex
utility takes slightly different arguments than does the BRCFG package (that
will be covered later when I talk about configuring the bridge).
</p>
<sect1>Kernel Configuration
<p> You will need to patch and configure your kernel for bridging and the bridging filter
(as well as firewalling, networking, etc. if you do not already have it). The following
kernel configuration items will be needed (at least):
</p>
<p><verb>
CONFIG_EXPERIMENTAL=y
CONFIG_BRIDGE=y
CONFIG_FIREWALL=y
CONFIG_IP_FIREWALL=y
</verb></p>
<p> You should grab the <url url="http://ac2i.tzo.com/bridge_filter/" name="Bridge Filter Patch">
and apply it to your kernel. Recompile and install your kernel and then reboot.
</p>
<sect1>Putting It All Together
<p> So you should have your two NIC's working, a newly configured kernel, and <bf>brcfg</bf>
installed. Now you need to construct a startup script to put it all together. I did this using
the RedHat type startup scripts (<bf>/etc/rc.d</bf>). I put specific network addresses and
masks in <bf>/etc/sysconfig/network</bf>:
</p>
<p><verb>
GATEWAY=192.168.2.129 # the address of the DSL router
GATEWAYDEV=eth1 # the NIC that the router is connected to
ETH0_ADDR=192.168.2.130 # the IP address for the NIC on our LAN
ETH0_MASK=255.255.255.192 # the netmask of our LAN
ETH0_BROAD=192.168.2.191 # the broadcast address of our LAN
ETH1_ADDR=192.168.2.130 # the IP address for the NIC on the DSL side
# can be different from ETH0_ADDR if you want
ETH1_MASK=$ETH0_MASK # the DSL side netmask, should be the same as eth0
ETH1_BROAD=$ETH1_BROAD # ditto for the broadcast address
</verb></p>
<p> Next I created a script in <bf>/etc/rc.d/init.d/bridge</bf> to setup the bridge.
I include two scripts here. The first script is used with the old BRCFG utility,
the second for the newer bridgex. First the one for the older BRCFG:
<p><verb>
#!/bin/sh
#
# bridge This shell script takes care of installing bridging for dsl with BRCFG
#
# description: Uses brcfg to start bridging and ifconfigs eths
# processname: bridge
# config:
# Source function library.
. /etc/rc.d/init.d/functions
# Source networking configuration.
. /etc/sysconfig/network
# See how we were called.
case "$1" in
start)
echo -n "Configuring bridge: "
ifconfig eth0 $ETH0_ADDR netmask $ETH0_MASK broadcast $ETH0_BROAD
ifconfig eth1 $ETH1_ADDR netmask $ETH1_MASK broadcast $ETH1_BROAD
route add $GATEWAY dev $GATEWAYDEV
route add default gw $GATEWAY dev $GATEWAYDEV
ifconfig eth0 promisc
ifconfig eth1 promisc
brcfg -enable
echo
;;
stop)
# Stop daemons.
brcfg -disable
ifconfig eth0 down
ifconfig eth1 down
;;
restart)
$0 stop
$0 start
;;
status)
ifconfig eth0
ifconfig eth1
brcfg
;;
*)
echo "Usage: bridge {start|stop|restart|status}"
exit 1
esac
exit 0
</verb></p>
<p>The next script is the one to use with the newer bridge configuration utility bridgex.
Note that bridgex is much more configurable than the older BRCFG and so you may want
to look man page included with the bridgex tarball and custom configure this script:
<p><verb>
#!/bin/sh
#
# bridge This shell script takes care of installing bridging for dsl with BRCFG
#!/bin/sh
#
# bridge This shell script takes care of installing bridging for dsl with bridgex
#
# description: Uses brcfg to start bridging and ifconfigs eths
# processname: bridge
# config:
# Source function library.
. /etc/rc.d/init.d/functions
# Source networking configuration.
. /etc/sysconfig/network
# See how we were called.
case "$1" in
start)
echo -n "Configuring bridge: "
ifconfig eth0 $ETH0_ADDR netmask $ETH0_MASK broadcast $ETH0_BROAD
ifconfig eth1 $ETH1_ADDR netmask $ETH1_MASK broadcast $ETH1_BROAD
route add default gw $GATEWAY dev $GATEWAYDEV
ifconfig eth0 promisc
ifconfig eth1 promisc
brcfg start
brcfg device eth0 enable
brcfg device eth1 enable
echo
;;
stop)
# Stop daemons.
brcfg stop
ifconfig eth0 down
ifconfig eth1 down
;;
restart)
$0 stop
$0 start
;;
status)
ifconfig eth0
ifconfig eth1
brcfg
;;
*)
echo "Usage: bridge {start|stop|restart|status}"
exit 1
esac
exit 0
</verb></p>
<p> The script is run during bootup. It assigns addresses to each NIC, adds a default route
that goes to the DSL router, adds a specific route direct to the DSL router, puts each NIC
in "promiscuous" mode, and then enables bridging. I linked this script into the following
directories in <bf>/etc/rc.d</bf>:
<p><verb>
/etc/rc.d/rc0.d/K90bridge
/etc/rc.d/rc1.d/K90bridge
/etc/rc.d/rc2.d/S11bridge
/etc/rc.d/rc3.d/S11bridge
/etc/rc.d/rc4.d/S11bridge
/etc/rc.d/rc5.d/S11bridge
/etc/rc.d/rc6.d/K90bridge
</verb></p>
<p> This makes it run right after the network start script. You should disable
other configuration of eth0 (or eth1) such as done in the <bf>/etc/rc.d/init.d/network</bf> script
(in RedHat by removing files <bf>ifcfg-eth?</bf> from <bf>/etc/sysconfig/network-scripts/</bf>).
</p>
<p> To try things out, I suggest rebooting in single user mode (specify <bf>"single"</bf>
as an arg to the kernel, e.g. in lilo "lilo: linux single")
and running the startup scripts in <bf>/etc/rc.d/rc3.d</bf> one at a time
until you get to the bridge startup. Startup the bridge and then see if you can reach some
machines (you probably
want to use "<bf>ping -n</bf>" for this to keep the nameserver out of the equation):
</p>
<p><itemize>
<item>ping the DSL router
<item>ping a local machine
<item>ping a machine on the global net
</itemize></p>
<p> If you can ping all those places, there is a good chance that things are working.
Note that the bridge takes a few moments to startup. You can monitor the status of
the bridge by issuing the command <bf>brcfg</bf> with no arguments.
</p>
<sect1>Firewall Setup
<p>You still need to setup your firewall (assuming you want one) to prevent unauthorized
access. The <url url="http://ac2i.tzo.com/bridge_filter/" name="Bridge Filter Patch">
that you applied allows you to use a new built-in rule "bridgein" with ipchains. This rule
is used whenever a packet is going to be forwarded either from eth0 to eth1 or vice versa.
The bridgein rule is not used when a packet is destined for the firewall itself; you
will want to use the input rule for that. I will not attempt to delve into the firewall
setup in detail; please see the
<url url="http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html" name="IPCHAINS HOWTO"> for that.
</p>
<sect1>Local Machine Setup
<p> For each of your local machines, you simply have to setup the proper IP address and netmask
and use the DSL router for the gateway (default route). The firewall/bridge will bridge the packets
to/from the DSL router.
</p>
<sect>Quirks and Problems
<sect1>Odd message when using <bf>ipchains -X</bf>
<p> The patch to add the bridgein built-in rule to ipchains makes the "delete all chains"
command, <bf>ipchains -X</bf>, issue the following error:
<p><verb>
ipchains: Device or resource busy
</verb></p>
<p> As far as I can tell this is harmless. I suspect that ipchains does not
understand that the new bridgein rule is a builtin.
</p>
<sect1> Shared Interrupts
<p>
As I mentioned in <ref id="Hardware Setup" name="Hardware Setup">, at least for PCI NIC's
you do not want to share interrupts between the two cards (or probably with any other device).
</p>
</article>

353
LDP/howto/linuxdoc/KDE-GUI-Login-Configuration-HOWTO.sgml
View File

@ -1,353 +0,0 @@
<!doctype linuxdoc system>
<article>
<title>KDE GUI Login Configuration HOWTO
<author>John P. Meshkoff,II <url url="mailto:johnm@sivakalpa.org" name="johnm@sivakalpa.org">
<date>v1.03 2003/04/13 update icon notes and kde 3.1 handbook notes
<!-- v1.02 2002/07/14 kcontrol update -->
<!-- v1.01 2002/06/10 link update -->
<!-- v1.0 2002/06/07 Added kcontrol info -->
<!-- v0.03 2002/05/22 -->
<!-- was KDE GUI Login Window Manager HOWTO; changed 2002/05/22 -->
<!-- v0.02 2002/05/21 -->
<!-- v0.01, 2002/04/14 -->
<!-- v0.0, 2002/04/10 1st sgml draft -->
<!-- re-phrased the abstract 2002/05/21 -->
<!-- re-phrased the abstract 2002/05/22 -->
<abstract>
This is the KDE GUI Login Configuration HOWTO, a tutorial on customizing the
GUI login screen. Topics include:
How to add other window managers to the drop-down selection list;
how to enable user selection icons in the login window;
and requiring root permission for system shutdown.
</abstract>
<toc>
<sect> Copyright
<P>
Copyright (c) 2002 by John Meshkoff
Please freely copy and distribute (sell or give away) this document in any format. It's
requested that corrections and/or comments be forwarded to the document maintainer. You
may create a derivative work and distribute it provided that you:
1. Send your derivative work (in the most suitable format such as sgml) to the LDP (Linux
Documentation Project) or the like for posting on the Internet. If not the LDP, then let
the LDP know where it is available.
2. License the derivative work with this same license or use GPL. Include a copyright notice
and at least a pointer to the license used.
3. Give due credit to previous authors and major contributors.
If you're considering making a derived work other than a translation, it's
requested that you discuss your plans with the current maintainer.
<sect> Introduction
<P>
This info is based on my RedHat 6.1 default KDE Workstation installation. If you are using
another distribution, or even another version of RedHat, or a different Workstation install,
then you may have to do some detective work. Hopefully, this info will give you what you need
to start detecting! This HOWTO began as the result of wondering how to add another window manager
or desktop environment to the drop-down list on the GUI login screen; further investigation
revealed other configuration options.
I began my own "detective work" when I found a reference on a RedHat List which
mentioned <tt>/etc/inittab</tt>, and its role in system startup. In
<tt>/etc/inittab</tt> I found the following entries, which define how the
X Window System is started in my distribution and version:
<tscreen><code>
&num; Run xdm in runlevel 5
&num; xdm is now a separate service
x:5:respawn:/etc/X11/prefdm -nodaemon
</code></tscreen>
Here is what prefdm looks like:
<tscreen><code>
&num;!/bin/sh
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin
&num; Run preferred X display manager
preferred=
if [ -f /etc/sysconfig/desktop ]; then
if grep -q GNOME /etc/sysconfig/desktop 2>/dev/null; then
preferred=gdm
elif grep -q KDE /etc/sysconfig/desktop 2> /dev/null; then
preferred=kdm
elif grep -q AnotherLevel /etc/sysconfig/desktop 2> /dev/null; then
preferred=xdm
fi
fi
if [ -z ":&dollar;preferred" ]; then
if which gdm >/dev/null 2>&amp;1; then
preferred=gdm
elif which kdm >/dev/null 2>&amp;1; then
preferred=kdm
elif which xdm >/dev/null 2>&1; then
preferred=xdm
fi
fi
if [ -n "&dollar;preferred" ] &amp;&amp; which &dollar;preferred >/dev/null 2>&amp;1; then
exec `which &dollar;preferred` &dollar;*
fi
exit 1
</code></tscreen>
No changes to prefdm are necessary; it determines which display manager is the
system default, and which runs the GUI login. During boot-up, prefdm parses
<tt>/etc/sysconfig/desktop</tt> and selects the display manager listed there;
in the case of my KDE Workstation install, this is kdm (KDE Display Manager).
Note that gdm (Gnome Display Manager) is not installed on my system; xdm (X
Display Manager) is installed by default as part of the X Window System, and
was apparently used by older versions of Red Hat.
<!-- added caution and editing tips 2002/05/22 -->
<sect> Adding new window manager selections to the drop-down list
<p>
WARNING: The procedures explained in this HOWTO involve making changes to system
configuration files; if you are not experienced in making such changes, some
caution is required. Introducing errors into such files may make your system
unstable, or cause it to crash. The procedures explained in this HOWTO have
been tested and should not cause problems if used correctly.
If you have KDE 2.2 or higher, and you are not comfortable with manual editing of system files, you may open a
terminal window (xterm or konsole) from your user desktop (NOT the root
desktop), then type and enter:
<tscreen><code>
su -c 'kcontrol'
</code></tscreen>
Enter your root password at the prompt, and make the changes from within the
KDE Control Center that appears: go to <em>Applications ==> Login Manager</em>. Choose
the appropriate configuration tab; you can easily configure every aspect of
the login screen from there. In Earlier versions of KDE, kcontrol can modify
kdmrc, but cannot modify Xsession which is used in those versions; see the
note below about changes from KDE 2.2 and higher.
To see how to manually configure some of these, and see what these
configuration files do, proceed as follows:
(Caution: Some configuration files have changed since the version of kdm
I'm using, particularly since KDE > 2.0:
The following is quoted from
<url url="http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x11-wm.html" name="the FreeBSD
Handbook-X11:">
"Note:
In KDE 2.2 this has changed: kdm now uses its own configuration files. Please
see the KDE 2.2 documentation for details.")
<!-- add ref to kde 3.1 2003/04/13 -->
Note:
KDE 3.1 has added kdm documentation, see <url url="http://docs.kde.org/en/3.1/kdebase/kdm/" name="The kdm Handbook">
Much of the material in this new handbook applies to the older versions;
new features are also described therein.
Check the documentation for your version to identify the current configuration
files if you want to manually edit these, or just want to see how they work.
Do <em>not</em> use a <em>word-processor</em> program for editing system configuration
files; such programs introduce special formatting characters which will corrupt the files.
Use a <em>text-editor</em>, particularly one which can handle long lines without introducing
extra carriage-return or line feed characters into existing code. Suitable editors include
vim (vi improved), vi, and emacs. There are others, but these are usually installed by default
in Linux workstation installations; they each have features which make them especially suitable for
writing and editing computer code. See the bibliography section at the end of this HOWTO for
more information.
IMPORTANT: Before making changes to <em>any</em> system configuration files, you should make
back-up copies of the originals, so you can restore them in case of serious errors!
The files which we will be changing here are <tt>/usr/share/config/kdmrc</tt>, which
is where we add selection labels to the drop-down list on the login screen, and
<tt>/etc/X11/xdm/Xsession</tt>, which is where we add the path to the executables
for our labels (if you are using a different distribution, the path to these
files may be different; just do "<tt>locate kdmrc</tt>" and "<tt>locate Xsession</tt>"
in the shell [i.e., in a terminal emulation, such as <em>xterm</em>, or KDE's <em>konsole</em>]
to find them).
The default line to change in kdmrc looks like this:
<tscreen><code>
SessionTypes=kde;gnome;anotherlevel;default;failsafe;
</code></tscreen>
After adding selection labels for two new window managers, windowmaker and blackbox, the line looks like this:
<tscreen><code>
SessionTypes=kde;gnome;windowmaker;blackbox;anotherlevel;default;failsafe;
</code></tscreen>
<!-- cleaned up phrasing in this paragraph 21May2002 -->
Notice the positions where I have added the labels for the new window managers; all
entries will appear on the drop-down list in the same order as they
appear in the SessionTypes list. Next, the actual choosing takes place in
<tt>/etc/X11/xdm/Xsession</tt>. Here is what the appropriate section of
Xsession looks like before adding the new entries:
<tscreen><code>
&num; now, we see if xdm/gdm/kdm has asked for a specific environment
&num;
case &dollar;&num; in
1)
case &dollar;1 in
failsafe)
exec xterm -geometry 80x24-0-0
;;
gnome)
exec gnome-session
;;
kde)
exec startkde
;;
anotherlevel)
&num; we assume that switchdesk is installed.
exec /usr/share/apps/switchdesk/Xclients.anotherlevel
;;
esac
esac
</code></tscreen>
<!-- removed for clarity "I have just copied, pasted, and edited (to help avoid mis-typing) existing entries
to create the new entries." 21May2002 -->
<!-- added "appropriate section of the" 14Apr2002 -->
<!-- re-phrased "NOTE" to clarify; added "spelling and case..." 21May2002 -->
Here is what this section of the Xsession file looks like after adding the new
entries (NOTE that the selection labels <em>must</em> be <em>exactly</em> the
same in Xsession and prefdm, i.e., spelling and case must be identical):
<tscreen><code>
&num; now, we see if xdm/gdm/kdm has asked for a specific environment
&num;
case &dollar;&num; in
1)
case &dollar;1 in
failsafe)
exec xterm -geometry 80x24-0-0
;;
gnome)
exec gnome-session
;;
kde)
exec startkde
;;
windowmaker)
exec wmaker
;;
blackbox)
exec blackbox
;;
anotherlevel)
&num; we assume that switchdesk is installed.
exec /usr/share/apps/switchdesk/Xclients.anotherlevel
;;
esac
esac
</code></tscreen>
<!-- added path note 2002/05/22 -->
Note that when the executables are installed in one of the paths shown below, only the
executable name is required after "exec"; otherwise the full path must be included,
as shown for "Xclients.anotherlevel" (above):
<tt>/usr/bin/</tt>
<tt>/usr/local/bin/</tt>
<tt>/usr/X11R6/bin/</tt>
<tt>/usr/bin/X11/</tt>
These examples should be enough for you to add your favorite window manager(s) to the
KDE graphical login, or to give you a starting point to find out how it's done in your
particular installation.
<!-- added two new sections 2002/05/22 -->
<sect>Enabling user selection icons in the login dialog box
<p>
In RedHat 6.1, the default KDE login window shows a dialog box with a space to
type in the user name, one in which to type the user password, and a drop down
list to select the window manager/desktop environment of choice. By making the
following changes to <tt>/usr/share/config/kdmrc</tt>, user icons will appear in
the top of the login box.
Here is what the default lines that control user icon view in kdmrc look like (other
lines between these two are not shown, and are represented by "..."):
<tscreen><code>
#Users=root;johndoe
...
UserView=false
</code></tscreen>
Here are the same lines after editing; delete the comment character ("#") in
front of "Users=..." and change "johndoe" to your username (if there are more
user accounts on your system, you may add their usernames here, separated by semi-colons
as shown). Change "UserView=false" to "UserView=true" as shown here:
<tscreen><code>
Users=root;johnpipe
...
UserView=true
</code></tscreen>
Now, when you login, you may click on an icon with the mouse to enter the user name; you must still type in your password.
<!-- new info on adding your own icons -->
You can add your own icons in place of the default icons; place you own icons
in /usr/share/apps/kdm/pics/users/. They should be of size 64 x 64, according
to the kdm handbook; in KDE 1.x, the default icons are 62 x 63, and my new user icon is 60
x 60, so if icons are reasonably close to the specified 64 x 64 size, they
will work OK. The handbook says "kdm is able to handle icons of different
sizes, but the result looks messy.", so there is evidently some leeway here.
Your icons should be named 'username.xpm', for example my username is
"johnpipe" and my new icon is named 'johnpipe.xpm'
NOTE: at some time since kde 1.x, the icon format has been changed from '.xpm'
(XPixMap) to '.png' (portable network graphic).
<sect>Requiring root permission for shutdown
<p>
The default for the shutdown button on the login box allows anyone to use it to shutdown the system.
The section in <tt>/usr/share/config/kdmrc</tt> controlling who may use this button looks like this:
<tscreen><code>
#ShutdownButton=RootOnly
ShutdownButton=ConsoleOnly
</code></tscreen>
To enable only the root user to shutdown the system, change the lines as shown below:
<tscreen><code>
ShutdownButton=RootOnly
#ShutdownButton=ConsoleOnly
</code></tscreen>
Clicking the shutdown button will now prompt for the root password before shutting down the
system.
<sect>Bibliography
<p>
For more HOWTO's, see <url url="http://www.tldp.org/" name="The Linux Documentation Project">
Recommended reading:
<itemize>
<item><url url="http://www.tldp.org/HOWTO/XWindow-User-HOWTO/" name="XWindow-User-HOWTO">
<item><url url="http://www.tldp.org/HOWTO/Emacs-Beginner-HOWTO.html" name="Emacs Beginner's HOWTO">
<item><url url="http://www.tldp.org/HOWTO/Vim-HOWTO.html" name="Vim Color Editor HOW-TO (Vi Improved with syntax color highlighting)">
</itemize>
Depending on your Linux distribution and version, you may already have the
above HOWTO's installed on your system. If not installed, you may have them
on your installation CD.
</article>