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

Mounting Volumes

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

For more automatic network data setups please look at

• Windows Drives in Home Directory
• Central Storage Mount
• autofs
• AFS

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. 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'

Checkout Permanent Kerberos with gssproxy and Password Keytab if you want to access a Kerberos protected share, e.g. with background processes without having to type passwords (kinit) regularly.

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).

Checkout Permanent Kerberos with gssproxy and Password Keytab if you want to access a Kerberos protected share, e.g. with background processes without having to type passwords (kinit) regularly.

CIFS with User and Password

Remote CIFS mountpoints can be defined as follows:

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'
  cifs:
    cifs_mpc2375:
      username: 'allowedWindowsUser'
      password: 'ENC[PKCS7,MIIBeQYJKoZIhvc...]'

mounter::mounts: 
  - 'emf'

In the above example, we need to create a credentials file with the content below the cifs -> $NAME parameter. This file will be called like the key below cifs and will be located in /etc/cifs-utils and will contain information about the username and password allowed to mount it. To be used the file needs to be referenced as credentials= in the mount options.

Systemd Automount

Adding the options noauto,x-systemd.automount will make the mount not happen on startup, but will be automounted on the first use of the mountpoint.

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.