Administering Network Interfaces and Network Clients - RHCSA Section - RHCSA & RHCE Red Hat Enterprise Linux 7: Training and Exam Preparation Guide (EX200 and EX300), Third Edition (2015)

RHCSA & RHCE Red Hat Enterprise Linux 7: Training and Exam Preparation Guide (EX200 and EX300), Third Edition (2015)

Part I. RHCSA Section

Chapter 12. Administering Network Interfaces and Network Clients

This chapter describes the following major topics:

· Basic networking including hostname, IPv4, IPv6, network classes, subnet, subnet mask, protocol, TCP/UDP, Ethernet addresses, and ARP

· Understand network interfaces and consistent interface naming

· Comprehend interface configuration files, hosts table, and management commands

· Overview of NetworkManager

· Configure a network interface manually and with NetworkManager

· Use ping to test connectivity

· Manage network interfaces via Graphical Network Administration tool

· Configure a system to get time from NTP servers

· OpenLDAP concepts, terminology, roles, and client packages

· Understand OpenLDAP client configuration files

· Configure OpenLDAP client with authconfig tool

· Overview of Graphical Authentication Configuration tool

RHCSA Objectives:

31. Configure networking and hostname resolution statically or dynamically

40. Configure a system to use time services

47. Configure a system to use an existing authentication service for user and group information

Acomputer network is a group of two or more physical or virtual computers connected together to share their resources and data. The computers may be interlinked via wired or wireless means, and a device such as a switch is required to interconnect several computers so that they can communicate with one another on the network.

To comprehend how networks work and how network services are configured properly, some basic networking terminology needs to be understood first. For a system to be able to talk to other networked systems, one of its network interfaces must be configured with a unique IP address, hostname, and other essential network parameters. Several files are involved for the interface configuration, which may be modified by hand or by using commands and graphical tools. After networking has been configured, testing is done to confirm the system’s ability to communicate with other systems on the network.

NTP is a networking protocol that allows a system to synchronize its clock with a more reliable source of time in order for time-sensitive applications running on the system to function accurately.

OpenLDAP is an open source implementation of LDAP. In order for a system to have its users authenticated by a remote OpenLDAP server and to obtain other directory information, the OpenLDAP client functionality needs to be configured on the system. There are certain configuration files that are modified for this purpose, and they may be edited manually, or via commands and graphical tools.

Basic Networking

There are many basic concepts and terms that you need to grasp before being able to configure network interfaces and perform advanced network client and server setups. Likewise, there are also many configuration files and commands related to various network services that you need to thoroughly understand. Some of the concepts, terms, configuration files, and commands are explained in this chapter, and many more will be introduced in the RHCE section of this book.

Hostname

A hostname is a unique alphanumeric label (the dash, underscore, and dot characters are also allowed) that is assigned to a system to identify it on the network. It can consists of up to 64 characters. It is normally allotted based on the purpose and primary use of the system. In RHEL7, the hostname is stored in the /etc/hostname file.

The hostname of a system can be viewed with the use of several different commands, such as hostname, hostnamectl, and uname. We can also display the contents of the /etc/hostname file where the hostname is stored. Moreover, the NetworkManager service is also available to show us the hostname at the command prompt, in text mode, and in graphical mode.

# hostname

server1.example.com

# hostnamectl | grep hostname

Static hostname: server1.example.com

# uname –n

server1

# cat /etc/hostname

server1.example.com

# nmcli general hostname

server1.example.com

Similarly, the hostname can be changed using any of the methods mentioned above, except for the uname command. The hostname command allows you to rename the hostname temporarily. For instance, to rename server1.example.com to server10.example.com, run this command as follows:

# hostname server10.example.com

The hostnamectl command changes the hostname on a permanent basis. The following renames server10.example.com to server100.example.com:

# hostnamectl set-hostname server100.example.com

Alternatively, you can simply edit the /etc/hostname file and make the desired change in it. After saving the file and exiting the editor, restart the systemd-hostnamed service for this permanent change to take effect right away. The following changes the hostname back to server1.example.com:

# vi /etc/hostname

server1.example.com

# systemctl restart systemd-hostnamed

Do not forget to update the /etc/hosts file to reflect the new hostname.

The NetworkManager can also be used to change the hostname via its command line interface (nmcli) or text interface (nmtui).

IPv4 Address

IPv4 stands for Internet Protocol version 4 and it represents a unique 32-bit software address that every single system on the network must have in order to communicate with other systems. It was the first version of IP that was released for public use. IPv4 addresses can be assigned on a temporary or permanent basis. Temporary addresses are referred to as dynamic addresses and are typically leased from a DHCP server for a specific period of time. Permanent addresses, on the other hand, are called static addresses and are set either manually or using the NetworkManager service. Permanent addresses are typically not changed unless there is a need.

We use the ip command with the addr argument to view current IP assignments on our system:

# ip addr

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo

valid_lft forever preferred_lft forever

inet6 ::1/128 scope host

valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000

link/ether 52:54:00:17:91:8d brd ff:ff:ff:ff:ff:ff

inet 192.168.0.110/24 brd 192.168.0.255 scope global eth0

valid_lft forever preferred_lft forever

inet6 fe80::5054:ff:fe17:918d/64 scope link

valid_lft forever preferred_lft forever

ImagesWe can also use the ifconfig command to obtain this information, but this command is deprecated in RHEL7 and will be removed from a future RHEL release.

The above output indicates the presence of one configured network interface called eth0 on the system with IPv4 address 192.168.0.110 assigned to it. The other interface, called lo, is a special purpose software interface reserved for use on every UNIX and Linux system. Its IPv4 address is always 127.0.0.1 and it is referred to as the system’s loopback (or localhost) address. This hostname is used by network applications to access the networking resources on the local system.

Network Classes

An IP address is comprised of four dot-separated octets that are divided into a network portion and a node portion. The network portion identifies the correct destination network and the node portion identifies the correct destination node on that network. Network addresses are classified into three classes, referred to as class A, class B, and class C. Classes D and E are also defined and in use; however, their use is limited to special areas such as scientific and engineering.

ImagesA node is any device on the network with an IP address. Examples include computers, storage devices, routers, switches, hand-held devices, printers, and so on.

Class A addresses are used for large networks with up to 16 million nodes. The network address range for class A networks is between 1 and 126. This class uses the first octet as the network portion and the rest of the octets as the node portion.

Class B addresses are used for mid-sized networks with up to 65 thousand nodes. The network address range for class B networks is between 128 and 191. This class uses the first two octets as the network portion and the other two octets as the node portion.

