Beiträge von DerRené

Zitat von mainziman

was soll der 4te Punkt denn heissen?

die restlichen Punkte sind aber genauso toll (automatisch?!) übersetzt. Wer bitte möchte zufällige I/O Leistung haben? Sehr geil!

Cool, danke für den Einblick. Ich glaube damit kann man wirklich jedes denkbare Szenario irgwendwie abdecken.

Edit tatsächlich übersehen. Klingt als wäre man mit dem Setup wirklich sehr flexibel.

Soweit ich weiß ist die DNS-Waittime bei Acme fest. Aber mit meinen 630 Sekunden hatte ich da tatsächlich auch noch nie Probleme. Und ob der Job nun 630 oder nur 421 Sekunden benötigt, spielt für mich dann doch eher eine untergeordnete Rolle.

Was mich am Acme Client stört, ist dass man die Jobs hinterher nicht wirklich bearbeiten kann. Möchte man beispielsweise nur das Reload-Kommando ändern, muss man den Auftrag neu erteilen/überschreiben. Irgendwie doof umgesetzt. Aber im Grunde kann ich damit leben, da dafür eh nur ein eigenes Bashscript aufgerufen wird, dass das Zertifikat dann in den Containern verteilt und selber die richtigen Reloadbefehle durchschleift.

Ich bin jedoch ein Fan von klassischen Konfigdateien, die man auch nachträglich editieren kann. Vielleicht ist getssl doch mal ein Blick wert. Danke für den Denkanstoß.

Ah cool, hatte ich bei der Suche nicht entdeckt. Sieht interessant aus, danke.

Vielleicht bleibe ich aber einfach bei acme, da der Client immerhin von Haus aus alles Nötige mitbringt - so auch die API Unterstützung.

Aber ich schaue gern mal über den Tellerrand, man möchte ja nix cooles verpassen.

Zitat von KB19

Ich verwende das, seit es Let's Encrypt gibt: https://github.com/srvrco/getssl

Wollte mir den auch mal näher anschauen gerade, aber die Netcup API wird nicht direkt unterstützt, wenn ich's richtig sehe, oder?

Der Check auf xmpp.net machte z.B. Probleme bei Crosssigned Zertifikaten, in denen auch die alte CA noch enthalten war. Nutzen womöglich eine sehr alte openssl Version. kA...

Acme.sh hat beispielsweise gestern extra ein Update rausgebracht, wodurch man die Zertifikatchains gezielt auswählen kann um dem ein wenig aus dem Weg zu gehen.

Dann mal im Client / CLI im Debugmodus der Sache auf die Spur gehen und schauen welche Fehler geschmissen werden. Ansonsten kommen wir mit "geht nicht" hier nicht weiter, denn bei anderen scheint's ja zu gehen.

Mit welchem (S)FTP-Server verbindest du dich denn? Und nutzt du die im SCP->Medien->Images gezeigten Logindaten dafür?

Beispiel bei mir:

(beachte den SSH-Port, ist nicht der Standardport)

pasted-from-clipboard.png

Zitat von frank_m

Da entscheide ich selber, wann was gelöscht wird.

Aber auch nur solange man weiß, was man dort tut. Folgt man blind ohne Verständnis irgendwelchen Tutorials, passiert es ganz schnell, dass erneut Daten ungewollt flöten gehen.

Nicht dass wir uns falsch verstehen, ich bin da prinzipiell bei dir! Ich mag diese Einklickinstallationen auch nicht, weil die Automatismen oft viel ungewollt kaputt machen oder eben nicht die eigenen Bedarfe richtig abdecken. Nur ist die RS/VPS-Lösung eben auch nicht für jeden geeignet - wenn auch leider oft so suggeriert.

Ist richtig, alle 90 Tage ist prinzipiell nicht die Welt, aber: 4x im Jahr * Anzahl der Services, die letztendlich mit dem Zertifikat arbeiten. Da kommt bei mir einiges zusammen und ich mag nicht händisch überall nachsehen, ob das Zertifikat ordentlich gesetzt wurde.

Streng genommen sogar nicht alle 90, sondern alle 60 Tage. Ich update die Dinger ja nicht erst am letzten möglichen Tag, um dann noch unter Zeitdruck zu geraten.

Bei nur einem Dienst, den ich täglich eh kontrolliere, würde ich mir das Monitorting womöglich auch sparen.

Zitat von mainziman

ich wills vorher wissen was upgedatet wird

Na wollen wir doch mal beim Thema bleiben: primär ging es dir ja um Zertifikatsverlängerungen - da wird nix grundlegend neues installiert. Zumindest laufen die LE-Crons bei mir sehr zuverlässig. Und ja, auch wie du vorgeschlagen hast: an den meisten Stellen zentralisiert. Dennoch sitzt ein Monitoring an jedem Service und prüft, ob dort das Zertifikat i.O. ist. Spart mir letztendlich jede Menge Zeit ein.

