[homepage.git] / blog / tags / ldap / ldap.rss

<?xml version="1.0" encoding="utf-8"?>
<rss version='2.0' xmlns:lj='http://www.livejournal.org/rss/lj/1.0/'>
        <channel>
                <title>Petter Reinholdtsen - Entries tagged ldap</title>
                <description>Entries tagged ldap</description>
                <link>http://people.skolelinux.org/pere/blog/</link>

        
        <item>
                <title>How to add extra storage servers in Debian Edu / Skolelinux</title>
                <link>http://people.skolelinux.org/pere/blog/How_to_add_extra_storage_servers_in_Debian_Edu___Skolelinux.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/How_to_add_extra_storage_servers_in_Debian_Edu___Skolelinux.html</guid>
                <pubDate>Fri, 14 Mar 2014 12:50:00 +0100</pubDate>
                <description>&lt;p&gt;On larger sites, it is useful to use a dedicated storage server for
storing user home directories and data.  The design for handling this
in Debian Edu / Skolelinux, is to update the automount rules in LDAP
and let the automount daemon on the clients take care of the rest.  I
was reminded about the need to document this better when one of the
customers of &lt;a href=&quot;http://www.slxdrift.no/&quot;&gt;Skolelinux Drift AS&lt;/a&gt;,
where I am on the board of directors, asked about how to do this.  The
steps to get this working are the following:&lt;/p&gt;

&lt;p&gt;&lt;ol&gt;

&lt;li&gt;Add new storage server in DNS.  I use nas-server.intern as the
example host here.&lt;/li&gt;

&lt;li&gt;Add automoun LDAP information about this server in LDAP, to allow
all clients to automatically mount it on reqeust.&lt;/li&gt;

&lt;li&gt;Add the relevant entries in tjener.intern:/etc/fstab, because
tjener.intern do not use automount to avoid mounting loops.&lt;/li&gt;

&lt;/ol&gt;&lt;/p&gt;

&lt;p&gt;DNS entries are added in GOsa², and not described here.  Follow the
&lt;a href=&quot;https://wiki.debian.org/DebianEdu/Documentation/Wheezy/GettingStarted&quot;&gt;instructions
in the manual&lt;/a&gt; (Machine Management with GOsa² in section etting
started).&lt;/p&gt;

&lt;p&gt;Ensure that the NFS export points on the server are exported to the
relevant subnets or machines:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;&lt;pre&gt;
root@tjener:~# showmount -e nas-server
Export list for nas-server:
/storage         10.0.0.0/8
root@tjener:~#
&lt;/pre&gt;&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;Here everything on the backbone network is granted access to the
/storage export.  With NFSv3 it is slightly better to limit it to
netgroup membership or single IP addresses to have some limits on the
NFS access.&lt;/p&gt;

&lt;p&gt;The next step is to update LDAP.  This can not be done using GOsa²,
because it lack a module for automount.  Instead, use ldapvi and add
the required LDAP objects using an editor.&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;&lt;pre&gt;
ldapvi --ldap-conf -ZD &#39;(cn=admin)&#39; -b ou=automount,dc=skole,dc=skolelinux,dc=no
&lt;/pre&gt;&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;When the editor show up, add the following LDAP objects at the
bottom of the document.  The &quot;/&amp;&quot; part in the last LDAP object is a
wild card matching everything the nas-server exports, removing the
need to list individual mount points in LDAP.&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;&lt;pre&gt;
add cn=nas-server,ou=auto.skole,ou=automount,dc=skole,dc=skolelinux,dc=no
objectClass: automount
cn: nas-server
automountInformation: -fstype=autofs --timeout=60 ldap:ou=auto.nas-server,ou=automount,dc=skole,dc=skolelinux,dc=no

add ou=auto.nas-server,ou=automount,dc=skole,dc=skolelinux,dc=no
objectClass: top
objectClass: automountMap
ou: auto.nas-server

add cn=/,ou=auto.nas-server,ou=automount,dc=skole,dc=skolelinux,dc=no
objectClass: automount
cn: /
automountInformation: -fstype=nfs,tcp,rsize=32768,wsize=32768,rw,intr,hard,nodev,nosuid,noatime nas-server.intern:/&amp;
&lt;/pre&gt;&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;The last step to remember is to mount the relevant mount points in
tjener.intern by adding them to /etc/fstab, creating the mount
directories using mkdir and running &quot;mount -a&quot; to mount them.&lt;/p&gt;

&lt;p&gt;When this is done, your users should be able to access the files on
the storage server directly by just visiting the
/tjener/nas-server/storage/ directory using any application on any
workstation, LTSP client or LTSP server.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>What are they searching for - PowerDNS and ISC DHCP in LDAP</title>
                <link>http://people.skolelinux.org/pere/blog/What_are_they_searching_for___PowerDNS_and_ISC_DHCP_in_LDAP.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/What_are_they_searching_for___PowerDNS_and_ISC_DHCP_in_LDAP.html</guid>
                <pubDate>Sat, 17 Jul 2010 21:00:00 +0200</pubDate>
                <description>&lt;p&gt;This is a
&lt;a href=&quot;http://people.skolelinux.org/pere/blog/Time_for_new__LDAP_schemas_replacing_RFC_2307_.html&quot;&gt;followup&lt;/a&gt;
on my
&lt;a href=&quot;http://people.skolelinux.org/pere/blog/Idea_for_a_change_to_LDAP_schemas_allowing_DNS_and_DHCP_info_to_be_combined_into_one_object.html&quot;&gt;previous
work&lt;/a&gt; on
&lt;a href=&quot;http://people.skolelinux.org/pere/blog/Combining_PowerDNS_and_ISC_DHCP_LDAP_objects.html&quot;&gt;merging
all&lt;/a&gt; the computer related LDAP objects in Debian Edu.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

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.

&lt;p&gt;&lt;strong&gt;powerdns&lt;/strong&gt;&lt;/p&gt;

&lt;a href=&quot;http://www.linuxnetworks.de/doc/index.php/PowerDNS_LDAP_Backend&quot;&gt;Clues
on how to&lt;/a&gt; set up PowerDNS to use a LDAP backend is available on
the web.

&lt;p&gt;PowerDNS have two modes of operation using LDAP as its backend.
One &quot;strict&quot; mode where the forward and reverse DNS lookups are done
using the same LDAP objects, and a &quot;tree&quot; 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.&lt;/p&gt;

&lt;p&gt;In tree mode, the server is set up to use a LDAP subtree as its
base, and uses a &quot;base&quot; scoped search for the DNS name by adding
&quot;dc=tjener,dc=intern,&quot; to the base with a filter for
&quot;(associateddomain=tjener.intern)&quot; for the forward entry and
&quot;dc=2,dc=2,dc=0,dc=10,dc=in-addr,dc=arpa,&quot; with a filter for
&quot;(associateddomain=2.2.0.10.in-addr.arpa)&quot; 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:&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
ldapsearch -h ldap \
  -b dc=tjener,dc=intern,ou=hosts,dc=skole,dc=skolelinux,dc=no \
  -s base -x &#39;(associateddomain=tjener.intern)&#39; 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 &#39;(associateddomain=2.2.0.10.in-addr.arpa)&#39;
  dnsttl, arecord, nsrecord, cnamerecord soarecord ptrrecord \
  hinforecord mxrecord txtrecord rprecord aaaarecord locrecord \
  srvrecord naptrrecord modifytimestamp
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
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
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;In strict mode, the server behaves differently.  When looking for
forward DNS entries, it is doing a &quot;subtree&quot; scoped search with the
same base as in the tree mode for a object with filter
&quot;(associateddomain=tjener.intern)&quot; 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 &quot;(arecord=10.0.2.2)&quot;
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.&lt;/p&gt;

&lt;p&gt;The forward and reverse searches can be simulated using ldapsearch
like this:&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
ldapsearch -h ldap -b ou=hosts,dc=skole,dc=skolelinux,dc=no -s sub -x \
  &#39;(associateddomain=tjener.intern)&#39; 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 \
  &#39;(arecord=10.0.2.2)&#39; associateddomain dnsttl modifytimestamp
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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).&lt;/p&gt;

