Re: Is existing documentation kind of vague?

MJ J wrote: Certainly, I will make a better list tomorrow or so and send them to you. Generally, it relates to the areas of cn=config which are not runtime configurable and the lack of inline ACLs being first-class citizens. Basically, I feel that anything which is exposed via cn=config should

Re: Is existing documentation kind of vague?

Certainly, I will make a better list tomorrow or so and send them to you. Generally, it relates to the areas of cn=config which are not runtime configurable and the lack of inline ACLs being first-class citizens. Basically, I feel that anything which is exposed via cn=config should not require an

Re: Is existing documentation kind of vague?

MJ J wrote: I actually like 389 a lot and I have used Netscape DS extensively in managing international telecom networks about 15 years ago. There are quite many management features that are superior to OpenLDAP still to this day, but I simply cannot use it anymore because of the lack of

Re: Is existing documentation kind of vague?

Thanks, Howard. Without a doubt, your opinion and comments matter greatly. We will be in touch. On Sun, Nov 19, 2017 at 8:22 PM, Howard Chu wrote: > MJ J wrote: >> >> I had a requirement to build a centrally managed SSO system that >> replicated subordinate subtrees (kerberos,

Re: Is existing documentation kind of vague?

There are no emotional reactions - there are simply statements that I won't be submitting to your condescending attitude. I have also been working in this same arena for 20 years and I have long ago found what is need to make large systems function. Perhaps if you would drop the zero-sum-game

Re: Is existing documentation kind of vague?

MJ J wrote: I had a requirement to build a centrally managed SSO system that replicated subordinate subtrees (kerberos, identities, roles, permissions, resources, dns, etc) to the respective sites and handle tens of thousands of concurrent requests per second. I determined that FreeIPA was

Re: Is existing documentation kind of vague?

I had a requirement to build a centrally managed SSO system that replicated subordinate subtrees (kerberos, identities, roles, permissions, resources, dns, etc) to the respective sites and handle tens of thousands of concurrent requests per second. I determined that FreeIPA was unable to perform

Re: Is existing documentation kind of vague?

I actually like 389 a lot and I have used Netscape DS extensively in managing international telecom networks about 15 years ago. There are quite many management features that are superior to OpenLDAP still to this day, but I simply cannot use it anymore because of the lack of scalability. I know

Re: Is existing documentation kind of vague?

> On Nov 17, 2017, at 12:34 AM, William Brown wrote: > > Whoa mate - I'm not here to claim that 389 is a better ldap server - we > just do some different things. We acknowledge our limitations and are > really working on them and paying down our tech debt. We want to remove

Re: Is existing documentation kind of vague?

MJ J wrote: > I know because I have built such a system (based on OpenLDAP) and > deployed it internationally. So what makes your system special, which goals does it reach and how? Ciao, Michael.

Re: Is existing documentation kind of vague?

MJ J wrote: > You're right, except for the fact that deploying 2 lines of new code > into production can still be a long process ;-) The phrase comes to > mind: If it ain't broken, don't fix it. You're free to decide to ignore good advice. But you have to accept that someone might point out

Re: Is existing documentation kind of vague?

On Fri, 2017-11-17 at 08:27 +0200, MJ J wrote: > No matter how you wrap poll() and select(), they will always be > poll() > and select() - you will always run loops around an ever increasing > stack of file descriptors while doing I/O. BDB is always going to > have > the same old problems...

Re: Is existing documentation kind of vague?

No matter how you wrap poll() and select(), they will always be poll() and select() - you will always run loops around an ever increasing stack of file descriptors while doing I/O. BDB is always going to have the same old problems... That's what I'm talking about - sacrificing performance for

Re: Is existing documentation kind of vague?

You're right, except for the fact that deploying 2 lines of new code into production can still be a long process ;-) The phrase comes to mind: If it ain't broken, don't fix it. Why is this mailing list constantly used as a vehicle for people pushing their own consulting services and products?

Re: Is existing documentation kind of vague?

On Thu, 2017-11-16 at 05:54 +0200, MJ J wrote: > Sure, it can be improved to become invulnerable to the academically > imaginative race conditions that are not going to happen in real > life. > That will go to the very bottom of my list of things to do now, > thanks. > > FreeIPA is a cool

Re: Is existing documentation kind of vague?

MJ J wrote: > Sure, it can be improved to become invulnerable to the academically > imaginative race conditions that are not going to happen in real life. > That will go to the very bottom of my list of things to do now, > thanks. Adding a couple of lines of Python code is such a low-hanging

Re: Is existing documentation kind of vague?

Sure, it can be improved to become invulnerable to the academically imaginative race conditions that are not going to happen in real life. That will go to the very bottom of my list of things to do now, thanks. FreeIPA is a cool concept, too bad it's not scalable or multi-tenant capable. On Wed,

Re: Is existing documentation kind of vague?

MJ J wrote: > TLDR; in a split-brain situation, you could run into trouble. But this > isn't the only place. Efffective systems monitoring is the key here. > > Long answer; > [..] > The solution I posted has been in production in a large, dynamic > company for several years and never encountered

Antw: Re: Is existing documentation kind of vague?

>> together that information. I have a good idea how to implement >> uidNumber, but I haven't seen it done and I can't do it CORRECT today >> because I would have to register for a Private Enterprise Number so I >> won't hijack an OID namespace and that would take up to 30 days and >> there is no documented contingency plan anywhere. >> >> We are all familiar with the the LDAP call out articles that come out >> every year. All of the articles seem to come from a place of >> frustration. To be fair I think call out articles are a trend with >> databases. >> >> Do you think existing documentation is kind of vague? >>

Re: Re: Is existing documentation kind of vague?

hat the specific object wouldn't be listed. >>> >>>> Under no circumstances should you hijack OID namespace! >>> - OpenLDAP Software 2.4 Administrator's Guide >>> >>> That is a lot of data from a lot of different websites to string >>> together that information. I have a good idea how to implement >>> uidNumber, but I haven't seen it done and I can't do it CORRECT today >>> because I would have to register for a Private Enterprise Number so I >>> won't hijack an OID namespace and that would take up to 30 days and >>> there is no documented contingency plan anywhere. >>> >>> We are all familiar with the the LDAP call out articles that come out >>> every year. All of the articles seem to come from a place of >>> frustration. To be fair I think call out articles are a trend with >>> databases. >>> >>> Do you think existing documentation is kind of vague? >>> > > >

Re: Is existing documentation kind of vague?

MJ J wrote: > Client apps are not scoped to do subtree searches from the root of the > directory where the autoincrement objects live, nor do the ACLs permit > it, but you knew that already. Good to hear it's alright in your deployment. But please add this extra note next time you give general

Re: Is existing documentation kind of vague?

John Lewis wrote: > I was trying to implement uidNumber Attribute Auto-Incrementing Method > and I read http://www.rexconsulting.net/ldap-protocol-uidNumber.html This is 3rd-party documentation. Just a blog article, but not bad. => Take it with a grain of salt. > what name the called the schema.

Re: Is existing documentation kind of vague?

Client apps are not scoped to do subtree searches from the root of the directory where the autoincrement objects live, nor do the ACLs permit it, but you knew that already. Duplicate a race condition using the above code and you shouldn't be using LDAP in the first place. On Tue, Nov 14, 2017

Re: Is existing documentation kind of vague?

MJ J wrote: > You don't need a special object class or schema, you can use this: > dn: cn=user,ou=increment,dc=foo,dc=bar > objectClass: top > objectClass: account > objectClass: posixAccount Ouch! Depending on the config of your LDAP server and client systems this is a visible user account with

Re: Is existing documentation kind of vague?

ncy plan anywhere. > > We are all familiar with the the LDAP call out articles that come out > every year. All of the articles seem to come from a place of > frustration. To be fair I think call out articles are a trend with > databases. > > Do you think existing documentation is kind of vague? >

Is existing documentation kind of vague?

nd with databases. Do you think existing documentation is kind of vague?