Convertire una installazione fisica in una macchina virtuale.

Pagina 1 di 2 1 2 ultimo
Visualizzazione dei risultati da 1 a 10 su 16
  1. #1
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    43
    Messaggi
    23,379
    configurazione

    Predefinito Convertire una installazione fisica in una macchina virtuale.

    E' arrivato il momento di pensionare il serverino: Ho deciso di passare l'installazione da Debian a CentOS.
    Debian si è comportata egregiamente, non ho riscontrato alcun problema: Semplicemente ho necessità di lavorare di più sulle derivate di RedHat quindi ho deciso di uniformare l'installazione alla distro che uso di più in ufficio.

    Ho però un solo hardware a disposizione quindi le alternative sono due:
    • Metto offline il server e tutto (posta compresa) rimane offline fino a quando non ho completato la nuova installazione;
    • Converto l'installazione attuale in una macchina virtuale e mi installo con calma il nuovo server, approfittando di una settimana di ferie...


    Alla fine della fiera, la seconda opzione ha la meglio anche solo per la curiosità di provare la conversione da macchina fisica a virtuale (p2v) di una installazione di linux “up&running”.

    1_ L'hypervisor: KVM.
    2_ Ottenere l'immagine del sistema operativo da virtualizzare.
    3_ Importazione dell'immagine nello hypervisor.
    4_ Alla fine della fiera...
    Ultima modifica di frakka : 09-04-2014 a 00:52

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  2. #2
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    43
    Messaggi
    23,379
    configurazione

    Predefinito 1_ L'hypervisor: KVM.

    L'hypervisor che andrò ad utilizzare come appoggio per la conversione è KVM, che è la soluzione di virtualizzazione che RedHat ha adottato come “predefinita” dalla release 6, in sostituzione di Xen Server.

    Libera traduzione dal sito linux-kvm.org:
    Kernel Based Virtual Machine
    KVM (acronimo di Kernel-based Virtual Machine) è una soluzione di virtualizzazione completa per Linux su hardware x86 dotato di estensioni di virtualizzazione (Intel VT o AMD-V). Consiste in un modulo del kernel, kvm.ko, che costituisce il nucleo dell'infrastruttura di virtualizzazione ed uno modulo specifico per la CPU della macchina host, kvm-intel.ko o kvm-amd.ko. [...]
    Usando KVM, è possibile eseguire più virtual machines che eseguono immagini non modificate di Linux o Windows. Ogni virtual machine ha il proprio hardware esclusivo: una scheda di rete, disco, adattatore grafico, etc.
    Il componente kernel di KVM è incluso nel ramo principale di Linux dalla versione 2.6.20.
    KVM è software open source.

    Status
    KVM è incluso in ramo principale di sviluppo del kernel linux dalla versione 2.6.20 ed è sufficientemente stabile e veloce per molte tipologie di utilizzi.
    [...]
    Feature supportate:
    • Host fisici Intel-based (richiede processori dotati di estensioni VT)
    • Host fisic AMD-based (richiede processori dotati di estensioni SVM)
    • Host virtuali Windows/Linux/Unix (32-bit e 64-bit)
    • Sistemi fisici SMP (multiprocessore)
    • Sistemi virtuali SMP (fino a 16 cpu virtuali)
    • Migrazione Live di sistemi guest da una macchina fisica ad un'altra (32-bit e 64-bit)
    • […]
    • Supporto alla paravirtualizzazione dei dispositivi di rete
    • Supporto alla paravirtualizzazione dei dispositivi a blocchi
    • PCI-Express passthrough
    • Guest swapping


    In fase di realizzazione:
    • Port su architetture PowerPC
    • Port su architetture IA64
    • Port su architetture ARM
    • [...]

    Il pc che andrà a costituire l'host fisico che ospiterà la virtual machine è un muletto così composto:

    • Sapphire A85XT
    • APU AMD A-5800K
    • 8Gb di ram GSkill 1866
    • Scheda di rete aggiuntiva su PCI 10/100
    • WD CaviarBlack da 1Tb


    Il sistema operativo scelto per eseguire KVM è CentOS 6.4 a 64bit, che è la distro che andrà ad usare anche per la nuova installazione del serverino. Tutto l'hardware essenziale è riconosciuto e funzionate senza interventi particolari: Per l'installazione dei driver Catalyst AMD è necessario utilizzare l'ultima beta disponibile perchè l'APU non è ancora supportata dalla release stabile corrente ma il sistema si avvia comunque in modalità grafica usando il driver generico. Non ho verificato il funzionamento del bluetooth perchè non mi interessa assolutamente...
    Niente RAID ma l'installazione deve rimanere in funzione (spero, salvo problemi) solo pochi giorni... Praticamente solo il tempo di installare la nuova distro sul server fisico e migrare i servizi essenziali.
    Ultima modifica di frakka : 07-10-2016 a 09:22

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  3. #3
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    43
    Messaggi
    23,379
    configurazione

    Predefinito 2_ Ottenere l'immagine del sistema operativo da virtualizzare.

    Ottenere l'immagine del sistema operativo è la parte forse più interessante dell'intera operazione.

    C'è il metodo "facile" che consiste nello spegnere il server e copiare il disco "offline" ed il metodo "figo" che permette di salvare su un altro computer della rete un'immagine funzionante di un sistema operativo “live & running”, senza spegnerlo ne fermare i servizi in esecuzione.
    Dato che il metodo facile non presenta alcun difficoltà, mi sono messo a cercare qualche guida che permetta di eseguire il secondo metodo. Il problema principale è che ho utilizzato una schema di partizionamento che non permette la realizzazione di snapshot live del filesystem, altrimenti si poteva usare quello.

    Mi sono messo alla ricerca ed ho trovato questo articolo in cui l'autore spiega come ottenere l'immagine consistente di un sistema avviato attraverso una connessione di rete. Questa strada può essere seguita (è il caso del post) anche per effettuare l'immagine di un sistema attraverso internet, con le limitazioni derivanti dalla banda disponibile, ma è sicuramente estremamente interessante:

    Copy the disc

    At the destination server start netcat listening to a port (in this example 43333), redirecting all its input to a file. If you connect using SSH do it in a screen so you can close the session.
    nc -nvv -w30 -l 43333 | gzip -dc > disk.raw

    At the origin server use dd to dump its disk. It is then compressed and sent to the netcat at port 43333 waiting with the command above. Gzip compresses the stream and reduces the amount of data to be transferred over the net. Our disk was 72 GB and took 4 hours to 10 Mbps, via the Internet.
    dd if=/dev/cciss/c0d0 | gzip -c | nc -w30 -vvn your_server_address 43333
    L'operazione non è esente da rischi: Fare l'immagine a sistema acceso senza ricorrere agli snapshoot, comporta elevate possibilità che l'immagine risultante abbia qualche problema. Per minimizzare questi rischi e velocizzare le operazioni è utile ridurre al minimo le attività del server, arrestando i servizi non indispensabili prima di procedere alla copia.
    La guida linkata concatena il comando netcat (nc) utilizzato per trasmettere i dati via rete (ricordarsi di aprire le porte utilizzate nei firewall!!!) con il comando “gzip” per comprimere il flusso dei dati in realtime sul server sorgente prima di trasmetterlo e decomprimerlo, sempre realtime, sul server di destinazione:
    codice:
    nc -nvv -w30 -l 43333 | gzip -dc > disk.raw
    dd if=/dev/cciss/c0d0 | gzip -c | nc -w30 -vvn your_server_address 43333
    A differenza dell'autore dell'articolo che ha a disposizione molta cpu e poca banda (un server vero, probabilmente HP, ed una connessione 10Mbps) io ho molta banda e pochissima cpu (scheda madre con processore Atom su rete LAN Gigabit). Non è quindi utile utilizzare la compressione, perchè il carico di lavoro aggiuntivo finirebbe per essere controproducente.
    Ho fatto comunque un prova per dimostrarlo e la differenza è abissale: Lo screen sulla sinistra mostra la velocità dell'operazione di clone usando la compressione del flusso dati, nel secondo la stessa operazione senza la compressione.


    Nel primo caso il processo di compressione cappotta il mio serverino: il processo gzip usa un core al 100% ma ottengo una velocità di trasferimento ridicola. Rimuovendo invece la compressione realtime (sia dalla trasmissione che dalla ricezione, ovviamente) la velocità di trasferimento migliora decisamente, il carico sulla CPU è elevato ma la velocità di trasferimento è rispettabile e arrivo vicino a saturare la banda della Gigabit. Qui credo che il limite sia il controller dei dischi, un vecchissimo ICH6:
    codice:
    nc -nvv -w30 -l 43333 > /var/lib/libvirt/images/debian_nc.img
    dd if=/dev/sdb bs=4096 | nc -nvv -w30 192.168.200.208 43333
    Per informazione, netcat non è l'unico strumento che permette di ottenere lo stesso risultato: E' possibile, anzi, incapsulare il flusso dei dati attraverso un tunnel criptato per effettuare, ad esempio, il trasferimento attraverso internet in massima sicurezza sfruttando ssh:

    codice:
    dd if=/dev/sdb bs=4096 | ssh root@192.168.200.50 'cat > /var/lib/libvirt/images/debian_ssh.img'
    Questa modalità permette anche di non dover avviare un processo in ricezione sulla macchina di destinazione ma permette di fare tutto dal sistema di cui si stà facendo l'immagine. Anche in questo caso, però, l'overhead dato dall'attività di cifra del dato in uscita è proibitivo per il mio serverino:


    Sicuramente, in presenza di una connessione più lenta attraverso una rete pubblica questo metodo è una validissima soluzione.
    Il trasferimento in rete locale di un'immagine da 32Gb perfettamente funzionante ha richiesto circa 22 minuti:

    codice:
    root@server:/home/matteo# dd if=/dev/sdb bs=4096 | ssh root@192.168.200.50 'cat > /var/lib/libvirt/images/debian_ssh.img'
    root@192.168.200.50's password: 
    7816662+0 records in
    7816662+0 records out
    32017047552 bytes (32 GB) copied, 1304.66 s, 24.5 MB/s
    Netcat senza compressione è quindi la mia scelta per l'operazione. Tempo stimato per il completamento: Poco più di 7 minuti per fare l'immagine del disco da 32Gb, meno di 50 minuti per fare l'immagine completa di un disco da 250Gb:

    codice:
    root@server:/home/matteo# dd if=/dev/sda bs=4096 | nc -nvv -w30 192.168.200.50 43333
    (UNKNOWN) [192.168.200.50] 43333 (?) open
    61049646+0 records in
    61049646+0 records out
    250059350016 bytes (250 GB) copied, 2938.98 s, 85.1 MB/s
     sent 951246848, rcvd 0
    La comparsa sulla macchina sorgente in fase di avvio della copia del seguente messaggio di errore indica semplicemente che non è stata aperta nel firewall della macchina di destinazione la porta indicata per il trasferimento dati:

    codice:
    (UNKNOWN) [192.168.200.50] 4333 (?) : No route to host
     sent 0, rcvd 0
    Ultima modifica di frakka : 03-10-2016 a 08:40

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  4. #4
    Moderatore L'avatar di italian soldier
    Registrato
    Jan 2006
    Località
    Bergamo
    Età
    43
    Messaggi
    7,414

    Predefinito

    Bella Frakka mi piace un sacco. KVM sta diventano una soluzione sempre più all'avanguardia. Ottimo lavoro!

    Il futuro, di nuovo ignoto, scorre verso di noi, e io lo affronto per la prima volta con un senso di speranza, perché se un robot, un Terminator, può capire il valore della vita umana, forse potremo capirlo anche noi.

  5. #5
    ●⁞◌ Ȏrȉzzȏntέ Ðέglȋ ȨvέntȊ ◌⁞●
    Registrato
    Aug 2008
    Località
    Palermo
    Messaggi
    2,952

    Predefinito

    Bene, stai portando avanti anche la serie di commenti, indicazioni e tip di indubbio aiuto.




    KVM è un gran passo avanti per le necessità in cui ti sei venuto a trovare seppur nei limiti,
    a livello concettuale e di architettura (peraltro non necessariamente penalizzanti), di un
    hosted hypervisor rispetto ad una soluzione bare metal come quella che avevi con Xen.

    Voglio dire che in ambito sicurezza, ed in qualche modo anche affidabilità, avere l'hypervisor
    che lavora a livello kernel, non dovrebbe rappresentare, a puro livello concettuale la miglior
    soluzione.

    Non ho idea se avessi già preso in considerazione l'analoga soluzione (open source) ProxMox VE
    (bare metal) ed eventualmente le motivazioni alla base della non-scelta.

    ProxMox VE è sempre basato su KVM e OpenVZ, ma tale prodotto avrebbe anche concesso la
    possibilità di allocare le immagini delle VM a livello nativo su storage condiviso, di tipo iSCSI ed NFS,
    caratteristica di cui, se non vado errato, è priva KVM.

    O meglio, probabilmente è prevista ma non implementata allo stesso livello di gestibilità con la quale
    ProxMox VE supporta volumi logici a livello cluster (CLVM) come blocchi di storage.

    Questa modalità sarebbe, teoricamente, in grado di evitare fastidiosi overhead al momento che il guest
    debba ricorrere a ripetuti accessi, a livello di filesystem, sul sistema host.

    Credo che tali overhead, a.e., possano iniziare a manifestarsi allorché lo spazio di memorizzazione a
    disposizione cominci in qualche modo ad esser stretto.

    Per tutto il resto, ottimo lavoro.


  6. #6
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    43
    Messaggi
    23,379
    configurazione

    Predefinito

    Scusate se ho tardato le risposte... Sono parecchio in banana perchè la migrazione su CentOS si stà rivelando più problematica del previsto: Ad averlo saputo prima, non sò se l'avrei fatto lo stesso...

    La scelta di KVM è stata dettata semplicemente dal fatto che è la soluzione che RedHat ha scelto come "predefinita" per le sue soluzioni di virtualizzazione ed è quella che può essere richieste in sede di esame RHCSA.
    La scelta di passare a CentOS è dovuta al fatto che, in sede di verifica degli skill per decidere a quale certificazione RH puntare, è emerso un livello di conoscenza Linux piuttosto buono e un livello di conoscenza delle peculiarità di RedHat molto basso... Quindi dato che CentOS la usiamo anche in ufficio, ho deciso di sacrificare Debian per mantenere Arch sul desktop e RedHat/CentOS sui server.

    Sicuramente questa soluzione, su mulettino con storage locale, non può aspirare a grandi prestazioni ma KVM supporta la migrazione live di virtual machine e quindi, per forza di cose, anche le soluzioni di storage avanzate condivise, senza la quali la migrazione di una vm tra host fisici non sarebbe possibile.
    Ultima modifica di frakka : 08-08-2013 a 00:35

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  7. #7
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    43
    Messaggi
    23,379
    configurazione

    Predefinito 3_ Importazione dell'immagine nello hypervisor.

    La procedura di importazione, trattandosi dell'immagine di una macchina fisica su un partizionamento tradizionale, è talmente banale da essere quasi noiosa... KVM prevede degli script per la migrazione di virtual machine provenienti da altri sistemi di virtualizzazione ma in questo caso non c'è da fare assolutamente nulla: E' sufficiente creare la macchina virtuale, collegarvi l'immagine così ottenuta e avviare la virtual machine.


    Nel mio caso, la virtual machine ha bisogno di due schede di rete perchè funzionava come gateway per la rete locale: Per mantenere inalterata la funzionalità e potermi reinstallare con calma il server sull'hardware fisico ho aggiunto una seconda scheda fisica alla macchina host e ho creato sul server fisico due interfacce "bridge" a cui collegare le schede di rete della virtual machine.


    L'unica operazione di riconfigurazione "necessaria" è la semplice cancellazione dal file "/etc/udev/rules.d/70-persistent-net.rules" delle righe presenti e relative alle vecchie interfacce di rete.
    (Lo screen qui sotto si riferisce alla macchina virtuale già "ripulita", al primo avvio le righe erano 4):


    Si cancellano le righe presenti (ci sono anche quelle relative alle nuove schede di rete, si può cancellare tutto senza problemi tanto al riavvio le ricrea, oppure si possono modificare "correttamente" se non si vuole o può riavviare), si riavvia il server e fine del cinema: La macchina virtuale così convertita è di nuovo up&running con tutti i servizi funzionanti come lo erano sull'hardware fisico.

    Ovviamente il sistema di monitoraggio del RAID si lamenta della mancanza di un disco: Questa è forse la parte più fastidiosa della conversione perchè, per fare le cose per bene, ci sarebbe da spiegare all'installazione che è più su un dispositivo RAID ma deve puntare al disco singolo...
    Ma nel mio caso non ne ho bisogno: La macchina convertita può benissimo rimanere così per qualche giorno, poi andrà definitivamente spenta quindi il gioco non vale la candela.

    That's all Folks!
    Ultima modifica di frakka : 03-10-2016 a 08:43

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  8. #8
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    43
    Messaggi
    23,379
    configurazione

    Predefinito Alla fine della fiera...

    Per migrare tutti i servizi dal server debian al server su CentOS ci sono voluti, alla fine, quasi 5 giorni di cui 3 in full immersion nonostante abbia attinto a piene mani dal lavoro già fatto per il server Debian e sui server CentOS che abbiamo in ufficio.
    Sono arrivato al punto che non ce la facevo più a stare davanti al pc e non mi era mai successo prima...

    Ho portato da Debian 6 a CentOS 6.4:
    • Configurazione RAID: A quanto pare, dalla versione precedente del kernel CentOS fà del casino con l'enumerazione dei dispositivi in fase di boot... Quindi i dischi fissi vengono sempre "visiti" dopo le periferiche USB con una serie di rogentte in fase di installazione del bootloader...
    • Semplicissima share Samba che con SELinux qualche problema me lo ha dato...
    • Mail server (iRedMail, postfix + Dovecot). Ne ho approfittato per una modifica alla configurazione di Dovecot per permettere l'uso del "." nei nomi delle directory. Sembra una cavolata ma per qualche motivo il "." viene usato al posto di qualche simbolo astruso come separatore e non può essere utilizzato in uno spazio dei nomi IMAP su dovecot senza modifiche alla configurazione. Ok, la modifica era piuttosto semplice ma per riuscire a capire dove farla e come farla funzionare non è stato altrettanto facile... Comunque è andata.
    • Server FTP. Qui ci sono state le maggiori bestemmie... Per autenticare gli utenti virtuali su Debian utilizzavo un modulo PAM (pam_pwdfile.so) che per RedHat/CentOS non esiste come pacchetto precompilato... E inoltre ha altri problemi con CentOS ed in particolare con la versione a 64bit. Ho dovuto ravanare per la rete alla ricerca di due diverse patch dei sorgenti prima di riuscire a compilarne una versione funzionante su CentOS.
    • Webmail. Ho rimpiazzato il "RoundCube" fornito di default con iRedMail con SOGo 2.x Non che RoundCube non facesse il suo lavoro ed in realtà SOGo è molto di più che una semplice webmai. SOGo E' una suite di collaborazione che permette la creazione e gestione di calendari privati e condivisi, inoltre è dotata di moduli e connettori per il collegamento e la sincronizzazione con praticamente ogni dispositivo mobile. Nonostante tutto, questa è stata forse la parte più semplice da tirare in piedi... Anche se non ho ancora preso a mano la parte "mobile", per questa rimando a Settembre!


    Problemi riscontrati:
    • Se dovete installare CentOS su un dispositivo non provvisto di lettore ottico e non avete a disposizone un server PXE... Auguri!!! L'unico modo in cui sono riuscito ad avere un'immagine bootabile da una stupida chiavetta USB è stato usare unebootin. Con tanti saluti al semplicissimo "dd" usato per fare la stessa operazione prima dell'installazione di Debian.
    • Disponibillità di pacchetti binari precompilati: Certo, il parco disponibile è estremamente ampio ma ancora non ai livelli di quello disponibile per Debian.
    • Difficoltà di crearsi un pacchetto RPM per "tenere da parte" una libreria che è stato particolarmente difficile procurarsi... Su Debian la generazione di un pacchetto .deb per installare, ad esempio, trasmission-daemon in una versione non compresa nei repository Debian è stato piuttosto semplice. Compilare correttamente una file .spec per creare un RPM "corretto" lo è decisamente meno... Alla fine, mi sono tenuto da parte il modulo nudo e crudo.
    • SELinux è stato lasciato disattivato... E' richiesto da iRedMail ma mi riprometto di studiare meglio la gestione di policy personalizzate per poterlo riattivare.
    • awstats con "basic auth" per l'accesso alle statistiche del server non mi permette l'accesso, rimbalza sempre le credenziali... La configurazione è quella predefinita di iRedMail e non ho sminchiato nulla (credo!)... Boh...


    To do:
    • Test dei connettori mobile per SOGo.
    • Volevo aggiornare la versione di transmission-daemon a qualcosa di più recente e mi stuzzicava anche l'idea di passare vsftpd alla versione 3.x... Ma ovviamente per entrambi è tutto da compilare a manina,,,
    • Buttare giù la guida per l'integrazione di iRedMail con la versione 2.x di SOGo dato che non mi pare ci sia nulla di già scritto.


    Buonanotte!!
    Ultima modifica di frakka : 03-10-2016 a 08:44

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  9. #9
    ●⁞◌ Ȏrȉzzȏntέ Ðέglȋ ȨvέntȊ ◌⁞●
    Registrato
    Aug 2008
    Località
    Palermo
    Messaggi
    2,952

    Predefinito

    Quando hai accennato al lavoro da svolgere avevo immaginato a tutta una serie di piccole, subdole
    problematiche: che tutto avesse poi immediatamente funzionato, non era poi così scontato.

    Ti sei trovato a dover portare a termine un lavorone, e se te ne sei dovuto occupare da solo, devo
    anzi dire che hai avuto sapientemente modo di accelerare comunque i tempi!


    Originariamente inviato da frakka
    [...]

    • awstats con "basic auth" per l'accesso alle statistiche del server non mi permette l'accesso, rimbalza sempre le credenziali... La configurazione è quella predefinita di iRedMail e non ho sminchiato nulla (credo!)... Boh...

    [...]
    per quanto riguarda questa fastidiosa situazione, prova a controllare (se non l'avessi già fatto)
    utente e password che si siano andati ad inserire nello stats all'interno di ireadmail.tips


    Spero possa aiutarti.

  10. #10
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    43
    Messaggi
    23,379
    configurazione

    Predefinito

    Purtroppo avevo già verificato...
    Ho aperto una segnalazione sul forum di iRedMail... L'installazione è nuova e praticamente stock, non mi spiego quindi perchè non funzioni.
    Potrebbe essere un problema con la cifratura utilizzata per riscontrare la password verso ldap??

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

Pagina 1 di 2 1 2 ultimo

Informazioni Thread

Users Browsing this Thread

Ci sono attualmente 1 utenti che stanno visualizzando questa discussione. (0 utenti e 1 ospiti)

Tags

Regole d'invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
nexthardware.com - © 2002-2022