&lt;p&gt;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):&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
objectclass ( some-oid NAME &#39;dnsDomainAux&#39;
    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
    ))
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;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&#39;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.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;ISC dhcp&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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:&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
ldap-base-dn &quot;dc=skole,dc=skolelinux,dc=no&quot;;
ldap-dhcp-server-cn &quot;dhcp&quot;;
&lt;/pre&gt;&lt;/blockquote&gt;

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

&lt;blockquote&gt;&lt;pre&gt;
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
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;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 &quot;cn=DHCP
Config,dc=skole,dc=skolelinux,dc=no&quot; and filter
&quot;(&amp;(objectClass=dhcpService)(|(dhcpPrimaryDN=cn=dhcp,dc=skole,dc=skolelinux,dc=no)(dhcpSecondaryDN=cn=dhcp,dc=skole,dc=skolelinux,dc=no)))&quot;.
The search result is this entry:&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
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
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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 &quot;cn=DHCP Config,dc=skole,dc=skolelinux,dc=no&quot; as
the base and &quot;(&amp;(objectClass=dhcpHost)(dhcpHWAddress=ethernet
00:00:00:00:00:00))&quot; as the filter.  This is what a host object look
like:&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
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
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;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.

&lt;p&gt;&lt;strong&gt;Conclusion&lt;/strong&gt;&lt;/p&gt;

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

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;Based on the observed behaviour, I suspect a LDAP structure like
this might work for Debian Edu:&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
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)
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;P&gt;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.&lt;/p&gt;

&lt;p&gt;The combined object under the machines subtree would look something
like this:&lt;/p&gt;
    
&lt;blockquote&gt;&lt;pre&gt;
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
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;/p&gt;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.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Combining PowerDNS and ISC DHCP LDAP objects</title>
                <link>http://people.skolelinux.org/pere/blog/Combining_PowerDNS_and_ISC_DHCP_LDAP_objects.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Combining_PowerDNS_and_ISC_DHCP_LDAP_objects.html</guid>
                <pubDate>Wed, 14 Jul 2010 23:45:00 +0200</pubDate>
                <description>&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;I&#39;ve looked at how powerdns and dhcpd is using LDAP, and using this
information finally found a solution that seem to work.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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&#39;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.&lt;/p&gt;

&lt;p&gt;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:&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
  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
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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 &quot;DHCP Config&quot; subtree, but hope to figure out a way to do
that.  If I can&#39;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.&lt;/p&gt;

&lt;p&gt;If you want to help out with implementing this for Debian Edu,
please contact us on debian-edu@lists.debian.org.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Idea for storing LTSP configuration in LDAP</title>
                <link>http://people.skolelinux.org/pere/blog/Idea_for_storing_LTSP_configuration_in_LDAP.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Idea_for_storing_LTSP_configuration_in_LDAP.html</guid>
                <pubDate>Sun, 11 Jul 2010 22:00:00 +0200</pubDate>
                <description>&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

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

&lt;p&gt;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?&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
# 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 &#39;ltspClientAux&#39;
#     SUP top
#     AUXILIARY
#     MAY ( ltspConfigServer $ ltsConfigSound $ ... )

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

&lt;p&gt;I&#39;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. :)&lt;/p&gt;

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

&lt;p&gt;Update 2010-07-17: I am aware of another effort to store LTSP
configuration in LDAP that was created around year 2000 by
&lt;a href=&quot;http://www.pcxperience.com/thinclient/documentation/ldap.html&quot;&gt;PC
Xperience, Inc., 2000&lt;/a&gt;.  I found its
&lt;a href=&quot;http://people.redhat.com/alikins/ltsp/ldap/&quot;&gt;files&lt;/a&gt; on a
personal home page over at redhat.com.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>jXplorer, a very nice LDAP GUI</title>
                <link>http://people.skolelinux.org/pere/blog/jXplorer__a_very_nice_LDAP_GUI.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/jXplorer__a_very_nice_LDAP_GUI.html</guid>
                <pubDate>Fri, 9 Jul 2010 12:55:00 +0200</pubDate>
                <description>&lt;p&gt;Since
&lt;a href=&quot;http://people.skolelinux.org/pere/blog/LUMA__a_very_nice_LDAP_GUI.html&quot;&gt;my
last post&lt;/a&gt; about available LDAP tools in Debian, I was told about a
LDAP GUI that is even better than luma.  The java application
&lt;a href=&quot;http://jxplorer.org/&quot;&gt;jXplorer&lt;/a&gt; is claimed to be capable of
moving LDAP objects and subtrees using drag-and-drop, and can
authenticate using Kerberos.  I have only tested the Kerberos
authentication, but do not have a LDAP setup allowing me to rewrite
LDAP with my test user yet.  It is
&lt;a href=&quot;http://packages.qa.debian.org/j/jxplorer.html&quot;&gt;available in
Debian&lt;/a&gt; testing and unstable at the moment.  The only problem I
have with it is how it handle errors.  If something go wrong, its
non-intuitive behaviour require me to go through some query work list
and remove the failing query.  Nothing big, but very annoying.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Caching password, user and group on a roaming Debian laptop</title>
                <link>http://people.skolelinux.org/pere/blog/Caching_password__user_and_group_on_a_roaming_Debian_laptop.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Caching_password__user_and_group_on_a_roaming_Debian_laptop.html</guid>
                <pubDate>Thu, 1 Jul 2010 11:40:00 +0200</pubDate>
                <description>&lt;p&gt;For a laptop, centralized user directories and password checking is
a bit troubling.  Laptops are typically used also when not connected
to the network, and it is vital for a user to be able to log in or
unlock the screen saver also when a central server is unavailable.
This is possible by caching passwords and directory information (user
and group attributes) locally, and the packages to do so are available
in Debian.  Here follow two recipes to set this up in Debian/Squeeze.
It is also possible to set up in Debian/Lenny, but require more manual
setup there because pam-auth-update is missing in Lenny.&lt;/p&gt;

&lt;h2&gt;LDAP/Kerberos + nscd + libpam-ccreds + libpam-mklocaluser/pam_mkhomedir&lt;/h2&gt;

This is the traditional method with a twist.  The password caching is
provided by libpam-ccreds (version 10-4 or later is needed on
Squeeze), and the directory caching is done by nscd.  The directory
lookup and password checking is done using LDAP.  If one want to use
Kerberos for password checking the libpam-ldapd package can be
replaced with libpam-krb5 or libpam-heimdal.  If one is happy having a
local home directory with the path listed in LDAP, one can use the
pam_mkhomedir module from pam-modules to make this happen instead of
using libpam-mklocaluser.  A setup for pam-auth-update to enable
pam_mkhomedir will have to be written until a fix for
&lt;a href=&quot;http://bugs.debian.org/568577&quot;&gt;bug #568577&lt;/a&gt; is in the
archive.  Because I believe it is a bad idea to have local home
directories using misleading paths like /site/server/partition/, I
prefer to create a local user with the home directory in /home/.  This
is done using the libpam-mklocaluser package.&lt;/p&gt;

&lt;p&gt;These packages need to be installed and configured&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
libnss-ldapd libpam-ldapd nscd libpam-ccreds libpam-mklocaluser
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;The ldapd packages will ask for LDAP connection information, and
one have to fill in the values that fits ones own site.  Make sure the
PAM part uses encrypted connections, to make sure the password is not
sent in clear text to the LDAP server.  I&#39;ve been unable to get TLS
certificate checking for a self signed certificate working, which make
LDAP authentication unsafe for Debian Edu (nslcd is not checking if it
is talking to the correct LDAP server), and very much welcome feedback
on how to get this working.&lt;/p&gt;

