Ruhiges IT-Forum

WAPT Discovery -- 2.6.1.17472 -- SRV Ubuntu 24.04

Guten Morgen,

Ich hatte einen WAPT-Server in der Oracle Cloud auf einer Micro-x64-Instanz (1/8 CPU / 1 GB RAM) eingerichtet. Alles funktioniert einwandfrei, nur dass man aufgrund der Serverleistung etwas mehr Geduld haben muss (Limit der Upload-Bandbreite: 50 Mbit/s).
Ich wollte den Server auf eine arm-x64-Instanz migrieren (bessere Leistung und 1 Gbit/s/CPU Bandbreite).

Also habe ich ein Backup erstellt

Code: Alle auswählen

/opt/wapt/conf
/opt/wapt/waptserver/ssl
/var/www/wapt*
/var/www/*.json

und die Datenbank sichern.

Ich habe die Installation auf der arm64 VM gestartet, aber es scheint ein Problem mit dem Postconf-Skript zu geben:

Code: Alle auswählen

root@xxxx:/opt/wapt/waptserver/ssl# /opt/wapt/waptserver/scripts/postconf.sh
/opt/wapt/waptserver/scripts/postconf.sh: line 12: 20784 Segmentation fault      (core dumped) NCURSES_NO_UTF8_ACS=1 PYTHONPATH=/opt/wapt /opt/wapt/bin/python -I /opt/wapt/waptserver/scripts/postconf.py $@

Nach meinen Recherchen stürzt es in der neuen Python 3.10-Umgebung beim Importieren von "setuphelper" in postconf.py ab. (Aber ich irre mich wahrscheinlich und habe das nicht weiter untersucht.)

Um da rauszukommen, habe ich alles deinstalliert und die neueste Version 2.5 installiert, und es gab keine Probleme.
Ich bin ausgewandert

Code: Alle auswählen

/opt/wapt/conf
/opt/wapt/waptserver/ssl
/var/www/wapt*
/var/www/*.json

Die Wiederherstellung der Datenbank schlägt jedoch fehl (wahrscheinlich nicht die gleichen Schemas, da ich die neueste Version 2.6 verwendet habe)

Ich habe also den Server mit der neuesten Version 2.5 am Laufen, ich habe die Serverkonfiguration, meine Pakete und die Hostdateien wiederhergestellt, aber das Konsoleninventar bleibt leer (weil keine Datenbankwiederherstellung erfolgt?) und ich kann dann aufgrund eines Fehlers während der Postkonfiguration nicht auf die neueste Version 2.6 aktualisieren.

(Um einen Rechner mit Agent 2.6 neu zu registrieren, habe ich bisher keine andere Lösung gefunden, als einen waptagent 2.5 neu zu generieren und mit "wapt-get install --force" den installierten Agent 2.6 zu überschreiben. Dafür muss ich jedoch jeden Rechner einzeln aufsuchen.)

Kommandant.

Guten Morgen,

Ich bin zurück mit ein paar weiteren Ideen, auch wenn ich keine Lösung habe (und ich würde sowieso keine finden ^^)

Das Problem nach der Konfiguration, das zu einem Absturz mit der Meldung "segfault" führt, tritt also tatsächlich schon ab der ersten Version 2.6.1 auf.
Ich habe versucht, postconf.py mit jeder Python-Umgebung zu starten (nun ja, ich bin kein Entwickler... ich werde wahrscheinlich einige dumme Dinge sagen, aber egal)

Code: Alle auswählen

/opt/wapt/bin/python3.10
/opt/wapt/bin/python3.9
/opt/wapt/bin/python*oopsjesaisplusdsl*

Aber ich erhielt beim Testen denselben Speicherfehler.

Kurz gesagt, ich habe die neueste Version 2.6.0 (wapt-2.6.0.17392-0ac7bf48) installiert

Code: Alle auswählen

cd /tmp

wget https://wapt.tranquil.it/wapt/releases/wapt-2.6.0.17392-0ac7bf48/tis-waptsetup-windows-2.6.0.17392-0ac7bf48-debian-10-amd64.deb
wget https://wapt.tranquil.it/wapt/releases/wapt-2.6.0.17392-0ac7bf48/tis-waptserver-2.6.0.17392-0ac7bf48-arm64.deb

apt install ./tis-waptserver-2.6.0.17392-0ac7bf48-arm64.deb ./tis-waptsetup-windows-2.6.0.17392-0ac7bf48-debian-10-amd64.deb

Anschließend habe ich Folgendes ausgeführt:

Code: Alle auswählen

/opt/wapt/waptserver/scritp/postconf.sh -s

derjenige, der damit beginnen konnte.

Allerdings gab es in dieser Version bereits am Ende der Postconf ein Problem, das ich zuvor schon einmal umgehen/lösen konnte.
Es war ganz eindeutig:

Code: Alle auswählen

Output:Traceback (most recent call last):
  File "/opt/wapt/wapt-scanpackages.py", line 140, in <module>
    main()
  File "/opt/wapt/wapt-scanpackages.py", line 101, in main
    res2 = len(update_packages_table(conf, wapt_path))
  File "/opt/wapt/wapt-scanpackages.py", line 46, in update_packages_table
    load_db_config(conf, conf.get('db_schema'))
  File "/opt/wapt/waptserver/model.py", line 105, in load_db_config
    with wapt_db:
  File "/opt/wapt/lib/python3.9/site-packages/peewee.py", line 481, in inner
    return getattr(self.obj, method)(*args, **kwargs)
  File "/opt/wapt/lib/python3.9/site-packages/peewee.py", line 3231, in __enter__
    self.connect()
  File "/opt/wapt/lib/python3.9/site-packages/playhouse/pool.py", line 133, in connect
    ret = super(PooledDatabase, self).connect(reuse_if_open)
  File "/opt/wapt/lib/python3.9/site-packages/peewee.py", line 3263, in connect
    self._state.set_connection(self._connect())
  File "/opt/wapt/lib/python3.9/site-packages/playhouse/pool.py", line 83, in inner
    return fn(self, *args, **kwargs)
  File "/opt/wapt/lib/python3.9/site-packages/playhouse/pool.py", line 177, in _connect
    conn = super(PooledDatabase, self)._connect()
  File "/opt/wapt/lib/python3.9/site-packages/playhouse/postgres_ext.py", line 476, in _connect
    conn = super(PostgresqlExtDatabase, self)._connect()
  File "/opt/wapt/lib/python3.9/site-packages/peewee.py", line 3991, in _connect
    raise ImproperlyConfigured('Postgres driver not installed!')
peewee.ImproperlyConfigured: Postgres driver not installed!

Soweit ich das verstanden habe, fehlte der PostgreSQL-Treiber in der Python 3.9-Umgebung (psycopg2), daher habe ich Folgendes getan:

Nach einiger Recherche stellte sich heraus, dass es sich um „psycopg2-binary“ und nicht um „psycopg2“ handelte… (offenbar um mögliche Probleme mit „Kompilierungsabhängigkeiten“ zu vermeiden…?)

Code: Alle auswählen

/opt/wapt/bin/python3.9 -m pip install psycopg2-binary

und ich habe die Nachbesprechung der Konferenz wieder aufgenommen, die dann auch beendet werden konnte.

Diesmal habe ich nicht gewartet und die Prozedur zur Wiederherstellung der Datenbank wiederholt (die korrekt abgeschlossen wurde, da ich beim ersten Mal bereits alles andere wiederhergestellt hatte).
Ich habe postconf neu gestartet (notwendig? Ich glaube, das ist das Erste, was postconf macht, die Datenbank bearbeiten/aktualisieren oder... ich weiß es nicht genau).

und (nach waptsetup -> install -> Konsole öffnen) nach dem Neustart der Konsole eine kleine Erleichterung:

: 251006_00h06m16s_1759701976.png (235,73 KB) 21551 Aufrufe

Abgesehen von meiner Administratorposition sind jedoch alle Agenten auf Version 2.6.1 (also n+1), aber alles scheint zu funktionieren (Inventarisierung / Aktualisierung / Installation / waptexit / usw.)

Ich habe einen Agenten in Version 2.6.0.17392 neu generiert, fragte mich dann aber, was die beste Vorgehensweise wäre:

Soll ich es so lassen?

Agent 2.6.1 durch Version 2.6.0.17392 mittels einer erzwungenen Installation überschreiben?

Ich bleibe bei Version 2.6.0.17392. Wenn ich auf 2.6.1 zurückgehe, glaube ich nicht, dass die Postkonfiguration funktionieren wird.

Kommandant.

Hallo Bastien,

Ich habe es gerade auf einem Debian 12 arm64-System getestet, und die Serverinstallation verlief reibungslos. Ich habe leider kein Ubuntu 24.04 arm64-System zum Testen zur Hand.

Welche CPU ist in Ihrer Amazon-Instanz verbaut? Der Test, den ich gerade durchgeführt habe, lief auf einem Mac mini mit Parallels

Code: Alle auswählen

root@debian12:~# lscpu 
Architecture:             aarch64
  CPU op-mode(s):         64-bit
  Byte Order:             Little Endian
CPU(s):                   2
  On-line CPU(s) list:    0,1
Vendor ID:                ARM
  BIOS Vendor ID:         Apple
  Model name:             -
    BIOS Model name:      Apple Silicon None CPU @ 2.0GHz
    BIOS CPU family:      257
    Model:                0
    Thread(s) per core:   1
    Core(s) per cluster:  2
    Socket(s):            1
    Cluster(s):           1
    Stepping:             r0p0
    BogoMIPS:             48.00
    Flags:                fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 asimddp 
                          sha512 asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp flagm2 frint

Aufrichtig,

Denis

Hallo nochmal Bastien,

Ich habe gerade einen Test auf einem Debian 13 arm64 in einer virtuellen Parallels-Umgebung auf demselben Mac Mini durchgeführt, und es funktioniert.

Allerdings erhalte ich auch auf einer Debian 13 arm64 VM in einer vbox auf einem Win11 arm64 (Altra Ampere Prozessor) einen Segmentierungsfehler beim Importieren von setuphelpers.

Andererseits liegt das Problem nicht bei psycopg2, es wird korrekt geladen (siehe unten).

: Capture.PNG (5,74 KB) 21504 Mal angesehen

Ich grabe morgen.

Aufrichtig,

Denis

Hallo nochmal,

Tatsächlich lag das Problem am Laden der Datei waptlicences.so (die fälschlicherweise „waptfpclibs.so“ heißt, also die Wapt-Bibliotheken in Lazarus/FPC, die Python zur Verfügung gestellt werden). Diese ist nun direkt in wapt-get.bin eingebunden und sollte unter Linux nicht mehr separat geladen werden müssen. Das Postconf-Skript rief jedoch (dies wurde soeben im Master-Git-Repository behoben) /opt/wapt/bin/python anstelle von /opt/wapt/wapt-get.bin auf (was gleichzeitig der Python-Interpreter ist).

Zur Information: Wir sind auf /opt/wapt/wapt-get.bin umgestiegen, um den wapt-Prozess und seine Python-Skripte besser von der Systemumgebung zu isolieren: Der cpython-Projektlader, d. h. python.exe (oder das Äquivalent unter Linux), ist viel zu nachlässig in Bezug darauf, was er lädt.

Daher müssen Sie lediglich die folgende Zeile in der Datei /opt/wapt/waptserver/scripts/postconf.sh ändern

Code: Alle auswählen

NCURSES_NO_UTF8_ACS=1 PYTHONPATH=/opt/wapt /opt/wapt/wapt-get.bin -I /opt/wapt/waptserver/scripts/postconf.py $@

Die Nachbearbeitung der Konferenz sollte nun funktionieren. Vielen Dank für den Hinweis; wir hätten das Problem früher beheben sollen.

Aufrichtig,

Denis

Hallo Denis,

vielen Dank.

Die Instanz läuft in der Oracle Cloud. Daher war ich nicht wirklich überrascht (eher erleichtert), als ich las, dass sie unter vBox abstürzte.
Es handelt sich um eine A1-ARM-Instanz mit Ampere-Prozessor. Ich hätte Debian bevorzugt, aber Oracles kostenloses Kontingent bietet nur Ubuntu (kein Debian) an, und man kann kein eigenes Image importieren.

Das Problem mit „psycopg2“ trat auf, als ich Version 2.6.0.17392 manuell installierte, genauer gesagt mit „wget“. Ich hätte mich klarer ausdrücken und etwas detaillierter sein sollen… (Übrigens, in dieser Version gibt es keinen „Segfault“.)

Und ja, ich erinnere mich, irgendwo gelesen zu haben (ich weiß aber nicht mehr wo), dass Sie die Python-Projekt-Binärdatei als zu permissiv empfanden (ich bin aber kein professioneller Entwickler, daher frage ich mich immer noch, warum ^^) und dass wapt-get.bin tatsächlich die Python-Binärdatei war, die Sie neu entwickelt haben, wenn ich mich recht erinnere.
Danke für die detaillierten Informationen;

ich muss sie erst einmal etwas genauer analysieren. ^^

Die Umstellung auf /opt/wapt/wapt-get.bin erfolgt also ab Version 2.6.1?

Ich werde den Server aktualisieren und postconf.sh anpassen.
Nochmals vielen Dank.

Beste Grüße,
Bastien

Hallo nochmal,

Die Postkonfiguration startet und beendet sich korrekt (zumindest denke ich das). Vielen Dank.

Nur :

Code: Alle auswählen

Waptsetup agent installer:
    Version available on server: (True, '2.6.1.17472')
    You can download "waptsetup" Windows agent installer at URL: @@@@@
    Check the Code signing signature and the hash of the installer: Sha256: 718ad50ee9ad965206ced382260c7b882b9bf2d26265c6db37e955fd5baab0c8


Traceback (most recent call last):
  File "<string>", line 1404, in <module>
  File "<string>", line 1315, in main
  File "/opt/wapt/waptutils.py", line 2263, in run
    raise CalledProcessErrorOutput(proc.returncode, cmd, ''.join(output))
waptutils.CalledProcessErrorOutput: Command b'/opt/wapt/wapt-scanpackages.sh -b /var/www/wapt' returned non-zero exit status 139.
Output:/opt/wapt/wapt-scanpackages.sh: line 30: 72915 Segmentation fault      sudo -u wapt CRYPTOGRAPHY_OPENSSL_NO_LEGACY=1 PYTHONNOUSERSITE=1 PYTHONPATH="${WAPT_HOME}" "${WAPT_HOME}"/bin/python -I "${WAPT_HOME}"/wapt-scanpackages.py $@

CalledProcessErrorOutput: Command b'/opt/wapt/wapt-scanpackages.sh -b /var/www/wapt' returned non-zero exit status 139.
Output:/opt/wapt/wapt-scanpackages.sh: line 30: 72915 Segmentation fault      sudo -u wapt CRYPTOGRAPHY_OPENSSL_NO_LEGACY=1 PYTHONNOUSERSITE=1 PYTHONPATH="${WAPT_HOME}" "${WAPT_HOME}"/bin/python -I "${WAPT_HOME}"/wapt-scanpackages.py $@

Ich werde wapt-scanpackages.sh auf die gleiche Weise modifizieren und "/bin/python" ersetzen (nun ja... nehme ich an?)

Grüße,
Bastien

[Bearbeitung]: Ich habe die Änderung zu "wapt-scanpackage" letztendlich nicht vorgenommen, da der Befehl "wapt-get" funktioniert:

Code: Alle auswählen

root@my-wapt:~# wapt-get scan-packages /var/www/wapt/
Using config file: /opt/wapt/wapt-get.ini
Packages filename : /var/www/wapt/Packages
Processed packages :
  /var/www/wapt/zth-testscanpkg_0-1_PROD.wapt
Skipped packages :
  /var/www/wapt/zth-ms-store-winget_2025.717.1857.0-78_windows_10.0_PROD.wapt
  /var/www/wapt/zth-rustdesk_1.4.2-3_x64_windows_10_PROD_7c3f13b8f4e027b6494b2a1dc7e20407.wapt

+ In der Konsole funktioniert alles einwandfrei, aber ich bin mir nicht sicher, wann dieses Skript aufgerufen werden kann.
Danke trotzdem, Server und Agenten laufen tatsächlich mit Version 2.6.1 und alles scheint zu funktionieren. (Möglicherweise muss /bin/python an anderen Stellen ersetzt werden.)

Hallo Bastien,

ja, die Datei `/opt/wapt/wapt-scanpackages.sh` hat dasselbe Problem wie die `postconf`-Datei. Wir werden sie ebenfalls anpassen.

Die Umstellung auf den Python-Loader `wapt-get.exe`/`wapt-get.bin` (geschrieben in Lazarus/FPC) haben wir in Version 2.6.0 implementiert. Um die Hintergründe besser zu verstehen, können Sie beim Start von Python unter Windows einen Prozess-Explorer verwenden. Neben dem Problem mit `PYTHONPATH` (das ohnehin schon problematisch ist) gibt es auch das Problem, dass DLLs/SO-Dateien von unerwarteten Orten geladen werden können. Hinzu kommen Bibliotheken, die unter Windows nach Pfaden suchen, als wären es Linux-Systeme (z. B. die Suche nach Standarddateien in `c:\etc\...`).

Außerdem ist die Python-Engine selbst in die Datei `python310.dll`/`libpython310.so` integriert, und dort gibt es keine Änderungen, nur am Loader.

Die Integration der Bibliothek waptlicences.dll/waptlicences.so in die wapt-get-Binärdatei erfolgte vermutlich zeitgleich. Dies lag ebenfalls an Problemen mit dem dynamischen Linker, der gelegentlich Schwierigkeiten hat.

Kurz gesagt: Dynamische Sprachen wie Python sind zwar äußerst nützlich, aber man muss sehr vorsichtig sein, wenn man sie als Unterkomponente eines Produkts einsetzt.

Mit freundlichen Grüßen,

Denis

Hallo Denis,

danke für die Erklärung, aber ich muss gestehen, dass ich noch nicht alles verstehe.

Ich weiß zum Beispiel nicht, was ein dynamischer Linker ist, aber ich werde mir das merken und mich damit auseinandersetzen.
Ich habe einen recht schnellen Karrierewechsel in die IT gemacht. Ich habe einige Netzwerk-/Systemkurse belegt, aber nur sehr wenige Entwicklungskurse (naja, wenn man sie so nennen kann: konzeptionelle/logische Datenmodelle, Java-Klassendiagramme usw.). Ich
habe ein bisschen in Bash gescriptet, aber ansonsten beschränkt sich meine Python-Erfahrung auf WAPT, da ich praktisch der Einzige bin, der die Pakete bearbeitet und die Server aktualisiert. Ich habe Python aber nie wirklich außerhalb der WAPT-Umgebung über Pakete oder die wapt-get-Shell verwendet.
Ich klicke viel mit gedrückter Strg-Taste in PyScripter und versuche zu verstehen, was sich bereits in den setuphelpers/common-Ordnern befindet oder wie man diese oder jene Bibliothek (DLLs? usw.) verwendet. Ich glaube, ich habe BeautifulSoup (eine Funktion?) in einem Paket verwendet. Ich bin mir nicht einmal sicher, ob ich die richtigen Begriffe verwende, geschweige denn, ob mein Python-Code „sauber“ ist.

Ich habe einen Fall gesehen (ich erinnere mich nicht mehr an die Details), in dem Websites JS-DLLs von einer seriösen Domain luden, die später von chinesischen Firmen aufgekauft und mit Schadcode infiziert wurde.

Gibt es für WAPT einen Bereich oder eine Plattform, wo man sich bezüglich Server- und Agentenkonfiguration (je nach Umgebung/Kontext), Sicherheit usw. beraten lassen kann?
Ich habe bisher hauptsächlich Beiträge zu „Fehlerbehebung/Support“ oder „Bug-Reports/Feedback“ gesehen.

Es geht mir vor allem um die Discovery-Version, bei der ich mir bezüglich Konfiguration und Absicherung unsicher bin, insbesondere wenn der Server öffentlich zugänglich ist (in meinem Fall in der Oracle Cloud).

Ansonsten ist es noch nicht lange her, aber seit der Modifikation und dem Update sind mir keine Bugs oder Fehler in der Konsole aufgefallen. Ich habe außer der Datei postconf.sh keine weiteren Änderungen vorgenommen.
Endlich erhalte ich Feedback in der Konsole, denn mit dem anderen, trägen Server lief alles einwandfrei; Downloads waren zwar zugegebenermaßen sehr langsam, aber Installationen, Updates und Deinstallationen wurden alle korrekt abgeschlossen.
In der Konsole wurde mir jedoch nur der Zustand vor und nach der Änderung angezeigt. ^^

Vielen Dank nochmal.

Beste Grüße,
Bastien

Hallo,

ich denke, dieses Thema kann geschlossen werden, wenn Sie das wünschen.

Viele Grüße,
Bastien

Ruhiges IT-Forum

[GELÖST] Migration von srv-x64-ubuntu zu srv-arm64-ubuntu

[GELÖST] Migration von srv-x64-ubuntu zu srv-arm64-ubuntu

Betreff: Migration von srv-x64-ubuntu zu srv-arm64-ubuntu

Betreff: Migration von srv-x64-ubuntu zu srv-arm64-ubuntu

Betreff: Migration von srv-x64-ubuntu zu srv-arm64-ubuntu

Betreff: Migration von srv-x64-ubuntu zu srv-arm64-ubuntu

Betreff: Migration von srv-x64-ubuntu zu srv-arm64-ubuntu

Betreff: Migration von srv-x64-ubuntu zu srv-arm64-ubuntu

Betreff: Migration von srv-x64-ubuntu zu srv-arm64-ubuntu

Betreff: Migration von srv-x64-ubuntu zu srv-arm64-ubuntu

Betreff: Migration von srv-x64-ubuntu zu srv-arm64-ubuntu