RHCSA Exam Prep Answers

RHCSA Exam Prep
Chapter 1 Prepare for Red Hat Hands-On

Certifications LABS
Basic Setup
A) Parallels create new RHEL VM:
rhel64vmhost1.dno.com
4 CPUS
8 GB Memory
80 GB hard disk space:
/boot primary partition 500 MB
/ primary partition 10 GB
swap primary partition 4 GB
/home extended partition 5 GB
/var extended partition 10 GB
/data the rest for RHEL VMs and additional virtual disks
51 GB
Network 1 x NIC:
NIC1 192.168.0.40 / 24 DG MAC BOOK WI-FI NIC and
sky router at ( 192.168.0.1)
UK keyboard and language
Basic server packages plus Desktops Desktop, Fonts and
X window system and Applications Internet browser
First Boot:
Not RHL registered.
Create user doldham
NTP sync over network with default rhel ntp servers.
KDUMP enabled, default size
Reboot for changes to take effect.
B) Install Parallels tools:
1) Login to VM.
2) Switch to root user:
$su enter root password

3) Install missing package gcc:
a) Parallels->Devices->CD/DVD1 switch Parallels tools iso
to RHEL 6.4 iso.
b) Unmount Parallels iso:
#cd /
#umount /media
c) Mount RHEL 6.4 iso:
#mount /dev/sr0 /media
d) Copy RHEL 6.4 iso contents to /data/rhel64 directory:
#cd /data
#mkdir rhel64
#cd rhel64
#cp ar /media/. .
e) Unmount /media:
#cd /
#umount /media
Parallels->Devices->CD/DVD1->Disconnect ISO.
f) Change directory to /etc/yum.repos.d:
#cd /etc/yum.repos.d
g) Copy rhel-source.repo to new repository local.repo:
#cp rhel-source.repo local.repo
h) Amend new repository local.repo to setup local
repository pointing at local copy of RHEL 6.4 ISO files
copied above as follows:
[local]
name=Red Hat Enterprise Linux 6.4 local copy
baseurl:file///data/rhel64/
enable=1
gpgcheck=1
gpgkey=file:///data/rhel64/RPM-GPG-KEY-redhatrelease
i) Setup new repository local:

#yum clean all
#yum update
j) Test new local repo:
#yum listrepo
k) Install missing package gcc:
#yum install gcc
l) Parallels->Actions-> Install Parallels Tools:
#cd /media/Parallels Tools
#./install
Next
If complains on missing packaged select install them and
then select reboot once installed.
m) Parallels->Devices->CD/DVD1->Disconnect ISO.
C) Setup Apache server:
1) Install apache packages:
#yum install httpd
2) Start apache:
#service httpd start
Ignore error about using 127.0.0.1 for now.
3) Set apache to start at runlevels 2345:
#chkconfig httpd on levels 2345
4) Confirm auto run level startup of apache:
#chkconfig httpd list
5) Open httpd port 80 in local firewall:
a) Add port 80 to iptables configuration file:
#vi /etc/sysconfig/iptables
Add following line:
-A INPUT -m state --state NEW -m tcp -p tcp --dport
80 -j ACCEPT
b) Restart iptables service to reread configuration file and
add port 80:
#service iptables restart
c) Check iptables now allows incoming packets on port 80:
#iptables list
You should see the following line added to cmd output:
ACCEPT
tcp -- anywhere
NEW tcp dpt:http
anywhere
state
6) Confirm you can see test apache web page:

Open browser to http://127.0.0.1/
D) Add RHEL 6.4 installation to apache so you can use install
using RHEL files from apache web server:
1) Create new /var/www/html/inst directory to hold RHEL
install files:
#mkdir /var/www/html/inst
2) Copy RHEL 6.4 DVD files from /data/rhel64 to new inst
subdirectory:
#cp ar /data/rhel64/. /var/www/html/inst
4) Change selinux security context for my inst sub directory
and its files:
#chcon R reference /var/www/html
/var/www/html/inst
5) Check you can now see the RHEL 6.4 DVD files via the web
browser:
browse to http://127.0.0.1/inst
You should now see the required files.

E) Setup vsFTP server:
1) Install vsFTP packages:
#yum install vsftpd
2) Start vsFTPd:
#service vsftpd start
3) Set vsftpd to start at runlevels 2345:
#chkconfig vsftpd on levels 2345
4) Confirm auto run level startup of vsftpd:
#chkconfig vsftpd list
5) Open ftp port 21 in local firewall:
a) Add port 21 to iptables configuration file:
Add following line:
21 -j ACCEPT
b) Restart iptables service to reread configuration file and
add port 21:
c) Check iptables now allows incoming packets on port 21:
#iptables list
You should see the following line added to cmd output:
ACCEPT
tcp -- anywhere
NEW tcp dpt:ftp
anywhere
state
d) Browse to new FTP server pub directory to confirm

access to port 21 through local firewall:
browse to ftp:///127.0.0.1/pub
F) Add RHEL 6.4 DVD files to vsFTP server so they can be used in
remote installs:
1) Create new /var/ftp/pub directory to hold RHEL install files:
#mkdir /var/ftp/pub/inst
2) Copy RHEL 6.4 DVD files from /data/rhel64 to new inst
subdirectory:
#cp ar /data/rhel64/. /var/ftp/pub/inst
6) Change selinux security context for my inst sub directory
and its files:
#chcon R reference /var/ftp/pub /var/ftp/pub/inst
7) Check you can now see the RHEL 6.4 DVD files via the web
browser:
browse to http://127.0.0.1/inst
You should now see the required files.
G) Setup local user doldham to use sudo cmd:
#usermod G wheel doldham
#vi /etc/sudoers
Uncomment following line to allow wheel group access to
sudo:
## Allows people in group wheel to run all commands
# %wheel
ALL=(ALL)
ALL
to:
%wheel
ALL=(ALL)
ALL
Write and save /etc/sudoers file.
H) Add eth0 NIC IP address details to /etc/hosts:
#vi /etc/hosts
Add following line:
192.168.0.40
rhel64vmhost1 rhel64vmhost1.dno.com
I) Configure rhel64vmhost1 to use DNS lookup from home

network:
1) Edit /etc/resolv.conf to add Home and dno.com domain and
to use Home domain IP as dns lookup:
#vi /etc/resolv.conf
Amend following line:
search Home dno.com
Add following line:
nameserver 192.168.0.1
Save and write /etc/resolv.conf file.
2) Manually set ipv4 packet forwarding kernel parameter:
#sysctl w net.ipv4.ip_forward=1
3) Edit /etc/sysctl.conf to make ipv4 packet forwarding kernel
parameter change permanent:
#vi /etc/sysctl.conf
# Controls IP packet forwarding
net.ipv4.ip_forward = 0
to:
# Controls IP packet forwarding
net.ipv4.ip_forward = 1
4) Change macbook parallel NIC settings for this VM to be
bridged to Wi-Fi card on macbook.
5) Edit /etc/sysconfig/network-scripts/ifcfg-eth0 to add DNS1
and DOMAINS so network manager populates
/etc/resolv.conf correctly to allow inter DNS searches etc:
#vi /etc/sysconfig/network-scripts/ifcfg-eth0
Add following lines:
DNS1=192.168.0.1
DOMAIN=Home dno.com
Write and Save /etc/sysconfig/network-scripts/ifcfg-eth0
file.
6) Prove DNS lookup is now working:
#dig google.com
Note you should see an IP address returned for google.com.
7) Prove Firefox web browser now works:
Open Firefox and browse to google.com
Page should now load.
J) Configure NTP to sync to Red Hat public NTP pool servers:
1) Edit /etc/ntp.conf to confirm the 3 Red Hat NTP servers are
listed:
#vi /etc/ntp.conf
Confirm following lines are within the /etc/ntp.conf file:
server 0.rhel.pool.ntp.org
If these are missing then add them and Write and Save
the /etc/ntp.conf
file.
2) Edit /etc/ntp.conf to confirm correct restrictions are in place:
#vi /etc/ntp.conf
Confirm following lines are within the /etc/ntp.conf file:
# Permit time synchronization with our time source,
but do not
# permit the source to query or modify the service
on this system.
restrict default kod nomodify notrap nopeer
noquery
restrict -6 default kod nomodify notrap nopeer

noquery
# Permit all access over the loopback interface.
This could
# be tightened as well, but to do so would effect
some of
# the administrative functions.
restrict 127.0.0.1
restrict -6 ::1
If these are missing then add them and Write and Save
the /etc/ntp.conf
file.
3) Make sure ntpd is stopped and manually sync the date and
time with 0.rhel.pool.ntp.org rhel public ntp server pool:
#service ntpd stop
#ntpdate 0.rhel.pool.ntp.org
4) Confirm that ntpd is set to run at runlevels 2345:
#chkconfig ntpd --list
If ntpd is not set to run at runlevels 2345 then set it:
#chkconfig ntpd on levels 2345
5) Start ntpd:
#service ntpd start
6) Confirm ntpd is syncing its time:
#ntpq p
You should see one entry starting with * meaning this is the
NTP server
you are syncing with, the other 2 should start with +
meaning they can
take over if there is an issue with the primary one.
remote
reach delay
refid
offset jitter
st t
when poll
=====================================
=====================
*janetzki.eu
131.188.3.220 2 u 58 64 377
43.353 -37.863 10.379
+h002.helix.fast 193.190.230.66 2 u 62 64 377
34.580 -54.235 14.04
+golf.zq1.de
122.227.206.195 3 u 60 64 377
40.022 -50.357 7.039
K) Install and configure DNS server:
1) Install all bind packages:
#yum install bind*
2) Edit /etc/named.conf and configure this as a DNS server
that the KVM VMs will poll for DNS queries:
#vi /etc/named.conf
As the KVM VMs will be installed with following IP
addressing:
server1.dnoexample.com eth0 192.168.122.51 /24
DG 192.168.122.1
(rhel64vmhost virtual network 1)
tester1.dnoexample.com eth0 192.168.122.151 /24
DG 192.168.122.1
outsider1.dnoexample.org eth0 192.168.100.100 /
24 DG 192.168.100.1
(rhel64vmhost1 virtual network 2)
These need to be added into the /etc/named.conf bold text
was added:
options {
listen-on port 53 { 127.0.0.1; 192.168.122.1; 192.168.100.1;};
listen-on-v6 port 53 { ::1; };
directory
"/var/named";
dump-file
"/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query
{ localhost; 192.168.122.0/24; 192.168.100.0/24;};
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
Zone "." IN {
type hint;
file "named.ca";
};
zone"dnoexample.com" IN {
type master;
file "fwd.dnoexample.com";
allow-update { none; };
};
zone"dnoexample.org" IN {
type master;
file "fwd.dnoexample.org";
};
zone"122.168.192.in-addr.arpa" IN {
type master;
file "rev.dnoexample.com";
};
zone"100.168.192.in-addr-arpa" IN {
type master;
file "rev.dnoexample.org";
};
Include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
Write and Save /etc/named.conf file.

3) Create zone files fwd.dnoexample.com
rev.dnoexample.com fwd.dnoexample.org and
rev.dnoexample.org:
#vi /var/named/fwd.dnoexample.com
$TTL 86400
@ IN SOA
rhel64vmhost1.dnoexample.com.
root.dnoexample.com. (
2011071001 ;Serial
3600
;Refresh
1800
;Retry
604800
;Expire
86400
;Minimum TTL
)
@
IN NS rhel64vmhost1.dnoexample.com.
@
IN A 192.168.122.1
@
IN A 192.168.122.51
@
IN A 192.168.122.151
rhel64vmhost1
IN A 192.168.122.1
server1
IN A 192.168.122.51
tester1 IN A 192.168.122.151
#vi /var/named/rev.dnoexample.com
$TTL 86400
@ IN SOA
rhel64vmhost1.dnoexample.org.
root.dnoexample.org. (
2011071001 ;Serial
3600
;Refresh
1800
;Retry
604800
;Expire
86400
;Minimum TTL
)
@
IN NS
@
IN A 192.168.100.1
@
IN A 192.168.100.101
rhel64vmhost1 IN A 192.168.100.1
outsider1 IN A 192.168.100.101
#vi /var/named/fwd.dnoexample.org
$TTL 86400
@ IN SOA
2011071001 ;Serial
3600
;Refresh
1800
;Retry
604800
;Expire
86400
;Minimum TTL
)
@
IN NS
@
IN A 192.168.100.1
@
IN A 192.168.100.101
outsider1 IN A 192.168.100.101
#vi /var/named/rev.dnoexample.org
$TTL 86400
@ IN SOA
2011071001 ;Serial
3600
;Refresh
1800
;Retry
604800
86400
;Expire
;Minimum TTL
)
@
IN NS rhel64vmhost1.dnoexample.org.
@
IN PTR dnoexample.org.
outsider1 IN A 192.168.100.101
1
IN PTR rhel64vmhost1.dnoexample.org.
101
IN PTR outsider1.dnoexample.org.
4) Set correct selinux context for files created in 3):
#chcon --reference=/var/named fwd.*
#chcon reference=/var/named rev.*
5) Set correct ownership and file permissions on files created
in 3):
#chown root:named fwd.*
#chown root:named rev.*
#chmod o-r fwd.*
#chmod o-r rev.*
6) Add DNS port 53 for TCP and UDP within the iptables:
Add following two lines:
-A INPUT -m state --state NEW -m udp -p udp
--dport 53 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp
--dport 53 -j ACCEPT
Write and Save /etc/sysconfig/iptables file.
7) Restart iptables server to take changes into effect:
Note we now need to install Red Hat KVM packages and
configure the 2 virtual networks so main server
rhel64vmhost1 has virtual NICs we can assign the .1
addresses for 192.168.122 and 192.168.100 subnets. Once
this completed we can return to finish the DNS setup.
L) Install and configure Red Hat KVM.

1) Install KVM packages:
#yum
#yum
#yum
#yum
#yum
#yum
#yum
install
install
install
install
install
install
install
qemu*
python-virtinst*
virt-manager*
virt-top*
virt-viewer*
libvirt
libvirt-client
2) Confirm correct HW modules have been loaded by installs:

#lsmod | grep kvm
For a Intel based processor you should see:
kvm_intel
kvm
53484 0
316506 1 kvm_intel
To manually load module if missing:

#modprobe kvm
3) Configure Virtual Machine Manager:
#chkconfig libvirtd on levels 2345
#service libvirtd start
#virt-manager
4) Add two require virtual networks on subnets 192.168.122
and 192.168.100:
Right Click localhost (QEMU) line and click Details
option.
Select Virtual Networks tab.
Click + button to add a secondary virtual network for
192.168.100 subnet.
Virtual Network Name
outsider
IPv4 address space
192.168.100/24
Select Forwarding to physical network Any physical
device
Mode
NAT
This will now configure 2 virtual NICs:

virbr0 192.168.122.1
virbr1 192.168.100.1
6) Remove original /var/lib/libvirt/images and create a soft link
to large data subdirectory to hold all virtual storage files:
#mkdir /data/KVM
#chcon R reference=/var/lib/libvirt/images
/data/KVM
#rmdir /var/lib/libvirt/images
#ln s /data/KVM /var/lib/libvirt/images
M) Now complete and test DNS server configuration.
1) Update /etc/hosts file with two new rhel64vmhost1 names:
#vi /etc/hosts
Add two following lines:
192.168.122.1 rhel64vmhost1.dnoexample.com
192.168.100.1 rhel64vmhost1.dnoexample.org
Write and Save /etc/hosts file.
2) Check DNS configuration files:
#named-checkconf /etc/named.conf
#named-checkzone
/var/named/fwd.dnoexample.com
#named-checkzone
/var/named/rev.dnoexample.com
#named-checkzone
/var/named/fwd.dnoexample.org
#named-checkzone /var/named/rev.dnoexample.org
3) If no errors from step 2) then start named DNS daemon:
#service named start
4) Confirm DNS for dnoexample.com and dnoexample.org are
working:
#dig @rhel64vmhost1.dnoexample.com
rhel64vmhost1.dnoexample.com
server1.dnoexample.com
tester1.dnoexample.com
#dig @rhel64vmhost1.dnoexample.org
rhel64vmhost1.dnoexample.org
#dig @rhel64vmhost1.dnoexample.org
outsider1.dnoexample.org
These should all return the required IP addresses as follows:
rhel64vmhost1.dnoexample.com 192.168.122.1
192.168.122.51
192.168.122.151
rhel64vmhost1.dnoexample.org 192.168.100.1
192.168.100.101
Base Parallels RHEL 6.4 VM is now ready for you to create the
required Red Hat KVM VMs to use in the following LAB sections.
Chapter 2 Virtual Machines and Automated

Installations LABS
Lab 1
Missing LAB, but install new RHEL 6.4 VM as follows:
Hostname
IP address
CPU
Memory
Disk
192.168.122.51/24 DG 192.168.122.1
2
2 GB
1 x 12 GB virtual disk for use by whole server
Packages Basic server plus desktop, fonts, X Window

system and Internet browser
**** Note that the ftp load of install.img will fail if nf_conntrack_ftp
module is not loaded. ****
To load module:
#modprobe nf_conntrack_ftp
#lsmod | grep ftp
1) Open Red Hat Virtual Manager:

#virt-manager
2) Select localhost (QEMU), right click and select New option.
3) Enter Name as server1.dnoexample.com.
4) Select Network Install option and click Forward button.
5) Enter URL as
ftp://rhel64vmhost1.dnoexample.com/pub/inst.
6) Click Forward button.
7) Change Memory to 2 GB and CPUs to 2 and click Forward
button.
8) Change disk image size to 12 GB and click Forward
button.
9) Check Customize configuration before install checkbox
and click Finish.
10) Click Begin Installation button.
11) Select English as language and click OK button.
12) Select uk as keyboard type and click OK button.
13) Amend Enable IPv4 support from DHCP to Manual
Configuration.
14) Enter IPv4 Address as 192.168.122.51 / 255.255.255.0
DG 192.168.122.1
NS 192.168.122.1 and click OK button.
15) When Red Hat splash screen loads click Next button.
16) Confirm Basic Storage Devices checkbox is selected and
click Next button.
17) Select Yes, discard any data option button.
18) Confirm hostname is server1.dnoexample.com and click
Next Button.
19) Select Europe/London as timezone and click Next button.
20) Enter root password twice and click Next button.
21) Select Use All Space option and click Next button.
22) Click Write changes to disk button.
23) Confirm Basic server is selected, check Customize now
checkbox and Next.
24) Add Desktops-> Desktop, Fonts and X Window system

and Applications->
Web Browser additional software and click Next button.
OS install will now start, wait until its finished.
25) At install complete splash screen click reboot button.
First boot of server1.dnoexample.com will now occur:
1) Click Forward button at Welcome splash screen.
2) Confirm Yes check box is selected and click Forward
button.
3) Check NO, I prefer to register at a later time and click
Forward button.
4) Click Register Later button and click Forward button.
5) Enter doldham as new user and enter password twice and
click Forward.
6) Check Synchronize date and time over the network as
long as 3 default Red
Hat NTP servers are listed click Forward.
7) Confirm Enable kdump is checked and click Finish button
and choose Yes
when prompted for another reboot and then OK button to
reboot.
Basic server1.dnoexample.com server has now been installed.
Add 2 x 1gb virtual disks to this VM:
1) In Virt-Manager right click on server1.dnoexample.com
entry and Open.
2) Click on View tab and select Details.
3) Click Add new Hardware.
4) Select Storage and amend disk size to 1 GB and IDE disk
type and Finish.
5) Repeat step 4) and then reboot VM.
6) Once server is back up login and as root check new disks
are available:
#fdisk l
Lab 2
A) In this lab, you'll clone the system created in Lab 1. Use the
techniques discussed in this chapter to clone that system. This
process can be completed either at the command line interface with
the virt-clone command or with the Virtual Machine Manager.
1) Make sure server1.dnoexample.com VM is shutdown.

2) Logon to rhel64vmhost1 server and switch to root user.
3) Clone server1.dnoexample.com to clone1.dnoexample.org
with following
Server details:
Hostname
IP address
CPU
Memory
Disk
server
Packages
clone1.dnoexample.org
192.168.100.51/24 DG 192.168.100.1
2
2 GB
1 x 12 GB virtual disk for use by whole
Basic server plus desktop, fonts, X Window
Note that as we are cloning server1.dnoexample.org we only

need to change
The hostname and IP addressing for now as the rest will be
cloned.
#virt-clone --prompt
As prompted enter the following details:
Name of original server?
Name of new cloned server? clone1.dnoexample.org
Cloned disk file path?
/var/lib/libvirt/images/clone1.dnoexample.org.img
nd
2 Cloned disk file path?
/var/lib/libvirt/images/clone1.dnoexample.org-1.img
rd
3 Cloned disk file path?
/var/lib/libvirt/images/clone1.dnoexample.org-2.img
Confirm clone finished with created successfully message.
4) Check new VM status:
#virsh list all
5) Boot clone1.dnoexample.org server to runlevel 1:
Interrupt boot and add 1 on boot line in grub to
boot into single user
mode.
7) Amend /etc/sysconfig/network file:
#vi /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=clone1.dnoexample.org
GATEWAY=192.168.100.1
Write and Save /etc/sysconfig/network file.
8) Amend /etc/sysconfig/network-scripts/ifcfg-eth1 file:
DEVICE=eth1
BOOTPROTO=static
DNS1=192.168.100.1
GATEWAY=192.168.100.1
HWADDR=52:54:00:B6:A7:7F
IPADDR=192.168.100.51
NETMASK=255.255.255.0
NM_CONTROLLED=yes
ONBOOT=yes
TYPE=ETHERNET
Write and Save /etc/sysconfig/network-scripts/ifcfg-eth1 file.
9) Amend /etc/hosts file to added hostname and IP address:
#vi /etc/hosts
Add following line:
192.168.100.51 clone1 clone1.dnoexample.org
Write and Save /etc/hosts file.
10)
Amend VM virtual network from cloned default network
to outsider1 network:
VM CONSOLE -> View -> Details -> NIC
Amend Source Device from Virtual network default : NAT
to Virtual network outsider : NAT and click Apply button.
11)
Reboot clone1.dnoexample.org.
12)
Confirm network access back to rhel64vmhost1 on
192.169.100 subnet:
#ping 192.168.100.1
As long as the above ping works the basic clone1 server setup
is completed.
B) In addition, when rebooting the system, you'll want to set this

system up as the clone1.example.org system on the 192.168.100.50
IP address. You can substitute a different IP address as long as it's
on a different network from the server1.example.com system.
All required steps performed in A).
C) When a system is cloned; it carries everything from the previous
system. So the first time you boot a cloned system, it's best to boot
it into a run level that does not start networking. Run level 1 is best
for that purpose. For more information on run levels and network
configuration, see Chapters 3 and 5.
All required steps performed in A).
Lab 3
A) Use the virt-install command to create a new system. Use the
model described in Chapter 1 for the tester1.example.com system,
with an IP address of 192.168.122.150.
1) From rhel64vmhost1 server install tester1.dnoexample.com
VM from cmd
line using virt-install cmd:
Server details:
Hostname
IP address
CPU
Memory
Disk
server
Packages
192.168.122.151/24 DG 192.168.122.1
2
2 GB
#virt-install n tester1.dnoexample.com r 2048 vcpus=2

disk
path=/var/lib/libvirt/images/tester1.dnoexample.com.img,siz
e=12 network network:default l
ftp://192.168.122.1/pub/inst
Within install console above cmd opens:
Language English
Keyboard UK
Enable IPv4 Manual Configuration
IPv4 address
192.168.122.151
Gateway
192.168.122.1
Name Server
192.168.122.1
** Note install will fail if kernel module nf_conntrack_ftp module is
not loaded **
To load this module:
#modprobe nf_conntrack_ftp
#lsmod | grep nf_conntrack_ftp
2) At Red Hat install splash screen click Next button.
3) Confirm Basic Storage Devices checkbox is selected and
click Next button.
4) Select Yes, discard any data option button.
5) Confirm hostname is server1.dnoexample.com and click
Next Button.
6) Select Europe/London as timezone and click Next button.
7) Enter root password twice and click Next button.
8) Select Use All Space option and click Next button.
9) Click Write changes to disk button.
10) Confirm Basic server is selected, check Customize now
checkbox and Next.
11) Add Desktops-> Desktop, Fonts and X Window system
and Applications->
Web Browser additional software and click Next button.
OS install will now start, wait until its finished.
12) At install complete splash screen click reboot button.
First boot of tester1.dnoexample.com will now occur:
1) Click Forward button at Welcome splash screen.
2) Confirm Yes check box is selected and click Forward
button.
3) Check NO, I prefer to register at a later time and click
Forward button.
4) Click Register Later button and click Forward button.
5) Enter doldham as new user and enter password twice and
click Forward.
6) Check Synchronize date and time over the network as
long as 3 default Red
Hat NTP servers are listed click Forward.

7) Confirm Enable kdump is checked and click Finish button
and choose Yes
when prompted for another reboot and then OK button to
reboot.
Basic tester1.dnoexample.com server has now been installed.
Lab 4
A) In this lab, you'll modify the Kick start file created on the
server1.example.com VM in Lab 1. It's the anaconda-ks.cfg file in
the root user's home directory. That file will be used to automate the
installation of a system on a virtual machine. Unless you've already
created it, the system will be tester1.example.com on IP address
192.168.122.150. If you've set up the server1.example.com system
on a different network, make sure the tester1.example.com system
is on the same network. Remember the lessons of the chapter when
modifying that file.
As we already have an installed tester1.example.com install
outsider1.dnoexample.org as follows instead.
Hostname
IP address
CPU
Memory
Disk
server
Packages
192.168.100.101/24 DG 192.168.100.1
2
2 GB
1) Create kickstart file to help build

outsider1.dnoexample.org.
#cp /root/anaconda-ks.cfg
/var/www/html/inst/outsider1-ks.cfg
#vi /var/www/html/inst/outsider1-ks.cfg
Amend outsider-ks.cfg where following bold text is the
changes:
# Kickstart file automatically generated by anaconda.
#version=DEVEL
install
url --url ftp://192.168.100.1/pub/inst
lang en_US.UTF-8
keyboard uk
network --onboot yes --device eth0 --bootproto
static --ip 192.168.100.101 --netmask 255.255.255.0
--gateway 192.168.100.1 --nameserver
192.168.100.1 --noipv6 --hostname
rootpw --iscrypted
$6$D56NF/WKvyWdFauz$dY.QQWm6SAP0PEuiCEJv370uaSC
Oz7Yg.Rttd8xGhlDY0m.85RSUEq3e7aN1ghV4iSBRGIqhUvKc
vF9hZKBY/1
firewall --service=ssh
authconfig --enableshadow --passalgo=sha512
selinux --enforcing
timezone --utc Europe/London
bootloader --location=mbr --driveorder=sda
--append="crashkernel=auto rhgb quiet"
# The following is the partition information you requested
# Note that any partitions you deleted are not expressed
# here so unless you clear all partitions first, this is
# not guaranteed to work
clearpart --all
zerombr
part /boot --fstype=ext4 --asprimary --size=500
part / --fstype=ext4 --asprimary --size=6656
part swap --asprimary --size=4096
part /home --fstype=ext4 --size=1024
%packages
@base
@client-mgmt-tools
@console-internet
@core
@debugging
@basic-desktop
@directory-client
@fonts
@hardware-monitoring
@internet-browser
@java-platform
@large-systems
@legacy-x
@network-file-system-client
@performance
@perl-runtime
@server-platform
@server-policy
@x11
mtools
pax
python-dmidecode
oddjob
sgpio
device-mapper-persistent-data
samba-winbind
certmonger
pam_krb5
krb5-workstation
libXmu
perl-DBD-SQLite
%end
shutdown
firstboot --disabled
2) Copy newly created kickstart file to /var/ftp/pub:
#cp /var/www/html/inst/outsider1-ks.cfg /var/ftp/pub
3) Change selinux settings for kickstart file in both
/var/www/html/inst and /var/ftp/pub.
#chcon reference=/var/www/html
/var/www/html/inst/outsider1-ks.cfg
#chcon reference=/var/ftp/pub
/var/ftp/pub/outsider1-ks.cfg
Make sure all users have read access to new kickstart file:
#chmod 444 /var/www/html/inst/outsider1-ks.cfg
#chmod 444 /var/ftp/pub/outsider1-ks.cfg
4) Create new outsider1.dnoexample.org from virt-manager
gui.
Select localhost (QEMU) and right click, then select New
option>
Enter hostname as outsider1.dnoexample.org
Leave install method as local install media (ISO image or
CDROM) and click Forward button.
Click Use CDROM or DVD option and set OS type to Linux
and Version should default to RHEL 6 then click Forward
button.
Set Memory to 2048 and 2 CPUs and click Forward button.
Set disk image size to 12 GB and make sure Allocate entire

disk now is checked and click Forward button.
Under Advanced Options change Virtual Network to
outsider : NAT and click Finish button.
System will now boot into install splash screen.
5) Configure install to use the kickstart file created above.
Make sure you have first line selected Install or upgrade an
existing system. And press TAB key to append to install
line.
Add the following text:
ks=ftp://192.168.100.1/pub/outsider1-ks.cfg
Then press Return key to start install. As the kickstart file
had shutdown and firstboot disabled directives, new VM
should reboot once install is completed.
Here are a few hints: ( Note all of this is as per above ).
1. Change the network directive to set the new system to an
appropriate IP address and hostname.
2. Make sure the partition directives are active. Change them as
needed to make sure a size is specified. If partition devices are
named directly, that can lead to problems.
3. Configure the system to shut down after installation is complete.
4. Don't be afraid of some trial and error. If the installation stops
during the process, check the messages in different virtual consoles.
5. Copy the Kick start to the installation directory created in Chapter
1. Use the techniques discussed in that chapter to make sure the
Kick start file matches the SELinux context of other files in that
directory.
6. Create a new KVM-based VM, using the techniques discussed in
the chapter.
7. Boot the system from the RHEL 6 network boot CD.
8. At the boot screen, highlight the Install Or Upgrade An Existing
System option and press TAB.
9. Add the ks directive along with the URL of the network

installation source created in Chapter 1.
10. Press ENTER. The installation should now proceed to completion,
without intervention.
11. If the installation stops during the process, make notes on
where it stopped. The screens available during the installation
process can help. To access those screens, press CTRL-ALT-F3, CTRLALT-F4, and CTRL-ALT-F5. To return to the main installation screen,
press ALT-F6 (ALT-F1 if you're using the text-based installation
program).
12. Match the stopping point with the appropriate entry in the Kick
start configuration file.
13. Modify the Kick start configuration file, and rerun the Kick startbased installation.
Lab 5
A) In this lab, you'll modify the Kickstart file created on the
server1.example.com VM in Labs 1 and 4, for use by the virt-install
command. Unless you've already created it, the system will be
outsider1.example.org on IP address 192.168.100.100. (If that IP
address network is in use by another component such as a cable
"modem," another IP address such as 192.168.101.100 is
acceptable.) As discussed in the chapter, the virt-install command
uses the more standard sda device for virtual hard drives, instead of
the vda device associated with the Virtual Machine Manager. You'll
have to change the Kickstart file accordingly.
Due to space issues we will now remove the
outsider1.dnoexample.org VM and re-install it from cmd line using
virt-install cmd.
1) Manually shutdown outsider1.dnoexample.org VM.
#virsh destroy outsider1.dnoexample.org
2) Manually delete outsider1.dnoexample.org VM.
#virsh undefine outsider1.dnoexample.org
3) Manually remove outsider1.dnoexample.org disk file:
#rm
/var/lib/libvirt/images/outsider1.dnoexample.org.img
4) Re-install outsider1.dnoexample.org from cmd line using

virt-install cmd.
#virt-install n outsider1.dnoexample.org r 2048
vcpus 2 disk
path=/var/lib/libvirt/images/outsider1.dnoexample.o
rg,size=12 network network:outsider l
ftp://192.168.100.1/pub/inst -x
ks=ftp://192.168.100.1/pub/outsider1-ks.cfg
Install will now start, and reboot after install.
The basic setup of outsider1.dnoexample.org is now complete.
Lab 6
A) In this lab, you'll test a Secure Shell client on any and all virtual
machines that you've created. Hopefully, you'll remember the root
administrative password configured during the installation process.
1. To see how the system works, first run the command on the local
system with the following command (if desired, substitute 127.0.0.1
for localhost).
# ssh localhost
2. Proceed with the login to the localhost system. Log out with the
exit command.
3. Review the current known hosts for the system with the cat
~/.ssh/known_hosts command. The file may appear
incomprehensible, but you'll see a line such as the following near
the end of the file, which refers to the public RSA key from the
localhost system.
localhost ssh-rsa dsaf34sfdajlk....
localhost ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAQEA9dXQ2l/vmnbtIIA/lbx+m
OplVba824wuT+hRb5cKdnun7m64UytAwdcALtpXmEVSKzmB
meKP4b7a1MwUErQdf4CjMcAnfQx94e170OOy3ltEqey92MI6H
aZDEOMqO4QJMMQaEsMTf4izHw0GdtnJFrDdcPxfWGtuzfRzT8
NlY6Bzq6TK5kSHBmipAKvyQw2h/U+sNeVNhI08HkVDm6lFqN
UckoWMaqU/K+
+/YC7egpP6Q+8Ac1/ISEAp/wJuPQ3KYHsrTv15ebi/EN9V3xUM
ObAHLwqHwP6d7uwWC7ha76aCNvRfNkptZxF4NPKosyuappF
jiT3wvuCzjjWr6Hb5kQ==
4. Repeat the process with a remote system such as

server1.example.com, or the equivalent IP address such as
192.168.122.50. After returning to the local system, what do you
see added to the known_hosts file? (Direct connections to the
server1.example.com system may not work until you've set up
the /etc/hosts file as discussed in Chapter 3.)
We can ignore the /etc/hosts as we have rhel64vmhost1 configure
as a DNS server.
Addition to /root/.ssh/known_hosts file:
server1.dnoexample.com,192.168.122.51 ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAQEAy/6ebOWSMK98hU5az7R
H1NI1yRpKOZXtO5oLEnlcLcJAv84tHZ/k9Z8xGeQKw/7lSywDB
DAd0QT+vhd9rK9OVNgvJDXEX+vmLM0hyAAo7KOoxFbagQdK
uvc71AkfIrsYx/q6JD9K7BWhv6xFgA9DYiVz70FBYNsC7ZqcdUz
D8QxdzFUInvzX4yMz8z4XXYS2A0ZMzmp5J02Nep+nyWhz8Wj
/pAKmdj3v6b55jWihD2yZRukBArejEcgfjdAukd8szojMgb/Jkj3M
tu0vR2NNmkcW3SPjMUNOMcQH2qBfJ+kvqZeVCMiTR1Gfecz9
uvR72mCX8tWqqoP/x7GFWqh31Q==
5. This step requires access to the GUI on a local system and GUI
applications on the remote system. If you've followed the
instructions so far in Chapters 1 and 2, you'll have a number of
systems that meet these requirements. With that in mind, log in to
the noted remote system from a local GUI-based command line with
the following command (substitute an appropriate hostname or IP
address as needed).
# ssh -X root@192.168.122.51
Note you will have to install xorg-x11-apps* packages to test xclock
etc on remote server. To do this you will need to setup
server1.dnoexample.com to have a repository from
https://192.168.122.1/inst/ rhel64vmhost1.dnoexample.com the
repository can be setup as follows:
a) Copy rhel-source.repo to new repository local.repo:
#cd /etc/yum.repos.d/
#cp rhel-source.repo rhel64vmhost1.repo
b) Amend new repository rhel64vmhost1.repo to setup
repository pointing at copy of RHEL 6.4 ISO files served
using http from rhel64vmhost1 as follows:
[rhel64vmhost1]
name=Red Hat Enterprise Linux 6.4 served from

baseurl:http://192.168.122.1/inst/
enable=1
gpgcheck=1
gpgkey=http://192.168.122.1/inst/RPM-GPG-KEYredhat-release
c) Setup new repository rhel64vmhost1:
#yum clean all
#yum update
d) Test new local repo:
#yum listrepo
e) Install missing package gcc:
#yum install xorg-x11-apps*
6. Now try to open a GUI application on the remote system, perhaps
even the Firefox Web browser (if that's installed) with the firefox
command. To confirm success, look at the title bar of the window
that appears. It should display a message with the location of the
remote application, such as:
#xclock
xClock (on server1.example.com) should be shown in title of window
opened by xclock cmd.
7. Exit from the remote application and then exit from the remote
system.
Lab 7
A) In this lab, you'll perform three tasks associated with one of the
VMs created in previous labs:
1. Start a VM from the command line.
#virsh start tester1.dnoexample.com
2. Stop a VM from the command line.
#virsh destroy tester1.dnoexample.com
3. Configure that VM from the command line.
#virsh autostart tester1.dnoexample.com

To turn off autobooting for VM:
#virsh autostart disable tester1.dnoexample.com
Above covers all rest of Lab 7.
B) You may recognize these tasks from the RHCSA objectives. The
process should be fairly simple. First, take account of currently
configured VMs with the following command:
# virsh list --all
From the VMs that appear in the output, pick one that isn't currently
running. If the server1.example.com system is not running, start it.
Confirm that it is currently running. Use the ssh command to access
a remote console on that VM system.
Now from the command line of the host physical system, stop that
virtual console. What command actually performs the task? Confirm
the result with the virsh list --all command.
C) Now, if you want to set up the server1.example.com system to
start automatically during the boot process, run the following
command:
# virsh autostart server1.example.com
To confirm the change, review the contents of the
/etc/libvirt/qemu/autostart directory. Next, enter the VM system and
run the ifconfig command to confirm the IP address of that VM's
network card. If you've configured this particular
server1.example.com system per the instructions discussed in
Chapter 1, that IP address should be 192.168.122.50.
Now power down any currently running VMs, and reboot the physical
host system. When the system boots again, log in to the local host
system. Don't start any hypervisors. Run the ssh commands
described in Lab 7. If it works, then you should be able to connect to
the VM as if it were a remote system.
Exit from the remote system and run the virsh list --all command.
You should see output similar to:
Id Name
State
----------------------------------------------4 server1.example.com
running
D) Now power down the remote system. You can ssh again into the
remote system and run the poweroff command directly from there.
Run the exit command immediately, or just wait until the VM has
had a chance to shut down. Now how do you reverse the process, so
this system does not start the next time you reboot the physical
host system?
Lab 8
A) In this lab, you'll use the commands described at the end of
Chapter 2 to test connections to available services. If you've created
the network installation servers described in Chapter 1, there will be
at least FTP and HTTP servers active on those systems. The default
ports for these services are 21 and 80, respectively. Try the telnet
localhost 21 command on a local system, where the vsFTP service is
active. Look at the following output:
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 (vsFTPd 2.2.2)
B) Now exit from the local connection. Confirm the IP address of the
local system with the ifconfig eth0 command. It should be an
address such as 192.168.122.50. Log in to a remote VM such as
tester1.example.org with a command like ssh
root@192.168.122.150. Now try the same command again from that
remote system; for example, for the server1.example.com system
on IP address 192.168.122.50, run the following command:
Note you will need to install telnet to perform this test:
#yum install telnet
# telnet 192.168.122.50 21
Do you get a "connection refused" or a "no route to host" message?
What do each of those messages mean? It's acceptable if you're not
certain about how to address this issue now, as firewalls are not
covered until Chapter 4.
C) Now try nmap on the local system with the following command:
# nmap localhost
Starting Nmap 5.51 ( http://nmap.org ) at 2015-03-04 17:13

GMT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000040s latency).
Other addresses for localhost (not scanned): 127.0.0.1
Not shown: 990 closed ports
PORT
STATE SERVICE
21/tcp open ftp
22/tcp open ssh
25/tcp open smtp
53/tcp open domain
80/tcp open http
111/tcp open rpcbind
631/tcp open ipp
5900/tcp open vnc
5901/tcp open vnc-1
5902/tcp open vnc-2
D) Now from the tester1.example.com system, review what other
systems on the local network can see from the following command.
Pay attention to the differences. That will give you hints on what
services are blocked by firewalls. Those firewalls may go beyond
that configured with the iptables command discussed in Chapter 4.
You will need to setup tester1.dnoexample.com to take its repository
served via http from rhel64vmhost1.dnoexample.com so you can
install nmap package:
a) Copy rhel-source.repo to new repository local.repo:
b) Amend new repository rhel64vmhost1.repo to setup
[rhel64vmhost1]
enable=1
gpgcheck=1
c) Setup new repository rhel64vmhost1:
#yum clean all
#yum update
d) Test new local repo:
#yum listrepo
e) Install missing package gcc:
#yum install nmap
# nmap 192.168.122.50
Chapter 3 Fundamental Command Line Skills LABS

During the Red Hat exams, the tasks will be presented electronically.
Therefore, this book presents most of the labs electronically as well.
For more information, see the Lab Questions section toward the end
of Chapter 3.
While there's no longer a separate troubleshooting section on the
RHCSA/RHCE exams, troubleshooting skills are still useful on handson exams--and on the job. So the first four lab will help you set up a
troubleshooting scenario. Standard warning: these labs, even when
properly executed, can render a system unusable. So do not run
these labs on a system where you need the data. Worst case, you
should be prepared to reinstall RHEL 6 on that system.
A) For the first four labs, you'll need to execute scripts from the
Chapter3/ directory of the CD included with the book. For example,
the script for the first lab is called Ch3Lab1. In all cases, you'll need
to copy the script to the server1.example.com test system. The
following steps assume the system is on a KVM-based virtual
machine. If it's on a different virtual machine manager such as
VMware or Virtualbox, you'll have to consult the documentation for
that virtual machine manager, at least for instructions on how to
connect a CD/DVD drive. But remember, only KVM is a virtualization
technology found on RHEL 6. Don't look at the contents of the
copied scripts or files, or the files in the /root/backup directory, until
the lab is complete.
The following are steps common to those first four labs.
1. Open the KVM Virtual Machine Manager from a GUI command line
with the virt-manager command.
2. Connect to the localhost (QEMU) system.
3. Double-click on the virtual machine with the

server1.example.com system. In the window that appears, click
View | Details.
4. Insert the CD for the book. Use the options that appear to connect
the CD/DVD drive to the virtual machine. Return to the console for
the virtual machine by clicking View | Console.
5. Boot the server1.example.com system. Mount the book CD with
the mount /dev/cdrom /media command.
6. Log in to the root administrative account.
7. Make sure you're in the /root directory with the cd /root
command. Copy the noted scripts (and associated test files) from
the CD to the root user's home directory with the cp
/media/Chapter3/Ch3Lab* ~ command.
8. These labs should work even if the /root/backup directory exists,
though you'll see an error message if it does.
9. Make sure the scripts are executable; run the chmod +x Ch3Lab?
command.
Files copied to server1.dnoexample.com as required.
Lab 1
This lab is based on the Ch3Lab1 script, available in the Chapter3/
subdirectory, as described earlier. If you followed the instructions at
the beginning of this section, the script should be available in the
/root directory. Navigate to that directory and take the following
steps:
1. Execute the script for this lab with the ./Ch3Lab1 command.
2. Deactivate the current network device. If it's eth0, run the ifdown
eth0 down command. If uncertain, run the ifconfig command;
substitute for eth0 as needed.
3. Restart networking with the /etc/init.d/network restart command.
What happens? Can you connect? Start looking through network
configuration files until you can identify and repair the problem.
4. If you don't see the problem right away, go through the different
configuration files discussed in the chapter. You may need to make a
couple of changes to a configuration file.
5. Once you've identified and fixed the problem in the appropriate

configuration file, you'll be ready to run the /etc/init.d/network
restart command and see successful messages.
6. Make sure the system configuration works after a restart of the
/etc/init.d/network script, as well as a system reboot.
7. If you still have problems, look at the file in the /root/backup
directory. If you're not sure which file has been changed, run the ls
-ltr command. It'll be the last file listed in the output. Even if you
don't have problems, look at the file in that directory. You may have
forgotten something.
Answer:
/etc/sysconfig/network file has changed to:
NETWORKING=no
HOSTNAME=server1.example.org
To fix amend this file to:
NETWORKING=yes
HOSTNAME=server1.dnoexample.com
GATEWAY=192.168.122.1
Restart networking:
#service network restart
Lab 2
steps:
1. Execute the script associated with this lab with the ./Ch3Lab2
command.
2. Test connections to local and remote systems, such as the
hostname or FQDN for the local system and the IP address of the
nameserver in the /etc/resolv.conf file. Try the ping command as
appropriate.
3. Review applicable network configuration files. Run the ifconfig
command. Review the information given for consistency. Can you
identify the problem yet?
4. If you can't yet identify the problem, open the Network Manager
Network Connections tool. Review the wired Ethernet connections. If
you see the inconsistency, address it.
-ltr command. It'll be the last file listed in the output.
7. After completing this lab, restore the latest file copied to the
/root/backup directory to its original location. The standard directory
is described in the body of this chapter. Then run the chattr -i
/root/backup/* command; otherwise, Lab 3 won't work.
Answer:
File /etc/sysconfig/network-scripts/ifcfg-eth0 was amended as
follows:
IPADDR=192.168.12.51
From:
IPADDR=192.168.122.51
So eth0 is now configured on a new network subnet and cant reach
192.168.122.1 NIC on rhel64vmhost.dnoexample.com.
To fix amend IPADDR back to 192.168.122 subnet and restart
networking.
Confirm you can now reach rhel64vmhost1.dnoexample.com.
Lab 3
steps.
Be aware, this lab assumes the first Ethernet adapter on the system
is active, as device eth0. If that isn't the case on your test system,
the script used in this lab won't work.
1. Execute the script for this lab with the ./Ch3Lab3 command.
2. Test connections to local and remote systems, such as the
hostname or FQDN for the local system or the IP address of the
nameserver listed in the /etc/resolv.conf file. Use the ping command
as appropriate.
3. Review applicable network configuration files. Run the ifconfig
command. Can you identify the problem yet?
4. If you can't yet identify the problem, try the ifconfig -a command.
Do you see a difference in the output? What do you do?
Answer:
Primary NOC eth0 was down.
Up eth0 as follows:
#ifup eth0
Lab 4
the beginning of this section, the script should be available in your
steps:
1. Execute the script associated with this lab with the ./Ch3Lab4
command.
2. Test connections to remote systems, such as the hostname or
FQDN for the local system. Try the ping command as appropriate, on
local and remote hostnames and IP addresses. Can you identify the
problem yet?
-ltr command. It'll be the last file listed in the output.
Answer:
File /etc/resolv.conf was amended:
From:
So any name resolution will fail as server is trying to use a
nameserver that doesnt exist.
To fix amend /etc/resolv.conf:
Lab 5
In this lab, you'll set up an /etc/hosts file for the different systems on
the local network. The instructions in this lab are based on the test
systems described in Chapter 1.
1. Back up the /etc/hosts file to an appropriate directory, such as
/root.
2. Open the /etc/hosts file. You'll probably see IPv4 and IPv6 entries
for their respective loopback hostnames and addresses. That can
serve as a model for the other entries that you'll make in this file.
3. You'll probably see an entry with the local hostname and a
comment about it being added by the Network Manager. Do not
change that entry.
4. When all the noted systems are running, test the result. If these
systems are on virtual machines, that may depend in part on the
activation of IP forwarding as discussed in Chapter 1. Run the ping
command, first on each IP address in /etc/hosts, and then on each
hostname in /etc/hosts.
Answer:
Following added to /etc/hosts on each server.
192.168.0.40
192.168.122.1
192.168.100.1
192.168.122.51
192.168.122.151
rhel64vmhost1 rhel64vmhost1.dno.com
rhel64vmhost1.dnoexample.org
server1 server1.dnoexample.com
tester1 tester1.dnoexample.com
192.168.100.51 clone1 clone1.dnoexample.org

192.168.100.101 outsider1 outsider1.dnoexample.org
Lab 6
In this lab, you'll use the system-config-network configuration tool
from the console. But before you do so, remember to back up
appropriate configuration files. As this is a console tool, you'll have
to use the TAB and ENTER or SPACEBAR keys to make selections.
1. Back up the network configuration files for the first Ethernet
adapter from the /etc/sysconfig/network-scripts directory with a
command like the following:
# cp /etc/sysconfig/network-scripts/ifcfg-*eth0 /root/
2. Open the system-config-network configuration tool from a
command line with the command of the same name.
3. In the console menu that appears, select Device Configuration
and press ENTER.
4. In the Select A Device Menu that appears, select the first Ethernet
network card, and press ENTER.
5. Make a change in the current configuration. Assuming a static IP
address configuration for one of the systems described in Chapter 1,
you should be able to make a minor change in the IP address. For
example, you could change the server1.example.com IPv4 address
from 192.168.122.50 to 192.168.122.51. Highlight OK and press
ENTER.
6. You're taken back to the Select A Device screen. Highlight the
Save option and press ENTER.
7. You're taken back to the Select Action screen. Make sure
Save&Quit is highlighted and press ENTER.
8. Deactivate and then reactivate the first Ethernet card with the
ifdown eth0 and ifup eth0 commands, and check the result with the
ifconfig eth0 and route -n commands. The configuration of the
network card and the associated routing table should reflect the
new configuration.
9. Use the diff command to analyze the difference between the ifcfgeth0 files in the /etc/sysconfig/network-scripts and the /root
directories. (If you've previously used the Network Connections tool,
the file name may be ifcfg-System_eth0.)
10. If you're really interested in the differences, compare files

created with static and a dynamic IP address. In the system-confignetwork tool, that's based on the Use DHCP option in Step 5.
11. To restore the original configuration, restore the ifcfg-eth0 file to
the /etc/sysconfig/network-scripts directory and restart the network
with the /etc/init.d/network restart command.
Answer:
All performed the network manager adds the following to the ifcfgeth0 file:
Changed BOOTPROTO to none from STATIC.
Added:
IPV6INIT=no
USERCTL=no
Lab 7
Repeat the process described in Lab 6 with the Network Connections
tool. To open it, start a GUI and click System | Preferences | Network
Connections; alternatively, from a command line, run the nmconnection-editor command. That command also works from a
remote console, as long as you've logged in with the help of the ssh
-X command described in Chapter 2.
Answer:
All performed, the nm_connection_editor run from ssh session with
X flag amended the ifcfg-eth0 file as follows:
Amended BOOTPROTO from static to none.
Added:
PREFIX=24
DEFROUTE=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="System eth0"
LAST_CONNECT=1425518253
Chapter 4 RHCSA-Level Security Options - LABS

of Chapter 4.
The Red Hat exams are unique based on their reliance on labs and
hands-on demonstrations. Be aware, while Labs 1 and 2 cover
different topics, they are designed to be run consecutively. The
same is true for Labs 5, 6, and 7, which are also designed to be run
consecutively.
Lab 1
In this lab you'll explore the role of permissions and the SUID bit. To
do so, you'll create a simple script in the /usr/local/bin directory. Call
it script1.
1. In a text editor, open file script1 in the /usr/local/bin directory.
2. Enter the following lines in that file:
#!/bin/bash
/bin/ls > filelist
3. Save the file.
4. Try to execute that script as the root administrative user. What
happens?
Answer:
The default umask has set the permissions of script1 file as rw-rr
so even script owner root does not have execute permission to run
the script.
5. Set up execute permissions for the user owner of the script1 file
with the chmod u+x /usr/local/bin/script1 command. Can you now
execute the script as the root administrative user?
Answer:
#chmod +x script1
#./script
#cat filelist
6. Now set up execute permissions for other users in the script1 file.
Log in as a regular user. Can you now execute the script as a regular
user?
Answer:
#chmod +x script1
#su doldham
#cd /usr/local/bin
#./script1
Note the script will run but as other users dont have the permission
to write into /usr/local/bin the ls output redirection into the file filelist
fails. To fix add other user write permissions to /usr/local/bin
directory. Also it will fail if you dont remove the original copy of
filelist output file created by first run as root user.
#chmod o+w /usr/local/bin
#./script1
#cat filelist
as root
as doldham
7. As it's a big security risk to set SUID permissions on a shell script,

don't do that on the script1 file. Instead, remove SUID permissions
on the /usr/bin/passwd executable file with the chmod u-s
/usr/bin/passwd command.
Answer:
#chmod u-s /usr/bin/passwd
8. Try to run the passwd command as a regular user. What happens?
Did your password change? Try again. What worked when prompted
for the current password?
Answer:
You can enter your password and enter the new password twice as
normal but then you get a Authentication token manipulation error
and password has not changed. Same happens the second time.
9. Return to the root user account, and restore SUID permissions on
the /usr/bin/passwd file.
Answer:
#chmod u+s /usr/bin/passwd
10. Try to run the passwd command again as a regular user. Change
your password. What happens this time?
Answer:
The change of password now works again for a regular user.
Lab 2
In this lab, you'll use the script created in Lab 1. You'll set up regular
permissions on that script, and then configure ACLs for that script to
be executed by a regular user. It also assumes that the filesystem
with the /usr/local/bin directory is the top-level root directory, and is
not already mounted with ACLs.
1. Change the permissions on the script1 file created in Lab 1 with
the chmod 644 /usr/local/bin/script1 command.
Answer:
#chmod 644 /usr/local/bin/script1
2. Log in as a regular user. Try to execute that script. What happens?
Answer:
As the script1 now has no execute permissions you cant run it as
root or a regular user.
3. Remount the top-level root directory (/) with ACLs with the
following command:
# mount -o remount,acl /
As long as the /etc/fstab file is configured in the top-level root
directory (/), this command should work. To verify, run the mount
command by itself; it should show output similar to:
/dev/vda2 on / type ext4 (rw,acl)
Answer:
/dev/sda2 on / type ext4 (rw,acl)
So root filesystem mounted on / including /usr/local/bin subdirectory
is now mounted to allow ACLs.
4. Now you'll be able to set ACLs on the noted script. Configure read
and execute ACLs for one regular user on the script1 file. Verify with
the getfacl command.
Answer:
#setfacl m u:doldham:r-x /usr/local/bin/script1
#getfacl /usr/local/bin/script1
getfacl: Removing leading '/' from absolute path names
# file: usr/local/bin/script1
# owner: root
# group: root
user::rwuser:doldham:r-x
group::r-mask::r-x
other::r-5. Repeat Step 2, logging in as the regular user given ACL privileges
to the script1 script. What happens?
Answer:
The specified normal user with ACL access can run script1 but other
regular users still cannot.
6. If you want to restore the original configuration, delete the script1
file from the /usr/local/bin directory. If your original configuration did
not include ACLs on the top level root directory, you can restore that
situation with the following command:
Answer:
#rm /usr/local/bin/script1
#rm /usr/local/bin/filelist
# mount -o remount /
Lab 3
In this lab, you'll set ACLs for a regular user for the root
administrative user's home directory, /root. Start with setting ACLs
for the directory, and review the results from the regular user's
account. What files can be read from the /root directory? What else
do you have to do to set up ACLs on a specific file in the /root
directory?
Just make sure to disable ACLs on the /root directory when the lab is
complete. ACLs can be a risky business if the account of the subject
regular user is ever compromised.
Answer:
1) Add ACL to root filesystem:
#mount o remount,acl /
#mount | grep acl
2) Check normal user doldham access to /root directory:

#su doldham
#ls als /root
[doldham@rhel64vmhost1 ~]$ ls -asl /root
ls: cannot open directory /root: Permission denied
So with no ACLs set regular users cannot list the contents of
/root.
3) Add a ACL to allow regular user doldham to list files in the
/root dir:
#setfacl m u:doldham:r-- /root
5) Check normal user access for doldham account on /root:
#su doldham
#ls als /root
[doldham@rhel64vmhost1 ~]$ ls -asl /root
ls: cannot access /root/.tcshrc: Permission denied
ls: cannot access /root/.virt-manager: Permission
denied
ls: cannot access /root/.gconfd: Permission denied
ls: cannot access /root/.recently-used.xbel:
Permission denied
ls: cannot access /root/.ssh: Permission denied
ls: cannot access /root/..: Permission denied
ls: cannot access /root/.gconf: Permission denied
ls: cannot access /root/.bashrc: Permission denied
ls: cannot access /root/anaconda-ks.cfg: Permission
denied
ls: cannot access /root/.bash_history: Permission
denied
ls: cannot access /root/.bash_profile: Permission
denied
ls: cannot access /root/.xauthRzWwEK: Permission
denied
ls: cannot access /root/.dbus: Permission denied
ls: cannot access /root/.: Permission denied
ls: cannot access /root/install.log: Permission denied
ls: cannot access /root/install.log.syslog: Permission
denied
ls: cannot access /root/.lftp: Permission denied
ls: cannot access /root/.bash_logout: Permission
denied
ls: cannot access /root/.cshrc: Permission denied

ls: cannot access /root/.virsh: Permission denied
ls: cannot access /root/.virtinst: Permission denied
total 0
? d????????? ? ? ? ?
?.
? d????????? ? ? ? ?
? ..
? -????????? ? ? ? ?
? anaconda-ks.cfg
? -????????? ? ? ? ?
? .bash_history
? -????????? ? ? ? ?
? .bash_logout
? -????????? ? ? ? ?
? .bash_profile
? -????????? ? ? ? ?
? .bashrc
? -????????? ? ? ? ?
? .cshrc
? d????????? ? ? ? ?
? .dbus
? d????????? ? ? ? ?
? .gconf
? d????????? ? ? ? ?
? .gconfd
? -????????? ? ? ? ?
? install.log
? -????????? ? ? ? ?
? install.log.syslog
? d????????? ? ? ? ?
? .lftp
? -????????? ? ? ? ?
? .recently-used.xbel
? d????????? ? ? ? ?
? .ssh
? -????????? ? ? ? ?
? .tcshrc
? d????????? ? ? ? ?
? .virsh
? d????????? ? ? ? ?
? .virtinst
? d????????? ? ? ? ?
? .virt-manager
? -????????? ? ? ? ?
? .xauthRzWwEK
So with read ACL set for this user for /root directory allows
a list but not file information.
So if we now set a rad ACL on the file /root/install.log as
follows:
#setfacl m u:doldham:r-- /root/install.log
#su doldham
#ls asl /root/install.log
[doldham@rhel64vmhost1 ~]$ ls -asl /root/install.log
ls: cannot access /root/install.log: Permission denied
So even with a read ACL on /root directory and
/root/install.log file still no permission to list file.
We need to add execute ACL on /root for the user doldham
as follows:
#setfacl m u:doldham:r-x /root
#su doldham
#ls asl /root/install.log
[doldham@rhel64vmhost1 ~]$ ls -asl /root/install.log

52 -rw-r--r--+ 1 root root 41896 Feb 24 16:52
/root/install.log
Tidy up ACLs as root user:
#setfacl b /root/install.log
#setfacl b /root
#mount o remount /
#mount | grep acl
Lab 4
In this lab, you'll review the process for disabling and re-enabling
SELinux on a system. Review the current status of SELinux with the
sestatus command. You can disable SELinux through the
/etc/sysconfig/selinux file, or through the SELinux Administration
tool. Do so and reboot the system. Try the sestatus command again.
Re-enable SELinux and reboot the system. What happens? Does the
process take long? How many times does the system reboot? What
would happen if you had to wait for the relabel and the reboot
process during a Red Hat exam?
Answer:
1) To check current selinux status:
#sestatus
SELinux status:
SELinuxfs mount:
Current mode:
Mode from config file:
Policy version:
Policy from config file:
enabled
/selinux
enforcing
enforcing
24
targeted
or
#getenforce
Enforcing
2) Amend selinux status:
From cmd line:
#setenforce permissive
Amend /etc/sysconfig/selinux file and reboot:
#vi /etc/sysconfig/selinux
Change as follows:
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#
enforcing - SELinux security policy is enforced.
#
permissive - SELinux prints warnings instead of enforcing.
#
disabled - No SELinux policy is loaded.
SELINUX=permissive
# SELINUXTYPE= can take one of these two values:
#
targeted - Targeted processes are protected,
#
mls - Multi Level Security protection.
SELINUXTYPE=targeted
#reboot
New sestatus:
#sestatus
SELinux status:
enabled
SELinuxfs mount:
/selinux
Current mode:
permissive
Mode from config file:
error (Success)
Policy version:
24
Policy from config file:
targeted
So selinux is now in premissive mode.
Once we amend /etc/sysconfig/selinux file back to enforcing
and reboot,
reboots twice and takes a lot longer.
So avoid changing the setting in file in exam if at all possible,
if you have to change mode use setenforce cmd from cmd line
unless they explicitly state file needs updated i.e. change is
reboot persitant.
Lab 5
In this lab, you'll set up one regular user in the SELinux guest_u
category. Remember that the relevant commands start with
semanage login. Given the options with the __default__ user, there
are multiple ways to meet the requirements of this lab.
Before making any changes, record the current status of SELinux
users; one method is with the following command, which records the
output in the selinuxusers file. (Strangely enough, a single forward

redirection arrow does not record the output from the noted
command.)
# semanage login -l >> selinuxusers
Your work will continue in Lab 6.
Answer:
Note package that provides semanage is not installed by part of
basic system, to install:
#yum whatprovides semanage
Loaded plugins: product-id, refresh-packagekit, security,
subscription-manager
This system is not registered to Red Hat Subscription
Management. You can use subscription-manager to register.
policycoreutils-python-2.0.83-19.30.el6.x86_64 : SELinux
policy core python utilities
Repo
: local
Matched from:
Filename : /usr/sbin/semanage
policycoreutils-python-2.0.83-19.30.el6.x86_64 : SELinux
policy core python utilities
Repo
: installed
Matched from:
Other
: Provides-match: /usr/sbin/semanage
#yum install policycoreutils-python-2.0.8319.30.el6.x86_64
# semanage login -l >> selinuxusers
#cat selinuxusers
Login Name
SELinux User
__default__
unconfined_u
root
unconfined_u
system_u
system_u
1) Set regular user test1 into the guest_u
MLS/MCS Range
s0-s0:c0.c1023
s0-s0:c0.c1023
s0-s0:c0.c1023
category:
#semanage login a s guest_u test1

Lab 6
Now with the regular user in the guest_u category, see what you can
do. Try the following actions:
1. Try logging into the GUI. What happens?

Answer:
Unable to login to GUI as a member of guest_u which is not allowed
gui access, but regular console login does work.
2. Log into a regular console. Try running the startx command. What
kind of user message do you get?
Answer:
You get a PAM authentication error stating cannot start X server
perhaps you dont have console ownership?
3. Back in the console, try the su and sudo commands. What
happens?
Answer:
When you try su cmd it fails to find the binary su.
When you try sudo bash cmd it failes stating /var/db/sudo and even
with correct password you get /root/.bashrc permission denied
message.
4. Try some of the system-config-* commands. What happens?
Answer:
When you try and run system-config-network cmd it opens windows
but actual ip details are missing.
All of these cmd issues at console are due to user being in the
guest_u group which limits user access.
Lab 7
In this lab, you'll activate the allow_guest_exec_content SELinux
boolean. Do so with a command that ensures that the change
survives a reboot. Once complete, log out as the configured guest
user, and log back in. Create a script; one simple script is shown
here:
#!/bin/bash
/bin/df > disks
Make sure to make the script executable. If the script runs and the
disks file is created, then you were successful.
When the process is complete, log in to the GUI as an unconfined
user and review the SELinux users in the GUI SELinux Administration
tool. (For this purpose, it's acceptable to log into the GUI with the
root administrative account.) Use the User Mapping section, and the
tools available to restore the original configuration as documented
in the selinuxusers file. Don't forget to deactivate the
allow_guest_exec_content boolean.
Answer:
1) Check normal state of selinux boolean
allow_guest_exec_content:
#getsebool allow_guest_exec_content
allow_guest_exec_content --> off
2) Set selinux boolean allow_guest_exec_content on:
#setsebool P allow_guest_exec_content=1
#getsebool allow_guest_exec_content
allow_guest_exec_content --> on
3) Login to console as test1 user assigned as guest_u.
4) Create disklist script:
#vi disklist
Add required code:
#!/bin/bash
/bin/df > disks
Save and Write the disklist script.
5) Add execute permission to script:
#chmod u+x disklist
6) Run disklist script:
#./disklist
#cat disks
Note script does run and produce the disks output file but
does error with /bin/df /var/lib/nfs/rpc_pipefs permission
denied but rest of mounts are listed.
Note before the setting of selinux boolean
allow_guest_exec_content the script fails to run with a
permission error even with user execute privilege.
Lab 8
In this lab, you'll create a new /ftp directory with SELinux contexts
appropriate for that directory. It should be based on the contexts in
the /var/ftp/pub directory. Use the knowledge that you gained in this
chapter to complete this lab. When you are done, restore the
original contexts on the /ftp directory. How do the SELinux contexts
differ? From what file did the restored contexts come from? Are the
restored contexts the same as when the /ftp directory was created?
Answer:
1) Create new directory /ftp and confirm selinux contexts:
#mkdir /ftp
#ls Zd /ftp
drwxr-xr-x. root root
unconfined_u:object_r:default_t:s0 /ftp
2) Change contexts to whats required for an ftp directory:
#chcon reference=/var/ftp/pub /ftp
#ls Zd /ftp
drwxr-xr-x. root root
system_u:object_r:public_content_t:s0 /ftp
3) Restore original contexts to /ftp directory:
#restorecon F /ftp
#ls Zd /ftp
drwxr-xr-x. root root system_u:object_r:default_t:s0
/ftp
Once you restore the context it changes from unconfined_u to
system_u.
Lab 9
At this point, you should have some data available in an audit.log

file in the /var/log/audit directory. If so, try to read the log file. If not,
make sure SELinux is set in enforcing (or at least in permissive)
mode. Make sure the audit service is working with the
/etc/init.d/auditd restart command.
Apply the sealert -a command to that file; you may want to redirect
that output to a text file for easier perusal. Can you identify
problems in the file? What users have been identified in that file?
Can you identify problem users and groups by their UID and GID
numbers? For more information on UIDs and GIDs, see Chapter 8.
Are there any proposed solutions?
If you don't have a current audit.log file or just need another
perspective, a sample audit.log file has been included on the
Chapter4/ directory of the CD. That directory also includes the
sealert.audit.output file, which is what happens to the file after the
sealert -a command has been applied to it.
Answer:
1) Start auditd daemon:
#service auditd start
2) Set auditd to run an runlevels 2345:
#chkconfig auditd on levels 2345
3) As we have turned off boolean allow_guest_exec_content,
so to generate an error login t console as test1 user and
run script ./disklist.
4) Note sealert is not install on a basic system to install:
#yum whatprovides /usr/bin/sealert
Loaded plugins: product-id, refresh-packagekit, security,
subscription-manager
This system is not registered to Red Hat Subscription
Management. You can use subscription-manager to
register.
setroubleshoot-server-3.0.47-6.el6.x86_64 : SELinux
troubleshoot server
Repo
: local
Matched from:
Filename : /usr/bin/sealert
#yum install setroubleshoot-server*
5) Run sealert cmd against current audit.log:

#sealert a /var/log/audit/audit.log
100% done found 1 alerts in /var/log/audit/audit.log
-------------------------------------------------------------------------------SELinux is preventing /bin/bash from execute access on
the file disklist.
***** Plugin catchall_boolean (89.3 confidence) suggests
*******************
If you want to allow_guest_exec_content
Then you must tell SELinux about this by enabling the
'allow_guest_exec_content' boolean. You can read
'user_selinux' man page for more details.
Do
setsebool -P allow_guest_exec_content 1
***** Plugin catchall (11.6 confidence) suggests
***************************
If you believe that bash should be allowed execute access
on the disklist file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep bash /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
So this shows that user as guest_u cannot run a script
unless the boolean allow_guest_exec_content is set on.
Chapter 5 The Boot Process - LABS

of Chapter 5.
For Labs 5 and 7, you'll need to execute scripts from the Chapter5/
directory of the CD included with the book. For example, the script
for the fifth lab is called Ch5Lab5. In all cases, you'll need to copy
the script to the server1.example.com test system. The following
steps assume the system is on a KVM-based virtual machine. If it's

on a different virtual machine manager such as VMware or
Virtualbox, you'll have to consult the documentation for that virtual
machine manager, at least for instructions on how to connect a
CD/DVD drive. But remember, only KVM is a virtualization
technology found on RHEL 6. Don't look at the contents of the
copied scripts or files, or the files in the /root/backup directory, until
the lab is complete.
The following are steps common to those first four labs.
3. Double-click the virtual machine with the server1.example.com
system. In the window that appears, click View | Details.
command. Copy the noted scripts (and associated test files) from
the CD to the root user's home directory with the cp
/media/Chapter5/Ch5Lab* ~ command.
8. These labs should work even if the /root/backup directory exists,
though you'll see an error message if it does.
9. Make sure the scripts are executable; run the chmod +x Ch5Lab?
command.
All Chapter 5 scripts copied to /root directory.
Lab 1
This lab is focused on runlevels and the boot process. You'll boot a
system into runlevel 1, with a full display of all boot messages. You'll
then set up the system to boot into runlevel 2 by default.
1. On what part of the boot hard drive is the first stage of the GRUB
bootloader typically located?
Answer:
A small 500m partition at the beginning of disk mounted on /boot.
2. Power-up the local system. During the boot process, when you
see the following message (the operating system name and version
number may vary), press a key.
Booting Red Hat Enterprise Linux Server (2.6.32-71.el6.x86_64) in 5
seconds....
Done.
3. Edit the default option. If the GRUB bootloader is already
password-protected, press P and enter the password.
4. Press A to edit the kernel command line.
Done.
5. What do you need to change and add to that command line to
boot the system into runlevel 3 with all boot messages displayed?
Remove rhgb quiet and add 3 to end of boot line.
6. Make required changes, and proceed with booting into runlevel 3.
Done.
7. Once the system is booted, what command verifies the current
runlevel?
#who r
or
#runlevel
8. Open the /etc/inittab configuration file. What's the current default
runlevel? Make a note of that number.
Default current runlevel is 5 multi usermode with X11 and
networking.
9. Edit the /etc/inittab configuration file so that the system boots
normally into runlevel 2.
#vi /etc/inittab
Change as follows:
id:2:initdefault:
Write and Save /etc/inittab file.
10. Reboot the system. How do you confirm that the changes
worked?
#who r
or
#runlevel
11. Edit the /etc/inittab configuration file. Restore the original
default runlevel.
#vi /etc/inittab
Change as follows:
Id:5:initdefault:
Save and Write /etc/inittab file.
Lab 2
This lab is focused on one thing you can do when booting into
runlevel 1, also known as single-user mode. As suggested by a nowsuperseded version of the RHCSA objectives, in this lab you'll
change the root administrative password. But here's a twist: assume
that you don't know the current version of that password. What do
you do?
Answer:
1) Break into boot sequence and edit boot line and boot into
single user mode.
2) Remove current root password from /etc/shadow file:
#vi /etc/shadow
Remove any text on root line after first colon and before
the 2nd colon.
Write and Save /etc/shadow file.
3) Now reset root passwd without knowing password:

#passwd
4) Reboot server:
#reboot
Lab 3
In this lab, you'll add one layer of security to the local system, by
adding an encrypted password to the GRUB menu.
Answer:
1) Backup /boot/grub/grub.conf file:
#cp /boot/grub/grub.conf /root
2) Generate new MD5 password for grub.conf file:
#grub-md5-crypt
Enter required grub password twice and a MD5 hash of
password is displayed.
$1$EWuR8$LpeFJglwRSd086C89i5q30
3) Edit /boot/grub/grub.conf and add password directive for 1st
stanza:
#vi /boot/grub/grub.conf
Add the following text after the default-0 line:
password md5
$1$EWuR8$LpeFJglwRSd086C89i5q30
Write And Save /boot/grub/grub.conf file.
4) Reboot server:
#reboot
5) Break into boot sequence and you will see that now you
only get b to boot or p for password options, you will have
to enter password prior to accessing the rest of the options.
Lab 4
In this lab, you'll set up a second stanza in the GRUB configuration
file. Before getting started, it's best to back up the file. For example,
the following command backs up the file to the root user's home
directory (/root):
# cp /boot/grub/grub.conf ~
In the second stanza, you'll set up a system that boots into runlevel
1, with boot messages shown on the screen. Make sure to label that
stanza appropriately, so the option Single User Mode appears in the
GRUB menu. To prove the result, reboot the system, check the
menu, and boot into the Single User Mode option.
Password-protect that stanza using the techniques described in Lab
3. Reboot the system. If successful, when you select the Single User
Mode option, the GRUB menu should prompt for the password that
was just created.
Answer:
1) Backup /boot/grub/grub.conf file:
#cp /boot/grub/grub.conf /root/
2) Add 2nd required stanza to grub.conf file, which boots into
runlevel 1 with full messages and add a password to
stanza:
Copy the 4 lines starting with title line from the existing
stanza and paste them at bottom of the file.
Generate another grub password as per Lab 3 and add the
password directive after the new title line you just pasted.
Amend the end of the Kernel line to remove rhgb quiet and
add 1.
Write and Save the /boot/grub/grub.conf file.
3) Reboot server:
#reboot
Now break into boot sequence and select new 2nd entry in
grub loader note you will now have to enter the new grub
password to then use this to boot into single usermode.
Lab 5
Be careful with this lab. The steps may render this system
unbootable, unless you understand the skills described in this
chapter. There's always the risk that key configuration files will not
be properly backed up, which means there's a risk of losing all data
on the system. If you understand these risks, proceed with this lab.
This lab is based on the Ch5Lab5 script described earlier. If you
followed the instructions at the beginning of this section, the script
should be available in your /root directory. Navigate to that directory
and take the following steps:
1.Log into the root account. If you're not already there, navigate to
the /root directory. Execute the script for this lab with the ./Ch5Lab5
command.
Script run.
2. Reboot the system.
System rebooted.
3. When you see the grub> prompt, use the skills described in this
chapter to identify the drive and partition with the /boot directory.
Hint: the stage1 file will still exist in that directory.
Answer:
1) Confirm what disk has the /boot directory:
grub>root
You should see:
(hd0,0): Filesystem type is ext2fs, partition type 0x83find
2) Load kernel to boot:
grub>kernel /vmlinuz-2.6.32-358.el6.x86_64 ro
root=/dev/vda2
You should see:
[Linux-bzImage, setup=0xnnnn, size=0xnnnnnn]

Note you can use the tab complete feature to get the
kernel file name, to confirm the boot disk normally
/dev/vda2.
But this will fail on server1.dnoexample.com as the root
filesystem is a logical volume LVM. So to perform this on
server1 i.e. a server where root volume is a LVM:
grub>kernel /vmlinuz-2.6.32-358.el6.x86_64 ro
root=/dev/mapper/vg_server1-lv_root
Note if you dont know, then add rdshell to end of kernel
line and once it fails check /dev directory tree to work out
where the root FS might be.
3) Load initramfs to boot:
grub>initrd /initramfs-2.6.32-358.el6.x86_64.img
You should see:
[Linux-initrd @ 0xnnnnnnn, 0xnnnnnnn bytes]
Note you can use the tab auto complete to confirm
initramfs file name.
4) You can now boot the system:
grub>boot
5) Once system has booted, move grub.conf from
/root/backup back to /boot/grub/:
#cp /root/backup/grub.conf /boot/grub/grub.conf
4. Where applicable, take advantage of the command completion
features at the grub> prompt. That's especially useful with the
kernel / and initrd / commands.
5. Don't forget, the kernel is first booted in read-only mode, as
specified by the ro option.
6. Remember that the top-level root directory is specified by the
root directive with the kernel command.
7. You don't have to remember the UUID associated with the toplevel root directory; in fact, it would be remarkable if you did. Just
use the partition or volume device file such as /dev/vda1. (Hint: in
the default installation created in Chapter 1, the partition device file
associated with the top-level root directory is not /dev/vda1.)
8. After entering the location of the Initial RAM disk, run the boot
command at the grub> prompt.
9. If your efforts are successful, the system will boot normally. In the
answer section, you'll see how to restore the backed-up GRUB
configuration file.
10. If your efforts are not successful, boot the system from the
installation DVD or the network boot CD and select Rescue Installed
System as described in the main body of the Chapter.
4 through 10 covered in 3.
Lab 6
This lab is focused on active terminals. Normally, Linux includes six
active terminals. If a GUI is installed and active with a graphical
display manager, that system is run in place of the first active
terminal. To review, you can switch between active terminals with
the ALT key and the function key associated with a terminal number,
such as ALT-F1. If in the GUI, you'll need to add the CTRL key to the
combination.
1. Back up the current versions of the /etc/sysconfig/init and
/etc/init/start-ttys.conf configuration files. A logical location is the
current user's home directory. If you make a serious mistake, you'll
be able to restore the system from the backup. In the worst case,
you'll be able to restore these files from backup by booting into
single-user mode, as described in Lab 1 and in the body of the
chapter.
Answer:
1) Backup /etc/sysconfig/init and /etc/init/start-ttys.conf files:
#cp /etc/sysconfig/init /root
#cp /etc/init/start-ttys.conf /root
2. Now limit the active consoles to terminals 1 and 2.
Answer:
1) Amend /etc/sysconfig/init file to limit access to 2 consoles:

#vi /etc/sysconfig/init
ACTIVE_CONSOLES=/dev/tty[1-6]
to:
Write and Save /etc/sysconfig/init file.
2) Amend /etc/init/start-ttys.conf to limit access to consoles 1
and 2 only:
#vi /etc/init/start-ttys.conf
env ACTIVE_CONSOLES=/dev/tty[1-6]
to:
env ACTIVE_CONSOLES=/dev/tty[1-2]
Write and Save /etc/init/start-ttys.conf
3) Reboot server:
#reboot
You will only be able to access consoles 1 and 2 now.
3. If successful, you'll be able to access only those two terminals on
the local system. Can you restore the original configuration?
Answer:
Reverse steps in 2) to reverse.
Lab 7
While there's no longer a separate troubleshooting section on the
RHCSA or RHCE exams, troubleshooting skills are still useful on the
exam--and on the job. So this lab will help you set up a
troubleshooting scenario.
This lab is based on the Ch5Lab7 script, similar to the Ch5Lab5

script described earlier. If you followed the instructions at the
beginning of this section, the script should be available in your /root
directory.
Navigate to that directory and take the following steps:
1. Log into the root account. If you're not already there, navigate to
the /root directory. Execute the script for this lab with the ./Ch5Lab7
command.
2. Deactivate the current network device. If it's eth0, run the ifdown
eth0 down command. Substitute for eth0 as needed. (The device
may be some other file like eth1 or System_eth0, as shown in the
output to the ifconfig -a command.)
3. Restart networking with the /etc/init.d/network restart command.
What happens? Do you have a network connection?
4. If you don't see the problem right away, go through the different
configuration files discussed in the chapter. You may need to make a
couple of changes to a configuration file.
5. When you've identified and fixed the problem in the appropriate
configuration file, you'll be able to run the /etc/init.d/network restart
command and see successful messages. If a "Device not managed
by NetworkManager" message appears, you may also need to run
the ifup eth0 command.
directory. To restore the system, copy that file to the /etc/sysconfig
directory.
Answer:
Script copied to /root.
1) Run script:
#cd /root
#./Ch5Lab7
Once the network was restarted eth0 had no configuration,
after checking
network configuration files I found that /etc/sysconfig/network
had been changed as follows:
NETWORKING=no
HOSTNAME=server1.example.org
To fix:
#vi /etc/sysconfig/network
Amend as follows:
NETWORKING=yes
HOSTNAME=server1.dnoexample.com
GATEWAY=192.168.122.1
Write and Save /etc/sysconfig/network file.
Restart network:
Chapter 6 Linux Filesystem - LABS

of Chapter 6.
If you've run the exercises while reading the chapter, it's best to use
a different virtual machine. If one is not available, the first thing you
should do is delete any logical volumes, volume groups, and
physical volumes created during the chapter. To that end, the
lvremove, vgremove, and pvremove commands should prove
helpful.
Next, delete the partitions created during the chapter. If you used
the spare hard drives created for the virtual machines specified in
Chapter 2, those would be in the /dev/sda and /dev/sdb hard drive
device files.
Lab 1
This lab assumes you have a new hard disk (or at least empty space
on a current hard drive where you can add a new partition). You can
simulate a new hard disk by adding appropriate settings to a KVM or
VMware virtual machine. In this lab, you'll create one new partition
using parted, format it to the ext4 filesystem, and configure it on the
/test1 directory in /etc/fstab so that the new partition is properly
mounted the next time you boot Linux. You'll also create a second
new partition using fdisk, format it, and configure as additional swap
space /etc/fstab so that space is also used the next time you boot
Linux. Oh yes, use the UUIDs in /etc/fstab.
Answer:
1) Create 500MB partition on /dev/sda spare 1GB disk using
parted utility:
#parted /dev/sda
Parted>mklabel msdos
(Setup basic disk partition
table)
Parted>#mkpart
Partition Type Primary partition
Partition Start 1 MB
Partition end 513 MB
2) Create a ext4 filesystem on the newly created partition:
#mkfs.ext4 /dev/sda1
3) Confirm new partition UUID number:
#blkid | grep sda1
4) Edit /etc/fstab file to add this disk to be mounted upon
boot:
#vi /etc/fstab
Add following line:
UUID=252176c1-add2-4116-95d7-de2fef60dcf5 /test1
ext4 defaults
12
Write and Save /etc/fstab file.

5) Create new mount point directory for this mount:
#mkdir /test1
6) Manually mount new Filesystem:
#mount t ext4 /dev/sda1 /test1
7) Create a new 500 MB partition on /dev/sda using fdisk:
#fdisk /dev/sda
Command> c
Command>u
Command>n
Turn DOS compatibility off

Set display units to sectors
Create new partition
Partition Type
Partition Number
First Sector
end of /dev/sda1
Last Sector
disk.
Command>w
p for primary
2
Take default i.e. after the
Take default i.e. end of this
Write changes to disk
8) Reboot for disk changes to be seen:

#reboot
9) Check partition can now be seen:
#fdisk l /dev/sda2
10)
Add new partition to be used as additional swap space:
#mkswap /dev/sda2
Make note of the UUID number of the new swap partition.
Edit /etc/fstab to mount this new swap partition upon
boot:
11)
#vi /etc/fstab
Add the following line:
UUID=f28bfa50-d5b7-4f44-b80c-88e1697d5418
swap defaults 0 0
swap
Write and Save /etc/fstab.

12)
Manually add the new swap partition:
#swapon /dev/sda2
13)
Confirm new swap space:
#swapon s
14) Reboot to confirm /etc/fstab entries are correct for both
new partitions:
#reboot
15)
Confirm both new partitions are in use:
#df h Confirm /dev/sda1 is mounted on /test1 as EXT4

Filesystem.
#swapon s
Confirm /dev/sda2 is mounted as swap
space.
Lab 2
In this lab, you'll set up a formatted logical volume, based on
partitions appropriately configured. If you use the partitions created
in Lab 1, don't forget to delete or at least comment out any
associated settings in the /etc/fstab file.
Once you create a VG, don't use it all. For example, if you've set up
a VG of 1000MB, configure 900 MB as a LV. Mount the resulting
logical volume on the /test2 directory, and confirm the result with
the mount and df commands. Name the VG volgroup1 and the LV
logvol1.
Set it up on the /test2 directory in the /etc/fstab file, formatted to
the ext4 filesystem. Use the UUID for the associated logical volume
device in /etc/fstab.
Answer:
1) Tidy up /dev/sda1 and /dev/sda2 created in Lab1 for use in
Lab2:
#vi /etc/fstab
Remove both lines added in Lab 1 and Write and Save
the /etc/fstab file.
#umount /test1
#swapoff /dev/sda2
#fdisk /dev/sda
Command> c
compatibility off.
Command>u
sectors.
Command> d
Partition.
Partition Number
Command>d
selected.
Command> w
to /dev/sda disk.
#fdisk /dev/sda
Turn DOS
Set display units to
Delete
1
Partition 2 will be auto
Write new partition table
Command>n
partition.
Partition Type
Partition Number
First Sector
Last Sector
Command>n
new partition.
Partition Type
Partition Number
First Sector
partition 1.
Last Sector
disk.
Command>w
changes to disk.
Create new
p for primary
1
Take default i.e. 2048
+500M i.e. start plus 500 MB
Create
p for primary
2
Take default i.e. from end of
Take default i.e. to end of
Write
2) Confirm you now have 2 new partitions on disk /dev/sda:

#fdisk l /dev/sda
3) Add both new partitions as LVM partitions:
#pvcreate /dev/sda1 /dev/sda2
4) Create new volume group called volgroup1:
#vgcreate volgroup1 /dev/sda1 /dev/sda2
5) Create new logical volume called logvol1:
#lvcreate L 800M volgroup1 n logvol1
6) Create a ext4 Filesystem on new LV:
#mkfs.ext4 /dev/volgroup1/logvol1
7) Confirm UUID of this new LV:
#blkid
8) Create new mountpoint directory for new LV:
#mkdir /test2
9) Edit /etc/fstab file to allow new LV to mount on /test2 at
boot:
#vi /etc/fstab
Add following line:
UUID=d36241e5-0458-4b9c-b97d-b27bf94456a1 /test2
defaults 1 2
ext4
10)
Manually mount /test2:
#mkdir /test2
#mount t ext4 /dev/volgroup1/logvol1 /test2
11)
Confirm /etc/fstab entries are correct:
#mount /test2
Lab 3
In this lab, you'll continue the work done in Lab 2, expanding the
space available to the formatted LV closer to the capacity of the VG.
For example, if you were able to follow the size guidelines in Lab 2,
use appropriate commands to increase the space available to the LV
from 900MB to 950MB. Set it up on the /test3 directory in the
/etc/fstab file, formatted to the ext4 filesystem. Use the UUID for the
associated logical volume device in /etc/fstab.
Don't forget to delete or at least comment out any settings from
previous labs in the /etc/fstab file. Just one hint: it's far too easy to
skip steps during the process.
Answer:
1) Tidy up from Lab 2:
#umount /test2
#vi /etc/fstab
Amend line added in Lab 2 to comment out the auto mount
of LV as follows:
#UUID=d36241e5-0458-4b9c-b97d-b27bf94456a1 /test2
defaults 1 2

2) Extend the LV from 800MB to 900MB:
#lvextend L 900M /dev/volgroup1/logvol1
ext4
3) Resize the ext4 Filesystem to match the new size of the LV:
#resize2fs /dev/volgroup1/logvol1
If required run e2fsck f /dev/volgroup1/logvol1.
4) Confirm UUID of LV:
#blkid| grep logvol1
5) Create new mountpoint /test3:
#mkdir /test3
6) Edit /etc/fstab file to add auto mount to /test3 directory:
#vi /etc/fstab
Add following line:
#UUID=d36241e5-0458-4b9c-b97d-b27bf94456a1 /test3 ext4
defaults 1 2
7) Test /etc/fstab entry for auto mount by mounting /test3:

#mount /test3
8) Confirm extra 100 MB has been added to mounted
Filesystem on /test3:
#df h
Lab 4
In this lab, you'll set up a filesystem formatted with LUKS
encryption. It's appropriate to use either the partition created in Lab
1 or the logical volume created in Lab 2. In fact, it would be helpful
to practice creating such encryption in both ways.
Of course, there are risks with any sort of encryption, especially if
the passphrase is lost. For the purpose of this lab, write down the
passphrase you choose! There is no requirement to first prepare the
filesystem with random data. Confirm the result.
Answer:
1) Tidy up from Lab 3:
#umount /test3
#vi /etc/fstab
Amend line added in Lab 3 to comment out the auto mount

of LV as follows:
#UUID=d36241e5-0458-4b9c-b97d-b27bf94456a1 /test3 ext4
defaults 1 2

#lvremove volgroup1 logvol1
#vgremove volgroup1
2) Amend /boot/grub/grub.conf to remove rd_NO_LUKS
directive:
Remove rd_NO_LUKS directive from 1st stanza kernel line.
Write and Save /boot/rub/grub.conf file.
3) Manually load encryption module dm_crypt:
#modprobe dm_crypt
4) Confirm dm_crypt module has loaded:
#lsmod | grep dm_crypt
5) If missing install crypt package:
#yum install cryptsetup-luks
6) Create an crypt passphrase for /dev/sda1:
#cryptsetup luksFormat /dev/sda1
7) Create UUID for encrypted /dev/sda1 device:
#cryptsetup luksUUID /dev/sda1
9114727b-4611-40bd-9f2e-e80013ab22b5
8) Open access to encrypted /dev/sda1 device:
#cryptsetup luksOpen /dev/sda1
Enter passphrase created in step 6).
9) Create an ext4 Filesystem on opened encrypted /dev/sda1

device:
#mkfs.ext4 /dev/mapper/9114727b-4611-40bd-9f2ee80013ab22b5
10) Create new mountpoint /test4:
#mkdir /test4
11)
Confirm new EXT4 filesystem UUID:
#blkid | grep 9114727b-4611-40bd-9f2ee80013ab22b5 | grep ext4

4986a7a4-90be-4368-b296-5e512358446e
12) Edit /etc/fstab file to add entry for new encrypted
/dev/sda1 auto mount:
#vi /etc/fstab
Add following line:
UUID= 4986a7a4-90be-4368-b296-5e512358446e /test4
defaults 1 2
ext4

** Note UUID of the EXT4 filesystem needs to be entered
in /etc/fstab. **
13)
Add new encrypted /dev/sda1 to /etc/crypttab file:
#vi /etc/crypttab
Add following line:
9114727b-4611-40bd-9f2e-e80013ab22b5 UUID=9114727b-4611-40bd-9f2ee80013ab22b5 none
Write and Save /etc/crypttab file.

** The 1st filed is a mapper name so you dont have to use
the UUID number here, but the 2nd field must be UUID of
encrypted /dev/sda1. **
14)
Test by rebooting:
#reboot
Enter passphrase created in step 6).

System should now boot and mount the encrypted Filesystem on
/test4 directory.
Lab 5
In this lab, you'll set up the LUKS-encrypted volume set up in Lab 4
in the /etc/fstab configuration file. Try it with the /dev/mapper device
file, as well as the associated UUID. Be sure to select the correct
UUID.
Answer:
See Lab 4 answer for Lab 5 it includes all required steps.
Lab 6
In this lab, you'll configure the automounter to automatically read
an installed CD/DVD. While NFS services are covered in Chapter 17,
the Red Hat RHCSA prep course does suggest that you need to know
how to use the automounter to connect to a shared NFS directory.
So the steps included in this lab are designed to help you set up a
simple shared NFS directory on one system, with connections
allowed from a second system. If you've set up the systems
described in Chapter 2, the first system would be
server1.example.com, and the second system would be
tester1.example.com. If you're using RHEL 6, it assumes that you
have a connection to the Red Hat Network. If you're using a rebuild
distribution such as Scientific Linux 6, it assumes you have a
connection to the standard repositories for that distribution as
discussed in Chapter 7. You should not need to read that chapter. As
long as networking is configured and connected to the Internet as
discussed in Chapter 3, a connection to such repositories is enabled
by default.
1. On the first system, back up your current /etc/auto.master and
/etc/auto.net configuration files.
Answer:
1) Backup /etc/auto.master and /etc/auto.net files:
#cp /etc/auto.master /root/
#cp /etc/auto.net /root/
2. Install NFS server configuration files with the following command:
Answer:
1) Install nfs-utils package on server1.dnoexample.com

# yum install nfs-utils
3. If you're working with the baseline virtual system configured in
Chapter 2, this NFS and related packages should already be
installed.
4. Share the /tmp directory by adding the following line to
/etc/exports. Be careful; don't include extra spaces:
Answer:
1) Edit /etc/exports and add export of /tmp directory on
server1.dnoexample.com:
#vi /etc/exports
Add following line:
/tmp *(ro)
Write and Save /etc/exports file.
5. Activate the NFS service, and disable any current iptables-based
firewall with the following commands. (Firewalls are described in
Chapter 4.)
Answer:
1) Restart NFS services on server1.dnoexample.com to enable
changes in
step 4:
#service nfsd restart
2) Edit /etc/sysconfig/iptables to add NFS ports:
-A INPUT -m state --state NEW -m tcp -p tcp --dport 2049
-j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 111 -j
ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 111
-j ACCEPT
-A INPUT -m
-j ACCEPT
-A INPUT -m
-j ACCEPT
-A INPUT -m
32927 -j ACCEPT
-A INPUT -m
-j ACCEPT
-A INPUT -m
-j ACCEPT
state --state NEW -m udp -p udp --dport 2049

state --state NEW -m tcp -p tcp --dport 20048
state --state NEW -m udp -p udp --dport

So open ports:
TCP: 111, 2049, 20048, 33672, 3000
UDP: 111, 2049, 32927
3) Restart iptables service:
Bonus: it's best if you can use the Firewall Configuration tool or
iptables commands to support access through a firewall, as it is a
RHCSA skill.
See above steps.
6. Record the IP address of the local system, as shown by the
ifconfig command. If it's the server1.example.com system described
in Chapter 2, it should be 192.168.122.50; but another IP address is
OK okay too.
Answer:
1) Confirm ip address of server1.dnoexample.com:
#ifconfig eth0
192.168.122.51
7. Go to another RHEL 6 system, such as the tester1.example.com
system described in Chapter 2. The following command should
confirm a good connection to the remote NFS server; substitute the
IP address of the remote system for remote_ipaddr.
Answer:
1) Confirm server1.dnoexample.com is now serving /tmp

using NFS from
tester1.dnoexample.com:
#showmount e 192.168.122.51
8. Now you can configure the local automounter for both a
connection to a CD/DVD and a shared NFS directory, using the
techniques described in the chapter.
Answer:
1) On tester1.dnoexample.com start automounter autofs
service:
#service autofs start
2) Edit /etc/auto.misc file to confirm CD is automounted:
#vi /etc/auto.misc
Confirm presence of following line:
cd
-fstype=iso9660,ro,nosuid,nodev
:/dev/cdrom
If line is missing add it and Write and Save /etc/auto.misc

file.
3) Edit /etc/auto.net file to add NFS mount of /tmp from
#vi /etc/auto.misc
Add following line:
dno
-ro,soft,intr
192.168.122.51:/tmp
Write and Save /etc/auto.misc file.

4) Reload autofs service:
#service autofs reload
5) Set autofs service to start upon boot:
#chkconfig autofs on levels 2345
6) Connect Cdrom from Parallels host to KVM.
7) Confirm autofs service is allowing auto mount of both

Cdrom and /tmp from server1.dnoexample.com:
#ls /misc/dno
#df h
You should now see correct output from both cmds.
Chapter 7 Package Management - LABS

of Chapter 7.
Lab 1
This lab assumes you've completed Chapter 1, Lab 2. While it's best
to have a working network connection to that system, it's certainly
possible to set it up on the same system as was done in the lab, as
long as the associated server is operational. In either case, you may
need to make sure any firewall is not running (or preferably, is
properly configured per Chapter 4.). Hint: based on Chapter 1, Lab
2, you'll be connecting to an FTP Server-based repository on IP
address 192.168.122.1.
You'll create a file.repo file in the /etc/yum.repos.d directory. It's
okay to use any existing files in that directory as a model. Use [inst]
as the ID, and install for the name of the repository. For reference,
the installation files created in that lab were copied to the pub/inst/
subdirectory. Make sure the local system is actually looking for the
repository and is using the correct file for verification.
Answer:
1) Copy rhel-source.repo to new repository local.repo:
2) Amend new repository rhel64vmhost1.repo to setup
[rhel64vmhost1]
enable=1
gpgcheck=1
3) Setup new repository rhel64vmhost1:
#yum clean all
#yum update
4) Test new local repo:
#yum listrepo
5) Install package xorg as a test of remote YUM repository:
#yum install xorg-x11-apps*
Lab 2
In this lab, you'll be identifying a potential security problem. You've
been given a tip by security staff that the problem is related to a
binary file that starts a server.
In this lab, you'll use a script in the Chapter7/ directory of the CD
included with the book. The script is called Ch7Lab2. You'll need to
copy the script to the server1.example.com test system created in
Chapter 2. The following steps assume the system is on a KVMbased virtual machine. If it's on a different virtual machine manager
such as VMware or Virtualbox, you'll have to consult the
documentation for that virtual machine manager, at least for
instructions on how to connect a CD/DVD drive.
3. Double-click the virtual machine with the server1.example.com
system. In the window that appears, click View | Details.

command. Copy the noted script (and associated test file) from the
CD to the root user's home directory with the cp
/media/Chapter7/Ch7Lab2 ~ command.
8. Make sure the script is executable; run the chmod u+x Ch7Lab2
command.
9. As the root user, execute the script with the ./Ch7Lab2 command.
Now you can start the actual work of the lab.
File copied to /root directory and has been run.
As suggested earlier, the problem relates to a binary file associated
with a server. Identify the binary file that's been changed and
should, therefore, be regarded with suspicion. Most Linux servers
are started with a binary file in the /usr/sbin directory. Address the
problem. Uninstall and reinstall the associated package. Don't lose
any changes made to the configuration file. If one or more of the
steps required in this lab take time, use that time to start work on
Lab 3.
Answer:
1) Install vsFTPd package on server1.dnoexample.com:
#yum install vsftpd*
3) Start vsFTPd service:
#service vsftpd start
4) Set vsFTPd to start upon boot:
#chkconfig vsftpd on levels 2345
5) Rerun lab script now vsFTPd is installed and running:
#cd /root
#./Ch7Lab2
6) Confirm whats changed in /usr/sbin directory:
#rpm Va | grep /usr/sbin
Note this might take some time to run.
You will see:
.T.
/usr/sbin/vsftpd
This means that the vsftpd binary file modification time has
changed since it was installed, so binary file had been
compromised.
7) Remove vsftpd package:
#yum remove vsftpd
8) Re-install vsftpd package:
#yum install vsftpd
9) Confirm binary is now as it should be:
#rpm Va | grep /usr/sbin
This time there should be nothing outputted.
Lab 3
Note as not registered can not run this lab.
This lab may not be possible unless updates are available from the
RHN (or if you're using a rebuild of RHEL 6, a remote repository with
updates, configured in files in the /etc/yum.repos.d directory). In this
lab, you will examine what happens when you run an update to
upgrade to newer versions of packages available for new features,
to address security issues, and more. Before you start, run the
following command to clear the cache, to enable the full set of
messages:
# yum clean all
Run the following command to send the messages to a text file:
# yum update > update.txt
If a lot of updates are available, this process may take some time. If
you want to watch, run the following command in a different
command line console.
# tail -f update.txt
If you want to download and install the updates, use the -y switch,
which answers, "yes" to all prompts. The complete command
becomes
# yum update -y > update.txt
After the download and installation is complete, review the

update.txt file. Note the first messages, how plug-ins are installed
from the /etc/yum/pluginconf.d/ directory. Note how it loads
information from the repositories, downloads headers, and resolves
dependencies.
Once dependencies are resolved, examine where the downloads
come from. Note how some packages are installed and how others
are updated.
Lab 4
In this lab, you'll create a job that ensures security updates are
automatically installed on the local system, on an hourly basis. You'll
need to log in as a regular user for this purpose, to ensure
configuration settings are saved to an appropriate directory. While
it's possible to set up such a job using the cron daemon, that's a
topic for Chapter 9.
Answer:
1) Login as a standard user on
rhel64vmhost1.dnoexample.com.
2) Confirm current security auto update configuration:
#gpk-prefs
Change the default of Daily updates to Hourly and the
Automatically install to only security updates. Then Close
gui.
Note gui updates following file:
/home/doldham/.gconf/apps/gnome-packagekit/update/
%gconf.xml
Lab 5
In this lab, you'll examine what happens when you update a kernel
RPM by installing it side by side with an existing kernel. If a newer
kernel is not available, use an older kernel available on the book CD,
in the Chapter 7/ subdirectory. Two kernels are available for this
purpose in that directory, both for 64-bit systems:
kernel-2.6.32-71.el6.x86_64.rpm
kernel-2.6.32-71.14.1.el6.x86_64.rpm
The associated kernel-firmware package is also included in the

Chapter7/ directory, as it is a dependency of the kernel. Just
remember, if you don't want the kernel that you install during this
lab, make sure to remove the package properly after the lab is
complete.
Answer:
1. Make a copy of the existing GRUB configuration file,
/boot/grub/grub.conf. Print it out or copy it to your home directory.
#cp /boot/grub/grub.conf /root
2. Make a copy of the current file list in the /boot directory. One
method uses the ls /boot > bootlist command, which writes the file
list to the bootlist file.
#ls las /boot > /root/bootlist
3. If a newer kernel is available, and you're connected to the RHN or
another appropriate repository, run the following command:
# yum install kernel
Another alternative is to download and install the RPM with the
yumdownloader command. Just be sure to use the rpm -i switch to
install the new kernel; otherwise, the command overwrites the
existing kernel. (If you're installing an older kernel, you'll have to
add the --force switch.) Two older kernels are available for this
purpose on the CD, in the Chapter 7 subdirectory.
As we are not connected to RHN we will try the kernels that
came with the exam guide.
#cd /data/rhcsa/Chapter7
#rpm ivH kernel-2.6.32-71.14.1.el6.x86_64.rpm
Note this failed as installed kernel is newer so should not
continue with this lab on rhel64vmhost1.dnoexample.com,
switch to server1.dnoexample.com vm and repeat above.
But to force install of older kernel:
#cd /RHCSA/Chapter7
#rpm ivH force kernel-2.6.32-71.14.1.el6.x86_64.rpm
4. Check the results in the GRUB configuration file,
/boot/grub/grub.conf. Observe the differences versus the old GRUB
configuration file, which you saved in Step 1. What is the default
kernel? If you happened to install an older kernel, is the default what
you expected?
Answer:
The older kernel has been added to grub.conf as the new first
stanza.
5. Check the results in the /boot directory. Observe the differences
with the original list of files in the /boot directory. Test the result with
a reboot.
Answer:
The following older kernel files have been added into /boot directory:
config-2.6.32-71.14.1.el6.x86_64
initramfs-2.6.32-71.14.1.el6.x86_64.img
symvers-2.6.32-71.14.1.el6.x86_64.gz
System.map-2.6.32-71.14.1.el6.x86_64
vmlinuz-2.6.32-71.14.1.el6.x86_64
When rebooted server1.dnoesampel.com is now running on older
kernel:
#uname a
Linux server1.example.com 2.6.32-71.14.1.el6.x86_64
To remove this older kernel perform the following:
1) Remove older kernel file:
#rpm ev kernel-2.6.32-71.14.1.el6.x86_64
2) Remove older kernel-firmware package:
#rpm ev kernel-firmware-2.6.32-71.14.1.el6
3) Confirm /boot/grub/grub.conf has been reverted to original
configuration:
#cat /boot/grub/grub.conf
I.E. the older kernel stanza should have been removed.
4) Confirm contents of /boot have reverted to original
contents:
#ls als /boot

5) Reboot to confirm all back to normal:
#reboot
6) Confirm original newer kernel is now running post reboot:
#uname a
Linux server1.example.com 2.6.32-358.el6.x86_64 #1
Lab 6
In this lab, you'll use both the yum command and the Add/Remove
Software tool to install packages from the Remote Desktop Clients
package group. At this point, multiple virtual machines should be
available. Be sure to install all packages from the Remote Desktop
Clients package group on both the server1.example.com and
tester1.example.com systems. On one system, use the Add/Remove
Software tool. On the second system, use the yum command.
The Remote Desktop Clients package group can be found in the
Desktop category in the Add/Remove Software tool. You could also
use a certain yum command for that purpose. Make sure every
package named in the group is installed on both systems.
Answer:
1) Install all remote desktop client package group packages
on
server1.dnoexample.com using yum:
Note the remote-desktop-group package groups packages
must be installed one by one.
So to list all packages within the group:
#yum groupinfo remote-desktop-clients
Optional Packages:
rdesktop
spice-client
spice-xpi
tigervnc
tsclient
vinagre
Install all of these packages:

#yum install rdesktop spice-client spice-xpi tigervnc
tsclient vinagre
2) Install remote desktop clients group package on
Using Add/Remove Software Tool gui:
Open Add/Remove Software gui from cmd line:
# gpk-application
Search for remote-desktop-client group and then click
Apply. Note for this package group this fails so again install
manually as follows:
#yum install rdesktop spice-client spice-xpi tigervnc
tsclient vinagre
Chapter 8 User Administration - LABS

of Chapter 8. Most of the labs for this chapter are straightforward
and require a very few commands or changes to one or two
configuration files.
Lab 1
For this lab, create a new user named newguy. Make sure that user
is a member of the users group. Create a second user named intern.
Create a special group named peons, and make both new users
members of that group. Assign a GID of 123456 to that group.
Answer:
1) Add newguy user account, creating home dir and adding
supplementary group of users:
#useradd -c"New Guy" -d /home/newguy -m -s /bin/bash
-g users newguy
2) Set password for newguy account:

#passwd newguy
3) Add intern user account:

#useradd cIntern d /home/intern m s /bin/bash
intern
4) Set Password for intern account:
#passwd intern
5) Create new group peons with a GID of 123456:
#groupadd g 123456 peons
6) Amend both newguy and intern users to have
supplementary group membership of peon group:
#usermod G peons newguy
#usermod G peons intern
Lab 2
In this lab, you'll make it a bit more difficult for the root
administrative user to log into any console. Make whatever changes
are required to limit local access from the root user to the sixth
virtual console.
Answer:
1) Backup /etc/securetty file:
#cp /etc/securetty /root/backup
2) Edit /etc/securetty file and limit access to only 6th virtual
console:
#vi /etc/securetty
Comment out all lines except following:
vc/6
tty6
Write and Save /etc/securetty file.
3) Test to confirm root can only login by using the 6th console:
Use ctrl-alt-F1 through ctrl-alt-F6 to confirm only access for
root from 6th console.
4) Note if you want to limit what consoles are actually started

edit
/etc/sysconfig/init file.
Look for line:
Amend as required.
Lab 3
Create a new user named senioradm. Set up that user with full sudo
privileges. But user senioradm should still be required to enter his
regular account password before he's allowed to run an
administrative command.
Answer:
1) Create new senioradm user:
#useradd -c"Senior Admin" -d /home/senioradm -m -s
/bin/bash senioradm
2) Set password for new senioradm user account:

#passwd senioradm
3) Confirm wheel group is enabled in /etc/sudoers file:
#grep wheel /etc/sudoers
You should see the following:
%wheel ALL=(ALL) ALL
# %wheel
ALL=(ALL) NOPASSWD: ALL
Confirm bold line is as above i.e. not commented out. If it is
commented edit file and remove comment hash at the
start of the bold line above.
4) Add the wheel group as a supplementary group to the
senioradm user account:
#usermod G wheel senioradm
5) Login as senioradm user and test sudo command:
#sudo bash
If you reach root prompt after entering your user password
for senioradm its worked.
Lab 4
Create a new user named junioradm. Set up that user with
privileges to run the fdisk command, with the help of sudo. In this
case, user junioradm should still be required to enter his regular
account password before he's allowed to run the fdisk command.
Answer:
1) Create new user junioradm account:
#useradd -c"Junior Admin" -d /home/junioradm -m -s
/bin/bash junioradm
2) Set password for junioradm user account:

#passwd junioradm
3) Edit /etc/sudoers to add specific access to /usr/sbin/fdisk

cmd for user junioradm:
#vi /etc/sudoers
## Allows user junioradm to access /sbin/fdisk cmd
junioradm ALL=/sbin/fdisk
Write and Save /etc/sudoers file.
4) Login as junioradm user account and test access to fdisk
cmd:
#sudo fdisk l
If you see the fdisk output its worked.
Lab 5
Make sure all new users get a copy of the info-* subdirectory of
the /usr/share/doc directory, including all files therein. Test the result
by creating a new user named infouser with the useradd command
and the User Manager.
Answer:
1) Copy /usr/share/doc/info-* to /etc/skel directory:
#cp ar /usr/share/doc/info-* /etc/skel
3) Create new infouser user account:
#useradd -c"Info User" -d /home/infouser -m -s /bin/bash
infouser
4) Set password for infouser account:

#passwd infouser
5) Login as infouser and confirm they have a copy of
/usr/share/doc/info-* subdirectory within their home
directory:
#ls als /home/infouser
You should see a subdirectory called info-* that includes the
same files as /usr/share/doc/info-* directory.
Lab 6
In this lab, you'll create a private directory for a group of engineers
designing some galleys. You'll want to create a group named galley
for the engineers named mike, rick, terri, and maryam. They'll want
to share files in the /home/galley directory. What do you need to do?
Answer:
1) Add new user accounts for mike, rick, terri and maryam:
#useradd
#useradd
#useradd
#useradd
maryam
-c"MIke" -d /home/mike -m -s /bin/bash mike

-c"Rick" -d /home/rick -m -s /bin/bash rick
-c"Terri" -d /home/terri -m -s /bin/bash terri
-c"Maryam" -d /home/maryam -m -s /bin/bash
2) Set password for new user accounts mike, rick, terri and
maryam:
#passwd
#passwd
#passwd
#passwd
mike
rick
terri
maryam
3) Create new group galley:

#groupadd galley
4) Add new group galley as a supplementary group for user
accounts mike, rick, terri and maryam:
#usermod
#usermod
#usermod
#usermod
G
G
G
G
galley
galley
galley
galley
mike
rick
terri
maryam
5) Create new directory /home/galley:

#mkdir /home/galley
6) Set /home/galley to be owned by group galley:
#chown nobody.galley /home/galley
#chmod 2770 /home/galley
7) Create a dummy file in /home/galley from user accounts
mike, rick, terri and maryam:
#vi /home/galley/mike.file
Enter user name in file, repeat for each user. Note all 4
users should be able to create files and edit each other files
using the group permissions.
8) Try to access directory for another user not in galley group
i.e. infouser:
#ls asl /home/galley
Note this user should NOT be able to either list contents
of /home/galley or read, edit any of the files created in step
7).
Chapter 9 - RHCSA-Level System Administration

Tasks - LABS
of Chapter 9. Most of the labs for this chapter are straightforward
and require a very few commands or changes to one or two
configuration files.
Lab 1
As the root user, create cron jobs that change the login message for
users at the text console. To do so, you'll want to change the
content of /etc/motd. Make sure that people who log in at different
times get appropriate messages:
If users log in between 7 a.m. and 1 p.m., create the login message
"Coffee time!"
If users log in between 1 p.m. and 6 p.m., create the login message
"Want some ice cream?"
If users log in between 6 p.m. and 7 a.m., create the login message
"Shouldn't you be doing something else?"
Answer:
1) Edit roots crontab file and jobs to set /etc/motd text based
on time of day:
#crontab e
Add the following lines:
#Example job definition:
#.------------------- minute (0-59)
#| .----------------- hour (0-23)
#| | .--------------- day of month (1-31)
#| | | .------------- month (1-12) OR jan,feb etc
#| | | | .----------- day of the week (0-6) OR sun,mon
etc note 0 is Sunday
#* * * * * cmd
0 7 * * * echo "Coffee Time!" > /etc/motd
0 13 * * * echo "Want some ice cream?" >
/etc/motd
0 18 * * * echo "Should'nt you be doing something
else?" > /etc/motd
Write and Save the crontab file.
3) Use date cmd to tmp set date and time to 06:59, and 17:59
to test above:
#date 031206592015
06:59 am
Set date to 12th March 2015
4) Logout and 1 minute later login to console.

You should now see the first message.
5) Use date cmd to tmp set date and time to 17:59 to test
above:
#date 031217592015
17:59
Set date to 12th March 2015
6) Logout and 1 minutes later login to console:

You should now see last message.
7) Use date cmd to set correct date and time.
#date ????????????
Lab 2
In this lab, you'll set up an at job as the root administrative user, to
save a list of currently installed RPMs in the /root/rpms.txt file. That
job will be run once, 24 hours from now. If you want to verify your
work, set up a second at job with the same commands to start 5
minutes from now.
Answer:
1) Set AT job to run in 24 hours to save installed package list
to /root/rpms.txt file:
#at now +1Day
at>/bin/rpm qa > /root/rpms.txt
at> CTRL-D
Repeat using +5Minutes and after 5 minutes cat
/root/rpms.txt if this lists installed package its worked.
Lab 3
In this lab, you'll set up a VNC server using the tigervnc package. Be
aware, if you're running a KVM-based VM on the local system, that
VM would actually have to be shut down for a real test of the VNC
server. (It's acceptable if that VM was just autostarted, as described
in Chapter 2, as long as the Virtual Machine Manager is not running.)
Since no remote physical system is assumed, you'll have to test the
result with the nmap and telnet commands. Be sure appropriate
ports are open from the localhost, along with a remote system. A
KVM-based VM is acceptable for that purpose.
Answer:
1) Confirm if vinagre tigervnc and tigervnc-server packages
are installed on
#rpm qa | grep e tiger e vinagre
If any of these packages are missing install them:
#yum install tigervnc-server
2) Edit /etc/sysconfig/vncservers file:
#vi /etc/sysconfig/vncservers
Amend this file as follows:
Defaults:
# VNCSERVERS="2:myusername"
# VNCSERVERARGS[2]="-geometry 800x600 -nolisten tcp
-localhost"
Change to:
VNCSERVERS="2:doldham"
VNCSERVERARGS[2]="-geometry 800x600"
Write and Save /etc/sysconfig/vncservers file.
3) Stop tigervnc server service:
#/etc/init.d/vncserver stop
4) Switch to user doldham:
#su doldham
5) Start vncserver process for this user:
#vncserver :2
6) Confirm vncserver is now running:
#/etc/init.d/vncserver status
You should see:
Xvnc (pid nnn) is running

7) Open vncserver ports in iptables:
#vi /etc/sysconfig/iptables:
5901 -j ACCEPT
5902 -j ACCEPT
8) Reload iptables service:
9) Note in KVM env this wont work , so just test telnet to port
from tester1.dnoexample.com:
#telnet 192.168.122.51 5902
Note you should connect if its running.
Lab 4
In this lab, you'll find the value of several different log files. In
preparation, use the wrong password to log in to a regular account.
Then take the following steps:
1. Navigate to /var/log as the root user. All of the files listed in this
lab are in that /var/log directory.
Answer:
1) Attempt login using doldham account with wrong password
on
server1.dnoexample.com.
2) Change directory to /var/log directory:
#cd /var/log
2. Explore the contents of the anaconda.* log files.
Answer:
1) Review the contents of the anaconda.* log files:

#cat anaconda.*
These various log file hold information on the installation
process.
3. Run the utmpdump btmp command. Do you see the login
attempt? Can you tell if it succeeded?
Answer:
1) Run utmpdump btmp cmd and look for a login attempt:
#utmpdump btmp
You can see attempt but only the ssh:notty is a give away
for unsuccessfully login. To confirm look in file
/var/log/secure.
4. Review the contents of the cron log file. Scroll through it. If your
computer has been on for a while, most of what you see will be
based on the run-parts /etc/cron.hourly command. Alternatively, if
you reboot on occasion, you'll see messages associated with the
anacron service.
Answer:
1) Review /var/log/cron file:
#more /var/log/cron
5. Review the contents of the dmesg log file. Compare the beginning
of it with the start of the anaconda.syslog file. Which one includes
the currently booted kernel?
Answer:
1) Review /var/log/dmesg:
#more /var/log/dmesg
2) Review /var/log/anaconda.syslog:
#more /var/log/anaconda.syslog
At start of both log files you see kernel to be loaded.
6. Navigate toward the bottom of the dmesg file. Can you identify
the amount of swap space? Can you identify one or more partitions
with the default EXT4 filesystem?
Answer:
1) Review /var/log/dmesg:
#more /var/log/dmesg
There is 4128760k of swap added on
/dev/mapper/vg_server1-lv_swap.
There are 3 EXT4 partitions mounted at boot time:
Dm-1, vda1 and dm-0 these point to:
Dm-0 points to UUID of LUKS encrypted partition.
Dm-1 points to vg_server1-lv_root LVM root partition.
Vda1 points to /boot partition
7. Review the maillog log file. If that file is short, there may be an
older maillog-* file; if so, review that as well. Do you see any
messages associated with mail messages?
Answer:
1) Review /var/log/maillog:
#more /var/log/maillog
There are 3 separate emails to root account with mail
references of:
D0D0A30C3
8DC8930CB
451FE3118
All had status of sent.
8. Review the secure log file. Navigate to the bottom of the file. Do
you see a message associated with the failed login?
Answer:
1) Review /var/log/secure:
#more /var/log/secure
There are 3 failed login messages that represent the 3 mistake

logins from above.
Mar 12 16:45:59 server1 sshd[3347]: Failed password
for doldham from 192.168.122.1 port 55684 ssh2
Mar 12 16:46:02 server1 unix_chkpwd[3350]: password
check failed for user (doldham)
Mar 12 16:46:08 server1 unix_chkpwd[3351]: password
check failed for user (doldham)
Mar 12 16:46:10 server1 sshd[3348]: Connection closed
by 192.168.122.1
9. Finally, review the Xorg.0.log file. Do you see any messages
related to the graphical screen in file? How does that work when you
didn't configure a GUI during the installation process?
Answer:
1) Review /var/log/Xorg.0.log:
#more /var/log/Xorg.0.log
Since RHEL v5 and onwards a gui configuration tool has been
included so gui is auto configured no need for the older
xorg.conf cd /data/ file.

RHCSA Exam Prep Answers

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RHCSA Exam Prep Answers

Uploaded by

Copyright:

Available Formats

RHCSA Exam Prep

Chapter 1 Prepare for Red Hat Hands-On

$su enter root password

i) Setup new repository local:

6) Confirm you can see test apache web page:

You should now see the required files.

d) Browse to new FTP server pub directory to confirm

I) Configure rhel64vmhost1 to use DNS lookup from home

restrict -6 default kod nomodify notrap nopeer

Write and Save /etc/named.conf file.

L) Install and configure Red Hat KVM.

2) Confirm correct HW modules have been loaded by installs:

To manually load module if missing:

This will now configure 2 virtual NICs:

Chapter 2 Virtual Machines and Automated

Packages Basic server plus desktop, fonts, X Window

1) Open Red Hat Virtual Manager:

24) Add Desktops-> Desktop, Fonts and X Window system

1) Make sure server1.dnoexample.com VM is shutdown.

Note that as we are cloning server1.dnoexample.org we only

B) In addition, when rebooting the system, you'll want to set this

#virt-install n tester1.dnoexample.com r 2048 vcpus=2

Hat NTP servers are listed click Forward.

1) Create kickstart file to help build

Set disk image size to 12 GB and make sure Allocate entire

9. Add the ks directive along with the URL of the network

4) Re-install outsider1.dnoexample.org from cmd line using

4. Repeat the process with a remote system such as

name=Red Hat Enterprise Linux 6.4 served from

#virsh autostart tester1.dnoexample.com

Starting Nmap 5.51 ( http://nmap.org ) at 2015-03-04 17:13

Chapter 3 Fundamental Command Line Skills LABS

3. Double-click on the virtual machine with the

5. Once you've identified and fixed the problem in the appropriate

192.168.100.51 clone1 clone1.dnoexample.org

10. If you're really interested in the differences, compare files

Chapter 4 RHCSA-Level Security Options - LABS

7. As it's a big security risk to set SUID permissions on a shell script,

2) Check normal user doldham access to /root directory:

ls: cannot access /root/.cshrc: Permission denied

[doldham@rhel64vmhost1 ~]$ ls -asl /root/install.log

output in the selinuxusers file. (Strangely enough, a single forward

#semanage login a s guest_u test1

1. Try logging into the GUI. What happens?

At this point, you should have some data available in an audit.log

5) Run sealert cmd against current audit.log:

Chapter 5 The Boot Process - LABS

steps assume the system is on a KVM-based virtual machine. If it's

3) Now reset root passwd without knowing password:

[Linux-bzImage, setup=0xnnnn, size=0xnnnnnn]

1) Amend /etc/sysconfig/init file to limit access to 2 consoles:

This lab is based on the Ch5Lab7 script, similar to the Ch5Lab5

Chapter 6 Linux Filesystem - LABS

Write and Save /etc/fstab file.

Turn DOS compatibility off

8) Reboot for disk changes to be seen:

Add new partition to be used as additional swap space:

Write and Save /etc/fstab.

Manually add the new swap partition:

Confirm new swap space:

Confirm both new partitions are in use:

#df h Confirm /dev/sda1 is mounted on /test1 as EXT4

2) Confirm you now have 2 new partitions on disk /dev/sda:

Write and Save /etc/fstab file.