• MamotfrTermsOfServices
• Wiki
  • AddingANewDomain
  • ConfigurationManagement
  • ContactAddress
    • DNS
  • ContribRepositories
  • FilteringSpamOnTheMailingList
  • Forges
  • FSFVM
  • FSFVMConfigurationManagement
  • FSFVMRootAccess
  • GitHosting
  • GitRedirects
  • GRUBCrypt
  • HowToVerifyAnEmail
  • InCaseOfRedmineRgistrationIssues
  • InfrastructureEfficency
  • IRC
  • MailingListSoftware
  • MediawikiMigration
  • NetworkInfrastructure
    • Cgit
    • Mastodon
  • Replicant-bridge
  • RSS
  • VMSpecifications
  • Wordpress

AddingANewDomain¶

Here's an example for the fictional domain r2d2.replicant.us

bind¶

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/db.replicant.us configuration file and increment the serial.

To add the example r2d2.replicant.us domain, we add this line:

r2d2     3M IN A    18.4.89.63

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

; replicant.us
@    1D IN SOA    replicant.us. gnutoo.no-log.org. (
    1000000007    ; serial
    3H        ; refresh
    1H        ; retry
    24D        ; expiry
    3H )        ; minimum ttl

So we make it become 1000000008:

; replicant.us
@    1D IN SOA    replicant.us. gnutoo.no-log.org. (
    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 r2d2.replicant.us, you'll need to adapt it for a different domain:

<VirtualHost *:80>
    ServerName          r2d2.replicant.us
    DocumentRoot        /var/www/letsencrypt/r2d2.replicant.us/
</VirtualHost>

• You can add it to /etc/apache2/sites-enabled/letsencrypt.conf if you plan to keep using it after for enabling letencrypt to renew the certificates automatically. This is typically useful if you don't need a web server at that domain, which can be the case if you only intend to host a mail server there for instance.
• You can add it in a temporary file like /etc/apache2/sites-enabled/r2d2.conf if you use another configuration for that later on.
• Or you can add it to any existing or new file in the /etc/apache2/sites-enabled/ depending on your needs.

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.

• make sure that you can ping the domain
• make sure that apache responds, a "Forbidden" web page is good enough for that

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 r2d2.replicant.us 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): r2d2.replicant.us
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for r2d2.replicant.us
Input the webroot for r2d2.replicant.us: (Enter 'c' to cancel): /var/www/letsencrypt/r2d2.replicant.us/
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/r2d2.replicant.us/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/r2d2.replicant.us/privkey.pem
   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:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

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

Cgit¶

• https://git.replicant.us/LineageOS-mirror
• https://git.replicant.us/replicant

• https://git.replicant.us/replicant/manifest/

ConfigurationManagement¶

Sumarry¶

Etckeeper¶

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):

• It expects sysadmins to only use etckeeper for a single directory like /etc/ or maybe /boot for special cases. It doesn't seem well suited for keeping / under git. While some automatic commits can be disabled¹, it will for instance scan the whole directory and populate .etckeeper with many mkdirs. While this is highly desirable for /etc/, because without that some daemons might fail to start, it is clearly not desirable for /. The consequence is that any configuration outside of /etc/ will not be tracked by etckeeper. This behavior is governed by the code in /etc/etckeeper/pre-commit.d/30store-metadata which doesn't contain any way to disable that behavior, and that still needs to run somehow as otherwise some of the permissions will probably not be correct.

¹ 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.

ContactAddress¶

• Table of contents
• ContactAddress
  • Design
  • Adding new people
    • HOWTO
    • Example
    • Mail clients configurations
      • FDM
      • Thunderbird and derivatives
  • Notes
  • Switching to more recent OpenSMTPD

Design¶

• There is no need of reverse DNS for the IP address.
• We don't need to use DKIM.
• It's easier to get the setup right and secure. We don't even need any authentication to receive the mail.
• We don't need to make sure that the system cannot be abused to send arbitrary mail to arbitrary address by anyone as it's not supposed to send any mail in the first place.

• We would need to see with the FSF if they could handle us the control of the reverse DNS for the IP address we use.
• For DKIM, we would need to look if Trisquel 8 has DKIM implementations (like dkimproxy) that are easy to integrate with OpenSMTPD.
• We would need to make sure that the server configuration cannot be abused to send mails to arbitrary address by anyone else it would ended up being blacklisted by companies and project trying to fight SPAM.

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¶

HOWTO¶

• Make sure that the person knows that she will be publicly listed as a person that receives that contact email address
• Ask the person for which lowercase username they wish to use
• Ask the person to run the following command: doveadm pw -u <username> -s SHA512-CRYPT

• Add the person to the list of people receiving the address at the Infrastructure wiki page in the main Replicant wiki.
• Create an account inside the vm for the new person. This can be done with the following command:
  

  useradd -m <lowercase_username>
  

• Add the lower_case_username to /etc/smtpd/aliases
• run smtpctl update table aliases

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:

<user>:<password_hash>:<uid>:<gid>::<home>::userdb_mail=maildir:<Maildir_path>

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.
Hostname: imap.replicant.us
Port: 143
Protocol: TLSv1.3, imaps

Example¶

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.

• Username: yokotsuno
• password hash:
  

  {SHA512-CRYPT}$6$v.YlRHeVQpNmheHv$yaqUhQ5xnyFzV2SNbfdYWmeQT3Gg4fZ/7AC.rixBHpUaqT9XsXSU2CSQKLyyghHovDo.p1hnveki4DnoE1GJL/
  

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:

yokotsuno:{SHA512-CRYPT}$6$v.YlRHeVQpNmheHv$yaqUhQ5xnyFzV2SNbfdYWmeQT3Gg4fZ/7AC.rixBHpUaqT9XsXSU2CSQKLyyghHovDo.p1hnveki4DnoE1GJL/:1010:1010::/home/yokotsuno::userdb_mail=maildir:/home/yokotsuno/Maildir

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.
Hostname: imap.replicant.us
Port: 143
Protocol: TLSv1.3, imaps

Mail clients configurations¶

FDM¶

Example for the fdm mail fetch program:

.fdm.conf:

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

.netrc:

machine imap.replicant.us login yokotsuno password theultrasecretpassphrase

Thunderbird and derivatives¶

Thunderbird currently doens't support this setup.

See the bug #2032 for more details.

Notes¶

• The Maildir directory is created automatically when receiving the first mail
• There is no need to setup a password for the account
• I didn't look how much we can lock down the accounts and still make openstmtpd work.

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.

ContribRepositories¶

Requirement¶

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).

Procedure¶

First you need to clone the gitolite repository:

git clone ssh://git@git.replicant.us/gitolite-admin

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/newuser.pub b/keydir/userkey2/newuser.pub
new file mode 100644
index 0000000..f8d32aa
--- /dev/null
+++ b/keydir/userkey2/newuser.pub
@@ -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.

Caveats¶

• Note that pushing to an address with a typo (like ssh://git@git.replicant.us/contrib/newuser/hardware_replicant_libsamsung-pic instead of ssh://git@git.replicant.us/contrib/newuser/hardware_replicant_libsamsung-ipc) will create the hardware_replicant_libsamsung-pic repository.
• Also I don't know how users can delete repositories, but people with root access to the VM (at the time of writing, GNUtoo and Putti) can still do that.

DNS¶

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 git.replicant.us vm by bind.

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

Quick HOWTO¶

First edit the zone file:

# vim /etc/bind/db.replicant.us

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.

FilteringSpamOnTheMailingList¶

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.

• Login inside the mailman administration page for pending messages
• Go to the "view the details" link
• For each message:
  • Read the message to understand if it's a SPAM or not
  • If it's a SPAM, click on discard. This will make sure that the spammers are not informed about the issue of their message.
  • If it's not a SPAM and that the message is to be sent to the mailing list, click on "Approve" to send it.
• Once done click on "Submit all data".

Forges¶

Usage¶

• Provide a way for users to create and manage repositories by themselves, without any administrator interventions.
• Enable users to fork repositories very efficiently (without having the users push all the repository contents over a slow Internet connection).
• Enable users not used to sending patches by mail to have the forge do it for them.

Requirements¶

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

• Fully free software: we currently don't have the resources to maintain fully free forks of forges that aren't fully free software.
• Low resource usage: we have a VM with very low CPU and RAM.
• Javascript requirements: we can't ship Nonfree JavaScript and forcing users to run specific JavaScript code without being able to easily modify it is an issue, even if the code is free software. To work to avoid that we have the following requirements:
  • A Friendly upstream that accepts patches to make all features work without JavaScript.
  • A code base that don't depend a lot on JavaScript
  • If possible all features should be usable without JavaScript
  • If possible the JavaScript has to be compatible with LibreJS
• Workflow requirements:
  • Have the ability to customize the interface, for instance if the forge doesn't support a mail workflow we need to add a link from within the forge to a page that explains how to send patches to the mailing list. The same probably applies to bug tracker system as we already have one that is already handled by redmine.
  • Friendly upstream that can accept patches for integrating it with a mailing based workflow. We might need to customize it as we have many git repos.
  • Code base where integrating a mailing list based workflow is not too hard to do
• Have it packaged in a distribution we can use in the FSF VMs to reduce maintenance cost

Forge evaluations done by other Free Software organizations¶

The FSF is currently evaluating forges to compliment their Savannah servers: https://www.fsf.org/blogs/sysadmin/coming-soon-a-new-site-for-fully-free-collaboration

FSF 2020 forge evaluation page on the LibrePlanet wiki: https://libreplanet.org/wiki/FSF_2020_forge_evaluation

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." https://www.fsf.org/bulletin/2020/fall/updates-from-the-fsf-tech-team

Possible forges for Replicant¶

Gitlab¶

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: ?

Libregit.org (GOGS/Gitea)¶

Website: https://libregit.org
Primary Developer: SharePunks Collective - spks.cc
Primary Maintainer: Lauris BH

Pros

• Based of Gitea and Gogs, so self-hosting is the focus.
• LibreJS complaint.
• Simple user export and import of data, including migration feature.
• Simple and easy to use interface, making for the easy integration for non-technical users.
• FSDG complaint distributions installations would both work with minimal effort.

Cons

• MIT Licensed, not committed to free software philosophies given it is permissibly licensed.
• Email setup is not the most straight forward but it could be accomplished.
• The size of the project is growing exponentially given its upstream, which includes GOGS/Gitea.

Packages: ?

Pagure¶

Website: https://pagure.io/pagure
Command line tools : https://pagure.io/pag-off

• The buttons seem to be greyed out when they cannot be used This is much better than Gitlab where the buttons like "Send pull request" completely disappear if the feature is deactivated. Having button like that disappearing is really bad as users struggle to understand what they are doing wrong and can't contribute, when in fact the feature is simply deactivated without any way that shows it.
• It's possible to create a theme that replaces the Pull Requests tab with a link (for instance the link could point to a page that explains how to send patches to the mailing list). src.fedoraproject.org uses that to replace the Issues tab with a link to Red Hat's Bugzilla
• It's compatible with LibreJS but still requires JavaScript for some functionalities. Upstream seem friendly and is probably very interested in getting patches to make it possible to use all features without any JavaScript . Few features seem to depend on JavaScript.
• There is some interest in bridging a mailing based workflow to pagure: https://pagure.io/pagure/issue/15

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

Contacts: #pagure on Freenode and/orthe pagure-devel@lists.pagure.io mailing list

Sourcehut¶

Website: https://sourcehut.org
Primary Maintainer: Drew Devault - sir@cmpwn.com
Person who wrote this section: j3s - j3s@c3f.net (feel free to contact me with any questions!)

Pros

• Completely integrated mailing list, build, todo, hub, and git repositories. Organizations/groups coming eventually.
• Only has 3 static js files. Extremely easy to support LibreJS. Requires no Javascript to function.
• Simple user export of data
• AGPLv3, committed to free software philosophies and open source communities https://sourcehut.org/blog/2019-10-23-srht-puts-users-first/
• Also has wiki/manpage support, a paste service, and a dispatch service.
• Trisquel/Parabola installations would both work with minimal fuss: https://man.sr.ht/packages.md

Cons

• Alpine Linux is the most supported distribution, and doesn't meet RYF certification.
• Email setup can be a bit more complicated than alternatives, but it's fine if one is familiar with email concepts - SPF/DKIM/etc
• Drew maintains that sourcehut is "in alpha stage" - he goes over what that means here: https://sourcehut.org/alpha-details

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: https://lists.libreplanet.org/archive/html/libreplanet-dev/2021-01/msg00001.html

FSFVM¶

• Trisquel

• Either upstream grub-crypt patches or maintain them in the other distribution we want to add support for (1) The patches are now upstream and (2) the patches are not needed anymore since the encryption is now handled in another way that is completely transparent for the distribution.
• Send a patch to the current version of the vm creation script. An old version of the script has been added to this page. There is no public git for it at the FSF because they cannot share its history as they probably have passwords or things like that inside.

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

FSFVMConfigurationManagement¶

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. The FSF is only doing backup for us through scripts that use SSH.

History¶

• It's not using cfengine anymore and the FSF sysadmins do not manage it anymore but they can help in case of issues (See FSFVMRootAccess for more details).
• We then took over FAI which is still being used for automatic updates only, but since it installed packages that increased the attack surface all the time (like samba) we switched to using unattended-upgrades.
• We then tried etckeeper and configured it to do manual commits only. Though it didn't work for '/' (but worked fine for directories)
• We then moved to ad-hoc configurations in git with custom install scripts / Makefile and templating.

FSFVMRootAccess¶

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:

init=/bin/sh

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.

• We need the agreement of at least one person that is not you and that is from the Replicant steering commitee
• We need to add it in the List of people having access so we have to make the person is also ok for being mentioned as a pre-requisite for giving that person access.
• We also have to inform the FSF sysadmins about it as they also maintain a list of people that have access to VMs on their side (along with contact information for at least a subset of the people for emergency purposes).
• They probably have an agreement to agree to for new people as well (which has clauses about good practices like to not give access to anybody like that, what the FSF staff can do if the VM is compromised, etc).

GitHosting¶

• Move the part of the Replicant wiki on git hosting here (like the contributors guide)
• Point the Replicant wiki here

• Replicant -> Replicant source code
• Mirrors -> Mirrors used by Replicant
  • AOSP
  • LineageOS
• Replicant versions that are a work in progress (Example: replicant-9 and replicant-10 when the last release is Replicant 6)
• ArchiveMirrors -> Mirrors used to archive code only (FSO, paulk, etc)
• Contrib -> contributors repositories only
• Link to explain how to contribute to Replicant

GitRedirects¶

Introduction¶

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¶

GRUBCrypt¶

Introduction¶

Before we need to upstream in grub the ability to open a partition with an external key to be able to use other distributions than Trisquel.

This was because distributions like Ubuntu and Trisquel had patches, that probably came from the grub crypt project that enabled such functionality.

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

However now not only the patches are upstream, but the FSF also don't depend on them anymore.

HowToVerifyAnEmail¶

Introduction¶

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.

• We need to verify that the mail was sent from the right server
• We also need to make sure that the person who sent the mail can also receive mails at the same address.
• We should not verify the person's name, credentials or similar since they are not needed to do the operation anyway.

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. This done with the following command:

For Parabola:

$ sudo pacman -S python-dkim

Or for Guix:

$ guix package -i python-dkimpy

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 sender@gmail.com, a self hosted domain like cyberdimension.org 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.

InCaseOfRedmineRgistrationIssues¶

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.

• The registration mail could be lost.
• Redmine could have lost its "Email notification" settings. In that case, Administration->Settings->Email notifications will shows that it's not configured.

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¶

• Send a mail to the Mailing list (Registration required) or the PrivateContact address or the mailing list.

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

• First we ask the people having the issue to send a mail on the mailing list, or to the contact address, asking for an account, along with the account details.
• We then verify that the account is not registered, and that the mail is the same between the mail we received and the account.
• Then we verify that the mail we received was not forged by verifying the DKIM signatures.
• Then we activate the account if everything is good.

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.

InfrastructureEfficency¶

Continuous integration¶

Here's an example of not very efficent continuous integration system: https://lwn.net/Articles/813767/

IRC¶

Introduction¶

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

Freenode¶

This documentation was for when we used Freenode. It needs to be replaced with documentation for Libera Chat.

Now we migrated to Libera Chat instead. We also have a bridge that bridges the #replicant channels on Hackint, Libera Chat, and OFTC.

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]

