Beiträge von jamesbond

Zitat von AndreasD

Gute Idee, aber sollte ufw disable nicht per sudo eriolgen?

Ich persönlich mache das noch ganz old-fashioned als root, aber per sudo geht sicherlich auch.

Hallo AndreasD,

um ein dauerhaftes Selbst-Aussperren zu vermeiden, kann man vor dem Aktivieren neuer Firewall-Regeln per "ufw enable" sicherheitshalber erstmal eine zeitgesteuerte Deaktivierung beispielsweise 10 Minuten später vorsehen:

echo "/usr/sbin/ufw disable" | at 21:45

So kann man in Ruhe schauen, ob die erstellten Regeln den gewünschten Effekt haben. Und falls man über das Ziel hinaus geschossen ist, kann man nach 10 Minuten einen neuen Anlauf nehmen.

Inzwischen habe ich festgestellt, daß für meine Zwecke ncdapi (inofficial netcup DNS API Client, https://github.com/linxside/ncdapi) die bessere Lösung darstellt.

Hallo Patrick0815, besten Dank für Deine schnelle Antwort.

Hallo zusammen,

ich versuche gerade, ownDynDNS von felix.kretschmer einzurichten. Der Aufruf erfolgt bei mir nicht über die Fritzbox, sondern wie https://github.com/fernwerker/…examples/update-dyndns.sh dargestellt per bash-Skript. Irgendwas mache ich offenbar nicht richtig, aber bisher habe ich noch nicht rausgefunden, was das ist - die Einträge für Kundennummer, API-Key und API-Passwort habe ich bereits mehrfach kontrolliert und bin der Ansicht, diese sollten soweit passen.

Als Fehlermeldung erhalte ich folgendes:

Fatal error: Uncaught Error: Class 'SoapClient' not found in /var/www/ownDynDNS/src/Soap.php:40
Stack trace:
#0 /var/www/ownDynDNS/src/Soap.php(130): netcup\DNS\API\Soap\DomainWebserviceSoapClient::_Call('login', Array)
#1 /var/www/ownDynDNS/src/Handler.php(104): netcup\DNS\API\Soap\DomainWebserviceSoapClient->login('xxxxx', 'xxxxxxxxxxxxxxx...', 'xxxxxxxxxxxxxxx...', '68c0ce0b77cecac...')
#2 /var/www/ownDynDNS/update.php(20): netcup\DNS\API\Handler->doRun()
#3 {main}
  thrown in /var/www/ownDynDNS/src/Soap.php on line 40

Hat jemand einen Tipp für mich, wo das Problem liegen könnte?

Hallo KB19 ,

wenn ich den Link "IRC Chat für Kunden von Kunden" aus Deiner Signatur anklicke, gelange ich zu einem (nicht existierenden) Channel #%23nc-kunden. Keine Ahnung, wo das "%23" herkommt.

Hallo @Kraeutergarten,

Zitat von 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).

Auf dem Desktop: Arch Linux wegen der großen Software-Auswahl sowie der Aktualität des Systems.

Auf dem Server: Debian wegen der Stabilität und der konservativen Update-Politik.

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.

@Remsboys: Da ich ein ähnliches Problem hatte, zwei Fragen:

1) Hast Du auf Deinem KVM-Server IPv6 aktiviert?

2) Falls ja: welche Ausgabe ergibt folgendes Kommando?

ip -6 route show

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:

> cat /etc/debian_version
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?

> cat /etc/apt/sources.list
deb http://ftp.de.debian.org/debian/ stretch main
deb-src http://ftp.de.debian.org/debian/ stretch main
deb http://security.debian.org/debian-security stretch/updates main
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:

# /sbin/hdparm -tT --direct /dev/sda3
/dev/sda3:
Timing O_DIRECT cached reads:   3112 MB in  2.00 seconds = 1555.24 MB/sec
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:

# dd if=/dev/zero of=disk.img bs=1024k count=6000
6000+0 records in
6000+0 records out
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:

# /sbin/hdparm -tT --direct /dev/sda3
/dev/sda3:
Timing O_DIRECT cached reads:    24 MB in  2.02 seconds =  11.86 MB/sec
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...?