Cum se înregistrează o mașină SLES 15 în SUSE Manager offline

O mașină SLES 15 nu necesită acces direct la internet pentru a deveni un client SUSE Manager gestionat. Ceea ce are nevoie este acces fiabil la rețea la serverul sau proxy-ul intern SUSE Manager, plus canalele de produs SLES corecte, depozitul de bootstrap, cheia de activare și materialul de încredere deja disponibile în mediul respectiv.

Această distincție este importantă. „Înregistrarea clientului offline” înseamnă de obicei că gazda SLES nu poate ajunge la Centrul pentru clienți SUSE sau la depozitele publice, dar poate ajunge la un sistem SUSE Manager intern. O implementare SUSE Manager complet izolată reprezintă o problemă arhitecturală mai mare: conținutul depozitului trebuie mai întâi importat în mediul deconectat folosind metodele de oglindire acceptate. SUSE documentează acest lucru separat în ghidul său de configurare deconectată .

Scopul acestei proceduri nu este doar de a face clientul să apară în lista Sisteme. Un rezultat bun are patru semne vizibile: gazda este înregistrată sub cheia de activare și canalul de bază dorite, clientul Salt rulează și comunică cu managerul, metadatele pachetului provin din SUSE Manager și nu din repozitorii publice și o acțiune simplă de gestionare, cum ar fi o reîmprospătare sau o verificare a stării, se finalizează cu succes.

Ce ar trebui să însemne „offline” înainte de a începe

Pentru acest ghid, clientul SLES 15 nu are acces direct la internet. Acesta poate rezolva și accesa serverul sau proxy-ul intern SUSE Manager prin FQDN prin rețea. Managerul are deja sincronizat conținutul SLES 15 necesar. Dacă serverul SUSE Manager este deconectat de la internet, pregătiți și sincronizați mai întâi conținutul respectiv utilizând fluxul de lucru documentat pentru deconectare al SUSE înainte de a încerca integrarea clientului.

Documentația actuală a clientului SUSE menționează, de asemenea, că SLE 15 utilizează Python 3 în mod implicit și că scripturile bootstrap create pentru Python 2 ar trebui regenerate. După o actualizare sau o migrare SUSE Manager, regenerarea scripturilor bootstrap este, de asemenea, recomandată înainte de integrarea noilor sisteme. Consultați Înregistrarea clienților cu un script Bootstrap .

Pasul 1: Verificați dacă sunt sincronizate canalele SLES corecte

Înainte de a accesa clientul, confirmați dacă SUSE Manager are versiunea SLES exactă, service pack-ul, arhitectura și modulele necesare pentru mașina respectivă. De exemplu, o gazdă SLES 15 SP7 x86_64 nu ar trebui să fie bootată pentru conținut destinat unui service pack sau unei arhitecturi diferite.

În interfața web SUSE Manager, examinați canalele produsului și starea de sincronizare. Numele specifice ale canalelor variază în funcție de versiune și de modulele activate, așadar nu copiați o etichetă de canal dintr-un alt mediu fără a o verifica.

Vizualizare ilustrativă a canalului: confirmați că familia de produse SLES 15 și modulele necesare sunt sincronizate înainte de a crea depozitul bootstrap.

Verificare a calității: produsul de bază și toate canalele necesare cheii dvs. de activare sunt complet sincronizate. Dacă sincronizarea este incompletă, opriți-vă aici. Înregistrarea poate funcționa parțial și apoi poate eșua atunci când pachetele client necesare nu pot fi descărcate.

Pasul 2: Confirmați sau generați depozitul bootstrap

Fiecare client are nevoie de acces la un depozit bootstrap care conține pachetele utilizate pentru integrarea inițială. În mod normal, SUSE Manager creează și regenerează automat depozitele bootstrap după sincronizarea canalelor de produs necesare, dar puteți genera unul și manual.

Pe un server SUSE Manager 5.x containerizat, introduceți mai întâi containerul serverului:

mgrctl term

Apoi, listați țintele disponibile pentru repozitoriul bootstrap:

mgr-create-bootstrap-repo -l

Folosește lista de repozitorii pentru a identifica ținta care corespunde versiunii SLES și arhitecturii pe care o integrezi.

Creați depozitul bootstrap corespunzător dacă lipsește sau necesită regenerare:

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

SUSE documentează locația depozitului bootstrap în /srv/www/htdocs/pub/repositories/. Dacă mai multe produse partajează aceeași bază de cod, instrumentul vă poate solicita să specificați canalul părinte corect. Procedura curentă este documentată în depozitul Bootstrap .

