Introduction
Real administration tasks rarely involve only one command. A service can fail because the unit is inactive, the service user cannot read content, SELinux labels are incomplete, or the firewall does not expose the required port.
In this lab, you will repair a prepared web service host. The service should run as labex, serve content from /srv/rhcsa-review/site, listen on 127.0.0.1:18082, be enabled at boot, have correct SELinux labels, and expose 18082/tcp through firewalld.
Reproduce and Diagnose the Service Failure
In this step, you will reproduce the service failure and inspect evidence before making changes. Start with systemctl and journalctl, then compare the log message with file permissions.
The setup permanently preserves SSH and the LabEx browser terminal on 3002/tcp in the public zone. Keep these management rules while changing the application firewall policy.
Move into the project directory.
cd /home/labex/project
Check the prepared service. It exists, but it is not running yet.
systemctl status rhcsa-review-web.service --no-pager || true
Try to start it. This should fail because the service runs as labex, but the content directory is not accessible to that user.
sudo systemctl start rhcsa-review-web.service || echo "service start failed as expected"
sleep 1
Show whether systemd marked the unit failed.
systemctl is-failed rhcsa-review-web.service || true
Read the most recent service log entries. The journal should point you toward the service account failing to use the configured working directory or content path.
sudo journalctl -u rhcsa-review-web.service -n 20 --no-pager
Inspect the content path permissions.
sudo stat -c '%a %U:%G %n' /srv/rhcsa-review /srv/rhcsa-review/site /srv/rhcsa-review/site/index.html
Repair Content Permissions
In this step, you will make the content readable by the service account without making it world-readable. The service runs as user labex and group labex.
Set the directory tree group to labex. The service runs with group labex, so group ownership lets you grant access without changing the files to be owned by the service user.
sudo chown root:labex /srv/rhcsa-review /srv/rhcsa-review/site /srv/rhcsa-review/site/index.html
Allow the group to traverse the directories and read the content file. Directories need the execute bit for traversal, and the HTML file needs the read bit so the service can serve it.
sudo chmod 750 /srv/rhcsa-review /srv/rhcsa-review/site
sudo chmod 640 /srv/rhcsa-review/site/index.html
Inspect the repaired permissions.
sudo stat -c '%a %U:%G %n' /srv/rhcsa-review /srv/rhcsa-review/site /srv/rhcsa-review/site/index.html
Clear the failed state and start the service again. reset-failed removes the old failed marker, making the next systemctl state easier to read after the permission repair.
sudo systemctl reset-failed rhcsa-review-web.service
sudo systemctl start rhcsa-review-web.service
sleep 1
Confirm the service is active and serving content.
systemctl is-active rhcsa-review-web.service
curl -s http://127.0.0.1:18082/
Make the Service Persistent
In this step, you will enable the repaired service so it starts at boot. A service that works only until the next boot is not fully repaired.
Enable the unit. Starting fixes the current boot; enabling records that the repaired service should start automatically in the normal boot target.
sudo systemctl enable rhcsa-review-web.service
Check the enablement state.
systemctl is-enabled rhcsa-review-web.service
Restart the service to confirm the unit can still start cleanly after the permission repair. A clean restart is stronger evidence than only checking the process that happened to be running.
sudo systemctl restart rhcsa-review-web.service
sleep 1
Test the service again.
systemctl is-active rhcsa-review-web.service
curl -s http://127.0.0.1:18082/
Add SELinux Context and Port Labels
In this step, you will make SELinux policy metadata match the service design. Even when a simple demo service can read the content, RHCSA-style web service repairs should include persistent file context and port labels.
Add a persistent HTTP content context rule for the service content. The fcontext rule is persistent policy metadata; it tells SELinux what label this path should receive after relabeling.
sudo semanage fcontext -a -t httpd_sys_content_t '/srv/rhcsa-review/site(/.*)?'
Apply the rule to existing files. restorecon reads the persistent rule and applies the correct label to files that already exist.
sudo restorecon -Rv /srv/rhcsa-review/site
Inspect the custom rule and resulting label.
sudo semanage fcontext -l | grep '/srv/rhcsa-review/site'
ls -Zd /srv/rhcsa-review/site /srv/rhcsa-review/site/index.html
Add the service port to the HTTP port type. Port labels let SELinux policy understand that TCP 18082 is intended for HTTP-style service traffic.
sudo semanage port -a -t http_port_t -p tcp 18082
Inspect the HTTP port label.
sudo semanage port -l | grep '^http_port_t'
Open the Firewall and Validate End to End
In this step, you will expose the service port through firewalld and run a final audit. The service should be active, enabled, labeled, and allowed by the host firewall.
Start and enable firewalld.
sudo systemctl enable --now firewalld
Add the service port permanently and reload the firewall. The permanent rule survives firewalld reloads, and the reload applies it to the active firewall.
sudo firewall-cmd --permanent --add-port=18082/tcp
sudo firewall-cmd --reload
Inspect the active port list.
sudo firewall-cmd --list-ports
Run final service checks. These commands confirm the service is enabled for boot, active now, and returning the expected local web response.
systemctl is-enabled rhcsa-review-web.service
systemctl is-active rhcsa-review-web.service
curl -s http://127.0.0.1:18082/
Audit the content permissions one last time. This final permission check protects against a common partial repair: the service works now, but the access model is broader or narrower than intended.
sudo stat -c '%a %U:%G %n' /srv/rhcsa-review /srv/rhcsa-review/site /srv/rhcsa-review/site/index.html
Summary
You repaired a multi-issue service host by diagnosing a failed systemd unit, fixing service-user permissions, enabling the service, adding SELinux file and port labels, opening firewalld, and validating the final web response.
