Difference between revisions of "FAQ for pod maintainers"

From diaspora* project wiki
Jump to: navigation, search
(Cleaned up English a bit.)
Line 1: Line 1:
 
{{Languages}}
 
{{Languages}}
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 the [[How we communicate#IRC|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]].
  
 
== Installation ==
 
== Installation ==
Line 7: Line 7:
 
=== Do you have a detailed installation guide? ===
 
=== Do you have a detailed installation guide? ===
 
   
 
   
Yes. [[Installation|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.
 
  
=== 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 that, 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.
+
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? ===
+
=== Can I use Apache to run diaspora*? ===
 
    
 
    
Yes, Diaspora is a standard Rails application, so you can run it with [https://www.phusionpassenger.com/ Passenger]. Though common setup is to use a reverse proxy configuration. You should definitively read [[Diasporas_components_explained|this brief explanation of Diasporas components]] before attempting such a setup.
+
Yes: diaspora* is a standard Rails application, so you can run it with [https://www.phusionpassenger.com/ Passenger], though the common setup is to use a reverse proxy configuration. You should definitely read [[Diasporas_components_explained|this brief explanation of diaspora*s components]] before attempting such a setup.
  
=== I installed Diaspora on my machine, went to <nowiki>http://localhost:3000</nowiki> and signed up. But my friends can't add me! ===
+
=== I installed diaspora* on my machine, went to <nowiki>http://localhost:3000</nowiki> and signed up. But my friends can't add me! ===
 
    
 
    
You signed up with "localhost" which is not a valid external address. You first need an
+
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
+
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:schema:load`) and re-register coming in on the outside URL. Note that if your externally accessible address changes, you need to start over. Diaspora is designed as a server application running all day and night.
+
working, you need to clear your database (`$ bundle exec rake db:drop db:create db:schema:load`) 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 ===
 
=== I get 'command not found' if I run bundle install ===
Line 28: Line 27:
 
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.
 
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.
  
If you don't use RVM, a common issue is that Debian based distributions, this includes Ubuntu, don't add gem executables to the search path. Read up on the <tt>PATH</tt> environment variable on how to solve that.
+
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.
  
=== 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 <nowiki>http://yourdiasporainstance.com/users/sign_up</nowiki>
+
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 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! ===
+
=== 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 a way better job at it than anybody 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 looks up if requested files are found there before directing the request to the application server.
+
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>.
 
Also make sure you ran <tt>bundle exec rake assets:precompile</tt>.
  
If you need to workaround this requirement you can turn <tt>environment.assets.serve</tt> to <tt>true</tt> in <tt>config/diaspora.yml</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>.
  
 
=== There are no uploaded images on my pod ===
 
=== There are no uploaded images on my pod ===
 
    
 
    
First make sure other static content is working, as described in the previous question. 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 construct the full URL, is set to an incorrect value.
+
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.
  
 
=== I can't find anybody on another pod / I am receiving posts but nobody is receiving mine ===
 
=== I can't find anybody on another pod / I am receiving posts but nobody is receiving mine ===
 
    
 
    
Make sure to initially search by their full Diaspora ID. Check that your Sidekiq worker is running. Check Sidekiqs retry queue for error messages. Check that the <tt>environement.certificate_authorities</tt> setting is correct.
+
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.
  
 
=== I can't find myself from another pod / I am not receiving any posts but everybody is receiving mine ===
 
=== I can't find myself from another pod / I am not receiving any posts but everybody is receiving mine ===
Line 57: Line 56:
 
=== I'm getting the warning "... in production without Sidekiq workers" ===
 
=== I'm getting the warning "... in production without Sidekiq workers" ===
 
    
 
    
[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
+
[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
  
 
<syntaxhighlight lang="bash">
 
<syntaxhighlight lang="bash">
Line 63: Line 62:
 
</syntaxhighlight>
 
</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.
+
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.
  
 
== Upgrading ==
 
== Upgrading ==
Line 73: Line 72:
 
=== How do I roll back my installation if an update breaks it? ===
 
=== How do I roll back my installation if an update breaks it? ===
  
First of try to get help to fix your installation, as always the [[How we communicate#IRC|IRC]] should be helpful here.
+
First, try to fix your installation; as always our [[How we communicate#IRC|IRC channel]] should be helpful for getting help with this.
  
 
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.
 
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.
Line 79: Line 78:
 
You can also checkout a particular version with <tt>git checkout v0.1.1.0</tt>, replacing the version of course.
 
You can also checkout a particular version with <tt>git checkout v0.1.1.0</tt>, replacing the version of course.
  
After that just do the same procedure as if you made an update.
+
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? ===
Line 86: Line 85:
 
<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.
 
<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. So in this case it's generally much easier to seek for help to fix your setup.
+
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 ==
Line 92: Line 91:
 
=== Will a pod eventually receive federated posts that it misses while being offline/down? ===
 
=== Will a pod eventually receive federated posts that it misses while being offline/down? ===
  
Yes, eventually. We retry the delivery three times, in one hour intervals.
+
Yes, eventually. We retry the delivery three times, at hourly intervals.
  
 
=== What do I do about all these PGErrors, like disconnects and SSL 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.
+
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.
+
Set <tt>settings.enable_registrations</tt> to <tt>false</tt> in your <tt>config/diaspora.yml</tt> and then restart diaspora*.
  
 
=== How do I back up my pod? ===
 
=== 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 <tt>public/uploads</tt> directory. Then just dump all <tt>diaspora_*</tt> databases from your database server. Google should get you along on how to do that. Make sure to store the backups on a different server or at least on a different hard drive.
+
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.
  
=== 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 <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.
 
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.
Line 112: Line 111:
 
=== What are roles and how do I use them? / Make yourself an admin ===
 
=== What are roles and how do I use them? / Make yourself an admin ===
 
    
 
    
We have a role system that allows to make some accounts special during runtime, without restarting the server.  
+
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 and the admins through this system. Start by starting a Rails console:
 
Currently you can manage the community spotlight and the admins through this system. Start by starting a Rails console:
  
Line 119: Line 119:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
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 users username, not the full Diaspora ID:
+
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:
  
 
<syntaxhighlight lang="ruby">
 
<syntaxhighlight lang="ruby">
Line 132: Line 132:
 
=== Followed tags don't work on my pod ===
 
=== Followed tags don't work on my pod ===
  
There is no synchronization in Diaspora. This means your pod only knows post he has received for a purpose. These purposes are of course the author is local, someone on your pod is following the post author or the post author is following someone on your pod. Another reason is that the post got reshared to one of the users on your pod. In the (followed) tag streams are only posts your pod knows about.
+
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! ===
 
=== My log files are getting huge, help! ===
  
Configure yourself a log rotation solution. For example, on Linuxes with ''logrotate'', something like the following (change the paths where needed) in ''/etc/logrotate.d/diaspora'':
+
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 {
 
<pre>/home/diaspora/diaspora/log/*.log {

Revision as of 16:51, 24 February 2014

Template:Languages 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.

Contents

Installation

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, though the common setup is to use a reverse proxy configuration. You should definitely read this brief explanation of diaspora*s components before attempting such a setup.

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:schema:load`) 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 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, this test gives a good indication. 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.

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.1.1.0, 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

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

Yes, eventually. We retry the delivery three times, at hourly intervals.

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.

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.

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

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 and the admins through this system. Start by starting a Rails console:

bundle exec rails console production

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_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

Congratulation, you now have access to the /admins and /admin_panel pages :)

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

What if my question isn't answered here?

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