all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: "Lukas Wagner" <l.wagner@proxmox.com>
To: "Proxmox Datacenter Manager development discussion"
	<pdm-devel@lists.proxmox.com>,
	"Hannes Laimer" <h.laimer@proxmox.com>
Subject: Re: [pdm-devel] [PATCH proxmox{, -yew-comp, -datacenter-manager} 00/13] add basic integration of PVE firewall
Date: Tue, 04 Nov 2025 15:19:02 +0100	[thread overview]
Message-ID: <DDZZ51VQT69Z.2NL7QSCX5E5CZ@proxmox.com> (raw)
In-Reply-To: <20251030143406.193744-1-h.laimer@proxmox.com>

On Thu Oct 30, 2025 at 3:33 PM CET, Hannes Laimer wrote:
> This adds a basic UI for displaying the status of the firewall on remotes,
> nodes and guests in a tree. Status includes whether the firewall is
> enabled and the count of enabled rules. These rules are also shown in a
> panel once an enetity in the tree is selected. Firewall options can be
> edited, most useful is probably enable/disable, but generally all
> options are exposed(since we had the types anyway).
>
> Generally loading the status involves 2 requests per entity, so the PDM
> server has to do quite a bit of work collecting all the relevant data.
> That is the reason we have multiple status endpoints
>  - for all pve remotes
>  - for a specific remote
>  - for a specific node
> a bit more context on the commit adding these endpoints. With these we
> can limit the number of requests the PDM potentially has to do. In this
> context a cache could also make sense, should be somewhat straight
> forward integrating something like Dominik proposed in [1]. But since
> these are configs, caches would have to be really short lived, but still,
> they could help with different useres requesting the same data at close
> to the same time.
>
> Firewall options edit form and the firewall rules tables were added to
> yew-comp as they are not necesarrily PDM specific. I tried having them
> in a way so it would not be too complicated reusing them in other places
> at some point.
>
> This also includes an updated pve-api.json, some api endpoint specs did
> require minor adjustments so they'd work with the type generator. This
> includes the not yet applied changes in [2]. This also needs [3] to be
> present. Generally this is build with the latest master of
> proxmox-yew-comp and proxmox-yew-widget-toolkit.
>
> Notes: node or guest firewalls could be enabled, but end up being masked
> by the cluster setting. I tried visualizing that by having the checkmark
> normal if masked and green if not.
>
> [1] https://lore.proxmox.com/pdm-devel/20251017120315.2723235-1-d.csapak@proxmox.com/
> [2] https://lore.proxmox.com/pve-devel/20251023141546.105302-1-h.laimer@proxmox.com/T/#u
> [3] https://lore.proxmox.com/yew-devel/20251029173528.378487-1-h.laimer@proxmox.com/T/#u
>

Some general high-level notes about this, I have not yet checked the
code yet:

I'm not sure whether this 'side-by-side' view of the remote/node/guest tree
and the table for the firewall rules is a good idea. The table has 12
columns, none of which could be hidden by default without hiding
potentially crucial information. Even at a width of 1920 pixels, 3 1/2
columns are outside the view port and only accessible when scrolling
horizontally. Some of the columns are also too narrow by default, like
the ones for Source/Dest IP addresses, so the table might need even more
space than it already does.

Hannes and I briefly discussed the issue off-list already, here are some
of the ideas that popped up:

  - Hiding some columns: Not ideal, since potentially any column can
    contain important information about the rule

  - We could leave out the 'x out of y rules enabled' in the tree
    and make the tree as narrow as possible. I've played around with
    a 1:4 flex ratio, which *could* work - the table still barely
    fits, e.g. 'Comment' entries longer than one or two words would
    still overflow the view

  - Change the layout from two cards next to each other to two cards on
    top of each other: Possible, but not ideal, since then the tree view
    is limited in height - leading to more scrolling and possibly worse
    UX when having a large number of remotes/nodes/guests.

  - Show rule list in a dialog: The tree view would then become
    full-width (similar to the SDN view), with a dialog showing the
    ruleset that could be opened via some button.
    This could work, but could become a bit awkward once we want to
    support editing rules as well - since then you would spawn the "Edit
    dialog" from the "Rule List Dialog". We already have one other
    instance where we spawn a dialog from within another dialog
    (Fingerprint confirmation when adding a remote), but I think this
    should be avoided if possible.

  - Similar to the previous, but without a pop-up:
    Make the tree view full-width and add a
    'Show Rules >' button for each tree item in the furthest right
    column. If pressed, the tree view as a whole hides/collapses/moves to the
    left and yields space for a full-width list view for the firewall
    rules. Somewhere there then should be some "< Show Tree View" (or
    some other text) button, which can be pressed to hide the list view
    again and expand the tree view widget horizontally again.

    In (rather crude) ASCII art this could be:

	----------------------------------------------------------
	    * remote-a
	       + node-a                              (>)
		 * VM 100                            (>)
		 * VM 101                            (>)
	       + node-b                              (>)
	       + node-c                              (>)
	    * remote-b
	       + node-a                              (>)
	       + node-b                              (>)
	       + node-c                              (>)

	----------------------------------------------------------

	and when the (>) button is pressed, the entire view changes to the
	rule list. If (< back) is pressed, the tree is shown again.

	----------------------------------------------------------
	(< back)
	    
	   Enabled | Type | Action | Macro | Interface | Protocol | ...
	      x    | in   | ACCEPT |     - | vmbr0     | tcp      | ...

	----------------------------------------------------------


