What Core Maintenance does your team do?

As we are still in beta, new files and features are still being added regularly.

However in the long-term, our team (or whoever forks SlickStack) would need to keep the following in mind:

The root crontab is the “holy” part of SlickStack, the only file that can’t self-heal. It absolutely must install correctly during initial install, or during reinstalls.  The root crontab will forcefully download and reinstall the ss core cron jobs multiple times per day, so even if they are corrupted, a few hours later they will be reinstalled again. The ss core cron jobs are the life blood of SlickStack because they perform various self-healing tasks and also run custom and scheduled tasks (based on SS_INTERVAL settings in ss-config). As far as self-healing, the ss core cron jobs will ensure (every time they run) that ss-config, ss-functions, ss-check, and ss-worker exist and are intact. If ss-config is corrupt or missing, the core cron jobs will attempt to restore ss-config using a recent backup in the /var/www/meta/ directory. If the ss-functions, ss-check, or ss-worker files are corrupt or missing, the ss core cron jobs will forcefully download each of those files from our public mirrors and then forcefully reinstall them to the correct location.

Because there are so many ss core bash scripts (which occasionally change) we have the ss-check script perform the retrieving of all the ss-… bash scripts. This is also performed forcefully meaning that every time ss-check runs, it will download and overwrite any existing ss-… scripts under /var/www/ directory to ensure they are always current. To ensure ss-check is not self-reliant, we have the ss-worker script download and reinstall the ss-check script instead… along with some other maintenance tasks, and self-healing of the “modules” if needed. For example, if ss-worker notices that SSL certificates are missing, it will run ss-encrypt. Or if it notices the UFW Firewall config file is missing, it will run ss-install-ufw. Keep in mind also that ss-check is also retrieving and reinstalling the ss core cron jobs files too (not just the ss-… scripts) so there is various redundancy built into SlickStack.

As the ss core cron jobs have become more and more our focus, we’ve questioned whether or not to get rid of ss-check or ss-worker entirely, and have the cron job files perform 100% of self-healing and file retrieval tasks. If you have opinions on this, please let us know.

All of this to say that what our team “maintains” at the end of the day is mostly releasing new config file versions for modules (e.g. Nginx or UFW) and over time, less and less “patches” should be needed for our ss core cron jobs and ss core bash scripts. We will also continue to “bump” the SS_BUILD version in ss-config-sample boilerplate when new settings are released, or when new versions of modules (or their config files) are released.

The maintenance that YOU (as the server admin) need to do with SlickStack should be minimal, since the point of SS is to be totally automated. However if you want to check on the health of your SS server you can verify that ss-config looks good, that ss core cron jobs exist (and are being called regularly as per /var/log/syslog), and that all ss core bash scripts exist.