Come configurare un server SUSE RMT locale (sostituto di SMT)

Se stai configurando un server locale per i sistemi SUSE Linux Enterprise esistenti, utilizza il Repository Mirroring Tool (RMT) e non una nuova installazione di SMT. SUSE ha sostituito il Subscription Management Tool (SMT) con RMT a partire da SLE 15. RMT sincronizza le informazioni sui prodotti e sui repository da SUSE Customer Center (SCC), esegue il mirroring dei pacchetti selezionati e consente ai client supportati di registrarsi tramite il server locale. Questa guida si basa sulla documentazione di RMT per SUSE Linux Enterprise Server 15 SP7, verificata il 6 ottobre 2026. I comandi e la disponibilità dei pacchetti possono variare in altre versioni, quindi utilizza la guida per la versione esatta del server che stai implementando.

È meglio utilizzare RMT o mantenere SMT?

Scegli RMT per un nuovo servizio locale di registrazione e aggiornamento per i client SLES 12 e versioni successive. RMT è incluso in SLES a partire dalla versione 15 e può replicare i repository SUSE e i repository personalizzati. Riduce i download ripetuti e impedisce ai computer client di connettersi direttamente a SCC.

SMT rimane rilevante per gli ambienti meno recenti, ma SUSE identifica SLE 12 come l'ultima versione del codice per SMT. RMT non supporta i client SLE 11 e precedenti e SUSE avverte che RMT non è una sostituzione completa, funzionalità per funzionalità: ad esempio, la sua guida alla migrazione elenca i repository di staging, la gestione dei client SMT e la creazione di report come funzionalità che non vengono trasferite allo stesso modo. Se la vostra infrastruttura include SLE 11 o dipende da flussi di lavoro esclusivamente SMT, non date per scontato che sia possibile una sostituzione diretta. Consultate la guida alla migrazione e le opzioni di supporto SUSE prima di cambiare servizio.

RMT si differenzia anche da un repository di pacchetti isolato dalla rete. Un server RMT standard necessita di accesso in uscita a SCC e ai servizi di aggiornamento SUSE per sincronizzare metadati e pacchetti. Un'implementazione disconnessa richiede un processo separato di esportazione/importazione o di mirroring offline.

Cosa bisogna preparare prima dell'installazione?

• Host supportato: pianificare un server SLES 15 per il servizio RMT. Per la migrazione da SMT, SUSE consiglia di utilizzare un host SLES 15 appena installato.
• Credenziali dell'organizzazione SCC: RMT utilizza le credenziali di mirroring dell'organizzazione, non un normale codice di registrazione client. In SCC, seleziona l'organizzazione corretta e apri la sezione Proxy per trovarle.
• Un nome DNS stabile e un piano TLS: scegli il nome di dominio completo (FQDN) che i client utilizzeranno, ad esempio rmt.example.com. Assicurati che sia risolvibile dalle reti dei client e che corrisponda al nome sul certificato HTTPS.
• Spazio di archiviazione del repository: dimensione dello spazio di archiviazione per i prodotti, i moduli, le versioni e le architetture che si intende replicare. SUSE fornisce circa 1,5 volte la dimensione totale del repository abilitato come guida di pianificazione generale e osserva che ciò corrisponde a circa 200 GB per ogni release SLE, incluse le estensioni. Le esigenze effettive variano; monitorare lo spazio libero, in particolare lo spazio temporaneo in /tmp.
• Accesso alla rete: consentire all'host RMT di raggiungere gli endpoint SUSE richiesti dalla versione in uso. La guida di SLES 15 SP7 elenca scc.suse.com, updates.suse.com, e installer-updates.suse.comsulle porte 80 e 443. Limitare l'accesso dei client al servizio RMT alle reti che ne hanno bisogno.

Non combinare il ruolo RMT con il ruolo server di installazione SLES sulla stessa macchina senza prima aver verificato l'avviso di SUSE: le due configurazioni utilizzano server web diversi sulla porta 80 e non sono progettate per essere abilitate contemporaneamente.

Come si installa e si configura RMT?

1. Installa il pacchetto RMT

Su un host SLES 15 esistente con i repository necessari disponibili, installare il pacchetto server e applicare gli aggiornamenti di manutenzione correnti:

sudo zypper in rmt-server
sudo zypper patch

Il set esatto di pacchetti può variare a seconda delle immagini minimali e dei metodi di distribuzione. Segui la sezione di installazione relativa alla versione di SLES che hai scelto, anziché copiare un comando da una piattaforma diversa.

2. Eseguire la configurazione YaST RMT

Avviare il modulo di configurazione:

sudo yast2 rmt

Inserire il nome utente e la password per il mirroring dell'organizzazione SCC quando richiesto. YaST richiede anche un database e un utente MariaDB, nonché un nome comune per il certificato. Utilizzare il FQDN (Fully Qualified Domain Name) del server RMT rivolto al client come nome comune. Aggiungere eventuali altri nomi o indirizzi IP che i client utilizzeranno effettivamente come nomi alternativi sul certificato. Un client che si connette tramite un nome non presente nell'elenco può segnalare una mancata corrispondenza del certificato anche se il servizio è raggiungibile.

Se firewalldabilitato, utilizzare l'opzione YaST per aprire le porte RMT necessarie. Ove possibile, limitare l'accesso all'interfaccia di rete o alla zona corretta. Completare la procedura guidata e rivederne il riepilogo; SUSE afferma che YaST abilita e avvia i servizi e i timer systemd necessari.

3. Confermare il nome del server, il certificato e il servizio

Dalla rete client, verificare che il FQDN scelto si risolva nell'host RMT e che HTTPS presenti un certificato considerato attendibile dal client. Il certificato CA generato da RMT è memorizzato in /etc/rmt/ssl/rmt-ca.crt; il certificato del server e la chiave sono memorizzati in /etc/rmt/ssl/rmt-server.crte /etc/rmt/ssl/rmt-server.key. Proteggere la chiave privata e mantenere il certificato CA disponibile per i client che devono considerarlo attendibile. Utilizzare esattamente lo stesso FQDN presente nel certificato del server per la registrazione.

Come si selezionano e si replicano solo i repository necessari?

4. Sincronizzare i metadati del prodotto e del repository

Dopo la configurazione, sincronizzare il database RMT locale con SCC:

sudo rmt-cli sync

Questo aggiorna le informazioni sui prodotti e sui repository disponibili per RMT; non significa che tutti i pacchetti siano già stati scaricati. La sincronizzazione automatica dei metadati è gestita da rmt-server-sync.timer. Verifica il suo stato con:

systemctl status rmt-server-sync.timer

5. Trova gli identificativi del prodotto per il tuo patrimonio

Elenca i prodotti e i repository disponibili prima di abilitare qualsiasi cosa:

sudo rmt-cli products list --all
sudo rmt-cli repos list --all

Utilizza gli ID o le stringhe di prodotto segnalate dal tuo server. Gli ID negli esempi online potrebbero essere diversi perché la disponibilità dipende dagli abbonamenti, dalle versioni del prodotto, dalle architetture e dai metadati restituiti da SCC.

6. Abilitare i prodotti richiesti

Abilita i prodotti che i clienti utilizzano effettivamente. Ad esempio, dopo aver verificato che la stringa del prodotto sia presente nell'output, potresti eseguire:

sudo rmt-cli products enable SLES/15/x86_64

L'attivazione di un prodotto abilita automaticamente anche i repository associati, come i repository di pool e di aggiornamento. Se i sistemi utilizzano moduli o estensioni aggiuntivi, verificare che tali prodotti siano disponibili e abilitare quelli necessari. Evitare di replicare ogni prodotto "per precauzione": ciò consuma spazio di archiviazione e aumenta i tempi di sincronizzazione.

7. Specchiare le confezioni e controllare il risultato

Avvia manualmente il mirror iniziale in modo da poter osservare il completamento e risolvere eventuali problemi prima di affidarti alla pianificazione:

sudo rmt-cli mirror

RMT memorizza i contenuti replicati in /var/lib/rmt/public/repouna posizione predefinita. Controlla lo spazio su disco disponibile e rivedi l'output del comando. La pianificazione giornaliera del mirroring è gestita da rmt-server-mirror.timer; controlla il suo stato con:

systemctl status rmt-server-mirror.timer

Una sincronizzazione dei metadati riuscita da sola non garantisce che i client possano installare gli aggiornamenti. I repository selezionati devono essere replicati, il client deve essere in grado di raggiungere il server e l'accesso al prodotto deve essere valido per l'organizzazione.

Come si registra un client sul server locale?

8. Esegui prima un test con un cliente.

Su un client SLES supportato, registrarlo con il nome host RMT. SUSE documenta questa forma di comando:

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

Sostituisci l'host di esempio con il FQDN coperto dal tuo certificato. I client normalmente non necessitano delle credenziali di mirroring SCC; l'host RMT utilizza tali credenziali per la sincronizzazione per conto dell'organizzazione. Per i sistemi che necessitano di assistenza per l'importazione della CA RMT, SUSE fornisce uno rmt-client-setupscript dal server. Consulta la guida client corrente e verifica l'impronta digitale o la catena di fiducia del certificato prima di accettarlo.

È possibile configurare la registrazione anche durante l'installazione tramite il regurl=https://rmt.example.comparametro di avvio, oppure utilizzare il modulo di registrazione del prodotto di YaST e scegliere il server di registrazione locale. Per le installazioni automatizzate, SUSE documenta un'opzione AutoYaST. Scegliete il metodo più adatto alla configurazione dei vostri sistemi.

9. Verifica la registrazione e l'accesso al pacchetto

Sul client, verificare che la registrazione sia completata, che i prodotti e i repository previsti siano visualizzati e che i metadati del repository possano essere aggiornati. Ad esempio, ispezionare le definizioni del repository con zypper lre aggiornarle con sudo zypper refresh. Quindi testare una query o un aggiornamento del pacchetto durante una finestra di manutenzione. Se manca un modulo, verificare che sia abilitato e replicato su RMT prima di modificare i file del repository lato client.

Prima di reindirizzare un'ampia flotta di sistemi, testa un normale percorso di aggiornamento su un singolo client rappresentativo. Una volta verificato il successo del test, aggiorna i profili di provisioning, i parametri di avvio dell'installazione o la gestione della configurazione in modo che i sistemi nuovi e ricostruiti utilizzino lo stesso URL RMT.

Cosa bisogna controllare quando qualcosa non funziona?

Cosa cambia se si effettua la migrazione da SMT?

Considerate la migrazione come una modifica dei dati e del flusso di lavoro, non come un aggiornamento del pacchetto in loco. SUSE consiglia un nuovo host SLES 15. Il processo di esportazione/importazione documentato viene utilizzato smt-data-exportsu SMT e rmt-data-importsul nuovo server dopo che RMT si è sincronizzato con SCC. Le impostazioni del repository in fase di staging non vengono esportate, vengono trasferiti solo i repository contrassegnati per il mirroring e i prodotti scaduti non sono disponibili su RMT. I job client e lo stato delle patch di SMT non vengono esportati. Pianificate di ricreare i processi operativi che dipendono da tali funzionalità e convalidate i record di registrazione prima di reindirizzare i client di produzione.

Se le politiche di supporto e sicurezza lo consentono, mantieni attivo il vecchio servizio durante una transizione controllata. Esegui la migrazione di un piccolo gruppo di client, verifica la registrazione, i repository, l'attendibilità dei certificati e il comportamento degli aggiornamenti, quindi estendi il gruppo. Non dismettere l'host SMT finché i client legacy e tutti i flussi di lavoro non supportati non avranno una destinazione specifica.

Come fai a sapere se l'allestimento è pronto?

• Il FQDN RMT viene risolto correttamente e HTTPS utilizza un certificato considerato attendibile dai client.
• L'host RMT sincronizza i metadati SCC correnti e replica ogni repository di prodotto richiesto dai clienti del progetto pilota.
• Un client supportato si registra all'URL locale e visualizza i repository dei prodotti desiderati.
• Un client può aggiornare i metadati del repository e completare un'operazione controllata sul pacchetto.
• La capacità del disco, lo spazio temporaneo, i timer, i registri, i backup e il rinnovo dei certificati hanno un proprietario e un piano di monitoraggio.

RMT centralizza la registrazione e la distribuzione dei pacchetti, ma non elimina la necessità di gestire abbonamenti, selezione dei prodotti, ciclo di vita del client, attendibilità dei certificati, backup e test degli aggiornamenti. Per le procedure esatte e le differenze specifiche della versione, consultare la Guida allo strumento di mirroring del repository SLES 15 SP7 di SUSE , il capitolo sulla migrazione da SMT a RMT , il capitolo sulla configurazione del client RMT e il capitolo sul mirroring del repository di SUSE .