No hardcoded config on Debian Edu clients
The last few days I have looked at how Debian Edu clients are
configured, and tried to get rid of all hardcoded configuration
settings on the clients. I believe the work to be mostly done, and the
clients seem to work just fine with dynamically generated
configuration.
What is the point, you might ask? The point is to allow a Debian Edu
desktop to integrate into an existing network infrastructure without
any manual configuration.
This is what happens when installing a Debian Edu client here at the
University of Oslo using PXE. With the PXE installation, I am asked
for language (Norwegian Bokmål), locality (Norway) and keyboard layout
(no-latin1), Debian Edu profile (Roaming Workstation), if I accept to
reformat the hard drive (yes), if I want to submit info to
popcon.debian.org (no) and root password (secret). After answering
these questions, the installer goes ahead and does its thing, and
after around 50 minutes it is done. I press enter to finish the
installation, and the machine reboots into KDE. When the machine is
ready and kdm asks for login information, I enter my university
username and password, am told by kdm that a local home directory has
been created and that I must log in again, and finally log in with the
same username and password to the KDE 4.4 desktop. At no point during
this process did it ask for university specific settings, and all the
required configuration was dynamically detected using information
fetched via DHCP and DNS. The roaming workstation is now ready for
use.
How was this done, you might wonder? First of all, here is the list of
things that need to be configured on the client to get it working
properly out of the box:
* IP address/netmask and DNS server.
* Web proxy URL.
* LDAP server for NSS directory information (user, group, etc).
* Kerberos server for PAM password checking.
* SMB mount point to access the network home directory. (*)
* Central syslog server to send syslog messages to. (*)
* Sitesummary collector URL to submit info to central server. (*)
(Hm, did I forget anything? Let me knew if I did.)
The points marked (*) are not required to be able to use the machine,
but needed to provide central storage and allowing system
administrators to track their machines. Since yesterday, everything
but the sitesummary collector URL is dynamically discovered at boot
and installation time in the svn version of Debian Edu.
The IP and DNS setup is fetched during boot using DHCP as usual. When
a DHCP update arrives, the proxy setup is updated by looking for
http://wpat/wpad.dat and using the content of this WPAD file to
configure the http and ftp proxy in /etc/environment and
/etc/apt/apt.conf. I decided to update the proxy setup using a DHCP
hook to ensure that the client stops using the Debian Edu proxy when
it is moved outside the Debian Edu network, and instead uses any local
proxy present on the new network when it moves around.
The DNS names of the LDAP, Kerberos and syslog server and related
configuration are generated using DNS information at boot. First the
installer looks for a host named ldap in the current DNS domain. If
not found, it looks for _ldap._tcp SRV records in DNS instead. If an
LDAP server is found, its root DSE entry is requested and the
attributes namingContexts and defaultNamingContext are used to
determine which LDAP base to use for NSS. If there are several
namingContexts attibutes and the defaultNamingContext is present, that
LDAP subtree is used as the base. If defaultNamingContext is missing,
the subtrees listed as namingContexts are searched in sequence for any
object with class posixAccount or posixGroup, and the first one with
such an object is used as the LDAP base. For Kerberos, a similar
search is done by first looking for a host named kerberos, and then
for the _kerberos._tcp SRV record. I've been unable to find a way to
look up the Kerberos realm, so for this the upper case string of the
current DNS domain is used.
For the syslog server, the hosts syslog and loghost are searched for,
and the _syslog._udp SRV record is consulted if no such host is found.
This algorithm works for both Debian Edu and the University of Oslo. A
similar strategy would work for locating the sitesummary server, but
have not been implemented yet. I decided to fetch and save these
settings during installation, to make sure moving to a different
network does not change the set of users being allowed to log in nor
the passwords required to log in. Usernames and passwords will be
cached by sssd when the user logs in on the Debian Edu network, and
will not change as the laptop move around. For a non-roaming machine,
there is no caching, but given that it is supposed to stay in place it
should not matter much. Perhaps we should switch those to use sssd
too?
The user's SMB mount point for the network home directory is located
when the user logs in for the first time. The LDAP server is consulted
to look for the user's LDAP object and the sambaHomePath attribute is
used if found. If it isn't found, the home directory path fetched from
NSS is used instead. Assuming the path is of the form
/site/server/directory/username, the second part is looked up in DNS
and used to generate a SMB URL of the form
smb://server.domain/username. This algorithm works for both Debian edu
and the University of Oslo. Perhaps there are better attributes to use
or a better algorithm that works for more sites, but this will do for
now. :)
This work should make it easier to integrate the Debian Edu clients
into any LDAP/Kerberos infrastructure, and make the current setup even
more flexible than before. I suspect it will also work for thin client
servers, allowing one to easily set up LTSP and hook it into a existing
network infrastructure, but I have not had time to test this yet.
Happy hacking,
--
Petter Reinholdtsen
Reply to: