The future of Symbiosis


#1

Looking on Github I see no project for Debian Buster on symbiosis. Given how long it takes to build and test symbiosis on a new Debian release I would have thought something would have been started by now? Would be good to get an idea so I can begin to plan for the future.


#2

Take a look here @phill104:

https://sympl.host/what-is-sympl/

Andy


#3

Thanks for that. I will set it up on a Pi and see how I get on.


#4

All bar 1 of mine now are running sympl as linked above.


#5

Was it easy to setup on Bytemark? Did you have to filled with DNS much?


#6

To be honest, at the minute, the 1 symbiosis machine left is running most of the DNS for the other servers, but I’m planning to change that.

I believe the DNS side of sympl has some development planned for uploading to other systems if used elsewhere.

I’m not sure if the BytemarkDNS is included in sympl.


#7

Yeah (don’t quote me) but I’m not entirely sure Symbiosis is actively developed by Bytemark anymore. Sympl is a very good active fork though


#8

It is a shame nobody from Bytemark responded as it would be nice to get it from the horses mouth so to speak.

My only concern with Sympl would be DNS setup and how I achieve that on Bytemark


#9

Given that symbiosis no longer seems to be maintained, I’m not sure that I’d want to rely on a Bytemark DNS solution long term anyway.

In theory, the BytemarkDNS script should work just on sympl as well as symbiosis, perhaps @Kelduum could confirm if this is the case? I’m not sure how you’d go about installing it though.


#10

Yes, it should work the same way for now, as the hook for /root/BytemarkDNS/upload are still there.

Sympl should create a dummy file at that path if none exists when it’s installed, but I haven’t been able to test it yet so take care if you’re running it on an existing Bytemark imaged server.

Longer term, sympl-dns will be replaced with wrappers around OctoDNS, to add support for various other DNS providers, but it’s not clear yet if I’ll be able to retain backward compatability with Bytemark’s old DNS platform, however the newer panel-based one should work if they have the relevant API’s enabled.

As far as the future of Symbiosis goes, I forked Sympl when it looked like there wasn’t really a future for Symbiosis - there were no developers remaining within Bytemark at the time, and the support team member(s) who had worked on Symbiosis Stretch were unlikely to have the time to make the relevant updates.


#11

Many thanks Paul. It is nice to see the excellent symbiosis live on. So much work went into it that it would be criminal to have seen it die.


#12

I am aware that Sympl officially does not support upgrades from Symbiosis, but starting afresh is a very unattractive prospect for me.
Has anyone tried moving to Sympl from Symbiosis? If so, how did you do it, and how did it go?


#13

While I can’t officially Support it, if someone wants to write a HowTo on the Sympl Wiki, then that could be useful.

I’ve upgraded a few test machines, but the end results were inconsistent depending on how closely it was to a stock Debian install.

In theory, it would be possible to ‘upgrade’ by removing the bytemark-symbiosis and symbiosis-* packages, along with anything else which Symbiosis needed (theres a few Ruby things packaged by Bytemark as part of the Symbiosis install, so effectively return it to a base Debian install), then run the Sympl installer, you should be fine.

The preferred option would be to simply migrate however, and there’s a guide for that already.


Symbiosis/Lets Encrypt: Account creation on ACMEv1 is disabled (certificates fail to be created/renewed)
#14

Well, I tried it on a dev server. I did it like this:
apt remove bytemark-symbiosis
apt remove symbiosis*
apt autoremove
then I installed sympl
there was a problem with ftp, so I fixed that by
apt remove sympl-ftp
apt remove pure-ftpd
apt install sympl-ftp
apt install pure-ftpd

So far it all seems fine. Is there annything in particular I should look at?


#15

I’ve considered doing it that way but I think I’m just going to do a fresh install and pull the data back across


#16

There are a couple of packaged ruby libraries and so on which are needed by Symbiosis, and the packages are only in the Bytemark repo.

I don’t recall what they are, but it’s worth checking they were removed as you may end up with conflicts.

Similarly, it’s probably worth doing an apt purge symbiosis-* bytemark-* to make sure everything is gone, and try to get the system as close as possible to a stock Debian.

It may be worth firing up BigV VMs running SymStretch and regular Debian Stretch, and comparing the packages/filesystems to be sure everything gets removed fully.

That’s the best option really, as you may find things act unusually later on otherwise.


#17

As I have explained several times, a fresh install is not an option.

It isn’t a VM, it’s a dedicated host running loads of domains and loads of websites and email boxes.

Leaving aside the cost of setting up a new server, the downtime would be unacceptable.

Many people’s livelihoods depend on it working. They can’t have a few days off whilst I play with migrating their website. Their customers would be mightily unchuffed.

As far as I can see, the only thing that isn’t playing nicely after moving to sympl is nextcloud, but that instance of nextcloud wasn’t in use before, so it may not have been working anyway.


#18

My symbiosis box is in the same position - a dedi outside of bytemark.

My plan was to make sure backups were up to date late at night, then going into the early hours take server down, reinstall OS (20 mins?), install sympl (10 mins) and then pull /srv and database dumps.

IMO a couple of hours overnight for maintenance is going to be no worse than a failed disk during the day - and if it ensures everything will run correctly I think it’s the way I’ll be going about it.


#19

Nice optimism there. Were you involved in the planning of the TSB migration?
I saw some of their documentation before the TSB fiasco, and I commented that it seemed that they assumed all would go well and nothing could go wrong.


#20

I’m aware stuff can go wrong, even with any well planned project, but pulling the data back into a fresh Sympl install is less likely to go wrong down the line IMO.