Una macchina SLES 15 non necessita di accesso diretto a Internet per diventare un client gestito di SUSE Manager. Ciò di cui ha bisogno è un accesso di rete affidabile al server o al proxy interno di SUSE Manager, oltre ai canali di prodotto SLES corretti, al repository di bootstrap, alla chiave di attivazione e al materiale attendibile già presenti in tale ambiente.
Questa distinzione è importante. La "registrazione client offline" di solito significa che l'host SLES non può raggiungere SUSE Customer Center o i repository pubblici, ma può raggiungere un sistema SUSE Manager interno. Un'implementazione di SUSE Manager completamente isolata dalla rete rappresenta un problema architetturale più ampio: il contenuto del repository deve essere prima importato nell'ambiente disconnesso utilizzando metodi di mirroring supportati. SUSE documenta questo processo separatamente nella sua guida alla configurazione disconnessa .
L'obiettivo di questa procedura non è semplicemente quello di far apparire il client nell'elenco dei sistemi. Un buon risultato presenta quattro segnali visibili: l'host è registrato con la chiave di attivazione e il canale base previsti, il client Salt è in esecuzione e comunica con il gestore, i metadati dei pacchetti provengono da SUSE Manager anziché da repository pubblici e una semplice azione di gestione, come un aggiornamento o un controllo dello stato, viene completata con successo.
In questa guida, il client SLES 15 non ha accesso diretto a Internet. Può risolvere e raggiungere il server SUSE Manager interno o il proxy tramite FQDN sulla rete. Il server Manager ha già sincronizzato i contenuti SLES 15 necessari. Se il server SUSE Manager è disconnesso da Internet, preparare e sincronizzare prima tali contenuti utilizzando il flusso di lavoro per ambienti disconnessi documentato da SUSE, prima di tentare l'onboarding del client.
La documentazione client di SUSE indica inoltre che SLE 15 utilizza Python 3 per impostazione predefinita e che gli script di bootstrap creati per Python 2 devono essere rigenerati. Dopo un aggiornamento o una migrazione di SUSE Manager, si consiglia anche di rigenerare gli script di bootstrap prima di integrare nuovi sistemi. Vedere Registrazione di client con uno script di bootstrap .
Prima di intervenire sul client, verificare che SUSE Manager disponga della versione di SLES, del service pack, dell'architettura e dei moduli necessari corretti per quella macchina. Ad esempio, un host SLES 15 SP7 x86_64 non deve essere avviato con contenuti destinati a un service pack o a un'architettura diversi.
Nell'interfaccia web di SUSE Manager, verifica i canali del prodotto e lo stato di sincronizzazione. I nomi specifici dei canali variano a seconda della versione e dei moduli abilitati, quindi non copiare l'etichetta di un canale da un altro ambiente senza prima averla controllata.
Vista illustrativa del canale: verificare che la famiglia di prodotti SLES 15 e i moduli richiesti siano sincronizzati prima di creare il repository di bootstrap.
Controllo qualità: il prodotto base e tutti i canali necessari per la chiave di attivazione sono completamente sincronizzati. Se la sincronizzazione è incompleta, interrompere qui. La registrazione potrebbe funzionare parzialmente e poi fallire se non è possibile scaricare i pacchetti client necessari.
Ogni cliente necessita di accedere a un repository bootstrap contenente i pacchetti utilizzati per l'onboarding iniziale. SUSE Manager crea e rigenera automaticamente i repository bootstrap dopo la sincronizzazione dei canali di prodotto richiesti, ma è anche possibile generarne uno manualmente.
Su un server SUSE Manager 5.x containerizzato, accedere innanzitutto al container del server:
mgrctl termQuindi elenca i target del repository bootstrap disponibili:
mgr-create-bootstrap-repo -l
Utilizza l'elenco dei repository per identificare la destinazione corrispondente alla versione e all'architettura di SLES che stai integrando.
Se il repository bootstrap corrispondente non è presente o necessita di essere rigenerato, crealo:
mgr-create-bootstrap-repo -c SLE-version-x86_64SUSE documenta la posizione del repository bootstrap in /srv/www/htdocs/pub/repositories/. Se più prodotti condividono una codebase, lo strumento potrebbe richiedere di specificare il canale padre corretto. La procedura corrente è documentata nel repository Bootstrap .
Una corretta creazione del repository significa che i pacchetti iniziali di Salt e di registrazione possono essere distribuiti dall'interno della rete gestita.
Quando cambiare approccio: se il repository non può essere generato perché mancano i canali obbligatori, non tentare di aggirare l'errore copiando pacchetti RPM a caso sul client. Risolvi prima i problemi di sincronizzazione del prodotto o di importazione dei contenuti disconnessi.
Una chiave di attivazione è più di un semplice token di registrazione. Determina importanti comportamenti di onboarding, inclusi i canali software e i gruppi assegnati al client. Crea una chiave specifica per la versione di SLES e il ruolo che stai registrando.
Nell'interfaccia Web, apri la configurazione della chiave di attivazione e verifica che il canale base e i canali secondari corrispondano alla macchina SLES di destinazione. Evita di riutilizzare una chiave creata per un service pack diverso solo perché la registrazione è andata a buon fine.
La chiave di attivazione deve associare il nuovo host SLES 15 esattamente ai canali interni che si intende utilizzare.
Controllo qualità: la chiave di attivazione si risolve in un unico canale base univoco per il sistema operativo e l'architettura del client. Se la presenza di più canali padre rende la mappatura poco chiara, correggerla prima di eseguire lo script di bootstrap.
SUSE consiglia di utilizzare mgr-bootstrapper creare uno script di registrazione. In SUSE Multi-Linux Manager 5.1, i due argomenti obbligatori sono --activation-keyse --script.
mgrctl term
mgr-bootstrap --activation-keys=<ACTIVATION_KEY> --script=bootstrap-sles15-offline.shLo script generato può essere creato anche dall'interfaccia utente web in Amministrazione > Configurazione gestore > Script di bootstrap . Per una configurazione basata su proxy, è consigliabile generare lo script per il FQDN del proxy anziché modificare in seguito i riferimenti al server in modo automatico.
Genera un nuovo script associato alla chiave di attivazione e al server o proxy che il client offline può effettivamente raggiungere.
Mantieni SSL abilitato. SUSE sconsiglia esplicitamente di disabilitare SSL nella configurazione di bootstrap. In una rete isolata, la fiducia nel certificato rimane importante perché il client deve verificare di comunicare con il sistema di gestione previsto.
Prima di eseguire lo script, testa il percorso interno da SLES 15 a SUSE Manager. I controlli specifici dipendono dalla topologia, ma come minimo verifica la risoluzione DNS e la raggiungibilità HTTPS del manager o del FQDN del proxy utilizzato dallo script.
getent hosts suma.example.com
curl -I https://suma.example.com/pub/Se l'ambiente utilizza il metodo di contatto Salt predefinito, il client deve essere in grado di stabilire la connessione Salt necessaria con il gestore. La documentazione di SUSE relativa alla registrazione manuale da riga di comando identifica le porte 4505 e 4506 per la comunicazione con Salt. Vedere Registrazione dei client da riga di comando .
La fase di trasferimento deve utilizzare il gestore interno o l'indirizzo proxy; per il client non è necessario l'accesso diretto a Internet.
Controllo di qualità: il client risolve lo stesso FQDN incorporato nello script di bootstrap e riesce a raggiungerlo senza ricorrere a un percorso pubblico. In caso di errore, correggere DNS, firewall, routing proxy o attendibilità CA prima di continuare.
Se il client può accedere direttamente al servizio web di SUSE Manager, scaricare lo script di bootstrap dal gestore. Se il client si trova in un segmento con restrizioni più severe, trasferire il file tramite un meccanismo interno approvato, come SCP, attraverso un jump host o un supporto rimovibile. Lo script in sé non elimina la necessità di una connessione continua al gestore interno; gestisce solo la configurazione iniziale.
curl -O https://suma.example.com/pub/bootstrap/bootstrap-sles15-offline.sh
chmod 700 bootstrap-sles15-offline.shLaddove il trasferimento HTTP diretto sia proibito, verificare il checksum dello script dopo averlo trasferito tramite il processo di trasferimento controllato. Ciò è particolarmente utile in ambienti isolati dalla rete o ad alta affidabilità.
Eseguire lo script localmente sul client SLES:
sudo ./bootstrap-sles15-offline.shLo script installa i componenti Salt necessari, posiziona il materiale di fiducia, applica la chiave di attivazione e avvia il processo di onboarding. I nomi esatti dei pacchetti possono variare a seconda di SUSE Manager e della versione di SLES. La documentazione SUSE attuale utilizza sempre più spesso il Salt Bundle, venv-salt-minionmentre alcuni percorsi di bootstrap di SLES 15 possono iniziare con salt-minione poi passare a durante l'onboarding.
Controlla l'output di bootstrap per individuare errori relativi ai certificati, pacchetti non disponibili, incongruenze nei repository o problemi con le chiavi di attivazione, invece di giudicare il successo solo dall'ultima riga.
Controllo qualità: non sono presenti errori di risoluzione dei pacchetti, errori di attendibilità TLS e riferimenti a repository pubblici irraggiungibili per il client offline. Se lo script tenta di utilizzare repository errati, rivedere i passaggi da 1 a 4 anziché eseguirlo ripetutamente.
Una volta completata la fase di onboarding, apri la sezione Sistemi in SUSE Manager e individua il nuovo client. Verifica il nome host, il canale base, il gruppo di sistema e lo stato corrente. La presenza di un sistema nell'elenco è un controllo necessario, ma non rappresenta l'intero test di accettazione.
La registrazione è completa solo quando il sistema viene visualizzato con l'assegnazione del canale prevista e il client Salt rimane attivo.
Sul client, verifica che il nome del servizio corrisponda allo stack Salt installato:
systemctl status venv-salt-minion
# or, where applicable:
systemctl status salt-minionSuccessivamente, esegui un'azione di gestione a basso rischio da SUSE Manager, come l'aggiornamento dei dati dei pacchetti o l'esecuzione di uno stato/query innocuo. Verifica che l'azione venga completata e che il client si connetta nuovamente in seguito.
| Controllo | Buon risultato | Motivo per fermarsi e riparare |
|---|---|---|
| Contenuto del prodotto | Il service pack, l'architettura e i moduli di SLES 15 corretti sono sincronizzati internamente | Canali del service pack mancanti o misti |
| Repository Bootstrap | Generato per il target di prodotto corretto | La creazione non riesce o il canale padre è ambiguo |
| Chiave di attivazione | Assegna i canali base e figlio previsti | Punti chiave per un altro ruolo o versione del sistema operativo |
| Percorso di rete | Il cliente risolve e raggiunge il FQDN del Manager/Proxy internamente | È necessario un DNS pubblico o un percorso Internet |
| TLS | Nessun errore di convalida del certificato | SSL disabilitato o catena di fiducia non risolta |
| Sale | Il servizio Salt Bundle/minion rimane attivo e le azioni di gestione vengono completate. | Il cliente si presenta una sola volta ma non riesce a effettuare il check-in in seguito. |
Innanzitutto, confrontate la mappatura del repository di bootstrap e del canale della chiave di attivazione con la versione esatta di SLES del client. SUSE avverte che le informazioni del repository devono corrispondere al canale base; in caso contrario, il processo di bootstrap non sarà in grado di recuperare i pacchetti corretti.
Verifica se i repository locali sono sopravvissuti da una configurazione precedente. Il processo di bootstrap di Salt di SUSE è progettato per i repository gestiti da SUSE Manager e i repository assegnati localmente possono interferire con la gestione coerente dei canali. In un ambiente offline, è particolarmente probabile che i riferimenti a repository pubblici rimanenti non funzionino.
Convalidare DNS, policy del firewall e metodo di contatto. Se la connettività Salt standard non è possibile attraverso il confine di rete, SUSE documenta SSH Push come alternativa per i client in zone protette da firewall o disconnesse. Si tratta di una modifica di progettazione, non di una semplice modifica di avvio, quindi utilizzarla solo quando il modello di rete lo richiede effettivamente.
Rigeneralo. SUSE consiglia di ricreare gli script di bootstrap dopo le migrazioni e durante l'integrazione di sistemi SLE 15 che altrimenti potrebbero ereditare presupposti Python precedenti.
Questa procedura non fa apparire magicamente il contenuto di SUSE Manager in un ambiente isolato. Se il gestore non può accedere a SUSE Customer Center, è comunque necessario un flusso di lavoro per contenuti disconnessi supportato, come il mirroring assistito da RMT/SMT o un altro schema di sincronizzazione documentato. Lo script di bootstrap, inoltre, non sostituisce l'accesso di rete tra il client e il suo Manager o Proxy interno dopo la registrazione.
Infine, i comandi e i nomi dei servizi possono variare tra le diverse generazioni di SUSE Manager e i service pack di SLES. L'articolo utilizza come riferimento il flusso di lavoro di bootstrap corrente di SUSE 5.x, ma è necessario adattare la procedura alla documentazione specifica della versione installata nel proprio ambiente.
Gioca a GTA: Vice City su Linux usando Steam e Proton. Installa la Definitive Edition, abilita la compatibilità, avviala e risolvi i problemi più comuni di Proton.
Scopri come giocare a The Sims 4 su Linux tramite Steam Play e Proton, collegare il tuo account EA e risolvere i problemi di avvio più comuni.
Scopri come ridimensionare in modo sicuro una partizione /home separata su Linux con GParted Live, incluse informazioni su backup, limiti del filesystem e passaggi per ridurla o espanderla.
È possibile eseguire VRChat su Linux con Steam e Proton Experimental. Seguite la procedura di configurazione attuale, le note di Steam Deck e le soluzioni per i problemi di avvio e video.
Scopri come avviare Sea of Thieves su Linux tramite Steam e Proton, collegare il tuo account Xbox e risolvere i problemi più comuni di avvio o quelli relativi a Easy Anti-Cheat.
Formattare un'unità USB in FAT32 su Linux con GNOME Disks o mkfs.fat, includendo controlli di sicurezza del dispositivo, smontaggio, verifica e limiti di FAT32.
Installa Google Earth Pro su Linux con i pacchetti ufficiali DEB e RPM a 64 bit, oltre ai comandi per Ubuntu, Debian, Fedora e openSUSE.
Impara a creare directory Linux da Bash con mkdir, inclusi percorsi annidati, cartelle multiple, nomi con spazi, permessi, verifica e rimozione sicura.
Convertire un eBook PDF in EPUB su Linux con Calibre: installazione, impostazioni di conversione, passaggi per l'esportazione e limitazioni comuni dei file PDF.
Gioca al classico GTA III su Linux con Steam Proton. Installa Steam, abilita la compatibilità, scegli Proton, avvia il gioco e risolvi i problemi di avvio più comuni.
