systemd 259: 주요 변경 사항 및 시스템 요구 사항

인포마텍 디지털 » 자료 » systemd 259: 주요 변경 사항 및 시스템 요구 사항

systemd 259의 안정 버전 출시는 리눅스 생태계에서 가장 논란이 많으면서도 핵심적인 구성 요소 중 하나에 또 다른 변화를 가져왔습니다. 대부분의 배포판에서 이미 지배적인 위치를 차지하고 있는 서비스 시작 및 관리 프레임워크인 systemd는 이번 릴리스에서 기술적 요구 사항, 보안 및 기존 기술의 폐기 측면에서 더욱 강화되었습니다.

이번 업데이트는 수개월간의 집중적인 작업 끝에 이루어졌으며, 새로운 C 라이브러리와의 호환성 개선, 보안 강화, 그리고 기존 코드 정리 (SysV 스크립트, TPM 1.2, iptables 등)라는 세 가지 주요 영역에 중점을 두었습니다. 또한, run0을 사용한 권한 관리, systemd-oomd를 사용한 메모리 처리, 로그 저장 방식, 그리고 libsystemd의 내부 종속성 모델에도 상당한 변화가 있습니다.

systemd 259 및 musl에 대한 실험적 지원

이번 버전에서 가장 주목받는 기능 중 하나는 systemd 259가 처음으로 C 표준 라이브러리 musl에 대한 부분적인 지원을 포함한다는 점입니다 . 이 라이브러리는 glibc에 비해 단순성과 리소스 소비 감소가 요구되는 경량 시스템, 최소형 컨테이너 및 임베디드 환경에서 널리 사용됩니다.

meson 빌드 시스템의 "libc" 옵션을 "musl"로 설정하면 musl 지원이 활성화됩니다 . 그러나 이 통합은 아직 완벽하지 않습니다. musl은 이름 서비스 스위치(NSS) 메커니즘을 구현하지 않기 때문에 이 라이브러리를 사용하여 컴파일할 때 systemd의 여러 부분이 비활성화됩니다.

구체적으로, musl을 사용하여 systemd 259를 빌드하면 nss-systemd, nss-resolve, systemd-homed, systemd-userdbd 및 systemd-nsresourced와 같은 핵심 구성 요소가 제외됩니다 . DynamicUser 옵션과 권한 없이 systemd-nspawn을 실행하는 기능도 사용할 수 없는데, 이는 이러한 기능에 크게 의존하는 컨테이너 환경에서 특히 중요한 문제입니다.

개발자들 스스로도 장기적인 지원을 보장할 수 없다고 인정하고 있습니다 . 지원 지속 여부는 커뮤니티의 실제 관심도, musl에 부족한 기능을 제공하는 추가 레이어의 완성도, 그리고 이 라이브러리에 특화된 버그 보고에 달려 있습니다. 수요가 적거나 유지 관리가 너무 복잡하다고 판단될 경우, 향후 버전에서 지원이 중단될 가능성도 배제할 수 없습니다.

하지만 musl에 대한 이러한 개방은 상징적인 차원에서 중요합니다. systemd는 오랫동안 glibc에 거의 전적으로 의존한다는 비판을 받아왔는데 , 이 때문에 다른 배포판이나 최소한의 구성으로 사용하는 시나리오에 적합하지 않았습니다. 이번 조치가 모든 문제를 해결하는 것은 아니지만, 다른 C 라이브러리에 완전히 폐쇄된 시스템이라는 기존의 이미지를 깨뜨리는 계기가 될 것입니다.

run0과 새로운 권한 모델: sudo의 대안

systemd 259의 또 다른 주요 기능은 유틸리티입니다. run0은 sudo를 대체할 현대적이고 안전한 명령어로 제안되었습니다.이 도구는 이미 systemd-run을 기반으로 구축되었지만, 이제 핵심 기능인 옵션이 추가되었습니다. --empower.

새로운 `--empower` 인수를 사용하면 UID를 루트로 변경하지 않고도 관리자 권한으로 세션을 시작할 수 있습니다 . 기존의 사용자 전환 방식 대신 `run0`은 커널 기능(예: `CAP_SYS_ADMIN`)을 활용하여 관리자 권한 작업을 수행하는 데 필요한 권한만 부여함으로써 루트 권한으로 완전히 전환될 위험을 줄입니다.

또한, 이러한 접근 방식으로 시작된 프로세스는 Polkit에서 관리하는 광범위한 작업 세트에 액세스할 수 있는 논리적 "권한 부여" 그룹 으로 묶입니다 . 이는 권한 증가가 세분화되고 제어되어, 액세스가 지나치게 광범위하게 허용되는 기존 sudo 방식보다 훨씬 엄격한 분리를 유지하기 위함입니다.

이러한 접근 방식은 가능한 한 루트 사용자의 직접 사용을 피하는 추세와 일맥상통하며 , 이는 매우 중요한 보안 원칙입니다. 그러나 run0의 진정한 효과는 실제 운영 환경에서 입증되어야 합니다. 각 배포판의 정책과 어떻게 통합되는지, 실제 기능 구성은 어떻게 되는지, 그리고 시스템 관리자가 새로운 워크플로에 얼마나 잘 적응하는지 등을 살펴봐야 할 것입니다.

SysV 초기화 및 레거시 정리 지원이 종료되었습니다.

systemd 259는 System V 스타일 서비스 스크립트의 완전한 종말을 알리는 시작 이기도 합니다 . 이러한 고전적인 메커니즘과의 호환성은 이미 수년 전부터 "점차 사라질 것"으로 알려져 왔으며, 이제 제거를 위한 명확한 일정이 확정되었습니다.

이번 버전에서는 차기 주요 릴리스를 앞두고 다음과 같은 내용을 발표합니다. systemd-sysv-generator, systemd-rc-local-generator, systemd-sysv-install과 같은 기존 구성 요소는 제거될 예정입니다.즉, 대본은 다음과 같습니다. /etc/init.d/ 이제 systemd는 이러한 사항들을 더 이상 고려하지 않게 되며, 이로써 거의 10년 동안 지속된 전환 과정이 마무리됩니다.

SysV 스크립트 기반의 사용자 지정 서비스를 여전히 유지 관리하는 관리자라면 이제 본격적으로 작업에 착수해야 합니다. 모든 스크립트를 목록화하고 네이티브 systemd 유닛 (.service, .socket 등)으로 마이그레이션해야 합니다. 대규모 배포판은 이미 이러한 전환을 거의 완료했지만, 사용자 지정 환경이나 오래된 설치 환경에서는 일부 "잔재"가 여전히 백그라운드에서 실행 중일 수 있습니다.

이러한 기존 코드 정리 작업은 SysV에만 국한되지 않습니다. systemd의 최근 버전에서는 `/forcefsck` 및 `/fastboot`와 같은 기존 방식에 대한 지원을 제거하고 커널 매개변수 및 최신 자격 증명 메커니즘으로 대체하고 있습니다. 버전 259에서도 동일한 방향으로 나아가고 있습니다. 즉, 유지 관리가 더 쉽고 일관성 있는 코드베이스를 위해 하위 호환성을 줄이는 것입니다.

systemd의 최소 요구 사항 259: 커널, 라이브러리 및 환경

구형 시스템에 가장 큰 영향을 미칠 수 있는 변화 중 하나는 systemd 259를 실행하기 위한 최소 소프트웨어 요구 사항이 증가했다는 점 입니다 . 이 버전은 더 이상 아주 오래된 하드웨어나 스택을 고려하지 않고, 최신 플랫폼을 지향합니다.

systemd 259에 통합된 주요 요구 사항 중에는 최신 플랫폼에 대한 헌신이 포함됩니다.

• 리눅스 커널 5.10 이상 필요 (최소 5.14까지 올라가는 것을 권장합니다.)
• 글리시 2.34 GNU 표준 라이브러리의 최소 버전입니다.
• 오픈 SSL 3.0.0 지원되는 암호화 기능의 필수 기반으로서.
• 유틸리티 리눅스 2.37 시스템의 기본 유틸리티를 사용하기 위한 필수 조건입니다.
• libxcrypt 4.4.0 비밀번호와 관련된 암호화 기능 관리를 위해.
• cryptsetup 2.4.0 및 libseccomp 2.4.0 볼륨 암호화 및 시스템 호출 필터링을 위해.
• 파이썬 3.9.0 보조 도구에 필요한 최소한의 필수 요소입니다.
• 일부 메모에는 다음과 같은 내용도 포함되어 있습니다. 엘푸틸스 0.177 업데이트된 종속성 세트의 일부로.

이러한 강화 조치는 5.10 이전 커널 브랜치를 고수하는 매우 오래된 시스템 이나 배포판이 기본 기술을 업데이트하지 않는 한 해당 버전에 대한 지원에서 자동으로 제외됨을 의미합니다 . 그 결과, 특수한 경우와 타협적인 해결책이 줄어들어 더욱 균일한 생태계가 조성됩니다.

대부분의 일반적인 데스크톱 및 서버 배포판에서는 이러한 요구 사항이 문제가 되지 않습니다. 최신 LTS 커널 브랜치는 이미 5.10 버전을 훨씬 넘어섰고 , 언급된 라이브러리도 널리 구할 수 있기 때문입니다. 가장 큰 문제는 임베디드 시스템, 어플라이언스 또는 업데이트가 자주 이루어지지 않는 매우 보수적인 설치 환경에서 발생할 수 있습니다.

보안 강화: TPM 2.0, 암호화 및 기기 제한 기능

보안 측면에서 systemd 259는 몇 가지 중요한 결정을 통해 발전을 가속화했습니다. 가장 눈에 띄는 변화는 systemd-boot와 systemd-stub이 TPM 1.2 지원을 완전히 중단하여 이제부터 TPM 2.0만이 참조 표준으로 간주된다는 점입니다.

이번 변경 사항으로 인해 보안 부팅 정책이나 암호화 키 관리를 위해 TPM 1.2 에 의존했던 시스템은 최신 버전의 systemd-boot에서도 이러한 기능을 계속 사용하려면 하드웨어 업그레이드(예: 마더보드 교체)가 필요하게 됩니다. 많은 Linux 데스크톱 사용자는 TPM과 보안 부팅 기능을 비활성화해 놓았기 때문에 이러한 변화를 알아차리지 못할 수도 있지만, 기업 환경이나 높은 수준의 보안이 요구되는 환경에서는 영향을 미칠 수 있습니다.

systemd 258과 같은 이전 릴리스에서는 이 분야에서 이미 상당한 조정이 이루어졌습니다. systemd-resolved와 systemd-importd는 OpenSSL만 지원하는 암호화 라이브러리로 지정하고 GnuTLS 및 libgcrypt와 같은 대안은 제외했습니다. 이 모든 것은 더 작고 통제된 암호화 도구 세트를 중심으로 통합하려는 움직임을 보여줍니다.

또한 258번 브랜치에서는 tty/pts에 대한 기본 접근 제한이 더욱 엄격해졌습니다 . 노드가 0620 권한 대신 0600 권한으로 생성되어 다른 사용자가 터미널에 쓰기 작업을 할 수 없게 되었습니다. 이는 systemd가 오랜 기간에 걸쳐 세부적인 저수준 설정을 조정해 온 또 다른 예이며, 이러한 조정 사항들이 결합되어 시스템의 전반적인 보안을 강화합니다.

libsystemd는 모듈화되어 있고 동적으로 로드됩니다.

시스템d 259는 효율성을 높이고 의존성 부하를 줄이기 위해 libsystemd가 다른 시스템 라이브러리와 상호 작용하는 방식 에 근본적인 변화를 도입했습니다 . 목표는 처음부터 모든 것을 가져오는 대신 필요할 때만 로드하는 것입니다.

구체적으로, libsystemd는 이제 dlopen() 함수를 사용하여 libacl, libblkid, libseccomp, libselinux, libmount와 같은 라이브러리를 동적으로 로드합니다 . 즉, 이러한 종속 라이브러리는 컴파일 시점에 엄격하게 링크되지 않으며 항상 메모리에 로드되어 있지도 않습니다. 특정 함수에서 필요로 할 때만 활성화됩니다.

`dlopen()` 함수와 동일한 메커니즘이 Linux 감사 하위 시스템 및 PAM과의 통합 에도 적용됩니다 . 이러한 방식으로, 이러한 구성 요소들이 동시에 필요하지 않은 환경에서는 systemd의 시작 및 정상 작동을 더 가볍게 할 수 있습니다.

반면에, 이전에 libcap 라이브러리가 제공했던 기능은 libsystemd에 직접 통합되었습니다 . 이로써 외부 종속성이 하나 더 제거되어 빌드 과정이 간소화되고 잠재적인 오류 발생 가능성이나 호환성 문제가 줄어듭니다.

일반적으로 이러한 접근 방식은 특히 빠른 부팅 시간과 밀집된 서비스 세트가 요구되는 시스템에서 더 나은 모듈성과 더 작은 메모리 및 디스크 공간을 제공합니다.

네트워크 및 컨테이너 변경 사항: iptables는 이제 안녕, nftables가 등장합니다

네트워킹 및 가상화 영역에서도 상당한 변화가 있습니다. systemd 259 버전부터 systemd-networkd와 systemd-nspawn은 더 이상 iptables/libiptc를 사용한 NAT 규칙 생성을 지원하지 않습니다 . 지원되는 유일한 방화벽 백엔드는 nftables입니다.

이는 iptables를 통한 NAT에 의존하는 systemd-nspawn으로 관리되는 컨테이너 와 기존 백엔드를 사용하는 주소 변환 규칙을 사용하는 systemd-networkd에 정의된 네트워크에 직접적인 영향을 미칩니다. 릴리스 후보 버전을 사용한 테스트에서 전체 구성을 nftables로 마이그레이션할 때까지 NAT 기능에 대한 오류가 조용히 발생하는 현상이 관찰되었습니다.

주소 번역을 넘어, systemd-resolved는 로컬 훅을 사용할 수 있는 기능을 얻었습니다. en /run/systemd/resolve.hook/이러한 명령은 로컬 이름 확인 쿼리가 수행될 때마다 실행됩니다. 이를 통해 관리자는 고급 DNS 사용자 지정 및 특정 로직을 구현할 수 있습니다.

이미지 가져오기 및 관리 분야에서, systemd-importd는 TAR 파일 작업을 위한 네이티브 로직을 통합합니다.또한, GNU tar 유틸리티의 libarchive 라이브러리를 사용합니다. 더 나아가 systemd-importd와 systemd-machined 모두 이제 사용자 모드에서 실행되어 시스템 이미지를 관리할 수 있습니다. ~/.local/state/machines/.

이러한 모드를 제어하기 위해 importctl 유틸리티는 "--user" 및 "--system" 옵션을 추가하여 사용자 컨텍스트에서 작업할지 시스템 수준에서 작업할지 쉽게 선택할 수 있도록 합니다. 이 접근 방식은 시스템의 전역 구성을 수정하지 않으려는 개발 및 테스트 환경에서 유용합니다.

기본적으로 영구 저널링 및 디스크 공간 관리

실질적인 영향을 미치는 또 다른 변화는 다음과 같은 수정 사항입니다. 기본 저널 저장 모드systemd의 로깅 하위 시스템입니다. 지금까지 "자동" 동작은 디렉터리의 존재 여부에 따라 달라졌습니다. /var/log/journal.

systemd 259 버전부터는 폴더의 기존 존재 여부와 관계없이 기본 모드가 "영구 저장 "으로 설정됩니다. 즉, 저널은 기본적으로 휘발성 RAM에 저장되는 대신 디스크에 영구적으로 저장됩니다.

이 결정에는 장단점이 있습니다. 한편으로는 관리자의 특별한 조치 없이도 로그가 재부팅 후에도 유지되므로 문제 해결이 크게 간소화됩니다 . 그러나 다른 한편으로는 임베디드 시스템, 경량 컨테이너 또는 저장 공간이 매우 제한적인 환경에서는 디스크 사용량이 크게 증가할 수 있습니다.

이러한 시나리오에서는 저널 순환 및 크기 정책을 조정하거나 , 과도한 마모를 방지하려면 (예: 쓰기 주기 제한이 있는 플래시 메모리의 경우) 다른 저장 모드를 강제로 적용하는 것이 그 어느 때보다 중요해집니다 .

systemd-oomd, OOM 추적 및 리소스 제어

메모리 관리 및 "메모리 부족" 시나리오도 크게 개선되었습니다. 메모리 부족 상황에 대응하는 systemd-oomd 구성 요소 에 새로운 속성이 추가되어 가시성이 향상되었습니다.

구체적으로, 이제 서비스에서 OOMKills 및 ManagedOOMKills 속성을 사용할 수 있습니다 . 이 속성은 커널 또는 systemd-oomd 자체에서 메모리 부족으로 인해 종료된 프로세스 수를 기록합니다. systemd 도구를 사용하여 이 정보에 직접 접근할 수 있으므로 이후 사고 분석이 용이해집니다.

프로세스가 제어 불능 상태가 되어 시스템에 심각한 위협이 될 정도로 RAM을 과도하게 사용 하기 시작하면 , 이러한 지표를 통해 어떤 장치가 영향을 받았는지, OOM(메모리 부족) 메커니즘이 몇 번 트리거되었는지, 그리고 어떤 구성 요소가 가장 큰 메모리 부하를 유발하는지 한눈에 확인할 수 있습니다.

부하가 높은 환경이나 리소스가 매우 부족한 시스템을 관리하는 관리자에게 있어, OOM(메모리 부족) 현상을 관찰 할 수 있는 이러한 향상된 기능은 특히 유용합니다. 이를 통해 이전에는 발견하지 못했을 수도 있는, 서비스 크기가 부적절하거나 메모리 누수를 식별하는 데 도움이 되기 때문입니다.

systemd 259의 기타 주목할 만한 개선 사항

위에서 언급한 주요 변경 사항 외에도 systemd 259에는 생태계 전반에 걸쳐 수많은 개선 사항과 사소한 수정 사항이 포함되어 있습니다 . 대부분은 다소 기술적인 내용이지만, 이러한 변경 사항들이 모두 합쳐져 상당한 변화를 가져오기 때문에 검토해 볼 가치가 있습니다.

API의 새로운 기능 중에는 다음과 같은 것들이 있습니다. Varlink 프로토콜 기반 인터페이스가 확장되고 있습니다. 서비스 구성에 대한 접근을 허용하고 IPC 호출을 실행합니다. Reload() y Reexecute()systemd-repart, systemd-resolved 및 systemd-networkd 기능을 처리하기 위한 특정 호출도 추가되었습니다.

설정 및 단위 영역에서 ExecReloadPost 옵션이 도입되어 서비스 설정이 다시 로드된 직후 명령을 실행할 수 있게 되었습니다. 또한, ".ignore"로 끝나는 설정 파일은 이제 자동으로 삭제됩니다. 이는 파일을 삭제하거나 이름을 크게 변경하지 않고도 간단하게 비활성화할 수 있는 방법입니다.

임시 부대가 소유권을 획득합니다 루트디렉토리파일디스크립터루트 디렉터리에 해당하는 파일 디스크립터를 정의하는 이 설정에 새로운 옵션이 추가되었습니다. 사용자 네임스페이스 경로이 기능을 사용하면 경로를 지정하여 드라이브를 사용자 네임스페이스에 연결할 수 있습니다. /procsystemd-nspawn에서 해당 지시문이 나타납니다. NamespacePath 섹션 .nspawn 파일에서 사용할 네트워크 네임스페이스를 지정합니다.

