Archivi tag: scp

scp ed i symlinks

Avere a che fare con delle share NFS è un po’ frustrante. Migrare tali share su un altro server lo è ancora di più, soprattutto se si utilizza scp per spostare le directory da condividere sul nuovo server NFS.

Infatti, subito dopo aver completato la copia, mi hanno fatto notare che i symlinks non funzionavano.

 

scp,symlinks,link simbolici,rsync,find

Inizialmente credevo fosse problema di cp, in quanto il trasferimento delle directory via scp non puntava direttamente alla dir target NFS ma ad una di appoggio (per via delle credenziali utilizzate da scp e dei permessi associati all’utente).

In soldoni, ho dapprima spostato le suddette dir sulla mia home e da lì ho lanciato un cp -d (per includere nella copia i link simbolici) verso il target della share. In seguito, mi sono posizionato sulla dir target ed ho lanciato il comando:

[root@nfs2 ~]# find . -type l -exec ls -ld {} +

per cercare eventuali simlynks, ma, come potete immaginare, la ricerca non ha fornito alcun risultato.

Dunque, non essendo problema di cp, l’unico comando responsabile della mancata copia dei link simbolici non poteva che essere scp.

Ed infatti, guardate qui:

http://superuser.com/questions/233036/scp-copy-the-same-links

La soluzione che ho adottato, senza dovermi necessariamente impelagare con rsync, consiste nel creare una tarball contenente le dir da migrare, copiarla via scp ed infine scompattarla sul nuovo server:

[root@nfs1 ~]# tar -cvf dirtomigrate.tar.gz /var/www/html/siti

[root@nfs2 ~]# tar -xvf dirtomigrate.tar.gz /var/www/html/siti

(da lanciare sul nuovo server NFS).

E’ tutto.

A presto.

File Transfer Protocol in tutte le salse

Chiunque abbia un background sistemistico avrà sentito parlare del File Transfer Protocol (FTP). Esso si basa sul protocollo TCP (lato trasporto) e dunque implica dei collegamenti di tipo affidabile. Inoltre, sfrutta le porte 20 e 21 (dette rispettivamente Data e Command), la prima per il trasferimento dei dati e la seconda per l’invio dei comandi.

Ma andiamo con ordine. Il suddetto protocollo può funzionare in 2 modalità:

1) attiva;

2) passiva.

Nel primo caso il client contatta il server sulla porta 21, inviandogli il comando PORT, in cui specifica appunto la porta ( >1023) su cui il server potrà provare a connettersi. A questo punto, dato che il server conosce la suddetta porta, lancerà un tentativo di connessione proveniente dalla porta 20 e diretta a quella precedentemente specificata dal client.

activeftp.gif

Nel secondo caso, invece, il client invia al server (sempre mediante la porta 21), il comando PASV (tentativo di connessione in modalità passiva) a cui il server risponde con il comando PORT (specificando una porta >1023). A questo punto sarà il client a tentare di instaurare la connessione dati verso la porta specificata dal server (a differenza di quanto avveniva nella modalità attiva).

passiveftp.gif

Ma quando utilizzare una o l’altra modalità? Semplice. Potrebbe accadere che il client si trovi dietro un firewall e che quindi i tentativi di connessione provenienti dal server vengano droppati. In questo caso è necessario utilizzare la modalità passiva, poichè in questo modo sarà sempre il client ad effettuare i tentativi di connessione, aggirando le restrizioni imposte dal suddetto firewall (essi, salvo eccezioni, solitamente non filtrano i tentativi di connessione in uscita da porte “alte”).

Avrete notato che la denominazione delle modalità avviene prendendo come punto di riferimento il server: se il traffico dati avviene mediante connessione instaurata dal server verso il client parliamo di modalità attiva; viceversa, se è il client ad effettuare la connessione dati verso il server parliamo di modalità passiva.

Ora, poichè il protocollo FTP è piuttosto datato, esso risulta abbastanza vulnerabile, soprattutto nei confronti operazioni di sniffing del traffico (poichè il trasferimento dati e l’invio di comandi viaggiano in chiaro).

Poprio per questo motivo negli anni si è cercato di correre ai ripari, creando dei meccanismi di cifratura che potessero garantire:

1) autenticazione della fonte;

2) confidenzialità.

Il primo tentativo di questo tipo prese il nome di SFTP (che sta per SSH File Transfer Protocol), ovvero un protocollo basato su SSH versione 2 (anche se esistono delle varianti basate su SSHv1, ma non tutti i client sono compatibili). Esso, più che un protocollo di trasferimento file, rappresenta una sorta di “file system remoto”, consentendo dunque di effettuare operazioni quali la creazione di nuove directory, la cancellazione dei file, ecc. Una restrizione del suddetto protocollo è rappresentata da SCP (Secure Copy), che consente solo il trasferimento dei file.

Entrambi i protocolli menzionati in precedenza, però, presentano una limitazione: necessitano di shell account per funzionare.

Proprio per evitare ciò è stato creato FTPS (FTP over SSL), che sfrutta i meccanismi di cifratura messi a disposizione dai protocolli SSL/TLS.

Esso può essere di due tipologie:

1) implicito;

2) esplicito.

Nel primo caso il server è in ascolto su una porta diversa dalla 21 (solitamente la 990) e tale tipologia è stata creata soprattutto per questioni di retrocompatibilità.

Nel secondo caso, invece, il server è in ascolto sulla classica porta 21 (FTP Command), ed accetta il comando esplicito AUTH <meccanismo di cifratura>, ad esempio AUTH TLS.

Dopo questa piccola premessa, prossimamente vedremo come abilitare FTPS su vsftpd.

A presto.

Script per il backup giornaliero di un database remoto

Visto che la ridondanza non è mai troppa (Murphy vi dice qualcosa?), ho pensato di realizzare uno scrip per effettuare il backup di un database hostato su un server remoto.

shell

Ecco lo scrip (basato su expect):

#!/usr/bin/expect -f
set date [exec date +%d_%m_%y]
set password1 "<pass1>"
set password2 "<pass2>"
set database "<nomedb>"
spawn ssh user@hostname
expect "*?assword:*"
send "$passwordr"
send "r"
expect ":~$"
send "mysqldump $database -u root -ppassvostrodb > $database_$date.plr"
send "$database_$date.pl user@hostname:/home/userr"
expect "*?assword:*"
send "$password2r"
send "r"
expect ":~$"
send "rm database_*r"
expect eof

Lo scrip in questione si collega via SSH al server remoto, esegue un dump del database per poi copiarlo tramite SCP sul mio server.

Affinchè tale scrip venga eseguito giornalmente (per la precisione ogni sera alle 22) è necessario editare il file /etc/crontab aggiungendo la seguente direttiva:

00 22   * * * user  cd /home/user/ && ./backupremotedb > /dev/null 2>&1

Per ulteriori info contattatemi.

A presto.