25.2 Konfigurieren einer Softwarespiegelung

Die Konfiguration einer Softwarespiegelung besteht aus folgenden Schritten:

  1. Erstellen einer gesonderten XML-Konfigurationsdatei für jeden zu spiegelnden Fernserver.

    Weitere Informationen hierzu finden Sie unter Abschnitt 25.2.1, Erstellen von Konfigurationsdateien

  2. Spiegeln von Patch-Bundles

    Weitere Informationen hierzu finden Sie unter Abschnitt 25.2.2, Spiegeln von Patch-Bundles für SLES 10 / SLED 10 / OES 2 aus NU- und RCE-Repositorys

  3. Testen und Ausführen der Spiegelung mithilfe von zlmmirror.

    Weitere Informationen hierzu finden Sie unter Abschnitt 25.2.3, Testen und Ausführen der Spiegelung

25.2.1 Erstellen von Konfigurationsdateien

Führen Sie folgenden Befehl aus, um eine leere Konfigurationsdatei zu erstellen:

zlmmirror conf-generate dateiname.xml

Mit diesem Befehl erstellen Sie im aktuellen Verzeichnis eine Vorlagenkonfigurationsdatei mit dem Namen zlmmirror-config.xml.

Sie können die Konfigurationsdatei aus einer früheren Version von ZENworks Linux Management oder Red Carpet konvertieren oder Konfigurationsdateien manuell erstellen. Die Konfigurationsdateien werden mit der Flagge -c angegeben:

zlmmirror befehl -c dateiname.xml

Wenn keine Konfigurationsdatei angegeben wurde, wird der Speicherort für die Konfigurationsdatei standardmäßig in /etc/opt/novell/zenworks/zlmmirror.xml erstellt.

Sie können die Konfigurationsdatei auf Fehler überprüfen und die analysierten Konfigurationsinformationen mithilfe des Befehls conf-validate (cv) Dateiname anzeigen.

Nach dem Erstellen einer Basiskonfigurationsdatei, können Sie mithilfe folgender Aufgaben die erforderlichen Konfigurationsinformationen hinzufügen:

Schritt 1: Server

Sie müssen Einzelheiten zu einem Fernserver angeben, der die zu spiegelnde Software enthält, sowie einen lokalen Server, bei dem es sich um den ZENworks Linux Management-Server handelt, der die gespiegelte Software erhalten soll.

RemoteServer
<RemoteServer>
   <Base>http://red-carpet.ximian.com/</Base>
   <Type>rce</Type>
   <User />
   <Password />
</RemoteServer>

Konfigurationselement

Beschreibung

Base

Pfad des zu spiegelnden Servers, je nach Typ im folgenden Format:

ZLM: https://server

DELL: http://ftp.dell.com

RCE: https://server/path

YAST: http(s)://server/path oder ftp://server/path

RHN: http(s)://server/pfad

YUM http://server/pfad

STATIC: /path/on/filesystem

NU: https://nu.novell.com/repo

Typ

Typ des Servers, den Sie spiegeln möchten:

ZLM: ZENworks 7 Linux Management

DELL: Dell-Aktualisierungspaket-FTP-Server

RCE: Red Carpet® Enterprise™ oder ZENworks 6.x Linux Management

YAST: YAST Online Updates

RHN: Red Hat Network

YUM: YUM

NU: Novell Updates

Benutzer

Bei der Verbindung mit dem Fernserver zu verwendender Benutzername. Wenn kein Benutzer angegeben ist, ruft zlmmirror den Benutzernamen je nach Typ von folgendem Ort ab:

ZLM: Für SLES 9 und OES unter /etc/opt/novell/zenworks/zmd/deviceid und für SLES 10 und SLED 10 unter /etc/zmd/deviceid

RCE: /etc/ximian/mcookie

YAST: /etc/sysconfig/onlineupdate

Lassen Sie dieses Element bei einer Verbindung mit einem RHN- oder Dell-Server leer.

NU: Für SLES 9 und OES unter /etc/opt/novell/zenworks/zmd/deviceid und für SLES 10 und SLED 10 unter /etc/zmd/deviceid

Für den Novell Updates- (NU-)Server muss das Gerät bei NCC registriert sein, um die deviceid als Benutzer verwenden zu können.

