While it surely is nice to follow the layout of the job creation/edit
panel for sharing familiarity, it does not means that we need to show
the data 1:1, we can profit from the read-only fact and merge stuff a
bit, like the mail to/when field.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Not doing so leads to an off-by-one error, and pruning in a dumpdir
really should behave the same way as pruning in a storage.
Reported in the community forum:
https://forum.proxmox.com/threads/problem-mit-prune-backups.95737/
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
This is the same as fix 40ff84b138bb7127ecc05a2f587cca4e7a917810 in
proxmox-backup. When returning a boolean instead of the expected
{negative, 0, positive}, the behavior is browser-dependent.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
This was already possible via API (or manually editing vzdump.cron)
for a long time, but the settings were not visible in the UI at all.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
1. Rename the isPBS variable to match the actual purpose. When editing
a backup job, the hint should not be shown, even if the storage is
PBS.
2. Allow specifying the text used for the fallback hint. For backup
jobs, the first fallback is the storage configuration, so the text
needs to be different there.
3. Make using keep-all=1 by default upon creation optional. For backup
jobs, the default should be "use fallback", i.e. no settings.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
So that we circumvent browsers caching 6.0 extjs js/css
this should (at least for new users upgrading) fix the browser caching
issue for extjs (we had some now in the forums)
I did it this way since we do not often change version of the extjs
package (since its a big task everytime anyway), but if wanted i can
do it differently. e.g.:
* hardcode it in the perl code
* generate it during the build (also for the control file)
But this is fine for ExtJS as we rarely update that and especially for
major releases we would need to adapt stuff anyway
Also bump the versioned dependency on extjs to 7.0.0 in the Debian
control file.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Adds some missing descriptions to the api/man page documentation, for
certain options of the `pvenode` command. Some minor language fix-ups
are also included
Signed-off-by: Dylan Whyte <d.whyte@proxmox.com>
the GUI now defaults to creating unprivileged containers with nesting
enabled, but that requires a pve-container that actually allows this for
VM.Allocate users instead of root@pam only
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
but only enable the field for unprivileged containers.
We do this, since newer containers need this feature for basic
functions.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
remove type check for the specific plugins, instead we can deduce it
from the supported content type in config (this can only be set on
storages that declare to support backups). should also work with
external storage plugins.
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
link the user directly to the vm config section of the pci
passthrough docs, since that is whats happening on that panel.
It still is on the same page as the whole passthrough docs, so
the remaining info is still there.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
With live migration with local cloud-init disk now possible via the CLI
also remove the limitation in the GUI.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
also rearranged the regex groups to allow sk-ecdsa-sha2-...
note: FIDO keys are now parsable, the backend only supports it with
OpenSSH >= 8.2. This may be achieved with upgrading to PVE 7 or
using a back port.
so that they are documented and get displayed by pvesh/pvenode
all those fields must exists (since they come from the upid)
aside from the exitstatus, so marking that as optional
forum user reported that they are missing:
https://forum.proxmox.com/threads/ergebnis-eines-tasks-per-api-abfragen.92267/
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
The check isn't specific enough, it also catches deb-src entries and
would give a false impression of security in certain circumstances, or
lead to false negatives in case you have a deb-src entry for
buster/updates even though you have bullseye-security in just the next
line -- something that isn't that uncommon for developers.
Signed-off-by: Rhonda D'Vine <rhonda@deb.at>
Reviewed-by: Fabian Ebner <f.ebner@proxmox.com>
If the same local storage is configured twice with content type
separation, migration in PVE 6 would lead to the volumes being
duplicated. As that would happen for every migration, such an issue
would likely be noticed already, and in PVE 7 such configuration is
not problematic for migration anymore. Also, misconfigured
unreferenced volumes are not an issue with respect to the upgrade
itself, just drop the check.
It's not necessary to scan storages with either 'images' or 'rootdir'
anymore, as only the log_info() remains.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Shared storages are not scanned for migration either, so they cannot
be problematic in this context. This could lead to false positives
where it actually is completely unproblematic:
https://forum.proxmox.com/threads/proxmox-ve-7-0-released.92007/post-401165
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
we filtered out devices which belong into the 'Generic System Peripheral'
category, but this can contain actual useful pci devices
users want to pass through, so simply do not filter it by default.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
we incorrectly used 'total' as 100% of the to recovered objects here,
but that containst the total number of *bytes*.
rename 'toRecover' to better reflect that the unit is 'objects' and
use that as total
reported by a user:
https://forum.proxmox.com/threads/bug-ceph-recovery-bar-not-showing-percentage.91782/
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
It needs to be a 'proxmoxButton' to get activated when selecting a HA
ressource. This was lost during the last code cleanup, commit d11524c.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
we don't have a mandatory Ceph major version upgrade this time around,
so this check does not make sense. instead, we want noout until the full
cluster is upgraded. let's use the simple approach and just flip the
switch to "turn off noout if all of Ceph is a single version" in the PVE
7.x branch.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>