Hey Tim, I just posted that the Nginx vhost update on the slave was working and solved which it seems to be. However I just realized that the LetEncrypt update is not being triggered during this process of updating the Nginx Vhost. Is there another plugin that triggers that which I may have missed, can't see any difference on the master to the slave / master. I can see the primary server LetEncrypt code working in the log but no equivalent on the slave server.
Just setup an rsync of /etc/letencrypt from primary to secondary which has at least updated the certificates. I assume the certs would normally get triggered at the same time as the slave nginx update ?
Certbot certs are created on the master only, otherwise both nodes use would use different certs and issuing of certs would fail. /etc/letsencrypt and /usr/local/ispconfig/interface/acme/ should be on a shared network filesystem that is accessible on both nodes.
Thanks Till, I'm trying to understand the advantage of an NFS share on one server over rsync or unison ? If I create a nfs mount on the primary server am I not creating a reliance on a this share and machine being available / accessible on the secondary server ? Would it not be better to have complete copies of the files and no reliance on the primary server in the event it goes down ?
rsync or unison will not work here as it's not realtime. If certbot tries to renew the cert when run on the master and the incoming verify request from le isreceived on the slave and not the master, then the cert renewal (or creation) will fail if you use a non-realtime solution. Beside that, ssl activation in an ispconfig website on slave will probably dail too when LE is used as the cert is not on the slave at the time the slaves is writing the vhost configuration.
Ah yes I understand it relates to the renewal process that could fail with the incoming query not being on the other respective server in time.
I moved to the NFS share to primary server which appears to be working a week or so back. With geographically challenged primary and secondary servers there is quite a large latency with reading the NFS share. In setting this up one aspect that struck me is if the primary server goes down for whatever reason and the secondary server gets restarted (again for whatever reason) it will not be able to load the SSL certificates. We will of course be storing backups to external servers which would resolve the aspect of not having the share, is this how you mitigate this potential issue ? I will probably do a test of this scenario, will not having the NFS share available affect any services on outage ? I believe postfix and dovecot load those files on startup, I haven't looked at nginx but assume it does something similar.
When the NFS server fails then that's a problem indeed, as services will fail when you try to restart them and the SSL cert is unavailable. There is no real solution for that, one thing might be to automatically create a backup copy of the certs and in case that nfs share is offline this script creates a symlink to the backup or similar.
An other option might be to use a network file system which has also local caching, e.g. glusterfs, instead of nfs. But I haven't tried that, just an idea.
Just a query in setting up a third server, this time without ISPConfig at the present time, I used Certbot to install a certificate which used a DNS entry to verify against. Have you guys looked at that functionality as opposed to using web based files ?
Yes, I'm aware of that option and we plan to implement it. The problem is that it will not work that seamlessly for most users as multiple steps are involved in that case, some of them outside of ispconfig, when the dns server of that domain is not the ispconfig server or a node of the same ispconfig multiserver setup.
