Beiträge von m_ueberall

  • Das längste Thema

    Zitat von P.Se

    Soweit ich mich erinnen mag war das schon Immer(?) so.

    Gerade einmal mit dem ältesten vorgehaltenen Build-Container nachgestellt – Debian 8.x (Jessie) – und Frage mit Eingabetaste beantwortet:

  • 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://www.whatsmydns.net/).

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