blog/data/2010-08-09-edu-autoconf.txt

   1 Title: No hardcoded config on Debian Edu clients
   2 Tags: english, nuug, debian edu
   3 Date: 2010-08-09 20:15
   4
   5 <p>As reported earlier, the last few days I have looked at how Debian
   6 Edu clients are configured, and tried to get rid of all hardcoded
   7 configuration settings on the clients.  I believe the work to be
   8 mostly done, and the clients seem to work just fine with dynamically
   9 generated configuration.</p>
  10
  11 <p>What is the point, you might ask?  The point is to allow a Debian
  12 Edu desktop to integrate into an existing network infrastructure
  13 without any manual configuration.</p>
  14
  15 <p>This is what happens when installing a Debian Edu client here at
  16 the University of Oslo using PXE.  With the PXE installation, I am
  17 asked for language (Norwegian Bokmål), locality (Norway) and keyboard
  18 layout (no-latin1), Debian Edu profile (Roaming Workstation), if I
  19 accept to reformat the hard drive (yes), if I want to submit info to
  20 popcon.debian.org (no) and root password (secret).  After answering
  21 these questions, the installer goes ahead and does its thing, and
  22 after around 50 minutes it is done.  I press enter to finish the
  23 installation, and the machine reboots into KDE.  When the machine is
  24 ready and kdm asks for login information, I enter my university
  25 username and password, am told by kdm that a local home directory has
  26 been created and that I must log in again, and finally log in with the
  27 same username and password to the KDE 4.4 desktop.  At no point during
  28 this process did it ask for university specific settings, and all the
  29 required configuration was dynamically detected using information
  30 fetched via DHCP and DNS.  The roaming workstation is now ready for
  31 use.</p>
  32
  33 <p>How was this done, you might wonder?  First of all, here is the
  34 list of things that need to be configured on the client to get it
  35 working properly out of the box:</p>
  36
  37 <ul>
  38 <li>IP address/netmask and DNS server.</li>
  39 <li>Web proxy URL.</li>
  40 <li>LDAP server for NSS directory information (user, group, etc).</li>
  41 <li>Kerberos server for PAM password checking.</li>
  42 <li>SMB mount point to access the network home directory. (*)</li>
  43 <li>Central syslog server to send syslog messages to. (*)</li>
  44 <li>Sitesummary collector URL to submit info to central server. (*)</li>
  45 </ul>
  46
  47 <p>(Hm, did I forget anything?  Let me knew if I did.)</p>
  48
  49 <p>The points marked (*) are not required to be able to use the
  50 machine, but needed to provide central storage and allowing system
  51 administrators to track their machines.  Since yesterday, everything
  52 but the sitesummary collector URL is dynamically discovered at boot
  53 and installation time in the svn version of Debian Edu.</p>
  54
  55 <p>The IP and DNS setup is fetched during boot using DHCP as usual.
  56 When a DHCP update arrives, the proxy setup is updated by looking for
  57 http://wpat/wpad.dat and using the content of this WPAD file to
  58 configure the http and ftp proxy in /etc/environment and
  59 /etc/apt/apt.conf.  I decided to update the proxy setup using a DHCP
  60 hook to ensure that the client stops using the Debian Edu proxy when
  61 it is moved outside the Debian Edu network, and instead uses any local
  62 proxy present on the new network when it moves around.</p>
  63
  64 <p>The DNS names of the LDAP, Kerberos and syslog server and related
  65 configuration are generated using DNS information at boot.  First the
  66 installer looks for a host named ldap in the current DNS domain.  If
  67 not found, it looks for _ldap._tcp SRV records in DNS instead.  If an
  68 LDAP server is found, its root DSE entry is requested and the
  69 attributes namingContexts and defaultNamingContext are used to
  70 determine which LDAP base to use for NSS.  If there are several
  71 namingContexts attibutes and the defaultNamingContext is present, that
  72 LDAP subtree is used as the base.  If defaultNamingContext is missing,
  73 the subtrees listed as namingContexts are searched in sequence for any
  74 object with class posixAccount or posixGroup, and the first one with
  75 such an object is used as the LDAP base.  For Kerberos, a similar
  76 search is done by first looking for a host named kerberos, and then
  77 for the _kerberos._tcp SRV record.  I've been unable to find a way to
  78 look up the Kerberos realm, so for this the upper case string of the
  79 current DNS domain is used.</p>
  80
  81 <p>For the syslog server, the hosts syslog and loghost are searched
  82 for, and the _syslog._udp SRV record is consulted if no such host is
  83 found.  This algorithm works for both Debian Edu and the University of
  84 Oslo.  A similar strategy would work for locating the sitesummary
  85 server, but have not been implemented yet.  I decided to fetch and
  86 save these settings during installation, to make sure moving to a
  87 different network does not change the set of users being allowed to
  88 log in nor the passwords required to log in.  Usernames and passwords
  89 will be cached by sssd when the user logs in on the Debian Edu
  90 network, and will not change as the laptop move around.  For a
  91 non-roaming machine, there is no caching, but given that it is
  92 supposed to stay in place it should not matter much.  Perhaps we
  93 should switch those to use sssd too?</p>
  94
  95 <p>The user's SMB mount point for the network home directory is
  96 located when the user logs in for the first time.  The LDAP server is
  97 consulted to look for the user's LDAP object and the sambaHomePath
  98 attribute is used if found.  If it isn't found, the home directory
  99 path fetched from NSS is used instead.  Assuming the path is of the
 100 form /site/server/directory/username, the second part is looked up in
 101 DNS and used to generate a SMB URL of the form
 102 smb://server.domain/username.  This algorithm works for both Debian
 103 edu and the University of Oslo.  Perhaps there are better attributes
 104 to use or a better algorithm that works for more sites, but this will
 105 do for now. :)</p>
 106
 107 <p>This work should make it easier to integrate the Debian Edu clients
 108 into any LDAP/Kerberos infrastructure, and make the current setup even
 109 more flexible than before.  I suspect it will also work for thin
 110 client servers, allowing one to easily set up LTSP and hook it into a
 111 existing network infrastructure, but I have not had time to test this
 112 yet.</p>
 113
 114 <p>If you want to help out with implementing these things for Debian
 115 Edu, please contact us on debian-edu@lists.debian.org.</p>
 116
 117 <p>Update 2010-08-09: Simon Farnsworth gave me a heads-up on how to
 118 detect Kerberos realm from DNS, by looking for _kerberos TXT entries
 119 before falling back to the upper case DNS domain name.  Will have to
 120 implement it for Debian Edu. :)</p>