RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Paul B. Henson]

> From: Mike Jackson
> Sent: Thursday, May 15, 2014 10:44 PM
>
> Herein lies the problem: your sense of entitlement - your sense of
> entitlement to receive an answer simply because you asked someone a
> question.

Hmm, I'm not sure how continuing to engage in a discussion in which two people 
are involved demonstrates a sense of entitlement? I don't believe I have sent a 
single post on this thread that was not in response to someone else's post. Am 
I mistaken? Perhaps you could point one out? If no one replied to me, I'd stop 
posting. Clearly, as people continue to reply, they are interested in 
continuing the discussion. I'm not demanding an answer, I'm simply saying that 
if you're going to take the trouble to keep replying to the conversation, why 
not answer the actual question rather than continuously going off on tangents 
and insulting people?

> And the reason that you want that answer is so you can use
> it for the next step in whatever scheme your small little mind is
> trying to concoct.

I believe you overestimate the deviousness of my "small little" mind.

> You, personally, can not win an argument with Howard. He's far more
> intelligent than you, his grasp on technology light years ahead of
> your own and his ability to funnel an argument down to a conclusion
> puts yours to shame.

Well, I definitely concede his superiority in the department of spewing 
insults, making irrelevant demeaning comments, and most certainly in posting 
pictures of grumpy cats with snappy slogans. But personally, I find a technical 
argument much more compelling when it is not interwoven with baseless 
accusations and judgments, and turns of phrase that would be much more suitable 
in a kindergarten playground confrontation.

Do you enjoy making conclusions about others peoples abilities and skill sets 
with no evidence to back them up? When combined with your obvious pleasure in 
telling boastful stories of your own abilities and accomplishments, it makes 
one wonder if they might be signs of some type of self-confidence disorder. 
Perhaps you should see someone about that?

> Still, you continue to walk around the orchard
> where there is clearly no fruit available - wandering around looking
> for fruit to appear just because you want some.

Actually, it's more like flipping the channels on late-night TV and 
accidentally tuning in the Jerry Springer show. It's a guilty pleasure to be 
sure, but watching people make train wrecks of themselves in wild agitation is 
such schadenfreude. Yelling, screaming, insulting; if we happened to be 
speaking in person, would you be the guy that starts throwing chairs around?

> I've been going the rounds with my youngest daughter to ensure that
> she actually gets past this same thing as just one of the things she
> needs to do in order to leave her childhood selfishness behind, reach
> emotional maturity and become an adult.

If you're going to use this thread as a learning experience for your daughter, 
be sure to include the parts where it is rude to be vain and boastful, that all 
human beings deserve to be treated with some level of common courtesy and not 
insulted for no cause, and maybe not to judge people you don't actually know? 
God willing, perhaps she will grow up to be kinder and less egotistical than 
you've shown yourself to be.

> Netscape code already had dynamic configuration more than 15 years ago
> as a result of having DISA as one of their main customers should
> demonstrate to you that it's actually a feature that was needed by
> organizations with a very large userbase. Those requirements are even

I'm going to have to agree with Michael on your reading comprehension skills, 
as my input in this thread clearly demonstrates I agreed that dynamic 
configuration is important and an excellent feature. Perhaps if you go and 
reread it a couple more times, you will understand that all I ever said was 
that it would be possible to have a flat text configuration file interface to 
dynamic configuration. It seems you continue to make the mistake upon which I 
first called you out, confusing the feature (dynamic configuration) with the 
implementation (LDIF over an LDAP interface).

> Finally, if you don't like the way the project is going then do a git
> clone and stab yourself repeatedly in the eye with your own fork.
> Darwinism in action, and all that.

Does your daughter tell her friends on the playground that they should go stab 
themselves in the eye with a fork? Cause you know, saying things like that is a 
sign of a lack of emotional maturity. Would you show this thread to your 
daughter and take pride in it, and tell her "Hey, look at me! I told some guy I 
don't even know to stab himself in the eye with a fork! That showed him!"

> The summary here is that far greater minds than yours have already
> considered the problems at hand and taken appropriate action to solve
> them.

I get the feeling there are many many far greater minds than yours. But

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Michael Ströder]

Howard Chu wrote:
> Michael Ströder wrote:
>> Howard Chu wrote:
>>> Michael Ströder wrote:
 Mike Jackson wrote:
> I have built a fully automated installation system directly using
> cn=config. I
> have a file called config.ldif which contains a lot of %%MACROS%% and a 
> tiny
> perl script that replaces those macros with actual values depending on the
> details of the particular installation. So, there isn't any of this
> silliness
> of creating slapd.conf, converting it into cn=config, and then continuing 
> -
> that's an unnecessary step.
>
> After I generate the real config.ldif from the template config.ldif, I
> simply
> load it with slapadd to build my cn=config hierarchy.
>
> slapadd \
> -n0 \
> -v \
> -F ${CONF_DIR} \
> -l ldifs/config.ldif

 When using slapadd to fully load cn=config you have to stop your slapd 
 during
 that. So this is definitely *not* how cn=config is supposed to be operated.
>>>
>>> Perfectly fine for bootstrapping the initial config though.
>>
>> But the main argument for cn=config in this discussion is *modifying* the
>> configuration of a running server without taking it down. So Mike's arguing
>> with boot-strapping with slapadd is clearly a contradiction.
>>
>> IMO this is one of the main problems of OpenLDAP admins with cn=config,
>> besides lack of comments, missing support for deletion etc.:
>> Many of the instructions on the mailing list how to use back-config are not
>> really consequent. And sorry that I have to repeat my statement, this is a 
>> bit
>> consequence of the design. And i might be worth to rethink some aspects of 
>> it.
> 
> In this post I believe you're the one who has missed the point. The point is
> the cn=config format serves both needs - you can create a slapd configuration
> in pure LDIF, and you can dynamically modify it.

I understand that pretty well. Really no need to explain that.

> You seem to be arguing that cn=config is only useful for dynamic
> modification,

Nope.

My impression of this thread was that dynamic modification is used as the
strongest argument *for* cn=config. And therefore IMO pointing to using
slapadd as a configuration tool is a contradiction.

> which implies that you use some other format for your seed
> configs, which is, frankly, stupid.

At LDAPcon we already agreed that we slightly disagree. ;-)
But you confirmed that slapd.conf will not be hunked out of 2.5.
So I'm perfectly fine with that.

Ciao, Michael.




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Michael Ströder]

Paul B. Henson wrote:
>> From: Michael Ströder
>> Wir können ja auch auf Deutsch schreiben.
>> Dann habe ich den Vorteil der Muttersprache.
> 
> Was auf der Erde haben die Menschen tun, bevor Google übersetzen?

They hired better translators. ;-)

> So your native language is German, you're posting on a primarily 
> English-based mailing list, and then your signature includes an Italian 
> colloquialism ;)?

That's globalization - I guess. ;-)

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Antw: Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Ulrich Windl]

>>> Mike Jackson  schrieb am 15.05.2014 um 18:20 in Nachricht
<20140515192013.horde.4mvyb8utnuc1xnvdjjmk...@mail.netauth.com>:

> Quoting Howard Chu :
> 
>> It's not mentioned because it ought to be blindingly obvious. We  
>> provide a sample config.ldif in the Admin Guide. Only an idiot would  
>> create a format that can never be created directly, and can only be  
>> used through conversion of some other format.
> 
> I agree, but it does serve to reinforce rule number 1 of system  
> engineering: design a better system and they'll design a better idiot.

No, it's just that new people will use the system. See MS-Windows.

> 
> 
>> Doc patches are always welcome.
> 
> OK, I will prepare one. I already did a git clone.
> 
> 
> -mike

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Mike Jackson]

Quoting "Paul B. Henson" :


I will grant that I've been *asking* you for an answer to a question for far
longer than any rational person should waste time doing so, but stopping
that is entirely in your own hands - either actually answer the question
rather than deflecting, or just stop responding with tangential topics.



Herein lies the problem: your sense of entitlement - your sense of  
entitlement to receive an answer simply because you asked someone a  
question. And the reason that you want that answer is so you can use  
it for the next step in whatever scheme your small little mind is  
trying to concoct.


I've been going the rounds with my youngest daughter to ensure that  
she actually gets past this same thing as just one of the things she  
needs to do in order to leave her childhood selfishness behind, reach  
emotional maturity and become an adult.


You, personally, can not win an argument with Howard. He's far more  
intelligent than you, his grasp on technology light years ahead of  
your own and his ability to funnel an argument down to a conclusion  
puts yours to shame. Still, you continue to walk around the orchard  
where there is clearly no fruit available - wandering around looking  
for fruit to appear just because you want some.


Additionally, there's a matter at hand called evolution. One either  
adapts to a changing environment or one becomes extinct. That the  
Netscape code already had dynamic configuration more than 15 years ago  
as a result of having DISA as one of their main customers should  
demonstrate to you that it's actually a feature that was needed by  
organizations with a very large userbase. Those requirements are even  
moreso valid today than they were back in 1996 when the world was  
hoping to escape from the grasp of Nexor and the like - that  
monstrosity we, we who knew and operated things, knew as X.500.


Finally, if you don't like the way the project is going then do a git  
clone and stab yourself repeatedly in the eye with your own fork.  
Darwinism in action, and all that.


The summary here is that far greater minds than yours have already  
considered the problems at hand and taken appropriate action to solve  
them. A long time ago. And the fact that you mistake ruthless  
pragmatism for simple arrogance leaves you out of that club. Sorry.  
Case dismissed.



-mike

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Paul B. Henson]

> From: Michael Ströder
> Sent: Thursday, May 15, 2014 1:02 AM
>
> Wir können ja auch auf Deutsch schreiben.
> Dann habe ich den Vorteil der Muttersprache.

Was auf der Erde haben die Menschen tun, bevor Google übersetzen?

> Ciao, Michael.

So your native language is German, you're posting on a primarily English-based 
mailing list, and then your signature includes an Italian colloquialism ;)?

RE: Antw: RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Paul B. Henson]

> From: Ulrich Windl
> Sent: Wednesday, May 14, 2014 11:13 PM
>
> Well if you want to sync your configuration with LDAP means, the LDAP
> representation (as well as DIT metadata) makes sense.

Yes, if you eat LDAP for breakfast, lunch, and dinner, dream about LDAP, and
don't really work with anything else, then the LDAP-based configuration is
probably great for you. If you manage dozens of other services for which you
already have a well developed and flexible framework for managing
configuration files, perhaps not so much.

> > with no luck. Why on earth would I spend the amount of time and effort
it
> > would take to implement flat text config file based dynamic
> > reconfiguration
> > when I can't even get engagement on what will likely be a five line
diff? On
> 
> If you see the server as an island, modifications are trivial, but if the
server is
> part of an infrastructure, any change may break other parts of the
> infrastructure.

I'm not quite sure what you're addressing with this remark? Implementing
flat text config file reconfiguration? The five line diff for increasing the
granularity of the authentication failure attribute for the password policy
module? Something else?

> At that point one might argue that implementinc two mechanisms for the
> same thing is one too much, maybe.

Possibly. But assuming the "convert slapd.conf into LDIF" functionality
isn't going away, then flat text config file reconfiguration would really be
only a layer on top of that and the existing LDIF dynamic reconfiguration
implementation.

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Paul B. Henson]

> From: Howard Chu
> Sent: Wednesday, May 14, 2014 10:25 PM
>
> There's a difference between expressing a desire, and insisting upon it.

Yup. Can't speak for anybody else, but I'm pretty sure I've never insisted
on or demanded anything from you.

> The desire has been expressed, hooray, move on now.

That's true; but in case you missed it, this discussion for some time now
has been less about whether or not someone wants something, and more about
whether or not it could be done. At least twice if not three times now I've
suggested a hypothetical implementation that should allow dynamic
reconfiguration from flat text configuration files without that much
complexity. And while you keep sending me links and telling me about
discussions that are 10 years old, I don't believe you have even once
addressed that specific question about implementing something today, not
about not implementing something 10 years ago. I'm not insisting that you do
it, I'm not demanding that you do it, I'm not even asking you to do it, I'm
just looking for a nonbiased technical response as to whether or not it
could be done.

> In an open source project, the only people with the right to insist on how
> code should work are the people who are willing and able to make it so.

Good thing I haven't been insisting then. I notice you didn't respond to my
previous inquiry requesting mailing list archive links to those messages
where I allegedly insisted or demanded for something from you?

> You continue to insist, but you don't have the capability to implement.

As it turns out, no matter how many times you say something that isn't true,
it doesn't become true.

I will grant that I've been *asking* you for an answer to a question for far
longer than any rational person should waste time doing so, but stopping
that is entirely in your own hands - either actually answer the question
rather than deflecting, or just stop responding with tangential topics.

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Paul B. Henson]

> From: Howard Chu
> Sent: Wednesday, May 14, 2014 8:15 PM
> 
> There's no point in people writing email replies to you if you're
incapable of
> reading. If you're unwilling to read information that people provide you
in
> links, you're just wasting everyone's time.

So far I've seen a lot of links and explanations as to why you could
not/would not do it 10 years ago; an answer as to why it couldn't be fairly
readily bolted on on top of the existing LDIF dynamic reconfiguration today
(other than you don't want to), not so much. Asking one question and
continuously getting an answer to a different one is a bit of a waste of
time too.

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Mike Jackson]

Quoting Quanah Gibson-Mount :


   Convert quickstart guide to cn=config


OK, then no need for me to spend time on it.


-mike

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Mike Jackson]

Quoting Howard Chu :

It's not mentioned because it ought to be blindingly obvious. We  
provide a sample config.ldif in the Admin Guide. Only an idiot would  
create a format that can never be created directly, and can only be  
used through conversion of some other format.


I agree, but it does serve to reinforce rule number 1 of system  
engineering: design a better system and they'll design a better idiot.




Doc patches are always welcome.


OK, I will prepare one. I already did a git clone.


-mike

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Quanah Gibson-Mount]

--On May 15, 2014 at 8:32:07 AM +0300 Mike Jackson  wrote:



Quoting Quanah Gibson-Mount :


That'll work up until the point cn=config is migrated to a binary
backend such as back-mdb, and there are no flat text files to access
at all.


It'll work after that as well: you'll still be able to create n0 from
zero with slapadd in the same way that you can already create n2 from
zero with slapadd.


Yeah, sorry, I misread what you were saying.  I thought you were saying you 
were hand-editing the cn=config LDIF entries, which wouldn't be portable if 
cn=config goes to a binary format.  Since your not, never mind. ;)


--Quanah


--
Quanah Gibson-Mount
Server Architect
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Quanah Gibson-Mount]

--On May 15, 2014 at 7:03:50 AM -0700 Howard Chu  wrote:


Mike Jackson wrote:

Quoting Howard Chu :


We've never changed the names of any config attributes. The only
thing that has changed over time is adding new definitions.


So, it's not even a concern at all.


The schema is published in the cn=schema,cn=config entry. That's as
much a public interface as there'll ever be in an LDAP directory.


Well, I did consider it as a "public interface". What I meant was that
it didn't seem to be the officially sanctioned way to do things - it's
not mentioned in any of the documentation that you can bootstrap your
initial config in this way, although the attributes and such are
documented in the admin guide.


It's not mentioned because it ought to be blindingly obvious. We provide
a sample config.ldif in the Admin Guide. Only an idiot would create a
format that can never be created directly, and can only be used through
conversion of some other format.


Now that we are clear on this, would
you mind if I rewrote the Quick-Start Guide to remove slapd.conf
references and provide a clear example how to bootstrap config with an
LDIF? I'd be happy to do it.


Doc patches are always welcome.


Already done a few weeks ago.  As is of course, public record.. ;)

- Log -
commit f48242de0051380d3ec4d9bb72976f277a9ddeac
Author: Quanah Gibson-Mount 
Date:   Fri Apr 25 15:03:50 2014 -0500

   Convert quickstart guide to cn=config


--Quanah

--
Quanah Gibson-Mount
Server Architect
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Howard Chu]

Michael Ströder wrote:

Howard Chu wrote:

Michael Ströder wrote:

Mike Jackson wrote:

I have built a fully automated installation system directly using cn=config. I
have a file called config.ldif which contains a lot of %%MACROS%% and a tiny
perl script that replaces those macros with actual values depending on the
details of the particular installation. So, there isn't any of this silliness
of creating slapd.conf, converting it into cn=config, and then continuing -
that's an unnecessary step.

After I generate the real config.ldif from the template config.ldif, I simply
load it with slapadd to build my cn=config hierarchy.

slapadd \
-n0 \
-v \
-F ${CONF_DIR} \
-l ldifs/config.ldif


