Petter Reinholdtsen

Autodetecting Client setup for roaming workstations in Debian Edu
2010-08-07 14:45

A few days ago, I tried to install a Roaming workation profile from Debian Edu/Squeeze while on the university network here at the University of Oslo, and noticed how much had to change to get it operational using the university infrastructure. It was fairly easy, but it occured to me that Debian Edu would improve a lot if I could get the client to connect without any changes at all, and thus let the client configure itself during installation and first boot to use the infrastructure around it. Now I am a huge step further along that road.

With our current squeeze-test packages, I can select the roaming workstation profile and get a working laptop connecting to the university LDAP server for user and group and our active directory servers for Kerberos authentication. All this without any configuration at all during installation. My users home directory got a bookmark in the KDE menu to mount it via SMB, with the correct URL. In short, openldap and sssd is correctly configured. In addition to this, the client look for http://wpad/wpad.dat to configure a web proxy, and when it fail to find it no proxy settings are stored in /etc/environment and /etc/apt/apt.conf. Iceweasel and KDE is configured to look for the same wpad configuration and also do not use a proxy when at the university network. If the machine is moved to a network with such wpad setup, it would automatically use it when DHCP gave it a IP address.

The LDAP server is located using DNS, by first looking for the DNS entry ldap.$domain. If this do not exist, it look for the _ldap._tcp.$domain SRV records and use the first one as the LDAP server. Next, it connects to the LDAP server and search all namingContexts entries for posixAccount or posixGroup objects, and pick the first one as the LDAP base. For Kerberos, a similar algorithm is used to locate the LDAP server, and the realm is the uppercase version of $domain.

So, what is not working, you might ask. SMB mounting my home directory do not work. No idea why, but suspected the incorrect Kerberos settings in /etc/krb5.conf and /etc/samba/smb.conf might be the cause. These are not properly configured during installation, and had to be hand-edited to get the correct Kerberos realm and server, but SMB mounting still do not work. :(

With this automatic configuration in place, I expect a Debian Edu roaming profile installation would be able to automatically detect and connect to any site using LDAP and Kerberos for NSS directory and PAM authentication. It should also work out of the box in a Active Directory environment providing posixAccount and posixGroup objects with UID and GID values.

If you want to help out with implementing these things for Debian Edu, please contact us on debian-edu@lists.debian.org.

Tags: debian edu, english, nuug.
Debian Edu roaming workstation - at the university of Oslo
2010-08-03 23:30

The new roaming workstation profile in Debian Edu/Squeeze is fairly similar to the laptop setup am I working on using Ubuntu for the University of Oslo, and just for the heck of it, I tested today how hard it would be to integrate that profile into the university infrastructure. In this case, it is the university LDAP server, Active Directory Kerberos server and SMB mounting from the Netapp file servers.

I was pleasantly surprised that the only three files needed to be changed (/etc/sssd/sssd.conf, /etc/ldap.conf and /etc/mklocaluser.d/20-debian-edu-config) and one file had to be added (/usr/share/perl5/Debian/Edu_Local.pm), to get the client working. Most of the changes were to get the client to use the university LDAP for NSS and Kerberos server for PAM, but one was to change a hard coded DNS domain name in the mklocaluser hook from .intern to .uio.no.

This testing was so encouraging, that I went ahead and adjusted the Debian Edu scripts and setup in subversion to centralise the roaming workstation setup a bit more and avoid the hardcoded DNS domain name, so that when I test this tomorrow, I expect to get away with modifying only /etc/sssd/sssd.conf and /etc/ldap.conf to get it to use the university servers.

My goal is to get the clients to have no hardcoded settings and fetch all their initial setup during installation and first boot, to allow them to be inserted also into environments where the default setup in Debian Edu has been changed or as with the university, where the environment is different but provides the protocols Debian Edu uses.

Tags: debian edu, english, nuug.
Circular package dependencies harms apt recovery
2010-07-27 23:50

I discovered this while doing automated testing of upgrades from Debian Lenny to Squeeze. A few packages in Debian still got circular dependencies, and it is often claimed that apt and aptitude should be able to handle this just fine, but some times these dependency loops causes apt to fail.

An example is from todays upgrade of KDE using aptitude. In it, a bug in kdebase-workspace-data causes perl-modules to fail to upgrade. The cause is simple. If a package fail to unpack, then only part of packages with the circular dependency might end up being unpacked when unpacking aborts, and the ones already unpacked will fail to configure in the recovery phase because its dependencies are unavailable.

In this log, the problem manifest itself with this error:

dpkg: dependency problems prevent configuration of perl-modules:
 perl-modules depends on perl (>= 5.10.1-1); however:
  Version of perl on system is 5.10.0-19lenny2.
dpkg: error processing perl-modules (--configure):
 dependency problems - leaving unconfigured

The perl/perl-modules circular dependency is already reported as a bug, and will hopefully be solved as soon as possible, but it is not the only one, and each one of these loops in the dependency tree can cause similar failures. Of course, they only occur when there are bugs in other packages causing the unpacking to fail, but it is rather nasty when the failure of one package causes the problem to become worse because of dependency loops.

Thanks to the tireless effort by Bill Allombert, the number of circular dependencies left in Debian is dropping, and perhaps it will reach zero one day. :)

