Beiträge von 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

# 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.

bei parted kannst du das mit resizepart vergrößern

Bist du sicher daß das der korrekte Wert ist?

Zitat von AutoYaST

`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.

Zitat von AutoYaST

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.

achja, danach noch schauen ob alles ok ist oder ob schon ein update abgebrochen wurde weil kein platz mehr frei war, in dem fall das update nachholen

machen und schauen ob sich irgendwas über fehlende libllvm beschwert, das ist das einzige was passieren könnte

aber solange sich keiner um die paketverwaltung drum herum gewurschtelt hat, ist das sicher und gehört so

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.

zumindest mal das /64 weglassen

Zitat von mr_egbert

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

Zitat von mr_egbert

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.

Websockets haben theoretisch keepalive / ping-pong https://www.rfc-editor.org/rfc/rfc6455.html#section-5.5.2 Wenn das von den Servern / Clients praktisch eingesetzt wird, dann ist die Verbindung nie lange genug idle. Daß der Ping den Timeout zurücksetzt, steht auch unter http://nginx.org/en/docs/http/websocket.html so beschrieben.

Obs das in deinem Fall wirklich ist, müsstest du mal debuggen.

Theme für was eigentlich?

Die Anforderungen klingen ein wenig verrückt.

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.

Zitat von Bachsau

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.

Zitat von Andi22

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

Zitat

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.