I love Debian and the release of 'etch' has made even the stable branch of Debian suitable for regular users (when I say this I mean ones with an IQ above a labotomised flatworm, no hope for the other 90%).
Sometimes however it is hard to find a straight forward way to do various tasks in a way that is 'compatible' with the Debian packaging system and still be dead easy for the user to use.
Below are a number of things I have documented how to do things that I felt were not straight forward to work out.
Okay, these are not real sysadmin'ing tasks...but you get the drift :)
The downside of this approach is that DHCP is assumed to always be available and that you use the Debian 'staff' (gid 50) group for administrators/owners of the machine whilst 'users' for 'guest' access on the laptop.
Once done when you plug in your wireless card you will be able to configure it with 'wpa_gui', if the card recongises the network then it will automatically connect and get a DHCP lease.
When running 'wpa_gui' you will have to call it as:
/usr/sbin/wpa_gui -p /var/run/wpa_supplicant.ath0
If you do not do this then the wpa_supplicant control socket cannot be found and things go wrong. As this would only be a task to do when you configure the laptop for the network, I hardly is a big inconvience.
The method depends on 'ifmetric' (optional but recommended), 'wpasupplicant', 'wpagui', 'ifplugd' (optional) and 'wireless-tools'. Slight amendments will need to be made if you are not using a madwifi. This method also lets you connect both a wired and wirelessly, the routing tables are amended (using 'ifmetric') so that the priority of the wireless route is lower than any present wired route.
When unplugged 'wpasupplicant' is gracefully shutdown and the wireless card driver is unloaded; this is so that when the module is loaded next time the card is plugged in the hotplug scripts are triggered correctly.
/etc/wpa_supplicant/ath0.conf
Make sure the file is only readable and writable by root.
ctrl_interface=/var/run/wpa_supplicant.ath0 ctrl_interface_group=50 update_config=1
/etc/network/interfaces
If your wireless card is not a PCMCIA one then comment out 'allow-hotplug'.
auto lo
iface lo inet loopback
# The primary network interface
#allow-hotplug eth0
iface eth0 inet dhcp
allow-hotplug ath0
iface ath0 inet dhcp
wpa-conf /etc/wpa_supplicant/ath0.conf
wpa-driver madwifi
# meant to turn on my LED's but does not :(
# device: 3Com OfficeConnect Wireless 11a/b/g PC Card
up sysctl -q -w dev.wifi0.ledpin=1
up sysctl -q -w dev.wifi0.softled=1
up sysctl -q -w dev.wifi0.softled=0
# stops the Atheros chipset disconnecting and noseying around
up iwpriv ath0 bgscan 0
up ifmetric ath0 5
down wpa_cli -p/var/run/wpa_supplicant.ath0 terminate
down modprobe -r ath_pci
/etc/default/ifplugd
You do not actually need ifplugd unless you would like your laptop to beep when it connects and disconnects. This I would usually find annoying however it is handy to 'hear' when you lose wireless reception.
INTERFACES="eth0" HOTPLUG_INTERFACES="ath0" #ARGS="-q -f -u0 -d10 -w -I" ARGS="-q -u0 -d10 -w" SUSPEND_ACTION="stop"
Alas using libldap2 when it is linked against libgnutls13 can be damn slow. Using GQ or ldapvi can result in an incredibly slow operation when using TLS/SSL connections.
'strace'ing the process and munching the sourcecode for the Debian libldap2 package reveals a lot and it turns out that before starting the TLS/SSL connection every file in the directory specified by TLS_CACERTDIR variable is each loaded, each file can take as much as half a second to load as the function gnutls_certificate_set_x509_trust_file is really slow on long lists.
On a default install of Debian this is not a problem however if you install ca-certificates (highly recommended) then around 100 certificates are placed in this directory along with 100 softlinks for the digest and a huge single certificate file that contains all of the above 100 certificates anyway. The result, 300 certificates are parsed instead of 100, the other 200 being duplicates of the first 100!
By reading the advice in Debian Bug #225597 I found out that the following makes for a very reasonable '/etc/ldap/ldap.conf' file:
TLS_CACERT /etc/ssl/certs/ca-certificates.crt TLS_CACERTDIR /etc/ssl/certs/local TLS_REQCERT demand
The '/etc/ssl/certs/local/' directory lets you add your own local CA's easily whilst keeping the whole thing nice and fast. To create the softlink's correctly you type in the '/etc/ssl/certs/local/' directory something like:
ln -s ca.pem `openssl x509 -noout -hash -in ca.pem`.0
N.B. Whilst using SSL/TLS you might find 'gq' does not work when doing some searching through branches, I found by applying the patch referenced in Debian Bug #364614 (also the same as Debian Bug #262539) and installing the 'libldap2' DEB built from it fixed the problem.
Well annoyingly for a laptop etch does not have dynticks (as it uses kernel 2.6.18) and so power saving is a little annoying. Fortunately etch-backports can be called upon to provide a kernel with dynticks support.
/etc/apt/sources.list.d/backports.list
#deb http://www.backports.org/debian etch-backports main # my local mirror (find a suitable one for your own needs) deb http://backports.sipo.nl etch-backports main
/etc/apt/preferences
Package: linux-image-2.6-686 powertop Pin: release a=etch-backports Pin-Priority: 999 Package: * Pin: release a=etch Pin-Priority: 900
Once you have done this you should find that you can update to a more recent kernel and also install the powertop to find out what is soaking up your battery life.
N.B. you will find the old kernel kicking around still which you should remove with something like:
# aptitude remove linux-image-2.6.18-5-686 linux-kernel-headers
If you have any 'externel' kernel modules compiled, such as from the debian 'madwifi' package, you will need to recompile these (install the 'linux-headers-2.6.22-3-686' package for the headers).
One hugely under used feature of PAM is the ability to add any used to additional groups depending on if they logged into the local console or not. Why would you want to do this, well usually you only want local users to be able to tinker with the audio card and have DRI permission for X. You might be inclinded to only want to let local users access the floppy and CD rom drive devices too.
This is a pretty trivial thing to configure:
/etc/security/group.conf
login; vc/*; *; Al0000-2400; audio,floppy,video,cdrom,plugdev,powerdev wdm; :*; *; Al0000-2400; audio,floppy,video,cdrom,plugdev,powerdev
/etc/security/common-auth
This file should really just look like:
auth required pam_unix.so nullok_secure auth optional pam_group.so