Jak zarejestrować maszynę SLES 15 w SUSE Manager w trybie offline

Komputer z systemem SLES 15 nie potrzebuje bezpośredniego dostępu do internetu, aby stać się zarządzanym klientem SUSE Manager. Wymaga on niezawodnego dostępu sieciowego do wewnętrznego serwera SUSE Manager lub serwera proxy, a także odpowiednich kanałów produktów SLES, repozytorium bootstrap, klucza aktywacyjnego i materiałów zaufania, które są już dostępne w tym środowisku.

To rozróżnienie ma znaczenie. „Rejestracja klienta offline” zazwyczaj oznacza, że ​​host SLES nie może nawiązać połączenia z Centrum Obsługi Klienta SUSE ani z publicznymi repozytoriami, ale może nawiązać połączenie z wewnętrznym systemem SUSE Manager. Wdrożenie SUSE Manager w pełni odizolowane od sieci to większy problem architektoniczny: zawartość repozytorium musi najpierw zostać zaimportowana do środowiska odłączonego za pomocą obsługiwanych metod tworzenia kopii lustrzanych. Firma SUSE dokumentuje to osobno w swoim przewodniku „Disconnected Setup” .

Celem tej procedury nie jest jedynie pojawienie się klienta na liście systemów. Dobry wynik ma cztery widoczne oznaki: host jest zarejestrowany pod docelowym kluczem aktywacji i kanałem bazowym, klient Salt jest uruchomiony i komunikuje się z menedżerem, metadane pakietów pochodzą z SUSE Manager, a nie z publicznych repozytoriów, oraz prosta czynność zarządzania, taka jak odświeżenie lub sprawdzenie stanu, kończy się pomyślnie.

Co powinno oznaczać „offline” przed rozpoczęciem pracy

W tym przewodniku klient SLES 15 nie ma bezpośredniego dostępu do internetu. Może on nawiązać połączenie z wewnętrznym serwerem SUSE Manager Server lub serwerem proxy za pomocą nazwy w pełni kwalifikowanej (FQDN) przez sieć. Menedżer ma już zsynchronizowaną wymaganą zawartość SLES 15. Jeśli sam serwer SUSE Manager Server jest odłączony od internetu, przed przystąpieniem do wdrażania klienta należy najpierw przygotować i zsynchronizować tę zawartość, korzystając z udokumentowanego przez SUSE przepływu pracy dla odłączonych serwerów.

Aktualna dokumentacja klienta SUSE informuje również, że SLE 15 domyślnie korzysta z Pythona 3 i że skrypty bootstrap utworzone dla Pythona 2 powinny zostać wygenerowane ponownie. Po aktualizacji lub migracji SUSE Manager, zaleca się również ponowne wygenerowanie skryptów bootstrap przed wdrożeniem nowych systemów. Zobacz Rejestrowanie klientów za pomocą skryptu bootstrap .

Krok 1: Sprawdź, czy zsynchronizowane są właściwe kanały SLES

Przed uruchomieniem klienta należy upewnić się, że SUSE Manager ma dokładną wersję systemu SLES, pakiet Service Pack, architekturę i wymagane moduły dla danej maszyny. Na przykład host SLES 15 SP7 x86_64 nie powinien być uruchamiany z zawartością przeznaczoną dla innego pakietu Service Pack lub architektury.

W interfejsie internetowym SUSE Manager sprawdź kanały produktów i stan synchronizacji. Konkretne nazwy kanałów różnią się w zależności od wersji i włączonych modułów, dlatego nie kopiuj etykiety kanału z innego środowiska bez jej sprawdzenia.

Przykładowy widok kanału: przed utworzeniem repozytorium Bootstrap sprawdź, czy rodzina produktów SLES 15 i wymagane moduły są zsynchronizowane.

Kontrola jakości: produkt podstawowy i wszystkie kanały wymagane przez klucz aktywacyjny są w pełni zsynchronizowane. Jeśli synchronizacja jest niekompletna, należy przerwać w tym miejscu. Rejestracja może działać częściowo, a następnie zakończyć się niepowodzeniem, gdy nie będzie można pobrać wymaganych pakietów klienckich.

Krok 2: Potwierdź lub wygeneruj repozytorium Bootstrap

Każdy klient potrzebuje dostępu do repozytorium bootstrap zawierającego pakiety użyte do wstępnego wdrożenia. SUSE Manager zazwyczaj automatycznie tworzy i regeneruje repozytoria bootstrap po zsynchronizowaniu wymaganych kanałów produktów, ale można je również wygenerować ręcznie.

Na serwerze kontenerowym SUSE Manager 5.x najpierw wprowadź kontener serwera:

mgrctl term

Następnie wypisz dostępne cele repozytoriów Bootstrap:

mgr-create-bootstrap-repo -l

Użyj listy repozytoriów, aby zidentyfikować cel odpowiadający wersji SLES i architekturze, którą wdrażasz.

Utwórz pasujące repozytorium Bootstrap, jeśli go brakuje lub wymaga regeneracji:

mgr-create-bootstrap-repo -c SLE-version-x86_64

SUSE dokumentuje lokalizację repozytorium Bootstrap w sekcji /srv/www/htdocs/pub/repositories/. Jeśli kilka produktów współdzieli bazę kodu, narzędzie może poprosić o wskazanie prawidłowego kanału nadrzędnego. Aktualna procedura jest udokumentowana w repozytorium Bootstrap .

Pomyślna kompilacja repozytorium oznacza, że ​​początkowe pakiety Salt i rejestracyjne mogą być dostarczane z poziomu zarządzanej sieci.

Kiedy zmienić podejście: jeśli nie można wygenerować repozytorium z powodu braku obowiązkowych kanałów, nie próbuj obejść problemu, kopiując losowe pakiety RPM do klienta. Najpierw napraw synchronizację produktów lub import odłączonych treści.

Krok 3: Utwórz klucz aktywacyjny z przypisanym do niego kanałem

Klucz aktywacyjny to coś więcej niż token rejestracyjny. Określa on ważne zachowania związane z wdrażaniem, w tym kanały oprogramowania i grupy przypisane do klienta. Utwórz klucz specjalnie dla wersji SLES i roli, którą rejestrujesz.

W interfejsie internetowym otwórz konfigurację klucza aktywacyjnego i sprawdź, czy kanał bazowy i kanały podrzędne odpowiadają docelowej maszynie SLES. Unikaj ponownego używania klucza utworzonego dla innego Service Packa tylko dlatego, że sama rejestracja się powiodła.

Klucz aktywacyjny powinien mapować nowego hosta SLES 15 na dokładne kanały wewnętrzne, z których ma on korzystać.

Kontrola jakości: klucz aktywacyjny jest jednoznaczny z jednym kanałem bazowym dla systemu operacyjnego i architektury klienta. Jeśli wiele kanałów nadrzędnych uniemożliwia mapowanie, należy to poprawić przed uruchomieniem skryptu rozruchowego.

Krok 4: Wygeneruj nowy skrypt Bootstrap

Firma SUSE zaleca użycie tego argumentu mgr-bootstrapdo utworzenia skryptu rejestracyjnego. W programie SUSE Multi-Linux Manager 5.1 dwa obowiązkowe argumenty to --activation-keysi --script.

mgrctl term
mgr-bootstrap --activation-keys=<ACTIVATION_KEY> --script=bootstrap-sles15-offline.sh

Wygenerowany skrypt można również utworzyć z poziomu interfejsu internetowego w obszarze Administracja > Konfiguracja menedżera > Skrypt Bootstrap . W przypadku projektu opartego na serwerze proxy, należy wygenerować skrypt dla pełnej nazwy kwalifikowanej serwera proxy, zamiast później bezgłośnie edytować odwołania do serwera.

Wygeneruj nowy skrypt powiązany z kluczem aktywacyjnym i serwerem lub serwerem proxy, do którego klient offline będzie mógł uzyskać dostęp.

Pozostaw włączony protokół SSL. SUSE wyraźnie ostrzega przed wyłączaniem protokołu SSL w konfiguracji rozruchowej. W sieci odizolowanej zaufanie do certyfikatu nadal ma znaczenie, ponieważ klient musi zweryfikować, czy komunikuje się z docelowym systemem zarządzania.

