From: Petter Reinholdtsen 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
+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. 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
+ 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. 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:
+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:
(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 +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 -installation time in the svn version of Debian Edu.
+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 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.
+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.
-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?
+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 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. :)
+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 -the existing network infrastructure, but I have not tested this +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.
If you want to help out with implementing these things for Debian