Discussione:Un server DNS e DHCP su Debian: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
m (ha spostato Discussione:Un server DNS e DHCP su Debian Etch a Discussione:Un server DNS e DHCP su Debian: La guida è valida anche per Lenny e Squeeze e il titolo è fuorviante.)
 
(6 versioni intermedie di 2 utenti non mostrate)
Riga 78: Riga 78:


--risca 18:53, 11 mar 2010 (CET)
--risca 18:53, 11 mar 2010 (CET)
Ciao
ho seguito con interesse la tua guida e volevo solo segnalarti due problemi in cui mi sono imbattuto.
Se è un problema non solo mio, allora forse può essere utile segnalarli nella tua guida.
In breve, ho installato tre virtual machine con debian lenny.
Su una ho installato il dns e il dhcp server (debiansrv) seguendo la tua guida. Le altre due facevano da client (debian1 e debian2).
In sostanza questi sono i problemi:
1) -------------------------------
Prima di testare il tutto, ho fatto delle prove con l'utility nsupdate.
Provando con il nsupdate, falliva l'inserimento dei record.
Ho notato che il server che rispondeva era il 127.0.1.1 e non il 127.0.0.1.
Così guardando il file /etc/hosts le prime due righe erano
127.0.0.1    localhost
127.0.1.1    debiansrv.arpa.veneto.it    debiansrv
ho cosi commentato la riga 127.0.1.1
127.0.0.1    localhost
commentata---> 127.0.1.1    debiansrv.arpa.veneto.it    debiansrv
Riavviato. A questo punto nsupdate inseriva correttamente i records A e PTR.
2)  -------------------------------
Dopo aver testato che l'inserimento dinamico dei record A e PTR funzionava, ho fatto la prova finale avviando i due client.
Guardando il log con:
tail -f /var/log/daemon.log
si vedevano le assegnazioni degli ip alle due macchine client ma nessuna attività di named circa la scrittura dei rr A e PTR relative alle due macchine.
Così alla fine guardando un pò su internet ho capito che forse il problema era dovuto al fatto che i client non inviano il loro hostname al dhcp server per cui non succedeva nulla.
C'è un bug segnalato (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=151820) che dice che il client dhcp non invia di default il suo hostname.
Così sono andato sui client in /etc/dhcp3/dhclient.conf e ho decommentato e modificato la seguente linea:
send host-name "debian1"
e altrettanto per debian2
Ho riavviato. Dopodichè tutto ha funzionato correttamente e dal log si vedeva l'attività di named nella scrittura dei record dinamici.
ciao
ciao
scusa la formattazione del commento appena inserito.
Ho fatto il copia e incolla da un file di testo e non mi sono accorto che era cambiata la formattazione.
ciao
massimo
== problema managed-keys-zone... file not found ==
Ciao, complimenti per la guida, davvero ben fatta :)
Volevo segnalare un problema che ho riscontrato e chiedere il tuo parere se val la pena di inserire la seguente informazione nella guida.
In soldoni, dopo aver configurato tutto correttamente nei log appare sempre un errore del tipo:
''managed-keys-zone ./IN/external: loading from master file 3c46[...]d8.mkeys failed: file not found''
Questo è un vecchio bug segnalato: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632274 , ma che non comporta nessun tipo di malfunzionamento di bind.
Ho trovato su internet come risolverlo al meglio e ci sono due scuole di pensiero:
* 1) semplice touch /etc/bind/managed-keys.bind (quindi dargli il file vuoto che cerca)
* 2) inserire in /etc/bind/named.conf le riga: 'include "/etc/bind/bind.keys";'
Il secondo metodo sarebbe quello più corretto perchè utilizza proprio la chiave creata da bind, ma in questo modo per far funzionare il DNS bisogna inserire in named.conf.local le opzioni: dnssec-enable no; dnssec-validation=no; poichè poi bind genera l'errore RSIG segnalato proprio nella guida.
Chiedo scusa per la formattazione e/o qualche eventuale errore, sono ancora poco pratico.
----
--[[Utente:Fexice|Fexice]] 20:00, 2 dic 2012 (CET)
----
Ciao, credo sarebbe meglio che segnalassi la cosa direttamente sul forum; qui potrebbe passare inosservata.<br>
[[Utente:Wtf|Wtf]] 16:59, 3 dic 2012 (CET)

Versione attuale delle 15:59, 3 dic 2012

Ciao, grazie per la guida. La sto seguendo proprio ora sul mio server. Ho riscontrato una serie di problemi che penso sia meglio segnalare. Al momento li elenco per poi verificare meglio la correttezza delle mie affermazioni e delle soluzioni adottate.

Macchina con su Squeeze 2.6.32-trunk-amd64, senza server DHCP (trattasi di una LAN proprio piccola).

Primo problema: la sezione di /etc/bind/named.conf da aggiungere, ovvero:

include "/etc/bind/named.conf.options";
// prime the server with knowledge of the root servers
zone "." {
        type hint;
        file "/etc/bind/db.root";
};
zone "localhost" {
        type master;
        file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
        type master;
        file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
        type master;
        file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
        type master;
        file "/etc/bind/db.255";
};

è ridondante e causa errore di avvio di bind. Infatti quelle informazioni sono già contenute nei file:

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";


Secondo errore riscontrato è dovuto alla non possibilità di accedere a bind/rndc.key Problema risolto cambiando lo user da bind a root (chown root rndc.key)

I problemi li ho risolti leggendo l'output di named -g, come suggerito dai manuali (ovviamente collegato a /var/log/stslog.

Infine, per chi è proprio nubbio come il sottoscritto, magari specificherei che il file /etc/bind/named.conf.options debba essere editato solo all'interno di:

options {
        directory "/var/cache/bind";

...
...
...

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};


Al momento mi sembra funzionare tutto. Grazie per la guida.

Risca


Su Lenny la ridondanza dell'inclusione che causa errore nel riavvio di Bind non c'è. Se riesci a specificarmi con precisione cosa devo togliere, cosa devo lasciare e cosa devo aggiungere ail files di configurazione provvedo ad aggiornare la guida. Il problema di permessi del file rndc.key è un bug di Squeeze. Si veda ad esempio: Bug 409166.
--Ferdybassi 13:53, 10 mar 2010 (CET)


Ciao, appena tornato a casa. Allora purtroppo al momento ho sperimentato solo la prima parte (indirizzi statici) e non quella inerente al DHCP.

Apporterei le seguenti modifiche:

  • le modifiche al file /etc/bind/named.conf non sono più necessarie in Squeeze.

Infatti gli script da te indicati sono già inseriti, tramite richiamo, nel suddetto file (se ti interessa maggiormente la questione te li posto).

  • il bug è ad oggi ancora presente, magari sarebbe il caso di consigliare una verifica al medesimo file durante la configurazione.
  • invece di /var/log/syslog io mi sono trovato meglio con named -g (ovvero: Run the server in the foreground and force all logging to stderr)
  • infine, in Squeeze è possibile sostituire /etc/init.d/bind9 restart con service bind9 start.

Per ora è tutto. Invece scusami a riguardo del file /etc/bind/named.conf.options: funziona bene, purtroppo non avevo letto la sezione per intero. Probabilmente ora proverò anche l'altra parte della guida siccome devo settare un accesso anche per un mac di una terza persona. Ciao

--risca 18:53, 11 mar 2010 (CET)

Ciao

ho seguito con interesse la tua guida e volevo solo segnalarti due problemi in cui mi sono imbattuto. Se è un problema non solo mio, allora forse può essere utile segnalarli nella tua guida.

In breve, ho installato tre virtual machine con debian lenny. Su una ho installato il dns e il dhcp server (debiansrv) seguendo la tua guida. Le altre due facevano da client (debian1 e debian2).

In sostanza questi sono i problemi:

1) -------------------------------

Prima di testare il tutto, ho fatto delle prove con l'utility nsupdate.

Provando con il nsupdate, falliva l'inserimento dei record. Ho notato che il server che rispondeva era il 127.0.1.1 e non il 127.0.0.1.

Così guardando il file /etc/hosts le prime due righe erano

127.0.0.1 localhost 127.0.1.1 debiansrv.arpa.veneto.it debiansrv

ho cosi commentato la riga 127.0.1.1

127.0.0.1 localhost commentata---> 127.0.1.1 debiansrv.arpa.veneto.it debiansrv

Riavviato. A questo punto nsupdate inseriva correttamente i records A e PTR.

2) -------------------------------

Dopo aver testato che l'inserimento dinamico dei record A e PTR funzionava, ho fatto la prova finale avviando i due client.

Guardando il log con: tail -f /var/log/daemon.log

si vedevano le assegnazioni degli ip alle due macchine client ma nessuna attività di named circa la scrittura dei rr A e PTR relative alle due macchine.

Così alla fine guardando un pò su internet ho capito che forse il problema era dovuto al fatto che i client non inviano il loro hostname al dhcp server per cui non succedeva nulla.

C'è un bug segnalato (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=151820) che dice che il client dhcp non invia di default il suo hostname.

Così sono andato sui client in /etc/dhcp3/dhclient.conf e ho decommentato e modificato la seguente linea:

send host-name "debian1"

e altrettanto per debian2

Ho riavviato. Dopodichè tutto ha funzionato correttamente e dal log si vedeva l'attività di named nella scrittura dei record dinamici.


ciao

ciao

scusa la formattazione del commento appena inserito. Ho fatto il copia e incolla da un file di testo e non mi sono accorto che era cambiata la formattazione.

ciao massimo

problema managed-keys-zone... file not found

Ciao, complimenti per la guida, davvero ben fatta :) Volevo segnalare un problema che ho riscontrato e chiedere il tuo parere se val la pena di inserire la seguente informazione nella guida. In soldoni, dopo aver configurato tutto correttamente nei log appare sempre un errore del tipo:

managed-keys-zone ./IN/external: loading from master file 3c46[...]d8.mkeys failed: file not found

Questo è un vecchio bug segnalato: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632274 , ma che non comporta nessun tipo di malfunzionamento di bind.

Ho trovato su internet come risolverlo al meglio e ci sono due scuole di pensiero:

  • 1) semplice touch /etc/bind/managed-keys.bind (quindi dargli il file vuoto che cerca)
  • 2) inserire in /etc/bind/named.conf le riga: 'include "/etc/bind/bind.keys";'

Il secondo metodo sarebbe quello più corretto perchè utilizza proprio la chiave creata da bind, ma in questo modo per far funzionare il DNS bisogna inserire in named.conf.local le opzioni: dnssec-enable no; dnssec-validation=no; poichè poi bind genera l'errore RSIG segnalato proprio nella guida. Chiedo scusa per la formattazione e/o qualche eventuale errore, sono ancora poco pratico.


--Fexice 20:00, 2 dic 2012 (CET)


Ciao, credo sarebbe meglio che segnalassi la cosa direttamente sul forum; qui potrebbe passare inosservata.
Wtf 16:59, 3 dic 2012 (CET)