Jak skonfigurować lokalny serwer SUSE RMT (zamiennik SMT)

Jeśli konfigurujesz serwer lokalny dla obecnych systemów SUSE Linux Enterprise, użyj narzędzia Repository Mirroring Tool (RMT), a nie nowej instalacji SMT. Firma SUSE zastąpiła narzędzie Subscription Management Tool (SMT) narzędziem RMT od wersji SLE 15. RMT synchronizuje informacje o produkcie i repozytorium z Centrum Obsługi Klienta SUSE (SCC), tworzy kopię lustrzaną wybranych pakietów i umożliwia klientom rejestrację za pośrednictwem serwera lokalnego. Niniejszy przewodnik jest oparty na dokumentacji RMT systemu SUSE Linux Enterprise Server 15 SP7, sprawdzonej 6 października 2026 r. Polecenia i dostępność pakietów mogą się różnić w innych wersjach, dlatego należy zapoznać się z przewodnikiem dotyczącym konkretnej wersji serwera, którą wdrażasz.

Czy powinieneś używać RMT czy zachować SMT?

Wybierz RMT, aby skorzystać z nowej lokalnej usługi rejestracji i aktualizacji dla klientów SLES 12 i nowszych. RMT jest dostępny w SLES od wersji 15 i może odzwierciedlać repozytoria SUSE oraz repozytoria niestandardowe. Zmniejsza to liczbę wielokrotnych pobrań i może uniemożliwić komputerom klienckim bezpośrednie łączenie się z SCC.

SMT nadal ma zastosowanie w starszych środowiskach, ale SUSE identyfikuje SLE 12 jako ostatni kod źródłowy dla SMT. RMT nie obsługuje klientów SLE 11 i starszych, a SUSE ostrzega, że ​​RMT nie jest kompletnym zamiennikiem funkcji po funkcji: na przykład, przewodnik migracji wymienia repozytoria etapowe, zarządzanie klientami SMT i raportowanie jako funkcje, które nie są przenoszone w ten sam sposób. Jeśli Twoja infrastruktura obejmuje SLE 11 lub opiera się wyłącznie na przepływach pracy SMT, nie zakładaj, że bezpośrednia wymiana jest możliwa. Przed zmianą usługi zapoznaj się z przewodnikiem migracji i opcjami wsparcia SUSE.

RMT różni się również od repozytorium pakietów z izolacją powietrzną. Standardowy serwer RMT wymaga dostępu wychodzącego do usług aktualizacji SCC i SUSE, aby synchronizować metadane i pakiety. Wdrożenie bez połączenia wymaga oddzielnego procesu eksportu/importu lub tworzenia kopii lustrzanej offline.

Co należy przygotować przed instalacją?

• Obsługiwany host: Zaplanuj serwer SLES 15 dla usługi RMT. W przypadku migracji z SMT firma SUSE zaleca użycie nowo zainstalowanego hosta SLES 15.
• Dane uwierzytelniające organizacji SCC: RMT używa danych uwierzytelniających organizacji, a nie zwykłego kodu rejestracyjnego klienta. W SCC wybierz odpowiednią organizację i otwórz zakładkę „Proxies” , aby ją znaleźć.
• Stabilna nazwa DNS i plan TLS: Wybierz w pełni kwalifikowaną nazwę domeny (FQDN), której będą używać klienci, na przykład rmt.example.com. Upewnij się, że jest ona rozpoznawana w sieciach klientów i odpowiada nazwie w certyfikacie HTTPS.
• Przechowywanie w repozytorium: Określ rozmiar pamięci masowej dla produktów, modułów, wersji i architektur, które zamierzasz dublować. SUSE podaje około 1,5-krotność całkowitego dostępnego rozmiaru repozytorium jako ogólną wytyczną planowania i zaznacza, że ​​wynosi on około 200 GB na wydanie SLE, wliczając rozszerzenia. Rzeczywiste zapotrzebowanie jest zmienne; monitoruj wolne miejsce, zwłaszcza tymczasowe w ramach /tmp.
• Dostęp do sieci: Zezwól hostowi RMT na dostęp do punktów końcowych SUSE wymaganych przez Twoją wersję. W podręczniku SLES 15 SP7 wymieniono scc.suse.com, updates.suse.com, i installer-updates.suse.comna portach 80 i 443. Ogranicz dostęp klientów do usługi RMT do sieci, które go potrzebują.

Nie należy łączyć roli RMT z rolą serwera instalacji SLES na tym samym komputerze bez sprawdzenia ostrzeżenia SUSE: te dwie konfiguracje używają różnych serwerów WWW na porcie 80 i nie są przeznaczone do jednoczesnego włączania.

Jak zainstalować i skonfigurować RMT?

1. Zainstaluj pakiet RMT

Zainstaluj pakiet serwera i zastosuj bieżące aktualizacje konserwacyjne na istniejącym hoście SLES 15 z dostępnymi wymaganymi repozytoriami:

sudo zypper in rmt-server
sudo zypper patch

Dokładny zestaw pakietów może się różnić w zależności od minimalnej liczby obrazów i metod wdrażania. Postępuj zgodnie z sekcją instalacji dla wybranej wersji SLES, zamiast kopiować polecenie z innej platformy.

2. Uruchom konfigurację YaST RMT

Uruchom moduł konfiguracji:

sudo yast2 rmt

Wprowadź nazwę użytkownika i hasło organizacji SCC, gdy pojawi się monit. YaST poprosi również o bazę danych MariaDB i użytkownika oraz o wspólną nazwę certyfikatu. Jako wspólną nazwę użyj pełnej nazwy domeny (FQDN) serwera RMT dla klienta. Dodaj wszelkie inne nazwy lub adresy IP, których klienci będą faktycznie używać jako nazw alternatywnych w certyfikacie. Klient łączący się za pomocą nazwy niewymienionej na liście może zgłosić niezgodność certyfikatu, nawet jeśli usługa jest dostępna.

Jeśli firewalldopcja jest włączona, użyj opcji YaST, aby otworzyć wymagane porty RMT. W miarę możliwości określ zakres dostępu do odpowiedniego interfejsu sieciowego lub strefy. Ukończ działanie kreatora i zapoznaj się z jego podsumowaniem; SUSE informuje, że YaST włącza i uruchamia wymagane usługi systemd oraz timery.

3. Potwierdź nazwę serwera, certyfikat i usługę

Z sieci klienta sprawdź, czy wybrana nazwa FQDN jest rozpoznawana przez hosta RMT i czy protokół HTTPS prezentuje certyfikat zaufany przez klienta. Wygenerowany przez RMT certyfikat CA jest przechowywany w /etc/rmt/ssl/rmt-ca.crt; certyfikat i klucz serwera są przechowywane w /etc/rmt/ssl/rmt-server.crti /etc/rmt/ssl/rmt-server.key. Chroń klucz prywatny i udostępniaj certyfikat CA klientom, którzy muszą mu zaufać. Do rejestracji użyj dokładnie tej samej nazwy FQDN, która pojawia się w certyfikacie serwera.

Jak wybierać i odzwierciedlać tylko te repozytoria, których potrzebujesz?

4. Synchronizuj metadane produktu i repozytorium

Po konfiguracji należy zsynchronizować lokalną bazę danych RMT z SCC:

sudo rmt-cli sync

Aktualizuje to informacje o produkcie i repozytorium dostępne dla RMT; nie oznacza to, że każdy pakiet został już pobrany. Automatyczna synchronizacja metadanych jest zarządzana przez rmt-server-sync.timer. Sprawdź jej stan za pomocą:

systemctl status rmt-server-sync.timer

5. Znajdź identyfikatory produktów dla swojej posiadłości

Przed włączeniem czegokolwiek wyświetl listę dostępnych produktów i repozytoriów:

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

Użyj identyfikatorów lub ciągów produktów zgłoszonych przez Twój serwer. Identyfikatory w przykładach online mogą się różnić, ponieważ dostępność zależy od subskrypcji, wersji produktów, architektur i metadanych zwróconych przez SCC.

6. Włącz wymagane produkty

Włącz produkty, z których klienci faktycznie korzystają. Na przykład, po potwierdzeniu, że ciąg znaków produktu znajduje się w wynikach, możesz uruchomić:

sudo rmt-cli products enable SLES/15/x86_64

Włączenie produktu powoduje również włączenie powiązanych z nim repozytoriów, takich jak repozytoria pul i aktualizacji. Jeśli Twoje systemy korzystają z dodatkowych modułów lub rozszerzeń, sprawdź, czy te produkty są dostępne i włącz te, które są potrzebne. Unikaj tworzenia kopii lustrzanych każdego produktu „na wszelki wypadek”: zużywa to pamięć masową i wydłuża czas synchronizacji.

7. Odbij pakiety i sprawdź wynik

Uruchom ręcznie początkowe lustro, aby móc obserwować jego ukończenie i rozwiązywać problemy przed rozpoczęciem pracy na podstawie harmonogramu:

sudo rmt-cli mirror

RMT domyślnie przechowuje zdublowaną zawartość w katalogu /var/lib/rmt/public/repo. Sprawdź dostępne miejsce na dysku i przejrzyj wyniki polecenia. Codziennym harmonogramem dublowania zarządza rmt-server-mirror.timer; sprawdź jego status za pomocą:

systemctl status rmt-server-mirror.timer

Sama pomyślna synchronizacja metadanych nie jest dowodem na to, że klienci mogą instalować aktualizacje. Wybrane repozytoria muszą być zdublowane, klient musi mieć dostęp do serwera, a dostęp do produktu musi być ważny dla organizacji.

Jak zarejestrować klienta na serwerze lokalnym?

