ITrig

Bei Arbeiten mit ESXi Servern, ist es sinnvoll auf allen virtuellen Maschinen VMware Tools zu installieren. Auf Windows Maschinen ist die kein Problem, ein Rechtsklick auf die virtuelle Maschine und "VMware Tools installieren/aktualisieren" und schon sind die Tools quasi aktiv.

Bei Linux Geräten müssen neben diesem ersten Schritt noch ein paar weitere ausgeführt werden.

VMware Tools in CentOS installieren

yum install make gcc kernel-devel kernel-headers glibc-headers perl

mkdir /mnt/cdrom

mount /dev/cdrom /mnt/cdrom

cd /tmp/

tar xvf /mnt/cdrom/VMwareTools-9.*.tar.gz

cd vmware-tools-distrib/

./vmware-install.pl -d

umount /mnt/cdrom/

Der Parameter "-d" hinter dem Perlskript bewirkt das automatische Bestätigen aller Abfragen während der Installation.

VMware Tools in Ubuntu installieren

Die Quick and Dirty Methode ist hier sicherlich die freie Alternative der VM Tools via sudo apt-get install open-vm-tools zu installieren. Wer dennoch auf die offizielle Variante zurückgreifen möchte, der führt folgendes aus.

sudo apt-get install make gcc

sudo mkdir cdrom

sudo mount /dev/cdrom /mnt/cdrom

cd /tmp

ls -l /mnt/cdrom/

sudo tar zxf /mnt/cdrom/VMwareTools-9.*.gz

cd vmware-tools-distrib/

./vmware-install.pl -d

umount /mnt/cdrom/

Kleiner Tipp zum Wochenende. Solltet ihr beim Versuch Updates via apt-get upgrade einzuspielen, folgende Fehlermeldung erhalten:

WARNING: The following packages cannot be authenticated!

linux-image-3.8.0-xx-generic...

Install these packages without verification [y/N]?

Dann müsst ihr zu vor noch die Keys und  Repositories aktualisieren

sudo apt-key update

sudo apt-get update

sudo apt-get upgrade

Und schon ist die Fehlermeldung verschwunden

Die Tage gab es seitens Dell mal wieder ein OMSA Update. Bei der letzten Aktualisierung gab es bereits Probleme und siehe da, aktuell ist es ähnlich. Sobald die neue Version (7.4) installiert ist, startet OMSA nicht mehr und wirft Fehler wie z.B.:

DRAC4 probe: DRAC4 pci device not found                    [FAILED]

oder

Unable to get install path from file: /opt/dell/srvadmin/etc/omreg.cfg

Tauchen solche Fehler auf, ist bei der Installation etwas schiefgegangen. Gut, das sollte jedem schnell klar sein ;).

Ursachen kann dies viele haben. Eventuell wurde das falsche Repository verwendet oder eine falsche Architektur. Die neueste OMSA Version kann nicht mehr nur 32bit, sondern auch 64bit.

OMSA Installation reparieren 

Auch wenn die Ursache für den Fehler nicht genau bekannt ist, gibt es einen schnellen Weg dieses Problem zu lösen.

 

• Deinstallieren bzw. Löschen der Betroffenen Pakete und Verzeichnisse.
• Das aktuelle Repository herunterladen (Hier ein Überblick der verfügbaren Versionen)  
• OMSA neu Installieren 
• Dienste neu starten

Auf einem CentOS System sieht die Befehlskette wie folgt aus. Bei anderen Distributionen dürfte es ähnlich sein.

Tipp: Schaut auf der Repo Seite, dass ihr das richtige Repository wählt. Ich habe hier das aktuellste (Q1 2014) gewählt

cd /

yum remove dell-omsa* libcmpiCppImpl0 libsmbios libsmbios* libwsman* openwsman-*

yum remove python-smbios smbios-utils-**

yum remove srvadmin-*

rm -rf /etc/openwsman

rm -Rf /opt/dell/srvadmin

wget -q -O - http://linux.dell.com/repo/hardware/Linux_Repository_14.04.00/bootstrap.cgi | bash

yum install srvadmin-all

srvadmin-services.sh start

sudo service snmpd restart

 

Vor einiger Zeit hatte ich einen kleinen Beitrag zur SSL Zertifikaten geschrieben. Damals ging es um die Erstellung einer Anfrage und das eigene Signieren einer Zertifizierungsanforderung. Hin und wieder kann es jedoch vorkommen, dass genau diese CSR Datei noch einmal lesbar ausgelesen werden muss, um die zuvor gemachten Eingaben zu prüfen.

Wird eine CSR Datei in einem Editor geöffnet, werden nur kryptische Inhalte ausgegeben, eingefasst von einem -----BEGIN CERTIFICATE REQUEST----- und einem -----END CERTIFICATE REQUEST-----.

Eine für Menschen leserliche Ausgabe lässt sich mit einem einfachen Konsolenbefehl erreichen.

ubuntu:~$ openssl req -in test.csr -noout -text

Certificate Request:

    Data:

        Version: 0 (0x0)

        Subject: C=DE, ST=Some-State, O=Internet Widgits Pty Ltd, CN=itrig.de

        Subject Public Key Info:

            Public Key Algorithm: rsaEncryption

                Public-Key: (2048 bit)

                Modulus:

                    00:a1:4e:b4:77:61:1a:ee:1c:65:2b:e7:e0:5f:6a:

                    34:83:ff:a4:35:a7:b3:13:63:ac:dd:10:a1:ee:eb:

                    d5:fb:2c:36:93:03:bd:72:88:4f:74:b6:79:d7:05:

                    73:c6:82:37:4b:81:87:db:fa:c6:66:01:79:16:e1:

                    d9:c3:d8:39:80:d4:da:4d:da:76:f1:44:59:c4:01:

                    37:1d:90:44:7c:7f:9a:f9:66:d6:9e:0a:6b:99:5f:

                    .........

PS: Solltet ihr Open SSL verwenden, vergesst das Aktualisieren nicht.

Für den Exchange Server, speziell für die 2013er Version, hatte ich erst vor wenigen Wochen ein paar praktische Befehle für die Exchange Management Shell vorgestellt. Damals ging es hauptsächlich um die Rechtevergabe oder Auswertungen von Einstellungen.

Heute soll es ebenfalls um Auswertungen gehen, aber dieses Mal in Bezug auf die Exchange Funktion an sich, den E-Mailverkehr. Gemeint ist damit das sogenannte Message Tracking Log, welches auf dem Exchange Server grobe forensische Methoden liefert, um den Mailverkehr oder einzelne Mailzustellungen zu untersuchen.

Ich ziehe auch unter Exchange 2013 die Auswertung via Shell vor, es wird zwar auf eine Analyse via Weboberfläche verwiesen. Diese ist aber mehr als schäbig und bringt nicht den gewünschten Komfort einer Konsole mit.

Somit muss für die folgenden Abfragen zunächst die Exchange Management Shell auf dem zu untersuchenden Server gestartet werden. Die Angaben eines Servers, in den kommenden Befehlen habe ich bewusst weggelassen, wer mehrere Server im Betrieb hat, kann eine genaue Auswahl mit "-Server Name" gerne treffen.

Befehle zur Nachrichtenuntersuchung - Exchange Server 2010/2013

Gesamten Mailverkehr ausgeben

Die Ausgabe erfolgt der Übersicht wegen, immer über die sogenannte GridView

Get-MessageTrackingLog | Out-Gridview

Mailverkehr mit Sender, Empfänger, Betreff und Datum anzeigen

Get-MessageTrackingLog -ResultSize Unlimited | select-object eventid,timestamp,source,messageid,sender,recipients,messagesubject | Out-Gridview

Mailverkehr eines bestimmten Datums ausgeben

Get-MessageTrackingLog -ResultSize Unlimited -Start "03 31 2014" | select-object eventid,timestamp,source,messageid,sender,recipients,messagesubject | Out-Gridview

E-Mails eines Zeitraums anzeigen

Get-MessageTrackingLog -ResultSize Unlimited -Start "03 31 2014" -End "04 02 2014"| select-object eventid,timestamp,source,messageid,sender,recipients,messagesubject | Out-Gridview

E-Mails eines bestimmten Nutzer in einem Zeitraum suchen

get-messagetrackinglog -Start "03 31 2014" -End "04 02 2014" -sender: nutzer@domain.de | Select timestamp,EventID,recipients,messagesubject | Out-Gridview

E-Mails eines bestimmten Nutzer in einem Zeitraum suchen und in Datei abspeichern

get-messagetrackinglog -sender: nutzer@domain.de | Select timestamp,EventID,recipients,messagesubject | Out-File D:\Maillog.txt

Mails eines bestimmten Zeitraums sortiert in Datei ablegen 

Get-MessageTrackingLog -ResultSize Unlimited -Start "03 31 2014" -End "04 02 2014" | sort Timestamp | Select timestamp,EventID,recipients,messagesubject | Out-File D:\Maillog-sortiert.txt