-----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.
- --
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@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
