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

Reply via email to