Linux에는 다양한 얼굴이 있습니다. 모든 배포판에서 작업하는 방법

모든 배포에서 작동하는 백업 애플리케이션을 만드는 것은 쉬운 작업이 아닙니다. Veeam Agent for Linux가 Red Hat 6 및 Debian 6부터 OpenSUSE 15.1 및 Ubuntu 19.04까지의 배포판에서 작동하도록 하려면 특히 소프트웨어 제품에 커널 모듈이 포함되어 있다는 점을 고려하여 다양한 문제를 해결해야 합니다.

이 기사는 컨퍼런스에서 발표한 자료를 바탕으로 작성되었습니다. 리눅스 피터 2019.

Linux는 단지 가장 인기 있는 운영 체제 중 하나가 아닙니다. 본질적으로 이것은 당신이 뭔가 독특하고 자신만의 것을 만들 수 있는 기반이 되는 플랫폼입니다. 덕분에 Linux에는 소프트웨어 구성 요소 세트가 다른 많은 배포판이 있습니다. 그리고 여기서 문제가 발생합니다. 소프트웨어 제품이 어떤 배포판에서든 작동하려면 각 기능을 고려해야 합니다.

패키지 관리자. .deb 대 .rpm

다양한 배포판에 제품을 배포하는 명백한 문제부터 시작해 보겠습니다.
소프트웨어 제품을 배포하는 가장 일반적인 방법은 패키지를 저장소에 저장하여 시스템에 내장된 패키지 관리자가 저장소에서 설치할 수 있도록 하는 것입니다.
그러나 널리 사용되는 두 가지 패키지 형식이 있습니다. RPM и 뎁. 이는 모두가 지원해야 함을 의미합니다.

deb 패키지의 세계에서는 호환성 수준이 놀랍습니다. 동일한 패키지가 Debian 6과 Ubuntu 19.04 모두에 동일하게 설치되고 작동합니다. 기존 데비안 배포판에 규정된 패키지 구축 및 작업 프로세스에 대한 표준은 새로운 Linux Mint 및 기본 OS와 관련이 있습니다. 따라서 Veeam Agent for Linux의 경우 각 하드웨어 플랫폼당 하나의 deb 패키지로 충분합니다.

그러나 rpm 패키지의 세계에서는 차이점이 큽니다. 첫째, Red Hat과 SUSE라는 두 개의 완전히 독립적인 배포자가 있기 때문에 호환성이 전혀 필요하지 않습니다. 둘째, 이러한 유통업체는 해당 유통업체의 배포 키트를 보유하고 있습니다. 지원하고 실험적입니다. 그들 사이의 호환성도 필요하지 않습니다. el6, el7 및 el8에는 자체 패키지가 있는 것으로 나타났습니다. Fedora용 별도 패키지. SLES11 및 12용 패키지와 openSUSE용 별도 패키지입니다. 주요 문제는 종속성과 패키지 이름입니다.

의존성 문제

불행하게도 동일한 패키지가 다른 배포판에서 다른 이름으로 끝나는 경우가 많습니다. 다음은 Veeam 패키지 종속성의 일부 목록입니다.

EL7의 경우:
SLES 12의 경우:

• libblkid
• libgcc
• libstdc++
• ncurses-libs
• 퓨즈 라이브러리
• 파일 라이브러리
• veeamsnap=3.0.2.1185

• libblkid1
• libgcc_s1
• 된 libstdc ++ 6
• libmagic1
• libfuse2
• veeamsnap-kmp=3.0.2.1185

결과적으로 종속성 목록은 배포에 대해 고유합니다.

더 나쁜 것은 업데이트된 버전이 이전 패키지 이름 아래에 숨겨지기 시작할 때입니다.

예 :

패키지가 Fedora 24에서 업데이트되었습니다. 저주를 받다 버전 5에서 버전 6으로. 당사 제품은 이전 배포판과의 호환성을 보장하기 위해 버전 5로 제작되었습니다. Fedora 5에서 이전 24번째 버전의 라이브러리를 사용하려면 다음 패키지를 사용해야 했습니다. ncurses-compat-libs.

결과적으로 Fedora에는 종속성이 다른 두 가지 패키지가 있습니다.

더욱 더 흥미롭습니다. 다음 배포 업데이트 이후 패키지는 ncurses-compat-libs 라이브러리 버전 5에서는 사용할 수 없는 것으로 나타났습니다. 배포자가 오래된 라이브러리를 새 버전의 배포판으로 끌어들이는 것은 비용이 많이 듭니다. 얼마 후 SUSE 배포판에서 문제가 반복되었습니다.

결과적으로 일부 배포판은 다음에 대한 명시적인 종속성을 삭제해야 했습니다. ncurses-libs, 모든 버전의 라이브러리에서 작동할 수 있도록 제품을 수정합니다.

그런데 Red Hat 버전 8에는 더 이상 메타 패키지가 없습니다. 파이썬, 이는 좋은 옛적을 가리킨다. 파이썬 2.7. 있다 python2 и 파이썬3.

패키지 관리자의 대안

종속성 문제는 오래되었으며 오랫동안 명백했습니다. 의존성 지옥을 기억하세요.
다양한 라이브러리와 애플리케이션을 결합하여 모두 안정적으로 작동하고 충돌하지 않도록 하는 것은 실제로 모든 Linux 배포자가 해결하려고 하는 작업입니다.

패키지 관리자는 완전히 다른 방식으로 이 문제를 해결하려고 합니다. 팔팔한 캐노니컬에서. 주요 아이디어: 애플리케이션은 메인 시스템으로부터 격리되고 보호되는 샌드박스에서 실행됩니다. 애플리케이션에 라이브러리가 필요한 경우 해당 라이브러리는 애플리케이션 자체와 함께 제공됩니다.

플랫 팩 또한 Linux 컨테이너를 사용하여 샌드박스에서 애플리케이션을 실행할 수도 있습니다. 샌드박스 아이디어도 사용됩니다. AppImage.

이러한 솔루션을 사용하면 모든 배포에 대해 하나의 패키지를 만들 수 있습니다. 다음의 경우 플랫 팩 관리자가 알지 못하는 사이에도 애플리케이션의 설치 및 실행이 가능합니다.

가장 큰 문제는 모든 응용 프로그램이 샌드박스에서 실행될 수 없다는 것입니다. 어떤 사람들은 플랫폼에 직접 액세스해야 합니다. 나는 커널에 엄격하게 의존하고 샌드박스 개념에 맞지 않는 커널 모듈에 대해 말하는 것이 아닙니다.

두 번째 문제는 Red Hat 및 SUSE의 기업 환경에서 널리 사용되는 배포판에는 아직 Snappy 및 Flatpak에 대한 지원이 포함되어 있지 않다는 것입니다.

이와 관련하여 Linux용 Veeam Agent는 사용할 수 없습니다. snapcraft.io 별말씀을요 플랫허브.org.

패키지 관리자에 대한 질문을 마무리하기 위해 바이너리 파일과 이를 하나의 패키지에 설치하기 위한 스크립트를 결합하여 패키지 관리자를 완전히 버릴 수 있는 옵션이 있다는 점에 주목하고 싶습니다.

이러한 번들을 사용하면 다양한 배포판과 플랫폼에 대한 하나의 공통 패키지를 만들고, 대화형 설치 프로세스를 수행하고, 필요한 사용자 정의를 수행할 수 있습니다. 저는 VMware의 Linux용 패키지만 접했습니다.

업데이트 문제

모든 종속성 문제가 해결되더라도 동일한 배포판에서 프로그램이 다르게 실행될 수 있습니다. 업데이트의 문제입니다.

업데이트 전략에는 3가지가 있습니다.

• 가장 간단한 방법은 업데이트하지 않는 것입니다. 서버를 설정하고 잊어버렸어요. 모든 것이 작동한다면 업데이트하는 이유는 무엇입니까? 문제는 지원팀에 처음 문의할 때부터 시작됩니다. 배포판 작성자는 업데이트된 릴리스만 지원합니다.
• 배포자를 신뢰하고 자동 업데이트를 설정할 수 있습니다. 이 경우 업데이트가 실패한 직후 지원 요청이 발생할 가능성이 높습니다.
• 테스트 인프라에서 실행한 후에만 수동으로 업데이트하는 옵션은 가장 안정적이지만 비용이 많이 들고 시간이 많이 걸립니다. 모든 사람이 그것을 감당할 수 있는 것은 아닙니다.

사용자마다 다른 업데이트 전략을 사용하므로 최신 릴리스와 이전에 릴리스된 모든 릴리스를 모두 지원해야 합니다. 이는 개발 및 테스트 프로세스를 모두 복잡하게 만들고 지원 팀에 골치 아픈 일을 가중시킵니다.

다양한 하드웨어 플랫폼

다양한 하드웨어 플랫폼은 주로 네이티브 코드와 관련된 문제입니다. 최소한 지원되는 각 플랫폼에 대한 바이너리를 수집해야 합니다.

Veeam Agent for Linux 프로젝트에서는 여전히 이 RISC와 같은 것을 지원할 수 없습니다.

이 문제에 대해서는 자세히 다루지 않겠습니다. 나는 단지 주요 문제들에 대해서만 설명할 것입니다: 플랫폼에 의존하는 유형들, size_t, 구조 정렬 및 바이트 순서.

정적 및/또는 동적 연결

그러나 문제는 "라이브러리와 어떻게 연결합니까 - 동적으로 또는 정적으로?"입니다. 논의할 가치가 있습니다.

일반적으로 Linux의 C/C++ 애플리케이션은 동적 연결을 사용합니다. 이는 애플리케이션이 특정 배포용으로 특별히 제작된 경우 효과적입니다.

작업이 하나의 바이너리 파일로 다양한 배포판을 다루는 것이라면 지원되는 가장 오래된 배포판에 집중해야 합니다. 우리에게 이것은 Red Hat 6입니다. 여기에는 C++4.4 표준에서도 지원하지 않는 gcc 11가 포함되어 있습니다. 충분히.

우리는 C++6.3를 완벽하게 지원하는 gcc 14을 사용하여 프로젝트를 빌드합니다. 당연히 이 경우 Red Hat 6에서는 libstdc++ 및 Boost 라이브러리를 휴대해야 합니다. 가장 쉬운 방법은 정적으로 연결하는 것입니다.

하지만 안타깝게도 모든 라이브러리를 정적으로 링크할 수 있는 것은 아닙니다.

첫째, 다음과 같은 시스템 라이브러리 libfuse, libblkid 커널 및 해당 모듈과의 호환성을 보장하려면 동적으로 링크해야 합니다.

둘째, 라이센스에는 미묘함이 있습니다.

GPL 라이선스를 사용하면 기본적으로 오픈소스 코드로만 라이브러리를 연결할 수 있습니다. MIT와 BSD는 정적 링크를 허용하고 라이브러리가 프로젝트에 포함될 수 있도록 합니다. 그러나 LGPL은 정적 링크와 모순되지 않는 것으로 보이지만 링크에 필요한 파일을 공유하도록 요구합니다.

일반적으로 동적 연결을 사용하면 아무것도 제공할 필요가 없습니다.

C/C++ 애플리케이션 구축

다양한 플랫폼과 배포판을 위한 C/C++ 애플리케이션을 구축하려면 적절한 gcc 버전을 선택하거나 구축하고 특정 아키텍처에 대한 크로스 컴파일러를 사용하고 전체 라이브러리 세트를 어셈블하는 것으로 충분합니다. 이 작업은 실현 가능하지만 상당히 번거롭습니다. 그리고 선택한 컴파일러와 라이브러리가 실행 가능한 버전을 제공한다는 보장도 없습니다.

분명한 이점은 전체 빌드 프로세스가 하나의 시스템에서 완료될 수 있기 때문에 인프라가 크게 단순화된다는 것입니다. 또한 하나의 아키텍처에 대해 하나의 바이너리 세트를 수집하는 것으로 충분하며 이를 다양한 배포용 패키지로 패키징할 수 있습니다. 이것이 Veeam Agent for Linux용으로 veeam 패키지가 구축되는 방식입니다.

이 옵션과 달리 빌드 팜, 즉 조립을 위한 여러 기계를 간단히 준비할 수 있습니다. 이러한 각 머신은 특정 배포판 및 특정 아키텍처에 대한 애플리케이션 컴파일 및 패키지 어셈블리를 제공합니다. 이 경우 편집은 배포자가 준비한 수단을 사용하여 수행됩니다. 즉, 컴파일러를 준비하고 라이브러리를 선택하는 단계가 생략됩니다. 또한 빌드 프로세스를 쉽게 병렬화할 수 있습니다.

그러나 이 접근 방식에는 단점이 있습니다. 동일한 아키텍처 내의 각 배포에 대해 자체 바이너리 파일 세트를 수집해야 합니다. 또 다른 단점은 이렇게 많은 수의 머신을 유지 관리해야 하고 많은 양의 디스크 공간과 RAM을 할당해야 한다는 것입니다.

이는 veeamsnap 커널 모듈의 KMOD 패키지가 Red Hat 배포판용으로 컴파일되는 방식입니다.

오픈 빌드 서비스

SUSE의 동료들은 애플리케이션 컴파일 및 패키지 조립을 위한 특별 서비스 형태로 중간 지점을 구현하려고 했습니다. 오픈빌드 서비스.

기본적으로 가상 머신을 생성하고, 필요한 모든 패키지를 설치하고, 애플리케이션을 컴파일하고, 이 격리된 환경에서 패키지를 빌드한 후 가상 머신을 릴리스하는 것은 하이퍼바이저입니다.

OpenBuildService에 구현된 스케줄러는 최적의 패키지 구축 속도를 위해 실행할 수 있는 가상 머신 수를 결정합니다. 내장된 서명 메커니즘은 패키지에 서명하고 내장된 저장소에 업로드합니다. 내장된 버전 관리 시스템은 변경 및 빌드 기록을 저장합니다. 이제 남은 것은 소스를 이 시스템에 추가하는 것뿐입니다. 서버를 직접 설정할 필요도 없으며 공개 서버를 사용할 수도 있습니다.

그러나 문제가 있습니다. 이러한 수확기는 기존 인프라에 적합하기 어렵습니다. 예를 들어, 버전 관리는 필요하지 않습니다. 우리는 이미 소스 코드에 대한 자체 버전을 갖고 있습니다. 우리의 서명 메커니즘은 다릅니다: 우리는 특별한 서버를 사용합니다. 저장소도 필요하지 않습니다.

또한 Red Hat과 같은 다른 배포판에 대한 지원은 다소 제대로 구현되지 않았으며 이는 이해할 수 있습니다.

이러한 서비스의 장점은 SUSE 배포판의 다음 버전을 빠르게 지원한다는 것입니다. 공식 릴리스 발표 전에 어셈블리에 필요한 패키지가 공개 저장소에 게시됩니다. OpenBuildService의 사용 가능한 배포 목록에 새로운 배포가 나타납니다. 확인란을 선택하면 빌드 계획에 추가됩니다. 따라서 새 버전의 배포판을 추가하는 것은 거의 한 번의 클릭으로 완료됩니다.

우리 인프라에서는 OpenBuildService를 사용하여 SUSE 배포용 veeamsnap 커널 모듈의 다양한 KMP 패키지가 어셈블됩니다.

다음으로 커널 모듈과 관련된 문제에 대해 이야기하고 싶습니다.

커널 ABI

Linux 커널 모듈은 역사적으로 소스 형태로 배포되었습니다. 사실 커널 작성자는 커널 모듈, 특히 kABI라고도 하는 바이너리 수준에서 안정적인 API를 지원하는 문제에 대해 부담을 느끼지 않습니다.

바닐라 커널용 모듈을 빌드하려면 이 특정 커널의 헤더가 반드시 필요하며 이는 이 커널에서만 작동합니다.

DKMS를 사용하면 커널을 업데이트할 때 모듈 구축 프로세스를 자동화할 수 있습니다. 결과적으로 Debian 저장소(및 많은 관련 저장소) 사용자는 배포자의 저장소에서 커널 모듈을 사용하거나 DKMS를 사용하여 소스에서 컴파일됩니다.

그러나 이러한 상황은 특히 Enterprise 부문에 적합하지 않습니다. 독점 코드 배포자는 제품을 컴파일된 바이너리로 배포하려고 합니다.

관리자는 보안상의 이유로 프로덕션 서버에 개발 도구를 유지하는 것을 원하지 않습니다. Red Hat 및 SUSE와 같은 엔터프라이즈 Linux 배포자는 사용자를 위해 안정적인 kABI를 지원할 수 있다고 결정했습니다. 그 결과 Red Hat용 KMOD 패키지와 SUSE용 KMP 패키지가 탄생했습니다.

이 솔루션의 본질은 매우 간단합니다. 특정 버전의 배포판에서는 커널 API가 동결됩니다. 배포자는 커널(예: 3.10)을 사용하고 커널 인터페이스에 영향을 주지 않는 수정 및 개선만 수행하며 첫 번째 커널에 대해 수집된 모듈은 재컴파일 없이 모든 후속 커널에 사용할 수 있다고 명시합니다.

Red Hat은 전체 라이프사이클에 걸쳐 배포판에 대해 kABI 호환성을 주장합니다. 즉, rhel 6.0(2010년 6.10월 릴리스)용으로 조립된 모듈은 버전 2018(8년 XNUMX월 릴리스)에서도 작동해야 합니다. 그리고 이것은 거의 XNUMX 년입니다. 당연히 이 작업은 상당히 어렵습니다.
kABI 호환성 문제로 인해 veeamsnap 모듈이 작동을 멈춘 여러 사례를 기록했습니다.

RHEL 7.0용으로 컴파일된 veeamsnap 모듈이 RHEL 7.5의 커널과 호환되지 않는 것으로 밝혀졌지만 로드되어 서버 충돌이 보장된 후 우리는 RHEL 7에 대한 kABI 호환성 사용을 완전히 포기했습니다.

현재 RHEL 7용 KMOD 패키지에는 각 릴리스 버전에 대한 어셈블리와 모듈을 로드하는 스크립트가 포함되어 있습니다.

SUSE는 kABI 호환성 작업에 더욱 신중하게 접근했습니다. 하나의 서비스 팩 내에서만 kABI 호환성을 제공합니다.

예를 들어 SLES 12는 2014년 12월에 출시되었습니다. 그리고 SLES 1 SP2015은 이미 3.12년 XNUMX월에 출시되었습니다. 즉, XNUMX년이 조금 넘었습니다. 두 릴리스 모두 XNUMX 커널을 사용하지만 kABI와 호환되지 않습니다. 분명히 XNUMX년 동안 kABI 호환성을 유지하는 것이 훨씬 쉽습니다. 연간 커널 모듈 업데이트 주기는 모듈 작성자에게 문제를 일으키지 않아야 합니다.

