some high-level feedback: - looks much better than previous version already, I think v3 should be the one that makes it :)
- just upgrading triggers the following error on order/renew: Loading ACME account details Placing ACME order Order URL: https://acme-staging-v02.api.letsencrypt.org/acme/order/foobar Getting authorization details from 'https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/barbaz' ... pending! can't open '/etc/pve/priv/plugins.cfg' - No such file or directory ...propagated at /usr/share/perl5/PVE/ACME.pm line 527. Task can't open '/etc/pve/priv/plugins.cfg' - No such file or directory ...propagated at /usr/share/perl5/PVE/ACME.pm line 527. - Touching that file and repeating: Loading ACME account details Placing ACME order Order URL: https://acme-staging-v02.api.letsencrypt.org/acme/order/6085187/82472654 Getting authorization details from 'https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/46773730' ... pending! Died at /usr/share/perl5/PVE/ACME.pm line 527. Task Died at /usr/share/perl5/PVE/ACME.pm line 527. what's at line 527? 527 die if $plugin_type eq "standalone"; die without a message ;) also, "standalone" is the (implicit) default, so this whole die is probably very wrong? removing it, and adding a standalone plugin definition to /etc/pve/priv/plugins.conf and /etc/pve/local/config seems to work, but this needs to be fixed else ALL the configs out there break on upgrade. it's probably a good idea to just always define a 'standalone: default', similar to the always defined local storage, and then use that as default plugin id when going from NodeConfig -> ACME if no explicit one is defined. - some more detailed comments as replies to individual patches, a mix of design/architecture improvements and concrete stuff On March 31, 2020 12:08 pm, Wolfgang Link wrote: > The acme_sh project is used as a DNS API plugin system. > So we can reuse the already defiend plugins. > I add it as a submodule. > > The acme.sh script is replaced by proxmox-acme, > which contains the function required to operate the DNSAPI plug-ins. > > The login information is saved in the file plugin.cfg > and passt directly on the proxmox-acme. > > The DNSAPI plugin credentials are not standardized, so each plugin expects > different parameters. > > These patches are only tested against the OVH API because of missing > alternative possibilities. > > This implementation uses the design that we discuss at the pve-devel list. > It doesn't have much to do with V1. > > Build conflicts arise due to the code movements. > The prerequisite for this series is the installation of Curl. > For this series you have to create the deb packages pve-common, pve-cluster > and proxmox-acme. > Then apply these packages and you can now build and install the pve-manager > package. > > The GUI is broken at the moment. > Fixes will follow shortly. > Old configurations are converted and can be used without any problems. > The new configuration must be defined via the CLI. > > For the alias mode a CNAME record is needed > _acme-challenge.<host>.<domain>.<TLD> CNAME _acme-challenge.<Alias > Target> > > Steps to test. > > 1.) pvenode acme account register default <mail@example.invalid> > 2.) pvenode acme plugin add <dns|standalone> <plugin_id> --data <login > information> > 3.) pvenode config set --acme > domain=<Domain>,plugin=<plugin_id>[,alias=<alias_domain>] > 4.) pvenode acme cert order > > > > _______________________________________________ > 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