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

Tue Nov 25 09:00:04 UTC 2014

On 25.11.2014 04:09, Simo Sorce wrote:
> 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.

William, please open tickets for deficiencies you have found, preferably one
ticket for one specific deficiency:
https://fedorahosted.org/freeipa/newticket

Splinting FreeIPA to separate packages is already tracked in
https://fedorahosted.org/freeipa/ticket/4058

Also, you can help us with documentation yourself - feel free to edit pages
http://www.freeipa.org/page/HowTos
and
http://www.freeipa.org/page/Documentation

You will need an Fedora account - you can get one for free:
https://admin.fedoraproject.org/accounts/user/new

Have a nice day!

-- 
Petr^2 Spacek