Re: New ldap schema for debian-edu?
Le Saturday 17 July 2010 22:48:59 Petter Reinholdtsen, vous avez écrit :
> [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.
if you try only with the IETF schema you will ahve nightmare as those are
to strict and too unix centric to make them work
> But some times the standard schemas are simply not good enough, or are
> missing for the services we want to configure using LDAP.
That's not right, each service that can be controlled by ldap has i own
schema, it's right that some of them are broken or not well written but
its no the case of the classical services, dhcp / dns / ftp / radius
etc..
> 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.
That's not exactly right GOsa use the standard schema, but added is own to
store more info that in the ietf standard ones. You have to understand
that the goal of Gosa is to manage all you users / group / systems /
deployment / applications in the ldap server so it was obvious that it
needed more info.
You have to stop thinking from a technician point of wiew by more from a
fonctionnality point of view.
We all are can do everything by hand but what happens when you put someone
without knowledge in charge ? You have to give him something easy to use
and not 5 or 6 deifferents applications.
> 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. :)
that again is not right ! The computer object is only the representation
of a computer / Server / terminal. And on a server you can add services
that peut entries in this server that other applicatiosn can use !
> > 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.
That the error you should think about how to manage it from a user point
of view and then decide on the application to manage it and after that
see how you can modelize your tree to attain your goal.
The tree in the wiki is too complicated for no reason ! i can simplify it
and make it easier to maintain for the admin.
> 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.
Please don't tell me that Active Directory is usefull and have nice
schema ;-) Active Directory is crap and their tree is even more crap ..
> 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/Migrati
>on >:
>
> 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.
So one of them is not registred with the iana correctly will check now ;-)
the owner of the dnszone.schema enregistered it correctly with the iana,
see below.
> 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.
the oid of the dnszone schema is attribued to uineet.no, its the guy who
has done the ldap2zone program, so the the powerdns guy done it wrong and
just derived the schema without changing and registering oid !
> > 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.
again i'am against creating new schema, we have everything we need here,
so please stop trying to create new schema.
> 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___Po
>werDNS_and_ISC_DHCP_in_LDAP.html > and notice the only replacement LDAP
> schema on the table so far:
Please stop ! and use the classical dnszone.schema or the one from
powerdns but don't create new schema.
> 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 was looking for a ldap schema for is but not looked to much will look
again
> 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?
It very easy to undertstand they use for the most part entries in their
ldap server for users, group etc..
And they want some kind of way to manage computers / servers / services ,
they want manage ssh, sudo etc..
When they chose their application to manage this complexity, they look at
how nicely the schema odf the application can be installed in their ldap
server, how new objectclass merge with the one they already have.
They also think in term of user friendly interface, fonctionnality,
easiest way to manage their assets.
They are rassured that GOsa aprt form his schema use the calssical dhcp,
dns, ftp etc ... schema
To understand that you have to think like a first line technican or end
user
Cheers
--
Benoit Mortier
CEO
OpenSides "logiciels libres pour entreprises" : http://www.opensides.eu/
Promouvoir et défendre le Logiciel Libre http://www.april.org/
Contributor to Gosa Project : http://gosa-project.org/
Reply to: