Since we already have the information from the API call, why not add it
as a (hidden) column. It can be useful to quickly see which ceph
applications are enabled for a pool in some situations.

Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>

As else we trigger a change event for the size field which triggers
the sizeChange callback that then re-calculates the default size
suggestion, which might be lower as the value the user configured.

This was reported in the Forum for a 5/4 size/min-size configuration
that got reset to 5/3 on edit.

Report: https://forum.proxmox.com/threads/158798/


Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

Most options come from the api call parameter list
(`json_config_properties`). The description and types for the remaining
ons are either taken from the manpages, source code or similar
documentation where available.

Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

This fixes the error:
  unknown permission test at /usr/share/perl5/PVE/RPCEnvironment.pm line 536. (500)
which occurred when trying to create or update a notification target.

The cause was a permission 'check' parameter for the API handlers
which was nested one level too deep by accident.

This regression was introduced in a previous commit which raised the
needed permissions for notification target management. It likely went
unnoticed because the permission check is skipped for root@pam, so the
error occurs only if using another user.

Reported in the community forum:
https://forum.proxmox.com/threads/158101

Fixes: a3fe9c54

 ("api: notifications: require powerful privileges for target management")
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
 [ TL: minor commit message touch ups ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

Since tags are mostly free-form, a single tag with a numeric value will
get sent to influxdb as a number by default. Change that to always quote
the tags as a string, like we do for the 'name' field. (InfluxDB can
only have one type per field, so either a string or a number type).

This won't fix influxdb databases after there are already numeric values
in there, but I guess most tags won't be purely numeric, so this won't
be an issue for most users, and fixes the reverse case where purely
numeric tags won't show up in influxdb.

reported in the community forum:
https://forum.proxmox.com/threads/138004/#post-724127



Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>

We use the same icon in other similar buttons already, e.g. for copying the
TLS certificate fingerprint in PBS.

Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>

Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

To have a better distinction from the cluster wide Firewall entry
that's basically just below that (at least if one isn't root, as then
the ACME one is separating them)

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

They wanted to generate a new one about a year ago [0], but seems they
did not get around to that and reused the existing key with an updated
expiry.

[0]: https://lore.proxmox.com/pve-devel/576a10b6-2a41-49b0-8bae-8abcb6786e93@turnkeylinux.org/



