tl:dr; So if you’re reading this thread and you want to setup diaspora* on CentOS, read the entire script and make sure you understand every single line of it before running,
It’s dangerous to go alone Proceed with caution.
While I do appreciate the effort, I… don’t quite like this. I agree that diaspora* is way too complicated to set up at the moment, but this is something we as a project have to solve, and not something anyone should hide away behind a script that claims to do everything correctly. Instead of spending time on such scripts, we probably should be spending time on improving our own setup flow, and improving documentation. I obviously can’t tell you what to do - and I’m not trying to do that - but let me go into detail why I think this isn’t great:
- You make a lot of assumptions that may completely break someone’s setup. You seem to assume that people will only ever run this on a dedicated diaspora*-only VM, which isn’t quite the reality. Most people try to add diaspora* to their existing one machine. Blindly installing apache and mariadb may go horribly wrong if people already have nginx or mysql installed.
- Another assumption is that users are fine with registering their pod on
the-federation.info, which I know not to be universally true.
- The script completely hides
diaspora.yml away from the podmin. The eMail setup will pretty much never work unless the local server is also their mailserver, because pretty much everything else will require authentication. Podmins also will never see all the other options that are available - for example closing the pod down for new signups, removing inactive accounts, setting up a welcome message, … We did spend a lot of time documenting every option, and podmins really should go through the file manually.
- Copying over a potentially old version of
diaspora.yml and the
database.yml isn’t good. This gets outdated very quickly.
- Things like the iptables config are so specific to your setup, they’ll break on other machines (not all network interfaces are called
ens192, for example.)
- If there is already an application on the server that uses redis, this setup will start burning immeidately.
- … who is going to update this setup when there is an upstream change or a diaspora change.
There is a lot more, but I think you get the point. We’ve seen many attempts like this before - hosting providers trying to offer a 1-click-diaspora*-installer, which tremendously goofed up pods because they simply missed somthing in their script, resulting in us spending weeks of work just to fix that; people building packages for their favorite distribution, which was outdated before it got into the mainline repo, and making so many wrong assumptions that the setup was broken and we had no idea how to fix it because we didn’t know the setup, … it’s a mess, really.
I’m having a really hard time endorsing something like this script. While I like the amount of work you spent, hiding away diaspora*s current complexity behind a script that makes bold assumptions and does things a lot of podmins may not fully understand is nothing I’m really comfortable with.