systemd ha tante caratteristiche interessanti, una delle quali è l’attivazione tramite socket, vale a dire che si può configurare systemd si mette in attesa su una certa porta TCP (o una pipe, o altro tipo di socket) al posto di un altro programma. Quando arriva una richiesta di connessione, systemd l’accetta e attiva il servizio configurato, poi questo deve comunicare con systemd, prendere la richiesta in arrivo e servirla.

Perché è interessante? Perché si possono configurare molti servizi su una sola macchina, ma attivarli solo quando veramente sono richiesti. Oppure, durante l’avvio del computer, si possono attivare vari servizi in contemporanea, con l’attivazione tramite socket, e proseguire come se già fossero attivi.

Continua a leggere→

Di recente ho dovuto installare un server Red Hat Enterprise Linux 7, si tratta di una macchina che ospita un database Oracle, ma mi è stato chiesto di attivare anche alcune condivisioni tramite samba. Ho fatto tutti i passaggi consueti per l’installazione e configurazione, ma non funzionava nulla. Dopo due giorni di lavoro ho sistemato la macchina, superando vari ostacoli. Elenco qui i problemi più grossi e le relative soluzioni.

Autenticazione

La macchina è stata messa in dominio Windows per poter accettare connessioni dai computer aziendali. Per farlo è stato installato il server SSSD che permette l’integrazione con il dominio Windows e la mappatura di utenze e gruppi di dominio. Samba è stato configurato copiando il tutto da un’altra macchina, SunOS, che ospitava precedentemente le cartelle di rete. Quel samba usava Winbind per l’integrazione con il dominio, sicché anche qui è stato usato winbind.
Nelle utenze sul dominio Windows non sono presenti userid e groupid come su Linux, sicché tutti i programmi di interfaccia con il dominio fanno una mappatura che parte dal SID dell’utenza Windows e arrivare a userid e groupid di Linux. Ovviamente per un determinato utente la mappatatura deve essere sempre eguale, sicché questa associazione viene memorizzata in un file. Il file è diverso se si usa SSSD o se si usa Winbind. Ma la cosa che non sapevo è che anche l’algoritmo di mappatura è diverso, quindi quando samba riceve una richiesta di connessione, effettua l’autenticazione con Kerberos e poi mappa il SID dell’utenza Windows su una utenza locale, che però qui non veniva trovata. L’errore era:

[2022/12/22 10:37:04.668145, 1] ../../source3/auth/token_util.c:561(add_local_groups)
SID S-1-5-21-990198401-320236572-313593124-1040 -> getpwuid(11040) failed

in effetti l’utenza in questione aveva un uid diverso: 1092201040 anziché 11040

[linux]# id 'azienda\nome.utente'
uid=1092201040(nome.utente@azienda.dom) gid=1092200513(domain users@azienda.dom) gruppi=1092200513(domain users@azienda.dom)

mentre sul vecchio server era proprio 11040:

[SunOS] # id 'azienda\nome.utente'
uid=11040(AZIENDA\nome.utente) gid=10513(AZIENDA\domain users)

Per sistemare questa cosa ci sono due diverse possibilità. La più diffusa, ma secondo me peggiore, è di fare usare winbind anche a NSS, cambiando le tre righe nel file /etc/nssswitch.conf da

passwd: files sss
group: files sss
shadow: files sss

a

passwd: files winbind
group: files winbind
shadow: files winbind

la seconda è di cambiare l’algoritmo usato da SSSD per generare userid e groupid. Questo si fa nel file /etc/sssd/sssd.conf, dove, per il dominio in questione, ci sarà scritto che il backend è proprio il dominio tramite la configurazione id_provider=ad. Questo vuol dire che si possono usare anche le configurazioni di sssd-ad come quella che ci interessa: ldap_idmap_autorid_compat. Il valore predefinito è false, ma se viene aggiunta al file di configurazione e impostata a true, risolve il problema.

Una volta fatto questo, l’autenticazione dovrebbe cominciare a funzionare.

Accesso al file system

Quando si accede tramite samba, l’utenza sulla quale si viene mappati deve avere l’accesso alle directory e ai file da utilizzare. Se, ad esempio, la condivisione utilizza la directory /s6/work1/samba, allora sarà necessario che l’utente possa arrivarci. Per farlo è necessario che la directory e quelle padre, cioè /s6, /s6/work1 e /s6/work1/samba abbiano tutte i bit “r” e “x” accesi, cioè che siano leggibili (“r”) e che ci si possa spostare in quella directory (“x”).

Una volta fatto questo, si ottiene ancora l’errore:

[2022/12/22 12:23:30.517028, 0] ../../source3/smbd/service.c:784(make_connection_snum)
make_connection_snum: canonicalize_connect_path failed for service CARTELLA, path /s6/work1/samba

Questo perché è attivo SELinux. Quando samba lavora su un sistema con SELinux è necessario fare alcune operazioni in più:

indicare che la directory in questione deve essere accessibile a samba per una condivisione. Questo si fa con la policy samba_share_t. Il comando da usare per fare una prova è;

[linux]# chcon --recursive --type samba_share_t /s6/work1/samba

mentre quelli per rendere il tutto permanente sono;

[linux]# semanage fcontext --add --type samba_share_t "/s6/work1/samba(/.*)?"
[linux]# restorecon -R -v /s6/work1/samba/

Per verificare che il tutto abbia funzionato, date il comando:

[linux]# ls -ldZ /s6/work1/samba/ /s6/work1/ /s6/
drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 /s6/
drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 /s6/work1/
drwxrwxrwx+ root root unconfined_u:object_r:samba_share_t:s0 /s6/work1/samba/

A questo punto samba potrà accedere a quella directory e ai file ivi contenuti senza che SELinux la blocchi. Ma, se cercate di collegarvi ottenete ancora lo stesso errore:

[2022/12/22 14:05:14.602571, 0] ../../source3/smbd/service.c:784(make_connection_snum)
make_connection_snum: canonicalize_connect_path failed for service CARTELLA, path /s6/work1/samba

Ora però il problema è un altro, sempre legato a SELinux: ci sono delle attività che sono completamente inibite in samba a meno di attivare tramite la configurazione di SELinux. Perché sia possibile condividere una qualsiasi directory in lettura va usato il parametro samba_export_all_ro, perché sia possibile farlo anche in scrittura va usato il parametro samba_export_all_rw. I due si attivano in questo modo:

[linux]# setsebool -P samba_export_all_ro=1 samba_export_all_rw=1
[linux]# getsebool -a| grep samba
samba_create_home_dirs --> off
samba_domain_controller --> off
samba_enable_home_dirs --> off
samba_export_all_ro --> on
samba_export_all_rw --> on
samba_load_libgfapi --> off
samba_portmapper --> off
samba_run_unconfined --> off
samba_share_fusefs --> off
samba_share_nfs --> off
sanlock_use_samba --> off
tmpreaper_use_samba --> off
use_samba_home_dirs --> off
virt_use_samba --> off
[linux]# systemctl restart smb nmb winbind

A questo punto tutto dovrebbe funzionare.

Qualche giorno fa uno dei computer dell’ufficio non si è acceso per bene: è partito grub2 e ha dato l’errore grub_file_filters not found.
Internet è decisamente prolifica nel trovare situazioni analoghe, ma per lo più si tratta di narrazioni di troubleshooting, senza indicare esattamente quali siano il problema e la soluzione.

E allora diciamolo chiamaramente: il problema è che la versione di grub scritta nell’MBR, cioè dentro il disco, non corrisponde a quella dei moduli presenti in /boot/grub. Questo può succedere per vari motivi: nel mio caso avevo installato grub sull’MBR di tutti i dischi del server (per poter fare il boot anche in caso di guasto di un disco), ma non avevo configurato correttamente questa cosa in debconf, sicché dopo gli aggiornamenti di grub, solo l’MBR del disco principale era stato aggiornato, lasciando gli altri MBR con la vecchia versione di grub. Questo era successo perché il sistema era stato installato con un solo disco e poi ampliato con gli altri. Appena si è rotto il disco principale, il BIOS ha letto grub dal secondo disco, grub ha caricato i moduli dalla directory /boot/grub che era su un RAID, ma la versione non combaciava.

La soluzione è quella di avere sempre grub allineato: ogni volta che si aggiorna il pacchetto si deve riscrivere grub su tutti i dischi dove è stato installato. Per farlo si può semplicemente riconfigurare grub con il comando

dpkg-reconfigure grub-pc