A OneFS network group, or netgroup, defines a network-wide group of hosts and users. As such, they can be used to restrict access to shared NFS filesystems, etc. Network groups are stored in a network information services, such as LDAP, NIS, or NIS+, rather than in a local file. Netgroups help to simplify the identification and management of people and machines for access control.
The isi_netgroup_d service provides netgroup lookups and caching for consumers of the ‘isi_nfs’ library. Only mountd and the ‘isi nfs’ command-line interface use this service. The isi_netgroup_d daemon maintains a fast, persistent cluster-coherent cache containing netgroups and netgroup members. isi_netgroup_d enforces netgroup TTLs and netgroup retries. A persistent cache database (SQLite) exists to store and recover cache data across reboots. Communication with isi_netgroup_d is via RPC and it will register its service and port with the local rpcbind.
Within OneFS, the netgroup cache possesses the following gconfig configuration parameters:
# isi_gconfig -t nfs-config | grep cache shared_config.bypass_netgroup_cache_daemon (bool) = false netcache_config.nc_ng_expiration (uint32) = 3600000 netcache_config.nc_ng_lifetime (uint32) = 604800 netcache_config.nc_ng_retry_wait (uint32) = 30000 netcache_config.ncdb_busy_timeout (uint32) = 900000 netcache_config.ncdb_write (uint32) = 43200000 netcache_config.nc_max_hosts (uint32) = 200000
Similarly, the following files are used by the isi_netgroup_d daemon:
File | Purpose |
/var/run/isi_netgroup_d.pid | The pid of the currently running isi_netgroup_d |
/ifs/.ifs/modules/nfs/nfs_config.gc | Server configuration file |
/ifs/.ifs/modules/nfs/netcache.db | Persistent cache database |
/var/log/isi_netgroup_d.log | Log output file |
In general, using IP addresses works better than hostnames for netgroups. This is because hostnames require a DNS lookup and resolution from FQDN to IP address. Using IP addresses directly saves this overhead.
Resolving a large set of hosts in the allow/deny list is significantly faster when using netgroups. Entering a large host list in the NFS export means OneFS has to look up the hosts for each individual NFS export. In Netgroups, once looked up, it is cached by netgroups, so it doesn’t have to be looked up again if there are overlap between exports. It is also better to use an LDAP (or NIS) server when using Netgroups instead of the flat file. If you have a large list of hosts in the netgroups file, it can take a while to resolve as it is single threaded and sequential. LDAP/NIS provider based netgroups lookup is parallelized.
The OneFS netgroup cache has a default limit in gconfig of 200,000 host entries.
# isi_gconfig -t nfs-config | grep max netcache_config.nc_max_hosts (uint32) = 200000
So what is the waiting period between when /etc/netgroup is updated to when the NFS export realizes the change? OneFS uses a netgroup cache and both its expiration and lifetime are both tunable. The netgroup expiration and lifetime can be configured with this following CLI command:
# isi nfs netgroup modify --expiration or -e <duration> Set the netgroup expiration time. --lifetime or -l <duration> Set the netgroup lifetime.
OneFS also provides the ‘isi nfs netgroups flush’ CLI command, which can be used to force a reload of the file.
# isi nfs netgroup flush [--host <string>] [{--verbose | -v}] [{--help | -h}] Options: --host <string> IP address of the node to flush. Defaults is all nodes. Display Options: --verbose | -v Display more detailed information. --help | -h Display help for this command.
However, it is not recommended to flush the cache as a part of normal cluster operation. Refresh will walk the file and update the cache as needed.
Another area of caution is applying a netgroup with unresolved hostname(s). This will also slow down resolution of the hosts in the file when a refresh or startup of node happens. The best practice is to ensure that each host in the netgroups file is resolvable in DNS, or to just use IP addresses rather than names in the netgroup.
When it come to switching to a netgroup for clients already on an export, a netgroup can be added and clients removed in one step (#1 –add-client netgroup –remove-clients 1,2,3,etc). The cluster allows a mix of netgroup and host entries, so duplicates are tolerated. However, it’s worth noting that if there are unresolvable hosts in both areas, the startup resolution time will take that much longer.