RHCE - RHEL7 - Part 1Published on 2014-11-25
System Configuration and management
This is the first in a three part series covering the objectives for the Red Hat Certified Engineer (RCHE, EX300) exam.
Each part will follow the objectives as they have been outlined by Red Hat.
- Use network teaming or bonding to configure aggregated network links between two Red Hat Enterprise Linux systems
- Configure IPv6 addresses and perform basic IPv6 troubleshooting
- Route IP traffic and create static routes
- Use firewalld and associated mechanisms such as rich rules, zones and custom rules, to implement packet filtering and configure network address translation (NAT)
- Use /proc/sys and sysctl to modify and set kernel runtime parameters
- Configure a system to authenticate using Kerberos
- Configure a system as either an iSCSI target or initiator that persistently mounts an iSCSI target
- Produce and deliver reports on system utilization (processor, memory, disk, and network)
- Use shell scripting to automate system maintenance tasks
Aggregated network links
The full objective is: Use network teaming or bonding to configure aggregated network links between two Red Hat Enterprise Linux systems
Using VirtualBox, we can configure two machines to connect to each other with several network configurations. In this setup I'll be using a 'host-only network'. With two NICs in the VM they are named
enp0s8 which will be the "ports" which will be teamed.
I have to modify the configuration files for these interfaces. I use a "golden image" which I clone to make the practice devices to I have make sure to ignore the configured MAC address (since it changes from the one configured during installation when we clone). I've shown which lines I modified, the rest can remain as the default.
[root@red ~]# cd /etc/sysconfig/network-scripts [root@red network-scripts]# cp ifcfg-enp0s3 ifcfg-enp0s8 [root@red network-scripts]# vim ifcfg-enp0s3 #HWADDR= BOOTPROTO=none NAME=enp0s3 (or enp0s8 depending on which interface config we're using) #UUID= ONBOOT=yes [root@red network-scripts]# ifdown enp0s3 [root@red network-scripts]# ifdown enp0s8
Now we can actually configure our team:
[root@red ~]# nmcli connection add type team ifname Team0 [root@red ~]# nmcli connection add type team-slave con-name Team0-port1 ifname enp0s3 master Team0 [root@red ~]# nmcli connection add type team-slave con-name Team0-port2 ifname enp0s8 master Team0 [root@red ~]# nmcli connection up Team0-port1 Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/4) [root@red ~]# nmcli connection up Team0-port2 Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/5) [root@red ~]# vim /etc/sysconfig/network-scripts/ifcfg-team-Team0 BOOTPROTO=none IPADDR=192.168.0.2 NETMASK=255.255.255.0
Setting the IP address statically this way requires us to restart the system in order for the team to actually have the address assigned. At the time of writing I am not aware of any way to set the ip address without rebooting besides doing this command:
[root@red ~]# ip addr add 192.168.0.2/24 dev Team0
From here, we can ping other devices in the nework showing that the team has been created successfully.
Configuring the runners (to change from the default roundrobin) will require information from the relevant man page:
[root@red ~]# man 5 teamd.conf
Configure IPv6 addresses and perform basic IPv6 troubleshooting
Configuring IPv6 addresses follow the same procedure as configuring IPv4 addresses. We would edit the files in /etc/sysconfig/network-scripts and set the address we want there.
Route IP traffic and create static routes
There is a section in the documentation on configuring static routed using the command line. The relevant man page to get information on configuring static routes will be
ip-route. Thanks to Will Twomey who helped me figure out the static networking aspect of this section.
An important thing to note is how to make changes persistent:
Static routes set using ip commands at the command prompt will be lost if the system is shutdown or restarted. To configure static routes to be persistent after a system restart, they must be placed in per-interface configuration files in the /etc/sysconfig/network-scripts/ directory.
For this example, I'll be using three devices and 2 subnets. I'll have one device in each subnet with the third device acting at the router between them. This is how the network will be configured:
DEVICE NETWORK ADDRESS alpha 192.168.0.0/24 192.168.0.1 beta 192.168.1.0/24 192.168.1.1 router both 192.168.0.2 and 192.168.1.2
To configure the interfaces we'll edit the files within
/etc/sysconfig/network-scripts/ and provide the following information:
DEVICE=enp0s3 BOOTPROTO=none ONBOOT=yes IPADDR=192.168.0.1 NETMASK=255.255.255.0
For the static routes themselves we can create files in
route-enp0s3 with the routes listed with the following format:
192.168.0.0/24 via 192.168.1.2
This is how
alpha was configured, we'd adjust the information for each system. Also, the router is going to have an interface in each network so I had files
ifcfg-enp0s8 on that system.
With just this much we can have
beta ping the
router successfully and the
router can ping both but the systems can't ping across the router yet.
We'll have to turn routing 'on' at the router by modifying a kernel parameter. We'll have to add the following to the
net.ipv4.ip_forward = 1
Now we can start configuring the static routes. First, I want
alpha to know how to get to the 192.168.1.0/24 network. It will have to go through the routers interface on the 192.168.0.0/24 network. So:
ip route add 192.168.1.0/24 via 192.168.0.2
From here we can ping the routers interface in that network, 192.168.1.2 but pings will fail if we try to reach
betas interface. This is because the packets are sent to
beta but beta doesn't know how to get those packts back to where they came from. We'll now have to configure the static route on
ip route add 192.168.0.0/24 via 192.168.1.2
Now pings between the two systems work as expected since they both know how to reach each other.
We can check the system configured on the system by using the following commands:
The full objective is: Use firewalld and associated mechanisms such as rich rules, zones and custom rules, to implement packet filtering and configure network address translation (NAT)
The Fedora project has a great document on the subject of firewallD which I'll be following along with here.
Let's start with the most important command for an exam: where to get quick help:
[root@firewall ~]# firewall-cmd -h
First, let's see what firewallD is up to:
[root@firewall ~]# firewall-cmd --state running
firewallD uses zones to configure rules based on levels of trust, let's see what zones firewallD is working with:
[root@firewall ~]# firewall-cmd --get-zones block dmz drop external home internal public trusted work
We can use the
--list-all-zones command to get an overview of all the zones. In this example I'm only showing the config for the
block zone but it shows you the type of things that are available for configuration for the zone.
[root@firewall ~]# firewall-cmd --list-all-zones block interfaces: sources: services: ports: masquerade: no forward-ports: icmp-blocks: rich rules:
So let's get down to some actual work. I'll set up apache and we'll work through getting it opened and available.
[root@firewall ~]# firewall-cmd --add-service=http success
That's it! Without specifying a zone, it will automatically use the default zone, in my case the
We use the
--permanent option to make sure that the rules we set will be available after we reboot. Note:
The permanent options are not affecting runtime directly.
The fedoraproject site also has some documentation for information pertaining to 'rich rules'. Essentially 'rich rules' is a syntax that allows us to describe iptables rules in a structured sort of way.
[root@firewall ~]# firewall-cmd --add-rich-rule='rule protocol value='ah' accept' success
In this example we are adding a protocol rule which applies to the 'authentication header' protocol.
The scope of the rich rules syntax is a bit much to cover here but there is a man-page for it which provides several examples and is actually easy to use.
[root@firewall ~]# man firewalld.richlanguage
As for NAT, SSN Network has a great video on youtube on the subject. In short you are going to either add an interface to the
external zone where masquerading is enabled by default or adding the
masquerade option to a zone you would like to add NAT to.
Use /proc/sys and sysctl to modify and set kernel runtime parameters
We can use /proc/sys or /etc/sysctl.conf to make changes to the kernel runtime parameters.
For example, if we
cat out the contents of the
/proc/sys/net/ipv4/ip_forward file we can see what forwarding for this system is set to
0 (off) or
We can change the value to what we want in this file or we can set it in the /etc/sysctl.conf file this way:
net.ipv4.ip_forward = 1
Notice that the name follows the directory structure within
Configure a system to authenticate using Kerberos
You'll need the
authconfig package which will give you the
authconfig-tui program which makes configuring a system to use kerberos very, very easy.
yum install -y krb5-workstation pam_krb5 authconfig-tui domain PEQUENO.in kdc krb.pequeno.in admin krb.pequeno.in # kinit test1 ssh firstname.lastname@example.org
Configure a system as either an iSCSI target or initiator
The full objective is: Configure a system as either an iSCSI target or initiator that persistently mounts an iSCSI target
In the version of this exam for RHEL 6 the objective was to configure an iscsi initiator but in this version it seems like you should be able to do both. The good news is that configuring an iscsi target is actually easier since we now use a tool from Datera called
targetcli. I'll be following this guide.
The important thing to note is that we need to
set attribute authentication=0 and
set attribute generate_node_acls=1 to allow us to use the target without having to use authentication. This isn't the safest option but it will help when practicing.
yum -y install targetcli [root@iscsi ~]# mkdir /iscsi_disks [root@iscsi ~]# targetcli targetcli shell version 2.1.fb34 Copyright 2011-2013 by Datera, Inc and others. For help on commands, type 'help'. /> cd backstores/fileio /backstores/fileio> create disk01 /iscsi_disks/disk01.img 5G Created fileio disk01 with size 5368709120 /backstores/fileio> cd /iscsi /iscsi> create iqn.2014-11.in.pequeno.iscsi:tgt1 Created target iqn.2014-11.in.pequeno.iscsi:tgt1. Created TPG 1. /> cd iscsi/iqn.2014-11.in.pequeno.iscsi:tgt1/tpg1/ /iscsi/iqn.20...csi:tgt1/tpg1> set attribute authentication=0 Parameter authentication is now '0'. /iscsi/iqn.20...csi:tgt1/tpg1> set attribute generate_node_acls=1 Parameter generate_node_acls is now '1'. /iscsi> cd /portals /iscsi/iqn.20.../tpg1/portals> create Using default IP port 3260 Binding to INADDR_ANY (0.0.0.0) Created network portal 0.0.0.0:3260. /iscsi/iqn.20.../tpg1/portals> cd ../luns /iscsi/iqn.20...gt1/tpg1/luns> create /backstores/fileio/disk01 Created LUN 0. /iscsi/iqn.20...gt1/tpg1/luns> exit Global pref auto_save_on_exit=true Last 10 configs saved in /etc/target/backup. Configuration saved to /etc/target/saveconfig.json
Now we can configure the initiator:
[root@initiator ~]# yum install iscsi-initiator-utils -y [root@initiator ~]# iscsiadm -m discovery -t sendtargets -p iscsi.pequeno.in 220.127.116.11:3260,1 iqn.2014-11.in.pequeno.iscsi:tgt1 [root@initiator ~]# iscsiadm -m node -T iqn.2014-11.in.pequeno.iscsi:tgt1 -p iscsi.pequeno.in -l Logging in to [iface: default, target: iqn.2014-11.in.pequeno.iscsi:tgt1, portal: 18.104.22.168,3260] (multiple) Login to [iface: default, target: iqn.2014-11.in.pequeno.iscsi:tgt1, portal: 22.214.171.124,3260] successful.
From here, we can treat the target as a normal disk and add it to our
/etc/fstab for persistant mounting.
Produce and deliver reports on system utilization (processor, memory, disk, and network)
I think the idea here is to get familiar with the
sar command to generate reports on system utilization. A very quick way to cover all your bases is to get
sar to give you everything (
-A) and dump it into a file:
[root@sysconfig #] sar -A > system-info.txt
Generally, get familiar with
sars flags. How you produce reports and what you report on will depend on how they ask the question on the exam.
In Michael Jang's book he also suggests to use
sadf to produce reports.
sadf works similarly to
sar but it produces output in CSV so they can be easily imported into other data analysis tools.
Use shell scripting to automate system maintenance tasks
Again, how you solve this problem depends on exactly what they ask you to do on the exam. But let's make up some scenarios that will demonstrate how we'd be able to do some common administration tasks with some scripts.
In this example I've created a short python script that will create 10 files randomly named and of a random size between 1MB and 10MB. I'll tell cron to run this a few times to generate a lot of files.
import random from subprocess import call import uuid import os os.chdir("/root/manyfiles") for i in range(1, 11): file_size = str(random.randint(1, 10)) file_name = str(uuid.uuid4()) call("dd if=/dev/zero of=" + file_name + " bs=1M count=" + file_size + " 2> /dev/null", shell=True)
Now we have a directory full of files of various sizes. Let's use bash to go into the directory and identify files smaller than 2MB:
[root@script ~]# cat cleanup.sh cd /root/manyfiles # 2MB in bytes MINFILESIZE=2097152 for i in $(ls); do FILESIZE=$(wc -c "$i" | cut -f 1 -d ' '); if [[ $FILESIZE -le $MINFILESIZE ]]; then echo $i fi done [root@script ~]# ./cleanup.sh 2c426daf-5754-4104-8db6-c8e775f1206f 695159d8-9f01-4b38-a859-915e3f00403e f13720bf-c44f-404d-9107-f7cc5c511ab7
In this example we'll have bash tell us how many httpd processes are running and put them into a file to be served by Apache
[root@script ~]# cat httpd.sh echo "There are" $(ps aux | grep -c httpd) "httpd processes currently running" > /var/www/html/proc.html
Now we can just have cron run this every minute and when we go to http://powertra.in/proc.html (for example) we will see how many http process were running when the script was called.