Without this newline running commands with missing arguments, e.g.
```
proxmox-backup-client backup
```
will print their usage string without a newline at the end, which is
costing me my sanity.
As per commit d872eb9d7e ("router: cli: rework newline handling for
doc and help output"), usage shouldn't contain trailing new lines and
this in principle should not print double new lines.
Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
By default, the mapping between tracing/log error levels to
syslog priorities is as follows:
error! -> Error
warn! -> Warning
info! -> Notice
debug! -> Informational
trace! -> Debug
Before using tracing-journald, we used `syslog` to write log messages
to the journal. That one has the following mapping:
error! -> Error
warn! -> Warning
info! -> Informational
debug! -> Debug
trace! -> Debug
The changed mapping of info! log messages led to many messages being
written with the Notice priority, which are formatted bold when running
journalctl to view log messages.
This commit changes the mapping so that it is the same as with the
syslog crate.
Support for custom priority mappings was only introduced in
tracing-journald 0.3.1, so we have to bump the dependency
to that version.
Reported-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Allow to instantiate a `HttpsConnector` not using the default
`getaddrinfo` based `GaiResolver` for domain name resolution, but
rather a custom resolver implementing the required traits.
The usecase for this is to swap out the DNS resolver for the
statically linked proxmox-backup-client binary, where the glibc
dependency is problematic because of possible ABI incompatibility.
However, set the generic type on `HttpsConnector` to default to
`GaiResolver` to limit inconvenience for implementations using it.
Adds tower-service as cargo workspace dependency and build dependency
to debian/control.
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
Previously, notification templates could be modified by the user, but
these were overwritten again with installing newer package versions of
pve-manager and proxmox-backup.
Now override templates can be created cluster-wide in the path
“/etc/{pve,proxmox-backup}/notification-templates/{namespace}”, which
are used with priority. The folder structure has to be created and
populated manually (e.g. /etc/pve/notification-templates/default).
If override templates are not existing or their rendering fails, the
vendor templates in
"/usr/share/{pve-manager,proxmox-backup}/templates/default/" are used.
Sequence: [override html -> vendor html ->] override txt -> vendor txt
An error is only returned if none of the template candidates could be
used. Using an override template gets not logged.
Signed-off-by: Alexander Zeidler <a.zeidler@proxmox.com>
Reviewed-by: Lukas Wagner <l.wagner@proxmox.com>
Tested-by: Lukas Wagner <l.wagner@proxmox.com>
Link: https://lore.proxmox.com/20250321133341.151340-1-a.zeidler@proxmox.com
The old code was wrong and overestimated the memory used because it
did not take into account things like "SReclaimable", a part of slab
(in-kernel memory allocator) describing things like caches that can be
reclaimed, plus the memory for "Active(file)" and "Inactive(file)",
and other internal kernel things that even though small for each one,
can add up quickly.
Most of these metrics are exposed and could be included in the
calculation, but this will simply become obsolete in the future as the
kernel changes how it does things and how it calculates such available
memory, as it has done many times in the past.
To solve this problem for the long term, the MemAvailable field was
added to /proc/meminfo as of kernel 3.14. It describes "the amount of
memory available for a new workload without pushing the system into
swap". While it is only an estimate, it is as good as it gets, and
since it comes from the kernel, we can always assume that it is
correct for the currently booted kernel.
So, switch over to this metric for calculating the used memory by
subtracting MemAvailable from MemTotal.
Also adds a simple test case for the parser.
This commit is based on a patch from Dietmar [1].
[0]: https://git.kernel.org/torvalds/c/34e431b0ae398fc54ea69ff85ec700722c9da773
[1]: https://lore.proxmox.com/all/20250313114535.99912-2-dietmar@proxmox.com/
Originally-by: Dietmar Maurer <dietmar@proxmox.com>
[TL: rewrite comments and commit message from scratch]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Add optional sync job config options to allow to include only
encrypted and/or verified backup snapshots, excluding others from the
sync.
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
Link: https://lore.proxmox.com/pbs-devel/20250404132106.388829-2-c.ebner@proxmox.com
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Introduces two new, simple API types representing the built-in PAM and
PBS authentication realms.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Reviewed-by: Lukas Wagner <l.wagner@proxmox.com>
Tested-by: Lukas Wagner <l.wagner@proxmox.com>
[TL: adapt doc-comment for new default field like Shannon pointed out
but with a slightly different text than she proposed]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The field indicates whether the realm should be the default realm to
select in the login dialog.
Per definition, the field should only ever be set to `true` on exactly
one realm - up to the consumer/storage to ensure that.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Reviewed-by: Lukas Wagner <l.wagner@proxmox.com>
Tested-by: Lukas Wagner <l.wagner@proxmox.com>
[TL: adapt doc-comment for new default field like Shannon pointed out
but with a slightly different text than she proposed and change
regular comment to doc-comment.]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Add the `gc-atime-cutoff` option to the datastore tuning parameters.
This allows to specify the time after which the chunks are not
considered in use anymore if their atime has not been updated since
then.
The default is to keep chunks within the 24h 5m timespan (given no
active writers).
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
Add the `gc-atime-safety-check` flag to the datastore tuning
parameters. This flag allows to enable/disable a check to detect if
the atime update is honored by the filesystem backing the chunk store
during phase 1 of garbage collection and during datastore creation.
The default is to perform the check.
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
Sometimes it's useful to give the user control over how much
parallelized the job is, so introduce a worker thread option.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
To quote from RFC 9110 [1]:
A user agent SHOULD send Content-Length in a request when
the method defines a meaning for enclosed content and it
is not sending Transfer-Encoding. For example, a user agent
normally sends Content-Length in a POST request even when
the value is 0 (indicating empty content).
A user agent SHOULD NOT send a Content-Length header field
when the request message does not contain content and the
method semantics do not anticipate such data.
It seemed like our HTTP client lib did not set the header
automatically, which is why we should do it manually.
While most services seemed to have worked fine without setting
the header, some Microsoft services seem to require it
to accept the webhook request [2].
[1] https://datatracker.ietf.org/doc/html/rfc9110#name-content-length
[2] https://forum.proxmox.com/threads/158827
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Currently the anyhow error context of a given error is not included
in the error message, as `to_string` does use the default formatting
[0].
Include the error context, formatting it as single line as the
message is also shown to the users in e.g. the Proxmox Backup Severs
task state in the UI.
[0] https://docs.rs/anyhow/latest/anyhow/struct.Error.html#display-representations
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
These will produce an error in edition 2024 otherwise. The reason this
is needed is because the `unsafe` block has its own scope.
The bytes were defined inside of the let-mut block to preserve the
lifetime they had before this commit.
Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
Prevents the following error:
```
error[E0597]: `inner` does not live long enough
--> proxmox-async/src/broadcast_future.rs:109:24
|
107 | inner: Arc<Mutex<BroadCastFutureBinding<T>>>,
| ----- binding `inner` declared here
108 | ) -> impl Future<Output = Result<T, Error>> {
109 | let mut data = inner.lock().unwrap();
| ^^^^^ borrowed value does not live long enough
...
121 | data.broadcast.listen()
| ----------------------- argument requires that `inner` is borrowed for `'static`
122 | }
| - `inner` dropped here while still borrowed
error[E0597]: `data` does not live long enough
--> proxmox-async/src/broadcast_future.rs:121:9
|
109 | let mut data = inner.lock().unwrap();
| -------- binding `data` declared here
...
121 | data.broadcast.listen()
| ^^^^-------------------
| |
| borrowed value does not live long enough
| argument requires that `data` is borrowed for `'static`
122 | }
| - `data` dropped here while still borrowed
```
The use<...> pattern was introduced in rust 1.82.
Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
To write result message manually, bypassing tracing.
The workertasks currently get their status from parsing the log
messages in the task-log file. The problem is that if these messages are
filtered – which is now possible using the PBS_LOG env variable – some
workertasks will end up with a "stopped: unknown" status. This is not
desirable so write the message manually to the workertask file and
bypass tracing.
This way we are guaranteed that, regardless of the max logging level the
user sets, the final message (and status) is written.
Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
Add a layer that outputs messages to stderr in a specific format. In
PVE, stderr is rerouted to the tasklog if the we are within a
workertask. Therefore, ensure the stderr output is formatted
appropriately.
Reported-by: Lukas Wagner <l.wagner@proxmox.com>
Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
Add a builder-like struct to compose a tracing logger using different
layers. Instead of having an init function per product/binary or
super-specific init functions that describe the logger, have a dynamic
builder. The builder improves the usability and makes the logging
initialization more self-explaining.
Suggested-by: Lukas Wagner <l.wagner@proxmox.com>
Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