Passwort

Bei der Verbindung mit dem Fernserver zu verwendendes Passwort. Wenn kein Passwort angegeben wird, liest zlmmirror das Passwort je nach Typ vom folgenden Speicherort ab:

ZLM: Für SLES 9 und OES unter /etc/opt/novell/zenworks/zmd/secret und für SLES 10 und SLED 10 unter /etc/zmd/secret

RCE: /etc/ximian/partnernet

YAST: /etc/sysconfig/onlineupdate

Lassen Sie dieses Element bei einer Verbindung mit einem RHN- oder Dell-Server leer.

NU: Für SLES 9 und OES unter /etc/opt/novell/zenworks/zmd/secret und für SLES 10 und SLED 10 unter /etc/zmd/secret

Für den Novell Updates- (NU-)Server muss das Gerät bei NCC registriert sein, um das Gerätegeheimnis als Passwort verwenden zu können.

Proxy

Die Angabe dieses Konfigurationselements ist optional; es wird für einen Internet-Proxyserver verwendet. Sie können dieses Element an einer beliebigen Stelle im Abschnitt „RemoteServer“ einfügen.

Wenn für den Internet-Proxyserver eine Authentifizierung erforderlich ist, verwenden Sie folgende Syntax:

<Proxy>http://username:password@server:port</Proxy>

Ist keine Authentifizierung erforderlich, verwenden Sie folgende Syntax:

<Proxy>https://server:port</Proxy>

LocalServer
<LocalServer>
   <Base></Base>
   <Type>zlm</Type>
   <User>Administrator</User>
   <Password>password</Password>
</LocalServer>

Konfigurationselement

Beschreibung

Base

Wenn im Element „Typ“ eine statische Spiegelung (STATIC) festgelegt ist, definieren Sie mit dem Element „Basis“ den Zielpfad für die gespiegelten Dateien (zum Beispiel /pfad/auf/dateisystem).

Legt das Element „Type“ eine ZLM-Spiegelung fest, dann lassen Sie das Element „Base“ leer.

Typ

Typ der vorzunehmenden Spiegelung:

ZLM: Spiegelt Kataloge und Bundles direkt auf den ZENworks Linux Management-Server. Nach der Spiegelung werden die gespiegelten Kataloge und Bundles im ZENworks Control Center angezeigt.

STATIC: Spiegelt die Pakete in das Dateisystem des ZENworks Linux Management-Servers, fügt ZENworks die gespiegelten Pakete jedoch nicht hinzu.

Benutzer

Der bei der Verbindung mit dem (lokalen) ZENworks Linux Management zu verwendende Benutzername. Wenn das Standard-Administratorkonto verwendet werden soll, müssen Sie den Benutzernamen „Administrator“ eingeben.

Passwort

Das Passwort für das unter „Benutzer“ angegebene Konto. Wenn Sie das Administratorkonto verwenden, geben Sie das gleiche Passwort ein, das Sie während der Serverinstallation angegeben haben. Informationen zur Verschlüsselung Ihres Passworts erhalten Sie unter Abschnitt 25.6, Verschlüsseln des ZENworks-Serverpassworts..

Schritt 2: Katalog- und Bundle-Konfiguration

Sie müssen Details zu den Katalogen und Bundles angeben, die auf Ihren Server gespiegelt werden sollen.

Vor einer Spiegelung der Kataloge und Bundles auf Ihren Server können Sie die verfügbaren Kataloge und Bundles auf dem Fernserver anzeigen.

Zur Anzeige der verfügbaren Kataloge führen Sie den folgenden Befehl aus:

zlmmirror -c dateiname.xml slc

Zur Anzeige der verfügbaren Bundles führen Sie den folgenden Befehl aus:

zlmmirror -c dateiname.xml slb

CatalogConf

Jeder zu spiegelnde Katalog muss einen gesonderten CatalogConf-Abschnitt aufweisen:

<CatalogConf>
   <Name>Red Carpet 2</Name>
   <LocalName>Red Carpet 2</LocalName>
   <Target>sles-9-i586</Target>
   <Package>lib.*</Package>
</CatalogConf>

Konfigurationselement

Beschreibung

Name

Name des Katalogs, der von diesem Fernserver gespiegelt werden soll.

Dies ist er einzige erforderliche Parameter.

Lokaler Name

Name des Katalogs, dem die gespiegelte Software angehören soll. Wenn kein lokaler Name angegeben ist, wird der auf dem Fernserver verwendete Katalogname übernommen. Der lokale Name für den Katalog sollte nicht identisch mit dem für den <catalogname>-Patchordner reservierten Namen sein

Ordner

Legt den eDirectory™-Ordner fest (z. B. /folder1/folder2), in dem Bundles und Kataloge erstellt und aktualisiert werden. Wenn dieser Ordner nicht angegeben ist, werden die Kataloge und Bundles im Ordner /zlmmirror erstellt und aktualisiert.

Target

Spiegelt nur die Pakete und Patches des Katalogs, die die angegebenen Zielplattformen unterstützen. Wenn keine Zielplattform angegeben ist, werden Pakete für alle Plattformen gespiegelt.

Diese Option kann mehrmals vorhanden sein. Sie kann direkt einen Zielnamen enthalten, aber auch eine reguläre Ausdruckszeichenfolge mit Platzhaltern, die alle übereinstimmenden Zielnamen auswählt.

Um beispielsweise Ziele einzuschließen, die mit „sles“ beginnen, wie „sles-9-i586“, verwenden Sie den regulären Ausdruck <Target>sles.*</Target>.

ExcludeTarget

Für diese Option gilt das Gleiche wie für „Target“. Allerdings werden bei dieser Option Pakete und Patches, die die angegebenen Zielplattformen unterstützen, von der Spiegelung ausgeschlossen. „ExcludeTarget“ wird nach „Target“ ausgeführt. Plattformen, die in „ExcludeTarget“ aufgeführt werden, sind daher definitiv ausgeschlossen, selbst wenn sie zuvor in „Target“ genannt wurden. Um beispielsweise Ziele auszuschließen, die mit „i586“ enden, wie „sles-9-i586“, verwenden Sie den regulären Ausdruck <ExcludeTarget>.*i586</ExcludeTarget>.

Bundle

Beschränkt die Spiegelung für den Katalog auf die angegebenen Bundles. Wenn keine Bundles angegeben sind, werden alle Bundles gespiegelt.

Diese Option gilt nur für ZENworks Linux Management- und YAST-Ursprungsserver. Diese Option kann mehrmals angegeben werden. Sie kann entweder einen Paketnamen enthalten oder eine reguläre Ausdruckszeichenfolge, die alle übereinstimmenden Paketnamen auswählt.

LocalBundleName

Benennt das Bundle lokal um. Dies gilt nur für die RCE-, NU- und RHN-Dienste, in denen ein Katalog auf dem Fernserver nur ein Bundle besitzt. Wenn Sie <LocalBundleName> angeben, dürfen Sie das <Bundle>-Tag nicht angeben. Dieses Tag ist nicht verwendbar, wenn Sie OES aus dem RCE-Dienst mit mehr als einem Bundle pro Katalog spiegeln. Es ist jedoch für YOU und ZLM verwendbar.

ExcludeBundle

Für diese Option gilt das Gleiche wie für „Bundle“. Allerdings werden bei dieser Option die Pakete und Patches der angegebenen Bundles von der Spiegelung ausgeschlossen.

Diese Option gilt nur für ZENworks Linux Management- und YAST-Ursprungsserver. Diese Option kann mehrmals angegeben werden. Sie kann entweder einen Paketnamen enthalten oder eine reguläre Ausdruckszeichenfolge, die alle übereinstimmenden Paketnamen auswählt.

„ExcludeBundle“ wird nach „Bundle“ ausgeführt. Bundles, die in „ExcludeBundle“ aufgeführt werden, sind daher definitiv ausgeschlossen, selbst wenn sie zuvor in „Bundle“ genannt wurden.

Paket

Beschränkt die Spiegelung für den Katalog auf die angegebenen Pakete. Wenn keine Pakete angegeben sind, werden alle Pakete gespiegelt. Diese Option kann mehrmals vorhanden sein. Sie kann direkt einen Paketnamen enthalten, aber auch eine reguläre Ausdruckszeichenfolge, die alle übereinstimmenden Paketnamen auswählt. Diese Option wird für YOU-Patches nicht unterstützt.

