On Mon, Mar 10, 2008 at 2:00 PM, Ethan Quach <ethan.quach at sun.com> wrote:
>  Proposal
>  --------
>  A proposal we have for solving this in Snap Upgrade, is to create
>  a /var/shared directory which will be its own dataset shared across
>  all Snap Upgrade BEs.  We will move the directories that we want
>  "synced" under /var/shared and create symlinks from their original
>  locations.  The directories that we are proposing to do this with are:

I (still) think this is a very good idea.  Thanks for listening!

>  /var/adm
>  /var/log
>  /var/mail
>  /var/spool

There may be others worth discussing.  For details see
http://mail.opensolaris.org/pipermail/caiman-discuss/2007-August/000737.html.


>  Restrictions/Issues
>  -------------------
>  The list of items being synced will no longer be a publicly
>  modifiable interface.  Users will no longer be able to add
>  arbitrary files or dirs that they want synced.

Does it need to be an either/or?

Perhaps keeping the lu style synclist with a DATASET entry would be
best.  Merging your list above with the example at
http://docs.sun.com/app/docs/doc/820-0178/6nbufm85f?a=view:

/var/share                   DATASET
/etc/passwd                  OVERWRITE
/etc/shadow                  OVERWRITE
/etc/opasswd                 OVERWRITE
/etc/oshadow                 OVERWRITE
/etc/group                   OVERWRITE
/etc/pwhist                  OVERWRITE
/etc/default/passwd          OVERWRITE
/etc/dfs                     OVERWRITE

>  To keep the current BE's namespace safe, the /var/shared directory
>  must be mounted read-only for alternate BEs.  pkg(5) transactions
>  against mounted BE alternate roots will require special support.
>
>  For this to be supportable with zones, a separate /var/shared
>  dataset will need to exist for every zone.  Upon BE creation,
>  corresponding zones across BEs share a /var/shared dataset.

Assuming my suggestion for augmenting rather than replacing synclist
is taken, it would be most desirable to allow each zone to have its
own synclist.

-- 
Mike Gerdts
http://mgerdts.blogspot.com/

Reply via email to