Skip to content

NGINX - Installation

NGINX
  • Es gibt da ein kleines Problem, was einige verwirren könnte. Wenn man NGINX aus den normalen Repos installiert, bekommt man auf Debian 10.1 folgende Version.

    root@rockpro64:/etc/nginx/sites-enabled# nginx -v
    nginx version: nginx/1.14.2
    

    Diese Installation arbeitet mit /etc/nginx/sites-enabled und dem Pfad /var/www/html

    Und deinstalliert.

    apt purge nginx
    

    Aufpassen, verschiedene Ordner blieben bestehen. Habe ich alle von Hand gelöscht. Als nächstes gehen wir nach der Anleitung von NGINX vor. https://nginx.org/en/linux_packages.html#Debian

    Step 1

    apt install curl gnupg2 ca-certificates lsb-release
    

    Macht nix, alles schon da.

    Step 2

    echo "deb http://nginx.org/packages/debian `lsb_release -cs` nginx" \
        | sudo tee /etc/apt/sources.list.d/nginx.list
    

    Das macht folgendes

    nano /etc/apt/sources.list.d/nginx.list
    

    Inhalt der Datei

     deb http://nginx.org/packages/debian buster nginx
    

    Step 3

    curl -fsSL https://nginx.org/keys/nginx_signing.key | sudo apt-key add -
    

    Als nächstes wird der Key gecheckt.

    root@rockpro64:/etc# apt-key fingerprint ABF5BD827BD9BF62
    pub   rsa2048 2011-08-19 [SC] [expires: 2024-06-14]
          573B FD6B 3D8F BC64 1079  A6AB ABF5 BD82 7BD9 BF62
    uid           [ unknown] nginx signing key <signing-key@nginx.com>
    

    Sieht so weit alles gut aus. Dann wie gewohnt.

    apt update
    apt install nginx
    

    Doch hier ein Problem

    N: Skipping acquire of configured file 'nginx/binary-arm64/Packages' as repository 'http://nginx.org/packages/debian buster InRelease' doesn't support architecture 'arm64'
    

    Hmm, kein arm64 Paket von NGINX!?

    fef101ac-3a97-4bce-a0b1-4091d831471a-grafik.png

    Ok, dann auf einem Ubuntu Bionic Minimal 🙂

    6f82b5da-c57e-4b04-972a-beab4c88bada-grafik.png

    Installation nach -> https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-open-source/#prebuilt_ubuntu

    Nach der Installation erhält man folgendes

    rock64@rockpro64:/etc/apt$ nginx -v
    nginx version: nginx/1.17.4
    

    Wir sind also auf der letzten "Mainline" Version von NGINX. Aber hier gibt es

    • /var/www/ nicht mehr
    • /etc/nginx/sites-enabled nicht mehr

    Was ist jetzt anders?

    Nicht so viel, man muss es nur wissen.

    In /etc/nginx findet man die

    • nginx.conf

    Unter /etc/nginx/conf.d findet man die Config Dateien der einzelnen Webseiten, hier im Beispiel die

    • default.conf

    Und die Daten der Webseiten findet man unter /usr/share/nginx/html

    rock64@rockpro64:/etc/nginx/conf.d$ ls -lha /usr/share/nginx/html
    total 16K
    drwxr-xr-x 2 root root 4.0K Oct  1 08:52 .
    drwxr-xr-x 3 root root 4.0K Oct  1 08:52 ..
    -rw-r--r-- 1 root root  494 Sep 24 14:49 50x.html
    -rw-r--r-- 1 root root  612 Sep 24 14:49 index.html
    

    Nach was, der NGINX Server ist nicht automatisch gestartet.

    rock64@rockpro64:/etc/nginx/conf.d$ sudo service nginx status
    ● nginx.service - nginx - high performance web server
       Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
       Active: inactive (dead)
         Docs: http://nginx.org/en/docs/
    

    Mit

    sudo service nginx start
    

    ist das dann auch erledigt.

    Fazit

    Ich wollte hier kurz aufzeigen, das es Unterschiede gibt, ob man NGINX aus den Repos installiert oder man die Daten direkt von NGINX benutzt. Mit dem Wissen darüber, ist es nicht so schwer auch die vielen Tutorials im Netz zu verstehen. Hat mich lange verwirrt, bis ich endlich begriffen hatte, warum das so ist.

    In der Praxis ist das hinterher völlig egal. Macht beides das Gleiche, wobei ich es besser finde da ich jetzt den Zwischenschritt mit dem symbolischen Link los bin.

    zusätzlich haben wir gelernt, das es nicht für jede Distribution arm64 Pakete gibt 🙂

  • 0 Stimmen
    1 Beiträge
    122 Aufrufe
    Niemand hat geantwortet
  • Crowdsec - Ein fail2ban Ersatz?

    Linux
    2
    0 Stimmen
    2 Beiträge
    493 Aufrufe
    FrankMF

    Ich kann jetzt hier von meiner ersten Erfahrung berichten und wie CrowdSec mich gebannt hat 🙂

    Was war passiert? Ich war gestern sehr intensiv mit der Konfiguration von Nextcloud <-> Collabora Online beschäftigt. Nachdem ich irgendwie nicht weiterkam habe ich mich der Erstellung eines Dokumentes gewidmet. Nach einiger Zeit war die Nextcloud nicht mehr erreichbar.

    Ok, hatte ich bei der Konfiguration auch schon mal, den Server einmal neugestartet und fertig. Doch jetzt kam es, Server neugestartet - hilft nicht. Gut, schauen wir mal nach, Der SSH Login ging auch nicht 😞

    Jetzt war guter Rat gefragt. Zu diesem Zeitpunkt ging ich noch davon aus, das auf diesem Server kein CrowdSec installiert war, sondern fail2ban. Und fail2ban hatte eine sehr kurze Bantime vom 10M.

    Also blieb wohl nur noch das Rescue System von Hetzner.

    488866bc-3dcf-4abc-9e98-6107d65aa4c7-grafik.png

    Da hatte ich ja so gut wie gar keine Erfahrung mit. Also mal kurz den Nico angetriggert und es kam folgender Link.

    Link Preview Image Hetzner Rescue-System - Hetzner Docs

    favicon

    (docs.hetzner.com)

    Das Laufwerk war schnell bestimmt und schnell nach /tmp gemountet. Danach musste man sich noch mit chroot in diese Umgebung anmelden.

    chroot-prepare /mnt chroot /mnt

    Nachdem das klappte, habe ich eben fail2ban disabled.

    sysmctl disable fail2ban

    Danach das Rescue beendet. Der Server startete wieder und ich kam wieder per SSH drauf. Puuh.
    Bei meiner ersten Kontrolle fiel mir was auf

    root@:~# pstree systemd─┬─2*[agetty] ├─atd ├─cron ├─crowdsec─┬─journalctl │ └─8*[{crowdsec}] ├─crowdsec-firewa───9*[{crowdsec-firewa}]

    Wie? Da läuft CrowdSec? Da ich dabei bin die Server auf CrowdSec umzustellen, war das wohl hier schon gemacht, aber leider nicht vernünftig. fail2ban hätte mindestens disabled werden müssen und in meiner Dokumentation war das auch nicht enthalten. 6 setzen!

    CrowdSec besteht ja aus zwei Diensten, CrowdSec und dem Firewall-Bouncer. Der CrowdSec Dienst lief aber nicht, der war irgendwie failed. Ok, starten wir ihn und schauen was passiert. Nachdem er gestarte war mal die Banliste angeschaut.

    cscli decisions list

    ergab diesen Eintrag.

    2551501 │ crowdsec │ Ip:5.146.xxx.xxx │ crowdsecurity/http-crawl-non_statics │ ban │ │ │ 53 │ 1h5m55.391864693s │ 1671

    Meine IP war gebannt. Dann wissen wir ja , woher die Probleme kamen.

    cscli decisions delete --id 2551501

    Nach Eingabe war der Ban entfernt. Na gut, aber da ich aktuell immer noch an der richtigen Konfiguration von NC <-> CODE bastel, könnte das ja wieder passieren. Was machen? Kurz gegoogelt. Es gibt eine Whitelist. Aha!

    /etc/crowdsec/parsers/s02-enrich/whitelists.yaml

    name: crowdsecurity/whitelists description: "Whitelist events from private ipv4 addresses" whitelist: reason: "private ipv4/ipv6 ip/ranges" ip: - "127.0.0.1" - "::1" - "5.146.XXX.XXX" cidr: - "192.168.0.0/16" - "10.0.0.0/8" - "172.16.0.0/12" # expression: # - "'foo.com' in evt.Meta.source_ip.reverse"

    Danach den Dienst neustarten. Jetzt hoffen wir mal, das es hilft.

    Zum Schluss noch was, was mir aufgefallen war und was mich auch sehr verwirrt hatte. CrowdSec hatte wegen einem crowdsecurity/http-crawl-non_statics gebannt. Dadurch konnte ich meine
    subdomain.<DOMAIN> nicht erreichen. Ok, logisch, wenn der Ban von da ausgeht. Ich konnte aber gleichzeitig eine andere subdomain mit derselben <DOMAIN> auch nicht erreichen. Komplett verwirrte es mich dann, als ich eine andere <DOMAIN> auf dem selben Server erreichen konnte. Und zum Schluss ging auch der SSH nicht.

    Also, wieder viel gelernt.. 🤓

  • EndeavourOS - ein Test

    Linux
    12
    0 Stimmen
    12 Beiträge
    174 Aufrufe
    FrankMF

    Ich möchte aus Fairness Gründen hier festhalten, das die Probleme mit dem Standby in Endeavour vermutlich kein Problem der Distrubution sind.

    Bitte dazu folgenden Beitrag von mir lesen.
    https://linux-nerds.org/topic/1397/debian-bookworm-12-test/3

  • Linux Mint Cinnamon 20.2 "Uma" released

    Linux
    3
    0 Stimmen
    3 Beiträge
    236 Aufrufe
    FrankMF

    Was noch gestört hatte, war der Scrollbalken im FF. Der war zu schmal, konnte man schlecht erwischen.

    8e403120-11e2-413f-a479-0ebc3002e6d4-grafik.png

    Quelle: https://forums.linuxmint.com/viewtopic.php?f=47&t=330849&sid=1c7c71850931d5c34d8a0dd41ff57679

  • NGINX - Grundlagen worker_processes

    NGINX
    1
    0 Stimmen
    1 Beiträge
    223 Aufrufe
    Niemand hat geantwortet
  • NGINX - www entfernen

    NGINX
    2
    0 Stimmen
    2 Beiträge
    283 Aufrufe
    FrankMF

    Es geht noch eleganter. Für eine Domain wie frank-mankel.de z.B. so. Muss das mal hier parken, damit ich nicht immer wieder danach suchen muss.

    server { server_name www.example.com example.com; return 301 https://example.com$request_uri; } server { listen 443 ssl; ssl_certificate /path/to/server.cert; ssl_certificate_key /path/to/server.key; server_name www.example.com; return 301 https://example.com$request_uri; } server { listen 443 ssl; ssl_certificate /path/to/server.cert; ssl_certificate_key /path/to/server.key; server_name example.com; <locations for processing requests> }

    Quelle: https://serverfault.com/questions/258378/remove-www-and-redirect-to-https-with-nginx

  • NGINX

    Verschoben NGINX
    1
    0 Stimmen
    1 Beiträge
    534 Aufrufe
    Niemand hat geantwortet
  • 0 Stimmen
    1 Beiträge
    812 Aufrufe
    Niemand hat geantwortet