In general you are correct, but there's a nuance: Mark's users are to be added
a local zone. That generally means he has no NFS/kernel-CIFS server inside it,
while having an FTP or SSH server (and possibly SAMBA, I didn't check).
So he can indeed use the automounter to mount the home directories from the
global zone's (or some other) NFS server with home directories.
While I have seen many warnings explicitly noting that an NFS server should
never be its own client (including sharing global shares to local zones), I
confess I have failed to find any specific grounds for that. We use the scheme
on many systems, and nearly the only problems we have are when the domain names
(rarely - host names) need to be changed - this can occasionally lock the
server/client, including failure of a zone reboot if it had mounted shares, and
may require a server reboot. Happened about 2-3 times overall for the past 3
years and dozens of servers.
Now, a better way in terms of performance may be to share a global zone's
"/export/home" into the local zone via loopback-mounts (see zonecfg).
And by far the most simple way would be to adduser with the home directory
plainly in /export/home of the local zone (and referenced so in /etc/passwd) -
but if he rolls back snapshots of the zone, this may cause loss of recent
editions - which may be or not be what Mark desires.
Personally, I'd primarily go with user homes stored in /export/home,
automounted over NFS into the local zone, until someone proves me how and why
this is a wrong thing to do (I am asking for that for a while now).
As a second option, I'd access the global zone's /export/home(/username) via
loopback mount of the zone config, and use this very path in the definition of
the local zone's user account.
Both ways data (home dir) is kept separately from code (zone) and can be
managed (rolled back, backed up, re-shared, etc.) separately.
This message posted from opensolaris.org
zones-discuss mailing list