Feeds:
Articoli
Commenti

Archive for gennaio 2008

Per cluster di application servers si intende una serie di istanze del server su cui girano le stesse risorse (le stesse Java web applications). Generalmente istanze diverse girano su Java Virtual Machine differenti e su macchine fisiche separate (sebbene appattenenti alla stessa sottorete) e questo introduce tutta una serie di problematiche peculiari al clustering. Il motivo per cui si ricorre a questa architettura è che in applicazioni di un certo peso la disponibilità del servizio (e le sue prestazioni) devono essere per quanto possibile garantite. In maniera molto semplice (e anche non del tutto precisa), un cluster di tre istanze è sempre in grado di svolgere il suo lavoro (garantire la disponibilità del sito all’utente finale) anche se una o due istanze dovessero incepparsi o crashare. Non solo, se mi accorgo che il sito e molto trafficato, posso sempre aggiungere un’istanza al cluster per ripartire il lavoro (scalabilità). Tutto questo inoltre avviene in maniera trasparente per l’utente finale che, anche se loggato ad un sito, non perderà la sessione, né si accorgerà di nessun cambiamento qualora alcune istanze del cluster dovessero avere dei problemi perché quelle rimaneni si faranno carico del lavoro.

Proseguendo il precedente post, vediamo come installare un architettura cluster su più server Linux fisicamente distinti. Suppongo si siano eseguite le istruzioni per installare Glassfish su un singolo server con supporto cluster abilitato come spiegato nel precedente articolo.

Se avete seguito le istruzioni, l’installazione di Glassfish che ne risulterà, sarà il nostro DAS (Domain Administration Server) vale a dire il nodo centrale di amministrazione delle varie istanze che comporranno il cluster.

È possibile installare una o più istanze all’interno di uno stesso cluster e residenti sulla stessa macchina fisica semplicemente leggendo la documentazione ufficiale e con qualche semplice e intuitiva operazione dalla interfaccia web di amministrazione. Caso più interessante è invece l’installazione di istanze su macchine fisiche separate. Partiamo col dire che le macchine devono appartenere alla stessa sottorete e nessun firewall deve impedire la comunicazione tra le varie istanze del cluster ospitate. Detto questo pensiamo di avere due macchine diciamo:

test1.acme.com

e

test2.acme.com

e supponiamo anche di aver già installato Glassfish con supporto cluster su test1.acme.com così come descritto nel precedente post. Logghiamoci a test1.acme.com con l’utente glassfish e avviamo il server:

asadmin start-domain domain1

Avviato il server, la console di amministrazione sarà disponibile all’indirizzo:

http://test1.acme.com:4848

ora dobbiamo creare un node agent per test1.acme.com

asadmin create-node-agent --host localhost --port 4848 <node-name>>

dove “nodename” è il nome da noi scelto per il nodo (per esempio test1-node). Senza scendere nei dettagli, dobbiamo avere un agent node su ogni singola macchian fisica che entrerà a far parte del cluster. Dalla console di amministrazione possiamo proseguire creando un nuovo cluster e una nuova istanza che assegneremo al cluster (e che avrà come node agent il nodo appena creato e per ora l’unico disponibile). Ora avviamo il node-agent appena creato:

asadmin start-node-agent --syncinstances=true <node-name>

Ora ci dobbiamo loggare sulla seconda macchina che ospiterà una o più istanze del nostro cluster: test2.acme.com. Su questo server dobbiamo installare Glassfish per cui rimando al post precedente alle sezioni “installare il JDK” e “installare ANT”. In questo caso però non abbiamo bisogno di un’installazione completa che creerebbe un secondo DAS ridondante, per cui invece di eseguire il comando

lib/ant/bin/ant -f setup-cluster.xml

useremo questo di seguito:

lib/ant/bin/ant -f setup-cluster.xml create-node-agent --nodeagent <node-agent-name> -Ddas.host="test1.acme.com"

Dove “host” è l’host su cui è installato il DAS (nel nostro caso test1.acme.com) e <node-agent-name> è il nome del nuovo nodo che stiamo per creare (per esempio test2-node). Ci deve essere un node agent per ogni macchina fisica distinta destinata ad ospitare istanze del cluster e ovviamente il nome del nodo deve essere unico entro un cluster.
Avviamo il nuovo node agent creato su test2:

asadmin start-node-agent --syncinstances=true <node-agent-name>

Logghiamoci alla admin console (o facciamo un refresh se siamo già loggati) e nella sezione dedicata ai nodi dovremmo poter essere in grado di vedere il nuovo nodo appena creato su test2.acme.com. Sempre attraverso l’interfaccia web di amministrazione possiamo creare nuove istanze appartenenti al cluster e assegnarle il nodo su test2. Questo vuol dire che l’istanza verrà creata e girerà su test2.acme.com.
Le istanze del cluster girano su porte particolari. Se, per esempio, creiamo due istanze su test2.acme.com e una su test1.acme.com avremo le varie istanze del server in ascolto su queste porte:

A questo punto di solito si prosegue creando un load balancer e integrando Glassfish con un web server tipo Apache. Avremo quindi un unico URL con cui invocare la nostra applicazione java e dietro le quinte il load balancer deciderà concretamente (e in maniera trasparente per l’utente) a quale istanza del cluster indirizzare la richiesta.

Un ultima nota dedicata più agli sviluppatori Java. Le librerie (file .jar) che dovrebbero essere condivise tra le farie applicazioni java deployate su uno stesso cluster (per esempio un driver jdbc per un database) dovrebbero essere piazzate qui:

<glassfish-home>/domains/domain1/config/<cluster-name>-config/lib

La documentazione completa sul clustering su Glassfish (e argomenti correlati) è disponibile qui:


http://glassfish.dev.java.net/nonav/javaee5/docs/SJSASEEHAAG.pdf

Read Full Post »

Glassfish e un application server che stà riscuotendo una crescente popolarità ed è giunto ad una fase di maturità tale da farne un ottimo candidato per applicazioni professionali in campo aziendale. Glassfish è free ed open source ed è sfornato dalla Sun (casa madre di Java). La versione 2 è un container pienamente conforme alle specifiche JEE 5, questo significa in altre parole che potete deployare EJB (anche la versione 3.0), JMS, ecc. e lo distingue da servlet container come Tomcat o Jetty. Un servlet container, anche conforme alle specifice Java, come suggerisce il nome, può essere di default solo utilizzato per deployare Servlet, JSP, ecc. ma non EJB appunto perché Tomcat non è e non è pensato per essere, un EJB container. Come corollario, mentre su Glassfish potete installare tutte le applicazioni Java che girano su Tomcat, non vale il viceversa: applicazioni Java che fanno uso di tecnologie quali EJB o JMS non possono essere deployate su Tomcat. Glassfish appartiene in sostanza alla stessa famiglia di JBoss e Geronimo (progetto Apache), con cui condivide la caratteristica di essere free e open source, ma anche, sul lato commerciale, di Weblogic (Bea) e WebSphere (IBM).
Ho installato Glassfish V2 sotto un server Linux RedHat e sul mio portatile su cui gira Ubuntu 7.10. La procedura è simile ma c’è qualche piccola differenza principalmente dovuta al fatto che mentre è normale disporre di un ambinete grafico su un sistema Linux per utente finale (caso di Ubuntu installato sul portatile) questo non è normalmente il caso su un server Linux su cui spesso ci si connette da remoto e si opera attraverso una shell.
In questa prima quida prenderò in considerazione l’installazione su un server Linux (nella fattispece RedHat) dove si possono presentare anche esigenze di clustering (argomento a mio avviso non del tutto chiaro nella documentazione ufficiale). L’installazione di Glassfish sul Ubuntu 7.10 sarà lasciata ad un prossimo post.

Per installare e configurare Glassfish V2 abbiamo bisogno di un JDK5 o un JDK6 presente sul server. Accertatevi di aver installato un JDK e non un semplice JRE (per la differenza vedi qui). Potete sempre verificare la versione di Java eventualmente già installata sul server con questo comando:

java –version

Ora creiamo un nuovo user (diciamo “glassfish”):

adduser glassfish

Se sul vostro server è già installato un JDK (e se combacia con una delle due versioni di cui abbiamo bisogno per Glassfish) allora potete saltare la prossima sezione.

Come installare il JDK

Fate il download del JDK (1.6) da qui (ovviamente per Linux):

http://java.sun.com/javase/downloads/index.jsp

o del JDK (1.5) da qui

http://java.sun.com/javase/downloads/index_jdk5.jsp

copiate il file scaricato (un .bin) in una directory di vostra scelta, diciamo

/opt

spostatevi nella directory

cd /opt

ed eseguite il file per installare il JDK

./jdk-1_5_0_14-linux-i586.bin

Ora dobbiamo settare la variabile d’ambiente JAVA_HOME e modificare la variabile d’ambiente PATH per includere gli eseguibili Java che abbiamo installato con il JDK. Se vogliamo rendere disponibili questi settaggi per tutti gli utenti del sistema dovremo editare il file

/etc/profile

Se invece vogliamo rendere disponibili questi nuovi settaggi solo per l’utente glassfish dovremmo solo editare il file:

/home/glassfish/.bash_profile

in entrambi i casi le linee extra che dobbiamo aggiungere al file sono le seguenti:

JAVA_HOME=/opt/jdk1.5.0_14
PATH=$JAVA_HOME/bin:$PATH
export PATH
export JAVA_HOME

Io consiglierei di modificare i settaggi per il singolo user glassfish che sembra essere un’approccio meno intrusivo e più prudente specie su un server su cui potrebbero girare altri applicativi di cui non siamo a conoscenza. Se decidete per queasta strategia loggatevi come glassfish e procedete con questo utente da ora in poi.

Installare ANT

ANT è un prerequisito per l’installazione di Glassfish. Lo script d’installazione controllera il filesystem alla ricerca del file:

/etc/ant.conf

Che nel vostro server sarà presente solo se ci dovesse essere una versione di ANT già installata. Il file in questione, se ci date una sbirciata dentro, non fa altro che settare la fariabile di ambiente ANT_HOME (per esempio qualcosa come ANT_HOME=/usr/share/ant) che Glassfish userà durante l’installazione. Tenete presente che Glassfish richiede una versione di ANT uguale o superiore alla 6.5. Se ANT non è già installato sul vostro sistema, potete scaricarlo da qua:

http://ant.apache.org/bindownload.cgi

Scompattate il file (per esempio in /opt) e la directory che otterrete sarà la vostra ANT_HOME. Non vi rimane che creare un file /etc/ant.conf che punti alla vostra ANT_HOME. Se un’installazione di ANT è già presente sul vostro sistema ma volete usare un’altra versione di ANT senza interferire con le applicazione già installate che potrebbero usare la versione installata, potete creare il vostro file ant.conf che punti alla vostra ANT_HOME e poi editare il file

/lib/ant/bin/ant

per farlo puntare al vostro ant.conf. Il file lib/ant/bin/ant non esiste ancora a questo punto perché dobbiamo ancora installare Glassfish, cosa che faremo nella prossima sezione. Il file ant.conf, in ogni caso, assomigliarà a qualcosa tipo:

# /etc/ant.conf
# Options for classic-ant
# ANT_HOME is the directory in which the jarfiles that are required by
# classic-ant are located.
ANT_HOME=/opt/ant

Installare Glassfish

Potete scaricare una copia di Glassfish (che si presente come un file .jar) da qua:

https://glassfish.dev.java.net/downloads/v2ur1-b09d.html

