How to configure the linux

Network Configuration

Ubuntu ships with a number of graphical utilities to configure your network devices. This document is geared toward server administrators and will focus on managing your network on the command line.

Ethernet Interfaces

Ethernet interfaces are identified by the system using predictable network interface names. These names can appear as eno1 or enp0s25. However, in some cases an interface may still use the kernel eth# style of naming.

Identify Ethernet Interfaces

To quickly identify all available Ethernet interfaces, you can use the ip command as shown below.

Another application that can help identify all network interfaces available to your system is the lshw command. This command provides greater details around the hardware capabilities of specific adapters. In the example below, lshw shows a single Ethernet interface with the logical name of eth0 along with bus information, driver details and all supported capabilities.

Ethernet Interface Logical Names

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. 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

ethtool is a program that displays and changes Ethernet card settings such as auto-negotiation, port speed, duplex mode, and Wake-on-LAN. The following is an example of how to view supported features and configured settings of an Ethernet interface.

IP Addressing

The following section describes the process of configuring your systems IP address and default gateway needed for communicating on a local area network and the Internet.

Temporary IP Address Assignment

For temporary network configurations, you can use the ip command which is also found on most other GNU/Linux operating systems. The ip command allows you to configure settings which take effect immediately, however they are not persistent and will be lost after a reboot.

To temporarily configure an IP address, you can use the ip command in the following manner. Modify the IP address and subnet mask to match your network requirements.

The ip can then be used to set the link up or down.

To verify the IP address configuration of enp0s25, you can use the ip command in the following manner.

To configure a default gateway, you can use the ip command in the following manner. Modify the default gateway address to match your network requirements.

To verify your default gateway configuration, you can use the ip command in the following manner.

If you require DNS for your temporary network configuration, you can add DNS server IP addresses in the file /etc/resolv.conf . In general, editing /etc/resolv.conf directly is not recommanded, but this is a temporary and non-persistent configuration. The example below shows how to enter two DNS servers to /etc/resolv.conf , which should be changed to servers appropriate for your network. A more lengthy description of the proper persistent way to do DNS client configuration is in a following section.

If you no longer need this configuration and wish to purge all IP configuration from an interface, you can use the ip command with the flush option as shown below.

Flushing the IP configuration using the ip command does not clear the contents of /etc/resolv.conf . You must remove or modify those entries manually, or re-boot which should also cause /etc/resolv.conf , which is a symlink to /run/systemd/resolve/stub-resolv.conf , to be re-written.

Dynamic IP Address Assignment (DHCP Client)

To configure your server to use DHCP for dynamic address assignment, create a netplan configuration in the file /etc/netplan/99_config.yaml . The example below assumes you are configuring your first Ethernet interface identified as enp3s0.

The configuration can then be applied using the netplan command.

Static IP Address Assignment

To configure your system to use static address assignment, create a netplan configuration in the file /etc/netplan/99_config.yaml . The example below assumes you are configuring your first Ethernet interface identified as eth0. Change the addresses, gateway4, and nameservers values to meet the requirements of your network.

The configuration can then be applied using the netplan command.

Loopback Interface

The loopback interface is identified by the system as lo and has a default IP address of 127.0.0.1. It can be viewed using the ip command.

Name Resolution

Name resolution as it relates to IP networking is the process of mapping IP addresses to hostnames, making it easier to identify resources on a network. The following section will explain how to properly configure your system for name resolution using DNS and static hostname records.

DNS Client Configuration

Traditionally, the file /etc/resolv.conf was a static configuration file that rarely needed to be changed or automatically changed via DCHP client hooks. Systemd-resolved handles name server configuration, and it should be interacted with through the systemd-resolve command. Netplan configures systemd-resolved to generate a list of nameservers and domains to put in /etc/resolv.conf , which is a symlink:

To configure the resolver, add the IP addresses of the nameservers that are appropriate for your network to the netplan configuration file. You can also add an optional DNS suffix search-lists to match your network domain names. The resulting file might look like the following:

