On 05/24/12 16:24, Jack Schwartz wrote:
Hi Matt.
I'm sure the fix works as you've tested it in our environment, but I
want to understand better the reason under the fix.
It looks to me that there is a race condition between setting something
up (happens to be a user account) under rpool/export and mounting the
rpool/export zfs filesystem tree. The fix appears to be to specify the
mountpoint to zfs only when the default mountpoint doesn't match the
fs.mountpoint.
There is definitely a difference between the sequence of events that
take place on initial boot depending on whether users are created
automatically via profiles or manually via sysconfig.
Why, I don't know.
Users's home dirs are created as datasets under rpool/export/home
If rpool/export/home has it's mountpoint manually set to
rpool/export/home the automatic user creation succeeds, but the home
directory is created before rpool/export/home dataset is mounted.
If the mountpoint for rpool/export/home is left at "inherited" this
sequence works.
Someone else more knowledgeable can probably explain this better. My fix
just reverts back to what has been happening all along and ensure things
continue to work.
1) What would the default mountpoint and fs.mountpoint be in the case
when setting up a user?
The code is not concerned directly with creating a user. Initial user
creation is done as stated either automatically via sysconfig profiles
or manually on first boot, so mountpoint vs fs.mountpoint is not
relevant here.
2) How come not specifying mountpoints fixes a race condition? The term
"ZFS inheriting from its parent" to me still means a new ZFS file system
will be created. (How could there be a parent if there was no child
created?) Does the new ZFS file system get created at a different point
in time?
To be honest as stated I'm not really sure why it fixes the problem. In
terms of rpool/export/home, a new dataset is created and it does have a
parent rpool/export.
cheers
Matt
Thanks,
Jack
On 05/24/12 04:09 AM, Matt Keenan wrote:
Hi,
Can I get a pair of eyes on a fix for bug :
Bug;
7171068 booting zones with non-root users in SC config profiles leads
to svc:/filesystem/local in mainteance
http://monaco.us.oracle.com/detail.jsf?cr=7171068
Webrev:
https://cr.opensolaris.org/action/browse/caiman/mattman/7171068/
Bug is caused by fix for 7166325, which attempted to fix where
mountpoints even if specified in Manifest were ignored during zones
creation.
What was not realized during this fix is that Target Discovery will in
99% of cases always set the mountpoint property of a filesystem during
discovery, regardless of whether it's specified in the manifest or not.
Because of this after fix for 7166325, ALL datasets being created in a
zone were now explicit setting their mountpoint. This should not be
the case, in particular rpool/export/home needs to inherit it's
mountpoint from it's parent. Mountpoint setting should only happen
where the mountpoint differs from the default mountpoint as set by
Target Discovery. Target Discovery sets the mountpoint because DC
needs to know this.
- Tested installing zones where users are autoconfigured.
- Also ensured bug 7166325 is fixed with this new revision.
- Ran full suite of unit tests and no regressions found.
regards
Matt
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
