Joa... Das wird bei mir jetzt dann auch wieder für ein paar Monate so werden...
Sag aber bitte vorher Bescheid. Nicht, dass wir uns hier wieder alle Sorgen machen. 
Posts by Virinum
-
-
Da hängt doch wieder was!
Fehler Lag doch auf meiner Seite. Bind hatte keine Berechtigung auf die Key-Files zuzugreifen.
Wenn das CCP in so einem Fall irgendwie eine Rückmeldung geben könnte, dass das Update nicht an DENIC übermittelt werden konnte, wäre das schon hilfreich gewesen. Aber wir drehen uns gefühlt mit dem DNS-Thema eh im Kreis.
-
Dann kann ich davon ausgehen das netcup einfach nur ein paar Sekunden einen "Komplettausfall" des Netzwerkes im RZ hatte?
Möglich, aber eher unwahrscheinlich. Ich denke eher da war irgendwas auf der Strecke zwischen Strota und netcup kaputt. Kurzzeitig falsch geroutet, eine Leitung irgendwo auf der Strecke hat den Geist aufgegeben und es musste umgeroutet werden usw.
-
Hab mir heute auch mal wieder ne neue Domain gegönnt (für meine AnonAddy-Instanz). Änderung der Nameserver ging schnell (ca. halbe Stunde). Aber auf den DS-Record warte ich seit über 8 Stunden. Da hängt doch wieder was!
-
Wenn du die 301-Weiterleitung verwendest, funktionieren nur http-Anfragen. Jedoch keine https.
Mach die Umleitung am besten mittels .htaccess-Datei. -
Gebt es zu, ihr bekommt doch alle Provision wenn ich was bestelle.
Übrigens brauchst du für jeden Container bei Docker einen eigenen Server. Sonst geht das nicht...
-
Von meinem Verständnis passt das Wildcard-Zertifikat zum Server, aber warum wird das von allen Client angemeckert.
Zu SOGo kann ich leider nicht viel sagen. Nur zum Zertifikat. Die Wildcard im Zertifikat gilt nur für eine Ebene. Also *.example.com gilt z.B. für www.example.com, aber nicht für test.www.example.com.
Ob das Weglassen von smtp. hilft/funktioniert/sinnvoll ist, weiß ich leider nicht. Wäre aber mein erster Versuch an deiner Stelle.
-
Hab bei meinem Matomo auch Cron konfiguriert, es heult aber trotzdem rum. Soll es halt, funktioniert und gut ist.
Nach erfolgreich eingerichtetem Cron-Job muss auch noch diese Option hier auf „nein“ gestellt werden.
-
Hast du mal versucht einen Benutzer hinzuzufügen (siehe Link auf deinem Screenshot). An der Stelle kannst du dann auch ein Passwort vergeben.
-
und sgplex.de wird bei mir im Browser als 202.61.242.104 aufgelöst (Cookie?) ...
Cookies haben nichts mit DNS zu tun.
Und der Rest der Welt bekommt da auch die 81.169.145.80 (eine IP von Str@t0) zurück: https://dnschecker.org/#A/sgplex.de
-
Könnte mir vorstellen, dass du erst auf „Fertig stellen“ klicken musst.
Netcup möchte, dass die besagten Nameserver sich für deine Domain verantwortlich fühlen. Das tun sie aber aktuell nicht.
Könnte mir vorstellen, dass „Fertig stellen“ dafür sorgt, dass deine Domain in die Nameserver übernommen werden.
-
Noch ein Indiz, dass die Nameserver nicht aktualisiert wurden.
Also Support anhauen oder (bringt leider in den wenigsten Fällen was) die Nameserver z.B. auf desec.io ändern. Vielleicht aktualisieren sie sich dann.
-
Typisch Support. Anstatt mal selber nachzugucken, was eventuell an der Domain falsch sein könnte, wird behauptet alles sei ok.
Schreib dem Support, dass die Nameserver nicht aktualisiert werden. Das ist ein häufiges Problem. Nur scheint der Support das immer wieder zu vergessen.
-
Könnte mir auch vorstellen, dass netcup es mal wieder nicht hinbekommen hat die Nameserver zu aktualisieren.
In dem Fall kann der Support am besten helfen.
-
Ist bei beiden der "Proxy mode" aktiviert?
Siehe https://forum.netcup.de/netcup…onieren-lokal/#post151391
-
Brumm brumm
-
Ist mir auch nicht aufgefallen (gut aufgefallen Chris M.), aber hier gibt es zwei verschiedene Versuche sich per SSH zu verbinden:
ssh sgplex.de:4747
ssh 202.61.242.104:4747
Nur löst sgplex.de nicht zu 202.61.242.104 auf, sondern zu 81.169.145.80 und 2a01:238:20a:202:1080::
Dass der Port beim Befehl falsch angegeben wurde, stimmt aber in beiden Fällen. Ist nur die Frage, welcher Host jetzt der richtige ist.
-
Was genau hast du denn bisher konfiguriert? Die IP 2001:9e8:234:6a00:b1e7:5a97:cfcc:84e1 ist eine 1&1-IP (vermutlich deine).
Mach doch mal ein paar Screenshots. Aktuell ist es wirklich sehr schwierig für uns dir zu helfen. -
Ich habe beim Certbot auch einfach die Option --reuse-key verwendet. Mein TLSA-Record verwendet dann DANE-EE (3), SubjectPublicKeyInfo (1) und SHA-256 (1).
Und hier noch ein Tool, mit dem man das ganz gut testen kann: https://dane.sys4.de/
-
Wenn ich mir sicher bin, dass alles richtig konfiguriert ist, dann gehe ich lieber nach dem Motto "Je strikter, desto besser" (reject).
