Posts by frostschutz

    Remote DB ist eben so. Latenz gilt für jedes Query einzeln, bei Seitenaufrufen mit vielen Queries summiert sich das dementsprechend. Obendrauf kommt dann noch die Bandbreite, die jedes Query benötigt. Hier wird oft zuviel abgefragt (SELECT * ohne Limit) was dann tatsächlich gar nicht benötigt wurde. Lokal fällt das oft nicht weiter auf, Remote tut es sehr schnell ziemlich weh. Da hast du dir mit mehreren Servern dann keine zusätzliche Performanz geschaffen, sondern nur einen schönen Flaschenhals gebaut.


    Wenn deine Anwendung nicht speziell darauf optimiert worden ist, bist du mit der Remote DB auf dem Holzweg.

    Mache ich so wie in EDIT2 vorgeschlagen, mit Partitionen gleicher Größe (250GB, 500GB oder 1TB) und obendrauf dann LVM.


    Synology macht das auch so und nennt diesen Ansatz "Hybrid Raid".


    Ansonsten kannst du dein Glück mit dateisystembasiertem RAID also ZFS odgl. versuchen. Klassisches RAID hält auch freien Speicher und unwichtige Dateien redundant, beim Dateisystem kannst du hier vielleicht etwas besser regulieren.

    Wenn du eine scharfe DNS TTL eingestellt hattest, könntest du kurzfristig umsatteln. Alternativ wenn deine App es selbst unter mehreren alternativen URLs versucht. Ansonsten gibt es nicht viel, was du tun kannst. Ausfälle gibts auch bei Servern, und auch in der Cloud. Ausfallsicherheit gibt es nur mit entsprechender Vorbereitung.

    Du kannst mit sshd -T testen welche Konfiguration tatsächlich gilt


    Code
    # sshd -T | grep -i passwordauthentication
    passwordauthentication no


    yes dürfte da eigentlich nur heraus kommen, wenn das obere auskommentiert ist


    aber in dem Fall braucht man es eigentlich auch gar nicht, da yes ohnehin der Default ist


    irgendwie macht es also in beiden Fällen keinen Sinn und es bleibt dabei, daß das einfach nur Quark ist


    Wenn das von Netcup her so kommt kannst du Netcup fragen wozu das gut sein soll...


    Wenn Netcup das explizit auf yes setzen möchte wärs schöner das mit awk/sed an Ort und Stelle zu machen statt da einfach Sachen unten anhängen wo man nicht damit rechnet. Aber damit muss man bei vorgefertigten Images eben leben.


    Ich benutze nie den Installer des Hosters sondern installiere immer selbst von den offiziellen Distro Images bzw. per debootstrap & Co.

    Das PasswordAuthentication ist da ein Fremdkörper und war ursprünglich nicht Teil des Beispiels für den Match Block. Das wurde der Datei einfach nur angehängt.


    Die Einrückung ist auch nur für den Menschen da, für den Match Block selbst spielt diese keine Rolle. Der Match Block geht bis zum nächsten Match Block oder bis zum Dateiende. Deswegen stehen die wenn dann auch ganz unten... irgendwo mitten rein geht nicht, auch wenn die Einrückung das an sich so suggerieren könnte.

    Da gibts nicht viel zu erklären, das ist einfach Quark.


    Bzw. wenn es ganz unten am Dateiende steht oft das Ergebnis von irgendwelchen Tutorials die nach dem Schema 'echo zeug >> datei' anhängen arbeiten weil Einzeiler sind toll und editieren ist ja zu kompliziert...


    In der sshd_config manpage steht, "For each keyword, the first obtained value will be used." die letzte Zeile dürfte daher in deinem Fall ignoriert werden. Aber eine Garantie dafür gibts nicht, daher - lieber korrigieren so daß es keine doppelten Einträge gibt.

    `fstrim` meldet es sei nicht unterstützt - vermutlich weil LUKS die discard Option nicht durchschleift - laut `dmsetup table` ist keine discard Option vorhanden

    Das solltest du dann mal ändern, irgendwo muss es ja hängen. Ob der Parameter vom Bootloader her richtig übergeben wurde, kannst du in /proc/cmdline schauen. Dann kommts auch noch auf die Distro / Initramfs Konfiguration an, wie der Parameter genau heißen muss, nicht immer wird dracut / systemd-cryptsetup verwendet und dann ist es eben auch anders.


    Ansonsten zur Not aus dem Rettungssystem heraus von Hand durchführen.


    Oder auf das Snapshot-Feature (hosterseitig) ganz verzichten und einfach selbst Snapshots (serverseitig) machen.

    Verstehe jedoch nicht ganz, warum das bei dem nötig ist, bei einem guten Dutzend anderer VPS/Root-Server der Speicherplatz mit selbiger Konfiguration und auch ohne jegliche Discard Zusatzoptionen problemlos reported wird.

    Vielleicht sind die dann einfach nie vollgeschrieben worden...

    Da fehlt dem Kernel aus irgendeinem Grund dein Laufwerk... (nur /dev/sr0 erkannt sonst nichts). Storage-Treiber geändert und Modul dann nicht im Initramfs gehabt? Da müsste aus dem Rettungssystem chrooten und Initramfs neu bauen funktionieren.

    Das autoremove --purge fragt ja vorher nochmal. Von daher einfach anschauen. Wenn autoremove etwas entfernt das du noch brauchst, hast vorher schon was falsch gemacht mit der Paketverwaltung. Und für solche Fälle sollte man zur Not auch noch ein Backup (von Konfigurationsdateien /etc usw.) haben. Hast du keins, mach vorher eins.

    Um zu verstehen wie nginx funktionert habe ich alle Konfigurationsdateien aus /etc/nginx/sites-enabled entfernt, das Verzeichnis ist leer. Trotzdem liefer nginx die Seite index.nginx-debian.html aus dem Verzeichnis /var/www/html aus Warum?

    Wenn nginx keinen passenden Server Eintrag findet, geht der Request an den Default Server. Wenn du da eine Fehlerseite haben möchtest, musst du einen Default Server definieren, der eine solche ausgibt. Ist kein Default Server definiert, dann ist der erste beste Server auch der Default Server und somit werden deine Inhalte dann auch auf falschen Domainnamen ausgegeben. Siehe auch https://nginx.org/en/docs/http/request_processing.html und https://nginx.org/en/docs/http/server_names.html

    Konfigurationsdateien die ich selber für die Subdomian anlege (sites-availabel, Link in sites-enabled) scheinen ignoriert zu werden. Warum?

    nginx hat nur eine Konfigurationsdatei, der Rest läuft über includes. sites-enabled funktioniert nur, wenn in der nginx.conf die entsprechende include-Anweisung steht.


    Du kannst für jede Site, Location eigene Logdateien definieren, so kannst du ein wenig nachvollziehen, ob die Requests an der richtigen Stelle landen.


    Mit Certbot kann ich leider nicht helfen, da ich einen anderen Client nutze.

    HTTPS ist ein anderer Port als HTTP (443 statt 80), dein Webserver muss das anbieten, zusammen mit dem passenden HTTPS-Zertifikat (z.B. von Letsencrypt).


    Es ist sehr ungewöhnlich, einen Server daheim so ins Internet zu hängen. Machst du da irgendwas ganz besonderes drauf, was mit einem normalen Webspace oder VPS nicht abbildbar ist?


    Selbst dann würde ich dir empfehlen trotzdem einen VPS zu nehmen, den du deinem Server zuhause vorschalten kannst (nginx reverse proxy). Dann bleibt deine heimische IP privat und du kannst ordentliche A-Records im DNS (auf den VPS) machen statt dich da mit CNAME durchzuhangeln. Und du brauchst gar kein DynDNS mehr, wenn sich dein Server zuhause per VPN (WireGuard) mit dem VPS verbindet. Und wenn dein Server zuhause mal nicht erreichbar ist, kann der VPS wenigstens noch eine schöne Fehlerseite anzeigen.


    Einrichten musst das halt alles erstmal können. Lohnt sich nur wenn du eine besondere Anwendung hast... sonst 0815 Webspace.

    Ihn nicht einzusetzen schadet letztendlich Allen, da ungenutzte Resourcen, wie beispielsweise freier Arbeitsspeicher, nicht für andere VMs freigegeben werden können, oder anders gesagt: Es ist asozial.


    Habe ich noch nicht gehört. Freien Arbeitsspeicher habe ich auch gar nicht. Linux verwertet den ja stets zu 100% für den Dateisystemcache. Wenn das tatsächlich für Netcup relevant ist, wäre eine technisch fundierte Dokumentation im Wiki ganz nett, sei es zum Guest Agent direkt oder allgemein zur Fair use Thematik.

    Sendet Netcup hier keinen Shutdown Befehl per ACPI ?

    Meine letzte mir bekannte vServer Migration durch Host-Hardwarefehler ("Meldung über Migration Ihres vServers" Mail von Netcup) war irgendwann 2018 und da hat das einwandfrei geklappt. Irgendwelche Guest-Additions habe ich noch nie benutzt. Ich installiere mein Linux auch immer selbst und nicht mit den vorgefertigten Images...


    Verschlüsselung kann man machen - rein aus Datenschutzgründen oder gegen menschliche Fehler. Aber solange die VM die Schlüssel hat käme der Host über einen RAM-Dump da auch jederzeit dran. An irgendeinem Punkt muss man dem Host einfach vertrauen.


    Edit: wortlaut email


    Quote

    Bei einer Migration wird zunächst ein temporärer Snapshot erstellt. Dies ist auch im angeschalteten Zustand möglich. Sobald der Snapshot erstellt wurde, werden die "alten" Daten auf den neuen Host kopiert.

    Sobald diese kopiert wurden, wird der Server normal per ACPI heruntergefahren und die "neuen" Daten, die nach dem Snapshot erstellt oder verändert wurden werden noch kopiert. Im letzten Schritt wird Ihr Server dann auf dem neuen Host gestartet.