]> pere.pagekite.me Git - homepage.git/commitdiff
Første utkast.
authorPetter Reinholdtsen <pere@hungry.com>
Mon, 9 Aug 2010 17:38:40 +0000 (17:38 +0000)
committerPetter Reinholdtsen <pere@hungry.com>
Mon, 9 Aug 2010 17:38:40 +0000 (17:38 +0000)
blog/data/2010-08-09-edu-autoconf.txt [new file with mode: 0644]

diff --git a/blog/data/2010-08-09-edu-autoconf.txt b/blog/data/2010-08-09-edu-autoconf.txt
new file mode 100644 (file)
index 0000000..6c1c0ee
--- /dev/null
@@ -0,0 +1,110 @@
+Title: No hardcoded config on Debian Edu clients
+Tags: english, nuug, debian edu
+Date: 2010-08-09 20:00
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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:</p>
+
+<ul>
+<li>IP address/netmask and DNS server.</li>
+<li>Web proxy URL.</li>
+<li>LDAP server for NSS directory information (user, group, etc).</li>
+<li>Kerberos server for PAM password checking.</li>
+<li>SMB mount point to access the network home directory. (*)</li>
+<li>Central syslog server to send syslog messages to. (*)</li>
+<li>Sitesummary collector URL to submit info to central server. (*)</li>
+</ul>
+
+<p>(Hm, did I forget anything?  Let me knew if I did.)</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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?</p>
+
+<p>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. :)</p>
+
+<p>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.</p>
+
+<p>If you want to help out with implementing these things for Debian
+Edu, please contact us on debian-edu@lists.debian.org.</p>