FAQ pour mainteneurs de pod

De Traduction du Wiki diaspora* (non officiel)
Aller à la navigation Aller à la recherche
Ambox rewrite.png »» Traduction en cours
Cet article est en cours de traduction. Vous trouverez les informations complètes en anglais à la page correspondante du du wiki officiel
Date : Le jeudi 7 octobre 2021


Nous avons commencé à ajouter à cette page les questions qui nous sont fréquemment posées, mais elle ne couvre pas tout. Si vous avez d'autres questions, le meilleur moyen d'obtenir une réponse rapidement est de nous rendre visite sur notre canal IRC.

Informations sur l'installation

Quelles sont les exigences générales du système ?

L'exécution de diaspora* nécessite des ressources qui dépendent du nombre d'utilisateurs qui utilisent l'installation et du trafic que l'installation reçoit des autres pods. En général, il est recommandé de disposer d'au moins 1 Gig de mémoire, même pour les petites instances.

Pour les pods avec plus d'utilisateurs, la quantité de mémoire disponible pour diaspora* et les tâches d'arrière-plan dont il a besoin est plus élevée en fonction du nombre d'utilisateurs qui utilisent activement l'instance. Au fur et à mesure que la base de données grandit, il faudra pus mémoire pour compenser.

Étant donné que diaspora* nécessite l'installation d'un grand nombre de composants différents, les serveurs d'hébergement mutualisé ne sont généralement pas suffisants. N'importe quel VPS ou serveur dédié avec une quantité appropriée de mémoire suffira.

Avez-vous un guide d'installation détaillé ?

Oui. Consultez-le !. Il sera probablement plus à jour que cette page, en général.

Quels sont les ports que la diaspora* doit ouvrir pour communiquer ?

Puisque nous recommandons de fonctionner en HTTPS, vous ne devez ouvrir que le port standard pour cela : 443. Vous devriez avoir un proxy inverse qui écoute à cet endroit et qui transmet les demandes au serveur d'application que diaspora* démarre, sur le port 3000 par défaut. Vous pouvez utiliser votre Nginx ou Apache existant pour faire cela. Bien que nous ne le recommandions pas, vous pouvez aussi utiliser le HTTP avec son port standard 80. Ne laissez jamais diaspora* écouter sur ces ports directement. Vous n'avez pas besoin d'ouvrir le port du serveur d'application, 3000, il est pour la communication interne seulement.

Puis-je utiliser Apache pour faire fonctionner diaspora* ?

Oui : diaspora* est une application Rails standard, donc vous pouvez l'exécuter avec Passenger, ou en faisant la configuration la plus commune qui est d'utiliser une installation de proxy inverse. Consultez cet exemple pour savoir comment configurer cette installation.

Ai-je besoin d'un certificat SSL commercial ? / Puis-je utiliser des certificats CAcert ?

Si vous prévoyez de faire fonctionner votre pod en HTTPS (oui, vous devriez !), alors oui vous aurez besoin d'un certificat SSL commercial valide. Par conception, la fédération ne fonctionnera pas avec les pods qui ont des certificats SSL auto-signés ou invalides installés. Nous faisons ceci pour assurer que tous les utilisateurs dans le réseau sont capables d'utiliser diaspora* sans souffrir des avertissements de sécurité constants liés aux certs 'invalides'.

Pour plus d'informations, voir ces discussions ici et ici.

Il existe des certificats commerciaux gratuits - consultez Let's Encrypt par exemple (acme.sh rend le processus un peu plus simple).

Comment puis-je exécuter plusieurs instances de diaspora* équilibrées en termes de charge ?

Plusieurs instances de diaspora* pour le même "pod" doivent partager les bases de données SQL et Redis, ainsi que les répertoires "public/uploads". Il existe de nombreuses façons d'accomplir cela, mais le scénario le plus classique serait de configurer tous les nœuds pour qu'ils pointent vers un serveur de base de données central pour MySQL/Postgres et Redis, et de partager le répertoire de téléchargement à partir d'un serveur de fichiers via NFS. Pour éviter les problèmes liés aux changements de schéma, il serait souhaitable que toutes les instances utilisent la même version de diaspora* à tout moment.

L'équilibrage de la charge des instances peut être accompli avec n'importe quel équilibreur de charge TCP qui supporte le collage de session (tel que Apache ou nginx, entre autres).

Comment puis-je redémarrer diaspora* sans temps d'arrêt ?

Par défaut, diaspora* utilise Unicorn pour servir les requêtes. En mode production, il est possible d'effectuer un redémarrage en douceur du processus Unicorn pour éviter les temps d'arrêt. Cette commande, exécutée dans le répertoire de votre installation diaspora, va engendrer un nouveau processus maître, en chargeant tous les changements de code/configuration que vous avez effectués :

RAILS_ENV=production bin/eye restart web
As the new master spawns workers, old workers finish their requests and are removed from the old master until the last new worker is spawned, at which time the old master is shut down.

Pour donner une idée d'ensemble mais, la traduction n'est pas bonne : Au fur et à mesure que la nouvelle installation engendre des données, l'ancienne termine de répondre à ses requêtes. À la fin du processus, l'ancienne installation est fermée.

Note : ceci ne s'applique qu'aux versions 0.6.2.0 ou plus récentes.

Dépannage

J'ai installé diaspora* sur ma machine, je suis allé sur http://localhost:3000 et je me suis inscrit. Mais mes amis ne peuvent pas m'ajouter !

Vous avez défini "localhost" comme adresse, mais ce n'est pas une adresse externe valide. Vous avez d'abord besoin d'une adresse accessible de l'extérieur - soit un nom de domaine, soit une adresse IP. Une fois que cela fonctionne, vous devez vider votre base de données (`$ bundle exec rake db:drop db:create db:migrate`) et vous réenregistrer, en passant par l'URL externe. Notez que si votre adresse accessible de l'extérieur change, vous devez recommencer. diaspora* est conçu comme une application serveur pour fonctionner jour et nuit.

J'obtiens 'command not found' si je lance bundle install

Assurez-vous que RVM est chargé et que la bonne version de Ruby et gemset sont activés. La sortie des commandes rvm info et gem env peut être utile à cet égard. Exécutez gem install bundler pour vous assurer que bundler est effectivement installé.

Si vous n'utilisez pas RVM, un problème courant est que les distributions basées sur Debian, y compris Ubuntu, n'ajoutent pas les exécutables gem au chemin de recherche. Consultez la variable d'environnement PATH pour savoir comment résoudre ce problème.

Comment passer la page de connexion pour créer un nouveau compte ?

Pour créer un nouveau compte, allez sur http://yourdiasporainstance.tld/users/sign_up (en remplaçant yourdiasporainstance.tld par le nom d'hôte de votre pod).

J'ai installé diaspora* sur ma machine, mais lorsque je charge le site, il n'y a pas d'images et la mise en page est horrible !

Vous avez très probablement démarré diaspora* en mode production et accédé au serveur d'application directement et non par le biais de votre proxy inverse. En mode production, nous nous attendons à ce que votre proxy inverse serve le contenu statique, car il fait le travail bien mieux que tout autre. Si vous avez accédé à diaspora* par le biais d'un proxy inverse, assurez-vous qu'il n'a aucun problème de configuration, que la racine du document est le public/ et qu'il est configuré pour vérifier si les fichiers demandés s'y trouvent avant de diriger la demande vers le serveur d'application.

Assurez-vous également que vous avez exécuté bundle exec rake assets:precompile.

Si vous devez contourner cette exigence, vous pouvez mettre environnement.assets.serve à true dans config/diaspora.yml.

Il n'y a pas d'images téléchargées sur mon pod

Assurez-vous d'abord que les autres contenus statiques fonctionnent, comme décrit dans la section précédente. Nous intégrons les images téléchargées avec leur URL complète, cela a à voir avec la façon dont diaspora* s'assure que vos images peuvent être vues par les utilisateurs sur d'autres pods. Un problème commun ici est que environnement.url dans config/diaspora.yml, à partir duquel diaspora* construit l'URL complète, est défini à une valeur incorrecte.

Je ne trouve personne sur un autre pod / Je reçois des messages mais personne ne reçoit les miens

Si vous avez des problèmes, assurez-vous de rechercher les personnes par leur ID diaspora* complet. Vérifiez que Sidekiq est en cours d'exécution. Contrôlez les messages d'erreur dans la file d'attente de relance de Sidekiq. Vérifiez que le paramètre environnement.certificate_authorities est correct.

Je n'arrive pas à me retrouver dans un autre pod / Je ne reçois aucun message, mais tout le monde reçoit les miens.

Vérifiez que votre configuration SSL est correcte, utilisez sslshopper, ssllabs ou High-Tech Bridge pour tester votre configuration. Assurez-vous qu'il n'y a que du vert, pas de jaune, pas de rouge.

Je reçois l'avertissement "... in production without Sidekiq workers"

Sidekiq est le backend que nous utilisons pour traiter les tâches en arrière-plan. Normalement, Sidekiq est lancé en tant que processus distinct, mais dans ce cas, vous avez configuré diaspora* pour qu'il exécute les tâches dans le même processus que l'application. Ceci est normalement utilisé à des fins de développement ou de test, mais s'il est utilisé en production, il peut entraîner des problèmes de performance importants. Ainsi, vous devez toujours exécuter Sidekiq dans son propre processus, en définissant environnement.single_process_mode à false dans votre config/diaspora.yml et en démarrant le processus Sidekiq avec.

RAILS_ENV=production bundle exec sidekiq

Dans le cas où vous utilisez script/server pour démarrer diaspora*, alors vous n'avez pas besoin de démarrer manuellement les workers ! Ceci est déjà fait par le script.

Comment puis-je dépanner ma configuration de messagerie ?

Utilisez la commande suivante pour envoyer un courriel et obtenir les exceptions directement sur votre console :

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

Assurez-vous de redémarrer diaspora* une fois que vous avez reçu avec succès le message de test.

Je reçois une page d'erreur 500

Oh non, vous avez peut-être rencontré un bug dans diaspora* ! Mais cela peut aussi être causé par des problèmes de configuration, comme une page d'accueil mal configurée, une ancienne version de Redis ou un problème de connectivité à la base de données.

  1. Assurez-vous que vous avez trouvé un moyen fiable de reproduire le problème.
  2. Exécutez tail -f log/production.log. Observez attentivement la sortie pendant que vous reproduisez le problème.
  3. Si vous ne parvenez pas à comprendre le message d'erreur, contactez-nous, voir Comment nous communiquons. Dans ce cas, indiquez les étapes que vous avez suivies pour produire la page d'erreur ainsi que la sortie complète du journal lors de la reproduction de l'erreur.
  4. Si l'on vous demande d'ouvrir une issue, allez sur https://github.com/diaspora/diaspora/issues. Encore une fois, assurez-vous de fournir les étapes pour reproduire le problème ainsi que la sortie du journal.

J'obtiens une erreur lors du démarrage de ./script/server

Si vous obtenez undefined symbol : sigar_skip_token, vous devez exécuter dans votre répertoire de serveur diaspora* :

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

Ensuite, vous devez réexécuter la commande bundle install à partir des instructions d'installation.

Mise à jour

Y a-t-il quelque chose que je dois faire avant de mettre à jour mon installation ?

Oui, lisez notre note pour la mise à jour.

Comment faire revenir en arrière mon installation si une mise à jour l'interrompt ?

Tout d'abord, essayez de réparer votre installation ; comme toujours, notre canal IRC devrait être utile pour obtenir de l'aide à ce sujet.

Pour revenir en arrière, il suffit de faire : git checkout refref est l'identifiant du commit auquel il faut revenir. C'est une longue chaîne de lettres et de chiffres. Vous pouvez trouver le ref en faisant un git log, en regardant les dates de commit, et en trouvant où vous étiez avant de faire le pull. Bien entendu, il serait plus sûr de conserver une trace de cette ref avant une mise à jour.

Vous pouvez également extraire une version particulière avec git checkout v0.3.0.1, bien sûr, en remplaçant la version.

Après cela, suivez la même procédure que pour la mise à jour de votre installation.

Que se passe-t-il s'il y a eu des migrations de bases de données dans le code en cas de retour en arrière ?

Vous devez également les restaurer séparément. Vous devez faire cela avant de rétablir le code. Regardez dans le répertoire db/migrate et déterminez quels fichiers sont nouveaux depuis la dernière fois que vous avez effectué votre pull - c'est-à-dire sur quelle migration votre base de données devrait se trouver. Ils sont dans l'ordre de l'horodatage dans ce répertoire. Ensuite, faites : bundle exec rake db:rollback et regardez la sortie. ELle vous dira sur quelle migration vous êtes maintenant. Cette commande recule d'une unité à chaque fois que vous l'exécutez. Exécutez-la jusqu'à ce que vous soyez sur la bonne migration et ensuite restaurez le code comme décrit ci-dessus.

Sachez également que les retours en arrière de bases de données peuvent échouer - Elles dépendent de l'auteur de la migration qui doit écrire le code correct pour une restauration des bases de données. Dans ce cas, il est généralement plus facile de demander de l'aide pour réparer votre configuration que de la réinitialiser.

Général

Comment puis-je recevoir des nouvelles du projet ? (Mises à jour, correctifs de sécurité, ...)

Il existe plusieurs canaux pour les nouvelles importantes, notamment :

Suis-je seul ici ? (Établir des connexions avec les autres pods)

Une fois que vous avez configuré votre pod, vous devez ajouter quelques contacts pour commencer à recevoir du contenu d'autres pods. C'est une bonne idée d'ajouter des personnes actives de la diaspora* à vos contacts, car elles possèdent presque toutes leur propre pod, ainsi, votre pod sera connu d'eux et vous serez facilement accessible à partir de là.

Voici une petite liste :

  • Compte officiel du projet : hq[at]pod.diaspora.software
  • Sean Tilley : deadsuperhero[at]joindiaspora.com
  • Jonne Haß : jhass[at]diaspora.social
  • Jason Robinson : jaywink[at]jasonrobinson.me
  • L'équipe Geraspora : team[at]pod.geraspora.de
  • Waithamai : waithamai[at]pod.geraspora.de
  • Fla : fla[at]diaspora-fr.org

Après avoir ajouté quelques contacts, c'est une bonne idée de publier un message public contenant les balises #newhere et #nouveauici, annonçant votre nouveau pod, pour obtenir encore plus de contacts.

Puis-je rendre mon pod privé/isolé/ne pas communiquer avec les autres pods ?

Non. diaspora* est construit autour de l'idée d'un réseau social distribué. Nous voulons construire un seul réseau, et non pas permettre à des communautés d'intérêt ou à des entreprises d'héberger leur propre réseau social (nous vous accueillons cependant sur diaspora* !). Une grande partie de l'effort de développement est consacrée pour rendre ce réseau unique possible et l'ensemble de l'expérience utilisateur est conçu autour de cela. Ainsi, non seulement d'autres solutions existantes ont souvent des fonctionnalités bien plus adaptées pour ce cas d'utilisation, mais aussi, si nous implémentions un interrupteur pour désactiver la communication avec les autres pods, il y aurait de nombreuses ruptures dans l'interface utilisateur, ce qui entraînerait une mauvaise expérience pour l'utilisateur.

Puis-je modifier le code ?

Oui. Mais gardez à l'esprit que diaspora* est sous licence AGPLv3, ce qui signifie que vous devez mettre le code source en cours d'exécution à la disposition de vos utilisateurs. Pour des conseils juridiques au-delà de cela, veuillez contacter votre avocat.

Un pod recevra-t-il éventuellement les messages fédérés qu'il a manqués pendant qu'il était hors ligne/hors service ?

C'est possible. Nous relançons la transmission trois fois à une heure d'intervalle.

J'ai démarrer mon pod. Comment puis-je désactiver les connexions extérieures ?

Définissez settings.enable_registrations à false dans votre config/diaspora.yml et ensuite redémarrez diaspora*.

Comment puis-je sauvegarder mon pod ?

Vous devez faire des sauvegardes de toutes les données utilisateur, c'est-à-dire de toute la base de données et des images téléchargées. Pour les images faites juste des copies du répertoire public/uploads. Ensuite, il suffit de sauvegarder toutes les bases de données Diaspora_ de votre serveur de base de données. Une recherche sur le web devrait vous donner les informations dont vous avez besoin sur la façon de le faire. Assurez-vous de stocker les sauvegardes sur un serveur différent, ou au moins sur un disque dur différent.

Pour plus de détails, voir Sauvegarde des données du pod.

Je suis sur PPC (par exemple un vieil iMac) et je veux l'utiliser pour servir diaspora*, mais il n'y a pas de runtime JS compatible avec ExecJS.

Une chose que vous pourriez faire, en supposant que vous avez un autre PC qui exécutera Node : Pré-compiler vos actifs sur cette machine (en utilisant bundle exec rake assets:precompile) et ensuite les vérifier dans git avant de les déployer sur la boîte PPC, ou simplement copier le contenu de public/assets. Le runtime Javascript n'est vraiment nécessaire que pour la précompilation des actifs et ne devrait pas être chargé du tout dans l'environnement de production réel. Vous devrez peut-être utiliser git add public/assets -f pour forcer git à les enregistrer, car je pense que ce répertoire est dans .gitignore.

Que sont les rôles et comment les utiliser ? / Faites-vous administrateur ou assignez des modérateurs

Bookmark.png »» Note
Depuis diaspora* 0.7.8.0, vous pouvez ajouter des rôles d'administrateur et de modérateur dans le panneau d'administration de diaspora*.


Recherchez un utilisateur et modifiez son rôle. Vous devez encore faire le premier administrateur manuellement comme décrit ci-dessous pour avoir accès à cette page.


Nous avons un système de rôles qui permet de rendre certains comptes "spéciaux" pendant l'exécution, sans redémarrer le serveur.

Actuellement, vous pouvez gérer le spotlight de la communauté, les modérateurs et les admins à travers ce système. Si vous utilisez PostgreSQL, assurez-vous d'avoir défini la variable d'environnement DB='postgres' ou vous obtiendrez une erreur très trompeuse de la part de bundler et si vous la suivez, vous installerez accidentellement l'adaptateur MySQL.

Commencez par démarrer une console Rails, en utilisant cette commande dans le répertoire de votre gem diaspora (généralement /home/diaspora/diaspora) :

RAILS_ENV=production bundle exec rails console

Vous obtiendrez un nouveau shell dans lequel vous pourrez entrer du code Ruby. Pour le quitter, appuyez simplement sur Ctrl+D ou tapez exit ou quit. Voici quelques exemples pour gérer les rôles, remplacez the_username par le nom d'utilisateur de l'utilisateur, et non son ID diaspora* complet :

Role.add_admin User.where(username: "the_username").first.person           # Ajouter un utilisateur comme administrateur par son nom d'utilisateur
Role.add_admin User.where(email: "the_email").first.person                 # Ajouter un utilisateur comme administrateur par son  email
Role.add_moderator User.where(username: "the_username").first.person       # Ajouter un utilisateur comme modérateur par son nom d'utilisateur
Role.add_moderator User.where(email: "the_email").first.person             # Ajouter un utilisateur comme modérateur par son email
Role.add_spotlight User.where(username: "the_username").first.person       # Ajouter un utilisateur comme 'community spotlight' par son nom d'utilisateur
Role.add_spotlight User.where(email: "the_email").first.person             # Ajouter un utilisateur comme 'community spotlight' par son email
Role.add_spotlight Person.where(diaspora_handle: "username@pod.tld").first # Ajouter un utilisateur comme 'community spotlight' pardiaspora par handle (autre pod), assurez-vous qu'au moins un utilisateur de votre pod suit ce compte.

Pour les admins : votre profil d'utilisateur devrait maintenant avoir un lien "Admin" ajouté à la liste de survol de la souris. Cela vous donne des trucs comme la recherche d'utilisateurs et les statistiques pour votre pod.
Pour les modérateurs : Le modérateur devrait maintenant avoir un lien "Modérateur" ajouté à la liste de survol de la souris. Les modérateurs ont accès à la section des rapports du panneau d'administration et peuvent examiner les messages et les commentaires signalés. Les modérateurs reçoivent également des courriels lorsqu'un nouveau commentaire ou message est signalé.

