Network Configuration
NetworkConfiguration
The ifup and ifdown commands may be used to configure (or, respectively, deconfigure) network interfaces based on interface definitions in the file /etc/network/interfaces.
/etc/network/interfaces
This contains network interface configuration information for the ifup and ifdown commands. This is where you configure how your system is connected to the network.
EXAMPLE
auto eth0 allow-hotplug eth1 iface eth0 inet dhcp iface eth0 inet6 auto iface eth1 inet static address 192.168.1.2/24 gateway 192.168.1.1 iface eth1 inet6 static address fec0:0:0:1::2/64 gateway fec0:0:0:1::1The above example configures two network interfaces:
- eth0
- brought up at boot
- uses DHCP for IPv4 and SLAAC for IPv6
- eth1
- brought up whenever the network hardware is detected
- configured with static IPv4 and IPv6 addresses
HOOK SCRIPTS
There are four directories in which scripts can be placed which will always be run for any interface during certain phases of ifup and ifdown commands. These are:- /etc/network/if-pre-up.d/ Scripts in this directory are run before bringing the interface up.
- /etc/network/if-up.d/ Scripts in this directory are run after bringing the interface up.
- /etc/network/if-down.d/ Scripts in this directory are run before bringing the interface down.
- /etc/network/if-post-down.d/ Scripts in this directory are run after bringing the interface down.
ENVIRONMENT VARIABLES
All hook scripts have access to the following environment variables:- IFACE The physical name of the interface being processed, or "--all" (see below).
- LOGICAL The logical name of the interface being processed, or "auto" (see below).
- ADDRFAM The address family of the interface, or "meta" (see below).
- METHOD The method of the interface (e.g., static), or "none" (see below).
- CLASS The class of interfaces being processed. This is a copy of the value given to the --allow option when running ifup or ifdown, otherwise it is set to "auto" when the --all option is used.
- MODE start if run from ifup, stop if run from ifdown.
- PHASE As per MODE, but with finer granularity, distinguishing the pre-up, post-up, pre-down and post-down phases.
- VERBOSITY Indicates whether --verbose was used; set to 1 if so, 0 if not.
- PATH The command search path: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Examples
For ex., the package "ethtool":- /etc/network/if-pre-up.d/ethtool
#!/bin/sh
ETHTOOL=/sbin/ethtool
test -x $ETHTOOL || exit 0
[ "$IFACE" != "lo" ] || exit 0
# Gather together the mixed bag of settings applied with -s/--change
SETTINGS="\
${IF_ETHERNET_PORT:+ port $IF_ETHERNET_PORT}\
${IF_DRIVER_MESSAGE_LEVEL:+ msglvl $IF_DRIVER_MESSAGE_LEVEL}\
"
[ -z "$SETTINGS" ] || $ETHTOOL --change "$IFACE" $SETTINGS
#!/bin/sh
ETHTOOL=/sbin/ethtool
test -x $ETHTOOL || exit 0
[ "$IFACE" != "lo" ] || exit 0
# Find settings with a given prefix and print them as they appeared in
# /etc/network/interfaces, only with the prefix removed.
# This actually prints each name and value on a separate line, but that
# doesn't matter to the shell.
gather_settings () {
set | sed -n "
/^IF_$1[A-Za-z0-9_]*=/ {
h; # hold line
s/^IF_$1//; s/=.*//; s/_/-/g; # get name without prefix
y/ABCDEFGHIJKLMNOPQRSTUVWXYZ/abcdefghijklmnopqrstuvwxyz/; # lower-case
p;
g; # restore line
s/^[^=]*=//; s/^'\(.*\)'/\1/; # get value
p;
}"
}
# Gather together the mixed bag of settings applied with -s/--change
SETTINGS="\
${IF_LINK_SPEED:+ speed $IF_LINK_SPEED}\
${IF_LINK_DUPLEX:+ duplex $IF_LINK_DUPLEX}\
"
# WOL has an optional pass-key
set -- $IF_ETHERNET_WOL
SETTINGS="$SETTINGS${1:+ wol $1}${2:+ sopass $2}"
# Autonegotiation can be on|off or an advertising mask
case "$IF_ETHERNET_AUTONEG" in
'') ;;
on|off) SETTINGS="$SETTINGS autoneg $IF_ETHERNET_AUTONEG" ;;
*) SETTINGS="$SETTINGS autoneg on advertise $IF_ETHERNET_AUTONEG" ;;
esac
[ -z "$SETTINGS" ] || $ETHTOOL --change "$IFACE" $SETTINGS
SETTINGS="$(gather_settings ETHERNET_PAUSE_)"
[ -z "$SETTINGS" ] || $ETHTOOL --pause "$IFACE" $SETTINGS
SETTINGS="$(gather_settings HARDWARE_IRQ_COALESCE_)"
[ -z "$SETTINGS" ] || $ETHTOOL --coalesce "$IFACE" $SETTINGS
SETTINGS="$(gather_settings HARDWARE_DMA_RING_)"
[ -z "$SETTINGS" ] || $ETHTOOL --set-ring "$IFACE" $SETTINGS
SETTINGS="$(gather_settings OFFLOAD_)"
[ -z "$SETTINGS" ] || $ETHTOOL --offload "$IFACE" $SETTINGS
Other packages can make other options available for use in /etc/network/.
Netplan
The old way of configuring Debian-based network interfaces was based on the ifupdown package.The new default is called Netplan.
Netplan is a utility for easily configuring networking on a linux system.
You simply create a YAML description file of the required network interfaces then all the necessary configuration for your chosen renderer tool will be generated by Netplan.
How does it work?
There are central network config files for Snappy, Server, Client, MaaS, cloud-init in /etc/netplan/*.yaml.All installers only generate such a file, no /etc/network/interfaces any more.
Netplan reads network configuration files from /etc/netplan/*.yaml, during early boot, Netplan generates backend specific configuration files in /run to hand off control of devices to a particular networking daemon(renderers):
- NetworkManager This will make NetworkManager manage all devices (and by default, any ethernet device will come up with DHCP once carrier is detected).
For ex., /etc/netplan/01-network-manager-all.yaml:
# Let NetworkManager manage all devices on this system
network:
version: 2
renderer: NetworkManager
The NetworkManager program itself is the same GUI-based interface configuration system.
For ex., /etc/netplan/01-netcfg.yaml
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
version: 2
renderer: networkd
ethernets:
enp0s31f6:
dhcp4: yes
The above config tells of bringing up the Ethernet interface named enp0s31f6 via DHCP. Configuration is done with Netplan YAML files, but once "applied", Netplan creates the back-end configurations systemd requires. A set of subcommands can be used to drive Netplan:
- netplan generate netplan generate converts netplan YAML into configuration files understood by the backends (systemd-networkd(8) or NetworkManager(8)). It does not apply the generated configuration.
- /lib/netplan/*.yaml
- /etc/netplan/*.yaml
- /run/netplan/*.yaml
- netplan apply Apply all configuration files for the renderers, restarting them as necessary.
- netplan try Apply configuration and wait for user confirmation; will roll back if network is broken or no confirmation is given.
You will not normally need to run this directly as it is run by netplan apply, netplan try, or at boot.
There are 3 locations that netplan generate considers:
Netplan Design
Systems are configured during early boot with a “network renderer” which reads /etc/netplan/*.yaml and writes configuration to /run to hand off control of devices to the specified networking renderer(daemon).
- Wifi and WWAN get managed by NetworkManager
- Configured devices get handled by systemd-networkd by default Unless explicitly marked as managed by a specific renderer (NetworkManager)
- Devices not covered by the network config do not get touched at all.
netplan apply
netplan-apply - apply configuration from netplan YAML files to a running system.The process works as follows:
- The backend configuration is generated from netplan YAML files.
- The appropriate backends (systemd-networkd(8) or NetworkManager(8)) are invoked to bring up configured interfaces.
- netplan apply iterates through interfaces that are still down, unbinding them from their drivers, and rebinding them. This gives udev(7) renaming rules the opportunity to run.
- If any devices have been rebound, the appropriate backends are re-invoked in case more matches can be done.
$ sudo systemctl status systemd-networkd
* systemd-networkd.service - Network Service
Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled-runtime; vendor preset: enabled)
Active: active (running) since Mon 2022-04-18 01:35:56 UTC; 9min ago
Docs: man:systemd-networkd.service(8)
Main PID: 938 (systemd-network)
Status: "Processing requests..."
Tasks: 1 (limit: 1680)
Memory: 1.2M
CGroup: /system.slice/systemd-networkd.service
`-938 /lib/systemd/systemd-networkd
Apr 18 01:35:56 ubuntu systemd[1]: Starting Network Service...
Apr 18 01:35:56 ubuntu systemd-networkd[938]: ens3: Gained IPv6LL
Apr 18 01:35:56 ubuntu systemd-networkd[938]: Enumeration completed
Apr 18 01:35:56 ubuntu systemd[1]: Started Network Service.
Apr 18 01:35:56 ubuntu systemd-networkd[938]: ens3: IPv6 successfully enabled
Apr 18 01:35:56 ubuntu systemd-networkd[938]: ens3: DHCPv4 address 10.0.2.15/24 via 10.0.2.2
Networkctl is a command line utility in the new release of systemd- To get the status information about your network links
$ networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 ens3 ether routable configured
2 links listed.
$ networkctl status ens3
* 2: ens3
Link File: /usr/lib/systemd/network/99-default.link
Network File: /run/systemd/network/10-netplan-ens3.network
Type: ether
State: routable (configured)
Alternative Names: enp0s3
Path: pci-0000:00:03.0
Driver: virtio_net
Vendor: Red Hat, Inc.
Model: Virtio network device
HW Address: 52:54:00:12:34:56
MTU: 1500 (min: 68, max: 65535)
Queue Length (Tx/Rx): 1/1
Auto negotiation: no
Speed: n/a
Address: 10.0.2.15 (DHCP4)
fec0::5054:ff:fe12:3456
fe80::5054:ff:fe12:3456
Gateway: 10.0.2.2
fe80::2
DNS: 10.0.2.3
Activation Policy: up
Required For Online: yes
General structure
A subset of the Networking Config Version 2 format defined for the netplan tool is upported by the cloud-init.
network:
version: 2
renderer: <RENDER>
<TYPE>:
<DEVICE CONFIGURATION ID>:
The network key has at least two required elements:First it must include version: 2 and one or more of possible device types.
- RENDER networking backend for this definition
- NetworkManager
- networkd
- TYPE
- ethernets
- wifis
- modems
- bonds
- bridges
- DEVICE CONFIGURATION ID The key names below the per-device-type definition maps (like ethernets:) are called “ID”s.
They must be unique throughout the entire set of configuration files.
Their primary purpose is to serve as anchor names for composite devices, each entry may include IP and/or device configuration.
- Virtual devices These devices are being created by the protocol stack. (Examples: veth, bridge, bond)
- Physical devices These can dynamically come and go between reboots and even during runtime (hotplugging). (Examples: ethernet, wifi)
- name: Current interface name.
- macaddress: Device’s MAC address in the form XX:XX:XX:XX:XX:XX.
- driver: Kernel driver name, corresponding to the DRIVER udev property.
They can be selected by “match:” rules.
All specified properties for the match: key must match.
The following properties for creating matches are supported:
# all cards on second PCI bus
match:
name: enp2*
# fixed MAC address
match:
macaddress: 11:22:33:AA:BB:FF
# first card of driver ``ixgbe``
match:
driver: ixgbe
name: en*s0
Match rules can be written so that they only match one device. Then the “set-name:” property can be used to give that device a more specific/desirable/nicer name than the default from udev’s ifnames.It is valid to specify no match rules at all, in which case the ID field is simply the interface name to be matched.
Netplan reference (Properties)
Common properties for all device types
- dhcp4: bool.
- dhcp6: bool.
- addresses: sequence of scalars.
- addr is an IPv4 or IPv6 address as recognized by inet_pton(3)
- prefixlen the number of bits of the subnet.
Enable DHCP for IPv4. Off by default.
Enable DHCP for IPv6. Off by default.
Add static addresses to the interface in addition to the ones received through DHCP or RA.
Each sequence entry is in CIDR notation, i. e. of the form addr/prefixlen .
addresses: [192.168.14.2/24, 2001:1::1/64]
Example for IPv4:
gateway4: 172.16.0.1 Example for IPv6: gateway6: 2001:4::1
The MTU key represents a device’s Maximum Transmission Unit, the largest size packet or frame, specified in octets (eight-bit bytes), that can be sent in a packet- or frame-based network. Specifying mtu is optional.
Set DNS servers and search domains, for manual address configuration.
There are two supported fields:
- addresses: is a list of IPv4 or IPv6 addresses similar to gateway*, and
- search: is a list of search domains.
nameservers: search: [lab, home] addresses: [8.8.8.8, FEDC::1]
Add device specific routes. Each mapping includes a to, via key with an IPv4 or IPv6 address as value. metric is an optional value. Example:
routes: - to: 0.0.0.0/0 via: 10.23.2.1 metric: 3
Properties for modems:
GSM/CDMA modem configuration is only supported for the NetworkManager backend.- apn scalar.
- auto-config bool.
- device-id scalar.
- network-id scalar.
- number scalar.
- password scalar.
- pin scalar.
- sim-id scalar.
- sim-operator-id scalar.
- username scalar.
Set the carrier APN (Access Point Name).
This can be omitted if auto-config is enabled.
Specify whether to try and autoconfigure the modem by doing a lookup of the carrier against the Mobile Broadband Provider database.
This may not work for all carriers.
Specify the device ID (as given by the WWAN management service) of the modem to match.
This can be found using mmcli.
Specify the Network ID (GSM LAI format).
If this is specified, the device will not roam networks.
The number to dial to establish the connection to the mobile broadband network. (Deprecated for GSM)
Specify the password used to authenticate with the carrier network.
This can be omitted if auto-config is enabled.
Specify the SIM PIN to allow it to operate if a PIN is set.
Specify the SIM unique identifier (as given by the WWAN management service) which this connection applies to.
If given, the connection will apply to any device also allowed by device-id which contains a SIM card matching the given identifier.
Specify the MCC/MNC string (such as “310260” or “21601”) which identifies the carrier that this connection should apply to.
If given, the connection will apply to any device also allowed by device-id and sim-id which contains a SIM card provisioned by the given operator.
Specify the username used to authentiate with the carrier network.
This can be omitted if auto-config is enabled.
Properties for wifis:
- access-points: Note that systemd-networkd does not natively support wifi:.
- password: The network is assumed to be open.
- mode:
- infrastructure The default mode.
- ap create an access point to which other devices can connect.
- adhoc Connect to peer to peer networks without a central access point.
- mesh
- bssid: only associate with the given BSSID
- band:
- 5GHz
- 2.4GHz
- channel: This property takes effect only if the band property is also set.
- hidden:
- Set to true for connecting to hidden WiFi networks.
- Set to false (the default) for connecting to publicly broadcast SSIDs.
- wakeonwlan: This enables WakeOnWLan on supported devices.
This provides pre-configured connections to NetworkManager. The keys of the mapping are the SSIDs with the following supported properties:
Properties for bonds:
Network bonding is a way to combine multiple physical ports programmatically so that they act as one.There are two reasons: throughput and fault tolerence.
- interfaces: Sequence of scalars.
All devices matching this ID list will be added to the bond.
Example,
ethernets:
switchports:
match: {name: "enp2*"}
[...]
bonds:
bond0:
interfaces: [switchports]
Time values are specified in seconds unless otherwise specified.
- mode scalar.
- balance-rr The default is balance-rr (round robin).
- active-backup Active-backup policy: Only one interface in the bond is active.
- balance-xor XOR policy: Transmit based on selectable hashing algorithm.
- broadcast Broadcast policy: transmits everything on all interfaces. This mode provides fault tolerance.
- 802.3ad IEEE 802.3ad Dynamic link aggregation.
- balance-tlb Adaptive transmit load balancing: channel bonding that does not require any special switch support. The outgoing traffic is distributed according to the current load (computed relative to the speed) on each interface. Incoming traffic is received by the current interface. If the receiving interface fails, another interface takes over the MAC address of the failed receiving interface.
- balance-alb Adaptive load balancing: includes balance-tlb plus receive load balancing (rlb) for IPV4 traffic, and does not require any special switch support. The receive load balancing is achieved by ARP negotiation. The bonding driver intercepts the ARP Replies sent by the local system on their way out and overwrites the source hardware address with the unique hardware address of one of the interfaces in the bond such that different peers use different hardware addresses for the server.
- lacp-rate Set the rate at which LACPDUs are transmitted. This is only useful in 802.3ad mode.
- mii-monitor-interval Specifies the interval for MII monitoring (verifying if an interface of the bond has carrier).
- min-links The minimum number of links up in a bond to consider the bond interface to be up.
- transmit-hash-policy Specifies the transmit hash policy for the selection of slaves.
- ad-select Set the aggregation selection mode.
- all-slaves-active bool.
- primary Specify a device to be used as a primary slave, or preferred device to use as a slave for the bond (ie. the preferred device to send data through), whenever it is available.
Set the bonding mode used for the interfaces. Possible values are
Round-robin policy: Transmit packets in order from the first available interface to the last.
This mode provides load balancing and fault tolerance.
A different interface becomes active if, and only if, the active interface fails.
The bond's MAC address is externally visible on only one port (network adapter) to avoid confusing the switch. This mode provides fault tolerance.
The default policy is a simple source+destination MAC address algorithm.
Alternate transmit policies may be selected via the xmit_hash_policy option, described below.
This mode provides load balancing and fault tolerance.
Creates aggregation groups that share the same speed and duplex settings.
Utilizes all interfaces in the active aggregator according to the 802.3ad specification.
Possible values are slow (30 seconds, default), and fast (every second).
This is only useful in balance-xor, 802.3ad and balance-tlb modes.
Possible values are layer2, layer3+4, layer2+3, encap2+3, and encap3+4.
Possible values are stable, bandwidth, and count.
This option is only used in 802.3ad mode.
If the bond should drop duplicate frames received on inactive ports, set this option to false. If they should be delivered, set this option to true.
The default value is false, and is the desirable behavior in most situations.
This only affects active-backup, balance-alb, and balance-tlb modes.
network:
version: 2
renderer: networkd
ethernets:
enp13s0:
#Disables DHCP for the interface.
dhcp4: no
#Optional option allows for this interface to be disabled without breaking the bond.
optional: true
enp0s31f6:
#Disables DHCP for the interface.
dhcp4: no
#Optional option allows for this interface to be disabled without breaking the bond.
optional: true
bonds:
bond4:
interfaces:
- enp13s0
- enp0s31f6
parameters:
mode: active-backup
mii-monitor-interval: 1
dhcp4: true
Netplan configuration examples
Configuration
To configure netplan,- save configuration files under /etc/netplan/ with a .yaml extension For e.g., /etc/netplan/01-network-manager-all.yaml:
# Let NetworkManager manage all devices on this system
network:
version: 2
renderer: NetworkManager
$ sudo netplan apply
Examples
- Using DHCP and static addressing
network:
version: 2
renderer: networkd
ethernets:
enp3s0:
dhcp4: true
enp3s1:
addresses:
- 10.10.10.2/24
gateway4: 10.10.10.1
nameservers:
search: [mydomain, otherdomain]
addresses: [10.10.10.1, 1.1.1.1]
network:
version: 2
ethernets:
enred:
dhcp4: yes
dhcp4-overrides:
route-metric: 100
engreen:
dhcp4: yes
dhcp4-overrides:
route-metric: 200
To achieve the exact routing desired over DHCP by specifying a metric.
network:
version: 2
renderer: NetworkManager
network:
version: 2
wifis:
wl0:
access-points:
opennetwork: {}
dhcp4: yes
network:
version: 2
renderer: networkd
wifis:
wlp2s0b1:
dhcp4: no
dhcp6: no
addresses: [192.168.0.21/24]
gateway4: 192.168.0.1
nameservers:
addresses: [192.168.0.1, 8.8.8.8]
access-points:
"network_ssid_name":
password: "**********"
network:
version: 2
renderer: networkd
ethernets:
enp3s0:
addresses:
- 10.100.1.38/24
- 10.100.1.39/24
gateway4: 10.100.1.1
Below is an example of an active-backup bond that uses DHCP to obtain an address:
network:
version: 2
renderer: networkd
bonds:
bond0:
dhcp4: yes
interfaces:
- enp3s0
- enp4s0
parameters:
mode: active-backup
primary: enp3s0
Network Manager
NetworkManager is a program for providing detection and configuration for systems to automatically connect to networks.NetworkManager's functionality can be useful for both wireless and wired networks.
For wireless networks, NetworkManager prefers known wireless networks and has the ability to switch to the most reliable network.
NetworkManager also prefers wired connections over wireless ones, has support for modem connections and certain types of VPN.
NetworkManager was originally developed by Red Hat and now is hosted by the GNOME project.
Installation
NetworkManager can be installed with the package networkmanager, which contains- a daemon
- a command line interface (nmcli)
- a curses‐based interface (nmtui)
systemctl --type=serviceExcept for the Ethernet networking support,
- Mobile broadband support Install modemmanager, mobile-broadband-provider-info and usb_modeswitch packages for mobile broadband connection support. See USB 3G Modem#NetworkManager for details.
- PPPoE / DSL support Install rp-pppoe package for PPPoE / DSL connection support.
- VPN support NetworkManager since version 1.16 has native support for WireGuard, all it needs is the wireguard kernel module.
To actually add PPPoE connection, use nm-connection-editor and add new DSL/PPPoE connection.
Support for other VPN types is based on a plug-in system.
Control
The basic format of a nmcli command is as follows:
nmcli [OPTIONS] OBJECT { COMMAND | help }
where OBJECT can be one of the following options:
- general
- networking
- radio
- connection
- device
- agent
- monitor
- List nearby Wi-Fi networks:
$ nmcli device wifi list
$ nmcli device wifi connect SSID_or_BSSID password password
$ nmcli device wifi connect SSID_or_BSSID password password hidden yes
$ nmcli device wifi connect SSID_or_BSSID password password ifname wlan1 profile_name
$ nmcli device disconnect ifname eth0
$ nmcli connection show
$ nmcli connection up name_or_uuid
$ nmcli connection delete name_or_uuid
$ nmcli device
$ nmcli radio wifi off
Configuration
All the connection configuration files will be stored under /etc/NetworkManager:
├── conf.d
│ ├── 10-ubuntu-fan.conf
│ └── default-wifi-powersave-on.conf
├── dispatcher.d
│ ├── 01-ifupdown
│ ├── no-wait.d
│ ├── pre-down.d
│ └── pre-up.d
├── dnsmasq.d
├── dnsmasq-shared.d
├── NetworkManager.conf
└── system-connections
├── Jerry_DSL-5G.nmconnection
└── tw-jerry-lee-tpe@2.nmconnection
- the global default configuration NetworkManager has a global configuration file at /etc/NetworkManager/NetworkManager.conf.
[main] plugins=ifupdown,keyfile [ifupdown] managed=false [device] wifi.scan-rand-mac-address=noUsually no configuration needs to be done to the global defaults.
After editing a configuration file, the changes can be applied by running:
# nmcli general reload
DHCP client
By default NetworkManager uses its internal DHCP client.To change the DHCP client backend, set the option main.dhcp=dhcp_client_name with a configuration file in /etc/NetworkManager/conf.d/.
For ex., /etc/NetworkManager/conf.d/dhcp-client.conf:
[main] dhcp=dhclient
DNS management
NetworkManager's DNS management is described in the GNOME project's wiki page—Projects/NetworkManager/DNS.Network services with NetworkManager dispatcher
NetworkManager has the ability to start services when you connect to a network and stop them when you disconnect (e.g. when using NFS, SMB and NTPd).To activate the feature you need to enable and start the NetworkManager-dispatcher.service.
Once the service is active, scripts can be added to the /etc/NetworkManager/dispatcher.d directory.
The scripts will be run in alphabetical order at connection time, and in reverse alphabetical order at disconnect time.
Scripts will receive the following arguments in order:
- Interface name e.g. eth0
- Interface status up or down
- VPN status vpn-up or vpn-down
The idea is to only turn Wi-Fi on when the LAN cable is unplugged (for example when detaching from a laptop dock), and for Wi-Fi to be automatically disabled, once a LAN cable is plugged in again.
Create the following dispatcher script, replacing enp3s0 with yours.:
#!/bin/sh
if [ "$1" = "enp3s0" ]; then
case "$2" in
up)
nmcli radio wifi off
;;
down)
nmcli radio wifi on
;;
esac
fi
Tips and tricks
- Encrypted Wi-Fi passwords By default, NetworkManager stores passwords in clear text in the connection files at /etc/NetworkManager/system-connections/.
$ sudo grep -r '^psk=' /etc/NetworkManager/system-connections/
/etc/NetworkManager/system-connections/Jerry_DSL-5G.nmconnection:psk=***
It's possible to save the passwords in encrypted form in a keyring instead of clear text. The downside of using a keyring is that the connections have to be set up for each user.You will need:
- A Wi-Fi card which supports AP mode You need a nl80211 compatible wireless device, which supports the AP operating mode:
$ iw list
...
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
* P2P-client
* P2P-GO
...
NetworkManager checks if the wifi card supports AP mode, so the rest of the job is to push the correct configuration options to wpa_supplicant when Internet Connection Sharing is started.
NetworkManager now supports an enhanced Hotspot/Internet Connection Sharing mode for WiFi, which enables a much smoother connection sharing experience and is better supported by hardware.
$ sudo journalctl -u dnsmasq.service
-- Logs begin at Fri 2022-03-04 03:12:14 UTC, end at Sat 2022-03-05 08:51:40 UTC. --
-- No entries --
Install the dnsmasq package to be able to actually share the connection
nmcli device > nmcli.log
cat nmcli.log | while read line
do
TYPE=$( echo $line | cut -f2 -d" " )
if [ $TYPE == "wifi" ]; then
STATE=$( echo $line | cut -f3 -d" " )
if [ $STATE == "connected" ]; then
echo "WiFi is connected"
# Whatever you want to do if the network is online
else
echo "WiFi is not connected"
# Whatever you want to do if the network is offline
fi
fi
done
[keyfile]
unmanaged-devices=mac:00:22:68:1c:59:b1;mac:00:1E:65:30:D1:C4;interface-name:eth0
Debug NetworkManager
NetworkManager provides different levels and domains to produce logging information.Viewing NetworkManager logs
# journalctl -u NetworkManager -bIncreasing the log levels for all or certain domains helps to log more details of the operations NetworkManager performs.
- The level defines the verbosity level One of OFF, ERR, WARN, INFO, DEBUG, TRACE.
- The domain define the category of the messages to be logged with given level The following log domains are available: PLATFORM, RFKILL, ETHER, WIFI, BT, MB, DHCP4, DHCP6, PPP, WIFI_SCAN, IP4, IP6, AUTOIP4, DNS, VPN, SHARING, SUPPLICANT, AGENTS, SETTINGS, SUSPEND, CORE, DEVICE, OLPC, WIMAX, INFINIBAND, FIREWALL, ADSL, BOND, VLAN, BRIDGE, DBUS_PROPS, TEAM, CONCHECK, DCB, DISPATCH, AUDIT, SYSTEMD, VPN_PLUGIN, PROXY.
You can change the log level at run time using nmcli.
- Display the current logging settings
$ nmcli general logging
LEVEL DOMAINS
INFO PLATFORM,RFKILL,ETHER,WIFI,BT,MB,DHCP4,DHCP6,PPP,IP4,IP6,AUTOIP4,DNS,VPN,SHARING,SUPPLICANT,AGENTS,SETTINGS
,SUSPEND,CORE,DEVICE,OLPC,INFINIBAND,FIREWALL,ADSL,BOND,VLAN,BRIDGE,TEAM,CONCHECK,DCB,DISPATCH,AUDIT,SYSTEMD,PROXY
# nmcli general logging level LEVEL domains ALL
# nmcli general logging level LEVEL domains DOMAINS
For ex., the snap.network-manager.networkmanager.service:
$ sudo nmcli general logging level TRACE domain WIFI
$ sudo journalctl -u snap.network-manager.networkmanager -b
# nmcli general logging level KEEP domains DOMAIN:LEVEL,DOMAIN:LEVEL
But, updating debugging levels and domains using the /etc/NetworkManager/NetworkManager.conf file helps to debug boot issues and captures all the logs from the initial state.
Troubleshooting
- Network management disabled When NetworkManager shuts down but the pid (state) file is not removed, you will see a Network management disabled message. If this happens, remove the file manually:
# rm /var/lib/NetworkManager/NetworkManager.state
nm-settings
NetworkManager is based on a concept of connection profiles, sometimes referred to as connections only.The connection profiles are handled by NetworkManager via settings service and are exported on D-Bus.
- Connection (profile) A specific, encapsulated, independent group of settings describing all the configuration required to connect to a specific network.
- Setting A group of related key/value pairs describing a specific piece of a Connection (profile).
It is referred to by a unique identifier called the UUID.
Settings keys(properties) and allowed values are described in the tables below.
- 802-11-wireless setting
- mode src/libnm-core-public/nm-setting-wireless.h:
#define NM_SETTING_WIRELESS_MODE_INFRA "infrastructure"
#define NM_SETTING_WIRELESS_MODE_ADHOC "adhoc"
#define NM_SETTING_WIRELESS_MODE_AP "ap"
#define NM_SETTING_WIRELESS_MODE_MESH "mesh"
- infrastructure Indicates infrastructure mode where an access point is expected to be present for this connection.
- ap Indicates AP/master mode where the wireless device is started as an access point/hotspot.
- adhoc Indicates Ad-Hoc mode where no access point is expected to be present.
- mesh Indicates that the connection should create a mesh point.
| Key Name | Value Type | Default Value | Value Description |
|---|---|---|---|
| auth-alg | string | When WEP is used (ie, key-mgmt = "none" or "ieee8021x") indicate the 802.11 authentication algorithm required by the AP here. One of "open" for Open System, "shared" for Shared Key, or "leap" for Cisco LEAP. When using Cisco LEAP (ie, key-mgmt = "ieee8021x" and auth-alg = "leap") the "leap-username" and "leap-password" properties must be specified. | |
| group | array of string | [] | A list of group/broadcast encryption algorithms which prevents connections to Wi-Fi networks that do not utilize one of the algorithms in the list. For maximum compatibility leave this property empty. Each list element may be one of "wep40", "wep104", "tkip", or "ccmp". |
| key-mgmt | string | Key management used for the connection. One of "none" (WEP), "ieee8021x" (Dynamic WEP), "wpa-none" (Ad-Hoc WPA-PSK), "wpa-psk" (infrastructure WPA-PSK), or "wpa-eap" (WPA-Enterprise). This property must be set for any Wi-Fi connection that uses security. | |
| leap-password | string | The login password for legacy LEAP connections (ie, key-mgmt = "ieee8021x" and auth-alg = "leap"). | |
| leap-password-flags | NMSettingSecretFlags (uint32) | Flags indicating how to handle the "leap-password" property. (see the section called “Secret flag types:” for flag values) | |
| leap-username | string | The login username for legacy LEAP connections (ie, key-mgmt = "ieee8021x" and auth-alg = "leap"). | |
| name | string | 802-11-wireless-security | The setting's name, which uniquely identifies the setting within the connection. Each setting type has a name unique to that type, for example "ppp" or "wireless" or "wired". |
| pairwise | array of string | [] | A list of pairwise encryption algorithms which prevents connections to Wi-Fi networks that do not utilize one of the algorithms in the list. For maximum compatibility leave this property empty. Each list element may be one of "tkip" or "ccmp". |
| proto | array of string | [] | List of strings specifying the allowed WPA protocol versions to use. Each element may be one "wpa" (allow WPA) or "rsn" (allow WPA2/RSN). If not specified, both WPA and RSN connections are allowed. |
| psk | string | Pre-Shared-Key for WPA networks. If the key is 64-characters long, it must contain only hexadecimal characters and is interpreted as a hexadecimal WPA key. Otherwise, the key must be between 8 and 63 ASCII characters (as specified in the 802.11i standard) and is interpreted as a WPA passphrase, and is hashed to derive the actual WPA-PSK used when connecting to the Wi-Fi network. | |
| psk-flags | NMSettingSecretFlags (uint32) | Flags indicating how to handle the "psk" property. (see the section called “Secret flag types:” for flag values) | |
| wep-key-flags | NMSettingSecretFlags (uint32) | Flags indicating how to handle the "wep-key0", "wep-key1", "wep-key2", and "wep-key3" properties. (see the section called “Secret flag types:” for flag values) | |
| wep-key-type | NMWepKeyType (uint32) | Controls the interpretation of WEP keys. Allowed values are NM_WEP_KEY_TYPE_KEY (1), in which case the key is either a 10- or 26-character hexadecimal string, or a 5- or 13-character ASCII password; or NM_WEP_KEY_TYPE_PASSPHRASE (2), in which case the passphrase is provided as a string and will be hashed using the de-facto MD5 method to derive the actual WEP key. | |
| wep-key0 | string | Index 0 WEP key. This is the WEP key used in most networks. See the "wep-key-type" property for a description of how this key is interpreted. | |
| wep-key1 | string | Index 1 WEP key. This WEP index is not used by most networks. See the "wep-key-type" property for a description of how this key is interpreted. | |
| wep-key2 | string | Index 2 WEP key. This WEP index is not used by most networks. See the "wep-key-type" property for a description of how this key is interpreted. | |
| wep-key3 | string | Index 3 WEP key. This WEP index is not used by most networks. See the "wep-key-type" property for a description of how this key is interpreted. | |
| wep-tx-keyidx | uint32 | 0 | When static WEP is used (ie, key-mgmt = "none") and a non-default WEP key index is used by the AP, put that WEP key index here. Valid values are 0 (default key) through 3. Note that some consumer access points (like the Linksys WRT54G) number the keys 1 - 4. |
$ nmcli c NAME UUID TYPE DEVICE netplan-wlan0-guest abc5d1b3-dc99-3148-821e-ea5f6d253dd5 wifi wlan0 netplan-all-en 5ed20450-f673-31b9-a57a-c0737409da91 ethernet -- netplan-all-eth bd1f2e72-56d1-3145-b8ff-9a2f9b07daed ethernet -- $ nmcli c show netplan-wlan0-guest connection.id: netplan-wlan0-guest ... 802-11-wireless.ssid: guest 802-11-wireless.mode: ap 802-11-wireless.band: -- 802-11-wireless.channel: 0 802-11-wireless.bssid: -- 802-11-wireless.rate: 0 802-11-wireless.tx-power: 0 802-11-wireless.mac-address: -- 802-11-wireless.cloned-mac-address: -- 802-11-wireless.generate-mac-address-mask:-- 802-11-wireless.mac-address-blacklist: -- 802-11-wireless.mac-address-randomization:default 802-11-wireless.mtu: auto 802-11-wireless.seen-bssids: 00:90:4C:C5:12:38 802-11-wireless.hidden: no 802-11-wireless.powersave: 0 (default) 802-11-wireless.wake-on-wlan: 0x1 (default) 802-11-wireless-security.key-mgmt: wpa-psk 802-11-wireless-security.wep-tx-keyidx: 0 802-11-wireless-security.auth-alg: -- 802-11-wireless-security.proto: -- 802-11-wireless-security.pairwise: -- 802-11-wireless-security.group: -- 802-11-wireless-security.pmf: 0 (default) 802-11-wireless-security.leap-username: -- 802-11-wireless-security.wep-key0: <hidden> 802-11-wireless-security.wep-key1: <hidden> 802-11-wireless-security.wep-key2: <hidden> 802-11-wireless-security.wep-key3: <hidden> 802-11-wireless-security.wep-key-flags: 0 (none) 802-11-wireless-security.wep-key-type: unknown 802-11-wireless-security.psk: <hidden> 802-11-wireless-security.psk-flags: 0 (none) 802-11-wireless-security.leap-password: <hidden> 802-11-wireless-security.leap-password-flags:0 (none) 802-11-wireless-security.wps-method: 0x0 (default) 802-11-wireless-security.fils: 0 (default) ipv4.method: shared ...
Configuring networking with nmcli
It is recommended to type a partial nmcli command, and then press the Tab key to auto-complete the command sequence. If multiple completions are possible, then Tab lists them all. Fox ex.,$ nmcli con dev nm $ nmcli con delete down list status up
Overview of nmcli property names and aliases
systemd.network - Network configuration
The main network file must have the extension .network; other extensions are ignored.The .network files are read from the files located in the system network directory /lib/systemd/network and the volatile runtime network directory /run/systemd/network and the local administration network directory /etc/systemd/network:
- /run/systemd/network
├── 73-usb-net-by-mac.link ├── 80-container-host0.network ├── 80-container-ve.network ├── 80-container-vz.network ├── 80-wifi-adhoc.network ├── 80-wifi-ap.network.example ├── 80-wifi-station.network.example └── 99-default.link
SystemdNetworkd
Setting up Systemd-Networkd
If you currently have a network running using /etc/network/, move the interfaces file there to another name so that it won't be used after systemd-networkd is set up:mv /etc/network/interfaces /etc/network/interfaces.save
- basic configuration
- enable systemd-networkd
# systemctl status systemd-networkd
● systemd-networkd.service - Network Service
Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service; disabled;
vendor preset: enabled)
Active: inactive (dead)
Docs: man:systemd-networkd.service(8)
# systemctl enable systemd-networkd
Created symlink /etc/systemd/system/dbus-org.freedesktop.network1.service → /usr/lib/systemd/system/systemd-networkd.service.
Created symlink /etc/systemd/system/multi-user.target.wants/systemd-networkd.service → /usr/lib/systemd/system/systemd-networkd.service.
Created symlink /etc/systemd/system/sockets.target.wants/systemd-networkd.socket → /usr/lib/systemd/system/systemd-networkd.socket.
Created symlink /etc/systemd/system/network-online.target.wants/systemd-networkd-wait-online.service → /usr/lib/systemd/system/systemd-networkd-wait-online.
All configuration files are generally stored in /etc/systemd/network. - DHCP
[Match] Name=eth0 [Network] DHCP=ipv4
- define the virtual network device using a br0.netdev file in /etc/systemd/network/
[NetDev] Name=br0 Kind=bridge MACAddress=xx:xx:xx:xx:xx:xx
[Match] Name=eth0 [Network] Bridge=br0
[Match] Name=br0 [Network] DHCP=ipv4Configuring the physical layer.(Network Interface Configuration Files)
In general you don't need a .link file since udev already identifies the device.
However you can configure multiple options here that can't be set elsewhere. The most basic of these is the name.
udev these days does a good job of consistently handling the naming of network devices.
Wired interfaces are usually something like "enp5s0". This is derived from its PCI address:
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
enp5s0 isn't very descriptive if you've got multiple NICs in your system.To give the interface a more descriptive name. Simply create a .network file or a .link file to give it a more descriptive name.
Configuration files for systemd-networkd (and systemd-resolved) can be placed in /usr/lib/systemd/network or /etc/systemd/network.
Files in /etc/systemd/network have a higher priority than the ones in /usr/lib/systemd/network. There are three types of configuration files:
- .link Udev normally assigns network card interface names based on system physical characteristics such as enp2s1.
- Mask udev's .link file for the default policy
If you prefer to use the classic or customized network interface names, there are three alternative ways to do that:
ln -s /dev/null /etc/systemd/network/99-default.link
The link files are read from the files located in:
- /lib/systemd/network the system network directory.
/lib/systemd/network/99-default.link:
[Match] OriginalName=* [Link] NamePolicy=keep kernel database onboard slot path AlternativeNamesPolicy=database onboard slot path MACAddressPolicy=persistent
Files in /etc have the highest priority The link file contains 2 sections:
- [Match] determines if a given link file may be applied to a given device.
- MACAddress= The hardware address.
- OriginalName= A whitespace-separated list of shell-style globs matching the device name, as exposed by the udev property "INTERFACE".
- [Link] specify how the device should be configured.
- Name= The interface name to use in case all the policies specified in NamePolicy= fail, or in case NamePolicy= is missing or disabled. Note that specifying a name that the kernel might use for another interface (for example "eth0") is dangerous because the name assignment done by udev will race with the assignment done by the kernel.
- NamePolicy= An ordered, space-separated list of policies by which the interface name should be set.
- kernel If the kernel claims that the name it has set for a device is predictable, then no renaming is performed.
- Name= The interface name to use in case all the policies specified in NamePolicy= fail, or in case NamePolicy= is missing or disabled.
A link file is said to match a device if each of the entries in the "[Match]" section matches.
The following keys are accepted:
This cannot be used to match on names that have already been changed from userspace.
The "[Link]" section accepts the following keys:
Each of the policies may fail, and the first successful one is used. The name is not set directly, but is exported to udev as the property "ID_NET_NAME", which is, by default, used by a udev rule to set "NAME".
The available policies are:
For example:
cat > /etc/systemd/network/10-ether0.link << "EOF"
[Match]
# Change the MAC address as appropriate for your network device
MACAddress=12:34:45:78:90:AB
[Link]
Name=ether0
EOF
Setting up cloud-init
cloud-init is used to configure the system during installation and first-boot.Here are some examples of how to do common tasks with cloud-init.
create users with cloud-init
- Create a file called meta-data
instance-id: qeum-arm64
local-hostname: qemu
#cloud-config
password: ubuntu
chpasswd: {expire: False}
ssh_pwauth: True
ssh_authorized_keys:
- ssh-rsa AAA...SDvZ user1@domain.com
The final line "ssh_authorized_keys:" above is an SSH public key.SSH public keys are found in ~/.ssh/id_rsa.pub.
Expire the cloud-user’s password so that the user must change it during their first login
- user-data
#cloud-config
password: atomic
chpasswd: {expire: True}
ssh_pwauth: True
ssh_authorized_keys:
- ssh-rsa AAA...SDvz user1@yourdomain.com
- ssh-rsa AAB...QTuo user2@yourdomain.com
Note: This is a global setting.If you set expire to True all users who are created (see below) will have to change their password.
Change the default username
The default username is cloud-user.Add the line user: to the user-data file:
- user-data
#cloud-config
user: ubuntu
password: ubuntu
chpasswd: {expire: False}
ssh_pwauth: True
ssh_authorized_keys:
- ssh-rsa AAA...SDvz user1@yourdomain.com
- ssh-rsa AAB...QTuo user2@yourdomain.com
Set the root password
To set the root password you must create a user list in the chpasswd section of the user-data file.If you use this method to set the user passwords, all passwords must be set in this section. This means that the password: line must be moved from the top and into this section.
- user-data
#cloud-config
ssh_pwauth: True
ssh_authorized_keys:
- ssh-rsa AAA...SDvz user1@yourdomain.com
- ssh-rsa AAB...QTuo user2@yourdomain.com
chpasswd:
list: |
root:ubuntu
cloud-user:ubuntu
expire: False
Snappy Ubuntu Core and cloud-init
cloud-init is installed inside the Snappy image which allows you to customize the instance and automate its startup and configuration.For example, at instance creation time you can specify a snappy application to be installed, cloud-init receives this information from the user in the form of ‘user-data’.
One of the formats that can be fed to cloud-init is called ‘cloud-config’.
cloud-config is yaml formatted data that is interpreted and acted on by cloud-init.
A couple specific configuration values have been aded in the snappy image:
- ssh_enabled Determine if ‘ssh’ service is started or not.
- packages A list of snappy packages to install on first boot.
By default ssh is not enabled.
Items in this list are snappy package names.
When running inside a snappy image, cloud-init still provides many of the features it provides on traditional instances:
- runcmd A list of commands run after boot has been completed.
- If the entry is a string, it is interpreted by ‘sh’.
- If it is a list, it is executed as a command and arguments without shell interpretation.
- ssh_authorized_keys This is a list of strings.
- write_files This allows you to write content to the filesystem.
Commands are run as root.
Each entry in the list can be a string or a list:
Each key present will be put into the default user’s ssh authorized keys file.
Note that ssh authorized keys are also accepted via the cloud’s metadata service.
The module is still expected to work, but the user will have to be aware that much of the filesystem is read-only. Specifically, writing to file system locations that are not writable is expected to fail.
Example Cloud Config
Note that user data intended to be consumed as cloud-config must contain the first line ‘#cloud-config‘.
#cloud-config
snappy:
ssh_enabled: True
packages:
– xkcd-webserver
write_files:
– content: |
#!/bin/sh
echo “==== Hello Snappy! It is now $(date -R) ====”
permissions: ‘0755’
path: /writable/greet
runcmd:
– /writable/greet | tee /run/hello.log
The above user-data(because of #cloud-config) instructed cloud-init to do a number of different things:- instructed cloud-init to install the Snappy ‘xkcd-webserver’ application
- it wrote a file via ‘write_files’ to a writable space on disk
- executed that file with ‘runcmd’
Use Ubuntu Server Cloud Image to Create a KVM Virtual Machine with Fixed Network Properties
To create a KVM VM using Ubuntu server 20.04 cloud image with the following network properties:- a static MAC address
- a pre-defined network interface name
- a static internal IP address
Preparation
- Run the following command to install cloud image management utilities, cloud-image-utils:
$ sudo apt install -y cloud-image-utils
$ sudo apt install -y qemu-kvm libvirt-daemon-system bridge-utils virtinst
$ sudo usermod -aG kvm $USER $ sudo usermod -aG libvirt $USERLog out then log in again.
$ wget https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64.img
$ qemu-img create -F qcow2 -b focal-server-cloudimg-amd64.img -f qcow2 vm01.qcow2 5G $ ls -al total 537872 drwxrwxr-x 2 jerry jerry 4096 二 13 18:02 . drwxrwxr-x 7 jerry jerry 4096 二 4 21:45 .. -rw-rw-r-- 1 jerry jerry 550567936 二 3 07:04 focal-server-cloudimg-amd64.img -rw-r--r-- 1 jerry jerry 196688 二 13 18:02 vm01.qcow2
Network Configuration
- To generate a MAC address and write it to an environment variable, MAC_ADDR For KVM VMs it is required that the first 3 pairs in the MAC address be the sequence 52:54:00.
$RANDOM is an internal Bash function (not a constant) that returns a pseudorandom integer in the range 0 - 32767.
$ export MAC_ADDR=$(printf '52:54:00:%02x:%02x:%02x' $((RANDOM%256)) $((RANDOM%256)) $((RANDOM%256))) $ echo $MAC_ADDR 52:54:00:b0:c7:f1
$ export INTERFACE=enp1s0 $ export IP_ADDR=192.168.122.101
cat > network-config <<EOF
ethernets:
$INTERFACE:
addresses:
- $IP_ADDR/24
dhcp4: false
gateway4: 192.168.122.1
match:
macaddress: $MAC_ADDR
nameservers:
addresses:
- 1.1.1.1
- 8.8.8.8
set-name: $INTERFACE
version: 2
EOF
Cloud-Init Configuration
Basically, user-data is simply user-data and meta-data is a yaml formatted file representing.- Create meta-data:
$ touch meta-data
$ cat > user-data <<EOF
#cloud-config
hostname: vm01
manage_etc_hosts: true
users:
- name: vmadm
sudo: ALL=(ALL) NOPASSWD:ALL
groups: users, admin
home: /home/vmadm
shell: /bin/bash
lock_passwd: false
ssh_pwauth: true
disable_root: false
chpasswd:
list: |
vmadm:vmadm
expire: false
EOF
The filesystem volume label must be cidata or CIDATA. This is usually attached to the VM as a cdrom or transient 2nd vdisk
cloud-localds creates a disk-image with user-data and/or meta-data for cloud-init. user-data can contain everything which is supported by cloud-init.
$ cloud-localds -v --network-config=network-config seed.qcow2 user-data meta-data wrote seed.qcow2 with filesystem=iso9660 and diskformat=rawInformation is consumed from the the root of the ‘cidata’ filesystem:
- meta-data the aggregate of /meta-data and /network-config
- user-data /user-data.
Provision a New Guest VM (NoCloud)
Creating Virtual machine can be done via virt-manager or virt-install command.- start the VM virt-install is a command line tool for creating new KVM , Xen, or Linux container guests using the "libvirt" hypervisor management library.
- --connect [hostname-or-URI] The hypervisor connection URI specifies how to connect to the hypervisor.
- qemu:///system connects locally as the root user to the daemon supervising guest virtual machines on the KVM hypervisor.
- qemu:///session connects locally as a user to the user's set of guest local machines using the KVM hypervisor.
- lxc:/// connects to a local Linux container
- --virt-type The hypervisor to install on.
- --name NAME Name of the new guest virtual machine instance.
- --memory OPTIONS Memory to allocate for the guest, in MiB.
- --vcpus OPTIONS Number of virtual cpus to configure for the guest.
- --import Skip the OS installation process, and build a guest around an existing disk image.
- --disk OPTIONS Specifies media to use as storage for the guest.
The guest can be configured to use one or more virtual disks, network interfaces, audio devices, physical USB or PCI devices, among others.
Options:
The most commonly used URIs are:
The device used for booting is the first device specified via "--disk" or "--filesystem".
The general format of a disk string is
--disk opt1=val1,opt2=val2,...
There are various options:
- path A path to some storage media to use, existing or not. Existing media can be a file or block device.
- size size (in GiB) to use if creating new storage
- device Disk device type.
Example values are be 'cdrom', 'disk', 'lun' or 'floppy'.
The default is 'disk'.
The value for "NETWORK" can take one of 4 formats:
- network=NAME Connect to a virtual network in the host called "NAME".
- bridge=BRIDGE Connect to a bridge device in the host called "BRIDGE".
- type=direct,source=IFACE[,source.mode=MODE] Direct connect to host interface IFACE using macvtap.
- user
- none Tell virt-install not to add any default network interface.
Virtual networks can be listed, created, deleted using the "virsh" command line tool.
In an unmodified install of "libvirt" there is usually a virtual network with a name of "default".
Use a virtual network if the host has dynamic networking (eg NetworkManager), or using wireless. The guest will be NATed to the LAN by whichever connection is active.
Use this option if the host has static networking config and the guest requires full outbound and inbound connectivity to/from the LAN.
Also use this if live migration will be used with this guest.
The default behaviour is to launch virt-viewer(1) to display the graphical console, or to run the "virsh console" command to display the text console.
$ virt-install --connect qemu:///system
--virt-type kvm
--name vm01
--ram 2048
--vcpus=2
--os-type linux
--os-variant ubuntu20.04
--disk path=/home/jerry/work/iso/vm01.qcow2,device=disk
--disk path=/home/jerry/work/iso/seed.qcow2,device=disk
--import
--network network=default,model=virtio,mac=$MAC_ADDR
--noautoconsol
Starting install...
Domain creation completed.
$ virsh list Id Name State ---------------------- 1 vm01 running
$ virsh console vm01 vm01 login: vmadm Password:
$ ssh vmadm@192.168.122.101
$ virsh destroy vm01 $ virsh undefine vm01
Cloud Instance Initialization with cloud-init
An OS and its cloud must share some critical configuration data which tells the OS how to behave in its particular environment.By separating configuration data, one can avoid the tight coupling of OS and cloud.
cloud-init provides a mechanism for separating out configuration data from the OS.
Introduction
cloud-init enables the automated provisioning of a basic OS image into a fully running state, complete with required access and applications.Typical initialzation tasks handled by cloud-init:
- networking
- stoage
- package installation
- user account creation
- security key provisioning for remote access
Instance Initialization
An individual running system on a cloud is typically composed of:- disk image The OS to be deployed. Many OS's have cloud-init pre-installed for cloud images.
- metadata Each cloud provider produces metadata which is used for setting up the instance.
The source and format of the metadat varies from cloud to cloud.
Some clouds use a drive attached to the instance, others use networking APIs.
After deployment, the metadata can be queried :
cloud-init query ds.meta_data
{
"dsmode": "net",
"instance_id": "nocloud"
}
This data can be a simple script file or a structured cloud-config file which uses cloud-init's built-in config modules.
cloud-init
cloud-init Documentation
Cloud-init is the method for cloud instance initialization.Cloud instances are initialized from a disk image with instance data:
- Cloud metadata
- User data (optional)
- Vendor data (optional)
Cloud-init will identify the cloud which the cloud instance is running on during boot, read any provided metadata from the cloud and initialize the system accordingly.
This may involve : setting up the network and storage devices to configuring SSH access key and many other aspects of a system.
Boot Stages
In order to be able to provide the functionality that it does, cloud-init must be integrated into the boot in fairly controlled way.There are five stages :
- Generator When booting under systemd, a generator will run that determines if cloud-init.target should be included in the boot goals.
- The file /etc/cloud/cloud-init.disabled exists
- The kernel command line as found in /proc/cmdline contains cloud-init=disabled. When running in a container, the kernel command line is not honored, but cloud-init will read an environment variable named KERNEL_CMDLINE in its place.
- Local The systemd service cloud-init-local.service runs as soon as possible with / mounted read-write.
- locate “local” data sources
- apply networking configuration to the system (including “Fallback”)
- datasource cloud provided network configuration via metadata
- fallback cloud-init’s fallback networking consists of rendering the equivalent to “dhcp on eth0”, which was historically the most popular mechanism for network configuration of a guest
- none network configuration can be disabled by writing the file /etc/cloud/cloud.cfg with the content: network: {config: disabled}
- Network The systemd service, cloud-init.service runs after local stage and configured networking is up.
- Config The systemd service cloud-config.service runs after network.
- Final The systemd service cloud-final.service as final part of boot (traditional “rc.local”).
It will not enable cloud-init if either:
These mechanisms for disabling cloud-init at runtime currently only exist in systemd.
In most cases, this stage does :
Cloud-init then exits and expects for the continued boot of the operating system to bring network up as configured settings.
This stage requires all configured networking to be online, as it will fully process any user-data that is found.
First Boot Determination
cloud-init has to determine whether or not the current boot is the first boot of a new instance or not, so that it applies the appropriate configuration.- On an instance’s first boot, it should run all “per-instance” configuration
- On a subsequent boot it should run only “per-boot” configuration.
By checking the instance ID in the cache against the instance ID it determines at runtime, cloud-init determines which case it is running.
Internally, cloud-init refers to this behavior as check. cloud-init exposes the manual_cache_clean configuration option:
- false (the default) cloud-init will check and clean the cache if the instance IDs do not match
- true cloud-init will trust the existing cache (and therefore not clean it).
CLI Interface
$ cloud-init --helpAn overview of each of the subcommands
- analyze Analyze cloud-init logs and data.
- blame report ordered by most costly operations
- dump machine-readable JSON dump of all cloud-init tracked events
- show show time-ordered report of the cost of operations during each boot stage
- boot show timestamps from kernel initialization, kernel finish initialization, and cloud-init start
- clean Remove cloud-init artifacts from /var/lib/cloud to simulate a clean instance.
- collect-logs Collect and tar cloud-init generated logs, data files, and system information for triage.
- devel
- features
- init
- modules
- query
- single
- status
Possible subcommands include:
FAQ
Where are the logs?
- /var/log/cloud-init-output.log captures the output from each stage of cloud-init when it runs
- /var/log/cloud-init.log very detailed log with debugging output, detailing each action taken
- /run/cloud-init contains logs about how cloud-init decided to enable or disable itself, as well as what platforms/datasources were detected. These logs are most useful when trying to determine what cloud-init ran or did not run.
Where are the configuration files?
These files can define the modules that run during instance initialization, the datasources to evaluate on boot, and other settings.- /etc/cloud/cloud.cfg
- /etc/cloud/cloud.cfg.d/*.cfg
Where are the data files?
- /var/lib/cloud/instance/ This is a symbolic link that points to the most recenlty used instance-id directory. This folder contains the information cloud-init received from datasources, including vendor and user data.
- /var/lib/cloud/data/ This directory contain information related to the previous boot
What datasource am I using?
To find what datasource is getting used$ cloud-idIf the cloud-id is not what is expected, run the scrip to debug it:
$ sudo DEBUG_LEVEL=2 DI_LOG=stderr /usr/lib/cloud-init/ds-identify --force
Debug
$ sudo DI_LOG=stderr /usr/lib/cloud-init/ds-identify --force $ sudo cloud-init clean --logs $ sudo cloud-init init --local $ sudo cloud-init initThese commands will re-run cloud-init as if this were first boot of a system.
Two of the most common issues with user data, that also happens to be cloud-config is:
- Incorrectly formatted YAML
- First line does not contain #cloud-config
User-Data Formats
Cloud config examples
Modules
Merging User-Data Sections
Instance
Datasources
Vendor Data
Network Configuration
Default Behavior
Cloud-init searches for network configuration in order of increasing precedence; each item overriding the previous:- Datasource For example, OpenStack may provide network config in the MetaData Service
- System Config All files with the '.cfg' extension in /etc/cloud/cloud.cfg.d/* will be read by cloud-init.
- Kernel Command Line One of the following 2 ways:
- ip=
- network-config=<Base64 encoded YAML config string>
Disabling Network Configuration
Users may disable Cloud-init ‘s network configuration capability and rely on other methods, such as embedded configuration or other customizations.Cloud-init supports the following methods for disabling cloud-init‘s network configuration capability :
- Kernel Command Line
network-config=disabled
network: config: disabledIf Cloud-init ‘s networking config has not been disabled, and no other network information is found, then it will proceed to generate a fallback networking configuration.
Fallback Network Configuration
Cloud-init will attempt to determine which of any attached network devices is most likely to have a connection and then generate a network configuration to issue a DHCP request on that interface.After selecting the “right” interface, a configuration is generated and applied to the system.
Network Configuration Sources
Cloud-init accepts a number of different network configuration formats in support of different cloud substrates.- Config Drive
- Digital Ocean
- OpenNebula
- OpenStack
- SmartOS Datasource
- UpCloud
- NoCloud The data source NoCloud allows the user to provide user-data and meta-data to the instance without having a network at all.
- provide meta-data and user-data to a local VM boot via files on a vfat or iso9660 filesystem The filesystem volume label must be cidata or CIDATA.
- provide meta-data via kernel command line The parameter must be passed in one of the following forms:
- ds=nocloud[;key=val;key=val]
- ds=nocloud-net[;key=val;key=val]
- h or local-hostname
- i or instance-id
- s or seedfrom
- With ds=nocloud, the seedfrom value must start with / or file://
- With ds=nocloud-net, the seedfrom value must start with http:// or https://.
This can be provided by 2 ways:
The following renderers (configurations) are supported in cloud-init with the order of preference:
- ENI /etc/network/interfaces or ENI is supported by the ifupdown package
- Sysconfig Sysconfig format is used by RHEL, CentOS, Fedora and other derivatives.
- Netplan netplan consumes Networking Config Version 2 input and renders network configuration for supported backends such as systemd-networkd and NetworkManager.
system_info:
network:
renderers: ['netplan', 'eni', 'sysconfig']
KVM: Testing cloud-init locally using KVM for an Ubuntu cloud image
Prerequisites
Install the tool managing cloud-images$ sudo apt install -y cloud-image-utilsDownload the Ubuntu cloud image
$ wget https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64.img
Create cloud-init configuration
Create a file named “cloud_init.cfg”: (refer to Modules)
#cloud-config
hostname: test1
fqdn: test1.example.com
manage_etc_hosts: true
users:
- name: ubuntu
sudo: ALL=(ALL) NOPASSWD:ALL
groups: users, admin
home: /home/ubuntu
shell: /bin/bash
lock_passwd: false
ssh-authorized-keys:
- <sshPUBKEY>
# only cert auth via ssh (console access can still login)
ssh_pwauth: false
disable_root: false
chpasswd:
list: |
ubuntu:linux
expire: False
packages:
- qemu-guest-agent
# written to /var/log/cloud-init-output.log
final_message: "The system is finally up, after $UPTIME seconds"
Then replace the “<sshPUBKEY>” placeholder in the file above, with the content of “id_rsa.pub”.
Create network configuration
Create a file named “network_config_static.cfg” to define the networking parameters.
version: 2
ethernets:
ens3:
dhcp4: false
# default libvirt network
addresses: [ 192.168.122.158/24 ]
gateway4: 192.168.122.1
nameservers:
addresses: [ 192.168.122.1,8.8.8.8 ]
search: [ example.com ]
Insert metadata into seed image
# insert network and cloud config into seed image cloud-localds -v --network-config=network_config_static.cfg test1-seed.img cloud_init.cfg # show seed disk just generated $ qemu-img info test1-seed.imgcloud-localds:
Usage: cloud-localds [ options ] output user-data [meta-data]
Create a disk for cloud-init to utilize nocloud
options:
-h | --help show usage
-d | --disk-format D disk format to output. default: raw
can be anything supported by qemu-img or
tar, tar-seed-local, tar-seed-net
-H | --hostname H set hostname in metadata to H
-f | --filesystem F filesystem format (vfat or iso), default: iso9660
-i | --interfaces F write network interfaces file into metadata
-N | --network-config F write network config file to local datasource
-m | --dsmode M add 'dsmode' ('local' or 'net') to the metadata
default in cloud-init is 'net', meaning network is
required.
-V | --vendor-data F vendor-data file
-v | --verbose increase verbosity
Note, --dsmode, --hostname, and --interfaces are incompatible
with metadata.
Example:
* cat my-user-data
#cloud-config
password: passw0rd
chpasswd: { expire: False }
ssh_pwauth: True
* echo "instance-id: $(uuidgen || echo i-abcdefg)" > my-meta-data
* cloud-localds my-seed.img my-user-data my-meta-data
* kvm -net nic -net user,hostfwd=tcp::2222-:22 \
-drive file=disk1.img,if=virtio -drive file=my-seed.img,if=virtio
* ssh -p 2222 ubuntu@localhost
Start VM
virt-install --name test1 \ --virt-type kvm --memory 2048 --vcpus 2 \ --boot hd,menu=on \ --disk path=test1-seed.img,device=cdrom \ --disk path=snapshot-bionic-server-cloudimg.qcow2,device=disk \ --graphics vnc \ --os-type Linux --os-variant ubuntu18.04 \ --network network:default \ --console pty,target_type=serialAfter the machine has booted up and you have given cloud-init a couple of minutes to configure networking, you should be able to login to this guest OS from either virt-viewer or ssh.
ssh ubuntu@192.168.122.158 -i id_rsa # final cloud-init status cat /run/cloud-init/result.json # cloud logs vi /var/log/cloud-init.log vi /var/log/cloud-init-output.log
netplan
Netplan configuration examples
Configuration
To configure netplan, save configuration files under /etc/netplan/ with a .yaml extension (e.g. /etc/netplan/config.yaml), then run sudo netplan apply. This command parses and applies the configuration to the system.Configuration written to disk under /etc/netplan/ will persist between reboots.
Network - Configuration
Ethernet Interface Logical Names
As boot processes became less linear and interfaces became more hotpluggable this became more of a concern.For ex., eth0 and eth1 might switch places on successive boots.
The classic naming scheme for network interfaces applied by the kernel is to simply assign names beginning with "eth0", "eth1", ... to all interfaces as they are probed by the drivers.
But these names do not necessarily correspond to actual labels on the chassis.
In recent Linux distribution, systemd/udev will automatically assign predictable, stable network interface names for all local Ethernet, WLAN and WWAN interfaces.
The default is to assign fixed names based on firmware, topology, and location information.
Assigning fixed names based on firmware/topology/location information has the big advantage that the names are fully automatic, fully predictable, that they stay fixed even if hardware is added or removed.
With systemd (v 197), the following different naming schemes for network interfaces are now supported by udev natively:
- Firmware or BIOS provided index numbers for on-board devices example: eno1
- Firmware or BIOS provided PCI Express hotplug slot index numbers example: ens1
- physical/geographical location information of the connector of the hardware example: enp2s0
- interface's MAC address example: enx78e7d1ea46da
- unpredictable kernel naming scheme if all other methods fail (example: enp1s0)
That means,
- if the system has biosdevname installed, it will take precedence. This requires passing biosdevname=1 as a kernel command-line parameter.
- if the user has added udev rules which change the name of the kernel devices these will take precedence
- any distribution specific naming schemes generally take precedence.
HowTo Change Network Interface Name in Linux Permanently:
- Find the the ports you wish to change their names Collect the device information for matching.
$ ifconfig
Add the following line per device.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="7c:fe:90:cb:76:02", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
Interface logical names can also be configured via a netplan configuration.
If you would like control which interface receives a particular logical name use the match and set-name keys.
network:
version: 2
renderer: networkd
ethernets:
eth_lan0:
dhcp4: true
match:
macaddress: 00:11:22:33:44:55
set-name: eth_lan0
- The match key is used to find an adapter based on some criteria like MAC address, driver, etc.
- Then the set-name key can be used to change the device to the desired logial name.
Ethernet Interface Settings
Aapplication that can help identify all network interfaces available to your system:- lshw lshw is a small tool to extract detailed information on the hardware configuration of the machine.
It currently supports DMI (x86 and IA-64 only), OpenFirmware device tree (PowerPC only), PCI/AGP, CPUID (x86), IDE/ATA/ATAPI, PCMCIA (only tested on x86), SCSI and USB.
$ sudo lshw -class network
$ sudo ethtool enp3s0
IP settings
- configure an IP address
$ sudo ip addr add 10.102.66.200/24 dev enp0s25
$ sudo ip link set dev enp0s25 up
$ sudo ip link set dev enp0s25 down
$ sudo ip route add default via 10.102.66.1
在 QEMU 使用 Ubuntu Cloud Images
Cloud Image 是已經預先裝好作業系統的磁碟映像.
一些 Cloud Image 像是 Ubuntu Cloud Image 會在初始化時執行 cloud-init。
The Ubuntu cloud images are pre-installed images that allow your to boot directly without doing the usual desktop system installation.
- 下載 Ubuntu Cloud Images focal-server-cloudimg-amd64.img
- 製作供 cloud-init 使用的映像檔 用data source NoCloud 來設定 cloud-init，需要一個 ISO 檔，它的 volume label（掛載之後顯示的名稱）要是 cidata 或 CIDATA，裡面要包含 2 個檔案：
- meta-data
- user-data
- 安裝 cloud-utils cloud-localds 指令包含在 cloud-utils 套件中.
sudo apt install cloud-image-utils
#cloud-config
password: 你的密碼
chpasswd: { expire: False }
ssh_pwauth: True
登入帳號是 ubuntu，密碼是你設定的密碼。
cloud-localds seed.iso user-data.txtcloud-localds 在製作映像檔時可以自己產生預設的 meta-data 檔，所以不用提供。
{
"instance-id": "iid-local01"
}
genisoimage -output seed.iso -volid cidata -joliet -rock user-data meta-data
- Back up the original images
$ cp ~/work/imgs/focal-server-cloudimg-amd64.img .
$ ls -l focal-server-cloudimg-amd64.img -rw-rw-r-- 1 jerry jerry 552468480 Feb 22 08:29 focal-server-cloudimg-amd64.img $ qemu-img resize focal-server-cloudimg-amd64.img 8G
- Use virt-install
virt-install \ --name ubuntu20.04 \ --memory 512 \ --disk focal-server-cloudimg-amd64.img,device=disk,bus=virtio \ --disk seed.iso,device=cdrom \ --os-type linux \ --os-variant ubuntu20.04 \ --virt-type kvm \ --graphics none \ --network network=default,model=virtio \ --import
- "New Virtual Machine"
- "Import existing disk image"
- "Provide the existing storage path" to the image
- "Choose Memory and CPU settings"
- "Ready to begin the installation" Click "Customize configuration before install" and "Finish":
- Click "Add Hardware"
- Finish
- click "Begin Installation"
Introduction to AppArmor
Using NetworkManager and ModemManager in Linux to automatically establish and maintain a connection
This will show how to set up NetworkManager to automatically configure, establish and maintain the cellular data connection in your system.NetworkManager and ModemManager are open source tool for Linux to manage several types of networks and interfaces such as ethernet, wifi, etc. It can also manage cellular WWAN interfaces through the ModemManager tool.
It is hosted by the Freedesktop.org community and driven by Aleksander Morgado and other contributors. please visit https://wiki.gnome.org/Projects/NetworkManager and https://www.freedesktop.org/wiki/Software/ModemManager/ for latest information.
ModemManager is capable of communicating over several types of device control channels such as QMI/RMNET, MBIM, MODEM / AT command etc.
Installation
$ apt install network-manager $ NetworkManager -V $ ModemManager -VBoth NetworkManager and ModemManager have command line interfaces (nmcli and mmcli respectively) where you can interact with the management tools.
Have ModemManager list all the cellular device it has detected:
$ mmcli --list-modemsGeneral details and status of the modem can be listed with:
$ mmcli --modem=0Check if the cellular device is managed by NetworkManager :
$ nmcli device statusNow you should create a connection profile in NetworkManager for your specific network carrier and SIM card with the "nmcli connection add" command:
留言