Beiträge von volker.trotte

Zitat von Lina Valantukeviciute

Hallo,

nun habe ich ein identisches Problem wie Stefan

Zitat von StefanF

Die Installation der Version 1710.bin unter Debian bricht in Zeile 215 mit folgenden Meldungen ab:

ldconfig: Kommando nicht gefunden. Libaio1 not found, please install ist, before installing agorum core on debian-bases systems, ....

libaio1 ist aber mit der aktuellsten Version installiert.

installiert wurde die Version agorum-core-server-linux-pro-11_2_3_3-1710 . Als root.

Erstmal auf Debian 12 in VMware Workstation. Nachdem ich die Beiträge gelesen hatte, versuchte ich das auf Debian 11 zu installieren, bei mir kommt aber wieder die gleiche Fehlermeldung.

Gibt es hierzu schon Hinweise, woran es liegen könnte?

Vielen Dank!

Alles anzeigen

Falls debian 12 mit netinstall iso installiert worden ist, kann es sein, dass /usr/sbin nicht im Pfad von root ist.

In diesem Fall schlägt der Aufruf (der in der agorum installation enthalten ist)

 ldconfig -p | grep libaio.so.1 | grep /lib | wc -l

fehl bzw. findet kein Ergebnis

Um das zu beheben in der .bashrc des users der die Installation vornimmt

nano ~/.bashrc

den Eintrag

export PATH=/usr/sbin:$PATH

hinzufügen.

Den user aus und wieder einloggen (damit der Pfad geladen werden kann)

und dann wieder

ldconfig -p | grep libaio.so.1 | grep /lib | wc -l

ausführen.

Das sollte "1" zurückgeben.

Dann die agorum installation starten.

StefanF Ich denke, hier wäre ein Screenshot der Suche bzw. des Suchergebnisses wichtig.

Aus der Ferne gibts es meiner Ansicht nach 2 mögliche Ursachen:
a) Das gefundene Dokument liegt in keinem Ordner (Dann kann kann kein Ordnerpfad angezeigt werden

b) Der genutzte User hat keine Berechtigung auf den Ordner bzw. einen Ordner im Orderpfad des Dokumentes (Dann wird kein Ordnerpfad angezeigt)

Zitat von Majob

Daher haben wir stattdessen zunächst die Icons in die Werte des Metadatums selbst als Unicode-Zeichen integriert 🟢=> https://www.compart.com/de/unicode/U+1F7E2. Jedoch ist die SOLR-Suche nach Metadaten, die mit einem Unicode-Icon beginnen, nicht so schön. In einem zweiten Schritt haben wir daher die Icons in separate Übersetzungsdateien ausgelagert und speichern lediglich die Übersetzungskeys als Werte am Metadatum. Mit Hilfe des etwas spärlich dokumentierten Features, Metadaten anzulegen, deren Werte vor der Anzeige übersetzt werden, ist es uns dann gelungen, die Übersetzung in die Listen-Konfiguration aufzunehmen (siehe https://agorumdocproxy.agorum.…5056aa0ecc/acds-anchor-48).

Das ist echt kreativ! Klasse Ansatz!

Hallo 0711_Rudi,

Zu 1. Gibt es eine Funktion oder Einstellung, die Dateien, welche seit 6 Monaten nicht mehr verändert wurden, automatisch in ein Verzeichnis bzw. Laufwerk X verschiebt?

Mit etwas Programmierung ist es durchaus möglich, Dateien auf ein "Laufwerk X:" (und damit raus aus agorum) zu verschieben.
So z.B: auch Betriebssystemebene über ein shell oder Bash-script.

• Wenn man das agorum Laufwerk mountet und dazu Laufwerk X kannst du ein entsprechendes Shell script bauen, dass entsprechende regelmäßig prüft und dann die Dateien verschiebt.

Alternativ kann das auch agorum direkt;

Das ist ein Beispiel um eine Datei direkt auf einen Server zu schreiben.

/* global sc, sca  */
let Files = java.nio.file.Files;
let Paths = java.nio.file.Paths;
let pipe = Packages.agorum.commons.string.StringConverterUtils.pipe;
let toStream = Packages.agorum.commons.string.StringConverterUtils.toStream;

let targetFolder = '/opt/agorum';
function writeXMLFile(name, content) {
  // Check and create file if not already exists
  let file = Paths.get(targetFolder, name);

  if (!Files.exists(file)) {
    Files.createFile(file);
  }
  // Write the content   let os = Files.newOutputStream(file);   try {     pipe(toStream(content, 'UTF-8'), os);   }
  // Write the content
  let os = Files.newOutputStream(file);
  try {
    pipe(toStream(content, 'UTF-8'), os);
  } finally {
    os.close();
  }
}
writeXMLFile('test.txt', 'mein inhalt');

Für einen Entwickler ist es recht leicht das zu erweitern und zu modifizieren um dein Ziel zu erreichen. (Dateien auf dem Zielpfad erstellen und dann in agorum löschen).

Sicherheitshalber wäre bei wichtigen Daten noch zu prüfen ob die erstellte Datei der Ursprungsdatei gleicht (z.B: über einen hash-Wert der verglichen wird)

ACHTUNG:

-> Du verlierst mit dem Löschen der Dateien in agorum natürlich alle Metadaten und Versionen. Du kannst sie dann nicht mehr per Suche finden.

-> Weiterhin bietet es sich an, wenn man größere, löschende Datenbewegungen betreibt, regelmäßig die Datenbank selbst aufzuräumen. Das gehört zur allgemeinen Systempflege dazu. Besonders empfehle ich das aber, wenn viele Daten aus der Datenbank gelöscht werden.

Sebastian Grund

Ich denke du könntest anhand einer Kombination aus JavaScript beim Öffnen von agorum core ausführen und Listen-Styles basierend auf Selektoren anpassen dein Ziel erreichen. Du könntest per JS auf deine css-Klasse reagieren und dann entsprechend alles "farbig" via JS kennzeichen, was du möchtest. Nicht schön, aber ich denke doch machbar.

Guten Morgen 0711_Rudi,
funktioniert denn die Verbindung per SMB? Wurde das bereits einmal probiert?

Zitat von StefanF

Sag mal, ist die setup immer noch nicht Debian 12 fähig? Ich bekomme die gleichen Meldungen wie noch vor über einem Jahr.

Das kann ich dir leider nicht beantworten.
Aber vielleicht annkatrin.goepfert ?

Das Verzeichnis /opt/agorum/agorumcore scheint leer zu sein.

Das zeigt die Ausgabe von

/opt/agorum/agorum ls
<hier müsste was stehen>

StefanF

sind solr und agorum version identisch?

Zitat von bkl-isos.de

Hinweis: die großen "log.abc" - Files (siehe Abbildung in #3) sind laut "roi" keine Logdateien, sondern enthalten die Index-Daten für solr! Diese sollte man auf keinen Fall löschen. Eventuell gibt es ja noch irgendeine andere Möglichkeit, um den Speicherplatz zu reduzieren.

Das dürfte die transaction logs für zookeper sein:

The Log Directory

The Log Directory contains the ZooKeeper transaction logs. Before any update takes place, ZooKeeper ensures that the transaction that represents the update is written to non-volatile storage. A new log file is started each time a snapshot is begun. The log file's suffix is the first zxid written to that log.

https://zookeeper.apache.org/d…than%20the%20data%20files.

Hallo floriani,

das SSL-zertfiikat von Letsencrypt muss in den java-keystore von agorum übernommen werden. Dafür gibt es keinen vorgefertigten Automatismus, insbesondere nicht, wenn ihr LetsEncrypt verwendet und somit aller 3 Monate ein neues Zertifikat bekommt.
Verwendet am besten fürs erste (manuelle) Mal die folgende Anleitung:
https://agorumdocproxy.agorum.…75-11e7-a23e-005056aa0ecc
Achtet dabei bitte genau auf die Anleitung. Passwort für den keystore von agorum ist "changeit" und der alias für das Zertifikat muss zwingend "tomcat" sein.

Aus dieser lässt sich dann auch ein Script ableiten, dass das SSL-Script automatisch erneuert.

Ich hoffe das hilft euch weiter!

Hallo cordeshosting

Sollte der Download nach außen hin freigegeben werden (also im internet stehen) ist ein reverse proxy zu Verwendung empfohlen.
z:B. apache oder nginx

<VirtualHost *:80>
  ...

  RewriteEngine On

  ProxyPass /agorum-download/ http://interne-agorum-ip/api/object/download/
  ProxyPassReverse /agorum-download/ http://interne-agorum-ip/api/object/download/

  RequestHeader set Authorization "Basic XJHVDJVXJHGVXHGVXHGVXHGXVHGV="
</VirtualHost>

Wird auf dem Webserver die URL http://ihr-webproxy-server/agorum-download/[ID oder UUID] aufgerufen, so findet ein interner Proxy-Aufruf der internen agorum-core-Download-URL statt.

Dabei wird immer ein Request-Header mit Benutzername und Kennwort eines technischen agorum core-Benutzers mitgeschickt, codiert als BASE64. Dieser Header ist lediglich intern sichtbar und wird nie nach außen gegeben, der Aufrufer bekommt davon nichts mit.

Durch diesen gezielten Proxy wird der Aufruf ausschließlich auf den Download-Teil der agorum core-API beschränkt und intern ausschließlich mit den Rechten des technischen Benutzers gearbeitet.

Bitte dabei dir Doku beachten: https://agorumdocproxy.agorum.…5056aa0ecc/acds-anchor-12

Steht der Server intern, dann kann man das natürlich entweder genauso machen oder alternativ einen eigenen api-Service bereitstellen, der auf Basis einer ID/uuid einen Download startet. DIes geht auch ohne login:

Dateien können Sie über den CustomService zum Download bereitstellen.

Methode    Header
GET    Accept: application/octet-stream
Beispiel
/* global request */

let objects = require('common/objects');

let obj = objects.find('id-eines-dokumentes');

let response = {
  body: obj.contentStream,
  name: obj.name,
  size: obj.contentSize,
  type: obj.format.mimeType
};

response;

Dokumentation agorum core

Mit diesem Ansatz sind Sie voll flexibel.

cordeshosting
Der Download eines Objektes geht über den Aufruf von:

'/api/rest/object/download/' + object;

wobei das letzte "object" die id des Objektes ist.

Gerne kannst du auch hier schauen:
https://agorumdocproxy.agorum.…05056aa0ecc/acds-anchor-4

Zitat von Martin

Moin Herr Trotte!

Danke für die Info. Haben nachgeschaut und gefunden, dass der RAM-Speicher zu klein in agorum angegeben war. Nachdem wir den erhöht hatten lief alles super.

Dankeschön für Ihre schnelle Hilfe/Antwort.

MFG
Martin

Alles anzeigen

Dann weiterhin viel Spaß mit agorum Martin

Moin Martin,

Gibt es dazu Fehlermeldungen aus dem Supporttool?

Gut möglich, dass diese nicht als "Sticky" (rote und sehr offensichtliche) Meldungen ausgegeben werden - da müssten du ein wenig schauen.

NorbertK

Ich habe früher tatsächlich agorum auf postgresql und mit proxmox-virtualisiert betrieben.
Zuletzt hatten wir auch einen Kunden, wo ZFS als Dateisystem interessant war und vielleicht auch wieder wird.

Einzig mit originalem RedHat hatte ich noch nichts am Hut, aber mit CentOs, dass ja quasi ein kostenfreier "Fork" ist/war. Daher dürfte sich nichts großartig zwischen den beiden unterscheiden.

Hallo Reinhard,

wir verwenden tatsächlich i.d.R. strikt die Doku von agorum
Nur den csr passen wir an, damit wir ein für Chrome gültiges SSL-Zertifikat bekommen.

./keytool -genkey -alias tomcat -keyalg RSA -keysize 2048 -keystore /root/.keystore
./keytool -certreq -alias tomcat -file request.csr -keystore /root/.keystore

Hier müssen wir explizit das -alias tomcat mitführen.

Zitat von volker.trotte

floriani

Das Problem mit "verschwundenen" Portfreigaben ergibt sich utner Linux häufiger aus der Fall heraus, dass die getätigten Freigaben nur zur Laufzeit des Server/der Firewall gelten. Um diese zu dauerhaft zu speichern, bedarf es häufig (aber abhängig von der Firewalld) eines zweiten Kommandos - Nach dem Motto: Das ist die Regel, speichere diese dauerhaft.

Beispiel:

Um einen neuen Dienst zu einer Zone hinzuzufügen, steht folgender Befehl zur Verfügung:

Code

firewall-cmd --zone=public --add-service=https




Um einen Dienst auch permanent hinzuzufügen, also auch beim Neustart von firewalld:

Code

firewall-cmd --zone=public --permanent --add-service=https




(Auszug aus https://www.security-insider.d…und-einrichten-a-1071233/)

Alles anzeigen

floriani

Das Problem mit "verschwundenen" Portfreigaben ergibt sich utner Linux häufiger aus der Fall heraus, dass die getätigten Freigaben nur zur Laufzeit des Server gelten. Um diese zu dauerhaft zu speichern, bedarf es häufig (aber abhängig von der Firewalld) eines zweiten Kommandos - Nach dem Motto: Das ist die Regel, speichere diese dauerhaft.

Beispiel:

Um einen neuen Dienst zu einer Zone hinzuzufügen, steht folgender Befehl zur Verfügung:

firewall-cmd --zone=public --add-service=https

Um einen Dienst auch permanent hinzuzufügen, also auch beim Neustart von firewalld:

firewall-cmd --zone=public --permanent --add-service=https

(Auszug aus https://www.security-insider.d…und-einrichten-a-1071233/)

Hallo Reinhard

hast du eine Aktion im Supporttool ausgeführt, in deren Folge die Meldung "Unable to import certificate: Keystore was tampered with, or password was incorrect" auftrat?

Wichtig im Sinne des SSL bei agorum ist, dass bei der manuellen "keystore"-Behandlung immer "tomcat" als alias für das Zertifikat zu verwenden ist.
Weiterhin ist es so (meines Wissens nach), dass das CSR,d as agorum erstellt kein "SAN" (Subject Alternative Name) enthält. Damit wird das Zertifikat für chromium-basierte Browser (chrome, edge..) als ungültig angezeigt.
Wir sind da bisher nur drum herum gekommen, in dem wir

a) manuell ein eigenes csr erstellt haben

b) direkt (ohne CSR) ein Zertifikat von der lokalen CA ausgestellt haben.

Vielleicht hilft das ja?