Beiträge von darkside40

Zitat von the ratman

ich hätte auch noch 'ne frage ... was passiert in folgendem szenario?

ich hab ja 2 kodis über db verbunden, weil das die geräte sind, die ich hauptsächlich nutze.
meine holde hat 'nen kodi ohne mysql, weil sie bisher nur auf einem gerät schaut.

jetzt will sie aber eventuell auch 'nen kodi am tablet haben, der sich dann idealerweise auch mit ihrem "tv-kodi" abgleicht.
--> wie kriegt mans eigentlich hin, dass auch die holde am selben mysql eine EIGENE db fahren kann?
reichts da, dass die user verschieden sind, die auf mysql zugreifen, oder wie wäre das zu lösen? und wenn ja: wie krieg’ ich ihren user auf eine noch nicht vorhandene db fixiert? oder regelt das dann kodi?

Naja du erstellst auf deinem MySQL Server halt für Sie eine extra Datenbank und trägst diese dann in die Advanced Settings bei Ihr ein.

Ein MySQL Server kann ja durchaus mehrere Datenbanken verwalten

Korrigiert

Hab mir in den letzten Tagen mal wieder zwei Filme gegeben die so diese Rache Genre ala Punischer bedienen:

Silent Night: dachte bei John Woo kann man nix falsch machen. Ganz ehrlich allein schon dadurch das in dem Film kaum geredet wird ist der Film echt dröge, und die Kampfszenen waren jetzt auch alles andere als spektakulär, die Zeit hätte ich mir echt sparen können.

Ballerina: ähnliches Schema aber mMn wesentlich besser gemacht. Kampfszenen einfach nur super umgesetzt mit viel Action.

Naja entweder machst du nen DB Dump aus der laufenden DB heraus, oder die fährst die DB runter und sicherst die Dateien in denen deine Datenbanken liegen.

Weg Nr.2 bedeutet zwar eine Downtime ist beim recovern aber wesentlich schneller (man sollte nur nicht die DB Software aktualisieren zwischendurch).

Wo diese Daten liegen hängt davon ab ob MariaDB bare metal installiert ist oder ggf. in einem Container läuft. Normalerweise legt Kodi bei einem Upgrade neue DB's an und lässt die alten bestehen so das nix passieren sollte, aber ein Backup kann nicht schaden.

Statt Infotafeln zum drunter her fahren hätte viele Rollis wahrscheinlich lieber mehr Rollstuhlrampen wo sonst Treppen sind

Wollte es gerade sagen: ohne einen passenden Sensor wird das nix, auf einen Wetterbericht würde ich mich in diesem Fall nicht verlassen.

Aufgrund des Urheberrechts gibt es bei EPG leider keine einfache legale Lösung.

Da unkomplizierteste ist noch der [RELEASE] Takealug EPG Grabber

Für die installation musst du nur das Kodinerds Repo hinzufügen.

"In den nächsten Wochen sollte die Hintertüre mit dem neusten Update an alle Linux-Rechner weltweit verbreitet werden."

Okay das halte ich dann doch für arg übertrieben.

Kannst mich gerne berichtigen aber unter LE ist der SSH Server nicht standardmäßig aktiv und ohne das man Portforwarding einrichtet schonmal garnicht über das Netz erreichbar. Es gibt mMn auch absolut keinen Grund den SSH Server eines LibreElec ins Internet zu hängen. Genauso wenig wie bei Desktop Linux Systemen. Wenn man dies jedoch tut dann weiß man hoffentlich ganz genau was man macht und dann sollte auch diese Formulierung nicht missverständlich sein.

Radiuskoepfchen hat schon recht. Dadurch das dieses Backdoor es nur in einige Rolling Release Distributionen und Testbranches geschafft hat ist der Schaden zum Glück gering. Das sind eigentlich Distributionen die man idR nicht als Server OS nutzt und schon garnicht als Produktivumgebungen. Aber wer weiss vielleicht war das ganze auch nur ein Testballon.

Haben halt einen Rollback gemacht. Aber in dem Beitrag steht auch das man dort keine Zeichen einer Infektion gefunden hat.

Wenn Sie liblzma aus den Sourcen bauen sind Sie nicht betroffen, das Backdoor war nur in den Release Tarballs die Upstream gegangen sind und nicht im Sourcecode auf Github. Nen Rollback zu machen war aber auf jeden Fall die bessere wahl.

Sicher ein verwundbares (extern erreichbares) sshd muss auf dem System laufen. So wie ich das gelesen habe sorgt die bösartige liblzma dann übrigens dafür das die Authentifizierungsroutine von sshd so manipuliert wird das ein Schlüssel den nur der Angreifer hält für valide gehalten wird.

Das blöde daran: eigentlich braucht SSHD die liblzma eigentlich nicht, Sie wird nur von den meisten Distri's mit reinkompiliert weil Systemd eine Abhängigkeit dazu hat.

Doch anscheinend ist genau das der Fall:

Red Hat mentions that “the resulting malicious build interferes with authentication in sshd via systemd. Under the right circumstances, this interference could potentially enable a malicious actor to break sshd authentication and gain unauthorized access to the entire system remotely.”

XZ Utils SSHd Backdoor | Qualys Security Blog

On March 29th, 2024, security researcher Andres Freund discovered a backdoor in XZ Utils versions 5.6.0 and 5.6.1. Under certain conditions, this backdoor may…

blog.qualys.com

Jap das hat eher sehr viel mit klassischem Social Engineering zu tun.

Das Problem was es hier gibt ist mit der Log4J Lücke vor einigen Jahren vergleichbar. Eine wichtige Software Komponente in der Open Source Szene die von einer Einzelperson, am Rande des Burnouts, in Ihrer Freizeit Maintained wird.

Aber auch hier hätte es ggf. die Möglichkeit gegeben es technisch zu unterbinden. Scheinbar wird nämlich nicht gechecked ob die Release Tarballs die Upstream gehen dem entsprechen was im Git Repo steckt. Bei alles was ich gelesen habe war das Backdoor ja nicht im Git Repo vorhanden sondern wurde in den Tarballs versteckt die an die Distributionen gingen. Wäre das Backdoor in den Commits des Git Repo aufgetaucht dann hätte man es früher bemerken können.

Haben uns mal die erste Staffel von Die frei erfundenen Abenteuer von Dick Turpin gegeben. Kann man sich auf jeden Fall mal anschauen.

Hat so ein bisschen was von Our Flag Means Death. Und ja der Hauptdarsteller ist der Grufti aus IT Crowd.

Leute IPv6 besetzt den AAAA Record nicht den AAA Record.

Moin Leute,

öfter mal was neues. Falls Ihr einen Server betreibt der einen SSH Server bereitstellt (ist ja nicht ungewöhnlich) dann checked doch bitte mal eure Version der xz Utils (beinhaltet liblzma) unter Linux (Kommando ist xz -V).

Die Versionen 5.6.0 und 5.6.1 haben scheinbar eine Backdoor eingebaut welche am 29.03.2024 entdeckt wurde. Realistisch muss man sagen das man wohl eher nur betroffen ist wenn man einen Server mit einer Rolling Release Distro betreibt. Die Versionen der xz Utils unter Debian 11 und 12 sind z.B. viel zu alt um betroffen zu sein.

Eine Übersicht wo die verwundbaren Pakete drin stecken können seht ihr hier: https://repology.org/project/xz/versions

Eine detaillierte Beschreibung der Lücke findet ihr hier:

Deutsche Infos gibt es hier: https://www.borncity.com/blog/2024/03/3…der-ssh-server/

Wenn Ihr die V 5.6.0/5.6.1 irgendwo bei euch findet unbedingt updaten oder das System so lange vom Netz nehmen bis es Updates gibt.

Okay du bist auf ipvlan, ist also unwahrscheinlich das die Probleme von macvlan verursacht werden.

FunnyBoy  Acid_Rain könnt Ihr bitte mal nen Screenshot von euren Docker Setting in der Advanced View machen? Wie sieht es bei euch aus, wenn Ihr den Server über die GUI runter fahrt, geht der dann auch wirklich aus?

Ehrlich gesagt habe ich selber nie mit Mutischaltern gearbeitet. Vier im Digibit mit einem Kabel per Unicable LNB versorgt war für uns immer mehr als genug.

Naja was du auf jeden Fall brauchst ist ein Unicable fähigen LNB, der den du hast schient ja nicht Unicable fähig zu sein.