Use the job start-time as end-time when it's stuck in the
`JobState::Starting` state, no active working is running and the task
log of the last run doesn't exists.
A user experienced a power loss, which left a GC job in the `Started`
state, but the task log did not exist. This breaks the schedule and no
following GC runs. Now, the error is simply ignored and a new gc job
is started on the next occurrence.
Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
This will show the ip-address of the client creating
the backup in the logs. For example it will output:
"starting new backup on datastore 'test1' from ::ffff:192.168.1.192:
"host/test/2023-08-21T07:28:10Z"".
Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
/sys/firmware/efi is a directory and std::path::Path seems to detect
only regular files with is_file [0].
Reported in our Enterprise support portal.
Quickly tested the fix on a VM.
https://doc.rust-lang.org/stable/std/path/struct.Path.html#method.is_file
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Like in PVE.
This means that /access/users is now a 'protected' call to
get access to 'tfa.cfg'.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
this commit makes the ldap realm endpoints check whether a new or
updated configuration works correctly. it uses the new
`check_connection` function to make sure that a configuration can be
successfully used to connect to and query an ldap directory.
doing so allows us to remove the ldap domain regex. instead of relying
on a regex to make sure that a given distinguished name (dn) could be
correct, we simply let the ldap directory tell us whether it accepts
it. this should also aid with usability as a dn that looks correct
could still be invalid.
this also implicitly removes unauthenticated binds, since the new
`check_connection` function does not support those. it will simply
bail out of the check if a `bind_dn` but no password is configured.
therefore, this is a breaking change.
Signed-off-by: Stefan Sterz <s.sterz@proxmox.com>
From rust-lang:
> Why is this bad?
>
> First, it’s more complex, involving two calls instead of one. Second,
> Box::default() can be faster in certain cases.
Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
The function will always be called. This is only bad if it allocates or does some non-trivial amount of work.
Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
Adds the commands
proxmox-backup-manager user tfa list <userid>
proxmox-backup-manager user tfa delete <userid> <id>
Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
In the next commit we expose a command to list the tfa methods of a
user. Without this annotation one would get the following error
unable to format result: got unexpected data (expected null).
when running the proposed cli command.
Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
instead of aborting. If the tape is currently e.g. offline, in an
import/export slot or in the wrong drive, this gives the user the chance to
manually move it/insert it, so that the backup job can continue.
Send an e-mail like we do on a standalone drive, but adapt the messages
to contain the changer instead of the drive.
This can help when not all tapes are currently available in the changer.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
like we do on a full restore, for that refactor the functionality into
'log_required_tapes' to be reused across the workers
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Adding an opening line for every group makes parsing the log easier.
We can also remove the 're-sync [...] done' line, because the next
line should be a progress line anyway.
The new output for the sync job/pull logs looks as follows:
- skipped already synced (happens in most jobs, except for first run)
- re-sync of last synced snapshot (if it still exists on source)
- skipped because of transfer-last (if set and skips something)
- sync of new snapshots (if they exist)
Suggested-By: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Specifying the transfer-last parameter limits the amount of backups
that get synced via the pull command/sync job. The parameter specifies
how many of the N latest backups should get pulled/synced. All other
backups will get skipped.
This is particularly useful in situations where the sync target has
less disk space than the source. Syncing all backups from the source
is not possible if there is not enough disk space on the target.
Additionally this can be used for limiting the amount of data
transferred, reducing load on the network.
The newest backup will always get re-synced, regardless of the setting
of the transfer-last parameter.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
This reverts commit 6bac67195e and
commit 783e88c2df as they were both
superseded by 569324cb ("provide separate helpers for pub/priv auth
keyring access").
This used to be the case before the switch to the auth api
crate and is required for some helpers where we don't want
to have to setup the complete auth context.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
as otherwise build fails in a clean environment, where no API auth
key is available.
This whole printdoc command injection is quite ugly and causes
headache in general though, we'd be better off if we could do away
with that..
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The manager, tape and debug admin and debug CLI tools all are meant
to run locally on the PBS directly and often directly by the root
user.
So for convenience they will create a valid API ticket for `root@pam`
to connect via localhost to the API proxy, either transparently if
the UID is 0 (= root) or interactively by asking the password of the
root user.
In d97ff8ae ("use new auth api crate") the API key handling was
reworked, but while the call sites that get the auth keys for signing
a ticket where adapted to use the new auth_keyring helper, the
reworked API keeps the key in shared OnceCell which needs to be
actually setup once per executable to the respective correct key,
i.e., public for the proxy, which only checks signatures, but never
creates them, and private for all those that want to sign tickets;
and that was only added for the prrivileged and public daemon, but
not above mentioned CLI tools.
So all calls into the tools that actually required to create a ticket
for connecting to the local API panicked.
Fix this by adding a call to setup_auth_context in the main entry
point of each of those CLI tools, so that they have the private key
available to be used if the tools is executed by root.
Fixes: d97ff8ae ("use new auth api crate")
Reported-by: Friedrich Weber <f.weber@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
previously the upid would just be used without a file extension when
downloading a task log. this lead to rather strange filenames that
appeared unfamiliar to users as the upid is not very prevalent in the
gui. set a proper file name based on the node name, worker type and a
time stamp instead. also add the ".log" file extension to indicate
that these files contain logs.
Signed-off-by: Stefan Sterz <s.sterz@proxmox.com>
the backup is finished at that point, the only lock clash that is possible when
dropping the exclusive and attempting to obtain a shared lock would be
- the snapshot is pruned/removed
- the backup is in a pre-upgrade process, and the post-upgrade process opens a reader
the first case is OK, if the other invocation wins the race and removes the
snapshot verification is pointless anyway.
the second case means the snapshot is not verified directly after completion
(this fact would be logged in the backup task log), but usable immediately for
pulling/restoring/..
this should decrease the chances of triggering the issues described in #4523
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Sometimes it can be quite useful to know when exactly a system report
was generated. Adds the following output:
# date -R
Thu, 23 Feb 2023 16:21:12 +0100
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Previously, the same approach as in `proxmox-backup-debug` was used.
With the changes from this commit, realm syncing uses the same method for
waiting for task output as other parts of `proxmox-backup-manager`.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Previously, if the value of a synced property did not validate properly
(e.g only 1 character in length instead of the required 2), the whole
sync job failed without any useful error message.
In this commit, the values are validated manually by their
respective StringSchema. If the validation fails, the value is
ignored and a warning is displayed in the task log.
In addition to that, some error messages have been improved.
Also, user sync is now more fault-tolerant in general, showing
warnings if something goes wrong while creating/updating a
single user, instead of aborting the whole sync job.
Reported-by: Friedrich Weber <f.weber@proxmox.com>
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Tested-by: Friedrich Weber <f.weber@proxmox.com>
while with rust strings we cannot inject \0, it feels a bit safer to
enforce some basic restrictions, with length and not containing any
slash seems sensible enough.
Admins should not put sensible data as theme-XYZ.css files in
/usr/share (which is normally readable by all system users anyway)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
adds a theme switcher to the ui and handles the necessary cookies in
the backend.
this requires a bump of the widget toolkit so the necessary widgets
are present.
Signed-off-by: Stefan Sterz <s.sterz@proxmox.com>