이 SUSE 정책의 결과로 우리는 veeamsnap 모듈에서 kABI 호환성과 관련된 단일 문제를 기록하지 않았습니다. 사실, SUSE의 패키지 수가 거의 한 자릿수 더 많습니다.

패치 및 백포트

배포자는 kABI 호환성과 커널 안정성을 보장하려고 노력하지만, 이 안정적인 커널의 성능을 향상하고 결함을 제거하려고도 노력합니다.

동시에 엔터프라이즈 Linux 커널 개발자는 "오류에 대한 작업" 외에도 바닐라 커널의 변경 사항을 모니터링하고 이를 "안정적인" 커널로 전송합니다.

때로는 이것이 새로운 것으로 이어지기도 합니다. 실수.

Red Hat 6의 최신 릴리스에서는 사소한 업데이트 중 하나에 실수가 있었습니다. 이는 스냅샷이 공개될 때 veeamsnap 모듈이 시스템 충돌을 보장한다는 사실로 이어졌습니다. 업데이트 전후의 커널 소스를 비교한 결과, 백포트가 원인이라는 것을 알게 되었습니다. 바닐라 커널 버전 4.19에서도 비슷한 수정이 이루어졌습니다. 이 수정 사항은 바닐라 커널에서는 잘 작동했지만 "안정적인" 2.6.32로 전송할 때 스핀록에 문제가 발생했습니다.

물론 누구에게나 항상 오류가 있지만, 안정성을 위협하면서 코드를 4.19에서 2.6.32로 드래그할 가치가 있었나요?.. 잘 모르겠습니다...

최악의 상황은 마케팅이 '안정'과 '현대화' 사이의 줄다리기에 끼어들 때입니다. 마케팅 부서에서는 업데이트된 배포판의 핵심이 안정적이면서 동시에 성능이 향상되고 새로운 기능이 필요합니다. 이것은 이상한 타협으로 이어집니다.

SLES 4.4 SP12에서 커널 3에 모듈을 빌드하려고 했을 때 바닐라 4.8의 기능이 포함되어 있다는 사실에 놀랐습니다. 제 생각에는 SLES 4.4 SP12의 3 커널의 블록 I/O 구현은 SLES4.8 SP4.4의 안정적인 12 커널의 이전 릴리스보다 2 커널과 더 유사합니다. SP4.8용 커널 4.4에서 SLES 3로 코드의 몇 퍼센트가 전송되었는지 판단할 수는 없지만 커널을 동일한 안정 4.4라고 부를 수도 없습니다.

가장 불쾌한 점은 다른 커널에서 동일하게 작동하는 모듈을 작성할 때 더 이상 커널 버전에 의존할 수 없다는 것입니다. 분포도 고려해야합니다. 때때로 새로운 기능과 함께 나타나는 정의에 참여할 수 있다는 것은 좋지만 이러한 기회가 항상 나타나는 것은 아닙니다.

결과적으로 코드는 이상한 조건부 컴파일 지시문으로 가득 차게 됩니다.

문서화된 커널 API를 변경하는 패치도 있습니다.
배포판을 접했어요 KDE 네온 5.16 버전을 사용했으며 이 커널 버전의lookup_bdev 호출이 입력 매개변수 목록을 변경한 것을 보고 매우 놀랐습니다.

이를 통합하기 위해 makefile에 lookup_bdev 함수에 마스크 매개변수가 있는지 확인하는 스크립트를 추가해야 했습니다.

커널 모듈 서명

하지만 패키지 배포 문제로 돌아가 보겠습니다.

안정적인 kABI의 장점 중 하나는 커널 모듈을 바이너리 파일로 서명할 수 있다는 것입니다. 이 경우 개발자는 모듈이 실수로 손상되거나 의도적으로 수정되지 않았음을 확신할 수 있습니다. modinfo 명령으로 이를 확인할 수 있습니다.