Permissions:
    +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.

Examples:
    /msg ChanServ FLAGS #foo
    /msg ChanServ FLAGS #foo foo!*@bar.com VOP
    /msg ChanServ FLAGS #foo foo!*@bar.com -V+oO
    /msg ChanServ FLAGS #foo foo!*@bar.com -*
    /msg ChanServ FLAGS #foo foo +oOtsi
    /msg ChanServ FLAGS #foo TroubleUser!*@*.troubleisp.net +b
    /msg ChanServ FLAGS #foo !baz +*
***** End of Help *****

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

OFTC¶

TODO

See also¶

• The Infrastructure page on the Replicant wiki has many information on the IRC channel(s) too.

MailingListSoftware¶

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: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/latest

Hyperkitty instances¶

• https://mail.coreboot.org/hyperkitty/
• https://spectrum-os.org/lists/hyperkitty/

public-inbox¶

website: https://public-inbox.org/README.html

• https://lore.kernel.org/lkml/

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

MamotfrTermsOfServices¶

• Table of contents
• MamotfrTermsOfServices
  • Introduction
  • Example on how to tranlate it.
  • Terms of services
    • Politique de confidentialité du service Mamot
    • Privacy policy of the Mamot service
    • Informations que vous nous communiquez
    • Informations that you gave us
    • Contenus que vous publiez
    • Correspondance privée
    • Cookies
    • Données de connexion
    • Accès aux données et portabilité
    • Suppression de compte
    • Données que nous sommes obligés de communiquer
    • Utilisations que nous ne faisons pas des données vous concernant
    • Charte d'utilisation de mamot.fr
    • Préambule
    • Langue
    • Language used
    • Communication vers les personnes concernées
    • Communication vers le public
    • Comment signaler un contenu ?
    • Charte de modération
    • Annexes

Introduction¶

Original document URL: https://mamot.fr/terms

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 mamot.fr est fourni par : La Quadrature du Net, Association, située au 60 rue des Orteaux, 75020 Paris, et joignable à l'adresse sysadmin@laquadrature.net

Privacy policy of the Mamot service¶

