Beiträge von tab

Zitat von Lukay

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.

Zitat von timkoop

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.

Zitat von killerbees19

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.

Zitat von killerbees19

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 .

Zitat von tab

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.

Zitat von tab

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.

Zitat von aRaphael

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.

Zitat von killerbees19

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?

Zitat von ccarlooon

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 .

Berechtigungen müssen dazu nicht umgestellt werdem. Zunächst solltest du in deinem config-Verzeichnis eine Datei erzeugen, bei mir heißt sie data.config.php und setzt den Pfad zum Data-Verzeichnis.

<?php

$CONFIG =
[
        'datadirectory' => realpath(__dir__ . '/../data'),
];

(Copyright KB19 ) Das wird benötigt, weil der Pfad zum data-Verzeichnis in der Konsole anders ist als im Webprozess.

Falls dann php -v bei dir die gewünschte PHP-Version anzeigt, bei mir php 7.4, dann kannst du mit php occ <Befehl> die occ-Befehle ausführen. Ansonsteh halt den Pfad zum gewünschten PHP mitgeben (/usr/local/php74/bin/php occ ...)

Meckert er wegen memory_limit, dann eben "php -d memory_limit=512M occ <Befehl>"

Hmm, wie sehen denn deine nginx-Einstellungen aus? Bei mir ist "Proxymodus" und "Intelligente Bearbeitung statischer Dateien" gesetzt, der Rest nicht. Also FastCGI Anwendung von Apache bedient.

Mit meiner Variante oder mit deiner? Wie sieht der Response-Header aus? Nextcloud setzt von sich aus schon einen Header X-Frame-Options: SAMEORIGIN

Vielleicht beisst sich der irgendwie mit deinem?! Ich habe den Header jetzt so in drei Nextclouds bei zwei Hostern drin und keine davon meckert mehr über fehlendes HSTS.

Zitat von goudi

Vielen Dank, hatte dass auch schon vor 2-3 Stunden (natürlich ohne die 1) in meine Config eingetragen.

Leider habe ich den Fehler in meiner NC Installation damit nicht wegbekommen. Was habe ich falsch gemacht?

Hast du nach dem Speichern der Änderung auch lange genug gewartet? Das dauert schon ein wenig, bis es wirksam wird.

Welche Header tatsächlich ausgegeben werden, kannst du in den Entwickler-Tools deines Browsers sehen.

Die Partition vergrößern? Anleitung gibt es auch im Wiki glaube ich. Der zusätzliche Speicherplatz ist jedenfalls da, aber die Partitionen bleiben beim Upgrade in der bisherigen Größe erhalten.

Natürlich ohne das "1." ...