Una volta scaricato il file copiatelo nella directory

/opt

Spostatevi dentro questa directory:

cd /opt

ed eseguite il seguente comando:

java -Xmx256m -jar filename.jar

dove “filename” è il nome del file che avete scaricato (per esempio glassfish-installer-v2ur1-b09d-linux.jar). Spostatevi nella directory creata:

cd glassfish

e date i permessi di esecuzione agli script ANT inclusi in Glassfish:

chmod -R +x lib/ant/bin

Ora dobbiamo decidere se vogliamo installare un singolo server o un server con supporto per il clustering. Nel primo caso eseguiamo:

lib/ant/bin/ant -f setup.xml

nel secondo invece:

lib/ant/bin/ant -f setup-cluster.xml

Tenete presente che, se scegliete la prima via, è sempre possibile aggiungere il supporto cluster dalla console di amministrazione in modo semplice ed intuitivo. Spostatevi ora nella directory bin ed eseguite:

./asadmin start-domain domain1

Per far partire Glassfish mentre per arrestarlo potete usare:

./asadmin stop-domain domain1

Ora dovreste essere in grado di amministrare Glassfish da remoto attraverso una comoda ed elegante interfaccia web semplicemente collegandovi al seguente indirizzo:

http://host-name:4848

con username “admin” e password “adminadmin”. Trovate anche una nutrita documentazione (in inglese) sul sito a questo indirizzo:

https://glassfish.dev.java.net/javaee5/docs/DocsIndex.html

Read Full Post »

Problema: avete uno o più file video (.avi, .ogg, .mpeg, ecc.) e volete farne un normale DVD riproducibile in un qualsiasi lettore, magari aggiungendo un menù personalizzato che vi permetta di scorrere e selezionare i filmati da riprodurre.

Ricetta: DeVeDe è un programma che vi consente di risolvere il problema. A dire il vero supporta tutti I tipi di formati video supportati da Mplayer, che non sono pochi, non necessita di molte dipendenze installate (Mplayer, Mencoder, DVDAuthor, VCDImager, MKisofs, Python, PyGTK, PyGlade) ed è piuttosto intuitivo nell’utilizzo.

Per installare DeVeDe (faccio riferimento a Ubuntu 7.10) ci sono due possibilità: il programma è presente nei repository ufficiali nella versione 2.13 quindi se vogliamo installare questa versione basta usare Synaptec (System -> Administration -> Synaptic Manager) cercando per nome oppure da terminale con il comando:

sudo apt-get install devede

Purtroppo la versione 2.13 è piuttosto vecchiota e non permette la creazione di menu personalizzati per il vostro DVD. DeVeDe, nel momento in cui scrivo, è arrivato alla versione 3.16 che corregge multi bugs e implementa qualche funzionalità in più (tra cui appunto la possibilità di introdurre menu personalizzati). Per le ragioni esposte, ho deciso di scaricare la versione 3.16 da qui. Per Ubuntu è disponibile un file “Ubuntu 7.10 DEB ALL”, basta cliccarci sopra, scaricarlo e una volta scaricato il file, farci un doppio click sopra per avviare l’installazione.

Per le altre distribuzioni Linux basterà scaricare l’altro file in formato tar.bz2. Una volta scaricato sul vostro pc, scompattatelo con il commando:

tar xvjf devede-3.6.tar.bz2

nella directory scompattata dovreste trovare lo script per l’installazione. Spostatevi dentro la directory in questione, acquisite I privilege di root:

su

e poi lanciate lo script:

./install.sh

Utilizzare DeVeDe: una volta installato dovreste poter lanciare DeVeDe dal menu (in Ubuntu verrà creata una nuova voce sotto applicazioni Sound & video).
Appena lanciato, DeVeDe vi chiede cosa volete fare:

Choose disk

Nel nostro caso vogliamo creare un DVD quindi selezioniamo “Video DVD”. Abbiamo un titolo (Title1)

Schermata principale

a cui ovviamente dobbiamo associare un filmato. Clicchiamo “Add” sotto “Files” e selezioniamo il file video che costituirà il primo (o l’unico) filmato del DVD.

file properties

Poi selezioniamo il titolo e cliccando su “properties” modifichiamo il nome in qualcosa che rifletta il contenuto del nostro video.

title properties

Ripetiamo l’operazione se vogliamo aggiungere qualche altro video. Non ci rimane che creare il menù per il nostro DVD qundi selezioniamo “Add a menu with the titles” e poi “menu options” per selezionare il background del menu.

menue properties

Finito il tutto clicchiamo su “Preview menu” per visualizzare il risultato del nostro lavoro. DeVeDe offre una piccola serie di possibili background ma nulla ci vieta di usare immagini personalizzate.
Quando siamo soddisfatti possiamo partire con la creazione del vero e proprio DVD: selezioniamo “Create an ISO or BIN/CUE image…” e poi clicchiamo su “Forward” in basso a destra. Il tempo di creazione del file .iso potrebbe essere anche di alcune ore, molto dipende dalle dimensioni del DVD e dalle caratteristiche hardware del vostro PC. In ogni caso al termine del processo possiamo masterizzare il file .iso su DVD utilizzando il nostro programma preferito (brasero, k3b) oppure click con il tasto destro sul file e “Write to disk”.

Read Full Post »

IPCop è una distribuzione Linux gratuita studiata per essere un pratico firewall per reti casalinghe e uffici di piccole medie dimensioni. IPCop è facilmente installabile su vecchi pc che invece di essere rottamati e buttati con conseguente danno ambientale (i componenti del pc sono inquinanti) possono essere riciclati e trovare un nuovo valido impiego per migliorare la nostra sicurezza. Per alcuni il concetto di firewall coincide con quello di un programma che gira sul proprio pc: sia in ambiente Windows (Zone Alarm, BlackICE, Look’n’Stop, lo stesso firewall di Windows XP) che Linux (Iptables) ci sono vari esempi, tuttavia in questi casi si parla di “personal firewall” e non di “firewall” vero e proprio. IPCop appartiene alla seconda categoria: per alcuni sarà scontato ma giova ricordare che IPCop non è appunto un personal firewall ma a suo modo un vero e proprio sistema operativo minimale che necessita di una macchina dedicata e pensato solo per svolgere le funzioni di firewall e router. Una soluzione di questo tipo è più professionale e più sicura per varie ragioni su cui non mi soffermo e permette di impostare policy di sicurezza comuni a più utenti.

A dire il vero questo post non è un vero e proprio how-to che spiega passo passo l’installazione e configurazione di IPCop: in rete si trova molta documentazione a riguardo anche se prevalentemente in inglese. Diciamo piuttosto che ho speso qualche parola in più sul hardware (cosa serve, dove infilare i cavi, ecc.) e sul come mettere assieme i vari pezzi, più qualche altro appunto sull’installazione vera e propria teso principalmente a chiarire alcuni passaggi critici ed evitare alcuni errori che ho sperimentato di persona.
Io ho approfittato del fatto che l’azienda per cui lavoro ha deciso di mandare in pensione dei vecchi pc che ormai avevano fatto il loro dovere. In questo modo sono entrato in possesso di un Pentium 3 (1Ghz), 256Mb di ram e 20 Gb di hard disk (caratteristiche che, ad essere onesti, per IPCop sono anche troppo generose) e lettore cd rom indispensabile per l’installazione. Il primo passo consiste nell’adattare l’hardware alle nostre esigenze. In casa ci sono 5 laptop quindi il supporto wireless è obbligatorio. Ho deciso anche di installare una rete non wireless in modo che sia sempre possibile connettersi ad internet inserendo nel pc un semplice cavo ethernet.
Entriamo subito nella terminologia di IPCop che definisce diversi tipi di interfacce:

  • Un interfaccia RED (rossa): questa è l’interfaccia verso internet e verso il mondo esterno. In termini hardware è la scheda di rete ethernet che collegherà il pc su cui andremo ad installare IPCop al modem ADSL (che quindi deve avere una presa ethernet)
  • Un interfaccia GREEN (verde): è la rete protetta di tutti quei pc che si connetteranno a IPCop con un cavo ethernet (eventualmente attraverso un hub se più pc devono essere connessi in contemporanea). Da un punto di vista pratico, questa interfaccia consiste in una scheda ethernet che andremo ad installare sul pc su cui risiede IPCop e da cui partirà un cavo ethernet che si andrà direttamente a connettere ad un pc o a più pc attraverso un hub. Se avete un pc desktop, questa è l’interfaccia a cui lo collegherete.
  • Un interfaccia BLUE: questa è l’interfaccia opzionale per la rete wireless (sempre che ne abbiate bisogno). Anche in questo caso corrisponde ad una scheda ethernet da cui partirà il relativo cavo diretto ad un wireless access point (o wireless router).
  • Un interfaccia ORANGE (arancio): l’interfaccia opzionale dedicata a server (per esempio un web server). In questo post non prenderò in considerazione questa ipotesi, peraltro abbastanza inusuale per una rete casalinga.

struttura rete
Riepiloghiamo:

  1. dobbiamo avere un vecchio pc su cui installeremo IPCop. Almeno durante la fase d’installazione dobbiamo anche collegare ad esso un monitor e una tastiera. Quando avremo installato e testato il tutto, tastiera e monitor potranno essere rimossi.
  2. dobbiamo avere un modem connesso ad internet (farò riferimento in seguito ad un modem ADSL) con una presa ethernet
  3. se vogliamo allacciare e proteggere dietro il firewall anche una rete wireless, dobbiamo avere un wireless access point o un wireless router. In parole semplici, la differenza tra un access point e un router è che l’access point permette ad un solo computer alla volta di essere connesso alla rete wireless mentre il router gestisce anche accessi contemporanei e concorrenti. Se quindi avete, per esempio, più portatili che si vogliono connettere ad internet nello stesso momento, dovete optare per un wireless router.

Il passo successivo è quello di connettere assieme tutti questi pezzi. Sul vecchio computer dobbiamo avere quindi tre schede ethernet distinte.

  • una verrà utilizzata per connettere la macchina IPCop con il modem ADSL (interfaccia RED)
  • una per connettere la macchina IPCop con il router wireless (interfaccia BLUE)
  • una per connettere la macchina IPCop con un pc direttamente con un cavo ethernet o con più computers attraverso un hub (interfaccia GREEN)

Qui c’è un primo passo molto delicato. è piuttosto improbabile che il vecchio pc in questione abbia tre schede ethernet installate. Se siamo fortunati ne ha una, e se siamo molto fortunati ne ha una compatibile con IPCop. Già perchè IPCop supporta un buon numero di schede ethernet ma non tutte. Trovate una lista di tutte le schede supportate qui. Ed è qua che dobbiamo stare attenti. Se abbiamo una scheda non supportata, all’atto dell’installazione, IPCop la potrebbe tranquillamente riconoscere salvo poi non riuscire a connetterci a quella scheda e indurci atroci dubbi su probabili errori commessi nella configurazione (sperimentato sulla mia pelle). Morale della favola dobbiamo essere assolutamente sicuri che le schede ethernet montate (o che monteremo) sul pc siano nella lista e prestare particolare attenzione al modello: una scheda RealTek RTL-8139C+ non è uguale ad una scheda RealTek RTL-8139D. Il metodo migliore consiste nel controllare il nome del chipset direttamente sulla scheda.
Ricapitolando

  • dovete assicurarvi che sul vecchio pc ci siano gli slot e lo spazio per installare le schede ethenet.
  • dovete avere un totale di due schede ethernet se non volete installare un interfaccia blue per la rete wireless e tre schede nel caso la vogliate abilitare.
  • dovete accertarvi che tutte le schede ethernet siano compatibili con IPCop e presenti nella lista delle schede supportate.
  • dovete materialmente installare le schede ethernet aprendo il vostro pc e sporcandovi un pò le mani. Di solito è un’operazione abbastanza intuitiva.

Ora possiamo passare all’installazione di IPCop sulla macchina. Scarichiamo IPCop dal sito (http://ipcop.org/index.php)
poi masterizziamo su un cd l’immagine .iso scaricata. Accertatevi che sia possibile avviare il pc da cd rom (in caso contrario cambiate appropriatamente la sequenza di boot da bios), infilate il cd rom di IPCop e avviate il pc.

L’installazione è molto ben documentata sulla guida ufficiale disponibile qui. È in inglese ma è corredata da una serie di screenshot che rendono la procedura accessibile anche ai non anglofoni. L’unica cosa che forse potrebbe non essere chiara a chi è a digiuno di networking è la scelta degli ip per le varie interfaccie associate alle differenti schede di rete. Le tre (o due) schede di rete, devono essere associate a reti differenti.

Scelta indirizzo IP

Vale a dire che se scegliamo, per esempio per l’interfaccia GREEN, un IP tipo 192.168.1.1 con una network mask 255.255.255.0 allora tutti gli indirizzi IP da 192.168.1.1 a 192.168.1.255 apparterranno alla stessa rete. I vari pc che si connetteranno alla interfaccia GREEN riceveranno (via DHCP) un IP all’interno di questo range (per esempio, 192.168.1.2, 192.168.1.3, ecc.). Ne consegue anche che possiamo avere fino a 255 pc connessi alla nostra interfaccia.
Se decidiamo di installare una seconda interfaccia (per esempio la BLUE per la rete wireless) questa dovrà ovviamente avere un diverso indirizzo IP, per esempio 192.168.2.1, che denoti una differente rete per suo conto. La network mask 255.255.255.0 ci dice che i due indirizzi IP 192.168.1.1 (per la green) e 192.168.2.1 (per la blue), appartengono a due diverse reti. I portatili che si connetteranno alla rete wireless in questo modo riceveranno un indirizzo IP compreso tra 192.168.2.2 e 192.168.2.255 e apparterranno tutti alla stessa rete che però è una rete diversa da quella a cui appartengono tutti i pc connessi all’interfaccia green.
Per quanto riguarda i cavi ethernet di collegamento, dovremmo avere:

  • un cavo che parte dalla scheda di rete che rappresenta l’interfaccia RED e si connette al modem ADSL
  • un cavo che parte dalla scheda di rete che rappresenta l’interfaccia GREEN e si connette direttamente ad un PC o portatile oppure ad un hub a cui saranno poi connessi altri computers (ovviamente se non abbiamo nessun pc da connettere alla green possiamo anche evitare l’uso di questo cavo)
  • un cavo che parte dalla scheda di rete che rappresenta l’interfaccia BLUE i si connette al router wireless (opzionale ovviamente)

Prima di chiudere spendo ancora un paio di parole sul router wireless. Essendo IPCop anche un router va da sé che vi sarà una certa sovrapposizione di competenze tra i due, potrebbe non essere un problema ma personalmente ho preferito incaricare IPCop anche dell’assegnazione degli indirizzi IP ai vari portatili connessi via wireless. In sostanza il servizio DHCP viene gestito da IPCop mentre ho disabilitato il servizio sul router wireless che ora incarica IPCop per il DHCP. La configurazione dipende molto dal tipo (marca e modello) di router wireless utilizzato e mi è quindi difficile scendere nei dettagli. Vi posso dire però che il wireless router in questione dovrebbe supportare “DHCP passthrough”. In caso di problemi insormontabili si può comunque sempre lasciare al wireless router la responsabilità di gestire il DHCP.

Read Full Post »