[WORKLOG] - Installazione e configurazione di un serverino domestico / small office

Pagina 3 di 5
prima
1 2 3 4 5 ultimo
Visualizzazione dei risultati da 21 a 30 su 44
  1. #21
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    43
    Messaggi
    23,379
    configurazione

    Predefinito 5_ Installazione e configurazione del server DNS e di rndc

    Il DNS o Domain Name System è il servizio utilizzato per dare una corrispondenza tra gli indirizzi di rete scritti nel che siamo soliti utilizzare con il nostro browser (ad esempio, Nexthardware -X- news, recensioni ed anteprime su hardware, software, overclock e fotografia digitale - www.nexthardware.com) e l'unico indirizzamento di rete che i nostri computer sono in grado di capire, in questo caso l'indirizzo IP (62.149.214.80). E' uno dei servizi più sfruttati dell'internetworking ma è anche uno dei pochi servizi di rete che non ha alcun lato client con cui l'utente interagisca direttamente e quindi è anche uno dei più sconosciuti.

    Uno degli strumenti più utilizzati per questo servizio è Bind, un tools che è quasi un standard "de-facto" ed è utilizzato anche per i cluster che costituiscono la maggior parte dei "root name server", 13 sistemi sparsi per il mondo che sono la radice della risoluzione dei nomi a livello mondiale.

    A me interessano in realtà due funzionalità molto semplici di Bind: Il "caching name server" che avrà lo scopo di sostituirsi all'interno della LAN al DNS del provider, rispondendo alle interrogazioni dei client utilizzando una cache locale (dovrebbe anche contribuire a rendere molto più veloce l'esperienza utente, in quanto le risposte al browser arrivano molto più velocemente che non interrogando il DNS del provider) ed un "Master server" che avrà lo scopo di fornire la risoluzione dei nomi all'interno della rete locale.

    Il server l'ho selezionato durante il setup, quindi non c'è da installare niente altro. Se invece non lo avessi fatto prima l'installazione è, come al solito, terribilmente banale:
    codice:
    sudo apt-get update
    sudo apt-get  install  bind9 bind9utils dnsutils
    La configurazione completa di questo software è data da 4 files di configurazione, tutti contenuti nella directory /etc/bind/ e che sono named.conf, named.conf.options, named.conf.local e named.conf.default-zones. In modo un pò impreciso ed inesatto, posso dire che i primi due servono per specificare le funzionalità di base di Bind, le funzionalità che servono quindi al server DNS per rimanere "acceso" e gli altri due invece che determinano il contenuto e quindi le informazioni che il server distribuisce.

    La versione 9 di Bind introduce una utility per la gestione remota di bind che si chiama rndc. Questa utility utilizza delle connessioni di rete per gestire bind ed inviargli i comandi attraverso lo scambio di una secret-key che deve essere indicata sia nei files di configurazione di rndc che di bind (su alcuni sistemi a volte indicato anche come "named"). Nella guida che ho finora seguito per l'installazione del DNS, che ricordo essere per Ubuntu invece che per Debian, la configurazione di rndc non è implementata.

    La configurazione di default dovrebbe essere già funzionante ma preferisco ripartire da zero. Copio quindi tutto il contenuto della directory "bind" in una sottodirectory di backup ed elimino il file "rndc.key" presente in /etc/bind/ e rigenero la configurazione di rndc con il tool apposito. La directory è scrivibile solo da root, quindi è più comodo farlo come root che dover cambiare tutti i permessi alla directory e farlo con sudo:
    codice:
    cd /etc/bind
    su
    
    mkdir backup
    cp * backup/
    rm rndc-key
    
    sudo rndc-confgen
    Questo è quello che mi viene mostrato sulla consolle:

    Questo output può essere direttamente utilizzato per generare i due files di configurazione che mi servono e che, come detto, si trovano entrambi nella directory /etc/bind/.

    A questo punto lancio il comando
    codice:
    rndc-confgen > rndc.conf
    per creare un nuovo file di configurazione contenente il nuovo output che stò generando. Questo sostituirà nel caricamento di named e rndc il solo file contenente la secret-key e aggiunge la configurazione necessaria per autorizzare rndc a connettersi a named dal localhost sulla porta 953 per interagire col server DNS.
    codice:
    nano rndc.conf
    
    options {
            default-key "rndc-key";
            default-server 127.0.0.1;
            default-port 953;
    };
    La secret-key può essere specificata in un file separato come nella configurazione di default oppure all'interno di rndc.conf, come in questo caso.

    Il file termina circa a metà. La seconda metà del file è da copiare nel file named.conf, perchè possa autenticare la secret-key di rndc. La cosa più comoda è copiare la seconda parte del file rndc.conf ed incollarla in fondo al file named.conf, cancellando da questa i "#" che non servono prima di salvare.
    Il mio named.conf diventa quindi:
    codice:
    // This is the primary configuration file for the BIND DNS server named.
    //
    // Please read /usr/share/doc/bind9/README.Debian.gz for information on the
    // structure of BIND configuration files in Debian, *BEFORE* you customize
    // this configuration file.
    //
    // If you are just adding zones, please do that in /etc/bind/named.conf.local
    
    include "/etc/bind/named.conf.options";
    include "/etc/bind/named.conf.local";
    include "/etc/bind/named.conf.default-zones";
    
    # Use with the following in named.conf, adjusting the allow list as needed:
    key "rndc-key" {
          algorithm hmac-md5;
          secret "A53ltLIByMlmlaDrIUhBsQ==";
    };
    
    controls {
          inet 127.0.0.1 port 953
                  allow { 127.0.0.1; } keys { "rndc-key"; };
    };
    # End of named.conf
    Questa configurazione permette il controllo di named solo da locale, se si volesse controllare il DNS anche da remoto bisognerebbe modificare la configurazione del file, copiare la secret-key sul dispositivo remoto e aprire nel firewall la porta 953, ma non è decisamente il mio caso.
    codice:
    sudo /etc/init.d/bind9 restart
    Ultima modifica di frakka : 22-08-2011 a 15:10

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  2. #22
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    43
    Messaggi
    23,379
    configurazione

    Predefinito 5.1_ Installazione del server DNS: Caching name server

    Usando le solite guide e le relative fonti (qui e qui), anche la configurazione di base del "Caching name server" è molto semplice.
    Di default, l'installazione è già configurata per operare in questa modalità: E' comunque necessario specificare a bind alcuni server DNS definiti "Forwarders" a cui il mio server può indirizzare le richieste che non ha in cache. In sostanza, se il nostro server non conosce già la risposta da dare al client perchè non ce l'ha nella propria cache locale, interrogherà uno di questi forwarders. Le versioni più vecchie di Bind usavano i forwarders nell'ordine in cui erano indicati, la nostra versione credo utilizzi il più veloce ma la cosa non fà una grande differenza.
    Questa configurazione si fà nel file named.conf.options:
    codice:
    nano /etc/bind/named.conf.options
    codice:
    options {
            directory "/var/cache/bind";
    ...
            // If your ISP provided one or more IP addresses for stable
            // nameservers, you probably want to use them as forwarders.
            // Uncomment the following block, and insert the addresses replacing
            // the all-0's placeholder.
    
            // forwarders {
            //      0.0.0.0;
            // };
    
            auth-nxdomain no;    # conform to RFC1035
            listen-on-v6 { any; };
    };
    Praticamente non c'è nulla: Il percorso della directory in cui Bind salva la propria cache, un utilissimo suggerimento e la riga per impostare i Forwarders.
    Perchè il suggerimento è utilissimo? Quali DNS indicare come forwarders?
    Un scelta sicuramente non sbagliata sarebbe indicare dei root name server: Sono sicuramente sempre raggiungibili, sono la base della risoluzione dei nomi a livello mondiale quindi una risposta alla nostra interrogazione ce l'hanno di sicuro. Il problema è che sono più sovraccarichi, più lontani e quindi generalmente più lenti. Inoltre l'intero DNS ha una struttura di funzionamento "ad albero" ed i root name servers, essendo la radice, sono anche solitamente gli ultimi a ricevere le modifiche ai valori registrati. Quindi se un server cambia indirizzo IP uno degli ultimo a saperlo potrebbe essere proprio il root name server e questo non li rende la scelta migliore per l'utilizzo di tutti i giorni.

    Di massima si preferisce quindi indicare come forwarders i DNS del nostro provider o delle autorità nazionali immediatamente superiori (per l'Italia il NIC), senza risalire fino ai root name server che vengono lasciati appunto all'interrogazione da parte delle autorità nazionali. In alternativa, anche società private come Google forniscono un servizio DNS.
    Elenchi dei principali DNS Italiani se ne trovano un pò ovunque, l'indicazione corretta si trova sicuramente anche nella sezione tecnica delle FAQ del nostro provider. Una buona scelta potrebbe essere quindi quella di indicare due DNS del nostro provider ed un DNS del NIC, oppure un DNS del nostro provider e due del NIC... In rete si trovano anche delle comparazioni di velocità tra i vari DNS quindi la scelta si può fare in base alle proprie necessità.
    Personalmente, a causa di questo, preferisco adottare dei DNS magari più lenti ma non nazionali.
    I miei forwarders sono quindi 208.67.222.222 e 208.67.220.220 (di OpenDNS) e 193.205.245.5 (dns.nic.it) Con Open DNS mi sono sempre trovato bene, sono società note e soprattutto non soggette alla legislazione italiana. Il DNS del NIC è l'ultima spiaggia nel caso OpenDNS non rispondesse all'interrogazione.
    codice:
    options {
    	directory "/var/cache/bind";
    
    	// If there is a firewall between you and nameservers you want
    	// to talk to, you may need to fix the firewall to allow multiple
    	// ports to talk.  See http://www.kb.cert.org/vuls/id/800113
    
    	// If your ISP provided one or more IP addresses for stable 
    	// nameservers, you probably want to use them as forwarders.  
    	// Uncomment the following block, and insert the addresses replacing 
    	// the all-0's placeholder.
    
    //	forwarders {
    //		0.0.0.0;
    //	};
    
    	auth-nxdomain no;    # conform to RFC1035
    	listen-on-v6 { any; };
    
    	forwarders {
    		208.67.222.222;
    		193.205.245.5;
    		};
    };
    Il file di configurazione di bind è posizionale: praticamente è necessario che la sezione "forwarders" venga dopo le due direttive "auth-nxdomain no;" e "listen-on-v6 { any; };". Se per pigrizia vi venisse voglia di decommentare la sezione "forwarders" presente nell'esempio invece che riscriverla in fondo preparatevi a un potente mal di testa: Bind non si avvia restituendo un errore piuttosto generico:
    codice:
    Stopping domain name service...: bind9rndc: connect failed: 127.0.0.1#953: connection refused
    Generalmente se c'è un errore nel file di configurazione il servizio dà un messaggio di errore un pò più specifico ma in questo caso ho ottenuto solo questo... E sono riuscito a risolverlo solo facendo seguire la sezione "Forwarders" alla altre due direttive...

    Riavvio il demone, anche per verificare che funzioni tutto: Il nome del servizio è diverso da quello che si trova su ubuntu, quindi il comando è:
    codice:
    sudo /etc/init.d/bind9 restart
    Questa configurazione mi permette di avere il mio server DNS in modalità "caching name server" configurato e funzionante. Per far sì che il server stesso interroghi se stesso come DNS devo però aggiornare anche il file /etc/resolv.conf, utilizzato in precedenza per configurare i DNS del server.
    codice:
     sudo nano /etc/resolv.conf
    e sostituire agli IP registrati come nameserver l'IP del server, meglio se utilizzando l'IP del localhost. Il mio resolv.conf diventa quindi:
    codice:
    nameserver 127.0.0.1
    Si potrebbe indicarne anche più di uno (basta elencarli di uno per riga allo stesso modo) per permettere al server di navigare comunque anche in caso di problemi con bind ma, se non diventa necessario, preferisco fare così.

    A questo punto, posso fare un test per verificare la velocità del DNS. Ovviamente quello che stò utilizzando è uno strumento di caching: quindi la prima volta che interrogo il DNS relativamente ad un dominio specifico la risposta potrebbe non essere superlativa. Il vantaggi maggiori si ottengono in LAN con più client (l'interrogazione di uno è valida per fare caching anche per tutti gli altri) ma dalle successive, il risultato è decisamente migliore.
    Il primo screen riporta il tempo impiegato dal DNS 151.99.125.2, di Telecom Italia ed il secondo il tempo di risposta del mio DNS, ovviamente dopo la seconda interrogazione:

    Il riavvio di bind ne azzera la cache sarà necessario rigenerarla ad ogni riavvio del servizio.

    Verificato che il servizio funziona egregiamente posso modificare le impostazioni del DHCP per distribuire ai client della mia LAN l'IP del server con DNS primario e magari come secondario un altro DNS.
    Nel file di configurazione del DHCP quindi modifichiamo questa riga
    codice:
    option domain-name-servers 208.67.222.222, 208.67.220.220;
    in
    codice:
    option domain-name-servers 192.168.100.150, 208.67.222.222, 193.205.245.5;
    In questo modo, se il servizio DNS sul nostro serverino dovesse smettere di funzionare i client potrebbero comunque navigare su internet, in quando avrebbero la possibilità di interrogare il DNS secondario o terziario. Di massima, dopo un periodo iniziale di test o affinamento è meglio però lasciare come DNS solo il mio server, soprattutto se si intende implementare anche la funzionalità di master dns server descritta di seguito.

    In ultimo, apportiamo anche le seguenti modifiche al file /etc/network/interface:
    codice:
    # The loopback network interface
    auto lo
    iface lo inet loopback
    
    # The primary network interface - Outside -
    auto eth0
    allow-hotplug eth0
    iface eth0 inet static
                 address 192.168.50.2
                 netmask 255.255.255.0
                 gateway 192.168.50.1
                 dns-nameservers 208.57.222.222 151.99.125.2 8.8.8.8
                 broadcast 192.168.50.255
                 pre-up /etc/firewall
    
    # Scheda di rete secondaria - Inside -
    auto eth1
    allow-hotplug eth1
    iface eth1 inet static
                 address 192.168.100.150
                 netmask 255.255.255.0
                 dns-search fracassetti.lan
                 dns-nameservers 192.168.100.150
                 broadcast 192.168.100.255

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  3. #23
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    43
    Messaggi
    23,379
    configurazione

    Predefinito 5.2_ Installazione del server DNS: Master name server

    Voglio ora configurare il server DNS in esecuzione sul mio server per risolvere anche i nomi della mia rete locale (e diventare quindi Master name server per il dominio della mia rete locale).

    Come prima cosa devo quindi creare le zone primarie, i "registri" che il DNS utilizzerà per tenere traccia degli host che si collegano alla mia rete. Per farlo è necessario agire su uno dei due files di configurazione di Bind che avevo indicato come uno dei files che ne gestiscono il contenuto, il named.conf.local.
    Il files "named.conf.default-zones" fornisce dei contenuti di default necessari per il funzionamento generico e definisce le master zone che vediamo configurate nel nostro DNS se ci colleghiamo al pannello di webmin.
    Il "contenuto" di un server DNS sono le "zone di ricerca" che vi sono definite. Esistono due tipi di "zona" nel sistema DNS: La zona di ricerca diretta (che dal nome host permette di risalire ad un indirizzo IP) e la zona di ricerca inversa (che permette invece di risalire dall'indirizzo Ip al nome host).

    Un breve premessa:
    Il nome di un computer in rete è identificato da un nome host e vari livelli di dominio. Ad esempio, www.nexthardware.com identifica la macchina denominata "www" nel dominio di secondo livello "nexthardware" appartenente al dominio di primo livello ".com". L'insieme del nome host e di tutti i livelli di dominio si chiama "FQDN" (fully qualified domain name o nome di dominio completamente qualificato) e è l'FQDN che identifica un computer all'interno di una rete e solo l'FQDN può essere risolto dal DNS. E' necessario quindi, se voglio che il mio computer sia in grado di individuare il pc denominato "SALOTTO" presente all'interno della mia rete scrivendo solo il nome e non tutto l'FQDN, che il mio computer sappia che deve completare il nome "SALOTTO" con quello che si chiama "dominio di ricerca" e che nel mio caso è "fracassetti.lan". Questa informazione si dà inserendo la direttiva "search" nel file "/etc/resolv.conf" che diventa quindi
    codice:
    search fracassetti.lan
    nameserver 127.0.0.1
    Per popolare il mio DNS devo quindi creare due zone per la mia rete locale (una di ricerca diretta ed una di ricerca inversa) per le quali il mio server sarà "Master server". Creare le zone a mano di per sè è semplice, è sufficiente aggiungere in fondo al file named.conf.local le tre righe che definiscono l'esistenza di una zona:
    codice:
    zone "fracassetti.lan" {
    	type master;
    	file "/var/lib/bind/fracassetti.lan.hosts";
    	};
    
    zone "100.168.192.in-addr.arpa" {
    	type master;
    	file "/var/lib/bind/192.168.200.rev";
    	};
    Una configurazione di base di Bind non è quindi complicatissima ma la zona DNS ha una sua sintassi ed alcuni requisti fondamentali senza i quali non viene riconosciuta come valida. Quello che ho qui definito dice a Bind che esiste una zona definita "fracassetti.lan" per cui lui è autorevole ma ancora non contiene alcuna informazione e quindi bind non sarà in grado di dare alcuna risposta ad una interrogazione relativa a questa zona. Ci sono dei campi obbligatori e delle informazioni minime indispensabili perchè il DNS possa restituire delle risposte valide alle interrogazioni dei client che riguardano soprattutto la temporizzazione della validità di queste risposte. Senza scendere troppo nel dettaglio, preferisco utilizzare il wizard di webmin per creare una "master zone" minimale e popolarla con i dati minimi indispensabili perchè funzioni correttamente. La documentazione alla base del funzionamento del DNS è ampia e, anche se una descrizione minimale non sarebbe troppo lunga, non rientra tra i miei scopi.

    La procedura è semplice: Dal menù di webmin "Servers -> BIND DNS Server" selezionare il link "Create Master Zone" dal gruppo di link nella parte centrale della pagina.

    E' necessario creare due master zone, una per la zona di ricerca diretta (il cui nome corrisponde al nostro dominio) e una zona di ricerca inversa il cui nome si compone, in questo caso, dai primi tre gruppi dell'indirizzamento che costituisce la nostra rete, riportati però da destra verso sinistra (terzo-secondo-primo). Il discorso è un pò più complesso ma serve per ottimizzare la ricerca del nome di un host partendo dal suo indirizzo IP.
    Inserendo le informazioni richieste da webmin e lasciando a default gli altri parametri, otteniamo quindi una "Master zone" identica a come l'avremmo definita manualmente e la creazione di un file, in questo caso denominato "/var/lib/bind/fracassetti.lan.hosts" con il contenuto della zona fracassetti.lan:
    codice:
    $ttl 38400
    fracassetti.lan.	IN	SOA	server.fracassetti.lan. utente.dominio.dom. (
    			1311519410
    			10800
    			3600
    			604800
    			38400 )
    fracassetti.lan.	IN	NS	server.fracassetti.lan.
    e per la zona di ricerca inversa un file denominato "/var/lib/bind/192.168.100.rev":
    codice:
    $ttl 38400
    100.168.192.in-addr.arpa.	IN	SOA	server.fracassetti.lan. utente.dominio.dom. (
    			1311519476
    			10800
    			3600
    			604800
    			38400 )
    100.168.192.in-addr.arpa.	IN	NS	server.fracassetti.lan.
    Notare il formato in cui viene riportato l'indirizzo email.

    Da una lettura veloce, vediamo che il contenuto riporta i dati inseriti nel wizard di webmin. La zona così creata è però vuota: Non ci sono host registrati, neppure lo stesso "server.fracassetti.lan" che è indicato come il server di riferimento ed è quindi sostanzialmente inutile. E' necessario procedere a fare almeno con questa registrazione, per completare la configurazione di base del mio DNS. Per registrare il nome host del mio server posso procedere da Webmin, selezionando la master zone "fracassetti.lan" e, dalla schermata successiva, l'icona "Address record":

    oppure posso aggiungere in calce al file fracassetti.lan.hosts, sempre con i permessi di superutente in quanto il file di zona per ora appartiene a root, la riga con la definizione del record:
    codice:
    server.fracassetti.lan. IN      A       192.168.100.150
    Onestamente è una delle poche cose che preferisco fare da webmin...

    Testando la mia zona, verifico anche che funzioni l'impostazione relativa al dominio di ricerca:

    Ok!
    Decido di creare anche un record nel DNS anche per il dominio (nel mio caso fracassetti.lan) che punti al server DNS stesso.

    Per testare le zone DNS ci sono strumenti più appropriati del semplice "ping" che ho usato sopra... nslookup o dig sono tool creati allo scopo e quindi sicuramente più indicati ma a me interessava mostrare un risultato pratico. Avrei potuto ottenere lo stesso risultato, ad esempio, scrivendo solo "https://server:15000" nella barra degli url del browser: Il funzionamento corretto del DNS mi avrebbe portato direttamente alla schermata di login di webmin.
    Ultima modifica di frakka : 22-08-2011 a 15:24

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  4. #24
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    43
    Messaggi
    23,379
    configurazione

    Predefinito 6_ Integrazione dei servizi DHCP e DNS: DDNS

    L'integrazione dei servizi DHCP e DNS non è, concettualmente, una cosa complessa: mano a mano che il DHCP assegna un indirizzo ad un client comunica al DNS quale FQDN ha ottenuto un determinato indirizzo IP. Questo permette al DNS di tenere costantemente aggiornate sia la zona di ricerca diretta che quella di ricerca inversa. In questo modo non devo conoscere l'IP di ogni macchina che si registra sulla mia rete per raggiungerla ma mi basterà saperne il nome.
    Anche nella pratica non è difficile ma è necessario però ricordarsi che una zona su cui è attivo l'aggiornamento dinamico non deve essere aggiornata manualmente. Dopo aver attivato l'aggiornamento dinamico devo quindi ricordarmi che non posso aggiungere a mano registrazioni sul DNS senza avere prima provveduto a "freezare" la zona.

    A questo proposito, per evitare confusione o dimenticanze è consigliabile scegliere una strada (consolle o interfaccia grafica) e proseguire con quella: Per quanto mi riguarda, preferisco finire la configurazione tramite la consolle e, dopo il riavvio, proseguire solo utilizzando webmin per l'aggiornamento delle registrazioni DNS.

    Per quanto riguarda debian, possiamo adattare le informazioni trovate nel solito blog con le informazioni trovate in quest'altro blog, specifiche per la versione di isc-dhcp che stò usando.
    Le due guide seguono un metodo leggermente diverso: Una genera una nuova chiave di cifratura specifica per il servizio di aggiornamento del DNS mentre l'altra riutilizza la chiave di rndc. Avrei voluto procedere nel secondo modo ma riutilizzando la chiave di rndc (forse per un problema con la cifratura della chiave?) il DHCP effettivamente non aggiornava la zona del DNS e nei log di sistema trovavo registrato questo errore:
    codice:
    Jul 16 21:01:56 server named[3320]: client 127.0.0.1#35841: updating zone 'fracassetti.lan/IN': error: journal open failed: unexpected error
    Generando una nuova chiave, sono riuscito ad aggirare il problema.

    Già dalla configurazione di default del DNS Debian conserva i file delle zone in /var/lib/bind piuttosto che in /etc/named quindi i primi step della guida di lani78 dovrebbero essere applicati. Al limite, è il caso di verificare i permessi sulla directory ed eventualmente eseguire il comando
    codice:
     sudo chown -R bind:bind /var/lib/bind
    per cambiare la proprietà del file ed essere sicuri che bind abbia i permessi per leggere e scrivere nei files delle zone.
    Ho quindi generato la nuova chiave, che ho però deciso di chiamare "DHCP-KEY". E' una modifica solo "cosmetica", non cambia la sostanza. I comandi utilizzati sono:
    codice:
    sudo dnssec-keygen -r /dev/urandom -a HMAC-MD5 -b 128 -n USER DHCP-KEY
    sudo cat KDHCP-KEY.*.private | grep Key
    Il primo comando genera la chiave "DHCP-KEY", il secondo la mostra a video. I due files vengono creati nella directory in cui mi trovo quindi vedo di appuntarmelo perchè, una volta finita la procedura, dovrò eliminarli.

    A questo punto ho editato il file /etc/bind/named.conf.local per aggiungere alle due zone definite l'istruzione che ne autorizza l'aggiornamento da parte del DHCP. Tale istruzione è "allow-update { key DHCP-KEY; };" che sostanzialmente autorizza i servizi che si presentano a bind usando la secret key "DHCP-KEY" ad aggiornare le due zone DNS. Il mio /etc/bind/named.conf.local diventa quindi:
    codice:
    // Do any local configuration here
    //
    
    // Consider adding the 1918 zones here, if they are not used in your
    // organization
    //include "/etc/bind/zones.rfc1918";
    
    key DHCP-KEY {
        algorithm HMAC-MD5.SIG-ALG.REG.INT;
    
        # Important: Replace this key with your generated key.
        # Also note that the key should be surrounded by quotes.
        secret "O/ejTdPuFsU7URlVHo8Rxg==";
    };
    
    zone "fracassetti.lan" {
    	type master;
    	file "/var/lib/bind/fracassetti.lan.hosts";
    	allow-update { key dhcp-key; };
    	};
    
    zone "100.168.192.in-addr.arpa" {
    	type master;
    	file "/var/lib/bind/192.168.100.rev";
    	allow-update { key dhcp-key; };
    	};
    Bind è ora pronto a ricevere gli aggiornamenti.

    E' necessari ora configurare il DHCP per aggiornare bind ogni volta che ad un host viene assegnato un indirizzo IP. Editiamo quindi il nostro file di configurazione del servizio DHCP con il comando
    codice:
     sudo nano /etc/dhcp/dhcpd.conf
    inserendo le direttive in rosso:
    codice:
    #
    # Sample configuration file for ISC dhcpd for Debian
    #
    #
    
    # The ddns-updates-style parameter controls whether or not the server will
    # attempt to do a DNS update when a lease is confirmed. We default to the
    # behavior of the version 2 packages ('none', since DHCP v2 didn't
    # have support for DDNS.)
    ddns-updates on;
    ddns-update-style interim;
    ddns-domainname "fracassetti.lan";
    ddns-rev-domainname "in-addr.arpa.";
    update-static-leases on;
    update-optimization  false;
    
    # Usa gli FQDN configurati nei client
    allow client-updates;
    
    # option definitions common to all supported networks...
    option domain-name "fracassetti.lan";
    option domain-name-servers 192.168.200.1;
    
    default-lease-time 600;
    max-lease-time 7200;
    
    # If this DHCP server is the official DHCP server for the local
    # network, the authoritative directive should be uncommented.
    authoritative;
    
    # Use this to send dhcp log messages to a different log file (you also
    # have to hack syslog.conf to complete the redirection).
    log-facility local7;
    
    # [...]
    
    # Configurazione dello scope per la mia rete locale:
    subnet 192.168.100.0 netmask 255.255.255.0 {
    
    # Secret-key per l'aggiornamento DDNS
     key "DHCP-KEY" {
          algorithm HMAC-MD5.SIG-ALG.REG.INT;
          secret "O/ejTdPuFsU7URlVHo8Rxg==";
     }
    
    # Zona di forward
    zone fracassetti.lan. {
    	primary 127.0.0.1;
    	key DHCP-KEY;
    }
    
    # Zona di reverse
    zone 100.168.192.in-addr.arpa. {
    	primary 127.0.0.1;
    	key DHCP-KEY;
    }
    
      range 192.168.100.200 192.168.100.220;
      option domain-name-servers 192.168.100.150;
      option domain-name "fracassetti.lan";
      option routers 192.168.100.150;
      option broadcast-address 192.168.100.255;
      default-lease-time 600;
      max-lease-time 7200;
    # pc salotto
    	host salotto {
    		hardware ethernet 00:18:f3:82:82:fd;
    		fixed-address 192.168.100.201;
    		}
    }
    Salvare, chiudere e riavviare i servizi DNS e DHCP con il solito comando
    codice:
    sudo /etc/init.d/bind9 restart
    sudo  /etc/init.d/isc-dhcp-server restart
    verificando che non restituisca errori.

    Per verificare il funzionamento della procedura è necessario che un client si registri con il DHCP e poi è sufficiente verificare che il dns lo conosca. Questo si può fare in diversi modi ad esempio, dopo che il client ha preso l'indirizzo IP, è sufficiente interrogare il DNS e vedere se il nome host è conosciuto. Per farlo basta aprire un prompt e digitare il comando:
    codice:
    nslookup salotto
    Se la risposta (da un client linux) è questa:
    codice:
    nslookup salotto
    Server:		192.168.100.150
    Address:	192.168.100.150#53
    
    Name:	salotto.fracassetti.lan
    Address: 192.168.100.201
    allora la procedura funziona. Se la procedura invece restituisce una cosa del genere:
    codice:
    nslookup salotto
    Server:		192.168.100.150
    Address:	192.168.100.150#53
    
    Non-authoritative answer:
    Name:	salotto
    Address: 67.215.65.132
    oppure un errore tipo "nxdomain" allora c'è qualcosa che non va.

    Si potrebbe anche verificare direttamente da webmin se la procedura funziona: Dal menù "Servers -> DHCP Server" è possibile premere il pulsante "List active Lease" per vedere le attribuzioni di indirizzi IP attualmente in funzione e dal menù "Servers -> Bind DNS Server -> " possiamo accedere alla sezione "Address" oppure "Edit record file" per vedere le registrazioni attualmente presenti nel DNS. Prima consiglio però di "freezare" la zona con l'apposito pulsante altrimenti potrebbe accadere che non si vedano anche registrazioni effettivamente funzionanti (è poi necessario ricordarsi di "scongelare" la zona al termine, altrimenti l'aggiornamento dinamico si blocca.)

    Tramite webmin, è possibile consultare il log di bind e dhcp dal menù "System -> System logs -> File /var/log/syslog -> View.."
    Queste registrazione indicato un'assegnazione di IP da parte del server DHCP, l'aggiornamento delle zona zona diretta ed inversa e nessun errore di aggiornamento del DNS quindi va bene:
    Originariamente inviato da /var/log/syslog
    Jul 24 17:36:34 server named[1373]: client 127.0.0.1#59132: signer "dhcp-key" approved
    Jul 24 17:36:34 server named[1373]: client 127.0.0.1#59132: updating zone 'fracassetti.lan/IN': adding an RR at 'salotto.fracassetti.lan' A
    Jul 24 17:36:34 server named[1373]: client 127.0.0.1#59132: updating zone 'fracassetti.lan/IN': adding an RR at 'salotto.fracassetti.lan' TXT
    Jul 24 17:36:34 server dhcpd: Added new forward map from salotto.fracassetti.lan to 192.168.100.201
    Jul 24 17:36:34 server named[1373]: client 127.0.0.1#48548: signer "dhcp-key" approved
    Jul 24 17:36:34 server named[1373]: client 127.0.0.1#48548: updating zone '100.168.192.in-addr.arpa/IN': deleting rrset at '201.100.168.192.in-addr.arpa' PTR
    Jul 24 17:36:34 server named[1373]: client 127.0.0.1#48548: updating zone '100.168.192.in-addr.arpa/IN': adding an RR at '201.100.168.192.in-addr.arpa' PTR
    Jul 24 17:36:34 server dhcpd: added reverse map from 201.100.168.192.in-addr.arpa. to salotto.fracassetti.lan
    Jul 24 17:36:34 server dhcpd: DHCPREQUEST for 192.168.100.201 from 00:18:f3:82:82:fd via eth1
    Jul 24 17:36:34 server dhcpd: DHCPACK on 192.168.100.101 to 00:18:f3:82:82:fd (salotto) via eth1
    Verificato che tutto funziona, eliminiamo i due files che compongono la chiave e restringiamo i permessi sui file di configurazione che contengono la secret-key come suggerito dalla guida:
    codice:
    sudo rm Kdhcp_updater.*
    sudo chmod o-r /etc/bind/named.conf.local
    sudo chmod o-r  sudo chmod o-r /etc/dhcp/dhcpd.conf
    In questo modo, vengono tolti i permessi di lettura sui file di bind e dhcp a tutti gli utenti non proprietari dei files o che non appartengono allo user group assegnato al file (nel mio caso il proprietario è root e il gruppo bind/root).

    That's all folks!!


    [EDIT: 14 Ottobre 2011]
    Oggi mi sono accorto che l'aggiornamento dinamico del master server non funzionava più. Analizzando i log, ho trovato delle registrazioni relative all'impossibilità da parte del DHCP di aggiornare il DNS, per problemi di permessi sul file:
    Oct 14 01:07:18 server named[2059]: client 127.0.0.1#45047: signer "dhcp-key" approved
    Oct 14 01:07:18 server named[2059]: client 127.0.0.1#45047: updating zone 'fracassetti.lan/IN': adding an RR at 'arch.fracassetti.lan' A
    Oct 14 01:07:18 server named[2059]: client 127.0.0.1#45047: updating zone 'fracassetti.lan/IN': adding an RR at 'arch.fracassetti.lan' TXT
    Oct 14 01:07:18 server named[2059]: /var/lib/bind/fracassetti.lan.hosts.jnl: create: permission denied
    Oct 14 01:07:18 server named[2059]: client 127.0.0.1#45047: updating zone 'fracassetti.lan/IN': error: journal open failed: unexpected error
    Oct 14 01:07:18 server dhcpd: Unable to add forward map from arch.fracassetti.lan to 192.168.100.215: timed out
    Facendo un paio di verifiche, sembra che in realtà il file con estensione ".jnl" che mantiene il journal della zona sia andato fuori sincro con il contenuto della zona stessa. Il server DNS ha continuato quindi a distribuire i dati che aveva registrati ma non ha più aggiornato la zona con i nuovi record. Probabilmente il problema è stata causato da qualche spegnimento imprevisto del sistema... L'installazione dell'UPS si fà quindi più urgente del previsto.
    Per risolvere il problema arrestato bind, eliminato il file e riavviato il servizio DNS. Probabilmente sarebbe bastato anche freezare la zona, eliminare il file con estensione .jnl e scongelarla ma ho preferito non rischiare. Non sembra un file che può essere corretto a mano!!
    Strano però... Possibile che basti così poco a inchiodare in questo modo l'aggiornamento di un server DNS??

    [EDIT: 22 Ottobre 2011]
    Altro strano comportamento. Mi sono accorto che il mio nuovo computer non veniva registrato nel DNS, pur ottenendo correttamente il lease dal DHCP. Verificando i log, ho trovato questa registrazione:
    Oct 22 12:00:09 server named[1344]: zone fracassetti.lan/IN: arch_UEFI.fracassetti.lan/A: bad owner name (check-names)
    A quanto pare, usare l'underscore "_"nel nome di un host mette in difficoltà bind. Rinominare il computer in "arch-UEFI" dovrebbe risolvere la situazione.

    [EDIT: 09 Dicembre 2011]
    Il problema di Ottobre si è ripresentato, con la stessa soluzione. Sono comparsi però un altro paio di errori nel log e ho notato delle difformità nei files di configurazione rispetto a quanto finora postato. Probabilmente è passato un aggiornamento di bind o di rndc a cui non ho fatto caso e ha cambiato qualcosa nella configurazione. C'è probabilmente da rivedere questa parte e aggiornarla...
    Ultima modifica di frakka : 09-12-2011 a 01:24

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  5. #25
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    43
    Messaggi
    23,379
    configurazione

    Predefinito 7_ Riassunto e conclusioni.

    Direi che c'è tutto, quindi posso considerare praticamente concluso questo lavoro.

    La macchina, dopo circa un mese di utilizzo, sembra funzionare perfettamente in tutte le sue parti: Firewalling, DHCP, DNS... ma progetto è solo agli inizi. Essendo un sistema server a tutti gli effetti si presta praticamente ad ogni tipo di espansione, limitato solamente dalle possibilità dell'hardware che si sceglie di utilizzare. L'unico problema che ho finora riscontrato è quanto segnalato in merito alla SSD a seguito di un arresto anomalo del sistema: E' un problema probabilmente di derivazione bios della mobo o firmware del disco e dubito che sarà risolto in tempi brevi, essendo entrambi i prodotti un pò vecchiotti.
    Ho riprovato la procedura di installazione e configurazione passo-passo più di una volta. Le spiegazioni, i post e gli screen che ho allegato dovrebbero coprire tutta la procedura di installazione che dovrebbe essere, quindi, completa e perfettamente riproducibile, se qualcuno è interessato a farlo.

    Per quanto mi riguarda, le prossime espansioni del sistema riguarderanno sicuramente l'installazione e la configurazione di un client bittorrent (transmission) e di amule in modalità daemon e la configurazione di SAMBA per l'accesso alle share di rete del serverino da parte dei miei client Windows. Forse anche la configurazione di un server FTP (che può sempre far comodo) e la configurazione di un daemon per la gestione dell'UPS, se riesco a recuperare un altro gruppo di continuità da dedicare a questa macchina. In futuro mi piacerebbe anche implementare un server di posta come si deve, magari in grado di gestire domini virtuali...

    Spero che qualcuno avrà la pazienza di leggersi tutto questo pappone e dirmi cosa ne pensa, magari segnalando errori, omissioni e migliorie che posso apportare al progetto.

    Saluti!!
    Ultima modifica di frakka : 05-09-2011 a 19:50

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  6. #26
    ●⁞◌ Ȏrȉzzȏntέ Ðέglȋ ȨvέntȊ ◌⁞●
    Registrato
    Aug 2008
    Località
    Palermo
    Messaggi
    2,952

    Predefinito

    mi fa molto piacere essere il primo a fornire un feedback decisamente positivo al tuo lavoro.

    Non sono riuscito a leggerlo in modo del tutto esaustivo, e mi riprometto di farlo al più presto, ma in un quarto d'ora circa di visione relativamente veloce ho trovato in pratica nulla di sostanziale da rivedere, ritoccare o ampliare. Le piccolezze da rivedere, che inevitabilmente un lavoro così ampio si porta in dote, possono per ora senz'altro attendere alla porta.

    Ritengo sia un lavoro ben strutturato, discretamente approfondito, descritto in maniera precisa e puntuale e, non ultimo, decisamente digeribile anche nella lunga lettura, che porterà senz'altro il lettore interessato al raggiungimento di un utile ed appagante risultato.

    In sintesi, complimenti per la qualità immessa ed il tempo che hai deciso di spenderci sopra


  7. #27
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    43
    Messaggi
    23,379
    configurazione

    Predefinito

    E' l'obbiettivo che mi sono prefisso, quindi grazie!

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  8. #28
    Nexthardware Staff L'avatar di brugola.x
    Registrato
    Feb 2007
    Località
    1/2 lombardo
    Età
    50
    Messaggi
    18,798
    configurazione

    Predefinito

    tantaroba quì
    complimenti Frakka e... grazie

  9. #29
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    43
    Messaggi
    23,379
    configurazione

    Predefinito

    Grazie!!!

    Avrei intenzione di espandere il lavoro con alcuni "moduli", come discusso ma il tempo è tiranno e mi sono un pò impantanato.

    Spero che possa essere utile a qualcuno...

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  10. #30
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    43
    Messaggi
    23,379
    configurazione

    Predefinito 8.1_ Configurazione iniziale di samba.

    La condivisione di files e risorse all'interno di una rete necessita che tutti i sistemi parlino un linguaggio che tutti coloro che devono usufruire delle risorse a disposizione siano in grado di capire. In particolare, se è necessario imporre delle restrizioni all'uso di determinate risorse, è necessario che tutti gli attori in gioco siano in grado di identificare i parametri che determinano tali restrizioni.

    Il linguaggio comune è il "protocollo" usato per inviare o rendere disponibili determinate informazioni. Il protocollo attualmente utilizzato per la condivisione di risorse come files e stampanti all'interno di una rete Windows è il protocollo SMB (server message block) di Microsoft, derivato da NetBios (sviluppato nel lontano 1984 da IBM).
    Perchè un sistema basato su Linux come il mio server sia in grado di accedere alle condivisioni di rete di un computer Windows oppure di offrire ad una rete Windows le proprie risorse è necessario quindi che anche il mio server parli il protocollo SMB.

    Samba è un software pensato per la condivisione di files e risorse all'interno di rete aziendali, che prevedono molti utenti e la necessità di gestirne le varie restrizioni. Con l'aiuto della guida di zmo, sempre dal forum debianizzati.org è possibile realizzare la configurazione anche complessa ma, in questo caso specifico, non ho stampanti da condividere, non voglio creare altri utenti sul server e la rete che disporrà delle risorse è la mia rete locale di casa.
    WebMin dispone di un modulo di configurazione anche per questa funzionalità, raggiungibile nel menù "Servers -> Samba Windows File Sharing" ma questo modulo è, appunto, adeguato a gestire un'infrastruttura complessa. Preferisco quindi ricorrere alla configurazione rapida di una share di rete senza restrizioni come indicato nella guida di Keltik sempre sul forum di debianizzati.org

    Il server Samba ho scelto di preinstallarlo in fase di setup, quindi non ci dovrebbe essere altro da installare. Quello che voglio fare ora, è configurare samba perchè mostri una share di rete che faccia riferimento alla directory "/download" su cui è stato montato lo spazio rimasto disponibile sul disco da 750Gb.

    Secondo la guida, ora devo creare un utente "guest" che possa fornire l'accesso non autenticato alle mie share di rete:
    codice:
    adduser guest --home=/home/guest --shell=/bin/false --disabled-password
    [sudo] password for matteo: 
    Adding user `guest' ...
    Adding new group `guest' (1001) ...
    Adding new user `guest' (1001) with group `guest' ...
    Creating home directory `/home/guest' ...
    Copying files from `/etc/skel' ...
    Changing the user information for guest
    Enter the new value, or press ENTER for the default
    	Full Name []: 
    	Room Number []: 
    	Work Phone []: 
    	Home Phone []: 
    	Other []: 
    Is the information correct? [Y/n] y
    Le informazioni per l'utente non mi interessano, lascio tutto vuoto e confermo. editando con nano il file "/etc/passwd" in effetti all'ultima riga compare il mio utente, quindi il comando e la creazione del file sono andati a buon fine.

    Prima di configurare samba, faccio la solita copia di backup del file di configurazione "/etc/samba/smb.conf". Il software è stato installato e preconfigurato in fase di setup quindi il mio per ora risulta:
    codice:
    #
    # Sample configuration file for the Samba suite for Debian GNU/Linux.
    #
    #
    # This is the main Samba configuration file. You should read the
    # smb.conf(5) manual page in order to understand the options listed
    # here. Samba has a huge number of configurable options most of which 
    # are not shown in this example
    #
    # Some options that are often worth tuning have been included as
    # commented-out examples in this file.
    #  - When such options are commented with ";", the proposed setting
    #    differs from the default Samba behaviour
    #  - When commented with "#", the proposed setting is the default
    #    behaviour of Samba but the option is considered important
    #    enough to be mentioned here
    #
    # NOTE: Whenever you modify this file you should run the command
    # "testparm" to check that you have not made any basic syntactic 
    # errors. 
    # A well-established practice is to name the original file
    # "smb.conf.master" and create the "real" config file with
    # testparm -s smb.conf.master >smb.conf
    # This minimizes the size of the really used smb.conf file
    # which, according to the Samba Team, impacts performance
    # However, use this with caution if your smb.conf file contains nested
    # "include" statements. See Debian bug #483187 for a case
    # where using a master file is not a good idea.
    #
    
    #======================= Global Settings =======================
    
    [global]
    
    ## Browsing/Identification ###
    
    # Change this to the workgroup/NT-domain name your Samba server will part of
       workgroup = fracassetti.lan
    
    # server string is the equivalent of the NT Description field
       server string = %h server
    
    # Windows Internet Name Serving Support Section:
    # WINS Support - Tells the NMBD component of Samba to enable its WINS Server
    #   wins support = no
    
    # WINS Server - Tells the NMBD components of Samba to be a WINS Client
    # Note: Samba can be either a WINS Server, or a WINS Client, but NOT both
    ;   wins server = w.x.y.z
    
    # This will prevent nmbd to search for NetBIOS names through DNS.
       dns proxy = no
    
    # What naming service and in what order should we use to resolve host names
    # to IP addresses
    ;   name resolve order = lmhosts host wins bcast
    
    #### Networking ####
    
    # The specific set of interfaces / networks to bind to
    # This can be either the interface name or an IP address/netmask;
    # interface names are normally preferred
    ;   interfaces = 127.0.0.0/8 eth0
    
    # Only bind to the named interfaces and/or networks; you must use the
    # 'interfaces' option above to use this.
    # It is recommended that you enable this feature if your Samba machine is
    # not protected by a firewall or is a firewall itself.  However, this
    # option cannot handle dynamic or non-broadcast interfaces correctly.
    ;   bind interfaces only = yes
    
    
    
    #### Debugging/Accounting ####
    
    # This tells Samba to use a separate log file for each machine
    # that connects
       log file = /var/log/samba/log.%m
    
    # Cap the size of the individual log files (in KiB).
       max log size = 1000
    
    # If you want Samba to only log through syslog then set the following
    # parameter to 'yes'.
    #   syslog only = no
    
    # We want Samba to log a minimum amount of information to syslog. Everything
    # should go to /var/log/samba/log.{smbd,nmbd} instead. If you want to log
    # through syslog you should set the following parameter to something higher.
       syslog = 0
    
    # Do something sensible when Samba crashes: mail the admin a backtrace
       panic action = /usr/share/samba/panic-action %d
    
    
    ####### Authentication #######
    
    # "security = user" is always a good idea. This will require a Unix account
    # in this server for every user accessing the server. See
    # /usr/share/doc/samba-doc/htmldocs/Samba3-HOWTO/ServerType.html
    # in the samba-doc package for details.
    #   security = user
    
    # You may wish to use password encryption.  See the section on
    # 'encrypt passwords' in the smb.conf(5) manpage before enabling.
       encrypt passwords = true
    
    # If you are using encrypted passwords, Samba will need to know what
    # password database type you are using.  
       passdb backend = tdbsam
    
       obey pam restrictions = yes
    
    # This boolean parameter controls whether Samba attempts to sync the Unix
    # password with the SMB password when the encrypted SMB password in the
    # passdb is changed.
       unix password sync = yes
    
    # For Unix password sync to work on a Debian GNU/Linux system, the following
    # parameters must be set (thanks to Ian Kahan < for
    # sending the correct chat script for the passwd program in Debian Sarge).
       passwd program = /usr/bin/passwd %u
       passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
    
    # This boolean controls whether PAM will be used for password changes
    # when requested by an SMB client instead of the program listed in
    # 'passwd program'. The default is 'no'.
       pam password change = yes
    
    ########## Domains ###########
    
    # Is this machine able to authenticate users. Both PDC and BDC
    # must have this setting enabled. If you are the BDC you must
    # change the 'domain master' setting to no
    #
    ;   domain logons = yes
    #
    # The following setting only takes effect if 'domain logons' is set
    # It specifies the location of the user's profile directory
    # from the client point of view)
    # The following required a [profiles] share to be setup on the
    # samba server (see below)
    ;   logon path = \\%N\profiles\%U
    # Another common choice is storing the profile in the user's home directory
    # (this is Samba's default)
    #   logon path = \\%N\%U\profile
    
    # The following setting only takes effect if 'domain logons' is set
    # It specifies the location of a user's home directory (from the client
    # point of view)
    ;   logon drive = H:
    #   logon home = \\%N\%U
    
    # The following setting only takes effect if 'domain logons' is set
    # It specifies the script to run during logon. The script must be stored
    # in the [netlogon] share
    # NOTE: Must be store in 'DOS' file format convention
    ;   logon script = logon.cmd
    
    # This allows Unix users to be created on the domain controller via the SAMR
    # RPC pipe.  The example command creates a user account with a disabled Unix
    # password; please adapt to your needs
    ; add user script = /usr/sbin/adduser --quiet --disabled-password --gecos "" %u
    
    # This allows machine accounts to be created on the domain controller via the 
    # SAMR RPC pipe.  
    # The following assumes a "machines" group exists on the system
    ; add machine script  = /usr/sbin/useradd -g machines -c "%u machine account" -d /var/lib/samba -s /bin/false %u
    
    # This allows Unix groups to be created on the domain controller via the SAMR
    # RPC pipe.  
    ; add group script = /usr/sbin/addgroup --force-badname %g
    
    ########## Printing ##########
    
    # If you want to automatically load your printer list rather
    # than setting them up individually then you'll need this
    #   load printers = yes
    
    # lpr(ng) printing. You may wish to override the location of the
    # printcap file
    ;   printing = bsd
    ;   printcap name = /etc/printcap
    
    # CUPS printing.  See also the cupsaddsmb(8) manpage in the
    # cupsys-client package.
    ;   printing = cups
    ;   printcap name = cups
    
    ############ Misc ############
    
    # Using the following line enables you to customise your configuration
    # on a per machine basis. The %m gets replaced with the netbios name
    # of the machine that is connecting
    ;   include = /home/samba/etc/smb.conf.%m
    
    # Most people will find that this option gives better performance.
    # See smb.conf(5) and /usr/share/doc/samba-doc/htmldocs/Samba3-HOWTO/speed.html
    # for details
    # You may want to add the following on a Linux system:
    #         SO_RCVBUF=8192 SO_SNDBUF=8192
    #   socket options = TCP_NODELAY
    
    # The following parameter is useful only if you have the linpopup package
    # installed. The samba maintainer and the linpopup maintainer are
    # working to ease installation and configuration of linpopup and samba.
    ;   message command = /bin/sh -c '/usr/bin/linpopup "%f" "%m" %s; rm %s' &
    
    # Domain Master specifies Samba to be the Domain Master Browser. If this
    # machine will be configured as a BDC (a secondary logon server), you
    # must set this to 'no'; otherwise, the default behavior is recommended.
    #   domain master = auto
    
    # Some defaults for winbind (make sure you're not using the ranges
    # for something else.)
    ;   idmap uid = 10000-20000
    ;   idmap gid = 10000-20000
    ;   template shell = /bin/bash
    
    # The following was the default behaviour in sarge,
    # but samba upstream reverted the default because it might induce
    # performance issues in large organizations.
    # See Debian bug #368251 for some of the consequences of *not*
    # having this setting and smb.conf(5) for details.
    ;   winbind enum groups = yes
    ;   winbind enum users = yes
    
    # Setup usershare options to enable non-root users to share folders
    # with the net usershare command.
    
    # Maximum number of usershare. 0 (default) means that usershare is disabled.
    ;   usershare max shares = 100
    
    #======================= Share Definitions =======================
    
    [homes]
       comment = Home Directories
       browseable = no
    
    # By default, the home directories are exported read-only. Change the
    # next parameter to 'no' if you want to be able to write to them.
       read only = yes
    
    # File creation mask is set to 0700 for security reasons. If you want to
    # create files with group=rw permissions, set next parameter to 0775.
       create mask = 0700
    
    # Directory creation mask is set to 0700 for security reasons. If you want to
    # create dirs. with group=rw permissions, set next parameter to 0775.
       directory mask = 0700
    
    # By default, \\server\username shares can be connected to by anyone
    # with access to the samba server.
    # The following parameter makes sure that only "username" can connect
    # to \\server\username
    # This might need tweaking when using external authentication schemes
       valid users = %S
    
    # Un-comment the following and create the netlogon directory for Domain Logons
    # (you need to configure Samba to act as a domain controller too.)
    ;[netlogon]
    ;   comment = Network Logon Service
    ;   path = /home/samba/netlogon
    ;   guest ok = yes
    ;   read only = yes
    
    # Un-comment the following and create the profiles directory to store
    # users profiles (see the "logon path" option above)
    # (you need to configure Samba to act as a domain controller too.)
    # The path below should be writable by all users so that their
    # profile directory may be created the first time they log on
    ;[profiles]
    ;   comment = Users profiles
    ;   path = /home/samba/profiles
    ;   guest ok = no
    ;   browseable = no
    ;   create mask = 0600
    ;   directory mask = 0700
    
    [printers]
       comment = All Printers
       browseable = no
       path = /var/spool/samba
       printable = yes
       guest ok = no
       read only = yes
       create mask = 0700
    
    # Windows clients look for this share name as a source of downloadable
    # printer drivers
    [print$]
       comment = Printer Drivers
       path = /var/lib/samba/printers
       browseable = yes
       read only = yes
       guest ok = no
    # Uncomment to allow remote administration of Windows print drivers.
    # You may need to replace 'lpadmin' with the name of the group your
    # admin users are members of.
    # Please note that you also need to set appropriate Unix permissions
    # to the drivers directory for these users to have write rights in it
    ;   write list = root, @lpadmin
    
    # A sample share for sharing your CD-ROM with others.
    ;[cdrom]
    ;   comment = Samba server's CD-ROM
    ;   read only = yes
    ;   locking = no
    ;   path = /cdrom
    ;   guest ok = yes
    
    # The next two parameters show how to auto-mount a CD-ROM when the
    #	cdrom share is accesed. For this to work /etc/fstab must contain
    #	an entry like this:
    #
    #       /dev/scd0   /cdrom  iso9660 defaults,noauto,ro,user   0 0
    #
    # The CD-ROM gets unmounted automatically after the connection to the
    #
    # If you don't want to use auto-mounting/unmounting make sure the CD
    #	is mounted on /cdrom
    #
    ;   preexec = /bin/mount /cdrom
    ;   postexec = /bin/umount /cdrom
    Ultima modifica di frakka : 26-11-2011 a 13:04

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

Pagina 3 di 5
prima
1 2 3 4 5 ultimo

Informazioni Thread

Users Browsing this Thread

Ci sono attualmente 1 utenti che stanno visualizzando questa discussione. (0 utenti e 1 ospiti)

Tags

Regole d'invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
nexthardware.com - © 2002-2022