Todays testing also exposed a bug in update-notifier and different behaviour between apt-get and aptitude, the latter possibly caused by some circular dependency. Reported both to BTS to try to get someone to look at it.

Tags: debian, english, nuug.
First Debian Edu test release (alpha0) based on Squeeze is released
2010-07-27 17:45

I just posted this announcement culminating several months of work with the next Debian Edu release. Not nearly done, but one major step completed.

This is the first test release based on Squeeze. The focus of this release is to test the user application selection. To have a look, install the standalone profile and let the developers know if the set of installed packages i.e. applications should be modified. If some user application is missing, or if there are some applications that no longer make sense to be included in Debian Edu, please let us know. Also, if a useful application is missing the translation for your language of choice, please let us know too.

In addition, feedback and help to polish the desktop (menus, artwork, starters, etc.) is appreciated. We would like to ship a nice and handy KDE4 desktop targeted for schools out of the box.

The other profiles should be installable, but there is a lot more work left to be done before they are ready, so do not expect to much.

Changes compared to the lenny based version

  • Everything from Debian Squeeze
    • Desktop environment KDE 4.4 => the new KDE desktop in combination with some new artwork
    • Web browser Iceweasel 3.5
    • OpenOffice.org 3.2
    • Educational toolbox GCompris 9.3
    • Music creator Rosegarden 10.04.2
    • Image editor Gimp 2.6.10
    • Virtual universe Celestia 1.6.0
    • Virtual stargazer Stellarium 0.10.4
    • 3D modeler Blender 2.49.2 (new application)
    • Video editor Kdenlive 0.7.7 (new application)
  • Now using Kerberos for password checking (migration not finished). Enabled for:
    • PAM
    • LDAP
    • IMAP
    • SMTP (sender verification)
  • New experimental roaming workstation profile for laptops.
  • Show welcome page to users when they first log in. The URL is fetched from LDAP.
  • New LXDE desktop option, in addition to KDE (default) and Gnome.
  • General cleanup (not finished)

The following features are not working as they should

  • No web based administration tool for creating users and groups. The scripts ldap-createuser-krb and ldap-add-user-to-group can be used for testing.
  • DVD installs are missing debian-installer images for the PXE boot, and do not set up the PXE menu on eth0 because of this. LTSP clients should still boot from eth1 on thin client servers.
  • The restructured KDE menu is not implemented.
  • The LDAP server setup need to be reviewed for security.
  • The LDAP directory structure need to be reworked.
  • Different sets of packages are installed when using the DVD and the netinst CD. More packages are installed using the netinst CD.
  • The jackd package fail to install. This is believed to be caused by some ongoing transition, and hopefully should be solved soon. The jackd1 package can be installed manually for those that need it.
  • Some packages lack translations. See http://wiki.debian.org/DebianEdu/Status/Squeeze for updated status, and help out with translations.

To download this multiarch netinstall release you can use

To download this multiarch dvd release you can use

There is no source DVD available yet. It will be prepared when we get closer to the final release.

The MD5SUM of these images are

  • 3dbf45d59f42a53518b6e3c9ec3b5eb6 debian-edu-6.0.0+edua0-CD.iso
  • 22f2cbfce281d1c6e478be452638675d debian-edu-6.0.0+edua0-DVD.iso

The SHA1SUM of these images are

  • c53d1b69b40cf37cd27aefaf33f6f6a3821bedf0 debian-edu-6.0.0+edua0-CD.iso
  • 2ec29d7db676d59d32197b05c277ffe16348376c debian-edu-6.0.0+edua0-DVD.iso

How to report bugs: http://wiki.debian.org/DebianEdu/HowTo/ReportBugsInBugzilla

Please direct replies to debian-edu@lists.debian.org

Tags: debian edu, english, nuug.
One step closer to single signon in Debian Edu
2010-07-25 10:00

The last few months me and the other Debian Edu developers have been working hard to get the Debian/Squeeze based version of Debian Edu/Skolelinux into shape. This future version will use Kerberos for authentication, and services are slowly migrated to single signon, getting rid of password questions one at the time.

It will also feature a roaming workstation profile with local home directory, for laptops that are only some times on the Skolelinux network, and for this profile a shortcut is created in Gnome and KDE to gain access to the users home directory on the file server. This shortcut uses SMB at the moment, and yesterday I had time to test if SMB mounting had started working in KDE after we added the cifs-utils package. I was pleasantly surprised how well it worked.

Thanks to the recent changes to our samba configuration to get it to use Kerberos for authentication, there were no question about user password when mounting the SMB volume. A simple click on the shortcut in the KDE menu, and a window with the home directory popped up. :)

One step closer to a single signon solution out of the box in Debian Edu. We already had PAM, LDAP, IMAP and SMTP in place, and now also Samba. Next step is Cups and hopefully also NFS.

We had planned a alpha0 release of Debian Edu for today, but thanks to the autobuilder administrators for some architectures being slow to sign packages, we are still missing the fixed LTSP package we need for the release. It was uploaded three days ago with urgency=high, and if it had entered testing yesterday we would have been able to test it in time for a alpha0 release today. As the binaries for ia64 and powerpc still not uploaded to the Debian archive, we need to delay the alpha release another day.

If you want to help out with implementing Kerberos for Debian Edu, please contact us on debian-edu@lists.debian.org.

Tags: debian edu, english, nuug, sikkerhet.
Digitale restriksjonsmekanismer fikk meg til å slutte å kjøpe musikk
2010-07-22 23:50

For mange år siden slutte jeg å kjøpe musikk-CDer. Årsaken var at musikkbransjen var godt i gang med å selge platene sine med DRM som gjorde at jeg ikke fikk spilt av musikken jeg kjøpte på utstyret jeg hadde tilgjengelig, dvs. min datamaskin. Det var umulig å se på en plate om den var ødelagt eller ikke, og jeg hadde jo allerede en anseelig samling med plater, så jeg bestemme meg for å slutte å gi penger til en bransje som åpenbart ikke respekterte meg.

Jeg har mange titalls dager med musikk på CD i dag. Det meste er lagt i et stort arkiv som kan spilles av fra husets datamaskiner (har ikke rukket rippe alt). Jeg ser dermed ikke behovet for å skaffe mer musikk. De fleste av mine favoritter er i hus, og jeg er dermed godt fornøyd.

Hvis musikkbransjen ønsker mine penger, så må de demonstrere at de setter pris på meg som kunde, og ikke skremme meg bort med DRM og antydninger om at kundene er kriminelle.

Filmbransjen er like ille, men mens musikk gjerne varer lenge, er filmer mer ferskvare. Har dermed ikke helt sluttet å kjøpe filmer, men holder meg til DVD-filmer som kan spilles av på mine Linuxbokser. Kommer neppe til å ta i bruk Blueray, og ei heller de nye DRM-greiene «Ultraviolet» som be annonsert her om dagen.

Tags: fildeling, norsk, nuug, opphavsrett, personvern.
OpenStreetmap one step closer to having routing on its front page
2010-07-18 16:45

Thanks to todays opengeodata blog entry, I just discovered that the OpenStreetmap.org site have gotten support for calculating routes. The support is still experimental and only available from the development server, until more experience is gathered on the user interface and any scalability issues.

Earlier, the routing I knew about using the OpenStreetmap.org data was provided by Cloudmade, but having it on the main page is required to make everyone aware of the issue. I've had people reject Openstreetmap.org as a viable alternative for them because the front page lacked routing support, and I hope their needs will be catered for when routing show up on the www.openstreetmap.org front page.

