Die Konfiguration einer Softwarespiegelung besteht aus folgenden Schritten:
Erstellen einer gesonderten XML-Konfigurationsdatei für jeden zu spiegelnden Fernserver.
Weitere Informationen hierzu finden Sie unter Abschnitt 25.2.1, Erstellen von Konfigurationsdateien
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
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
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:
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> <Base>http://red-carpet.ximian.com/</Base> <Type>rce</Type> <User /> <Password /> </RemoteServer>
<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.. |
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
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>
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.
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:
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.
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.
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.
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.