Ein OS würde ich auch nicht unbeaufsichtigt upgraden lassen, aber das ist doch ein ganz anderes Thema.

Zitat von mainziman

(ich bin auch ein Gegner irgendwas unbeaufsichtigt automatisiert updaten zu lassen)

Kann ich sogar ein Stück weit nachvollziehen, aber ohne verlässliche Automatismen käme man doch zu nix anderem mehr als manuell ständig und überall Updates zu triggern / zu kontrollieren. Wenn ich mir allein nur vorstelle, auf all meinen Servern die LE Zertifikate manuell anzustoßen, bekomme ich Zuckungen.

Ordentliches Monitoring dran, das mir rechtzeitig eine fehlgeschlagene Verlängerung meldet und das reicht mir dann auch. Dafür ist mir die Lebenszeit dann doch zu kostbar, aber jeder setzt eben andere Prioritäten.

Zitat von siwa

Hier entsteht die Webpräsenz von willichtb.at.

Das ist offenbar nur die hinterlegte statische index.html:

http://hosting162844.a2f54.netcup.net/index.html

(die kannst du gern mal umbenennen/verschieben - die braucht es hier gerade nicht; im Grunde kann die komplett weg, der Platzhalter stammt ja noch vom Altprovider)

die index.php sieht schon anders aus (Fehlermeldung)

http://hosting162844.a2f54.netcup.net/index.php

Da müsste man dann wieder ins Errorlog schauen, was genau gemeldet wird.

Zitat von frank_m

Das zeigt z.B. bei "Wie ist meine IP" auch keine IPv4 an, trotzdem ist der Zugriff auf die IPv4 meines Wireguard Server völlig problemlos möglich

Korrekt. Mir ist auch kein (Standard)Fall bekannt, in dem ein Mobilgerät keine IPv4-Verbindungen aufbauen kann. Klar ist das dort alles geNATed, aber ausgehende Verbindungen klappen damit natürlich anstandslos.

shack hier z.B. kannst du prüfen, ob IPv4 und IPv6 vom jeweiligen Gerät grundsätzlich gehen würden: https://ipv6-test.com/ oder https://ip.zuim.de/

Zitat von mfnalex

Serverho(a)rder ist als Organisations-Name schon vergeben.

da war halt jemand schneller:

Zitat von H6G

Hab da mal zwei GH Orgs angelegt.

Einmal serverhorder und einmal serverhoarder

Die DNS-Records lösen auch alle richtig auf, eben überprüft:

me@host:~$ dig +short menetekel.net MX
10 mx2f0b.netcup.net.

me@host:~$ dig +short menetekel.net TXT
"v=spf1 mx a include:_spf.webhosting.systems ~all"

me@host:~$ dig +short key1._domainkey.menetekel.net CNAME
key1._domainkey.webhosting.systems.

me@host:~$ dig +short key2._domainkey.menetekel.net CNAME
key2._domainkey.webhosting.systems.

Würde mich mit der Info dann einfach nochmal an den Support wenden. Schließlich sind die genannten Angaben genau so umgesetzt worden.

mfnalex
am einfachsten wird es sein eine getrennte Umfrage zu starten und darum zu bitten die Themen zusammenzuführen. Dann muss nirgends ein Sonderfall konfiguriert werden.

Haben beide Domains einen unterschiedlichen Dokumentenstamm? Standardmäßig ist dieser nämlich /httpdocs.

Meine Empfehlung: beide Domains in komplett getrennten Verzeichnissen laufen lassen, beispielsweise /webseiten/domain1/ und /webseiten/domain2/

Anderenfalls würden beide Installationen imselben Verzeichnis landen und das sorgt für Probleme.

Siehe: https://www.netcup-wiki.de/wiki/Plesk_Ony…iduelle_Domains

Bei mir 1 von 1. Heißt also Netcup ist mit der Umstellung durch, eure Hostings wurden lediglich vergessen.

It's done when it's done, einfach gedulden.

Dank SRV-Records könnte man, bei Bedarf, den TS auch direkt über blabla.de erreichbar machen, aber ich möchte jetzt nicht noch zusätzlich verwirren.

Zitat von ichhalt033

bis die Änderung aktiv ist.

Ja, das dauert ein Weilchen.

Überprüfen kannst du es beispielsweise von einem Windows in der CMD aus:

nslookup -type=srv _ts3._udp.ts.blabla.de

Ergebnis müsste dann in etwa so aussehen:

>nslookup -type=srv _ts3._udp.ts.blabla.de
Server:  UnKnown
Address:  fd00::10:10:10:50

Nicht autorisierende Antwort:
_ts3._udp.ts.blabla.de  SRV service location:
          priority       = 0
          weight         = 5
          port           = 51234
          svr hostname   = domain.des.ts.servers.de

blabla.de    nameserver = root-dns.netcup.net
blabla.de    nameserver = second-dns.netcup.net
blabla.de    nameserver = third-dns.netcup.net