ExcludePackage

Für diese Option gilt das Gleiche wie für „Package“. Allerdings werden bei dieser Option die angegebenen Pakete von der Spiegelung ausgeschlossen. Diese Option kann mehrmals vorhanden sein. Sie kann direkt einen Paketnamen enthalten, aber auch eine reguläre Ausdruckszeichenkette, die alle übereinstimmenden Paketnamen auswählt. Diese Option wird für YOU-Patches nicht unterstützt. „ExcludePackage“ wird nach „Package“ ausgeführt. Pakete, die in „ExcludePackage“ aufgeführt werden, sind daher definitiv ausgeschlossen, selbst wenn sie zuvor in „Package“ genannt wurden.

Kategorie

Beschränkt den Spiegelungsvorgang am Katalog auf die angegebenen Kategorien der Patch-Bundles. Wenn keine Kategorie angegeben wird, werden alle Patch-Bundles gespiegelt. Gültige Werte sind „Empfohlen“, „Optional“ und „Sicherheit“. Dieses Tag eignet sich nur für SLES 10-, SLED 10- und OES 2-Server des Typs NU.

ServicePackGroups

Es sind ausschließlich boolesche Werte verwendbar (true oder false). Standardmäßig wird für <ServicePackGroups> der Wert „true“ festgelegt und es werden automatisch Bundle-Gruppen erstellt. Diese Option wird nur für YOU-Patches unterstützt

AutoDeploy

Die Spiegelung des Pakets auf ein vorhandenes Bundle erzeugt eine neue Version des Bundles und stellt diese auf dem Server bereit. Wenn für AutoDeploy „false“ festgelegt wird, beschränkt die Spiegelung die Bereitstellung des neuen Bundles. Es sind nur boolesche Werte gültig (true oder false). Standardmäßig wird für die Option „true“ festgelegt

FilterPatchRPM

Beschränkt die Spiegelung der YOU-Patch-Bundles, um alle Pakete vom Typ .patch.rpm zu filtern. Diese Option erzeugt ein entsprechendes RPM-Paket-Bundle auf dem lokalen Server. Es sind nur boolesche Werte gültig (true oder false). Standardmäßig wird für die Option „false“ festgelegt. Diese Option wird nur für YOU-Patches unterstützt

HINWEIS:Die Verwendung von regulären Ausdrücken (regexes) hat sich in ZENworks 7.2 Linux Management geändert. ZENworks 7.2 Linux Management verwendet keine Platzhalterzeichenabgleiche. In ZENworks Linux Management 6.6.x können Sie eine Platzhalterausdrucks-Zeichenkette statt einer regulären Ausdruckszeichenkette verwenden. In ZENworks 7.2 Linux Management sollten Sie <Bundle>patch-.*</Bundle> verwenden, um alle Bundles zu spiegeln, die mit dem Namen „patch-“ beginnen. ZENworks Linux Management unterstützt alle regulären Ausdrücke von Java. Weitere Informationen über reguläre Ausdrücke in Java finden Sie in der Java-Dokumentation.

25.2.2 Spiegeln von Patch-Bundles für SLES 10 / SLED 10 / OES 2 aus NU- und RCE-Repositorys

Sie können Patch-Bundles für SLES 10, SLED 10 und OES 2 von NU- und RCE-Repositorys wie nu.novell.com und update.novell.com. spiegeln. Weitere Informationen finden Sie in den folgenden Abschnitten:

Spiegeln von monolithischen und Patch-Bundles für SLES 10 / SLED 10 / OES 2

Das Spiegeln von Aktualisierungen für SLES 10-, SLED 10- und OES 2-Plattformen von NUServer und RCEServer mithilfe des Kommandos zlmmirror m -c conf.xml erzeugt Patch-Bundles und ein monolithisches Bundle <katalogname>-bundle mit allen Paketen darin.

Spiegeln der Patch-Bundles für SLES 10 / SLED 10 / OES 2

Um nur die Patch-Bundles für SLES 10, SLED 10- und OES 2-Plattformen von entfernten Servern des Typs RCE und NU zu spiegeln, verwenden Sie die Option -p im zlmmirror-Kommando m -p -c mirror-conf.xml.

Spiegeln der monolithischen Bundles für SLES 10 / SLED 10 / OES 2

Um die monolithischen Bundles ohne Erstellung der Patch-Bundles zu spiegeln, verwenden Sie das Tag <Bundle> der Konfigurationsdatei für das Spiegeln. Beispiel: Verwenden Sie <Bundle>SLED10-Up dates-bundle</Bundle> zum Spiegeln des SLED10-Aktualisierungskatalogs. Die Option slb zeigt sowohl monolithische Bundles als auch Patch-Bundles an. Sie können das gewünschte Bundle mithilfe des Tags <Bundle> herunterladen. Um die spezifischen Pakete im monolithischen Bundle herunterzuladen, verwenden Sie das <Bundle>-Tag für das monolithische Bundle und <Package>-Tags für die spezifischen Pakete. Beispiel: Ein <Catalog>-Abschnitt zum Spiegeln der Mozilla-Pakete des monolithischen Bundles kann wie folgt aussehen:

<Catalog>
        <Name>SLED10-Updates</Name>
    <LocalName>SLED10-Updates</LocalName>
    <Folder></Folder>
    <Target>sled-10-i586</Target>
    <ExcludeTarget></ExcludeTarget>
    <Bundle>SLED10-Updates-bundle</Bundle>
    <ExcludeBundle></ExcludeBundle>
    <Package>Mozilla*</Package>
    <ExcludePackage></ExcludePackage>
</Catalog>

HINWEIS:Der lokale Name für den Katalog sollte nicht identisch mit dem für den Ordner <catalogname>-Patches reservierten Namen sein. Anders ausgedrückt: Das <localName>-Tag der Konfigurationsdatei für das Spiegeln darf nicht mit dem Namen der <catalogname>-Patches identisch sein.

25.2.3 Testen und Ausführen der Spiegelung

Stellen Sie vor Beginn des Spiegelungsvorgangs sicher, dass mindestens 10 GB Speicherplatz auf dem Gerät frei sind.

Führen Sie nach dem Erstellen der Konfigurationsdatei für einen Fernserver den folgenden Befehl aus, um einen Probelauf der Spiegelung durchzuführen, und fügen Sie gegebenenfalls die Flagge „verbose“ hinzu, um ausführliche Meldungen anzuzeigen:

zlmmirror mirror -c dateiname.xml --dryrun --verbose

Wenn dieser Vorgang die geplanten Ergebnisse liefert, führen Sie den Spiegelungsbefehl ohne die Flagge für den Probelauf („dryrun“) aus, um den Vorgang abzuschließen:

zlmmirror mirror -c zlmmirror-config.xml

Wenn Sie ein Bundle spiegeln, das mehrere Pakete mit verschiedenen Installationstypen/Aktualisierungs-Flags enthält, wird für jede Installationstyp-/Aktualisierungs-Flags-Kombination eine eigene Bundle-Version erstellt.

Ein Beispiel: Sie spiegeln ein Bundle, das vier der gleichen Zielplattform zugewiesene Pakete enthält. Beim ersten dieser vier Pakete ist die Installationstyp-Flagge auf „false“ eingestellt, beim zweiten Paket ist sie auf „true“ eingestellt, beim dritten Paket ist die Aktualisierungsflagge auf „false“ eingestellt und beim vierten Paket ist die Aktualisierungsflagge auf „true“ eingestellt. In diesem Fall werden vier verschiedene Bundle-Versionen erstellt.

Die Anzahl der erstellten Bundle-Versionen richtet sich auch nach der Anzahl der Zielplattformen. Im vorangegangenen Beispiel müssen für die vier Pakete, jeweils mit einer anderen Installationstyp-/Aktualisierungs-Kombination, zwei Zielplattformen berücksichtigt werden. In diesem Fall werden für beide Zielplattformen jeweils eigene Bundles mit allen vier Installationstyp-/Aktualisierungs-Kombinationen erstellt. Es werden also acht verschiedene Bundles erstellt.

Die Anzahl der erstellten Bundle-Versionen errechnet sich aus der Anzahl der eindeutigen Installationstyp-/Aktualisierungs-Kombinationen multipliziert mit der Anzahl der Zielplattformen.