RHCSA (027): Season 2 - Scenario 2 of 25: Application Directory Cleanup and Re-structuring

Podcast: The RHCSA Series Podcast
Season: 2 (Episodes 26A - 50)
Episode: 27
Title: RHCSA (027): Season 2 - Scenario 2 of 25: Application Directory Cleanup and Re-structuring
Release date: January 20, 2026
Produced by: Djere Services Group

You can support my work here:   / djere  

Season 1 is complete. We have no Patron tiers; all Patrons can download the 25 Season 1 mp3s here:
  / rhcsa-series-1-138247495  

**PRO TIP: NotebookLM sometimes pronounces technical words incorrectly making it hard to understand what it's saying. Opening the associated article and following along as it speaks helps A LOT.**

Associated article: https://djere.com/rhcsa-027-season-2-...

NOTE: This podcast is 100% independent, and is in no way affiliated with Red Hat.

Mission: This podcast is 100% focused on 1 goal: providing knowledge to help its listeners pass the RHCSA exam.

###

RHCSA Objectives covered in this video:

1.7: Create and edit system configuration files (e.g., /etc/hosts).
1.8: Create a complex, multi-level directory structure and manipulate files within it.
1.9: Create, delete, and manage hard and symbolic (soft) links.
8.2: Configure local hostname resolution using static entries.

###

Executive Summary

This Episode 27 RHCSA GNU/Linux Lab is focused on essential file system management and application deployment tasks. The primary scenario involves addressing a failed application deployment located in /var/tmp/failed_deploy. The lab's core objectives test the administrator's ability to create, move, and edit files and directories (Objectives 1.8, 1.7) and to properly integrate the application into the system using hard and soft links (Objective 1.9).

The solution process begins by creating a new, standardized directory structure at /opt/webapp with distinct subdirectories for binaries, configuration, and documentation. The administrator must then migrate the relevant application files from the failed deployment, such as app.bin and config.xml, into this new structure and subsequently remove the original temporary directory. A critical step involves reconfiguring the application by editing its configuration file with vim to update a database endpoint from db.old.internal to db.prod.internal.

To complete the deployment, the administrator must ensure the new database is reachable by modifying the /etc/hosts file to resolve db.prod.internal to its correct IP address (Objective 8.2). Finally, the application is integrated into the system by creating a symbolic link to its binary in /usr/local/bin for easy execution and a hard link to its configuration file in /etc for system-wide access. The lab concludes with a verification sequence that confirms the links are correct by checking their properties and inode numbers, and that name resolution is functional by successfully pinging the new database hostname.