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
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 Sorce * Red Hat, Inc * New York

Freeipa-devel mailing list

Reply via email to