Das längste Thema


  • Ansonsten sind wir auch sehr sehr gut aufgestellt. Große Gummibärchen Boxen, verschiedene Riegel, Bulk mini Rittersport Boxen, für den Winter Teebeutel...

    Erinnere mich daran, einen Bogen um Euer Büro zu machen. Bei uns wird auch ständig irgend ein Dickmacher als Köder ausgelegt, ... subtil, aber hinterhältig... ;-)

  • übersehe ich gerade irgendwas, oder kann ich bei acme.sh nicht mehr einfach die renew-hook manuell editieren? sind die jetzt encryptet? o0

    Ich zitiere mich mal selbst. Man darf die Änderungen also vorab per base64 codieren...


    der Sinn erschließt sich mir hierbei zwar nicht, aber okay...

  • Wer sich die Implementierung von Letsencrypt bei Synology ausgedacht hat sollte irgendwo an ein Server Rack gekettet werden, ....


    hab jetzt 1h gebraucht um 2 wildcard Zertifikate von meinem Cert VPS elegant auf der DS einzupflegen und automatisch zu erneuern. Acme.sh direkt auf der DS laufen zu lassen ist keine Option, da ich die Zertifikate lieber alle Zentral auf einer Maschine verwalte.

  • da ich die Zertifikate lieber alle Zentral auf einer Maschine verwalte.

    Magst du mir/uns erklären wie du die Zertifikate von deinem zentralen Server an deine jeweilige Webserver schickst und auch die Dienste neu startest?


    Weil ich aktuell noch auf jeden Host mit certbot arbeite und mich aktuell in acme.sh, RSA und ECDSA einlesen und wenn ich das ganze schon ändere würde ich dies auch gerne zentral über nen kleinen VPS. Jedoch bin ich noch unschlüssig wie ich die Zertifikate sicher auf meine Server übertrage und den Webserver im Anschluss neu starte bzw. reloade.

  • Bensen des geht trivial

    per sftp transferieren und z.B. das Äquivalent von dem da


    C:\_TOOLS\putty\plink.exe -4 -ssh host.domain.tld -l root -i C:\_TOOLS\putty\host.ppk shutdown -h now


    gibts unter Linux bestimmt (nur halt net gleich niederfahren); oder wie war das mit dicken Fenstern und schlanken Tuxen?

  • Magst du mir/uns erklären wie du die Zertifikate von deinem zentralen Server an deine jeweilige Webserver schickst und auch die Dienste neu startest?


    Weil ich aktuell noch auf jeden Host mit certbot arbeite und mich aktuell in acme.sh, RSA und ECDSA einlesen und wenn ich das ganze schon ändere würde ich dies auch gerne zentral über nen kleinen VPS. Jedoch bin ich noch unschlüssig wie ich die Zertifikate sicher auf meine Server übertrage und den Webserver im Anschluss neu starte bzw. reloade.

    Geht eigentlich erstaunlich einfach:


    auf dem Cert VPS läuft eigentlich fast nix außer acme.sh welches sich um 99% meiner Zertifikate kümmert.

    Per --renew-hook wird quasi nen bash script aufgerufen /opt/lazy_server/ssl/ssl_deploy.sh <server> <domain>


    wobei bei mir jeder Server eine eigene domain hat unter der er erreichbar ist, also übergebe $1/2 innerhalb des renew-hooks:

    ./ssl_deploy.sh server1.de domain.de


    damit verbindet sich der Cert server dann mit server1.de lädt dort die files hoch und löst dort dann /opt/lazy_server/ssl/ssl_receive.sh <domain> aus.



    Hier ist eigentlich nur mailcow_host="<domain.de>" wichtig, da hier noch mal gesondert ssl_mailcow.ssh ausgelöst wird. Damit werden die Zertifikate in die Mailkuh kopiert

    Das Script sieht dann so aus:



    Zusätzlich werde ich über das neue Zertifikat per push notification benachrichtigt /lazy_server/notify/push_ssl.sh <domain.de>



    die API keys für die ganzen server liegen noch mal extra in einem config file, aber folgen immer dem gleichen Muster:


    Code
    1. <hostname>_api_token="xxxxx"
    2. <hostname>_user_key="xxxx"



    ...


    Zugegeben auf den ersten Blick etwas verwirrend, aber ich nutze die Scripte nun schon seit mehreren Jahren und fahre eigentlich immer die gleich syntax - von daher versuche ich alles so allgemein wie möglich zu halten. Der vorteil von bash scripten im renew-hook ist, dass man die eben jederzeit anpassen kann. ändert sich z.b. der SSH Port kann ich das schnell korrigieren :)


    Der Vorteil ist halt, dass es sich beliebig erweitern lässt mit anderen dingen wie nem nextcloud container z.b. :)

    Geht sicher irgendwie eleganter, aber bash läuft auf allen maschinen und solange der code läuft bin ich zufrieden :D

  • geekmonkey vielen lieben Dank für die ausführliche Antwort + deine Scripts :thumbup:


    Ich werde mich da morgen mal in Ruhe durchkämpfen.

    Kein Ding, wenn du Fragen hast ruf an 😂😂😂


    Spaß beiseite, wenn ich endlich mal Zeit finde lade ich den ganzen überarbeiteten Quack mal bei github hoch. Gibt sicher besserer und professionellere Lösungen. Aber mein ganzes Script System läuft seit Jahren ohne Probleme und reduziert meine eigentliche Arbeit an den ganzen Servern auf weniger als 10min in der Woche.


    Bei sensiblen Daten machts evtl. noch Sinn die Daten zu verschlüsseln oder aber auf das vLAN auszuweichen. Hatte ich auch mal am Anfang, aber dann wars mir zu doof für netcup und nicht netcup Server unterschiedliche Lösungen zu haben.


    Edit: Bei der Lösung für ein eher eingeschränktes System würde hier wahrscheinlich ein Teil der User im Dreieck springen. Da wird das Wildcard Zertifikat im renew-hook verschoben, umbenannt, gepackt und per nginx bereit gestellt. Der Empfänger zieht sich das dann per curl.... immerhin gibt's ne htpasswd 😂😅

  • wo is jetzt des Problem?

    Quote

    Of the 51% observed fewer than four times, all
    but 2.86% of these have a first label between 7 and 15 characters in length
    (inclusive). Furthermore, most of these match the pattern consisting of only a-z
    characters (case insensitive), leaving us with 45.80% of total traffic on this
    day that appear to be from Chromium probes


    Fast 46% aller Anfragen und damit nach meinem Verständnis auch Last sind sinnlose Müllanfragen aus Chromium, für eine in meinen Augen irgendwie ziemlich fraghafte Funktion, die dem User scheinbar mal wieder das Denken abnehmen soll.

  • Fast 46% aller Anfragen und damit nach meinem Verständnis auch Last sind sinnlose Müllanfragen aus Chromium

    und die anderen 53,999% von Seiten mit

    - Adwords

    - Adsense

    - Tracking

    - anderer 3rd Party Quark


    des verbleibende Etwas - 1 von 100 000 Requests - wär somit tatsächlich sinnvoll;


    wobei wenn die Server dieser Last nicht gewachsen sind,

    dann hätten sie keine Server werden dürfen ;)


    für eine in meinen Augen irgendwie ziemlich fraghafte Funktion, die dem User scheinbar mal wieder das Denken abnehmen soll.

    back to Lynx wär angesagt :D


    ich hätte irgendwo aufgeschnappt, dass dieser Unfug wie ein DDoS wirkt, wobei auch,

    wenn die des net aushalten, hätten sie keine Server werden dürfen, den anderen Quark vertragen sie ja auch ;)


    des stell ich mir dann bei den kurgepfuschten Unfug von DNS-over-HTTPS od. DNS-over-TLS interessant vor ;)