Für die Installation der Data Protector Software auf Linux basierenden Betriebssystemen und HP-UX wird, genau wie unter Windows, ein Installation Server benötigt. Erst mit einem Installation Server ist es möglich automatisiert neue Clients über die GUI zu installieren und bestehende Clients zu aktualisieren (Push-Installation). Ich verwende hierfür immer eine virtuelle Maschine. Eine Basisinstallation ohne graphische Benutzeroberfläche ist völlig ausreichend; unterstützt wird der Linux Installation Server auf RedHat, CentOS, Oracle Enterprise Linux und SUSE Linux Enterprise Server (Details zu den Versionen stehen in der Matrix: Platform_Integrtn_SptMtx.pdf). Mit der nachfolgenden Anleitung zeige ich, welche Schritte notwendig sind einen Data Protector Linux Installation Server zu installieren oder auf eine neuere Version zu aktualisieren. Dies schließt das Entfernen einer älteren „Major Version“ vom Data Protector auf dem Installation Server ein. Das Abarbeiten der Schritte dauert maximal fünf Minuten.
Entfernen einer älteren Data Protector Version:
cp /opt/omni/.omnirc /tmp/.omnirc.sav rpm -qa | grep -i ob2 > /tmp/removeOB2 for PACKAGE in `cat /tmp/removeOB2`; do rpm -e $PACKAGE --nodeps --noscripts; done; cp /etc/services /tmp/services.bak cat /etc/services | sed -e "s/omni/\#omni/" > /tmp/services.new cp /tmp/services.new /etc/services rm /etc/xinetd.d/omni rm -r /etc/opt/omni rm -r /opt/omni rm -r /var/opt/omni rm /tmp/removeOB2 rm /tmp/services.new
Kommentar: Dies ist nicht der empfohlene Weg zum Entfernen, jedoch der schnellste Weg. Bitte beachte, dass unter Umständen für Data Protector „Site Specific Patches“ oder andere „Hotfixes“ nicht der String „OB2“ in der Paketbeschreibung genutzt wurde.
Installation der neuen Data Protector Version (nur Installation Server):
mkdir /dpinstall (*) mkdir /dpinstall/dp9 mkdir /dpinstall/dp9pb copy ISO file to /dpinstall (**) copy patch bundle file to /dpinstall (***) mount -o loop /dpinstall/TD586-15021.iso /dpinstall/dp9 /dpinstall/dp9/LOCAL_INSTALL/omnisetup.sh -IS umount /dpinstall/dp9 tar -xvf DPLNXBDL_00902.tar -C /dpinstall/dp9pb/ cd /dpinstall/dp9pb ./omnisetup.sh -bundleadd b902 cd / rm -r /dpinstall cp /tmp/.omnirc.sav /opt/omni/.omnirc (****)
* oder einem Verzeichnis mit ausreichend freiem Speicher
** zum Beispiel: TD586-15021.iso – Data Protector 9.00 Linux – kopieren mit winscp
*** zum Beispiel: DPLNXBDL_00902.tar – Data Protector 9.02 Linux – kopieren mit winscp
**** sofern die Datei vorhanden ist – siehe Entfernen Data Protector
In dem Beispiel wird davon ausgegangen, dass auch ein Patch Bundle installiert werden muss, ansonsten wären die Schritte 3, 5, 9, 10 und 11 nicht erforderlich. Nach der Installation sollte der Inhalt der .omnirc
Datei geprüft werden; mindestens die Varaiable OB2_SSH_ENABLED=1
wird in /opt/omni/.omnirc
benötigt, da sonst eine Verteilung der Client Software über die Data Protector GUI nicht möglich ist. Falls die Datei noch nicht existiert, so kann sie aus der Vorlage erstellt werden – cp /opt/omni/.omnirc.TMPL /opt/omni/.omnirc
. Wenn zusätzliche Updates verfügbar sind, so sind diese auf den Server zu kopieren. Das Entpacken von zusätzlichen Updates wird mit dem Kommando tar
durchgeführt. Es werden das RPM Paket und eine Text Datei generiert. In der Text Datei steht das Kommando zum Installieren des Patches. Es ist zu beachten, dass die Patches in einer bestimmten Reihenfolge zu installieren sind, Details: https://www.data-protector.org/wordpress/2013/06/basics-installation-order-patches/.
Registrieren des Installation Server in der Data Protector Zelle:
omnicc -export_is <installation server> (*) omnicc -import_is <installation server> (**)
* Der Schritt ist nur notwendig, wenn der Server bereits als Installation Server genutzt wurde
** Für „installation server“ ist der Name des Servers (FQDN) zu verwenden
Wenn dieser Installation Server bereits früher für die Verteilung der Client Software genutzt wurde, so kann er jetzt direkt für ein Upgrade der bestehenden Clients über die Data Protector GUI genutzt werden. Falls dies der erste Linux Installation Server in der Umgebung ist, so ist zusätzlich die SSH basierende Anmeldung zu konfigurieren.
Erstellen des public/private rsa key pair:
ssh-keygen (*) ssh <client - short name> (**) ssh <client - FQDN name> (**) ssh <client - IP address> (**) Add public key (***)
* Beantworten der Fragen, danach wird das „Key Pair“ generiert
** Der Anmeldevorgang kann abgebrochen werden, sobald der Host-Key des Clients akzeptiert wurde
*** Mit ssh
am zu installierenden Client anmelden, es muss der Public Key des Installation Servers (cat /root/.ssh/id_rsa.pub
) der Datei /root/.ssh/authorized_keys
hinzugefügt werden
Es wird davon ausgegangen, dass bei der Beantwortung der Fragen des Kommandos ssh-keygen
die Standardwerte übernommen werden. Es wird ferner davon ausgegangen, dass für die SSH Konfiguration ebenfalls die Standardwerte und Standardpfade genutzt wurden.
The lines:
rpm -qa | grep -i ob2 > /tmp/removeOB2
for PACKAGE in `cat /tmp/removeOB2`; do rpm -e $PACKAGE –nodeps –noscripts; done;
can be substitued by (alternative):
rpm -qa | grep OB2 | xargs rpm -e
Best regards
Daniel
Hi Daniel,
Firstly thanks for the post.
Couple of discussion points 🙂
1. I do not have OB2_SSH_ENABLED=1 in omnirc or any of the ‚Create public/private rsa key pair‘ notes. I assume this is optional for security? Will Linux agent push not work without it?
2. From my own build notes I also have the below:
(hopefully the packages are on the yum repo already).
Install pre-reqs
a. ‘yum install xinetd’
b. ‘yum install compat-libstdc++-33’
For GRE web-plugin
1. ‘yum install fuse-libs-2.8.3-4.el6.x86_64’
2. ‘yum install fuse-2.8.3-4.el6.x86_64’
3. ‘yum install cifs-utils’
4. ‘yum install ntfs-3g’
and adding DP to the firewall:
‘vi /etc/sysconfig/iptables’
add ‘–A INPUT –p tcp –m state –state NEW –m tcp –dport 5555 –j ACCEPT’
‘/sbin/service iptables save’
Hi Michael,
Regarding your first comment, in general the SSH method is the preferred method to push new clients. If not configured or if omnirc variable is not set, pushing clients will fallback to rexec. Of course, for security reason SSH should be the preferred method and rexec is not available or configured by default when installing a Linux system.
Regarding second comment, yes, xinetd or inetd is a requirement in any way, so I skipped this step. Thanks for the iptables command, I missed this step (normally I do not have installed a firewall when the installation server is located in local network). The other lines are not required on SLES/RedHat (support matrix 😉 ) and the GRE part I install on another dedicated server.
Thanks for contribution.
Best regards
Daniel
Thanks Daniel.
This post was a real help for me