Class C addresses are used for small networks with up to 254 nodes. The network address range for class C networks is between 192 and 223. This class uses the first three octets as the network portion and the last octet as the node portion.

Subnetting and Subnet Mask

Subnetting is a method by which a large network address space can be divided into several smaller and more manageable logical sub-networks, commonly referred to as subnets. Subnetting usually results in reduced network traffic, improved network performance, and de-centralized and easier administration, among other benefits.

The following should be kept in mind when dealing with subnetting:

· Subnetting does not increase the number of IP addresses in a network. In fact, it reduces the number of usable IP addresses.

· All nodes in a given subnet have the same subnet mask.

· Each subnet acts as an isolated network and requires a router to talk to other subnets.

· The first and the last IP address in a subnet are reserved. The first address points to the subnet itself and the last address is the broadcast address.

After a given address has been subnetted, we determine something called subnet mask or netmask. The subnet mask is the network portion plus the subnet bits. In other words, the subnet mask segregates the network bits from the node bits. It is used by routers to identify the start and end of the network/subnet portion and the start and end of the node portion for a given IP address.

The default subnet masks for class A, B, and C networks are 255.0.0.0, 255.255.0.0, and 255.255.255.0, respectively.

Protocol

A protocol is a set of rules governing the exchange of data between two networked entities. These rules include how data is formatted, coded, and controlled. The rules also provide error handling, speed matching, and data packet sequencing. In other words, a protocol is a common language that all nodes on the network speak and understand. Some common protocols are TCP, UDP, IP, and ICMP. Protocols are defined in the /etc/protocols file. An excerpt from this file is provided below:

Images

TCP and UDP Protocols

Two key protocols besides IP are TCP and UDP. TCP is reliable, connection-oriented, and point-to-point. When a stream of packets is sent to the destination node using the TCP protocol, the destination node checks for errors and packet sequencing upon its arrival. Each packet contains information such as the IP addresses for the source and destination systems, port numbers, data, a sequence number, and checksum fields. The TCP protocol at the source node establishes a point-to-point connection with the peer TCP protocol at the destination. When the packet is received by the receiving TCP, an acknowledgment is returned. If the packet contains an error or is lost in transit, the destination node requests the source node to resend the packet. This ensures guaranteed data delivery and makes TCP reliable.

UDP, on the other hand, is unreliable, connectionless, and multi-point. If a packet is lost or contains errors upon arrival at the destination, the source node is unaware of it. The destination node does not send an acknowledgment back to the source node. UDP is normally used for broadcast purposes.

Both TCP and UDP protocols use ports for data transmission between a client and its associated server program. Ports are defined in the /etc/services file. Some common services and the ports they listen on are: ftp 21, ssh 22, postfix 25, http 80, and ntp 123. An excerpt from the /etc/services file is shown below:

Images

Ethernet Address and Address Resolution Protocol

An Ethernet address represents a unique 48-bit address that is used to identify the correct destination node for data packets transmitted from the source node. The data packets include Ethernet addresses for both the source and the destination node. A network protocol called ARP, maps the Ethernet address to the destination node’s IP address. The Ethernet address is also referred to as the hardware, physical, link layer, or MAC address.

We can use the ip command to list all network interfaces available on the system along with their hardware addresses:

# ip addr | grep ether

link/ether 52:54:00:17:91:8d brd ff:ff:ff:ff:ff:ff

IP and Ethernet addresses work hand in hand, and a combination of both is critical to identifying the correct destination node on the network. A protocol called Address Resolution Protocol (ARP) is used to enable IP and hardware addresses to work together. ARP determines the hardware address of the destination node when its IP address is already known.

ARP broadcasts messages over the network requesting each alive neighbor to reply with its link layer and IP addresses. The addresses received are cached locally on the node, and can be viewed using the ip command with the neighbor argument:

Images

ImagesWe can also use the arp command to obtain this information, but this command is now obsolete.

The above output shows IP addresses of the neighbors in the first column followed by the interface devices that they are using, their link layer addresses, and their NUD (Nieghbor Unreachability Detection) states. A neighbor can be in one of four states: permanent, noarp, reachable, and stale. The permanent state indicates a valid entry that can only be deleted manually, the noarp state designates a valid entry that expires at the end of its lifetime, the reachable state shows a valid entry that expires when its reachability timeout expires, and the stale state specifies a valid but suspicious entry.

Network Interfaces

Network Interface Cards are the hardware adapters that provide one or more Ethernet ports for network connectivity, and they are abbreviated as NICs. NICs may also be referred to as network adapters and individual ports as network interfaces or simply interfaces. NICs may be built-in to the system board or are add-on adapters. They are available in one to four port configuration on a single adapter. Two or more interfaces can be configured to provide bonding and teaming for redundancy and faster throughput. Individual interfaces as well as bonding and teaming can be configured with IPv4 and IPv6 assignments by editing files, or using either commands or the NetworkManager toolset. Additional tasks such as activating and deactivating them manually and auto-activating them at system reboots can also be performed with these tools. We discuss interface configuration and their administration in this chapter; bonding and teaming are RHCE topics and are covered in Chapter 15 “Configuring Bonding, Teaming, IPv6, and Routing”.

Consistent Interface Naming

In earlier RHEL versions, network interfaces were named eth (Ethernet), em (embedded), and wlan (wireless lan) and were numbered beginning at 0 as the interfaces were discovered during a system boot. This was the default interface naming scheme that had been in place for years. Given a large number of interfaces located onboard and on add-on NIC adapters, these number assignments could possibly change on the next boot, resulting in all kinds of connectivity and system operational issues. As of RHEL7, the default naming scheme is now based on several rules governed by systemd and udevd, which assign names based on BIOS/topology/location information. The key rules are presented below for Ethernet interfaces and are applied in the order in which they are listed. These rules are applicable to wireless adapters as well.

1. Onboard interfaces at firmware/BIOS-supplied index numbers (e.g. eno1).

2. Interfaces at PCI Express hotplug slot numbers (e.g. ens3).

3. Adapters in the specified PCI slot, with slot index number on the adapter (e.g. enp3s0).

4. If the above rules are disabled or the information furnished by firmware/BIOS is invalid, the system reverts to the traditional ethX convention.

This advanced ruleset has resulted in consistent naming, eliminating the odds of re-enumeration during a hardware rescan. Moreover, the assigned names are not affected by the addition or removal of interface cards. This naming scheme helps in identifying, configuring, troubleshooting, and replacing the right adapter without hassle.

In order to apply the above naming, we need to ensure that the biosdevname software package is removed from the system and no custom udev rules are in place for interface naming.

Understanding Interface Configuration File

Each network interface has a configuration file that stores IP assignments and other relevant parameters for the interface. The system reads this file and applies the settings at the time the interface is activated. Configuration files for all interfaces are stored at a central location, which is the/etc/sysconfig/network-scripts directory. The interface file names begin with ifcfg- and is followed by the name of the interface by which the system recognizes it. Some instances of interface file names are ifcfg-eth0, ifcfg-enp0s3, ifcfg-br0, and ifcfg-em1.

On server1 and server2, we used eth0 for the interface that we had configured at the time of installation as we picked up the virtual bridge br0 for the default interface. If we had chosen ‘default NAT’, the interface name would have been ens3 as the default.

The current contents of the ifcfg-eth0 file from server1 are presented below:

# cat /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE="eth0"

ONBOOT=yes

NETBOOT=yes

UUID="0764d665-dd86-4001-bdc5-3b280d32a11d"

IPV6INIT=yes

BOOTPROTO=none

TYPE=Ethernet

NAME="eth0"

HWADDR=52:54:00:17:91:8D

IPADDR0=192.168.0.110

PREFIX0=24

GATEWAY0=192.168.0.1

DEFROUTE=yes

IPV4_FAILURE_FATAL=no

IPV6_AUTOCONF=yes

IPV6_DEFROUTE=yes

IPV6_FAILURE_FATAL=no

IPV6_PEERDNS=yes

IPV6_PEERROUTES=yes

These and a few other directives that can be defined in this file are described in Table 12-1.

Directive

Description

BOOTPROTO

Defines the boot protocol to be used. Values include “dhcp” to obtain IP from a DHCP server, “bootp” to boot off of a network boot server and get IP, and “none” or “static” to use a static IP set with the IPADDR directive.

BRIDGE

Specifies the name of the network bridge to be used. On host1, we created br0 in Chapter 06 “Configuring Server Virtualization and Network Installing RHEL7”.

BROADCAST0

Sets the broadcast IP address for the first IP on this interface.

DEFROUTE

Whether to use this interface as the default route.

DEVICE

Specifies the device name for the network interface.

DNS1

Places an entry for the first DNS server in the /etc/resolv.conf file if PEERDNS directive is set to “yes” in this file.

GATEWAY0

Specifies the gateway address for the first IP on this interface.

HWADDR

Describes the hardware address for this interface.

IPADDR0

Specifies the IP for this interface.

IPV6INIT

Whether to enable IPv6 support for this interface.

NAME

Any description given to this interface.

NETMASK0

Sets the netmask address for the first IP on this interface.

NM_CONTROLLED

Whether the NetworkManager service is allowed to modify the configuration in this file. Default is yes.

ONBOOT

Whether to activate this interface at system boot.

PEERDNS

Whether to modify the DNS client resolver file /etc/resolv.conf. Default is “yes” if BOOTPROTO=dhcp is set.

USERCTL

Whether to allow non-root users to activate this interface.

UUID

The UUID associated with this interface.

TYPE

Specifies the type of this interface.

Table 12-1 Network Interface Configuration File

Understanding the Hosts Table

Each IP configured on an interface has a hostname assigned to it. In an environment with multiple networked systems, it is prudent to have some kind of hostname to IP resolution in place to avoid typing the destination system IP over and over when we need to access it. DNS is one such method. It is designed for large networks such as corporate networks and the Internet. For small, internal networks, the use of a local host table (the /etc/hosts file) is more common. This table is used to maintain hostname to IP mapping for all systems on the local network, allowing us access to a system by simply typing its hostname. From the standpoint of this book, we have three systems in place: host1.example.com with IP 192.168.0.100 and alias host1; server1.example.com with IP 192.168.0.110 and alias server1; and server2.example.com with IP 192.168.0.120 and alias server2. We can append this IP and hostname information to the /etc/hosts file as shown below:

192.168.0.100

host1.example.com

host1

192.168.0.110

server1.example.com

server1

192.168.0.120

server2.example.com

server2

Each row in the file contains an IP address in the first column followed by the official (or canonical) hostname in the second column, and one or more aliases subsequently. The official hostname and one or more aliases give us the flexibility of accessing a system using any of these names.

EXAM TIP: In the presence of an active DNS with all hostnames resolvable, there is no need to worry about updating the hosts file.

As indicated above, the hosts file is normally used on small networks only, and therefore must be updated on each individual system to reflect changes.

Interface Administration Commands

There are several commands available to administer network interfaces. The NetworkManager service includes a toolset for this purpose as well, which provides us with access to a command line interface and a text interface. Table 12-2 lists and describes the commands and the NetworkManager tools.

Command

Description

ifdown / ifup

Deactivates / activates an interface.

ip

A powerful tool for administering interfaces, routing, etc. It is a replacement for ifconfig and netstat obsoleted commands.

nm-connection-editor

A graphical tool for interface administration.

Network Settings

A graphical connection status and network administration tool.

NetworkManager Tools

nmcli

A command line tool for interface administration.

nmtui

A text-based tool for interface administration.

Table 12-2 Network Interface Administration Tools

What is NetworkManager?

NetworkManager is the default interface configuration and monitoring service available in RHEL7. It has a daemon program called NetworkManager that dynamically keeps configured interfaces up and active. It has a set of client programs for managing network interfaces and controlling the service itself from the command line (nmcli) or via the text tool (nmtui). The availability of these tools is dependent on the presence of NetworkManager and NetworkManager-tui software packages on the system. By default, the NetworkManager service is enabled and active.

The nmcli utility is powerful and has many options available for effective interface administration. Its text equivalent is nmtui, which also allows us to add, modify, and delete an interface connection, activate and deactivate an interface, and change the hostname of the system. The main window, as depicted in Figure 12-1, appears when we issue nmtui at the command prompt:

Images

Figure 12-1 NetworkManager TUI

This tool updates appropriate files on the system for any operations that we perform.

Exercise 12-1: Present, Configure, and Activate a Network Interface Manually

This exercise should be done on host1 and server1.

In this exercise, you will add a new network interface to the virtual machine hosting server1, with the source device “Host device em1 (Bridge ‘br0’)”, default MAC address, and device model virtio. On server1, you will call this interface eth1 and manually assign the IP 192.168.0.111/24 for temporary use. You will copy the ifcfg-eth0 file in the /etc/sysconfig/network-scripts directory as ifcfg-eth1 and modify it. You will set this interface to autoactivate at system reboots. You will deactivate and reactivate this interface at the command prompt. You will reboot server1 and verify the persistence of IP assignments for this new interface. You will assign it hostname server1ipv4.example.com and alias server1ipv4 and update the hosts file accordingly.

1. Open the virtual console for server1 on host1. Click “Show virtual hardware details” | Add Hardware | Network. Select host device “Host device em1 (Bridge ‘br0’)” from the drop-down list and device model virtio. Leave the MAC address to the default. Click Finish to complete the new interface assignment.

2. Log on to server1 as root and run the ip command to look for the new interface:

# ip addr

…… . .

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000

link/ether 52:54:00:39:16:9a brd ff:ff:ff:ff:ff:ff

The output indicates the presence of a new interface by the name eth1.

3. Assign IP 192.168.0.111/24 to eth1:

# ip addr add 192.168.0.111/24 broadcast 192.168.0.255 dev eth1

4. Verify the new IP assignments on eth1:

# ip addr

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000

link/ether 52:54:00:39:16:9a brd ff:ff:ff:ff:ff:ff

inet 192.168.0.111/24 brd 192.168.0.255 scope global eth1

valid_lft forever preferred_lft forever

At this point, if you reboot server1, this IP information will be lost. You need to configure the settings in a file for persistence.

5. Copy the ifcfg-eth0 file as ifcfg-eth1 in the /etc/sysconfig/network-scripts directory:

# cd /etc/sysconfig/network-scripts

# cp ifcfg-eth0 ifcfg-eth1

6. Open ifcfg-eth1 in a text editor and modify the contents accordingly. On my server1, it will look as shown below:

# vi ifcfg-eth1

DEVICE="eth1"

ONBOOT=yes

NETBOOT=yes

IPV6INIT=yes

BOOTPROTO=none

TYPE=Ethernet

NAME="eth1"

IPADDR0=192.168.0.111

PREFIX0=24

GATEWAY0=192.168.0.1

DEFROUTE=yes

IPV4_FAILURE_FATAL=no

IPV6_AUTOCONF=yes

IPV6_DEFROUTE=yes

IPV6_FAILURE_FATAL=no

HWADDR=52:54:00:39:16:9A

IPV6_PEERDNS=yes

IPV6_PEERROUTES=yes

7. Deactivate this interface and then reactivate using the ifdown and ifup commands:

# ifdown eth1

# ifup eth1

Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/2)

8. Reboot the system:

# reboot

9. Verify the presence of eth1 assignments:

# ip addr

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000

link/ether 52:54:00:39:16:9a brd ff:ff:ff:ff:ff:ff

inet 192.168.0.111/24 brd 192.168.0.255 scope global eth1

valid_lft forever preferred_lft forever

10. Open the hosts file and append the following entry to it:

# vi /etc/hosts

192.168.0.111 server1ipv4.example.com server1ipv4

You can use puTTY in Windows and attempt to access the server using this new IP.

The nmcli Command

The nmcli command is a NetworkManager service tool, which allows us to create, view, modify, remove, activate, and deactivate network interfaces, and control and report their status. This tool operates on one of five objects at a time, with each object supporting several options to form a complete command. The five objects are general, networking, radio, connection, and device. For our purposes, the objects connection and device are important, and are described in Table 12-3.

Object

Description

Connection: activates, deactivates, and administers network connections.

show

Lists connection profiles.

up / down

Activates/deactivates a connection.

add

Adds a connection.

edit

Edits an existing connection or adds a new one.

modify

Modifies one or more properties in the connection profile.

delete

Deletes a connection.

reload

Instructs NetworkManager to re-read all interface configuration files.

load

Instructs NetworkManager to re-read the specified interface configuration file.

Device: displays and administers network interfaces.

status

Displays device status.

show

Displays detailed information about all or the specified interface.

Table 12-3 Network Interface Administration Tools

Objects may be abbreviated. For instance, the connection object may be specified as a ‘c’ or ‘con’. Similarly, the device object can be abbreviated as a ‘d’ or ‘dev’.

Exercise 12-2: Present, Configure, and Activate a Network Interface Using NetworkManager CLI

This exercise should be done on host1 and server2.

In this exercise, you will add a new network interface to the virtual machine hosting server2, with the source device “Host device em1 (Bridge ‘br0’)”, default MAC address, and device model virtio. On server2, you will call this interface eth1 and assign IP 192.168.0.121/24 using the NetworkManager CLI. You will deactivate and reactivate this interface at the command prompt. You will reboot server2 and verify the persistence of IP assignments for this new interface. You will assign it hostname server2-eth1.example.com and alias server2-eth1 and update the hosts file accordingly.

1. Open the virtual console for server2 on host1. Click “Show virtual hardware details” | Add Hardware | Network. Select host device “Host device em1 (Bridge ‘br0’)” from the drop-down list and device model virtio. Leave the MAC address to the default. Click Finish to complete the new interface assignment.

2. Log on to server2 and check the running status of NetworkManager service:

# systemctl status NetworkManager

NetworkManager.service - Network Manager

Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled)

Active: active (running) since Mon 2014-11-17 11:00:52 EST; 28min ago

…… . .

3. Look for the new interface with the ip command:

# ip addr

…… . .

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000

link/ether 52:54:00:96:13:58 brd ff:ff:ff:ff:ff:ff

The output indicates the presence of a new interface by the name eth1.

4. List all configured interfaces on the server:

Images

5. Show the status of all available interfaces on the server:

Images

6. Add a connection of type Ethernet, interface name eth1, connection name eth1, IP 192.168.0.121/24, and gateway 192.168.0.1:

# nmcli con add type Ethernet ifname eth1 con-name eth1 ip4 192.168.0.121/24 \ gw4 192.168.0.1

Connection 'eth1' (7f365451-fd33-44f0-bffb-45de70d06fe0) successfully added.

The nmcli command has added the new interface and has activated it. In addition, it has created the ifcfg-eth1 file in the /etc/sysconfig/network-scripts directory with all necessary directives.

7. Check the new connection and IP assignments:

# ip addr

…… . .

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000

link/ether 52:54:00:96:13:58 brd ff:ff:ff:ff:ff:ff

inet 192.168.0.121/24 brd 192.168.0.255 scope global eth1

valid_lft forever preferred_lft forever

inet6 fe80::5054:ff:fe96:1358/64 scope link

valid_lft forever preferred_lft forever

8. Check the contents of the ifcfg-eth1 file:

# cat /etc/sysconfig/network-scripts/ifcfg-eth1

TYPE=Ethernet

BOOTPROTO=none

IPADDR0=192.168.0.121

PREFIX0=24

GATEWAY0=192.168.0.1

DEFROUTE=yes

IPV4_FAILURE_FATAL=no

IPV6INIT=yes

IPV6_AUTOCONF=yes

IPV6_DEFROUTE=yes

IPV6_PEERDNS=yes

