On 25.11.2014 04:09, Simo Sorce wrote: > On Tue, 25 Nov 2014 08:31:33 +1030 > William B <will...@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 _______________________________________________ Freeipa-devel mailing list Freeipafirstname.lastname@example.org https://www.redhat.com/mailman/listinfo/freeipa-devel