Re: New ldap schema for debian-edu?
[Andreas B. Mundt]
> Especially with the ideas of creating a new schema I cannot get rid
> of a uncomfortable feeling. Let me explain why:
I am glad we both agree here. Creating new schemas make me
uncomfortable too, and we should try to avoid it as much as possible.
This is also the reason why we have tried our best to only use schemas
defined by IETF and other standard organizations since the project
started, and have tried our best for several years to get by with the
standard schemas.
But some times the standard schemas are simply not good enough, or are
missing for the services we want to configure using LDAP.
I was rather surprised to discover that Gosa had made their own home
grown schemas and not tried to use existing standard schemas to store
the information collected by and used in Gosa. This give me the same
uncomfortable feeling and I wonder if the not-invented-here syndrom
have been at work.
On the other hand Gosa seem to have solved several of the issues we
would like to solve in Debian too. LDAP driven PXE and X
configuration, for example. Gosa also have merged all information
about a computer into one object, but using their own home-grown LDAP
schemas which are incompaible with the ones used by the services, and
this computer object is not used by the services Gosa administrates.
Instead the information in this master object is duplicated into other
service specific LDAP objects. It is a reasonable design when the
available schemas compatible with the various services are
incompatible with each other and make it hard or impossible to use
merged objects directly with the services. This latter assumtion is
the one I have been investigating the last few weeks, and when it come
to PowerDNS and ISC DHCP, I suspect it is solvable with a new object
class. :)
> What makes me wonder is, why a small project like debian-edu needs
> to come up with the invention of a new schema when the rest of the
> world does not feel the pressure to move away from schemas that have
> been around and used successfully for many years in many
> institutions. I fear that this solo attempt to improve things might
> end up in loosing compatibility and flexibility to use tools for
> ldap administration, something we definitely need.
This must be based on some misunderstanding of my effort. I am trying
to figure out a way to organize the Debian Edu LDAP tree with
standardized LDAP schemas as much as possible, and with as little
information duplication as possible.
As for what the the rest of the world is using, it is worth noting
that while the unix side have a set of incompatible LDAP schemas
scattered around all over the Internet and included with various
service implementations, the windows world have a more well designed
set of compatible schemas available with Active Directory. With that
background knowledge, it seem to me that it is a misunderstanding to
believe the rest of the world i happy with the available schemas in
the unix world.
To give you an example of what I am talking about, notice this quote
from
<URL: http://www.linuxnetworks.de/doc/index.php/PowerDNS_LDAP_Backend/Migration >:
Unfortunately, both schemas (dnsdomain2 and dnszone) share the same
record types and use the same OIDs so the LDAP server can't use
both schemas at the same time.
I suspect dhsdomain2 is created by the powerdns project, and further
suspect dnszone is created by some bind9 related project. How they
managed to get the same OIDs is a mystery to me, given that they
should get them from the authority residing over the parent OID. But
my point is that these two schemas are incompabible and can not be
used together. It is not the only example, and a more common issue
are objectclasses that would be useful to combine but are impossible
to combine because both are strucutal.
> So as I point out from time to time: In my opinion, we as a project
> with rather limited manpower, we should really keep things as simple
> and mainstream as possible.
I agree. And to me that mean that if we conclude that some
non-standard or new LDAP schema is the way forward, we should try to
get these attributes/object classes standardized or at least merged
into the schemas provied by the service projects that would use them.
I've done that for my proposal for a new objectclass to be used by
powerdns, and also for my draft LTSP implementation.
I just publised my findings about the LDAP searches done by PowerDNS
and ISC DHCP, which is part of my work to try to see if we can get
both services to use the same LDAP objects. I recommend reading
<URL: http://people.skolelinux.org/pere/blog/What_are_they_searching_for___PowerDNS_and_ISC_DHCP_in_LDAP.html >
and notice the only replacement LDAP schema on the table so far:
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 effort is independent from my tries to get LTSP to fetch
configuration from LDAP, which I expect will be merged upstream if I
figure out a good way to do it. :)
I suspect the misunderstanding regarding my effort of late might
originate from your discovery of the lis schema that was created very
early in the project and not really used, but that is pure guesswork
on my part.
[Benoit Mortier]
> For example in the many university i came the want to use a frontend
> to manage their growing ldap servers but forbid using non standard
> schema. In this case debian Edu and is own schema who be forbidden
> and some other solution would be used.
What kind of definition for a standard schema do these universities
use? Would for example the gotoTerminal object class brewed by the
Gosa project be allowed into these LDAP servers?
Happy hacking,
--
Petter Reinholdtsen
Reply to: