We are pleased to inform you that you have successfully passed the NETASQ ADMINISTRATOR Version 9 certification.

—

CERTIFICATO

Teleport è una piccola utilità di sistema che si installa sul Mac nelle preferenze di sistema e fa una cosa semplicissima ma in certi contesti utilissima: permette di utilizzare più Mac con lo stesso Mouse e tastiera.

In pratica possiamo lavorare su piu computer senza cambiare mouse e tastiera, in modo semplice e trasparente.

Il mouse e la tastiera sono legati al movimento del mouse in modo simile a quando si si lavora con piu monitor in modalità di estensione scrivania: una volta che il mouse esce dall’area del monitor entrando nel raggio di azione del Mac che abbiamo disposto accanto, mouse e tastiera prendono il controllo dell’altra macchina.

Nel layout possiamo simulare la disposizione fisica dei Mac attraverso un comodo e intuitivo layout simile alle preferenze Monitor quando appunto abbiamo piu monitor a disposizione, e decidere alcune opzioni:

se possiamo trasferire files tra le macchine, impostare una scorciatoria

da tastiera per lo switch, se vogliamo condividere gli appunti e poi se vogliamo abilitare la cifratura della trasmissione dei dati, un centro di notifiche ecc.

Il software è donation-ware, il che significa che può essere usato gratuitamente se lo si desidera e va installato su tutti i Mac che intendiamo controllare.

La caratteristica base è che il repository dei files può essere manutenuto su qualsiasi server Web (Apache), quindi può andare bene OsX ma anche Linux o un NAS.
Utilizzando il protocollo HTTP poi otteniamo alcuni vantaggi basilari: in particolar modo la velocità del deploy rispetto ad altri protocolli specifici o ad hoc, secondariamente un protocollo standard come HTTP non richiede di solito modifiche importanti sulle policy di sicurezza.
Per approfondire le caratteristiche comunque rimandiamo a questo articolo…

Affrontiamo oggi un caso pratico sulla base della documentazione esistente.

La documentazione ufficiale fa riferimento a una installazione di munki client/server sulla stessa macchina. Il caso che affronteremo invece riguarda l’installazione del server (repo) su Linux (Ubuntu/Debian) e della parte Client (compresa l’amministrazione dei pacchetti) su un OsX 10.7 Lion.

Per ogni client OsX (e per la macchina amministrativa con la quale creeremo i pacchetti) è necessario scaricare il pacchetto qui ed installarlo (è richiesto un riavvio).

Per il server è necessario soltanto preparare una directory e un Virtual Host (per semplificare l’accesso) e mantenere ordinate le directory all’interno.
Munki per funzionare correttamente necessita di questa disposizione di cartelle nel repository (vedi anche foto):

/repo/catalogs
     /manifests
     /pkgs
     /pkgsinfo

Nella maggior parte dei casi (e specificatamente questo esempio), il software può essere utilizzato direttamente da un normalissimo file .dmg. E’ il caso di quegli applicativi che si installano drag-&-drop direttamente dall’immagine montata. Questi files .dmg vanno posti nella directory “pkgs”.
le altre tre cartelle conterranno dei files descrittivi e metadati nei quali si stabiliscono regole di deploy e informazioni di vario tipo e sono normalmente generati dai tools di munki.
Nella directory “catalogs” per esempio è contenuta la lista dei pacchetti disponibile, la directory “manifests” contiene i “manifesti” cioè una lista di ciò che deve essere installato e/o rimosso per una data macchina/client. Questi “manifesti” possono essere nidificati (sono in effetti dei files plist standard) e contenerne altri, per esempio si può fare un manifesto che contiene una lista completa di tutti i software disponibili per tutti i client e contenere a sua volta una lista di software installabili in più solo per determinati client.
Prepariamo quindi il repository (dando per scontato che su Linux Apache sia già installato e attivo).
Prima lo prepariamo in locale, con la struttura in cartelle di cui sopra, poi lo popoleremo con un applicativo e infine lo trasferiremo sul server.
Nel nostro esempio installeremo Google Chrome.
Potete scaricarlo direttamente dai link qui accanto e posizionare il file .dmg nella cartella /repo/pkg come indicato di seguito:

• Inserire il pacchetto googlechrome.dmg nella cartella repo/pkgs
• Creare il file pkginfo per i due software col seguente comando (ATTENZIONE: comando su un solo rigo):

/usr/local/munki/makepkginfo /pathtolocalrepo/pkgs/googlechrome.dmg > /pathtolocalrepo/pkgsinfo/googlechrome.pkginfo

• Creare il catalogo:

/usr/local/munki/makecatalogs /pathtolocalrepo/

• Creare un manifesto di prova (useremo il nome “testing”, da non usare ovviamente in ambienti di produzione:

< ?xml version="1.0" encoding="UTF-8"?>
< !DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>catalogs</key>
        <array>
                <string>testing</string>
        </array>
        <key>managed_installs</key>
        <array>
                <string>Google Chrome</string>
        </array>
</dict>
</plist>

E salvarlo nella directory /pathtolocalrepo/manifests con il nome “testing” (senza estensione).
A questo punto il repository è pronto, possiamo trasferirlo tutto quanto (tutta la cartella “repo”) nel server che abbiamo scelto, su Linux si può portare tutto il repo nella cartella di default dalla quale apache serve i files html: /var/www, ma va bene qualunque altra soluzione: nel mio caso per es. ho utilizzato un piccolo server Ubuntu LTS, ho creato un virtual host del tipo repo.dominiointerno.lan e una volta istruito il mio DNS interno, ho configurato di conseguenza i client OsX a “pescare” da lì.

Per configurare i client OsX dobbiamo dire al Managed Software Update a scaricare dal nostro server web.
Dobbiamo farlo su ogni client, in questo caso usiamo la macchina OsX (10.7) sulla quale abbiamo scaricato e prodotto i pacchetti (e sulla quale teniamo una copia del repository). Digitiamo i seguenti 2 comandi:

sudo defaults write /Library/Preferences/ManagedInstalls.plist ClientIdentifier testing
sudo defaults write /Library/Preferences/ManagedInstalls.plist SoftwareRepoURL http://indirizzoserver/repo

A questo punto non ci rimane che lanciare l’update software, possiamo farlo via terminale con il seguente comando: “sudo /usr/local/munki/managedsoftwareupdate”
O molto piu semplicemente lanciando l’apposito programma che munki ha installato per noi e che trovate in: /Applications/Utilities/ e che si chiama “Managed Software Update.app”.
A questo punto potrete installare Chrome sui vostri Mac.

Nel prossimo articolo entremo in profondità nelle policy di installazione, deploy, rimozione, temporizzazione, hosting di Apple Updates, installazione con o senza approvazione utente e via dicendo: Munki a dispetto della sua apparente semplicità è uno strumento molto potente, flessibile e configurabile…

ENJOY!

Adesso veniamo alle novità e i cambiamenti:

• Non esiste CD o DVD di installazione, l’installazione può essere remota.
• Non esiste un OsX Server, esistono una serie di App che rendono “Server” ogni Lion
• Kernel a 64 bit di default
• Nuovo applicativo (Server.app) per il management “Easy” dei servizi: On/Off Switch
• Assenza di default di Server Admin, Workgroup Manager, Sys Image Utility (da scaricare a parte)
• Difficoltà di andare nel dettaglio dei servizi con gli strumenti grafici (es. WWW)
• Nessuna funzionalità di Primary Domain Controller per Windows
• Eliminazione di MySQL a favore di PostgreSQL (nessuna U.I. a disposizione)
• Eliminazione di FTP e PPTP, Quicktime Streaming Server, Axis, Tomcat, Mobile Access
• Nuovo Wiki Server
• Nuovo Webmail
• Nuovo sistema di notifiche

La macchina era un vecchio server web/ftp che nel momento di maggior gloria ha servito anche 200 domini. Da allora sono passati alcuni anni e i domini sono migrati in un server web Linux per una serie di motivi, tra i quali ha pesato molto l’assenza di un pannello di configurazione e deploy di clienti/servizi/utenti ecc come ne esistono invece in ambito Linux (Plesk, cPanel).
Abbiamo quindi ritirato la macchina dal Data Center nel quale era ospitata per decidere che farne.
La macchina e’ un XServe Late 2006, primissima versione Intel (codice Apple 1,1), con alimentazione ridondata (doppio alimentatore), un doppio Xeon 2,0 GHz dual core, 6GB di Ram, e sopra vi era installato un vetusto OsX Server 10.4.11.
Non abbiamo provato ad utilizzare un MacPro della stessa generazione (codice 1,1) in produzione dal 2006 al 2008, ma TEORICAMENTE dovrebbe funzionare in quanto si tratta di hardware analogo.
Avevamo davanti alcune possibilità: rimetterla in piedi con un Os Apple aggiornato e riutilizzarla come server Apple, oppure installarci Debian e poi inserirla nel Cluster Proxmox che abbiamo gia in funzione nel nostro Data Center. Opzione finale: una triste rottamazione…

Prima di decidere, mi sono occupato di creare un ambiente di test e valutare la fattibilità del progetto.
I problemi da affrontare sono stati molteplici:

1. Superare il blocco firmware dell’EFI che su queste macchine non prevede lo startup da sistemi alternativi a OsX
2. Valutare se Linux (Debian v. 5.0.8, “Lenny”) riconosce la maggior parte dell’hardware, a cominciare dai controller dei dischi, le schede ethernet ecc.
3. Una volta installato linux, verificare il supporto di KVM e OpenVZ, le tecnologie di virtualizzazione su cui si basa Proxmox e installare Proxmox dai repository
4. Inserire la macchina nel cluster e testare le funzionalità

Come prima cosa e’ stato necessario installare un firmware alternativo open source^[1]: rEFIt che permette l’installazione di sistemi Win o Linux su questi vecchi Apple Intel (Bootcamp infatti non e’ supportato).

Il problema di questo software e’ che richiede una partizione sul disco rigido anche piccola, HFS+ nel quale essere installato, questo comporta alcuni problemi secondari poi per la gestione del bootloader di Linux che non può essere installato nel Master Boot Record (MBR), pena il mancato startup della macchina.
In alternativa è possibile installare rEFIt in un dongle USB visto che questa macchina supporta lo startup da USB ed è la strada che seguiremo per questo articolo.

Lo si trova a questo indirizzo: ed e’ dotato di un installer “amichevole”.
Basta scaricare la versione Mac disk image (o iso) e poi utilizzare l’installer.
Per installare invece su una chiavetta USB e’ necessario qualche passaggio in più:

• Scaricare il disco immagine (.dmg o .cdr)
• Formattare il dongle USB in HFS+ (con Disk Utility)
• Copiare la cartella “efi” nel primo livello della chiave USB
• “Benedire” la cartella come disco di avvio (blessing): aprire il terminale e digitare:

cd /Volumes/nomediscousb/efi/refit
./enable.sh

Questo passaggio e’ necessario ma non e’ ancora sufficiente a far partire Debian, infatti Debian non supporta EFI su piattaforme 64 bit. Ps. la versione di Debian che ci interessa e’ la Lenny, 5.x ^[2]
Quello che ci serve e’ produrre un grub2 come loader da installare in rEFIT. E’ possibile crearlo direttamente in Linux seguendo queste istruzioni: http://grub.enbug.org/TestingOnMacbook l’unica cosa a cui dobbiamo prestare attenzione e’ che la macchina in oggetto (XServe 1,1 2006) ha la caratteristica unica di utilizzare un EFI a 32 Bit nonostante la piattaforma sia a 64 Bit. Questo non e’ un problema, il linux che metteremo sarà pienamente 64 Bit ^[3], ma dovremo utilizzare un Grub2 che sia a 32 Bit.

L’operazione non e’ banalissima, ma grazie al lavoro svolto da Martijn Broeders nel suo Blog (finalizzato a installare Fedora 11 sulla stesso tipo di macchina), abbiamo  a disposizione un grub gia pronto da utilizzare. Potete seguire la sua guida, oppure i passi seguenti:

• Scaricare la versione “leggera” (netinstall) di debian AMD64 “Lenny” e masterizzarla
• File e settings per grub

Una volta scaricati il file grub.zip, decomprimetelo e piazzate i files ‘grub-dumpbios‘ e la cartella ‘grubefi-karmic‘ nella cartella ‘efi‘ che si trova nella radice del disco di avvio sul quale abbiamo installato rEFIt. Efi riconoscerà automaticamente questi files.
A questo punto apriamo ‘grub.cfg‘ nella cartella  ’grubefi-karmic‘ con un editor di testo, troveremo dentro un sacco di roba…

Eliminiamo tutta la parte che segue l’entry del fake bios lasciando intatte le entry relative al CD di Debian Lenny e al reboot e allo startup in modo che il nostro file diventi questo:

Visualizza codice



# grub.cfg pxw 20090316

timeout=20
default=0

set F1=ctrl-x
set F2=ctrl-c
set color_normal=yellow/blue

menuentry "0-testfakebios" {
# for debugging set debug=efi
hexdump -s 0xc0000 (mem)
fakebios
hexdump -s 0xc0000 (mem)
# deliberate error to get wait for key
xxx
}

menuentry "Debian-Lenny-CD" {
fakebios
root=cd0
linux /install.amd/vmlinuz nomodeset
initrd /install.amd/initrd.gz
}
menuentry "REBOOT" {
reboot
}
menuentry "SHUTDOWN" {
shutdown
}



Una volta salvato il file possiamo finalmente avviare la macchina e ottenere all’avvio la schermata di rEFIt che ci consentirà di avviare il server con il CD di Debian precedentemente masterizzato.
L’installazione di Debian non sarà trattata in questo articolo ma è semplicissima, basta seguire le informazioni dell’installer con queste uniche accortezze:

• Partizionare tutto il disco interno accettando i valori di default o scegliere un partizionamento  customizzato LVM (non trattato in questo articolo)
• Installare soltanto il sistema base, senza interfaccia grafica o altre ozpioni, scegliere eventualmente solo SSH se la versione lo consente.
• Installare il grub nell’MBR

A questo punto abbiamo installato Debian nel nostro Xserve!!!
Ma la macchina non può ancora partire perchè manca l’entry nel grub del dongle USB.
Eseguiamo quindi uno spegnimento della macchina [shutdown -h now], prendiamo la nostra chiave USB e andiamo a modificare di nuovo il file  grub.cfg’ nella cartella  ’grubefi-karmic’ aggiungendo questa entry:

menuentry "Debian-Lenny" {
fakebios
root=hd1,1
linux /boot/vmlinuz-2.6.26-2-amd64 root=/dev/sdb1 ro nomodeset
initrd /boot/initrd.img-2.6.26-2-amd64
}

Il posizionamento della root e’ hd1,1 se si tratta del primo alloggiamento dell’Xserve, eventualmente cambiare i parametri in base alle proprie esigenze.

Il file intero risultante e’ il seguente (basatevi su questo per il grub.cfg):

Visualizza codice



# grub.cfg pxw 20090316

timeout=20
default=0

set F1=ctrl-x
set F2=ctrl-c
set color_normal=yellow/blue

menuentry "0-testfakebios" {
# for debugging set debug=efi
hexdump -s 0xc0000 (mem)
fakebios
hexdump -s 0xc0000 (mem)
# deliberate error to get wait for key
xxx
}

menuentry "Debian-Lenny-CD" {
fakebios
root=cd0
linux /install.amd/vmlinuz nomodeset
initrd /install.amd/initrd.gz
}
menuentry "Debian-Lenny" {
fakebios
root=hd1,1
linux /boot/vmlinuz-2.6.26-2-amd64 root=/dev/sdb1 ro nomodeset
initrd /boot/initrd.img-2.6.26-2-amd64
}
menuentry "REBOOT" {
reboot
}
menuentry "SHUTDOWN" {
shutdown
}



Una volta salvato il file sul dongle USB saremo in grado di avviare l’XServe da HD con la debian appena installata. Modificate i timeout in secondi per l’avvio della macchina (sia per il rEFIT che per il grub) a vostro piacimento.
Debian riconosce la maggior parte dell’hardware e permette di utilizzare la macchina come un vero e proprio server Linux.
Nota: Non abbiamo provato ad utilizzare un MacPro della stessa generazione (codice 1,1) in produzione dal 2006 al 2008, ma TEORICAMENTE dovrebbe funzionare in quanto si tratta di hardware analogo.

La prossima parte dell’articolo  riguarda l’installazione ed il setup di Proxmox su Debian. A chi interessava installare solo Debian e basta può senz’altro fermarsi qui.

L’installazione di Proxmox è un passo piuttosto facile, quello che a questo punto è importante, è attivare le estensioni Intel VT dei processori che sono un set di istruzioni dedicate alla virtualizzazione e che KVM ^[4] sfrutta nativamente (come altri software di virtalizzazione).
Ovviamente tanto per semplificarci la vita (!) su Apple XServe le estensioni Intel VT sono disattive di default.
Sulle macchine dotate di Bios si deve operare direttamente nel Bios per attivarle, con le macchine Apple basate su EFI la procedura e’ diversa. Alcune indicazioni in rete mi hanno messo sulla strada giusta, bisogna fare così^[5]:

1. Riavviare il server e premere “alt” o aspettare la schermata di rEFIt
2. Selezionare la voce rEFIt tra le icone ed entrare nel menu di comando rEFIT
3. Nel menu di rEFIT scegliere “console”
4. Al prompt digitare il comando

   fs0:

5. Digitare

   ls

6. Se a questo punto si ottiene un codice di errore vuol dire che il volume di root non e’ listato, provare a incrementare il “volume number” per esempio “fs1:” e tornare al passo precedente, e così via.
7. Se non si ottiene errore, al comando “ls” dovrebbe seguire l’elenco dei files presenti nel disco (Users, Volumes, etc, match, private, var, usr ecc)
8. Digitare:

   cd efi

9. Inserire il comando:

   cd vmx

10. Inserire il comando:

    vmx-var-set.efi

11. Se non c’e’ nessun errore la procedura e’ andata a buon fine e si può uscire dalla console con il comando: “exit“, altrimenti se sulla console compare un errore, qualcosa e’ andata storto e bisogna ripartire daccapo nella procedura…
12. Spegnere e lasciare il Mac spento per almeno 10 secondi (togliere i cavi di alimentazione per sicurezza) e poi riavviare.

A questo punto si potrà verificare l’avvenuta abilitazione delle Intel VT extensions direttamente da Proxmox ^[6], oppure da Debian ^[7] La guida per l’installazione di Proxmox la si trova direttamente nel sito ufficiale, la riassumiamo per completezza ^[7]:

1. Installare il repository di Proxmox (modifica del file sources.list):

nano /etc/apt/sources.list

Aggiungere i repository in modo che il contenuto sia:

deb http://ftp.debian.org/debian lenny main
# PVE packages provided by proxmox.com
deb http://download.proxmox.com/debian lenny pve
# security updates
deb http://security.debian.org/ lenny/updates main

2. Aggiungere la chiave per il repository:

wget -O- "http://download.proxmox.com/debian/key.asc" | apt-key add -

3. Aggiornare il repository nel sistema:

aptitude update

4. Installare Proxmox:

aptitude upgrade

5. Installare Il Kernel:

aptitude install pve-kernel-2.6.32-4-pve

A questo punto basta comunicare al file grub.cfg qual’è il nuovo kernel di avvio. Quindi una volta finita l’installazione, facciamo lo shutdown della macchina^[8] e andiamo a modificare di nuovo il file grub.cfg nella nostra chiave USB che si trova in /Volumes/nomediscousb/efi/grubefi-karmic aggiungendo questa parte:

menuentry "Debian-Proxmox" {
fakebios
root=hd1,1
linux /boot/vmlinuz-2.6.32-4-pve root=/dev/sdb1 ro nomodeset
initrd /boot/initrd.img-2.6.32-4-pve
}

In modo che tutto il nostro file diventi ^[9]:

Visualizza codice



# grub.cfg pxw 20090316

timeout=20
default=0

set F1=ctrl-x
set F2=ctrl-c
set color_normal=yellow/blue

menuentry "0-testfakebios" {
# for debugging set debug=efi
hexdump -s 0xc0000 (mem)
fakebios
hexdump -s 0xc0000 (mem)
# deliberate error to get wait for key
xxx
}

menuentry "Debian-Proxmox" {
fakebios
root=hd1,1
linux /boot/vmlinuz-2.6.32-4-pve root=/dev/sdb1 ro nomodeset
initrd /boot/initrd.img-2.6.32-4-pve
}
menuentry "Debian-Lenny-CD" {
fakebios
root=cd0
linux /install.amd/vmlinuz nomodeset
initrd /install.amd/initrd.gz
}
menuentry "REBOOT" {
reboot
}
menuentry "SHUTDOWN" {
shutdown
}



Non è necessario modificare il bootloader di Linux perchè viene completamente bypassato dai parametri che sono nel rEFIt visto che e’ rEFIt il bootloader principale.

Se e’ andato tutto bene al riavvio della macchina loggatevi su linux e digitate:

uname -a

Dovreste ottenere la versione di Linux e il Kernel giusto (Linux 2.6.32-4-pve)

A questo punto è necessario installare i pacchetti che costituiscono il cuore della console di comando di Proxmox:

aptitude install proxmox-ve-2.6.32 ntp ssh lvm2

OK!, abbiamo praticamente FINITO: collegatevi all’indirizzo IP da una macchina in rete, preceduto da https://

https://youripaddress

Dovreste a questo punto arrivare alla pagina di configurazione, loggatevi come root ei giochi sono praticamente fatti…

Un ultimo passo per chi e’ interessato a costituire un cluster con due Proxmox:

La procedura di inizializzazione di un cluster è descritta qui, ed è piuttosto semplice anche se servono alcune accortezze:

1. Innanzitutto la procedura la si esegue solo via terminale
2. Secondariamente e’ necessario che i due cluster abbiamo hostname diversi
3. E’ molto importante che siano sincronizzati via NTP per evitare errori, visto che il cluster e’ sincronizzato anche come data e ora…

La procedura prevede la promozione di un Host a Master e uno o più di uno definiti come “nodi”.

Loggarsi sull’host principale e creare il master:

pveca -c

Controllare lo status del cluster:

pveca -l

Loggarsi sul secondo Host per promuoverlo a nodo, fare attenzione a che non ci siano già VM attive o se ci sono che non abbiamo ID che possano andare in conflitto con le VM eventualmente presenti sul Master:

pveca -a -h IP-ADDRESS-MASTER

Controllare lo status del cluster:

pveca -l

Se tutto e’ OK si dovrebbe vedere una schermata simile:

pveca -l
CID----IPADDRESS----ROLE-STATE--------UPTIME---LOAD----MEM---ROOT---DATA
 1 : 192.168.7.104   M     A    5 days 01:43   0.54    20%     1%     4%
 2 : 192.168.7.103   N     A    2 days 05:02   0.04    26%     5%    29%

Potete controllare il cluster direttamente nell’interfaccia Web (attiva su entrambi gli IP dei nodi) e fare prove anche di migrazione a caldo di VM tra un nodo e l’altro!!!

ABBIAMO FINITO!!!

Ringrazio Martijn Broeders e il suo splendido lavoro che mi ha consentito di procedere lungo il percorso, dandomi indicazioni utilissime, e anche tutte le risorse citate nell’articolo.
Ci tengo a precisare che si tratta di un caso reale e che questa macchina funziona regolarmente in un cluster Proxmox attivo presso il nostro principale data center.

Chi e’ registrato sul Blog può scaricare la versione in PDF di tutto l’articolo, ottimizzato per la stampa!

1. ^[1] L’approccio che seguiremo permetterà di far partire e funzionare la versione 1.1 di XServe, per chi fosse interessato alle versioni successive di Xserve Intel (2,1 e 3,1) dovrà seguire un altra strada; a maggior ragione chi volesse installare linux su macchine PPC (G4 e G5) che richiedono software specifico per quella piattaforma. ↩
2. ^[2] E’ necessaria questa versione se vogliamo installare Proxmox ↩
3. ^[3] E’ necessario per sfruttare appieno le possibilità di virtualizzazione, utilizzare un sistema a 64 Bit, nel caso di Debian il codice versione e’ Amd64 ↩
4. ^[4] una tecnologia di virtualizzazione utilizzata da Proxmox ↩
5. ^[5] Dopo l’inserimento di ogni comando premere “invio” ↩
6. ^[6] Basterà entrare sulla console di amministrazione di Proxmox e provare a creare una virtualizzazione KVM: se proxmox lo consente vuol dire che le estensioni Intel VT sono attive, altrimenti si otterrà un errore specifico ↩
7. ^[7] Bisogna digitare il comando:

   grep --color vmx /proc/cpuinfo

   Se nell’output c’e’ il flag “vmx” allora il processore ha le Intel VT abilitate e possiamo procedere ad installare Proxmox. ↩

8. ^[7] E’ necessario che Debian sia installata e funzionante ecollegata in rete ed è fortemente consigliato che sia installato SSH server/client ed NTP per la sincronizzazione dell’ora ↩
9. ^[8] shutdown -h now  ↩
10. ^[9] Nel file seguente ho tolto l’entry relativa allo startup “normale” di Debian che diventa inutile ↩

A questo si puo’ porre facilmente rimedio o installando i giusti codec (Quicktime e’ modulare e permette con l’aggiunta di codec di aprire e riprodurre molti piu formati di quelli standard) o in ultima istanza, utilizzando player universali.
Riportiamo in questo articolo, l’elenco dei più utilizzati ed utili.

Perian è un software free che permette la visualizzazione e riproduzione di una serie piuttosto ampia di formati (Avi, Divx, Flv, Mkv ecc vedi la lista completa). Si integra perfettamente con Quicktime in modo del tutto trasparente all’utente, permettendo di utilizzare il player di Quicktime anche per i formati che prima non si potevano aprire.
Installa un pannello di controllo in “Preferenze di sistema” da cui è possibile aggiornare il software:
E’ un software molto utile e potente.

Un altro software molto utile e’ “Flip for Mac” proprietario di Microsoft che serve a riprodurre i formati Window Media Audio e Video. Anche questo software si integra in modo trasparente con Quicktime diventando un componente di esso e permettendo quindi anche l’esecuzione di questi formati sui siti che lo inseriscono nelle loro pagine web.
Anche questo pacchetto installa un pannello in preferenze di sistema da cui impostare alcune opzioni e richiedere aggiornamenti e installa anche in “Applicazioni” una cartella con un comodo uninstaller, una guida ecc.
Insieme a questo pacchetto si trova anche l’installer di Silverlight che e’ necessario per visualizzare molti programmi dai siti della Rai.

Altro componente abbastanza diffuso e’ Real Player. Per poter visualizzare gli streaming in real player video o i filmati con quella codifica. Una cosa piuttosto utile di questo software e’ che installa un pratico downloader che permette anche lo scaricamento di filmati flash (flv) da siti come youtube.

Per tutti quei video o audio che non riuscite a leggere nonostante tutto, non rimane che affidarci a VLC, un riproduttore multimediale free che legge praticamente di tutto. non e’ integrato nel sistema operativo, ha un suo player, ma con questo normalmente si legge davvero di tutto…

KVM in particolare essendo stato integrato nello sviluppo del Kernel di Linux, sembra essere candidato a rimpiazzare almeno Xen nelle preferenze degli utenti Linux. Red Hat Enterprise sta costruendoci intorno una sua soluzione “professionale”.

Come spesso accade a determinare una scelta piuttosto che un altra, oltre alla bontà intrinseca della tecnologia, buona parte della differenza la fanno gli strumenti di amministrazione (non a caso un vanto di VmWare).
A questo proposito una azienda europea, sta lavorando molto bene in questo settore producendo una distribuzione basata su Debian che include KVM e OpenVZ come tecnologie, aggiungendovi validi e intuitivi strumenti di amministrazione basati su Web. SI tratta di “Proxmox”

In particolare Proxmox si installa su piattaforma x86 (richiesto il supporto dei processori a 64 Bit con estensioni IntelVT/AMD-V) con un installer semplice ed immediato che richiede di occupare tutto il disco disponibile. In pochi minuti si dispone di una comoda interfaccia web di management per il deploy di immagini virtuali e interi sistemi operativi.
Proxmox permette l’utilizzo di Virtualizzazione a livello di container (OpenVZ), full virtualisation o para-virtualizzazione (KVM).
Possiamo utilizzare immediatamente una serie di immagini preimpostate su repository remoto (direttamente distribuite dal team di Proxmox) o utilizzare qualsiasi ISO in nostro possesso da inserire nel repository centrale del sistema.
Tramite l’interfaccia web e’ possibile aprire una console grafica che consente di monitorare l’installazione remota del nostro sistema virtualizzato (una sessione VNC embedded in un applet Java), ovviamente alla macchina virtuale possiamo assegnare Ram, CPU, Spazio disco ecc in completa libertà.
Il sistema permette di gestire in modo flessibile lo spazio a disposizione e gli eventuali storage (iSCSI, NFS ecc.), il modello di storage si basa su DRDB.
E’ possibile aggiungere nodi hardware a proxmox costruendo un cluster di risorse, abbiamo anche dei tools di Live migration che ci consentono di spostare a “caldo” i sistemi, da un host a un altro.
Essendo basata su debian abbiamo la possibilità di accedere a livello basso sul sistema operativo (per intenderci e’ sempre attivo un accesso root) ed e’ anche possibile installare una Debian e trasformarla in seguito in una macchina proxmox.
E’ un oggetto molto interessante da tenere in considerazione e da testare anche per installazioni di una certa importanza, vista la stabilità della soluzione.
Di seguito alcune immagini, in un prossimo articolo tratteremo un caso reale.

Mi chiamo Andrea Posarelli e questo e’ il mio sito, l’angolino nel quale raccolgo idee, appunti “virtuali”, note e cose che mi sono state utili in qualche modo.
Ci sono alcune esperienze lavorative, una serie di informazioni utili di vario tipo sempre legate alla mia attività professionale, il curriculum, notizie, trucchi e suggerimenti.
Scegli una delle categorie di tuo interesse qui sulla sinistra e comincia la navigazione nel sito, oppure scorri cronologicamente in ordine di tempo i vari articoli o dai un’occhiata alle pagine del menu…
Ti auguro una buona navigazione, grazie per essere passato di qua, lascia pure un messaggio se vuoi contattarmi…

Sostanzialmente si tratta di un repository di applicativi funzionante sotto http (per il repo-server basta un Apache, quindi va bene anche un Linux per es.) per l’installazione di programmi orientati al Mac (siano essi updates di sistema che programmi di terze parti), dalle caratteristiche interessanti.

Ecco le caratteristiche salienti:

• Deploy software nuovo o aggiornamenti verso pochi o centinaia di Mac.
• Invio di patch di sicurezza sia in LAN o in VPN.
• Rimozione Applicativi
• Forza l’installazione di pacchetti con scelta obbligatoria o facoltativa.
• Compatibile con gli update Apple.
• Scala il deploying aggiungendo server all’infrastruttura.
• Individua le macchine in base all’user, hostname, versione Os ecc.
• Ottiene reportistica su tutti i client.
• Supporta pacchetti Apple-flat (.pkg)
• Supporta meta-pacchetti Apple-flat (.mpkg)
• Supporta pacchetti Apple-non-flats (.pkg)*
• Supporta meta-pacchetti  Apple-non-flats (.mpkg)*
• Supporta anche la rimozione del software
  
• Drag-and-drop immagini disco
• Pacchetti di deploy per Adobe CS3/CS4/CS5  creati con Adobe’s Enterprise Deployment tools – CS3 Info CS4 Info CS5 Info
• Svariati pacchetti Adobe CS3/CS4/CS5  updaters.
• Adobe Acrobat Pro 9.x updater disk images as downloaded from Adobe

* Questi pacchetti devono essere inseriti in un disco immagine (.dmg). I dischi immagine non devono contenere SLA da accettare

Il software funziona su Leopard (10.5.x) e Snow Leopard (10.6.x), l’applicativo e’ sviluppato principalmente in python quindi in teoria se compilato a “mano” con le giuste dipendenze potrebbe funzionare anche su OsX 10.4. L’altro requisito e’ Apache (va bene anche al condivisione web di osx client ovviamente, ma anche qualsiasi altro sistema non-Apple con Apache).
Ricordiamo che Munki è un tools dedicato al deploy applicativo e basta non permette di fare inventory, assistenza remota, management delle preferenze, imaging ecc.
Per funzionalità di questo tipo (e in molti casi anche di deploy) ricordiamo alcuni dei piu noti prodotti commerciali come: Casper Suite, Absolute Manage (ex: LANrev), KBox, e FileWave.

Come funziona:
Tramite un comodo installer che il pacchetto munki piazza su tutti i client si installano applicazioni da un repository, su tutti i client.
Sul server poi ci dovremo occupare di creare il repository, i vari rami, i manifesti, i file xml con le regole (ci sono i comandi appositi per farlo), sui client basterà configurare il client (indirizzamento verso il server) e utilizzarlo al posto del classico “Aggiornamento Software” (Software Update).
Il software e’ in grado di fare check periodici in automatico (randomici, per non intasare il server), i pacchetti possono essere installati anche da utenti non amministratori, ma l’utente locale non puo’ scegliere tra i pacchetti dato che l’amministratore sceglierà a seconda degli host, utenti e regole, quali pacchetti debbano essere o meno installati sulle singole macchine.
Se serve, il software identifica se un applicativo debba essere prima chiuso o meno, ed e’ in grado di funzionare anche senza alcun utente loggato.

Riferimenti:

• Per altre caratteristiche si rimanda al sito e alle FAQ.
• Per approfondire gli aspetti tecnici consigliamo questa serie di articoli (in lingua inglese):
  - MacEnterprise: Managing Software Installs with Munki – Part 1
  - MacEnterprise: Managing Software Installs with Munki – Part 2
  - MacEnterprise: Managing Software Installs with Munki – Part 3
  - MacEnterprise: Managing Software Installs with Munki – Part 4

Dopo aver cercato in lungo e in largo mi sono imbattuto in qualcuno che ha capito il perchè e ha risolto.

In pratica l’autenticazione sulle ADSL telecom e’ ininfluente, qualsiasi combinazione user/pass consentira’ la navigazione (normalmente si usa la classica aliceadsl/aliceadsl) ma si puo’ usare qualsiasi altra combinazione casuale. In questo modo pero’ la navigazione avviene solo per IP dinamico.

Invece per ottenere l’IP fisso bisogna utilizzare una particolare combinazione che si puo’ ottenere inserendo il MAC address del modem telecom nell’user (+ altra roba) e utilizzando una password particolare.

Poiche’ c’e’ bisogno del MAC address del router (il Pirelli ce lo ha scritto in una etichetta sul fondo), il cambio e’ possibile farlo SOLO e soltanto DOPO che e’ stato effettuato il primo collegamento col Pirelli e dopo che la telecom ha provisionato il router (operazione evidentemente necessaria per creare l’associazione del MAC address nella login).

I dati:

USER: MACADDRESSPirelli-0013C8-t@alicebiz.it
PASS: alicenewag

Posso testimoniare che funziona perfettamente. Ho testato la cosa su un normalissimo zyxel

Qui si puo’ vedere il prima e il dopo: prima con autenticazione pippo/pippo in PPPoE e il risultante Ip dinamico:

Dopo, con autenticazione “giusta” e il risultante IP pubblico (nonostante il router si aspetti un IP dinamico, e cioe’ imposto dal provider):

Ovviamente il “giochino” funziona anche se a fare l’autenticazione e’ un access point o un banalissimo Mac/PC con sopra il PPPoE, non ho provato col pirelli (ma dovrebbe funzionare gia di default visto che e’ configurato in routed+bridged) ma sullo Zyxel e’ bastato attivare la
modalità bridge e a valle fare l’autenticazione in PPPoE con un altro dispositivo (ho provato una pfsense che avevo su un PC ma anche una Apple Airport) e l’IP pubblico viene preso dal dispositivo tranquillissimamente.

Questo e’ importante perche’ nel mio caso avevo assolutamente bisogno di attestare una VPN IPSec sull’IP fisso della mia ADSL e sul Pirelli non si puo’ fare (tantomeno non e’ possibile utilizzare la modalita’ router+nat e i classici “virtual server) quindi avevo bisogno di un bridge per avere a disposizione l’IP fisso su un mio dispositivo (la Pfsense) sul quale poi ho effettivamente attestato la VPN.

Se infatti si controllano le opzioni vista nella finestra di ricerca (cmd + J) si può notare come questi parametri siano non più selezionabili e disattivati.

In particolare per le dimensioni e le etichette personalmente ho sempre ritenuto utile il loro utilizzo per ordinare il risultato delle ricerche.

E’ possibile risolvere questo piccolo problema andando a modificare il file delle preferenze del Finder: com.apple.finder.plist

Questo e’ quello che ci appare se chiamiamo le “opzioni vista” nella finestra di ricerca, come si può vedere, le opzioni in grigio non sono attivabili.

Per modificare il file com.apple.finder.plist e’ possibile utilizzare un qualsiasi editor di testo in grado di aprire i file plist come il gratuito Textwrangler o in alternativa con l’editor di Apple “Property List Editor”, disponibile se avete installato i developer tools.

ATTENZIONE: prima di fare danni, effettuate una copia del file com.apple.finder.plist da ripristinare nel caso qualcosa andasse storto.

Prendiamo in considerazione il primo metodo, quello con un editor di testo: aprite il file (si trova nella cartelle preferenze, nella libreria utente: ~/Library/Preferences) e con una semplice ricerca andate a cercare il valore corrispondente alla colonna da abilitare.

Cercate il valore: “SearchViewSettings” nel mio file si trova molto in basso (rigo 5115), a seguire trovate “ListViewSettings”, da li’ in poi basta si possono riconoscere i valori delle colonne (columns) e le si possono abilitare andando a cercare la chiave il cui valore da cambiare deve essere da “false” a “true”.

Questo e’ un esempio del codice:

<strong>&lt;key&gt;size&lt;/key&gt;
 &lt;dict&gt;
 &lt;key&gt;ascending&lt;/key&gt;
 &lt;false/&gt;
 &lt;key&gt;index&lt;/key&gt;
 &lt;integer&gt;3&lt;/integer&gt;
 &lt;key&gt;visible&lt;/key&gt;
 &lt;false/&gt;
 &lt;key&gt;width&lt;/key&gt;
 &lt;integer&gt;97&lt;/integer&gt;
 &lt;/dict&gt;</strong>

Bisogna cambiare:

<strong>&lt;key&gt;visible&lt;/key&gt;
 &lt;false/&gt;</strong>

In:

<strong>&lt;key&gt;visible&lt;/key&gt;
 &lt;true/&gt;</strong>

Dopodiche’ per applicare il cambiamento basta salvare il file e riavviare forzatamente il Finder (cmd+alt+esc).

L’uso più frequente che si fa di solito dell’history file e’ quando richiamiamo un comando precedente dentro la shell, cliccando sulla freccia in alto.

La lunghezza dell’elenco e’ variabile e puo’ essere allungata o diminuita.
Se utilizzato insieme a grep diventa molto utile per trovare comandi digitati in precedenza di cui non si ricordano che parti o porzioni…

Non esiste un vero e proprio manuale come negli altri comandi classici da terminale, perche’ history e’ un comando della shell e non di sistema.

Per sapere le opzioni non si digita infatti man history, bensì: help history (…continua)
I comandi eseguiti in shell vengono salvati nella home utente, nel file nascosto “.bash_history”.
Quando si richiama il messaggio precedente cliccando sulla freccia in alto sulla nostra tastiera viene richiamato l’ultimo comando salvato in quel file.

Alcuni esempi:

history 20 (elenco ultimi 20 comandi eseguiti)

history | grep porzionenomecomando (filtra i comandi eseguiti con un testo a scelta)

history -c (cancella tutta la history e l’elenco dei comandi)

!! (ripeti il comando precedente)

!n (ripeti il comando, dove “n” e’ il numero del comando nella lista history)

!string (ripeti il comando più recente, dove “string” sono le prime lettere del comando)

history > cmd.txt (salva tutto il contenuto di history nel file cmd.txt)

Un altro esempio per utilizzareil comando in congiunzione con grep per filtrarlo e con una stringa da cercare, formattato al meglio:

history | grep -i searchterm | less

Dove “searchterm” e’ ovviamente la porzione di comando che vi interessa ricercare.

Normalmente vengono salvati nel file nel file .bash_history gli ultimi 500 comandi eseguiti nella shell. Se si vuole incrementare questo valore fino a un massimo di 5000 digitando nel terminale:

histsize=number

Dove “number” e’ il numero massimo di comandi da memorizzare.

Il comando history si puo’ anche disabilitare per motivi di privacy o di sicurezza:

set +o history

e ovviamente riabilitare se disabilitato:

set -o history

Molto utile: se si vuole sapere anche quando i comandi sono stati eseguiti, e’ possibile ottenere oltre all’elenco dei comandi e al loro ID, anche la data e l’ora di esecuzione, aggiungendo il timestamp con questo comando:

export HISTTIMEFORMAT=’%d-%m-%Y %T ‘

Altra opzione molto utile: utilizzare control+R nella sessione terminale, per richiamare la modalita’ di ricerca interattiva nella history.
E’ possibile in pratica digitare una parte di un qualsiasi comando precedentemente eseguito e otterremo subito i risultati:

control+R si ottiene: (reverse-i-search)

Molto importante: se si usano uno o piu’ sessioni terminale aperte e’ bene sapere che tutte quante scriveranno i comandi nello stesso file, sovrascrivendo cosi’ eventuali modifiche precedenti.
Per far si che ogni sessione “aggiunga” al file esistente (append) i propri comandi e’ necessario impostare la variabile “histappend” (history append) in modo che ogni sessione terminale aggiunga e non sovrascriva il file .bash_history:

shopt -s histappend

E’ possibile anche cambiare nome al file nel quale vengono salvati i comandi in modo da non utilizzare il file .bash_history:

HISTFILE=percorso/nomefile

Io ci sarò, e voi?

Normalmente il Portachiavi viene attivato al login su OsX e la sua password coincide con quella dell’utente.
In questo modo l’utente non viene scomodato ogni volta che viene salvata una password e il portachiavi viene appunto sbloccato quando si logga nel proprio utente.

Se si apre l’applicazione (/Applicazioni/Utility/Accesso portachiavi) si puo’ notare come oltre al proprio portachiavi (che normalmente si chiama “Login” ed e’ in grassetto in quanto portachiavi di default) ci sono anche un portachiavi di sistema che puo’ contenere password che servono al sistema e una root di sistema che di solito contiene dei certificati.

La cosa interessante e’ che si puo’ usare il portachiavi in modo un po piu’ sicuro e utile, per esempio cambiando la password di default in modo da usarne una diversa rispetto al proprio account e rendendolo “mobile”, quindi mettendolo su una chiavetta USB o altro dispositivo (cosa che ci consente di portarci dietro in sicurezza ogni nostra password).
Vediamo come fare…

Possiamo spostare il portachiavi di login gia esistente, oppure farne uno nuovo.
Se uno ha gia la maggior parte delle password salvate nel portachiavi di login probabilmente e’ meglio spostare e rinominare quello, altrimenti per farne uno nuovo, basta aprire su “Accesso portachiavi” il menu’ “Archivio -> Nuovo portachiavi” e salvarlo sul disco esterno o dove vogliamo.
Se invece vogliamo spostarlo dobbiamo andare nella cartella “~/nomeutente/Library/Keychains” e spostare il file “login.keychain” nella sua nuova posizione, dopodiche’ dobbiamo modificare le impostazioni di Accesso portachiavi: “composizione -> elenco portachiavi (Alt+Cmd+L)” e da li’ si puo’ cancellare il riferimento al vecchio “login” e cliccare sul tasto “+” in basso per aggiungere il file che si trova nella nuova posizione.
Dopo aver fatto questo si puo’ rendere default (affinche’ i programmi salvino sempre sul nuovo portachiavi) il file selezionando nel menu di sinistra il keychain e da menu “Archivio” scegliere la voce “rendi portachiavi xxx di default” dove xxx sta per il nome del portachiavi che avete sul dispositivo esterno.

Per completare l’opera sarebbe utile cambiare la password di quel portachiavi, cosi’ da avere una sicurezza in piu’ nel caso la password del vostro utente sia troppo semplice o nel caso che il vostro utente sia usato da piu’ persone. Per farlo basta andare su “Composizione” e cliccare su “Modifica password per portachiavi…“.
In questo modo ogni volta che salverete una nuova password per un sito/forum/home banking o quando vorrete che Safari autocompleti con questi dati i siti relativi, bastera’ inserire la nuova password del portachiavi, ed il gioco e’ fatto.
Sempre nel menu’ “Composizione” di Accesso Portachiavi, potete modificare altre utili impostazioni nella voce “Modifica impostazioni per…“, per esempio potete assegnare una scadenza temporale personalizzata per proteggere il portachiavi (in modo che il sistema vi chieda di nuovo la password del portachiavi appunto).

Quali sono i vantaggi di un approccio simile?

- Innanzitutto si rende piu’ difficoltoso con una doppia password (una per il Login nel mac e una piu’ complessa per il vostro portachiavi), l’utilizzo di tutte le vostre password salvate, alcune delle quali possono essere veramente importanti (penso ai siti di Home Banking).
Con questa sicurezza poi potete usare il portachiavi per archiviare anche password di network, di aplicazioni o note protette o anche i dati della carta di credito.

- Secondariamente queste password possono seguirvi ovunque, senza essere legate necessariamente al vostro Mac (portatile o fisso che sia), avendo cura di salvarle su un dispositivo esterno, come per es. una piccolissima chiavettina USB.
A questo proposito ricordo anche che il formato del file NON puo’ essere sprotetto od osservato, neanche con un hex e/o text editor, e’ un file assolutamente sicuro, quindi non c’e’ pericolo se si smarrisce, l’importante ovviamente e’ averne un backup).

Reali svantaggi non ce ne sono, se no quello di dover collegare il dispositivo esterno ogni volta che si vuole accedere alle risorse presenti nel portachiavi.
Non c’e’ nessun pericolo se il file finisce in mani indesiderate il file e’ ben protetto.
C’e’ sempre la possibilita’ di smarrire la chiave USB, per questo consiglio un backup periodico del file del portachiavi anche online o su altra risorsa sempre raggiungibile.

Fedora/redhat: sudo yum install screen
Debian/Ubuntu: sudo apt-get install screen

L’utilizzo del programma e’ molto semplice, si tratta di lanciare una nuova sessione con screen e dargli un nome:

screen -S nomesessione

Dopodiche’ lanciare la procedura o lo script che si desidera. A quel punto possiamo tranquillamente chiudere il terminale, il processo avviato non si interrompera’. In seguito sara’ possibile riprendere quella sessione richiamandola con il comando:

screen -r nomesessione

Se non siamo sicuri del nome dato alla sessione e’ possibile listare le sessioni attive con il comando

screen -ls

Il risultato potrebbe essere il seguente:

There is a screen on:

21572.pippo (Detached)

1 Socket in /var/folders/Jf/Jfv6jbWaHOGEgCwxYDFMTk+++TM/-Tmp-/.screen.

Il comando screen -ls ci da’ come si puo’ vedere le seguenti informazioni:

21572      = il numero di PID del processo qualora si voglia killarlo per es.
pippo       = il nome della sessione screen attiva
detached = lo stato di screen
socket      = il percorso fisico nel quale viene eseguito il comando

Altre utilissime informazioni le trovate nel manuale allegato al comando (“man screen” da terminale) oppure ai seguenti link, per approfondire:

http://www.oreillynet.com/linux/cmd/cmd.csp?path=s/screen
http://www.rackaid.com/resources/linux-tutorials/general-tutorials/using-screen

Questi sistemi consensono un notevole risparmio di tempo se si vuole installare software originariamente pensato per linux che di norma su OsX va ricompilato da zero, passando appunto dalla compilazione del codice sorgente.
Un esempio (tra i piu’ semplici in verita’) lo abbiamo visto proprio per l’installazione di wget.

Fink Commander

I sistemi di pacchettizzazione grazie ai loro repository di binari, sono comodi proprio perche’ evitano ove possibile, questa trafila potendo accedere direttamente alla versione binaria del programma da installare e mantenendo una centralizzazione del software installato con la possibilita’ di disinstallarlo a piacere.

Porticus

Su Mac i sistemi piu’ popolari sono Fink (una ripropositione vera e propria di apt-get) e i MacPorts che invece implementa un sistema di pacchettizzazione che deriva dall’ambiente BSD.
Entrambi i sistemi possono essere utilizzati senza problemi sia su Leopard che su Snow Leopard.
Entrambi dispongono di una comoda interfaccia grafica di gestione che consente di installare al volo programmi.
Personalmente preferisco il sistema di MacPorts.

Per quanto riguarda i programmi di gestione ne segnalo due free e due a pagamento:

• Porticus (MacPorts, free)
• Portauthority (MacPorts, shareware)
• Fink Commander (Fink, free)
• Phynchronicity (Fink, shareware)

Per esempio, il comando:

wget http://www.ilmiosito.it

scarichera’ la home page del sito.
Altri utilizzi nel seguito dell’articolo:

Con il parametro “-r” si forzera’ wget a scaricare in modo ricorsivo anche i link collegati alla home page comprensivi di immagini e altri dati:

wget -r http://www.ilmiosito.it

wget permette anche di mascherare la propria identita’ fingendosi un browser qualsiasi nel caso servisse:

wget  -r -p -U Mozilla http://www.ilmiosito.it

Due opzioni molto importanti sono –wait e –limit-rate.
La prima serve per inserire una pausa tra un download e un altro e ogni tentativo di download, questo nel caso il sito riconoscesse il comportamento di wget come quello di un download manager e venisse percio’ blacklistato, col secondo comando si puo’ limitare il bitrate del download per evitare di saturare la banda in download.
Ad esempio (attenzione, si tratta di un solo rigo…):

wget –wait=20 –limit-rate=200K -r http://www.ilmiosito.it

Scarica tutti i files del sito in modo ricorsivo, fingendosi un browser Mozilla, aspettando 20 secondi tra un download e l’altro e limitando la banda a 200 Kilobit (KB/sec).
L’opzione -np (–no-parent) serve a confinare il download dei files presenti all’interno della stessa cartella…

Per automatizzare l’uso di wget e’ possibile inserire una serie di links di siti o files da scaricare, in un file di testo (separati ognuno da un “a capo”) e poi invocare il comando coi parametri adeguati per far si che wget scarichi l’intero elenco di files.
Il comando in oggetto e’:

wget -i lista.txt

I links all’interno del file di testo “lista.txt” verranno depositati all’interno della stessa directory.

wget puo’ inviare i parametri di username e password nel caso il sito o il servizio remoto lo richiedesse.
Un esempio: per chi possiede un account su rapidshare o altri servizi di download files che richiedono autorizzazione previo inserimento di username/password, e’ possibile inviare autenticazione all’interno dello stesso comando.
Per es.

wget –auth-no-challenge –user=USER –password=PASS -i lista.txt

In questo modo si otterra’ l’intera lista di files inviando per ognuno la corretta USER/PASS.
Se si aggiungera’ il parametro “&” alla fine del comando, sara’ possibile chiudere il terminale senza interrompere il download.
Oppure si puo’ utilizzar eil comando “screen”, che vedremo in un articolo a parte.

Ecco un altro comando un po piu’ complicato da analizzare:

wget -r -l1 -H -t1 -nd -N -np -A.mp3 -i ~/mp3blogs.txt

Ecco che significa:
-l1 (elle minuscola e 1) significa che si scaricheranno i files senza scendere oltre un livello di profondita’ nelle directory
-H significa che wget potra’ scaricare files che sono linkati fuori dal dominio indicato
- t1 (ti minuscola e 1) indica il numero di tentativi da fare se non trova un file
-np significa no-parent: non si dovra’ uscire fuori da quella cartella…
-A.mp3 e’ l’unione del comando -A (–accept=LIST) e dell’estensione desiderata, significa che il comando scarichera’ solo e soltanto files con estensione “.mp3″
-N significa che wget scarichera’ solo i files nuovi inserendo un timestamp sui files scaricati
-nd significa che wget non creera’ directory localmente per tener pulito il download

il resto serve per cercare il file mp3blogs.txt nella home utente, nel quale saranno elencati i siti da visitare
Alla fine il tutto serve per scaricare dai siti elencati nel file di testo, i files mp3 collegati alle pagine.

In particolare Google Calendar permette di crearsi una o piu’ agende personalizzate con la possibilita’ di condividere (in parte o del tutto) gli appuntamenti, con caratteristiche di assoluto rilievo come la possibilita’ di essere avvertiti con degli altert oltre che per email e popup, anche per cellulare, via SMS.

I calendari creati in google calendars possono essere scaricati in vari formati, compreso quello di iCal, per poi essere importati in altre applicazioni.
Ovviamente questa modalita’ e’ molto scomoda e obbliga a scaricare e sincronizzare manualmente i calendari con le proprie applicazioni.

Quello che molti non sanno e’ che Google supporta da un po di tempo, il protocollo CalDav introdotto da Apple nella versione 3.x di iCal, presente da Leopard (10.5.x) in poi.
Quindi e’ possibile ottenere una sincronizzazione tra iCal e Google Calendar (con qualche piccolo problemino e limitazione che vedremo), senza strumenti o programmi aggiuntivi.

Vediamo come fare: una volta creato un calendario in Google Cal, basta lanciare iCal

1. Selezionare Preferenze -> Account
2. Cliccare sul bottone “+” per aggiungere un nuovo account
3. Inserire una descrizione e le proprie credenziali per l’account di google
4. Sotto “Opzioni server” aggiungere il seguente indirizzo: “https://www.google.com/calendar/dav/INDIRIZZO@DOMINIO.COM/user“, rimpiazzare indirizzo@dominio.com con la propria casella di posta
5. Cliccare su “Aggiungi”

