Verified Commit 7bd54a54 authored by Marco Marinello's avatar Marco Marinello
Browse files

Merge

parents 993de5a1 54912b9f
......@@ -345,6 +345,26 @@ di tali firmware; per usarla è necessario abilitare le sezioni
``non-free`` diverso dai firmware necessari per il supporto hardware
non è supportata.
Rimozione parziale della configurazione
---------------------------------------
``fuss-client`` permette di togliere parte della configurazione di un
FUSS Client in modo da poterlo spostare da un server in dismissione ad
un nuovo server senza reinstallarlo.
Si ottiene lanciando il comando::
# fuss-client -r -p
quindi spostando il client sulla rete del nuovo server e lanciando
``fuss-client`` regolarmente come indicato sopra.
Attenzione che questa procedura non agisce sul server (non è quindi
adatta per scollegare client da server che si vogliono mantenere in uso)
e non rimuove tutta la configurazione del client; in generale il metodo
consigliato è sempre il ripristino del client da un'immagine clonezilla
fresca di installazione tramite fuss-fucc.
.. LocalWords: FUSS client Fuss fuss root RECAP localhost changed failed
.. LocalWords: unreachable This has several groups Please choose the one
.. LocalWords: desired for this machine Your choice number version apt log
......
......@@ -16,6 +16,7 @@ Gestione dei FUSS server
.. LocalWords: octofuss Fuss ansible variable separation yaml fuss upgrade
.. LocalWords: configure defaults Dansguardian OctoNet DHCP client dhcp DNS
.. LocalWords: conf reservation host nomeclient ethernet fixed address eth
......@@ -29,4 +30,13 @@ Gestione dei FUSS server
.. LocalWords: exclude shell pathname patterns repository extract mount xr
.. LocalWords: umount filesystem drwxr gen var Reset passwd pass mpwchange
.. LocalWords: sh gzip slapcat ldif nell'LDAP timestamp systemctl service
.. LocalWords: rm rf slapadd chown openldap
.. LocalWords: rm rf slapadd chown openldap playbook Squid dans localnet
.. LocalWords: guardian lease proxy win dansguardian squid all'acl acl url
.. LocalWords: repositories regex dhcpd bind find mmin name diff borgbackup
.. LocalWords: checkpoint ldappasswd Success vim smbpasswd Setting stored
.. LocalWords: for secrets admin Changing and passwords Retype new reset
.. LocalWords: octofussd System identified issues kadmin local kerberos cpw
.. LocalWords: principal exit freeradius history Troubleshooting join txt
.. LocalWords: dell’host capslock smbldap usermod nomeutente ldapvi cat MAC
.. LocalWords: done ddns style hostname DHCID hash shutdown conflict rndc
.. LocalWords: detection freeze hour weeks thaw octonet TTL static PTR
......@@ -14,7 +14,7 @@ Prima di mostrare come installare server e client, vediamo nella seguente figura
Tipica topologia di una rete FUSS
Un server FUSS deve avere almeno 2 interfacce di rete. La prima serve per la connessione alla WAN (Wide Area Network) mentre la seconda è collegata alla rete locale (LAN-1) della scuola. La presenza di una terza porta ethernet sul server e di una seconda LAN nella scuola alla quale sono connessi degli access point WiFi sono i presupposti per poter installare sul server FUSS un captive-portal che offre la possibilità a dispositivi satellite di accedere ad internet previa autenticazione.
Un server FUSS deve avere almeno 2 interfacce di rete. La prima serve per la connessione alla WAN (Wide Area Network) mentre la seconda è collegata alla rete locale (LAN-1) della scuola. La presenza di una terza porta Ethernet sul server e di una seconda LAN nella scuola alla quale sono connessi degli access point WiFi sono i presupposti per poter installare sul server FUSS un captive-portal che offre la possibilità a dispositivi satellite di accedere ad internet previa autenticazione.
.. _serverdaupstream:
......@@ -670,13 +670,13 @@ Questa interfaccia sarà quella che dovrà essere collegata fisicamente al
tratto di rete (che deve essere fisicamente separata dalla rete interna
del server) che verrà gestita dal *Captive Portal* (ad esempio vi si
potrà attaccare un access point senza autenticazione). Negli esempi
successivi assumeremo che si tratti di ``eth2``.
successivi assumeremo che si tratti di ``ens20``.
Si tenga presente che l’interfaccia fisica (``eth2``) viene gestita
Si tenga presente che l’interfaccia fisica (``ens20``) viene gestita
direttamente dal software di gestione del *Captive Portal* (Coova
Chilli) che poi fa passare i pacchetti autorizzati creando una
interfaccia tunnel (di default ``tun0``). Gli indirizzi di rete fanno
riferimento a quest’ultima, ad ``eth2`` non deve essere assegnato alcun
riferimento a quest’ultima, ad ``ens20`` non deve essere assegnato alcun
indirizzo IP.
Per questo si abbia cura di verificare che sul *Fuss Server* non sia
......@@ -686,7 +686,7 @@ presente si abbia cura di bloccare ogni possibile tentativo di
autoconfigurazione dell’interfaccia dedicata al *Captive Portal*
inserendo in ``/etc/network/interfaces`` una voce del tipo::
iface eth2 inet manual
iface ens20 inet manual
Per installare il *Fuss Captive Portal* occorre eseguire il comando::
......@@ -709,7 +709,7 @@ Un esempio di sessione di installazione è il seguente::
Please insert Hot Spot Interface
The Hotspot interface of the server, ex. 'eth3'
Your choice? eth2
Your choice? ens20
################################################################################
Please insert Hot Spot Network (CIDR)
......
Dump e restore del fuss-server
==============================
A partire dalla versione 8.0.46 e 10.0.25 del fuss-server sono stati
predisposti gli strumenti necessari ed una procedura che consente di eseguire
il dump di un server FUSS e ripristinarlo su un altro, in particolare per
poter consentire il passaggio da FUSS 8 a FUSS 10, mantenendo la gran parte
dei dati presenti sul server di partenza.
La procedura prevede che si effettui un backup completo delle home degli
utenti sul server (che deve comprendere oltre a ``/home`` qualunque altra
directory in cui queste possono essere state inserite), da cui poi
ripristinare i dati. Si darà per scontato che questo sia stato fatto con il
programma ``fuss-backup``.
Il primo passo è eseguire lo script
``/usr/share/fuss-server/scripts/fuss-dump.sh`` sul server di partenza (si
assume che sia un FUSS 8), questo creerà un file
``fuss-server-dump-$DATA.tgz`` nella directory corrente con i dati necessari
al ripristino, che dovrà essere copiato a destinazione sul nuovo server (i
dati dell'archivio restano comunque salvati anche nel server originale sotto
``/var/backups/fuss-server``).
Occorrerà poi installare il sistema operativo sul nuovo server, e configurarne
la rete; è opportuno (anche se non indispensabile, ma potrebbe dare luogo ad
inconvenienti relativi a nomi rimasti in cache sui client fare altrimenti)
usare lo stesso hostname del server precedente. Inoltre se sul vecchio server
si stanno usando le quote disco, occorrerà anche abilitarle esplicitamente.
Per poter utilizzare il ripristino occorre installare il nuovo server FUSS10
normalmente, con ``fuss-server create``, mantenendo però identici il dominio,
la master password ed il workgroup. É opportuno mantenere anche la stessa
anche la rete interna ed il range del DHCP, dato che alcuni dati (in
particolare le impostazioni del firewall e le reservation statiche) possono
dipendere da queste impostazioni.
Pertanto prima dell'esecuzione di ``fuss-server create`` è opportuno copiarsi
i dati della configurazione del server di partenza (il file
``/etc/fuss-server/fuss-server.yaml``, che viene comunque anche incluso
nell'archivo prodotto dallo script di dump come ``fuss-server.yaml.old``) e
modificare soltanto le voci ``external_ifaces:`` e ``internal_ifaces:`` che
possono essere cambiate (come avviene nel passaggio da Jessie a Buster),
adattandole al nuovo server.
Una volta completata la configurazione di base del fuss-server occorrerà
copiarvi il file con il dump dei dati, ed eseguire lo script di restore con::
/usr/share/fuss-server/scripts/fuss-restore.sh fuss-server-dump-$DATA.tgz
lo script una volta scompattato l'archivio nella sottodirectory
``fuss-server`` (sovrascriverà eventuali file omonimi contenuti) fermerà tutti
i servizi, reimporterà i dati, e poi li riavvierà.
A questo punto gli utenti e le configurazioni dei servizi saranno stati
reimportati, ma resterà da ripristinare il contenuto delle home degli utenti,
operazione da fare con le istruzioni date per l'uso di ``fuss-backup``.
.. warning::
Il nuovo server, essendo stato reinstallato, avrà delle chiavi SSH diverse
dal vecchio, pertanto collegandosi dai client si potranno avere degli
errori di cambiamento delle chiavi. Occorrerà cancellare le vecchie chiavi
ed accettare le nuove.
......@@ -37,8 +37,8 @@ chiederà una serie di dati. In particolari saranno richiesti:
* un intervallo di indirizzi per il DHCP (es. 192.168.1.10 192.168.1.100);
* la master password del server (usarne una lunga e complicata!);
* la località (es. Bolzano);
* l'interfaccia della rete esterna (es. eth0);
* l'interfaccia della rete interna (es. eth1);
* l'interfaccia della rete esterna (es. ens18);
* l'interfaccia della rete interna (es. ens19);
Il programma per la richiesta dei dati, se disponibile, userà
l'interfaccia grafica, altrimenti queste dovranno essere inserite con
......
......@@ -131,3 +131,122 @@ usando un IP fuori dal range del DHCP (che di default prende gli
indirizzi fra 1/4 e 3/4 della rete usata per la LAN). Se il file
``/etc/fuss-server/dhcp-reservations`` viene eliminato, il servizio non
viene avviato.
.. _file-configurazione-firewall:
Firewall
--------
I file di configurazione per il firewall sono tutti nel formato::
valore:descrizione
con l'eccezione di quello che descrive macchine interne consentite e
servizi esterni raggiungibili, che è nella forma::
host:servizio:descrizione
Le righe che iniziano con un # sono considerate commenti e vengono
ignorate, inoltre quanto non compare all'interno del blocco marcato
``ANSIBLE MANAGED BLOCK`` non viene sovrascritto dalla riesecuzione del
comando di installazione del fuss-server.
Se si specifica un host questo deve essere o un nome a dominio o un
indirizzo IP, si tenga conto però del fatto che il firewall effettua la
risoluzione dell'indirizzo IP al suo avvio, pertanto usare un nome a
dominio è rischioso, specie quando ad esso possono corrispondere a
diversi indirizzi (ad esempio www.google.com) perché il firewall farà
riferimento soltanto a quello risolto in fase di avvio.
Quando si specifica un servizio invece questo deve essere nella forma
porta/protocollo (ad esempio 123/udp o 2628/tcp). Si raccomanda di usare
le minuscole ed i valori numerici.
La descrizione può essere omessa, verrà comunque inserita una
descrizione standard.
I file utilizzati sono i seguenti; vengono abilitati su firewall nella
sequenza in cui sono indicati nella tabella (questo significa che un
host nel primo file non potrà raggiungere comunque nessun servizio
esterno, neanche quelli resi accessibili con gli altri file):
.. list-table::
:header-rows: 1
* - File
- Contenuto
- Formato
* - ``/etc/fuss-server/firewall-denied-lan-hosts``
- Host che **non** possono raggiungere alcun servizio sulla rete
internet
- IP-address
* - ``/etc/fuss-server/firewall-allowed-lan-hosts``
- Elenco di host che possono accedere ai servizi della rete internet
senza alcun filtro e/o limitazione
- IP-address
* - ``/etc/fuss-server/firewall-allowed-wan-hosts``
- Elenco di host sulla rete internet che possono essere acceduti senza
alcun filtro e/o limitazione
- IP-address
* - ``/etc/fuss-server/firewall-allowed-wan-services``
- Servizi sulla rete internet che possono essere raggiunti senza
limitazioni e/o controllo. Devono essere indicate le porte da
utilizzare per il servizio
- porta/protocollo
* - ``/etc/fuss-server/firewall-external-services``
- Servizi offerti dal server sulla rete esterna
- porta/protocollo
* - ``/etc/fuss-server/firewall-allowed-wan-host-services``
- Servizi sulla rete internet raggiungibili da specifici host della
rete interna senza alcun limite.
- IP-address:porta/protocollo
Si ricordi che dopo aver eseguito modifiche manuali sui suddetti file
occorre rilanciare il firewall perché esse diventino effettive, con::
/etc/init.d/firewall restart
Nel caso si sia installato anche il Captive Portal il firewall usa
l'ulteriore file ``/etc/fuss-server/fuss-captive-portal.conf``, per ottenere
la rete usata dallo stesso e abilitare gli accessi necessari. Detto file
non deve essere cancellato, pena la mancanza dei suddetti accessi ed il
conseguente non funzionamento del Captive Portal in caso di riavvio del
firewall.
squid (web proxy)
-----------------
Il file ``/etc/squid3/squid-added-repo.conf`` permette di aggiungere
siti web all'acl ``repositories`` ai quali l'accesso è sempre permesso
senza autenticazione.
I contenuti devono essere della forma::
acl repositories url_regex XXX
dove ``XXX`` è l'espressione regolare che rappresenta il sito che
vogliamo abilitare; esempi di sintassi sono presenti in ``squid.conf``,
come::
acl repositories url_regex ^http://.*.debian.org/
dhcpd
-----
Il file ``/etc/dhcp/dhcpd-added.conf`` permette di aggiungere parametri
di configurazione del demone dhcp oltre a quanto gestito dal
fuss-server.
Tale file viene caricato alla fine di ``/etc/dhcp/dhcpd.conf``, e ne
condivide la sintassi.
bind (DNS)
----------
Il file ``/etc/bind/named.added.conf.local`` permette di aggiungere
parametri di configurazione di bind oltre a quanto gestito dal
fuss-server.
Tale file viene caricato alla fine di ``/etc/bind/named.conf.local``, e ne
condivide la sintassi.
Troubleshooting
----------
Può accadere che, se il programma viene interrotto in maniera inopportuna, il
repository che mantiene i dati del backup risulti corrotto. In tal caso si
potranno ottenere degli errori (riportati nella mail riassuntiva inviata al
completamento di ogni backup) del tipo::
borg.helpers.IntegrityError: Segment entry checksum mismatch [...]
In questo caso è necessario eseguire una verifica manuale, ed eventualmente
riparare il repository dei dati.
Per farlo è necessario montare il disco remoto su cui si fanno i backup,
questo si può fare (utilizzando i dati contenuti nella configurazione del
fuss-backup) con i comandi::
. /etc/fuss-backup/fuss-backup.conf
mount $DISK $BASEDIR
poi si potrà verificare lo stato del repository, con::
borg check $BASEDIR/$BACKUP_DIR
e se questo riporta degli errori si potranno sistemare con::
borg check --repair $BASEDIR/$BACKUP_DIR
accettando che si possano perdere dei dati (sono dati del backup, si possono
ripristinare facendone uno subito dopo la riparazione). Completata la
riparazione ci si ricordi di smontare il disco remoto con ``umount $BASEDIR``.
Risoluzione di problemi
=======================
......@@ -77,7 +110,7 @@ L'operazione si sarà conclusa correttamente se verrà restituito il seguente OU
Result: Success (0)
2) Modificare i seguenti file, sostituento la ``vecchia-password`` con la ``nuova-password``.
2) Modificare i seguenti file, sostituendo la ``vecchia-password`` con la ``nuova-password``.
::
......@@ -325,9 +358,9 @@ Troubleshooting DNS
-------------------
Mancata risoluzione di macchine reinstallate con lo stesso nome
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Il fuss-server utilizza il DNS dinamico per creare automaticante delle voci
Il fuss-server utilizza il DNS dinamico per creare automaticamente delle voci
con i nomi delle macchine all'interno della zona locale della scuola, con la
direttiva ``ddns-update-style standard`` in ``/etc/dhcp/dhcpd.conf``. Il
meccanismo prevede che ogni volta che un client ottiene un indirizzo dinamico
......@@ -413,7 +446,7 @@ generale tutti quelli che si sono inseriti manualmente nel file per le
assegnazioni statiche.
Una volta rimosse le voci da ``/var/cache/bind/db.local`` si cancellino le
voci corripondenti con la risoluzione inversa in
voci corrispondenti con la risoluzione inversa in
``/var/cache/bind/db.192.168.XX.00``, che nel caso dell'esempio precedente
saranno qualcosa del tipo::
......@@ -422,7 +455,7 @@ saranno qualcosa del tipo::
Una volta completate le modifiche occorre aggiornare il seriale dei file di
zona (entrambi), per questo occorre cercare la riga identificata dal commento
``; serial`` nel record ``SOA`` che è all'inzio del file, ed aumentare di uno
``; serial`` nel record ``SOA`` che è all'inizio del file, ed aumentare di uno
il valore in essa indicata; se ad esempio 811 era il valore in
``/var/cache/bind/db.local`` precedente alle modifiche, si dovrà indicare al
suo posto 812, con qualcosa del tipo::
......@@ -443,3 +476,69 @@ Fatto questo si potrà "scongelare" la zona con il comando::
rndc thaw
e l'aggiornamento dinamico riprenderà a funzionare.
Mancata risoluzione di macchine con assegnazione statica
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Una delle funzionalità fornite dal fuss-server è quella di consentire delle
assegnazioni statiche (reservation) degli IP in base al MAC address delle
macchine. Queste vengono mantenute nel file
``/etc/fuss-server/dhcp-reservations`` e gestite tramite ``octonet``.
Fino alla versione 10.0.13 ``octofussd`` si limita a gestire questa
assegnazione statica, le macchine elencate nel file non venivano inserite nel
DNS. Pertanto le macchine elencate ottengono un indirizzo IP (quello
selezionato dalla funzionalità) ma il loro nome resta assente dal DNS.
A partire dalla versione 10.0.14 è stato aggiunto il supporto per
l'inserimento (in fase di creazione) e la cancellazione (in fase di rimozione)
sul DNS delle macchine indicate per l'assegnazione statica. Non è ancora
disponibile il supporto per la modifica dei dati (pertanto in caso di
necessità si cancelli e si ricrei una voce).
Il supporto disponibile a partire dalla versione 10.0.14 riguarda però
soltanto le nuove voci, per quelle già presenti il DNS non viene
aggiornato. Per gestire questo caso (o se si sta mantenendo l'uso una versione
precedente la 10.0.14) le voci devono essere inserite o eliminate a mano.
L'operazione prevede la modifica manuale dei file di zona
(``/var/cache/bind/db.local`` e ``/var/cache/bind/db.192.168.XX.00``) che sono
gestiti in maniera dinamica; per questo (si riveda quanto già detto al
riguardo nella sezione precedente, prima di modificarli occorre "congelare" la
situazione con il comando::
rndc freeze
a questo punto si potranno aggiungere i dati, in ``/var/cache/bind/db.local``
va messa la risoluzione diretta, usando un TTL adeguato, con qualcosa del
tipo::
$TTL 604800 ; 1 week
static1 A 192.168.0.100
(avendo cura di usare il nome e l'indirizzo che ci sono in
``/etc/fuss-server/dhcp-reservations``) dove la voce del TTL può essere omessa
se la riga viene inserita sotto un blocco di definizione che ha all'inizio la
stessa.
La modifica va fatta anche nella zona inversa (in
``/var/cache/bind/db.192.168.XX.00``) con qualcosa del tipo::
$TTL 604800 ; 1 week
100 PTR static1.fusslab.blz.
e vale lo stesso avviso relativamente al TTL, fatte le modifiche occorrerà di
nuovo aumentare il seriale (si rimanda a quanto detto nella sezione
precedente) e poi si potrà "scongelare" la zona con il comando::
rndc thaw
a questo punto le risoluzioni saranno disponibili.
A partire dal ``fuss-server`` 10.0.24 è disponibile lo script ``dnsreserv.py``
(in ``/usr/share/fuss-server/scripts``) che rilegge il contenuto di
``/etc/fuss-server/dhcp-reservations`` ed esegue un DDNS update per tutti i
nomi ivi contenuti, questo consente di evitare l'intervento manuale per
reinserirli, ma la eventuale cancellazione di nomi spuri non viene eseguita e
in tal caso si deve ricorrere alla precedente procedura manuale.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment