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@pve.proxmox.com > https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel > > _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
