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

[Fabian Grünbichler]

note: the comment here is not just for this patch, but also references 
stuff that comes in later patches..

On October 14, 2019 1:08 pm, Wolfgang Link wrote:
> The dynamic approach reduces failure if new plugins will included.
> ---
>  src/PVE/ACME.pm            | 4 ++++
>  src/PVE/ACME/Challenge.pm  | 8 ++++++++
>  src/PVE/ACME/StandAlone.pm | 4 ++++
>  3 files changed, 16 insertions(+)
> 
> diff --git a/src/PVE/ACME.pm b/src/PVE/ACME.pm
> index 38a14a5..da4cbcc 100644
> --- a/src/PVE/ACME.pm
> +++ b/src/PVE/ACME.pm
> @@ -17,6 +17,9 @@ use LWP::UserAgent;
>  
>  use Crypt::OpenSSL::RSA;
>  
> +use PVE::ACME::Challenge;
> +use PVE::ACME::StandAlone;
> +
>  use PVE::Certificate;
>  use PVE::Tools qw(
>  file_set_contents
> @@ -24,6 +27,7 @@ file_get_contents
>  );
>  
>  Crypt::OpenSSL::RSA->import_random_seed();
> +PVE::ACME::StandAlone->register();
>  
>  my $LETSENCRYPT_STAGING = 'https://acme-staging-v02.api.letsencrypt.org/directory';
>  
> diff --git a/src/PVE/ACME/Challenge.pm b/src/PVE/ACME/Challenge.pm
> index 40d32b6..786666c 100644
> --- a/src/PVE/ACME/Challenge.pm
> +++ b/src/PVE/ACME/Challenge.pm
> @@ -3,6 +3,14 @@ package PVE::ACME::Challenge;
>  use strict;
>  use warnings;
>  
> +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

(moving the definition together with the rest of general ACME code to a 
new package would allow PMG to re-use most of it with just a different 
high-level client and file location)

the GUI could have a mapping of the most important plugins and their 
config KEYs, with a fallback to just "edit whole data as textfield" or 
"edit whole data as key-value pairs". this would still allow adding your 
own acme.sh dnsapi compatible plugins, and would avoid having to import 
the full key-value schema into our section config.

the node config's acme key would then just reference the concrete plugin 
instance (but see later patches for another issue regarding this), which 
would be available cluster-wide, but also allow different plugin 
instances for each node..

> +
> +my $defaultData = {};
> +
> +sub private {
> +    return $defaultData;
> +}
> +
>  sub supported_challenge_types {
>      return {};
>  }
> diff --git a/src/PVE/ACME/StandAlone.pm b/src/PVE/ACME/StandAlone.pm
> index f48d638..3766862 100644
> --- a/src/PVE/ACME/StandAlone.pm
> +++ b/src/PVE/ACME/StandAlone.pm
> @@ -8,6 +8,10 @@ use HTTP::Response;
>  
>  use base qw(PVE::ACME::Challenge);
>  
> +sub type {
> +    return 'standalone';
> +}
> +
>  sub supported_challenge_types {
>      return { 'http-01' => 1 };
>  }
> -- 
> 2.20.1
> 
> 
> _______________________________________________
> pve-devel mailing list
> pve-devel at pve.proxmox.com
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> 
>