Tags: english, kart, web.
What are they searching for - PowerDNS and ISC DHCP in LDAP
2010-07-17 21:00

This is a followup on my previous work on merging all the computer related LDAP objects in Debian Edu.

As a step to try to see if it possible to merge the DNS and DHCP LDAP objects, I have had a look at how the packages pdns-backend-ldap and dhcp3-server-ldap in Debian use the LDAP server. The two implementations are quite different in how they use LDAP.

To get this information, I started slapd with debugging enabled and dumped the debug output to a file to get the LDAP searches performed on a Debian Edu main-server. Here is a summary.

powerdns

Clues on how to set up PowerDNS to use a LDAP backend is available on the web.

PowerDNS have two modes of operation using LDAP as its backend. One "strict" mode where the forward and reverse DNS lookups are done using the same LDAP objects, and a "tree" mode where the forward and reverse entries are in two different subtrees in LDAP with a structure based on the DNS names, as in tjener.intern and 2.2.0.10.in-addr.arpa.

In tree mode, the server is set up to use a LDAP subtree as its base, and uses a "base" scoped search for the DNS name by adding "dc=tjener,dc=intern," to the base with a filter for "(associateddomain=tjener.intern)" for the forward entry and "dc=2,dc=2,dc=0,dc=10,dc=in-addr,dc=arpa," with a filter for "(associateddomain=2.2.0.10.in-addr.arpa)" for the reverse entry. For forward entries, it is looking for attributes named dnsttl, arecord, nsrecord, cnamerecord, soarecord, ptrrecord, hinforecord, mxrecord, txtrecord, rprecord, afsdbrecord, keyrecord, aaaarecord, locrecord, srvrecord, naptrrecord, kxrecord, certrecord, dsrecord, sshfprecord, ipseckeyrecord, rrsigrecord, nsecrecord, dnskeyrecord, dhcidrecord, spfrecord and modifytimestamp. For reverse entries it is looking for the attributes dnsttl, arecord, nsrecord, cnamerecord, soarecord, ptrrecord, hinforecord, mxrecord, txtrecord, rprecord, aaaarecord, locrecord, srvrecord, naptrrecord and modifytimestamp. The equivalent ldapsearch commands could look like this:

ldapsearch -h ldap \
  -b dc=tjener,dc=intern,ou=hosts,dc=skole,dc=skolelinux,dc=no \
  -s base -x '(associateddomain=tjener.intern)' dNSTTL aRecord nSRecord \
  cNAMERecord sOARecord pTRRecord hInfoRecord mXRecord tXTRecord \
  rPRecord aFSDBRecord KeyRecord aAAARecord lOCRecord sRVRecord \
  nAPTRRecord kXRecord certRecord dSRecord sSHFPRecord iPSecKeyRecord \
  rRSIGRecord nSECRecord dNSKeyRecord dHCIDRecord sPFRecord modifyTimestamp

ldapsearch -h ldap \
  -b dc=2,dc=2,dc=0,dc=10,dc=in-addr,dc=arpa,ou=hosts,dc=skole,dc=skolelinux,dc=no \
  -s base -x '(associateddomain=2.2.0.10.in-addr.arpa)'
  dnsttl, arecord, nsrecord, cnamerecord soarecord ptrrecord \
  hinforecord mxrecord txtrecord rprecord aaaarecord locrecord \
  srvrecord naptrrecord modifytimestamp

In Debian Edu/Lenny, the PowerDNS tree mode is used with ou=hosts,dc=skole,dc=skolelinux,dc=no as the base, and these are two example LDAP objects used there. In addition to these objects, the parent objects all th way up to ou=hosts,dc=skole,dc=skolelinux,dc=no also exist.

dn: dc=tjener,dc=intern,ou=hosts,dc=skole,dc=skolelinux,dc=no
objectclass: top
objectclass: dnsdomain
objectclass: domainrelatedobject
dc: tjener
arecord: 10.0.2.2
associateddomain: tjener.intern

dn: dc=2,dc=2,dc=0,dc=10,dc=in-addr,dc=arpa,ou=hosts,dc=skole,dc=skolelinux,dc=no
objectclass: top
objectclass: dnsdomain2
objectclass: domainrelatedobject
dc: 2
ptrrecord: tjener.intern
associateddomain: 2.2.0.10.in-addr.arpa

In strict mode, the server behaves differently. When looking for forward DNS entries, it is doing a "subtree" scoped search with the same base as in the tree mode for a object with filter "(associateddomain=tjener.intern)" and requests the attributes dnsttl, arecord, nsrecord, cnamerecord, soarecord, ptrrecord, hinforecord, mxrecord, txtrecord, rprecord, aaaarecord, locrecord, srvrecord, naptrrecord and modifytimestamp. For reverse entires it also do a subtree scoped search but this time the filter is "(arecord=10.0.2.2)" and the requested attributes are associateddomain, dnsttl and modifytimestamp. In short, in strict mode the objects with ptrrecord go away, and the arecord attribute in the forward object is used instead.

The forward and reverse searches can be simulated using ldapsearch like this:

ldapsearch -h ldap -b ou=hosts,dc=skole,dc=skolelinux,dc=no -s sub -x \
  '(associateddomain=tjener.intern)' dNSTTL aRecord nSRecord \
  cNAMERecord sOARecord pTRRecord hInfoRecord mXRecord tXTRecord \
  rPRecord aFSDBRecord KeyRecord aAAARecord lOCRecord sRVRecord \
  nAPTRRecord kXRecord certRecord dSRecord sSHFPRecord iPSecKeyRecord \
  rRSIGRecord nSECRecord dNSKeyRecord dHCIDRecord sPFRecord modifyTimestamp

ldapsearch -h ldap -b ou=hosts,dc=skole,dc=skolelinux,dc=no -s sub -x \
  '(arecord=10.0.2.2)' associateddomain dnsttl modifytimestamp

In addition to the forward and reverse searches , there is also a search for SOA records, which behave similar to the forward and reverse lookups.

A thing to note with the PowerDNS behaviour is that it do not specify any objectclass names, and instead look for the attributes it need to generate a DNS reply. This make it able to work with any objectclass that provide the needed attributes.

The attributes are normally provided in the cosine (RFC 1274) and dnsdomain2 schemas. The latter is used for reverse entries like ptrrecord and recent DNS additions like aaaarecord and srvrecord.

In Debian Edu, we have created DNS objects using the object classes dcobject (for dc), dnsdomain or dnsdomain2 (structural, for the DNS attributes) and domainrelatedobject (for associatedDomain). The use of structural object classes make it impossible to combine these classes with the object classes used by DHCP.

There are other schemas that could be used too, for example the dnszone structural object class used by Gosa and bind-sdb for the DNS attributes combined with the domainrelatedobject object class, but in this case some unused attributes would have to be included as well (zonename and relativedomainname).

My proposal for Debian Edu would be to switch PowerDNS to strict mode and not use any of the existing objectclasses (dnsdomain, dnsdomain2 and dnszone) when one want to combine the DNS information with DHCP information, and instead create a auxiliary object class defined something like this (using the attributes defined for dnsdomain and dnsdomain2 or dnszone):

objectclass ( some-oid NAME 'dnsDomainAux'
    SUP top
    AUXILIARY
    MAY ( ARecord $ MDRecord $ MXRecord $ NSRecord $ SOARecord $ CNAMERecord $
          DNSTTL $ DNSClass $ PTRRecord $ HINFORecord $ MINFORecord $
          TXTRecord $ SIGRecord $ KEYRecord $ AAAARecord $ LOCRecord $
          NXTRecord $ SRVRecord $ NAPTRRecord $ KXRecord $ CERTRecord $
          A6Record $ DNAMERecord
    ))

This will allow any object to become a DNS entry when combined with the domainrelatedobject object class, and allow any entity to include all the attributes PowerDNS wants. I've sent an email to the PowerDNS developers asking for their view on this schema and if they are interested in providing such schema with PowerDNS, and I hope my message will be accepted into their mailing list soon.

ISC dhcp

The DHCP server searches for specific objectclass and requests all the object attributes, and then uses the attributes it want. This make it harder to figure out exactly what attributes are used, but thanks to the working example in Debian Edu I can at least get an idea what is needed without having to read the source code.

In the DHCP server configuration, the LDAP base to use and the search filter to use to locate the correct dhcpServer entity is stored. These are the relevant entries from /etc/dhcp3/dhcpd.conf:

ldap-base-dn "dc=skole,dc=skolelinux,dc=no";
ldap-dhcp-server-cn "dhcp";

