The main change with Bullseye is the move to PHP 7.4, so if you’re migrating from a previous version of Sympl you should ensure your sites operate normally with the new PHP version.
There have been quite a few changes under the hood, mainly around the way email security is handled due to changes with the underlying Exim mail server version being used, but you shouldn’t notice any issues. For a full list of the changes, you can check the changelog.
As before, all other features in Sympl are the same across all versions, with Sympl 9, Sympl 10 and Sympl 11 all having identical functionality, and as before we’re committing to supporting Sympl 11 for the lifetime of the Debian release.
I hope this isn’t a silly question, but how risky is it likely to be to upgrade a running server by updating the contents of /etc/apt for both Debian and Sympl and then just running apt dist-upgrade ?
I think I got away with doing similar in the past on Bytemark and Symbiosis, but I didn’t know better then and I have some more serious commercial customer sites now. I don’t think an hour or so of downtime at a weekend would be a problem during the upgrade, but if there were problems that needed fixing over the next few days it would be embarrassing.
The safer alternative would be to move sites and mailboxes one domain at a time to another server, fixing glitches as they appear.
Doing a dist-upgrade is always dangerous, the further things get done the default Debian configurations, and while Sympl has its own unique configurations for things like mail, it’s not uncommon for something not to clean up properly after itself, which can end up with things in an inconsistent state, such as PHP5 still being enabled after it was supposed to be replaced with PHP7 in a Jessie to Stretch upgrade.
On top of that, most installs are likely customised to some extent, especially with different cloud server providers, so while it may work okay with one, you may have problems with another.
The safest way (and only supported way at the moment) is to simply set up a fresh machine and migrate context across, but obviously that’s not possible in all situations.
Once Bullseye has been around a few weeks then it should be something I can look at properly, taking a stock Sympl Buster install and comparing it to stock Sympl Bullseye before and after a dist-upgrade.
Migration to Bullseye is also my next ‘rainy day’ task.
Anahata, so we can all learn, could you kindly post details of any glitches you encounter during the process of installing sympl on a fresh Bullseye vm and during your subsequent migration process.
I’ll post what I can that might be useful. Most of the glitches are likely to be from my own customisations which won’t apply to other users (e.g use of bind9, nftables and fail2ban.)
Anahata that would be brilliant, thank you so much in advance!
Sympl sure is a great piece of work. However I just couldn’t get to grips with dns setup on a Mythic vm (domain externally registered with 123 reg) so I resorted to installing Sympl on a Bytemark vm in order to harness Bytemark’s content dns system; thereafter Sympl worked brilliantly.
However, Bytemark’s not quite the same as it used to be so I’m keen to transfer business across to alternative hosting. As a former Symbiosis user I was able to get to grips with Sympl despite the lack of mature documentation but the stumbling block for me remains dns config and deployment.
In lieu of mature Sympl dns documentation it would be useful to learn how others are managing the dns aspect?
This is perhaps not the place to go to great lengths on how I do DNS (nor others to describe how they do theirs). Perhaps I should put a write-up on my web site and link to it from a freshly created thread on this forum.