Giusto un paio di giorni fa sono entrato in possesso di un bellissimo MacBook Pro. La mia attività principale, nell’utilizzo di un computer, è lo sviluppo di applicazioni web. Dopo aver installato tutto il necessario lato client (ah, il software libero… ma di questo parlerò più avanti) rimaneva tutta la parte “server” ovvero, nella fattispecie, PHP, MySQL e Apache.
Quando mi sono posto il problema della loro installazione, partivo da questi prerequisiti:
- su quei servizi ho bisogno di avere la massima flessibilità. Devo poter decidere la loro versione, le eventuali estensioni, dove mettere i dati, i permessi, i virtual host, eccetera eccetera
- il deploy delle nostre applicazioni avviene sempre su server linux, per cui mi piaceva continuare ad usare una Ubuntu come macchina di sviluppo per non avere sorpresine in fase di deploy
- questo OSX è puro e vergine e non ho nessuna voglia di incasinarlo con installazioni non… “standard”
- i vari MAMP, distribuzioni buffe di PHP e MySQL, sono roba per ragazzi (per non parlare di quello che arriva direttamente con OSX) :)
Detto questo rimaneva da scegliere il sistema di virtualizzazione ma ovviamente (costo, libertà, solite cose) la scelta è caduta su VirtualBox.
Installarci Ubuntu è stata una passeggiata di salute: avevo l’immagine ISO di una 9.10 su una pennetta USB e dopo aver creato una macchina virtuale ho montato la ISO all’interno del suo CD (senza neanche toglierla dalla chiavetta USB) e l’installazione è partita.
Anche la rete è stata vista subito e da Ubuntu ho installato tutto il necessario. Anche qui tutto allegro e banale.
A questo punto dovevo condividere una directory tra OSX e Ubuntu. L’idea appunto è quella di usare OSX per programmare, fare debug con i browser, magari un po’ di grafica e usare la macchina virtuale Ubuntu per servire l’applicazione via Apache. Avrei dunque condiviso la directory Sites di OSX con Ubuntu (che sarebbe poi diventata la base di tutti i miei virtual host di sviluppo).
Lato OSX è stato facile: si dichiara direttamente da VirtualBox che esiste uno “shared folder”, dandogli il path locale e un nome (questa configurazione è per singola macchina virtuale). Nel mio caso il nome è stato proprio “Sites”.
In Ubuntu occorre montare da qualche parte questa directory “esportata”. Non esistono però sistemi automagici per farlo, afaik. L’operazione è fattibile direttamente tramite mount, configurando /etc/fstab. Nel mio caso ho aggiunto la seguente riga al file (dopo aver creato la directory Sites nella mia home):
Sites /home/claudioc/Sites vboxsf uid=1000,gid=1000,exec 0 0
A questo punto un bel sudo mount Sites e siete a posto (successivi riavvii della macchina virtuale useranno l’fstab e non ci sarà bisogno di intervenire manualmente). Credo si possa fare anche in modo di che il mount sia permesso ad un utente qualsiasi usando il parametro “user” della riga di mount, ma non ho indagato oltre.
A questo punto si è presentato il primo problema: non è possibile creare link simbolici dalla macchina guest. In pratica, da Ubuntu, non si possono creare link simbolici su un file system montato con vboxsf. Non si può: è proprio un limite riconosciuto. È tuttavia possibile fare il contrario: ovvero creare un link simbolico in quella directory dal sistema ospite (nel mio caso OSX). In tal caso il link simbolico sarà visto, da Ubuntu, come un normale file (non so se questo fatto possa avere o meno conseguenze strane…). Per certe configurazioni questo rimane comunque uno show stopper. Speriamo che nelle versioni successive di vbox il limite sia superato.
Passo successivo era quello di testare il funzionamento di apache di Ubuntu da OSX, accedendo da un browser di OSX all’indirizzo IP del server embedded. Il funzionamento (me illuso) sembrava scontato… e invece niente da fare. Eccoci al secondo problema.
Non appena viene installata una macchina virtuale con supporto di rete, questa viene configurata per uscire in modalità NAT. Questo vuol dire che da vbox viene assegnato un IP privato all’interfaccia di rete della macchina virtuale la quale poi userà la macchina ospite come gateway. Il tutto viene configurato automaticamente e trasparentemente.
Un ifconfig di Ubuntu mi aveva rilevato l’IP del serverino Ubuntu (10.0.2.15). Da OSX riuscivo a fare ping a quell’indirizzo, ma qualsiasi altro servizio sembrava stranamente non attivo. Questo dettaglio (il ping…) è quello che mi ha fatto sprecare più tempo in assoluto. Si dà il caso, ho realizzato più tardi, che non era assolutamente possibile che io potessi fare ping al 10.0.2.15! Eppure succedeva. La cosa buffa infatti è che quell’indirizzo esisteva, sì, ma… nella rete di Fastweb. Non apparteneva dunque al mio server embedded, ma a chissà chi :)
Se il guest è in modalità NAT, l’host non può vedere i suoi servizi di rete. Period.
Un’altra possibilità sarebbe stata quella di configurare il sottosistema di rete di Ubuntu a lavorare in modalità “bridge”, ovvero fare in modo che usando OSX come ponte (appunto…) questa entrasse direttamente nella rete di OSX ricevendo dunque un IP dal dhcp server usato dallo stesso OSX. Per fare questo avrei dovuto associare l’interfaccia di rete di Ubuntu ad un’interfaccia di rete fisica di OSX (per esempio Airport). Ma così non andava bene: io volevo che le due macchine, quella fisica e quella virtuale, potessero colloquiare anche quando nessuna connessione esterna fosse attiva.
In pratica quello che mi serviva era la possibilità di poter uscire su internet con Ubuntu, quando una connessione fosse presente, ma comunque poter SEMPRE parlare con l’host OSX usando una sottorete privata.
Questa configurazione è possibile avendo a disposizione DUE schede di rete sulla Ubuntu (operazione da eseguire nei Settings della macchina virtuale, aggiungendo una scheda). La prima scheda è quella che farà parte della sottorete “privata” tra Ubuntu e OSX e va configurata in modalità Host-only. La seconda è quella che ci farà uscire su internet e possiamo configurarla a piacere su NAT o Bridge (Bridge, per me).
La cosa bella, una volta capito il funzionamento, è che il resto è tutto automatico. Fatta ripartire la macchina virtuale Ubuntu, avremo a disposizione due interfacce, una delle quali si troverà nella stessa sottorete di una nuova interfaccia di rete virtuale creata sul sistema host (OSX). Nel mio caso, su OSX, l’interfaccia si chiama vboxnet0.
Maggiori informazioni nel manuale di VirtualBox (pdf).

7 Responses to “Usare VirtualBox per sviluppare su OSX”
Ecco, parliamone ;-)
Sbaglio o la licenza di Virtual Box non prevede uso commerciale, e le licenze commerciali vengono vendute a costi improponibili per un libero professionista?
flod, la VirtualBox OSE è GPL. http://www.virtualbox.org/wiki/Editions. Io non sto (al momento) usando la OSE, perché prima di tutto dovevo verificare se questo giochino che qui spiego avrebbe funzionato. Comunque del supporto USB non me ne frega nulla e posso passare alla OSE (una volta capito come installarlo su OSX).
Perdona il basso livello del commento, io che non sto mica tanto bene avrei fatto una VPN tra Mac e la macchina virtuale con tinc. Ci vigliono circa cinque minuti e poi scala bene all’aumentare delle macchine virtuali.
Miki, non mi è neanche venuto in mente :) Se scrivi un articolo sugli step necessari per farlo lo provo subito :)
Ecco, VirtualBox OSE me l’ero persa :-)
Per il momento su Mac sono ancora su Parallels 4 per le macchine virtuali, anche se in realtà le uso pochissimo.
Cinque minuti? Ti dico solo che ci sto diventando matto da almeno 18 ore! :-)
Ok, la VPN non si può fare. La tua soluzione è LA soluzione.
Additional comments powered by BackType