If timeout is reached, run_fork_with_timeout will warn "got timeout".
When processing triggers for pve-manager (because of ExecStartPre of
pveproxy.service invoking pvecm updatecerts) that warning can appear
in the apt output without any context (output of the forked sub
doesn't appear there). So give it some actual content using the
$got_timeout returned in wantarray list context of the
run_fork_with_timeout method.
Note that this could be seen as clash with the silent flag, but IMO
that is a bit misnamed, we mostly want to avoid outputting the info
messages from updatecerts_and_ssh, and that silent (i.e., quite) gets
convoluted with a no-error behavior seems also odd.
TBH., I actually thought about printing the "waiting for quorum" at
least once for the silent case too, but for now omitted it – lets
wait on actual feedback and then maybe restructure this completely.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Mostly useful for the updatecerts call triggered via the ExecStartPre
hook for pveproxy.service.
When starting a node that's part of a cluster, there is a time window
between the start of pve-cluster.service and when quorum is reached
(from the node's perspective). pveproxy.service is ordered after
pve-cluster.service, but that does not prevent the ExecStartPre hook
from being executed before the node is part of the quorate partition.
The pvecm updatecerts command won't do much without quorum. Generating
local (non-pmxcfs) files is still done before waiting on quorum.
In particular, it might happen that the base directories for observed
files will not get created during/after the upgrade from Proxmox VE 7
to 8 (reported in the community forum [0] and reproduced right away in
a virtual test cluster).
Waiting on quorum should highly increase the chances for successful
execution of the ExecStartPre hook.
[0]: https://forum.proxmox.com/threads/129644/
Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
In preparation to wait for quorum in the updatecerts command. The
generation of files that do not depend on quorum should still be done
beforehand.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Make the resolution of the node name to a local non-loopback address
through getaddrinfo more flexible.
Don't just ask for one, but for all addresses, then loop through the
returned linked list until the first non-loopback one is found.
It seems that some cloud-init templates hosting providers, like e.g.
OVH use, are misconfigured in always adding 127.0.1.1 for the
hostname to /etc/hosts, even if another mapping for the hostname
exists already. This popped up in our community forum with the
upgrade to bookworm, so might be related to the cloud-init version
from Bookworm.
Some examples pointed out by Alexandre:
https://forum.proxmox.com/threads/129678/https://forum.proxmox.com/threads/129669/#post-568172https://forum.proxmox.com/threads/129398/#post-568290
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The call was moved by 84c3ab0 ("pve-cluster.service: move pvecm call
to pveproxy.service") to pveproxy.service's ExecStartPre.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
There might be more mapping types in the future, but for now it's:
- mapping/pci.cfg
- mapping/usb.cfg
Add them to both, the perl side (PVE/Cluster.pm) and pmxcfs side
(status.c).
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
[ TL: Dominik, Fabian and I decided to do a s/resource/mapping/
rename on the cfg & API paths and privileges, so ammend that ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Since rsync 3.2.4, the syntax to give multiple files in one parameter
does not work anymore, so instead add both files explicitly.
this fixes the cluster join over ssh on Bookworm based Proxmox VE,
and Bullseye has rsync 3.2.3 so no change required there.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
data/src was a bit odd, and git is good enough to resolve such things
for history (blame) or applying patches, so don't bother enduring
this.
The process was basically:
git mv data/src/ data/pmxcfs
git mv data/ src
git mv cpgtest.c src/test
git mv src/cts/* src/test/scripts
And a few Makefile fixups.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
As the previously used g_memdup is deprecated since GLib 2.68, due to
being prone to integer overflows when converting the argument from a
gsize to a guint, while that only produces a warning we compile with
Werror, so this FTBFS.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
for us not _that_ relevant, but it makes backporting unnecessarily
difficult and is just useless.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
If `pvecm add` is issued from /etc/pve (or any subdirectory), it
prints some errors:
[...]
shell-init: error retrieving current directory: getcwd: cannot
access parent directories: Transport endpoint is not connected
[...]
successfully added node 'pve-c2' to cluster.
cannot fetch initial working directory: Transport endpoint is not
connected at /usr/share/perl5/PVE/CLI/pvecm.pm line 446.
The reason is that `pvecm add` restarts pmxcfs, which re-mounts the
fuse mount at /etc/pve, invalidating pvecm's working directory.
The error messages give the impression that something went wrong.
Indeed, the second error indicates the temporary directory is not
cleaned up. The cluster join itself actually works, though.
The issue could be fixed by chdir'ing to / in `pvecm add`. However,
the user's shell would still remain in the now-invalid /etc/pve,
potentially leading to confusing "transport endpoint not connected"
messages in future interactions.
To avoid this, require the user to chdir out of /etc/pve before
running `pvecm add`.
Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
For now allow a simple selection of `auto` (current behavior),
`always` (if updates are available) or `never`.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
