Index by title


Here's an example for the fictional domain


To add this domain, we first need to have the domain resolvable through the DNS system.

For that you need to first add the domain in the /etc/bind/ configuration file and increment the serial.

To add the example domain, we add this line:

r2d2     3M IN A

And then we increment the serial from by at least one, here it's 1000000007:

@    1D IN SOA (
    1000000007    ; serial
    3H        ; refresh
    1H        ; retry
    24D        ; expiry
    3H )        ; minimum ttl

So we make it become 1000000008:

@    1D IN SOA (
    1000000008    ; serial
    3H        ; refresh
    1H        ; retry
    24D        ; expiry
    3H )        ; minimum ttl

Then we need to make bind9 take the changes into account. We can use the following command for that:

systemctl reload bind9

TLS certificates

As we need to protect people's privacy and security, we often need a TLS certificate associated with every new domains.

We first need to have a web server be able to serve files at that domain to make letsencrypt work.

To do that you can either add the new domain in /etc/apache2/sites-enabled/letsencrypt.conf, or another configuration file in the same directory.

Here's configuration directives for, you'll need to adapt it for a different domain:

<VirtualHost *:80>
    DocumentRoot        /var/www/letsencrypt/

You can paste that in any file in /etc/apache2/sites-enabled/:

Then you need to make apache2 take this into account. You can do it with the following command:

root@replicantserver0:~# systemctl reload apache2

You can check if apache2 is still running fine with the following command:

root@replicantserver0:~# pidof apache2
10465 10456 10421 230

At this point it would be a good idea to verify that everything works well before proceding as there is a limited number of (failed) attempt with letencrypt. When the limit is reached you have to wait before being able to retry which can be time consuming.

To check if everything is fine, it would be a good idea to:

It's then a good time to finally get a certifificate. You can use the 'certbot certonly --webroot' command to do that.

Here's an example of usage for the domain:

root@replicantserver0:~# certbot certonly --webroot 
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Please enter in your domain name(s) (comma and/or space separated)  (Enter 'c'
to cancel):
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for
Input the webroot for (Enter 'c' to cancel): /var/www/letsencrypt/
Waiting for verification...
Cleaning up challenges

 - Congratulations! Your certificate and chain have been saved at:
   Your key file has been saved at:
   Your cert will expire on 2020-08-28. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew" 
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:
   Donating to EFF:          

Finally don't forget to change the apache configuration again if the changes you made were only meant to be temporary.


path usage when to touch it
/etc/cgitrc generic cgit configuration
/etc/cgit.d The various repositories group configuration when adding new repositories to an existing group
/etc/apache2/sites-available/ when adding a new group
Example of groups: Example of repositories:



Project Comments
Ansible Probably well adapted to Trisquel
etckeeper Too complicated to use for handling /, well suited for directories like /etc/


Etckeeper seemed a good start to at least be able to track the virtual machine configuration in git and be able to re-deploy it easily.

However it seems to have some limitations (tested with Trisquel 8):

1 It tend to do things automatically, but with AVOID_DAILY_AUTOCOMMITS=1 and AVOID_COMMIT_BEFORE_INSTALL=1 in /etc/etckeeper/etckeeper.conf, and doing chmod -x /etc/etckeeper/init.d/70vcs-add, it won't git add all the files under the directory it manages at boot and will not do automatic commit each days.



This system was designed to be as simple as possible:
It was designed in a way that enables it to receive mail but it does not to need to send any mail: If we want to send mail we would need to implement all that:

We could also whitelist the servers used by the people receiving this mail through this system, through SPF, if we want people to send mail to the same address they received it from (which is probably not very important).

The DNS zones are configured to set the MX to the Replicant vm at the FSF.
For more details on how the DNS is hosted, see DNS.

For now this uses OpenSMTPD just because the person implementing that system initially (GNUtoo) already used OpenSMTPD at home, so it was faster as the configurations could be partially reused and the setup compared.

For consulting the mail we will use dovecot as the person willing to implement it (GNUtoo) already uses that at home too.

This will still need some authentication but as it's a separate part it also limit the risk of missconfiguration as for the ability to abuse the system to send mails.

Adding new people


First start by making sure that you have all the required information: To enable the person to receive mail you will need to:

Then to enable the person to retrieve the mail that are being received, you need to edit the /etc/dovecot/conf.d/secrets/server.passwd file and add a line that uses this format:


Then it's up to the person to configure her mail client with the following information
Username: The lower case username
Password: The secret password that was used to generate the password hash.
Port: 143
Protocol: TLSv1.3, imaps


Let's take a potentially fictional person named Yoko Tsuno that started contributing a lot to Replicant and that for some reasons needs to receive mails from the Replicant contact address (for instance for applying to some NLnet grants).

First we make sure that the person agrees to be listed on the Infrastructure wiki page as explained before.

Then the person comes up with a lowercase useranme (yokotsuno) and give us the following information

We start by enabling Yoko Tsuno to receive mail:

# useradd -m yokotsuno
# vim /etc/smtpd/aliases

