Currently pve-network has a (versioned) build-dep of pve-firewall, which has
a (versioned) runtime dependency of a newer version of libpve-network-perl,
which is not available because it has not been built. It turns out that
pve-firewall is only needed in testing, so let's only pull it in if
we don't use the "nocheck" build profile so that we can actually build
pve-network from source.
perl is a build-essential so no need to add it in build-deps.
Fixes: cbc70c81b9
Signed-off-by: Jing Luo <jing@jing.rocks>
Link: https://lore.proxmox.com/mailman.599.1732342430.391.pve-devel@lists.proxmox.com
Currently, we do not verify the TLS certificate for API requests
external IPAM and DNS integration. This could allow man-in-the-middle
attacks, albeit most IPAM infrastructure is on controlled and isolated
LANs, so it's not something that should frequently happen; and
technically our IPAM integration is still marked as tech-preview,
which had its reasons.
Enforce verification, and allow users to pass a cert SHA256
fingerprint to ensure a certificates validity if it's not trusted by
the system trust store, as it's, e.g., the case for self-signed certs.
The code was adapted from the one in pve-apiclient, which we cannot
reuse directly as it is only implemented for requests against PVE
nodes, not as a generic HTTP client request helper.
Add the new dependency `libio-socket-ssl-perl` required to get the
verify callback for the TLS certificate used for cert-fingerprint
checking.
Signed-off-by: Hannes Duerr <h.duerr@proxmox.com>
Tested-by: Stefan Hanreich <s.hanreich@proxmox.com>
[TL: return valid for non-leaf certs and rewrite commit message]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
failing a package-install does not help repairing the situation - so
inform the user about the issue instead of erroring out. The copy
could fail if a node is not quorate, so writes in /etc/pve are a bit
more likely to fail
adapts the change introduced in
d0628df ("debian: migrate legacy mac/ipam cache/state files")
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
We opted for a simple copy of the legacy file to the new location,
since any other migration path would be too strenuous. The worst-case
scenario of failures with this approach is losing IPAM / MAC entries
that are created during the update window in the legacy files by nodes
that are not yet updated to the new version. Those can be fixed by a
simple start / stop of the affected VMs, triggering a rewrite of the
IPAM database.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
[ TL: output message if files get moved and add todo-comment ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
We mount the per-vnet firewall API endpoints here now, as we split api
and implementation we can avoid a cyclic dependency.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This is not yet marked as released as the bump was mostly done to
allow testing with correct version for the package split's
break/replaces.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
To better handle the case where firewall requires to parse the SDN
config and this package here would like to mount some vnet specific
firewall endpoints, without a split we got a cyclic dependency here,
and those are painful, especially on bootstrapping.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
to ensure 'sdn/pve-ipam-state.json' is in the list of observed files
for version tracking and direct IPC get-config availability through
pmxcfs.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
For mocking RPCEnvironment in sbuild.
Signed-off-by: Stefan Lendl <s.lendl@proxmox.com>
Reviewed-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Stefan Hanreich <s.hanreich@proxmox.com>
avoid pulling FRR in on upgrade if we'd hard-depend on
libpve-network-perl for all those systems that kept the default
install-recommends enabled as FRR is a bit involved and might announce
stuff and break some network environments if not correctly configured.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The plugin creates a dnsmasq@<zone> service that spawns a dnsmasq
instance that handles dhcp for that zone.
The configuration files for a dnsmasq instance lie within
/etc/dnsmasq.d/<zone>
The plugin generates the following configuration files:
* 00-default.conf
Contains the default global configuration for dnsmasq. Disables DNS,
enables some specific options for Windows, does some
security-related configuration and makes dnsmasq bind only to the
interfaces it is responsible for
* 10-<subnet>.conf
Contains the default settings for a subnet. Sets dhcp options for
DNS and gateway.
* 10-<subnet>.ranges.conf
Contains the configuration of DHCP ranges for a subnet.
* ethers
Contains the MAC address to IP mappings for a zone.
Every subnet gets assigned a tag in the dnsmasq configuration that is
equal to the subnet_id. This can be used to override / set additional
configuration options on a per-subnet basis.
Additionally it creates the file /etc/default/dnsmasq.<zone> that
provides default options for the dnsmasq service.
Leases are stored in /var/lib/misc/dnsmasq.<zone>.
Co-Authored-By: Alexandre Derumier <aderumier@odiso.com>
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
