Wednesday Feb 18, 2009

ACLs on Shares

With build 109 of Open Solaris, a new feature has been added to the CIFS server - ACLs on Shares.


ACLs on shares bring better compability with the Microsoft implementation and allow more control over access than the CIFS server previously supported.  Basically, it is now possible to set and modify ACLs on the individual share resources for CIFS.  That is, if you create a CIFS resource called "My Files" on a ZFS dataset pool/my-files, you can add another layer of ACL support at the share level.  This is done using standard Open Solaris utilities (chmod to modify and ls to view).  There is now a new file system object that holds the ACLs for ZFS file systems.  In the case of "My Files", the root of the file system is /pool/my-files. If you "cd /pool/my-files/.zfs/shares", you will now see a file object with the name "my_files".


This file object is only used to hold the ACL values for the share. It cannot be renamed or removed using file system utilities.  Only chmod and ls (or other utilities that deal with ZFS ACLs) work on it.


If you create a second resource (CIFS share) on the same path, that share name will also appear in the same directory.  Each one of these objects may have different ACL specifications. The result is that you could have one share that is read/write while the other is read-only.


ACLs on shares are essentially used to remove access that the file system may be providing.  When used in conjunction with the host-based access control, there is a great deal of fine level control over access available.

Most of the time there won't be a need for ACLs on the individual shares, but they do provide some flexibility that can be useful. One possibility is to provide a standard, read-only share for a path that is the one normally available. A second share defined for the same path could have read-write set for some users in order for them to do maintenance on the share.


 Combined with the ACLs on the underlying file system and the coarser level, host-based access control (the rw/ro/none properties on a resource), access can be controlled with quite a bit of detail.  One warning is that with this much control, it is also possible to setup shares that you cannot access, so be careful and plan things out carefully.








Thursday Oct 30, 2008

Some new features

A new set of features have been recently added to sharemgr (ON build 103). These have been long pending RFEs for both NFS and SMB.


New properties available for NFS:



  • none=<access-list>
    Any host that is attempting access that is found in the access-list will be denied all access.

  • root_mapping=uid
    Any root user that is allowed access via the root=<access-list> property will have the root UID mapped to uid on the server

  • charset=<access-list>
    Any host found in the access-list will be assumed to be using the specified charset and file names and paths will be converted between charset and UTF8 on the server.


New properties available for SMB:



  • none=<access-list>
    Any host that is attempting access that is found in the access-list will be denied all access.

  • ro=<access-list>
    Any host found in the access-list will have read-only access

  • rw=<access-list>
    Any host found in the access-list will have read-write access


Note that the new SMB properties are the same as those of the same name in NFS.  Details of all the properties will be included in the sharemgr man page. Adding these properties to SMB and NFS provides functionality that is present in the StorEdge 5210/5310 products.


Note that the <access-list> is the same as has been part of NFS for a long time. It is a list of hosts and/or netgroups. The sharemgr(1m) man page and share_nfs(1) man page describe them in detail.


Monday Dec 17, 2007

sharemgr screencast available

I have just completed a screencast giving an overview of sharemgr usage with examples.  The examples cover NFS and SMB as well as managing with sharemgr directly or via ZFS.  The screencast can be found at http://frsun.downloads.edgesuite.net/sun/08B01361/

Thursday Nov 08, 2007

Other SMB Related Differences

The SMB support brings a few new wrinkles to file sharing.  For example, NFS requires that a given path only be shared once while SMB allows it to be shared multiple times. This is supported via the resource names as described in earlier articles.  There are a couple of other differences that will be visible to administrators:

SMB shares are resource name based while NFS shares are path based 

While NFS shares appear on the client relative to their paths, SMB shares end up flattening the name space and using the resource name as the way to find the data. What this means to the end user is that a file system hierarchy such as would be generated with ZFS won't appear as a directory hierarchy on the client when accessed via SMB.  For example, consider the following ZFS hierarchy:

zfs create data/user1
zfs create data/user2
zfs create data/user2/database
zfs set sharenfs=on data

When seen from an NFS client using the /net/host mechanism, will appear as a full directory tree:

    /net/host/data/user1
    /net/host/data/user2
    /net/host/data/user2/database

When using SMB, things are a bit different:

zfs set sharesmb=on data

From a Windows browser, you will see:

    data_user1
    data_user2
    data_user2_database

as three separate shares that can be mapped (or accessed). That is, they are all at the same level and attempting to go into the directory database in data_user2 won't get you to the data_user2_database share.

Sharing parent or child directories

NFS mandates that if a path is shared, then it is not also possible to share its parent or any of its subdirectories if they are on the same file system. SMB, on the other hand, expects to be able to do this. Sharemgr will allow you to share a parent or child directory if at least one protocol that is enabled for the group supports it. If not do, an error occurs.

In the case where a protocol does support it, the share will only be done for that protocol and an indication is made when the sharemgr show -vp command is run. A "not-shared-with=[protocol]" will be added to the line displaying the share/resource.

Autohome shares

The Solaris SMB implementation concept of autohome shares can result in shares being created dynamically and not being stored in a configuration repository. While this is will appear in sharemgr output the same as a transient share for NFS (share -F nfs /path or sharemgr add-share -t -s /path group), the SMB autohome shares are not created directly by administrator action.

Share command output

The output of the share command works as it always has and shows the paths that are shared by the specified protocol. Currently, it only shows one entry for a path shared via SMB that has multiple resources asssigned. Share defaults to displaying NFS shares. To show SMB shares, use share -F smb. There is currently a limitation that only one instance of the SMB path is displayed via "share" even if there are multiple resource names defined.



Wednesday Nov 07, 2007

SMB vs. ZFS

ZFS users can manage SMB shares similar to the way they manage NFS shares. A new ZFS property, sharesmb, has been added that can be used to enable or disable SMB sharing on ZFS datasets. In general, it works the same as it does with NFS, but a few differences will be visible to users.

The simple case

Consider a ZFS pool "homes" with homes/user01 and homes/user02.  These can be shared via SMB by setting the sharesmb property. In the simplest case, zfs set sharesmb=on homes will start sharing while zfs set sharesmb=off homes will stop sharing. Using sharemgr to display the result shows one of the differences that does occur:

$ sharemgr show -vp zfs
zfs   nfs=() smb=()
          homes
                   homes=/homes
                   homes_user01=/homes/user01
                   homes_user02=/homes/user02

 Note that there is a resource name assigned to each dataset. Since SMB requires a resource name, the simple case of sharesmb will create a name from the dataset name by replacing the disallowed characters ('/' in this case) with an underscore '_' character.

If we expand the above example by creating a new dataset under user02 with zfs create homes/user02/db, the output of sharemgr show will be:

$ sharemgr show -vp zfs
zfs   nfs=()
          homes
smb=()
                   homes=/homes
                   homes_user01=/homes/user01
                   homes_user02=/homes/user02
                   homes_user02_db=/homes/user02/db

 A more complex case

Sometimes the dataset configuration may be deeper than the previous example and the resource names can get a bit long. The sharesmb implementation allows for changing the name to be used. Datasets that inherit the sharesmb property will use the new name as a prefix that replaces the dataset prefix.  For example, if the above example used a more global zpool "data" with homes being a child of data, the resource names would be prefxed with "data_" even if the data/homes dataset was given a mountpoint of /homes.  That is, the output of show would be:

$ sharemgr show -vp zfs
zfs   nfs=()
          homes
smb=()
                   data_homes=/data/homes
                   data_homes_user01=/data/homes/user01
                   data_homes_user02=/data/homes/user02
                   data_homes_user02_db=/data/homes/user02/db

If it is preferred to have /data/homes have a resource name of homes, use sharesmb=name=homes rather than just setting sharesmb=on. For example:


$ zfs set sharesmb=name=homes data/homes
$ sharemgr show -vp zfs
zfs   nfs=()
          data/homes
smb=()
                   homes=/data/homes
                   homes_user01=data//homes/user01
                   homes_user02=/data/homes/user02
                   homes_user02_db=/data/homes/user02/db

 

It is also possible to set any SMB share specific properties via sharesmb. Multiple resource names are also supported for SMB shares. The basic syntax for the sharesmb property is:

sharesmb=on|off|<property-lists>

where <property-lists> is a comma separated list of <property-list>. A <property-list> is a comma separted list of SMB share properties with an optional name=resource pseudo-property in front of it. So, if you use sharesmb=name=homes,name=maisons,ad-container=cn=Other when setting up the SMB sharing, each dataset will be shared with two resource names, homes and maisons.

 

$ sharemgr show -vp zfs
zfs   nfs=()
          homes
smb=()
                homes=/homes
                homes_user01=/homes/user01
                homes_user02=/homes/user02
                homes_user02_db=/homes/user02/db
                   maisons=/homes   smb=(ad-container=cn=Other)
                   maisons_user01=/homes/user01 
smb=(ad-container=cn=Other)
                   maisons_user02=/homes/user02 
smb=(ad-container=cn=Other)
                   maisons_user02_db=/homes/user02/db    smb=(ad-container=cn=Other)

 

Tuesday Nov 06, 2007

Enhanced Resource Names for CIFS

With the putback of SMB functionality in sharemgr, the concept of resources has been significantly enhanced. The first enhancement is that resource names are now full objects within sharemgr. This was necessary in order to fully map SMB functionality into the framework. Second, there can be multiple resources associated with a share.

For SMB, a sharemgr resource implements an SMB share name. SMB allows sharing the same path under multiple share names, each with potentially different properties associated with it. This is what lead to supporting multiple resources for each share. With NFS, the same resource names may be used but the protocol does not really support the concept so they are treated simply as alternate names for the share.

The names allowed for resources are stored internally in UTF-8 after conversion from the locale in effect when the name is created. There are some limitations in what characters may be in a resource name due to restrictions imposed by the SMB environment.  Basically, names may contain any characters except for:

    " / \\ [ ] : | < > + ; , ? \* = <tab>

Spaces are allowed but require careful quoting on the command line.

Using resource names follows the existing sharemgr syntax of: sharemgr set-share -s path -r resource group

When the SMB protocol is enabled on a group, resource names MUST be supplied. This is a requirement of the SMB protocol. Additional names are added using the same syntax as adding the original share and resource. Removing resource names uses the remove-share subcommand syntax: "sharemgr remove-share -s path -r resource group". If multiple resources exist, then just the specified resource is removed. If there is only one resource defined, then the resource and share will be removed.  If remove-share is used without the "-r resource" option, then all resources and the share will be removed.

To illustrate, the following example will create a group "homegroup" with default protocols of nfs and smb. Then a share will be added followed by adding a second resource to the share.

    $ sharemgr create homegroup
    $ sharemgr add-share -s /export/home -r home homegroup
    $ sharemgr show -vp homegroup
    homegroup   nfs=() smb=()
          home=/export/home

    $ sharemgr add-share -s /export/home -r maison homegroup
    $ sharemgr show -vp homegroup
    homegroup   nfs=() smb=()
          /export/home
                   home=/export/home
                   maison=/export/home

The above would result in /export/home being shared by NFS and "home" and "maison" being shared via SMB. If maison should be in a different Active Directory Container, this can be done by setting the "ad-container" property on the maison resource. 

    $ sharemgr set -P smb -p ad-container=cn=Other -r maison -s /export/home homegroup
    $ sharemgr show -vp homegroup
    homegroup   nfs=() smb=()
          /export/home
                   home=/export/home
                   maison=/export/home   smb=(ad-container=cn=Other)

Because resource names are full objects, it is possible to place SMB properties at any of the three levels: group, share and resource with resources inheriting as appropriate just as it does with group and share for NFS.

Renaming a resource is implemented with the set-share sub-command. To rename the resource "maison" to "chateau", use sharemgr set-share -r maison=chateau -s /export/home homegroup

Resource names are global to all groups and must be unique.

If you want to add the SMB protocol to an existing group, it can be done with "sharemgr create -P smb group" command. This assumes that a resource name has been added to each existing share.  If you want to enable SMB but not go through the process of adding a resource name to each share, sharemgr will do it for you if you use the "-f" option.  E.g. "sharemgr create -P smb -f group" will enable SMB after adding a constructed resource name to each share.  The constructed resource name will be based on the path of the share with all the disallowed characters (/) being replaced with underscore (_). This will get things running and allows you to rename the resources later.

 

 

 

Sunday Nov 04, 2007

Sharemgr gets a new protocol


With the introduction of SMB (aka CIFS) server support to Solaris, sharemgr has been enhanced to fully support it. The SMB server implements Windows file sharing functionality. While some of the new features have been discussed in earlier blog entries, there are a few new features as well as details on how the SMB functionality is mapped into sharemgr that will be covered in more detail. The new features include:

  • new protocol "smb"
  • a group may have either, or both, of "nfs" and "smb" enabled
  • a share may have multiple resource names
  • resource names are case insensitive for all protocols
  • resources may be renamed
  • resource names may be used to identify shares on the command line
  • resources may have protocol specific properties for protocols that support this concept
  • sharectl supports SMB operational properties

In general, sharemgr behaves for SMB the same as it does for NFS.  The NFS functionality hasn't been changed other than the resource names can be used as an alias for the path. A given share group may have either or both "nfs" and "smb" enabled. When SMB is enabled, there may be some things that are required for NFS that weren't when only NFS was enabled.

Subsequent blog entries will discuss the SMB support in more detail. Others bloggers will be covering the SMB functionality in more detail.

Wednesday May 23, 2007

Extending sharemgr: How will this impact current NFS users?

How will this impact current NFS users?

Changes to the sharenfs internal model should be made in a way that is transparent to current users. Other than some display differences when using the "show" sub-command and in how resource names are handled, the differences should not really be visible to NFS users. Since resource names are mostly unused with NFS, most users won't even notice the change in how they are handled.

Where changes will be noticable is when another file sharing protocol is installed on the system. When a share group is created, it will be created with all of the protocols enabled unless the administrator specifically creates it with only one protocol enabled. For example:

    sharemgr create -P nfs new-group

would create a group "new-group" with only NFS enabled. Groups that already exist when a system is upgraded to have a new file sharing protocol won't automatically have the new protocol added in order to not cause any surprises. If you do want to enable the new protocol on a group, it is a simple matter of issuing the following command:

    sharemgr create -P newproto new-group

and the protocol is added to the group and shares wil be shared out with the newproto protocol. There is a special case where the command will not work. If the newproto is a protocol that requires resource names for operation and any of the existing shares don't have a resource name, the create of the new protocol will fail with a warning indicating that the protocol requires the resource name. This allows the admin to go in and add a resource name to each share that doesn't have one. It is also possible to tell sharemgr to add the protocol anyway and to create a resource name for those shares based on the path name. This can be done using the force (-f) option:

    sharemgr create -P newproto -f new-group

In this case, the path is used as a resource name with all the '/' characters changed to '_'. If the name isn't unique, the a ~n is used on the end of the name where n is incremented until a unique name is constructed. All characters that aren't legal in a resource name are also converted to '_' and the leading / will have been removed prior to conversion.

Since the constructed names won't always be useful, the administrator can then go in and change the resource name to something meaningful. In general, it is best to add the resource names prior to adding the protocol, but if the paths are unique and meaningful, use the -f option.

All other sharemgr operations will be unaffected by the proposed changes when applied to the NFS protocol. 

Friday May 11, 2007

Thoughts on extending sharemgr to other protocols

This is the beginning of a new series of articles on possible future enhancements to sharemgr.


The current implementation of sharemgr only supports NFS. Since the initial release, more has been learned about features that will be needed in the framework to support non-NFS protocols. The first change that became obvious is the need for another layer of object to describe shares for protocols such as CIFS that don't use paths as their identifiers. Sharemgr currently allows a single resource name to be associated with a share. This is fine for NFS where it isn't really used. Some protocols want to use the resource name as the share identifier. In that case, there is a need to provide for multiple resource names per share.

What does it mean for sharemgr to support resource objects? 

 First, the command line will need to be changed to accomodate this. Most places where a "-s path" option can be used, a "-r resource" should also be usable. For consistency, I'm proposing that resources are added like shares. That is:

    sharemgr add-share -s /path -r resource group

would add a share /path with resource named resource to group.  If /path already exists in group, then a new resource will be added to /path. Multiple add-share commands can be used to add as many resource names as needed. Note that resource names would need to be unique in the system and, due to requirements in some sharing protocols, would need to be checked in a case-insensitive manner. Some protocols would use resource names simply as an alias for the path while others may have properties associated with the resource. For NFS, resources are always just aliases.

    sharemgr remove-share -s /path -r resource group

would remove resource from the share /path if there are multiple resources. If resource is the last resource, the whole share would be removed. This is necessary in order to deal with sharing protocols that require having at least one resource name.

Now that there are potentially multiple resource names for a share, show command will need to accomodate them. The current syntax for output isn't up to the task. The XML output always gives detailed info, but what I'm proposing for a "show -vp" is something like:

    sharemgr show -vp
    default      nfs=()   newproto=()
               /tmp    nfs=(nosuid=true) newproto=(uid=4321)

                       resource-1=/tmp
                       resource-2=/tmp   newproto=(uid=5432)

The above shows that share with path /tmp is in a group with NFS and a new protocol newproto enabled. The share has properties for both nfs and newproto and two resource names - resource-1 and resource-2. Resource-2 has an override uid property for newproto. Note that since NFS only uses resource names as aliases, you won't ever see properties on the resource level for NFS.

Next: how will this impact current NFS users?

Tuesday May 08, 2007

Recent performance improvement in ZFS handling of shares

With the recent putback of the fix for CR 6491973 "sharemgr: zfs set sharenfs=on is slow with lots of zfs filesystems", sharemgr and ZFS have taken the next step in integration. The "zfs" command now calls the sharemgr internal API to directly do sharing instead of  using popen to call the share or unshare commands. This has the effect of a significant performance improvement when handling large numbers of ZFS shares via the the "set sharenfs=" mechanism. The largest contributing factor to the popen being slow is the time necessary to pull in large amounts of the configuration data on each invocation of share/unshare with each subsequent call needing more data (in the share case). In conjunction with the in-kernel sharetab implementation, overhead from updating the sharetab file has also helped.

With the changes, times have been reduced significantly. Turning sharenfs on is still faster than turning it off, but both have had significant improvements. The following table shows the results seen in testing (times in H:MM:SS):

  100 on
 100 off
 2900 on
 2900 off
 5000 on
 5000 off
 15150 on
 15150 off
 Before the fix
 0:07:350:12:23
    more than 1 week 
 After the fix
 0:00:070:00:13
 0:02:55
0:05:40 0:08:41  0:33:24 1:06:362:35:36
 Fix plus in-kernel sharetab
0:00:0.7 0:00:0.4 0:00:54
0:03:39  0:02:370:12:08 0:19:40  2:12:14
         

 The times before the fix were very long and I didn't get number for all of them. Additional performance work will be done over time for both ZFS and non-ZFS shares. Some of these could be interesting projects for someone wanting to learn more about shares and SMF.

 

 

 

