mirror of
https://github.com/linux-system-roles/network.git
synced 2026-01-23 02:15:17 +00:00
Unify Markdown syntax
- Use a consistent style for lists and fix indentations - Adjust whitespace to fence lists or code blocks - Remove double blank lines - Wrap lines at 88 characters - Add missing notations for code - Use proper links instead of plain URLs - Reword some parts to fit the style and update the text Signed-off-by: Till Maas <opensource@till.name>
This commit is contained in:
Till Maas
parent
a3ccd5561e
commit
ffa98f4876
3 changed files with 307 additions and 270 deletions
16
CHANGELOG.md
16
CHANGELOG.md
|
|
@ -1,18 +1,28 @@
|
|||
# Changelog
|
||||
## [1.2.0] - 2020-08-26
|
||||
Changelog
|
||||
=========
|
||||
|
||||
[1.2.0] - 2020-08-26
|
||||
--------------------
|
||||
|
||||
### Changes
|
||||
|
||||
- Rename ethtool features to use underscores instead of dashes to support
|
||||
Jinja2 dot notation. Accept old notation for compatibility with existing
|
||||
playbooks.
|
||||
|
||||
### New features
|
||||
|
||||
- Initial 802.1x authentication support (only EAP-TLS)
|
||||
- Wireless support
|
||||
- Handle OracleLinux as a RHEL clone
|
||||
- Remove dependency on ethtool command line tool
|
||||
- initscripts: Support creating and activating bond profiles in one run
|
||||
- Ignore up/down states if a profile is not defined and not present on the managed host
|
||||
- Ignore up/down states if a profile is not defined and not present on the
|
||||
managed host
|
||||
- Document bond profiles
|
||||
|
||||
### Bug fixes
|
||||
|
||||
- NetworkManager: Always rollback checkpoint on failure
|
||||
- NetworkManager: Try to reapply changes to reduce network interruptions
|
||||
- initscripts: Fix dependencies for Fedora 32
|
||||
|
|
|
|||
306
README.md
306
README.md
|
|
@ -1,5 +1,6 @@
|
|||
linux-system-roles/network
|
||||
==========================
|
||||
|
||||
[](https://coveralls.io/github/linux-system-roles/network)
|
||||
|
||||
[](https://github.com/ambv/black)
|
||||
|
|
@ -23,6 +24,7 @@ This role can be used to configure:
|
|||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
The `network` role supports two providers: `nm` and `initscripts`. `nm` is
|
||||
used by default in RHEL7 and `initscripts` in RHEL6. These providers can be
|
||||
configured per host via the [`network_provider`](#provider) variable. In
|
||||
|
|
@ -35,19 +37,20 @@ For `initscripts`, the legacy network service is required as used in Fedora or R
|
|||
For each host a list of networking profiles can be configured via the
|
||||
`network_connections` variable.
|
||||
|
||||
- For `initscripts`, profiles correspond to ifcfg files in the `/etc/sysconfig/network-scripts/ifcfg-*` directory.
|
||||
- For `initscripts`, profiles correspond to ifcfg files in the
|
||||
`/etc/sysconfig/network-scripts/ifcfg-*` directory.
|
||||
|
||||
- For `NetworkManager`, profiles correspond to connection profiles as handled by
|
||||
NetworkManager. Fedora and RHEL use the `ifcfg-rh-plugin` for NetworkManager,
|
||||
which also writes or reads configuration files to `/etc/sysconfig/network-scripts/ifcfg-*`
|
||||
for compatibility.
|
||||
|
||||
Note that the `network` role primarily operates on networking profiles (connections) and
|
||||
not on devices, but it uses the profile name by default as the interface name.
|
||||
It is also possible to create generic profiles, by creating for example a
|
||||
profile with a certain IP configuration without activating the profile. To
|
||||
apply the configuration to the actual networking interface, use the `nmcli`
|
||||
commands on the target system.
|
||||
Note that the `network` role primarily operates on networking profiles
|
||||
(connections) and not on devices, but it uses the profile name by default as
|
||||
the interface name. It is also possible to create generic profiles, by creating
|
||||
for example a profile with a certain IP configuration without activating the
|
||||
profile. To apply the configuration to the actual networking interface, use the
|
||||
`nmcli` commands on the target system.
|
||||
|
||||
**Warning**: The `network` role updates or creates all connection profiles on
|
||||
the target system as specified in the `network_connections` variable. Therefore,
|
||||
|
|
@ -57,21 +60,25 @@ Exceptions are mentioned below.
|
|||
|
||||
Variables
|
||||
---------
|
||||
The `network` role is configured via variables starting with `network_` as the name prefix.
|
||||
List of variables:
|
||||
|
||||
* `network_provider` - The `network_provider` variable allows to set a specific provider
|
||||
(`nm` or `initscripts`) . Setting it to `{{ network_provider_os_default }}`, the
|
||||
provider is set depending on the operating system. This is usually `nm` except for
|
||||
RHEL 6 or CentOS 6 systems. Changing the provider for an existing profile is not
|
||||
supported. To switch providers, it is recommended to first remove profiles with the
|
||||
old provider and then create new profiles with the new provider.
|
||||
* `network_connections` - The connection profiles are configured as `network_connections`,
|
||||
which is a list of dictionaries that include specific options.
|
||||
* `network_allow_restart` - Certain configurations require the role to restart network services.
|
||||
For example, if a wireless connection is configured and NetworkManager-wifi is not installed,
|
||||
NetworkManager must be restarted prior to the connection being configured. Setting this to
|
||||
`no` will prevent the role from restarting network service.
|
||||
The `network` role is configured via variables starting with `network_` as
|
||||
the name prefix. List of variables:
|
||||
|
||||
- `network_provider` - The `network_provider` variable allows to set a specific
|
||||
provider (`nm` or `initscripts`) . Setting it to `{{
|
||||
network_provider_os_default }}`, the provider is set depending on the
|
||||
operating system. This is usually `nm` except for RHEL 6 or CentOS 6 systems.
|
||||
Changing the provider for an existing profile is not supported. To switch
|
||||
providers, it is recommended to first remove profiles with the old provider
|
||||
and then create new profiles with the new provider.
|
||||
- `network_connections` - The connection profiles are configured as
|
||||
`network_connections`, which is a list of dictionaries that include specific
|
||||
options.
|
||||
- `network_allow_restart` - Certain configurations require the role to restart
|
||||
network services. For example, if a wireless connection is configured and
|
||||
NetworkManager-wifi is not installed, NetworkManager must be restarted prior
|
||||
to the connection being configured. Setting this to `no` will prevent the
|
||||
role from restarting network service.
|
||||
|
||||
Examples of Variables
|
||||
---------------------
|
||||
|
|
@ -88,8 +95,9 @@ network_allow_restart: yes
|
|||
|
||||
Options
|
||||
-------
|
||||
The `network_connections` variable is a list of dictionaries that include the following options.
|
||||
List of options:
|
||||
|
||||
The `network_connections` variable is a list of dictionaries that include the
|
||||
following options. List of options:
|
||||
|
||||
### `name` (required)
|
||||
|
||||
|
|
@ -100,38 +108,42 @@ Note that you can have multiple profiles for the same device, but only
|
|||
one profile can be active on the device each time.
|
||||
For NetworkManager, a connection can only be active at one device each time.
|
||||
|
||||
* For `NetworkManager`, the `name` option corresponds to the
|
||||
- For `NetworkManager`, the `name` option corresponds to the
|
||||
[`connection.id`](https://developer.gnome.org/NetworkManager/stable/nm-settings.html#nm-settings.property.connection.id)
|
||||
property option.
|
||||
Although NetworkManager supports multiple connections with the same `connection.id`,
|
||||
the `network` role cannot handle a duplicate `name`. Specifying a `name` multiple
|
||||
times refers to the same connection profile.
|
||||
|
||||
* For `initscripts`, the `name` option determines the ifcfg file name `/etc/sysconfig/network-scripts/ifcfg-$NAME`.
|
||||
- For `initscripts`, the `name` option determines the ifcfg file name `/etc/sysconfig/network-scripts/ifcfg-$NAME`.
|
||||
Note that the `name` does not specify the `DEVICE` but a filename. As a consequence,
|
||||
`'/'` is not a valid character for the `name`.
|
||||
|
||||
You can also use the same connection profile multiple times. Therefore, it is possible to create a profile and activate it separately.
|
||||
You can also use the same connection profile multiple times. Therefore, it is possible
|
||||
to create a profile and activate it separately.
|
||||
|
||||
### `state`
|
||||
|
||||
The `state` option identifies what is the runtime state of each connection profile. The `state` option (optional) can be set to the following values:
|
||||
The `state` option identifies what is the runtime state of each connection profile. The
|
||||
`state` option (optional) can be set to the following values:
|
||||
|
||||
* `up` - the connection profile is activated
|
||||
* `down` - the connection profile is deactivated
|
||||
- `up` - the connection profile is activated
|
||||
- `down` - the connection profile is deactivated
|
||||
|
||||
#### `state: up`
|
||||
|
||||
- For `NetworkManager`, this corresponds to `nmcli connection id {{name}} up`.
|
||||
|
||||
- For `initscripts`, this corresponds to `ifup {{name}}`.
|
||||
|
||||
When the `state` option is set to `up`, you can also specify the `wait` option (optional):
|
||||
|
||||
* `wait: 0` - initiates only the activation, but does not wait until the device is fully connected.
|
||||
The connection will be completed in the background, for example after a DHCP lease was received.
|
||||
* `wait: <seconds>` is a timeout that enables you to decide how long you give the device to
|
||||
activate. The default is using a suitable timeout. Note that the `wait` option is
|
||||
only supported by NetworkManager.
|
||||
- `wait: 0` - initiates only the activation, but does not wait until the device is fully
|
||||
connected. The connection will be completed in the background, for example after a
|
||||
DHCP lease was received.
|
||||
- `wait: <seconds>` is a timeout that enables you to decide how long you give the device
|
||||
to activate. The default is using a suitable timeout. Note that the `wait` option is
|
||||
only supported by NetworkManager.
|
||||
|
||||
Note that `state: up` always re-activates the profile and possibly changes the
|
||||
networking configuration, even if the profile was already active before. As
|
||||
|
|
@ -143,14 +155,16 @@ a consequence, `state: up` always changes the system.
|
|||
|
||||
- For `initscripts`, it corresponds to call `ifdown {{name}}`.
|
||||
|
||||
You can deactivate a connection profile, even if is currently not active. As a consequence, `state: down` always changes the system.
|
||||
|
||||
Note that if the `state` option is unset, the connection profile’s runtime state will not be changed.
|
||||
You can deactivate a connection profile, even if is currently not active. As a
|
||||
consequence, `state: down` always changes the system.
|
||||
|
||||
Note that if the `state` option is unset, the connection profile’s runtime state will
|
||||
not be changed.
|
||||
|
||||
### `persistent_state`
|
||||
|
||||
The `persistent_state` option identifies if a connection profile is persistent (saved on disk). The `persistent_state` option can be set to the following values:
|
||||
The `persistent_state` option identifies if a connection profile is persistent (saved on
|
||||
disk). The `persistent_state` option can be set to the following values:
|
||||
|
||||
#### `persistent_state: present` (default)
|
||||
|
||||
|
|
@ -169,30 +183,31 @@ profile on a currently disconnected device. ([rh#1401515](https://bugzilla.redha
|
|||
The `absent` value ensures that the profile is not present on the
|
||||
target host. If a profile with the given `name` exists, it will be deleted. In this case:
|
||||
|
||||
- `NetworkManager` deletes all connection profiles with the corresponding `connection.id`.
|
||||
Deleting a profile usually does not change the current networking configuration, unless
|
||||
the profile was currently activated on a device. Deleting the currently
|
||||
active connection profile disconnects the device. That makes the device eligible
|
||||
to autoconnect another connection (for more details, see [rh#1401515](https://bugzilla.redhat.com/show_bug.cgi?id=1401515)).
|
||||
- `NetworkManager` deletes all connection profiles with the corresponding
|
||||
`connection.id`. Deleting a profile usually does not change the current networking
|
||||
configuration, unless the profile was currently activated on a device. Deleting the
|
||||
currently active connection profile disconnects the device. That makes the device
|
||||
eligible to autoconnect another connection (for more details, see
|
||||
[rh#1401515](https://bugzilla.redhat.com/show_bug.cgi?id=1401515)).
|
||||
|
||||
- `initscripts` deletes the ifcfg file in most cases with no impact on the runtime state of the system unless some component is watching the sysconfig directory.
|
||||
- `initscripts` deletes the ifcfg file in most cases with no impact on the runtime state
|
||||
of the system unless some component is watching the sysconfig directory.
|
||||
|
||||
**Note**: For profiles that only contain a `state` option, the `network` role only activates
|
||||
or deactivates the connection without changing its configuration.
|
||||
|
||||
|
||||
### `type`
|
||||
|
||||
The `type` option can be set to the following values:
|
||||
|
||||
- `ethernet`
|
||||
- `bridge`
|
||||
- `bond`
|
||||
- `team`
|
||||
- `vlan`
|
||||
- `macvlan`
|
||||
- `infiniband`
|
||||
- `wireless`
|
||||
- `ethernet`
|
||||
- `bridge`
|
||||
- `bond`
|
||||
- `team`
|
||||
- `vlan`
|
||||
- `macvlan`
|
||||
- `infiniband`
|
||||
- `wireless`
|
||||
|
||||
#### `type: ethernet`
|
||||
|
||||
|
|
@ -200,17 +215,20 @@ If the type is `ethernet`, then there can be an extra `ethernet` dictionary with
|
|||
items (options): `autoneg`, `speed` and `duplex`, which correspond to the
|
||||
settings of the `ethtool` utility with the same name.
|
||||
|
||||
* `autoneg`: `yes` (default) or `no` [if auto-negotiation is enabled or disabled]
|
||||
* `speed`: speed in Mbit/s
|
||||
* `duplex`: `half` or `full`
|
||||
- `autoneg`: `yes` (default) or `no` [if auto-negotiation is enabled or disabled]
|
||||
- `speed`: speed in Mbit/s
|
||||
- `duplex`: `half` or `full`
|
||||
|
||||
Note that the `speed` and `duplex` link settings are required when autonegotiation is disabled (autoneg:no).
|
||||
Note that the `speed` and `duplex` link settings are required when autonegotiation is
|
||||
disabled (`autoneg: no`).
|
||||
|
||||
#### `type: bridge`, `type: bond`, `type: team`
|
||||
|
||||
The `bridge`, `bond`, `team` device types work similar. Note that `team` is not supported in RHEL6 kernels.
|
||||
The `bridge`, `bond`, `team` device types work similar. Note that `team` is not
|
||||
supported in RHEL6 kernels.
|
||||
|
||||
For ports, the `port_type` and `controller` properties must be set. Note that ports should not have `ip` settings.
|
||||
For ports, the `port_type` and `controller` properties must be set. Note that ports
|
||||
should not have `ip` settings.
|
||||
|
||||
The `controller` refers to the `name` of a profile in the Ansible
|
||||
playbook. It is neither an interface-name nor a connection-id of
|
||||
|
|
@ -224,11 +242,13 @@ NetworkManager.
|
|||
|
||||
As `controller` refers to other profiles of the same or another play, the order of the
|
||||
`connections` list matters. Profiles that are referenced by other profiles need to be
|
||||
specified first. Also, `--check` ignores the value of the `controller` and assumes it will
|
||||
be present during a real run. That means, in presence of an invalid `controller`, `--check`
|
||||
may signal success but the actual play run fails.
|
||||
specified first. Also, `--check` ignores the value of the `controller` and assumes it
|
||||
will be present during a real run. That means, in presence of an invalid `controller`,
|
||||
`--check` may signal success but the actual play run fails.
|
||||
|
||||
The `team` type uses `roundrobin` as the `runner` configuration. No further
|
||||
configuration is supported at the moment.
|
||||
|
||||
The `team` type uses `roundrobin` as the `runner` configuration. No further configuration is supported at the moment.
|
||||
#### `type: vlan`
|
||||
|
||||
Similar to `controller`, the `parent` references the connection profile in the ansible
|
||||
|
|
@ -236,22 +256,24 @@ role.
|
|||
|
||||
#### `type: macvlan`
|
||||
|
||||
Similar to `controller` and `vlan`, the `parent` references the connection profile in the ansible
|
||||
role.
|
||||
Similar to `controller` and `vlan`, the `parent` references the connection profile in
|
||||
the ansible role.
|
||||
|
||||
#### `type: wireless`
|
||||
|
||||
The `wireless` type supports WPA-PSK (password) authentication and WPA-EAP (802.1x) authentication.
|
||||
The `wireless` type supports WPA-PSK (password) authentication and WPA-EAP (802.1x)
|
||||
authentication.
|
||||
|
||||
`nm` (NetworkManager) is the only supported `network_provider` for this type.
|
||||
|
||||
If WPA-EAP is used, ieee802_1x settings must be defined in the [ieee802_1x](#-`ieee802_1x`) option.
|
||||
If WPA-EAP is used, ieee802_1x settings must be defined in the
|
||||
[ieee802_1x](#-`ieee802_1x`) option.
|
||||
|
||||
The following options are supported:
|
||||
|
||||
* `ssid`: the SSID of the wireless network (required)
|
||||
* `key_mgmt`: `wpa-psk` or `wpa-eap` (required)
|
||||
* `password`: password for the network (required if `wpa-psk` is used)
|
||||
- `ssid`: the SSID of the wireless network (required)
|
||||
- `key_mgmt`: `wpa-psk` or `wpa-eap` (required)
|
||||
- `password`: password for the network (required if `wpa-psk` is used)
|
||||
|
||||
### `autoconnect`
|
||||
|
||||
|
|
@ -280,11 +302,10 @@ maximum value of the `mtu` option depends on the underlying device.
|
|||
|
||||
### `interface_name`
|
||||
|
||||
For the `ethernet` and `infiniband` types, the `interface_name` option restricts the profile to
|
||||
the given interface by name. This argument is optional and by default the
|
||||
profile name is used unless a mac address is specified using the `mac` key.
|
||||
Specifying an empty string (`""`) means that the profile is not
|
||||
restricted to a network interface.
|
||||
For the `ethernet` and `infiniband` types, the `interface_name` option restricts the
|
||||
profile to the given interface by name. This argument is optional and by default the
|
||||
profile name is used unless a mac address is specified using the `mac` key. Specifying
|
||||
an empty string (`""`) means that the profile is not restricted to a network interface.
|
||||
|
||||
**Note:** With [persistent interface naming](https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html),
|
||||
the interface is predictable based on the hardware configuration.
|
||||
|
|
@ -302,16 +323,15 @@ The `zone` option sets the firewalld zone for the interface.
|
|||
|
||||
Ports to the bridge, bond or team devices cannot specify a zone.
|
||||
|
||||
|
||||
### `ip`
|
||||
|
||||
The IP configuration supports the following options:
|
||||
|
||||
* `address`
|
||||
- `address`
|
||||
|
||||
Manual addressing can be specified via a list of addresses under the `address` option.
|
||||
|
||||
* `dhcp4`, `auto6`, and `ipv6_disabled`
|
||||
- `dhcp4`, `auto6`, and `ipv6_disabled`
|
||||
|
||||
Also, manual addressing can be specified by setting either `dhcp4` or `auto6`.
|
||||
The `dhcp4` key is for DHCPv4 and `auto6` for StateLess Address Auto Configuration
|
||||
|
|
@ -319,7 +339,7 @@ The IP configuration supports the following options:
|
|||
depends on the presence of manual addresses. `ipv6_disabled` can be set to disable
|
||||
ipv6 for the connection.
|
||||
|
||||
* `dhcp4_send_hostname`
|
||||
- `dhcp4_send_hostname`
|
||||
|
||||
If `dhcp4` is enabled, it can be configured whether the DHCPv4 request includes
|
||||
the hostname via the `dhcp4_send_hostname` option. Note that `dhcp4_send_hostname`
|
||||
|
|
@ -327,17 +347,17 @@ The IP configuration supports the following options:
|
|||
[`ipv4.dhcp-send-hostname`](https://developer.gnome.org/NetworkManager/stable/nm-settings.html#nm-settings.property.ipv4.dhcp-send-hostname)
|
||||
property.
|
||||
|
||||
* `dns`
|
||||
- `dns`
|
||||
|
||||
Manual DNS configuration can be specified via a list of addresses given in the
|
||||
`dns` option.
|
||||
|
||||
* `dns_search`
|
||||
- `dns_search`
|
||||
|
||||
`dns_search` is only supported for IPv4 nameservers. Manual DNS configuration can
|
||||
be specified via a list of domains to search given in the `dns_search` option.
|
||||
|
||||
* `dns_options`
|
||||
- `dns_options`
|
||||
|
||||
`dns_options` is only supported for the NetworkManager provider and IPv4
|
||||
nameservers. Manual DNS configuration via a list of DNS options can be given in the
|
||||
|
|
@ -358,43 +378,47 @@ The IP configuration supports the following options:
|
|||
- `trust-ad`
|
||||
- `use-vc`
|
||||
|
||||
**Note:** The "trust-ad" setting is only honored if the profile contributes name
|
||||
**Note:** The "trust-ad" setting is only honored if the profile contributes name
|
||||
servers to resolv.conf, and if all contributing profiles have "trust-ad" enabled.
|
||||
When using a caching DNS plugin (dnsmasq or systemd-resolved in NetworkManager.conf)
|
||||
then "edns0" and "trust-ad" are automatically added.
|
||||
|
||||
- `route_metric4` and `route_metric6`
|
||||
|
||||
* `route_metric4` and `route_metric6`
|
||||
|
||||
- For `NetworkManager`, `route_metric4` and `route_metric6` corresponds to the
|
||||
[`ipv4.route-metric`](https://developer.gnome.org/NetworkManager/stable/nm-settings.html#nm-settings.property.ipv4.route-metric) and
|
||||
For `NetworkManager`, `route_metric4` and `route_metric6` corresponds to the
|
||||
[`ipv4.route-metric`](https://developer.gnome.org/NetworkManager/stable/nm-settings.html#nm-settings.property.ipv4.route-metric)
|
||||
and
|
||||
[`ipv6.route-metric`](https://developer.gnome.org/NetworkManager/stable/nm-settings.html#nm-settings.property.ipv6.route-metric)
|
||||
properties, respectively. If specified, it determines the route metric for DHCP
|
||||
assigned routes and the default route, and thus the priority for multiple interfaces.
|
||||
assigned routes and the default route, and thus the priority for multiple
|
||||
interfaces.
|
||||
|
||||
* `route`
|
||||
- `route`
|
||||
|
||||
Static route configuration can be specified via a list of routes given in the `route`
|
||||
option. The default value is an empty list. Each route is a dictionary with the following
|
||||
entries: `network`, `prefix`, `gateway` and `metric`. `network` and `prefix` specify
|
||||
the destination network.
|
||||
Note that Classless inter-domain routing (CIDR) notation or network mask notation are not supported yet.
|
||||
Static route configuration can be specified via a list of routes given in the
|
||||
`route` option. The default value is an empty list. Each route is a dictionary with
|
||||
the following entries: `network`, `prefix`, `gateway` and `metric`. `network` and
|
||||
`prefix` specify the destination network.
|
||||
Note that Classless inter-domain routing (CIDR) notation or network mask notation
|
||||
are not supported yet.
|
||||
|
||||
* `route_append_only`
|
||||
- `route_append_only`
|
||||
|
||||
The `route_append_only` option allows only to add new routes to the
|
||||
existing routes on the system.
|
||||
|
||||
If the `route_append_only` boolean option is set to `yes`, the specified routes are appended to the existing routes.
|
||||
If `route_append_only` is set to `no` (default), the current routes are replaced.
|
||||
Note that setting `route_append_only` to `yes` without setting `route` has the effect of preserving the current static routes.
|
||||
If the `route_append_only` boolean option is set to `yes`, the specified routes are
|
||||
appended to the existing routes. If `route_append_only` is set to `no` (default),
|
||||
the current routes are replaced. Note that setting `route_append_only` to `yes`
|
||||
without setting `route` has the effect of preserving the current static routes.
|
||||
|
||||
* `rule_append_only`
|
||||
- `rule_append_only`
|
||||
|
||||
The `rule_append_only` boolean option allows to preserve the current routing rules.
|
||||
Note that specifying routing rules is not supported yet.
|
||||
|
||||
**Note:** When `route_append_only` or `rule_append_only` is not specified, the `network` role deletes the current routes or routing rules.
|
||||
**Note:** When `route_append_only` or `rule_append_only` is not specified, the network
|
||||
role deletes the current routes or routing rules.
|
||||
|
||||
**Note:** Ports to the bridge, bond or team devices cannot specify `ip` settings.
|
||||
|
||||
|
|
@ -488,29 +512,31 @@ kernel and device, changing some options might not be supported.
|
|||
|
||||
Configures 802.1x authentication for an interface.
|
||||
|
||||
Currently, NetworkManager is the only supported provider and EAP-TLS is the only supported EAP method.
|
||||
Currently, NetworkManager is the only supported provider and EAP-TLS is the only
|
||||
supported EAP method.
|
||||
|
||||
SSL certificates and keys must be deployed on the host prior to running the role.
|
||||
|
||||
* `eap`
|
||||
- `eap`
|
||||
|
||||
The allowed EAP method to be used when authenticating to the network with 802.1x.
|
||||
|
||||
Currently, `tls` is the default and the only accepted value.
|
||||
|
||||
* `identity` (required)
|
||||
- `identity` (required)
|
||||
|
||||
Identity string for EAP authentication methods.
|
||||
|
||||
* `private_key` (required)
|
||||
- `private_key` (required)
|
||||
|
||||
Absolute path to the client's PEM or PKCS#12 encoded private key used for 802.1x authentication.
|
||||
Absolute path to the client's PEM or PKCS#12 encoded private key used for 802.1x
|
||||
authentication.
|
||||
|
||||
* `private_key_password`
|
||||
- `private_key_password`
|
||||
|
||||
Password to the private key specified in `private_key`.
|
||||
|
||||
* `private_key_password_flags`
|
||||
- `private_key_password_flags`
|
||||
|
||||
List of flags to configure how the private key password is managed.
|
||||
|
||||
|
|
@ -522,43 +548,48 @@ SSL certificates and keys must be deployed on the host prior to running the role
|
|||
- `not-saved`
|
||||
- `not-required`
|
||||
|
||||
See NetworkManager documentation on "Secret flag types" more details (`man 5 nm-settings`).
|
||||
See NetworkManager documentation on "Secret flag types" more details (`man 5
|
||||
nm-settings`).
|
||||
|
||||
* `client_cert` (required)
|
||||
- `client_cert` (required)
|
||||
|
||||
Absolute path to the client's PEM encoded certificate used for 802.1x authentication.
|
||||
Absolute path to the client's PEM encoded certificate used for 802.1x
|
||||
authentication.
|
||||
|
||||
* `ca_cert`
|
||||
- `ca_cert`
|
||||
|
||||
Absolute path to the PEM encoded certificate authority used to verify the EAP server.
|
||||
Absolute path to the PEM encoded certificate authority used to verify the EAP
|
||||
server.
|
||||
|
||||
* `ca_path`
|
||||
- `ca_path`
|
||||
|
||||
Absolute path to directory containing additional pem encoded ca certificates used to
|
||||
verify the EAP server. Can be used instead of or in addition to ca_cert. Cannot be
|
||||
used if system_ca_certs is enabled.
|
||||
|
||||
* `system_ca_certs`
|
||||
- `system_ca_certs`
|
||||
|
||||
If set to `True`, NetworkManager will use the system's trusted ca certificates to verify the EAP server.
|
||||
If set to `True`, NetworkManager will use the system's trusted ca
|
||||
certificates to verify the EAP server.
|
||||
|
||||
* `domain_suffix_match`
|
||||
- `domain_suffix_match`
|
||||
|
||||
If set, NetworkManager will ensure the domain name of the EAP server certificate matches this string.
|
||||
If set, NetworkManager will ensure the domain name of the EAP server certificate
|
||||
matches this string.
|
||||
|
||||
### `bond`
|
||||
|
||||
The `bond` setting configures the options of bonded interfaces
|
||||
(type `bond`). It supports the following options:
|
||||
|
||||
* `mode`
|
||||
- `mode`
|
||||
|
||||
Bonding mode. See the
|
||||
[kernel documentation](https://www.kernel.org/doc/Documentation/networking/bonding.txt)
|
||||
or your distribution `nmcli` documentation for valid values.
|
||||
NetworkManager defaults to `balance-rr`.
|
||||
Bonding mode. See the
|
||||
[kernel documentation](https://www.kernel.org/doc/Documentation/networking/bonding.txt)
|
||||
or your distribution `nmcli` documentation for valid values.
|
||||
NetworkManager defaults to `balance-rr`.
|
||||
|
||||
* `miimon`
|
||||
- `miimon`
|
||||
|
||||
Sets the MII link monitoring interval (in milliseconds)
|
||||
|
||||
|
|
@ -638,7 +669,6 @@ network_connections:
|
|||
#interface_name: br0 # defaults to the connection name
|
||||
```
|
||||
|
||||
|
||||
Configuring a bridge connection:
|
||||
|
||||
```yaml
|
||||
|
|
@ -797,7 +827,6 @@ The `network` role rejects invalid configurations. It is recommended to test the
|
|||
with `--check` first. There is no protection against wrong (but valid) configuration.
|
||||
Double-check your configuration before applying it.
|
||||
|
||||
|
||||
Compatibility
|
||||
-------------
|
||||
|
||||
|
|
@ -823,13 +852,15 @@ after disabling the NetworkManager service.
|
|||
Limitations
|
||||
-----------
|
||||
|
||||
As Ansible usually works via the network, for example via SSH, there are some limitations to be considered:
|
||||
As Ansible usually works via the network, for example via SSH, there are some
|
||||
limitations to be considered:
|
||||
|
||||
The `network` role does not support bootstraping networking configuration. One
|
||||
option may be [ansible-pull](https://docs.ansible.com/ansible/playbooks_intro.html#ansible-pull).
|
||||
Another option maybe be to initially auto-configure the host during installation
|
||||
(ISO based, kickstart, etc.), so that the host is connected to a management LAN
|
||||
or VLAN. It strongly depends on your environment.
|
||||
The `network` role does not support bootstraping networking configuration. One option
|
||||
may be
|
||||
[ansible-pull](https://docs.ansible.com/ansible/playbooks_intro.html#ansible-pull).
|
||||
Another option maybe be to initially auto-configure the host during installation (ISO
|
||||
based, kickstart, etc.), so that the host is connected to a management LAN or VLAN. It
|
||||
strongly depends on your environment.
|
||||
|
||||
For `initscripts` provider, deploying a profile merely means to create the ifcfg
|
||||
files. Nothing happens automatically until the play issues `ifup` or `ifdown`
|
||||
|
|
@ -845,12 +876,12 @@ down and possibly removes virtual interfaces. With the `initscripts` provider
|
|||
removing a profile does not change its current runtime state (this is a future
|
||||
feature for NetworkManager as well).
|
||||
|
||||
For NetworkManager, modifying a connection with autoconnect enabled
|
||||
may result in the activation of a new profile on a previously disconnected
|
||||
interface. Also, deleting a NetworkManager connection that is currently active
|
||||
results in removing the interface. Therefore, the order of the steps should be
|
||||
followed, and carefully handling of [autoconnect](#autoconnect) property may be
|
||||
necessary. This should be improved in NetworkManager RFE [rh#1401515](https://bugzilla.redhat.com/show_bug.cgi?id=1401515).
|
||||
For NetworkManager, modifying a connection with autoconnect enabled may result in the
|
||||
activation of a new profile on a previously disconnected interface. Also, deleting a
|
||||
NetworkManager connection that is currently active results in removing the interface.
|
||||
Therefore, the order of the steps should be followed, and carefully handling of
|
||||
[autoconnect](#autoconnect) property may be necessary. This should be improved in
|
||||
NetworkManager RFE [rh#1401515](https://bugzilla.redhat.com/show_bug.cgi?id=1401515).
|
||||
|
||||
It seems difficult to change networking of the target host in a way that breaks
|
||||
the current SSH connection of ansible. If you want to do that, ansible-pull might
|
||||
|
|
@ -876,6 +907,5 @@ connectivity due to an error, NetworkManager would automatically rollback after
|
|||
timeout. The limitations is that this would only work with NetworkManager, and
|
||||
it is not clear that rollback will result in a working configuration.
|
||||
|
||||
|
||||
*Want to contribute? Take a look at our [contributing
|
||||
guidelines](https://github.com/linux-system-roles/network/blob/main/contributing.md)!*
|
||||
|
|
|
|||
255
contributing.md
255
contributing.md
|
|
@ -1,6 +1,8 @@
|
|||
# Contributing to the Network Linux System Role
|
||||
Contributing to the Network Linux System Role
|
||||
=============================================
|
||||
|
||||
## Where to start
|
||||
Where to start
|
||||
--------------
|
||||
|
||||
- **Bugs and needed implementations** are listed on [Github
|
||||
Issues](https://github.com/linux-system-roles/network/issues). Issues labeled with
|
||||
|
|
@ -14,7 +16,8 @@ Requests](https://help.github.com/en/github/collaborating-with-issues-and-pull-r
|
|||
|
||||
- The code needs to be **compatible with Python 2.6, 2.7, 3.6, 3.7 and 3.8**.
|
||||
|
||||
## Code structure
|
||||
Code structure
|
||||
--------------
|
||||
|
||||
The repository is structured as follows:
|
||||
|
||||
|
|
@ -36,26 +39,26 @@ The repository is structured as follows:
|
|||
|
||||
- `./tests/playbooks/` - Contains the complete tests for the role. `./tests/test_*.yml`
|
||||
are shims to run tests once for every provider. `./tests/tasks/` contains task
|
||||
snippets that are used in multiple tests to avoid having the same code repeated
|
||||
snippets that are used in multiple tests to avoid having the same code repeated
|
||||
multiple times.
|
||||
|
||||
The rest of files in the root folder mostly serve as configuration files for diferent
|
||||
testing tools and bots that help with the manteinance of the project.
|
||||
|
||||
|
||||
The code files will always have the imports on the first place, followed by constants
|
||||
and in the last place, classes and methods. The style of python coding for this project
|
||||
is [**PEP 8**](https://www.python.org/dev/peps/pep-0008/), with automatic formatting
|
||||
thanks to [Python Black](https://black.readthedocs.io/en/stable/). Make sure to install
|
||||
the formatter, it will help you a lot throughout the whole coding process!
|
||||
|
||||
## Configuring Git
|
||||
Configuring Git
|
||||
---------------
|
||||
|
||||
Before starting to contribute, make sure you have the basic git configuration: Your name
|
||||
and email. This will be useful when signing your contributions. The following commands
|
||||
will set your global name and email, althought you can change it later for every repo:
|
||||
|
||||
```
|
||||
```bash
|
||||
git config --global user.name "Jane Doe"
|
||||
git config --global user.email janedoe@example.com
|
||||
```
|
||||
|
|
@ -63,14 +66,15 @@ git config --global user.email janedoe@example.com
|
|||
The git editor is your system's default. If you feel more comfortable with a different
|
||||
editor for writing your commits (such as Vim), change it with:
|
||||
|
||||
```
|
||||
```bash
|
||||
git config --global core.editor vim
|
||||
```
|
||||
|
||||
If you want to check your settings, use `git config --list` to see all the settings Git can find.
|
||||
If you want to check your settings, use `git config --list` to see all the settings Git
|
||||
can find.
|
||||
|
||||
|
||||
## How to contribute
|
||||
How to contribute
|
||||
-----------------
|
||||
|
||||
1. Make a
|
||||
[fork](https://help.github.com/en/github/getting-started-with-github/fork-a-repo)
|
||||
|
|
@ -80,30 +84,34 @@ of this repository.
|
|||
changes you need to complete an issue.
|
||||
|
||||
3. Do not forget to run unit and integration tests before pushing any changes!
|
||||
1. This project uses [tox](https://tox.readthedocs.io/en/latest/) to run unit tests.
|
||||
You can try it with `tox -e py36` in case you want to try it using Python 3.6, or
|
||||
just `tox` if you want to run all the tests.
|
||||
|
||||
- This project uses [tox](https://tox.readthedocs.io/en/latest/) to run unit tests.
|
||||
You can try it with `tox -e py36` in case you want to try it using Python 3.6, or
|
||||
just `tox` if you want to run all the tests.
|
||||
2. Check the formatting of the code with
|
||||
[Python Black](https://black.readthedocs.io/en/stable/)
|
||||
|
||||
- Check the formatting of the code with [Python Black](https://black.readthedocs.io/en/stable/)
|
||||
3. Check the YAML files are correctly formatted using `tox -e yamllint`.
|
||||
|
||||
- Check the YAML files are correctly formatted using `tox -e yamllint`.
|
||||
4. Integration tests are executed as
|
||||
[Ansible Playbooks](https://docs.ansible.com/ansible/latest/user_guide/playbooks.html).
|
||||
|
||||
- Integration tests are executed as
|
||||
[ansible-playbooks](https://docs.ansible.com/ansible/latest/user_guide/playbooks.html).
|
||||
To run them you can use a cloud image like the [CentOS Linux 8.1
|
||||
VM](https://cloud.centos.org/centos/8/x86_64/images/CentOS-8-GenericCloud-8.1.1911-20200113.3.x86_64.qcow2)
|
||||
and execute the command and download the package
|
||||
`standard-test-roles-inventory-qemu` from the Fedora repository:
|
||||
|
||||
To run them you can use a cloud image like the [CentOS 8.1
|
||||
VM](https://cloud.centos.org/centos/8/x86_64/images/CentOS-8-GenericCloud-8.1.1911-20200113.3.x86_64.qcow2)
|
||||
and execute the command and download the package
|
||||
`standard-test-roles-inventory-qemu` from the Fedora repository:
|
||||
```bash
|
||||
dnf install standard-test-roles-inventory-qemu
|
||||
```
|
||||
|
||||
```dnf install standard-test-roles-inventory-qemu```
|
||||
Note that the last path is the one of the test you want to run:
|
||||
|
||||
Note that the last path is the one of the test you want to run:
|
||||
|
||||
`TEST_SUBJECTS=CentOS-8-GenericCloud-8.1.1911-20200113.3.x86_64.qcow2
|
||||
ansible-playbook -v -i /usr/share/ansible/inventory/standard-inventory-qcow2
|
||||
tests/test_default.yml`
|
||||
```bash
|
||||
TEST_SUBJECTS=CentOS-8-GenericCloud-8.1.1911-20200113.3.x86_64.qcow2 \
|
||||
ansible-playbook -v -i /usr/share/ansible/inventory/standard-inventory-qcow2 \
|
||||
tests/test_default.yml
|
||||
```
|
||||
|
||||
4. Once the work is ready and commited, push the branch to your remote fork and click on
|
||||
"new Pull Request" on Github.
|
||||
|
|
@ -113,29 +121,28 @@ tests/test_default.yml`
|
|||
will merge it to the main project.
|
||||
|
||||
### Find other images for testing
|
||||
To use the CentOS 6, CentOS 7, CentOS 8 images, please checkout the link below:<br/>
|
||||
https://cloud.centos.org/centos/6/images/CentOS-6-x86_64-GenericCloud-1907.qcow2c<br/>
|
||||
https://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud-2003.qcow2c<br/>
|
||||
https://cloud.centos.org/centos/8/x86_64/images/CentOS-8-GenericCloud-8.1.1911-20200113.3.x86_64.qcow2
|
||||
|
||||
- `/6/images/` stands for CentOS 6 images, we can also change it to `/7/images/` to use
|
||||
CentOS 7 images, change it to `/8/images/` to use CentOS 8 images.
|
||||
The CentOS project publishes cloud images for
|
||||
[CentOS Linux 6](https://cloud.centos.org/centos/6/images/),
|
||||
[CentOS Linux 7](https://cloud.centos.org/centos/7/images/) and
|
||||
[CentOS Linux 8](https://cloud.centos.org/centos/8/x86_64/images/).
|
||||
|
||||
- For qemu testing cases, we prefer the image architecture to be `x86_64-GenericCloud`.
|
||||
- `2003` in `CentOS-7-x86_64-GenericCloud-2003.qcow2c` stands for image released in
|
||||
March 2020.
|
||||
March 2020.
|
||||
- We can use the image with extension `.qcow2` and `.qcow2c`.
|
||||
- To save the image, right click on the link above, then select "Save link as...".
|
||||
|
||||
For Fedora, we recommend to use the latest qcow2 images from<br/>
|
||||
https://kojipkgs.fedoraproject.org/compose/cloud/
|
||||
For Fedora, we recommend to use the [latest qcow2
|
||||
images](https://kojipkgs.fedoraproject.org/compose/cloud/).
|
||||
|
||||
### Some important tips
|
||||
|
||||
- Make sure your fork and branch are up-to-date with the main project. First of all,
|
||||
[configure a remote upstream for your
|
||||
fork](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/configuring-a-remote-for-a-fork),
|
||||
and keep your branch up-to-date with the upstream using ```git pull --rebase upstream
|
||||
main```
|
||||
and keep your branch up-to-date with the upstream using
|
||||
`git pull --rebase upstream main`.
|
||||
|
||||
- Try to make a commit per issue.
|
||||
|
||||
|
|
@ -157,49 +164,50 @@ added, and merge both file versions into one that combines it all.
|
|||
|
||||
### Naming Ansible Items
|
||||
|
||||
* All YAML or Python files, variables, arguments, repositories, and other such names
|
||||
- All YAML or Python files, variables, arguments, repositories, and other such names
|
||||
should follow standard Python naming conventions of being in
|
||||
`snake_case_naming_schemes`.
|
||||
|
||||
* Names should be mnemonic and descriptive and not strive to shorten more than
|
||||
- Names should be mnemonic and descriptive and not strive to shorten more than
|
||||
necessary. Systems support long identifier names, so use them to be descriptive
|
||||
|
||||
* All defaults and all arguments to a role should have a name that begins with the role
|
||||
- All defaults and all arguments to a role should have a name that begins with the role
|
||||
name to help avoid collision with other names. Avoid names like `packages` in favor of
|
||||
a name like `network_packages`.
|
||||
|
||||
* Same argument applies for modules provided in the roles, they also need a `$ROLENAME_`
|
||||
- Same argument applies for modules provided in the roles, they also need a `$ROLENAME_`
|
||||
prefix: `network_module`. While they are usually implementation details and not intended
|
||||
for direct use in playbooks, the unfortunate fact is that importing a role makes them
|
||||
available to the rest of the playbook and therefore creates opportunities for name
|
||||
collisions.
|
||||
|
||||
* Moreover, internal variables (those that are not expected to be set by users) are to
|
||||
- Moreover, internal variables (those that are not expected to be set by users) are to
|
||||
be prefixed by two underscores: `__network_variable`. This includes variables set by
|
||||
set_fact and register, because they persist in the namespace after the role has
|
||||
`set_fact` and `register`, because they persist in the namespace after the role has
|
||||
finished!
|
||||
|
||||
* Do not use special characters other than underscore in variable names, even if
|
||||
- Do not use special characters other than underscore in variable names, even if
|
||||
YAML/JSON allow them. (Using such variables in Jinja2 or Python would be then very
|
||||
confusing and probably not functional.)
|
||||
|
||||
*Find more explanation on this matter in the [meta
|
||||
standards](https://github.com/oasis-roles/meta_standards#naming-things).*
|
||||
|
||||
|
||||
### Write a good commit message
|
||||
|
||||
Here are a few rules to keep in mind while writing a commit message
|
||||
|
||||
1. Separate subject from body with a blank line
|
||||
2. Limit the subject line to 50 characters
|
||||
3. Capitalize the subject line
|
||||
4. Do not end the subject line with a period
|
||||
5. Use the imperative mood in the subject line
|
||||
6. Wrap the body at 72 characters
|
||||
7. Use the body to explain what and why vs. how
|
||||
1. Separate subject from body with a blank line
|
||||
2. Limit the subject line to 50 characters
|
||||
3. Capitalize the subject line
|
||||
4. Do not end the subject line with a period
|
||||
5. Use the imperative mood in the subject line
|
||||
6. Wrap the body at 72 characters
|
||||
7. Use the body to explain what and why vs. how
|
||||
|
||||
A good commit message looks something like this
|
||||
```
|
||||
A good commit message looks something like this:
|
||||
|
||||
```text
|
||||
Summarize changes in around 50 characters or less
|
||||
|
||||
More detailed explanatory text, if necessary. Wrap it to about 72
|
||||
|
|
@ -229,29 +237,27 @@ Here are a few rules to keep in mind while writing a commit message
|
|||
See also: #456, #789
|
||||
|
||||
Do not forget to sign your commit! Use `git commit -s`
|
||||
|
||||
```
|
||||
|
||||
This is taken from [chris beams git commit](https://chris.beams.io/posts/git-commit/).
|
||||
You may want to read this for a more detailed explanation (and links to other posts on
|
||||
how to write a good commit message). This content is licensed under
|
||||
how to write a good commit message). This content is licensed under
|
||||
[CC-BY-SA](https://creativecommons.org/licenses/by-sa/4.0/).
|
||||
|
||||
### Sign off your commit.
|
||||
### Sign off your commit
|
||||
|
||||
You need to sign off your commit. By adding your 'Signed-off-by'
|
||||
line to the commit messages you adhere to the [Developer
|
||||
Certificate of Origin (DCO)](https://developercertificate.org/).
|
||||
You need to sign off your commit. By adding your 'Signed-off-by' line to the commit
|
||||
messages you adhere to the
|
||||
[Developer Certificate of Origin (DCO)](https://developercertificate.org/).
|
||||
|
||||
Use the `-s` command-line option to append the `Signed-off-by`
|
||||
line when committing your code:
|
||||
Use the `-s` command-line option to append the `Signed-off-by` line when committing your
|
||||
code:
|
||||
|
||||
`$ git commit -s`
|
||||
|
||||
This is the full text of the Developer Certificate of Origin:
|
||||
|
||||
This is the full text of the DCO:
|
||||
|
||||
```
|
||||
```text
|
||||
Developer Certificate of Origin
|
||||
Version 1.1
|
||||
|
||||
|
|
@ -291,12 +297,11 @@ By making a contribution to this project, I certify that:
|
|||
this project or the open source license(s) involved.
|
||||
```
|
||||
|
||||
|
||||
### Debugging
|
||||
|
||||
When using the `nm` provider, NetworkManager create a checkpoint and reverts the changes
|
||||
on failures. This makes it hard to debug the error. To disable this, set the Ansible
|
||||
variable `__network_debug_flags to include the value `disable-checkpoints`. Also tests
|
||||
variable `__network_debug_flags` to include the value `disable-checkpoints`. Also tests
|
||||
clean up by default in case there are failures. They should be tagged as
|
||||
`tests::cleanup` and can be skipped. To use both, run the test playbooks like this:
|
||||
|
||||
|
|
@ -307,77 +312,68 @@ ansible-playbook --skip-tags tests::cleanup \
|
|||
```
|
||||
|
||||
### NetworkManager Documentation
|
||||
- [NM 1.0](https://lazka.github.io/pgi-docs/#NM-1.0), it contains full explanation about NetworkManager API, including but not limited to:
|
||||
- Functions
|
||||
- Callbacks
|
||||
- Interfaces
|
||||
- Classes
|
||||
- Hierarchy
|
||||
- Structures
|
||||
- Class Structures
|
||||
- Interface Structures
|
||||
- Flags
|
||||
- Enums
|
||||
- Constants
|
||||
- Symbol Mapping
|
||||
|
||||
- [NM 1.0](https://lazka.github.io/pgi-docs/#NM-1.0), it contains a full explanation
|
||||
about the NetworkManager API.
|
||||
|
||||
### Integration tests with podman
|
||||
|
||||
1. Create `~/.ansible/collections/ansible_collections/containers/podman/` if this
|
||||
directory does not exist and `cd` into this directory.
|
||||
```bash
|
||||
mkdir -p ~/.ansible/collections/ansible_collections/containers/podman/
|
||||
cd ~/.ansible/collections/ansible_collections/containers/podman/
|
||||
```
|
||||
directory does not exist and `cd` into this directory.
|
||||
|
||||
```bash
|
||||
mkdir -p ~/.ansible/collections/ansible_collections/containers/podman/
|
||||
cd ~/.ansible/collections/ansible_collections/containers/podman/
|
||||
```
|
||||
|
||||
2. Clone the collection plugins for Ansible-Podman into the current directory.
|
||||
```bash
|
||||
git clone https://github.com/containers/ansible-podman-collections.git .
|
||||
```
|
||||
|
||||
3. Change directory into the `network/tests`, `network` is the Repo you cloned from
|
||||
your local fork.
|
||||
```bash
|
||||
cd ~/network/tests
|
||||
```
|
||||
```bash
|
||||
git clone https://github.com/containers/ansible-podman-collections.git .
|
||||
```
|
||||
|
||||
3. Change directory into the `tests` subdirectory.
|
||||
|
||||
```bash
|
||||
cd ~/network/tests
|
||||
```
|
||||
|
||||
4. Use podman with `-d` to run in the background (daemon). Use `c7` because
|
||||
`centos/systemd` is centos7.
|
||||
```bash
|
||||
podman run --name c7 --rm --privileged -v /sys/fs/cgroup:/sys/fs/cgroup:ro -d registry.centos.org/centos/systemd
|
||||
```
|
||||
`centos/systemd` is centos7.
|
||||
|
||||
```bash
|
||||
podman run --name lsr-ci-c7 --rm --privileged -v /sys/fs/cgroup:/sys/fs/cgroup:ro \
|
||||
-d registry.centos.org/centos/systemd
|
||||
```
|
||||
|
||||
5. Use `podman unshare` first to run "podman mount" in root mode, use `-vi` to run
|
||||
ansible as inventory in verbose mode, use `-c podman` to use collection plugins. Note,
|
||||
the following tests are currently not working with podman:
|
||||
- `tests_802_1x_nm.yml`
|
||||
- `tests_802_1x_updated_nm.yml`
|
||||
- `tests_bond_initscripts.yml`
|
||||
- `tests_bond_nm.yml`
|
||||
- `tests_bridge_initscripts.yml`
|
||||
- `tests_bridge_nm.yml`
|
||||
- `tests_default_nm.yml`
|
||||
- `tests_ethernet_nm.yml`
|
||||
- `tests_reapply_nm.yml`
|
||||
- `tests_states_nm.yml`
|
||||
- `tests_vlan_mtu_initscripts.yml`
|
||||
- `tests_vlan_mtu_nm.yml`
|
||||
- `tests_wireless_nm.yml`
|
||||
ansible as inventory in verbose mode, use `-c podman` to use collection plugins. Note,
|
||||
the following tests are currently not working with podman:
|
||||
- `tests_802_1x_nm.yml`
|
||||
- `tests_802_1x_updated_nm.yml`
|
||||
- `tests_bond_initscripts.yml`
|
||||
- `tests_bond_nm.yml`
|
||||
- `tests_bridge_initscripts.yml`
|
||||
- `tests_bridge_nm.yml`
|
||||
- `tests_default_nm.yml`
|
||||
- `tests_ethernet_nm.yml`
|
||||
- `tests_reapply_nm.yml`
|
||||
- `tests_states_nm.yml`
|
||||
- `tests_vlan_mtu_initscripts.yml`
|
||||
- `tests_vlan_mtu_nm.yml`
|
||||
- `tests_wireless_nm.yml`
|
||||
|
||||
```bash
|
||||
podman unshare
|
||||
ansible-playbook -vi c7, -c podman tests_provider_nm.yml
|
||||
```
|
||||
```bash
|
||||
podman unshare
|
||||
ansible-playbook -vi lsr-ci-c7, -c podman tests_provider_nm.yml
|
||||
```
|
||||
|
||||
6. NOTE that this leaves the container running in the background, to kill it:
|
||||
```bash
|
||||
> podman ps
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
02a45f9d53df registry.centos.org/centos/systemd:latest /usr/sbin/init 13 minutes ago Up 13 minutes ago c7
|
||||
> podman stop 02a45f9d53df
|
||||
> podman rm 02a45f9d53df
|
||||
```
|
||||
|
||||
```bash
|
||||
podman stop lsr-ci-c7
|
||||
podman rm lsr-ci-c7
|
||||
```
|
||||
|
||||
### Continuous integration
|
||||
|
||||
|
|
@ -392,17 +388,18 @@ comment. The available commands are:
|
|||
- [citest bad] - Trigger a re-test for all machines with an error or failure status.
|
||||
- [citest pending] - Trigger a re-test for all machines with a pending status.
|
||||
- [citest commit:<sha1\>] - Whitelist a commit to be tested if the submitter is not
|
||||
trusted.
|
||||
trusted.
|
||||
|
||||
How to reach us
|
||||
---------------
|
||||
|
||||
## How to reach us
|
||||
The mailing list for developers: systemroles@lists.fedorahosted.org
|
||||
|
||||
[Subscribe to the mailing list](https://lists.fedorahosted.org/admin/lists/systemroles.lists.fedorahosted.org/)
|
||||
|
||||
[Archive of the mailing list](https://lists.fedorahosted.org/archives/list/systemroles@lists.fedorahosted.org/)
|
||||
|
||||
If you are using IRC, join the `#systemroles` IRC channel on
|
||||
If you are using IRC, join the `#systemroles` IRC channel on
|
||||
[freenode](https://freenode.net/kb/answer/chat)
|
||||
|
||||
|
||||
*Thanks for contributing and happy coding!!*
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue