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

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

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/

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 🙂

Wenn man einen UniFi Controller hinter einen ReverseProxy (in meinem Fall einen nginx) betreibt bekommt man oft nach dem einloggen einen WebSocket connection error

Das lässt sich einfach mit einer kleinen Konfig-Änderung am nginx-ReverseProxy beheben:

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection „upgrade“;

Diese Zeilen bewirken ein sauberes Weiterleiten von WebSocket-Aufrufen. Nachdem diese Zeilen die die Konfiguration eingetragen und der nginx seine Konfiguration neu geladen hat funktioniert der Aufruf ohne den Fehler 🙂

Hier noch meine nginx-Konfig:

server {
        listen 80;
        listen [::]:80;
 
        server_name unifi.domain.net;
 
        include /etc/nginx/snippets/letsencrypt.conf;
 
        # Redirect any HTTP request to HTTPS
        location / {
        return 301 https://unifi.domain.net;}
 
        error_log  /var/log/nginx/unifi-error.log;
        access_log /var/log/nginx/unifi-access.log;
}

server {
listen 443;
listen [::]:443;
server_name unifi.domain.net;

#cipers
ssl_protocols TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_ecdh_curve secp384r1; 
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off; 
ssl_stapling on; 
ssl_stapling_verify on;
resolver 8.8.8.8 valid=300s;
resolver_timeout 5s;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;

# Enable SSL
ssl on;
ssl_certificate /etc/letsencrypt/live/unifi.domain.net/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/unifi.domain.net/privkey.pem;
ssl_session_timeout 5m;

# Set global proxy settings
proxy_read_timeout      360;

proxy_http_version 1.1;
proxy_pass_request_headers on;

proxy_pass_header       Date;
proxy_pass_header       Server;

proxy_set_header        Host $host;
proxy_set_header        X-Real-IP $remote_addr;
proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header        Accept-Encoding "";

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

location / {proxy_pass https://localhost:8443;}

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

Quelle: nginx.org

Verbindet man Outlook für Mac von extern mit einem Exchange wird über den AutoDiscover-Mechanismus der Servername automatisch konfiguriert – bzw. geändert.

Problematisch ist es aber wenn hier der lokale Name des Exchange-Servers eingetragen wird – und somit keine Verbindung mehr zustande kommt.

Dieses Verhalten von Outlook kann man aber deaktiveren:

1) Outlook öffnen

2) AppleScript Editor öffnen (Script Editor.app in Programme/Dienstprogramme)

3) folgendes Script ausführen

tell application "Microsoft Outlook"
set background autodiscover of every exchange account to false
end tell

Danach den Servernamen im Outlook nochmal auf den externen Namen setzten – jetzt sollte der Servername nicht mehr geändert werden und die Verbindung funktionieren!

Wenn man auf einem Windows Server das Dedup-Feature einschaltet kann es passieren, dass der ChunkStore (dieser befindet sich in dem Ordner „System Volume Information“) in dem die Informationen für das Dedup gespeichert werden immer weiter wächst und so riesig wird das er teilweise den ganzen freien Platz auf dem Volume verbraucht.

Das kann man aber über einen DedupJob aber wieder fixen -hier am Beispiel eines Volumes F: :

eine Powershell als Administrator öffnen

und

Start-DedupJob -Volume “F:” -Type GarbageCollection -Memory 50

man kann mit

Get-DedupJob

überprüfen wie weit der Job schon ist.

Hilft dies nicht ist eine Möglichkeit noch die Deduplizierung rückgänging zu machen.

Dazu lässt man Dedup auf dem Volume aktiviert – deaktiviert aber die Hintergrundaktivität

Set-DedupSchedule BackgroundOptimization -enable $false

Start-DedupJob -Volume „F:“ -Type Unoptimization

Start-DedupJob -Volume “F:” -Type GarbageCollection

danach sollte der Chunk-Ordner weg sein – dann kann dedup bei Bedarf wieder aktiviert werden.

Wenn man einen Nginx als ReverseProxy für einen Upstream-Server verwendet der SNI verwendet (egal ob Apache, IIS, etc) , muss man dies in der Konfiguration des Nginx beachten – sonst klappt die Verbindung nicht und wirft 502-Errors.

Die Konfiguration ist allerdings ganz einfach:

location / {
    proxy_pass https://upstream-server;
    proxy_ssl_name $host;
    proxy_ssl_server_name on;
  }

So wird dem Upstream-Server „sauber“ mitgeteilt welche Webseite aufgerufen werden soll.

Und schon klappt der Aufruf über einen Nginx ReverseProxy 🙂

Hier eine kleine Beispiel-Komplett-Konfig:

server {
    listen                  443 ssl; 
    server_name             www.domain.com;
    ssl_certificate         /etc/nginx/ssl/domain/server.crt; 
    ssl_certificate_key     /etc/nginx/ssl/domain/server.key; 

    proxy_read_timeout      360;
    proxy_pass_header       Date;
    proxy_pass_header       Server;
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header        Accept-Encoding "";


    location / {
    proxy_pass https://1.2.3.4;
    proxy_ssl_name $host;
    proxy_ssl_server_name on;
    }

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

Quelle: serverfault.com

Auf einem Windows-Server (in dem Fall ein 2008 R2) mit IIS starteten die IIS-Dienste nicht, da der Windows-Prozessaktivierungsdienst mit folgender Fehlermeldung nicht starten wollte:

„Windows konnte den Prozessaktivierungsdienst nicht sarten – Fehler 6801: Die Transaktionsunterstützung im angegebenen Ressourcen-Manager wurde nicht gestartet oder aufgrund eines Fehlers heruntergefahren“

bzw.:

„Windows could not start the Windows Process Activation Service – Error 6801: Transaction support within the specified resource manager is not started or was shut down due to an error“

Das Problem kann man folgend lösen:

eine Eingabeaufforderung (cmd) als Administrator startet und folgenden Befehl ausführen:

fsutil resource setautoreset true c:\

Danach muss man den Server neu starten – jetzt sollte der WAS (Windows-Prozessaktivierungsdienst) wieder starten – und somit auch die davon abhängigen IIS-Dienste 🙂

Quelle: forum.iis.net