Beiträge von volker.trotte

Ich denke hier werden die verschiedenen Möglichkeiten sehr gut erklärt:
(aus: https://stackoverflow.com/ques…ly-set-path-on-linux-unix)

Zitat von stackoverflow

There are multiple ways to do it. The actual solution depends on the purpose.

The variable values are usually stored in either a list of assignments or a shell script that is run at the start of the system or user session. In case of the shell script you must use a specific shell syntax and export or set commands.

System wide

1. /etc/environment List of unique assignments. Allows references. Perfect for adding system-wide directories like /usr/local/something/bin to PATH variable or defining JAVA_HOME. Used by PAM and systemd.
2. /etc/environment.d/*.conf List of unique assignments. Allows references. Perfect for adding system-wide directories like /usr/local/something/bin to PATH variable or defining JAVA_HOME. The configuration can be split into multiple files, usually one per each tool (Java, Go, and Node.js). Used by systemd that by design do not pass those values to user login shells.
3. /etc/xprofile Shell script executed while starting X Window System session. This is run for every user that logs into X Window System. It is a good choice for PATH entries that are valid for every user like /usr/local/something/bin. The file is included by other script so use POSIX shell syntax not the syntax of your user shell.
4. /etc/profile and /etc/profile.d/* Shell script. This is a good choice for shell-only systems. Those files are read only by shells in login mode.
5. /etc/<shell>.<shell>rc. Shell script. This is a poor choice because it is single shell specific. Used in non-login mode.

User session

1. ~/.pam_environment. List of unique assignments, no references allowed. Loaded by PAM at the start of every user session irrelevant if it is an X Window System session or shell. You cannot reference other variables including HOME or PATH so it has limited use. Used by PAM.
2. ~/.xprofile Shell script. This is executed when the user logs into X Window System system. The variables defined here are visible to every X application. Perfect choice for extending PATH with values such as ~/bin or ~/go/bin or defining user specific GOPATH or NPM_HOME. The file is included by other script so use POSIX shell syntax not the syntax of your user shell. Your graphical text editor or IDE started by shortcut will see those values.
3. ~/.profile, ~/.<shell>_profile, ~/.<shell>_login Shell script. It will be visible only for programs started from terminal or terminal emulator. It is a good choice for shell-only systems. Used by shells in login mode.
4. ~/.<shell>rc. Shell script. This is a poor choice because it is single shell specific. Used by shells in non-login mode.

Übersetzt:

Zitat

Es gibt verschiedene Möglichkeiten, wie Umgebungsvariablen gesetzt werden können. Die tatsächliche Lösung hängt vom Zweck ab.

Die Werte der Variablen werden normalerweise entweder in einer Liste von Zuweisungen oder in einem Shell-Skript gespeichert, das beim Start der System- oder Benutzersitzung ausgeführt wird. Bei einem Shell-Skript muss eine spezielle Shell-Syntax sowie die Befehle export oder set verwendet werden.

Systemweit

• /etc/environment: Liste von eindeutigen Zuweisungen. Erlaubt Referenzen. Perfekt, um systemweite Verzeichnisse wie /usr/local/something/bin zur PATH-Variablen hinzuzufügen oder JAVA_HOME zu definieren. Wird von PAM und systemd verwendet.
• /etc/environment.d/*.conf: Liste von eindeutigen Zuweisungen. Erlaubt Referenzen. Perfekt, um systemweite Verzeichnisse wie /usr/local/something/bin zur PATH-Variablen hinzuzufügen oder JAVA_HOME zu definieren. Die Konfiguration kann auf mehrere Dateien aufgeteilt werden, normalerweise eine pro Tool (Java, Go, Node.js). Wird von systemd verwendet, gibt diese Werte jedoch standardmäßig nicht an Benutzer-Login-Shells weiter.
• /etc/xprofile: Shell-Skript, das beim Start der X Window System-Sitzung ausgeführt wird. Es wird für jeden Benutzer ausgeführt, der sich in das X Window System einloggt. Eine gute Wahl für PATH-Einträge, die für jeden Benutzer gültig sind, wie /usr/local/something/bin. Die Datei wird von einem anderen Skript eingebunden, daher sollte die POSIX-Shell-Syntax und nicht die Syntax der Benutzershell verwendet werden.
• /etc/profile und /etc/profile.d/: Shell-Skript. Eine gute Wahl für rein Shell-basierte Systeme. Diese Dateien werden nur von Shells im Login-Modus gelesen.
• /etc/<shell>.<shell>rc: Shell-Skript. Eine schlechte Wahl, da sie spezifisch für eine einzige Shell ist. Wird im Nicht-Login-Modus verwendet.

Benutzersitzung

• ~/.pam_environment: Liste von eindeutigen Zuweisungen, keine Referenzen erlaubt. Wird von PAM beim Start jeder Benutzersitzung geladen, unabhängig davon, ob es sich um eine X Window System-Sitzung oder eine Shell handelt. Sie können keine anderen Variablen, einschließlich HOME oder PATH, referenzieren, daher ist die Verwendung eingeschränkt. Wird von PAM verwendet.
• ~/.xprofile: Shell-Skript. Wird ausgeführt, wenn sich der Benutzer in das X Window System einloggt. Die hier definierten Variablen sind für jede X-Anwendung sichtbar. Perfekte Wahl, um PATH mit Werten wie ~/bin oder ~/go/bin zu erweitern oder benutzerspezifische Werte wie GOPATH oder NPM_HOME zu definieren. Die Datei wird von einem anderen Skript eingebunden, daher sollte die POSIX-Shell-Syntax verwendet werden. Ihr grafischer Texteditor oder IDE, die per Verknüpfung gestartet werden, sehen diese Werte.
• ~/.profile, ~/.<shell>_profile, ~/.<shell>_login: Shell-Skript. Es wird nur für Programme sichtbar sein, die vom Terminal oder Terminal-Emulator aus gestartet werden. Eine gute Wahl für rein Shell-basierte Systeme. Wird von Shells im Login-Modus verwendet.
• ~/.<shell>rc: Shell-Skript. Eine schlechte Wahl, da es spezifisch für eine einzige Shell ist. Wird von Shells im Nicht-Login-Modus verwendet.

StefanF

Möglicherweise sind deine Pfade in Dateien hinterlegt, die bei einem Update vom Linux überschrieben werden?

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/)