Das längste Thema

  • Das ist dort völlig normal... lies mal Permanent Record von Edward Snowden, da erklärt er das alles sehr ausführlich. ;)

    Ich lese es gerade und kann es nur wärmestens weiterempfehlen.

    Danke dir. Hat es bei deiner Nutzung von Diensten etwas geändert? Ich denke mir oft "Die bekommen alle Daten vom Knotenpunkt in Frankfurt". :)

  • Danke dir. Hat es bei deiner Nutzung von Diensten etwas geändert? Ich denke mir oft "Die bekommen alle Daten vom Knotenpunkt in Frankfurt". :)

    Jain, viel gab oder gibt es da nicht mehr zu ändern. Außerdem bin ich noch bei der Vorgeschichte, irgendwo so Seite 165 von 428.


    Und das mit FfM ist irgendwo zumindest teilweise Bullshit bzw. so ein Halbwissens-Hype. Das Internet ist dezentral - für viele Dinge musst du doch garnicht über FfM. Mein ISP ist an den NIX rangeklöppelt und von da aus gehts dann zu Netcup - ich für meinen Teil gehe dementsprechend z.B. bei der Kommunikation mit meinen Servern nicht über FfM.


    Mal abgesehen davon ist ein Großteil deiner Daten ja sowieso verschlüsselt. Da fallen "nur" Metadaten zur Verbindung an, aber die sind eher relativ überschaubar.

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Es weiß niemand ob nicht nur in Frankfurt Daten abgegriffen werden. Daher ist es doch egal wie dein Routing ist.

    "Security is like an onion - the more you dig in the more you want to cry"

  • Verwendet hier jemand pbuilder und/oder mock zur Paketierung von Linux-Paketen auf ARM64-Hardware? Mich würden Links bzw. Erfahrungen und Benchmarks/geeignete Gerätekonfigurationen (Raspberry/"NUCs"/Cloud-Angebote) interessieren, nachdem die binfmt+qemu/kvm-Kombination in LXD-Containern leider arg zu wünschen übrig lässt und "ganze" VMs (virt-manager+qemu/kvm) für eine simulierte Fremdarchitektur doch mit einem gewissen Overhead daherkommen.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Verwendet hier jemand pbuilder und/oder mock zur Paketierung von Linux-Paketen auf ARM64-Hardware? Mich würden Links bzw. Erfahrungen und Benchmarks/geeignete Gerätekonfigurationen (Raspberry/"NUCs"/Cloud-Angebote) interessieren, nachdem die binfmt+qemu/kvm-Kombination in LXD-Containern leider arg zu wünschen übrig lässt und "ganze" VMs (virt-manager+qemu/kvm) für eine simulierte Fremdarchitektur doch mit einem gewissen Overhead daherkommen.

    Müssen die Pakete lokal gebaut werden? Ich nutze dafür ja immer sehr gerne den Fedora Cloud Dienst: https://copr.fedorainfracloud.org/. Ich beschränke mich bei meinen Paketen aber auch auf Fedora/CentOS/OpenSUSE. Der Openbuild Service von Suse (https://build.opensuse.org/) kann das aber auch für Debian/Ubuntu Pakete, falls die Pakete am Ende auch öffentlich sichtbar sein dürfen. Ich finde den Overhead relativ hoch, wenn man sich die Infrastruktur selbst hinstellen möchte. Wenn es daher nicht unbedingt nötig ist, würde ich einfach einen entsprechenden (Cloud) Dienst nutzen.

  • Müssen die Pakete lokal gebaut werden?

    Guter Punkt, genau das ist tatsächlich der Fall (was eigentlich "Cloud"-basierte Angebote ausschließt, aber zum Vergleich interessieren mich da schon Erfahrungswerte). Bei den Paketen handelt es sich nicht (nur) um Rebuilds öffentlich verfügbarer Software und sie werden ohne Ausnahme auch im Rahmen des Prozesses bei Erstellung signiert (insbesondere auch die .deb-Archive selbst). Die verwendeten Schlüssel und Scripts sollen "das Haus nicht verlassen".

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Guter Punkt, genau das ist tatsächlich der Fall (was eigentlich "Cloud"-basierte Angebote ausschließt, aber zum Vergleich interessieren mich da schon Erfahrungswerte). Bei den Paketen handelt es sich nicht (nur) um Rebuilds öffentlich verfügbarer Software und sie werden ohne Ausnahme auch im Rahmen des Prozesses bei Erstellung signiert (ja, insbesondere auch die .deb-Archive). Die verwendeten Schlüssel und Scripts sollen "das Haus nicht verlassen".

    Ah ok, das verändert natürlich die Ausgangslage ein wenig. Vielleicht könnte es ja dann interessant sein, eine eigene (private) Instanz von https://openbuildservice.org/ zu betreiben. Das wäre zumindest mein erster Ansatz. Hier haben sie auch einige Tipps und Empfehlungen zum Thema "Cross Architecture Builds": https://speakerdeck.com/openbu…uild-service-cross-builds

  • nachdem die binfmt+qemu/kvm-Kombination in LXD-Containern leider arg zu wünschen übrig lässt und "ganze" VMs (virt-manager+qemu/kvm) für eine simulierte Fremdarchitektur doch mit einem gewissen Overhead daherkommen.

    Was fehlt dir am CrossCompiling? Du kannst doch ARM Executables auf x64 builden und linken, so auch Pakete?

  • […] Vielleicht könnte es ja dann interessant sein, eine eigene (private) Instanz von https://openbuildservice.org/ zu betreiben.

    Softwareseitig (bis auf ein paar… äh… wenige Wünsche auf einer TODO/Feature-Creep-Liste) ist alles abgedeckt, es geht mir wirklich nur um die Eruierung, wie sinnvoll es ist, frühzeitig ARM64-Hardware auch zu Testzwecken während der lokalen Paketentwicklung einzusetzen.

    Was fehlt dir am CrossCompiling? Du kannst doch ARM Executables auf x64 builden und linken, so auch Pakete?

    […] Hier haben sie auch einige Tipps und Empfehlungen zum Thema "Cross Architecture Builds": https://speakerdeck.com/openbu…uild-service-cross-builds

    Der "Bau" der Pakete ist nur die eine Hälfte der Medaille, eine Testinstallation (und ggf. paketspezifische automatisierte Vergleichstests von Konfigurationen zwischen verschiedenen Architekturen, sofern verfügbar) ist ebenfalls erforderlich, bevor die Pakete "veröffentlicht" werden können. Somit kommt man an qemu oder spezifischer Hardware "eh'" nicht vorbei.


    (Im Optimalfall würde das alles in einer Containerinstanz ablaufen, die in irgendeinem LXD-Cluster liegt, aber das erlaubt binfmt derzeit noch nicht. ;()

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • 50% der User werden wohl jetzt durchdrehen, ...






    Unterwegs nen ./sshport 0000 beim Überlaufe von fail2ban ist auf jeden Fall ne ziemlich praktische Lösung. Evtl. noch mit nem timer der den Port 48h später zurück wechselt :D

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

  • 50% der User werden wohl jetzt durchdrehen, ...

    Und ob sie das machen. Die anderen 50% betreiben nämlich keine eigenen Server ;)


    Was hast du denn für Firewalls im Einsatz, die einfach so einen anderen SSH Port erlauben? Das wäre das Mindeste, was dem Skript noch fehlen würde :) Achja, und entsprechende SELinux Regeln müssten auch erstmal konfiguriert werden. Dieses Skript würde wohl auf keinem meiner Server funktionieren. SSH Port Änderungen sind gar nicht so einfach in der Regel.

  • Inwiefern?

    Das ist immer eines der ersten Dinge, die ich auf einem neuen Server erledige. Anderen Port eintragen, ssh neu starten, fertig.

    Aus den oben genannten Gründen. Es muss die Firewall entsprechend konfiguriert und zusätzlich Security / Hardening Features angepasst werden. Ich mache das ja auch bei jedem Server, den ich offen im Internet betreibe. Daher weiß ich auch nur zu gut, dass man sich so ganz schnell mal aussperren kann, wenn man nicht vorher an alles gedacht hat und einfach nur den SSH Port in der sshd_config geändert hat, oder SELinux Regel nicht bootfest konfiguriert hat oder das Automatisierungstool eine Änderungen wieder überschreibt...


    Natürlich gibt es auch Server, bei denen das auch einfach so geht. Aber ok, bei denen lohnt sich vermutlich auch eine SSH Port Änderung nicht so wirklich ;)