LFCS 운영·배포 실습

커널부터 SELinux까지 운영·배포 8개 competency를 상태 구성과 검증으로 연습

아래 문제는 공개된 LFCS 시험문항이나 복원 문제가 아니다. 공식 Operations Deployment 범위를 바탕으로 독자적으로 만든 연습 시나리오다.

작성·검증 상태: AI가 문제·풀이 구조화를 보조했다. libvirt·container·failure recovery는 fixture와 host capability가 필요하며 전체 시나리오를 동일 VM에서 end-to-end 검증한 상태는 아니다.

실습 전 준비

• 폐기하거나 검사점으로 되돌릴 수 있는 VM에서 수행한다.
• 먼저 hostnamectl, lsblk -f, findmnt, ip -br address, systemctl --failed로 기준 상태를 확인한다.
• 파일을 덮어쓰기 전에 원문을 복사하고, 기존 서비스·컨테이너·VM 이름 충돌을 확인한다.
• 각 문제는 풀이를 닫아 둔 채 수행하고, 완료 조건을 명령 출력으로 증명한다.

1. 커널 매개변수 — 7분

문제

IPv4 forwarding을 지금 활성화하고 재부팅 후에도 유지되게 하라. 설정은 /etc/sysctl.d/90-lfcs-forwarding.conf에 둔다.

완료 조건

• 현재 net.ipv4.ip_forward 값이 1이다.
• 지정한 파일에 영구 설정이 있다.
• 전체 sysctl 설정 재적용에 오류가 없다.
• 같은 키를 덮어쓰는 다른 파일이 있는지 확인했다.

안전 주의

운영 호스트에서 forwarding을 켜면 라우팅·방화벽 정책에 영향을 줄 수 있다. 이 문제는 격리된 실습 VM에서 수행한다.

grep -R "^[[:space:]]*net.ipv4.ip_forward" /etc/sysctl.conf /etc/sysctl.d 2>/dev/null
sysctl -w net.ipv4.ip_forward=1
printf 'net.ipv4.ip_forward = 1\n' > /etc/sysctl.d/90-lfcs-forwarding.conf
sysctl --system
sysctl -n net.ipv4.ip_forward

2. custom systemd 서비스 — 12분

문제

다음 조건을 만족하는 health-check.service를 만들어라.

• /usr/local/bin/health-check.sh를 실행한다.
• lfcsuser 권한으로 10초마다 health check OK를 출력한다.
• 실패하면 5초 뒤 재시작한다.
• 지금 실행하고 부팅 시에도 자동 실행한다.
• 출력은 journal에서 확인할 수 있어야 한다.

완료 조건

• unit 문법 검사를 통과한다.
• is-active는 active, is-enabled는 enabled다.
• 실제 프로세스의 사용자가 lfcsuser다.
• journal에 반복 출력이 보인다.

안전 주의

/usr/lib/systemd/system의 패키지 unit을 수정하지 않는다. 실행 사용자와 스크립트 권한을 먼저 확인한다.

cat > /usr/local/bin/health-check.sh <<'SCRIPT'
#!/bin/bash
while true; do
  echo "$(date -Is) health check OK"
  sleep 10
done
SCRIPT

chmod 755 /usr/local/bin/health-check.sh
restorecon -v /usr/local/bin/health-check.sh

# /etc/systemd/system/health-check.service
[Unit]
Description=LFCS health check practice

[Service]
Type=simple
User=lfcsuser
ExecStart=/usr/local/bin/health-check.sh
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

systemd-analyze verify /etc/systemd/system/health-check.service
systemctl daemon-reload
systemctl enable --now health-check.service
systemctl is-active health-check.service
systemctl is-enabled health-check.service
systemctl show -p User -p MainPID health-check.service
journalctl -u health-check.service -n 10 --no-pager

3. 반복 작업 예약 — 8분

문제

/usr/local/bin/collect-space.sh가 매일 03:15에 실행되어 /var/log/space-report.log에 파일시스템 사용량을 덧붙이게 하라.

완료 조건

• 스크립트를 수동 실행할 수 있다.
• 실행 사용자, 절대경로, 실행 시각과 출력 위치가 분명하다.
• 예약 내용을 조회할 수 있다.
• 실제 실행 결과를 시험할 방법을 설명할 수 있다.

안전 주의

기존 root crontab을 통째로 덮어쓰지 않는다. crontab -l 결과를 보존한 뒤 필요한 한 줄만 추가한다.

cat > /usr/local/bin/collect-space.sh <<'SCRIPT'
#!/bin/bash
/usr/bin/date -Is
/usr/bin/df -hT
SCRIPT
chmod 755 /usr/local/bin/collect-space.sh
/usr/local/bin/collect-space.sh >> /var/log/space-report.log

15 3 * * * /usr/local/bin/collect-space.sh >> /var/log/space-report.log 2>&1

crontab -l
tail -n 20 /var/log/space-report.log

# Rocky/RHEL
systemctl status crond --no-pager

# Debian/Ubuntu
systemctl status cron --no-pager

4. 패키지와 저장소 — 7분

문제

활성 저장소에서 nginx를 검색해 설치하고, 후보·설치 버전, 제공 저장소와 주요 설정 파일을 확인하라. 서비스 시작은 요구사항에 포함하지 않는다.

완료 조건

• 활성 저장소를 확인했다.
• 설치 전 후보 패키지 정보를 확인했다.
• 설치된 버전과 패키지가 제공한 파일을 확인했다.
• 설치와 서비스 실행을 구분했다.

안전 주의

새 외부 저장소를 추가하지 않는다. 패키지 이름이 없는 배포판이면 동등한 기본 저장소 패키지로 바꾸고 이유를 기록한다.

dnf repolist
dnf info nginx
dnf install -y nginx
rpm -qi nginx
rpm -ql nginx | grep -E '/etc/|systemd'
systemctl is-enabled nginx
systemctl is-active nginx

5. 잘못된 fstab 복구 — 10분

문제

복제한 실습 VM에서 /etc/fstab의 보조 데이터 마운트 항목에 잘못된 UUID가 들어가 mount -a가 실패한다. 루트 파일시스템과 OS 디스크는 건드리지 않고 원인을 찾아 수정하라.

완료 조건

• 오류를 재현하고 메시지를 보존했다.
• lsblk -f·blkid로 실제 보조 장치 UUID를 확인했다.
• 백업한 fstab과 수정 내용을 비교했다.
• mount -a가 성공하고 대상 경로가 올바른 장치에 마운트됐다.

안전 주의

이 시나리오는 VM 콘솔과 검사점이 준비된 복제본에서만 수행한다. 루트·부트·OS 디스크 항목을 실습 대상으로 삼지 않는다.

cp -a /etc/fstab /etc/fstab.before-lfcs
mount -a
lsblk -f
blkid
findmnt --verify --verbose
diff -u /etc/fstab.before-lfcs /etc/fstab

mount -a
findmnt /data
findmnt --verify

6. libvirt domain — 10분

문제

미리 준비된 /root/web01.xml을 사용해 web01 domain을 지속 정의하고 시작하라. 호스트 부팅 시 자동 시작되게 하고 네트워크·블록 장치 연결을 확인하라.

완료 조건

• domain이 정의되고 running 상태다.
• autostart가 활성화됐다.
• 호스트에서 interface와 block device를 확인했다.
• 정상 종료와 강제 종료의 차이를 설명할 수 있다.

안전 주의

동일한 이름의 domain과 기존 디스크 경로가 있는지 먼저 확인한다. 실습 중 virsh destroy를 정상 종료 명령처럼 사용하지 않는다.

virsh list --all
virsh define /root/web01.xml
virsh start web01
virsh autostart web01
virsh dominfo web01
virsh domiflist web01
virsh domblklist web01

7. Podman 웹 컨테이너 — 9분

문제

/srv/web/index.html을 제공하는 web 컨테이너를 만들고 호스트의 8080/tcp로 접근할 수 있게 하라. 호스트 디렉터리의 콘텐츠는 컨테이너를 다시 만들어도 남아야 한다.

완료 조건

• 컨테이너 이름이 web이다.
• 8080이 컨테이너의 80으로 연결된다.
• bind mount와 SELinux label이 올바르다.
• 호스트에서 실제 HTTP 응답을 확인했다.

안전 주의

동일한 이름과 포트를 사용하는 컨테이너·프로세스를 먼저 확인한다. 기존 컨테이너를 무조건 삭제하지 않는다.

podman ps -a --filter name=web
ss -lntp | grep ':8080' || true
install -d -m 755 /srv/web
printf 'LFCS container lab\n' > /srv/web/index.html
podman run -d --name web -p 8080:80 \
  -v /srv/web:/usr/share/nginx/html:Z \
  docker.io/library/nginx:stable-alpine
podman ps --filter name=web
podman port web
podman inspect web
podman logs web
curl http://127.0.0.1:8080

8. SELinux 웹 콘텐츠 — 10분

문제

httpd의 DocumentRoot가 /srv/myweb으로 설정되어 있고 문법 검사는 통과했지만, SELinux 때문에 정적 파일을 읽지 못한다. 일반 파일 권한은 이미 올바르다고 가정하고 Enforcing을 유지한 채 해결하라.

완료 조건

• Enforcing 상태를 유지한다.
• 거부가 있다면 AVC 로그에서 확인한다.
• /srv/myweb에 영구 file context 규칙을 설정한다.
• 실제 label과 HTTP 응답을 검증한다.

안전 주의

setenforce 0, chmod 777, 광범위한 사용자 정책 모듈로 우회하지 않는다. 기존 file-context 규칙을 먼저 조회한다.

getenforce
ls -ldZ /srv/myweb
ausearch -m AVC -ts recent -i
semanage fcontext -l | grep '/srv/myweb' || true
semanage fcontext -a -t httpd_sys_content_t '/srv/myweb(/.*)?'
restorecon -Rv /srv/myweb
matchpathcon -V /srv/myweb/index.html
curl http://127.0.0.1/
ausearch -m AVC -ts recent -i

반복 기록표

풀이를 한 번 읽은 것으로 끝내지 않는다. 초기 상태로 돌아간 뒤 문제만 보고 다시 수행해 같은 결과를 만들 수 있어야 한다.

참고 자료

• LFCS Domains & Competencies
• systemd 매뉴얼
• libvirt virsh 매뉴얼
• Podman run 문서
• RHEL 10 SELinux 문서