The search option can also be used with multiple domain names so that DNS queries will be appended in the order in which they are entered. For example, your network may have multiple sub-domains to search; a parent domain of example.com , and two sub-domains, sales.example.com and dev.example.com .

If you have multiple domains you wish to search, your configuration might look like the following:

If you try to ping a host with the name of server1, your system will automatically query DNS for its Fully Qualified Domain Name (FQDN) in the following order:

If no matches are found, the DNS server will provide a result of notfound and the DNS query will fail.

Static Hostnames

Static hostnames are locally defined hostname-to-IP mappings located in the file /etc/hosts . Entries in the hosts file will have precedence over DNS by default. This means that if your system tries to resolve a hostname and it matches an entry in /etc/hosts, it will not attempt to look up the record in DNS. In some configurations, especially when Internet access is not required, servers that communicate with a limited number of resources can be conveniently set to use static hostnames instead of DNS.

The following is an example of a hosts file where a number of local servers have been identified by simple hostnames, aliases and their equivalent Fully Qualified Domain Names (FQDN’s).

In the above example, notice that each of the servers have been given aliases in addition to their proper names and FQDN’s. Server1 has been mapped to the name vpn, server2 is referred to as mail, server3 as www, and server4 as file.

Name Service Switch Configuration

The order in which your system selects a method of resolving hostnames to IP addresses is controlled by the Name Service Switch (NSS) configuration file /etc/nsswitch.conf . As mentioned in the previous section, typically static hostnames defined in the systems /etc/hosts file have precedence over names resolved from DNS. The following is an example of the line responsible for this order of hostname lookups in the file /etc/nsswitch.conf .

files first tries to resolve static hostnames located in /etc/hosts .

mdns4_minimal attempts to resolve the name using Multicast DNS.

[NOTFOUND=return] means that any response of notfound by the preceding mdns4_minimal process should be treated as authoritative and that the system should not try to continue hunting for an answer.

dns represents a legacy unicast DNS query.

mdns4 represents a Multicast DNS query.

To modify the order of the above mentioned name resolution methods, you can simply change the hosts: string to the value of your choosing. For example, if you prefer to use legacy Unicast DNS versus Multicast DNS, you can change the string in /etc/nsswitch.conf as shown below.

Bridging

Bridging multiple interfaces is a more advanced configuration, but is very useful in multiple scenarios. One scenario is setting up a bridge with multiple network interfaces, then using a firewall to filter traffic between two network segments. Another scenario is using bridge on a system with one interface to allow virtual machines direct access to the outside network. The following example covers the latter scenario.

Configure the bridge by editing your netplan configuration found in /etc/netplan/ :

Enter the appropriate values for your physical interface and network.

Now apply the configuration to enable the bridge:

The new bridge interface should now be up and running. The brctl provides useful information about the state of the bridge, controls which interfaces are part of the bridge, etc. See man brctl for more information.

networkd-dispatcher for pre-up, post-up, etc. hook scripts

Users of the former ifupdown may be familiar with using hook scripts (e.g pre-up, post-up, etc.) in their interfaces file. Netplan configuration does not currently support hook scripts in its configuration definition.

Instead to achieve this functionality with the networkd renderer , users can use networkd-dispatcher. The package provides users and packages hook points when specific network states are reached to aid in reacting to network state.

Note: If not on Ubuntu Server, but Desktop the network is driven by Network Manager — in that case you’d need NM Dispatcher scripts instead.

The Netplan FAQ has a great table that compares event timings between ifupdown / systemd-networkd / network-manager

It is important to be aware that those hooks run asychronous; that is they will not block transition into another state.

The Netplan FAQ also has an example on converting an old ifupdown hook to networkd-dispatcher .

Resources

The Ubuntu Wiki Network page has links to articles covering more advanced network configuration.

The netplan website has additional examples and documentation.

The netplan man page has more information on netplan.

The systemd-resolved man page has more information on systemd-resolved service.

Источник

How to configure the Linux kernel

This Howto shows you what each Linux kernel option is used for. The Linux kernel has hundreds of options and setting, this howto attempts to describe them. To learn howto compile the kernel see Howto compile the Linux Kernel.

Know your hardware

There are thousands of configuration options, so its a good idea to start with what you know you need and what you know you don’t need.

A good way to find what you have is to use the lspci , and lsusb commands. This will show you the name and model of your components. The Kernel configuration names are not always obvious, so these commands help you decipher the names.

• Creative Labs Sound Blaster PCI 128 is called
  • (Creative) Ensoniq AudioPCI 1370

Things you usually need

• Second extended fs support
• Ext3 journaling file system support
• ..

Things you usually don’t need

• I2O support
• ISDN support
• Dallas’s 1-wire support
• Memory Technology Device (MTD) support
• Support for Large Block Devices
• Instrumentation Support
• Kernel hacking
• Amateur Radio support
• InfiniBand support
• and any hardware that you obviously don’t have

Config Methods

1. console based: make menuconfig
2. (GUI) Qt Based: make xconfig
3. (GUI) GTK Based: make gconfig

Other

1. keep old Kernels settings: make oldconfig less screen Clutter: make silentoldconfig
2. edit the /usr/src/Linux/.config file manually

Configurations

This section explains all the configuration options. The are many. The Linux tree structure is organized and the extracted Linux source directory structure. The Menuconfig tree structure is as you would see using make menuconfig

Источник

How to configure networking on Linux

Subscribe now

Get the highlights in your inbox every week.

Connecting your Linux computer to a network is pretty straightforward, except when it is not. In this article I discuss the main network configuration files for Red Hat-based Linux distributions, and take a look at the two network startup services: the venerable network startup, and the controversial NetworkManager.

Linux easily manages multiple network interface adapters. Laptops typically include both wired and wireless interfaces, and may also support WiMax interfaces for cellular networks. Linux desktop computers also support multiple network interfaces, and you can use your Linux computer as a multi-network client, or as a router for internal networks; such is the case with a couple of my own systems.

Interface configuration files

Every network interface has its own configuration file in the /etc/sysconfig/network-scripts directory. Each interface has a configuration file named ifcfg- X, where X is the number of the interface, starting with zero or 1 depending upon the naming convention in use; for example /etc/sysconfig/network-scripts/ ifcfg-eth0 for the first Ethernet interface.

Most of the other files in the /etc/sysconfig/network-scripts directory are scripts used to start, stop and perform various network configuration activities.

Each interface configuration file is bound to a specific physical network interface by the MAC address of the interface.

Network interface naming conventions

The naming conventions for network interfaces used to be simple, uncomplicated, and, I thought, easy. Using ethX made sense to me and was easy to type. It did not require extra steps to figure out what long and obscure name belonged to an interface. Unfortunately, adding a new interface often forced the renaming of network interfaces, which broke scripts and configurations. That has all changed, more than once.

After a short stint with some long and unintelligible network interface names, we now have a third set of naming conventions which seem only marginally better. Names like ethX are still used by CentOS 6.x. The newest naming conventions, with names like eno1 and enp0s3 are used by RHEL 7, CentOS 7, and more recent releases of Fedora. The interface naming convention for RHEL 6 and CentOS 6 is described in Appendix A. Consistent Network Device Naming of the Red Hat Deployment Guide. RHEL 7, CentOS 7, and current versions of Fedora are described in Chapter 8. Consistent Network Device Naming of the Red Hat Networking Guide.

Configuration file examples

This example network interface configuration file, ifcfg-eth0, defines a static IP address configuration for a CentOS 6 server installation.

This file starts the interface on boot, assigns it a static IP address, defines a domain and network gateway, specifies two DNS servers, and does not allow non-root users to start and stop the interface.

The following interface configuration file, ifcfg-eno1, provides a DHCP configuration for a desktop workstation.

In this second configuration file example, the DHCP entries, IP address, the search domain, and all other network information are not defined because they are supplied by the DHCP server. Configuration items like the DNS servers can be overridden in the interface configuration file by adding DNS1 and DNS2 lines, as in the previous static configuration example.

