linux-nerds.org

@kiwilog Danke für die Antwort.

Ich habe mittlerweile ein ASUS Rog Strix B650E-F Gaming Wifi. Auch dieses Board hatte Probleme. Ich habe dann den RAM ausgetauscht und jetzt funktioniert es. Das MSI Board liegt hier aber noch, so das ich deinen Tipp da mal testen kann. Das wartet aber noch auf einen AMD Ryzen 9000 🙂

Als Fazit, die AM5 Plattform scheint sehr empfindlich zu sein.

So frisch von der MongoDB Front und wieder viel gelernt, weil beim Üben macht man Fehler 🙂

Oben war ja mongodump & mongorestore von der KI empfohlen. Hier das wie ich es gemacht habe.

mongodump frank@redis-stack:~$ mongodump -u frank -p '<password>' --host 192.168.3.9 --authenticationDatabase admin -d portfolio -o mongodump/ 2024-04-06T09:29:25.174+0200 writing portfolio.stockList to mongodump/portfolio/stockList.bson 2024-04-06T09:29:25.175+0200 writing portfolio.users to mongodump/portfolio/users.bson 2024-04-06T09:29:25.175+0200 done dumping portfolio.stockList (8 documents) 2024-04-06T09:29:25.176+0200 writing portfolio.total_sum to mongodump/portfolio/total_sum.bson 2024-04-06T09:29:25.177+0200 done dumping portfolio.total_sum (1 document) 2024-04-06T09:29:25.177+0200 writing portfolio.old_total_sum to mongodump/portfolio/old_total_sum.bson 2024-04-06T09:29:25.177+0200 writing portfolio.stocks to mongodump/portfolio/stocks.bson 2024-04-06T09:29:25.177+0200 done dumping portfolio.users (4 documents) 2024-04-06T09:29:25.178+0200 writing portfolio.settings to mongodump/portfolio/settings.bson 2024-04-06T09:29:25.178+0200 done dumping portfolio.settings (1 document) 2024-04-06T09:29:25.179+0200 done dumping portfolio.old_total_sum (1 document) 2024-04-06T09:29:25.179+0200 done dumping portfolio.stocks (34 documents) mongorestore mongorestore -u frank -p '<password>' --host 192.168.3.9 --authenticationDatabase admin -d portfolio mongodump/meineDatenbank/

Hier wird die Datensicherung mongodump/meineDatenbank/ in die neue Datenbank portfolio transferiert.

Grund für das Ganze? Mich hatte der Datenbank Name meineDatenbank gestört.

Benutzerrechte

Jetzt der Teil wo man schnell was falsch machen kann 🙂 Ich hatte also die neue Datenbank, konnte sie aber nicht lesen. Fehlten halt die Rechte. Ich hatte dann so was hier gemacht.

db.updateUser("frank", { roles: [ { role: "readWrite", db: "meineDatenbank" }, { role: "readWrite", db: "portfolio" }]})

Ging auch prima, kam ein ok zurück. Nun das Problem, ich hatte beim Einrichten, den User frank als admin benutzt. Durch den oben abgesetzten Befehl (frank ist ja admin), wurden die neuen Rechte gesetzt und die Rechte als Admin entzogen!! Das war jetzt nicht wirklich das was ich gebrauchen konnte. LOL

Ich hatte jetzt keine Kontrolle mehr über die DB. Das war aber nicht so wirklich kompliziert, das wieder zu ändern. Die Authentication temporär abstellen. Also /etc/mongod.conf editieren und

#security: security.authorization: enabled

eben mal auskommentieren. Den Daemon neustarten und anmelden an der DB.

mongosh --host 192.168.3.9

Danach neuen User anlegen

db.createUser({ user: "<name>", pwd: "<password>", roles: [ { role: "userAdminAnyDatabase", db: "admin" } ] })

mongod.conf wieder ändern und neustarten. Danach hat man wieder eine DB mit Authentifizierung und einen neuen Admin. Ich bin diesmal, man lernt ja, anders vorgegangen. Es gibt nun einen Admin für die DB und einen User zum Benutzen der Datenbanken! So wie man es auch auf einem produktiven System auch machen würde. Wenn ich jetzt mal was an den Benutzerrechten des Users ändere, kann mir das mit dem Admin nicht mehr passieren. Hoffe ich 🙂

Ein Artikel von Heise zum Thema

Link Preview Image Datenbankanbieter Redis ändert sein Lizenzmodell – erneut

Die No-SQL-Datenbank wird künftig nach einem dualen Modell lizenziert: Redis Source Available License Version 2 oder Server-Side Public License Version 1.​

favicon

Developer (www.heise.de)

Die Antwort von ChatGPT wie der Redis ConnectionPool funktioniert. Ein paar Dinge finde ich komisch.

https://chat.openai.com/share/b10fdadc-2c9b-404a-bc99-c883d110d6af

Da fällt mir heute beim Lesen dieses Beitrages auf das ich damals ja auf unstable gestellt habe.

[frank-manjaro ~]# pacman-mirrors --get-branch unstable

Anleitung dazu -> https://wiki.manjaro.org/index.php/Switching_Branches

Ok, da könnte ja auch mal was schief gehen? Da ich hier aber ein btrfs Filesystem fahre und Timeshift Snapshots anlegt, sollte das Risiko überschaubar sein.

567442e5-80f0-4ce9-9b91-3e8f9a4a94d8-grafik.png

Es werden bei jeder Aktion vorher Snapshots angelegt, auf die man im Grub Menü zugreifen kann und diese wieder installieren lassen kann. Hatte das früher schon mal getestet, ging wirklich gut. Werde ich die Tage auch hier auf dem System, zur Sicherheit, mal testen.

Fazit, ich lasse das mal so wie es ist 🙂

Heute mal in die bestehende Installation meine Intel ARC A580 GPU eingesteckt. Wollte mal schauen ob das gut klappt. Da die Treiber ja im Kernel vorhanden sind, habe ich keinerlei Probleme erwartet. Und so war es auch. Neustart und fertig. Im BIOS natürlich vorher umgestellt, das sie auch benutzt wird, habe ja einen AMD Prozessor mit eingebauter GPU im CPU-Sockel stecken.

Screenshot_20240303_101728.png

Die Wechselfunktion (oben links in der Ecke) um die virtuellen Desktops zu wechseln und zu bearbeiten ist richtig gut geworden.

Screenshot_20240303_101809.png

Und auch ein Ärgernis auf meiner KDE Plasma Installation scheint weg zu sein. Wenn ich ein Programm zur Arbeitsfläche hinzugefügt hatte, wurde die Position immer irgendwann zurückgesetzt. Beispiel, Icon des Programmes rechts unten abgelegt. Irgendwann tauchte es dann in der normalen Ansicht (alphabetisch) sortiert, links oben, wieder auf. Sehr nerviger Bug.

Mist, jetzt habe ich auch noch Streamlit gefunden. Jetzt geht mir langsam die Zeit aus...

Und hier taucht es dann auf -> https://www.debian.org/News/2024/20240210

Für den, der sich alle Änderungen ansehen möchten -> https://github.com/nextcloud/server/releases