&lt;p&gt;Because nscd do not have a default configuration fit for offline
caching until &lt;a href=&quot;http://bugs.debian.org/485282&quot;&gt;bug #485282&lt;/a&gt;
is fixed, this configuration should be used instead of the one
currently in /etc/nscd.conf.  The changes are in the fields
reload-count and positive-time-to-live, and is based on the
instructions I found in the
&lt;a href=&quot;http://www.flyn.org/laptopldap/&quot;&gt;LDAP for Mobile Laptops&lt;/a&gt;
instructions by Flyn Computing.&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
        debug-level             0
        reload-count            unlimited
        paranoia                no

        enable-cache            passwd          yes
        positive-time-to-live   passwd          2592000
        negative-time-to-live   passwd          20
        suggested-size          passwd          211
        check-files             passwd          yes
        persistent              passwd          yes
        shared                  passwd          yes
        max-db-size             passwd          33554432
        auto-propagate          passwd          yes

        enable-cache            group           yes
        positive-time-to-live   group           2592000
        negative-time-to-live   group           20
        suggested-size          group           211
        check-files             group           yes
        persistent              group           yes
        shared                  group           yes
        max-db-size             group           33554432
        auto-propagate          group           yes

        enable-cache            hosts           no
        positive-time-to-live   hosts           2592000
        negative-time-to-live   hosts           20
        suggested-size          hosts           211
        check-files             hosts           yes
        persistent              hosts           yes
        shared                  hosts           yes
        max-db-size             hosts           33554432

        enable-cache            services        yes
        positive-time-to-live   services        2592000
        negative-time-to-live   services        20
        suggested-size          services        211
        check-files             services        yes
        persistent              services        yes
        shared                  services        yes
        max-db-size             services        33554432
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;While we wait for a mechanism to update /etc/nsswitch.conf
automatically like the one provided in
&lt;a href=&quot;http://bugs.debian.org/496915&quot;&gt;bug #496915&lt;/a&gt;, the file
content need to be manually replaced to ensure LDAP is used as the
directory service on the machine.  /etc/nsswitch.conf should normally
look like this:&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
passwd:         files ldap
group:          files ldap
shadow:         files ldap
hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4
networks:       files
protocols:      files
services:       files
ethers:         files
rpc:            files
netgroup:       files ldap
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;The important parts are that ldap is listed last for passwd, group,
shadow and netgroup.&lt;/p&gt;

&lt;p&gt;With these changes in place, any user in LDAP will be able to log
in locally on the machine using for example kdm, get a local home
directory created and have the password as well as user and group
attributes cached.

&lt;h2&gt;LDAP/Kerberos + nss-updatedb + libpam-ccreds +
  libpam-mklocaluser/pam_mkhomedir&lt;/h2&gt;

&lt;p&gt;Because nscd have had its share of problems, and seem to have
problems doing proper caching, I&#39;ve seen suggestions and recipes to
use nss-updatedb to copy parts of the LDAP database locally when the
LDAP database is available.  I have not tested such setup, because I
discovered sssd.&lt;/p&gt;

&lt;h2&gt;LDAP/Kerberos + sssd + libpam-mklocaluser&lt;/h2&gt;

&lt;p&gt;A more flexible and robust setup than the nscd combination
mentioned earlier that has shown up recently, is the
&lt;a href=&quot;https://fedorahosted.org/sssd/&quot;&gt;sssd&lt;/a&gt; package from Redhat.
It is part of the &lt;a href=&quot;http://www.freeipa.org/&quot;&gt;FreeIPA&lt;/A&gt; project
to provide a Active Directory like directory service for Linux
machines.  The sssd system combines the caching of passwords and user
information into one package, and remove the need for nscd and
libpam-ccreds.  It support LDAP and Kerberos, but not NIS.  Version
1.2 do not support netgroups, but it is said that it will support this
in version 1.5 expected to show up later in 2010.  Because the
&lt;a href=&quot;http://packages.qa.debian.org/s/sssd.html&quot;&gt;sssd package&lt;/a&gt;
was missing in Debian, I ended up co-maintaining it with Werner, and
version 1.2 is now in testing.

&lt;p&gt;These packages need to be installed and configured to get the
roaming setup I want&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
libpam-sss libnss-sss libpam-mklocaluser
&lt;/pre&gt;&lt;/blockquote&gt;

The complete setup of sssd is done by editing/creating
&lt;tt&gt;/etc/sssd/sssd.conf&lt;/tt&gt;.

&lt;blockquote&gt;&lt;pre&gt;
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
domains = INTERN

[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3

[pam]
reconnection_retries = 3

[domain/INTERN]
enumerate = false
cache_credentials = true

id_provider = ldap
auth_provider = ldap
chpass_provider = ldap

ldap_uri = ldap://ldap
ldap_search_base = dc=skole,dc=skolelinux,dc=no
ldap_tls_reqcert = never
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;I got the same problem here with certificate checking.  Had to set
&quot;ldap_tls_reqcert = never&quot; to get it working.&lt;/p&gt;

&lt;p&gt;With the libnss-sss package in testing at the moment, the
nsswitch.conf file is update automatically, so there is no need to
modify it manually.&lt;/p&gt;

&lt;p&gt;If you want to help out with implementing this for Debian Edu,
please contact us on debian-edu@lists.debian.org.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>LUMA, a very nice LDAP GUI</title>
                <link>http://people.skolelinux.org/pere/blog/LUMA__a_very_nice_LDAP_GUI.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/LUMA__a_very_nice_LDAP_GUI.html</guid>
                <pubDate>Mon, 28 Jun 2010 00:30:00 +0200</pubDate>
                <description>&lt;p&gt;The last few days I have been looking into the status of the LDAP
directory in Debian Edu, and in the process I started to miss a GUI
tool to browse the LDAP tree.  The only one I was able to find in
Debian/Squeeze and Lenny is
&lt;a href=&quot;http://luma.sourceforge.net/&quot;&gt;LUMA&lt;/a&gt;, which has proved to
be a great tool to get a overview of the current LDAP directory
populated by default in Skolelinux.  Thanks to it, I have been able to
find empty and obsolete subtrees, misplaced objects and duplicate
objects.  It will be installed by default in Debian/Squeeze.  If you
are working with LDAP, give it a go. :)&lt;/p&gt;

&lt;p&gt;I did notice one problem with it I have not had time to report to
the BTS yet.  There is no .desktop file in the package, so the tool do
not show up in the Gnome and KDE menus, but only deep down in in the
Debian submenu in KDE.  I hope that can be fixed before Squeeze is
released.&lt;/p&gt;

&lt;p&gt;I have not yet been able to get it to modify the tree yet.  I would
like to move objects and remove subtrees directly in the GUI, but have
not found a way to do that with LUMA yet.  So in the mean time, I use
&lt;a href=&quot;http://www.lichteblau.com/ldapvi/&quot;&gt;ldapvi&lt;/a&gt; for that.&lt;/p&gt;

&lt;p&gt;If you have tips on other GUI tools for LDAP that might be useful
in Debian Edu, please contact us on debian-edu@lists.debian.org.&lt;/p&gt;

&lt;p&gt;Update 2010-06-29: Ross Reedstrom tipped us about the
&lt;a href=&quot;http://packages.qa.debian.org/g/gq.html&quot;&gt;gq&lt;/a&gt; package as a
useful GUI alternative.  It seem like a good tool, but is unmaintained
in Debian and got a RC bug keeping it out of Squeeze.  Unless that
changes, it will not be an option for Debian Edu based on Squeeze.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Idea for a change to LDAP schemas allowing DNS and DHCP info to be combined into one object</title>
                <link>http://people.skolelinux.org/pere/blog/Idea_for_a_change_to_LDAP_schemas_allowing_DNS_and_DHCP_info_to_be_combined_into_one_object.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Idea_for_a_change_to_LDAP_schemas_allowing_DNS_and_DHCP_info_to_be_combined_into_one_object.html</guid>
                <pubDate>Thu, 24 Jun 2010 00:35:00 +0200</pubDate>
                <description>&lt;p&gt;A while back, I
&lt;a href=&quot;http://people.skolelinux.org/pere/blog/Time_for_new__LDAP_schemas_replacing_RFC_2307_.html&quot;&gt;complained
about the fact&lt;/a&gt; that it is not possible with the provided schemas
for storing DNS and DHCP information in LDAP to combine the two sets
of information into one LDAP object representing a computer.&lt;/p&gt;

&lt;p&gt;In the mean time, I discovered that a simple fix would be to make
the dhcpHost object class auxiliary, to allow it to be combined with
the dNSDomain object class, and thus forming one object for one
computer when storing both DHCP and DNS information in LDAP.&lt;/p&gt;

&lt;p&gt;If I understand this correctly, it is not safe to do this change
without also changing the assigned number for the object class, and I
do not know enough about LDAP schema design to do that properly for
Debian Edu.&lt;/p&gt;

&lt;p&gt;Anyway, for future reference, this is how I believe we could change
the
&lt;a href=&quot;http://tools.ietf.org/html/draft-ietf-dhc-ldap-schema-00&quot;&gt;DHCP
schema&lt;/a&gt; to solve at least part of the problem with the LDAP schemas
available today from IETF.&lt;/p&gt;

&lt;pre&gt;
--- dhcp.schema    (revision 65192)
+++ dhcp.schema    (working copy)
@@ -376,7 +376,7 @@
 objectclass ( 2.16.840.1.113719.1.203.6.6
        NAME &#39;dhcpHost&#39;
        DESC &#39;This represents information about a particular client&#39;
-       SUP top
+       SUP top AUXILIARY
        MUST cn
        MAY  (dhcpLeaseDN $ dhcpHWAddress $ dhcpOptionsDN $ dhcpStatements $ dhcpComments $ dhcpOption)
        X-NDS_CONTAINMENT (&#39;dhcpService&#39; &#39;dhcpSubnet&#39; &#39;dhcpGroup&#39;) )
&lt;/pre&gt;

&lt;p&gt;I very much welcome clues on how to do this properly for Debian
Edu/Squeeze.  We provide the DHCP schema in our debian-edu-config
package, and should thus be free to rewrite it as we see fit.&lt;/p&gt;

&lt;p&gt;If you want to help out with implementing this for Debian Edu,
please contact us on debian-edu@lists.debian.org.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Time for new  LDAP schemas replacing RFC 2307?</title>
                <link>http://people.skolelinux.org/pere/blog/Time_for_new__LDAP_schemas_replacing_RFC_2307_.html</link>
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Time_for_new__LDAP_schemas_replacing_RFC_2307_.html</guid>
                <pubDate>Sun, 29 Mar 2009 20:30:00 +0200</pubDate>
                <description>&lt;p&gt;The state of standardized LDAP schemas on Linux is far from
optimal.  There is RFC 2307 documenting one way to store NIS maps in
LDAP, and a modified version of this normally called RFC 2307bis, with
some modifications to be compatible with Active Directory.  The RFC
specification handle the content of a lot of system databases, but do
not handle DNS zones and DHCP configuration.&lt;/p&gt;

&lt;p&gt;In &lt;a href=&quot;http://www.skolelinux.org/&quot;&gt;Debian Edu/Skolelinux&lt;/a&gt;,
we would like to store information about users, SMB clients/hosts,
filegroups, netgroups (users and hosts), DHCP and DNS configuration,
and LTSP configuration in LDAP.  These objects have a lot in common,
but with the current LDAP schemas it is not possible to have one
object per entity.  For example, one need to have at least three LDAP
objects for a given computer, one with the SMB related stuff, one with
DNS information and another with DHCP information.  The schemas
provided for DNS and DHCP are impossible to combine into one LDAP
object.  In addition, it is impossible to implement quick queries for
netgroup membership, because of the way NIS triples are implemented.
It just do not scale.  I believe it is time for a few RFC
specifications to cleam up this mess.&lt;/p&gt;

&lt;p&gt;I would like to have one LDAP object representing each computer in
the network, and this object can then keep the SMB (ie host key), DHCP
(mac address/name) and DNS (name/IP address) settings in one place.
It need to be efficently stored to make sure it scale well.&lt;/p&gt;

&lt;p&gt;I would also like to have a quick way to map from a user or
computer and to the net group this user or computer is a member.&lt;/p&gt;

&lt;p&gt;Active Directory have done a better job than unix heads like myself
in this regard, and the unix side need to catch up.  Time to start a
new IETF work group?&lt;/p&gt;
</description>
        </item>
        
        </channel>
</rss>