I meant to say the integration of components and subsystems and providing some automation is what is truly difficult.
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. Ah, yes, I had repressed my memories of SASL and nscd! So maybe FreeIPA has just a little bit more left to integrate, but it's light-years ahead of where we used to be. ;) Thanks for the nostalgic read! :) On Monday, November 18, 2013, Paul Robert Marino wrote: > 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. > 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. > > 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. > > 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. > > 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. > > 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. > > 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. > > 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. > > 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. > > > -- Sent from my HP Pre3 > > ------------------------------ > On Nov 15, 2013 11:44, Derek Moore <[email protected]<javascript:_e({}, > 'cvml', '[email protected]');>> > wrote: > > 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. >> > > This is very true! Nothing is quite so complex as realm controllers for > krb5+ldap+nss+sssd+bind+ca+blah+blim+blam! > > You guys sure have your work cut out for you! > > 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). > > 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. > > 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: > > http://www.ovirt.org/Features/Otopi_Infra_Migration > > 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 > > >
_______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
