Configure mandatory and recommended NFS client mount options with WEKA based on real-world testing and validation for optimal performance and reliability.
To ensure optimal performance and reliability when using NFS clients with WEKA, it is essential to configure specific mandatory and recommended mount parameters. These parameters have been tested and validated in various real-world scenarios.
The following parameters must be included alongside the client's default mount options:
NFSv3 and NFSv4: proto=tcp
For enhanced performance and stability, include the following parameters in addition to the mandatory ones:
NFSv3:
hard
vers=3
Specifying NFS Client Version: Always explicitly define the NFS client version (vers=3 or vers=4) to prevent unexpected protocol negotiation during server configuration changes.
Resiliency to network interruptions: Use the hard option to ensure the client retries operations during temporary network interruptions, maintaining data integrity and operation continuity.
Improving NFS performance: For the latest WEKA versions, consider setting the
Related topic
hard
vers=4
nconnect1Default NFS client options: Beyond the parameters listed above, the default options negotiated by the NFS client at mount time are suitable for most use cases. For advanced configurations or additional NFS client options, refer to the documentation provided by your operating system.
The WEKA system enables file access through the NFS protocol instead of the WEKA client.
NFS (Network File System) is a protocol that enables clients to access the WEKA filesystem without requiring WEKA's client software. This leverages the standard NFS implementation of the client's operating system.
WEKA supports an advanced NFS implementation, NFS-W, designed to overcome inherent limitations in the NFS protocol. NFS-W is compatible with NFSv3 or NFSv4 protocols and offers enhanced capabilities, including support for more than 16 user security groups and NFS file-locking.
Adhere to the following guidelines and requirements when deploying the NFS service.
A persistent cluster-wide configuration filesystem is required for the protocol's internal operations using NFSv4 or Kerberos integration. See .
An interface group is a configuration framework designed to optimize resiliency among NFS servers. It enables the seamless migration of IP addresses, known as floating IPs, from an unhealthy server to a healthy one, ensuring continuous and uninterrupted service availability.
An interface group consists of the following:
A collection of WEKA servers with a network port for each server, where all the ports must be associated with the same subnets. For resiliency, a minimum of two NFS servers are required.
A collection of floating IPs to support the NFS protocol on specified servers and NICs. All IP addresses are required to be within the same subnet, and the servers must already have static IP addresses on those NICs within that subnet.
A routing configuration for the IPs. The IP addresses must comply with the IP network configuration.
An interface group can have only a single port. Therefore, two interface groups are required to support High Availability (HA) in NFS. When assigning the other server ports to these interface groups, consider the network topology to ensure no single point of failure exists in the switch.
You can define up to 10 different Interface groups. Use multiple interface groups if the cluster connects to multiple subnets. You can set up to 50 servers in each interface group.
The WEKA system automatically distributes the IP addresses evenly on each server and port. If a server fails, the WEKA system redistributes the IP addresses associated with the failed server to other servers.
The WEKA system automatically configures the floating IP addresses used by the NFS service on the appropriate server. Refrain from manually configuring or using the floating IP.
To ensure load balancing between the NFS clients on the different WEKA servers serving NFS, it is recommended that a round-robin DNS entry be resolved to the list of floating IPs.
Related information
The NFS client mount is configured using the standard NFS stack operating system. The NFS server IP address must point to the round-robin DNS name.
The NFS client permission groups are defined to control the access mapping between the servers and the filesystems. Each NFS client permission group contains the following:
A list of filters for IP addresses or DNS names of clients that can be connected to the WEKA system by NFS.
A collection of rules that control access to specific filesystems.
WEKA facilitates the seamless integration of NFS with an existing Kerberos service. This integration enables clients' authentication, data integrity, and data privacy over the wire when interacting with the NFS server, ensuring robust security even across untrusted networks.
The Kerberos security levels are:
krb5: Implements basic Kerberos authentication.
krb5i: Incorporates Kerberos authentication with data integrity assurance.
krb5p: Integrates Kerberos authentication with data integrity and privacy measures.
WEKA supports Kerberos authentication for NFS using AD and Kerberos MIT:
Active Directory (AD): NFS integrates with Active Directory (AD), which includes built-in Kerberos services. WEKA interacts with the AD using the Kerberos protocol to authenticate service requests among trusted devices.
Kerberos MIT: NFS integrates with Kerberos MIT, implementing the Kerberos protocol, which uses secret-key cryptography for authentication across insecure networks. This protocol is widely standardized and utilized.
The following Kerberos service interactions ensure secure communication between the client and the WEKA NFS server:
Client authentication and ticket request: The client sends a request, including encrypted credentials, to the Authentication Server for a Ticket Granting Ticket (TGT).
Ticket generation and delivery: The Authentication Server verifies the client’s identity, generates a session key, forms a TGT, and sends these to the client.
Ticket extraction and service request: The client decrypts the received message, extracts the session key and the TGT, and sends a service request to the Ticket Granting Server.
Add as many servers as possible to the interface group for performance scalability.
Floating IPs facilitate load balancing by evenly distributing them across all interface group servers and ports, given the system has 50 or fewer NFS interfaces. However, with the limitation of 50 floating IPs per cluster, systems with more than 50 NFS interfaces may not have a floating IP for each interface.
When different clients resolve the DNS name into an IP service, each receives a different IP address, ensuring that other clients access different servers. This allows the WEKA system to scale and service thousands of clients.
To ensure the resilience of the service if a server fails, the system reassigns all IP addresses associated with the failed server to other servers (using the GARP network messages), and the clients reconnect to the new servers without any reconfiguration or service interruption.
NFS file-locking is a mechanism that ensures synchronized access to files by multiple processes in a networked environment. It maintains data integrity and consistency by preventing simultaneous access to the same file, thereby preventing potential data corruption.
Port prerequisites: Ports used by the nlockmgr and status services must be open on the clients and WEKA servers. Use one of the following methods to meet this requirement:
Disable and stop firewalld using the commands:
Define the ports in /etc/services
To inspect the active locks on a specific file, use the following command:
<inode-id>: The unique identifier of the file’s inode.
--snap-view-id snap-view-id: (Optional) Specifies the snapshot view ID for listing locks on a file within a particular snapshot.
--verbose: (Optional) Provides detailed lock information, including the lock owner and type.
This command outputs a list of all current locks on the specified file, enabling administrators to monitor and manage file access effectively.
For detailed procedures, see the related topics.
Related topics
Service ticket delivery & extraction: The Ticket Granting Server sends the Service Ticket and the Service Session Key to the client, who then decrypts the response and extracts these for later use.
Service access & verification: The client generates an authenticator for the network service and sends it along with the Service Ticket to the network service, which then verifies the Service Ticket and the authenticator.
rpc.statdNFS client prerequisite: To use NFSv3 with locking on an NFS client, ensure the rpc.statd service runs in the NFS client. This enables clients to mount NFSv3 shares.
systemctl stop firewalld.service
systemctl disable firewalld.serviceweka debug flock list <inode-id>
[--snap-view-id snap-view-id]
[--verbose]status 46999/tcp # rpc status
status 46999/udp # rpc status
nlockmgr 47000/tcp # nlockmgr
nlockmgr 47000/udp # nlockmgrThis page describes how to configure the NFS networking using the GUI.
Using the GUI, you can:
NFS global settings consist of parameters that enable you to customize various aspects of the NFS service, including the support of the NFS protocol versions, the types of Kerberos authentication to use, and the port for mount requests and NFS locking.
By tailoring these settings, you can ensure that the NFS service meets your needs and requirements, such as supporting NFS V3 and V4 for compatibility with different client systems.
Before you begin
To support NFS file-locking, ensure the system meets the prerequisites outlined in .
Procedure
From the menu, select Manage > Protocols.
On the left pane, select NFS.
Select the Settings tab.
In the Global Settings section, select Update, and do the following:
Config FS: Select the cluster-wide configuration filesystem that maintains the NFS and Kerberos configurations.
Supported Versions: Select the NFS versions you want to support based on your needs. Options include V3, V4, or both.
These ports are only relevant for NFSv3. The default value of 0 indicates using the default published ports.
Select Save to apply the settings.
Configuring the NFS cluster level involves creating an interface group and assigning at least one server with its corresponding port.
Procedure
From the menu, select Manage > Protocols.
On the left pane, select NFS.
In the Configuration tab, select the + sign near the Interface Groups title.
In the Create Interface Group dialog, set the following properties:
Name: A unique interface group name (maximum 11 characters).
Gateway: A valid IP address of the gateway.
After creating an interface group, set the ports for this group to establish the NFS cluster. You can only set these ports on frontend containers. To ensure system resiliency, have at least two NFS servers in place.
Repeat this port setting process for each server participating in the NFS cluster.
Procedure
In the Configuration tab, select the interface group.
In the Group Ports table, select +Create.
In the Add Port dialog, set the following properties:
You might need to remove an interface group due to a change in network configuration, for efficiency, for troubleshooting, during network reorganization, or to replace it with a more suitable group. Always check that the group isn’t in use before you remove it to avoid disruptions.
Procedure
In the Configuration tab, select the interface group.
In the Group Ports table, select the three dots, and from the menu, select Remove.
Procedure
In the Configuration tab, select the interface group.
In the Group IPs table, select +Create.
In the Add Range IP dialog, set the relevant IP range.
Select Save.
Procedure
In the Configuration tab, select the interface group.
In the Group IPs table, select the three dots, and from the menu, select Remove.
Integrating the NFS and Kerberos service is critical to setting up a secure network communication process. This procedure involves defining the Key Distribution Center (KDC) details, administrative credentials, and other parameters to ensure a robust and secure authentication process.
Before you begin
Ensure a configuration filesystem is set. See .
Ensure the NFS cluster is configured and running. See .
For Active Directory (AD) integration, obtain the required information from the AD administrator. (WEKA handles the generation of the keytab file.)
For MIT integration, obtain the required information from the MIT KDC and OpenLDAP administrators, and a pre-generated keytab file stored in an accessible location is required.
Procedure
From the menu, select Manage > Protocols.
On the left pane, select NFS.
Select the Settings tab.
In the Kerberos Authentication section, select Configure.
Choose the tab that matches your authentication method and follow its instructions.
From the Kerberos Authentication Type, select Active Directory (AD).
Set the following parameters to configure the Kerberos with AD KDC servers:
KDC Realm Name: Specifies the realm (domain) used by Kerberos.
Resetting the Kerberos configuration is necessary when you need to completely remove the Kerberos service configuration data. Once the data is removed, you can set up a new Kerberos service integration.
Upon resetting the Kerberos configuration, it triggers the following two actions:
The NFS containers are restarted, leading to a temporary disruption in the I/O service for connected NFS clients.
The authentication types in the NFS Global Settings are reset to their default values.
Creating additional client groups helps in better organization, customization of settings, and enhanced security by segregating access levels.
Procedure
In the Permissions tab, select the + sign near the Client Groups title.
In the Create Client Group dialog, set the client group name.
Select Save.
Assigning a DNS and IP to a client group facilitates network communication and resource access. This step is crucial for the group’s operational functionality.
Procedure
In the NFS configuration, select the Permissions tab.
In the Permissions tab, select Add DNS for the relevant Client Group.
In the Create Client Group DNS Rule dialog, set the DNS server name. Then, select Save.
In the Permissions tab, select Add IP for the relevant Client Group.
In the Create Client Group IP Rule dialog, set the IP address and bitmask. Then, select Save.
Procedure
In the Permissions tab, select the trash symbol displayed next to the DNS or IP for the relevant Client Group.
Creating NFS permissions for a client group enhances access control and efficiency. It allows system administrators to manage access to files, protecting sensitive data and simplifying permission management.
NFS permissions also provide flexibility and foster collaboration. They can be adjusted as needed, especially when a team needs to work on the same files. However, they work best in trusted environments.
Before you begin
If you create an NFS v4 client permission, verify that a global configuration filesystem is already set in the system. See .
Procedure
In the Permissions table, select +Create.
In the Create NFS Permission dialog, set the following properties:
Client Group: The client group to which the permissions are applied.
Filesystem: The filesystem to which the permissions are applied. A filesystem with Required Authentication set to ON cannot be used for NFS client permissions.
You can edit the existing NFS permission settings for a client group. You can also move the priority to the top or bottom priority (related to other client group priorities). If the client group permission setting is no longer required, you can remove it.
Procedure
In the Permissions table, select the three dots of the client group to edit, and select Edit.
Set the relevant properties: Type, Priority, Supported Versions, Squash Root, Authentication Type, Anon. UID, and Anon. GID. Then, select Save.
To move the priority of a client group setting to the top or bottom priority, select Move to top priority or Move to bottom priority.
To remove the client group permission setting, select Remove.
Related topics
NONE: No authentication.
SYS: System authentication.
KRB5: Basic Kerberos authentication.
KRB5i: Kerberos authentication with data integrity.
KRB5p: Kerberos authentication with data integrity and privacy.
The Kerberos authentication types are visible only if Kerberos is configured. Example: KRB5 KRB5i KRB5p. The default values depend on Kerberos configuration:
If not configured: NONE SYS
If configured: KRB5
Mount Port: Set the port that the mountd service binds to.
Lock Manager Port: Set the port for the network lock manager’s registration.
Status Monitor Port: Set the port for the network status monitor’s registration.
Notification Port: Set the port for the notification’s registration.
Select Save.
Port: Select the port from the list.
Select Save.
KDC Secondary Server: Identifies the server hosting the secondary Key Distribution Center service.
KDC Admin Server: Identifies the server hosting the administrative Key Distribution Center service.
Set the following parameters to register the Kerberos service:
NFS Service Name: This refers to the complete domain name for a specific NFS server.
KDC Realm Admin Name: The username of an administrator who has access to the LDAP directory. This user manages the KDC within a realm.
KDC Realm Admin Password: The password of the administrative user who manages the KDC within a realm.
Select Save to apply the changes.
In From the Kerberos Authentication Type, select MIT.
Set the following parameters to the MIT KDC servers:
KDC Realm Name: Specifies the realm (domain) used by Kerberos.
KDC Primary Server: Identifies the server hosting the primary Key Distribution Center service.
KDC Secondary Server: Identifies the server hosting the secondary Key Distribution Center service.
KDC Admin Server: Identifies the server hosting the administrative Key Distribution Center service.
Set the following parameters to register the Kerberos with LDAP service and uploaded keytab file:
NFS Service Name: This refers to the complete domain name for a specific NFS server.
Upload keytab file: Use the Browse option to upload the pre-generated keytab file. This file contains the keys for the NFS service’s unique identity, known as a principal, in Kerberos.
Select Save to apply the changes.
Type: The access type: RO (read-only) or RW (read/write).
Priority: Permissions are processed in ascending priority order during access evaluation, beginning with the lowest number. If a client matches multiple permission entries, the entry with the highest priority number determines the effective permission. Using a numbering system in tens (10, 20, 100) is advisable to facilitate the addition of priorities between existing ones.
Supported Versions: The supported NFS versions (V3, V4, or both).
User Squash: The system enforces squash mode with the client's permission.
Authentication Types: The method of authentication. The enabled authentication types in the NFS global settings determine the possible options and the default. Examples:
Enabled types: NONE, SYS, KRB5, KRB5i, KRB5p. Default: KRB5.
Enabled types: NONE, SYS. Default: NONE, SYS.
Enabled types: NONE, SYS, KRB5i, KRB5p. Default: KRB5i.
Anon. UID: Anonymous user ID. Only relevant for Root and All user squashing.
Anon. GID: Anonymous group ID. Only relevant for Root and All user squashing.
Select Save.
LDAP Domain: Defines the domain that the Lightweight Directory Access Protocol service will access.
LDAP Reader User Name: The username of an administrative user, used to generate the keytab file.
LDAP Reader User Password: The password of the administrative user.
LDAP Base DN: The base Distinguished Name (DN) for the Lightweight Directory Access Protocol directory tree.
LDAP Port: The port number on which the Lightweight Directory Access Protocol server listens.
This page describes how to configure the NFS networking using the CLI.
Using the CLI, you can:
NFSv4 and Kerberos require a persistent cluster-wide configuration filesystem for the protocol's internal operations.
Use the following command line to set the NFS configuration on the configuration filesystem:
weka nfs global-config set [--mountd-port mountd-port] [--lockmgr-port lockmgr-port] [--statmon-port statmon-port] [--notify-port notify-port] [--config-fs config-fs] [--default-supported-versions default-supported-versions] [--enable-auth-types enable-auth-types]
Parameters
Command: weka nfs global-config show
Example
Command: weka nfs interface-group add
Use the following command line to add an interface group:
weka nfs interface-group add <name> <type> [--subnet subnet] [--gateway gateway]
Example
weka nfs interface-group add nfsw NFS --subnet 255.255.255.0 --gateway 10.0.1.254
Parameters
Commands:
weka nfs interface-group port add
weka nfs interface-group port delete
Use the following command lines to add or delete an interface group port:
weka nfs interface-group port add <name> <container-id> <port>
weka nfs interface-group port delete <name> <container-id> <port>
Example
The following command line adds the interface enp2s0 on the Frontend container-id 3 to the interface group named nfsw.
weka nfs interface-group port add nfsw 3 enp2s0
Parameters
Commands:
weka nfs interface-group ip-range add
weka nfs interface-group ip-range delete
Use the following command lines to add/delete an interface group IP:
weka nfs interface-group ip-range add <name> <ips>
weka nfs interface-group ip-range delete <name> <ips>
Example
The following command line adds IPs in the range 10.0.1.101 to 10.0.1.118 to the interface group named nfsw.
weka nfs interface-group ip-range add nfsw 10.0.1.101-118
Parameters
The mountd service receives requests from clients to mount to the NFS server. It is possible to set it explicitly rather than have it randomly selected on each server startup. This allows an easier setup of the firewalls to allow that port.
Use the following command lines to set and view the mountd configuration:
weka nfs global-config set --mountd-port <mountd-port>
weka nfs global-config show
NFS-W can authenticate more than 16 user groups, but it requires the external resolution of the user's groups, which means associating users with their respective group-IDs outside of the NFS protocol.
Procedure
Configure interface groups:
See .
Configure NFS client permissions:
See .
Integrating the NFS and Kerberos service is critical to setting up a secure network communication process. This procedure involves defining the Key Distribution Center (KDC) details, administrative credentials, and other parameters to ensure a robust and secure authentication process.
Before you begin
Ensure a configuration filesystem is set. See .
Ensure the NFS cluster is configured and running. see .
For Active Directory (AD) integration, obtain the required information from the AD administrator. (WEKA handles the generation of the keytab file.)
For MIT integration, ensure the following:
Command: weka nfs kerberos service setup
Use the following command to set up NFS Kerberos Service information:
weka nfs kerberos service setup <kdc-realm-name> <kdc-primary-server> <kdc-admin-server> [--kdc-secondary-server kdc-secondary-server][--force] [--restart]
Example
Parameters
Command: weka nfs kerberos service show
Example
Integrating Kerberos with AD involves the following:
Command: weka nfs kerberos registration setup-ad
Use the following command to register the Kerberos with Microsoft Active Directory:
weka nfs kerberos registration setup-ad <nfs-service-name> <realm-admin-name> [realm-admin-passwd] [--force] [--restart]
Example
Parameters
Command: weka nfs ldap setup-ad
Use the following command to set up NFS configuration to use AD LDAP:
weka nfs ldap setup-ad [--force] [--no-restart]
Example
Parameters
In a successful operation, the system automatically restarts the NFS containers, leading to a temporary disruption in the IO service for connected NFS clients. However, if you want to avoid restarting the NFS-W containers, add the --no-restart option to the command line.
Integrating Kerberos with MIT involves the following:
Command: weka nfs kerberos registration setup-mit
Use the following command to register the Kerberos with MIT KDC:
weka nfs kerberos registration setup-mit <nfs-service-name> <keytab-file> [--force] [--restart]
Example
Parameters
Command: weka nfs ldap setup-openldap
Use the following command to set up Kerberos to use OpenLDAP:
weka nfs ldap setup-openldap <server-name> <ldap-domain> <reader-user-name>[reader-user-password] [--base-dn base-dn] [--ldap-port-number ldap-port-number][--force] [--no-restart]
Example
Parameters
In a successful operation, the system automatically restarts the NFS containers, leading to a temporary disruption in the IO service for connected NFS clients. However, if you want to avoid restarting the NFS-W containers, add the --no-restart option to the command line.
Command: weka nfs ldap show
Example
Command: weka nfs ldap reset
Use the following command to clear the NFS LDAP configuration:
weka nfs ldap reset [--force] [--no-restart]
Parameters
Command: weka nfs kerberos registration show
Example
Command: weka nfs kerberos reset
Use the following command to clear the NFS Kerberos service configuration:
weka nfs kerberos reset [--force] [--no-restart]
Parameters
In a successful operation, the system automatically restarts the NFS containers, leading to a temporary disruption in the IO service for connected NFS clients. However, if you want to avoid restarting the NFS-W containers, add the --no-restart option to the command line.
Once the Kerberos integration with NFS is configured, there might be instances where the Kerberos setup is modified.
Changes to the Kerberos configuration in a production environment are rare. We recommend making any necessary updates during periods of low load from NFS clients, such as when the system are in maintenance mode. This approach helps to minimize potential disruptions to your operations.
Select the relevant tab to learn what to do for each scenario:
Use this procedure if you want to add or remove a secondary KDC server:
Procedure
Run the command: weka nfs kerberos reset --no-restart --force
Run the command: weka nfs kerberos service setup <options>
Run one of the following commands:
Command: weka nfs client-group
Use the following command lines to add/delete a client access group:
weka nfs client-group add <name>
weka nfs client-group delete <name>
Parameters
Clients are part of groups when their IP address or DNS hostname match the rules of that group. Similar to IP routing rules, clients are matched to client groups according to the most specific matching rule.
Command: weka nfs rules
Use the following command lines to add a rule that causes a client to be part of a client group based on its DNS hostname:
weka nfs rules add dns <name> <dns>
Example
weka nfs rules add dns client-group1 hostname.example.com
Use the following command lines to delete a rule that causes a client to be part of a client group based on its DNS hostname:
weka nfs rules delete dns <name> <dns>
Example
weka nfs rules delete dns client-group1 hostname.example.com
Parameters
Command: weka nfs rules
Use the following command lines to add or delete a rule which causes a client to be part of a client group based on its IP and subnet mask (both CIDR and standard subnet mask formats are supported for enhanced flexibility):
weka nfs rules add ip <name> <ip>
Examples
weka nfs rules add ip client-group1 192.168.114.0/8
weka nfs rules add ip client-group2 172.16.0.0/255.255.0.0
weka nfs rules delete ip <name> <ip>
Examples
weka nfs rules delete ip client-group1 192.168.114.0/255.255.255.0
weka nfs rules delete ip client-group2 172.16.0.0/16
Parameters
Command: weka nfs permission
Use the following command lines to add NFS permissions:
weka nfs permission add <filesystem> <group> [--path path] [--permission-type permission-type] [--squash squash] [--anon-uid anon-uid] [--anon-gid anon-gid] [--obs-direct obs-direct] [--manage-gids manage-gids] [--privileged-port privileged-port] [--supported-versions supported-versions] [--enable-auth-types enable-auth-types]
Use the following command lines to update NFS permissions:
weka nfs permission update <filesystem> <group> [--path path] [--permission-type permission-type] [--squash squash] [--anon-uid anon-uid] [--anon-gid anon-gid] [--obs-direct obs-direct] [--manage-gids manage-gids] [--privileged-port privileged-port] [--supported-versions supported-versions][--enable-auth-types enable-auth-types]
Use the following command lines to delete NFS permissions:
weka nfs permission delete <filesystem> <group> [--path path]
Parameters
Command: weka nfs clients show
Use the following command line to view insights of NFS clients connected to the NFS-W cluster in JSON output format.
weka nfs clients show [--interface-group interface-group] [--container-id container-id] [--fip floating-ip]
Parameters
0
config-fs*
The predefined filesystem name for maintaining the persisting cluster-wide protocols' configurations. Verify that the filesystem is already created. If not, create it. For details, see
default-supported-versions
Determines the default NFS version.
Possible values:
v3
v4
v3,v4
v3
enable-auth-types
A comma-separated list of authentication types that can be used when setting the NFS client permissions.
Possible values: none,sys,krb5,krb5i,krb5p
Example:
krb5,krb5i,krb5p
Depends on Kerberos configuration:
If not configured: none,sys
If configured: krb5
255.255.255.255
Set up servers for group-IDs retrieval:
Configure relevant servers to retrieve user group-IDs information. This task is specific to NFS-W and does not involve WEKA management. See the following procedure.
nssIf you use another method than the sssd but with a different provider, configure an sssd proxy on each relevant server. The proxy is used for the WEKA container to resolve the groups by any method defined on the server.
To configure sssd proxy on a server, use the following:
All users must be present and resolved in the method used in the sssd for the group's resolution. In the above example, using an LDAP-only provider, local users (such as a local root) absent in LDAP do not receive their groups resolved and are denied. For such users or applications, add the LDAP user.
Obtain the required information from the MIT Key Distribution Center (KDC) and OpenLDAP administrators.
A pre-generated keytab file in base64 format stored in an accessible location is required.
force
When used, it forces the action to proceed without further confirmation. Typically used when the service is configured or registered.
Not used
restart
When used, the command restarts the NFS-W containers after the changes are applied.
Not used
Not used
restart
When used, the command restarts the NFS-W containers after the changes are applied.
Not used
Not used
base-dn
The base Distinguished Name (DN) for the Lightweight Directory Access Protocol directory tree.
ldap-port-number
The port number on which the Lightweight Directory Access Protocol server listens.
389
force
When used, it forces the action to proceed without further confirmation. Typically used when the service is configured or registered.
Not used
no-restart
When used, it prevents NFS-W containers from restarting to apply changes.
Not used
For AD implementation: weka nfs kerberos registration setup-ad <options> --restart
For MIT implementation: weka nfs kerberos registration setup-mit <options> --restart
Use this procedure if one of the following is changed:
Procedure
Run the command:
weka nfs kerberos registration setup-ad --restart --force
Use this procedure if one of the following is changed:
Procedure
Run the command:
weka nfs kerberos registration setup-mit <options> --restart --force
Use this procedure if one of the following is changed:
Procedure
For AD implementation, run the following:
weka nfs ldap reset --no-restart --force
weka nfs ldap <setup-ldap> <options/params>
For MIT implementation, run the following:
weka nfs ldap reset --no-restart --force
weka nfs ldap <setup-openldap> <options/params>
Permission type.
Possible values: ro (read-only), rw (read-write)
rw
squash
Squashing type.
Possible values: none, root, all
none
anon-uid*
Anonymous user ID.
Relevant only for root squashing.
Possible values: 1 to 65535.
65534
anon-gid*
Anonymous user group ID.
Relevant only for root squashing.
Possible values: 1 to 65535.
65534
obs-direct
See .
Possible values: on, off.
on
manage-gids
Sets external group IDs resolution.
The list of group IDs received from the client is replaced by a list determined by an appropriate lookup on the server.
Possible values: on, off.
off
privileged-port
Sets the share only to be mounted via privileged ports (1-1024), usually allowed by the root user.
Possible values: on, off.
off
supported-versions
A comma-separated list of supported NFS versions.
Possible values: v3, v4.
The default-supported-versions setting in determines the default NFS version.
enable-auth-types
A comma-separated list of NFS authentication types.
Possible values are determined by the enable-auth-types in .
The default-auth-types in NFS global settings determine the default.
mountd-port
Set the alternate port if the existing mountd service is not operating on the default published port. 0 means use the default published port.
0
lockmgr-port
Set the alternate port for the NFS lock manager used in NFSv3.
0 means use the default published port.
0
statmon-port
Set the alternate port for the NFS status monitor used in NFSv3. 0 means use the default published port.
0
notify-port
name*
Unique interface group name.
type*
Group type.
Can only be NFS.
subnet
The valid subnet mask in the 255.255.0.0 format.
255.255.255.255
gateway
name*
Interface group name.
container-id*
Valid frontend container ID on which the port resides. You can obtain the container ID by running the weka cluster container command.
port*
Valid port's device. Maximum 14 characters.
Example: eth1.
name*
Interface group name
ips*
Valid IP range
kdc-realm-name*
Specifies the realm (domain) used by Kerberos.
kdc-primary-server*
Identifies the server hosting the primary Key Distribution Center service.
kdc-admin-server*
Identifies the server hosting the administrative Key Distribution Center service.
kdc-secondary-server
nfs-service-name*
This refers to the complete domain name for a specific NFS server.
realm-admin-name*
The username of an administrator who has access to the LDAP directory. This user manages the KDC within a realm.
realm-admin-passwd
This parameter is for the password of the administrative user who manages the KDC within a realm. It’s not stored in the configuration for security reasons. If it’s not provided during setup, the system asks for it. The entered password isn’t shown on the screen to protect privacy and security.
force
force
When used, it forces the action to proceed without further confirmation. Typically used when the service is configured or registered.
Not used
no-restart
When used, it prevents NFS-W containers from restarting to apply changes.
Not used
nfs-service-name*
Fully Qualified Domain Name (FQDN) for the NFS Service. This refers to the complete domain name for a specific NFS server. The hostname part of the FQDN is restricted to a maximum of 20 characters.
keytab-file*
The path to the pre-generated keytab file containing the keys for the NFS service’s unique identity in base64 format.
force
When used, it forces the action to proceed without further confirmation. Typically used when the service is configured.
Not used
restart
server-name*
Specifies the server hosting the Lightweight Directory Access Protocol service.
ldap-domain*
Defines the domain the Lightweight Directory Access Protocol service will access.
reader-user-name*
The username of an administrative user used to generate the keytab file.
reader-user-password
force
When used, it forces the action to proceed without further confirmation. Typically used when the service is configured.
Not used
no-restart
When used, it prevents NFS-W containers from restarting to apply changes.
Not used
force
When used, it forces the action to proceed without further confirmation. Typically used when the service is configured or registered.
Use this flag only to clear the configuration created by a previous call to weka nfs kerberos service setup succeeded.
Not used
no-restart
When used, it prevents NFS-W containers from restarting to apply changes.
Not used
name*
Valid group name.
name*
Valid client group name.
dns*
DNS rule with *?[] wildcard rules.
name*
Valid client group name.
ip*
Valid IP address with subnet mask.
Both CIDR and standard subnet mask formats are supported for enhanced flexibility.
CIDR format: 1.1.1.1/16
Standard format: 1.1.1.1/255.255.0.0
filesystem*
Existing filesystem name. A filesystem with Required Authentication set to ON cannot be used for NFS client permissions.
group*
Existing client group name.
path
The root of the valid share path.
/
interface-group
Interface group name. A filter to show only the clients connected to the containers in the specified group.
The output shows all clients connected to any container in the NFS-W cluster regardless of the assigned interface group.
container-id
NFS-W container ID.
A filter to show only the clients connected to the specified container ID.
The output shows all clients connected to any container in the NFS-W cluster.
fip
Destination floating IP address.
The output shows all clients connected to all floating IP addresses.
Set the alternate port for notification used in NFSv3. 0 means use the default published port.
Gateway valid IP.
Identifies the server hosting the secondary Key Distribution Center service.
When used, it forces the action to proceed without further confirmation. Typically used when the service is configured or registered.
When used, the command restarts the NFS-W containers after the changes are applied.
The administrative user's password. (It is maintained in a configuration file.)
permission-type
realm-admin-name
realm-admin-passwdkeytab-filereader-user-name
reader-user-password$ weka nfs global-config show
NFS Global Configuration
mountd port: 0
Config FS: .config_fs
Default Supported Versions: V3
Enabled Auth Types: KRB5, KRB5i, KRB5p
Default Auth Types: KRB5
Supported Auth Types: NONE, SYS, KRB5, KRB5i, KRB5pweka nfs kerberos service setup WEKA-REALM kdc.primary.weka.io kdc.admin.weka.io --kdc-secondary-server kdc.secondary.weka.io$ weka nfs kerberos service show
REALM NAME PRIMARY SERVER SECONDARY SERVER ADMIN SERVER GENERATION ID SERVICE STATUS
TEST.WEKALAB.IO Zeus.test.wekalab.io Zeus.test.wekalab.io 1 CONFIGUREDweka nfs kerberos registration setup-ad myservicename.test.example.com myrealmadminweka nfs ldap setup-adweka nfs kerberos registration setup-mit myservicename.test.example.com myservicename.keytabweka nfs ldap setup-openldap myldapserver.test.example.com, myldapdomain.example.com, cn=readonly-user,dc=test,dc=example,dc=com$ weka nfs ldap show
SERVER TYPE LDAP DOMAIN SERVER NAME SERVER PORT BASE DN READER NAME READER PASSWORD GENERATION ID SETUP STATUS
ActiveDirectory test.wekalab.io 0 1 CONFIGURED$ weka nfs kerberos registration show
NFS SERVICE NAME NFS KDC TYPE GENERATION ID REGISTRATION STATUS
nfs.test.wekalab.io ActiveDirectory 1 REGISTEREDkdc-secondary-server[sssd]
services = nss
config_file_version = 2
domains = LDAP
[domain/LDAP]
id_provider = ldap
ldap_uri = ldap://ldap.example.com
ldap_search_base = dc=example,dc=com
# The DN used to search the ldap directory with.
ldap_default_bind_dn = cn=ro_admin,ou=groups,dc=example,dc=com
# The password of the bind DN.
ldap_default_authtok = password
# install sssd
yum install sssd
# set up a proxy for WEKA in /etc/sssd/sssd.conf
[sssd]
services = nss
config_file_version = 2
domains = proxy_for_weka
[nss]
[domain/proxy_for_weka]
id_provider = proxy
auth_provider = none
# the name of the nss lib to be proxied, e.g., ldap, nis, winbind, vas4, etc.
proxy_lib_name = ldap