create basic system configuration subdirectory
This commit is contained in:
@@ -0,0 +1,73 @@
|
||||
# Configuration to Send/Relay Emails
|
||||
|
||||
## Sending Emails Via PSI Central Mail Gateway
|
||||
To be able to send emails, the server needs to be registered on the PSI mail gateways.
|
||||
|
||||
This can be done by this ServiceNow request:
|
||||
(Service Catalog > IT Systems & Data Storage > Register E-Mail Sender)
|
||||
|
||||
https://psi.service-now.com/psisp?id=psi_new_sc_cat_item&sys_id=68d60ca74f8833407f7660fe0310c7e3
|
||||
|
||||
The default PSI mail gateways for the different network segments are defined in the puppet common.yaml. Depending on the machines location a different default will take effect. The defaults are as follows:
|
||||
|
||||
```
|
||||
mta::relays:
|
||||
'default': 'smtpint.psi.ch'
|
||||
'dmz': 'smtpdmz.psi.ch'
|
||||
'extranet': 'smtpdmz.psi.ch'
|
||||
'tier3': 'smtpdmz.psi.ch'
|
||||
```
|
||||
|
||||
To enable the possibility to send emails from a machine to one of the standard gateways the flag `base::enable_mta` simply needs to be enabled. No other configuration is needed.
|
||||
|
||||
```yaml
|
||||
base::enable_mta: true
|
||||
```
|
||||
|
||||
The default name of the sending mail server is the hostname of the machine running postfix. To rename it use `mta::myhostname`.
|
||||
|
||||
```yaml
|
||||
mta::myhostname: 'foobar.psi.ch'
|
||||
```
|
||||
|
||||
## Sending Emails Via An Other SMTP Relay
|
||||
|
||||
If your machine is in the default network zone (i.e. PSI intranet) sending via a differnet mail gateway than the default can be done like this:
|
||||
|
||||
```yaml
|
||||
base::enable_mta: true
|
||||
mta::relays:
|
||||
'default': 'test-smtp-relay.psi.ch'
|
||||
```
|
||||
|
||||
Wether the email is accepted by the mail relay depends on the relays configuration. Contact the relay admin what the rules for his gateway are.
|
||||
|
||||
|
||||
## Configure Server as Mail Relay
|
||||
|
||||
The following configuration is needed if you want to setup a email relay server accepting emails from clients.
|
||||
Depending on the rule where your relay should forward messages, your server/relay must be registered/authorized on the relay it forwardes messages to. (e.g. PSI default mail relay, procedure see above)
|
||||
|
||||
```yaml
|
||||
base::enable_mta: true
|
||||
|
||||
# if you want to use an other forward relay than the PSI defaults
|
||||
# mta::relays:
|
||||
# 'default': 'test-smtp-relay.psi.ch'
|
||||
|
||||
# interfaces postfix should accept emails
|
||||
mta::inet_interfaces: # array[string] default: loopback-only
|
||||
# networks from which this relay should accept emails
|
||||
mta::mynetworks: # default: undefined
|
||||
```
|
||||
|
||||
Example (assumption the servers ip address is 10.1.2.110):
|
||||
```yaml
|
||||
mta::inet_interfaces:
|
||||
- '10.1.2.110'
|
||||
- 'localhost'
|
||||
# mta::mynetworks_style: 'subnet'
|
||||
mta::mynetworks:
|
||||
- '10.1.2.0/24'
|
||||
- '10.1.3.0/24'
|
||||
```
|
||||
@@ -0,0 +1,50 @@
|
||||
# Host Renaming
|
||||
|
||||
Following steps are required to rename a host.
|
||||
|
||||
|
||||
## Introduce New Hostname
|
||||
|
||||
### Sysdb/bob
|
||||
For sysdb create a new node with bob as usual.
|
||||
For reference do
|
||||
|
||||
```
|
||||
bob node list -v $OLD_FQDN
|
||||
```
|
||||
then add the new node
|
||||
```
|
||||
bob node add $NEW_FQDN $SYSDB_ENV
|
||||
bod node set-attr $NEW_FQDN [all attributes as listed above]
|
||||
```
|
||||
and the same for the MAC addresses:
|
||||
```
|
||||
for mac in $(bob node list-macs $OLD_FQDN); do echo bob node add-mac $NEW_FQDN $mac; done
|
||||
```
|
||||
|
||||
### Hiera
|
||||
|
||||
In Hiera ensure that a host specific configuration file exists for the FQDN with the same content as for the old hostname.
|
||||
|
||||
## Acutal Hostname Change
|
||||
|
||||
On the node as `root` run
|
||||
|
||||
```
|
||||
hostnamectl set-hostname $NEW_FQDN
|
||||
rm -rf /etc/puppetlabs/puppet/ssl
|
||||
puppet agent -t
|
||||
```
|
||||
|
||||
which changes the local hostname, removes the local Puppet certificate and updates the configuration with Puppet using the new hostname.
|
||||
|
||||
## Other Changes to Consider
|
||||
|
||||
- change DNS entry if a static IP address is assigned
|
||||
- redo SSL/TLS certificates with new hostname
|
||||
|
||||
## Remove Old Hostname
|
||||
|
||||
- `bob node delete $OLD_FQDN`
|
||||
- remove from Hiera
|
||||
- inform the Linux Team (linux-eng@psi.ch) so it can remove from Puppet server the certificate and other data and remove the computer object from the AD
|
||||
@@ -0,0 +1,277 @@
|
||||
# Network Configuration
|
||||
|
||||
Our Puppet configuration management supports five types of network configuration:
|
||||
- **auto**: NetworkManager does automatic configuration while respecting local user managed configuration
|
||||
- **auto_static_ip**: static NetworkManager connection with IP from DNS and network information from DHCP
|
||||
- **managed**: NetworkManger is fully managed via Hiera/Puppet
|
||||
- **unmanaged**: network configuration (incl. DNS) is not touched by Puppet
|
||||
- **legacy**: Puppet keeps network configuration untouched except for DNS configuration and applying `network::*` Hiera settings
|
||||
|
||||
Not all types are supported by all RedHat versions:
|
||||
|
||||
| Type | RHEL7 | RHEL8 | RHEL9 |
|
||||
|----------------|---------|---------|---------|
|
||||
| auto | \- | ✓ | Default |
|
||||
| auto_static_ip | \- | ✓ | ✓ |
|
||||
| managed | \- | ✓ | ✓ |
|
||||
| unmanaged | \- | ✓ | ✓ |
|
||||
| legacy | Default | Default | \- |
|
||||
|
||||
## Automatic Network Configuration
|
||||
|
||||
The automatic network configuration will just let NetworkManager do the work as it does it by default.
|
||||
|
||||
In Hiera you can select this option with
|
||||
|
||||
```
|
||||
networking::setup: auto
|
||||
```
|
||||
|
||||
And what does NetworkManager actually do by default? It attemps automatic configuration on all interfaces (DHCP, SLAAC). Additionally the user may add desired connections. This might be Wifi, VPN, but also normal Ethernet. Automatic configuration is only attempted if there is no such specific configuration.
|
||||
|
||||
DNS configuration as such is learned by autoconfiguration/manual connection configuration and will not be managed by Puppet.
|
||||
|
||||
Note that when changing to `auto` all legacy `ifcfg` files for network configuration are removed.
|
||||
|
||||
## Automatic Network Configuration with Static IP Address
|
||||
|
||||
In a setup where there is just one static IP address which can be resolved via DNS, Puppet can configure a static connection with
|
||||
|
||||
```
|
||||
networking::setup: auto_static_ip
|
||||
```
|
||||
|
||||
Note this only works if there is a DHCP server in that network which provides the network mask and the default gateway IP address.
|
||||
|
||||
## Managed Network Configuration
|
||||
|
||||
The network configuration can be fully and fine-grained be managed from Hiera with
|
||||
|
||||
```
|
||||
networking::setup: managed
|
||||
```
|
||||
|
||||
and the configuration for the individual connections:
|
||||
|
||||
```
|
||||
networking::connections:
|
||||
- psi_network
|
||||
- management_network
|
||||
|
||||
networking::connection::psi_network:
|
||||
interface_name: 'eno0'
|
||||
ipv4_method: 'manual'
|
||||
ipv4_address: '129.129.241.66/24'
|
||||
ipv4_gateway: '129.129.241.1'
|
||||
ipv6_method: 'disabled'
|
||||
|
||||
networking::connection::management_network:
|
||||
interface_name: 'eno1'
|
||||
ipv4_method: 'manual'
|
||||
ipv4_address: '192.168.71.10/24'
|
||||
ipv6_method: 'disabled'
|
||||
```
|
||||
|
||||
|
||||
So there is the list `networking::connections` which selects the network connections which should be configured.
|
||||
|
||||
Then for each connection name listed there needs to be a hash in Hiera named `networking::connection::$CONNECTION_NAME`.
|
||||
|
||||
If you have a fixed IP address which is in the DNS, you might also interpolate the `ipv4_by_dns` or the `ipv6_by_dns` variable:
|
||||
|
||||
```
|
||||
networking::connection::psi_network:
|
||||
mac_address: '00:50:56:9d:bb:ad'
|
||||
ipv4_method: 'manual'
|
||||
ipv4_address: '%{ipv4_by_dns}/24'
|
||||
ipv4_gateway: '129.129.187.1'
|
||||
ipv6_method: 'manual'
|
||||
ipv6_address: '%{ipv6_by_dns}'
|
||||
ipv6_gateway: 'abcd:1234::1'
|
||||
```
|
||||
|
||||
```{note}
|
||||
The default value (if not specified) for `ipv6_method` is _disabled_.
|
||||
```
|
||||
|
||||
### Ethernet Connection Definition
|
||||
|
||||
The default connection type is `ethernet` (alias for `802-3-ethernet`).
|
||||
The network connection hash needs to specify the NIC for the connection either by name with the key `interface_name` or by MAC address with the key `mac_address`.
|
||||
|
||||
Next you need to specify how IPv4 configuration should be done. The key `ipv4_method` supports the values `auto`, `dhcp`, `manual`, `disabled`, `link-local`. All except `manual` do not need further configuation. For `manual` the `ipv4_address` in the CIDR format "IP/network mask bits". For the default router has to be set with the key `ipv4_gateway`.
|
||||
|
||||
We did not look into IPv6 configuration yet and usualy it is best to switch it off by setting `ipv6_method` to `disabled`.
|
||||
|
||||
To keep an interface down the setting `state` can be set to `down` (default is `up`).
|
||||
|
||||
You may also add additional configuration like size of the ring buffer:
|
||||
```
|
||||
networking::connection::psi_network:
|
||||
...
|
||||
additional_config:
|
||||
ethtool:
|
||||
ring-rx: 8192
|
||||
ring-tx: 8192
|
||||
```
|
||||
The first key level is the section in the NetworkManager configuration file (on the command line usually the first part before the dot), the second key level is the name of the value to be set.
|
||||
|
||||
### Infiniband Connection Definition
|
||||
For infiniband connections the configuration is similar to ethernet. Additionally there is there is the `type: 'infiniband` setting accompanied by an `additional_config` key holding an `infiniband` key with the infinibad specific optioins, as you see in below example:
|
||||
|
||||
```
|
||||
networking::connection::ipoib_network:
|
||||
interface_name: 'ib0'
|
||||
ipv4_method: 'manual'
|
||||
ipv4_address: '192.168.1.16/24'
|
||||
ipv4_gateway: '192.168.1.1'
|
||||
ipv6_method: 'disabled'
|
||||
type: 'infiniband'
|
||||
additional_config:
|
||||
infiniband:
|
||||
mtu: 65520
|
||||
transport-mode: 'connected'
|
||||
```
|
||||
|
||||
### Other Connection Types
|
||||
|
||||
NetworkManager also supports other types like `wifi`, `vpn`, `bridge`, `vlan`, etc. Note that other types than `ethernet` and `ethernet` have so far not been tested. Please contact us if you managed to set up some other network type or need help to do so.
|
||||
|
||||
|
||||
### Interface Bonding
|
||||
For a bonded interfaces there is an own list named `networking::bondings` which defines which configuration defined in `networking::bonding::$NAME` hashes should be appled:
|
||||
|
||||
```
|
||||
networking::bondings:
|
||||
- bond0
|
||||
|
||||
networking::bonding::bond0:
|
||||
ipv4_method: 'manual'
|
||||
ipv4_address: '%{ipv4_by_dns}/24'
|
||||
ipv4_gateway: '129.129.86.1'
|
||||
ipv6_method: 'ignore'
|
||||
slaves:
|
||||
- 'eno5'
|
||||
- 'eno6'
|
||||
bond:
|
||||
mode: '802.3ad'
|
||||
xmit_hash_policy: 'layer2+3'
|
||||
miimon: '100'
|
||||
# optional
|
||||
additional_config:
|
||||
ethernet:
|
||||
mtu: 9000
|
||||
```
|
||||
Feel free to extend the documentation here or provide a link for detailed explanation of the bond options.
|
||||
|
||||
By default the connection name is automatically used name of the bonding interface, Still, you can use speaking names instead for the connection if you specifiy the interface name explicitely:
|
||||
|
||||
```
|
||||
networking::bondings:
|
||||
- psi_network
|
||||
|
||||
networking::bonding::psi_network:
|
||||
ifc_name: 'bond0'
|
||||
ipv4_method: 'manual'
|
||||
...
|
||||
```
|
||||
|
||||
### Static Routes
|
||||
|
||||
Static routes can be added with the `additional_config` key in the connection settings.
|
||||
Depending on the IP version there is a `ipv4` or `ipv6` subkey which then can contain many `routes` + number keys. So the first route is `routes1`, the second `routes2`, etc.
|
||||
The minimal entry for `routesX` is the network and then, separated with a comma, the next hop IP. The optional third entry is the metric.
|
||||
For each route you may also add a option key `routesX_options`, where multiple options in the form `name=value` can be added, again comma separated.
|
||||
|
||||
An example:
|
||||
|
||||
```
|
||||
networking::connection::management_network:
|
||||
interface_name: 'eno1'
|
||||
ipv4_method: 'manual'
|
||||
ipv4_address: '192.168.71.10/24'
|
||||
ipv6_method: 'disabled'
|
||||
additional_config:
|
||||
ipv4:
|
||||
routes1: '10.255.254.0/24,192.168.71.1'
|
||||
routes2: '10.255.255.0/24,192.168.71.1,100'
|
||||
routes2_options: 'lock-cwnd=false,lock-mtu=false'
|
||||
```
|
||||
|
||||
All routing options can be found in the Red Hat NetworkManager documentation ([RHEL8](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/configuring-static-routes_configuring-and-managing-networking#how-to-use-the-nmcli-command-to-configure-a-static-route_configuring-static-routes), [RHEL9](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/configuring_and_managing_networking/configuring-static-routes_configuring-and-managing-networking#how-to-use-the-nmcli-command-to-configure-a-static-route_configuring-static-routes)).
|
||||
|
||||
### Removing a Connection
|
||||
|
||||
A connection does **not get removed** when its configuration has been removed in Hiera and was applied on the node.
|
||||
|
||||
To remove it you may do it manually or reboot.
|
||||
|
||||
Manual removal is done with `nmcli connection down $ID/$CONNECTION_NAME`:
|
||||
```
|
||||
[root@lx-test-dmz-01 ~]# nmcli connection
|
||||
NAME UUID TYPE DEVICE
|
||||
dmz_network f77611ac-b6e2-5a08-841e-8a1023eefaed ethernet ens33
|
||||
ens35 f3ba4a81-8c9b-4aec-88ee-ddffd32f67fa ethernet ens35
|
||||
[root@lx-test-dmz-01 ~]# nmcli connection down f3ba4a81-8c9b-4aec-88ee-ddffd32f67fa
|
||||
Connection 'ens35' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/2)
|
||||
[root@lmu-user-dmz-01 ~]# nmcli connection
|
||||
NAME UUID TYPE DEVICE
|
||||
dmz_network f77611ac-b6e2-5a08-841e-8a1023eefaed ethernet ens33
|
||||
[root@lx-test-dmz-01 ~]#
|
||||
```
|
||||
|
||||
### DNS Override
|
||||
|
||||
The internal nameservers are configured according to the network zone by Puppet.
|
||||
|
||||
If for some reason that is unsuitable, you might set your own in Hiera:
|
||||
```
|
||||
networking::nameservers_override:
|
||||
- 192.33.120.5
|
||||
- 192.33.121.5
|
||||
```
|
||||
|
||||
### No Automatic Migration to Legacy Configuration
|
||||
|
||||
Note that when changing to `managed` all legacy `ifcfg` files and all NetworkManager connections not reflected in Hiera are removed. So if you want to be able to go back to legacy mode you need to backup these files first.
|
||||
|
||||
## Unmanaged Network Configuration
|
||||
|
||||
Here Puppet keeps the fingers off any network related configuration like interface configuration, DNS or routing.
|
||||
|
||||
In Hiera you can select this option with
|
||||
|
||||
```
|
||||
networking::setup: unmanaged
|
||||
```
|
||||
|
||||
When you change to unmanaged network configuration, the configuration on the node will stay as is.
|
||||
|
||||
## Legacy Network Configuration
|
||||
|
||||
The legacy mode Puppet does not do configuration of network addresses and interfaces. This usually is done by the Kickstart file during OS installation and then not touched any more. Or with manual changes.
|
||||
|
||||
Additionally the `network` Puppet module can be used for more complex setups. But as this module is not maintained any more, we phase it out with RHEL9 and suggest to migrate away from it on RHEL8.
|
||||
|
||||
The legacy mode is selected by not setting `networking::setup` in Hiera.
|
||||
|
||||
### Custom Nameservers
|
||||
|
||||
The internal nameservers are configured according to the network zone by Puppet.
|
||||
|
||||
If for some reason that is unsuitable, you might set your own in Hiera:
|
||||
|
||||
```
|
||||
networking::nameservers_override:
|
||||
- 192.33.120.5
|
||||
- 192.33.121.5
|
||||
```
|
||||
|
||||
## Disable DNS Caching
|
||||
|
||||
Except for the `unmanaged` setup mode you may disable DNS caching with
|
||||
|
||||
```
|
||||
networking::enable_dns_caching: false
|
||||
```
|
||||
|
||||
@@ -0,0 +1,9 @@
|
||||
# Custom NTP Servers
|
||||
|
||||
You can add other nameservers to your list by extending in the Hiera key `ntp_client::servers` the list of your network zone (most probably `default`):
|
||||
|
||||
```
|
||||
ntp_client::servers:
|
||||
'default':
|
||||
- '172.16.1.15'
|
||||
```
|
||||
@@ -0,0 +1,9 @@
|
||||
# NTP Server
|
||||
|
||||
Your node can serve as NTP server. To allow access you need to configure which networks/hosts are allowed to contact `chrony` in the Hiera list `ntp_server::allow`:
|
||||
|
||||
```
|
||||
ntp_server::allow:
|
||||
- '129.129.0.0/16'
|
||||
- '10.10.10.10'
|
||||
```
|
||||
@@ -0,0 +1,50 @@
|
||||
# Puppet Agent Configuration
|
||||
The Puppet Agent provides the basic system configuration as defined in Hiera.
|
||||
|
||||
## Automatic Puppet Agent Runs
|
||||
|
||||
By default the Puppet Agent runs daily somewhen between 5-8 AM.
|
||||
|
||||
The frequency can be changed in Hiera with the key `puppet_client::exec_frequency`.
|
||||
|
||||
Allowed parameters are
|
||||
- 'halfhourly': every 30 minutes
|
||||
- 'daily': once a day (default)
|
||||
- 'weekly': every Monday
|
||||
|
||||
The actual automatic Puppet Agent run is always on the same random time. Check `systemctl list-timers pli-puppet-run.timer` for the exact time on a specific node.
|
||||
|
||||
For `daily` and `weekly` the time window is configured in Hiera with `puppet_client::exec_time`, the default is:
|
||||
```
|
||||
puppet_client::exec_time: '05:00 -- 08:00'
|
||||
```
|
||||
The time format used is '24-hour clock' `HH:MM -- HH:MM`.
|
||||
|
||||
## Temporarily Disable Automatic Puppet Agent Runs
|
||||
Puppet execution can be disabled for a certain amount of time with the
|
||||
`/opt/pli/libexec/pli-puppet-disable` command:
|
||||
|
||||
```
|
||||
# /opt/pli/libexec/pli-puppet-disable
|
||||
puppet currently not disabled
|
||||
# /opt/pli/libexec/pli-puppet-disable '1 week'
|
||||
# /opt/pli/libexec/pli-puppet-disable
|
||||
Puppet disabled until: Wed Nov 1 08:00:05 CET 2017
|
||||
# /opt/pli/libexec/pli-puppet-disable stop
|
||||
Stopping
|
||||
# /opt/pli/libexec/pli-puppet-disable
|
||||
puppet currently not disabled
|
||||
#
|
||||
```
|
||||
The disabling time has to be in the ``date`` format (see date(1)).
|
||||
|
||||
## Manual Execution of Puppet Agent
|
||||
At any time you might update the node configuration by running the Puppet Agent manually. To do so run as user `root` the following command:
|
||||
```
|
||||
puppet agent -t
|
||||
```
|
||||
|
||||
If you just wish to see what it would change without doing the actual change on the system, run
|
||||
```
|
||||
puppet agent -t --noop
|
||||
```
|
||||
Reference in New Issue
Block a user