173 lines
5.9 KiB
Markdown
173 lines
5.9 KiB
Markdown
# 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](windows_drives_in_home)
|
|
- [Central Storage Mount](central_storage_mount)
|
|
- [autofs](autofs)
|
|
- [AFS](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](../basic/gssproxy_with_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](../basic/gssproxy_with_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.
|