LFCS 필수 명령 실습

기본 Git 작업부터 SSL 인증서까지 공식 범위 기반 독립 연습 시나리오

이 과제는 과거 또는 실제 시험 문항이 아니다. LFCS 공식 범위에서 다루는 동작을 기준으로 독자적으로 만든 연습 시나리오다. 시나리오 결과는 실습 환경(폐기 가능 VM)에서만 재현하고, 운영 데이터에는 적용하지 않는다.

작성·검증 상태: AI가 문제·풀이 구조화를 보조했다. 전체 6개 시나리오를 모든 배포판에서 end-to-end 검증한 문서는 아니므로 각 완료 조건을 실습 VM에서 직접 확인한다.

1) 기본 Git Operations

문제

feature/lfcs-practice 브랜치를 만들어 config.txt 변경을 커밋하고, main에 병합하라.

완료 조건

  • main에 병합된 커밋이 git log --oneline --graph -n 8에 보인다.
  • 병합 전후 git status가 clean이다.
  • git show 또는 git diff --cached로 config.txt만 커밋되었음을 확인한다.

안전 주의

  • reset --hard, rebase -i 강제 편집은 사용하지 않는다.
  • 작업 트리 전체 변경을 한 번에 stage 하지 않는다.
풀이 예시 
git init -b main lfcs-lab
cd lfcs-lab
git config user.name "LFCS Lab"
git config user.email "lfcs@example.invalid"
printf 'mode=manual\n' > config.txt
git add config.txt
git commit -m "chore: init config"

git switch -c feature/lfcs-practice
printf 'mode=practice\n' > config.txt
git add config.txt
git diff --cached
git commit -m "chore: update config for practice"

git switch main
git merge --no-ff feature/lfcs-practice
git log --oneline --graph -n 8
git status
git status
git diff HEAD~1 HEAD -- config.txt
완료 기준:
- 두 커밋이 정상히 존재
- main 브랜치 HEAD가 병합 커밋을 포함
- 작업 트리 clean

2) 서비스 생성·설정·문제 해결

문제

웹 상태 점검용 oneshot unit health-check.service를 작성해 즉시 실행되면서 부팅 활성화되도록 구성하고, 실행 실패 원인 로그를 읽어 복구한다.

완료 조건

  • /etc/systemd/system/health-check.service가 존재하고 systemd-analyze verify가 통과한다.
  • systemctl daemon-reload 후 is-active와 is-enabled가 모두 active/enabled이다.
  • systemctl status health-check에서 최근 실행 로그에 예상 메시지가 찍힌다.

안전 주의

  • ExecStart는 실제 존재하고 실행 가능한 절대 경로를 사용한다.
  • 실행 파일 권한을 미검증 상태에서 단순 chmod 777으로 변경하지 않는다.
풀이 예시 
cat > /usr/local/bin/health-check <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
echo "health check ok"
EOF
chmod 700 /usr/local/bin/health-check
restorecon -v /usr/local/bin/health-check

cat > /etc/systemd/system/health-check.service <<'EOF'
[Unit]
Description=LFCS Practice Health Check

[Service]
Type=oneshot
ExecStart=/usr/local/bin/health-check
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF

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 status health-check.service --no-pager

3) 시스템 성능과 서비스 모니터링·문제 해결

문제

api.service가 느리다는 증상을 가정한다. CPU, 메모리, socket, journal를 묶어 병목 후보를 최소한 1개 이상 판별하라.

완료 조건

  • uptime과 vmstat을 통해 부하 성격을 파악한다.
  • ps -eo ... --sort=-pcpu에서 상위 사용 프로세스를 확인한다.
  • ss -lntp로 핵심 포트의 수신 상태를 확인한다.
  • journalctl에서 최근 오류 timestamp를 후보 판단 근거로 제시한다.

안전 주의

  • 진단 도중 캐시 정리, 서비스 강제 재시작을 기본 동작으로 두지 않는다.
  • 출력값이 불완전하면 반복 2~3회 측정 후 결론을 잡는다.
풀이 예시 
uptime
vmstat 1 6
ps -eo pid,ppid,pcpu,pmem,user,comm --sort=-pcpu | head
ps -eo pid,ppid,pcpu,pmem,user,comm --sort=-pmem | head
ss -lntp
systemctl status api.service --no-pager
journalctl -u api.service --since "-15 min" --no-pager
완료 판단:
- 평균 부하 높음 + 상위 프로세스 확인 = 후보 좁힘
- 로그/소켓에서 서비스 자체/네트워크 가시화 가능

4) 애플리케이션·서비스 제약 조건

문제

systemd service report-api가 사용자·그룹 report-api로 실행된다. 이 서비스가 443 포트와 /srv/report/config.yml 접근에서 실패한다. 설정 파일은 root:report-api, mode 0640이어야 한다.

완료 조건

  • systemctl cat report-api에서 사용자, 작업 경로, ExecStart를 확인한다.
  • namei -l /srv/report/config.yml로 경로 접근성 사유를 문서화한다.
  • 저포트 권한은 service unit에 필요한 capability만 위임한다.
  • 변경 후 서비스 재시작 성공 및 ss -lntp에서 443 리스닝 관찰.

안전 주의

  • 서비스 동작 보장을 위해 chmod 777처럼 전역 쓰기 권한으로 우회하지 않는다.
  • SELinux/감사 이슈가 있는 환경에서 무작정 무활성화하지 않는다.
풀이 예시 
systemctl cat report-api
namei -l /srv/report/config.yml
chown root:report-api /srv/report
chmod 0750 /srv/report
chown root:report-api /srv/report/config.yml
chmod 0640 /srv/report/config.yml
install -d -m 0755 /etc/systemd/system/report-api.service.d
cat > /etc/systemd/system/report-api.service.d/capability.conf <<'EOF'
[Service]
AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
EOF

systemctl daemon-reload
systemctl restart report-api
systemctl is-active report-api
systemctl show report-api -p User -p Group -p AmbientCapabilities -p CapabilityBoundingSet
ss -lntp | grep ':443'
journalctl -u report-api -n 80 --no-pager
완료 판단:
- 포트 바인딩 실패 사유와 파일 경로 권한 사유를 분리해 기재
- 수정 결과가 로그/소켓/서비스 상태와 일치

5) 디스크 공간 문제 해결

문제

/var가 100%로 보이나 du 합계가 상대적으로 작은 상황을 가정하고 원인을 분리해 보고서를 작성한다.

완료 조건

  • df -hT /var와 df -i /var를 동시에 캡처한다.
  • findmnt /var로 같은 파일시스템 경계를 확인한다.
  • du -xhd1 /var | sort -h로 큰 경로를 도출한다.
  • lsof -a +L1 /var에서 /var 아래의 열린 삭제 파일 후보를 확인한다.

안전 주의

  • 로그 디렉터리 삭제 전 회전 정책, 보존 정책, 서비스 영향도를 확인한다.
  • 원인 분석 전 불필요한 rm -rf를 금지한다.
풀이 예시 
df -hT /var
df -i /var
findmnt /var
du -xhd1 /var | sort -h
lsof -a +L1 /var | head -n 20
완료 판단:
- block 부족인지 inode 부족인지 분리 판단
- 동일 파일시스템 내 경로 기준으로만 원인 후보 도출
- 열린 삭제 파일 존재 시 서비스 중단 없이 조치 플랜 분리

6) SSL 인증서 작업

문제

폐기 가능한 디렉터리에 임시 Lab CA를 만들고, 그 CA로 서명한 api.example.net 인증서를 생성해 SAN·subject·key 일치와 chain을 검증한다.

완료 조건

  • CA key와 server key 권한이 600이다.
  • CSR에 SAN이 포함되어 있음을 openssl req -noout -text로 확인한다.
  • Lab CA로 서명된 인증서의 유효기간과 chain이 openssl x509, openssl verify로 검증된다.
  • key와 CSR 공개키 해시가 동일하다.

안전 주의

  • 개인 키 출력(콘솔/스크린샷/공유 저장소) 금지.
  • 임시 비밀번호 없는 키 생성은 과제용 실습 경계에서만 사용한다.
풀이 예시 
install -d -m 700 /root/lfcs-pki
cd /root/lfcs-pki
openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout lab-ca.key -out lab-ca.crt -days 30 \
  -subj "/CN=LFCS Lab CA"
openssl req -new -newkey rsa:2048 -nodes -keyout api.example.key -out api.example.csr \
  -subj "/CN=api.example.net" \
  -addext "subjectAltName=DNS:api.example.net"
chmod 600 lab-ca.key api.example.key
openssl req -in api.example.csr -noout -text
printf 'subjectAltName=DNS:api.example.net\n' > api.example.ext
openssl x509 -req -in api.example.csr \
  -CA lab-ca.crt -CAkey lab-ca.key -CAcreateserial \
  -out api.example.crt -days 30 -extfile api.example.ext

openssl pkey -in api.example.key -pubout -outform DER | sha256sum
openssl req -in api.example.csr -pubkey -noout | \
  openssl pkey -pubin -outform DER | sha256sum
openssl x509 -in api.example.crt -noout -subject -issuer -dates -ext subjectAltName
openssl verify -CAfile lab-ca.crt api.example.crt
완료 판단:
- SAN/subject/만료일 체크 완료
- key와 CSR 해시 일치
- verify 결과에서 chain 신뢰성 확인

공통 체크리스트

각 과제는 시작 전 date, hostname, 대상 명령의 현재 상태를 간단히 기록한 뒤 진행한다.

항목성공 기준
상태 정리작업 전후 id, status, 대상 명령 출력 캡처
안전 준수데이터 보존 정책 확인 없이 삭제·재생성하지 않음
완결성완료 조건의 각 항목을 텍스트로 증빙
시간 관리각 문제를 7~10분 내에 반복 수행

참고