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.

    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.


    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.

    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

    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:


    Dokumentation agorum core


    Mit diesem Ansatz sind Sie voll flexibel.

    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.

    Code
    ./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.

    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:

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

    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?

    Zitat

    Aktuell teste ich pgadmin 4 zum Zugriff auf die Datenbank, bekomme aber keine Verbindung. Im Plesk-Datenbankserver ist für die PostgreSQL-Datenbank der Remote-Zugriff freigegeben. Im agorum Datenblatt steht nur localhost und Port 5432. Zudem möchte pgadmin den Namen einer "Wartungsdatenbank" haben (Standardname postgres). Ich denke die agorum-DB hat einen anderen Namen, der leider in Plesk nicht angezeigt wird. Kann es auch sein, das der Remote-Zugriff auf die Datenbank noch anderweitig freigegeben werden muss?.Das agorum core selbst gestoppt sein muss, ist logisch.

    Wie mysql hat auch postgres seine eigene "Standarddatenbank", die es selbst benötigt.

    Die Datenbank oder bei Postgress besser das "Schema" von agorum heisst immer "roi"

    Wenn du pgadmin4 verwendest, dann sicherlich von deinem Client aus, da kann dann natürlich nicht "localhost" als ip/dns verwendet werden.
    Vielmehr muss der die Server-IP angegeben werden, dazu muss noch einiges sichergstellt werden , damit eine remoteverbindung (von extern via pgadmin 4 auf den Server) auch klappen könnte.

    Besser kommst du, in dem du auf der shell dich direkt mit der Datenbank verbindest und dort dann z.B. einen pgdump zum Export der Daten anstößt.

    Wie gesagt, kannst du allerdings auch einfach die PostgressDatenbank kopieren und somit sichern - sofern die DB vorher gestoppt wurde.

    Bleibt die Sicherung der PostgreSQL-Datenbank. Bei deinem Link ist leider eine Anmeldung nötig, für die ich keine Zugangsdaten habe. Kann es sein, das dafür die Pro-Version nötig ist? Vielleicht ist die Lösung aber auch einfacher. Mir reicht die Datensicherung bei gestopptem agorum core. Wenn dann alle Dateien gesichert werden, ist dann nicht die DB automatisch mit gesichert? Oder habe ich da einen Denkfehler?

    floriani Wichtig ist in diesem Backupszenario vor allem, dass sowohl agorum als auch die Datenbank gestoppt ist - nur dann kann die Datenbank als solche kopiert und gebackupt werden. Statt zu kopieren, würde es auch ein richtiger Datenbankdump tun. Je nach dem was schneller ist (in beide Richtungen (Backup/Restore)) sollte der passende Weg gewählt werden. Wichtig ist ja auch, dass das System schnell wieder herstellbar ist (das sollte auf jeden Fall getestet werden!).


    Normalerweise schlagen wir eigentlich ein Backup der ganzen VM vor, da dies i.d.R. am leichtesten von der Hand geht (in beide Richtungen). Das wird vermutlich aber in diesem Kontext nicht so einfach machbar sein.
    Allerdings hätte es den Charme, dass dann halt auch der komplette Server gebackupt ist, mit allen Wordpress-Geschichten und dem Plesk.

    Kurz zusammengefasst:
    * Es gibt keine Standardoberfläche um Dokumente miteinander zu verknüpfen oder zu entknüpfen - es ist auch derzeit seitens agorum nicht gelpant so eine zu bauen.

    * Verknüpfen/Entknüpfen ist aktuell nur technisch über JS möglich.