기타 구성 요소 등 systemd-sysext와 systemd-confext는 전용 구성 파일을 포함합니다. en /etc/systemd/systemd-sysext.conf y /etc/systemd/systemd-confext.conf환경 변수 SYSTEMD_SYSEXT_OVERLAYFS_MOUNT_OPTIONS y SYSTEMD_CONFEXT_OVERLAYFS_MOUNT_OPTIONS 이 기능을 사용하면 오버레이의 장착 옵션을 조정할 수 있습니다.

udev 환경에서는 해당 옵션이 추가됩니다. OPTIONS="dump-json"을 systemd-udevd에 입력 이벤트의 현재 상태를 JSON 형식으로 표시하려면 다음 함수를 사용하십시오. net_id 이 프로그램은 DeviceTree가 설치된 시스템의 무선 인터페이스에 대해 예측 가능한 이름을 생성하고 심볼릭 링크를 생성합니다. /dev/gpio/by-id/... GPIO 장치의 경우.

사용자 및 계정 섹션도 강화되고 있습니다. 사용자 데이터베이스에는 UUID 필드가 포함되어 있습니다.userdbctl 유틸리티는 이 식별자로 검색하기 위한 "-uuid" 옵션을 지원합니다. homectl update 이제 기존 계정에 복구 키를 추가하는 "--recovery-key" 옵션을 지원합니다.

systemd-homed에서 "--prompt-shell" 및 "--prompt-groups" 옵션은 systemd-homed-firstboot.service를 사용하여 첫 부팅 시에 통합되며 , systemd-firstboot에서 "--prompt-keymap-auto" 옵션은 첫 부팅 시 로컬 콘솔을 사용할 때 키보드 맵을 묻도록 되어 있습니다.

El systemd-boot 부트 관리자는 로그의 상세 수준을 정의할 수 있는 기능을 추가합니다. 매개 변수로 log-level en loader.conf 또는 SMBIOS 필드를 사용하여 io.systemd.boot.loglevel또한 XBOOTLDR과 같은 파티션에 대한 요구 사항이 더욱 엄격해지고 있으며, 이제 이러한 파티션은 최신 UEFI 시스템의 ESP에 요구되는 사항과 마찬가지로 VFAT 형식이어야 합니다.

고급 네트워킹 수준에서 systemd-networkd는 DHCP 서버에 EmitDomain 및 Domain 옵션을 추가하고 DNS 확인을 사용하여 DHCP를 통해 발급된 호스트 이름을 결정하는 컨트롤러를 구현합니다. 한편, systemd-modules-load는 커널 모듈을 병렬로 로드하여 드라이버가 많은 시스템의 부팅 시간을 단축합니다.

마지막으로, 무결성 섹션에서 systemd-integrity-setup은 HMAC-SHA256, PHMAC-SHA256 및 PHMAC-SHA512 알고리즘 지원을 추가하여 시스템 무결성을 보호하는 데 사용할 수 있는 암호화 옵션의 범위를 확장합니다.

이러한 모든 변화를 통해 systemd 259는 고도의 기술력과 높은 요구 사항을 갖춘, 미래 지향적인 버전 으로서의 입지를 더욱 공고히 합니다 . 이 버전은 SysV init, iptables, TPM 1.2와 같은 기존 기술을 버리도록 유도하고, 보안 및 리소스 제어를 강화하며, 내부 모듈성을 개선하고, musl을 사용한 새로운 구성(부분적이고 조건부적이긴 하지만)을 가능하게 합니다. 마이너 릴리스 배포판을 사용하는 최종 사용자에게는 이러한 새로운 기능들이 거의 눈에 띄지 않을 수 있지만, 최신 버전을 지속적으로 사용하는 관리자 및 프로젝트 담당자는 전환하기 전에 스크립트, 유닛, 하드웨어 요구 사항을 신중하게 검토해야 합니다.