[pve-devel] [common 1/9] Add dynamic plugin lookup for ACME

[Thomas Lamprecht]

On 10/22/19 11:17 AM, Fabian Grünbichler wrote:
> On October 21, 2019 12:12 pm, Wolfgang Link wrote:
>> On 10/18/19 11:22 AM, Fabian Grünbichler wrote:
>>> On October 14, 2019 1:08 pm, Wolfgang Link wrote:
>>>> +use base qw(PVE::SectionConfig);
>>> this would be the only SectionConfig that is not actually a config..
>>>
>>> after some off-list discussion with Thomas, how about the following:
>>>
>>> move PVE::ACME::Challenge and PVE::ACME::StandAlone to pve-manager, or a
>>> new pve-acme package (the latter could be combined with PVE::ACME, and
>>> some parts of what is currently in pve-manager, and your new
>>> package/repo)
>>>
>>> make the challenge plugins a real SectionConfig:
>>>
>>> standalone: http80
>>>    port 80
>>>
>>> dns: ovh1
>>>    api ovh
>>>    data encode_text("KEY1=foobar\nKEY2=foobaz")
>>>    nodes node1
>>>
>>> dns: ovh2
>>>    api ovh
>>>    data encode_text("KEY1=barfoo\nKEY2=foobaz")
>>>    nodes node2
>>>
>>> for PVE, store that section config file in
>>>
>>> /etc/pve/priv/acme/plugins.cfg
>>
>> I agree.
>>
>> It the ovh1/ovh2 the name of the definition like in storage.cfg?
> 
> yes. the string before the colon is the section type/plugin, the string 
> after is the ID of that specific section/plugin instance, just like in 
> storage.cfg
> 
>> Nodes should be a node list or '*' to indicate to use wildcards certificate.
> 
> I'd skip wildcard certificates for now (unless you explicitly want to 
> include them in your v1?) and just use the same definition like for 
> storages: either a list of nodes, or all nodes if absent.

I mean wildcards would be really nice and the end goal of all this,
but having first the infrastructure in place and then adding this in
a future series is totally fine for me.

> 
> for wild-card certificates we'd need more changes anyway:
> - not stored under /etc/pve/local
> - which nodes should use it (-> flag in node config?)

hmm, do we want to enforce that a cluster is a domain? I.e., all are just
hostnames on the same (sub)-domain? 
Giving the word domain some value back and making it slightly easier for us?
I'd guess that it should be OK for, like, 99.99% of real setups, accessing
clusters under different high level domains, or even accessing some parts of
clusters under different high level domains seems rather odd, maybe even
complex for some of our users. I'd omit that in a "v1 of wildcards" (independent
from if you send it already along with this series, or in a future one).

> - which node(s) should renew it

maybe all should try with a very low frequency (weekly timer?), lock the config
during that, then either check the certificate for it's lifetime left, and if
that's lower than X (where X is something a few weeks to a month), renew it.
We could also write the "time-at-reneval" in the config, but that seems
unnecessary if we have the real source of truth, the certificate itself,
available to check.
This way it's ensured that the cert will always get renewed as long as there
is a quorate partition. Having just one wildcert per node would simplify this
and avoids a case were a temporarily inquorate partitions certificate expires.
IMO, it would be really better to have wilcard certs just cluster-wide, else
we get just PITA edge cases for not much "real world usage" gain..