Note that this second example contains a UUID line. As far as I can determine, this line has no effect on the functionality of the configuration file. I usually comment it out or even delete it and have never experienced a detrimental effect on my network.

In both interface configuration files, the HWADDR line specifies the MAC address of the physical network interface. This binds the physical interface to the interface configuration file. You must change the MAC address in the file if you replace the interface.

There are a couple ways to locate the MAC address of a NIC. I usually use the ifconfig command which shows all installed NICs, thier MAC address and various statistics. Many new NICs have their MAC address printed on the box or labelled on the NIC itself. However, most interface configuration files are generated automatically during installation or when the NIC is first detected after being newly installed, and the MAC address is included as part of the new interface configuration file.

The ONBOOT line specifies that the interface is to be activated at startup time. If this line is changed to «no» the interface will have to be activated either manually, or by NetworkManager after a user logs in.

The USERCTL line specifies that non-privileged users cannot manage the interface; that is they cannot turn it on and off. Setting this parameter to «yes» allows regular users to activate and deactivate the interface.

Notice that the lines in the interface configuration files are not sequence-sensitive, and work just fine in any order. By convention, the option names are in uppercase and the values are in lowercase. Option values can be enclosed in quotes, but that is not necessary unless the value is more than a single word or number.

Configuration options

There are many configuration options for the interface configuration files. These are some of the more common options:

• DEVICE: The logical name of the device, such as eth0 or enp0s2.
• HWADDR: The MAC address of the NIC that is bound to the file, such as 00:16:76:02:BA:DB
• ONBOOT: Start the network on this device when the host boots. Options are yes/no. This is typically set to «no» and the network does not start until a user logs in to the desktop. If you need the network to start when no one is logged in, set this to «yes».
• IPADDR: The IP Address assigned to this NIC such as 192.168.0.10
• BROADCAST: The broadcast address for this network such as 192.168.0.255
• NETMASK: The netmask for this subnet such as the class C mask 255.255.255.0
• NETWORK: The network ID for this subnet such as the class C ID 192.168.0.0
• SEARCH: The DNS domain name to search when doing lookups on unqualified hostnames such as «example.com»
• BOOTPROTO: The boot protocol for this interface. Options are static, DHCP, bootp, none. The «none» option defaults to static.
• GATEWAY: The network router or default gateway for this subnet, such as 192.168.0.254
• ETHTOOL_OPTS: This option is used to set specific interface configuration items for the network interface, such as speed, duplex state, and autonegotiation state. Because this option has several independent values, the values should be enclosed in a single set of quotes, such as: «autoneg off speed 100 duplex full».
• DNS1: The primary DNS server, such as 192.168.0.254, which is a server on the local network. The DNS servers specified here are added to the /etc/resolv.conf file when using NetworkManager, or when the peerdns directive is set to yes, otherwise the DNS servers must be added to /etc/resolv.conf manually and are ignored here.
• DNS2: The secondary DNS server, for example 8.8.8.8, which is one of the free Google DNS servers. Note that a tertiary DNS server is not supported in the interface configuration files, although a third may be configured in a non-volatile resolv.conf file.
• TYPE: Type of network, usually Ethernet. The only other value I have ever seen here was Token Ring but that is now mostly irrelevant.
• PEERDNS: The yes option indicates that /etc/resolv.conf is to be modified by inserting the DNS server entries specified by DNS1 and DNS2 options in this file. «No» means do not alter the resolv.conf file. «Yes» is the default when DHCP is specified in the BOOTPROTO line.
• USERCTL: Specifies whether non-privileged users may start and stop this interface. Options are yes/no.
• IPV6INIT: Specifies whether IPV6 protocols are applied to this interface. Options are yes/no.

If the DHCP option is specified, most of the other options are ignored. The only required options are BOOTPROTO, ONBOOT and HWADDR. Other options that you might find useful, that are not ignored, are the DNS and PEERDNS options if you want to override the DNS entries supplied by the DHCP server.

