Re: Rootless Podman with VRRP

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 4655 bytes --]

On Tue, Sep 17, 2024 at 03:22:04PM +0000, Castelli, Anton wrote:
> David,
> 
> Thank you very much for the quick reply!
> 
> I tried querying the DNS with TCP and it worked correctly, using the
> VRRP address in the reply packet. Unfortunately, UDP is the default
> for DNS queries.

Right.

> Thanks for the advice about the options and the workaround. I had
> just copied them from the Podman docs and modified them slightly. I
> tried the '--publish 10.1.1.1:53:53/udp --publish
> 10.1.1.2:53:53/udp' options, and it worked great on the primary
> server that had the active VRRP address. I was able to query both
> the regular and VRRP addresses and get a response. Unfortunately,
> when I tried the same on the secondary server that doesn't have the
> VRRP address, it refused to bind to the non-existent '10.1.1.2'
> address.

Ah, right, of course.  I was just thinking about the primary, and
didn't consider how the secondaries would also need to listen on that
address at some future time.

> I tried with both the publish options and got an error (10.1.1.3 is
> the regular IP of the secondary server).
> 
> --publish 10.1.1.3:53:53/udp --publish 10.1.1.2:53:53/udp
> 
> Error: unable to start container "XXXX": pasta failed with exit code 1:
> Altering mapping of already mapped port number: 10.1.1.2/53-53:53-53

This looks like a different bug - although one that I think will be
fixed by some work that's pretty close to the top of my queue.  It's
not all that relevant for your case right now, because..

> Failed to bind port 53 (Cannot assign requested address) for option
> '-u 10.1.1.2/53-53:53-53', exiting

..this one is more fundamental.  Usually, you can't bind an address
you don't currently own.

> I also tried to publish just the VRRP address that isn't currently
> assigned to the secondary server and got a different error.
> 
> --publish 10.1.1.2:53:53/udp
> 
> Error: unable to start container "XXXX": pasta failed with exit code 1:
> Failed to bind port 53 (Cannot assign requested address) for option '-u 131.230.254.138/53-53:53-53', exiting

This one looks like the same error... except the IP is very strange.
Or was just this a mistake in anonymizing the addresses?

> Since the goal of this VRRP setup is to have an active/standby
> failover pair, I have to have the service started and running on the
> secondary server. If the primary server fails, the VRRP address will
> move to the secondary server and DNS should then respond to
> requests.
> 
> Unless you can think of another work-around for the secondary
> server, I might just have to use a rootful container and host
> networking for now.

I think I do have another workaround, although it will require
changing a setting as root.  If you set:
	sysctl net.ipv4.ip_nonlocal_bind=1
on the host (and the ipv6 version as well, if you need it), then pasta
should be able to bind the VRRP address even if it isn't (yet)
configured on the machine.

There's also a per-socket version of this (IP_FREEBIND) which wouldn't
require the root setup.  We've talked about supporting this in pasta
somehow, but we don't have any specific plans for it (it's not very
clear how you'd configure it, for example).

Note that with the ip_nonlocal_bind setting you might still run into
trouble binding both the VRRP and regular addresses due to the other
bug I mentioned in passing above.  As I said that one should be
addressed by some stuff that's pretty near the front of the queue.
Let me know if that's still an issue for you and I'll consider it a
priority bump to that work.

> I will be happy to submit a bug report. Unfortunately, I'm having
> trouble getting signed up. I've tried to send the new account email
> to both my work email address and a personal Gmail address. I have
> not received the email in either case (I've checked the spam folders
> too).

I see you and Stefano sorted that out.  Thanks for filing the bug.
Looks like in the confusion over signup, 4 almost duplicates were
filed, I've consolidated those now.

That will keep this on the radar, but I can't promise we'll be able to
fix this particularly soon.  There's a heap of other work that will
probably take priority.  I hope the workarounds above can tide you
over for now.

> I very much appreciate your work and the Pasta project. Thank you
> for taking the time to respond and helping me out!

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]