La presente brevissima guida descrive in estrema sintesi l’installazione e configurazione di un server DHCP su di una macchina Linux Ubuntu.  Come dovrebbe essere noto il DHCP, ovvero Dynamic Host Configuration Protocol, è un protocollo di rete utilizzato per configurare in maniera dinamica, potremmo dire “al volo”,   le schede di rete al fine di minimizzare gli sforzi necessari per manutenere configurazioni di tipo statico. In soldoni, invece di definire manualmente l’indirizzo IP, la netmask, il gateway di default, DNS, ecc. ecc. necessari per consentire alla specifica macchina di “navigare”    in rete, demandiamo il tutto al server DHCP. E’ intuitivo riflettere sull’utilità di tale approccio soprattutto quando i dispositivi in questione sono di tipo mobile.

Partiamo come di consueto con l’installazione sul server, nel mio caso un Ubuntu 12.04.1 LTS, del pacchetto richiesto:

$sudo apt-get install isc-dhcp-server

Per chi avesse già installato in tempi precedenti un server DHCP c’è da considerare la possibilità di andare in confusione. Infatti, il pacchetto che utilizzavamo un po’ di tempo fa, ovvero dhcp3-server  è stato rinominato in isc-dhcp-server.  In realtà anche se dessimo il comando:

$sudo apt-get install dhcp3-server

il risultato dovrebbe essere lo stesso. Ciò è testimoniato dal fatto che in risposta al comando:

$ apt-cache search dhcp3-server

otteniamo:

isc-dhcp-server – ISC DHCP server for automatic IP address assignment
dhcp3-server – ISC DHCP server (transitional package)
isc-dhcp-server-ldap – DHCP server able to use LDAP as backend

In buona sostanza i due pacchetti sono la stessa cosa.

A voler fare i “precisini”, e chi mi conosce spesso mi mette in questa categoria, il prefisso “isc” nel nome del pacchetto fa riferimento all’ Internet Systems Consortium(ISC), un’organizzazione che sviluppa e manutiene  una varietà di software tra cui  BIND, INN ed appunto una implementazione del DHCP. Per comprendere l’importanza di tale organizzazione pensate che il suo sito web, www.isc.org, ha un page rank Google di 7 che è di tutto rispetto.

Nel caso in cui sul server fossero presenti più schede di rete è possibile “bindare”, cioè legare, ad una specifica eth del server il demone in questione. Tutto ciò è possibile grazie al file:

/etc/default/isc-dhcp-server

Il file di configurazione principale è /etc/dhcp/dhcpd.conf

Al solito, prima di metterci le mani sopra e modificarlo, è saggio farsi una copia di backup dello stesso:

sudo cp /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.conf_BAK

Dunque per la modifica si può procedere con:

sudo nano /etc/dhcp/dhcpd.conf

Di seguito una configurazione minimale ma funzionante del suddetto file:

# (configurazione minimale per lan interna )

ddns-update-style none;

option domain-name “example.org”;
option domain-name-servers ns1.example.org, ns2.example.org;

default-lease-time 600;
max-lease-time 7200;

option subnet-mask 255.255.255.0;
option broadcast-address 192.168.0.255;
option routers 192.168.0.1;

subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.130 192.168.0.254;
}

Per riavviare:

sudo service isc-dhcp-server restart

Nota finale:  per verificare i lease è possibile usare il comando:

sudo tail /var/lib/dhcp/dhcpd.leases

Hope this helps 😉

Carlo A. Mazzone

La prima volta che feci conoscenza con il pacchetto Usermin fu quando ero in cerca di un sistema per consentire agli utenti, gestiti tramite una macchina Linux, di poter cambiare la propria password senza costringerli all’uso della shell testuale tramite un brutale passwd.

Usermin, una interfaccia web molto simile a Webmin, consente questa e tante altre possibilità.

Infatti Usermin consente ad utenti non amministratori (non root) di macchine Unix like di eseguire operazioni che dovrebbero essere normalmente realizzate tramite il prompt della shell. La similarità con Webmin è dovuta al fatto che gli autori sono gli stessi per entrambi i pacchetti mentre al differenza sostanziale, come avreste dovuto già intuire, è data dal fatto che Webmin è indirizzato agli  utenti che si loggano come root, essendo amministratori del sistema, mentre Usermin è dedicato agli utenti normali.

Tra le varie possibilità messe a disposizione da Usermin al “normal user” loggato via web mi viene da citare l’interfaccia webmail, la possibilità di configurare il proprio  Procmail per la gestione del forwarding e dello spam, la gestione di database  MySQL e PostgreSQL e la modifica del file .htaccess.

Ovviamente l’amministratore può definire un controllo molto fine su quali di queste operazioni risultano disponibili all’utente in questione.

Dopo questo ampio preambolo credo proprio sia il caso di passare all’azione.

La procedura descritta è stata verifica su di una macchina Linux Ubuntu ed il modo migliore  che consiglio in tale contesto  per installare ed aggiornare Usermin è quello di usare APT (Advanced Packaging Tool).

La prima operazione è richiesta è dunque quella di modificare il file  /etc/apt/sources.list aggiungendo la riga seguente:

deb http://download.webmin.com/download/repository sarge contrib

Attenzione che questa riga è la stessa richiesta per Webmin per cui se quest’ultimo lo  si  è già installato non è necessario aggiungerla. Installare preventivamente Webmin è proprio quello che vivamente consiglio in quanto l’amministrazione di tutte le funzionalità di Usermin saranno gestite appunto tramite l’interfaccia web di Webmin in maniera del tutto naturale. L’alternativa consisterebbe nell’editing diretto dei file di  configurazione nella directory /etc/usermin.

Procediamo dunque con l’installazione di Usermin lanciando i seguenti comandi:

apt-get update
apt-get install usermin

Tutte le dipendenza richieste dovrebbero essere risolte in maniera automatica.

Se tutto sarà andato per il verso giusto sarà sufficiente loggarsi con la userid e la password di un qualsiasi utnte Unix all’URL seguente:

https://serverip:20000/

Dove 20000 è il numero di porta utilizzato da Usermin rispetto al numero 10000 utilizzato da Webmin.

A questo punto l’ultima cosa che che mi sento di segnalare è che per poter selezionare ed indicare quali tra i vari moduli di Usermin devono essere visibili  agli utenti è sufficiente accedere alla sezione “Avalilable Modules” accessibile dopo un clic sulla voce “Usermin Configuration” della sezione Webmin nella treeview di amministrazione.

Alla prossima.

Carlo A. Mazzone

Webmin è un utilissimo strumento di amministrazione per server Linux. Esso consente tramite un semplice accesso via web di configurare ed amministrare svariati servizi: apache, dns, dhcp  solo per citarne alcuni. Webmin consente inoltre  di gestire account e lavorare sul file system del server sul quale è installato. Ma anche questo è un elenco estremamente riduttivo delle sue possibilità. In definitiva in un solo ambiente è possibile avere sotto le proprie dita un intero sistema server.

Il presente scritto vuole essere una veloce guida alla sua installazione.

Dunque partiamo. La prima operazione da portare a termine è la modifica del file  /etc/apt/sources.list

Per farlo usate il vostro editor preferito; il mio, da un po’ di tempo a questa parte,  è “nano”. Quest’ultimo lo sto preferendo al vecchio “vi” essendo ormai disponibile di default in varie distribuzioni Linux. Ed a proposito di distribuzione la procedura qui descritta è stata provata su di una distro Linux Ubuntu server 12.04 64 bit.

Procediamo allora con:

$ sudo nano /etc/apt/sources.list

Il file in questione  è utilizzato dal gestore di pacchetti APT per contenere la lista delle “sorgenti” dalle quali il sistema può attingere i pacchetti stessi.

Andiamo dunque ad aggiungere al file in questione le seguenti due righe di testo:

deb http://download.webmin.com/download/repository sarge contrib
deb http://webmin.mirror.somersettechsolutions.co.uk/repository sarge contrib

Salviamo il file ed usciamo.

A questo punto è necessario  importare la chiave GPG per validare il pacchetto webmin. In caso contrario potreste ricevere durante l’installazione un errore come il seguente:
“Le seguenti firme non sono state verificate perché la chiave pubblica non è disponibile”

Lanciamo dunque i seguenti comandi:

$ wget http://www.webmin.com/jcameron-key.asc
$ sudo apt-key add jcameron-key.asc

Aggiorniamo dunque la source list:

$ sudo apt-get update

e finalmente possiamo procedere all’installazione di webmin:

$ sudo apt-get install webmin

E dunque ci siamo; per accedere al pannello di controllo è sufficiente raggiungere l’URL:

https://serverip:10000/

Di seguito una revisione di un articolo già pubblicato relativo alla versione Ubuntu 7.04.

Hope this helps.

Qualsiasi programmatore che abbia sviluppato in team con altri sviluppatori si sarà reso conto della necessità di condividere pezzi di codice con gli altri elementi del gruppo e delle difficoltà legate a tale condivisione. Fortunatamente esistono software appositamente progettati per consentire a differenti sviluppatori di lavorare sugli stessi progetti controllando le modifiche apportate ed evitando sovrascritture accidentali degli stessi frammenti di codice.

Oltre al classico “SourceSafe” prodotto dalla Microsoft ed agli strumenti messi a disposizione nell’ultima, e molto costosa, suite Microsoft Visual Studio Team Edition, ha preso piede in questi ultimi tempi un sistema gratuito e molto affidabile chiamato SubVersion. Tale software sembra stia soppiantando nei gusti dei sistemi un po’ di tutto il mondo un software analogo di nome CVS (Concurrent Versions System) dal quale SubVersion prende le mosse.

In questo articolo vediamo come installare la parte server di SubVersion su di una distribuzione Linux Ubuntu. Nello specifico il tutto è stato provato con la versione 11.10.

Si presuppone che sul sistema sia installato Apache 2.

Il pacchetto indispensabile per subversion è semplicemetne “subversion”

Per cui procediamo alla sua installazione utilizzando il comando apt-get:

$ sudo apt-get install subversion

Il comando provvederà ad installare i moduli necessari, SubVersion e SVN per Apache.

Il modulo SVN dovrebbe essere automaticamente abilitato dopo l’installazione. Se così non fosse è possibile utilizzare il comando “a2enmod”, uno script che abilita il modulo specificato, ad esempio, nel nostro caso:

$ sudo a2enmod dav_svn

Incidentalmente faccio notare che esiste un comando con funzione opposta, vale a dire per disabilitare un modulo: “a2dismod [nome modulo]”

CREAZIONE DEL REPOSITORY SVN

Installeremo il repository in /svn

Creiamo come prima cosa il gruppo ‘subversion’

$ sudo groupadd subversion

Aggiungiamo l’utente Apache, ovvero www-data, al gruppo subversion appena creato.

$ sudo usermod -G subversion www-data

Da notare come con il comando $ groups www-data sia possibile verificare il successo del comando precedente.

Passiamo ora alla creazione della cartelle fisiche sul file system per i repository:

$ sudo mkdir /home/svn

Spostiamoci nella cartella appena creata e creaiamo una ulteriore nuova cartella per il nostro primo progetto:

$ cd /home/svn

$ sudo mkdir tesseract

A questo punto passo alla creazione dle repository vero e proprio

$ sudo svnadmin create /home/svn/tesseract

Passiamo ora alla corretta impostazion dei permessi:

$ cd /home/svn

$ sudo chown -R www-data:subversion tesseract

Dove, con l’ultimo comando, impostiamo per la cartella ‘tesseract’ ed in maniera ricorsiva per tutte le sottocartelle come prorietrartio l’utente ‘www-data’ e come gruppo ‘subversion’

Ed infine:

$ sudo chmod -R g+rws tesseract

Per abilitare lettura e scrittura (rw) per il gruppo. Da notare il flag ‘s’. Questo, detto di norma setuid e’ necessario in quanto svnadmin deve creare i file durante operazioni tipo  commit.

CONFIGURARE L’ACCESSO A SVN

I repository di SVN possono essere gestiti tramite vari protocolli (file, http, https, svn+ssh, …). Sicuramente, il piu’ semplice è l’accesso via protocollo WebDAV (http://).

Per utilizzare questo protocollo è necessario configurare correttamente Apache. Si presuppone quindi l’installazione del pacchetto libapache2-svn:

$ sudo apt-get install libapache2-svn

Sarebbe possibile apportare le modifiche del caso al file /etc/apache2/mods-enabled/dav_svn.conf, tuttavia ciò non è possibile nel caso di configurazione sulla macchina server di hosts virtuali (vhosts).

E’ questa la tipologia di configurazione che personalemtne prediligo per cui suggerisco la modifica dei file in /etc/apache2/sites-available/*

La cartella “/etc/apache2/sites-available/” contiene un file di configurazione per ogni sito virtuale disponibile sulla macchina. Ne esiste uno predefinito, con nome “default”. E’ possibile modificare direttamente questo file con le opportune proprie “customizzazioni” e, nel caso sia necessario rendere disponibile un nuovo sito virtuale, è possibile duplicare il file in questione (utilizzando un nome a piacimento) e modificarlo seconda necessità.

La cartella in questione elenca, come dice il nome stesso, i siti disponibili sulla macchina. Essere disponibile non è sufficiente: bisogna anche che il sito sia abilitato. A tale scopo esiste una utility “a2ensite” che abilita il sito specificato. Ciò che tale utility realizza è la creazione di un link simbolico nella cartella /etc/apache2/sites-enabled/ che punta al file di configurazione del sito specificato. Un utility complementare, “a2dissite”, consente di disabilitare momentaneamente uno specifico sito senza costringere a cancellare o rinominare il file di configurazione.

La lettura dei file “enabled”, cioè abilitati, è resa possibile dalla direttiva:

“Include /etc/apache2/sites-enabled/”

presente nel file di configurazione principale di Apache.

Un tipico file di configurazione di un host sarà qualcosa del tipo:

<VirtualHost 192.168.1.1:80>

DocumentRoot /home/test/public_html

ServerName nomesito.tesseract.it

<Location /svntest>

DAV svn

SVNListParentPath on

SVNPath /home/test/repositories/test1

AuthType Basic

AuthName “Tesseract SVN test repository”

AuthUserFile /etc/apache2/users

AuthGroupFile /etc/apache2/groups

Require group developers

</Location>

</VirtualHost>

Da notare che dovranno essere presenti nel file di configurazione generale (apache2.conf) le seguenti righe:

NameVirtualHost 192.168.1.1:80

Dove 192.168.1.1 è l’IP della vostra macchina server

Include /etc/apache2/sites-enabled/

Per includere i file di configurazione degli host virtuali.

Per aggiornare il server al nuovo stato dare il comando:

sudo /etc/init.d/apache2 reload

APACHE E IL CONTROLLO DEGLI UTENTI

Per memorizzare le informazioni relative agli utenti e relative password per l’accesso ai contenuti è necessario creare un apposito file.

Tale file, per ovvie ragioni di sicurezza, deve essere registrato in una posizione tale da non essere accessibile da web. Esso, inoltre, non può essere editato direttamente a mano; le password, infatti, sono registrate in forma cifrata.

Il programma utilizzato per tale gestione è “htpasswd”:

Per iniziare è necessario creare il file in questione indicando un primo nuovo utente da inserire nel file stesso:

htpasswd -c /etc/apache2/users carlo

Il comando, con l’opzione -c, crea il file “users” nella directory /etc/apache2/ chiedendo la password da associare all’utente (nel nostro caso, l’utente “carlo”).

Il contenuto del file “users” dovrebbe essere ora simile al seguente:

——————————————-

carlo: xx1LtcDbOY4/K

——————————————-

dove si individua il primo campo contenente il nome utente ed il secondo campo, separato dal simbolo “:” contenente la password in forma cifrata.

Per inserire nuovi utenti all’interno del file riusiamo il comando htpasswd, omettendo ovviamente il flag -c in quanto il file è stato già creato; ad esempio, il comando:

——————————————-

htpasswd /etc/apache2/users giuseppe

——————————————-

aggiunge al file /etc/apache2/users l’utente “giuseppe”

Nella sezione “<Location></Location>” si utilizzano una serie di direttive per configurare i contenuti del repository ed i relativi accessi.

Vediamo in dettaglio le principali tra tali direttive:

SVNPath valorizzato nel nostr caso con il percorso “/home/test/repositories/test1” indica, appunto, il percorso fisico del repository. Tale percorso viene raggiunto tramite la redirezione impostata con “<Location /svntest>”.

In concreto l’URL http://nomeMacchina/svntest redirigerà il browser nel repository specificato dal valore impostato in “SVNPath”.

AuthName indica un nome per la zona, ovvero l’insieme di file e cartelle, per le quali si vuole controllare l’accesso. Esso rappresenta quello che in gergo tecnico viene definito “realm”. Un realm rappresenta, appunto, una zona del file system, generalmente una directory con eventuali sottodirectory che si intende proteggere. Una volta avvenuta l’autenticazione relativamente ad un certo realm questa viene conservata per la sessione corrente e sarà valida anche in una zona differente purchè avente lo stesso nome di realm.

AuthType indica il protocollo da utilizzarsi per l’autenticazione. Basic è quello predefinito.

AuthUserFile indica al server il nome e la posizione del file da contenente le credenziali di accesso.

Nel caso si volessero usare dei gruppi, anzichè gestire il singolo utente, è possibile utilizzare la direttiva AuthGroupFile

require indica gli utenti che possono avere accesso al realm specificato: Nel caso si voglia abilitare tutti gli utenti indicati nel file delle password è sufficiente valorizzare la direttiva require con il valore valid-user.

In caso contrario, nel caso si volesse autorizzare un sottoinsieme di utenti sarà sufficiente indicare i loro nomi dopo la direttiva stessa. Ad esempio:

require user carlo giuseppe

abilita all’accesso i soli utenti “carlo” e “giuseppe”

Nel caso di situazioni più complesse è possibile ricorrere alla gestione dei gruppi utilizzardo la direttiva AuthGroupFile e specificando il file contenente le informazioni sui gruppi stessi. Un file di tale tipo è organizzato in una sequenza di righe contenenti i nomi dei gruppi e, separati dal sibolo “:”, l’elenco degli utenti appartenenti allo specifico gruppo:

amministratori:carlo giuseppe

segreteria:anna isabella antonella

Per l’autenticazione si può poi procedere, ad esempio, come segue:

require group amministratori segreteria

require user carlotta

Tali direttive abilitano, dopo l’inserimento delle giuste credenziali, gli utenti dei gruppi “amministratori” e “segreteria” e l’utente “carlotta”, all’accesso alle risorse del realm.

Il client di accesso a SubVersion

Come client è possibile usare TortoiseSVN (http://tortoisesvn.net). Si tratta di un software gratuito per Windows che si integra perfettamente in “gestione risorse”.

Carlo Mazzone

www.tesseract.it

E’ possibile rendere più fine il controllo degli accessi sui repository di SVN che utilizzano Apache 2 rispetto alle impostazioni standard che prevedono che un utente possa semplicemente accedere in lettura e scrittura ad uno specifico repository nella sua globalità.

Ad esempio, potrebbe essere possibile, in caso di necessità, voler consentire ad un dato utente l’accesso in lettura ad un repository e l’accesso in lettura e scrittura su di un altro repository. Ancora, potrebbe essere richiesto, relativamente ad uno stesso repository di abilitare la lettura o la scrittura su specifiche sottodirectory.

Per ottenere questa maggiore granularità di controllo con SVN è possibile modificare la configurazione del file di Apache rimuovendo, se presente, la riga: 

AuthGroupFile /etc/apache2/groups

che gestisce i gruppi “classici” ed aggiungere la direttiva:          

Require valid-user

che richiederà la validazione per tutti gli utenti che tenteranno di accedere al repository. Ovviamente /etc/apache2/groups è un file  specifico di un esempio specifico e potrebbe avere un nome differente in base a scelte personali.    

A questo punto è possibile aggiungere una riga come la seguente:

AuthzSVNAccessFile /etc/apache2/svnaccessfile

che indica il file sul quale verranno impostati i permessi di accesso.

In definitiva avremo qualcosa del tipo:

<Location /miorepo>
DAV svn
SVNListParentPath on
SVNPath /percorso/miorepo
AuthType Basic
AuthName “SVN repository”
AuthUserFile /etc/apache2/users
Require valid-user
AuthzSVNAccessFile /etc/apache2/svnaccessfile
</Location>


Il file in questione, /etc/apache2/svnaccessfile,  è un file di testo come il seguente:

[groups]
readers = michele
devs = carlo, marco, luigi, simone, daniele

[miorepo:/]
@readers = r
@devs = rw

#abilitazione-disabilitazione selettiva sottodirectory
[miorepo:/trunk/ProgettoX/cartellaY/cartellaZ]
carlo = rw

La direttiva [groups]  indica, così come ci aspetteremmo, i gruppi di utenti. Tali utenti sono ovviamente quelli inseriti con la normale procedura nel file  /etc/apache2/users

Le successive direttive, banalmente individuabili grazie al fatto di essere identificate da parentesi quadre specificano qualcosa del tipo:

[repository:percorso]

dove “repository” è ovviamente il nome del repository che si intende gestire e percorso è la cartella del repository stesso. Ad esempio:

[miorepo:/]

indica nella sua totalità il repository  “miorepo”.
I permessi specifici andranno inseriti nelle righe di seguito come ad esempio:

[miorepo:/]
@readers = r
@devs = rw

Si intuisce che ogni riga di abilitazione è formata da due sezioni separate dal simbolo “=”. Nel caso specifico ho inserito i nomi dei gruppi definiti nella sezione apposita. Si intuisce anche che per indicare i gruppi si antepone al nome del gruppo il simbolo della chiocciolina.
I simboli “r” e “rw” stanno ovviamente, rispettivamente, per sola lettura e lettura scrittura. Oltre ai nomi dei gruppi è possibile indicare i nomi dei singoli utenti, così come il carattere jolly * ad indicare tutti gli utenti.

Come detto è possibile settare i permessi di lettura/scrittura anche su di una specifica sottodirectory come segue:

[miorepo:/trunk/ProgettoX/cartellaY/cartellaZ]
carlo = rw

dove /trunk/ProgettoX/cartellaY/cartellaZ è il percorso nel repository che si vuole gestire in maniera differente rispetto alle restanti sezioni.

Per chiudere segnalo il seguente link di sicuro interesse:
http://svnbook.red-bean.com/en/1.1/ch06s04.html

Carlo A. Mazzone

Realizzazione di un hotspot wireless basato su di una macchina Linux, scheda di rete PCI  ed il demone hostapd (di Carlo A. Mazzone)

La presente procedura consente la realizzazione di un hotspot wireless basato su di una macchina Linux ed il demone hostapd (http://w1.fi/hostapd/).

La macchina è dotata di due schede di rete: una prima eth standard ed una seconda scheda PCI wireless.

La scheda eth0 ha come default gateway l’IP del router di uscita su Internet ed nel nostro caso un IP di classe C sulla rete 192.168.0.0 mentre la scheda wireless avrà un indirizzo 192.168.1.1 e quindi su di un’altra classe C intranet.

Sarà compito del software iptables far ruotare i pacchetti dalla rete wireless verso quella wired e quindi verso Internet.

La prima fase prevede una classica installazione della versione server di Linux. La prova è stata effettuata con Ubuntu 10.10 server 32 bit.
E’ consigliabile l’installazione di un server ssh per la gestione da remoto della macchina in oggetto.

Passiamo ora alla configurazione dei parametri di rete. Se durante l’installazione sono già stati indicati i parametri di rete per la eth0 (IP, netmask, …) sarà necessario agire solo quelli relativi alla scheda wireless. Se invece durante l’installazione è stato individuato un server DHCP sarà necessario modificare a mano i parametri di rete nel classico file /etc/network/interfaces

Di seguito il file di configurazione rete

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
#iface eth0 inet dhcp
iface eth0 inet static
address 192.168.0.11
netmask 255.255.255.0
gateway 192.168.0.1


Per apportare le modifiche senza riavviare la macchina è sufficiente dare il comando:

sudo /etc/init.d/networking restart

Passiamo ora ad esaminare la situazione della scheda wireless. Alcuni comandi ci possono venire incontro per individuare le caratteristiche precise della scheda in oggetto. Ad esempio:

sudo lshw

oppure in maniera ancora più dettagliata relativamente alla componentistica di rete:
sudo lshw -C network

dal quale, nel nostro caso otteniamo:

description: Wireless interface
product: AR5413 802.11abg NIC
vendor: Atheros Communications Inc.

e su di una linea successiva la seguente dicitura:

capabilities: pm bus_master cap_list rom ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd autonegotiation

che, tra le altre cose, ci rassicura sul fatto che la nostra scheda supporta la modalità MASTER, ovvero la possibilità di funzionare come hotspot.

Un altro possibile comando che ci conforta sulla nostra dotazione hardware è:

sudo lspci
che produce il seguente output:

01:09.0 Ethernet controller: Atheros Communications Inc. AR5413 802.11abg NIC (rev 01)

Se avessimo utilizzato una scheda di tipo USB avremmo potuto usare il comando: lsusb

Il comando: sudo iwconfig
potrà chiarirci meglio la situazione della nostra scheda di rete. Per poterlo utilizzare deve essere stato precedentemente installato il pacchetto wireless-tools eventualmente così come segue:

sudo apt-get install wireless-tools

Nel nostro caso l’output di iwconfig sarà:

lo        no wireless extensions.
eth0      no wireless extensions.
wlan0     IEEE 802.11bg  ESSID:off/any
Mode:Managed  Access Point: Not-Associated   Tx-Power=0 dBm
Retry  long limit:7   RTS thr:off   Fragment thr:off
Encryption key:off
Power Management:off


Scopriamo così che il nome della scheda è wlan0 ed utilizziamo allora tale informazione per configurare la scheda stessa nel file /etc/network/interfaces con le seguente impostazioni:

# wireless settings
auto wlan0
iface wlan0 inet static
address 192.168.1.1
netmask 255.255.255.0
broadcast 192.168.1.255
network 192.168.1.0

ed a questo punto anche la scheda wireless dovrebbe essere pronta e funzionante.

E’ ora finalmente giunto il momento di installare il software necessario al funzionamneto della scheda come access point, ovvero il demone hostapd.

Diamo allora il comando: sudo apt-get install hostapd

Il demone hostapd richiede, al momento del lancio, un file di testo con la configurazione da utilizzare. Supponendo di voler utilizzare una protezione di tipo wpa chiamiamo il file di configurazione  wpa.conf (ma potrebbe chiamarsi pippo.conf e le cose non cambierebbero di un bit ;). Per la creazione del file possiamo utilizzare il comando touch.

Di seguito presento il file in questione.

File di configurazione per hostapd (protetto)

interface=wlan0
driver=nl80211
ssid=RETE_DI_PROVA
channel=1
hw_mode=g
auth_algs=3
wpa=3
wpa_passphrase=qui_va_la_password
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP CCMP
rsn_pairwise=CCMP

Volendo fare una veloce prova si può utilizzare un file con il contenuto seguente che abilita un access point senza protezione. Il tutto ovviamente da utilizzare per breve tempo per ragioni di sicurezza al solo scopo di provare velocemente una configurazione il più semplice possibile:

File di configurazione per hostapd (aperto)

interface=wlan0
driver=nl80211
ssid=Fly_OPEN
channel=1

Un altro passo indispensabile è ora quello di configurare un demone DHCP per assegnare un IP dinamico alle macchine che si collegheranno in modalità wireless al nostro access point. Procediamo allora con l’installazione del dhcp:

$sudo apt-get install dhcp3-server

Il file di configurazione è:

/etc/dhcp3/dhcpd.conf

Come di consueto conviene fare una copia di backup del file in questione:

$sudo cp dhcpd.conf dhcpd.conf_orig

Una possibile configurazione potrebbe essere la seguente:

subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.2 192.168.1.254;
option routers 192.168.1.1;
}

Per completare non resta che abilitare il routing con iptables. Le seguenti righe di configurazione possono essere inserite nel file rc.local per un avvio in automatico al boot della macchina.

#INIZIO rc.local
#Autorizzo l’interfaccia wlan0 ad accettare nuove connessioni e la istruisco a forwardarle verso l’esterno attraverso l’interfaccia eth0
iptables -A FORWARD –in-interface wlan0 –out-interface eth0 –source 192.168.0.0/255.255.255.0 -m state –state NEW -j ACCEPT
iptables -A FORWARD -m state –state ESTABLISHED -j ACCEPT
iptables -A FORWARD -m state –state RELATED -j ACCEPT

#NATTING per mascherare gli ip della lan
iptables -t nat -A POSTROUTING -j MASQUERADE

#Attivo il packet forwarding a livello kernel
echo 1 > /proc/sys/net/ipv4/ip_forward

#Lancio demone per access point
hostapd /etc/hostapd/wpa.conf

#FINE  rc.local

Di seguito alcuni riferimenti interessanti:
https://help.ubuntu.com/community/WifiDocs/MasterMode
http://w1.fi/hostapd/

Carlo A. Mazzone

L’aggiornamento (detto anche upgrade) di un software è importante; fondamentale quando il software in questione è un sistema operativo.
Di seguito riporto qualche indicazione per l’upgrade di Ubuntu relativamente alla versione server.

Come noto le versioni di Ubuntu vengano rilasciate ogni 6 mesi e riportano un numero di versione del tipo aa.mm
dove aa è l’anno di rilascio e mm il mese.
Ad esempio Ubuntu 9.04 è la versione rilasciata nell’aprile dell’anno 2009.
Di tanto in tanto vengono rilasciate delle patch per aggiornare la versione corrente.

Per aggiornare la propria versione corrente con tali ultime patch si può procedere come segue:

$sudo apt-get update (per aggiornare la sources.list per nuovi pacchetti)
$sudo apt-get upgrade

L’aggiornamento ad una nuova versione (release) è invece una cosa diversa. Questa, infatti, consiste nel passare letteralmente alla versione successiva.
Ad esempio dalla versione 8.10 alla 9.04. Oppure dalla 8.04 alla versione 9.04. E qui c’è però da fare una precisazione importante: è assolutamente sconsigliato aggiornare direttamente da una versione ad un’altra saltando gli aggiornamenti intermedi. Al contrario bisogna procedere aggiornandosi prima alle versioni immediatamente successive fino ad arrivare all’ultima disponibile oppure, in alternativa, effettuare una clean/fresh install (cioè una NUOVA installazione).

Canonical Ltd,  società fondata e gestita dall’imprenditore sudafricano Mark Shuttleworth, che è dietro al progetto Ubuntu, sa quanto può essere oneroso un aggiornamento continuo a nuove versioni di un sistema operativo e su questa considerazione rende disponibili delle specifiche versioni, denominate LTS (Long Time Support) che prevedono rilasci specifici di patch per un lungo periodo di tempo.

Attualmente, ad esempio, è disponibile per il download, oltre alla versione 9.04, la versione Ubuntu 8.04 LTS Server: rilasciata ad Aprile 2008 e supportata fino ad Aprile 2013.

Per aggiornare un sistema ad una nuova release conviene in ogni caso consultare il sito ufficiale di ubuntu (www.ubuntu.com) per seguire le istruzioni relative alla specifica versione. A titolo di esempio di seguito riporto la procedura, in questo caso semplice e minimale, da seguire per aggiornare ubuntu server dalla versione 8.10 alla versione 9.04: 

1. Installare update-manager-core: sudo apt-get install update-manager-core
2. Aprire il programma di aggiornamento: sudo do-release-upgrade
3. Seguire le istruzioni

Chiudo con una nota importante: per verificare la versione attualmente installata sul proprio sistema è possibile utilizzare il seguente comando:
$lsb_release -a

Carlo Mazzone

PS
Ovviamente Murphy con la sua legge è sempre in agguato per cui il consiglio è sempre quello di evitare aggiornamenti critici il venerdi (non vorrete mica passare l’intero fine settimana in azienda ?!)