On 05/25/12 01:59 PM, Matt Keenan wrote:
Jan,
On 05/25/12 12:35, Jan Damborsky wrote:
On 05/24/12 07:01 PM, Matt Keenan wrote:
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.
As far as process of manipulating home ZFS dataset
is concerned, there is no difference between those two sysconfig
scenarios (non-interactive versus interactive).
That said, I did notice an issue in interactive scenario which
seems to get triggered by this bug. In particular, sysconfig UI doesn't
allow to create initial user account, since it thinks that parent
of to-be-created home ZFS dataset does not exist - I filed 7171775
for this.
Yeah just read that bug report, of course the reason rpool/export/home
dataset had an extra "/" at end was because in b16 the mountpoint was
being manually set to what target discovery determined to be the
default mountpoint e.g. /export/home/
This bug fix is trying to ensure this does not happen going forward.
Thank you for fixing that, Matt.
That means 7171775will be no longer exposed after your fix.
Though it would still make sense to fix it, since it seems
ZFS mountpoints with trailing slashes are allowed, thus
code processing them should be able to cope with that.
I could take care of that when fixing some other sysconfig CRs.
Jan
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
