Forum IT Tranquillo

WAPT Discovery -- 2.6.1.17472 -- SRV Ubuntu 24.04

Buongiorno,

Ho configurato un server wapt sul cloud Oracle su un'istanza micro-x64 (1/8 ocpu / 1 GB RAM), tutto funziona perfettamente, tranne per il fatto che bisogna essere un po' più pazienti date le prestazioni del server (limite di 50 Mb/sec di larghezza di banda in upload).
Volevo migrare il server su un'istanza arm-x64 (prestazioni migliori e 1 Gb/sec/ocpu di larghezza di banda).

quindi ho fatto marcia indietro

Codice: Seleziona tutto

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

e svuotare il database.

Ho avviato l'installazione sulla VM arm64, ma sembra che ci sia un problema con lo script postconf:

Codice: Seleziona tutto

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 $@

Da quello che sono riuscito a scoprire, si blocca con il nuovo ambiente Python 3.10 quando si importa "setuphelper" in postconf.py. (Ma probabilmente mi sbaglio e non ho indagato ulteriormente.)

Per uscirne, ho ripulito tutto e installato l'ultima versione 2.5 e non ci sono stati problemi.
Sono migrato

Codice: Seleziona tutto

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

ma il ripristino del database fallisce (probabilmente non sono gli stessi schemi dato che ero sull'ultima versione 2.6)

Quindi ho il server in esecuzione con l'ultima versione 2.5, ho recuperato la configurazione del server, i miei pacchetti e i file host, ma l'inventario della console rimane vuoto (perché non c'è alcun ripristino del database?) e non posso quindi aggiornare all'ultima versione 2.6 a causa dell'errore durante postconf.

(Per registrare nuovamente una macchina - agente 2.6 - finora non ho trovato altra soluzione se non quella di rigenerare un waptagent 2.5 ed eseguire un "wapt-get install --force" per sovrascrivere l'agente 2.6 installato, ma devo andare su ogni macchina per farlo)

Comandante.

Buongiorno,

Sono tornato con qualche altra idea, anche se non ho una soluzione (e comunque non la troverei ^^)

Quindi, il problema postconf che causa l'arresto anomalo in caso di "segfault" si verifica effettivamente a partire dalla prima versione 2.6.1.
Ho provato ad avviare postconf.py con ogni ambiente Python (beh, non sono uno sviluppatore... probabilmente dirò delle cose stupide, ma comunque)

Codice: Seleziona tutto

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

ma ho ricevuto lo stesso errore di memoria quando l'ho testato.

In breve, ho installato l'ultima versione 2.6.0 (wapt-2.6.0.17392-0ac7bf48)

Codice: Seleziona tutto

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

Ho quindi eseguito il

Codice: Seleziona tutto

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

che è riuscito a iniziare.

Tuttavia, alla fine della postconf c'era già un problema in questa versione che ero già riuscito a risolvere/aggirare in precedenza.
Era piuttosto esplicito:

Codice: Seleziona tutto

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!

Da quanto ho capito, il driver Postgres mancava nell'ambiente Python3.9 (psycopg2), quindi ho fatto quanto segue:

Quindi, dopo aver fatto qualche ricerca, si è scoperto che era "psycopg2-binary" e non "psycopg2"... (a quanto pare per evitare possibili problemi di "dipendenza dalla compilazione"...?)

Codice: Seleziona tutto

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

e ho ripreso la riunione post-conferenza che è riuscita a concludersi.

Questa volta non ho aspettato e ho rifatto la procedura di ripristino del database (che si è conclusa correttamente, avevo già ripristinato tutto il resto la prima volta).
Ho riavviato un postconf (necessario? Credo che sia la prima cosa che fa postconf, modificare/aggiornare il database o... non lo so bene).

e (dopo waptsetup -> installa -> apri console) al riavvio della console, un piccolo sollievo:

: 251006_00h06m16s_1759701976.png (235,73 KB) Visualizzato 20917 volte

Tuttavia, a parte la mia posizione di amministratore, tutti gli agenti sono sulla versione 2.6.1 (quindi n+1) ma tutto sembra funzionare (inventario / aggiornamento / installazione / waptexit / ecc.)

Ho rigenerato un agente nella versione 2.6.0.17392, ma poi mi sono chiesto quale sarebbe stata la soluzione migliore:

Lasciarlo così com'è?

Sovrascrivere l'agente 2.6.1 con la versione 2.6.0.17392 utilizzando un'installazione forzata?

Continuerò a usare la versione 2.6.0.17392, se torno alla 2.6.1 non credo che postconf funzionerà.

Comandante.

Ciao Bastien,

L'ho appena testato su un sistema Debian 12 arm64 e l'installazione del server è andata a buon fine. Non ho a portata di mano un sistema Ubuntu 24.04 arm64 per verificare.

Che CPU hai sulla tua istanza Amazon? Il test che ho appena eseguito è stato eseguito su un Mac mini utilizzando Parallels

Codice: Seleziona tutto

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

Sinceramente,

Denis

Ciao di nuovo Bastien,

Ho appena fatto un test su una Debian 13 arm64 in Parallels virtuale sullo stesso Mac Mini e funziona.

Tuttavia, su una VM Debian 13 arm64 su una vbox su un Win11 arm64 (processore Altra Ampere), ho anche un segfault durante l'importazione di setuphelpers.

Ma d'altro canto il problema non è psycopg2, si carica correttamente (vedi sotto).

: Capture.PNG (5,74 KB) Visualizzato 20870 volte

Scaverò domani.

Sinceramente,

Denis

Ciao di nuovo,

In realtà, si tratta del caricamento del file waptlicences.so (nome errato perché in realtà è "waptfpclibs.so", ovvero le librerie Wapt in Lazarus/FPC esposte a Python). Ora è incluso direttamente in wapt-get.bin e non dovrebbe più essere caricato separatamente su Linux, ma lo script postconf (il problema è stato appena corretto nel repository git principale) chiamava /opt/wapt/bin/python invece di /opt/wapt/wapt-get.bin (che è anche l'interprete Python).

Per vostra informazione, siamo passati a /opt/wapt/wapt-get.bin per isolare meglio il processo wapt e i suoi script python dall'ambiente di sistema: il caricatore del progetto cpython, ovvero python.exe (o l'equivalente su Linux) è troppo permissivo per quanto riguarda ciò che carica.

Pertanto, è sufficiente modificare la seguente riga nel file /opt/wapt/waptserver/scripts/postconf.sh

Codice: Seleziona tutto

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

E il post-conferenza dovrebbe funzionare. Grazie per avercelo fatto notare; avremmo dovuto risolvere il problema prima.

Sinceramente,

Denis

Ciao Denis,

prima di tutto, grazie mille.

L'istanza è in esecuzione sul cloud Oracle. Quindi non sono rimasto sorpreso (anzi, sollevato) nel leggere che si bloccava sotto vBox.
Si tratta di un'istanza A1-arm, quindi ha un processore Ampere... Avrei preferito usare Debian, ma il piano gratuito di Oracle offre solo Ubuntu (niente Debian) e non è possibile importare la propria immagine.

Per quanto riguarda "psycopg2", il problema si è verificato quando ho installato manualmente la versione 2.6.0.17392, in particolare quando usavo "wget". Avrei dovuto essere più chiaro e fornire maggiori dettagli... (a proposito, in questa versione non c'è nessun "segfault").

E sì, ricordo di aver letto da qualche parte (ma non ricordo dove) che avevi trovato il binario del progetto Python troppo permissivo (ma non sono uno sviluppatore di professione, quindi mi chiedo ancora perché ^^) e che wapt-get.bin era in realtà il binario Python che avevi rielaborato, se la memoria non mi inganna.
Grazie per le informazioni dettagliate;

dovrò "decifrarle" un po' ^^

Quindi, il passaggio a /opt/wapt/wapt-get.bin è dalla versione 2.6.1 in poi?

Aggiornerò il server e modificherò postconf.sh.
Grazie ancora.

Cordiali saluti,
Bastien

Ciao di nuovo,

Il postconf inizia e finisce correttamente (o almeno credo). Grazie mille.

Appena :

Codice: Seleziona tutto

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 $@

Modificherò wapt-scanpackages.sh nello stesso modo e sostituirò "/bin/python" (beh... suppongo di sì?)

Saluti,
Bastiano

[modifica]: Alla fine non ho apportato la modifica a "wapt-scanpackage" perché il comando "wapt-get" funziona:

Codice: Seleziona tutto

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

+ tutto funziona nella console e non sono sicuro di quando questo script potrà essere richiamato.
Grazie comunque, il server e gli agenti sono effettivamente sulla versione 2.6.1 e tutto sembra funzionare. (Forse /bin/python dovrà essere sostituito in altri punti)

Ciao Bastien,

sì, il file /opt/wapt/wapt-scanpackages.sh presenta lo stesso problema del file postconf. Lo modificheremo anche noi.

Per quanto riguarda il passaggio al loader Python wapt-get.exe/wapt-get.bin (scritto in Lazarus/FPC), lo abbiamo implementato nella versione 2.6.0. Se vuoi capire meglio il motivo, puoi eseguire Process Explorer all'avvio di Python su Windows. Oltre al problema di PYTHONPATH (che è già piuttosto problematico), c'è anche il problema del caricamento di DLL/file SO, che possono essere recuperati da posizioni inaspettate. Per non parlare delle librerie che cercano i percorsi su Windows come se fossero sistemi Linux (come la ricerca di file predefiniti in c:\etc\...).

Inoltre, il motore Python stesso è integrato nel file python310.dll/libpython310.so e non ci sono modifiche lì, solo al loader.

L'integrazione della libreria waptlicences.dll/waptlicences.so nel binario wapt-get deve essere avvenuta contemporaneamente. Ciò è stato dovuto anche a problemi con il linker dinamico, che a volte si confonde.

In breve, i linguaggi dinamici come Python sono incredibilmente utili, ma bisogna fare molta attenzione quando li si utilizza come sottocomponente di un prodotto.

Cordiali saluti,

Denis

Ciao Denis,

grazie per il chiarimento, ma confesso di non aver capito tutto.

Non so cosa sia un linker dinamico, per esempio, ma lo terrò a mente e cercherò di approfondire.
Ho fatto un cambio di carriera "rapido" nel settore IT. Ho seguito alcuni corsi di reti/sistemi, ma pochissimi corsi di sviluppo (beh, se così si possono definire: modelli di dati concettuali/modelli di dati logici, diagrammi di classi Java, ecc.). Ho
fatto un po' di scripting in Bash, ma per il resto la mia esperienza con Python si limita a WAPT, dato che sono praticamente l'unico a modificare i pacchetti e ad aggiornare i server. Ma non ho mai usato Python al di fuori dell'ambiente WAPT tramite pacchetti o la shell wapt-get.
Faccio molto "clic con il tasto Ctrl" in PyScripter e cerco di vedere e capire cosa c'è già nelle cartelle setuphelpers/common o come usare questa o quella libreria (DLL? e così via?). Credo di aver usato BeautifulSoup (una funzione?) in un pacchetto. Ma non sono nemmeno sicuro di usare i termini giusti, figuriamoci se le righe di codice Python che sto scrivendo siano "pulite" ^^.

E ho visto un caso (non ricordo i dettagli) in cui i siti caricavano DLL JS da un nome di dominio affidabile che è stato poi acquistato da aziende cinesi che vi hanno iniettato codice dannoso.

Per WAPT, esiste una sezione o un luogo in cui possiamo chiedere consigli/opinioni sulla configurazione del server e dell'agente (a seconda del loro ambiente/contesto), sicurezza, ecc., o non esiste?
Ho visto principalmente post su "risoluzione dei problemi/supporto" o "segnalazioni di bug/feedback".

Si tratta principalmente della versione Discovery, per la quale non sono del tutto sicuro del modo migliore per configurarla/proteggerla, soprattutto se il server è direttamente esposto al pubblico (nel mio caso sul cloud di Oracle per il server Discovery).

In ogni caso, non è passato molto tempo, questo è certo, ma dalla modifica e dall'aggiornamento non ho riscontrato bug o errori tramite la console. Non ho apportato altre modifiche oltre al file postconf.sh.
Finalmente riesco a ottenere un feedback nella console perché con l'altro server, quello più lento, tutto funzionava perfettamente; i download erano indubbiamente molto lenti, ma installazioni, aggiornamenti e disinstallazioni si completavano tutti correttamente.
Nella console, però, vedevo solo un confronto prima/dopo. ^^

Grazie ancora.

Cordiali saluti,
Bastien

Ciao,

credo che questa discussione possa essere chiusa, se lo desideri.

Cordiali saluti,
Bastien

Forum IT Tranquillo

[RISOLTO] Migrazione da srv-x64-ubuntu a srv-arm64-ubuntu

[RISOLTO] Migrazione da srv-x64-ubuntu a srv-arm64-ubuntu

Re: Migrazione da srv-x64-ubuntu a srv-arm64-ubuntu

Re: Migrazione da srv-x64-ubuntu a srv-arm64-ubuntu

Re: Migrazione da srv-x64-ubuntu a srv-arm64-ubuntu

Re: Migrazione da srv-x64-ubuntu a srv-arm64-ubuntu

Re: Migrazione da srv-x64-ubuntu a srv-arm64-ubuntu

Re: Migrazione da srv-x64-ubuntu a srv-arm64-ubuntu

Re: Migrazione da srv-x64-ubuntu a srv-arm64-ubuntu

Re: Migrazione da srv-x64-ubuntu a srv-arm64-ubuntu

Re: Migrazione da srv-x64-ubuntu a srv-arm64-ubuntu