Page MenuHomeVyOS Platform

Multiple names unable to be assigned to the same static mapping.
Needs testing, Requires assessmentPublicBUG

Description

There's no reason this should be denied:

set system static-host-mapping  host-name test1 inet 10.0.10.100
set system static-host-mapping  host-name test2 inet 10.0.10.100
static-host-mapping "test2" address "10.0.10.100"already used in another static-host-mapping

[[system static-host-mapping]] failed

There's an extra error check in host_name.py causing this.

Details

Difficulty level
Easy (less than an hour)
Version
1.3
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Perfectly compatible

Event Timeline

kroy created this task.Sat, Jun 27, 3:19 AM
kroy changed the task status from Open to In progress.Sat, Jun 27, 3:21 AM
kroy claimed this task.

This PR should correct.

kroy updated the task description. (Show Details)Sat, Jun 27, 3:23 AM
kroy closed this task as Resolved.Sat, Jun 27, 3:53 AM
jjakob reopened this task as Needs testing.Sat, Jun 27, 6:26 AM
jjakob added a subscriber: jjakob.

Have you tested that this actually works as intended? The reason I added that check is that each static-host-mapping "inet" address translates to a line in /etc/hosts. The hosts manpage says there should be only one line for each host:

For each host a single line
       should be present with the following information

I'm not sure how the system behaves when this requirement is broken. Some web searching seems to indicate only the first entry is used and the other ones ignored.

Are you sure this works as intended? You can check it with getent hosts and getent hosts foo.bar.

If you want to point multiple hostnames to a single IP you should use aliases instead so they all get added to a single line in /etc/hosts.

kroy added a comment.EditedSat, Jun 27, 6:38 AM

I guess there's two ways to approach it. This is the correct way:

10.0.100.12 host1 host2

vs

10.0.100.12 host1
10.0.100.13 host1

or

10.0.100.12 host1
10.0.100.12 host2

The first should be allowed. The second and third don't make sense.

I was only considering the second one with that patch.

So you are correct, my patch is definitely not the fix. It will take some more manipulation. The outright error is definitely not correct either.

At the very least it's misleading, since you should be able to point multiple hosts at the same IP

kroy added a comment.Sat, Jun 27, 6:44 AM

To add, maybe it's just the content of the error message that's misleading here if there other ways to do it. Or maybe the problem is that there are multiple ways to accomplish this

Yeah, only the first line will be used, the subsequent lines for an already existing IP or hostname will be ignored. pdns-recursor also behaves the same, it logs "not replacing entry" (or something similar, I can't recall) when encountering a entry with a different IP for a hostname already defined, so it behaves the same as getent. You can't add multiple entries for round-robin resolution, hosts has no support for that, if we want that we need to use zone files instead (but those only work for pdns-recursor and not the system, so are not a suitable replacement here, they could be added under the dns forwarding node)

You can already get the result you want by configuring "static-host-mapping host1 alias host2" (there can be an unlimited amount of aliases).

If, however, we want to transparently join all the entries for the same IP, we need to iterate over the dict and join all entries with the same address. Maybe an old version of Vyos did allow that, but if it didn't join entries to one line, it didn't work as it should and that was a bug.

Having a single hostname point to multiple IPs is not possible with hosts and must be disallowed.

kroy added a comment.Sat, Jun 27, 7:03 AM

Then I believe the best course of action is to restore that error condition, but have it reference the “alias” config then.

From the user standpoint, there is no reason they should not be able to apply the original config I referenced. If we want to guide them to the appropriate method of doing so, it should be in the error message.

I agree, we can make the error message point the user towards using an alias instead. But I don't think doing so is common practice, such things are usually written in docs.

Looking at the code, there is a missing error check for when an alias is the same as a static-host-mapping or already existing alias (either of this mapping or any other one). It will require some additional iteration.
Or maybe these should be converted to warnings and not errors, as they don't cause anything to break, just not work as expected?

Will you be doing this change or can I claim it? I'm ready to work on it right now if you prefer.

kroy reassigned this task from kroy to jjakob.EditedSat, Jun 27, 2:56 PM

Go for it. Just to confirm, this did work on the rolling from the 8th of this month, so it was something that got gobbled up in the rewrite.

At the very least, it seems to be a behavior change.

Thanks!