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

[Simo Sorce]

On Tue, 25 Nov 2014 08:31:33 +1030
William B <william at firstyear.id.au> 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. 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.

Hi William, good news is, Dogtag, DNS and NTP are all optional
components, you can install a FreeIPa server withouth the CA and
without DNS. NTP is installed by default, but it is very easy to
diasable it if you want.

Kerberos is a core feature and cannot be disabled, but I thing you
figured that out already.

We have some plans to split the rpm packaging so that DNS and CA
components can be split into separate subpackages, however we are not
there yet, as some restructuring of the installer and framework will
need to happen to be able to completely omit some of the pieces.

We are well aware of the shortcomings of the documentation,
unfortunately our upstream documentation effort died due to not enough
participation, so in the future the most up to date docs will be RHEL
docs. We'll add pointers to them in freeipa.org pages once we are happy
enough with them.

On the testing side we are adding a lot of tests upstream that should
help improving test coverage and feature regressions, any help there is
welcome.

We always welcome feedback and help with the project, whether it is
code, or additional HOWTOs documentation or even just specific bugs and
RFEs that point out specific issues or areas where we can do better. Of
course our resources are limited so we'll prioritize what is most
requested, sometimes at the expenses of features we'd really like to
see but have no way to fund development for in the short term.

HTH,
Simo.

-- 
Simo Sorce * Red Hat, Inc * New York