Monthly Archives: Marzo 2019

Obiettivi esame RHCVA

Installazione di Red Hat Virtualization Manager e Red Hat Virtualization Hypervisor

Installare Red Hat Virtualization Manager e le eventuali dipendenze.
Configurare Red Hat Virtualization Manager affinché esegua l’autenticazione a fronte di un servizio IPA esterno.
Installare Red Hat Virtualization Hypervisor.
Aggiungere una o più istanze di Red Hat Virtualization Hypervisor a Red Hat Virtualization Manager.

Gestione dello storage

Configurare i domini di storage.
Importare i supporti di installazione in un dominio di storage.
Creare e gestire datacenter e cluster.

Creazione e gestione di macchine virtuali

Installare macchine virtuali.
Avviare e arrestare macchine virtuali.
Modificare le caratteristiche hardware delle macchine virtuali.
Configurare la migrazione automatica delle macchine virtuali.

Attività con le immagini delle macchine virtuali

Creare snapshot.
Creare macchine virtuali da snapshot.
Importare le immagini di macchine virtuali esistenti in Red Hat Virtualization Manager.

Creazione e gestione di utenti Red Hat Virtualization Manager

Creare utenti interni.
Creare utenti esterni.
Configurare ruoli e assegnare utenti a tali ruoli.
Configurare l’accesso tramite i ruoli.

Deployment automatico di macchine virtuali

Creare modelli di macchine virtuali.
Deployment di macchine virtuali mediante i modelli.
Utilizzare l’inizializzazione cloud per configurare macchine virtuali.

Attività con le reti logiche

Creare reti logiche.
Assegnare host a reti logiche.

Come installare e configurare oVirt 4.3.2 su CentOS 7/RHEL 7

oVirt è un software di virtualizzazione gratuito e open source utilizzato in sistemi operativi Linux come Fedora, CentOS e RHEL. In altre parole, possiamo dire che oVirt è l’alternativa di VMware vSphere in Linux. La community di Ovirt è fondata e supportata da Red Hat ed è considerata come progetto upstream per Red Hat Enterprise Virtualization (RHEV).

oVirt è costituito da due componenti principali:

oVirt Engine
oVirt Node

oVirt Engine è un’interfaccia utente grafica o possiamo dire che è un portale di amministrazione Web da cui possiamo gestire macchine virtuali, risorse di calcolo, di rete e di archiviazione.

oVirt Node è un server RHEL/CentOS o Fedora su cui è attivo il servizio vdsm. Il nodo Ovirt fungerà da Hypervisor (KVM) su cui verranno create tutte le macchine virtuali.

In questo articolo installeremo l’ultima versione di oVirt 4.3.2 su CentOS 7/RHEL 7. Utilizzeremo due server che fungeranno da motore ovovie e altri fungeranno da nodo ovirt. Di seguito sono i dettagli:

oVirt Engine: ovirtengine.example.com (192.168.100.135)

Nodo oVirt: nodes-ovirt.example.com (192.168.100.136)

Aggiorna le voci sottostanti nel file /etc/hosts nel caso in cui tu non abbia il tuo server DNS locale.

192.168.100.135  ovirt.example.com
192.168.100.136  nodes-ovirt.example.com

Fasi di installazione del motore oVirt su CentOS 7/RHEL 7

Di seguito sono riportati i requisiti minimi per il motore ovetto:

Sistema operativo minimo (CentOS 7.x/RHEL7.x)
Server dual core
4 GB di RAM
25 GB di spazio su disco
1-Gbps Lan Card

Effettuare i seguenti passaggi uno dopo l’altro per installare il motore ovetto.

Passo: 1 Aggiorna il server usando il comando yum

Installa l’ultimo aggiornamento sul server usando il comando yum.

[root@ovirt ~]# yum update -y

Dopo aver installato gli aggiornamenti, riavviare il server.

Passaggio: 2 Abilita oVirt 4.3.2 Repository

i pacchetti motore ovirt non sono disponibili nei repository yum CentOS e RHEL. Esegui sotto il comando per impostare e abilitare il repertorio di ovirt 4.3.2

[root@ovirt ~]# yum install http://resources.ovirt.org/pub/yum-repo/ovirt-release43.rpm

Passo: 3 Installa pacchetto motore di oVirt usando il comando yum

Esegui il seguente comando yum per installare il motore di ovirt.

[root@ovirt ~]# yum install ovirt-engine -y

Passaggio: 4 Avvia l’installer del motore ovirt

Esegui il comando ‘engine-setup‘ dalla console, avvierà l’installer del motore di ovirt e interverrà in modo interattivo serie di domande durante l’installazione e salverà tutte le risposte a un file di risposta. Il file di risposta può essere riutilizzato per automatizzare l’installazione.

[root@ovirt ~]# engine-setup --generate-answer=/root/answer.txt
[ INFO ] Stage: Initializing
[ INFO ] Stage: Environment setup
 Configuration files: ['/etc/ovirt-engine-setup.conf.d/10-packaging-jboss.conf', '/etc/ovirt-engine-setup.conf.d/10-packaging.conf']
 Log file: /var/log/ovirt-engine/setup/ovirt-engine-setup-20160918040600-2gbi6m.log
 Version: otopi-1.5.2 (otopi-1.5.2-1.el7.centos)
[ INFO ] Stage: Environment packages setup
[ INFO ] Yum Downloading: base/7/x86_64 (0%)
[ INFO ] Yum Downloading: updates/7/x86_64 (0%)
[ INFO ] Stage: Programs detection
[ INFO ] Stage: Environment setup
[ INFO ] Stage: Environment customization
 
 --== PRODUCT OPTIONS ==--
 
 Configure Engine on this host (Yes, No) [Yes]: Yes
 Configure Image I/O Proxy on this host? (Yes, No) [Yes]: Yes
 Configure WebSocket Proxy on this host (Yes, No) [Yes]: Yes
 Please note: Data Warehouse is required for the engine. If you choose to not configure it on this host, you have to configure it on a remote host, and then configure the engine on this host so that it can access the database of the remote Data Warehouse host.
 Configure Data Warehouse on this host (Yes, No) [Yes]: Yes
 Configure VM Console Proxy on this host (Yes, No) [Yes]: Yes
 
 --== PACKAGES ==--
 
[ INFO ] Checking for product updates...
[ INFO ] No product updates found
 
 --== NETWORK CONFIGURATION ==--
 
 Host fully qualified DNS name of this server [ovirt.example.com]: ovirt.example.com
[WARNING] Failed to resolve ovirtengine.example.com using DNS, it can be resolved only locally
 Setup can automatically configure the firewall on this system.
 Note: automatic configuration of the firewall may overwrite current settings.
 Do you want Setup to configure the firewall? (Yes, No) [Yes]: No

 --== DATABASE CONFIGURATION ==--
 
 Where is the DWH database located? (Local, Remote) [Local]: Local
 Setup can configure the local postgresql server automatically for the DWH to run. This may conflict with existing applications.
 Would you like Setup to automatically configure postgresql and create DWH database, or prefer to perform that manually? (Automatic, Manual) [Automatic]: Automatic
 Where is the Engine database located? (Local, Remote) [Local]: Local
 Setup can configure the local postgresql server automatically for the engine to run. This may conflict with existing applications.
 Would you like Setup to automatically configure postgresql and create Engine database, or prefer to perform that manually? (Automatic, Manual) [Automatic]: Automatic
 
 --== OVIRT ENGINE CONFIGURATION ==--
 
 Engine admin password: 
 Confirm engine admin password: 
[WARNING] Password is weak: it is too simplistic/systematic
 Use weak password? (Yes, No) [No]: Yes
 Application mode (Virt, Gluster, Both) [Both]: Both
 
 --== STORAGE CONFIGURATION ==--
 
 Default SAN wipe after delete (Yes, No) [No]: No
 
 --== PKI CONFIGURATION ==--
 
 Organization name for certificate [example.com]: example.com

 --== APACHE CONFIGURATION ==--
 
 Setup can configure the default page of the web server to present the application home page. This may conflict with existing applications.
 Do you wish to set the application as the default page of the web server? (Yes, No) [Yes]: Yes
 Setup can configure apache to use SSL using a certificate issued from the internal CA.
 Do you wish Setup to configure that, or prefer to perform that manually? (Automatic, Manual) [Automatic]: Automatic
 
 --== SYSTEM CONFIGURATION ==--
 
 Configure an NFS share on this server to be used as an ISO Domain? (Yes, No) [No]: No
 
 --== MISC CONFIGURATION ==--
 
 Please choose Data Warehouse sampling scale:
 (1) Basic
 (2) Full
 (1, 2)[1]: 1
 
 --== END OF CONFIGURATION ==--
 
[ INFO ] Stage: Setup validation
[WARNING] Warning: Not enough memory is available on the host. Minimum requirement is 4096MB, and 16384MB is recommended.
 Do you want Setup to continue, with amount of memory less than recommended? (Yes, No) [No]: Yes
 
 --== CONFIGURATION PREVIEW ==--
 
 Application mode : both
 Default SAN wipe after delete : False
 Update Firewall : False
 Host FQDN : ovirtengine.example.com
 Engine database secured connection : False
 Engine database host : localhost
 Engine database user name : engine
 Engine database name : engine
 Engine database port : 5432
 Engine database host name validation : False
 DWH database secured connection : False
 DWH database host : localhost
 DWH database user name : ovirt_engine_history
 DWH database name : ovirt_engine_history
 DWH database port : 5432
 DWH database host name validation : False
 Engine installation : True
 PKI organization : example.com
 Configure local Engine database : True
 Set application as default page : True
 Configure Apache SSL : True
 DWH installation : True
 Configure local DWH database : True
 Engine Host FQDN : ovirt.example.com
 Configure Image I/O Proxy : True
 Configure VMConsole Proxy : True
 Configure WebSocket Proxy : True
 
 Please confirm installation settings (OK, Cancel) [OK]: OK

[ INFO ] Stage: Transaction setup
[ INFO ] Stopping engine service
[ INFO ] Stopping ovirt-fence-kdump-listener service
[ INFO ] Stopping dwh service
[ INFO ] Stopping Image I/O Proxy service
[ INFO ] Stopping websocket-proxy service
[ INFO ] Stage: Misc configuration
[ INFO ] Stage: Package installation
[ INFO ] Stage: Misc configuration
[ INFO ] Upgrading CA
[ INFO ] Initializing PostgreSQL
[ INFO ] Creating PostgreSQL 'engine' database
[ INFO ] Configuring PostgreSQL
[ INFO ] Creating PostgreSQL 'ovirt_engine_history' database
[ INFO ] Configuring PostgreSQL
[ INFO ] Creating CA
[ INFO ] Creating/refreshing Engine database schema
[ INFO ] Creating/refreshing DWH database schema
[ INFO ] Configuring Image I/O Proxy
[ INFO ] Setting up ovirt-vmconsole proxy helper PKI artifacts
[ INFO ] Setting up ovirt-vmconsole SSH PKI artifacts
[ INFO ] Configuring WebSocket Proxy
[ INFO ] Creating/refreshing Engine 'internal' domain database schema
[ INFO ] Generating post install configuration file '/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf'
[ INFO ] Stage: Transaction commit
[ INFO ] Stage: Closing up
[ INFO ] Starting engine service
[ INFO ] Starting dwh service
[ INFO ] Restarting ovirt-vmconsole proxy service
 
 --== SUMMARY ==--
 
[ INFO ] Restarting httpd
 In order to configure firewalld, copy the files from
 /etc/ovirt-engine/firewalld to /etc/firewalld/services
 and execute the following commands:
 firewall-cmd --permanent --add-service ovirt-postgres
 firewall-cmd --permanent --add-service ovirt-https
 firewall-cmd --permanent --add-service ovirt-fence-kdump-listener
 firewall-cmd --permanent --add-service ovirt-imageio-proxy
 firewall-cmd --permanent --add-service ovirt-websocket-proxy
 firewall-cmd --permanent --add-service ovirt-http
 firewall-cmd --permanent --add-service ovirt-vmconsole-proxy
 firewall-cmd --reload
 The following network ports should be opened:
 tcp:2222
 tcp:443
 tcp:5432
 tcp:54323
 tcp:6100
 tcp:80
 udp:7410
 An example of the required configuration for iptables can be found at:
 /etc/ovirt-engine/iptables.example
 Please use the user 'admin@internal' and password specified in order to login
 Web access is enabled at:
 http://ovirt.example.com:80/ovirt-engine
 https://ovirt.example.com:443/ovirt-engine
 Internal CA E2:96:0B:A0:6C:1E:B5:0D:BB:7B:B5:29:4D:88:92:5A:DA:1E:95:BC
 SSH fingerprint: 1f:7b:59:12:01:8c:b5:d7:21:49:3b:e9:e4:d1:72:da
