Merge branch 'master' of git.psi.ch:linux-infra/documentation
2
.dockerignore
Normal file
@@ -0,0 +1,2 @@
|
||||
.git*
|
||||
Dockerfile
|
||||
@@ -7,7 +7,7 @@ RUN install_packages pip jupyter-notebook python3-anyio python3-greenlet python3
|
||||
RUN pip install jupyter-book && rm -r /root/.cache/pip
|
||||
|
||||
RUN mkdir -p /root/documentation
|
||||
COPY * /root/documentation
|
||||
COPY . /root/documentation
|
||||
RUN cd /root/documentation && jupyter-book build .
|
||||
|
||||
# TODO make build book accessible through a webserver
|
||||
|
||||
21
_toc.yml
@@ -12,19 +12,24 @@ parts:
|
||||
- caption: Infrastructure Guide
|
||||
chapters:
|
||||
- file: infrastructure-guide/home
|
||||
sections:
|
||||
- file: infrastructure-guide/pxeserv01
|
||||
- file: infrastructure-guide/boot00
|
||||
- file: infrastructure-guide/puppet01
|
||||
- file: infrastructure-guide/repo00
|
||||
- file: infrastructure-guide/repo01
|
||||
- file: infrastructure-guide/reposync
|
||||
- file: infrastructure-guide/lxweb00
|
||||
- file: infrastructure-guide/login
|
||||
- file: infrastructure-guide/influx00
|
||||
- file: infrastructure-guide/metrics00
|
||||
- file: infrastructure-guide/lxsup00
|
||||
- file: infrastructure-guide/satint
|
||||
|
||||
- caption: RHEL8
|
||||
chapters:
|
||||
- file: rhel8/index
|
||||
sections:
|
||||
- file: rhel8/installation
|
||||
- file: rhel8/configuration
|
||||
- file: rhel8/vendor_documentation
|
||||
- file: rhel8/design_guiding_principles
|
||||
|
||||
- caption: RHEL8 Guides (Beta)
|
||||
chapters:
|
||||
- file: rhel8-guides-beta/developer_guide
|
||||
- file: rhel8-guides-beta/installation_guide
|
||||
- file: rhel8-guides-beta/admin_guide
|
||||
|
||||
BIN
admin-guide/deployment/_static/legacy_boot.png
Normal file
|
After Width: | Height: | Size: 127 KiB |
79
admin-guide/deployment/_static/legacy_boot.puml
Normal file
@@ -0,0 +1,79 @@
|
||||
@startuml
|
||||
|
||||
actor admin
|
||||
participant "BIOS Node\n(legacy boot)" as bootnode
|
||||
participant "QIP DHCP" as dhcp
|
||||
participant "pxeserv01.psi.ch" as pxeserver
|
||||
participant "boot00.psi.ch" as sysdb
|
||||
participant "repo00.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 "boot00.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/boot00.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 installs Red Hat 7.9.
|
||||
manually selectable are all
|
||||
Red Hat 7 versions 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
|
||||
|
||||
|
||||
@@ -32,6 +32,11 @@ 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 BIOS (Legacy) Boot Process
|
||||
--------------------------------------------------
|
||||
.. image:: _static/legacy_boot.png
|
||||
|
||||
|
||||
Building the iPXE boot image
|
||||
----------------------------
|
||||
|
||||
|
||||
@@ -33,7 +33,7 @@ and ``$ALIASES``::
|
||||
C = CH
|
||||
O = \$ORGNAME
|
||||
CN = \$FQDN
|
||||
OU = AIT
|
||||
OU = AWI
|
||||
|
||||
[ req_ext ]
|
||||
subjectAltName = \$ALTNAMES
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
Puppet client
|
||||
-------------
|
||||
|
||||
regular automatic Puppet client runs
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Puppet client run is executed once daily between 5AM and 8AM
|
||||
(``puppet_client::exec_time`` in hiera data).
|
||||
|
||||
@@ -15,6 +18,9 @@ The puppet client is executed via the ``pli-puppet-run`` system timer: ::
|
||||
2 timers listed.
|
||||
Pass --all to see loaded but inactive timers, too.
|
||||
|
||||
temporarily disable automatic Puppet client runs
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Puppet execution can be disabled for a certain amount of time with the
|
||||
``/opt/pli/libexec/pli-puppet-disable`` command: ::
|
||||
|
||||
@@ -31,3 +37,16 @@ Puppet execution can be disabled for a certain amount of time with the
|
||||
|
||||
The disabling time has to be in the ``date`` format (see date(1)).
|
||||
|
||||
|
||||
manually retrieve host information from Puppet
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To manually check the node information on the Puppet server for given host, do ::
|
||||
|
||||
FQDN=$(hostname --fqdn)
|
||||
curl \
|
||||
--cacert /etc/puppetlabs/puppet/ssl/certs/ca.pem \
|
||||
--cert /etc/puppetlabs/puppet/ssl/certs/$FQDN.pem \
|
||||
--key /etc/puppetlabs/puppet/ssl/private_keys/$FQDN.pem \
|
||||
"https://puppet01.psi.ch:8140/puppet/v3/node/$FQDN?environment=prod&configured_en" \
|
||||
| jq .
|
||||
|
||||
@@ -12,9 +12,9 @@ auditing. In particular, it
|
||||
Parameters
|
||||
----------
|
||||
|
||||
=============================== ======== ================================================
|
||||
=============================== ======== ==============================================================
|
||||
**Name** **Type** **Default**
|
||||
------------------------------- -------- ------------------------------------------------
|
||||
------------------------------- -------- --------------------------------------------------------------
|
||||
admins list hiera_array('aaa::admins')
|
||||
allow_sudoers_d bool hiera('aaa::allow_sudoers_d')
|
||||
bastions list hiera('aaa::bastions')
|
||||
@@ -32,9 +32,9 @@ 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('aaa::support_afs'),
|
||||
use_bastions bool hiera('aaa::use_bastions', undef)
|
||||
use_bastions bool hiera('aaa::use_bastions', $profile::networking::use_bastions)
|
||||
users list hiera_array('aaa::users', [])
|
||||
=============================== ======== ================================================
|
||||
=============================== ======== ==============================================================
|
||||
|
||||
|
||||
``admins``
|
||||
|
||||
@@ -25,10 +25,11 @@ journal_system_max_use string hiera('log_client::journal_system_max_us
|
||||
``journal_system_keep_free``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
How much space :manpage:`systemd-journald(8)` should keep free for non-journal
|
||||
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
|
||||
:manpage:`journald.conf(5)` we also support percentages, ie ``'25%'`` means that
|
||||
`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``
|
||||
@@ -41,8 +42,9 @@ The maximum size of individual journal files.
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The maximum amount of space that the journal is allowed to use. In addition to
|
||||
the syntax described in :manpage:`journald.conf(5)` we also support percentages,
|
||||
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``
|
||||
|
||||
@@ -22,10 +22,14 @@ variables listed below:
|
||||
|
||||
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``.
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
# boot00: SysDB API server
|
||||
|
||||
https://git.psi.ch/linux-infra/sysdb/ is pulled into /var/www/sysdb/app/ (no automation, just by hand)
|
||||
|
||||
httpd runs the service and it needs restarting, when pulling changes
|
||||
@@ -6,4 +8,4 @@ Access rights are granted on the environment level (bob env list). At this time,
|
||||
|
||||
Detailed documentation of the software is at:
|
||||
|
||||
http://linux-infra.gitpages.psi.ch/admin-guide/index.html
|
||||
https://linux.psi.ch/admin-guide/index.html
|
||||
|
||||
@@ -9,6 +9,8 @@ List of systems and their primary role:
|
||||
|
||||
* [repo00](repo00) - 129.129.160.212 - RPM/Yum repository server for RHEL7
|
||||
|
||||
* [repo01](repo01) - 129.129.190.190 - RPM/Yum repository server for RHEL8
|
||||
|
||||
* [reposync](reposync) - 129.129.161.222 - RPM/Yum repository server for RHEL8
|
||||
|
||||
* [lxweb00](lxweb00) - 129.129.190.46 - Exports further repositories from AFS
|
||||
@@ -52,7 +54,7 @@ Access to the redhat.com knowledge base:
|
||||
* [SSH config](sshconf)
|
||||
|
||||
# HTTPS Certificates
|
||||
* [HTTPS Certificates](https_certificates)
|
||||
* [HTTPS Certificates](https://linux.psi.ch/admin-guide/operations/certificates.html)
|
||||
|
||||
# SSH Certificates / Signing Public User Keys
|
||||
|
||||
|
||||
@@ -1,6 +0,0 @@
|
||||
# HTTPS Certificates
|
||||
|
||||
The https certificates and their requests for the web servers used in the core infrastructured are managed in this git repository:
|
||||
https://git.psi.ch/linux-infra/https_certificates
|
||||
|
||||
Details on how the https certs can be ordered / renewed can be found in the Readme of that repository.
|
||||
@@ -1,3 +1,5 @@
|
||||
# influx00
|
||||
|
||||
This is a RHEL7 machine and is puppet managed:
|
||||
https://git.psi.ch/linux-infra/data-pli/blob/master/default/influx00.psi.ch.yaml
|
||||
|
||||
@@ -98,4 +100,4 @@ Alias=influxd.service
|
||||
- What are the other open ports needed for? :111 :8086 :25 :8088
|
||||
|
||||
- 25 is postfix (SMTP), 111 belongs to NFS, the 80xx ports both belong to influx
|
||||
- It's certainly not being used, nothing is mounted or exported via NFS. It isn't even enabled in puppet for this host. However, most of the puppet works in a way, where it installs things, but doesn't remove anything, if the settings change. So if it was enabled at any time in the past, it was just left behind. Though the NFS service is not running, only the rpcbind is.
|
||||
- It's certainly not being used, nothing is mounted or exported via NFS. It isn't even enabled in puppet for this host. However, most of the puppet works in a way, where it installs things, but doesn't remove anything, if the settings change. So if it was enabled at any time in the past, it was just left behind. Though the NFS service is not running, only the rpcbind is.
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
# login
|
||||
|
||||
This is a cluster made up of 3 hosts, which all are VMs running on the AIT vmware cluster. These machines are pretty standard RHEL7 hosts managed by Puppet: https://git.psi.ch/linux-infra/data-pli/blob/master/login.yaml.
|
||||
|
||||
Info for users is published at https://intranet.psi.ch/de/computing/linux-login-clusters
|
||||
Info for users is published at https://intranet.psi.ch/de/computing/linux-login-clusters
|
||||
|
||||
@@ -1,2 +1,4 @@
|
||||
# lxsup00
|
||||
|
||||
This is a RHEL7 machine and is puppet managed:
|
||||
https://git.psi.ch/linux-infra/data-pli/blob/master/default/lxsup00.psi.ch.yaml
|
||||
https://git.psi.ch/linux-infra/data-pli/blob/master/default/lxsup00.psi.ch.yaml
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
# 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/data-pli/blob/master/default/lxweb00.psi.ch.yaml
|
||||
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
# metrics00
|
||||
|
||||
This machine is a RHEL7 machine and is puppet managed:
|
||||
https://git.psi.ch/linux-infra/data-pli/blob/master/default/metrics00.psi.ch.yaml
|
||||
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
# puppet01
|
||||
|
||||
Runs the puppet server for rhel7
|
||||
|
||||
The main code repositories are synced into:
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
# pxeserv01
|
||||
|
||||
The server is a RHEL 8, installed manually and registered directly with redhat.com . This is so that it's completely independent from anything else at PSI.
|
||||
|
||||
For historical reasons, the tftpboot directory is hosted on AFS. But for an unknown reason, the RHEL8 tftpd can not read the files from AFS. (It's not SELinux) So the data is mirrored to the local drive and is served from this copy.
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
# repo00
|
||||
|
||||
This machine is a RHEL7 system **not** under Puppet control. This machine has no AFS dependencies.
|
||||
The basic service provided by this system is: httpd
|
||||
|
||||
@@ -120,4 +122,4 @@ The rest were put there by hand. Much of it is probably not needed, but wouldn't
|
||||
|
||||
- Who belongs this repo? https://repo00.psi.ch/mt86/ (I guess mt86 is a person short code - unfortunately I cannot find this code in the phonebook)
|
||||
|
||||
- It's memory test for x86 systems, not a person at PSI.
|
||||
- It's memory test for x86 systems, not a person at PSI.
|
||||
|
||||
84
infrastructure-guide/repo01.md
Normal file
@@ -0,0 +1,84 @@
|
||||
# repo01.psi.ch
|
||||
|
||||
This machine is a RHEL8 system **not** under Puppet control. This machine has no AFS dependencies.
|
||||
The basic service provided by this system is: httpd
|
||||
|
||||
This machine acts as a mirror for the RHEL8 iso images.
|
||||
|
||||
Repo01 is connected to the Satelitte server from ETH Zürich. The Red Hat repositories are synced from there.
|
||||
|
||||
The installer iso images are downloaded from https://access.redhat.com/downloads and put into `/var/www/html/iso` manually
|
||||
|
||||
The iso images in `/var/www/html/iso` are then (automatically) mounted as loop devices by the pli-mount-iso-images.service under `/etc/systemd/system/`. Otherwise changes are not monitored, if a new iso is put there, a manual restart of the service is required for anything to happen.
|
||||
|
||||
```bash
|
||||
df -kh | grep /var/www
|
||||
/dev/loop0 11G 11G 0 100% /var/www/html/iso/rhel85 /dev/loop1 6.7G 6.7G 0 100% /var/www/html/iso/rhel80
|
||||
```
|
||||
|
||||
Under `/opt/pli/libexec` exist five shell scripts that run with systemctl timer.
|
||||
|
||||
The pli-repo-mirror runs a daily sync (at 21:30) via `/etc/systemd/system/pli-repo-mirror.timer`, which pulls the latest repos into `/var/www/html/el8/sources`.
|
||||
|
||||
The `gen-snapshot-page` is the basic script to generate a snapshot.
|
||||
|
||||
From the above, a weekly snapshot (at Sun 23:30) is taken by the `pli-repo-snapshot` via the `pli-repo-snapshot.timer`
|
||||
|
||||
From there the snapshot_is_prodable checks wheter the new snapshot is ready for a new prod tag.
|
||||
It will check if the latest yfs kernel module corresponds with the latest rhel8 kernel.
|
||||
If the kernel and the yfs module version correspond a prod snapshot is made under `/var/www/html/el8/tags`
|
||||
|
||||
The `pli-repo-zoom` is run via the `pli-repo-zoom.timer`. It maintains the zoom repo at `/var/www/html/zoom/`
|
||||
|
||||
The `pli-repo-yfs` script is run via the `pli-repo-yfs.timer`. It syncs the auristor repo and apparently also create tags.
|
||||
|
||||
In case of emergency, you can run a snapshot by force. Then you have to add the version before you can run the script
|
||||
|
||||
```bash
|
||||
$./pli-repo-snapshot el8
|
||||
```
|
||||
Under `/etc/systemd/system/` we have all the `pli-repo*` timer and service configurations.
|
||||
In order to start a new timer/service, the service and timer have to be a enabled.
|
||||
|
||||
|
||||
Under `/opt/pli/etc/mirror/` you find the repolist, cuda and yum.conf
|
||||
|
||||
Under `/etc/yum.repos.d/` you find the redhat.repo. This are the Red Hat repositories that are synced from ETH.
|
||||
|
||||
Under `/var/www/html/el8/keys/` you find the rpm-gpg-keys
|
||||
Under `/var/www/html/el8/manual/` you find the repos for nxserver. There is no automatic synchronisation for the rpms, they will be downloaded manually from the responsible person.
|
||||
Under `/var/www/html/el8/snapshots/` you will find all the preprod snapshots
|
||||
Under `/var/www/html/el8/sources` you will find the packages and repodata from synced rpms.
|
||||
Under `/var/www/html/el8/tags/` you will find all prod tags
|
||||
|
||||
|
||||
Under `/var/www/html/ipxe` is for testing purposes
|
||||
Under `/var/www/html/iso` you find the rhel-8.0 and the rhel-8.5 iso image.
|
||||
Under `/var/www/html/ks-test` you find the new kickstart directory, for testing. If all works this can be deleted.
|
||||
|
||||
The URI is https://repo01.psi.ch/el8/sources/
|
||||
|
||||
Provided http services:
|
||||
|
||||
```bash
|
||||
[root@repo01 ~]# netstat -tulnp | grep http
|
||||
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 3634/httpd
|
||||
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 3634/httpd
|
||||
```
|
||||
|
||||
The httpd configuration can be found in `/etc/httpd/conf.d`
|
||||
|
||||
```bash
|
||||
[root@repo01 ~]# ls -l /etc/httpd/conf.d/
|
||||
total 12
|
||||
-rw-r--r--. 1 root root 694 Apr 9 2019 25-repo01.psi.ch_non_ssl.conf
|
||||
-rw-r--r--. 1 root root 1131 Apr 9 2019 25-repo01.psi.ch_ssl.conf
|
||||
-rw-r--r--. 1 root root 366 Oct 9 2020 README
|
||||
``````
|
||||
|
||||
The ssl certificate is located in `/etc/pki/tls/certs`
|
||||
|
||||
For the certificate renewal the CSR configuration is under /root/certs
|
||||
|
||||
|
||||
https://git.psi.ch/linux-infra/repo01_pli-scripts
|
||||
@@ -1,3 +1,5 @@
|
||||
# reposync
|
||||
|
||||
This server exports all repositories for RHEL8 and uses btrfs to keep weekly snapshots of these. The btrfs is mounted at /var/www/html . Here the 'hot' directory is a sub-volume and the 'cold-*' directories are snapshots of the hot.
|
||||
|
||||
This system forms an integral part of the psi.packer ansible role.
|
||||
|
||||
@@ -1,7 +1,9 @@
|
||||
# satint
|
||||
|
||||
Manually installed installed RHEL7, registered directly with redhat.com
|
||||
|
||||
Standard RH Satellite installation through the puppet-based foreman installer. To install any extra packages or perform upgrades, the foreman-maintain command has to be used.
|
||||
|
||||
* **/root/httpd_psi_hack.sh** - Enables the non-authenticated access of the repositories stored on the host. Necessary to run after most foreman-maintain runs.
|
||||
|
||||
In case of issues with the manifest or anything else around the redhat.com account, contact **rhn@id.ethz.ch**
|
||||
In case of issues with the manifest or anything else around the redhat.com account, contact **rhn@id.ethz.ch**
|
||||
|
||||
229
infrastructure-guide/satint02.md
Normal file
@@ -0,0 +1,229 @@
|
||||
# satint02.psi.ch
|
||||
|
||||
For detailed documentation please refer to https://access.redhat.com/documentation/en-us/red_hat_satellite/6.10/html/administering_red_hat_satellite/index
|
||||
|
||||
Below are the PSI specific settings and documentation.
|
||||
|
||||
|
||||
Manually installed with RHEL7, registered directly with redhat.com through ETH Zürich.
|
||||
|
||||
The Satellite Server is setup with the latest version of RHEL7. The VM is connected to Netapp.
|
||||
SELinux is enabled and not supported.
|
||||
|
||||
The Satellite Server is connected to our Active Directory.
|
||||
|
||||
Satellite Server has an integrated Capsule and any host that is directly connected to Satellite Server is a Client of Satellite.
|
||||
|
||||
Red Hat Content Delivery network is protected by x.509 cert authentication to ensure that only valid users can access it.
|
||||
Directory and Structure of CDN:
|
||||
```
|
||||
[root@satint02 ~]# tree -d -L 11
|
||||
.
|
||||
├── satellite_cert
|
||||
└── ssl-build
|
||||
├── localhost
|
||||
└── satint02.psi.ch
|
||||
```
|
||||
|
||||
After installing Satellite with the satellite-installer command, all Satellite services are started and enabled automatically. View the list of these services by executing:
|
||||
```
|
||||
# satellite-maintain service list
|
||||
```
|
||||
To see the status of running services, execute:
|
||||
```
|
||||
# satellite-maintain service status
|
||||
```
|
||||
To stop the satellite-maintain services, execute:
|
||||
```
|
||||
# satellite-maintain service stop
|
||||
```
|
||||
To start the satellite-maintain services, execute:
|
||||
```
|
||||
# satellite-maintain service start
|
||||
```
|
||||
To restart the satellite-maintain services, execute:
|
||||
|
||||
## Create a User
|
||||
Ensure that you are logged on to the Satellite web UI as a user with administrator privileges for Satellite.
|
||||
|
||||
- Navigate to Administer > Users.
|
||||
- Click Create User.
|
||||
- In the Login field, enter a username for the user.
|
||||
- In the Firstname and Lastname fields, enter the real first name and last name of the user.
|
||||
- In the Mail field, enter the user’s email address.
|
||||
- In the Description field, add a description of the new user.
|
||||
|
||||
For CLI
|
||||
```
|
||||
# hammer user create \
|
||||
--login user_name \
|
||||
--password user_password \
|
||||
--mail user_mail \
|
||||
--auth-source-id 1 \
|
||||
--organization-ids org_ID1,org_ID2...
|
||||
```
|
||||
|
||||
## Assigning Roles to a User
|
||||
Ensure that you are logged on to the Satellite web UI as a user with administrator privileges for Satellite.
|
||||
|
||||
- Navigate to Administer > Users.
|
||||
- Click the username of the user to be assigned one or more roles.
|
||||
- Click the Organizations tab, and check that an organization is assigned.
|
||||
- Click the Roles tab to display the list of available roles.
|
||||
- Select the roles to assign from the Roles list.
|
||||
- To grant all the available permissions, select the Admin check box.
|
||||
- Click Submit.
|
||||
|
||||
For CLI
|
||||
```
|
||||
# hammer user add-role --id user_id --role role_name
|
||||
```
|
||||
|
||||
## Managing SSH Keys for a User
|
||||
Navigate to Administer > Users.
|
||||
From the Username column, click on the username of the required user.
|
||||
Click on the SSH Keys tab.
|
||||
Add SSH key
|
||||
|
||||
For CLI
|
||||
```
|
||||
# hammer user ssh-keys add \
|
||||
--user-id user_id \
|
||||
--name key_name \
|
||||
--key-file ~/.ssh/id_rsa.pub
|
||||
```
|
||||
|
||||
## Monitoring
|
||||
|
||||
The Red Hat Satellite content dashboard contains various widgets which provide an overview of the host configuration, Content Views, compliance reports, subscriptions and hosts currently registered, promotions and synchronization, and a list of the latest notifications.
|
||||
|
||||
In the GUI you can navigate to Monitor > Dashbord to see an overview. If you click a particular configuration status, you see the associated hosts.
|
||||
|
||||
Under Monitor > Facts you can see a combination of applications to gather information about managed hosts and to ensure that those hosts are maintained in the desired state. These applications include:
|
||||
- Foreman: Provides for the provisioning and life cycle management of physical and virtual systems. Foreman automatically configures these systems using various methods, including kickstart and Puppet modules.
|
||||
- Puppet: A client/server architecture for configuring hosts, consisting of the Puppet master (server) and the Puppet agent (client).
|
||||
- Facter: Puppet’s system inventory tool. Facter gathers basic information (facts) about hosts such as hardware details, network settings, OS type and version, IP addresses, MAC addresses, SSH keys, and more. These facts are then made available in Puppet manifests as variables.
|
||||
|
||||
Under Monitor > Audits there you will find a report on changes made by a specific user.
|
||||
|
||||
Under Monitor > Reports > Report Templates are there to schedule reports, you can configure a cron job or use the Satellite web UI.
|
||||
|
||||
- In the Satellite web UI, navigate to Monitor > Report Templates.
|
||||
- To the right of the report template that you want to use, click Generate.
|
||||
|
||||
CLI procedure
|
||||
|
||||
To generate a report, complete the following steps:
|
||||
|
||||
List all available report templates:
|
||||
```
|
||||
# hammer report-template list
|
||||
```
|
||||
Generate a report:
|
||||
```
|
||||
# hammer report-template generate --id template ID
|
||||
```
|
||||
If you go to Monitor > Satellite Task > Task you find a overview of all tasks.
|
||||
|
||||
|
||||
## Content
|
||||
|
||||
Under Content > Subscriptions you find an overview of all subscriptions and the Manifest. Satellite requires a Subscription Manifest to find, access, and download content from the corresponding repositories.
|
||||
|
||||
Under Content > Red Hat Repositories you find all available rpms. Here you can choose which repos should be mirrored /enabled.
|
||||
|
||||
Under Content > Products you can find a list of all mirrored repositories.
|
||||
|
||||
Under Content > Content Credentials here you can upload the SSL certs or GPG keys for new subscriptions.
|
||||
|
||||
Under Content > Sync Plans here you can see all created sync plans and you can create a new one.
|
||||
|
||||
Under Content > Sync Status here you can see a detailed overview of all rpms. You can ckeck details like; Start Time, Duration, Details and Result.
|
||||
|
||||
|
||||
Importing a Subscription Manifest into Satellite Server
|
||||
Procedure
|
||||
|
||||
- In the Satellite web UI, ensure the context is set to the organization you want to use.
|
||||
- Navigate to Content > Subscriptions and click Manage Manifest.
|
||||
- In the Manage Manifest window, click Browse.
|
||||
- Navigate to the location that contains the Subscription Manifest file, then click Open. If the Manage Manifest window does not close automatically, click Close to return to the Subscriptions window.
|
||||
|
||||
Lifecycle: this functionality is covered by repo01.
|
||||
|
||||
## Hosts
|
||||
|
||||
Under Hosts > Host you find a list of all hosts who are connected to Satellite server
|
||||
|
||||
Under Hosts > Discovered Hosts Satellite can detect hosts on a network that are not in our Satellite inventory. These hosts boot the discovery image that performs hardware detection and relays this information back to Satellite Server. This method creates a list of ready-to-provision hosts in Satellite Server without needing to enter the MAC address of each host.
|
||||
|
||||
Under Hosts > Create Hosts a host on the Satellite server
|
||||
|
||||
To create a host in Satellite
|
||||
|
||||
Procedure
|
||||
|
||||
- In the Satellite web UI, click Hosts > Create Host.
|
||||
- On the Host tab, enter the required details.
|
||||
- e.g. MAC address > Enter the MAC address.
|
||||
- DNS name > Enter the DNS name that is known to the DNS server $FQDN
|
||||
- Domain > Select the domain name of the provisioning network. This automatically updates the Subnet list with a selection of suitable subnets.
|
||||
|
||||
CLI procedure
|
||||
|
||||
To create a host associated to a host group, enter the following command:
|
||||
```
|
||||
# hammer host create \
|
||||
--name "host_name" \
|
||||
--hostgroup "hostgroup_name" \
|
||||
--interface="primary=true, \
|
||||
provision=true, \
|
||||
mac=mac_address, \
|
||||
ip=ip_address" \
|
||||
--organization "Your_Organization" \
|
||||
--location "Your_Location" \
|
||||
--ask-root-password yes
|
||||
```
|
||||
|
||||
Under Hosts > Content Hosts you find a overview of hosts and there corrent status of installable updates
|
||||
|
||||
Under Hosts > Register Hosts you can register a host to Satellite server
|
||||
|
||||
To Register a Host to Satellite server
|
||||
|
||||
Procedure
|
||||
- Navigate to Hosts > Register Host.
|
||||
- Optional: Select a different Organization.
|
||||
- Optional: Select a different Location.
|
||||
- Optional: From the Host Group list, select the host group to associate the hosts with. Fields that inherit value from Host group: Operating system, Activation Keys and Lifecycle environment.
|
||||
|
||||
|
||||
|
||||
Under Hosts > Provisioning Setup you find all information from Satellite server as, Architectures, Hardeware, Installation and operating system.
|
||||
|
||||
|
||||
|
||||
## Configure
|
||||
|
||||
Under Configure you can make the configuration for hosts group, Puppet and Ansible. No configuration has been made there right now.
|
||||
|
||||
## Infrastructure
|
||||
|
||||
Under Infrastructure > Capsules you find information about the Capsul server who provide content federation and run localized services to discover, provision, control, and configure hosts.
|
||||
|
||||
Administer
|
||||
|
||||
Under Administer > Location you can find the Location of the organization.
|
||||
|
||||
Under Administer > Organization you see the details to the registerd Organization PSI.
|
||||
|
||||
Under Administer > you can see that our Satellite server authentication source is AD.
|
||||
|
||||
Under Administer > Users here you find all registered users. Here you can also create a new user and give the user admin rights.
|
||||
|
||||
Under Administer > User Groups you can create user groups assign them roles and give them rights.
|
||||
|
||||
Under Administer > Settings you find all configuration and information for the Satellite server.
|
||||
|
||||
|
||||
In case of issues with the manifest or anything else around the redhat.com account, contact **rhn@id.ethz.ch**
|
||||
@@ -1,988 +0,0 @@
|
||||
# Admin Guide
|
||||
|
||||
## Introduction
|
||||
> This guide can be copy-pasted for the next release and changed accordingly
|
||||
|
||||
This document aims to describe PSI Linux Administrators how to configure *PSI's Red Hat Enterprise Linux 8* with *Ansible Inventory* settings. Use cases with configuration examples will explain the configuration that can be achieved.
|
||||
|
||||
The settings presented here can either be applied on a host or on a group of hosts or groups.
|
||||
|
||||
Intermediate understanding of Ansible is a prerequisite.
|
||||
|
||||
**Only important use cases are covered, others can be inquired with the respective Ansible Role owner**
|
||||
|
||||
## Table of Contents
|
||||
|
||||
* [Examples](#examples)
|
||||
* Ansible Inventories
|
||||
* [RHEL-8 PSI Defaults](#rhel-8-psi-defaults)
|
||||
* [AIT](#ait)
|
||||
* [CPT](#cpt)
|
||||
* [GFA](#gfa)
|
||||
* [HPCE](#hpce)
|
||||
* Use Cases
|
||||
* [System Information and Responsibility](#system-information-and-responsibilty)
|
||||
* [Network Configuration](#network-configuration)
|
||||
* [Storage Configuration](#storage-configuration)
|
||||
* [Icinga/NRPE/SNMP](#icinga-client-nrpe-and-snmp)
|
||||
* [System Registration](#system-registration)
|
||||
* [System Security](#system-security)
|
||||
* [Systemd Services](#systemd-services)
|
||||
* [System Time](#system-timentp)
|
||||
* [User Management](#user-management)
|
||||
* [Software Management](#software-management)
|
||||
* [AFS](#afs)
|
||||
|
||||
## Examples
|
||||
|
||||
Easy, simple and understandable examples are available under [PSI RHEL-8 RC1 Examples](https://git.psi.ch/linux/engineering/ansible/inventories/psi-rhel-8-rc1-examples/tree/master)
|
||||
|
||||
## Ansible Inventories
|
||||
|
||||
### RHEL-8 PSI Defaults
|
||||
|
||||
This repository hosts the PSI wide defaults inventory. It automatically groups systems from Satellite to AIT, CPT, GFA or HPCE. Link [here](https://git.psi.ch/linux/engineering/ansible/inventories/rhel-8-psi-defaults).
|
||||
|
||||
### AIT
|
||||
|
||||
[Ansible Inventory Git Repository](https://git.psi.ch/linux/engineering/ansible/inventories/ait) for AIT.
|
||||
|
||||
### CPT
|
||||
|
||||
[Ansible Inventory Git Repository](https://git.psi.ch/linux/engineering/ansible/inventories/cpt) for cpt.
|
||||
|
||||
### GFA
|
||||
|
||||
[Ansible Inventory Git Repository](https://git.psi.ch/linux/engineering/ansible/inventories/gfa) for gfa.
|
||||
|
||||
### HPCE
|
||||
|
||||
[Ansible Inventory Git Repository](https://git.psi.ch/linux/engineering/ansible/inventories/hpce) for hpce.
|
||||
|
||||
## Use cases
|
||||
|
||||
### System Information and Responsibilty
|
||||
Owned by @kapeller
|
||||
|
||||
The system `/etc/motd` can be changed by settings as
|
||||
|
||||
```yaml
|
||||
psi_motd_ou: CPT
|
||||
psi_motd_contact: Gilles Martin <gilles.martin@psi.ch> / +41 56 310 36 90
|
||||
```
|
||||
|
||||
or
|
||||
|
||||
```yaml
|
||||
psi_motd_ou: AIT
|
||||
psi_motd_contact_list: true
|
||||
psi_motd_contact:
|
||||
- Alvise Dorigo <alvise.dorigo@psi.ch> / +41 56 310 55 67
|
||||
- Leonardo Sala <leonardo.sala@psi.ch> / +41 56 310 33 69
|
||||
```
|
||||
|
||||
additional information can be provided as well
|
||||
|
||||
```yaml
|
||||
psi_motd_ou: AIT
|
||||
psi_motd_contact_list: true
|
||||
psi_motd_contact:
|
||||
- Alvise Dorigo <alvise.dorigo@psi.ch> / +41 56 310 55 67
|
||||
- Leonardo Sala <leonardo.sala@psi.ch> / +41 56 310 33 69
|
||||
psi_motd_additional: |
|
||||
Please be careful with this system.
|
||||
It is very sensitive.
|
||||
```
|
||||
|
||||
|
||||
---
|
||||
### Network Configuration
|
||||
Owned by @caubet_m
|
||||
|
||||
#### Configuring bonding re-using existing IP and interface
|
||||
|
||||
First, one needs to remove the **"System eth0"** created during the installation which is the active interface. Then, one can create the bonding with a master interface (i.e. `bond0`) and the slave interface with a new name (i.e. `eth0` and, when using NetworkManager, it will generate a new `connection.id`). We ensure that the *state is up* and we *allow network restart* to apply changes on the fly, and we *persistent* changes.
|
||||
|
||||
**Note:** Is important to have it persistent and state *up* and `network_allow_restart` for applying **online** changes affecting to a connected interface, otherwise the network service (or machine) needs to be rebooted.
|
||||
|
||||
```yaml
|
||||
- hosts: all,rhel-8-dev-7a95e9bb.psi.ch
|
||||
vars:
|
||||
network_allow_restart: yes
|
||||
network_connections:
|
||||
- name: "System eth0"
|
||||
persistent_state: absent
|
||||
state: down
|
||||
- name: bond0
|
||||
type: bond
|
||||
interface_name: bond0
|
||||
bond:
|
||||
mode: 'active-backup'
|
||||
miimon: 100
|
||||
persistent_state: present
|
||||
ip:
|
||||
address: "{{ ansible_default_ipv4.address }}/24"
|
||||
dns:
|
||||
- 129.129.190.11
|
||||
- 129.129.230.11
|
||||
dns_search:
|
||||
- psi.ch
|
||||
gateway4: '{{ ansible_default_ipv4.gateway }}'
|
||||
state: up
|
||||
- name: eth0
|
||||
type: ethernet
|
||||
interface_name: eth0
|
||||
persistent_state: present
|
||||
mac: "{{ ansible_default_ipv4.macaddress }}"
|
||||
master: bond0
|
||||
slave_type: bond
|
||||
state: up
|
||||
roles:
|
||||
- linux-system-roles.network
|
||||
```
|
||||
|
||||
#### DHCP interfaces
|
||||
|
||||
Adding a new interface `eth1` with *dhcp* protocol for getting the IP address:
|
||||
|
||||
```yaml
|
||||
- hosts: all,rhel-8-dev-7a95e9bb.psi.ch
|
||||
vars:
|
||||
network_allow_restart: yes
|
||||
network_connections:
|
||||
- name: eth1
|
||||
type: ethernet
|
||||
interface_name: eth1
|
||||
persistent_state: present
|
||||
mac: "0A:0B:0C:0D:0E:0F"
|
||||
ip:
|
||||
dhcp4: yes
|
||||
state: up
|
||||
```
|
||||
|
||||
#### Using ethtool for changing interface settings
|
||||
|
||||
One can change network specific settings on an interface with ethtool. In example, we wante to disable `scatter-gather`:
|
||||
|
||||
```shell
|
||||
[root@rhel-8-dev-7a95e9bb ~]# ethtool -k eth0 | grep scatter-gather
|
||||
scatter-gather: on
|
||||
tx-scatter-gather: on
|
||||
tx-scatter-gather-fraglist: off [fixed]
|
||||
```
|
||||
|
||||
We can modify with *ethtool* the interface to change this setting as follows:
|
||||
|
||||
```yaml
|
||||
- hosts: all,rhel-8-dev-7a95e9bb.psi.ch
|
||||
vars:
|
||||
network_allow_restart: yes
|
||||
network_connections:
|
||||
- name: eth0
|
||||
type: ethernet
|
||||
interface_name: eth0
|
||||
persistent_state: present
|
||||
mac: "{{ ansible_default_ipv4.macaddress }}"
|
||||
ip:
|
||||
dhcp4: yes
|
||||
state: up
|
||||
ethtool:
|
||||
features:
|
||||
tx_scatter_gather: no
|
||||
```
|
||||
|
||||
As a result, we disable `scatter-gather`.
|
||||
|
||||
```shell
|
||||
[root@rhel-8-dev-7a95e9bb ~]# ethtool -k eth0 | grep scatter-gather
|
||||
scatter-gather: off
|
||||
tx-scatter-gather: off
|
||||
tx-scatter-gather-fraglist: off [fixed]
|
||||
```
|
||||
|
||||
---
|
||||
### Icinga client (NRPE) and SNMP
|
||||
|
||||
#### NRPE
|
||||
|
||||
For enabling the Nagios client together with NRPE, is necesary to have EPEL in the system (either enabled or disabled). Also, one needs to enable `psi_icinga_client_configure_nrpe`. In case that EPEL is not available in the system, one can enable the installation of the repository from the module itself (by enabling `psi_icinga_client_configure_epel`, which takes it from the official EPEL repositories.
|
||||
|
||||
Important parameters are:
|
||||
* `psi_icinga_client_nrpe_allowed_hosts` (`String`) where one should specify a comma separated list of allowed hosts. Usually, this will be centrally updated from the default variables inventory, however, when a new Nagios worker or server is setup, might be useful to update this setting until this is centrally changed.
|
||||
* `psi_icinga_client_nrpe_dont_blame` (`Boolean`) , this option determines whether or not the NRPE daemon will allow clients to specify arguments to commands that are executed. Since this option is a security risk, is disabled by default. However, there are many cases where this is needed, so this is the reason why is provided (under administrator's responsability).
|
||||
* `psi_icinga_client_nrpe_allow_bash_command_substitution` (`Boolean`) , which determines whether or not the NRPE daemon will allow clients to specify arguments that contain bash command substitutions of the form $(...). Since this is also a security risk, is default by default.
|
||||
* Icinga checks, which have three different variables. The reason for that is that Ansible is not capable to merge down variables, and this is the way to workaround it. Each settins is a `Hash` where:
|
||||
* Item name is the file name that will be placed in `include_dir` (usually `/etc/nrpe.d/`).
|
||||
* For each item:
|
||||
* one or more `commands` can be specified, and will be placed in the same file
|
||||
* all commands specified in that file, might need sudo or not. One can enable `sudo` for that file, which will place the proper sudoers rules in the default sudoers location (usually `/etc/sudoers.d/`).
|
||||
* The 3 variables are:
|
||||
* `psi_icinga_client_nagios_include_dir_checks` (`Hash`)
|
||||
* `psi_icinga_client_nagios_include_dir_checks_common` (`Hash`)
|
||||
* `psi_icinga_client_nagios_include_dir_checks_extra` (`Hash`)
|
||||
|
||||
An example for setting Icinga alarms is the following:
|
||||
|
||||
```yaml
|
||||
# Allow different Icinga hosts (PSI workers)
|
||||
psi_icinga_client_nrpe_allowed_hosts: "emonma00.psi.ch,vemonma00.psi.ch,wmonag00.psi.ch,emonag00.psi.ch,eadmin00.psi.ch,wadmin00.psi.ch,monaggfa.psi.ch,monaggfa2.psi.ch,monagxbl.psi.ch,wmonagcpt.psi.ch,vwmonagcpt.psi.ch,monagmisc.psi.ch,wmonagnet.psi.ch,vwmonagnet.psi.ch,monagsfel.psi.ch"
|
||||
|
||||
# Allow arguments: NRPE Don't Blame
|
||||
psi_icinga_client_nrpe_dont_blame: True
|
||||
|
||||
# Allow arguments: Bash Command Substitution
|
||||
psi_icinga_client_nrpe_allow_bash_command_substitution: True
|
||||
|
||||
# Define NRPE checks with and withou "sudo"
|
||||
psi_icinga_client_nagios_include_dir_checks:
|
||||
system_checks:
|
||||
commands:
|
||||
- command: "check_disk"
|
||||
path: "{{ psi_icinga_client_nagios_plugins_dir }}/check_disk"
|
||||
arguments: "$ARG1$"
|
||||
- command: "check_load"
|
||||
path: "{{ psi_icinga_client_nagios_plugins_dir }}/check_load"
|
||||
arguments: "$ARG1$"psi_icinga_client_nagios_include_dir_checks_common
|
||||
|
||||
psi_icinga_client_nagios_include_dir_checks_common: {}
|
||||
|
||||
psi_icinga_client_nagios_include_dir_checks_extra:
|
||||
gpfs_checks:
|
||||
sudo: True
|
||||
commands:
|
||||
- command: "check_gpfs_health"
|
||||
path: "{{ psi_icinga_client_nagios_plugins_dir }}/check_gpfs_health"
|
||||
arguments: "--unhealth --ignore-tips"
|
||||
```
|
||||
|
||||
#### SNMP
|
||||
|
||||
For enabling SNMP, one needs to enable `psi_icinga_client_configure_snmp`. Once enabled, default settings should be ok for most of the use cases. However, is important to update at least:
|
||||
* `psi_icinga_client_snmpd_syscontact` (which defaults to *servicesdesk@psi.ch*)
|
||||
* `psi_icinga_client_snmpd_rocommunity`, which by default contains only the *PSI public network* (129.129.0.0/16) and *localhost*. Hence, one needs to specify extra networks if necessary.
|
||||
|
||||
An example for configuring SNMP:
|
||||
|
||||
```yaml
|
||||
# Configure SNMP
|
||||
psi_icinga_client_configure_snmp: True
|
||||
psi_icinga_client_snmpd_dontLogTCPWrappersConnects: true
|
||||
psi_icinga_client_snmpd_trapcommunity: psi
|
||||
psi_icinga_client_snmpd_syslocation: PSI
|
||||
psi_icinga_client_snmpd_syscontact: marc.caubet@psi.ch
|
||||
psi_icinga_client_snmpd_sysservices: 76
|
||||
psi_icinga_client_snmpd_rocommunity:
|
||||
- community: psi
|
||||
network: 172.21.0.0/16
|
||||
oid: .1.3.6.1
|
||||
- community: psi
|
||||
network: 129.129.0.0/16
|
||||
oid: .1.3.6.1
|
||||
- community: psi
|
||||
network: 192.168.1.0/24
|
||||
oid: .1.3.6.1
|
||||
- community: psi
|
||||
network: localhost
|
||||
oid: .1.3.6.1
|
||||
```
|
||||
---
|
||||
### Storage Configuration
|
||||
Owned by @dorigo_a
|
||||
|
||||
#### Configuring a partition
|
||||
Define the following variable:
|
||||
```yaml
|
||||
psi_local_storage_physical_volume:
|
||||
- /dev/<device>
|
||||
```
|
||||
This just tells to Ansible which device (or partition) must be used for the creation/modification of a volume group.
|
||||
Multiple instances can be used; for example:
|
||||
```yaml
|
||||
psi_local_storage_physical_volumes:
|
||||
- /dev/sdb1
|
||||
- /dev/sdb2
|
||||
...
|
||||
- /dev/sdb5
|
||||
```
|
||||
|
||||
|
||||
`<device>` can be either a block device (`sda`, `sdb`, …) or a partition previously (and manually) created in a block device using `fdisk/parted` (`sda1`, `sdc3`,...).
|
||||
|
||||
#### Configuring a volume group
|
||||
```yaml
|
||||
psi_local_storage_physical_name: <vg_name>
|
||||
```
|
||||
`<vg_name>` is the name of a new volume group or the name of an existing volume group in which one wants to create/modify logical volumes.
|
||||
If the volume group already exists the role will simply add to it the new physical volumes specified in the previous variable `psi_local_storage_physical_volumes`, or no action is taken if the volume group is already built on top of the same physical volumes.
|
||||
|
||||
#### Configuring a logical volume
|
||||
```yaml
|
||||
psi_local_storage_logical_volumes:
|
||||
- name: <lv_name>
|
||||
size: N # size in unit of GB
|
||||
fstype: ext4 # or xfs
|
||||
mount_point: <somepath>
|
||||
createfs: <boolean_value>
|
||||
```
|
||||
The above configuration will do two different things depending on existence of `<lv_name>`. Please note that `psi_local_storage_logical_volumes` is a list of dictionaries, meaning that one can create/modify multiple logical volumes:
|
||||
##### `<lv_name>` doesn’t exist
|
||||
A logical volume name is created inside the volume group specified above (`<vg_name>`). It’s size will be N GBytes. If `<boolean_value>` is true then a filesystem will be created in the device `/dev/<vg_name>/<lv_name>` of type `fstype` and mounted persistently on `<somepath>`.
|
||||
##### `<lv_name>` already exists and a filesystem is already present in it
|
||||
The logical volume name `<lv_name>` is expanded (together with the filesystem) to `N` GBytes (only if `N` is greater than the current size). Filesystem is always expanded to fill up the entire volume group.
|
||||
##### `<lv_name>` already exists and a filesystem is not present in it
|
||||
The logical volume name `<lv_name>` is expanded (together with the filesystem) to `N` GB (only if `N` is greater than the current size); if `<boolean_value>` is true (or `yes`) then a filesystem of type `fstype` is created and mounted persistently on `<some_path>`.
|
||||
|
||||
#### Use Case 1: extending an existing partition after system first installation
|
||||
ASSUMPTION 1: you have just installed a new system with the following partition scheme LVM-based:
|
||||
```
|
||||
[vagrant@your_server ~]$ df -h
|
||||
Filesystem Size Used Avail Use% Mounted on
|
||||
devtmpfs 393M 0 393M 0% /dev
|
||||
tmpfs 410M 0 410M 0% /dev/shm
|
||||
tmpfs 410M 5.7M 404M 2% /run
|
||||
tmpfs 410M 0 410M 0% /sys/fs/cgroup
|
||||
/dev/mapper/cl-root 50G 2.6G 48G 6% /
|
||||
/dev/sda1 976M 183M 726M 21% /boot
|
||||
/dev/mapper/cl-home 27G 225M 27G 1% /home
|
||||
tmpfs 82M 0 82M 0% /run/user/1000
|
||||
/dev/mapper/myvg_root-first 1014M 40M 975M 4% /mnt/first
|
||||
/dev/mapper/myvg_root-second 976M 2.6M 907M 1% /mnt/second
|
||||
/dev/mapper/myvg_root-third 1014M 40M 975M 4% /mnt/third
|
||||
```
|
||||
ASSUMPTION 2: the partition scheme was not created by you (or by the automatic Tower system) using a specific playbook. It is just there and you do not like the current size of `/mnt/first` and/or `/mnt/second` and/or `/mnt/third`.
|
||||
|
||||
ASSUMPTION 3: the volume group/physical devices supporting the logical volumes `myvg_root-[first,second,third]` do have some extra un-allocated space you can use to extend the parition mounted on `/mnt/[first,second,third]`.
|
||||
|
||||
Write the following playbook (named `extend.yml`) assuming that you want the new partitions respectively resized to 4, 6 and 2 GB:
|
||||
```
|
||||
---
|
||||
- name: Extend partition
|
||||
hosts: your_server.psi.ch
|
||||
roles:
|
||||
- name: psi.local_storage
|
||||
psi_local_storage_resizefs:
|
||||
- path: '/mnt/second'
|
||||
size: 4
|
||||
- path: '/mnt/third'
|
||||
size: 6
|
||||
- path: '/mnt/first'
|
||||
size: 2
|
||||
...
|
||||
```
|
||||
Execute it with usual `ansible-playbook` command:
|
||||
```
|
||||
[vagrant@control ~]$ ansible-playbook extend.yml
|
||||
|
||||
PLAY [Extend storage] ******************************************************************************************************************************
|
||||
|
||||
TASK [Gathering Facts] *****************************************************************************************************************************
|
||||
[DEPRECATION WARNING]: Distribution centos 8.2.2004 on host your_server should use /usr/libexec/platform-python, but is using /usr/bin/python for
|
||||
backward compatibility with prior Ansible releases. A future Ansible release will default to using the discovered platform python for this host.
|
||||
See https://docs.ansible.com/ansible/2.9/reference_appendices/interpreter_discovery.html for more information. This feature will be removed in
|
||||
version 2.12. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.
|
||||
ok: [your_server]
|
||||
|
||||
TASK [psi.local_storage : Check that user specified a fstype which is supported] *******************************************************************
|
||||
|
||||
TASK [psi.local_storage : Ensure lmv2 package is installed] ****************************************************************************************
|
||||
skipping: [your_server]
|
||||
|
||||
TASK [psi.local_storage : Create VG '' on physical volume '[]'] ************************************************************************************
|
||||
skipping: [your_server]
|
||||
|
||||
TASK [psi.local_storage : Create logical volume(s) on ''] ******************************************************************************************
|
||||
|
||||
TASK [psi.local_storage : Create not mounted filesystem(s)] ****************************************************************************************
|
||||
|
||||
TASK [psi.local_storage : Mount filesystem(s)] *****************************************************************************************************
|
||||
|
||||
TASK [psi.local_storage : Resize Filesystem] *******************************************************************************************************
|
||||
changed: [your_server] => (item={'path': '/mnt/second', 'size': 4})
|
||||
changed: [your_server] => (item={'path': '/mnt/third', 'size': 6})
|
||||
changed: [your_server] => (item={'path': '/mnt/first', 'size': 2})
|
||||
|
||||
PLAY RECAP *****************************************************************************************************************************************
|
||||
your_server : ok=2 changed=1 unreachable=0 failed=0 skipped=6 rescued=0 ignored=0
|
||||
```
|
||||
#### Use Case 2: extending an existing partition after system first installation using additional device
|
||||
|
||||
ASSUMPTION 1: you have just installed a new system with the following partition scheme LVM-based:
|
||||
```
|
||||
[vagrant@your_server ~]$ df -h
|
||||
Filesystem Size Used Avail Use% Mounted on
|
||||
devtmpfs 393M 0 393M 0% /dev
|
||||
tmpfs 410M 0 410M 0% /dev/shm
|
||||
tmpfs 410M 5.7M 404M 2% /run
|
||||
tmpfs 410M 0 410M 0% /sys/fs/cgroup
|
||||
/dev/mapper/cl-root 50G 2.6G 48G 6% /
|
||||
/dev/sda1 976M 183M 726M 21% /boot
|
||||
/dev/mapper/cl-home 27G 225M 27G 1% /home
|
||||
tmpfs 82M 0 82M 0% /run/user/1000
|
||||
/dev/mapper/myvg_root-first 1014M 40M 975M 4% /mnt/first
|
||||
/dev/mapper/myvg_root-second 976M 2.6M 907M 1% /mnt/second
|
||||
/dev/mapper/myvg_root-third 1014M 40M 975M 4% /mnt/third
|
||||
```
|
||||
ASSUMPTION 2: the partition scheme was not created by you (or by the automatic Tower system) using a specific playbook. It is just there and you do not like the current Size of `/mnt/first`
|
||||
|
||||
ASSUMPTION 3: you have a new HDD/SSD attached to your node and identified by device `/dev/sdc`, and you want to use it to expand the volume groups, logical volumes in order to be free to freely enlarge your partitions.
|
||||
|
||||
This procedure requires a bit more know-how on linux and logical volume management, but the following explanation will try to guide you as much as possible.
|
||||
|
||||
##### Step1 - Get Volume Group and physical devices
|
||||
Identify the volume group associated with the partition `/mnt/first` you want to expand, by executing this:
|
||||
```
|
||||
[root@your_server ~]# theVG=$(lvdisplay $(df -h /mnt/first|grep /mnt/first|awk '{print $1}')|grep "VG Name"|awk '{print $NF}')
|
||||
```
|
||||
|
||||
Identify the physical volumes on which the `vggroup` is built on:
|
||||
```
|
||||
[root@your_server ~]# vgdisplay -v $theVG |grep "PV Name"|awk '{print $NF}'
|
||||
/dev/sdb1
|
||||
/dev/sdb2
|
||||
/dev/sdb3
|
||||
```
|
||||
Take notes of these three physical devices and remember that you will have to add to this list your new device `/dev/sdd`.
|
||||
|
||||
##### Step2 - Get Logical volume name and filesystem type
|
||||
|
||||
Execute the following command to get the logical volume name:
|
||||
```
|
||||
[root@your_server ~]# theLV=$(lvdisplay $(df -h /mnt/first|grep /mnt/first|awk '{print $1}')|grep "LV Name"|awk '{print $NF}')
|
||||
[root@your_server ~]# echo $theLV
|
||||
first
|
||||
```
|
||||
Identify the filesystem type by executing this command:
|
||||
```
|
||||
[root@your_server ~]# theFS=$(mount|grep "/mnt/first"|awk '{print $5}')
|
||||
[root@your_server ~]# echo $theFS
|
||||
xfs
|
||||
```
|
||||
##### Step3 - Prepare the ansible playbook
|
||||
|
||||
Write the following playbook (named `extend.yml`) taking care to use the correct volume group name (`theVG`), logical volume name (`theLV`) and the filesystem type (`theFS`); of course also keep unchanged the mount point:
|
||||
```
|
||||
---
|
||||
- name: Extend storage
|
||||
hosts: your_server
|
||||
roles:
|
||||
- name: psi.local_storage
|
||||
psi_local_storage_physical_volumes:
|
||||
- /dev/sdb1
|
||||
- /dev/sdb2
|
||||
- /dev/sdb3
|
||||
- /dev/sdc # it doesn't matter that you didn't do any partition inside sdc; LVM is able to cope with RAW devices as well
|
||||
psi_local_storage_physical_name: 'myvg_root'
|
||||
psi_local_storage_logical_volumes:
|
||||
- name: 'first'
|
||||
size: 3
|
||||
fstype: 'xfs'
|
||||
mount_point: '/mnt/first'
|
||||
createfs: true
|
||||
...
|
||||
```
|
||||
Note that we have put in the playbook the three devices that we found above (output of `vgdisplay`: `/dev/sdb[1,2,3]`) plus the new one `/dev/sdd`.
|
||||
|
||||
Also note that the original size of the `/mnt/first` filesystem was 1GB, now in the playbook we put 3 (implicit unit is GB).
|
||||
|
||||
|
||||
Execute your playbook (suppose you called it as `extend.yml`):
|
||||
```
|
||||
[vagrant@control ~]$ ansible-playbook extend.yml
|
||||
|
||||
PLAY [Extend storage] **********************************************************************************************************************************************************************************************
|
||||
|
||||
TASK [Gathering Facts] *********************************************************************************************************************************************************************************************
|
||||
|
||||
TASK [psi.local_storage : Check that user specified a fstype which is supported] ***********************************************************************************************************************************
|
||||
skipping: [your_server] => (item={'name': 'first', 'size': 3, 'fstype': 'xfs', 'mount_point': '/mnt/first', 'createfs': True})
|
||||
|
||||
TASK [psi.local_storage : Ensure lmv2 package is installed] ********************************************************************************************************************************************************
|
||||
ok: [your_server]
|
||||
|
||||
TASK [psi.local_storage : Create VG 'myvg_root' on physical volume '['/dev/sdb1', '/dev/sdb2', '/dev/sdb3']'] ******************************************************************************************************
|
||||
ok: [your_server]
|
||||
|
||||
TASK [psi.local_storage : Create logical volume(s) on 'myvg_root'] *************************************************************************************************************************************************
|
||||
changed: [your_server] => (item={'name': 'first', 'size': 3, 'fstype': 'xfs', 'mount_point': '/mnt/first', 'createfs': True})
|
||||
|
||||
TASK [psi.local_storage : Create not mounted filesystem(s)] ********************************************************************************************************************************************************
|
||||
ok: [your_server] => (item={'name': 'first', 'size': 3, 'fstype': 'xfs', 'mount_point': '/mnt/first', 'createfs': True})
|
||||
|
||||
TASK [psi.local_storage : Mount filesystem(s)] *********************************************************************************************************************************************************************
|
||||
ok: [your_server] => (item={'name': 'first', 'size': 3, 'fstype': 'xfs', 'mount_point': '/mnt/first', 'createfs': True})
|
||||
|
||||
TASK [psi.local_storage : Resize XFS filesystem(s)] ****************************************************************************************************************************************************************
|
||||
changed: [your_server] => (item={'name': 'first', 'size': 3, 'fstype': 'xfs', 'mount_point': '/mnt/first', 'createfs': True})
|
||||
|
||||
TASK [psi.local_storage : Resize EXT filesystem(s)] ****************************************************************************************************************************************************************
|
||||
skipping: [your_server] => (item={'name': 'first', 'size': 3, 'fstype': 'xfs', 'mount_point': '/mnt/first', 'createfs': True})
|
||||
|
||||
PLAY RECAP *********************************************************************************************************************************************************************************************************
|
||||
your_server : ok=7 changed=2 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0
|
||||
```
|
||||
|
||||
And now check the size of `/mnt/first` on your your_server node:
|
||||
```
|
||||
[root@your_server ~]# df -h
|
||||
Filesystem Size Used Avail Use% Mounted on
|
||||
devtmpfs 393M 0 393M 0% /dev
|
||||
tmpfs 410M 0 410M 0% /dev/shm
|
||||
tmpfs 410M 5.7M 404M 2% /run
|
||||
tmpfs 410M 0 410M 0% /sys/fs/cgroup
|
||||
/dev/mapper/cl-root 50G 2.6G 48G 6% /
|
||||
/dev/sda1 976M 183M 726M 21% /boot
|
||||
/dev/mapper/cl-home 27G 225M 27G 1% /home
|
||||
tmpfs 82M 0 82M 0% /run/user/1000
|
||||
/dev/mapper/myvg_root-first 3.0G 55M 3.0G 2% /mnt/first
|
||||
/dev/mapper/myvg_root-second 976M 2.6M 907M 1% /mnt/second
|
||||
/dev/mapper/myvg_root-third 1014M 40M 975M 4% /mnt/third
|
||||
|
||||
```
|
||||
|
||||
#### Mount mountpoints
|
||||
Define the following dictionary:
|
||||
```yaml
|
||||
psi_mounts_mounts:
|
||||
- fstype: <ext4|xfs>
|
||||
mount_point: <somepath>
|
||||
device: /dev/<somedevice_or_lvm>
|
||||
options: <otps-to-be-put-in-fstab>
|
||||
state: mounted|unmounted|absent|present|remounted
|
||||
- fstype: <ext4|xfs>
|
||||
mount_point: <somepath2>
|
||||
device: /dev/<somedevice_or_lvm>
|
||||
options: <otps-to-be-put-in-fstab>
|
||||
state: mounted|unmounted|absent|present|remounted
|
||||
- [...]
|
||||
```
|
||||
and run this playbook.
|
||||
Note that block devices `/dev/something` must already be there and filesystem must me created.
|
||||
* `mounted/unmounted` has a clear meaning
|
||||
* `absent/present` concern the presence or not of the mount directive in /etc/fstab to have the mount automatically done at every boot of the system
|
||||
* `remounted` means that you want to remount the partition because, for example, you changed some parameter or option.
|
||||
|
||||
---
|
||||
### System Registration
|
||||
Owned by @spreitzer_s
|
||||
|
||||
Basically your system should receive default values that are supplied globally, from the PSI Default Inventory in GitLab and AWX, to successfully register it with Satellite, so it will have access to software repositories automatically.
|
||||
|
||||
However the following settings can be made.
|
||||
|
||||
```yaml
|
||||
psi_subscription_manager_activation_key: RHEL8-GFA
|
||||
psi_subscription_manager_org: PSI
|
||||
psi_subscription_manager_server: satint.psi.ch
|
||||
psi_subscription_manager_force_register: 'False'
|
||||
```
|
||||
|
||||
#### psi_subscription_manager_activation_key
|
||||
The Satellite activation key to use. Usually something that starts with `RHEL8-`.
|
||||
|
||||
#### psi_subscription_manager_org
|
||||
The Satellite Organization to use. Usually `PSI`.
|
||||
|
||||
#### psi_subscription_manager_server
|
||||
The Satellite to register with. Usually `satint.psi.ch`.
|
||||
|
||||
#### psi_subscription_manager_force_register
|
||||
Whether to or not run the subscription-management enforced. Usually `true` to ensure a system has software access.
|
||||
|
||||
---
|
||||
### System Security
|
||||
Owned by @caubet_m
|
||||
|
||||
This documentation shows how to manage SELinux with the Ansible *selinux* role. More examples can be found in the **['linux-system-roles' Official GitHUB Project Webpage](https://github.com/linux-system-roles/selinux)**
|
||||
|
||||
#### Enabling/Disabling SELinux
|
||||
|
||||
The defaults at PSI are:
|
||||
|
||||
```yaml
|
||||
selinux_state: enforcing
|
||||
selinux_policy: targeted
|
||||
```
|
||||
* Allowed values for **`selinux_state`** are `disabled`, `enforcing` and `permissive`.
|
||||
* Allowed values for **`selinux_policy`** are `targeted`, and `mls`.
|
||||
|
||||
#### (Un)Setting SELinux booleans
|
||||
|
||||
Common examples for setting SELinux booleans are the following:
|
||||
* Enabling the `use_nfs_home_dirs` Boolean to allow the usage of NFS based home directories, and make it persistent accross machine reboots.
|
||||
* Enabling the `httpd_use_nfs` Boolean to allow *httpd* to access and share NFS volumes.
|
||||
|
||||
```yaml
|
||||
selinux_booleans:
|
||||
- name: use_nfs_home_dirs
|
||||
state: on
|
||||
persistent: 'yes'
|
||||
- name: httpd_use_nfs
|
||||
state: on
|
||||
```
|
||||
Enable the httpd_use_nfs Boolean to allow httpd to access and share NFS volumes (labeled with the nfs_t type):
|
||||
|
||||
#### Set SELinux file contexts
|
||||
|
||||
In this example, we set /tmp/test_dir directories with `user_home_dir_t` context.
|
||||
|
||||
```yaml
|
||||
selinux_fcontexts:
|
||||
- target: '/tmp/test_dir(/.*)?'
|
||||
setype: user_home_dir_t
|
||||
ftype: d
|
||||
state: present
|
||||
```
|
||||
|
||||
#### Set SELinux Ports
|
||||
|
||||
In the example below, we allow SSH to use TCP port 22100, in that way we can tell *sshd* to listen on a non-standard port 22100 instead of the standard port 22. For that, we would neeed to update also `/etc/ssh/sshd_config` by changing `Port 22`to `Port 22100`.
|
||||
|
||||
```yaml
|
||||
selinux_ports:
|
||||
- ports: '22100'
|
||||
proto: tcp
|
||||
setype: ssh_port_t
|
||||
```
|
||||
|
||||
* (Persistent file contextes, semanage fcontext, if you have time)
|
||||
|
||||
#### Set linux user to SELinux mapping
|
||||
|
||||
When `selinux_policy: mls`, one would need to update linux users to SELinux users mapping.
|
||||
|
||||
In the example, we remove `feichtinger` from `staff_u`, and we add a new user `caubet_m`, as well as a generic username `staff`, to be mapped to the SELinux user `staff_u` (`caubet_m`, has more security privileges than a generic `staff` user; this is defined with `serange`). On the other hand, we set that any other not mapped user (`__default__`), should be mapped to the SELinux user `user_u`. Any user mapped in that way, have very low security level (`s0`, which is the lowest).
|
||||
|
||||
```yaml
|
||||
selinux_logins:
|
||||
- login: feichtinger
|
||||
seuser: staff_u
|
||||
state: absent
|
||||
- login: caubet_m
|
||||
seuser: staff_u
|
||||
serange: 's0-s15:c0.c1023'
|
||||
- login: staff
|
||||
seuser: staff_u
|
||||
serange: 's2:c100'
|
||||
- login: __default__
|
||||
seuser: user_u
|
||||
serange: 's0-s0:'
|
||||
|
||||
```
|
||||
|
||||
In example:
|
||||
|
||||
```bash
|
||||
[root@hpc-rhel8devel01 home]# semanage login -l
|
||||
|
||||
__default__ user_u s0-s0 *
|
||||
caubet_m staff_u s0-s15:c0.c1023 *
|
||||
root root s0-s15:c0.c1023 *
|
||||
staff staff_u s2:c100 *
|
||||
sysadm staff_u s0-s15:c0.c1023 *
|
||||
system_u system_u s0-s15:c0.c1023 *
|
||||
```
|
||||
|
||||
#### Restorecon
|
||||
|
||||
Run `restorecon` on filesystem trees for applying `selinux` policies:
|
||||
|
||||
```yaml
|
||||
selinux_restore_dirs:
|
||||
- /var
|
||||
- /tmp
|
||||
```
|
||||
|
||||
---
|
||||
### Systemd Services
|
||||
Owned by @caubet_m
|
||||
|
||||
This role creates by default **systemd** **service** *units*, however, is also possible to configure
|
||||
other system *units* such like **slice**, **socket**, **timers*, **mount**, etc.
|
||||
|
||||
Full examples for the **systemd** Ansible role can be found in the **['0x0I' Official GitHUB Project Webpage](https://github.com/0x0I/ansible-role-systemd#role-variables)**. The example below, shows how to create different *systemd* units: *service*, *socket*, *mount*, *target* and *timer*
|
||||
|
||||
```yaml
|
||||
unit_config:
|
||||
- name: "test-service"
|
||||
Unit:
|
||||
Description: "This is a test service unit which listens at port 1234"
|
||||
After: network-online.target
|
||||
Wants: network-online.target
|
||||
Requires: test-service.socket
|
||||
Service:
|
||||
User: 'kitchen'
|
||||
Group: 'kitchen'
|
||||
ExecStart: '/usr/bin/sleep infinity'
|
||||
ExecReload: '/bin/kill -s HUP $MAINPID'
|
||||
Install:
|
||||
WantedBy: 'multi-user.target'
|
||||
- name: "test-service"
|
||||
type: "socket"
|
||||
Unit:
|
||||
Description: "This is a test socket unit which specifies the test-service 'socket' unit type"
|
||||
Socket:
|
||||
ListenStream: '0.0.0.0:1234'
|
||||
Accept: 'true'
|
||||
Install:
|
||||
WantedBy: 'sockets.target'
|
||||
- name: "tmp-stdin"
|
||||
type: "mount"
|
||||
path: "/run/systemd/system"
|
||||
Unit:
|
||||
Description: "This is a test mount unit which overrides the default unit path"
|
||||
Mount:
|
||||
What: '/dev/stdin'
|
||||
Where: '/tmp/stdin'
|
||||
Install:
|
||||
WantedBy: 'mount.target'
|
||||
- name: "test-target"
|
||||
type: "target"
|
||||
path: "/etc/systemd/system"
|
||||
Unit:
|
||||
Description: This is an example unit Target
|
||||
Wants: test-service.service test-service.socket tmp-stdin.mount
|
||||
PartOf: test-service.service
|
||||
- name: dnf-makecache
|
||||
type: timer
|
||||
Unit:
|
||||
Description: "This is a test timer unit which refreshes dnf cache"
|
||||
Timer:
|
||||
OnBootSec: 10min
|
||||
OnUnitInactiveSec: 1h
|
||||
Unit: dnf-makecache.service
|
||||
Install:
|
||||
WantedBy: multi-user.target
|
||||
```
|
||||
|
||||
---
|
||||
### System Time/NTP
|
||||
Owned by @caubet_m
|
||||
|
||||
This document describes how to configure the system 'time' on RHEL8 based systems. Current *defaults* should fit for most of the cases at PSI:
|
||||
* The recommended service on RHEL8 systems for configuring *system time* is **`chrony`**
|
||||
* PSI provides different NTP servers which should be accessible by most of the PSI subnets:
|
||||
* `pstime1.psi.ch`
|
||||
* `pstime2.psi.ch`
|
||||
* `pstime3.psi.ch`
|
||||
* We usually apply custom settings in Chrony or logging and rapid clock measuring during boot time:
|
||||
* We setup `initstepslew` to `60` seconds. It is, if system's error is found to be 60 seconds or less, a slew will be used to correct it; if the error is above 60 seconds, a step will be used.
|
||||
* We log different metrics which would help to debug different timesync related problems: `measurements statistics tracking`
|
||||
|
||||
Example of default configuration at PSI, which should be adapted according to your needs:
|
||||
|
||||
```yaml
|
||||
# linux-system-roles.timesync settings
|
||||
timesync_chrony_custom_settings:
|
||||
- "# Allow chronyd to make a rapid measurement of the system and correct clock error at boot time"
|
||||
- "initstepslew 60 pstime1.psi.ch pstime2.psi.ch pstime3.psi.ch"
|
||||
- "# Select which information is logged."
|
||||
- "log measurements statistics tracking"
|
||||
timesync_ntp_provider: chrony
|
||||
timesync_ntp_servers:
|
||||
- hostname: pstime1.psi.ch
|
||||
- hostname: pstime2.psi.ch
|
||||
- hostname: pstime3.psi.ch
|
||||
```
|
||||
|
||||
---
|
||||
### User Management
|
||||
Owned by @spreitzer_s
|
||||
|
||||
User management is divided in two parts:
|
||||
* PSI Active Directory
|
||||
* Local system
|
||||
|
||||
**Overall users and group and group memberships must be managed in Active Directory!** Please consult the PSI Service Catalog to request users, groups and group membership as well as their removal. http://css.psi.ch/psisp
|
||||
|
||||
*Use `*_common` for inventory group variables and `*_extra` for host variables.*
|
||||
|
||||
#### psi_aaa_allow_groups{_common,_extra}
|
||||
|
||||
List of groups that are allowed to login to a system.
|
||||
|
||||
```yaml
|
||||
psi_aaa_allow_groups_extra:
|
||||
- unx-ait
|
||||
- unx-sls
|
||||
```
|
||||
|
||||
#### psi_aaa_allow_user{_common,_extra}
|
||||
|
||||
List of users that are allowed to login to a system. *Prefer using groups over users!*
|
||||
|
||||
```yaml
|
||||
psi_aaa_allow_user_extra:
|
||||
- kapeller
|
||||
- klar_t
|
||||
- spreitzer_s
|
||||
```
|
||||
|
||||
### Local User Management (Do not use, prefer Active Directory)
|
||||
|
||||
#### psi_aaa_local_sudo_rules{_common,_extra}
|
||||
|
||||
Manage local sudo roles by lists of (name, content and state). Be very cautios with the sudo rules, as one faulty rule will break sudo for the whole system.
|
||||
|
||||
```yaml
|
||||
psi_aaa_local_sudo_rules_extra:
|
||||
- name: sspreitz-root-nopasswd
|
||||
content: "sspreitz ALL=(ALL) NOPASSWD: ALL\n"
|
||||
- name: group-wheel-root-nopasswd
|
||||
content: "%wheel ALL=(ALL) NOPASSWD: ALL\n"
|
||||
- name: linuxsupport-root-nopasswd
|
||||
content: |
|
||||
jill ALL=(ALL) NOPASSWD: ALL
|
||||
joe ALL=(ALL) NOPASSWD: ALL
|
||||
jack ALL=(ALL) NOPASSWD: ALL
|
||||
tom ALL=(ALL) NOPASSWD: ALL
|
||||
- name: sam-root-nopasswd
|
||||
state: absent
|
||||
```
|
||||
|
||||
#### psi_aaa_local_groups{_common,_extra}
|
||||
|
||||
Manage local groups by a list of ansible group definitions. https://docs.ansible.com/ansible/latest/collections/ansible/builtin/group_module.html
|
||||
|
||||
```yaml
|
||||
psi_aaa_local_groups_extra:
|
||||
- name: group1
|
||||
gid: 30000
|
||||
- name: group2
|
||||
- name: support
|
||||
system: yes
|
||||
- name: group3
|
||||
state: absent
|
||||
```
|
||||
|
||||
#### psi_aaa_local_users{_common,_extra}
|
||||
|
||||
Manage local users by a list of ansible user definitions. https://docs.ansible.com/ansible/latest/collections/ansible/builtin/user_module.html
|
||||
|
||||
```yaml
|
||||
psi_aaa_local_users_extra:
|
||||
- name: guest
|
||||
- name: joe
|
||||
uid: 1000
|
||||
group: group1
|
||||
groups:
|
||||
- wheel
|
||||
- staff
|
||||
- audio
|
||||
home: /home/joe
|
||||
shell: /bin/fish
|
||||
# mkpasswd -m sha512crypt joe
|
||||
password: '$6$Mrq9msM24W$boAK1IYwuG6ze1qgk.HpqMqvj/zRThT2fTrb80kJTAiMg1CNXjbEEMH7A8KwAeKQJZuF14KRrpOK5NXxYvqqn1'
|
||||
- name: jill
|
||||
state: absent
|
||||
remove: yes
|
||||
```
|
||||
|
||||
#### psi_aaa_local_authorized_keys{_common,_extra}
|
||||
|
||||
Manage local ssh authorized keys by ansible ssh authorized keys definitions. https://docs.ansible.com/ansible/latest/collections/ansible/posix/authorized_key_module.html
|
||||
|
||||
```yaml
|
||||
psi_aaa_local_authorized_keys_extra:
|
||||
- user: sspreitz
|
||||
key: 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC9gU640HBk4m0OA4b2ziTCnVP6QYhs2Zs/LJWTN85+vCudgZfiMip2MAAR0OlOVtB4JYXJh83Rihj0REA13ei3akAPzgG+B4Qlk3QYA2Bf2YDjRGqwgpmhVlTNgJy+l9lS9rn5kPheXTi1GOgGVKi4jd5f6TuYhMBmSl64oCtWnanIwXd/u6teStTd7V0HKgev+GbAvTJPFoxOHFSV51mMvFkkW0s0cPTwLvekAPsnjw4ztEoX8Ar72U+KOnt6YLOEuKB0bKZ4PKTEz7woltDcXKzN9g5HKSY+RgSk9APrOol+HVgs841/1KChri7xPao4J1OzU0Ap6wkG+GfqPVc/ sspreitz@redhat.com'
|
||||
- user: evil
|
||||
key: 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC9gU640HBk4m0OA4b2ziTCnVP6QYhs2Zs/LJWTN85+vCudgZfiMip2MAAR0OlOVtB4JYXJh83Rihj0REA13ei3akAPzgG+B4Qlk3QYA2Bf2YDjRGqwgpmhVlTNgJy+l9lS9rn5kPheXTi1GOgGVKi4jd5f6TuYhMBmSl64oCtWnanIwXd/u6teStTd7V0HKgev+GbAvTJPFoxOHFSV51mMvFkkW0s0cPTwLvekAPsnjw4ztEoX8Ar72U+KOnt6YLOEuKB0bKZ4PKTEz7woltDcXKzN9g5HKSY+RgSk9APrOol+HVgs841/1KChri7xPao4J1OzU0Ap6wkG+GfqPVc/ mrevil@example.com'
|
||||
state: absent
|
||||
```
|
||||
|
||||
---
|
||||
### Software Management
|
||||
Owned by @klar_t
|
||||
|
||||
#### psi_packer_repo
|
||||
|
||||
A merged dictionary of yum repository definitions
|
||||
|
||||
#### psi_packer_inst
|
||||
|
||||
A merged list of rpm packages to be installed
|
||||
|
||||
#### psi_packer_rem
|
||||
|
||||
A merged list of rpm packages to be removed
|
||||
|
||||
#### psi_packer_update
|
||||
|
||||
`true` or `false` on whether to update all packages on each ansible run
|
||||
|
||||
#### Important
|
||||
|
||||
the `psi_packer_repo` and the `psi_packer_inst` variables are merged.
|
||||
It is a wildcard merge, so any suffix can be used, but it is recommended to use the group- or hostname, so there is no accidental overlap.
|
||||
The list of enabled and the list of disabled repos will be added to the repo file only. Otherwise a repo may e defined but will be ignored.
|
||||
These 2 lists are also wildcard merged.
|
||||
|
||||
```yaml
|
||||
- hosts: servers
|
||||
vars:
|
||||
psi_packer_update: true
|
||||
psi_packer_repo_group:
|
||||
myrepo:
|
||||
description: This is my repo
|
||||
baseurl: http://example.com/repos/myrepo/
|
||||
gpgcheck: yes
|
||||
gpgkey: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-myrepo
|
||||
psi_packer_repo_host:
|
||||
myotherrepo:
|
||||
description: This is my other repo
|
||||
baseurl: http://example.com/repos/myotherrepo/
|
||||
gpgcheck: yes
|
||||
gpgkey: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-myrepo
|
||||
psi_packer_enabled_repos_group:
|
||||
- myrepo
|
||||
psi_packer_disabled_repos_host:
|
||||
- myotherrepo
|
||||
psi_packer_inst_group:
|
||||
- httpd
|
||||
- mariadb
|
||||
psi_packer_inst_host:
|
||||
- mc
|
||||
- nano
|
||||
psi_packer_del_group:
|
||||
- matlab
|
||||
- office
|
||||
psi_packer_del_host:
|
||||
- kernel-devel
|
||||
- afs
|
||||
roles:
|
||||
- psi.packer
|
||||
```
|
||||
---
|
||||
### AFS
|
||||
Owned by @klar_t
|
||||
|
||||
Note: AFS and AFS homes are not enabled by default in RHEL-8.
|
||||
|
||||
PSI Linux Engineering does not support AFS and AFS homes. Contact Achim Gsell if you need AFS and AFS homes.
|
||||
|
||||
LVM partitioning and free space on the root VG are necessary to use this role. (The VG is selected based on where the root file system is located, the actual name does not matter)
|
||||
|
||||
#### psi_yfs_size
|
||||
|
||||
Default: `2147483648`
|
||||
|
||||
Cache LV size, strictly in bytes
|
||||
|
||||
#### psi_yfs_remove
|
||||
|
||||
Default: `false`
|
||||
|
||||
Set this to true and remove everything the role would have installed
|
||||
|
||||
|
||||
#### Example Playbook
|
||||
|
||||
An example of how to use this role (with variables passed in as parameters).
|
||||
|
||||
```yaml
|
||||
- hosts: servers
|
||||
roles:
|
||||
- psi.yfs
|
||||
psi_yfs_size: 2147483648
|
||||
```
|
||||
|
||||
@@ -1,69 +0,0 @@
|
||||
# Developer Guide
|
||||
|
||||
**This guide is under heavy development and just drafted, expect frequent changes and check back every now and then**
|
||||
|
||||
This guide contains information to develop and roll out the configuration management and system deployment of RHEL-8.<br>
|
||||
*PSI RHEL-8* heavily relies on the Ansible automation technology for configuration management and automation.
|
||||
|
||||
Mandatory information is available at
|
||||
* https://docs.ansible.com/ansible/latest/index.html
|
||||
* https://docs.ansible.com/ansible/latest/user_guide/index.html
|
||||
* https://docs.ansible.com/ansible/latest/user_guide/quickstart.html
|
||||
|
||||
## Main code
|
||||
|
||||
PSI RHEL-8 configuration management consists of mainly two things
|
||||
|
||||
* [RHEL-8 PSI Defaults](https://git.psi.ch/linux/engineering/ansible/inventories/rhel-8-psi-defaults) Ansible Inventory
|
||||
* [RHEL-8 Ansible Collection](https://git.psi.ch/linux/engineering/ansible/collections/rhel-8)
|
||||
|
||||
The supplemental PSI Ansible Roles, which are referrenced from the *RHEL-8 Ansible Collection* are developed in
|
||||
|
||||
* [PSI Ansible Roles](https://git.psi.ch/linux/engineering/ansible/roles)
|
||||
|
||||
Addition group/section inventories are managed in
|
||||
|
||||
* [PSI Ansible Inventories](https://git.psi.ch/linux/engineering/ansible/inventories)
|
||||
|
||||
## Adding my code
|
||||
|
||||
Depending on where your code changes are happening (see section [Main code](#main-code)) you need to follow the following process:
|
||||
|
||||
1. Create a branch for what you are doing eg. *feature/my-new-feature* or *fix/problem-xyz-solved*
|
||||
2. Do your work and commit and push your branch
|
||||
3. Create a merge request and fill in a human understandable description
|
||||
4. Motivate other maintainers to approve your changes and get the code merged
|
||||
|
||||
## Using Vagrant to develop Ansible code
|
||||
|
||||
[Vagrant](https://vagrantup.com/intro) is a tool for building and managing virtual machine environments in a single workflow. With an easy-to-use workflow and focus on automation, Vagrant lowers development environment setup time, increases production parity, and makes the "works on my machine" excuse a relic of the past.
|
||||
|
||||
Documentation
|
||||
|
||||
* https://www.vagrantup.com/docs
|
||||
* https://www.vagrantup.com/intro/getting-started
|
||||
|
||||
[PSI Ansible Vagrant](https://git.psi.ch/linux/engineering/ansible/vagrant) is a preconfigured environment allowing an easy and fast development of PSI related Ansible based configuration mangement.
|
||||
|
||||
System requirements are either Virtualbox on Linux/Windows or Mac or libvirt on Linux.
|
||||
|
||||
## Components and Functions
|
||||
|
||||
The following software or solutions are chosen to provide RHEL-8 in compliance with the PSI Linux support policy
|
||||
|
||||
| Component | Function | URL |
|
||||
| --- | --- | --- |
|
||||
| Red Hat Satellite 6 | system deployment, update and oversight | [satint.psi.ch](satint.psi.ch) |
|
||||
| Red Hat Ansible | configuration management | [docs.ansible.com](https://docs.ansible.com/ansible/latest/index.html) |
|
||||
| Red Hat Ansible Tower (AWX) | configuration management center | [rhel-8-awx.psi.ch](https://rhel-8-awx.psi.ch) |
|
||||
| Koji | RPM package building solution | (tbd..) |
|
||||
|
||||
## Tools and Functions
|
||||
|
||||
The following tools are chosen for code and collaboration
|
||||
|
||||
| Tool | Function | URL |
|
||||
| --- | --- | --- |
|
||||
| GitLab | Git code revision system and code collaboration | [git.psi.ch/linux/engineering/home](https://git.psi.ch/linux/engineering/home) |
|
||||
| Slack | instant messaging, ChatOps | [controls-ha.slack.com/rhel-8-maintainers](https://controls-ha.slack.com/archives/G0163S918CB) |
|
||||
| Zoom | video conferencing | [psich.zoom.us](https://psich.zoom.us/j/2970303190)
|
||||
@@ -1,112 +0,0 @@
|
||||
# Installation Guide
|
||||
|
||||
## 1. Introduction
|
||||
|
||||
This guide is about installing a RHEL-8 Beta system at Paul Scherrer Insitute (called PSI furtheron) and how to provide empirical feedback to PSI Linux Engineering for further development of the release candidate aimed for 15th October of 2020.
|
||||
|
||||
**Check back to this documentation frequently, while the RHEL-8 Beta is valid, as changes may occur every day!**
|
||||
|
||||
## 2. How to find help and give feedback
|
||||
|
||||
### 2.1. How to receive help
|
||||
|
||||
There are two ways to receive help.
|
||||
|
||||
1. If you have a minor question or easy request (< 5 minutes of effort) you can contact the PSI Linux Engineering Slack channel via https://controls-ha.slack.com/archives/CUZDL5094
|
||||
2. Any other requests can be made by opening a request with the Linux Engineering team under [Issues](https://git.psi.ch/linux/engineering/documentation/rhel-8-beta-guide/issues)
|
||||
Please explain what is the exact problem or question and provide what you would behaviour you would expect from the system/solution
|
||||
|
||||
List of documentation that can answer general questions:
|
||||
|
||||
* [Product Documentation for Red Hat Enterprise Linux 8](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/)
|
||||
* [Product Documentation for Red Hat Satellite 6.7](https://access.redhat.com/documentation/en-us/red_hat_satellite/6.7/)
|
||||
* [Ansible Tower User Guide](https://docs.ansible.com/ansible-tower/latest/html/userguide/index.html)
|
||||
|
||||
There is also the [PSI Linux Mailing List](mailto:linux@lists.psi.ch) that you can always ask Linux related questions. It is even better to use as a lot of readers will also get answers to questions they might have had in the future.
|
||||
To subscribe to the list, click [here](mailto:linux-requests@lsits.psi.ch?subject=subscribe) and submit the email.
|
||||
|
||||
|
||||
### 2.2. How to give feedback
|
||||
|
||||
* Create an Issue [here](https://git.psi.ch/linux/engineering/documentation/rhel-8-beta-guide/issues) with the label *suggestion* or *enhancement*
|
||||
|
||||
Be as precise as possible and give an example that is easy to understand<br/>
|
||||
Be polite and constructive to motivate our PSI Linux Engineering :thumbsup:
|
||||
|
||||
### 2.3. Known things that can cause problems
|
||||
|
||||
At the moment there can be:
|
||||
* Various permission and access problems
|
||||
|
||||
If you happen to fall into one of the categories, receive help as described in [2.1. How to receive help](#21-how-to-receive-help)
|
||||
|
||||
## 3. Installing a system
|
||||
|
||||
### 3.1 Prerequisites and information
|
||||
|
||||
* If you are creating a Virtual Machine, make sure to use normal BIOS mode instead of EFI. EFI booting is not yet supported.
|
||||
* If you are working on **ScienceIT** systems in Leonardo Sala's team, please make sure to use the **"RHEL-8/AIT"** hostgroup. ScienceIT is a division of AIT.
|
||||
|
||||
|
||||
### 3.2. Easy
|
||||
|
||||
1. Login to [Red Hat Ansible Tower (AWX)](https://rhel-8-awx.psi.ch/) using your PSI credentials
|
||||
2. Launch the "Create Host" [template](https://rhel-8-awx.psi.ch/#/templates?template_search=page_size:20;order_by:name;type:workflow_job_template,job_template;search:Create;search:Host)
|
||||
3. **IMPORTANT: Select a hostgroup that is appropriate to the designated department eg. "RHEL-8/AIT"**
|
||||
4. Enter the survey and finalize the launch (Your PSI username and password must be supplied to allow the template to create the Host)
|
||||
5. Power on you hardware or virtual machine and boot from network
|
||||
6. In the network boot prompt enter "satint" and press enter
|
||||
7. The system will install and reboot
|
||||
8. After the first reboot the system will configure itself and will be accessible in a couple of minutes
|
||||
|
||||
### 3.3. Advanced
|
||||
|
||||
Be mindful with the information you enter, usually the minimal steps provided here are perfectly fine for 99% of all systems. If you change settings, you might break the system installation or configuration.
|
||||
|
||||
1. Login to [Red Hat Satellite](https://satint.psi.ch/hosts) using your PSI credentials
|
||||
2. Click on Hosts->Create Host
|
||||
3. Enter the designated hostname without the domain suffix psi.ch
|
||||
4. Select a hostgroup starting with "RHEL-8/..."
|
||||
5. In the "Interfaces" tab provide a mac address for the interface
|
||||
6. Click "Submit" to create the host
|
||||
7. Power on you hardware or virtual machine and boot from network
|
||||
8. In the network boot prompt enter "satint" and press enter
|
||||
9. The system will install and reboot
|
||||
10. After the first reboot the system will configure itself and will be accessible in a couple of minutes
|
||||
|
||||
## 4. Removing a system
|
||||
|
||||
### 4.1. Easy
|
||||
|
||||
1. Power off your hardware or virtual machine
|
||||
2. Login to [Red Hat Ansible Tower (AWX)](https://rhel-8-awx.psi.ch/) using your PSI credentials
|
||||
3. Launch the "Delete Host" [template](https://rhel-8-awx.psi.ch/#/templates?template_search=page_size:20;order_by:name;type:workflow_job_template,job_template;search:Host;search:Delete)
|
||||
4. Enter the survey and finalize the launch
|
||||
|
||||
|
||||
### 4.2. Advanced
|
||||
|
||||
1. Power off your hardware or virtual machine
|
||||
2. Login to [Red Hat Satellite](https://satint.psi.ch/hosts) using your PSI credentials
|
||||
3. Click on Hosts->All Hosts
|
||||
4. Click in your Host's name
|
||||
5. In the right upper corner of the host pane click "Delete"
|
||||
6. Confirm the deletion
|
||||
|
||||
## 5. Accessing an installed system
|
||||
|
||||
RHEL-8 beta systems can be accessed with your PSI Active Directory Kerberos user and password. Including native Kerberos authentication.
|
||||
|
||||
```shell
|
||||
kinit spreitzer_s@D.PSI.CH
|
||||
ssh -K my-new-system@psi.ch
|
||||
su -
|
||||
```
|
||||
|
||||
or
|
||||
|
||||
```shell
|
||||
ssh root@my-new-system.psi.ch
|
||||
```
|
||||
|
||||
> The default root password for the RHEL-8 beta is 'redhatredhat' without the quotation marks
|
||||
|
Before Width: | Height: | Size: 34 KiB |
|
Before Width: | Height: | Size: 34 KiB |
|
Before Width: | Height: | Size: 47 KiB |
|
Before Width: | Height: | Size: 51 KiB |
|
Before Width: | Height: | Size: 12 KiB |
|
Before Width: | Height: | Size: 9.4 KiB |
@@ -1,951 +0,0 @@
|
||||
# Configuration
|
||||
|
||||
The configuration documentation is intended for Linux Adminsistrators, that need to configure groups of systems at once.
|
||||
For example:
|
||||
* Groups of Servers
|
||||
* Groups of Consoles
|
||||
|
||||
## Ansible Inventories
|
||||
|
||||
### Inventory Examples
|
||||
|
||||
Easy, simple and understandable examples are available under <a href="https://git.psi.ch/linux/engineering/ansible/inventories/psi-rhel-8-rc1-examples/tree/master" target="_blank">PSI RHEL-8 RC1 Examples</a>
|
||||
|
||||
### List of Ansible Inventories
|
||||
|
||||
The `RHEL-8 PSI Defaults` inventory houses the PSI wide defaults such as timeserver settings or access for support group members. The `AIT`, `CPT`, `GFA` and `HPCE` inventories are housing the division specific configuration.
|
||||
|
||||
* <a href="https://git.psi.ch/linux/engineering/ansible/inventories/rhel-8-psi-defaults" target="_blank">RHEL-8 PSI Defaults</a>
|
||||
* <a href="https://git.psi.ch/linux/engineering/ansible/inventories/ait" target="_blank">AIT</a>
|
||||
* <a href="https://git.psi.ch/linux/engineering/ansible/inventories/cpt" target="_blank">CPT</a>
|
||||
* <a href="https://git.psi.ch/linux/engineering/ansible/inventories/gfa" target="_blank">GFA</a>
|
||||
* <a href="https://git.psi.ch/linux/engineering/ansible/inventories/hpce" target="_blank">HPCE</a>
|
||||
|
||||
{{% alert text="You need to have permissions to access inventories.<br/>Please contact AIT Helpdesk." %}}
|
||||
|
||||
## Ansible Roles Configuration
|
||||
|
||||
### System Information and Responsibilty
|
||||
Maintained by spreitzer_s
|
||||
|
||||
The system `/etc/motd` can be changed by settings as
|
||||
|
||||
```yaml
|
||||
psi_motd_ou: CPT
|
||||
psi_motd_contact: Gilles Martin <gilles.martin@psi.ch> / +41 56 310 36 90
|
||||
```
|
||||
|
||||
or
|
||||
|
||||
```yaml
|
||||
psi_motd_ou: AIT
|
||||
psi_motd_contact_list: true
|
||||
psi_motd_contact:
|
||||
- Alvise Dorigo <alvise.dorigo@psi.ch> / +41 56 310 55 67
|
||||
- Leonardo Sala <leonardo.sala@psi.ch> / +41 56 310 33 69
|
||||
```
|
||||
|
||||
additional information can be provided as well
|
||||
|
||||
```yaml
|
||||
psi_motd_ou: AIT
|
||||
psi_motd_contact_list: true
|
||||
psi_motd_contact:
|
||||
- Alvise Dorigo <alvise.dorigo@psi.ch> / +41 56 310 55 67
|
||||
- Leonardo Sala <leonardo.sala@psi.ch> / +41 56 310 33 69
|
||||
psi_motd_additional: |
|
||||
Please be careful with this system.
|
||||
It is very sensitive.
|
||||
```
|
||||
|
||||
|
||||
---
|
||||
### Network Configuration
|
||||
Maintained by caubet_m
|
||||
|
||||
#### Configuring bonding re-using existing IP and interface
|
||||
|
||||
First, one needs to remove the **"System eth0"** created during the installation which is the active interface. Then, one can create the bonding with a master interface (i.e. `bond0`) and the slave interface with a new name (i.e. `eth0` and, when using NetworkManager, it will generate a new `connection.id`). We ensure that the *state is up* and we *allow network restart* to apply changes on the fly, and we *persistent* changes.
|
||||
|
||||
**Note:** Is important to have it persistent and state *up* and `network_allow_restart` for applying **online** changes affecting to a connected interface, otherwise the network service (or machine) needs to be rebooted.
|
||||
|
||||
```yaml
|
||||
- hosts: all,rhel-8-dev-7a95e9bb.psi.ch
|
||||
vars:
|
||||
network_allow_restart: yes
|
||||
network_connections:
|
||||
- name: "System eth0"
|
||||
persistent_state: absent
|
||||
state: down
|
||||
- name: bond0
|
||||
type: bond
|
||||
interface_name: bond0
|
||||
bond:
|
||||
mode: 'active-backup'
|
||||
miimon: 100
|
||||
persistent_state: present
|
||||
ip:
|
||||
address: "{{ ansible_default_ipv4.address }}/24"
|
||||
dns:
|
||||
- 129.129.190.11
|
||||
- 129.129.230.11
|
||||
dns_search:
|
||||
- psi.ch
|
||||
gateway4: '{{ ansible_default_ipv4.gateway }}'
|
||||
state: up
|
||||
- name: eth0
|
||||
type: ethernet
|
||||
interface_name: eth0
|
||||
persistent_state: present
|
||||
mac: "{{ ansible_default_ipv4.macaddress }}"
|
||||
master: bond0
|
||||
slave_type: bond
|
||||
state: up
|
||||
roles:
|
||||
- linux-system-roles.network
|
||||
```
|
||||
|
||||
#### DHCP interfaces
|
||||
|
||||
Adding a new interface `eth1` with *dhcp* protocol for getting the IP address:
|
||||
|
||||
```yaml
|
||||
- hosts: all,rhel-8-dev-7a95e9bb.psi.ch
|
||||
vars:
|
||||
network_allow_restart: yes
|
||||
network_connections:
|
||||
- name: eth1
|
||||
type: ethernet
|
||||
interface_name: eth1
|
||||
persistent_state: present
|
||||
mac: "0A:0B:0C:0D:0E:0F"
|
||||
ip:
|
||||
dhcp4: yes
|
||||
state: up
|
||||
```
|
||||
|
||||
#### Using ethtool for changing interface settings
|
||||
|
||||
One can change network specific settings on an interface with ethtool. In example, we wante to disable `scatter-gather`:
|
||||
|
||||
```shell
|
||||
[root@rhel-8-dev-7a95e9bb ~]# ethtool -k eth0 | grep scatter-gather
|
||||
scatter-gather: on
|
||||
tx-scatter-gather: on
|
||||
tx-scatter-gather-fraglist: off [fixed]
|
||||
```
|
||||
|
||||
We can modify with *ethtool* the interface to change this setting as follows:
|
||||
|
||||
```yaml
|
||||
- hosts: all,rhel-8-dev-7a95e9bb.psi.ch
|
||||
vars:
|
||||
network_allow_restart: yes
|
||||
network_connections:
|
||||
- name: eth0
|
||||
type: ethernet
|
||||
interface_name: eth0
|
||||
persistent_state: present
|
||||
mac: "{{ ansible_default_ipv4.macaddress }}"
|
||||
ip:
|
||||
dhcp4: yes
|
||||
state: up
|
||||
ethtool:
|
||||
features:
|
||||
tx_scatter_gather: no
|
||||
```
|
||||
|
||||
As a result, we disable `scatter-gather`.
|
||||
|
||||
```shell
|
||||
[root@rhel-8-dev-7a95e9bb ~]# ethtool -k eth0 | grep scatter-gather
|
||||
scatter-gather: off
|
||||
tx-scatter-gather: off
|
||||
tx-scatter-gather-fraglist: off [fixed]
|
||||
```
|
||||
|
||||
---
|
||||
### Icinga client (NRPE) and SNMP
|
||||
|
||||
#### NRPE
|
||||
|
||||
For enabling the Nagios client together with NRPE, is necesary to have EPEL in the system (either enabled or disabled). Also, one needs to enable `psi_icinga_client_configure_nrpe`. In case that EPEL is not available in the system, one can enable the installation of the repository from the module itself (by enabling `psi_icinga_client_configure_epel`, which takes it from the official EPEL repositories.
|
||||
|
||||
Important parameters are:
|
||||
* `psi_icinga_client_nrpe_allowed_hosts` (`String`) where one should specify a comma separated list of allowed hosts. Usually, this will be centrally updated from the default variables inventory, however, when a new Nagios worker or server is setup, might be useful to update this setting until this is centrally changed.
|
||||
* `psi_icinga_client_nrpe_dont_blame` (`Boolean`) , this option determines whether or not the NRPE daemon will allow clients to specify arguments to commands that are executed. Since this option is a security risk, is disabled by default. However, there are many cases where this is needed, so this is the reason why is provided (under administrator's responsability).
|
||||
* `psi_icinga_client_nrpe_allow_bash_command_substitution` (`Boolean`) , which determines whether or not the NRPE daemon will allow clients to specify arguments that contain bash command substitutions of the form $(...). Since this is also a security risk, is default by default.
|
||||
* Icinga checks, which have three different variables. The reason for that is that Ansible is not capable to merge down variables, and this is the way to workaround it. Each settins is a `Hash` where:
|
||||
* Item name is the file name that will be placed in `include_dir` (usually `/etc/nrpe.d/`).
|
||||
* For each item:
|
||||
* one or more `commands` can be specified, and will be placed in the same file
|
||||
* all commands specified in that file, might need sudo or not. One can enable `sudo` for that file, which will place the proper sudoers rules in the default sudoers location (usually `/etc/sudoers.d/`).
|
||||
* The 3 variables are:
|
||||
* `psi_icinga_client_nagios_include_dir_checks` (`Hash`)
|
||||
* `psi_icinga_client_nagios_include_dir_checks_common` (`Hash`)
|
||||
* `psi_icinga_client_nagios_include_dir_checks_extra` (`Hash`)
|
||||
|
||||
An example for setting Icinga alarms is the following:
|
||||
|
||||
```yaml
|
||||
# Allow different Icinga hosts (PSI workers)
|
||||
psi_icinga_client_nrpe_allowed_hosts: "emonma00.psi.ch,vemonma00.psi.ch,wmonag00.psi.ch,emonag00.psi.ch,eadmin00.psi.ch,wadmin00.psi.ch,monaggfa.psi.ch,monaggfa2.psi.ch,monagxbl.psi.ch,wmonagcpt.psi.ch,vwmonagcpt.psi.ch,monagmisc.psi.ch,wmonagnet.psi.ch,vwmonagnet.psi.ch,monagsfel.psi.ch"
|
||||
|
||||
# Allow arguments: NRPE Don't Blame
|
||||
psi_icinga_client_nrpe_dont_blame: True
|
||||
|
||||
# Allow arguments: Bash Command Substitution
|
||||
psi_icinga_client_nrpe_allow_bash_command_substitution: True
|
||||
|
||||
# Define NRPE checks with and withou "sudo"
|
||||
psi_icinga_client_nagios_include_dir_checks:
|
||||
system_checks:
|
||||
commands:
|
||||
- command: "check_disk"
|
||||
path: "{{ psi_icinga_client_nagios_plugins_dir }}/check_disk"
|
||||
arguments: "$ARG1$"
|
||||
- command: "check_load"
|
||||
path: "{{ psi_icinga_client_nagios_plugins_dir }}/check_load"
|
||||
arguments: "$ARG1$"psi_icinga_client_nagios_include_dir_checks_common
|
||||
|
||||
psi_icinga_client_nagios_include_dir_checks_common: {}
|
||||
|
||||
psi_icinga_client_nagios_include_dir_checks_extra:
|
||||
gpfs_checks:
|
||||
sudo: True
|
||||
commands:
|
||||
- command: "check_gpfs_health"
|
||||
path: "{{ psi_icinga_client_nagios_plugins_dir }}/check_gpfs_health"
|
||||
arguments: "--unhealth --ignore-tips"
|
||||
```
|
||||
|
||||
#### SNMP
|
||||
|
||||
For enabling SNMP, one needs to enable `psi_icinga_client_configure_snmp`. Once enabled, default settings should be ok for most of the use cases. However, is important to update at least:
|
||||
* `psi_icinga_client_snmpd_syscontact` (which defaults to *servicesdesk@psi.ch*)
|
||||
* `psi_icinga_client_snmpd_rocommunity`, which by default contains only the *PSI public network* (129.129.0.0/16) and *localhost*. Hence, one needs to specify extra networks if necessary.
|
||||
|
||||
An example for configuring SNMP:
|
||||
|
||||
```yaml
|
||||
# Configure SNMP
|
||||
psi_icinga_client_configure_snmp: True
|
||||
psi_icinga_client_snmpd_dontLogTCPWrappersConnects: true
|
||||
psi_icinga_client_snmpd_trapcommunity: psi
|
||||
psi_icinga_client_snmpd_syslocation: PSI
|
||||
psi_icinga_client_snmpd_syscontact: marc.caubet@psi.ch
|
||||
psi_icinga_client_snmpd_sysservices: 76
|
||||
psi_icinga_client_snmpd_rocommunity:
|
||||
- community: psi
|
||||
network: 172.21.0.0/16
|
||||
oid: .1.3.6.1
|
||||
- community: psi
|
||||
network: 129.129.0.0/16
|
||||
oid: .1.3.6.1
|
||||
- community: psi
|
||||
network: 192.168.1.0/24
|
||||
oid: .1.3.6.1
|
||||
- community: psi
|
||||
network: localhost
|
||||
oid: .1.3.6.1
|
||||
```
|
||||
---
|
||||
### Storage Configuration
|
||||
Maintained by dorigo_a
|
||||
|
||||
#### Configuring a partition
|
||||
Define the following variable:
|
||||
```yaml
|
||||
psi_local_storage_physical_volume:
|
||||
- /dev/<device>
|
||||
```
|
||||
This just tells to Ansible which device (or partition) must be used for the creation/modification of a volume group.
|
||||
Multiple instances can be used; for example:
|
||||
```yaml
|
||||
psi_local_storage_physical_volumes:
|
||||
- /dev/sdb1
|
||||
- /dev/sdb2
|
||||
...
|
||||
- /dev/sdb5
|
||||
```
|
||||
|
||||
|
||||
`<device>` can be either a block device (`sda`, `sdb`, …) or a partition previously (and manually) created in a block device using `fdisk/parted` (`sda1`, `sdc3`,...).
|
||||
|
||||
#### Configuring a volume group
|
||||
```yaml
|
||||
psi_local_storage_physical_name: <vg_name>
|
||||
```
|
||||
`<vg_name>` is the name of a new volume group or the name of an existing volume group in which one wants to create/modify logical volumes.
|
||||
If the volume group already exists the role will simply add to it the new physical volumes specified in the previous variable `psi_local_storage_physical_volumes`, or no action is taken if the volume group is already built on top of the same physical volumes.
|
||||
|
||||
#### Configuring a logical volume
|
||||
```yaml
|
||||
psi_local_storage_logical_volumes:
|
||||
- name: <lv_name>
|
||||
size: N # size in unit of GB
|
||||
fstype: ext4 # or xfs
|
||||
mount_point: <somepath>
|
||||
createfs: <boolean_value>
|
||||
```
|
||||
The above configuration will do two different things depending on existence of `<lv_name>`. Please note that `psi_local_storage_logical_volumes` is a list of dictionaries, meaning that one can create/modify multiple logical volumes:
|
||||
##### `<lv_name>` doesn’t exist
|
||||
A logical volume name is created inside the volume group specified above (`<vg_name>`). It’s size will be N GBytes. If `<boolean_value>` is true then a filesystem will be created in the device `/dev/<vg_name>/<lv_name>` of type `fstype` and mounted persistently on `<somepath>`.
|
||||
##### `<lv_name>` already exists and a filesystem is already present in it
|
||||
The logical volume name `<lv_name>` is expanded (together with the filesystem) to `N` GBytes (only if `N` is greater than the current size). Filesystem is always expanded to fill up the entire volume group.
|
||||
##### `<lv_name>` already exists and a filesystem is not present in it
|
||||
The logical volume name `<lv_name>` is expanded (together with the filesystem) to `N` GB (only if `N` is greater than the current size); if `<boolean_value>` is true (or `yes`) then a filesystem of type `fstype` is created and mounted persistently on `<some_path>`.
|
||||
|
||||
#### Use Case 1: extending an existing partition after system first installation
|
||||
ASSUMPTION 1: you have just installed a new system with the following partition scheme LVM-based:
|
||||
```
|
||||
[vagrant@your_server ~]$ df -h
|
||||
Filesystem Size Used Avail Use% Mounted on
|
||||
devtmpfs 393M 0 393M 0% /dev
|
||||
tmpfs 410M 0 410M 0% /dev/shm
|
||||
tmpfs 410M 5.7M 404M 2% /run
|
||||
tmpfs 410M 0 410M 0% /sys/fs/cgroup
|
||||
/dev/mapper/cl-root 50G 2.6G 48G 6% /
|
||||
/dev/sda1 976M 183M 726M 21% /boot
|
||||
/dev/mapper/cl-home 27G 225M 27G 1% /home
|
||||
tmpfs 82M 0 82M 0% /run/user/1000
|
||||
/dev/mapper/myvg_root-first 1014M 40M 975M 4% /mnt/first
|
||||
/dev/mapper/myvg_root-second 976M 2.6M 907M 1% /mnt/second
|
||||
/dev/mapper/myvg_root-third 1014M 40M 975M 4% /mnt/third
|
||||
```
|
||||
ASSUMPTION 2: the partition scheme was not created by you (or by the automatic Tower system) using a specific playbook. It is just there and you do not like the current size of `/mnt/first` and/or `/mnt/second` and/or `/mnt/third`.
|
||||
|
||||
ASSUMPTION 3: the volume group/physical devices supporting the logical volumes `myvg_root-[first,second,third]` do have some extra un-allocated space you can use to extend the parition mounted on `/mnt/[first,second,third]`.
|
||||
|
||||
Write the following playbook (named `extend.yml`) assuming that you want the new partitions respectively resized to 4, 6 and 2 GB:
|
||||
```
|
||||
---
|
||||
- name: Extend partition
|
||||
hosts: your_server.psi.ch
|
||||
roles:
|
||||
- name: psi.local_storage
|
||||
psi_local_storage_resizefs:
|
||||
- path: '/mnt/second'
|
||||
size: 4
|
||||
- path: '/mnt/third'
|
||||
size: 6
|
||||
- path: '/mnt/first'
|
||||
size: 2
|
||||
...
|
||||
```
|
||||
Execute it with usual `ansible-playbook` command:
|
||||
```
|
||||
[vagrant@control ~]$ ansible-playbook extend.yml
|
||||
|
||||
PLAY [Extend storage] ******************************************************************************************************************************
|
||||
|
||||
TASK [Gathering Facts] *****************************************************************************************************************************
|
||||
[DEPRECATION WARNING]: Distribution centos 8.2.2004 on host your_server should use /usr/libexec/platform-python, but is using /usr/bin/python for
|
||||
backward compatibility with prior Ansible releases. A future Ansible release will default to using the discovered platform python for this host.
|
||||
See https://docs.ansible.com/ansible/2.9/reference_appendices/interpreter_discovery.html for more information. This feature will be removed in
|
||||
version 2.12. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.
|
||||
ok: [your_server]
|
||||
|
||||
TASK [psi.local_storage : Check that user specified a fstype which is supported] *******************************************************************
|
||||
|
||||
TASK [psi.local_storage : Ensure lmv2 package is installed] ****************************************************************************************
|
||||
skipping: [your_server]
|
||||
|
||||
TASK [psi.local_storage : Create VG '' on physical volume '[]'] ************************************************************************************
|
||||
skipping: [your_server]
|
||||
|
||||
TASK [psi.local_storage : Create logical volume(s) on ''] ******************************************************************************************
|
||||
|
||||
TASK [psi.local_storage : Create not mounted filesystem(s)] ****************************************************************************************
|
||||
|
||||
TASK [psi.local_storage : Mount filesystem(s)] *****************************************************************************************************
|
||||
|
||||
TASK [psi.local_storage : Resize Filesystem] *******************************************************************************************************
|
||||
changed: [your_server] => (item={'path': '/mnt/second', 'size': 4})
|
||||
changed: [your_server] => (item={'path': '/mnt/third', 'size': 6})
|
||||
changed: [your_server] => (item={'path': '/mnt/first', 'size': 2})
|
||||
|
||||
PLAY RECAP *****************************************************************************************************************************************
|
||||
your_server : ok=2 changed=1 unreachable=0 failed=0 skipped=6 rescued=0 ignored=0
|
||||
```
|
||||
#### Use Case 2: extending an existing partition after system first installation using additional device
|
||||
|
||||
ASSUMPTION 1: you have just installed a new system with the following partition scheme LVM-based:
|
||||
```
|
||||
[vagrant@your_server ~]$ df -h
|
||||
Filesystem Size Used Avail Use% Mounted on
|
||||
devtmpfs 393M 0 393M 0% /dev
|
||||
tmpfs 410M 0 410M 0% /dev/shm
|
||||
tmpfs 410M 5.7M 404M 2% /run
|
||||
tmpfs 410M 0 410M 0% /sys/fs/cgroup
|
||||
/dev/mapper/cl-root 50G 2.6G 48G 6% /
|
||||
/dev/sda1 976M 183M 726M 21% /boot
|
||||
/dev/mapper/cl-home 27G 225M 27G 1% /home
|
||||
tmpfs 82M 0 82M 0% /run/user/1000
|
||||
/dev/mapper/myvg_root-first 1014M 40M 975M 4% /mnt/first
|
||||
/dev/mapper/myvg_root-second 976M 2.6M 907M 1% /mnt/second
|
||||
/dev/mapper/myvg_root-third 1014M 40M 975M 4% /mnt/third
|
||||
```
|
||||
ASSUMPTION 2: the partition scheme was not created by you (or by the automatic Tower system) using a specific playbook. It is just there and you do not like the current Size of `/mnt/first`
|
||||
|
||||
ASSUMPTION 3: you have a new HDD/SSD attached to your node and identified by device `/dev/sdc`, and you want to use it to expand the volume groups, logical volumes in order to be free to freely enlarge your partitions.
|
||||
|
||||
This procedure requires a bit more know-how on linux and logical volume management, but the following explanation will try to guide you as much as possible.
|
||||
|
||||
##### Step1 - Get Volume Group and physical devices
|
||||
Identify the volume group associated with the partition `/mnt/first` you want to expand, by executing this:
|
||||
```
|
||||
[root@your_server ~]# theVG=$(lvdisplay $(df -h /mnt/first|grep /mnt/first|awk '{print $1}')|grep "VG Name"|awk '{print $NF}')
|
||||
```
|
||||
|
||||
Identify the physical volumes on which the `vggroup` is built on:
|
||||
```
|
||||
[root@your_server ~]# vgdisplay -v $theVG |grep "PV Name"|awk '{print $NF}'
|
||||
/dev/sdb1
|
||||
/dev/sdb2
|
||||
/dev/sdb3
|
||||
```
|
||||
Take notes of these three physical devices and remember that you will have to add to this list your new device `/dev/sdd`.
|
||||
|
||||
##### Step2 - Get Logical volume name and filesystem type
|
||||
|
||||
Execute the following command to get the logical volume name:
|
||||
```
|
||||
[root@your_server ~]# theLV=$(lvdisplay $(df -h /mnt/first|grep /mnt/first|awk '{print $1}')|grep "LV Name"|awk '{print $NF}')
|
||||
[root@your_server ~]# echo $theLV
|
||||
first
|
||||
```
|
||||
Identify the filesystem type by executing this command:
|
||||
```
|
||||
[root@your_server ~]# theFS=$(mount|grep "/mnt/first"|awk '{print $5}')
|
||||
[root@your_server ~]# echo $theFS
|
||||
xfs
|
||||
```
|
||||
##### Step3 - Prepare the ansible playbook
|
||||
|
||||
Write the following playbook (named `extend.yml`) taking care to use the correct volume group name (`theVG`), logical volume name (`theLV`) and the filesystem type (`theFS`); of course also keep unchanged the mount point:
|
||||
```
|
||||
---
|
||||
- name: Extend storage
|
||||
hosts: your_server
|
||||
roles:
|
||||
- name: psi.local_storage
|
||||
psi_local_storage_physical_volumes:
|
||||
- /dev/sdb1
|
||||
- /dev/sdb2
|
||||
- /dev/sdb3
|
||||
- /dev/sdc # it doesn't matter that you didn't do any partition inside sdc; LVM is able to cope with RAW devices as well
|
||||
psi_local_storage_physical_name: 'myvg_root'
|
||||
psi_local_storage_logical_volumes:
|
||||
- name: 'first'
|
||||
size: 3
|
||||
fstype: 'xfs'
|
||||
mount_point: '/mnt/first'
|
||||
createfs: true
|
||||
...
|
||||
```
|
||||
Note that we have put in the playbook the three devices that we found above (output of `vgdisplay`: `/dev/sdb[1,2,3]`) plus the new one `/dev/sdd`.
|
||||
|
||||
Also note that the original size of the `/mnt/first` filesystem was 1GB, now in the playbook we put 3 (implicit unit is GB).
|
||||
|
||||
|
||||
Execute your playbook (suppose you called it as `extend.yml`):
|
||||
```
|
||||
[vagrant@control ~]$ ansible-playbook extend.yml
|
||||
|
||||
PLAY [Extend storage] **********************************************************************************************************************************************************************************************
|
||||
|
||||
TASK [Gathering Facts] *********************************************************************************************************************************************************************************************
|
||||
|
||||
TASK [psi.local_storage : Check that user specified a fstype which is supported] ***********************************************************************************************************************************
|
||||
skipping: [your_server] => (item={'name': 'first', 'size': 3, 'fstype': 'xfs', 'mount_point': '/mnt/first', 'createfs': True})
|
||||
|
||||
TASK [psi.local_storage : Ensure lmv2 package is installed] ********************************************************************************************************************************************************
|
||||
ok: [your_server]
|
||||
|
||||
TASK [psi.local_storage : Create VG 'myvg_root' on physical volume '['/dev/sdb1', '/dev/sdb2', '/dev/sdb3']'] ******************************************************************************************************
|
||||
ok: [your_server]
|
||||
|
||||
TASK [psi.local_storage : Create logical volume(s) on 'myvg_root'] *************************************************************************************************************************************************
|
||||
changed: [your_server] => (item={'name': 'first', 'size': 3, 'fstype': 'xfs', 'mount_point': '/mnt/first', 'createfs': True})
|
||||
|
||||
TASK [psi.local_storage : Create not mounted filesystem(s)] ********************************************************************************************************************************************************
|
||||
ok: [your_server] => (item={'name': 'first', 'size': 3, 'fstype': 'xfs', 'mount_point': '/mnt/first', 'createfs': True})
|
||||
|
||||
TASK [psi.local_storage : Mount filesystem(s)] *********************************************************************************************************************************************************************
|
||||
ok: [your_server] => (item={'name': 'first', 'size': 3, 'fstype': 'xfs', 'mount_point': '/mnt/first', 'createfs': True})
|
||||
|
||||
TASK [psi.local_storage : Resize XFS filesystem(s)] ****************************************************************************************************************************************************************
|
||||
changed: [your_server] => (item={'name': 'first', 'size': 3, 'fstype': 'xfs', 'mount_point': '/mnt/first', 'createfs': True})
|
||||
|
||||
TASK [psi.local_storage : Resize EXT filesystem(s)] ****************************************************************************************************************************************************************
|
||||
skipping: [your_server] => (item={'name': 'first', 'size': 3, 'fstype': 'xfs', 'mount_point': '/mnt/first', 'createfs': True})
|
||||
|
||||
PLAY RECAP *********************************************************************************************************************************************************************************************************
|
||||
your_server : ok=7 changed=2 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0
|
||||
```
|
||||
|
||||
And now check the size of `/mnt/first` on your your_server node:
|
||||
```
|
||||
[root@your_server ~]# df -h
|
||||
Filesystem Size Used Avail Use% Mounted on
|
||||
devtmpfs 393M 0 393M 0% /dev
|
||||
tmpfs 410M 0 410M 0% /dev/shm
|
||||
tmpfs 410M 5.7M 404M 2% /run
|
||||
tmpfs 410M 0 410M 0% /sys/fs/cgroup
|
||||
/dev/mapper/cl-root 50G 2.6G 48G 6% /
|
||||
/dev/sda1 976M 183M 726M 21% /boot
|
||||
/dev/mapper/cl-home 27G 225M 27G 1% /home
|
||||
tmpfs 82M 0 82M 0% /run/user/1000
|
||||
/dev/mapper/myvg_root-first 3.0G 55M 3.0G 2% /mnt/first
|
||||
/dev/mapper/myvg_root-second 976M 2.6M 907M 1% /mnt/second
|
||||
/dev/mapper/myvg_root-third 1014M 40M 975M 4% /mnt/third
|
||||
|
||||
```
|
||||
|
||||
#### Mount mountpoints
|
||||
Define the following dictionary:
|
||||
```yaml
|
||||
psi_mounts_mounts:
|
||||
- fstype: <ext4|xfs>
|
||||
mount_point: <somepath>
|
||||
device: /dev/<somedevice_or_lvm>
|
||||
options: <otps-to-be-put-in-fstab>
|
||||
state: mounted|unmounted|absent|present|remounted
|
||||
- fstype: <ext4|xfs>
|
||||
mount_point: <somepath2>
|
||||
device: /dev/<somedevice_or_lvm>
|
||||
options: <otps-to-be-put-in-fstab>
|
||||
state: mounted|unmounted|absent|present|remounted
|
||||
- [...]
|
||||
```
|
||||
and run this playbook.
|
||||
Note that block devices `/dev/something` must already be there and filesystem must me created.
|
||||
* `mounted/unmounted` has a clear meaning
|
||||
* `absent/present` concern the presence or not of the mount directive in /etc/fstab to have the mount automatically done at every boot of the system
|
||||
* `remounted` means that you want to remount the partition because, for example, you changed some parameter or option.
|
||||
|
||||
---
|
||||
### System Registration
|
||||
Maintained by spreitzer_s
|
||||
|
||||
Basically your system should receive default values that are supplied globally, from the PSI Default Inventory in GitLab and AWX, to successfully register it with Satellite, so it will have access to software repositories automatically.
|
||||
|
||||
However the following settings can be made.
|
||||
|
||||
```yaml
|
||||
psi_subscription_manager_activation_key: RHEL8-GFA
|
||||
psi_subscription_manager_org: PSI
|
||||
psi_subscription_manager_server: satint.psi.ch
|
||||
psi_subscription_manager_force_register: 'False'
|
||||
```
|
||||
|
||||
#### psi_subscription_manager_activation_key
|
||||
The Satellite activation key to use. Usually something that starts with `RHEL8-`.
|
||||
|
||||
#### psi_subscription_manager_org
|
||||
The Satellite Organization to use. Usually `PSI`.
|
||||
|
||||
#### psi_subscription_manager_server
|
||||
The Satellite to register with. Usually `satint.psi.ch`.
|
||||
|
||||
#### psi_subscription_manager_force_register
|
||||
Whether to or not run the subscription-management enforced. Usually `true` to ensure a system has software access.
|
||||
|
||||
---
|
||||
### SELinux
|
||||
Maintained by caubet_m
|
||||
|
||||
This documentation shows how to manage SELinux with the Ansible *selinux* role. More examples can be found in the **['linux-system-roles' Official GitHUB Project Webpage](https://github.com/linux-system-roles/selinux)**
|
||||
|
||||
#### Enabling/Disabling SELinux
|
||||
|
||||
The defaults at PSI are:
|
||||
|
||||
```yaml
|
||||
selinux_state: enforcing
|
||||
selinux_policy: targeted
|
||||
```
|
||||
* Allowed values for **`selinux_state`** are `disabled`, `enforcing` and `permissive`.
|
||||
* Allowed values for **`selinux_policy`** are `targeted`, and `mls`.
|
||||
|
||||
#### (Un)Setting SELinux booleans
|
||||
|
||||
Common examples for setting SELinux booleans are the following:
|
||||
* Enabling the `use_nfs_home_dirs` Boolean to allow the usage of NFS based home directories, and make it persistent accross machine reboots.
|
||||
* Enabling the `httpd_use_nfs` Boolean to allow *httpd* to access and share NFS volumes.
|
||||
|
||||
```yaml
|
||||
selinux_booleans:
|
||||
- name: use_nfs_home_dirs
|
||||
state: on
|
||||
persistent: 'yes'
|
||||
- name: httpd_use_nfs
|
||||
state: on
|
||||
```
|
||||
Enable the httpd_use_nfs Boolean to allow httpd to access and share NFS volumes (labeled with the nfs_t type):
|
||||
|
||||
#### Set SELinux file contexts
|
||||
|
||||
In this example, we set /tmp/test_dir directories with `user_home_dir_t` context.
|
||||
|
||||
```yaml
|
||||
selinux_fcontexts:
|
||||
- target: '/tmp/test_dir(/.*)?'
|
||||
setype: user_home_dir_t
|
||||
ftype: d
|
||||
state: present
|
||||
```
|
||||
|
||||
#### Set SELinux Ports
|
||||
|
||||
In the example below, we allow SSH to use TCP port 22100, in that way we can tell *sshd* to listen on a non-standard port 22100 instead of the standard port 22. For that, we would neeed to update also `/etc/ssh/sshd_config` by changing `Port 22`to `Port 22100`.
|
||||
|
||||
```yaml
|
||||
selinux_ports:
|
||||
- ports: '22100'
|
||||
proto: tcp
|
||||
setype: ssh_port_t
|
||||
```
|
||||
|
||||
* (Persistent file contextes, semanage fcontext, if you have time)
|
||||
|
||||
#### Set linux user to SELinux mapping
|
||||
|
||||
When `selinux_policy: mls`, one would need to update linux users to SELinux users mapping.
|
||||
|
||||
In the example, we remove `feichtinger` from `staff_u`, and we add a new user `caubet_m`, as well as a generic username `staff`, to be mapped to the SELinux user `staff_u` (`caubet_m`, has more security privileges than a generic `staff` user; this is defined with `serange`). On the other hand, we set that any other not mapped user (`__default__`), should be mapped to the SELinux user `user_u`. Any user mapped in that way, have very low security level (`s0`, which is the lowest).
|
||||
|
||||
```yaml
|
||||
selinux_logins:
|
||||
- login: feichtinger
|
||||
seuser: staff_u
|
||||
state: absent
|
||||
- login: caubet_m
|
||||
seuser: staff_u
|
||||
serange: 's0-s15:c0.c1023'
|
||||
- login: staff
|
||||
seuser: staff_u
|
||||
serange: 's2:c100'
|
||||
- login: __default__
|
||||
seuser: user_u
|
||||
serange: 's0-s0:'
|
||||
|
||||
```
|
||||
|
||||
In example:
|
||||
|
||||
```bash
|
||||
[root@hpc-rhel8devel01 home]# semanage login -l
|
||||
|
||||
__default__ user_u s0-s0 *
|
||||
caubet_m staff_u s0-s15:c0.c1023 *
|
||||
root root s0-s15:c0.c1023 *
|
||||
staff staff_u s2:c100 *
|
||||
sysadm staff_u s0-s15:c0.c1023 *
|
||||
system_u system_u s0-s15:c0.c1023 *
|
||||
```
|
||||
|
||||
#### Restorecon
|
||||
|
||||
Run `restorecon` on filesystem trees for applying `selinux` policies:
|
||||
|
||||
```yaml
|
||||
selinux_restore_dirs:
|
||||
- /var
|
||||
- /tmp
|
||||
```
|
||||
|
||||
---
|
||||
### Systemd Services
|
||||
Maintained by caubet_m
|
||||
|
||||
This role creates by default **systemd** **service** *units*, however, is also possible to configure
|
||||
other system *units* such like **slice**, **socket**, **timers*, **mount**, etc.
|
||||
|
||||
Full examples for the **systemd** Ansible role can be found in the **['0x0I' Official GitHUB Project Webpage](https://github.com/0x0I/ansible-role-systemd#role-variables)**. The example below, shows how to create different *systemd* units: *service*, *socket*, *mount*, *target* and *timer*
|
||||
|
||||
```yaml
|
||||
unit_config:
|
||||
- name: "test-service"
|
||||
Unit:
|
||||
Description: "This is a test service unit which listens at port 1234"
|
||||
After: network-online.target
|
||||
Wants: network-online.target
|
||||
Requires: test-service.socket
|
||||
Service:
|
||||
User: 'kitchen'
|
||||
Group: 'kitchen'
|
||||
ExecStart: '/usr/bin/sleep infinity'
|
||||
ExecReload: '/bin/kill -s HUP $MAINPID'
|
||||
Install:
|
||||
WantedBy: 'multi-user.target'
|
||||
- name: "test-service"
|
||||
type: "socket"
|
||||
Unit:
|
||||
Description: "This is a test socket unit which specifies the test-service 'socket' unit type"
|
||||
Socket:
|
||||
ListenStream: '0.0.0.0:1234'
|
||||
Accept: 'true'
|
||||
Install:
|
||||
WantedBy: 'sockets.target'
|
||||
- name: "tmp-stdin"
|
||||
type: "mount"
|
||||
path: "/run/systemd/system"
|
||||
Unit:
|
||||
Description: "This is a test mount unit which overrides the default unit path"
|
||||
Mount:
|
||||
What: '/dev/stdin'
|
||||
Where: '/tmp/stdin'
|
||||
Install:
|
||||
WantedBy: 'mount.target'
|
||||
- name: "test-target"
|
||||
type: "target"
|
||||
path: "/etc/systemd/system"
|
||||
Unit:
|
||||
Description: This is an example unit Target
|
||||
Wants: test-service.service test-service.socket tmp-stdin.mount
|
||||
PartOf: test-service.service
|
||||
- name: dnf-makecache
|
||||
type: timer
|
||||
Unit:
|
||||
Description: "This is a test timer unit which refreshes dnf cache"
|
||||
Timer:
|
||||
OnBootSec: 10min
|
||||
OnUnitInactiveSec: 1h
|
||||
Unit: dnf-makecache.service
|
||||
Install:
|
||||
WantedBy: multi-user.target
|
||||
```
|
||||
|
||||
---
|
||||
### System Time/NTP
|
||||
Maintained by caubet_m
|
||||
|
||||
This document describes how to configure the system 'time' on RHEL8 based systems. Current *defaults* should fit for most of the cases at PSI:
|
||||
* The recommended service on RHEL8 systems for configuring *system time* is **`chrony`**
|
||||
* PSI provides different NTP servers which should be accessible by most of the PSI subnets:
|
||||
* `pstime1.psi.ch`
|
||||
* `pstime2.psi.ch`
|
||||
* `pstime3.psi.ch`
|
||||
* We usually apply custom settings in Chrony or logging and rapid clock measuring during boot time:
|
||||
* We setup `initstepslew` to `60` seconds. It is, if system's error is found to be 60 seconds or less, a slew will be used to correct it; if the error is above 60 seconds, a step will be used.
|
||||
* We log different metrics which would help to debug different timesync related problems: `measurements statistics tracking`
|
||||
|
||||
Example of default configuration at PSI, which should be adapted according to your needs:
|
||||
|
||||
```yaml
|
||||
# linux-system-roles.timesync settings
|
||||
timesync_chrony_custom_settings:
|
||||
- "# Allow chronyd to make a rapid measurement of the system and correct clock error at boot time"
|
||||
- "initstepslew 60 pstime1.psi.ch pstime2.psi.ch pstime3.psi.ch"
|
||||
- "# Select which information is logged."
|
||||
- "log measurements statistics tracking"
|
||||
timesync_ntp_provider: chrony
|
||||
timesync_ntp_servers:
|
||||
- hostname: pstime1.psi.ch
|
||||
- hostname: pstime2.psi.ch
|
||||
- hostname: pstime3.psi.ch
|
||||
```
|
||||
|
||||
---
|
||||
### User Management
|
||||
Maintained by spreitzer_s
|
||||
|
||||
User management is divided in two parts:
|
||||
* PSI Active Directory
|
||||
* Local system
|
||||
|
||||
**Overall users and group and group memberships must be managed in Active Directory!** Please consult the PSI Service Catalog to request users, groups and group membership as well as their removal. http://css.psi.ch/psisp
|
||||
|
||||
*Use `*_common` for inventory group variables and `*_extra` for host variables.*
|
||||
|
||||
#### psi_aaa_allow_groups{_common,_extra}
|
||||
|
||||
List of groups that are allowed to login to a system.
|
||||
|
||||
```yaml
|
||||
psi_aaa_allow_groups_extra:
|
||||
- unx-ait
|
||||
- unx-sls
|
||||
```
|
||||
|
||||
#### psi_aaa_allow_users{_common,_extra}
|
||||
|
||||
List of users that are allowed to login to a system. *Prefer using groups over users!*
|
||||
|
||||
```yaml
|
||||
psi_aaa_allow_users_extra:
|
||||
- kapeller
|
||||
- talamo_i
|
||||
```
|
||||
|
||||
### Local User Management
|
||||
{{% alert text="Do not use this method, prefer Active Directory for users" %}}
|
||||
|
||||
#### psi_aaa_local_sudo_rules{_common,_extra}
|
||||
|
||||
Manage local sudo roles by lists of (name, content and state). Be very cautios with the sudo rules, as one faulty rule will break sudo for the whole system.
|
||||
|
||||
```yaml
|
||||
psi_aaa_local_sudo_rules_extra:
|
||||
- name: sspreitz-root-nopasswd
|
||||
content: "sspreitz ALL=(ALL) NOPASSWD: ALL\n"
|
||||
- name: group-wheel-root-nopasswd
|
||||
content: "%wheel ALL=(ALL) NOPASSWD: ALL\n"
|
||||
- name: linuxsupport-root-nopasswd
|
||||
content: |
|
||||
jill ALL=(ALL) NOPASSWD: ALL
|
||||
joe ALL=(ALL) NOPASSWD: ALL
|
||||
jack ALL=(ALL) NOPASSWD: ALL
|
||||
tom ALL=(ALL) NOPASSWD: ALL
|
||||
- name: sam-root-nopasswd
|
||||
state: absent
|
||||
```
|
||||
|
||||
#### psi_aaa_local_groups{_common,_extra}
|
||||
|
||||
Manage local groups by a list of ansible group definitions. https://docs.ansible.com/ansible/latest/collections/ansible/builtin/group_module.html
|
||||
|
||||
```yaml
|
||||
psi_aaa_local_groups_extra:
|
||||
- name: group1
|
||||
gid: 30000
|
||||
- name: group2
|
||||
- name: support
|
||||
system: yes
|
||||
- name: group3
|
||||
state: absent
|
||||
```
|
||||
|
||||
#### psi_aaa_local_users{_common,_extra}
|
||||
|
||||
Manage local users by a list of ansible user definitions. https://docs.ansible.com/ansible/latest/collections/ansible/builtin/user_module.html
|
||||
|
||||
```yaml
|
||||
psi_aaa_local_users_extra:
|
||||
- name: guest
|
||||
- name: joe
|
||||
uid: 1000
|
||||
group: group1
|
||||
groups:
|
||||
- wheel
|
||||
- staff
|
||||
- audio
|
||||
home: /home/joe
|
||||
shell: /bin/fish
|
||||
# mkpasswd -m sha512crypt joe
|
||||
password: '$6$Mrq9msM24W$boAK1IYwuG6ze1qgk.HpqMqvj/zRThT2fTrb80kJTAiMg1CNXjbEEMH7A8KwAeKQJZuF14KRrpOK5NXxYvqqn1'
|
||||
- name: jill
|
||||
state: absent
|
||||
remove: yes
|
||||
```
|
||||
|
||||
#### psi_aaa_local_authorized_keys{_common,_extra}
|
||||
|
||||
Manage local ssh authorized keys by ansible ssh authorized keys definitions. https://docs.ansible.com/ansible/latest/collections/ansible/posix/authorized_key_module.html
|
||||
|
||||
```yaml
|
||||
psi_aaa_local_authorized_keys_extra:
|
||||
- user: sspreitz
|
||||
key: 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC9gU640HBk4m0OA4b2ziTCnVP6QYhs2Zs/LJWTN85+vCudgZfiMip2MAAR0OlOVtB4JYXJh83Rihj0REA13ei3akAPzgG+B4Qlk3QYA2Bf2YDjRGqwgpmhVlTNgJy+l9lS9rn5kPheXTi1GOgGVKi4jd5f6TuYhMBmSl64oCtWnanIwXd/u6teStTd7V0HKgev+GbAvTJPFoxOHFSV51mMvFkkW0s0cPTwLvekAPsnjw4ztEoX8Ar72U+KOnt6YLOEuKB0bKZ4PKTEz7woltDcXKzN9g5HKSY+RgSk9APrOol+HVgs841/1KChri7xPao4J1OzU0Ap6wkG+GfqPVc/ sspreitz@redhat.com'
|
||||
- user: evil
|
||||
key: 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC9gU640HBk4m0OA4b2ziTCnVP6QYhs2Zs/LJWTN85+vCudgZfiMip2MAAR0OlOVtB4JYXJh83Rihj0REA13ei3akAPzgG+B4Qlk3QYA2Bf2YDjRGqwgpmhVlTNgJy+l9lS9rn5kPheXTi1GOgGVKi4jd5f6TuYhMBmSl64oCtWnanIwXd/u6teStTd7V0HKgev+GbAvTJPFoxOHFSV51mMvFkkW0s0cPTwLvekAPsnjw4ztEoX8Ar72U+KOnt6YLOEuKB0bKZ4PKTEz7woltDcXKzN9g5HKSY+RgSk9APrOol+HVgs841/1KChri7xPao4J1OzU0Ap6wkG+GfqPVc/ mrevil@example.com'
|
||||
state: absent
|
||||
```
|
||||
|
||||
---
|
||||
### Software Management
|
||||
Maintained by klar_t
|
||||
|
||||
#### psi_packer_repo
|
||||
|
||||
A merged dictionary of yum repository definitions
|
||||
|
||||
#### psi_packer_inst
|
||||
|
||||
A merged list of rpm packages to be installed
|
||||
|
||||
#### psi_packer_rem
|
||||
|
||||
A merged list of rpm packages to be removed
|
||||
|
||||
#### psi_packer_update
|
||||
|
||||
`true` or `false` on whether to update all packages on each ansible run
|
||||
|
||||
#### Important
|
||||
|
||||
the `psi_packer_repo` and the `psi_packer_inst` variables are merged.
|
||||
It is a wildcard merge, so any suffix can be used, but it is recommended to use the group- or hostname, so there is no accidental overlap.
|
||||
The list of enabled and the list of disabled repos will be added to the repo file only. Otherwise a repo may e defined but will be ignored.
|
||||
These 2 lists are also wildcard merged.
|
||||
|
||||
```yaml
|
||||
- hosts: servers
|
||||
vars:
|
||||
psi_packer_update: true
|
||||
psi_packer_repo_group:
|
||||
myrepo:
|
||||
description: This is my repo
|
||||
baseurl: http://example.com/repos/myrepo/
|
||||
gpgcheck: yes
|
||||
gpgkey: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-myrepo
|
||||
psi_packer_repo_host:
|
||||
myotherrepo:
|
||||
description: This is my other repo
|
||||
baseurl: http://example.com/repos/myotherrepo/
|
||||
gpgcheck: yes
|
||||
gpgkey: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-myrepo
|
||||
psi_packer_enabled_repos_group:
|
||||
- myrepo
|
||||
psi_packer_disabled_repos_host:
|
||||
- myotherrepo
|
||||
psi_packer_inst_group:
|
||||
- httpd
|
||||
- mariadb
|
||||
psi_packer_inst_host:
|
||||
- mc
|
||||
- nano
|
||||
psi_packer_del_group:
|
||||
- matlab
|
||||
- office
|
||||
psi_packer_del_host:
|
||||
- kernel-devel
|
||||
- afs
|
||||
roles:
|
||||
- psi.packer
|
||||
```
|
||||
---
|
||||
### AFS
|
||||
Maintained by klar_t
|
||||
|
||||
Note: AFS and AFS homes are not enabled by default in RHEL-8.
|
||||
|
||||
PSI Linux Engineering does not support AFS and AFS homes. Contact Achim Gsell if you need AFS and AFS homes.
|
||||
|
||||
LVM partitioning and free space on the root VG are necessary to use this role. (The VG is selected based on where the root file system is located, the actual name does not matter)
|
||||
|
||||
#### psi_yfs_size
|
||||
|
||||
Default: `2147483648`
|
||||
|
||||
Cache LV size, strictly in bytes
|
||||
|
||||
#### psi_yfs_remove
|
||||
|
||||
Default: `false`
|
||||
|
||||
Set this to true and remove everything the role would have installed
|
||||
|
||||
|
||||
#### Example Playbook
|
||||
|
||||
An example of how to use this role (with variables passed in as parameters).
|
||||
|
||||
```yaml
|
||||
- hosts: servers
|
||||
roles:
|
||||
- psi.yfs
|
||||
psi_yfs_size: 2147483648
|
||||
```
|
||||
@@ -1,55 +0,0 @@
|
||||
# Design Guiding Principles
|
||||
|
||||
This page describes the design decisions made for RHEL-8 and the reasoning.
|
||||
|
||||
## General
|
||||
|
||||
* *To prefer software and solutions with support available externally*</br>
|
||||
This is to reduce the risk of isolated knowledge leaving PSI as well as to reduce the support load of present PSI Linux Engineers.
|
||||
* *To prefer to enable self-service for Linux as wide as possible at PSI*</br>
|
||||
This is to enable users and to give space for Proof of Concepts and trial and error.
|
||||
|
||||
## Red Hat Satellite
|
||||
*to supersede bob/sysdb*
|
||||
|
||||
Red Hat Satellite is an all-in-one product to
|
||||
* Deploy and install Linux systems
|
||||
* Manage Linux software repositories centrally
|
||||
* Visualization of software status on hosts
|
||||
* Can install machines in DMZ environments via *Capsules*
|
||||
* Has role based access control (RBAC) to support PSI division segregation
|
||||
|
||||
## Ansible Configuration Management
|
||||
*to supersede Puppet*
|
||||
|
||||
Ansible
|
||||
* Has a lower learning curve than Puppet
|
||||
* Results can be achieved faster than in Puppet
|
||||
* Ansible is in strategic focus of Red Hat
|
||||
* [Puppet is/will go out-of-support from Red Hat](https://access.redhat.com/articles/5065671)
|
||||
* [Ansible Galaxy](https://galaxy.ansible.com) provides many externally maintained collections and roles
|
||||
|
||||
## Ansible Tower
|
||||
*to supersede Puppet*
|
||||
|
||||
Ansible Tower / AWX
|
||||
* Is a central automation solution and can run Ansible playbooks centrally
|
||||
* Be used as Ansible Configuration Management for RHEL-8+ systems
|
||||
* Allows flexible control
|
||||
* Can be used as general purpose automation platform
|
||||
* Has role based access control (RBAC) to support PSI division and network segregation
|
||||
|
||||
## User Management
|
||||
*SSSD and Microsoft Active Directory to supersede legacy pam customizations*
|
||||
|
||||
* To prefer to attach all RHEL-8+ systems to the central PSI Microsoft Active Directory (AD) via SSSD
|
||||
* To prefer centrally managing users and groups for Linux in AD
|
||||
* To prefer to manage system access for Linux in AD
|
||||
* To prefer to integrate Linux user, group and access management into ServiceNow as a self-service
|
||||
|
||||
## Network Filesystems
|
||||
*to focus on local disks and optionally provide Network Fileystem support*
|
||||
|
||||
* By default to place home directories on local disks</br>
|
||||
This is to avoid users being affected to network issues on logins. Such as missing authentication tokens or shared and locked files in firefox profiles.</br>
|
||||
The homes on network shares still being accessable if requested.
|
||||
@@ -3,14 +3,29 @@ title: RHEL-8
|
||||
description: PSI Red Hat Enterprise Linux 8
|
||||
lead: ""
|
||||
date: 2020-10-06T08:48:23+00:00
|
||||
lastmod: 2020-10-06T08:48:23+00:00
|
||||
lastmod: 2022-05-10T11:13:00+00:00
|
||||
draft: false
|
||||
images: []
|
||||
toc: true
|
||||
---
|
||||
# RHEL 8
|
||||
# Red Hat Enterprise Linux 8
|
||||
|
||||
* [Installation](installation)
|
||||
* [Configuration](configuration)
|
||||
The current state of RHEL 8.6 support is very alpha. It is possible to install a system and install packages provided by Red Hat.
|
||||
The configuration management is done with Puppet like for RHEL 7.
|
||||
|
||||
## Testing
|
||||
|
||||
It looks like it works already a lot out of the box, but no guarantee can be given unless your specfic setup has been tested. The epic [RHEL 8.6 Alpha Test](https://jira.psi.ch/browse/PSILINUX-93) lists the currently knowns issues. Please add your bugs there too.
|
||||
|
||||
### Major Known Issues
|
||||
|
||||
### Major Missing Features
|
||||
|
||||
- default user home is local unless configured to be on AFS [PSILINUX-97](https://jira.psi.ch/browse/PSILINUX-97)
|
||||
- security patches are automatically installed [PSILINUX-98](https://jira.psi.ch/browse/PSILINUX-98)
|
||||
- minimal default installation, aka gem, git and postfix is not installed by default [PSILINUX-100](https://jira.psi.ch/browse/PSILINUX-100)
|
||||
|
||||
## Documenatation
|
||||
|
||||
* [Installation (Alpha)](installation)
|
||||
* [Vendor Documentation](vendor_documentation)
|
||||
* [Design Guiding Principles](design_guiding_principles)
|
||||
@@ -1,58 +1,47 @@
|
||||
# Installation
|
||||
# Installation (Alpha)
|
||||
|
||||
## Type
|
||||
### From Network
|
||||
## Network Installation
|
||||
|
||||
1. Login to <a href="https://rhel-8-awx.psi.ch/" target="_blank">Red Hat Ansible Tower (AWX)</a> using your PSI credentials
|
||||
<br/><br/>
|
||||

|
||||
<br/><br/>
|
||||
2. Launch the `Create Host` [Job Template](https://rhel-8-awx.psi.ch/#/templates?template_search=page_size:20;order_by:name;type:workflow_job_template,job_template;search:Create;search:Host). Click on the small rocket.
|
||||
<br/><br/>
|
||||

|
||||
<br/><br/>
|
||||
3. Enter the new installation specific details such as your PSI credentials, hostname, mac address and root password.
|
||||
<br/><br/>
|
||||

|
||||
<br/><br/>
|
||||
4. Select the applicable PSI division the Host belongs to, or AIT, and the PSI Network Zone. PSIGEN is the office network.
|
||||
<br/><br/>
|
||||

|
||||
<br/><br/>
|
||||
5. Select `Launch` to register your new system in the portfolio and to prepare the network boot.
|
||||
<br/><br/>
|
||||

|
||||
<br/><br/>
|
||||
5. Power on the target machine and boot from network.
|
||||
6. In the network boot prompt, select `Red Hat Enterprise Linux 8 Network Install`.
|
||||
7. The system will install and reboot.
|
||||
8. After the first reboot the system will configure itself and will be accessible in a couple of minutes.
|
||||
9. Within the next 2 hours, you should be able to login with your Kerberos or PSI Active Directory or root credentials.
|
||||
10. If you can not login to the system within 2 hours, please contact the [AIT Helpdesk](/help/).
|
||||
(note the screenshots still show v8.5, but v8.6 was just released so we proceed with it)
|
||||
|
||||
### From Media
|
||||
The machine you want to install needs to be registered in `sysdb`, so far it works best in the `rhel8_preprod` Puppet environment:
|
||||
```
|
||||
FQDN=...
|
||||
bob node set-attr $FQDN puppet_env=rhel8_preprod
|
||||
```
|
||||
|
||||
1. Download, mount or burn the installation media from [Installation Media](https://satint.psi.ch/psi/http/isos/PSI/Library/content/dist/rhel8/8/x86_64/baseos/iso/).
|
||||
2. Install the Host.
|
||||
3. Run the following command as `root`: <br/>
|
||||
`bash <(curl -q -k -L http://satint.psi.ch/pub/psi-rhel-8-registration.sh)`
|
||||
4. Answer the questions.
|
||||
5. The script will register the system and add it to the PSI RHEL-8 systems portfolio.
|
||||
6. An Ansible job run will be triggered, which will configure and finish the system.
|
||||
Optional you can set `netboot` and RHEL 8.6 installer but that can also be selected manually in be boot menu:
|
||||
```
|
||||
bob node netboot $FQDN
|
||||
bob node set-attr $FQDN ipxe_installer=rhel85install
|
||||
```
|
||||
### Installation with UEFI
|
||||
Start the machine and select network boot (if not already the default), then you get following menu:
|
||||

|
||||
|
||||
### From Media - Unattended
|
||||
There select "Windows and Tools Menus" (do not get irritated by the name) to get into the iPXE menu, where you can do also a lot of other stuff.
|
||||

|
||||
(I plan to get rid of above menu as it also breaks automatic installation by `sysdb` configuration).
|
||||
|
||||
1. Download, mount or burn the installation media from [Installation Media](https://satint.psi.ch/psi/http/isos/PSI/Library/content/dist/rhel8/8/x86_64/baseos/iso/).
|
||||
2. Install the Host.
|
||||
3. Run the following command as `root` (eg. in a post-installation script): <br/>
|
||||
`bash <(curl -q -k -L http://satint.psi.ch/pub/psi-rhel-8-registration.sh) -d "<division AIT,CPT,GFA or HPCE>" -n "<Network Zone PSIGEN, FEL or SLS>"`
|
||||
for example:<br/>
|
||||
`bash <(curl -q -k -L http://satint.psi.ch/pub/psi-rhel-8-registration.sh) -d "AIT" -n "PSIGEN"`
|
||||
4. The script will register the system and add it to the PSI RHEL-8 systems portfolio.
|
||||
5. An Ansible job run will be triggered, which will configure and finish the system.
|
||||
The iPXE menu is then generated according to `sysdb` and its default depends on the configuration, there, but you may override it manualy:
|
||||

|
||||
|
||||
<!--
|
||||
### Infrastructure as Code
|
||||

|
||||
|
||||

|
||||
|
||||
### Installation with Legacy BIOS
|
||||
Start the machine and select network boot (if not already the default), then you get following menu:
|
||||

|
||||
|
||||
There select "Red Hat Enterprise Linux 7 Network Install Menu" to get into the iPXE menu, where you can do also a lot of other stuff.
|
||||

|
||||
(I plan to get rid of above menu as it also breaks automatic installation by `sysdb` configuration).
|
||||
|
||||
The iPXE menu is then generated according to `sysdb` and its default depends on the configuration, there, but you may override it manualy:
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
1. Instantiate
|
||||
-->
|
||||
|
||||
BIN
rhel8/installation/grub_default.png
Normal file
|
After Width: | Height: | Size: 7.6 KiB |
BIN
rhel8/installation/grub_select.png
Normal file
|
After Width: | Height: | Size: 7.5 KiB |
BIN
rhel8/installation/ipxe_default.png
Normal file
|
After Width: | Height: | Size: 10 KiB |
BIN
rhel8/installation/ipxe_select_rhel8.png
Normal file
|
After Width: | Height: | Size: 2.2 KiB |
BIN
rhel8/installation/ipxe_select_test.png
Normal file
|
After Width: | Height: | Size: 13 KiB |
BIN
rhel8/installation/pxe_default.png
Normal file
|
After Width: | Height: | Size: 86 KiB |
BIN
rhel8/installation/pxe_select.png
Normal file
|
After Width: | Height: | Size: 79 KiB |