I meant to say the integration of components and subsystems and providing some automation is what is truly difficult.<div><br></div><div>Back then I was coming from Netware NDS, so I already got DNs and RDNs. For me the holy grail was sendmail + Cyrus IMAP + bind all serving from a deduped/normalized LDAP schema. I remember having to hack the sendmailMTA object class schema so it could overlay inetOrgPerson/posixAccount and host and domain definitions (localdomains and virtusertable stuff), or writing object creation templates in PHP LDAP admin, or trying to unify /etc into LDAP for openMosix clusters.</div>
<div><br></div><div>Ah, yes, I had repressed my memories of SASL and nscd! </div><div><br></div><div>So maybe FreeIPA has just a little bit more left to integrate, but it's light-years ahead of where we used to be. ;)</div>
<div><br></div><div>Thanks for the nostalgic read! :)<span></span><br><br>On Monday, November 18, 2013, Paul Robert Marino wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't really agree with you that it is all that difficult to get a real LDAPv3 server up and running. I've built quite a few of them over the years and what I mostly found was it was just poorly documented.<br>Although I will say putting it all into one uniform toolset is ambitious, its not the first time its been attempted SuSE had a similar project based on openldap Perl and Java before Novel bought and them and killed it which was very similar.<br>
<br>1) Kerberos V servers are the easiest thing in the world to setup as long as you aren't using LDAP as the backend database. I've done several presentations over the last 14 years where I was able to teach an entire room how to build and manage a Kerberos V infrastructure in 2 Hours or less. Furthermore you can even configure PAM To do Kerberos auth without a keytab file on the host as long as you except the fact that users will not be able to change their passwords on those hosts, which is fantastic for edge facing host such as web servers.<br>
<br>2) LDAP servers are not easy to understand at first but once you get use to the but once you create some LDIF templates its not too ad. There were always 3 difficult parts though two of which are made easier by 389 server but are hardly new, the first time I saw 389 Server I had a nasty flashback of supporting SCO servers running Netscape Directory Server syncing to NT4 domain controllers. The finally one which it works around via plugins is most applications despite saying they are LDAPv3 compatible are really doing LDAPv2 over TLS. Simply put instead of doing a bind to authenticate users like the RFC's specify they are searching for the password field in the users account and validating it themselves.<br>
<br>3) The biggest difficulties people always had were always in the SASL layer the Cyrus SASL project has almost no real practical documentation and many people in the early 2000's were writing documentation and presentations based on a site written by someone who claimed to be an LDAPv3 expert that appeared in the late 90s which was flat out wrong. To be honest the only good documentation on Cyrus SASL I've ever seen is on the Postfix site.<br>
<br>4) The other big difficulty was stabilizing of nscd. I can't tell you how many times I've seen people complain about it who never looked at tuning it. With its default setting its tuned for a desktop with local auth not a server using LDAP auth. Most of the problem with it centered around using the memory mapped file mode instead of the sockets connection mode, that with having too low a configured thread limit to really handle server activity was a recipe for disaster.<br>
<br>5) TLS can be easy if you are willing to pay for a 3rd party wildcard cert. Self signed certs have always been a bad idea and incompatible with LDAPv3. DogtagPKI does make it easier to create a more robust CA/PKI infrastructure but again its nothing new its just an updated version of Netscape's Certificate manager.<br>
<br>Now that said I'm glad to see RedHat bought all that great Netscape code and GPLed it because it was always good codebase which was neglected by SUN and AOL, and I think Red Hat and the free speech software community have been and will continue to be greater custodians of that codebase.<br>
<br>What most impresses me with FreeIPA is the fact that its pushed fixes into the MIT Kerberos V project for problems that have been know about for over a decade which in the past were declared as limitations rather than bugs by its original developers. While I still do firmly believe Heimdal Kerberos is a far superior Kerberos server for the first time ever I now consider MIT Kerberos V stable enough for mission critical environments which is a huge step forward.<br>
<span style="font-family:Prelude,Verdana,san-serif"><br><br></span><span><div style="font-family:arial,sans-serif;font-size:12px;color:#999999">-- Sent from my HP Pre3</div><br></span><span style="color:navy;font-family:Prelude,Verdana,san-serif"><hr align="left" style="width:75%">
On Nov 15, 2013 11:44, Derek Moore <<a href="javascript:_e({}, 'cvml', 'derek.p.moore@gmail.com');" target="_blank">derek.p.moore@gmail.com</a>> wrote: <br><br></span><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Practically though, I think an idempotent installer opens a lot of cans of worms. Do we limit some answers to their original? Take for instance the REALM. Can someone change it on-the-fly? It would have some deep repercussions. Similarly, changing the hostname. There are all kinds of corner cases.<br>
</blockquote><div><br></div><div>This is very true! Nothing is quite so complex as realm controllers for krb5+ldap+nss+sssd+bind+ca+blah+blim+blam!<br><br>You guys sure have your work cut out for you!<br><br>About the only other Red Hat projects I've seen that are nearly as complex as FreeIPA are oVirt & OpenShift (ok, maybe Cluster Suite, too), in terms of fully taking over the host being configured and the insane amount of inter-dependencies therein and the fragility of installers (installers from nightlies, alpha, or beta; I like to live on the bleeding edge).<br>
<br></div><div>In ~2002 I setup my own hand-rolled krb5+ldap+nss realm cluster for virtual domain web & email hosting, and I swear that took me weeks. It is a joy to have something like FreeIPA these days.<br><br></div>
<div>Once again I'll take the opportunity to pimp otopi, even if it may not be the right solution for you guys, they are trying to solve similar problems in a similarly complex environment:<br><br><a href="http://www.ovirt.org/Features/Otopi_Infra_Migration" target="_blank">http://www.ovirt.org/Features/Otopi_Infra_Migration</a><br>
<br><pre>otopi -- oVirt Task Oriented Pluggable Installer/Implementation
===============================================================
Standalone plugin based installation framework to be used to setup
system components. The plugin nature provides simplicity to
add new installation functionality without the complexity of the state
and transaction management.
At the core of the implementation there is environment dictionary and
a flow of stages within plugins. The environment can be modified using
command-line parameters, configuration file, or dialog customization.
Features:
* otopi is a library for component installation.
* Modular, task oriented implementation.
* Supports pluggable manager dialog protocol, provides
human and machine dialogs.
* Localization support, gettext enabled.
* Local and remote execution modes are supported.
* Distribution independent implementation (core).
* Compatible with python-2.6, python-2.7, python-3.2</pre><br></div></div></div></div>
</blockquote></div>