[리눅스 기초] 고급 권한 관리, 작업 스케줄링, 디스크 관리, 파일시스템 및 스왑

Chapter 02. 고급 권한 관리

• 대부분의 경우 기본 권한만으로도 파일의 접근 제어를 설정할 수 있지만, 특정한 목적을 가진 파일의 경우 기본적인 권한만으로는 적절한 권한을 부여하기 어려운 경우가 있다.
• 이러한 문제를 해결하기 위해 특수 권한(확장 권한)을 사용한다.
• 특수 권한의 종류 - setuid, setgid, sticky bit
• setuid
  • 실행 중 프로세스 소유자를 파일 소유자로 변경한다.
  • 기호 s
  • 다른 사용자의 신분으로 잠깐 변신할 수 있게 해준다.
  • 설정된 파일 실행 시 실행자가 아니라 파일의 소유한 사용자의 권한으로 프로세스가 실행된다.
  • 대표적인 예 - passwd
    • student6@rocky-node2:~$ passwd → 일반 사용자가 자신의 패스워드를 설정한다.
    • 즉, /etc/shadow → 여기가 수정이 된다. 아무런 권한이 없는데, 일반 사용자가 어떻게 수정할까? 원칙적으로는 루트 사용자만 해당 파일 수정이 가능하다.
    • 살펴보면 실행 권한이 아니고, 소유자의 실행권한에 rws, 즉 s가 들어가 있다. → setuid 설정이 되었다는 뜻이다.
    • 즉 일반 사용자가 사용해도 루트권한을 빌려서 비밀번호를 변경할 수 있게 된다.
• setgid
  • 파일에서의 기능 - 실행 중 프로세스 그룹을 파일 소유 그룹으로 변경한다.
  • 디렉터리에서의 기능 - 파일 생성 시 소유 그룹을 디렉터리 소유 그룹으로 상속한다.
  • 기호 s
  • 첫번째 용도 - 실행파일에 setgid 설정 시 실행자의 그룹이 아니라 파일을 소유한 그룹으로 실행이 된다.
  • 두번째 용도(주로 사용) - 디렉토리에 setgid 설정 시 해당 디렉터리 안에 생성된 파일의 소유 그룹이 디렉토리 소유 그룹으로 상속한다.
    • 회사의 공유 폴더 - 부서별 공유 폴더
    • 누가 파일을 만들었든지, 각 팀끼리는 같은 팀 내의 팀원들이 만든 파일에 접근이 가능해야 한다.
  • 그룹 권한에 s 설정 → setgid
  • 기본 그룹이 아닌 systemd-journal 그룹이 상속되었다. → setgid가 설정되었기 때문이다.
• sticky bit
  • 디렉토리 안에서 자신의 파일만 삭제할 수 있도록 하기 위해 설정한다.
  • 공유게시판 → A, B, … → A는 A가 쓴 글만 지워야한다.
  • 기호 t
  • rwx의 권한의 한계 → 다른 사람이 글을 지울 수 있다. 자기가 쓴 것만 지울 수 있게 하자 → sticky bit
  • 대표적인 예 - /tmp → t로 설정 → sticky bit
  • 공용 게시판의 문제 → sticky bit 설정하여 해결
• 특수 권한 설정
  • chmod 명령어 사용
  • 심볼릭 모드와 절대 모드(8진수 방식) → 표준 권한 부여할 때와 동일
  • 절대 모드
    • 표준 파일의 권한은 3자리이지만, 특수 권한을 포함하는 경우 4자리 8진수이다.
    • 4자리 8진수의 첫째 자리에 특수 권한 값을 지정하고, 나머지 세 자리에 소유자, 그룹, 기타 사용자의 표준 권한을 지정한다.
    • umask → 4자리
    • setuid: 4000
    • setgid: 2000
    • sticky bit: 1000
  • 심볼릭 모드
    • setuid: u + xs
    • setgid: g + xs
    • sticky bit: o + xt
• ACL
  • 세밀한 권한 제어가 가능하다.
  • 표준 권한 체계에서 제외된 개별 사용자나 그룹에 별도의 권한을 부여 및 제한할 수 있다.
  • 현업에서 잘 사용하지 않는다. 이유는 복잡도가 올라가기 때문이다.
  • 관리해야 할 것이 많아진다.
  • 기본적인 내용 및 개념 위주로 학습을 하자.
  • 마케팅 팀 협업 프로젝트를 가정해보자
    • A 파일 → 과장급만 보게 하기
    • B 파일 → 대리급만 보게 하기
    • 이러한 상황은 rwx로는 부족하다 → ACL 도입
  • ACL → 확장 권한 시스템
  • ACL은 기본적으로 적용이 되어있다.
  • acl이 적용되었다면 권한 끝부분이 .이 아니고 +로 나온다. +로는 설정 유무만 파악이 가능하고 구체적인 설정을 보려면, getfacl로 확인한다.
  • getfacl 으로 확인해보면, user:user01:rw 와 같이 이전에 했던 구체적인 설정이 나온다.
  • ,를 사용하여 한번에 여러 명 및 여러 그룹 권한 설정도 가능하다.
  • 그룹 권한 설정도 가능하다.
  • ACL 설정은 setfacl 명령어를 사용하고, 정보 확인은 getfacl 을 사용한다.
  • 디테일하게 파일에 대해 권한을 설정하는 것이다.
  • mask 개념 - acl에서 중요하다.
    • 마스크는 지정된 사용자와 그룹 그리고 소유 그룹이 사용할 수 있는 최대 권한을 일괄적으로 제한하는 역할을 한다.
    • setfacl -m m::r acl/files/mask.txt
    • 위와 같이 마스크 설정 후 getfacl 으로 확인해보면 일부 사용자들에게 effective가 붙어있다.
    • effective의 뜻 → 권한을 부여받았지만 마스크로 인해 r 과 같이 일부 권한만 가능하다는 뜻이다.
  • 제거
    • setfacl -x u:user02 acl/files/mask_test.tsx → 부분적으로 acl 제거
    • setfacl -b acl/files/mask_test.tsx
      • 모든 설정을 하기 이전으로 돌아감. 기존의 처음 상태가 된다.
      • +도 다시 .으로 돌아가있다.

 

Chapter 03. 작업 스케줄링

• 지정한 시간에 한번만 실행하는 작업을 설정 및 관리할 수 있다.
• 특정 주기를 가진 작업을 반복 실행하도록 등록하고 관리할 수 있다.
• 예) 일요일마다 로그 파일 정리하기, 새벽 3시 마다 백업하기
• 단일 작업 예약
  • 한 번만 실행하고 종료되는 것
  • 예) 3시간 후에 시스템 재부팅
• 주기적인 작업 예약
  • 주기적인 패턴에 따라 실행
  • 예) 매주 일요일, 매일 3시… 등
• 단일 작업 예약
  • at
    • 해당 명령어를 통해서 단일 작업 예약을 등록한다. 그러나 주기적인 작업으로 거의 다 대체가 된다.
  • atd
    • atd 데몬이 지정한 시점에 해당 작업을 백그라운드에서 실행하며, 실행 결과는 터미널 화면에 출력되지 않는다.
    • 마지막 d는 데몬(daemon)이다.
    • 데몬은 백그라운 프로세스에 의해서 관리되고 있는 것을 말한다. 백그라운드에서 실제로 작업을 실행시켜주는 것이다.
    • at으로 만들고, 시간이 되면 실제로 작업을 해주는 것은 데몬이다.
    • atd → 백그라운드에서 대기하면서 예약된 at 작업을 처리한다.
• 주기적인 작업 예약
  • crontab: 해당 명령어를 통해 작업을 등록 및 수정하며, 등록된 작업 내역은 /var/spool/cron 디렉터리 아래에 사용자 이름과 동일한 이름의 파일에 저장된다.
  • -e 옵션으로 crontab 파일을 편집한다.
  • crond: cron 데몬이 매 분마다 crontab 파일을 확인해서 백그라운드에서 작업을 실행시킨다.
  • 시스템 cron: 관리자가 시스템 전체에 걸쳐서 정기적으로 실행해야 하는 유지보수 작업을 등록할 때 사용한다. 이 기능을 활용하기 위해서는 /etc/crontab 파일을 관리자 권한으로 직접 편집해야 한다.
  • crond가 매분 마다 crontab 파일을 확인하고 실행한다.
• anacron
  • 예약한 시점에 시스템 전원이 꺼져 있거나 장애가 발생하면 해당 작업을 수행하지 않고 누락되는 한계를 anacron을 통해서 나중에 시스템이 다시 켜졌을 때 주기 조건을 확인하여 누락된 작업은 마저 수행한다.
  • cron은 항상 켜져있는 것을 가정하고 정확한 시각을 기준으로 동작하는 구조적 특성이 있다.
  • anacron은 시스템이 꺼져있을 때 놓친 작업을 시스템이 다시 켜지면 주기 조건을 확인하여 누락된 작업을 실행한다.
  • 엔터프라이즈에서는 거의 사용하지 않는다. 서버용 컴퓨터는 꺼지지 않기 때문이다. 오히려 개인이 사용
  • 서버 다운 시를 대비한다.
  • 시각 단위로 작업하는 cron과 달리, 지정한 주기(매일, 매주, 매월)를 기준으로 작동한다.
  • cron은 일반 사용자가 사용할 수 있지만, anacron은 시스템 관리자만 사용한다.

 

Chapter 04. 디스크 관리

• 서버 관리의 기본이자 중요한 작업이다.
• sda라는 디스크다 1, 2, 3으로 파티셔닝되어 있다.
• 메모리 → 2GB
• 최대 용량이 90GB이고, 실제로는 전부 쓰지는 않는다.
• HW → OS → VM
• lsblk → 디스크 장치 구조 확인 명령어
  • 현재 작업 시스템이 sda에 들어있다.
  • sda1, sda2, sda3로 파티셔닝 되어있고, root는 sda3에 있다.
  • 디스크가 sdb, sdc도 있는 것을 확인할 수 있다.
• sdb → 두번째 디스크
• sab 장치에서 최대 4조각으로 나뉘고, 그 중 하나는 자유롭게 또 나눌 수 있다.
• 끝에가 리눅스 타입 → 이것을 스왑 파티션으로 변경할 것이다.
• 스왑은 메모리가 부족할 때 디스크를 임시 메모리로 사용하는 것이다. 타입 t로 표시한다.
• 저장을 하고 나가야 최종 저장이 된다.
• extended → 18G를 1G씩 혹은 2G씩 나눠서 18개, 9개로 나눌 수 있다.
• 4번까지는 자리가 있으므로 확장 파티션은 5번부터 시작한다.
• 파티션을 했는데 바로 lsblk으로 확인이 안되는 경우 partprobe으로 확인
  • 보통 자원 낭비를 막고자 작업한 부분만 partprobe 으로 본다.
• 디스크 파티셔닝

 

Chapter 05. 파일시스템 및 스왑

• 파일시스템은 운영체제가 사용하는 구조이다.
  • 도서관을 운영한다고 하자. 수만권의 책을 관리해야 한다. 어떻게 관리할 것인가?
  • 책의 종류, 주제, 고유 번호, 위치 기록(시스템) → 이러한 것들이 파일시스템과 유사하다.
  • 파일의 이름, 위치, 크기 등의 정보를 관리하고, 운영체제가 파일을 쉽게 접근할 수 있도록 해준다.
  • 파일시스템 규칙에 맞게 데이터를 저장한다. 그렇게 해야 속도도 빠르고 효율적이다.
  • 파일 시스템은 운영체제가 디스크나 저장 매체에 데이터를 구조화하여 저장하고 관리하는 방식이다. 파일과 디렉터리를 계층적으로 구성하며, 데이터의 저장 위치, 접근 방법, 권한 관리 등을 담당한다.
  • 파일시스템 규칙에 맞게 데이터들이 저장되어 효율적으로 데이터를 사용할 수 있다.
  • os가 파일시스템을 거치지 않고 디스크를 직접 읽게 되면
    • 비효율적이다.
    • 오류가 많이 나올 것이다.
  • 파일시스템은 추상화 계층을 제공해서 복잡한 것을 규격화 시켜서 파일 관리를 단순하게 해준다.
  • 파일시스템으로 운영체제가 스토리지를 인식하고 연결하는 과정이 가능하다(?)
  • macOS → USB를 꽂고 파일을 옮기고 window로 다시 꽂으면 파일이 안읽힌다. 파일시스템이 다르기 때문이다.
  • windows = NTFS, macOS = APFS … 10 이전 = HFS+, Rocky linux = XFS …
• exFAT → 현대적이고 범용적인 파일시스템이다. 범용적이므로 크로스 플랫폼으로 파일을 이동하는게 가능하다.
• FAT32 → 4GB의 제약을 받는다.
• 섹터: 디스크의 가장 작은 저장 단위로 디스크 블록이라고도 한다. (512byte)
• isize=512 → 1섹터
• bsize=4096 → 블록 크기, 4KB
• sudo blkid → 블록 장치의 속성
• UUID는 고유한 식별자. 중복 가능성이 통계적으로 없다. 식별자가 왜 필요할까? 부팅 순서에 의해서 숫자가 달라질 수 있다. sdb가 다음에 가장 먼저 부팅되면 sda가 된다. 이전에 sda였던 것이 sdb가 된다. 이전에 설정한 경로에 문제가 생긴다. 그래서 현업에서는 장치 이름을 절대 쓰지 않고 UUID로 식별한다. UUID는 변하지 않으므로 장비를 식별하는데 문제가 되지 않는다.
• 파일시스템 관리
  • 파일시스템 생성
    • 디스크의 파티셔닝을 완료하면, 파티셔닝한 장치에 파일시스템을 생성해야한다.
    • 파일시스템을 생성하는 도구는 mkfs 명령어이다.
  • 파일시스템 마운트
    • 파일시스템을 생성한 장치를 사용하기 위해 연결할 디렉터리를 생성하고 해당 경로에 장치를 연결해야 한다.
    • 파일시스템은 자동 마운트 되지 않아서 풀린다.
    • 파일 시스템 마운트 두가지 방법
      1. UUID로 장치를 식별해서 넣는 방법
      2. /dev/sdb1과 같이 경로를 지정해서 연결하는 방법
    • 비유하자면 게임기에는 게임 카트리지에 꽂을 수 있는 슬롯이 있다. 카트리지에 꽂기 전까지는 게임을 할 수 없다. 마리오 게임이 파일시스템이고, 이것을 슬롯에 꽂는다. 꽂는 곳이 마운트 포인트다. 꽂는 순간 마운트되고, 게임기가 마운트를 인식해서 사용할 수 있다.
    • 파일시스템을 설정했으니 마운트해야 한다. (꽂는다.)
    • 사실 이미 꽂아져있지만 아직 인식을 못했다. 슬롯을 먼저 만든다.
    • 자동 마운트 → UUID 방법과 디바이스명으로 넣는 방법이 있다.
    • sudo mount -a → 설정한 것에 문제가 있는지 확인할 수 있다. 에러가 난다면 무조건 확인할 것.