When using slapadd to fully load cn=config you have to stop your slapd during
that. So this is definitely *not* how cn=config is supposed to be operated.


Perfectly fine for bootstrapping the initial config though.


But the main argument for cn=config in this discussion is *modifying* the
configuration of a running server without taking it down. So Mike's arguing
with boot-strapping with slapadd is clearly a contradiction.

IMO this is one of the main problems of OpenLDAP admins with cn=config,
besides lack of comments, missing support for deletion etc.:
Many of the instructions on the mailing list how to use back-config are not
really consequent. And sorry that I have to repeat my statement, this is a bit
consequence of the design. And i might be worth to rethink some aspects of it.


In this post I believe you're the one who has missed the point. The point is 
the cn=config format serves both needs - you can create a slapd configuration 
in pure LDIF, and you can dynamically modify it. You seem to be arguing that 
cn=config is only useful for dynamic modification, which implies that you use 
some other format for your seed configs, which is, frankly, stupid.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: Antw: Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Howard Chu]

Ulrich Windl wrote:

Howard Chu  schrieb am 15.05.2014 um 05:14 in Nachricht

There's no point in people writing email replies to you if you're incapable
of
reading. If you're unwilling to read information that people provide you in
links, you're just wasting everyone's time.


But there's also no point in writing replies like "it's documented" (as if the 
writer has found it) without giving the proof (i.e.: URI).
Finding such a response in a mailing list archive is just as useless IMHO. (You 
may supress the flame that usually follows such replies).


You will note that I always specify where something is documented. In this case:


If you didn't read the debates from the openldap-devel mailing list back when 
this was first covered, you've got no business rehashing the conversation now. 
If you didn't actually spend any of your own time writing code to test an 
approach, failing, and trying another approach, you've got no right to demand 
any particular implementation from anyone else.

http://www.openldap.org/conf/odd-wien-2003/proceedings.html


Which you can plainly see in the archive 
http://www.openldap.org/lists/openldap-technical/201405/msg00105.html


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Howard Chu]

Mike Jackson wrote:

Quoting Howard Chu :


We've never changed the names of any config attributes. The only
thing that has changed over time is adding new definitions.


So, it's not even a concern at all.


The schema is published in the cn=schema,cn=config entry. That's as
much a public interface as there'll ever be in an LDAP directory.


Well, I did consider it as a "public interface". What I meant was that
it didn't seem to be the officially sanctioned way to do things - it's
not mentioned in any of the documentation that you can bootstrap your
initial config in this way, although the attributes and such are
documented in the admin guide.


It's not mentioned because it ought to be blindingly obvious. We provide a 
sample config.ldif in the Admin Guide. Only an idiot would create a format 
that can never be created directly, and can only be used through conversion of 
some other format.



Now that we are clear on this, would
you mind if I rewrote the Quick-Start Guide to remove slapd.conf
references and provide a clear example how to bootstrap config with an
LDIF? I'd be happy to do it.


Doc patches are always welcome.

--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Michael Ströder]

Mike Jackson wrote:
> Quoting Michael Ströder :
> 
>> *You* clearly don't understand what the discussion is all about.
>> And you're arguing with contradictions.
> 
> Either you are wilfully dense, or your grasp of the english language hasn't
> quite reached full maturity.

Wir können ja auch auf Deutsch schreiben.
Dann habe ich den Vorteil der Muttersprache.

> In any case, I was reverse-engineering the
> management protocols of commercial LDAP servers with ethereal so I could build
> automated installations and command-line management tools to said management
> interfaces already 15 years ago.

Do you really think you're the only one?
And where's the public proof that you really did all that?

BTW: I think I recall who you were, back then at ODD 2006.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Michael Ströder]

Howard Chu wrote:
> Michael Ströder wrote:
>> Mike Jackson wrote:
>>> I have built a fully automated installation system directly using 
>>> cn=config. I
>>> have a file called config.ldif which contains a lot of %%MACROS%% and a tiny
>>> perl script that replaces those macros with actual values depending on the
>>> details of the particular installation. So, there isn't any of this 
>>> silliness
>>> of creating slapd.conf, converting it into cn=config, and then continuing -
>>> that's an unnecessary step.
>>>
>>> After I generate the real config.ldif from the template config.ldif, I 
>>> simply
>>> load it with slapadd to build my cn=config hierarchy.
>>>
>>> slapadd \
>>>-n0 \
>>>-v \
>>>-F ${CONF_DIR} \
>>>-l ldifs/config.ldif
>>
>> When using slapadd to fully load cn=config you have to stop your slapd during
>> that. So this is definitely *not* how cn=config is supposed to be operated.
> 
> Perfectly fine for bootstrapping the initial config though.

But the main argument for cn=config in this discussion is *modifying* the
configuration of a running server without taking it down. So Mike's arguing
with boot-strapping with slapadd is clearly a contradiction.

IMO this is one of the main problems of OpenLDAP admins with cn=config,
besides lack of comments, missing support for deletion etc.:
Many of the instructions on the mailing list how to use back-config are not
really consequent. And sorry that I have to repeat my statement, this is a bit
consequence of the design. And i might be worth to rethink some aspects of it.

In the past you've argued that one should point out issues more clearly. But
people will only put effort into it if there is some willingness shown by you
to really consider suggestions.

>> Also when mucking directly with the LDIF you loose slapd's capability of 
>> input
>> validation.
> 
> You can muck with input to slapadd all you want. It will still get basic
> validation.

Regarding validation it's still in some cases a big difference whether an
entry is added with slapadd or via LDAP.

Ciao, Michael.




smime.p7s
Description: S/MIME Cryptographic Signature

Antw: Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Ulrich Windl]

>>> Howard Chu  schrieb am 15.05.2014 um 05:14 in Nachricht
<53743120.9040...@symas.com>:
> Paul B. Henson wrote:
>>> There's no excuse for ignorance when the links have already been posted
>> and
>>> everything is published on the www.openldap.org website.
>>
>> May I see a show of hands as to who has reviewed the entirety of the
>> www.openldap.org website, including all of the mailing list threads,
>> presentations, topics linked to, and FAQs? Didn't raise your hand? Please
>> unsubscribe from the list immediately and stop pestering Howard with your
>> uninformed and ignorant postings.
> 
> Standard netiquette is that you search for topics before posting. The 
> standard 
> welcome message for these lists already tell you to search the archives 
> before 
> asking a question that has already been asked and answered.
> 
> There's no point in people writing email replies to you if you're incapable 
> of 
> reading. If you're unwilling to read information that people provide you in 
> links, you're just wasting everyone's time.

But there's also no point in writing replies like "it's documented" (as if the 
writer has found it) without giving the proof (i.e.: URI).
Finding such a response in a mailing list archive is just as useless IMHO. (You 
may supress the flame that usually follows such replies).

> 
> -- 
>-- Howard Chu
>CTO, Symas Corp.   http://www.symas.com 
>Director, Highland Sun http://highlandsun.com/hyc/ 
>Chief Architect, OpenLDAP  http://www.openldap.org/project/ 

Antw: RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Ulrich Windl]

>>> "Paul B. Henson"  schrieb am 14.05.2014 um 22:18 in 
>>> Nachricht
<0ce601cf6fb1$b6199c60$224cd520$@acm.org>:
>>  From: Howard Chu
>> Sent: Tuesday, May 13, 2014 10:41 PM
>>
>> If you didn't actually spend any of your own time writing code to test an
>> approach, failing, and trying another approach, you've got no right to
>> demand any particular implementation from anyone else.
> 
> I'm sorry, I must not be remembering the message in which I demanded you do 
> anything. Could you possibly send a link to the list archives pointing it 
> out?
> 
> As I recall, I simply said that dynamic reconfiguration could be done via 
> rereading the flat text configuration file, and that the developers chose not 
> to do so then and choose not to do so now. Both of which are factually true. 
> Perhaps the basis for your venomous and unnecessary personal attacks is what 
> you read into my message that wasn't actually there?

Well if you want to sync your configuration with LDAP means, the LDAP 
representation (as well as DIT metadata) makes sense.

> 
> I've been trying to get a message I posted to the developers list regarding 
> a trivial extension of the password policy module to support microsecond 
> granularity for authentication failures approved and delivered for two weeks 
> with no luck. Why on earth would I spend the amount of time and effort it 
> would take to implement flat text config file based dynamic reconfiguration 
> when I can't even get engagement on what will likely be a five line diff? On 

If you see the server as an island, modifications are trivial, but if the 
server is part of an infrastructure, any change may break other parts of the 
infrastructure.

> top of which, you've already made it clear that you would not accept an 
> implementation of dynamic reconfiguration from flat text configuration files 
> even if it existed and functioned perfectly, so it would be an exercise in 
> utter futility, even more so than this discussion.

At that point one might argue that implementinc two mechanisms for the same 
thing is one too much, maybe.

I'm not an OpenLDAP developer...

Regards,
Ulrich

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Mike Jackson]

Quoting Howard Chu :


We've never changed the names of any config attributes. The only 
thing that has changed over time is adding new definitions.


So, it's not even a concern at all.


The schema is published in the cn=schema,cn=config entry. That's as 
much a public interface as there'll ever be in an LDAP directory.


Well, I did consider it as a "public interface". What I meant was that  
it didn't seem to be the officially sanctioned way to do things - it's  
not mentioned in any of the documentation that you can bootstrap your  
initial config in this way, although the attributes and such are  
documented in the admin guide. Now that we are clear on this, would  
you mind if I rewrote the Quick-Start Guide to remove slapd.conf  
references and provide a clear example how to bootstrap config with an  
LDIF? I'd be happy to do it.


-mike

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Mike Jackson]

Quoting Quanah Gibson-Mount :


That'll work up until the point cn=config is migrated to a binary  
backend such as back-mdb, and there are no flat text files to access  
at all.


It'll work after that as well: you'll still be able to create n0 from  
zero with slapadd in the same way that you can already create n2 from  
zero with slapadd.

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Howard Chu]

Paul B. Henson wrote:

From: Howard Chu



No. That's experience too.


Yes, you have plenty of experience at telling people who express the desire,
need, or requirement for plaintext configuration that they don't really
desire, need, or require plaintext configuration, that they are morons, have
no basis for an opinion, have nothing to contribute to the discussion,
clearly have no development skills, and perhaps should have never been born
in the first place.


There's a difference between expressing a desire, and insisting upon it. The 
desire has been expressed, hooray, move on now.


In an open source project, the only people with the right to insist on how 
code should work are the people who are willing and able to make it so. You 
continue to insist, but you don't have the capability to implement.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Howard Chu]

Paul B. Henson wrote:

There's no excuse for ignorance when the links have already been posted

and

everything is published on the www.openldap.org website.


May I see a show of hands as to who has reviewed the entirety of the
www.openldap.org website, including all of the mailing list threads,
presentations, topics linked to, and FAQs? Didn't raise your hand? Please
unsubscribe from the list immediately and stop pestering Howard with your
uninformed and ignorant postings.


Standard netiquette is that you search for topics before posting. The standard 
welcome message for these lists already tell you to search the archives before 
asking a question that has already been asked and answered.


There's no point in people writing email replies to you if you're incapable of 
reading. If you're unwilling to read information that people provide you in 
links, you're just wasting everyone's time.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Paul B. Henson]

> From: Howard Chu
> Sent: Wednesday, May 14, 2014 6:41 PM
>
> Not at all. My position is still that we tried multiple alternatives and
ruled
> them out.

Yes, 10 odd years ago you looked at reloading a flat text configuration file
and decided not to do it. And since not a single thing could have possibly
changed in that 10 years, there's absolutely no reason to ever consider it
again. After all, since signals and multithreaded programs were a bad
combination 10 years ago, there's no way that signals and multithreaded
programs could possibly work today, right? Just like 10 years ago there were
no other options other than signals, such as UNIX sockets, to control a
program externally. A decision made is a decision finalized, and pity the
fool who might want to reconsider it, even if only as an abstract
hypothetical.

> > And you're still acting as if nobody has ever posted to the mailing list
in
> > favor of keeping the plaintext configuration, and of having the feature
of
> > dynamic reconfiguration from the plaintext configuration, which is just
plain
> > egocentric.
> 
> No. That's experience too.

Yes, you have plenty of experience at telling people who express the desire,
need, or requirement for plaintext configuration that they don't really
desire, need, or require plaintext configuration, that they are morons, have
no basis for an opinion, have nothing to contribute to the discussion,
clearly have no development skills, and perhaps should have never been born
in the first place.

> There's no excuse for ignorance when the links have already been posted
and
> everything is published on the www.openldap.org website.

May I see a show of hands as to who has reviewed the entirety of the
www.openldap.org website, including all of the mailing list threads,
presentations, topics linked to, and FAQs? Didn't raise your hand? Please
unsubscribe from the list immediately and stop pestering Howard with your
uninformed and ignorant postings.

You already have the framework for dynamic reconfiguration. If the guts are
LDIF, more power to them. But there's nothing magic about feeding that
framework LDIF. Given the ability to turn a plaintext slapd.conf into LDIF
(which exists), the ability to take two LDIF files and generate a third LDIF
file that turns the first into the second (which exists), it seems it's
really not that much glue required to hook all that together and feed your
dynamic reconfiguration framework the LDIF it wants based on the changes
between two flat text configuration files. Disregarding the fact that you
don't want to do it, disregarding the fact you don't want it done, and maybe
even staying on track with the technical discussion and not diverging onto a
tangent about how my great great great grandfather was too incompetent to
shoe a horse, why exactly is it that such a design is infeasible,
impracticable, and impossible to implement? Obviously you couldn't do this
10 years ago before you had the existing LDIF based reconfiguration
framework, so saying you couldn't do this 10 years ago is not really a valid
justification as to why it could not be done now...

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Brett @Google]

On Thu, May 15, 2014 at 10:48 AM, Paul B. Henson  wrote:

> > https://www.facebook.com/georgehtakei/photos/a.223098324386295.105
> > 971.205344452828349/908340742528713/?type=1
>
> Ah, yes, the grumpy cat meme. Posting pictures of grumpy cats never fails
> to help solidify the soundness and accuracy of one's arguments. I counter
> your grumpy cat position with a happy cat rebuttal:
>
> http://breakappz.com/wp-content/uploads/2014/02/happycat.jpg


I raise your happy cat, to 10 interesting facts about bunnies :)

http://www.clickreadshare.com/10-facts-never-knew-bunny-rabbits/

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Howard Chu]

Paul B. Henson wrote:

From: Howard Chu
Sent: Wednesday, May 14, 2014 4:43 PM

If it's not the best design, then it's not worth doing.


So you're changing your position from "it's impossible to do" to "it's not worth 
doing"?


Not at all. My position is still that we tried multiple alternatives and ruled 
them out. That's experience, not opinion. You have no experience.



You're still acting as
if nobody ever considered what you're suggesting, which is just plain
ignorant.


And you're still acting as if nobody has ever posted to the mailing list
in

favor of keeping the plaintext configuration, and of having the feature of
dynamic reconfiguration from the plaintext configuration, which is just plain
egocentric.

No. That's experience too.


I apologize, Dr. Chu, could you please repost the syllabus and study guide


There's no excuse for ignorance when the links have already been posted and 
everything is published on the www.openldap.org website.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Paul B. Henson]

> From: Howard Chu
> Sent: Wednesday, May 14, 2014 4:43 PM
> 
> If it's not the best design, then it's not worth doing.

So you're changing your position from "it's impossible to do" to "it's not 
worth doing"?

> You're still acting as
> if nobody ever considered what you're suggesting, which is just plain
> ignorant.

And you're still acting as if nobody has ever posted to the mailing list in 
favor of keeping the plaintext configuration, and of having the feature of 
dynamic reconfiguration from the plaintext configuration, which is just plain 
egocentric.

> You still have nothing worthwhile to contribute to this topic.

So you say. Yet clearly you still feel compelled to continue to attempt to 
refute any argument I raise; it seems that if I were only generating noise it 
would be far simpler to ignore it and let it fade into the background…

> https://www.facebook.com/georgehtakei/photos/a.223098324386295.105
> 971.205344452828349/908340742528713/?type=1

Ah, yes, the grumpy cat meme. Posting pictures of grumpy cats never fails to 
help solidify the soundness and accuracy of one's arguments. I counter your 
grumpy cat position with a happy cat rebuttal:

http://breakappz.com/wp-content/uploads/2014/02/happycat.jpg

No snappy slogan, but happy cats need no caption to make their point.

> You haven't done enough homework to justify having an alternative
> viewpoint.

I apologize, Dr. Chu, could you please repost the syllabus and study guide that 
might lead one to a full and complete understanding of everything you've ever 
said, done, or looked at in your lifespan? Perhaps if they ever achieve cloning 
a human being along with all of their knowledge and memories, you might 
actually have someone you consider worthy of corresponding with without 
childish tantrums and and taunting?

Sheesh.

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Howard Chu]

Paul B. Henson wrote:

From: Howard Chu
Sent: Wednesday, May 14, 2014 1:20 PM

A technical debate can only productively occur between parties that both
understand the issues at hand. You clearly don't, and had no business joining
the debate.


Nice way to short-circuit a debate. "You don't understand the issues, you lose."


It would save a lot of time.


Actually, I do understand the issue; you are right, everyone who disagrees

with you or expresses an alternative viewpoint is wrong. Perhaps reloading
flat text configuration files wasn't the best design then, perhaps it isn't
the best design now, but it's certainly *possible*, which is all that I'm
saying.

If it's not the best design, then it's not worth doing. You're still acting as 
if nobody ever considered what you're suggesting, which is just plain 
ignorant. You still have nothing worthwhile to contribute to this topic.


Just for you:

https://www.facebook.com/georgehtakei/photos/a.223098324386295.105971.205344452828349/908340742528713/?type=1

You haven't done enough homework to justify having an alternative viewpoint.

--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Paul B. Henson]

On Thu, May 15, 2014 at 01:28:16AM +0300, Mike Jackson wrote:

> I was reverse-engineering the management protocols of commercial LDAP
> servers with ethereal so I could build automated installations and
> command-line management tools to said management interfaces already 15
> years ago.

So, when might we expect your memoirs to be published? It seems you have
done so many interesting things in your life. You didn't perchance
happen to walk barefoot ten miles through the snow to get to the
computer with ethereal on it? That would certainly add a dash of spice
to the story, which is always helpful when one hopes to make the
bestsellers list.

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Stephan Fabel]

On 05/13/2014 12:55 PM, Howard Chu wrote:
> LDAP administrators have to know how LDIF works anyway. LDAP 
> administrators have to know about ldapsearch/add/modify 
> slapadd/slapcat anyway. LDAP administrators have to know how to read 
> schema anyway. This is, in fact, shortening the learning curve for 
> brand new admins.

Having been exposed to OpenLDAP for the first time two and a half years
ago, I can attest that this was true, at least for me. Not that it
wasn't a frustrating journey.

For me, lack of _context_ surrounding for example, configuration
options, was more difficult than learning LDIF, client tools or server
configuration, though.

Hugs & Kisses,

Stephan

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Howard Chu]

Mike Jackson wrote:


Quoting Michael Ströder :


When using slapadd to fully load cn=config you have to stop your slapd during
that. So this is definitely *not* how cn=config is supposed to be operated.
Also when mucking directly with the LDIF you loose slapd's
capability of input
validation.

Ciao, Michael.


Please read my post more carefully and understand it before commenting.

Slapd has never been started at this point so there's nothing to stop.
It doesn't have any configuration at all. I don't muck with the LDIF,
I generate it. If you take a little time to study the cn=config
entries, you'll see that it's not exactly rocket science to write or
generate your own. The only real concern is that the attribute names
or something change over time and I have to adapt my template, in


We've never changed the names of any config attributes. The only thing that 
has changed over time is adding new definitions.



other words it's not declared as a public interface but it really
should be. You can even keep it in git (my template is certainly in
git).


The schema is published in the cn=schema,cn=config entry. That's as much a 
public interface as there'll ever be in an LDAP directory.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Quanah Gibson-Mount]

--On May 15, 2014 at 12:58:30 AM +0300 Mike Jackson  wrote:

Please read my post more carefully and understand it before commenting.

Slapd has never been started at this point so there's nothing to stop. It
doesn't have any configuration at all. I don't muck with the LDIF, I
generate it. If you take a little time to study the cn=config entries,
you'll see that it's not exactly rocket science to write or generate your
own. The only real concern is that the attribute names or something
change over time and I have to adapt my template, in other words it's not
declared as a public interface but it really should be. You can even keep
it in git (my template is certainly in git).


That'll work up until the point cn=config is migrated to a binary backend 
such as back-mdb, and there are no flat text files to access at all.


--Quanah


--
Quanah Gibson-Mount
Server Architect
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Brett Maxfield]

On 15 May 2014, at 6:21 am, "Paul B. Henson"  wrote:

>> From: Mike Jackson
>> Sent: Tuesday, May 13, 2014 10:59 PM
>> 
>> you're simply not important  in the grand scheme of things.
>> 
>> So before you all go blowing smoke out of your asses, Stroeder, that
>> includes you, too, it might be wise not to underestimate with whom you
>> are speaking.
> 
> The ego is strong with this one.

Lol. And the award goes to??

I think it would be impossible to decide.. 

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Paul B. Henson]

On Wed, May 14, 2014 at 11:57:22PM +0200, Michael Ströder wrote:

> Well, judging from your postings my impression of your analytical skills are
> pretty precise.

Hey now, you do realize that back in 2002-2003, as a *core architect*, Mike
*personally* made the decision regarding which LDAP server software to use
for a mobile network management system that *still* has a *very large* market
share? *And* he had dinner with Howard in Tuebingen? And that not only did
he attend the developers conference but he *brought* a *friend* to
*boot*? And that while *you've* never contributed *anything* but
*complaints*, *he's* ... oh, wait:

$ git log | grep mich...@stroeder.com | wc -l
2

$ git log | grep m...@netauth.com | wc -l
0
$ git log | grep Jackson | wc -l
0


Be sure not to underestimate with whom you are speaking 8-/.

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Mike Jackson]

Quoting Michael Ströder :


*You* clearly don't understand what the discussion is all about.
And you're arguing with contradictions.



Either you are wilfully dense, or your grasp of the english language  
hasn't quite reached full maturity. In any case, I was  
reverse-engineering the management protocols of commercial LDAP  
servers with ethereal so I could build automated installations and  
command-line management tools to said management interfaces already 15  
years ago. And you still don't have a grasp of this concept today.  
What have you been doing with your time if your knowledge still hasn't  
advanced after 15 years?



-mike

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Howard Chu]

Michael Ströder wrote:

Mike Jackson wrote:

I have built a fully automated installation system directly using cn=config. I
have a file called config.ldif which contains a lot of %%MACROS%% and a tiny
perl script that replaces those macros with actual values depending on the
details of the particular installation. So, there isn't any of this silliness
of creating slapd.conf, converting it into cn=config, and then continuing -
that's an unnecessary step.

After I generate the real config.ldif from the template config.ldif, I simply
load it with slapadd to build my cn=config hierarchy.

slapadd \
   -n0 \
   -v \
   -F ${CONF_DIR} \
   -l ldifs/config.ldif


When using slapadd to fully load cn=config you have to stop your slapd during
that. So this is definitely *not* how cn=config is supposed to be operated.


Perfectly fine for bootstrapping the initial config though.


Also when mucking directly with the LDIF you loose slapd's capability of input
validation.


You can muck with input to slapadd all you want. It will still get basic 
validation.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Michael Ströder]

Mike Jackson wrote:
> 
> Quoting Michael Ströder :
> 
>> When using slapadd to fully load cn=config you have to stop your slapd during
>> that. So this is definitely *not* how cn=config is supposed to be operated.
>> Also when mucking directly with the LDIF you loose slapd's capability of 
>> input
>> validation.
>
> Please read my post more carefully and understand it before commenting.
> 
> Slapd has never been started at this point so there's nothing to stop. It
> doesn't have any configuration at all. I don't muck with the LDIF, I generate
> it. If you take a little time to study the cn=config entries, you'll see that
> it's not exactly rocket science to write or generate your own.

Be assured that I did study cn=config schema in depth.

> The only real
> concern is that the attribute names or something change over time and I have
> to adapt my template, in other words it's not declared as a public interface
> but it really should be. You can even keep it in git (my template is certainly
> in git).

*You* clearly don't understand what the discussion is all about.
And you're arguing with contradictions.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Mike Jackson]

Quoting Michael Ströder :


When using slapadd to fully load cn=config you have to stop your slapd during
that. So this is definitely *not* how cn=config is supposed to be operated.
Also when mucking directly with the LDIF you loose slapd's  
capability of input

validation.

Ciao, Michael.


Please read my post more carefully and understand it before commenting.

Slapd has never been started at this point so there's nothing to stop.  
It doesn't have any configuration at all. I don't muck with the LDIF,  
I generate it. If you take a little time to study the cn=config  
entries, you'll see that it's not exactly rocket science to write or  
generate your own. The only real concern is that the attribute names  
or something change over time and I have to adapt my template, in  
other words it's not declared as a public interface but it really  
should be. You can even keep it in git (my template is certainly in  
git).




-mike

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Michael Ströder]

Mike Jackson wrote:
> So before you all go blowing smoke out of your asses, Stroeder, that includes
> you, too, it might be wise not to underestimate with whom you are speaking.

Well, judging from your postings my impression of your analytical skills are
pretty precise.

Ciao, Michael.




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Michael Ströder]

Mike Jackson wrote:
> I have built a fully automated installation system directly using cn=config. I
> have a file called config.ldif which contains a lot of %%MACROS%% and a tiny
> perl script that replaces those macros with actual values depending on the
> details of the particular installation. So, there isn't any of this silliness
> of creating slapd.conf, converting it into cn=config, and then continuing -
> that's an unnecessary step.
> 
> After I generate the real config.ldif from the template config.ldif, I simply
> load it with slapadd to build my cn=config hierarchy.
> 
> slapadd \
>   -n0 \
>   -v \
>   -F ${CONF_DIR} \
>   -l ldifs/config.ldif

When using slapadd to fully load cn=config you have to stop your slapd during
that. So this is definitely *not* how cn=config is supposed to be operated.
Also when mucking directly with the LDIF you loose slapd's capability of input
validation.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Michael Ströder]

Brett @Google wrote:
> But can we reliably create the slap.d config file with deployment scripts
> directly, as it also seems to just be text.

That's *not* the official way of doing it. The general recommendation on this
mailing list has always been not to touch the LDIF files in slapd.d/ directly.
Especially input validation cannot be performed in this case.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Paul B. Henson]

> From: Howard Chu
> Sent: Wednesday, May 14, 2014 1:20 PM
>
> A technical debate can only productively occur between parties that both
> understand the issues at hand. You clearly don't, and had no business joining
> the debate.

Nice way to short-circuit a debate. "You don't understand the issues, you lose."

Actually, I do understand the issue; you are right, everyone who disagrees with 
you or expresses an alternative viewpoint is wrong. Perhaps reloading flat text 
configuration files wasn't the best design then, perhaps it isn't the best 
design now, but it's certainly *possible*, which is all that I'm saying. I'm 
not saying I'm going to do it, I'm not demanding that you do it, I am simply 
saying it can be done. Hell, you already have a function that converts a 
slapd.conf into ldif format. Given two slapd.conf files, convert them both into 
ldif, run an ldifdiff on them to generate the ldif modifying the first into the 
second, and feed that into the existing ldif-based dynamic reconfiguration 
code. It can be done. You choose not to do it.

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Paul B. Henson]

> From: Mike Jackson
> Sent: Tuesday, May 13, 2014 10:59 PM
>
> you're simply not important  in the grand scheme of things.
>
> So before you all go blowing smoke out of your asses, Stroeder, that
> includes you, too, it might be wise not to underestimate with whom you
> are speaking.

The ego is strong with this one.

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Howard Chu]

Paul B. Henson wrote:

From: Howard Chu
Sent: Tuesday, May 13, 2014 6:35 PM

You're not a developer and clearly unable to write code that behaves as you 
suggest.

[...]

Your opinion is worthless noise.

[...]

Your examples are irrelevant and not applicable.

[...]

But hey moron, that didn't work with threaded programs.

[...]

If you were a developer you might be aware of this
fact. But you're not, and you have no valid basis for any opinion

[...]

You're clearly not qualified to do the work yourself.


You aren't by any chance the long-lost separated at birth twin of Theo de

Raadt? You seem to share the great skill of turning what should be a technical
debate into a circus of baseless insults, groundless accusations, and ad
hominem attacks.

A technical debate can only productively occur between parties that both 
understand the issues at hand. You clearly don't, and had no business joining 
the debate.


If you had done your homework (it's not hard, everything is on 
www.openldap.org), read up on everything that had been considered and tried 
before, and understood anything about writing code, you might have had 
something useful to contribute. The fact (not opinion) is you didn't, and you 
don't. Irresponsible posts like yours deserve flames, not respect.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Paul B. Henson]

> From: Howard Chu
> Sent: Tuesday, May 13, 2014 10:41 PM
>
> If you didn't actually spend any of your own time writing code to test an
> approach, failing, and trying another approach, you've got no right to
> demand any particular implementation from anyone else.

I'm sorry, I must not be remembering the message in which I demanded you do 
anything. Could you possibly send a link to the list archives pointing it out?

As I recall, I simply said that dynamic reconfiguration could be done via 
rereading the flat text configuration file, and that the developers chose not 
to do so then and choose not to do so now. Both of which are factually true. 
Perhaps the basis for your venomous and unnecessary personal attacks is what 
you read into my message that wasn't actually there?

I've been trying to get a message I posted to the developers list regarding a 
trivial extension of the password policy module to support microsecond 
granularity for authentication failures approved and delivered for two weeks 
with no luck. Why on earth would I spend the amount of time and effort it would 
take to implement flat text config file based dynamic reconfiguration when I 
can't even get engagement on what will likely be a five line diff? On top of 
which, you've already made it clear that you would not accept an implementation 
of dynamic reconfiguration from flat text configuration files even if it 
existed and functioned perfectly, so it would be an exercise in utter futility, 
even more so than this discussion.

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Paul B. Henson]

> From: Howard Chu
> Sent: Tuesday, May 13, 2014 6:35 PM
>
> You're not a developer and clearly unable to write code that behaves as you 
> suggest.
[...] 
> Your opinion is worthless noise.
[...]
> Your examples are irrelevant and not applicable.
[...]
> But hey moron, that didn't work with threaded programs.
[...]
> If you were a developer you might be aware of this
> fact. But you're not, and you have no valid basis for any opinion
[...]
> You're clearly not qualified to do the work yourself.

You aren't by any chance the long-lost separated at birth twin of Theo de 
Raadt? You seem to share the great skill of turning what should be a technical 
debate into a circus of baseless insults, groundless accusations, and ad 
hominem attacks.

On the other hand, both of you are brilliant in your own ways, so I guess what 
god takes with one hand he gives with the other.

I already told you I was not going to continue this argument, it's like trying 
to talk the sun into not casting shadows...

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Mike Jackson]

Quoting "Brett @Google" :



But the benefits come from synergy of using ldap as the internal config
structure should not be overlooked, there are strongly typed data storage,
fast lookups, and reams of boilerplate code being thrown away. But
presently we still need a binary (executable) to turn that cn=config text
format into something slapd can boot up and use. Given the text ->
cn=config code is present already, is there really that much work to
leaving it there?


Since the cn=config is simply the conversion of one LDIF file into a  
hierarchical directory structure of LDIF files, there isn't any  
conversion needed for slapd to be able to use it or write to it for  
that matter - slapadd already exists. Only thing that is needed is  
some filesystem directory traversal logic in order to write out the  
LDIF hierarchy.



But can we reliably create the slap.d config file with deployment scripts
directly, as it also seems to just be text.


I have built a fully automated installation system directly using  
cn=config. I have a file called config.ldif which contains a lot of  
%%MACROS%% and a tiny perl script that replaces those macros with  
actual values depending on the details of the particular installation.  
So, there isn't any of this silliness of creating slapd.conf,  
converting it into cn=config, and then continuing - that's an  
unnecessary step.


After I generate the real config.ldif from the template config.ldif, I  
simply load it with slapadd to build my cn=config hierarchy.


slapadd \
  -n0 \
  -v \
  -F ${CONF_DIR} \
  -l ldifs/config.ldif


Repeat the process to load the DIT skeleton into n2 with slapadd,  
slapindex n2 (needed if the DIT skeleton is huge like mine), fire up  
the server and do the rest of the work.


My cn=config is replicated across servers so that access control,  
tuning, and indices, for example, only need to be added to one server  
over the wire. And they only need to be dumped from one server, over  
the wire. That is a workable management interface.


My entire installation system: TLS certs, replication, DIT skeleton,  
service admin users, access control, tuning, indexing, everything - it  
takes less than 2 minutes and is 100% hands free.



-mike

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Brett @Google]

>
> Yes for a solution for arbitrarily large networks cn=config could be
> more scalable and cheaper. But that's not true for a small server for a
> small organization that doesn't need the extra complexity.
>
> I don't want to understate the pros of cn=config, I just state my
> opinion about the cons. If you tell me the maintaining slapd.conf is too
> costly in terms of developers energies I've nothing to say. But I don't
> agree that cn=config is always better.
>
>
There is not much difference between a slapd.conf and an .ldif of the
cn=config information, just a different text format.

But the benefits come from synergy of using ldap as the internal config
structure should not be overlooked, there are strongly typed data storage,
fast lookups, and reams of boilerplate code being thrown away. But
presently we still need a binary (executable) to turn that cn=config text
format into something slapd can boot up and use. Given the text ->
cn=config code is present already, is there really that much work to
leaving it there?

But can we reliably create the slap.d config file with deployment scripts
directly, as it also seems to just be text.

Other than being nicer to read, is there really anything wrong with the
(already) text format of cn=config on the disk ?

There are some gotchas with the conf file, in any case. Config options mean
different things in different places etc.,

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Mike Jackson]

Quoting "Paul B. Henson" :



Really? It's amazing then how other enterprise scale software  
packages such as Apache httpd managed to survive using flat text  
file configuration models without inventing secure remote  
administration protocols for deploying that configuration.


Apache httpd was not responsible for providing core services and  
management interfaces inside of telecom networks (it was even so  
unsuitable as a middleware platform that java was used instead). LDAP,  
on the other hand was, and is a core component of every telecom  
network in existence.


Things like, oh I don't know, being able to dynamically crank up the  
logging level without disconnecting your clients in order to respond  
to and investigate alarms... Those are sort of important and stuff,  
you know, for a network to which 50 million phones are connected.


Back in 2002-2003, as a core architect I personally made the decision  
regarding which LDAP server software to use for a mobile network  
management system that still has a very large market share. If you use  
a mobile phone, chances are high that you are supported still today by  
the system I designed and implemented. I wrote a scathing report about  
the capabilities of OpenLDAP at the time, and I even shared it with  
Howard IIRC. I'm pretty sure I also discussed it with him in person in  
Tuebingen over dinner. OpenLDAP was not my choice, even though I did  
attend the developers conference and bring along a friend to boot.


Needless to say, the situation is completely reversed today and given  
the current capabilities of OpenLDAP, I wouldn't recommend anything  
else. Howard and crew have done one hell of a job positioning OpenLDAP  
so that it can be used inside the telecom arena. Little IT shops where  
you want LDAP to authenticate 10 users and you are never going to  
contribute anything except for complaints, you're simply not important  
in the grand scheme of things.


So before you all go blowing smoke out of your asses, Stroeder, that  
includes you, too, it might be wise not to underestimate with whom you  
are speaking.



-mike

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Howard Chu]

Paul B. Henson wrote:

You can reply to this if you like, but I'm done with the debate, as
clearly

you will never accept an alternative viewpoint and banging my head against a
concrete wall is not my favorite hobby. While I have great respect for your
skills and knowledge, and great appreciation for your work with openldap, I
think your opinion on this particular topic is a bit too artificially ingrained.

You really think what you're suggesting wasn't suggested already, 12 years 
ago? You really think we didn't already *try* it and see that it didn't work? 
This is why advice and opinions from people like you is utterly worthless. If 
you didn't participate in the work leading up to the current implementation, 
and didn't walk through the code and previous designs, and don't understand 
the coding implications of a particular approach, then you've got nothing 
valid to contribute to the topic.


If you didn't read the debates from the openldap-devel mailing list back when 
this was first covered, you've got no business rehashing the conversation now. 
If you didn't actually spend any of your own time writing code to test an 
approach, failing, and trying another approach, you've got no right to demand 
any particular implementation from anyone else.


http://www.openldap.org/conf/odd-wien-2003/proceedings.html

--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Howard Chu]

Paul B. Henson wrote:

From: Howard Chu
Sent: Tuesday, May 13, 2014 3:56 PM

It was the only sane choice, and as you are not a developer and were not
participating in the design discussions back in 2002-2003 you're not in any
position to comment or critique on it. And judging from your commentary,
you're not qualified to offer an opinion.


I see, you're going to go with the "your opinion differs from mine;

therefore, you are clearly not qualified to have an opinion" argument?

No, I'm going with the "where were you with your bright ideas when we needed 
help designing and implementing this?" argument. You're not a developer and 
clearly unable to write code that behaves as you suggest. Nor are you anywhere 
volunteering to sponsor such work.


Meanwhile, you have no concept of the programming constraints that led to the 
decisions we made, nor sufficient background to appreciate their significance.


Your opinion is worthless noise.


As a systems administrator who has been managing large-scale distributed

systems since the mid-90s, I think I do actually have the qualifications to
have an opinion on configuration management.



It's all well and fine for you to say "sure they could have kept the flat text
file" but we would have had to invent a remote administration protocol and
all of its required security mechanisms.


Really? It's amazing then how other enterprise scale software packages
such

as Apache httpd managed to survive using flat text file configuration models
without inventing secure remote administration protocols for deploying that
configuration.


Again, you're mixing up two things – how configuration is processed, and
how

configuration is delivered. You are tightly coupling two things that do not
need to be coupled, basically decreeing by fiat that only that configuration
which arrives over the LDAP protocol may be dynamically placed into effect. If
someone already has a secure way of delivering flat text file configuration
updates, too bad, they don't get to be dynamically applied. Not because it's
impossible to reload a configuration file and apply the changes, but because
you don't want to do it.



stupid, when we already have highly evolved protocol, data model, and
security mechanisms in place. Keep in mind that none of
puppet/chef/cfengine/what-have-you existed or were in common use in that
timeframe.


Perhaps, but in the late 90s, before this design discussion that I didn't

participate in even took place, I already had secure mechanisms for delivering
configuration files to large distributed networks of systems.

Your examples are irrelevant and not applicable.

I've been writing server code since the 1980s. Yes, it was common practice 
back in the day to allow manual rewriting of config files and sending a server 
a SIGHUP to tell it to reread its config. But hey moron, that didn't work with 
threaded programs. Signal handling wreaked havoc with the threading 
implementations of the day. If you were a developer you might be aware of this 
fact. But you're not, and you have no valid basis for any opinion of how the 
code should have been implemented.



Nor can you sanely reload an entire slapd.conf file without doing a bunch of
redundant parsing, to skip over the parts that didn't change. It's a lot of
work simply to find the parts that didn't change, unless you invent a network
protocol that lets you send deltas. But oh wait, we already have a protocol
with that - we can use the LDAPModify operation.


I don't think I ever claimed it wouldn't involve some additional code,
some

additional work, to allow dynamic reconfiguration from rereading a flat text
configuration; I simply claimed it is possible. And "redundant" or not,
parsing a configuration file into a configuration structure is hardly
intractable, nor is running through the existing in-place configuration and
comparing it to the new configuration just loaded in determining the 
differences.

How kind of you to volunteer someone else to go to all the trouble of donating 
the additional work required to implement a non-viable mechanism. That's not 
how open source development works. If you want a feature, you either write it 
or you sponsor its development. You're clearly not qualified to do the work 
yourself. In this particular case, it's pointless anyway because the feature 
you're requesting, to make slapd behave like every other historical Unix 
daemon, is a non-starter.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Paul B. Henson]

> From: Howard Chu
> Sent: Tuesday, May 13, 2014 3:59 PM
>
> That's not really dynamic configuration. Anything that requires you to
> physically login to a server to issue a change is not scalable. With cn=config
> you can delegate configuration privileges across an arbitrarily large network,
> without requiring any host/OS privileges.

Ah, yes, the "I'm going to redefine terminology so your argument is no longer 
valid" approach.

I never said I had to or planned to physically login to a server to make a 
change. I simply said that reloading a flat text configuration file and 
applying any configuration changes in it is a valid and reasonable approach. 
Perhaps in a scenario where the person managing the LDAP server configuration 
does not have any operating system privileges, your feature would be 
invaluable. But in an environment where the person managing the operating 
system configuration itself is also managing the LDAP server configuration, it 
is meaningless. What next, you're going to offer the feature for slapd to proxy 
changes to the operating system configuration files via the LDAP interface? You 
just don't seem to understand or accept that deployment scenarios other than 
the one you envision exist, are useful, or should be supported, and that the 
ability to manage openldap via existing infrastructure that is already managing 
other systems and applications is a valuable feature.

> Most people didn't "need" electricity when they still had oil lamps...

Many people still drive a manual transmission vehicle even after the widespread 
availability of the automatic transmission. See, I can spew irrelevant 
platitudes too…

You can reply to this if you like, but I'm done with the debate, as clearly you 
will never accept an alternative viewpoint and banging my head against a 
concrete wall is not my favorite hobby. While I have great respect for your 
skills and knowledge, and great appreciation for your work with openldap, I 
think your opinion on this particular topic is a bit too artificially ingrained.

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Paul B. Henson]

> From: Howard Chu
> Sent: Tuesday, May 13, 2014 3:56 PM
>
> It was the only sane choice, and as you are not a developer and were not
> participating in the design discussions back in 2002-2003 you're not in any
> position to comment or critique on it. And judging from your commentary,
> you're not qualified to offer an opinion.

I see, you're going to go with the "your opinion differs from mine; therefore, 
you are clearly not qualified to have an opinion" argument?

As a systems administrator who has been managing large-scale distributed 
systems since the mid-90s, I think I do actually have the qualifications to 
have an opinion on configuration management.

> It's all well and fine for you to say "sure they could have kept the flat text
> file" but we would have had to invent a remote administration protocol and
> all of its required security mechanisms.

Really? It's amazing then how other enterprise scale software packages such as 
Apache httpd managed to survive using flat text file configuration models 
without inventing secure remote administration protocols for deploying that 
configuration.

Again, you're mixing up two things – how configuration is processed, and how 
configuration is delivered. You are tightly coupling two things that do not 
need to be coupled, basically decreeing by fiat that only that configuration 
which arrives over the LDAP protocol may be dynamically placed into effect. If 
someone already has a secure way of delivering flat text file configuration 
updates, too bad, they don't get to be dynamically applied. Not because it's 
impossible to reload a configuration file and apply the changes, but because 
you don't want to do it.

> stupid, when we already have highly evolved protocol, data model, and
> security mechanisms in place. Keep in mind that none of
> puppet/chef/cfengine/what-have-you existed or were in common use in that
> timeframe.

Perhaps, but in the late 90s, before this design discussion that I didn't 
participate in even took place, I already had secure mechanisms for delivering 
configuration files to large distributed networks of systems.

> You cannot sanely rewrite a slapd.conf file from machine-generated code
> and
> expect it to resemble the original input.

I have no expectation that you will rewrite my slapd.conf. My expectation is 
that *I* will rewrite my slapd.conf, and then slapd will reread it and apply 
the change configuration.

> Nor can you sanely reload an entire slapd.conf file without doing a bunch of
> redundant parsing, to skip over the parts that didn't change. It's a lot of
> work simply to find the parts that didn't change, unless you invent a network
> protocol that lets you send deltas. But oh wait, we already have a protocol
> with that - we can use the LDAPModify operation.

I don't think I ever claimed it wouldn't involve some additional code, some 
additional work, to allow dynamic reconfiguration from rereading a flat text 
configuration; I simply claimed it is possible. And "redundant" or not, parsing 
a configuration file into a configuration structure is hardly intractable, nor 
is running through the existing in-place configuration and comparing it to the 
new configuration just loaded in determining the differences.

> Only a moron would have chosen any other design path than the one we
> took.

All those morons that would really really really like the ability to have slapd 
dynamically reload its configuration from a changed flat text file, please 
raise your hands? Based on the mailing list archives, there seem to be quite a 
few of us. And I guess now we have degenerated to the "if you wouldn't have 
done it the way I did, you're a moron" argument.

> Any
> other path would have been tons of redundant code, redundant processing,
> and
> still caused complaints from clueless ungrateful users because it transformed
> their sloppily constructed config files into something else.

Assuming the implementation of what I would actually want, not the 
implementation you are currently imagining I would want, that is blatantly 
false, as nothing would ever touch the configuration file other than the user 
or their agent. The whole point is I don't want something *else* touching my 
configuration files, I want my *configuration management system* generating 
them.

> You're entirely mistaken. LDAP administrators have to know how LDIF works
> anyway. LDAP administrators have to know about ldapsearch/add/modify
> slapadd/slapcat anyway. LDAP administrators have to know how to read
> schema
> anyway. This is, in fact, shortening the learning curve for brand new admins.

By that argument, apache administrators need to know how http works, so it 
would only make sense to manage an apache server configuration via HTTP PUT. 
And bind administrators clearly do need to know the details of the DNS 
protocol, so it only makes sense to manage named configuration via secure dns 
updates. Anybody running samba should surely know the details o

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Simone Piccardi]

On 14/05/2014 00:58, Howard Chu wrote:
> Most people didn't "need" electricity when they still had oil lamps...
> 
If I'm going in a cave almost everytime I still need an oil lamp.
Bringing there electricity can be far more costly.

Yes for a solution for arbitrarily large networks cn=config could be
more scalable and cheaper. But that's not true for a small server for a
small organization that doesn't need the extra complexity.

I don't want to understate the pros of cn=config, I just state my
opinion about the cons. If you tell me the maintaining slapd.conf is too
costly in terms of developers energies I've nothing to say. But I don't
agree that cn=config is always better.

Simone

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Howard Chu]

Simone Piccardi wrote:

On 13/05/2014 11:01, Mike Jackson wrote:


In any case, dynamic configuration IS an enterprise-grade/carrier-grade
feature as opposed to static configuration.


I don't need anything of this. I just need a simple LDAP server for a
small business, where the complexity of dynamic configuration is just a
cost with no benefit.

And anyway a lot of services (bind, apache, posfix just to name a few)
implemented dynamic configuration by the means of a kill -HUP.


That's not really dynamic configuration. Anything that requires you to 
physically login to a server to issue a change is not scalable. With cn=config 
you can delegate configuration privileges across an arbitrarily large network, 
without requiring any host/OS privileges.


Most people didn't "need" electricity when they still had oil lamps...

--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Howard Chu]

Paul B. Henson wrote:

From: Mike Jackson
Sent: Tuesday, May 13, 2014 2:02 AM

In any case, dynamic configuration IS an
enterprise-grade/carrier-grade feature as opposed to static
configuration. It enables you to perform critical adjustments to your
service without interrupting your service (more or less depending on
the implementation).


You seem to be confusing the concept of "dynamic configuration", the
ability

to change the configuration of a running service without having to stop said
service or disrupt providing the service, with the concept of where the
configuration is stored, in a flat text file or in a database.


There is absolutely no reason why openldap could not support dynamic

configuration when the configuration is stored in a flat text file. There are
numerous examples of services which store their configuration in a flat text
file, and are capable of rereading that file and dynamically changing the
running configuration based on the changes found.


Yes, the current implementation of openldap only supports dynamic

configuration when the configuration is stored in an LDAP database, but that
is not an inherent limitation of storing configuration in a flat text file,
but simply the preference of the openldap developers. If they chose to do so,
they could absolutely implement a similar dynamic configuration for flat text
file configuration. The merits of flat text versus LDAP database configuration
have been debated to no end, and I don't intend to reopen that discussion, but
rather simply to point out it was a choice and not a restriction.

It was the only sane choice, and as you are not a developer and were not 
participating in the design discussions back in 2002-2003 you're not in any 
position to comment or critique on it. And judging from your commentary, 
you're not qualified to offer an opinion.


It's all well and fine for you to say "sure they could have kept the flat text 
file" but we would have had to invent a remote administration protocol and all 
of its required security mechanisms. Reinventing those wheels would have been 
stupid, when we already have highly evolved protocol, data model, and security 
mechanisms in place. Keep in mind that none of 
puppet/chef/cfengine/what-have-you existed or were in common use in that 
timeframe.


You cannot sanely rewrite a slapd.conf file from machine-generated code and 
expect it to resemble the original input. Since sysadmins tended to be sloppy 
and put config directives where they didn't belong, it was guaranteed that any 
dynamically modified file would still be reorganized relative to the input. 
Nor can you sanely reload an entire slapd.conf file without doing a bunch of 
redundant parsing, to skip over the parts that didn't change. It's a lot of 
work simply to find the parts that didn't change, unless you invent a network 
protocol that lets you send deltas. But oh wait, we already have a protocol 
with that - we can use the LDAPModify operation.


Only a moron would have chosen any other design path than the one we took. Any 
other path would have been tons of redundant code, redundant processing, and 
still caused complaints from clueless ungrateful users because it transformed 
their sloppily constructed config files into something else.



If you don't see why dynamic configuration is a good idea, then you
probably shouldn't be using LDAP for anything too important, anyway.


I guess if we're going to play at being haughty, perhaps people that
cannot

differentiate between where the configuration is stored and how it is
processed shouldn't be using LDAP for anything too important, anyway…



I personally believe that support for static configuration should be
removed already because having two different configuration systems in
place serves to confuse a lot of people, especially learners.


That statement is true; but if you had to pick which configuration system

confused more people, especially learners, it wouldn't be the flat text file
implementation…

You're entirely mistaken. LDAP administrators have to know how LDIF works 
anyway. LDAP administrators have to know about ldapsearch/add/modify 
slapadd/slapcat anyway. LDAP administrators have to know how to read schema 
anyway. This is, in fact, shortening the learning curve for brand new admins. 
You're just too stuck in your flatland ways to recognize that fact.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Matheus Eduardo Bonifacio Morais]

Well, I can say that I operate OpenLDAP at an "enterprise" level and the
configuration do not change very often here. The dynamic configuration
is something that could be useful but definetly is not required for me.

I also think the term "enterprise-grade" is misleading. There is a lot
of junk software out there which call themselves "enterprise solution"
but in fact are just garbage. I can give a list of LDAP servers which
have dynamic configuration but can't scale, can't keep data sync between
the servers, fail frequently and etc.

At the end of the day the most important thing for me and business
people is stability/performance and if one can't configure OpenLDAP with
all man pages and documentation that it have, maybe it's in the wrong role.

Em 13-05-2014 16:47, Simone Piccardi escreveu:
> On 13/05/2014 11:01, Mike Jackson wrote:
> 
>> In any case, dynamic configuration IS an enterprise-grade/carrier-grade
>> feature as opposed to static configuration.
> 
> I don't need anything of this. I just need a simple LDAP server for a
> small business, where the complexity of dynamic configuration is just a
> cost with no benefit.
> 
> And anyway a lot of services (bind, apache, posfix just to name a few)
> implemented dynamic configuration by the means of a kill -HUP.
> 
> Simone
> 
> 
> 
> Esta mensagem é somente para uso do destinatário informado e pode conter 
> informações privilegiadas, proprietárias, ou privadas. Se você recebeu esta 
> mensagem por engano, por favor notifique o remetente imediatamente e apague a 
> original. Qualquer uso deste email é proibido. 
> This message is for the designated recipient only and may contain privileged, 
> proprietary, or otherwise private information. If you have received it in 
> error, please notify the sender immediately and delete the original. Any 
> other use of the email by you is prohibited.
> 


-- 
Matheus Morais
Plataforma e Aplicações de TI
Confederação SICREDI - Porto Alegre
51 3358-7143
http://www.sicredi.com.br

www.sicredi.com.br



Esta mensagem é somente para uso do destinatário informado e pode conter 
informações privilegiadas, proprietárias, ou privadas. Se você recebeu esta 
mensagem por engano, por favor notifique o remetente imediatamente e apague a 
original. Qualquer uso deste email é proibido. 
This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise private information. If you have received it in 
error, please notify the sender immediately and delete the original. Any other 
use of the email by you is prohibited.


signature.asc
Description: OpenPGP digital signature

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Simone Piccardi]

On 13/05/2014 11:01, Mike Jackson wrote:

> In any case, dynamic configuration IS an enterprise-grade/carrier-grade
> feature as opposed to static configuration.

I don't need anything of this. I just need a simple LDAP server for a
small business, where the complexity of dynamic configuration is just a
cost with no benefit.

And anyway a lot of services (bind, apache, posfix just to name a few)
implemented dynamic configuration by the means of a kill -HUP.

Simone

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Paul B. Henson]

> From: Mike Jackson
> Sent: Tuesday, May 13, 2014 2:02 AM
>
> In any case, dynamic configuration IS an
> enterprise-grade/carrier-grade feature as opposed to static
> configuration. It enables you to perform critical adjustments to your
> service without interrupting your service (more or less depending on
> the implementation).

You seem to be confusing the concept of "dynamic configuration", the ability to 
change the configuration of a running service without having to stop said 
service or disrupt providing the service, with the concept of where the 
configuration is stored, in a flat text file or in a database.

There is absolutely no reason why openldap could not support dynamic 
configuration when the configuration is stored in a flat text file. There are 
numerous examples of services which store their configuration in a flat text 
file, and are capable of rereading that file and dynamically changing the 
running configuration based on the changes found.

Yes, the current implementation of openldap only supports dynamic configuration 
when the configuration is stored in an LDAP database, but that is not an 
inherent limitation of storing configuration in a flat text file, but simply 
the preference of the openldap developers. If they chose to do so, they could 
absolutely implement a similar dynamic configuration for flat text file 
configuration. The merits of flat text versus LDAP database configuration have 
been debated to no end, and I don't intend to reopen that discussion, but 
rather simply to point out it was a choice and not a restriction.

> If you don't see why dynamic configuration is a good idea, then you
> probably shouldn't be using LDAP for anything too important, anyway.

I guess if we're going to play at being haughty, perhaps people that cannot 
differentiate between where the configuration is stored and how it is processed 
shouldn't be using LDAP for anything too important, anyway…

> I personally believe that support for static configuration should be
> removed already because having two different configuration systems in
> place serves to confuse a lot of people, especially learners.

That statement is true; but if you had to pick which configuration system 
confused more people, especially learners, it wouldn't be the flat text file 
implementation…

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Michael Ströder]

Mike Jackson wrote:
> Quoting Christian Kratzer :
>>
>> as has been said before several times.  There is no reason to lose your
>> ability to put your configs into version control when you move to cn=config.
>>
>> - You can check the output from slapcat -n0 into your vcs.
> 
> "You" in my message referring to the OP, not you Christian.
> 
> Or you can ldapsearch it from a backup script running on a cron job. Or you
> can cd into the config directory and do a git init.

We've discussed that here many times:
IMO it's a big difference to export a running configuration in your VCS just
for the records or to control the configuration in VCS before rollout.

For me doing the VCS actions *before* rolling out the configuration to all the
slapd instances gives much more control especially if you have to roll *back*
something. And think of staging. And slapd-config does not handle deletion =>
rollback can be very hard.

Also orchestrated rollout of changes might spread across other systems as
well. E.g. when I'm deploying schema changes in slapd I have to change the
web-based admin UI as well etc.

> In any case, dynamic configuration IS an enterprise-grade/carrier-grade
> feature as opposed to static configuration. It enables you to perform critical
> adjustments to your service without interrupting your service (more or less
> depending on the implementation). I have built multilevel LDAP clusters where
> there were over 15000 simultaneous persistent connections from mobile network
> elements checking RBAC against management actions and believe me, static
> configuration would have been a showstopper if I needed to restart LDAP
> services just to expand my capacity (adding new replicas, etc).

Nonsense. If HA is important you must have decent load-balancers in front of
your servers and know how to operate them.

> If you don't see why dynamic configuration is a good idea, then you probably
> shouldn't be using LDAP for anything too important, anyway.

Ah, and you are the one and only *real* expert.

Strange enough my customers are running mission-critical OpenLDAP deployments
with static configuration - since years.

> I personally believe that support for static configuration should be removed
> already because having two different configuration systems in place serves to
> confuse a lot of people, especially learners.

Complete nonsense.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Mike Jackson]

Quoting Christian Kratzer :


as has been said before several times.  There is no reason to lose  
your ability to put your configs into version control when you move  
to cn=config.


- You can check the output from slapcat -n0 into your vcs.


"You" in my message referring to the OP, not you Christian.

Or you can ldapsearch it from a backup script running on a cron job.  
Or you can cd into the config directory and do a git init.


In any case, dynamic configuration IS an  
enterprise-grade/carrier-grade feature as opposed to static  
configuration. It enables you to perform critical adjustments to your  
service without interrupting your service (more or less depending on  
the implementation). I have built multilevel LDAP clusters where there  
were over 15000 simultaneous persistent connections from mobile  
network elements checking RBAC against management actions and believe  
me, static configuration would have been a showstopper if I needed to  
restart LDAP services just to expand my capacity (adding new replicas,  
etc).


If you don't see why dynamic configuration is a good idea, then you  
probably shouldn't be using LDAP for anything too important, anyway.


I personally believe that support for static configuration should be  
removed already because having two different configuration systems in  
place serves to confuse a lot of people, especially learners.



-mike

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Christian Kratzer]

Hi,

On Thu, 6 Feb 2014, Andy Dorman wrote:

On 02/06/2014 03:28 PM, Paul B. Henson wrote:

From: Michael Ströder
Sent: Saturday, February 01, 2014 2:45 AM

As Howard confirmed on this mailing list static configuration will still

be

available in OpenLDAP 2.5.x.


Really? I didn't see that; my last understanding was that it was deprecated
in 2.4 and was going to be removed in 2.5. Sweet, that means I can push off
dealing with the conversion for much longer :).



Just FWIW, we also have the configs for our different OpenLDAP databases on 
various servers under git version control.  This provides us with a critical, 
time-stamped audit trail and documentation for all changes along with a fast, 
reliable method for reverting to earlier configs should it become necessary.


We would very much hate to lose that audit-trail & documentation and control. 
;-)


as has been said before several times.  There is no reason to lose your ability 
to put your configs into version control when you move to cn=config.

- You can check the output from slapcat -n0 into your vcs.

- You can revert to an older configuration from your version control by using 
slapadd -n0.

- You can use ldapdiff between old and new versions and generate deltas that 
you could apply with ldapmodify.

- etc ...

Greetings
Christian

--
Christian Kratzer   CK Software GmbH
Email:   c...@cksoft.de   Wildberger Weg 24/2
Phone:   +49 7032 893 997 - 0   D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9   HRB 245288, Amtsgericht Stuttgart
Mobile:  +49 171 1947 843   Geschaeftsfuehrer: Christian Kratzer
Web: http://www.cksoft.de/

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Andy Dorman]

On 02/06/2014 03:28 PM, Paul B. Henson wrote:

From: Michael Ströder
Sent: Saturday, February 01, 2014 2:45 AM

As Howard confirmed on this mailing list static configuration will still

be

available in OpenLDAP 2.5.x.


Really? I didn't see that; my last understanding was that it was deprecated
in 2.4 and was going to be removed in 2.5. Sweet, that means I can push off
dealing with the conversion for much longer :).



Just FWIW, we also have the configs for our different OpenLDAP databases 
on various servers under git version control.  This provides us with a 
critical, time-stamped audit trail and documentation for all changes 
along with a fast, reliable method for reverting to earlier configs 
should it become necessary.


We would very much hate to lose that audit-trail & documentation and 
control. ;-)


--
Andy Dorman
Ironic Design, Inc.
AnteSpam.com, ComeHome.net

CONFIDENTIALITY NOTICE: This message is for the named person's use only. 
It may contain confidential, proprietary or legally privileged 
information. No confidentiality or privilege is waived or lost by any 
erroneous transmission. If you receive this message in error, please 
immediately destroy it and notify the sender. You must not, directly or 
indirectly, use, disclose, distribute, or copy any part of this message 
if you are not the intended recipient.

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Brett @Google]

We have run openldap for some years, and it runs very well, but it's a fair
comment for openldap to include a simple installation script, to get a
server installed for the new B. That would encourage evaluation and
adoption.

OpenDJ has one, it asks for base, port, hostname, if ssl is required, etc.,
and optionally includes a bunch of randomly generated data for testing or
proof of concept type applications. If ssl is requested, it just generates
a self signed certificate and installs it. Some people have pretty
straightforward ldap requirements.

People who do this sort of birds eye or top down review, aren't going to
spend more than an hour or two, even if they try, which it seems this one
didn't. This article seems to me to be no more than a re-hash of other
people's experiences with openldap, and they did not install themselves.
But the ideas re-hashed

I can download a copy of OpenDJ, run the setup script and at the end of the
install the server is running and configured. It has a dynamic
configuration backend, but it has a command line interface for day to day
usage. And the config.ldif can be hand edited if you do something
unexpected like sexy up the listening port, which stops the server from
starting.

I don't mean to make this a sales spiel, but my point is, there should be
some notion of new B friendliness. Also i know plenty of busy computer
operators who look after many different bit of software, and are not
interested in the details of the server, they want to start / stop,
diagnose problems, and move on to something else. Time is an issue.

I don't think as much of the idea of a configuration tui/gui for openldap
though, as you'd always be tweaking the interface to batch the config
backend. But i think a optimal solution of a dynamic config backend is to
go in this ease of maintenance direction, otherwise you are just
sweeping the rats under the rug.

I dont see how the RHEL package issues can be fixed, other than :

#!/bin/sh
echo "This package is too old, download  and run the auto-build-rhel.sh
script!"

There is no such script, AFAIK but it would be nice. Install required
packages & libraries, warn about library conflicts, etc.,

Cheers
Brett

On Fri, Jan 31, 2014 at 2:35 AM, Howard Chu  wrote:

> Gavin Henry wrote:
>
>> http://searchdatacenter.techtarget.com/feature/IT-pros-suffer-OpenLDAP-
>> configuration-headaches
>>
>> Any one been in touch with them?
>>
>
> I saw some of this on twitter before, ignored it since none of the parties
> involved have any clue what they're talking about.
>
> --
>   -- Howard Chu
>   CTO, Symas Corp.   http://www.symas.com
>   Director, Highland Sun http://highlandsun.com/hyc/
>   Chief Architect, OpenLDAP  http://www.openldap.org/project/
>
>


-- 
Whenever you find yourself on the side of the majority, it is time to pause
and reflect.

- Mark Twain

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[harry . jede]

Howard Chu wrote:
> harry.j...@arcor.de wrote:
> > #!/bin/sed -rf
> > # Author: Harry Jede
> > # produce human readable but still machine parseable
> > # olcAccess lines and removes the ordering numbers in {}
> > # because humans don't need them, really.
> 
> Nice formatting, but just a note - the ordering prefixes are there to
> allow you to insert new ACLs in the precise spot where they belong.
> So in fact, human or machine, they are necessary. We wouldn't throw
> things in there for no reason.
I know this. The reason why you have created the ordering prefixes is 
that without them the ordering is *not* always the same during multiple 
searches.


> 
> Otherwise, to insert one rule in front of existing rules, you would
> need to delete and reinsert all of the rules.
Dacor.
For documenting, comparing, testing or creating access to new databases 
I found that this is my favorite approach.

And during some support sessions by customers I found that one of the 
common failures during access design, is that customers failed to order 
the "to clause" of access rules. In such cases I retrieve the access 
rules, reorder them with an editor, and upload all at once wih 
ldapmodify. And yes, slapd adds the ordering prefixes in line order of 
the ldif file. Magic and cool.

If I need to modify or add single rules, i still use the script to 
retrieve, but without the olcacces line. Now I can create ldifs for 
ldapmodify with ordering prefix. The "by clauses" are one at a line. 
That's better for my eys.

# cat $(which fmt_olcAccess2)
#!/bin/sed -rf
# Author: Harry Jede
# produce human readable but still machine parseable
# olcAccess lines
# the hole script
$!{H;d}
${H;g;s/\n //g;s/[[:space:]]+by /\n  by /g}

the output is now with prefixes.



-- 

Harry Jede

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Howard Chu]

harry.j...@arcor.de wrote:


#!/bin/sed -rf
# Author: Harry Jede
# produce human readable but still machine parseable
# olcAccess lines and removes the ordering numbers in {}
# because humans don't need them, really.


Nice formatting, but just a note - the ordering prefixes are there to allow 
you to insert new ACLs in the precise spot where they belong. So in fact, 
human or machine, they are necessary. We wouldn't throw things in there for no 
reason.


Otherwise, to insert one rule in front of existing rules, you would need to 
delete and reinsert all of the rules.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[harry . jede]

Simone Piccardi wrote:
> On 07/02/2014 18:36, Quanah Gibson-Mount wrote:
> > --On Friday, February 07, 2014 2:25 PM +0100 Simone Piccardi
> > 
> >  wrote:
> >> Not to mention that slapd.conf is still far more readable that any
> >> slapd.d ldif...
> > 
> > Definitely not.  slapd.conf allows people to put things in all
> > sorts of random order that slapd "fixes" when it reads in the
> > slapd.conf file.
> 
> I never got any problem with it having always used a it in a correct
> order with well commented directives. But if ordering is needed not
> having it enforced in the file configuration syntax is a design
> defect of slapd, not a shortcoming of using a text file for
> configuration.
> 
> > cn=config enforces correct ordering, so with cn=config you can tell
> > exactly what is happening, where it can be a muddled mess with
> > slapd.conf.
> 
> Using apache, postfix, bind, and so on I usually know quite well what
> is happening, just having a text configuration file. And I can use a
> generic text editor to modify it, and I don't need to feed the
> configuration to the program using some dedicated tool or talking
> the specific protocol they are serving.
> 
> I agree that the current slapd.conf has lot problems and is prone to
> abuse, and if you tell me that rewriting it in a saner way or simply
> mantaining it is too much a burden for developers, I will not raise
> any further objection.
> 
> But this does not change the fact that slapd.conf is far more
> readable than a cn=config ldif file, were the use of LDIF syntax
> force the use of that ugly curly brace index prefix to order things,
you are right, but is is easy to reformat things

