Hi, I can’t remember the exact answer off-hand, but while you’re waiting for one of the experts to reply, I can say that this has been asked and answered a few times over the past few months. So if you want, you could look back through recent podmin support requests and you’ll hopefully find the answer. (It’s something to do with having created a user, I think.)
You need to run this command as root or as user with sudo permission. The diaspora user you created usually doesn’t have permissions to run commands as postgres user.
Thanks Benjamin, we have sorted that out. When you say “diaspora user” do you mean the account name where diaspora will hosted, or must there literally be a user named "diaspora?
Bundle complete! 142 Gemfile dependencies, 234 gems now installed.
Gems in the groups test and development were not installed.
Bundled gems are installed into ./vendor/bundle
Post-install message from i18n:
but on database setup we get:
[vbco@162-241-125-3 diaspora]$ RAILS_ENV=production bundle exec rake db:create db:migrate
Rack::SSL is enabled
FATAL: Ident authentication failed for user "postgres"
Couldn't create 'diaspora_production' database. Please check your configuration.
rake aborted!
PG::ConnectionBad: FATAL: Ident authentication failed for user "postgres"
/home/vbco/diaspora/vendor/bundle/ruby/2.6.0/gems/pg-1.2.3/lib/pg.rb:58:in `initialize'
/home/vbco/diaspora/vendor/bundle/ruby/2.6.0/gems/pg-1.2.3/lib/pg.rb:58:in `new'
/home/vbco/diaspora/vendor/bundle/ruby/2.6.0/gems/pg-1.2.3/lib/pg.rb:58:in `connect'
/home/vbco/diaspora/vendor/bundle/ruby/2.6.0/gems/activerecord-5.2.4.3/lib/active_record/connection_adapters/postgresql_adapter.rb:692:in `connect'
/home/vbco/diaspora/vendor/bundle/ruby/2.6.0/gems/activerecord-5.2.4.3/lib/active_record/connection_adapters/postgresql_adapter.rb:223:in `initialize'
/home/vbco/diaspora/vendor/bundle/ruby/2.6.0/gems/activerecord-5.2.4.3/lib/active_record/connection_adapters/postgresql_adapter.rb:48:in `new'
Ok, got the server started, now need to do the reverse proxy.
This is a trial install on v-b.co.za. I was wondering when we setup the proper one, is it possible to get someone to do it for us?
Will also want to look at adding Afrikaans language?
Stupid question, where do I put the edited diaspora.conf file? The instructions do not say?
Also, in cPanel servers, the default document root of a website will be set to /home/username/public_html. Hence what contents do we put in the document root to access the site contents via browser?
Wherever your webserver is configured to reads its configuration. The configuration examples for Nginx and Apache suggest to set the document root accordingly, I can not recommend to copy assets around over just setting the document root to where they are, it would break for picture uploads.
Thanks Jonne, I did initially put it in the document root, but a .conf file is nor readable by a web browser except as text. Should I put it as a .htaccess file?
I will see if I can change the document root in the meantime
It’s the configuration, it defines the document root. Nowhere I said to put the configuration itself into the document root, that doesn’t make any sense whatsoever.
So if the server is already running, to connect with other nodes, what address is it using?
I have asked the hosting people about the root.
This is a trial setup to check this kind of thing and determine if it will be suitable, so not the end of the world.
Just surprised it is not covered in the setup. I did go through each step.
The guide intentionally only covers setting up diaspora, configuring a whole server is beyond its scope.
diaspora* works much by email, the initial connections have to be made explicitly by the user, searching for diaspora* IDs which just look like email addresses too, so they encode the host. The federation protocol sits on top of HTTPS, so just uses the same address as you put under url in the diaspora configuration.
I was wondering, if we went on the cloud, how complicated is it to move from cloud to local in the future, for instance ones the 12 months free on AWS runs out? Our community would like to keep control and ownership of data.
The “cloud” is a fancy term for a platform that offers many hosted services, with usually at its core just yet another VPS hosting service. As long as you use “the cloud” just as that, a VPS hosting service, I cannot see any vendor lock-in.
