Difference between revisions of "Small Business Server (Italiano)/File Server Domain Controller"

From ArchWiki
Jump to: navigation, search
(Concludiamo managgia !)
(Quota)
Line 916: Line 916:
 
Abbiamo già visto come sia possibile da Windows amministrare le ''permissions'' sulle share Samba. Esistono anche delle GUI che ci permettono di gestire utenti e password in modo semplice, specie se le opzioni da settare sono un po' ''esotiche'', tipo la scadenza della password o la lista delle workstation da cui un utente può fare il logon. Ne esistono diversi, dall'ufficale [http://de.samba.org/samba/docs/man/Samba-HOWTO-Collection/SWAT.html Samba Web Adiministration Tool (SWAT)] all' [http://lam.sourceforge.net/ LDAP Account Manager]. Possiamo usarne anche da Windows, ad esempio dal mio preferito (forse perchè fatto con Delphi ?) [http://ldapadmin.sourceforge.net/ LDAP Admin], allo [http://www.microsoft.com/downloads/details.aspx?FamilyID=C0011AB8-3178-4701-A791-EAFBA0F42DE2&displaylang=en User Manager for Domains] "ufficiale" fornito da Microsoft (non è uno scherzo) per amministrare i vari aspetti e flag.
 
Abbiamo già visto come sia possibile da Windows amministrare le ''permissions'' sulle share Samba. Esistono anche delle GUI che ci permettono di gestire utenti e password in modo semplice, specie se le opzioni da settare sono un po' ''esotiche'', tipo la scadenza della password o la lista delle workstation da cui un utente può fare il logon. Ne esistono diversi, dall'ufficale [http://de.samba.org/samba/docs/man/Samba-HOWTO-Collection/SWAT.html Samba Web Adiministration Tool (SWAT)] all' [http://lam.sourceforge.net/ LDAP Account Manager]. Possiamo usarne anche da Windows, ad esempio dal mio preferito (forse perchè fatto con Delphi ?) [http://ldapadmin.sourceforge.net/ LDAP Admin], allo [http://www.microsoft.com/downloads/details.aspx?FamilyID=C0011AB8-3178-4701-A791-EAFBA0F42DE2&displaylang=en User Manager for Domains] "ufficiale" fornito da Microsoft (non è uno scherzo) per amministrare i vari aspetti e flag.
 
== Quota ==
 
== Quota ==
Altro aspetto interessante è la gestione delle ''Disk Quota'' da assegnare ad utenti e gruppi. Questo, come per le ACL Posix, è un "affare" anche del file system, oltre che di Samba con il ''vfs objects = default_quota''
+
Altro aspetto interessante è la gestione delle ''Disk Quota'' da assegnare ad utenti e gruppi. Questo, come per le ACL Posix, è un "affare" anche del file system, oltre che di Samba con il ''vfs objects = default_quota''.
 +
 
 
Dopo averli installati con  
 
Dopo averli installati con  
 
  sudo pacman -S quota-tools
 
  sudo pacman -S quota-tools
 
Potete trovare informazioni sulla parte file system su come amministrarli e configurarli in giro per la rete, ad esempio [http://a2.pluto.it/a2204.htm qui]. Per la parte Samba naturalmente la solita "bibbia" rappresentata dalle guide ufficiali.
 
Potete trovare informazioni sulla parte file system su come amministrarli e configurarli in giro per la rete, ad esempio [http://a2.pluto.it/a2204.htm qui]. Per la parte Samba naturalmente la solita "bibbia" rappresentata dalle guide ufficiali.
 +
 
== Comandi Samba ==
 
== Comandi Samba ==
 
Samba viene fornito con una serie di comandi utili all'amministratore, da ''pdbedit'' per amministrare utenti e gruppi alla pletora dei comandi ''net'' disponibili. Facciamo un paio di esempi, con il comando:
 
Samba viene fornito con una serie di comandi utili all'amministratore, da ''pdbedit'' per amministrare utenti e gruppi alla pletora dei comandi ''net'' disponibili. Facciamo un paio di esempi, con il comando:

Revision as of 11:32, 30 January 2008

Introduzione

Questa parte della guida è, personale opinione, la più importante. Un file server in una azienda è sicuramente lo scopo principale per cui si installa un server (almeno inizialmente). Oramai nessuno può svolgere i compiti principali senza condivisione di dati tra utenti, e le soluzioni peer to peer di condivisione hanno limiti che non stò neanche a considerare qui. Prima di proseguire permettetemi di sintetizzare dei concetti di base che devono essere ben chiari prima di passare alla fase di implementazione della rete vera e propria.

Samba

Con GNU/Linux ho diverse possibilità di scelta, ma io considererò solo la soluzione Sambache mi permette di interagire ottimamente con dei clients Microsoft Windows che, volenti o dolenti, rappresentano il 98% del mercato desktop. Samba è un grande, complesso progetto. Scopo del progetto è l’ interoperabilità il più trasparente possibile tra il mondo Microsoft Windows e i sistemi Unix/Linux. Samba offre servizi di autenticazione e condivisione file e stampanti da una qualsiasi piattaforma TCP/IP enabled. Le piattaforme originali erano Unix e Linux,ma oggi vengono impiegati con successo anche altri tipi di sistemi.

Cos’e’ questa guida ?

Ricordo ancora che questa guida NON è una guida completa a Samba e OpenLDAP, oltre a quanto già ribadito presuppone anche che abbiate già una buona conoscenza di come funziona una rete Windows basata su un dominio. Lo scopo che ci prefiggiamo qui è quello di descrivere in modo abbastanza esteso un caso di reale implementazione di una rete che utilizzano Microsoft Windows sui loro desktop e Linux, Samba e OpenLDAP su lato server in sostituzione dei prodotti server di Microsoft. Essendo un progetto di una certa complessità non bisogna trascurare il fatto che leggere le guide “ufficiali” molto ben fatte e aggiornate che trovate sul sito è molto più di un consiglio: fare le cose senza capirle bene è una pessima abitudine.

Samba Server è meglio di Windows Server ?

Ad essere sinceri, secondo me, la risposta è NO. Samba è fantastico nel “mascherare” le evidenti differenze tra le piattaforme Windows e Linux/Posix, il risultato non è perfetto, ma essendo un prodotto il continua e veloce evoluzione queste “imperfezioni” sono sempre meno percettibili. Và comunque detto che queste “imperfezioni” non si riferiscono alle funzionalità nei servizi offerti da Samba (questi oramai hanno raggiunto un grado di affidabilità molto elevata, considerando il fatto che milioni di PC nel mondo usano questi servizi), ma bensì al fatto di far credere ai client Windows che dalla parte server non c’e’ Samba ma un “regolare” server Windows. Non tutte le funzionalità sono state implementate (ad esempio i gruppi nidificati e le utili Group Policy) e quindi se voglio usare Samba qualche caratteristica avanzata deve essere lasciata da parte. Queste “mancanze” saranno dei macigni per un fido Microsoft sponsor, dei sassolini per chi, come me, non ama le guerre di religione Microsoft/Linux, ma cerca di cavare il meglio dalle due piattaforme. Pane al pane, vino al vino: Windows sui Desktop (per ora) e, ove possibile e conveniente, Linux sui Server. Ricordiamoci, inoltre, che Samba NON puo’ agire come ADS (Active Directory) Domain Controller (Windows 2000/2003 server), ma puo’ efficacemente diventarne membro come server aggiuntivo. La funzionalità ADS domain controller sarà inclusa nella versione 4 di Samba ora in fase di sviluppo. Samba 3 puo’ “emulare” un Domain Controller stile Windows NT 4 anche se con notevoli miglioramenti nella scalabilità dovuti in gran parte alla adozione di OpenLDAP come possibile backend (repository) per utenti, gruppi e passwords. Naturalmente dei server Windows 2000 o 2003 possono efficacemente essere inseriti in un dominio controllato da Samba 3 come server membri.

Ma allora perché usare Samba ?

I motivi possono essere molti. Vi posso dire i miei personali. Ho optato per Samba perché :

  • Salute. Mi viene il mal di testa quando leggo le politiche licensing di Microsoft, non per i costi ma per il garbuglio di opzioni che cambiano ad ogni quando. Con Linux/Samba questi pensieri svaniscono per sempre.
  • Risparmio. Fate voi il conto di quanto costano le licenze per un dominio con il numero di PC nella vostra rete e il server. Attenzione però, inutile illudersi, generalmente i costi di manutenzione sono grossomodo gli stessi.
  • Sicurezza. Non voglio sindacare sul livello di sicurezza raggiunto da Windows (dipende naturalmente anche da chi lo installa), ma il fatto che Linux è molto meno preso di mira da virus e allegra brigata mi fa dormire sonni più tranquilli.
  • Single Signon. Con OpenLDAP riesco ad avere un unico repository dei dati utenti/password per tutti i servizi e server aziendali (posta, rete ecc.). Il cambio password di un utente non è più un incubo, ogni Desktop o Server, Windows o Linux che sia, viene autenticato centralmente nell’ albero OpenLDAP.

E’ più facile usare/amministrare Windows o Linux/Samba ?

Qui sarebbe difficile trovare due persone con la stessa opinione. Personalmente vi posso dire che Windows e il suo Active Directory Services (ADS è un LDAP pesantemente personalizzato da Microsoft per lo scopo) è un eccellente prodotto e capire come realizzare un dominio con esso vuol dire masticare argomenti disparati quali LDAP, DNS, DHCP, TCP/IP, KERBEROS, WINS, e tutti gli aspetti inerenti ad una rete Microsoft: Primary Domain Controller (PDC), Backup Domain Controller (BDC), Browsing della rete, Access Control List (ACL) alle share, Profili Roaming eccetera. Insomma l’argomento è complesso, e avventurarsi in una installazione di questo tipo senza padroneggiare questi concetti è una PESSIMA IDEA. E con Linux/Samba ? Stessa cosa, devo avere alba di cosa sia Linux, come si installa e come si amministra in modo almeno basilare, oltre a tutte le cose dette per Windows: LDAP, DNS, WINS, PDC, BDC, ACL, Profili Roaming ecc.. Ovviamente anche con Samba ci scontreremo con questi concetti basilari. Alla fine della fiera la differenza sarà che con Windows ho dei comodi (ma a parer mio a volte diseducativi) tools grafici per fare il tutto, con Linux un mix tra tools grafici e cari e vecchi (ma efficaci) tools da linea di comando.

Sostituisco i miei server Windows con Linux/Samba ?

Mah, dipende. Se ho già un dominio Windows 2000/2003 ADS funzionante significa che ho già investito in licenze ed ammennicoli vari e sostituirlo con Samba non è che porta a svolte miracolose. Io eviterei, ribadisco che ADS è un buon prodotto. Se invece devo aggiungere un file server al dominio ADS, Samba puo’ essere una valida opzione. Diverso il caso in cui dovessi aggiornare dei server Windows NT che ora Microsoft non segue più. Anche in questo caso la migrazione a Samba può essere una valida opzione.

N.B. Se ho più server ricordiamoci un concetto importante : Se il PDC è Windows il/i BDC devono essere Windows, i server membri aggiuntivi sia Samba che Windows. Se il PDC è Samba il/i BDC devono essere Samba, i server membri aggiuntivi sia Samba che Windows.

Bene, ora che è tutto chiaro (...) con possiamo iniziare :) .

Installazione

Cominciamo con la configurazione del nostro file server domain controller basato su Samba e OpenLDAP. Come primo passo dedichiamoci all' installazione dei pacchetti necessari.

Operazioni preliminari

In questo tipo di configurazioni è bene concentrarci sul singolo problema, evitando di correr dietro a cause esterne dovute ad altri servizi. Tutto questo per dire che se per caso avete attivato il firewall è giunto il momento di disattivarlo momentaneamente. Quando tutto funzionerà a dovere lo ripristineremo con le rules aggiuntive opportune. Quindi:

sudo /etc/rc.d/shorewall stop

In più abilitiamo momentaneamente **tutti** i protocolli :

sudo nano /etc/hosts.allow

e aggiungiamo la riga

all: ALL : allow

Bene, ora che abbiamo eliminato eventuali cause esterne possiamo proseguire.

Il repository radioattivo

Durante l'installazione ho, purtroppo, constatato che i pacchetti necessari in questa impresa non sono tutti disponibili né sui repository ufficiali nè su AUR. Certo, essendo degli script perl e delle librerie dello stesso, avrei potuto usare CPAN ed installare gli script a mano, ma finché posso voglio evitare questa pratica e allora (rullo di tamburi:)) ho creato un piccolo e radioattivo repository personale con quello che ci serve. Creare un repository con Arch è veramente una operazione banale con il comando repo-add, un po' più complicati sono i PKGBUILD. Di grande aiuto mi è stata l'utility cpan4pacman installata precedentemente, che mi ha creato i PKGBUILD per le librerie perl mancanti, appena un po' più complesso il pacchetto smbldap-tools che ho dovuto fare da zero (o quasi). Perchè radioattivo ? Perchè ho ignorato tutte le opzioni di verifica delle dipendenze e i checksum MD5. Sono script in perl, di bassa pericolosità, ma naturalmente non mi assumo responsabilità.

Attiviamo il repository

sudo nano /etc/pacman.conf

aggiungiamo in fondo :

[stenoweb]
Server = http://www.stenoweb.it/repo/i686

e per finire aggiorniamo la lista dei pacchetti "risucchiando" la lista anche dal repo stenoweb:

sudo pacman -Sy

Bene ! Non dovreste ottenere errori.

Installazione pacchetti

Samba

Ma come diavolo si installerà Samba ? io proverei con un:

sudo pacman -S samba

Funziona ! Scusate non ho resistito ...

LDAP Tools

E qui interviene il mio repository. Gli LDAP Tools sono degli script realizzati in perl che permettono di gestire utenti e gruppi Samba/Unix salvando i dati sull'albero LDAP anziché sui file /etc/passwd e /etc/group. In pratica sostituiscono i vari comandi standard linux di gestione degli utenti. Iniziamo con installare le librerie perl necessarie :

sudo pacman -S perl-digest-sha1 perl-crypt-smbhash perl-jcode perl-unicode-map perl-unicode-map8 perl-unicode-maputf8 perl-unicode-string perl-ldap perl-io-socket-ssl 

e poi il pacchetto vero e proprio con gli scripts:

sudo pacman -S smbldap-tools

Gli script sono stati copiati/installati in /usr/local/bin e i file di configurazione in /etc/smbldap-tools. I comandi sono nella forma (ad esempio per aggiungere un utente) :

sudo /usr/local/bin/smbldap-useradd nomeutente

ma non provateci adesso, mancando la necessaria configurazione otterrete solo un errore. Ho fatto qualcosa in più: data la lunghezza del comando lo script di installazione del pacchetto crea anche dei link simbolici di più agevole forma in /bin. Il comando di prima diventerà il più semplice:

sudo netuseradd nomeutente

Prolunghiamo la vita alle nostre tastiere! :)

Samba LDAP Schema

Per ultimo abbiamo bisogno del file di schema da applicare a OpenLDAP per memorizzare i dati di cui ha bisogno Samba. Cos'e' un file di schema ? LDAP in buona sostanza è un database, lo schema non è altro che il tracciato record che descrive, dichiara e crea i campi nel database LDAP. Nello schema Samba ci sono i campi per il nome utente, la password, la home, i gruppi ecc. che servono a memorizzare i nostri dati nell'albero LDAP. Il file samba.schema di cui abbiamo bisogno è fornito con i sorgenti di Samba: anziché scaricare i 17MB, scompattare e recuperare il file ve lo fornisco io direttamente. Spostiamoci nella cartella degli schemi di OpenLDAP :

cd /etc/openldap/schema

e scarichiamoci lo schema:

sudo wget http://www.stenoweb.it/repo/noarch/samba.schema

Configurazione autenticazione LDAP

Dopo aver installato tutti i pacchetti necessari cominciamo con la configurazione di OpenLDAP e la inizializzazione del suo database con gli utenti e gruppi di default richiesti da un dominio stile Microsoft.

OpenLDAP server

Abbiamo già configurato in modo basilare OpenLDAP, ora rimettiamo mano alla configurazione per includere ciò di cui ha bisogno samba.

sudo nano /etc/openldap/slapd.conf

Includiamo gli schemi necessari all'inizio (nis e samba):

include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/samba.schema

Impostiamo le regole di accesso :

access to dn.base=""
               by self write
               by * auth
access to attrs=userPassword,sambaNTPassword,sambaLMPassword
       by dn="cn=Manager,dc=mede,dc=it" write
       by anonymous auth
       by self write
       by * none
access to *
               by * read
               by anonymous auth

Soffermiamoci su di un aspetto: il rootdn cn=Manager,dc=mede,dc=it ha comunque accesso ai dati in lettura scrittura anche se non specifico nulla, ma di particolare importanza è la regola di accesso access to attrs=userPassword,sambaNTPassword,sambaLMPassword che di fatto permette ai singoli utenti di cambiare la propria passaword direttamente da Windows. Per ultima cosa definiamo gli indici di ricerca per velocizzare gli accessi all'albero ldap (eliminate le voci "index" già presenti e sostituitele con queste) :

# Indices
index objectClass           eq
index cn                    pres,sub,eq
index sn                    pres,sub,eq
index uid                   pres,sub,eq
index displayName           pres,sub,eq
index uidNumber             eq
index gidNumber             eq
index memberUID             eq
index sambaSID              eq
index sambaPrimaryGroupSID  eq
index sambaDomainName       eq
index default               sub

Per attivare le nuove impostazioni riavviamo il servizio:

sudo /etc/rc.d/slapd restart

Il nostro albero è pronto.

LDAP Tools

Gli LDAP tools sono necessari per gestire utenti e gruppi, per poterli utilizzare dobbiamo configurarli a dovere. Per prima cosa diamo un file di configurazione di base a Samba :

sudo nano /etc/samba/smb.conf

e inseriamo :

[global]
       unix charset = LOCALE
       workgroup = MEDE
       netbios name = ARCHI
       server string = %h PDC (%v)
       interfaces = eth1, lo
       bind interfaces only = Yes
       enable privileges = yes
       guest account = guest
       domain logons = Yes
       domain master = yes
       preferred master = Yes
       os level = 65
       wins support = Yes
       security = user
       ldap suffix = dc=mede,dc=it
       ldap user suffix = ou=Users
       ldap machine suffix = ou=Computers
       ldap group suffix = ou=Groups
       ldap idmap suffix = ou=Idmap
       ldap admin dn = cn=Manager,dc=mede,dc=it
       idmap backend = ldap:ldap://archi.mede.it
       idmap uid = 10000-20000
       idmap gid = 10000-20000
       ldap passwd sync = Yes
      #ldap ssl = start tls
       ldap ssl = no

Come si può notare al momento (ricordo che il servizio samba non è stato ancora avviato) forniamo sono i dati essenziali, quali il dominio (workgroup = MEDE), il nome del server (netbios name = ARCHI), il suo ruolo di Domain Controller (domain logons = Yes) e i parametri LDAP. Sugli altri parametri consiglio una buona guida di Samba o le sue manpage :). Come secondo passo prendiamo nota del SID del nostro server:

sudo net getlocalsid

dovrei ottenere qualcosa del tipo:

SID for domain ARCHI is: S-1-5-21-1491279793-2809991009-2777690449

Ora editiamo i file di configirazione dei smbldap-tools:

nano /etc/smbldap-tools/smbldap.conf

e scorrendo i parametri impostamoli così:

#Il SID ricavato con il comando precedente
SID="S-1-5-21-1491279793-2809991009-2777690449"
sambaDomain="MEDE"
suffix="dc=mede,dc=it"
hash_encrypt="MD5"
defaultMaxPasswordAge="180"
userSmbHome=""
userProfile=""
userHomeDrive="K:"
userScript="%U.bat"
mailDomain="mede.it"

Gli altri lasciamoli con i valori di default. Salviamo e editiamo il file:

sudo nano /etc/smbldap-tools/smbldap_bind.conf

e facciamo diventare così:

slaveDN="cn=Manager,dc=mede,dc=it"
slavePw="archimede"
masterDN="cn=Manager,dc=mede,dc=it"
masterPw="archimede"

Ricordo che "archimede" è la password che ho deciso per l'amministratore LDAP, la stessa che ho messo in /etc/openldap/slapd.conf in formato MD5. Finito questo proteggiamo i file da occhi indiscreti:

sudo chmod 0644 /etc/smbldap-tools/smbldap.conf
sudo chmod 0600 /etc/smbldap-tools/smbldap_bind.conf

Ora non ci resta che dire anche a Samba la password da utilizzare per accedere a LDAP:

sudo smbpasswd -w archimede

se ottenete una risposta del tipo:

Setting stored password for "cn=Manager,dc=mede,dc=it" in secrets.tdb

Significa che fino ad ora tutto và per il verso giusto, e possiamo proseguire.

Popolare LDAP

Per il funzionamento corretto SAMBA ha bisogno di diversi gruppi predefiniti e 2 utenti: Administrator e guest. Inoltre, affinché si riesca ad aggiungere computer al dominio in modo automatico (da macchine Windows), deve esistere un utente con uid = 0 da utilizzare per questa operazione. Tale utente può essere un utente root (da aggiungere a mano) o lo stesso Administrator cambiandogli l'uid. Quest'ultima è la scelta presa in questa configurazione, in modo da avere un utente Administrator che è Administrator per Samba e root per il "dominio" UNIX. Gli ldap tools forniscono un comodo comando per svolgere questa operazione: smbldap-populate. Lanciamolo così con questi parametri:

sudo /usr/local/bin/smbldap-populate -a Administrator -u 5001 -g 5001 -r 5001 -b guest -l 5000

al termine ci viene chiesta la password di "Administrator", mettiamo la stessa di root per non fare confusione. Dovrei vedere qualcosa del genere :

Populating LDAP directory for domain MEDE (S-1-5-21-1491279793-2809991009-2777690449)
(using builtin directory structure)
 
adding new entry: dc=mede,dc=it
adding new entry: ou=Users,dc=mede,dc=it
adding new entry: ou=Groups,dc=mede,dc=it
adding new entry: ou=Computers,dc=mede,dc=it
adding new entry: ou=Idmap,dc=mede,dc=it
adding new entry: uid=Administrator,ou=Users,dc=mede,dc=it
adding new entry: uid=guest,ou=Users,dc=mede,dc=it
adding new entry: cn=Domain Admins,ou=Groups,dc=mede,dc=it
adding new entry: cn=Domain Users,ou=Groups,dc=mede,dc=it
adding new entry: cn=Domain Guests,ou=Groups,dc=mede,dc=it
adding new entry: cn=Domain Computers,ou=Groups,dc=mede,dc=it
adding new entry: cn=Administrators,ou=Groups,dc=mede,dc=it
adding new entry: cn=Account Operators,ou=Groups,dc=mede,dc=it
adding new entry: cn=Print Operators,ou=Groups,dc=mede,dc=it
adding new entry: cn=Backup Operators,ou=Groups,dc=mede,dc=it
adding new entry: cn=Replicators,ou=Groups,dc=mede,dc=it
adding new entry: sambaDomainName=MEDE,dc=mede,dc=it
 
Please provide a password for the domain Administrator:
Changing UNIX and samba passwords for Administrator
New password:
Retype new password: 

Come possiamo notare smbldap-populate ha creato utenti e gruppi predefiniti in una installazione di windows server. Per vedere se tutto funziona proviamo a creare un utente user1:

sudo netuseradd -a -m user1

e diamogli una password :

sudo netpasswd user1

ora controlliamo se l'utente c'e':

sudo getent passwd

Dovrei ottenere la lista degli utenti tra cui :

Administrator:x:0:0:Netbios Domain Administrator:/home/Administrator:/bin/false
guest:x:5000:514:guest:/dev/null:/bin/false
user1:x:5001:513:System User:/home/user1:/bin/bash

per le opzioni complete digitiamo netuseradd senza parametri e diamo una occhiata. Nell'esempio il parametro -a crea sia l'utente unix che samba e -m crea la home (/home/user1) dell'utente.

Pianificazione condivisioni

E' (quasi) giunto il momento di avviare Samba, ma prima dobbiamo pianificare un po' COSA andremo a condividere e COME impostare gli accessi al file system (ACL). Quello che propongo qui è solo un esempio, i casi possono essere innumerevoli, ma secondo me questa rappresenta comunque una buona base di partenza.

Gruppi

Definiamo e creiamo un insieme di gruppi di utenti a cui poi assegnare una condivisione "privata". I nomi sono di fantasia (anche se non proprio :)):

Gruppo Descrizione
commerciale utenti ufficio commerciale
tecnico utenti ufficio tecnico
Domain Users gruppo che contiene tutti gli utenti

Domain Users è già stato creato con smbldap-populate. Ogni nuovo utente viene assegnato in modo automatico a questo gruppo.

Creiamo gli altri gruppi

sudo netgroupadd -a Commerciale
sudo netgroupadd -a Tecnico

Creiamo gli utenti

sudo netuseradd -a -m commerciale1
sudo netpasswd commerciale1
sudo netuseradd -a -m tecnico1
sudo netpasswd tecnico1

se abbiamo fatto tutto correttamente non dovrei vedere errori, controlliamo con:

sudo getent passwd

Alla fine dovrei vedere gli utenti appena creati:

commerciale1:x:5001:513:System User:/home/commerciale1:/bin/bash
tecnico1:x:5002:513:System User:/home/tecnico1:/bin/bash

Nota: come possiamo vedere ad ogni utente viene concesso l'accesso shell (/bin/bash). Se vogliamo togliere questo privilegio basta modificare l'utente (ad esempio tecnico1) così:

sudo netusermod -s /bin/false tecnico1  

Assegniamo gli utenti ai gruppi

sudo netgroupmod -m commerciale1 Commerciale
sudo netgroupmod -m tecnico1 Tecnico

Anche qui possiamo controllare con :

sudo getent group

e ottenere qualcosa del genere:

Commerciale:*:5001:commerciale1
Tecnico:*:5002:tecnico1

I comandi net* li trovo in /bin: è utile prendere dimestichezza con questi per amministrare utenti e gruppi.

Condivisioni

Vediamo ora cosa andremo a condividere, ho deciso di mettere tutto (tranne le home directory) in /samba:

Condivisione Percorso Descrizione
public /samba/public Cartella pubblica. Contiene una cartella per ogni gruppo (vedi dopo)
netlogon /samba/netlogon Cartella di sistema necessaria in un domain controller. Contiene gli script di login utente.
profiles /samba/profiles Cartella di sistema. Mi serve se uso i Profili Roaming di windows.
rootdir /samba Condivisione ad uso backup. Contiene anche i symlink ai file più importanti del mio server
apps /samba/apps Cartella applicazioni. Sola lettura
homes /home Cartelle home per gli utenti. Ognuno la sua.

public

Questa condivisione è la principale, anziché creare una condivisione per ogni gruppo ho deciso di mettere tutto dentro a public e di "giocare" poi con i permessi sulle cartelle. Per capirci meglio :

/samba/public di proprietà di root/Administrator solo leggibile dagli altri
/samba/public/commerciale Cartella per gruppo "Commerciale"
/samba/public/tecnico Cartella per gruppo "Tecnico"
/samba/public/comune Cartella condivisa di tutti ("Domain Users")

Poi andremo a mappare una unità L: (a scelta) sulla condivisione "public" e gli utenti del gruppo "Commerciale" vedranno L:\COMUNE e L:\COMMERCIALE, gli utenti del gruppo "Tecnico" vedranno solo L:\COMUNE e L:\TECNICO. Nessuno (tranne i membri del gruppo "Domain Admins", off course) possono creare files o cartelle nella root di L:. Tengo a precisare che questa non è una regola ma una mia personale idea su come organizzare le condivisioni. Quando abbiamo a che fare con molti gruppi ritengo abbastanza noioso e confusionario fare condivisioni separate. Un utente membro di diversi gruppi si troverebbe con molte mappature diverse che esauriscono in breve l'alfabeto. In questo modo ho una unica mappatura (L:\) e ognuno vedrà le sottocartelle a cui avrà accesso. Molto più ordinato e comodo. Questo tipo di organizzazione è la stessa che usavo quando installavo Novell Netware 10-15 anni fà, e quindi non ha niente di specifico di Samba o di Windows. Quindi creiamo la struttura :

sudo mkdir /samba/public
sudo mkdir /samba/public/commerciale
sudo mkdir /samba/public/tecnico
sudo mkdir /samba/public/comune

e sistemiamo i permessi e la proprietà :

sudo chmod 770 /samba/public/commerciale
sudo chgrp Commerciale /samba/public/commerciale
sudo chmod 770 /samba/public/tecnico
sudo chgrp Tecnico /samba/public/tecnico
sudo chmod 770 /samba/public/comune
sudo chgrp "Domain Users" /samba/public/comune

Controlliamo cosa abbiamo combinato:

ls -al /samba/public

e dovrei vedere qualcosa del genere:

drwxr-xr-x 5 root root         4096 17 dic 16:24 .
drwxr-xr-x 7 root root         4096 12 dic 16:11 ..
drwxrwx--- 2 root Commerciale  4096 17 dic 16:24 commerciale
drwxrwx--- 2 root Domain Users 4096 17 dic 16:24 comune
drwxrwx--- 2 root Tecnico      4096 17 dic 16:24 tecnico

La "rogna" dei permessi utente

Ora che abbiamo dato i permessi alle cartelle ci troviamo di fronte ad un problema inaspettato. Quando gli utenti creano nuovi files o cartelle nelle condivisioni questi vengono flaggati con utente=UtenteCreatore e gruppo=GruppoDefaultUtente. Il gruppo di default è "Domain Users", quindi tutti i nuovi files vengono impostati con questo gruppo. Dunque i nuovi files creati in "commerciale" sono potenzialmente a disposizione anche degli utenti del gruppo "Tecnico", essendo anche questi membri del gruppo "Domain Users". In questo caso sono protetti dai permessi della cartella stessa, ma potrebbe non essere così in un altro caso. L'utente "Administrator" ha come gruppo di default "Domain Admins", quindi ogni file creato/copiato/ripristinato dall'amministratore risulta non accessibile dagli utenti "normali". Indubbiamente una bella rottura di scatole dover ogni volta reimpostare a mano i permessi sui files manipolati dall'amministratore ... Ma non disperate ! :) Ci viene in aiuto il flag SETUID di unix. Se leggete l'articolo linkato sembra non centrare una benemerita fava con l'argomento in questione, ma in questo caso l'effetto del flag è quello da noi voluto. In pratica abilitiamo il flag sul gruppo in questo modo :

sudo chmod g+s /samba/public/commerciale
sudo chmod g+s /samba/public/tecnico
sudo chmod g+s /samba/public/comune

se ricontrollo ora con ls -al dovrei vedere che la tripletta dei permessi sul gruppo è cambiata da rwx a rws che indica, appunto, che è attivo il setuid. Cosa provoca questo ? Questo trucchetto fà si che ogni file creato nelle cartelle avrà come gruppo proprietario il guppo della cartella e non quello dell'utente. Quindi ogni file, ad esempio, creato in "commerciale" avrà come gruppo proprietario "Commerciale" che corrisponde al gruppo proprietario della cartella. Ora potete usare anche "Administrator" per ripristinare o creare files che saranno accessibili agli utenti normali. Fiuuuuuu. Andiamo avanti.

netlogon & profiles

Queste sono due condivisioni di sistema, necessarie quando si configura un domain controller. In netlogon si saranno gli script di login degli utenti (che vedremo come creare al "volo" in modo dinamico), in profiles ci saranno i profili utente nel caso avessimo deciso di usare i profili roaming di Microsoft (utili i certi casi, ma a me, idea personalissima, non piacciono). Creiamo le certelle e diamo i permessi :

sudo mkdir /samba/netlogon
sudo mkdir /samba/profiles
chmod 777 /samba/profiles

rootdir

Questa è una condivisione di "comodo" accessibile solo all'amministratore. Creiamo anche una cartella system con i link simbolici alle cartelle o ai file che poi potremmo salvare via condivisione samba da un altro PC per fare dei veloci backup.

sudo ln -s /home /samba/home

In questo modo l'amministratore accedendo alla condivisione "rootdir" potrà vedere e manipolare tutte le home degli utenti

sudo mkdir /samba/system
sudo ln -s /etc /samba/system/etc
sudo ln -s /var/lib/openldap/openldap-data /samba/system/ldap

Ora l'amministratore trova nella cartella "system" anche i file di configurazione del server e il database utenti/gruppi di OpenLDAP. Molto comodo, e potrei anche aggiungere altri link senza inventarmi condivisioni "esotiche".

apps

In questa condivisione mettiamo i programmi condivisi nella rete. Solo "Administrator" può scrivere nella cartella, gli altri utenti possono solo leggere e eseguire i file contenuti. creiamo la cartella e settiamo i permessi:

sudo mkdir /samba/apps
sudo chmod 750 /samba/apps
sudo chgrp "Domain Users" /samba/apps
sudo chmod g+s /samba/apps

homes

Questa condivisione è creata automaticamente (o quasi) da Samba. Le home degli utenti saranno mappate con K: e sarà privata ad ogni utente.

Bene, dovremmo esserci. Ora siamo pronti a completare la configurazione di samba ed ad avviare (finalmente) il servizio.

Configurazione di Samba

E' giunta l' ora del servizio Samba finalmente. Configuriamolo a dovere e avviamo il servizio. Vediamo anche una (breve) spiegazione dei parametri principali applicati al nostro smb.conf. Andiamo ad editare il file di configurazione di Samba:

sudo nano /etc/samba/smb.conf

e vediamo cosa scriverci ...

Parametri globali

Nella sezione [global] abbiamo i parametri generali del server, soffermiamoci solo su quelli (per me) significativi. Alla fine c'e' il file completo per un comodo copia/incolla. Per il resto rimando alla guida. Il nome del dominio:

workgroup = MEDE

Il nome del server :

netbios name = ARCHI

Samba rimane in ascolto solo sulle interfacce specificate, la eth0 che è rivolta all'esterno verso internet naturalmente non viene servita. O vogliamo dare servizi di file server al mondo ? :)

interfaces = eth1, lo
bind interfaces only = Yes

Diciamo a Samba che il repository di utenti, gruppi e password è il server LDAP specificato.

passdb backend = ldapsam:ldap://archi.mede.it

Ordine con cui vengono risolti i nomi delle workstation. Broadcast per ultimo off course.

name resolve order = wins host dns bcast

Script richiamati da Samba quando da Windows tento le operazioni citate. Questo mi permette di usare tools windows per gestire utenti e gruppi, oltre che ad eseguire la join al dominio.

add user script = /bin/netuseradd -a -m '%u'
delete user script = /bin/netuserdel '%u'
add group script = /bin/netgroupadd -a -p '%g'
delete group script = /bin/netgroupdel '%g'
add user to group script = /bin/netgroupmod -m '%u' '%g'
delete user from group script = /bin/netgroupmod -x '%u' '%g'
set primary group script = /bin/netusermod -g '%g' '%u'
add machine script = /bin/netuseradd -w '%u'

Script di login eseguiti dagli utenti quando si collegano. %U viene trasformata nel nome utente. Ad esempio l' utente tecnico1 eseguirà (se esiste) lo script tecnico1.bat che si trova in netlogon.

logon script = %U.bat

Non voglio i profili roaming, quindi metto a null questi parametri. Attenzione che i parametri userSmbHome e userProfile specificati in /etc/smbldap-tools/smbldap.conf hanno la precedenza su questi !

logon path =
logon home =

Il mio server è un domain controller :)

domain logons = Yes

Eleggiamo il nostro server ad autorità maxima, facciamolo diventare master browser per il segmento della nostra rete.

domain master = yes
preferred master = Yes
os level = 65

Il nostro server è anche server wins

wins support = Yes

Parametri dell'albero LDAP a cui Samba si collega. In questo modo si indica a Samba dove trovare utenti, gruppi, computer e il nome utente da utilizzare per connettersi (cn=Manager). Ricordiamo che la password la abbiamo memorizzata con il comando smbpasswd -w nell'articolo precedente.

ldap suffix = dc=mede,dc=it
ldap user suffix = ou=Users
ldap machine suffix = ou=Computers
ldap group suffix = ou=Groups
ldap idmap suffix = ou=Idmap
ldap admin dn = cn=Manager,dc=mede,dc=it
idmap backend = ldap:ldap://archi.mede.it
idmap uid = 10000-20000
idmap gid = 10000-20000
ldap passwd sync = Yes
ldap ssl = no

Il tipo di autenticazione da usare (IMPORTANTISSIMO!).

security = user

Ho specificato dei parametri aggiuntivi che vedete alla fine del post, lascio a voi il compito di interpretarli ;). Ora passiamo alla sezione condivisioni.

Condivisioni

Abbiamo visto nell' articolo precedente quali condivisioni andiamo a realizzare, vediamo come sono state tradotte sul file di configurazione. Non le espongo tutte, ma solo quelle che hanno qualche parametro significativo da spiegare. La versione completa del file smb.conf la trovate alla fine del post.

public

Nome e percorso condivisione

comment = "L: - Cartella Pubblica Utenti"
path = /samba/public

Scrivibile:

writeable = yes

La vedo nel browsing della rete:

browseable = Yes

Nascondi i file e le cartelle che l'utente non può leggere. Questo è utile, in questa condivisione un utente vedrà solo quello che gli serve anzichè chiedersi cosa ci sia "dentro" una cartella che non riesce ad aprire... :)

hide unreadable = Yes

Questa serie di parametri corrispondono ad una serie di tentativi per fare in modo che questa condivisione funzioni a dovere. Ora non me la sento di cambiare qualcosa. Chi lascia la vecchia strada ...

directory mask = 0775
create mask = 0775
force create mode = 0775
force directory mode = 6775
security mask = 0777
force security mode = 0
directory security mask = 0777
force directory security mode = 0

I vfs objects sono un utile "plugin" di Samba. In questo caso usiamo l'oggetto recycle per realizzare un cestino di rete. I file eliminati non andranno eliminati immediatamente ma finiranno in una cartella nascosta .cestino/nomeutente. Poi faremo uno script di purge per vuotare i cestini ogni tanto. I parametri aggiuntivi servono per dire a samba di non salvare i file temporanei e di backup e di non applicare il versioning ai file di office (creano problemi con il salvataggio automatico di quest'ultimo).

vfs objects = recycle
recycle:repository = .cestino/%U
recycle:keeptree = yes
recycle:touch = yes
recycle:versions= yes
recycle:exclude = *.tmp *.bak ~$*
recycle:exclude_dir = /tmp /temp /cache
recycle:noversions = *.doc *.xls *.ppt

netlogon

Questa condivisione di "servizio" è fondamentale per la gestione degli script di logon degli utenti. Intanto la nascondiamo dal browsing della rete.

browseable = No

Nel momento in cui l'utente accede alla condivisione (e tutti gli utenti di un dominio lo fanno) viene eseguito /etc/samba/logon.pl a cui vengono passati dei parametri tipo il nome utente che ha richiamato lo script, il gruppo, l'orario ecc.. Cosa fà questo programmino ? Semplice, crea lo script di logon dell'utente "al volo" secondo le regole definite in logon.pl. Ad esempio viene creato tecnico1.bat per l'utente tecnico1. Potrei omettere questo parametro e creare a mano lo script, ma così è molto più comodo e vedremo perché.

root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"

E ora vediamo come è fatto questo logon.pl.

sudo nano /etc/samba/logon.pl

e impostiamolo così:

#!/usr/bin/perl
#
open LOG, ">>/var/log/samba/netlogon.log";
print LOG "$ARGV[3] - Utente $ARGV[0] collegato a $ARGV[2]\n";
close LOG;
#
# Elenco utenti per share
#
$APPS   ="-tecnico1-tecnico2-";
$NOLOGON ="-administrator-";
$DELMAP  ="-winnt-win2k-win2k3-winxp-";
$ADMIN   ="administrator";
#
# Inizio generazione script
#
open LOGON, ">/samba/netlogon/$ARGV[0].bat";
print LOGON "\@ECHO OFF\r\n";
print LOGON "ECHO ARCHI logon script\r\n";
print LOGON "ECHO.\r\n";
#
# Sincronizza orario con il server
#
print LOGON "NET TIME \\\\ARCHI /SET /YES\r\n";
#
# Se piattaforma PC in lista $DELMAP cancella i vecchi mappaggi
#
if (index($DELMAP,"-".lc($ARGV[5])."-") >=0)
 {
       print LOGON "NET USE * /DEL /YES\r\n";
 }
#
# Esci se utente in lista $NOLOGON altrimenti applica i mappaggi comuni
#
if (index($NOLOGON,"-".lc($ARGV[0])."-") == -1)
 {
   # Disco L: (PUBLIC)
   print LOGON "NET USE L: \\\\ARCHI\\public /YES\r\n";
   # Disco K: (HOME)
   print LOGON "NET USE K: \\\\ARCHI\\$ARGV[0] /YES\r\n";
  
   # Disco X: (APPS)
   if (index($APPS,"-".lc($ARGV[0])."-") >=0)
     {
       print LOGON "NET USE X: \\\\ARCHI\\apps /YES\r\n";
     }
 }
# Chiudi il file.
close LOGON;

Possiamo vedere che condizioniamo la creazione dello script in base a delle variabili in testa. Ad esempio solo la lista degli utenti specificata in $APPS (tecnico1 e tecnico2 separati con "-") avranno la mappatura X:, e gli utenti listati in $NOLOGON (administrator) non avranno alcuno script. Tutto chiaro ? Questo script può essere modificato ed esteso con semplicità seguendo questo schema di esempio, e ha il pregio di semplificare la gestione degli script di logon. Voglio che anche l'utente "commerciale1" mappi la X: per \\archi\apps ? Basta aggiungerlo nella lista $APPS e la prossima volta che si collega al server avrà il suo script aggiornato "al volo". In più ho anche un file di log in /var/log/samba/netlogon.log che mi informa dell'orario di collegamento degli utenti.

Wow. A volte le cose semplici sono le più importanti. Come compito a casa mi fate lo script che scrive nel log l'orario in cui si scollegano usando il parametro root postexec. ;)

Tengo a precisare che i parametri root preexec (e root postexec che viene eseguito allo "scollegamento") non sono una prerogativa di netlogon. Possono essere usati con qualunque condivisione per eseguire "qualcosa" al momento del collegamento (e/o dello scollegamento).

Ricordiamoci di rendere eseguibile lo script perl :

sudo chmod 775 /etc/samba/logon.pl

smb.conf completo

E dulcis in fundo ecco il file di configurazione completo da spulciare e studiare. Posso, ad esempio, notare che ho gestito il cestino anche sulle home e autorizzato solo i membri del gruppo "Domain Admins" ad accedere alla condivisione di "servizio" rootdir.

[global]
       workgroup = MEDE
       netbios name = ARCHI
       server string = %h PDC (%v)
       interfaces = eth1, lo
       bind interfaces only = Yes
       passdb backend = ldapsam:ldap://archi.mede.it
       enable privileges = yes
       log level = 0
       log file = /var/log/samba/%m
       max log size = 50
       smb ports = 139 445
       hide dot files = yes
       name resolve order = wins host dns bcast
       time server = Yes
       guest account = guest
       show add printer wizard = No
       add user script = /bin/netuseradd -a -m '%u'
       delete user script = /bin/netuserdel '%u'
       add group script = /bin/netgroupadd -a -p '%g'
       delete group script = /bin/netgroupdel '%g'
       add user to group script = /bin/netgroupmod -m '%u' '%g'
       delete user from group script = /bin/netgroupmod -x '%u' '%g'
       # Disabilitare quando a fare il join al dominio è un Windows NT
       set primary group script = /bin/netusermod -g '%g' '%u'
       add machine script = /bin/netuseradd -w '%u'
       logon script = %U.bat
       # Profili Roaming
       #logon path = \\%L\profiles\%U
       logon path =
       logon home =
       logon drive = K:
       domain logons = Yes
       domain master = yes
       preferred master = Yes
       os level = 65
       wins support = Yes
       # LDAP
       ldap suffix = dc=mede,dc=it
       ldap user suffix = ou=Users
       ldap machine suffix = ou=Computers
       ldap group suffix = ou=Groups
       ldap idmap suffix = ou=Idmap
       ldap admin dn = cn=Manager,dc=mede,dc=it
       idmap backend = ldap:ldap://archi.mede.it
       idmap uid = 10000-20000
       idmap gid = 10000-20000
       ldap passwd sync = Yes
      #ldap ssl = start tls
       ldap ssl = no
       map acl inherit = Yes
       #printing = cups
       lock directory = /var/lock/samba
       winbind use default domain = yes
       winbind enum users = yes
       winbind enum groups = yes
       security = user
       template shell = /bin/false
[public]
       comment = "L: - Cartella Pubblica Utenti"
       path = /samba/public
       writeable = yes
       browseable = Yes
       hide unreadable = Yes
       directory mask = 0775
       create mask = 0775
       force create mode = 0775
       force directory mode = 6775
       security mask = 0777
       force security mode = 0
       directory security mask = 0777
       force directory security mode = 0
       #inherit acls = yes
       #inherit permissions = yes
       vfs objects = recycle
       recycle:repository = .cestino/%U
       recycle:keeptree = yes
       recycle:touch = yes
       recycle:versions= yes
       recycle:exclude = *.tmp *.bak ~$*
       recycle:exclude_dir = /tmp /temp /cache
       recycle:noversions = *.doc *.xls *.ppt
[homes]
       comment = "K: - Cartella privata di %U, %u"
       writeable = yes
       create mask = 0700
       directory mask = 0775
       browseable = No
       force user = %U
       vfs objects = recycle
       recycle:repository = .cestino
       recycle:keeptree = yes
       recycle:touch = yes
       recycle:versions= yes
       recycle:exclude = *.tmp *.bak ~$*
       recycle:exclude_dir = /tmp /temp /cache
       recycle:noversions = *.doc *.xls *.ppte_dir = /tmp /temp /cache
       recycle:noversions = *.doc *.xls *.ppt
[rootdir]
       comment = Cartella globale, solo per amministrazione e backup
       path = /samba
       writeable = yes
       browseable = yes
       directory mask = 0770
       create mask = 0775
       force create mode = 0775
       force directory mode = 6775
       security mask = 0777
       force security mode = 0
       directory security mask = 0777
       admin users = Administrator
       valid users = "@Domain Admins"
       force create mode = 0644
       force directory mode = 6775
[apps]
       comment = "Y: - Applicazioni"
       path = /samba/apps
       writeable = yes
       browseable = Yes
       directory mask = 0770
       create mask = 0775
       security mask = 0777
       force security mode = 0
       directory security mask = 0777
       force directory security mode = 0
       hide unreadable = Yes
       force create mode = 0775
       force directory mode = 6775
[netlogon]
       comment = Network Logon Service
       path = /samba/netlogon
       guest ok = Yes
       locking = No
       browseable = No
       root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"
       #root postexec = /etc/samba/logoff.pl "%U" "%G" "%L" "%T"
[profiles]
       comment = Profile Share
       path = /samba/profiles
       writeable = yes
       profile acls = Yes
       browsable = No

Avvio del servizio

Quasi me ne dimenticavo :)

sudo /etc/rc.d/samba start

e mettiamolo nella lista dei nostri deamons:

DAEMONS=(... ... ... ... ... samba ... ... ...) 

Join al dominio e scripts di manutenzione

Ora che finalmente abbiamo avviato Samba, facciamo la join del server al nostro dominio nuovo fiammante, controlliamo che funzioni e creiamo un paio di script bash utili per la manutenzione del sistema

Join al dominio

Per prima cosa dobbiamo unire il nostro server al dominio (che traduzione orrenda: diciamo che dobbiamo fare la join...), con il comando :

sudo net rpc join -S ARCHI -U Administrator

dopo aver digitato la password dovreste vedere il messaggio:

Joined domain MEDE.

In questa fase Samba ha creato l'account workstation per il vostro server nel suo backend LDAP nel formato nomemacchina$. Andiamo a vedere se è vero con il comando getent:

sudo getent passwd

Alla fine dovrei vedere il mio server :

archi$:*:5004:515:Computer:/dev/null:/bin/false

Ottimo. Passiamo oltre.

Funziona ?

Controlliamo subito. Facciamolo con i comandi di Samba, così siamo sicuri che sia lui a rispondere alle nostre richeste:

sudo pdbedit -L

Dovrebbe mostrarmi la lista degli utenti, tipo questa:

Administrator:0:Administrator
guest:5000:guest
commerciale1:5001:commerciale1
tecnico1:5002:tecnico1
archi$:5004:Computer

e ora controlliamo anche le condivisioni :

sudo smbclient -L localhost -U administrator

e dopo la password dovrei vedere una cosa del tipo :

Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]
        Sharename       Type      Comment
        ---------       ----      -------
        IPC$            IPC       IPC Service (archi PDC (3.0.28))
        print$          Disk      Printer Drivers
        apps            Disk      Y: - Applicazioni
        rootdir         Disk      Cartella globale, solo per amministrazione e backup
        public          Disk      L: - Cartella Pubblica Utenti
        Administrator   Disk      K: - Cartella privata di administrator, Administrator
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]
        Server               Comment
        ---------            -------
        ARCHI                archi PDC (3.0.28)
        Workgroup            Master
        ---------            -------
        MEDE                 ARCHI

Wow! Ce l'abbiamo fatta, il nostro domain controller è pronto ad accogliere le vostre workstation Windows (e Linux off course) tra le sue forti braccia.

Scripts di manutenzione

purge

Predentemente abbiamo abilitato il plugin Samba per gestire il cestino del server: ogni utente che cancella i file in realtà li sposta nella cartella .cestino/nomeutente che abbiamo definito. Capirete anche voi che non possiamo lasciarli lì per sempre ma abbiamo bisogno di purgare i cestini di tanto in tanto per mantenere il sistema pulito dalla spazzatura. Chi ha conosciuto Novell Netware non può non ricordare il comando purge che svolgeva egregiamente questa funzione, purtroppo qui non abbiamo niente di simile, e dobbiamo arrangiarci con bash. Tranquilli, ci ho già pensato io qualche anno fa, niente di eclatante ma svolge la sua funzione in modo preciso. Creiamo il file:

sudo nano /bin/purge

e inseriamoci quanto segue:

#!/bin/bash
# purge
# Vuota il cestino degli utenti e di sistema
# by steno 2005-2007
#
# Controlla i parametri
if [ $# = 0 ]
 then
   echo "uso: purge {all|<username>}"
   exit;
 else
  if [ $1 = 'all' ]
   then
    DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`; 
   else
    DIR=$1;
  fi;
fi;
#
# Vuota il cestino privato degli utenti
#
for user in $DIR; do
  if [ -e /home/$user/.cestino ];
   then
    X="`(cd /home/$user/.cestino ; echo *)`";
    if [ ! "$X" = "*" ] ; then
                echo "Elimina file dal cestino utente <$user>";
                rm /home/$user/.cestino/* -r;
    else
                echo "Cestino personale utente <$user> vuoto";
    fi;
  fi;
done;
#
# Vuota il cestino globale di "public"
#
DIR=`ls /samba/public/.cestino -F | awk '/\/$/ {sub( /\/$/,""); print}'`;
for user in $DIR; do
 X="`(cd /samba/public/.cestino/$user ; echo *)`";
 if [ ! "$X" = "*" ] ; then
  echo "Elimina file dal cestino globale utente <$user>" ;
  rm /samba/public/.cestino/$user -R;
 else
  echo "Cestino globale utente <$user> vuoto";
 fi 
done;

Come vedete possiamo "purgare" tutto con il parametro all o limitarci ad uno specifico utente. Lo script è poi suddiviso in due parti, la prima si occupa del cestino di ogni singola home/user, la seconda del cestino della share principale public. Rendiamo eseguibile lo script:

sudo chmod 755 /bin/purge

e creiamo il Cestino globale dando i permessi corretti alla cartella:

sudo mkdir /samba/public/.cestino
sudo chmod 770  /samba/public/.cestino 
sudo chgrp "Domain Users" /samba/public/.cestino

Ora basta digitare purge all da shell per avviare le pulizie di primavera :), purge tecnico1 per il cestino del solo utente tecnico1. Prendiamo anche in considerazione la possibilità di schedularlo con crontab per avviarlo automaticamente al "calar della notte".

setchown

Questo script si usa meno del precedente, ma in alcuni casi è molto utile. Cosa fà lo script ? Semplice, corregge i permessi su file e directory delle home degli utenti. A volte magari, come amministratore, si ripristinano, copiano o spostano dei file da una cartella di un utente ad un altro e poi dobbiamo manualmente lavorare di chown e chmod per sistemare il tutto. Lo script setchown lo fa da solo spazzolando tutte le home degli utenti (con i parametro all) correggendo permessi e proprietà. Creiamo il file:

sudo nano /bin/setchown 

e inseriamoci quanto segue:

#!/bin/bash
# setchown
# Setta il proprietario della home dir e dei file allo user
# escludi dal processo le home listate nella var "exclude"
exclude="httpd ftp amavis";
# Controlla i parametri
if [ $# = 0 ]
 then
   echo "uso: setchown {all|<username>}"
   exit;
 else
  if [ $1 = 'all' ]
   then
    DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`;
   else
    DIR=$1;
  fi;
fi; 
#
for user in $DIR; do
    mask=${exclude#*$user};
    if [ "$mask" = "$exclude" ]
     then
      chown $user /home/$user -R
      chmod 700 /home/$user
      echo "Permessi corretti in /home/$user";
    fi
done

Anche qui vediamo che possiamo digitare setchown all per tutte le home oppure setchown tecnico1 per la singola home. Non dimentichiamoci di rendere eseguibile lo script:

sudo chmod 755 /bin/setchown

Tenete presente anche la variabile $exclude nello script, in cui dobbiamo inserire la lista delle cartelle in home da non processare. Ho messo "httpd","ftp" e "amavis" che Archlinux ha la malaugurata idea di creare in home (ma /var faceva schifo ?).

Firewall

Ora possiamo riabilitare il firewall. Prima modifichiamo il file rules:

sudo nano /etc/shorewall/rules

e aggiungiamo le nuove regole:

SMB/ACCEPT      $FW             loc
SMB/ACCEPT      loc             $FW

Per riavviare il servizio usiamo il comando shorewall, così vediamo se abbiamo commesso sbagli:

sudo shorewall start

Abbiamo finito ?

In teoria sì, in pratica no. Per domini semplici da pochi utenti potreste essere già ok, ma la realtà è ben diversa dalla teoria e nel proseguo scoprirete uno dei perché con un semplice esempio.

Gestione dei permessi

Seeee, abbiamo il nostro nuovo scintillante domain controller Samba su Archlinux, abbiamo sottomesso i creduloni client windows (avete fatto la join al dominio da windows ? Questo non ve lo spiego mica ...) facendoli illudere di giocare in casa. Ah! Con il petto in fuori ci fregiamo a pieno titolo del grado di "sysnetworksuperexpertadmin". Wow, e cosa ci ferma più? --- Vi fermo io, e con un esempio semplice semplice. Ecco un caso pratico che dimostra ancora una volta, se ce ne fosse bisogno, come fra la teoria e la pratica ... ci sia di mezzo il vostro zelante capo ufficio tecnico.

Raccontiamo una storia.

Gli utenti Windows

Tutti abbiamo abbiamo usato o usiamo tuttora (e perchè no?) Windows. Voglia o no questo sistema operativo rappresenta il motore del 92%-98% (a seconda degli studi) dei PC in questo pianeta. Impossibile non farci i conti. Un tipico utente di questo sistema operativo (e per tipico intendo chi lo usa per lavoro o per gioco senza conoscenze tecniche informatiche) non ha mai avuto a che fare con diritti di accesso e permessi su file o attività del computer. Probabilmente non sanno nemmeno che esistono dato che il 99% dei PC con windows lavorano con Administrator o con un utente equivalente. (Spesso se ci si sottrae a questa regola addirittura certi software non funzionano, quindi candidamente ammetto che pure io in Windows lavoro come Administrator).

Ma quando però scoprono che esistono è la fine, specie se hanno qualche autorità in azienda. "Io voglio vedere i file di Antonio che può vedere quelli Giovanni che però non può cancellare quelli di Lucia. Ok ? " Vengono da voi "sysnetworksuperexpertadmin" e cominciano con queste richieste cambiando idea ogni 2 minuti circa. Vi assicuro che capita, capita...

Un caso pratico

Senza andare sul paradossale presentiamo un caso molto frequente e per niente ingiustificato, e vediamo se riusciamo a risolverlo con Samba. Come dicevo all'inizio, il Responsabile dell'Ufficio Tecnico viene da voi e vi dice:

"Antonio e Giovanni disegnano e amministrano le schede tecniche dei prodotti. Vorrei che salvassero i disegni su L:\prodotti e che Lucia e Maria potessero visualizzarle o inviarle ai clienti senza però poterle cancellare o modificare."

Bhe, richiesta ragionevole direi. Sufficente, però, a metterci in crisi. Vediamo perchè.

Mettamoci la lavoro

Allora, noi abbiamo la condivisione "public" (che i nostri utenti chiamano L:\), creiamo gli utenti, la cartella "prodotti" e un gruppo "Prodotti" che come membri ha Antonio e Giovanni. Cosa già vista, facciamolo il fretta:

sudo netuseradd -a -m Antonio
sudo netpasswd Antonio
sudo netuseradd -a -m Giovanni
sudo netpasswd Giovanni 
sudo netgroupadd -a Prodotti
sudo netgroupmod -m Antonio,Giovanni Prodotti
sudo mkdir /samba/public/prodotti
sudo chmod 770 /samba/public/prodotti
sudo chgrp Prodotti /samba/public/prodotti
sudo chmod g+s /samba/public/prodotti

Bene. Ora Antonio e Giovanni hanno a disposizione L:\prodotti su cui possono leggere e scrivere liberamente senza aver minimamente modificato la configurazione di Samba, ho solo agito su utenti gruppi e permessi sul file system. Andiamo avanti. Per Lucia e Maria creiamo un gruppo "Prodotti-RO" (Read Only):

sudo netuseradd -a -m Lucia
sudo netpasswd Lucia
sudo netuseradd -a -m Maria
sudo netpasswd Maria
sudo netgroupadd -a Prodotti-RO
sudo netgroupmod -m Lucia,Maria Prodotti-RO

E adesso ? Cosa faccio ?

  1. Cambio permessi a /samba/public/prodotti in 775 così gli "altri" possono leggerci ma non scriverci. Sbagliato. Così anche gli utenti del gruppo "Commerciale" che non c'entrano nulla possono leggerci.
  2. Uso i parametri di smb.conf "Read List" e "Write List". Sbagliato. I parametri agiscono su tutta la share/condivisione "public" e hanno la precedenza su quelle del file system. Lucia e Maria non potrebbero scrivere nemmeno su L:\COMUNE.
  3. Faccio una share "prodotti" apposita slegata da "public".Ok, funziona ma a me non piace. Se per ogni caso del genere devo fare una share nuova in breve esaurisco le lettere dell'alfabeto per mapparle e il mio smb.conf diventa un libro. E poi ci hanno richiesto "L:\prodotti", non vorrete mica deluderli ? Con Windows si faceva in due secondi.

Prima che buttiate dalla finestra la vostra spilla di Samba vi dico che la soluzione c'e'. Poco usata e pubblicizzata ma c'e'.

Samba non c'entra

E sì. Samba non c'entra con questa limitazione. Samba poggia i suoi servizi sul file system che trova (ext3 nel mio caso) e fà il possibile per "mascherarlo" ma in questo caso non può nulla. Semplicemente abbiamo scoperto la forte limitazione del meccanismo "tripletta" rwxrwxrwx tipico di unix. Fanno quasi tenerezza se confrontati con la granularità di permessi che riesco a raggiungere con NTFS. Inadeguati. Completamente inadeguati. Ma non penserete mica che nessuno ci abbia fatto caso a questo ? Naturalmente sì, e un bel po' di anni fà.

ACL POSIX

La soluzione al nostro problema passa attraverso una estensione della gestione dei permessi chiamate ACL POSIX. Ancora una bozza, non facili da capire e gestire ma perfettamente funzionanti su Linux. La cosa simpatica è che sulla nostra Arch (su tutte le distro che io sappia) sono già installate e supportate, basta solo attivarle. Editiamo il nostro /etc/fstab :

sudo nano /etc/fstab

e abilitamole specificando il flag "acl" nel mount del nostro file system:

/dev/sda3 / ext3 defaults,acl 0 1

Riavviamo e siamo a posto. Abbiamo le estensioni attivate.

setfacl & getfacl

Questi sono i nostri due nuovi amici, setfacl per settare i permessi estesi e getfacl per visualizzarli. Non stò a spiegare come funzionano in dettaglio le acl posix, c'e' chi lo ha già fatto in modo ottimale. Per approfondire leggete ad esempio qui, oppure qui se preferite la lingua italiana. Questa è la nostra situazione:

drwxrws---  2 root Prodotti     4096 21 dic 15:46 prodotti

Visualizziamola con :

sudo getfacl /samba/public/prodotti

e ottengo questo, non ho attivato alcuna estensione e quindi corrispondono ai normali flag che tutti conosciamo :

# file: samba/public/prodotti
# owner: root
# group: Prodotti
user::rwx
group::rwx
other::---

Ora impostamo i nostri sospirati permessi al gruppo "Prodotti-RO":

sudo setfacl -d -m group:Prodotti-RO:r-x /samba/public/prodotti
sudo setfacl -m group:Prodotti-RO:r-x /samba/public/prodotti

Visualizziamo di nuovo:

sudo getfacl /samba/public/prodotti

e stavolta ottengo questo:

# file: prodotti
# owner: root
# group: Prodotti
user::rwx
group::rwx
group:Prodotti-RO:r-x
mask::rwx
other::---
default:user::rwx
default:group::rwx
default:group:Prodotti-RO:r-x
default:mask::rwx
default:other::---

Bene. Abbiamo dato i permessi di lettura al gruppo "Permessi-RO", impostandoli anche come default. Riappuntiamoci sul petto la nostra spilla di "sysnetworksuperexpertadmin" :). Se adesso riguardiamo la situazione con ls -al vedo questo :

drwxrws---+  2 root Prodotti     4096 21 dic 15:46 prodotti

Il segno '+' alla fine indica che nella cartella prodotti sono attive le estensioni acl posix.

Questa parte non è proprio specifica di Arch, ma serve sopratutto per capire come anche problemi semplici a volte possono farci traballare e desistere se non si hanno delle basi. E se ne potrebbe fare una montagna di esempi come questo, anche qualcuno da cui non se ne esce ... I manuali di Samba in PDF hanno oltre 1200 pagine, e nessuna scritta per niente. La cosa divertente è che leggendoli e studiandoli capite pure come funziona Windows meglio di molti altri. Le ACL Posix sono importanti e hanno un piacevole effetto collaterale (voluto ovviamente): 'possiamo gestire e cambiare i permessi sulle cartelle anche direttamente da Windows. Basta collegarsi con "Administrator" sul dominio da una macchina Windows e con pulsante destro->proprieta->protezione sulla cartella "prodotti" vedo le permissions ACL Posix che posso pure cambiare: Samba si occuperà del comando setfacl corrispondente.

Ma voi preferite la shell vero ?

Conclusioni

Terminiamo qui la parte File Server. Si potrebbe continuare per non sò quanto, ma tutto quello che potremmo dire sarebbe "Off Topic" in questa guida incentrata su ArchLinux. Tutto "il di più" sarebbe qualcosa di cross distro (sì può dire ?) ed esistono già valide guide sul web. Limitiamoci allora ad una lista di cose che potrebbero risultare utili e su cui magari sarebbe oppurtuno approfondire in modo autonomo.

Print services

Non abbiamo minimamente parlato delle condivisioni delle stampanti. Qui si aprirebbe un altro fronte che coinvolge CUPS e la distribuzione automatica dei drivers stampante ai client Windows. Samba supporta questa funzionalità, e il posto migliore dove apprendere questa tecnica sono le guide ufficiali. Io personalmente non l'ho mai implementato non per pigrizia ma per le oramai onnipresenti stampanti con scheda di rete integrata a cui i client inviano direttamente le stampe. Tuttavia una sbirciatina non fà male.

Client grafici di amministrazione

Abbiamo già visto come sia possibile da Windows amministrare le permissions sulle share Samba. Esistono anche delle GUI che ci permettono di gestire utenti e password in modo semplice, specie se le opzioni da settare sono un po' esotiche, tipo la scadenza della password o la lista delle workstation da cui un utente può fare il logon. Ne esistono diversi, dall'ufficale Samba Web Adiministration Tool (SWAT) all' LDAP Account Manager. Possiamo usarne anche da Windows, ad esempio dal mio preferito (forse perchè fatto con Delphi ?) LDAP Admin, allo User Manager for Domains "ufficiale" fornito da Microsoft (non è uno scherzo) per amministrare i vari aspetti e flag.

Quota

Altro aspetto interessante è la gestione delle Disk Quota da assegnare ad utenti e gruppi. Questo, come per le ACL Posix, è un "affare" anche del file system, oltre che di Samba con il vfs objects = default_quota.

Dopo averli installati con

sudo pacman -S quota-tools

Potete trovare informazioni sulla parte file system su come amministrarli e configurarli in giro per la rete, ad esempio qui. Per la parte Samba naturalmente la solita "bibbia" rappresentata dalle guide ufficiali.

Comandi Samba

Samba viene fornito con una serie di comandi utili all'amministratore, da pdbedit per amministrare utenti e gruppi alla pletora dei comandi net disponibili. Facciamo un paio di esempi, con il comando:

sudo net rpc rights list -U Administrator

ottengo questo:

    SeMachineAccountPrivilege  Add machines to domain
     SeTakeOwnershipPrivilege  Take ownership of files or other objects
            SeBackupPrivilege  Back up files and directories
           SeRestorePrivilege  Restore files and directories
    SeRemoteShutdownPrivilege  Force shutdown from a remote system
     SePrintOperatorPrivilege  Manage printers
          SeAddUsersPrivilege  Add users and groups to the domain
      SeDiskOperatorPrivilege  Manage disk shares

e vedo i permessi dell'utente Administrator. Potrei voler assegnare una "right" di amministrazione a qualche altro utente, e questo si fà con i comandi net rpc right. Se digito :

sudo pdbedit -L -v Antonio

Ottengo

Unix username:        antonio
NT username:          antonio
Account Flags:        [UX         ]
User SID:             S-1-5-21-1491279793-2809991009-2777690449-11012
Primary Group SID:    S-1-5-21-1491279793-2809991009-2777690449-513
Full Name:            antonio
Home Directory:
HomeDir Drive:        K:
Logon Script:         antonio.bat
Profile Path:
Domain:               MEDE
Account desc:
Workstations:
Munged dial:
Logon time:           0
Logoff time:          never
Kickoff time:         never
Password last set:    0
Password can change:  0
Password must change: 0
Last bad password   : 0
Bad password count  : 0
Logon hours         : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

che sono tutte le impostazioni assegnate all'utente Antonio e che posso variare con pdbedit. Gran parte di queste le posso anche amministrare con il nostro netusermod, ma sicuramente il comando standard è più completo essendo parte di Samba.

I comandi man net e man pdbedit forniscono le informazioni di cui si ha bisogno.

Lock sui file

Stiamo amministrando un server con dei file condivisi, quindi il lock dei file è cosa vitale. In genere non ci sono problemi, Samba "standard" ci risolve già gran parte dei problemi, ma in alcuni casi (tipo il "solito" file access mdb condiviso) dovete metter manina voi. Vi scontrerete ad esempio con il concetto di "Opportunistic Locking" inventato da Microsoft per aumentare le performance in rete, ma che in alcuni casi con Samba non produce gli effetti desiderati. Niente paura, vanno solo gestiti. Anche in questo caso (son stufo di scriverlo) vi rimando alla guida ufficiale.

Sicurezza

Non abbiamo nemmeno discusso della messa in sicurezza del colloquio tra Samba e OpenLDAP che adesso avviene in chiaro. Essendo entrambi i servizi nella stessa macchina magari il problema e minimo, ma se cominciate ad avere più server Samba che "puntano" allo stesso server LDAP o più server LDAP replicati magari in remoto tra sedi diverse è una opzione da prendere in seria considerazione.

Client Linux

O perbacco ! E i client Linux ? Qualcuno comincerà ad arrivare... Per le autenticazioni LDAP e le share non credo sia un problema (anche se devo ogni volta digitare utente e password), ma il logon ad un dominio Microsoft ? Ho visto solo due distro che lo fanno: SLED e la sua controparte libera OpenSUSE. Quindi è possibile ma mi sento proprio impreparato sull'argomento. Fatemi sapere voi magari.

Concludiamo managgia !

Dite la verità: Pensavate fosse più semplice. O almeno è quello che ho pensato io la prima volta che mi sono imbattuto in questi argomenti. Spero di aver acceso l'interesse di qualcuno che abbia la voglia studiare, la rete offre tutto di cui si ha bisogno. E credetemi, se imparate bene ad amministrare LOS (Linux Openldap Samba) amigos (senza dimenticare DNS/DHCP) domani (quasi) potete installare una rete con Windows, perchè i concetti li conoscete (anche più in profondità di altri), dovete solo scoprire dove fare "click" con il mouse (uaaaah, questa forse è grossa ma suona bene :)).

Ma che bello era fare "Pulsante destro sulla cartella -> convidi con nome -> ok " ?