which returns a list of challenge api types with the schema of their
required data (if it exists)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
[ Thomas: adapt to my changes from proxmox-acme schema def and change
path from challengeschema to challenge-schema ]
As proxmox-acme has now a default delay for DNS challenge plugins,
which is the important one. Those are just for not overloading the
acme servers with a lot of requests, but once the challenge was
propagate they have it verified pretty quickly, so reduce delay for
checking validation after first requesting it down to 10 seconds
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
re-loading it always would mean that we could potentially switch the
config to something completely different, and the mix of the previous
and the old could result in total bogus actions.
Better to use the same one for one full order, even if it may get
"outdated" it was still valid in the past and most important
coherent.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Drop various leftovers from the storage content API module this was
based on, e.g., ACME plugins have no fixed options and the like.
Also, the descriptions shouldn't mention "storage".
Further, drop the "update_config" "helper" with its operations
effectively only increasing code complexity and adding another rabbit
hole to jump into.
IF, this should have been factoring out the lock+read+write cycle
only, living the rest to a passed CODE-ref, but honestly that saves
only really the read and write config lines, and at this point
nothing is really gained, so just let it be.
Should have been actually three or so separate patches, but to deep
into this rabbit hole to care..
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
for now mostly due to the "nice" property of the acmedomains which
do not use their property key as index but actually the doamain.
Without this one could set up duplicated domain entries just fine,
but once using them -> error.
This is not nice UX, so verify node config before writing an updated
one out, to catch those issues.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
add checks, encoding of loaded data files, update API path, proper inclusion into API tree
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
instead of relying that the authorization URLs and the ordered
identifiers are sorted the same way for already validated
authorizations.
on the contrary, RFC 8555 even says:
"The authorizations required are dictated by server policy; there may
not be a 1:1 relationship between the order identifiers and the
authorizations required."
authorizations MUST always include a single identifier, no matter which
state they are in.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
mixed bag of improvements:
- return hash based on domain
- check for duplicate domains, allow overlap between main and additional
keys otherwise
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
With this configuration it is possible to use many different plugins
with different providers and users.
Signed-off-by: Wolfgang Link <w.link@proxmox.com>
The public_addr option for creating a new MON is only valid for manual
startup (since Ceph Jewel) and is just ignored by ceph-mon during setup.
As the MON is started after the creation through systemd without an IP
specified. It is trying to auto-select an IP.
Before this patch the public_addr was only explicitly written to the
ceph.conf if no public_network was set. The mon_address is only needed
in the config on the first start of the MON.
The ceph-mon itself tries to select an IP on the following conditions.
- no public_network or public_addr is in the ceph.conf
* startup fails
- public_network is in the ceph.conf
* with a single network, take the first available IP
* on multiple networks, walk through the list orderly and start on
the first network where an IP is found
Signed-off-by: Alwin Antreich <a.antreich@proxmox.com>
so that we can choose to only include the versions and not all metadata
this is done to avoid having a seperate 'versions' api call
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
instead of having multiple regexes in various places for the name,
define a 'SERVICE_REGEX' in PVE::Ceph::Services, and use that
everywhere in the api where we need it
additionally limit new sevices to 200 characters, since
systemd units have a limit of 256 characters[0] (including suffix), and
200 seems to be enough.
users can now create ceph services on machines with hostnames
longer than 32 characters
0: https://www.freedesktop.org/software/systemd/man/systemd.unit.html
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
the network and the cluster network are optional in the ceph config
and with 'pveceph init', so only check if we have an ip address
from those networks if it is actually configured
otherwise, the createosd call dies with an 'ip' error message
even if it would work
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
To (re)start and stop Ceph services the API calls systemd units using the
function ceph_service_cmd. If unspecified, this function assumes the type
".target" for a unit. By making the unit type suffix in the API optional, it
can make use of this assumption.
Signed-off-by: Dominic Jäger <d.jaeger@proxmox.com>
We need a recent version *and* our patches on top of the vanilla
ifupdown2:
0001-don-t-remove-tap-veth-fwpr-interfaces-from-bridge-on.patch
0004-don-t-remove-bridge-is-tap-veth-are-still-plugged.patch
So check for at least 1.2.8 and the pve string in the version output.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
It's possible to have a situation where the cluster network (used for
inter-OSD traffic) is not configured on a node. The OSD can still be
created but can't communicate.
This check will abort the creation if there is no IP within the subnet
of the cluster network present on the node. If there is no dedicated
cluster network the public network is used as a failsafe even though
this situation should not occur.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
Ceph MGR fails to start when installed on a node without existing
symlink to /etc/pve/ceph.conf.
Signed-off-by: Alwin Antreich <a.antreich@proxmox.com>
To make it backward compaitble. NBo real harm without this, but lots
of ugly undefiend $val warnings...
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
