[Freeipa-devel] RFE - Number of thoughts on FreeIPA

[Rich Megginson]

On 11/24/2014 03:01 PM, William B wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> I have been using FreeIPA for some time now. I have done a lot of
> testing for the project, and have a desire to see FreeIPA do well.
>
> As some background, I'm a system admin for a University, who currently
> runs an unmanaged instance of 389ds. In the future I would love to move
> to FreeIPA, but I want to explain some concerns first.
>
> I have always noticed that FreeIPA is feature rich, but over time I
> have noticed that this comes at a cost. Most components don't get as
> much testing as they deserve, and just installing and running FreeIPA
> for a few hours, one can quickly find rough edges and issues. Run it
> for longer, and you quickly find more. As a business we value reliable,
> and consistent software that doesn't have any "surprises" when we use
> it. Unforseen issues sour peoples taste for things like FreeIPA, as
> many people get stuck on their first impressions.
>
> With these features also comes a lack of advanced documentation. Too
> often the basics are well covered, but there are lots of simple tasks
> that an admin would wish to perform that aren't covered in the
> documentation. High quality, and advanced documentation is really key
> to my work, as not everyone has as much time as I might to learn the
> inside-out of FreeIPA. People want to reference documentation. Again,
> one only needs to sit down and use FreeIPA for a few days, to try and
> use it in their environment and you will quickly find that many tasks
> aren't covered by the documentation. The documentation itself is also
> hard to find, or out of date (Such as on fedoraproject.org, which is
> the first google hit for me).
>
> FreeIPA also pushes a some policies and ideas by default. Consider the
> password reset functionality. By default, when the password is reset,
> the password is also expired. In our environment, where we have a third
> party tool that does password resets on accounts (Password manager),
> this breaks our expectation as a user would then have to reset their
> password again in the FreeIPA environment. Little things like this
> remove flexibility and inhibit people making the swap. These options
> shouldn't be hardcoded, they should be defaults that can be tuned. If
> someone wants to do stupid things with those options, that is their
> choice, but that flexibility will help FreeIPA gain acceptance into
> businesses.
>
> Finally, back to our rich features. Not all businesses want all the
> features of FreeIPA. For example, we don't want the Dogtag CA, NTP, DNS
> or Kerberos components.

Then why do you want to use FreeIPA?  Is it just for 389 LDAP + nice 
command line interface + nice web based UI?

> But the default install, installs all these
> packages even if we don't use them, and it configures services that we
> don't necesarily need. Kerberos is especially a risk for us as there
> are plenty of unforseen issues that can arise when you have an AD
> kerberos domain on the same network, even if they live in different DNS
> namespaces. Contractors install systems into unix networks, unix
> systems end up in windows networks. Over time, as process and better
> discipline is involved, these little mistakes will be removed, but if
> we were to deploy FreeIPA tomorrow, I have no doubt the kerberos
> install would interfere with other parts of the network. I would really
> like to see the FreeIPA build, split into "freeipa-servers" and
> "freeipa-servers-core" where the core has only the 389ds, web ui and
> kerberos components, and perhaps even one day, could even be "kerberos
> free". This might be taking a step back in some ways, but the
> simplicity would be attractive to complex environments wanting to step
> up from unmanaged 389ds, to something like FreeIPA, but without all the
> complexity and overhead of a full install. Over time the extra modules
> can be enabled as administrators please in a controlled fashion.
> - - Yes, these things can be controlled through the use of the server
> install command line switches, but if I'm installing and using only 389
> and krb from FreeIPA, I shouldn't need to install all of dogtag as well.
>
>
> These are just my thoughts on the project, and I think it boils down to
> a few things:
>
> * RFE to split freeipa packages to core and full.
> * Asking for a review and enhancement of documentation.
> * Better functional testing of FreeIPA server and tasks to help iron out
>      obvious issues before release.
>
> Don't take this as harsh criticism. I think FreeIPA is a great project,
> and a great system. I would like to see it improve and be used more
> widely.
>
> - -- 
> Sincerely,
>
> William Brown
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBAgAGBQJUc6q9AAoJEO/EFteBqAmaa+gP/1kB4recq6BFI/RkyBTMvdal
> mUnjJHm5M07xvaYVvO56tjhyQFwja9MrDHO5XWekQFmyKG34/5uOEc5rSUX3Jgvh
> r09r8Tfc8yUmLGtPcbTgw9mK3KgxYKgYCTkucvQPGZN8Yk/mLlkWk8ttGHrO01O4
> ZUZnoG0GxdM6q4NP6Iy/U1hpZTOs2jllir0CGUt6v1gUnGXN6vlpF0SLUcto19XN
> PLBUQRmuwDmGjlCsvBu4k1o4Zjf0rn52+FXNYCNpY95geFxQ4M6tU0N7iw3g4hW2
> u53gklJbQX2u0BdI8KknWnGYg+JzRRh1Gz8wRBHJOZC//SiZndyvekm0SPxkZVPt
> 6JCyei3Uku6KPQwcFFJT7FVmeG5Q5ZSOgzFa6mN7Tky5qu6NwLNe8Rld0/vGQUp+
> 5i0YkPwNo9IV2F+A8KDVQ2BPEjfbjB74c5n0rJojMpS//R192ocoFHVbjQjXK2ho
> dr8rN6lkhPynxw6KakA/8tvfZHTIrgomOCBY8SLyRScRNJYrgWBhSFzPi1+yS6+R
> lRq4fQIiGVfZmwpy7TkhWfiM6N6Y/YmRFOTykm4baHSRiNC+CUlUmN7ONQivWwVs
> 2y1lhAim5VIdBEXXjOIvAa0t7UIaUa/14ajHv29jtfLDGMtJirxU9U/vLSoOOojJ
> W4rLomyv4mLvlK5nAV2o
> =7/dF
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel