Ich hätte hier noch ein paar einzelne Haare auf dem Schreibtisch rumliegen. Soll ich die einem von euch zum spalten schicken?
Danke, meine Katze sorgt schon dafür, dass ich immer genug Haare auf dem Schreibtisch und immer weniger auf dem Kopf habe.
Ich hätte hier noch ein paar einzelne Haare auf dem Schreibtisch rumliegen. Soll ich die einem von euch zum spalten schicken?
Danke, meine Katze sorgt schon dafür, dass ich immer genug Haare auf dem Schreibtisch und immer weniger auf dem Kopf habe.
Warum sind denn heute alle so böse?
Weil ihnen warm ist.
Ich denke das ist spannend für einige hier.
ZitatNeue Forschungsergebnisse zeigen, dass Unternehmen aus dem Silicon Valley Tausende von bisher nicht gemeldeten Unterverträgen mit den US-Militär- und Bundesbehörden, einschließlich ICE und FBI, haben.
Ich denke das ist spannend für einige hier.
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.
Finde ich überhaupt nicht ok, dass du deinen Avatar geändert hast! Musste erstmal auf den Namen achten.
Finde ich überhaupt nicht ok, dass du deinen Avatar geändert hast! Musste erstmal auf den Namen achten.
Sorry - aber dieser Hund ist halt einfach zehn Mal cooler als ich, ich musste ihm den Vortritt lassen.
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.
Es weiß niemand ob nicht nur in Frankfurt Daten abgegriffen werden. Daher ist es doch egal wie dein Routing ist.
Sorry - aber dieser Hund ist halt einfach zehn Mal cooler als ich, ich musste ihm den Vortritt lassen.
is ein süsser japanischer Hund; Balkonnachbar gegenüber hat so einen Burschen;
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.
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".
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. )
50% der User werden wohl jetzt durchdrehen, ...
#!/bin/bash
#################################################
#
# Change SSH Port
# Version 1.0
# Copyright 2020, Veit <git@brnk.de>
#
# Tested: 09.07.2020
#
#################################################
##
## Usage: ./sshport <port>
##
################### Config ####################
mydir="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
. $mydir/../src/design.cfg
ssh_port=$1
######### DO NOT EDIT BELOW THIS LINE ##########
if [[ $# -eq 0 ]] ; then
cat <<- EOF
----------------------------------------------------
Usage: ./sshport <port>
EOF
exit 1
else
sed -i 's/^Port .*/'"Port $ssh_port/g" /etc/ssh/sshd_config
/etc/init.d/ssh restart > /dev/null 2>&1
echo ""
echo -e "[${green}Ok${nc}] Changed SSH Port: $ssh_port"
echo ""
fi
Alles anzeigen
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
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.
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.
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