in theory we'd need to be more cautios but this was added only during
beta, which is when we do not really provided any stability
guarantee, further, it's rather unlikely that one added very
important repos that, when removed, break something (again *during*
beta).
The new APT repo management makes it also easy to see when one does
not gets any PVE updates, and one can add the pvetest repo there
again easily too.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Makes no sense, as the URL is the same so the info, if any at all, is
still valid - not counting the rather rare case where in the exact
moment one disables cert checking a MITM interception goes live ;-)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
As OpenID is the old one, with several security implications/issues
present, so avoid suggesting that its used.
`OpenID Connect` revers to the "third gen" on top of oauth2
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
As 200 lines is a bit much for the content view, i.e., basically
growing it by 50% in size for a very specific feature is not ideal.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
uses the common function PVE::Tools::download_file_from_url to
download a iso image or container template.
note: Only users with permissions `Sys.Audit` and `Sys.Modify` on
`/` are permitted to use the api endpoints due to security reasons.
(it is possible to download files from internal networks which would
be not visible/accessible from outside)
Signed-off-by: Lorenz Stechauner <l.stechauner@proxmox.com>
Reviewed-By: Dominik Csapak <d.csapak@proxmox.com>
metadata is gained using a HEAD request.
Due to the ability of this api endpoint to request files on internal
networks (which would not be visible/accessible from outside) it is
restricted to users with permissions `Sys.Audit` and `Sys.Modify` on
`/`. Users with these permissions are able to alter node (network)
config anyway, so this should not create any further security risk.
Signed-off-by: Lorenz Stechauner <l.stechauner@proxmox.com>
Reviewed-By: Dominik Csapak <d.csapak@proxmox.com>
while we cannot allow editing it after realm creation it is still
interesting to know to which value it was set.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
in the user menu
we have to make an additional api call here, since it is the only
place (currently) where we can get the realm type
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
[ Thomas: adapt to move of parse_userid to widget-toolkit ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Dietmar Maurer <dietmar@proxmox.com>
[ Thomas: amended the following changes:
- factor out openid_login_param to widget-toolkit as
getOpenIDRedirectionAuthorization and use it
- use camel case to match our JS style guide and our framework (and
basically the rest of the JS world)
- minor cleanups like moving variable definition into the single if
branch their used
]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
And also add the 'backup-info' endpoint to the index.
Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
these were mostly releveant for upgrading from Corosync 2.x to 3.x - so
keep the warnings/errors, but reduce the noise a bit by skipping lots of
PASS output.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
This had a myriad of issues:
* marked as protected, thus forwarded to the privileged daemon even
if it just returned static information
* did not return directory index but a "stub" string, which does not
makes sense.
* not named index
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
If neither 'rootdir' nor 'images' are configured on a storage, but
there are guest images, just log the number of volumes found. If they
are relevant for migration, the check for unreferenced volumes will
catch them later.
Also detect content type mismatch for all volumes of existing guests,
which also covers the case of a VM image on a storage with only
'rootdir' and vice versa. To catch all such unreferenced volumes too,
it is necessary to scan all storages that do not have both content
types configured.
Change the message from 'will not work' to 'might not work'. If a
volume only referenced by a snapshot is misconfigured, it doesn't mean
that the guest doesn't work at all. Or it might be an ISO on a
misconfigured storage.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
If there is a log_fail, because of misconfigured 'none' content type, the final
log_pass should not be printed.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
