[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Freeipa-devel] Streamline client use cases

On 05/18/2011 11:03 AM, Simo Sorce wrote:
On Tue, 2011-05-17 at 13:56 -0400, Adam Young wrote:
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.
I am not sure how this can be fixed, have a cron job that test the
config is right ?

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.
This could be valuable beyond mere development so it would be anice to

Agreed.  Should I open an enhancement request for this?

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'
We have thought about this earlier, the problem is that the UI runs as
the apache user, so running a script is not going to be really helpful
to run a script straight from the web server.

True, although you could do something where the NFS /home directory gets mounted such that the httpd user has very limited rights on it, basically mkdir and chown. But I agree, that is not a good approach for the general case.
And having a setuid binary to run scripts makes me a little nervous.

In general we have considered the admin duty to create appropriate
storage resources for user's home directories.
Yeah. But it might be a problem of scale. For large organizations, there should be some (optional) support built in for managing user directories.

The thinking was that they can create their own scripts that use the
XML-RPC interface to deal with the IPA part and whatever they like to
deal with any other operation they need to do when enrolling new users/

The more I think about it, the more I realize that it has to be either a standalone process, something done asynchronously, or something done on demand when the user logs in. Take the case where we do a winsync/passsync, we'd want to only create the home dirs at a minimum upon "migrate." Possibly not even then. Take the case where a lab system has its own set of home directories, or a worldwide company where home directoreis are created on local drives and not-necessarily synced.

Still, I'd like to have a solution documented for some of the simple cases.

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]