Noch eine Info:
Da die IP auf einer Blacklist von Crowdsec ist, kann man die nicht einfach löschen, da diese nach 2h wieder auf der internen Blocklist vom Server ist.
Man muss dann dieser IP vertrauen und da hilft dieser Artikel:
https://docs.crowdsec.net/docs/next/whitelist/create_capi/
Das Problem ist gelöst.
Durch eine Blocklist von Crowdsec war der Webhosting-Server gebannt.
Der Server ist nun auf der Whitelist und sollte damit nicht mehr gebannt werden.
Der Dienst Crowdsec konnte beim Starten des Betriebssystems nicht hochfahren. Ich habe auch keine SSH-Verbindung aufbauen können.
Ich habe dann über die Weboberfläche mich als root angemeldet und nachgeschaut. Komischerweise lief der Dienst doch. Habe Crowdsec neugestartet und dann konnte ich mich wieder über ssh verbinden.
Crowdsec ist eine Alternative zu Fail2Ban. Diese hat sich in den letzten Jahren etabliert.
Ich habe mir gerade das Rettungssystem gestartet und es hat funktioniert.
Jetzt habe ich es deaktiviert und nun komme ich gar nicht mehr ran. Der Crowdsec-Dienst bleibt unten und ssh geht gar nicht.
Ich verstehe das Ganze gerade nicht mehr.
Wenn ich den Server neustarte, dann kann ich für 10 Sekunden in beiden Richtung eine ssh-Session aufbauen, dann nicht mehr.
Aber aus dem Internet, z.B. von mir Zuhause geht es ohne Probleme.
Weiß einer wie ich ein Rollback bei Debian 12 mache?
Folgende Software wurde aktualisiert:
containerd.io:amd64 (1.7.21-1, 1.7.22-1), docker-compose-plugin:amd64 (2.29.2-1~debian.12~bookworm, 2.29.7-1~debian.12~bookworm), docker-ce-cli:amd64 (5:27.2.1-1~debian.12~bookworm, 5:27.3.1-1~debian.12~bookworm), crowdsec-firewall-bouncer-iptables:amd64 (0.0.29, 0.0.31), crowdsec:amd64 (1.6.2, 1.6.3), docker-buildx-plugin:amd64 (0.16.2-1~debian.12~bookworm, 0.17.1-1~debian.12~bookworm), docker-ce:amd64 (5:27.2.1-1~debian.12~bookworm, 5:27.3.1-1~debian.12~bookworm), docker-ce-rootless-extras:amd64 (5:27.2.1-1~debian.12~bookworm, 5:27.3.1-1~debian.12~bookworm)
Ich warte erstmal auf die Antwort vom Support ab.
Danach entscheide ich, ob ich ein Rollback mache.
das ist definitiv falsch.
ich z.b. ziehe unregelmäßig backup-kopien von WHs auf RS oder VPS via rsync oder scp.
Das wage ich mal stark zu bezweifeln.
Das ist nur das was sich vom Support habe. Ich habe vergessen, dass ich mich nur damit auf rsync bezog. Die eigentliche Kommunikation ist möglich.
Ich mache das andersum. Ich sende von meinem root-Server zum Webhosting.
Aber wie schon geschrieben, muss ich aktuell auf eine Antwort vom Support warten, warum die Kommunikation zwischen meinem root-Server und dem Webhosting nicht funktioniert. Danach würde ich es nochmal testen.
Alles anzeigenBei mir klappt die ssh Verbindung zwischen VPS und Webhosting.
Es gehen beide Richtungen.Das Webhosting habe ich im VPS per sshfs eingebunden. Hier wäre auch syncronisieren mit rsync möglich.
Bevor ich auf den gemounteten Webspace zugreife, überprüfe ich ob dieser auch da ist. Das passiert über eine Abfrage ob sich eine bestimmte Datei im Verzeichnis befindet.
Ist auf deiner VPS ein Nameserver in /etc/resolv.conf eingetragen?
Bzw. kannst du vom VPS auch etwas anderes anpingen.
Nicht das es an der Namensauflösung liegt.
Moin,
die Kommunikation zwischen root-Server und Webhosting ist laut dem Support von Netcup nicht möglich.
In der resolv.conf sind 2 Server eingetragen
nameserver 46.38.225.230
nameserver 46.38.252.230Ich kann auch alle Adressen in das Internet auflösen. Google, web.de, facebook, etc.
Ich habe gestern noch dem Support geschrieben und eine Antwort bekommen. Es wird angenommen, dass mein Server auf einer internen Blacklist gelandet sein könnte. Warum, kann ich nicht sagen? Dies wird gerade weiter vom Support überprüft.
Ich habe Docker auf dem root-Server mit Mailcow und Vaultwarden darauf. Die Backups von den Mailcow und Vaultwarden lasse ich in der Nacht über FTP auf das Webhosting legen. Dafür habe ich immer rclone mit dem FTP-Module durchgeführt.
/Edit:
Die Adresse von meiner Domäne für den FTP-Zugang kann ja aufgelöst werden, nur werden keine Pakete angenommen oder gesendet.
Ich würde zunächst einmal ping- und traceroute-Ergebnisse ansehen. (Nutze kein Webhosting, kann also nicht sagen, ob ein Anpingen regelmäßig funktionieren sollte.)
Bei ssh-Tests spielt immer eine Rolle, welche Ciphers usw. auf beiden Seiten erlaubt werden (in der Vergangenheit hatte ich bspw. Probleme, von einem RS ein ISO-Image via (S)FTP(S) für die Verwendung im SCP zu übertragen). Hier hilft es, mit mehreren "-v" die Geschwätzigkeit zu erhöhen, um ggf. Fehlermeldungen besser erfassen zu können und explizit die entsprechenden Einstellungen auf allen Seiten anzeigen zu lassen. Ich bin mir fast sicher, dass sich die SSH-Einstellungen zwischen HomeServer und Netcup-RS an einer Stelle unterscheiden.
Soll es schnell gehen, hilft immer noch die Methode "von hinten durch die Brust ins Auge" über zwei "Sprünge" : Netcup-RS <-> HomeServer <-> Netcup-Webhosting
EDIT: Fürs Protokoll: Bei SSH-Kontaktaufnahmen von exponierten Hosts auf einen HomeServer insbesondere zu Testzwecken würde ich hier zusätzliche Sicherheitsvorkehrungen treffen, beispielsweise die Verwendung eines gesicherten Containers oder einer VM und dedizierte SSH-Schlüssel, die nur an einer Stelle bzw. für die vorgenannten Tests verwendet werden.
Die Lösung über den HomeServer finde ich nicht gut. Deshalb lasse ich es und warte ab.
Danke trotzdem für den Lösungsansatz.
Ich habe die Ciphers auf dem Netcup-root-Server angepasst. Nach einem Best Practice.
Das Problem sehe ich nicht an den Ciphers. Das Probleme sehe ich aktuell beim Routing. Wenn ich eine SSH-Verbindung zwischen den Netcup-Produkten aufbauen möchte, dann geht es nicht. Gleiches Problem mit FTP von Netcup-root-Server zu Netcup-Webhosting. (Hatte ich ja mit rclone benutzt). Habe einen weiteren Test mit dem ftp-CMD ausprobiert., geht auch nicht.
Andersrum kann ich das nicht testen, da ich auf dem Netcup-root-Server kein FTP möchte und auch brauche.
Ich mache mal ein Ticket beim Support auf, mit meinen ganzen Informationen die ich herausgefunden habe.
ufw ist es doch nicht, das funktioniert.
Habe nun mal die SSH-Verbindungen getestet.
Ich habe bei mir zuhause von einen meiner Server den SSH-Port ins Internet freigegeben (Habe ich schon wieder geschlossen)
Ich habe nun ein paar SSH-Verbindungen getestet. Folgendes habe ich getestet
HomeServer zu Netcup-Webhosting --> funktioniert
Netcup-Webhosting zu HomeServer --> funktioniert
HomeServer zu Netcup-root-Server --> funktioniert
Netcup-root-Server zu HomeServer --> funktioniert
Netcup-root-Server zu Netcup-Webhosting --> funktioniert nicht
Netcup-Webhosting zu Netcup-root-Server --> funktioniert nicht
Wie schon gesagt, bis zum 20.10.2024 hat es funktioniert. Nun bekomme ich keine FTP und SSH-Verbindung zwischen den Netcup-Produkten.
Ich denke, da gibt es aktuell Routing-Probleme zwischen dem Webhosting und den root-Servern.
Oder sehe ich das gerade völlig falsch?
/edit:
Traceroute von meinen HomeServer zum Netcup-Webhosting kann ich ohne Probleme auflösen.
Traceroute von meinem Netcup-root-Server zum Netcup-Webhosting läuft ins leere. Wenn ich z.B. google.de verfolge kann dies aufgelöst werden.
Ich denke, das Problem liegt nicht an rclone. Ich glaube der Server hat ein Problem.
Ich kann keine normale ssh-Verbindung zum Webhosting aufbauen oder mit scp (was ja das gleiche Protokoll ist).
Das muss ich mir erstmal in ruhe anschauen, bevor ich das Thema rsync angehe.
Leider hat das Webhosting kein rsync.
Muss ich leider auf scp wechseln.
Danke, schaue ich mir morgen an. Heute ist Feierabend. 😅
Das ist ja das Problem. Die letzte Version die installiert wurde, war vor einem Monat.
Ich denke das Problem besteht auch in den anderen Versionen.
Mit rsync habe ich mir gerade mal angeschaut. Das ist eine gute alternative, aber leider kann ich im Webhosting von Netcup kein Private\Public-Key-Verfahren einrichten und ein Passwort kann ich nicht hinterlegen.
Moin,
ich habe für meine Backups für Vaultwarden und Mailcow rclone eingerichtet.
Es werden die Backups erstellt, gezippt und dann noch mnit gpg verschlüsselt. Danach wird mit rclone über FTP die Daten mein Webhosting bei Netcup kopiert.
Seit heute funktioniert es gar nicht mehr.
Folgende Fehlermeldung bekomme ich:
024/10/21 17:19:54 DEBUG : Creating backend with remote "SourceFolder"
2024/10/21 17:19:54 DEBUG : Using config file from "/root/.config/rclone/rclone.conf"
2024/10/21 17:19:54 DEBUG : Creating backend with remote "Destination:"
2024/10/21 17:19:54 DEBUG : ftp://server.net:21: Connecting to FTP server
2024/10/21 17:19:54 DEBUG : ftp://server.net:21: dial("tcp","server.net:21")
2024/10/21 17:20:54 DEBUG : ftp://server.net:21: > dial: conn=<nil>, err=dial tcp IP:21: i/o timeout
2024/10/21 17:20:54 DEBUG : pacer: low level retry 1/10 (error dial tcp IP:21: i/o timeout)
2024/10/21 17:20:54 DEBUG : pacer: Rate limited, increasing sleep to 20ms
2024/10/21 17:20:54 DEBUG : ftp://server.net:21: dial("tcp","server.net:21")
Leider wird keine Verbindung mehr zu FTP-Server aufgebaut, benutze ich einen FTP-Client funktioniert es super.
Gestern habe ich auf dem Server Updates installiert, aber da gab es nur ein paar Update für Crowdsec und Docker, mehr nicht.
Ich wollte daher fragen, ob einer von euch das gleiche Problem schonmal hatte?
Bei github habe ich auch folgendes Issue gefunden, aber dazu gibt es keine Lösung.
https://github.com/rclone/rclone/issues/7022
Schönen Gruß,
Robert
Ja, ist halt nur diese nervige Warnmeldung.
Ich denke, ich werde auf mein root-Server nextcloud als AIO im Docker installieren. Dann sollte alles optimal laufen.
Trotzdem danke.
Hat leider beides nicht geholfen, habe immernoch die Meldung:
Es wurde kein Speichercache konfiguriert. Um die Leistung zu verbessern, konfiguriere bitte Memcache, sofern verfügbar. Weitere Informationen findest du in der Dokumentation/Edit:
Mach etwas recherchieren habe ich wohl den falschen Ansatz
Ich denke, es geht um das Thema:
https://docs.nextcloud.com/server/29/admi…figuration.html
Der Memcache muss noch eingerichtet werden. Ich habe schon in der config.php folgende Zeile hinzugefügt:
'memcache.local' => '\OC\Memcache\APCu',Leider führt das dazu, dass die Seite nicht erreichbar wird.
In der Logdateien kommen keine Fehler mehr wegen dem OPCache.
Moin,
ich ziehe aktuell mein Webhosting um und habe heute eine neue Nextcloud-Instanz installiert.
In der Administration habe ich folgenden HInweis:
Es wurde kein Speichercache konfiguriert. Um die Leistung zu verbessern, konfiguriere bitte Memcache, sofern verfügbar. Weitere Informationen findest du in der DokumentationIn den Logs habe ich folgenden Eintrag:
Zend OPcache can't be temporary enabled (it may be only disabled till the end of request) at Unknown#0In meinem Webspace ist der OPCache aktiviert.
In der Datei .user.ini habe ich noch folgende Optionen eingetragen:
opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1Leider wird der OPCache trotzdem nicht aktiviert. Kann mir einer sagen, was ich noch machen soll, damit der OPCache von Nextcloud verwendet wird?
Danke im Voraus,
Robert
Wie lange dauert es, das ein WebHosting-Paket zu dem Account dazu gebucht wird?
Ich würde gerne heute noch ein paar Domains umziehen, da einige Domainendungen, die ich benutze im Angebot sind.