The DHCP server uses this information to nest all the DHCP configuration it need. The cn "dhcp" is located using the given LDAP base and the filter "(&(objectClass=dhcpServer)(cn=dhcp))". The search result is this entry:

dn: cn=dhcp,dc=skole,dc=skolelinux,dc=no
cn: dhcp
objectClass: top
objectClass: dhcpServer
dhcpServiceDN: cn=DHCP Config,dc=skole,dc=skolelinux,dc=no

The content of the dhcpServiceDN attribute is next used to locate the subtree with DHCP configuration. The DHCP configuration subtree base is located using a base scope search with base "cn=DHCP Config,dc=skole,dc=skolelinux,dc=no" and filter "(&(objectClass=dhcpService)(|(dhcpPrimaryDN=cn=dhcp,dc=skole,dc=skolelinux,dc=no)(dhcpSecondaryDN=cn=dhcp,dc=skole,dc=skolelinux,dc=no)))". The search result is this entry:

dn: cn=DHCP Config,dc=skole,dc=skolelinux,dc=no
cn: DHCP Config
objectClass: top
objectClass: dhcpService
objectClass: dhcpOptions
dhcpPrimaryDN: cn=dhcp, dc=skole,dc=skolelinux,dc=no
dhcpStatements: ddns-update-style none
dhcpStatements: authoritative
dhcpOption: smtp-server code 69 = array of ip-address
dhcpOption: www-server code 72 = array of ip-address
dhcpOption: wpad-url code 252 = text

Next, the entire subtree is processed, one level at the time. When all the DHCP configuration is loaded, it is ready to receive requests. The subtree in Debian Edu contain objects with object classes top/dhcpService/dhcpOptions, top/dhcpSharedNetwork/dhcpOptions, top/dhcpSubnet, top/dhcpGroup and top/dhcpHost. These provide options and information about netmasks, dynamic range etc. Leaving out the details here because it is not relevant for the focus of my investigation, which is to see if it is possible to merge dns and dhcp related computer objects.

When a DHCP request come in, LDAP is searched for the MAC address of the client (00:00:00:00:00:00 in this example), using a subtree scoped search with "cn=DHCP Config,dc=skole,dc=skolelinux,dc=no" as the base and "(&(objectClass=dhcpHost)(dhcpHWAddress=ethernet 00:00:00:00:00:00))" as the filter. This is what a host object look like:

dn: cn=hostname,cn=group1,cn=THINCLIENTS,cn=DHCP Config,dc=skole,dc=skolelinux,dc=no
cn: hostname
objectClass: top
objectClass: dhcpHost
dhcpHWAddress: ethernet 00:00:00:00:00:00
dhcpStatements: fixed-address hostname

There is less flexiblity in the way LDAP searches are done here. The object classes need to have fixed names, and the configuration need to be stored in a fairly specific LDAP structure. On the positive side, the invidiual dhcpHost entires can be anywhere without the DN pointed to by the dhcpServer entries. The latter should make it possible to group all host entries in a subtree next to the configuration entries, and this subtree can also be shared with the DNS server if the schema proposed above is combined with the dhcpHost structural object class.

Conclusion

The PowerDNS implementation seem to be very flexible when it come to which LDAP schemas to use. While its "tree" mode is rigid when it come to the the LDAP structure, the "strict" mode is very flexible, allowing DNS objects to be stored anywhere under the base cn specified in the configuration.

The DHCP implementation on the other hand is very inflexible, both regarding which LDAP schemas to use and which LDAP structure to use. I guess one could implement ones own schema, as long as the objectclasses and attributes have the names used, but this do not really help when the DHCP subtree need to have a fairly fixed structure.

Based on the observed behaviour, I suspect a LDAP structure like this might work for Debian Edu:

ou=services
  cn=machine-info (dhcpService) - dhcpServiceDN points here
    cn=dhcp (dhcpServer)
    cn=dhcp-internal (dhcpSharedNetwork/dhcpOptions)
      cn=10.0.2.0 (dhcpSubnet)
        cn=group1 (dhcpGroup/dhcpOptions)
    cn=dhcp-thinclients (dhcpSharedNetwork/dhcpOptions)
      cn=192.168.0.0 (dhcpSubnet)
        cn=group1 (dhcpGroup/dhcpOptions)
    ou=machines - PowerDNS base points here
      cn=hostname (dhcpHost/domainrelatedobject/dnsDomainAux)

This is not tested yet. If the DHCP server require the dhcpHost entries to be in the dhcpGroup subtrees, the entries can be stored there instead of a common machines subtree, and the PowerDNS base would have to be moved one level up to the machine-info subtree.

The combined object under the machines subtree would look something like this:

dn: dc=hostname,ou=machines,cn=machine-info,dc=skole,dc=skolelinux,dc=no
dc: hostname
objectClass: top
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.intern

One could even add the LTSP configuration associated with a given machine, as long as the required attributes are available in a auxiliary object class.

Tags: debian, debian edu, english, ldap, nuug.
Combining PowerDNS and ISC DHCP LDAP objects
2010-07-14 23:45

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.

I've looked at how powerdns and dhcpd is using LDAP, and using this information finally found a solution that seem to work.

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.

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.

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:

  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

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.

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.

If you want to help out with implementing this for Debian Edu, please contact us on debian-edu@lists.debian.org.

Tags: debian, debian edu, english, ldap, nuug.
Idea for storing LTSP configuration in LDAP
2010-07-11 22:00

Vagrant mentioned on IRC today that ltsp_config now support sourcing files from /usr/share/ltsp/ltsp_config.d/ on the thin clients, and that this can be used to fetch configuration from LDAP if Debian Edu choose to store configuration there.

Armed with this information, I got inspired and wrote a test module to get configuration from LDAP. The idea is to look up the MAC address of the client in LDAP, and look for attributes on the form ltspconfigsetting=value, and use this to export SETTING=value to the LTSP clients.

The goal is to be able to store the LTSP configuration attributes in a "computer" LDAP object used by both DNS and DHCP, and thus allowing us to store all information about a computer in one place.

This is a untested draft implementation, and I welcome feedback on this approach. A real LDAP schema for the ltspClientAux objectclass need to be written. Comments, suggestions, etc?

# Store in /opt/ltsp/$arch/usr/share/ltsp/ltsp_config.d/ldap-config
#
# Fetch LTSP client settings from LDAP based on MAC address
#
# Uses ethernet address as stored in the dhcpHost objectclass using
# the dhcpHWAddress attribute or ethernet address stored in the
# ieee802Device objectclass with the macAddress attribute.
#
# This module is written to be schema agnostic, and only depend on the
# existence of attribute names.
#
# The LTSP configuration variables are saved directly using a
# ltspConfig prefix and uppercasing the rest of the attribute name.
# To set the SERVER variable, set the ltspConfigServer attribute.
#
# Some LDAP schema should be created with all the relevant
# configuration settings.  Something like this should work:
# 
# objectclass ( 1.1.2.2 NAME 'ltspClientAux'
#     SUP top
#     AUXILIARY
#     MAY ( ltspConfigServer $ ltsConfigSound $ ... )

LDAPSERVER=$(debian-edu-ldapserver)
if [ "$LDAPSERVER" ] ; then
    LDAPBASE=$(debian-edu-ldapserver -b)
    for MAC in $(LANG=C ifconfig |grep -i hwaddr| awk '{print $5}'|sort -u) ; do
	filter="(|(dhcpHWAddress=ethernet $MAC)(macAddress=$MAC))"
	ldapsearch -h "$LDAPSERVER" -b "$LDAPBASE" -v -x "$filter" | \
	    grep '^ltspConfig' | while read attr value ; do
	    # Remove prefix and convert to upper case
	    attr=$(echo $attr | sed 's/^ltspConfig//i' | tr a-z A-Z)
	    # bass value on to clients
	    eval "$attr=$value; export $attr"
	done
    done
fi

I'm not sure this shell construction will work, because I suspect the while block might end up in a subshell causing the variables set there to not show up in ltsp-config, but if that is the case I am sure the code can be restructured to make sure the variables are passed on. I expect that can be solved with some testing. :)

If you want to help out with implementing this for Debian Edu, please contact us on debian-edu@lists.debian.org.

Update 2010-07-17: I am aware of another effort to store LTSP configuration in LDAP that was created around year 2000 by PC Xperience, Inc., 2000. I found its files on a personal home page over at redhat.com.

Tags: debian, debian edu, english, ldap, nuug.

RSS feed

Created by Chronicle v3.2