Close

Not a member yet? Register now and get started.

lock and key

Sign in to your account.

Account Login

Forgot your password?

Come ho trasferito dominio e hosting

03 Set Posted by in Uncategorized | Comments

Quello che segue è il procedimento che ho seguito per il trasferimento del mio blog (dominio e hosting) da un gestore (Aruba) all’altro (OVH).
Ho voluto condividerlo perché è la prima volta che mi capita di fare una operazione simile (di solito i domini li apro direttamente sul gestore che ritengo più adatto per l’esigenza specifica), quindi la mia esperienza può essere paragonabile a quella di qualsiasi newbie che si trova nella stessa situazione e non sa dove sbattere la testa.

Come dicevo, io ho scelto di portare tutto su OVH.
Come prima cosa mi sono creato un identificativo cliente (o NIC-handle) sul loro portale.
Poi ho acquistato un piano di hosting condiviso su OVH, indicando che si trattava del trasferimento di un dominio esistente.
A questo punto le operazioni da compiere sono tre:

  • il trasferimento dei file di installazione di WordPress
  • il trasferimento del database
  • il trasferimento del dominio.

Procediamo con ordine.

Trasferimento dei files di WordPress

Mi sono collegato via FTP all’hosting corrente e ho trasferito in locale i file dell’installazione di WordPress.

Fatto questo, mi sono collegato al manager di OVH, molto completo: da qui posso gestire praticamente di tutto.
Nella sezione di gestione dell’hosting posso utilizzare uno dei tanti moduli che mettono a disposizione per installazioni guidate: WordPress, Drupal, Joomla, SugarCRM, phpBB, coppermine, oscommerce e altri.
Purtroppo la versione di WordPress che hanno in linea non è l’ultima ma è la 2.9.1.: il mio consiglio spassionato è quello di installare comunque questa versione, se non altro perché imposta i permessi di file e cartelle esattamente come il server di OVH si aspetta che siano (per esempio, OVH non ammette permessi di tipo 777).
Una volta terminata l’installazione guidata, si può effettuare l’aggiornamento di core e plugin dal solito pannello di amministrazione all’interno di WordPress.

L’alternativa è quella dell’installazione manuale, un percorso certamente più difficoltoso, che poi è quello scelto consapevolmente e masochisticamente da me. Ripeto: seguite l’altra strada!
In ogni caso, ho trasferito i files di installazione che mi ero precedentemente salvato e rettificato uno per uno i permessi di migliaia di file e cartelle (più che altro perché non mi fidavo della loro installazione standard).
Per fare questo, ho creato un identificativo per l’accesso FTP sui loro server: come indirizzo ho utilizzato quello temporaneo che mi hanno comunicato quelli di OVH, dal momento che ftp.myweb20.it punterà ancora ai vecchi server fino a quando il trasferimento del dominio non diventerà effettivo.

Trasferimento del database di WordPress

Mi sono collegato al pannello phpMyAdmin sull’hosting corrente per esportare il db: qui suggerisco vivamente di attivare l’opzione “Disabilita i controlli sulle chiavi straniere” (o “foreign keys“, a seconda delle vostre impostazioni di lingua), così da poter caricare i file dati in qualsiasi sequenza cronologica e non perdere per strada parte delle righe delle tabelle.
Dal momento che l’interfaccia phpMyAdmin di OVH (destinazione) non legge i file SQL di dimensioni superiori a 16 Mb, occorre spezzare quelli che eccedono questo limite: tipicamente, capita con tabelle con almeno qualche decina di migliaia di righe.
In questi casi, io ho preferito non spezzare il file di testo generato ma generare file distinti già all’origine, perché ci sono alcune istruzioni che devono ripetersi all’interno di ogni file che genereremo. Prendendo come esempio la tabella wp_wassup (quella contenente le statistiche degli accessi al blog), ho cercato di identificare una colonna partizionabile su un sottoinsieme limitato di valori distinti (diciamo al massimo una decina).
Visto che nessuna aveva queste caratteristiche, ho considerato il primo carattere della colonna IP, che contiene i valori da 1 a 9.
Dal pannello di esecuzione di comandi SQL ho lanciato la stringa SELECT count(*) FROM `wp_wassup` WHERE ip like ‘1%’, quindi ho cliccato sul tasto “esporta“: occorre fare attenzione a utilizzare la funzione di esportazione dei risultati della query (in basso nella pagina) e non quella relativa all’intero contenuto della tabella (in alto nella pagina).
Questo passaggio l’ho ripetuto quindi nove volte, ottenendo altrettanti file.

A questo punto mi sono collegato al manager OVH e ho creato un database su cui importare le tabelle di WordPress.
Fatto ciò, tramite il pannello di phpMyAdmin ho importato il db, file per file (avendo cura di verificare, per scrupolo, che il totale dei record di ogni tabella corrispondesse tra i due ambienti).

Trasferimento del dominio

Io ho deciso che, per comodità, oltre all’hosting voglio gestire su OVH anche il dominio: in caso contrario dovrei far puntare i DNS del dominio esterno (Aruba) all’indirizzo IP del piano di hosting di OVH, così come ben spiega Andrea Beggi.
Da notare che OVH non mi fa pagare il trasferimento del dominio se lo richiedo contestualmente all’acquisto dell’hosting.

La procedura di trasferimento di un dominio (e quindi del suo DNS) cambia a seconda di alcuni fattori.
Anzitutto all’interno delle procedure da seguire possiamo distinguere quattro soggetti diversi: il Registro, il Mantainer, il Registrante (noi) e il Registrar.

Il Registro, gestito dal CNR, è il Database dei Nomi Assegnati, cioè tutti i dati relativi alle assegnazioni dei domini .it: per questo motivo, ogni modifica su questi domini (nel mio caso, il trasferimento da un gestore all’altro) deve essere comunicata al Registro.

La prima cosa da fare è verificare se attualmente il dominio viene gestito da un Mantainer o da un Registrar, perché nel primo caso le comunicazioni sono cartacee, mentre nel secondo caso si svolgono on-line.
Dal primo gennaio 2011 (finalmente!) invece non ci sarà più questa distinzione perché esisteranno solo i Registrar.

Per fare questa verifica si può usare il servizio whois, che è disponibile su parecchi siti: io, per esempio, ho usato quello del NIC.
Digito il nome del mio dominio nel riquadro “whois” in alto a destra, clicco sul link “whois” in basso e guardo se accanto al nome del gestore c’è MNT o REG.
Già che ci sono, posso anche vedere come si chiamano gli attuali server DNS, cioé dns.technorail.com e dns2.technorail.com.
Ripetendo questa verifica a trasferimento avvenuto, al loro posto dovrò trovare i DNS del nuovo Registrar.
Di queste informazioni che leggo, ce ne sono diverse che possono essere modificate sia dal Mantainer che dal Registrante, come per esempio il nome dell’uno o dell’altro.
Appurato che nel mio caso si tratta di un Mantainer, scarico il modulo che mi interessa e lo trasmetto via fax al Registro.

La seconda cosa da fare è legata al tipo di dominio di primo livello.
Nel caso di dominio .com, .net, .org, .biz, .info e .mobi, per effettuare un trasferimento presso un altro Registrar occorre farsi dare l’Auth-code dal Registrar attuale.
Nel caso di dominio .it occorre verificare se è registrato con un Registrar, anziché con un Mantainer, perché in questo caso occorre farsi dare il codice AuthInfo (che non esiste in caso di Mantainer).
L’Authinfo è un codice che viene assegnato al momento della registrazione e che identifica in modo univoco il dominio: il Registrar è tenuto a comunicare al Registrante questo codice, indispensabile per poter eseguire tutte le operazioni; il Registrante lo comunicherà a sua volta al nuovo Registrar.

ATTENZIONE!
1) Per completare tutte le attività per il trasferimento di un dominio scaduto si hanno 15 giorni di tempo, dopodiché questo viene riassegnato al gestore iniziale.
E’ un periodo di tempo adeguato, però non bisogna prendersela troppo comoda perché ci sono tempi di attesa che non dipendono solo da noi, senza contare che possono verificarsi errori umani.
L’ideale è anticipare la data di scadenza del dominio e, se occorre, chiedere direttamente al NIC se ci sono problemi nel completamento della procedura.

2) Se il modulo della richiesta da spedire al NIC non è compilato correttamente o se è incompleto, la nostra richiesta verrà respinta senza che qualcuno ce ne dia comunicazione e senza saperne il motivo!
Se abbiamo un dubbio di questo tipo, possiamo chiedere al futuro Mantainer (o Registrar) di fare questa verifica, visto che lui ha accesso a queste informazioni.
Faccio un esempio: se indico il codice fiscale e la località di nascita (da notare che quest’ultima è inutile perché già compresa nel codice fiscale) ma non la provincia di nascita (ancora più inutile), il NIC scarterà la richiesta.
Ovviamente, le persone nate all’estero dovranno indicare anche la nazione.

3) E’ sempre meglio farsi dare i moduli dal nuovo gestore del nostro servizio, facendosi indicare il link preciso da cui scaricarlo: i moduli cambiano a seconda delle casistiche, che sono veramente tante.
E’ meglio non riciclare mai il modello di un modulo che abbiamo scaricato mesi prima, perché nel frattempo potrebbe essere cambiato qualcosa: per esempio, con i Mantainer che entro fine anno diventano Registrar, occorre obbligatoriamente indicare sulla richiesta una informazione in più, cioè il contactID.

Per tutte le casistiche diverse dalle mie, segnalo la documentazione per i trasferimenti asincroni (da mantainer a mantainer) che cesserà di essere utilizzata a fine anno e la documentazione per i trasferimenti sincroni.

Finalmente, riecco il blog!

A questo punto sul nuovo hosting ci sono i file e il db dell’installazione WordPress, ho fatto tutte le comunicazioni che occorrevano….
Dopo mezza giornata mi arriva la comunicazione di OVH che l’operazione di trasferimento è conclusa: ora posso andare nel loro pannello di controllo e impostare i nuovi nameserver per i record NS: questo aggiornerà quasi istantaneamente anche il Db del Registro.
Non mi resta che aspettare che tutta Internet recepisca i nuovi indirizzi, processo che di solito si conclude entro 36-48 ore.

In tutto questo cosa ho imparato?

  • E’ meglio farsi aiutare da qualcuno più esperto, sia per gli aspetti tecnici che per quelli burocratici
  • In caso di necessità non bisogna esitare a contattare il registrar e, se serve, anche il NIC
  • I moduli vanno controllati e ricontrollati prima della spedizione
  • Mentre aspettiamo che diventi effettivo il trasferimento del dominio, è meglio fare una installazione di prova sui server del nuovo gestore (alcuni forniscono indirizzi temporanei per fare ciò) oppure in locale su XAMPP
  • Il livello di servizio di un fornitore lo valuti meglio nel momento del bisogno
  • Il pannello di controllo e le persone del servizio clienti di OVH sono troppo nerd per i miei gusti: dovrebbero essere maggiormente aperti verso persone che vogliono semplicemente pubblicare e condividere contenuti su uno spazio web e non sanno (o non vogliono sapere) troppi tecnicismi. Oltre a questo, alcuni servizi e alcune pagine di documentazione sono scritte in lingua francese: non è il massimo della comodità.
    Purtroppo le stesse limitazioni (problema di lingua a parte) le ho notate anche nei pannelli di controllo di altri gestori (Aruba e Serverplan).

Probabilmente avrei potuto scegliere percorsi migliori, però ho imparato molte cose e, anche se ogni migrazione è una storia a sé, credo che tutto questo mi potrà tornare utile la prossima volta.

 


Leave a comment