From db34f20822e09617a7a1c6f8c76505a5df3fa9fa Mon Sep 17 00:00:00 2001 From: ebner Date: Wed, 7 Aug 2024 15:45:56 +0200 Subject: [PATCH] cleanup --- _toc.yml | 9 +- admin-guide/{operations => }/certificates.md | 4 +- admin-guide/deployment.md | 45 ++++++++ admin-guide/operations.md | 7 -- admin-guide/operations/deployment.rst | 60 ---------- admin-guide/operations/ip-address-change.md | 112 ------------------- admin-guide/operations/version-control.rst | 85 -------------- 7 files changed, 49 insertions(+), 273 deletions(-) rename admin-guide/{operations => }/certificates.md (97%) delete mode 100644 admin-guide/operations.md delete mode 100644 admin-guide/operations/deployment.rst delete mode 100644 admin-guide/operations/ip-address-change.md delete mode 100644 admin-guide/operations/version-control.rst diff --git a/_toc.yml b/_toc.yml index 7fd9016e..476bcac5 100644 --- a/_toc.yml +++ b/_toc.yml @@ -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 diff --git a/admin-guide/operations/certificates.md b/admin-guide/certificates.md similarity index 97% rename from admin-guide/operations/certificates.md rename to admin-guide/certificates.md index 8f283f32..747ce7bd 100644 --- a/admin-guide/operations/certificates.md +++ b/admin-guide/certificates.md @@ -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 diff --git a/admin-guide/deployment.md b/admin-guide/deployment.md index c33aa156..9745d0f4 100644 --- a/admin-guide/deployment.md +++ b/admin-guide/deployment.md @@ -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} ``` diff --git a/admin-guide/operations.md b/admin-guide/operations.md deleted file mode 100644 index d9a5ceb7..00000000 --- a/admin-guide/operations.md +++ /dev/null @@ -1,7 +0,0 @@ -# Operations - -Contents - -```{tableofcontents} -``` - diff --git a/admin-guide/operations/deployment.rst b/admin-guide/operations/deployment.rst deleted file mode 100644 index d0b6af8e..00000000 --- a/admin-guide/operations/deployment.rst +++ /dev/null @@ -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. diff --git a/admin-guide/operations/ip-address-change.md b/admin-guide/operations/ip-address-change.md deleted file mode 100644 index ab4875f1..00000000 --- a/admin-guide/operations/ip-address-change.md +++ /dev/null @@ -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. - - diff --git a/admin-guide/operations/version-control.rst b/admin-guide/operations/version-control.rst deleted file mode 100644 index a0eafb28..00000000 --- a/admin-guide/operations/version-control.rst +++ /dev/null @@ -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 `_ 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 - `_ 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 -`_: 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