Posts by jamesbond

    Hallo @Kraeutergarten,

    • packages.sury.org/php/

    Dieses Repo wird von jemanden betrieben, der auch die offiziellen Debian Pakete betreut.

    das ist natürlich eine wichtige Info! - Besten Dank. Das ändert die Situation schon mal ein wenig.


    Wenn ich PHP 7.2 aus diesem Repo installieren würde, müßten dann auch alle PHP-Module wie z.B. php-curl, php-gd, php-imagick, php-mbstring, php-mysql, php-zip, usw. aus diesem Repository kommen? Falls ja: Kann ich vorher irgendwie überprüfen, ob es überhaupt alle PHP-Module in diesem Repository gibt, die ich für meine Anwendungen (u.a. nextcloud, ttrss sowie ein Forum) benötige?

    Hallo zusammen,


    auf einem netcup-Rootserver mit Debian-Stretch nutze ich unter anderem eine veraltete Version von nextcloud. Nun wollte ich nextcloud updaten auf das aktuelle Release (16.0.1). Zu meiner Überraschung steht in der nextcloud-Dokumentation im Abschnitt "Prerequisites for manual installation", daß für nextcloud 16 eine der drei folgenden PHP-Versionen benötigt wird: 7.1, 7.2 oder 7.3.


    Debian-Stretch bietet in den Standard-Repositories jedoch maximal Version 7.0 von PHP an. Auf meine Anfrage bei den nextcloud-Leuten wurde ich darüber informiert, daß die Version 7.0 von PHP bereits "end of life" ist und nicht mehr supported wird. Auch (Security-)Updates gibt es wohl keine mehr für 7.0.


    Bisher war mein Verständnis das, daß es sich bei Debian um eine sehr verbreitete Server-Distribution handelt und deshalb eine gute Wahl zum Hosting von Web-Applikationen darstellt. Daß man mit dem aktuellen Debian-Release bei einer nicht mehr unterstützten PHP-Version landet und deshalb aktuelle Software, die PHP voraussetzt, nicht mehr nutzen kann, hätte ich eigentlich nicht für möglich gehalten.


    An Lösungsvorschlägen wurden mir bisher folgende unterbreitet:

    1. PHP 7.2 installieren aus einem mir unbekannten Repository (packages.sury.org/php/)
    2. warten auf das nächste Debian-Release "Buster"

    Zu Vorschlag Nummer 1: Ein non-standard-Repository einzubinden, mag ich eigentlich grundsätzlich nicht. Woher soll ich wissen,

    • ob man dieser Software überhaupt trauen kann?
    • ob darüber (Security-)Updates ausgeliefert werden?
    • ob ich mir zukünftig damit irgendwelche (Kompatibilitäts-)Probleme einhandeln werde?
    • ob es das Repository in einem Monat oder in einem Jahr überhaupt noch geben wird?

    Und mit Vorschlag Nummer 2 kann mein Problem nicht jetzt, sondern erst zu einem aktuell noch unbekannten Zeitpunkt in der Zukunft gelöst werden.


    Aktuell läßt mich diese Situation etwas ratlos zurück. Sollte ich mich ggf. nach einer anderen Server-Distribution umschauen?


    Vielleicht habt Ihr schon mal ein ähnliches Problem gehabt? Und im Idealfall auch irgendwie gelöst? - Für Kommentare, Erfahrungsberichte, Meinungen und Vorschläge bin ich auf jeden Fall dankbar.

    Hallo Anzulo , falls es auf Deinem System eine Datei namens /etc/network/interfaces.d/50-cloud-init.cfg gibt, dann verschieb die mal (z.B. in ein Temp-Verzeichnis).

    Die bei einigen Servern/Usern offenbar vorhandenen Stabilitäts-Probleme möchte ich keinesfalls klein- oder gar wegreden. Auf jeden Fall kann ich für meinen "RS 2000 SAS G7SE" feststellen, daß in den bisher knapp 6 Monaten Nutzungszeit noch kein einziges Problem aufgetreten ist.

    Hallo broda ,


    ich betreibe ebenfalls ein Simple Machines Forum in der Version 2.0.15 (allerdings auf einem Root-Server 2000) und habe mit dem Zugriff per IPv6 keinerlei Probleme. Bist Du sicher, daß Deine Fehler mit einer IPv6-Problematik zu tun haben?


    Hast Du Zugriff auf die Apache-Error-Logs? Wenn ja: was wird dort protokolliert, wenn Du im Browser einen Fehler angezeigt bekommst?

    @Remsboys: Hm, bei Dir ist gar keine öffentliche IPv6 aktiviert. Bei mir ist das der Fall, es hatte aber nach dem Neustart die Default-Route gefehlt. - Lösung war: Server einmal komplett ausschalten (nicht nur rebooten) und dann wieder hochfahren. Danach war sowohl die Default-Route wieder da als auch die ewigen Wartezeiten beim Aufruf von Webseiten komplett verschwunden.

    Hallo talkuvit ,


    im Find-Kommando mußt Du "Verzeichnis" natürlich mit kleinem "v" schreiben, wenn die Dateien wie angegeben heißen. Ansonsten denke ich, daß es grundsätzlich funktionieren sollte. Allerdings müßtest Du (um genau zu sein) "-mtime +29" angeben, um Dateien älter als 30 Tage zu löschen.

    Hallo zusammen,


    bei der Installation von Debian Stretch über das von netcup bereitgestellte Minimal-Image (ohne irgendwelche Verwaltungs-Panels) sind mir zwei Dinge aufgefallen:


    Code
    1. > cat /etc/debian_version
    2. 9.1


    Obwohl mit "apt update" bzw. "apt upgrade" keinerlei Aktualisierungen verfügbar sind, wird nicht die aktuellste Debian-Version gemeldet. Erwartet hätte ich hier 9.2. - Ist meine Erwartungshaltung falsch oder liegt hier irgendein Problem vor?


    Code
    1. > cat /etc/apt/sources.list
    2. deb http://ftp.de.debian.org/debian/ stretch main
    3. deb-src http://ftp.de.debian.org/debian/ stretch main
    4. deb http://security.debian.org/debian-security stretch/updates main
    5. deb-src http://security.debian.org/debian-security stretch/updates main


    Bei meinem Rootserver aus 2015 wurde automatisch (also ohne daß ich etwas geändert hätte) der netcup-Mirror verwendet. Hat netcup hier einfach nur vergessen, in dem bereitgestellten Image die sources.list entsprechend anzupassen? - Da die Updates über den netcup-Mirror erheblich schneller über die Bühne gehen, frage ich mich: Ist es mit irgendwelchen Nachteilen verbunden, wenn ich die Repository-URLs in der sources.list einfach auf den netcup-Mirror umbiege?


    Danke im voraus für Eure Kommentare.

    Vorhin hatte ich die Messung zwei, drei mal wiederholt, um sicherzustellen, daß es sich nicht nur um einen Ausreißer handelt. Nun, knapp eine Stunde später, habe ich das ganze nochmal versucht, mit deutlich besserem (wenn auch nicht überragendem) Ergebnis:

    Code
    1. # /sbin/hdparm -tT --direct /dev/sda3
    2. /dev/sda3:
    3. Timing O_DIRECT cached reads: 3112 MB in 2.00 seconds = 1555.24 MB/sec
    4. Timing O_DIRECT disk reads: 460 MB in 3.00 seconds = 153.12 MB/sec


    Vielleicht gab es nur ein temporäres Problem auf dem Wirtssystem?

    Die Werte stammen nicht aus dem Rettungssystem.


    Zu tun hat der Server im Grunde so gut wie nichts. Vor dem Sart der obigen Kommandos habe ich das mittels htop sowie iotop überprüft. - Der Server ist eigentlich dafür vorgesehen, verschiedene Web-Anwendungen zu betreiben. Bisher habe ich allerdings apache und PHP noch gar nicht installiert.

    Auch ein Test mit dd bringt absolut inakzeptable Werte:

    Code
    1. # dd if=/dev/zero of=disk.img bs=1024k count=6000
    2. 6000+0 records in
    3. 6000+0 records out
    4. 6291456000 bytes (6.3 GB, 5.9 GiB) copied, 279.851 s, 22.5 MB/s


    Hilfe?!

    Hallo zusammen,


    auf meinen brandneuen RS 2000 SAS sieht das leider so aus:

    Code
    1. # /sbin/hdparm -tT --direct /dev/sda3
    2. /dev/sda3:
    3. Timing O_DIRECT cached reads: 24 MB in 2.02 seconds = 11.86 MB/sec
    4. Timing O_DIRECT disk reads: 4 MB in 3.47 seconds = 1.15 MB/sec


    Dementsprechend frage ich mich natürlich, ob ich irgendwas falsch mache...?

    Vielen Dank für alle Antworten. Da gemäß Auskunft des Supports ein späterer Wechsel von SSD auf SAS nicht möglich ist, werde ich mich angesichts des extrem limitierten Speicherplatzes der SSD-Variante wohl für die SAS-Option entscheiden.

    Root-Server Herbst-Aktion


    Frage dazu: Beim meinem letzten Wechsel auf den "Root-Server M SSD v6" war ich relativ enttäuscht, daß der Umstieg von Festplatte auf SSD sich kaum bemerkbar gemacht hat. Daher mal eine Frage an diejenigen, die einen Vergleich anstellen können zwischen einem Root-Server der aktuellen Generation 7 einerseits mit SSD und andererseits mit SAS-Platten: Hat jemand Meßwerte zum Unterschied bei Lese-/Schreibzugriffen? Oder zumindest eine subjektive Einschätzung dazu?


    Auf meinem Rootserver laufen im wesentlichen die beiden Applikationen Tiny Tiny RSS und Nextcloud basierend auf Apache, PHP und MySQL.


    Meine Überlegung ist, die aktuellen Angebote zum Wechsel auf die aktuelle Rootserver-Generation sowie von Debian 8 auf Debian 9 zu nutzen. Allerdings bin ich noch unentschieden, welches Produkt es genau sein soll - speziell bei der Frage, ob SSD oder SAS. Dementsprechend bin ich für alle konstruktiven Hinweise dankbar.