Systemd 260: TPM2, 샌드박싱 및 Linux의 새로운 기능

하드웨어 가이드 » 구매 가이드 » Systemd 260: TPM2, 샌드박싱 및 Linux의 새로운 기능

도착과 함께 systemd 260 리눅스 배포판들이 클라우드 환경, 가상화 및 자동화에 최적화된 더욱 현대적이고 안전한 생태계를 향해 또 하나의 중요한 발걸음을 내딛고 있습니다. 이번 버전은 단순히 세부적인 부분을 다듬는 데 그치지 않고, 부팅, 서비스 관리, 네트워킹, 무결성 및 암호화를 위한 TPM2 사용, 드라이브 수준 샌드박싱 기능 등 여러 측면에서 중요한 변화를 가져왔습니다.

동시에, 프로젝트는 문서화 및 작업 방식을 강화합니다. 인공지능 에이전트이로써 systemd는 점점 더 많은 개발 및 관찰 도구가 연결되는 핵심 기반이 되고 있음이 분명해집니다. 서버, 클라우드, 회사 데스크톱 또는 연구실에서 Linux 시스템을 관리하는 경우, 이러한 새로운 기능들을 모두 검토하여 업데이트 및 구성 조정을 계획하는 것이 좋습니다.

System V와 네이티브 드라이브에 대한 완전한 의존 관계와 마침내 작별을 고합니다.

systemd 260에서 가장 눈에 띄는 변화 중 하나는 다음과 같습니다. System V 스크립트에 대한 지원을 완전히 중단합니다./etc/init.d를 기반으로 하는 기존 부팅 프로세스는 수년 동안 단계적으로 폐지되어 왔지만, 이제 systemd 코드에서 사실상 사라졌습니다.

이는 SysV 스크립트와 네이티브 유닛 간의 연결을 담당하는 구성 요소가 제거되었음을 의미합니다. systemd-rc-local-generator, rc-local.service, systemd-sysv-generator 및 systemd-sysv-install 이러한 기존 메커니즘은 더 이상 존재하지 않게 됩니다. 결과적으로, 이러한 기존 메커니즘에 여전히 의존하는 모든 서비스는 systemd 260을 채택한 시스템에서는 시작되지 않습니다.

정리 과정에서 Meson 빌드 옵션 중 일부가 더 이상 사용되지 않거나 제거된 것으로 표시되었습니다. -Drc-local=, -Dsysvinit-path= 및 -Dsysvrcnd-path= 어떤 것들은 기억의 상자 속에 묻혀버리지만, 또 어떤 것들은... -Dintegration-tests= 및 -Dcryptolib= 그것들은 바로 제거됩니다. 이는 모든 것이 네이티브 유닛과 최신 systemd 인프라를 거쳐야 한다는 분명한 메시지입니다.

여전히 구형 구성 요소에 의존하는 많은 유럽 인프라의 경우, 이러한 변화로 인해 내부 서비스, 사용자 지정 스크립트 및 기존 배포를 재검토해야 합니다. 잘 정의된 유닛 파일로 마이그레이션하는 것은 더 이상 권장 사항이 아니라, systemd 260을 통합하는 배포판에서 서비스를 계속 실행하려면 필수 사항입니다.

커널 요구 사항 강화 및 최신 환경에 대한 집중

새 버전은 커널의 기준을 한 단계 높였습니다. 이제부터는 지원되는 최소 Linux 버전은 5.10입니다.5.4와 같은 아주 오래된 가지들을 남겨두고. 또한, 이 프로젝트는 이상적인 작업 방식은 다음과 같다고 제시합니다. 커널 5.14 이상특히 다음을 추천합니다. 6.6 시리즈 사용 가능한 모든 기능을 활용하기 위해.

이러한 요구 사항 증가는 최신 배포판에서는 일반적으로 문제가 되지 않지만, 매우 보수적인 환경이나 오랫동안 유지 관리되어 온 임베디드 솔루션에서는 문제를 복잡하게 만들 수 있습니다. systemd 260으로 업그레이드하기 전에, 특히 다음과 같은 상황에서 현재 사용 중인 커널을 확인하는 것이 좋습니다. 장기 구축이 가능한 유럽 데이터 센터 또는 사용자 지정 이미지에서.

