From: Petter Reinholdtsen Date: Mon, 9 Aug 2010 17:38:40 +0000 (+0000) Subject: Første utkast. X-Git-Url: https://pere.pagekite.me/gitweb/homepage.git/commitdiff_plain/b599a2fb4785923f2534abe59abbe7c38240e178 Første utkast. --- diff --git a/blog/data/2010-08-09-edu-autoconf.txt b/blog/data/2010-08-09-edu-autoconf.txt new file mode 100644 index 0000000000..6c1c0ee84f --- /dev/null +++ b/blog/data/2010-08-09-edu-autoconf.txt @@ -0,0 +1,110 @@ +Title: No hardcoded config on Debian Edu clients +Tags: english, nuug, debian edu +Date: 2010-08-09 20:00 + +

As reported earlier, 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 mostly +done, and the clients seem to work just fine with dynamically +generated configuration.

+ +

What is the point, you might ask. I'll answer by describing what +happen 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), accepting 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 go ahead and do its thing, and after around 50 minutes it +reports that it is done. I press enter to finish the installation, +and the machine reboots into KDE. When The machine is ready and kdm +ask for login information, I enter my university username and +password, am told my kdm that a local home directory have 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 configuration, and all the +required configuration was dynamically detected using information +fetched via DHCP and DNS. Without any university specific +configuration being asked for by the installer, the roaming +workstation is ready for use directly after installation.

+ +

How as this done, you might wonder. First of all, here is the list +of things to configure on the client to get it working properly out of +the box:

+ + + +

(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 wanted to provide central storage and allowing system +administrators to track their machines. Since yesterday, everything +but the sitesummary collector URL is dynamically discovered at +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 stop using the Debian Edu proxy when it +is moved outside the Debian Edu network, and instead use any local +proxy present on the new network when it move around.

+ +

The LDAP, Kerberos and syslog server and configuration is generated +using DNS information at boot. First the installer look for a host +named ldap in the current DNS domain. If not found, it look for +_ldap._tcp SRV records in DNS instead. If a LDAP server is found, its +root DSE entry is requested and the attributes namingContexts and +defaultNamingContext are used to determine the LDAP base to use. 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 object is used +as the LDAP base for NSS. For Kerberos, a similar search is done by +first looking for a host named kerberos, and then for the +_kerberos._tcp SRV record is consulted. 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 syslog server, the hosts +syslog and loghost is searched for, and the _syslog._udp SRV record is +consulted if no such host is found. This algorithm work for both +Debian Edu and the University of Oslo. A similar strategy would work +for locating the sitesummary server. I decided to store these +settings during installation, to make sure moving to a different +network do not change the set of user being allowed to log nor the +password required to log in. Those settings should be cached by sssd +when the user log in on the Debian Edu network, and 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 users SMB mount point for the network home directory is located +when the user log in for the first time. The LDAP server is consulted +to look for the users 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 work for both Debian edu +and the University of Oslo too. Perhaps there are better attributes +to use or a better algorithm that work for more sites, but this can 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 +the existing network infrastructure, but I have not tested this +yet.

+ +

If you want to help out with implementing these things for Debian +Edu, please contact us on debian-edu@lists.debian.org.