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
Shouldn’t this part be deleted then?
nm… you got that error by using the rake command?
Done. Thanks.
Yes.
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…
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
[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.
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.
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
That’s really confusing. Thanks. I changed it.
By the way, I really appreciate that.
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.
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
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 ofconfig/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
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…
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.
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 initialyum 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 bervm install 2.6
. - It doesn’t appear necessary any more to specify bundler v. 1.16.2.
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.