LFCS 필수 명령 핵심 정리

Basic Git Operations에서 SSL 인증서까지 6개 필수 명령 competency를 상태/동작 중심으로 정리한다

이 문서는 공식 Essential Commands 6개 competency의 개념 층이다. shell·file·pipe·검색 기초가 약하면 Linux 기초와 기초 lab을 먼저 수행한다.

작성·검증 상태: AI가 구조화와 설명 초안을 보조했다. tool별 option은 local help를 우선하며, 실습에서 실제 service·certificate 동작까지 확인해야 완료로 본다.

이 영역을 끝내는 순서

  1. 각 competency에서 객체·설정 위치·runtime 상태·검증 command를 연결한다.
  2. 필수 명령 안내형 lab을 수행한다.
  3. 환경을 초기화하고 영문 단계별 실전을 풀이 없이 수행한다.
  4. Git·systemd·disk space·certificate의 이름과 조건을 바꿔 다시 푼다.

완료 기준은 service의 active나 Git의 commit 존재만 확인하는 것이 아니라 실제 process·socket·response, 요구된 file만 기록됐는지, certificate의 SAN·기간·key 일치까지 검증하는 것이다.

대상은 LFCS Essential Commands 공식 competency 6개: 기본 Git 작업, 서비스 생성·설정·문제 해결, 시스템 성능·서비스 모니터링·문제 해결, 애플리케이션·서비스 제약 조건, 디스크 공간 문제, SSL 인증서 작업이다. 모든 항목은 Rocky/RHEL 기준으로 설명하고, Debian 계열은 필요 지점에서만 병행 비교한다.

1) 기본 Git Operations

핵심 개념

작업 트리(worktree), index(staging area), commit, branch, remote의 구분이 핵심이다.

  • git status/git diff는 작업 트리 변경 유무를 본다.
  • git add는 변경을 staging하고, git commit은 staging을 스냅샷으로 고정한다.
  • git switch/git branch는 작업 흐름 분기를 만든다.
  • git fetch/git pull는 원격 상태 동기화, git push는 로컬 변경 공유를 담당한다.

대표 명령

git init
git status
git add path/to/file
git commit -m "feat: update config"
git switch -c feature/small
git merge feature/small
git remote -v
git fetch
git status
git log --oneline --graph --decorate -8

검증

  1. 커밋의 대상이 특정 파일인지 git diff --cached로 확인한다.
  2. 병합 후 이력 분기와 최종 상태를 git log --oneline --graph -n 10으로 확인한다.
  3. 원격 추적 상태를 git status -sb 또는 git branch -vv로 점검한다.

실수/위험

  • 전체 파일을 git add .로 넣은 뒤 불필요 변경이 들어가면 롤백 범위가 커진다.
  • git push --force를 확인 없이 사용하면 원격 히스토리를 파괴할 수 있다.
  • 작업 트리에 미완료 변경이 있을 때 무리하게 branch를 전환하지 말고 status와 diff로 충돌 가능성을 먼저 확인한다.

배포판 차이

  • Git 기본 동작은 배포판 간 동일하지만 패키지 이름·버전이 다를 수 있다.
  • Rocky/RHEL은 dnf install git, Debian 계열은 apt install git.
  • 초기 설정은 ~/.gitconfig가 시스템별 자동 설정 차이를 가질 수 있으므로 각 환경에서 재확인한다.

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

핵심 개념

systemd의 서비스는 설정 파일(유닛), 실행/종료 동작, 로그를 분리해 본다.

  • daemon-reload는 unit 파일 재해석만 수행한다.
  • enable --now는 부팅 활성화와 즉시 시작을 같이 수행한다.
  • is-active(실행 상태), is-enabled(부팅 활성), status, journalctl -u를 함께 본다.

대표 명령

systemctl daemon-reload
systemctl cat my-service
systemctl enable --now my-service.service
systemctl is-active my-service.service
systemctl is-enabled my-service.service
journalctl -u my-service.service -n 60 --no-pager
systemctl status my-service.service
systemd-analyze verify /etc/systemd/system/my-service.service

검증

  1. systemd-analyze verify로 문법 오류를 먼저 걸러낸다.
  2. systemctl is-active, is-enabled를 통해 런타임/부팅 기준을 분리해 확인한다.
  3. journalctl과 systemctl status로 실패 원인의 첫 번째 에러를 확인한다.

실수/위험

  • 유닛 파일 편집 후 daemon-reload 없이 start만 하면 변경 반영이 안 될 수 있다.
  • 권한 없는 실행 파일/경로 오타로 ExecStart가 실패한다.
  • service/target 이름을 헷갈리면 systemctl stop 범위를 잘못 선택해 다른 서비스에 영향 줄 수 있다.

배포판 차이

  • 서비스 이름은 배포판마다 다르다. (예: sshd vs ssh)
  • 정책은 유사하지만 패키지 경로 및 기본 target/유닛 구성은 다르다.

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

핵심 개념

성능 진단은 단일 지표가 아니라 시점 동기화된 지표 묶음으로 본다.

  • load average는 실행 대기 압력을 의미하지만 곧바로 CPU 병목은 아니다.
  • ps는 누가 자원 사용이 큰지 구체적으로 보여 준다.
  • ss -lntp는 실제 listening socket과 소유 프로세스를 확인해 서비스 가시성을 더한다.
  • 네트워크/디스크 I/O 지표와 조합해야 병목 위치가 정밀해진다.

대표 명령

uptime
ps -eo pid,ppid,pcpu,pmem,user,comm --sort=-pcpu | head
vmstat 1 5
ss -lntp
systemctl status api.service
journalctl -u api.service --since "10 min ago"

검증

  1. uptime의 평균치 추세와 ps 상위 프로세스 사용률을 비교한다.
  2. ss -lntp에서 서비스 소켓 바인딩 실패 여부를 본다.
  3. 같은 시간축에서 journalctl 에러 타임스탬프를 맞춰 원인 후보를 좁힌다.

실수/위험

  • top/vmstat 단일 스냅샷만 보고 원인을 확정하면 간헐 장애를 놓친다.
  • CPU 수치만 보고 서비스를 재시작하면 disk/memory 원인을 감춘다.
  • 모니터링 중 캐시 삭제, 서비스 재시작은 최후 수단으로 한다.

배포판 차이

  • CPU/메모리 기본 도구는 거의 공통이나 기본 유틸 존재 패키지가 다를 수 있다.
  • Rocky/RHEL은 netstat 미설치가 잦아 ss 위주로 훈련하고 Debian 계열도 동일 패턴을 권장한다.

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

핵심 개념

서비스 실패는 보통 “권한→경로→포트→리소스 제한→보안 레이블(SELinux)” 순으로 좁혀 본다.

  • 먼저 대상 서비스의 실제 실행 사용자와 실행 파일 권한을 확인한다.
  • namei -l로 경로의 모든 구성요소 권한을 따라간다.
  • 저포트 바인딩은 capability 또는 권한 위임 설계가 필요할 수 있다.
  • ulimit로 자원 제한, SELinux context와 log를 함께 확인한다.

대표 명령

systemctl cat report-api
namei -l /srv/report/config.yml
getfacl /srv/report/config.yml
systemctl show report-api -p User -p Group -p LimitNOFILE -p AmbientCapabilities
getcap /usr/local/bin/report-api
ss -lntp
journalctl -u report-api -n 80

검증

  1. 서비스 사용자와 설정 파일 경로의 접근성을 확인한다.
  2. 포트가 사용 가능한지 ss -lntp로 본다.
  3. systemd unit의 AmbientCapabilities= 또는 native binary의 file capability를 선택하고 effective 설정을 확인한다.

실수/위험

  • Permission denied를 chmod 777로 즉시 해결하려고 하지 않는다.
  • 루트 실행권한만 올리는 방식은 표면적 해결이지만 보안/감사에서 위험하다.
  • SELinux를 일괄 비활성화하면 감사 추적이 약해진다.
  • file capability는 script에 기대대로 적용되지 않을 수 있고 package update로 사라질 수 있다. systemd 서비스라면 unit 범위의 capability 위임을 우선 검토한다.

배포판 차이

  • RHEL 계열은 SELinux가 기본 활성일 가능성이 높다.
  • Debian 계열은 기본 정책이 다른 경우가 있어 getenforce/sestatus 전후를 구분해 분석한다.

5) 디스크 공간 문제 해결

핵심 개념

df는 파일시스템 전체 사용량, du는 디렉터리 트리 사용량이다. 둘의 불일치는 정상일 수 있다.

  • df -i로 inode 고갈도 반드시 확인한다.
  • 같은 파일시스템 경계(findmnt)를 보고 du 범위를 정확히 제한한다.
  • 삭제된 파일이 열린 상태(lsof +L1)면 실제로 파일이 없어도 공간이 유지될 수 있다.

대표 명령

df -hT /var
df -i /var
findmnt /var
du -xhd1 /var | sort -h
lsof -a +L1 /var
journalctl -S "1 hour ago" --priority=err

검증

  1. block 사용률과 inode 사용률을 함께 본다.
  2. 경로별 기여도(du)와 동일 파일시스템 여부(findmnt)를 일치시킨다.
  3. /var 아래 실제 사용량을 막는 프로세스는 lsof -a +L1 /var로 확인한다.

실수/위험

  • du 합이 작다는 이유만으로 즉시 삭제를 시작하지 않는다.
  • 운영 중 로그 디렉터리를 삭제 전에는 서비스 정책/보존주기를 확인한다.
  • 캐시 정리/로그 회전 조치를 문서화 없이 수행하면 추적이 어려워진다.

배포판 차이

  • 기본 패키지 구성으로 lsof가 없을 수 있으므로 설치 유무를 확인한다.
  • journald 로그 정책 및 기본 회전 주기가 배포판마다 달라 진단 기준 오탐 가능성이 있다.

6) SSL 인증서

핵심 개념

private key는 비밀 자산, CSR은 서명 요청, cert는 공개 검증 대상이다.

  • 키와 인증서는 형식과 알고리즘 일치가 먼저다.
  • CN만 확인하면 안 되고 SAN, 유효기간, CA 체인, key 매칭을 모두 점검한다.
  • 만료 임박 판단은 notAfter 기준으로 정량적으로 확인한다.

대표 명령

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,DNS:www.api.example.net"

openssl req -in api.example.csr -noout -text
openssl x509 -in api.example.crt -noout -text
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 verify -CAfile ca-bundle.crt api.example.crt

검증

  1. 키 권한이 600이고 경로가 보호되어 있는지 확인한다.
  2. 인증서의 subject, SAN, 만료일(notAfter)을 openssl x509 -text로 확인한다.
  3. 키 공개키와 CSR 공개키 해시가 일치하는지 비교한다.

실수/위험

  • 키를 널리 출력하거나 공유 저장소에 두면 민감정보 유출이다.
  • CN만 맞고 SAN이 누락되면 브라우저 인증 실패가 발생한다.
  • CA 체인 경로를 점검하지 않으면 trust 오류를 제대로 진단하지 못한다.

배포판 차이

  • OpenSSL 버전에 따라 기본 동작이 다를 수 있다. 특히 확장 지정 방식과 출력 형식은 1.1/3.0에서 차이를 보일 수 있다.
  • Rocky 9 계열(주로 OpenSSL 3)에서는 openssl 기본 정책 제약이 더 엄격한 편이다.

참고