Archives For PostgreSQL

Ciao. Ti sei ritrovato davanti all’errore “psql: FATAL: no pg_hba.conf entry for host “::1”, user “postgres”, database “servicedesk”,SSL off” mentre cercavi di collegarti via prompt al database del tuo ServiceDesk Plus? Anche io. Poi ho scoperto che si tratta di un errore riconosciuto da documentazione ufficiale, e che ti basta modificare un file di configurazione per poter tornare sulla retta via.

ServiceDesk: Error While connecting postgresDB

Di come collegarti via prompt al database del tuo software di supporto te ne avevo già parlato qui:

ServiceDesk: jespa.log sempre più grande?

Per risolvere il problema che ho riportato in apertura “pillola” devi invece ritoccare il file pg_hba.conf che trovi sotto ManageEngine\ServiceDesk\pgsql\data, andando a togliere il cancelletto di commento in corrispondenza dei valori specificati sotto la riga # IPv6 local connections.

La situazione che dovresti trovare è teoricamente questa:

# IPv6 local connections:
#host all all ::1/128 trust

Tu dovrai trasformarla in questa:

# IPv6 local connections:
host all all ::1/128 trust

Salva il file e riprova a connetterti al database, non dovresti ora riscontrare ostacoli.

È tutto spiegato qui: kbase.servicedeskplusmsp.com/troubleshooting/2014/02/28/error-while-connecting-postgresdb.

Buon lavoro!

× Le pillole del Dr.Mario

Pillole

Le pillole sono articoli di veloce lettura dedicati a notizie, script o qualsiasi altra cosa possa essere "divorata e messa in pratica" con poco. Uno spazio del blog riservato ai post "a bruciapelo"!
Condividi l'articolo con i tuoi contatti:

Avevamo già parlato di ServiceDesk Plus e tuning qualche tempo fa, quando la piattaforma principale girava su MySQL (se la usavi già da qualche tempo), ormai andato completamente fuori supporto secondo lo sviluppatore del software (è stato richiesto il passaggio a PostgreSQL per continuare a ottenere supporto):

Pulizia e Tuning di ServiceDesk Plus (MySQL)

Cosa cambia dal punto di vista del tuning dell’installazione con PgSQL?

Tuning di ServiceDesk Plus (PostgreSQL)

Nulla a livello di Wrapper Java, almeno rispetto alla precedente volta quando si parlava di modifica per macchine con almeno (o più) di 4 GB di RAM, che è poi lo stesso concetto di base che riguarda l’ulteriore modifica del file di configurazione del Postgres suggerito sempre all’interno della community del prodotto (ServiceDesk, nda).

Ferma il servizio di ServiceDesk prima di continuare ed effettua un backup dei tuoi attuali dati (consigliato uno Snaphost della macchina, se virtuale).

Ti ripropongo ora il passaggio relativo al Wrapper del precedente articolo:

Il file di configurazione del Wrapper Java è quello che trovi in C:\ManageEngine\ServiceDesk\server\default\conf\wrapper.conf, da ritoccare sui due valori suggeriti:

# Initial Java Heap Size (in MB)
wrapper.java.initmemory=128

# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=256

a (nel caso della mia macchina con più di 4GB di RAM, occhio quindi alla tua):

# Initial Java Heap Size (in MB)
wrapper.java.initmemory=256

# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=1024

[…]

Ciò che stavolta cambia è il file di configurazione relativo al database. Sto parlando del postgres_ext.conf che dovresti poter trovare già nella cartella ManageEngine\ServiceDesk\pgsql\data. Probabilmente al suo interno potresti già trovare qualche specifica, per esempio:

wal_level = archive
archive_command = 'IF EXIST archive.bat (archive.bat "%p" "%f")'
archive_mode = on

Ciò che tu devi fare, è semplicemente dare un colpo di invio e aggiungerne qualcuna in più, per includere nuovi parametri entro i quali Postgres può continuare a riservare memoria per sé. Sto parlando di questi:

shared_buffers = 512MB
maintenance_work_mem = 100MB
effective_cache_size = 512MB
work_mem = 12MB

che, rispettivamente:

  • shared_buffers: corrisponde generalmente al 25% della memoria di sistema. Su Windows, 512 MB può essere il valore massimo.
  • maintenance_work_mem: corrisponde circa il 5% della memoria di sistema, ma senza superare mai i 512 MB.
  • effective cache size: si aggira approssimativamente sul 50% della memoria fisica disponibile, ho personalmente continuato a indicare 512 MB anche se avrei potuto tenerlo più alto.
  • work_mem: riporta un valore ragionevole che si attesta tipicamente tra i 4 e i 64 MB.

Il riferimento sulla community di ManageEngine, seppur riferito a SupportCenter, è questo: pitstop.manageengine.com/portal/community/topic/supportcenterplus-optimize-postgresql

Puoi riavviare ora il servizio di ServiceDesk per verificare se la modifica alla configurazione appena operata ha portato i benefici sperati (risposta positiva nel mio caso).


Photo by Igor Ovsyannykov on Unsplash
Condividi l'articolo con i tuoi contatti:

ManageEngine ServiceDesk è un software che utilizziamo parecchio in azienda, abbiamo dato vita a più HelpDesk che servono diversi team di lavoro, mette a disposizione di tecnici e commerciali una molteplicità di risorse e probabilmente fa anche al caso vostro, vi consiglio di dare un’occhiata al sito ufficiale del prodotto. Oggi però non mi voglio soffermare sulla descrizione del software in se ma parlare di un problema che ha colpito una delle installazioni nata diversa dalle altre: la quantità di log generata dal PostgreSQL configurato per il massimo del verbose.

ManageEngine

Provate a pensare a circa una decina di tecnici, ora aggiungete il carico di mail catturate direttamente da una casella di posta elettronica (per essere trasformate in ticket, ndr) e utenti con libero accesso al form di login per controllare lo stato della loro richiesta o aggiungere dettagli. Login, logout, query e modifiche al database. Una configurazione errata è stata in grado di produrre circa 32GB di file di log su disco in appena un giorno. La diretta conseguenza è facile da immaginare: spazio disco esaurito, impossibilità di fare ulteriori login o operazioni sul software.

Rimettere a posto la situazione è altrettanto semplice. Fermate il servizio che tiene vivo l’HelpDesk (si fermerà così anche il database) e intervenite sul file di configurazione di PostgreSQL che si trova tipicamente in X:\ManageEngine\ServiceDesk\pgsql\data\postgresql.conf (dove X: è il drive dove avete installato il software, ovviamente), a questo punto aprendolo con un editor di testo (Notepad++ tanto per citare il mio preferito) intervenite su questo blocco:

#------------------------------------------------------------------------------
# ERROR REPORTING AND LOGGING
#------------------------------------------------------------------------------

# - Where to Log -

log_destination = 'stderr'        # Valid values are combinations of
                    # stderr, csvlog, syslog and eventlog,
                    # depending on platform.  csvlog
                    # requires logging_collector to be on.

# This is used when logging to stderr:
logging_collector = off        # Enable capturing of stderr and csvlog

Nel codice sopra indicato ho già ritoccato la destinazione log (passata da csvlog che salvava quindi file mastodontici su disco fisso) a stderr. Una volta ritoccato il primo parametro potrete “spegnere” anche il logging_collector (che passa quindi da on a off). Continuerete a poter verificare eventuali problemi direttamente dai log messi a disposizione dal software ma almeno così le sorti del vostro disco di sistema (o dati, se l’installazione del ServiceDesk è stata fatta in una posizione diversa) saranno ben differenti da quelle che ne prevedono la fine (poco) naturale o la necessità dell’allargare lo spazio dedicato ogni 24h!

Sia chiaro: il consiglio vale per qualsiasi altro software si basi su PostgreSQL dato che il file di configurazione è sempre lo stesso. Per ciò che riguarda ServiceDesk potrete ora riavviare il servizio che provvederà a sua volta a resuscitare il DB e permettervi di tornare a lavorare tranquillamente con i vostri ticket.

Let’s rock! :-)

Condividi l'articolo con i tuoi contatti: