Pagina 1 di 1

Installazione di WAPT Community 1.8 su LINUX DEBIAN buster 10.2 - errore psql 5432

Pubblicato: 2 marzo 2020 - 14:41
di Aleks
Ciao,

sto provando la versione Community di WAPT prima di passare alla versione Enterprise.

Sto seguendo la documentazione di installazione del software su Debian, ma sto riscontrando un problema di installazione durante l'esecuzione dello script di installazione: /opt/wapt/waptserver/scripts/postconf.sh.
Ho controllato il forum prima di pubblicare questo messaggio, ma non ho trovato una soluzione da testare.

Avete qualche idea su quale potrebbe essere il problema con psql? È un problema di firewall? Devo modificare manualmente un file di configurazione di psql? :?

Grazie in anticipo! ;)

Ricevo il seguente errore come root:

Sincronizzazione dello stato di postgresql.service con lo script del servizio SysV con /lib/systemd/systemd-sysv-install.
Esecuzione: /lib/systemd/systemd-sysv-install enable postgresql
psql: impossibile connettersi al server: Nessun file o directory di questo tipo
Il server è in esecuzione localmente e accetta
connessioni sul socket di dominio Unix "/var/run/postgresql/.s.PGSQL.5432"?
Traceback (most recent call last):
File "/opt/wapt/waptserver/scripts/postconf.py", line 702, in
main()
File "/opt/wapt/waptserver/scripts/postconf.py", riga 423, in main
ensure_postgresql_db(db_name=server_config['db_name'],db_owner=server_config['db_name'],db_password=server_config['db_password'])
File "/opt/wapt/waptserver/scripts/postconf.py", riga 191, in ensure_postgresql_db
val = run(""" sudo -u postgres psql template1 -c " select usename from pg_catalog.pg_user where usename='wapt';" """, cwd='/opt/wapt')
File "/opt/wapt/waptserver/scripts/postconf.py", riga 66, in run
return subprocess.check_output(*args, shell=True, **kwargs)
File "/usr/lib/python2.7/subprocess.py", riga 223, in check_output
raise CalledProcessError(retcode, cmd, output=output)
subprocess.CalledProcessError: il comando ' sudo -u postgres psql template1 -c " select usename from pg_catalog.pg_user where usename='wapt';" ' ha restituito uno stato di uscita diverso da zero 2


debug:

root@WAPTC:~# psql
psql: impossibile connettersi al server: nessun file o directory di questo tipo
Il server è in esecuzione localmente e accetta
connessioni sul socket di dominio Unix "/var/run/postgresql/.s.PGSQL.5432"?

-------------

stato del servizio postgresql
● postgresql.service - PostgreSQL RDBMS
Caricato: caricato (/lib/systemd/system/postgresql.service; abilitato; preimpostazione del fornitore: abilitato)
Attivo: attivo (uscito) da lun 2020-03-02 14:13:19 CET; 13 min fa
PID principale: 486 (codice=uscito, stato=0/SUCCESSO)
Attività: 0 (limite: 2346)
Memoria: 0B
CGroup: /system.slice/postgresql.service

mar 02 14:13:19 WAPTC.****.*** systemd[1]: Avvio di PostgreSQL RDBMS...
mar 02 14:13:19 WAPTC.****.*** systemd[1]: PostgreSQL RDBMS avviato.

----------

root@WAPTC:~# localectl status
Impostazioni locali di sistema: LANG=en_US.UTF-8
Mappa tasti VC: n/d
Layout X11: fr
Modello X11: pc105
Variante X11: latin9

Re: Installazione di WAPT Community 1.8 su LINUX DEBIAN buster 10.2 - errore psql 5432

Pubblicato: 2 marzo 2020 - 18:05
di dcardon
Ciao,
hai AppArmor abilitato?
Cordiali saluti,
Denis

Re: Installazione di WAPT Community 1.8 su LINUX DEBIAN buster 10.2 - errore psql 5432

Pubblicato: 3 marzo 2020 - 09:51
di Aleks
Ciao,

sì, AppArmor è abilitato di default su Debian 10...

questa è un'installazione pulita il cui unico scopo è WAPT.

Immagino di dover trovare le righe di comando per AppArmor + PostgreSQL + WAPT?
:freccia: Sarebbe possibile includere un esempio tipico nella documentazione di installazione del server Debian?
Oppure è meglio disabilitare AppArmor? :?

Grazie per il suggerimento.

Cordiali saluti,
Aleks

Re: Installazione di WAPT Community 1.8 su LINUX DEBIAN buster 10.2 - errore psql 5432

Pubblicato: 3 marzo 2020 - 16:04
di dcardon
Ciao,

la configurazione di AppArmor in un'installazione standard di Debian 10 non dovrebbe essere un problema. Probabilmente è per questo che non ci sono molti post a riguardo. Se il socket esiste e il server PostgreSQL è in ascolto su di esso, il problema probabilmente risiede lì; controlla i permessi, ecc. (Sono più abituato a riscontrare questo tipo di problemi con SELinux).

Cordiali saluti,

Denis