Darüber hinaus ist das Webhosting mit zwei inkl. Domains wohl auch günstiger als zwei separate Domains.
Sehr wahrscheinlich 
, zumal es derzeit keine Domainaktion gibt und außerdem würde der Support da wohl auch nicht mit sich reden lassen von wegen Inklusivdomain umwandeln in zusätzliche Domain zum Aktionstarif.
Das wurde aber in der Vergangenheit nicht immer logisch behandelt seitens netcup. Ich glaub sogar es war der identische Dall, Inklusiv- zu Zusatzdomain, was zumindest noch zusätzliche Gebühren gekostet hätte, sogar obwohl ich bereit war, dafür auf den freigewordenen Inklusivplatz zu verzichten. Verstanden habe ich das nie, aber es akzeptiert und meine Konsequenzen daraus gezogen.
Umfangreicher IT-Service wollte (und sollte!) schon immer entsprechend bezahlt werden.
In der Sache stimme ich dir natürlich voll zu...
Aber das liest sich für mich unter https://www.netcup.de/ueber-netcup/ unter "Unser Qualitätsanspruch" Punkt 6, "Kompetenter Support", doch anders.Ok, RTFM ist auch kompetenter Support, immer noch besser als fehlerhafte Tipps an Kunden rauszugeben. Ich bin immer wieder erstaunt, dass man zwar auf das Forum verweist aber nicht auf das Wiki.
Sollte doch eigentlich laut deiner Wix-Anleitung (
) reichen.
Und falls du wirklich die IPv4 brauchen solltest, ein ping oder nslookup aus der Konsole in Windows oder auch sonstwo sollte eigentlich Auskunft geben. Bei ping unter Windows also z.B. "ping -4 hostname.de" bzw "nslookup hostname.de".
Vielleicht hilft dir das Wiki weiter: https://www.netcup-wiki.de/wiki/Domains_C…erver_eintragen
Ich kann dir nur sagen, dass ih in einem etwa 1 Jahr alten Paket mit Plesk Obsiodian die folgenden Python-Versionen wählen kann:
Bei einem neuen Webhostingpaket aus dem Adventskalender sieht es so aus:
Ob die alten Pakete jemals Plesk Obsidian sehen werden (und damit auch die neueren Pytho-Versionen) ist mir leider nicht bekannt.
Das gibt es bei Netcup leider nicht. Nachdem sich nach 30 Stunden an meinem Ticket (gleiches Problem) nichts getan hatte, hab ich dann noch mal ne Nachricht abgeschickt. Dann hab ich auf beide Tickets ne Antwort erhalten, aka "ich hab das gesehen und weiter gegeben".
Ja, eine direkte automatische Bestätigung gibt es nicht. Die Bestätigung erfolgt manuell, sobald es bearbeitet oder weitergegeben wird. Und das scheint momentan eben doch etwas länger zu dauern. Das ist dann bei tiefergehenden technischen Problemen in der Regel die oben erwähnte Mail.
Ich weiß zwar nicht, wieso genau ich ein Weihnachtspräsent bekommen habe, aber vielen lieben Dank [netcup] Felix P. und Co
Da schliesse ich mich gleich mal an, heute Nachmittag ist das Päckchen völlig unerwartet ins Haus geflattert.
Eventuell andere Subdomain? Mit bzw. ohne WWW? Subdomain dazwischen gelöscht und neu angelegt? Keine Ahnung, was Plesk da genau macht.
Nee, war mit der gleichen extern aufgeschalteten Subdomain (cloud.meinedomain.de). Ich muss mal das Wiki lesen, vielleicht mache ich beim Anlegen irgendwas grundsätzlich falsch, falsche Reihenfolge oder was auch immer. Immerhin scheint der Text unter dem Zertifikatsnamen bei Lets Encrypt normal zu sein, also dass das Zertifikat nicht mehr für die Domain verwendet wird. Das steht bei mir bei jeder einzelnen (Sub-)Domain in mehreren Webhostings so drin. Ich vermute mal es ist gemeint, dass das momentan vorhandene Zertifikat nicht mehr verwendet wird, wenn ich auf "Installieren" klicke, also ein neues Zertifikat anfordere. Eine andere Erklärung habe ich dafür nicht.
tab Weil die Domain-Verifikation nur alle x Tage/Wochen notwendig ist. Wenn danach ein neues Zertifikat über den gleichen LE-Account angefordert wird, wird es somit direkt ausgestellt und der ACME-Client muss nichts in diesen Ordner speichern.
Das habe ich aber gestern anders erlebt: Ordner gelöscht, LE-Zertifikat neu angefordert, Ordner wieder da. Naja, warten wir die Erneuerung ab. Falls das Verzeichnis dann wieder da sein sollte, bekommt der Support halt noch ein weiteres Ticket. Bei meinen anderen Anwendungen wäre es zwar störend, aber nur bei der Neuinstallation zum Glück. Ansonsten müsste ich mein Dutzend Webhostings komplett woanders unterbringen. Naja, ausdünnen muss ich den Bestand trotzdem im Lauf des Jahres 
.
Im conf-Verzeichnis (/conf) müsstest du in der Datei phpversion die PHP-Version eingeben (72,73,74 oder 80) und die Datei dann speichern. Falls das bei deinem Webhosting funktionieren würde, wäre dann spätestens nach 15 Minuten bei Eingabe von "php" die passende PHP-Version verwendet worden. Funktioniert in meinem neuen Webhosting aber nicht, der entsprechende Symlink in /usr/bin fehlt komplett und wird auch nicht angelegt. In den älteren Webhostings mit Plesk Onyx hat das bei mir noch überall funktioniert.
Das habe ich jetzt mal dem Support gemeldet und auch darauf hingewiesen, dass das Problem(chen) auch andere haben. Schaun mer mal was draus wird.
Ja, bleibt gültig, jedenfalls hat noch kein Browser gemeckert. Aber in dem Lets Encrypt Dialog, wenn ich da nochmal reingehe, dann steht unter dem aktuell verwendeten Zertifikat "wird nicht mehr von meinedomain.de verwendet". Alles dubios, vielleicht habe ich da was kaputtgemacht durch das Löschen und anfordern eines neuen Zertifikats. Unter Zertifikate wird aber auch nur das eine angezeigt und das sieht ok aus. Ich muss das nachher mal in Ruhe mit anderen Installationen und Zertifikaten in meinen netcup Webhostings vergleichen. Nicht, dass ich da jetzt, weil ich danach suche, Sachen komisch finde, die schon immer so waren und mir nur bisher nicht aufgefallen sind.
So, für den Moment hat sich das Problem erst mal in Luft aufgelöst. Ich habe zuerst das Zertifikat in den Hostingeinstellungen rausgenommen und auch die sichere Weiterleitung von http auf https. Dann habe ich unter SSL-Zertifikate das Zertifikat entfernt und anschliessend das .well-known-Verzeichnis im document root meiner Nextcloud-Installation gelöscht. Danach habe ich ein neues LE-Zertifikat installiert und in den Hosting-Einstellungen die sichere Weiterleitung wieder aktiviert und abgespeichert. Es wurde kein neues .well-known-Verzeichnis mehr angelegt. Hoffen wir mal, dass es so bleibt.
Die data.config.php kommt dann in das config Verzeichnis der Nextcloud-Installation. Also dahin, wo auch die config.php drin ist. Sie muss auch nicht unbedingt data.config.php heissen, der erste Teil ist mehr oder weniger beliebig, nur ".config.php" muss so sein, also z.B. xyz.config.php geht auch. Ich habe sie halt data genannt, weil sie den Pfad zum data-Verzeichnis setzt. Im conf-Verzeichnis (/conf) müsstest du in der Datei phpversion die PHP-Version eingeben (72,73,74 oder 80) und die Datei dann speichern. Falls das bei deinem Webhosting funktionieren würde, wäre dann spätestens nach 15 Minuten bei Eingabe von "php" die passende PHP-Version verwendet worden. Funktioniert in meinem neuen Webhosting aber nicht, der entsprechende Symlink in /usr/bin fehlt komplett und wird auch nicht angelegt. In den älteren Webhostings mit Plesk Onyx hat das bei mir noch überall funktioniert. Solange das nicht gefixed ist mus man halt entweder den Pfad angeben oder ein Alias oder Symlink (in einem Verzeichnis wo man Schreibrechte hat und das im Pfad liegt) selbst anlegen.
Na, solang es wirklich keine Auswirkungen hat, wenn das Verzeichnis fehlt und es nur bei der Erneuerung neu angelgt wird, dann lösche ich es manuell. Und sobald ich sehe, dass die Nextcloud bei der Überprüfung wieder den Fehler ausspuckt, lösche ich den neu angelegten Ordner halt wieder. Der angezeigte Fehler hat ja keine Auswirkung auf die Funktion der Cloud. Nur beim Update darf er halt nicht vorhanden sein, weil das sonst meckert und abbricht. Trotzdem will ich wissen, ob das jetzt normal ist oder nicht und falls nicht, woran es liegt. Letztlich ist es halt nur in etwa so unschön wie der tmp-Ordner, der eine Zeit lang angemeckert wurde, ohne den die Cloud aber Fehlermeldungen produzierte. Ist halt leider in Version 20 immer noch maximal eine Betaversion, nicht mal konform mit der deutschen Rechtsprechung. Oder wo ist der Link zur Datenschutzerklärung auf jeder einzelnen angezeigten Seite? Den gibts ja nur auf der Login-Seite und sonst nirgends. Naja, Hauptsache jeden Tag ein neues Feature.
Das .well-known Verzeichnis wird, glaube ich von lets-encrypt nur temporär bei der Installation eines Zertifikates genutzt um die Inhaberschaft der domain zu verifizieren, oder täusche ich mich da?
Nach der Erstellung sollte man es also ohne Gefahr löschen können und es sollte dann auch verschwunden bleiben, sofern du kein neues cert erstellst.
Bin mir aber nicht ganz sicher. Bleibt das Zertifikat noch weiterhin gültig, wenn du den Ordner löschst?
Ja, bleibt gültig, jedenfalls hat noch kein Browser gemeckert. Aber in dem Lets Encrypt Dialog, wenn ich da nochmal reingehe, dann steht unter dem aktuell verwendeten Zertifikat "wird nicht mehr von meinedomain.de verwendet". Alles dubios, vielleicht habe ich da was kaputtgemacht durch das Löschen und anfordern eines neuen Zertifikats. Unter Zertifikate wird aber auch nur das eine angezeigt und das sieht ok aus. Ich muss das nachher mal in Ruhe mit anderen Installationen und Zertifikaten in meinen netcup Webhostings vergleichen. Nicht, dass ich da jetzt, weil ich danach suche, Sachen komisch finde, die schon immer so waren und mir nur bisher nicht aufgefallen sind.
Jetzt habe ich gerade eben bei dem Webhosting 2000 Plus das Verzeichnis .well-known rausgelöscht und ein neues Zertifikat installiert. Und zack ist das Verzeichnis wieder drin. Muss ich jetzt echt bei diesem Webhosting auf SSL bei der Nextcloud verzichten? Ich fasse es nicht, ich installiere die Cloud jetzt woanders. Das kann doch eigentlich nicht normal sein, es gibt ja außer Nextcloud auch noch jede Menge andere Software, die keine fremden Verzeichnisse im document root haben wollen. Schade, sie lief eigentlich recht flüssig. Hmm, ich frag mal morgen beim Support nach, ob das wirklich so gedacht ist wie es jetzt ist.
tab Das liegt doch glaube ich normalerweise außerhalb, für den Kunden nicht erreichbar, und wird mittels Alias eingebunden. Oder hat sich das geändert?
Ja, so hatte ich das eigentlich bisher auch vermutet. Allerdings hatte ich letztens eine Nextcloud auf einem Webhosting 2000 Plus installiert. Da habe ich eine Subdomain extern aufgeschaltet (als externe Domain). Zertifikatserstellung dafür hat anscheinend funktioniert, das Zertifikat ist auch gültig, aber das .well-known-Verzeichnis war danach im document root der externen (Sub-)Domain, was wiederum der Nextcloud nicht gefallen hat von wegen "Extra Files". Also ist entweder die Geschichte für externe Domains anders geregelt oder es ist bei der Zertifikatserstellung was schiefgelaufen. Zumal mir bisher ein .well-known-Verzeichnis in meinen anderen Installationen noch nie untergekommen ist im document root. Auch nicht bei einer anderen Nextcloud in einem anderen Webhosting (8000), obwohl auch dort eine Subdomain als externe Domain verwendet wurde.
Hm, jetzt bin ich verwirrt. Habe gerade dem Webhosting 1000 vom 24.12. eine Zusatzdomain zugewiesen. Habe erst mal nichts eingestellt und wollte ein Lets Encrypt Zertifikat für die Domain erstellen lassen. Das gab dann eine Fehlermeldung, weil das entsprechende Token nicht gefunden wurde. Ok, habe dann den Dokumentenstamm auf ein anderes Verzeichnis, außerhalb von httpdocs gesetzt. Nochmal mein Glück versucht und ein Lets Encrypt Zertifikat erstellen lassen. Diesmal hat es funktioniert, jedenfalls kam die Erfolgsmeldung und das Zertifikat war in den Hosting-Einstellungen ausgewählt. Allerdings frage ich mich jetzt, wo denn eigentlich das .well-known Verzeichnis dazu ist. Das einzige das ich finden kann ist in httpdocs. Aber das ist Datum und Uhrzeit nach bereits beim ersten Versuch erstellt worden und ich habe es auch vor dem zweiten Versuch gesehen. Wo sollte denn das vom zweiten, erfolgreichen Versuch sein? Wird das nach erfolgreicher Zertifikatsserstellung automatisch gelöscht oder woanders hin verschoben, wo ich nicht drankomme?
Vielen Dank für die Antwort.
Ich fühle mich dumm das zusagen aber gerade hab ich einfach die Seite neu geladen und dann kams. Das Zertifikat wird jetzt angezeigt.
Dauert das ganze oder ist es Glücksspiel? Ich hoffe dass es bei den anderen auch funktioniert. Jetzt heißt es: Nie wieder anfassen bevor man was kaputt macht.
Besser so als anders rum.
Es dauert etwas, aber normalerweise höchstens einige Minuten. Also hat es entweder jetzt 3 Stunden gedauert oder die Heinzelmännchen von Support und/oder Technik haben hier mitgelesen.
Normalerweise sollte es so sein, dass man es im Plesk bei der entsprechenden Domain durch Klick auf "Lets Encrypt" erstellt. Dann sollte es in den Hosting-Einstellungen bereits automatisch ausgewählt sein. Falls das so nicht klappt, hast du wahrscheinlich einen Server erwischt, auf dem es - warum auch immer - nicht richtig funktioniert. Das wäre dann ein Problem, das du dem Support melden solltest. Kam leider in letzter Zeit schon öfter vor .
