[Freeipa-devel] idempotent installer [from LinuxAlt 2013]

[Derek Moore]

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 <derek.p.moore at gmail.com<javascript:_e({}, 'cvml', 'derek.p.moore at gmail.com');>>
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20131120/480d2b7f/attachment.htm>