Controls/gitea-pages
0
2
Fork 0
Code Pull Requests Actions Activity

cleanup

Browse Source
This commit is contained in:
ebner
2024-08-07 15:45:56 +02:00
parent d3d708034e
commit db34f20822
7 changed files with 49 additions and 273 deletions
Download Patch File Download Diff File Expand all files Collapse all files
_toc.yml
+2 -7
View File
@@ -88,16 +88,11 @@ chapters:
- glob: admin-guide/puppet/profiles/*/*/*/*
- glob: admin-guide/puppet/components/*
- file: admin-guide/puppet/development
- file: admin-guide/selinux
- file: admin-guide/certificates
- file: admin-guide/accounts-and-groups
- file: admin-guide/active-directory
- file: admin-guide/selinux
- file: admin-guide/updates
- file: admin-guide/operations
sections:
- file: admin-guide/operations/certificates
- file: admin-guide/operations/deployment
- file: admin-guide/operations/ip-address-change
- file: admin-guide/operations/version-control
- file: admin-guide/troubleshooting
sections:
- file: admin-guide/troubleshooting/methods-and-tools
admin-guide/operations/certificates.md → admin-guide/certificates.md
+2 -2
View File
@@ -1,4 +1,4 @@
# Managing SSL certificates
# Managing HTTPS/SSL Certificates
We use DigiCert certificates.
@@ -8,7 +8,7 @@ We use DigiCert certificates.
First create a certificate signing request (CSR) like this, replacing the values for `FQDN`
and `ALIASES`
```
```bash
ALIASES=xyz.psi.ch
FQDN=xyz00.psi.ch
admin-guide/deployment.md
+45
View File
@@ -13,5 +13,50 @@ a command line client is available.
When PXE boot is not an option, e.g. in restricted networks, it is possible to
start iPXE from a USB stick or other media.
The general process for a deployment/installation is:
1. Register the system with sysdb (only for new systems).
2. Tell sysdb to perform an installation on the next boot.
3. Reboot the system and trigger a PXE boot (usually by pressing F12 during
POST).
The easiest way to interact with sysdb is to use `bob`, a command-line client, set up ready to use on `lxsup.psi.ch`.
Alternatively it is possible to use the web API directly.
First, add the new node:
```bash
bob node add $FQDN $ENV netboot
```
To be able to PXE boot we need to configure at least one MAC address for the new
node:
```bash
bob node add-mac $FQDN 00:50:56:aa:fe:9b
```
Finally we need to configure the installer to use, and the Puppet-related
parameters:
```bash
bob node set-attr $FQDN ipxe_installer=rhel8install
bob node set-attr $FQDN puppet_role=role::server
```
and optional:
```bash
bob node set-attr $FQDN puppet_group=cluster
bob node set-attr $FQDN puppet_subgroup=compute
bob node set-attr $FQDN network=static
bob node set-attr $FQDN puppet_env=prod
```
## Redeployment
After the initial installation the boot mode has been reset from netboot to local so it will then always boot from the local disk. For a redeployment the netboot needs to be set anew (on UEFI based systems netboot also needs to be always selected by the UEFI menu)):
```
bob node netboot $FQDN
```
```{tableofcontents}
```
admin-guide/operations.md
-7
View File
@@ -1,7 +0,0 @@
# Operations
Contents
```{tableofcontents}
```
admin-guide/operations/deployment.rst
-60
View File
@@ -1,60 +0,0 @@
Deployment
==========
This section describes how to (re-)deploy Puppet-managed Linux systems. The general process is:
1. Register the system with sysdb (only for new systems).
2. Tell sysdb to perform an installation on the next boot.
3. Reboot the system and trigger a PXE boot (usually by pressing F12 during
POST).
On some systems it is not possible to use PXE boot. Either because the network
card doesn't support it/has a bug/doesn't work with iPXE, or because the system
is in a network from which TFTP requests to the boot server are not allowed. In
those cases it is possible to either boot iPXE from a USB stick or DVD, or to
simply boot the RHEL installer from DVD and point it at the Kickstart file
generated by sysdb.
Registration with sysdb
~~~~~~~~~~~~~~~~~~~~~~~
The easiest way to interact with sysdb is to use `bob`, a command-line client, set up ready to use on `lxsup.psi.ch`.
Alternatively it is possible to use the web API directly.
First, add the new node::
bob node add $FQDN $ENV netboot
To be able to PXE boot we need to configure at least one MAC address for the new
node::
bob node add-mac $FQDN 00:50:56:aa:fe:9b
Finally we need to configure the installer to use, and the Puppet-related
parameters::
bob node set-attr $FQDN ipxe_installer=rhel8install
bob node set-attr $FQDN puppet_role=role::server
and optional::
bob node set-attr $FQDN puppet_group=cluster
bob node set-attr $FQDN puppet_subgroup=compute
bob node set-attr $FQDN network=static
bob node set-attr $FQDN puppet_env=prod
Redeployment
~~~~~~~~~~~~
After the initial installation the boot mode has been reset from netboot to local
so it will then always boot from the local disk. For a redeployment the netboot
needs to be set anew::
bob node netboot $FQDN
and after redo the PXE boot.
admin-guide/operations/ip-address-change.md
-112
View File
@@ -1,112 +0,0 @@
# IP Address Change
An IP address change needs following steps
**I stay in the same firewall zone**
- change IP address
- restart networking or reboot
**I move out to the DMZ**
- change IP address
- change nameservers (DNS)
- change timeservers (NTP)
- change mail relay (SMTP)
- restart all these services or reboot
One day when there is Puppet available in the DMZ then it will handle the later part.
## Networking Infrastructure
| Zone | Name Server (DNS) | Time Server (NTP) | Mail Relay (SMTP) |
|-----------|-------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
| default | `129.129.190.11` `129.129.230.11` | `pstime1.psi.ch` `pstime2.psi.ch` `pstime3.psi.ch` | `smtpint.psi.ch` |
| dmz/tier3 | `192.33.120.5` `192.33.121.5` | `dmztime1.psi.ch` `dmztime2.psi.ch` | `smtpdmz.psi.ch` |
| _source_ | [networking::nameservers](https://git.psi.ch/linux-infra/puppet/-/blob/preprod/data/common.yaml#L538) | [net_client::servers](https://git.psi.ch/linux-infra/puppet/-/blob/preprod/data/common.yaml#L595) | [mta::relays](https://git.psi.ch/linux-infra/puppet/-/blob/preprod/data/common.yaml#L527) |
## Select the Network Interface Device
To see what network interfaces are available, use
```
ip link show
```
(all RHEL versions)
or
```
nmcli device status
```
(starting from RHEL8)
## Edit the IP Configuration of a Network Interface
The configuration is done in the file `/etc/sysconfig/network-scripts/ifcfg-$DEVICE`.
An example configuration for a static IP address as set up by the kickstart file looks like:
```
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=none
IPADDR=129.129.187.41
PREFIX=24
GATEWAY=129.129.187.1
DNS1=129.129.190.11
DNS2=129.129.230.11
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=eui64
NAME=ens160
UUID=db60a82b-2a4c-4077-b4c1-5dd0e2476be1
DEVICE=ens160
ONBOOT=yes
```
Here you need to change the `IPADDR` and possibly the `GATEWAY` and rarely the `PREFIX`. The last two can be looked up in [QIP](https://qip.psi.ch/qip), but the usual pattern is `*.*.*.1` for the gateway and a prefix of 24.
When moving to a different zone, then you need also to adapt the DNS servers.
If you alterntively change to DHCP, then you can use this:
```
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=dhcp
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=eui64
NAME=ens160
UUID=b5e9cf25-056d-4acb-958c-7a443300e1e1
DEVICE=ens160
ONBOOT=yes
```
This will be active after boot or
```
systemctl restart NetworkManager
```
(RHEL8) or
```
systemctl restart network.service
```
(RHEL7)
Note if you are in need of a new UUID run `uuidgen`.
## Change Time Server (NTP)
Adapt in the file `/etc/chrony.conf` the `server` list and the `initstepslew` config with the respective time servers.
```
systemctl restart chronyd.service
```
applies the changes.
## Change Server for Outgoing Mails
This depends on the software running on the system.
admin-guide/operations/version-control.rst
-85
View File
@@ -1,85 +0,0 @@
Version Control
===============
Setting up Git
--------------
Initialize Git to use your username and PSI email address, for example::
git config --global user.name kaminski_k
git config --global user.email kai.kaminski@psi.ch
Gitlab server
-------------
We use the `PSI-internal Gitlab server <https://git.psi.ch>`_ to host our
repositories.
Groups
------
Currently, all of our repositories are in the repository group ``linux-infra``.
Setting up a repository
-----------------------
Repositories containing code are configured along the following lines:
1. Only fast-forward merges are allowed, no merge commits.
2. Merge requests require at least one approval (by someone other than the
requester).
Workflow
--------
Changes to repositories containing **only** documentation can simply be pushed
to the repository in question.
Changes to repositories containing code, SPEC files, or anything else that is
not pure documentation, need to be reviewed - even if the change in question
only changes documentation.
To implement a change, follow these steps:
1. Create an issue on GitLab.
2. Create a feature branch with name starting with
`issue-n-description`.
3. Assign the issue to yourself when you start working on it.
4. Commit the change to the feature branch and push it.
5. Create a merge request mentioning the issue in the commit message
or in the merge request (see `this
<http://doc.gitlab.com/ee/customization/issue_closing.html>`_ for
the syntax).
6. Wait for **someone else** to approve and apply the merge request.
Commit messages
~~~~~~~~~~~~~~~
A commit message follows the well-known `50/72 format
<http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html>`_: 50
characters for the first line of the commit message, followed by a blank line,
which is then followed by zero or more paragraphs with a maximal line-length of
72 characters.
If the commit fixes an issue recorded on Gitlab (which it should), the commit
message must start with ``Fix #N:``, where ``N`` is the number of the issue.
This will automatically close the issue when the commit is merged into master.
Code reviews
~~~~~~~~~~~~
During a code review be sure to check for at least the following:
1. adherence to the guidelines described in this document,e.g. PEP8-compliance
for Python code
2. solid implementation: edge cases and failures are considered and handled
appropriately, etc. Non-obvious bits are explained.
3. documentation has been written or changed as appropriate