SUSE RMT 서버(SMT 대체) 로컬 설정 방법

현재 SUSE Linux Enterprise 시스템용 로컬 서버를 설정하는 경우 새 SMT 설치가 아닌 RMT(Repository Mirroring Tool)를 사용하십시오. SUSE는 SLE 15부터 SMT를 RMT로 대체했습니다. RMT는 SUSE 고객 센터(SCC)에서 제품 및 저장소 정보를 동기화하고, 선택한 패키지를 미러링하며, 지원되는 클라이언트가 로컬 서버를 통해 등록할 수 있도록 합니다. 이 가이드는 2026년 10월 6일 기준으로 확인된 SUSE Linux Enterprise Server 15 SP7 RMT 설명서를 기반으로 합니다. 다른 릴리스에서는 명령 및 패키지 가용성이 다를 수 있으므로 배포하는 정확한 서버 버전에 맞는 가이드를 참조하십시오.

RMT를 사용해야 할까요, 아니면 SMT를 유지해야 할까요?

SLES 12 이상 클라이언트를 위한 새로운 로컬 등록 및 업데이트 서비스로 RMT를 선택하십시오. RMT는 SLES 15 버전부터 포함되어 있으며 SUSE 저장소 및 사용자 지정 저장소를 미러링할 수 있습니다. 이를 통해 반복 다운로드를 줄이고 클라이언트 컴퓨터가 SCC에 직접 연결하지 않도록 할 수 있습니다.

SMT는 이전 환경에서 여전히 유용하지만, SUSE는 SLE 12를 SMT의 마지막 코드 스트림으로 규정하고 있습니다. RMT는 SLE 11 이전 버전의 클라이언트를 지원하지 않으며, SUSE는 RMT가 SMT를 완벽하게 대체하는 서비스가 아니라고 경고합니다. 예를 들어, 마이그레이션 가이드에서는 스테이징된 저장소, SMT 클라이언트 관리 및 보고 기능이 RMT로 이전될 때 동일하게 제공되지 않는다고 명시하고 있습니다. SLE 11을 사용하거나 SMT 전용 워크플로에 의존하는 환경이라면, RMT로 바로 대체할 수 있다고 생각하지 마십시오. 서비스를 변경하기 전에 마이그레이션 가이드와 SUSE 지원 옵션을 검토하시기 바랍니다.

RMT는 에어갭 방식의 패키지 저장소와도 다릅니다. 표준 RMT 서버는 메타데이터와 패키지를 동기화하기 위해 SCC 및 SUSE 업데이트 서비스에 대한 외부 액세스가 필요합니다. 연결이 끊긴 배포 환경에서는 별도의 내보내기/가져오기 또는 오프라인 미러링 프로세스가 필요합니다.

설치 전에 무엇을 준비해야 할까요?

• 지원되는 호스트: RMT 서비스를 위해 SLES 15 서버를 계획하십시오. SMT에서 마이그레이션하는 경우 SUSE는 새로 설치된 SLES 15 호스트를 사용하는 것을 권장합니다.
• SCC 조직 자격 증명: RMT는 일반 클라이언트 등록 코드가 아닌 조직의 미러링 자격 증명을 사용합니다. SCC에서 올바른 조직을 선택하고 프록시 설정을 열어 해당 조직을 찾으십시오.
• 안정적인 DNS 이름과 TLS 플랜: 클라이언트가 사용할 정규화된 도메인 이름(FQDN)을 선택하십시오(예: rmt.example.com). 클라이언트 네트워크에서 해당 이름이 제대로 확인되고 HTTPS 인증서의 이름과 일치하는지 확인하십시오.
• 저장소 저장 공간: 미러링할 제품, 모듈, 버전 및 아키텍처에 필요한 저장 공간을 지정합니다. SUSE는 일반적인 계획 지침으로 활성화된 전체 저장소 크기의 약 1.5배를 권장하며, 이는 확장 기능을 포함하여 SLE 릴리스당 약 200GB에 해당한다고 명시합니다. 실제 필요량은 다를 수 있으므로, 특히 . 아래의 임시 공간을 포함하여 여유 공간을 지속적으로 모니터링해야 합니다 /tmp.
• 네트워크 액세스: RMT 호스트가 사용 중인 릴리스에 필요한 SUSE 엔드포인트에 접근할 수 있도록 허용하십시오. SLES 15 SP7 가이드에는 포트 80 및 443을 통한 scc.suse.com, updates.suse.com, 가 installer-updates.suse.com나열되어 있습니다. RMT 서비스에 대한 클라이언트 액세스는 필요한 네트워크로 제한하십시오.

SUSE 경고를 확인하지 않고 동일한 시스템에서 RMT 역할과 SLES 설치 서버 역할을 함께 사용하지 마십시오. 두 구성은 포트 80에서 서로 다른 웹 서버를 사용하며 동시에 활성화하도록 설계되지 않았습니다.

RMT를 설치하고 구성하는 방법은 무엇입니까?

1. RMT 패키지를 설치합니다.

필요한 저장소가 있는 기존 SLES 15 호스트에 서버 패키지를 설치하고 최신 유지 관리 업데이트를 적용하십시오.

sudo zypper in rmt-server
sudo zypper patch

최소 이미지 및 배포 방법에 따라 정확한 패키지 세트가 다를 수 있습니다. 다른 플랫폼의 명령어를 복사하지 말고 선택한 SLES 릴리스의 설치 섹션을 따르십시오.

2. YaST RMT 구성을 실행합니다.

구성 모듈을 시작하세요:

sudo yast2 rmt

메시지가 표시되면 SCC 조직 미러링 사용자 이름과 암호를 입력하십시오. YaST는 MariaDB 데이터베이스 및 사용자 이름과 인증서 공통 이름도 요청합니다. 공통 이름으로는 RMT 서버의 클라이언트용 FQDN을 사용하십시오. 클라이언트가 실제로 사용할 다른 이름이나 IP 주소가 있는 경우 인증서의 대체 이름으로 추가하십시오. 목록에 없는 이름으로 연결하는 클라이언트는 서비스에 연결할 수 있더라도 인증서 불일치를 보고할 수 있습니다.

YaST 옵션이 활성화된 경우 firewalld, 필요한 RMT 포트를 열도록 YaST를 사용하십시오. 가능한 경우, 올바른 네트워크 인터페이스 또는 영역에 대한 액세스 범위를 지정하십시오. 마법사를 완료하고 요약을 검토하십시오. SUSE에 따르면 YaST는 필요한 systemd 서비스와 타이머를 활성화하고 시작합니다.

3. 서버 이름, 인증서 및 서비스를 확인하십시오.

클라이언트 네트워크에서 선택한 FQDN이 RMT 호스트로 확인되는지, 그리고 HTTPS가 클라이언트가 신뢰하는 인증서를 제공하는지 확인하십시오. RMT에서 생성된 CA 인증서는 에 저장되고 /etc/rmt/ssl/rmt-ca.crt, 서버 인증서와 키는 /etc/rmt/ssl/rmt-server.crt및 에 저장됩니다 /etc/rmt/ssl/rmt-server.key. 개인 키를 안전하게 보관하고, 신뢰가 필요한 클라이언트가 사용할 수 있도록 CA 인증서를 유지하십시오. 등록 시 서버 인증서에 표시된 것과 동일한 FQDN을 사용하십시오.

필요한 저장소만 선택하고 미러링하는 방법은 무엇인가요?

4. 제품 및 저장소 메타데이터 동기화

설정 후 로컬 RMT 데이터베이스를 SCC와 동기화하십시오.

sudo rmt-cli sync

이는 RMT에서 사용할 수 있는 제품 및 저장소 정보를 업데이트하는 것이며, 모든 패키지가 이미 다운로드되었다는 의미는 아닙니다. 자동 메타데이터 동기화는 에서 관리합니다 rmt-server-sync.timer. 다음 명령으로 상태를 확인하세요.

systemctl status rmt-server-sync.timer

5. 소유 부동산의 제품 식별자를 찾으십시오.

기능을 활성화하기 전에 사용 가능한 제품 및 저장소 목록을 확인하세요.

sudo rmt-cli products list --all
sudo rmt-cli repos list --all

서버에서 제공하는 ID 또는 제품 문자열을 사용하십시오. 온라인 예제의 ID는 구독, 제품 버전, 아키텍처 및 SCC에서 반환하는 메타데이터에 따라 가용성이 달라지므로 실제 ID와 다를 수 있습니다.

6. 필요한 제품을 활성화합니다.

고객이 실제로 사용하는 제품을 활성화하세요. 예를 들어, 제품 문자열이 출력에 있는지 확인한 후 다음 명령을 실행할 수 있습니다.

sudo rmt-cli products enable SLES/15/x86_64

제품을 활성화하면 풀 저장소 및 업데이트 저장소와 같은 관련 저장소도 함께 활성화됩니다. 시스템에서 추가 모듈이나 확장 기능을 사용하는 경우 해당 제품이 사용 가능한지 확인하고 필요한 제품만 활성화하십시오. 모든 제품을 "혹시 모를 경우를 대비해" 미러링하는 것은 저장 공간을 차지하고 동기화 시간을 증가시키므로 피해야 합니다.

7. 패키지를 미러링하고 결과를 검사합니다.

일정에 따라 진행하기 전에 완료 여부를 확인하고 문제를 해결할 수 있도록 초기 미러링을 수동으로 시작하세요.

sudo rmt-cli mirror

RMT는 /var/lib/rmt/public/repo기본적으로 미러링된 콘텐츠를 해당 위치에 저장합니다. 사용 가능한 디스크 공간을 확인하고 명령 출력 결과를 검토하십시오. 일일 미러링 일정은 에서 관리하며 rmt-server-mirror.timer, 다음 명령으로 상태를 확인할 수 있습니다.

systemctl status rmt-server-mirror.timer

메타데이터 동기화가 성공적으로 완료되었다고 해서 클라이언트가 업데이트를 설치할 수 있다는 것을 보장하는 것은 아닙니다. 선택한 저장소가 미러링되어 있어야 하고, 클라이언트가 서버에 연결할 수 있어야 하며, 조직에 제품 액세스 권한이 유효해야 합니다.

로컬 서버에 클라이언트를 등록하는 방법은 무엇입니까?

8. 먼저 한 명의 고객으로 테스트해 보세요.

지원되는 SLES 클라이언트에서 RMT 호스트 이름에 대해 등록하십시오. SUSE는 이 명령 형식을 문서화했습니다.

sudo SUSEConnect --url https://rmt.example.com

예제 호스트를 인증서에 포함된 FQDN으로 바꾸십시오. 클라이언트는 일반적으로 SCC 미러링 자격 증명이 필요하지 않습니다. RMT 호스트가 해당 자격 증명을 사용하여 조직을 대신하여 동기화합니다. RMT CA 가져오기에 도움이 필요한 시스템의 경우 SUSE에서 rmt-client-setup서버에서 제공하는 스크립트를 사용할 수 있습니다. 인증서를 수락하기 전에 최신 클라이언트 가이드를 검토하고 인증서 지문 또는 신뢰 체인을 확인하십시오.

설치 중에 부팅 매개변수를 사용하여 등록을 구성하거나 YaST의 제품 등록 모듈을 사용하여 로컬 등록 서버를 선택할 수도 있습니다 regurl=https://rmt.example.com. 자동 설치의 경우 SUSE에서 제공하는 AutoYaST 옵션을 참조하십시오. 시스템 프로비저닝 방식에 맞는 방법을 선택하십시오.

