There are a wide variety of install scenarios, so we don't get too
specific on some scenarios. One that is pretty common in the test and
acceptance phase that might not be a real issue in a live deployment
deals with DHCP values for nameservers. For example, when coding on my
laptop, the DHCP server provides a bogus value for the nameserver.
Additionally, we have a Lab setup at our office that is managed by
another team, and it certainly won't provide the nameserver value for a
development IPA server.
What I'd like to see is a workflow based approach to the ipa-client
setup that does basic configuration and troubleshooting.
If the user runs ipa-client, attempt autodiscovery. If autodiscovery
fails, the first thing we should do is get the name or IP address of the
nameserver, and then retry autodiscovery. If it fails again, we can
potentially test for firewall ports etc. For example, if we attempt to
do an xmlrpc to the IPA server, get back a "Negotiate" response, and yet
we can't talk to the KDC, it is likely a firewall issue. These are
probably the most common issues on client install.
Second deals with adding users. We have a catch 22 regarding
automount. Ideally, an NFS server will contain the automounted home
directories for the users. For a small organization, automounted /home
in its entirety is probably fine. However, far more common is to
autmount the separate directories for each user using a matching rule.
In this case, there is no easy way to create the users home directory on
demand. I'm not sure that there is a single 'right' solution, but one
possible approach is to provide a "call this script after user creation'
hook.
I can open tickets for these, but I'd like to vet the concepts first.
Perhaps there is something I'm missing in both cases.
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel