Un server FTP

Accedere ai file sul nostro server da remoto è più semplice se su di esso installiamo un servizio FTP. Questo protocollo è nato appositamente per lo scambio dei file da remoto e, sebbene esponga la nostra linux-box a qualche rischio di sicurezza in più, rende il suo utilizzo da remoto ancora più flessibile.
Un’installazione standard (ovvero senza particolari configurazioni) richiede pochissimo tempo. Innanzitutto installiamo il servizio vsftpd:

$ sudo apt-get install vsftpd

Quindi editiamo il file di configurazione /etc/vsftpd.conf e impostiamo i parametri che seguono:

#Disabilita il login anonimo
anonymous_enable=NO
#Abilita l'autenticazione basandosi sugli utenti locali
local_enable=YES
#Abilita la scrittura dei file per gli utenti accreditati
write_enable=YES

Per rendere effettive le modifiche non resta che riavviare il servizio e poi siamo subito pronti per accedere al nostro server via FTP!

Soluzioni a linea di comando per il backup in Mac OS X

Fare il backup del proprio hard drive è un po’ come andare dal dentista: importante ma sgradevole, tanto da rimandarlo o dimenticarsene. Proprio per questo, il miglior modo per tenere al sicuro i propri dati è di programmare dei backup in modo regolare. Esistono in commercio diverse soluzioni, tra cui il software Apple .mac Backup, che però necessita la sottoscrizione del relativo servizio a pagamento e che l’utente si sia autenticato.
La tradizionale alternativa UNIX consiste nell’eseguire programmi di backup a linea di comand in uno script di cron, ma molti amministratori ignorano la varietà di opzioni disponibili per backup non controllati sotto Mac OS X.
Questo articolo tratta di alcuni aspetti inerenti la gestione dei backup e delle particolari considerazioni per i sistemi Mac OS X, la varietà delle opzioni che permettono la creazione delle copie e i trabocchetti nei quali si può cadere quando si sviluppa un sistema di backup. L’articolo non copre i flags BSD e i sistemi precedenti a Mac OS v10.4 (Tiger). Inoltre, per semplicità, si presumerà che nei filesystem per i quali si intende effettuare le copie, non siano attivi gli ACL (se si usa Mac OS X Server o fsaclctl). Ci sono alcune questioni su come questi programmi di backup interagiscono con gli ACL che esulano l’obiettivo di questo articolo e pertanto non verranno trattate. E’ possibile comunque consultare la documentazione di ogni programma in maniera più approfondita.

Un po’ di storia, dump e tar

Lo scopo principale di un backup è quello di riprodurre, nella maniera più accurata possibile, lo stato di un filesystem. Nella maggior parte dei casi la duplicazione del contenuto di un file non è sufficiente; la gerarchia del filesystem, i permessi, le date e le altre informazioni devono anch’esse essere preservate. I due principali programmi di backup UNIX, dump e tar, hanno approcci differenti sotto questo aspetto.Il programma dump legge la struttura sottostante il filesystem e ne produce una copia esatta. Fin dagli inizi di UNIX, dump esegue una scansione della tabella degli inode, crea una lista completa di tutti i file del disco e della struttura dei filesystem, analizza le directory e quindi il contenuto dei file. Questo approccio è dovuto alla particolare struttura di un filesystem UNIX, che è differente da un filesystem HFS+. Al contrario, tar usa le API del filesystem per creare l’immagine di una directory e dei file in esso contenuti. Questo approccio risulta più semplice e più portabile ma il formato del file tar non gestisce direttamente le peculiarità di Mac OS X come ad esempio le resource forks e i metadati del filesystem.
In tutti i casi, backup affidabili generalmente richiedono un filesystem inerte, ovvero un filesystem che non venga modificato durante il processo di copia. Per esempio, un file che viene spostato da una directory ad un’altra durante la creazione del backup, potrebbe risultare in entrambe all’interno del backup, o (peggio) in nessuna. Potrebbero verificarsi anche altri tipi errori, alcuni meno evidenti. Un file molto grande che viene riscritto durante il processo di copia, potrebbe venire troncato prima della fine o contenere dati non coerenti dove alcune parti provengono dalla versione originale e altre dalla versione modificata del file, con conseguente perdita di dati.
Sfortunatamente, i moderni sistemi sono spesso attivi 24 ore su 24, 7 giorni su 7, rendendo così impossibile la programmazione dei backup. Tuttavia, in una situazione del genere, una precisa strategia di backup diventa particolarmente importante, vista la più alta probabilità che un data copia di backup si corrompa in qualche modo. Inoltre potrebbe essere utile se si considerano strategie di backup che non operino a livello di filesystem; ad esempio, l’esportazione delle tabelle da un database è un operazione assicurata che produce un’immagine valida di quel databas, che può essere così tranquillamente copiato.

Considerazioni in merito a HFS/HFS+

Il filesystem HFS+ usato in Mac OS X ha una serie di funzionalità e caratteristiche molto diverse da quelle di un tradizionale filesystem UNIX. Più semplicemente, un programma di backup che si basa sulle API del filesystem, per questioni di portabilità, non è in grado di creare copie valide di un filesystem HFS+.
Innanzitutto ogni cosa ha una sua resource fork. Le resource fork vengono ignorate dalle API UNIX tradizionali, in quanto gestiscono solo la data fork di un file. Ci sono poi altre questioni che possono mettere in dubbio una strategia di backup. Gli attributi di un file (i flags del Finder, le date, il tipo di file e i riferimenti a chi lo ha creato) sono informazioni addizionali che un sistema di backup standard per UNIX non solo non ha modo di leggere, ma anche di registrare. Congiuntamente, questi dati sono riferiti da ora in poi come “attributi estesi”.
Il filesystem HFS+ non usa gli inode allo stesso modo dei filesystem UNIX (infatti gli hard link vengono emulati grazie ad un elaborato sistema che riproduce gli stessi effetti di un tradizionale hard link UNIX). Di conseguenza uan strategia di backup basata sulla scansione degli inode è praticamente impossibile.
Gli alberi binari del filesystem da sole potrebbero offrire una soluzione ma in pratica è meglio ignorare questa implementazione e concentrarsi sulle API; questo approccio offre risultati più consistenti ed è portabile.
A causa delle differenze tra i filesystem HFS + e gli UNIX tradizionali (come ad esempio UFS, il filesystem di Berkeley disponibile in Mac OS X) è necessario l’utilizzo di soluzioni particolari per la creazione e il ripristino delle copie di backup nei sistemi Mac OS X.
Inoltre i sistemi non-Mac non possono essere usati per la copia di file provenienti da un sistema Mac. Se si scompattano i file di un archivio su un’altra macchina e poi li si ricompatta, i datiche non possono essere rappresentati su quella macchina verrebbero irrimediabilmente persi.

Cosa funziona in Mac OS X v10.4 Tiger

Esistono alcune soluzioni commerciali per Mac OS X. Dettagli in merito allo loro compatibilità e funzionalità esulano da questo articolo, ma i relativi rivenditori saranno quasi con ogni probabilità felici di rispondere a tali domande. Assicuratevi di chiedere tutte le informazioni che vi servono secondo le vostre specifiche esisgenze. Non tutti i programmi compatibili con Mac OS X supportano pienamente tutte le sue funzionalità.
Ci sono alcune utilità già incluse in Mac OS X che possono essere utili allo scopo almeno in parte. Il più conosciuto è senz’altro ditto, un’utility specifica per Mac OS X che sin dalla nascita è stata in grado di gestire le resource fork dei file (nelle versioni precedenti la 1.4, il flag -rsrc deve essere passato per permettere a ditto di copiare le resource fork). Ditto può essere usato quasi in ogni tipo di situazione dal momento che può copiare interi file, archiviarli e ripristinarli. L’archivio crreato da ditto può essere sia nel formato PkZip che cpio. Siccome ditto può essere eseguito dalla linea di comando, è molto semplice programmare i backup e gestire eventuali problemi senza la necessità di una supervisione costante.
Un’altra opzione è tar che, a partire da Mac OS X 10.4, riconoscee gestisce le resource fork e gli attributi. Per contro non è in grado di gestire path molto lunghi e potrebbe non salvare i nomi dei file in maniera corretta (tale anomalia viene seganalata con un messaggio di errore). Tar può comunque archiviare e ripristinare le resource fork e gli attributi dei file. Nelle versioni più obsolete di Mac OS X tar non gestiva niente che non fosse solo il data fork e i permessi del file.
L’utilità pax è un’alternativa più flessibile rispetto a tar supportando le intestazioni di formati multipli. Preserva inoltre gli attributi estesi. Grazie a queste funzionalità pax è in grado di gestire path più lunghe.
L’utilità rsync offre performance migliori quando si eseguono copie di file particolarmente grossi. Per copiare gli attributi estesi occorre specificare il flag -E. rsync può essere usato in rete per centralizzare i backup.
In termini di affidabilità e velocità l’Apple Software Restore (ASR) è difficile da battere. Questo programma viene usato per la creazione di CD di ripristino in volumi HFS+. Per usare ASR, occorre creare un’immagine del disco  usando Disk Utility (usare il comando Crea immagine da directory, no Crea immagine da dispositivo). Un backup creato in questo modo può essere ripristinato in altri dischi come nello stesso. ASR può ripristinare i dati sostiuendoli oppure ridormattando il disco e poi copiarli in esso. In ogni caso, il largo impiego è dovuto essenzialmente per la velocità but of course it does remove any existing files.
Le immagini disco usate da ASR sono immagini disco standard Mac e possono essere montate nel desktop per copiare file specifici.
Vi è anche un’utlità a riga di comando denominata asr che può essere usata allo stesso modo. Inoltre è possibile specificare un volume esistente come sorgente piuttosto che un un’immagine compressa. Se asr viene richiamato senza il flag -erase, il programma semplicemente estrae i dati nella posizione corrente. Da tenere presente che asr non è in grado di operare in sorgenti o destinazioni che non siano volumi, ovvero non è possibile copiare i file in una subdirectory.
Per effettuare il restore di macchine di cui si conosce perfettamente la configurazione. è possibile usare asr in modelità serve, in cui fornirà una stream da una immagine sorgente. I sistemi client non possono usare questo sistema per un ripristino in locale  senza prima aver riformattato il volume di destinazione.Questo è un ottimo modo per effettuare il backup della configurazione del sistema, ma sarà necessario usare qualcos’altro per i file personali.

Avvertimenti

Ci sono alcune cose da tenere bene a mente quando si sviluppa una strategia di backup. Una delle cose più importanti è quella di testare il proprio sistema di backup in più circostanze differenti. Una delle cose più ovvie da testare è se è effettivamente possibile ripristinare i file. Un programmatore che ha sviluppato un’utilità per l’archiviazione a scopo ricreativo ha osservato che la gente rimane si è sempre impressionata per la qualità dei suoi backup senza chiedersi mai se era possibile effettuarne poi il ripristino. Prima di iniziare a fidarsi del proprio ssitema, è necessario effettuare il ripristino dei dati per testarlo! Ripristinare una gran varietà di file per testare tutte le possibilità: file con resource fork, file con l’ACL (se lo si utilizza), ecc.
I backup su sistemi attivi possono perdere dati significativi. Qualunque strategiadi backup che si adotta per questo tipo di sistemi devono tenere presente questo; se non si prevede questo rischio.

Localizzazione delle cartelle

Uno dei punti di forza di Mac OS X, dal punto di vista di un programmatore, è senza dubbio il sistema di localizzazione integrato in esso. Il Sistema Operativo offre allo sviluppatore una serie di strumenti che facilitano l’integrazione delle proprie applicazioni nella lingua usata dall’utente. Questi strumenti possono essere estesi non solo alle applicazioni, ma anche alle cartelle del filesystem. Se con il Finder apriamo la nostra Home, troviamo al suo interno le cartelle Documenti, Filmati e Musica. Ma se andiamo ad esplorarla attraverso il Terminale, ci accorgeremo che tali cartelle corrispondono alle directory Documents, Movies e Music.
Attraverso questo sistema, è possibile semplificare le operazioni sulle cartelle rendendole più user-friendly all’utente, senza complicare troppo la vita al programmatore, dal momento che egli, potrà sempre e comunque, fare riferimento alle path di queste cartelle attraverso il nome reale, senza preoccuparsi di come queste vengono chiamate dall’utente nella sua lingua.
Vediamo come possiamo personalizzare i nomi di queste cartelle, o meglio ancora, aggiungerne di altre.

Metodo 1

Questo metodo prevede la modifica della configurazione del Finder e, affichè la nostra cartella venga localizzata, occorre ripetere l’operazione sotto descritta in ogni singola installazione di Mac OS X. Questo approccio viene usato per le cartelle di sistema predefinite.
Andiamo nella nostra Home e creiamo la cartella Projects.
Quindi da terminale, attraverso il nostro editor di testo preferito (io uso vi) editiamo il file contenente le stringhe di localizzazione per l’italiano (ovviamente la regola vale per qualunque lingua, basta modificare il file corretto!):

$ sudo vi /System/Library/CoreServices/SystemFolderLocalizations/it.lproj/SystemFolderLocalizations.strings

e andiamo ad aggiungere la seguente riga:

"Projects" = "Progetti";

Salviamo il file e poi digitiamo il seguente comando:

$ touch Projects/.localized

Quest’ultimo crea un file all’interno della nostra cartella che indica al Finder di localizzarla usando la stringa che abbiamo impostato.
Per rendere effettive le modifiche dobbiamo disconnetterci e effettuare di nuovo il login, oppure riavviare il sistema.

Metodo 2

Questo metodo segue invece un approccio leggermente diverso in quanto le stringhe di localizzazione risiedono all’interno della cartella stessa. Per fare ciò dobbiamo innanzitutto aggiungere l’estensione .localized al nome della cartella. Questa volta creeremo la relativa directory direttamente da Terminale:

$ mkdir Projects.localized

Noterete fin da subito che il Finder mostrerà solo la prima parte del nome, nascondendone l’estensione.
Adesso creiamo la subdirectory .localized:

$ mkdir Projects.localized/.localized

Quindi creiamo al suo interno il file per la localizzazione in italiano:

$ vi Projects.localized/.localized/it.strings

e inseriamo la traduzione:

"Projects" = "Progetti";

Salvate le modifiche; dopodiché rifate il login oppure riavviate il sistema, al termine del quale troverete il nome della vostra cartella localizzata.

I metodi descritti in questo articolo sono validi purché nelle preferenze del Finder non sia stata spuntata l’opzione Mostra tutte le estensioni dei documenti (Menù Finder > Preferenze > Avanzate).
La localizzazione delle applicazioni invece, benché si basi sullo stesso principio, merita senza dubbio un articolo a parte, vista la maggior complessità.

Come prevenire la creazione dei file .DS_Store sui dischi di rete

Mac OS X, quando monta un volume crea nel suo filesystem un file nascosto denominato .DS_Store dove memorizza alcune informazioni usate poi dal Finder. Questo sistema risulta a volte antipatico se un utente si connette ad una condivisione SMB all’interno di una rete ibrida. In questi casi infatti il file risulta visibile agli altri utenti Window e Linux.
Questo meccanismo può essere disattivato per le sole connessioni SMB/CIFS, AFP, NFS e WebDAV.
Aprite il terminale e digitate il seguente comando, seguito da Invio:

$ defaults write com.apple.desktopservices DSDontWriteNetworkStores true

Questo comando modifica le impostazioni dell’utente che si è loggato. Pertanto, in caso di più utenti registrati sul Mac, accedete e per ognuno di essi ripetete la procedura sopra descritta.
La disattivazione della creazione dei file .DS_Store sui dischi di rete non permetterà la gestione dei commenti del Finder su di essi.
Per ulteriori informazioni potete consultare il sito di supporto Apple, in particolare l’articolo HT1629 e 107822.

Stampare con CUPS da Windows

Ho una stampante installata e funzionante sul mio server linux attraverso il sistema di stampa CUPS. Come faccio a stamparci da un client Windows senza passare da una condivisione Samba?

E’ più semplice di quel che sembra. Basta creare una nuova stampante di rete attraverso l’apposito wizard Installazione guidata stampante e selezionare l’opzione Connetti a una stampante in internet o della rete domestica o aziendale, quindi inserite , nell’apposito box, l’url della nostra stampante, che sarà
http://nomeoipdelmioserver:631/printers/nomedellacodaostampantecups

A questo punto proseguite selezionando il driver di stampa adatto alla vostra stampante e terminate la procedura di installazione. Fatto, adesso sarete in grado di stampare su CUPS!

Nel mio caso, l’url che ho inserito era http://mrserver:631/printers/ML-1710. Ovviamente ho configurato il firewall del mio server affinché accettasse le connessioni esterne sulla porta 631 che, per chi non lo sapesse, è la predefinita sulla quale il demone di CUPS resta in ascolto. Volete fare una prova?! Sul vostro server aprite un browser (ad esempio Firefox) e andate all’url http://localhost:631, e divertitevi! Sempre per i più curiosi, CUPS utilizza un protocollo di rete standard chiamato ipp (Internet Protocol Printing) che permette la stampa attraverso una rete locale LAN o WAN.