Les tags suivis ne fonctionnent pas sur mon pod.

Il n'y a pas de synchronisation dans diaspora*. Cela signifie que votre pod ne connaît que les messages qu'il a reçus dans un des conditions précises. Ces conditions sont, bien sûr : l'auteur est local, quelqu'un sur votre pod suit l'auteur du post, ou l'auteur du post suit quelqu'un sur votre pod. Une autre raison est que le message a été partagé à nouveau par quelqu'un que l'un des utilisateurs de votre pod suit. Les tags ne sont pas fédérés à tous les pods : le flux de #Suivi des Tags affiche uniquement les messages que votre pod connaît par le biais de l'un des scénarios précédents.

Mes fichiers journaux deviennent énormes, aidez-moi !

Configurez vous-même une solution de rotation des journaux. Par exemple, sur les distros Linux, faites-le avec logrotate, quelque chose comme ce qui suit (changez les chemins si nécessaire) dans /etc/logrotate.d/diaspora :

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

Une fois que vous avez ajouté le fichier à "/etc/logrotate.d/", exécutez

sudo logrotate -f /etc/logrotate.conf

Comment puis-je envoyer un courriel à un utilisateur / un groupe d'utilisateurs ?

Vous avez besoin d'une configuration d'emails qui fonctionne. Il existe deux façons de générer les e-mails.

Console Ruby

Lancez votre console rails avec RAILS_ENV=production bundle exec rails console, puis suivez l'un des exemples ou inventez le vôtre :

Notifier.admin("important message", User.where(username: "someuser")).each(&:deliver)                  # Envoyer un message à un utilisateur
Notifier.admin("important message", User.where(username: ["someuser", "anotheruser"])).each(&:deliver) # Envoyer un message à un groupe d'utilisateurs
Notifier.admin("important message", User.yearly_actives).each(&:deliver)                               # Envoyer un message à tous les utilisateurs actifs

Rake task

Il y a une tâche Rake podmin:admin_mail disponible pour permettre aux podmins d'envoyer facilement des nouvelles et des avis aux utilisateurs. La tâche rake génère des emails via le mécanisme normal de diaspora mailer (ils sont donc intégrés dans le modèle standard) et prend les paramètres suivants :

 1) Définition des utilisateurs
   all - tous les utilisateurs de la base de données (sauf ceux qui ont été supprimés)
   active_yearly - utilisateurs connectés au cours de la dernière année
   active_monthly - utilisateurs connectés au cours du dernier mois
   active_halfyear - utilisateurs connectés au cours des 6 derniers mois
 2) Chemin d'accès au fichier de messages
   Indiquez ici le chemin d'accès à un fichier HTML ou texte brut contenant le message.
 3) Sujet
   Un sujet pour l'e-mail

Exemple de commande shell (en fonction de votre environnement) ;

RAILS_ENV=production bundle exec rake podmin:admin_mail['active_monthly','./message.html','Message important du pod']

En savoir plus sur spécifier les arguments des tâches Rake.

Puis-je ajouter des publicités à mon pod ?

Bien sûr, aucune règle ne vous interdit d'ajouter des publicités à votre installation diaspora*.

Comment définir un document de conditions de service pour l'inscription à mon pod ?

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

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

  terms:
    enable: true

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

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

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

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

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

Comment modifier la page d'accueil du pod ?

Please see Custom_splash_page.

Comment puis-je supprimer les spams de mon pod ?

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

Erreurs et problèmes

Que dois-je faire de toutes ces erreurs PGErrors, comme les déconnexions et les problèmes SSL ?

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

Mon sidekiq se bloque, aidez-moi !

Vérifiez la version de votre curl.

   /usr/bin/curl --version

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

Vérifiez le pool de connexion de la base de données

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

Vérifier les erreurs d'ouverture de fichiers

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

Assurez-vous qu'il n'y ait pas de fuite de mémoire

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

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

Et si ma question ne trouve pas de réponse ici ?

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