The deprecated network file

There is one old and now deprecated file you might encounter. The network file usually contains only a single comment line for current releases of Fedora, RHEL, and CentOS. It is located in /etc/sysconfig and was used in the past to enable or disable networking. It was also used to set the networking host name as shown in the following example:

This file has been present but unused in Fedora since release 19. It is still used in RHEL/CentOS 6.x, but is no longer used in RHEL/CentOS 7.x. The network hostname is now set in the /etc/hostname file.

Other network files

The /etc/sysconfig/network-files directory contains many other files, all of which are usually executable BASH scripts rather than configuration files. This is, to me at least, one of the bothersome exceptions to the Linux Filesystem Hierarchical Standard (FHS) which explicitly states that only configuration files and not executable files are to be located in the /etc tree.

One other network configuration file you might find in /etc/sysconfig/network-files is the route- file. If you want to set up static routes on a multi-homed system, create a route file for each interface. For example, the following file is named route-eth0, and defines routes for that specific interface to both networks and individual hosts.

The use of this file is uncommon, unless you are using the host as a router with some complex routing needs. See the Networking Guide for your version of Red Hat Enterprise Linux or CentOS for more details on configuring routing.

Network startup

With the advent of wireless networks and mobile devices, reconfiguring the network interfaces for each new wireless network became complicated and time-consuming. It may also create naming conflicts when adding a new network interface.

network

The old network service was used by default on Red Hat based distributions until 2004 to manage network startup and stop tasks. A SystemV start script used static configuration files to start the wired or wireless network at boot time, or with a simple command like service network start command from the command line. This service is still available, although the commands are redirected through systemd.

The network service is unable to monitor pluggable devices or changing wireless networks, so it cannot be used easily on laptops or netbook-style computers.

There were also issues with configuring wired networks with laptops, and servers or desktops with multiple network interfaces. I encountered problems when replacing a defective interface in a host with multiple network interfaces, as the interface name often changed during system startup.

NetworkManager

Red Hat introduced NetworkManager in 2004 to simplify and automate network configuration and connections, especially wireless connections. The intent is to prevent the user from having to manually configure each new wireless network. Although it is intended to make network management easier for non-technical users, it requires some adjustment by the Linux administrator because many of the familiar configuration functions are now handled by a new layer of configuration files and scripts. This means that the standard configuration files are subject to being overwritten by NetworkManager every time the network is restarted, including every reboot.

The udev daemon is a kernel device manager which is supposed to provide consistent and persistent device naming for all devices, including network devices and removable mass storage devices. It is also used to match network device names, i.e., eth0 or eno1, for example, to the MAC address on the network interface.

How it works, sort of

The udev device manager detects when a new device has been added to the system, such as a new network interface, and creates a rule to identify and name it if one does not already exist. The details of how this works have changed in more recent versions of Fedora, CentOS and RHEL. The current device naming procedure is described in detail in the RHEL 7 Networking Guide, along with a description of how the names are derived.

The current convention is to use the contents of the interface configuration files to generate the rules. However, if an interface configuration file does not exist, plugging in a new device or connecting with a new wireless network causes udev to notify NetworkManager of the new device or wireless connectrion. NetworkManager then creates the new interface configuration file.
The udev daemon creates an entry for each network interface in the network rules file. NetworkManager uses these entries, along with information in the interface configuration files in the /etc/sysconfig/network-scripts/ directory to initialize each interface.

Admins’ choice

It is possible to use the older network service and disable NetworkManager. There are plenty of howtos that describe how to disable NetworkManager and return to using the network service, including this one, so I won’t go into those details here.
I personally recommend against returning to the older network service because, once I understood how NetworkManager and udev work together provide a consistent naming scheme and automatic configuration for both existing and new devices, it all made sense and made managing network interfaces easier. In my opinion, NetworkManager is the best of both worlds.

As always with Linux, the decision of which service to use is your choice.

Источник