Beiträge von m_ueberall

    Ok, also alles manuell editiert. Das erleichtert die Fehlersuche/Konfiguration.

    Aus der vorgenannten Ausgabe (Tip: Im Forum ist es üblich, längere Terminalausgaben oder Quellcode unter Verwendung des code.png-Symbols in der Editor-Menüleiste einzufügen, was das Lesen/Überspringen erleichtert) ist zu entnehmen, dass Apache2 bislang keinerlei TLS-relevante Definitionen enthält.

    Inwieweit certbot diese Konfiguration im Erfolgsfall ergänzt, kann ich nicht sagen. Ich verwende ein anderes Hilfswerkzeug, bin aber unabhängig dessen kein Freund von "Mischkonfigurationen", bei denen Teile der Konfiguration einer Anwendung quasi "im laufenden Betrieb" abgeändert werden können. certbot selbst erlaubt auch einen Modus, bei welchem Webserver-Konfigurationsdateien überhaupt nicht angefasst werden; diesen würde ich persönlich bevorzugen.

    • Zuerst zu dem potenziellen Zugriffsproblem: Ich habe certbot in einem Ubuntu 18.04-Container installiert und sehe nicht, dass hier ein eigenes System­nutzer­konto angelegt wurde. Wenn man certbot als Administrator/root ausführt, kann es eigentlich keine Zugriffsrechtsprobleme geben. Ich würde also vermuten, das Problem liegt darin begründet, dass certbot bestimmte Definitionen erwartet und ggf. nur Zertifikats-relevante Definitionen hinzufügt/modizifiert.
    • Jetzt zur fehlenden TLS-Unterstützung durch Apache2: Hier fehlen eine ganze Reihe von Einstellungen/Module.
      • Mit Eingabe von a2enmod ssl wird Apache2 nach einem Neustart auch auf Port 443 lauschen (siehe Datei /etc/apache2/ports.conf).
      • Die Definitionen in Datei /etc/apache2/sites-enabled/cloud.bitzeit.de.conf sind entsprechend zu ergänzen/modifizieren, indem für eben­diesen Port 443 ein ei­gener Abschnitt mit denselben Einstellungen verwendet wird wie für Port 80, ergänzt um TLS-spezifische Angaben. Ein gutes Beispiel für diese Definitionen findet sich beim Mozilla SSL Configuration Generator. Hierfür kann es nötig werden, zusätzliche Module zu installieren/aktivieren (bspw. a2enmod http2). Die Pfade für die beiden erforderlichen Zertifikatsdateien hat certbot ja bekannt gegeben: /etc/letsencrypt/live/de/{fullchain|privkey}.pem

    Ausblick: Wenn die Einstellungen einmal funktionieren, sollte man grundsätzlich alle Zugriffe auf Port 80 (http://) auf Port 443 (https://) umleiten, welche eigene Seiten/Anwendungen wie Nextcloud betreffen.

    Wo wird denn die "VHost"-Definition gespeichert und was müsste hier aktualisiert werden, ich persönlich tippe auch auf fehlende Berechtigungen.

    Wo sollte denn im normal Fall der Speicherort für diese Direktiven sein?

    Normalerweise findet man alles unterhalb von /etc/apache2/ – Ein Aufruf von apachectl -S (ggf. gefolgt von -D DUMP_INCLUDES) auf der Kommandozeile listet aber auf, welche Definitionen konkret von apache2 verwendet werden (inklusive Dateinamen).

    Je nachdem, wie der zuerst erwähnte Schritt der Neuerstellung der "VHost-Datei" durchgeführt wurde, kann es natürlich sein, dass dies unter Verwendung eines Hilfsprogramms geschehen ist, welches andere Verzeichnisse zur Verwaltung verwenden kann (ich lese das so, dass die Datei nicht händisch kopiert/editiert wurde, sonst wäre die Frage nach dem "Wo" oben ja unlogisch):

    Folgendes habe ich schon Versucht:

    • […] VHost file erneuert

    Ich verwende certbot nicht, aber wie es aussieht, wurden die Zertifikate wie gewünscht erzeugt und abgerufen. Was scheitert, ist die versuchte Aktualisierung der "VHost"-Definition. Dafür kann es eine Reihe von Ursachen geben: Etwa fehlende Zugriffsrechte durch certbot oder nicht-zuzuordnende "VHost"-Definitionen für Zertifikate (falls es mehrere gibt).

    Enthält die Apache2-Konfiguration denn schon Direktiven für die TLS-Unterstützung (angefangen bei Bedienung von Port 443 bis zur Einbindung der beiden Zertifikatsdateien mittels SSLCertificateKeyFile und SSLCertificateFile)?

    Die entsprechende Fehlermeldung wurde auch mehrfach in den LetsEncrypt-Diskussionsforen diskutiert, da könnte sich eine entsprechende Suche lohnen.

    Hallo Thomas,

    Ich würde mich bereiterklären, bereits bezahlte Serververträge via Transfercode zu übernehmen, damit Du (a) keinen Unsinn mehr damit anstellen kannst und (b) die jeweilige herzzerreißende Kündigung nicht selbst übernehmen musst*.

    Näheres gerne per DM.

    *Sofern hierbei keinerlei Folgekosten für mich entstehen, versteht sich.

    Bei Netcup stellst du dann folgendes ein:

    Entweder: Host: st.ouen Typ: CNAME Destination: uplawski.eu

    Oder Host: st.ouen Typ: A Destination: (identisch wie bei @)

    Als Ergänzung: Der Webserver, welcher bereits Anfragen für http://www.uplawski.eu bedient, enthält in beiden Fällen bei Aufruf von https://st.ouen.uplawski.eu[/…] dann eine Anfrage unter Verwendung der Unter(unter)domäne (st.ouen.uplawski.eu), welche er entsprechend bedienen muss.

    Nein es passiert nichts auf dm Server um diese Zeit.

    Wenn möglich und zeitlich genau eingrenzbar, würde ich vor diesem Zeitraum einmal das Rettungssystem booten. Tauchen dieselben Fehlermeldungen immer noch im syslog auf, ist die Ursache ganz klar nicht auf eine kundenseitige Einstellung zurückzuführen und sollte umgehend mit Protokollausschnitt an den Support gemeldet werden. (Dieser wird ggf. sowieso auf einen "Testlauf" mit dem Rettungssystem bestehen.)

    Its not possible to "partition" your server the way that you're asking for.

    Actually it is–think Proxmox in conjunction with LXC containers. (There are reasons why you don't want to use Proxmox on a G9 series RS due to stability issues ATM.)

    Using e.g. LXD–a system container manager, a tool for LXC, an operating-system-level virtualization method–you can basically achieve the same (including logically partitioning your virtual disk drive; think LVM/Btrfs/ZFS–but then, LXC/LXD can even do without those to limit/partition all kinds of resources).

    Having said that: With "limited IT expertise" and/or (virtually) no knowledge regarding the linked references, IMHO the only option to achieve "proper" isolation is to aim for option B suggested by itsmee and/or pay someone to help you understand technical/monetary/time-related requirements regarding both the implementation and management/maintenance of a potential (variety of) solutions regarding your plan in the first place, crybaby .

    Wenn du ein Server mit verknüpften Produkten zum Inhaberwechsel hinzufügst (z.B. mit VLAN), dann wird dir auch angezeigt, dass du gerade 20 statt nur einem Server versuchst zu übertragen. Ich sehe da nicht, dass man da noch nachbessern könnte.

    Laut Aussage von MSandro war doch gerade das nicht der Fall. Und die gezeigte Liste war ja lang genug, um sofort ins Auge zu fallen. Wenn es immer angezeigt würde (bei der Auswahl von Produkten mit verknüpften Netzen), wäre das ja kein Problem.

    m_ueberall Was passiert eigentlich, wenn man einen Transfercode generiert und das VLAN erst später dem zu transferierenden Server zuweist? :/

    Laut Dokumentation der Transferfunktion soll man die mit einem Transfercode verknüpften Produkte danach nicht mehr "anfassen", da der Code ansonsten nicht mehr funktionieren würde. Aber ein Test wäre es unbedingt wert.

    Hat eigentlich schon einmal jemand versucht, ein eigenes Produkt über den selbsterstellten Transfercode zu übernehmen? Unter Nutzung desselben Kontos? Diesen Test habe ich vor Abgabe der letzten eigenen RS leider versäumt, und mit den verbleibenden RS im Cluster will ich aktuell nicht experimentieren. (Das wäre ggf. ein Thema für bekannte Serverhorter, ThomasChr?)

    ja das war mir natürlich klar daher habe ich auch den RS Formatiert, aber natürlich nicht die anderen Server... Vom Support wurde mir da keine klare Antwort gegeben warum mir beim Wechsel andere Server angezeigt werden. Es hieß quasi "nur das Ausgewählte Produkt wird übertragen".

    pasted-from-clipboard.png

    Diese Antwort ist keinesfalls zufriedenstellend. "[…] In der Regel […]"?

    Wenn bei der Transfercode-Erstellung bei dem "Produktüberlasser" eine andere Liste von verknüpften Produkten angezeigt wird als sie später der "Produktübernehmer" sieht (beispielsweise verknüpft über ein VLAN), ist das schon schlimm genug. Wenn die Übernahme allerdings funktionieren würde – was in diesem Fall nicht ausprobiert wurde – ist das ein absoluter GAU. Selbst "Encryption at rest" und/oder IP-Adressen-spezifische NBDE (network-bound disk encryption) würde bei laufenden/herunter­ge­fah­re­nen, aber problemlos hochzufahrenden Servern (ggf. dank Übernahme der primären IP-Adresse) bei einer unbemerkten Übergabe/Übernahme keinen wirksamen Schutz bieten. Im nicht-privaten Bereich ist bereits bei der (ungeplanten) Übergabe zusätzlicher Rechner mit Kundendaten ganz schnell eine Mitteilung gem. Artikel 4 Nr. 12 DSGVO ("Verletzung des Schutzes personenbezogener Daten") fällig, sofern über Serverlogs (auch im SCP) nicht hieb- und stichfest dokumentiert werden kann, dass sie nicht von dritter Seite "angefasst/benutzt" wurden…

    Und alleine die Diskrepanz bei der gezeigten Liste der Produkte sollte Kunden mit mehr als einem Rechner (und einem gebuchten VLAN) erst einmal abschrecken, eine Vertragsübergabe eines Einzelservers in Erwägung zu ziehen… =O
    Ich denke, hier muss Netcup [ CC [netcup] Anna H. ] bei der entsprechenden Funktion nochmals dringendst nachbessern. Und diese Nachbesserung auch dokumentieren.

    dann hattest noch nie ein Programm von außerhalb der Paketverwaltung, des die 'Hello World'-Schallmauer durchbrochen hat;

    (es war ein Closed-Source Programm, auch sowas soll es mit Linux geben, des mir den Verstand raubte)

    Spätestens heute würde man ein Programm, welches nicht sauber paketiert ist, notfalls in einen Container verbannen (früher waren da ggf. Klimmzüge mit einer VM nötig). Und sofern Probleme direkt nach der Installation auffallen, kann man diese problemlos zurückdrehen, egal, ob das Programm dieses von sich aus erlaubt oder nicht, wenn das System vorher entsprechend sauber aufgesetzt wurde (beispielsweise dank ZFS/Btrfs, siehe etwa hier).

    bei dem was ich gerade in Bezug auf die Sicherung des Systemlaufwerks (NVMe SSD)

    erlebe wundert es mich wirklich nicht, wenn kaum jemand bereit ist f. Software Geld auszugeben;

    Da Windows seit vielen Jahren nur noch in einer virtuellen Maschine läuft, ist die Sicherung recht einfach und umfasst nur wenige (teilweise etwas größere) Dateien. Das erleichterte in der Vergangenheit auch den Umzug bei Wechsel des Hostrechners neben einem Upgrade von Windows XP auf Windows 10, da ich mich nicht wirklich auf die Windows-eigenen Snapshots verlassen mag. Externe (ZFS-)Snapshots außerhalb der VM gewährleisten, dass ich innerhalb von Sekundenbruchteilen auf eine alte Konfiguration zurückwechseln kann, wenn es nötig sein sollte.

    Eine Komprimierung des Abbilds lässt sich innerhalb der VM mit SDelete unterstützen, und gegen kippende Bits auf den Archivmedien hilft par2/MultiPar.

    (Wenn sich im Laufe der Zeit mit Rechnerneukäufen Windows-Lizenzen "ansammeln", wäre obiger Ansatz übrigens wohl auch unter alleiniger Verwendung von Hyper-V möglich, wobei die Windows-Unterstützung von ZFS noch etwas experimentellen Charakter besitzt.)

    [I]nwieweit unterscheiden sich hier USB-Sticks von SSDs - sind doch beides Flash-Speicher, oder irre ich mich?

    Neben Online-Quellen gab es in der aktuellen c't 10/2021 auch einen kurzen Artikel zum Thema (offensichtlich ist ein zweiter Teil angedacht, denn der Artikel schließt mit dem Absatz: "Flash altert vor allem durch die Benutzung. Doch auch stromlos gelagerte SSDs halten ihre Daten nicht über Jahre hinweg. In einem der kommenden Hefte lesen Sie, warum die Daten verloren gehen und was Sie dagegen tun können.") – Ich lehne mich mal aus dem Fenster und behaupte: Regelmäßiger Betrieb in 1–4 Monatsabständen, und sei es ein Prüfsummenabgleich aller Dateien auf einer Archiv-SSD.

    Mit "banaction = nftables-multiport" hatte ich es auch versucht. Zudem hatte ich das Paket nftables auch noch installiert […]

    Wenn das wirklich alles war (eine einzelne Zeile ändern und das Paket installieren), dann reicht das für sich nicht aus. Es gibt mehrere ausführlichere Anleitungen, wenn man wirklich eine saubere Umstellung auf nftables vornehmen will unter Debian Buster (anstatt die Kompatibilitätsschicht zu verwenden), siehe beispielsweise "Fail2Ban auf nftables umstellen". Ganz ohne ein Einlesen in das nftables-Thema wird das aber ggf. nicht (zufriedenstellend) gelingen. Informationen zu nftables sind im Upstream-GitHub-Repository von fail2ban leider sehr verteilt/versteckt.