Howto install Diaspora pod on NethServer

I think it was a copy/paste action of an already working postgres db creation.
I’ll have a look and change it if needed.

I’ve been looking into this a bit because I was quite confused. Then I found this: http://www.polylab.dk/utf8-vs-unicode.html
Turns out UTF8 is using unicode 8bit: https://www.postgresql.org/docs/9.1/static/multibyte.html (find UTF8 in the table)
I have too little knowledge on this subject but what I understand is that having the database as UTF8 should be ok since it is using unicode…
anyone can comment on this? @davidep @giacomo

I updated the howto to use unicode now instead of utf-8 and create the database with bin/rake db:create.

I don’t remember exactly why I used UTF8 but I think I got this error:

ERROR:  new encoding (UTF8) is incompatible with the encoding of the template database (SQL_ASCII)
HINT:  Use the same encoding as in the template database, or use template0 as template.

and solved it with using utf8 and manual db creation but it would have been enough to just use template: template0.

I am sorry for that, I am afraid the database needs to be converted.

Docs about postgres templates:

https://www.postgresql.org/docs/9/static/manage-ag-templatedbs.html

2 Likes

Shouldn’t this part be deleted then?

nm… you got that error by using the rake command?

1 Like

Done. Thanks.

Yes.

1 Like

When I look at the howto on d* wiki on setting up the db I see another part in the setup of the db:

RAILS_ENV=production bundle exec rake db:create db:migrate

I don’t know what the bundle exec part does and how essential this is for setting up the db. Maybe it must be added?

/edit: info on bundle exec command: https://bundler.io/man/bundle-exec.1.html
/edit2: this is quite specific ruby stuff…

1 Like

Thanks, I edited it to

RAILS_ENV=production bundle exec rake db:create db:migrate

It may have been a copy/paste error.

Just chiming in here to help you out on your guide.

bin/rake and bundle exec rake are interchangeable here.

Please be careful with this. You’re editing YAML files using a tool that’s not aware of the YAML structure [0]. If we move password from line 6 for whatever reason, your script fails. If we change our example domain, your script fails. Similar goes for the other sed lines. Also, sed is not exactly known for its usability. My suggestion, if I may, is to find a different, less obfuscating tool to do this job.

If you run into errors like the one with the database creation you mentioned earlier, please do not invent custom solutions but drop by at diaspora*'s Discourse as it might be an error affecting other users as well. In addition, you avoid adding errors to your guide that way.

I took the liberty to investigate the impact of the error of specifying utf8 instead of unicode as character set setting, and we got lucky. As per current PostgreSQL documentation, in this case they have been aliases for each other at least since PostgreSQL 9.6 [1]. This means installations are not broken, contrary to what I was afraid of earlier.

On a long-term note: Please make sure to support users of your guide properly. We’ve had situations in the past where projects would create guides for their platforms, but turned their users to the diaspora* support channels if problems arised, on the grounds that they “did not know how diaspora* works”. We do not know your platform and often cannot help properly in such a case. As you provide this guide, I encourage you to know diaspora* well enough to be able to support users of your guide, or they may end up without any support, and we’d like to avoid that :slight_smile:

[0] It is not possible to correctly parse context sensitive grammer with regular expressions.
[1] Note that them being aliases is not the case for all database systems; for example MySQL has a quite unique character set utf8 which is not compliant to standards and has given us a fair share of trouble.

1 Like

Thanks for clarifying, I really appreciate it.

This howto was intended to provide a quick setup of diaspora on Nethserver to test it.
I already added a link to diaspora documentation.

2 Likes

I am sorry, didn’t see that update.

When skipping through the revisions, I noticed changing # Create DB to # Create DB User might avoid confusion for other readers :slight_smile:

2 Likes

That’s really confusing. Thanks. I changed it.

1 Like

By the way, I really appreciate that.

2 Likes

Diaspora is really a nice software and we like to test it for the education part of Nethserver. We also like to explore the addons like chat and see if we can integrate Diaspora to Nethserver, maybe as a module.
But first we have to get into it and learn how to correctly setup and use it, as you mentioned.

1 Like

Today I did a (minor) update on the diaspora software on my server. Installed version was 0.7.6.0, new version is 0.7.7.1
The instructions on diaspora wiki are almost complete.
https://wiki.diasporafoundation.org/Updating
The extra info that you need to perform the update:

  • stop diaspora: systemctl stop diaspora.target
  • change to diaspora user: su diaspora
  • change to the directory where diaspora is installed: cd /home/diaspora/diaspora

Then follow the directions of the wikipage
Afterwards restart diaspora: systemctl enable diaspora.target diaspora-sidekiq.service diaspora-web.service --now

2 Likes

Trying to follow this guide, I’m having trouble at the step of rvm install 2.4. It apparently wants to run yum install -y ruby internally, which of course requires root permissions. Since the diaspora user doesn’t have those permissions, it tries to run that command using sudo, which requires diaspora's password. Two problems: (1) the diaspora user doesn’t have a password (since we haven’t set it), and (2) that user doesn’t have sudo permissions anyway.

Solution was to run yum install ruby in a separate shell as root.

Next issue: after git clone and changing into the diaspora directory, I get:

[diaspora@neth-test ~]$ cd diaspora/
Required ruby-2.6.5 is not installed.
To install do: 'rvm install "ruby-2.6.5"'

Running the suggested command succeeded.

  • There is no config/database.yml until you create it with a copy of config/database.yml.example
  • Same for config/diaspora.yml.

Going through the rest of the guide gets me this when browsing to my instance:

Further investigation reveals that whatever should be listening on port 3000, isn’t:

[root@neth-test httpd]# tail error_log
[Thu Sep 10 13:41:30.977142 2020] [lbmethod_heartbeat:notice] [pid 16707] AH02282: No slotmem from mod_heartmonitor
[Thu Sep 10 13:41:30.980148 2020] [ssl:warn] [pid 16707] AH02292: Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)
[Thu Sep 10 13:41:31.000400 2020] [mpm_prefork:notice] [pid 16707] AH00163: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.4.16 configured -- resuming normal operations
[Thu Sep 10 13:41:31.000418 2020] [core:notice] [pid 16707] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
[Thu Sep 10 14:51:28.561813 2020] [proxy:error] [pid 12460] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:3000 (localhost) failed
[Thu Sep 10 14:51:28.561975 2020] [proxy:error] [pid 12460] AH00959: ap_proxy_connect_backend disabling worker for (localhost) for 60s
[Thu Sep 10 14:51:28.562871 2020] [proxy_http:error] [pid 12460] [client 192.168.1.226:53726] AH01114: HTTP: failed to make connection to backend: localhost
[Thu Sep 10 16:50:39.980984 2020] [proxy:error] [pid 12463] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:3000 (localhost) failed
[Thu Sep 10 16:50:39.981147 2020] [proxy:error] [pid 12463] AH00959: ap_proxy_connect_backend disabling worker for (localhost) for 60s
[Thu Sep 10 16:50:39.981206 2020] [proxy_http:error] [pid 12463] [client 192.168.1.226:58765] AH01114: HTTP: failed to make connection to backend: localhost

But all the systemd units seem to be active:

[root@neth-test httpd]# systemctl status diaspora.target
● diaspora.target - Diaspora social network
   Loaded: loaded (/etc/systemd/system/diaspora.target; enabled; vendor preset: disabled)
   Active: active since Thu 2020-09-10 14:26:34 EDT; 2h 25min ago

Sep 10 14:26:34 neth-test.familybrown.org systemd[1]: Reached target Diaspora social network.
[root@neth-test httpd]# systemctl status diaspora-sidekiq
● diaspora-sidekiq.service - Diaspora social network (sidekiq)
   Loaded: loaded (/etc/systemd/system/diaspora-sidekiq.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2020-09-10 16:53:50 EDT; 12s ago
 Main PID: 12489 (ruby)
   CGroup: /system.slice/diaspora-sidekiq.service
           └─12489 /home/diaspora/diaspora/vendor/bundle/ruby/2.6.0/bin/sidekiq

Sep 10 16:53:50 neth-test.familybrown.org systemd[1]: Started Diaspora social network (sidekiq).
Sep 10 16:53:59 neth-test.familybrown.org bash[12489]: Rack::SSL is enabled
[root@neth-test httpd]# systemctl status diaspora-web
● diaspora-web.service - Diaspora social network (unicorn)
   Loaded: loaded (/etc/systemd/system/diaspora-web.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2020-09-10 16:53:57 EDT; 9s ago
 Main PID: 12681 (ruby)
   CGroup: /system.slice/diaspora-web.service
           └─12681 /home/diaspora/diaspora/vendor/bundle/ruby/2.6.0/bin/unicorn -c config/unicorn.rb -E production

Sep 10 16:53:57 neth-test.familybrown.org systemd[1]: Started Diaspora social network (unicorn).
Sep 10 16:53:59 neth-test.familybrown.org bash[12681]: I, [2020-09-10T16:53:59.179441 #12681]  INFO -- : Refreshing Gem list
Sep 10 16:54:06 neth-test.familybrown.org bash[12681]: Rack::SSL is enabled

But trying to connect directly to port 3000 gives the same result:

[diaspora@neth-test config]$ curl http://localhost:3000
curl: (7) Failed connect to localhost:3000; Connection refused
2 Likes

In my case the database was not installed with

RAILS_ENV=production bundle exec rake db:create db:migrate

because the credentials in config/database.yml were not set correctly (postgres/SECRET instead of diaspora/SECRET).

After the db was created and another run of

RAILS_ENV=production bin/rake assets:precompile

I just needed to enable/start the services to make Diaspora work:

systemctl enable diaspora.target #diaspora-sidekiq.service diaspora-web.service --now

Next to the points you provided, I think there are some problems with the sed lines, I’m going to rewrite the howto…

2 Likes

That was my problem (and that I’d left out the template line)–oops. I’d done the edits by hand, largely out of the concern mentioned up-thread that locations or variables might change, so it’s entirely possible that if I’d used sed after making the copies, it would have worked fine.

2 Likes

I now see what happened with the config files–those commands are in the OP, but the code block is shortened so that I didn’t see them without scrolling. The last line I saw was “# Edit configuration files”, followed by the message to “Replace SECRET…”

A few other clean-up things:

  • ruby needs to be added to the initial yum install command.
  • The path to policy.xml is (now) incorrect; it’s now /etc/ImageMagick-6/policy.xml.
  • Unless I’m misunderstanding the messages I’m seeing, the rvm command should now be rvm install 2.6.
  • It doesn’t appear necessary any more to specify bundler v. 1.16.2.
1 Like

It seems this conflicts with ntopng; both listen on port 3000 (such that browsing to the FQDN I’ve assigned to Diaspora brings up my ntopng instance without authentication). Would there be any concern with having Diaspora listen on a different port like 3001? Or on a Unix socket (which seems preferred, as it would avoid the problem entirely)?

I don’t think so, it shouldn’t matter which port as long as the reverse proxy points to the right one.

1 Like