In questa sezione sono descritte le operazioni di amministrazione avanzate.
In questo esempio vogliamo creare utenti in gruppi per ogni anno, con home directory comuni per ogni gruppo (home0/2024, home0/2026, etc.). Gli utenti saranno creati importando un file csv.
(come root sul server principale)
Creare le directory di gruppo per ogni anno
mkdir /skole/tjener/home0/2024
(come primo utente in Gosa)
Dipartimento
Menu principale: andare in "Directory structure", clic su dipartimento "Students". Il campo "Base" dovrebbe visualizzare "/Students". Dalla casella "Actions" scegliere "Create"/"Department". Inserire i valori per Name (2024) e nel campo Description (studenti iscritti nel 2024), lasciare il campo Base così com'è (dovrebbe essere "/Students"). Salvare facendo clic su "Ok". Ora il nuovo dipartmento (2024) dovrebbe essere visualizzato sotto /Students. Fare clic su di esso.
Gruppo
Scegliere "Groups" dal menu principale; "Actions"/Create/Group. Inserire il nome del gruppo (lcasciare "Base" così com'è, dovrebbe essere /Students/2024) e 'Ok' per salvarlo.
Modello di desktop
Scegliere 'users' dal menu principale. Cambiare a "Students" nel campo
Base. Si dovrebbe vedere la voce
NewStuden'
, cliccarci sopra. Questo è il
modello per gli studenti, non un utente reale. Si dovrebbe creare un modello
basato su questo (per poter usare l'importazione da csv per la propria
struttura) perciò prestare attenzione a tutte le voci nelle schede Generic e
POSIX magari catturando screenshot per avere informazioni utili per il
nuovo modello.
Ora cambiare a /Students/2024 nel campo Base; scegliere Create/Template e cominciare a riempire con i valori desiderati, prima la scheda Generic (aggiungere il nuovo gruppo 2024 anche sotto il Group Membership), poi aggiungere l'account POSIX.
Importare utenti
Scegliere il nuovo modello quando si importa il csv; conviene provarlo con pochi utenti.
Con questo script l'amministratore può creare una cartella in tutte le directory home degli utenti e impostare permessi e proprietà.
Nell'esempio mostrato sotto con il gruppo=teachers e i permessi=2770 un utente può consegnare un compito salvando il file nella cartella "assignments" dove gli insegnanti hanno accesso di scrittura per fare commenti.
#!/bin/bash home_path="/skole/tjener/home0" shared_folder="assignments" permissions="2770" created_dir=0 for home in $(ls $home_path); do if [ ! -d "$home_path/$home/$shared_folder" ]; then mkdir $home_path/$home/$shared_folder chmod $permissions $home_path/$home/$shared_folder #set the right owner and group #"username" = "group name" = "folder name" user=$home group=teachers chown $user:$group $home_path/$home/$shared_folder ((created_dir+=1)) else echo -e "the folder $home_path/$home/$shared_folder already exists.\n" fi done echo "$created_dir folders have been created"
Fare questi passaggi per configurare un server storage dedicato per le home directory utente e per altri dati.
Aggiungere un nuovo sistema tipo server
con
GOsa² come indicato nella capitolo Getting
started di questo manuale.
Questo esempio usa come nome del server "nas-server.intern". Una volta configurato "nas-server.intern", controllare se i punti di esportazione di NFS nello storage server contengono rilevanti to sottoreti o macchine:
root@tjener:~# showmount -e nas-server Export list for nas-server: /storage 10.0.0.0/8 root@tjener:~#
In questo esempio l'accesso all'esportazione di /storage è consentito nella rete backbone. (Per restringere l'accesso a NFS si potrebbe limitarlo al netgroup di appartenenza o al singolo indirizzo IP, come si è fatto in tjener :/etc/exports).
Aggiungere le informazioni di automount in LDAP per "nas-server.intern" in modo da consentire a tutti i client di montarlo automaticamente su richiesta.
Questo non si può fare con GOsa², perché non c'è il modulo per automount. Occorre utilizzare ldapvi e aggiungere gli oggetti LDAP necessari usando un editor.
ldapvi --ldap-conf -ZD '(cn=admin)' -b
ou=automount,dc=skole,dc=skolelinux,dc=no
Nell'editor aggiungere i seguenti oggetti LDAP in fondo al documento. ("/&" nell'ultimo oggetto LDAP è un metacarattere che permette di esportare ogni cosa di "nas-server.intern", eliminando la necessità di elencare singoli punti di montaggio in LDAP.)
add cn=nas-server,ou=auto.skole,ou=automount,dc=skole,dc=skolelinux,dc=no objectClass: automount cn: nas-server automountInformation: -fstype=autofs --timeout=60 ldap:ou=auto.nas-server,ou=automount,dc=skole,dc=skolelinux,dc=no add ou=auto.nas-server,ou=automount,dc=skole,dc=skolelinux,dc=no objectClass: top objectClass: automountMap ou: auto.nas-server add cn=/,ou=auto.nas-server,ou=automount,dc=skole,dc=skolelinux,dc=no objectClass: automount cn: / automountInformation: -fstype=nfs,tcp,rsize=32768,wsize=32768,rw,intr,hard,nodev,nosuid,noatime nas-server.intern:/&
Aggiungere le voci pertinenti in tjener.intern:/etc/fstab, perché, per evitare loop di montaggio, tjener.intern non usa automount:
Creare le directory da montare usando
mkdir
e modificare come necessario
"/etc/fstab" ed eseguire mount -a
per
montare le nuove risorse.
Ora gli utenti dovrebbero essere in grado di accedere ai file su "nas-server.intern" direttamente nella directory "/tjener/nas-server/storage/" utilizzando qualsiasi applicazione su qualunque workstation, LTSP thin client o server LTSP.
Ci sono diversi modi per limitare il login ssh, alcuni dei quali sono elencati qui.
Se non vengono usati client LTSP una soluzione semplice è quella di creare
un nuovo gruppo (per esempio sshusers
) e
aggiungere una riga al file /etc/ssh/sshd_config della macchina. Solo ai
membri del gruppo sshusers
sarà permesso di
utilizzare ssh nella macchina dappertutto.
La gestione di questo caso con GOsa è abbastanza semplice:
Creare un gruppo sshusers
al livello di
base (dove ci sono già altri gruppi di amministrazione di sistema come
gosa-admins
).
Aggiungere utenti al nuovo gruppo sshusers
.
Aggiungere AllowGroups sshusers
a
/etc/ssh/sshd_config.
Eseguire service ssh restart
.
L'installazione predefinita del client senza disco LTSP utilizza connessioni ssh. È sufficiente aggiornare l'immagine SquashFS sul relativo server LTSP dopo che la configurazione ssh è stata modificata.
I thin client X2Go usano connessioni ssh al relativo server LTSP. Quindi è necessario un approccio diverso usando PAM.
Permettere pam_access.so nel file /etc/pam.d/sshd nei server LTSP.
Configurare /etc/security/access.conf per consentire le connessioni per gli utenti (esempio)alice, jane, bob e john ovunque e per tutti gli altri utenti solo dareti interne aggiungendo queste righe:
+ : alice jane bob john : ALL + : ALL : 10.0.0.0/8 192.168.0.0/24 192.168.1.0/24 - : ALL : ALL #
Se sono utilizzati solo server LTSP dedicati, la rete 10.0.0.0/8 potrebbe essere disabilitata per il login ssh interno. Nota: qualcuno che collega la sua box alla rete dei client dedicata LTSP avrà accesso ssh ai server LTSP.
Se i client X2Go sono stati collegati alla rete backbone 10.0.0.0/8, sarebbe ancora più complicato e forse solo una configurazione DHCP sofisticata (in LDAP) con il controllo del vendor-class-identifier insieme a una configurazione PAM appropriata permetterebbe di disabilitare il login ssh interno.