Se tutto e’ andato bene a questo punto nell’elenco dei calendari dovrebbe essere apparso anche il calendario di Google, con eventualmente gli eventi gia inseriti.
Quindi abbiamo iCal col suo calendario Google entrambi perfettamente sincronizzati.
Funziona anche per gli utenti di google apps che possono inserire quindi i propri indirizzi di posta personalizzati.

Adesso veniamo alle dolenti note, ci sono infatti alcuni problemi:

• Non e’ possibile condividere piu’ di un calendario. Il primo che create in google sara’ visibile in iCal, i successivi purtroppo no.
• Gli avvisi non possono essere sincronizzati
• Alcune operazioni generano errori (cambio del nome e/o colore del calendario in ical)

Chi volesse una migliore integrazione dovra’ necessariamente passare a prodotti commerciali di terze parti come Spanning Sync o Busy Sync

A questo scopo esiste una piccola applicazione gratuita “ufficiale” di google che si chiama Google Notifier e si inserisce come accessorio di menu’, appunto nella barra dei menu’.
Google Notifier permette di inserire un solo account di posta ma ha come opzione la possibilita’ di visualizzare anche i dati relativi all’agenda degli appuntamenti legata a quell’account.

Per i miei scopi pero’ non andava bene perche’ con google ho almeno 3 account e perche’ anche se uso l’agenda, non mi piace visualizzare le informazioni nella barra dei menu’.

Fino ad oggi quando ho scoperto Notify.

Notify e’ una applicazione del tutto gratuita come quella di google, ma che permette di inserire vari account gmail (o google apps, col proprio dominio quindi) e visualizza in modo semplice, immediato ma di grande efficacia, i vari account e il loro stato, si integra con le notifiche di Growl e mostra oltre al mittente e l’oggetto della mail, anche un piccolo estratto del corpo.

L’unico problema che mi sento di segnalare e’ che diversamente da Google Notifier, non e’ possibile inserire un account personalizzato di gmail col proprio dominio (Google Apps).

Enjoy.