IIS: X-Forwarded-For Header im Log

Wenn man einen Microsoft Internet Information Services (IIS) hinter einem Reverse Proxy oder einem Load Balancer betreibt, sieht man in den Logs des IIS nur immer die IP-Adresse der Reverse Proxys bzw. dem Load Balancers und nicht die eigentliche IP des Clients.

Wenn der Reverse Proxy bzw. Load Balancer richtig konfiguriert wurde – z.B. bei Nginx wäre es

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

dann wird die IP des Clients an den IIS jedoch sauber übergeben.

Um diese jetzt in den Logs zu sehen muss jetzt nur noch der X-Forwarded-For-Header aktiviert werden.

Den IIS Manager starten und den Punkt Protokollierung öffnen

Dort bei Format auf Felder auswählen…

Dort auf Feld hinzufügen

Dort folgende Werte eintragen:

Feldname: x-forwarded-for
Quelltyp: Anforderungsheader
Quelle: X-Forwarded-For

und mit OK bestätigen.

nochmal mit OK bestätigen und auf Übernehmen klicken

Jetzt taucht im Log-Verzeichnis eine Log-Datei mit eine vorangestellten x_ auf – dort wird jetzt reingeloggt – mit dem X-Forwarded-For-Header und so auch mit der originalen Client-IP.

Quelle: www.loadbalancer.org

Exchange 2013 und 2016: Mails bleiben in Entwürfe hängen

Es gibt manchmal mal das Problem unter Exchange Server 2013 und 2016 dass Emails nicht versendet werden und in Entwürfe (Drafts) bzw. manchmal auch in Postausgang hängen bleiben.

Das Problem tritt sowohl in Outlook als auch in der Outlook Web App (OWA) auf.

Der Grund war bei mir bisher immer eine fehlerhafte DNS-Konfiguration des Exchanges!

Vor allem bei mehreren Netzwerkkarten oder bei mehreren DNS-Servern kann hier die Automatik versagen.

Einzustellen ist das am einfachsten in der ECP:

Hier stehen die DNS-Lookups (intern und extern) standardmäßig auf „Alle Netzwerkkarten“:

Hier kann die richtige Netzwerkkarte ausgewählt werden – oder auch ein DNS-Server manuell eingetragen werden:

Danach sollte das Problem gelöst sein 🙂

Quelle: thoughtsofanidlemind.com

PowerShell: Der watch-Befehl aus Linux

Unter Linux gibt es ja den watch-Befehl mit dem man einen Befehl alle x Sekunden wiederholen kann. Unter der Windows PowerShell gibts sowas leider standardmäßig nicht – aber man kann den Befehl mit Boardmitteln nachbauen:

while ($true) {Clear-Host; gci; sleep 15}

In diesem Beispiel wird zuerst mit Clear-Host die aktuelle Anezige der PowerShell gelöscht, dann gci ausgeführt und zum Schluss 15 Sekunden gewartet. Danach wiederholt sich das ganze bis man es mit STRG-C abbricht.

der Befehl lässt sich natürlich durch fast jeden anderen Befehl ersetzten 😉

Das ganze lässt sich gut für z.B. anzeigen von Verschiebeanforderungen bei Exchange benutzen:

while ($true) {Clear-Host; get-moverequest; sleep 15}

man kann auch Befehle kombinieren – z.B. das Datum anzeigen und etwas pingen

while ($true) {Clear-Host; date; ping 9.9.9.9; sleep 15}

VMware: Exportieren einer VM als OVA

In den Web-Interfaces der ESXi und vCenter fehlt die Funktion eine VM als OVA zu exportieren – es geht nur der Export als OVF (2 Dateien) – und eine OVA ist da doch deutlich schöner.

Früher konnte man das mit dem alten Windows-vSphere-Client sehr einfach machen – aber seit 6.5 ist das ja keine Alternative mehr 😉

Ein super einfacher und – wie ich finde – schöner Weg ist der Export mittels dem OFV-Tool von VMWare.

Das VMware Open Virtualization Format Tool kann hier runtergeladen werden:

https://my.vmware.com/group/vmware/details?downloadGroup=OVFTOOL420&productId=676

Nach der Installation führen wir das Tool aus (hier am Beispiel von Windows – unter Linux und MacOS ähnlich):

ovftool.exe --noSSLVerify vi://root@ip.des.esxi.host/name-der-vm c:\export\vm-name.ova

Also z.B.:

ovftool.exe --noSSLVerify vi://root@192.168.178.220/sv-reverse c:\Users\schaloml\Downloads\sv-revese.ova

Kurze Erklärung:
–noSSLVerifiy -> Keine Prüfung des SSL-Zetifikats
vi://root@ip.des.esxi.host/name-der-vm -> hier wird die Verbindung zum ESXi bzw. vCenter mit dem angegebenen User hergestellt
c:\Users\schaloml\Downloads\sv-revese.ova -> Export-Pfad und Name der Datei

Insgesamt also super einfach zu bedienen und erfüllt seinen Zweck 🙂

VMware: Systemprotokolle auf dem Host abc.xyz werden in einem nicht beständigen Speicher gespeichert

Bei Installationen des ESXi auf einem USB-Stick oder einer SD-Karte wird die Warnung „Systemprotokolle auf dem host abc.xyz werden in einem nicht beständigen Speicher gespeichert„ angezeigt. VMware logt nämlich nicht auf USB-Speicher und Sd-Karten – den die sind nach VMWare-denke „volatil“. Nur Festplatten (respektive Datastores) sind beständig.

Einen Lösungsweg hab ich schon hier beschrieben – hier will ich aber meine aktuelle und bevorzugte Lösung beschreiben – der dazu noch ohne Neustart auskommt 🙂

Um das Problem der Protokolle zu lösen, lasse ich die ESXi-Hosts ihre Protokolle auf den Syslog-Server des vCenters ablegen.

Dazu wird auf dem jeweiligen Host unter

Verwaltung – Erweiterte Einstellungen

in dem Eintrag

„Syslog.global.loghost“

die Adresse des Syslog-Server des vCenter-Servers eintragen.

Das Format lautet: udp://ip.des.vCenter.Server:514

fertig 🙂

Hinweis: Der Syslog-Server (Syslog Collector) ist ab der Version 6 standardmäßig an – bei älteren Version muss er noch aktiviert werden: Eine Anleitung hirzu gibts hier

Quelle: thomas-krenn.com

ESXi 6.5 U1: Upgrade schlägt fehl

Ich wollte einen ESXi auf 6.5 U1 upgraden – doch das Upgrade auf einem USB-Stick installierten Server ist mit folgender Fehlermeldung abgebrochen:

[InstallationError]
Failed updating the bootloader: Execution of command /usr/lib/vmware/bootloader-installer/install-bootloader failed: non-zero code returned
return code: 1
output: ERROR: ld.so: object ‚/lib/libMallocArenaFix.so‘ from LD_PRELOAD cannot be preloaded: ignored.
Traceback (most recent call last):
File „/usr/lib/vmware/bootloader-installer/install-bootloader“, line 238, in
main()
File „/usr/lib/vmware/bootloader-installer/install-bootloader“, line 223, in main
partType, diskGeom, parts = getDiskInfo(diskPath)
File „/usr/lib/vmware/bootloader-installer/install-bootloader“, line 151, in getDiskInfo
rc, out, err = execCommand(command)
File „/usr/lib/vmware/bootloader-installer/install-bootloader“, line 94, in execCommand
raise Exception(„%s failed to execute: status(%d)“ % (command, process.returncode))
Exception: /sbin/partedUtil getptbl /vmfs/devices/disks/naa.200049454505080f failed to execute: status(255)
vibs = VMware_bootbank_esx-base_6.5.0-1.26.5969303
Please refer to the log file for more details.

Ich habe das Problem mit dem deaktivieren des neuen USB-Treibers gelöst:

esxcli system module set -m=vmkusb -e=FALSE

danach reboot und dann nochmal das Upgrade versucht -> funktioniert.

Nach dem erfolgreichen Upgrade sollte man den Treiber wieder mit

esxcli system module set -m=vmkusb -e=TRUE

aktivieren.

Nach einem weiteren Reboot ist man dann wieder up-to-date 🙂

Quellen: VMWare und VMWare-Forum

Vim: Automatischen Visual Mode bei Maus-Benutzung deaktivieren

Ich bin ja ein eingefleischter Vim-Benutzer. Doch manchmal öffnet man Vim und es geht der Visual Mode automatisch an weil er erkennt dass man eine Maus benutzt – gerne wenn man mit Putty unter Windows arbeitet.

Ich mag den Visual Mode aber so gar nicht und deaktiviere ihn eigentlich immer.

Das geht einfach wenn man im Vim ist mit:

:set mouse-=a

Wenn man es grundsätzlich ausschalten will fügt man einfach folgende Zeile in die vimrc-Datei ( vim ~/.vimrc ) ein:

set mouse-=a

Einfügen (oder die Datei erstellen) und speichern. Beim nächsten Start von Vim sollte der Modus deaktiviert sein 🙂

Quelle: http://www.varesano.net/blog/fabio/disable+vim+automatic+visual+mode+using+mouse

Let’s Encrypt mit NGINX auf Debian

Ich setze den NGINX ja gerne sowohl als Web Server als auch als Reverse Proxy ein – fast genauso gerne setzte ich mittlerweile die Let´s Encrypt Zertifikate ein.

Ich hab jab hier schon eine Anleitung geschrieben wie man das auf Ubuntu einrichtet – aber mittlerweile mach ich hauptsächlich Server mit Debian – deshalb hier eine kleine Anleitung wie ich das immer unter Debian konfiguriere:

1) Erstellen eines NGINX-Config-Snippet

wir erstellen einen Config-Datei

vim /etc/nginx/snippets/letsencrypt.conf

und dort einfügen (gegebenfalls das Verzeichnis unter root ändern):

location ^~ /.well-known/acme-challenge/ {
default_type „text/plain“;
root /var/www/letsencrypt;
allow all;
}

und mit :wq abspeichern.

2) Anpassen der bestehenden NGINX-Konfig

Ich konfiguriere eigentlich meine Webseiten immer als HTTPS-only – das heißt jede Anfrage auf Port 80 (HTTP) auf 443 (HTTPS) umgeleitet.

Da die Domänen-Verifizierung von Let´s Encrypt über einen HTTP Aufruf gemacht wird, müssen wir allerdings hier eine Ausnahme erstellen.

Dazu passen wir unsere Webseiten Konfig an:

vim /etc/nginx/sites-available/meineseite

und fügen unser Snippet mittels include in dem Serverteil für HTTP hinzu:

server {
        listen 80;
        listen [::]:80;

        server_name www.meineseite.de;

	include /etc/nginx/snippets/letsencrypt.conf;

        # Redirect any HTTP request to HTTPS
        location / {
        return 301 https://www.meineseite.de;}

        error_log  /var/log/nginx/meineseite-error.log;
        access_log /var/log/nginx/meineseite-access.log;
}

Der Serverteil für HTTPS braucht hier nichts angegeben werden – wir haben ja auch noch keine Zertifikate 😉

3) Installieren des Let´s Encrypt Clients

Installation unter Debian 9 (Stretch):

sudo apt-get install certbot

Installation unter Debian 8 (Jessie):

Bei Debian 8 muss der Client über die Backports installiert werden.

Dazu müssen zuerst die Backports in den Apt-Sources eingetragen werden:

sudo vim /etc/apt/sources.list

und dort die Zeile

deb http://ftp.debian.org/debian jessie-backports main

ans Ende anfügen und mit :wq speichern und den vim verlassen.

Danach die Sources updaten:

sudo apt-get update

und mit

sudo apt-get install certbot -t jessie-backports

4) erstellen des root-Verzeichnises für Let´s Encrypt

sudo mkdir -p /var/www/letsencrypt/.well-known/acme-challenge

Ich vergebe auch noch entsprechende Rechte (meistens läuft der NGINX ja als www-data User bzw. der User ist in der www-data-Gruppe)

sudo chown -R www-data:www-data /var/www/letsencrypt

5) NGINX reload

sudo systemctl reload nginx

6) Let´s Encrypt Client auführen

Jetzt kann der Client ausgeführt werden – hier als Beispiel für die Domänen meineseite.de und www.meineseite.de (mittels -d domain.tld können noch weitere Domains – falls benötigt – hinzugefügt werden)

sudo certbot certonly --webroot -w /var/www/letsencrypt -d meineseite.de -d www.meineseite.de

dann gibt man eine Mail-Adresse ein und bestätigt mit A die Lizenz-Bedingungen.

Falls alles geklappt hat werden jetzt die Zertifikate ausgestellt – zu finden sind die Zertifikate unter /etc/letsencrypt/live/www.meineseite.de

7) HTTPS-Konfig am NGINX

Jetzt müssen wir noch die HTTPS-Konfig mit unseren neuen Zertifikaten hinzufügen bzw. anpassen.

vim /etc/nginx/sites-available/meineseite

und die Zertifikate im der HTTPS Konfiguration angeben

ssl_certificate /etc/letsencrypt/live/www.meineseite.de/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/www.meineseite.de/privkey.pem;

mit :wq speichern.

jetzt noch die Konfiguration am NGINX neu laden

systemctl reload nginx

und wir müssten jetzt die Seite mit einem wunderbaren Zertifikat öffnen können 🙂

8) Renew automatisieren

Die Let´s Encrypt Zertifikate haben die Einschränkung, dass sie nur 90 Tage gültig sind. Man kann hier aber über einen cron-job Abhilfe leisten:

sudo crontab -e

und die folgenden Zeilen hinzufügen

30 2 * * 1 certbot renew >> /var/log/le-renew.log
35 2 * * 1 systemctl reload nginx

so wird automatisch das Zertifikat verlängert und die Konfig des NGINX aktualisiert

9) fertig 🙂

Quelle: https://certbot.eff.org/

Checkpoint: Management-Zertifikat erneuern

Ich hatte bei einem Checkpoint-Cluster (ClusterXL, R77.30, Gaia) das Problem das das Management-Zertifikat abgelaufen ist. Über das SmartDashboard war keine Verlängerung – oder ein Neuausstellen – möglich. Administration des Clusters war auch nicht mehr sauber möglich, da die Kommunikation natürlich über Zertifikate läuft…

Über die CLISH (Expert-Modus) auf der betroffenen Maschine war ein erstellen eines neuen Zertifikats aber zum Glück noch möglich:

1. Backup des derzeitigen Zertifikats

mv $CPDIR/conf/sic_cert.p12 $CPDIR/conf/sic_cert.p12_BACKUP

2. Wiederrufen des derzeitigen Zertifikats

cpca_client revoke_cert -n „CN=cp_mgmt“

3. Neues Zertifikat erstellen

cpca_client create_cert -n „CN=cp_mgmt“ -f $CPDIR/conf/sic_cert.p12

4. Neustarten der Check Point Services:

cpstop && cpstart

Danach liefen alle Dienste wieder sauber und eine Administration des Clusters war wieder ohne Probleme möglich 🙂