Ubuntu 20.04 diaspora-installer-MySQL setup

Support Podmin Support
1

I’m trying to set up a new pod on Ubuntu 20.04 using the diaspora-installer-MySQL package. The installation completes with no errors but there is no default page in the /user/lib/diaspora/public folder. Consequently I receive a ‘you do not have permission to access this page’ error. Is there a default page located in another folder? Where is the default page located? I can create an index.html page in the public folder and it is viewable on the web.

Once this issue is resolved I hope to make my pod publicly viewable.

2

Diaspora is a Ruby on Rails app, as such it needs to run a so called application server which any requests for non-static files, including the index request, should be reverse proxied to.

The diaspora installer package is not an officially supported installation method and thus I have no clue what or how it sets things up.

3

Is there an official set up document for Ubuntu 20.04 That I can follow to set up a live pod? All the documents I have seen are at least two years old.

4

The official guide for Ubuntu 16.04 should still work, as far as I know nothing changed: https://wiki.diasporafoundation.org/Installation/Ubuntu/Xenial

(if it doesn’t, let us know and we can help you and updated the guide if needed)

5

If it does still let us know so we can copy paste it for 20.04 :smiley:

6

A better approach would be to look at the diaspora-iinstaller and diaspora-installer-MySQL packages in Ubuntu 20.04 to see what might be missing or done incorrectly by those packages. If the process can be automated, you would do the entire diaspora* communities a huge favor and make it possible for non-techie users to join the community.

I will attempt to use the very old process from Xenial To do my installation but an automated process would greatly enlarge the potential user base.

7

If it were that easy, we absolutely would have done that. We had very intense discussions when the people who build and “maintain” that script started because they wanted to have their installer adopted by us as an officially supported method. We had a look, we did some tests, and a lot of discussions and decided that there is no way that we can adopt this, and do be quite frank, you showing up here with no idea of what the installer did and how diaspora* even works (leading to “let’s try something out” debugging sessions that usually end up in people breaking their setup even more) is a perfect example of why we were probably right with this decision. Here are just some points:

  • These packages are incredibly slow to update because distributions generally don’t care about receiving updates, raising bogus arguments about “stability”. The diaspora-installer package for Ubuntu Focal installs a 0.7.6.0. This is a version from June 27, 2018. We are now at 0.7.14.0, and one version in between, namely 0.7.7.1 was a security hotfix that fixed an XSS issue with specially graphed OpenGraph metadata on the mobile interface. Is this package updated anywhere? Obviously not. Is it easy for us to update the package? Also not, because in the world of linux package maintenance, rolling out updates takes weeks. This is unacceptable for us.
  • The installer just assumes that your setup is whatever the package maintainer expects it to be. If it’s not, then something goes wrong without even telling you. It asks you some questions for configurations the installer deems important, while completely ignoring others. It uses a mechanism to set settings via environmental variables, instead of setting them in diaspora.yml. All our guides, and all our support help, depends on diaspora.yml having the correct value - which just isn’t the case for this script. Instead, settings are placed in a separate config file, where everything is left uncommented. This has lead to people changing things like the pod URL without knowing what they do. In our diaspora.yml, all settings are documented. For the URL, for example, there is a very explicit comment telling you that you absolutely cannot change the URL after setup.
  • diaspora* requires manual actions by a podmin on major version upgrades. The installer package just runs the usual update procedure, regardless of the version in use. Also, podmins who use this package have a setup that does not match what we expect, so our upgrade guides would most likely fail them (stuff like configs not being where they should, configs not even being loaded because the installer package decides to use a dedicated config vile and environmental variables, …)
  • The installer package depends on other packages provided by the distribution. For Ubuntu Focal, for example, the package installs bundler 2.1.4, while our current setup expects a 1.x version. Also, the Ubuntu package installs Ruby 2.7, while the recommended version is 2.6. We know that diaspora* works in 2.7, but it spams a lot of warning messages that are outside our control, and these walls of warnings result in the important messages being lost. Other packages even change the version of libraries we depend on, and they randomly update Rubygems to versions we have not tested diaspora* with, and sometimes this results in people’s setups randomly exploding. The debian package no longer did this, because they realized that this, to everyone’s surprise, randomly explodes, but others do.

There are a lot more reasons, but I’m going to stop here. It’s not a random coincidence that 90% of all the podmin support requests we recevie are from people using some kind of automated installer, either a package like the diaspora-installer deb, or something like Bitnamo. We tried our best to communicate our concerns and issues to those people, and they’ve been continuously ignored or downplayed because “that’s not an issue”, and yet, here we are, with tons of people on those broken setups. We pretty much never receive complaints about setup issues from people following our installation guide - with the rare occurrence of something changing in distribution upgrades, where we can quickly address that ourselves without involving external people.

As much as I’d love there to be an easy one-click-way to install diaspora*, that’s unlikely to happen anytime soon and that’s for a good reason. We want people to end up with a setup they can reliably use and maintain, not something that works for a bit and then randomly breaks with nobody being able to fix things.

If you want to improve the diaspora-installer package, then sure, go ahead. Please get in touch with the maintainers. IIRC, they’re using the Debian forum for discussions, so you might get help here. But as Jonne said, we looked into the package, we tried to support them, but we quickly realized that this is not really a possibility for us.

2 Likes
8

Dennis,

Thank you for your response to my comment. I can certainly understand your frustration with the maintainers of the Debian/Ubuntu packages and their arbitrary decisions on the versions they used. Having been a Linux user since version 0.9 when, by the way, it came on six 360k floppies, and having watched its growth over the years into multiple distributions, I know that the diversity of the Linux landscape makes it very difficult to make an application that easily fits all distributions. Plus you have to deal with Apple which uses a BSD base. It would be nice, however, up to date instructions on how to do a diaspora* installation

As I told Jonne, I will attempt to perform a manual installation of diaspora* on my server using the Ubuntu Xenial instructions. I did notice when I ran the installer that there were numerous nonfatal errors during the Ruby portion of the installation most of which mentioned that certain syntax was deprecated. This likely is due to using the 2.7 version rather than 2.6. I will note any issues I encounter on Ubuntu 20.04 so that I can report them to you as I follow the Xenial instructions.

Hopefully I will be able to get a working diaspora* server up and running.

9

Absolutely! We have a couple of podmins running on 20.x, so I assume it works. If the Xenial instructions do not work for you, please open a new thread - and we’ll figure out why it doesn’t work and get that resolved. If it works without issues, please also ping back, so we can create a new site for 20.x using the same instructions. :slight_smile:

10

Receive the following error running script/configure_bundler:

Traceback (most recent call last):
9: from script/configure_bundler:7:in <main>' 8: from /home/diaspora/diaspora/config/bundler_helper.rb:8:in rails_env’
7: from /home/diaspora/diaspora/config/bundler_helper.rb:22:in parse_value_from_file' 6: from /home/diaspora/.rvm/rubies/ruby-2.6.5/lib/ruby/2.6.0/psych.rb:577:in load_file’
5: from /home/diaspora/.rvm/rubies/ruby-2.6.5/lib/ruby/2.6.0/psych.rb:577:in open' 4: from /home/diaspora/.rvm/rubies/ruby-2.6.5/lib/ruby/2.6.0/psych.rb:578:in block in load_file’
3: from /home/diaspora/.rvm/rubies/ruby-2.6.5/lib/ruby/2.6.0/psych.rb:277:in load' 2: from /home/diaspora/.rvm/rubies/ruby-2.6.5/lib/ruby/2.6.0/psych.rb:390:in parse’
1: from /home/diaspora/.rvm/rubies/ruby-2.6.5/lib/ruby/2.6.0/psych.rb:456:in parse_stream' /home/diaspora/.rvm/rubies/ruby-2.6.5/lib/ruby/2.6.0/psych.rb:456:in parse’: (/home/diaspora/diaspora/config/diaspora.yml): did not find expected key while parsing a block mapping at line 80 column 7 (Psych::SyntaxError)

11

When you edited your diaspora.yml you created a syntax error somewhere, probably somewhere around line 80.

YAML is sensitive for indentation, so if you uncomment something, make sure it’s not at the start of the line, it should still be at the same level (just remove the #).

You can upload your config to a pastebin and we can have a look at it, if you don’t find the syntax error yourself (just make sure to remove secrets if there are any).

12

I redid the diaspora.yml file from diaspora.yml.example. I’m continuing to get the same error as follows:

diaspora@XLHou064004:~/diaspora$ script/configure_bundler
Traceback (most recent call last):
9: from script/configure_bundler:7:in `<main>'
8: from /home/diaspora/diaspora/config/bundler_helper.rb:8:in `rails_env'
7: from /home/diaspora/diaspora/config/bundler_helper.rb:22:in `parse_value_from_file'
6: from /home/diaspora/.rvm/rubies/ruby-2.6.5/lib/ruby/2.6.0/psych.rb:577:in `load_file'
5: from /home/diaspora/.rvm/rubies/ruby-2.6.5/lib/ruby/2.6.0/psych.rb:577:in `open'
4: from /home/diaspora/.rvm/rubies/ruby-2.6.5/lib/ruby/2.6.0/psych.rb:578:in `block in load_file'
3: from /home/diaspora/.rvm/rubies/ruby-2.6.5/lib/ruby/2.6.0/psych.rb:277:in `load'
2: from /home/diaspora/.rvm/rubies/ruby-2.6.5/lib/ruby/2.6.0/psych.rb:390:in `parse'
1: from /home/diaspora/.rvm/rubies/ruby-2.6.5/lib/ruby/2.6.0/psych.rb:456:in `parse_stream'
/home/diaspora/.rvm/rubies/ruby-2.6.5/lib/ruby/2.6.0/psych.rb:456:in `parse': (/home/diaspora/diaspora/config/diaspora.yml): did not find expected key while parsing a block mapping at line 80 column 7 (Psych::SyntaxError)

Line 80 is the final line in the sidekiq section below:

## Sidekiq - background processing
    sidekiq: ## Section

      ## Number of parallel threads Sidekiq uses (default=5).
      ## If you touch this, please set the pool setting in your database.yml
      ## to a value that's at minimum close to this! You can safely increase
      ## it to 25 and more on a medium-sized pod. This applies per started
      ## Sidekiq worker, so if you set it to 25 and start two workers, you'll
      ## process up to 50 jobs in parallel.
      concurrency: 5

The spacing to the word concurrency is exactly 6 spaces with no tabs.

Any suggestions? Where can I download a fresh copy of diaspora.yml.example?

13

Just run git checkout config/diaspora.yml.example to reset any changes.

Is the above an exact copy paste? It’s hard to tell since I needed to edit in the code fences for you. But if it is, the indentation of the comment in the first line of the paste would be wrong.

It would help if you could upload the file as is somewhere, just replacing any secrets as Benjamin noted.

14

I was able to get the script/configure_bundler command to run by commenting out the setting on line 80 in the diaspora.yml file … concurrency: 5.

So my question is: If I only change the items in the diaspora.yml file that directly apply to my installation (in other words … things like the name of my installation, email address and enabling different sections to which I do not want to accept the default settings), will all the other default settings be applied to my installation? Or do I need to explicitly set various settings to the default?

Another way of asking my question is … Are default settings automatically applied if left unchanged?

I hope my question is clear.

15

Yup, that’s exactly how it’s meant to be, as explained in the header of the file.

The diaspora.yml.example shows you all available configurations and their default values, and if you’re fine with that, there’s no reason to change anything.

16

Received the following messages following my running the command … bin/bundle install --full-index

Are these messages fatal to my installation? How should I proceed?

HEADS UP! i18n 1.1 changed fallbacks to exclude default locale.
But that may break your application.

If you are upgrading your Rails application from an older version of Rails:

Please check your Rails app for ‘config.i18n.fallbacks = true’.
If you’re using I18n (>= 1.1.0) and Rails (< 5.2.2), this should be
‘config.i18n.fallbacks = [I18n.default_locale]’.
If not, fallbacks will be broken in your app by I18n 1.1.x.

If you are starting a NEW Rails application, you can ignore this notice.

For more info see:
https://github.com/svenfuchs/i18n/releases/tag/v1.1.0

Post-install message from acts-as-taggable-on:
When upgrading

Re-run the migrations generator

rake acts_as_taggable_on_engine:install:migrations

This will create any new migrations and skip existing ones
Version 3.5.0 has a migration for mysql adapter
Post-install message from encryptor:

Please be aware that Encryptor v2.0.0 had a major security bug when using AES-*-GCM algorithms.

By default You will not be able to decrypt data that was previously encrypted using an AES-*-GCM algorithm.

Please see the README and https://github.com/attr-encrypted/encryptor/pull/22 for more information.

Post-install message from attr_encrypted:

WARNING: Several insecure default options and features were deprecated in attr_encrypted v2.0.0.

Additionally, there was a bug in Encryptor v2.0.0 that insecurely encrypted data when using an AES-*-GCM algorithm.

This bug was fixed but introduced breaking changes between v2.x and v3.x.

Please see the README for more information regarding upgrading to attr_encrypted v3.0.0.

Post-install message from compass:
Compass is charityware. If you love it, please donate on our behalf at http://umdf.org/compass Thanks!
Post-install message from handlebars_assets:
Remember to rake assets:clean or rake assets:purge on update! this is required because of handlebars updates
Post-install message from rails-assets-autosize:
This component doesn’t define main assets in bower.json.
Please open new pull request in component’s repository:
https://github.com/jackmoore/autosize
Post-install message from rails-assets-blueimp-gallery:
This component doesn’t define main assets in bower.json.
Please open new pull request in component’s repository:
https://github.com/blueimp/Gallery
Post-install message from rails-assets-jquery.ui:
This component doesn’t define main assets in bower.json.
Please open new pull request in component’s repository:
https://github.com/jquery/jquery-ui
Post-install message from rails-assets-utatti-perfect-scrollbar:
This component doesn’t define main assets in bower.json.
Please open new pull request in component’s repository:
https://github.com/utatti/perfect-scrollbar

17

All perfectly fine to ignore, it worked!

18

Completed the installation per the instructions. These are the diaspora processes running inside a Screen terminal:

diaspora 178785 2529 0 Jul08 ? 00:00:00 SCREEN
diaspora 178786 178785 0 Jul08 pts/3 00:00:00 /bin/bash
diaspora 179006 178786 0 Jul08 pts/3 00:00:50 eye monitoring v0.10.0 [diaspora] (in /home/diaspora)
diaspora 179177 179006 0 Jul08 pts/3 00:02:27 sidekiq 5.2.8 diaspora [0 o
diaspora 179182 2529 0 Jul08 ? 00:00:10 unicorn master -c config/unicorn.rb -D
diaspora 179212 179182 0 Jul08 ? 00:00:00 unicorn worker[0] -c config/unicorn.rb -D
diaspora 179214 179182 0 Jul08 ? 00:00:00 unicorn worker[1] -c config/unicorn.rb -D
postfix 179437 2183 0 Jul08 ? 00:00:00 qmgr -l -t unix -u

When I go to the URL for my installation (https://diaspora.xlhou.com), I this error:

Service Unavailable

The service is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again

19

This can have a number of reasons. Check your apache error logs, it’s probably misconfigured. Make sure it can open and read from the unix socket permission wise.

20

Checked my logs and discovered a bad path to the unix socket in the sites available configuration file for this web site. I corrected that path and restarted apache2. This gave me an initial start page for diaspora*. So I restarted the server in the hope that reloading all the configuration files would give me a startup page that was formatted according to the proper stylesheet for that page. Since that time after running the ./script/server command in a Screen session gives me continuous errors like the following:

W, [2020-07-10T15:57:09.162380 #4636] WARN – : [diaspora:web] check crashed: process is down
I, [2020-07-10T15:57:09.162447 #4636] INFO – : [diaspora:web] schedule :restore (crashed)
I, [2020-07-10T15:57:09.162508 #4636] INFO – : [diaspora:web] <= check_crash
I, [2020-07-10T15:57:09.162563 #4636] INFO – : [diaspora:web] => restore (crashed)
I, [2020-07-10T15:57:09.162699 #4636] INFO – : [diaspora:web] load_external_pid_file: pid_file found, but process <6220> not found
I, [2020-07-10T15:57:09.163016 #4636] INFO – : [diaspora:web] switch :starting [:down => :starting] crashed
I, [2020-07-10T15:57:09.163279 #4636] INFO – : [diaspora:web] executing: bin/bundle exec unicorn -c config/unicorn.rb -D with start_timeout: 15.0s, start_grace: 2.5s, env: ‘RAILS_ENV=production PORT=’ (in /home/diaspora/diaspora)
I, [2020-07-10T15:57:23.729723 #4636] INFO – : [diaspora:web] sleeping for :start_grace 2.5
I, [2020-07-10T15:57:26.230316 #4636] INFO – : [diaspora:web] load_external_pid_file: pid_file found, but process <6234> not found
E, [2020-07-10T15:57:26.230468 #4636] ERROR – : [diaspora:web] exit status 1, process <6234> (from /home/diaspora/diaspora/tmp/pids/web.pid) was not found; ensure that the pid_file is being updated correctly (you should check the process logs ["/home/diaspora/diaspora/log/eye_processes_stdout.log", “/home/diaspora/diaspora/log/eye_processes_stderr.log”])
E, [2020-07-10T15:57:26.230540 #4636] ERROR – : [diaspora:web] process <> failed to start (:not_really_running)
I, [2020-07-10T15:57:26.230960 #4636] INFO – : [diaspora:web] switch :crashed [:starting => :down] crashed
I, [2020-07-10T15:57:26.231538 #4636] INFO – : [diaspora:web] schedule :check_crash (crashed)
I, [2020-07-10T15:57:26.231626 #4636] INFO – : [diaspora:web] <= restore
I, [2020-07-10T15:57:26.231701 #4636] INFO – : [diaspora:web] => check_crash (crashed)
W, [2020-07-10T15:57:26.231795 #4636] WARN – : [diaspora:web] check crashed: process is down
I, [2020-07-10T15:57:26.231893 #4636] INFO – : [diaspora:web] schedule :restore (crashed)
I, [2020-07-10T15:57:26.231977 #4636] INFO – : [diaspora:web] <= check_crash
I, [2020-07-10T15:57:26.232071 #4636] INFO – : [diaspora:web] => restore (crashed)
I, [2020-07-10T15:57:26.232259 #4636] INFO – : [diaspora:web] load_external_pid_file: pid_file found, but process <6234> not found

I’ve checked the pid files in ~/diaspora/tmp/pids, but their contents are always different than what the error messages reveal/expect. Are there pid files in another location that I should check? Do you have any ideas on how to resolve this issue?

The installation tutorial gave me the command to start up diaspora. What is the proper way to gracefully shutdown diaspora?