Beiträge von Dominik Katzenmaier

Als Gast kann das komplette Forum angesehen werden. Um selbst Beiträge oder Themen verfassen zu können, musst du dich erst registrieren.

  • Open Source: Sieben Vor(ur)teile unter der Lupe

    Da gebe ich MarkusK voll und ganz Recht. Agorum Core Open nutzt zwar selbst diverse Open Source Komponenten von Red Hat, Apache und co., wirkt selbst aber eher wie Freeware, statt Open Source. Eben weil all diese Dinge fehlen (zumindest finden wir sie nicht), die ein Open Source Projekt ausmachen:


    - Zugänglicher aktueller Quellcode (zum Beispiel in Form von Git)

    - Mitwirkungsmöglichkeiten durch die Community und zwar nicht nur in Form von Verbesserungsvorschlägen und Feature-Wünschen, sondern auch durch Code-Beiträge (zum Beispiel in Form von Pull Requests)

    - Eine Möglichkeit eigene Builds zu erzeugen.


    Ich persönlich habe nichts dagegen, dass Agorum Core Open eine Freeware ist. Zumal man im betrieblichen Umfeld sowieso sehr schnell an dem Punkt ankommt, an dem man bereit ist für die Pro-Features und den Support eines Enterprise-DMS zu zahlen, oder das Thema DMS ganz sein lässt. Aber Agorum Core Open als Open Source zu deklarieren, hat wohl mehr mit Marketing zu tun ;).

  • Bedeutung des "Haken"-Bages im Information Center

    Hallo zusammen,


    Uns ist etwas ins Auge gefallen und wir rätseln über dessen Bedeutung. Wir sehen im Information Center teilweise Dokumente, die mit einem Haken markiert sind. Wir wissen bereits, dass es sich bei diesem Haken um ein Aguila-Element des Typs agoum.bage handelt, der an Elementen des Typs agorum.cards angehängt werden kann. Soweit so schön, kann man vielleicht mal in eigenen Card-Widgets gebrauchen ^^.


    Aber was möchte uns das Information Center damit sagen, wenn dessen Cards mit diesem Haken-Bage markiert werden?


  • Virtual Appliance Upgrade

    Wir dockern unsere Agorum-Umgebung. Das Prinzip ist da ähnlich.


    Im Endeffekt definieren wir uns ein Dockerfile, nehmen ein x-beliebiges Linux-Image als Grundimage und installieren die von Agorum zusätzlich benötigten Komponenten wie z.B. LibreOffice hinein. Damit erzeugen wir uns dann ein Docker-Image, damit dann einen Container und mounten da ganz einfach /opt/agorumcore als Volume hinein und starten dann Agorum über das Startscript im Container. In /opt/agorumcore scheint alles enthalten zu sein, was Agorum benötigt um grundsätzlich lauffähig zu sein, von ein paar zusätzlichen Tools wie LibreOffice mal abgesehen, aber Agorum würde auch ohne diese erstmal starten.

    Persönlich ausprobiert habe ich es nicht, aber da es mit Docker super klappt, sollte auch das Kopieren von /opt/agorumcore auf einer VM zu einer anderen VM theoretisch genauso funktionieren. Versuch macht klug ;)

  • Rest Api

    Metadaten werden nur ausgespuckt, wenn diese mit dem query-parameter "properties" angefragt werden.

    properties=~ gibt alle Metadaten aus (..naja, zumindest die selbst definierten und grundlegende wie area,identifier),

    properties=~metadatum spuckt ein bestimmtes Metadaten aus.


    Die Tilde (~) signalisiert in der API, dass es sich um ein Metadatum handelt. Denn mit properties können auch Objektdaten wie "name" oder "description" abgefragt werden, die werden dann ohne Tilde angegeben.


    Auch vielleicht noch wissenswert, "properties" kann mehrfach angegeben werden, um weitere Einzelwerte abzufragen.

  • Anzahl der Zookeeper-Logfiles bschränken

    Guten Morgen!

    Ich möchte dieses Thema mal aufgreifen, denn dieses Zookeeper-Verhalten ist wirklich ziemlich doof für die Datensicherung. Unsere Produktivumgebung ist ebenfalls gedockert, das Docker-Volume welches die Zookeeper-Daten enthält ist ein Bind Mount, sodass die Zookeeper Dateien im Endeffekt im Dateisystem des Docker-Host liegen. Hierbei handelt es sich eine ext4-Partition.


    Bei ext4 nutzt Zookeeper offenbar irgendwelche Techniken des Dateisystems, damit die Dateien im Dateisystem deutlich weniger phyischen Speicherplatz belegen, als sie vorgeben.


    Außerhalb des data-Ordner ist mit du ist zu sehen, dass nur 92MB phyischer Speicherplatz benötigt wird:

    Code
    [root@1a0a7df858a3 zookeeper]# cd /opt/agorum/agorumcore/zookeeper/data/
