Diskussion:Entwicklungsumgebung/DHCP

Aus Delixs
Zur Navigation springen Zur Suche springen

DDNS

ist eine feine Sache, machen wir seit Jahren, weil es die Namensauflösung extrem beschleunigt.

Was man dafür braucht ist ein key, der dem bind und dem dhcpd bekannt ist.

in die dhcpd.conf:

allow booting;
server-identifier   192.168.3.2;
option domain-name    "sub.domain.tld";
option domain-name-servers  192.168.3.2;
option subnet-mask    255.255.255.0;
option netbios-node-type  8;    # First WINS,then Broadcast
option netbios-name-servers 192.168.3.3; # Samba
#neu: http://wiki.bsdforen.de/howto/automatische_proxy-konfiguration
option wpad code 252 = text;
option wpad "http://wpad.domain.tld/wpad.dat";
default-lease-time    3600;   # 1h
max-lease-time      86400;    # 1d
authoritative;
# Der DHCPd soll DDNS machen
ddns-update-style   interim;
# Die Clients sollen *nie* selbst DDNS machen, sondern immer der DHCPd
ignore client-updates;
get-lease-hostnames on;
# Anstelle den key anzugeben, sollte auch ein include möglich sein:
# include "/etc/bind/Kbst.domain.tld.+157+35662.key";
key sub.domain.tld {
  algorithm HMAC-MD5.SIG-ALG.REG.INT;
  secret xRLSiTqRBXw[...snip...]UbaAIXUfBpJ4M0XovKQj76Lg==
}; 
zone sub.domain.tld {
  primary 127.0.0.1;
  key sub.domain.tld;
}
zone 3.168.192.in-addr.arpa. {
  primary 127.0.0.1;
  key sub.domain.tld;
}
## END DEFAULTS
# DHCP für Netz sub.domain.tld
subnet 192.168.3.0 netmask 255.255.255.0 {
  option broadcast-address  192.168.3.255;
  option domain-name    "sub.domain.tld";
  option routers      192.168.3.1;
  range       192.168.3.150 192.168.3.199;
  host alix  # Schulserver Installer
  {
    hardware ethernet 00:01:02:03:04:05;
    fixed-address   192.168.3.241;
  }


und dann in die named.conf.local

key sub.domain.tld {
       algorithm hmac-md5;
       secret "xRLSiTqRBE2SG.......ovKQj76Lg==";
};
// sub.domain.tld mit 192.168.3.0/24
zone "sub.domain.tld" IN {
  type master;
  file "db.sub.domain.tld";
  allow-update {key sub.domain.tld;};
};
// 3.168.192.in-addr.arpa für sub.domain.tld
zone "3.168.192.in-addr.arpa" IN {
  type master;
  file "db.192.168.3";
  allow-update {key sub.domain.tld;};
};

Das wars schon. Den Key erstellt man über

 /usr/sbin/dnssec-keygen -a HMAC-MD5 -n HOST -b 512  $DOMAIN.


Wenn auch noch Linuxclients in der /etc/dhcp3/dhcclient.conf ein send host-name "workstation"; stehen haben, sind auch diese mit im Geschäft.

Viele Grüße Thorsten (080606)

X.509-Zertifikate

Zertifikate machen nur dann Sinn, wenn der Dienst der sie benutzt auch verifizieren kann. Dazu gehört nicht nur ein Public/Private Key-Pair, sondern auch, im Falle von Serverdiensten, ein eindeutiger DNS-Name.

Das Problem mit dem eindeutigen DNS-Namen ist etwas diffizil. Fast alle Anwender von ssl, also X.509, benutzen den DNS-Namen des Rechners. Für einfachste Dinge ist das OK. Aber wenn ein Rechner Dienste wie LDAP oder SAMBA bereitstellt, die einen Online-Backup-Dienst ermöglichen, wie PDC + 1 bis 99 BDC, dann ist die Benutzung des realen Hostnamens, als Key-Bezeichner echt schwachsinnig.

Stellt euch vor, der PDC fällt aus. Ein BDC übernimmt vollautomatisch seine Funktion. Der hat aber einen anderen DNS-Namen, damit einen anderen Key und der Admin und alle, die via ssl darauf zugreifen wollen, sind draussen.

Also für solche Dienste muss als Key-Bezeichner ein DNS-Alias genommen werden. Denn der darf auf mehreren DNS-Hostnamen zeigen.

Die DNS-Domain für den aktuellen Rechner:

 hostname -d

Im LDAP stehen nur Kopien des Domain-Namens.

 ldapsearch -x -LLL  "cn=DHCP Service Config" dhcpOption|\
 sed -ne '/^dhcpOption/{N;s/dhcpOption: domain-name //;s/"//g;p}'

Der Installer hat auch eine Kopie gespeichert:

 debconf-get-selections --installer|grep netcfg/get_domain|cut -f4

Es gibt aber keine LDAP-Domain. Nur einen NamingContext:

 ldapsearch -x -LLL -h localhost -s base -b "" "objectclass=*" \ 
 namingcontexts


Red. gekürzt. Text von Harry.