반대로, 최신 기능을 원하는 사용자들에게 매우 인기 있는 Arch Linux나 openSUSE Tumbleweed와 같은 롤링 릴리스 배포판은 새로운 커널과 systemd의 새로운 브랜치를 신속하게 통합하는 경향이 있습니다. 반면 Fedora와 같은 배포판은 각 릴리스의 수명 주기 동안 systemd의 주요 버전에서 어느 정도 안정성을 유지하여 마이그레이션을 계획할 시간을 좀 더 확보할 수 있습니다.

TPM2, 부팅 무결성 및 고급 SRK 지원

systemd가 가장 빠르게 발전하고 있는 분야 중 하나는 다음과의 통합입니다. TPM2(신뢰할 수 있는 플랫폼 모듈 2.0)이 칩은 최신 UEFI 마더보드와 중급 및 고급 하드웨어에서 점점 더 흔하게 사용되고 있으며, 시스템 상태에 비밀 정보를 연결하고 부팅 단계를 측정할 수 있도록 해줍니다. 암호화된 볼륨 잠금 해제 환경이 예상대로 되면 자동으로 작동합니다.

Systemd 260은 부팅 프로세스의 다양한 단계를 지원하는 도구와 서비스를 추가하여 이러한 통합을 더욱 강화합니다. 핵심 구성 요소는 다음과 같습니다... systemd-tpm2-설정주변 인프라를 준비하는 책임을 맡고 있습니다. 저장소 루트 키(SRK) TPM의 루트 키입니다. 이 루트 키는 칩과의 통신을 보호하고 다른 비밀 정보를 안전하게 저장하기 위한 암호화 기반 역할을 합니다.

시스템 시작 과정은 크게 두 단계로 나눌 수 있습니다. 첫 번째는 initrd에서, 두 번째는 루트 시스템에서 진행되는 초기 단계입니다. 초기 단계에서는 "Early TPM SRK Setup"이라는 서비스가 TPM에 SRK가 이미 저장되어 있는지 확인하고, 없으면 SRK를 생성하여 임시로 사용 가능하게 만듭니다. /run/systemd/tpm2-srk-public-key.*이후 실제 파일 시스템이 마운트되면 서비스는 SRK를 통합하고 저장된 키가 올바른지 확인합니다. /var/lib/systemd/tpm2-srk-public-key.pem 이는 TPM에 있는 내용과 일치합니다.

적절하게 구성된 시나리오에서는 이와 같은 저널 항목이 표시됩니다. "SRK는 이미 TPM에 저장되어 있습니다." 또한 SRK 풋프린트가 예상과 일치함을 나타내는 메시지가 표시됩니다. 그러나 환경이 일치하지 않는 경우(예: Yocto를 사용하는 설정이나 SPI TPM이 탑재된 Raspberry Pi 보드, U-Boot 및 측정 부팅과 같은 사용자 지정 부팅 방식을 사용하는 경우) systemd가 /var/lib/systemd 아래에 이러한 파일을 생성하지 못하여 SRK가 올바르게 구성되었는지에 대한 의문이 생길 수 있습니다.

TPM 상태가 변경되었거나, 파티션이 수정되었거나, 부팅 흐름이 변경된 경우 관련 정책이 더 이상 적용되지 않을 수 있습니다. 이러한 경우 일부 관리자는 다음과 같은 조치를 권장합니다. TPM 슬롯 또는 정책을 지우고 키를 다시 등록하십시오.openSUSE와 같은 환경에서 TPM을 사용하는 디스크 암호화 가이드에 설명된 것과 유사한 절차를 따르면 PCR 정책을 다시 생성하고 볼륨 잠금 해제를 다시 연결하는 방법을 자세히 알 수 있습니다.

SRK 외에도 또 다른 실질적인 개선 사항은 udev에 내부 유틸리티가 도입된 것입니다. tpm2_id이 통합 도구는 시스템이 TPM2 장치를 감지하면 실행됩니다. 이 기능은 제조업체 식별자와 모델명을 자동으로 추출합니다.이는 보안 하드웨어 재고 관리를 간소화하여, 어떤 TPM 모듈이 배포되었는지 정확히 파악해야 하는 공공기관, 규제 대상 기업 또는 중요 인프라 시설에서 매우 유용합니다.

스타트업 측정 인프라와의 통합은 다음과 같은 특정 장치를 통해 더욱 강화됩니다. systemd-pcrextend이러한 확장 기능은 "enter-initrd", "leave-initrd", "sysinit" 또는 "ready"와 같은 이벤트를 서로 다른 PCR(예: PCR 11)에 기록합니다. 이러한 일련의 확장을 통해 TPM은 부팅 흐름에 대한 암호학적으로 검증 가능한 기록을 축적할 수 있으며, 이는 신뢰 부팅 정책 또는 기타 용도로 사용될 수 있습니다. UKI(통합 커널 이미지) 키를 발급하기 전에 기기의 상태를 확인하는 절차입니다.

systemd를 이용한 서비스 보안 조치 및 샌드박싱

Systemd는 프로세스를 시작하는 기능뿐만 아니라 매우 광범위한 기능 세트도 제공합니다. 샌드박싱 지침 침해 발생 시 서비스를 격리하고 피해를 최소화하기 위한 것입니다. 이러한 "심층 방어" 접근 방식은 cgroups, 네임스페이스, 커널 기능 및 시스템 호출 필터(seccomp)에 의존합니다.

systemd는 특정 서비스의 상태를 평가하기 위한 도구를 제공합니다. systemd-보안 분석이 도구를 실행하면 0에서 10까지의 노출 지수가 포함된 보고서가 생성되며, 지수가 낮을수록 좋습니다. 보고서는 활성화되었거나 활성화되지 않은 보호 기능(네트워크 격리, 파일 시스템 액세스, 장치 등)을 자세히 보여주므로 취약점을 쉽게 파악할 수 있습니다. 어떤 조정이 필요합니까? 그리고 도입된 변경 사항이 실제로 점수를 향상시키는지 확인합니다.

원본 유닛을 편집하는 대신(원본 유닛은 향후 패키지 업데이트 시 손실될 수 있음) 새 유닛을 생성하는 것이 좋습니다. 보수 en /etc/systemd/system/mi-servicio.service.d/ 예를 들어 파일을 이용하면, sandbox.conf수정 후에는 다음 명령으로 설정을 다시 로드하기만 하면 됩니다. systemctl 데몬 -reload 새로운 제한 사항이 적용되도록 서비스를 다시 시작하십시오.

파일 시스템 수준에서 가장 중요한 옵션 중 하나는 다음과 같습니다. 프로텍트시스템=값들(예: ...) strict, full o true 그들은 트리의 여러 부분을 읽기 전용 모드로 마운트합니다. 가능한 경우 일반적으로 사용하는 방법은 다음과 같습니다. ProtectSystem=strict이렇게 하면 /usr, /boot, /efi 및 /etc 디렉터리가 해당 서비스에 대해 읽기 전용이 됩니다. 애플리케이션이 특정 디렉터리에 쓰기 작업을 해야 하는 경우, 별도의 명령을 사용하여 허용됩니다. ReadWritePaths=/path 단결.

개인 정보 보호를 더욱 강화하기 위해 사용자 디렉터리에 대한 접근을 제한하는 것도 권장됩니다. ProtectHome=true이는 서비스가 /home, /root 또는 /run/user를 읽는 것을 방지합니다. 또한, PrivateTmp=true 이는 격리된 /tmp 및 /var/tmp 공간을 생성하여 프로세스 간 임시 파일의 상호 접근을 방지합니다.

기기에서, PrivateDevices=true 이 명령어는 실제 /dev 트리를 숨기고 안전한 최소한의 가상 장치(null, 0, 임의 등) 집합으로 대체합니다. 장치가 특정 장치(예: 직렬 포트 또는 디스크 블록)를 필요로 하는 경우, 해당 장치를 다음과 같이 할당할 수 있습니다. DeviceAllow=/dev/xxx rw 또는 읽기 전용 모드.

네트워크 또한 핵심적인 매개체입니다. PrivateNetwork=true 격리된 네트워크 네임스페이스가 생성되고 루프백 인터페이스만 남게 됩니다. 서비스는 물리적 인터페이스를 볼 수 없으며 외부와 통신할 수 없습니다. 또는 서비스가 사용할 수 있는 주소 패밀리를 제한할 수도 있습니다. RestrictAddressFamilies=IPv4/IPv6에는 AF_INET 및 AF_INET6만 허용하고, 로컬 소켓에는 AF_UNIX를 허용하거나 그 외의 경우에도 허용합니다. none 네트워크 기능을 완전히 일본식으로 만들기 위해.

특권과 관련하여, 지침은 다음과 같습니다. NoNewPrivileges=true 이는 가장 강력한 보안 방식 중 하나로, setuid 바이너리나 기능 변경을 통해 프로세스가 새로운 권한을 획득하는 것을 방지합니다. 즉, 서비스가 취약한 코드를 실행하더라도 기존 방식으로는 루트 권한으로 상승할 수 없게 됩니다. 이러한 보안 방식은 다음과 결합될 때 더욱 효과적입니다. CapabilityBoundingSet=허용되는 기능 목록을 정확하게 정의함으로써(예: 낮은 포트에서 수신 대기하는 CAP_NET_BIND_SERVICE만 허용) 공격 표면을 최소화할 수 있습니다.

더 나아가 systemd는 시스템 호출을 필터링할 수 있도록 해줍니다. 시스템콜필터=수동으로 시스템 호출 목록을 관리하는 대신, 다음과 같은 미리 정의된 그룹이 사용됩니다. @system-service, @network-io, @basic-io 또는 다음과 같은 그룹을 거부합니다 ~@privileged. 과 systemd-analyze syscall-filter 어떤 특정 호출이 각 그룹에 속하는지 검사할 수 있습니다. 이를 통해 전용 샌드박스에서 제공하는 것과 유사한 매우 제한적인 실행 프로파일을 구축할 수 있습니다.

기타 관련 조정 사항은 다음과 같습니다. ProtectKernelTunables=true이는 /proc/sys 및 /sys에서 커널 매개변수 수정을 차단합니다. ProtectKernelModules=true모듈의 적재 또는 하역을 방지하는 기능입니다. ProtectKernelLogs=true이는 커널 레지스터 읽기를 방지합니다. ProtectControlGroups=true이는 cgroups 계층 구조에 대한 쓰기를 차단합니다. 이 모든 것은 다음과 같은 새로운 사용자 격리 기능과 완벽하게 결합됩니다. PrivateUsers=전체버전 260에서는 전체 사용자 ID 범위를 매핑하도록 업데이트되어 중첩된 systemd가 있는 환경에서 필요했던 이전의 해결 방법이 사라졌습니다.

PrivateUsers, xaccess 및 새로운 장치 접근 제어

메커니즘 개인 사용자격리된 사용자 ID 공간에서 서비스를 실행하도록 설계되었으며 systemd 260에 통합되었습니다. PrivateUsers=전체 이제 모든 식별자 범위를 매핑하여 컨테이너 환경이나 이전 버전(257 이전)을 기반으로 하는 중첩된 systemd 인스턴스가 있는 시스템에서 작업이 간소화되었습니다. 이러한 개선으로 이전 버전을 감지하기 위해 사용되었던 편법이 더 이상 필요하지 않게 되었습니다.

이와 동시에 다음과 같은 구성 요소들이 있습니다. systemd-logind 및 systemd-udevd 그들은 다음과 같은 개념을 도입하고 있습니다. xaccess이 메커니즘은 고전 논리를 보완합니다. uaccessxaccess는 로컬 컴퓨터에서 포그라운드 그래픽 세션을 실행 중인 사용자에게 특정 장치(예: 오디오 또는 비디오)에 대한 액세스 권한을 부여합니다. 권한은 xaccess로 위임할 수 있습니다. 특별히 표시된 세션을 사용하는 원격 사용자예를 들어 원격 데스크톱을 통해 연결된 사용자가 시스템 전체에 광범위한 권한을 부여하지 않고도 로컬 GPU 렌더링 장치에 액세스할 수 있도록 합니다.

이러한 세션의 구성에는 PAM을 통해 노출되는 환경 변수가 포함됩니다. 특히, PAMXDG_SESSION_EXTRA_DEVICE_ACCESS=이를 통해 어떤 특정 장치가 이 프레임워크에 해당하는지 정의할 수 있습니다. 이는 민감한 하드웨어에 대한 접근에 있어 세분화된 관리와 추적성을 요구하는 유럽 연합의 규제 준수 및 데이터 보호 요건과 매우 부합하는 접근 방식입니다.

mstack, systemd-mstack 및 새로운 컨테이너 도구

컨테이너화 분야에서 systemd 260은 다음과 같은 기능을 도입합니다. mstack 그리고 관련 명령어가 있습니다. systemd-mstackmstack의 기본 아이디어는 정의를 허용하는 것입니다. 오버레이FS 특정 디렉토리의 구조를 기반으로 합니다. .mstack/이는 계층 구조를 구성하는 특정 사양을 따릅니다.

새로운 명령줄 도구인 systemd-mstack을 사용하면 이러한 파일 시스템 "스택"을 대화형으로 더 쉽게 다룰 수 있어 컨테이너 또는 고도로 격리된 서비스를 위한 계층형 환경을 설정할 때 유연성이 향상됩니다. 이 기능은 또한 다음과 같은 개선 사항과도 연관되어 있습니다. systemd-import이는 지원을 확대하는 것입니다. OCI 이미지 다운로드 및 관리이는 systemd가 컨테이너화 및 샌드박싱 엔진으로서의 역할을 강화하는 것으로, 유럽의 클라우드 제공업체와 최신 호스팅 플랫폼에서 매우 흔하게 볼 수 있는 기능입니다.

네트워크: ModemManager와의 통합 및 새로운 성능 옵션

네트워크 계층에서 systemd-networkd는 계속해서 중요성이 커지고 있습니다. systemd-networkd의 주목할 만한 새로운 기능 중 하나는 다음과 같습니다. "심플 커넥트" 프로토콜을 사용한 ModemManager와의 통합이를 통해 외부 도구에 의존하지 않고 networkd에서 모뎀과 모바일 연결을 직접 관리할 수 있습니다.

이러한 흐름을 원활하게 하기 위해 새로운 섹션이 추가됩니다. 다음과 같은 매개변수를 사용하여 구성 파일에 추가합니다. APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=이는 배포를 용이하게 합니다. 농촌 지역 또는 모바일 네트워크 기반 연결 환경을 갖춘 지역유럽의 특정 지역, 특히 광섬유망이나 양질의 유선 전화망이 항상 갖춰져 있지 않은 지역에서 매우 흔하게 사용됩니다.

성능 측면에서 볼 때, 해당 파일들은 .링크 systemd-networkd에는 이더넷 장치를 위한 새로운 옵션이 포함되어 있습니다. 그중 일부는 다음과 같습니다. ScatterGather, ScatterGatherFragmentList, TCPECNSegmentationOffload, TCPMangleIdSegmentationOffload, GenericReceiveOffloadList 및 GenericReceiveOffloadUDPForwarding이러한 옵션을 통해 하드웨어 및 드라이버로의 작업 분담을 세밀하게 조정할 수 있으며, 이는 지연 시간을 1밀리초라도 최소화해야 하는 기업 네트워크, 데이터 센터 및 서비스 제공업체에 매우 중요합니다.

또한 인터페이스는 Varlink와 JSON systemd-networkd는 이제 IP 주소를 특정 형식으로 보고할 수 있습니다. 사람이 읽을 수 있는 문자열을 정수 배열 형태로 유지하면서 변환할 수 있습니다. 이를 통해 직관적이지 않은 숫자 형식을 다루지 않아도 되는 모니터링 대시보드, 관리 스크립트 또는 타사 도구와의 통합이 간소화됩니다.

서비스 이식성, 임시 가상 머신 및 비특권 서비스

그 조각 systemd-portabled이미지 패키지에 담긴 "이식 가능한" 서비스를 관리하는 소프트웨어가 매우 흥미로운 기능을 갖게 되었습니다. 바로 실행할 수 있게 된 것입니다. 사용자 수준 서비스로서이는 권한이 없는 사용자도 일반 세션에서 sudo나 관리자 권한 없이 자신의 공간 내에서 휴대용 서비스를 실행하고 관리할 수 있음을 의미합니다.

또한, 이번 버전부터 휴대용 캔 정책을 생성하고 휴대용 서비스와 관련된 이미지를 설정합니다.이렇게 하면 이미지를 다시 첨부하지 않고는 수정할 수 없습니다. 따라서 사용자는 변경 불가능성이 강화된 자체 포함 환경을 구축할 수 있으며, 이는 연구실, 개발 환경 및 테스트 샌드박스에 매우 유용합니다.

또한, systemd-vmspawn —systemd와 통합된 방식으로 가상 머신을 실행하도록 설계된 도구—는 등록 기능을 확장합니다. 사용자 세션 내의 systemd-machined또한 하나의 옵션을 도입합니다. –덧없는 사용 후 파괴되는 임시적인 시스템을 구축하는 것입니다. 이는 CI/CD 파이프라인, 가상 교실 또는 유럽 교육 플랫폼과 같이 임시적인 시스템이 필요한 환경에 완벽하게 부합합니다. 기계를 빠르고 정확하게 들어 올리고 당기기.

SCHED_EXT 및 THP를 사용하여 CPU, 메모리 및 스케줄링을 세밀하게 제어합니다.

Systemd 260은 새로운 정책을 통해 성능 제어에 대해서도 자세히 다룹니다. 서비스 옵션은 다음과 같습니다. CPU 스케줄링 정책= 이제 값을 받아들이세요 ext스케줄러를 활성화합니다. SCHED_EXT이 대안적 계획법은 다음과 같은 가능성을 열어줍니다. 다양한 계획 정책을 사용한 실험 커널 표준과 관련된 내용인데, 이는 연구 개발 연구소나 고도로 전문화된 배포 환경에서나 관심을 가질 만한 사항입니다.

메모리 영역에 나타납니다 메모리THP=이를 통해 사용을 관리할 수 있습니다. 투명 대용량 페이지(THP) 서비스별로 설정할 수 있습니다. 시스템 전체에 대한 전역적인 동작 방식을 사용하는 대신, 특정 서비스에서 THP를 활용할지, 비활성화할지, 또는 중간 모드를 채택할지 결정할 수 있습니다. 은행, 보험 또는 공공 행정 분야의 중요 애플리케이션의 경우, 이러한 세분화된 제어는 큰 차이를 만들어낼 수 있습니다. 지연 시간, 메모리 사용량 및 성능.

systemctl에 새로운 명령어가 추가되었고 Varlink의 사용 범위가 확장되었습니다.

잘 알려진 특공대원 systemctl 새로운 질서를 획득합니다: 대기열 표시됨이 동작은 내부적으로 D-Bus 메서드를 호출합니다. EnqueueMarkedJobs() 또한 미리 선택된 작업 및 서비스 대기열을 사용하여 작업할 수 있습니다. 이는 사소한 세부 사항처럼 보일 수 있지만, 운영 팀이 작업을 조율하는 데 있어 매우 중요합니다. 대규모 서버 팜 이는 배포 및 자동화 워크플로우를 개선하는 또 다른 도구입니다.

이와 동시에, 프로젝트는 활용 범위를 지속적으로 확대하고 있습니다. 바르링크 시스템d는 구성 요소 간의 통신 메커니즘으로 사용됩니다. systemd의 많은 부분은 안정적인 Varlink 인터페이스를 제공하여 시스템 정보에 대한 구조화된 접근이 필요한 외부 도구, 사용자 지정 대시보드 또는 모니터링 에이전트와의 통합을 용이하게 합니다.

시스템 식별 필드 및 사용자 경험

일부 배포판에서 새롭게 추가된 흥미로운 기능 중 하나는 필드의 도입입니다. FANCY_NAME= 아카이브에서 /etc/os-release이 필드는 PRETTY_NAME과 유사하지만, 다음과 같은 기능을 허용합니다. ANSI 시퀀스 및 더욱 정교한 유니코드 문자덕분에 특정 배포판 및 에디션에 더욱 눈길을 사로잡거나 차별화된 이름을 붙일 수 있습니다.

FANCY_NAME의 값은 systemd 관리자를 통해 확인할 수 있습니다. systemd-호스트네임드 또는 상담할 때 hostnamectl작은 변화이긴 하지만, 데스크톱 환경이나 그래픽 관리자 패널에서는 유용할 수 있습니다. 시스템을 한눈에 파악하세요 특히 파생 변종이 많은 경우 관리가 중요합니다.

AI 에이전트 및 지원 검토 워크플로에 대한 구체적인 문서

systemd 개발의 방향을 보여주는 가장 흥미로운 징후 중 하나는 특정 사용자층을 겨냥한 문서들이 등장하고 있다는 점입니다. 인공지능 에이전트저장소에 파일이 포함되어 있습니다. 에이전트.md코드 분석 도구 및 프로그래밍 도우미를 위해 설계되었으며, 일부에서 지적했듯이 기술 가이드프로젝트의 아키텍처, 스타일, 개발 흐름 및 기여 지침을 더 잘 이해할 수 있습니다.

이 문서에서는 구성 요소, 빌드 경로, 테스트 및 통합 실행 방법, 그리고 허용 가능한 패치 생성 지침을 설명합니다. 이 문서의 목적은 코드 검토 또는 변경 사항 생성을 담당하는 AI 에이전트가 이를 기반으로 작동하도록 하는 것입니다. systemd가 어떻게 구성되어 있는지에 대한 확실한 맥락오류 및 잘못된 제안을 줄입니다.

AGENTS.md 옆에는 라는 파일이 있습니다. 클로드.md이는 첫 번째 사례를 명시적으로 참조하며, 가장 널리 사용되는 AI 기반 개발 도우미 중 하나인 Claude Code 도구를 활용하는 데 중점을 둡니다. 이러한 방식으로 프로젝트는 개발 주기 내에 AI를 명시적으로 통합합니다.

또한, 설정 파일이 포함되어 있습니다. 클로드 리뷰.yml여기서는 클로드 코드(Claude Code)를 활용하여 변경 요청(풀 리퀘스트) 분석 프로세스를 검토하는 방법을 정의합니다. 이와 관련하여 AI를 활용한 기여는 반드시 포함되어야 합니다. 정보 공개 라벨 으로 Co-developed-by 패치에서 자동화 도구가 코드 생성에 관여했다는 증거가 발견되었습니다.

이러한 모든 변화들, 즉 기존 지원 정리, 샌드박싱 개선, TPM2 및 SRK 개선, 고급 네트워크 통합, 새로운 이식성 기능, 그리고 지능형 에이전트를 위해 설계된 문서화 등을 통해 systemd 260 이는 현대 리눅스 생태계에서 커널의 핵심적인 역할을 더욱 강화합니다. 스페인과 유럽의 시스템 관리자 및 개발자에게 있어 당면 과제는 커널을 검토하고, 부팅 구성 및 서비스를 조정하며, 이러한 기능을 활용하여 현재 시스템 사용 패턴에 맞춘 더욱 안전하고 자동화된 인프라를 구축하는 것입니다.