FAQ for pod maintainers: Difference between revisions

From diaspora* project wiki
No edit summary
m (Fix typos, thanks Besnik_b :))
 
(114 intermediate revisions by 32 users not shown)
Line 1: Line 1:
We've started adding questions that we see a lot to this page, but it doesn't cover everything.
We've started adding questions that we're frequently asked to this page, but it doesn't cover everything.
If you have other questions, the best way to get an answer quickly is to visit us in IRC.  
If you have other questions, the best way to get an answer quickly is to visit us in our [[How we communicate#IRC|IRC channel]].
You might think, "IRC? For real? Is this 1994 again?"


Yes. I mean, '''no'''! Just think of IRC as the open-source equivalent of a Campfire room. **Links
== Installation Information ==
to IRC channels and mailing lists are at the bottom of this page.**


== Installation ==
=== What are the general system requirements? ===


'''Do you have a detailed install guide?'''
Running diaspora* requires resources depending on how many users use the installation and how much traffic the installation receives from other pods. Generally it is recommended that at least 1 Gig of memory should be available for even small instances.
 
For pods with more users the amount of memory available to diaspora* and the background jobs it needs is higher depending on the amount of users actively using the instance. As the database grows, more memory will be needed to compensate.
 
Since diaspora* requires quite a lot of different components to be installed, generally shared hosting servers are not sufficient. Any VPS or dedicated server with a suitable amount of memory will suffice.
 
=== Do you have a detailed installation guide? ===
   
   
Yes. [[Installing and Running Diaspora|Check it out!]] It will probably be more up-to-date than
Yes. [[Installation|Check it out!]] It will probably be more up-to-date than this page, in general.
this page, in general. Also, feel free to look at the [https://github.com/diaspora/diaspora/wiki/Installation-Guides collected guides] page for OS-specific/service-specific help.


'''What ports does Diaspora need open for communication?'''
=== What ports does diaspora* need open for communication? ===
 
Since we recommend running on HTTPS you should only need to open the standard port for it: 443. You should have a reverse proxy listening there that forwards the requests to the application server that diaspora* starts, on port 3000 by default. You can use your existing Nginx or Apache to do that. While we don't recommend it, you can run on plain HTTP with its standard port 80 too. Just never let diaspora* listen on these ports directly. You don't need to open the application server port, 3000, it's for internal communication only.
 
=== Can I use Apache to run diaspora*? ===
    
    
Your webserver must be on port 443 for HTTPS. You must forward that port to 3000 or configure Apache or Nginx to do reverse-proxying. Otherwise friend requests may cause lockups on other servers. See the command-line switches below.
Yes: diaspora* is a standard Rails application, so you can run it with [https://www.phusionpassenger.com/ Passenger], or doing the more common setup which is to use a reverse proxy configuration. Check [https://gist.github.com/719014 this example] on how to configure that setup.


'''Can I use Apache to run Diaspora?'''
=== Do I need a commercial SSL certificate? / Can I use CAcert certificates? ===
 
 
Yes, but that's quite uncommon and thus you might not have as many people being able to support you in case of need. See [[Installing on Ubuntu Apache]] or the [http://blog.fejes.ca/?p=41 Unofficial Diaspora with Apache2] guide.
If you plan on running your pod over HTTPS (yes, [http://stackoverflow.com/a/4495612/1489738 you should]!) then yes you will need a valid commercial [https://aboutssl.org/what-is-ssl-certificate/ SSL certificate]. By design, federation will not work with pods that have self-signed or invalid SSL certs installed. We do this to ensure that all users in the network are able to use diaspora* without suffering from constant security warnings related to 'invalid' certs.
 
For more information see [https://discourse.diasporafoundation.org/t/do-we-need-valid-ssl-certificates/110 this] and [https://discourse.diasporafoundation.org/t/make-cacert-a-valid-certificate-authority-now/230 this] discussion.
 
There '''are''' free commercial certificates around - check [https://letsencrypt.org/ Let's Encrypt] for example ([https://acme.sh/ acme.sh] makes the process a bit more simple).
 
=== How can I run multiple load-balanced instances of diaspora*? ===
 
Multiple diaspora* instances for the same "pod" must share SQL and Redis databases, and ''public/uploads'' directories. There are many possible ways to accomplish this, but perhaps the most classical scenario would be to configure all the nodes to point at a central database server for MySQL/Postgres and Redis, and share the uploads directory from a file server via NFS. To avoid problems with schema changes, it would be desirable to keep all of the instances running the same version of diaspora* at all times.
 
Load-balancing of the instances can be accomplished with any TCP load balancer that supports session stickiness (such as [https://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html Apache] or [http://nginx.org/en/docs/http/load_balancing.html nginx], among others).
 
=== How can I restart diaspora* without any downtime? ===
 
By default, diaspora* uses Unicorn to serve requests. In production mode, it's possible to do a graceful restart of the Unicorn process to avoid downtime. This command, executed in the directory of your diaspora installation, will spawn a new master process, loading any code/configuration changes that you've made:
 
<syntaxhighlight lang="bash">
RAILS_ENV=production bin/eye restart web
</syntaxhighlight>


'''What are the command line options for launching thin (Diaspora's HTTP server)?'''
As the new master spawns workers, old workers finish their requests and are removed from the old master until the last new worker is spawned, at which time the old master is shut down.
 
There are a couple of helpful command line options for setting the address and port for thin:


    bundle exec thin -a <address> -p <port> start
'''Note: this only applies for 0.6.2.0 or newer.'''


Use <code>-D</code> to turn on debug mode.  Run <code>thin -h</code> to see a complete list.
== Troubleshooting ==


'''How do I install on various linux distros or Mac?'''
=== I installed diaspora* on my machine, went to <nowiki>http://localhost:3000</nowiki> and signed up. But my friends can't add me! ===
    
    
See the [https://github.com/diaspora/diaspora/wiki/Installation-Guides Installation Guides] for a list of supported distros/OSs and what to do in each case.
You set "localhost" as your address, but this is not a valid external address. You first need an
There is also an [http://aur.archlinux.org/packages.php?ID=40859 AUR package] for Arch Linux and some guides to install it manually:
externally accessible address - either a domain name or an IP address. Once you have that
[https://bbs.archlinux.org/viewtopic.php?pid=826763#p826763 Unofficial guide for Arch Linux installation 1 (Arch Linux Forums)]<br>
working, you need to clear your database (`$ bundle exec rake db:drop db:create db:migrate`) and re-register, coming in via the external URL. Note that if your externally accessible address changes, you need to start over. diaspora* is designed as a server application to run all day and night.
[http://www.diederickdevries.net/blog/2010/09/16/diaspora-on-arch/ Unofficial guide for Arch Linux installation 2]<br>


'''I'm getting SSL_connect returned=1 errno=0 state=SSLv2/v3 read server hello A: unknown protocol!'''
=== I get 'command not found' if I run bundle install ===
 
Close the port, make it do connection refused, not timeout. 
(Disclaimer: hopefully this doesn't screw up anyone) 
<james_> On Ubuntu: sudo ufw enable, sudo ufw reject 443 (, sudo reboot?)


'''I installed Diaspora on my machine, went to http://localhost:3000 and signed up. But my friends can't add me!'''
Make sure RVM is loaded and the correct Ruby version and gemset are activated. The output of the <tt>rvm info</tt> and <tt>gem env</tt> commands can be helpful in that. Run <tt>gem install bundler</tt> to reassure bundler is actually installed.
 
You signed up with "localhost" which is not a valid external address. You first need an
externally-accessible address - either a domain name or an IP address. Once you have that
working, you need to clear your database (`$ bundle exec rake db:migrate:reset`) and re-register coming in on the outside URL.


'''bundle install >>> command not found ?'''
If you don't use RVM, a common issue is that Debian-based distributions, including Ubuntu, don't add gem executables to the search path. Read up on the <tt>PATH</tt> environment variable on how to solve that.
 
sudo ln -s /var/lib/gems/1.8/bin/bundle /usr/local/bin/bundle
though the best solution is ./ubuntu-setup.bash


'''How do I get past the sign in page to create a new account?'''
=== How do I get past the sign-in page to create a new account? ===
    
    
To create a new account, go to http://yourdiasporainstance.com/users/sign_up  
To create a new account, go to <nowiki>http://yourdiasporainstance.tld/users/sign_up</nowiki>
(replacing *yourdiasporainstance.com* with the the host name of your pod).
(replacing ''yourdiasporainstance.tld'' with the host name of your pod).
 
=== I installed diaspora* on my machine, but when I load the site there are no images and the layout looks horrible! ===
 
You most likely started diaspora* in production mode and accessed the application server directly and not through your reverse proxy. In production mode we expect your reverse proxy to serve the static content since it does the job way better than anything else. If you did access diaspora* through a reverse proxy, make sure it has no configuration issues, has the <tt>public/</tt> directory as document root and is set to look up if requested files are found there before directing the request to the application server.
 
Also make sure you ran <tt>bundle exec rake assets:precompile</tt>.
 
If you need to work around this requirement you can turn <tt>environment.assets.serve</tt> to <tt>true</tt> in <tt>config/diaspora.yml</tt>.


'''I installed Diaspora on my machine, but when I load the site there are no images and the layout looks horrible!'''
=== There are no uploaded images on my pod ===
    
    
If you're missing your images in the production environment, change serve_static_assets in config/environments/production.rb to true and restart Diaspora. Or set up a reverse proxy to serve the files directly under public/.
First make sure other static content is working, as described in the previous section. We embed uploaded images with their full URL, this has to do with the way diaspora* makes sure your images can be seen by users on other pods. A common problem here is that <tt>environment.url</tt> in <tt>config/diaspora.yml</tt>, from which diaspora* constructs the full URL, is set to an incorrect value.


'''There are no images on my pod'''
=== I can't find anybody on another pod / I am receiving posts but nobody is receiving mine ===
    
    
You are most likely in production mode and/or your apache/nginx is not serving static assets.  If you just want to run your server directly from thin on port 3000, you can set ruby to servce static assets by changing `serve_static_assets` to `true` in your `config/application.yml`. Please note, that it is faster if apache/nginx is set up to serve the files from the `public/` directory, since that's what it's build to do - serve files over http.
If you're having problems, make sure to search for people by their full diaspora* ID. Check that your Sidekiq worker is running. Check Sidekiq's retry queue for error messages. Check that the <tt>environement.certificate_authorities</tt> setting is correct.
*When deploying to heroku:* 
Be sure to check that the `serve_static_assets` is set to true in the production block of your `config/application.yml` file.


        production:
=== I can't find myself from another pod / I am not receiving any posts but everybody is receiving mine ===
          <<: *defaults
          serve_static_assets: true


'''Webfinger does not seem to be working'''
Check that your SSL setup is correct, use [http://www.sslshopper.com/ssl-checker.html sslshopper], [https://www.ssllabs.com/ssltest/ ssllabs] or [https://www.htbridge.com/ssl/ High-Tech Bridge] to test your configuration. Make sure it's all green, no yellow, no red.
 
=== I'm getting the warning "... in production without Sidekiq workers" ===
    
    
Is your _resque_ worker running? Can you see the error in resque web? Does your SSL cert check out? (try a [ssl cert checker][ssl-check]).
[http://sidekiq.org/ Sidekiq] is the backend we use for processing background jobs. Normally, Sidekiq is spawned as a separate process, but in this case you have configured diaspora* to run the jobs in the same process as the application. This is normally used for development or testing purposes, but if used in production, it can bring major performance penalties. Thus you should always run Sidekiq in its own process, by setting <tt>environment.single_process_mode</tt> to <tt>false</tt> in your <tt>config/diaspora.yml</tt> and starting the Sidekiq process with
We do not support self signed certs, but you can get a free one [https://www.startssl.com/ from StartSSL].
 
<syntaxhighlight lang="bash">
RAILS_ENV=production bundle exec sidekiq
</syntaxhighlight>
 
In case you are using <tt>script/server</tt> to start diaspora*, then you don't have to manually start the workers! This is already done by the script.
 
=== How can I troubleshoot my email configuration? ===
 
Use the following command to send an email and get the exceptions right on your console:


'''I am receiving posts, but nobody is receiving mine...'''
<syntaxhighlight lang="bash">
 
RAILS_ENV=production bundle exec rails runner 'Notifier.admin("test message", User.where(username: "your_username")).each(&:deliver_now)'  
[Check your ssl certs][ssl-check]!
</syntaxhighlight>
 
Make sure to restart diaspora* once you successfully receive the test message.
 
=== I'm getting a 500 error page ===
 
Oh noes, you might have hit a bug in diaspora*! But this can also be caused by setup issues, like a incorrectly setup custom landing page, an old Redis version or database connectivity issue.
 
# Make sure you found a reliable way to reproduce the issue.
# Run <tt>tail -f log/production.log</tt>. Watch the output closely as you reproduce the issue.
# If you can't make sense out of the actual error message, reach out to us, see [[How we communicate]]. When doing so provide the steps you have taken to produce the error page as well as the full output from the log while reproducing it.
# If told to open an issue, go to https://github.com/diaspora/diaspora/issues. Again make sure to provide the steps to reproduce the problem as well as the log output.


'''I'm getting the warning "... in production without Resque workers"''''
=== I'm getting an error when starting ./script/server ===
 
[https://github.com/defunkt/resque Resque] is the backend we use for processing background jobs. Normally, resque is spawned as a separate process, but in this case you have configured Diaspora to run the jobs in the same process as the application. This is normally used for development or testing purposes, but if used in production, it can bring major performance penalties. Thus you should always run resque in its own process, by setting `single_process_mode` to `false` in your `config/application.yml` and starting the resque process with


    RAILS_ENV=production DB=mysql QUEUE=* bundle exec rake resque:work  # or
If you get <tt>undefined symbol: sigar_skip_token</tt>, you need to run in your diaspora* server directory:
    RAILS_ENV=production DB=postgres QUEUE=* bundle exec rake resque:work


(In case you are using `script/server` to start Diapora, then you don't have to manually start the workers. This is already done by the script.)
<syntaxhighlight lang="bash">
GEM_HOME=vendor/bundle/ruby/2.4.0 gem uninstall sigar
bin/bundle config --local build.sigar "--with-cppflags='-fgnu89-inline'"
</syntaxhighlight>


[ssl-check]: https://www.sslshopper.com/ssl-checker.html
Afterwards, you need to re-run the <tt>bundle install</tt> command from the installation instructions.


=== Upgrading ===
== Upgrading ==


'''Is there anything I should do before upgrading my installation?'''
=== Is there anything I should do before upgrading my installation? ===
    
    
We have a service (Travis) that builds all our code for each ruby version/database combination that we support. Before you update your Diaspora installation, you should check here to see if your combination is green: http://travis-ci.org/diaspora/diaspora  If it's not green, wait to do the update. (Note: Travis is having issues with their SSL cert, so you may get a warning, but it is safe to proceed.)
Yes, read our [[Updating|notes for updating]].
 
=== How do I roll back my installation if an update breaks it? ===
 
First, try to fix your installation; as always our [[How we communicate#IRC|IRC channel]] should be helpful for getting help with this.


'''How do I roll back my installation if an update breaks it?'''
To roll back, just do:  <tt>git checkout ref</tt> Where ''ref'' is the identifier of the commit to go back to. It's a long string of letters and numbers. You can find the ''ref'' by doing a <tt>git log</tt>, eyeballing the commit dates, and figuring out where you were before you pulled. Of course it's best if you keep track of that ''ref'' before you update.
 
 
Just do:  `git checkout [ref]` Where [ref] is the identifier of the commit to go back to. It's a long guid-like string of letters and numbers. You can find the ref by doing a git log, eyeballing the commit dates, and figuring out where you were before you pulled. Of course it's best if you keep track of that ref before you update. :)
You can also checkout a particular version with <tt>git checkout v0.3.0.1</tt>, replacing the version of course.
 
After that just follow the same procedure that you would to update your installation.


'''What if there were database migrations in the code I am rolling back?'''
=== What if there were database migrations in the code I am rolling back? ===
    
    
Then you also need to roll those back separately. You need to do this BEFORE you roll back the code. Look in the db/migrate directory and figure out which files are new since the last time you pulled - i.e., which migration your db should be on. They are in timestamp order in that directory. Then do:
Then you also need to roll those back separately. You need to do this '''before''' you roll back the code. Look in the <tt>db/migrate</tt> directory and figure out which files are new since the last time you pulled - i.e., which migration your database should be on. They are in timestamp order in that directory. Then do:
`rake db:rollback`  And look at the output. It will tell you which migration you are now on. It rolls back one each time you run it. Run it until you're on the right migration and then roll back the code as described above.
<tt>bundle exec rake db:rollback</tt> and look at the output. It will tell you which migration you are now on. It rolls back one each time you run it. Run it until you're on the right migration and then roll back the code as described above.


Also be aware that database rollbacks can fail - they depend on the migration author writing the correct code to roll back. And if they didn't right the correct code to roll forward... :)  So really, the best thing you can do to avoid this is check [http://travis-ci.org/diaspora/diaspora Travis] (as described above) before doing an update.
Also be aware that database rollbacks can fail - they depend on the migration author writing the correct code to roll back. So in this case it's generally much easier to seek help to fix your current setup than to roll it back.


== General ==
== General ==


'''Will a pod eventually receive federated posts that it misses while being offline/down?'''
=== How can I receive project news? (Updates, Security fixes, ...) ===
 
 
Currently no, there are no retries, though we'd like to add that at some point.
There are multiple channels for important news, including:
 
* the official diaspora* project account: hq[at]pod.diaspora.software.
* the official blog at [https://blog.diasporafoundation.org/ blog.diasporafoundation.org], which also offers [https://blog.diasporafoundation.org/feed an Atom feed].
* the [https://discourse.diasporafoundation.org/c/announcements announcements category on Discourse], to which you can subscribe if you have a Discourse account.
 
=== Am I alone here? (Establish connections with other pods) ===
 
Once you set up your pod, you should add some contacts to start receiving content from other pods.
It's a good idea to add some active diaspora* people to your contacts, because they almost all run their own pod,
so your pod will be known by them and you will be easily findable from there.
 
Here is a small list:
 
* Official account of the project: hq[at]pod.diaspora.software
* Sean Tilley: deadsuperhero[at]joindiaspora.com
* Jonne Haß: jhass[at]diaspora.social
* Jason Robinson: jaywink[at]jasonrobinson.me
* The Geraspora team: team[at]pod.geraspora.de
* Waithamai: waithamai[at]pod.geraspora.de
* Fla: fla[at]diaspora-fr.org
 
After you added a few contacts it's a good idea to make a '''public''' post containing the <tt>#newhere</tt> tag, announcing your new pod, to get even more contacts.
 
=== Can I make my pod private/isolated/not communicate with other pods? ===
 
No. diaspora* is built around the idea of a distributed social network. We want to build one network, not enable special interest communities or companies to host their own social network (We do welcome you on diaspora* though!). A large amount of the development effort goes into making that one network possible and the whole user experience is designed around it. This not only means that other existing solutions often have feature-sets way better suited to that usecase, but also that if we did implement a switch to turn off communication with other pods, there would be many broken ends in the user interface, which would lead to a bad user experience.
 
=== Can I modify the code? ===
 
Yes. But keep in mind that diaspora* is licensed under the AGPLv3, that means you must
make the currently running source code available to your users. For legal advice beyond
that, please contact your lawyer.
 
=== Will a pod eventually receive federated posts that it misses while being offline/down? ===


'''What do I do about all these PGErrors, like disconnects and SSL problems?'''
Possibly. We retry the delivery three times at one hour intervals.


If you are running Diaspora with PostgreSQL, beware that having [http://www.postgresql.org/docs/9.1/interactive/runtime-config-connection.html#GUC-SSL the ssl setting] turned on in the PostgreSQL config has been causing problems for several people.  We recommend turning it off unless you know what you're doing.
=== I've got my pod running. How do I disable outside logins? ===


'''I've got my pod running. How do I disable outside logins?'''
Set <tt>settings.enable_registrations</tt> to <tt>false</tt> in your <tt>config/diaspora.yml</tt> and then restart diaspora*.


Change <code>registrations_closed</code> in config/application.yml from false to true, and then
=== How do I back up my pod? ===
restart the server.


'''How do I back up the database?'''
You should do backups of all user data, that is the whole database and uploaded images. For the images just make copies of the <tt>public/uploads</tt> directory. Then just dump all <tt>Diaspora_</tt> databases from your database server. A web search should get you the information you need on how to do that. Make sure to store the backups on a different server, or at least on a different hard drive.
 
From the command line type: 
    mysqldump -u <mysql username> -p diaspora_development > backup.sql
Enter your mysql password when prompted for it.
Replace \_development with \_production if you're running the production environment.


'''What's up with assets/jammit/js-runtime?'''
For more details, see [[Pod data backup]].
 
The recent update to Rails 3.1 made it possible for us to use the included asset compilation mechanism and therefore drop the requirement for jammit and a Java environment. The new method requires a JavaScript runtime like [http://nodejs.org/ Node.js] or [https://github.com/cowboyd/therubyracer TheRubyRacer] to be installed, though. See the [Installation-Guides specific distribution guides] for how to install them. After it has been installed, you can compile the assets by running `bundle exec rake assets:precompile`. See the [Notes-on-Installing-and-Running-Diaspora installation guide] for more detailed instructions.


'''I am on PPC (e.g. old iMac) and want to use it for serving Diaspora, but there is no ExecJS compatible JS runtime'''
=== I am on PPC (e.g. old iMac) and want to use it for serving diaspora*, but there is no ExecJS compatible JS runtime ===
   
   
One thing you could do, assuming you have another PC that will run Node. Precompile your assets on that machine (using `bundle exec rake assets:precompile`) and then check them into git before you deploy to the PPC box. The Javascript runtime is only really needed for precompiling assets and shouldn't be loaded at all in the actual production environment. You may need to use `git add public/assets -f` to force git to check them in, since I think that directory is in .gitignore.
One thing you could do, assuming you have another PC that will run Node: Precompile your assets on that machine (using <tt>bundle exec rake assets:precompile</tt>) and then check them into git before you deploy to the PPC box, or just copy over the contents of <tt>public/assets</tt>. The Javascript runtime is only really needed for precompiling assets and shouldn't be loaded at all in the actual production environment. You may need to use <tt>git add public/assets -f</tt> to force git to check them in, since I think that directory is in .gitignore.
(''from [https://github.com/diaspora/diaspora/issues/3429 #3429]'')
 
=== What are roles and how do I use them? / Make yourself an admin or assign moderators ===
 
{{Note|Since diaspora* 0.7.8.0, you can add admin and moderator roles in the admin panel inside diaspora*. Search for a user and change the role there. You still need to make the first admin manually as described below to have access to that page}}


'''What are roles and how do I use them?'''
    
    
We switched from statically configured 'special' user accounts in the config file to a role system, which lets us change role assignments without having to restart the server.
We have a role system that allows to make some accounts 'special' during runtime, without restarting the server.  
In order to convert your current config to the new roles you can import them by going to the rails console in the production environment by running the following command in your diaspora directory:


    $ RAILS_ENV=production rails c
Currently you can manage the community spotlight, the moderators and the admins through this system. If you are using PostgreSQL, ensure you have set the environment variable <tt>DB='postgres'</tt> or you will get a very misleading error from bundler and if you follow it, accidentally install the MySQL adapter.


There you can run the functions that will convert the config values to database entries:
Start by starting a Rails console, using this command in directory of your diaspora gem (usually /home/diaspora/diaspora):


    > Role.load_admins
<syntaxhighlight lang="bash">
    > Role.load_spotlight
RAILS_ENV=production bundle exec rails console
</syntaxhighlight>


In case you want to assign roles to other users, you can do so by running these commands:
You'll get a new shell where you can enter Ruby code. To exit it just press <tt>Ctrl+D</tt> or type  <tt>exit</tt> or <tt>quit</tt>. Here are some examples to manage the roles, replace ''the_username'' with the user's username, not their full diaspora* ID:


    > u = User.find_by_email("user@email.com")
<syntaxhighlight lang="ruby">
    > Role.add_admin(u.person)      # to add as admin, or
Role.add_admin User.where(username: "the_username").first.person          # Add an user as admin by username
    > Role.add_beta(u.person)       # to add as 'beta' user, or
Role.add_admin User.where(email: "the_email").first.person                # Add an user as admin by email
    > Role.add_spotlight(u.person) # to add as 'community spotlight'
Role.add_moderator User.where(username: "the_username").first.person      # Add an user as moderator by username
Role.add_moderator User.where(email: "the_email").first.person             # Add an user as moderator by email
Role.add_spotlight User.where(username: "the_username").first.person      # Add an user to the 'community spotlight' by username
Role.add_spotlight User.where(email: "the_email").first.person            # Add an user to the 'community spotlight' by email
Role.add_spotlight Person.where(diaspora_handle: "username@pod.tld").first # Add an user to the 'community spotlight' by diaspora handle (other pod), make sure that at least one user of your pod follows that account
</syntaxhighlight>


When you are done, you can exit the console with
For admins: your user profile should now have an "Admin" link added to the mouse hover list. This gives you stuff like user search and stats for your pod.<br />
For moderators: The moderator should now have an "Moderator" link added to the mouse hover list. Moderators have access to the report section of the admin panel and can review reported posts and comments. Moderators also get emails when a new comment or post is reported.


    > quit
=== Followed tags don't work on my pod ===


== What if my question isn't answered here? ==
There is no synchronization in diaspora*. This means your pod only knows about posts it has received for a purpose. These purposes are, of course: the author is local, someone on your pod is following the post's author, or the post's author is following someone on your pod. Another reason is that the post got reshared by someone whom one of the users on your pod follows. Tags are not federated to all pods: the #Followed Tags stream displays only posts your pod knows about through one of the previous scenarios.
 
=== My log files are getting huge, help! ===
 
Configure yourself a log rotation solution. For example, on Linux distros, do this with ''logrotate'', something like the following (change the paths where needed) in ''/etc/logrotate.d/diaspora'':
 
<pre>/home/diaspora/diaspora/log/*.log {
  notifempty
  copytruncate
  missingok
  compress
  monthly
  delaycompress
  rotate 5
}</pre>
 
Once you've added the file to "/etc/logrotate.d/" run
 
<pre>sudo logrotate -f /etc/logrotate.conf</pre>
 
=== How can I send an email to a user / a group of users? ===
 
You need a working email configuration. There are two ways for triggering the emails.
 
==== Ruby console ====
 
Fire up your rails console with <code>RAILS_ENV=production bundle exec rails console</code>,
then follow one of the examples or make up your own:
 
<syntaxhighlight lang="ruby">
Notifier.admin("important message", User.where(username: "someuser")).each(&:deliver)                  # Send a message to someuser
Notifier.admin("important message", User.where(username: ["someuser", "anotheruser"])).each(&:deliver) # Send a message to a group of users
Notifier.admin("important message", User.yearly_actives).each(&:deliver)                              # Send a message to all active users
</syntaxhighlight>
 
==== Rake task ====
 
There is a Rake task <tt>podmin:admin_mail</tt> available to allow podmins to easily send news and notices to users. The rake task triggers emails via the normal diaspora mailer mechanism (so they are embedded in the standard template) and takes the following parameters:
 
  1) Users definition
    <tt>all</tt> - all users in the database (except deleted)
    <tt>active_yearly</tt> - users logged in within the last year
    <tt>active_monthly</tt> - users logged in within the last month
    <tt>active_halfyear</tt> - users logged in within the last 6 months
  2) Path to message file
    Give here a path to a HTML or plain text file that contains the message.
  3) Subject
    A subject for the email
 
Example shell command (depending on your environment);
 
<syntaxhighlight lang="bash">
RAILS_ENV=production bundle exec rake podmin:admin_mail['active_monthly','./message.html','Important message from pod']
</syntaxhighlight>
 
Read more about [http://stackoverflow.com/a/825832/1489738 specifying arguments to Rake tasks].
 
=== Can I add advertisements to my pod? ===
 
Sure, we have no rules that you cannot add advertisements to your diaspora* installation.
 
=== How do I define a Terms of Service document for signing up to my pod? ===
 
That feature is built in and we have a generic template that you are welcome to use. Of course, you can also edit it or create your own set of terms.
 
This feature is built in but not enabled by default. If you want to enable it, please add under settings in <tt>config/diaspora.yml</tt> the following and restart diaspora. If in doubt see <tt>config/diaspora.yml.example</tt>:
 
<pre><nowiki>
  terms:
    enable: true
</nowiki></pre>
 
When enabled, the footer and sidebar will have a link to terms page, and signup will have a disclaimer indicating that creating an account means the user accepts the terms of use.
 
While the project itself doesn't restrict what kind of terms pods run on, we realize not all podmins want to spend time writing them from scratch. Thus there is a basic ToS template included that will be used unless a custom one available.
 
To modify (or completely rewrite) the terms template, create a file called <tt>app/views/terms/terms.haml</tt> or <tt>app/views/terms/terms.erb</tt> and it will automatically replace the default template, which you can find at <tt>app/views/terms/default.haml</tt>.
 
There are also two configuration settings to customize the terms (when using the default template). These are optional.
 
* <tt>settings.terms.jurisdiction</tt> - indicate here in which country or state any legal disputes are handled.
* <tt>settings.terms.minimum_age</tt> - indicate here if you want to show a minimum required age for creating an account.
 
=== How do I modify the pod landing page? ===
 
Please see [[Custom_splash_page]].
 
=== How can I delete spam from my pod? ===
 
To properly delete spam accounts and contents from your pod, no matter if the spam was created on your pod for federated to your pod, download [https://gist.github.com/jhass/9104029 this script], place it in your <tt>diaspora</tt> directory, read the comments, fill in the details, and run the script with <tt>RAILS_ENV=production bin/bundle exec ruby diaspora_spam.rb</tt>. If you have questions, please reach out to the project team on Discourse.
 
== Errors and problems ==
 
=== What do I do about all these PGErrors, like disconnects and SSL problems? ===
 
If you are running diaspora* with PostgreSQL, beware that having [http://www.postgresql.org/docs/9.1/interactive/runtime-config-connection.html#GUC-SSL the SSL setting] turned on in the PostgreSQL config has been causing problems for several people.  We recommend turning it off unless you know what you're doing.
 
=== My sidekiq is crashing, help! ===
 
==== Check your <tt>curl</tt> version ====
 
<pre><nowiki>
  /usr/bin/curl --version
</nowiki></pre>
 
Make sure you see <tt>AsynchDNS</tt> in the output. If this does not happen, check [https://github.com/diaspora/diaspora/issues/4202 this issue on how to upgrade curl].
 
==== Check database connection pool ====
 
Make sure you have enough database pool connections to top your <tt>environment.sidekiq.concurrency</tt>. Search <tt>logs/sidekiq.log</tt> for errors relating to database connection not being available if unsure if you are running out. You can edit the <tt>pool</tt> setting in <tt>config/database.yml</tt> if needed and then restart. Make it sufficiently larger than your <tt>sidekiq concurrency*sidekiq workers</tt>, 1.5x is a safe rule here.
 
==== Check for out of open files errors ====  


=== IRC Channels ===
In the diaspora* app folder, do <tt>grep "Too many open files" log/sidekiq.log</tt> and check for results relating to the system user running the diaspora server running out of open files. If you get any errors, it is possible sidekiq can be brought down by the same problem. Follow for example [https://rtcamp.com/tutorials/linux/increase-open-files-limit/ this guide] to increase the limit of open files available to the user running diaspora*.


IRC is the best way to get an answer quickly. Click the link to the join the channel in a new
==== Make sure memory is not running out ====
browser window. You can also download and use an IRC client such as
[http://colloquy.info/ Colloquy] for OS X or
[http://www.mirc.com/ mIRC] for Windows.


* [http://webchat.freenode.net/?channels=diaspora #diaspora on irc.freenode.net] - general discussion and help for folks installing Diaspora
If the server runs out of memory, it is likely sidekiq will be the first to be killed. Check for <tt>Cannot allocate memory</tt> text in the <tt>./script/server</tt> output, or use monitoring to see when memory goes critical. [http://serverfault.com/questions/348052/how-to-increase-swap-size Increase the amount of swap available] to make sure the application does not die (swap should be at least the same as RAM).
* [http://webchat.freenode.net/?channels=diaspora-dev #diaspora-dev on irc.freenode.net] - discussion of the source code and help for new developer contributors
* [http://webchat.freenode.net/?channels=diaspora-de #diaspora-de on irc.freenode.net] - discussion in German.


=== Mailing lists ===
To make sure sidekiq doesn't use too much memory, make sure you are not running with too many Sidekiq workers or concurrency. On a small pod, you can safely but both values to 1 in <tt>config/diaspora.yml</tt>. Then restart and watch the Sidekiq admin panel and if a queue starts to build up, increase the <tt>concurrency</tt> in small increments until Sidekiq can handle the queue. There is '''NO''' need to run more Sidekiq concurrent threads than is needed to process the queue - you just use more memory this way!


We have two mailing lists, both Google groups. They tend to have a slightly different audience than
== What if my question isn't answered here? ==
the IRC channels, so if you can't get your question answered in IRC, you can try here.


* [http://groups.google.com/group/diaspora-discuss Discussion list] - Google group for discussion of non-technical topics
Just ask us! Read more on how to do that at [[How we communicate]].
* [http://groups.google.com/group/diaspora-dev Development discussion list] - Google group for discussion of installation, source code, and other technical topics


[[Category:Podmin]]
[[Category:Podmin]]
[[Category:Github transfer done]]

Latest revision as of 12:08, 18 June 2020

We've started adding questions that we're frequently asked to this page, but it doesn't cover everything. If you have other questions, the best way to get an answer quickly is to visit us in our IRC channel.

Installation Information

What are the general system requirements?

Running diaspora* requires resources depending on how many users use the installation and how much traffic the installation receives from other pods. Generally it is recommended that at least 1 Gig of memory should be available for even small instances.

For pods with more users the amount of memory available to diaspora* and the background jobs it needs is higher depending on the amount of users actively using the instance. As the database grows, more memory will be needed to compensate.

Since diaspora* requires quite a lot of different components to be installed, generally shared hosting servers are not sufficient. Any VPS or dedicated server with a suitable amount of memory will suffice.

Do you have a detailed installation guide?

Yes. Check it out! It will probably be more up-to-date than this page, in general.

What ports does diaspora* need open for communication?

Since we recommend running on HTTPS you should only need to open the standard port for it: 443. You should have a reverse proxy listening there that forwards the requests to the application server that diaspora* starts, on port 3000 by default. You can use your existing Nginx or Apache to do that. While we don't recommend it, you can run on plain HTTP with its standard port 80 too. Just never let diaspora* listen on these ports directly. You don't need to open the application server port, 3000, it's for internal communication only.

Can I use Apache to run diaspora*?

Yes: diaspora* is a standard Rails application, so you can run it with Passenger, or doing the more common setup which is to use a reverse proxy configuration. Check this example on how to configure that setup.

Do I need a commercial SSL certificate? / Can I use CAcert certificates?

If you plan on running your pod over HTTPS (yes, you should!) then yes you will need a valid commercial SSL certificate. By design, federation will not work with pods that have self-signed or invalid SSL certs installed. We do this to ensure that all users in the network are able to use diaspora* without suffering from constant security warnings related to 'invalid' certs.

For more information see this and this discussion.

There are free commercial certificates around - check Let's Encrypt for example (acme.sh makes the process a bit more simple).

How can I run multiple load-balanced instances of diaspora*?

Multiple diaspora* instances for the same "pod" must share SQL and Redis databases, and public/uploads directories. There are many possible ways to accomplish this, but perhaps the most classical scenario would be to configure all the nodes to point at a central database server for MySQL/Postgres and Redis, and share the uploads directory from a file server via NFS. To avoid problems with schema changes, it would be desirable to keep all of the instances running the same version of diaspora* at all times.

Load-balancing of the instances can be accomplished with any TCP load balancer that supports session stickiness (such as Apache or nginx, among others).

How can I restart diaspora* without any downtime?

By default, diaspora* uses Unicorn to serve requests. In production mode, it's possible to do a graceful restart of the Unicorn process to avoid downtime. This command, executed in the directory of your diaspora installation, will spawn a new master process, loading any code/configuration changes that you've made:

RAILS_ENV=production bin/eye restart web

As the new master spawns workers, old workers finish their requests and are removed from the old master until the last new worker is spawned, at which time the old master is shut down.

Note: this only applies for 0.6.2.0 or newer.

Troubleshooting

I installed diaspora* on my machine, went to http://localhost:3000 and signed up. But my friends can't add me!

You set "localhost" as your address, but this is not a valid external address. You first need an externally accessible address - either a domain name or an IP address. Once you have that working, you need to clear your database (`$ bundle exec rake db:drop db:create db:migrate`) and re-register, coming in via the external URL. Note that if your externally accessible address changes, you need to start over. diaspora* is designed as a server application to run all day and night.

I get 'command not found' if I run bundle install

Make sure RVM is loaded and the correct Ruby version and gemset are activated. The output of the rvm info and gem env commands can be helpful in that. Run gem install bundler to reassure bundler is actually installed.

If you don't use RVM, a common issue is that Debian-based distributions, including Ubuntu, don't add gem executables to the search path. Read up on the PATH environment variable on how to solve that.

How do I get past the sign-in page to create a new account?

To create a new account, go to http://yourdiasporainstance.tld/users/sign_up (replacing yourdiasporainstance.tld with the host name of your pod).

I installed diaspora* on my machine, but when I load the site there are no images and the layout looks horrible!

You most likely started diaspora* in production mode and accessed the application server directly and not through your reverse proxy. In production mode we expect your reverse proxy to serve the static content since it does the job way better than anything else. If you did access diaspora* through a reverse proxy, make sure it has no configuration issues, has the public/ directory as document root and is set to look up if requested files are found there before directing the request to the application server.

Also make sure you ran bundle exec rake assets:precompile.

If you need to work around this requirement you can turn environment.assets.serve to true in config/diaspora.yml.

There are no uploaded images on my pod

First make sure other static content is working, as described in the previous section. We embed uploaded images with their full URL, this has to do with the way diaspora* makes sure your images can be seen by users on other pods. A common problem here is that environment.url in config/diaspora.yml, from which diaspora* constructs the full URL, is set to an incorrect value.

I can't find anybody on another pod / I am receiving posts but nobody is receiving mine

If you're having problems, make sure to search for people by their full diaspora* ID. Check that your Sidekiq worker is running. Check Sidekiq's retry queue for error messages. Check that the environement.certificate_authorities setting is correct.

I can't find myself from another pod / I am not receiving any posts but everybody is receiving mine

Check that your SSL setup is correct, use sslshopper, ssllabs or High-Tech Bridge to test your configuration. Make sure it's all green, no yellow, no red.

I'm getting the warning "... in production without Sidekiq workers"

Sidekiq is the backend we use for processing background jobs. Normally, Sidekiq is spawned as a separate process, but in this case you have configured diaspora* to run the jobs in the same process as the application. This is normally used for development or testing purposes, but if used in production, it can bring major performance penalties. Thus you should always run Sidekiq in its own process, by setting environment.single_process_mode to false in your config/diaspora.yml and starting the Sidekiq process with

RAILS_ENV=production bundle exec sidekiq

In case you are using script/server to start diaspora*, then you don't have to manually start the workers! This is already done by the script.

How can I troubleshoot my email configuration?

Use the following command to send an email and get the exceptions right on your console:

RAILS_ENV=production bundle exec rails runner 'Notifier.admin("test message", User.where(username: "your_username")).each(&:deliver_now)'

Make sure to restart diaspora* once you successfully receive the test message.

I'm getting a 500 error page

Oh noes, you might have hit a bug in diaspora*! But this can also be caused by setup issues, like a incorrectly setup custom landing page, an old Redis version or database connectivity issue.

  1. Make sure you found a reliable way to reproduce the issue.
  2. Run tail -f log/production.log. Watch the output closely as you reproduce the issue.
  3. If you can't make sense out of the actual error message, reach out to us, see How we communicate. When doing so provide the steps you have taken to produce the error page as well as the full output from the log while reproducing it.
  4. If told to open an issue, go to https://github.com/diaspora/diaspora/issues. Again make sure to provide the steps to reproduce the problem as well as the log output.

I'm getting an error when starting ./script/server

If you get undefined symbol: sigar_skip_token, you need to run in your diaspora* server directory:

GEM_HOME=vendor/bundle/ruby/2.4.0 gem uninstall sigar
bin/bundle config --local build.sigar "--with-cppflags='-fgnu89-inline'"

Afterwards, you need to re-run the bundle install command from the installation instructions.

Upgrading

Is there anything I should do before upgrading my installation?

Yes, read our notes for updating.

How do I roll back my installation if an update breaks it?

First, try to fix your installation; as always our IRC channel should be helpful for getting help with this.

To roll back, just do: git checkout ref Where ref is the identifier of the commit to go back to. It's a long string of letters and numbers. You can find the ref by doing a git log, eyeballing the commit dates, and figuring out where you were before you pulled. Of course it's best if you keep track of that ref before you update.

You can also checkout a particular version with git checkout v0.3.0.1, replacing the version of course.

After that just follow the same procedure that you would to update your installation.

What if there were database migrations in the code I am rolling back?

Then you also need to roll those back separately. You need to do this before you roll back the code. Look in the db/migrate directory and figure out which files are new since the last time you pulled - i.e., which migration your database should be on. They are in timestamp order in that directory. Then do: bundle exec rake db:rollback and look at the output. It will tell you which migration you are now on. It rolls back one each time you run it. Run it until you're on the right migration and then roll back the code as described above.

Also be aware that database rollbacks can fail - they depend on the migration author writing the correct code to roll back. So in this case it's generally much easier to seek help to fix your current setup than to roll it back.

General

How can I receive project news? (Updates, Security fixes, ...)

There are multiple channels for important news, including:

Am I alone here? (Establish connections with other pods)

Once you set up your pod, you should add some contacts to start receiving content from other pods. It's a good idea to add some active diaspora* people to your contacts, because they almost all run their own pod, so your pod will be known by them and you will be easily findable from there.

Here is a small list:

  • Official account of the project: hq[at]pod.diaspora.software
  • Sean Tilley: deadsuperhero[at]joindiaspora.com
  • Jonne Haß: jhass[at]diaspora.social
  • Jason Robinson: jaywink[at]jasonrobinson.me
  • The Geraspora team: team[at]pod.geraspora.de
  • Waithamai: waithamai[at]pod.geraspora.de
  • Fla: fla[at]diaspora-fr.org

After you added a few contacts it's a good idea to make a public post containing the #newhere tag, announcing your new pod, to get even more contacts.

Can I make my pod private/isolated/not communicate with other pods?

No. diaspora* is built around the idea of a distributed social network. We want to build one network, not enable special interest communities or companies to host their own social network (We do welcome you on diaspora* though!). A large amount of the development effort goes into making that one network possible and the whole user experience is designed around it. This not only means that other existing solutions often have feature-sets way better suited to that usecase, but also that if we did implement a switch to turn off communication with other pods, there would be many broken ends in the user interface, which would lead to a bad user experience.

Can I modify the code?

Yes. But keep in mind that diaspora* is licensed under the AGPLv3, that means you must make the currently running source code available to your users. For legal advice beyond that, please contact your lawyer.

Will a pod eventually receive federated posts that it misses while being offline/down?

Possibly. We retry the delivery three times at one hour intervals.

I've got my pod running. How do I disable outside logins?

Set settings.enable_registrations to false in your config/diaspora.yml and then restart diaspora*.

How do I back up my pod?

You should do backups of all user data, that is the whole database and uploaded images. For the images just make copies of the public/uploads directory. Then just dump all Diaspora_ databases from your database server. A web search should get you the information you need on how to do that. Make sure to store the backups on a different server, or at least on a different hard drive.

For more details, see Pod data backup.

I am on PPC (e.g. old iMac) and want to use it for serving diaspora*, but there is no ExecJS compatible JS runtime

One thing you could do, assuming you have another PC that will run Node: Precompile your assets on that machine (using bundle exec rake assets:precompile) and then check them into git before you deploy to the PPC box, or just copy over the contents of public/assets. The Javascript runtime is only really needed for precompiling assets and shouldn't be loaded at all in the actual production environment. You may need to use git add public/assets -f to force git to check them in, since I think that directory is in .gitignore.

What are roles and how do I use them? / Make yourself an admin or assign moderators

NoteNote:Since diaspora* 0.7.8.0, you can add admin and moderator roles in the admin panel inside diaspora*. Search for a user and change the role there. You still need to make the first admin manually as described below to have access to that page


We have a role system that allows to make some accounts 'special' during runtime, without restarting the server.

Currently you can manage the community spotlight, the moderators and the admins through this system. If you are using PostgreSQL, ensure you have set the environment variable DB='postgres' or you will get a very misleading error from bundler and if you follow it, accidentally install the MySQL adapter.

Start by starting a Rails console, using this command in directory of your diaspora gem (usually /home/diaspora/diaspora):

RAILS_ENV=production bundle exec rails console

You'll get a new shell where you can enter Ruby code. To exit it just press Ctrl+D or type exit or quit. Here are some examples to manage the roles, replace the_username with the user's username, not their full diaspora* ID:

Role.add_admin User.where(username: "the_username").first.person           # Add an user as admin by username
Role.add_admin User.where(email: "the_email").first.person                 # Add an user as admin by email
Role.add_moderator User.where(username: "the_username").first.person       # Add an user as moderator by username
Role.add_moderator User.where(email: "the_email").first.person             # Add an user as moderator by email
Role.add_spotlight User.where(username: "the_username").first.person       # Add an user to the 'community spotlight' by username
Role.add_spotlight User.where(email: "the_email").first.person             # Add an user to the 'community spotlight' by email
Role.add_spotlight Person.where(diaspora_handle: "username@pod.tld").first # Add an user to the 'community spotlight' by diaspora handle (other pod), make sure that at least one user of your pod follows that account

For admins: your user profile should now have an "Admin" link added to the mouse hover list. This gives you stuff like user search and stats for your pod.
For moderators: The moderator should now have an "Moderator" link added to the mouse hover list. Moderators have access to the report section of the admin panel and can review reported posts and comments. Moderators also get emails when a new comment or post is reported.

Followed tags don't work on my pod

There is no synchronization in diaspora*. This means your pod only knows about posts it has received for a purpose. These purposes are, of course: the author is local, someone on your pod is following the post's author, or the post's author is following someone on your pod. Another reason is that the post got reshared by someone whom one of the users on your pod follows. Tags are not federated to all pods: the #Followed Tags stream displays only posts your pod knows about through one of the previous scenarios.

My log files are getting huge, help!

Configure yourself a log rotation solution. For example, on Linux distros, do this with logrotate, something like the following (change the paths where needed) in /etc/logrotate.d/diaspora:

/home/diaspora/diaspora/log/*.log {
   notifempty
   copytruncate
   missingok
   compress
   monthly
   delaycompress
   rotate 5
}

Once you've added the file to "/etc/logrotate.d/" run

sudo logrotate -f /etc/logrotate.conf

How can I send an email to a user / a group of users?

You need a working email configuration. There are two ways for triggering the emails.

Ruby console

Fire up your rails console with RAILS_ENV=production bundle exec rails console, then follow one of the examples or make up your own:

Notifier.admin("important message", User.where(username: "someuser")).each(&:deliver)                  # Send a message to someuser
Notifier.admin("important message", User.where(username: ["someuser", "anotheruser"])).each(&:deliver) # Send a message to a group of users
Notifier.admin("important message", User.yearly_actives).each(&:deliver)                               # Send a message to all active users

Rake task

There is a Rake task podmin:admin_mail available to allow podmins to easily send news and notices to users. The rake task triggers emails via the normal diaspora mailer mechanism (so they are embedded in the standard template) and takes the following parameters:

 1) Users definition
   all - all users in the database (except deleted)
   active_yearly - users logged in within the last year
   active_monthly - users logged in within the last month
   active_halfyear - users logged in within the last 6 months
 2) Path to message file
   Give here a path to a HTML or plain text file that contains the message.
 3) Subject
   A subject for the email

Example shell command (depending on your environment);

RAILS_ENV=production bundle exec rake podmin:admin_mail['active_monthly','./message.html','Important message from pod']

Read more about specifying arguments to Rake tasks.

Can I add advertisements to my pod?

Sure, we have no rules that you cannot add advertisements to your diaspora* installation.

How do I define a Terms of Service document for signing up to my pod?

That feature is built in and we have a generic template that you are welcome to use. Of course, you can also edit it or create your own set of terms.

This feature is built in but not enabled by default. If you want to enable it, please add under settings in config/diaspora.yml the following and restart diaspora. If in doubt see config/diaspora.yml.example:

  terms:
    enable: true

When enabled, the footer and sidebar will have a link to terms page, and signup will have a disclaimer indicating that creating an account means the user accepts the terms of use.

While the project itself doesn't restrict what kind of terms pods run on, we realize not all podmins want to spend time writing them from scratch. Thus there is a basic ToS template included that will be used unless a custom one available.

To modify (or completely rewrite) the terms template, create a file called app/views/terms/terms.haml or app/views/terms/terms.erb and it will automatically replace the default template, which you can find at app/views/terms/default.haml.

There are also two configuration settings to customize the terms (when using the default template). These are optional.

  • settings.terms.jurisdiction - indicate here in which country or state any legal disputes are handled.
  • settings.terms.minimum_age - indicate here if you want to show a minimum required age for creating an account.

How do I modify the pod landing page?

Please see Custom_splash_page.

How can I delete spam from my pod?

To properly delete spam accounts and contents from your pod, no matter if the spam was created on your pod for federated to your pod, download this script, place it in your diaspora directory, read the comments, fill in the details, and run the script with RAILS_ENV=production bin/bundle exec ruby diaspora_spam.rb. If you have questions, please reach out to the project team on Discourse.

Errors and problems

What do I do about all these PGErrors, like disconnects and SSL problems?

If you are running diaspora* with PostgreSQL, beware that having the SSL setting turned on in the PostgreSQL config has been causing problems for several people. We recommend turning it off unless you know what you're doing.

My sidekiq is crashing, help!

Check your curl version

   /usr/bin/curl --version

Make sure you see AsynchDNS in the output. If this does not happen, check this issue on how to upgrade curl.

Check database connection pool

Make sure you have enough database pool connections to top your environment.sidekiq.concurrency. Search logs/sidekiq.log for errors relating to database connection not being available if unsure if you are running out. You can edit the pool setting in config/database.yml if needed and then restart. Make it sufficiently larger than your sidekiq concurrency*sidekiq workers, 1.5x is a safe rule here.

Check for out of open files errors

In the diaspora* app folder, do grep "Too many open files" log/sidekiq.log and check for results relating to the system user running the diaspora server running out of open files. If you get any errors, it is possible sidekiq can be brought down by the same problem. Follow for example this guide to increase the limit of open files available to the user running diaspora*.

Make sure memory is not running out

If the server runs out of memory, it is likely sidekiq will be the first to be killed. Check for Cannot allocate memory text in the ./script/server output, or use monitoring to see when memory goes critical. Increase the amount of swap available to make sure the application does not die (swap should be at least the same as RAM).

To make sure sidekiq doesn't use too much memory, make sure you are not running with too many Sidekiq workers or concurrency. On a small pod, you can safely but both values to 1 in config/diaspora.yml. Then restart and watch the Sidekiq admin panel and if a queue starts to build up, increase the concurrency in small increments until Sidekiq can handle the queue. There is NO need to run more Sidekiq concurrent threads than is needed to process the queue - you just use more memory this way!

What if my question isn't answered here?

Just ask us! Read more on how to do that at How we communicate.