X-Git-Url: https://pere.pagekite.me/gitweb/homepage.git/blobdiff_plain/3d495cea0d027fa819e77bc725cc975a240e6c8e..2115f37ef137d707943a1a5a0f6d0ba6df630cee:/blog/index.rss diff --git a/blog/index.rss b/blog/index.rss index 38857dcdbd..8f2094baa9 100644 --- a/blog/index.rss +++ b/blog/index.rss @@ -6,6 +6,126 @@ http://people.skolelinux.org/pere/blog/ + + No hardcoded config on Debian Edu clients + http://people.skolelinux.org/pere/blog/No_hardcoded_config_on_Debian_Edu_clients.html + http://people.skolelinux.org/pere/blog/No_hardcoded_config_on_Debian_Edu_clients.html + Mon, 9 Aug 2010 20:15:00 +0200 + +<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 to be +mostly done, and the clients seem to work just fine with dynamically +generated configuration.</p> + +<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 +fetched via DHCP and DNS. The roaming workstation is now ready for +use.</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> +<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 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 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 +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>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 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 +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 +Edu, please contact us on debian-edu@lists.debian.org.</p> + + + Testing if a file system can be used for home directories... http://people.skolelinux.org/pere/blog/Testing_if_a_file_system_can_be_used_for_home_directories___.html @@ -931,71 +1051,5 @@ auxiliary object class.</p> - - Combining PowerDNS and ISC DHCP LDAP objects - http://people.skolelinux.org/pere/blog/Combining_PowerDNS_and_ISC_DHCP_LDAP_objects.html - http://people.skolelinux.org/pere/blog/Combining_PowerDNS_and_ISC_DHCP_LDAP_objects.html - Wed, 14 Jul 2010 23:45:00 +0200 - -<p>For a while now, I have wanted to find a way to change the DNS and -DHCP services in Debian Edu to use the same LDAP objects for a given -computer, to avoid the possibility of having a inconsistent state for -a computer in LDAP (as in DHCP but no DNS entry or the other way -around) and make it easier to add computers to LDAP.</p> - -<p>I've looked at how powerdns and dhcpd is using LDAP, and using this -information finally found a solution that seem to work.</p> - -<p>The old setup required three LDAP objects for a given computer. -One forward DNS entry, one reverse DNS entry and one DHCP entry. If -we switch powerdns to use its strict LDAP method (ldap-method=strict -in pdns-debian-edu.conf), the forward and reverse DNS entries are -merged into one while making it impossible to transfer the reverse map -to a slave DNS server.</p> - -<p>If we also replace the object class used to get the DNS related -attributes to one allowing these attributes to be combined with the -dhcphost object class, we can merge the DNS and DHCP entries into one. -I've written such object class in the dnsdomainaux.schema file (need -proper OIDs, but that is a minor issue), and tested the setup. It -seem to work.</p> - -<p>With this test setup in place, we can get away with one LDAP object -for both DNS and DHCP, and even the LTSP configuration I suggested in -an earlier email. The combined LDAP object will look something like -this:</p> - -<blockquote><pre> - dn: cn=hostname,cn=group1,cn=THINCLIENTS,cn=DHCP Config,dc=skole,dc=skolelinux,dc=no - cn: hostname - objectClass: dhcphost - objectclass: domainrelatedobject - objectclass: dnsdomainaux - associateddomain: hostname.intern - arecord: 10.11.12.13 - dhcphwaddress: ethernet 00:00:00:00:00:00 - dhcpstatements: fixed-address hostname - ldapconfigsound: Y -</pre></blockquote> - -<p>The DNS server uses the associateddomain and arecord entries, while -the DHCP server uses the dhcphwaddress and dhcpstatements entries -before asking DNS to resolve the fixed-adddress. LTSP will use -dhcphwaddress or associateddomain and the ldapconfig* attributes.</p> - -<p>I am not yet sure if I can get the DHCP server to look for its -dhcphost in a different location, to allow us to put the objects -outside the "DHCP Config" subtree, but hope to figure out a way to do -that. If I can't figure out a way to do that, we can still get rid of -the hosts subtree and move all its content into the DHCP Config tree -(which probably should be renamed to be more related to the new -content. I suspect cn=dnsdhcp,ou=services or something like that -might be a good place to put it.</p> - -<p>If you want to help out with implementing this for Debian Edu, -please contact us on debian-edu@lists.debian.org.</p> - - -