IPV6_PEERROUTES=yes

IPV6_FAILURE_FATAL=no

NAME=eth1

UUID=7f365451-fd33-44f0-bffb-45de70d06fe0

DEVICE=eth1

ONBOOT=yes

9. Show the connection information for eth1:

# nmcli con show | grep eth1

eth1 7f365451-fd33-44f0-bffb-45de70d06fe0 802-3-ethernet eth1

10. Show the connection status of eth1:

# nmcli dev status | grep eth1

eth1 ethernet connected eth1

11. Deactivate this interface and then reactivate:

# nmcli con down id eth1

# nmcli con up id eth1

Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3)

12. Reboot the system:

# reboot

13. Verify the presence of eth1 assignments:

# ip addr

…… . .

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000

link/ether 52:54:00:96:13:58 brd ff:ff:ff:ff:ff:ff

inet 192.168.0.121/24 brd 192.168.0.255 scope global eth1

valid_lft forever preferred_lft forever

inet6 fe80::5054:ff:fe96:1358/64 scope link

valid_lft forever preferred_lft forever

14. Open the hosts file and append the following entry to it:

# vi /etc/hosts

192.168.0.121 server2-eth1.example.com server2-eth1

You can use puTTY in Windows and attempt to access the server using this new IP.

Testing Network Connectivity with ping

After the new connections have been established on server1 and server2, we need to test whether the IP addresses are pingable and accessible from other systems. Log on to host1 or another RHEL system and run the ping (packet internet gropper) command. The ping command is used to check the network connectivity at the IP level when the physical connectivity is ok and proper IP address and network assignments are in place. This command sends out a series of 64-byte Internet Control Message Protocol (ICMP) test packets to the destination IP and waits for a response. With the –c option, we can specify the number of packets that we want to send.

The following will send two packets from host1 to 192.168.0.111 and two packets to 192.168.0.121:

# ping –c2 192.168.0.111

PING 192.168.0.111 (192.168.0.111) 56(84) bytes of data.

64 bytes from 192.168.0.111: icmp_seq=1 ttl=64 time=0.240 ms

64 bytes from 192.168.0.111: icmp_seq=2 ttl=64 time=0.269 ms

--- 192.168.0.111 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 999ms

rtt min/avg/max/mdev = 0.240/0.254/0.269/0.021 ms

# ping –c2 192.168.0.121

PING 192.168.0.121 (192.168.0.121) 56(84) bytes of data.

64 bytes from 192.168.0.121: icmp_seq=1 ttl=64 time=0.237 ms

64 bytes from 192.168.0.121: icmp_seq=2 ttl=64 time=0.234 ms

--- 192.168.0.121 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 999ms

rtt min/avg/max/mdev = 0.234/0.235/0.237/0.015 ms

Under the ping statistics, the outputs show the number of packets transmitted, received, and lost. The packet loss should be 0% and the round trip time should not be too high for a healthy connection. In general, we can use this command to test connectivity with a system’s own IP, the loopback IP, the default route, other systems on the local network, systems on a different network, and systems beyond the local network.

If ping fails in any of the situations, we need to check if the network adapter is seated properly, its driver installed, network cable secured appropriately, IP and subnet mask values set correctly, the default route configured right, and proper rules are defined in the firewall. We also need to verify entries in the hosts file and files in the /etc/sysconfig/network-scripts directory.

Overview of Graphical Network Administration Tools

RHEL7 offers Network Settings and Network Connections tools for graphical management of network interfaces. The Network Settings (or Control Network) is located in the Control Center and it may be accessed by clicking the network icon at the top right-hand corner in the GNOME desktop as shown in Figure 12-2 or by clicking Applications | System Tools | Settings | Network.

Images

Figure 12-2 Network Icon

The Network Settings graphical tool allows us to view the status of available network interfaces, activating and deactivating them by sliding the bar to ON or OFF, add a new interface by clicking the + sign in the bottom left, delete an existing interface by highlighting an existing connection on the left and clicking the – sign in the bottom left, and modify an existing connection by selecting an existing connection on the left and clicking the gear wheel icon in the bottom right. See Figure 12-3.

Images

Figure 12-3 Network Settings

There are five types of network connections that we can add with this tool. These are VPN, Bond, Team, Bridge, and VLAN. Choosing any one of them brings up a new window with four tabs available in it. Figure 12-4 shows the window when we choose to add a Bridge. One of the three tabs is specific to the type of connection chosen; the rest are common for all interface types. Each tab allows us to enter necessary configuration information, including user-defined connection and interface names, static or dynamic IPv4 or IPv6 settings, DNS client and routing information, name of the firewall zone, and so on.

Images

Figure 12-4 Network Settings / Add Connection

If we choose to modify a connection, the tabs will appear vertically on the left side, as shown in Figure 12-5. We can see the details for the interface; modify its IP, DNS, and routing information; reset all current assignments; and so on.

Images

Figure 12-5 Network Settings / Modify a Connection

The Network Connections Editor tool provides pretty much the same functionality as the Network Settings tool we have just studied. Try running it with the nm-connection-editor command in an X terminal window and navigate to familiarize yourself with it.

The NTP Client

Network Time Protocol (NTP) is a networking protocol for synchronizing the system clock with more reliable remote providers of time. Using this protocol, a system can be configured as a server, peer, or client. The configuration changes to implement any of these roles are straightforward. In fact, the NTP client functionality comes pre-configured with the installation of NTP software. You simply need to enable and start the service, and your system will begin synchronizing its clock with one of the pre-defined timeservers.

The NTP client service can be modified by hand-editing a configuration file and restarting the service. This can alternatively be done using a graphical tool called System-Config-Date. You need to install the software packages for the base NTP software and, optionally, the GUI tool to configure your system to obtain time from a remote timeserver and maintain it. The software packages are referred to as ntp and system-config-date, respectively.

Activate the NTP Client

In order to establish the binding with a remote timeserver for time synchronization, install the ntp software on the system, along with the GUI tool:

# yum –y install ntp system-config-date

…… . .

Installed:

ntp.x86_64 0:4.2.6p5-18.el7

system-config-date.noarch 0:1.10.6-2.el7

Dependency Installed:

ntpdate.x86_64 0:4.2.6p5-18.el7

system-config-date-docs.noarch 0:1.0.11-4.el7

Complete!

By default, the NTP client functionality is pre-configured in the /etc/ntp.conf file, which is the primary configuration file for NTP in RHEL7. You simply need to enable and start the service. There are four default remote timeservers listed in the /etc/ntp.conf file, and they can be viewed as follows:

# grep ^server /etc/ntp.conf

server 0.rhel.pool.ntp.org iburst

server 1.rhel.pool.ntp.org iburst

server 2.rhel.pool.ntp.org iburst

server 3.rhel.pool.ntp.org iburst

EXAM TIP: As you will not have access to the outside network during the exam, you will need to point your system to an NTP server available on the local network. Simply comment the four server directives and add a single directive “server <hostname>” to the file. Replace <hostname> with an NTP server name or its IP address.

After the installation of the software is complete, run the following pair of commands to enable and start the service:

# systemctl enable ntpd

ln -s '/usr/lib/systemd/system/ntpd.service' '/etc/systemd/system/multi-user.target.wants/ntpd.service'

# systemctl start ntpd

The NTP daemon is now started. Execute the ntpq command with the –p switch to determine the association of your system with a timeserver:

Images

The output displays several timeservers. Your system has time association with the second server on the list prefixed with the * character.

Overview of the System-Config-Date GUI

The NTP client functionality may also be configured using the System-Config-Date graphical tool. This tool reads the definitions from the /etc/ntp.conf file and shows them graphically. In order to bring this tool up, execute system-config-date in an X terminal window or choose Applications | Sundry | System-Config-Date in the GNOME desktop. The System-Config-Date tool will open up as shown in Figure 12-6.

Images

Figure 12-6 System-Config-Date GUI for NTP Client Configuration

Select the option “Synchronize date and time over the network” to enable the service, and click Add to add hostnames or IP addresses for remote timeservers that you wish your system clock to synchronize with. You may leave the default server entries there. Expand Advanced Options to view two additional choices. Select “Speed up initial synchronization” to instruct the tool to run the ntpdate command and immediately bring the local system clock close to that of the first NTP server listed. Choose “Use Local Time Source” if you wish to use the local system clock as the provider of time. Click OK when done.

Chapter 16 “Synchronizing Time with NTP” discusses NTP in more detail.

The OpenLDAP Client

Lightweight Directory Access Protocol (LDAP) is a trivial, simplified networking protocol for obtaining centrally-stored information over the network. LDAP is designed to retrieve information that may include user account data (username, location, address, phone number, job title, etc.), group information (group names, members, etc.), calendar services, and other system and network configuration data. It can be configured and used to authenticate users over the network rather than storing and managing users locally on individual systems. Most of this information is static and does not change frequently, making OpenLDAP a suitable solution for write-once-read-many-times applications. All this data, configuration items, and other similar information can be stored on the central server running an LDAP-supported database.

LDAP was derived from Directory Access Protocol (DAP), which is one of the protocols within X.500 specifications developed jointly by the International Telecommunication Union (ITU) and the International Organization for Standardization (ISO). One of the major disadvantages of DAP was its heavy requirement for computer hardware resources to work efficiently. LDAP (also referred to as X.500 Lite), on the other hand, is thinner and requires less client-side compute power. LDAP is platform-independent, which has contributed in its wide availability on a variety of vendor hardware platforms running heterogeneous operating system software.

LDAP is hierarchical; its structure is similar to the Linux/UNIX directory tree and DNS. It can be based on logical boundaries defined by geography or organizational arrangements. A typical LDAP directory structure for a company called ABC with domain abc.com and offices located in Canada, USA, UK, and Australia, may look analogous to what is shown in Figure 12-7.

Images

Figure 12-7 LDAP Directory Hierarchy

The top of the company is referred to as the root of the LDAP directory hierarchy. Underneath it, domain component (dc) is located, which is usually the name of the company; country (c) falls under the domain component; and organizational units (ou) separate categories of directory information and may or may not be country-specific. The actual information resides at the lowest level of the hierarchy, which may include resources, such as users, profiles, people, printers, servers, photos, text, URLs, pointers to information, binary data, and public key certificates.

Benefits of Using OpenLDAP

There are many benefits associated with implementing and using OpenLDAP solution in an enterprise. In addition to its wide availability and its flexible design to suit an organizational structure, OpenLDAP offers the following key benefits:

· Has a hierarchical directory structure that provides organizations with information and resources in a logical fashion.

· Allows the consolidation of common data and storing it in separate organizational units.

· Provides users and applications with a unified, standard interface to a single, extensible directory service, allowing rapid development and deployment of directory-enabled applications.

· Enables fast searches and cost-effective management of users and security.

· Maintains directory-wide consistent and non-redundant information.

OpenLDAP Terminology

Before we go any further on this topic, let’s review and comprehend the following key terms.

Directory: A directory is a kind of a specialized database that stores information about objects such as people, profiles, printers, and servers. This information is trivial and is intended for write-once, read-many operations. A directory organizes the information in a hierarchical fashion, making it easier for users to look up and retrieve needed data, and at the same time making it simpler from an administration standpoint.

Entry: An entry is a building block for a directory and represents a specific record in it. In other words, an entry is a collection of information consisting of one or more attributes for an object. An LDAP directory, for instance, might include entries for employees, contractors, printers, servers, and buildings. Each entry is recognized by its unique distinguished name in the LDAP hierarchy.

Attribute: An attribute is associated with one or more entries and is made up of an attribute type and an attribute value. The attribute type such as jobTitle represents the type of information the attribute contains. An attribute value is the specific information contained in that entry. For instance, a value for the jobTitle attribute type could be “director” or “associate director”. Table 12-4 lists some common attribute types.

Attribute Type

Description / Attribute Value

CommonName (cn)

A common or full name of an entry, such as cn=John Doe.

DomainComponent (dc)

The distinguished name (DN) of a component in DNS such as dc=example and dc=com.

Country (c)

A country abbreviation such as c=ca.

Mail (mail)

An email address.

Organization (o)

The name of an organization such as o=redhat.

OrganizationalUnit (ou)

The name of a unit within an organization such as ou=Printers.

Owner (owner)

The owner of an entry such as cn=John Doe, ou=Printers, dc=example, and c=ca.

Surname (sn)

A person’s last name (or surname), such as Doe.

TelephoneNumber (telephoneNumber)

A telephone number, such as (123) 456-7890 or 1234567890.

User ID (uid)

A user’s login name.

Table 12-4 Common LDAP Attribute Types

An attribute type can use long names or corresponding abbreviations as identified in the above table.

Matching Rule: A matching rule matches the attribute value sought against the attribute value stored in the directory in a search and compare task. For example, matching rules associated with the telephoneNumber attribute could cause “(123) 456-7890” to match with either “(123) 456-7890” or “1234567890”, or both.

Object Class: Each entry belongs to one or more object classes. An object class is a group of required and optional attributes that define the structure of an entry. For instance, an organizationalUser object class may include commonName and Surname as required attributes and telephoneNumber, UID, streetAddress, and userPassword as optional attributes.

Schema: A schema is a collection of attributes and object classes along with matching rules and syntax, and other related information, that defines rules surrounding them. A properly configured schema ensures data consistency and helps keep the data organized.

LDAP Data Interchange Format (LDIF): LDAP Data Interchange Format (LDIF) is a special format used for importing and exporting LDAP records among LDAP servers. The data is in the text format and consists of entries or alterations to entries, or a combination.

Each record is represented as a group of attributes, with each attribute listed on a separate line comprising “name:value” pair. The following is a sample directory entry, with attributes representing a record in LDIF:

dn: cn=John Doe,ou=People, c=ca,dc=abc

objectClass: inetLocalMailRecipient

sn: Doe

mail: john.doe@abc.com

cn: John Doe

givenName: John

uid: jdoe

telephoneNumber: (416) 123-4567

Distinguished Name: A Distinguished Name (DN) uniquely identifies an entry in the entire directory tree. It is similar in concept to the absolute pathname of a file in the Linux directory hierarchy. For instance, cn=prn1,ou=Printers,c=ca,dc=abc is the distinguished name for prn1 printer. A DN is thus a sequence of RDNs separated by commas.

Relative Distinguished Name: A Relative Distinguished Name (RDN), in contrast, represents individual components of a DN. It is similar in concept to the relative pathname of a file in the Linux directory hierarchy. As an example, the RDN for the printer prn1 under Printers located in Canada (See Figure 12-6) is cn=prn1. Similarly, the RDN for Printers is ou=Printers, the RDN for ca is c=ca, and that for abc is dc=abc.

OpenLDAP Roles

There are four roles – server, replica, client, and referral – that systems within an LDAP environment may perform. One system can be configured to execute more than one role.

Server: A server is the central system that holds the LDAP directory information. It may be referred to as the master server. There must be at least one such server in the environment.

Replica: A replica is the system that receives a copy of the information that the LDAP server maintains. It may be referred to as a slave server. It is recommended to have at least one replica available on the network for enhanced availability and load sharing.

Client: A client is the system that binds itself with a server or replica to establish a communication session to perform queries on directory entries and carry out necessary modifications.

Referral: A referral is an entity on an LDAP server that redirects a client request to some other LDAP server or replica if it is unable to fulfill the request. It contains names and locations of other LDAP servers that might store the requested information.

OpenLDAP Client Packages

In order to implement and use OpenLDAP client functionality, software packages openldap, openldap-clients, and nss-pam-ldapd are required on the system. Furthermore, we have the option of choosing between one of two types of authentication services that are available in RHEL7. These services are System Security Services Daemon (SSSD) and Name Service Local Caching Daemon (NSLCD), and their purpose is to facilitate user authentication against a directory server. We can use either of them; however, the use of SSSD is preferred. Therefore, in addition to the three OpenLDAP packages, we will also need the sssd package and all the packages that it relies on. Together, these software bring with them necessary configuration files, library routines, and tools to support the implementation. The openldap package includes library and configuration files, the openldap-clients package contains client utilities such as ldapadd, ldapmodify, ldapcompare, ldapsearch, and ldapdelete to perform add, modify, compare, search, and delete operations on the directory, the nss-pam-ldapd package comprises of a library routine that must be installed for LDAP support to work properly, and the sssd package installs the sssd service on the client to support identity lookups and user authentication, authorization, and password modifications. We will need either TLS or LDAPs to establish an encrypted channel between the client and the server.

RHEL7 provides two more packages that are used to set up user identity and authentication on the client using LDAP, NIS, Kerberos, and a few other services. These packages are authconfig and authconfig-gtk, and they contain the authconfig command and its graphical equivalent system-config-authentication, a.k.a. authconfig-gtk, (the Authentication Configuration tool), respectively. The authconfig package also includes the authconfig-tui text tool that is equivalent to the graphical tool.

OpenLDAP Client Configuration Files

With the installation of the OpenLDAP client packages, configuration file /etc/openldap/ldap.conf becomes available on the system. This file sets system-wide default settings for LDAP client operations. Another file /etc/sssd/sssd.conf is created at the time of client configuration to store control data for the sssd daemon.

Table 12-5 lists and describes some key directives that are used in the ldap.conf file.

Directive

Description

BASE

Sets the base DN to be used for LDAP operations.

URI

Specifies the URI for the LDAP server.

TLS_CACERTDIR

Specifies the location where TLS certificates are stored. The default location is in /etc/openldap/cacerts directory.

Table 12-5 /etc/openldap/ldap.conf File

The authconfig Command

The LDAP client configuration can be done using the authconfig command. This command offers several options; Table 12-6 lists and describes the ones that affect LDAP client setup only.

Option

Description

--enableldap / --disableldap

Enables/disables LDAP for user information.

--enableldapauth / --disableldapauth

Enables/disables LDAP for user authentication.

--enableldaptls / --disableldaptls

Enables/disables the use of TLS with LDAP.

--enablesssd / --disablesssd

Enables/disables the use of SSSD for user information.

--ldapserver

Specifies the LDAP server hostname or IP.

--ldapbasedn

Sets the default LDAP base distinguished name.

--test

Displays new settings without updating the configuration.

--update

Updates the configuration with the supplied information. This option should be specified each time a change is desired in the configuration.

Table 12-6 The authconfig Command

We are going to use this command to configure an LDAP client in our next exercise.

Exercise 12-3: Configure LDAP Client to Obtain User and Group Information

This exercise should be done on server1.

It is assumed that server2 has the OpenLDAP service, such as FreeIPA or Red Hat Directory Server, configured and running, and it has a user account ldapuser1 and group account dba available to test authentication.

In this exercise, you will configure the LDAP client with the authconfig command. You will ensure that the client is autostarted at each system reboot. You will run appropriate commands to test it.

1. Install the necessary LDAP client software packages:

# yum –y install openldap openldap-clients nss-pam-ldapd sssd authconfig

2. Set up the client and update the configuration files. Enable the use of LDAP, LDAP authentication, and SSSD. Specify the hostname for the LDAP server and the base DN.

# authconfig --enableldap --enableldapauth --ldapserver=ldap://server2.example.com \ --enablesssd --ldapbasedn=”dc=example,dc=com” --update

3. Show the contents of the /etc/sssd/sssd.conf and /etc/openldap/ldap.conf files:

# cat /etc/sssd/sssd.conf

[domain/default]

autofs_provider = ldap

cache_credentials = True

krb5_realm = #

ldap_search_base = dc=example,dc=com

id_provider = ldap

auth_provider = ldap

chpass_provider = ldap

ldap_uri = ldap://server2.example.com/

ldap_id_use_start_tls = True

ldap_tls_cacertdir = /etc/openldap/cacerts

[sssd]

services = nss, pam, autofs

config_file_version = 2

domains = default

[nss]

[pam]

[sudo]

[autofs]

[ssh]

[pac]

# grep –v ^# /etc/openldap/ldap.conf

TLS_CACERTDIR /etc/openldap/cacerts

URI ldap://server2.example.com/

BASE dc=example,dc=com

4. Edit the /etc/nsswitch.conf file and ensure the passwd, shadow, and group entries look like the following (for details on this file, see Chapter 24 “Configuring DNS”):

passwd: files sss

shadow: files sss

group: files sss

5. Enable the sssd service to autostart at system reboots:

# systemctl enable sssd

6. Start the sssd service, which will also start the OpenLDAP client on the system:

# systemctl start sssd

7. Test group data by pulling dba group information from the server with the getent command (the getent command displays entries from the databases listed in the /etc/nsswitch.conf file):

# getent group dba

8. Test authentication by logging in as ldapuser1 from server1 to server2, using the ssh command:

# ssh ldapuser1@server2

If you want the client to use TLS for secure communication with the server, add --enableldaptls and --ldaploadcacert options with the authconfig command in step 2. You will need to ensure that a valid certificate is stored on server2 at an appropriate location.

Moreover, you may want to use Kerberos for authentication in place of LDAP’s password authentication method. For this, supply options specific to Kerberos with the authconfig command and do not specify the --ldapauth option. See Chapter 17 “Working with Firewalld and Kerberos” for details on Kerberos client setup.

EXAM TIP: Use either the graphical (authconfig-gtk or system-config-authentication) or the text (authconfig-tui) Authentication Configuration tool for LDAP client setup with or without Kerberos.

Overview of Graphical Authentication Configuration Tool

The Authentication Configuration tool is used for convenience if we do not feel comfortable with using the authconfig command. This graphical tool is easier to use provided we have the data handy that we want entered. This tool may be invoked by running the authconfig-gtk or the system-config-authentication command in an X terminal window or choosing Applications | Sundry | Authentication in the GNOME desktop. It will open up as shown in Figure 12-8.

Images

Figure 12-8 Authentication Configuration Tool

There are three tabs across the top for configuring identity & authentication, advanced options, and password options. As we know, this tool allows us to access user information stored on various types of databases and to configure the service to be used for user authentication purpose. For any user account database that we select from the drop-down list under Identification & Authentication, we see the window size changes providing room to enter data specific to the selected database. Figure 12-9 depicts the window for LDAP.

Images

Figure 12-9 Authentication Configuration Tool – LDAP Client Configuration

Similarly, we can use a method for authentication. For instance, LDAP can use either the LDAP password or Kerberos password. If the latter is chosen, we will need to enter Kerberos server details.

The Advanced Options provide additional configuration selections for authentication, and the Password Options tab allows us to set password rules.

Chapter Summary

This chapter discussed networking and OpenLDAP client configuration. It started by providing an understanding of various essential networking terms to build the foundation for networking topics going forward. Topics such as the hostname, IPv4, IPv6, network classes, subnetting, subnet mask, protocol, and Ethernet address were covered.

We configured one network interface on server1 and another one on server2 using commands. We had an overview of the graphical tool. We reviewed various files involved in the configuration. We performed activation and deactivation of interfaces manually and defined the IP and hostname mappings in the hosts databases on both servers. We used tools to test network connectivity.

We covered the configuration of an NTP client on our system to synchronize the clock with a more accurate provider of time. We looked at how to enable the service using commands and the graphical setup tool.

Finally, we studied OpenLDAP: concepts, benefits, terminology, and roles. We performed an exercise to configure the LDAP client service on our system, and then tested it. We looked at the graphical authentication tool and saw how to use it to configure the OpenLDAP client.

Chapter Review Questions

1. What is a relative distinguished name?

2. What is meant by the object Entry in LDAP terminology?

3. The NTP client is pre-configured when the ntp software is installed on the system. We just need to start the service to begin synchronizing the clock. True or False?

4. Which class of IP addresses has the least number of node addresses?

5. What is the use of ifup and ifdown commands?

6. Which command may we use to display the hardware address of a network interface?

7. Which directory does the Network Manager store the interface configuration files?

8. Which file defines the protocols in the system?

9. List three benefits of using LDAP as a directory server.

10. What is the purpose of the ONBOOT directive in the interface configuration file?

11. The /etc/hosts file maintains the hostname to hardware address mappings. True or False?

12. Which file contains service, port, and protocol mappings?

13. What is the name of the graphical NTP client configuration tool?

14. What would the ip addr command produce?

15. Which command can be run at the command prompt in an X terminal window to bring up the graphical Network Connections tool?

16. List any two benefits of subnetting.

17. The ip neighbor command uses the RARP protocol to provide MAC to IP address mappings. True or False?

18. What would the command system-config-authentication do?

Answers to Chapter Review Questions

1. The relative distinguished name represents individual components of a DN.

2. The object Entry represents a specific record in the LDAP directory.

3. True.

4. The C class has the least number of node addresses.

5. The purpose of these two commands is to activate and deactivate an interface.

6. The ip command.

7. The /etc/sysconfig/network-scripts directory.

8. The /etc/protocols file.

9. Three benefits are access to uniform information, centralized storage for information, and user authentication.

10. The purpose of this directive is to tell the boot scripts whether to activate this interface.

11. False. This file maintains hostname to IP address mappings.

12. The /etc/services file.

13. The name of the graphical NTP client configuration tool is System-Config-Date.

14. This command will display information about interfaces including IP and hardware address information.

15. The command to bring up the graphical Network Connections tool is nm-connection-editor.

16. Better manageability and less traffic.

17. False. It uses ARP protocol.

18. This command will bring up the graphical Authentication Configuration tool.

DIY Challenge Labs

The following labs are useful to strengthen most of the concepts and topics learned in this chapter. It is expected that you perform these labs without any additional help. A step-by-step guide is not provided, as the implementation of these labs requires the knowledge that has been presented in this chapter. Use defaults or your own thinking for missing information.

Lab 12-1: Assign a New IP to the System

Remove the current IP assignments for eth0 on server1.example.com and replace them with something different but on the same subnet. Apply the new IP information using appropriate tools and test it using the ip and ping commands, then edit appropriate files to make this modification persistent across reboots. Activate and deactivate the interface manually. Reboot the system and verify the new IP using appropriate commands.