SLES 11 SP2 SMT Server - Howto
Einleitung
Der SMT Server ist eine freie Software zur einfachen Systemverwaltung von SUSE Linux Enterprise Servern (SLES10, SLES11). Er dient primär zur lokalen Verwaltung von den von SUSE zur Verfügung gestellten Reposiories um Netzwerktraffic zu sparen und einen besseren Überblick über seine Systemlandschaft zu gelangen. Neben den von SUSE zur Verfügung gestellten Repositorys können aber auch noch eigene hinzugefügt werden.
Ein weiterer Vorteil des SMT ist die Möglichkeit ein Stageing von z.B. Test und Produktivumgebungen in der eigenen Serverlandschaft darzustellen.
Neben diesen Funktionen bietet er auch die Möglichkeit Scripte zentral vom SMT aus auf den Clients auszuführen.
In diesem Howto beschreibe ich, wie ich den SMT nutze und wie am Ende die Ausgaben auszusehen haben. Bei der Installation verweise ich dabei auf die recht gute und ausgearbeitet SUSE Dokumentation.
Voraussetzung
NCC Zugang (Novell Customer Center)
Mindestens 3 Aktive Subscriptions für SLES 11 SP2
Einen Server
Name: server-smtBetriebssystem: SLES 11
Netzwerkadapter:
eth0: 192.168.1.200
LVM Volume:
/dev/VolGroup00/smt 80 GB -> /var/lib/smt
Pakete:
SLES: smt
Anzahl Clients
Name: client1
Betriebssystem: SLES 11
Netzwerkadapter: eth0: 192.168.1.201
Name: client2
Betriebssystem: SLES 11
Netzwerkadapter: eth0: 192.168.1.202
Installation/Konfiguration
Das Subscription Management Tool steht frei zur Verfügung und kann bei SUSE https://download.suse.com/index.jsp in der Suche unter dem gleichnamigen Begriff runtergeladen werden. Die Installation läuft unter einer normal installierten SLES Instanz.
Unter der SLES Installation kann das runtergeladene Addon in YaST2 unter dem Punkt "Software" - "Add-On Product" hinzugefügt werden. Hierbei wird als Installationquelle die CD ausgewählt und die Installation nach Bestätigung der Lizenzvereinbarungen gestartet.
Eine ausführliche Installationsanleitung gibt es von SUSE unter dem folgenden Link:
Bei der Konfiguration ist drauf zu achten, dass der Domainname incl. Domain (FQND) im ganzen Netzwerk erreichbar ist, da es sonst zu Problemen mit den vom SMT erstellten SSL Zertifikaten kommt.
Sobald die Server Konfiguration durchgeführt wurde geht es daran die Clients an das System anzubinden. Mit der folgenden Befehlsreihenfolge bin ich bisher immer gut gefahren:
Kopieren des Scripts clientSetup4SMT.sh auf die Clients:
[root@<server-smt> ~]# scp -rp /usr/lib/suseRegister/bin/clientSetup4SMT.sh root@client01: ↵
[root@<server-smt> ~]# scp -rp /usr/lib/suseRegister/bin/clientSetup4SMT.sh root@client02: ↵
Löschen der vorhandenen Repositories, dies verhindert, dass der Server noch auf die lokal Konfigurierten CD/DVSs zugreift, die häufig nicht mehr eingebunden sind:
[root@<client1> ~]# rm -rf /etc/zypp/repos.d/* ↵
Konfiguration des Clients:
[root@<client1> ~]# ./clientSetup4SMT.sh https://server-smt.bludau.home/center/regsvc ↵
Sollten eigene nicht zertifizierte Repositories mit eingebunden werden helfen noch folgende Befehle weiter, welche noch einmal nachfragen, ob nicht zertifizierte Pakete zugelassen werden.
[root@<client1> ~]# suse_register --restore-repos
[root@<client1> ~]# zypper ref
Konfiguration des Clients:
[root@<client1> ~]# ./clientSetup4SMT.sh https://server-smt.bludau.home/center/regsvc ↵
Sollten eigene nicht zertifizierte Repositories mit eingebunden werden helfen noch folgende Befehle weiter, welche noch einmal nachfragen, ob nicht zertifizierte Pakete zugelassen werden.
[root@<client1> ~]# suse_register --restore-repos
[root@<client1> ~]# zypper ref
Anwendung
Im folgenden Absatz werden die wichtigen Befehle gelistet um den SMT Server zu benutzen.
Eine Liste aller angebundenen Clients und deren aktuellen Status gibt der Befehl smt-client aus. Der Status sollte möglichst auf Up-to-date sein, dies ist aber nicht immer realsierbar.
Um den SMT Mirror auf den aktuellen Stand zu bringen reicht es aus den folgenden Befehl auszuführen. Sollen die Updates ständig eingespielt werden, kann dieser Befehl auch als Cronjob gestartet werden.
[root@server-smt ~]# smt-mirror
Eine Liste aller angebundenen Clients und deren aktuellen Status gibt der Befehl smt-client aus. Der Status sollte möglichst auf Up-to-date sein, dies ist aber nicht immer realsierbar.
[root@server-smt ~]# smt-client ↵
.-----------------------------------------------------------------------------------------------.
| GUID | Hostname | Patch Status | Patch Status Date |
+----------------------------------+-----------------------+--------------+---------------------+
| 12345678901234567890123456789012 | client1 | Up-to-date | 2013-06-17 12:17:31 |
| 12345678901234567890123456789013 | client2 | Critical | 2013-06-17 12:15:07 |
.-----------------------------------------------------------------------------------------------.
| GUID | Hostname | Patch Status | Patch Status Date |
+----------------------------------+-----------------------+--------------+---------------------+
| 12345678901234567890123456789012 | client1 | Up-to-date | 2013-06-17 12:17:31 |
| 12345678901234567890123456789013 | client2 | Critical | 2013-06-17 12:15:07 |
'----------------------------------+-----------------------+--------------+---------------------'
[root@server-smt ~]#
Der SMT Server bietet die Möglichkeit einen Report zu generieren, in dem dargestellt wird, wie viele Subscription man aktuell hat und wie lange diese noch gültig sind.
[root@server-smt ~]# smt-reportDer SMT Server bietet die Möglichkeit einen Report zu generieren, in dem dargestellt wird, wie viele Subscription man aktuell hat und wie lange diese noch gültig sind.
Um den SMT Mirror auf den aktuellen Stand zu bringen reicht es aus den folgenden Befehl auszuführen. Sollen die Updates ständig eingespielt werden, kann dieser Befehl auch als Cronjob gestartet werden.
[root@server-smt ~]# smt-mirror
