gitea-pages/admin-guide/configuration/mount.md

Mounting Volumes

Managing mount points of local or network volumes can also be managed in Hiera.

Managing Mountpoints in Hiera

The configuration in Hiera is done with two parts:

1. the definition of a mountpoint (mounter::def::$NAME)
2. the list of mount points actually configured on a system (mounter::mounts)

Due to this the mountpoints can be prepared once on a high scope (e.g. for all systems in an environment), but then the individual systems pick out whatever is required for them.

Example:

mounter::def::scratch:
  ensure: 'mounted'
  mountpoint: '/scratch'
  device: '/dev/vg_data/lv_scratch'
  type: 'xfs'

mounter::mounts:
  - 'scratch'

The directory of the mountpoint is automatically created when missing.

For auto-mounts, add another option to the mountpoint definition:

  auto: true

NFS

Remote NFS mountpoints can be defined as in following example:

mounter::def::data1:
  'ensure': 'mounted'
  'device': 'x01dc-fs-1:/export/X01DC/Data1'
  'mountpoint': '/sls/X01DC/Data1'
  'type': 'nfs'
  'options': 'nfsvers=4.2,sec=krb5'

mounter::def::controls:
  'ensure': 'mounted'
  'device': 'sls-hafs:/export/sls/controls'
  'mountpoint': '/gfa/.mounts/sls_controls'
  'type': 'nfs'

mounter::mounts:
  - 'data1'
  - 'controls'

Ideally use NFSv4 (option nfsvers=4.2) and Kerberos authentication (option sec=krb5) is used. For Kerberos please contact the Linux Core Group for support. We managed to get it running experimentally, but it might not run yet automatically from Puppet. And of course also the NetApp side needs to be prepared accordingly.

Following options are possible for sec:

• sys client enforces access control (default on NFS3)
• krb5 server enforces access control, client user authenticates with Kerberos
• krb5i server enforces access control, client user authenticates with Kerberos and traffic is integrity checked
• krb5p server enforces access control, client user authenticates with Kerberos and traffic is fully encrypted

NFS and Kerberos also needs ID mapping, which is automatically configured to the default domain psi.ch. Should a different domain be required, you may set it with Hiera:

nfs_idmap::domain: 'ethz.ch'

CIFS

CIFS with Multiuser Option and Kerberos

Mounting a CIFS share with the multiuser option and Kerberos has the advantage that no password is needed and each user gets personal access rights checked on the server side. But she/he needs to have, similar to AFS, an appropriate Kerberos ticket. Additionally the option cifsacl is required for showing the proper file owner.

mounter::def::scratch:
  ensure: 'mounted'
  device: '//scratch01.psi.ch/scratch'
  mountpoint: '/media/scratch'
  type: 'cifs'
  options: 'multiuser,sec=krb5,cifsacl'

mounter::mounts:
  - 'scratch'

For shares on NetApp (fs00.psi.ch until fs03.psi.ch) you can mount the data folder which contains all shares on this server:

mounter::def::fs00:
  ensure: 'mounted'
  device: '//fs00.psi.ch/data'
  mountpoint: '/cifs/fs00'
  type: 'cifs'
  options: 'multiuser,sec=krb5,cifsacl'

mounter::mounts:
  - 'fs00'

This only works if everybody has read access to the share itself, but that is not needed for subfolders. Else you need a password as below or a keytab (here feel free to ask the Linux Group for support).

CIFS with User and Password

Remote CIFS mountpoints can be defined as follows:

mounter::cifs::def::cifs_mpc2375:
  ensure: 'present'
  path: '/etc/cifs-utils'
  cifs_username: 'allowedWindowsUser'
  cifs_password: 'ENC[PKCS7,MIIBeQYJKoZIhvc...]'

mounter::cifs::files: 
  - 'cifs_mpc2375'

mounter::def::emf: 
  ensure: 'mounted'
  device: '//172.23.75.16/Users'
  mountpoint: '/emf/jeol2200fs/k2'
  type: 'cifs'
  options: 'credentials=/etc/cifs-utils/cifs_mpc2375,uid=35667,gid=35270,forcegid,file_mode=0660,dir_mode=0770'

mounter::mounts: 
  - 'emf'

In the above example, we need to create a credentials file with mounter::cifs::def::$NAME_. This file will be called cifs_mpc2375 and will be located in /etc/cifs-utils and will contain information about the username and password allowed to mount it.

On the other hand, a mount emf with type cifs is defined. You should specify in options the location of credentials as well as optional parameters.

AFS

AFS is depending on role already configured by default. Additionally it can be enabled or disabled in Hiera with base::enable_afs:

base::enable_afs: true

respectively to disable:

base::enable_afs: false

Following details can be modified, but are usually not required:

• afs_client::mountpoint
• afs_client::root_volume
• afs_client::enable_dynroot
• afs_client::min_cache_size (e.g. 8G)
• afs_client::files
• afs_client::dcache

When disabling AFS the daemon is not automatically switched off. There is additional manual effort required on the host:

systemctl disable yfs-client.service
reboot

If you want to do it without reboot, first stop all processes using AFS. You might figure them out e.g. with lsof | grep /afs.

Then do

umount /afs
systemctl stop yfs-client.service
systemctl disable yfs-client.service
afsd -shutdown

Bind Mounts

Bind mounts can be defined as follows:

mounter::def::e10550:
  'ensure': 'mounted'
  'device': '/gpfs/perf/MX/Data10-pro/e10550'
  'mountpoint': '/sls/MX/Data10/e10550'
  'type': 'none'
  'options': 'bind,_netdev,x-systemd.requires-mounts-for=/gpfs/perf/MX/Data10-pro'

Note that beside the mandatory bind option there is

• _netdev to be set when the directory to bind (device) is on a network volume
• x-systemd.requires-mounts-for=$OTHER_MOUNTPOINT ensures that systemd prepares the bind mount after the volume on which the directory to bind (device) is located

Removing a Mount

Only removing a mount point definition from Hiera does not unmount and remove it from the node. This can then be done manually by unmounting it and removing it from /etc/fstab.

Alternatively an absent mount defintion as in below example will automatically unmount and remove the mount /etc/fstab entry:

mounter::def::scratch:
  ensure: 'absent'
  mountpoint: '/media/scratch'

mounter::mounts:
  - 'scratch'

This configuration can then be removed again after it has been rolled out once to all concernded nodes.