There is a usable walkthrough on installing diaspora* on CentOS 7, but it’s quite a lot to go through manually and doesn’t give a lot of help in configuring the supporting systems like iptables, Apache and MariaDB.
So, I turned it into a script with an accompanying directory of support files.
You just have to extract that tgz file and run the dinstall.sh script; it will ask you some questions, then do the whole install. Some of the commands it calls are interactive (specifically certbot and mysql_secure_installation) but I don’t think any of the prompts can timeout so checking the terminal occasionally should be enough.
It does the complete setup of Diaspora* for you, with a server start script as well as setting up scheduled local backups and scheduled LetsEncrypt cert renewals.
It does need integration as a system service to be complete, but I normally do that via Puppet so I’m going to have to go learn how to write init scripts before I can add that.
This is pretty awesome! Manual Diaspora install can be rather tedious with little but important things easily forgotten.
Just a heads up though: Diaspora seems to be optimized for PostgreSQL, there can be very noticeable performance difference and there were talks about gradually dropping support for MySQL in the future.
So if you have a young pod, consider switching the DB.
That’s annoying; I have many (many) years of MySQL and now MariaDB experience, and pretty much no PostgreSQL. Even if a service is optimized for Postgres I’ll pretty much always opt for Maria since I’m way more experienced with it and server resources at this scale are basically free. (The VM host is running at <20% utilization with 25 active VMs on it.
I’d be happy to add a Postgres branch to this, since just installing the RPM and setting Diaspora* to use it would be simple enough, but I may need some help with the post-install security and backups parts.
Though please, if there are any devs listening, please don’t drop MariaDB support.
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.
Thanks for the specific comments; I’ve added a description of the script’s assumptions about the host it’s installing on and how the diaspora* install should be configured at the top and prompted the user to confirm that before proceeding.
I also added a block at the end about going through the diaspora.yml file.
Like I said, I made this for my own use and figured I’d share it for anyone who it could help; I don’t want it to bork anyone’s server, so thanks for the comments.
I flagged this script very specifically with the version of diaspora* it’s for; I intend to update that with future diaspora* releases. (Simply because I intend to keep using it, not because I expect anyone else to.
Can you provide a list of services to be started after running the script?
I have managed to run the script without errors and rebooted afterwards. But I keep getting “503 service unavailable” when I browse to the *diaspora instance.
You may need to manually execute /etc/rc.local after a reboot.
CentOS 7 seems to not execute it reliably, and I haven’t taken the time yet to figure out why; the docs say if the file exists that they’ll run it, but this seems often not to happen.
The install script adds the following to rc.local:
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: