Skip to content

Installation von Grav & NGinx & PHP7.2

Angeheftet Verschoben Grav
  • Wird nochmal überarbeitet, da ich noch über einige Probleme gestolpert bin! Für Einsteiger im Moment nur bedingt zu empfehlen!

    Ich hatte schon mal auf einem Debian System PHP7 installiert -> https://frank-mankel.de/kategorien/15-joomla/202-debian-joomla-mit-php7-auf-nginx

    Nun habe ich das auf einem ROCKPro64 gemacht und ein wenig Kopfschmerzen bekommen 😉 Ziel des Ganzen ist es eine Grav-Installation zum Laufen zu bekommen.

    Hardware

    • ROCKPro64 v2.0

    Software

    Linux

    rock64@rockpro64v2_0:~$ uname -a
    Linux rockpro64v2_0 4.4.132-1081-rockchip-ayufan-g50be7e64a779 #1 SMP Tue Jul 31 20:09:25 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
    

    NGinx

    rock64@rockpro64:~$ nginx -v
    nginx version: nginx/1.14.0 (Ubuntu)
    

    PHP

     rock64@rockpro64:~$ php -v
     PHP 7.2.7-0ubuntu0.18.04.2 (cli) (built: Jul  4 2018 16:55:24) ( NTS )
     Copyright (c) 1997-2018 The PHP Group
     Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
         with Zend OPcache v7.2.7-0ubuntu0.18.04.2, Copyright (c) 1999-2018, by Zend Technologies
    

    Installation

    NGinx

    sudo apt-get install nginx 
    

    PHP

    sudo apt-get install php7.2
    

    Benötigte Module für PHP

    sudo apt-get install php7.2-mysql php7.2-opcache php7.2-readline php7.2-xml php7.2-xsl php7.2-zip
    sudo apt-get install php7.2-cli php7.2-curl php7.2-gd php7.2-geoip php7.2-intl php7.2-json php7.2-mbstring
    

    Konfiguration NGinx

    /etc/nginx/nginx.conf

    user www-data;
    worker_processes auto;
    worker_rlimit_nofile 8192; # should be bigger than worker_connections
    pid /run/nginx.pid;
    
    events {
        use epoll;
        worker_connections 8000;
        multi_accept on;
    }
    
    http {
        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
    
        keepalive_timeout 30; # longer values are better for each ssl client, but take up a worker connection longer
        types_hash_max_size 2048;
        server_tokens off;
    
        # maximum file upload size
        # update 'upload_max_filesize' & 'post_max_size' in /etc/php5/fpm/php.ini accordingly
        client_max_body_size 32m;
        # client_body_timeout 60s; # increase for very long file uploads
    
        # set default index file (can be overwritten for each site individually)
        index index.html;
    
        # load MIME types
        include mime.types; # get this file from https://github.com/h5bp/server-configs-nginx
        default_type application/octet-stream; # set default MIME type
    
        # logging
        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;
    
        # turn on gzip compression
        gzip on;
        gzip_disable "msie6";
        gzip_vary on;
        gzip_proxied any;
        gzip_comp_level 5;
        gzip_buffers 16 8k;
        gzip_http_version 1.1;
        gzip_min_length 256;
        gzip_types
            application/atom+xml
            application/javascript
            application/json
            application/ld+json
            application/manifest+json
            application/rss+xml
            application/vnd.geo+json
            application/vnd.ms-fontobject
            application/x-font-ttf
            application/x-web-app-manifest+json
            application/xhtml+xml
            application/xml
            font/opentype
            image/bmp
            image/svg+xml
            image/x-icon
            text/cache-manifest
            text/css
            text/plain
            text/vcard
            text/vnd.rim.location.xloc
            text/vtt
            text/x-component
            text/x-cross-domain-policy;
        
        # disable content type sniffing for more security
        add_header "X-Content-Type-Options" "nosniff";
        
        # force the latest IE version
        add_header "X-UA-Compatible" "IE=Edge";
        
        # enable anti-cross-site scripting filter built into IE 8+
        add_header "X-XSS-Protection" "1; mode=block";
        
        # include virtual host configs
        include sites-enabled/*;
    }
    

    Unter /etc/nginx/sites-available die Datei default löschen. Die Datei grav-site anlegen.

    /etc/nginx/sites-available/grav-site

    server {
        #listen 80;
        index index.html index.php;
    
        ## Begin - Server Info
        root /var/www/grav;
        server_name localhost;
        ## End - Server Info
    
        ## Begin - Index
        # for subfolders, simply adjust:
        # `location /subfolder {`
        # and the rewrite to use `/subfolder/index.php`
        location / {
            try_files $uri $uri/ /index.php?$query_string;
        }
        ## End - Index
    
        ## Begin - Security
        # deny all direct access for these folders
        location ~* /(\.git|cache|bin|logs|backup|tests)/.*$ { return 403; }
        # deny running scripts inside core system folders
        location ~* /(system|vendor)/.*\.(txt|xml|md|html|yaml|yml|php|pl|py|cgi|twig|sh|bat)$ { return 403; }
        # deny running scripts inside user folder
        location ~* /user/.*\.(txt|md|yaml|yml|php|pl|py|cgi|twig|sh|bat)$ { return 403; }
        # deny access to specific files in the root folder
        location ~ /(LICENSE\.txt|composer\.lock|composer\.json|nginx\.conf|web\.config|htaccess\.txt|\.htaccess) { return 403; }
        ## End - Security
    
        ## Begin - PHP
        location ~ \.php$ {
            # Choose either a socket or TCP/IP address
            #fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
             fastcgi_pass 127.0.0.1:9000;
    
            fastcgi_split_path_info ^(.+\.php)(/.+)$;
            fastcgi_index index.php;
            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;
        }
        ## End - PHP
    }
    

    Danach brauchen wir einen symbolischen Link in /etc/nginx/sites-enabled Nur dann funktioniert eine Seite.

    sudo ln -s /etc/nginx/sites-available/grav-site /etc/nginx/sites-enabled/
    

    Installation Grav

    Core installieren
    Option 3 der Anleitung https://learn.getgrav.org/basics/installation

    Admin Panel installieren
    https://learn.getgrav.org/admin-panel/introduction

    Meine Grav-Installation liegt unter

     /var/www/grav
    

    Womit hatte ich nun Probleme? NGinx dient ja als Webserver, dieser Webserver muss jetzt die PHP-Dateien entsprechend verarbeiten können. Dazu gibt es folgenden Block in der Datei /etc/nginx/sites-available/grav-site

     ## Begin - PHP
         location ~ \.php$ {
             # Choose either a socket or TCP/IP address
             #fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
              fastcgi_pass 127.0.0.1:9000;
     
             fastcgi_split_path_info ^(.+\.php)(/.+)$;
             fastcgi_index index.php;
             include fastcgi_params;
             fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;
         }
         ## End - PHP
    

    Es war vorher folgendermaßen

    fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
    #fastcgi_pass 127.0.0.1:9000;
    

    Das hat nicht geklappt. Was sagt die Ubuntu Seite dazu?? Man soll folgendes machen. Datei /usr/local/bin/php-fastcgi anlegen.

     #!/bin/bash
     php-cgi -b 127.0.0.1:9000
    

    Ausführungsrechte

    chmod a+x /usr/local/bin/php-fastcgi 
    

    Danach starten

     sudo php-fastcgi 
    

    Das funktioniert aber nur, wenn folgendes eingestellt ist.

    #fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
    fastcgi_pass 127.0.0.1:9000;
    

    Damit wird PHP direkt an die FastCGI-Schnittstelle gebunden.

    Quelle: https://wiki.ubuntuusers.de/nginx/PHP/

    Danach lief meine Grav-Installation.

    0_1532448808009_Grav_ergebnis.jpg

    So weit so gut. Ein kleiner Schönheitsfehler. Konsole zu beendet

    sudo php-fastcgi 
    

    dann war es das wieder mit NGinx. Die Lösung wir brauchen eine Datei /etc/rc.local

    #!/bin/bash
    #
    # rc.local - executed at the end of each multiuser runlevel
    #
    # Make sure that the script will "exit 0" on success or any other
    # value on error.
    php-fastcgi 
    exit 0
    

    Den Dienst dann nach dieser Anleitung einrichten

    Danach den Server neu starten und es funktioniert!

    Achtung! Nicht auf einem produktiven System einsetzen, ich bin mir nicht sicher ob das zu 100% sicher ist.

  • Nachdem ich den ROCKPro64 jetzt auf den Mainline umgestellt habe, lief meine Testinstallation von Grav nicht mehr.

    Hilfreiche Sache um das Problem zu lösen -> https://gist.github.com/GhazanfarMir/03bd1f1f770a3834d47274586d46ea62

    Ich bekam immer 502 Bad Gateway, Grund war ein nicht korrekt gestarteter php-pfm Service.

    rock64@rockpro64v2_0:/usr/local/bin$ sudo service php7.2-fpm start
    rock64@rockpro64v2_0:/usr/local/bin$ sudo service php7.2-fpm status
    ● php7.2-fpm.service - The PHP 7.2 FastCGI Process Manager
       Loaded: loaded (/lib/systemd/system/php7.2-fpm.service; enabled; vendor preset: enabled)
       Active: active (running) since Thu 2018-08-16 20:15:20 CEST; 21s ago
         Docs: man:php-fpm7.2(8)
     Main PID: 3206 (php-fpm7.2)
       Status: "Processes active: 0, idle: 2, Requests: 3, slow: 0, Traffic: 0.2req/sec"
        Tasks: 3 (limit: 4622)
       CGroup: /system.slice/php7.2-fpm.service
               ├─3206 php-fpm: master process (/etc/php/7.2/fpm/php-fpm.conf)
               ├─3207 php-fpm: pool www
               └─3208 php-fpm: pool www
    
    Aug 16 20:15:19 rockpro64v2_0 systemd[1]: Starting The PHP 7.2 FastCGI Process Manager...
    Aug 16 20:15:20 rockpro64v2_0 systemd[1]: Started The PHP 7.2 FastCGI Process Manager.
    

  • 0 Stimmen
    3 Beiträge
    119 Aufrufe
    FrankMF

    Ich baue seit vielen Jahren immer mal wieder neue Boards zusammen. Seit dem ich denken kann, fast immer MSI Boards. Ich habe noch nie so viel Ärger mit einem Board gehabt, wie mit diesem 😞

    Den Anfang machten merkwürdige USB Probleme. Zusammenhang könnte das Flashen eines neuen BIOS gewesen sein. Habe dann viel rum gefummelt und dann gelesen, das ein Reset des CMOS helfen soll.

    Das habe ich gemacht, danach waren die USB Probleme weg. Aber ein Hauptproblem blieb bestehen. Der Standby Modus ging nicht mehr. Am Anfang ging er mal, aber nach dem ich ein neues BIOS geflasht hatte, war Ende. Leider half auch ein Flashen eines älteren BIOS nicht.

    Heute dann mal zur Sicherheit ein anderes Betriebssystem installiert. Ein Fedora 40 mit Plasma 6 hat dasselbe Ergebnis!?

    Ich habe jetzt ein neues Board einer anderen Firma bestellt, ich werde berichten.

  • Fragen, Probleme, geht nicht?

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

    Linux
    2
    0 Stimmen
    2 Beiträge
    520 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.. 🤓

  • KDE Plasma setzt auf Wayland

    Linux
    1
    0 Stimmen
    1 Beiträge
    50 Aufrufe
    Niemand hat geantwortet
  • Linux Mint "Una" Cinnamon 20.3

    Linux
    7
    0 Stimmen
    7 Beiträge
    319 Aufrufe
    FrankMF

    Heute drüber gestolpert, man hat sich auch der alten Version des Thunderbirds angenommen.

    0aa9e265-95b3-4de6-a8c8-b23c5b980f09-grafik.png

    Damit sind zwei wichtige Programme jetzt hoffentlich immer auf dem aktuellsten Stand.

  • Kernel-Log 4.20

    Linux
    1
    0 Stimmen
    1 Beiträge
    300 Aufrufe
    Niemand hat geantwortet
  • Cups Druckdaemon

    Linux
    1
    0 Stimmen
    1 Beiträge
    370 Aufrufe
    Niemand hat geantwortet
  • Youtube in Grav

    Grav
    1
    0 Stimmen
    1 Beiträge
    503 Aufrufe
    Niemand hat geantwortet