Damit man den Webserver (in meinem Fall der Apache) absichert um nicht für poodle, rc4 oder ähnliches anfällig ist sollte man folgendes machen.

SSLLABS A

 

Wie man sieht habe ich fast alles Umgesetzt was machbar ist.

Hier könnt Ihr eure Internet-Seite überprüfen https://www.ssllabs.com

Mit folgenden Einstellungen in der vHOST könnt ihr die wichtigsten Einstellungen für SSL sichern, bis der nächste BUG kommt...

[pastacode lang="apache" message="SSL" highlight="" provider="manual"]

SSLEngine On
SpdyEnabled on
SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5
SSLCompression Off
SSLCertificateFile /etc/ssl/crt
SSLCertificateKeyFile /etc/ssl/key
SSLCertificateChainFile /etc/ssl/sub.class2.server.ca.pem

[/pastacode]

So sieht es im Übrigen aus, wenn man die Einstellungen nicht vorgenommen hat:

Screen Shot 2015-01-20 at 08.14.19

 

Wie man sieht ist es wirklich wichtig diese Einstellungen vorzunehmen, damit SSL einem auch was bringt.

 

Viele Grüße

Sven

Wie ja sicherlich einige von Euch schon gehört haben, gibt es zur Zeit einen sehr gefährlichen Bug im OpenSSL: http://www.heise.de/newsticker/meldung/Der-GAU-fuer-Verschluesselung-im-Web-Horror-Bug-in-OpenSSL-2165517.html

Wer seine Webseite Überprüfen möchte kann hier das Webinterface benutzen: http://filippo.io/Heartbleed/

image

Quelle: http://filippo.io/Heartbleed/

Ist euer Server Angreifbar? Nutzt die Kommentarfunktion! Zwinkerndes Smiley

Beim Betrieb einer Oracle VM-Umgebung ist es hilfreich, die syslog-Meldungen der OVM-Server auf einen Host zentral zu sammeln. Da nicht jeder einen syslog-Server im Einsatz hat, möchte ich nachfolgend beschreiben, wie man sehr einfach einen solchen Server aufsetzen kann.
Ich verwende dafür meist den OVM-Manager, da dieser für eine OVM-Umgebung benötigt wird und man so alle notwendigen Loginformationen auf einen Server vereinen kann.

Auf OracleLinux6 wird schon im Rahmen der OS-Installation rsyslog mit installiert, so das nur noch Konfigruationsarbeit notwendig ist.

Auf dem OVM-Manager muß lediglich folgende Datei angelegt werden. In der 'if'-Zeile muß noch der Hostname vom OVM-Manager eingetragen werden, damit die Remotemeldungen in die zusätzlichen Logs geschrieben werden. Andernfalls landen sie im syslog unter /var/log/messages

vi /etc/rsyslog.d/remotehost.conf

# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# Provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514

$template RemoteHost,"/var/log/remote-hosts/%HOSTNAME%/%HOSTNAME%.log"

if ($hostname != 'OVM-Manager Hostname') then ?RemoteHost
& ~

Nun noch das Verzeichnis für die Remotelogs erzeugen:

mkdir /var/log/remote-hosts

Syslog neu starten:

service rsyslog restart

Nun noch den logrotate konfigurieren:

vi /etc/logrotate.d/syslog-remote

/var/log/remote-hosts/*/*.log
{
sharedscripts
postrotate
/bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
endscript
}

Nun ist der Syslogserver konfiguriert.

Auf den OVM-Servern muß der syslog noch angepaßt werden, damit er die Meldungen an den neuen Syslogserver schickt:
vi /etc/syslog.conf

*.info;mail.none;authpriv.none;cron.none @192.168.100.234
*.info;mail.none;authpriv.none;cron.none /var/log/messages

Die untere Zeile existiert bereits in syslog.conf. Die Zeile darüber muß mit der IP vom OVM-Manager eingefügt und der syslog neu gestartet werden.

service syslog reload

logger test

Der syslog-Eintrag mit logger sollte nun auf dem syslogserver im Verzeichnis /etc/logrotate.d/syslog-remote/.log sichtbar werden.

Nun sind wir mit der Konfiguration fertig. 🙂

Das Thema Monitoring habe ich hier ja schon in einigen Postings erläutert. Ich möchte nun eine sehr interessante Variante eines Monitoringsystems vorstellen, die ich mir am Wochenende angeschaut habe.

Warum überhaupt eine neue Lösung?
Ich wollte meine Nagiosspielwiese schon seit Monaten auf OracleLinux6 neu bauen, hatte aber noch immer nicht die ultimative Lösung, wie ich das mit möglichst wenig Aufwand machen kann. Das Ziel sollte sein, eine Umgebung mit möglichst wenig Anpassungen zu bauen, die darüber hinaus auch einfach zu aktualisieren ist.

Altsystem:
Meine derzeitige Umgebung ist komplett selbst gebaut und kompiliert, da es vor 1,5 Jahren noch nicht die benötigen RPMs gab bzw. die Versionen zu alt waren. Ich habe folgende Komponenten gebaut:
- Nagios Core
- PNP4Nagios
- NagiosQL
- Thruk
- Livestatus
- check_nrpe

Das ist eine nicht zu unterschätzende Liste, wobei einige Komponenten sehr einfach zu bauen sind, da lediglich ein tar.gz entpackt und ein paar Dateien konfiguriert werden müssen. Technisch interessant vom Pflegeaufwand aber nicht so toll.

Geht es besser?
Ja, es geht mittlerweile sehr einfach und genau das habe ich mal probiert:
Man nehme OMD (Open Monitoring Distribution) und installiere diese auf OracleLinux6 als RPM.

wget -O - http://labs.consol.de/OMD/rh6/stable/omd.repo > /etc/yum.repos.d/omd.repo
yum search omd-

Nun das aktuelle Package von OMD installieren und warten bis fertig. Die notwendigen Abhängigkeiten werden aufgelöst, so das Du am Ende ein lauffähiges OMD hast. Der Apache muß noch aktiviert werden, da sonst nach nem Reboot die Weboberfläche nicht funktioniert.

Dann bekommt man fertig konfiguriert folgende Komponenten:

nagios
nagios-plugins
nsca
check_nrpe
Icinga
Shinken
nagvis
pnp4nagios
rrdtool/rrdcached
Check_MK
MK Livestatus
Multisite
dokuwiki
Thruk
Mod-Gearman
check_logfiles
check_oracle_health
check_mysql_health
jmx4perl
check_webinject
check_multi

Die Liste ist schon krank aber wirklich genial an dem System ist, das man nur das OS installieren muß, das RPM drauf packt und alle Komponenten sind zusammen installiert und miteinander konfiguriert. Den letzten Punkt konnte ich erst nicht glauben und habe es daher mal ausprobiert und kann bestätigen das es funktioniert. Ich habe nicht alles probiert, da ich mich vorerst mit Komponenten beschäftigen möchte, die mir bekannt sind.
Ich habe mir bisher folgendes angeschaut, die 'out of the box' funktionierten:
- Nagios Core
- pnp4nagios
- Check_MK
- Multisite
- Thruk
- MK Livestatus

=> Das ist alles was man so braucht. 🙂

Das hat mich sehr beeindruckt, da ein RPM + 2 Befehle für OMD zu einer lauffähigen Umgebung geführt haben.
check_mk rundet das ganze richtig toll ab, weil check_mk ein Agent auf dem zu überwachenden System mit bringt, der die zu konfigurierenden Services in Nagios automatisch generiert. (Das hatte mich früher abgeschreckt, weil ich hier starke Einschränkungen in der Flexibilität befürchtet habe, die sich jedoch nicht bestätigt haben.)
Man kann mit dieser Konfiguration innerhalb von Minuten zahlreiche Systeme in ein Nagios-Monitoring bringen, weil der Agent lediglich xinetd + Python auf dem zu überwachenden System benötigt. Der Agent ist so gebaut, das er problemlos mit Shell-Skript o.ä. erweitert werden kann.

check_mk und NRPE
Das ist schon eingebaut. Man kann bestehende Nagios-Plugins die für NRPE gebaut wurden in den Agenten von check_mk integrieren - also beliebig erweitern. Auch das war im Test sehr einfach. Analog zur nrpe.cfg muss man eine /etc/check_mk/mrpe.cfg erzeugen, die Einträge im passenden Format für check_mk eintragen und speichern.
Nun auf dem OMD den Client neu inventarisieren, die Konfig in Nagios übernehmen und der Check ist als Passivecheck eingebunden. (Erneute Verwunderung wie einfach das sein kann...)
Das hat aber einen Nachteil. check_mk inventarisiert die Checks automatisch aber sie müssen auf dem Agenthost konfiguriert werden, was beim alten NRPE aber ebenfalls notwendig war.

Wichtig ist. Es können alle bekannten Plugins von Nagios in check_mk eingebunden werden und das bei genauer Betrachtung mit weniger Aufwand als beim klassischen NRPE.

Ist OMD ernst zu nehmen?
Definitiv ja, da zahlreiche bekannte Personen hinter dem Projekt stehen. Mathias Kettner bietet eine kommerzielle Lösung von OMD an, die sich von der frei verfügbaren Lösung im Funktionsumfang kaum unterscheidet. Man bekommt dort auf Wunsch einen kommerziellen Support für OMD.
Es gibt eine wirklich große verteilte Installation die zeigt, was OMD kann:
http://mathias-kettner.de/check_mk_success_edeka.html

Fazit:
Nagios kann man so innerhalb von Minuten in lauffähiger Form bekommen. Einfach zu konfigurieren, Updates von OMD sind im Konzept von Grund auf eingeplant und man kann mehrere Nagioskonfigurationen parallel betreiben.
Den letzten Punkt finde ich besonderst lustig. Einfach mal eine neue Nagioskonfiguration auf dem bestehenden System aufsetzen, testen und bei Bedarf wieder weg werfen. Man kann auch eine bestehende Konfiguration kopieren, ändern oder auf einen neue Version von OMD bringen und bei Bedarf dann wieder entsorgen.
Hier braucht man zum Spielen keine 2 getrennten Systeme mehr, da man alles mit 1 System machen kannst und der Updatemodus ist halt von Haus aus vorgesehen, worauf die Entwickler gezielt geachtet haben.
check_mk ist so gewaltig, das ich die Möglichkeiten noch nicht alle verstanden habe. Das was ich bisher gesehen habe hat mich aber sehr überzeugt - ich werde definiiv auf OMD umsteigen und bin gerade dabei meinen heimischen Nagioshost von Grund auf neu zu bauen.

Der Verzicht auf NagiosQL als Administrationsfrontend ist mittlerweile zu verschmerzen, da es mit den neuen Versionen von Thruk oder der GUI von check_mk möglich ist, diesen Punkt zu ersetzen. Das war zum damaligen Bauzeitpunkt der Altumgebung noch nicht der Fall.

Gruß
Thorsten

Enable CPU-Hot Plug and RAM-Hot Add at Virtual machines on VMware vCenter 5

Update 12.02.2013 / Gabrie post in the comments a important extra info about Hot-Add and post the link to the blog from Duncan Eppinghttp://www.yellow-bricks.com/2012/01/16/enabling-hot-add-by-default-cc-gabvirtualworld/ it's important to read this!!!

vSphere Virtual Machine Administration, Chapter 8 “Configuring Virtual Machines”, Section “Change CPU Hot Plug Settings in the … Client”, page 94.

cpu-and-ram-hot-add

Some conditions and requirements for CPU Hot Plug

To enable new CPU after adding a new CPU. You can use this script:

Hot add cpu to supported Linux guestOS

#!/bin/bash
# William Lam
# http://engineering.ucsb.edu/~duonglt/vmware/
# hot-add cpu to LINUX system using vSphere ESX(i) 4.0
# 08/09/2009

for CPU in $(ls /sys/devices/system/cpu/ | grep cpu | grep -v idle)
do
CPU_DIR="/sys/devices/system/cpu/${CPU}"
echo "Found cpu: "${CPU_DIR}" ..."
CPU_STATE_FILE="${CPU_DIR}/online"
if [ -f "${CPU_STATE_FILE}" ]; then
STATE=$(cat "${CPU_STATE_FILE}" | grep 1)
if [ "${STATE}" == "1" ]; then
echo -e "t${CPU} already online"
else
echo -e "t${CPU} is new cpu, onlining cpu ..."
echo 1 > "${CPU_STATE_FILE}"
fi
else
echo -e "t${CPU} already configured prior to hot-add"
fi
done

Hot adding memory in Linux

ONLY for Suse Linux Enterprise Linux 11

Note: These instructions work for SLES OS. Other distributions may be different.

To enable acpi_memhotplug, run this command within the SLES virtual machine:

modprobe acpi_memhotplug

Using vSphere Client, edit the virtual machine settings to increase the memory assigned to the virtual machine. For more information, see Increasing the amount of memory assigned to a virtual machine (1004059).

Bring the memory online in /sys/devices/system/memory with the command:

echo online > /sys/devices/system/memory/memory[number]/state

Run this command to check the state of the memory, looking for memory that appears offline:

grep line /sys/devices/system/memory/*/state

If memory appears as offline, set it to online with the command:

echo online > /sys/devices/system/memory/memory[number]/state

Verify that you can see the extra memory with the command:

free -m

Expert Mode: PowerCLI

This Works when System is online, but need one "cold" start to enable this function.

Enable-MemHotAdd and Enable-vCpuHotAdd

Function Enable-MemHotAdd($vm){
$vmview = Get-vm $vm | Get-View
$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec

$extra = New-Object VMware.Vim.optionvalue
$extra.Key="mem.hotadd"
$extra.Value="true"
$vmConfigSpec.extraconfig += $extra

$vmview.ReconfigVM($vmConfigSpec)
}
Function Enable-vCpuHotAdd($vm){
$vmview = Get-vm $vm | Get-View
$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec

$extra = New-Object VMware.Vim.optionvalue
$extra.Key="vcpu.hotadd"
$extra.Value="true"
$vmConfigSpec.extraconfig += $extra

$vmview.ReconfigVM($vmConfigSpec)
}

 

Good information about hot-add cpu and memory can found here

 

Seit gestern den 22.01.201(2) 😉 ist nun Oracle VM 3.2 öffentlich für alle Verfügbar.

Hier der Pressebericht von Oracle: http://www.oracle.com/us/corporate/press/1899105

Mehr Informationen zum Thema Oracle VM 3.x findet man auf der Homepage von Oracle:

http://www.oracle.com/us/technologies/virtualization/oraclevm/overview/index.html

Alle Neuerungen die, die Version 3.2 mit sich bringt, findet man in der Data sheet: Oracle VM 3.2: What's New (PDF)

Die aktuellen Installationsdateien für Oracle VM 3.2 kann man hier herunterladen: https://edelivery.oracle.com/linux (Achtung es wird ein Account bei Oracle benötigt! Kostenlos!)

Viel Spaß mit der neuen Version!

Thorsten und ich werden sicherlich demnächst neues zu dem Thema hier im Blog für Euch zur Verfügung stellen!

Viele Grüße

Sven

Hallo,
neben dem Thema Virtualisierung beschäftige ich mich noch viel mit Oracle Grid-Infrastructure und Nagios.
Ich habe mir heute mal die Zeit genommen und ein entsprechendes Plugin geschrieben.

Getestet habe ich das Skript mit Oracle Restart 11.2.0.3 und Grid-Infrastructure 11.2.0.3. Es wird mindestens die Version 11.2.0.1 benötigt, da mit der Grid-Infrastructure die Syntax von crsctl grundlegend geändert wurde.

Folgende Punkte werden im Plugin berücksichtigt:

Im Kopfbereich des Plugins befindet sich ein Beispiel für die sudo-Konfiguration

Parallel habe ich das Plugin auf http://exchange.nagios.org eingereicht, warte dort aber noch auf die Veröffentlichung.

Gruß
Thorsten

Update: 23.01.2012
Das Plugin steht nun auch auf Nagiosexchange zur Verfügung:
http://exchange.nagios.org/directory/Plugins/Clustering-and-High-2DAvailability/Check-Oracle-Grid-2DInfrastructure-or-Oracle-Restart/details

(mehr …)

Beim Betrieb eines RAID-1 möchte man üblicherweise über einen Ausfall einer Platte möglichst sofort informiert werden, um sie schnellstmöglich tauschen lassen zu können.

Nach Installation des CIM-Providers von LSI für den LSI MegaRAID SAS 9260-4i wird auf der Hardware-Monitoring-Seite im vSphere-Client der Status des RAID angezeigt. Eine aktive Alarmierung ist aber nur in der kostenpflichtigen Version und bei Betrieb eines vCenter möglich - der vSphere-Client allein hat keine Alarmierungsfunktionalität.

Als Alternative installieren wir das "MegaCli" (ein Kommandozeilentool zum Management des RAID-Controllers) auf dem Host und richten ein Skript ein, das regelmäßig Hardwarestatus-Informationen zusammenstellt und per SCP an einen Server schickt, auf dem die Informationen weiter ausgewertet werden können.

In unserem Beispiel verwenden wir die Monitoring-Software "Zabbix", für die wir ein Skript, User-Parameter und ein Template zur Verfügung stellen. Mit etwas Erfahrung sollten sich die Skripts aber auch für andere Monitoring-Systeme anpassen lassen.

Skriptinstallation auf dem ESXi-Host

MegaCli installieren

In diesem Abschnitt der Installationsanleitung ist beschrieben, wie wir den MegaCli installieren.

Verzeichnis für die Skripts einrichten

Da der Großteil des ESXi-Dateisystems beim Booten neu zusammengesetzt und vorige Inhalte damit gelöscht werden, brauchen wir einen "sicheren Ort" für unsere Skripts und Dateien. Wir entschließen uns, ein Unterverzeichnis des Datastores zu benutzen, hier /vmfs/volumes/datastore1/lsi. Dieses legen wir an.

[bash]mkdir /vmfs/volumes/datastore1/lsi[/bash]

SSH-Key vom Monitoring-Server übertragen

Die fertigen RAID-Informationen sollen per SCP auf den Monitoring-Server geschickt werden. Damit dies automatisiert und ohne Kennworteingabe geht, brauchen wir ein "Identity-File", sprich den SSH Private Key des gewünschten Users auf dem Monitoring-Server.

In unserem Beispiel hat der Monitoring-Server den Hostnamen centaurus.tianet.de und der User heißt zabbix

Mit dem Kommando ssh-keygen erzeugen wir auf dem Monitoring-Server ein solches, falls der User noch keins hat. Die Passphrase lassen wir leer, da der ESXi-Host ohne Kennworteingabe den Key benutzen können muß.

[bash]zabbix@centaurus:~$ ssh-keygen

Generating public/private rsa key pair.
Enter file in which to save the key (/home/zabbix/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/zabbix/.ssh/id_rsa.
Your public key has been saved in /home/zabbix/.ssh/id_rsa.pub.
The key fingerprint is:
4c:60:c9:cb:0f:e4:92:c4:2a:40:60:86:af:82:0f:7b zabbix@centaurus
The key's randomart image is: [...][/bash]

Die Datei id_rsa kopieren wir per SCP auf den ESXi-Host ins richtige Verzeichnis. Dazu brauchen wir das Root-Kennwort.

[bash]zabbix@centaurus:~$ scp .ssh/id_rsa root@esxi.tianet.de:/vmfs/volumes/datastore1/lsi/centaurus_zabbix_id
The authenticity of host 'esxi.tianet.de (5.9.86.110)' can't be established.
RSA key fingerprint is 77:d8:25:f8:40:16:e6:6c:36:c1:ed:5f:8f:99:6e:b0.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'esxi.tianet.de,5.9.86.110' (RSA) to the list of known hosts.
Password:
id_rsa 100% 1675 1.6KB/s 00:00[/bash]

(mehr …)

Bei der Virtualisierung auf Hetzner-Servern ist es aus mehreren Gründen sinnvoll bzw. notwendig, die VMs an einen separaten virtuellen Switch anzuschließen und das so entstehende Netz über eine Router-VM mit dem Hetzner-Netz zu verbinden.

Dieser Abschnitt beschreibt, wie wir eine Router-VM auf Basis von "pfSense" einrichten. Es gibt natürlich unzählige weitere Routerlösungen. Wir haben uns für pfSense entschieden, weil diese sehr stabil läuft, einen großen Funktionsumfang bietet und eine komfortabel zu bedienende GUI aufweist.

Anlegen der VM

Wir loggen mit dem vSphere-Client am ESXi ein und erstellen eine neue virtuelle Maschine.

Grundkonfiguration

Configuration Custom
Name pfSense
Destination Storage datastore1
Virtual Machine Version 8
Guest OS: Other / FreeBSD (64-bit)
Number of virtual sockets 1
Number of cores per socket 1
Memory 256 MB

Netzwerkkonfiguration

Netzwerkkonfiguration

Storage-Konfiguration

SCSI Controller LSI Logic Parallel
Type of disk Create a new virtual disk
Disk Size 5 GB
Disk Provisioning Thick Provision Lazy Zeroed
Location Store with the virtual machine
Virtual Device Node SCSI (0:0)
Mode "Independent" unchecked

Abschließende Konfiguration

Wir setzen den Haken bei "Edit the virtual machine settings before completion" und führen folgende Schritte durch:

Konfiguration der MAC-Adresse
(mehr …)

Die Version vom Ausgelieferten ESXi-Server ist veraltet. Auslieferungs Build-Nummer: 623860

Die aktuellen Updates kann man direkt von der VMware-Homepage ziehen oder wie bei Virtualisierung mit VMware ESXi auf EX4 - Server-Vorbereitung beschrieben herunterladen.

Die aktuellen Patche kann man auch immer von hier ziehen: http://www.vmware.com/patchmgr/download.portal (Achtung, ESX kann kein WGET über HTTPS!)

Deswegen wird nun hier gezeigt, wie man die aktuellen Updates einspielt.

ESXi-Updates

Wir verwenden hier das Kommando esxcli software vib install anstelle von update, da "update" keine neuen VIBs installiert, sondern nur bereits existierende upgradet. "install" macht beides: es upgradet existierende VIBs und installiert fehlende. Bereits existierende VIBs, die im Zip nicht enthalten sind, bleiben in beiden Fällen unangetastet.

Wichtig: Vor der Installation von Updates sollten alle VMs heruntergefahren und der Host über den vSphere Client in den Maintenance Mode versetzt werden. Dies kann man natürlich auch mit Hilfe der CLI machen.

[bash]
# backup ESXi configuration to persist changes /sbin/auto-backup.sh
# enter maintenance mode
vim-cmd hostsvc/maintenance_mode_enter[/bash]

Installation von ESXi500-201204001 - Build Number: 653509

[bash]~ # esxcli software vib install --depot=/vmfs/volumes/datastore1/patches/ESXi500-201204001.zip
Installation Result
Message: Operation finished successfully.
Reboot Required: false
VIBs Installed: VMware_locker_tools-light_5.0.0-1.12.653509
VIBs Removed: VMware_locker_tools-light_5.0.0-1.11.623860
VIBs Skipped: VMware_bootbank_ata-pata-amd_0.3.10-3vmw.500.0.0.469512,
...[/bash]

Installation von ESXi500-201205001 - Build Number: 702118

[bash]~ # esxcli software vib install --depot=/vmfs/volumes/datastore1/patches/ESXi500-201205001.zip
Installation Result
Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
Reboot Required: true
VIBs Installed: VMware_bootbank_esx-base_5.0.0-1.13.702118
VIBs Removed: VMware_bootbank_esx-base_5.0.0-1.11.623860
VIBs Skipped: VMware_bootbank_ata-pata-amd_0.3.10-3vmw.500.0.0.469512, VMware_bootbank_ata-pata-atiixp_0.4.6-3vmw.500.0.0.469512, VMware_bootbank_ata-pata-cmd64x_0.2.5-3vmw.500.0.0.469512,
...[/bash]

Installation von ESXi500-201206001 - Build Number: 721882

[bash]~ # esxcli software vib install --depot=/vmfs/volumes/datastore1/patches/ESXi500-201206001.zip
Installation Result
Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
Reboot Required: true
VIBs Installed: VMware_bootbank_esx-base_5.0.0-1.16.721882
VIBs Removed: VMware_bootbank_esx-base_5.0.0-1.13.702118
VIBs Skipped: VMware_bootbank_ata-pata-amd_0.3.10-3vmw.500.0.0.469512, VMware_bootbank_ata-pata-atiixp_0.4.6-3vmw.500.0.0.469512,
...[/bash]

Installation von ESXi500-201207001 - Build Number: 768111

[bash]~ # esxcli software vib install --depot=/vmfs/volumes/datastore1/patches/ESXi500-201207001.zip
Installation Result
Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
Reboot Required: true
VIBs Installed: VMware_bootbank_esx-base_5.0.0-1.18.768111, VMware_bootbank_misc-drivers_5.0.0-1.18.768111, VMware_bootbank_net-e1000_8.0.3.1-2vmw.500.1.18.768111, VMware_bootbank_scsi-mptsas_4.23.01.00-5vmw.500.1.18.768111, VMware_locker_tools-light_5.0.0-1.18.768111
VIBs Removed: VMware_bootbank_esx-base_5.0.0-1.16.721882, VMware_bootbank_misc-drivers_5.0.0-1.11.623860,
...[/bash]

Installation von ESXi500-201209001 - Build Number: 821926

[bash]~ # esxcli software vib install --depot=/vmfs/volumes/datastore1/patches/ESXi500-201209001.zip
Installation Result
Message: Operation finished successfully.
Reboot Required: false
VIBs Installed: VMware_locker_tools-light_5.0.0-1.22.821926
VIBs Removed: VMware_locker_tools-light_5.0.0-0.0.469512
VIBs Skipped: VMware_bootbank_ata-pata-amd_0.3.10-3vmw.500.0.0.469512,
...[/bash]

Installation von allen Updates nach einander

[bash]esxcli software vib install --depot=/vmfs/volumes/datastore1/patches/ESXi500-201204001.zip
sleep 10
esxcli software vib install --depot=/vmfs/volumes/datastore1/patches/ESXi500-201205001.zip
sleep 10
esxcli software vib install --depot=/vmfs/volumes/datastore1/patches/ESXi500-201206001.zip
sleep 10
esxcli software vib install --depot=/vmfs/volumes/datastore1/patches/ESXi500-201207001.zip
sleep 10
esxcli software vib install --depot=/vmfs/volumes/datastore1/patches/ESXi500-201209001.zip
sleep 10
reboot[/bash]

Raid-Controller Update

Überprüfen der Firmware des Raid-Controllers

Die hier installierte Firmware ist die aktuellste von LSI.

[bash]/opt/lsi/MegaCLI # ./MegaCli -adpallinfo -a0|grep ^FW

FW Package Build: 12.12.0-0111
FW Version : 2.130.353-1663[/bash]

Installation des Firmware Updates vom Raid-Contoller

ACHTUNG! Bei unserem Testserver war die aktuellste Firmware schon installiert. Deswegen nur exemplarisch!

[bash]/opt/lsi/MegaCLI # ./MegaCli -adpfwflash -f /vmfs/volumes/datastore1/patches/mr2108fw.rom -a0

Adapter 0: LSI MegaRAID SAS 9260-4i
Vendor ID: 0x1000, Device ID: 0x0079

Package version on the controller: 12.12.0-0111
Package version of the image file: 12.12.0-0111
ERROR: The image file has older version than or same as that on the
controller. The controller is not flashed.

Exit Code: 0x01[/bash]

© 2011-2019 SJT CONSULTING – Alle Rechte vorbehalten. | Datenschutz | Impressum