[pve-devel] [PATCH v2 0/4] Read corosync.conf for firewall rules

[Fabian Grünbichler]

applied series with follow-ups, thanks!

besides some stylistic things I fixed the multicast detection to
actually only trigger when transport is 'udp', and added an early return
before getaddrinfo in case the hostname is already an IP address.

another potentially nice follow-up would be to include the
detected/allowed corosync addresses in the 'localnet' API call/CLI
command - maybe you want to take a look at that as well?

On Mon, Jul 01, 2019 at 05:22:13PM +0200, Stefan Reiter wrote:
> Related to issue #2245 (pve-firewall poorly detects 'localnet').
> Doesn't actually fix the underlying issue (i.e. localnet is still
> detected poorly), however, with this patchset corosync rules are
> at least unaffected.
> 
> corosync.conf is read directly during firewall rule generation, allowing
> much more fine-grained rules to be constructed. These are targeted directly
> at ring/link addresses and thus bypass any network detection that could
> go wrong. Supports hostname resolving, corosync style.
> 
> Tested on a 6.0 cluster, no change in behaviour with IPv4, IPv6 and
> hostnames in corosync.conf, multiple links work fine two (tested with
> two links, IPv4 and IPv6 simultaniously). 5.4 works fine too, patches
> applied cleanly to commit dd7d737bcb (bump version to 3.0-21) and
> behaviour of cluster was unaffected (as it should be). The bug mentioned
> in #2245 and on the pve-user list is no longer reproducible (corosync
> works fine, even with IPv6 address in /etc/hosts and firewall enabled).
> 
> Note that joining a new node to a cluster that has its firewall enabled
> might be delayed up to 10 seconds, until the firewall daemon has a chance
> to re-read the updated corosync.conf and adjust its rules.
> 
> 
> v2:
>  * Moved iterating and resolving subs to Corosync.pm
>  * Unified hostname resolving and iterating commit into one
>  * Added multicast-transport condition patch (for corosync 3 only)
>  * Fixed code style on several occasions
>  * Typos
> 
> 
> I will try to look into triggering a firewall update immediately if
> corosync.conf has changed, but I think that would be ok to send as a
> different patch. The delay is hardly noticeable in my testing.
> Maybe an inotify on corosync.conf in the firewall daemon?
> 
> 
> pve-cluster:
> Stefan Reiter (1):
>   Add functions to resolve hostnames and iterate corosync nodes
> 
>  data/PVE/Corosync.pm | 89 ++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 89 insertions(+)
> 
> 
> pve-firewall:
> Stefan Reiter (3):
>   Create corosync firewall rules independently of localnet
>   Update and add tests for corosync firewall changes
>   Only include multicast rules if transport is udp
> 
>  src/PVE/Firewall.pm            | 83 +++++++++++++++++++++++++++-------
>  test/corosync.conf             | 53 ++++++++++++++++++++++
>  test/fwtester.pl               | 11 ++++-
>  test/test-default-rules1/tests |  4 ++
>  4 files changed, 133 insertions(+), 18 deletions(-)
>  create mode 100644 test/corosync.conf
> 
> -- 
> 2.20.1
> 
> 
> _______________________________________________
> pve-devel mailing list
> pve-devel at pve.proxmox.com
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel