Debian 8 (Jessie): Update über apt schlägt fehl

Will man ein Debian 8 mit apt-get update oder apt update updaten und schlägt dies mit einer Meldung wie dieser fehl

Fehl http://ftp.debian.org jessie-backports/main amd64 Packages 404 Not Found [IP: 130.89.148.12 80] W: Fehlschlag beim Holen von http://ftp.debian.org/debian/dists/jessie-backports/main/binary-amd64/Packages 404 Not Found [IP: 130.89.148.12 80] E: Einige Indexdateien konnten nicht heruntergeladen werden. Sie wurden ignoriert oder alte an ihrer Stelle benutzt.

liegt das daran, dass Debian im März 2019 die Sourcen verschoben haben – und die alten in der sources.list nicht mehr funktionieren.

Man muss jetzt nur die sources.list Datei in /etc/apt/ auf die neuen Quellen ändern:

deb http://security.debian.org/ jessie/updates main
deb-src http://security.debian.org/ jessie/updates main

deb http://archive.debian.org/debian/ jessie-backports main
deb-src http://archive.debian.org/debian/ jessie-backports main

deb http://archive.debian.org/debian/ jessie main contrib non-free
deb-src http://archive.debian.org/debian/ jessie main contrib non-free

Und zusätzlich muss noch folgender Befehl auf der Shell ausführt werden:

echo "Acquire::Check-Valid-Until false;" | tee -a /etc/apt/apt.conf.d/10-nocheckvalid

Jetzt sollte einem gepflegten apt update && apt upgrade -y nichts mehr im Wege stehen 🙂

Quelle: www.kernelhost.de

Upload zu Nextcloud aus der Konsole via cURL

Um Daten von der Konsole aus zu einer Nextcloud hochzuladen braucht es nur cURL :

curl -X PUT „https://meine.nextcloud.net/remote.php/webdav/Ordner/Datei.txt“ –data-binary @“Datei.txt“ -u nextcloud-user

Um also z.B. die Datei Backup.tar.gz in den Ordner Backup des Users cloud hochzuladen wäre der Befehl also:

curl -X PUT „https://meine.nextcloud.net/remote.php/webdav/Backup/Backup.tar.gz“ –data-binary @“Backup.tar.gz“ -u cloud

Super easy und man muss die Konsole nicht verlassen 🙂

Nextcloud 15: occ-Befehle nach Upgrade

Mir wurde nach einem Upgrade von meiner Nextcloud 14 auf die aktuelle Version folgendes angezeigt:

Um die Datenbankoperationen mit occ auszuführen musste ich folgendes machen :

per SSH auf dem Server und in das Nextcloud-Verzeichnis (bei mir /var/www/html/nextcloud) wechseln

cd /var/www/html/nextcloud

Dann zuerst die Indizies erstellen

sudo -u www-data php occ db:add-missing-indices

Und anschliesend die Konvertierung auf big int durchführen

sudo -u www-data php occ db:convert-filecache-bigint

Danach war die Datenbank glücklich 🙂

Und man kann sich an die anderen Meldungen machen 😉

Nginx: upstream timed out (110: Connection timed out)

Ich hatte bei einem Nginx als ReverseProxy das Problem das dieser oft in Fehler upstream timed out (110: Connection timed out) lief und so die Seite nicht funktionierte – der User bekam dann eine 504 Fehlerseite.

Ich habe das mit dem hinzufügen der beiden Zeilen

proxy_http_version 1.1;
proxy_set_header Connection „“;

gefixt – danach lief alles ohne Probleme.

Quelle: stackoverflow

Nginx: Einbinden von allen Domains erlauben

Ich hatte das Problem eine Seite bzw. Unterseite die unter einem Nginx als ReverseProxy lief so zu konfigurieren, dass diese sich von jeder Seite einbinden lassen lies. Dies verhindern aber eigentlich die sehr sinnvollen X-Frame-Options.

Diese lassen sich aber einfach mit proxy_hide_header X-Frame-Options für eine Seite oder auch nur für Unterseiten deaktivieren – hier ein Beispiel für eine Unterseite:

location /api {
    proxy_pass https://1.2.3.4/api;
    proxy_hide_header X-Frame-Options;
}

Nach einem Reload oder Restart des Nginx klappte mit der Einbindung 🙂

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://$server_name$request_uri;}

        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/

UniFi Controller: WebSocket connection error

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