Skip to content

Redis ändert das Lizenz Modell

Redis
  • Das sitzt man morgens beim Kaffee und dann liest man das hier.

    Schnelle Kontrolle, ob das so stimmt -> https://redis.com/blog/redis-adopts-dual-source-available-licensing/

    Ich verstehe das schon, man baut ein sehr beliebtes Tool. Alle Welt benutzt das und ich kann leider nichts dran verdienen, das kann ja nicht der richtige Weg sein. Wenn die großen Player das entsprechend honorieren würden, bräuchte es wohl solche Moves nicht. Ok, nun ist es so. Was ändert sich für mich persönlich?

    Dazu hole ich mal gerade aus und liste kurz den Einsatz von Redis für meine privaten Projekte auf.

    • NodeBB Foren
    • Als Cache für meine Nextcloud
    • Als Entwicklungsdatenbank (lokal)

    Man sieht ich mag Redis 🙂 Ich schaue mal dann was sie so geschrieben haben.

    1. What are the implications of this change for end users of Redis’ open source products?

    For end users who are using Redis’ open source version of Redis and new releases using either of the dual licenses for their internal or personal usage, there is no change.

    Das lass ich jetzt mal so stehen und schaue mir da die Entwicklung und die Reaktionen im Netz mal an. Ich werde sehr genau schauen, wie sich das entwickelt.

    MongoDB kann man als Alternative zur Redis Datenbank für NodeBB nutzen, das steht aber unter der selben Lizenz wie jetzt auch Redis. Also, zu mindestens Serverseitig.

    Our goal in selecting the Server Side Public License (SSPL) v1.0, a license introduced by MongoDB, as our license is to require that enhancements to MongoDB be released to the community.

    Für meine Nextcloud Installation müsste man mal schauen, was man noch nehmen könnte.

    Da ich von diesen ganzen Lizenmodellen nicht wirklich Ahnung habe, warten wir es mal entspannt ab und schauen wie sich das entwickelt.

    Es werden sicher auch bald ein paar deutschsprachige Medien das Themen aufnehmen.

  • Ein Artikel von Heise zum Thema

  • FrankMF FrankM hat am auf dieses Thema verwiesen

  • Proxmox 8.3 released

    Proxmox
    2
    0 Stimmen
    2 Beiträge
    122 Aufrufe
    FrankMF

    Ich habe gestern mal eine Neuigkeit ausprobiert, den Import einer Anwendung mittels OVA. Dazu habe ich irgendwo im Netz ein File für OpenProject gefunden (steht schon sehr lange auf meiner Testliste).

    Der Import war langweilig einfach. Nach Import ein paar Dinge eingestellt, Netzwerk usw. und die VM gestartet. Ok, die Installation war so alt, das ich sie danach wieder gelöscht habe, aber das soll ja kein Problem sein. Man kann OpenProject ja auch mittels .deb Package installieren.

    Zweiter Test war der "Tag View". Interessantes Feature, was ich auch mal direkt angewendet habe, auch wenn fast alle meine VMs Debian sind 🤓

  • MSI B650 Tomahawk WiFi

    Allgemeine Diskussionen
    5
    0 Stimmen
    5 Beiträge
    1k Aufrufe
    FrankMF

    @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.

  • MongoDB - Erste Erfahrungen

    Linux
    2
    0 Stimmen
    2 Beiträge
    150 Aufrufe
    FrankMF

    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 🙂

  • Nextcloud - extrem lange Ladezeiten

    Nextcloud
    1
    0 Stimmen
    1 Beiträge
    137 Aufrufe
    Niemand hat geantwortet
  • Nach Kernel Update werden die Module nicht automatisch gebaut!?

    Linux
    1
    0 Stimmen
    1 Beiträge
    180 Aufrufe
    Niemand hat geantwortet
  • Nextcloud - Upgrade auf 19.0.1

    Nextcloud
    1
    0 Stimmen
    1 Beiträge
    225 Aufrufe
    Niemand hat geantwortet
  • Rest-Server

    Verschoben Restic
    8
    0 Stimmen
    8 Beiträge
    563 Aufrufe
    FrankMF

    Dann mal eben ausprobiert. Auf meinem Server war die Version 0.9.7 selber, mit go, gebaut. Dann mache ich das auch mit der v0.10.0 so. Aber bevor ich anfange, wird die v0.9.7 gesichert.

    mv /usr/local/bin/rest-server /usr/local/bin/rest-server_0_9_7

    So erspare ich mir im Problemfall das selber bauen.

    Ok, dann die neue Version bauen.

    git clone https://github.com/restic/rest-server.git cd rest-server go run build.go

    Danach befindet sich im Verzeichnis die Binärdatei rest-server

    Die kopieren wir jetzt

    cp rest-server /usr/local/bin

    Danach kurzer Test

    # rest-server --version rest-server 0.10.0 (v0.10.0-6-g037fe06) compiled with go1.11.6 on linux/amd64

    Gut Version passt 🙂

    Dann ein Backup gestartet. Das sichert einen Teil meines Home-Verzeichnis

    Files: 153 new, 100 changed, 177857 unmodified Dirs: 0 new, 1 changed, 0 unmodified Added to the repo: 81.881 MiB processed 178110 files, 80.571 GiB in 0:28 snapshot 607e0027 saved Applying Policy: keep the last 3 snapshots, 3 monthly snapshots keep 5 snapshots: ID Time Host Tags Reasons Paths --------------------------------------------------------------------------------------- fa97890e 2020-07-25 21:02:05 frank-XXX monthly snapshot /home/frank 5b073bbb 2020-08-30 10:17:27 frank-XXX monthly snapshot /home/frank f7cf37ef 2020-09-06 15:13:03 frank-XXX last snapshot /home/frank 0157462c 2020-09-13 13:32:12 frank-XXX last snapshot /home/frank 607e0027 2020-09-14 08:09:34 frank-XXX last snapshot /home/frank monthly snapshot --------------------------------------------------------------------------------------- 5 snapshots remove 1 snapshots: ID Time Host Tags Paths --------------------------------------------------------------------- 3010b7cc 2020-09-06 11:39:27 frank-XXX /home/frank --------------------------------------------------------------------- 1 snapshots 1 snapshots have been removed, running prune counting files in repo building new index for repo [1:34] 100.00% 17351 / 17351 packs

    So weit funktioniert das genau wie vorher. Im Changelog stand ja was von Subfoldern. Das betrifft mich nicht, weil ich für jeden User genau ein Verzeichnis habe.

    So mit alles Gut 🙂 Dann warte ich mal morgen ab, ob die täglichen Backups der Server rund laufen.

  • IPTables dauerhaft speichern

    Angeheftet Linux
    1
    0 Stimmen
    1 Beiträge
    537 Aufrufe
    Niemand hat geantwortet