Beiträge von m_ueberall

  • Debian oder Ubuntu für den Serverbetrieb

    Zitat von H6G

    Bei Debian bleiben sie auf einer Kernel-Major-Version, bei Ubuntu springen sie ganz gerne mal durch den HWE Kernel, was zu komischen Verhalten führen kann.

    Wobei man sagen muss, dass man alternativ auf dem "GA"-Kernel bleiben können sollte (insbesondere bei virtuellen [amd64-/x86_64-]Servern, deren Hardware sich "sel­ten" ändert); für alle unterstützten Kernel gibt es aber mittlerweile einen "Livepatch"-Dienst, welcher durchaus seine Berechtigung hat (kann einige ansonsten kurz­fri­stig nötige Kernel-Updates/Reboots abfedern). Auch die Auswahlmöglichkeiten, was Kernelvarianten betrifft, sind bei Ubuntu größer.

  • Backup-Strategie bei hoher Latenz und vielen kleinen Dateien? Mit Borg-Backup machbar?

    Zitat von mbw

    Aber auch ein einfaches "scp -r <remote host>:/usr/share/man ." (viele kleine Dateien) drückt die Übertragungsrate reproduzierbar auf ca. 40 kB/s runter.

    Das ist sicherlich der schlechteste Fall/Ansatz, da scp nicht inkrementell arbeitet. Sowohl Borg-Backup (welches ich nicht nutze) als auch rsync via ssh (welches ich al­ler­dings ausschließlich für größere Archiv-Dateien und Netcup-RS nutze) sollten hier besser abschneiden.

    Eine weitere Möglichkeit, wenn Änderungen schon allein am letzten Modifikationszeitpunkt festgemacht werden können (vgl. find -mtime), wäre, nur die betref­fen­den Da­tei­en zuerst lokal zu archivieren und dann dieses Archiv via scp zu übertragen (unter der Voraussetzung, dass verschachtelte Lese-/Schreib­ope­ra­tio­nen in Sum­me mit der Übertragung von einer/wenigen "maximalgroßen" Archivdatei(en) schnel­ler sind, weil hier ggf. ein Caching ausgenutzt werden kann).

    Bei Platzmangel hat tar die Möglichkeit, das zu erstellende Archiv in Teile zu schneiden, welche beliebig groß sein können (vgl. tar --multi-volume --files-from=$(find ...)) und diese Teile können während ih­rer Erstellung auf /tmp (=RAM-Disk!) liegen, bevor sie (ggf. einzeln kom­pri­miert und ggf. auch nochmals verschlüsselt; das geschieht über ein Script, welches man tar via --new-volume-script übergeben kann) in einem Zielverzeichnis lan­den, welches ggf. direkt via sshfs/GlusterFS o. Ä. "auf den heimischen Rechner verweist". Damit entsteht im Rahmen der Archivierung keinerlei Da­tei­system-Over­head auf dem VPS (=temporär belegter Platz auf der virtuellen Platte) und die resultierenden Teilarchive sollten mit maximaler Geschwindigkeit über­tra­gen werden können. Ich selbst nutze diesen Ansatz in abgewandelter Form zusammen mit rclone statt sshfs, um Archive in der Cloud abzulegen und jedes Teil­archiv (über das vorgenannte Script) zudem via par2 vor Bitrot zu schützen.

    (Der Vollständigkeit halber: Bei rclone gibt es i.d.R. einen lokalen Dateisystem-Overhead, da man hier einen Festplatten-Cache verwendet; diesen kann man allerdings begrenzen.)

  • Catchall für Main Domain und Dyndns für Subdomain via Docker

    Zitat von 132818

    Das Catchall und die Weiterleitung funktionieren aber noch nicht so ganz. Kann das sein, da die NS die 48 Std Zeit brauchen das überall einzutragen?

    Jein; das geht in der Praxis deutlich schneller, aber die Gültigkeit der Einträge (TTL) ist/war ja laut Screenshot auf 86400 Sekunden gesetzt. Und alle Rechner, welche vor der gewünschten Änderung DNS-Einträge der Domäne angefordert haben, cachen die alten Werte. Also entweder lokale Caches explizit löschen und/oder Tests/Abfragen über andere DNS-Server abwickeln (1.1.1.1, 8.8.8.8, 9.9.9.9, … oder https://forum.netcup.de).

  • Catchall für Main Domain und Dyndns für Subdomain via Docker

    Zitat von 132818

    ad 1) Danke, meinst du mit einem "CNAME * meinedomain.com"? --> Habe den Eintrag hinzugefügt, siehe "Rot umrandet" im Bild im Anhang.

    Die aktuelle Konfiguration wird dadurch strenggenommen (laut RFC-Definition) ungültig, da neben einem CNAME-Eintrag normalerweise* keine anderen DNS-Einträge mit demselben Namen (hier: *) existieren dürfen (und im Optimalfall sollte dies im CCP auch als Fehler markiert werden; wie die jeweiligen Resolver bei Netcup da­mit um­gehen, ist eine andere Sache). Die A-/AAAA-Einträge unter der rot hervorgehobenen Zeile sind also zu löschen, weil sie durch den CNAME-Eintrag ja über­flüs­sig werden und man jegliche Missverständnisse ausschließen will. Beide CNAME-Einträge für die Subdomänen autoconfig und autodiscover lie­gen zwar auf derselben (Subdomänen-)Ebene, haben aber einen anderen Namen. Da es sich hierbei nicht um einen Wildcard-Namen ("*") handelt, haben sie somit Pri­ori­tät gegen­über letzterem Eintrag.


    *es gibt Anbieter, welche ein derartiges Konstrukt erlauben, wodurch auch ein CNAME-Eintrag/-Äquivalent für die Hauptdomäne (bei Netcup: @) möglich wird

  • NXDOMAIN looking up TXT for _acme-challenge (Subdomain lokale IP)

    Zitat von bonn13

    Sind hier 5min zu wenig Zeit?

    Potentiell ja. Insbesondere, falls für die Domäne DNSSEC-Signaturen aktiviert sind (Häkchen im CCP).

    Wenn es sich um einen neuen Eintrag handelt, würde ich nach ein paar Minuten zunächst einmal eine Abfrage über https://www.whatsmydns.net/ abschicken – sofern nicht mindestens ein paar wenige Server eine Antwort liefern, wird der LetsEncrypt-Dienst da auch nichts sehen.

  • Das längste Thema

    Zitat von friend_of_root

    Trotzdem ist es teilweise merkbar langsam zum Beispiel die Menüs eines Programmes zu öffnen, ein Fenster in den Vordergrund zu bringen oder einen Text einzutippen.

    Unter dem wichtigen Gesichtspunkt der Durchführung von Tests auf nativer Hardware ist das sicherlich letztendlich nicht zu umgehen, aber für die laufende Entwicklung gäbe es durchaus auch die Möglichkeit, auf dem Entwicklungsrechner eine virtuelle Maschine mit macOS zu betreiben. Auch der umgekehrte Weg – der Zugriff auf die Entwicklungsumgebung vom Mac, der zu diesem Zeitpunkt als "dummes Terminal" fungiert – ist ggf. möglich und könnte sich als schneller erweisen.

  • Trello/Kanban selfhosted

    Zitat von cltrmx

    Mein Gitlab läuft auf Debian 11, das macht überhaupt keine Probleme. Es gibt zwar offiziell noch keine Pakete für Bullseye, es funktioniert dennoch: https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6348

    Oder man zwingt GitLab in einen LXC-/LXD-Container, wenn man Omnibus-Paketen nicht traut (das Umkonfektionieren/Auftrennen "downstream" bei Debian ist leider ein Kampf gegen Windmühlen trotz sehr motivierter Paketierer); da hat man dann die freie Wahl der Linux-Distribution.

  • Domain auf Webserver umleiten

    Für eine Verknüpfung mit einer statischen IP-Adresse sind A- (IPv4-Adressen) und/oder AAAA-Einträge (IPv6-Adressen) im CCP erforderlich wie im Netcup-Wiki hier erklärt. "*" steht hier für alle potentiellen Subdomänen (www, ...) und "@" steht für die Hauptdomäne.

    Soll die DynDNS-Adresse genutzt werden (diese ist i.d.R. unter einem vergebenen Namen erreichbar), geht das nur über eine Umleitung mittels eines CNAME-Eintrags, welcher allerdings nur für Subdomänen definiert werden kann (Nutzung von "@" ist bei Netcup hier nicht möglich; es gibt allerdings Anbieter, die auch das erlauben); einen Beispiel-Diskussionsfaden im Forum zu diesem Thema findet man hier. Wichtig ist, dass auf der Ebene/unter demselben resultierenden Unterdomänennamen des CNAME-Eintrags keine anderen Einträge definiert werden können.

  • Bastel- und Bau-Ecke

    Zitat von mropen

    Wie sieht's denn bei den Vorgängern mit der Unterstützung durch den Linuxkernel aus? Bei den meisten SBCs wird eine Kernelversion so hingefrickelt, dass sie einigermaßen läuft und bei der hängt man dann für immer fest.

    Ich habe hier zwei ODROID N2+ (S922X CPU, 4xA73@2.4GHz + 2xA53@2.0GHz) und die Kernelunterstützung ist einwandfrei (derzeit bis 5.14.y – wobei ich selbst die jeweils neuesten verfügbaren Kernel meide und hier aktuell 5.13.y verwende)[*]; im Forum tummeln sich u. a. Debian-, Ubuntu- und Arch-Nutzer – viel besser wird's nicht. HardKernel hat hier schon mit älteren Modellen bewiesen, dass sie um den Wert der Software-Unterstützung wissen und entsprechend Aufwand investiert, um gän­gi­ge Linux-/Android-Distributionen damit zum Laufen zu bekommen. Dennoch sollte man sich zutrauen, bei Nicht-x86_64/amd64-Architekturen den Kernel selbst zu über­setz­en, weil ab und zu einmal Module nicht einkompiliert sind (insgesamt eben eine drastisch kleinere Nutzerbasis verglichen mit vorgenannter Architektur, klar) wie etwa diejenigen, welche man für die LXD+QEmu-VM-Steuerung benötigt.

    Bei den Radxa-SBC kommt es stark auf das Modell und die jeweilige CPU an, da gibt es durchaus auch größere Probleme, was man so im Forum sieht – mit der Zeit wird es sicherlich besser, aber man kann dort eher in die Rolle eines "Early Adopters" geraten (was schlichtweg daran liegt, dass die verbauten CPU neueren Datums sind als die vorgenannte). Andererseits wird auch bei Radxa Wert darauf gelegt, dass viele OSS-Autoren entsprechende Modelle als Erste in die Hand bekommen (dadurch wird die Kernel-/Treiberunterstützung stärker ausgelagert).

    Gegenüber den zahlenmäßig weiterverbreiteten "Original-Raspberries" – und da muss man sich einlesen! – haben alle vorgenannten Modelle allerdings den Vorteil, dass hier wirklich alles als OSS verfügbar ist, ohne jegliche proprietären Software-/Firmware-Bestandteile, welche man beim Raspberry nicht umgehen kann und (bislang) nicht dokumentiert be­kommt[**]. Das ist ein Grund, warum beispielsweise verschiedene Distributionen diese Modelle meiden. Es empfiehlt sich also, bei Interesse an SBC zu­nächst sehr intensiv auf Unterschiede zwischen den Modellen und verbaute Hardware ("überschaubarer Anzahl" von Komponenten auf dem SBC) zu achten. Hier kann es sich durchaus lohnen, auch ein­mal "gegen den Strom zu schwimmen" und Modelle mit kleinerer Nutzerbasis ins Auge zu fassen. Ich bin mit obiger Erstwahl un­ein­ge­schränkt zufrieden, auch wenn ich Ende des Jahres ggf. langsam mit einer neueren CPU-Generation (ARMv8.2) liebäugle, welche Radxa auf den Markt bringen will.

    EDIT: Bei Radxa sollte man im Auge behalten, dass dort bisweilen auch verschiedene Revisionen desselben Basis-Boards in zeitlich kurzen Abständen herausgegeben werden, welche bisweilen signifikante Design-Anpassungen/-Korrekturen (Stromversorgung auf den Pins, …) aufweisen. Mein bisheriger Eindruck ist der, dass die Chi­ne­sen (Radxa) wesentlich mehr Modelle entwerfen und "näher an der Chip-Quelle" sitzen als die Koreaner (HardKernel), welche dafür ggf. etwas mehr Aufwand beim ini­ti­alen De­sign eines Modells betreiben, weil sie sich aufgrund der Unternehmensgröße auf weniger Modelle konzentrieren und diese in Stückzahlen "an den Mann" bringen müssen.

    [*] Gerade die letzten v5.1x-Kernel haben sukkzessiv Erweiterungen für die aarch64/arm64-Architektur gesehen, wobei etwa Patches für die Reboot-Unter­stütz­ung bis­lang noch durch die SBC-Anbieter "downstream" beigesteuert werden müssen (diese werden ihren Weg in den Standard-Kernel finden, aber das kann noch ein paar Wochen/Monate dauern)

    [**] Nach meinem bisherigen Kenntnisstand; allerdings habe ich mit Entscheidung für den HardKernel ODROID N2+ im August letzten Jahres die Veröffentlichung von Firm­ware-De­tails zum Raspberry nicht mehr wirklich verfolgt, da mir selbst die aktuellen RPi-Modelle eine zu schwache CPU-Leistung aufweisen und ich von der obengenannten Software-Un­ter­stützung be­gei­stert bin.

  • Wordpress lädt kein Theme/Layout (nackte Oberfläche)

    Zitat von JoWin

    Die aktuelle index.php (s.Anhang) hat in der zweiten Zeile eine Menge kryptischer Zeichen. Kann die Ursache ein Virus oder Malware sein?

    Davon würde ich ausgehen. Nach Berichten aus dem Internet, welche man durch Suchen der ersten Zeichen dieser Zeile findet, werden seit einigen Tagen bisweilen mehrere PHP-Scripts damit manipuliert. Der Inhalt des (partiell) decodierten Scripts deutet nicht darauf hin, dass dies eine vom Nutzer gewünschte Erweiterung sein könnte, da es für die identische Manipulierung mehrerer PHP-Scripts in diesem Umfang und in derart kryptischer Form (da die Dekodierung Zeit kostet, würde kein WordPress-Modul-Autor derartige unsinnige "Klimmzüge" veranstalten!) schlechterdings keinen logischen Grund gibt außer sicherzustellen, dass dieser Code mit hoher Wahrscheinlichkeit ein- oder mehrmals ausgeführt wird.

    Zwecks Analyse würde ich eine Kopie aller Logs/Dateien anraten, gefolgt von umgehender Neuaufsetzung der Webpräsenz unter Verwendung aktueller Komponenten (WordPress, PHP, ...) und expliziter Kontrolle aller Zugriffsrechte.