Beiträge von eNBeWe

    Für bestehende Server passiert erst einmal nichts, solange Kundinnen und Kunden den neuen AGB zustimmen. Für Neubestellungen gilt die neue Version der AGB. Diese erlaubt übrigens wieder den Betrieb von TOR. In Zeiten in denen Staaten immer mehr kontrollieren, möchten wir uns nicht länger dem TOR-Netzwerk verschließen.

    Bezieht sich das auf TOR-Relays oder auch explizit auf TOR-Exit-Nodes?

    Wie verhält sich diese Änderung bei "alten" Servern? Könnte/Dürfte ich auf meinem bestehenden Server TOR betreiben

    Server Firmware Updates sind echt Ungesund für den Admin. Mein Supermicro-Homeserver ist nach der Installation neuer IPMI/BIOS Versionen mehrfach direkt nach dem POST resettet. Hatte echt schiss, dass irgendwas schief gegangen ist... :|

    Das Gefühl kenne ich. Ich habe mal einen Fujitsu Server gebrickt, weil ich erst das BIOS und danach das IPMI aktualisiert habe. Das war anscheinend böse und hat einen Mainboard-Tausch nach sich gezogen. Seit dem immer IPMI -> BIOS -> RAID

    Deine Liste ist schon ganz okay. Ich nutze gerne FireHOL für die Firewall, aber das ist vermutlich Geschmackssache.

    Auf einem frischen Server sind noch Dinge wie

    - Root-login deaktivieren

    - Auto-Updates konfigurieren

    - Ungenutzte Dienste deinstallieren

    zu empfehlen.


    Ansonsten wie weiter oben: Mal die Suche bemühen zum Thema.

    Na ja, wie du das ganze schon angefangen hattest.


    Mein persönliches Vorgehen wäre:

    (0. Server Grundabsicherung)

    1. Webserver Nginx oder Apache erstmal für statische Seiten zum laufen bringen

    2. PHP im Webserver einbauen und mal mit einer phpinfo() Seite testen.

    3. MariaDB/MySQL installieren und absichern

    4. PHP <-> Datenbank Verbindung testen

    5. Easy-wi Installation anfangen

    Monitoring ist bei LE noch wichtiger, da zu vorher nicht unbedingt ersichtlichen Zeitpunkten der Webserver neu startet. Das führt zu einem kurzen Ausfall.

    Der Webserver muss nicht neustarten, sondern nur ein reload durchführen. Dadurch werden keine Verbindungen getrennt und die alten Verbindungen nutzen weiter die ausgehandelten Keys.

    Moin,


    die Antworten kommen natürlich sehr auf die Details an. Was ist der eigene Anwendungsfall, wie sind die technischen Rahmenbedinungen, usw.

    1. Haltet ihr LE für eine echte Alternative für die DV?
    2. Habt ihr Erfahrung mit OV? Habe schon mal bisschen geguckt, bisher war mir alles zu teuer. Gut & günstig wäre wie immer schön.
    3. Gibt es eine Übersicht welcher CA in welchen Browser "anerkannt" wird? Ich habe sowas nicht gefunden.
    4. Könnt ihr gute Alternativen empfehlen zu RapidSSL?

    Zu 1: Ich halte LE zur Zeit für das beste System für DV Zertifikate. Es gibt einige Ausnahmen, wie z.B. (noch) Wildcards, aber für die meisten Settings ist LE großartig. Man muss sich zwar erstmal an die kurzen Laufzeiten gewöhnen, aber dadurch ist man gezwungen einen anständigen Prozess zu automatisieren, der auch funktioniert und nicht alle 3 Jahre aus dem Aktenordner gekramt werden muss. Und Updates für Signaturen und Widerrufslisten sind so deutlich einfacher.


    Zu 2: Keine eigene Erfahrung mit OV, aber gut & günstig ist halt schwer. Im Gegensatz zur DV wird halt manuelle Arbeit notwendig. Und wenn die gut gemacht werden soll, dann muss das auch einfach was kosten.


    Zu 3: Kenne auch keine schöne Liste. Ändert sich auch gerne mal durch Updates etc. Am "einfachsten" in die Browser reinschauen und die interne CA Liste durchgehen. Ist sowieso mal ganz interessant zu sehen was da alles zugelassen wird.


    Zu 4: Kommt auf den Anwendungsfall an. IMHO, falls möglich, LE.

    Moin,


    ich finde die Idee auch sehr interessant.
    Dass nich alle Rechnungen am 1. gestellt werden sollen, ist auch sehr verständlich. Wie wäre es denn, wenn jeder Kunde sein eigenes Datum hat, z.B. der Tag der ersten Bestellung? Wenn ich mir also am 12.1. einen Server bestelle, wird die Rechnung wie üblich am 12. gestellt. Wenn ich dann am 19.1. noch einen zweiten Server klicke, wird der auf die bisherige Rechnungsstellung hinzugefügt und künftig auch am 12. abgerechnet. Die anteilige Rechnungsstellung für Anfang und Ende hat tldev ja schon vorgeschlagen.


    Und ja, ich sehe auch, dass das zusätzlichen Aufwand für netcup bedeutet :whistling: Wäre aber trotzdem cool

    Ich habe hier auch seit einiger Zeit eine APC unterm Tisch stehen. Flüsterleise und macht ihren Job einfach.


    KB19: Ich habe irgendwann mal mit NUT rumgespielt, aber ist ewig her. Die können aber auch den apcupsd abfragen wenn ich das richtig sehe: APCUPSD-UPS(8)

    Kurzzeitiges v6 klingt meistens nach einer falsch eingestellten Firewall. Wenn du die Router Advertisements nicht durchlässts kann es nach kurzer Zeit nicht mehr klappen.

    Das :: in der Adresse ist eine Kurzschreibweise für "Hier mit Nullen auffüllen". Daher konfigurierst du mit :: am Ende halt die Adresse, die hinten eine 0 hat, und mit ::1 halt die Adresse, die auf 1 endet. Grundsätzlich hast du ein Präfix mit 64 Bit zugewiesen bekommen. In diesem Präfix kannst du dir jede beliebige (und beliebig viele) Adressen auswählen. Trotzdem musst du natürlich konfigurieren, welche Adresse du nutzen willst. Der Server hört nicht auf das gesamte Präfix.


    Mach mal den Test im Rettungssystem. Eventuell muss der Support noch mal was im Routing reparieren. Ich habe den Verdacht, dass die Einrichtung von IPv6 nicht immer so ganz sauber funktioniert wenn die Server eingerichtet werden.

    Einmal kurz grundsätzlich zu IPv6 Adressen:
    Die Zeiten wo man nur eine Adresse hatte sind mit v6 vorbei. Die Adressen haben immer einen sogenannten Gültigkeitsbereich.
    Dieser kann zum Beispiel "global" sein, aber auch "Verbindung" bzw "link". Das ist auch der Fall bei der "anderen" IP Adresse die du gefunden hast. Die wird wohl mit fe80:: anfangen, oder?


    Du möchtest also tatsächlich, wie bei der statischen Konfiguration zwei Adressen in der Liste stehen haben.


    Die Konfiguration auf meinem VPS 20 sieht so aus:


    Zusätzlich muss noch darauf geachtet werden, dass die Firewall nicht zu viel verschluckt. Da gibt es ein paar Dinge, die zu zulassen möchtest.


    Ich hatte allerdings auch schon mehrfach das Problem, dass IPv6 initial auf einem Server nicht funktioniert hat und zunächst vom Support repariert werden musste. Dazu kann man einmal aus dem Rettungssystem heraus die v6 Verbindung testen.


    Hier dazu ein kleines Log wie es aussieht wenn es nicht klappt:


    Bei diesem Fehlerbild würde ich mich mal an den Support wenden.

    *Paranoia-Modus an*
    Grundsätzlich ist ein DNSSEC validierender Resolver ausserhalb deines gesicherten Netzes nicht viel wert. Du kannst dich dann immer noch nicht darauf verlassen, ob die Antwort nicht vielleicht zwischen dir und dem Resolver manipuliert wurde.
    Für 'echtes' DNSSEC musst du selbst resolven und validieren.
    *Paranoia-Modus aus*

    Nur so für die Gretchenfrage:
    Brauchst du zwingend den "originalen" LE-Client? Es stehen diverse Clients zur Verfügung, die bestimmte Anforderungen deutlich besser abdecken. Sehr beliebt ist zum Beispiel der "dehydrated" client: GitHub - lukas2511/dehydrated: letsencrypt/acme client implemented as a shell-script – just add water


    Der "Vorteil" des originalen Clients ist natürlich die automatische Anpassung der Konfigurationsdateien von apache etc.