forked from Controls/gitea-pages
rename infrastructure-guide to engineering guide
This commit is contained in:
Binary file not shown.
|
After Width: | Height: | Size: 1.9 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 132 KiB |
@@ -0,0 +1,82 @@
|
||||
@startuml
|
||||
|
||||
actor admin
|
||||
participant "BIOS Node\n(legacy boot)" as bootnode
|
||||
participant "QIP DHCP" as dhcp
|
||||
participant "boot.psi.ch" as pxeserver
|
||||
participant "sysdb.psi.ch" as sysdb
|
||||
participant "repos.psi.ch" as reposerver
|
||||
|
||||
admin -> bootnode : boots up
|
||||
|
||||
hnote over bootnode
|
||||
BIOS
|
||||
endhnote
|
||||
bootnode -> dhcp : DHCP request
|
||||
dhcp -> bootnode : IP + PXE boot location
|
||||
bootnode -> pxeserver : load PXE kernel tftp:/tftpboot/pxelinux.0
|
||||
|
||||
hnote over bootnode
|
||||
PXE
|
||||
endhnote
|
||||
bootnode -> pxeserver : load PXE config tftp:/tftpboot/pxelinux.cfg/01-$MAC
|
||||
note right
|
||||
By manually setting a MAC or IP config the
|
||||
boot menu can be customised or shortcut.
|
||||
Most is managed by symlinks. There is the
|
||||
undocumented "link-to-lxprod.py" script for
|
||||
manually linking MAC to hostname and hostname
|
||||
to "lxprod". At some places this is done the
|
||||
opposite by linking hostname to MAC to "lxprod".
|
||||
Having the **link to "lxprod" loads directly**
|
||||
**the iPXE kernel "ipxe.lkrn"**, shortcutting
|
||||
the manual selection below.
|
||||
end note
|
||||
bootnode -> pxeserver : load PXE config tftp:/tftpboot/pxelinux.cfg/$HEX-IP
|
||||
bootnode -> pxeserver : load PXE config tftp:/tftpboot/pxelinux.cfg/default
|
||||
note right
|
||||
**Default selection is local boot**,
|
||||
but also visible and manually selectable are
|
||||
- Red Hat 7 Network Install
|
||||
- Windows Network install
|
||||
and many more which are hidden, but can
|
||||
be selected from the prompt, some with
|
||||
comments from 2013.
|
||||
end note
|
||||
admin -> bootnode : selects "Red Hat 7 Network Install"
|
||||
bootnode -> pxeserver : load iPXE kernel tftp:/tftpboot/ipxe.lkrn
|
||||
note right
|
||||
https://git.psi.ch/linux-infra/ipxe-build
|
||||
The following steps are by embed/pxe.ipxe
|
||||
end note
|
||||
|
||||
hnote over bootnode
|
||||
iPXE
|
||||
endhnote
|
||||
bootnode -> dhcp : DHCP request
|
||||
dhcp -> bootnode : IP
|
||||
bootnode -> sysdb : load iPXE menu http:/ipxe/v1/config?mac=$MAC
|
||||
note right
|
||||
Default selection by sydb boot
|
||||
property "local" or "netboot",
|
||||
later automatically starts the
|
||||
installer configured in sysdb
|
||||
attribute "ipxe_installer".
|
||||
Manually selectable are all
|
||||
Red Hat 7 versions and Red Hat 8
|
||||
alpha test version to install,
|
||||
Windows, a selection of tools
|
||||
and "HP SPP".
|
||||
endnote
|
||||
bootnode -> reposerver : load initrd http:/iso/rhel-server-7.9-x86_64-dvd/images/pxeboot/initrd.img
|
||||
bootnode -> reposerver : load kernel http:/iso/rhel-server-7.9-x86_64-dvd/images/pxeboot/vmlinuz
|
||||
|
||||
hnote over bootnode
|
||||
Linux kernel
|
||||
endhnote
|
||||
bootnode -> reposerver : installation media http:/iso/rhel-server-7.9-x86_64-dvd/
|
||||
bootnode -> sysdb : kickstart file http:/kickstart/v1/config?fqdn=$HOSTNAME&instrepo=rhel-server-7.9-x86_64-dvd
|
||||
|
||||
@enduml
|
||||
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 130 KiB |
@@ -0,0 +1,88 @@
|
||||
@startuml
|
||||
|
||||
actor admin
|
||||
participant "UEFI Node" as bootnode
|
||||
participant "QIP DHCP" as dhcp
|
||||
participant "boot.psi.ch" as pxeserver
|
||||
participant "sysdb.psi.ch" as sysdb
|
||||
participant "repos.psi.ch" as reposerver
|
||||
|
||||
admin -> bootnode : boots up
|
||||
|
||||
hnote over bootnode
|
||||
EFI
|
||||
endhnote
|
||||
bootnode -> dhcp : DHCP request
|
||||
dhcp -> bootnode : IP + PXE boot location
|
||||
bootnode -> pxeserver : load PXE kernel tftp:/tftpboot/shimx64.efi
|
||||
bootnode -> pxeserver : load PXE kernel tftp:/tftpboot/grubx64.efi
|
||||
|
||||
|
||||
hnote over bootnode
|
||||
GRUB
|
||||
endhnote
|
||||
bootnode -> pxeserver : load PXE config tftp:/tftpboot/grub.cfg-01-$MAC
|
||||
note right
|
||||
By manually setting a MAC or IP config the
|
||||
boot menu can be customised or shortcut.
|
||||
end note
|
||||
bootnode -> pxeserver : load PXE config tftp:/tftpboot/grub.cfg-$HEX-IP
|
||||
bootnode -> pxeserver : load PXE config tftp:/tftpboot/grub.cfg
|
||||
bootnode -> sysdb : load GRUB menu http:/grub/v1/config?mac=$MAC
|
||||
note right
|
||||
Default selection by sydb boot
|
||||
property "local" or "netboot",
|
||||
later automatically starts the
|
||||
installer configured in sysdb
|
||||
attribute "ipxe_installer".
|
||||
Manually selectable are other
|
||||
version of RHEL 7 and
|
||||
"Windows and Tools Menus".
|
||||
endnote
|
||||
|
||||
admin -> bootnode : selects "Windows and Tools Menus"
|
||||
note left
|
||||
Now the automatic installation kicks in,
|
||||
but here we show the manual detour over iPXE.
|
||||
end note
|
||||
|
||||
bootnode -> pxeserver : load iPXE kernel tftp:/tftpboot/ipxe.efi
|
||||
note right
|
||||
https://git.psi.ch/linux-infra/ipxe-build
|
||||
The following steps are by embed/pxe.ipxe
|
||||
end note
|
||||
|
||||
hnote over bootnode
|
||||
iPXE
|
||||
endhnote
|
||||
bootnode -> dhcp : DHCP request
|
||||
dhcp -> bootnode : IP
|
||||
bootnode -> sysdb : load iPXE menu http:/ipxe/v1/config?mac=$MAC
|
||||
note right
|
||||
Default selection by sydb boot
|
||||
property "local" or "netboot",
|
||||
later automatically starts the
|
||||
installer configured in sysdb
|
||||
attribute "ipxe_installer".
|
||||
Manually selectable are all
|
||||
Red Hat 7 versions and Red Hat 8
|
||||
alpha test version to install,
|
||||
Windows, a selection of tools
|
||||
and "HP SPP".
|
||||
endnote
|
||||
bootnode -> reposerver : load initrd http:/iso/rhel-server-7.9-x86_64-dvd/images/pxeboot/initrd.img
|
||||
note left
|
||||
Automatic installation in GRUB
|
||||
directly jumps here without iPXE
|
||||
end note
|
||||
bootnode -> reposerver : load kernel http:/iso/rhel-server-7.9-x86_64-dvd/images/pxeboot/vmlinuz
|
||||
|
||||
hnote over bootnode
|
||||
Linux kernel
|
||||
endhnote
|
||||
bootnode -> reposerver : installation media http:/iso/rhel-server-7.9-x86_64-dvd/
|
||||
bootnode -> sysdb : kickstart file http:/kickstart/v1/config?fqdn=$HOSTNAME&instrepo=rhel-server-7.9-x86_64-dvd
|
||||
|
||||
@enduml
|
||||
|
||||
|
||||
@@ -0,0 +1,9 @@
|
||||
# Boot Server
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
To troubleshoot the tftp server / tftp queries check the tftpserver logs as follows:
|
||||
|
||||
```bash
|
||||
journalctl -u tftp.service
|
||||
```
|
||||
@@ -0,0 +1,90 @@
|
||||
# Custom RPM Repositories
|
||||
|
||||
It is possible to manage own RPM repositories which are accessible inside PSI.
|
||||
If you need one please contact the Linux Core team (linux-eng@psi.ch).
|
||||
|
||||
|
||||
To setup the your custom repository/ies we need following information:
|
||||
- Name of the repository
|
||||
- Do you want to have your repository available for __all__ RHEL major versions (i.e. all RHEL major versions will see the same packages) or do you need a repository for each RHEL major version (i.e. you can have different packages for each RHEL major version)?
|
||||
|
||||
## Usage
|
||||
|
||||
On `lxsup.psi.ch` you can easily access this data on `/packages_misc`.
|
||||
|
||||
|
||||
The backend for these custom repos is on a NFS4 share. This share can be mounted from __lx-fs:/packages_misc__
|
||||
|
||||
On __Linux__ systems you should be able to mount the share like this
|
||||
```bash
|
||||
mount -t nfs4 -o sec=krb5 lx-fs.psi.ch:/packages_misc /mnt
|
||||
```
|
||||
|
||||
On __MacOS__ you could mount and access the share like this:
|
||||
```bash
|
||||
mount_nfs -o sec=krb5,nfsvers=4 lx-fs.psi.ch:/packages_misc ~/some_directory
|
||||
```
|
||||
|
||||
(on __Windows__ - it should be/is also possible with Windows >=10 to mount the NFS4 share- https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/mount - details to be added here)
|
||||
|
||||
|
||||
Once your folder/folders is/are created and your are autorized to write into these folders you can place RPMs and files into that directory/directories
|
||||
|
||||
__Important__: Once mounted, to be able to change things on the filesystem you have to have a valid kerberosticket for your PSI user.
|
||||
```
|
||||
kinit <username>@D.PSI.CH
|
||||
# or on standard PSI linux systems
|
||||
kinit
|
||||
```
|
||||
|
||||
|
||||
|
||||
## Overview
|
||||
Custom repositories are provided by the central repository server as all other repositories. They will be available on the URL
|
||||
|
||||
```
|
||||
https://repos.psi.ch/<os>/latest/<repository_name>
|
||||
```
|
||||
|
||||
The custom repositories are snapshotted and tagged as any other repository.
|
||||
|
||||
Inside __hiera__ please use the URL:
|
||||
```
|
||||
https://$lx_reposerver/<os>/latest/<repository_name>
|
||||
```
|
||||
This ensures that the systems will always use the correct repository server url to access the repositories. (e.g. in the DMZ/extranet the DNS hostname of the repository is different ...)
|
||||
|
||||
|
||||
The content of the custom repositories are managed on a a dedicated NFS4 share. On this share groups can have different folders where they place/manage their rpms. These RPMs are periodically synced to the main repository share (i.e. every 15 minutes), so what you see on the `packages_misc` is not exactly what will end up on the repository server. Upon sync the repository will be automatically build via the create-repo command.
|
||||
|
||||
The structure of the share is usually as follows:
|
||||
|
||||
```
|
||||
<base>/<repository name>
|
||||
# content in the case of one repo for all major RHEL version
|
||||
/rhel7
|
||||
/rhel8
|
||||
/rhle9 # in case of different repo for major RHEL version
|
||||
```
|
||||
|
||||
The access control is done by a Unix group usually named `unx-<something>_adm` (most of the time this is a group that also gives access to hiera repos)
|
||||
|
||||
|
||||
## Preparation for new Custom RPM Repository
|
||||
|
||||
The packages_misc share is only root writeable from lx-sync-01.psi.ch. Therefore the initial setup needs to be done there.
|
||||
|
||||
Creation of a new repo (on lx-sync-01 in /packages_misc):
|
||||
```
|
||||
cd /packages_misc
|
||||
mkdir <reponame>
|
||||
chgrp 35588 <reponame> ## We need to use the numeric group id here as lx-sync is not directly connected to AD
|
||||
chmod g+w <reponame>
|
||||
chmod g+s <reponame>
|
||||
```
|
||||
|
||||
To sync the repo and make it available there needs to be a sync config added to https://git.psi.ch/linux-infra/rpm-repo-utils/-/tree/main/etc?ref_type=heads
|
||||
(inside the __*-misc__ directories)
|
||||
|
||||
After adding this config the changes need to be deployed on lx-sync-01.psi.ch.
|
||||
(either bootstrap/ansible or a manual `git pull` in `/opt/rpm-repo-utils/`)
|
||||
@@ -0,0 +1,138 @@
|
||||
# Icinga2
|
||||
|
||||
We want to support monitoring of the Linux machines in Icinga2. The Icinga2 infrastructure as such is maintained by AIT, currently mainly Heinz Scheffler, with Bernard Bumbak as deputy.
|
||||
|
||||
## Icinga2 Servers
|
||||
|
||||
- PROD [monitoring.psi.ch](https://monitoring.psi.ch/) (Loadbalancer)
|
||||
- Primary [vemonma01a.psi.ch](https://vemonma01a.psi.ch/) (with Icinga Director)
|
||||
- Secondary [wmonma01b.psi.ch](https://wmonma01b.psi.ch/)
|
||||
|
||||
- DEV
|
||||
- Primary [vmonma02a.psi.ch](https://vmonma02a.psi.ch/) (with Icinga Director)
|
||||
- Secondary [vmonma02b.psi.ch](https://vmonma02b.psi.ch/)
|
||||
|
||||
|
||||
## Automated Host Configuration
|
||||
|
||||
The Linux part of the Icinga2 Master configuration is manged using Ansible in the [`icinga_master` role in the `bootstrap` repo](https://git.psi.ch/linux-infra/bootstrap/-/tree/prod/ansible/roles/icinga_master).
|
||||
|
||||
For Puppet managed nodes there is an automated import pipeline using the Icinga Director. For the central infrastructure itself there is a predefined Configuration Basket snapshot which is installed by manual Ansible run.
|
||||
|
||||
Configuration which is shared and used by both type of systems are found in the [`awi-lx-basic` Configuration Basket](https://git.psi.ch/linux-infra/bootstrap/-/blob/prod/ansible/roles/icinga_master/files/etc/icingaweb2/psi/lx-core/Director-Basket_awi-lx-basic.json)
|
||||
|
||||
### Puppet Managed Nodes
|
||||
|
||||
The individual host configuration is automatically generated using already known information from
|
||||
- Sysdb (inventory of nodes)
|
||||
- Hiera (configuration and customization of the nodes)
|
||||
- Puppet Facts (OS version, attached networks, partitions)
|
||||
- NetOps (security levels of networks, needed for selecting the correct Icinga2 Satellite)
|
||||
|
||||
|
||||
|
||||
#### Import of Hiera Data to Sysdb
|
||||
|
||||
TODO
|
||||
|
||||
#### Import of Puppet Facts to Sysdb
|
||||
|
||||
TODO
|
||||
|
||||
#### Import of NetOps Data
|
||||
|
||||
TODO
|
||||
|
||||
#### Import into Director
|
||||
What in the overview diagram is one arrow, is a bit more complicated when implemented:
|
||||
|
||||
|
||||
|
||||
It contains two parts:
|
||||
- the import of host information (a bit simpler)
|
||||
- the import of notification users (a bit more complex).
|
||||
|
||||
The import as such is triggered every 10 minutes by the `sysdb-director-import` timer.
|
||||
|
||||
To avoid interference with manual Director change operations the import script checks first if there are no undeployed objects. If so it it will not run.
|
||||
|
||||
A Director import pipeline needs first a Import Source which imports the data from an external source. The second element is the Sync Rule which then creates actual Director objects out of the data provided by one or more Import Sources
|
||||
|
||||
##### Director Import of Host Information
|
||||
|
||||
The Icinga Director import pipeline is provides as [Configuration Basket template `awi-lx-sysdb`](https://git.psi.ch/linux-infra/bootstrap/-/blob/prod/ansible/roles/icinga_master/templates/Director-Basket_awi-lx-sysdb.json).
|
||||
|
||||
The pipeline for host groups imports the list of sysdb host groups and the filter to select the hosts where the group name is listed in the `host.vars.host_groups` array of the host.
|
||||
|
||||
The host import contains all the special configuration for a host. But there we need two sync rules, where `awi-lx-sysdb-host-sync-rule` creates and fills the host object.
|
||||
|
||||
The second `awi-lx-sysdb-service-override-sync-rule` just fills `host.vars._override_servicevars` which the Director does not touch in the normal import.
|
||||
The reason is that this variable stores usually manual serice override changes made in Director, an those should survive normal imports. But as we also manage these in Hiera, we need a `Update only` sync rule which allows also to set this variable.
|
||||
|
||||
##### Director Import of Notification Users
|
||||
Here the actual user information comes from the AD. But as we do not import all users, but only those who want to be notified, we also need to modify what is being imported.
|
||||
|
||||
An LDAP filter selects these users specificly. The filter has three sections:
|
||||
- users we do not want (service users, etc)
|
||||
- departments we want
|
||||
- notification users for Linux machines
|
||||
|
||||
The LDAP filter is created on one side out of `ignore_list.conf` and `department_list.conf` which are managed by AIT/Icinga2 Team. The second part is read from the Sysdb API (`user_list.conf`). Together the Configuration Basket `Director-Basket_icinga-notification-user-import.json` which contains the full notification user import pipeline (import source `icinga-notification-user-import` and sync rule `icinga-notification-user-sync-rule` which also get updated always on an import run, before they are then actually triggered.
|
||||
|
||||
### Ansible Managed Central Infrastructure (e.g. Puppet Server)
|
||||
TODO
|
||||
|
||||
## Development of Icinga Director Import Pipeline
|
||||
|
||||
The base are always the Configuration Basket snapshots (JSON files) which we have in Git.
|
||||
For changes either change them directly or change them in the Icinga Director web UI and then create a new snapshot of the according Configuration Basket, download it, modify if necessary, e.g. if it is templated as for the Sysdb import pipeline
|
||||
and then commit it to the git repo.
|
||||
|
||||
The rollout into production is then done with the bootstrap Ansible role for the Icinga2 Master nodes.
|
||||
Note that it will only attempt to import the Configuration Basket snapshot as provided from git when the file changes on disk. So if there is an failure during the import, best delete them on the Icinga2 Master:
|
||||
```
|
||||
rm /etc/icingaweb2/psi/lx-core/*
|
||||
```
|
||||
|
||||
Further there is an issue with updated Sync Rules in the Configuration Basket snapshot. There is a [bug which makes their property list not updated on import](https://github.com/Icinga/icingaweb2-module-director/issues/2779). To work around you need to delete the Sync Rule manually in the Icinga Director UI. They cannot be deleted from shell with `icingacli director` ([feature request](https://github.com/Icinga/icingaweb2-module-director/issues/2706)).
|
||||
|
||||
## Bootstrap
|
||||
|
||||
The Icinga2 infrastructure is maintained and prepared by AIT. Following items need to be prepared from their side:
|
||||
- basic setup of Icinga2 Master
|
||||
- addition of the Icinga Director module
|
||||
- addition of the Fileshipper module with following configuration (`/etc/icingaweb2/modules/fileshipper/imports.ini`):
|
||||
```
|
||||
[Import AWI Linux Infrastructure Servers]
|
||||
basedir = "/etc/icingaweb2/psi/lx-core"
|
||||
```
|
||||
- in `roles.ini` have a `Generic User Role` with read/monitoring-only permissions
|
||||
- the `/etc/icingaweb2/psi/merge-roles-ini.py` script provided by AIT to be able to merge in roles via Ansible/Sysdb API
|
||||
- access to the AD with and LDAP import source named `LDAP PSI`
|
||||
|
||||
From our side we need the following manual setup
|
||||
- prepare the Scheduled Downtime `Generic Linux Alert Suppression` (cannot be imported with Configuration Basket, see [feature request](https://github.com/Icinga/icingaweb2-module-director/issues/2795)) with
|
||||
- Downtime name: `Generic Linux Alert Suppression`
|
||||
- Author: `Core Linux Research Services`
|
||||
- Comment:
|
||||
```
|
||||
By default manged RHEL systems do not alert or send notifications, they just collect monitoring information in Icinga2.
|
||||
To enable alerting, set in Hiera:
|
||||
icinga2::alerting::enable: true
|
||||
```
|
||||
- Fixed: `Yes`
|
||||
- Disabled: `No`
|
||||
- Apply to: `Hosts`
|
||||
- With Services: `Yes`
|
||||
- Assign where: `host.vars.lx_disabled_alerting` `is true (or set)`
|
||||
- and finally on "Ranges" add a range with
|
||||
Days: `january 1 - december 31`
|
||||
Timeperiods: `00:00-24:00`
|
||||
- run the Ansible playbook:
|
||||
```
|
||||
ansible-playbook -i inventory_test.yaml --vault-pass-file ./vault-pass prepare_icinga_master.yaml
|
||||
```
|
||||
or for production
|
||||
```
|
||||
ansible-playbook -i inventory.yaml -i inventory_dmz.yaml --vault-pass-file ./vault-pass prepare_icinga_master.yaml
|
||||
```
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 96 KiB |
@@ -0,0 +1,59 @@
|
||||
@startuml
|
||||
|
||||
node "Icinga2 Master" as master {
|
||||
control "= sysdb-director-import.timer" as import_timer #line.bold
|
||||
file "sysdb-director-import" as import_script
|
||||
component "Director" as director {
|
||||
component "awi-lx-sysdb-hostgroup-import" as hostgroup_import
|
||||
component "awi-lx-sysdb-hostgroup-sync-rule" as hostgroup_sync
|
||||
component "awi-lx-sysdb-host-import" as host_import
|
||||
component "awi-lx-sysdb-host-sync-rule" as host_sync
|
||||
component "awi-lx-sysdb-service-override-sync-rule" as service_override_sync
|
||||
component "icinga-notification-user-import" as user_import
|
||||
component "icinga-notification-user-sync-rule" as user_sync
|
||||
}
|
||||
together {
|
||||
file "user_and_group_list.conf" as user_and_group_list
|
||||
file "department_list.conf" as department_list
|
||||
file "ignore_list.conf" as ignore_list
|
||||
}
|
||||
file "generate_icinga_notification_user_import_basket.py" as notification_user_basket_generator
|
||||
file "Director-Basket_icinga-notification-user-import.json" as notification_user_basket
|
||||
note top of notification_user_basket : adapted LDAP filter
|
||||
' make it stand out, = is for large text
|
||||
folder "= Icinga2 configuration" as icinga2_configuration #line.bold
|
||||
}
|
||||
node "Sysdb Server" as sysdb_server {
|
||||
component "Sysdb API" as sysdb_api {
|
||||
' component "icinga2/v1/roles" as sysdb_api_roles
|
||||
component "icinga2/v1/hostgroups" as sysdb_api_hostgroups
|
||||
component "icinga2/v1/hosts" as sysdb_api_hosts
|
||||
component "icinga2/v1/ad_notification_users" as sysdb_api_roles_ad_notification_users
|
||||
}
|
||||
}
|
||||
database "AD" as ad
|
||||
|
||||
import_timer -[dashed]down-> import_script : "triggers"
|
||||
import_script -[dashed]down-> director : triggers imports, sync rules and deployment
|
||||
import_script -[dashed]up-> user_and_group_list : downloads
|
||||
import_script -[dashed]right-> notification_user_basket_generator : runs
|
||||
|
||||
sysdb_api_hostgroups ==> hostgroup_import
|
||||
hostgroup_import --> hostgroup_sync
|
||||
|
||||
sysdb_api_hosts ==> host_import
|
||||
host_import --> host_sync
|
||||
host_import --> service_override_sync
|
||||
|
||||
sysdb_api_roles_ad_notification_users ==> user_and_group_list
|
||||
notification_user_basket_generator -[dashed]-> notification_user_basket : generates
|
||||
user_and_group_list --> notification_user_basket
|
||||
department_list --> notification_user_basket
|
||||
ignore_list --> notification_user_basket
|
||||
notification_user_basket --> user_import
|
||||
ad ==> user_import
|
||||
user_import --> user_sync
|
||||
|
||||
director ==> icinga2_configuration
|
||||
|
||||
@enduml
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 20 KiB |
@@ -0,0 +1,20 @@
|
||||
@startuml
|
||||
|
||||
skinparam componentStyle rectangle
|
||||
|
||||
component "Icinga2 Master" as master
|
||||
component "Director" as director
|
||||
database "Sysdb" as sysdb
|
||||
database "NetOps" as netops
|
||||
database "Hiera" as hiera
|
||||
database "Puppet Facts" as facts
|
||||
interface "Sysdb API" as sysdb_api
|
||||
|
||||
sysdb --> sysdb_api
|
||||
hiera --> sysdb_api
|
||||
facts --> sysdb_api
|
||||
netops --> sysdb_api
|
||||
sysdb_api --> director
|
||||
director --> master
|
||||
|
||||
@enduml
|
||||
@@ -0,0 +1,4 @@
|
||||
# Engineering Guide
|
||||
|
||||
```{tableofcontents}
|
||||
```
|
||||
@@ -0,0 +1,55 @@
|
||||
# Metrics Server - Influx DB
|
||||
|
||||
This is puppet managed:
|
||||
https://git.psi.ch/linux-infra/hiera/data-lx/blob/master/default/lx-influx-01.psi.ch.yaml
|
||||
|
||||
Runs the influxdb backend for the metrics.psi.ch service, as part of the telegraph, influxdb and grafana stack.
|
||||
|
||||
Data is stored at `/var/lib/influxdb` "locally" on the virtual machine.
|
||||
The influx configuration can be found `/etc/influxdb/influxdb.conf`
|
||||
|
||||
|
||||
# Administration Influx Database
|
||||
|
||||
Connect to the influx server
|
||||
```bash
|
||||
ssh influx.psi.ch
|
||||
```
|
||||
|
||||
Connect to the influx database:
|
||||
```bash
|
||||
influx
|
||||
```
|
||||
|
||||
Now you should have the prompt of the influx cli client
|
||||
|
||||
|
||||
Show all databases
|
||||
```bash
|
||||
show databases
|
||||
```
|
||||
|
||||
Switch to a database:
|
||||
```bash
|
||||
use "database_name"
|
||||
```
|
||||
|
||||
Show all measurements
|
||||
```bash
|
||||
show measurements
|
||||
```
|
||||
|
||||
Show all series (of all measurements)
|
||||
```bash
|
||||
show series
|
||||
```
|
||||
|
||||
Show all series for a particular host:
|
||||
```bash
|
||||
show series where "host" = 'lx-puppet-01.psi.ch'
|
||||
```
|
||||
|
||||
Delete all series for a particular host:
|
||||
```
|
||||
DROP SERIES FROM /.*/ WHERE "host" = 'lx-puppet-01.psi.ch'
|
||||
```
|
||||
@@ -0,0 +1,55 @@
|
||||
# Infrastructure Administration
|
||||
|
||||
## How to Grant a Access to bob/sysdb
|
||||
|
||||
bob is making http calls to the sysdb app. Authorization (https://git.psi.ch/linux-infra/sysdb#authentication-and-authorization) is done via krb5 tokens. Operations outside of environments (creating/changing the owner of/deleting environments) needs to be done by a sysdb admin, ie someone who is a member of the group sysdb-admins. Group membership of the authenticated users is evaluated on the OS level on sysdb.psi.ch. So group memberships can be set both locally or in the AD. This makes it a bit confusing, but both are used.
|
||||
|
||||
|
||||
For the envs (bob env list), only adding and listing are implemented in bob, any other operation, like deletion or modification can only be performed in the sysdb sqlite database itself.
|
||||
|
||||
Each env can only have one user and one group assigned to it.
|
||||
|
||||
|
||||
To grant access to different environments data-xxx repositories normal Git access control is used.
|
||||
Nothing overrides the access control of the git server.
|
||||
|
||||
|
||||
## linux.psi.ch
|
||||
linux.psi.ch is hosted from this git repo as git pages. There is a proxy entry for the domain name linux.psi.ch on the F5 reverse proxy, that is managed by the network team, to reach the git pages by https://linux.psi.ch
|
||||
|
||||
The HTTPS certificates of the domain linux.psi.ch is managed by the network team.
|
||||
|
||||
## Email Lists
|
||||
|
||||
### linux@psi.ch
|
||||
|
||||
Right now following people are on the list:
|
||||
- Marc Caubet
|
||||
- Derek Feichtinger
|
||||
- Peter Huesser
|
||||
- Rene Kapeller
|
||||
- Gilles Martin
|
||||
- Leonardo Sala
|
||||
- Ivano Talamo
|
||||
- Alvise Dorigo
|
||||
- Joshua Taylor
|
||||
- Simon Ebner
|
||||
- Konrad Bucheli
|
||||
|
||||
This email list is administered by Outlook in the following way (if you have manager right):
|
||||
|
||||
- Open outlook and go to the address book
|
||||
|
||||
|
||||
|
||||
- Search for the PSI.Linux mailing list and double click
|
||||
|
||||
|
||||
|
||||
- Go to modify members (you only see this if you are a manager)
|
||||
|
||||
|
||||
- Click on Add and add a new email address
|
||||
|
||||
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 693 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 475 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 505 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 301 KiB |
@@ -0,0 +1,109 @@
|
||||
# Infrastructure Systems
|
||||
List of systems and their primary role:
|
||||
|
||||
|
||||
__Core Infrastructure:__
|
||||
* [boot.psi.ch](boot_server) - TFTP server for PXE booting
|
||||
* [sysdb.psi.ch](sysdb_server) - Runs sysdb, providing the dynamic iPXE, Grub and kickstart files
|
||||
* [puppet.psi.ch](puppet01) - puppet.psi.ch - Puppet server
|
||||
* [repos.psi.ch](repo_server) - Repository server
|
||||
* [lx-sync-01.psi.ch](sync_server) - System to mirror external yum repositories / packages / ...
|
||||
|
||||
* [lxweb00](lxweb00) - http://linux.web.psi.ch - legacy - 129.129.190.46 - Exports further repositories from AFS
|
||||
|
||||
|
||||
|
||||
__Additional Infrastructure__
|
||||
|
||||
Sysdb Access:
|
||||
* [lxsup](lxsup) - Standard node for the linux support, primarily to run bob
|
||||
|
||||
|
||||
Monitoring:
|
||||
|
||||
* [Icinga2](icinga2) - automatic integration into Icinga2
|
||||
* [lx-influx-01.psi.ch](influx) - Influx database server
|
||||
* [lx-metrics-01.psi.ch](metrics) - https://metrics.psi.ch - Grafana frontend for Influx
|
||||
|
||||
|
||||
__Enduser Systems__
|
||||
* [login.psi.ch](login) - Set of nodes for enduser use
|
||||
* cpw.psi.ch - Node to change passwords
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## SSH Certificates / Signing Public User Keys
|
||||
|
||||
Generate a ssh key e.g. as follows:
|
||||
```bash
|
||||
ssh-keygen -o -a 100 -t ed25519 -f ~/.ssh/linux_id_ed25519
|
||||
```
|
||||
|
||||
Use the [user ca certificate](https://git.psi.ch/linux-infra/core-linux-secrets/-/blob/main/ssh-ca/user-ca.gpg), but this is automated by pasting below function into your shell
|
||||
```bash
|
||||
function sign-user-ssh-key {
|
||||
(
|
||||
name="$1"
|
||||
pubkey="$2"
|
||||
|
||||
# let the private key flow through a named pipe
|
||||
# so it never ends up on the file system
|
||||
|
||||
umask 077
|
||||
pipe_base="$(mktemp)" # MacOS does not know about --dry-run
|
||||
pipe="${pipe_base}.pipe"
|
||||
echo "mkfifo '$pipe'"
|
||||
mkfifo "$pipe" || return 1
|
||||
[ -p "$pipe" ] || return 1
|
||||
echo "pass ssh-ca/user-ca > '$pipe' &"
|
||||
pass ssh-ca/user-ca > "$pipe" &
|
||||
echo "ssh-keygen -s '$pipe' -I '$name' -n '$name' -V +55w '$pubkey'"
|
||||
ssh-keygen -s "$pipe" -I "$name" -n "$name" -V +55w "$pubkey"
|
||||
echo "rm '$pipe' '$pipe_base'"
|
||||
rm "$pipe" "$pipe_base"
|
||||
)
|
||||
}
|
||||
```
|
||||
and run it with the user name as principal and the public key file
|
||||
```
|
||||
sign-user-ssh-key $PRINCIPAL $PUBKEY_FILE
|
||||
```
|
||||
|
||||
More details on how this works can be found in this article: https://engineering.fb.com/2016/09/12/security/scalable-and-secure-access-with-ssh/
|
||||
|
||||
|
||||
## Unix Groups
|
||||
|
||||
Currently we have following AD groups to grant access to certain services/systems:
|
||||
|
||||
| Group | Notes |
|
||||
| ---- | ---- |
|
||||
| unx-lx_eng | Member of linux engineering - used to give access to management NFS filesystem, sysdb, ... |
|
||||
| unx-lx_support | used to give Linux supporters access to systems/services |
|
||||
| unx-puppet_adm -| associated with lxdev environment/systems |
|
||||
| unx-puppet_dev | developer of puppet code |
|
||||
| unx-puppet_usr | user of puppet (i.e. need access to linux-infra group/repos) |
|
||||
| unx-lx_users | all personal linux accounts at PSI (directly updated from SAP) |
|
||||
| unx-lx_grafana_adm | Grafana Administrators |
|
||||
| unx-lx_grafana_edi | Group with Grafana editor rights |
|
||||
|
||||
These two groups are used within Service now to assign tickets:
|
||||
| Group |
|
||||
| ---- |
|
||||
| itsm-linux |
|
||||
| itsm-linux_2nd |
|
||||
|
||||
Access VM infrastructure for linux core employees:
|
||||
| Group | Notes |
|
||||
| ---- | ---- |
|
||||
| VC_Admins_Linux | Access to the PSI VM Infrastructure |
|
||||
|
||||
## AD Users
|
||||
| Group | Notes |
|
||||
| ---- | ---- |
|
||||
| lx-netops-api | (keytab) Used to access the netops api |
|
||||
| lx_ad_join | (keytab) Used to join a machine to AD |
|
||||
| linux_ldap ???? | was registered by Derek (he is noted as responsible in AD) - used for ???? |
|
||||
|
||||
@@ -0,0 +1,53 @@
|
||||
# Initial Infrastructure Setup
|
||||
|
||||
This document describes the steps needed for the initial infrastructure setup (in case everything needs to be bootstrapped from scratch)
|
||||
|
||||
This would be the sequence the systems need to be set up:
|
||||
- lx-boot-xx (boot.psi.ch, boot-dmz.psi.ch)
|
||||
- lx-repos-xx (repos.psi.ch, repos-dmz.psi.ch)
|
||||
- lx-sysdb-xx (sysdb.psi.ch)
|
||||
- lx-puppet-xx (puppet.psi.ch)
|
||||
|
||||
The steps involved to bootstrap the boot server and the repository server are the following:
|
||||
|
||||
1. Create the VM in vcenter (Make sure secure boot is disabled!)
|
||||
1. Get the latest RedHat RHEL iso from somewhere (i.e. ETH Red Hat Satellite or directly from [Red Hat](https://access.redhat.com/downloads))
|
||||
- There are two ISOs, one ~900MB and one ~11GB (RHEL8). The smaller one is able to boot and start the installation of the system, however it requires a network based repository for the installation (i.e. the content of the unpacked ISO need to be available via http(s))
|
||||
With the bigger one the system can be completely installed.
|
||||
|
||||
1. Generate a kickstart file for the system in the https://git.psi.ch/linux-infra/bootstrap repository
|
||||
- For the DMZ server the ip of the DNS server needs to be different in DMZ `--nameserver=192.168.70.5`
|
||||
|
||||
1. Create a new iso including the generated kickstart file via the [mkksiso](https://weldr.io/lorax/mkksiso.html) utility:
|
||||
```
|
||||
mkksiso lx-boot-dmz-01.psi.ch.ks rhel-8.7-x86_64-boot.iso lx-boot-dmz-01-rhel-8.7-x86_64-boot.iso
|
||||
```
|
||||
Alternatively create a second iso file with just the kickstart file. Place the kickstart file as `ks.cfg` in an directory and run:
|
||||
```
|
||||
mkisofs -volid OEMDRV -output $TARGET_HOSTNAME-kickstart.iso $DIR_WITH_KICKSTART_FILE
|
||||
```
|
||||
|
||||
1. Remote Login (via RDP) to vmsmgt.psi.ch and mount the ISO to the VM
|
||||
|
||||
1. Make the generated iso accessible to the machine vmsmgt.psi.ch
|
||||
|
||||
1. Open vcenter.psi.ch in the browser, search the virtual machine you want to mount the ISO to. Click on __Launch Remote Console__
|
||||
|
||||
|
||||
1. This will open the VMWare Remote Console program. To mount the ISO do the following (Pay attention that the __"Connect at Boot"__ option is checked):
|
||||
|
||||
|
||||
|
||||
1. If you have a separate kickstart iso file, you need two CD drives and connect both iso files.
|
||||
|
||||
1. Start the VM to trigger the install
|
||||
|
||||
```{note}
|
||||
For the initial setup of boot and repos server in the DMZ a temporary firewall access rule need to be enabled to the PSI internal server https://repos.psi.ch
|
||||
```
|
||||
|
||||
## References
|
||||
- https://weldr.io/lorax/mkksiso.html
|
||||
- https://access.redhat.com/solutions/60959
|
||||
- https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/performing_an_advanced_rhel_8_installation/starting-kickstart-installations_installing-rhel-as-an-experienced-user#doc-wrapper
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 113 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 349 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 213 KiB |
@@ -0,0 +1,116 @@
|
||||
# PXE-booting with iPXE
|
||||
|
||||
## UEFI
|
||||
|
||||
iPXE supports UEFI and so do we. This requires the ``ipxe.efi`` boot image.
|
||||
|
||||
Instructions how to copy the necessary grub files to the tftp server:
|
||||
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/chap-installation-server-setup#sect-network-boot-setup-uefi
|
||||
(alternatively one can also copy the files from the /boot/efi/EFI/redhat/ directory of an installed system)
|
||||
|
||||
```
|
||||
[root@ tmp]# cd /tmp
|
||||
[root@ tmp]# curl -OL http://repos.psi.ch/rhel9/iso/rhel-baseos-9.1-x86_64-dvd/BaseOS/Packages/shim-x64-15.6-1.el9.x86_64.rpm
|
||||
% Total % Received % Xferd Average Speed Time Time Time Current
|
||||
Dload Upload Total Spent Left Speed
|
||||
100 471k 100 471k 0 0 92.0M 0 --:--:-- --:--:-- --:--:-- 92.0M
|
||||
[root@lx-repos-01 tmp]# curl -LO http://repos.psi.ch/rhel9/iso/rhel-baseos-9.1-x86_64-dvd/BaseOS/Packages/grub2-efi-x64-2.06-46.el9.x86_64.rpm
|
||||
% Total % Received % Xferd Average Speed Time Time Time Current
|
||||
Dload Upload Total Spent Left Speed
|
||||
100 1333k 100 1333k 0 0 8550k 0 --:--:-- --:--:-- --:--:-- 8550k
|
||||
[root@ tmp]# rpm2cpio shim-x64-15.6-1.el9.x86_64.rpm | cpio -dimv
|
||||
./boot/efi/EFI/BOOT/BOOTX64.EFI
|
||||
./boot/efi/EFI/BOOT/fbx64.efi
|
||||
./boot/efi/EFI/redhat/BOOTX64.CSV
|
||||
./boot/efi/EFI/redhat/mmx64.efi
|
||||
./boot/efi/EFI/redhat/shim.efi
|
||||
./boot/efi/EFI/redhat/shimx64-redhat.efi
|
||||
./boot/efi/EFI/redhat/shimx64.efi
|
||||
9232 blocks
|
||||
[root@ tmp]# rpm2cpio grub2-efi-x64-2.06-46.el9.x86_64.rpm | cpio -dimv
|
||||
./boot/efi/EFI/redhat/grubx64.efi
|
||||
./boot/grub2/fonts
|
||||
./boot/grub2/fonts/unicode.pf2
|
||||
./boot/grub2/grubenv
|
||||
./boot/loader/entries
|
||||
./etc/dnf/protected.d/grub2-efi-x64.conf
|
||||
./etc/grub2-efi.cfg
|
||||
./etc/grub2.cfg
|
||||
9612 blocks
|
||||
[root@ tmp]# ls boot/efi/EFI/redhat/
|
||||
BOOTX64.CSV grubx64.efi mmx64.efi shim.efi shimx64.efi shimx64-redhat.efi
|
||||
[root@ tmp]# ls -la boot/efi/EFI/redhat/
|
||||
total 6088
|
||||
drwxr-xr-x. 2 root root 122 Mar 1 16:16 .
|
||||
drwxr-xr-x. 4 root root 32 Mar 1 16:16 ..
|
||||
-rwx------. 1 root root 108 Jun 7 2022 BOOTX64.CSV
|
||||
-rwx------. 1 root root 2524792 Aug 25 2022 grubx64.efi
|
||||
-rwx------. 1 root root 856528 Jun 7 2022 mmx64.efi
|
||||
-rwx------. 1 root root 946736 Jun 7 2022 shim.efi
|
||||
-rwx------. 1 root root 946736 Jun 7 2022 shimx64.efi
|
||||
-rwx------. 1 root root 938808 Jun 7 2022 shimx64-redhat.efi
|
||||
[root@ tmp]#
|
||||
```
|
||||
|
||||
|
||||
## Process
|
||||
|
||||
When a system PXE boots, the DHCP server will boot either pxelinux in legacy
|
||||
mode or grub on UEFI. It is still possible to load ipxe from either of these.
|
||||
With the right option, the boot process is pointed to ``sysdb.psi.ch`` and one
|
||||
of the following boot images:
|
||||
|
||||
- `ipxe.efi` for systems using UEFI
|
||||
- `ipxe.lkrn` for all other systems
|
||||
|
||||
The system downloads the image and executes it.
|
||||
|
||||
The image contains a small iPXE script, which makes iPXE retrieve its actual
|
||||
configuration from a web service running (usually) on `sysdb.psi.ch`.
|
||||
Specifically, it queries the URL
|
||||
`https://sysdb.psi.ch/ipxe/v1/config?mac=<MAC>`, where `<MAC>` is the MAC
|
||||
address of the interface used by iPXE.
|
||||
|
||||
The web service on ``sysdb.psi.ch`` will generate the iPXE configuration on the
|
||||
fly, depending on whether the system is supposed to be reinstalled and if so,
|
||||
which distribution it is supposed to use. The menu offers other options as well,
|
||||
e.g. an interactive iPXE shell and a memory test.
|
||||
|
||||
|
||||
## Sequence Diagram of the UEFI Boot Process
|
||||
|
||||
|
||||
|
||||
## Sequence Diagram of the BIOS (Legacy) Boot Process
|
||||
|
||||
|
||||
|
||||
## Building the iPXE boot image
|
||||
|
||||
The steps for building an iPXE image are
|
||||
|
||||
1. Clone `git@git.psi.ch:linux-infra/ipxe-build.git`
|
||||
2. Change into the new directory
|
||||
3. Run the `refresh-ipxe.sh` script. This will check out the iPXE source code
|
||||
mirror from `git.psi.ch`.
|
||||
4. Run the `build.sh` script. This will use the named configurations in the
|
||||
`ipxe-build` repository to compile two iPXE images: `src/bin/ipxe.lkrn`
|
||||
(legacy boot) and `src/bin-x86_64-efi/ipxe.efi` (UEFI).
|
||||
|
||||
|
||||
As described above, we use an iPXE boot image with an embedded script looking
|
||||
roughly like the following
|
||||
```
|
||||
#!ipxe
|
||||
|
||||
dhcp && goto dhcp_succeeded
|
||||
|
||||
shell
|
||||
#prompt for network info
|
||||
|
||||
:dhcp_succeeded
|
||||
|
||||
chain http://sysdb.psi.ch/ipxe/v1/config?mac=${netX/mac}
|
||||
```
|
||||
|
||||
|
||||
@@ -0,0 +1,3 @@
|
||||
# Login Nodes
|
||||
|
||||
This is a set of 3 machines which have the same DNS alias (connection to a random machine) The machines are managed by Puppet: https://git.psi.ch/linux-infra/hiera/data-lx/blob/master/login.yaml.
|
||||
@@ -0,0 +1,6 @@
|
||||
# Login Node - Supporters
|
||||
|
||||
lxsup.psi.ch is a utility machine for our supporters. It provides a readily installed and configured `bob` as well as `ansible` command to provision and modify systems.
|
||||
|
||||
This is a RHEL8 machine and is fully Puppet managed:
|
||||
https://git.psi.ch/linux-infra/hiera/data-lx/-/blob/master/default/lx-sup-01.psi.ch.yaml
|
||||
@@ -0,0 +1,66 @@
|
||||
# Repository Server - LEGACY - lxweb00
|
||||
|
||||
This is a RHEL7 machine and is puppet managed. The httpd configuration seem to be managed there as well:
|
||||
https://git.psi.ch/linux-infra/hiera/data-lx/blob/master/default/lxweb00.psi.ch.yaml
|
||||
|
||||
Exports various paths from AFS to http(s), see /etc/httpd/conf.d/ for details.
|
||||
The AFS directories exported are:
|
||||
```
|
||||
Alias /pxe "/afs/psi.ch/service/linux/tftpboot"
|
||||
Alias /ext/cpt "/afs/psi.ch/project/cpt/repo/"
|
||||
Alias /ext/gfa "/afs/psi.ch/project/gfa-controls-sw-repo"
|
||||
Alias /ext/gpfs "/afs/psi.ch/software/linux/dist/scientificlinux/7x/x86_64/GPFS"
|
||||
Alias /ext/hpc-extra "/afs/psi.ch/software/linux/dist/scientificlinux/7x/x86_64/hpc-extra"
|
||||
Alias /ext/lmu "/afs/psi.ch/project/lmu/lmu_rpm/"
|
||||
Alias /ext/ofed "/afs/psi.ch/software/linux/dist/scientificlinux/7x/x86_64/OFED"
|
||||
Alias /ext/slurm "/afs/psi.ch/software/linux/dist/scientificlinux/7x/x86_64/slurm"
|
||||
|
||||
Alias /dist/yfs "/afs/psi.ch/software/mirror/your-file-system.com/yfs"
|
||||
Alias /dist/ks "/afs/psi.ch/software/mirror/ks"
|
||||
Alias /dist/scientificlinux "/afs/psi.ch/software/mirror/scientificlinux"
|
||||
Alias /dist/scientificlinux/epel "/afs/psi.ch/software/mirror/epel"
|
||||
Alias /dist/scientificlinux/7x/x86_64/tier3 "/afs/psi.ch/software/linux/dist/scientificlinux/7x/x86_64/tier3"
|
||||
```
|
||||
|
||||
|
||||
The httpd config files are located here:
|
||||
```
|
||||
[root@lxweb00 conf.d]# ls -la /etc/httpd/conf.d/25*
|
||||
-rw-r--r-- 1 root root 3294 Dec 3 07:55 /etc/httpd/conf.d/25-linux.web.psi.ch_non_ssl.conf
|
||||
-rw-r--r-- 1 root root 3559 Dec 3 07:55 /etc/httpd/conf.d/25-linux.web.psi.ch_ssl.conf
|
||||
```
|
||||
|
||||
The content is served on port 80 and 443
|
||||
```
|
||||
[root@lxweb00 conf.d]# netstat -tulnp | grep http
|
||||
tcp6 0 0 :::80 :::* LISTEN 19619/httpd
|
||||
tcp6 0 0 :::443 :::* LISTEN 19619/httpd
|
||||
```
|
||||
|
||||
The https certificate is located/installed in `/etc/pki/tls`
|
||||
|
||||
# Questions
|
||||
- who is taking care of this certificate, how is it installed? how is the expiration monitored?
|
||||
- The owner/admin of this system must take care of the certificate. There is no monitoring or automation. The standard SWITCH procedure is to be used.
|
||||
- Why is "/afs/psi.ch/service/linux/tftpboot" exported on this server as well?
|
||||
- Don't know, could only guess.
|
||||
- Who is responsible or the contact person for the different exported AFS directories?
|
||||
- I don't know, it's not really formalized. I have some guesses for some parts:
|
||||
|
||||
| AFS | Responsible / Contact Person |
|
||||
| ------ | ------ |
|
||||
| /afs/psi.ch/project/cpt/repo/ | Gilles Martin |
|
||||
| /afs/psi.ch/project/gfa-controls-sw-repo | Rene Kapeller|
|
||||
| /afs/psi.ch/software/linux/dist/scientificlinux/7x/x86_64/GPFS | Leo's group |
|
||||
| /afs/psi.ch/software/linux/dist/scientificlinux/7x/x86_64/hpc-extra | Marc & Ivano |
|
||||
| /afs/psi.ch/project/lmu/lmu_rpm/ | Andrea Raselli |
|
||||
| /afs/psi.ch/software/linux/dist/scientificlinux/7x/x86_64/OFED | Marc & Ivano |
|
||||
| /afs/psi.ch/software/linux/dist/scientificlinux/7x/x86_64/slurm | Marc & Ivano |
|
||||
| -- | -- |
|
||||
| /dist/yfs | Achim |
|
||||
| /dist/ks | Achim |
|
||||
| /dist/scientificlinux | Achim |
|
||||
| /dist/scientificlinux/epel | Achim |
|
||||
| /dist/scientificlinux/7x/x86_64/tier3 | Derek |
|
||||
|
||||
All repos in the /dist path are Scientific Linux 7 !!!!
|
||||
@@ -0,0 +1,19 @@
|
||||
# Metrics Server - Grafana
|
||||
|
||||
The Grafana frontend can be accessed via - https://metrics.psi.ch
|
||||
|
||||
This machine is puppet managed:
|
||||
https://git.psi.ch/linux-infra/hiera/data-lx/blob/master/default/lx-metrics-01.psi.ch.yaml
|
||||
|
||||
The rights for Grafana are managed with these two AD groups:
|
||||
| Group | Notes |
|
||||
| ---- | ---- |
|
||||
| unx-lx_grafana_adm | Grafana Administrators |
|
||||
| unx-lx_grafana_edi | Group with Grafana editor rights |
|
||||
|
||||
## Administration
|
||||
|
||||
New telegraf/hiera metric sources are automatically added by a systemd timer once a day (~ 01:08).
|
||||
|
||||
To add a new metric source manually go about like this:
|
||||
|
||||
@@ -0,0 +1,130 @@
|
||||
# New Sysdb Environment
|
||||
|
||||
## Introduction
|
||||
|
||||
Deploying a new environment requires the following:
|
||||
1. Configuring the environment in **bob**
|
||||
2. Configuring the environment in GIT (`https://git.psi.ch/linux-infra/hiera`)
|
||||
- Environment format: `data-<environment_name>`
|
||||
- And change permissions accordingly
|
||||
- Configure the necessary webhooks for the Puppet and Sysdb server
|
||||
3. Configuring the environment in Puppet (e.g. `puppet01.psi.ch`)
|
||||
|
||||
## Configuring the environment in sysdb
|
||||
|
||||
Bob allows to create a new environment in `sysdb` by using the `bob env` option.
|
||||
You must have permissions to do that.
|
||||
|
||||
|
||||
You must belong to the `sysdb-admins` group that is actually
|
||||
configured on the local `/etc/group` file. A migration to Active
|
||||
Directory should be done for that group.
|
||||
|
||||
To list current defined environments run
|
||||
|
||||
bob env list
|
||||
|
||||
To add a new environment, run
|
||||
|
||||
bob env add <environment_name> <owner> <admin_group> "<description>"
|
||||
|
||||
In example, for the MeG cluster
|
||||
|
||||
bob env add meg caubet_m unx-hpc_adm "MeG Cluster"
|
||||
|
||||
### Test new environment in BOB
|
||||
|
||||
In order to test that environment was successfully created
|
||||
|
||||
bob env list | grep <environment_name>
|
||||
|
||||
An example
|
||||
|
||||
caubet_m@caubet-laptop:~/GIT/admin-guide/deployment$ bob env list | grep meg
|
||||
meg caubet_m unx-hpc_adm MeG Cluster
|
||||
|
||||
|
||||
## Configuring the environment in GIT
|
||||
|
||||
You must belong to the `unx-puppet_adm` Active Directory group in order to be able to create new projects.
|
||||
|
||||
In order to create a new environment in **GIT**, you should access and login in the following link: https://git.psi.ch/linux-infra/hiera/.
|
||||
Here you can see the different environments.
|
||||
|
||||
The steps to create and configure a new **GIT** project are:
|
||||
|
||||
1. Create a new project (environment) in the `hiera` group. It can be done here: https://git.psi.ch/projects/new?namespace_id=1738
|
||||
|
||||
- Click `[Create blank project]`
|
||||
- Define `[Project name]`, which *must* have the format `data-<environment_name>` where `<environment_name>` is the one defined in **Bob**
|
||||
- Specify `[Visibility Level]`: Should be `Internal` or `Private`
|
||||
- Remove the tick `[Initialize repository with a README]`.
|
||||
|
||||
2. Configure project permissions as follows:
|
||||
|
||||
- `[data-<environment_name]->[Settings]->[Repository]`, or directly: https://git.psi.ch/linux-infra/hiera/data-(environment_name)/-/settings/repository
|
||||
- Enable already registered deploy key: `[Deploy Keys]` -> `[Privately accessible deploy keys]` -> select `root@puppet01'` -> click on `'Enable'`
|
||||
- `[data-<environment_name]->[Manage]->[Members]`, or directly: https://git.psi.ch/linux-infra/hiera/data-(environment_name)/project_members
|
||||
- Setup specific permissions for specific users or groups. In example:
|
||||
- Set project `Maintainer`:
|
||||
- `[Select members to invite]` (`caubet_m`) + `[Choose a role permission]` (`Maintainer`) + `[Add to project]`
|
||||
- Set other roles:
|
||||
- `[Select members to invite]` (`dorigo_a`) + `[Choose a role permission]` (`Developer`) + `[Add to project]`
|
||||
- `[data-<environment_name]->[Settings]->[Webhooks]`, or directly: https://git.psi.ch/linux-infra/hiera/data-(environment_name)/-/hooks
|
||||
- Add WebHooks as follows:
|
||||
- `[URL]`: http://puppet01.psi.ch/events/dataupdate
|
||||
- `[URL]`: http://sysdb.psi.ch/events/dataupdate
|
||||
- (Checked) `[Push events]`. Uncheck the rest.
|
||||
- `[SSL verification]` -> (uncheck) `[Enable SSL verification]`
|
||||
- Confirm information from above, and click on `[Add webhook]` to add the new WebHook.
|
||||
|
||||
### Test new environment in GIT
|
||||
|
||||
In order to test that environment was successfully created
|
||||
|
||||
git clone git@git.psi.ch:linux-infra/hiera/data-<environment_name>.git
|
||||
|
||||
An example
|
||||
|
||||
caubet_m@caubet-laptop:~/GIT$ git clone git@git.psi.ch:linux-infra/hiera/data-meg.git
|
||||
Cloning into 'data-meg'...
|
||||
X11 forwarding request failed
|
||||
warning: You appear to have cloned an empty repository.
|
||||
|
||||
## Configuring the environment in Puppet server
|
||||
|
||||
In [bootstrap](https://git.psi.ch/linux-infra/bootstrap) add the new repo to `instcode/puppet/puppet_server/manifests/data.pp` and run the bootstrap for the Puppet server. Note that before this can be rolled out `master` branch needs to exist on `git.psi.ch`.
|
||||
|
||||
## Configuring the environment in Sysdb Server
|
||||
|
||||
In [bootstrap](https://git.psi.ch/linux-infra/bootstrap) add the new repo to the suitable inventory file (eg. `ansible/inventory.yaml` for production) and run the playbook for the Sysdb server. Note that before this can be rolled out `master` branch needs to exist on `git.psi.ch`.
|
||||
|
||||
|
||||
## Test new environment in Puppet
|
||||
|
||||
In order to test that environment was successfully created
|
||||
|
||||
git clone git@git.psi.ch:linux-infra/data-<environment_name>.git
|
||||
|
||||
Add a new file <environment_name>.yaml in to the project:
|
||||
|
||||
cd data-<environment_name>
|
||||
touch <environment_name>.yaml
|
||||
git add <environment_name>.yaml
|
||||
git commit -a -m "Added first empty file"
|
||||
git push
|
||||
|
||||
After a few seconds (needs time to trigger the change), check in `puppet01.psi.ch:/srv/puppet/data/<environment_name>` that file was successfully triggered (copied) to the puppet server from **GIT**
|
||||
|
||||
ssh root@puppet01.psi.ch ls /srv/puppet/data/<environment_name>/<environment_name>.yaml
|
||||
|
||||
Full real example:
|
||||
|
||||
git clone git@git.psi.ch:linux-infra/data-meg.git
|
||||
cd data-meg
|
||||
touch meg.yaml
|
||||
git add meg.yaml
|
||||
git commit -a -m "Added first empty file"
|
||||
git push
|
||||
sleep 5
|
||||
ssh root@puppet01.psi.ch ls /srv/puppet/data/meg/meg.yaml
|
||||
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 121 KiB |
@@ -0,0 +1,4 @@
|
||||
# Puppet
|
||||
|
||||
```{tableofcontents}
|
||||
```
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 37 KiB |
@@ -0,0 +1,20 @@
|
||||
``grub2``
|
||||
=========
|
||||
|
||||
This module provides a defined type to configure kernel arguments in grub2.
|
||||
|
||||
|
||||
Defined Types
|
||||
-------------
|
||||
|
||||
|
||||
``grub2::kernel_arg``
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Modify a kernel argument.
|
||||
|
||||
Parameters:
|
||||
|
||||
- ``action``: one of 'add' and 'remove'
|
||||
- ``value``: specifies the value for arguments of the form ``arg=value``, e.g.
|
||||
``crashkernel=auto``.
|
||||
@@ -0,0 +1,156 @@
|
||||
``logrotate``
|
||||
=============
|
||||
|
||||
This module configures ``logrotate``. Further information an examples can be
|
||||
found in the following link:
|
||||
|
||||
* https://git.psi.ch/linux-infra/voxpupuli-logrotate
|
||||
|
||||
Main class ``logrotate`` can be called, but usually calling just a rule ``logrotate::rule``
|
||||
should be enough to automatically configure ``logrotate`` in the host. It will use the
|
||||
default values for this class, which is placing all the default ``rules`` from the O.S.
|
||||
to the ``/etc/logrotate.d`` directory.
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
All available parameters are::
|
||||
|
||||
namevar - The String name of the rule.
|
||||
path - The path String to the logfile(s) to be rotated.
|
||||
ensure - The desired state of the logrotate rule as a String. Valid
|
||||
values are 'absent' and 'present' (default: 'present').
|
||||
compress - A Boolean value specifying whether the rotated logs should
|
||||
be compressed (optional).
|
||||
compresscmd - The command String that should be executed to compress the
|
||||
rotated logs (optional).
|
||||
compressext - The extention String to be appended to the rotated log files
|
||||
after they have been compressed (optional).
|
||||
compressoptions - A String of command line options to be passed to the
|
||||
compression program specified in `compresscmd` (optional).
|
||||
copy - A Boolean specifying whether logrotate should just take a
|
||||
copy of the log file and not touch the original (optional).
|
||||
copytruncate - A Boolean specifying whether logrotate should truncate the
|
||||
original log file after taking a copy (optional).
|
||||
create - A Boolean specifying whether logrotate should create a new
|
||||
log file immediately after rotation (optional).
|
||||
create_mode - An octal mode String logrotate should apply to the newly
|
||||
created log file if create => true (optional).
|
||||
create_owner - A username String that logrotate should set the owner of the
|
||||
newly created log file to if create => true (optional).
|
||||
create_group - A String group name that logrotate should apply to the newly
|
||||
created log file if create => true (optional).
|
||||
dateext - A Boolean specifying whether rotated log files should be
|
||||
archived by adding a date extension rather just a number
|
||||
(optional).
|
||||
dateformat - The format String to be used for `dateext` (optional).
|
||||
Valid specifiers are '%Y', '%m', '%d' and '%s'.
|
||||
dateyesterday - A Boolean specifying whether to use yesterday's date instead
|
||||
of today's date to create the `dateext` extension (optional).
|
||||
delaycompress - A Boolean specifying whether compression of the rotated
|
||||
log file should be delayed until the next logrotate run
|
||||
(optional).
|
||||
extension - Log files with this extension String are allowed to keep it
|
||||
after rotation (optional).
|
||||
ifempty - A Boolean specifying whether the log file should be rotated
|
||||
even if it is empty (optional).
|
||||
mail - The email address String that logs that are about to be
|
||||
rotated out of existence are emailed to (optional).
|
||||
mailfirst - A Boolean that when used with `mail` has logrotate email the
|
||||
just rotated file rather than the about to expire file
|
||||
(optional).
|
||||
maillast - A Boolean that when used with `mail` has logrotate email the
|
||||
about to expire file rather than the just rotated file
|
||||
(optional).
|
||||
maxage - The Integer maximum number of days that a rotated log file
|
||||
can stay on the system (optional).
|
||||
minsize - The String minimum size a log file must be to be rotated,
|
||||
but not before the scheduled rotation time (optional).
|
||||
The default units are bytes, append k, M or G for kilobytes,
|
||||
megabytes and gigabytes respectively.
|
||||
maxsize - The String maximum size a log file may be to be rotated;
|
||||
When maxsize is used, both the size and timestamp of a log
|
||||
file are considered for rotation.
|
||||
The default units are bytes, append k, M or G for kilobytes,
|
||||
megabytes and gigabytes respectively.
|
||||
missingok - A Boolean specifying whether logrotate should ignore missing
|
||||
log files or issue an error (optional).
|
||||
olddir - A String path to a directory that rotated logs should be
|
||||
moved to (optional).
|
||||
postrotate - A command String that should be executed by /bin/sh after
|
||||
the log file is rotated (optional).
|
||||
prerotate - A command String that should be executed by /bin/sh before
|
||||
the log file is rotated and only if it will be rotated
|
||||
(optional).
|
||||
firstaction - A command String that should be executed by /bin/sh once
|
||||
before all log files that match the wildcard pattern are
|
||||
rotated (optional).
|
||||
lastaction - A command String that should be execute by /bin/sh once
|
||||
after all the log files that match the wildcard pattern are
|
||||
rotated (optional).
|
||||
rotate - The Integer number of rotated log files to keep on disk
|
||||
(optional).
|
||||
rotate_every - How often the log files should be rotated as a String.
|
||||
Valid values are 'hour', 'day', 'week', 'month' and 'year'
|
||||
(optional). Please note, older versions of logrotate do not
|
||||
support yearly log rotation.
|
||||
size - The String size a log file has to reach before it will be
|
||||
rotated (optional). The default units are bytes, append k,
|
||||
M or G for kilobytes, megabytes or gigabytes respectively.
|
||||
sharedscripts - A Boolean specifying whether logrotate should run the
|
||||
postrotate and prerotate scripts for each matching file or
|
||||
just once (optional).
|
||||
shred - A Boolean specifying whether logs should be deleted with
|
||||
shred instead of unlink (optional).
|
||||
shredcycles - The Integer number of times shred should overwrite log files
|
||||
before unlinking them (optional).
|
||||
start - The Integer number to be used as the base for the extensions
|
||||
appended to the rotated log files (optional).
|
||||
su_owner - A username String that logrotate should use to rotate a
|
||||
log file set instead of using the default if
|
||||
su => true (optional).
|
||||
su_group - A String group name that logrotate should use to rotate a
|
||||
log file set instead of using the default if
|
||||
su => true (optional).
|
||||
uncompresscmd - The String command to be used to uncompress log files
|
||||
(optional).
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
||||
Configure ``logrotate.conf``::
|
||||
|
||||
logrotate::conf { '/etc/logrotate.conf':
|
||||
rotate => 10,
|
||||
rotate_every => 'week',
|
||||
ifempty => true,
|
||||
dateext => true,
|
||||
}
|
||||
|
||||
|
||||
Rule for rotating ``messages``::
|
||||
|
||||
logrotate::rule { 'messages':
|
||||
path => '/var/log/messages',
|
||||
rotate => 5,
|
||||
rotate_every => 'week',
|
||||
postrotate => '/usr/bin/killall -HUP syslogd',
|
||||
}
|
||||
|
||||
|
||||
Rule for rotating ``slurmd`` client::
|
||||
|
||||
logrotate::rule { 'slurmd':
|
||||
path => '/var/log/slurm/slurmd.log',
|
||||
rotate => $rotate,
|
||||
rotate_every => $rotate_every,
|
||||
compress => true,
|
||||
create => true,
|
||||
create_mode => '0600',
|
||||
create_owner => 'slurm',
|
||||
create_group => 'slurm',
|
||||
missingok => true,
|
||||
ifempty => false,
|
||||
sharedscripts => true,
|
||||
postrotate => '/bin/systemctl reload slurmd.service > /dev/null 2>/dev/null || true';
|
||||
}
|
||||
@@ -0,0 +1,43 @@
|
||||
``selinux``
|
||||
===========
|
||||
|
||||
This module configures :doc:`selinux`. It allows configuring the SELinux mode
|
||||
as well as setting SELinux booleans.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
``selinux_mode``
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Acceptable values are ``enforcing``, ``permissive``, and ``disabled``. The
|
||||
module configures this mode for the next reboot. It also sets it right away
|
||||
unless the mode to be configured is ``disabled`` or SELinux is currently
|
||||
disabled. In the former case the current mode is set to ``permissive``. In the
|
||||
latter case nothing is done before the next reboot.
|
||||
|
||||
|
||||
Defined Types
|
||||
-------------
|
||||
|
||||
``set_sebool``
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
Sets the SELinux boolean specified as the resource title unless SELinux is
|
||||
disabled, in which case it does nothing.
|
||||
|
||||
Parameters:
|
||||
|
||||
- ``enable``
|
||||
|
||||
If true, the boolean is set to ``on``. If false, the boolean is set to
|
||||
``off``.
|
||||
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
||||
Allow httpd to access user's home directories::
|
||||
|
||||
selinux::set_sebool {'httpd_enable_homedirs': enable => true }
|
||||
@@ -0,0 +1,25 @@
|
||||
``sudo``
|
||||
========
|
||||
|
||||
This module installs and configures ``sudo(8)``.
|
||||
This is only internal documentation, Hiera configuration is done in the :doc:`aaa profile<../profiles/aaa>`.
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
|
||||
``allow_sudoers_d``
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This boolean determines whether the files in ``/etc/sudoers.d/`` are included in
|
||||
the sudo configuration.
|
||||
|
||||
|
||||
Defined types
|
||||
-------------
|
||||
|
||||
``sudo::rules``
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
This defined type accepts a parameter ``rules``, which is an array of strings to
|
||||
be added to ``/etc/sudoers``.
|
||||
@@ -0,0 +1,18 @@
|
||||
``sysctl``
|
||||
===========
|
||||
|
||||
This module configures ``sysctl``. Further information an examples can be
|
||||
found in the official page:
|
||||
|
||||
* https://forge.puppet.com/tpdownes/sysctl
|
||||
|
||||
The sysctl module is called automatically so is possible to do sysctl tuning
|
||||
by configuring properly hiera using the `sysctl::values` variable, eg.::
|
||||
|
||||
sysctl::values:
|
||||
net.ipv4.tcp_slow_start_after_idle:
|
||||
value: '0'
|
||||
net.core.rmem_max:
|
||||
value: '83886080'
|
||||
net.core.wmem_max:
|
||||
value: '83886080'
|
||||
@@ -0,0 +1,77 @@
|
||||
``systemd``
|
||||
===========
|
||||
|
||||
This module provides defined types to create systemd units. It automatically
|
||||
takes care of reloading systemd when necessary, automatically generates correct
|
||||
names for ``.mount`` units, etc.
|
||||
|
||||
The parameters of defined types are usually similar to the systemd option names
|
||||
that they represent. Camel case (as used by systemd) is transformed to the
|
||||
lowercase-with-underscore style usually used with Puppet, e.g. ``OnCalendar`` in
|
||||
systemd becomes ``on_calendar``.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
``default_target``
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The systemd default target, i.e. usually one of ``multi-user.target`` or
|
||||
``graphical.target``.
|
||||
|
||||
|
||||
Defined Types
|
||||
-------------
|
||||
|
||||
All units support the following parameters for the ``[Unit]`` or ``[Install]``
|
||||
sections:
|
||||
|
||||
- ``description``
|
||||
- ``wanted_by``
|
||||
|
||||
|
||||
``systemd::timer``
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Creates a timer unit.
|
||||
|
||||
Parameters:
|
||||
|
||||
- ``on_calendar``
|
||||
- ``unit``
|
||||
|
||||
|
||||
``systemd::mount``
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Creates a mount unit. The name of the unit file has to be (an encoded form of)
|
||||
the mountpoint, which is automatically generated. See ``systemd.mount(5)`` for
|
||||
details.
|
||||
|
||||
Parameters:
|
||||
|
||||
- ``what``
|
||||
- ``where``
|
||||
- ``options``
|
||||
|
||||
|
||||
``systemd.service``
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- ``type`` (default: ``simple``)
|
||||
- ``exec_start``
|
||||
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
||||
Defining a timer unit
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Timer units integrate nicely with the remaining services. They can be managed
|
||||
through ``systemctl(1)`` and their log messages can easily be accessed through
|
||||
``journalctl -u xxxxx.timer``.
|
||||
|
||||
A timer unit needs a corresponding service unit which executes the actual
|
||||
command.
|
||||
@@ -0,0 +1,24 @@
|
||||
``updatedb``
|
||||
============
|
||||
|
||||
This module manages the configuration for ``mlocate`` aka ``updatedb(8)``.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
``enable``
|
||||
~~~~~~~~~~
|
||||
|
||||
A boolean indicating whether ``mlocate`` - ie the ``updatedb(8)`` cron job -
|
||||
should be enabled or not.
|
||||
|
||||
|
||||
Defined Types
|
||||
-------------
|
||||
|
||||
``updatedb::exclude``
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Takes a list of directories and makes sure that ``updatedb(8)`` ignores them
|
||||
when indexing.
|
||||
@@ -0,0 +1,32 @@
|
||||
``utils``
|
||||
=========
|
||||
|
||||
This module contains a number of utility functions used at PSI. It is the
|
||||
PSI-specific analogue to Puppetlabs' ``stdlib``.
|
||||
|
||||
|
||||
Functions
|
||||
---------
|
||||
|
||||
|
||||
``check_os``
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Accepts an arbitrary number of arguments, each of which is a string of the form
|
||||
``$osfamily $majorversion`` as reported by ``facter(8)``. If the facts of the
|
||||
client system **do not** match any of the arguments, the function aborts the
|
||||
Puppet run.
|
||||
|
||||
|
||||
``rand_time``
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
This function takes a parameter specifying a time window and returns a specific
|
||||
time within this window based on the MD5 on the hostname. This allows scheduling
|
||||
cron jobs etc uniformly across a fleet of system within a given window, while
|
||||
keeping the time on each system predictable.
|
||||
|
||||
The format for the argument specifying the time window is ``HH:MM--HH:MM``. The
|
||||
window must not include midnight.
|
||||
|
||||
The format of the return value is ``HH:MM``.
|
||||
@@ -0,0 +1,107 @@
|
||||
# Modules
|
||||
|
||||
The repository for the Puppet role/profile modules is <https://git.psi.ch/linux-infra/puppet>.
|
||||
|
||||
|
||||
So we have some roles that are generic PSI-wide (eg. `role::server`) while
|
||||
some roles that are specific to some projects and have a dedicated namespace (e.g. `role::hpc::database`).
|
||||
|
||||
For the profiles we have
|
||||
|
||||
|
||||
- `profile::ssh_client`
|
||||
- `profile::afs_client`
|
||||
- `profile::log_client`
|
||||
- `profile::mysql_server`
|
||||
- ...
|
||||
|
||||
For profiles maybe we will not need namespace areas dedicated to
|
||||
specific projects, since profiles should be generic enough to be
|
||||
reusable.
|
||||
|
||||
|
||||
Components are gernerally useful Puppet modules and they reside in an own git repository and are handled like any other externally used module.
|
||||
|
||||
|
||||
## Hiera queries
|
||||
|
||||
Only profiles and roles query Hiera. Components should take all their inputs as
|
||||
parameters or facts.
|
||||
|
||||
In profiles, Hiera queries must generally be done as default arguments to
|
||||
parameters, **not** inside the modules body
|
||||
|
||||
```
|
||||
class profile::logging (
|
||||
$forward_to = lookup('...'),
|
||||
$persistent_journal = lookup('...'),
|
||||
)
|
||||
{
|
||||
```
|
||||
|
||||
The reason is that this allows a role to enforce certain parameters and disable
|
||||
the corresponding Hiera query.
|
||||
|
||||
|
||||
## Layout
|
||||
|
||||
Roles and profiles are usually implemented in a single file, e.g.
|
||||
`code/profile/manifests/logging.pp`. Components on the other hand follow the
|
||||
standard Puppet layout, i.e.
|
||||
`auditd/manifests/{init,install,config,service}.pp`.
|
||||
|
||||
## Files and templates
|
||||
|
||||
Every file or template should be used by only one class and its path inside the
|
||||
module should reflect this. Eg. if the template `sshd_config.erb` is used by
|
||||
the `profile::ssh_server` module, it will be places inside the
|
||||
`templates/profile/ssh_server` directory.
|
||||
|
||||
Furthermore, on top of every file managed by puppet, a header like the
|
||||
following should be present:
|
||||
|
||||
```
|
||||
########################################################################
|
||||
#
|
||||
# THIS FILE IS MANAGED BY PUPPET - DO NOT MODIFY!
|
||||
#
|
||||
# profile::ssh_server
|
||||
# sshd_config.erb
|
||||
#
|
||||
########################################################################
|
||||
```
|
||||
|
||||
The last two lines should be:
|
||||
|
||||
- the puppet class using the file;
|
||||
- the name of the file/template.
|
||||
|
||||
## Debugging templates
|
||||
|
||||
You can use the `erb` tool to test the variable interpolation. One easy way is to prepare a file with the variable values and pipe it together with the template through erb. Define the variables in a file `test-vars.erb` like in this example
|
||||
|
||||
```
|
||||
<%
|
||||
@partitions = {'a' => 'aa', 'b' => 'bb', 'c' => 'cc'}
|
||||
@group_whitelist = ['groupA', 'groupB']
|
||||
@port = 8000
|
||||
%>
|
||||
```
|
||||
|
||||
and then use a commmand line like the following to pipe it through `erb`
|
||||
|
||||
```
|
||||
erb <(cat /tmp/test-vars.erb /tmp/my-template.erb)
|
||||
```
|
||||
|
||||
The output will contain the variable substituted template. If you want to check your
|
||||
template for syntax errors, you can just use the following command
|
||||
|
||||
```
|
||||
erb -P -x -T '-' jupyterhub_config.py.erb | ruby -c
|
||||
```
|
||||
|
||||
## Contents
|
||||
|
||||
```{tableofcontents}
|
||||
```
|
||||
@@ -0,0 +1,40 @@
|
||||
|
||||
# Overview
|
||||
|
||||
Puppet is used in master mode and the general idea is to make large use of indipendent and (relatively) small puppet modules and composing profiles and roles based on them to create classes that are assigned to the hosts. By independence of puppet modules we mean that each puppet module targets a single functionality (eg. `web server`, `afs client`) and this is choosen to keep the code of the single module smaller, more coherent and easier to debug.
|
||||
|
||||
Furthermore the system makes use of some puppet modules from the [puppet forge](https://forge.puppet.com). These puppet modules are not accessed directly but through a PSI mirror.
|
||||
|
||||
Code and data are kept separated, using puppet modules for code and hiera for data. Secure data are safely managed inside hiera using [hiera eyaml](https://github.com/TomPoulton/hiera-eyaml).
|
||||
|
||||
For each host the following parameters will determine how it will be configured:
|
||||
|
||||
- the puppet environment (that will determine the puppet role/profile code base)
|
||||
- the sysdb data environment (that will determine the hiera code base)
|
||||
- the puppet group (that will determine what files will be considered in the hiera code base)
|
||||
- the role
|
||||
|
||||
All these elements are configured inside sysdb as attributes and are accessed by the puppet master via the ENC.
|
||||
|
||||
Here you can get a general overview:
|
||||
|
||||
|
||||
|
||||
## Puppet Environments
|
||||
------------
|
||||
|
||||
We use Puppet environments for two purposes:
|
||||
- roll out changes to a small subset of all systems first
|
||||
- module development
|
||||
|
||||
|
||||
The following environments exist:
|
||||
- `prod` - The most stable, and most systems are attached to it. All changes to `prod` have to go through `preprod` first.
|
||||
|
||||
- `preprod` - production test environment
|
||||
|
||||
- Development environments. These are private to a single developer,
|
||||
can have names matching the regex ``^[a-z]+[a-z,0-9,_]+$`` like ``ganglia_issue_21`` or
|
||||
``klog_client``, and are used for developing and testing
|
||||
changes. Generally, only individual systems are attached to these
|
||||
environments.
|
||||
@@ -0,0 +1,335 @@
|
||||
``profile::aaa``
|
||||
=====================
|
||||
|
||||
This module manages configuration related to authentication, authorization, and
|
||||
auditing. In particular, it
|
||||
|
||||
- performs the Active Directory join (optional)
|
||||
- configures login restrictions (e.g. :manpage:`pam_access(8)`)
|
||||
- adds sudo rules for administrators
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
=============================== ======== ==============================================================
|
||||
**Name** **Type** **Default**
|
||||
------------------------------- -------- --------------------------------------------------------------
|
||||
admins list hiera_array('aaa::admins')
|
||||
bastions list hiera('aaa::bastions')
|
||||
cache_creds bool hiera('aaa::cache_creds')
|
||||
create_homes bool hiera('aaa::create_homes')
|
||||
enable_ad bool hiera('aaa::enable_ad')
|
||||
enable_eaccounts bool hiera('aaa::enable_eaccounts')
|
||||
enable_slurm bool false
|
||||
enable_ssh_allow bool hiera('aaa::enable_ssh_allow')
|
||||
enable_tier3_ldap bool hiera('aaa::enable_tier3_ldap', false)
|
||||
ldap_enabled bool hiera('aaa::ldap_enabled')
|
||||
offline_creds_expiration string hiera('aaa::offline_creds_expiration')
|
||||
override_homedir string hiera('aaa::override_homedir', undef)
|
||||
ssh_authorized_keys hash hiera_hash('aaa::sshkeys', {})
|
||||
sssd_debuglevel int hiera('aaa::sssd_debuglevel')
|
||||
sudo_rules (Hiera only) list hiera_array('aaa::sudo_rules', [])
|
||||
support_afs bool hiera('base::enable_afs'),
|
||||
use_bastions bool hiera('aaa::use_bastions', $profile::networking::use_bastions)
|
||||
users list hiera_array('aaa::users', [])
|
||||
=============================== ======== ==============================================================
|
||||
|
||||
|
||||
``admins``
|
||||
~~~~~~~~~~
|
||||
|
||||
A list of user and/or group names. The users as well as the members of the groups
|
||||
can log in on the system and have full root privileges via sudo.
|
||||
|
||||
Group names must be prefixed with ``%``.
|
||||
|
||||
Example::
|
||||
|
||||
aaa::admins:
|
||||
- 'markushin'
|
||||
- 'gsell'
|
||||
- 'barabas'
|
||||
- '%unx-linux_support'
|
||||
|
||||
Also see `users`_.
|
||||
|
||||
|
||||
``bastions``
|
||||
~~~~~~~~~~~~
|
||||
|
||||
A list of FQDNs. If `use_bastions`_ is true, then root logins are only allowed
|
||||
from the hosts on this list. *Note*: If the list is empty, login is unrestricted
|
||||
again!
|
||||
|
||||
Example::
|
||||
|
||||
aaa::bastions:
|
||||
- 'gpfs-node1.psi.ch'
|
||||
- 'gpfs-node2.psi.ch'
|
||||
- 'gpfs-node3.psi.ch'
|
||||
- 'wmgt01.psi.ch'
|
||||
- 'wmgt02.psi.ch'
|
||||
|
||||
``create_homes``
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
This boolean controls whether home directories are created on login when
|
||||
necessary. This only works if the underlying filesystem allows it. In
|
||||
particular, it does not work on AFS.
|
||||
|
||||
Also see `override_homedir`_.
|
||||
|
||||
|
||||
``cache_creds``
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This boolean controls whether sssd caches credentials.
|
||||
|
||||
Also see `offline_creds_expiration`_.
|
||||
|
||||
|
||||
``enable_ad``
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Determines whether the system will be configured for Active Directory
|
||||
authentication.
|
||||
|
||||
|
||||
``enable_eaccounts``
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Setting this to ``true`` enables the Active Directory OU containing the
|
||||
e-accounts.
|
||||
|
||||
|
||||
``enable_slurm``
|
||||
~~~~~~~~~~~~~~~~
|
||||
When set to ``true``, we allow slurm users to login on computing nodes in where
|
||||
their jobs are running. Otherwise, users are not allowed to login in the computing
|
||||
nodes.
|
||||
|
||||
To enable this behaviour, someone needs to call directly the ``profile::aaa`` class
|
||||
and enable this feature, but also needs to change the call of the ``role::base``
|
||||
class by setting ``include_aaa`` to ``false``. For example::
|
||||
|
||||
class {
|
||||
'role::base':
|
||||
include_aaa => false;
|
||||
'profile::aaa':
|
||||
support_afs => hiera('base::enable_afs'),
|
||||
enable_slurm => true;
|
||||
'slurm::compute':
|
||||
cluster => $cluster;
|
||||
}
|
||||
|
||||
|
||||
|
||||
``enable_ssh_allow``
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Allow users to manage access to the system bypassing Puppet by adding usernames
|
||||
to ``/etc/security/ssh.allow.user``. This file is never touched by Puppet.
|
||||
Documentation can be found in :manpage:`pam_listfile(8)` or
|
||||
``/etc/security/ssh.allow.README`` on the target system.
|
||||
|
||||
|
||||
``enable_tier3_ldap``
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
When set to ``true``, sssd.conf is configured to support only OpenLDAP for
|
||||
the Tier3. Other domains (Active Directory D.PSI.CH and LDAP SLS.PSI.CH) are
|
||||
not included in the configuration file.
|
||||
|
||||
|
||||
``ldap_enabled``
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
This boolean controls whether LDAP (AD) is used for user information and
|
||||
authentication.
|
||||
|
||||
In this case the following port have to be accessible from the host to the
|
||||
domain controllers:
|
||||
|
||||
- 389/TCP
|
||||
- 389/UDP
|
||||
- 88/TCP
|
||||
- 88/UDP
|
||||
- 464/UDP
|
||||
|
||||
|
||||
|
||||
``offline_creds_expiration``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This integer controls for how many days cached credentials are valid after the
|
||||
last successful online login. A value of 0 means that there is no limit.
|
||||
|
||||
Also see `cache_creds`_.
|
||||
|
||||
|
||||
``override_homedir``
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This string defines the home directory path to use as expected by sssd's
|
||||
``override_homedir`` option. See :manpage:`sssd.conf(5)` for details.
|
||||
|
||||
Example::
|
||||
|
||||
aaa::override_homedir: '/home/%u'
|
||||
|
||||
|
||||
``sshkeys``
|
||||
~~~~~~~~~~~
|
||||
|
||||
A hash of hashes, each of which contains the parameters as accepted by the
|
||||
`ssh_authorized_key
|
||||
<https://docs.puppet.com/puppet/latest/types/ssh_authorized_key.html>`_ resource
|
||||
type.
|
||||
|
||||
Example::
|
||||
|
||||
aaa::sshkeys:
|
||||
'root@ra':
|
||||
user: 'root'
|
||||
type: 'ssh-dss'
|
||||
key: 'AAAAB3Nz...'
|
||||
|
||||
Keep in mind that this only works if the user's home directory is accessible to
|
||||
root. In particular, it doesn't work if the home is on AFS.
|
||||
|
||||
|
||||
``sssd_debuglevel``
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This integer configures sssd's ``debug_level`` option (see
|
||||
:manpage:`sssd.conf(5)`). It is rarely necessary to use this setting, as the
|
||||
debug level can be changed at runtime using :manpage:`sss_debuglevel(8)`.
|
||||
|
||||
|
||||
``sudo_rules``
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
A list of strings taken from Hiera containing additional sudo rules.
|
||||
Example::
|
||||
|
||||
aaa::sudo_rules:
|
||||
- 'ALL ALL=(ALL) NOPASSWD: /usr/local/bin/add_eaccount.sh'
|
||||
- 'DETGROUP ALL= NOPASSWD: /bin/systemctl'
|
||||
- 'DETGROUP ALL=(ALL) NOPASSWD: /usr/sbin/tcpdump'
|
||||
|
||||
|
||||
|
||||
``support_afs``
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Configure PAM and related tools which are necessary for running AFS.
|
||||
|
||||
|
||||
``use_bastions``
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
This parameter determines whether root logins are only possible from the hosts
|
||||
listed in `bastions`_. Normally the value is taken from the network property of
|
||||
the same name, but this parameter allows overriding the network setting through
|
||||
Hiera or in Puppet manifests.
|
||||
|
||||
|
||||
``users``
|
||||
~~~~~~~~~
|
||||
|
||||
A list of user and/or group names. The users as well as the members of the
|
||||
groups can log in on the system.
|
||||
|
||||
Group names must be prefixed with ``%``.
|
||||
|
||||
Also see `admins`_.
|
||||
|
||||
|
||||
``ssh_authorized_key``
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A hash containing SSH public keys as expected by the ``ssh_authorized_key``
|
||||
Puppet resource.
|
||||
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
||||
The base role includes this profile by default. If you need to customize the
|
||||
profile, do it like this::
|
||||
|
||||
class role::some_role () {
|
||||
class {'role::base':
|
||||
include_aaa => false,
|
||||
...
|
||||
}
|
||||
|
||||
class {'profile::aaa':
|
||||
override_homedir => '/localhomes/%u',
|
||||
create_homes => true,
|
||||
...
|
||||
}
|
||||
...
|
||||
|
||||
|
||||
Implementation Notes
|
||||
--------------------
|
||||
|
||||
|
||||
User/Group Enumeration
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
User/group enumeration happens when using the ``{set,get,end}pwent`` and
|
||||
``{set,get,ent}grent`` APIs to enumerate all users or groups. These are used by
|
||||
``getent passwd`` and ``gentent group`` for example, when not providing a
|
||||
specific user or group to query.
|
||||
|
||||
Enumeration would potentially be very slow and put a high load on the AD domain
|
||||
controllers if it were to return all users/groups from AD. To prevent this, we
|
||||
disable enumeration for AD accounts using the ``enumerate`` setting in
|
||||
:manpage:`sssd.conf(5)`. This means that enumeration using the APIs/programs
|
||||
above only returns local users and groups.
|
||||
|
||||
|
||||
The ``min_id`` issue
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
There are Unix groups in AD at PSI with very low GIDs, the lowest being 101
|
||||
(``unx-fkt``). This leads to problems, because :manpage:`sssd(8)` ignores users
|
||||
and groups with GIDs lower than ``min_id`` (from :manpage:`sssd.conf(5)`), which
|
||||
has a value of 500 by default.
|
||||
|
||||
Therefore we set ``min_id`` to 100. One consequence is that there is overlap
|
||||
between the IDs considered by sssd when querying AD, and the ID range for system
|
||||
users and groups (``[SYS_]ID_{MIN,MAX}``) as defined in
|
||||
:manpage:`login.defs(5)`.
|
||||
|
||||
When creating system groups, :manpage:`groupadd` scans **all** GIDs from
|
||||
``SYS_GID_MAX`` to ``SYS_GID_MIN``. This causes a number of requests to AD,
|
||||
which is usually not a problem but can be, if those take a long time to
|
||||
complete. This used to happen without the ``ad_enabled_domains`` setting for
|
||||
example. ``sssd`` would query ``d.ethz.ch`` in addition to ``d.psi.ch``, which
|
||||
would time out after a few seconds.
|
||||
|
||||
|
||||
PAM details
|
||||
~~~~~~~~~~~
|
||||
|
||||
There have been discussions to move :manpage:`pam_access` to the ``auth``
|
||||
section (from the ``account`` section) to prevent information leakage for
|
||||
accounts that can't even log in: an attacker would get a different error message
|
||||
depending on whether the password was wrong or whether :manpage:`pam_access`
|
||||
didn't allow access.
|
||||
|
||||
The problem is that when using Kerberos authentication, sshd does not use PAM
|
||||
for authentication, circumventing :manpage:`pam_access`. Hence, just moving the
|
||||
latter from ``account`` to ``auth`` does not work.
|
||||
|
||||
|
||||
Kerberos ticket/AFS token renewal
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Kerberos tickets and AFS tokens are automatically renewed for as long as
|
||||
possible. This is done by running a :manpage:`krenew` for every session in the
|
||||
background.
|
||||
|
||||
@@ -0,0 +1,51 @@
|
||||
``profile::afs_client``
|
||||
============================
|
||||
|
||||
This module installs and configures the OpenAFS client.
|
||||
|
||||
On systems using AFS it is necessary to have the AFS kernel module for the
|
||||
running kernel installed. This module installs the AFS kernel module for
|
||||
**every** installed kernel (usually up to 3). Therefore it is recommended to run
|
||||
Puppet after (kernel) updates.
|
||||
|
||||
Note: Simply including this profile is usually **not** enough to enable AFS on a
|
||||
system. It is also necessary to enable AFS support when including
|
||||
``profile::aaa``. The latter makes sure that AD is used for authentication and
|
||||
configures PAM to automatically create and renew AFS tokens.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
=============================== ======== ================================================
|
||||
**Name** **Type** **Default**
|
||||
------------------------------- -------- ------------------------------------------------
|
||||
enable_dynroot bool hiera('afs_client::enable_dynroot')
|
||||
min_cache_size int hiera('afs_client::min_cache_size')
|
||||
mountpoint string hiera('afs_client::mountpoint')
|
||||
root_volume string hiera('afs_client::root_volume')
|
||||
=============================== ======== ================================================
|
||||
|
||||
|
||||
``enable_dynroot``
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
||||
``min_cache_size``
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The minimum size for the local AFS cache. If the cache is smaller than this,
|
||||
Puppet will try to resize the logical volume =lv_openafs=, otherwise Puppet will
|
||||
leave it alone.
|
||||
|
||||
|
||||
``mountpoint``
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
Defines the mountpoint for the AFS filesystem.
|
||||
|
||||
|
||||
``root_volume``
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
The name of the root volume to mount.
|
||||
@@ -0,0 +1,23 @@
|
||||
``profile::autofs``
|
||||
===================
|
||||
|
||||
This profile enables the ``autofs`` service. For normal automounts this is not
|
||||
necessary, as they can be implemented using systemd, but this module can enable
|
||||
the autofs ``-hosts`` map.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
=============================== ======== ================================================
|
||||
**Name** **Type** **Default**
|
||||
------------------------------- -------- ------------------------------------------------
|
||||
install_auto_master bool hiera('autofs::install_auto_master', true)
|
||||
=============================== ======== ================================================
|
||||
|
||||
|
||||
``autofs::install_auto_master``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If this variable is true, the profile will create an ``/etc/auto.master`` file
|
||||
enabling the ``-hosts`` map on ``/net``.
|
||||
@@ -0,0 +1,50 @@
|
||||
``profile::custom_timers``
|
||||
==========================
|
||||
|
||||
This profile is a defined type to define systemd timers together with the corresponding service.
|
||||
|
||||
The resources are defined using the ``systemd::service`` and ``system::service``.
|
||||
The service is defined as type simple and it it has dependency (``Wants`` and ``After``) from
|
||||
the ``network-online.target``.
|
||||
|
||||
|
||||
The defined type is used from ``role::base`` to create the resources
|
||||
defined in the ``base::timers`` hiera hash.
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
=============================== ======== ================================================
|
||||
**Name** **Type** **Default**
|
||||
------------------------------- -------- ------------------------------------------------
|
||||
description String
|
||||
command String
|
||||
on_calendar String
|
||||
timer_options Hash {}
|
||||
service_options Hash {}
|
||||
=============================== ======== ================================================
|
||||
|
||||
|
||||
``description``
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Human-oriented description of the service and timer.
|
||||
|
||||
``command``
|
||||
~~~~~~~~~~~
|
||||
|
||||
Path to the command to invoke into the service. It should be an absolute path
|
||||
and a check is performed against this.
|
||||
|
||||
``on_calendar``
|
||||
~~~~~~~~~~~~~~~
|
||||
The definition of the timer execution time. See `OnCalendar` on :manpage:`systemd.timer(5)`.
|
||||
|
||||
``timer_options``
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
Additional options for the ``[Timer]`` section of the timer unit file, see :manpage:`systemd.timer(5)`.
|
||||
|
||||
``service_options``
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
Additional options for the ``[Service]`` section of the timer related service unit file, see :manpage:`systemd.service(5)`.
|
||||
@@ -0,0 +1,38 @@
|
||||
``profile::dnf_automatic``
|
||||
==========================
|
||||
|
||||
This profile configures automatic package updates using ``dnf-automatic``
|
||||
|
||||
It is used by ``role::base`` and there configured with the ``base::automatic_updates::*`` hiera keys.
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
=============================== ======== ================================================
|
||||
**Name** **Type** **Default**
|
||||
------------------------------- -------- ------------------------------------------------
|
||||
interval Enum
|
||||
type Enum
|
||||
exclude Array
|
||||
incldue_kernel Boolean
|
||||
=============================== ======== ================================================
|
||||
|
||||
|
||||
``interval``
|
||||
~~~~~~~~~~~~
|
||||
How often should the automatic updates be installed. Valid options are ``never``, ``daily`` and ``weekly``. ``never`` disables it altogether.
|
||||
|
||||
|
||||
``type``
|
||||
~~~~~~~~
|
||||
What type of package updates should be installed automatically, either ``security`` for only security updates or ``all`` for all updates.
|
||||
|
||||
|
||||
``exclude``
|
||||
~~~~~~~~~~~
|
||||
List of packages which shall not be updated automatically. Wildcards like * are allowed. The kernel is excluded by default.
|
||||
|
||||
``incldue_kernel``
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
Marks if also the kernel package should be automatically updated. Note that the necessary reboot to run the new kernel needs to be done manually.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
``profile::epics``
|
||||
==================
|
||||
|
||||
Install and configure Epics.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
============ ======== ===========
|
||||
**Name** **Type** **Default**
|
||||
------------ -------- -----------
|
||||
epics_func string -
|
||||
============ ======== ===========
|
||||
|
||||
|
||||
``epics_func``
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
A command written to ``/etc/epics_func.conf``, followed by ``>/dev/null``.
|
||||
@@ -0,0 +1,37 @@
|
||||
``profile::filecopy``
|
||||
=====================
|
||||
|
||||
This module allows to copy file on the host using a git repository as
|
||||
the source.
|
||||
|
||||
The purpose of this module is to distribute files that are not
|
||||
created/configured with other modules, usually files very specific
|
||||
eg. scripts for very specific environments.
|
||||
|
||||
With this module is possible to specifiy only single files, so no
|
||||
directory or recursion is possible.
|
||||
|
||||
The source files are taken from the master branch of a git repo that
|
||||
should be accessible without authentication. Or anyway accessible from
|
||||
the host where the files have to be copied (eg. via a proper ssh key).
|
||||
|
||||
A section like the following in hiera will copy on file ``/tmp/test1``
|
||||
the content of
|
||||
``https://git.psi.ch/talamo_i/copy-file-test/raw/master/abc``::
|
||||
|
||||
filecopy::files:
|
||||
'/tmp/test1':
|
||||
repo: 'talamo_i/copy-file-test'
|
||||
path: 'abc'
|
||||
mode: '0600'
|
||||
owner: 'talamo_i'
|
||||
|
||||
You can additionally specify the group owner of the file:
|
||||
group: 'apache'
|
||||
|
||||
|
||||
This module is included by default and ``filecopy::files`` is empty by
|
||||
default.
|
||||
|
||||
To copy files just define properly the ``filecopy::files`` variable.
|
||||
|
||||
@@ -0,0 +1,45 @@
|
||||
``profile::files``
|
||||
==================
|
||||
|
||||
This profile creates symlinks.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
=============================== ======== ================================================
|
||||
**Name** **Type** **Default**
|
||||
------------------------------- -------- ------------------------------------------------
|
||||
symlinks hash hiera('files::symlinks')
|
||||
directories hash hiera_hash('files::directories')
|
||||
=============================== ======== ================================================
|
||||
|
||||
|
||||
``symlinks``
|
||||
~~~~~~~~~~~~
|
||||
|
||||
A hash specifying symlinks to be created. The keys of the hash are the absolute
|
||||
pathnames of the symlinks, the values of the hash are the corresponding symlink
|
||||
targets.
|
||||
|
||||
Example::
|
||||
|
||||
files::symlinks:
|
||||
'/opt/foo': '/var/lib/foo'
|
||||
|
||||
|
||||
|
||||
``directories``
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
A hash specifying directories to be created. The keys of the hash are the absolute
|
||||
pathnames of the directory, the optional values can be ``owner``, ``group`` (default is ``root`` for both) and the ``mode`` (default ``755``). Parent directories are automatically created with default settings. If that is not desired, do a custom definition for each parent directory too.
|
||||
|
||||
Example::
|
||||
|
||||
files::directories:
|
||||
/etc/test1:
|
||||
/etc/test2/foo/bar:
|
||||
owner: 'buchel_k'
|
||||
group: 'unx-nogroup'
|
||||
mode: '775'
|
||||
@@ -0,0 +1,36 @@
|
||||
``profile::ganglia_client``
|
||||
============================
|
||||
|
||||
This module installs and configures Ganglia's gmond.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
=============================== ======== ================================================
|
||||
**Name** **Type** **Default**
|
||||
------------------------------- -------- ------------------------------------------------
|
||||
grid string hiera('ganglia::grid')
|
||||
cluster string hiera('ganglia_client::cluster')
|
||||
n/a hash hiera('ganglia::grid_${GRID}')
|
||||
=============================== ======== ================================================
|
||||
|
||||
|
||||
``grid``
|
||||
~~~~~~~~
|
||||
|
||||
The name of the Ganglia grid the client is a part of.
|
||||
|
||||
|
||||
``cluster``
|
||||
~~~~~~~~~~~
|
||||
|
||||
The name of the Ganglia cluster within the grid the client is a part of.
|
||||
|
||||
|
||||
``grid_${GRID}``
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
The definition of the grid. See the :doc:`ganglia_server documentation
|
||||
<../profiles/ganglia_server>` for details.
|
||||
|
||||
@@ -0,0 +1,104 @@
|
||||
``profile::ganglia_server``
|
||||
===========================
|
||||
|
||||
This module configures the following Ganglia server components:
|
||||
|
||||
- the web interface (using Apache)
|
||||
- one gmond for each cluster to be monitored by this server
|
||||
|
||||
The latter is a little unusual. Normally, the gmonds collecting the data for
|
||||
each cluster, which are then queried by gmetad, are part of the cluster. The
|
||||
implementation chosen by this module makes it easier to deal with firewalls.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
=============================== ======== ================================================
|
||||
**Name** **Type** **Default**
|
||||
------------------------------- -------- ------------------------------------------------
|
||||
grid string hiera('ganglia::grid')
|
||||
grid_${GRID} hash hiera('ganglia::grid_${GRID}')
|
||||
=============================== ======== ================================================
|
||||
|
||||
|
||||
``grid``
|
||||
~~~~~~~~
|
||||
|
||||
This string identifies the grid (ie the collection of clusters) this server
|
||||
monitors. The definition of the grid is taken from the Hiera value
|
||||
``grid_${GRID}``.
|
||||
|
||||
|
||||
``grid_${GRID}``
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
The definition of the Ganglia grid this server is responsible for. It is a hash
|
||||
containing the following keys:
|
||||
|
||||
|
||||
``name``
|
||||
,,,,,,,,
|
||||
|
||||
The name of the grid as used in the web interface.
|
||||
|
||||
|
||||
``ui``
|
||||
,,,,,,
|
||||
|
||||
The FQDN of the server hosting the web UI and collecting the data for the grid.
|
||||
A system with role ``ganglia_server`` will compare its own FQDN to this value
|
||||
and fail if they are not equal. Clients will need this value to know where they
|
||||
they should send their metrics.
|
||||
|
||||
|
||||
``clusters``
|
||||
,,,,,,,,,,,,
|
||||
|
||||
A hash of cluster definitions. The keys are the IDs of the clusters, ie. what a
|
||||
client expects to find in ``ganglia::cluster``. The values are hashes containing
|
||||
the following attributes:
|
||||
|
||||
``name``
|
||||
........
|
||||
|
||||
The user-friendly name of the cluster to be used in the web UI.
|
||||
|
||||
``port``
|
||||
........
|
||||
|
||||
The port used within the cluster. The first cluster should use 8649 (the Ganglia
|
||||
standard port), the next cluster should use 8650, and so on.
|
||||
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
||||
Suppose we have a Ganglia grid for Swissfel (sysdb_env == swissfel).
|
||||
The we could put the following in Hiera.
|
||||
|
||||
In ``swissfel.yaml`` we would define grid, say ``sfel``, and set the grid for
|
||||
all systems in the ``swissfel`` environment to ``sfel``::
|
||||
|
||||
|
||||
ganglia::grid: 'sfel'
|
||||
|
||||
ganglia::grid_sfel:
|
||||
name: 'SwissFEL'
|
||||
ui: 'gmeta00.psi.ch'
|
||||
clusters:
|
||||
'sf-daqbuf':
|
||||
name: 'DAQ Buffers'
|
||||
port: 8649
|
||||
'sf-athos'
|
||||
name: 'Athos Beamline Systems'
|
||||
port: 8650
|
||||
|
||||
In the ``swissfel/daqbuf.yaml`` we would then set the cluster to ``sf-daqbuf``::
|
||||
|
||||
ganglia::cluster: 'sf-daqbuf'
|
||||
|
||||
In ``swissfel/athos.yaml`` on the other hand, we would set the cluster to
|
||||
``sf-athos``::
|
||||
|
||||
ganglia::cluster: 'sf-athos'
|
||||
@@ -0,0 +1,46 @@
|
||||
``profile::gnome``
|
||||
==================
|
||||
|
||||
This module installs and configures the Gnome desktop environment.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
=============================== ======== ================================================
|
||||
**Name** **Type** **Default**
|
||||
------------------------------- -------- ------------------------------------------------
|
||||
banner_message string
|
||||
enable_update_notifications bool
|
||||
favorites list
|
||||
keyboard_layouts list
|
||||
=============================== ======== ================================================
|
||||
|
||||
|
||||
``banner_message``
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The message displayed above the login prompt.
|
||||
|
||||
|
||||
``enable_update_notifications``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Whether or not ``gnome-software`` is started at the beginning of a session to
|
||||
notify the user about available updates.
|
||||
|
||||
|
||||
``favorites``
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
The applications/directories/etc to be displayed in the *Favorites* menu and/or
|
||||
the Gnome dock. Each member of the list must be a string containing the full
|
||||
name (not path!) of the ``.desktop`` file, eg. ``gnome-terminal.desktop`` for
|
||||
the Gnome Terminal.
|
||||
|
||||
|
||||
``keyboard_layouts``
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A list of the keyboard mappings which should be available on the login screen.
|
||||
The first mapping in the list is the default.
|
||||
@@ -0,0 +1,91 @@
|
||||
``profile::gpfs``
|
||||
=================
|
||||
|
||||
Install and configure the `GPFS parallel file system
|
||||
<https://en.wikipedia.org/wiki/IBM_General_Parallel_File_System>`_.
|
||||
|
||||
The installation also includes the configuration of the rpm repositories.
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
================= ========== ===========
|
||||
**Name** **Type** **Default**
|
||||
----------------- ---------- -----------
|
||||
version string
|
||||
repo_base_url string
|
||||
setup_repos bool true
|
||||
setup_pmsensors bool true
|
||||
setup_pmcollector bool false
|
||||
setup_ces bool false
|
||||
setup_gui bool false
|
||||
fs_opts hash empty hash
|
||||
================= ========== ===========
|
||||
|
||||
|
||||
``version``
|
||||
~~~~~~~~~~~
|
||||
|
||||
The version of GPFS to install.
|
||||
|
||||
|
||||
``repo_base_url``
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
The base URL of the GPFS repositories. Each version of GPFS comes in its own
|
||||
repositories, which are assumed to be located under
|
||||
``${repo_base_url}/${version}/``.
|
||||
|
||||
Repository configuration is subject to `setup_repos`_.
|
||||
|
||||
|
||||
``setup_repos``
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Whether or not to configure the GPFS repositories.
|
||||
|
||||
|
||||
``setup_pmsensors``
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Install packages needed to run the pmsensors service.
|
||||
|
||||
``setup_pmcollector``
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Install packages needed to run the pmcollector service.
|
||||
|
||||
``setup_ces``
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
|
||||
``setup_gui``
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Install packages needed to run the gpfsgui service.
|
||||
|
||||
``fs_opts``
|
||||
~~~~~~~~~~~
|
||||
|
||||
By default a GPFS filesystem will be mounted on all nodes of
|
||||
the cluster with the same option, eg. it will be read-write if
|
||||
the filesystem as been defined with read-write access (see ``mmfs``
|
||||
for the mount options).
|
||||
|
||||
It is possible to override these option on a host specific base
|
||||
configuring a file named ``/var/mmfs/etc/localMountOptions.<filesystem>``
|
||||
with one option per line.
|
||||
|
||||
Please note that even if the parameter is ``fs_opts`` in the code,
|
||||
the hiera variable is called ``fs_mount_opts``.
|
||||
|
||||
The following hiera code can be used to make the ``beamline`` filesystem
|
||||
mounted in read-only mode::
|
||||
|
||||
gpfs::fs_mount_opts:
|
||||
'beamline': ['ro']
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,65 @@
|
||||
``profile::grafana``
|
||||
====================
|
||||
|
||||
This module installs and configures Grafana server.
|
||||
It requires a SSL cert/key since the server will be provided over HTTPS.
|
||||
|
||||
The system uses AD authentication for users and allows anonymous user
|
||||
with view-only capabilities.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
=============================== ======== ================================================
|
||||
**Name** **Type** **Default**
|
||||
------------------------------- -------- ------------------------------------------------
|
||||
vhost string hiera('grafana::vhost', FQDN)
|
||||
servers array hiera('grafana::influxdb_servers')
|
||||
admin_groups array hiera('grafana::admin_groups')
|
||||
editor_groups array hiera('grafana::editor_groups')
|
||||
admin_pw string hiera('grafana::admin_pw')
|
||||
cert string hiera('grafana::tls_cert')
|
||||
key string hiera('grafana::tls_key')
|
||||
=============================== ======== ================================================
|
||||
|
||||
|
||||
``vhost``
|
||||
~~~~~~~~~
|
||||
|
||||
The hostname through which the server will provide http/https service.
|
||||
By default it corresponds to the FQDN, but in case of aliases or Round-Robin DNS it can be different.
|
||||
|
||||
``servers``
|
||||
~~~~~~~~~~~
|
||||
|
||||
A list of influx db servers url to query for data.
|
||||
Each server should be specified with a URL like ``http://hostname:8086``.
|
||||
|
||||
The list of services will be queried to get the list of available databases and
|
||||
the corresponding data sources will be automatically created.
|
||||
The generation of the data sources happens when the list of server files or automatically every day.
|
||||
|
||||
``admin_groups``
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
The list of unix groups that will have full (admin) rights when logging into the server.
|
||||
See `this <http://docs.grafana.org/installation/ldap/>`_ for further details.ls.
|
||||
|
||||
``editor_groups``
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
The list of unix groups that will have editor rights when logging into the server.
|
||||
See `this <http://docs.grafana.org/installation/ldap/>`_ for further details.
|
||||
|
||||
``admin_pw``
|
||||
|
||||
Password of the ``admin`` user.
|
||||
|
||||
``cert``
|
||||
|
||||
SSL public certificate of the HTTPS server.
|
||||
|
||||
``key``
|
||||
|
||||
Private key matching with the SSL certificate.
|
||||
@@ -0,0 +1,15 @@
|
||||
``profile::icewm``
|
||||
==================
|
||||
|
||||
This profile installs and configures the IceWM window manager.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
=============================== ======== ================================================
|
||||
**Name** **Type** **Default**
|
||||
------------------------------- -------- ------------------------------------------------
|
||||
toobar_apps hash hiera('icewm::toolbar::apps', {})
|
||||
menu_apps hash hiera('icewm::menu::apps', {})
|
||||
=============================== ======== ================================================
|
||||
@@ -0,0 +1,41 @@
|
||||
``profile::icinga::checks::gpfs``
|
||||
=================================
|
||||
|
||||
This profile is called when ``gpfs`` is being configured.
|
||||
|
||||
Setup specific checks for GPFS:
|
||||
* It will check that **GPFS** service is running correctly.
|
||||
* Also checks node status with ``mmhealth``.
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
=================== ========== =============================================================
|
||||
**Name** **Type** **Default**
|
||||
------------------- ---------- -------------------------------------------------------------
|
||||
check_unhealth_only Boolean ``icinga::checks::options::gpfs::ignoretips:`` **``true``**
|
||||
check_ignore_tips Boolean ``icinga::checks::options::gpfs::unhealth:`` **``false``**
|
||||
=================== ========== =============================================================
|
||||
|
||||
``check_unhealth_only``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
By default ``mmhealth`` is called with the option ``--unhealth``. This shows only **unhealthy** problems. This can be disabled
|
||||
by setting ``icinga::checks::options::gpfs::unhealth: false``, in this case ``mmhealth`` will also report about **healthy** checks.
|
||||
|
||||
|
||||
``check_ignore_tips``
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
**TIPS** errors are considered ``[WARNING]`` by default. As these are configuration tips, some admins can consider that tips are ``[OK]``
|
||||
in their clusters. This behaviour can be changed by setting ``icinga::checks::options::gpfs::ignoretips: true``, which will consider **TIPS** as ``[OK]``.
|
||||
|
||||
Facts
|
||||
-----
|
||||
|
||||
When some specific facts are detected, it will trigger some actions.
|
||||
|
||||
===================================== =============== ==============================================
|
||||
**Fact** **Value(s)** **Action description**
|
||||
------------------------------------- --------------- ----------------------------------------------
|
||||
===================================== =============== ==============================================
|
||||
@@ -0,0 +1,29 @@
|
||||
``profile::icinga::checks::hp::smart_array``
|
||||
============================================
|
||||
|
||||
This profile is automatically called when a HP Smart Array is detected through facter from the
|
||||
``profile::platform::hewlett_packard`` class.
|
||||
|
||||
Setup checks for HP Smart Arrray.
|
||||
* Will setup a check executing ``ssacli`` in order to check the following components:
|
||||
* **Controller(s)** status, **Cache** status (when configured) & **Battery** status (when present)
|
||||
* **Logical Drive(s)** status
|
||||
* **Physical Drive(s)** status
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
================= ========== =========================================================
|
||||
**Name** **Type** **Default**
|
||||
----------------- ---------- ---------------------------------------------------------
|
||||
================= ========== =========================================================
|
||||
|
||||
Facts
|
||||
-----
|
||||
|
||||
When some specific facts are detected, it will trigger some actions.
|
||||
|
||||
===================================== =============== ==============================================
|
||||
**Fact** **Value(s)** **Action description**
|
||||
------------------------------------- --------------- ----------------------------------------------
|
||||
===================================== =============== ==============================================
|
||||
@@ -0,0 +1,31 @@
|
||||
``profile::icinga::checks::nvidia``
|
||||
========================================
|
||||
|
||||
This profile is called when ``nvidia`` is being configured through ``cuda``
|
||||
|
||||
Setup specific checks for the Puppet Client:
|
||||
* It will check that ``nvidia-smi`` correctly responds with the NVIDIA GPU cards.
|
||||
When kernel is updated, it may cause to boot up with the NVIDIA drivers.
|
||||
|
||||
It will return OK and the list of GPUS when ``nvidia-smi`` correctly answers.
|
||||
It will return CRITICAL and the error message when ``nvidia-smi`` is unable to detect GPU cards.
|
||||
|
||||
Most probably in the future drivers will be directly checked.
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
================== ========== =============================================================
|
||||
**Name** **Type** **Default**
|
||||
------------------ ---------- -------------------------------------------------------------
|
||||
================== ========== =============================================================
|
||||
|
||||
Facts
|
||||
-----
|
||||
|
||||
When some specific facts are detected, it will trigger some actions.
|
||||
|
||||
===================================== =============== ==============================================
|
||||
**Fact** **Value(s)** **Action description**
|
||||
------------------------------------- --------------- ----------------------------------------------
|
||||
===================================== =============== ==============================================
|
||||
@@ -0,0 +1,33 @@
|
||||
``profile::icinga::checks::puppet_client``
|
||||
==========================================
|
||||
|
||||
This profile is called when ``puppet`` client is being configured.
|
||||
|
||||
Setup specific checks for the Puppet Client:
|
||||
* It will check that the current running environment is ``puppet_environment``.
|
||||
Otherwise it will return a **nagios** ``WARNING`` message and error.
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
================== ========== =============================================================
|
||||
**Name** **Type** **Default**
|
||||
------------------ ---------- -------------------------------------------------------------
|
||||
puppet_environment String hiera('icinga::checks::options::puppet_environment',**prod**)
|
||||
================== ========== =============================================================
|
||||
|
||||
``puppet_environment``
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This setting defaults to the puppet environment ``prod``. Can be changed from YAML by setting
|
||||
``icinga::checks::options::puppet_environment`` to a different value.
|
||||
|
||||
Facts
|
||||
-----
|
||||
|
||||
When some specific facts are detected, it will trigger some actions.
|
||||
|
||||
===================================== =============== ==============================================
|
||||
**Fact** **Value(s)** **Action description**
|
||||
------------------------------------- --------------- ----------------------------------------------
|
||||
===================================== =============== ==============================================
|
||||
@@ -0,0 +1,36 @@
|
||||
``profile::icinga::checks::service``
|
||||
====================================
|
||||
|
||||
This class will configure Nagios checks for one or more ``systemctl`` services. This can be done by setting
|
||||
a list of services with the ``icinga::checks::service::list`` *hiera* setting. ``check_service`` is the
|
||||
script that will be in charge for that, which is also used by other Nagios scripts (i.e. ``check_slurm`` &
|
||||
``check_gpfs``) to check specific services for these alarms.
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
===================== ========== =========================================================================
|
||||
**Name** **Type** **Default**
|
||||
--------------------- ---------- -------------------------------------------------------------------------
|
||||
service_list Array ``'icinga::checks::service::list'``, defaults to ``'[]'``
|
||||
===================== ========== =========================================================================
|
||||
|
||||
``service_list``
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
The default value is an empty ``Array`` (``'[]'``). Hence, no ``systemctl`` services are checked.
|
||||
This value can be overwritten with a list of services. In example::
|
||||
|
||||
icinga::checks::service::list:
|
||||
- ntpd
|
||||
- postfix
|
||||
|
||||
Facts
|
||||
-----
|
||||
|
||||
When some specific facts are detected, it will trigger some actions.
|
||||
|
||||
===================================== =============== ==============================================
|
||||
**Fact** **Value(s)** **Action description**
|
||||
------------------------------------- --------------- ----------------------------------------------
|
||||
===================================== =============== ==============================================
|
||||
@@ -0,0 +1,87 @@
|
||||
``profile::icinga::checks::slurm``
|
||||
==========================================
|
||||
|
||||
This profile should be called when **Slurm** (server, cn, ui) is being configured.
|
||||
|
||||
Setup specific checks for Slurm nodes:
|
||||
* It can check ``slurmd`` service. This check makes sense on computing nodes running ``slurmd``.
|
||||
* It can check ``munge`` service. This check makes sense on any node with a configured **Slurm** client/server.
|
||||
* It can check ``slurmctld`` service. This check makes sense on server nodes, will disable ``slurmd`` check.
|
||||
* It can check ``slurmdbd`` service. This check makes sense on server nodes.
|
||||
* It can check ``sinfo`` status, detecting miss-behaving nodes.
|
||||
|
||||
By default, since the most common node in a **Slurm** cluster is a computing node, this check will report about
|
||||
``slurmd`` and ``munge`` status.
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
===================== ========== =========================================================================
|
||||
**Name** **Type** **Default**
|
||||
--------------------- ---------- -------------------------------------------------------------------------
|
||||
skip_munge Boolean ``icinga::checks::options::slurm::skip_munge`` **``false``**
|
||||
skip_slurmd Boolean ``icinga::checks::options::slurm::skip_slurmd``: **``false``**
|
||||
check_slurmdbd Boolean ``icinga::checks::options::slurm::check_slurmdbd`` **``false``**
|
||||
check_slurmctld Boolean ``icinga::checks::options::slurm::check_slurmctld`` **``false``**
|
||||
ignore_draining Boolean ``icinga::checks::options::slurm::ignore_draining`` **``false``**
|
||||
ignore_drained Boolean ``icinga::checks::options::slurm::ignore_drained`` **``false``**
|
||||
check_nodes Boolean ``icinga::checks::options::slurm::check_nodes`` **``false``**
|
||||
no_reason Boolean ``icinga::checks::options::slurm::no_reason`` **``true``**
|
||||
no_timestamp Boolean ``icinga::checks::options::slurm::no_timestamp`` **``false``**
|
||||
===================== ========== =========================================================================
|
||||
|
||||
``skip_munge``
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
By default ``munge`` service is checked. Can be disabled by setting ``icinga::checks::options::slurm::skip_munge: false``.
|
||||
|
||||
``skip_slurmd``
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
By default ``slurmd`` service is checked. Can be disabled by setting ``icinga::checks::options::slurm::skip_slurmd: false``.
|
||||
|
||||
|
||||
``check_slurmdbd``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
By default ``slurmdbd`` service is disabled. Can be enabled by setting ``icinga::checks::options::slurm::check_slurmdbd: true``.
|
||||
|
||||
``check_slurmctld``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
By default ``slurmctld`` service is disabled. Can be enabled by setting ``icinga::checks::options::slurm::check_slurmctld: true``, in this case ``icinga::checks::options::slurm::skip_slurmd``
|
||||
should be also set to ``true``.
|
||||
|
||||
`ignore_draining``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
By default nodes in ``draining`` state are checked and will be reported as ``[WARNING]``. This can be disabled by setting ``icinga::checks::options::slurm::ignore_draining: true``.
|
||||
When set to ``true``, ``draining`` nodes will be reported anyway but will be considered as ``[OK]``
|
||||
|
||||
``ignore_drained``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
By default nodes in ``drained`` state are checked and will be reported as ``[WARNING]``. This can be disabled by setting ``icinga::checks::options::slurm::ignore_drained: true``.
|
||||
When set to ``true``, ``drained`` nodes will be reported anyway but will be considered as ``[OK]``
|
||||
|
||||
``no_reason``
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
By default **no** ``Reason`` is reported. This is because it will add extra text to the alarm output when nodes are ``drained``/``draining``/``down``/``failed``.
|
||||
Printing ``Reason`` can be turned on by setting ``icinga::checks::options::slurm::no_reason: false``.
|
||||
|
||||
``no_timestamp``
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
By default ``Timestamp`` is being reported. Timestamp shows the date and time when a node was set ``drained``/``draining``/``down``/``failed``.
|
||||
As this setting adds extra text in the alarm, it can be disabled by setting ``icinga::checks::options::slurm::no_reason: true``.
|
||||
|
||||
Facts
|
||||
-----
|
||||
|
||||
When some specific facts are detected, it will trigger some actions.
|
||||
|
||||
===================================== =============== ==============================================
|
||||
**Fact** **Value(s)** **Action description**
|
||||
------------------------------------- --------------- ----------------------------------------------
|
||||
===================================== =============== ==============================================
|
||||
@@ -0,0 +1,50 @@
|
||||
``profile::icinga::client``
|
||||
===========================
|
||||
|
||||
This profile installs and configured the ``nrpe`` service:
|
||||
* Installs ``mod_gearman-static``, ``nrpe-selinux``, ``nrpe``
|
||||
* Instals Nagios plugins: ``nagios-plugins-disk``, ``nagios-plugins-load``
|
||||
* Manages the NRPE service and ensures that is ``running`` and ``enabled``
|
||||
* Allows to configure the ``nrpe.cfg`` file with the ``icinga::client::servers`` setting which defaults to ``[ 'emonma00.psi.ch','wmonag00.psi.ch','emonag00.psi.ch' ]`` (default value on fresh *nrpe* installations)
|
||||
* SELinux policy setup to allow ``nagios_run_sudo``.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
================= ========== =========================================================
|
||||
**Name** **Type** **Default**
|
||||
----------------- ---------- ---------------------------------------------------------
|
||||
servers Array hiera('icinga::client::servers')
|
||||
blame Array hiera('icinga::client::dont_blame_nrpe', 0)
|
||||
================= ========== =========================================================
|
||||
|
||||
``servers``
|
||||
~~~~~~~~~~~
|
||||
|
||||
The local parameter for ``icinga::client::servers`` is ``servers``. Defaults to ``[ 'emonma00.psi.ch','wmonag00.psi.ch','emonag00.psi.ch' ]``
|
||||
which is the default value in the ``nrpe.cfg`` file on fresh ``nrpe`` installations. Somebody can
|
||||
overwrite this value with a new ``Array`` of Icinga servers. This ``Array`` will be converted to ``String``
|
||||
afterwards::
|
||||
|
||||
...
|
||||
Array $servers = hiera('icinga::client::servers'),
|
||||
...
|
||||
$icinga_servers = join($servers,",")
|
||||
...
|
||||
|
||||
``blame``
|
||||
~~~~~~~~~
|
||||
|
||||
With this option, the NRPE will allow clients to specify arguments in the commands. By default this is ``disabled``: arguments must be
|
||||
specified in the NRPE daemon side and not from the client side. This option modifies the setting ``dont_blame_nrpe`` in the ``nrpe.cfg`` file.
|
||||
|
||||
Facts
|
||||
-----
|
||||
|
||||
When some specific facts are detected, it will trigger some actions.
|
||||
|
||||
===================================== =============== ==============================================
|
||||
**Fact** **Value(s)** **Action description**
|
||||
------------------------------------- --------------- ----------------------------------------------
|
||||
===================================== =============== ==============================================
|
||||
@@ -0,0 +1,55 @@
|
||||
``profile::icinga::nrpe``
|
||||
=========================
|
||||
|
||||
This profile is a function that configures ``nrpe`` and ``sudoers`` (whenever needed) for a specific command:
|
||||
* Will create a ``/etc/nrpe.d/<filename>.cfg`` file for ``nrpe``
|
||||
* Will create a ``/etc/sudoers.d/<filename>`` file for ``sudoers`` (if ``sudo`` is required)
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
====================== ========== =========================================================
|
||||
**Name** **Type** **Default**
|
||||
---------------------- ---------- ---------------------------------------------------------
|
||||
command String
|
||||
sudo Boolean ``false``
|
||||
notifications_enabled Boolean ``true``
|
||||
====================== ========== =========================================================
|
||||
|
||||
``command``
|
||||
~~~~~~~~~~~
|
||||
|
||||
Full path for the command to be configured in the ``nrpe.d`` file. This will be translated
|
||||
in the ``nrpe.d`` as::
|
||||
|
||||
# sudo = true
|
||||
command[${title}]=/usr/bin/sudo ${command}
|
||||
|
||||
# sudo = false
|
||||
command[${title}]=${command}
|
||||
|
||||
``sudo``
|
||||
~~~~~~~~
|
||||
|
||||
Whether ``sudo`` is required or not for that command. By default is ``false``.
|
||||
When set to ``true``, ``/usr/bin/sudo`` will be added to the ``nrpe`` command, and proper
|
||||
``sudoers`` file will be configured. Example::
|
||||
|
||||
Defaults:nrpe !requiretty
|
||||
nrpe ALL=(root) NOPASSWD: ${command}
|
||||
|
||||
``notifications_enables``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Currently this settings has no effect. Will be used when exporting Nagios resources to the PuppetDB.
|
||||
Please ignore it in the meantime.
|
||||
|
||||
Facts
|
||||
-----
|
||||
|
||||
When some specific facts are detected, it will trigger some actions.
|
||||
|
||||
===================================== =============== ==============================================
|
||||
**Fact** **Value(s)** **Action description**
|
||||
------------------------------------- --------------- ----------------------------------------------
|
||||
===================================== =============== ==============================================
|
||||
@@ -0,0 +1,53 @@
|
||||
``profile::infiniband``
|
||||
=======================
|
||||
|
||||
Installs and configures the Infiniband software stack.
|
||||
|
||||
* New service ``ib-online`` is being installed, which will wait until IB gets online. The script ``/opt/pli/libexec/ib-check-active-ports`` is used for that.
|
||||
* Setup of the ``/etc/sysconfig/network-scripts/ifcfg-${ib_ifname}`` files.
|
||||
* Installation of ``/usr/local/bin/mlxup`` which is useful for checking firmware version and upgrade Mellanox IB cards directly from Mellanox.
|
||||
* OFED repository + installation of the following packages: ``ibutils``, ``infiniband-diags``, ``mlnx-ofed-basic``, ``librdmacm-devel``, ``perftest``, ``infinipath-psm``
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
========== ========= ==========================
|
||||
**Name** **Type** **Default**
|
||||
---------- --------- --------------------------
|
||||
ib_ifname string *undef*
|
||||
ib_ip string *undef*
|
||||
ib_subnet string *undef*
|
||||
repo_tag String *yum_client::repo_tag*
|
||||
ofed_vers String *infiniband::ofed_version*
|
||||
========== ========= ==========================
|
||||
|
||||
|
||||
``ib_ifname``
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
The name of the Infiniband interface.
|
||||
|
||||
|
||||
``ib_ip``
|
||||
~~~~~~~~~
|
||||
|
||||
The IP to be configured on the Infiniband interface.
|
||||
|
||||
|
||||
``ib_subnet``
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
The subnet to be used on the Infiniband interface in CIDR notation.
|
||||
|
||||
|
||||
``repo_tag``
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Which ``yum`` ``repo_tag`` should be used. In example, ``latest`` can be used.
|
||||
|
||||
|
||||
``ofed_vers``
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
OFED version to be installed and configured. Format: ``X.Y-A.B.C.D``, where X.Y is the major OFED version and
|
||||
A.B.C.D is the subversion.
|
||||
@@ -0,0 +1,138 @@
|
||||
``profile::jupyterhub``
|
||||
=======================
|
||||
|
||||
This module configures the node for running a jupyterhub service
|
||||
able to spawn singleuser servers on cluster nodes via SLURM
|
||||
|
||||
The jupyterhub software itself will not be installed by this
|
||||
module. It is expected to be found in an existing environment
|
||||
usually installed separately by ``conda`` and centrally served on a
|
||||
distributed file system (There is a reference installation in the
|
||||
environment module ``anaconda/2019.03`` within the
|
||||
``jupyterhub_dev_py36`` conda environment)
|
||||
|
||||
Supported jupyterhub versions: jupyterhub-0.96 or the current
|
||||
(as of 2019-05) development version 1.0.0b1. The development version is preferred
|
||||
due to recent fixes that enable a clean shutdown on a batch cluster.
|
||||
|
||||
Optional customization of User selectable options
|
||||
-------------------------------------------------
|
||||
|
||||
This installation uses the `optionsSpawner <https://github.com/ResearchComputing/jupyterhub-options-spawner>`_ plugin to offer user selectable
|
||||
customizations on the spawning web page. By default, a simple dialog
|
||||
with selectable partitions and runtime is offered. If a more extended
|
||||
customization page is required, the administrator can create the file
|
||||
``/etc/jupyterhub/optionsspawner_config.py`` and put additional options inside.
|
||||
The jupyterhub main configuration file ``/etc/jupyterhub/jupyterhub_config.py``
|
||||
will check whether the file exists and load it. In this way we can
|
||||
keep the puppet module more generic.
|
||||
|
||||
Some adaptions may require deeper changes to the configuration file
|
||||
and adaption of the puppet code
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
=============================== ======== ================================================
|
||||
**Name** **Type** **Default**
|
||||
------------------------------- -------- ------------------------------------------------
|
||||
admin_users Array hiera('jupyterhub\:\:admin_users')
|
||||
api_port Integer hiera('jupyterhub\:\:api_port', 8080)
|
||||
env_setup String hiera('jupyterhub\:\:env_setup')
|
||||
group_whitelist Array hiera('jupyterhub\:\:group_whitelist')
|
||||
hub_port Integer hiera('jupyterhub\:\:hub_port', 8000)
|
||||
hub_version String hiera('jupyterhub\:\:hub_version')
|
||||
partitions Hash hiera('jupyterhub\:\:partitions')
|
||||
tls_cert String hiera('jupyterhub\:\:tls_cert')
|
||||
tls_key String hiera('jupyterhub\:\:tls_key')
|
||||
=============================== ======== ================================================
|
||||
|
||||
|
||||
|
||||
``admin_users``
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
A list of user names. These users will get access to the jupyterhub administration
|
||||
web pages.
|
||||
|
||||
Example:
|
||||
|
||||
::
|
||||
|
||||
jupyterhub::admin_users:
|
||||
- 'feichtinger'
|
||||
- 'caubet_m'
|
||||
- 'bliven_s'
|
||||
- 'loktionova_n'
|
||||
|
||||
``api_port``
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Port number of the port on which the jupyterhub API will be listening (internally
|
||||
used by jupyterhub for control communications)
|
||||
|
||||
``env_setup``
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Lines to be inserted into the bash scripts for defining the
|
||||
jupyterhub environment for both the server and the spawned client
|
||||
sessions (it is important that the server and the singleserver
|
||||
client host both run the same jupyterhub and spawner codes)
|
||||
|
||||
Example:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
export PMODULES_VERSION=1.0.0rc4
|
||||
source /opt/psi/config/profile.bash
|
||||
module use unstable &> /dev/null
|
||||
module load anaconda/2019.03 &> /dev/null
|
||||
conda activate jupyterhub_dev
|
||||
|
||||
``group_whitelist``
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A list of unix groups that will be granted access to this jupyterhub.
|
||||
|
||||
Example:
|
||||
|
||||
::
|
||||
|
||||
jupyterhub::group_whitelist:
|
||||
- 'svc-cluster_merlin5'
|
||||
|
||||
``hub_port``
|
||||
~~~~~~~~~~~~
|
||||
|
||||
The main port to which clients will connect.
|
||||
|
||||
``hub_version``
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Version String of jupyterhub. Currently either '0.96' or '1.0.0b2' is
|
||||
supported. Recommended: '1.0.0b2'.
|
||||
|
||||
partitions
|
||||
~~~~~~~~~~
|
||||
|
||||
SLURM partitions to be offered in the default option selection. Should be
|
||||
a mapping of partition names to descriptive strings.
|
||||
|
||||
Example:
|
||||
|
||||
::
|
||||
|
||||
jupyterhub::partitions:
|
||||
'test' : 'Test nodes'
|
||||
'merlin' : 'merlin standard'
|
||||
'gpu' : 'GPU nodes'
|
||||
|
||||
tls_cert
|
||||
~~~~~~~~
|
||||
|
||||
String (PEM Format) of the web server certificate
|
||||
|
||||
tls_key
|
||||
~~~~~~~
|
||||
|
||||
Eyaml encoded string of the web server certificate key (PEM format)
|
||||
@@ -0,0 +1,42 @@
|
||||
``profile::kdump_client``
|
||||
=========================
|
||||
|
||||
This profile manages the ``kdump`` service. It automatically reserves memory for
|
||||
the crash kernel.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
=========== ======== ================================================
|
||||
**Name** **Type** **Default**
|
||||
----------- -------- ------------------------------------------------
|
||||
crashkernel string hiera('kdump_client::crashkernel')
|
||||
target string hiera('kdump_client::target')
|
||||
=========== ======== ================================================
|
||||
|
||||
|
||||
``crashkernel``
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Configures the kernel parameter ``crashkernel``, which specifies the amount of
|
||||
memory to be reserved for the crash kernel. This can be ``auto`` or ``xxxM``.
|
||||
Further information is provided by `Red Hat
|
||||
<https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s1-kdump-configuration.html>`_.
|
||||
|
||||
|
||||
``target``
|
||||
~~~~~~~~~~
|
||||
|
||||
The target for kernel dumps as documented in ``kdump.conf(5)``. Currently SSH
|
||||
targets do not work, as there is no way to specify an SSH key.
|
||||
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
||||
Transfer kernel dumps to a remote server using NFS::
|
||||
|
||||
class {'kdump':
|
||||
target => 'nfs some-server.psi.ch/crashes/',
|
||||
}
|
||||
@@ -0,0 +1,102 @@
|
||||
``profile::local_accounts``
|
||||
===========================
|
||||
|
||||
This module helps managing local users and groups.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
=============================== ======== ================================================
|
||||
**Name** **Type** **Default**
|
||||
------------------------------- -------- ------------------------------------------------
|
||||
group_defs hash hiera('local_accounts::group_defs')
|
||||
groups hash hiera('local_accounts::groups')
|
||||
user_defs hash hiera('local_accounts::user_defs')
|
||||
users list hiera('local_accounts:users')
|
||||
=============================== ======== ================================================
|
||||
|
||||
|
||||
``group_defs``
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
A hash containing the definitions of local groups. The keys are the group names,
|
||||
the values are the numeric group IDs.
|
||||
|
||||
|
||||
Example::
|
||||
|
||||
local_accounts::group_defs:
|
||||
'my_local_group': 673
|
||||
|
||||
Also see `groups`_.
|
||||
|
||||
|
||||
``groups``
|
||||
~~~~~~~~~~
|
||||
|
||||
A list containing the names of the local groups to be created. The definition
|
||||
for each group is taken from `group_defs`_.
|
||||
|
||||
|
||||
``user_defs``
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
A hash containing the definitions of local users. The keys are the user names,
|
||||
the values are hashes containing the usual user properties, ie:
|
||||
|
||||
============ ==========================
|
||||
``password`` password hash (optional)
|
||||
``uid`` numeric UID (required)
|
||||
``gid`` numeric GID (required)
|
||||
``comment`` comment (optional)
|
||||
``home`` home directory (required)
|
||||
``shell`` shell (required)
|
||||
============ ==========================
|
||||
|
||||
Ideally the password hash is generated with ``openssl passwd -6`` and then encrypted as in chapter "Example: Encrypting password" :doc:`../hiera`
|
||||
|
||||
|
||||
``users``
|
||||
~~~~~~~~~
|
||||
|
||||
A list of the users to be created. The definition of each user is taken from
|
||||
`user_defs`_.
|
||||
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
||||
The following defines three users and one group, but only creates one each::
|
||||
|
||||
local_accounts::group_defs:
|
||||
'archadm': 503
|
||||
|
||||
local_accounts::user_defs:
|
||||
'ioc':
|
||||
'uid': 500
|
||||
'gid': 9102
|
||||
'home': '/home/ioc'
|
||||
'shell': '/bin/bash'
|
||||
'comment': 'IOC Account'
|
||||
|
||||
'slsop':
|
||||
'uid': 501
|
||||
'gid': 9102
|
||||
'home': '/home/slsop'
|
||||
'shell': '/bin/bash'
|
||||
'comment': 'SLS Operator'
|
||||
|
||||
'archadm':
|
||||
'uid': 503
|
||||
'gid': 503
|
||||
'home': '/home/archadm'
|
||||
'shell': '/bin/bash'
|
||||
'comment': ''
|
||||
'password': 'ENC[PKCS7,MIIB2gYxxxxxx...xxxxxxx]'
|
||||
|
||||
local_accounts::groups:
|
||||
- 'archadm'
|
||||
|
||||
local_accounts::users:
|
||||
- 'archadm'
|
||||
@@ -0,0 +1,93 @@
|
||||
``profile::log_client``
|
||||
=======================
|
||||
|
||||
This module manages the local logging-related configuration.
|
||||
|
||||
It can make the journal permanent, enable or disable legacy configuration files
|
||||
(e.g. ``/var/log/messages``), and configure log forwarding.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
============================ ======== ==================================================
|
||||
**Name** **Type** **Default**
|
||||
---------------------------- -------- --------------------------------------------------
|
||||
forward_to list hiera('log_client::forward_to', [])
|
||||
legacy_logs bool hiera('log_client::legacy_logs')
|
||||
persistent_journal bool hiera('log_client::persistent_journal')
|
||||
journal_system_keep_free string hiera('log_client::journal_system_keep_free')
|
||||
journal_system_max_file_size string hiera('log_client::journal_system_max_file_size')
|
||||
journal_system_max_use string hiera('log_client::journal_system_max_use')
|
||||
============================ ======== ==================================================
|
||||
|
||||
|
||||
``journal_system_keep_free``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
How much space `systemd-journald(8) <https://www.freedesktop.org/software/systemd/man/systemd-journald.html>`_ should keep free for non-journal
|
||||
use in ``/var/log``. In addition to the syntax described in
|
||||
`journald.conf(5) <https://www.freedesktop.org/software/systemd/man/journald.conf.html#SystemMaxUse=>`_ (bytes or use K, M, G, T, P, E as units) we also support percentages, ie ``'25%'`` means that
|
||||
the journal will leave at least 25% of ``/var/log`` for other uses.
|
||||
Note that for the use of a percentage limit ``/var/log`` must be an separate partition, else absolute values need to be set.
|
||||
|
||||
|
||||
``journal_system_max_file_size``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The maximum size of individual journal files.
|
||||
|
||||
|
||||
``journal_system_max_use``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The maximum amount of space that the journal is allowed to use. In addition to
|
||||
the syntax described in `journald.conf(5) <https://www.freedesktop.org/software/systemd/man/journald.conf.html#SystemMaxUse=>`_ (bytes or use K, M, G, T, P, E as units) we also support percentages,
|
||||
ie ``'50%'`` means that the journal can use at most 50% of ``/var/log``.
|
||||
Note that for the use of a percentage limit ``/var/log`` must be an separate partition, else absolute values need to be set.
|
||||
|
||||
|
||||
``forward_to``
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
An array of FQDNs, possibly prefixed with ``@`` for enabling TCP and followed by
|
||||
a port number. Log messages are forwarded to all entries in this list.
|
||||
|
||||
|
||||
``legacy_logs``
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
A boolean controlling whether the legacy log files (``/var/log/messages`` etc)
|
||||
should be created (true) or not (false).
|
||||
|
||||
|
||||
``persistent_journal``
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A boolean controlling whether the journal should be persistent (true) or not
|
||||
(false).
|
||||
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
||||
This profile is included in the base role. To customize the log_client in a
|
||||
role, do this::
|
||||
|
||||
class role::some_role () {
|
||||
class {'role::base':
|
||||
include_log_client => false,
|
||||
...
|
||||
}
|
||||
|
||||
class {'profile::log_client':
|
||||
legacy_logs => false,
|
||||
persistent_journal => true,
|
||||
}
|
||||
|
||||
In Hiera, configure forwarding to ``log1`` using UDP on port 1514 and to
|
||||
``log2`` using TCP (on port 514)::
|
||||
|
||||
log_client::forward_to:
|
||||
- 'log1.psi.ch:1514'
|
||||
- '@log2.psi.ch'
|
||||
@@ -0,0 +1,25 @@
|
||||
``profile::log_server``
|
||||
=============================
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
======== ========= =================================
|
||||
**Name** **Type** **Default**
|
||||
-------- --------- ---------------------------------
|
||||
base_dir string hiera('log_server::base_log_dir')
|
||||
rules list hiera('log_server::rules')
|
||||
======== ========= =================================
|
||||
|
||||
|
||||
``base_dir``
|
||||
~~~~~~~~~~~~
|
||||
|
||||
This parameter designates the directory where the log data is stored.
|
||||
|
||||
|
||||
``rules``
|
||||
~~~~~~~~~
|
||||
|
||||
A list of rules to add to the end of ``/etc/rsyslog.conf``.
|
||||
@@ -0,0 +1,107 @@
|
||||
``profile::mkresource::files``
|
||||
==============================
|
||||
|
||||
``profile::mkresource::files`` is a puppet ``define`` (a.k.a. ``function``) which easily allows the creation of files
|
||||
through the puppet ``file`` resource (through the ``create_resources`` puppet function.
|
||||
|
||||
This ``define`` is intended to be called in a controlled way from a ``role`` or from another ``profile``, through an ``Array``
|
||||
list. However, it also allows the possibility to provide freedom by calling it through a ``Hash`` of files. Further information
|
||||
is explained below":
|
||||
|
||||
* ``Array``: In order to have more control on the files that are being created. In example::
|
||||
|
||||
# Begin: puppet class
|
||||
class role::hpc::ui (
|
||||
Array $scratch = hiera('base::scratch', []),
|
||||
...
|
||||
) {
|
||||
...
|
||||
profile::mkresource::files { "scratch":
|
||||
files => $scratch,
|
||||
defaults => { mode => '1777' };
|
||||
}
|
||||
...
|
||||
}
|
||||
# End: puppet class
|
||||
|
||||
# Begin: hiera call
|
||||
base::scratch:
|
||||
- '/scratch'
|
||||
- '/ssd-scratch'
|
||||
# End: hiera call
|
||||
|
||||
* ``Hash``: This will provide more flexibility from the user side. Only really strange cases will be allowed. Example::
|
||||
|
||||
# Begin: puppet class
|
||||
class role::hpc::ui (
|
||||
Array $scratch = hiera('base::scratch', {}),
|
||||
...
|
||||
) {
|
||||
...
|
||||
profile::mkresource::files { "scratch":
|
||||
files => $scratch;
|
||||
}
|
||||
...
|
||||
}
|
||||
# End: puppet class
|
||||
|
||||
# Begin: hiera call
|
||||
base::scratch:
|
||||
'/scratch':
|
||||
ensure: directory
|
||||
mode: '1777'
|
||||
owner: 'root'
|
||||
group: 'root'
|
||||
'/ssd-scratch'
|
||||
ensure: directory
|
||||
mode: '1770'
|
||||
group: 'svc-cluster_merlin5'
|
||||
# End: hiera call
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
========== ==================== ==========================
|
||||
**Name** **Type** **Default**
|
||||
---------- -------------------- --------------------------
|
||||
$files Variant[Array, Hash] {}
|
||||
$defaults Hash {}
|
||||
========== ==================== ==========================
|
||||
|
||||
|
||||
``files``
|
||||
~~~~~~~~~
|
||||
Defaults to ``Hash`` type ``{}``. Whenever is an ``Array``, it will be converted to ``Hash`` as ``create_resources`` is used and
|
||||
it always expects a ``Hash``.
|
||||
|
||||
Two different call examples:
|
||||
|
||||
* ``Hash``::
|
||||
|
||||
base::scratch:
|
||||
'/scratch':
|
||||
ensure: directory
|
||||
mode: '1777'
|
||||
owner: 'root'
|
||||
group: 'root'
|
||||
'/ssd-scratch'
|
||||
ensure: directory
|
||||
mode: '1770'
|
||||
group: 'svc-cluster_merlin5'
|
||||
|
||||
* ``Array``::
|
||||
|
||||
base::scratch:
|
||||
- '/scratch'
|
||||
- '/ssd-scratch'
|
||||
|
||||
``defaults``
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Defaults to empty ``Hash``. Should contain ``file`` resource parameters (in example, ``mode``, ``owner``, ``group``, ``ensure``, etc.)
|
||||
Example::
|
||||
|
||||
profile::mkresource::files { "scratch":
|
||||
files => [ '/scratch', '/ssd-scratch' ],
|
||||
defaults => { mode => '1777' };
|
||||
}
|
||||
@@ -0,0 +1,220 @@
|
||||
``profile::mounter``
|
||||
====================
|
||||
|
||||
This module manages mounts and installs filesystem-specific utilities.
|
||||
|
||||
Mounts are configured using the Puppet ``mount`` resource type, ie. they get
|
||||
added to ``/etc/fstab``. Auto-mounts are implemented by adding the
|
||||
``x-systemd.automount`` option.
|
||||
|
||||
The directory of the mount point is automatically created when missing.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
=============================== ======== ================================================
|
||||
**Name** **Type** **Default**
|
||||
------------------------------- -------- ------------------------------------------------
|
||||
mounts Array []
|
||||
def::$NAME Hash None
|
||||
cifs_files Array []
|
||||
cifs::def::$NAME Hash None
|
||||
=============================== ======== ================================================
|
||||
|
||||
|
||||
``mounter::def::$NAME``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A hash defining a mount ``$NAME`` which can then be referenced by a module or
|
||||
through the Hiera variable ``mounter::mounts``.
|
||||
|
||||
The hash may contain the following keys:
|
||||
|
||||
- ensure
|
||||
|
||||
Is passed to the ``mount`` resource type unaltered with the following
|
||||
exception. If the value is ``running``, it is changed to ``mounted``. This
|
||||
ensures compatibility with an older version of this module.
|
||||
|
||||
- mountpoint
|
||||
|
||||
Will be created, if necessary.
|
||||
|
||||
- device
|
||||
- options
|
||||
- type
|
||||
|
||||
The filesystem type. Passed to the ``mount`` resource as ``fstype``.
|
||||
|
||||
- auto
|
||||
|
||||
Whether or not this mount should be automounted. Default: ``false``.
|
||||
|
||||
- updatedb
|
||||
|
||||
A boolean specifying whether :manpage:`updatedb(8)` should index the files
|
||||
below the mountpoint. See the :doc:`updatedb <../components/updatedb>`
|
||||
module for details.
|
||||
|
||||
|
||||
``mounter::mounts``
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
An array of strings referring to mount definitions to be configured on the
|
||||
target system. Each string is the name of a mount defined through
|
||||
`mounter::def::$NAME`_.
|
||||
|
||||
``mounter::cifs::def::$NAME``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
A ``Hash`` containing information for creating an authentication file for CIFS
|
||||
mounts.
|
||||
|
||||
The ``Hash`` may contain the following keys:
|
||||
|
||||
- ensure
|
||||
|
||||
Is passwed to the ``profile::mounter::cifs`` resource, should contain any
|
||||
possible value for the attribut ``ensure`` in a ``File`` resource type.
|
||||
Usually, ``present`` will ensure that file is existing and updated will
|
||||
``absent`` will remove it.
|
||||
|
||||
- path
|
||||
|
||||
This is mandatory, should contain the path where the new credential file
|
||||
should be located. Usually, ``/etc/cifs-utils`` would be a good option.
|
||||
|
||||
- mode
|
||||
|
||||
Defaults to ``0400``. It can be changed.
|
||||
|
||||
- owner
|
||||
|
||||
Defaults to ``root`` user. It can be changed.
|
||||
|
||||
- group
|
||||
|
||||
Defaults to ``group`` user. It can be changed.
|
||||
|
||||
- cifs_username
|
||||
|
||||
Must be defined. Should contain the ``username`` of the user allowed to
|
||||
mount the CIFS mountpoint.
|
||||
|
||||
- cifs_password
|
||||
|
||||
Must be defined. Should contain the ``password`` of the user allowed to
|
||||
mount the CIFS mountpoint, defined with ``cifs_username``.
|
||||
|
||||
|
||||
``mounter::cifs``
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
This defined type takes the paremters accepted for CIFS definitions (see
|
||||
`mounter::cifs::def::$NAME`_).
|
||||
|
||||
|
||||
Defined Types
|
||||
-------------
|
||||
|
||||
``mount``
|
||||
~~~~~~~~~
|
||||
|
||||
This defined type takes the parameters accepted for mount definitions (see
|
||||
`mounter::def::$NAME`_).
|
||||
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
||||
Local mount
|
||||
~~~~~~~~~~~
|
||||
|
||||
A local mount can be configured in the following way::
|
||||
|
||||
mounter::def::scratch:
|
||||
ensure: 'mounted'
|
||||
mountpoint: '/scratch'
|
||||
device: '/dev/vg_data/lv_scratch'
|
||||
type: 'xfs'
|
||||
|
||||
mounter::mounts:
|
||||
- 'scratch'
|
||||
|
||||
|
||||
To have the ``scratch`` mount from the previous example auto-mounted instead,
|
||||
add the ``auto`` parameter::
|
||||
|
||||
mounter::def::scratch:
|
||||
ensure: 'mounted'
|
||||
mountpoint: '/scratch'
|
||||
device: '/dev/vg_data/lv_scratch'
|
||||
type: 'xfs'
|
||||
auto: true
|
||||
|
||||
mounter::mounts:
|
||||
- 'scratch'
|
||||
|
||||
|
||||
Supposedly this is a scratch mount, so we exclude the whole mount both from
|
||||
backups and from updatedb.
|
||||
|
||||
|
||||
NFS Mount
|
||||
~~~~~~~~~
|
||||
|
||||
Remote NFS mountpoints can be defined as follows::
|
||||
|
||||
mounter::def::controls:
|
||||
'ensure': 'running'
|
||||
'enable': true
|
||||
'device': 'sls-hafs:/export/sls/controls'
|
||||
'mountpoint': '/gfa/.mounts/sls_controls'
|
||||
'type': 'nfs'
|
||||
|
||||
mounter::def::data1:
|
||||
'ensure': 'running'
|
||||
'enable': true
|
||||
'device': 'x01dc-fs-1:/export/X01DC/Data1'
|
||||
'mountpoint': '/sls/X01DC/Data1'
|
||||
'type': 'nfs'
|
||||
'options': 'soft,nfsvers=4,tcp,bg'
|
||||
|
||||
|
||||
mounter::mounts:
|
||||
- 'controls'
|
||||
- 'data1'
|
||||
|
||||
|
||||
CIFS Mount
|
||||
~~~~~~~~~~
|
||||
|
||||
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: 'running'
|
||||
enable: 'true'
|
||||
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`` is defined. You should specify in options the location of ``credentials``.
|
||||
Other optional parameters are used. ``emf`` is mounted with type ``cifs``, which will automatically ensure that
|
||||
proper ``cifs-utils`` package is installed.
|
||||
@@ -0,0 +1,16 @@
|
||||
``profile::mta``
|
||||
================
|
||||
|
||||
This module manages configures the system's MTA, currently
|
||||
:manpage:`postfix(1)`. At the moment it only configures a relay host and
|
||||
restricts access to the loopback interface.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
|
||||
``relay``
|
||||
~~~~~~~~~
|
||||
|
||||
The FQDN of a host that all outgoing mail will be forwarded to for delivery.
|
||||
@@ -0,0 +1,147 @@
|
||||
``profile::multipath``
|
||||
=======================
|
||||
|
||||
This profile configures :manpage:`multipath.conf`.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
==================== ======== =============================================
|
||||
**Name** **Type** **Default**
|
||||
-------------------- -------- ---------------------------------------------
|
||||
wwid hash hiera_hash('multipath::wwid',{})
|
||||
blacklist_wwid hash hiera_hash('multipath::blacklist_wwid',{})
|
||||
devices array hiera_hash('multipath::devices',{})
|
||||
blacklist_devices array hiera_hash('multipath::blacklist_devices',{})
|
||||
blacklist_devnode array hiera_hash('multipath::blacklist_devnode',{})
|
||||
==================== ======== =============================================
|
||||
|
||||
|
||||
``wwid``
|
||||
~~~~~~~~
|
||||
|
||||
A hash containing the `allowed multipaths` by adding the `device alias` and its corresponding `'wwid'`.
|
||||
In example:
|
||||
|
||||
Hiera data::
|
||||
|
||||
profile::multipath::wwid:
|
||||
'vol1_a': '360080e50004315f40000087e5966df82'
|
||||
'vol1_b': '360080e5000431680000007c35966e03e'
|
||||
'vol1_c': '360080e50004315f4000008825966e1bf'
|
||||
|
||||
will generate the following lines in the `'/etc/multipath.conf'` file::
|
||||
|
||||
multipaths {
|
||||
multipath {
|
||||
alias vol1_a
|
||||
wwid "360080e50004315f40000087e5966df82"
|
||||
}
|
||||
multipath {
|
||||
alias vol1_b
|
||||
wwid "360080e5000431680000007c35966e03e"
|
||||
}
|
||||
multipath {
|
||||
alias vol1_c
|
||||
wwid "360080e50004315f4000008825966e1bf"
|
||||
}
|
||||
}
|
||||
|
||||
``blacklist_wwid``
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
An hash containing `blacklisted multipaths` by adding the `device alias` and its corresponding `wwid`. In example:
|
||||
|
||||
Hiera data::
|
||||
|
||||
profile::multipath::blacklist_wwid:
|
||||
'vol1_j': '360080e50004315f40000087e59aaaaaa'
|
||||
|
||||
will generate the following lines in the `'/etc/multipath.conf'` file::
|
||||
|
||||
blacklist {
|
||||
...
|
||||
multipath {
|
||||
alias vol1_j
|
||||
wwid "360080e50004315f40000087e59aaaaaa"
|
||||
}
|
||||
...
|
||||
}
|
||||
|
||||
|
||||
``devices``
|
||||
~~~~~~~~~~~
|
||||
|
||||
An array containing `allowed devices` in the `multipath.conf` configuration. In example:
|
||||
|
||||
Hiera data::
|
||||
|
||||
profile::multipath::devices:
|
||||
- vendor: "Supermicro"
|
||||
product: "Supermicro"
|
||||
|
||||
|
||||
will generate the following lines in the `'/etc/multipath.conf'` file::
|
||||
|
||||
devices {
|
||||
device {
|
||||
vendor "Supermicro"
|
||||
product "Supermicro"
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
``blacklist_devices``
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
An array containing `blacklisted devices` in the `multipath.conf` configuration. In example:
|
||||
|
||||
Hiera data::
|
||||
|
||||
profile::multipath::blacklist_devices:
|
||||
- vendor: "HP"
|
||||
product: "HP"
|
||||
- vendor: "HP"
|
||||
|
||||
will generate the following lines in the `'/etc/multipath.conf'` file::
|
||||
|
||||
blacklist {
|
||||
...
|
||||
device {
|
||||
vendor "HP"
|
||||
product "HP"
|
||||
}
|
||||
device {
|
||||
vendor "HP"
|
||||
}
|
||||
...
|
||||
}
|
||||
|
||||
|
||||
``blacklist_devnode``
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
An array containing a list of `node devices` that will be `blacklisted` in `multipath.conf`.
|
||||
By default some `'devnodes'` are already included and fixed by default in the template file. These ones are the following::
|
||||
|
||||
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
|
||||
devnode "^(td|hd|vd)[a-z]"
|
||||
devnode "^(dcssblk)[0-9]*"
|
||||
|
||||
In example, hiera data::
|
||||
|
||||
profile::multipath::blacklist_devnode:
|
||||
- "sda"
|
||||
- "sdb"
|
||||
|
||||
will generate the following lines in the `'/etc/multipath.conf'` file::
|
||||
|
||||
blacklist {
|
||||
...
|
||||
devnode "sda"
|
||||
devnode "sdb"
|
||||
...
|
||||
}
|
||||
|
||||
|
||||
@@ -0,0 +1,69 @@
|
||||
``profile::networking``
|
||||
============================
|
||||
|
||||
This module configures most network-related settings, in particular:
|
||||
|
||||
- DNS resolution (``/etc/resolv.conf``)
|
||||
- DNS caching (via :manpage:`nscd(8)`)
|
||||
- static host entries
|
||||
|
||||
Notable exceptions are the firewall and ``/etc/hosts.{allow,deny}``.
|
||||
|
||||
It also provides information about networks to other modules through the
|
||||
variables listed below:
|
||||
|
||||
- ``profile::networking::zone``
|
||||
|
||||
The name of network zone. This is used by the :doc:`ntp_client
|
||||
<../profiles/ntp_client>` profile, for example, to determine which NTP servers
|
||||
to use.
|
||||
|
||||
- ``profile::networking::use_bastions``
|
||||
|
||||
This boolean indicates to the :doc:`aaa <../profiles/aaa>` profile whether SSH
|
||||
access should be restricted to connections coming from the bastion hosts.
|
||||
Override possible with ``aaa::use_bastions``.
|
||||
|
||||
|
||||
Notes:
|
||||
|
||||
- the above variables are not configured in ``hiera``, but in the
|
||||
`Puppet manifest <https://git.psi.ch/linux-infra/puppet/-/blob/preprod/code/modules/profile/manifests/networking/params.pp>`_
|
||||
|
||||
- the DNS cache is configured to be persistent, i.e. the cached data will
|
||||
survive restarts of ``nscd.service``. To clear the cache, run ``nscd -i
|
||||
hosts`` or ``systemctl reload nscd``.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
|
||||
``dns_servers``
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
The list of DNS servers (IP addresses) to be configured. This is only effective
|
||||
if the client doesn't use DHCP (see `enable_dhcp`_).
|
||||
|
||||
|
||||
``enable_dhcp``
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
If this is true, then settings that are typically configured through DHCP (e.g.
|
||||
DNS servers) are not touched by this module.
|
||||
|
||||
|
||||
``enable_dns_caching``
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This boolean determines whether DNS caching with nscd is enabled (``true``) or
|
||||
not (``false``). It is only effective if the client doesn't use DHCP (see
|
||||
`enable_dhcp`_).
|
||||
|
||||
|
||||
``static_host_entries``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A hash representing static host entries. The keys are the IP addresses, the
|
||||
values are expected to be lists of aliases for the given IP address. Special IP
|
||||
addresses like 127.0.0.1 are not allowed.
|
||||
@@ -0,0 +1,68 @@
|
||||
``profile::nfs_server``
|
||||
=======================
|
||||
|
||||
This module manages the Linux kernel NFS server and configures the exports.
|
||||
|
||||
See `Implementation Notes`_ below for details.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
=============================== ======== ================================================
|
||||
**Name** **Type** **Default**
|
||||
------------------------------- -------- ------------------------------------------------
|
||||
exports hash hiera('nfs_server::exports')
|
||||
=============================== ======== ================================================
|
||||
|
||||
|
||||
``exports``
|
||||
~~~~~~~~~~~
|
||||
|
||||
A hash containing the NFS exports to be configured. The keys are the pathnames
|
||||
to be exported, the values are hashes with two attributes:
|
||||
|
||||
- ``options``: the default options for the export
|
||||
- ``clients``: a list of hashes describing the clients
|
||||
|
||||
The hashes describing the clients have two entries as well, the second one being
|
||||
optional:
|
||||
|
||||
- ``hosts``: a client specification as described in :manpage:`exports(5)`
|
||||
- ``options`` (optional): an option string specific to these clients
|
||||
|
||||
Example::
|
||||
|
||||
nfs_server::exports:
|
||||
# Make software available via NFS. Installation happens
|
||||
# on builder.psi.ch.
|
||||
'/exports/prog':
|
||||
options: 'ro,root_squash'
|
||||
clients:
|
||||
- hosts: '129.129.0.0/16'
|
||||
- hosts: 'builder.psi.ch'
|
||||
options: 'rw,no_root_squash'
|
||||
# Scratch directories for prod servers. Files on scratch
|
||||
# are cleaned up by a cron job on janitor.psi.ch.
|
||||
'/exports/scratch':
|
||||
options: 'rw,root_squash'
|
||||
clients:
|
||||
- hosts: '129.129.160.0/24'
|
||||
- hosts: '129.129.190.0/24'
|
||||
- hosts: 'janitor.psi.ch'
|
||||
options: 'no_root_squash'
|
||||
|
||||
|
||||
Implementation Notes
|
||||
--------------------
|
||||
|
||||
We pass ``--manage-gids`` to :manpage:`rpc.mountd(8)` to avoid the following
|
||||
problem. When not using Kerberos, the NFS client passes a list of groups (GIDs
|
||||
really) that the user is a member of, and the server consults this list when
|
||||
making access decisions. The client can pass at most 16 groups, which means that
|
||||
if a user is a member of more than 16 groups, they may be denied access even
|
||||
though they are a member of the necessary group.
|
||||
|
||||
One solution is to use Kerberos, the other is to have the server determine group
|
||||
membership itself, ignoring the client's list. The latter is what
|
||||
``--manage-gids`` does.
|
||||
@@ -0,0 +1,45 @@
|
||||
``profile::nomachine``
|
||||
=======================
|
||||
|
||||
Installs and configures a NoMachine server. i
|
||||
|
||||
|
||||
This is the main class. It will configure several settings (license, service), but also
|
||||
depending on the ``$nomachine_profile`` setting (defined from hiera with
|
||||
``hiera('nomachine::profile')``), it will trigger different configurations according to
|
||||
its profile type.
|
||||
|
||||
Dependencies
|
||||
------------
|
||||
|
||||
``profile::nomachine`` is invoked from the ``role::base``. In order to be able to install
|
||||
NoMachine, you must setup the following setting in hiera: ``base::enable_nomachine: true``
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
================== =========================================== =============================
|
||||
**Name** **Type** **Default**
|
||||
------------------ ------------------------------------------- -----------------------------
|
||||
$nomachine_profile Enum['desktop', 'terminal', 'workstation' ] *No default. Must be defined*
|
||||
================== =========================================== =============================
|
||||
|
||||
``nomachine_profile``
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This is the NoMachine profile type. Depending on the profile type, it will call a different
|
||||
sub-profile:
|
||||
|
||||
- ``desktop``:
|
||||
|
||||
profile::nomachine::desktop
|
||||
|
||||
- ``terminal``:
|
||||
|
||||
profile::nomachine::terminal
|
||||
|
||||
- ``workstation``:
|
||||
|
||||
profile::nomachine::workstation
|
||||
|
||||
Each type contains its own specific settings and packages.
|
||||
@@ -0,0 +1,55 @@
|
||||
``profile::nomachine::desktop``
|
||||
===============================
|
||||
|
||||
This is a sub-class for ``profile::nomachine``.
|
||||
|
||||
Installs and configures NoMachine with profile type ``desktop``.
|
||||
|
||||
Dependencies
|
||||
------------
|
||||
|
||||
This is part of the ``profile::nomachine``.
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
==================================== ========= ========================================================================================================================================================================================
|
||||
**Name** **Type** **Default**
|
||||
------------------------------------ --------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
$nomachine_version String ``hiera('nomachine::desktop::version')``
|
||||
$server_EnableUPnP String ``hiera('nomachine::desktop::server::EnableUPnP', 'NX')``
|
||||
$server_ConnectionsLimit Integer ``hiera('nomachine::desktop::server::ConnectionsLimit', 20)``
|
||||
$server_ConnectionsUserLimit Integer ``hiera('nomachine::desktop::server::ConnectionsUserLimit', 20)``
|
||||
$server_VirtualDesktopMode Integer ``hiera('nomachine::desktop::server::VirtualDesktopMode', 2)``
|
||||
$server_VirtualDesktopsLimit Integer ``hiera('nomachine::desktop::server::VirtualDesktopsLimit', 20)``
|
||||
$server_VirtualDesktopsUserLimit Integer ``hiera('nomachine::desktop::server::VirtualDesktopsUserLimit', 20)``
|
||||
$server_SSHAuthorizedKeys String ``hiera('nomachine::desktop::server::SSHAuthorizedKeys', 'authorized_keys')``
|
||||
$server_PhysicalDesktopAuthorization Integer ``hiera('nomachine::desktop::server::PhysicalDesktopAuthorization', 0)``
|
||||
$server_PhysicalDesktopMode Integer ``hiera('nomachine::desktop::server::PhysicalDesktopMode', 1)``
|
||||
$server_PhysicalDesktopSharing Integer ``hiera('nomachine::desktop::server::PhysicalDesktopSharing', 1)``
|
||||
$server_EnableNetworkBroadcast Integer ``hiera('nomachine::desktop::server::EnableNetworkBroadcast', 1)``
|
||||
$server_AvailableSessionTypes String ``hiera('nomachine::desktop::server::AvailableSessionTypes', 'physical-desktop,shadow')``
|
||||
$node_DefaultDesktopCommand String ``hiera('nomachine::desktop::node::DefaultDesktopCommand', '"/etc/X11/xinit/Xsession \'gnome-session --session=gnome\'"')``
|
||||
$node_AvailableSessionTypes String ``hiera('nomachine::desktop::node::AvailableSessionTypes', 'unix-remote,unix-console,unix-default,unix-application,physical-desktop,shadow,unix-xsession-default,unix-gnome,unix-xdm')``
|
||||
$node_EnableSmartcardSharing Integer ``hiera('nomachine::desktop::node::EnableSmartcardSharing', 1)``
|
||||
$node_AudioInterface String ``hiera('nomachine::desktop::node::AudioInterface', 'disabled')``
|
||||
$node_EnableCUPSSupport Integer ``hiera('nomachine::desktop::node::EnableCUPSSupport', 1)``
|
||||
$node_ClientConnectionMethods String ``hiera('nomachine::desktop::node::ClientConnectionMethods', 'NX,SSH')``
|
||||
$node_DisplayServerThreads String ``hiera('nomachine::desktop::node::DisplayServerThreads', 'auto')``
|
||||
$node_DisplayEncoderThreads String ``hiera('nomachine::desktop::node::DisplayEncoderThreads', 'auto')``
|
||||
==================================== ========= ========================================================================================================================================================================================
|
||||
|
||||
``nomachine_version``
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This parameters must be defined. Please see ``common.yaml`` for checking the default value.
|
||||
|
||||
``server_*``
|
||||
~~~~~~~~~~~~
|
||||
|
||||
``$server_*`` paremeters are customizable settings for the NoMachine ``server.cfg`` configuration file. Please refer to NoMachine official documentation for more information.
|
||||
|
||||
``node_*``
|
||||
~~~~~~~~~~
|
||||
|
||||
``$node_*`` paremeters are customizable settings for the NoMachine ``node.cfg`` configuration file. Please refer to NoMachine official documentation for more information.
|
||||
@@ -0,0 +1,45 @@
|
||||
``profile::nomachine::license``
|
||||
===============================
|
||||
|
||||
This is a sub-class for ``profile::nomachine``.
|
||||
|
||||
Installs and configures NoMachine server and node licenses to a specific directory (default ``/etc/NX``).
|
||||
When licenses are updated, it triggers the activation of the new NoMachine licenses and it deploys them in ``/usr/NX/etc``.
|
||||
|
||||
Dependencies
|
||||
------------
|
||||
|
||||
This is part of the ``profile::nomachine``.
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
=========================== ========== ================================================================================================
|
||||
**Name** **Type** **Default**
|
||||
--------------------------- ---------- ------------------------------------------------------------------------------------------------
|
||||
$nomachine_license_location String ``hiera('nomachine::license::location', '/etc/NX')``. Defaults to ``/etc/NX``
|
||||
$nomachine_license_server String ``hiera("nomachine::license::server::$hostname")``. Must be defined and encrypyed with ``eyaml``
|
||||
$nomachine_license_node String ``hiera("nomachine::license::node::$hostname")``. Must be defined and encrypyed with ``eyaml``
|
||||
=========================== ========== ================================================================================================
|
||||
|
||||
``nomachine_license_location``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Defaults to ``/etc/NX``. Will be a temporary location for ``node.lic`` and ``server.lic``. **You must avoid to setup ``/usr/NX/etc``**
|
||||
as the ``nomachine_license_location``. Can be defined in Hiera as ``nomachine::license::location``.
|
||||
|
||||
``nomachine_license_server``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
``eyaml`` encrypted ``server.lic``. Must be defined in hiera as ``nomachine::license::server::$hostname``, where ``$hostname`` is the
|
||||
host shortname of the NoMachine server (equivalent to run ``hostname -s`` from command line).
|
||||
|
||||
For more information about encryption with ``eyaml``, please refer to http://linux-infra.gitpages.psi.ch/admin-guide/puppet/hiera.html#secret-values
|
||||
|
||||
``nomachine_license_node``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
``eyaml`` encrypted ``node.lic``. Must be defined in hiera as ``nomachine::license::node::$hostname``, where ``$hostname`` is the
|
||||
host shortname of the NoMachine server (equivalent to run ``hostname -s`` from command line).
|
||||
|
||||
For more information about encryption with ``eyaml``, please refer to http://linux-infra.gitpages.psi.ch/admin-guide/puppet/hiera.html#secret-values
|
||||
@@ -0,0 +1,20 @@
|
||||
``profile::nomachine::repository``
|
||||
==================================
|
||||
|
||||
This is a sub-class for ``profile::nomachine``.
|
||||
|
||||
This class just installs and configures a NoMachine repository. Is a very basic class with
|
||||
no configurable options.
|
||||
|
||||
Dependencies
|
||||
------------
|
||||
|
||||
This is part of the ``profile::nomachine``.
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
================== =========================================== =============================
|
||||
**Name** **Type** **Default**
|
||||
------------------ ------------------------------------------- -----------------------------
|
||||
================== =========================================== =============================
|
||||
@@ -0,0 +1,20 @@
|
||||
``profile::nomachine::service``
|
||||
===============================
|
||||
|
||||
This is a sub-class for ``profile::nomachine``.
|
||||
|
||||
This class just installs and configures a NoMachine service. Is a very basic class with
|
||||
no configurable options.
|
||||
|
||||
Dependencies
|
||||
------------
|
||||
|
||||
This is part of the ``profile::nomachine``.
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
================== =========================================== =============================
|
||||
**Name** **Type** **Default**
|
||||
------------------ ------------------------------------------- -----------------------------
|
||||
================== =========================================== =============================
|
||||
@@ -0,0 +1,56 @@
|
||||
``profile::nomachine::terminal``
|
||||
================================
|
||||
|
||||
This is a sub-class for ``profile::nomachine``.
|
||||
|
||||
Installs and configures NoMachine with profile type ``terminal``.
|
||||
|
||||
Dependencies
|
||||
------------
|
||||
|
||||
This is part of the ``profile::nomachine``.
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
==================================== ========= ===========================================================================================================================================================================================
|
||||
**Name** **Type** **Default**
|
||||
------------------------------------ --------- -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
$nomachine_version String ``hiera('nomachine::terminal::version')``. This is mandatory. See ``common.yaml`` for default value.
|
||||
$server_EnableUPnP String ``hiera('nomachine::terminal::server::EnableUPnP', 'none')``
|
||||
$server_ConnectionsLimit Integer ``hiera('nomachine::terminal::server::ConnectionsLimit', 200)``
|
||||
$server_ConnectionsUserLimit Integer ``hiera('nomachine::terminal::server::ConnectionsUserLimit', 2)``
|
||||
$server_DisconnectedSessionExpiry Integer ``hiera('nomachine::terminal::server::DisconnectedSessionExpiry', 0)``
|
||||
$server_VirtualDesktopMode Integer ``hiera('nomachine::terminal::server::VirtualDesktopMode', 0)``
|
||||
$server_VirtualDesktopsLimit Integer ``hiera('nomachine::terminal::server::VirtualDesktopsLimit', 300)``
|
||||
$server_VirtualDesktopsUserLimit Integer ``hiera('nomachine::terminal::server::VirtualDesktopsUserLimit', 2)``
|
||||
$server_SSHAuthorizedKeys String ``hiera('nomachine::terminal::server::SSHAuthorizedKeys', 'authorized_keys')``
|
||||
$server_PhysicalDesktopAuthorization Integer ``hiera('nomachine::terminal::server::PhysicalDesktopAuthorization', 1)``
|
||||
$server_PhysicalDesktopMode Integer ``hiera('nomachine::terminal::server::PhysicalDesktopMode', 2)``
|
||||
$server_PhysicalDesktopSharing Integer ``hiera('nomachine::terminal::server::PhysicalDesktopSharing', 0)``
|
||||
$server_EnableNetworkBroadcast Integer ``hiera('nomachine::terminal::server::EnableNetworkBroadcast', 0)``
|
||||
$server_AvailableSessionTypes String ``hiera('nomachine::terminal::server::AvailableSessionTypes', 'unix-remote,unix-console,unix-default,unix-application,physical-desktop,shadow,unix-xsession-default,unix-gnome,unix-xdm')``
|
||||
$node_DefaultDesktopCommand String ``hiera('nomachine::terminal::node::DefaultDesktopCommand', '"/etc/X11/xinit/Xsession \'gnome-session --session=gnome\'"')``
|
||||
$node_AvailableSessionTypes String ``hiera('nomachine::terminal::node::AvailableSessionTypes', 'unix-remote,unix-console,unix-default,unix-application,physical-desktop,shadow,unix-xsession-default,unix-gnome,unix-xdm')``
|
||||
$node_EnableSmartcardSharing Integer ``hiera('nomachine::terminal::node::EnableSmartcardSharing', 1)``
|
||||
$node_AudioInterface String ``hiera('nomachine::terminal::node::AudioInterface', 'disabled')``
|
||||
$node_EnableCUPSSupport Integer ``hiera('nomachine::terminal::node::EnableCUPSSupport', 1)``
|
||||
$node_ClientConnectionMethods String ``hiera('nomachine::terminal::node::ClientConnectionMethods', 'NX,SSH')``
|
||||
$node_DisplayServerThreads String ``hiera('nomachine::terminal::node::DisplayServerThreads', 'auto')``
|
||||
$node_DisplayEncoderThreads String ``hiera('nomachine::terminal::node::DisplayEncoderThreads', 'auto')``
|
||||
==================================== ========= ===========================================================================================================================================================================================
|
||||
|
||||
``nomachine_version``
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This parameters must be defined. Please see ``common.yaml`` for checking the default value.
|
||||
|
||||
``server_*``
|
||||
~~~~~~~~~~~~
|
||||
|
||||
``$server_*`` paremeters are customizable settings for the NoMachine ``server.cfg`` configuration file. Please refer to NoMachine official documentation for more information.
|
||||
|
||||
``node_*``
|
||||
~~~~~~~~~~
|
||||
|
||||
``$node_*`` paremeters are customizable settings for the NoMachine ``node.cfg`` configuration file. Please refer to NoMachine official documentation for more information.
|
||||
@@ -0,0 +1,56 @@
|
||||
``profile::nomachine::workstation``
|
||||
===================================
|
||||
|
||||
This is a sub-class for ``profile::nomachine``.
|
||||
|
||||
Installs and configures NoMachine with profile type ``workstation``.
|
||||
|
||||
Dependencies
|
||||
------------
|
||||
|
||||
This is part of the ``profile::nomachine``.
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
==================================== ========= ===============================================================================================================================
|
||||
**Name** **Type** **Default**
|
||||
------------------------------------ --------- -------------------------------------------------------------------------------------------------------------------------------
|
||||
$nomachine_version String ``hiera('nomachine::workstation::version')``
|
||||
$server_EnableUPnP String ``hiera('nomachine::workstation::server::EnableUPnP', 'NX')``
|
||||
$server_ConnectionsLimit Integer ``hiera('nomachine::workstation::server::ConnectionsLimit', 20)``
|
||||
$server_ConnectionsUserLimit Integer ``hiera('nomachine::workstation::server::ConnectionsUserLimit', 20)``
|
||||
$server_VirtualDesktopMode Integer ``hiera('nomachine::workstation::server::VirtualDesktopMode', 2)``
|
||||
$server_VirtualDesktopsLimit Integer ``hiera('nomachine::workstation::server::VirtualDesktopsLimit', 20)``
|
||||
$server_VirtualDesktopsUserLimit Integer ``hiera('nomachine::workstation::server::VirtualDesktopsUserLimit', 20)``
|
||||
$server_SSHAuthorizedKeys String ``hiera('nomachine::workstation::server::SSHAuthorizedKeys', 'authorized_keys')``
|
||||
$server_PhysicalDesktopAuthorization Integer ``hiera('nomachine::workstation::server::PhysicalDesktopAuthorization', 0)``
|
||||
$server_PhysicalDesktopMode Integer ``hiera('nomachine::workstation::server::PhysicalDesktopMode', 1)``
|
||||
$server_PhysicalDesktopSharing Integer ``hiera('nomachine::workstation::server::PhysicalDesktopSharing', 2)``
|
||||
$server_EnableNetworkBroadcast Integer ``hiera('nomachine::workstation::server::EnableNetworkBroadcast', 1)``
|
||||
$server_AvailableSessionTypes String ``hiera('nomachine::workstation::server::AvailableSessionTypes', 'shadow,unix-xsession-default')``
|
||||
$node_DefaultDesktopCommand String ``hiera('nomachine::workstation::node::DefaultDesktopCommand', '"/etc/X11/xinit/Xsession \'gnome-session --session=gnome\'"')``
|
||||
$node_AvailableSessionTypes String ``hiera('nomachine::workstation::node::AvailableSessionTypes', 'shadow,unix-xsession-default')``
|
||||
$node_EnableSmartcardSharing Integer ``hiera('nomachine::workstation::node::EnableSmartcardSharing', 1)``
|
||||
$node_AudioInterface String ``hiera('nomachine::workstation::node::AudioInterface', 'disabled')``
|
||||
$node_EnableCUPSSupport Integer ``hiera('nomachine::workstation::node::EnableCUPSSupport', 1)``
|
||||
$node_ClientConnectionMethods String ``hiera('nomachine::workstation::node::ClientConnectionMethods', 'NX,SSH')``
|
||||
$node_DisplayServerThreads String ``hiera('nomachine::workstation::node::DisplayServerThreads', 'auto')``
|
||||
$node_DisplayEncoderThreads String ``hiera('nomachine::workstation::node::DisplayEncoderThreads', 'auto')``
|
||||
==================================== ========= ===============================================================================================================================
|
||||
|
||||
``nomachine_version``
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This parameters must be defined. Please see ``common.yaml`` for checking the default value.
|
||||
|
||||
|
||||
``server_*``
|
||||
~~~~~~~~~~~~
|
||||
|
||||
``$server_*`` paremeters are customizable settings for the NoMachine ``server.cfg`` configuration file. Please refer to NoMachine official documentation for more information.
|
||||
|
||||
``node_*``
|
||||
~~~~~~~~~~
|
||||
|
||||
``$node_*`` paremeters are customizable settings for the NoMachine ``node.cfg`` configuration file. Please refer to NoMachine official documentation for more information.
|
||||
@@ -0,0 +1,32 @@
|
||||
``profile::ntp_client``
|
||||
=======================
|
||||
|
||||
This module configures the NTP client to synchronize the local system time with
|
||||
a number of time servers. Queries by other systems are disabled for security
|
||||
reasons.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
=============================== ======== ================================================
|
||||
**Name** **Type** **Default**
|
||||
------------------------------- -------- ------------------------------------------------
|
||||
servers hash hiera_hash('ntp_client::servers')
|
||||
=============================== ======== ================================================
|
||||
|
||||
|
||||
``servers``
|
||||
~~~~~~~~~~~
|
||||
|
||||
A hash containing the list of NTP servers for each :doc:`network zone
|
||||
<../profiles/networking>`, eg.::
|
||||
|
||||
ntp_client::servers:
|
||||
'default':
|
||||
- 'pstime1.psi.ch'
|
||||
- 'pstime2.psi.ch'
|
||||
- 'pstime3.psi.ch'
|
||||
'dmz':
|
||||
- 'dmztime1.psi.ch'
|
||||
- 'dmztime2.psi.ch'
|
||||
@@ -0,0 +1,37 @@
|
||||
``profile::nvidia``
|
||||
===================
|
||||
|
||||
The purpose of this module is to install the NVIDIA drivers. If NVIDIA GPU cards are
|
||||
detected with the facter ``pci_devices.gpu.nvidia``, automatically the ``profile::nvidia``
|
||||
class will be called. The ``class profile::platform`` is responsible for calling this profile::
|
||||
|
||||
if ( $facts['pci_devices']['gpu']['nvidia'].size > 0 ) {
|
||||
class { 'profile::nvidia':; }
|
||||
}
|
||||
|
||||
By default the profile only installs the GPU drivers, which can be disabled setting ``nvidia::driver::enable`` to ``false``.
|
||||
|
||||
To enable CUDA installation ``nvidia::cuda::enable`` must be set to ``true`` (default
|
||||
is ``false``).
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
============= ======== =======================================================
|
||||
**Name** **Type** **Default**
|
||||
------------- -------- -------------------------------------------------------
|
||||
dgx boolean $::productname ? { /^DGX.*/ => true, default => false }
|
||||
driver_enable boolean hiera('nvidia::driver::enable', true)
|
||||
cuda_enable boolean hiera('nvidia::cuda::enable', true)
|
||||
============= ======== =======================================================
|
||||
|
||||
|
||||
``driver_enable``
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
Install the Nvidia GPU drivers. By default is ``true``.
|
||||
|
||||
``cuda_enable``
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
By default is ``false``. Set to ``true`` if you want to install CUDA.
|
||||
@@ -0,0 +1,48 @@
|
||||
``profile::nvidia::cuda``
|
||||
=========================
|
||||
|
||||
The purpose of this module is to install the NVIDIA drivers and CUDA.
|
||||
This
|
||||
|
||||
The GPU drivers are always installed when this profile is included.
|
||||
|
||||
To enable CUDA installation ``nvidia::cuda::enable`` must be set to ``true`` (default
|
||||
is ``false``).
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
============== ======== =========================================================
|
||||
**Name** **Type** **Default**
|
||||
-------------- -------- ---------------------------------------------------------
|
||||
driver_version string hiera('nvidia::driver::version', undef)
|
||||
driver_branch string hiera('nvidia::driver::branch', undef)
|
||||
cuda_enable boolean hiera('nvidia::cuda::enable', true)
|
||||
cuda_version string hiera('nvidia::cuda::version')
|
||||
nv_persist boolean hiera('nvidia::cuda::nvidia_persistenced::enable', undef)
|
||||
============== ======== =========================================================
|
||||
|
||||
|
||||
``driver_version``
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Keep the Nvidia GPU driver at a given version.
|
||||
|
||||
``driver_branch``
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
RHEL 8 only: Use the GPU drivers from given driver branch.
|
||||
|
||||
``cuda_enable``
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
By default is ``false``. Set to ``true`` if you want to install CUDA.
|
||||
|
||||
|
||||
``cuda_version``
|
||||
~~~~~~~~~~~~~~~~
|
||||
The version of CUDA to be used. On RHEL 8 it will install the newest possible still supporting the installed driver.
|
||||
|
||||
``nv_persist``
|
||||
~~~~~~~~~~~~~~
|
||||
Controls the ``nvidia_persistenced`` service. By default is disabled and stopped on RHEL 7, while on RHEL 8 it is enabled and running by defautl.
|
||||
@@ -0,0 +1,54 @@
|
||||
``profile::package_list``
|
||||
============================
|
||||
|
||||
This module installs a list of packages on the node, with extra options including package removal or selection by OS.
|
||||
|
||||
This profile is used from Puppet::
|
||||
|
||||
profile::package_list{'icinga_client':
|
||||
packages => [
|
||||
'nrpe',
|
||||
'nrpe-selinux',
|
||||
'mod_gearman-static:os=redhat7',
|
||||
'mod_gearman:os!redhat7',
|
||||
'nagios-plugins-disk',
|
||||
'nagios-plugins-load',
|
||||
],
|
||||
}
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
=============================== ======== =============================================
|
||||
**Name** **Type** **Default**
|
||||
------------------------------- -------- ---------------------------------------------
|
||||
packages list []
|
||||
=============================== ======== =============================================
|
||||
|
||||
|
||||
|
||||
``packages``
|
||||
~~~~~~~~~~~~
|
||||
|
||||
This list contains the names of the packages to be installed. The names may be "extended" by tags, separated by ``:``.
|
||||
|
||||
========== ===============================
|
||||
**Tag** **Function**
|
||||
---------- -------------------------------
|
||||
absent package will be removed
|
||||
latest always latest version installed
|
||||
os=redhat7 only install on given OS
|
||||
os!redhat7 do not install on given OS
|
||||
========== ===============================
|
||||
|
||||
|
||||
Example definitions::
|
||||
|
||||
java-11-openjdk
|
||||
@Java Platform
|
||||
java-1.8.0-openjdk:os=redhat8:latest:os!redhat9
|
||||
java-1.8.0-openjdk:os=redhat7:absent
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,47 @@
|
||||
``profile::platform``
|
||||
=====================
|
||||
|
||||
The purpose of this ``profile`` is to install specific components depending on the hardware components
|
||||
and hardware/platform type.
|
||||
|
||||
Currently, for ``vmware`` machines no actions are performed. For ``physical`` machines some actions will
|
||||
be performed depending on the parameter settings (see below).
|
||||
|
||||
Also, according to the facter ``manufacturer``, some specific actions can be triggered. Currently only
|
||||
``HP``/``HPE`` hardware is considered.
|
||||
|
||||
Other options such like NVIDIA or Infiniband card detection are possible. Whenever detected, it will call
|
||||
the corresponding class and will perform required actions.
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
================= ========== ===========
|
||||
**Name** **Type** **Default**
|
||||
----------------- ---------- -----------
|
||||
enable_rasdaemon bool
|
||||
enable_smartd bool
|
||||
================= ========== ===========
|
||||
|
||||
``enable_rasdaemon``
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
When set to ``true``, will install and enable the ``rasdaemon`` service.
|
||||
|
||||
``enable_smartd``
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
When set to ``true``, will install and enable the ``smartmontools`` (``smartd``) service.
|
||||
|
||||
Facts
|
||||
-----
|
||||
|
||||
When some specific facts are detected, it will trigger some actions.
|
||||
|
||||
===================================== =============== ==============================================
|
||||
**Fact** **Value(s)** **Action description**
|
||||
------------------------------------- --------------- ----------------------------------------------
|
||||
``manufacturer`` ``HP``|``HPE`` ``include profile::platform::hewlett_packard``
|
||||
``['pci_devices']['gpu']['nvidia']`` count > 0 ``include profile::nvidia``
|
||||
``['pci_devices']['ib']['mellanox']`` count > 0 ``include profile::infiniband``
|
||||
===================================== =============== ==============================================
|
||||
@@ -0,0 +1,24 @@
|
||||
``profile::platform::hewlett_packard``
|
||||
======================================
|
||||
|
||||
When ``profile::platform::hewlett_packard`` is called (usually from the ``profile::platform`` through
|
||||
the facter ``manufacturer``, by auto-detecting an HP platform) some actions will be triggered.
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
================= ========== ===========
|
||||
**Name** **Type** **Default**
|
||||
----------------- ---------- -----------
|
||||
================= ========== ===========
|
||||
|
||||
Facts
|
||||
-----
|
||||
|
||||
When some specific facts are detected, it will trigger some actions.
|
||||
|
||||
==================================== ================= =======================================================
|
||||
**Fact** **Value(s)** **Action description**
|
||||
------------------------------------ ----------------- -------------------------------------------------------
|
||||
``productname`` ``/^ProLiant.*/`` Install ``hpssacli`` for HP Array Management/Monitoring
|
||||
==================================== ================= =======================================================
|
||||
@@ -0,0 +1,54 @@
|
||||
``profile::pmodules``
|
||||
=====================
|
||||
|
||||
This module manages the `AIT Pmodules
|
||||
<https://amas.psi.ch/Pmodules/wiki/Pmodules>`_.
|
||||
|
||||
It automatically enables Pmodules for all users with
|
||||
|
||||
1. a UID >= 1000
|
||||
2. a username **not** ending in ``-adm``
|
||||
|
||||
This makes sure that local service accounts, root, and administrator accounts do
|
||||
not use Pmodules automatically.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
================== ======== ==============================
|
||||
**Name** **Type** **Default**
|
||||
------------------ -------- ------------------------------
|
||||
basedir string hiera('pmodules::basedir')
|
||||
================== ======== ==============================
|
||||
|
||||
|
||||
``basedir``
|
||||
~~~~~~~~~~~
|
||||
|
||||
The subdirectory of ``/afs/psi.ch/sys/`` where the modules can be found, e.g.
|
||||
``psi.x86_64_slp6`` or ``psi.ra``.
|
||||
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
||||
This profile is included in the base role, but disabled. To enable Pmodules
|
||||
simply pass ``enable_pmodules => true`` when including the base role::
|
||||
|
||||
class role::some_role () {
|
||||
class {'role::base':
|
||||
enable_pmodules => true,
|
||||
...
|
||||
}
|
||||
...
|
||||
|
||||
To customize the base directory, include ``pmodules`` separately::
|
||||
|
||||
class role::some_role () {
|
||||
include role::base
|
||||
|
||||
class {'profile::pmodules':
|
||||
basedir => 'psi.ra',
|
||||
}
|
||||
...
|
||||
@@ -0,0 +1,29 @@
|
||||
``profile::print_client``
|
||||
=========================
|
||||
|
||||
This module configures printing to the PSI print server.
|
||||
|
||||
Currently, CUPS is used.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
=============================== ======== =======================================
|
||||
**Name** **Type** **Default**
|
||||
------------------------------- -------- ---------------------------------------
|
||||
default_printer string hiera('print_client::default_printer')
|
||||
print_server string hiera('print_client::server')
|
||||
=============================== ======== =======================================
|
||||
|
||||
|
||||
``default_printer``
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The default printer to be configured in the PRINTER environment variable.
|
||||
|
||||
|
||||
``print_server``
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
The FQDN of the CUPS print server to use.
|
||||
@@ -0,0 +1,23 @@
|
||||
``profile::puppet_client``
|
||||
==========================
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
========== ========= =========================
|
||||
**Name** **Type** **Default**
|
||||
---------- --------- -------------------------
|
||||
exec_time string ``05:00:00 -- 08:00:00``
|
||||
========== ========= =========================
|
||||
|
||||
|
||||
``exec_time``
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Defines a time window during which Puppet will run every day. The exact time
|
||||
depends on the FQDN of the system (see below), ensuring that on each system the
|
||||
timing is consistent and predictable, but across a group of systems using the
|
||||
same time window the exact times are distributed uniformly.
|
||||
|
||||
The syntax is ``HH:MM:SS -- HH:MM:SS``.
|
||||
@@ -0,0 +1,73 @@
|
||||
``profile::repository``
|
||||
============================
|
||||
|
||||
This module configures adds a list of package repositories from hiera
|
||||
and filters those according to OS version.
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
=============================== =========== =============================================
|
||||
**Name** **Type** **Default**
|
||||
------------------------------- ----------- ---------------------------------------------
|
||||
descr string
|
||||
baseurl string
|
||||
gpgkey string undef
|
||||
gpgcheck bool false
|
||||
disable bool true
|
||||
priority integer undef
|
||||
exclude string/list ''
|
||||
=============================== =========== =============================================
|
||||
|
||||
|
||||
``title``
|
||||
~~~~~~~~~
|
||||
|
||||
The repository definition will end up as ``/etc/yum.repos.d/${title}.repo`` on the node
|
||||
|
||||
|
||||
|
||||
``descr``
|
||||
~~~~~~~~~
|
||||
|
||||
Description of the package repository.
|
||||
|
||||
|
||||
``baseurl``
|
||||
~~~~~~~~~~~
|
||||
|
||||
URL where the repository is available from, e.g.::
|
||||
|
||||
https://repos.psi.ch/rhel8/tags/$pli_repo_tag/epel/
|
||||
|
||||
|
||||
``gpgkey``
|
||||
~~~~~~~~~~
|
||||
|
||||
URL or file path where the signing GPG key is available from, e.g.::
|
||||
|
||||
https://repos.psi.ch/rhel8/keys/RPM-GPG-KEY-EPEL-8
|
||||
|
||||
|
||||
``gpgcheck``
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Check GPG signature of installed packages.
|
||||
|
||||
|
||||
``disable``
|
||||
~~~~~~~~~~~
|
||||
|
||||
If the repository should be checked for package installation/updates or not.
|
||||
|
||||
|
||||
``priority``
|
||||
~~~~~~~~~~~~
|
||||
|
||||
What priority do packages from this repositry have?
|
||||
|
||||
|
||||
``exclude``
|
||||
~~~~~~~~~~~
|
||||
|
||||
List or comma separated string with packages to be ignored from this repositores. Wildcards are supported.
|
||||
@@ -0,0 +1,64 @@
|
||||
``profile::repository_list``
|
||||
============================
|
||||
|
||||
This module configures adds a list of package repositories from hiera
|
||||
and filters those according to OS version.
|
||||
|
||||
This profile is used from Puppet::
|
||||
|
||||
profile::repository_list{'rpm_repos::epel':}
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
=============================== ======== =============================================
|
||||
**Name** **Type** **Default**
|
||||
------------------------------- -------- ---------------------------------------------
|
||||
accept_empty bool false
|
||||
=============================== ======== =============================================
|
||||
|
||||
|
||||
``title``
|
||||
~~~~~~~~~
|
||||
|
||||
Name of the list of software repositores to be installed.
|
||||
It will lookup in Hiera for a list ``$title`` and look up the
|
||||
repository definitons with ``hiera_hash("rpm_repos::repo::${name}")``.
|
||||
|
||||
The repository definitions not suitable for this OS will be filtered away,
|
||||
then with the rest a repository configuration is writen to the node
|
||||
using ``profile::repository``. The ``osversion`` key in the repository definition
|
||||
signals the major RHEL version for which this repository is for.
|
||||
|
||||
Example::
|
||||
|
||||
rpm_repos::repo::epel_rhel8:
|
||||
name: 'epel'
|
||||
descr: "Extra Packages for Enterprise Linux 8"
|
||||
baseurl: 'https://repos.psi.ch/rhel8/tags/$pli_repo_tag/epel/'
|
||||
gpgkey: 'https://repos.psi.ch/rhel8/keys/epel.gpg'
|
||||
disable: false
|
||||
gpgcheck: true
|
||||
osversion: 8
|
||||
exclude:
|
||||
- "slurm*"
|
||||
|
||||
rpm_repos::repo::epel_rhel7:
|
||||
name: 'epel'
|
||||
descr: "Extra Packages for Enterprise Linux 7"
|
||||
baseurl: 'https://repos.psi.ch/rhel7/tags/$pli_repo_tag/epel/'
|
||||
disable: false
|
||||
gpgcheck: false
|
||||
osversion: 7
|
||||
exclude:
|
||||
- "slurm*"
|
||||
|
||||
rpm_repos::epel
|
||||
- epel_rhel7
|
||||
- epel_rhel8
|
||||
|
||||
|
||||
``accept_empty``
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Do not fail when the repository list is empty after filtering away those not suitable for the current OS.
|
||||
@@ -0,0 +1,53 @@
|
||||
``profile::rpm_repos``
|
||||
=======================
|
||||
|
||||
This module configures :manpage:`dnf(8)` and sets up the default package repositores.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
=============================== ======== =============================================
|
||||
**Name** **Type** **Default**
|
||||
------------------------------- -------- ---------------------------------------------
|
||||
repo_list string 'rpm_repos::default'
|
||||
repo_tags hash hiera_hash('rpm_repos::tag')
|
||||
exclude list hiera('base::package_exclude, [])
|
||||
purge_repositories bool hiera('rpm_repos::purge_repositories')
|
||||
=============================== ======== =============================================
|
||||
|
||||
|
||||
``repo_list``
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Name of the list of default software repositores to be installed.
|
||||
|
||||
``repo_tags``
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Hash containing the repository tag which should be used per OS.
|
||||
The key for RHEL 7 is ``redhat7`` and points by default to ``prod``,
|
||||
whereas for later versions is ``rhel-$MAJOR_VERSION`` (eg. for ``redhat8`` it is ``rhel-8``)
|
||||
|
||||
``exclude``
|
||||
~~~~~~~~~~~
|
||||
|
||||
An array containing entries suitable for the ``exclude`` option in
|
||||
:manpage:`dnf.conf(5)`.
|
||||
|
||||
|
||||
``purge_repositories``
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A boolean controlling whether files that were not created by Puppet should be
|
||||
removed from ``/etc/yum.repos.d``. This is useful to prevent repositories to be
|
||||
configured through other means (e.g. manually).
|
||||
|
||||
|
||||
``repos``
|
||||
~~~~~~~~~
|
||||
|
||||
A list of names designating the repositories that are to be configured (not
|
||||
necessarily enabled) on the system. If ``<name>`` is the name of the repository,
|
||||
then its definition is determined by searching Hiera for the
|
||||
``rpm_repos::repo::<name>`` key.
|
||||
@@ -0,0 +1,27 @@
|
||||
``profile::serial_console``
|
||||
===========================
|
||||
|
||||
Configures the serial console on physical systems.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
========= ========= ============
|
||||
**Name** **Type** **Default**
|
||||
--------- --------- ------------
|
||||
device string ``ttyS0``
|
||||
rate integer 115200
|
||||
========= ========= ============
|
||||
|
||||
|
||||
``device``
|
||||
~~~~~~~~~~
|
||||
|
||||
The device to configure as a console.
|
||||
|
||||
|
||||
``rate``
|
||||
~~~~~~~~
|
||||
|
||||
The rate to use for the serial console.
|
||||
@@ -0,0 +1,10 @@
|
||||
``profile::sysinfo``
|
||||
====================
|
||||
|
||||
Stores certain information about the system in ``/etc/sysconfig/pli-info`` for
|
||||
the use of other programs and scripts. Currently, the following values are
|
||||
stored:
|
||||
|
||||
- ``SYSDB_ENV``: the system's sysdb environment
|
||||
- ``PUPPET_GROUP``: the system's ``puppet_group`` value from sysdb
|
||||
- ``PUPPET_ROLE``: the system's ``puppet_role`` value from sysdb
|
||||
@@ -0,0 +1,59 @@
|
||||
``profile::telegraf``
|
||||
=====================
|
||||
|
||||
This profile configures the `telegraf
|
||||
<https://www.influxdata.com/time-series-platform/telegraf/>`_ metrics collection
|
||||
agent.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
=============================== ======== ================================================
|
||||
**Name** **Type** **Default**
|
||||
------------------------------- -------- ------------------------------------------------
|
||||
enable_service bool
|
||||
agent hash hiera_hash('telegraf::agent')
|
||||
agent:url String zone defaults in common.yaml
|
||||
metrics hash lookup('telegraf::metrics', {merge => 'deep'})
|
||||
config::purge bool true
|
||||
=============================== ======== ================================================
|
||||
|
||||
|
||||
``enable_service``
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Determines whether or not Puppet will start or stop the service.
|
||||
|
||||
|
||||
``agent``
|
||||
~~~~~~~~~
|
||||
|
||||
This hash can be used to set the following configuration options in
|
||||
``/etc/telegraf/telegraf.conf``:
|
||||
|
||||
- ``metric_buffer_limit``
|
||||
- ``collection_jitter``
|
||||
- ``flush_interval``
|
||||
- ``flush_jitter``
|
||||
|
||||
|
||||
``metrics``
|
||||
~~~~~~~~~~~
|
||||
|
||||
This hash defines the metrics which the telegraf agent will collect. The keys
|
||||
are the names of the metrics and the values are hashes describing the metric.
|
||||
Every key/value pair in these hashes will be added to the configuration files
|
||||
directly without any checks.
|
||||
|
||||
Examples::
|
||||
|
||||
'cpu':
|
||||
enable: true
|
||||
'disk':
|
||||
enable: true
|
||||
interval: '30m'
|
||||
ignore_fs:
|
||||
- 'aufs'
|
||||
- 'auristorfs'
|
||||
- 'devfs'
|
||||
@@ -0,0 +1,28 @@
|
||||
``profile::vgroot``
|
||||
=======================
|
||||
|
||||
This module allows to resize logical volumes/partitions on the default volume group ``vg_root``.
|
||||
|
||||
If you alternatively want to control the full volume group or add an additional one, please configure in Hiera the `lvm Puppet module <https://forge.puppet.com/modules/puppetlabs/lvm>`_.
|
||||
|
||||
|
||||
Parameters
|
||||
----------
|
||||
|
||||
=============================== ======== ================================================
|
||||
**Name** **Type** **Default**
|
||||
------------------------------- -------- ------------------------------------------------
|
||||
vgroot hash hiera_hash('vgroot::path')
|
||||
=============================== ======== ================================================
|
||||
|
||||
|
||||
``vgroot``
|
||||
~~~~~~~~~~~
|
||||
|
||||
A hash containing as key the name of the volume group (``/dev/mapper/vg_root-$NAME``) to be adjusted and the volume size as value::
|
||||
|
||||
vgroot::path:
|
||||
lv_root: 20GB
|
||||
lv_var: 10GB
|
||||
|
||||
The contained file system will then automatically resized if needed.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user