O construire reușită a repozitoriului înseamnă că pachetele inițiale Salt și de înregistrare pot fi servite din interiorul rețelei gestionate.

Când se schimbă abordarea: dacă depozitul nu poate fi generat din cauza lipsei canalelor obligatorii, nu încercați să ocoliți eroarea prin copierea RPM-urilor aleatorii pe client. Remediați mai întâi sincronizarea produsului sau importul de conținut deconectat.

Pasul 3: Creați o cheie de activare cu alocarea canalului dorită

O cheie de activare este mai mult decât un token de înregistrare. Aceasta determină comportamentul important la integrare, inclusiv canalele și grupurile software atribuite clientului. Creați o cheie specială pentru versiunea SLES și rolul pe care le înregistrați.

În interfața web, deschideți configurația cheii de activare și verificați dacă canalul de bază și canalele secundare corespund cu mașina SLES țintă. Evitați reutilizarea unei chei create pentru un alt pachet service pack doar pentru că înregistrarea în sine a reușit.

Cheia de activare ar trebui să mapeze noua gazdă SLES 15 la canalele interne exacte pe care intenționați să le consume.

Verificare a calității: cheia de activare se rezolvă într-un canal de bază neechivoc pentru sistemul de operare și arhitectura clientului. Dacă mai multe canale părinte fac maparea neclară, corectați acest lucru înainte de a rula scriptul bootstrap.

Pasul 4: Generați un script bootstrap nou

SUSE recomandă utilizarea mgr-bootstrappentru a crea un script de înregistrare. În SUSE Multi-Linux Manager 5.1, cele două argumente obligatorii sunt --activation-keysși --script.

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

Scriptul generat poate fi creat și din interfața web, în ​​Admin > Manager Configuration > Bootstrap Script . Pentru un design bazat pe proxy, generați scriptul pentru FQDN-ul proxy, în loc să editați ulterior în mod silențios referințele serverului.

Generați un script nou legat de cheia de activare și de serverul sau proxy-ul pe care clientul offline îl poate accesa.

Mențineți SSL activat. SUSE avertizează explicit împotriva dezactivării SSL în configurația bootstrap. Într-o rețea izolată, încrederea în certificate este încă importantă, deoarece clientul trebuie să verifice dacă comunică cu sistemul de gestionare dorit.

Pasul 5: Testați rezoluția numelui, rutarea și accesibilitatea certificatului de la client

Înainte de a executa scriptul, testați calea internă de la SLES 15 la SUSE Manager. Verificările exacte depind de topologia dvs., dar verificați cel puțin rezoluția DNS și accesibilitatea HTTPS la manager sau la proxy FQDN utilizat de script.

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

Dacă mediul utilizează metoda implicită de contact Salt, clientul trebuie să poată stabili și conexiunea Salt necesară la manager. Documentația manuală de înregistrare a liniei de comandă SUSE identifică porturile 4505 și 4506 pentru comunicarea Salt. Consultați Înregistrarea clienților pe linia de comandă .

Pasul de transfer ar trebui să utilizeze managerul intern sau adresa proxy; accesul direct la internet nu este necesar pentru client.

Verificare a calității: clientul rezolvă același FQDN încorporat în scriptul bootstrap și îl poate accesa fără a reveni la o rută publică. Dacă această acțiune eșuează, remediați problemele DNS, firewall-ului, rutarii proxy sau încrederii CA înainte de a continua.

Pasul 6: Copiați scriptul bootstrap în rețeaua izolată

Dacă clientul poate accesa direct serviciul web SUSE Manager, descărcați scriptul bootstrap din manager. Dacă clientul se află într-un segment mai strict, transferați fișierul printr-un mecanism intern aprobat, cum ar fi SCP, printr-o gazdă de salt sau un suport media amovibil. Scriptul în sine nu elimină necesitatea conectivității continue la managerul intern; acesta se ocupă doar de configurarea inițială.

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

Acolo unde transferul direct HTTP este interzis, verificați suma de control a scriptului după ce îl treceți prin procesul de transfer controlat. Acest lucru este util în special în mediile cu spații închise sau cu grad ridicat de siguranță.

Pasul 7: Rulați scriptul bootstrap ca root și urmăriți erorile de repozitoriu sau certificat

Executați scriptul local pe clientul SLES:

sudo ./bootstrap-sles15-offline.sh

Scriptul instalează componentele Salt necesare, plasează materialul de încredere, aplică cheia de activare și pornește procesul de onboarding. Numele exacte ale pachetelor pot diferi în funcție de versiunea SUSE Manager și SLES. Documentația actuală SUSE utilizează din ce în ce mai mult Salt Bundle, venv-salt-minion, în timp ce unele căi de bootstrap SLES 15 pot începe cu salt-minionși apoi pot face tranziția în timpul onboarding-ului.

Urmăriți ieșirea bootstrap pentru erori de certificat, pachete indisponibile, nepotriviri de repozitoriu sau probleme legate de cheia de activare, în loc să judecați succesul doar după ultima linie.

Verificare a calității: nu există erori de rezoluție a pachetului, nicio eroare de încredere TLS și nicio referință la depozite publice pe care clientul offline nu le poate accesa. Dacă scriptul încearcă să utilizeze depozite incorecte, reluați pașii 1-4 în loc să îl rulați în mod repetat.

Pasul 8: Verificați clientul în SUSE Manager și testați traficul de gestionare

După finalizarea integrării, deschideți Systems în SUSE Manager și găsiți noul client. Verificați numele gazdei, canalul de bază, grupul de sisteme și starea curentă. Un sistem listat este un punct de control necesar, dar nu reprezintă întregul test de acceptare.

Înregistrarea este completă numai atunci când sistemul apare cu alocarea de canal așteptată și clientul Salt rămâne activ.

Pe client, verificați numele serviciului care corespunde cu stiva Salt instalată:

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

Apoi, efectuați o acțiune de gestionare cu risc scăzut din SUSE Manager, cum ar fi actualizarea datelor pachetului sau executarea unei stări/interogări inofensive. Confirmați că acțiunea este finalizată și că clientul se conectează din nou ulterior.

Cum să evaluezi dacă înregistrarea offline este într-adevăr bună

Modele comune de eșec și ce înseamnă acestea de obicei

Scriptul nu poate descărca un pachet

Mai întâi comparați maparea canalului din depozitul bootstrap și a cheii de activare cu versiunea exactă SLES a clientului. SUSE avertizează că informațiile din depozit trebuie să corespundă cu canalul de bază; altfel, procesul bootstrap nu poate prelua pachetele corecte.

Clientul se înregistrează, dar operațiunile cu pachetul eșuează

Verificați dacă depozitele locale au supraviețuit dintr-o configurație anterioară. Procesul de bootstrap Salt al SUSE este conceput în jurul depozitelor deservite de SUSE Manager, iar depozitele atribuite local pot interfera cu gestionarea consistentă a canalelor. Într-un mediu offline, orice referințe rămase la depozite publice sunt deosebit de susceptibile de a eșua.

Serviciul Salt pornește, dar sistemul rămâne inactiv

Validați DNS, politica firewall și metoda de contact. Dacă conectivitatea Salt standard nu este posibilă peste granița rețelei, SUSE documentează SSH Push ca alternativă pentru clienții din zonele protejate prin firewall sau deconectate. Aceasta este o modificare de design, nu o modificare minoră de tip bootstrap, așa că folosiți-o atunci când modelul de rețea o necesită cu adevărat.

Un script bootstrap copiat funcționa înainte de o actualizare, dar nu mai funcționează.

Regenerați-l. SUSE recomandă recrearea scripturilor de bootstrap după migrări și la implementarea sistemelor SLE 15 care altfel ar putea moșteni presupuneri Python mai vechi.

Limitele acestei metode

Această procedură nu face ca conținutul SUSE Manager să apară în mod magic într-un spațiu liber. Dacă managerul nu poate accesa Centrul pentru clienți SUSE, aveți nevoie în continuare de un flux de lucru pentru conținut deconectat acceptat, cum ar fi oglindirea asistată de RMT/SMT sau un alt design de sincronizare documentat. Scriptul bootstrap nu înlocuiește nici accesul la rețea dintre client și Managerul sau Proxy-ul său intern după înregistrare.

În cele din urmă, comenzile și numele serviciilor pot diferi între generațiile SUSE Manager și pachetele service pack SLES. Articolul folosește fluxul de lucru actual de bootstrap SUSE 5.x ca punct de referință, dar ar trebui să potriviți procedura cu documentația pentru versiunea exactă instalată în mediul dvs.

Referințe oficiale

• SUSE: Înregistrarea clienților cu un script Bootstrap
• SUSE: Depozit Bootstrap
• SUSE: Înregistrarea clienților în linia de comandă
• SUSE: Configurare deconectată