Go to file
Stefan Hanreich f83a9a6367 firewall: sdn: ignore EPERM when reading the legacy IPAM file
On fresh installations, neither the new nor the old IPAM db file
exist. This triggers our fallback code path and leads to errors in the
syslog on fresh installs where there is no IPAM database. This happens
whenever a firewall API call is made. Because of this, we choose to
ignore EPERM when reading the legacy files. This is okay, because we
move existing databases in the postinstall script of
libpve-network-perl, making the situation where the new file does not
exist, but the old file exists unlikely.

Reported-by: Alexander Zeidler <a.zeidler@proxmox.com>
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
2024-11-20 16:17:20 +01:00
common common: buildsys: Makefile: drop --no-pre-clean 2024-11-11 11:41:17 +01:00
pmg-rs update proxmox-subscription to 0.5 2024-11-10 19:11:14 +01:00
pve-rs firewall: sdn: ignore EPERM when reading the legacy IPAM file 2024-11-20 16:17:20 +01:00
.gitignore fixup .gitignore 2022-03-01 11:46:49 +01:00
README.md README: add note on version bumps 2024-11-11 11:15:34 +01:00

Hints for development:

With the current perlmod, the .pm files don't actually change anymore, since the exported method setup is now handled by the bootstrap rust-function generated by perlmod, so for quicker debugging, you can just keep the installed .pm files from the package and simply link the library to the debug one like so:

NOTE: You may need to adapt the perl version number in this path:

# ln -sf $PWD/target/debug/libpve_rs.so /usr/lib/x86_64-linux-gnu/perl5/5.32/auto/libpve_rs.so

Then just restart pvedaemon/pveproxy after running make pve.

Version Bumps

TL;DR

  • Common code changes -> bump the products, not the common package.
  • Common package list changes -> bump common AND products (That's the $(PERLMOD_PACKAGES) list in common/pkg/Makefile)
  • On breaking changes to the common code, both PVE and PMG should be bumped along with the common package which should declare its Depends/Breaks accordingly.

The common package.

This package only provides the "list" of packages the common code contains, but does not by itself provide a library. In other words, this only provides a bunch of .pm files which cause whichever product-specific library is available to be loaded.

The rust code in the common directory is compiled as part of the product libraries. Those libraries actually provide both the product specific as well as the common perl "packages" via the library.

The product packages.

These are the actual libraries. Their source code both "include" the common rust code by way of a symlink (but when a source package is created, that symlink is replaced by a copy of the common dir), so building them locally with cargo build should use the common code from git.

These provide the actual functionality the common package declares to exist (via its .pm files), in addition to the product specific parts.