On Thu 12 Jan 2012 at 03:58PM, Jan Damborsky wrote: > 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.
That's fine - I thought you were asking for more freedom. I'm all for starting simple and building more complexity only if there is justification. > > 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 > -- Mike Gerdts Solaris Core OS / Zones http://blogs.oracle.com/zoneszone/ _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
