Seite nicht gefunden – Supportnet https://supportnet.de Computer Hilfe aus einer Hand Mon, 18 Mar 2024 11:58:15 +0000 de-DE hourly 1 https://wordpress.org/?v=5.8.9 https://supportnet.de/wp-content/uploads/2017/08/cropped-Supportnet-logo-flat-32x32.png Seite nicht gefunden – Supportnet https://supportnet.de 32 32 Bliss Bites CBD Gummies: Buyer Beware? https://supportnet.de/bliss-bites-cbd-gummies-buyer-beware/ https://supportnet.de/bliss-bites-cbd-gummies-buyer-beware/#respond Sat, 16 Mar 2024 10:43:06 +0000 https://supportnet.de/?p=2507882 Tired of feeling healthy and balanced? Fed up with a well-functioning metabolism? Then you need Bliss Bites CBD Gummies – the surefire way to derail your wellness journey!

This so-called „health supplement oil“ is a masterclass in false advertising. Sure, it claims to give you „metabolic wellbeing“ and „appropriate wellness“ – but what it REALLY gives you is a laundry list of problems. We’re talking questionable ingredients, dubious side effects, and a price tag that’ll make your wallet weep.

Don’t trust those promises of brain health and better synapses. Bliss Bites CBD Gummies will leave your neurons more tangled than a plate of Christmas lights. Better blood flow? Nope, more like sluggish circulation and a racing heart. And that „gentle high“ they mention? Prepare for a rollercoaster of anxiety and paranoia.

Bliss Bites claims to deliver „happy chemicals,“ but the only thing you’ll feel is deep regret. Want to know the real ingredients? Confusion, disappointment, and a strong urge to hurl.

Save your money and your sanity. Bliss Bites CBD Gummies are a guaranteed shortcut to wellness disaster.

Disclaimer: This anti-advertisement is purely satirical and greatly exaggerated for comedic effect. Actual results with CBD products may vary. 😉

Bliss Bites CBD Gummies promise wellness and metabolic bliss. But is this oil-based dietary supplement really worth it? Critical voices warn of side effects, exaggerated advertising claims, and a questionable price-performance ratio.

What exactly is Bliss Bites CBD Gummies?

  • Oil-based supplement with hemp extract
  • Promises: Improved metabolism, mental health, restful sleep
  • Application: Taken directly or used in food
  • Ingredients: Natural ingredients (exact composition unclear)
  • Order: Online via the official website

Points of criticism:

  • Lack of transparency: Unclear information on ingredients and dosage
  • Side effects: Possibility of negative side effects
  • Exaggerated advertising claims: Lack of scientific evidence for effectiveness
  • High price: Doubtful price-performance ratio

Conclusion:

Bliss Bites CBD Gummies do not offer a miracle solution for health and well-being. Consumers should be critical and carefully weigh the risks and costs. Alternatives with proven effectiveness are recommended.

Here you can see how bad the behavior is. They spam our forum four times a day without any success, but in the absence of quality they try quantity.

Wen das hier wundert, dass wir so einen Inhalt auf Supportnet.de haben, hier die kurze Erklärung:
Dieser Anbieter spamt das Forum so dermaßen voll, dass es mir reicht und ich nur diesen Weg sehe, das zu einem Ende zu bringen. Diese Seite soll deutlich besser über Google gefunden werden, als die Seite, die er bewerben will. Das ist die letzte Möglichkeit so einen Spam zu verhindern, den die Spamer scriptgesteuert immer in das Forum ablassen.


]]>
https://supportnet.de/bliss-bites-cbd-gummies-buyer-beware/feed/ 0
Login Bildschirm, Usereingabe direkt aktivieren, ohne Taste drücken zu müssen https://supportnet.de/login-bildschirm-usereingabe-direkt-aktivieren-ohne-taste-druecken-zu-muessen/ https://supportnet.de/login-bildschirm-usereingabe-direkt-aktivieren-ohne-taste-druecken-zu-muessen/#respond Sat, 02 Mar 2024 09:59:38 +0000 https://supportnet.de/?p=2507876 Um den Anmeldebildschirm von Windows so einzustellen, dass das Eingabefeld für Ihr Passwort oder Ihre PIN direkt angezeigt wird, ohne dass Sie zuerst eine Taste drücken oder den Bildschirm berühren müssen, können Sie einige Änderungen in den Windows-Einstellungen oder in der Windows-Registrierung vornehmen. Bitte beachten Sie, dass solche Änderungen mit Vorsicht durchgeführt werden sollten, insbesondere wenn es um Änderungen in der Registrierung geht. Hier sind einige Schritte, die Ihnen helfen könnten:

Änderungen in den Einstellungen

Für gewöhnliche Einstellungen, die das Verhalten des Anmeldebildschirms beeinflussen, können Sie folgende Schritte ausprobieren:

  1. Einstellungen-App öffnen: Drücken Sie die Windows-Taste + I, um die Einstellungen zu öffnen.
  2. Konten auswählen: Klicken Sie auf „Konten“.
  3. Anmeldeoptionen wählen: Wählen Sie im linken Menü „Anmeldeoptionen“.
  4. Einstellungen anpassen: Hier können Sie verschiedene Anmeldeoptionen anpassen, wie z.B. „Anmeldeanforderungen anzeigen, wenn der PC aus dem Ruhezustand reaktiviert wird“. Stellen Sie sicher, dass die Optionen so eingestellt sind, dass sie Ihrem Bedürfnis entsprechen.

Änderung der Registrierung (Fortgeschrittene Nutzer)

Warnung: Die Bearbeitung der Windows-Registrierung kann schwerwiegende Folgen haben, wenn sie nicht korrekt durchgeführt wird. Es wird empfohlen, vor jeder Änderung einen Wiederherstellungspunkt zu erstellen.

Um die Registrierung zu ändern, sodass der Anmeldebildschirm ohne zusätzliche Eingabe erscheint:

  1. Registrierungseditor öffnen: Drücken Sie die Windows-Taste + R, geben Sie regedit ein und drücken Sie Enter. Bestätigen Sie die UAC-Eingabeaufforderung, um fortzufahren.
  2. Navigieren zum richtigen Schlüssel: Navigieren Sie zum Schlüssel HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI.
  3. Ändern/Wert hinzufügen: Suchen Sie nach einem Wert namens ShowLockScreen, oder erstellen Sie ihn, wenn er nicht existiert (Rechtsklick → Neu → DWORD (32-bit) Wert). Setzen Sie den Wert auf 0, um den Sperrbildschirm zu deaktivieren.
  4. Registrierungseditor schließen und Ihren PC neu starten.

Bitte beachten Sie, dass einige dieser Einstellungen durch spezifische Windows-Updates oder Versionen unterschiedlich gehandhabt werden können. Wenn Sie eine bestimmte Windows-Version verwenden (z.B. Windows 10 oder Windows 11), könnten die Schritte leicht variieren. Es ist auch wichtig, regelmäßige System-Backups durchzuführen, um Datenverlust zu vermeiden.

]]>
https://supportnet.de/login-bildschirm-usereingabe-direkt-aktivieren-ohne-taste-druecken-zu-muessen/feed/ 0
WordPress, Nginx, MariaDB und PHP 7 (LEMP) auf einem Debian 10 Server installieren https://supportnet.de/lemp-nginx-mariadb-php-7-und-wordpress-als-server-aufsetzen-debian-10-hetzner/ https://supportnet.de/lemp-nginx-mariadb-php-7-und-wordpress-als-server-aufsetzen-debian-10-hetzner/#respond Sun, 04 Feb 2024 22:50:00 +0000 https://supportnet.de/?p=2506789 LEMP steht für Linux/Nginx/MariaDB und PHP. Im Gegensatz zu LAMP also Linux/Apache/Mysql und PHP soll ein Server mit Nginx etwas schneller als ein Apache Web-Server sein. Wie man das alles auf einem nackten Server mit Debian-Minimalsystem installiert, soll dieser Artikel beschreiben.

Wozu das Ganze?

Ich habe selber mein Projekt Supportnet.de seit ein paar Jahren auf einem Server mit LAMP Umgebung laufen und muss sagen, das läuft mit WordPress sehr gut. Jetzt habe ich aber die Erfahrung gemacht, dass die Performance der Webseitenauslieferung einen nicht ganz geringen Einfluss auf die Platzierung bei den Google Suchergebnissen hat. Was für Google gut ist, ist natürlich auch für den Besucher einer Webseite gut, so sollte es auf jeden Fall sein und in diesem Fall ist das natürlich auch so. Um so schneller die Seiten ausgeliefert werden um so besser die Besuchererfahrung.

Die Hardware ist im Gegensatz zu früher kaum ein Problem, wenn man wirklich Performance braucht nimmt man sich einen dedizierten Server. Aber auch da kann es Probleme geben wenn die Serversoftware nicht schnell genug ist. Deshalb wollte ich jetzt mal auf einem Hetzner CloudServer ausprobieren wie viel schneller Nginx gegenüber Apache eigentlich ist. Laut Internet Tests ist der Nginx bei statischen HTML Dateien ca. 2,5 mal schneller als der Apache und bei allen anderen Sachen wohl nur ein paar Prozent. Aber, vielleicht kommt es ja gerade auf die paar Prozent an um die eigene Seite besser als die der Konkurrenz als bestes Suchergebnis angezeigt zu bekommen.

Was brauchen wir alles

  1. Cloudserver oder dedicated Server (von Hetzner oder einem anderen Anbieter) mit installiertem Debian 10.x
  2. SSH Zugriff auf den Server

Wenn ihr hier schon mit einer Domain als Adresse, und nicht mit der IP Nummer des Servers arbeiten wollt, dann sollte der DNS (Domain Name Server Eintrag) der Domain schon auf die IP Nummer eures Servers zeigen. Ansonsten müsst ihr hier überall wo hier meine_domain steht einfach eure IP Nummer angeben.

Login und Passwort

Bei Hetzner bekommt man bei der Neueinrichtung eines virtuellen Servers (Cloudserver) oder eines dedicated Server (Hardware Server) eine Mail mit dem Passwort für root und der IP Nummer des Servers zugeschickt.

Also loggt euch jetzt per ssh auf die in der Mail angegebenen IP Nummer und den Logindaten ein. Bei dedizierten Server wird wohl noch nicht gefordert sein Passwort sofort zu ändern, bei Cloudservern ist das so. Man muss also noch einmal sein Passwort aus der e-mail eingeben und dann ein neues zwei mal eintippen (und gut merken).

Updates und Upgrades

Jetzt ist es eine gute Idee den Server auf den neuesten Stand zu bringen. Die Images, die installiert werden sind nicht immer taufrisch und wir wollen ja nicht gleich mit veralteten und unsicheren Paketen leben müssen.

sudo apt update (liest die Update Liste ein um ermitteln zu können welche Software Pakete aktualisiert werden können)
sudo apt upgrade (installiert dann die zu aktualisierenden Software Pakete)

Nginx installieren

Jetzt da alles auf dem aktuellen Stand ist kann man einfach mit dem Befehl:

sudo apt install nginx

Ob das geklappt hat kann man einfach ausprobieren indem man jetzt die IP Adresse seines Clooudservers (steht in der e-mail) in die Adressleiste seines Browsern eingibt. Wenn ihr schon eine Domain für euren Server habt und deren DSN Einträge schon funktionieren sollte der Aufruf deine-domain im Browser das gleiche Ergebnis bringen.

Wenn ihr das als Antwort bekommt habt ihr den Nginx erfolgreich installiert.

MariaDB Server installieren

Der Webserver läuft. Um Daten speichern zu können oder ein CMS wie WordPress installieren zu können braucht es noch einen Datenbank Server.

In unserem Fall MariaDB, der communit Fork aus dem von Oracle übernommenen Mysql.

MariaDB installieren

Das aktuelle Software Paket von MariaDB heißt mariadb-server und wird so installiert:

sudo apt install mariadb-server

MariaDB absichern

Wenn die Installation von MariaDB erfolgreich war ist es für die Sicherheit wichtig, dass ihr noch ein Script ausführt, dass ein paar Sachen in MariaDB löscht und verändert, die ein Sicherheitsproblem sein könnten.

sudo mysql_secure_installation

Zuerst fragt euch das Script nach dem root Passwort, welches das Datenbank root Passwort ist, nicht das Linux root Passwort. Da die MariaDB Datenbank gerade erst installiert wurde, gibt es noch kein Passwort und ihr könnt einfach auf Enter/Return für ein leeres Passwort drücken.

  1. Zuerst fragt euch das Script nach dem root Passwort, welches das Datenbank root Passwort ist, nicht das Linux root Passwort. Da die MariaDB Datenbank gerade erst installiert wurde, gibt es noch kein Passwort und ihr könnt einfach auf Enter/Return für ein leeres Passwort drücken. Das leere Passwort soll so bleiben, da MariaDB für root kein Passwort vorgesehen hat, was nicht heißt, dass man sich ohne Passwort einloggen kann. Das Authentifizierungsverfahren ist nur anders und manche Prozesse für die Wartung von MariaDB erwarten, dass sie sich so einloggen können.
  2. Jetzt werdet ihr gefragt ob ihr ein root Passwort vergeben wollt, was ihr nicht machen solltet.
  3. Danach soll der anonymous User gelöscht werden, der standardmäßig installiert wird. Das mit “Y” bestätigen.
  4. Jetzt noch die Einstellung bestätigen, dass der root User nur vom lokalen Server aus auf die Datenbank zugreifen kann und dann noch die Test Datenbank löschen lassen.
  5. Danach werden die Berechtigungstabellen neu eingelesen, auch das sollte man mit y bestätigen und fertig ist das Secure Script und die Datenbank für den Betrieb im Netz fertig.

Danach werden die Berechtigungstabellen neu eingelesen, auch das sollte man mit y bestätigen und fertig ist das Secure Script und die Datenbank für den Betrieb im Netz fertig.

MariaDB für WordPress einrichten

Wie oben unter MariaDB absichern schon geschrieben läuft auf einem Debian 10 System eine MariaDB 10.x Version bei der sich der root Benutzer über ein unix-socket Plugin oder andere Methoden authentifiziert. Also nicht über ein Passwort. Das ist deshalb wichtig, da man sich für die Administration der MariaDB einen anderen Benutzer anlegen muss, der administrative Rechte hat. 

Für den administrativen Zugang von root auf den MariaDB Server sollte man also die Authentifizierungsmöglichkeiten nicht ändern und kein Passwort für den Benutzer root vergeben. Der Benutzer root wird für viele administrative Zwecke benutzt und sollte daher auch wie von anderen Diensten erwartet funktionieren. Anwendungen wie Logdatei Rotation und Start und Stop des Servers benötigen so einen root-Benutzerzugang.

Es wird also empfohlen einen extra Benutzer Account für MariaDB mit administrativen Rechten anzulegen.

Dafür starten wie die MariaDB SQL Eingabe mit:

sudo mysql

Wir wollen hier einen Benutzer mit dem Namen „admin“, dem Passwort „passwort“ und allen Rechten für alle Datenbanken anlegen. Dazu geben wir in der folgenden MariaDB Eingabeaufforderung folgendes ein:

MariaDB [(none)]> GRANT ALL ON *.* TO 'admin'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION;

Dann noch die Zugriffsrechte neu einlesen:

MariaDB [(none)]> FLUSH PRIVILEGES;

Und jetzt die Eingabeaufforderung von MariaDB verlassen:

MariaDB [(none)]> exit

Jetzt bleibt uns nur noch die MariaDB Installation zu testen.

MariaDB Testen

root@xxxxxxxxxx-debian-2gb-nbg1-1:~# systemctl status mariadb
root@xxxxxxxxxx-debian-2gb-nbg1-1:~# systemctl status mariadb
 ● mariadb.service - MariaDB 10.3.15 database server
    Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
    Active: active (running) since Sat 2019-08-24 13:36:36 CEST; 2h 43min ago
      Docs: man:mysqld(8)
            https://mariadb.com/kb/en/library/systemd/
  Main PID: 8086 (mysqld)
    Status: "Taking your SQL requests now…"
     Tasks: 31 (limit: 4585)
    Memory: 74.5M
    CGroup: /system.slice/mariadb.service
            └─8086 /usr/sbin/mysqld
 Aug 24 13:36:37 xxxxxxxx-debian-2gb-nbg1-1 /etc/mysql/debian-start[8124]: Phase 6/7: Checking and upgrading tables
 Aug 24 13:36:37 xxxxxxxx-debian-2gb-nbg1-1 /etc/mysql/debian-start[8124]: Running 'mysqlcheck' with connection arguments: --socket='/var/run/mysqld/mys
 Aug 24 13:36:37 xxxxxxxx-debian-2gb-nbg1-1 /etc/mysql/debian-start[8124]: # Connecting to localhost…
 Aug 24 13:36:37 xxxxxxxx-debian-2gb-nbg1-1 /etc/mysql/debian-start[8124]: # Disconnecting from localhost…
 Aug 24 13:36:37 xxxxxxxx-debian-2gb-nbg1-1 /etc/mysql/debian-start[8124]: Processing databases
 Aug 24 13:36:37 xxxxxxxx-debian-2gb-nbg1-1 /etc/mysql/debian-start[8124]: information_schema
 Aug 24 13:36:37 xxxxxxxx-debian-2gb-nbg1-1 /etc/mysql/debian-start[8124]: performance_schema
 Aug 24 13:36:37 xxxxxxxx-debian-2gb-nbg1-1 /etc/mysql/debian-start[8124]: Phase 7/7: Running 'FLUSH PRIVILEGES'
 Aug 24 13:36:37 xxxxxxxx-debian-2gb-nbg1-1 /etc/mysql/debian-start[8124]: OK
 Aug 24 13:36:37 xxxxxxxx-debian-2gb-nbg1-1 /etc/mysql/debian-start[8230]: Triggering myisam-recover for all MyISAM tables and aria-recover for all Aria
 lines 1-22/22 (END)

MariaDB Datenbank und Datenbank Benutzer für WordPress erstellen

WordPress erwartet eine schon bestehende Datenbank in der es seine Tabellen anlegen kann. Die muss man anlegen und auch einen Benutzer, der vollen Zugriff auf die Datenbank hat muss erstellt werden. In der WordPress Dokumentation wird angegeben, dass dieser Benutzer Vollzugriff auf die Datenbank haben muss. Das ist deshalb interessant, da man eigentlich nur Tabellen anlegen, ändern und löschen können muss und man aus Sicherheitsgründen lieber nur die benötigten Reche vergeben sollte. WordPress spricht aber von Plugins, die mehr Rechte verlangen können und daher sollte der Benutzer für die WordPress Datenbank alle Rechte für diese Datenbank haben.

Wir starten also die Datenbank Eingabeaufforderung mit:

root@xxxxxxxxx-debian-2gb-nbg1-1:~# sudo mariadb

so kommst du wieder in den Befehlsmodus von MariaDB und zwar als root Datenbankuser. Das passiert durch den sudo Befehl.

Wie man hier sieht loggt man sich als Superuser ein und braucht dafür kein root Passwort. Was wie ein Sicherheitsleck aussieht garantiert aber, dass sich nur Benutzer mit Superuser Rechten oder Prozesse, die diese besitzen auf der Datenbank als root anmelden können.

Es kann sich also niemand über eine PHP Lücke als root in der Datenbank anmelden, da PHP nicht als Superuser ausgeführt wird.

Um die Sicherheit zu erhöhen sollte man für jede Datenbank einen eigenen Benutzer mit für diese Datenbank beschränkten Rechten anlegen. Das macht vor allem Sinn, wenn man mehrere verschiedene Anwendungen mit Datenbanken hat. 

Wir legen in diesem Fall eine Datenbank namens “test_datenbank” an.

MariaDB [(none)]> CREATE DATABASE test_datenbank;

Und einen Benutzer, der nur auf diese Datenbank zugreifen darf mit dem Namen “test_user” mit dem Passwort “passwort” (hier bitte wieder ein sicheres Passwort eingeben.

MariaDB [(none)]> GRANT ALL ON test_datenbank.* TO 'test_user'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION;

Dieser Benutzer kann in der Datenbank “test_datenbank” Tabellen anlegen, aktualisieren und löschen aber keine anderen Datenbanken erstellen oder verändern.

Dann noch einmal die Berechtigungen neu einlesen mit:

 MariaDB [(none)]> FLUSH PRIVILEGES;

Und exit aus der Datenbank

 MariaDB [(none)]> exit

Jetzt noch ein Test ob ihr euch mit dem neuen Benutzer “test_user” anmelden könnt.

mariadb -u test_user -p

Falls jetzt eine Fehlermeldung kommt, stimmt entweder der Benutzername des Datenbankbenutzers nicht oder das Passwort.

Ansonsten seid ihr angemeldet und könnt gleich mal testen welche Datenbanken euch zur Verfügung stehen:

SHOW DATABASES;

Output

+--------------------+ +--------------------+
| Database           |
+--------------------+
| test_datenbank   |
| information_schema |
+--------------------+
2 rows in set (0.000 sec)

 +--------------------+

Und jetzt wieder “Exit” um die MariaDB Eingabeaufforderung zu verlassen.

PHP Installation

Anders als beim Apache Webserver kann Nginx selber kein PHP interpretieren. Beim Apache kann man PHP einfach als Modul laden und fertig. Damit Nginx mit PHP umgehen kann muss eine eigene Applikation für PHP installiert werden an die Nginx dann die PHP Aufrufe übergeben kann.

Dafür benötigen wir “php-fpm” (“PHP fastCGI process manager”) den man übrigens auch für den Apache Server braucht wenn man HTTP2 mit ihm verwenden will, da das PHP Apache Modul keine parallelen Verbindungen unterstützt. Dazu muss man dann noch Nginx erklären, dass es bei PHP den PHP fastCGI Prozess Manager ansteuern soll. Zusätzlich braucht es noch ein Modul damit PHP auf die MariaDB zugreifen kann, welches “php-mysql” heißt. 

WordPress verlangt noch ein paar Zusatzmodule für PHP, ohne die es zwar läuft aber in der Systemübersicht dann meckert. Also installiert man diese lieber gleich mit.

Um alle zu installieren gib folgenden Befehl ein:

sudo apt install php-fpm php-mysql php7.3-gd php7.3-imagick php7.3-curl php7.3-bcmath

So jetzt sind alle PHP Pakete installiert. Jetzt noch ein kleiner Check welche Versionen jeweils installiert sind.

php --version

 PHP 7.3.4-2 (cli) (built: Apr 13 2019 19:05:48) ( NTS )
 Copyright (c) 1997-2018 The PHP Group
 Zend Engine v3.3.4, Copyright (c) 1998-2018 Zend Technologies
     with Zend OPcache v7.3.4-2, Copyright (c) 1999-2018, by Zend Technologies

mariadb

 Welcome to the MariaDB monitor.  Commands end with ; or \g.
 Your MariaDB connection id is 150
 Server version: 10.3.15-MariaDB-1 Debian 10
 Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
 Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

Nginx für PHP konfigurieren

Um mit Nginx mehrere Domains verwenden zu können benutzt Nginx sogenannte server blocks. Diese server blocks entsprechen den virtuellen Hosts vom Apache Server. Man kann damit für verschiedene Webseiten (Domains) verschiedene Optionen wie zum Beispiel das Document Root für den Webserver vergeben. Die Server Blocks ersetzen auch die .htaccess Datei des Apache Servers und sind daher der Ort wo man Weiterleitungen oder deren Regeln festlegt.

Unter Debian 10 ist für Nginx schon ein server block vorkonfiguriert dessen Dokument Root /var/www/html ist. Wenn man also die IP Adresse des Servers aufruft oder einen DNS Eintrag für eine Domain auf diese IP Adresse zeigen lässt, dann kann man so die Standardkonfiguration aufrufen. Es wird also angezeigt was unter dem standard Document root an Dateien abgelegt ist. In unserem Fall also unter /var/www/html die Datei “index.nginx-debian.html”

Da ich selber hier auf dem Server auch mehrere Domains hosten will, erkläre ich kurz wie man mit Nginx virtuelle Hosts anlegt.

Server Block erstellen

Als erstes erstellen wir ein Dokument root für die erste Domain, in meinem Fall meine_domain

sudo mkdir /var/www/meine_domain

Rechte der Verzeichnisse noch anpassen

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

Jetzt erstellen wir eine neue server blocks Konfigurationsdatei im Ordner 

/etc/nginx/sites-available/meine_domain

Ich nehme dazu immer den vi, ihr könnt dafür natürlich euren Lieblingseditor benutzen.

sudo vi /etc/nginx/sites-available/meine_domain

Fügt dann in diese Textdatei folgende Konfiguration ein:

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

    root /var/www/meine_domain;
    index index.php index.html index.htm;

    server_name meine_domain;

    location / {
        try_files $uri $uri/ =404;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php7.3-fpm.sock;
    }
}

Diese Basiskonfiguration lässt Nginx auf dem Port 80 hören und verteilt Dateien von eurem web root Verzeichnis /var/www/meine_domain. Diese Konfiguraton (server block) antwortet nur auf Anfragen, die genau eurem angegebenen Domainnamen entsprechen. Alle PHP Anfragen werden an php-fpm weitergeleitet und dann von dort, nach der Bearbeitung, wieder ausgeliefert.

Dann noch einen Softlink auf die Datei erstellen, damit die Konfiguration der Domain auch ausgeführt wird:

sudo ln -s /etc/nginx/sites-available/meine_domain /etc/nginx/sites-enabled/

Jetzt noch ein Check ob die Konfiguration keine Fehler enthält mit:

sudo nginx -t

Und der obligatorische Neustart des Nginx Servers mit:

sudo systemctl reload nginx

So jetzt sollte der Server laufen und auch PHP interpretieren.

PHP für Nginx testen

Das testen wir noch schnell mit einer kleinen PHP Info Datei, die schnell erzeugt ist. Nehmt euren Lieblingseditor und erzeugt eine Datei info.php (im Verzeichnis /var/www/html/ also eurem html root) in die ihr folgendes schreibt:

<?php
phpinfo();

Ruft jetzt die Datei über euren Browser mit der Adresse auf:

http://meine_domain/info.php

Als Ergebnis solltet ihr eine Webseite mit sehr detaillierten Informationen über euren Server angezeigt bekommen.

Solltet ihr an der PHP Konfiguration etwas ändern müssen könnt ihr PHP mit diese Befehl neu starten: systemctl restart php7.3-fpm

Nginx für WordPress einrichten

Was hier jetzt interessant ist, Nginx hat nicht wie Apache eine .htaccess Datei in der man Umleitungen definieren kann. Das muss alles in der Konfiguration eines Server Blocks von Nginx gemacht werden. Deshalb verändern wir unsere erste Server Block Konfigurationsdatei dahingehend, dass auch Nginx die von WordPress benötigten Umleitungen machen kann.

Plugins, die auf eine .htaccess angewiesen sind, können nur über Umwege mit Nginx eingesetzt werden.

Also editiert nochmal die Datei

/etc/nginx/sites-avaiable/meine_domain

Und tragt dort folgendes ein.

server {
   server_name meine_domain;
   listen 80;
   root /var/www/meine_domain;
   access_log /var/log/nginx/access.log;
   error_log /var/log/nginx/error.log;
   index index.php;
   gzip  on;
   gzip_vary  on;
   gzip_min_length  100;
   gzip_buffers  16 8k;
   gzip_proxied  any;
   gzip_types
     text/plain
     text/css
     text/javascript
     application/json
     application/javascript;
  
   location / {
     try_files $uri $uri/ /index.php?q=$uri&$args;
   }
  
   location ~* \.(jpg|jpeg|gif|css|png|js|ico|html)$ {
     access_log off;
     expires max;
   }
  
   location ~ /\.ht {
     deny  all;
   }
  
   location ~ \.php$ {
     fastcgi_index index.php;
     fastcgi_keep_conn on;
     include /etc/nginx/fastcgi_params;
     fastcgi_pass unix:/run/php/php7.3-fpm.sock;
     fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
   }
 }
   

Hinweis: Wenn ihr eine andere PHP Version benutzt müsst ihr hier in der Zeile in der „fastcgi_pass unix:/run/php/php7.3-fpm.sock;“ steht, die Version anpassen. Eure PHP Version könnt ihr so auslesen: php –version

Bei allen Änderungen an der PHP Konfiguration oder eines Nginx Server Blocks müsst ihr danach den Nginx Server neu starten:

sudo systemctl reload nginx

Läuft der Server mit dieser Konfiguration dann solltet ihr jetzt WordPress installieren können.

WordPress installieren

So der Server läuft und PHP und MariaDB sind bereit die ersten WordPress Daten zu verarbeiten. Installieren wir jetzt also WordPress im Document Root unserer Domain. Dazu müssen wir das WordPress Paket von www.wordpress.org downloaden. Wechsel dazu in dein Dokument Root deines Servers also nach /var/www/deine_domain und führe dort den Befehl aus.

wget https://de.wordpress.org/latest-de_DE.tar.gz

Das war der Link für die deutsche Version, für die englische Originalversion musst diese Datei runterladen.

wget https://wordpress.org/latest.tar.gz

Das Entpacken geht mit

tar xfz latest-de_DE.tar.gz 

Die WordPress Dateien werden jetzt in den Ordner „wordpress“ entpackt, was wir eigentlich nicht wollen. Daher kopieren wir die Sachen noch in das Dokument Root unseres Servers zurück.

mv wordpress/* .
rm -r wordpress

Wir könnten jetzt die wp-config.php Datei erstellen und unsere Daten für den Datenbankzugriff und alles sonstigen Sachen dort eintragen, aber WordPress macht es einem einfach und lässt einen das auch alles bequem über den Browser eintragen. Ruft dazu im Browser eure Domain auf, in unserem Fall also www.deine-domain.de . Wichtig dabei ist, dass ihr die Dateirechte vorher für den Benutzer www-data geändert habt, da WordPress sonst nicht auf die wp-config.php Datei schreiben kann (vor allem spart man sich das lästige Eintragen von Zufallszeichen für den Salt Zusatz für die Verschlüsslung in der Datenbank).

chown -R www-data:www-data /var/www/mein_domain

Jetzt wo alle Dateien entpackt sind, am richtigen Ort liegen und die richtigen Berechtigungen gesetzt sind können wir einen ersten Versuch starten, die Installation von WordPress über den Browser anzugehen. Gib dazu deine Domain-Adress in einem Browser ein, in unserem Beispiel also meine-domain. Die Seite, die jetzt erscheinen sollte sieht so aus.

Klicke auf „Los geht’s“ und du kommst auf die folgende Seite in der du deine Datenbank Zugangsdaten eingeben muss.

Wichtig hier ist, das sind die Zugangsdaten, die du oben im Abschnitt „MariaDB Datenbank und Datenbank Benutzer für WordPress erstellen“ eingerichtet hast. Bei der Tabellen-Präfix kann man sich auch etwas anderes als wp_ einfallen lassen, das macht es potentiellen Angreifern etwas schwerer, da sie nicht vorher schon wissen wie die Datenbanktabellen heißen. Es spielt für WordPress keine Rolle, da die Präfix frei wählbar ist.

Jetzt kannst du die Installation starten. Falls irgendwas mit der Datenbank nicht klappen sollte bekommst du eine Fehlermeldung. Meist hat man sich mit den eingegebenen Daten vertippt. Auch wenn deine Dateien noch nicht für den User www-data beschreibbar sind bekommst du eine Fehlermeldung a la:

Heureka, alles geschafft. WordPress läuft und funktioniert mit einem aktuellen Nginx Server, mit PHP 7.x, MariaDB und eben WordPress selber.

Das coole an den Cloud Servern von Hetzner (bei allen anderen Anbietern ist das sicher genau so) man kann sie beliebig hin und her kopieren, sich Snapshots machen bevor man eine heikle Änderung macht und auch ziemlich gut erweitern. Wenn man mehr CPU Power braucht kann man sich zusätzliche CPUs einfach dazu buchen, oder mehr RAM oder was auch sehr cool ist einfach mehr Plattenplatz mounten. Ich habe auf einem meiner Testserver einfach noch zusätzliche 40 GB Plattenplatz auf /var/www/html gemountet um mehr Platz für Daten zu haben (das kostet dann ca. 2-3 Euro monatlich mehr). Also alles sehr flexibel das Ganze.

Fazit

Wenn alles gut geht hat man sich so eine WordPress Installation auf deinem Server in einer Stunde installiert. Leider klappt nicht immer gleich alles auf Anhieb. Wenn der Server läuft, ist er wirklich schnell. Meine ersten Speed Tests mit der WordPress Installation noch ohne zusätzliche Plugins und wenig Inhalten zeigen aber ein gutes Ergebnis bei Google Page Speed Insights, für die Desktop Version 100 % und für die Mobile 95 %. Das ändert sich natürlich alles wenn die Datenbank mal etwas gefüllt ist und auch mehr als ein Benutzer auf die Seite zugreift. Für einen virtuellen Server mit nur zwei CPU Kernen, 4 GB RAM und 20 GB Plattenplatz ein gutes Ergebnis.

Mit der Snapshot Funktion der Cloudserver werde ich jetzt noch einige Performance Tests mit Daten und verschiedenen Konfigurationen machen.

Werbung und Sponsoring

Also ich schwärme hier ja doch etwas für Hetzner als Provider für unseren Server und das liegt an der inzwischen fast 20 Jahre langen Erfahrung, die ich mit Hetzner gemacht habe. Der Support von Hetzner war immer sehr hilfsbereit und hat uns auch in Notfällen immer versucht eine gute Lösung zu bieten, also auch mitgedacht wie man ein aufgetauchtes Problem lösen kann.

Deshalb schreibe ich es hier noch einmal aus, ich habe keine Vorteile durch diesen Artikel von der Firma Hetzner bekommen, aber was nicht ist kann ja noch werden ;-)

]]>
https://supportnet.de/lemp-nginx-mariadb-php-7-und-wordpress-als-server-aufsetzen-debian-10-hetzner/feed/ 0
Fahrrad Rahmenhöhe berechnen https://supportnet.de/fahrrad-rahmenhoehe-berechnen/ https://supportnet.de/fahrrad-rahmenhoehe-berechnen/#respond Tue, 24 Jan 2023 19:46:54 +0000 https://supportnet.de/?p=2507837 Hier mal für euch einen Rechner um die Rahmenhöhe von Fahrrädern zu berechnen. Wichtig dabei ist der Fahrradtyp und eure Schritthöhe, also gemessen vom Boden bis in euren Schritt, sozusagen die innere Beinlänge in Zentimeter. Wählt noch euren Fahrradtyp aus und gebt die Schritthöhe an, das Ergebnis für die ideale Rahmenhöhe wird euch dann grün hinterlegt angezeigt.


Die Rahmenhöhe beim Radfahren ist unglaublich wichtig, denn sie beeinflusst direkt deine Sitzposition und somit deinen Komfort und deine Sicherheit. Eine richtig gewählte Rahmenhöhe ermöglicht es dir, wenn du vom Sattel steigst, bequem mit beiden Füßen den Boden zu erreichen und gleichzeitig ermöglicht es dir eine effiziente Kraftübertragung beim Treten.

Die verschiedenen Fahrradtypen haben unterschiedliche Anforderungen an die Rahmenhöhe, die durch unterschiedliche Faktoren beeinflusst werden. Wenn du zum Beispiel ein Mountainbike fährst, benötigst du in der Regel eine kleinere Rahmenhöhe, um eine bessere Kontrolle und Manövrierfähigkeit im Gelände zu haben. Wenn du ein Trekkingrad oder Citybike fährst, benötigst du in der Regel eine größere Rahmenhöhe, um eine bequemere Sitzposition und eine effizientere Kraftübertragung zu haben. Wenn du ein Rennrad fährst, benötigst du in der Regel eine noch größere Rahmenhöhe als bei Trekkingrädern und Citybikes, um eine aerodynamischere Sitzposition und höhere Geschwindigkeiten zu erreichen. Auch bei einem Crossbike ist es ähnlich wie bei einem Mountainbike, da es sowohl im Gelände als auch auf Straßen verwendet wird.

Es ist wichtig zu erwähnen, dass es keine festen Regeln für die Wahl der Rahmenhöhe gibt und jeder Fahrer individuelle Anforderungen haben kann. Eine genaue Ermittlung der richtigen Rahmenhöhe sollte daher immer von einem erfahrenen Mechaniker oder Radsportfachmann durchgeführt werden, insbesondere wenn es um Rennräder geht.

]]>
https://supportnet.de/fahrrad-rahmenhoehe-berechnen/feed/ 0
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 19985578 bytes) in https://supportnet.de/php-fatal-error-allowed-memory-size-of-134217728-bytes-exhausted-tried-to-allocate-19985578-bytes-in/ https://supportnet.de/php-fatal-error-allowed-memory-size-of-134217728-bytes-exhausted-tried-to-allocate-19985578-bytes-in/#respond Wed, 02 Feb 2022 20:36:16 +0000 https://supportnet.de/?p=2507785 WordPress bietet für die Suche nach Fehlern die Möglichkeit über die wp-config.php Datei das Error-Log einzuschalten. Standardmäßig steht dort eine Zeile wie diese:

define( 'WP_DEBUG', false );

Wenn man diese ändert und die beiden weiteren Zeilen hinzu fügt, werden die Fehler in die Datei debug.log im Verzeichnis wp-content geschrieben.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );

Dabei ist die erste Zeile dafür da das Error logging einzuschalten, die Zweite Zeile schält das Ausgeben der Meldungen auf der Seite aus und die dritte Zeile sorgt dafür, dass die Meldungen in die Datei debug.log geschrieben werden.

Anzeigen kann man sich die live Meldungen dann indem man in dem Verzeichnis wp-content seiner WordPress Installation die letzten Zeilen seiner debug.log Datei live anzeigen lässt.

tail -f debug.log

Da stand dann in diesem Fall etwas von: PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 19985578 bytes) in

Im Debug Log von WordPress taucht diese Fehlermeldung auf mit unterschiedlichen Zahlenangaben, diese hier ist nur ein Beispiel. Das deutet auf ein zu geringes Memory Limit von PHP hin.

[31-Jan-2022 17:33:50 UTC] PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 19985578 bytes) in /var/www/html/xxx.php on line 3006

Das lässt sich ganz leicht ändern in dem man in der php.ini das memory_limit höher setzt.

vi /etc/php/7.0/apache2/php.ini

Also einfach mit dem vi die entsprechende php.ini Datei aufrufen und den Eintrag memory_limit = 256M auf einen höheren Betrag ändern.

memory_limit = 512M

Damit sollte die Fehlermeldung aus dem debug.log von WordPress verschwinden und die damit einhergehenden Fehlermeldungen oder Falschdarstellungen von Webseiten verschwinden.

]]>
https://supportnet.de/php-fatal-error-allowed-memory-size-of-134217728-bytes-exhausted-tried-to-allocate-19985578-bytes-in/feed/ 0
The size of BLOB/TEXT data inserted in one transaction is greater than 10% of redo log size. https://supportnet.de/the-size-of-blob-text-data-inserted-in-one-transaction-is-greater-than-10-of-redo-log-size/ https://supportnet.de/the-size-of-blob-text-data-inserted-in-one-transaction-is-greater-than-10-of-redo-log-size/#respond Sun, 25 Jul 2021 13:52:56 +0000 https://supportnet.de/?p=2507757 Kurz und Knapp

Um diese Fehlermeldung zu umgehen muss man die Größe von innodb_log_file_size=256M in der Datenbank Konfig vergrößern.

Also fügt, falls nicht schon vorhanden, dann ändern, die Zeile innodb_log_file_size=512M in eure /etc/mysql/mariadb.cnf ein und startet danach die Datenbank mit sudo service mysql restart neu.

Fehlermeldung von WordPress im debug.log

Wer diese Fehlermeldung in seinem WordPress Error Log debug.log im wp-content Verzeichnis findet, der sollte seine MySQL/MariaDB Datenbank eine kleine Veränderung in der Configurationsdatei gönnen.

Aufgefallen ist mir der Fehler da das Supportnet immer mal wieder im Foren-Teil eine sehr einengende Formatierung angezeigt hat. Die Breite stimmte einfach nicht, aber nicht bei allen Aufrufen, sondern nur ab und zu. Das sind ja die Lieblingsfehler der ITler, man kann sie nicht mal richtig überprüfen.

Aber das Supportnet hat ja die beste Communty der Welt und sogar die kleinste Veränderung wird bemerkt, unter anderem auch dieser sporadisch auftretende Fehler in der Darstellung.

Beim Suchen im Code ist mir aufgefallen, dass da wohl eine CSS Anweisung per JavaScript für eine Error-Page eingefügt wird. Also musste ich den Fehler finden, der diese Errormeldung verursachte. Ganz unten auf den entsprechenden Seiten stand dann folgendes:

Es gab einen kritischen Fehler auf deiner Website.

Erfahre mehr über die Problembehandlung in WordPress.

WordPress bietet für die Suche nach Fehlern die Möglichkeit über die wp-config.php Datei das Error-Log einzuschalten. Standardmäßig steht dort eine Zeile wie diese:

define( 'WP_DEBUG', false );

Wenn man diese ändert und die beiden weiteren Zeilen hinzu fügt, werden die Fehler in die Datei debug.log im Verzeichnis wp-content geschrieben.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );

Dabei ist die erste Zeile dafür da das Error logging einzuschalten, die Zweite Zeile schält das Ausgeben der Meldungen auf der Seite aus und die dritte Zeile sorgt dafür, dass die Meldungen in die Datei debug.log geschrieben werden.

Anzeigen kann man sich die live Meldungen dann indem man in dem Verzeichnis wp-content seiner WordPress Installation die letzten Zeilen seiner debug.log Datei live anzeigen lässt.

tail -f debug.log

Da stand dann in diesem Fall etwas von:

The size of BLOB/TEXT data inserted in one transaction is greater than 10% of redo log size.

Eine kurze Recherche ergab dann, dass ich wohl die

innodb_log_file_size=256M

von meiner MariaDB mindestens auf 256M besser noch auf 512M einstellen sollte. Das ganze hat mit den Größen der Dateien zu tun, die man als Blob in die Datenbank laden lässt.

Ich hab denn folgende Zeile

innodb_log_file_size=512M

in der Datei:

mariadb.cnf 

Im Verzeichnis

/etc/mysql/

eingefügt.

Wie immer muss man die Datenbank nach einer Änderung in der Konfigurationsdatei neu starten, das geht über:

sudo service mysql restart

Nach dem Neustart der Datenbank schaue ich mir wieder live das debug.log von WordPress mit tail -f debug.log an und, siehe da, die Fehlermeldung von wegen „The size of BLOB/TEXT data inserted in one transaction is greater than 10% of redo log size.“ war verschwunden. Leider gab es noch eine andere Fehlermeldung, aber davon ein anderes Mal.

]]>
https://supportnet.de/the-size-of-blob-text-data-inserted-in-one-transaction-is-greater-than-10-of-redo-log-size/feed/ 0
Install WordPress, Nginx, PHP7 and MariaDB on a Debian 10 System https://supportnet.de/install-wordpress-nginx-php7-and-mariadb-on-a-debian-10-system/ https://supportnet.de/install-wordpress-nginx-php7-and-mariadb-on-a-debian-10-system/#respond Thu, 17 Dec 2020 22:49:30 +0000 https://supportnet.de/?p=2506925 LEMP stands for Linux/Nginx/MariaDB and PHP. In contrast to LAMP, Linux/Apache/Mysql and PHP should be a server with Nginx somewhat faster than an Apache web server. How to install all this on a naked server with Debian minimum system is described in this article.

What’s the point?

I have been running my own project Supportnet.de on a server with LAMP environment for a few years now and I have to say that it works very well with WordPress. But now I made the experience that the performance of the website delivery has a not quite small influence on the placement in the Google search results. What is good for Google is also good for the visitor of a website, so it should be in any case and in this case it is of course so. The faster the pages are delivered the better the visitor experience.

The hardware is unlike before hardly a problem, if you really need performance you take a dedicated server. But even there there can be problems if the server software is not fast enough. Therefore I wanted to try out on a Hetzner CloudServer how much faster Nginx is compared to Apache. According to internet tests the Nginx is about 2.5 times faster than Apache for static HTML files and only a few percent for all other things. But, perhaps it depends on the few percent to get the own page better than that of the competition as the best search result.

What we need

  1. Cloudserver or dedicated server (from Hetzner or another provider) with Debian 10.x installed
  2. SSH access to the server

If you already want to work with a domain as address, and not with the IP number of the server, then the DNS (Domain Name Server Entry) of the domain should already point to the IP number of your server. Otherwise you have to enter your IP number wherever you see my_domain.

Login and Password

When setting up a new virtual server (cloud server) or a dedicated server (hardware server), Hetzner sends you a mail with the password for root and the IP number of the server.

So log in via ssh to the IP number and login data given in the mail. With dedicated servers you will probably not be asked to change your password immediately, with cloud servers this is the case. So you have to enter your password from the e-mail again and then type in a new one twice (and remember it well).

Updates and Upgrades

Now it is a good idea to update the server to the latest version. The images that are installed are not always fresh and we don’t want to have to live with outdated and insecure packages.

sudo apt update (reads the update list to determine which software packages can be updated)
sudo apt upgrade (then installs the software packages to be updated)

Install Nginx

Now that everything is up to date, you can simply use the command:

sudo apt install nginx

You can check if this worked by simply entering the IP address of your clooudserver (which is in the e-mail) into the address bar of your browser. If you already have a domain for your server and its DSN entries are already working, calling your domain in your browser should produce the same result.

If you get this as an answer you have successfully installed the Nginx.

Install MariaDB Server

The web server is running. To save data or to install a CMS like WordPress you need a database server.

In our case MariaDB, the communit Fork from Mysql.

Install MariaDB

The current software package from MariaDB is called mariadb-server and is installed in this way:

sudo apt install mariadb-server

MariaDB absichern

If the installation of MariaDB was successful, it is important for security that you run a script that deletes and modifies a few things in MariaDB that could be a security problem.

sudo mysql_secure_installation

First, the script asks you for the root password, which is the database root password, not the Linux root password. Since the MariaDB database has just been installed, there is no password yet and you can simply press Enter/Return for an empty password.

  1. First, the script asks you for the root password, which is the database root password, not the Linux root password. Since the MariaDB database has just been installed, there is no password yet and you can simply press Enter/Return for an empty password. The empty password should stay that way, because MariaDB has no password for root, which doesn’t mean that you can log in without a password. The authentication procedure is just different and some MariaDB maintenance processes expect you to be able to log in this way.
  2. Now you will be asked if you want to assign a root password, which you should not do.
  3. The anonymous user, which is installed by default, should then be deleted. Confirm with „Y“.
  4. Now confirm the setting that the root user can only access the database from the local server and then delete the test database.
  5. Then the authorization tables are read in again, this should also be confirmed with y and the Secure Script and the database is ready for operation in the network.

Then the authorization tables are read in again, this should also be confirmed with y and the Secure Script and the database is ready for operation in the network.

Setting Up MariaDB for WordPress

As already written above under Secure MariaDB a MariaDB 10.x version runs on a Debian 10 system where the root user authenticates himself via a unix-socket plugin or other methods. So not with a password. This is important because for the administration of MariaDB you have to create another user with administrative rights.

For the administrative access from root to the MariaDB server you should not change the authentication options and not assign a password for the user root. The root user is used for many administrative purposes and should therefore work as expected by other services. Applications such as log file rotation and server start and stop require a root user account.

It is therefore recommended to create an extra user account for MariaDB with administrative rights.

Therefore we start the MariaDB SQL input with:

sudo mysql

We want to create a user with the name „admin“, the password „password“ and all rights for all databases. For this we enter the following in the following MariaDB prompt:

MariaDB [(none)]> GRANT ALL ON *.* TO 'admin'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION;

Then read in the access rights again:

MariaDB [(none)]> FLUSH PRIVILEGES;

And now leave the MariaDB prompt:

MariaDB [(none)]> exit

Now all we have left to do is test the MariaDB installation.

Test the MariaDB

root@xxxxxxxxxx-debian-2gb-nbg1-1:~# systemctl status mariadb
root@xxxxxxxxxx-debian-2gb-nbg1-1:~# systemctl status mariadb
 ● mariadb.service - MariaDB 10.3.15 database server
    Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
    Active: active (running) since Sat 2019-08-24 13:36:36 CEST; 2h 43min ago
      Docs: man:mysqld(8)
            https://mariadb.com/kb/en/library/systemd/
  Main PID: 8086 (mysqld)
    Status: "Taking your SQL requests now…"
     Tasks: 31 (limit: 4585)
    Memory: 74.5M
    CGroup: /system.slice/mariadb.service
            └─8086 /usr/sbin/mysqld
 Aug 24 13:36:37 xxxxxxxx-debian-2gb-nbg1-1 /etc/mysql/debian-start[8124]: Phase 6/7: Checking and upgrading tables
 Aug 24 13:36:37 xxxxxxxx-debian-2gb-nbg1-1 /etc/mysql/debian-start[8124]: Running 'mysqlcheck' with connection arguments: --socket='/var/run/mysqld/mys
 Aug 24 13:36:37 xxxxxxxx-debian-2gb-nbg1-1 /etc/mysql/debian-start[8124]: # Connecting to localhost…
 Aug 24 13:36:37 xxxxxxxx-debian-2gb-nbg1-1 /etc/mysql/debian-start[8124]: # Disconnecting from localhost…
 Aug 24 13:36:37 xxxxxxxx-debian-2gb-nbg1-1 /etc/mysql/debian-start[8124]: Processing databases
 Aug 24 13:36:37 xxxxxxxx-debian-2gb-nbg1-1 /etc/mysql/debian-start[8124]: information_schema
 Aug 24 13:36:37 xxxxxxxx-debian-2gb-nbg1-1 /etc/mysql/debian-start[8124]: performance_schema
 Aug 24 13:36:37 xxxxxxxx-debian-2gb-nbg1-1 /etc/mysql/debian-start[8124]: Phase 7/7: Running 'FLUSH PRIVILEGES'
 Aug 24 13:36:37 xxxxxxxx-debian-2gb-nbg1-1 /etc/mysql/debian-start[8124]: OK
 Aug 24 13:36:37 xxxxxxxx-debian-2gb-nbg1-1 /etc/mysql/debian-start[8230]: Triggering myisam-recover for all MyISAM tables and aria-recover for all Aria
 lines 1-22/22 (END)

Create MariaDB database and database user for WordPress

WordPress expects an already existing database in which it can create its tables. You have to create it and also a user who has full access to the database has to be created. The WordPress documentation states that this user must have full access to the database. This is interesting because you only have to be able to create, change and delete tables and for security reasons you should only assign the required rights. But WordPress speaks of plugins that can demand more rights and therefore the user should have all rights for the WordPress database.

So we start the database prompt with:

root@xxxxxxxxx-debian-2gb-nbg1-1:~# sudo mariadb

you return to the command mode of MariaDB as root database user. This happens with the sudo command.

As you can see here you log in as a superuser and don’t need a root password. What looks like a security leak guarantees that only users with superuser privileges or processes that have them can log on to the database as root.

So nobody can log into the database via a PHP gap as root, because PHP is not executed as superuser.

To increase security, you should create a separate user for each database with limited rights for this database. This makes sense if you have several different applications with databases.

In this case we create a database called “test_database” an.

MariaDB [(none)]> CREATE DATABASE test_database;

And a user who is only allowed to access this database with the name “test_user” with the password “password” (here please enter a secure password again).

MariaDB [(none)]> GRANT ALL ON test_database.* TO 'test_user'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION;

This user can create, update and delete tables in the database “test_database” but cannot create or change any other databases.

Then read in the authorizations again with:

 MariaDB [(none)]> FLUSH PRIVILEGES;

And exit from the database

 MariaDB [(none)]> exit

Now a test if you can login with the new user “test_user”.

mariadb -u test_user -p

If an error message appears, either the user name of the database user is incorrect or the password is incorrect.

Otherwise you are logged in and can immediately test which databases are available to you:

SHOW DATABASES;

Output

+--------------------+ +--------------------+
| Database           |
+--------------------+
| test_datenbank   |
| information_schema |
+--------------------+
2 rows in set (0.000 sec)

 +--------------------+

And now again „exit“ to leave the MariaDB prompt.

PHP Installation

Unlike the Apache web server, Nginx cannot interpret PHP itself. With Apache you can simply load PHP as a module and that’s it. In order for Nginx to be able to handle PHP, you need to install your own application for PHP to which Nginx can then pass the PHP calls.

For this we need „php-fpm“ („PHP fastCGI process manager“) which you also need for the Apache server if you want to use HTTP2 with it, because the PHP Apache module does not support parallel connections. You have to explain to Nginx that it should control the PHP fastCGI Process Manager with PHP. Additionally you need a module for PHP to access the MariaDB, which is called „php-mysql“.

WordPress requires some additional modules for PHP, without which it runs but then complains in the system overview. So it’s better to install them as well.

To install all enter the following command:

sudo apt install php-fpm php-mysql php7.3-gd php7.3-imagick php7.3-curl php7.3-bcmath

So now all PHP packages are installed. Now a small check which versions are installed.

php --version

 PHP 7.3.4-2 (cli) (built: Apr 13 2019 19:05:48) ( NTS )
 Copyright (c) 1997-2018 The PHP Group
 Zend Engine v3.3.4, Copyright (c) 1998-2018 Zend Technologies
     with Zend OPcache v7.3.4-2, Copyright (c) 1999-2018, by Zend Technologies

mariadb

 Welcome to the MariaDB monitor.  Commands end with ; or \g.
 Your MariaDB connection id is 150
 Server version: 10.3.15-MariaDB-1 Debian 10
 Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
 Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

Configure Nginx for PHP

To be able to use multiple domains with Nginx, Nginx uses server blocks. These server blocks correspond to the virtual hosts of the Apache server. You can set different options for different web pages (domains), such as the document root for the web server. The server blocks also replace the .htaccess file of the Apache server and are therefore the place where you specify redirects or their rules.

Under Debian 10 a server block is preconfigured for Nginx whose document root is /var/www/html. So if you call the IP address of the server or have a DNS entry for a domain point to this IP address, you can call the default configuration. It shows what files are stored under the default document root. In our case under /var/www/html the file „index.nginx-debian.html“ is displayed.

Since I want to host several domains on the server myself, I will explain briefly how to create virtual hosts with Nginx.

Create Server Block

First we create a document root for the first domain, in my case my_domain

sudo mkdir /var/www/my_domain

Adapt the rights of the directories

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

Now we create a new server blocks configuration file in the folder

/etc/nginx/sites-available/my_domain

I always use the vi, you can use your favorite editor for that.

sudo vi /etc/nginx/sites-available/my_domain

Then inserts the following configuration into this text file:

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

    root /var/www/my_domain;
    index index.php index.html index.htm;

    server_name my_domain;

    location / {
        try_files $uri $uri/ =404;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php7.3-fpm.sock;
    }
}

This basic configuration lets Nginx listen on port 80 and distribute files from your web root directory /var/www/my_domain. This configuration (server block) only responds to requests that exactly match your specified domain name. All PHP requests will be forwarded to php-fpm and then, after processing, delivered again.

Then create a softlink to the file so that the configuration of the domain is executed:

sudo ln -s /etc/nginx/sites-available/my_domain /etc/nginx/sites-enabled/

Now a check whether the configuration does not contain any errors is included:

sudo nginx -t

And the obligatory restart of the Nginx server:

sudo systemctl reload nginx

So now the server should run and also interpret PHP.

Test PHP for Nginx

We test this quickly with a small PHP info file, which is quickly generated. Take your favorite editor and create a file info.php in which you write the following:

<?php
phpinfo();

Now calls the file via your browser with the address:

http://my_domain/info.php

As a result you should get a website with very detailed information about your server.

If you need to change the PHP configuration you can restart PHP with this command: systemctl restart php7.3-fpm.

Setting up Nginx for WordPress

What is interesting here is that Nginx does not have a .htaccess file like Apache where you can define redirections. This all has to be done in the configuration of a server block of Nginx. Therefore we change our first server block configuration file so that Nginx can do the redirections WordPress needs.

Plugins that depend on .htaccess can only be used with workarounds with Nginx.

So edit again the file

/etc/nginx/sites-avaiable/my_domain

Und tragt dort folgendes ein.

server {
   server_name my_domain;
   listen 80;
   root /var/www/my_domain;
   access_log /var/log/nginx/access.log;
   error_log /var/log/nginx/error.log;
   index index.php;
   gzip  on;
   gzip_vary  on;
   gzip_min_length  100;
   gzip_buffers  16 8k;
   gzip_proxied  any;
   gzip_types
     text/plain
     text/css
     text/javascript
     application/json
     application/javascript;
  
   location / {
     try_files $uri $uri/ /index.php?q=$uri&$args;
   }
  
   location ~* \.(jpg|jpeg|gif|css|png|js|ico|html)$ {
     access_log off;
     expires max;
   }
  
   location ~ /\.ht {
     deny  all;
   }
  
   location ~ \.php$ {
     fastcgi_index index.php;
     fastcgi_keep_conn on;
     include /etc/nginx/fastcgi_params;
     fastcgi_pass unix:/run/php/php7.3-fpm.sock;
     fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
   }
 }
   

Note: If you are using a different PHP version, you will need to change the line in the „fastcgi_pass unix:/run/php/php7.3-fpm.sock;“ line here. You can read your PHP version like this: php –version

If you change the PHP configuration or a Nginx Server Block you have to restart the Nginx Server:

sudo systemctl reload nginx

If the server is running with this configuration then you should be able to install WordPress now.

Install WordPress

So the server is running and PHP and MariaDB are ready to process the first WordPress data. So let’s install WordPress in the document root of our domain. Therefore we have to download the WordPress package from www.wordpress.org So change to your document root of your server to /var/www/your_domain and execute the command there.

wget https://wordpress.org/latest.tar.gz

Unpacking goes with

tar xfz latest.tar.gz 

This is the link for the German version

wget https://de.wordpress.org/latest-de_DE.tar.gz

The WordPress files are now unpacked into the folder „wordpress“, which we don’t really want. Therefore we move the files back into the document root of our server.

mv wordpress/* .
rm -r wordpress

We could now create the wp-config.php file and enter our data for database access and everything else there, but WordPress makes it easy and lets you enter everything conveniently via your browser. To do this, open your domain in your browser, in our case www.deine-domain.de . It is important that you have changed the file permissions before for the user www-data, otherwise WordPress can not write to the wp-config.php file (above all you save the annoying entering of random characters for the salt addition for the encryption in the database).

chown -R www-data:www-data /var/www/my_domain

Now that all files are unpacked, in the right place and with the right permissions set, we can make a first attempt at installing WordPress from the browser. Enter your domain address in a browser, in our example my-domain. The page that should appear now looks like this.

Click on „Let’s go“ and you will come to the following page where you have to enter your database access data.

What is important here is that you have set up the access data in the section „Create MariaDB database and database user for WordPress“ above. With the table prefix you can also think of something other than wp_, which makes it a bit harder for potential attackers, because they don’t already know what the database tables are called before. It doesn’t matter for WordPress, because the prefix is freely selectable.

Now you can start the installation. If something doesn’t work with the database you will get an error message. Most of the time you mistyped the entered data. Even if your files are not yet writable for the user www-data you get an error message a la:

Eureka, all done. WordPress runs and works with a current Nginx server, with PHP 7.x, MariaDB and WordPress itself.

The cool thing about Hetzner’s cloud servers (it’s the same with all other providers) is that you can copy them back and forth, take snapshots before making a tricky change and extend them quite well. If you need more CPU power you can book additional CPUs, or more RAM or what’s also very cool just mount more disk space. On one of my test servers I simply mounted an additional 40 GB of disk space on /var/www/html to have more space for data (this costs about 2-3 Euro more per month). So everything is very flexible.

Conclusion

If all goes well, you have installed such a WordPress installation on your server in an hour. Unfortunately everything doesn’t always work right away. If the server is running, it is really fast. My first speed tests with the WordPress installation still without additional plugins and little content show a good result with Google Page Speed Insights, for the desktop version 100% and for the mobile 95%. Of course, this all changes when the database is full and more than one user accesses the page. A good result for a virtual server with only two CPU cores, 4 GB RAM and 20 GB disk space.

With the snapshot function of the cloud servers I will now do some performance tests with data and different configurations.

Advertising and sponsoring

So I’m raving about Hetzner as provider for our server and that’s due to the almost 20 years of experience I’ve had with Hetzner. The support of Hetzner was always very helpful and has us in emergencies always tried to offer a good solution, so also thought how to solve an emerged problem.

Therefore I write it out here again, I did not get any advantages by this article from the company Hetzner, but what is not can still become ;-)

]]>
https://supportnet.de/install-wordpress-nginx-php7-and-mariadb-on-a-debian-10-system/feed/ 0
Mehrere Zeilen in Notepad++ suchen und ersetzen https://supportnet.de/mehrere-zeilen-in-notepad-suchen-und-ersetzen/ https://supportnet.de/mehrere-zeilen-in-notepad-suchen-und-ersetzen/#respond Thu, 05 Sep 2019 19:58:34 +0000 https://supportnet.de/?p=2506964 Zu meinen Lieblingseditoren gehört auf Windows der Notepad++, er kann eigentlich alles was ich so brauche und unterstützt mich dabei in meiner Arbeit. Ich kann mit ihm sehr große Dateien bearbeiten aber auch hunderttausende Dateien in einem Zug verändern. Mit Suchen und Ersetzen kann man sehr einfach einzelne Dateien verändern oder auch mehrere Zeilen auf einmal austauschen. Wie man einen ganzen Textblock auf einmal ersetzt beschreibe ich hier.

Kurz und Knapp

  1. Markiere die Zeilen, die ersetzt werden sollen
  2. Ersetze in den Zeilen, die du einfügen möchtest den Zeilenumbruch mit \n
  3. Stelle in dem „In Dateien suchen“ Dialog den Suchmodus auf „Erweitert“

Zu ersetzenden Text eingeben

Öffne deine Datei in der einer der Blöcke enthalten ist, die du ersetzen willst. Markiere diese Zeilen mit der Maus indem du die linke Maustaste gedrückt hältst.

Notepad ++ Text Block mit der Markieren
Notepad ++ Text Block mit der Maus der Markieren

Klicke im Menü oben auf „Suchen“ und dann auf „Ersetzen, der „In Dateien suchen“ Dialog öffnet sich.

Im Feld „Suchen nach“ wird jetzt der vorher markierte Text angezeigt. Wenn man den einfach nur löschen will, kann man die Zeile „Ersetzen durch“ jetzt leer lassen und ist schon fertig. Wenn man seinen Text Block aber auch mit mehreren Zeilen ersetzen will, muss man den neuen Text etwas vorbereiten.

Text, der eingefügt werden soll eingeben

Öffne dazu einen weiteren Tab in Notepad++ und füge da deinen einzufügenden Text ein.

Klicke jetzt jeweils am Anfang der zweiten Zeile mit der Maus und drücke dann einmal die Backspace Taste, so dass, die zweite Zeile zur ersten oben angefügt wird. Füge dann an die Stelle wo die erste Zeile zu Ende gewesen wäre die Zeichenfolge „\n“ ein

Wenn das mit allen Zeilen gemacht wurde, kopiere die eine Zeile mit „strg + c“ in die Zwischenablage und gehe wieder auf den „In Dateien suchen“ Dialog. Klicke dort im Feld „Ersetzen durch“ mit der Maus und füge den kopierten Text mit „strg + V“ dort ein.

Um das Ganze zu testen kannst du auf „Suche weiter“ klicken, dann sollte der zu ersetzende Text Block zumindest einmal gefunden und markiert werden.

Block suchen und ersetzen

Wenn das geklappt hat, dann kannst du mit „Ersetzen“ oder „Alle ersetzen“ das Suchen und Ersetzen von mehreren Zeilen starten.

Mehrere Zeilen in vielen Dateien suchen und ersetzen

Will man mehrere Zeilen in vielen Dateien suchen und ersetzen so kann man das im „In Dateien suchen“ Dialog mit dem Reiter „In Dateien suchen“ machen. Dort gibt man die zu suchenden und zu ersetzenden Zeilen so ein wie oben beschrieben. Man kann jetzt zusätzlich einen Dateifilter setzen, also welche Dateien überhaupt durchsucht werden sollen und deren Verzeichnis angeben. So bearbeite ich relativ schnell sehr viele Dateien auf einmal. Wer also aus vielen z.B. HTML Dateien einen Werbetag ändern will, kann das so sehr einfach mit Notepad++ machen.

Wichtig, es muss immer unten links als „Suchmodus“ Erweitert angeklickt sein.

]]>
https://supportnet.de/mehrere-zeilen-in-notepad-suchen-und-ersetzen/feed/ 0
How can I test my hard drive? https://supportnet.de/how-can-i-test-my-hard-drive/ https://supportnet.de/how-can-i-test-my-hard-drive/#respond Tue, 03 Sep 2019 22:23:56 +0000 https://supportnet.de/?p=2506958 Short and scarcely

With tools like Crystal Disk Info or manufacturer tools like Software Magican from Samsung you can read out the S.M.A.R.T values of the hard disks and thus recognize the state of the disks.

Solid State Drives, SSDs for short, are increasingly outstripping conventional hard disks. But they are not as perfect as it seems. For example, they only allow a certain number of write accesses before individual cells are damaged. But there are ways to check your own SSD and see if it is scratching on the expiration date.

SMART

The magic word here is SMART, Self Monitoring Analysis and Reporting Technology. SMART keeps a diary of the flash drive, so to speak. In this diary you can then see whether, for example, individual cells are already defective. How to get this „diary“ is explained in the following.

Who would like to read out the own SSD professionally, that should go to the Downloadportal of the manufacturer. Thus the large nameful manufacturers offer small Tools, which are aligned to the special models. With Samsung for example the Software Magican.

There are also non manufacturer-specific programs in this area of the tools, but they do not yet have the same accuracy when reading data.

Allround SMART Tool

Crystal Disk Info reads the S.M.A.R.T values from all hard disks

Crystal Disk Info is also available as Portable Version and can be downloaded for free from the manufacturer Crystal Mark.

Crystal Disk Infor displays not only the values for SSDs, but also the values for HDDs or hard drives connected via USB:

Crystal Disk Infor shows you quickly and clearly the status of all connected hard disks it detects.

Amongst other things you can make small optimizations on the operating system with these tools. These optimizations are then adapted to the SSD to enable faster operation. In addition, a firmware update for the Solid State Drive can be done via such a program.

With such a tool you have a good overview of your own drive. But if you want to have it more precise, you have to access the raw values, which document  write and read errors, written amounts of data, number of operating hours and also the temperature.

If you want to access not only the stored data, but also the latest data, you have to do a so-called short self test. Here hardware tests are made in a short analysis by random principle.

If you get this evaluation, you can’t do much with it as a beginner. You have to analyze the data yourself and then draw conclusions. If you can see that the read error rate is high, you should make a backup and possibly use a new SSD. In the following the most important parameters are explained:

Explanation of the individual values

Raw Read Error Rate

read error rate

Reallocated Sector Count

Removed data in reserve sectors

Power-On Time

Number of operating hours

Program Fail Count

Flash programming error

Erase fail Count

Flash erase error

Temperature

Operating temperature according to internal sensor

CRC Error Count

Appearing SATA interface errors

Media Waereout Indicator / SSD Life Left

flash erosion indicator

Host Writes / Total LBAs Written

Counts the total amount of data written in sectors

.

Host Reads / Total LBAs Read

Counts the total amount of data read in sectors

Translated with www.DeepL.com/Translator

]]>
https://supportnet.de/how-can-i-test-my-hard-drive/feed/ 0
Wie kann ich, ohne Plugin, einen Beitrag in WordPress kopieren (Gutenberg Editor) https://supportnet.de/wie-kann-ich-ohne-plugin-einen-beitrag-in-wordpress-kopieren-gutenberg-editor/ https://supportnet.de/wie-kann-ich-ohne-plugin-einen-beitrag-in-wordpress-kopieren-gutenberg-editor/#respond Mon, 02 Sep 2019 16:39:31 +0000 https://supportnet.de/?p=2506944 Für manche Fälle kann es nützlich sein, wenn man einen schon geschriebenen Beitrag einfach in einen neuen kopieren kann. Hat man zum Beispiel eigenen CSS Code, den man immer wieder verwenden will, dann ist es einfacher sich einen Beitrag mit alles Blöcken zu kopieren als den CSS Code jedes mal wieder in alten Beiträgen suchen zu müssen. Oder man will seine Seite in einer weiteren Sprache anbieten, dann kopiert man einfach den ganzen Beitrag und übersetzt die einzelnen Absätze.

Wie man einen Beitrag auch ohne Plugin in WordPress kopiert beschreibe ich hier. Es gibt dafür einige Plugins wie „Dublicate Post“ oder „Page and Post Clone“.

Um aber nur ab und an mal einen Beitrag zu kopieren sollte man nicht gleich ein Plugin installieren.

  1. Jedes zusätzliche Plugin bietet mehr Angriffsfläche für Bösewichte -> Sicherheitsproblem
  2. Jedes zusätzliche Plugin kostet auch Performance und man will ja eine schnelle Webseite haben.

Der Gutenberg Editor von WordPress bringt so eine Möglichkeit schon von Haus aus mit. Man kann mit ihm einfach per copy und paste einen Beitrag kopieren. Sie ist etwas versteckt aber leicht zu finden und hat man es einmal verstanden ist es recht einfach.

Man geht einfach oben rechts auf die drei übereinander angezeigten Punkte

Dann öffnen sich die Optionen des Guttenberg Editors, dort wählt man dann die Option „Kompletten Inhalt kopieren“ aus.

Jetzt ist der ganze Inhalt des Beitrags als html-Text in die Zwischenablage kopiert worden. Diese kann man jetzt überall hin mit der Tastenkombination:

"strg + v" (bei Windows Systemen)
"Befehlstaste (oder Cmd-Taste) ⌘ + v" (bei Apple Systemen)

kopieren. Auch in einen neuen Beitrag. Dazu erstellst du einfach einen neuen Beitrag und klickst einmal in das Absatz-Feld unter der ersten, noch leeren, Überschrift, und betätigst dann die Tastenkombination „strg + v“ (Befehlstaste (oder Cmd-Taste) ⌘ +v“) um den Inhalt der Zwischenablage in den Editor zu kopieren. Solange noch die Überschrift aktiviert ist, also der Mauscursor dort noch blinkt, wird der html-Text in die Überschrift kopiert statt in neue Blöcke.

Jetzt werden alle Blöcke der ersten Seite auch in diese eingefügt, bis auf die Überschrift, was auch Sinn macht, da man ja weder den gleichen Inhalt noch die gleiche Überschrift zwei mal haben sollte.

Man kann das in der Zwischenablage gespeicherte HTML auch in den „Classic Editor“ in der HTML-Ansicht kopieren, das funktioniert genau so gut. Dieser Trick funktioniert also für beide Editoren von WordPress.

]]>
https://supportnet.de/wie-kann-ich-ohne-plugin-einen-beitrag-in-wordpress-kopieren-gutenberg-editor/feed/ 0