> and make visible irrelevant (for the sake of configuration)
> informations like entryCSN, createTimestamp, and the like.
> 
> Perhaps I'm just getting old, but I still prefer the traditional Unix
> way to configure services, by the simple use of human (almost)
> readable text configuration files.
same to me ;-) but ldif may also looks nice

# ldapsearch -LLLY external -H ldapi:/// -b 'cn=config' '(olcaccess=*)' 
olcaccess 2>/dev/null|fmt_olcAccess

dn: olcDatabase={-1}frontend,cn=config
olcAccess: to *
  by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage
  by * break
olcAccess: to dn.exact=""
  by * read
olcAccess: to dn.base="cn=Subschema"
  by * read

dn: olcDatabase={0}config,cn=config
olcAccess: to *
  by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage
  by * break

dn: olcDatabase={1}hdb,cn=config
olcAccess: to attrs=userPassword,shadowLastChange
  by self write
  by anonymous auth
  by dn="cn=admin,dc=kronprinz,dc=xx" write
  by * none
olcAccess: to dn.base=""
  by * read
olcAccess: to *
  by self write
  by dn="cn=admin,dc=kronprinz,dc=xx" write
  by * read

# cat $(which fmt_olcAccess)

#!/bin/sed -rf
# Author: Harry Jede
# produce human readable but still machine parseable
# olcAccess lines and removes the ordering numbers in {}
# because humans don't need them, really.

# the hole script
s/^(olcAccess: )\{[[:digit:]]+\}(.*$)/\1\2/
$!{H;d}
${H;g;s/\n //g;s/[[:space:]]+by /\n  by /g}



> 
> Regards
> Simone


-- 

Harry Jede

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Michael Ströder]

Quanah Gibson-Mount wrote:
> --On Friday, February 07, 2014 2:25 PM +0100 Simone Piccardi
>  wrote:
> 
>> Not to mention that slapd.conf is still far more readable that any
>> slapd.d ldif...
> 
> Definitely not.  slapd.conf allows people to put things in all sorts of random
> order that slapd "fixes" when it reads in the slapd.conf file.

It's not fair to argue with idiots messing up their slapd.conf file.

My slapd.conf files are readable, in correct order and with lots of comments
and this is indeed much more readable than back-config LDIF files.

Ciao, Michael.




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Michael Ströder]

Christopher Wood wrote:
> On Fri, Feb 07, 2014 at 02:25:45PM +0100, Simone Piccardi wrote:
>> these last two are far usually done with a service restart, or, when
>> the service support the online changes, with a service reload or a
>> kill -HUP.
> 
> Therein lies the issue with the text config file for some of us - we are
> not able to interrupt the ldap service which supports critical
> customer-facing services. Or, more specifically, we are not able to
> interrupt ldap service without floods of really grumpy master tickets. The
> cn=config layout really helps here.

If you have strong HA requirements you have to run with decent load-balancers
in front of your LDAP servers anyway. So restarting replicas one after another
is not really a big deal.

> For my part I had ldap bootstrapped via puppet into a full cn=config
> supplier/consumer multimaster setup, but I never got as far as a
> type/provider to configure ACLs or anything.

Well, it seems there's a choice of whether to use back-config or config file.

Ciao, Michael.




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Michael Ströder]

Paul B. Henson wrote:
>> From: Quanah Gibson-Mount
>> Sent: Friday, January 31, 2014 6:03 PM
>>
>> Our servers do a nightly backup of cn=config via slapcat -n 0, and those
>> are kept for a month.  Since this is for clients, there's no revision
>> control involved, but it would be trivial for someone to check in the
>> resulting LDIF file into their favorite RCS system.
> 
> Hmm, so the revision control system would transition from being the
> authoritative source of what the configuration is (ie, in our current
> system, if somehow the running configuration deviated from the version in
> revision control, it would automatically be corrected back) to simply
> becoming a record of whatever changes happen to have been made on the
> running configuration?

Especially I'm not keen on allowing a CRON job with a clear-text credential in
a config file to commit into the VCS. Also you don't have meaningful commit
messages when doing so.

Ciao, Michael.




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Simone Piccardi]

On 07/02/2014 18:36, Quanah Gibson-Mount wrote:
> --On Friday, February 07, 2014 2:25 PM +0100 Simone Piccardi
>  wrote:
> 
>> Not to mention that slapd.conf is still far more readable that any
>> slapd.d ldif...
> 
> Definitely not.  slapd.conf allows people to put things in all sorts of
> random order that slapd "fixes" when it reads in the slapd.conf file.

I never got any problem with it having always used a it in a correct
order with well commented directives. But if ordering is needed not
having it enforced in the file configuration syntax is a design defect
of slapd, not a shortcoming of using a text file for configuration.

> cn=config enforces correct ordering, so with cn=config you can tell
> exactly what is happening, where it can be a muddled mess with slapd.conf.
> 

Using apache, postfix, bind, and so on I usually know quite well what is
happening, just having a text configuration file. And I can use a
generic text editor to modify it, and I don't need to feed the
configuration to the program using some dedicated tool or talking the
specific protocol they are serving.

I agree that the current slapd.conf has lot problems and is prone to
abuse, and if you tell me that rewriting it in a saner way or simply
mantaining it is too much a burden for developers, I will not raise any
further objection.

But this does not change the fact that slapd.conf is far more readable
than a cn=config ldif file, were the use of LDIF syntax force the use of
that ugly curly brace index prefix to order things, and make visible
irrelevant (for the sake of configuration) informations like entryCSN,
createTimestamp, and the like.

Perhaps I'm just getting old, but I still prefer the traditional Unix
way to configure services, by the simple use of human (almost) readable
text configuration files.

Regards
Simone
-- 
Simone Piccardi - KeyID:2A972F9D - JabberID:picca...@truelite.it
http://piccardi.gnulinux.it - http://www.fountainpen.it
Prima ti ignorano, poi ti deridono, poi ti combattono.  Poi vinci.
 M. K. Ghandi

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Quanah Gibson-Mount]

--On Friday, February 07, 2014 2:25 PM +0100 Simone Piccardi 
 wrote:



Not to mention that slapd.conf is still far more readable that any
slapd.d ldif...


Definitely not.  slapd.conf allows people to put things in all sorts of 
random order that slapd "fixes" when it reads in the slapd.conf file. 
cn=config enforces correct ordering, so with cn=config you can tell exactly 
what is happening, where it can be a muddled mess with slapd.conf.


--Quanah


--

Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Christopher Wood]

On Fri, Feb 07, 2014 at 02:25:45PM +0100, Simone Piccardi wrote:

(SNIP)

> these last two are far usually done with a service restart, or, when
> the service support the online changes, with a service reload or a
> kill -HUP.

Therein lies the issue with the text config file for some of us - we are not 
able to interrupt the ldap service which supports critical customer-facing 
services. Or, more specifically, we are not able to interrupt ldap service 
without floods of really grumpy master tickets. The cn=config layout really 
helps here.

For my part I had ldap bootstrapped via puppet into a full cn=config 
supplier/consumer multimaster setup, but I never got as far as a type/provider 
to configure ACLs or anything.

(SNIP)

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Simone Piccardi]

On 02/07/2014 01:00 PM, Aaron Richton wrote:

(human on workstation)
$RCS checkout repo/production.slapd.conf
$EDITOR !$
$RCS checkin repo/production.slapd.conf

(magical config overlord/human on server)
$RCS checkout repo/production.slapd.conf
cp repo/production.slapd.conf /server/production.slapd.conf
pkill slapd
slapd


these last two are far usually done with a service restart, or, when the 
service support the online changes, with a service reload or a kill -HUP.



or slapd.d:

(human on workstation)
$RCS checkout repo/production.slapd.ldif
$EDITOR !$
$RCS checkin repo/production.slapd.ldif

(magical config overlord/human on server)
$RCS checkout repo/production.slapd.ldif
ldifdiff /server/production.slapd.ldif repo/production.slapd.ldif >
/tmp/diff.ldif
ldapmodify [...] -f /tmp/diff.ldif
slapcat -n0 -l /server/production.slapd.ldif

These both end up with the same state, and it's the same number of
commands!


As noted before is usually shorter, I can put comment in the file about 
the change I done, and reverting it is done by using the previous file, 
and having coherent data and doing modification does not depends in 
using specialized software over different files.


Not to mention that slapd.conf is still far more readable that any 
slapd.d ldif...


Regards
Simone
--
Simone Piccardi Truelite Srl
picca...@truelite.it (email/jabber) Via Monferrato, 6
Tel. +39-347-103243350142 Firenze
http://www.truelite.it  Tel. +39-055-7879597Fax. +39-055-736

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Michael Ströder]

Aaron Richton  wrote
> On Thu, 6 Feb 2014, Paul B. Henson wrote:
> 
> >> Our servers do a nightly backup of cn=config via slapcat -n 0, and 
> >> those are kept for a month.  Since this is for clients, there's no 
> >> revision control involved, but it would be trivial for someone to check 
> >> in the resulting LDIF file into their favorite RCS system.
> >
> > Hmm, so the revision control system would transition from being the 
> > authoritative source of what the configuration is (ie, in our current 
> > system, if somehow the running configuration deviated from the version 
> > in revision control, it would automatically be corrected back) to simply 
> > becoming a record of whatever changes happen to have been made on the 
> > running configuration?
> 
> Off the top of my head, I'm not really seeing this. With slapd.conf:
> 
> (human on workstation)
> $RCS checkout repo/production.slapd.conf
> $EDITOR !$
> $RCS checkin repo/production.slapd.conf
> 
> (magical config overlord/human on server)
> $RCS checkout repo/production.slapd.conf
> cp repo/production.slapd.conf /server/production.slapd.conf
> pkill slapd
> slapd
> 
> 
> or slapd.d:
> 
> (human on workstation)
> $RCS checkout repo/production.slapd.ldif
> $EDITOR !$
> $RCS checkin repo/production.slapd.ldif
> 
> (magical config overlord/human on server)
> $RCS checkout repo/production.slapd.ldif
> ldifdiff /server/production.slapd.ldif repo/production.slapd.ldif >
> /tmp/diff.ldif ldapmodify [...] -f /tmp/diff.ldif
> slapcat -n0 -l /server/production.slapd.ldif
> 
> These both end up with the same state, and it's the same number of 
> commands! You can checkout and revert to the latest head/trunk/etc. or any 
> arbitrary rev with either config format. Monitoring in-core vs. on-disk 
> vs. expected-in-production committed config is possible in both cases and 
> actually easier/more comprehensive with cn=config. If "magical config 
> overlord" is a cron job then "automatically be corrected" happens with 
> both of these workflows. How are your hands tied in this case?

I'm checking in the VCS and from there the automated configuration (puppet,
ansible etc.) does the rest of it. Automatically diffing config DBs and apply
the changes is far more complicated than diffing text files. Especially the
latter gives you far better text logs of which changes were done.

Ciao, Michael.

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Aaron Richton]

On Thu, 6 Feb 2014, Paul B. Henson wrote:

Our servers do a nightly backup of cn=config via slapcat -n 0, and 
those are kept for a month.  Since this is for clients, there's no 
revision control involved, but it would be trivial for someone to check 
in the resulting LDIF file into their favorite RCS system.


Hmm, so the revision control system would transition from being the 
authoritative source of what the configuration is (ie, in our current 
system, if somehow the running configuration deviated from the version 
in revision control, it would automatically be corrected back) to simply 
becoming a record of whatever changes happen to have been made on the 
running configuration?


Off the top of my head, I'm not really seeing this. With slapd.conf:

(human on workstation)
$RCS checkout repo/production.slapd.conf
$EDITOR !$
$RCS checkin repo/production.slapd.conf

(magical config overlord/human on server)
$RCS checkout repo/production.slapd.conf
cp repo/production.slapd.conf /server/production.slapd.conf
pkill slapd
slapd


or slapd.d:

(human on workstation)
$RCS checkout repo/production.slapd.ldif
$EDITOR !$
$RCS checkin repo/production.slapd.ldif

(magical config overlord/human on server)
$RCS checkout repo/production.slapd.ldif
ldifdiff /server/production.slapd.ldif repo/production.slapd.ldif > 
/tmp/diff.ldif
ldapmodify [...] -f /tmp/diff.ldif
slapcat -n0 -l /server/production.slapd.ldif

These both end up with the same state, and it's the same number of 
commands! You can checkout and revert to the latest head/trunk/etc. or any 
arbitrary rev with either config format. Monitoring in-core vs. on-disk 
vs. expected-in-production committed config is possible in both cases and 
actually easier/more comprehensive with cn=config. If "magical config 
overlord" is a cron job then "automatically be corrected" happens with 
both of these workflows. How are your hands tied in this case?

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Paul B. Henson]

> From: Michael Ströder
> Sent: Saturday, February 01, 2014 2:45 AM
> 
> As Howard confirmed on this mailing list static configuration will still
be
> available in OpenLDAP 2.5.x.

Really? I didn't see that; my last understanding was that it was deprecated
in 2.4 and was going to be removed in 2.5. Sweet, that means I can push off
dealing with the conversion for much longer :).

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Paul B. Henson]

> From: Quanah Gibson-Mount
> Sent: Friday, January 31, 2014 6:03 PM
>
> Our servers do a nightly backup of cn=config via slapcat -n 0, and those
> are kept for a month.  Since this is for clients, there's no revision
> control involved, but it would be trivial for someone to check in the
> resulting LDIF file into their favorite RCS system.

Hmm, so the revision control system would transition from being the
authoritative source of what the configuration is (ie, in our current
system, if somehow the running configuration deviated from the version in
revision control, it would automatically be corrected back) to simply
becoming a record of whatever changes happen to have been made on the
running configuration?

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Meike Stone]

2014-02-03 Pieter Baele :
> It's a sadly a bit true.
>
> I like OpenLDAP a lot but if you don't need the *fastest* LDAP server,
> something as OpenDJ from Forgerock
> is a lot easier to configure.
>

I tried to use aliases (as defined in rfc 4512/2.6) with OpenDJ, but
it is not implemented.
So if anyone like to switch, you should take care. I can confirm, that
the configuration seems at first a little easier with OpenDJ and ACLs
working well, but thats not the only thing to make a choice ;-)

Kindly regards

Meike

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Pieter Baele]

It's a sadly a bit true.

I like OpenLDAP a lot but if you don't need the *fastest* LDAP server,
something as OpenDJ from Forgerock
is a lot easier to configure.

But is a problem with LDAP in general. If you only use it for
authentication/authorization,
it's complex to get everything 100% right. (on the other side, it's very
flexible.)
That's the reason why Red Hat created it's FreeIPA product, isn't it (and a
lot of sysadmins create users using configuration management tools)
Some other (big) companies only have central SSH hosts and from those hosts
use root.

AD is an exception with LDAP complexity well hidden away. But if you see
the results  there is a lot to say about the directory designs I have
seen ;-)



On Thu, Jan 30, 2014 at 5:07 PM, Gavin Henry  wrote:

>
> http://searchdatacenter.techtarget.com/feature/IT-pros-suffer-OpenLDAP-configuration-headaches
>
> Any one been in touch with them?
>
> --
> Kind Regards,
>
> Gavin Henry.
> Managing Director.
>
> T +44 (0) 1224 279484
> M +44 (0) 7930 323266
> F +44 (0) 1224 824887
> E ghe...@suretec.co.uk
>
> Open Source. Open Solutions(tm).
>
> http://www.suretecsystems.com/
>
> Suretec Systems is a limited company registered in Scotland. Registered
> number: SC258005. Registered office: 24 Cormack Park, Rothienorman,
> Inverurie,
> Aberdeenshire, AB51 8GL.
>
> Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html
>
> Do you know we have our own VoIP provider called SureVoIP? See
> http://www.surevoip.co.uk
>
> OpenPGP (GPG/PGP) Public Key: 0x8CFBA8E6 - Import from hkp://
> subkeys.pgp.net
> or http://www.suretecgroup.com/0x8CFBA8E6.gpg
>
>

Antw: RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Ulrich Windl]

>>> "Paul B. Henson"  schrieb am 01.02.2014 um 02:20 in 
>>> Nachricht
<070e01cf1eeb$ded56ab0$9c804010$@acm.org>:
>>  From: Quanah Gibson-Mount
>> Sent: Thursday, January 30, 2014 1:09 PM
>>
>> Having used both methods for years, I disagree.  It is a learning curve to
>> understand the cn=config backend, but once you do, it is far superior to
>> the old flat file, and to me, much easier to use.
> 
> My main issue with the cn=config method is how to integrate it into our
> revision control and approval system.

Why not check-in the config directory? It shouldn't change that often.
You could check in the "slapcat" also, but ordering of entries may be somewhat, 
well, chaotic.
Personally I wrote a program that postprocesses the slapcat LDIF output to 
write the entries in a structured directory (similar to slapd.d) while avoiding 
line breaks in the LDIF. I wonder whether it would make sense to sort the 
attribute namess of an entry (I already have one file per entry)...

> 
> Currently, with the flat file, the authoritative configuration is stored in
> a revision control system. When there are any changes to be made, they are
> made in a development branch, tested, then reviewed and approved to be
> merged into the production branch, at which point they are pushed out to the
> system. I'm not really sure how to do that with the dynamic cn=config
> method.

Well maybe you'd need another tool, like LDIF-diff-to-ldapmodify ;-)


> 
> For example, currently our revision control system could tell us exactly
> what configuration was in place seven weeks ago. How would you do that with
> cn=config? I suppose you could have a change log document in revision
> control, but unlike the actual configuration file in revision control,
> there's no way to say whether or not the changes made dynamically via
> cn=config are exactly matched to the changelog. Unless perhaps the ldif
> executing the change is maintained in revision control?

I'm experimenting with importing LDAP database backups into Git with structured 
LDIFs as described above. Anybody else?

Regards,
Ulrich

Antw: Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Ulrich Windl]

>>> Michael Ströder schrieb am 31.01.2014 um 16:24 in
Nachricht <52ebc029.9000...@stroeder.com>:
> Turbo Fredriksson wrote:
>> On Jan 31, 2014, at 3:06 PM, Michael Ströder wrote:
>> 
>>> Yeah, if she manages to setup AD the next thing is to teach her how to fix

> or
>>> work around replication problems.
>> 
>> Not the point. The argument was that OpenLDAP "is difficult to install and
>> setup". NOT administrate!
> 
> Nonsense! There is no difference between installation and administration. 
> It's
> a major fault to artificially distinguish that!

I disagree: Once the infrastructure is set up, the basic directory structure
is set up, and the clients are configured, it's much easier to
add/remove/modify entries than to do the initial setup.

> 
>> And my opinion (and many, many others!) have been that it is. And that 
> there's
>> something huge lacking in the OpenLDAP documentation. But every time this
is
>> brought up, all the maintainers get very hostile.
>> 
>> I started '99/2k with OpenLDAP, and I had huge problems understanding and
>> reading the documentation at the time. Most regarding the whole concept of

> LDAP.
> 
> I've started with OpenLDAP 1.0 in 1998 (well actually I've started with 
> Umich
> 3.3. just before). But it's unfair to argue with docs from that time. Many
> things improved since then.
> 
> And yes, I'm still reading OpenLDAP docs. Especially when designing ACLs.
> Fine-grained ACLs are hard in every software component.

Personally I could not decide whether the implementation is ease of use or
ease of implementation.

> 
> Anyone not able to read man pages and admin guides should not touch server
> configurations at all.

Just as anyone not able to write man pages should not write software.

> 
> No wonder that so many systems are hacked when so-called "IT pros" (web
> enthusiasts etc.) set up systems without learning about what they are
doing.
> 
>> Luckily, I've adapted (through years of testing) to this, so now it's 
> reasonably
>> easy. But when installing the new auth VM a few weeks ago, I had forgot
that
>> there's a problem with OpenSSL/GnuTLS (the interaction between them) so I
>> couldn't get SSL/TLS work. It took hours of googling the very weird and
>> non-discriptive errors to figure out the problem. And that of course struck
a
>> memory cord on how to solve it...
> 
> In this particular case your problems arised from deficiencies of the
GnuTLS
> code layer. Simply don't use GnuTLS or try to improve this code part.
> 
> Ciao, Michael.

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Michael Ströder]

Paul B. Henson wrote:
>> From: Quanah Gibson-Mount
>> Sent: Thursday, January 30, 2014 1:09 PM
>>
>> Having used both methods for years, I disagree.  It is a learning curve to
>> understand the cn=config backend, but once you do, it is far superior to
>> the old flat file, and to me, much easier to use.
> 
> My main issue with the cn=config method is how to integrate it into our
> revision control and approval system.
> 
> Currently, with the flat file, the authoritative configuration is stored in
> a revision control system. When there are any changes to be made, they are
> made in a development branch, tested, then reviewed and approved to be
> merged into the production branch, at which point they are pushed out to the
> system. I'm not really sure how to do that with the dynamic cn=config
> method.
> 
> For example, currently our revision control system could tell us exactly
> what configuration was in place seven weeks ago. How would you do that with
> cn=config? I suppose you could have a change log document in revision
> control, but unlike the actual configuration file in revision control,
> there's no way to say whether or not the changes made dynamically via
> cn=config are exactly matched to the changelog. Unless perhaps the ldif
> executing the change is maintained in revision control?

I'm also working with a configuration pulled from revision control system and
pushed to the systems with automated orchestration system.

As Howard confirmed on this mailing list static configuration will still be
available in OpenLDAP 2.5.x.

Ciao, Michael.




smime.p7s
Description: S/MIME Cryptographic Signature

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Christian Kratzer]

Hi,

On Fri, 31 Jan 2014, Paul B. Henson wrote:


From: Quanah Gibson-Mount
Sent: Thursday, January 30, 2014 1:09 PM

Having used both methods for years, I disagree.  It is a learning curve to
understand the cn=config backend, but once you do, it is far superior to
the old flat file, and to me, much easier to use.


My main issue with the cn=config method is how to integrate it into our
revision control and approval system.


all of the below:

- apply the changes using ldif files and put those changes into your approval 
system

- run nightly slapcat of cn=config an archive those

- put an ldif auditlog on cn=config and user personal users only to modify 
cn=config so you have a clean audit trail.

- ...


Currently, with the flat file, the authoritative configuration is stored in
a revision control system. When there are any changes to be made, they are
made in a development branch, tested, then reviewed and approved to be
merged into the production branch, at which point they are pushed out to the
system. I'm not really sure how to do that with the dynamic cn=config
method.

For example, currently our revision control system could tell us exactly
what configuration was in place seven weeks ago. How would you do that with
cn=config? I suppose you could have a change log document in revision
control, but unlike the actual configuration file in revision control,
there's no way to say whether or not the changes made dynamically via
cn=config are exactly matched to the changelog. Unless perhaps the ldif
executing the change is maintained in revision control?



I fail to see any issues in the above  ...


Greetings
Christian

--
Christian Kratzer  CK Software GmbH
Email:   c...@cksoft.de  Wildberger Weg 24/2
Phone:   +49 7032 893 997 - 0  D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9  HRB 245288, Amtsgericht Stuttgart
Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Quanah Gibson-Mount]

--On Friday, January 31, 2014 5:20 PM -0800 "Paul B. Henson" 
 wrote:



For example, currently our revision control system could tell us exactly
what configuration was in place seven weeks ago. How would you do that
with cn=config? I suppose you could have a change log document in revision
control, but unlike the actual configuration file in revision control,
there's no way to say whether or not the changes made dynamically via
cn=config are exactly matched to the changelog. Unless perhaps the ldif
executing the change is maintained in revision control?


Our servers do a nightly backup of cn=config via slapcat -n 0, and those 
are kept for a month.  Since this is for clients, there's no revision 
control involved, but it would be trivial for someone to check in the 
resulting LDIF file into their favorite RCS system.


--Quanah



--

Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Paul B. Henson]

> Regardless of what you may think about the tone of postings on this list
> (which is ludicrous to begin with since emails by their nature are horrible at
> conveying tone or emotion), actual subject matter experts monitor this list
> and make sure that correct answers get posted and that BS is censured. That
> is the purpose of this forum.
> 
> If you want to be coddled, feel free to look elsewhere. If you want real
> answers, this is the place.

Just to drop an alternative viewpoint into this frenzy of openldap bashing ;), 
we've been using openldap for well over a decade and been extremely happy with 
it. There've been a few bugs along the way, nothing is perfect, but overall 
it's been extremely reliable. Obviously the documentation isn't exactly bedtime 
story reading, but I've always found the admin guide and the man pages clear 
and accurate, and any time I've needed clarification or assistance I've always 
found helpful replies on this list.

So, thanks much to all of the openldap developers and experts who have provided 
an enterprise quality software package and support forum at no cost for us to 
use.

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Paul B. Henson]

> From: Quanah Gibson-Mount
> Sent: Thursday, January 30, 2014 1:09 PM
>
> Having used both methods for years, I disagree.  It is a learning curve to
> understand the cn=config backend, but once you do, it is far superior to
> the old flat file, and to me, much easier to use.

My main issue with the cn=config method is how to integrate it into our
revision control and approval system.

Currently, with the flat file, the authoritative configuration is stored in
a revision control system. When there are any changes to be made, they are
made in a development branch, tested, then reviewed and approved to be
merged into the production branch, at which point they are pushed out to the
system. I'm not really sure how to do that with the dynamic cn=config
method.

For example, currently our revision control system could tell us exactly
what configuration was in place seven weeks ago. How would you do that with
cn=config? I suppose you could have a change log document in revision
control, but unlike the actual configuration file in revision control,
there's no way to say whether or not the changes made dynamically via
cn=config are exactly matched to the changelog. Unless perhaps the ldif
executing the change is maintained in revision control?

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Quanah Gibson-Mount]

--On Friday, January 31, 2014 12:24 PM +0100 Wiebe Cazemier 
 wrote:



I agree that this list is the place to be for real help. However, I did
post that question here, to no avail. Eventually, I posted my own answer.


Hi Wiebe,

Not an excuse, but I did see that your unanswered question was posted on 
December 24th.  In much of the world, most people are offline and not 
reading email during that time.  I for example was on vacation during that 
time, otherwise I would have pointed you at olcSecurity.


--Quanah



--

Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Howard Chu]

Turbo Fredriksson wrote:

And my opinion (and many, many others!) have been that it is. And that there's
something huge lacking in the OpenLDAP documentation. But every time this is
brought up, all the maintainers get very hostile.


Let me be clear about this - there is nothing hostile in this message:

The Project is run by volunteers. If you want something to improve, then 
contribute your time to making it happen. There is no chain of command where 
any person gives orders and someone else carries them out. Areas get worked on 
when interested people step up and work on them. The areas of code that I've 
worked on were the areas that interested me personally. Areas that don't 
interest me get ignored. (Some things, like asserts and other annoying 
crashes, may get my attention even though the code doesn't interest me, but 
these are somewhat rare.)


The topic of documentation does raise some ire these days, particularly 
because we see companies like Zytrax slurping up our Admin Guide and 
regurgitating it with a large dose of their own misunderstanding and 
misinformation. If you actually want to help make things better for the 
Project and the community, then do so - submit documentation patches back to 
us. Don't splinter off and write your own fantasy novel of how you think 
things work. Write patches to the Guide to expand on the areas you think need 
to be explained better. Fragmenting the knowledge base only increases 
confusion, it doesn't make things better.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Michael Ströder]

Turbo Fredriksson wrote:
> On Jan 31, 2014, at 3:06 PM, Michael Ströder wrote:
> 
>> Yeah, if she manages to setup AD the next thing is to teach her how to fix or
>> work around replication problems.
> 
> Not the point. The argument was that OpenLDAP "is difficult to install and
> setup". NOT administrate!

Nonsense! There is no difference between installation and administration. It's
a major fault to artificially distinguish that!

> And my opinion (and many, many others!) have been that it is. And that there's
> something huge lacking in the OpenLDAP documentation. But every time this is
> brought up, all the maintainers get very hostile.
> 
> I started '99/2k with OpenLDAP, and I had huge problems understanding and
> reading the documentation at the time. Most regarding the whole concept of 
> LDAP.

I've started with OpenLDAP 1.0 in 1998 (well actually I've started with Umich
3.3. just before). But it's unfair to argue with docs from that time. Many
things improved since then.

And yes, I'm still reading OpenLDAP docs. Especially when designing ACLs.
Fine-grained ACLs are hard in every software component.

Anyone not able to read man pages and admin guides should not touch server
configurations at all.

No wonder that so many systems are hacked when so-called "IT pros" (web
enthusiasts etc.) set up systems without learning about what they are doing.

> Luckily, I've adapted (through years of testing) to this, so now it's 
> reasonably
> easy. But when installing the new auth VM a few weeks ago, I had forgot that
> there's a problem with OpenSSL/GnuTLS (the interaction between them) so I
> couldn't get SSL/TLS work. It took hours of googling the very weird and
> non-discriptive errors to figure out the problem. And that of course struck a
> memory cord on how to solve it...

In this particular case your problems arised from deficiencies of the GnuTLS
code layer. Simply don't use GnuTLS or try to improve this code part.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Turbo Fredriksson]

On Jan 31, 2014, at 3:06 PM, Michael Ströder wrote:

> Yeah, if she manages to setup AD the next thing is to teach her how to fix or
> work around replication problems.

Not the point. The argument was that OpenLDAP "is difficult to install and
setup". NOT administrate!

And my opinion (and many, many others!) have been that it is. And that there's
something huge lacking in the OpenLDAP documentation. But every time this is
brought up, all the maintainers get very hostile.

I started '99/2k with OpenLDAP, and I had huge problems understanding and
reading the documentation at the time. Most regarding the whole concept of LDAP.

Luckily, I've adapted (through years of testing) to this, so now it's reasonably
easy. But when installing the new auth VM a few weeks ago, I had forgot that
there's a problem with OpenSSL/GnuTLS (the interaction between them) so I
couldn't get SSL/TLS work. It took hours of googling the very weird and
non-discriptive errors to figure out the problem. And that of course struck a
memory cord on how to solve it...
--
You know, boys, a nuclear reactor is a lot like a woman.
You just have to read the manual and press the right buttons
- Homer Simpson

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Michael Ströder]

Turbo Fredriksson wrote:
> But setting up something like Active Directory is something my aunt can/could
> do.

Yeah, if she manages to setup AD the next thing is to teach her how to fix or
work around replication problems.
(Note: It's nearly impossible to repair a broken AD domain without migrating
it and/or re-joining all systems.)

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Wiebe Cazemier]

- Original Message -
> From: "Howard Chu" 
> To: "Wiebe Cazemier" , "Brent Bice" 
> Cc: openldap-technical@openldap.org
> Sent: Friday, 31 January, 2014 11:43:53 AM
> Subject: Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration 
> headaches ?
> 
> actual subject matter experts monitor this list
> and make sure that correct answers get posted and that BS is censured. That
> is
> the purpose of this forum.
> 
> If you want to be coddled, feel free to look elsewhere. If you want real
> answers, this is the place.

I agree that this list is the place to be for real help. However, I did post 
that question here, to no avail. Eventually, I posted my own answer.

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Howard Chu]

Wiebe Cazemier wrote:

- Original Message -

(snip)
(long)
(snip)


I am by no means an LDAP expert, but as an experienced Linux sysadmin I do

have to say that I have had some very tricky issues with OpenLDAP.


One of them involved fiddling for days with difficulty changing the root

password, after finally finding out that the Ubuntu docs were wrong [1]; they
had cause me to create two admin users, with the passwords in plain text no 
less.


The other involved getting 'TLS required' on the TCP connection, which
seems

to be undocumented.

Nonsense. The security directive is documented in slapd.conf(5) and 
slapd-config(5) manpages.



My question on Serverfault about it [2] is getting to be

quite popular. Forcing encryption would have been a lot easier if a different
port for SSL wasn't deprecated.

As usual when you go to unofficial support channels, all you get is garbage 
from unqualified self-proclaimed experts. The highest ranked answer on your 
question is flat wrong, and refers to Zytrax documentation, which is poorly 
plagiarized from outdated copies of the OpenLDAP Admin Guide and mixed with a 
generous helping of misinformation from their own addled brains.



[1] https://bugs.launchpad.net/serverguide/+bug/1094842
[2] 
https://serverfault.com/questions/459718/configure-openldap-with-tls-required


Regardless of what you may think about the tone of postings on this list 
(which is ludicrous to begin with since emails by their nature are horrible at 
conveying tone or emotion), actual subject matter experts monitor this list 
and make sure that correct answers get posted and that BS is censured. That is 
the purpose of this forum.


