Re: document ldapd schema files
On Fri, Nov 5, 2010 at 1:57 PM, Bob Beck wrote: >> I've always thought Bob's comment from 2/11/2005, was worth adding to >> quotes, but it might be a "bit" long. Bob might even remember why I >> say that. > > I remember. Your response was priceless share! >>> > > It wasn't the response itself that was funny. it was the response in > conjunction with the email domain it came from ;) I did pick up on that ;)
Re: document ldapd schema files
> I've always thought Bob's comment from 2/11/2005, was worth adding to > quotes, but it might be a "bit" long. Bob might even remember why I > say that. I remember. Your response was priceless >>> >>> share! >> It wasn't the response itself that was funny. it was the response in conjunction with the email domain it came from ;)
Re: document ldapd schema files
On 11/05/10 19:43, Eichert, Diana wrote: > On Fri, Nov 5, 2010 at 12:34 PM, patrick keshishian < pkesh...@gmail.com > > wrote: >> On Fri, Nov 5, 2010 at 11:04 AM, Marco S Hyman wrote: I've always thought Bob's comment from 2/11/2005, was worth adding to quotes, but it might be a "bit" long. Bob might even remember why I say that. >>> >>> I remember. Your response was priceless >> >> share! > > mail archives are your friend. I'll give you the thread > > http://marc.info/?t=11080677753&r=3&w=2 Indeed that was very funny! :-)
Re: document ldapd schema files
On Fri, Nov 5, 2010 at 12:34 PM, patrick keshishian < pkesh...@gmail.com > wrote: >On Fri, Nov 5, 2010 at 11:04 AM, Marco S Hyman wrote: >>> I've always thought Bob's comment from 2/11/2005, was worth adding to >>> quotes, but it might be a "bit" long. Bob might even remember why I >>> say that. >> >> I remember. Your response was priceless > > share! mail archives are your friend. I'll give you the thread http://marc.info/?t=11080677753&r=3&w=2
Re: document ldapd schema files
On Fri, Nov 5, 2010 at 11:04 AM, Marco S Hyman wrote: >> I've always thought Bob's comment from 2/11/2005, was worth adding to >> quotes, but it might be a "bit" long. Bob might even remember why I >> say that. > > I remember. Your response was priceless share!
Re: document ldapd schema files
> I've always thought Bob's comment from 2/11/2005, was worth adding to > quotes, but it might be a "bit" long. Bob might even remember why I > say that. I remember. Your response was priceless /\/\arc
Re: document ldapd schema files
I've always thought Bob's comment from 2/11/2005, was worth adding to quotes, but it might be a "bit" long. Bob might even remember why I say that. diana Bob Beck said on Feb 11, 2005 in a comment Re: Star & OpenBSD . OpenBSD wants even the worst nastiest anal-carotid-constriction-software-patent-loving-spam-your-grandma-for-a-doll ar-bottom-feeding-killing-babies-in-palestine-and-iraq type organizations to be able to use our codebase in whatever they like.
Re: document ldapd schema files
On Fri, 05 Nov 2010, Sebastian Reitenbach wrote: > I like that, and probably worth a fortune cookie, starting with a dedicated > cookie file just for theo! > OK? ;) Here's to you ;) ciao, david Write more code. % Make more commits. % That's because you have been slacking. % slacker! % That's what happens when you're lazy. % idler! % slackass! % lazy bum! % Stop slacking you lazy bum! % slacker slacker lazy bum bum bum slacker! % I could search... but I'm a lazy bum ;) % sshutup sshithead, ssharpsshooting susshi sshplats ssharking assholes. % Lazy bums slacking on your asses. % 35 commits an hour? That's pathetic! % Fine software takes time to prepare. Give a little slack. % I am just stating a fact % you bring new meanings to the term slackass. I will have to invent a new term. % if they cut you out, muddy their back yards % Make them want to start over, and play nice the next time. % It is clear that this has not been thought through. % avoid using abort(). it is not nice. % That's the most ridiculous thing I've heard in the last two or three minutes! % I'm not just doing this for crowd response. I need to be right. % I'd put a fan on my bomb.. And blinking lights... % I love to fight % No sane people allowed here. Go home. % you have to stop peeing on your breakfast % feature requests come from idiots % henning and darren / sitting in a tree / t o k i n g / a joint or three % KICK ASS. TIME FOR A JASON LOVE IN! WE CAN ALL GET LOST IN HIS HAIR! % shame on you for following my rules. % altq's parser sucks dead whale farts through the finest chemistry pipette's % screw this operating system shit, i just want to drive! % Search for fuck. Anytime you see that word, you have a paragraph to write. % Yes, but the ports people are into S&M. % Buttons are for idiots. % We are not hackers. We are turd polishing craftsmen. % who cares. style(9) can bite my ass % It'd be one fucking happy planet if it wasn't for what's under this fucking sticker. % I would explain, but I am too drunk. % you slackers don't deserve pictures yet % Vegetarian my ass % Wait a minute, that's a McNally's! % don't they recognize their moral responsibility to entertain me? % #ifdef is for emacs developers. % Many well known people become net-kooks in their later life, because they lose touch with reality. % You're not allowed to have an opinion. % tweep tweep tweep % Quite frankly, SSE's alignment requirement is the most utterly retarded idea since eating your own shit. % Holy verbose prom startup Batman. % Any day now, when we sell out. % optimism in man kind does not belong here % First user who tries to push this button, he pounds into the ground with a rant of death. % we did farts. now we do sperm. we are cutting edge. % the default configuration is a mixture of piss, puke, shit, and bloody entrails. % Stop wasting your time reading people's licenses. % doing it with environment variables is OH SO SYSTEM FIVE LIKE OH MY GOD PASS ME THE SPOON % Linux is fucking POO, not just bad, bad REALLY REALLY BAD % penguins are not much more than chickens that swim. % i am a packet sniffing fool, let me wipe my face with my own poo % Whiners. They scale really well. % in your world, you would have a checklist of 50 fucking workarounds just to make a coffee. % for once, I have nothing to say. % You have no idea how fucked we are % You can call it fart if you want to. % wavelan is a battle field % You are in a maze of gpio pins, all alike, all undocumented, and a few are wired to bombs. % And that is why humppa sucks... cause it has no cause. % cache aliasing is a problem that would have stopped in 1992 if someone had killed about 5 people who worked at Sun. % Don't spread rumours about me being gentle. % If municipal water filtering equipment was built by the gcc developers, the western world would be dead by now. % kettenis supported a new machine in my basement and all I got to do was fix a 1 character typo in his html page commit. % industry told us a lesson: when you're an asshole, they mail you hardware % I was joking, really. I think I am funny :-) % the kernel is a harsh mistress % Have I ever been subtle? If my approach ever becomes subtle, shoot me. % the acpi stabs you in the back. the acpi stabs you in the back. you die ... % My cats are more observant than you. % our kernels have no bugs % style(9) has all these fascist rules, and i have a problem with some of them because i didn't come up with them % I'm not very reliable % I don't like control % You aren't being conservative -- you are trying to be a caveman. % nfs loves everyone % basically, dung beetles fucking. that's what kerberosV + openssl is like % I would rather run Windows than use vi. %
Re: document ldapd schema files
On Thursday, November 4, 2010 21:32 CET, Theo de Raadt
wrote:
> > On second thought, I should answer with a little less snark, though I
> > think this one attribute sums it up pretty well.
> >
> > First, some committee sat around and tried to come up with all the
> > things needed to describe a person, like license plates and pager
> > numbers and who your secretary is. It's like it's custom built for
> > handling the personnel records of IBM management. They made all this
> > nonsense optional thankfully, but who's to say there aren't other
> > attributes you need to store in your organization? Now you're off
> > making your own schema. Adios interop!
> >
> > Second, the file formats seem purpose designed to be incomprehensible.
> >
> > Third, just doing something as simple as putting a single user record
> > into the db using ldapadd involved an insane amount of typing of magic
> > incantations. This is not entirely the tool's fault, there's just so
> > much "stuff" involved it bubbles up to the user whether they like it
> > or not.
> >
> > On the whole, "infinite flexibility" is pretty much synonymous with
> > "infinite complexity".
>
> not enough axe murderers.
>
> note to axe murderers: ietf and other such organizations are purposely
> weak at checking badges at their events, because who would want to go
> to them? use this to your advangage. the people attending these
> meetings are generally pretty unfit and move slowly, so you don't need
> a large, long handled axe -- something small will do.
>
I like that, and probably worth a fortune cookie, starting with a dedicated
cookie file just for theo!
OK? ;)
cheers,
Sebastian
Index: Makefile
===
RCS file: /cvs/src/games/fortune/datfiles/Makefile,v
retrieving revision 1.6
diff -u -r1.6 Makefile
--- Makefile26 Sep 2003 03:08:44 - 1.6
+++ Makefile5 Nov 2010 07:23:58 -
@@ -2,9 +2,9 @@
# $NetBSD: Makefile,v 1.15 1996/02/29 00:21:16 jtc Exp $
# @(#)Makefile8.2 (Berkeley) 4/19/94
-SRCS= fortunes fortunes2 startrek zippy recipes
+SRCS= fortunes fortunes2 startrek zippy recipes theo
BLDS= fortunes.dat fortunes2.dat startrek.dat zippy.dat \
- fortunes-o fortunes-o.dat recipes.dat
+ fortunes-o fortunes-o.dat recipes.dat theo.dat
# TO INSTALL THE POTENTIALLY OFFENSIVE FORTUNES, UNCOMMENT THE THREE
# LINES AND COMMENT OUT THE FOURTH LINE.
@@ -31,7 +31,7 @@
${INSTALL} ${INSTALL_COPY} -o ${BINOWN} -g ${BINGRP} -m 444 ${BLDS} \
${DESTDIR}/usr/share/games/fortune
-fortunes.dat fortunes2.dat fortunes2-o.dat limerick.dat startrek.dat zippy.dat
recipes.dat:
+fortunes.dat fortunes2.dat fortunes2-o.dat limerick.dat startrek.dat zippy.dat
recipes.dat theo.dat:
${STRFILE} -rs ${.CURDIR}/${.TARGET:R} ${.TARGET}
fortunes-o.dat: fortunes-o
Index: theo
===
RCS file: theo
diff -N theo
--- /dev/null 1 Jan 1970 00:00:00 -
+++ theo5 Nov 2010 07:23:58 -
@@ -0,0 +1,8 @@
+note to axe murderers: ietf and other such organizations are purposely
+weak at checking badges at their events, because who would want to go
+to them? use this to your advangage. the people attending these
+meetings are generally pretty unfit and move slowly, so you don't need
+a large, long handled axe -- something small will do.
+
+Theo de Raadt on tech@ answering the thread: document ldapd schema files
+
Re: document ldapd schema files
On Thu, Nov 04, 2010 at 02:32:45PM -0600, Theo de Raadt wrote: > > On second thought, I should answer with a little less snark, though I > > think this one attribute sums it up pretty well. > > > > First, some committee sat around and tried to come up with all the > > things needed to describe a person, like license plates and pager > > numbers and who your secretary is. It's like it's custom built for > > handling the personnel records of IBM management. They made all this > > nonsense optional thankfully, but who's to say there aren't other > > attributes you need to store in your organization? Now you're off > > making your own schema. Adios interop! > > > > Second, the file formats seem purpose designed to be incomprehensible. > > > > Third, just doing something as simple as putting a single user record > > into the db using ldapadd involved an insane amount of typing of magic > > incantations. This is not entirely the tool's fault, there's just so > > much "stuff" involved it bubbles up to the user whether they like it > > or not. > > > > On the whole, "infinite flexibility" is pretty much synonymous with > > "infinite complexity". > > not enough axe murderers. > > note to axe murderers: ietf and other such organizations are purposely > weak at checking badges at their events, because who would want to go > to them? use this to your advangage. the people attending these > meetings are generally pretty unfit and move slowly, so you don't need > a large, long handled axe -- something small will do. nce!
Re: document ldapd schema files
> On second thought, I should answer with a little less snark, though I > think this one attribute sums it up pretty well. > > I enjoyed the first response but thanks for the follow-up. > First, some committee sat around and tried to come up with all the > things needed to describe a person, like license plates and pager > numbers and who your secretary is. It's like it's custom built for > handling the personnel records of IBM management. They made all this > nonsense optional thankfully, but who's to say there aren't other > attributes you need to store in your organization? Now you're off > making your own schema. Adios interop! > I've found LDAP useful in simple situations and barely tolerable in big organizations for reasons you highlighted. A lot of people have to justify their existence and some can do it by managing a directory server. On the flip side, I recently used LDAP for a guest wireless application and saved us from having to rely on Active Directory (definitely not something I like but for some organizations they think they need a directory system). I've tried to ponder how one might lobby managers in an organization to not go the "single sign on route" or use Active Directory (and AD "like" solutions) but I'm always faced with the ... "it's easy and it works with everything" counterpoints (and no it doesn't work with everything). I was hoping maybe some of you could shed light on approaches to solving the "how do I manage users across multiple operating systems and application domains" problem that faces a lot of organizations but I imagine that's a question better asked on a different mailing list. That question is why I asked you about your decision earlier. > Second, the file formats seem purpose designed to be incomprehensible. > > Third, just doing something as simple as putting a single user record > into the db using ldapadd involved an insane amount of typing of magic > incantations. This is not entirely the tool's fault, there's just so > much "stuff" involved it bubbles up to the user whether they like it > or not. > > Yup, it's a bit of a mess and nearly impossible to create good and powerful abstractions for admins when faced with so many permutations. > On the whole, "infinite flexibility" is pretty much synonymous with > "infinite complexity". > This is where I led myself to on the whole discussion of identify management in an enterprise.
Re: document ldapd schema files
On Thu, Nov 04, 2010 at 02:32:45PM -0600, Theo de Raadt wrote: > > On second thought, I should answer with a little less snark, though I > > think this one attribute sums it up pretty well. > > > > First, some committee sat around and tried to come up with all the > > things needed to describe a person, like license plates and pager > > numbers and who your secretary is. It's like it's custom built for > > handling the personnel records of IBM management. They made all this > > nonsense optional thankfully, but who's to say there aren't other > > attributes you need to store in your organization? Now you're off > > making your own schema. Adios interop! > > > > Second, the file formats seem purpose designed to be incomprehensible. > > > > Third, just doing something as simple as putting a single user record > > into the db using ldapadd involved an insane amount of typing of magic > > incantations. This is not entirely the tool's fault, there's just so > > much "stuff" involved it bubbles up to the user whether they like it > > or not. > > > > On the whole, "infinite flexibility" is pretty much synonymous with > > "infinite complexity". > > not enough axe murderers. > > note to axe murderers: ietf and other such organizations are purposely > weak at checking badges at their events, because who would want to go > to them? use this to your advangage. the people attending these > meetings are generally pretty unfit and move slowly, so you don't need > a large, long handled axe -- something small will do. > like blades in a cheese burger ? Gilles
Re: document ldapd schema files
4 nov 2010 kl. 21.22 skrev Ted Unangst: On Thu, Nov 4, 2010 at 3:53 PM, Ted Unangst wrote: >> On Thu, Nov 4, 2010 at 3:10 PM, Adam M. Dutko wrote: I can't really comment on the accuracy because I'm trying to avoid learning about LDAP at all cost, but this gives me enough info to start searching with, so I think it's a great addition. >>> >>> What is the technical reason behind not wanting to learn about LDAP? I'd > be >>> interested to hear feedback/input from you and the rest of the list. > > On second thought, I should answer with a little less snark, though I > think this one attribute sums it up pretty well. It does. My personal favourite otherwise is the wealth of useful syntax rules: ( 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal Identifier' ) > First, some committee sat around and tried to come up with all the > things needed to describe a person, like license plates and pager > numbers and who your secretary is. It's like it's custom built for > handling the personnel records of IBM management. They made all this > nonsense optional thankfully, but who's to say there aren't other > attributes you need to store in your organization? Now you're off > making your own schema. Adios interop! You can also add the extensibleObject object class to your entry. This way you can use any defined attribute. > Second, the file formats seem purpose designed to be incomprehensible. > > Third, just doing something as simple as putting a single user record > into the db using ldapadd involved an insane amount of typing of magic > incantations. This is not entirely the tool's fault, there's just so > much "stuff" involved it bubbles up to the user whether they like it > or not. > > On the whole, "infinite flexibility" is pretty much synonymous with > "infinite complexity". > > >> attributetype ( 2.16.840.1.113730.3.1.1 >> NAME 'carLicense' >> DESC 'RFC2798: vehicle license or registration plate' >> EQUALITY caseIgnoreMatch >> SUBSTR caseIgnoreSubstringsMatch >> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
Re: document ldapd schema files
> On second thought, I should answer with a little less snark, though I > think this one attribute sums it up pretty well. > > First, some committee sat around and tried to come up with all the > things needed to describe a person, like license plates and pager > numbers and who your secretary is. It's like it's custom built for > handling the personnel records of IBM management. They made all this > nonsense optional thankfully, but who's to say there aren't other > attributes you need to store in your organization? Now you're off > making your own schema. Adios interop! > > Second, the file formats seem purpose designed to be incomprehensible. > > Third, just doing something as simple as putting a single user record > into the db using ldapadd involved an insane amount of typing of magic > incantations. This is not entirely the tool's fault, there's just so > much "stuff" involved it bubbles up to the user whether they like it > or not. > > On the whole, "infinite flexibility" is pretty much synonymous with > "infinite complexity". not enough axe murderers. note to axe murderers: ietf and other such organizations are purposely weak at checking badges at their events, because who would want to go to them? use this to your advangage. the people attending these meetings are generally pretty unfit and move slowly, so you don't need a large, long handled axe -- something small will do.
Re: document ldapd schema files
On Thu, Nov 4, 2010 at 3:53 PM, Ted Unangst wrote: > On Thu, Nov 4, 2010 at 3:10 PM, Adam M. Dutko wrote: >>> I can't really comment on the accuracy because I'm trying to avoid >>> learning about LDAP at all cost, but this gives me enough info to >>> start searching with, so I think it's a great addition. >>> >> >> What is the technical reason behind not wanting to learn about LDAP? I'd be >> interested to hear feedback/input from you and the rest of the list. On second thought, I should answer with a little less snark, though I think this one attribute sums it up pretty well. First, some committee sat around and tried to come up with all the things needed to describe a person, like license plates and pager numbers and who your secretary is. It's like it's custom built for handling the personnel records of IBM management. They made all this nonsense optional thankfully, but who's to say there aren't other attributes you need to store in your organization? Now you're off making your own schema. Adios interop! Second, the file formats seem purpose designed to be incomprehensible. Third, just doing something as simple as putting a single user record into the db using ldapadd involved an insane amount of typing of magic incantations. This is not entirely the tool's fault, there's just so much "stuff" involved it bubbles up to the user whether they like it or not. On the whole, "infinite flexibility" is pretty much synonymous with "infinite complexity". > attributetype ( 2.16.840.1.113730.3.1.1 >NAME 'carLicense' >DESC 'RFC2798: vehicle license or registration plate' >EQUALITY caseIgnoreMatch >SUBSTR caseIgnoreSubstringsMatch >SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
Re: document ldapd schema files
On Thu, Nov 4, 2010 at 3:10 PM, Adam M. Dutko wrote: >> I can't really comment on the accuracy because I'm trying to avoid >> learning about LDAP at all cost, but this gives me enough info to >> start searching with, so I think it's a great addition. >> > > What is the technical reason behind not wanting to learn about LDAP? I'd be > interested to hear feedback/input from you and the rest of the list. attributetype ( 2.16.840.1.113730.3.1.1 NAME 'carLicense' DESC 'RFC2798: vehicle license or registration plate' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
Re: document ldapd schema files
4 nov 2010 kl. 20.10 skrev Adam M. Dutko: >> I can't really comment on the accuracy because I'm trying to avoid >> learning about LDAP at all cost, but this gives me enough info to >> start searching with, so I think it's a great addition. >> > > What is the technical reason behind not wanting to learn about LDAP? I'd be > interested to hear feedback/input from you and the rest of the list. I can't speak for Ted, but I would guess having other priorities or lack of time. Anyway, I should perhaps mention the 'relax schema' keyword in the ldapd.conf file, if you don't want to write a schema definition. Basically it bypasses all attribute checking of stored entries, so you can use it as a simple key-value store. Any attribute will be accepted. Don't use if you want any kind of interoperability. -martin
Re: document ldapd schema files
> I can't really comment on the accuracy because I'm trying to avoid > learning about LDAP at all cost, but this gives me enough info to > start searching with, so I think it's a great addition. > What is the technical reason behind not wanting to learn about LDAP? I'd be interested to hear feedback/input from you and the rest of the list.
Re: document ldapd schema files
On Wed, Nov 3, 2010 at 4:00 PM, Martin Hedenfalk wrote: > On Wed, Nov 03, 2010 at 01:19:26PM -0400, Ted Unangst wrote: >> Am I missing something, or is there no documentation for the schema >> files? man ldapd.conf tells me I can include additional schema files >> via the schema keyword, but nothing tells me what to put in those >> files. > > Following diff attempts to documents the schema file syntax. Only > a brief synopsis of the attribute type and object class syntax is > given, the rest is referred to the RFC. I can't really comment on the accuracy because I'm trying to avoid learning about LDAP at all cost, but this gives me enough info to start searching with, so I think it's a great addition.
document ldapd schema files
On Wed, Nov 03, 2010 at 01:19:26PM -0400, Ted Unangst wrote: > Am I missing something, or is there no documentation for the schema > files? man ldapd.conf tells me I can include additional schema files > via the schema keyword, but nothing tells me what to put in those > files. Following diff attempts to documents the schema file syntax. Only a brief synopsis of the attribute type and object class syntax is given, the rest is referred to the RFC. I couldn't get the long synopsis lines to display as I wanted, so I'm hoping for some mdoc help :) -martin Index: ldapd.conf.5 === RCS file: /cvs/src/usr.sbin/ldapd/ldapd.conf.5,v retrieving revision 1.11 diff -u -p -u -r1.11 ldapd.conf.5 --- ldapd.conf.53 Nov 2010 11:21:11 - 1.11 +++ ldapd.conf.53 Nov 2010 19:47:39 - @@ -132,6 +132,9 @@ Password for the root user. Specified either in plain text, or in hashed format. .It schema Ar filename Add schema definitions from the specified file. +For a description of the schema file syntax see +.Sx SCHEMA +below. .El .Sh NAMESPACES A namespace is a subtree of the global X.500 DIT (Directory Information Tree), @@ -250,16 +253,79 @@ Typically used to allow users to modify Enable compression of entries and optionally specify compression level (0 - 9). By default, no compression is used. .El +.Sh SCHEMA +Schema files define the structure and format of entries in the directory tree. +There are three types of definitions in a schema file: +.Bl -tag -width Ds +.It attributetype +\*(lp +.Ar oid +.Op NAME name +.Op DESC description +.Op OBSOLETE +.Op SUP oid +.Op EQUALITY oid +.Op ORDERING oid +.Op SUBSTR oid +.Op SYNTAX oid +.Op SINGLE-VALUE +.Op COLLECTIVE +.Op NO-USER-MODIFICATION +.Op USAGE Brq userApplications | directoryOperation | distributedOperation | dSAOperation +\*(rp +.Pp +An attribute type definition specifies the syntax of attribute values, whether +it allows multiple values and how it can be compared in search requests. +For a complete description of attribute type defitions, see section +4.1.2 in RFC 4712. +.It objectclass +\*(lp +.Ar oid +.Op NAME name +.Op DESC description +.Op OBSOLETE +.Op SUP oids +.Op Brq ABSTRACT | STRUCTURAL | AUXILIARY +.Op MUST oids +.Op MAY oids +\*(rp +.Pp +An object class definition specifies which attributes are required +and which are allowed. +For a complete description of object class definitions, see section +4.1.1 in RFC 4712. +.It objectidentifier Ar symbolic-name Ar OID +Defines a symbolic name for the object identifier. +A symbolic name can be used in place of a numeric OID in definitions +of attribute types, object classes and other symbolic OIDs. +A descendant OID can be defined in terms of another symbolic OID by appending +a numeric OID after a colon, for example: +.Bd -literal -offset indent +objectidentifier MyOidRoot 1.2.3.4 +objectidentifier MyOidAttributes MyOidRoot:5.6 +objectidentifier MyOidObjects MyOidRoot:7 +.Ed +.Pp +This would define MyOidAttributes as a symbolic name for the OID +1.2.3.4.5.6, and MyOidObjects for 1.2.3.4.7. +.El .Sh FILES .Bl -tag -width "/etc/ldap/ldapd.confXXX" -compact .It Pa /etc/ldapd.conf Default .Xr ldapd 8 configuration file. +.It Pa /etc/ldap/*.schema +Default schema definition files. .El .Sh SEE ALSO .Xr ldapctl 8 , .Xr ldapd 8 +.Rs +.%R RFC 4512 +.%T Lightweight Directory Access Protocol (LDAP): Directory Information Models +.%D June 2006 +.Re .Sh HISTORY The .Nm