Last update: 2 April 2018
The service which is provided on the mamot.fr 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: sysadmin@laquadrature.net

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 mamot.fr (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 mamot.fr ou d'autres instances. Si nous devions apprendre qu'un tel problème de sécurité avait affecté mamot.fr, le compte @admin@mamot.fr 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.

Cookies¶

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 mamot.fr (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 mamot.fr : 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 mamot.fr 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 mamot.fr. 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 mamot.fr 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 mamot.fr¶

v1, juillet 2019

Préambule¶

En créant un compte sur mamot.fr, vous vous engagez à adhérer à cette charte.

Mamot.fr, 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 :

• Nous sommes susceptibles de republier sur mamot.fr, le plus souvent de manière automatique, des contenus publiés initialement ailleurs. Nous n'avons cependant aucune obligation de le faire. Le fait de bloquer ou rendre silencieux un compte distant ou une instance distante entière est donc du choix des modérateurs.
• Par opposition aux réseaux centraux monopolistiques (facebook, twitter, etc.), et en tant que réseau décentralisé, bloquer un contenu ou un compte n'est pas de la censure : nous n'avons aucune obligation de vous fournir une plateforme pour vos déclarations, le réseau de la fédiverse est bien assez grand pour que, dans ce cas, vous puissiez vous exprimer ailleurs, sur une autre instance ou la vôtre propre.
• Le réseau Internet étant basé sur une garantie de moyen et pas de résultat, il se peut que tout message ne passe pas, de manière temporaire ou permanente. Nous ne saurions en être responsables.

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 mamot.fr", 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 mamot.fr. Nous ne nous saisissons que des messages visibles sur mamot.fr 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)]

Langue¶

• Tout contenu qui nous sera signalé, parlant une langue que nous ne parlons pas, peut, dans le doute, être potentiellement supprimé.
• Si votre compte souhaite pouvoir publier majoritairement dans d'autres langues, nous vous invitons à utiliser une autre instance de la fédiverse.

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¶

Mamot.fr 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 moderation@mamot.fr. 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 mamot.fr 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 ?¶

• Préférez le signalement de certains messages (en les cochant "?" plutôt que "x") si ceux-ci posent problème, plutôt qu'un compte globalement.
• Surtout, mettez un "commentaire additionnel" (dans la zone de texte) pour nous expliquer en quoi ce message pose problème, que nous n'ayons pas à deviner.
• Si le compte provient d'un autre serveur, une case à cocher permet d' "envoyer le signalement de manière anonyme au serveur concerné", faites selon votre souhait, et nous vous recommandons de le faire. Enfin, cliquez sur "Envoyer".

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 mamot.fr.
suppression (d'un compte) : ne s'applique qu'aux comptes locaux (@mamot.fr), 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 mamot.fr. 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 mamot.fr, et le compte concerné n'apparaît plus dans les mentions des gens qui ne le suivent pas.

• Conformément aux lois françaises et à la jurisprudence, les contenus pédopornographiques, y compris sous forme dessinée, sont illégaux et seront supprimés, et les comptes concernés bloqués (si distants) ou supprimés (si local).
• Les contenus pornographiques ou visiblement violents doivent être marqués avec le drapeau "sensible / sensitive". Les comptes ne respectant pas cette règle seront rendus invisibles aux flux locaux et fédérés.
• La publicité, sous forme répétée et/ou intrusive (faisant mention d'autres utilisateur·ices), n'est pas acceptée. Les comptes concernés seront rendus invisibles aux flux locaux et fédérés, ou supprimés, selon la gravité de la situation.
• Mastodon est un média social. Vous pouvez y fréquenter des ami·e·s et y croiser des inconnu·e·s. Dans la rue, on ne parle pas à ses ami·e·s de la même manière qu'aux inconnu·e·s. Cela vaut aussi pour la vie en ligne. Approchez les personnes que vous ne connaissez pas avec précaution et politesse. Ce n'est pas parce qu'un message traverse votre écran que vous devez nécessairement y répondre. Avant de mentionner une personne, demandez-vous si votre message mérite son temps, son attention et surtout si elle a envie de vous lire. Si une personne vous demande d'arrêter de la mentionner ou qu'elle exprime ne plus vouloir participer à une discussion, arrêtez immédiatement. Nous pourrons avertir par message privé, rendre silencieux ou suspendre tout compte qui ne respecterait pas ce processus de manière répétée.

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 :

• Les propos, images ou vidéos racistes, sexistes, homophobes ou transphobes.
• Les avances ou propositions à caractères sexuels non-sollicitées.
• Toute conduite, en public ou en privé, ayant pour but de traquer, harceler ou intimider d'autres personnes.
• Rassembler, publier, disséminer les informations personnelles d'une autre personne sans son autorisation explicite.
• Poursuivre une conversation ou inciter une personne à poursuivre une interaction avec une personne ayant réclamé la cessation de ladite interaction peut être considéré comme du harcèlement, indépendamment de la confidentialité employée.
• Toute tentative de retournement d’une oppression systémique. Par exemple : « racisme anti-blanc », « sexisme anti-homme », « hétérophobie », « cisphobie ».
• Publier ou diffuser intentionnellement des propos diffamatoires, calomnieux. Cela concerne aussi toute désinformation avec intention de tromper (le gorafi ou the onion sont donc autorisés).
• Tout comportement cité précédemment qui serait présenté comme « ironique » ou « pour rire ».

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).

Annexes¶

Rappel de fonctionnement de la fédiverse :

• les comptes créés sur mamot.fr peuvent publier des messages à destination de tout autre compte de la fediverse, qui peut l'accepter ou pas. Chaque compte peut choisir de bloquer tout autre compte local ou distant, ou toute instance distante.
• les messages apparaissent (si publiés en "public") dans la "timeline locale" de mamot.fr, sauf si votre compte a été rendu silencieux / masqué.
• les messages de mamot.fr et de toutes les personnes d'autres instances suivies par des comptes de mamot.fr apparaissent sur la "timeline globale" de mamot.fr, sauf les comptes qui ont été rendus silencieux / masqués.
• Le silence / masquage (de compte ou d'instance) ne fait que rendre invisbile sur les flux locaux ou fédérés les messages d'un compte ou de tous les comptes d'une instance donnée. Cela n'empêche pas nos utilisateurs de recevoir des toots (par boost ou fav de leurs abonnés) ou de s'abonner à ces comptes, mais cela décide de la charte éditoriale des flux locaux / fédérés de notre instance.

Modèles de message envoyé par moderation@mamot.fr
Bonjour,
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
Pédopornographie
Violence / insulte / harcèlement ... {précision si besoin} merci,
l'équipe de modération

Mastodon¶

Introduction¶

Replicant has an account on a Mastodon instance.

Information¶

Account: Replicant
Terms of service: https://mamot.fr/terms (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).

Maintenance¶

• Mail used for the account creation: Replicant private contact address
• Migrating instance (in French): http://www.kozlika.org/kozeries/post/2017/04/10/Mastodon-changer-d-instance

TODO:¶

• Translate the terms of service from French to English See MamotfrTermsOfServices for the page about that.
• Check if they are members of the CHATONS => They are not members of the CHATONS.

MediawikiMigration¶

TODO:¶

Installation:¶

• [x] Test instance - We find a way to install mediawiki somehow and we do the install but we don't use it officially yet
  like there would be no users accounts, so migration scripts can be tested.
• [ ] Migrating off Redmine - When everything is ready we'd disable wiki editions in redmine and enable account creation in mediawiki and announce it

Migration:¶

• [ ] Use migration-scripts developed in-house for the creation of a git repository with all the history preserved
• [ ] Use pandoc ":https://pandoc.org/" code-base to convert from textile to mediawiki (or a markdown derivative if we end up going that route), including child/parent structure of the articles, to transfer all articles to new mediawiki installation.
• [ ] Use git-mw remote to prevent the loss of history, by recreating past contributors and editors accounts, so we make sure that smaller contributors don't get forgotten (alternatively look into "ActiveResource" has a simple way to solve the history issue, in order to get timestamps, use https://github.com/CyberTech/WikiText_to_RedMine_Migration as reference)
• [ ] Check if mmigration was sucessfull, with shell command diff, and using export of the whole wiki for comparing. For that use either simple script like https://stbuehler.de/blog/article/2011/06/04/exporting_redmine_wiki_pages.html, or we could also use the redmine plugin https://github.com/eugene-sy/redmine_wiki_hierarchical_export but we might need to contact server admins for that.

Usability¶

• [ ] use sphynx like skin for mediawiki (nice userfriendly implementation of mediawiki https://wiki.trezor.io/ ant there is good information on skining in https://supertuxkart.net/Maintaining_the_Wiki)

Archive¶

• [ ] Contact the Archive team to backup the redmine's wiki
• [ ] Make sure it gets archived completely on archive.org/web
• [ ] Make sure it gets archived in files that can be restored (but without non public information like password hashes, etc)

Rationale¶

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

• Migrate part of the information in Wikidata.
• Use template and/or generate information from Wikidata.

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.

• Practically speaking, it makes it impossible for many people that don't know how to program, to participate in Replicant, fix issues etc. This would be very problematic for diversity and inclusiveness of people as it would unnecessarily discriminate against people without such skills. We could also potentially loose important contributions.
• While it would make the job of contributors way easier than without any templating or ways to programmatically generate documentation, it also increase the dependency on people who knows how to use that documentation system.

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.

• It enables to reuse the information across different projects with similar goals (libreplanet wiki, Parabola wiki), different goals (for instance we could share the work of documenting hardware with the wikipedia and wikidata community), or through custom made tools.
• It can isolate the tasks requiring some programming to the strict minimum: Using programming in documentation systems can makes it easy to generate huge quantity of information, and Wikidata makes it possible to contribute to the information itself without knowing how to program. The programming is then potentially only required to fetch and show / format the information that comes from Wikidata.

Redmine wiki¶

• The table syntax of Redmine textile format is too complicated for several key contributors like dllud.
• It's probably hard to interface with Wikidata
• Javascript is required for the preview to work. GNUtoo has huge issues with that as it leads him to many bad editions that are fixed in subsequent editions that are fixed in subsequent editions...
• The syntax is less well known and the documentation is available on Redmine website but harder to find.
• No one seem to know the syntax for the templating system nor its limits yet.

Mediawiki¶

• Can be interfaced with Wikidata in various ways that are used in production on Wikipedia.
• The syntax is easy enough to use by people that don't know how to program, many people are used to it, and at the same time it's well documented.
• The table format is much easier to use, and it's usable by dllud.
• The main functionality, including the preview work completely without JavaScript, which leads to an increase of edits quality by people that don't run JavaScript from remote websites.
• Other projects like Libreplanet, and Parabola uses mediawiki, so we can probably reuse things across different wikis.
• Can be used offline thanks to projects like Kiwix
• Can be more easily backuped by external projects like the archive team
• We can probably reuse many templates from other wikis with compatible licensing, and some Replicant contributors like GNUtoo already know a bit the template language.
• There are probably many more tools compatible with mediawiki than the Redmine wiki.

• We need to migrate, if possible in a way that preserves history
• We loose the integration with redmine #<bug number> and will have to address this during the migration

Decision¶

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.

Formats¶

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: https://www.redmine.org/issues/32424 https://www.redmine.org/plugins/redmine_reformat https://github.com/orchitech/redmine_reformat https://hub.docker.com/r/orchitech/redmine-gfm

There is currently an RFC at MediaWiki about supporting CommonMark in MediaWiki natively: https://www.mediawiki.org/wiki/Requests_for_comment/Markdown

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: https://hub.docker.com/r/orchitech/redmine-gfm

Interfacing with Wikidata¶

Wikidata has documetation that claims that¹:

The access to Wikidata data is currently restricted to the Wikimedia projects, because of technical limitations. If you have your own instance of MediaWiki, you can't use Wikidata's data using these features. However, you can set up your own Wikibase instance and use data from there in the same way.

So here are some of the options we have:

• So we will either need to host our own Wikibase at the beginning or find another system to access the data.
• We could also just write a program that generates wiki pages and update that with git.
• We could also use an SQL interface to Wikidata and somehow hook that to mediawiki.

We also don't know the size of the database dumps as they are compressed²:

latest-all.json.bz2 28-Dec-2022 16:28 79404778391
latest-all.json.gz 04-Jan-2023 11:23 120635974570

Though Replicant source code is already big (more than 400GiB) so depending on how much space it takes it might not be a big issue.

Though we might need to have the FSF to host it in order to enable other FSDG distributions to access it.

Here's a list of what other distro use:

¹ https://www.wikidata.org/wiki/Wikidata:How_to_use_data_on_Wikimedia_projects#Can_I_access_Wikidata_data_from_my_wiki? Note that the '?' is part of the URL and that redmine has a bug with URLs ending with a '?'.

² https://dumps.wikimedia.org/wikidatawiki/entities/

³ https://libreplanet.org/wiki/Special:Version

⁴ https://wiki.parabola.nu/Special:Version

⁵ https://libreplanet.org/wiki/Main_Page

⁶ Content is available under GNU Free Documentation License 1.3. By contributing to any page on this wiki, you agree to assign copyright for your contribution to the Free Software Foundation (see LibrePlanet:Copyrights for details). The Free Software Foundation promises to always use either a verbatim copying license or a free documentation license when publishing your contribution. We grant you back all your rights under copyright, including the rights to copy, modify, and redistribute your contributions. You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. DO NOT SUBMIT COPYRIGHTED WORK WITHOUT PERMISSION!

⁷ https://creativecommons.org/licenses/by-sa/3.0/

⁸ https://wiki.parabola.nu/Main_Page

⁹ https://creativecommons.org/licenses/by-sa/4.0/

¹⁰ https://wiki.hyperbola.info/doku.php?id=en:start

¹¹ http://creativecommons.org/licenses/by-sa/4.0/

¹² https://librecmc.org/fossil/librecmc/wiki?name=home

¹³ https://creativecommons.org/licenses/by-sa/4.0/

References:¶

https://git.replicant.us/contrib/irelativism/wiki-migration-scripts/

Annexes¶

https://docs.bitnami.com/installer/how-to/configure-advanced-integration-git-redmine/
https://docs.bitnami.com/installer/apps/redmine/configuration/use-git/
https://www.redmine.org/projects/redmine/wiki/HowTo_configure_Redmine_for_advanced_git_integration
inspiration https://gist.github.com/tim-jansen/6263586
for usage parameters and variables use https://github.com/likema/redmine-exporter has reference
look into this for inspiration https://github.com/vile/redmine2confluence-wiki
inspiration http://stbuehler.de/blog/article/2011/06/04/exporting_redmine_wiki_pages.html

Network Infrastructure¶

OSUOSL¶

The OSUOSL is the Oregon State University Open Source Lab.

• They can be contacted on #osuosl on the Freenode IRC network
• They also have a 'support' mail address at osuosl.org

Virtual machine in FSF's infrastructure¶

• The virtual machine is hosted in a server that is in their office or in a datacenter.
• Several FSF network administrator also have access to the virtual machine

• The 'sysadmin' mail address at gnu.org
• The FSF system administrators can also be contacted on #fsfsys on the Freenode IRC network for more urgent matters

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:

/dev
/proc
/tmp
/sys
/run
/mnt
/mnt0
/mnt1
/mnt2
/mnt3
/mnt4
/mnt5
/mnt6
/mnt7
/mnt8
/mnt9
/floppy/
/cdrom/
/media/
/net/
/var/spool/squid/
/var/spool/squid3/
/var/spool/squid3_bak/
/var/spool/squid-tbd/
/var/spool/squid*/
/var/spool/django/
/var/spool/exim/
/var/cache/
/srv/chroot/
/t
/srv/to-tape
/var/lib/ceph/osd/
/var/lib/apt/lists/
/var/cache/apt/

git hosting infrastructure on this machine¶

• Replicant source code
• LineageOS mirror
• AOSP mirror
• Various developers repositories

Gandi¶

• See https://en.wikipedia.org/wiki/Gandi for more details

Freenode¶

GDPR¶

• For GDPR related inquiries, you can write to the PrivateContact mail address.

TODO:¶

• Ask the OSUOSL about backup policies. The OSUOSL will do backup of the FTP for us.
• Document public spaces like Liber chat IRC channel.
• Do our own backup policies and do some backups ourselves.
• Contact the people that have some control of the resources above and ask for permission to mention them here
• Fill the gaps (mentioned with '?') in this page
• Look what happens when an account is deleted
• Fix the related issues in the tracker
• Move the entries of this TODO list to the tracker when it makes sense

Funding and legal entity¶

See the SteeringCommittee for more details.

Legal advise¶

Contact Zoë Kooyman at the FSF.

Note that Zoë Kooyman is not a lawyer but the FSF has lawyers.

Documentation¶

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

Replicant-bridge¶

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: https://git.replicant.us/infrastructure/matterbridge/

RSS¶

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.

Distros¶

Projects¶

• git2rss: https://git.remirepo.net/cgit/tools/git2rss.git

Virtual machine specifications¶

• About 6G of RAM
• 2 virtual core
• a 500G storage partition on an HDD for everything.
• One public IPv4 (18.4.89.63) but no public IPv6

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:

Software:¶

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. The encryption is now handled transparently (outside of the VM? in btrfs?).

Replicant infrastructure Wiki¶

• Table of contents
• Replicant infrastructure Wiki
  • Current infrastructure
  • Maintenance information
  • Tools
  • Research
  • License

Current infrastructure¶

• NetworkInfrastructure: main description of the infrastructure

Maintenance information¶

• AddingANewDomain: How to add a new domain
• contactAddress: Technical infrastructure behind the contact address
• DNS: Technical infrastructure behind the DNS
• FilteringSpamOnTheMailingList: How to filter spam manually on the mailing list
• FSF infrastructure and Replicant infrastructure at the FSF:
  • FSFVMConfigurationManagement:
  • FSFVM: Documentation for deploying VMs at the FSF
  • FSFVMRootAccess: Root access setup in the Replicant VM and and general requirements for the FSF infrastructure.
  • GRUBCrypt: Upstreaming grub crypt patches to enable other FSDG compliant distributions than Trisquel on the FSF infrastructure
  • VMSpecifications: Software (OS) and virtual hardware (RAM, etc) specfications
• gitHosting: Infrastructure to host git repositories
  • GitRedirects: How are handled redirects for our git.replicant.us server and why we have to handle it
  • ContribRepositories: How to open a new space for a new contributor
• InCaseOfRedmineRgistrationIssues: What to do when the registration mail doesn't arrive
• IRC: How to manage the Replicant IRC channels
  • Replicant-bridge: How to run the Replicant-bridge bridge
• MailingListSoftware: Software to run mailing lists, bridging them with forums, etc
• Mastodon: Information about the Replicant Mastodon account.
• Wordpress: Information about our Wordpress instance (at OSUOSL).

Tools¶

• HowToVerifyAnEmail: HOWTO for verifying the provenance of an email

Research¶

• ConfigurationManagement: Research on various configuration management
• Forges
• InfrastructureEfficency
• MediawikiMigration: Documentation on how to migrate from the Redmine wiki to mediawiki.
• RSS: How to fix the broken RSS link on www.replicant.us

License¶

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

Wordpress¶

Plugins¶

Replicant also has a modified Post Notification by Email modified by Paul Kocialkowski from version Version 4.1.2 of Post Notification by Email.

Research on markdown with Wordpress.¶

Using markdown through Haunt.¶

There is work in progress to migrate the Wordpress blog to a static website that uses markdown.

Haunt is a good candidate for that and there was some work to try it out in the contrib/GNUtoo/haunt-blog repository.

So until this work is finished, we can still use that work to work on blog posts with a markdown format and then convert that markdown to html suitable for Wordpress.

To do that, you can follow the README of this project.