Beiträge von SebWei

Für den Umzug habe ich bei kleineren Postfächern immer Drag&Drop im Thunderbrid genutzt. Für größere Umzüge habe ich mit imapsync sehr gute Erfahrungen gemacht. Der Source-Code ist frei verfügbar (https://github.com/imapsync/imapsync), sodass du es auch gratis nutzen kannst (mit dem Zusatzaufwand von kompilieren, make und co)

Danke codesight für die Nachfragen beim Support und das Teilen der Antworten. Das erspart mir eine Anfrage. Ich habe mich nämlich in den letzten Wochen auch vermehrt über die fehlerhaften Spam-Markierungen gewundert, obwohl ich alle Spam-Filter im CCP/Plesk bewusst deaktiviert hatte.

Gegen den Einsatz von Blacklisting und Greylisting habe ich ja nichts. Aber diese "neue Schicht der Spam-Filterung" bringt nur Ärger.

Von ca. 1000 Mails in den letzten Wochen wurden rund 10 als Spam markiert, alles Fehlalarme. Tatsächlich habe ich 0 Spam Mails in diesem Zeitraum bekommen.

Ich habe das Glück auf meinen eigenen .de Domains extrem wenig Spam-Nachrichten zu bekommen, weshalb ich dort tatäschlich nie Spam-Filter aktiviert habe (weder auf dem Server, noch im Client). Dass Netcup diese Einstellung jetzt als "Service" einfach ignoriert, finde ich nicht akzeptabel!

Achja: Da der Support es ja unter anderem mit ungefilterten Weiterleitungen begründet: Ich nutze keine externen Weiterleitungen, sondern nur Aliase und Weiterleitungen im selben Webhosting Paket.

Ich habe gerade, zum ersten Mal, exakt dieselbe Fehlermeldung bekommen. Ich habe ebenfalls versucht mit einer nicht dem Hostingpaket zugeordneten Mail-Adresse zu senden. Die andere Domain gehört mir, SPF Einträge sind auch korrekt, SMTP Auth in Thunderbird aktiv. Ich sehe keinen Grund, warum das geblockt werden sollte. In den letzten Jahren hat es mit derselben Domain und demselben Mailserver nie Probleme gegeben.

Also: Was wurde geändert? War das ein Fehler? Was kann ich machen, dass die vorherige Funktionalität wieder kommt?

So, ich möchte euch mein Feedback natürlich nicht schuldig bleiben. Nachdem ich es am Wochenende nicht mehr lösen konnte, hatte ich keine Zeit mehr mich drum zu kümmern. Ich habe also NICHTS GEÄNDERT.

Seit Mittwoch morgen (also zwischen 48 und 72 Stunden nach der Änderung) liefert der Webserver das richtige Zertifikat aus. Warum? Ich habe keine Ahnung

DNS ist natürlich inzwischen auch auf dem Webserver korrekt.

Zitat von CmdrXay

Die eine Hälfte iv6 hast Du ja schon....z.B. lässt sich wget auf ipv4 zwingen. curl auch, mit -ipv4 als parameter.

Wäre mal interessant zu sehen, was curl so ausgibt...

Danke für die Befehle. Dort bekomme ich tatsächlich auf einzelnen Domains noch die alte IP. Auf diesen Domains wird auch korrekterweise noch das alte LE Zertifikat ausgeliefert vom Server. Auf den ganz neuen Domains kommt aber der korrekte Server und das Plesk self-signed Zertifikat

Hier mal ein Screenshot von der URL für die Nextcloud Instanz (leitet auf die alte Instanz weiter, mit HTTP 503 wegen Wartungsmodus):

Nextcloud alt.PNG

Und zum Vergleich die neue Domain (mit neuer IP):

Neue Domain.PNG

curl von meinem PC aus ergibt etwas ähnliches, aber eben auch auf der Nextcloud Instanz:

Nextcloud Neu.PNG

Edit: Vor lauter Screenshots meine letzte offene Frage vergessen:

Wie kann es denn sein, dass der Webserver offensichtlich alles richtig ausliefert, aber das falsche Zertifikat nimmt? DNS hin oder her. Es kommt ja der korrekte Content (per HTTP). Nach meinem Verständnis macht das alles der Nginx auf der .132 oder etwa nicht?

Danke für die Hinweise. Da geht uns wohl ähnlich mit der Ungeduld

Danke auch für die Erfahrungen, dass die Änderung bei Netcup selbst wohl am längsten dauert.

Leider kann ich in der SSH chroot weder dig, noch ping oder sonst was nützliches finden, womit ich das testen kann. Auch openssl fehlt leider.

Ein curl https://domain.tld -v liefert wenigstens die Info, dass die korrekte IPv6 Adresse geladen wird, aber auch dort kommt ein self signed certificate.

Aber gut. Ich habe alles auf dem neuen Webspace fertig konfiguriert. Außer den Zertifikatswarnungen funktionieren auch alle Clients (Nextcloud und Co) wieder einwandfrei. Ich werde mich dann also zurücklehnen und auf morgen oder übermorgen warten.

P.S.: Es ist einfach frustrierend, dass die einzige Lösung "bitte warten" ist

Den Support hätte ich dafür aber auch nicht voreilig bemüht.

Ich möchte hier nochmal nachhaken, da ich vor demselben Problem stehe und "einfach warten" mich nicht zufrieden stellt.

Auch glaube ich irgendwie nicht, dass es am DNS liegt. Ich vermute eher, dass irgendein "Trigger" im Plesk noch fehlt oder ein Cronjob noch nicht gelaufen ist.

Ich habe heute gegen 11:30 Uhr eine Domain von meinem alten Webhosting auf das neue Webhosting umgezogen. Mit /flushdns, Reboot der Fritzbox usw. konnte ich schon ab 12:00 Uhr den neuen Webspace erreichen und alles konfigurieren. Alle Zugriffe per HTTP funktionieren problemlos. nslookup liefert ebenfalls korrekte Ergebnisse zurück.

Auch Let's Encrypt hat vollkommen problemlos funktioniert (an deren DNS kann es also auch nicht liegen). Es wurde ein korrektes Zertifikat beantragt und im Plesk hinterlegt. Auch ist jeweils genau das richtige Zertifikat für die betroffenen Domains / Subdomains im Plesk hinterlegt. Ich habe sogar den Text, der im Plesk als *.crt angezeigt wird, in eine Datei gegeben und mir von Windows interpretieren lassen. Ergebnis: Alles korrekt, zertifiziert von LE, DNS der Subdomain hinterlegt.

Kurzum: Es ist alles da, HTTP läuft problemlos, nur mag der Webserver irgendwie nicht das im Plesk korrekt definierte SSL Zertifikat ausliefern.

So. Und jetzt wird es komisch.

Ich hatte gestern um 20:00 Uhr eine weitere Domain dem Webhosting zugewiesen. Gegen 01:30 Uhr habe ich für diese Domain im Plesk zwei Subdomains zum Testen angelegt. Auf beiden Domains hatte ich direkt beim Anlegen LE beantragt.

Für diese Subdomains hat alles (HTTP und HTTPS) sofort funktioniert. Die Hauptdomain hatte ich unangetastet gelassen.

Jetzt habe ich zum Test für diese weitere Domain selbst, auch ein LE Zertifikat beantragt. Und das Ergebnis? Der gleiche Mist wie mit der umgezogenen Domain. Dabei hat es für die Subdomains doch bereits funktioniert!?

Auch das Verfahren von gestern (also Test Subdomain für diese weitere Domain) habe ich gerade wiederholt. Ebenfalls wird nur das Default-Zertifikat ausgeliefert. HTTP geht wie immer, komplett problemlos, weshalb ich DNS ausschließe.`

Ich vermute, dass gestern irgendwas zwischen 20:00 und 01:30 Uhr passiert ist. Aber was?

Die Frage ist also: Wie bringe ich den Webserver dazu, endlich meine Einstellungen aus dem Plesk anzuerkennen? Muss ich etwa wieder bis 01:30 Uhr warten?

Funktioniert die Methode denn bei dir?

Zitat von killerbees19

Der Aufruf über HTTP und SSH gibt wirklich immer den gleichen Pfad aus?

PHP

<?php printf("%s\n", __dir__);

Das war nämlich bisher nicht so beim Webhosting. Deshalb wundert mich das etwas...

Ah vielen Dank. Da bekomme ich tatsächlich eine andere Ausgabe jetzt. Bei dem vorherigen Befehl mittels echo hatte ich natürlich auf der Konsole keine Ausgabe und hatte mir das Ergebnis wohl falsch gemerkt.

Ergebnis jetzt:

Aufruf per HTTP(S): /var/www/vhosts/hostingXXXXXXXXXX.aXXXX.netcup.net/httpdocs/rss

Aufruf per SSH: /httpdocs/rss

Wenn Plesk also im chroot ist, sollte dort auch der kürzere Pfad funktionieren Eigentlich logisch, denn genau so kann ich per SSH die Skripte ja auch aufrufen.

Zitat von netzroot

Hast Du auch mal die Option "Befehl" ausprobiert?

Habe ich. Der Befehl funktioniert exakt so auch auf der Konsole.

Er wird aber nicht gemäß Cron ausgeführt. Mit einem anderen Test-Skript, das eine Status-Datei schreiben soll, habe ich auch die dritte Option "URL aufrufen" getestet. Das Skript gibt über keine der drei Optionen eine Rückmeldung und die Datei wird auch nicht geschrieben

Wie gesagt: Klicke ich im Plesk Onyx auf "Jetzt ausführen" klicke, klappt ja auch alles.

Mein Anliegen hier im Forum war, einen simplen Fehler meinerseits auszuschließen und vielleicht einen oder zwei andere User zu finden, die Crons im neuen WCP nutzen. Offensichtlich bin ich da aber doch (fast) alleine und einen offensichtlichen Fehler finde ich jetzt auch nicht Danke für euren Input. Damit bin ich mir zumindest sicher, dass meine Befehle korrekt sein müssen.

Sobald ich während der Support-Zeiten mal dazu komme, werde ich den Support anrufen oder per Mail anschreiben.

Mit absolutem Pfad wird das Script gar nicht ausgeführt. Weder manuell und eben auch nicht automatisch. Der Pfad von dem o.g. Script ist auch immer identisch. Egal wie ich das Script aufrufe.

Ja, der absolute Pfad ist wirklich kein Problem

Daran liegt es auch sicher nicht, denn das habe ich jetzt mit einem kleinen Test-Script getestet. Auch dieses wird weder mit relativem, noch dem absoluten Pfad aufgerufen.

Ich habe auch die Methode getestet, direkt einen Befehl aufzurufen. Hier darf ich in der Tat sogar gar nicht die absoluten Pfade eingeben, sonst gibt es auch bei der manuellen Ausführung einen Fehler. Da wird offenbar alles in einer chroot Umgebung ausgeführt.

Auch ein simpler URL-Abruf funktioniert nicht.

Manuell läuft das alles, aber nicht automatisch. Mail-Benachrichtigungen gibt es auch nie.

Ich glaube langsam, dass bei mir crond gar nicht läuft

Danke für die Info. Die Probleme mit absoluten Pfaden bei crontab kenne ich. Leider sind mir die absoluten Pfade auf dem Shared Hosting gar nicht bekannt. Zugriff auf crontab habe ich verständlicherweise auch nicht.

Deshalb habe ich mich ja zu 100% an die Plesk-GUI gehalten und den Pfad mit dem eingeblendeten Dateimanager gewählt. Auch passt der Pfad voll zu dem gegebenen Code-Beispiel und eine manuelle Ausführung inkl. Status im WCP funktioniert ebenfalls. Wenn hier also ein Fehler vorliegt, ist das ein Bug des WCP.

Was mich am meisten stutzig macht, sind die fehlenden Rückmeldungen. Weder im WCP, noch per Mail erhalte ich Infos, dass der Cron ausgeführt wurde. Eine fehlerhafte Einstellung sollte ja ebenso eine Mail auslösen, wie eine korrekte Einstellung.

Bin ich denn wirklich der einzige User des neuen WCP, der cronjobs braucht?

Hallo zusammen,

nach der von mir selbst angestoßenen Soft-Migration auf ein Webhosting 2000 habe ich auch direkt noch einen neuen Dienst auf meinem Webspace installieren wollen: Tiny Tiny RSS.

Damit die RSS-Feeds regelmäßig geladen werden, muss man natürlich einen Cronjob einrichten (https://git.tt-rss.org/fox/tt-rss/wiki/UpdatingFeeds). Das habe ich wie folgt gemacht:

pasted-from-clipboard.png

Leider wird der Cronjob nie automatisch ausgeführt (E-Mail-Benachrichtigung kam auch noch keine einzige). Klicke ich auf "Jetzt ausführen" wird die RSS-Datenbank aber sofort aktualisiert. Am Befehl sollte es also nicht liegen.

Ich scheine auch nicht der einzige mit dem Problem zu sein: https://forum.netcup.de/anwend…lux-rss-dienst/#post90378

Funktioniert das bei irgendjemandem? Liegt es an meinem Host? Habe ich doch einen Fehler im Aufruf?

Ich habe auf meinem SoGo Paket hier auch mal Wildcards probiert, aber ein ganz anderes Verhalten bekommen.

Eingerichtet habe ich:
Postfach:
postfach1@domain.de

Alias:
post.*@domain.de

Wenn ich jetzt eine Mail sende bekomme ich immer Fehlermeldungen im Mail-Client bzw. ein "Mail returned to sender".
z.B.: 5.1.1 <post.@domain.de>: Recipient address rejected: User unknown in virtual mailbox table.

Interessanterweise kommt eine Mail an post.*@domain.de an

Generell bin ich noch etwas verwirrt, weil ich nirgends einen Hinweis finden konnte ob und wie Wildcards überhaupt unterstützt werden. Ich hatte auf Grund dieses Threads einfach mal angenommen, dass es mit * geht.

Hi zusammen,

ich möchte auch Outlook mit SOGo nutzen, aber auf externe Tools verzichten. Mit Outlook 2013 oder 2016 funktioniert dies auch recht gut, wenn man mal die Konfiguration geschafft hat

Das Problem ist nämlich, dass Outlook am Ende der Konfiguration die Verbindung zum Server verweigert. Die Lösung habe ich dort gefunden: Outlook 2013 mit ActiveSync über Z-Push nutzen :: blog.bartlweb
Also einfach Outlook am Ende der Konfiguration abschießen und danach EAS nutzen Aktuell scheint alles gut zu laufen!

Edit: Meine Euphorie wurde etwas gedämpft. Auf den ersten Blick geht viel, aber eben nicht alles. Schuld ist wohl Z-Push. Was genau nicht geht, wurde von einem anderen Hoster in einem Kommentar ganz gut zusammengefasst: Zarafa verlängert auslaufenden Outlook-Support nun bis 2017 - ETES GmbH