On 01/12/12 03:05 PM, Mike Gerdts wrote:
On Thu 12 Jan 2012 at 11:20AM, Jan Damborsky wrote:
On 01/11/12 04:27 PM, Mike Gerdts wrote:
On Wed 11 Jan 2012 at 03:34PM, Jan Damborsky wrote:
[snip]
Looking at existing config-user start method, determining that information
should not be a big deal. The modified error message would then look like:
"Service failed to create home directory ZFS dataset for initial user,
because following parent ZFS datasets are missing (were not created
during installation):
rpool/export
rpool/export/home
To recover from the failure, create parent dataset(s) manually on command
line and clear the service using 'svcadm clear config-user'."
Alternatively, reinstall affected system(s) using ai_manifest(4) specifying
appropriate entries for those ZFS datasets (refer to
/usr/share/auto-install/manifest/default.xml as an example)."
That last paragraph should be reworked to include the commands required.
Otherwise, we will end up in a situation where the home directories are
mounted at /rpool/export/home/<user> rather than /export/home/user.
Suggested text follows:
"To recover from the failure, create parent dataset(s) manually on command
line with:
zfs create -o mountpoint=/export rpool/export
zfs create rpool/export/home
then clear the service using 'svcadm clear config-user'." Alternatively,
reinstall affected system(s) using ai_manifest(4) specifying appropriate
entries for those ZFS datasets (refer to
/usr/share/auto-install/manifest/default.xml as an example)."
It certainly makes sense in 'default' scenario (home dataset in form of
<root_pool>/export/home/<login>), since in this case we know how mountpoints
should look like.
I may still recommend to go with just listing missing parent datasets
in case user provides arbitrary home ZFS dataset in SC profile, as
mountpoints
for parent datasets in such case may not be guessed correctly. I assume
that would be only a minority of cases, as AFAIK that feature hasnot
been used
so far.
Jan
My assumption was that the commands I mentioned were not hard coded,
rather based on looking at the current zfs dataset hierarchy and
figuring out what makes. For instance, if the system has a pool called
export with mountpoint=/export and the home directory needs to be
created at /export/home/<user> it would say:
zfs create export/home
If it had one pool (myrootpool in this example) and the home directory
needed to be created at /export/home/<user>, and no dataset was mounted
at /export, it would advise:
zfs create -o mountpoint=/export myrootpool/export
zfs create myrootpool/export/home
If it had multiple pools (rpool and data) it would need to be somewhat
ambiguous, while still offering clear advice:
zfs create -o mountpoint=/export<pool>/export
zfs create<pool>/export/home
It arrives at what it recommends to do via logic similar to what I
described in comment 11 of 7058014.
I didn't mean to hardcode things for default case either, though it seems
we are not perhaps on the same page as far as definition of 'default' case
is concerned.
When referring to 'default', I mean
* home ZFS dataset in form of <root_pool>/export/home/<login>
AND
* mountpoint in form of /export/home/<login>
which is compliant with what useradd(1m) considers to be a default case.
If my understanding is correct, your 'default' scenario
just requires mountpoint hardcoded to /export/home/<login>.
I don't think we want such level of freedom, as I am afraid that
however we implemented it, the result would be fragile, thus potential
source of maintainability issues in future.
Also, I feel it would not be easy for end user to understand how
home ZFS dataset will look like.
Jan
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
