Keycloak bietet standardmäßig mehr kein JDBC_PING, also Clusterknotenerkennung via Datenbank an - nur mehr über Multicast (gibt zwar einen Workaround mit irgendwelchen manuellen Einträgen, aber soweit bin ich noch nicht, dass ich einen Master in Java-Infinispan absolvieren möchte).
Habe sicher schon im ein oder anderen Beitrag über die tollen Features geschwärmt, welche einem Netcup zu einem super Hobby-freundlichen Preis anbietet - aber ich bin immer wieder auf's neue entzückt.
We prefer to transfer our offers to established forum members as a matter of fairness towards Netcup. Improper use of cheap servers with high performance negatively affects all of us - and due to recent events we have to raise the suspicion of such improper use with all new forum registrations who are seemingly only interested in purchasing cheap servers and not interested in participating in the community.
Moooment. Ich muss hier in der Community mit-participaten?
Moooment. Ich muss hier in der Community mit-participaten?
Du bist ja sowas wie Papa-Schlumpf 
Deshalb brauchen wir einen neuen Avatar.6E443731-0B74-4A2F-AEEB-31DA97B9B952.png
Oh nein! Das tut mir jetzt aber leid für die MS-Kunden. Einbruchsversuch auf einem meiner Server, da werde ich das Subnetz 10.192.0.0/10 20.192.0.0/10jetzt wohl sicherheitshalber sperren müssen 
Moooment. Ich muss hier in der Community mit-participaten?
Du bist Master, das reicht.
Oh nein! Das tut mir jetzt aber leid für die MS-Kunden. Einbruchsversuch auf einem meiner Server, da werde ich das Subnetz
10.192.0.0/1020.192.0.0/10jetzt wohl sicherheitshalber sperren müssen
ip r a 192.168.0.0/24 via $(dig +short microsoft.com |head -n1)Edit: Hmm, ich hatte erst 192.168.0.0 gelesen - dacht es wäre einer dieser Abuse Meldungen mit lustigen Logauszügen.
Was ist denn hier aktuell los, dass immer ausländische Neukunden in der Tauschbörse unterwegs sind und kurz darauf gesperrt werden?
Wie bereits erwähnt, wollen die wahrscheinlich Server für Flux kaufen (dar Netcup für internationale Kunden die Preise für RS verdoppelt hat und genauer prüft - mit Tauschen umgehen sie das)
Erkenne lassen sie sich daran:
Mit einem Server machen sie dann um 30-50€ im Monat (und zahlen nur 9€, Server von anderen Anbieter wie DiOzean usw. lohnen sich dar nicht
(Im Reddit empfohlene sie meist Netcup oder Con...)
Das Flux Konzept an sich finde ich ja auch interessant, aber die herangehensweise der Teilnehmer scheint etwas eigennützig.
Ist wohl so ähnlich wie in früheren Bitcoin Jahren, in denen auf Teufel komm raus stromfressende Bitcoinfarmen in die Wüste gepflanzt wurden.
Mit einem Server machen sie dann um 30-50€ im Monat (und zahlen nur 9€...)
Ich bezweifle irgendwie, dass das funktioniert. 
(Zumindest nicht dauerhaft)
Ich bezweifle irgendwie, dass das funktioniert.
Davon ist auszugehen, aber viele sehen jetzt halt darin das schnelle Geld.
Im Sub Reddit raten einige Nutzer auch schon ab von Netcup und Co, dar das Ziel von Flux eigentlich Dezentralisierung ist (die fehlt wenn fast 50% der Server bei Con und Netcup sind) .
Also Nutzer die Flux wirklich unterstützen wollen (nicht nur Geld verdienen) gehen eigentlich nicht mehr zu Netcup
Copro Was hast Du mit der Nestkamera angestellt?
Ich habe leider schlechte Neuigkeiten für die Amselnest Fans - aber die Natur ist hier einfach brutal. Das Amselnest wurde von unbekanntem Zerstörer auf den Boden befördert und es gab keine überlebenden Nestlinge - nur noch das letzte vermutlich unbefruchtete Ei lag am Boden.
Zur technischen Tragödie und dem Post Mortem bei der Ermittlung des Schuldigen: Leider war die minütliche FTP Upload Funktion der Kamera deaktiviert und die Youtube Streams Geschichte noch nicht eingerichtet und den RTSP Recorder mit iSpy hat jemand ausgeschaltet gehabt ... also wissen wir nicht genau wer verantwortlich ist. Elstern, Katzen und andere Nesträuber hatten vermutlich leichtes Spiel ... Murphys Law hat leider ohne Rücksicht auf Verluste zugeschlagen.
Sowas erlebe ich leider jedes Jahr bei mir im Garten
Ich schätze mal höchstens ein Drittel der bei mir im Garten erbrüteten Jungvögel haben es überlebt.
Im letzten Jahr hat von den drei Jungamseln z.B. gar keine überlebt.
Sowas erlebe ich leider jedes Jahr bei mir im Garten
Bisher war ich da relativ verwöhnt und habe mir schon Vorwürfe gemacht - nicht nur wegen dem heftigen technische Versagen. Leider waren wir hier noch zu früh in der Nestling Phase als dass die Jungen schon das Nest hätten verlassen sollen.
Wir hatten einige Monde zuvor ein Hausrotschwänzchen Paar dass auf dem Reifen des Traktors im Stadl genistet hat. Das hiess für uns für einen Monat haben wir weder den Traktor bewegt noch versucht die Eltern zu stören. (Aber ich habe die erste Kamera hingestellt weil es mich interessiert hat - und das war schon sehr interessant)
Und nachdem am Ende auch 3-4 Nestlinge ziemlich unruhig wurden, könnt ihr Euch den Schrecken nicht vorstellen als auch hier das Nest auf einmal nicht mehr da war. Da konnten wir aber problemlos auf der Aufzeichnung feststellen, dass nur die Jungen bei ersten Flugversuchen zu rumgeturnt sind und die fittesten eben dabei das Nest runterschmissen haben. Wir haben die Eltern dann noch bei der Fütterung und der Flugbegleitung aller drei Jungvögel beobachtet und derweilen aufgepasst, dass keine Katzen angeschlichen kamen.
Wenn es SCSI ist, sollte theoretisch ein zpool trim helfen.
Toll und bei mir läuft das am Homeserver (Proxmox 7 / Debian 11) versehentlich gar nicht…
# zpool status -t | grep -Eo '\(.+%.+\)'
(100% trimmed, completed at Sat 11 Dec 2021 04:33:27 AM CET)
(100% trimmed, completed at Sat 11 Dec 2021 04:24:07 AM CET)
(100% trimmed, completed at Sat 11 Dec 2021 04:24:07 AM CET)Eigentlich dachte ich, dass sich der Cronjob in /etc/cron.d/zfsutils-linux darum kümmert, genauso wie der SCRUB-Eintrag, der einwandfrei funktioniert. Man könnte die zwar beide durch benutzerdefinierte ZFS-Eigenschaften am Root-Dataset deaktivieren (org.debian:periodic-scrub & org.debian:periodic-trim), aber standardmäßig sollten die auch ohne Wert aktiv sein. Tja, weit gefehlt…
# read user-defined config
ret=$(get_property "${pool}")
if [ $? -ne 0 ] || [ "disable" = "${ret}" ]; then
:
elif [ "enable" = "${ret}" ]; then
trim_if_not_already_trimming "${pool}"
elif [ "-" = "${ret}" ] || [ "auto" = "${ret}" ]; then
if zpool_is_nvme_only "${pool}"; then
trim_if_not_already_trimming "${pool}"
fi
else
cat > /dev/stderr <<EOF
$0: [WARNING] illegal value "${ret}" for property "${PROPERTY_NAME}" of ZFS dataset "${pool}".
$0: Acceptable choices for this property are: auto, enable, disable. The default is auto.
EOF
fiZeile 50 bis 51: zpool_is_nvme_only – WTF?! 
Keine Ahnung, warum das überprüft wird. Aber nun wird es endlich automatisch ausgeführt…
zfs set "org.debian:periodic-trim=enable" <POOL>1. Mai, Wetter gut. Prost 🍻 auf euch
(Zumindest nicht dauerhaft)
Wie bei allen Pyramiden/Schneeballsystemen eben...
Nutze den Thread mal als Tagebuch:
Ich konfiguriere auf jedem meiner Root Server vier virtuelle Netzwerkkarten:
eth0 - das Standardinterface in's Internet
eth1-3 - VLAN's
Das erste VLAN füge ich schon vor Installation hinzu, brauche ich für die Einrichtung. Die anderen beiden füge ich dann im SCP nach der Installation hinzu, und nach einem Neustart sind dann auch alle vorhanden und funken auf Anhieb in ihre jeweiligen Netze.
Netcup vergibt mir auch total schöne sequenzielle MAC Adressen, in diesem Fall enden sie in: :db:01 bis :db:04
Hier habe ich jetzt das Phänomen, dass mit den zwei zusätzlichen VLAN Interfaces das erste ausfällt. Das macht sich im OS bemerkbar, als dass er das Interface, welches eth1 war, als "rename4" markiert - aber mit selbiger MAC Adresse wie zuvor (:db:02). Die zwei zusätzlichen eth2 (:db:03) und eth3 (:db:04) sind problemlos vorhanden.
Wenn ich im SCP die zwei zusätzlichen wieder entferne und neu starte, taucht eth1 wieder auf, und ist nutzbar.
Füge ich die zwei zusätzlichen wieder hinzu und starte neu, verschwindet eth1 wieder unkonfiguriert in "rename4".
Ich führe mehrere Root Server mit exakt gleichem Aufbau, und habe das noch nie gehabt, deshalb etwas verwundert, was hier anders ist - habe jetzt (mit den zwei zusätzlichen eingebunden) das "rename4" via UDEV Regel per MAC Adresse auf eth1 forciert, und die IP Adresse (die eth1 ursprünglich schon genutzt hat) in das "neue eth1" umgetragen.
Das funktioniert jetzt - ist aber komisch - wie als würde da irgendein virtueller PCI Bus kollidieren. Habe allerdings auch nur die MAC Adressen und nicht die Busnummern verglichen, also bleibt wohl ein Rätsel - nochmal zurückbauen mag ich's nicht.
Sofern meine Ausführung Sinn macht, hat das schon mal jemand mit seinen virtuellen Interfaces erlebt?
Oder bin ich schlicht ein Spezialfall mit meinen vier Netzwerkkarten und habe Wettlaufsituationen (ja, ich habe das tatsächlich soeben mittels Wikipedia auf Deutsch übersetzt!) einfach verdient... 
Eben erst gesehen (weil ich so selten in die Logs des RSS-Feed-Scrapers schaue): https://infosec-handbook.eu ist nicht mehr erreichbar; die Domäne ist aber nach wie vor über Netcup registriert. Weiß hier ggf. jemand etwas Näheres? 
Da werden lediglich die "ja, seh ich auch so" und "Bravo für diese Aussage" Posts ansteigen...
Ja, sehe ich auch so. Bravo für diese Aussage! 