[root@1a0a7df858a3 data]# du -sh *
92M     version-2
4.0K    zookeeper_server.pid



    Schauen wir uns die Dateien mit ls im version-2-Ordner an, sehen wir jedoch, dass jede Datei so aussieht, als sei sie 64MB groß.



    Welche ext4-Magie Zookeeper da für dieses Phänomen verwendet macht weiß ich genauso wenig wie unsere Backup-Software ^^. Die sichert nämlich stets die 64MB pro Datei. Und von denen haben wir im Produktivsystem mittlerweile 1092 Stück. Das macht aktuell: 1092 * 64MB / 1024 = 68GB Overhead im Backup, Tendenz steigend. Und dieser würde im Restore-Fall auch wieder zurückgespielt werden.


    Uns ist dieses Problem bereits seit 1,5 Jahren bekannt und wir standen bereits mit dem Agorum-Support in Kontakt. Wir hatten zuletzt die Empfehlung erhalten folgende (die letzten 4 Zeilen) Einstellungen in der zoo.cfg zu tätigen, die wohl von Agorum mittlerweile getestet und freigegeben wurden:

    Code
    tickTime=2000
dataDir=/opt/agorum/agorumcore/jboss/server/default/../../../zookeeper/data
clientPort=9981
minSessionTimeout=60000
maxSessionTimeout=120000
snapCount=100
preAllocSize=1M
autopurge.snapRetainCount=3
autopurge.purgeInterval=12


    Das ist nun ziemlich genau 7 Tage her, bisher haben sich die Log-Dateien noch nicht reduziert. Müssen wir einfach noch länger warten oder hätte sich in der Zeit schon etwas tun müssen?

  • MySQL 5.7 EOL - Versionsupgrade?

    Das ist mir bewusst, tatsächlich habe ich neulich erst den MySQL 5.7 - Server unserer Testumgebung zu einem MariaDB 10.11 migiert, indem ich einfach das mysql-Datadir umgehängt und mit mariadbupgrade aktualisiert habe. Einfach nur um mal zu schauen, ob das funktioniert. Agorum startete ohne irgendeine Konfigurationsänderung (diese Agorum-Instanz lief auf dem Standardtreiber).


    Dennoch würde ich für die Produktivumgebung die MySQL-Version vorziehen, die auch von Agorum empfohlen wird. Einfach weil ich dadurch bei Fragestellungen oder gar Notfällen welche die Datenbank betreffen bessere Supportunterstützung durch Agorum erhoffe. Ja ich weiß, Agorum stellt offiziell keinen Support für das Datenbanksystem, aber sicherlich sind trotzdem Erfahrungswerte vorhanden auf die zugegriffen werden kann.

  • MySQL 5.7 EOL - Versionsupgrade?

    Guten Tag,


    Da ihr ja mittlerweile so ein schönes aktives Forum habt, dachte ich mir, dass man solche allgemeine Themen vielleicht auch hier anfragen kann :).


    Ich wollte mich mal erkundigen, wie es mit der Unterstützung von neueren MySQL-Versionen aussieht. Hintergrund ist, dass der Support von MySQL 5.7 zum 23.10.2023 endet, sprich ab dann auch keine Sicherheitsupdates mehr erhalten wird.


    Soweit eure Doku dazu noch aktuell ist, liefert ihr Agorum nach wie vor mit MySQL 5.7 aus. Auch wir hatten unsere Echtumgebung vor 2,5 Jahren (..unglaublich wie die Zeit vergeht) aufgrund dieser Empfehlung mit einer externen MySQL 5.7-Datenbank aufgesetzt und laufen seit dem auf 5.7. Nun müssen wir angesichts des bevorstehenden Supportendes bald Upgraden.


    Ich nehme an, dass auch ihr bald ganz offiziell Agorum mit einer höheren MySQL-Version ausliefern werdet, gibt es dazu schon Details welche es werden wird? Wir würden uns zumindest bei unserer Echtumgebung auch weiterhin nach eurer Versionsempfehlung richten wollen.


    Gruß,

    Dominik