Topic: Passare dalla versione 8.x alla 9.x

[gromit60]

Finalmente è giunto il momento, anche perché la 8.x sta andando definitivamente in pensione.
Nonostante questo contravvenga al primo comandamento dell'informatico (Se una cosa funziona, non toccare niente), sto pianificando l'upgrade dei "miei" SME, tutti 8.2, alla versione 9.1.
In materia c'è un ottimo articolo nel wiki (https://wiki.contribs.org/SME_Server:9.1) e ho trovato anche un post nella sezione inglese del sito con utili consigli (https://forums.contribs.org/index.php/topic,52264.0.html).

Detto ciò, ho ancora qualche dubbio, in particolare:
- quale tipo di backup utilizzare per il restore, considerato che devo trasportare anche tutte le mail degli utenti;
- se ho capito bene, riguardo ai contribs, basta reinstallarli, perché le configurazioni sono già state importate con il backup.

Riguardo a quali contribs sono installati ed alle eventuali modifiche fatte a mano, ho già trovato risposta nei due link precedenti, si tratta solo di verificare.

Grazie in anticipo.

[Stefano]

ciao

prima di tutto: TUTTE le modalità di backup disponibili su SME includono le email degli utenti

la risposta a "quale backup usare" dipende da quanti dati hai da trasportare e quanto dowtime dei servizi puoi sopportare, visto che se le tue macchine sono server di posta "puri" (i.e. su di loro punta il record MX dei domini), nel tempo che effettui il backup e restore la macchina in produzione deve stare "offline" (per evitare incongruenze).

se per te non è un problema stare offline, il backup su workstation (i.e. con dar tramite server-manager) o quello tramite console sono equivalenti.. la differenza è che nel secondo caso non devi configurare nulla sul nuovo server.

io usualmente non uso dar (backup su workstation) ma un approccio simile a quello della console, cioè creo un file monoblocco smeserver.tgz e poi effettuo il restore "a mano" (ci sono le istruzioni nel wiki)

se invece hai la necessità di mantenere online la macchina in produzione, hai anche qui 2 vie: usare affa oppure uno script ad hoc.. io ho usato affa molte volte per migrazioni secche (sia di hw che di S.O.) e non ho avuto problemi, ma ultimamente lavoro con uno script personalizzato basato su rsync, che posso anche condividere ma che richiede attenzione e conoscenza del S.O. linux (non solo di SME).
con questo script h migrato macchine online stando anche a 700 km di distanza e con quantità di dati considerevoli (450GB di posta)..

tu scegli l'approccio e poi vediamo..
<self promotion>
se serve assistenza/consulenza per la migrazione, mi trovi offline ai recapiti visibili
</self promotion>

[gromit60]

Grazie come sempre della risposta.
In effetti mi sovviene che lo SME agisce come smtp, per cui in caso di downtime si avrebbe un problema con la consegna della posta.
I contribs presenti sono hylafax e backuppc, ma su questi non credo ci siano problemi.

[Stefano]

In effetti mi sovviene che lo SME agisce come smtp, per cui in caso di downtime si avrebbe un problema con la consegna della posta.

decisamente si

I contribs presenti sono hylafax e backuppc, ma su questi non credo ci siano problemi.

per il primo, dalla 8 alla 9 (i.e. da centos5 a centos6) c'è qualcosa da smandruppare perchè il servizio parte ma non "ascolta".. ho un server di un cliente dove gira e posso recuperare il custom template

per il secondo, è opportuno/necessario informarsi prima di come fare a muovere il salvato (se necessario) perchè non è banale.. a meno che i dati non siano su disco separato ed allora il problema non si pone, si trasporta su macchina nuova e si rimonta come era

[gromit60]

Stefano,
in base alle tue indicazioni, siamo addivenuti con il cliente che acquista un nuovo hardware. In questo modo posso pianificare la cosa senza downtime (spero).

[Stefano]

ottimo..

se servono input, siamo qui

[gromit60]

Ci siamo. A questo punto, avendo un nuovo hardware utilizzerei la modalità che prevede l'utilizzo di Affa. Allo scopo ho trovato questo articolo: https://wiki.contribs.org/Moving_SME_to_new_Hardware.
Se ho capito bene, la sequenza è:
- installazione nuovo server
- installazione di affa sul vecchio e sul nuovo server
- installazione dei contribs sul nuovo server
- ulteriori aggiustamenti.
E' corretto?

[Stefano]

affa lo puoi mettere sul nuovo server e basta, configuri il backup del vecchio, esegui il rise
poi installi i vari contrib

[Stefano]

se non hai molti dati, puoi testare su una VM temporanea (consigliato)

[gromit60]

Per quanto riguarda i dati si parla di poco più di 200 Gb.
Per il backup, invece, sul vecchio server è già abilitato il backup su workstation, che viene effettuato su un NAS. Va bene o devo abilitare un altro tipo di backup?

[Stefano]

Per usare affari per trasferire il server, lo installi solo sul nuovo, lo configuri per fare il backup del vecchio su se stesso e poi fai il rise

[gromit60]

Perdonami, sono un po' gnucco...
Mi sa che provo la strada VM, giusto per vedere a cosa vado incontro, anche come tempistica.

[Stefano]

la pagina

https://wiki.contribs.org/Moving_SME_to_new_Hardware

da' esattamente tutte le info..

tu hai 2 server:
- produzione (vecchio)
- destinazione (nuovo)

su nuovo installi affa e configuri un job affinchè faccia il backup di vecchio..

in altre parole, il nuovo server è un server di backup che va a prendersi tutti i file sul server in produzione (pull backup invece che push backup)

quindi affa va su una macchina sola, quella di destinazione

in ogni caso concordo con te.. fai tutte le prove finchè non capisci perfettamente come funziona la cosa, perchè pur avendo la certezza che la macchina vecchia non viene toccata, perdere tempo non è il massimo

[gromit60]

Ho seguito i preziosi consigli di Stefano e, approfittando del fine settimana, ho approntato una VM con SME 9.1 e ho seguito la procedura.
Fare questa prova è stato fondamentale, perché ho ricavato dati importanti.
Il primo: il primo backup dei dati ha preso la bellezza di circa 9 ore. Non so se questo sia dovuto al fatto che si trattava di una macchina virtuale, fattostà che ho lanciato il comando 'affa --run prodserv' alle 11.27 e ha terminato alle 20.30 circa. Questo pone anche un problema di contemporaneità, ovvero, durante la lunga fase di backup ovviamente le mail arrivano e gli utenti aggiungono file, visto che lo usano anche come file server; da qui una prima domanda: questo problema si risolve con l'ultimo 'affa --run prodserv' fatto con i servizi down?
Altra domanda: seguendo le istruzioni nell'howto segnalato più sopra, dopo la prima fase di backup occorre verificare nel file /var/affa/prodserv/rpms-missing.txt i pacchetti installati sul server di produzione ma non sul server di backup e quelli installati ma differenti nella versione, e devo dire che la lista è lunga! Il passo successivo, se ho capito bene, prevede di installare sul server di backup i pacchetti non presenti e di allineare quelli con differente versione, poi rilanciare il comando 'affa --run prodserv', fino a che il file risulta vuoto. Ho provato a fare come indicato, ho installato alcuni contribs presenti nel vecchio server e ho rilanciato il comando, ma nulla, il file non si è aggiornato e, provando a cancellarlo, non è stato nemmeno ricreato. E' un problema o me ne devo fregare e procedere ugualmente?

[Stefano]

Rispondo sinteticamente: tutto OK, ignora lista rpm

[Stefano]

adesso che sono al pc rispondo con più calma..

si, è normale che la prima esecuzione richieda parecchio tempo.. in compenso quelle successive possono richiedere solo pochi minuti

l'ultimo "giro" prima del rise (quello con i servizi spenti sulla macchina di produzione) ci mette meno di 5 minuti.

Relativamente alla lista degli rpm, devi forzatamente ignorarla perchè stai migrando da una major release ad un'altra.. assicurati solo di reinstallare i contrib necessari..

ah, prima di procedere con installazione di contrib dopo il rise, devi resettare i repository:

Code: [Select]

cd /home/e-smith/db
mv yum_repositories yum_repositories.old
/etc/e-smith/events/actions/initialize-default-databases

e riconfigurare eventuali repo esterni (trovi info nel wiki)

[gromit60]

Fatto! E quasi tutto sembra funzionare egregiamente!
Dico "quasi" perché c'è ancora qualche piccolo aggiustamento da fare, ma i servizi essenziali funzionano.
Per la prima fase, ho attaccato il nuovo server allo stesso switch al giga dove è attaccato il vecchio. Grazie a questo, ed al fatto che si trattava di una macchina fisica e non virtuale, c'è voluto meno della metà del tempo, infatti ho lanciato il "affa --run prodserv" alle 13;40 e quando sono tornato alle 17:00 aveva già finito.
Poi, in realtà, ho invertito le due fasi finali, cioè prima ho installato i contribs e poi ho effettuato il rise, tuttavia, come detto, sembra tutto ok.

Grazie di nuovo!

[Stefano]

you are welcome

comunque, possiamo accettare donazioni in termini economici o di impegno nel mantenimento/sviluppo di SME

[gromit60]

Siccome la sfiga ci vede benissimo, ovviamente l'unico particolare che non funziona(va) era quello fondamentale per il titolare... Si tratta di un plugin di qpsmtpd, cioè bcc. Ho individuato il problema e corretto. Come posso fare? Apro un altro thread? Lo segnalo nei bug? Anche se forse non si tratta di un vero e proprio bug...

[Stefano]

Racconta qui il problema, con tutti i particolari
Grazie

[gromit60]

Sostanzialmente ho attivato bcc, plugin di qpsmtpd, che consente la copia di tutte le mail in transito verso un determinato account.
Per farlo ho eseguito i seguenti comandi, come da istruzioni:

config setprop qpsmtpd Bcc enabled
config setprop qpsmtpd BccUser utente
config setprop qpsmtpd BccMode bcc
signal-event email-update

Fin qui tutto a posto, non ho avuto messaggi di errore e, guardando i log, sembrava che le mail venissero regolarmente copiate sull'account di destinazione.
Il problema era che in realtà le mail non arrivavano all'account in questione.
Per la soluzione del problema, non essendo un programmatore, ho applicato il metodo deduttivo: ho confrontato le due versioni di bcc, quella in SME 8.2 (funzionante) e quella in SME 9.1 (non funzionante), e ho visto che l'unica differenza tra le due consisteva nella presenza di Qpsmtpd al posto di Mail, ad esempio:

=cut
use Qpsmtpd::Address;
my $VERSION = 0.04;

anziché

=cut
use Mail::Address;
my $VERSION = 0.04;

non ho fatto altro che sostituire Qpsmtpd con Mail, signal-event email-update, ho riavviato e tutto è tornato a posto.

[Stefano]

cioè hai modificato il plugin?

[Stefano]

per cortesia, segnala la cosa in bugzilla, spiegano bene cosa non andava, cosa hai fatto
poi porta qui il riferimento del bug che ci metto il naso anche io
grazie

ah, english only.. eventualmente, scrivi il bug in italiano, ma dando il maggior numero possibile di dettagli, poi io vedo di tradurlo in inglese (ma se potessi evitarlo sarei + contento)

[gromit60]

Sì, ho modificato il plugin. Provo a riportarlo nei bug.

[Stefano]

molto gradito..

[Milano1971]

Mi accodo alla discussione per una domanda:
ho un sme 8 che non aggiorno da qualche mese, vorrei fare l'upgrade alla 9 tra qualche settimana, nel frattempo ho provato ad aggiornare l' sme 8 ma senza successo, ricevo errori nei repo... è normale?

[gromit60]

Che metodo hai usato?

[Milano1971]

servermanager e yum upgrade da console. Essendo la stessa cosa, ho ricevuto lo stesso errore.

[Fumetto]

L'errore è dato dall'ELO della versione di RHL su cui si basa SME. Personalmente ho provveduto ad aggiornare sabato notte un mailserver dalla versione 8.2 alla 9.1 utilizzando il backup e restore da console... più difficile a dirsi che a farsi!

In linea di massima puoi seguire questa procedura:
1) Stacchi dalla rete lo SME "vecchio".
2) Accedi alla console e fai il backup su periferica USB (formattata in ext3, thanks Stefano) collegandola solo quando richiesto dalla procedura
3) Installi SME 9 e durante la fase di installazione, appena te lo chiede, gli dici di fare il restore e attacchi la periferica USB sempre dopo che te lo chiede esplicitamente a schermo
4) dopo il successivo upgrade un bel "yum update", installi i contrib di cui necessiti e hai finito.

Nel mio caso l'unica "rogna" è stata quella di perdere le statistiche di sme8admin che non sono state aggiornate su sme9admin del nuovo server (in effetti ritengo che ci siano ancora le statistiche sul db o da qualche parte nel filesystem ma non me ne poteva fregar de meno il sabato notte alle 4 ).

Per fare backup e rispristino con circa 25Gb di file tgz ci sono stato circa 3 ore... per aggiornamenti più grandi (nel senso di dimensioni da spostare) si potrebbe pensare all'utilizzo di Affa (che ho già usato per passare da uno SME7 a uno SME8), sul wiki ci dovrebbero essere tutte le informazioni al riguardo. in tal caso il downtime si può ridurre a 10 minuti o poco più...

PS: Penso di aprire un NFR... non ha senso che per fare il backup la compressione gzip sia bloccata a un valore di "6"... meglio IMHO se si potesse stabilire il livello di compressione in anticipo in modo da utilizzare su hardware datato una copressione nulla (si risparmia tempo) o su hardware con molti dati una compressione più elevata (per diminuire le dimensioni del tgz).

[gromit60]

In ogni caso la 8 non si aggiorna più, è andata in EOL il 31 marzo.

[Stefano]

Mi accodo alla discussione per una domanda:
ho un sme 8 che non aggiorno da qualche mese, vorrei fare l'upgrade alla 9 tra qualche settimana, nel frattempo ho provato ad aggiornare l' sme 8 ma senza successo, ricevo errori nei repo... è normale?

direi di si

https://forums.contribs.org/index.php/topic,52058.msg274059.html#msg274059

a corollario, invito tutti a leggere sempre gli sticky topics nei forum in lingua inglese e, se possibile, a documentarsi prima di chiedere

grazie per la collaborazione

[Stefano]

PS: Penso di aprire un NFR... non ha senso che per fare il backup la compressione gzip sia bloccata a un valore di "6"... meglio IMHO se si potesse stabilire il livello di compressione in anticipo in modo da utilizzare su hardware datato una copressione nulla (si risparmia tempo) o su hardware con molti dati una compressione più elevata (per diminuire le dimensioni del tgz).

esiste già

https://wiki.contribs.org/SME_Server:Documentation:Administration_Manual:Chapter6#Option_8:_Perform_backup_to_USB_device

BTW, puoi fare di meglio su hw nuovo e multicore installando da epel pigz (la versione multithread di gzip) e creando un link simbolico ad esso al posti di gzip

i.e. una cosa tipo

Code: [Select]

cd /bin
mv gzip gzip.orig
ln -s pigz gzip

in questo modo sfrutti il processore al meglio ed i tempi si riducono notevolmente.

riguardo al backup (inteso come funzionalità su SME) sto/stiamo lavorando su più fronti (quasi tutti per SME10):
- uso di duplicity come sostituto di dar (più robusto, supporta encryption e storage in cloud): https://bugs.contribs.org/show_bug.cgi?id=10236
- utilizzo di sistemi di lock per prevenire race conditions di 2 backup che girano contemporaneamente (col risultato di non averne nemmeno uno di buono): https://bugs.contribs.org/show_bug.cgi?id=9127
- miglioramento del detect delle unità esterne, in termini di tipo, fs, spazio disponibile: https://bugs.contribs.org/show_bug.cgi?id=9299
- inclusione/esclusione di path o file dal backup in modo semplice: https://bugs.contribs.org/show_bug.cgi?id=9607
- possibilità di avere, come era una volta, il backup della sola configurazione.. questo renderebbe possibile effettuare un restore minimale e veloce su nuova installazione (a seguito di un crash o per una migrazione) avendo tutte le funzionalità presenti (ricezione ed invio della posta in primis) e permettendo un sync/restore dei file dal backup o da vecchio hw "con calma", senza quasi down dei servizi.. per questa ultima feature devo aprire NFR

@all: necessitiamo di vostro aiuto.. portare avanti lo sviluppo è oneroso in termini di tempo e risorse.. chi potesse/volesse, può dare una mano partendo da Bugzilla, anche solo per test/verifications... o, altra necessità, da pottle per le traduzioni.. chi non potesse donare tempo ed energie potrebbe donare denaro.. questo ci permette di tenere in piedi l'infrastruttura e, sperabilmente, di poter pagare dei developers per lo sviluppo di parti particolarmente ostiche.

Grazie a tutti per la collaborazione
Stefano, a nome di Koozali Inc.

[Fumetto]

esiste già

Ecco... dicevo io... many thanks (again).

[Milano1971]

direi di si

https://forums.contribs.org/index.php/topic,52058.msg274059.html#msg274059

a corollario, invito tutti a leggere sempre gli sticky topics nei forum in lingua inglese e, se possibile, a documentarsi prima di chiedere

grazie per la collaborazione

Avevo letto gli sticky topics in inglese, ma forse per la fretta non avevo trovato niente, perdonatemi.

Ad ogni modo seguendo quelle istruzioni ho aggiornato sme 8, che mi risultava aggiornato, ma poi basta un riavvio del server per riavere la precedente situazione che mi richiede di aggornare 2 pacchetti, ma che poi non scarica.
In pratica la procedura riportata funziona fino al riavvio del server.

Inoltre aggiornando ho scaricato qualcosa che mi ha messo il messaggio di warning in rosso sopra ogni pagina del servermanager, che mi informa della fine del supporto di sme 8 e mi invita a passare alla 9. Questo messaggio è molto fastidioso per me che per qualche altro mese dovrò convivere con sme 8. Sapete come è possibile eliminarlo?

[Stefano]

Ad ogni modo seguendo quelle istruzioni ho aggiornato sme 8, che mi risultava aggiornato, ma poi basta un riavvio del server per riavere la precedente situazione che mi richiede di aggornare 2 pacchetti, ma che poi non scarica.
In pratica la procedura riportata funziona fino al riavvio del server.

"non funziona" senza estratti di log o messaggi chiari serve a poco

Inoltre aggiornando ho scaricato qualcosa che mi ha messo il messaggio di warning in rosso sopra ogni pagina del servermanager, che mi informa della fine del supporto di sme 8 e mi invita a passare alla 9. Questo messaggio è molto fastidioso per me che per qualche altro mese dovrò convivere con sme 8. Sapete come è possibile eliminarlo?

è un warning, serve come memorandum, è per la tua sicurezza.. se sai di cosa si parla puoi ignorarlo e organizzarti per l'upgrade
se lo legge qualcun altro non preparato basta spiegare cosa esso significhi e perchè ci sia
se proprio non lo vuoi, puoi leggere qui:
https://lists.contribs.org/pipermail/devinfo/2017-April/014038.html
e successivi, ma dal server-manager non lo puoi togliere

[Milano1971]

"non funziona" senza estratti di log o messaggi chiari serve a poco

Il server non scaricava più gli aggiornamenti essendo in EOL, ricevevo errori dei repo, poi seguendo quelle istruzioni dal server manager ha ripreso a funzionare il tutto. Al riavvio del server, devo eseguire nuovamente la proceduta, altrimenti gli aggiornamenti dal server manager non funzionano nuovamente. Più chiaro di così

è un warning, serve come memorandum, è per la tua sicurezza.. se sai di cosa si parla puoi ignorarlo e organizzarti per l'upgrade
se lo legge qualcun altro non preparato basta spiegare cosa esso significhi e perchè ci sia
se proprio non lo vuoi, puoi leggere qui:
https://lists.contribs.org/pipermail/devinfo/2017-April/014038.html
e successivi, ma dal server-manager non lo puoi togliere

In pratica la procedura per togliere quel warning dal server-manager non c'è.
Il problema è che potrebbe portare l'utente ad ignorare anche altri messaggi di warning, non so se mi spiego...

[Stefano]

Il server non scaricava più gli aggiornamenti essendo in EOL, ricevevo errori dei repo, poi seguendo quelle istruzioni dal server manager ha ripreso a funzionare il tutto. Al riavvio del server, devo eseguire nuovamente la proceduta, altrimenti gli aggiornamenti dal server manager non funzionano nuovamente. Più chiaro di così

se hai "risintonizzato" i repo non dovresti aver problemi: dovresti arrivare a non trovare più aggiornamenti ma senza errori dovuti a repo non trovati

In pratica la procedura per togliere quel warning dal server-manager non c'è.
Il problema è che potrebbe portare l'utente ad ignorare anche altri messaggi di warning, non so se mi spiego...

a parte la richiesta di reconfigure, nessun altro warning in rosso viene mostrato (eccetto errori quando effettui delle configurazioni con valori sbagliati) nel server-manager

Premettendo che ti considero persona intelligente ed attenta, ritengo che una volta che hai visto il messaggio e compreso il suo significato tu possa mentalmente ignorarlo e concentrarti solo su quanto (di altro) ti viene mostrato a video.

Vorrei chiarire che l'intento dietro a quel messaggio non è terroristico, ma di tutela degli utenti meno smaliziati.. ogni tanto capita gente che chiede info su come manutenere/aggiustare SME7.. per noi developers/maintainers (il noi è maiestatis, non mi considero né uno né l'altro) che siamo in pochi, è fondamentale sapere che non ci siano in giro versioni potenzialmente pericolose..

anche io ho ancora (e li avrò a lungo) dei server SME8, ma non sono esposti su WAN e quindi la criticità è bassa.. tutto sta sapere cosa si rischia, il perchè il prodotto sia in EOL (non dipende da noi, è una scelta di RH) e come comportarsi

infine, "escludere" le versioni EOL dal supporto diretto ci mette nelle condizioni di poterci concentrare sullo sviluppo di SME10, che giocoforza dovrà essere rivoluzionario (samba4 AD, nuovo server-manager ecc)

[Milano1971]

Condivido pienamente tutto quello che hai scritto, anche se credo che gli utenti meno smaliziati non cercheranno mai il modo di eliminare quel warning che, come prima, condivido pienamente. Però credo che ai TUOI sme 8 non esposti su wan, quel messaggio sia meglio eliminarlo perchè potrebbe farti sfuggire il warning di reconfigure o di valori sbagliati. Questo lo dico perchè non credo proprio che un utente come te possa dimenticare che sta utilizzando un sme8 quindi in eol. 

Riguardo il primo punto, seguendo la procedura del link che mi hai inviato

https://forums.contribs.org/index.php/topic,52058.msg274059.html#msg274059

ho di fatto "risintonizzato" i repo, ma al riavvio del server perdo questa "risintonizzazione"

[Stefano]

Condivido pienamente tutto quello che hai scritto, anche se credo che gli utenti meno smaliziati non cercheranno mai il modo di eliminare quel warning che, come prima, condivido pienamente. Però credo che ai TUOI sme 8 non esposti su wan, quel messaggio sia meglio eliminarlo perchè potrebbe farti sfuggire il warning di reconfigure o di valori sbagliati. Questo lo dico perchè non credo proprio che un utente come te possa dimenticare che sta utilizzando un sme8 quindi in eol. 

a mio vantaggio il fatto che non uso praticamente mai server-manager

Riguardo il primo punto, seguendo la procedura del link che mi hai inviato

https://forums.contribs.org/index.php/topic,52058.msg274059.html#msg274059

ho di fatto "risintonizzato" i repo, ma al riavvio del server perdo questa "risintonizzazione"

ecco, questa è una cosa da verificare..

Puoi per cortesia aprire un bug con tutti i dettagli? anche se SME8 è in EOL dobbiamo "curare" questo problema

grazie

[Milano1971]

Se hai anche tu degli sme8 su cui effettuare aggiornamenti, forse sarebbe meglio che verifichi se il bug c'è realmente, non vorrei fosse un problema solo del mio server. Lo dico perchè il mio è un server non in produzione su cui ci ho pasticciato parecchio   

[Stefano]

i miei SME8 sono di un cliente non pagante ergo non aggiornabili
e sono in produzione con un paio di cinquine di TB di dati, vorrei evitare problemi