Chapter 13. Exercises

Table of Contents

Concept Mastery
Initial Setup Exercise
Recovering the 'root' Password
View Logs
Manipulating Services
Manipulating the System Bootloader
Creating & Managing User Accounts
Creating Basic Partitions
Using Logical Volume Management (LVM)
User Collaborative Directory
Create a LUKS Encrypted Partition
Creating Swap Space Method #1
Creating Swap Space Method #2
Configure File System ACLs (Access Control Lists)
Manually Create a Software Repo
Manually Build an RPM
Manually Create a Bridge Networking Device
Establish Key-Based SSH Login
Create a Secure "Drop-box" for Anonymous FTP Upload
Apache User Home Directories
Apache User Authentication
Apache User Configuration with .htaccess
Apache User Based Security with LDAP Authentication
Apache Group Share
Configuring for Name Virtual Host Configuration
Configuring for CGI-BIN Scripts
Create & Install a Self-Signed SSL Certificate
Enable Home Directory Shares with Samba
Create a Public Share with Samba
NFS Server Setup
NFS Client Setup
NFS & AutoMount Setup
Create a Caching DNS Server
Create a Forwarding DNS Server
Configure postfix Email Server
iSCSI Initiator Setup

Concept Mastery

The exercises below will guide you through various operations to help "solidify" what we have learned in class. Some of these exercises are similar to those in the book. Also, some of them reference the exercises in the book.

Initial Setup Exercise

Setup a practice environment following instructions in RHCSA/RHCE Linux Certification Study Guide , Chapter 1.

As a matter of reference, the commands we used in class to create and clone virtual machines directly from the command line are listed below.

       `virt-install -n <name> -r <amount-of-ram> -l <location> -x <extra-parameters> --prompt`   1
       `virt-clone -o <vm> -n <new-name> -f <new-file> --prompt`    2

1

Enter the name of the machine, the amount of ram to be assigned to the machine, the location of the install media, and any extra parameters - such as the location of a kickstart file. The --prompt option will query you for additional info as required.

2

Enter the old machine name, the new machine name, and the file path/name as the flags. The --prompt option will query you for additional info as required.

Recovering the 'root' Password

In this exercise, we will use 'single user' mode to recover a root password.

  1. Reboot your virtual machine.
  2. Activate the GRUB Menu - press any key when the boot manager displays.
  3. Boot the system in Single User Mode - manipulate the kernel parameters.
  4. Set SELinux to Permissive Mode - use the command setenforce 0
  5. Change the root password - use the command passwd
  6. Set SELinux back to Enforcing Mode - use the command setenforce 1
  7. Activate runlevel 3 - use the command init 3
  8. Login as root with the new password

View Logs

In this exercise, we will view logs from two types of terminals.

  1. Launch a gnome-terminal session and browse the /var/log/messages file.
  2. Switch to a virtual terminal by pressing CTRL + ALT + F2, login as root, and view /var/log/secure.

Manipulating Services

In this exercise, we will manipulate the cups service. Note the importance of using the service ... as well as chkconfig commands to manipulate the services as needed.

  1. Check the status of the cups service:
    • Is it running now? service cups status
    • Is it configured to run on future boots? In which runlevels? chkconfig --list cups
  2. Stop the cups service: service stop cups
  3. Start the cups service: service start cups
  4. Configure cups to start automatically at boot: chkconfig cups on

Manipulating the System Bootloader

In this exercise we will modify the system bootloader in order to change how the system boots.

Creating & Managing User Accounts

This exercise will configure several users and groups. Note that these users and groups will appear in other exercises, so make sure to complete this exercise successfully. On your client virtual machines, perform these tasks:

  1. Create groups "goodguys" and "villains" by issuing groupadd goodguys villains. Note that a precaution can be taken to use custom GIDs so that the automatically created GIDs for the UPG scheme remain in sync with the usernames.
  2. Create users "bugs", "tweety" and "roadrunner" and make them members of "goodguys". useradd bugs tweety roadrunner
  3. Create users "taz", "sam", and "wiley" and make them members of "villains". useradd taz sam wiley
  4. Set sam's account to expire in 30 days.

Creating Basic Partitions

We will now create some basic partitions that will be used in other exercises. On your Host machine:

  1. Use virt-manager to create a 20 GB virtual disk for your Client VM.

Then on your client virtual machine:

  1. Use fdisk -luc to verify that it is seen after a reboot of the VM.
  2. Use fdisk to create a 5 GB partition (leaving the remainder unused.
  3. Create an ext4 filesystem on the new partition.
  4. Create a new directory at /shared/villains and mount the new filesystem there.
  5. Verify with df -h that the new space is seen.
  6. Create an entry in /etc/fstab to make it persistent.

Optional Steps:

  1. Save a test file to /shared/villains/.
  2. Use ls to verify that it was saved as intended.
  3. Use umount to unmount the new partition.
  4. Use ls to verify that the file is no longer seen.
  5. Remount the partition.

Using Logical Volume Management (LVM)

In this exercise, we will begin to work with Logical Volume Management (LVM). On your Client virtual machine:

  1. From the unallocated space on the disk you added in the previous exercise, create a 5 GB partition (type 8e) for LVM.
  2. Initialize it with pvcreate.
  3. Use vgcreate to create a volume group named "shared" from the physical volume.
  4. Use lvcreate to create a 2.5 GB logical volume.
  5. Create an ext4 filesystem on /dev/shared/goodguys.
  6. Create a directory /shared/goodguys and mount the LV there.
  7. Create an entry in /etc/fstab for persistance.
  8. Use df -h to verify the available space.
  9. Use lvextend to add another 1 GB to the new partition.
  10. Use resize2fs to grow the filesystem on /dev/shared/goodguys to use the new space.
  11. use df -h to verify the available space.

User Collaborative Directory

The steps below outline how to create a group-owned directory sufficient for several users working collaboratively.

  1. Create a shared directory, such as '/<filesystem>/<share-dir>'.
  2. Create the group and populate it with the users who are to write to the directory.
  3. Set up ownership of the specified directory: `chown nobody:<accessgroup>/<filesystem>/<share-dir>`.
  4. To set group permissions on <share-dir> w/sgid bit, no 'sticky bit': `chmod 2770 /<filesystem>/<share-dir>`.
  5. To set the 'sticky bit' on the directory: `chmod 3770 /<filesystem>/<share-dir>`.

Create a LUKS Encrypted Partition

See the section called "LUKS Encryption" for the steps used to create a LUKS encrypted partition.

Creating Swap Space Method #1

Add a new partition and use it for SWAP space. On your Client virtual machine:

  1. Use free -m to report the amount of swap your system is configured to use. Note that number.
  2. Create a new partition (this may be a new primary partition, or a logical partition on an extended partition, or you may need to add a new virtual disk, depending on your needs - - consult with the instructor if you need help making this determination) of 512 MiB and make it a "Linux Swap" partition (type 82).
  3. Initialize it with mkswap. Note the "UUID=..." in the output.
  4. Configure /etc/fstab to use that device by device name or, preferably, by UUID as swap.
  5. Activate the new swap partition with swapon.
  6. Use free -m to confirm that the new swap space is available.

Creating Swap Space Method #2

Create swap space from a file on disk. On your Client virtual machine:

  1. Use free -m to report the amount of swap your system is configured to use. Note that number.
  2. Create a new file for swap by using `dd` to write zeros to a file of 128 MiB.
  3. Initialize it with `mkswap`.
  4. Configure '/etc/fstab' to use that file (by pathname) as swap.
  5. Activate the new swap partition with `swapon`.
  6. Use `free -m` to confirm that the new swap space is available.

Configure File System ACLs (Access Control Lists)

This exercise will demonstrate how to set up access control list (acl) permissions for granular permission control. The exercise assumes that there are three available users on the system, in our instance they are "huey", "dewey", and "louie". Additionally, the file system to be configured must be mounted with "acl" capability. There are three options for this. See the section called "Access Control Lists" for more information on how to enable those options.

  1. Create a directory in "dewey's" home folder called "stuff". The full path will be '/home/dewey/stuff'.
  2. Set the 'x' permission (701) on "dewey's" home directory: `chmod 701 /home/dewey`.
  3. Set the facl permission on "dewey's" "stuff" directory: `setfacl -m user:huey:rwx /home/dewey/stuff`
  4. Set the facl mask on "dewey's" "stuff" directory: `setfacl -m mask:rwx /home/dewey/stuff`.
  5. The user "huey" should now be able to `cd` into "dewey's" home directory, but not be able to see, read, write, or list anything.
  6. The user "huey" should now be able to `cd` into "dewey's" "stuff" directory, and be able to create, edit, and delete files.
  7. The user "louie" should not be able to do any of the above.
  8. Use the command `getfacl <dir> to display the acl permissions.

Manually Create a Software Repo

See the section called "Managing & Creating a Software Repository" for the steps used to create repository capable of deploying packages.

Manually Build an RPM

The following exercise demonstrates the process of building a simple rpm package that can be delpoyed. Note that this is a simple exercise, there are many, many additional options available. See Fedora RPM Build Info and IBM RPM Build Info for additional information.

  1. As root, install the following packages: `yum -y install rpm-build rpmlint rpmdevtools tree`
  2. Create a project directory in your home directory[33]: `cd && mkdir hello-1.0`[34])
  3. Create bash script in the newly created project directory called 'hello.sh' with the following content:
        #!/bin/bash
        # hello.sh
        echo 'hello'
        exit 0
    
  4. Create a tarball of the project directory: `tar cvzf hello-1.0.tar.gz hello-1.0`.[35]
  5. Still in the home directory, create an rpm development environment: `rpmdev-setuptree`. This will create several directories that are beneath the 'rpmbuild' directory that will become the build environment.[36]
  6. Move the tarball we created to the SOURCES directory in the build environment: `mv hello-1.0.tar.gz rpmbuild/SOURCES`.
  7. Change into the 'rpmbuild/SPECS' directory and create a .spec file. Either of the following commands will create a pre-formatted ready-to-use file: `vim hello.spec` or `rpmdev-newspec -o hello.spec`. The next several items will deal with editing this pre-formatted file.
  8. On the Name line, insert the name hello. Note that there is no version or file extension info included.
  9. Insert a version, match the version on the tar.gz file: 1.0.
  10. Leave the release line empty.
  11. Insert a brief human-readable summary of the package all on one line.
  12. If your package will belong to a package group, insert a group name. It's also safe to delete this line.[37]
  13. Insert a license description of some type: GPL, GPLv3, Creative Commons, whatever, etc.
  14. Insert a home page URL or delete the line.
  15. Insert on the Source0 line, the full name of your tarball.
  16. Leave the BuildRoot line alone, if there is one.
  17. Unless your package has prerequisites needed before it can be compiled, delete the BuildRequires line. Note that, in this exercise, we are NOT building our package.
  18. Unless your package has prerequisites needed before it can work, delete the Requires line. This will be a list of the pre-requisite packages or versions need before your package can/will work.
  19. On a blank line below %description, insert a brief description of your package. Note that the summary and description are (and can be) similar (but different) as necessary.
  20. Leave the %prep and %setup lines alone.
  21. If your package does not need to be "built" (compiled), delete the %build, %configure, and make lines.
  22. Leave the %install section header alone.
  23. Under the %install section, leave the rm line alone.
  24. If your package does not need to be built, modify the 'make install' line to read as follows: 'install -D hello.sh $RPM_BUILD_ROOT/usr/local/bin/hello.sh'.
  25. Leave the %clean and the 'rm -rf' lines alone.
  26. Under %files, use the following syntax to list each of the files your package will place on the target system: '%attr(770,owner,group)/usr/local/bin/hello.sh'
  27. Use the following syntax to list each of the directories you package will place on the target system: '%dir /usr/local/bin'.
  28. The %attr(755,root,root) directive should be left as is.
  29. The changelog section can be deleted, configured, or left alone.
  30. At this point, we're finished with the .spec file. Save and exit the file. Now it's time to "build" the package, as follows: `rpmbuild -ba rpmbuild/SPECS/hello.spec`.[38]
  31. If the rpm package built correctly, you should get the following output to the `tree` command:
        --> tree rpmbuild
        rpmbuild
        |-- BUILD
        |   `-- hello-1.0
        |       `-- hello.sh
        |-- BUILDROOT
        |-- RPMS
        |   `-- x86_64
        |       `-- hello-1.0-1.fc20.x86_64.rpm
        |-- SOURCES
        |   `-- hello-1.0.tgz
        |-- SPECS
        |   `-- hello.spec
        `-- SRPMS
            `-- hello-1.0-1.fc20.src.rpm
    
        8 directories, 5 files
    

In the final analysis, the final command above should give a '0' output as the return value. If it doesn't, try to follow the output to determine where the process breaks for hints as to how to fix it. Most often, either the process can't find the files as indicated, or there's a syntax error in the .spec file. If you have problems, compare your configuration to the files contained in mine: RPM Build Exercise Final Files .

Manually Create a Bridge Networking Device[39]

Create /etc/sysconfig/network-scripts/ifcfg-br0 for Virtual Machines.

  1. `cd /etc/sysconfig/network-scripts`
  2. `cp ifcfg-eth0 /root/ifcfg-eth0.bak` - or your active device config file.
  3. `cat ifcfg-eth0 > ifcfg-br0`
  4. Make sure the following four items are inside the 'ifcfg-eth0' file. Delete everything else.
    DEVICE="eth0"
    # change the hardware address to match the hardware address your NIC uses
    HWADDR="00:16:76:D6:C9:45"
    ONBOOT="yes"
    BRIDGE="br0"
  1. Place the following inside the 'ifcfg-br0' file. Delete everything else.[40]
    DEVICE="br0"
    TYPE="Bridge"       #(note the CAPITAL B, not b)
    ONBOOT="yes"
    BOOTPROTO="dhcp"
    DELAY="0"

Or, as shown below, the configuration can be established manually.

    DEVICE="br0"
    TYPE="Bridge"           # (note the CAPITAL B, not b)
    ONBOOT="yes"
    BOOTPROTO="none"
    IPADDR="192.168.5.170"  # these settings must match your network requirements
    GATEWAY="192.168.4.1"
    NETMASK=255.255.255.0
    DNS1="192.168.7.254"
    DNS2="192.168.7.253"
    DELAY="0"
  1. Set the DNS servers in /etc/resolv.conf appropriately.
  2. Restart the network: `service network restart`

Establish Key-Based SSH Login

Establish a key-based SSH authentication mechanism for remote login that does not prompt for a password. This exercise assumes that you have an account on computer#2 and know the password for that account.

  1. On the machine that you will connect FROM, run: `ssh-keygen -t dsa`.
  2. Then place the public part of that key on the machine that you will connect TO: `ssh-copy-id -i ~/.ssh/id_dsa.pub user@computer#2`

Create a Secure "Drop-box" for Anonymous FTP Upload

Run the following commands to create an upload directory owned by root.ftp and with 730 permissions as follows:

  1. `cd /var/ftp`
  2. `mkdir incoming`
  3. `chgrp ftp incoming`
  4. `chmod 730 incoming`

Modify SELinux to set the context of public_content_rw_t on the upload directory with the following commands.

  1. `semanage fcontext -a -t public_content_rw_t '/var/ftp/incoming(/.*)?'`
  2. `restorecon -rvv /var/ftp/`

Enable the allow_ftp_anon_write boolean with the following command:

  1. `setsebool -P allow_ftpd_anon_write on`

Modify '/etc/vsftpd/vsftpd.conf' as follows:

    anonymous_enable=YES
    local_enable=NO
    write_enable=YES
    anon_upload_enable=YES
    chown_uploads=YES
    chown_username=daemon
    anon_umask=077

Modify IP Tables for inbound FTP[41]

Modify '/etc/sysconfig/iptables-config' and set the following directives to enable additional IP Tables modules for connection tracking:

  IPTABLES_MODULES="nf_conntrack_ftp nf_nat_ftp"

Apache User Home Directories

To establish web access for system users, find the following in httpd.conf and uncomment/modify as shown.[42] QUIZ QUESTION: How will SELinux apply in this instance?

# UserDir: The name of the directory that is appended onto a user's home
# directory if a ~user request is received.
#
# The path to the end user account 'public_html' directory must be
# accessible to the webserver userid.  This usually means that ~userid
# must have permissions of 711, ~userid/public_html must have permissions
# of 755, and documents contained therein must be world-readable.
# Otherwise, the client will only receive a "403 Forbidden" message.
#
# See also: http://httpd.apache.org/docs/misc/FAQ.html#forbidden
#
<IfModule mod_userdir.c>
    #
    # UserDir is disabled by default since it can confirm the presence
    # of a username on the system (depending on home directory
    # permissions).
    #
    # UserDir disabled

    #
    # To enable requests to /~user/ to serve the user's public_html
    # directory, remove the "UserDir disabled" line above, and uncomment
    # the following line instead:
    # 
    UserDir public_html

</IfModule>

#
# Control access to UserDir directories.  The following is an example
# for a site where these directories are restricted to read-only.
#
<Directory /home/*/public_html>
    AllowOverride FileInfo AuthConfig Limit
    Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
   <Limit GET POST OPTIONS>
        Order allow,deny
        Allow from all
  </Limit>
  <LimitExcept GET POST OPTIONS>
        Order deny,allow
        Deny from all
    </LimitExcept>
</Directory>

Apache User Authentication

The exercise below will create a password protected directory that will, when properly configured, present the "Authentication Required" dialog box when accessed through a browser. The exercise assumes that Apache is installed and working properly.

  1. Create a directory at the location '/var/www/html/restricted'.
  2. Alter the Apache configuration file '/etc/httpd/conf/httpd.conf' to include the following stanza.
    <Directory "/var/www/html/restricted">
        AuthType Basic
        AuthName "Password Protected"
        AuthUserFile /etc/httpd/.htpasswd
        Require valid-user
        # or Require user <username>
    </Directory>
  1. Run the command `htpasswd -cm /etc/httpd/.htpasswd <first_user>` to create the first user.[43]
  2. Answer the password prompts as they are presented.
  3. Run the command `htpasswd -m /etc/httpd/.htpasswd <another_user>` to add additional users to the file who will access the 'restricted' directory.

Note that a complete explanation of Apache operation and configuration is available online at Apache 2.2 Documentation . Becoming familiar with the information in the documentation will provide all the steps and familiarity necessary to fulfill the RHCSA/RHCE exam objectives.[44]

Apache User Configuration with .htaccess

The above access requirements can be established with a .htaccess file that lives in the same directory that is protected. The following steps outline how to accomplish that objectives.

  1. Set the override AllowOverride Options (or All) in the directory stanza of httpd.conf.
    <Directory "/var/www/html/restricted">
       AllowOverride All
       Order allow,deny
       Allow from all
    </Directory>
  1. Create a .htaccess file in the directory that is to be reconfigured.
  2. Place the options that you want in the .htaccess file (can be similar to the options listed above).
  3. Other options that are available are All, None, ExecCGI, FollowSymLinks, Includes, Indexes, etc.

Apache User Based Security with LDAP Authentication

Not yet ready for Prime Time.

Apache Group Share

There can be additional aspects of sharing web directories that tie to file system shares. The following exercise shows how to create a web-accessible group share that contains various files owned & modified by system users.

  1. Create a regular user called 'webaccess'. This will be a 'dummy' account, and will not be allowed login privileges.
  2. Set UID & GID for 'webaccess' at an arbitrarily high number, well above regular users to avoid breaking UID/GID sequencing. This is an optional step.
  3. Configure the 'webaccess' home directory w/owner as 'nobody' & set login of 'webaccess' as '/sbin/nologin'.
  4. Create a 'public_html' directory for 'webaccess'. The directory will be located at /home/webaccess/public_html.
  5. Change permissions of the entire directory tree (/home/webaccess/public_html) to include execute for 'other'. These will be 701 perms.
  6. It is possible to set acls on the directory path to allow the apache user to execute the directories, as shown in the program listing below.[45]
    `setfacl -m u:apache:x /home/webaccess`
    `setfacl -m u:apache:rx /home/webaccess/public_html`
    `setfacl -m g:groupie:x webaccess`
  1. Run the command `chmod -R 3770 /home/webaccess/public_html` to establish SGID + sticky bit on the directory.
  2. Add the users that need to access the directory to the group webaccess.
  3. Configure Apache to establish "UserDir" access. See the section called "Apache User Home Directories" above.
  4. Restart the web server.
  5. Address SELinux: `setsebool -P httpd_enable_homedirs 1`.
  6. As root, run `ln -s /home/groupie/public_html /webaccess` for easy access to the `webaccess` directory.
  7. Members of the webaccess group should be able to access the directory from within the file system.
  8. Files within `/home/webaccess/public_html` should be accessible from the web via http://server/~webaccess.

Configuring for Name Virtual Host Configuration

The steps below will enable a named virtual host in Apache.[46]

  1. Install the httpd package and all dependencies, etc.
  2. Near the end of '/etc/httpd/conf/httpd.conf', create a stanza similar to the following.[47]
    NameVirtualHost *:80

    # A separate stanza can be created for each vhost desired.

    <VirtualHost *:80>
        ServerAdmin admin@example.com
        DocumentRoot /var/www/vhost1
        ServerName vhost1.example.com
        ErrorLog logs/vhost1-error_log
        CustomLog logs/vhost1-access_log common
    </VirtualHost>
  1. Restart the Apache server.
  2. There can be several (or many) virtual hosts served by the Apache server.
  3. Apache will serve pages for virtual hosts with different domain names without problems.
  4. Each virtual host will need a valid DNS record (or '/etc/hosts' file entry) to properly resolve the names to the correct web server.

Configuring for CGI-BIN Scripts

Note that a complete explanation of CGI operation and configuration is available online at Apache How-To Tutorials . Becoming familiar with the information in the documentation will provide all the steps and familiarity necessary to fulfill the RHCSA/RHCE exam objectives.[48]

Create & Install a Self-Signed SSL Certificate

The steps below outline how to generate and install a self-signed SSL certificate. In order to complete this process, the openssl package must be installed. Please note that certain versions of the openssl package are vulnerable to the Heart Bleed Bug.[49]

  1. Run the command `openssl genrsa -out test.key 1024` to generate the private key. The name is arbitrary, and can be changed as needed.
  2. Run the command `openssl req -days 3650 -new -key test.key -x509 -out test.crt` to generate the public certificate from the key. Prompts will appear asking for several key pieces of information. Again, the name is arbitrary.
  3. Run the command `openssl x509 -text -in test.crt` to view the contents of the certificate.
  4. Place the private key in '/etc/pki/tls/private'.
  5. Change the permissions on the private key such that only the root user can read it. `chmod 400 test.key`
  6. Place the public certificate in '/etc/pki/tls/certs'.
  7. If SELinux is set to Enforcing, make sure that both files are labeled appropriately. They will need to have the cert_t context set on them. Run the command `restorecon -rv /etc/pki/tls`.
  8. For the web site that is to be have SSL enabled, the appropriate ssl.conf file must include the following:
    SSLCertificateFile /etc/pki/tls/certs/test.crt      # change name accordingly
    SSLCertificateKeyFile /etc/pki/tls/private/test.key # change name accordingly
  1. Restart the httpd service.
  2. When the configured web site is called in a browser, a prompt should appear asking to accept the newly installed certificate.

Enable Home Directory Shares with Samba

The following exercise will configure samba to share home directories. Refer to the section called "Intro to Samba" for configuration details.

  1. Install the appropriate Samba packages.
  2. Start and enable the service to start at boot.
  3. Configure the workgroup name in '/etc/samba/smb.conf.
  4. Uncomment the [homes] stanza in '/etc/samba/smb.conf as shown in the listing below.[50]
    [homes]
        comment = Home Directories
        browseable = no
        writable = yes
        valid users = <comma,separated,list,of,valid,samba,users>
  1. Create the required Samba users and passwords.
  2. Enable the SELinux boolean permitting home directory access.
  3. Configure the firewall.
  4. Restart the service.
  5. Test from another system.

Create a Public Share with Samba

  1. Create the folder to be shared and set the file system permissions as required.
  2. Install the appropriate Samba packages.
  3. Start and enable the service to start at boot.
  4. Configure the workgroup name and netbios name in '/etc/samba/smb.conf.
  5. Create a stanza as shown below in '/etc/samba/smb.conf.[51]
    [samba-share]
        comment = Important Samba Share
        path = /mnt/samba-share 
        public = yes
        writable = yes
        printable = no
        browseable = yes
        write list = <valid,samba,users>
  1. Create the required Samba users and passwords.
  2. Enable the SELinux boolean permitting home directory access.
  3. Configure the firewall.
  4. Restart the service.
  5. Test from another system.

NFS Server Setup

The following steps will establish an NFS server. Note that the IP address and exported directory may need to be adjusted for specific needs.

  1. Run the command `yum -y install nfs-utils nfs4-acl-tools` to install the NFS server packages.
  2. Create a directory that will be exported via NFS, such as '/nfs_export'. Place content of some kind in that directory.
  3. Configure '/etc/exports' with directives as needed. The following listing gives a starting point.
    /nfs_export 192.168.5.0/24(rw,no_root_squash) *(ro,root_squash)
  1. Open port 2049 on firewall.
  2. Start the service: `service nfs start`.
  3. Configure the service to start at boot: `chkconfig nfs on`
  4. Check the status of the service: `service nfs status`
  5. Check that the service is alive and properly listening on the system: `netstat -ant | grep 2049`
  6. Check the status of the exported directories: `showmount -e localhost`
  7. Mount the directories from the client server: `mount <nfs-server>:/nfs_export /mnt/<nfs>/<directory>`

NFS Client Setup

This exercise addresses a manual or static NFS mount method. The automount method is shown in the section called "NFS & AutoMount Setup".

  • To see a list of shares exported from the server, run the command `showmount -e <server>`.[52]
  • Run the command `mount -t nfs <server>:/share '/<where>/<to>/<mount>/<it>'` to mount the share.
  • List the mount in '/etc/fstab'.

NFS & AutoMount Setup

Not yet ready for Prime Time.

Create a Caching DNS Server

The steps below will install and configure a basic caching DNS server.

  1. Run the command `yum -y install bind` to install the bind DNS server.
  2. Configure '/etc/named.conf' to change the 'listen-on' directive to the IP address of local NIC.[53]
  3. Change the allow-query directive to host, subnet, etc.
  4. Comment out (to eliminate) dnssec directive.
  5. Open port 53 in the firewall for both UDP and TCP.
  6. To finish and test the setup, change '/etc/resolv.conf' to 'nameserver <ip address of machine>'.

Create a Forwarding DNS Server

The DNS forwarding facility of bind can be used to create a large site-wide cache on a few servers, reducing traffic over links to external nameservers. It can also be used to allow queries by servers that do not have direct access to the Internet so that they can look up exterior names. Forwarding occurs only on those queries for which the server is not authoritative and does not have the answer in its cache. To set up a forwarding DNS server, first install the caching server per above. Then establish the following in /etc/named.conf.

options {
    directory "/var/named";
    ...
    forward first; #NOTE: there are two options for the forward directive: 'first' and 'only'
    forwarders {
        8.8.8.8;
    };
};

The steps below will establish a forwarding-only server.

  1. First install a caching DNS server as outlined above.
  2. Set up forward stanza as listed above.
  3. Comment out 'recursion yes';.
  4. Change the forward directive to say 'forward only';.
  5. List the servers to which DNS queries should be forwarded.
  6. Restart the named daemon.

Configure postfix Email Server

The steps below will configure the machine to send/receive mail via postfix. Note that the config file for postfix is '/etc/postfix'.

  1. Activate and modify 'myhostname' directive in the config file.
    myhostname = <hostname>.<domain>.<xxx>
  1. Activate and modify the 'mydomain' directive in the config file.
    mydomain =  <domain>.<xxx>
  1. Activate and modify the 'myorigin' directive in the config file.
    myorigin = $myhostname
  1. Alter 'inet_interfaces'. If set to 'all', postfix will listen for traffic on all configured and active interfaces.
    inet_interfaces = all
  1. Activate and modify 'mynetworks' for the network that is to be served. From whom will this machine receive/relay mail?
    mynetworks = subnet # capable of receiving mail from any host on the subnet
  1. The 'relayhost' directive enables relaying through another host. This directive will not be necessary if relaying is not desired.
    #relayhost = [an.ip.add.ress] - put ip address in the braces to eliminate dns validation
    relayhost = aaa.bbb.ccc.ddd

iSCSI Initiator Setup

In order to access an iSCSI device, follow the steps below.

  1. Install the required package with the command `yum -y install iscsi-initiator-utils`.
  2. Start the iscsi and iscsid services and configure them to persistently start at boot.
  3. Make sure there is an initiator IQN in '/etc/iscsi/initiatorname.iscsi'. Typically, the default will be sufficient.
  4. Discover targets with the command `iscsiadm -m discovery -t st -p <portal IP address>`.
  5. Log in to the target using the name displayed in discovery with the command `iscsiadm -m node -T <IQN> -p <portal IP address> -l`.
  6. Identify the SCSI device name with `dmesg`, `tail /var/log/messages` or `ls -l /dev/disk/by-path/*iscsi*`.
  7. Format and mount the disk as though it were a local hard disk.

The steps below can be followed to disconnect from an iSCSI device.

  1. Ensure that the device is not in use.
  2. Unmount the device.
  3. Remove the '/etc/fstab' entry for the device.
  4. Logout from the target with the command `iscsiadm -m node -T <IQN> -p <portal IP> -u`.
  5. Delete the local record with the command `iscsiadm -m node -T <IQN> -p <portal IP> -o delete`.

Finally, be certain to use UUIDs or labels for persistent mounts in '/etc/fstab'. Also, provide _netdev as a mount option so that this device will not be mounted until after the network is up and running.



[33] Note that best practice is to build packages as a "non-privileged" user. If you're deploying a package for production or to share, this convention is strongly suggested.

[34] Name this according to the convention: <projname>-<majorver>.<minorver>

[35] It's wise to check the newly created tarball with the command `tar tvzf hello-1.0.tar.gz`. The output should have only one directory and one file.

[36] You can check the the result with the command `tree rpmbuild`. The output should look like the following:

    --> tree rpmbuild
    rpmbuild
    |-- BUILD
    |-- BUILDROOT
    |-- RPMS
    |-- SOURCES
    |-- SPECS
    |-- SRPMS

[37] Package groups are different from `yum grouplist`. A useful command to show what groups are being used by a set of packages: `rpm -qa --qf '%{group}\n' * |sort -u`.

[38] Note that the `ba` options as specified are only a small subset of the options available to build the package. Read the man page for additional information.

[39] See the Red Hat Bridging Doc for more details.

[40] Note the difference between a dhcp assigned IP address and a static address. Either can be used, based upon the network you're working with.

[41] The easiest way is with the command `system-config-firewall-tui` issued from a terminal window.

[42] NOTE that this is a basic configuration, a mere subset of the possible configuration options.

[43] NOTE the flags passed to this command. The cm flags will create and modify the config file. The c flag is only used the first time the command is called on the file.

[44] An important resource for times when Internet connectivity is not available is by a) installing the httpd-manual package, and b) accessing the available online documentation locally at 'http://localhost/manual'. Follow the links in the upper right hand corner to access crucial information for several crucial configuration objectives on the local computer.

[45] NOTE the subtle differences regarding what these commands do. a)If you set the 701 permissions, it allows ALL USERS execute permissions on the directory tree. b) The `setfacl` commands permit ONLY apache & webaccess access privileges on the directory tree. c) The apache user must be given READ access as well as EXECUTE on the directory.

[46] See Apache 2.2 VHost Documentation for more information and examples. NOTE that this documentation is insalled on the local machine with the httpd-manual package.

[47] Copying the existing example and pasting it back into the file, then editing the copy is a good practice. That way, there is always a copy of the original stanza to refer to.

[48] An important resource for times when Internet connectivity is not available is by a) installing the httpd-manual package, and b) accessing the available online documentation locally at 'http://localhost/manual'. Follow the links in the upper right hand corner to access crucial information for CGI configuration on the local computer.

[49] See the Wikipedia Heart Bleed Article and the Heart Bleed Official Website for more information.

[50] Note that you will need to adjust the values (for users, MYDOMAIN, etc.) as needed.

[51] Note that you will need to adjust the values as needed.

[52] The firewall on the server may interfere with this command. YMMV.

[53] When editing bind configuration files, watch the placement of semi-colons - ";". One of the most common mistakes when editing the '/etc/named.conf' file is a misplaced or missing semi-colon.