8. Najpierw przetestuj z jednym klientem

Na obsługiwanym kliencie SLES zarejestruj go, używając nazwy hosta RMT. SUSE dokumentuje następującą formę polecenia:

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

Zastąp przykładowy host nazwą FQDN objętą certyfikatem. Klienci zazwyczaj nie potrzebują poświadczeń lustrzanych SCC; host RMT używa tych poświadczeń do synchronizacji w imieniu organizacji. W przypadku systemów, które potrzebują pomocy w zaimportowaniu urzędu certyfikacji RMT, SUSE udostępnia skrypt rmt-client-setupz serwera. Zapoznaj się z aktualnym podręcznikiem klienta i zweryfikuj odcisk palca lub łańcuch zaufania certyfikatu przed zaakceptowaniem certyfikatu.

Możesz również skonfigurować rejestrację podczas instalacji za pomocą regurl=https://rmt.example.comparametru rozruchu lub skorzystać z modułu rejestracji produktu YaST i wybrać lokalny serwer rejestracji. W przypadku instalacji zautomatyzowanych SUSE dokumentuje opcję AutoYaST. Wybierz metodę, która odpowiada sposobowi, w jaki Twoje systemy są aprowizowane.

9. Zweryfikuj rejestrację i dostęp do pakietu

Po stronie klienta sprawdź, czy rejestracja została zakończona, czy pojawiły się oczekiwane produkty i repozytoria, a metadane repozytorium można odświeżyć. Na przykład, sprawdź definicje repozytorium za pomocą zypper lri odśwież je za pomocą sudo zypper refresh. Następnie przetestuj zapytanie o pakiet lub aktualizację w oknie konserwacji. Jeśli brakuje modułu, sprawdź, czy jest on włączony i zdublowany w RMT przed zmianą plików repozytorium po stronie klienta.

Przetestuj standardową ścieżkę aktualizacji na jednym reprezentatywnym kliencie przed przekierowaniem dużej floty. Po pomyślnym teście zaktualizuj profile provisioningu, parametry rozruchu instalacji lub zarządzanie konfiguracją, aby nowe i przebudowane systemy korzystały z tego samego adresu URL RMT.

Co należy sprawdzić, gdy coś ulegnie awarii?

Co się zmieni, jeśli migrujesz z SMT?

Potraktuj migrację jako zmianę danych i przepływu pracy, a nie aktualizację istniejącego pakietu. SUSE zaleca nowy host SLES 15. Udokumentowany proces eksportu/importu działa smt-data-exportw SMT i rmt-data-importna nowym serwerze po synchronizacji RMT z SCC. Ustawienia repozytorium etapowego nie są eksportowane, przenoszone są tylko repozytoria oznaczone do tworzenia kopii lustrzanych, a wygasłe produkty nie są dostępne w RMT. Zadania klienta SMT i status poprawek nie są eksportowane. Zaplanuj ponowne utworzenie procesów operacyjnych zależnych od tych funkcji i sprawdź poprawność rekordów rejestracji przed przekierowaniem klientów produkcyjnych.

Zachowaj dostępną starą usługę podczas kontrolowanej migracji, jeśli pozwalają na to Twoje zasady wsparcia i bezpieczeństwa. Przenieś niewielką grupę klientów, potwierdź rejestrację, repozytoria, zaufanie do certyfikatów i sposób aktualizacji, a następnie rozszerz. Nie wycofuj hosta SMT, dopóki starsi klienci i wszelkie nieobsługiwane przepływy pracy nie będą miały wyraźnie określonego celu.

Skąd wiesz, że konfiguracja jest gotowa?

• Nazwa FQDN RMT jest poprawnie rozpoznawana, a protokół HTTPS używa certyfikatu, któremu klienci ufają.
• Host RMT synchronizuje bieżące metadane SCC i odzwierciedla wszystkie repozytoria produktów wymagane przez klientów pilotażowych.
• Obsługiwany klient rejestruje się pod lokalnym adresem URL i widzi docelowe repozytoria produktów.
• Klient może odświeżyć metadane repozytorium i wykonać kontrolowaną operację pakowania.
• Pojemność dysku, przestrzeń tymczasowa, liczniki czasu, dzienniki, kopie zapasowe i odnawianie certyfikatów mają właściciela i plan monitorowania.

RMT centralizuje rejestrację i dostarczanie pakietów, ale nie eliminuje konieczności zarządzania subskrypcjami, wyborem produktów, cyklem życia klienta, zaufaniem certyfikatów, kopiami zapasowymi i testowaniem aktualizacji. Dokładne procedury i różnice w poszczególnych wersjach można znaleźć w podręczniku SUSE SLES 15 SP7 Repository Mirroring Tool Guide , w rozdziale poświęconym migracji z SMT do RMT , w rozdziale poświęconym konfiguracji klienta RMT oraz w rozdziale SUSE poświęconym tworzeniu kopii lustrzanych repozytoriów .