Introduction
Les tâches d'administration réelles ne se limitent rarement à une seule commande. Un service peut échouer parce que l'unité est inactive, que l'utilisateur du service ne peut pas lire le contenu, que les étiquettes SELinux sont incomplètes ou que le pare-feu n'expose pas le port requis.
Dans ce laboratoire, vous allez réparer un hôte de service web préparé. Le service doit s'exécuter en tant que labex, servir le contenu depuis /srv/rhcsa-review/site, écouter sur 127.0.0.1:18082, être activé au démarrage, posséder les étiquettes SELinux correctes et exposer 18082/tcp via firewalld.
Reproduire et diagnostiquer la défaillance du service
Dans cette étape, vous allez reproduire la défaillance du service et inspecter les preuves avant d'effectuer des modifications. Commencez par systemctl et journalctl, puis comparez le message de journal avec les permissions des fichiers.
La configuration initiale conserve de manière permanente l'accès SSH et l'accès au terminal de navigateur LabEx sur 3002/tcp dans la zone public. Conservez ces règles d'administration lorsque vous modifiez la politique de pare-feu de l'application.
Accédez au répertoire du projet.
cd /home/labex/project
Vérifiez le service préparé. Il existe, mais il n'est pas encore en cours d'exécution.
systemctl status rhcsa-review-web.service --no-pager || true
Essayez de le démarrer. Cela devrait échouer car le service s'exécute en tant que labex, mais le répertoire de contenu n'est pas accessible à cet utilisateur.
sudo systemctl start rhcsa-review-web.service || echo "service start failed as expected"
sleep 1
Vérifiez si systemd a marqué l'unité comme étant en échec.
systemctl is-failed rhcsa-review-web.service || true
Lisez les entrées de journal les plus récentes du service. Le journal devrait vous indiquer que le compte de service ne parvient pas à utiliser le répertoire de travail ou le chemin de contenu configuré.
sudo journalctl -u rhcsa-review-web.service -n 20 --no-pager
Inspectez les permissions du chemin de contenu.
sudo stat -c '%a %U:%G %n' /srv/rhcsa-review /srv/rhcsa-review/site /srv/rhcsa-review/site/index.html
Réparer les permissions de contenu
Dans cette étape, vous allez rendre le contenu lisible par le compte de service sans le rendre lisible par tout le monde. Le service s'exécute avec l'utilisateur labex et le groupe labex.
Définissez le groupe de l'arborescence des répertoires sur labex. Le service s'exécute avec le groupe labex, donc la propriété de groupe vous permet d'accorder l'accès sans changer le propriétaire des fichiers vers l'utilisateur du service.
sudo chown root:labex /srv/rhcsa-review /srv/rhcsa-review/site /srv/rhcsa-review/site/index.html
Autorisez le groupe à parcourir les répertoires et à lire le fichier de contenu. Les répertoires ont besoin du bit d'exécution pour le parcours, et le fichier HTML a besoin du bit de lecture pour que le service puisse le servir.
sudo chmod 750 /srv/rhcsa-review /srv/rhcsa-review/site
sudo chmod 640 /srv/rhcsa-review/site/index.html
Inspectez les permissions réparées.
sudo stat -c '%a %U:%G %n' /srv/rhcsa-review /srv/rhcsa-review/site /srv/rhcsa-review/site/index.html
Effacez l'état d'échec et redémarrez le service. reset-failed supprime l'ancien marqueur d'échec, ce qui rend l'état systemctl suivant plus facile à lire après la réparation des permissions.
sudo systemctl reset-failed rhcsa-review-web.service
sudo systemctl start rhcsa-review-web.service
sleep 1
Confirmez que le service est actif et qu'il sert le contenu.
systemctl is-active rhcsa-review-web.service
curl -s http://127.0.0.1:18082/
Rendre le service persistant
Dans cette étape, vous allez activer le service réparé afin qu'il démarre au démarrage du système. Un service qui ne fonctionne que jusqu'au prochain redémarrage n'est pas entièrement réparé.
Activez l'unité. Le démarrage corrige le démarrage actuel ; l'activation enregistre que le service réparé doit démarrer automatiquement dans la cible de démarrage normale.
sudo systemctl enable rhcsa-review-web.service
Vérifiez l'état d'activation.
systemctl is-enabled rhcsa-review-web.service
Redémarrez le service pour confirmer que l'unité peut toujours démarrer proprement après la réparation des permissions. Un redémarrage propre est une preuve plus solide que la simple vérification du processus qui se trouvait être en cours d'exécution.
sudo systemctl restart rhcsa-review-web.service
sleep 1
Testez à nouveau le service.
systemctl is-active rhcsa-review-web.service
curl -s http://127.0.0.1:18082/
Ajouter le contexte SELinux et les étiquettes de port
Dans cette étape, vous allez faire correspondre les métadonnées de la politique SELinux à la conception du service. Même lorsqu'un simple service de démonstration peut lire le contenu, les réparations de service web de style RHCSA doivent inclure le contexte de fichier persistant et les étiquettes de port.
Ajoutez une règle de contexte de contenu HTTP persistante pour le contenu du service. La règle fcontext est une métadonnée de politique persistante ; elle indique à SELinux quelle étiquette ce chemin doit recevoir après une réétiquetage.
sudo semanage fcontext -a -t httpd_sys_content_t '/srv/rhcsa-review/site(/.*)?'
Appliquez la règle aux fichiers existants. restorecon lit la règle persistante et applique l'étiquette correcte aux fichiers qui existent déjà.
sudo restorecon -Rv /srv/rhcsa-review/site
Inspectez la règle personnalisée et l'étiquette résultante.
sudo semanage fcontext -l | grep '/srv/rhcsa-review/site'
ls -Zd /srv/rhcsa-review/site /srv/rhcsa-review/site/index.html
Ajoutez le port du service au type de port HTTP. Les étiquettes de port permettent à la politique SELinux de comprendre que le port TCP 18082 est destiné au trafic de service de type HTTP.
sudo semanage port -a -t http_port_t -p tcp 18082
Inspectez l'étiquette du port HTTP.
sudo semanage port -l | grep '^http_port_t'
Ouvrir le pare-feu et valider de bout en bout
Dans cette étape, vous allez exposer le port du service via firewalld et effectuer un audit final. Le service doit être actif, activé, étiqueté et autorisé par le pare-feu de l'hôte.
Démarrez et activez firewalld.
sudo systemctl enable --now firewalld
Ajoutez le port du service de manière permanente et rechargez le pare-feu. La règle permanente survit aux rechargements de firewalld, et le rechargement l'applique au pare-feu actif.
sudo firewall-cmd --permanent --add-port=18082/tcp
sudo firewall-cmd --reload
Inspectez la liste des ports actifs.
sudo firewall-cmd --list-ports
Effectuez les vérifications finales du service. Ces commandes confirment que le service est activé pour le démarrage, actif maintenant et renvoie la réponse web locale attendue.
systemctl is-enabled rhcsa-review-web.service
systemctl is-active rhcsa-review-web.service
curl -s http://127.0.0.1:18082/
Auditez les permissions de contenu une dernière fois. Cette vérification finale des permissions protège contre une réparation partielle courante : le service fonctionne maintenant, mais le modèle d'accès est plus large ou plus restreint que prévu.
sudo stat -c '%a %U:%G %n' /srv/rhcsa-review /srv/rhcsa-review/site /srv/rhcsa-review/site/index.html
Résumé
Vous avez réparé un hôte de service présentant de multiples problèmes en diagnostiquant une unité systemd défaillante, en corrigeant les permissions de l'utilisateur du service, en activant le service, en ajoutant les étiquettes de fichier et de port SELinux, en ouvrant firewalld et en validant la réponse web finale.
