Beiträge von volker.trotte

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

    StefanF Was genau ist denn das Problem/das Ziel?
    In welchen "Configurations" haben Sie was genau gesucht?


    "Active Modules" finden sich althergebracht im Supporttool. Dort können diese ein/ausgeschaltet werden.
    Ohne genauere Angebn wird es leider schwer zu helfen.

    KStoehr

    zu 1.
    In der 7.8.15 gabs den auf jeden Fall schon.
    Daher würde ich vermuten, dass es den in der 7.7 auch schon gegeben haben sollte

    Versuch doch einfach mal, von einem anderen ocr die exe zu kopieren - vielleicht gehts ja.

    zu 2.
    Nicht zwangsläufig. Jedoch gab es in den letzten Jahren ab und zu explizit anpassungen auf der Seite der ocr engine.
    Das stand immer im changelog. Vermutlich wird aber eine 11er OCR nicht mit dem 7er agorum zusammenarbeiten.

    Hallo @Katrin,

    das unterbinden des verschiebens ist ein wenig tricky, aber es geht mit Systemflags


    Hier ist die Doku dazu:

    DISALLOW_ITEM_REMOVE64Verhindert das Entfernen von Objekten aus einem Ordner.



    Hinweis: Das Systemflag muss sowohl für den Ordner als auch für die Objekte innerhalb dieses Ordners gesetzt sein, die nicht entfernt werden dürfen.

    Quelle


    LG
    Volker

    Hallo JanR

    bzgl. "ist das agorum fertig hochgefahren"

    Das agorum ist dann vollständig einsatzbereit, wenn die Rest-API fertig geladen ist. Du könntest also mit einem Script einfach aller paar Minute/Sekunden einen simplen api Aufruf tätigen - das wäre ein Ansatz.


    Bzgl. log und Problemursache:


    ich habe folgende 3 aufeinanderfolgende Zeilen im Log gefunden:


    2023-05-23 07:24:39,743 WARN [org.jboss.resource.connectionmanager.TxConnectionManager] Prepare called on a local tx. Use of local transactions on a jta transaction with more than one branch may result in inconsistent data in some cases of failure.

    2023-05-23 07:38:47,138 INFO [STDOUT] SEQ ejbPassivate

    2023-05-23 07:45:40,427 INFO [org.apache.struts.util.PropertyMessageResources] Initializing, config='org.apache.struts.taglib.logic.LocalStrings', returnNull=true


    Wenn du dir die zeitstempel anschaust siehst du, dass zwischen 7 und 14 Minuten! zwischen diesen beiden Einträgen liegen.

    Das ist sehr wahrscheinlich kein singuläres agorum problem.


    "Waiting until the server becomes available" sagt, soweit ich das weiss, eigentlich nur aus, dass das System noch startet und du bitte solange warten sollst.
    Die Weboberfläche ist dann fertig einsatzbereit , wenn im log so etwa in der Art auftaucht: "... published to /rest". Bis dahin ist der Server unavailable.
    Das Problem liegt irgendwo anders.

    Vielleicht im zugrundeliegenden filesystem/storage. Vielleicht ist auch die FP voll?
    Selbst unserer größten System starten das agorum innerhalb von 5 Minuten.


    Wir müssten mehr über die zugrundeliegende Konfig wissen. Im Rahmen des Forums wird es schwierig deine Fragen zu beantworten.

    Ich habe das gerade mal nachgestellt:
    Ein Dokument A erstellt mit einem nicht-admin user,

    Diesem Dokument die ACL Published zugewiesen. somit hat er nur read-Rechte.

    In Version 11.2.2 kann der user über die Standard-rechtsklickaktionen das Dokument nicht mehr löschen.

    Im Desk4Web wird das Dokument via "ACL-Überwachung" als grün markiert. Demnach ein all-Recht.

    In der entsprechenden Doku dazu findet sich auch folgender Satz:


    Zitat

    Hinweis: Der Objekt-Owner (Besitzer) hat immer Vollrechte an diesem Objekt, egal welche Berechtigung auf dem Objekt gesetzt ist.

    Quelle


    Dazu ein Screenshot aus dem d4w

    Technisch gesehen kann der user das Dokument auch selbst löschen


    Code
    /* global sc */
    
    
    let objects = require('common/objects');
    let testUserSc = sc.asUser(objects.find('user:bes.test'));
    let testobjects = require('common/objects')(testUserSc);
    let metadata = require('common/metadata');
    
    
    testobjects.find('/agorum/roi/Files/Demo/Willkommen (1).pdf').mayDelete; // ergibt true

    Allerdings bringt

    Code
    let testUserSc = sc.asUser(objects.find('user:bes.test'));
    let testobjects = require('common/objects')(testUserSc);
    let testobjektAlsTestUser = testobjects.find('/agorum/roi/Files/Demo/Willkommen (1).pdf');
    testobjects.trash(testobjektAlsTestUser);

    einen Fehler:

    Code
    org.mozilla.javascript.WrappedException: Wrapped agorum.roi.exception.RoiException: No Access (objects.js#768)


    Damit ist dann wohl die Doku eindeutig veraltet :)




    Eine kurze Ergänzung der Vollständigkeit halber :)

    Für den unwahrscheinlichen Fall, dass der User nur ein read-recht (oder write-recht) auf Dokument A hat, zugleich aber dessen Ersteller (creator) ist, kann er das Dokument auch löschen.


    So hat man mir das mal erklärt :)

    Ich habe es jetzt gerade nicht testen können, meine aber das es noch immer so ist.

    Hallo KStoehr,


    du könntest quick & dirty:

    Code
    let results = objects
    .query('name:test')
    .filter('inpath:9999', 'nameextension:pdf')
    .sort('contentsize desc')
    .limit(5)
    .find();

    in der Javascript Console nutzen.
    Quelle


    Willst du die Suche verwenden, musst du eine Smart Assistant konfigurations Liste verwenden, die als Metadatum die contentSize verwendet und deinem Filter sagen, er soll diese Liste verwenden. Dann kannst du nach der contentSize sortieren

    etwa so:

    Code
     listType: 'explorer',
      list: 'Standard',

    Quelle

    @Jan.


    Zitat

    PS Wie ist das denn, meinetwegen auch in der Bezahlversion, gelöst? Oder klicken ALLE agorumcore-Kunden die Sicherheitswarnungen weg bzw. installieren sich das enthaltene Zertifikat als vertrauenswürdige Stammzertifizierungsstelle. Wäre ja beides nicht so unbedingt optimal.

    Die meisten größeren Kunden (bei uns) haben über ihr Active Directory einfach eine eigene Stammzertifizierungsstelle aufgebaut (geht relativ einfach) und haben das Zertifikat dann via AD auf alle clients verteilt. und einmalig im agorum eingespielt.

    Zitat

    Aber der Transfer in den agorumcore-Webserver ist ja offensichtlich aktuell nur manuell möglich.

    Alle Schritte die du grad gemacht hast, dürften auch automatisierbar sein. Das ist ja das schöne bei Linux.

    einfach ein entsprechendes shell-script bauen und und per crontab o.ä. einbinden.

    volker.trotte Hier scheint die Doku nicht zu stimmen (auch wichtig für Euch, Oliver Kaufmann , denke ich):

    Ist ja kein Windows, sondern ein 🐧.

    Habt Ihr für mich hier den richtigen Befehl griffbereit?

    Edit: Der dürfte es sein ".\keytool -keypasswd -alias tomcat -keystore /root/.keystore" (Aber die Doku passt dann trotzdem nicht!)

    Der Befehl ist schon der richtige, nur der Pfad ist in der falschen form angegen. müsste wohl

    Code
    keytool -keypasswd  -alias <key_name> -keystore my.keystore


    Code
    /root/keystore

    lauten




    Edit: ahh erst jetzt gesehen, dass es dir schon aufgefallen ist :)

    JanR

    Soweit ich weiss, muss das neue Zertifikat das alias "tomcat" haben.
    Dazu musst du natürlich zuerst das alte zertifikat mit alias "tomcat" entfernen um dann das neue entsprechend hinzufügen zu können, da der alias unique sein muss.

    Gut möglich, dass du dein *.pem-Zertifikat vorher in *.pfx konvertieren musst:

    Code
    openssl pkcs12 -inkey bob_key.pem -in bob_cert.cert -export -out bob_pfx.pfx

    Quelle...

    1. Importieren Sie das Zertifikat mit folgendem Befehl:
      Code
      ./keytool -importkeystore -srckeystore ihr-zertifikats-file.pfx -srcstoretype pkcs12 -destkeystore /root/.keystore
      Ergebnis: Nach erfolgreichem Import wird der alias des soeben importierten Zertifikats in der Konsole ausgegeben. Diesen alias benötigen Sie für Schritt 3.
    2. Löschen Sie das vorhandene (alte) Zertifikat mit dem alias tomcat mit folgendem Befehl:
      Code
      ./keytool -delete -alias tomcat -keystore /root/.keystore
    3. Benennen Sie den Zertifikats-alias in tomcat mit folgendem Befehl um. Als keystore-Password geben Sie changeit ein, als zweites Passwort das Passwort des Zertifikats:
      Code
      ./keytool -changealias -alias alias-des-importierten-zertifikats -destalias tomcat -keystore /root/.keystore
    4. Ändern Sie das Passwort des Zertifikats in changeit mit folgendem Befehl und verwenden Sie folgende Passwörter:
      Code
      .\keytool -keypasswd -alias tomcat -keystore c:\Windows\System32\config\systemprofile\.keystore


      Passwort des Keystores

      changeit



      Passwort des Private Keys

      Ihr-Passwort



      Zweimalige Eingabe des neuen Passworts

      changeit
    5. Starten Sie agorum core neu.




    Doku siehe auch hier

    Guten Morgen Lily,
    Dokumente können wie folgt heruntergeladen werden:


    Der Link lädt das Dokument direkt vom agorum core-Server im Original herunter. Dabei können Sie die ID oder UUID (empfohlen) angeben.

    Code
    http://agorum-core-server/api/rest/object/download/[ID oder UUID]

    Falls Sie das Dokument im Browser nur anzeigen und nicht herunterladen möchten, führen Sie nachfolgenden Aufruf aus, etwa für Bilder oder PDF-Dateien:

    Code
    http://agorum-core-server/api/rest/object/embed/[ID oder UUID]


    Weitere Infos: Doku Dateidownload

    Zitat

    Remote document service server is configured, but login is not possible

    Klassischer Punkt sind da auch fehlende Firewall Regeln.

    • Auf dem Server, auf dem die agorum core ocr engine installiert ist, muss der Port 8080 (TCP) freigeschaltet sein, da der Dienst AgorumDocumentService standardgemäß diesen Port verwendet (Einstellungen siehe Firewall konfigurieren).

    Link zur Doku