If you want to be coddled, feel free to look elsewhere. If you want real 
answers, this is the place.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Antw: Re: FW: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Ulrich Windl]

>>> "A. P. Garcia"  schrieb am 30.01.2014 um 23:36 
>>> in
Nachricht
:

Windows: Brains not needed.

> OpenLDAP: "Brains not included."
> On Jan 30, 2014 3:45 PM, "Borresen, John - 0442 - MITLL" <
> john.borre...@ll.mit.edu> wrote:
> 
>> Sorry, I didn't read the original mailing list...I too wanted to send to
>> the board and not you individually.  My apologies.
>>
>> -Original Message-
>> From: Borresen, John - 0442 - MITLL
>> Sent: Thursday, January 30, 2014 1:16 PM
>> To: 'Turbo Fredriksson'; Howard Chu
>> Subject: RE: Have you seen this FUD - IT pros suffer OpenLDAP
>> configuration headaches ?
>>
>> I have experience with OpenLDAP, 389-Directory-Server, OpenDJ, OpenDS,
>> RedHat's Directory Studio.  I am not an LDAP expert by any means (as can be
>> seen by my help posts -- that was supposed to be funny).  While I get
>> aggravated by the difficulty in installing OpenLDAP, the miniscule
>> documentation, and the differing, and often conflicting, documents found
>> via a google search I always recommend OpenLDAP over the other products.
>>  The OpenLDAP Admin Guide, for a product that has been out for a very long
>> time, as far as a how-to-guide, is lacking a lot and seems incomplete --
>> many areas are simply blank.  The bouncing back and forth between the
>> slapd.conf (old) and the slapd.d (new) methodologies is very aggravating
>> and not helpful (to me).
>>
>> I understand that there is not just one way to install OpenLDAP...the
>> options are pretty mind-boggling -- and can't all be put in an Admin Guide,
>> the manual as more than a dictionary could be so much more.  With this test
>> environment I've been building over that 2 or 3 months, it's been broken
>> down and restarted, from scratch, at least once a month.  The original
>> environment (the current production) took me about a year to get up and
>> running.
>>
>> We use the Apache Directory Studio as a front-end GUI to view the dbase,
>> mostly.  Most modifications are via the CLI tools.
>>
>> Don't get me wrong, even for my "bashing" of OpenLDAP above, it is the
>> first one that I would recommend.  I look at the bright side...each time
>> the slate has to be cleaned and restarted the more I learn.
>>
>> Dave Borresen
>>
>>
>> -Original Message-
>> From: openldap-technical-boun...@openldap.org [mailto:
>> openldap-technical-boun...@openldap.org] On Behalf Of Turbo Fredriksson
>> Sent: Thursday, January 30, 2014 11:53 AM
>> To: Howard Chu
>> Subject: Re: Have you seen this FUD - IT pros suffer OpenLDAP
>> configuration headaches ?
>>
>> On Jan 30, 2014, at 5:35 PM, Howard Chu wrote:
>>
>> > I saw some of this on twitter before, ignored it since none of the
>> parties involved have any clue what they're talking about.
>>
>>
>> Personally, I think it's spot on. It IS hard to configure an LDAP server,
>> and even harder to understand how it works (the object based part). Took me
>> three months first time, and I'm not an idiot.
>>
>> Even today, I need to consult either my own book or the howto (or
>> seriously skim through the man pages) to setup a new server.
>>
>> And even worse if when you want to optimize the backend... There's a lot
>> of magic there
>>
>> And with the new config backend!? I haven't even had the time or energy to
>> go that far yet!
>> --
>> I love deadlines. I love the whooshing noise they make as they go by.
>> - Douglas Adams
>>
>>
>>
>>

RE: FW: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Alex Samad - Yieldbroker]

Hi

Basically what Jon and Turbo and Dan have said.  I have been on and off  this 
mailing list for nearly 10 years and my first choice for ldap server has always 
been openldap, but to be honest gone are the days when I want to read code to 
find out what its doing. Take that to read the unit tests as well.

I have also found the list to be rather abrasive to people who's first job is 
not ldap who come here to ask questions.

Alex




From: openldap-technical-boun...@openldap.org 
[mailto:openldap-technical-boun...@openldap.org] On Behalf Of Dan Pritts
Sent: Friday, 31 January 2014 9:20 AM
To: Borresen, John - 0442 - MITLL
Cc: Howard Chu; openldap-technical@openldap.org
Subject: Re: FW: Have you seen this FUD - IT pros suffer OpenLDAP configuration 
headaches ?

I'm with John & Turbo, and I guess with the article author.  Openldap is hard 
to configure.  It is also, in my limited experience, pretty solid, once you get 
it working the way you want.

Part of the problem is definitely just groking LDAP itself.   And I haven't 
ever tried to configure any of the competition, except I guess AD, so I can't 
compare to the others directly.

I have so far always been able to bend openldap to my will, usually with help 
from the people on this mailing list.  But I've been at this *nix stuff for 
more than 20 years, and it has never been easy.

Someone compared configuring openldap to configuring apache.  Apache is hardly 
the model of easy-to-configure software.  However, the documentation is much 
better and the examples are much, much more usable.

The openldap Administrator's guide and man pages are incomplete and 
occasionally incorrect/outdated.  For example, yesterday I found bad syntax in 
the "map" examples at the bottom of the slapo-rwm man page (i do intend to 
report a bug on that one).

Error messages are pretty bad.  For example, an unreadable private key file 
causes this error in the syslog:  "main: TLS init def ctx failed: -1".   Of 
course, this and the associated startup failure is a big improvement, version 
2.4.23 failed the initialization silently, and just logged "TLS Negotiation 
failed" when you tried to connect.

Another example - slaptest gives the following when I test a config file that 
has the old, bad rwm syntax:

[root@cnsutil0 openldap]# ../../sbin/slaptest -f test
slaptest: config.c:198: config_check_vals: Assertion `c->argc == 2' failed.
Aborted

The administrator's guide talks about stacking overlays, but doesn't mention 
that gee, sometimes that doesn't work real well (ITS 5941, rwm + translucent = 
crash).   That issue is from 2010, with no apparent solution.


Just so we are clear --- I would not have posted these complaints (at least, 
not without solutions) if it weren't for this thread.  My intent is not to 
bitch about the quality of the software or the documentation.  I am getting 
much more than I am paying for, and I notably have not raised my hand to 
rewrite the documentation or fix any bugs in the code.  However, to deny these 
things is to put one's head in the sand.

regards
danno

Borresen, John - 0442 - MITLL wrote:

Sorry, I didn't read the original mailing list...I too wanted to send to the 
board and not you individually.  My apologies.



-Original Message-

From: Borresen, John - 0442 - MITLL

Sent: Thursday, January 30, 2014 1:16 PM

To: 'Turbo Fredriksson'; Howard Chu

Subject: RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration 
headaches ?



I have experience with OpenLDAP, 389-Directory-Server, OpenDJ, OpenDS, RedHat's 
Directory Studio.  I am not an LDAP expert by any means (as can be seen by my 
help posts -- that was supposed to be funny).  While I get aggravated by the 
difficulty in installing OpenLDAP, the miniscule documentation, and the 
differing, and often conflicting, documents found via a google search I always 
recommend OpenLDAP over the other products.  The OpenLDAP Admin Guide, for a 
product that has been out for a very long time, as far as a how-to-guide, is 
lacking a lot and seems incomplete -- many areas are simply blank.  The 
bouncing back and forth between the slapd.conf (old) and the slapd.d (new) 
methodologies is very aggravating and not helpful (to me).



I understand that there is not just one way to install OpenLDAP...the options 
are pretty mind-boggling -- and can't all be put in an Admin Guide, the manual 
as more than a dictionary could be so much more.  With this test environment 
I've been building over that 2 or 3 months, it's been broken down and 
restarted, from scratch, at least once a month.  The original environment (the 
current production) took me about a year to get up and running.



We use the Apache Directory Studio as a front-end GUI to view the dbase, 
mostly.  Most modifications are via the CLI tools.



Don't get me wrong, even for my &quo

Re: FW: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[A. P. Garcia]

OpenLDAP: "Brains not included."
On Jan 30, 2014 3:45 PM, "Borresen, John - 0442 - MITLL" <
john.borre...@ll.mit.edu> wrote:

> Sorry, I didn't read the original mailing list...I too wanted to send to
> the board and not you individually.  My apologies.
>
> -Original Message-
> From: Borresen, John - 0442 - MITLL
> Sent: Thursday, January 30, 2014 1:16 PM
> To: 'Turbo Fredriksson'; Howard Chu
> Subject: RE: Have you seen this FUD - IT pros suffer OpenLDAP
> configuration headaches ?
>
> I have experience with OpenLDAP, 389-Directory-Server, OpenDJ, OpenDS,
> RedHat's Directory Studio.  I am not an LDAP expert by any means (as can be
> seen by my help posts -- that was supposed to be funny).  While I get
> aggravated by the difficulty in installing OpenLDAP, the miniscule
> documentation, and the differing, and often conflicting, documents found
> via a google search I always recommend OpenLDAP over the other products.
>  The OpenLDAP Admin Guide, for a product that has been out for a very long
> time, as far as a how-to-guide, is lacking a lot and seems incomplete --
> many areas are simply blank.  The bouncing back and forth between the
> slapd.conf (old) and the slapd.d (new) methodologies is very aggravating
> and not helpful (to me).
>
> I understand that there is not just one way to install OpenLDAP...the
> options are pretty mind-boggling -- and can't all be put in an Admin Guide,
> the manual as more than a dictionary could be so much more.  With this test
> environment I've been building over that 2 or 3 months, it's been broken
> down and restarted, from scratch, at least once a month.  The original
> environment (the current production) took me about a year to get up and
> running.
>
> We use the Apache Directory Studio as a front-end GUI to view the dbase,
> mostly.  Most modifications are via the CLI tools.
>
> Don't get me wrong, even for my "bashing" of OpenLDAP above, it is the
> first one that I would recommend.  I look at the bright side...each time
> the slate has to be cleaned and restarted the more I learn.
>
> Dave Borresen
>
>
> -Original Message-
> From: openldap-technical-boun...@openldap.org [mailto:
> openldap-technical-boun...@openldap.org] On Behalf Of Turbo Fredriksson
> Sent: Thursday, January 30, 2014 11:53 AM
> To: Howard Chu
> Subject: Re: Have you seen this FUD - IT pros suffer OpenLDAP
> configuration headaches ?
>
> On Jan 30, 2014, at 5:35 PM, Howard Chu wrote:
>
> > I saw some of this on twitter before, ignored it since none of the
> parties involved have any clue what they're talking about.
>
>
> Personally, I think it's spot on. It IS hard to configure an LDAP server,
> and even harder to understand how it works (the object based part). Took me
> three months first time, and I'm not an idiot.
>
> Even today, I need to consult either my own book or the howto (or
> seriously skim through the man pages) to setup a new server.
>
> And even worse if when you want to optimize the backend... There's a lot
> of magic there
>
> And with the new config backend!? I haven't even had the time or energy to
> go that far yet!
> --
> I love deadlines. I love the whooshing noise they make as they go by.
> - Douglas Adams
>
>
>
>

Re: FW: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Dan Pritts]

I'm with John & Turbo, and I guess with the article author.  Openldap is 
hard to configure.  It is also, in my limited experience, pretty solid, 
once you get it working the way you want.


Part of the problem is definitely just groking LDAP itself.   And I 
haven't ever tried to configure any of the competition, except I guess 
AD, so I can't compare to the others directly.


I have so far always been able to bend openldap to my will, usually with 
help from the people on this mailing list.  But I've been at this *nix 
stuff for more than 20 years, and it has never been easy.


Someone compared configuring openldap to configuring apache.  Apache is 
hardly the model of easy-to-configure software.  However, the 
documentation is much better and the examples are much, much more usable.


The openldap Administrator's guide and man pages are incomplete and 
occasionally incorrect/outdated.  For example, yesterday I found bad 
syntax in the "map" examples at the bottom of the slapo-rwm man page (i 
do intend to report a bug on that one).


Error messages are pretty bad.  For example, an unreadable private key 
file causes this error in the syslog:  "main: TLS init def ctx failed: 
-1".   Of course, this and the associated startup failure is a big 
improvement, version 2.4.23 failed the initialization silently, and just 
logged "TLS Negotiation failed" when you tried to connect.


Another example - slaptest gives the following when I test a config file 
that has the old, bad rwm syntax:


[root@cnsutil0 openldap]# ../../sbin/slaptest -f test
slaptest: config.c:198: config_check_vals: Assertion `c->argc == 2' failed.
Aborted

The administrator's guide talks about stacking overlays, but doesn't 
mention that gee, sometimes that doesn't work real well (ITS 5941, rwm + 
translucent = crash).   That issue is from 2010, with no apparent solution.



Just so we are clear --- I would not have posted these complaints (at 
least, not without solutions) if it weren't for this thread.  My intent 
is not to bitch about the quality of the software or the documentation.  
I am getting much more than I am paying for, and I notably have not 
raised my hand to rewrite the documentation or fix any bugs in the 
code.  However, to deny these things is to put one's head in the sand.


regards
danno

Borresen, John - 0442 - MITLL wrote:

Sorry, I didn't read the original mailing list...I too wanted to send to the 
board and not you individually.  My apologies.

-Original Message-
From: Borresen, John - 0442 - MITLL
Sent: Thursday, January 30, 2014 1:16 PM
To: 'Turbo Fredriksson'; Howard Chu
Subject: RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration 
headaches ?

I have experience with OpenLDAP, 389-Directory-Server, OpenDJ, OpenDS, RedHat's 
Directory Studio.  I am not an LDAP expert by any means (as can be seen by my 
help posts -- that was supposed to be funny).  While I get aggravated by the 
difficulty in installing OpenLDAP, the miniscule documentation, and the 
differing, and often conflicting, documents found via a google search I always 
recommend OpenLDAP over the other products.  The OpenLDAP Admin Guide, for a 
product that has been out for a very long time, as far as a how-to-guide, is 
lacking a lot and seems incomplete -- many areas are simply blank.  The 
bouncing back and forth between the slapd.conf (old) and the slapd.d (new) 
methodologies is very aggravating and not helpful (to me).

I understand that there is not just one way to install OpenLDAP...the options 
are pretty mind-boggling -- and can't all be put in an Admin Guide, the manual 
as more than a dictionary could be so much more.  With this test environment 
I've been building over that 2 or 3 months, it's been broken down and 
restarted, from scratch, at least once a month.  The original environment (the 
current production) took me about a year to get up and running.

We use the Apache Directory Studio as a front-end GUI to view the dbase, 
mostly.  Most modifications are via the CLI tools.

Don't get me wrong, even for my "bashing" of OpenLDAP above, it is the first 
one that I would recommend.  I look at the bright side...each time the slate has to be 
cleaned and restarted the more I learn.

Dave Borresen


-Original Message-
From: openldap-technical-boun...@openldap.org 
[mailto:openldap-technical-boun...@openldap.org] On Behalf Of Turbo Fredriksson
Sent: Thursday, January 30, 2014 11:53 AM
To: Howard Chu
Subject: Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration 
headaches ?

On Jan 30, 2014, at 5:35 PM, Howard Chu wrote:


I saw some of this on twitter before, ignored it since none of the parties 
involved have any clue what they're talking about.



Personally, I think it's spot on. It IS hard to configure an LDAP server, and 
even harder to under

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

[Quanah Gibson-Mount]

--On Thursday, January 30, 2014 8:02 PM +0100 Turbo Fredriksson 
 wrote:





I'm all for removing the flat config file, I also think that the new way
is better. But it IS more complicated, no matter how you see it. TO
complicated, no, but still MORE complicated...


Having used both methods for years, I disagree.  It is a learning curve to 
understand the cn=config backend, but once you do, it is far superior to 
the old flat file, and to me, much easier to use.  The main thing at this 
point that is lacking is getting the admin and quick start guides updated 
to reference cn=config instead of slapd.conf.  I've gotten some progress on 
that going in the OpenLDAP 2.5 code branch. It is my goal to have both 
pieces fully "cn=config"'d for 2.5.   Also being able to make modifications 
on the fly to my configuration is a major plus.  It has allowed me to 
script pretty much everything our clients need to do on the ldap side of 
things.


You may want to read over the various bits I've written for Zimbra.

Our cn=config defaults: 



Script to configure MMR:


Script to initialize our ldap server:


MDB monitoring script:


Script to promote a replica to a MMR member:


etc

--Quanah

--Quanah

--

Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration