Quest’applicazione automatizza e rende perfino simpatico il backup del mac garantendo un meccanismo di salvataggio differenzia facilmente utilizzabile.

Di base questo sistema puo’ essere utilizzazione se si dispone di un disco esterno formattato per mac o di un Airport a cui e’ collegato l’ennesimo disco.

Inoltre, sullo stesso disco e’ possibile inserire i backup di piu’ macchine, crearsi aree personali e via disquisendo.

Freebsd, un po’ di pazienza e il divertimento che puo’ dare il compilatore, consentono di ottenere gli stessi risultati con costi decisamente piu’ bassi.

sul mac ci servono due cose compilate dai ports.

netatalk: protocollo di rete mac (in fase di compilazione va’ disattivata l’opzione “zeroconf” e ovviamente tenuta abilita l’opzione “AppleTalk”).

mdnsresponder: un demone che si occupa di gestire il dns via Multicast, ovvero consente a una macchina di annunciare in rete le proprie funzionalita’.

compilato il tutto, passiamo alle configurazioni in /etc/rc.conf:

netatalk_enable="YES"
cnid_metad_enable="YES"
afpd_enable="YES"
mdnsadv_enable="YES"

le prime tre righe riguardano netatalk, mentre l’ultima riguarda mdns.

passiamo poi alle configurazioni di rito in /usr/local/etc

AppleVolume.default: contiene le aree condivise in rete: nel mio caso ho condiviso solo due spazi: quello personale e l’area destinata a TimeMachine:

~

/home/TM TimeMachine allow:mauro options:usedots,tm

la prima voce, la tilde, indica che deve essere condivisa l’home dell’utente che si collega. Io ho creato due utenti, dotati di password, pertando le due directory saranno visibili quando si collega l’utente selezionato.

L’altra voce (/home/TM…) mette a disposizione dell’utente mauro (solo mauro) l’area destinata ai backup (vedi options: usedots,tm – in particolare ‘tm’ che indica che l’area serve a timemachine).

anziche’ usare avahi, (che dopo un po’ di esperimenti mi ha fatto girare largamente le balls), ho installato l’mdns di cui sopra con il seguente file di configurazione:

baratro# cat mdnsadv.conf
 Scaficchio AFP Server
 _afpovertcp._tcp
 548
 title="Scaficchio File Server"
 _adisk._tcp
 9
 sys=waMA=00:22:4d:7a:f7:9f,adVF=0x100
 dk2=adVF=0x83,adVN=Backup

la prima riga indica il nome del mio server, il quale annuncia (da riga 2 a riga 6) il protocollo AFP sulla porta 548, e il protocollo _adisk sulla porta 9

le ultime due righe indicano il macaddress della macchina che esporta questi servizi (sys=waMA=00:22:4d….) e altri parametri che devo ancora capire (ho cercato qualche riferimento e ho trovato questo:

http://www.dreness.com/blog/?p=48

ma in realta’ si trova diversa roba che andro a vedere dopo la pennica pomeridiana.

.

infine, creo uno script adeguato:

#!/bin/sh

# PROVIDE: mdnsadv
 # REQUIRE: LOGIN mdnsd
 #
 # Add the following lines to /etc/rc.conf to enable the mDNSResponder service advertising:
 #
 # mdnsadv_enable="YES"

. /etc/rc.subr

name="mdnsadv"
 rcvar=${name}_enable

command="/usr/local/bin/mDNSResponderPosix"

load_rc_config $name

: ${mdnsadv_enable="NO"}

command_args="-f /usr/local/etc/mdnsadv.conf > /dev/null 2>&1 &"

in rc.d dandogli poi gli attributi di esecuzione.

Avviati tutti i servizi, ultima cosa da fare e’ aprire una console su mac e dando un bel sudo, digitare il seguente comando:

"defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1″

Possiamo a questo punto definire nel mac, l’unita’ dove fare i backup e dove mettere e/o condividere i propri dati.

Per ottenere questo risultato, ho usato e sommato due siti diversi che usavano due approcci lievemente differenti:

http://www.aisecure.net/2011/08/02/freebsd-and-os-x-lion-time-machine/

e

http://blogs.freebsdish.org/rpaulo/2008/10/04/apple-time-machine-freebsd-in-14-steps/

per logica cerco di suddividere il lavoro sui diversi fronti che le macchine si trovano a gestire.

Disco:

Secondo quanto ho trovato in giro, e’ importante aumentare il numero di file che il sistema puo’ aprire (in /proc/sys/fs/file-max ho un’impostazione pare a 100000 (http://www.netadmintools.com/part295.html). Questo valore puo’ benissimo essere inserito in sysctl sotto la voce: fs.file-max = 100000

sulla documentazione di gluster viene riportata una modifica al readahead sui dischi. Di default le macchine riportano il valore di 256. Per gluster consigliano 16384.

net134 (134):/etc/apache2# blockdev –getra /dev/sda
256
net134 (134):/etc/apache2# blockdev –setra 16384 /dev/sda

gestione della memoria dirty:

net134 (134):/etc/apache2# grep -A 1 dirty /proc/vmstat
 nr_dirty 2062
 nr_writeback 0

vm.dirty_background_ratio = 3
vm.dirty_ratio = 40

Apache2:
da tutte le parti si consiglia di attivare i meccanismi di cache di apache2. Era quello che avevo fatto (sia mem-disk che mem-cache cercando di capire chi era meglio. Tanto per la cronaca ero arrivato a far lavorare mem-disk su una partizione dedicata tmpfs). Purtroppo ho rilevato problemi con alcuni portali basati su wordpress. Una specie di corruzione degli header; teniamo in considerazione che su questi siti vengono usati pesantemente i permalink mentre senza la loro attivazione non abbiamo rilevato problemi di sorta.
Ora sono tornato senza.

KeepAliveTimeout: attualmente il timeout e’ fissato a 3. Sto monitorando attraverso le funzioni di status dei server quanto beneficio porta questo valore rispetto al valore di default (http://w3techie.com/2010/optimize-site-high-traffic/)

riferimenti:

http://blog.monitis.com/index.php/2011/07/05/25-apache-performance-tuning-tips/

Aggiornamenti:

ho allungato il keepAliveTimeout a 10, ho inoltre impostato il limite di MaxKeepAliveRequest a 10000; successivamente ho impostato la coda di attesa di evasione delle richiesta (listenbacklog) a 500.

Poi, sempre che c’ero: ho cercato di capire un po’ meglio il gioco della cache di apache tra cache su disco e cache in memoria tentando di unire i vantaggi di entrambe. Premesso che la cache in memoria (mem_cache) non viene condivisa tra le diverse sessioni pertanto a meno di uno intenso di un singolo demone in grado di sfruttare quanto messo da parte, si ottiene solo uno spreco di memoria senza un vantaggio effettivo sul carico generale, ho optato nell’uso di disk_cache.

Disk_cache ha il vantaggio di condividere la cache tra tutti i demoni attivi, quindi risparmio di memoria e maggiore efficienza nell’usare la stessa risorsa tra piu connessioni. Per ovviare alla lentezza di accessi continui al disco, ho usato un’area tmpfs dove far finire la cache stessa. Il vantaggio effettivamente si vede soprattutto su quei siti che hanno accessi continui.

nota:

mount -t tmpfs none –directory dove finisce la cache–

la voce –directory dove finisce la cache– corrisponde a quanto riportato nella configurazione del disk_cache (Apache su debian: CacheRoot /var/cache/apache2/mod_disk_cache).

Questo limite puo’ essere aggiornato localmente usando due righe da inserire in htaccess:

php_value upload_max_filesize 50000000
php_value post_max_size 50000000

la configurazione di default e’ ottima, ma in caso di aumento dei dati in entrata (mailserver in particolare, ma non tralasciamo dhcp, dns) la configurazione di default complica un po’ l’esistenza.

alcuni dati sono ridodanti. Il tipico esempio sono i messaggi di posta generati da cron che vengono contemporaneamente registrati in syslog e in mail. Leggere poi questi file diventa frustrante.

andiamo a modificare il file.
tralasciando tutte le opzioni generali mettiamo mano nella sezione che riguarda le “RULES”:

la riga che fa riferimento a syslog deve essere modificata in quanto, come indicato nella riga di default “*.*” registra tutti i messaggi di tutto quello che ha qualcosa da dire.

modifichiamo questa riga con:

*.*;auth,authpriv.none;mail.none -/var/log/syslog

in questo modo, gia’ non registriamo piu’ i dati delle mail (“mail.none“) che finiranno solo in mail.log.

una volta salvato il file, e’ sufficiente riavviare il demone che la nuova configurazione e’ subito operativa.

aggiungiamo: server dhcp

di default, il dhcpd server logga le proprie informazioni usando la riga: log-facility local7.

in pratica manda tutto quello che emette usando l’indicazione local7.

non ci resta che dire a rsyslog (o syslog) che vogliamo utilizzare un file diverso per memorizzare tutto quello che arriva con la facility “local7″:

nel file rsyslog.conf aggiungiamo l’indicazione per local7: local7.* ~/var/log/facility7.log

facciamo in modo che la stessa facility non venga registrata da altro file:

tipicamente: *.*;auth,authpriv.none,local7.none              -/var/log/syslog

salvare e riavviare.

considerando l’uso intelligente di severity e facility e’ possibile fare in modo che ogni demone possa registrare la propria messaggistica (sempre che faccia uso di rsyslog) in file organizzati a dovere in modo da non rendere impossibile l’esistenza.

riferimento: http://rsyslog.com

Il file ha una struttura estremamente semplice.

Ogni partizione viene definita da una sezione che abbia inizio con due parentesi quadre:

[root], p.es, definisce la partizione di root, [home] definisce la partizione usata poi come home.

per ogni sezione vanno poi definiti:

size = ovvero la dimensione della partizione,
type = il filesystem utilizzato,
mountpoint = l’effettivo mount point , eccetto per la part. di swap,
options = ovvero le opzioni di montaggio della partizione.

facendo un esempio pratico riporto un file che utilizzo io:

[root]
size=1G
type=xfs
mountpoint=/
options=sync,errors=remount-ro

[swap]
size=1G
type=swap

[home]
size=5G
type=xfs
mountpoint=/home
options=nodev,nosuid,noexec

[tmp]
size=0.5G
type=xfs
mountpoint=/tmp
options=nodev,nosuid,noexec

per utilizzare questa struttura deve essere usata l’opzione partition=nomescelto in xen-create-image.

La spiegazione ufficiale e’ qua : http://www.postfix.org/postconf.5.html.

l’utilizzo e’ semplice.

creiamo un file dove scriviamo:

@dominio serverdiinoltro1

account@dominio serverdiinoltro2

un bel postmap sul file in modo da ottenere il relativo cdb.

dopo di che, in main.cnf inseriamo quanto segue:

sender_dependent_relayhost_maps = hash:/etc/postfix/sender_maps

e refreshiamo la configurazione di postfix.

il discorso postmap va bene per piccole configurazioni. nulla vieta di usare altre soluzioni piu’ performanti e adatte alle scopo in base alle necessita’.

altro link: http://readlist.com/lists/postfix.org/postfix-users/14/74989.html utile allo scopo.

ambiente:
lighttpd
sqlite (2), il (3) attualmente non e’ supportato.
php5-cgi installazione standard debian.

problema 1:
durante l’installazione roundcube verra’ richiesto se affidare il lavoro a db-config di debian: io rispondo sempre NO.

problema 2:
una volta individuato il posto dove piazzare il db di sqlite provvedete a rendere scrivibile da tutti la dir, almeno a utente www-data (che e’ l’utente di lighttpd).

scaricate da roundcube un pacchetto vergine di installazione di roundcube perche’ servira’ il file SQL/sqlite.initial.db che non ho trovato nell’installazione standard di roundcube.

inizializzate il db con sqlite -init “dove lo avete messo”/SQL/sqlite.initial.sql “/posizione del db/nome del file che avete intenzione di creare”.

provvedete a utenti e diritti per lo stesso discorso di cui sopra.

problema 3:
configurate il tutto (server smtp, pop e quant’altro).

ultimo dettaglio, di primo acchitto vi ritroverete davanti a un roundcube che dopo pochi istanti dal login vi sbattera’ fuori.

nei log troverete a ripetizione questo errore:

PHP Deprecated: Assigning the return value of new by reference is deprecated in /usr/share/php/MDB2.php on line 2647

poco male, non inficia, almeno per il momento, pero’, ho scoperto che roundcube va in conflitto con suhosin che ovviamente viene installato di default.

come da ricerchina veloce sul web, ho aggiornato mdb2 (per upgrade mdb2).

problema 4:

se abbiamo un’altra installazione roundcube e’ logico pensare di esportare il db e importarlo nella nuova. anche qui c’e’ un problema, semplice, ma rognoso: nel db, ci sono diverse tavole (contacts,event, messages,identities) tutte legate alla tabella users attraverso la join su users.user_id. Ogni volta che un utente si collega, se esiste in users si va avanti, altrimenti viene creato un nuovo record. Importando la tabella saltano totalmente gli id tra users e le altre tabelle in quanto sulla nuova installazione gli utenti vengono ricreati mano a mano che si collegano. Per risolvere basta risistemare gli id nelle quattro tabelle, in base alle nuove connessioni. Probabilmente ci sara’ un sistema meno incasinato, ma per il momento va bene cosi’.

altro problema relativo a un piccolo baco nella gestione dell’imap:

PHP Warning: strtolower() expects parameter 1 to be string, array given in /…/roundcube/program/include/rcube_imap.php on line 1285

(http://trac.roundcube.net/ticket/1486284)  corretto seguendo sempre le indicazioni sul trac di roundcube (http://trac.roundcube.net/changeset/3176):

net131 (131):/usr/share/roundcube/program/include# diff rcube_imap.php rcube_imap.php.originale
1285,1290c1285,1287
< //if (strtolower($part[$i][0]) == 'message' ||
< // (in_array('name', (array)$part[$i][2]) && (empty($part[$i][3]) || $part[$i][3]=='NIL'))) {
< // fetch message headers if message/rfc822 or named part (could contain Content-Location header)
< if (!is_array($part[$i][0]) && (strtolower($part[$i][0]) == 'message' ||
< (in_array('name', (array)$part[$i][2]) && (empty($part[$i][3]) || $part[$i][3]=='NIL')))) {
< $part_headers[] = $struct->mime_id ? $struct->mime_id.'.'.($i+1) : $i+1;
---
> if (strtolower($part[$i][0]) == 'message' ||
> (in_array('name', (array)$part[$i][2]) && (empty($part[$i][3]) || $part[$i][3]=='NIL'))) {
> $part_headers[] = $struct->mime_id ? $struct->mime_id.'.'.($i+1) : $i+1;

Si deve quindi provvedere ad aumentare il numero di risorse loop mappabili. In sintesi si tratta di caricare il modulo loop con un numero maggiore attraverso l’opzione max_loop.

Si puo’ provvedere al boot modificando il file modules (modules.conf in alcune versioni) inserendo o sostituendo loop con loop max_loop=64.

se non possiamo riavviare la macchina, la soluzione e’ fermare tutte le vm xen, rimovere il modulo loop e provvedere con “modprobe loop max_loop=64″. Successivamente possiamo riavviare la baracca.

Il 64 e’ il numero di loop che potremo utilizzare.

/dev/loop4 on /tmp/YJnmLmyJJ0 type xfs (rw)
proc on /tmp/YJnmLmyJJ0/proc
devpts on /tmp/YJnmLmyJJ0/dev/pts

puo’ capitare che il processo di generazione venga interrotto accidentalmente (nel mio caso, p.es, visto che lavoro sempre da remoto, ci potrebbe stare una caduta della connessione verso le macchine interessate).

in questo caso, nonostante il processo di creazione sia interrotto, i mountpoint restano attivi.

e’ buona cosa ripulire questa situazione smontando le unita’ interessate a xen.

ATTENZIONE: non andate prima a cancellare il file generato, ma smontate i vari mountpoint nel loro giusto ordine (dal piu’ basso – dev/pts, proc – al piu’ alto). Poi potete ripartire con la nuova generazione.

SUGGERIMENTO: se, come me, lavorate da remoto, un tool utile potrebbe essere “screen” che vi consente di staccare la sessione dalla connessione attiva e metterla in background. Nel caso di disconnessione, non perderete l’opera in corso.

la prima: giocare con le porte, programmando il firewall in modo che ogni porta venga dirottata verso una particolare macchina.

la seconda: facciamo in modo che sia il server vnc a collegarsi verso di noi. Noi mettiamo il client in ascolo con l’opzione -listen .

l’ultima e quella di utilizzare la redirezione di ssh.
in pratica ci colleghiamo al nostro server – presupponde che si tratti di un server linux con tanto di ssh attivo. usiamo l’opzione -L per forwardare l’ip del vnc in ascolto sul nostro localhost. A questo punto basta pure un vncviewer localhost che gia’ possiamo connetterci.

Inoltre, per migliorare le performance, ho giocato stasera con le seguenti opzioni, che devo dire hanno reso un servizio decisamente alto al godimento della sessione:

vncviewer -compresslevel 9 -quality 0 -depth 2 -noshared -encoding tight localhost

di solito la connessione e’ abbastanza stantia. Sto’ giro e’ andata di una velocita’ notevole, ma goduta prima.