ISPConfig Update

Whilst I'm sorting out things with our cluster, I decided I'd also update ISPConfig at the same time.

But with one of the nodes, I'm getting a "backup failed" when it attempts a backup of "/etc" (the previous backup of ISPConfig itself works fine). As this diagnostic message is a bit spartan, I'm not sure why the backup of "/etc" is failing.

It's not a lack of disk space, though, as "df -h" shows that "/" - under which "/var/backup" would live - has 95% free.

(I could update without a backup, I guess. But I'd rather not, lest it all goes horribly wrong.)

Also, another thing I'm wondering is if it's possible to install the ISPConfig web interface onto a node that didn't previously have it? During an update, I'm not asked if I'd like to install the web interface, but I'd actually like to do so. Because it'd be nice to have a URL like "ispconfig.domain.tld" rather than "domain.tld:8080" and my plan was to install the web interface onto my web servers, where I could create a vhost file for Apache with the new domain name.

The alternative, I guess, would be to create a vhost that proxies to "domain.tld:8080" but that seems overly complicated.

And the reason why I have to have the web interfaces on the web servers is because my load balancing passes port 80 / 443 traffic to the web servers, and deals with port 8080 itself - the port number is used to differentiate where to send the traffic - but with a standard "ispc.domain.tld" name then we're on port 80 and that'll end up on the web servers. So I want to add the ISPConfig web interface on the web servers and can sort out the vhost to that subdomain myself. As it all works through the master database and jobs are queued up, then I presume load balancing multiple web interfaces won't be a problem (as you already thought of that to design it this way).

Of course, it is possible for me to simply uninstall ISPConfig on these nodes and then add them back again, but this time specifying I want the web interface. Just checking if there's a slightly less drastic method of doing it.

 

Okay, doing some further investigation, I edited update.php to not have "2> /dev/null" in the tar command it executes, so that the output isn't silenced and what I'm seeing is:

Creating backup of "/etc" directory...
tar: Removing leading `/' from member names
tar: /etc/letsencrypt/renewal/domain.conf: file changed as we read it
Backup failed. We stop here...​

So, for whatever reason, it reckons that this file is changing while it's being read. Now, the "/etc/letsencrypt" directory is actually on the shared storage server and bind-mounted - so that every web server can access the Letsencrypt certificates - but, well, the other nodes updated just fine (and that's also true for them too) and nothing would be altering that file right now (just certbot at renewal but that's not due).

 

Right, I added "--warning=no-file-changed" to the tar options, which apparently stops it complaining about changed files, but then it's saying that it can't stat the "etc.tar.gz" archive itself. Which is odd, as the command is all about creating that archive in the first place.

 

Yes, in the end, this is what I did and it worked. I just manually copied the files with the shell and then updated without selecting "yes" for the backup.

(Although, yes, maybe I was being overcautious anyway, as the whole disk does get periodically copied over to another disk via a daily cronjob too. But, basically, whenever I do big updates of major software, I'm always nervous, double-checking and paranoid to never hit that ENTER key until I'm 100% sure that I'm able to reverse it.)

So that issue is fixed now. But I'm still wondering about the possibility of adding the web interface to a node that didn't previously have it - the ":8080" is very ugly for our customers.