DBusExports
Export management uses the same configuration file syntax and processing for both server startup and DBus initiated changes. This page first describes how to write an export to do what you intend it to do and then explains how to manage exports on a running server.
An export is defined in an EXPORT block. The granted permissions and protocol options are better explained in the configuration file so we will not discuss them here. Instead, we will focus on the interactions between individual exports and their CLIENT sub-blocks.
The whole purpose of an export block in the configuration is to describe where in the server's file namespace to attach a portion of the backend filesystem(s). The export also attaches global and client specific permissions to those mount points.
A default is what you get if you do not explicitly specify a value for a parameter. The server has built in defaults for all parameters that are more or less sensible for the majority of configurations. These can be changed for all exports by using an EXPORTS_DEFAULTS which is similar to an EXPORT block but only has permission and transport options. These override the built-in defaults. As an export block is processed, all its parameters are first set to a default. The values server's built-n values are used unless one has been set in the EXPORT_DEFAULTS block.
NFS-Ganesha infrastructure is able to properly support export of multiple FSALs. Also, several FSALs (VFS, XFS, GPFS, and LUSTRE) now properly support export of multiple filesystems including sub-mounted filesystems. Nested exports (where /exp1 and /exp1/some/path/exp2 are both exports) are more properly supported for NFS v4. Nested exports are mostly supported when the two exports use different FSALs. The Pseudo Filesystem may be used to paste various exports together in a flexible manner.
- NOTE:
- Version 2.1 behavior is that VFS and XFS support sub-mounted non-XFS file systems, while GPFS doesn't. If you use PseudoFS to paste exports together such that one export is pasted on top of a non-FSAL_PSEUDO export, then you need to have an empty directory in the non-FSAL_PSEUDO exported filesystem to serve as a "mountpoint". NFSv3 supports nested exports, but not in the same way.
EXPORT {
export_id = 50;
path = /srv/fs0;
access_type = RW;
pseudo = /fs0;
}
and
EXPORT {
export_id = 51;
path = /srv/fs1;
access_type = MDONLY;
pseudo = /fs0/some/path/fs1;
}
Any file access or client mount in /fs0 will use VFS and be read and write. This will extend all the way down to /fs0/some/path at which point it will transition to /fs1 which only allows MDS access. Presumably DS access is to other nodes in the GPFS cluster. The server must do two things in this example:
- The server detects these relationships at export processing time and sets up a junction in its internal (pseudo) filesystem. When a mount request for NFSv3 is processed, where the lookup of the full path requested in the mount will determine which export is applicable. In other words, a mount request with /fs0/some will use the VFS FSAL and will validate the client operations for read-write. Another mount request for /fs0/some/path/fs1/foo will use the GPFS FSAL and validate client operations for MDONLY. Note that this example has an access type that is NFSv4.1 pNFS and a mount request is an NFSv3 operation. The mount request would be denied in this case. If the exports were defined in reverse where the sub-mount was the ext4 filesystem in /fs0, it would work.
- As regular operatations step through the pseudo filesystem paths, each lookup must detect the junction and move to the appropriate FSAL to continue the lookups. This also applies if there is only a single (the second) export in the examples. Lookup operations will detect that there is a transition between filesystem types in the server's local filesystem and do the appropriate thing, using VFS for the first three nodes followed by GPFS for the rest.
The CLIENT sub-block is used for fine grained control of access to the export. We will discuss the following example.
EXPORT {
Path = /srv/fs0;
Pseudo = /fs0;
Access_type = none;
...
CLIENT {
Access = 192.168.3.4;
Access_type = RW;
}
CLIENT {
Access = 192.168.3.0/16;
Access_type = RO;
}
}
The export as a whole refuses access to any clients because the access permissions are none. However, there are two CLIENT blocks that do allow some access. There can be any number of CLIENT blocks defined. The following is how client access and options are processed on each request.
1. Client 192.168.3.4 gets read-write access because it matches the first CLIENT block. The permissions scan stops on this first match.
2. Client 192.168.4.52 only gets read-only access because it does not match the first CLIENT block but it does match the CIDR address definition of the second one.
3. Client 192.168.5.3 gets no access at all because it does not match any CLIENT blocks and the export's permissions deny all access.
This rule not only applies to access permissions but the other options as well. For example, one could set up the same sequence to allow NFSv3 access to some clients and only NFSv4 access to others.
Version 2.1 adds the capability of managing exports without having to restart the server. This is an important new feature for enterprise environments where server restarts can be very disruptive. The manage_exports command is provided for this purpose.
To add an export, the administrator supplies two arguments to the command and sub-command. The first argument is the path to a configuration file and the second is an expression that identifies which export in the file is to be added.
# manage_exports add /etc/ganesha/my_server.conf 'export(export_id = 14)'
The first argument can be any configuration file with the relevant EXPORT block in it. Common practice would be to edit the main configuration file or a file it may include. In this way, if the server must restart, it would come up with the new export included. This is not a hard requirement however. One could have some exports in separate files and control them with cron jobs.
The second argument to the add command is a description of the export to add. This example shows the addition of the export with the id of 14. This expression is not limited to the export's id number. Any export parameter that can uniquely identify the export can be used. The most common of these would be export_id, path, or pseudo. See DBus interface for a more detailed explanation of the expression syntax. Another example using the path instead would look like:
# manage_exports add /etc/ganesha/my_server.conf 'export(path = /fs0/some/path)'
This example selects the export whose path is defined as /fs0/some/path and adds it to the server's exports.
- NOTE:
- These examples have single quotes around the expression argument because they have whitespace. However, given that the syntax uses ( and ), Bash will get upset unless some quotes are in place. These Python scripts are reference implementations. These kinds of conflicts with Bash or any shell would not be an issue for management tools that did all the DBus operations internally.
To remove an export, the administrator supplies the export's id to the subcommand.
# manage_exports remove 14
This example removes the export added in the previous example. As of V2.1, the argument is the export id. A future version may support the same selection syntax as the add command.
As of V2.1, the only options available are add and remove so the equivalent to a modify is a remove followed by an add of the edited export configuration. This works in that it does not disrupt the server but it does make the export unavailable in the interval between the remove and the add. This is usually not an issue because the NFS protocol expects things to go away. There are ramifications for 9P and if the new export definition does things like turning a read-write into a read-only export.