Red Hat 및 SUSE 배포판에서는 모듈의 서명을 확인하고 해당 인증서가 시스템에 등록된 경우에만 로드할 수 있습니다. 인증서는 모듈이 서명되는 데 사용되는 공개 키입니다. 별도의 패키지로 배포하고 있습니다.

여기서 문제는 인증서가 커널에 내장되거나(배포자가 사용함) 유틸리티를 사용하여 EFI 비휘발성 메모리에 기록되어야 한다는 것입니다. 모쿠틸. 공익사업 모쿠틸 인증서를 설치할 때 시스템을 재부팅해야 하며 운영 체제 커널을 로드하기 전에도 관리자에게 새 인증서 로드를 허용하라는 메시지가 표시됩니다.

따라서 인증서를 추가하려면 시스템에 대한 물리적 관리자 액세스가 필요합니다. 머신이 클라우드 어딘가에 있거나 단순히 원격 서버실에 있고 네트워크(예: SSH를 통해)를 통해서만 액세스할 수 있는 경우 인증서를 추가할 수 없습니다.

가상 머신의 EFI

거의 모든 마더보드 제조업체에서 EFI를 오랫동안 지원해 왔음에도 불구하고 시스템을 설치할 때 관리자는 EFI의 필요성에 대해 생각하지 않고 비활성화될 수 있습니다.

모든 하이퍼바이저가 EFI를 지원하는 것은 아닙니다. VMWare vSphere는 버전 5부터 EFI를 지원합니다.
Microsoft Hyper-V는 Windows Server 2012R2용 Hyper-V부터 EFI 지원도 얻었습니다.

그러나 기본 구성에서는 Linux 시스템에 대해 이 기능이 비활성화되어 있으므로 인증서를 설치할 수 없습니다.

vSphere 6.5에서 옵션을 설정하십시오. 안전 부팅 Flash를 통해 실행되는 이전 버전의 웹 인터페이스에서만 가능합니다. HTML-5의 웹 UI는 아직 한참 뒤처져 있습니다.

실험적 분포

그리고 마지막으로 실험적인 배포판과 공식적인 지원이 없는 배포판의 문제를 고려해 보겠습니다. 한편으로 이러한 배포판은 심각한 조직의 서버에서 발견될 가능성이 낮습니다. 이러한 배포판에 대한 공식적인 지원은 없습니다. 그러므로 이를 제공하십시오. 해당 배포판에서는 제품을 지원할 수 없습니다.

그러나 이러한 배포판은 새로운 실험 솔루션을 시도하기 위한 편리한 플랫폼이 됩니다. 예를 들어 Fedora, OpenSUSE Tumbleweed 또는 Unstable 버전의 Debian이 있습니다. 그들은 매우 안정적입니다. 그들은 항상 새로운 버전의 프로그램과 항상 새로운 커널을 가지고 있습니다. XNUMX년 안에 이 실험적 기능은 업데이트된 RHEL, SLES 또는 Ubuntu로 끝날 수 있습니다.

따라서 실험적 배포판에서 무언가가 작동하지 않는다면 이것이 문제를 파악하고 해결해야 하는 이유입니다. 이 기능이 곧 사용자의 프로덕션 서버에 나타날 것이라는 사실에 대비해야 합니다.

버전 3.0에 대해 공식적으로 지원되는 배포판의 현재 목록을 연구할 수 있습니다. 여기에. 그러나 우리 제품이 작동할 수 있는 실제 배포판 목록은 훨씬 더 넓습니다.

개인적으로 저는 Elbrus OS 실험에 관심이 있었습니다. veeam 패키지를 완성한 후 제품이 설치되어 작동했습니다. 나는 Habré에 대한 이 실험에 대해 다음과 같이 썼습니다. 기사.

음, 새로운 배포판에 대한 지원은 계속됩니다. 버전 4.0이 출시되기를 기다리고 있습니다. 베타가 곧 등장할 예정이니 주목해주세요. 새로운 소식!

출처 : habr.com