Creare un server di aggiornamento SUSE locale con RMT su SLES 15

Per un nuovo server locale di sottoscrizione e aggiornamento SUSE, installa Repository Mirroring Tool (RMT) su un host SLES 15 supportato, configuralo con YaST, abilita i prodotti utilizzati dalla tua organizzazione ed esegui il mirroring dei relativi repository. Registra un client di test tramite l'URL HTTPS del server prima di indirizzare i sistemi di produzione a tale server. RMT sostituisce SMT per SLES 15; un'installazione SMT precedente non è il punto di partenza corretto per una nuova implementazione.

Questa architettura si adatta a un ambiente in cui un server si connette al SUSE Customer Center (SCC) e gli altri sistemi SUSE ricevono la registrazione e i pacchetti tramite un endpoint locale. Può ridurre i download esterni ripetuti, ma non fornisce diritti di abbonamento: sono comunque necessari abbonamenti aziendali validi e credenziali di mirroring SCC.

Conferma la piattaforma e pianifica il server

La guida di SLES 15 SP7 Repository Mirroring Tool (RMT) afferma che RMT supporta i client SLES 12 e versioni successive, ma non SLES 11 o versioni precedenti. RMT si differenzia da SMT anche per funzionalità quali la gestione degli ambienti di staging e la creazione di report. La migrazione va considerata come una modifica del servizio, non come un aggiornamento del pacchetto in loco; SUSE consiglia di installare RMT su un nuovo host SLES 15 durante la migrazione da SMT.

Assegna un nome di dominio completo (FQDN) stabile, ad esempio rmt.example.com, e un indirizzo statico. Assicurati che il DNS si risolva in modo coerente e che l'host possa raggiungere i servizi di aggiornamento SCC e SUSE tramite le porte in uscita 80 e 443. I client necessitano di accesso alla rete per il servizio RMT tramite HTTPS. Utilizza lo stesso FQDN nell'URL del client e nel certificato del server.

Pianifica lo spazio di archiviazione in base alle release, alle architetture, ai prodotti e ai repository che intendi replicare. La guida di SUSE SP7 fornisce una stima generale di circa 1,5 volte la dimensione totale dei repository abilitati, ovvero circa 200 GB per ogni release di SLES, incluse le estensioni. Si tratta di una stima, non di una garanzia di capacità; verifica le dimensioni attuali dei repository e lascia spazio per la crescita. RMT scrive anche file temporanei di grandi dimensioni /tmp, quindi assicurati che il filesystem disponga di spazio libero sufficiente. Non configurare lo stesso host come server di installazione di SLES: RMT configura NGINX sulla porta 80, mentre il ruolo del server di installazione configura Apache sulla stessa porta.

Installa il pacchetto RMT e configura YaST

Su un server SLES 15 aggiornato e registrato, installare RMT:

sudo zypper patch
sudo zypper in rmt-server

Esamina le modifiche al pacchetto e completa l'installazione. Avvia la configurazione iniziale:

sudo yast2 rmt

Inserisci le credenziali dell'organizzazione SCC utilizzate per il mirroring del repository. Si tratta delle credenziali proxy dell'organizzazione in SUSE Customer Center, non di un codice di registrazione client. Crea il database e l'utente MariaDB richiesti dalla procedura guidata. Imposta il nome comune del certificato sul FQDN del server e aggiungi eventuali altri nomi che i client utilizzeranno come nomi alternativi. Se firewalld è abilitato, seleziona le regole RMT necessarie e, ove possibile, estendile all'interfaccia di rete pertinente del server. Completa la procedura guidata; YaST abilita e avvia i servizi e i timer necessari.

YaST memorizza il certificato CA RMT in /etc/rmt/ssl/rmt-ca.crte il certificato e la chiave del server in /etc/rmt/ssl/. Proteggi la chiave privata. Distribuisci la fiducia per la CA utilizzando il tuo processo approvato. Un server che risponde tramite HTTPS può comunque non riuscire a registrare il client se il nome del suo certificato non corrisponde al nome host richiesto o se la sua CA non è considerata attendibile.

Sincronizza i metadati, abilita i prodotti e replica

Aggiorna il catalogo locale da SCC e controlla i prodotti disponibili:

sudo rmt-cli sync
sudo rmt-cli products list --all

Abilita un prodotto tramite il suo ID o la stringa prodotto mostrata nell'output. Le stringhe prodotto variano a seconda della versione e dell'architettura, quindi utilizza un valore dal tuo server anziché copiare un identificatore ipotizzato:

sudo rmt-cli products enable PRODUCT_STRING
sudo rmt-cli products list

L'attivazione di un prodotto seleziona i repository associati. Limita la selezione ai sistemi che intendi supportare: ogni nuova versione e architettura consuma spazio di archiviazione e aggiunge lavoro di sincronizzazione. Avvia il download iniziale del pacchetto con:

sudo rmt-cli mirror

La fase iniziale di mirroring può richiedere molto tempo. RMT di solito pianifica la sincronizzazione dei metadati e il mirroring del repository tramite timer di systemd. Verifica che entrambe le pianificazioni siano attive:

systemctl status rmt-server-sync.timer
systemctl status rmt-server-mirror.timer

Utilizzare rmt-cli products liste rmt-cli repos listper confermare che le voci previste siano abilitate e mostrare l'attività recente dei mirror. Se i repository non sono presenti, verificare le credenziali SCC, i diritti di sottoscrizione, la connettività in uscita, lo spazio su disco (incluso /tmp) e l'output dei comandi prima di riavviare ripetutamente i servizi.

Registra un client di prova e verifica gli aggiornamenti

Su un sistema di test SLES 12 o successivo, puntare SUSEConnect al server RMT:

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

Sostituisci il tuo FQDN effettivo e assicurati che sia incluso nel certificato. Se il client richiede di considerare attendibile l'autorità di certificazione RMT, verifica il certificato tramite il canale approvato dalla tua organizzazione prima di accettarlo. Non aggirare un'eventuale discrepanza di nome disabilitando i controlli del certificato. Quindi, controlla i repository configurati e aggiorna i metadati:

sudo zypper lr -u
sudo zypper refresh

Un risultato positivo indica che i repository basati su RMT previsti sono abilitati e che l'aggiornamento dei metadati è stato completato. Sul server, verificare che il client sia presente in sudo rmt-cli systems list. Se la registrazione non riesce, controllare DNS e routing, raggiungibilità HTTPS, attendibilità del certificato e corrispondenza del nome host, ambito del firewall e se il prodotto è abilitato e replicato. Esaminare l'output del comando e i log del servizio prima di modificare la configurazione condivisa.

Installare il pacchetto RMT sull'host SLES 15 predisposto.

Prima di applicare la configurazione di YaST, verificare le impostazioni di SCC, del database, del certificato FQDN e del firewall.

Aggiorna il catalogo prodotti e controlla le stringhe prodotto disponibili per la replica.

Avvia il mirroring del repository e registra un client di test con il nome host HTTPS del server.

Conosci i tuoi limiti e scegli un'altra strada quando necessario.

Utilizza SUSE Multi-Linux Manager o un altro servizio di gestione del ciclo di vita supportato se necessiti di funzionalità non offerte da RMT, come una gestione client più ampia, la creazione di report o flussi di lavoro di contenuti a fasi. Mantieni SMT solo laddove i client SLES 11 legacy o comportamenti specifici di SMT siano ancora requisiti e testa la migrazione separatamente. Una rete isolata dalla rete richiede un flusso di lavoro per il trasferimento dei dati: SUSE documenta i comandi di esportazione e importazione di RMT per spostare i dati e i metadati del repository utilizzando supporti di archiviazione rimovibili. RMT può replicare solo i prodotti disponibili per gli abbonamenti dell'organizzazione.

Documentazione ufficiale per SLES 15 SP7: installazione e configurazione di RMT ; Guida allo strumento di mirroring del repository ; Migrazione da SMT a RMT .