https://wiki.diasporafoundation.org/api.php?action=feedcontributions&user=Morriscloud&feedformat=atomdiaspora* project wiki - User contributions [en]2024-03-29T14:48:40ZUser contributionsMediaWiki 1.39.3https://wiki.diasporafoundation.org/wiki/index.php?title=Talk:Integrating_other_social_networks&diff=10291Talk:Integrating other social networks2018-05-04T00:49:45Z<p>Morriscloud: </p>
<hr />
<div>== Valid for Facebook May 2018 ==<br />
<br />
I am not particularly skilled and managed to go through the FB setup with zero issues. Might consider updating the "out of date" message. [[User:Morriscloud|Morriscloud]] ([[User talk:Morriscloud|talk]]) 00:49, 4 May 2018 (UTC)<br />
<br />
== New Facebook API ==<br />
<br />
So DenSchub, you're saying the new Facebook API does not need the changes indicated by RDash? --[[User:Jaywink|Jaywink]] ([[User talk:Jaywink|talk]]) 20:46, 3 October 2014 (UTC)</div>Morriscloudhttps://wiki.diasporafoundation.org/wiki/index.php?title=Integrating_other_social_networks&diff=10290Integrating other social networks2018-05-04T00:47:47Z<p>Morriscloud: minor language changes</p>
<hr />
<div>{{Out of date}}<br />
{{Note|1=I'm not sure the info here is still correct. At least for facebook I think I remember things have changed..? Please check and, if it's still correct, remove these templates. Also, it might be useful to link this page on the main page, in the "podmin resources" list(?) --[[User:Waithamai|waithamai]] <sup>[[User talk:Waithamai|talk]]</sup> 01:21, 30 August 2017 (UTC)}}<br />
<br />
== General ==<br />
<br />
Keys will be entered into your config/diaspora.yml<br />
<br />
== Twitter ==<br />
<br />
* Go to [https://apps.twitter.com https://apps.twitter.com] and sign in<br />
* Click on ‘Create an app’ [[Image:Twitter_1.png|thumb|300px|Create an app on Twitter]]<br />
* Register your app [[Image:Twitter_2.png|thumb|300px|Register your app]]<br />
** Give it a name. For example "Diaspora at example.org"<br />
** Give it a description<br />
** Set the application website to your pod URL or a page that describes what Diaspora is and what your pod has to do with it<br />
** '''Important:''' Set the callback URL to <tt>https://your_pod/auth/twitter/callback</tt>, replacing your_pod of course.<br />
** There’s a ToS to accept<br />
** There is a Captcha ;)<br />
** Click “Create Twitter application”<br />
* Click the “Permissions” tab and change the “Access” to “Read and Write”.<br />
* Click the “Keys and Access Tokens” tab. You now can see your “Consumer Key” and your “Consumer Secret”, copy them to the right places in <tt>config/diaspora.yml</tt><br />
* Restart Diaspora on your sever <br>(You can skip that if you plan to also add support for more services. Just remember to do it once you're finished with all of them.)<br />
* You’re done. It’s now possible to post to Twitter from your pod :)<br />
<br />
== Tumblr ==<br />
<br />
* Goto [http://www.tumblr.com/oauth/register Tumblr Apps] page<br />
** Enter your Application Name (eg. “Diaspora at social.example.org”)<br />
** Enter the Application website (eg. https://social.example.org)<br />
** Enter the Administrative contact email address<br />
** '''Important:''' Set the “Default callback URL” to your pod url (including http/https)+ <tt>/auth/tumblr/callback</tt> So if your pod is located at <tt>https://social.example.org</tt> enter <tt>https://social.example.org/auth/tumblr/callback</tt><br />
** You can upload an Icon if you wish<br />
** Click register<br />
* You’ll be redirected to the [http://www.tumblr.com/oauth/apps Application Overview] where you can see your "OAuth Consumer Key". Click on “Show secret key” to reveal your Secret Key.<br />
* Copy your OAuth Consumer Key and your Secret Key App to your <tt>config/diaspora.yml</tt><br />
* Restart Diaspora on your server<br />
* You’re done. It’s now possible to post to Tumblr from your pod :)<br />
<br />
== Facebook ==<br />
<br />
* Goto [https://developers.facebook.com/apps/?action=create Facebook Developers] page and click "Add a New App"<br />
* Type a name for your App (eg. “Diaspora at social.example.org”) enter your email and click "Create New Facebook App ID"<br />
* Solve the captcha. Your App has now been created.<br />
* You will see the screen "Add a product". Choose Facebook Login and click on setup. <br />
* Choose Web as plattform for using the facebook login.<br />
* Fill in your pod URL, e.g. https://<your pod url> and click on save.<br />
* On the left menu click on settings => basic.<br />
* Fill out: Display Name (= name of your Pod), App Domains (= your pod domain without any protocoll, e.g. geraspora.de), the links to privacy and tos urls.<br />
* At the top of this page copy the App ID and App Secret and insert these strings to your <tt>config/diaspora.yml</tt> at the right place.<br />
* On the left menu click on Facebook Login => settings. <br />
* Activate: Client OAuth Login, Web OAuth Login, Embedded Browser OAuth Login<br />
* At Valid OAuth Redirect URIs place the following url: https://<your pod url>/auth/facebook/callback<br />
* Before going live, create [https://developers.facebook.com/docs/apps/test-users test user acccounts] with different permissions that do not interfere with real Facebook users to make sure that everything is set up fine<br />
* When you are ready to go, click "Off" toggle at the top of the page next to "Status: In Development"<br />
* At the "Are you sure you want to make your app public? It will become available to everyone" message, click "Confirm"<br />
* Restart Diaspora on your server<br />
<br />
=== Additional information ===<br />
You can always create another [https://developers.facebook.com/docs/apps/test-apps test application] based on your live application if you need to update anything and then migrate the changes.<br />
<br />
=== Application for posting to Facebook ===<br />
<br />
By default posting from diaspora* is possible only from the app administrator's Facebook account. To allow all users on the pod to post with the Facebook integration, your app needs '''publish_actions''' permissions to be approved from Facebook as well as [https://developers.facebook.com/docs/apps/review review and approval]. <br />
Click on App Review and start a submission. Select publish_actions from the list and fill out the questionaire. Provide the additional infos: you´ve to describe, how someone can crosspost from diaspora to facebook and you´ve to create a screencast video. For the screencast you can use [https://screencast-o-matic.com/ Screen o Matic]. Before you start the video, add a test user (at roles) and login as test user (click on edit at the created user). So it should be easy to demonstrate how the connection between diaspora and facebook works.<br />
<br />
Requirements for approval:<br />
* Big Logo, (1024x1024 px)<br />
* Developer Contact Email,<br />
* Link to privacy policy, (https://[yourpod][dot][tld]/terms)<br />
* a [https://developers.facebook.com/docs/apps/test-users test account] for Facebook. (Roles - Test Users)<br />
* Screencast of you logging into diaspora and creating a post and showing it post to diaspora and then to your facebook test account user<br />
<br />
Tip:<br />
Make the application as clear and simple as possible like it is being explained to a 5 year old. This will improve the odds of having your app approved. If your application does not succeed the first time they will provide you with additional information.<br />
<br />
Once approved you can change the setting in your config/diaspora.yml to authorized:true facebook permissions and restart diaspora<br />
<br />
=== Privacy of posts to Facebook ===<br />
<br />
Any posts a user makes from a pod to Facebook will be made with the privacy level that the users sets on Facebook side when the user authorizes the diaspora* pod application. Posts done from diaspora* do not follow the privacy of selected aspects on diaspora* side. This behaviour is consistent with posting to Twitter etc where the target application governs the privacy of the post.<br />
<br />
== Wordpress ==<br />
<br />
* Go to the [https://developer.wordpress.com/apps/ Wordpress.com Developer Site] and click "Create New Application"<br />
* Add a name, a description (like "This application allows to post from the diaspora* social network to wordpress.com or any wordpress blog with jetpack enabled.") and the URL of your pod (eg. https://social.example.org)<br />
* '''Important:''' Set the “Redirect URL” to your pod url (including http/https)+ <tt>/auth/wordpress/callback</tt> So if your pod is located at <tt>https://social.example.org</tt> enter <tt>https://social.example.org/auth/wordpress/callback</tt><br />
* Answer the Captcha<br />
* Choose the type "web"<br />
* Click on "Create"<br />
* Visit the [https://developer.wordpress.com/apps/ MyApps] page and select your new App<br />
* Copy your Client ID and your Client Secret to your <tt>config/diaspora.yml</tt><br />
* Restart Diaspora on your server<br />
* You’re done. It’s now possible to post to Wordpress from your pod<br />
<br />
<br />
== Troubleshooting ==<br />
<br />
When thing goes wrong, sometimes the solution is very simple. Take a look at some known issues.<br />
<br />
=== Twitter and Tumblr ===<br />
<br />
==== Server date and time ====<br />
<br />
Authentication methods for Twitter and Tumblr use timestamps. If your server time and timezone are not set as expected, then the hash is generated incorrectly and it won't work.<br />
<br />
[[Category:Podmin]]</div>Morriscloudhttps://wiki.diasporafoundation.org/wiki/index.php?title=Updating&diff=10289Updating2018-05-04T00:03:19Z<p>Morriscloud: Adding notice that static content rake precompile also takes time</p>
<hr />
<div>This page contains specific directions on how to update diaspora*, if any special steps are necessary. If there are no special steps necessary, you can stick to the general guide in the section [[#Updating a production install to a new minor version|Updating a production install to a new minor version]].<br />
<br />
These guides are generally for production setups, if you're developing for diaspora* you should know which steps are relevant to update your development setup. The general steps are available in the section [[#Updating a development install|Updating a development install]]. If you run into any troubles, seek help via the usual channels.<br />
<br />
{{Note|Updating Diaspora is fairly straight forward. But sometimes there are special procedures or updates, so always read the [https://github.com/diaspora/diaspora/blob/master/Changelog.md changelog] first.}}<br />
<br />
= Updating a production install to a new minor version =<br />
<br />
First, make sure you stop your diaspora* pod before proceeding to update your installation. In case you followed the recommended setup and are on RVM, update RVM first:<br />
<br />
<syntaxhighlight lang="bash"><br />
rvm get latest<br />
</syntaxhighlight><br />
<br />
Afterwards, we need to update the code:<br />
<br />
<syntaxhighlight lang="bash"><br />
git checkout Gemfile.lock # Discard uninteresting local changes, if any<br />
git pull<br />
</syntaxhighlight><br />
<br />
Read the output! If you made local modifications to files tracked in git, it might refuse the update or place conflict markers into the files which need to be resolved. If you run on PostgreSQL and get a message about <tt>Gemfile.lock</tt> try <tt>git checkout Gemfile.lock</tt> first. If you get one about <tt>db/schema.rb</tt> try <tt>git checkout db/schema.rb</tt>.<br />
<br />
In case the recommended Ruby version changed you need to install it. Check with<br />
<syntaxhighlight lang="bash"><br />
cd .. && cd -<br />
</syntaxhighlight><br />
<br />
If that outputs a red warning run the command it gives you and do <tt>cd .. && cd -</tt> again.<br />
<br />
Now we need to update the Ruby libraries:<br />
<br />
<syntaxhighlight lang="bash"><br />
gem install bundler<br />
bin/bundle --full-index<br />
</syntaxhighlight><br />
<br />
{{Note|Ignore any migration notes this command gives you, they're already done for you or explicitly advised in our changelog!}}<br />
<br />
Then we apply updates to the database schema, attention this might take some time if you have a big database already:<br />
<br />
<syntaxhighlight lang="bash"><br />
RAILS_ENV=production bin/rake db:migrate<br />
</syntaxhighlight><br />
<br />
Update the static content, which is also likely to take a several minutes and may not give any output at first:<br />
<br />
<syntaxhighlight lang="bash"><br />
RAILS_ENV=production bin/rake assets:precompile<br />
</syntaxhighlight><br />
<br />
Make sure to check new configuration options in <tt>diaspora.yml.example</tt>. Tools like <tt>diff</tt> and <tt>vimdiff</tt> can help transfering new sections.<br />
<br />
Now you need to restart Diaspora. To do this with the standard startup method you need to get to the place where you run <tt>./script/server</tt>, hit <tt>Ctrl+C</tt>, open a new shell, and run it again.<br />
<br />
= Major version update guides =<br />
<br />
While it's fine to skip updates for minor versions, do not try to upgrade from one major version to another major version while skipping one or more in between. In example do not update from 0.5 to 0.7, update from 0.5 to 0.6 and then 0.7 instead.<br />
<br />
== Updating diaspora* 0.6 to diaspora* 0.7 ==<br />
<br />
Since there are a couple of major changes in upgrading to 0.7 which involve manual action, we provide a step by step guide. Please ensure to update to diaspora* 0.6 prior these steps.<br />
<br />
{{Note|If, and only if, you were testing the release candidate, skip this guide, run <tt>git checkout master && git pull</tt> and proceed with the minor release update instructions above.}}<br />
<br />
<ol><br />
<li>Backup your database, run the following steps in a screen or tmux session so they can't be interrupted when for example your SSH connection drops. Run all commands from within your diaspora* installation path.</li><br />
<li>Update RVM with <tt>rvm get latest</tt> and install Ruby 2.4 with <tt>rvm install 2.4</tt>. Ruby 2.1 and Ruby 2.2 are no longer supported. Ruby 2.3 however is supported.</li><br />
<li>Stop diaspora* now, it can't be running during the update or else the migrations will fail.</li><br />
<li>Update diaspora* by running <tt>git checkout db/schema.rb</tt> and <tt>git pull; git checkout master</tt>.</li><br />
<li>Run <tt>git status</tt> and delete all "Untracked files", especially make sure to delete <tt>public/.well-known/host-meta</tt>, since it will prevent the federation from working properly.</li><br />
<li>Activate the new Ruby with <tt>cd .. && cd -</tt>.</li><br />
<li>Install the latest Bundler version with <tt>gem install bundler</tt>.</li><br />
<li>Sometimes the bundler config is broken, so run <tt>script/configure_bundler</tt> to ensure it's correct.</li><br />
<li>Install the dependencies with <tt>bin/bundle</tt>. CAREFUL: Do not run any commands that are suggested at the end of the terminal output; that was already done for you.</li><br />
<li>Update the database with <tt>RAILS_ENV=production bin/rake db:migrate</tt>.</li><br />
<li>When the database was successfully updated, update the assets with: <tt>RAILS_ENV=production bin/rake tmp:cache:clear assets:precompile</tt>.</li><br />
<li>Next you can start diaspora* again. Don't forget to adjust the Ruby version in any startup scripts you may have.</li><br />
</ol><br />
<br />
You should now compare your <tt>config/diaspora.yml</tt> to the updated <tt>config/diaspora.yml.example</tt>, for example with <tt>vimdiff</tt>.<br />
<br />
Have a look at the [https://github.com/diaspora/diaspora/blob/ecd4601bacd8b2e235a05ce6d713fe8cebe89562/Changelog.md changelog] for the full list of changes.<br />
<br />
== Updating diaspora* 0.5 to diaspora* 0.6 ==<br />
<br />
Since there are a couple of major changes in upgrading to 0.6 which involve manual action, we provide a step by step guide. Please ensure to update to diaspora* 0.5 prior these steps.<br />
<br />
{{Note|This update will take a bit longer since it includes a couple of potentially long running migrations, especially for bigger databases.}}<br />
<br />
<ol><br />
<li>First, make sure you stop your diaspora* pod before proceeding to update your installation.</li><br />
<li>Backup your database, run the following steps in a screen or tmux session so they can't be interrupted when for example your SSH connection drops. Run all commands from within your diaspora* installation path.</li><br />
<li>Update RVM with <tt>rvm get latest</tt> and install Ruby 2.3 with <tt>rvm install 2.3</tt>. Ruby 2.0 is no longer supported and Ruby 2.2 is not officially supported but may work. Ruby 2.1 however is supported.</li><br />
<li>Stop diaspora* now, it can't be running during the update or else the migrations will fail.</li><br />
<li>With the old Ruby 2.1 still activated, run <tt>RAILS_ENV=production bundle exec sidekiq</tt> (add <tt>DB=postgres</tt> to the command if you're a PostgreSQL user), wait 5 minutes and take it down again with <tt>Ctrl+C</tt>.</li><br />
<li>Ensure to activate the new Ruby with <tt>rvm use 2.3</tt>.</li><br />
<li>Install the latest Bundler version with <tt>gem install bundler --version 1.15.4</tt>.</li><br />
<li>Update diaspora* by running <tt>git checkout Gemfile.lock db/schema.rb</tt> and <tt>git pull; git checkout v0.6.7.0</tt>.</li><br />
<li>The <tt>DB</tt> environment variable is gone, instead now we need to tell Bundler which database support to install. Run <tt>bin/bundle install --full-index --with mysql --deployment</tt> for MySQL support, run <tt>bin/bundle install --full-index --with postgresql --deployment</tt> for PostgreSQL support. Bundler remembers this choice and you won't have to specify it again. Ignore any migration notes this command gives you, they're already done for you.</li><br />
<li>Update the database with <tt>RAILS_ENV=production bin/rake db:migrate</tt>. This will take some time, be patient.</li><br />
<li>After or while the database is updating, review some of the new configuration defaults. The most important change is that the application server no longer listens to port 3000 by default, instead it now listens to a UNIX socket at <tt>tmp/diaspora.sock</tt>. You should either update your reverse proxy configuration to use the socket, or update <tt>config/diaspora.yml</tt> and explicitly configure it to listen to port 3000. You can find a summary of other important changes below.</li><br />
<li>When the database was successfully updated, update the assets with: <tt>RAILS_ENV=production bin/rake tmp:cache:clear assets:precompile</tt>.</li><br />
<li>Next you can start diaspora* again. Don't forget to adjust the Ruby version in any startup scripts you may have.</li><br />
<li>Finally you need to migrate any jobs from legacy Sidekiq queues to the new ones, to do this run <tt>RAILS_ENV=production bin/rake migrations:legacy_queues</tt>.</li><br />
</ol><br />
<br />
You should now compare your <tt>config/diaspora.yml</tt> to the updated <tt>config/diaspora.yml.example</tt>, for example with <tt>vimdiff</tt>. Notable changes, not only limited to the configuration, are:<br />
<br />
* We dropped support for Redis namespaces in this release. If you previously set a custom namespace, please note that diaspora* will no longer use the configured value. By default, Redis supports up to 8 databases which can be selected via the Redis URL in <tt>config/diaspora.yml</tt>. Please check the examples provided in our configuration example file.<br />
* diaspora* 0.5 introduced an experimental chat feature by making use of Vines. Due to many issues with Vines, we decided to remove it and offer a Prosody example configuration instead. Check [[Integration/Chat]] for more information on how to migrate to Prosody if you've been using Vines before. Unfortunately the feature still is experimental and we recommend careful consideration before you enable it.<br />
* With the port to Bootstrap 3, <tt>app/views/terms/default.haml</tt> has a new structure. If you have created a customised <tt>app/views/terms/terms.haml</tt> or <tt>app/views/terms/terms.erb</tt> file, you will need to edit those files to base your customisations on the new <tt>default.haml</tt> file.<br />
<br />
Have a look at the [https://github.com/diaspora/diaspora/blob/master/Changelog.md changelog] for the full list of changes.<br />
<br />
== Updating diaspora* 0.4 to diaspora* 0.5 ==<br />
<br />
Since there are a couple of major changes in upgrading to 0.5 which involve<br />
manual action, we provide a step by step guide. Please ensure to update<br />
to diaspora* 0.4 prior these steps.<br />
<br />
{{Note|This update will take from half an hour up to several hours, as it contains a long running migration, especially on MySQL/MariaDB.}}<br />
<br />
<ol><br />
<li>Make sure you stop your diaspora* pod before proceeding to update your installation. </li><br />
<li>Make a backup of at least the database.</li><br />
<li>If you're on PostgreSQL run <tt>export DB=postgres RAILS_ENV=production</tt>, if you're on MySQL/MariaDB run <tt>export DB=mysql RAILS_ENV=production</tt>.<br />
If you encounter a <code>rake aborted! NameError: uninitialized constant Rack::SSL</code> in the rest of this guide, that means you didn't execute this step correctly.</li><br />
<li>Run <tt>bundle exec sidekiq</tt>, wait 5 minutes and take it down again with <tt>Ctrl+C</tt>.</li><br />
<li>If you modified <tt>public/default.html</tt>, <tt>public/404.html</tt>, <tt>public/422.html</tt> or <tt>public/500.html</tt> take a backup of the changes, they will be gone or overwritten. Run <tt>git checkout Gemfile.lock db/schema.rb public/*.html</tt>. Run <tt>git stash</tt> to preserve any other uncommitted changes. You can later restore stashed changes with <tt>git stash pop</tt>.</li><br />
<li>Update RVM with <tt>rvm get stable</tt>. Install Ruby 2.1 with <tt>rvm install 2.1</tt>.</li><br />
<li>Update diaspora with <tt>git pull; git checkout v0.5.10.2</tt>.</li><br />
<li>Activate the new Ruby with <tt>cd .. && cd -</tt>.</li><br />
<li>Install the latest Bundler with <tt>gem install bundler --version 1.12.6</tt>.</li><br />
<li>Install the dependencies with <tt>bin/bundle install --full-index --without development test</tt>. CAREFUL: Do not run any commands that are suggested at the end of the terminal output; that was already done for you.</li><br />
<li>Verify you didn't run any additional commands already done for you, then run <tt>git status</tt> and delete any untracked files residing in <tt>db/migrate</tt>.</li><br />
<li>Edit <tt>config/initializers/secret_token.rb</tt>, replace <tt>secret_token</tt> with <tt>secret_key_base</tt>:<br />
<syntaxhighlight lang="ruby"><br />
# Old<br />
Rails.application.config.secret_token = '***********...'<br />
<br />
# New<br />
Diaspora::Application.config.secret_key_base = '*************...'<br />
</syntaxhighlight><br />
</li><br />
<li>If you're using MySQL/MariaDB, edit <tt>config/database.yml</tt>: Replace <tt><span style="color: red;">charset: utf8</span></tt> with <tt><span style="color: red;">encoding: utf8mb4</span></tt>, notice how the key changed! Replace <tt><span style="color: red;">collation: utf8_bin</span></tt> with <tt><span style="color: red;">collation: utf8mb4_bin</span></tt>. Have a look at the updated <tt>config/database.yml.example</tt> if you need additional guidance in this step.</li><br />
<li>Run <tt>bin/rake db:migrate</tt>, this will take quite a while but you should occasionally check if it failed and seek assistance if it happened to fail.</li><br />
<li>Run <tt>bin/rake tmp:cache:clear assets:precompile</tt>. This steps now generates <tt>public/404.html</tt>, <tt>public/422.html</tt> and <tt>public/500.html</tt>.</li><br />
<li>You can now start diaspora* again as you're used to.</li><br />
</ol><br />
<br />
You should now compare your <tt>config/diaspora.yml</tt> to the updated <tt>config/diaspora.yml.example</tt>, for example with <tt>vimdiff</tt>. Notable changes, not only limited to the configuration, are:<br />
<br />
* The surrounding markup for the custom splash page changed slightly, please refer to the [https://github.com/diaspora/diaspora/blob/master/Changelog.md#custom-splash-page-changes changelog].<br />
* If you're using Paypal donations, the settings in <tt>diaspora.yml</tt> for it changed, in order to support the unhosted button. Please take a look at the updated <tt>diaspora.yml.example</tt>.<br />
* The default for including jQuery from a CDN has changed. If you want to continue to include it from a CDN, please explicitly set the <tt>jquery_cdn</tt> setting to true in <tt>diaspora.yml</tt>.<br />
* There's a new feature to automatically prune inactive accounts, if you want to enable it please refer to the [https://github.com/diaspora/diaspora/blob/master/Changelog.md#new-maintenance-feature-to-automatically-expire-inactive-accounts changelog].<br />
* There's a new feature to proxy embedded images from external sources through your server, strengthening your users privacy. If you want to enable it please refer to [[Camo]].<br />
* diaspora* 0.5 includes a preview of the new chat feature, if you want to play with it, have a look at [[Vines]]. We do not generally recommend enabling this yet.<br />
<br />
= Post update cleanup =<br />
<br />
After you verified everything is working again you can free some space.<br />
<br />
== Clean old assets ==<br />
<br />
You can delete now unused precompiled assets by running:<br />
<br />
<syntaxhighlight lang="bash"><br />
RAILS_ENV=production bin/rake assets:clean<br />
</syntaxhighlight><br />
<br />
== Clean old gems ==<br />
<br />
You can delete now unused gems by running:<br />
<br />
<syntaxhighlight lang="bash"><br />
bin/bundle clean<br />
</syntaxhighlight><br />
<br />
Make sure to only run this if you're not sharing gems with another application.<br />
<br />
<br />
== Clean old Ruby installations ==<br />
<br />
If you're using RVM or another Ruby version manager, and switched to another Ruby version during the update, you can drop the old Ruby version. For example for RVM with:<br />
<br />
<syntaxhighlight lang="bash"><br />
rvm uninstall 2.1<br />
</syntaxhighlight><br />
<br />
Make sure to only run this if you're not sharing the Ruby installation with another application.<br />
<br />
= Updating a development install =<br />
<br />
Just checkout the develop branch, pull (from upstream), rebundle and migrate the database:<br />
<br />
<syntaxhighlight lang="bash"><br />
cd diaspora<br />
git checkout develop<br />
git pull # Or git pull upstream develop if you cloned from your fork<br />
cd .. && cd -<br />
bin/bundle --full-index<br />
bin/rake db:migrate<br />
</syntaxhighlight><br />
<br />
[[Category:Podmin]]<br />
[[Category:Installation]]</div>Morriscloudhttps://wiki.diasporafoundation.org/wiki/index.php?title=FAQ_for_pod_maintainers&diff=10288FAQ for pod maintainers2018-05-03T23:37:19Z<p>Morriscloud: adding info that must run command in rails gem directory because newbies to rails (e.g., me) don't know that</p>
<hr />
<div>{{Languages}}<br />
We've started adding questions that we're frequently asked to this page, but it doesn't cover everything.<br />
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]].<br />
<br />
== Installation Information ==<br />
<br />
=== What are the general system requirements? ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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. <br />
<br />
=== Do you have a detailed installation guide? ===<br />
<br />
Yes. [[Installation|Check it out!]] It will probably be more up-to-date than this page, in general.<br />
<br />
=== What ports does diaspora* need open for communication? ===<br />
<br />
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.<br />
<br />
=== Can I use Apache to run diaspora*? ===<br />
<br />
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.<br />
<br />
=== Do I need a commercial SSL certificate? / Can I use CAcert certificates? ===<br />
<br />
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 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.<br />
<br />
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.<br />
<br />
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).<br />
<br />
=== How can I run multiple load-balanced instances of diaspora*? ===<br />
<br />
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.<br />
<br />
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).<br />
<br />
=== How can I restart diaspora* without any downtime? ===<br />
<br />
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:<br />
<br />
<syntaxhighlight lang="bash"><br />
RAILS_ENV=production bin/eye restart web<br />
</syntaxhighlight><br />
<br />
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.<br />
<br />
'''Note: this only applies for 0.6.2.0 or newer.'''<br />
<br />
== Troubleshooting ==<br />
<br />
=== I installed diaspora* on my machine, went to <nowiki>http://localhost:3000</nowiki> and signed up. But my friends can't add me! ===<br />
<br />
You set "localhost" as your address, but this is not a valid external address. You first need an<br />
externally accessible address - either a domain name or an IP address. Once you have that<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.<br />
<br />
=== I get 'command not found' if I run bundle install ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== How do I get past the sign-in page to create a new account? ===<br />
<br />
To create a new account, go to <nowiki>http://yourdiasporainstance.tld/users/sign_up</nowiki><br />
(replacing ''yourdiasporainstance.tld'' with the host name of your pod).<br />
<br />
=== I installed diaspora* on my machine, but when I load the site there are no images and the layout looks horrible! ===<br />
<br />
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.<br />
<br />
Also make sure you ran <tt>bundle exec rake assets:precompile</tt>.<br />
<br />
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>.<br />
<br />
=== There are no uploaded images on my pod ===<br />
<br />
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.<br />
<br />
=== I can't find anybody on another pod / I am receiving posts but nobody is receiving mine ===<br />
<br />
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.<br />
<br />
=== I can't find myself from another pod / I am not receiving any posts but everybody is receiving mine ===<br />
<br />
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.<br />
<br />
=== I'm getting the warning "... in production without Sidekiq workers" ===<br />
<br />
[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<br />
<br />
<syntaxhighlight lang="bash"><br />
RAILS_ENV=production bundle exec sidekiq<br />
</syntaxhighlight><br />
<br />
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.<br />
<br />
=== How can I troubleshoot my email configuration? ===<br />
<br />
Use the following command to send an email and get the exceptions right on your console:<br />
<br />
<syntaxhighlight lang="bash"><br />
RAILS_ENV=production bundle exec rails runner 'Notifier.admin("test message", User.where(username: "your_username")).each(&:deliver_now)' <br />
</syntaxhighlight><br />
<br />
Make sure to restart diaspora* once you successfully receive the test message.<br />
<br />
=== I'm getting a 500 error page ===<br />
<br />
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.<br />
<br />
# Make sure you found a reliable way to reproduce the issue.<br />
# Run <tt>tail -f log/production.log</tt>. Watch the output closely as you reproduce the issue.<br />
# 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.<br />
# 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.<br />
<br />
=== I'm getting an error when starting ./script/server ===<br />
<br />
If you get <tt>undefined symbol: sigar_skip_token</tt>, you need to run in your diaspora* server directory:<br />
<br />
<syntaxhighlight lang="bash"><br />
GEM_HOME=vendor/bundle/ruby/2.4.0 gem uninstall sigar<br />
bin/bundle config --local build.sigar "--with-cppflags='-fgnu89-inline'"<br />
</syntaxhighlight><br />
<br />
Afterwards, you need to re-run the <tt>bundle install</tt> command from the installation instructions.<br />
<br />
== Upgrading ==<br />
<br />
=== Is there anything I should do before upgrading my installation? ===<br />
<br />
Yes, read our [[Updating|notes for updating]].<br />
<br />
=== How do I roll back my installation if an update breaks it? ===<br />
<br />
First, try to fix your installation; as always our [[How we communicate#IRC|IRC channel]] should be helpful for getting help with this.<br />
<br />
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.<br />
<br />
You can also checkout a particular version with <tt>git checkout v0.3.0.1</tt>, replacing the version of course.<br />
<br />
After that just follow the same procedure that you would to update your installation.<br />
<br />
=== What if there were database migrations in the code I am rolling back? ===<br />
<br />
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:<br />
<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.<br />
<br />
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.<br />
<br />
== General ==<br />
<br />
=== How can I receive project news? (Updates, Security fixes, ...) ===<br />
<br />
There are multiple channels for important news, including:<br />
<br />
* the official diaspora* project account: hq[at]pod.diaspora.software.<br />
* the official blog at [https://blog.diasporafoundation.org/ blog.diasporafoundation.org], which also offers [https://blog.diasporafoundation.org/feed an Atom feed].<br />
* the [https://discourse.diasporafoundation.org/c/announcements announcements category on Discourse], to which you can subscribe if you have a Discourse account.<br />
<br />
=== Am I alone here? (Establish connections with other pods) ===<br />
<br />
Once you set up your pod, you should add some contacts to start receiving content from other pods.<br />
It's a good idea to add some active diaspora* people to your contacts, because they almost all run their own pod,<br />
so your pod will be known by them and you will be easily findable from there.<br />
<br />
Here is a small list:<br />
<br />
* Official account of the project: hq[at]pod.diaspora.software<br />
* Sean Tilley: deadsuperhero[at]joindiaspora.com<br />
* Jonne Haß: mrzyx[at]social.mrzyx.de<br />
* Florian Staudacher: raven24[at]pod.fulll.name<br />
* Jason Robinson: jaywink[at]iliketoast.net<br />
* The Geraspora team: team[at]pod.geraspora.de<br />
* Waithamai: waithamai[at]pod.geraspora.de<br />
* Fla: fla[at]diaspora-fr.org<br />
<br />
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.<br />
<br />
=== Can I make my pod private/isolated/not communicate with other pods? ===<br />
<br />
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.<br />
<br />
=== Can I modify the code? ===<br />
<br />
Yes. But keep in mind that diaspora* is licensed under the AGPLv3, that means you must<br />
make the currently running source code available to your users. For legal advice beyond<br />
that, please contact your lawyer.<br />
<br />
=== Will a pod eventually receive federated posts that it misses while being offline/down? ===<br />
<br />
Possibly. We retry the delivery three times at one hour intervals.<br />
<br />
=== I've got my pod running. How do I disable outside logins? ===<br />
<br />
Set <tt>settings.enable_registrations</tt> to <tt>false</tt> in your <tt>config/diaspora.yml</tt> and then restart diaspora*.<br />
<br />
=== How do I back up my pod? ===<br />
<br />
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.<br />
<br />
For more details, see [[Pod data backup]].<br />
<br />
=== I am on PPC (e.g. old iMac) and want to use it for serving diaspora*, but there is no ExecJS compatible JS runtime ===<br />
<br />
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.<br />
<br />
=== What are roles and how do I use them? / Make yourself an admin or assign moderators ===<br />
<br />
We have a role system that allows to make some accounts 'special' during runtime, without restarting the server. <br />
<br />
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.<br />
<br />
Start by starting a Rails console, using this commend in directory of your diaspora gem (usually /home/diaspora/diaspora):<br />
<br />
<syntaxhighlight lang="bash"><br />
RAILS_ENV=production bundle exec rails console<br />
</syntaxhighlight><br />
<br />
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:<br />
<br />
<syntaxhighlight lang="ruby"><br />
Role.add_admin User.where(username: "the_username").first.person # Add an user as admin by username<br />
Role.add_admin User.where(email: "the_email").first.person # Add an user as admin by email<br />
Role.add_moderator User.where(username: "the_username").first.person # Add an user as moderator by username<br />
Role.add_moderator User.where(email: "the_email").first.person # Add an user as moderator by email<br />
Role.add_spotlight User.where(username: "the_username").first.person # Add an user to the 'community spotlight' by username<br />
Role.add_spotlight User.where(email: "the_email").first.person # Add an user to the 'community spotlight' by email<br />
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<br />
</syntaxhighlight><br />
<br />
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 /><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.<br />
<br />
=== Followed tags don't work on my pod ===<br />
<br />
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.<br />
<br />
=== My log files are getting huge, help! ===<br />
<br />
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'':<br />
<br />
<pre>/home/diaspora/diaspora/log/*.log {<br />
notifempty<br />
copytruncate<br />
missingok<br />
compress<br />
monthly<br />
delaycompress<br />
rotate 5<br />
}</pre><br />
<br />
Once you've added the file to "/etc/logrotate.d/" run<br />
<br />
<pre>sudo logrotate -f /etc/logrotate.conf</pre><br />
<br />
=== How can I send an email to a user / a group of users? ===<br />
<br />
You need a working email configuration. There are two ways for triggering the emails.<br />
<br />
==== Ruby console ==== <br />
<br />
Fire up your rails console with <code>RAILS_ENV=production bundle exec rails console</code>,<br />
then follow one of the examples or make up your own:<br />
<br />
<syntaxhighlight lang="ruby"><br />
Notifier.admin("important message", User.where(username: "someuser")).each(&:deliver) # Send a message to someuser<br />
Notifier.admin("important message", User.where(username: ["someuser", "anotheruser"])).each(&:deliver) # Send a message to a group of users<br />
Notifier.admin("important message", User.yearly_actives).each(&:deliver) # Send a message to all active users<br />
</syntaxhighlight><br />
<br />
==== Rake task ====<br />
<br />
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:<br />
<br />
1) Users definition<br />
<tt>all</tt> - all users in the database (except deleted)<br />
<tt>active_yearly</tt> - users logged in within the last year<br />
<tt>active_monthly</tt> - users logged in within the last month<br />
<tt>active_halfyear</tt> - users logged in within the last 6 months<br />
2) Path to message file<br />
Give here a path to a HTML or plain text file that contains the message.<br />
3) Subject<br />
A subject for the email<br />
<br />
Example shell command (depending on your environment);<br />
<br />
<syntaxhighlight lang="bash"><br />
RAILS_ENV=production bundle exec rake podmin:admin_mail['active_monthly','./message.html','Important message from pod']<br />
</syntaxhighlight><br />
<br />
Read more about [http://stackoverflow.com/a/825832/1489738 specifying arguments to Rake tasks].<br />
<br />
=== Can I add advertisements to my pod? ===<br />
<br />
Sure, we have no rules that you cannot add advertisements to your diaspora* installation.<br />
<br />
=== How do I define a Terms of Service document for signing up to my pod? ===<br />
<br />
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.<br />
<br />
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>:<br />
<br />
<pre><nowiki><br />
terms:<br />
enable: true<br />
</nowiki></pre><br />
<br />
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.<br />
<br />
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.<br />
<br />
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>.<br />
<br />
There are also two configuration settings to customize the terms (when using the default template). These are optional.<br />
<br />
* <tt>settings.terms.jurisdiction</tt> - indicate here in which country or state any legal disputes are handled.<br />
* <tt>settings.terms.minimum_age</tt> - indicate here if you want to show a minimum required age for creating an account.<br />
<br />
=== How do I modify the pod landing page? ===<br />
<br />
Please see [[Custom_splash_page]].<br />
<br />
== Errors and problems ==<br />
<br />
=== What do I do about all these PGErrors, like disconnects and SSL problems? ===<br />
<br />
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.<br />
<br />
=== My sidekiq is crashing, help! ===<br />
<br />
==== Check your <tt>curl</tt> version ====<br />
<br />
<pre><nowiki><br />
/usr/bin/curl --version<br />
</nowiki></pre><br />
<br />
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].<br />
<br />
==== Check database connection pool ====<br />
<br />
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.<br />
<br />
==== Check for out of open files errors ==== <br />
<br />
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*.<br />
<br />
==== Make sure memory is not running out ====<br />
<br />
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).<br />
<br />
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!<br />
<br />
== What if my question isn't answered here? ==<br />
<br />
Just ask us! Read more on how to do that at [[How we communicate]].<br />
<br />
[[Category:Podmin]]<br />
[[Category:Github transfer done]]</div>Morriscloudhttps://wiki.diasporafoundation.org/wiki/index.php?title=FAQ_for_pod_maintainers&diff=10287FAQ for pod maintainers2018-05-03T23:24:41Z<p>Morriscloud: Rather important to be in the gem directory when trying to open a console; it took me 10 minutes to figure that out just now.</p>
<hr />
<div>{{Languages}}<br />
We've started adding questions that we're frequently asked to this page, but it doesn't cover everything.<br />
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]].<br />
<br />
== Installation Information ==<br />
<br />
=== What are the general system requirements? ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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. <br />
<br />
=== Do you have a detailed installation guide? ===<br />
<br />
Yes. [[Installation|Check it out!]] It will probably be more up-to-date than this page, in general.<br />
<br />
=== What ports does diaspora* need open for communication? ===<br />
<br />
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.<br />
<br />
=== Can I use Apache to run diaspora*? ===<br />
<br />
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.<br />
<br />
=== Do I need a commercial SSL certificate? / Can I use CAcert certificates? ===<br />
<br />
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 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.<br />
<br />
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.<br />
<br />
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).<br />
<br />
=== How can I run multiple load-balanced instances of diaspora*? ===<br />
<br />
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.<br />
<br />
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).<br />
<br />
=== How can I restart diaspora* without any downtime? ===<br />
<br />
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 will spawn a new master process, loading any code/configuration changes that you've made:<br />
<br />
<syntaxhighlight lang="bash"><br />
RAILS_ENV=production bin/eye restart web<br />
</syntaxhighlight><br />
<br />
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.<br />
<br />
'''Note: this only applies for 0.6.2.0 or newer.'''<br />
<br />
== Troubleshooting ==<br />
<br />
=== I installed diaspora* on my machine, went to <nowiki>http://localhost:3000</nowiki> and signed up. But my friends can't add me! ===<br />
<br />
You set "localhost" as your address, but this is not a valid external address. You first need an<br />
externally accessible address - either a domain name or an IP address. Once you have that<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.<br />
<br />
=== I get 'command not found' if I run bundle install ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== How do I get past the sign-in page to create a new account? ===<br />
<br />
To create a new account, go to <nowiki>http://yourdiasporainstance.tld/users/sign_up</nowiki><br />
(replacing ''yourdiasporainstance.tld'' with the host name of your pod).<br />
<br />
=== I installed diaspora* on my machine, but when I load the site there are no images and the layout looks horrible! ===<br />
<br />
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.<br />
<br />
Also make sure you ran <tt>bundle exec rake assets:precompile</tt>.<br />
<br />
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>.<br />
<br />
=== There are no uploaded images on my pod ===<br />
<br />
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.<br />
<br />
=== I can't find anybody on another pod / I am receiving posts but nobody is receiving mine ===<br />
<br />
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.<br />
<br />
=== I can't find myself from another pod / I am not receiving any posts but everybody is receiving mine ===<br />
<br />
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.<br />
<br />
=== I'm getting the warning "... in production without Sidekiq workers" ===<br />
<br />
[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<br />
<br />
<syntaxhighlight lang="bash"><br />
RAILS_ENV=production bundle exec sidekiq<br />
</syntaxhighlight><br />
<br />
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.<br />
<br />
=== How can I troubleshoot my email configuration? ===<br />
<br />
Use the following command to send an email and get the exceptions right on your console:<br />
<br />
<syntaxhighlight lang="bash"><br />
RAILS_ENV=production bundle exec rails runner 'Notifier.admin("test message", User.where(username: "your_username")).each(&:deliver_now)' <br />
</syntaxhighlight><br />
<br />
Make sure to restart diaspora* once you successfully receive the test message.<br />
<br />
=== I'm getting a 500 error page ===<br />
<br />
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.<br />
<br />
# Make sure you found a reliable way to reproduce the issue.<br />
# Run <tt>tail -f log/production.log</tt>. Watch the output closely as you reproduce the issue.<br />
# 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.<br />
# 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.<br />
<br />
=== I'm getting an error when starting ./script/server ===<br />
<br />
If you get <tt>undefined symbol: sigar_skip_token</tt>, you need to run in your diaspora* server directory:<br />
<br />
<syntaxhighlight lang="bash"><br />
GEM_HOME=vendor/bundle/ruby/2.4.0 gem uninstall sigar<br />
bin/bundle config --local build.sigar "--with-cppflags='-fgnu89-inline'"<br />
</syntaxhighlight><br />
<br />
Afterwards, you need to re-run the <tt>bundle install</tt> command from the installation instructions.<br />
<br />
== Upgrading ==<br />
<br />
=== Is there anything I should do before upgrading my installation? ===<br />
<br />
Yes, read our [[Updating|notes for updating]].<br />
<br />
=== How do I roll back my installation if an update breaks it? ===<br />
<br />
First, try to fix your installation; as always our [[How we communicate#IRC|IRC channel]] should be helpful for getting help with this.<br />
<br />
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.<br />
<br />
You can also checkout a particular version with <tt>git checkout v0.3.0.1</tt>, replacing the version of course.<br />
<br />
After that just follow the same procedure that you would to update your installation.<br />
<br />
=== What if there were database migrations in the code I am rolling back? ===<br />
<br />
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:<br />
<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.<br />
<br />
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.<br />
<br />
== General ==<br />
<br />
=== How can I receive project news? (Updates, Security fixes, ...) ===<br />
<br />
There are multiple channels for important news, including:<br />
<br />
* the official diaspora* project account: hq[at]pod.diaspora.software.<br />
* the official blog at [https://blog.diasporafoundation.org/ blog.diasporafoundation.org], which also offers [https://blog.diasporafoundation.org/feed an Atom feed].<br />
* the [https://discourse.diasporafoundation.org/c/announcements announcements category on Discourse], to which you can subscribe if you have a Discourse account.<br />
<br />
=== Am I alone here? (Establish connections with other pods) ===<br />
<br />
Once you set up your pod, you should add some contacts to start receiving content from other pods.<br />
It's a good idea to add some active diaspora* people to your contacts, because they almost all run their own pod,<br />
so your pod will be known by them and you will be easily findable from there.<br />
<br />
Here is a small list:<br />
<br />
* Official account of the project: hq[at]pod.diaspora.software<br />
* Sean Tilley: deadsuperhero[at]joindiaspora.com<br />
* Jonne Haß: mrzyx[at]social.mrzyx.de<br />
* Florian Staudacher: raven24[at]pod.fulll.name<br />
* Jason Robinson: jaywink[at]iliketoast.net<br />
* The Geraspora team: team[at]pod.geraspora.de<br />
* Waithamai: waithamai[at]pod.geraspora.de<br />
* Fla: fla[at]diaspora-fr.org<br />
<br />
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.<br />
<br />
=== Can I make my pod private/isolated/not communicate with other pods? ===<br />
<br />
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.<br />
<br />
=== Can I modify the code? ===<br />
<br />
Yes. But keep in mind that diaspora* is licensed under the AGPLv3, that means you must<br />
make the currently running source code available to your users. For legal advice beyond<br />
that, please contact your lawyer.<br />
<br />
=== Will a pod eventually receive federated posts that it misses while being offline/down? ===<br />
<br />
Possibly. We retry the delivery three times at one hour intervals.<br />
<br />
=== I've got my pod running. How do I disable outside logins? ===<br />
<br />
Set <tt>settings.enable_registrations</tt> to <tt>false</tt> in your <tt>config/diaspora.yml</tt> and then restart diaspora*.<br />
<br />
=== How do I back up my pod? ===<br />
<br />
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.<br />
<br />
For more details, see [[Pod data backup]].<br />
<br />
=== I am on PPC (e.g. old iMac) and want to use it for serving diaspora*, but there is no ExecJS compatible JS runtime ===<br />
<br />
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.<br />
<br />
=== What are roles and how do I use them? / Make yourself an admin or assign moderators ===<br />
<br />
We have a role system that allows to make some accounts 'special' during runtime, without restarting the server. <br />
<br />
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.<br />
<br />
Start by starting a Rails console, using this commend in directory of your diaspora gem (usually /home/diaspora/diaspora):<br />
<br />
<syntaxhighlight lang="bash"><br />
RAILS_ENV=production bundle exec rails console<br />
</syntaxhighlight><br />
<br />
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:<br />
<br />
<syntaxhighlight lang="ruby"><br />
Role.add_admin User.where(username: "the_username").first.person # Add an user as admin by username<br />
Role.add_admin User.where(email: "the_email").first.person # Add an user as admin by email<br />
Role.add_moderator User.where(username: "the_username").first.person # Add an user as moderator by username<br />
Role.add_moderator User.where(email: "the_email").first.person # Add an user as moderator by email<br />
Role.add_spotlight User.where(username: "the_username").first.person # Add an user to the 'community spotlight' by username<br />
Role.add_spotlight User.where(email: "the_email").first.person # Add an user to the 'community spotlight' by email<br />
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<br />
</syntaxhighlight><br />
<br />
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 /><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.<br />
<br />
=== Followed tags don't work on my pod ===<br />
<br />
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.<br />
<br />
=== My log files are getting huge, help! ===<br />
<br />
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'':<br />
<br />
<pre>/home/diaspora/diaspora/log/*.log {<br />
notifempty<br />
copytruncate<br />
missingok<br />
compress<br />
monthly<br />
delaycompress<br />
rotate 5<br />
}</pre><br />
<br />
Once you've added the file to "/etc/logrotate.d/" run<br />
<br />
<pre>sudo logrotate -f /etc/logrotate.conf</pre><br />
<br />
=== How can I send an email to a user / a group of users? ===<br />
<br />
You need a working email configuration. There are two ways for triggering the emails.<br />
<br />
==== Ruby console ==== <br />
<br />
Fire up your rails console with <code>RAILS_ENV=production bundle exec rails console</code>,<br />
then follow one of the examples or make up your own:<br />
<br />
<syntaxhighlight lang="ruby"><br />
Notifier.admin("important message", User.where(username: "someuser")).each(&:deliver) # Send a message to someuser<br />
Notifier.admin("important message", User.where(username: ["someuser", "anotheruser"])).each(&:deliver) # Send a message to a group of users<br />
Notifier.admin("important message", User.yearly_actives).each(&:deliver) # Send a message to all active users<br />
</syntaxhighlight><br />
<br />
==== Rake task ====<br />
<br />
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:<br />
<br />
1) Users definition<br />
<tt>all</tt> - all users in the database (except deleted)<br />
<tt>active_yearly</tt> - users logged in within the last year<br />
<tt>active_monthly</tt> - users logged in within the last month<br />
<tt>active_halfyear</tt> - users logged in within the last 6 months<br />
2) Path to message file<br />
Give here a path to a HTML or plain text file that contains the message.<br />
3) Subject<br />
A subject for the email<br />
<br />
Example shell command (depending on your environment);<br />
<br />
<syntaxhighlight lang="bash"><br />
RAILS_ENV=production bundle exec rake podmin:admin_mail['active_monthly','./message.html','Important message from pod']<br />
</syntaxhighlight><br />
<br />
Read more about [http://stackoverflow.com/a/825832/1489738 specifying arguments to Rake tasks].<br />
<br />
=== Can I add advertisements to my pod? ===<br />
<br />
Sure, we have no rules that you cannot add advertisements to your diaspora* installation.<br />
<br />
=== How do I define a Terms of Service document for signing up to my pod? ===<br />
<br />
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.<br />
<br />
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>:<br />
<br />
<pre><nowiki><br />
terms:<br />
enable: true<br />
</nowiki></pre><br />
<br />
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.<br />
<br />
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.<br />
<br />
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>.<br />
<br />
There are also two configuration settings to customize the terms (when using the default template). These are optional.<br />
<br />
* <tt>settings.terms.jurisdiction</tt> - indicate here in which country or state any legal disputes are handled.<br />
* <tt>settings.terms.minimum_age</tt> - indicate here if you want to show a minimum required age for creating an account.<br />
<br />
=== How do I modify the pod landing page? ===<br />
<br />
Please see [[Custom_splash_page]].<br />
<br />
== Errors and problems ==<br />
<br />
=== What do I do about all these PGErrors, like disconnects and SSL problems? ===<br />
<br />
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.<br />
<br />
=== My sidekiq is crashing, help! ===<br />
<br />
==== Check your <tt>curl</tt> version ====<br />
<br />
<pre><nowiki><br />
/usr/bin/curl --version<br />
</nowiki></pre><br />
<br />
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].<br />
<br />
==== Check database connection pool ====<br />
<br />
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.<br />
<br />
==== Check for out of open files errors ==== <br />
<br />
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*.<br />
<br />
==== Make sure memory is not running out ====<br />
<br />
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).<br />
<br />
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!<br />
<br />
== What if my question isn't answered here? ==<br />
<br />
Just ask us! Read more on how to do that at [[How we communicate]].<br />
<br />
[[Category:Podmin]]<br />
[[Category:Github transfer done]]</div>Morriscloudhttps://wiki.diasporafoundation.org/wiki/index.php?title=Template:Installation/Common&diff=10276Template:Installation/Common2018-04-14T06:07:53Z<p>Morriscloud: minor word change</p>
<hr />
<div>== Get the source ==<br />
<br />
It's time to download diaspora*! As your diaspora user run:<br />
<br />
{{#tag:syntaxhighlight|<br />
cd ~<br />
git clone {{#ifeq: {{#var:mode}}|production|-b master|}} https://github.com/diaspora/diaspora.git<br />
cd diaspora<br />
|lang=bash}}<br />
<br />
Don't miss the <tt>cd diaspora</tt>, all coming commands expect to be run from that directory!<br />
<br />
== Configuration ==<br />
<br />
=== Copy files ===<br />
<br />
{{#tag:syntaxhighlight|<br />
cp config/database.yml.example config/database.yml<br />
cp config/diaspora.yml.example config/diaspora.yml<br />
|lang=bash}}<br />
<br />
{{#ifeq: {{#var:mode}}|production|{{Template:Installation/Configuration}}<br />
{{Installation/Reverse_proxy}}|}}<br />
== Bundle ==<br />
<br />
It's time to install the Ruby libraries required by diaspora*:<br />
<br />
{{#tag:syntaxhighlight|<br />
gem install bundler<br />
script/configure_bundler<br />
{{#ifeq:{{#var:dist}}{{#var:version}}{{#varDB}}|CentOS6postgres|bin/bundle config --local build.pg '--with-pg-config=/usr/pgsql-<version>/bin/pg_config'<br />
<nowiki/>}}bin/bundle install --full-index<br />
|lang=bash}}<br />
<br />
This takes quite a while. When it's finished, you should see a message similar to: <tt>Bundle complete! 137 Gemfile dependencies, 259 gems now installed.</tt> If that's not the case, you should seek for help on the mailing list or the IRC channel.<br />
<br />
Running the manual <tt>gem install</tt> command shown in the error message can sometimes show a clearer error message if the <tt>bundle</tt> command fails.<br />
<br />
== Database setup ==<br />
<br />
Double check your <tt>config/database.yml</tt> looks right and run:<br />
<br />
{{#tag:syntaxhighlight|<br />
{{#var:env_string}}bin/rake db:create db:migrate<br />
|lang=bash}}<br />
{{#ifeq: {{#var:mode}}|production|{{Installation/Assets}}|}}<br />
== Start diaspora* ==<br />
<br />
It's time to start diaspora*:<br />
<br />
{{#tag:syntaxhighlight|<br />
./script/server<br />
|lang="bash"}}<br />
<br />
{{#ifeq: {{#var:mode}}|production|In the most simple case you want to do this inside a [http://www.gnu.org/software/screen/ screen] or [http://tmux.sourceforge.net/ tmux] session from which you can safely detach.|}}<br />
<br />
Your diaspora server is now running, either on a unix socket (current default) or on http port 3000. The listening method can be configured in diaspora.yml, search for '3000' or 'listen' to find the correct line. <br />
<br />
You will likely need to install a reverse proxy ([https://gist.github.com/jhass/719014 example on github] for apache2) in order to get it to be served publicly. If you are new to running rails applications you may find the [[diaspora components]] page helpful for orientation.<br />
<br />
== Backup ==<br />
{{Serious|1=You have to do backups of your pod data. If you lose your data, you won't be able to use the combination of your old username and old domain ever again. Make sure to store the backups on a different server, or at least on a different hard drive.<br />For details on how to do backups, see [[Pod data backup]].}}<br />
<br />
== Further reading ==<br />
<br />
* [[Diasporas components explained]]<br />
* Is there anybody out there? [[FAQ_for_pod_maintainers#Am_I_alone_here.3F_.28Establish_connections_with_other_pods.29|Establish connections with other pods]]<br />
* [[FAQ_for_pod_maintainers#What_are_roles_and_how_do_I_use_them.3F_.2F_Make_yourself_an_admin_or_assign_moderators|Make yourself an admin]]<br />
* [[Updating#{{#switch: {{#var:mode}}|production=Updating_a_production_install|development=Updating_a_development_install}}|Updating Diaspora]]<br />
{{#ifeq: {{#var:mode}}|production|* [[Integrating other social networks]]<br />
* [[Alternative startup methods]] (Passenger, Init script, Daemontools, ...)<br />
* [[Asset hosting on S3]]|* [[Getting Started With Contributing]]|}}<br />
<br />
<includeonly><br />
[[Category:Installation]]<br />
[[Category:Podmin]]<br />
</includeonly><br />
<noinclude>[[Category:Installation-Templates]]</noinclude></div>Morriscloudhttps://wiki.diasporafoundation.org/wiki/index.php?title=Template:Installation/Common&diff=10275Template:Installation/Common2018-04-14T06:06:43Z<p>Morriscloud: Adding a few lines for people like me who are new to rails and are like "how does this work with my webserver?"</p>
<hr />
<div>== Get the source ==<br />
<br />
It's time to download diaspora*! As your diaspora user run:<br />
<br />
{{#tag:syntaxhighlight|<br />
cd ~<br />
git clone {{#ifeq: {{#var:mode}}|production|-b master|}} https://github.com/diaspora/diaspora.git<br />
cd diaspora<br />
|lang=bash}}<br />
<br />
Don't miss the <tt>cd diaspora</tt>, all coming commands expect to be run from that directory!<br />
<br />
== Configuration ==<br />
<br />
=== Copy files ===<br />
<br />
{{#tag:syntaxhighlight|<br />
cp config/database.yml.example config/database.yml<br />
cp config/diaspora.yml.example config/diaspora.yml<br />
|lang=bash}}<br />
<br />
{{#ifeq: {{#var:mode}}|production|{{Template:Installation/Configuration}}<br />
{{Installation/Reverse_proxy}}|}}<br />
== Bundle ==<br />
<br />
It's time to install the Ruby libraries required by diaspora*:<br />
<br />
{{#tag:syntaxhighlight|<br />
gem install bundler<br />
script/configure_bundler<br />
{{#ifeq:{{#var:dist}}{{#var:version}}{{#varDB}}|CentOS6postgres|bin/bundle config --local build.pg '--with-pg-config=/usr/pgsql-<version>/bin/pg_config'<br />
<nowiki/>}}bin/bundle install --full-index<br />
|lang=bash}}<br />
<br />
This takes quite a while. When it's finished, you should see a message similar to: <tt>Bundle complete! 137 Gemfile dependencies, 259 gems now installed.</tt> If that's not the case, you should seek for help on the mailing list or the IRC channel.<br />
<br />
Running the manual <tt>gem install</tt> command shown in the error message can sometimes show a clearer error message if the <tt>bundle</tt> command fails.<br />
<br />
== Database setup ==<br />
<br />
Double check your <tt>config/database.yml</tt> looks right and run:<br />
<br />
{{#tag:syntaxhighlight|<br />
{{#var:env_string}}bin/rake db:create db:migrate<br />
|lang=bash}}<br />
{{#ifeq: {{#var:mode}}|production|{{Installation/Assets}}|}}<br />
== Start diaspora* ==<br />
<br />
It's time to start diaspora*:<br />
<br />
{{#tag:syntaxhighlight|<br />
./script/server<br />
|lang="bash"}}<br />
<br />
{{#ifeq: {{#var:mode}}|production|In the most simple case you want to do this inside a [http://www.gnu.org/software/screen/ screen] or [http://tmux.sourceforge.net/ tmux] session from which you can safely detach.|}}<br />
<br />
Your diaspora server is now running, either on a unix socket (current default) or on http port 3000. The listening method can be configured in diaspora.yml, search for '3000' or 'listen' to find the correct line. <br />
<br />
You will likely need to install a reverse proxy ([https://gist.github.com/jhass/719014 example on github] on apache2) in order to get it to be served publicly. If you are new to running rails applications you may find the [[diaspora components]] page helpful for orientation.<br />
<br />
== Backup ==<br />
{{Serious|1=You have to do backups of your pod data. If you lose your data, you won't be able to use the combination of your old username and old domain ever again. Make sure to store the backups on a different server, or at least on a different hard drive.<br />For details on how to do backups, see [[Pod data backup]].}}<br />
<br />
== Further reading ==<br />
<br />
* [[Diasporas components explained]]<br />
* Is there anybody out there? [[FAQ_for_pod_maintainers#Am_I_alone_here.3F_.28Establish_connections_with_other_pods.29|Establish connections with other pods]]<br />
* [[FAQ_for_pod_maintainers#What_are_roles_and_how_do_I_use_them.3F_.2F_Make_yourself_an_admin_or_assign_moderators|Make yourself an admin]]<br />
* [[Updating#{{#switch: {{#var:mode}}|production=Updating_a_production_install|development=Updating_a_development_install}}|Updating Diaspora]]<br />
{{#ifeq: {{#var:mode}}|production|* [[Integrating other social networks]]<br />
* [[Alternative startup methods]] (Passenger, Init script, Daemontools, ...)<br />
* [[Asset hosting on S3]]|* [[Getting Started With Contributing]]|}}<br />
<br />
<includeonly><br />
[[Category:Installation]]<br />
[[Category:Podmin]]<br />
</includeonly><br />
<noinclude>[[Category:Installation-Templates]]</noinclude></div>Morriscloudhttps://wiki.diasporafoundation.org/wiki/index.php?title=Talk:Diasporas_components_explained&diff=10274Talk:Diasporas components explained2018-04-14T05:19:16Z<p>Morriscloud: created with note advising against deletion</p>
<hr />
<div>This page currently has a note indicating it is possibly slated for deletion. I would recommend against deleting this page. As a linux-experienced but new-to-rails person I needed the "application server" section of this page to get oriented on what to do after completing the ubuntu diaspora installation instructions. [[User:Morriscloud|Morriscloud]] ([[User talk:Morriscloud|talk]]) 05:19, 14 April 2018 (UTC)</div>Morriscloudhttps://wiki.diasporafoundation.org/wiki/index.php?title=Template:Installation/RVM&diff=10273Template:Installation/RVM2018-04-14T02:12:01Z<p>Morriscloud: running source .bashrc easier than close/open usually, no need to confuse with two possibilities</p>
<hr />
<div>{{#vardefine:rubyversion|2.4}}<br />
<br />
=== RVM ===<br />
<br />
We recommend using [http://rvm.io Ruby Version Manager] it will ensure you're always on the currently recommended Ruby version and cleanly separate your diaspora* installation from all other Ruby applications on your machine. If you opt for not using it ensure your Ruby version is at least 2.3.0, prior versions are incompatible. We currently recommend using the latest release of the {{#var:rubyversion}} series.<br />
<br />
==== Install RVM ====<br />
<br />
As the user you want to run diaspora* under, that is '''not''' as root, run:<br />
<br />
<syntaxhighlight lang="bash"><br />
curl -L https://s.diaspora.software/1t | bash<br />
</syntaxhighlight><br />
<br />
and follow the instructions. If you get GPG signature problems, follow the instructions printed by the command. Running the 'gpg --recv-keys' command with 'sudo' should not be necessary. If those commands give you permission denied errors, change them to 640 for all files and 750 for all folders in the <tt>.gnupg</tt> folder.<br />
<br />
==== Set up RVM ====<br />
<br />
Ensure the following line is in your <tt>~/.bashrc</tt>:<br />
<br />
<syntaxhighlight lang="bash"><br />
[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"<br />
</syntaxhighlight><br />
<br />
Now run <tt>source ~/.bashrc</tt> in the terminal(s) you are using for this guide.<br />
<br />
If you '''don't''' have sudo installed or your current user doesn't have the privileges to execute it, run:<br />
<syntaxhighlight lang="bash"><br />
rvm autolibs read-fail<br />
</syntaxhighlight><br />
<br />
The next command will check if all dependencies to build Ruby are installed. If these are not met, you will see a list of packages preceded by "<tt>Missing required packages:</tt>". As root install all the packages listed there for your OS. Then rerun the install command.<br />
<br />
Ensure the currently recommend version of Ruby is installed:<br />
<br />
{{#tag:syntaxhighlight|<br />
rvm install {{#var:rubyversion}}<br />
|lang=bash}}<br />
<br />
<noinclude>[[Category:Installation-Templates]]</noinclude></div>Morriscloudhttps://wiki.diasporafoundation.org/wiki/index.php?title=Template:Installation/Preparation/Ubuntu&diff=10272Template:Installation/Preparation/Ubuntu2018-04-14T02:09:58Z<p>Morriscloud: There are sudo commands in this guide, and there doesn't seem to be a reason to have the diaspora user be a sudoer</p>
<hr />
<div>{{#vardefine:version_number|{{#switch: {{#var:version}}|Precise=12.04|Trusty=14.04|Xenia=16.04}}}}<br />
=== Install packages ===<br />
<br />
Run:<br />
{{#tag:syntaxhighlight|<br />
sudo apt-get update<br />
sudo apt-get install build-essential git curl imagemagick libmagickwand-dev nodejs redis-server libssl-dev libcurl4-openssl-dev libxml2-dev libxslt1-dev {{#ifeq: {{#var:version}}|Precise||libgmp-dev <nowiki/>}}{{#switch: {{#var:DB}}|mysql=libmysqlclient-dev|postgres=libpq-dev|mariadb=libmysqlclient-dev}}{{#ifeq: {{#var:mode}}|development|<nowiki/> cmake|}}<br />
|lang=bash}}<br />
{{#ifeq: {{#var:version}}|Precise|<br />
{{Template:Installation/Ubuntu/CurlPPA}}<br />
{{Template:Installation/Ubuntu/RedisPPA}}<br />
}}<br />
<br />
If you receive errors about packages that could not be found, make sure that <tt>universe</tt> is enabled in <tt>/etc/apt/sources.list</tt> after the entry for <tt>trusty-updates</tt>.<br />
<br />
=== Install the database ===<br />
Skip this step if you already have one.<br />
<br />
See the [https://help.ubuntu.com/{{#var:version_number}}/serverguide/{{#switch: {{#var:DB}}|mariadb=mysql|mysql=mysql|postgres=postgresql}}.html Ubuntu server guide].<br />
{{#ifeq: {{#var:mode}}|production|<br />
=== Creating a user for Diaspora ===<br />
<br />
{{#tag: syntaxhighlight|<br />
sudo adduser --disabled-login diaspora<br />
sudo -iu diaspora<br />
|lang="bash"}}<br />
<br />
The rest of the guide, except for sudo commands, should be performed as the diaspora user. <br />
}}<br />
<br />
=== Removing packaged version of RVM ===<br />
<br />
If you installed RVM via the package manager, we recommend to remove it. See [http://stackoverflow.com/questions/9056008/installed-ruby-1-9-3-with-rvm-but-command-line-doesnt-show-ruby-v/9056395#9056395 this StackOverflow answer] for some tips on how to do that and then continue with the installation instructions below.<br />
<noinclude><br />
[[Category:Installation-Templates]]<br />
</noinclude></div>Morriscloudhttps://wiki.diasporafoundation.org/wiki/index.php?title=Template:Installation/RVM&diff=10268Template:Installation/RVM2018-04-12T22:53:20Z<p>Morriscloud: sudo doesn't work here because diapora not in sudoers</p>
<hr />
<div>{{#vardefine:rubyversion|2.4}}<br />
<br />
=== RVM ===<br />
<br />
We recommend using [http://rvm.io Ruby Version Manager] it will ensure you're always on the currently recommended Ruby version and cleanly separate your diaspora* installation from all other Ruby applications on your machine. If you opt for not using it ensure your Ruby version is at least 2.3.0, prior versions are incompatible. We currently recommend using the latest release of the {{#var:rubyversion}} series.<br />
<br />
==== Install RVM ====<br />
<br />
As the user you want to run diaspora* under, that is '''not''' as root, run:<br />
<br />
<syntaxhighlight lang="bash"><br />
curl -L https://s.diaspora.software/1t | bash<br />
</syntaxhighlight><br />
<br />
and follow the instructions. If you get GPG signature problems, follow the instructions printed by the command, except if running the 'gpg --recv-keys' command you should omit the preceding 'sudo' since it is not necessary and we have not added the diaspora user to the sudoers list. If those commands give you permission denied errors, change them to 640 for all files and 750 for all folders in the <tt>.gnupg</tt> folder.<br />
<br />
==== Set up RVM ====<br />
<br />
Ensure the following line is in your <tt>~/.bashrc</tt>:<br />
<br />
<syntaxhighlight lang="bash"><br />
[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"<br />
</syntaxhighlight><br />
<br />
Now close all your terminals and open a new one or run <tt>source ~/.bashrc</tt> in all of them.<br />
<br />
If you '''don't''' have sudo installed or your current user doesn't have the privileges to execute it, run:<br />
<syntaxhighlight lang="bash"><br />
rvm autolibs read-fail<br />
</syntaxhighlight><br />
<br />
The next command will check if all dependencies to build Ruby are installed. If these are not met, you will see a list of packages preceded by "<tt>Missing required packages:</tt>". As root install all the packages listed there for your OS. Then rerun the install command.<br />
<br />
Ensure the currently recommend version of Ruby is installed:<br />
<br />
{{#tag:syntaxhighlight|<br />
rvm install {{#var:rubyversion}}<br />
|lang=bash}}<br />
<br />
<noinclude>[[Category:Installation-Templates]]</noinclude></div>Morriscloudhttps://wiki.diasporafoundation.org/wiki/index.php?title=Template:Installation/Preparation/Ubuntu&diff=10269Template:Installation/Preparation/Ubuntu2018-04-12T22:50:53Z<p>Morriscloud: I had to add universe to trusty-updates to get this list of apt-installs to work</p>
<hr />
<div>{{#vardefine:version_number|{{#switch: {{#var:version}}|Precise=12.04|Trusty=14.04|Xenia=16.04}}}}<br />
=== Install packages ===<br />
<br />
Run:<br />
{{#tag:syntaxhighlight|<br />
sudo apt-get update<br />
sudo apt-get install build-essential git curl imagemagick libmagickwand-dev nodejs redis-server libssl-dev libcurl4-openssl-dev libxml2-dev libxslt1-dev {{#ifeq: {{#var:version}}|Precise||libgmp-dev <nowiki/>}}{{#switch: {{#var:DB}}|mysql=libmysqlclient-dev|postgres=libpq-dev|mariadb=libmysqlclient-dev}}{{#ifeq: {{#var:mode}}|development|<nowiki/> cmake|}}<br />
|lang=bash}}<br />
{{#ifeq: {{#var:version}}|Precise|<br />
{{Template:Installation/Ubuntu/CurlPPA}}<br />
{{Template:Installation/Ubuntu/RedisPPA}}<br />
}}<br />
<br />
If you get package errors, you may need to add "universe" to /etc/apt/sources.list after the entry for trusty-updates.<br />
<br />
=== Install the database ===<br />
Skip this step if you already have one.<br />
<br />
See the [https://help.ubuntu.com/{{#var:version_number}}/serverguide/{{#switch: {{#var:DB}}|mariadb=mysql|mysql=mysql|postgres=postgresql}}.html Ubuntu server guide].<br />
{{#ifeq: {{#var:mode}}|production|<br />
=== Creating a user for Diaspora ===<br />
<br />
{{#tag: syntaxhighlight|<br />
sudo adduser --disabled-login diaspora<br />
sudo -iu diaspora<br />
|lang="bash"}}<br />
<br />
The rest of the guide should happen under this user!<br />
}}<br />
=== Removing packaged version of RVM ===<br />
<br />
If you installed RVM via the package manager, we recommend to remove it. See [http://stackoverflow.com/questions/9056008/installed-ruby-1-9-3-with-rvm-but-command-line-doesnt-show-ruby-v/9056395#9056395 this StackOverflow answer] for some tips on how to do that and then continue with the installation instructions below.<br />
<noinclude><br />
[[Category:Installation-Templates]]<br />
</noinclude></div>Morriscloud