Ricerche IT

Uno dei possibili utilizzi dell’Asus eeepc (il nuovo subnotebook di Asus con schermo da 7"), è quello di avere un pratico gingillo da portare sempre con sé e da utilizzare, se necessario, per brevi operazioni di amministrazione su server Linux (tramite ssh) o su server Windows, connettendosi con rdesktop su quei server Windows Server 2003 su cui è abilitato Remote Desktop.

Rdesktop è un’utilità già presente sull’installazione predefinita dell’eeepc, che consente appunto di connettersi ad un qualsiasi computer Windows con attivo il servizio RDP; la particolarità di rdesktop presente su eeepc è che… non funziona. Per essere più precisi, rdesktop non ha alcun problema in sé, ma se lanciamo dal terminale il comando:

$ rdesktop -a 16 -f nomeserver

cercando di connetterci ad un server Windows Server 2003, ci viene presentata la schermata di login dove, se inseriamo nome utente e password, ci butta fuori dando un errore "segmentation fault" nella finestra del terminale.

La ragione di quest’errore, è che, per impostazione predefinita, X.org montato sull’eeepc funziona con una profondità di colore di 16 bit, per cui bisogna modificare quest’impostazione lanciando da terminale il comando:

$ sudo kwrite /etc/X11/xorg.conf

e andando a modificare il valore della voce "DefaultDepth", portandolo da 16 a 24. Salvare il file modificato, quindi riavviare X, ad esempio con la combinazione di tasti (brutale ma veloce) CTRL+ALT+BACKSPACE, e, da una finestra di terminale, dare di nuovo il comando:

$ rdesktop -a 16 -f nomeserver

quindi immettere nome utente e password, ed amministrare il proprio server Windows Server 2003 alla risoluzione di 800×480 pixel, non comodissima ma utilizzabile per periodi non troppo lunghi.

Una macchina Linux prende l’ora di sistema dall’orologio hardware del PC, per cui, se vogliamo avere l’ora corretta sul nostro calcolatore, è necessario che anche l’ora impostata nel BIOS sia corretta. In realtà però, ciò potrebbe non essere sufficiente, in quanto Linux considera anche il fuso orario impostato durante l’installazione del sistema operativo, quindi potremmo trovarci nella situazione in cui l’orario è avanti o indietro di qualche ora rispetto all’orario corrente. In questo caso, avendo un collegamento ad Internet, la cosa migliore da fare è sincronizzare l’ora del proprio sistema con un server dedicato allo scopo utilizzando il protocollo NTP. Per compiere questa operazione, dobbiamo essere loggati come root, in quanto solamente il superutente ha la facoltà di cambiare l’ora del sistema, ma prima dobbiamo installare il pacchetto ntpdate, se non installato, tramite il comando (su Debian e derivate):

# apt-get install ntpdate

Ora possiamo lanciare il comando che ci permette di sincronizzare l’ora del sistema con il server NTP time.ien.it

# ntpdate time.ien.it

Ora il nostro sistema è sincronizzato col server NTP, quindi, a questo punto, non ci rimane che schedulare il comando tramite cron per permetterci di mantenere sincronizzata nel tempo la nostra macchina Linux, e, se vogliamo, possiamo pensare anche di inserire il comando appena descritto in uno script di avvio.

In una rete locale con un server Linux e n client Windows "recenti" (quindi da Windows 2000 in poi), per far sì che le comunicazioni di rete avvengano in modo efficiente, è necessario avere un server DNS che sia in grado di risolvere i nomi host dei vari PC in rete, nonostante in linea teorica sia possibile utilizzare Samba come server WINS, che svolge grosso modo le stesse funzioni di un server DNS anche se ad un livello diverso. Siccome però, come detto precedentemente, lo strumento principe di risoluzione dei nomi host in ambiente Windows è DNS, occorre utilizzare un’architettura di rete con almeno un server DNS in grado di svolgere questo compito in rete locale. Linux risponde benissimo a quest’esigenza col pacchetto Bind, che è appunto il server DNS più utilizzato in ambiente Linux. Il problema però è che se abbiamo una rete abbastanza estesa e con cambi frequenti, dovremmo aggiornare a mano i record A e PTR del server DNS, cosa alquanto scomoda per ovvi motivi, senza considerare che un inserimento manuale si presta benissimo ad errori di digitazione.

Per ovviare a questo problema, è bene far lavorare Bind in stretto contatto con un server DHCP (dhcp3 su Linux), il quale assegnerà dinamicamente la configurazione IP ai vari host, e contestualmente aggiornerà dinamicamente i record DNS su Bind, in modo che l’intervento manuale dell’amministratore di sistema sia ridotto al minimo. Dulcis in fundo, il server DNS sarà utilizzato anche per risolvere i nomi di dominio Internet, impostando uno o più forwarders da interrogare se un dominio non è stato definito sul server DNS locale.

Il primo passo per organizzare questa architettura di rete è quello di installare Bind9 sul server Linux (la solita Debian Etch) e le relative utilità, col comando:

# apt-get install bind9 dnsutils

A questo punto va configurato Bind in modo che possa risolvere i nomi host per il dominio che andremo a creare. Il primo passo, consiste nel dire al server Linux che la risoluzione dei nomi dev’essere delegata a sé stesso, editando opportunamente il file /etc/resolv.conf. Successivamente, bisogna modificare il file /etc/bind/named.conf, che è il file principale di configurazione di Bind, il quale indica dove sono posizionati i file in cui sono definite le zone corrispondenti ai vari domini che si vogliono configurare. Ipotizziamo quindi di avere un dominio test.lan sulla rete 192.168.1.0: dovremo configurare due file di zona, uno chiamato /etc/bind/db.test ed uno chiamato /etc/bind/db.192.168.1, che rappresenta il file in cui inserire i record PTR (quelli di ricerca inversa). Di seguito vediamo come impostare il file /etc/resolv.conf, dopodiché vedremo il contenuto del file di configurazione generico di Bind9 /etc/bind/named.conf, ed infine esamineremo i file di zona /etc/bind/db.test e /etc/bind/db.192.168.1:

/etc/resolv.conf

search casa.lan
nameserver 127.0.0.1

/etc/bind/named.conf

include "/etc/bind/named.conf.options";

zone "1.168.192.in-addr.arpa" {
        type master;
        file "/etc/bind/db.192.168.1";
};

/etc/bind/db.test

$TTL 86400      ; 1 day
test.lan.       IN SOA  ns1.test.lan. hostmaster.test.lan. (
                                2007081501 ; serial
                                86400      ; refresh (1 giorno)
                                28800      ; retry (8 ore)
                                604800     ; expire (1 settimana)
                                86400      ; minimum (1 giorno)
                                );
                IN      NS      ns1.test.lan.
;
ns1             IN      A       192.168.1.1
client          IN      A       192.168.1.3

/etc/bind/db.192.168.1

;
; BIND reverse data file for local loopback interface
;
$TTL    604800
@       IN      SOA     test.lan.       hostmaster.test.lan. (
                                2007081501   ; serial
                                604800       ; refresh
                                86400        ; retry
                                2419200      ; expire
                                604800       ; negative cache ttl
                                );
@       IN      NS      ns1.test.lan.
1       IN      PTR     ns1.test.lan.
3       IN      PTR     client.test.lan.

Fatta la configurazione, bisogna riavviare il demone bind9:

# /etc/init.d/bind9 restart

Ora il server DNS può risolvere i nomi host per il dominio test.lan presente sulla rete LAN, a condizione che gli IP indicati nel file di configurazione non cambino (da tenere presente che i valori indicati sono puramente indicativi); ciò implica che la nostra rete deve essere configurata con indirizzi IP statici, condizione accettabile se i PC non superano le 10 unità, altrimenti si deve considerare l’utilizzo di un server DHCP. Altra cosa da considerare, è che in questa situazione, Bind non riesce a risolvere i nomi di dominio Internet; per ovviare al problema, bisogna indicare a Bind uno o più server DNS pubblici che possano soddisfare le richieste che il server Linux fa per conto dei client, editando opportunamente il file /etc/bind/named.conf.options aggiungendo queste righe:

forwarders {
151.99.125.2;
151.99.250.2;
};

In questo modo i client potranno tranquillamente risolvere sia i nomi host in LAN sia i nomi di dominio Internet.

A questo punto prendiamo in considerazione l’ipotesi di necessitare dello stesso tipo di configurazione, ma per una rete locale di 20 (o più) host: in questo contesto, non è saggio mantenere un indirizzamento di rete con IP fissi, è sicuramente più indicato utilizzare un indirizzamento dinamico, servizio fornito da un server DHCP. Nella situazione indicata in precedenza però, i file di zona del dominio test.lan dovranno essere editati ogniqualvolta cambia l’assegnazione dell’indirizzo IP ad un host, per cui va a farsi benedire la comodità dell’utilizzo di un server DHCP; è evidente quindi che la situazione ideale consiste nell’assegnazione di indirizzi IP dinamici agli host e nel contestuale aggiornamento dinamico della corrispondenza indirizzo IP -> nome host. Per fortuna, in Linux ciò è possibile, poiché sarà il server DHCP, opportunamente configurato, ad effettuare gli aggiornamenti dinamici sul server DNS, il quale dev’essere configurato per accettare gli aggiornamenti inviati dal server DHCP.

Il primo passaggio della messa in opera della configurazione appena esaminata consiste nell’installazione ed attivazione del server DHCP, senza per il momento prendere in esame l’aggiornamento dinamico del server DNS; per installare il pacchetto dhcp3, utilizzare il solito apt:

# apt-get install dhcp3-common dhcp3-server

quindi, fare una copia di salvataggio del file di configurazione di esempio, crearne uno nuovo vuoto ed editarlo:

# mv /etc/dhcp3/dhcpd.conf /etc/dhcp3/dhcpd.old
# touch /etc/dhcpd3/dhcpd.conf
# nano /etc/dhcp3/dhcpd.conf

Ora, aggiungere un ambito DHCP con le opzioni del caso che ci permetta di distribuire i parametri della configurazione TCP/IP ai client della LAN, operazioni che si traducono nel seguente contenuto del file dhcpd.conf:

server-identifier 192.168.1.1;
ignore client-updates;

subnet 192.168.1.0 netmask 255.255.255.0
        {
        range 192.168.1.100 192.168.1.150;
        option subnet-mask 255.255.255.0;
        default-lease-time 604800;
        max-lease-time 2592000;
        option broadcast-address 192.168.1.255;
        option routers 192.168.1.254;
        option domain-name-servers 192.168.1.1;
        option domain-name "test.lan";
        option netbios-name-servers 192.168.1.1;
        option netbios-node-type 8;
        }

A questo punto, far partire (o ripartire) il demone dhcp3-server per attivare la configurazione:

# /etc/init.d/dhcp3-server start

Giunti fin qui, rimangono da configurare gli aggiornamenti dinamici del server DNS. In questo caso, come già esposto, sarà il server DHCP ad aggiornare dinamicamente il server DNS, al quale dovremo dire che sono consentiti gli aggiornamenti dinamici solamente da parte degli host coinvolti nel processo. In questo caso, ipotizzando che DNS e DHCP siano sulla stessa macchina, abiliteremo solamente localhost all’aggiornamento dinamico del server DNS, e come ulteriore misura di sicurezza, specificheremo che l’aggiornamento delle zone coinvolte avverrà solamente utilizzando una chiave segreta che viene creata automaticamente all’installazione di Bind ed il cui nome file è /etc/bind/rndc.key. Il primo passaggio consiste nel modificare il file /etc/bind/named.conf per indicare che il server DNS accetta aggiornamenti dinamici solamente da localhost utilizzando la chiave segreta:

include "/etc/bind/rndc.key";

controls {
        inet 127.0.0.1 allow {localhost; } keys { "rndc-key"; };
};

Un’ulteriore modifica da fare al file /etc/bind/named.conf è relativa alle zone create in precedenza, poiché anche in esse è necessario indicare che è possibile l’aggiornamento solamente tramite l’utilizzo della chiave segreta:

zone "test.lan" {
        type master;
        file "/etc/bind/db.test";
        allow-update { key rndc-key; };
};

zone "1.168.192.in-addr.arpa" {
        type master;
        file "/etc/bind/db.192.168.1";
        allow-update { key rndc-key; };
};

Fatto questo, far ripartire il demone bind9. Ora, rimane da configurare il server DHCP, il quale sarà incaricato di effettuare gli aggiornamenti sul server DNS, e che quindi dovrà obbligatoriamente "autenticarsi" su Bind utilizzando la chiave segreta /etc/bind/rndc.key. Ciò si traduce nell’aggiunta delle seguenti opzioni nel file di configurazione /etc/dhcp3/dhcpd.conf:

ddns-update-style interim;
ddns-domainname "test.lan.";
ddns-rev-domainname "in-addr.arpa.";
include "/etc/bind/rndc.key";
authoritative;

zone 1.168.192.in-addr.arpa. {
        primary 192.168.1.29;
        key rndc-key;
        }

L’ultimo passaggio consiste nel rendere la directory /etc/bind scrivibile anche per l’utente bind, in modo tale che Bind possa creare i file di zona con estensione .jnl che contengono i record DNS generati dinamicamente tramite l’aggiornamento di Bind da parte del server DHCP:

# chmod 775 /etc/bind

Ora, un riavvio del demone dhcp3-server completerà l’opera, ed avremo una rete con i PC che prendono la configurazione IP da un server DHCP, il quale aggiorna dinamicamente il server DNS in modo tale che tutte le operazioni di risoluzione dei nomi host avvengano correttamente sull’intera rete locale. Il vantaggio di questa soluzione è l’elevata automatizzazione dei processi descritti, che comporta un intervento dell’amministratore di sistema che si limita alla configurazione iniziale ed alla normale manutenzione del server, senza dover svolgere noiosi, inutili e ripetitivi aggiornamenti manuali.

Aggiornamento: ringrazio Croccobiscotto per avermi segnalato tramite un suo articolo una mia dimenticanza che riguarda l’aggiunta della direttiva "authoritative;" alla configurazione del server DHCP, la quale, da quel che ho letto, va indicata se il server DHCP è quello "ufficiale" della rete locale. Devo dire che al momento ho in "produzione" un solo server DHCP con Linux su cui avevo inserito a suo tempo la direttiva, facendo qualche prova a casa non ho inserito la direttiva ed il server DHCP e gli aggiornamenti dinamici funzionavano comunque bene, certo è che le prove che posso fare a casa non sono molto significative.

Se si dispone di uno o più indirizzi IP pubblici statici con la propria connessione ad Internet, è abbastanza consueto che si voglia approfittarne per pubblicare un proprio server Web, un proprio server di posta, o altri servizi che necessitano di un IP pubblico statico, come una VPN. In questi casi, una buona politica di sicurezza è far passare tutto il traffico diretto verso uno di questi servizi pubblicati attraverso un firewall, che poi ridirigerà le richieste verso un server posto verso la rete "interna", che prenderà il nome di DMZ (zona demilitarizzata), una rete "intermedia" che è posta tra la rete pubblica (Internet) e la rete locale e su cui saranno posti solamente quei server che devono pubblicare servizi verso Internet, oltre ad un eventuale firewall che connetta LAN e DMZ.

Per fare in modo che il firewall "esterno" rediriga le richieste verso il/i server in DMZ, esiste un meccanismo chiamato "port forwarding", che dal firewall esterno riceve la comunicazione in ingresso su una determinata porta con un determinato protocollo di trasporto, e la "rimbalza" verso il server in DMZ con lo stesso protocollo di trasporto e su una porta che spesso è identica a quella della richiesta originaria, ma che può anche cambiare.

Se si utilizza un firewall Linux, il port forwarding è impostato tramite iptables, che oltre a fungere da firewall è perfettamente in grado di gestire anche la redirezione del traffico. In particolare, si prenda in esame una configurazione di iptables come quella mostrata qui, dove la cosa di cui tenere conto quando si configura il port forwarding, è che il comportamento predefinito relativo alla catena di FORWARD consiste nel blocco del traffico, per cui, oltre all’istruzione necessaria per indicare la redirezione vera e propria, è necessario impostare una regola di FORWARD  che abilita il traffico dall’interfaccia esterna (eth1) alla DMZ (la cui interfaccia di rete definita sul firewall Linux è eth0) solamente per il tipo di richiesta necessaria. Si consideri la pubblicazione di un server Web che risponde alla canonica porta 80, e la cui interfaccia di rete in DMZ ha indirizzo IP 192.168.20.1; questa esigenza viene soddisfatta scrivendo queste due righe di configurazione di iptables:

iptables -A FORWARD -i eth1 -o eth0 -p tcp –dport 80 -j ACCEPT
iptables -A PREROUTING -t nat -p tcp -i eth1 –dport 80 -j DNAT –to 192.168.20.1:80

A questo punto, se dall’esterno si digita in un browser l’indirizzo IP (o il corrispondente nome host) dell’interfaccia eth1, si vedrà il sito pubblicato tramite il port forwarding di iptables.

Può capitare, avendo un sito web composto da diverse directory e/o sottodirectory, di dover consentire l’accesso ad una particolare directory solamente ad alcuni utenti. Avendo un web server come Apache su piattaforma Linux (le informazioni indicate di seguito le ho provate su una Debian Etch), è possibile utilizzare un file .htaccess, da creare nella directory a cui si vuole limitare l’accesso, per raggiungere lo scopo prefisso.

Il primo passo consiste appunto nella creazione del file .htaccess e nell’assegnazione dei corretti permessi al file stesso:

# touch /var/www/sito/dirProtetta/.htaccess
# chmod 644 /var/www/sito/dirProtetta/.htaccess

Fatto questo, editare il file .htaccess col proprio editor preferito inserendo queste righe:

AuthName "Area protetta"
AuthType Basic
AuthUserFile /var/www/sito/dirProtetta/.htpasswd
<Limit GET PUT POST>
Require valid-user
</Limit>

L’istruzione nella prima riga rappresenta il titolo della finestra di richiesta autenticazione, la seconda riga indica invece il tipo di autenticazione alla directory, cioé l’autorizzazione di tipo Basic, che consente il passaggio in chiaro del traffico di autenticazione, a differenza dell’autenticazione di tipo Digest; la terza riga specifica il percorso del file .htpasswd, che altri non è che il file contenente le accoppiate username -> password degli utenti a cui è consentito autenticarsi. Di seguito abbiamo il tag <Limit>, con gli attributi GET, PUT e POST che rappresentano le operazioni consentite in relazione alla directory (rispettivamente download, upload e invio informazioni tramite form), al cui interno vi è l’istruzione "Require valid-user" che dice ad Apache di consentire l’accesso alla directory solamente agli utenti riconosciuti come validi, cioé che hanno fornito le corrette credenziali d’accesso.

Eseguiti questi passaggi, bisogna creare gli utenti del caso tramite il comando htpasswd. La creazione del primo utente comporta anche la creazione del file .htpasswd, tramite questo comando:

# htpasswd -c /var/www/sito/dirProtetta/.htpasswd utente1

Digitato questo comando, verrà chiesta per due volte la password da assegnare all’utente, e contestualmente verrà creato il file .htpasswd nella directory specificata con l’opzione -c; a questo file vanno assegnati adeguate autorizzazioni, in particolare il gruppo www-data (il gruppo che contiene l’utente omonimo che esegue il demone apache2) dovrà poter accedere al file almeno in lettura:

# chown root:www-data /var/sito/dirProtetta/.htpasswd
# chmod 640 .htpasswd

Ora possiamo creare gli altri utenti in questo modo:

# htpasswd /var/www/sito/dirProtetta/.htpasswd utente2

Creati gli utenti, abbiamo fatto quasi tutto; l’ultimo passaggio consiste nel modificare la configurazione di Apache in modo tale che sia consentito l’accesso ai file .ht per la directory che vogliamo proteggere, infatti, almeno in Debian (non so se è così anche con altre distribuzioni), l’accesso ai file .ht è inibito per default, quindi bisogna dire ad Apache che vogliamo sovrascrivere questa impostazione limitatmente alla directory specifica. In particolare, cercare all’interno del file /etc/apache2/apache2.conf il tag <Files> in modo tale che la configurazione finale sia questa:

<Files ~ "^\.ht">
    Order allow,deny
    Deny from all
</Files>

<Directory /var/www/sito/dirProtetta/>
    AllowOverride AuthConfig Limit
</Directory>

dove il tag <Directory> rappresenta appunto la sovrascrittura delle impostazioni date all’interno del tag <Files>.

E’ tutto, ora quando un utente accede a questa particolare directory del sito si ritroverà davanti alla richiesta di inserimento di username e password che Apache dovrà autenticare o meno.

E’ ormai una pratica consolidata, in una rete aziendale, quella di avere un firewall perimetrale attraverso cui passa tutto il traffico in uscita della rete locale, e che regola il traffico in arrivo dall’esterno. La situazione ideale è quella di permettere il traffico in uscita verso Internet e di bloccare tutto il traffico in ingresso da Internet ad eccezione delle risposte alle richieste generate all’interno della rete locale, poi ovviamente succede sempre che devi aprire una porta per il tal servizio, poi l’altro vuole l’accesso remoto, quindi magari pensi che ci starebbe bene una VPN, ecc…

Esistono diversi firewall hardware che svolgono ottimamente questo compito, ma se abbiamo già disponibile un vecchio PC con due schede di rete, possiamo costruirci in modo autonomo un firewall utilizzando una qualsiasi distribuzione Linux. Un’ottima distribuzione da utilizzare per questo scopo è una Debian con installato solamente il sistema di base, infatti tutto ciò che serve per gestire il firewall è compreso nel kernel e più precisamente nel componente Netfilter, che permette appunto di gestire firewall e natting sulla propria macchina Linux tramite diverse regole che vengono definite dall’amministratore tramite il programma iptables.

Iptables raggruppa logicamente i pacchetti in transito sul firewall in base al loro "comportamento" e li suddivide in tre catene generali: INPUT (i pacchetti in ingresso), OUTPUT (i pacchetti in uscita) e FORWARD (i pacchetti in transito tra una scheda di rete e l’altra), quindi, all’interno di queste tre catene, è possibile regolare il traffico di rete in modo anche molto sofisticato. Nel nostro caso invece dovremo semplicemente creare un firewall e non avremo bisogno di un elevato grado di sofisticazione.

Il nostro firewall si posiziona tra la rete locale ed il router Internet che avrà un indirizzo IP pubblico, per cui, il firewall avrà un’interfaccia di rete chiamata eth0 con un indirizzo IP valido sulla LAN, ed un’interfaccia di rete eth1 connessa direttamente col router e con un indirizzo IP pubblico assegnato in grado di comunicare con il router; a questo punto possiamo cominciare con la definizione delle regole del nostro firewall.

Per farlo, creiamo un piccolo script che posizioniamo nella directory /etc/default/ (in realtà penso si possa posizionare più o meno ovunque, io lo metterei comunque dentro /etc) chiamato semplicemente firewall (o comunque lo vogliamo chiamare), quindi lo rendiamo eseguibile e lo andiamo ad editare:

# touch /etc/default/firewall
# chmod 755 /etc/default/firewall
# nano /etc/default/firewall

Come primo passo, dobbiamo abilitare il "routing" tra le due schede di rete, scrivendo all’interno del file l’istruzione

echo 1 > /proc/sys/net/ipv4/ip_forward # abilita il routing tra le due schede di rete

Ora dobbiamo cancellare qualsiasi altra impostazione precedente data a Netfilter e specificare il comportamento predefinito delle tre catene principali:

iptables -F #cancella le impostazioni delle tre catene principali
iptables -X #cancella eventuali catene personalizzate
iptables -P INPUT DROP #rifiuta le connessioni in ingresso
iptables -P OUTPUT DROP #rifiuta le connessioni in uscita
iptables -P FORWARD DROP #rifiuta le connessioni in transito

Trattandosi di un firewall, dobbiamo grossolanamente specificare che le connessioni in uscita sono abilitate mentre non lo sono quelle in ingresso ed in transito, per evitare che le connessioni richieste dalla rete Internet verso la rete LAN possano essere accettate; in questo modo però non sono accettate nemmeno le richieste di connessione dalla rete LAN verso il firewall, ed anche se fossero accettate, non riuscirebbero ad arrivare all’interfaccia eth1 a causa del comportamento predefinito della catena FORWARD, si tratta quindi di raffinare il comportamento del firewall. Inoltre, in questo caso, blocchiamo anche le connessioni in uscita, che non è quel che ci serve, ma come politica predefinita è più sicura, poiché se un pacchetto in uscita non sa come comportarsi, viene scartato. Come prima cosa, accettiamo le connessioni in ingresso su eth0 provenienti dalla nostra LAN, non strettamente necessario ma sicuramente molto utile per amministrare il firewall:

iptables -A INPUT -s 192.168.10.0/24 -i eth0 -j ACCEPT #accetta le connessioni in ingresso dalla propria LAN

ora dobbiamo permettere che i pacchetti in transito da eth0 a eth1 non vengano filtrati dal firewall, quindi dobbiamo fare in modo che i pacchetti di ritorno di connessioni generate dalla nostra rete locale possano transitare nella direzione opposta, cioè da eth1 a eth0:

iptables -A FORWARD -s 192.168.10.0/24 -i eth0 -o eth1 -j ACCEPT #permette il transito di pacchetti provenienti dalla nostra rete locale con destinazione il mondo esterno
iptables -A FORWARD -i eth1 -o eth0 -m state –state ESTABLISHED,RELATED -j ACCEPT #consente ai pacchetti di ritorno di transitare da eth1 a eth0 solo se la connessione era stata già stabilita

Così facendo, i client possono accedere ad Internet ma il firewall non può, cosa che non è positiva visto che di tanto in tanto è necessario aggiornare la nostra distribuzione, quindi vanno aggiunte queste due righe, di cui la seconda ha effetto anche per :

iptables -A INPUT -i eth0 -m state –state ESTABLISHED,RELATED -j ACCEPT #consente ai pacchetti generati direttamente dal firewall di tornare indietro
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE #abilita il natting in modo tale che tutti gli IP mittente vengano cambiati con l’IP di eth1

A questo punto, bisogna fare due operazioni, la prima permettere che i pacchetti che arrivano in ingresso su eth0 possano tornare verso la rete locale (operazione necessaria essendo la catena OUTPUT impostata su DROP come comportamento predefinito), quindi, per fare uscire il firewall verso Internet, bisogna che l’interfaccia eth1 sia abilitata in uscita:

iptables -A OUTPUT -d 192.168.10.0/24 -o eth0 -m state –state ESTABLISHED,RELATED -j ACCEPT #consente l’invio dei pacchetti di risposta generati in seguito a richieste della rete locale
iptables -A OUTPUT -o eth1 -j ACCEPT #consente il transito dei pacchetti in uscita da eth1

Ora i nostri client e il nostro firewall sono in grado di navigare, ovviamente però i client dovranno avere come default gateway l’indirizzo IP di eth0 del firewall. Per rendere attive queste impostazioni, è sufficiente lanciare lo script appena creato, il problema è che così facendo le modifiche andrebbero perse al successivo riavvio del firewall, per cui, è possibile richiamare questo script dal file /etc/network/interfaces in modo da applicare le regole di iptables ad ogni riavvio della rete, e quindi ad ogni riavvio del firewall; per farlo, è sufficiente aggiungere al file /etc/network/interfaces questa riga:

pre-up /etc/default/firewall

ed a questo punto abbiamo il nostro firewall pronto per entrare in funzione.

Possiamo vedere un’ultima casistica, e cioè quella dell’apertura di porte al mondo esterno sul nostro firewall. Ad esempio, potrebbe essere utile aprire la porta 22 del nostro firewall per consentirne l’amministrazione tramite SSH, quindi aggiungere la seguente riga al nostro script

iptables -A INPUT -s 1.1.1.1 -i eth0 -p tcp –dport 22 -j ACCEPT #consente l’accesso via SSH al nostro firewall esclusivamente all’indirizzo IP 1.1.1.1

che consente di accedere ad SSH sul firewall solo all’indirizzo IP 1.1.1.1, se limitare l’accesso SSH per indirizzo IP non è possibile, allora va levata l’opzione -s.

AGGIORNAMENTO

Questa configurazione dà alcuni problemi se si cerca di iniziare una sessione FTP dall’interno della nostra rete locale verso un server FTP esterno, in particolare, connessione ed autenticazione funzionano senza problemi, ma non si riesce ad aprire la sessione dati col server FTP; per ovviare a questo inconveniente, basta mettere nel nostro script contenente le regole di iptables l’istruzione:

modprobe ip_nat_ftp

a questo punto basta far ripartire lo script e sarà possibile effettuare il normale trasferimento di file via FTP.

Link utili
http://guide.debianizzati.org/index.php/Condividere_la_connessione_a_internet
http://it.wikipedia.org/wiki/Netfilter/iptables

Una delle operazioni fondamentali da effettuare su un server è pianificare ed attuare una strategia per il salvataggio dei dati utilizzati sul server. In un sistema Linux esistono diversi sistemi per effettuare un backup, alcuni anche abbastanza evoluti come Amanda e Bacula (almeno per quel che ho letto, fino ad ora non li ho mai utilizzati), ma per backup non troppo complessi da effettuare su una macchina Linux (io ho preso come riferimento la mia installazione di Debian Sarge), si può utilizzare il comando tar, nato proprio con questo scopo; in questo caso, ipotizziamo di fare il salvataggio su un’unità a nastro SCSI, una Sony SDT-10000 DDS4, dispositivo localizzabile su Linux in /dev/st0. Per effettuare un backup della cartella /home/samba (e relative sottocartelle), utilizzare i comandi:

# cd /home
# tar cf /dev/st0 samba

In questo modo verrà effettuato direttamente il backup sull’unità a nastro di tutto il contenuto della cartella; in questo caso il salvataggio avviene sull’unità a nastro senza compressione, poiché ho letto da qualche parte che in caso di problemi, se si effettua un backup con compressione, viene perduto tutto ciò che verrebbe dopo il file "problematico". Se per problemi di spazio, si è comunque costretti ad utilizzare la compressione è possibile usare l’opzione -z.

Effettuato il backup, è possibile verificare il corretto salvataggio dei dati con il comando

# tar dvf /dev/st0

in modo da vedere se ci sono stati problemi durante il salvataggio.

E’ utile poter vedere anche quali file sono stati salvati su nastro, tramite il comando

# tar tf /dev/st0

Un’altra cosa utile è quella di redirigere l’output degli ultimi due comandi in un file di testo, in modo da poterli consultare molto più comodamente che non tramite console:

# tar dvf /dev/st0 > verificaBackup.txt
# tar tf /dev/st0 > listaFileBackup.txt

Da notare che gli ultimi due comandi hanno praticamente lo stesso output, e che, almeno il primo dei due, è meglio lanciarlo dalla directory da cui si è lanciato il comando per effettuare il salvataggio. Ora non rimane che vedere come si ripristinano i dati salvati su nastro:

# tar xf /dev/st0

In molti casi non è necessario ripristinare l’intero contenuto del nastro, ma solamente una sua parte, ad esempio:

# tar xf /dev/st0 samba/scambio

Ovviamente è possibile creare un piccolo script schedulabile tramite cron che effettui un salvataggio periodico dei nostri dati.

Su una rete di PC client Windows che superi la decina di host, per motivi di sicurezza e di gestione centralizzata di utenti e risorse (con tutto ciò che di positivo questo comporta), è una buona cosa avere a disposizione un dominio. Questa tipologia di dominio è stata introdotta da Microsoft, forse con NT 4 o con qualche versione precedente di NT, ed è stata poi aggiornata a partire da Windows 2000 Server con Active Directory. Se la rete non ha esigenze specifiche, sarebbe possibile comunque utilizzare anche un dominio NT invece di un dominio Active Directory. Samba permette di emulare un PDC di un dominio NT 4 e quindi di gestire utenti e risorse condivise per una rete di client Windows su un server Linux, cosa che consente di risparmiare centinaia di euro in piccole realtà che non hanno bisogno di soluzioni particolarmente sofisticate.

La prima cosa ovviamente consiste nell’installare Samba prendendo come riferimento una macchina con installato Debian Sarge, e quindi ho digitato il comando:

# apt-get install samba samba-common samba-doc cupsys cupsys-client libcupsys2-gnutls10 libkrb53 winbind smbclient libcupsys2 smbfs

A questo punto, faccio una copia del file di configurazione smb.conf e ne creo uno nuovo pulito, che andrò a personalizzarmi come meglio credo:

# mv /etc/samba/smb.conf /etc/samba/smb.old
# touch /etc/samba/smb.conf

Ora posso procedere alla configurazione di Samba editando il file smb.conf, che segue regole ben precise. Prima di tutto, va creata una sezione [global] in cui viene descritto il funzionamento generale di Samba, poi verranno create la condivisioni presenti sul server PDC con le relative impostazioni di protezione. Per fare questo, va editato il file smb.conf:

# nano /etc/samba/smb.conf

Ora va creata la sezione [global] ed impostate le direttive basilari:

[global]
workgroup = DOMAIN
netbios name = serverpdc
security = USER

La direttiva workgroup indica il nome del gruppo di lavoro o del dominio (a seconda della configurazione della direttiva security), netbios name indica il nome NetBIOS del server Samba così come verrà visto dai client Windows, mentre security indica il ruolo del server Samba: se impostato a USER indica che il server è un PDC di un dominio, mentre se impostato a SHARE, indica che il server fa parte di un gruppo di lavoro. Ci sono altre possibili impostazioni della direttiva security che al momento non sono importanti. Ora continuare la configurazione di Samba in questo modo:

smb passwd file = /etc/samba/smbpasswd
encrypt passwords = YES
log file = /var/log/samba/%m.log
max log size = 1000
log level = 1

La direttiva smb passwd file indica la posizione del file contenente le password di accesso per gli utenti Samba (esistono altri metodi più evoluti per svolgere la stessa funzione ma questo è il più semplice), encrypt password se impostato a true indica che verranno utilizzate password criptate per l’accesso al dominio. La direttiva log file indica la posizione dei file di log di Samba, e impostando il nome del file a %m.log, viene detto a Samba di creare un file di log per ogni macchina iscritta nel dominio (la variabile di Samba %m specifica il nome NetBIOS dei PC); max log size indica la dimensione massima (in KB) di ogni file di log di Samba, ed una volta raggiunta la dimensione massima il file di log viene rinominato con estensione .old, quindi, va calibrata bene la dimensione dei vari log soprattutto su reti medio-grandi, anche con l’aiuto della direttiva log level, che determina il dettaglio delle informazioni messe da Samba nei file di log, in genere il valore 1 è adeguato. La sezione [global] continua con queste impostazioni:

os level = 255
preferred master = YES
local master = YES
domain master = YES
wins support = YES

Le prime quattro direttive servono per forzare l’elezione del server Samba a Local Master Browser e Domain Master Browser, ruoli che permettono al server Samba di gestire la lista degli host presenti sulla rete locale fornendo questo servizio agli altri PC del gruppo di lavoro / dominio; os level impostato a 255 è il valore massimo, che rende sicura l’elezione del server Samba nei confronti degli altri PC in rete, anche se basterebbe un valore decisamente più basso. La direttiva wins support impostata a YES permette al PC Samba di agire come server WINS per la risoluzione dei nomi NetBIOS nei corrispondenti indirizzi IP.

hosts allow = 192.168.1.0/24 127.0.0.1
hosts deny = all
follow symlinks = NO

Queste sono impostazioni di sicurezza , in particolare hosts allow specifica gli hosts che hanno la possibilità di comunicare con il server Samba, con la successiva direttiva hosts deny = all che nega l’accesso a Samba a tutti gli host, tranne quelli specificati nella riga precedente, mentre follow symlinks, impostato a NO, impedisce ad un utente di seguire un link simbolico se questo si trova su una directory non condivisa.

domain logons = YES
logon home = \\serverpdc\homeuser
logon drive = U:
logon path = \\serverpdc\profili\%u
logon script = logon.bat
add machine script = /usr/sbin/useradd -d /dev/null -g computers -s /bin/false %u

Queste direttive indicano diverse impostazioni specifiche di un PDC Samba; domain logon = YES è la direttiva che imposta il server Samba come PDC, logon home e logon drive permettono di specificare una home directory specifica per ogni utente creato su Samba, mappando sui client l’unità di rete U: sulla condivisione "homeuser" che sarà definita più avanti nel file di configurazione. La direttiva logon path permette di abilitare i profili mobili (chiamati anche roaming profiles), che servono per avere i profili personali degli utenti del dominio sul server invece che sul client; ciò consente ad ogni utente di conservare lo stesso ambiente di lavoro su tutti i PC del dominio; secondo questa configurazione, dovrà essere creata una condivisione "profili" sul server Samba. La direttiva logon script permette di specificare un file batch da inserire nella condivisione "netlogon" (da creare) che verrà eseguito ad ogni accesso da parte degli utenti del dominio, mentre add machine script serve per creare automaticamente l’account corrispondente alla macchina come utente di sistema, senza shell ed appartenente al gruppo "computers" (questo gruppo può assumere il nome desiderato), da creare a parte come mostrato precedentemente.

L’ultimo passo, facoltativo, è quello di indicare a Samba di fungere da print server con l’utilizzo di Cups, tramite le direttive

printing = CUPS
printcap = CUPS

Ora è finita la sezione [global], quindi si può passare alla configurazione delle directory condivise. Per prima cosa creare la directory /home/samba che conterrà tutte le sotto-directory da condividere:

# mkdir /home/samba

ed aggiungere le seguenti directory:

# mkdir /home/samba/netlogon
# mkdir /home/samba/profili
# mkdir /home/samba/scambio

Ora si torna al file smb.conf per definire le condivisioni:

[netlogon]
path = /home/samba/netlogon
read only = YES
write list = root

Per prima cosa creiamo la condivisione [netlogon], in cui andremo a piazzare l’eventuale script di logon per i client Windows. Da notare le due notazioni read only impostata a YES la quale indica che l’accesso alla directory è accessibile solamente in lettura, mentre write list specifica quali utenti hanno l’autorizzazione ad accedere in lettura / scrittura alla directory (in questo caso solo l’utente root può svolgere questa funzione). Inoltre, l’eventuale creazione di un batch di avvio va fatta su un PC Windows, visto che il sistema operativo Microsoft gestisce in modo diverso l’interruzione di riga rispetto a Linux.

[profili]
path = /home/samba/profili/
read only = NO
writable = YES
browsable = NO
create mask = 0600
directory mask = 0700

Qui creiamo invece la condivisione [profili], che serve per indicare la directory in cui verranno memorizzati i singoli profili mobili degli utenti definiti su Samba. Le opzioni read only e writable sono impostate rispettivamente a NO e YES per fare in modo che la directory sia accessibile in lettura e scrittura, con i permessi indicati con le diciture create mask e directory mask, che consentono solo all’utente proprietario della directory di leggere e modificare il contenuto della cartella del proprio profilo; browsable impostato a NO significa che la condivisione non è visibile dalle risorse di rete ma rimane completamente accessibile conoscendone il percorso.

[homeuser]
path = /home/%u
writable = YES
browsable = NO
create mask = 0600
directory mask = 0700
hide dot files = YES

La condivisione [homeuser] rappresenta la home directory di ogni utente, e per comodità e per evitare problemi è meglio crearla in modo tale che l’utente Samba utilizzi la stessa home directory che utilizza il corrispondente utente Linux, com’è possibile vedere nella direttiva path, in cui è presente la variabile %u, la quale consente di definire la directory di ogni utente. Le autorizzazioni ricalcano quelle concesse nella condivisione [profili], ovvero l’unico utente abilitato in lettura e scrittura sulla share è il proprietario della cartella. In più esiste l’opzione hide dot files che consente di non visualizzare i file che iniziano con . (che Linux vede come file nascosti) sulle macchine Windows.

[scambio]
path = /home/samba/scambio
writable = YES
public = YES

La condivisione [scambio] è creata con l’obiettivo di avere un’area comune a tutti gli utenti della rete su cui tutti gli utenti possano leggere e scrivere dati, quindi basta impostare le direttive writable e public a YES per raggiungere lo scopo.

[printers]
path = /var/spool/samba
printable = YES
use client driver = YES

Per condividere stampanti su Samba, deve essere obbligatoriamente creata una condivisione [printers], che imporrà a Samba di condividere le stampanti installate su CUPS (la scelta di CUPS deriva dalle due direttive inserite nella sezione [global]). Path indica il percorso in cui è posizionato lo spooling sul quale transiteranno i job di stampa (se la directory non esiste, va creata in modo esplicito); printable impostato a YES significa che è possibile mandare job di stampa in spooling, mentre la direttiva use client driver impone ai client di installare il driver della stampante di rete quando questa viene installata su un client. Terminata la configurazione di smb.conf, rimangono altre cose da sistemare.

Per prima cosa, bisogna sistemare le autorizzazioni sulla directory /home/samba/profili, facendo in modo che tutti gli utenti della rete possano modificarne il contenuto, così che venga creata la directory del profilo per ogni utente, il cui accesso è regolato dalle direttive già impartite in smb.conf; inoltre, bisogna fare la stessa cosa per la directory scambio, in cui tutti gli utenti possono leggere e scrivere:

# chmod 777 /home/samba/profili
# chmod 777 /home/samba/scambio

Ora bisogna creare la coda di stampa su Linux per definire la stampante condivisa in Samba, quindi per prima cosa assicurarsi che la cartella /var/spool/samba esista, e poi creare la coda di stampa RAW tramite il comando:

# lpadmin -p STAMPANTECONDIVISA -v parallel:/dev/lp0 -E

dove al posto di STAMPANTECONDIVISA va messo un nome a nostra scelta che rappresenta il nome della stampante condivisa (ad esempio Laser1Piano) sul server Samba, mentre /dev/lp0 rappresenta la porta parallela del nostro PC. Creata la coda di stampa, va abilitata la stampa in RAW (cioè con l’invio dei dati grezzi alla stampante), questo serve poiché i driver della stampante devono essere installati lato client e non lato server, e quindi bisogna editare il file mime.types:

# nano /etc/cups/mime.types

decommentando la riga #application/octet e decommentare la stessa riga editando il file mime.convs:

# nano /etc/cups/mime.convs

Fatto questo, è necessario creare la directory /var/spool/samba ed assegnare i permessi in scrittura a tutti gli utenti, in modo che chiunque possa stampare sulla stampante condivisa appena creata:

# mkdir /var/spool/samba
# chmod 777 /var/spool/samba

Fatto questo e riavviato il demone cupsys, la stampante dovrebbe essere accessibile a tutti gli utenti. Nel mio caso, la stampante condivisa è un HP Laserjet 1005, e per questa stampante è necessario fare alcuni passaggi come avevo precedentemente descritto, in questo caso ho fatto un’aggiunta ed ho messo la riga cat /usr/share/foo2zjs/firmware/sihp1005.dl > /dev/lp0 nello script /etc/init.d/cupsys, in modo tale che il firmware della stampante venga inviato alla stampante stessa ad ogni avvio di CUPS. Senza questo accorgimento la stampante non vuole saperne di funzionare.

Ora bisogna creare gli utenti in Samba, infatti gli utenti di Linux non diventano automaticamente utenti di Samba, ma vanno "mappati" tra loro. Il primo utente da creare su Samba è l’utente root, che sarà anche l’amministratore del dominio Samba:

# smbpasswd -a root

e poi faremo in modo di associare il gruppo root di Linux al gruppo globale Domain Admins di Samba, poiché il gruppo Domain Admins è automaticamente amministratore sulle macchine locali una volta che queste sono iscritte al dominio, cosa molto utile per diversi motivi:

# net groupmap modify ntgroup="Domain Admins" unixgroup=root

E’ molto utile anche mappare il gruppo Samba Domain Users (che rappresenta il gruppo di tutti gli utenti del dominio) con il gruppo users di Linux, in questo modo gli utenti che verranno creati faranno automaticamente parte del gruppo Domain Users, utile in fase di assegnazione di permessi:

# net groupmap modify ntgroup="Domain Users" unixgroup=users

Ora è possibile creare gli utenti del dominio; il primo passo consiste nella creazione dell’utente sul sistema Linux, con il comando:

# useradd -m -g users nomeutente

dove l’opzione -m consente la creazione automatica della home directory all’interno della directory /home (cosa indispensabile altrimenti l’utente non si troverà connessa l’unità di rete U: rappresentante la propria home directory), l’opzione -g users assegna l’utente appena creato al gruppo users, mentre nomeutente rappresenta il nome che vogliamo dare a questo utente, ovviamente se abbiamo creato ulteriori gruppi per l’utilizzo in Samba, non sempre assegneremo l’utente appena creato al gruppo users; creato l’utente, bisogna assegnarli una password:

# passwd nomeutente

dopodiché verrà richiesto per due volte di inserire la password dell’utente. Arrivati qui è necessario creare l’utente in Samba con il comando:

# smbpasswd -a nomeutente

dove per nomeutente si intende il nome da assegnare all’utente in Samba; verrà richiesto di digitare due volte la password, ed è bene usare la stessa password per Linux e per Samba, onde evitare problemi. Per creare altri utenti e altri gruppi in Samba si può vedere un approccio leggermente alternativo qui.

Fatti questi passaggi abbiamo un server di dominio ed un print server in grado di servire una rete di client Windows.

N.B. Ho provato ad eseguire questi passaggi su Debian Etch ma con questa configurazione non funziona il join al dominio da parte dei client Windows XP, per qualche motivo che non ho ancora compreso e che sembrano legati alla versione di Samba in uso, più recente su Debian Etch.

Link di riferimento: HowToForge - Openskills - Linux Server Guida completa

Come tutti i sistemi operativi, Linux ha un proprio metodo per eseguire qualsiasi processo ad una determinata ora e per programmarne l’esecuzione ricorrente, in particolare ciò è possibile grazie al demone cron. Questo demone, ogni minuto controlla i file "crontab" presenti sul sistema, poiché non esiste solamente il file /etc/crontab di sistema, ma ogni utente ha la possibilità di definire il proprio file crontab; per definire un file crontab per l’utente corrente, digitare il comando

$ crontab -e

che aprirà un file di testo con nano pronto per essere editato a seconda dei processi che vorremo schedulare. Per controllare la programmazione di cron relativa al proprio utente, digitare il comando

$ crontab -l

e digitare di nuovo il comando

$ crontab -e

se si vuole modificare ulteriormente il proprio crontab.

Invece, come detto, se si vuole modificare la schedulazione "generale" del sistema, bisogna modificare il file /etc/crontab, di cui di seguito è riportato il contenuto predefinito presente su Ubuntu Server 6.10:

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
17 *    * * *   root    run-parts –report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || run-parts –report /etc/cron.daily
47 6    * * 7   root    test -x /usr/sbin/anacron || run-parts –report /etc/cron.weekly
52 6    1 * *   root    test -x /usr/sbin/anacron || run-parts –report /etc/cron.monthly

I primi cinque valori indicano quando (od ogni quanto) i processi verranno eseguiti, in particolare, leggendo da sinistra verso destra, abbiamo:

• valore ‘m’: rappresenta il minuto dell’orario impostato;
• valore ‘h’: rappresenta l’ora dell’orario impostato;
• valore ‘dom’: rappresenta il giorno del mese (da 1 a 31)
• valore ‘mon’: rappresenta il mese dell’anno (da 1 a 12)
• valore ‘dow’: rappresenta il giorno della settimana (da 0 a 6, cioè da domenica a sabato)

Un tipico utilizzo di cron riguarda la procedura di backup dei dati, oppure, come in questo caso, l’aggiornamento periodico di un sistema Ubuntu tramite apt. Ad esempio, andiamo ad impostare l’aggiornamento di Ubuntu il primo di ogni mese alle ore 21. La riga corrispondente da aggiungere  al file /etc/crontab è la seguente:

0 21   1 * *   root    apt-get update && apt-get -y upgrade > /tmp/logcron.txt

Da notare l’opzione -y applicata al comando apt-get upgrade, che permette il download e l’installazione dei pacchetti di aggiornamento senza che compaiano richieste di conferma che di fatto impedirebbero l’esecuzione dell’istruzione, poiché il processo schedulato gira in background e non è possibile interagire con esso. La successiva istruzione > /tmp/logcron.txt permette di salvare l’output del comando nel file /tmp/logcron.txt cancellando tutto il contenuto del file di log, se si vuole fare aggiungere del contenuto al file di log invece di sovrascriverlo, utilizzare il simbolo >> al posto del simbolo >.

Sul sistema Ubuntu che ho utilizzato, ho abilitato l’utente root, non so se non abilitandolo la linea in crontab appena descritta porti all’esecuzione del processo. Inoltre, per questa che è essenzialmente una prova, ho messo il log nella cartella /tmp, magari se la schedulazione è sistematica, potrebbe valer la pena mettere il file di log in un’altra cartella (/var/log ?).

Link di riferimento: Wiki della comunità Ubuntu

In un dominio (Samba o Microsoft) è centrale la gestione degli utenti e dei gruppi per poter gestire al meglio autorizzazioni ed autenticazione sul sistema informativo. Samba e Linux mettono a disposizione gli strumenti per poter gestire con una certa granularità gli utenti ed i gruppi che si autenticano sul dominio. Pensiamo ad esempio di creare un utente con nome BugsBunny appartenente al gruppo LooneyToons, disponibili sull’intero dominio.

Il primo passo consiste nel creare gli utenti sul sistema Linux, che saranno quindi utenti Linux a tutti gli effetti. Per farlo, è possibile utilizzare il comando useradd -m BugsBunny, dove al posto di BugsBunny va inserito il nome con cui l’utente effettuerà il login; quest’utente avrà bisogno anche di una password, da assegnare tramite il comando passwd BugsBunny. L’utente appena creato però sarà disponibile solamente per il login sul sistema Linux, per poterlo usare come utente del dominio Samba quest’utente va creato in modo esplicito per Samba, utilizzando il comando smbpasswd -a BugsBunny, che richiederà anche la password da utilizzare per quell’utente: in genere è buona norma utilizzare la password già specificata per l’utente Linux, anche se questa cosa devo ancora guardarmela bene.

Per quanto riguarda i gruppi di utenti, i concetti sono più o meno simili. Prima cosa, creare il gruppo LooneyToons sul sistema Linux, tramite il comando groupadd LooneyToons, dove al posto di LooneyToons bisogna inserire il nome del gruppo facente parte del dominio. A questo punto bisogna creare il gruppo in Samba, ed è possibile farlo creando automaticamente la corrispondenza tra il gruppo Samba e il gruppo Linux con un unico comando: net groupmap add ntgroup="LooneyToons" unixgroup=LooneyToons type=d. La postilla type=d sta ad indicare che il gruppo appena creato è un gruppo globale, se si volesse creare un gruppo locale bisognerebbe dare l’istruzione type=l. E’ importante notare che un gruppo globale è visibile sull’intero dominio, a differenza di un gruppo locale.

Ora non rimane altro che assegnare l’utente BugsBunny al gruppo LooneyToons. Per farlo, basta assegnare "l’utente Linux" BugsBunny al "gruppo Linux" LooneyToons con il comando gpasswd -a BugsBunny LooneyToons, e quest’impostazione sarà automaticamente recepita da Samba, per cui a tutti gli effetti l’utente BugsBunny farà parte del gruppo LooneyToons anche in Samba, non solo in Linux. Per verificarlo, è possibile elencare gli utenti che fanno parte del gruppo LooneyToons tramite il comando net rpc group members "LooneyToons" -Uroot, inserire la password dell’utente root di Samba e di seguito comparirà la lista degli utenti facenti parte del gruppo LooneyToons.

Ora possiamo autenticarci con l’utente BugsBunny su una qualsiasi macchina iscritta nel dominio, con i privilegi eventualmente assegnati al gruppo LooneyToons.

Link di riferimento: documentazione ufficiale Samba.