Some other things that I've noticed:

  - The check-mark or - in the Enabled column should be centered

  - A button to quickly go to the firewall rules page in the PVE Web UI
    would be nice, at least as long was we cannot edit rules in PDM
    directly.

  - Could make sense to add an explict rule numbering column, just to
    emphasize that the order of rules is important (same as in PVE).

  - In the 'Edit Cluster Firewall Dialog', there are two 'Enable'
    checkboxes, one says 'Enable Firewall' and the other one just 'Enable'.
    I assume the latter refers to rate limiting? IMO this one is a bit
    confusing and could use some polish. Maybe something like
       
       Log Rate Limiting   [x]
             Rate          [        ]
	     Burst         [        ]

     With Rate and Burst disabled/greyed out if 'Log Rate Limiting' is
     not ticked (assuming that I understood the options correctly, I
     have not really checked how they work exactly)




_______________________________________________
pdm-devel mailing list
pdm-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pdm-devel


      parent reply	other threads:[~2025-11-04 14:18 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-30 14:33 Hannes Laimer
2025-10-30 14:33 ` [pdm-devel] [PATCH proxmox 1/5] pve-api-types: update pve-api.json Hannes Laimer
2025-10-30 14:33 ` [pdm-devel] [PATCH proxmox 2/5] pve-api-types: add get/update firewall options endpoints Hannes Laimer
2025-10-30 14:33 ` [pdm-devel] [PATCH proxmox 3/5] pve-api-types: schema2rust: handle `macro` keyword like we do `type` Hannes Laimer
2025-10-30 14:33 ` [pdm-devel] [PATCH proxmox 4/5] pve-api-types: add list firewall rules endpoints Hannes Laimer
2025-10-30 14:33 ` [pdm-devel] [PATCH proxmox 5/5] pve-api-types: regenerate Hannes Laimer
2025-11-04 14:19   ` Lukas Wagner
2025-10-30 14:33 ` [pdm-devel] [PATCH proxmox-yew-comp 1/4] form: add helpers for extractig data out of schemas Hannes Laimer
2025-10-30 14:34 ` [pdm-devel] [PATCH proxmox-yew-comp 2/4] firewall: add FirewallContext Hannes Laimer
2025-10-30 14:34 ` [pdm-devel] [PATCH proxmox-yew-comp 3/4] firewall: add options edit form Hannes Laimer
2025-10-30 14:34 ` [pdm-devel] [PATCH proxmox-yew-comp 4/4] firewall: add rules table Hannes Laimer
2025-10-30 14:34 ` [pdm-devel] [PATCH proxmox-datacenter-manager 1/4] pdm-api-types: add firewall status types Hannes Laimer
2025-10-30 14:34 ` [pdm-devel] [PATCH proxmox-datacenter-manager 2/4] api: firewall: add option, rules and status endpoints Hannes Laimer
2025-10-30 14:34 ` [pdm-devel] [PATCH proxmox-datacenter-manager 3/4] pdm-client: add api methods for firewall options, " Hannes Laimer
2025-10-30 14:34 ` [pdm-devel] [PATCH proxmox-datacenter-manager 4/4] ui: add firewall status tree Hannes Laimer
2025-11-04 14:19 ` Lukas Wagner [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DDZZ51VQT69Z.2NL7QSCX5E5CZ@proxmox.com \
    --to=l.wagner@proxmox.com \
    --cc=h.laimer@proxmox.com \
    --cc=pdm-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal