From f31d25a82242b4e7dbfb9602fb8e5635139ef8de Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= <anarcat@debian.org> Date: Thu, 25 Aug 2022 09:57:53 -0400 Subject: [PATCH] merge template into service/survey.md, still to be filled in This is mostly so I can document the new ~Survey tag in GitLab. --- service/survey.md | 131 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 131 insertions(+) diff --git a/service/survey.md b/service/survey.md index cbc73394..96b7646f 100644 --- a/service/survey.md +++ b/service/survey.md @@ -62,6 +62,12 @@ in case of problems during an upgrade. [LimeSurvey latest stable release page]: https://account.limesurvey.org/stable-release [admin interface]: https://survey.torproject.org/admin +## Pager playbook + +<!-- information about common errors from the monitoring system and --> +<!-- how to deal with them. this should be easy to follow: think of --> +<!-- your future self, in a stressful situation, tired and hungry. --> + ## Disaster recovery In case of a disaster restoring both `/srv` and the PostgreSQL database on a @@ -69,9 +75,134 @@ new server should be sufficient to get back up and running. # Reference +## Installation + +<!-- how to setup the service from scratch --> + +## SLA + +<!-- this describes an acceptable level of service for this service --> + ## Design This service runs on a standard Apache/PHP/PostgreSQL stack. Self-hosting a LimeSurvey instance allows us to better safeguard user-submitted data as well as allowing us to make it accessible through an onion service. + +<!-- how this is built --> +<!-- should reuse and expand on the "proposed solution", it's a --> +<!-- "as-built" documented, whereas the "Proposed solution" is an --> +<!-- "architectural" document, which the final result might differ --> +<!-- from, sometimes significantly --> + +<!-- a good guide to "audit" an existing project's design: --> +<!-- https://bluesock.org/~willkg/blog/dev/auditing_projects.html --> + +<!-- things to evaluate here: + + * services + * storage (databases? plain text files? cloud/S3 storage?) + * queues (e.g. email queues, job queues, schedulers) + * interfaces (e.g. webserver, commandline) + * authentication (e.g. SSH, LDAP?) + * programming languages, frameworks, versions + * dependent services (e.g. authenticates against LDAP, or requires + git pushes) + * deployments: how is code for this deployed (see also Installation) + +how is this thing built, basically? --> + +## Issues + +<!-- such projects are never over. add a pointer to well-known issues --> +<!-- and show how to report problems. usually a link to the --> +<!-- issue tracker. consider creating a new Label to regroup the --> +<!-- issues if using the general tracker. see also TPA-RFC-19. --> + +There is no issue tracker specifically for this project, [File][] or +[search][] for issues in the [team issue tracker][search] with the +label ~Survey. + + [File]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/new + [search]: https://gitlab.torproject.org/tpo/tpa/team/-/issues?label_name%5B%5D=Survey + +## Maintainer, users, and upstream + +<!-- document who deployed and operates this service, who the users --> +<!-- are, who the upstreams are, if they are still active, --> +<!-- collaborative, how do we keep up to date, --> + +## Monitoring and testing + +<!-- describe how this service is monitored and how it can be tested --> +<!-- after major changes like IP address changes or upgrades. describe --> +<!-- CI, test suites, linting, how security issues and upgrades are --> +<!-- tracked --> + +## Logs and metrics + +<!-- where are the logs? how long are they kept? any PII? --> +<!-- what about performance metrics? same questions --> + +## Backups + +<!-- does this service need anything special in terms of backups? --> +<!-- e.g. locking a database? special recovery procedures? --> + +## Other documentation + +<!-- references to upstream documentation, if relevant --> + +# Discussion + +<!-- the "discussion" section is where you put any longer conversation --> +<!-- about the project that you will not need in a casual --> +<!-- review. history of the project, why it was done the way it was --> +<!-- (as opposed to how), alternatives, and other proposals are --> +<!-- relevant here. --> + +<!-- this at least partly overlaps with the TPA-RFC process (see --> +<!-- policy.md), but in general should defer to proposals when --> +<!-- available --> + +## Overview + +<!-- describe the overall project. should include a link to a ticket --> +<!-- that has a launch checklist --> + +<!-- if this is an old project being documented, summarize the known --> +<!-- issues with the project. --> + +## Security and risk assessment + +<!-- + + 5. When was the last security review done on the project? What was + the outcome? Are there any security issues currently? Should it + have another security review? + + 6. When was the last risk assessment done? Something that would cover + risks from the data stored, the access required, etc. + +--> + +## Technical debt and next steps + +<!-- + + 7. Are there any in-progress projects? Technical debt cleanup? + Migrations? What state are they in? What's the urgency? What's the + next steps? + + 8. What urgent things need to be done on this project? + +--> + +## Proposed Solution + +<!-- Link to RFC --> + +## Other alternatives + +<!-- include benchmarks and procedure if relevant --> -- GitLab