Krok 5: Przetestuj rozpoznawanie nazw, routing i dostępność certyfikatu dla klienta

Przed uruchomieniem skryptu przetestuj wewnętrzną ścieżkę z SLES 15 do SUSE Manager. Dokładne sprawdzenie zależy od topologii, ale co najmniej sprawdź rozpoznawanie DNS i dostępność HTTPS dla menedżera lub nazwy domeny serwera proxy używanej przez skrypt.

getent hosts suma.example.com
curl -I https://suma.example.com/pub/

Jeśli środowisko korzysta z domyślnej metody kontaktu Salt, klient musi również móc nawiązać wymagane połączenie Salt z menedżerem. Dokumentacja ręcznej rejestracji wiersza poleceń SUSE identyfikuje porty 4505 i 4506 do komunikacji Salt. Zobacz Rejestrowanie klientów w wierszu poleceń .

Do transferu należy użyć wewnętrznego adresu menedżera lub adresu proxy; klient nie musi mieć bezpośredniego dostępu do Internetu.

Kontrola jakości: klient rozwiązuje tę samą nazwę FQDN osadzoną w skrypcie bootstrap i może do niej dotrzeć bez konieczności korzystania z trasy publicznej. Jeśli to się nie powiedzie, przed kontynuowaniem należy naprawić DNS, zaporę sieciową, routing proxy lub zaufanie CA.

Krok 6: Skopiuj skrypt rozruchowy do odizolowanej sieci

Jeśli klient ma bezpośredni dostęp do usługi sieciowej SUSE Manager, należy pobrać skrypt rozruchowy z menedżera. Jeśli klient znajduje się w segmencie o bardziej rygorystycznym standardzie, należy przesłać plik za pomocą zatwierdzonego mechanizmu wewnętrznego, takiego jak SCP, przez hosta przeskoku lub nośnik wymienny. Sam skrypt nie eliminuje konieczności ciągłego połączenia z wewnętrznym menedżerem; obsługuje on jedynie początkową konfigurację.

curl -O https://suma.example.com/pub/bootstrap/bootstrap-sles15-offline.sh
chmod 700 bootstrap-sles15-offline.sh

W przypadku, gdy bezpośredni transfer HTTP jest zabroniony, należy zweryfikować sumę kontrolną skryptu po jego przeniesieniu przez kontrolowany proces transferu. Jest to szczególnie przydatne w środowiskach z izolacją powietrzną lub o wysokim poziomie bezpieczeństwa.

Krok 7: Uruchom skrypt rozruchowy jako root i obserwuj, czy nie występują błędy repozytorium lub certyfikatu

Uruchom skrypt lokalnie na kliencie SLES:

sudo ./bootstrap-sles15-offline.sh

Skrypt instaluje wymagane komponenty Salt, umieszcza materiał zaufania, stosuje klucz aktywacyjny i rozpoczyna proces wdrażania. Dokładne nazwy pakietów mogą się różnić w zależności od wersji SUSE Manager i SLES. Aktualna dokumentacja SUSE coraz częściej korzysta z pakietu Salt, venv-salt-miniona niektóre ścieżki rozruchowe SLES 15 mogą zaczynać się od niego salt-minion, a następnie przechodzić do niego w trakcie wdrażania.

Zamiast oceniać sukces tylko na podstawie ostatniego wiersza, obserwuj wynik bootstrapu pod kątem błędów certyfikatów, niedostępnych pakietów, niezgodności repozytoriów lub problemów z kluczami aktywacyjnymi.

Kontrola jakości: nie występują błędy w rozwiązywaniu pakietów, brak błędów zaufania TLS ani odwołań do publicznych repozytoriów, do których klient offline nie może uzyskać dostępu. Jeśli skrypt próbuje użyć nieprawidłowych repozytoriów, należy powtórzyć kroki od 1 do 4, zamiast uruchamiać go wielokrotnie.

Krok 8: Zweryfikuj klienta w Menedżerze SUSE i przetestuj ruch zarządzania

Po zakończeniu wdrażania otwórz zakładkę Systemy w SUSE Manager i znajdź nowego klienta. Sprawdź jego nazwę hosta, kanał bazowy, grupę systemową i aktualny status. System wymieniony na liście jest niezbędnym punktem kontrolnym, ale nie stanowi pełnego testu akceptacyjnego.

Rejestracja zostanie ukończona dopiero wtedy, gdy w systemie pojawi się oczekiwany przydział kanału, a klient Salt pozostanie aktywny.

Na kliencie sprawdź nazwę usługi odpowiadającą zainstalowanemu stosowi Salt:

systemctl status venv-salt-minion
# or, where applicable:
systemctl status salt-minion

Następnie wykonaj jedną czynność zarządzania o niskim ryzyku z poziomu SUSE Manager, taką jak odświeżenie danych pakietu lub wykonanie nieszkodliwego stanu/zapytania. Upewnij się, że czynność została zakończona i że klient ponownie się zamelduje.

Jak ocenić, czy rejestracja offline jest rzeczywiście prawidłowa

Typowe wzorce awarii i ich znaczenie

Skrypt nie może pobrać pakietu

Najpierw porównaj repozytorium bootstrap i mapowanie kanałów klucza aktywacyjnego z dokładną wersją SLES klienta. SUSE ostrzega, że ​​informacje o repozytorium muszą być zgodne z kanałem bazowym; w przeciwnym razie proces bootstrap nie będzie mógł pobrać prawidłowych pakietów.

Klient rejestruje się, ale operacje pakietowe kończą się niepowodzeniem

Sprawdź, czy lokalne repozytoria przetrwały z wcześniejszej konfiguracji. Proces bootstrapowy SUSE Salt został zaprojektowany z myślą o repozytoriach obsługiwanych przez SUSE Manager, a lokalnie przypisane repozytoria mogą zakłócać spójne zarządzanie kanałami. W środowisku offline wszelkie pozostałe odwołania do publicznych repozytoriów są szczególnie narażone na awarię.

Usługa Salt uruchamia się, ale system pozostaje nieaktywny

Sprawdź poprawność DNS, zasad zapory sieciowej i metody kontaktu. Jeśli standardowa łączność Salt nie jest możliwa przez granicę sieci, SUSE dokumentuje funkcję SSH Push jako alternatywę dla klientów w strefach chronionych zaporą sieciową lub w strefach odłączonych. Jest to zmiana w projekcie, a nie drobna modyfikacja bootstrapowa, więc należy jej używać, gdy model sieci tego rzeczywiście wymaga.

Skopiowany skrypt Bootstrap działał przed aktualizacją, ale teraz już nie działa

Wygeneruj go ponownie. SUSE zaleca ponowne utworzenie skryptów rozruchowych po migracjach i podczas wdrażania systemów SLE 15, które w przeciwnym razie mogłyby odziedziczyć starsze założenia Pythona.

Ograniczenia tej metody

Ta procedura nie powoduje, że zawartość SUSE Manager pojawia się magicznie w przestrzeni powietrznej. Jeśli menedżer nie może uzyskać dostępu do Centrum Obsługi Klienta SUSE, nadal potrzebny jest obsługiwany przepływ pracy dla odłączonej zawartości, taki jak tworzenie kopii lustrzanych wspomaganych przez RMT/SMT lub inny udokumentowany mechanizm synchronizacji. Skrypt bootstrapowy nie zastępuje również dostępu sieciowego między klientem a jego wewnętrznym menedżerem lub serwerem proxy po rejestracji.

Nazwy poleceń i usług mogą się różnić między generacjami SUSE Manager i pakietami serwisowymi SLES. W artykule jako punkt odniesienia wykorzystano aktualny schemat uruchamiania systemu SUSE 5.x, ale należy dopasować procedurę do dokumentacji konkretnej wersji zainstalowanej w środowisku.

Oficjalne referencje

• SUSE: Rejestracja klientów za pomocą skryptu Bootstrap
• SUSE: repozytorium Bootstrap
• SUSE: Rejestrowanie klientów w wierszu poleceń
• SUSE: Odłączona konfiguracja