[WARNING] Warning: Not enough memory is available on the host. Minimum requirement is 4096MB, and 16384MB is recommended.
 
 --== END OF SUMMARY ==--
 
[ INFO ] Stage: Clean up
 Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20160918040600-2gbi6m.log
[ INFO ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20160918041930-setup.conf'
[ INFO ] Generating answer file '/root/answer.txt'
[ INFO ] Stage: Pre-termination
[ INFO ] Stage: Termination
[ INFO ] Execution of setup completed successfully
[root@ovirt ~]#

Nel caso il firewall sia abilitato sul tuo server, quindi esegui i passaggi citati nell’output precedente.

Passaggio: 5 Accedere al portale dell’amministratore Web di oVirt Engine.

Apri il browser web e digita l’URL:

https://ovirt.example.com

https://IP_Address

Sostituisci il nome del dominio o l’indirizzo IP come da impostazione.

Clicca sul Portale di amministrazione.

Inserisci il nome utente come “admin” e la password che abbiamo menzionato durante l’installazione e il profilo come interno.

A questo punto, l’installazione del motore ovirt è completata, ora installare il nodo.

Passi di installazione di oVirt Node (hypervisor)

oVirt Node può essere configurato in due diversi metodi, Il primo metodo è che possiamo scaricare il file hypervisor o ovirt-node iso dal suo sito web ufficiale e installare il server dal file iso scaricato.

Il secondo metodo è che possiamo rendere esistenti i server CentOS, RHEL e Fedora come ovirt node installando il pacchetto vdsm su di essi e quindi aggiungeremo manualmente quegli hosts o server dal portale dell’amministratore del motore ovirt.

I requisiti minimi per oVirt Node sono:

Sistema dual-core
RAM fisica da 10 GB
10 GB di spazio su disco
1-Gbps Lan Card

In questo tutorial vado con il primo metodo, ho già scaricato il file iso di oVirt 4.3.
Seleziona la prima opzione ‘Installa oVirt Node 4.3.2’

Seleziona la lingua e clicca su Continua …

Nel passaggio successivo, procedi come segue:

Configura rete
Imposta nome host
Seleziona disco per l’installazione del sistema operativo
Data e ora come da configurazione
Layout della tastiera

Nel mio caso Hostname è “nodes-ovirt.example.com” e l’indirizzo IP è 192.168.100.136

Fare clic su Inizia installazione

Imposta la password di root e fai clic su done

oVirt 4.3.2 L’installazione del nodo è in corso.

Al termine dell’installazione riavviare il server.
Aggiungi oVirt Node (nodes-ovirt.example.com) nel motore ovirt da Web Administrator Portal.

Accedi al portale amministratore, vai alla scheda Host -> fai clic su Nuovo

Specificare i dettagli del nodo ovirt.

Una volta fatto con le voci, fare clic su OK.
Come sto facendo questa installazione nel mio laboratorio, quindi non ho intenzione di “Configurare Power Management”. Clicca su OK

L’ovirt Engine sta installando il software sul nodo ovirt. In caso l’host non venga attivato dopo l’installazione del software selezionate l’ Host e fare clic su Attiva

Come possiamo vedere l’Host è ora attivato.

È tutto. Nel prossimo articolo discuteremo come creare un data center, un cluster e una macchine virtuale.

Web Container Custom properties

WebSphere Application Server consente di configurare il comportamento del contenitore Web a livello di sistema impostando alcune proprietà personalizzate predefinite.

È possibile impostare proprietà del contenitore Web personalizzate utilizzando la Console di amministrazione WAS, andando su Application servers > servername > Web container > Custom Properties. Questa è una schermata di proprietà personalizzate che sono impostate sulla mia installazione di WebSphere Portal locale

Queste sono le liste di proprietà e il loro significato in WAS 6.1

com.ibm.ws.webcontainer.disallowserveservletsbyclassname: quando la proprietà serveServletsByClassnameEnabled è abilitata, è possibile accedere direttamente ai servlet, con conseguente possibile esposizione di sicurezza. Definire la seguente proprietà personalizzata per impedire l’utilizzo della proprietà serveServletsByClassnameEnabled a livello dell’intero server delle applicazioni.

com.ibm.ws.webcontainer.donotservebyclassname: un elenco delimitato da punti e virgola di classi da non consentire completamente di essere servito dal nome della classe.

com.ibm.ws.webcontainer.suppressheadersinrequest: è possibile utilizzare la proprietà personalizzata com.ibm.ws.webcontainer.suppressheadersinrequest per sopprimere l’inclusione delle intestazioni delle richieste che iniziano con caratteri speciali, come “$” o “_“. Alcune applicazioni non gestiscono intestazioni di richiesta che iniziano con caratteri speciali

com.ibm.ws.webcontainer.webgroupvhostnotfound: messaggio di errore SRVE0017W indica “Web Group not found: {0}” e il messaggio di errore SRVE0255 indica “A WebGroup/Virtual Host to handle {0} has not been defined”. Questi messaggi possono essere restituiti quando l’applicazione chiamata per elaborare la richiesta servita da IBM WebSphere Application Server non viene trovata. È possibile utilizzare la proprietà personalizzata com.ibm.ws.webcontainer.webgroupvhostnotfound per modificare il testo di questi messaggi in un testo più adatto all’ambiente.

DecodeUrlAsUTF8: la funzione URL con codifica UTF-8, che fornisce URL (Uniform Resource Locators) codificati in UTF-8 per supportare i caratteri a doppio byte negli URL, è abilitata per impostazione predefinita. È possibile impedire al contenitore Web di decodificare esplicitamente gli URL in UTF-8 e fare in modo che utilizzino lo standard ISO-8859 secondo la specifica HTTP corrente impostando il valore di DecodeUrlAsUTF8 su falso

listener: le specifiche del servlet supportano le applicazioni che registrano i listener per gli eventi relativi alla servlet su una singola applicazione tramite il descrittore web.xml. Tuttavia, utilizzando la proprietà personalizzata degli ascoltatori, un server può ascoltare gli eventi servlet attraverso le applicazioni Web. Per implementare l’ascolto globale, un listener viene registrato a livello di contenitore Web e viene propagato a tutte le applicazioni Web installate e nuove. È possibile creare un listener servlet seguendo la specifica J2EE e specificarne il nome per applicarlo a tutte le applicazioni Web

DebugSessionCrossover: la proprietà personalizzata DebugSessionCrossover consente al codice di eseguire controlli aggiuntivi per verificare che solo la sessione associata alla richiesta sia accessibile o referenziata. I messaggi vengono registrati se vengono rilevate discrepanze.

com.ibm.wsspi.jsp.disableTldSearch: la proprietà personalizzata com.ibm.wsspi.jsp.disableTldSearch può essere utilizzata per migliorare il tempo di avvio dell’applicazione. Per impostazione predefinita, all’avvio di un’applicazione, il motore JSP ricerca le directory di installazione dell’applicazione per i file TDT (taglib descriptor). Questo processo di ricerca potrebbe aumentare il tempo di avvio per le applicazioni di grandi dimensioni con un numero elevato di file e directory. Per disabilitare questo processo di ricerca, imposta il valore di questa proprietà su true

com.ibm.ws.webcontainer.disallowAllFileServing: è possibile abilitare la pubblicazione di file a livello globale su un determinato server applicazioni utilizzando la proprietà personalizzata fileServingEnabled. Tuttavia, la proprietà fileServingEnabled viene sovrascritta dalle informazioni di distribuzione specifiche di ciascuna applicazione. Pertanto, la proprietà personalizzata fileServingEnabled corrente si applica solo come backup nel caso in cui un’applicazione non definisca l’impostazione fileServingEnabled stessa. Per ignorare globalmente questa impostazione su un server applicazioni specifico per impedire al server delle applicazioni di offrire file statici indipendentemente dalle impostazioni di distribuzione individuali, impostare la proprietà personalizzata del contenitore Web com.ibm.ws.webcontainer.disallowAllFileServing su true.

com.ibm.ws.webcontainer.mapFiltersToAsterisk: durante l’elaborazione di una richiesta, il contenitore Web riconosce i mapping del servlet su “*” come i mapping servlet su “/ *”. Per fornire lo stesso comportamento con la mappatura dei filtri, impostare la proprietà personalizzata com.ibm.ws.webcontainer.mapFiltersToAsterisk su true. Impostando la proprietà personalizzata com.ibm.ws.webcontainer.mapFiltersToAsterisk su true, il contenitore Web riconosce i mapping dei filtri su “*” come mappatura del filtro su “/ *”. Questa proprietà personalizzata non fa distinzione tra maiuscole e minuscole.

RHCE 7: Condivisioni dei servizi SMB/CIFS in un gruppo

Samba è un’implementazione open source dei protocolli SMB (server message block) e CIFS (Common Internet File System), ci consente di accedere alle risorse di condivisione file di Windows da Linux. Con Samba possiamo esportare directory specifiche all’interno di un file system attraverso la rete ad altri client Windows o Linux, permettendoci di condividere vari file sulla rete tra diversi sistemi operativi.Qui tratteremo la configurazione di una condivisione di file samba che consente la collaborazione di gruppo. Gli utenti all’interno di un particolare gruppo saranno in grado di creare contenuti all’interno di una condivisione samba che altri utenti all’interno dello stesso gruppo saranno in grado di accedere e modificare.

Abbiamo già spiegato come configurare le condivisioni di samba per clienti specifici, questo post si espanderà su queste informazioni.

Ambiente di esempio

Ecco un elenco dei nostri server con cui testeremo, entrambi utilizzano CentOS 7.

Client Samba: 192.168.0.100 – Questo client Linux monterà una directory dal server SMB/CIFS.
Samba Server: 192.168.0.200 – Questo server Linux servirà una directory su SMB/CIFS al client.

Configurazione del server Samba

Installazione di base del server Samba

Il server che ha i dati da condividere funzionerà come server samba e ha bisogno del pacchetto samba installato.

yum install samba -y

Una volta installato, possiamo abilitare il nostro server Samba ad avviare automaticamente il servizio SMB richiesto all’avvio, inoltre avvieremo il servizio ora poiché non è in esecuzione di default dopo l’installazione. Lo facciamo anche con il servizio NMB, che è responsabile di NetBIOS e fa parte del pacchetto samba.

Per ulteriori informazioni sulla gestione dei servizi di base con systemctl, consultare la nostra guida qui.

systemctl enable smb nmb
systemctl start smb nmb

Successivamente il firewall deve essere configurato per consentire il corretto traffico SMB, ciò può essere fatto come mostrato di seguito con firewalld. Questa modifica consentirà il traffico delle porte TCP 135/445 SMB/CIFS nel server da qualsiasi indirizzo IP di origine. Anche la configurazione del firewall deve essere ricaricata poiché abbiamo messo in atto una regola permanente che non si applica alla configurazione in esecuzione.

firewall-cmd --permanent --add-service=samba
firewall-cmd --reload

Configura la condivisione di gruppo

Quindi dobbiamo configurare samba e la condivisione di gruppo sul nostro server.

Iniziamo con la creazione di un gruppo e due utenti, in questo caso group1 sarà il gruppo in cui entreranno entrambi i nostri utenti.

[root@server ~]# groupadd group1
[root@server ~]# useradd -s /sbin/nologin -G group1 user1
[root@server ~]# useradd -s /sbin/nologin -G group1 user2

Questi due utenti non saranno utilizzati per accedere direttamente al sistema, motivo per cui è stata specificata la shell / sbin / nologin, saranno solo gli utenti SMB. Questo viene fatto impostando le loro password con smbpasswd, come mostrato sotto.

[root@server ~]# smbpasswd -a user1
New SMB password:
Retype new SMB password:
Added user user1.

[root@server ~]# smbpasswd -a user2
New SMB password:
Retype new SMB password:
Added user user2.

Ora prepariamo la directory da condividere al gruppo, condivideremo / groupshare dal server.

[root@server ~]# mkdir /groupshare
[root@server ~]# chown root:group1 /groupshare
[root@server ~]# chmod 2770 /groupshare

Abbiamo impostato il gruppo della directory/groupshare che appartiene al nostro gruppo1 appena creato. Le autorizzazioni sono state impostate su 2770, dove i primi 2 indicano SetGID mentre 770 sono permessi standard. SetGID viene utilizzato per impostare il gruppo di file e directory creati all’interno di /groupshare nello stesso gruppo che è stato impostato nella directory /groupshare stessa. Poiché /groupshare è di proprietà di group1, tutti i file o le directory create in /groupshare saranno di proprietà del gruppo group1 richiesto per la collaborazione di gruppo.

Questo verrà visualizzato come un ‘s‘ dove il permesso ‘x‘ si trova di solito nella directory per il gruppo. Se non esiste il permesso “x” per il gruppo, la “s” appare invece come “S“.

[root@server ~]# ls -la /groupshare/
total 4
drwxrws---.  2 root group1    6 May 22 02:55 .

Quindi dobbiamo configurare SELinux, una directory richiede il contesto samba_share_t per essere condivisa con samba.

[root@server ~]# semanage fcontext -a -t samba_share_t "/groupshare(/.*)?"
[root@server ~]# restorecon -v /groupshare/
restorecon reset /groupshare context unconfined_u:object_r:default_t:s0->unconfined_u:object_r:samba_share_t:s0

Infine, abbiamo bisogno di definire effettivamente la condivisione del file di gruppo nel file di configurazione /etc/samba/smb.conf, abbiamo aggiunto il contenuto sottostante a questo file.

[groupshare]
        create mask = 0660
        force create mode = 0660
        comment = This allows us to share the /groupshare directory to group1
        path = /groupshare
        valid users = @group1
        writable = yes

“Create mask” e “force create mode” assicurano che quando un utente in group1 crea un nuovo file, le autorizzazioni saranno impostate su 660. Per default i file sono stati creati con 644 che impedisce ad altri membri del gruppo di scrivere sui file . Gli “utenti validi” specificano il nostro gruppo1, i gruppi sono specificati con il prefisso ‘@‘.

Per applicare queste modifiche, riavviare o ricaricare il servizio smb.

[root@server ~]# systemctl restart smb

Configurazione del client Samba

Ora che il server è pronto per accettare le connessioni SMB, è necessario preparare il client.

Prima installa il pacchetto samba-client e cifs-utils che viene utilizzato per il montaggio delle condivisioni SMB.

yum install samba-client cifs-utils -y

Successivamente modifica il firewall abilitando il servizio samba-client.

firewall-cmd --permanent --add-service=samba-client
firewall-cmd --reload

Test della condivisione file di gruppo

Il sistema client dovrebbe ora essere in grado di montare la condivisione di file samba come utente1 o utente2. Entrambi questi utenti dovrebbero essere in grado di modificare gli stessi file che saranno di proprietà di group1.

Innanzitutto come utente1 installiamo la directory /groupshare dal server e creiamo “shared-file” con alcuni contenuti.

[root@client ~]# mount //192.168.0.200/groupshare /mnt -o username=user1
Password for user1@//192.168.0.200/groupshare:  ********
[root@client ~]# echo user1 > /mnt/shared-file

Fatto questo, smonteremo e monteremo nuovamente come utente2 questa volta e aggiungeremo più contenuti al file.

[root@client ~]# umount /mnt

[root@client ~]# mount //192.168.0.200/groupshare /mnt -o username=user2
Password for user2@//192.168.0.200/groupshare:  ********
[root@client ~]# echo user2 >> /mnt/shared-file

Ora sul server possiamo controllare questo file di file condiviso e vedere che è stato correttamente impostato sulle autorizzazioni di 660, consentendo al gruppo di group1 sia l’accesso in lettura che in scrittura come previsto. Vedremo anche che contiene i contenuti sia dell’utente1 che dell’utente2, confermando che entrambi gli utenti sono in grado di modificare il file nella condivisione samba.

[root@server ~]# ls -la /groupshare/shared-file
-rw-rw----. 1 user1 group1 12 May 22 03:19 /groupshare/shared-file
[root@server ~]# cat /groupshare/shared-file
user1
user2

Sommario

Come mostrato possiamo creare una directory per la condivisione di file e condividerla con samba, consentendo la collaborazione di gruppo con l’aiuto di SetGID. Gli utenti all’interno dello stesso gruppo sono in grado di lavorare insieme per accedere e modificare il contenuto nella stessa directory.

Questo post fa parte della nostra serie di guide agli esami per l’esame di Red Hat Certified Engineer (RHCE). Per ulteriori informazioni e post relativi consulta Obiettivi esame RHCE 7.