[Freeipa-devel] Streamline client use cases

[Adam Young]

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
> have.

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'
>> hook.
> 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.
> Simo.
>