Monday Apr 09, 2007

Future enhancements

There are a number of enhancements planned for the future of sharemgr.  These enhancements fall into four distinct areas:

  • bugs fixes and performance improvements
  • better ZFS integration
  • additional protocol support
  • usability

The first three are relatively straightforward while the last (usability) is a bit more subjective and will be based, to a large extent, on user feedback.

The next ZFS integration point is to have the "zfs" command use the sharemgr internal API to enable/disable shares. This will improve performance, especially on very large configurations, when setting the "sharenfs" property. The current implementation is calling the share/unshare commands which are slow to startup on large configurations. This fix/enhancement is currently in test.

For additional protocol support, we are looking at what changes to sharemgr are required to potentially support non-NFS protocols such as CIFS. CIFS has some requirements that are quite different from NFS, but for the most part is pretty much the same. One area where CIFS differs significantly is in how shares are named. NFS uses the shared path and CIFS uses a "share name" (there can be multiple share names per path). In sharemgr we are looking at extending the current notion of resource names to provide the naming that CIFS requires. For NFS, resource names will be aliases for the path. For CIFS, they will likely represent the CIFS share name. We are still working out all of the details. Suggestions on other enhancements, or where there are differences between NFS and other file sharing protocols, are always welcome. We want sharemgr to be ready in the event someone wants to integrate another protocol into the sharemgr facility.

As mentioned above, user input is taken into account for future usability enhancements. One area that needs some enhancement is output of the "show" subcommand. We should have an option similar to the "zfs" -o option that allows the user to specify what gets displayed.

Discussion of sharemgr can take place on the OpenSolaris "nfs" community discussion. Bugs and RFEs should be filed under category "utility" and subcategory "filesystem". Anyone interested in making enhancements should start a discussion in the "nfs" discussion area.

Wednesday Mar 21, 2007

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.

Monday Feb 12, 2007

Back to sharemgr - interactions with SMF

Today's article will describe in more detail how sharemgr interacts with the SMF system.

As was mentioned earlier, each sharemgr group is implemented as an instance of the svc:/network/shares/group service. The configuration information for each share is kept in the SMF repository.

The "default" instance always exists and is where shares that were originally specified in the /etc/dfs/dfstab file will be stored. Also, shares that are started with the "share" command will appear as transient shares in the default group.

The other group that always exists is the "zfs" group. This is a special case group where none of the shares are stored in the SMF repository since ZFS manages the configuration information. This group exists in order to start shares at boot time. ZFS interactions will be covered in a future article.

Share groups provide a boot time advantage for large configurations since all of the instances of the group service are started in parallel by SMF. The startup also eliminates the need to run the share command for each share (the traditional model just ran the commands in /etc/dfs/dfstab as a script). The sharemgr command sees the full configuration and starts each share directly. The NFS service (svc:/network/nfs/server) has a dependency on the group service. This causes all of the enabled group instances to be started when the nfs/server service is started.

Associated with a group are protocol specific property sets. These are implemented in the SMF repository as property groups. The details of these property groups are currently subject to change and the details really are protocol specific.  NFS is currently supported but we will likely add more in the future.  The property groups come in two forms.  One for the general properties associated with the protocol and others that are different negotiated property spaces.  For NFS, this latter is how the security properties are handled. Properties are currently implemented using the same name that is defined in share_nfs(1m) and can be seen with the svcprop command.

Shares are also currently implemented as property groups. Since SMF has limitations on which characters that can be used in a property or property group name, the names used for shares are constructed with a GUID (Globally Unique IDentifier) using libuuid. The "path" property within the constructed property group contains the share path. Other properties may also appear in the property group for a share. If you are looking at properties with svcprop, the property groups with a name of the form "S-<GUID>" are related to individual shares. This is for information purposes only. Since the properties and property groups could change in the future, it isn't advisable to modify them directly.

Whenever the sharemgr or sharectl commands make a change to properties that would have an effect on the state of the service, the appropriate parts are notified. Changes to shares directly update the service's idea of the configuration using a protocol specific plugin module. Sharectl issues the appropriate restart commands to the affected protocol service modules.

Because the groups are implemented as service instances, it is possible to enable/disable groups individually thus giving the administrator more control over how and when things are shared.  

Wednesday Feb 07, 2007

The sharectl command

The sharectl command is a companion to sharemgr. It is used to change the operational properties that the NFS service. Prior to the sharemgr interfaces, these operational properties were changed in the /etc/default/nfs file and the services restarted. The sharectl command should now be used to modify any of the properties currently documented in nfs(4).

Sharectl can also be used to view the properties.  For example:

    sharectl get nfs

will  get and display all the properties for the NFS protocol. The output of the above command would be something like:

max_connections=-1
listen_backlog=32
protocol=ALL
servers=32
lockd_listen_backlog=32
lockd_servers=20
lockd_retransmit_timeout=5
grace_period=90
server_versmin=4
server_versmax=4
client_versmin=3
nfsmapid_domain=sun.com
client_versmax=4
server_delegation=on

Note that the property names are all lower case and the NFS_ prefix is generally removed.

If you want to get the current value of just the nfsmapid_domain property, use:

    sharectl get -p nfsmapid_domain nfs

Setting properties is similar to the sharemgr set sub-command. For example, if you want to change the nfsmapid_domain property to abc.com, use the command:

    sharectl set -p nfsmapid_domain=abc.com nfs

The sharectl syntax allows multiple properties to be set at the same time.

An additional function of the sharectl command is that it will restart the services that are affected by changes in the properties if those services are already running. This elliminates the need to find which services need to be restarted. In the future, sharectl will make it easier to migrate the /etc/default/nfs properties into the SMF repository.


In the future, other protocols may be added and an enhanced syntax for dealing with sub-services may be added.


Tuesday Feb 06, 2007

Share properties under sharemgr

Sharemgr uses a different syntax for share property handling than the traditional share command in an effort to provide a more consistent user model. When setting properties, they are always in the property=value form while the traditional share command sometimes used this form and sometimes implied a value. Also, sharemgr deals with each property separately while the traditional share grouped them into a single option string.

For initial setting, the single option string approach isn't really a problem, but if you want to make a change to a single property, you have be careful and reissue the share command with a correctly updated option string. With sharemgr, it is possible to change a single property independently of the other properties.

TraditionalSharemgr
rwrw=\*
rw=access-listrw=access-list
roro=\*
 ro=access-listro=access-list
 nosuidnosuid=true
 nosubnosub=true
root=access-list
root=access-list
public
public=true


 

It should also be noted that the sharemgr "set" sub-command allows changing a single property at a time rather than having to respecify all of the properties. To remove a property, the "unset" sub-command is used. For example:

    sharemgr set -P nfs -S sys -p ro="\*" -p rw=host1:host2 test-group

would set the NFS sys security mode with read only for all hosts except host1 and host2 which are read/write. If you later decide that host3 should be read/write, then:

    sharemgr set -P nfs -S sys -p rw=host1:host2:host3 test-group

would change rw but leave ro alone. Also note that to set security properties for NFS that it is necessary to use the -S option to set the property space to put the properties in.

Non-negotiated properties such as nosuid and nosub are not placed in one of the alternate property spaces and would be set with:

    sharemgr set -P nfs -p nosuid=true test-group

In general, properties can be placed either on the group or on individual shares with properties on a share overriding the same property that is on the group. That is, while shares always inherit properties from the group they are contained in, they can have properties that override them.  There is also one property that is only allowed on shares and not on groups -- the "public" property. This is due to there only being one share on a server that may have that property set.

The syntax for setting a property on a share is:

    sharemgr set -P nfs -s /share/path -p property=value test-group


About

dougm

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today