▒ SU의 CentOS7 강좌33 14. 시스템 및 서비스 관리(systemd) (1/2)

12.4. TCP wrapper
TCP wrapper는 클라이언트 IP, 호스트네임, 서버의 프로세스 이름 등을 기반으로 간다하게 접근 제어할 수 있다. 하지만 TCP wrapper를 사용하기 위해서는 13장 초반부분에도 소개하였듯 libwrap 라이브러리를 사용하는 경우 또는 xinetd를 사용하는 경우 가능하다. CentOS7의 경우 CentOS6까지 xinetd를 통해 제공되던 서비스들(rsync, telnet등)이 systemd로 통합되어 rsync, telnet 서비스의 경우는 TCP wrapper를 사용할 수 없게 되었다. libwrap 라이브러리를 사용하는 프로그램을 찾아보면 다음과 같다.

 

14. 시스템 및 서비스 관리(systemd)

CentOS7 부터는 시스템 및 서비스를 관리하기 위해 systemd가 도입되었다.
CentOS6 이하에서 모든 프로세스의 조상은 init프로세스이며 PID 1이였다. CentOS7부터는 모든 프로세스의 조상은 systemd프로세스이며 PID 1이다. 이는 systemd가 시스템을 시작하고 관리하는 역할을 하게 되었다는 것이다. systemd는 멀티코어 환경을 고려하여 개발되었기 때문에 병렬처리에 있어 우수하다. 특히 부팅과정에서 많은 서비스를 동시에 시작하기 때문에 리눅스 부팅 시간이 아주 많이 단축되었다. 또한 cgroup을 사용하여 데몬을 제한할 수 있고 시스템 상태를 저장할 수 있는 Snapshot기능을 제공한다. 서비스 제어 과정에서 파일시스템을 마운트, 언마운트할 수 있고 서비스 시작을 위해 소켓(Socket)과 D-Bus를 활성화 시킬 수 있다. systemd는 예전에 사용하던 SysV와 LSB init 스크립트들과 호환을 가지지만 옵션에 있어 제약은 있다. systemd의 특별한 기능으로 로깅 데몬이 포함되어 있어 서비스별로 로그를 조회할 수 있다. systemd는 timedatectl과 같이 원격 제어를 지원한다.
systemd의 도입으로 많은 부분이 통합되었다. CentOS6까지 사용하던 /etc/rc.d/init.d/서비스 파일은 몇몇 서비스를 제외하고 서비스 Unit로 분리되었다. rsync, telnet등의 xinetd서비스 파일들(/etc/xinetd.d/*)은 xinetd를 사용하지 않고 systemd에서 직접 서비스 Unit로 지원한다. 부팅 시 순차적으로 실행되던 스크립트 파일인 /etc/rc.d/rc.sysinit 파일은 존재하지 않는다. rc.sysinit에서 실행되던 부분이 의존성을 고려하여 병렬 처리될 수 있게 체계화되어 Unit으로 분리되었다.
systemd의 Unit 타입들을 확인해 보자.

CentOS7부터는 systemd 도입으로 부팅 과정이 바뀌었다. 변경된 부팅 과정을 살펴보자.

1. 시스템이 부팅되면, 시스템 BIOS에 의해 Disk의 MBR을 읽어 들인다. MBR에는 부트로더 GRUB이 설치되어 있으며 GRUB는 /boot/grub2/grub.cfg 파일을 읽어 부팅할 커널 리스트를 보여줄 것이다.

2. 기본 커널을 선택했다면, 커널이 저장된 /boot/vmlinuz-3.10.0-123.el7.x86_64파일을 실행하고 메모리 Disk(RAM Disk)를 생성하여 initramfs-3.10.0-123.el7.x86_64.img 파일을 압축해제 하여 chroot로 최상위 / 디렉토리를 압축이 해제된 경로로 변경하게 되며, 변경된 /의 /init파일을 실행하게 된다. 
initramfs-3.10.0-123.el7.x86_64.img파일을 압축해제 하고, cpio로 임시 디렉토리에 풀어서 확인해 보도록 하자.
우선 file 명령어로 파일 종류를 확인하였다.

 

~]# file /boot/initramfs-3.10.0-123.el7.x86_64.img
/boot/initramfs-3.10.0-123.el7.x86_64.img: gzip compressed data, from Unix, last modified: Wed Oct  8 16:05:43 2014, max compression

 

gzip 으로 압축된 데이터임을 확인할 수 있다.
다음으로 임시 디렉토리를 생성하고 압축을 해제 해 보자.

 

boot]# mkdir /boot/imsi
boot]# cd imsi
imsi]# zcat /boot/initramfs-3.10.0-123.el7.x86_64.img | cpio -iv
.
usr
usr/bin
usr/bin/bash
...

 

imsi 디렉토리를 생성하고, zcat으로 압축파일의 데이터를 해제 하여 cpio 명령어로 파일을 풀었다.
어떠한 파일 및 렉토리가 있는지 확인해 보자.

 

imsi]# tree -L 2
.
├── bin -> usr/bin
├── dev
│   ├── console
│   ├── kmsg
│   └── null
├── etc
│   ├── cmdline.d
│   ├── conf.d
...
│   └── virc
├── init -> usr/lib/systemd/systemd
├── lib -> usr/lib
├── lib64 -> usr/lib64
├── proc
├── root
├── run
│   ├── initramfs
│   └── lock
├── sbin -> usr/sbin
├── shutdown
├── sys
├── sysroot
├── tmp
├── usr
│   ├── bin
...
│   └── share
└── var
    ├── lib
    ├── lock -> ../run/lock
    ├── log -> ../run/log
    └── run -> ../run

 

 

리눅스에서 기본적으로 사용되는 실행파일, 설정파일, 장치파일등 대부분의 파일들이 존재한다.  /init은 /usr/lib/systemd/systemd로 심볼릭 링크된 것을 확인할 수 있다.

3. 위 “2번”의 과정에서 CentOS5와 CentOS6은 init 프로세스가 호출된다. CentOS 7은 systemd프로세스가 호출된다. 각 프로세스 호출 후 실행되는 스크립트들을 살펴보자.

위 표에서와 같이 CentOS 6 이하 버전에서 호출되던 rc.sysinit, rc 등의 초기화 스크립트들은 모두 없어지고, CentOS 7에 도입된 systemd는 각각의 유닛으로 모든 과정이 병렬화되어 실행된다.

 

14.2. 서비스 관리
CentOS 6이전 버전의 리눅스는 /etc/rc.d/init.d/ 디렉토리에 서비스 관리 스크립트가 존재했다. 하지만 CentOS 7 부터는 서비스 관리 스크립트들은 몇몇 서비스를 제외하고 각 서비스 유닛(Unit)으로 변경되었다. 서비스 유닛은 .service으로 끝나는 파일이며, systemctl에 의해 제어 된다. 물론 예전에 사용하던 service 명령어와 chkconfig 명령어의 사용은 가능하다. service 명령어와 chkconfig 명령어를 실행하면 systemctl으로 맵핑되어 실행된다.
예전 버전의 서비스를 제어하기 위한 service 명령어와 systemctl의 사용법을 비교하면 다음 표와 같다.

* systemctl은 <TAB>키를 사용한 자동완성 기능을 지능적으로 제공 한다. 예를 들면 systemctl start <TAB>키를 누르면 시작되지 않은 유닛들을 기준으로 자동완성 또는 유닛 리스트를 보여주고, systemctl stop <TAB>키를 누르면 시작된 유닛들을 기준으로 자동완성 또는 유닛 리스트를 보여준다.
* systemctl은 service와 달리 정해진 서비스 명령어외의 사용자 명령어는 제공하지 않는다. 예를 들면 Apache의 설정내역을 테스트하기 위한 configtest 등의 명령은 호환되지 않는다.

부팅 시 서비스 자동시작 여부를 설정하기 위해 사용하는 chkconfig와 systemctl의 명령을 비교해 보자.

14.2.1. 자동 시작 서비스 관리
시스템 부팅 시 자동 시작되는 서비스 리스트를 다음과 같이 확인해 보자.

 

 

~ ]# systemctl list-unit-files --type service |grep enabled
abrt-ccpp.service                           enabled
abrt-oops.service                           enabled
abrt-vmcore.service                         enabled
abrt-xorg.service                           enabled
abrtd.service                               enabled
accounts-daemon.service                     enabled
atd.service                                 enabled
...

 

 

systemctl을 사용하여 서비스 유닛 중 활성화(enabled)된 서비스 유닛을 나열해 보았다. 각 서비스 유닛을 확인하여 비활성화(disable)로 변경하는 것이 보안 및 시스템 성능 면에서도 필요한 부분이다.
프린트 관련 서비스 cups를 시스템 부팅 시 비활성화 되도록 해보자.

 

 

~ ]# systemctl disable cups.service
rm '/etc/systemd/system/multi-user.target.wants/cups.path'
rm '/etc/systemd/system/sockets.target.wants/cups.socket'
rm '/etc/systemd/system/printer.target.wants/cups.service'

 

 

cups서비스를 비활성화 하면, 관련된 파일이 위와 같이 삭제된다.
다시 cups서비스를 활성화 시켜보자.

 

 

~ ]# systemctl enable cups.service
ln -s '/usr/lib/systemd/system/cups.service' '/etc/systemd/system/printer.target.wants/cups.service'
ln -s '/usr/lib/systemd/system/cups.socket' '/etc/systemd/system/sockets.target.wants/cups.socket'
ln -s '/usr/lib/systemd/system/cups.path' '/etc/systemd/system/multi-user.target.wants/cups.path'

 

 

cups서비스를 활성화 하면, 관련된 파일을 심볼릭 링크를 건다.

 

14.2.2. 서비스 시작/상태확인/재시작/종료
서비스를 시작, 재시작, 종료를 다음과 같이해 보도록 하자. 먼저 시작되지 않은 서비스를 조회해 보자.

 

 

~ ]# systemctl list-units --type service -a |grep -w inactive
abrt-vmcore.service           loaded inactive dead    Harvest vmcores for ABRT
alsa-restore.service          loaded inactive dead    Restore Sound Card State
alsa-store.service            loaded inactive dead    Store Sound Card State
...

 

 

systemctl을 사용하여 서비스 유닛 중 중지된 서비스를 나열해 보았다.
정지된 서비스 중 파일 및 디렉토리 원격 동기화를 위해 사용하는 rsyncd 서비스를 시작시켜 보자.

 

 

~ ]# systemctl start rsyncd

 

 

위와 같이 입력하면 rsyncd 서비스가 시작된 것이다.
서비스 상태를 확인해 보자.

 

 

]# systemctl status rsyncd
rsyncd.service - fast remote file copy program daemon
   Loaded: loaded (/usr/lib/systemd/system/rsyncd.service; disabled)
   Active: active (running) since 일 2015-04-12 14:00:20 KST; 48s ago
 Main PID: 6379 (rsync)
   CGroup: /system.slice/rsyncd.service
           └─6379 /usr/bin/rsync --daemon --no-detach

 4월 12 14:00:20 localhost.localdomain systemd[1]: Starting fast remote file copy program .....
 ...

 

systemctl의 status명령을 사용하여 위와 같이 서비스 상태를 확인하였다. 서비스에 대한 간단한 설명, 시스템 부팅 시 자동시작 유무, 서비스 데몬 시작일, PID, CGroup, 최근 로그를 확인할 수 있다.
서비스 재시작은 다음과 같이 입력한다.

 

 

~ ]# systemctl restart rsyncd

 

그리고 서비스를 종료하는 방법은 다음과 같다.

 

~ ]# systemctl stop rsyncd

 

 

 

14.3. Target(런레벨)관리
CentOS 6이전 버전은 시스템 초기화를 위해 사용하는 0부터 6까지 런 레벨(run level)이 존재했다. 예를 들면 런 레벨 0은 종료, 런 레벨 3은 Text 모드, 런 레벨 5은 Xwindows를 사용한 GUI환경, 런 레벨 6은 리부팅으로 사용되었다. 하지만, CentOS 7에서 사용하는 systemd는 이 런 레벨을 타겟(target) 유닛으로 변경하였다. 기존 버전의 런 레벨과 systemd의 타겟 유닛은 다음 표와 같이 대응된다.


런 레벨 2,3,4는 동일하게 TUI 멀티유저 환경이다.
예전에 제공하던 runlevel명령어와 telinit 명령어는 호환을 가지며 다음과 같이 대응된다.


14.3.1. 현재 타겟(런 레벨) 확인
현재 런 레벨을 확인하기 위해 다음 명령어를 입력한다.

 

~ ]# runlevel
N 5

 

예전방식의 런 레벨 5를 확인할 수 있다. systemctl을 사용하여 확인해 보자.

 

~ ]# systemctl get-default
graphical.target

 

 

앞에서 정리한 표와 같이 런 레벨 5와 graphical.target은 동일한 것으로 볼 수 있다.

14.3.2. Target(런레벨) 변경
시스템의 기본 타겟을 변경해 보자.

 

 

~ ]# systemctl set-default multi-user.target
rm '/etc/systemd/system/default.target'
ln -s '/usr/lib/systemd/system/multi-user.target' '/etc/systemd/system/default.target'

 

 

systemctl set-default를 사용하여 multi-user 타겟으로 변경하였다. multi-user 타겟은 예전의 런 레벨 3이다. multi-user 타겟으로 전환해 보자.

 

 

~ ]# systemctl isolate multi-user.target

 

 

systemctl isolate를 이용하여 multi-user 타겟으로 전환하였다.
변경된 런 레벨을 확인하기 위해 다음 명령어를 입력한다.

 

 

~ ]# runlevel
5 3

 

 

런 레벨 5에서 3으로 변경된 것을 확인할 수 있다.
systemctl을 사용하여 확인해 보자.

 

 

~ ]# systemctl get-default
multi-user.target

 

 

multi-user 타겟으로 변경된 것을 확인할 수 있다.

14.4. 원격 시스템 systemd 제어
systemd의 특별한 기능중의 하나가 SSH를 이용하여 원격지에 있는 systemd를 제어할 수 있다는 것이다.

 

 

~]# systemctl -H root@192.168.0.201 restart rsyncd
The authenticity of host '192.168.0.201 (192.168.0.201)' can't be established.
ECDSA key fingerprint is 3c:40:a7:8a:e6:7e:0f:ba:f4:a1:c1:e3:6d:92:9d:d2.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.0.201' (ECDSA) to the list of known hosts.
root@192.168.0.201's password:
 ~]# systemctl -H root@192.168.0.201 status rsyncd
root@192.168.0.201's password:
rsyncd.service - fast remote file copy program daemon
   Loaded: loaded (/usr/lib/systemd/system/rsyncd.service; disabled)
   Active: active (running) since 일 2015-04-12 15:02:29 KST; 12s ago
 Main PID: 2153 (rsync)
   CGroup: /system.slice/rsyncd.service

 

위 예는 192.168.0.201 서버의 rsyncd 서비스를 재시작하고 서비스 상태를 확인한 것이다. SSH를 이용하기 때문에 계정@아이피를 -H옵션을 사용하여 입력한다. 그 외에는 systemctl명령어 사용법과 동일하다. 여러 대의 시스템을 관리한다면, 위와 같은 방법으로 쉽게 서비스를 관리할 수 있을 것이다. SSH의 키쌍을 이용하면 위 방법에서 비밀번호를 입력하지 않아도 되기 때문에 보다 효율적으로 대량의 시스템을 관리할 수 있을 것이다.