Ich habe einige 17.10-Instanzen in Amazon EC2 auf einem VPC laufen. Wenn ich einen Server neu starte (ich bin mir nicht sicher, ob das bei einem Kaltstart passiert, ich habe es nicht getestet), wird die /etc/resolv.confDatei als leer angezeigt:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
Die Namensauflösung schlägt wie erwartet fehl, beispielsweise beim Herstellen einer Verbindung zu einem Server mit einer statischen IP im privaten Subnetz über seinen internen DNS-Namen:
ssh: Could not resolve hostname example: Temporary failure in name resolution
Wenn ich jetzt eine Zeit lang warte, erscheinen plötzlich die richtigen Werte in /etc/resolv.conf:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
search subdomain.example.com
Der systemd-resolve --statusBefehl meldet dasselbe. Die /etc/resolv.confDatei ist auch richtig eingestellt, wenn ich manuell eine dhclientErneuerung erzwinge, und ich weiß, dass diese Werte vom EC2-DHCP-Server kommen.
Die Frage ist also: Welcher Teil meiner Konfiguration fehlt, der verhindert, dass dies unmittelbar beim Booten geschieht?
Das direkte Hinzufügen dieser Werte zu etwas wie /etc/resolvconf/resolv.conf.d/basewürde funktionieren, aber dann codiere ich etwas fest, das, glaube ich, über DHCP ankommen sollte. Ich habe /etc/netplanauch nachgesehen ( wird nicht verwendet) und dies scheint aus dem Cloud-Init-Zeug zu kommen, also frage ich mich, ob ich vielleicht etwas in oder ähnlichem ifupdownübersehe ?/etc/cloud/cloud.cfg