Fehler bei "pmgconfig sync" wenn "search"-Domain in "/etc/resolv.conf" leer ist

[xenon96]

Hallo erstmal,

ich versuche mein Problem mal etwas gegliederrt darzustellen.


Folgende Situation

Datei / Variable	Soll (laut Dokumentation)	Ist	Hinweis / Notiz
/etc/hostname	a b ...	a.pmg.example.com b.pmg.example.com ...	falsch, siehe folgenden Text ... (beim reboot überschrieben)
/etc/resolv.conf	search pmg.example.com nameserver x.x.x.x nameserver y.y.y.y nameserver z.z.z.z	nameserver x.x.x.x nameserver y.y.y.y nameserver z.z.z.z	falsch, siehe folgenden Text ... (beim reboot überschrieben)

Problem 1 - /etc/hostname enthalt FQDN

Ich habe einen vServer gemietet. Hier kann ich per Web-Oberfläche einen Hostname für die VM setzen (z.B. a.pmg.example.com, nicht aber nur "a"). Das Resultat ist, dass ich in /etc/hostname immer den FQDN habe, also a.pmg.example.com.

Normalerweise sollte es so sein, dass in /etc/hostname nur der Hostname steht, also a. Dann sollte in der /etc/resolv.conf unter dem Wert search der Domain-Name stehen, also pmg.example.com.

Leider wird mir das vom Hosting-Provider mittels Qemu-Agent verwehrt. Hier ist im Sylog folgedne Zeile zu sehen:

qemu-ga: info: guest-exec called: "prl_nettool set --search-domain remove --hostname a.pmg.example.com --ip <mac-address> <ipv4-address>/<netmask> <ipv6-address>/128 --gateway <mac-address> <ipv4-gateway> <ipv6-gateway>"

Der Search-Domainname wird somit bei jedem reboot wieder entfernt, und der Hostname auf den FQDN gesetzt.


Lösung Problem 1

Wie in [1] beschrieben, kann man die PMG-Config scheinbar mittels Templates überschreiben.
Wenn ich in der /etc/pmg/templates/main.cf.in (cp /var/lib/pmg/templates/main.cf.in /etc/pmg/templates/main.cf.in) folgende Zeilen

mydomain = [% dns.domain %]
myhostname = [% dns.hostname %].[% dns.domain %]

durch diese ersetze

mydomain = pmg.example.com
myhostname = a.pmg.example.com

Erhalte ich eine korrekte Datei, vorrausgesetzt ich habe vorher die Search-Domain in der /etc/resolf.conf gesetzt (siehe Problem 2).


Problem 2 - Fehlende Search-Domain in /etc/resolv.conf

Leider erhalte immer folgende Ausgabe bei einem pmgconfig dump:

composed.wl_bounce_relays = a.localdomain
dns.domain = localdomain
dns.fqdn = a.localdomain
dns.hostname = a

Die Ursache hierfür ist scheinbar dass pmgconfig sync --restart 1 folgende Fehlermeldung erzeugt:

Use of uninitialized value $domain in concatenation (.) or string at /usr/share/perl5/PMG/Utils.pm line 643.

Diese Zeile beinhaltet folgenden Code: https://git.proxmox.com/?p=pmg-api....3c3bf608204a4995a3f;hb=refs/heads/master#l643.

Dieser Fehler entsteht aufgrund des fehlenden search Eintrags in der /etc/resolv.conf.

D.h. die Ursache dass die Benutzerdefinierte-Config aus /etc/pmg/templates/main.cf.in (siehe oben) wegen des fehlenden Search-Eintrags nicht übernommen wird.
Sobald ich ein search pmg.example.com in die /etc/resolv.conf aufnehme, scheint der Fehler nicht mehr. In der /etc/postfix/main.cf wurden die Werte mydomain und myhostname auch korrekt gesetzt.

Leider überstehen diese Einstellungen aufgrund des o.g. Problems keinen Reboot.


Lösung Problem 2 - offen

Kann man die Validierung nach search deaktivieren bzw. ignorieren?


---

Allerdings bleibt die Frage, ob die eigene Config in /etc/pmg/templates/* ein Update überstehen?

[1] https://forum.proxmox.com/threads/change-helo-hostname.52582/

 

[Stoiko Ivanov]

Klingt eher nach einem Problem mit dem Hostingprovider.

PMG hat seit langem die search-domain als domain-part genommen - derzeit ist es nicht prioritär das zu ändern - aber es gibt dafür einen enhancement request:
https://bugzilla.proxmox.com/show_bug.cgi?id=1745

Allerdings bleibt die Frage, ob die eigene Config in /etc/pmg/templates/* ein Update überstehen?

ja die templates in /etc/pmg/templates werden mittels ucf verwaltet.
siehe https://packages.debian.org/bullseye/ucf
und https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html#pmgconfig_template_engine

Ich hoffe das hilft!

 

[xenon96]

Vielen Dank! Dann werde ich das Ticket mal in den Augen behalten.

Mein spezifisches Problem konnte ich temporär lösen, indem ich die Binary von "prl_nettool" einfach durch ein leeres Bash-Skript ersetzt habe. Das behebt aber ja auch eher nur die Ursache, aber nicht das Problem an sich.

Je nach dem wie ihr (der Support) das seht könnt ihr diesem Thread auch schließen. Ich habe ja nun eine Referenz.