Documenting securedrop.club sysadmin

DevOps
#1

Bonjour,

I propose we document all securedrop.club sysadmin in the securedrop-club repository. Including how and where DNS, hosting etc. are managed, who is part of the team, how to become part of the team etc.

Since SecureDrop is fully documented in RST it would be good to also use RST and the same documentation style guidelines.

I’m not sure when the documentation should be written but I’m convinced it must happen in the following weeks. Otherwise it may never happen. If we write it before weblate.securedrop.club is migrated from the current manual installation to the ansible based installation, we are likely to catch some inconsistencies. And we will be in a better position to fix them before going to production for the first time.

The downside of documenting everything before going to production with weblate is that it feels like procrastination :slight_smile:

What do you think ?

1 Like
#2

I propose we document all securedrop.club sysadmin in the securedrop-club repository. Including how and where DNS, hosting etc. are managed, who is part of the team, how to become part of the team etc.

Since SecureDrop is fully documented in RST it would be good to also use RST and the same documentation style guidelines.

Agreed.

I’m not sure when the documentation should be written but I’m convinced it must happen in the following weeks. Otherwise it may never happen.

Sure.

If we write it before weblate.securedrop.club is migrated from the current manual installation to the ansible based installation, we are likely to catch some inconsistencies. And we will be in a better position to fix them before going to production for the first time.

The downside of documenting everything before going to production with weblate is that it feels like procrastination :slight_smile:

I am not sure documentation should block production, a fortiori since we have a quite strong test/monitoring policy (then for me documentation is more a long term hygiene). Maybe part of it should (to be defined), but probably not all.

We have also hygienist guidelines to be defined. Doc is part of it.

Also, I am not used to with debops stuffs but as a dev I like to follow the CRUD paradigm. Then if I would write from scratch the infrastructure documentation, I would apply CRUD to write guidelines to an hypothetic (or not) service deployment:

  • howto deploy it (including doc, monitoring, backup (data dumps for easy restorations), security tracking, users notifications…).
  • howto exploit it (if needed).
  • howto amend it (in a CI way).
  • howto suspend it.
1 Like