[Freeipa-devel] Streamline client use cases

[Simo Sorce]

On Wed, 2011-05-18 at 14:13 -0400, Adam Young wrote:
> 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?

Yeah please do.

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

"just" mkdir and chown ? :)

The problem is that we may not even have a nfs mount with the home
directories.
In large domains that span though the globe, home directories may be
local to the zone the users are created and simply not exist elsewhere.

> > 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 larger the org, the more complex and less common the configuration.
I think we can help at most small shop with straightforward
configurations, anything else is simply unpredictable.

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

At login time it is very unlikely to be possible if you think of NFS
mounts. A cron job process is a distinct possibility that admins can
easily set up.

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

For local homes clients can be configured to use pam_oddjob_mkhomedir

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

Then go for pam_oddjob_mkhomedir it is the easiest one.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York