È possibile registrare un client SLES 15 senza fornirgli accesso diretto a Internet, a condizione che possa comunque raggiungere il server o il proxy SUSE Manager sulla rete privata. Preparare i repository software e di bootstrap corrispondenti sul Manager, creare una chiave di attivazione e quindi eseguire lo script di bootstrap sulla macchina SLES. Un client senza un percorso di rete verso il Manager non può completare la registrazione o il check-in di Salt; la semplice copia di uno script tramite USB non è sufficiente a rendere la procedura gestibile.
Esempio ipotetico: un amministratore sta installando una nuova macchina virtuale SLES 15 SP7 x86_64 in una rete aziendale senza accesso a Internet. Anche SUSE Multi-Linux Manager 5.1, il nome con cui viene attualmente chiamato SUSE Manager in questa guida, è disconnesso da Internet. I suoi canali software sono stati replicati nell'ambiente tramite supporti rimovibili. La macchina virtuale può raggiungere il Manager interno tramite HTTPS e porte Salt. Questo scenario è puramente illustrativo e non rappresenta una configurazione o un test reali.
"Offline" può significare che il client e il Manager non hanno accesso diretto a Internet, oppure che il client non può raggiungere alcun server. La prima configurazione supporta la registrazione; la seconda no. Il client necessita di un percorso interno verso il Manager o un proxy di SUSE Multi-Linux Manager, e il Manager necessita di pacchetti e metadati disponibili localmente per il client.
Se il Manager è disconnesso da SUSE Customer Center, la configurazione documentata da SUSE utilizza RMT o SMT e storage rimovibile per replicare i repository. Per SLES 15, sincronizzare il prodotto e i canali client-tools del Manager necessari per l'architettura client. Assicurarsi quindi che il repository bootstrap corrispondente sia presente sul Manager. Nell'interfaccia Web, la selezione del prodotto si trova in Admin > Setup Wizard > Products. La sincronizzazione del prodotto deve essere completata prima del bootstrap; se il repository bootstrap non è presente, la documentazione del Manager fornisce mgr-create-bootstrap-repoun'opzione per la creazione manuale.
Per la macchina virtuale ipotetica, prima di selezionare i canali, verificare il service pack e l'architettura di SLES. Una macchina SLES 15 SP7 x86_64 richiede il prodotto corrispondente, non un canale con un nome simile per un altro service pack o architettura. L'elenco dei prodotti supportati e i nomi dei canali possono variare tra le diverse versioni di SUSE Multi-Linux Manager, quindi fare riferimento alla guida relativa alla versione di Manager effettivamente installata.
Una chiave di attivazione applica l'assegnazione del canale e altre impostazioni di registrazione all'esecuzione dello script di bootstrap. Nell'interfaccia utente Web di Manager, apri Systems > Activation Keyse crea una chiave come sles15-sp7-offline. Seleziona il canale base SLES 15 SP7 x86_64 e i canali figlio richiesti per la tua sottoscrizione e la configurazione degli strumenti client. Evita il canale padre predefinito quando puoi assegnare un canale SLES specifico.
Prima di procedere, verificare che la chiave appartenga all'organizzazione corretta e che i canali necessari siano disponibili localmente. Le chiavi possono anche essere applicate a gruppi, configurazioni, pacchetti o un metodo di contatto; esaminare attentamente le impostazioni aggiuntive per evitare che la registrazione attivi il download di pacchetti o la modifica della configurazione inaspettati.
Sul server host di SUSE Multi-Linux Manager, accedi al container del server e crea uno script associato alla chiave di attivazione:
mgrctl term
mgr-bootstrap --activation-keys=sles15-sp7-offline --script=bootstrap-sles15-offline.shLo script di bootstrap è memorizzato nella /srv/www/htdocs/pub/bootstrap/directory del Manager. Mantenere SSL abilitato nello script. Nella rete di esempio, la VM SLES può recuperare lo script tramite HTTPS interno. Se è necessario trasferire lo script nel segmento isolato su un supporto rimovibile approvato, copiarlo da tale directory utilizzando la procedura di trasferimento controllata dell'organizzazione. Confrontare il checksum SHA-256 calcolato su entrambi i lati prima di eseguirlo e proteggere lo script come dati di configurazione poiché contiene la chiave di attivazione.
Non trasferire solo lo script di bootstrap e presumere che il client sia autonomo. Lo script installa le dipendenze di registrazione dal repository di bootstrap del Manager. Tali pacchetti RPM e i canali software devono essere già sincronizzati sul Manager disconnesso.
Sulla macchina SLES, verificare che l'orologio sia sincronizzato con quello del Manager e che il DNS interno risolva correttamente il nome del Manager:
timedatectl
getent hosts manager.example.netSostituire manager.example.netcon il FQDN del Manager o del Proxy incorporato nello script. I requisiti del client SUSE Multi-Linux Manager 5.1 includono l'accesso in uscita dal client al Manager o al Proxy sulla porta HTTPS 443 e sulle porte TCP 4505 e 4506 per Salt. La porta 80 può essere utilizzata anche da una distribuzione. La porta SSH 22 è rilevante quando si utilizza un metodo di contatto SSH push. Utilizzare la guida ai requisiti di rete corrente per la propria distribuzione e la configurazione del firewall; non esporre queste porte a Internet pubblico.
Con lo script sul client e i repository interni accessibili, eseguilo come root usando Bash:
bash ./bootstrap-sles15-offline.sh
La registrazione potrebbe richiedere del tempo, poiché il client sta installando il componente Salt e scaricando la configurazione del repository. Non interrompere il processo solo perché non è attivo. In caso di errore, conserva l'output esatto e controlla i log di bootstrap e Salt del client, il repository di bootstrap del Manager, il DNS, la fiducia nei certificati e il percorso del firewall prima di riprovare.
Nell'interfaccia Web di Manager, verifica Systems > Overviewla presenza del nuovo client. Se non è presente, aprilo Salt > Keyse cerca la chiave in sospeso del client. Prima di accettarlo, conferma che l'ID minion e l'identità della macchina corrispondano alla VM SLES. Una registrazione riuscita dovrebbe lasciare il sistema nell'elenco, la sua chiave Salt accettata e un check-in recente visibile.
Se la VM non ha un percorso verso il Manager, interrompere l'operazione dopo aver predisposto lo script e i pacchetti: la registrazione non può essere completata finché non viene fornito un percorso di rete controllato. Se in precedenza era registrata direttamente con SCC, SMT o RMT, seguire le istruzioni di migrazione client di SUSE per eliminare la vecchia registrazione e i repository prima di passare alla gestione; non lasciare configurazioni di repository in conflitto.
Questa procedura segue la documentazione di SUSE Multi-Linux Manager 5.1 per l'installazione disconnessa , i client SUSE Linux Enterprise , le chiavi di attivazione e la registrazione dei client tramite uno script di bootstrap . Verificare i requisiti di rete per la direzione delle porte e i dettagli specifici della versione. SLES 15 SP7 viene utilizzato come esempio; selezionare canali e script diversi per altri service pack, architetture o versioni di Manager.
Verifica se Btrfs è intenzionalmente di sola lettura, se ha poco spazio disponibile o se protegge i dati dopo gli errori, quindi scegli un percorso di ripristino adeguato alla causa.
Preparare canali mirror, creare una chiave di attivazione e avviare un client SLES 15 senza accesso diretto a Internet, preservando al contempo la connessione necessaria per i check-in dei manager.
Risolvi l'errore di avvio di YaST in XIO tramite SSH, verifica l'inoltro X11 e l'autenticazione xauth e passa all'interfaccia ncurses quando una finestra remota non è necessaria.
Trova lo snapshot di Btrfs precedente all'aggiornamento, testalo in sola lettura e rendi il ripristino permanente con Snapper, comprendendo quali dati rimangono al di fuori del rollback della partizione root.
Invio dei log di sistema SLES a un collettore rsyslog remoto tramite TLS autenticato, con verifica dei certificati, buffering in caso di interruzione del servizio e test di consegna.
Utilizza i log di RAM, swap, kernel e Zypper per identificare la reale pressione sulla memoria, proteggere lo stato dei pacchetti e scegliere un tentativo di aggiornamento SLES più sicuro.
Abilita gli aggiornamenti di sicurezza automatici di Debian tramite SSH, mantieni le sorgenti predefinite dei pacchetti e verifica le esecuzioni pianificate tramite i log di systemd e APT.
Confronta le opzioni di consegna della posta, configura smartd su Ubuntu e verifica che gli avvisi sullo stato del disco vengano recapitati nella tua casella di posta.
Ripristina le ricerche DNS su Debian 12 controllando systemd-resolved, riparando resolv.conf quando necessario e verificando la risoluzione DNS upstream e quella dell'applicazione.
Fai in modo che Ubuntu rilevi il monitor o la TV come uscita audio, selezionalo nelle impostazioni audio e controlla la connessione o l'elenco dei dispositivi PipeWire se l'HDMI non è presente.
