[pve-devel] [PATCH common v2 2/2] Fix #1234: allows multiple search domains to be set
Emmanuel Kasper
e.kasper at proxmox.com
Tue Apr 11 16:06:38 CEST 2017
First thank you for taking the time to review this.
On 04/11/2017 11:47 AM, Fabian Grünbichler wrote:
> meta: has the previous input about other code paths assuming
> $rc->{search} containing a single entry been addressed?
Yes.
ack resolvconf /usr/share/perl5/PVE/*
brings API2/OpenVZ.pm, API2/Nodes.pm, Cluster.pm and LXC/Setup.pm
* ignoring OpenVZ.pm,
* Nodes.pm only passes the read parameter as is to API clients,
* Cluster.pm expects a single entry ( hence the need to be patched
first, this can be done independently)
* LXC/Setup.pm expect can work with multiple search domains
$searchdomains = $host_resolv_conf->{search};
> On Tue, Apr 04, 2017 at 03:26:24PM +0200, Emmanuel Kasper wrote:
>
> some short description of this commit would be nice here, especially
> regarding the comments/questions below ;)
>
>> ---
>> src/PVE/INotify.pm | 15 ++++++++++-----
>> 1 file changed, 10 insertions(+), 5 deletions(-)
>>
>> diff --git a/src/PVE/INotify.pm b/src/PVE/INotify.pm
>> index 074f8b3..5f08439 100644
>> --- a/src/PVE/INotify.pm
>> +++ b/src/PVE/INotify.pm
>> @@ -539,11 +539,16 @@ sub read_etc_resolv_conf {
>> my $nscount = 0;
>> while (my $line = <$fh>) {
>> chomp $line;
>> - # resolv.conf should *either* have a search or domain, else behaviour is undefined
>> - # see res_init.c in libc, havesearch is set to 0 when a domain entry is found
>> - if ($line =~ m/^(search|domain)\s+(\S+)\s*/) {
>> - $res->{search} = $2;
>> - } elsif ($line =~ m/^\s*nameserver\s+($PVE::Tools::IPRE)\s*/) {
>> + # resolv.conf should *either* have a search or domain, else
>> + # last one found wins, see resolv.conf(5)
>
> resolv.conf(5) also mentions the following limitation for the search
> option (both in Jessie and Stretch):
>
> The search list is currently limited to six domains with a total of 256
> characters.
>
> maybe adding a check for that would make sense?
>
>> + if ($line =~ m/^domain\s+(\S+)\s*$/) {
>> + $res->{search} = $1;
>
> this actually became stricter than the old version - previously the
> (invalid)
>
> domain one two
>
> would have been parsed as "domain one", now it is skipped because the RE
> does not match.
>
> based on the previous feedback I think this is intentional - but it
> would be nice to make this explicit in the commit message
>
>> + }
>> + elsif ($line =~ m/^search\s+((?:\S+\s*)*)$/) {
>> + (my $domains = $1) =~ s/\s+$//;
>
> this would allow an empty search list - does that make sense? it is
> again a change in bevaviour, but this time in the other direction ;)
maybe we should find on a general direction on the question "what to
do with invalid entries in /etc/resolv.conf" ?
my answer would be: just like the libc resolver, silently ignores all
wrong entries, extract the correct ones ?
what do you think ?
that would mean concretly instead of
> if ($line =~ m/^domain\s+(\S+)\s*$/)
capture the first 6 words
and instead of
> if ($line =~ m/^domain\s+(\S+)\s*$/)
we should capture the first word when multiple entries are present
>> + elsif ($line =~ m/^search\s+((?:\S+\s*)*)$/) {
>> + (my $domains = $1) =~ s/\s+$//;
>
> this would allow an empty search list - does that make sense? it is
> again a change in bevaviour, but this time in the other direction ;)
an empty search list does not make sense and should not taken as valid
match (just like the resolver does) again your regexp makes sense
More information about the pve-devel
mailing list