Naja, dass zunächst Standardfälle abgefragt werden, ist ja normal und oftmals auch nötig. Sollte nach ein bisschen her dann aber hoffentlich zum Ziel führen. ![]()
Hast du dich ausgehend vom VPS aus denn mal woanders erfolgreich per SSH verbinden können?
Naja, dass zunächst Standardfälle abgefragt werden, ist ja normal und oftmals auch nötig. Sollte nach ein bisschen her dann aber hoffentlich zum Ziel führen. ![]()
Hast du dich ausgehend vom VPS aus denn mal woanders erfolgreich per SSH verbinden können?
Ab und an wird hier seitens Netcup kommentiert, aber letztendlich in fast allen Fällen das Öffnen eines Tickets empfohlen. Daher kürze das ruhig ab und öffne direkt eins mit Verweis auf diesen Thread. ![]()
Bin gespannt was des Rätsels Lösung sein wird.
die IP für die SSH Verbindung zu benutzen
Also auch wenn das die Empfehlung sein mag (wieso auch immer), kann ich zumindest bestätigen, dass es auch mit dem Hostnamen - zumindest in meinem Fall - einwandfrei klappt:
Hier mal ne debug-Ausgabe (wie gesagt, mit Passwort.. keys hab ich nur auf meinen Servern hinterlegt):
[12:32]<user>@v2:~$ ssh -v hosting123456@hosting123456.a2xyz.netcup.net
OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d 10 Sep 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to hosting123456.a2xyz.netcup.net [188.68.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /home/<user>/.ssh/id_rsa type -1
debug1: identity file /home/<user>/.ssh/id_rsa-cert type -1
debug1: identity file /home/<user>/.ssh/id_dsa type -1
debug1: identity file /home/<user>/.ssh/id_dsa-cert type -1
debug1: identity file /home/<user>/.ssh/id_ecdsa type -1
debug1: identity file /home/<user>/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/<user>/.ssh/id_ed25519 type -1
debug1: identity file /home/<user>/.ssh/id_ed25519-cert type -1
debug1: identity file /home/<user>/.ssh/id_xmss type -1
debug1: identity file /home/<user>/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9p1 Debian-10+deb10u2
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Debian-10+deb9u7
debug1: match: OpenSSH_7.4p1 Debian-10+deb9u7 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
debug1: Authenticating to hosting123456.a2xyz.netcup.net:22 as 'hosting123456'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:PVi6ADv+dpbaQ6DMC1oAYjpXT81crehDepe4MvB4ONE
debug1: Host 'hosting123456.a2xyz.netcup.net' is known and matches the ECDSA host key.
debug1: Found key in /home/<user>/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: Will attempt key: /home/<user>/.ssh/id_rsa
debug1: Will attempt key: /home/<user>/.ssh/id_dsa
debug1: Will attempt key: /home/<user>/.ssh/id_ecdsa
debug1: Will attempt key: /home/<user>/.ssh/id_ed25519
debug1: Will attempt key: /home/<user>/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/<user>/.ssh/id_rsa
debug1: Trying private key: /home/<user>/.ssh/id_dsa
debug1: Trying private key: /home/<user>/.ssh/id_ecdsa
debug1: Trying private key: /home/<user>/.ssh/id_ed25519
debug1: Trying private key: /home/<user>/.ssh/id_xmss
debug1: Next authentication method: password
hosting123456@hosting123456.a2xyz.netcup.net's password:
debug1: Authentication succeeded (password).
Authenticated to hosting123456.a2xyz.netcup.net ([188.68.xxx.xxx]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Sending environment.
debug1: Sending env LANG = de_DE.UTF-8
Linux a2xyz 4.9.0-12-amd64 #1 SMP Debian 4.9.210-1+deb9u1 (2020-06-07) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Mar 24 22:00:33 2021 from 87.173.xxx.xxx
bash-4.4$
Alles anzeigen
Warum es allerdings bei Felix scheitert, weiß ich leider auch nicht. ![]()
Kann ich bestätigen. Nach bisschen Hin- und Hergeklicke keine Cookies:
Wie genau machst du deine Cookies denn aus? Ggf. mal mit Bildern belegen. Vielleicht kommen wir der Quelle ja gemeinsam auf die Spur. ![]()
Sind die IPs von VPS gesperrt und ich komme nur mit externen IPs auf meinen Webhost?
Grundsätzlich eher nicht. Hab's eben getestet von einem VPS auf ein Webhosting (Password) - klappte anstandslos.
Ich würde so vorgehen:
beiden Domains vollständig voneinander unabhängige Stammverzeichnisse zuordnen (zb /webseiten/webseite1/ und /webseiten/webseite2/), zwei Datenbanken erstellen und dann Wordpress schlicht über das offizielle Setup einmal in Verzeichnis 1 mit Datenbank 1 und einmal in Verzeichnis 2 mit Datenbank 2 installieren. Fertig.
Könnte womöglich auch mit diesen automatischen Anwendungsinstallern im WCP klappen, aber hier im Forum liest man dazu ja des öfteren Probleme. Womöglich greift der eine oder andere Automatismus zu sehr ein, wer weiß.
Edit:
ohne irgendetwas zu schrotten?
So oder so sollte man natürlich immer ein Backup seiner Webseite haben. Schiefgehen kann immer mal was (Technik, Mensch, etc... gibt viele Fehlerquellen ^^)
Kann ich so nicht bestätigen, aber wie bereits angedeutet, nutze ich auch nicht die DNS Server der Telekom.
In der kurzen Zeit nach unserem Umzug (ca. ein Monat) bis das piHole-Setup wieder aufgebaut war, fiel mir aber auch nichts negatives auf. Aber dafür war der Zeitraum sicher auch zu kurz.
So oder so kann man ja, wenn man denn möchtre, sich dahingehend auch ein unabhängiges Setup aufbauen. In meinem Fall ist's ein piHole (in einem LXD Container) und ich bin sehr zufrieden.:)
Ich empfehle immer wieder gern einen eigenen piHole (o.ä.) mit vernünftigen upstream DNS-Servern beispielsweise von Digitalcourage im eigenen Netz. Auf die Vodafone-Dinger würde ich mich wirklich nicht verlassen wollen. ![]()
Ich habe Freunde gefragt und dort kommt es auch zum Fehler.
Sind diese Freunde zufällig ebenfalls bei Vodafone? Wäre nicht das erste mal, dass deren DNS Server einen Schluckauf haben.
Hier aus dem Telekom-Netz (und vom Netcup Server) ist deine Nextcloud jedenfalls einwandfrei erreichbar.
Edit: und nicht nur von mir aus ist deine Seite prima erreichbar, siehe:
Von einem allgemeinen DNS-Problem kannst du also getrost absehen.
Also bei mir klappt die DNS Auflösung problemlos.
Zuhause:
> nslookup cloud.popovic.io
Server: UnKnown
Address: fd00::10:10:10:50
Nicht autorisierende Antwort:
Name: cloud.popovic.io
Address: 5.45.108.74
NC Server:
$ dig cloud.popovic.io
; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> cloud.popovic.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 488
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 7
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cloud.popovic.io. IN A
;; ANSWER SECTION:
cloud.popovic.io. 3268 IN A 5.45.108.74
Alles anzeigen
Mobil klappt es ebenfalls. Daher: kannst es mal bei dir mit dem Handy (ohne WLAN) gegenprüfen?
Ohnehin wirft deine DNS-Abfrage ja bereits einen Fehler:
;; Got SERVFAIL reply from 192.168.0.1, trying next server
;; Got SERVFAIL reply from 2a02:908:2:b::1, trying next server
Würde also genau dort mal ansetzen und auf Fehlersuche gehen. ![]()
Edit: zu langsam... wieso müsst ihr kurz vor mir antworten? ![]()
![]()
wird sich damit dann irgendwas ändern?
Leider nein. Meins wurde bereits umgestellt:
Also im Grunde nur Passwort, Weiterleitung und Autoresponder. Die Aliase lassen sich dort leider nicht anlegen, nur anzeigen. Zumindest wenn die Aliase noch verwaltbar wären, würde das im Grunde für den Endverbraucher meiner Meinung nach ausreichen - oder welche Funktion fehlt dir noch?
Ich kann die jetzige Umsetzung aber durchaus verstehen. I.d.R. hat ein Mail-User eben nur Zugriff auf seine Mailbox, nicht auf die komplette Domain oder gar Speicherplatzmengen. Das obliegt dann schon eher dem Anbieter oder eben Webhosting-Inhaber. Ohne Reseller-Funktionen oder eigenen Mailserver wirst du glaube dein Ziel leider nicht erreichen können.
netcup-Hostings keine weiteren MX-Records/Mailserver neben den eigenen vertragen
Stimmt. Hat tab hier ausgiebig getestet.
Ist aber auch ein Konstrukt, das ich mir selbst nicht unbedingt antun würde. ![]()
christianr Wie bereits erwähnt, jeder Mailbox-User kann seine eigene Mailbox im groben selbst verwalten, sofern der Zugang erlaubt ist. (natürlich nur Dinge wie Password, Autoresponder etc, keine fundamentalen Dinge wie Speicherplatz ändern). Wenn dir das nicht ausreicht, könntest du auch mal über ein Reseller-Paket nachdenken (aber hier bin ich über die Möglichkeiten nicht im Bilde, dazu könnten andere hier sicher mehr sagen) oder Plesk/Mailcow/wasauchimmer womöglich komplett selbst hosten. Aber ein eigener Mailserver kann schon gut mit Arbeit verbunden sein, wenn man da beispielsweise an die Schikanen seitens Microsoft & Co denkt.
Edit: christianr Doch doch, das geht. Siehe beispielsweise hier - Login in die Mailverwaltung für den User.
Kann ich bestätigen. Ich meine zudem auch, dass das vor dem Update auf das neue Plesk Obsidian noch möglich war... ![]()
Jetzt aber kann man es zwar aktivieren:
Aber dann nicht mehr deaktivieren ![]()
Ist jetzt nicht wirklich optimal....
Hat das schon jemand dem Support gemeldet?
Betrifft bei mir übrigens Node a2fc4.
Dafür hat es aber einen schöneren Namen!
Dem einen oder anderen mag das durchaus 29 Cents wert sein! ![]()
Jap, es entspricht 1:1 meinem Webhosting 2000 Adv 19, ist aber 29Cents teurer. ![]()
Ansonsten kein Kracher, aber ein nettes kleines Paket.
Wobei die rote Fehlermeldung schon eher Richtung Plesk/WCP hindeutet. Die kenne ich so gar nicht und kann sie auch nicht mit fehlerhaften Pfaden erzwingen. Würde mich also nicht überraschen, wenn das ein Fall für den Support wäre.
Man könnte jetzt auch nochmal mit den anderen Cronjob-Typen (URL, Befehl) gegentesten, ob es da ebenfalls zu Fehlern kommt.
Edit: Aber ja, die Standarddomain würde ich auch zuvor nochmal prüfen. Wurde aber bereits mehrfach erwähnt, dass diese aktiv sein muss. ![]()
cltrmx Ich gehe mal anhand seines anderen Beitrags von einem Webhosting aus. ![]()
ipaschalis Ein Webhosting-Server kannst du als Endkunde natürlich nicht einfach rebooten - das würde ja alle anderen Kunden auf demselben Server ebenso betreffen, nicht auszumalen was dann los ist. ![]()
Wie genau hast du denn den Cronjob angelegt? Im WCP? Dann gerne mit einem Screenshot zeigen, damit wir mal drübergucken können. Klappt das manuelle Ausführen des Cronjobs noch?
Hast du sonst etwas in den letzten Tagen geändert, das ggf. darauf Einfluss haben könnte? (Einstellungen im WCP geändert.. zb die Hostingdomain deaktiviert? Dann gehen Cronjobs beispielsweise nicht mehr automatisch)
Ist in den Logdateien etwas zu erkennen?
Also ab und zu sieht man ja ganz kurz im netcup-status, welche Server derzeit aktualisiert werden. Aber die verschwinden leider dann auch sofort wieder nach Abschluss der Arbeiten. Falls so eine Info nicht öffentlich ausgestellt werden soll, wäre zumindest eine Mailbenachrichtigung wünschenswert.
Ich kann nur so viel sagen: meine Node wurde bereits aktualisiert. ![]()
Eine Info vorher gab es nicht, aber von den Arbeiten selbst habe ich auch nichts mitbekommen. Scheint alles zu laufen. Wäre jedoch etwas schief gegangen, hätte ich davon wenig mitbekommen, da ich ohne konkrete Ankündigung nicht zeitnah testen konnte.
Das beste, was dem geschehen ist, ist das der Support abgelaufen ist
Ein Windows ohne Updates..joa, das beste was Hackern passieren kann.
Da wird nicht über die Tage hinweg unnötig immer mehr Speicher verwendet
Schau dir mal dazu den Speicherverbrauch eines headless Linux an. Dann weißte wie viel "unnötigen" Speicher man mit einem vernünftigen Server-OS sparen kann. ![]()
Puh, ein Windows Client jahrelang ohne Updates am Netz, vermutlich auch ohne weitere Sicherheitsvorkehrungen... da läuft's mir eiskalt den Rücken runter, sorry.
Aber ich denke es lag an mir.
Oder an den Nachwirkungen eines Sixpacks? ![]()
![]()