Si applica a SUSE Enterprise Storage 7.1

24 Esportazione dei dati Ceph tramite Samba #

Questo capitolo descrive come esportare i dati memorizzati in un cluster Ceph tramite una condivisione Samba/CIFS per potervi accedere con facilità dai computer client Windows*. Contiene inoltre informazioni utili per la configurazione di un gateway Samba Ceph in modo che si unisca ad Active Directory nel dominio Windows* per eseguire l'autenticazione e l'autorizzazione degli utenti.

Nota: prestazioni del gateway Samba

A causa dell'aumento dell'overhead del protocollo e della latenza aggiuntiva causati dagli hop di rete extra tra il client e lo storage, l'accesso a CephFS tramite un gateway Samba potrebbe ridurre notevolmente le prestazioni dell'applicazione rispetto ai client Ceph nativi.

24.1 Esportazione di CephFS tramite la condivisione Samba #

Avvertimento: accesso su più protocolli

I client CephFS e NFS nativi non sono limitati dai blocchi di file ottenuti tramite Samba e viceversa. I dati delle applicazioni basate sul blocco di file su più protocolli potrebbero risultare danneggiati se l'accesso ai percorsi della condivisione Samba supportati da CephFS viene effettuato in altri modi.

24.1.1 Configurazione ed esportazione dei pacchetti Samba #

Per configurare ed esportare una condivisione Samba, è necessario che siano installati i pacchetti seguenti: samba-ceph e samba-winbind. Installarli se non lo sono:

cephuser@smb > zypper install samba-ceph samba-winbind

24.1.2 Esempio di gateway singolo #

Per prepararsi all'esportazione di una condivisione Samba, scegliere un nodo appropriato da utilizzare come gateway Samba. Il nodo deve disporre dell'accesso alla rete del client Ceph, oltre che di sufficienti risorse di CPU, memoria e networking.

La funzionalità di failover può essere fornita con CTDB e SUSE Linux Enterprise High Availability Extension. Per ulteriori informazioni sulla configurazione ad alta disponibilità, fare riferimento alla Sezione 24.1.3, «Configurazione dell'elevata disponibilità».

Accertare che nel cluster sia già esistente un CephFS operativo.

Creare un portachiavi gateway Samba specifico sul nodo admin Ceph e copiarlo in entrambi i nodi gateway Samba:

cephuser@adm > ceph auth get-or-create client.samba.gw mon 'allow r' \
 osd 'allow *' mds 'allow *' -o ceph.client.samba.gw.keyring
cephuser@adm > scp ceph.client.samba.gw.keyring SAMBA_NODE:/etc/ceph/

Sostituire SAMBA_NODE con il nome del nodo gateway Samba.

I passaggi seguenti vengono eseguiti sul nodo gateway Samba. Installare Samba insieme al pacchetto di integrazione Ceph:
```
cephuser@smb > sudo zypper in samba samba-ceph
```
Sostituire i contenuti di default del file /etc/samba/smb.conf con quanto segue:
```
[global]
  netbios name = SAMBA-GW
  clustering = no
  idmap config * : backend = tdb2
  passdb backend = tdbsam
  # disable print server
  load printers = no
  smbd: backgroundqueue = no

[SHARE_NAME]
  path = CEPHFS_MOUNT
  read only = no
  oplocks = no
  kernel share modes = no
```
Il percorso CEPHFS_MOUNT riportato sopra deve essere montato prima dell'avvio di Samba con una configurazione di condivisione del kernel CephFS. Vedere Sezione 23.3, «Montaggio di CephFS in /etc/fstab».
La configurazione di condivisione sopra utilizza il client CephFS del kernel Linux, consigliato per motivi di prestazioni. In alternativa, è possibile utilizzare anche il modulo vfs_ceph Samba per la comunicazione con il cluster Ceph. Le istruzioni sono riportate di seguito per scopi di legacy e non sono consigliate per nuove le distribuzioni Samba:
```
[SHARE_NAME]
  path = /
  vfs objects = ceph
  ceph: config_file = /etc/ceph/ceph.conf
  ceph: user_id = samba.gw
  read only = no
  oplocks = no
  kernel share modes = no
```
Suggerimento: oplocks e modalità di condivisione
Gli oplocks (noti anche come lease SMB2+) consentono di ottenere migliori prestazioni tramite un'aggressiva memorizzazione nella cache del client, ma sono poco sicuri se Samba è distribuito con altri client CephFS, come mount.ceph, FUSE o NFS Ganesha del kernel.
Se l'accesso al percorso del file system CephFS è gestito esclusivamente da Samba, è possibile abilitare il parametro degli oplocks in sicurezza.
Attualmente, è necessario disabilitare kernel share modes nelle condivisioni in esecuzione con il modulo vfs di CephFS per consentire il corretto funzionamento del file serving.
Importante: autorizzazione dell'accesso
Samba mappa gli utenti e i gruppi SMB agli account locali. È possibile assegnare agli utenti locali una password per l'accesso alla condivisione Samba tramite:
```
# smbpasswd -a USERNAME
```
Per operazioni I/O corrette, l'elenco di controllo dell'accesso (ACL) del percorso della condivisione deve consentire l'accesso all'utente connesso tramite Samba. È possibile modificare l'ACL effettuando un montaggio temporaneo tramite il client del kernel CephFS e utilizzando le utility chmod, chown o setfacl rispetto al percorso della condivisione. Ad esempio, per consentire l'accesso a tutti gli utenti, eseguire:
```
# chmod 777 MOUNTED_SHARE_PATH
```

24.1.2.1 Avvio dei servizi Samba #

Avviare o riavviare i servizi Samba stand-alone utilizzando i comandi seguenti:

# systemctl restart smb.service
# systemctl restart nmb.service
# systemctl restart winbind.service

Per assicurarsi che i servizi Samba vengano avviati al momento dell'avvio, abilitarli tramite:

# systemctl enable smb.service
# systemctl enable nmb.service
# systemctl enable winbind.service

Suggerimento: servizi nmb e winbind facoltativi

Se non è necessaria l'esplorazione di condivisione di rete, non occorre abilitare e avviare il servizio nmb.

Il servizio winbind è necessario soltanto se viene configurato come membro del dominio Active Directory. Vedere Sezione 24.2, «Unione di gateway Samba e Active Directory».

24.1.3 Configurazione dell'elevata disponibilità #

Importante: failover invisibile all'utente non supportato

Sebbene la disponibilità della distribuzione multi-nodo Samba + CTDB sia molto più elevata rispetto a quella a nodo singolo (vedere il Capitolo 24, Esportazione dei dati Ceph tramite Samba), il failover invisibile all'utente lato client non è supportato. In caso di errore del nodo gateway Samba, è probabile che si verifichi una breve interruzione delle attività delle applicazioni.

Questa sezione fornisce un esempio di come configurare una configurazione ad alta disponibilità a due nodi dei server Samba. La configurazione richiede SUSE Linux Enterprise High Availability Extension. I due nodi sono denominati earth (192.168.1.1) e mars (192.168.1.2).

Per informazioni su SUSE Linux Enterprise High Availability Extension, vedere https://documentation.suse.com/sle-ha/15-SP1/.

Inoltre, due indirizzi IP virtuali mobili consentono ai client di connettersi al servizio indipendentemente dal nodo fisico sul quale è in esecuzione. 192.168.1.10 è utilizzato per amministrazione del cluster con Hawk2 e 192.168.2.1 esclusivamente per esportazioni CIFS. Ciò semplifica la successiva applicazione delle limitazioni di sicurezza.

La procedura seguente descrive l'installazione di esempio. Ulteriori informazioni sono disponibili all'indirizzo https://documentation.suse.com/sle-ha/15-SP1/single-html/SLE-HA-install-quick/.

Creare un portachiavi gateway Samba specifico sul nodo admin e copiarlo su entrambi i nodi:

cephuser@adm > ceph auth get-or-create client.samba.gw mon 'allow r' \
    osd 'allow *' mds 'allow *' -o ceph.client.samba.gw.keyring
cephuser@adm > scp ceph.client.samba.gw.keyring earth:/etc/ceph/
cephuser@adm > scp ceph.client.samba.gw.keyring mars:/etc/ceph/

La configurazione SLE ad elevata disponibilità richiede un dispositivo di isolamento per evitare una situazione split-brain quando i nodi del cluster attivi non sono più sincronizzati. A questo scopo, è possibile utilizzare un'immagine RBD Ceph con il dispositivo di blocco Stonith (SBD, Stonith Block Device). Per ulteriori dettagli, fare riferimento a https://documentation.suse.com/sle-ha/15-SP1/single-html/SLE-HA-guide/#sec-ha-storage-protect-fencing-setup.
Se non è ancora esistente, creare un pool RBD denominato rbd (vedere la Sezione 18.1, «Creazione di un pool») e associarlo a rbd (vedere la Sezione 18.5.1, «Associazione di pool a un'applicazione»). Quindi, creare un'immagine RBD correlata chiamata sbd01:
```
cephuser@adm > ceph osd pool create rbd
cephuser@adm > ceph osd pool application enable rbd rbd
cephuser@adm > rbd -p rbd create sbd01 --size 64M --image-shared
```
Preparare earth e mars per ospitare il servizio Samba:
1. Prima di continuare, verificare che siano installati i seguenti pacchetti: ctdb, tdb-tools e samba.
```
# zypper in ctdb tdb-tools samba samba-ceph
```
2. Assicurarsi che i servizi Samba e CTDB siano interrotti e disabilitati:
```
# systemctl disable ctdb
# systemctl disable smb
# systemctl disable nmb
# systemctl disable winbind
# systemctl stop ctdb
# systemctl stop smb
# systemctl stop nmb
# systemctl stop winbind
```
3. Aprire la porta 4379 del firewall su tutti i nodi. Questo passaggio è necessario affinché CTDB comunichi con altri nodi del cluster.
Su earth, creare i file di configurazione per Samba, che verranno in seguito sincronizzati con mars.
1. Inserire un elenco di indirizzi IP privati dei nodi del gateway Samba nel file /etc/ctdb/nodes. Alla pagina della documentazione (man 7 ctdb) sono disponibili ulteriori dettagli.
```
192.168.1.1
192.168.1.2
```
2. Configurare Samba. Aggiungere le righe seguenti nella sezione [global] di /etc/samba/smb.conf. Utilizzare il nome host prescelto al posto di CTDB-SERVER (tutti i nodi del cluster compaiono in effetti come un grande nodo con questo nome). Aggiungere inoltre una definizione della condivisione, ad esempio SHARE_NAME:
```
[global]
  netbios name = SAMBA-HA-GW
  clustering = yes
  idmap config * : backend = tdb2
  passdb backend = tdbsam
  ctdbd socket = /var/lib/ctdb/ctdb.socket
  # disable print server
  load printers = no
  smbd: backgroundqueue = no

[SHARE_NAME]
  path = /
  vfs objects = ceph
  ceph: config_file = /etc/ceph/ceph.conf
  ceph: user_id = samba.gw
  read only = no
  oplocks = no
  kernel share modes = no
```
  Tenere presente che i file /etc/ctdb/nodes e /etc/samba/smb.conf devono corrispondere in tutti i nodi gateway Samba.
Installare ed eseguire il bootstrap del cluster SUSE Linux Enterprise High Availability.
1. Registrare SUSE Linux Enterprise High Availability Extension su earth e mars:
```
root@earth # SUSEConnect -r ACTIVATION_CODE -e E_MAIL
```
```
root@mars # SUSEConnect -r ACTIVATION_CODE -e E_MAIL
```
2. Installare ha-cluster-bootstrap su entrambi i nodi:
```
root@earth # zypper in ha-cluster-bootstrap
```
```
root@mars # zypper in ha-cluster-bootstrap
```
3. Mappare l'immagine RBD sbd01 a entrambi i gateway Samba tramite rbdmap.service.
  Modificare /etc/ceph/rbdmap e aggiungere una voce per l'immagine SBD:
```
rbd/sbd01 id=samba.gw,keyring=/etc/ceph/ceph.client.samba.gw.keyring
```
  Abilitare e avviare rbdmap.service:
```
root@earth # systemctl enable rbdmap.service && systemctl start rbdmap.service
root@mars # systemctl enable rbdmap.service && systemctl start rbdmap.service
```
  Il dispositivo /dev/rbd/rbd/sbd01 deve essere disponibile su entrambi i gateway Samba.
4. Inizializzare il cluster su earth e lasciare che mars si unisca.
```
root@earth # ha-cluster-init
```
```
root@mars # ha-cluster-join -c earth
```
  Importante
  Durante il processo di inizializzazione e unione del cluster, verrà richiesto se si desidera utilizzare SBD. Confermare con y e specificare /dev/rbd/rbd/sbd01 come percorso al dispositivo di memorizzazione.

Verificare lo stato del cluster. Dovrebbero essere visibili due nodi aggiunti al cluster:

root@earth # crm status
2 nodes configured
1 resource configured

Online: [ earth mars ]

Full list of resources:

 admin-ip       (ocf::heartbeat:IPaddr2):       Started earth

Eseguire i comandi seguenti su earth per configurare la risorsa CTDB:

root@earth # crm configure
crm(live)configure# primitive ctdb ocf:heartbeat:CTDB params \
    ctdb_manages_winbind="false" \
    ctdb_manages_samba="false" \
    ctdb_recovery_lock="!/usr/lib64/ctdb/ctdb_mutex_ceph_rados_helper
        ceph client.samba.gw cephfs_metadata ctdb-mutex"
    ctdb_socket="/var/lib/ctdb/ctdb.socket" \
        op monitor interval="10" timeout="20" \
        op start interval="0" timeout="200" \
        op stop interval="0" timeout="100"
crm(live)configure# primitive smb systemd:smb \
    op start timeout="100" interval="0" \
    op stop timeout="100" interval="0" \
    op monitor interval="60" timeout="100"
crm(live)configure# primitive nmb systemd:nmb \
    op start timeout="100" interval="0" \
    op stop timeout="100" interval="0" \
    op monitor interval="60" timeout="100"
crm(live)configure# primitive winbind systemd:winbind \
    op start timeout="100" interval="0" \
    op stop timeout="100" interval="0" \
    op monitor interval="60" timeout="100"
crm(live)configure# group g-ctdb ctdb winbind nmb smb
crm(live)configure# clone cl-ctdb g-ctdb meta interleave="true"
crm(live)configure# commit

Suggerimento: Primitive nmb e winbind facoltativi

Se non è necessaria l'esplorazione di condivisione di rete, non occorre aggiungere il primitive nmb.

Il primitive winbind è necessario soltanto se viene configurato come membro del dominio Active Directory. Vedere Sezione 24.2, «Unione di gateway Samba e Active Directory».

Il binario /usr/lib64/ctdb/ctdb_mutex_ceph_rados_helper nell'opzione di configurazione ctdb_recovery_lock ha i parametri CLUSTER_NAME, CEPHX_USER, RADOS_POOL, e RADOS_OBJECT in questo ordine.

È possibile aggiungere un ulteriore parametro di timeout del blocco per ignorare il valore di default utilizzato (10 secondi). Un valore più elevato consentirà di aumentare la durata di failover del master di recupero CTDB, mentre se viene impostato un valore più basso, il master di recupero potrebbe venire rilevato erroneamente come disattivato, innescando ripetutamente il failover.

Aggiungere un indirizzo IP di cluster:

crm(live)configure# primitive ip ocf:heartbeat:IPaddr2
    params ip=192.168.2.1 \
    unique_clone_address="true" \
    op monitor interval="60" \
    meta resource-stickiness="0"
crm(live)configure# clone cl-ip ip \
    meta interleave="true" clone-node-max="2" globally-unique="true"
crm(live)configure# colocation col-with-ctdb 0: cl-ip cl-ctdb
crm(live)configure# order o-with-ctdb 0: cl-ip cl-ctdb
crm(live)configure# commit

Se unique_clone_address è impostato su true, l'agente della risorsa IPaddr2 aggiunge un ID clone all'indirizzo specificato, portando a tre diversi indirizzi IP, che non sono di solito necessari, ma aiutano per il bilanciamento di carico. Per ulteriori informazioni su questo argomento, vedere https://documentation.suse.com/sle-ha/15-SP1/single-html/SLE-HA-guide/#cha-ha-lb.

Controllare il risultato:

root@earth # crm status
Clone Set: base-clone [dlm]
     Started: [ factory-1 ]
     Stopped: [ factory-0 ]
 Clone Set: cl-ctdb [g-ctdb]
     Started: [ factory-1 ]
     Started: [ factory-0 ]
 Clone Set: cl-ip [ip] (unique)
     ip:0       (ocf:heartbeat:IPaddr2):       Started factory-0
     ip:1       (ocf:heartbeat:IPaddr2):       Started factory-1

Eseguire un test da un computer client. Su un client Linux, eseguire il seguente comando per vedere se è possibile copiare i file dal e nel sistema:
```
# smbclient //192.168.2.1/myshare
```

24.1.3.1 Riavvio delle risorse Samba ad elevata disponibilità #

Se la configurazione di Samba o CTBD viene modificata, potrebbe essere necessario riavviare le risorse ad elevata disponibilità per applicare tali modifiche. Questa operazione può essere eseguita tramite:

# crm resource restart cl-ctdb

24.2 Unione di gateway Samba e Active Directory #

È possibile configurare il gateway Samba Ceph come membro del dominio Samba con supporto Active Directory (AD). In qualità di membro del dominio Samba, è possibile utilizzare nei file e nelle directory del CephFS esportato i gruppi e gli utenti di dominio riportati negli elenchi di controllo dell'accesso (ACL) locali.

24.2.1 Preparazione dell'installazione di Samba #

Questa sezione presenta la procedura preliminare da seguire prima della configurazione di Samba. Se si inizia da un ambiente pulito, sarà possibile evitare confusione e assicurarsi che nessun file dell'installazione Samba precedente venga mischiato con la nuova installazione del membro del dominio.

Suggerimento: sincronizzazione degli orologi

Tutti gli orologi dei nodi gateway Samba devono essere sincronizzati con il controller del dominio Active Directory. Gli sfasamenti di orario possono comportare errori di autenticazione.

Verificare che non siano in esecuzione processi di Samba o di memorizzazione dei nomi nella cache:

cephuser@smb > ps ax | egrep "samba|smbd|nmbd|winbindd|nscd"

Se nell'output vengono elencati i processi samba, smbd, nmbd, winbindd o nscd, interromperli.

Se in precedenza è stata eseguita un'installazione Samba su questo host, rimuovere il file /etc/samba/smb.conf. Rimuovere inoltre tutti i file di database Samba, ad esempio i file *.tdb and *.ldb. Per visualizzare un elenco delle directory contenenti i database Samba, eseguire:

cephuser@smb > smbd -b | egrep "LOCKDIR|STATEDIR|CACHEDIR|PRIVATE_DIR"

24.2.2 Verifica del DNS #

Active Directory (AD) utilizza il DNS per individuare altri controller del dominio (DC) e servizi, come Kerberos. Pertanto, i membri del domino e i server Active Directory devono essere in grado di risolvere le zone DNS di Active Directory.

Verificare che il DNS sia configurato correttamente e che la ricerca diretta e inversa vengano risolte correttamente, ad esempio:

cephuser@adm > nslookup DC1.domain.example.com
Server:         10.99.0.1
Address:        10.99.0.1#53

Name:   DC1.domain.example.com
Address: 10.99.0.1

cephuser@adm > 10.99.0.1
Server:        10.99.0.1
Address:	10.99.0.1#53

1.0.99.10.in-addr.arpa	name = DC1.domain.example.com.

24.2.3 Risoluzione dei record SRV #

Active Directory utilizza i record SRV per l'individuazione dei servizi, come Kerberos e LDAP. Per verificare che i record SRV vengano risolti correttamente, utilizzare la shell interattiva nslookup, ad esempio:

cephuser@adm > nslookup
Default Server:  10.99.0.1
Address:  10.99.0.1

> set type=SRV
> _ldap._tcp.domain.example.com.
Server:  UnKnown
Address:  10.99.0.1

_ldap._tcp.domain.example.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = dc1.domain.example.com
domain.example.com      nameserver = dc1.domain.example.com
dc1.domain.example.com  internet address = 10.99.0.1

24.2.4 Configurazione di Kerberos #

Samba supporta i back-end Heimdal e MIT Kerberos. Per configurare Kerberos sul membro del dominio, impostare quanto segue nel file /etc/krb5.conf:

[libdefaults]
	default_realm = DOMAIN.EXAMPLE.COM
	dns_lookup_realm = false
	dns_lookup_kdc = true

Nell'esempio precedente Kerberos viene configurato per il dominio DOMAIN.EXAMPLE.COM. Non si consiglia di impostare altri parametri nel file /etc/krb5.conf. Se il file /etc/krb5.conf contiene una riga include, non funzionerà: occorre rimuovere tale riga.

24.2.5 Risoluzione del nome host locale #

Quando viene eseguita l'unione a un host sul dominio, Samba tenta di registrare il nome host nella zona DNS di Active Directory. A questo scopo, l'utility net deve essere in grado di risolvere il nome host tramite DNS o utilizzando una voce corretta nel file /etc/hosts.

Per verificare che il nome host venga risolto correttamente, utilizzare il comando getent hosts:

cephuser@adm > getent hosts example-host
10.99.0.5      example-host.domain.example.com    example-host

Il nome host e il nome di dominio completo (FQDN) non devono identificarsi con l'indirizzo IP 127.0.0.1 o altri indirizzi IP diversi da quello utilizzato nell'interfaccia LAN del membro del domino. Se non viene visualizzato nessun output o se l'host viene risolto sull'indirizzo IP errato e DHCP non è in uso, impostare la voce corretta nel file /etc/hosts:

127.0.0.1      localhost
10.99.0.5      example-host.samdom.example.com    example-host

Suggerimento: DHCP ed /etc/hosts

Se si utilizza DHCP, verificare che la riga "127.0.0.1" sia presente soltanto in /etc/hosts. Se continuano a verificarsi problemi, contattare l'amministratore del server DHCP.

Se occorre aggiungere alias al nome host del computer, aggiungerli alla fine della riga che inizia con l'indirizzo IP del computer (non alla riga "127.0.01").

24.2.6 Configurazione di Samba #

Questa sezione fornisce informazioni sulle specifiche opzioni di configurazione da includere nel di configurazione di Samba.

L'appartenenza al dominio Active Directory è configurata principalmente tramite l'impostazione di security = ADS insieme al dominio Kerberos e ai parametri di mappatura ID appropriati nella sezione [global] di /etc/samba/smb.conf.

[global]
  security = ADS
  workgroup = DOMAIN
  realm = DOMAIN.EXAMPLE.COM
  ...

24.2.6.1 Scelta del back-end per la mappatura ID in `winbindd` #

Se è necessario assegnare agli utenti diverse shell di login e/o diversi percorsi alla home directory Unix o se si desidera invece che gli utenti abbiano lo stesso ID in generale, utilizzare il back-end "ad" winbind e aggiungere gli attributi RFC2307 ad Active Directory.

Importante: attributi RFC2307 e numeri di ID

Gli attributi RFC2307 non vengono aggiunti automaticamente durante la creazione di utenti o gruppi.

I numeri di ID rilevati su un controller del dominio (compresi nell'intervallo di 3000000) non sono attributi RFC2307 e non verranno utilizzati nei membri del dominio Unix. Se si necessita degli stessi numeri di ID in generale, aggiungere gli attributi uidNumber e gidNumber ad Active Directory e utilizzare il back-end "ad" winbind nei membri del dominio Unix. Se si decide di aggiungere gli attributi uidNumber e gidNumber ad Active Directory, non utilizzare i numeri nell'intervallo di 3000000.

Se gli utenti utilizzeranno il controller del dominio di Active Directory Samba soltanto per scopi di autenticazione e non per la memorizzazione dei dati o per eseguire il login, è possibile utilizzare il back-end "rid" winbind. Ciò consente di calcolare gli ID utente e gruppo dal RID Windows*. Se si utilizza la stessa sezione [global] di smb.conf in ogni membro del dominio Unix, si otterranno gli stessi ID. Se si utilizza il back-end "rid", non è necessario aggiungere nulla ad Active Directory e gli attributi RFC2307 verranno ignorati. Se si utilizza il back-end "rid", impostare i parametri template shell e template homedir in smb.conf. Queste impostazioni sono globali e tutti gli utenti ottengono la stessa shell di login e lo stesso percorso della home directory Unix (a differenza degli attributi RFC2307, in cui è possibile impostare shell e percorsi alla home directory Unix individuali).

È disponibile un'altra modalità di configurazione di Samba, relativa allo scenario in cui è necessario che gli utenti e i gruppi abbiano lo stesso ID in generale, ma che soltanto gli utenti dispongano della stessa shell di login e utilizzino lo stesso percorso della home directory Unix. In questo caso vengono utilizzati il back-end "ad" winbind e le righe modello in smb.conf. In questo modo, è necessario soltanto aggiungere gli attributi uidNumber e gidNumber ad Active Directory.

Suggerimento: ulteriori informazioni sui back-end per la mappatura degli ID

Altri dettagli e sui back-end di mappatura degli ID sono disponibili nella relativa documentazione: man 8 idmap_ad, man 8 idmap_rid e man 8 idmap_autorid.

24.2.6.2 Impostazione degli intervalli di ID utente e gruppo #

Dopo aver individuato il back-end winbind da utilizzare, è necessario specificare gli intervalli da applicare con l'opzione idmap config in smb.conf. Per default, su un membro del dominio Unix, sono presenti più blocchi di ID utente e gruppo:

Tabella 24.1: Blocchi ID utente e gruppo di default #

ID	Intervallo
0-999	Utenti e gruppi di sistema locali.
A partire da 1000	Utenti e gruppi Unix locali.
A partire da 10000	Utenti e gruppi DOMAIN.

Come è possibile vedere dagli intervalli riportati sopra, è consigliabile non far iniziare gli intervalli "*" o "DOMAIN" da un valore inferiore a 999, poiché potrebbero interferire con gli utenti e i gruppi di sistema locali. Dal momento che è consigliabile inoltre lasciare uno spazio per gli utenti e i gruppi Unix locali, un buon compromesso è far iniziare gli intervalli idmap config da 3000.

È necessario stabilire un valore potenziale relativo alla crescita di "DOMAIN" e se si intendono creare domini attendibili. Quindi, è possibile impostare gli intervalli idmap config come segue:

Tabella 24.2: Intervalli ID #

Dominio	Intervallo
*	3000-7999
DOMINIO	10000-999999
TRUSTED	1000000-9999999

24.2.6.3 Mappatura dell'account dell'amministratore del dominio all'utente `root` locale #

Samba consente di mappare gli account di dominio a un account locale. Utilizzare questa funzione per eseguire operazioni di file sul file system del membro del domino come utente diverso dall'account che ha richiesto l'operazione sul client.

Suggerimento: mappatura dell'amministratore del dominio (facoltativo)

La mappatura dell'amministratore del dominio all'account root locale è facoltativa. Configurarla solo se l'amministratore del dominio deve poter eseguire operazioni di file sul membro del dominio tramite le autorizzazioni root. Tenere presente che la mappatura dell'amministratore all'account root non consente di eseguire il login come "Amministratore" ai membri del dominio Unix.

Per mappare l'amministratore del dominio all'account root locale, seguire la procedura indicata di seguito:

Aggiungere il parametro seguente alla sezione [global] del file smb.conf:
```
username map = /etc/samba/user.map
```
Creare il file /etc/samba/user.map con il contenuto seguente:
```
!root = DOMAIN\Administrator
```

Importante

Se si utilizza il back-end di mappatura ID "ad", non impostare l'attributo uidNumber per l'account dell'amministratore del dominio. Se tale attributo è impostato per l'account, il valore sostituisce l'UID "0" locale dell'utente root e la mappatura non riesce.

Per ulteriori dettagli, vedere il parametro username map nella documentazione smb.conf (man 5 smb.conf).

24.2.7 Unione al dominio Active Directory #

Per unire l'host a un'Active Directory, eseguire:

cephuser@smb > net ads join -U administrator
Enter administrator's password: PASSWORD
Using short domain name -- DOMAIN
Joined EXAMPLE-HOST to dns domain 'DOMAIN.example.com'

24.2.8 Configurazione del Name Service Switch #

Per rendere gli utenti e i gruppi del domino disponibili sul sistema locale, è necessario abilitare la libreria Name Service Switch (NSS). Aggiungere la voce winbind ai database seguenti nel file /etc/nsswitch.conf:

passwd: files winbind
group:  files winbind

Importante: aspetti da considerare

Mantenere la voce files come prima origine di entrambi i database. In questo modo, NSS cercherà gli utenti e i gruppi del dominio nei file /etc/passwd e /etc/group prima di interrogare il servizio winbind.
Non aggiungere la voce winbind al database shadow di NSS, poiché potrebbe causare un errore dell'utility wbinfo.
Non utilizzare gli stessi nomi utente nel file /etc/passwd locale e nel dominio.

24.2.9 Avvio dei servizi #

In seguito alle modifiche della configurazione, riavviare i servizi Samba come descritto nella Sezione 24.1.2.1, «Avvio dei servizi Samba» o nella Sezione 24.1.3.1, «Riavvio delle risorse Samba ad elevata disponibilità».

24.2.10 Test della connettività di `winbindd` #

24.2.10.1 Invio di un ping `winbindd` #

Per verificare se il servizio winbindd è in grado di eseguire la connessione ai controller del dominio (DC) Active Directory o a un controller di dominio primario (PDC), immettere:

cephuser@smb > wbinfo --ping-dc
checking the NETLOGON for domain[DOMAIN] dc connection to "DC.DOMAIN.EXAMPLE.COM" succeeded

Se il comando precedente non riesce, verificare che il servizio winbindd sia in esecuzione e che il file smb.conf sia configurato correttamente.

24.2.10.2 Ricerca di utenti e gruppi del dominio #

Tramite la libreria libnss_winbind è possibile effettuare una ricerca degli utenti e dei gruppi del dominio. Ad esempio, per cercare l'utente del domino "DOMAIN\demo01":

cephuser@smb > getent passwd DOMAIN\\demo01
DOMAIN\demo01:*:10000:10000:demo01:/home/demo01:/bin/bash

Per cercare il gruppo del domino "Domain Users":

cephuser@smb > getent group "DOMAIN\\Domain Users"
DOMAIN\domain users:x:10000:

24.2.10.3 Assegnazione di autorizzazioni di file a utenti e gruppi del dominio #

Tramite la libreria NSS, è possibile utilizzare i gruppi e gli account utente del dominio nei comandi. Ad esempio, per impostare il proprietario di un file sull'utente del dominio "demo01" e il gruppo sul gruppo del dominio "Domain Users", immettere:

cephuser@smb > chown "DOMAIN\\demo01:DOMAIN\\domain users" file.txt