AIUTO!

[AceBlack]

Ciao a tutti, mi hanno dato da poco in gestione un nuovo cliente che utilizza otrs su una macchina virtuale freebsd.

Ora, ovviamente..., lo vogliono aggiornare all'ultima versione ma ho bisogno di una consulenza. Attualmente c'è installata la versione OTRS:ITSM 1.3.2. O_o

Ho già letto che bisogna fare l'upgrade di tutte le versioni in mezzo, ma, mi chiedevo, se qualcuno ha già provato a farlo o è pura follia...

In ogni caso, qualcuno ha dei suggerimenti e un link a tutti i vari step da seguire per non distruggere il database?

Questa è la schermata di riepilogo:

Database
Check Commento Stato
Check DateStyle. ISO, MDY OK
Check existing framework tables. 69 tables checked. OK
Check the utf8 client connection. UTF8 OK
Check the utf8 server connection. UTF8 OK
Check database version. 9.3.4 OK


OS
Check Commento Stato
Check disk usage. Disk usage (). OK
Shows the used distribution. freebsd is used. OK
Shows the used Kernel version. "FreeBSD xx.com 8.3-RELEASE-p3 OK
Check Perl Version. Perl 5.10.1 (freebsd) is used. OK


OTRS
Check Commento Stato
Check if Ticket::.... No $Data{""} found. OK
Check default SOAP credentials. You have not enabled SOAP or have set your own pwd. OK
Check if root@localhost account has the default pwd. There is no active root@localhost with default pwd. OK
Check if the configured FQDN is valid. FQDN 'xx.com' looks good. OK
Check if file system is writable. The file system is writable. OK
Search for invalid user with locked tickets. There are no invalid users with locked tickets. OK
Check log for error log entries. You have more error log entries: (LIST ERRORS) Failed
Check open tickets in your system. You have 187 open tickets in your system. OK
Check deployment of all packages. All packages are correctly installed. OK
Check if the configured SystemID contains only digits. Your SystemID setting is 121. OK
Check Ticket::SearchIndexModule setting. 91806 articles in your system. You should use the StaticDB backend for OTRS 2.3 and higher. Critical
Check Ticket::IndexModule setting. You are using "Kernel::System::Ticket::IndexAccelerator::RuntimeDB", that's fine for 26884 tickets in your system. OK
Check orphaned StaticDB records. No orphaned records found. OK


Webserver
Check Commento Stato
Display web server version. You are running Apache/2.2.22 (FreeBSD) mod_fcgid/2.3.6 mod_ssl/2.2.22 OpenSSL/0.9.8y DAV/2. OK
Check for CGI Accelerator. You should use FastCGI or mod_perl to increase your performance. Critical

[Giulio Soleni]

Ciao,
non mi sono mai lanciato in un aggiornamento dalla versione 1.x alla 3.x e - per la mia esperienza - posso darti solo qualche suggerimento legato al buon senso
1 - non aggiornare il sistema del cliente con una versione beta (fermati alla 3.3.9 per ora 24 ottobre 2014)
2 - ho visto che per fortuna si tratta di un sistema virtuale ... fagli fare una bella snapshot o un backup iniziale che non si sa mai
3 - se ti viene data la disponibilità, fatti dare dal cliente una copia della sua VM attuale e prova l'aggiornamento per conto tuo ... meglio perdere tempo a disfare un sistema di test che rovinare un sistema di produzione.
4 - verifica se gli articoli dei ticket sono salvati su filesystem (soluzione caldamente suggerita) o su DB ... possibilmente spostali su filesystem.
5 - le procedure di upgrade documentate da OTRS non prevedono di preservare eventuali personalizzazioni ... se il sistema del tuo cliente è molto personalizzato nel codice, nei template o a causa di una configurazione spinta cercherei in tutti i modi di dissuaderlo dal fare un aggiornamento e gli proporrei di installare l'ultima versione di OTRS stabile su un nuovo sistema pulito e di ricominciare da capo.
6 - tieni presente che le varie versioni di OTRS hanno requirement diversi in termini di perl e suoi moduli, apache e database e suo engine ... con un aggiornamento da una versione così vecchia all'ultima disponibile è verosimile che aggiornamenti del sistema (o comunque di software necessario a OTRS per funzionare come perl, apache e il db) portino a inconsistenze o a instabilità...

Io ho lavorato con CentOS (RedHat) e OpenSuse e da una versione all'altra del sistema operativo ho dovuto tenere conto dei seguenti problemi:
- l'engine del database (MySQL) su cui ci si basava nelle versioni più vecchie è passato da MyISAM a InnoDB ... bisogna tenerne conto durante l'aggiornamento
- apache 2.4 non supporta più out-of-the-box mod_perl ... ho trovato dei pacchetti nei repository epel ma il problema non è del tutto risolto
- alcuni pacchetti perl che prima erano disponibili nei repository di base non lo sono più con le ultime versioni di perl ... vedi punto precedente

Normalmente quando un cliente mi chiede un aggiornamento da una versione molto vecchia (ma ripeto, non mi è mai capitata una versione così vecchia) io gli propongo sempre una migrazione, ovvero ...
- Installo (e tengo offline) un sistema nuovo di zecca con l'ultima versione di OTRS disp (stesso IP e stesso nome del sistema vecchio);
- Aggiorno quello vecchio facendo tutti i passaggi necessari;
- Migro OTRS dal sistema vecchio aggiornato a quello nuovo in questo modo:
prendo il backup del database e dei seguenti file:
/opt/otrs/var/log/TicketCounter.log
/opt/otrs/var/log/ITSMChangeCounter.log
/opt/otrs/Kernel/Config.pm
/opt/otrs/Kernel/Config/Files/ZZZAuto.pm
/opt/otrs/var/article/*
... e riporto tutto sul nuovo sistema.
- incorcio le dita, spengo il sistema vecchio e accendo il sistema nuovo

... tutti suggerimenti che lasciano il tempo che trovano, mi rendo conto, ma effettivamente aggiornare un sistema che non ha avuto un upgrade in 10 anni è decisamente una sfida.

In bocca al lupo!

[AceBlack]

Intanto grazie della risposta... ehm come prevedevo sarà un bagno di sangue... comunque diciamo che la macchina virtuale è già una copia sul mio pc quindi lavoro in locale.

Tra l'altro il cliente usa una VM con su la parte web e su un'altra VM il DB in Postgresql.

Infatti la mia intenzione era proprio quella di aggiornare tutto su la mia macchina locale (sempre VM chiaramente) poi portare il db e i file che dici tu su una nuova macchina (che sarà su una serverfarm) installata ex-novo... diciamo però che vedo una % di riuscita molto bassa....

Per ora grazie mille e ti terrò buono per altre info ^_^

Ciao!

[AceBlack]

Ciao Giulio, sto tentando l'upgrade... quando devo aggiornare il db però, dove dice di lanciare questo comando:

cat scripts/DBUpdate-to-3.0.postgresql.sql | psql otrs

mi restituisce l'errore:

"psql: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5432"? "

E mi pare ovvio visto che il db non è locale ma su un'altra macchina... la mia domanda è: come faccio a dire allo script che il db è su un'altra macchina?

Grassie
Ciao!!

P.S. Anzi già che ci sono ti faccio un'altra domanda... ma quando aggiorno dalla versione 2.4.9 alla 3.0 devo aggiornare anche il pacchetto ITSM (che attualmente è alla 1.3.2.. e se si come?!?) oppure aggiorno tutto l'otrs all'ultima 3.4 e poi alla fine ci installo l'ultimo ITSM?

Gazie...

[Giulio Soleni]

ciao,
DBUpdate-to-3.0.postgresql.sql non è altro che un elenco di istruzioni sql da applicare in successione al db per aggiornarlo conformemente alla versione 3.0 di OTRS.
Dovrebbe essere sufficiente copiare DBUpdate-to-3.0.postgresql.sql localmente sul server dove sta il database ed eseguire lì il comando DBUpdate-to-3.0.postgresql.sql | psql otrs
Diversamente potresti lanciare un comando remotamente usando ssh ... ma perché complicarsi la vita?

Quanto all'aggiornamento del bundle ITSM ... in teoria dovrebbe essere aggiornato ad ogni passaggio con la versione relativa più aggiornata disponibile (che se non sbaglio per OTRS 3.0.x è http://ftp.otrs.org/pub/otrs/itsm/bundl ... -3.0.9.opm) il problema che vedo è che questo modulo pare non essere stato mai aggiornato (o almeno non sembra aver seguito gli aggiornamenti relativi alla versione di OTRS)...
Direi... verifica con il cliente se e quanto il modulo è effettivamente utilizzato e valuta l'opportunità di disinstallarlo, aggiornare OTRS all'ultima versione senza modulo e solo alla fine installare l'ultima versione disponibile. Tieni presente però che se disinstalli il modulo elimini anche tutti i dati relativi (change, CI etc...) anzi, se decidi di disinstallarlo, proprio per evitare di lasciare pezzi in giro, prima di rimuoverlo ti consiglio di usare i due comandi:
/opt/otrs/bin/otrs.ITSMConfigItemDelete.pl
/opt/otrs/bin/otrs.ITSMChangeDelete.pl
che fanno pulizia di tutti i dati specificati grazie al modulo.

In qualsiasi caso il consiglio che mi sento di darti è sempre quello scaricarti in locale i moduli opm da installare e di usare lo script a linea di comando /opt/otrs/bin/otrs.PackageManager.pl per fare tutte le operazioni di installazione, aggiornamento, rimozione dei moduli ... da preferire sempre alla console web che spesso si inceppa per svariati problemi e soprattutto non ti dà riscontro immediato dele operazioni in corso, mentre a command-line vedi tutto.

[AceBlack]

Grazie Giulio, sul discorso aggiornamento db alla fine ho risolto lanciando il comando sempre dalla macchina web pgsql aggiungendo -h hostname -d nomedb

Sull'itsm invece inizio ad avere dei dubbi... ma sostanzialmente a che serve? io senza aver aggiornato nessun modulo, sono alla versione 3.0.9 del framework e pare funzionare tutto (a parte alcune maschere dove non trova dei campi per dire mi esce "OTRS_Ticket_number" al posto dell'effettivo numero del ticket nel campo oggetto dello storicodi ogni ticket ) credo sia per un problema del tema....?!? proverò a rifare l'upgrade copiando solo il Config.pm dalla vecchia versione perchè se ho ben capito sia il ZZZAuto da dei problemi e anche il GenericAgent.pm.... te che ne pensi? cosa mi perdo di questi file che poi dovrò rifare? intanto ci do un'occhio....

[AceBlack]

questi sono i pacchetti che danno errore (tutti)...

errori pacchetti.jpg

ora mi chiedo, per l'ITSM cosa cambia dalla versione bundle che mi hai indicato te rispetto a quelli che trovi qui? http://ftp.otrs.org/pub/otrs/itsm/packages30/

Invece gli altri pacchetti tipo calendar dove trovo i file opm aggiornati?

THANKS!

[Giulio Soleni]

Ciao,
allora facciamo un po' di ordine.
ITSM serve (parlando veramente a graaaandi linee) a tre cose:
- Change management (definizione di change con i loro workorder etc)
- CMDB e Asset Management
- approfondisce e perfeziona la gestione dei servizi Service Management
... se al tuo cliente non interessa alcuna delle cose indicate qui sopra, significa che non gli interessa avere il modulo ITSM e gli basta uno strumento per fare troubleticketing puro.
In tal caso ti puoi tranquillamente sbarazzare del modulo disinstallandolo.

Se invece al cliente interessa va installato... ora cosa installare? ... con il bundle installi in un colpo solo tutti i moduli che servono alle tre cose che ho indicato sopra ma volendo puoi installare solo parti del bundle ITSM. Tieni presente che:
- "ITSM Core" e "General Catalog" sono comunque necessari agli altri moduli ITSM per funzionare, quindi se vuoi la parte ITSM devi installare almeno entrambi questi due.
- gli altri moduli sono opzionali ... anche se non ho mai visto un'installazione del modulo di Change Management senza i moduli per il ServiceLevelManagement senza i quali dubito che funzioni tutto a dovere ... ma io ti passo le info così come mi sono state raccontate quando ho fatto la certificazione.

Il mio consiglio è: se al cliente interessa anche uno solo degli aspetti ITSM sopracitati installa il paccone del bundle che è la cosa più semplice e anche più sicura IMHO.

Dove trovare gli altri pacchetti (non del gruppo ITSM)?
Qui: http://ftp.otrs.org/pub/otrs/packages/

Fatte queste precisazioni ... la cosa che mi preoccupa di più sono le incongruenze che vedi su alcune form.
Se c'è una cosa che cambia parecchio tra una versione e un'altra di OTRS sono proprio i template ... ma centrano poco sia con Config.pm che con ZZZAuto.pm
Come regola generale assumi che è severamente vietato fare il backup di OTRS di una versione usando /opt/otrs/scripts/backup.pl e ripristinare il tutto su un altro sistema con una versione di OTRS differente con /opt/otrs/scripts/restore.pl perché hai probabilità prossime al 99% che vada tutto a remengo.
Quando come nel tuo caso si tratta di fare una migrazione il backup e il restore devono essere fatti a mano e può essere necessario dover intervenire sugli specifici file da restorare per adattarli alla nuova versione prima di copiarli semplicemente così come sono nel nuovo sistema.
Ti confermo comunque che i file da ripristinare sono quelli che ti ho indicato all'inizio:

/opt/otrs/var/log/TicketCounter.log
/opt/otrs/var/log/ITSMChangeCounter.log
/opt/otrs/Kernel/Config.pm
/opt/otrs/Kernel/Config/Files/ZZZAuto.pm
/opt/otrs/var/article/*

ma prima di copiarli così come sono dal vecchio al nuovo sistema un controllino di consistenza (usando il buon winmerge) lo farei almeno per Config.pm
Non vorrei che il fatto che alcuni ticket vengano mostrati col ticket number sballato potesse essere dovuto al fatto che non hai importato il TicketCounter.log ... questo file è importantissimo perché tiene conto del numero complessivo di ticket in gioco e ci si basa su questo file per computare il prossimo ticketnumber... Inoltre, sul nuovo sistema ti sei ricordato di mantenere lo stesso SystemID di quello vecchio?? (impostabile durante le procedure di post installazione via web con l'installer.pl) se i due sistemi hanno SystemID diversi non potranno mai avere ticketnumber conformi.

ZZZAuto.pm registra la configurazione di tutti i parametri su cui puoi intervenire da SysConfig alla console web (e ZZZAAuto.pm è la differenza dei parametri rispetto alla personalizzazione che puoi fare tu. Non serve importare anche ZZZAAuto.pm (con 2 A) - anzi non si deve proprio importarlo - e in caso di problemi può essere cancellato e ricreato automaticamente collegandosi in console con l'utente otrs e eseguendo un /opt/otrs/bin/otrs.RebuildConfig.pl )
Il ripristino del db infine, deve anche quello essere fatto con attenzione perché non è possibile ripristinare un db sopra ad un altro che non è vuoto - questo significa che prima di un restore devi fare un bel drop di tutte le tabelle del db target - e soprattutto non è possibile ripristinare un db sopra un db che non è basato sullo stesso engine.

[AceBlack]

Come sempre grazie della risposta, sul discorso ITSM ho poi cercato in giro ed ho capito e "purtoppo" loro lo utilizzano eccome...

la tua frase però: " Inoltre, sul nuovo sistema ti sei ricordato di mantenere lo stesso SystemID di quello vecchio?? (impostabile durante le procedure di post installazione via web con l'installer.pl) se i due sistemi hanno SystemID diversi non potranno mai avere ticketnumber conformi." mi lascia perplesso...

nel senso che nelle varie documentazioni di upgrade non ho letto da nessuna parte da far rigirare l'installer.pl a meno che non fosse una nuova installazione... ma quindi secondo te lo devo lanciare? come faccio a vedere il SystemID?

Thanks

[Giulio Soleni]

la tua frase però: " Inoltre, sul nuovo sistema ti sei ricordato di mantenere lo stesso SystemID di quello vecchio?? (impostabile durante le procedure di post installazione via web con l'installer.pl) se i due sistemi hanno SystemID diversi non potranno mai avere ticketnumber conformi." mi lascia perplesso...

nel senso che nelle varie documentazioni di upgrade non ho letto da nessuna parte da far rigirare l'installer.pl a meno che non fosse una nuova installazione... ma quindi secondo te lo devo lanciare? come faccio a vedere il SystemID?

Mi sembrava di aver capito che avessi scelto la strada della migrazione ad un sistema nuovo... forse ho capito male.
Ad ogni modo il systemID è dato da due cifre: lo puoi vedere (e reimpostare) dai parametri di SysConfig Framework -> Core SystemID

[AceBlack]

No dunque sto procedendo così: prima aggiorno tutte le versioni fino ad arrivare all'ultima stabile (comprese quindi tutti gli aggiornamenti del db) una volta finito, installo su una macchina pulita l'appliance dell'ultima stabile e poi importo solo il db... che dici?

Non trovo il file dove c'è scritto il SystemID -_-

per ora trovo solo strano questo tipo di errore: nell'oggetto della mail che crea OTRS in automatico quando riceve un ticket mi omette il numero ticket mentre in quelli successivi no, ti allego un esempio:

errore.jpg

Grassie
Ciao

[Giulio Soleni]

Mi era sfuggito che parlavi della autoresponse e del subject.
Nel subject effettivo della mail ricevuta dal cliente che ha creato il ticket, il numero di ticket dovrebbe comparire già in modo predefinito (senza necessità di doverlo specificare). Nel tuo caso il cliente avrà ricevuto una mail con questo oggetto:
[Ticket#20140902121000259] Conferma ricezione segnalazione <OTRS_TICKET_TicketNumber>
Ma stiamo parlando dell'oggetto della mail; nella schermata di riepilogo degli articoli di un ticket (la schermata che hai messo in figura) il prefisso [Ticket#20140902121000259] non viene mai mostrato.

Non ne sono sicuro ma il fatto che <OTRS_TICKET_TicketNumber> non possa espandersi nell'oggetto di un messaggio è un fatto voluto proprio ad evitare possibili inconsistenze: OTRS si basa sul ticket-number che individua nell'oggetto di una email che riceve in ingresso per integrare l'email come contributo di un ticket già aperto... se trova una specifica diversa o multipla del ticket number il rischio è che la mail ricevuta non sia gestita in modo corretto.
Hai mai provato a creare un ticket spedendo una mail al tuo OTRS con un oggetto del tipo "[Ticket#20140902121111111] test" ...? i risultati sono imprevedibili

Quindi non è un problema di SystemID (per fortuna).
Ad ogni modo come ti dicevo il SystemID lo puoi impostare solo da web e non da un file: tab ADMIN e nel riquadro in basso a destra SysConfig (o Configurazione Sistema in ita)
Nel menu di ricerca inserisci direttamente 'SystemID' senza apici e tra i risultati seleziona 'Core' ... nella schermata dei parametri modificabili troverai anche il SystemID.

Infine, raccomandazione:
Quando sei pronto per ripristinare i dati da un sistema all'altro, ribadisco che oltre al database è necessario importare:

Tutti gli articoli dei ticket (una volta appurato che non siano stati salvati nel database ... cerca come hai fatto prima per il SystemID, la voce StorageModule nelle configurazioni di sistema e verifica se è il parametro Ticket::StorageModule è impostato a ArticleStorageDB o ArticleStorageFS (consigliato)).
/opt/otrs/var/article/*

Il TicketCounter.log ... altrimenti i numeri dei ticket ti si sballano per davvero.
/opt/otrs/var/log/TicketCounter.log

Il change counter ... per lo stesso motivo dei ticket, ma in relazione ai change
/opt/otrs/var/log/ITSMChangeCounter.log

Le personalizzazioni (che sicuramente ci saranno ... anche se minime ... banalmente le credenziali per accedere al db) del file /opt/otrs/Kernel/Config.pm

Inoltre le impostazioni dei parametri di SysConfig sono tutte contenute in
/opt/otrs/Kernel/Config/Files/ZZZAuto.pm

Non è necessario che lo importi ... ma se non lo fai rischi di perderti le personalizzazioni fatte via web in SysConfig e te le devi rifare a mano.

... ho già detto poi che i due database (sorgente e destinazione) devono avere lo stesso engine e per fare il restore avrai bisogno di fare un drop delle tabelle del db destinazione prima di sovrascriverlo con il backup del sistema vecchio.

[AceBlack]

Ok sempre preciso ed utile grazie, comunque a quello ci arriverò poi

intanto sto migrando alla 3.2 e stavolta mi chiede di lanciare lo script:
/bin/otrs.CheckModules.pl e come risultato mi da:

perl.jpg

a parte alcuni opzionali che però vorrei installare (ma non so come si fa....) per quelli obbligatori ho provato a lanciare il comando:
perl -MCPAN -e shell;

entra in cpan> a quel punto dovrei lanciare il comando tipo:

install YAML::XS
corretto o mi invento i comandi? ahahah

[Giulio Soleni]

Non ho esperienza con freebsd ma priviligerei il meccanismo di update dei pacchetti precompilati che sono messi a disposizione nei repository ufficiali (tipo gli rpm per Red Hat o SuSE, i deb per Debian etc. per capirsi).
In Freebsd credo ci sia il comando freebsd-update https://www.freebsd.org/cgi/man.cgi?que ... &sektion=8
Il vantaggio maggiore che hai nell'installare pacchetti precompilati ufficiali è che viene tutto registrato dal software che si occupa di fare l'aggiornamento del sistema e se più avanti deciderai di aggiornare il sistema, tutti i pacchetti potranno essere aggiornati di conseguenza in un colpo solo.

Puoi comunque usare CPAN ... e i comandi da impartire sono esattamente quelli che hai detto.
Al primo avvio (la prima volta che esegui perl -e shell -MCPAN) ti verrà proposta una procedura di configurazione (che forse hai già eseguito) praticamente tutta automatica.
Volendo la si può rieseguire con il comando:

Code: Select all

cpan> o conf init

CPAN ti permette di installare i moduli prendendosi cura di tutte le dipendenze richieste, quindi non ti devi preoccupare di installare a parte tutti i prerequisiti, ma solamente confermare (con un yes) nel caso ve ne siano.
Il comando per installare è

Code: Select all

cpan> install nome-modulo

per vedere la disponibilità di un modulo ed eventualmente se ne hai già una versione installata:

Code: Select all

cpan> m nome-modulo

Della lista di moduli richiesti vanno senz'altro installati YAML::XS e va sanata la situazione per il ModPerl.
Poi il mio consiglio è quello di cercare di installarli tutti salvo DBD::ODBC e DBD::Oracle (dato che non usi questi database) e Encode::HanExtra a meno che tu non abbia clienti cinesi (una volta mi è capitato).

[AceBlack]

Sei troppo preciso

Thanks

P.S. Altra domandina al nostro superHero

Ma se volessi cambiare Indirizzo IP al server sul quale gira OTRS ma soprattutto nome macchina (non quello fqdn raggiungibile da fuori) ma semplicemente il nome host del server, devo modificare qualcosa anche in otrs?

THANKSSS

[Giulio Soleni]

Il cambio del nome o del IP può avere impatto se hai configurato Apache per mettersi in listening specificamente su un ip e/o su un nome.
La proprietà FQDN interna di OTRS (sempre dal solito SysConfig se cerchi FQDN nel gruppo Framework -> Core) serve solo a valorizzare la variabile <OTRS_CONFIG_FQDN> che puoi usare nelle notifiche ma non ha impatto sulla raggiungibilità dello strumento (puoi scriverci pure ciccio.pasticcio.com se vuoi).
Valuta però se non siano state aperte specifiche regole sui firewall che - se cambi nome o indirizzo - devono essere aggiornate conformemente.
Infine, ovviamente, se il db è remoto o se il server di OTRS deve essere raggiunto anche da altre applicazioni, il discorso cambia e modificare nome e/o IP può avere un impatto nella raggiungibilità del sistema.

[AceBlack]

Il cambio del nome o del IP può avere impatto se hai configurato Apache per mettersi in listening specificamente su un ip e/o su un nome.
La proprietà FQDN interna di OTRS (sempre dal solito SysConfig se cerchi FQDN nel gruppo Framework -> Core) serve solo a valorizzare la variabile <OTRS_CONFIG_FQDN> che puoi usare nelle notifiche ma non ha impatto sulla raggiungibilità dello strumento (puoi scriverci pure ciccio.pasticcio.com se vuoi).
Valuta però se non siano state aperte specifiche regole sui firewall che - se cambi nome o indirizzo - devono essere aggiornate conformemente.
Infine, ovviamente, se il db è remoto o se il server di OTRS deve essere raggiunto anche da altre applicazioni, il discorso cambia e modificare nome e/o IP può avere un impatto nella raggiungibilità del sistema.

si certo tranquillo sto lavorando su una macchina VM che mi sono portato in ufficio per le prove quindi ci faccio girare solo l'otrs. Ho solo il problema che se la piazzo su internet si va a pescare i dati delle mail e quindi poi non mi apre i ticket quello in produzione. Ovviamente tengo stoppato postfix ma intanto sto disabilitando anche le mail "vere" da dentro otrs e poi ne creerò una fittizia per le prove e poi ritiro su postfix.

Concordi?

[Giulio Soleni]

Concordo.
condividere la stessa mailbox tra due sistemi OTRS diversi non è mai una buona idea anche perché il fetch svuota sempre la casella. Quindi sì ... è opportuno definire una mailbox per il sistema di test e una distinta per quello di prod.
Per quanto riguarda invece le mail che OTRS manda in giro si possono temporaneamente disabilitare tutte sempre dal solito SysConfig cercando 'sendmail' nel menu di ricerca dei parametri...
Tra i parametri del gruppo Core::Sendmail, il primo può essere temporaneamente impostato a DoNotSendEmail e OTRS rimane "zitto", cioè non inoltra più nessun tipo di mail (notifiche, risposte o altro).

[AceBlack]

Concordo.
condividere la stessa mailbox tra due sistemi OTRS diversi non è mai una buona idea anche perché il fetch svuota sempre la casella. Quindi sì ... è opportuno definire una mailbox per il sistema di test e una distinta per quello di prod.
Per quanto riguarda invece le mail che OTRS manda in giro si possono temporaneamente disabilitare tutte sempre dal solito SysConfig cercando 'sendmail' nel menu di ricerca dei parametri...
Tra i parametri del gruppo Core::Sendmail, il primo può essere temporaneamente impostato a DoNotSendEmail e OTRS rimane "zitto", cioè non inoltra più nessun tipo di mail (notifiche, risposte o altro).

Ottimo!

Invece ho dovuto cambiare il server di posta aziendale, tutto funge, ma in OTRS, le mail in entrata funzionano, quelle in uscita no, infatti quando cerco di rispondere a un ticket mi da questo errore: (no mail exchanger (mx) found!)! ed ha ragione ho cambiato l'IP!!!!... ma dove si va a cambiare?

Grazie!

[Giulio Soleni]

ciao,
la configurazione della posta in uscita la fai sempre dallo stesso modulo di OTRS dove ti dicevo di disabilitare tutto con DoNotSendEmail.
Sempre in quel gruppo, posto che tu specifichi come SendmailModule [SMTP] hai poco sotto SendmailModule::Host dove indicare l'ip o il nome del tuo server di posta, e in SendmailModule::Port puoi specificare la porta, se è diversa dalla 25 (default SMTP)

Sono disponibili anche i protocolli SMTPS e SMTPLS se avete cifratura sulla posta in uscita.

Oppure puoi bypassare il server di posta e usare il server OTRS stesso (su cui però deve essere installato e configurato postfix e io qui ti posso aiutare pochino...).

[AceBlack]

ciao,
la configurazione della posta in uscita la fai sempre dallo stesso modulo di OTRS dove ti dicevo di disabilitare tutto con DoNotSendEmail.
Sempre in quel gruppo, posto che tu specifichi come SendmailModule [SMTP] hai poco sotto SendmailModule::Host dove indicare l'ip o il nome del tuo server di posta, e in SendmailModule::Port puoi specificare la porta, se è diversa dalla 25 (default SMTP)

Sono disponibili anche i protocolli SMTPS e SMTPLS se avete cifratura sulla posta in uscita.

Oppure puoi bypassare il server di posta e usare il server OTRS stesso (su cui però deve essere installato e configurato postfix e io qui ti posso aiutare pochino...).

Gia gia l'avevo scoperto! non potevo configurare postfix perche lo era già per delle liste di distribuzione che il cliente usa con un smtp in uscita diverso quindi l'ho configurato con i classici parametri, thanks!!!

[AceBlack]

E fu così che dopo varie bestemmie sono riuscito (grazie anche al vostro aiuto) ad aggiornare otrs alla 4.0.7.

Quindi lo scenario ora è 1 server virtuale con su otrs 4.0.7 con il DB postgres che punta ad un altro server virtuale.

Adesso ho installato un'otrs appliance 4.0.7 dove ho importato tutti i file di configurazione e funziona se io faccio puntare il db alla vecchia macchina, ma il mio obiettivo è quello di spostare il db dal vecchio server nell'appliance in modo tale da avere una sola macchina per il servizio otrs.

Ho provato a spostarlo con il cloneDB ma non funziona, se faccio un dump a mano e lo reimporto nell'appliance funziona l'importazione ma otrs non si aggancia al db perchè dice che manca una password.... che presumo sia quella che c'è all'interno del file .../Kernel/Config.pm... solo che nella configurazione della vecchia macchina è vuota.. nell'appliance evidentamente non me lo accetta.... che potrei fare?

Consigli?
Grazie
Ciao

[Giulio Soleni]

ciao,
presumo tu debba proprio allineare le password dell'utente otrs di postgres per i due db (e di conseguenza la pass nei due file /opt/otrs/Kernel/Config.pm)

Io ho sempre usato MySQL e non so esattamente quale sia la sintassi da usare nel caso di PostgreSQL ... Google mi suggerisce

Code: Select all

ALTER ROLE otrs WITH PASSWORD 'newpass';

ma non ci metterei la mano sul fuoco... dipende anche dalla versione di Postgres che usi (che non so quale sia).

ciao

[AceBlack]

si ma la cosa che mi fa strano è che in quello di produzione quel campo password è vuoto!

e cmq si le due versioni di postgres sono diverse, quella dell'appliance è una 8.x quella in produzione è una 9.x... ma credevo non creasse troppi problemi... ora mi chiedo vale la pena upgradare alla 9 l'appliance se poi quando faccio gli aggiornamenti fa casino?

Oppure fare downgrade dalla 9 alla 8 su quello attuale in produzione dici che fa casino?....

E già che ci sono ti chiedo... se devo cambiare hostname e IP sia al server web di otrs sia al server dove risiede il DB che parametri devo cambiare in otrs? Sono tutti quelli che troco dentro il Config.pm e il ZZZAuto.pm o devo cercare in altre parti?

Grazie mille come sempre Giulio!

Ciao

[RouxBaron309]

Thanks admin to post the information.