Mein neues Lima-City Webhosting! Besser als Netcup und Webgo?

Nach langer Suche hab ich nun in Lima-City.de meinen neuen Webhosting Provider gefunden, warum das so ist erfahrt ihr im Artikel.

lima-city: Webhosting, Domains und Cloud

Den Wechsel hab ich jeweils vom Netcup Webhosting 8000 SE de und vom Webgo CMS Power (SSD) zum Lima-City Business Tarif vollzogen.

Im Vergleich zum Webgo und Netcup Hosting ist die Administration’s Oberfläche von Lima-City zur Verwaltung des Webhostings deutlich schneller. Die Oberfläche ist von den Funktionen logisch aufgebaut und sieht im Vergleich zur veralteten Webgo Oberfläche deutlich moderner aus, es macht wirklich Spaß darüber sein Webhosting zu konfigurieren.

Das Backend erkennt sogar vorhandene WordPress Installationen die man auf den FTP Server geladen hat, hier können dann direkt in der Verwaltung’s Oberfläche diverse Änderungen im WordPress vorgenommen werden, das gibt es bei den beiden anderen Mitbewerben nicht in dieser Form.

Bei Lima-City können ebenfalls externe Domains aufgeschaltet werden und mit diesen dann auch die kostenlosen Let’s Encrypt Zertifikate genutzt werden. Was mir auch besonders wichtig war und bei Lima-City dazu gehört ist die Nutzung von MySQL Datenbanken auf externen Servern.

Prinzipiell bin ich bisher wirklich schwer begeistert von Lima-City, denn auch die Performance ist vor den beiden anderen Anbietern und das ohne garantierten Arbeitsspeicher wie bei Netcup (8GB) und Webgo (2GB).

Hier mal der Benchmark und I/O Test auf meinem Lima-City Webspace:

--------------------------------------
|        PHP BENCHMARK SCRIPT        |
--------------------------------------
Start : 2020-11-22 13:23:09
Server : sleip.clan.rip@172.17.0.8
PHP version : 7.4.7
Platform : Linux
--------------------------------------
test_math                 : 0.276 sec.
test_stringmanipulation   : 0.279 sec.
test_loops                : 0.209 sec.
test_ifelse               : 0.153 sec.
--------------------------------------
Total time:               : 0.917 sec.

Benchmark: https://sleip.clan.rip/test/bench.php

Laufzeit gesamt: 826ms pro Zyklus(Schnitt): 0.055067ms

I/0: https://sleip.clan.rip/test/io.php

Im Vergleich dazu hier die beiden Test’s von Netcup und Webgo.

Zum Netcup Webhosting 8000 SE de:

Mit dem Netcup Hosting war ich aufgrund der viel zu hohen Server Auslastung und den dadurch resultierenden kurzen Ausfällen nie richtig zufrieden. Das habe ich dem Support auch mehrmals mittgeteilt und in deren Forum habe ich das in diesem Thread auch widerholt angesprochen. Es wurden im Laufe der Zeit zwar Verbesserungen durchgeführt wie z.B. das aktualisieren der eingesetzten Server Software sowie ein aufstocken der Hardware, allerdings hatte keine dieser Vorkehrungen einen positiven Einfluss auf die hohe Server Auslastung.

Hier ist die CPU Auslastung des Netcup Servers zu sehen auf dem mein Webhosting lag, die Grafiken zeigen die Auslastung über 24 Stunden am 08.06.2020, 15.06.2020 und am 24.06.2020:

Netcup cpu usage 08.06.2020

Netcup cpu usage 15.06.2020

Netcup cpu usage 24.06.2020

Ich möchte hier nochmals erwähnen das ich seit ungefähr 2012 Netcup Kunde mit einem Expert M Hosting war welches unter 5€ gekostet hat, dort gab es nie solche Performance Probleme wie mit dem aktuellsten und stärksten Webhosting 8000 Tarif für knapp 10€ pro Monat. Was nützt einem der beworbene enorme Speicherplatz von 500GB und die Arbeitsspeicher Garantie von 8GB wenn der Server so dermaßen ausgelastet wird das meine gehostete Seite teilweise Ladezeiten von +20 Sekunden hat? Richtig gar nichts, denn dadurch geht nicht nur das Google Ranking flöten sondern auch die Besucher, denn heute wartet niemand mehr +20 Sekunden darauf das eine Seite komplett ausgeladen hat.

Das SLA wie auch die garantierte Verfügbarkeit von 99,6% wurde von Netcup stets eingehalten. Die Uptime der letzten 30 Tage lag bei 99,977% laut Uptime Robot.

Netcup Uptime

Zum Webgo CMS Power (SSD):

Bei Webgo war ich nun 1 Jahr Kunde, die Server Performance war stets einwandfrei und gab keinen Anlass zur Kritik. Dazu schaut Euch auch meinen Performance Test an.

Ich hatte allerdings vor einer Woche einen Ausfall meines Hostings von knapp 9 Stunden, was aus meiner Sicht deutlich zu lang war. Das ist dann wohl auch der Grund weshalb es beim Webgo Webhosting kein SLA und demnach keine garantierte Mindestverfügbarkeit wie bei Netcup 99,6% oder bei Lima-City 99,9% gibt.

Die Uptime der letzten 30 Tage lag bei 98,774% laut Uptime Robot, allerdings war die Erreichbarkeit vor dem Ausfall immer bei über 99,9%, es gibt aber Stand November 2020 wie oben bereits angesprochen kein SLA und damit auch keine garantierte Mindestverfügbarkeit bei Webgo.

Webgo Uptime

UnixBench auf CentOS installieren!

Hier eine kurze Anleitung wie Ihr das Benchmark Tool UnixBench auf einem CentOS Server/vServer installiert. Die Installation für Debian/Ubuntu läuft ähnlich ab, nur muss das yum durch ein apt-get ersetzt werden.

wget http://byte-unixbench.googlecode.com/files/unixbench-5.1.3.tgz
gunzip unixbench-5.1.3.tgz
tar -xvf unixbench-5.1.3.tar
cd unixbench-5.1.3
./Run

Mögliche Fehlermeldung:

Can't locate Time/HiRes.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vend
or_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at ./Run line 6.
BEGIN failed--compilation aborted at ./Run line 6.

Lösung:

yum install perl-Time-HiRes
./Run

Mögliche Fehlermeldung:

gcc -o ./pgms/arithoh -DTIME -Wall -pedantic -ansi -O2 -fomit-frame-pointer -fforce-addr -ffast-math -Wall -Darithoh ./src/arith.c
make: gcc: Command not found
make: *** [pgms/arithoh] Error 127
Checking distribution of files
./pgms  exists
./src  exists
./testdir  exists
./tmp  exists
./results  exists
gcc -o ./pgms/arithoh -DTIME -Wall -pedantic -ansi -O2 -fomit-frame-pointer -fforce-addr -ffast-math -Wall -Darithoh ./src/arith.c
make: gcc: Command not found
make: *** [pgms/arithoh] Error 127

Lösung:

yum install gcc
./Run

Sobald UnixBench gestartet ist dauert es je nach Servergeschwindigkeit einige Minuten bis Euch das Ergebnis der Serverleistung angezeigt wird.

Ist alles durchgelaufen sieht das Ergebnis so aus, hier handelt es sich um Netcups kleinsten Root-Server S:

========================================================================
   BYTE UNIX Benchmarks (Version 5.1.3)

   System: v22013091804614475.yourvserver.net: GNU/Linux
   OS: GNU/Linux -- 3.2.0-4-amd64 -- #1 SMP Debian 3.2.41-2
   Machine: x86_64 (unknown)
   Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
   CPU 0: Intel(R) Xeon(R) CPU E5645 @ 2.40GHz (4788.0 bogomips)
          x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET
   23:08:11 up 9 min,  1 user,  load average: 0.15, 0.08, 0.06; runlevel 2

------------------------------------------------------------------------
Benchmark Run: Fri Sep 13 2013 23:08:11 - 23:36:19
1 CPU in system; running 1 parallel copy of tests

Dhrystone 2 using register variables       26536032.2 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     3207.7 MWIPS (9.6 s, 7 samples)
Execl Throughput                               3533.5 lps   (29.8 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        926550.0 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks          271528.3 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks       1524390.7 KBps  (30.0 s, 2 samples)
Pipe Throughput                             2058002.4 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 323703.6 lps   (10.0 s, 7 samples)
Process Creation                              10211.7 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   6530.4 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                    848.0 lpm   (60.0 s, 2 samples)
System Call Overhead                        3824876.4 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   26536032.2   2273.9
Double-Precision Whetstone                       55.0       3207.7    583.2
Execl Throughput                                 43.0       3533.5    821.7
File Copy 1024 bufsize 2000 maxblocks          3960.0     926550.0   2339.8
File Copy 256 bufsize 500 maxblocks            1655.0     271528.3   1640.7
File Copy 4096 bufsize 8000 maxblocks          5800.0    1524390.7   2628.3
Pipe Throughput                               12440.0    2058002.4   1654.3
Pipe-based Context Switching                   4000.0     323703.6    809.3
Process Creation                                126.0      10211.7    810.5
Shell Scripts (1 concurrent)                     42.4       6530.4   1540.2
Shell Scripts (8 concurrent)                      6.0        848.0   1413.3
System Call Overhead                          15000.0    3824876.4   2549.9
                                                                   ========
System Benchmarks Index Score                                        1418.2

phpMyAdmin im Document Root mit .htaccess schützen

Aufgrund dessen das es bei phpMyAdmin immer wieder Sicherheitslücken gab habe ich heute das Verzeichnis bei mir auf dem Server mit .htaccess geschützt. Auch alle anderen Verzeichnisse unter /var/www können nur noch mit Passwort aufgerufen werden.

Somit ist es für Script Kiddys oder Bots nicht mehr möglich den Document Root zu betreten ohne einen richtigen Benutzernamen und ein Passwort eingegeben zu haben. Klar ist das hinter diesem .htaccess Schutz noch die normale Anmeldemaske mit Benutzernamen und Passworteingabe erscheinen, somit quasi ein doppelter Schutz vor Eindringlingen. Wie ich das gemacht habe will ich euch in meiner kurzen Anleitung mal zeigen, mein Server Betriebssystem ist Debian Etch 64Bit.

Zuerst mal müsst ihr eine .htaccess Datei im Verzeichnis
/var/www/phpmyadminanlegen. In diese Datei schreibt ihr dann folgendes.

AuthType Basic
AuthName "Passwortschutz"
require valid-user
AuthUserFile /var/www/phpmyadmin/.htpasswd

Unter AuthName kommt das rein was ihr gerne über dem Anmeldefenster stehen haben wollt, kann auch leer bleiben. Unter AuthUserFile müsst ihr den absoluten Pfad zu eurer .htpasswd eintragen (siehe unten), diese enthält euren Benutzernamen und das verschlüsselte Passwort.

Nun könnt ihr entweder im selben Verzeichnis die .htpasswd erstellen oder ihr legt diese woanders hin, denkt aber bitte daran auch anschließend den Link in der .htaccess anzupassen. Weil das Passwort in der .htpasswd verschlüsselt sein muss verweise ich mal auf PHP-Space.info.

Dort könnt ihr unter Angabe eures Benutzernamens und eures Passworts den Inhalt der .htpasswd erstellen lassen. Kopiert dann alles und fügt es in die zuvor angelegte .htpasswd ein und speichert diese ab. Als Beispiel würde das jetzt für unseren Benutzer Max und seinem generierten Passwort so aussehen.

Max:$1$REwsjDUi$04HEpKpAYYDnIj/wY7atn0

So, jetzt ist das Gröbste schon erledigt.
Nun müssen wir mal folgende Datei öffnen.

/etc/apache2/sites-available/default

Dort muss der Punkt AllowOverride None auf AllowOveride All geändert werden, allerdings nur für den DocumentRoot. Das ist nötig weil die URL mit AllowOverride None generell immer ausgegeben wird, somit würde unser .htaccess Schutz einfach umgangen werden. Bei AllowOverride All hingegen wird die URL nur ausgegeben wenn die Zugriffssteuerung unserer .htaccess Abfrage positiv war.

AllowOverride All

Ok, das wars schon, jetzt den Apachen nochmal neu starten.

/etc/init.d/apache2 restart

Wenn ihr jetzt alles richtig gemacht habt könnt ihr das Verzeichnis von phpMyAdmin nicht mehr ohne die .htaccess Passwort-Abfrage aufrufen.

Viel Spaß beim ausprobieren ;)

Als kleinen Tipp am Rande empfehle ich euch noch allen Verzeichnissen unter /var/www andere Namen zu geben, denn Bots scannen den kompletten DocumentRoot nach Ordnern ab die im Namen phpMyAdmin usw. enthalten.

Einbinden von Bildern verbieten

Wenn ihr verhindern wollt das Bilder von eurem Webspace auf anderen Seiten eingebunden werden, z.B. weil ihr nicht besonders viel Traffic frei habt, müsst ihr euch mal folgenden Code ansehen.
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?domain.tld(/)?.*$ [NC]
RewriteRule .*\.(gif|jpg|jpeg|bmp|png)$ http://www.domain.tld/bild.jpe [R,NC]
Dieser Code muss als „.htaccess“ in den Ordner abgespeichert werden in dem eure Bilder liegen. Wenn ihr jetzt nicht nur verhindern wollt das die Bilder nicht angezeigt werden, sondern das auch noch eine alternatives Bild anstelle des geklauten Bildes angezeigt wird, dann müsst ihr in der Zeile „Rewrite Rule“ den Link zu diesem alternativen Bild anpassen. Das was unter „Rewrite Rule“ in Klammern steht „(gif|jpg|jpeg|bmp|png)“ sind die Dateiendungen die blockiert werden und für die das alternative Bild angezeigt wird.

Ich hatte dieses Script selbst 2 Jahre im Einsatz, es funktioniert auch bestens mit WordPress, dazu die „.htaccess“ unter „/wp-content/uploads“ hoch laden und schon werden die Bilder blockiert.