With this option, the command will list available extensions for your system. You can use the output to find a product identifier for product activation.

Use this option to specify a product for activation. The product identifier has the following format: <name>/<version>/<architecture>, for example, sle-module-live-patching/15.3/x86_64. The appropriate command will then be the following:

# transactional-update register -p sle-module-live-patching/15.3/x86_64

Register your system with the provided registration code. The command will register the subscription and enable software repositories.

The option deregisters the system, or when used along with the -p option, deregisters an extension.

Specify an email address that will be used in SUSE Customer Center for registration.

Specify the URL of your registration server. The URL is stored in the configuration and will be used in subsequent command invocations. For example:

# transactional-update register --url https://scc.suse.com

Displays the current registration status in JSON format.

Writes the provided options value to the /etc/SUSEConnect configuration file.

Removes old system credentials.

Prints the version.

Displays the usage of the command.

This is the netmask AND any address in the network, as shown in Example 5.2, “Linking IP addresses to the netmask” under Result. This address cannot be assigned to any hosts.

This could be paraphrased as: “Access all hosts in this subnet.” To generate this, the netmask is inverted in binary form and linked to the base network address with a logical OR. The above example therefore results in 192.168.0.255. This address cannot be assigned to any hosts.

The address 127.0.0.1 is assigned to the “loopback device” on each host. A connection can be set up to your own machine with this address and with all addresses from the complete 127.0.0.0/8 loopback network as defined with IPv4. With IPv6 there is only one loopback address (::1).

IPv6 makes the network “plug and play” capable, which means that a newly configured system integrates into the (local) network without any manual configuration. The new host uses its automatic configuration mechanism to derive its own address from the information made available by the neighboring routers, relying on a protocol called the neighbor discovery (ND) protocol. This method does not require any intervention on the administrator's part and there is no need to maintain a central server for address allocation—an additional advantage over IPv4, where automatic address allocation requires a DHCP server.

Nevertheless if a router is connected to a switch, the router should send periodic advertisements with flags telling the hosts of a network how they should interact with each other. For more information, see RFC 2462 and the radvd.conf(5) man page, and RFC 3315.

IPv6 makes it possible to assign several addresses to one network interface at the same time. This allows users to access several networks easily, something that could be compared with the international roaming services offered by mobile phone companies. When you take your mobile phone abroad, the phone automatically logs in to a foreign service when it enters the corresponding area, so you can be reached under the same number everywhere and can place an outgoing call, as you would in your home area.

With IPv4, network security is an add-on function. IPv6 includes IPsec as one of its core features, allowing systems to communicate over a secure tunnel to avoid eavesdropping by outsiders on the Internet.

Realistically, it would be impossible to switch the entire Internet from IPv4 to IPv6 at one time. Therefore, it is crucial that both protocols can coexist not only on the Internet, but also on one system. This is ensured by compatible addresses (IPv4 addresses can easily be translated into IPv6 addresses) and by using several tunnels. See Section 5.2.3, “Coexistence of IPv4 and IPv6”. Also, systems can rely on a dual stack IP technique to support both protocols at the same time, meaning that they have two network stacks that are completely separate, such that there is no interference between the two protocol versions.

Addresses of this type are associated with exactly one network interface. Packets with such an address are delivered to only one destination. Accordingly, unicast addresses are used to transfer packets to individual hosts on the local network or the Internet.

Addresses of this type relate to a group of network interfaces. Packets with such an address are delivered to all destinations that belong to the group. Multicast addresses are mainly used by certain network services to communicate with certain groups of hosts in a well-directed manner.

Addresses of this type are related to a group of interfaces. Packets with such an address are delivered to the member of the group that is closest to the sender, according to the principles of the underlying routing protocol. Anycast addresses are used to make it easier for hosts to find out about servers offering certain services in the given network area. All servers of the same type have the same anycast address. Whenever a host requests a service, it receives a reply from the server with the closest location, as determined by the routing protocol. If this server should fail for some reason, the protocol automatically selects the second closest server, then the third one, and so forth.

IPv4 addresses and IPv4 over IPv6 compatibility addresses. These are used to maintain compatibility with IPv4. Their use still requires a router able to translate IPv6 packets into IPv4 packets. Several special addresses, such as the one for the loopback device, have this prefix as well.

Aggregatable global unicast addresses. As is the case with IPv4, an interface can be assigned to form part of a certain subnet. Currently, there are the following address spaces: 2001::/16 (production quality address space) and 2002::/16 (6to4 address space).

Link-local addresses. Addresses with this prefix should not be routed and should therefore only be reachable from within the same subnet.

Site-local addresses. These may be routed, but only within the network of the organization to which they belong. In effect, they are the IPv6 equivalent of the current private network address space, such as 10.x.x.x.

These are multicast addresses.

The first part (which also contains one of the prefixes mentioned above) is used to route packets through the public Internet. It includes information about the company or institution that provides the Internet access.

The second part contains routing information about the subnet to which to deliver the packet.

The third part identifies the interface to which to deliver the packet. This also allows for the MAC to form part of the address. Given that the MAC is a globally unique, fixed identifier coded into the device by the hardware maker, the configuration procedure is substantially simplified. In fact, the first 64 address bits are consolidated to form the EUI-64 token, with the last 48 bits taken from the MAC, and the remaining 24 bits containing special information about the token type. This also makes it possible to assign an EUI-64 token to interfaces that do not have a MAC, such as those based on point-to-point protocol (PPP).

This address is used by the host as its source address when the interface is initialized for the first time (at which point, the address cannot yet be determined by other means).

The address of the loopback device.

The IPv6 address is formed by the IPv4 address and a prefix consisting of 96 zero bits. This type of compatibility address is used for tunneling (see Section 5.2.3, “Coexistence of IPv4 and IPv6”) to allow IPv4 and IPv6 hosts to communicate with others operating in a pure IPv4 environment.

This type of address specifies a pure IPv4 address in IPv6 notation.

There are two address types for local use:

IPv6 packets are automatically encapsulated as IPv4 packets and sent over an IPv4 network capable of multicasting. IPv6 is tricked into seeing the whole network (Internet) as a huge local area network (LAN). This makes it possible to determine the receiving end of the IPv4 tunnel automatically. However, this method does not scale very well and is also hampered because IP multicasting is far from widespread on the Internet. Therefore, it only provides a solution for smaller corporate or institutional networks where multicasting can be enabled. The specifications for this method are laid down in RFC 2529.

With this method, IPv4 addresses are automatically generated from IPv6 addresses, enabling isolated IPv6 hosts to communicate over an IPv4 network. However, several problems have been reported regarding the communication between those isolated IPv6 hosts and the Internet. The method is described in RFC 3056.

This method relies on special servers that provide dedicated tunnels for IPv6 hosts. It is described in RFC 3053.

the command will stop its run to ask for any missing arguments, for example, for a password to connect to a network.

controls the color output: yes to enable the colors, no to disable them, and auto creates color output only when the standard output is directed to a terminal.

switches between table (each line describes a single entry, columns define particular properties of the entry) and multiline (each entry comprises more lines, each property is on its own line). tabular is the default value.

prints help.

sets a time-out period for which to wait for NetworkManager to finish operations. Using this option is recommended for commands that might take longer to complete, for example, connection activation.

to list connections:

# nmcli connection show

You can also use this command to show details about a specified connection:

# nmcli connection show CONNECTION_ID

where CONNECTION_ID is any of the identifiers: a connection name, UUID, or a path

to activate the provided connection. Use the command to reload a connection. Also run this command after you perform any change to the connection.

# nmcli connection up [--active] [CONNECTION_ID]

When --active is specified, only the active profiles are displayed. The default is to display both active connections and static configuration.

to deactivate a connection.

# nmcli connection down CONNECTION_ID

where: CONNECTION_ID is any of the identifiers: a connection name, UUID, or a path

If you deactivate the connection, it will not reconnect later even if it has the autoconnect flag.

to change or delete a property of a connection.

# nmcli connection modify CONNECTION_ID SETTING.PROPERTY PROPERTY_VALUE

where:

The following example deactivates the autoconnect option on the ethernet1 connection:

# nmcli connection modify ethernet1 connection.autoconnect no

to add a connection with the provided details. The command syntax is similar to the modify command:

# nmcli connection add CONNECTION_ID save YES|NO SETTING.PROPERTY PROPERTY_VALUE

You should at least specify a connection.type or use type. The following example adds an Ethernet connection tied to the eth0 interface with DHCP, and disables the connection's autoconnect flag:

# nmcli connection add type ethernet autoconnect no ifname eth0

to edit an existing connection using an interactive editor.

# nmcli connection edit CONNECTION_ID

to clone an already existing connection. The minimal syntax follows:

# nmcli connection clone CONNECTION_ID NEW_NAME

where CONNECTION_ID is the connection to be cloned.

to delete an existing connection:

# nmcli connection delete CONNECTION_ID

to monitor the provided connection. Each time the connection changes, NetworkManager prints a line.

# nmcli connection monitor CONNECTION_ID

to reload all connection files from the disk. As NetworkManager does not monitor changes performed to the connection files, you need to use this command whenever you make changes to the files. This command does not take any further subcommands.

to load/reload a particular connection file, run:

# nmcli connection load CONNECTION_FILE

to print the status of all devices.

# nmcli device status

shows detailed information about a device. If no device is specified, all devices are displayed.

# mcli device show [DEVICE_NAME]

to connect a device. NetworkManager tries to find a suitable connection that will be activated. If there is no compatible connection, a new profile is created.

# nmcli device connect DEVICE_NAME

performs temporary changes to the configuration that is active on the particular device. The changes are not stored in the connection profile.

# nmcli device modify DEVICE_NAME [+|-] SETTING.PROPERTY VALUE

For possible SETTING.PROPERTY values, refer to nm-settings-nmcli(5).

The example below starts the IPv4 shared connection sharing on the device con1.

# nmcli dev modify con1 ipv4.method shared

disconnects a device and prevents the device from automatically activating further connections without manual intervention.

# nmcli device disconnect DEVICE_NAME

to delete the interface from the system. You can use the command to delete only software devices like bonds and bridges. You cannot delete hardware devices with this command.

# nmcli device DEVICE_NAME

lists all available access points.

# nmcli device wifi

connects to a Wi-Fi network specified by its SSID or BSSID. The command takes the following options:

# nmcli device wifi connect SSID [password PASSWORD_VALUE] [ifname INTERFACE_NAME]

To connect to a Wi-Fi GUESTWiFi with a password pass$word2#@@, run:

# nmcli device wifi connect GUESTWiFi password pass$word2#@@

displays the overall status of NetworkManager. Whenever you do not specify a command to the nmcli general command, status is used by default.

# nmcli general status

if you do not provide a new host name as an argument, the current host name is displayed. If you specify a new host name, the value will be used to set a new value.

# nmcli general hostname [HOSTNAME]

For example, to set MyHostname, run:

# nmcli general hostname MyHostname

shows your permission for NetworkManager operations like enabling or disabling networking, modifying connections, etc.

# nmcli general permissions

shows and changes NetworkManager logging levels and domains. Without any arguments, the command displays current logging levels and domains.

# nmcli general logging [level LEVEL domains DOMAIN]

LEVEL is any of the values: OFF, ERR, WARN, INFO, DEBUG, or TRACE.

DOMAIN is a list of values that can be as follows: 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.

enables or disables networking. The off command deactivates all interfaces managed by NetworkManager.

# nmcli networking on

displays the network connectivity state. If check is used, NetworkManager performs a new check of the state. Otherwise, the last detected state is displayed.

# nmcli networking connectivity

Possible states are the following:

Use the minimal option (-m):

# supportconfig -m

If you have already localized a problem that relates to a specific area or feature set only, you should limit the collected information to the specific area for the next supportconfig run. For example, you have detected problems with LVM and want to test a recent change that you introduced to the LVM configuration. In this case, it makes sense to gather the minimum Supportconfig information around LVM only:

# supportconfig -i LVM

Additional keywords can be separated with commas. For example, an additional disk test:

# supportconfig -i LVM,DISK

For a complete list of feature keywords that you can use for limiting the collected information to a specific area, run:

# supportconfig -F

# supportconfig -E tux@example.org -N "Tux Penguin" -O "Penguin Inc." ...

(all in one line)

# supportconfig -l

This is especially useful in high-logging environments or after a kernel crash when syslog rotates the log files after a reboot.

Contains the date when this script was executed and system information like version of the distribution, hypervisor information, and more.

Contains some basic health checks like uptime, virtual memory statistics, free memory and hard disk, checks for zombie processes, and more.

Contains basic hardware checks like information about the CPU architecture, list of all connected hardware, interrupts, I/O ports, kernel boot messages, and more.

Contains log messages from the system journal.

Contains a list of all installed RPM packages, their names and versions and where they come from.

Contains information in XML format, such as distribution, version and product-specific fragments.

Contains information about the supportconfig script itself.

Contains YaST-specific information like specific packages, configuration files and log files.