On Fri 06 Jan 2012 at 10:40AM, Jan Damborsky wrote: > Hi Paul, Mike, > > I am currently evaluating how to approach fix for following problem > you reported and commented on: > > 7058014 if svc-system-config creates rpool/export, it should mount it at > /export > > As it's been a while since that discussion happened, let me try to start with > summarizing the problem, then later take a look at possible solutions. > > Overview > ======== > > System configuration (config-user smf service in particular) provides for > possibility to create initial user account. As part of that, config-user > service creates separate ZFS dataset for user's home directory. > In default case, ZFS dataset '<root_pool>/export/home/<login>' is created with > mountpoint inherited from '<root_pool>/export/home' parent ZFS dataset. > > Since all installers create<root_pool>/export and<root_pool>/export/home > ZFS datasets during installation process (utilizing Target Instantiation > module) > with mountpoints set to /export and /export/home respectively, we end > up with desired '/export/home/<login>' mountpoint for home ZFS dataset. > > Problem statement > ================= > > That said, Automated Installer (used for installation of non-global zones) > is a little bit special in a sense it provides for complete control over > hierarchy of ZFS datasets created. > That means it's possible to end up with a system without '<root_pool>/export' > and > '<root_pool>/export/home' datasets created during installation. Such > configuration > is accomplished via omitting appropriate entries in target section of > customized > AI manifest. > > In such case, '<root_pool>/export' and '<root_pool>/export/home' datasets > are later created by config-user service along with home ZFS dataset as a side > effect of calling 'zfs create' with '-p' option which forces creating all > non-existent parent ZFS datasets. The problem is that those datasets are > mounted on mountpoints inherited from parent dataset (<root_pool> ZFS dataset > in this case), so we end up with following structure: > > dataset:mountpoint > ------------------ > <root_pool>/export:/<root_pool>/export > <root_pool>/export/home:/<root_pool>/export/home > <root_pool>/export/home/<login>:/<root_pool>/export/home/<login> > > Which is what user currently neither expects nor desires. > > Solution A > ========== > > If my understanding is correct you propose to address that in config-user smf > service by explicit setting desired mountpoints for all parents created. > > To be honest I am not quite convinced that's solution which fits the > existing model, as sysconfig should not explicitly manipulate datasets which > are out its scope (parent datasets). It's goal of Target Instantiation module > to handle that task and spreading that logic across several places would > be confusing as well as it does not sound as a good principle in general. > > Another issue I can see with this is that those datasets are explicitly > configured in default AI manifests. If user intentionally omits those entries > in customized AI manifest, I believe we should honor that and not implicitly > create those datasets despite user's intent. > > Based on that, I propose following alternative. > > Solution B > ========== > > If config-user is asked to create ZFS home dataset and its parents are > missing, treat > that as a fatal error. In such case, let config-user smf service inform user > on console > about that and let the service enter maintenance mode. > The reasoning behind this is that such situation would be result of a > misconfiguration > on user's side, in particular that there seems to be a requirement to create > ZFS dataset > in ZFS hierarchy not compliant with the one explicitly expressed via AI > manifest. > I believe we shouldn't try to remedy such state, as we can't assure the > result would > be compliant with user's intent. Instead, we should let user know that > invalid configuration > was supplied. > > Please let me know if that may be a reasonable alternative or if I am missing > other aspects of this problem which should be taken into account when looking > for a solution of this problem. > > Thank you very much, > Jan
I'm happy with Solution B. If we get an escalated RFE for something like Solution A, we can reconsider at that time. We should probably take a look at the relevant documentation and be sure that examples help users avoid the error path. -- 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
