January 2019 Upgrade
We’ve recently released an update to SpinupWP that will enable SFTP/SSH access on a per-site basis and provide security isolation between your sites by running each site as a separate system user. Upgrading is a multi-step process that involves first running some upgrade routines on the server and running different upgrade routines for each site. This allows you to upgrade one site at a time and test each site after each upgrade. But each site and server upgrade should only take a minute or two.
You will not be able to deploy new sites to a server until you have upgraded the server. Nor will you be able to manage existing sites via SpinupWP until they’ve been upgraded.
After clicking ‘Upgrade’ the
site-users group is created. This is the group that will be added to all site users. The Access Control Lists policies (added next) will be applied to this group.
ACL policies are added to the following directories:
This will prevent site users from viewing files in those directories.
Our cache daemon is installed, which allows the page cache to be cleared via our plugin. This is required because PHP will no longer have write permissions on the cache directory when a site is upgraded to use PHP pools (below). We install Supervisor to ensure the cache daemon is always running (even after a server reboot).
After you’ve upgraded a server you will be able to upgrade each site by visiting the site dashboard in SpinupWP. You’ll be prompted to enter a username when upgrading each site. This will be the system user which runs the site and must be unique, as no two sites are allowed to run as the same user.
A PHP pool will be created, which is owned by the new site user and ACL policies will be applied to the pool config. This will prevent other site users from viewing the PHP configuration. Nginx will be updated to forward PHP requests to the new PHP pool.
chown will be performed on the site directory, which will update ownership to the new site user.
Our plugin will be updated so that it can forward purge requests to the cache daemon.
A server cron job will be configured under the site user, to ensure that WordPress cron is performed every minute.
Finally, logrotate configuration will be updated to reflect the new file ownership of log files.