blog/tags/ldap/ldap.rss

   1 <?xml version="1.0" encoding="utf-8"?>
   2 <rss version='2.0' xmlns:lj='http://www.livejournal.org/rss/lj/1.0/'>
   3         <channel>
   4                 <title>Petter Reinholdtsen - Entries tagged ldap</title>
   5                 <description>Entries tagged ldap</description>
   6                 <link>http://people.skolelinux.org/pere/blog/</link>
   7
   8
   9         <item>
  10                 <title>Time for new  LDAP schemas replacing RFC 2307?</title>
  11                 <link>http://people.skolelinux.org/pere/blog/Time_for_new__LDAP_schemas_replacing_RFC_2307_.html</link>
  12                 <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Time_for_new__LDAP_schemas_replacing_RFC_2307_.html</guid>
  13                 <pubDate>Sun, 29 Mar 2009 20:30:00 +0200</pubDate>
  14                 <description>
  15 &lt;p&gt;The state of standardized LDAP schemas on Linux is far from
  16 optimal.  There is RFC 2307 documenting one way to store NIS maps in
  17 LDAP, and a modified version of this normally called RFC 2307bis, with
  18 some modifications to be compatible with Active Directory.  The RFC
  19 specification handle the content of a lot of system databases, but do
  20 not handle DNS zones and DHCP configuration.&lt;/p&gt;
  21
  22 &lt;p&gt;In &lt;a href=&quot;http://www.skolelinux.org/&quot;&gt;Debian Edu/Skolelinux&lt;/a&gt;,
  23 we would like to store information about users, SMB clients/hosts,
  24 filegroups, netgroups (users and hosts), DHCP and DNS configuration,
  25 and LTSP configuration in LDAP.  These objects have a lot in common,
  26 but with the current LDAP schemas it is not possible to have one
  27 object per entity.  For example, one need to have at least three LDAP
  28 objects for a given computer, one with the SMB related stuff, one with
  29 DNS information and another with DHCP information.  The schemas
  30 provided for DNS and DHCP are impossible to combine into one LDAP
  31 object.  In addition, it is impossible to implement quick queries for
  32 netgroup membership, because of the way NIS triples are implemented.
  33 It just do not scale.  I believe it is time for a few RFC
  34 specifications to cleam up this mess.&lt;/p&gt;
  35
  36 &lt;p&gt;I would like to have one LDAP object representing each computer in
  37 the network, and this object can then keep the SMB (ie host key), DHCP
  38 (mac address/name) and DNS (name/IP address) settings in one place.
  39 It need to be efficently stored to make sure it scale well.&lt;/p&gt;
  40
  41 &lt;p&gt;I would also like to have a quick way to map from a user or
  42 computer and to the net group this user or computer is a member.&lt;/p&gt;
  43
  44 &lt;p&gt;Active Directory have done a better job than unix heads like myself
  45 in this regard, and the unix side need to catch up.  Time to start a
  46 new IETF work group?&lt;/p&gt;
  47 </description>
  48         </item>
  49
  50         <item>
  51                 <title>Idea for a change to LDAP schemas allowing DNS and DHCP info to be combined into one object</title>
  52                 <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>
  53                 <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>
  54                 <pubDate>Thu, 24 Jun 2010 00:35:00 +0200</pubDate>
  55                 <description>
  56 &lt;p&gt;A while back, I
  57 &lt;a href=&quot;http://people.skolelinux.org/pere/blog/Time_for_new__LDAP_schemas_replacing_RFC_2307_.html&quot;&gt;complained
  58 about the fact&lt;/a&gt; that it is not possible with the provided schemas
  59 for storing DNS and DHCP information in LDAP to combine the two sets
  60 of information into one LDAP object representing a computer.&lt;/p&gt;
  61
  62 &lt;p&gt;In the mean time, I discovered that a simple fix would be to make
  63 the dhcpHost object class auxiliary, to allow it to be combined with
  64 the dNSDomain object class, and thus forming one object for one
  65 computer when storing both DHCP and DNS information in LDAP.&lt;/p&gt;
  66
  67 &lt;p&gt;If I understand this correctly, it is not safe to do this change
  68 without also changing the assigned number for the object class, and I
  69 do not know enough about LDAP schema design to do that properly for
  70 Debian Edu.&lt;/p&gt;
  71
  72 &lt;p&gt;Anyway, for future reference, this is how I believe we could change
  73 the
  74 &lt;a href=&quot;http://tools.ietf.org/html/draft-ietf-dhc-ldap-schema-00&quot;&gt;DHCP
  75 schema&lt;/a&gt; to solve at least part of the problem with the LDAP schemas
  76 available today from IETF.&lt;/p&gt;
  77
  78 &lt;pre&gt;
  79 --- dhcp.schema    (revision 65192)
  80 +++ dhcp.schema    (working copy)
  81 @@ -376,7 +376,7 @@
  82  objectclass ( 2.16.840.1.113719.1.203.6.6
  83         NAME &#39;dhcpHost&#39;
  84         DESC &#39;This represents information about a particular client&#39;
  85 -       SUP top
  86 +       SUP top AUXILIARY
  87         MUST cn
  88         MAY  (dhcpLeaseDN $ dhcpHWAddress $ dhcpOptionsDN $ dhcpStatements $ dhcpComments $ dhcpOption)
  89         X-NDS_CONTAINMENT (&#39;dhcpService&#39; &#39;dhcpSubnet&#39; &#39;dhcpGroup&#39;) )
  90 &lt;/pre&gt;
  91
  92 &lt;p&gt;I very much welcome clues on how to do this properly for Debian
  93 Edu/Squeeze.  We provide the DHCP schema in our debian-edu-config
  94 package, and should thus be free to rewrite it as we see fit.&lt;/p&gt;
  95
  96 &lt;p&gt;If you want to help out with implementing this for Debian Edu,
  97 please contact us on debian-edu@lists.debian.org.&lt;/p&gt;
  98 </description>
  99         </item>
 100
 101         </channel>
 102 </rss>