9. 등록 및 패키지 접근 권한을 확인합니다.

클라이언트 측에서 등록이 완료되고 예상되는 제품 및 저장소가 표시되며 저장소 메타데이터를 새로 고칠 수 있는지 확인하십시오. 예를 들어, `inspect` 명령어를 사용하여 저장소 정의를 검사 zypper lr하고 `renew` 명령어를 사용하여 새로 고침하십시오 sudo zypper refresh. 그런 다음 유지 관리 기간에 패키지 쿼리 또는 업데이트를 테스트하십시오. 모듈이 누락된 경우 클라이언트 측 저장소 파일을 변경하기 전에 해당 모듈이 활성화되어 있고 RMT에 미러링되어 있는지 확인하십시오.

대규모 시스템을 리디렉션하기 전에 대표 클라이언트 한 대에서 일반 업데이트 경로를 테스트하십시오. 테스트가 성공하면 프로비저닝 프로필, 설치 부팅 매개변수 또는 구성 관리를 업데이트하여 새 시스템과 재구축된 시스템이 동일한 RMT URL을 사용하도록 하십시오.

무언가에 문제가 생겼을 때 무엇을 확인해야 할까요?

SMT에서 마이그레이션하는 경우 어떤 점이 달라지나요?

마이그레이션은 패키지 업그레이드가 아닌 데이터 및 워크플로 변경으로 간주해야 합니다. SUSE는 새로운 SLES 15 호스트를 권장합니다. 문서화된 내보내기/가져오기 프로세스는 smt-data-exportSMT와 rmt-data-importRMT가 SCC와 동기화된 후 새 서버에서 수행됩니다. 스테이징된 저장소 설정은 내보내지지 않으며, 미러링 대상으로 표시된 저장소만 이전되고, 만료된 제품은 RMT에서 사용할 수 없습니다. SMT 클라이언트 작업 및 패치 상태는 내보내지지 않습니다. 이러한 기능에 의존하는 운영 프로세스를 다시 생성하고 프로덕션 클라이언트를 리디렉션하기 전에 등록 레코드를 검증해야 합니다.

지원 및 보안 정책이 허용하는 경우, 통제된 전환 과정 동안 기존 서비스를 계속 사용할 수 있도록 유지하십시오. 소규모 클라이언트 그룹을 마이그레이션하고 등록, 저장소, 인증서 신뢰 및 업데이트 동작을 확인한 후 확장하십시오. 레거시 클라이언트와 지원되지 않는 워크플로가 명확한 대상으로 지정될 때까지 SMT 호스트를 폐기하지 마십시오.

설치가 완료되었는지 어떻게 알 수 있나요?

• RMT FQDN은 올바르게 확인되고 HTTPS는 클라이언트가 신뢰하는 인증서를 사용합니다.
• RMT 호스트는 현재 SCC 메타데이터를 동기화하고 파일럿 클라이언트가 필요로 하는 모든 제품 저장소를 미러링합니다.
• 지원되는 클라이언트는 로컬 URL에 등록하고 의도된 제품 저장소를 볼 수 있습니다.
• 클라이언트는 저장소 메타데이터를 새로 고치고 제어된 패키지 작업을 완료할 수 있습니다.
• 디스크 용량, 임시 공간, 타이머, 로그, 백업 및 인증서 갱신에는 담당자와 모니터링 계획이 있습니다.

RMT는 등록 및 패키지 배포를 중앙 집중화하지만, 구독 관리, 제품 선택, 클라이언트 수명 주기, 인증서 신뢰, 백업 및 업데이트 테스트 관리가 필요 없어지는 것은 아닙니다. 정확한 절차 및 릴리스별 차이점에 대해서는 SUSE의 SLES 15 SP7 리포지토리 미러링 도구 가이드 , SMT에서 RMT로의 마이그레이션 장 , RMT 클라이언트 구성 장 및 SUSE의 리포지토리 미러링 장을 참조하십시오 .