One can see that this is the same key with just updated expiry by e.g.
comparing the output of `sq packet dump` for old and new.
That comparison shows the following, with re-ordering the packets to
minimize the diff:

 diff --git a/old b/new
 index be331bd..253924d 100644
 --- a/old
 +++ b/new
 @@ -52,3 +52,36 @@ Signature Packet, old CTB, 316 bytes
      Digest prefix: CDF9
      Level: 0 (signature over data)

 +Signature Packet, old CTB, 339 bytes
 +    Version: 4
 +    Type: PositiveCertification
 +    Pk algo: RSA
 +    Hash algo: SHA512
 +    Hashed area:
 +      Key flags: CS
 +      Symmetric algo preferences: AES256, AES192, AES128, CAST5, TripleDES
 +      Hash preferences: SHA1, SHA256, RipeMD
 +      Compression preferences: Zlib, BZip2, Zip
 +      Features: MDC
 +      Keyserver preferences: no modify
 +      Issuer Fingerprint: 694CFF26795A29BAE07B4EB585C25E95A16EB94D
 +      Signature creation time: 2023-11-09 11:18:41 UTC
 +      Key expiration time: P11039DT2036S
 +    Unhashed area:
 +      Issuer: 85C25E95A16EB94D
 +    Digest prefix: 527E
 +    Level: 0 (signature over data)
 +
 +Signature Packet, old CTB, 307 bytes
 +    Version: 4
 +    Type: GenericCertification
 +    Pk algo: RSA
 +    Hash algo: SHA256
 +    Hashed area:
 +      Issuer Fingerprint: AC62EF896DE64C99482FFDF7F0AE9360D9913430
 +      Signature creation time: 2018-10-27 06:25:56 UTC
 +    Unhashed area:
 +      Issuer: F0AE9360D9913430
 +    Digest prefix: E4BF
 +    Level: 0 (signature over data)
 +

Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
 [ TL: expand commit message slightly ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

There are certainly a few bug fixes to come, but it seems OK enough to
drop the preview flag, all else we will fix as it comes.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

These allow one to indirectly access resources from the POV of the
Proxmox VE cluster nodes. While gotify is relatively harmless, smtp
could already cause more problems to admins that are not aware of the
implications of allowing users to add targets while having some open
smtp relay that is only accessible from networks the PVE nodes can
access but not the user that can talk with PVE's API. The webhook one
is then pretty much free-form and might cause some adverse effects in
environments that are only loosely guarded, and while that might point
at general security problems, it's likely that admins will still place
the blame at our projects.

So while the former should not be problematic, the new not yet fully
released webhooks could have some impact. That said, it currently
requires Mapping.Modify, which is a intermediate powerful level priv,
so it's not like any user could use this. Still, hedging for the
safer side here seems the better choice for now, we still can open
this up if there's user feedback and we deem it safe enough doing so.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

We add this as advanced option in the UI and also move vlan-aware
to advanced section.

Signed-off-by: Alexandre Derumier <alexandre.derumier@groupe-cyllene.com>
 [ SH: improve naming and commit msg slightly ]
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

'import storage' is a bit amibuous as to whether it's the storage to
import from or to. To fix that, change it to 'source storage'

Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>

Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>

Since forward rules only take effect when the nftables firewall is
enabled, show a warning to users that informs them of this.

Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>

Expose the ability to create vnet-level firewalls in the PVE UI

Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Hannes Dürr <h.duerr@proxmox.com>

This adds the ability to dynamically configure and change the base_url
for the firewall options. This is needed for the SDN firewall dialog,
that updates the firewall components based on the selected vnet. This
avoids having to reinstantiate the component every time the user
selects a new vnet.

Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Hannes Dürr <h.duerr@proxmox.com>

Add the configuration options for vnet-level firewalls to the options
component. Additionally add the new policy_forward configuration
option to the datacenter-level firewall as well.

Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Hannes Dürr <h.duerr@proxmox.com>

Enables us to use the new forward direction as an option when creating
or editing firewall rules. By introducing firewall_type we can switch
between the available directions depending on which ruleset is being
edited.

Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Hannes Dürr <h.duerr@proxmox.com>

Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Gabriel Goller <g.goller@proxmox.com>
Tested-by: Hannes Dürr <h.duerr@proxmox.com>

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

to ensure we got the new Squid repos also available in the repo
management API.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

Signed-off-by: Timothy Nicholson <t.nicholson@proxmox.com>
 [ TL: squash in fixes for eslint missing-trailing-comma warnings ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

This patch adds a tooltip in the security group selector for group
comments that are too long to fit within the column width.

Signed-off-by: Timothy Nicholson <t.nicholson@proxmox.com>

For the newer OVF/OVA import functionality on file based storages that
the UI now has support for.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

To ensure we got the new OVF import stuff and the AMD SEV support
available.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

By adding a new input panel with an AMD SEV technology selection combo
box and checkboxes for the optional parameters in an advanced section,
the user can configure the amd_sev option via the WebUI's Options tab.

Signed-off-by: Markus Frank <m.frank@proxmox.com>
Reviewed-by: Shannon Sterz <s.sterz@proxmox.com>
 [ TL: fleeced in a nit from Shannon and went further with some
   personal ones, like using the field label as subject and avoiding
   the exact onlineHelp until pve-docs is bumped ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

For ova import, the help text for live-import is not really fitting, as
there is no 'old' vm that needs to be stopped, etc.

So show a more appropriate one if we import an ova

Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>

since there we already have the size information

Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>

since 'virtual guests' only make sense for a hypervisor, not e.g. a
directory for OVAs

also change the icon from 'desktop' to 'cloud-download' in the
non-esxi case

Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>