Bedre tekst.

diff --git a/blog/data/2010-08-09-edu-autoconf.txt b/blog/data/2010-08-09-edu-autoconf.txt
index 6c1c0ee84f682dabe21a142fbdb64c97ce97a3c4..0557ffc00b9abca918f07bce3b8a5cfdf4a7198b 100644 (file)
--- a/blog/data/2010-08-09-edu-autoconf.txt
+++ b/blog/data/2010-08-09-edu-autoconf.txt
@@ -4,33 +4,35 @@ 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
 
 <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
+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.</p>
 
 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
+<p>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.</p>
+
+<p>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
 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>
+fetched via DHCP and DNS.  The roaming workstation is now ready for
+use.</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>
+<p>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:</p>

 
 <ul>
 <li>IP address/netmask and DNS server.</li>
 
 <ul>
 <li>IP address/netmask and DNS server.</li>


@@ -45,65 +47,68 @@ the box:</p>
 <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
 <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
+machine, but needed to provide central storage and allowing system

 administrators to track their machines.  Since yesterday, everything
 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>
+but the sitesummary collector URL is dynamically discovered at boot
+and 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
 
 <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>
+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.</p>
+
+<p>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.</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>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?</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>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. :)</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
 
 <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
+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.</p>
 
 <p>If you want to help out with implementing these things for Debian
 yet.</p>
 
 <p>If you want to help out with implementing these things for Debian