Aber wie ASS bereits erwähnt hat geht beim Transfer ab und an etwas schief, daher würde ich das zu normalen Supportzeiten durchführen.
Daher auch der Hinweis so etwas ggf. nicht an einem Feiertag oder Wochenende zu tun 😉
Aber wie ASS bereits erwähnt hat geht beim Transfer ab und an etwas schief, daher würde ich das zu normalen Supportzeiten durchführen.
Daher auch der Hinweis so etwas ggf. nicht an einem Feiertag oder Wochenende zu tun 😉
Auch ohne Backup MX geht in der Regel nichts verloren, wenn du beim bisherigen Anbieter in der Lage bist den MX zu deaktivieren oder im DNS ungültig zu setzen können erstmal keine Mails mehr zugestellt werden.
Der sendende Mailserver versucht es dann später noch einmal.
Aber wie ASS bereits erwähnt hat geht beim Transfer ab und an etwas schief, daher würde ich das zu normalen Supportzeiten durchführen.
Absicherungsmaßnahmen hängen auch immer davon ab ob es sich um geschäftliche Konten oder private handelt
Schwierig,
was funktionieren könnte ist die Domains als externe Domains einzubinden, dann die Mailboxen einrichten, etc.
Später dann die Domains zu transferieren (KK).
Einfacher wäre sicher, sofern die bisherigen Mailboxen bei einem Transfer nicht sofort gelöscht werden,
den MX beim bisherigen Anbieter zu deaktivieren (Zustellversuche werden abgelehnt)
Die Domain zu transferieren, die Mailboxen zu kopieren und den MX bei Netcup zu aktivieren.
Während der Downtime des MX geht in solch einem Fall normalerweise nichts verloren (sofern wir nur von ein paar Stunden downtime sprechen).
Was möchtest du denn erreichen.
Der Fehler kommt da kein gültiges LE Zertifikat angefordert werden kann, stattdessen wird dann vermutlich das selbstsignierte Plesk Zertifikat verwendet.
Bei der netcup Domain würde ich den Fehler einfach ignorieren und einfach keinen Inhalt ausliefern.
301 Weiterleitung würde ich aktivieren.
E-Mailschutz schadet auch nicht, wird sich aber vermutlich gar nicht auswirken, da der Mailserver/Webmail separat laufen.
LE für die interne Domain kann ignoriert werden, hier würde ich das Hosting ggf. sogar deaktivieren.
Da es hier um DNS für Exchange geht, gehe ich davon aus, dass es eher um die Business Variante von Office 365 geht. Da braucht man für jeden Nutzer eine Lizenz.
Guter Punkt.
In dem Fall ist wohl für jeden User eine Abo/Lizenz fällig (https://docs.microsoft.com/en-us/microsof…=o365-worldwide)
Mit der Umleitung ist schon einmal sicher gestellt, dass per https auf die Seite zugegriffen wird.
Durch HSTS merkt sich der Browser das auf die Seite beim nächsten mal direkt über https zugegriffen werden soll
https://de.wikipedia.org/wiki/HTTP_Strict_Transport_Security
Bei OCSP (https://de.wikipedia.org/wiki/Online_Ce…Status_Protocol) geht es um Zertifikatssperrlisten, ob die für Let’s Encrypt nun einen Mehrwert bringen würde ich verneinen, schaden kann die Einstellung aber sicher auch nicht.
Habe über den lokalen Pi die .myfritz.net Domain genutzt, entsprechend ist das wie ein Zugriff von außen. In FileZilla geht es auch mit genau der Konfiguration die ich Plesk angegeben habe. Das forwarding übernimmt Fritz soweit ich weiß.
Diese Annahme ist falsch, ein Zugriff über die externe IP aus dem lokalen Netz ist nicht gleichzustellen wie ein wirklicher externer Zugriff.
Die FRITZ!Box sieht ja dass der Zugriff aus dem internen Netz kommt.
Ich fürchte ja, falscher Trip. Das Verzeichnis contao-manager ist absichtlich außerhalb des document root. Wenn open_basedir nicht aktiv ist oder eben das Verzeichnis oberhalb der document root freigibt, ist das kein Problem. Das ganze basiert auf Symfony, da ist die Verzeichnisstruktur üblicherweise so.
Ok, aber dann ist das doch die Ursache für den beschriebenen 500 beim Installer.
Zu Threadstart war doch open basedir auf DOCROOT gestellt und damit wird ein mkdir außerhalb abgestraft.
Nur mal eine grobe Idee, Du schreibst
Dokumentenstamm auf /httpdocs4/web eingestellt
in der Fehlermeldung ist der Pfad dann aber /httpdocs4/contao-manager.
Das ist doch schon ein versuchter Ausbruch aus dem docroot.
/httpdocs4/web/contao-manager müsste hingegen funktionieren.
Oder bin ich da jetzt auch auf dem falschen Trip?
Hallo,
ich kenne mich mit Shopify nicht aus, aber muss das Zertifikat für Deine Domain nicht bei Shopify, bzw. auf deren Server hinterlegt werden?
Ein LE Zertifikat bei Netcup hilft doch nicht, da der Webserver von Netcup doch gar nichts von der Verbindung mitbekommt, deine Domain verweist doch direkt auf die Server von Shopify.
https://help.shopify.com/en/manual/domains/managing-domains/secure-connections
Ich meine ja, der Server prüft nur ob die Adresse konfiguriert wurde.
Im Zweifelsfall einfach mal probieren
Meines Erachtens nach lässt sich das in Plesk nur über Weiterleitungen realisieren (dafür muss auch nicht pro Domain einr Mailbox eingerichtet werden)
Alles anzeigenNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 110.8M 1 loop /snap/core/12725
loop1 7:1 0 61.9M 1 loop /snap/core20/1376
loop2 7:2 0 21.2M 1 loop /snap/bashtop/450
loop3 7:3 0 110.7M 1 loop /snap/core/12821
sda 8:0 0 320G 0 disk
├─sda1 8:1 0 2M 0 part
├─sda2 8:2 0 1G 0 part /boot
└─sda3 8:3 0 159G 0 part /
sr0 11:0 1 1024M 0 rom
Über das Kundenportal.. https://www.customercontrolpanel.de
sda hat 320GB, da musst du wohl noch sda3 mit resize2fs vergrößern, siehe auch https://forum.netcup.de/administration…e2fs#post155948
Patrick0815 zugewiesen ist die Domain automatisch, weil es eine inklusiv-Domain ist.
Wenn die Domain im WCP nicht auftaucht, ist im Hintergrund wohl (mal wieder) etwas schief gegangen.
Wende dich am Besten direkt an den Support.
Dann würde ich den Support mal kontaktieren.
Dem Webhosting zugewiesen ist die Domain aber auch schon?
Ist die Domain denn auch dem Hosting zugewiesen?