#4424 closed Defekt (erledigt)
Fehlerhafte Namensauflösung auf checkmk2
| Reported by: | Stephan Richter | Owned by: | bau |
|---|---|---|---|
| Priority: | schnell erledigen | Milestone: | Schuljahr 2021/22 |
| Component: | Ich kenne die passende Komponente nicht. | Severity: | beeinträchtigt den Unterricht vieler Lehrer |
| Keywords: | Cc: | Rüdiger Kupper |
Description
Beim installieren von netbox ist mir folgendes aufgefallen:
root@checkmk:~# ping checkmk2 ping: checkmk2: Name or service not known root@checkmk:~# dig checkmk2 ; <<>> DiG 9.16.1-Ubuntu <<>> checkmk2 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 28140 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;checkmk2. IN A ;; AUTHORITY SECTION: . 86395 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2022032700 1800 900 604800 86400 ;; Query time: 4 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sun Mar 27 12:00:40 CEST 2022 ;; MSG SIZE rcvd: 112
Wieso steht hier überhaupt der google-DNS? Wo läuft denn unser interner DNS?
Außerdem: checkmk2 hat als hostname checkmk konfiguriert. Ist das Absicht?
Change History (9)
comment:1 by , 5 years ago
| Severity: | normal → kritisch |
|---|
follow-up: 5 comment:2 by , 5 years ago
Ich habe für checkmk2 einen Internetzugang benötigt und habe die VM mit ihrem eth2 (192.168.150.9) über den ProxmoxLS2 (192.168.150.6) über das Zwischennetz verbunden.
Wenn der Apache checkmk2.kg-fds.de kennen soll, dann ist es am einfachsten, dem einen Eintrag in der /etc/hosts zu machen. Für den VHost muss dann allerdings die Namensauflösung im jeweiligen lokalen Netz korrekt sein (also Einträge auf den jeweiligen DNS (dsmasq benutzt die /etc/hosts) der Netze:
- grün (paedml.kg-fds.de)
- rot (dhcp.kg-fds.de)
- orange (Gastnetzwerk, proxyl.tgs-freudenstadt.de=10.0.0.250 und proxyl.kg-fds.de=10.0.0.249)
- WLAN_iPad (proxmoxls2.kg-fds.de=10.2.0.10)
Im Gastnetzwerk haben wir also schon die Idee mit den multiplen Routern getestet, das funktioniert ja anscheinend recht gut, so dass wir so vorgehen könnten (also alle vier öffentlichen IP (auf ProxmoxLS, ProxmoxLS2, ProxmoxKWRS und ProxmoxTGS) mit Routing versehen, so dass jeweils vier DHCP/DNS/Router verfügbar sind und folglich bis zu drei davon ausfallen können, bevor kein Zugang mehr geht).
comment:4 by , 5 years ago
Ich muss ehrlich sagen, dass ich deine Antwort nicht verstanden habe. Es geht mir auch gar nicht um die Ausfallsicherheit. Auch nicht darum, eine Route nach draußen zu haben.
Ich möchte einfach nur, dass ich, wenn ich an irgend einem internen Rechner checkmk2.kg-fds.de auflöse, immer eine Antwort haben möchte, und möglichst auch immer die gleiche.
Dazu gehört für mich, dass DNS Anfragen intern immer an einen internen DNS gehen. Und wenn ich google.de auflösen möchte, dann macht das mein interner DNS für mich - da muss ich nicht 8.8.8.8 in meiner resolv.conf stehen haben.
Warum heißt der Rechner checkmk, aber der DNS-Eintrag checkmk2?
Daran, für jedes Subnetz einen eigenen DNS zu haben, führt vermutlich kein Weg vorbei, wenn wir Server mit mehreren NICs haben - bzw. ich weiß nicht, ob man das mit DNS-Zonen machen könnte.
comment:5 by , 5 years ago
Replying to bau:
- grün (paedml.kg-fds.de)
- rot (dhcp.kg-fds.de)
- orange (Gastnetzwerk, proxyl.tgs-freudenstadt.de=10.0.0.250 und proxyl.kg-fds.de=10.0.0.249)
- WLAN_iPad (proxmoxls2.kg-fds.de=10.2.0.10)
Wie hängen die Farben mit den VLANs (oder den Subnets) zusammen?
comment:6 by , 5 years ago
Oh, checkmk2 könnte natürlich nun auch wieder checkmk heißen, denn ich habe ja den ursprünglichen checkMK abgeschaltet.
Ja, genau - zum Verständnis: Wenn du im internen Netz einen WebServer aufrufen musst, dann benötigt das eine Namensauflösung - du gibst xyz.kg-fds.de als URL ein, der DNS sagt dem Browser die IP, damit kommst du beim WebServer an. Auf dem Webserver können aber viele VirtualHosts laufen, der Browser schickt die URL mit anhand derer du an den korrekten VHost geleitet wirst. Deshalb ist es wichtig, dass der DNS stimmt. Offenbar braucht der Apache dafür auch nochmals eine korrekte Namensauflösung lokal?
Die Farben haben sich aus dem ipFire ergeben (rot=Internet, grün=päd.Netz, blau=WLAN (obsolet)) wir haben das grau=Lehrernetz hinzugefügt, alle weiteren Netze heißen nicht mehr nach Farben.
comment:7 by , 5 years ago
Gut, dann würde ich die entsprechenden DNS-Einträge auf den vier DNS-Servern ändern.
(Kann ich das direkt in der /etc/hosts machen, oder wird die von irgendwo generiert?)
Wenn der Rechner gleich seiner URL heißt, dann hat sich das Problem vermutlich schon erledigt.
Welchen DNS-Server kann ich dann auch checkmk in die ressolv.conf eintragen?
(Die ganze Netzstruktur müsstest du Rüdiger und mir nochmal (am besten bei einem analogen Treffen) aufzeichnen.)
follow-up: 9 comment:8 by , 5 years ago
| Resolution: | → erledigt |
|---|---|
| Status: | new → closed |
-auf paedml den DNS Eintrag auf checkmk geändert
-auf checkmk habe ich in die resolv.conf 10.32.1.1 als nameserver eingetragen (das sieht auto-generiert aus: "--BEGINN PVE ---" wo wird das konfiguriert?)
-der Apache lauscht auf allen NICs auf Port 80
Ich hoffe ich habe damit die checkmk-Seite nicht zerschossen. Mir ist aber gar nicht klar, wie die ausgeliefert wird, denn der OMD-apache lauscht nur auf 127.0.0.1:5000!?!
(Naiv würde ich da jetzt einen zweiten vhost anlegen, der den checkmk-service als inverser proxy an den OMD-apache durchreicht.)
Langfristig würde ich den Server auch ganz anders nennen ("mondoc" - monitoring/documentation) und dann aber checkmk.kg-fds.de und netbox.kg-fds.de als CNAMEs setzen.
comment:9 by , 5 years ago
Replying to rich:
Ich hoffe ich habe damit die checkmk-Seite nicht zerschossen. Mir ist aber gar nicht klar, wie die ausgeliefert wird, denn der OMD-apache lauscht nur auf 127.0.0.1:5000!?!
Die Details dazu finden sich hier: https://forum.checkmk.com/t/check-mk-deutsch-eigene-sub-domain-fur-check-mk-site-definieren/2987
(Naiv würde ich da jetzt einen zweiten vhost anlegen, der den checkmk-service als inverser proxy an den OMD-apache durchreicht.)
siehe #4430
Das ist jetzt leider ein Blocker für mich, da sich Apache weigert einen VirtualHost anzulegen, wenn er den Namen nicht auflösen kann - und checkmk2.kg-fds.de kennt er nicht.
services hat auch den google-DNS eingetragen. Andere server, wie colabora den BelWue DNS. Zumindest bei mir zu Hause resolven alle Rechner auf den lokalen DNS - und der leitet die Anfragen dann an externe weiter, wenn er sie nicht bedienen kann.
Ich verstehe jetzt leider nur nicht, ob das im Kepler-Netz ein Bug oder ein Feature ist :).