sharemgr - Solaris管理共享文件新工具

1. Introduction to sharemgr

This is the first in a series of posts about the new NFS management facility called "sharemgr" that is now part of OpenSolaris.

Sharemgr is a new framework for managing shared files that makes extensive use of the SMF facility. All configuration information is kept in the SMF configuration repository although backward compatibility with the /etc/dfs/dfstab configuration file is maintained. Also, the traditional share/unshare commands continue to work but have been reimplemented using the sharemgr framework.

All management functions are handled through the command line. Having a command to perform all management operations simplifies tasks. Directly editing the /etc/dfs/dfstab file is discouraged, although it will continue to work for now.

Along with using the SMF repository for storing the configuration information for shares, sharemgr introduces the concept of "share groups". A share group is a collection of shares that have common sets of options or that need to be grouped for management reasons. Each share group is implemented as an SMF service instance. The "default" instance implements the traditional configuration that previously existed in /etc/dfs/dfstab.

An example of where share groups could be useful is in managing home directories. In this case, most, if not all, of the shares would have the same properties set. With sharemgr you could create a group "homedirs", set the operational properties on the group and then add the shares. All the shares inherit the properties set on the group. If you later decide to change the properties on all home directories, you change them on the group and the shares get updated. The sequence of commands would be:

sharemgr create homedirs
sharemgr set -P nfs -p nosuid=true homedirs
sharemgr add-share -s /export/home/user01 homedirs
sharemgr add-share -s /export/home/user02 homedirs
...
sharemgr add-share -s /export/home/user10
sharemgr show -vp homedirs
homedirs nfs=(nosuid=true)

/export/home/user01
/export/home/user02
...
/export/home/user10

If you later want to enable "sys" security with some read only hosts but all others are read/write, you can add it to the group with:

sharemgr set -P nfs -S sys -p rw="*" -p ro=host1:host2 homedirs
sharemgr show -vp homedirs
homedirs nfs=(nosuid=true) nfs:sys=(rw=* ro=host1:host2)

/export/home/user01
/export/home/user02
...
/export/home/user10

It is also possible to enable or disable a share group. A share group that has been disabled won't automatically be shared on reboot.

The full set of sub-commands for sharemgr are:

usage: sharemgr [-h | [options]]
sub-commands:

add-share [-nth] [-r resource-name] [-d "description text"] -s sharepath group
create [-nvh] [-P proto [-p property=value]] group
delete [-nvh] [-P proto] [-f] group
disable [-nvh] {-a | group ...}
enable [-nvh] {-a | group ...}
list [-vh] [-P proto]
move-share [-nvh] -s sharepath destination-group
remove-share [-fnvh] -s sharepath group
set [-nvh] -P proto [-S optspace] [-p property=value]* [-s sharepath] group
set-share [-nh] [-r resource] [-d "description text"] -s sharepath group
show [-pvxh] [-P proto] [group ...]
share [-F fstype] [-p] [-o optionlist][-d description] [pathname [resourcename]]
unset [-nvh] -P proto [-S optspace] [-p property]* group
unshare [-F fstype] [-p] [-o optionlist] sharepath

  2. Sharemgr and ZFS

While there is still some refinement occurring in how sharemgr and ZFS interact, there is already quite a bit of integration. There are two ways that ZFS file systems may be shared. The traditional method of using share (and now sharemgr) is fully supported and will behave like any other file system that is shared. Alternatively, there is the "sharenfs" property method. If a ZFS dataset is shared by setting the sharenfs property on the dataset, ZFS will manage the share(s).

This article will outline how ZFS managed shares interact with the sharemgr framework.

The first thing to note about ZFS shares is that they appear as sub-groups within the zfs group. For example, if you have a dataset tank/shares that is shared via the sharenfs property

    zfs set sharenfs=rw,nosuid tank/shares

this will show up in a sharemgr show as:

    sharemgr show -vp zfs
    zfs nfs=(nosuid) nfs:sys=(rw=*)
        zfs/tank/shares
          /tank/shares

If additional file systems are created within tank/shares, they are automatically shared and appear in the same sub-group. For example:

zfs create tank/shares/user01
zfs create tank/shares/user02
sharemgr show -vp
zfs nfs=(nosuid) nfs:sys=(rw=*)
    zfs/tank/shares
       /tank/shares
       /tank/shares/user01
       /tank/shares/user02

You can change NFS properties using either the same zfs command to change sharenfs, or you can use sharemgr to make the changes. For example, if you want to restrict the above example to being read-only for hosts host1 and host2, you can use sharemgr:

    sharemgr set -S sys -p ro=host1:host2 zfs/tank/shares

or you can use the zfs command:

    zfs set sharenfs=rw,ro=host1:host2,nosuid tank/shares

As the property lists get more complex, the sharemgr approach becomes simpler and less error prone than the zfs command-line due to not having to construct the entire list of options each time a change needs to be made.

Over time, there will be tighter integration between ZFS and sharemgr and ZFS. The next optimization will be to change the zfs command to call directly into the sharemgr API rather than doing a popen() of the share command for each share.

3. Presentation foils
sharemgr presentation [pdf]