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

cleanup test

Browse Source
This commit is contained in:
ebner
2024-08-08 10:54:06 +02:00
parent 328334d2ba
commit e468b218eb
3 changed files with 65 additions and 127 deletions
Download Patch File Download Diff File Expand all files Collapse all files
admin-guide/deployment/basic_installation.md
+47 -115
View File
@@ -1,132 +1,36 @@
# Installation
# Basic Installation
# Example Installation
Linux systems are installed using PXE and Kickstart. The Kickstart
configuration is auto-generated base on the configuration stored in sysdb/bob.
In this section we describe the deployment of a new server from
scratch.
All the operations will be performed using `bob`, the command-line
client for interacting with `sysdb`.
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 informations we need are:
The general process for a installation is:
- the server name: `logging-ra.psi.ch`
- the server MAC address: `23:3d:ef:33:11:22`
- optional static or dynamic IP: `static` (RHEL7 & RHEL8 only)
- the OS installer: `rhel8install`
- the server role: `role::logging_server`
- optional the server environment in puppet: `prod`
- the sysdb deployment environment: `daas`
- optional the group inside the sysdb environment (`default` if not specified): `logging`
- optional the subgroup inside the group: `collector`
1. Register and configure the system with sysdb
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)
## Setting up bob
The default way to interact with sysdb is to use [bob](https://git.psi.ch/linux-infra/bob). `bob` is already set up on `lxsup.psi.ch` for general use.
The `bob` tool is already set up on `lxsup.psi.ch`. You might connect with `ssh` and use it from there.
Altenatively you many have on your workstation a local copy of `bob`. This can be done by installing the RPM from the pli-misc repository - https://repos.psi.ch/rhel8/latest/pli-misc/
Altenatively you many have on your workstation a local copy of `bob`. This can be done by installing the RPM from the pli-misc repository - https://repos.psi.ch/rhel8/latest/pli-misc/ or by installing the Python package manually.
You might need to set a `PSI_BOB_USER` environment variable (`export PSI_BOB_USER=<you-name-it>`) or use the option `--user` if your local user is different from the one on sysdb.
## Sysdb configuration
## Sysdb Configuration
We add the node to the environment, specifing `netboot` as
the boot action
```bash
bob node add logging-ra.psi.ch daas netboot
```
We setup its MAC address:
```bash
bob node add-mac logging-ra.psi.ch 23:3d:ef:33:11:22
```
Next decide how the IP address is configured (`dhcp` or `static`):
```bash
bob node set-attr logging-ra.psi.ch network=static
```
And which installer is used:
```bash
bob node set-attr logging-ra.psi.ch ipxe_installer=rhel8install
```
And we finally setup the puppet role and puppet environment:
```bash
bob node set-attr logging-ra.psi.ch puppet_role=role::log_server
bob node set-attr logging-ra.psi.ch puppet_env=prod
bob node set-attr logging-ra.psi.ch puppet_group=logging
bob node set-attr logging-ra.psi.ch puppet_subgroup=collector
```
## Example
Full example:
```bash
bob node add lx-test-02.psi.ch lx netboot
bob node add-mac lx-test-02 00:50:56:9d:19:76
bob node set-attr lx-test-02.psi.ch ipxe_installer=rhel8install puppet_role=role::server
bob node netboot lx-test-02.psi.ch
bob node list -v lx-test-02
```
Ensure that a potential previous puppet certificate for this server is deleted on the puppet server: https://puppet.psi.ch
## Special Settings
### Custom Kernel Commandline Arguments
For custom kernel commandline arguments for the installer (e.g. to provide drivers) the sysdb attribute `kernel_cmdline` can be used:
```bash
bob node set-attr lx-test-02.psi.ch kernel_cmdline=inst.dd=https://linuxsoft.cern.ch/elrepo/dud/el8/x86_64/dd-megaraid_sas-07.725.01.00-1.el8_9.elrepo.iso
```
### Custom Partitioning
Please check out the [Partitioning page](partitioning).
Linux systems are generally deployed using PXE and Kickstart. We use iPXE, which
can retrieve its configuration via HTTP(S) and therefore gives us a lot of
flexibility, because the iPXE configuration can be generated on the fly with the
specific settings needed by the booting client. In the same way the Kickstart
configuration for the RHEL installer is auto-generated.
The information used for generating the iPXE and Kickstart configurations is
stored in the sysdb (see below). The sysdb is accessible through a web api, and
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:
Register 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:
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:
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
@@ -134,15 +38,43 @@ bob node set-attr $FQDN puppet_role=role::server
and optional:
```bash
# static IP address (options: static, dhcp)
bob node set-attr $FQDN network=static
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)):
```
Finally ensure that the node is set to `netboot`:
```bash
bob node netboot $FQDN
```
### Example
Minimal example:
```bash
bob node add lx-test-02.psi.ch lx netboot
bob node add-mac lx-test-02 00:50:56:9d:19:76
bob node set-attr lx-test-02.psi.ch ipxe_installer=rhel8install puppet_role=role::server
bob node netboot lx-test-02.psi.ch
# show the configuration
bob node list -v lx-test-02
```
### Special Settings
#### Custom Kernel Commandline Arguments
For custom kernel commandline arguments for the installer (e.g. to provide drivers) the sysdb attribute `kernel_cmdline` can be used:
```bash
bob node set-attr lx-test-02.psi.ch kernel_cmdline=inst.dd=https://linuxsoft.cern.ch/elrepo/dud/el8/x86_64/dd-megaraid_sas-07.725.01.00-1.el8_9.elrepo.iso
```
#### Custom Partitioning
Please check out the [Partitioning page](partitioning).
admin-guide/deployment/dmz.md
+7 -4
View File
@@ -1,6 +1,6 @@
# DMZ Deployment
The deployment in the DMZ ist the basically the same as [internaly](sample), but there are a few points to consider:
The deployment in the DMZ ist the basically the same as [internaly](basic_installation), but there are a few points to consider:
- a firewall rule for puppet is needed
- the commissioning can only be done in the special DMZ commissioning network
@@ -15,7 +15,8 @@ Because of this commissioning network we suggest that the DMZ VM gets for commis
- get both MAC addresses
- prepare the node in Sysdb/`bob` with the "back-door" MAC address
- in Hiera following network configuration is suggested which keeps the "front-door" interface disabled for the start:
```
```yaml
networking::setup: managed
networking::connections:
@@ -38,7 +39,8 @@ networking::connection::commissioning_network:
- for SSH access get assigned IP address from VMWare or Puppet facts or QIP
- at the moment puppet will fail, provide the IP address to your fellow friendly Core Linux Team member to manually finish the first boot
- if the configuration is fully ready, configure the "front-door" interface:
```
```yaml
networking::setup: managed
networking::connections:
@@ -62,7 +64,8 @@ networking::connection::commissioning_network:
- check if you still have management access (`ssh`) over the front door interface
- remove the configuration of the "back-door" interface:
```
```yaml
networking::setup: managed
networking::connections:
admin-guide/deployment/reinstall.md
+11 -8
View File
@@ -1,15 +1,18 @@
# How to reinstall a machine
# Reinstallation
Generally speaking, a reinstall can be done without doing anything other than doing the PXE boot, but there are some caveats to consider:
- the puppet server certificate is saved on the puppet server
- the puppet client certificate is saved by the kickstart script (which obviously can only happen, if the machine is reinstalled to the same drive with an intact file-system)
Basically a reinstall can be done without doing anything other than doing the PXE boot, but there are some caveats to consider:
- if you do a new install to a blank drive, but the puppet server has a certificate saved for the host, the client will generate a new cert, but the server will not, so the certificates saved on the 2 sides, will not match and will never work. In this case both sides need to be cleaned up before a new puppet run is attempted.
__Netboot__
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))
```bash
bob node netboot $FQDN
```
- somewhat unrelated to the other points, but a similar case is the ssh server keys, which are stored on the puppet server and are put in place by puppet agent, so they remain unchanged under all reinstall scenarios
__Puppet Certificates__
The puppet client certificate is saved on the puppet server. By default corresponding certificate on the client is tried to be saved by the kickstart script. If you do a new install to a blank drive, but the puppet server has a certificate saved for the host, the client will generate a new cert, but the server will not, so the certificates saved on the 2 sides, will not match and will never work. In this case both sides need to be cleaned up before a new puppet run is attempted.
Puppet server certs can be deleted at https://puppet01.psi.ch/ and on that page, the command to delete the client cert is specified.
Puppet client certs can be deleted at https://puppet.psi.ch/ and on that page, the command to delete the client cert is specified.
To access https://puppet01.psi.ch one needs to authenticate with your username/password. The server uses a invalid https certificate that is not accepted by modern safari/chrome any more. Use Firefox as a workaround.
To access https://puppet.psi.ch one needs to authenticate with your username/password. The server uses a invalid https certificate that is not accepted by modern safari/chrome any more. Use Firefox as a workaround.