If we had something like that in /etc/smtpd/aliases

contact: gnutoo, putti

Then we make it become something like that:

contact: gnutoo, putti, yototsuno

Then we update the table alias

# smtpctl update table aliases

Then we enable Yoko Tsuno to actually retrieve the mail:

# gpasswd -a yokotsuno mail
# id yokotsuno
uid=1010(yokotsuno) gid=1010(yokotsuno) groups=8(mail),1010(yokotsuno)
# vim /etc/dovecot/conf.d/secrets/server.passwd

And add the following line:


Then Yoko Tsuno needs to setup a mail client to retrieve the mail with the following details:

Username: yokotsuno
Password: The secret password that was used to generate the password hash.
Port: 143
Protocol: TLSv1.3, imaps

Mail clients configurations


Example for the fdm mail fetch program:


account "" imaps server "" port 143
set lock-file "%h/.local/" 
action "user-maildir" maildir "%h/.local/Maildir" 
match all action "user-maildir" 
set proxy "socks5://" # Use Tor
set verify-certificates


machine login yokotsuno password theultrasecretpassphrase

Thunderbird and derivatives

Thunderbird currently doens't support this setup.

See the bug #2032 for more details.


Switching to more recent OpenSMTPD

The configuration format changed in newer OpenSMTPD.

We will probably have to migrate the configuration when switching to to Trisquel 9.

TODO: Document the format change.



At the time of writing, only GNUtoo and Putti are able to do that, as they are the only people in the admin group in gitolite (this can be changed in conf/gitolite in the gitolite repository).


First you need to clone the gitolite repository:

git clone ssh://

Then you need to modify this repository to for adding a new user. In this tutorial we'll add the newuser user.

Here's an example of modification to do that:

diff --git a/conf/gitolite.conf b/conf/gitolite.conf
--- a/conf/gitolite.conf
+++ b/conf/gitolite.conf
+repo contrib/newuser/..*
+    C       =   newuser
+    RW+     =   newuser
+    R       =   @admins daemon
diff --git a/keydir/userkey2/ b/keydir/userkey2/
new file mode 100644
index 0000000..f8d32aa
--- /dev/null
+++ b/keydir/userkey2/
@@ -0,0 +1 @@
+ssh-rsa [...]

Then it would be a good idea to explain a bit why we need to do that (for instance newuser wants to work on Replicant 15, or newuser wants to add support for 6G devices) in the commit message.

Once the change is pushed, I'm unsure if the newuser directory also needs to be created or not.

If it does, the following commands could take care of it:

su -l git
mkdir -p /var/lib/gitolite3/repositories/contrib/newuser

The new user should then be able to create new repositories just using git push at the right address.



In the Gandi web interface we assigned the NS and SOA to the git.replicant.vm.

See the Infrastructure page on the main Replicant wiki for who has access to it.

The DNS zones are hosted on the vm by bind.

The Replicant zone is at /etc/bind/ and we don't have a reverse ip zone.


First edit the zone file:

# vim /etc/bind/

Then do the modifications you have to do

Then there is a line with a serial like that:

1590000005      ; serial

Increase that serial by at least 1, like here you can make it 1590000005 or 1600000000 but make sure to never go backward (I don't know why, however every documentation that I ready say that it could cause issues).

Then make bind take into account the modifications:

systemctl reload bind9

And wait for the information to propagate.


Mailing list administrators receive mails when messages are blocked by the mailing list for various reasons.

Some of the blocked messages are legitimate, but some are SPAM.

To filter that out:



Some forges might be able to:


Several forges have issues that prevent its use and deployment by Replicant and/or other free software projects.

Here are some of the requirements we could have:

Forge evaluations done by other Free Software organizations

The FSF is currently evaluating forges to compliment their Savannah servers:

FSF 2020 forge evaluation page on the LibrePlanet wiki:

December 4th, 2020 update: "The FSF forge is still a work in progress. Since our last update, summer intern Amin Bandali deployed a testing instance of SourceHut, one of many possible programs for the forge."

Possible forges for Replicant


We used gitlab before and we had resource usage issues. The VM went out of RAM because of that.

It also extensively depends on JavaScript and it doesn't look easy at all to fix.

From our FOSDEM 2020 report :

"GitLab was first built upon a framework that did most of the work on the server side, but at some point they switched to a framework thatdoes client-side rendering with JavaScript.

As we had an opportunity to talk with people from the GitLab team, weasked them whether they would be open to accept patches that fix this. They explained us that such would require to double the UI work for everything, but that it might be possible to do server side rendering with the same JavaScript that’s used on the client. The issue is that it cannot make requests from buttons like that, so in addition to the page rendering that could happen through server-side JavaScript, introspection could be used to rewrite the buttons."

It also hide buttons, which is awful for users as they don't understand what is going on.

Packages: ? (GOGS/Gitea)

Primary Developer: SharePunks Collective -
Primary Maintainer: Lauris BH



Packages: ?


Command line tools :


Packages: currently packaged in Debian SID, in a PPA, might be packaged in other distributions

Contacts: #pagure on Freenode and/orthe mailing list


Primary Maintainer: Drew Devault -
Person who wrote this section: j3s - (feel free to contact me with any questions!)



See Also

Relevant email from the libreplanet-dev email list about how the Sourcehut CI can optionally be adapted to provide CI support for other forges, like Pagure and Gitea:


Supported distributions: To add support for other distributions we need to:

It would be nice to be able use GuiX as the vm configuration could easily be deployed from git.


At the beginning the virtual machine was was administrated by the FSF sysadmins (through cfengine and FAI) and and Replicant maintainers (without configuration management).

The Replicant maintainers now completely took over the management of the VM: Future work:


Root password

The root password is managed by the FSF: the FSF sysadmins have access to it and it's stored encrypted somewhere.

If the VM doesn't show up on the network, they still need to be able to bring it back up by logging in and configuring the network manually.

In any case, if the VM doesn't boot or doesn't show up on the network they are able to get access to it without password by booting it with the following command line:


However using chroot (which also works when the VM is booted) from the host doesn't work here: if a VM is compromised somehow, chrooting into it could also compromise the host: when chrooting as root, the code and commands from within the VM are executed as root.

SSH Root access

The FSF sysadmins also have root access to the VM as they might need to access the VM through the network for various reasons like to shut it down cleanly in case of serious issues (security risk to the network), do emergency fixes inside it, test if SSH works, and so on.

When adding people to the authorized_keys:


TODO: New design of the portal (to be submitted to the mailing list and implemented):



We need to keep older Replicant versions fetchable and buildable. We cannot change the structure of the repositories we use in the manifests for older Replicant releases (they are tagged and so on), and we cannot go back in time either.

So if we change the repositories structure in the server, we need to keep compatibility with older versions as well.

Replicant versions

Replicant version manifest branch based on AOSP repo format AOSP CyanogenMod / LineageOS All other remotes
1.5 replicant AOSP kept not mirrored no CyanogenMod / LineageOS repos None
2.2 replicant-2.2 CyanogenMod kept not mirrored CyanogenMod, not mirrored not mirrored:
* f-droid (client)
2.3 replicant-2.3 CyanogenMod kept not mirrored CyanogenMod, not mirrored not mirrored:
* tinyalsa
* libsamsung-ipc
* f-droid (client)
4.0 replicant-4.0 CyanogenMod kept not mirrored CyanogenMod, not mirrored None
4.2 replicant-4.2 CyanogenMod kept not mirrored CyanogenMod, not mirrored None
6.0 replicant-6.0 LineageOS '/' changed to '_' mirrored in AOSP-mirror/ LineageOS-mirror F-droid (privileged-extension) mirrored in F-Droid-mirror/
9.0 (no releases yet) ? (Putti's AOSP) AOSP ? ? ? ?
9.0 (no releases yet) needs to be merged LineageOS kept not mirrored LineageOS, not mirrored freedesktop, not mirrored
10.0 (no releases yet) needs to be merged LineageOS kept mirrors/AOSP mirrored in mirrors/LineageOS/ freedesktop, not mirrored



We need to upstream the ability to open a partition with an external key.

Distributions like Ubuntu and Trisquel have patches, that probably comes from the grub crypt project that enables such functionality.

The FSF relies on such patches in their infrastructure to ensure that the rootfs of the vm remain encrypted.

As we need to deploy there, it's best to upstream such patches in order not to have to maintain them ourselves.

New upstreaming attempt



Sometimes we may want to verify the email address in a mail. That can happens when users ask to unsubscribe from something for instance.

Here the idea is to make sure we do almost the same checks than the ones that would be done if the users would unsubscribe themselves.

So here:

Handling cases that require to check more data (like people's identity or if people sent mails on behalf of organizations) would be too complicated to handle and might even put the person who does that in trouble in some cases (we're supposed to respect people's privacy).

How to do the checks manually

For verifying the mail we can save-as the mail for instance to /tmp/Mail.txt

Then we need to install python-dkim to be able to get the dkimverify command. In Parabola that can be done with the following command:

$ sudo pacman -S python-dkim

Then we can use dkimverify to verify that the DKIM signatures matches.

$ cat /tmp/Mail.txt | dkimverify
signature ok

We also need to inspect the mail headers manually to make sure that it was sent by and signed from the right server. For instance if the sender address is, a self hosted domain like shouldn't be the one signing the mail and vice-versa.

And finally we can reply to the mail telling that it's done in order to make sure that the person that has access to the mail address has a trace of the unsuscription.


Redmine registration issues

The Redmine registration procedure is a bit fragile: If account activation mail doesn't arrive, we don't know how to make Redmine resend it.

This could happen for several reasons:

When that happens, people can still create accounts but the account cannot be activated by them.

However it's still possible for Redmine Administrators to manually activate the account(s).

To manually activate an account for people creating new accounts

To manually activate an account for people that have admin access in the Redmine interface

All we need to check is that the email address is valid. Since many emails providers do use DKIM, we can easily reuse the DKIM signatures to do that:

We don't need to check the person's name as it's not checked by Redmine. Ideally we'd like to have a free form for the (real) name and also make it optional but we didn't find how to do it in a way that is easy to maintain in Redmine.

If you have the mail in Maildir format you can check the DKIM signatures with the following command:

$ cat ./the_mail_in_Maildir_format | dkimverify 
signature ok

And with claws mail, you can do it by opening the mail, then clicking on "File->Save Email as", and then you can verify it with the same command:

$ cat saved_mail | dkimverify
signature ok

Then to activate the account manually in Redmine, you can go in Administration->Users and Select All in Status, and search for the mail address.

Make sure that there is only one email matching, and then, once the user is selected, you should see the following links on the top-right of the page:

Emails Activate Delete Users

You can then activate the account by clicking on "Activate".

Be aware that there is no confirmation and that once the button is clicked, the account is activated immediately.


Continuous integration

Here's an example of not very efficent continuous integration system:



See the IRC section in the CommunityAndContact wiki page on the Replicant wiki for more details on how IRC is used.


How to make someone operator temporarily

Syntax: /mode #replicant +o <nickname>
Example: /mode #replicant +o GNUtoo

How to make someone operator automatically

To get the help on Freenode, and with irssi, you could use: /query ChanServ HELP FLAGS

It will switch to the ChanServ window and show the help.

At the time of writing this gives:

***** ChanServ Help *****
Help for FLAGS:

The FLAGS command allows for the granting/removal of channel
privileges on a more specific, non-generalized level. It
supports nicknames, groups and hostmasks as targets.

When only the channel argument is given, a listing of
permissions granted to users will be displayed.

Syntax: FLAGS <#channel>

Otherwise, an access entry is modified. A modification may be
specified by a template name (changes the access to the
template) or a flags change (starts with + or -). See the
TEMPLATE help entry for more information about templates.

If you are not a founder, you may only manipulate flags you
have yourself, and may not edit users that have flags you
don't have. For this purpose, +v grants the ability to grant
+V, +o grants the ability to grant +O, and +r grants the
ability to grant +b.

As of Atheme 7.0, there are now extended entity targets
which allow you to match chanacs against a situation instead
of against a nickname, hostmask or group.

Available exttargets are:
$chanacs:#channel - Any user with channel access in the given channel
                      (including hostmasks).

If you do not have +f you may still remove your own access
with -*.

Syntax: FLAGS <#channel> [nickname|hostmask|group template]
Syntax: FLAGS <#channel> [nickname|hostmask|group flag_changes]

    +v - Enables use of the voice/devoice commands.
    +V - Enables automatic voice.
    +o - Enables use of the op/deop commands.
    +O - Enables automatic op.
    +s - Enables use of the set command.
    +i - Enables use of the invite and getkey commands.
    +r - Enables use of the unban command.
    +R - Enables use of the recover, sync and clear commands.
    +f - Enables modification of channel access lists.
    +t - Enables use of the topic and topicappend commands.
    +A - Enables viewing of channel access lists.
    +S - Marks the user as a successor.
    +F - Grants full founder access.
    +b - Enables automatic kickban.
    +e - Exempts from +b and enables unbanning self.

The special permission +* adds all permissions except +b, +S, and +F.
The special permission -* removes all permissions including +b and +F.

    /msg ChanServ FLAGS #foo
    /msg ChanServ FLAGS #foo foo!* VOP
    /msg ChanServ FLAGS #foo foo!* -V+oO
    /msg ChanServ FLAGS #foo foo!* -*
    /msg ChanServ FLAGS #foo foo +oOtsi
    /msg ChanServ FLAGS #foo TroubleUser!*@* +b
    /msg ChanServ FLAGS #foo !baz +*
***** End of Help *****

So to make GNUtoo an operator we can use: /msg ChanServ FLAGS #replicant GNUtoo +O



See also


We currently use mailman 2.

Hyperkitty depends on mailman 3.

Mailman 3 uses Javascript but not extensively.

Example: to get the archive we need to click on the lastest button without javascript:

Hyperkitty instances




IRC notes

19:52 <@GNUtoo> Does mailman3 requires javascript?
19:52 < qyliss> it works, but does not work well, without JavaScript
19:53 < qyliss> fwiw, I read that the mailman developer would like there to be a simpler UI than hyperkitty
19:53 < qyliss> and it's all modular so it should be easy enough to make one
19:53 < qyliss> but nobody has done so yet

19:52 < qyliss> You can keep the old interface around as a static html archive
19:52 < qyliss> But you can't put new mail into it after upgrading to mailman 3



Original document URL:

We got the authorization from nono[m] in #laquadrature on Freenode to tranlate the terms of service:

11:29 < nono[m]> <GNUtoo "nono: est ce qu'il y-a une versi"> Si tu as envie de les traduire, hésite pas :)

As for the context nono[m] knows well the Mastodon instance and most probably worked on it. I also asked specifically for the right to translate that text. So given that context we can safely assume that we have the right to translate it.

Example on how to tranlate it.

We can strike text with dashes like that: - text -

So we can simply strike the text in French and tranlate it in english right below.

Note that there is a Language used section in English in the original document.

Terms of services

Politique de confidentialité du service Mamot

Dernière mise à jour : 2 avril 2018
Le service disponible sur le site est fourni par : La Quadrature du Net, Association, située au 60 rue des Orteaux, 75020 Paris, et joignable à l'adresse

Privacy policy of the Mamot service

Last update: 2 April 2018
The service which is provided on the website is provided by: La Quadrature du Net, non-profit organization, located at the 60 rue des Orteaux, 75020 Paris, France. It can be contacted at this email:

Informations que vous nous communiquez

Nous conservons l'identifiant et l'adresse email que vous nous fournissez lors de votre inscription, ainsi que des informations nous permettant de vérifier le mot de passe d'accès à votre compte.
Nous conservons ces informations jusqu'à la suppression de votre compte.

Informations that you gave us

We store the user name and the email address that you gave us as part of the account creation, along with information that enable us to verify the password that controls the access to your account.

We keep these information until the deletion of your account.

Contenus que vous publiez

Nous conservons et maintenons à disposition du public (de notre instance et des autres instances Mastodon) chaque contenu que vous publiez sur (en l'associant à votre pseudonyme, à votre avatar et à la date à laquelle vous l'avez publié).

Vous pouvez supprimer chaque contenu publié en cliquant sur l'icone représentant des points de suspension, située sous le dit-contenu, puis sur « Delete ». Nous indiquerons alors aux autres instances Mastodon qui conserveraient ce message d'en faire de même (sans pouvoir garantir qu'elles le fassent).

Correspondance privée

Nous conservons et maintenons à disposition des utilisateur·rice·s que vous avez choisis les correspondances privées que vous envoyez par messages dits « directs ».

Vous pouvez supprimer ces correspondances via l'option « Delete » décrite ci-dessus. Nous indiquerons alors aux autres instances Mastodon qui conserveraient ce message d'en faire de même (sans pouvoir garantir qu'elles le fassent).

En raison des limitations du protocole utilisé, la confidentialité des messages « directs » ne peut être garantie : ils sont susceptibles d'être accessibles aux administrateur·rice·s d'autres instances de Mastodon, voire au public en cas de problème sur la sécurité de Mastodon, de ou d'autres instances. Si nous devions apprendre qu'un tel problème de sécurité avait affecté, le compte publierait immédiatement un message afin d'en informer l'ensemble des utilisateur·rice·s.

Pour les différentes raisons évoquées ci-dessus, nous vous conseillons de veiller à ne pas partager d'informations destinées à rester absolument confidentielles.

Si vous souhaitez échanger de manière confidentielle des messages avec d'autres utilisateurs·rices, préférez Signal ou Jabber avec OMemo.


Nous déposons sur votre ordinateur deux cookies. Ces cookies permettent de maintenir votre navigateur connecté à votre compte et sont utilisés à cette seule fin.

Aucun pistage des utilisateurs·rices n'est réalisé au moyen de ces cookies, ni aucune autre utilisation que celle mentionnée ci-dessus.

Le premier de ces cookies est automatiquement détruit lorsque vous fermez votre navigateur. Le second l'est au terme d'un délai de deux semaines.

Données de connexion

Pour assurer le fonctionnement technique de (en effectuant des contrôles de qualité, pour déboguer ou pour empêcher des attaques), nous conservons pendant 14 jours l'ensemble des données de chaque accès au site : adresse IP, date et heure, informations sur le navigateur (user-agent), URL de la page demandée, taille de la réponse et le referrer (adresse de la page d'où vient l'utilisateur, si elle existe).

Accès aux données et portabilité

Vous pouvez télécharger la liste de vos messages, des utilisateur·rice·s que vous suivez, que vous avez bloqué·e·s ou caché·e·s à cette adresse (après vous être connecté à votre compte).

Si vous créez un nouveau compte sur ou une autre instance Mastodon, vous pourrez y importer ces données à cette adresse.

Suppression de compte

Vous pouvez demander à tout moment la suppression de votre compte Mamot en vous rendant à cette adresse (après vous être connecté à votre compte). puis en cliquant sur le lien sous "Supprimer le compte".

Données que nous sommes obligés de communiquer

En dehors des cas décrits ci-dessus, nous ne communiquerons des données vous concernant que dans le cadre d'une enquête pénale, sur l'autorisation d'un juge.

Données que nous refusons de conserver
Le droit français actuel prévoit que nous devrions conserver pendant un an des informations permettant de vous identifier (notamment votre adresse IP) chaque fois que vous créez un compte ou publiez un contenu sur Pourtant, la Cour de justice de l'Union européenne (CJUE) a décidé, de façon catégorique, qu’aucun État membre de l’Union ne pouvait imposer une obligation de conservation de données personnelles qui ne soit pas ciblée (qui ne distingue pas les données des personnes dont la surveillance est justifiée de celles des autres personnes).

Nous considérons donc que le droit français, n'étant plus conforme aux conventions européennes auquel il est soumis, n'a pas à être respecté - et nous ne le respectons pas.

Utilisations que nous ne faisons pas des données vous concernant

Nous ne faisons et ne ferons aucune exploitation commerciale des contenus que vous publiez, des correspondances privées que vous envoyez ou des données que nous collectons à votre sujet.

Nous ne diffusons et ne diffuserons les contenus et messages que vous partagez sur que dans le cadre de Mastodon.

En revanche, nous ne pouvons empêcher des tiers de collecter des contenus publiés sur le réseau Mastodon.

Charte d'utilisation de

v1, juillet 2019


En créant un compte sur, vous vous engagez à adhérer à cette charte., en tant qu'instance mastodon d'un réseau décentralisé (la fédiverse), a souhaité se doter de règles de modérations.
Le fait d'être une instance d'un réseau décentralisé a plusieurs conséquences :

L'équipe de modération est issue des membres de La Quadrature du Net, et évolue au fil du temps, principalement par cooptation. Le "nous" utilisé dans ce document sera considéré comme équivalent à "l'équipe de modération de", et ne représente pas l'association La Quadrature du Net dans son ensemble, mais uniquement la partie de ses membres et sympathisant·es en charge de Nous ne nous saisissons que des messages visibles sur qui nous ont été signalés. Aucune surveillance à priori des contenus n'est effectuée. L'équipe de modération reste seule décisionnaire des actions qu'elle entreprend sur les toots, comptes ou instances, et ses décisions, même si elles peuvent être discutées, sont souveraines.

[Note temporaire, sera supprimée début 2020 : La modération de mamot effectuée entre avril 2017, date de lancement du service, et juin 2019, était pour certains éléments similaire à cette charte, d'autres cas n'étaient pas documentés en raison de l'absence de charte. Cette charte précise donc pour partie un mode de modération déjà appliqué à ce jour, tout en ajoutant de nouvelles lignes directrices formalisées et de nouvelles pratiques comme la "communication vers les personnes concernées" (la modération était muette entre avril 2017 et juin 2019)]


L'instance, initiée par une équipe francophone, a pour langue principale le français, et parle et modère aussi l'anglais. Par conséquent :

Toutefois, rappelant que nous ne modérons que les contenus qui nous sont signalés, vous pouvez très bien disposer d'un compte parlant une autre langue et qui ne soit jamais inquiété. Nous vous conseillons cependant d'utiliser une autre instance si vous ne comptez pas utiliser le français ou l'anglais.

Language used moderation team is speaking French and English. As a result, we could delete or block any content in any other langage. If your account will post mostly non-French and non-English content, we ask you to choose another instance of the fediverse. Thanks.

Communication vers les personnes concernées

Tout signalement fera l'objet d'un retour vers la personne ayant signalé le toot / compte / instance. Ce retour se fera sous forme de message privé envoyé depuis le compte Ces messages seront automatiques et basés sur des modèles tenus à jour par l'équipe de modération.
On pourra regrouper plusieurs signalement reçu d'un·e même utilisateur·ice en un seul message, ou ne pas répondre systématiquement à cet·te utilisateur·ice s'il est habituel qu'iel nous signale des problèmes similaires.
(voir Annexe)

Communication vers le public

En plus de cette charte, l'équipe de modération maintiendra dans le temps un document de référence reprenant des cas précis de modération positive (conservation du contenu) ou négative (supression / silence du contenu).
Ces cas devront être proprement anonymisés et permettront à l'équipe de modération d'assurer la cohérence de ses réponses.
La liste des instances de la fédiverse bloquées par sera contenue aussi dans ce document, avec la date du blocage et la raison de ce dernier.
Ce document est public.

Comment signaler un contenu ?

Pour signaler un contenu de à l'équipe de modération, dans l'interface web principale visible à l'adresse et une fois connecté sur votre compte :
cliquez sur un toot ou un compte concerné, puis sur le menu signalé par 3 points "..." ,
cliquez ensuite sur "signaler @ un popup apparaît qui permet de signaler le compte ou certains de ses messages.

Charte de modération

Termes utilisés :
suppression (d'un message) : lorsque l'on enlève un contenu (message local ou distant) des bases de messages de
suppression (d'un compte) : ne s'applique qu'aux comptes locaux (, consiste en la destruction du compte, la suppression (locale) de tous ses messages, et le blocage de cette identité à l'avenir. blocage (d'un compte ou d'une instance distant) : lorsque les messages passés et nouveaux messages d'un compte distant ou d'une instance ne seront plus visible dans la base de messages de rendu silencieux (d'un compte local ou distant ou d'une instance distante) : les messages à venir du compte ou de l'instance n'apparaissent plus dans les timelines locales ou fédérées de, et le compte concerné n'apparaît plus dans les mentions des gens qui ne le suivent pas.

Nous reconnaissons que certains discours peuvent en empêcher d'autres. Nous prenons également en compte que la propagation des discours de haine, a fortiori contre des personnes marginalisées, banalise et encourage les violences qu'elles subissent au quotidien. Nous souhaitons donc protéger l'expression de celles et ceux qui ont le moins de pouvoir à l'échelle de la société.

Liste non exhaustive de messages inacceptables :

Nous recommandons l'utilisation des 'Content Warning' pour les contenus pouvant réveiller des traumatismes, choquer ou mettre mal à l'aise.
Exemples de sujets au CW vivement recommandés :
sexisme, racisme, homophobie, mort, viol, maladie, guerre, agressions et violence en tout genre, nourriture, sexe, et phobies courantes
autres CW possibles :
râlerie, selfie, contact visuel, spoiler / divulgâchage, tabac, alcool, addictions en tout genre, politique...

Les messages ou comportements décrits ci-dessus, ou l'absence répétée d'utilisation de CW sur les sujets vivement recommandés pourra faire l'objet de modération par : des messages envoyés au membre concerné, en privé ou en public, le fait de rendre son compte silencieux, son blocage s'il est distant, voire sa suppression.
S'il s'agit d'une instance sur laquelle nous est signalé régulièrement ce genre de messages ou comportement, et pour laquelle le ratio du nombre de signalement par rapport au nombre de messages ou d'utilisateurs de cette instance est important, ou si cette instance a une politique de modération explicitement favorable à ce type de messages ou de comportement, ou pour toute autre raison similaire, nous pouvons bloquer l'instance entièrement. Elle sera alors indiquée comme telle sur le document public de l'éuipe de modération (voir chapitre "Communication vers le public" plus haut).


Rappel de fonctionnement de la fédiverse :

Modèles de message envoyé par
Suite à votre signalement #{id} du {date}, voici notre réponse :
- nous n'avons rien fait, votre signalement ne précisant pas la nature du problème,
et n'étant pas évident au vu du compte/toot concerné.
- nous n'avons rien fait, votre signalement n'étant pas en violation de notre charte. {précision si besoin}
- le toot/compte/instance a été rendu silencieux/supprimé, pour la raison suivante :
Pornographie / violence non cachée
Violence / insulte / harcèlement ... {précision si besoin} merci,
l'équipe de modération



Replicant has an account on a Mastodon instance.


Account: Replicant
Terms of service: (Mostly in French)
Administration: La Quadrature du Net (Citizen advocacy group defending fundamental freedoms online. Information about Internet-related policy, mostly in European Union and in France).
Hosting: Octopuce (Company created by Benjamin Sonntag who also co-created La Quadrature du Net).










The documentation on the Redmine wiki has lot of duplication of information.

The solution that has been choosen for that is the following:

Other solutions were also possible such as migrating to documentation system like pandoc, but doing that would increase a lot the required skills of potential contributors.

Using complicated documentation systems has several issues:

Instead it would be better to use a documentation system that enable people without programming skills to easily contribute, while at the same time enabling people with programming skills to take advantage of it as well. Templates in various wikis system like Redmine or Mediawiki enables that.

In additions to wiki systems with templates, enabling to interface the documentation system with Wikidata also has many advantages:

Redmine wiki



Advantages: Issues:


At several conferences, including the Replicant conference in Paris in Summer 2019, and the FOSDEM, people were in favor of migrating to Mediawiki and didn't have objections to it.


The Replicant Project's Redmine wiki uses Textile markup language, while MediaWiki uses the Wikitext markup language.

It looks like some Redmine developers have recently been working to make it easier to transition from Textile to both generic Markdown and a more standardized flavor of Markdown called CommonMark:

There is currently an RFC at MediaWiki about supporting CommonMark in MediaWiki natively:

The comments section of MediaWiki's RFC page on this topic may be helpful to read for context on this proposal.

If we can find a reliable fork of MediaWiki that uses CommonMark instead of Wikitext, we should at least consider using it for the reasons outlined in the MediaWiki RFC links above and because of the fact that we now seem to have reliable software available to us to transition from Textile to CommonMark.

If we ultimately decide to use vanilla MediaWiki with Wikitext, or if we don't find any forks of Mediawiki that use CommonMark instead of Textile, it is our assumption that it would be easier to transition from the more common Markdown or CommonMark markup languages to MediaWiki's Wikitext markup language than it would be to transition from Textile directly to Wikitext. This assumption has been made based, in part, on arguments made here:


for usage parameters and variables use has reference
look into this for inspiration

Network Infrastructure

What Where Access type Who Comments
Redmine instance OSUOSL Redmine manager * Paul Kocialkowski
* Wolfgang Wiedmeyer
* GNUtoo
* Joonas Kylmälä
* Fil Bergamo
* Kurtis Hanna
* dl lud
* Grim Kriegor
* OSUOSL system administrators
Since we only have one project, OSUOSL put in a redirect from the main page of our Redmine instance to /project/replicant
OSUOSL keeps 2 weeks worth of backups for restoration purposes.
Mailing list Mailing list administrator * dl lud
* GNUtoo
* Joonas Kylmälä
* Kurtis Hanna
* Paul Kocialkowski
* Wolfgang Wiedmeyer
* OSUOSL system administrators
OSUOSL keeps 2 weeks worth of backups for restoration purposes.
Wordpress instance Wordpress administator * Paul Kocialkowski
* Wolfgang Wiedmeyer
* GNUtoo
* Joonas Kylmälä
* Fil Bergamo
* Kurtis Hanna
* dl lud
* OSUOSL system administrators
* Add your name here if you have access and want to be mentioned
This instance is auto-updated automatically with the help of a plugin.
Releases SSH * Paul Kocialkowski
* Wolfgang Wiedmeyer
* GNUtoo
* Joonas Kylmälä
* OSUOSL system administrators
We should not use too much space.
The (mostly-static) front website None: there is an automatic hook managed by OSUOSL. * Source code
* Patches should be sent to the Replicant mailing list.
* There is a jenkins hook with a token to pull and deploy the website source code.
Replicant Source code Virtual machine at FSF SSH root access * Paul Kocialkowski
* GNUtoo
* Joonas Kylmälä
* Several FSF system administrators
* FSF backup server
* FSF Ansible deployment server
Resources kindly offered by the FSF.
The git configuration has some documentation .
Before handling SSH (root) access to this machine:
* Make sure that the person really needs it.
* Make sure that the person already contributed to Replicant.
* Ask one other person that has SSH access and/or the SteeringCommittee to also agree on it.
Private contact address IMAP access * GNUtoo
* Joonas Kylmälä
* Fil Bergamo
* Kurtis Hanna
* dl lud
* Grim Kriegor
You can write to the contact address (all the members of SteeringCommittee receive it) if for some reasons you need to receive it as well.
#replicant IRC channel Freenode Channel operator * Paul Kocialkowski
* GNUtoo
* Joonas Kylmälä
* Kurtis Hanna
Quiet mode for unregistered users is disabled for the time being. If SPAM comes back use: /mode #replicant +qe $~a *!*@gateway/web/* and /mode #replicant +qe $~a *!*@gateway/shell/* to re-apply it. These commands whitelist users coming through web based IRC clients and via the IRC bridge.
OFTC Channel operator * Kurtis Hanna
* Jeremy Rand
Bridged with the Freenode IRC channel and Matrix channel through the NCBridge bot operated by Jeremy Rand
The domain name * Web inteface through gandi website
* The DNS entries are configured to use gandi's DNS server
* Bradley Kuhn : Can do everything (including designating the technical contact or transferring the domain)
* GNUtoo : can do DNS zone changes
* Other people? Paul Kocialkowski ?
The TLS certificate Let's Encrypt Access probably by controlling the respective domain name * OSUOSL
* ?
History: CA-cert -> GlobalSign -> LetsEncrypt
Mastodon account Administred by La quadrature du net Account only * TODO: ask the person who created the account
* The Private contact address address was used as the mail
See the Mastodon page for more details


The OSUOSL is the Oregon State University Open Source Lab.


Virtual machine in FSF's infrastructure


Virtual machine specifications

See VMSpecifications for the VM specifications.

Virtual machine backup policies

The virtual machine is backed up daily. The backup procedure excludes the following path at the time of writing:


git hosting infrastructure on this machine

The source code is in /srv/git/git-data/repositories and is divided in several groups:
function software documentation comments
authorization gitolite UpstrreamSourceCodeMirrors
read access * git:// -> git daemon
* ssh:// -> ssh daemon
* https:// -> ? (TODO: document the software/configuration)
web cgit Cgit





Funding and legal entity

See the SteeringCommittee for more details.

Legal advise

Contact John Sullivan at the FSF.

Note that John Sullivan is not a lawyer but the FSF has lawyers.


The replicant-infrastructure redmine project has a wiki with more documentation in it.


We run a bridge between different IRC channels (currently #replicant on OFTC and #replicant on liberachat).

The code, configuration and documentation about it is available here:


Gitlab provided an RSS feed of all git activity.

Since we migrated away from Gitlab, this link is broken.

So we probably need a more lightweight solution to properly fix that.


Distro Status
Trisquel 8 apt search rss found only RSS readers, libraries, and generators for other use cases


Virtual machine specifications

The virtual machine runs on top of Xen and has:

The FSF sysadmins control a firewall that is outside of the VM. So we need to contact them to open new ports.

At least the following ports have been opened:

Port Transport Service software
53 UDP DNS Bind 9
80 TCP HTTP Apache
143 TCP IMAP Dovecot
443 TCP HTTPS Apache


Disribution: Trisquel
Boot setup: Encrypted /, GRUB decrypts opens the encrypted rootfs and loads the kernel and initramfs from it which then opens the encrypted rootfs again with a key.

Replicant infrastructure Wiki

Current infrastructure

Maintenance information




All the wikis in this Redmine instance are available under the Creative Commons BY-SA license.