zimoch/Controls-docs
0
0
Fork 0
forked from Controls/gitea-pages
Code Pull Requests Actions Activity

create software management subdirectory

Browse Source
This commit is contained in:
buchel_k
2024-10-04 14:01:44 +02:00
parent c2c5953518
commit 047ce36996
11 changed files with 12 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
admin-guide/configuration/software/citrix_vda.md
+12
View File
@@ -0,0 +1,12 @@
# Citrix VDA Installation
There is a [installation guide](https://docs.citrix.com/en-us/linux-virtual-delivery-agent/current-release/installation-overview/manual-installation-overview/redhat.html) by Citrix to install the Citrix VDA manually on Red Hat systems.
The following Hiera settings will bring the system into a state as requested in the installation guide:
```
# Citrix VDA specialities
hostname::short: true
networking::hostname_on_lo: true
aaa::sssd_cache_creds: false
aaa::default_krb_cache: "FILE:/tmp/krb5cc_%{literal('%')}{uid}"
```
admin-guide/configuration/software/conda.md
+83
View File
@@ -0,0 +1,83 @@
# Conda / Anaconda
Conda / Anaconda (https://conda.org) is a package manager that can be used to easily create tailored Python environments without having required C/... binaries of some packages installed on the local system. (i.e. conda will take care that required binaries are installed into the environment)
```{warning}
Due to certain license restrictions the usage of Anaconda at PSI is not allowed without obtaining a professional license from Anaconda.com!
However the usage of the command `conda` and/or of packages from conda-forge is still possible - see below ...
```
This guide explains how to install and configure conda in accordance to the Anaconda.com license terms.
## Installation
On a standard Linux system the conda package can be simply installed via a:
```
yum install conda
```
To instruct puppet to install the package you can have following hiera config:
```yaml
base::pkg_group::extra:
- 'conda'
base::package_groups:
- 'extra'
```
## Configuration
To overwrite the default configuration of conda (which would violate the license because packages would be installed from anaconda.org by default) following config file needs to be deployed in `/etc/conda/condarc.d/base.yml` (or similar):
```yaml
channels:
- conda-forge
# Show channel URLs when displaying what is going to be downloaded
# and in 'conda list'. The default is False.
show_channel_urls: True
always_copy: true
```
To place the file via Puppet/Hiera you can have following configuration:
```yaml
files::files:
/etc/conda/condarc.d/base.yml:
content: |
channels:
- conda-forge
- nodefaults
# Show channel URLs when displaying what is going to be downloaded
# and in 'conda list'. The default is False.
show_channel_urls: True
always_copy: true
```
To be able to use the `conda` command a user needs to source the command into its current shell. This can be done like this:
```bash
source /opt/conda/etc/profile.d/conda.sh
```
Afterwards conda environments can be created in a license conformed way as documented at https://docs.conda.io/projects/conda/en/latest/user-guide/tasks/manage-environments.html
## Usage
More details on the usage of the `conda` command can be found here:
https://docs.conda.io/projects/conda/en/stable/user-guide/index.html
### Important Info
It seems that the `conda list <package>` command still uses the default channel. However `conda install` seem to respect the config above.
Probably related to this here:
https://stackoverflow.com/questions/67695893/how-do-i-completely-purge-and-disable-the-default-channel-in-anaconda-and-switch
admin-guide/configuration/software/labview.md
+102
View File
@@ -0,0 +1,102 @@
# LabView
We have a site license for LabView, the license server is `lic-ni.psi.ch:27020`.
## Installation of LabView
Select the desired version on the [NI Download Portal](https://www.ni.com/en/support/downloads/software-products/download.labview.html#544131).
It downloads a zip file which you need to extract and to install the rpm file according to your OS, e.g.:
```
sudo dnf install ni-labview-2024-pro-24.3.1.49155-0+f3-rhel9.noarch.rpm
```
This now installs the package repository for given LabView version. Now it is just left to install it
```
sudo dnf install ni-labview-2024-pro
```
Note that by default the package repository file will be removed by the next Puppet run.
To avoid this set `rpm_repos::purge: false` in Hiera or check the chapter "Installation via Puppet and Hiera".
## Installation of LabView Drivers
Again select you desired version on the [NI Download Portal](https://www.ni.com/en/support/downloads/drivers/download.ni-linux-device-drivers.html#544344).
Again it downloads a zip file you need to extract and then install the suitable rpm file, e.g.:
```
sudo dnf install ni-rhel9-drivers-2024Q3.rpm
```
This now installs the package repository for the drivers. Next install the needed drivers, e.g.
```
sudo dnf install ni-488.2
```
Now the kernel drivers need to be prepared
```
sudo dkms autoinstall
```
and finally reboot to prepare everything for showtime.
Note that by default the package repository file will be removed by the next Puppet run.
To avoid this set `rpm_repos::purge: false` in Hiera or check the next chapter "Installation via Puppet and Hiera".
## Installation via Puppet and Hiera
Above example could also be configured with Hiera:
```
rpm_repos::repo::labview:
name: 'labview'
descr: "NI LabVIEW 2024 Q3 pro"
baseurl: 'https://download.ni.com/ni-linux-desktop/LabVIEW/2024/Q3/f1/pro/rpm/ni-labview-2024/el9'
gpgkey: 'https://download.ni.com/ni-linux-desktop/stream/ni-linux-desktop-2019.pub'
disable: false
gpgcheck: false
repo_gpgcheck: true
rpm_repos::repo::labview_drivers:
name: 'labview_drivers'
descr: "NI Linux Software 2024 Q3"
baseurl: 'https://download.ni.com/ni-linux-desktop/2024/Q3/rpm/ni/el9'
gpgkey: 'https://download.ni.com/ni-linux-desktop/stream/ni-linux-desktop-2019.pub'
disable: false
gpgcheck: false
repo_gpgcheck: true
rpm_repos::default:
- 'labview'
- 'labview_drivers'
base::pkg_group::labview:
- 'ni-labview-2024-pro'
- 'ni-488.2'
base::package_groups:
- 'labview'
```
The main difficulty is to figure out the repository URLs, which is easiest done by the manual download, unpack and install the rpm file. Or by inspecting its content.
But with this Hiera configuration the setup can easily be replicated to other machines or to recreate the current setup.
What still needs to be done on first installation and cannot be automated with Puppet is:
Now the kernel drivers need to be prepared
```
sudo dkms autoinstall
```
and the following reboot.
admin-guide/configuration/software/package_repositories.md
+136
View File
@@ -0,0 +1,136 @@
# Selecting Package Repositories
## Package Repository Lists
Also for configuring package repositories our configuration management works with lists containing the names of the repositories to be installed.
The default list (except for nodes with the `bootpc` and `appliances::lenovo::*` Puppet roles) is `rpm_repos::default`.
If repositories are managed in Hiera, feel free to add them to `rpm_repos::default` like
```
rpm_repos::default:
- 'gfa'
```
Note that repositories for different versions of RHEL can be added and only the fitting ones will be configured on the node.
If the package repositories are managed by a Puppet module, then it is good practice is to define a specific package repository list in [`common.yaml`](https://git.psi.ch/linux-infra/puppet/-/blob/preprod/data/common.yaml) and then to install it only when needed. An example is `profile::telegraf` which only installes the repositories listed in `rpm_repos::influx` when needed.
## Package Repository Definition
An individual package repository is configured in Hiera within the namespace `rpm_repos::repo::*`, like following 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*"
```
### Package Repository Name
The reference name used in Hiera (the part after `rpm_repos::repo::` should be globally unique. An unfortunate practice is to use the same name for different package repositories. A current example is the `gfa` repository which has different URLs on different `sysdb` environments.
Note for `name` attribute, that only has to be unique on the machine where they are installed. So if there are two repositories defined to provide the same software for two different OS versions, then it is fine to have the same name there.
### Package Repository URL
Overriding the URL of a package repository definition on a stricter scope is considered bad practice. The URL defines the actual "identiy" of the package repository definition. It is confusing if it gets different meanings at different places. It is like one passport which will identify different persons in different countries.
If different sources are needed, define and name them appropriately. They point to one given repository and the package repository lists are the place to select what should be applied on a given node.
Also feel free to define all your package repositories in [`common.yaml`](https://git.psi.ch/linux-infra/puppet/-/blob/preprod/data/common.yaml).
### Select Package Repository by OS Version
Usually a package repository only serves packages for one major OS version. This can be stated by the `osversion` attribute. When a package repository list is installed, only the repositories fitting the version of the OS installed on the node are selected and configured.
If the `osversion` attribute is not set, then it is always installed.
### Package Repository GPG Verification
GPG verification is optional, so `gpgkey` may not be defined and `gpgcheck` is `false` by default. But ideally the packages are signed and checked for tampering and corruption.
### Exclude Packages
If certain packages provided by given repository should be ignored on the nodes, then add them to the `exclude` list.
## Using Specific Package Repository Snapshot
Most of the externally sourced package repositories on https://repos.psi.ch/rhel7 (RHEL7), https://repos.psi.ch/rhel8 (RHEL 8) and https://repos.psi.ch/rhel9 (RHEL 9) have snapshots which can be used to freeze the available package versions to a given date.
The tags are different per major OS version and are definied in the Hiera hash `rpm_repos::tag`, below you see the default:
```
yum_client::repo_tag: 'prod'
rpm_repos::tag:
redhat7: "%{lookup('yum_client::repo_tag')}"
redhat8: 'rhel-8'
redhat9: 'rhel-9'
```
So for RHEL 7 the default is `prod` and can be overriden on `yum_client::repo_tag` (backwards compatibility) or on the `redhat7` attribute of `rpm_repos::tag`.
To fix to a specific snapshot on RHEL 8, the `redhat8` attribute has to be set on `rpm_repos::tag`, the default is `rhel-8` which points to the latest snapshot.
The available tags your find at
- [https://repos.psi.ch/rhel9/tags/](https://repos.psi.ch/rhel8/tags/) for RHEL 9
- [https://repos.psi.ch/rhel8/tags/](https://repos.psi.ch/rhel8/tags/) for RHEL 8 (note the `prod` tag will phase out)
- [https://repos.psi.ch/rhel7/tags/](https://repos.psi.ch/rhel7/tags/) for RHEL 7
## Package Repositories made Available by the Linux Group
Availabe on all systems are:
- RedHat [BaseOS](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/package_manifest/baseos-repository), [AppStream](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/package_manifest/appstream-repository) and [CodeReady](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/package_manifest/codereadylinuxbuilder-repository) repositories
- [Extra Packages for Enterprise Linux (EPEL) repositories](https://docs.fedoraproject.org/en-US/epel/)
- Puppet 7 repository
- Auristor repository for YFS and AFS related packages (RHEL 7 and 8 only)
- Google Chrome repository
- pli-misc (not tagged for RHEL7, but on RHEL 8/9)
- Code (Visual Studio Code from Microsoft)
- Microsoft Teams
- PowerScript et. al. (Microsoft)
- HashiCorp (`vault`, `terraform`, `vagrant`, ...)
- Oracle Instant Client 19 and 21
- Opera
Predefined and used when needed are:
- Influx (`influxdb`, `telegraf`, ...)
- CUDA
- Nomachine
To be added/defined in [`common.yaml`](https://git.psi.ch/linux-infra/puppet/-/blob/preprod/data/common.yaml)?
- GPFS
- Epics (available for RHEL7)
### pli-misc Repository
A small list of packages managed by the Linux Team.
- *RHEL8*: make v4.3 from [CentOS](https://rpmfind.net/linux/RPM/centos-stream/9/baseos/x86_64/make-4.3-7.el9.x86_64.html) as v4.2.1 has been reported to to make trouble
- latest [Zoom client](https://zoom.us/download?os=linux)
- latest [Webex client](https://www.webex.com/downloads.html)
- latest [Slack client](https://slack.com/downloads/linux)
- latest [NoMachine Enterprise Client](https://downloads.nomachine.com/download/?id=11)
- latest [Real VNC Viewer](https://www.realvnc.com/en/connect/download/viewer/), recommended for VNC remote access to Windows machines
- `pli-assets` containing the PSI and the Customer Self Service logo, any hints about the source rpm are welcome
- *RHEL8*: [mod_gearman v4.0.1](https://mod-gearman.org/download/v4.0.1/rhel8/x86_64/)
- *RHEL8*: lightdm-gtk v2.0.8-3.pli, a patched lightdm-gtk-greeter ([SRPM](https://git.psi.ch/linux-infra/lightdm-gtk-rpm), [PR](https://github.com/Xubuntu/lightdm-gtk-greeter/pull/121)) which allows to limit the presented keyboard layouts
- Code Beamer Office pluging v9.5.0 managed by Gilles Martin
- storecli 007.2007.0000.0000 managed by Marc Caubet Serrabou
- [pam_single_kcm_cache PAM Module](https://github.com/paulscherrerinstitute/pam_single_kcm_cache) managed by Konrad Bucheli
- [nvidia-detect](http://elrepo.org/tiki/nvidia-detect) copied over from ElRepo to make it generally available
- [bob](https://git.psi.ch/linux-infra/bob)
## Package Repositories made Available by other PSI Groups
- `tivoli`, IBM backup software for Arema, managed by Datacenter and DB Services, AIT
- `nxserver` for NoMachine NX
admin-guide/configuration/software/package_updates.md
+18
View File
@@ -0,0 +1,18 @@
# Automated Package Updates
The automatic updates are controlled in Hiera (excluding RHEL7):
| Hiera key | default | comments |
|-------------------------------------|------------|-------------------------------------------------------------------------------|
| `base::automatic_updates::interval` | `weekly` | valid are `daily`, `weekly` and `never` which disables the automatic updates |
| `base::automatic_updates::type` | `security` | `security` installs only security updates whereas `all` installs all updates |
| `base::automatic_updates::exclude` | `[]` | list of packages not to update, wildcards like "*" are allowed |
| `base::automatic_updates::kernel` | `false` | define if new kernel packages also should be installed automatically |
Note that the updates run on midnight, for `weekly` from Sunday to Monday. There is no automatic reboot, e.g. for kernel updates.
---
**Important**
There will be no updates if you fix the package source to a snapshot/repo tag i.e. `rpm_repos::tag` or `yum_client::repo_tag` setting in Hiera point to a specfic snapshot.
admin-guide/configuration/software/packages.md
+150
View File
@@ -0,0 +1,150 @@
# Package Installation
## Install Packages with Hiera Package Groups
The packages automatically installed onto a system by Puppet are managed in the Hiera list `base::package_groups`. It contains the names of the package groups to be installed. Items can be added at all levels of the Hiera hierarchy and are merged.
The package groups itself are Hieara lists named `base::pkg_group::$USE_CASE`.
Here list all the packages you want to install.
Currently there exist the following package groups in the main [`common.yaml`](https://git.psi.ch/linux-infra/puppet/-/blob/preprod/data/common.yaml):
- `base::pkg_group::system_tools` (installed by default)
- `base::pkg_group::daq_buffer`
- `base::pkg_group::desktop_settings`
- `base::pkg_group::dev`
- `base::pkg_group::login_server`
- `base::pkg_group::qt5`
- `base::pkg_group::root`
but further ones can be created in Hiera at lower hierachies and added to `base::package_groups`, for example
```
base::pkg_group::java:
- 'java-1.8.0-openjdk'
- 'java-11-openjdk'
- 'java-17-openjdk'
base::package_groups:
- 'java'
```
## Install a Group of Packages
To add a RedHat predefined group of packages (checkout out `dnf grouplist --hidden`) prepend the name of it with a `@`, e.g. for "Java Platform" it would be `@Java Platform`:
```
base::pkg_group::java:
- '@Java Platform'
```
## Install Latest Package Version
Puppet by default only checks if a package is installed and only installs it if missing.
To ensure that always the latest available package version is installed, append the `:latest` tag to the package name in the package group:
```
base::pkg_group::java:
- 'java-1.8.0-openjdk'
- 'java-11-openjdk'
- 'java-17-openjdk:latest'
```
## Install Packages only on Given OS Version
Certain packages are only used on a given OS Version, so a `os=` with the OS name and the major version selects a package only for given OS, where as a `os!` will filter away given package on hosts with given OS, so they are not installed there.
```
base::pkg_group::java:
- 'java-1.8.0-openjdk:os=redhat7'
- 'java-11-openjdk'
- 'java-17-openjdk:os!redhat7'
```
Note that this tag can be combined with the `latest` and `absent` tag.
## Install Module Stream
RHEL 8 introduced the concept of [module streams](https://docs.pagure.org/modularity/).
A specific stream can be selected with the `stream` tag:
```yaml
base::pkg_group::nodejs:
- 'nodejs:stream=12'
```
## Install Python Modules with `pip`
The `pip` tag can be used to install a PYPI Python package using `pip`, e.g. `pygame-utility`:
```yaml
base::pkg_group::my_pip_modules:
- 'pygame-utility:pip'
```
To install a packages for specific python versions use the tag `:pip<version>` (example: `- 'numpy:pip3.12'`).
Note that packages installed with `pip` are not updated automatically!
## Remove Packages
To remove an already installed package, append the `:absent` tag to the package name in the package group:
```
base::pkg_group::java:
- 'java-1.8.0-openjdk:absent'
- 'java-11-openjdk'
- 'java-17-openjdk'
```
## Ignore Packages
To make packages unavailable for installation, even though provided by the package repositories, add them in Hiera to the list `base::package_exclude`:
```
base::package_exclude:
- 'epics-base-7.0.6*'
```
This list is merged over the full Hiera hierachy, so there is no need to copy exclusions from higher levels when creating an exclusion on a low level.
This list can also be used to opt out packages from other, maybe inherited package groups. But unlike the `:absent` tag in a package list it will not uninstall a package when found.
### Version Lock
If you have the need to freeze a software on given version, you can use `dnf versionlock`. First you need to install the `python3-dnf-plugin-versionlock` package (see above).
Then on the node best run
```
dnf versionlock add $PACKAGE
```
for every package you do not wish to get updates installed any more. If there are newer packages you might test with `dnf update --assumeno` if it does not show your software any more, while other updates are still possible. Sometimes this can cause dependency resolution failures and you might need to add a version lock for one ore more packages which depend on the locked package.
After you best put the resulting `/etc/dnf/plugins/versionlock.list` in Hiera with [`files::files`](distribute_files) for reproducability.
#### Kernel Version Lock
A full kernel version lock needs to include a number of packages:
```
dnf versionlock add kernel kernel-core kernel-modules kernel-tools kernel-tools-libs kernel-headers kernel-devel
```
and if AFS is configured
```
dnf versionlock add kmod-yfs
```
### Install Debuginfo Packages
The package repositories for debuginfo packages are disabled by default. To spontaneously install such a package, do
```
dnf --enablerepo '*_debug' install ...
```
## Missing Package
If there is no such package in the repositories, then
```
Error: Execution of '/usr/bin/dnf -d 0 -e 1 -y install non-existing-package-for-test' returned 1: Error: Unable to find a match: non-existing-package-for-test
```
admin-guide/configuration/software/python.md
+81
View File
@@ -0,0 +1,81 @@
# Python
## Overview
```{note}
This guide only covers RHEL8/9 and newer. Also we will __not__ cover how to use Python 2 any more.
```
There are several versions of Python(3) available from RedHat. This guide shows how one can install specific/multiple versions and how to configure the default Python of a system.
The use of Python environments like [`venv`](https://docs.python.org/3/library/venv.html) or [Conda](https://docs.conda.io) is recommended if a single user needs one or multiple specific Python environments. But this is not part of this guide.
## Platform Python vs Default Python
As many system tools are written in Python each RHEL8/9 system comes with a so called Platform Python. This is a _fixed_ Python version than cannot be modified and usually is also not available via the commandline.
Beside that, on each system you can install multiple Python versions. One of this Python version can then be set as the Default Python. This means that this Python version is called if you call `python` and/or `python3` on the commandline/script.
To explicitly call a specific Python version always specify the full version as follows: `python<version>`, e.g. `python3.12`. The same applies to the `pip` command!
### Using the Platform Python
For system tools, that should run consistently on all systems you may decide to use the "Platform Python" instead of the Default Python. For doing so you need to set the shebang of your script to
```bash
#!/usr/libexec/platform-python
```
## Python Versions
On __RHEL8__ the Platform (and usual Default) Python version is __3.6__. As the time of writing following Python versions are additinally available: _3.8_, _3.9_, _3.11_, _3.12_ .
On __RHEL9__ the Platform (and usual Default) Python version is __3.9__. As the time of writing following Python versions are additinally available: _3.11_, _3.12_
## Configuration
Following hiera keys can be used to configure Python on a system.
### Installing and Setting a Default Python
To install a default Python you can use:
```yaml
python::default_version: '3.11'
```
This will make sure that that this Python version is installed on the system and that this Python version is available via the `python` and `python3` command. The same applies for `pip` and `pip3`.
### Installing Additional Python Versions
To install additional Python versions on the system you can use:
```yaml
python::install_versions: ['3.6', '3.12']
```
This will take care that the necessary packages are installed on the system. These versions are then available by calling the version specific Python command `python<version` (e.g. `python3.12`).
### Installing PYPI Packages
You can install PYPI packages for the individual Python versions the same way as installing RPMS on a system (i.e. via the Puppet package module).
This can be done by adding a label after the PYPI package name:
```yaml
base::pkg_group::python_packages:
- 'numpy:pip' # installs package for the systems default python
- 'numpy:pip3.12' # installs numpy via PYPI for `python3.12`
base::package_groups:
- 'python_packages'
```
__IMPORTANT:__ Note that packages installed with `pip` are not updated automatically!
For additional information on how to install packages (including `pip`) please check out [this guide](packages).
```{note}
The packages prefixed with `python3-` are for the default Default Python version. For newer versions RedHat has a versioned prefix like `python38-` or `python3.11-`. There might not be for all libraries packages for all availabe Python versions. Then you might need to install your library with `pip`.
```
admin-guide/configuration/software/selinux_configuration.md
+114
View File
@@ -0,0 +1,114 @@
# SELinux Configuration
SELinux can be configured in Hiera.
For troubleshooting SELinux related problems please have a look at [SELinux Troublehooting Guide](../troubleshooting/selinux)`
## Basic Settings
Enable or disable SELinux with `base::selinux`. Options:
* `enforcing`
* `permissive`
* `disabled`
Example:
```yaml
base::selinux_mode: 'disabled'
```
The default depends on the Puppet role, e.g. for servers it is `enforcing` while for workstations and consoles it is `disabled`.
The `permissive` option is useful for setting up a new server to see where SELinux would block if enabled.
## Logging Violations
To record such violations `auditd` needs to run:
```yaml
base::enable_auditd: true
```
On RHEL9 and later this is enabled by default if SELinux is `permissive` or `enforcing`.
Then `setroubleshootd` is very helpful to learn how to configure SELinux if an action is wrongly considered a violation:
```yaml
selinux::setroubleshootd: true
```
On RHEL9 and later this is enabled by default if SELinux is `permissive` or `enforcing`.
## Finetuning
### SELinux Booleans
Use NFS home directory:
```yaml
selinux::use_nfs_home_dirs: true
```
Set SELinux booleans:
```yaml
selinux::booleans: [ 'httpd_can_network_connect', 'domain_can_mmap_files']
```
### File Context (`fcontext`)
Set fcontext for specific directories/directory
```yaml
selinux::fcontext:
logbook-data:
pathspec: '/var/www/html/logbook-data(/.*)?'
seltype: 'httpd_sys_rw_content_t'
logbook-data-local:
pathspec: '/var/www/html/logbook-data-local(/.*)?'
seltype: 'httpd_sys_rw_content_t'
```
a unique arbitrary key name for each entry is needed.
If you wish to have the same fcontext configuation as another path do
```yaml
selinux::fcontext::equivalence:
apache_ssl_conf:
path: '/srv/online/config/ssl.conf'
target: '/etc/httpd/conf/httpd.conf'
apache_index_html:
path: '/srv/online/config/index.html'
target: '/var/www/html/index.html'
apache_online_web:
path: '/srv/online/web'
target: '/var/www/html'
apache_offlinecheck:
path: '/srv/offlinecheck'
target: '/var/www/html'
```
a unique arbitrary key name for each entry is needed here as well.
### Custom Module
Custom SELinux modules can also be added.
Such a module can be created from recorded violations with
```
ausearch --raw | audit2allow -r -m $CUSTOM_SELINUX_MODULE_NAME
```
Note that the `setroubleshootd` log output ususally gives you a narrower search filter for `ausearch` for each recorded violation.
Each such module needs to be added with a unique key at the Hiera key `selinux::modules::te`. A full example is
```yaml
selinux::modules::te:
# SELinux is preventing /usr/local/bin/musrview from setattr access on the directory /usr/lib/fontconfig/cache
'musrview-font-cache': |
module musrview-font-cache 1.0;
require {
type lib_t;
type httpd_sys_script_t;
class dir setattr;
}
allow httpd_sys_script_t lib_t:dir setattr;
```
Do not forget to increase the version number if you update such a module.
admin-guide/configuration/software/services.md
+105
View File
@@ -0,0 +1,105 @@
# Managing Services with Systemd
Hiera can also be used to manage services and to automate reoccuring tasks with timers.
## Enabling/Starting a Service
If the software already comes with an systemd unit file, then it is sufficient to just enable it in Hiera by using the `base::services` key:
```
base::services:
netdata:
enable: true
```
The key inside is the `systemd` service name without the `.service` suffix.
## Disabling/Stopping a Service
To stop and disable an already running service, disable it in the `base::services` Hiera key with `enable: false`:
```
base::services:
netdata:
enable: false
```
## Systemd Timers
To have custom executables run regulary on given time/interval, you may use the `base::timers` Hiera key:
```
base::timers:
'timer_test':
description: 'test timers'
command: '/usr/bin/logger foo'
on_calendar: '*:*:10'
timer_options:
persistence: false
```
For each timer following keys are mandatory
- `description` for a short explaination what it is about
- `command` for the command to run
- `on_calendar` defining when it should run using the [`systemd` calendar event format](https://www.freedesktop.org/software/systemd/man/systemd.time.html#Calendar%20Events), (alternatively see also chapter "CALENDAR EVENTS" of `man systemd.date`)
Optional is
- `timer_options` for additional options. In the example it is `persistence`which signals if the timer should run immediately after boot when the node was switched of on the last scheduled run time (default is `false`).
## Manage Services with Custom Unit Files
It is also possible to provide a full systemd unit file if there is none already. For this define the different secions and their content with subkeys below the `options` key as in below example:
```
# The following service stops users from accessing the node
# before the home directory is mounted
base::services:
'wait_for_home':
enable: true
options:
Unit:
Before: 'systemd-user-sessions.service'
Install:
WantedBy: 'multi-user.target'
RequiredBy: 'multi-user.target'
Service:
Type: 'oneshot'
ExecStart: '/opt/pli/libexec/waitformount -m /das/home'
RemainAfterExit: 'true'
```
If you need to set multiple values, then put the values into an list:
```
Service:
Environment:
- "FOO=bar"
- "BIZ=buz"
```
## Enhance a Service with a Dropin Unit File
It is possible to fine-tune already existing `systemd` unit files with dropins. These are placed as `.conf` files in `/etc/systemd/system/$SERVICE.service.d/`.
With the `dropin: true` setting the content of the `options` parameter is written into the according dropin directory:
```
base::services:
'name_of_enhanced_service':
enable: true
dropin: true
options:
...
```
Often this is done to start the service with different options, then you need to reset the orginal value with an emty entry:
```
base::services:
'name_of_enhanced_service':
enable: true
dropin: true
options:
Service:
ExecStart:
- ''
- '/usr/sbin/my_service --verbose'
```
If there are multiple dropins, you might also name them individually with the `dropin_name` parameter.