MySQLDumper - Pareri e Osservazioni

56 contenuti / 0 new
Ultimo contenuto
MySQLDumper - Pareri e Osservazioni

Ciao a tutti!

Ho installato e testato MySQLDumper > http://www.mysqldumper.net/ e sono rimasto personalmente molto soddisfatto anzi, impressionato per la sua stabilità, sicurezza (spero...) e modalità di azione - Oltre a molte opzioni di Split - CronJob (credo tipo Backup and Migrate...), oltre alla sua capacità di "risolvere" e superare il time-out di 30 sec. dei più diffusi Shared Hosting senza che appaia nessun messaggio di interruzione...

Il mio obiettivo è quello di avere un sistema di Backup/Restore di MySQL il più semplice e indolore possibile senza ricorrere a linee di comando etc etc... - In pratica tutto tramite interfaccia web.

Lo script salva il backup del database in formato "GZip" - Il test che ho effettuato si è basato su un file *.sql; dal peso (senza compressione...) di 29,7MB che MySQLDumper ha ridotto/compresso con l'operazione di Backup a 2,43MB

Ho cancellato alcuni "nodi" in un'installazione "test", fatto partire il Restore e tutto è tornato perfettamente come prima (tempo impiegato per il restore circa 4 min. [non c'è stata nessuna interruzione causata dal time-out o quant'altro...])

Ora, riferendomi a questo post > http://www.drupalitalia.org/node/11106 (circa al #23) dove l'amico Pescetti fa notare il rischio potenziale di un'eventuale perdita di dati e dove spiega anche la questione qui > http://nuvole.org/blog/2010/apr/03/drupal-database-backup , vorrei sapere dagli esperti se, con questo script (MySQLDumper, appunto...) il problema si risolve e i backup/restore possono essere considerati "sicuri"

Tutto qui...

P.S. Personalmente, da alcune prove che ho fatto, MySQLDumper potrebbe creare dipendenza e mi domando (per quel poco che ho potuto testarlo...), se a questo punto ha ancora senso usare il modulo Backup and Migrate oppure fare i backup/restore tramite linea di comando... che sono anche un poco allergico...

Da profano quale sono in fatto di altri metodi di backup/restore (ho sempre operato con phpMyAdmin splittando i files SQL con SQLDumpSplitter...), mi scuso anticipatamente se questo mio post dovesse contenere da parte mia una certa dose di ingenuità... abbiate pazienza, qui le cose da tenere a bada sono molte!

http://www.mysqldumper.net/

Grazie

Ciao
Kipper

Interessante argomento. Io uso Backup&Migrate e non mi è chiaro cos'altro mi potrebbe servire. Attendo anche io qualche info in più da chi ha qualcosa da dire.

ci ho dato un occhio a mysqldumper, sembra un ottimo prodotto, però ho visto solo il video dimostrativo non ho avuto tempo di provarlo. :)
va installato sul server e non centra nulla però con drupal, cioè posso farmi i backup dei db qualunqui essi siano, questo credo sia la cosa principale che lo diversifica da backup and migrate di drupal.

ps non sono riuscita a capire se riesce a bypassare i limiti di grandezza che di solito ha phpmyadmin per uploadare un db (che se ricordo bene sono di 8mb per db).

da come si presenta sembra una ottima soluzione da testare.
Compliments

esiste un programmino php - free per fare i truncate delle query extra lunghe : ma è un pacco infinito

Lavatrice ad ultrasuoni
Sito http://www.ultrasuoni.net > Client service and contacts: [email protected]

l'installazione è semplice:
una volta scompattato MySQLDumper1.24stable.zip vai nella cartella mysqldumper > ReadMe > install_italiano e ci sono le istruzioni

Ho uploato (come dicevo nel post precedente...) un backup di 29,7MB compresso in GZip a 2,43MB - ci ha messo 4 minuti ma non c'è stato nessun time-out...

Secondo me vale la pena spendere 2 ore per leggere tutte le info su > http://www.mysqldumper.net/ e testarlo andando ad esplorare tutte le funzionalità e facendo un pò di prove

L'installazione è semplicissimabasta inserire: hostname - user - pass di MySQL e seguire le istruzioni

P.S. C'è anche la lingua italiana da scegliere in fase di install - perfettamente tradotto

Secondo me è ottimo; mai aveevo trovato un sistema per bypassare il time-out e poi, se il backup supera la dimensione massima caricabile, puoi scegliere l'opzione per splittare e definire anche quanti MB deve pesare ogni singolo file splittato - c'è anche un cronjob per programmare backup in automatico insomma, inviterei a provarlo anche per avere il riscontro da users più esperti!

Ciao
Kipper

@melissa - va installato sul server e non centra nulla però con drupal, cioè posso farmi i backup dei db qualunqui essi siano, questo credo sia la cosa principale che lo diversifica da backup and migrate di drupal

Yes!

Rileva tutti i database di ogni applicazione/cms/drupal/civicrm/wordpress/joomla!/coppermine/oscommerce... sul server ed è completamente indipendente/isolato da tutto... posso affermarlo con una certa sicurezza per via del fatto che non ho ancora finito tutti i test...

Ciao
Kipper

qui varie soluzioni

http://codex.wordpress.org/Backing_Up_Your_Database

in alternativa a phpmyadmin c'è o comando diretto
o interfaccia MySQL Workbench o altre interfaccie;

---
riguardo Phpmyadmin :
come mai non hanno considerato di poter fare
salvataggi anche per db grandi?

inoltre perchè nel link indicato mette tra i settaggi di phpmyadmin anche Add Drop Table/View/Procedure/Function ?
serve e quando?

(per inserire una immagine es in questo post, come si fa? se clicco su Insert Image si apre il box con richiesta url e non si apre invece la cartella del mio pc da cui scaricare l'img)

Ci sarebbe una soluzione di semplicità estrema: Usare MySQL da riga di comando.
In questo modo tutti i problemi sopra descritti diventano inesistenti.

Va da se che Backup&Migrate è la migliore soluzione per fare i backup in automatico e... "senza pensieri".

Ma quando fate l'import di un Dump, facendo come segue direttamente da riga di comando, vi risolvete tutti i problemi.

mysql -u userdb -p nomedb < dump.sql

jscm wrote:
Ci sarebbe una soluzione di semplicità estrema: Usare MySQL da riga di comando.
In questo modo tutti i problemi sopra descritti diventano inesistenti.

Allora da linea di comando si può benissimo usare anche Drush (comando sql-query), con il vantaggio che non devi nemmeno digitare utente e password e ricordarti come si chiama il DB, dato che viene tutto recuperato automaticamente da settings.php.

Ciao Pescetti,

Volevo sapere da te un paio di cose:

1. Cosa ne pensi di MySQLDumper (immagino che non lo hai provato; ma sul sito ci sono tutte le features...)

2. Se il suo sistema di backup/restore in formato GZip si può ritenere SICURO/INTEGRO e abbatte il potenziale rischio di perdite di dati come hai fatto notare giustamente nei post che ho linkato al #1

Grazie

Ciao
kipper

pescetti wrote:
jscm wrote:
Ci sarebbe una soluzione di semplicità estrema: Usare MySQL da riga di comando.
In questo modo tutti i problemi sopra descritti diventano inesistenti.

Allora da linea di comando si può benissimo usare anche Drush (comando sql-query), con il vantaggio che non devi nemmeno digitare utente e password e ricordarti come si chiama il DB, dato che viene tutto recuperato automaticamente da settings.php.

E allora, visto che si può fare senza difficoltà, perchè non usarlo?
rapido, semplice, efficace e privo di tutti i problemi indicati in questa discussione... e tra l'altro evitate pure di installare moduli o applicazioni esterne.

...e allora facciamolo!

io sono abituato (nel mio piccolo...), a spiegare le cose che so a fronte di eventuali rchieste dei vai users sul forum in modo molto dettagliato senza dare per scontato i particolari perchè di scontato non c'è mai nulla (spendo il mio tempo prezioso ma lo faccio volentieri...) - le cose che potrebbero esserlo per un esperto in materia non lo sono per un user a digiuno...

secondo me, sarebbe una bella cosa se in questa discussione "qualcuno" buttasse giù un bel tutorial circa i passi da seguire per eseguire un backup/restore tramite linea di comando es:

1......
2......
3....
etc...

...sono sicuro che sarebbe utile a molti!

mysql -u userdb -p nomedb < dump.sql ...dove va inserita questa stringa? ...bisogna usare Putty? ...bisogna creare una "cartella" nella root per ospitare i backup? ...come si fa un restore?...etc etc etc...

Si dice che in giro è pieno di questi tutorial - buttiamone giù uno "ufficiale" su drupalitalia.org una volta per tutte!

Ciao
Kipper

windows > esegui cmd
incolla la riga
mysql
mysql -u userdb -p nomedb < dump.sql
----------
..adesso non posso vedere se funziona : sono su un server - virtuale e sto finendo di instal/aggiorn Ubuntu
-------------
cmd lo trovi in windows/system, lo invii al desktop cosi hai l'icona sempre pronta (senza fare Esegui)

Lavatrice ad ultrasuoni
Sito http://www.ultrasuoni.net > Client service and contacts: [email protected]

kipper wrote:
Cosa ne pensi di MySQLDumper (immagino che non lo hai provato; ma sul sito ci sono tutte le features...)

Mai provato. Ma anche PhpMyAdmin ha opzioni per ovviare al timeout (almeno in fase di restore, in fase di backup non ricordo), quindi da questo punto di vista forse non ci sono grosse novità a meno che il tuo hosting non ponga limiti stretti.

kipper wrote:
Se il suo sistema di backup/restore in formato GZip si può ritenere SICURO/INTEGRO e abbatte il potenziale rischio di perdite di dati come hai fatto notare giustamente nei post che ho linkato al #1

Sì, a patto che tu non dimentichi tabelle quando dai il comando di backup. Per sicurezza, gzip --test nomefile.gz può controllare se ci sono errori. Naturalmente non può controllare se hai dimenticato delle tabelle, ma basta che ti ricordi di fare il backup di tutte quelle significative (o, per fare prima, di proprio tutte le tabelle, anche di quelle inutili come la cache) e stai tranquillo.

kipper wrote:
sarebbe una bella cosa se in questa discussione "qualcuno" buttasse giù un bel tutorial circa i passi da seguire per eseguire un backup/restore tramite linea di comando es:
1......
2......
3....

Non serve un lungo tutorial, sono solo un paio di comandi. Prerequisiti: server basato su Linux, accesso shell (command-line, con SSH o Putty), Drush installato sul server. I comandi vengono eseguiti dalla directory che contiene index.php del sito su cui vogliamo lavorare.

Per preparare, la prima volta, uno spazio per il backup:
mkdir sites/all/database (cioè metteremo i dump in sites/all/database).

Per fare il backup:
drush sql-dump --ordered-dump --result-file=sites/all/database/dump.sql

Per ripristinare un dump:
drush sql-cli < sites/all/database/dump.sql

Poi puoi fare infinite variazioni sul tema (ad esempio invece di dump.sql usare un nome di file legato alla data e archiviarne vari, oppure gestire i file di backup tramite SVN), ma gli ingredienti di base sono quelli che ho elencato.

Ciao Pescetti...

Innanzitutto grazie per le info... però, tenendo conto che non ho mai operato via Shell, mi sfugge una cosa, abbi pazienza...

Io ho deciso di usare Putty (l'ho usato tempo fa per installare il modulo PEAR su DreamHost e mi sono trovato bene...).

Ancora meglio preferirei accedere tramite "command-line" (con SSH) ma sul mio pannello di controllo (DreamHost) non riesco a trovare l'opzione che fa apparire il terminale per l'inserimento delle righe di comando... sai per caso dov'è questa opzione? (...oppure, se qualcun'altro usa DH mi portrebbe dare questa info?)

Detto questo, la cosa che mi sfugge è:
Nelle 2 stringhe che hai postato (Backup/Restore), non vedo lo "spazio" user e passw del database MySQL (abbi ancora pazienza perchè mi sto muovendo su un terreno per me nuovo e voglio essere sicuro di tutto...); immagino che debbano essere inserite nello "step" precedente per accedere alla mia Root insomma, il primo step dovrebbe essere sempre quello di accedere alla root (Putty/o SSH > hostname > username > password...) per qualsiasi operazione, giusto?

Seguono 2 schermate del mio Pannello di Controllo - va bene così oppure vedi qualcosa che è meglio cambiare/settare per una migliore performance/sicurezza?

In definitiva, cambiando il nome del "file" alla fine della stringa es. dump.sql, dump_01.sql, dump_02.sql (accetta gli underscore?) etc etc... alla fine me li dovrei trovare tutti in "sites/all/database" ok? - e se devo per esempio richiamare il backup dump_02.sql faccio così:
drush sql-cli < sites/all/database/dump_02.sql

Grazie di nuovo Pescetti

A presto

Ciao
Kipper

Ciao Pescetti,

Ho installato Drush seguendo questo tutorial:
http://brenthardinge.net/blog/howto-install-drush-dreamhost

...nella root del mio spazio web (FTP) è stata creata la cartella "Drush" nel Server con al suo interno i vari files... quindi il modulo dovrebbe essere installato...

Ho effettuato l'accesso con Putty, inserito mkdir sites/all/database ma mi da un primo errore e sono bloccato! - segue la schermata:

Come mi devo muovere!?

Grazie

Ciao
Kipper

kipper wrote:
Io ho deciso di usare Putty ... Ancora meglio preferirei accedere tramite "command-line" (con SSH)

Accesso SSH o command-line o PUTTY sono la stessa cosa. In tutti e tre i casi ti trovi a poter digitare comandi nella medesima interfaccia, la shell bash che ti fornisce Dreamhost.

kipper wrote:
Nelle 2 stringhe che hai postato (Backup/Restore), non vedo lo "spazio" user e passw del database MySQL

Non servono, magia di Drush: vengono carpiti direttamente dal file settings.php.

kipper wrote:
Seguono 2 schermate del mio Pannello di Controllo - va bene così oppure vedi qualcosa che è meglio cambiare/settare per una migliore performance/sicurezza?

Sono normalissime impostazioni e vanno bene. Io do per scontato che l'utente con cui ti colleghi via shell (con Putty) sia lo stesso che è "proprietario" del sito nel pannello di controllo "Manage Domains" o qualcosa del genere.

kipper wrote:
In definitiva, cambiando il nome del "file" alla fine della stringa es. dump.sql, dump_01.sql, dump_02.sql (accetta gli underscore?) etc etc... alla fine me li dovrei trovare tutti in "sites/all/database" ok? - e se devo per esempio richiamare il backup dump_02.sql faccio così:
drush sql-cli < sites/all/database/dump_02.sql

Esattamente. Occhio quando ripristini perché chiaramente il database corrente viene sovrascritto.

kipper wrote:
mi da un primo errore e sono bloccato!

I comandi vanno tutti eseguiti, come dicevo, dalla directory (cartella) che contiene il file index.php del sito su cui vuoi operare. Questo dipende dalla struttura della directory, ma credo che Dreamhost di default ti metta i siti in cartelle che hanno il dominio come nome, insomma se il tuo sito è http://miosito.com o http://www.miosito.com lo troverai nella cartella miosito.com o www.miosito.com rispettivamente e potrai accedervi con cd miosito.com o cd www.miosito.com[/codefilter_code] (anche via FTP puoi vedere facilmente il nome della directory, poi basta entrarci con il comando "cd", niente di terribile).

Tutti e tre i comandi vanno poi eseguiti dall'interno di quella directory.

Ciao Pescetti... allora,
Sono riuscito a navigare nelle cartelle e a capire il funzionamento che in effetti è sostanzialmente semplice e, come hai detto tu, non c'è "niente di terribile" ma, quando lancio il comando drush sql-dump --ordered-dump --result-file=sites/all/database/dump.sql per fare il backup, escono 2 errori (e ti pareva che dovesse andare tutto liscio al primo colpo...) - Mi viene richiesto di installare Console_Table - L'ho scaricato, scompattato, ma non capisco cosa voglia dire spostare il file Table.php in includes/table.inc insomma, dentro la cartella drush c'è la cartella includes ma poi? ...ho provato a mettere Table.php (in drush/includes...) ma niente da fare...

Avrei bisogno ancora di un'ultima "spinta" per risolvere questo grattacapo e poi ho un dubbio:
Avrò installato correttamente Drush?
...mi domando questo perchè nel tutorial che ho seguito ho un dubbio sugli ultimi 2 step che, in realtà, li ho tralasciati completamente in quanto credo di aver capito che sono superflui per l'installazione di Drush, almeno credo...

Riporto le istruzioni del tutorial di installazione di Drush - Ovviamente sono già dentro la root usando Putty:

curl -O http://ftp.drupal.org/files/projects/drush-All-Versions-2.0.tar.gz
(The latest version at the time of writing.)
Now type:
tar -zxf drush-All-Versions-2.0.tar.gz
You should be left with a folder called drush that contains the drush library.
2.
Get Drush on the Commandline: Now you need to make drush available to you on the command line. Open the file called .bash_profile by typing
nano .bash_profile
and navigate to the bottom of the screen. Enter the following line:
alias drush='/usr/local/php5/bin/php /home/<dreamhost username>/drush/drush.php'
(Don't forget to replace <dreamhost username> with your Dreamhost username.) Now save the file with the keystroke CTRL + X
3.
Logout: Now type exit to logout. This will force the shell to re-read the .bash_profile file.
4.
Log Back In: Log back in and you should be ready to drush!

Il dubbio ce l'ho sugli ultimi 2 punti (3 - 4) - In definitiva dopo aver dato il comando da tastiera "CTRL + X" ho chiuso il terminale - "Logout" e "Log Back In " cosa sono? ho fatto bene ad uscire o andava fatto qualcosa anche con queste 2 info/comandi credo...?

Riassumo i comandi che ho eseguito per l'installazione:

curl -O http://ftp.drupal.org/files/projects/drush-All-Versions-2.0.tar.gz
tar
-zxf drush-All-Versions-2.0.tar.gz
nano .bash_profile
alias drush='/usr/local/php5/bin/php /home/mio_username/drush/drush.php'
CTRL + X (da tastiera...)

Segue la schermata degli errori segnalati con istruzioni per Console_Table:

Ciao
Kipper

...seguendo le istruzioni da terminale sinceramente non capisco il seguente punto:

...extract, and move the file Table.php to includes/table.inc.

Ma come faccio a mettere Table.php in includes/table.inc se table.inc è un file e non una cartella!!!

Come devo fare per installare questo Package?

Boh, speriamo in bene...

Ciao
Kipper

[Risolto]
Risolto installando l'ultima versione > drush-All-versions-3.0.tar.gz

Nessuna richiesta o errore legati a Console_Table - Backup/Restore perfettamente funzionanti!

Grazie di nuovo a tutti...

Ciao
Kipper

Infatti, basta usare Drush 3 (anche 3.3, anche HEAD che è la versione di sviluppo successiva).

Aggiungo qualche commento sul resto, anche se hai risolto. Giusto per spiegare perché si fa così.

L'alias che hai dovuto aggiungere è un problema specifico di Dreamhost che di default fornisce PHP 5 sul sito ma PHP 4 sulla command-line, come spiego meglio in http://drupal.org/node/581870#comment-2061424

Il logout e login è esattamente quello che hai fatto.

Lo scaricamento di Console_Table è un passo fondamentale di drush che viene fatto in automatico alla prima esecuzione del programma. Nel tuo caso per qualche ragione falliva con la 2.0, è un bug noto.

Grazie per le preziose info e conferme aggiuntive Pescetti...

...tuttavia (senza al momento aver verificato e approfondito la cosa...), mi si presenta un fantasma:

Avendo installato il modulo CiviCRM (che a differenza degli altri moduli standard di Drupal fa uso di un suo database "dedicato" e che ha pure un suo file civicrm.settings.php che va a crearsi automaticamente subito dopo l'installazione in sites/default/civicrm.settings.php e quindi dove c'è anche setting.php di Drupal...), mi domando a questo punto se e come sia possibile effettuare il Dump anche per il database del suddetto modulo e che, se non dovesse essere possibile, potrebbe ancora entrare in "gioco" alla grande MySQLDumper > http://www.mysqldumper.net - avendolo già testato (come detto al post #1), fa un lavoro egregio nel "rilevare/salvare/ripristinare" tutti i database presenti nella Root...

Tu che dici? ...c'è un comando da terminale per fare un Dump anche del database di CiviCRM? ...così in prima battuta la vedo dura, ma credo che la mia preoccupazione sia dovuta all'inesperienza in questo settore specifico... una soluzione ci dovrà pur essere!!!

Grazie veramente per la preziosa collaborazione...

Ciao
Kipper

kipper wrote:
c'è un comando da terminale per fare un Dump anche del database di CiviCRM?

Su CivicCRM purtroppo non ti posso aiutare. Comunque con mysqldump puoi fare il dump di qualsiasi database mysql. Quindi, se il tuo database aggiuntivo è su MySQL e si chiama civdb e ha come utente civuser e come password civpass e si trova sul server civserver, il comando

mysqldump -h civserver -u civuser -pcivpass civdb > sites/all/database/civ.sql

(dove devi sostituire i valori giusti per civserver, civuser, civpass e civdb; nota anche che NON c'è uno spazio dopo il "-p") ti fa un backup del database sul file civ.sql; puoi ovviamente cambiare il nome del file come già detto in precedenza.

Per l'eventuale ripristino (distruttivo!) usa il commento di jscm qui sopra: http://www.drupalitalia.org/node/11579#comment-39077

ok, grazie molte...
al momento non ho tempo con civicrm... appena ci metto mano farò sapere gli esiti...

Grazie

Ciao
Kipper

Aggiungo anche (tanto per fare il rompiscatole) che conviene mettere il sito off-line prima di fare i backup (sempre tramite drush) e rimetterlo on-line dopo aver completato il backup.

Con drush si possono esludere delle tabelle facilmente riducendo drasticamente il peso del DB (e quindi il tempo di backup e di ripristino) quali le varie cache*, accesslog (dipende dai casi), sessions (anche qui dipende dai casi).

MAI fare i backup del DB sullo stesso server, se qualcosa non funziona sicuro perderai anche i backup (http://it.wikipedia.org/wiki/Legge_di_Murphy), quindi creare uno script che dopo aver fatto il backup lo sposti da qualche altra parte (FTP, AWS S3, ...).

JM2C

Ciao
Marco
--
My blog
Working at @agavee

Ok Mavimo... e da che parte dovrei iniziare per fare questo script!?

Mi state facendo venire la psicosi dei Backups ma d'altronde sono tutte cose da considerare...

Grazie a tutti per le preziose info...

Ciao
Kipper

@pescetti
Scusa se rompo ancora...

Ho installato Drush per un altro sito (sempre su DH), stesso procedimento descritto sopra (CTRL + X e ho chiuso il terminale) con l'unica differenza che la volta precedente dopo CTRL + X, mi sembra (adesso non ricordo bene...) di aver dato "Yes" nella riga dove si è posizionato il cursore dopo aver dato il comando da tastiera CTRL + X, appunto...

Entro nell'account con Putty
cd miosito.com (entrato nella root del sito...)
mkdir sites/all/database (cartella creata correttamente...)
drush sql-dump --ordered-dump --result-file=sites/all/database/dump.sql - (qui sta l'errore: dopo aver dato invio per lanciare il backup, mi appare questo msg: -bash: drush: command not found)

Cosa può essere successo? eppure Drush sul server è caricato (sul server compare la stessa cartella come nell'installazione precedente... - i vari files .bash_profile, .bash_profile_save etc.. - sono stati creati...)

Boh... ero così contento del funzionamento della precedente installazione e adesso sono in "frustrazione"

Devo reinstallare drush? Come faccio a disinstallarlo per poi re-installarlo che magari ho combinato qualche casino negli step 4 e 5... boh... che strano...

Mi daresti gentilmente una mano?

Può creare problemi al funzionamento del sito questo Drush magari NON installato correttamente?

Grazie

Ciao
Kipper

Devi controllare due cose:

1. Che lo script drush è eseguibile
2. Che lo script drush è nel path dei commandi

Presumendo che hai messo drush in un indirizzo ~/drush:
chmod u+x ~/drush/drush
ln -s ~/drush/drush /usr/bin/drush

(Vedo in #18 avevi usato alias drush='/usr/local/php5/bin/php /home/mio_username/drush/drush.php')

Edit: Leggo adesso che sei sempre su DreamHost, allora va bene l'alias (per motivi dei diversi versioni di php). Controlla che la modifica al .bash_profile c'é:
cat .bash_profile

Più imparo, più dubito.

oooh! John!!!

qui la situazione server:

Quote:

John wrote:
1. Che lo script drush è eseguibile
2. Che lo script drush è nel path dei commandi

Non capisco bene: in che modo controllo se è eseguibile e che sia nel path dei comandi?

Grazie molte!

Ciao
Kipper

In realtà non serve se usi l'alias (perchè esegui direttamente il file drush.php). Comunque, fai
ls ~/drush/drush
Dovrebbe dire qualcosa tipo:
-rwxr-xr-x 1 john john 1947 2010-06-02 17:53 /home/john/drush/drush
Se non c'è la x, fai
chmod u+x ~/drush/drush

Il problema mi sa è che non vede l'alias... Prova con:
echo "$drush"
Se il risultato è vuoto, l'alias non c'è, quindi riprovi editare .bash_profile con nano (Ctrl + O per scrivere il file, Crtl + X per uscire)

Più imparo, più dubito.

ho provato echo "$drush" e il risultato è vuoto... mi chiede di inserire un altro comando...

E' la lettera O - da quando linux usa Ctrl + numero?
Controlla che hai salvato bene con cat, oppura scrivi semplicemente drush (visualizza l'aiuto)

Più imparo, più dubito.

non ci sto capendo più niente... ho scritto drush ma mi dice: command not found... comunque il problema sta sull'alias (credo...) - con echo "$drush" mi ha dato un risultato vuoto - come si fa a editare ".bash_profile con nano"?

Scusami kipper - dormivo, sarà l'età.... (ma questo thread sta diventando una lezione di linux)

Premesso i commandi dovrebberono funzionare secondo il tuo screenshoot degli indirizzi...
1. Modifici .bash_profile

cd ~/
nano .bash_profile

usare la frecche giù per arrivare in fondo al file, poi digiti:
alias drush='/usr/local/php5/bin/php /home/mio_username/drush/drush.php'

(naturalmente controlla il percorso per PHP, e modifica il percorso a drush.php)
poi ctrl + X, viene richiesta se vuoi salvare, Y per yes (se è in inlgese)

2. Controlla la modifica:

cat .bash_profile

Adesso l'alias dovrebbe essere sull'ultima riga

3. Resetta bash (necessario solo una tantum) - oppura logout (exit) e rientrare con PuTTY

source ~/.bash_profile

4. Prova il commando:
drush

Più imparo, più dubito.

Ciao John,

Quote:

John wrote:
Scusami kipper - dormivo, sarà l'età.... (ma questo thread sta diventando una lezione di linux)

Anch'io me ne sono andato a dormire perchè non ce la facevo proprio più - per noi non è mai l'età!

Quote:

(ma questo thread sta diventando una lezione di linux)

Pienamente d'accordo!

Adesso non posso testare il tuo Tutorial perchè stiamo facendo le valige, caricare l'auto e partire per Milano - domani o dopo ti faccio sapere gli esiti...

Grazie ancora John...

Ciao
Giuliano

Ciao John,

Vorrei disinstallare Drush per re-installarlo da capo perchè si e creata un pò di confusione sul server...

In un sito "test", sempre su DH (quello dove attualmente Drush funziona correttamente e i backups/restore sono ok...), si era creata un pò la stessa situazione e ho tolto Drush semplicemente selezionando e cancellando i files di "troppo" nel server (dopo un'errata installazione di Drush, appunto...) portando il server alla situazione di default (a livello di files...) come quando te lo fornisce DH "ex-novo" - dopo di che, ho re-installato Drush (vers. 3.0) e tutto funziona...

Seguono le schermate della situazione del sito di cui stiamo parlando (dove è in atto questo tutorial linux...), che poi sarebbe il sito dove non funziona Drush... scusa i giochi di parlole ma vado veramente di fretta; qui tra poco si parte e il PC (compreso il cavo LAN di 70 Metri... per tetti e canali vari...) sarà l'ultima cosa che smonterò:

Situazione di default/originale (prima del tentativo "fallito" di installare Drush):

"Casino" di files creati dopo le varie prove di questa notte:

Domanda:
Posso eliminare "brutalmente" i files di troppo in modo da far rimanere quelli originali (per ripetere l'installazione da zero) oppure c'è una procedura particolare da seguire per DISINSTALLARE Drush???

In ogni caso, come ho già detto, domani o dopo ti faccio sapere gli esiti del tuo tutorial... avrei una mezzora/ora adesso, ma non sono concentrato e preferisco operare quando sono OK...

Se nel frattempo mi confermi la procedura che ho descritto sopra per disinstallare Drush te ne sarei grato...

P.S. Quasi quasi metto anch'io il mio motto:
Più imparo, più mi stresso...

Grazie

ciao
Giuliano

Si puoi...

kipper wrote:

Domanda:
Posso eliminare "brutalmente" i files di troppo in modo da far rimanere quelli originali (per ripetere l'installazione da zero) oppure c'è una procedura particolare da seguire per DISINSTALLARE Drush???

Nessun procedura, cancelli pura. Basta ricordare di rimuovere (se l'avevi messo) l'alias in .bash_profile...

Più imparo, più dubito.

Si, mi sa che hai ragione John...

La prima schermata non è quella di default di DH (andavo di fretta...) - credo che .bash_profile e anche gli altri:

.alias
.bashrc
.cshrc

...si siano creati per qualche ragione: per esempio quando ho installato MySQLDumper > http://www.mysqldumper.net/ - poi l'ho tolto... (semplicemente eliminando la cartella in miosito.com/mysqldumper)

Se cancello tutti i files elencati sopra (quelli preceduti dal "punto") con il risultato finale che su Server rimangono solo le cartelle > "Maildir - miosito.com (ovviamente...) e logs" ci sono controindicazioni?

Quote:

John wrote:
Nessun procedura, cancelli pura. Basta ricordare di rimuovere (se l'avevi messo) l'alias in .bash_profile

...rimuovere l'alias in .bash_profile intendi dire di eliminare il file semplicemente cancellandolo come gli altri oppure c'è un'operazione da fare da "Terminale" (Putty)?

Ammetto che con i comandi Linux sono a "zero" però, devo dire che sono veramente potenti - facendo il Dump del database MySQL (sul sito dove "Drush" funziona...), ho notato una rapidità e semplicità DISARMANTI!

Ciao
Kipper

Ben tornato Kipper. Qui qualche idea per i tuoi 70m di cavo.

E sufficiente che cancelli i file /indirizzi per portare il file system nello stato di immagine #1 nel commento #36 sopra. Si può fare anche dal command line ma rm o rmdir sono un pò pericoloso. Farlo dal panello.

A questo punto l'unico file non ancora 'originale' potrebbe essere .bash_profile se (e solo se) l'avevi modificato con nano. Altrimenti sei apposto.

Aneddoto: uno chiede spazio disco sul proprio account, l'operatore di sistema bastardo dal inferno risponde: esegui rm -xxx /
(Se sostituisci -xxx con le opzioni giusti spazi via tutti i file su tuo account. Ma almeno hai più spazio disco no?)

Più imparo, più dubito.

Cia John,

Grazie per le info sul cavo da 70m ;-)

Tornando ai files:
Sinceramente (con le varie prove che ho fatto da terminale per "settare Drush"), a questo punto non so se ".bash_profile" l'ho editato oppure no :-(

In ogni caso, se cancello tutti i files (.bash_profile, etc etc) lasciando solo le 3 cartelle "Maildir - miosito.com (ovviamente...) e logs" (con il dubbio se ho editato o no ".bash_profile" corro dei rischi? ...posso cancellarlo in ogni caso?

...abbi pazienza ma, essendo a "zero" di comandi/editing Linux, faccio un pò fatica anche a capire i tuoi preziosi e semplici suggerimenti... devo essere sicuro di procedere con la re-installazione di Drush senza fallire una seconda volta!

Grazie - qui siamo ancora in fase di piombatura stanza... ma non credo...

Ciao
Giuliano

Non cancellare .bash_profile. Per controllare se ha messo qualcosa (ci sono due file save nel secondo immagine, quindi è possibile) usi cat .bash_profile, se c'è il tuo alias in fondo al file togli quella riga con nano

Più imparo, più dubito.

Ciao John,

Non ho ancora fatto nessuna prova a causa di impegni imprevisti vari e poco tempo - ti farò sapere prossimamente gli esiti...

Ciao
Giuliano

Ciao John,

Lasciando in sospeso momentaneamente l'argomento/tutorial Drush vorrei se possibile avere un tuo aiuto su un problema che mi sta facendo impazzire da alcuni giorni... Lavoro sui miei siti, ma ogni tanto torno all'attacco con MySQLDumper che personalmente lo ritengo ottimo, naturalmente per le mie esigenze... avendo database diversi di applicazioni diverse...

Venendo al sodo, dopo aver installato lo script MySQLDumper > http://www.mysqldumper.net/ (funziona tutto perfettamente...) ho problemi a creare la Protection Directory (naturalmente d'obbligo... altrimenti potrebbe accedere e operare chiunque a miosito.com/mysqldumper)

Questo script, quando vai a creare la Protection Directory, genera 2 files (.htaccess e .htpasswd) ma il problema è che dopo aver creato questa Protection Directory e vado a navigare nell'interfaccia (che prima dell'impostazione della Protection Directory funzionava alla perfezione...) mi da un bel "Page not Found"!!!

Ho scritto sul forum di mySQLDumper, mi ha risposto uno sviluppatore (credo...) e mi dice che il problema sta nel fatto che devo creare una directory protetta utilizzando il mio pannello di Controllo di Dreamhost... Ho fatto tutto quello che dovevo fare ma niente! ...provo, riprovo ma quando setto quella dannata Password Directory mi da sempre Page not Found - ho notato, che se tolgo dalla directory i files ".htaccess e .htpasswd" riappare perfettamente l'interfaccia ma mi dice sempre: Urgentissimo > Impostare una Protection Directory... e così in Loop, metti togli, come un "circolo vizioso"

Mi è venuta un'idea (non mi vergogno nel dire che ha dell'allucinante e sicuramente non da Drupalist anzi... ma però, dopo alcuni test funziona... così per fare una prova... per curiosità...)

1. Non imposto nessuna Protection Directory
2. Faccio i miei Backup/Restore
3. Dopo i backup/restore cambio i permessi della directory miosito.com/mysqldumper (mysqldumper) da 755 a 000 - ho provato, e quando sono 000 digitando miosito.com/mysqldumper mi da (giustamente...) Page not Found mentre, quando vado a settarli a 755, appare l'interfaccia e posso riprendere le operazioni e tutto funziona....

Ci sono potenziali controindicazione "switchare" da 755 a 000 ogni qualvolta mi serve usare lo script?

Ci tengo a precisare che non voglio perdere di vista il tutorial di Drush e il Dump, sicuramente i backup/restore da terminale sono più sicuri, ma al momento non ho tempo di mettermi alle prese con la risuluzione dei miei problemi di cui sopra e vedo in MySQLDumper una soluzione più veloce e sbrigativa... e anche di una certa qualità... sempre secondo me...

Di seguito la discussione con lo sviluppatore:
http://forum.mysqldumper.de/page-not-found-t5674.html

Grazie

Ciao
Kipper

Beh se tutto funziona senza il .htaccess, e non funziona più con - sarà un problema del contenuto del file .htaccess (mio caro Watson). Puoi postare il contenuto?

Più imparo, più dubito.

ok, allora... seguono i 2 step di creazione password + la terza schermata del "Page not Found" + i contenuti dei 2 files ".htaccess" generati nella root di MySQLDumper dopo aver creato/impostato la Protection Directory:

.htaccess:

AuthName "MySQLDumper"
AuthType Basic
AuthUserFile "/home/miosito/miosito.com/mysqldumper/.htpasswd"
require valid-user

.htpasswd:

pippo:$1$aouAYkD6$1GwqR6WnOdZQYrknF74FC1

P.S. Naturlamente ho provato ad inserire "RewriteEngine Off" nel.htaccess nella root di MySQLDumper ma niente da fare... sempre Page not Found...

Grazie

Ciao
Giuliano

[RISOLTO] Installare Drush su DreamHost (e non solo... credo...)

P.S. John, se hai una dritta per risolvere i problemi di MySQLDumper (.htaccess e .htpasswd) del post sopra, a me, in ogni caso interessa comunque... il discorso per me è sempre aperto...

Ritornando a Drush, siccome ero riuscito ad installarlo (come da post > Mer, 01/09/2010 - 11:05 di questa discussione... ), ma il problema mi si era ri-presentato in una "seconda installazione" in quanto non ricordavo cosa avevo fatto nell'ultimo (e credo...) importante "step", posto di seguito i passaggi effettuati per un'installazione adesso perfettamente funzionante ma, tuttavia, non sono ancora sicuro se ho fatto i passaggi giusti e chiedo una conferma agli esperti in modo da stare tranquillo con la certezza che Drush sia OK. Comunque i backup/restore funzionano perfettamente...

Installazione (sono già nel mio account con Putty pronto a ricevere "comandi"):

1. curl -O http://ftp.drupal.org/files/projects/drush-6.x-3.3.tar.gz
2. tar -zxf drush-6.x-3.3.tar.gz
3. nano .bash_profile
5. alias drush='/usr/local/php5/bin/php /home/dreamhostusername/drush/drush.php'
6. CTRL + X (da tastiera)

Dopo CTRL + X la schermata è questa:

7. digito y (Yes) e do Invio - anche in minuscolo va bene (y)? - e la schermata cambia così:

8. Senza digitare nulla do "Invio"
9. Digito "exit" per uscire

Nel server dove ho l'elenco dei siti si sono aggiunti 3 files e lo scenario è questo:
miosito1.com
miosito2.org
drush
.bash_history
.bash_profile
drush-6.x-3.3.tar.gz

P.S. Avevo anche 2 files che ho salvato su PC e poi cancellato dal server:
.bashrc
.cshrc

...forse dei residui di una precedente installazione del modulo PEAR? oppure residui dei diversi tentativi di installare Drush? ...li devo rimettere? ...servono a qualcosa? ...sono importanti? ...cosa sono?

Per backup/restore e la navigazione nelle cartelle valgono le preziose info dell'amico Pescetti descritte già in questa discussione...

Riporto gli ultimi 2 step (descritti nel tutorial che ho seguito...) sul quale avevo il dubbio, sinceramente non li ho capiti bene (se qualcuno me li saprebbe spiegare lo ringrazio...) ma, comunque, il tutto funziona:

3.
Logout: Now type exit to logout. This will force the shell to re-read the .bash_profile file.
4.
Log Back In: Log back in and you should be ready to drush!

Grazie per eventuali conferme e ulteriori suggerimenti sulle operazioni effettuate...

Ciao
Giuliano

...non dovrebbe essere creato anche .bash_logout e/o qualcos'altro? ...se i backup/restore funzionano sto tranquillo? mi illumini su questi files? ...sempre se non chiedo troppo?

Scusa ma non ho la certezza matematica che i backup/restore funzionano come dovrebbero senza questi files... gli ho aperti con Scite e ho visto che sostanzialmente sono file di testo con delle istruzioni... se non c'è .bash_logout fa niente o è una cosa importante?

Ciao
Kipper

Per il momento non ho una soluzione per MySQLDumper - perchè l'ho installato e da me funziona...

kipper wrote:

Installazione (sono già nel mio account con Putty pronto a ricevere "comandi"):

1. curl -O http://ftp.drupal.org/files/projects/drush-6.x-3.3.tar.gz
2. tar -zxf drush-6.x-3.3.tar.gz
3. nano .bash_profile
5. alias drush='/usr/local/php5/bin/php /home/dreamhostusername/drush/drush.php'
6. CTRL + X (da tastiera)
7. digito y (Yes) e do Invio - anche in minuscolo va bene (y)? - e la schermata cambia così:
8. Senza digitare nulla do "Invio"
9. Digito "exit" per uscire


Yup, sembra tutto corretto.

kipper wrote:
Nel server dove ho l'elenco dei siti si sono aggiunti 3 files e lo scenario è questo:
miosito1.com
miosito2.org
drush
.bash_history
.bash_profile
drush-6.x-3.3.tar.gz

P.S. Avevo anche 2 files che ho salvato su PC e poi cancellato dal server:
.bashrc
.cshrc

...forse dei residui di una precedente installazione del modulo PEAR? oppure residui dei diversi tentativi di installare Drush? ...li devo rimettere? ...servono a qualcosa? ...sono importanti? ...cosa sono?


Si sono importante. Vengono inseriti da Linux per 'avviare' bash stesso. Vedi http://www.faqs.org/docs/abs/HTML/files.html - stesso discorso per cshrc se mai dovresti usare quel shell.

kipper wrote:
Per backup/restore e la navigazione nelle cartelle valgono le preziose info dell'amico Pescetti descritte già in questa discussione...

Riporto gli ultimi 2 step (descritti nel tutorial che ho seguito...) sul quale avevo il dubbio, sinceramente non li ho capiti bene (se qualcuno me li saprebbe spiegare lo ringrazio...) ma, comunque, il tutto funziona:

3.
Logout: Now type exit to logout. This will force the shell to re-read the .bash_profile file.
4.
Log Back In: Log back in and you should be ready to drush!

Grazie per eventuali conferme e ulteriori suggerimenti sulle operazioni effettuate...

Si esatto. Bisogna fare il logout (che probabilmente terminerà il console PuTTY), poi rifare il login in modo che le modifiche in .bash_profile et al veranno eseguiti.

kipper wrote:
...non dovrebbe essere creato anche .bash_logout e/o qualcos'altro? ...se i backup/restore funzionano sto tranquillo? mi illumini su questi files? ...sempre se non chiedo troppo?

Scusa ma non ho la certezza matematica che i backup/restore funzionano come dovrebbero senza questi files... gli ho aperti con Scite e ho visto che sostanzialmente sono file di testo con delle istruzioni... se non c'è .bash_logout fa niente o è una cosa importante?


Il file .bash_logout serve per terminare processi indipendente, ecc. Non hai bisogno. http://rcsg-gsir.imsb-dsgi.nrc-cnrc.gc.ca/documents/advanced/node125.html

Più imparo, più dubito.

Ok, John... sei sempre preziosissimo...

Credo che MySQLDumper non abbia più senso dal momento che c'è Drush!

Un ultima cosa veloce...

Siccome non ho capito al 100% l'operazione di logout che ho fatto vorrei una conferma:
Dopo aver Digitato da tastiera CTRL + X, il Logout l'ho effettuato negli step 7 - 8 e 9 giusto? e cioè:

7. digito y (Yes) e do Invio - anche in minuscolo va bene (y)? - e la schermata cambia così:

8. Senza digitare nulla do "Invio"
9. Digito "exit" per uscire

E' questo il logout che ho fatto?

Poi, le modifiche in .bash_profile vengono eseguite/attivate/confermate una volta effettuato il Login (RI-ACCEDENDO ancora con Putty...) e Drush è operativo giusto?

Un ultima cosa e ho finito, abbi pazienza:
In un secondo server dove devo installare un altro Drush ho una serie di file .bash (residui di precedenti tentativi andati male...):

.alias
.bash_profile
.bash_profile.save
.bash_profile.save.1
.bash_profileexit
.bash_profileexitexit
.bash_profileexitexit.save
.bash_profileexitexit.save.1
.bash_profilegg
.bashrc
.cshrc

...li cancello tutti e lascio solo ".bashrc e .cshrc" e procedo con la nuova installazione giusto? ...li ho cancellati e ricreati una decina di volte su un server "test" finchè non ho capito la procedura (sono un pò duro eh...!) e, nonostante le cancellazioni brutali varie, dopo aver trovato la soluzione il tutto funziona senza problemi...

In definitiva, dopo l'installazione sul server devo avere:
drush
.bash_history
.bash_profile
.bashrc
.cshrc

Giusto?

Ultimissima:
Il dump parte in automatico/magicamente intercettando setting.php in "sites/default/" però in questa cartella c'è anche setting.civicrm.php ...darà qualche fastidio/interferenza/problema? ...ho provato a fare i backup/restore nel primo sito Drupal dove c'è anche CiviCRM ma credo vada tutto bene nel senso che non ho notato cose strane...

Ho finito...

Grazie come sempre John

Più imparo più mi stresso... ;-)

Ciao
Giuliano

Non hai idea di quanto sono utile le immagine nei tuoi post. La fatica viene premiato...

kipper wrote:
Credo che MySQLDumper non abbia più senso dal momento che c'è Drush!

Good. Non mi piaceva particolarmente il codice.

kipper wrote:
Un ultima cosa veloce...

Siccome non ho capito al 100% l'operazione di logout che ho fatto vorrei una conferma:
Dopo aver Digitato da tastiera CTRL + X, il Logout l'ho effettuato negli step 7 - 8 e 9 giusto? e cioè:

7. digito y (Yes) e do Invio - anche in minuscolo va bene (y)? - e la schermata cambia così:
8. Senza digitare nulla do "Invio"
9. Digito "exit" per uscire

E' questo il logout che ho fatto?


Non esattamente. Nella tua lista originale #46, hai eseguito nano - l'editor al punto 3. (Che fine aveva fatto il punto 4?) Qui al punto 6, 7 e 8 stai uscendo da nano. Quindi torni nello shell. Al punto 9 (e solo li) esci dal shell, - il classico logout.

kipper wrote:
Poi, le modifiche in .bash_profile vengono eseguite/attivate/confermate una volta effettuato il Login (RI-ACCEDENDO ancora con Putty...) e Drush è operativo giusto?

Yes. In questo modo saranno attivi ogni volta che fai il login.

kipper wrote:
Un ultima cosa e ho finito, abbi pazienza:
In un secondo server dove devo installare un altro Drush ho una serie di file .bash (residui di precedenti tentativi andati male...):

.alias
.bash_profile
.bash_profile.save
.bash_profile.save.1
.bash_profileexit
.bash_profileexitexit
.bash_profileexitexit.save
.bash_profileexitexit.save.1
.bash_profilegg
.bashrc
.cshrc

...li cancello tutti e lascio solo ".bashrc e .cshrc" e procedo con la nuova installazione giusto? ...li ho cancellati e ricreati una decina di volte su un server "test" finchè non ho capito la procedura (sono un pò duro eh...!) e, nonostante le cancellazioni brutali varie, dopo aver trovato la soluzione il tutto funziona senza problemi...

In definitiva, dopo l'installazione sul server devo avere:
drush
.bash_history
.bash_profile
.bashrc
.cshrc

Giusto?


Si. Lasci anche .alias - era li prima, ed è un file 'standard' di sistema.

kipper wrote:
Ultimissima:

Mah, ho i miei dubbi ;-)

kipper wrote:
Il dump parte in automatico/magicamente intercettando setting.php in "sites/default/" però in questa cartella c'è anche setting.civicrm.php ...darà qualche fastidio/interferenza/problema? ...ho provato a fare i backup/restore nel primo sito Drupal dove c'è anche CiviCRM ma credo vada tutto bene nel senso che non ho notato cose strane...

Non credo che da fastidio, ma non farà il backup delle tabelle di CiviCRM. Drush fa girare Drupal come se forse un applicativo di linea di comando, invece di web. Quindi può leggere tutto l'informazione che 'vede' Drupal, ma senza problemi di tempi di esecuzione.

Più imparo, più dubito.

Pagine