diff --git a/service.md b/service.md index 1bcb59628394950b35de2c095227b708c279c3bb..b104d64ec9dd599f3af11f77ff3a0a79df8af55b 100644 --- a/service.md +++ b/service.md @@ -88,6 +88,7 @@ The Service Admins maintain the following list of Tor Services. | Service | Purpose | URL | Maintainers | Documented | Auth | |------------------------|-------------------------------------------------------|-----------------------------------------|-----------------------------|------------|-------------------------------| +| [anon_ticket][] | Anonymous ticket lobby for GitLab | <https://anonticket.torproject.org/> | ahf, juga | 10% | no | | [apps team builders][] | build Tor Browser and related | N/A | richard | 10% | LDAP | | [BBB][] | Video and audio conference system | <https://tor.meet.coop> | gaba, gus | - | yes (see [policy][]) | | [blog][] | Weblog site | <https://blog.torproject.org/> | lavamind, gus | 90% | GitLab | diff --git a/service/anon_ticket.md b/service/anon_ticket.md new file mode 100644 index 0000000000000000000000000000000000000000..956a6dda7755d83cb07b8d48f351a0c94fe0d46e --- /dev/null +++ b/service/anon_ticket.md @@ -0,0 +1,202 @@ +A web application that allows users to create anonymous tickets on the Tor +Project's GitLab instance by leveraging the GitLab API. + +The project is developed in-house and hosted on GitLab at +[tpo/tpa/anon_ticket](https://gitlab.torproject.org/tpo/tpa/anon_ticket/). + +[[_TOC_]] + +<!-- note: this template was designed based on multiple sources: --> +<!-- https://diataxis.fr/ --> +<!-- http://opsreportcard.com/section/9--> +<!-- http://opsreportcard.com/section/11 --> +<!-- comments like this one should be removed on instantiation --> + +# Tutorial + +<!-- simple, brainless step-by-step instructions requiring little or --> +<!-- no technical background --> + +# How-to + +<!-- more in-depth procedure that may require interpretation --> + +## 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 + +<!-- what to do if all goes to hell. e.g. restore from backups? --> +<!-- rebuild from scratch? not necessarily those procedures (e.g. see --> +<!-- "Installation" below but some pointers. --> + +# Reference + +<!-- this section is a more in-depth review of how this service works, --> +<!-- how it's setup. day-to-day operation should be covered in --> +<!-- tutorial or how-to, this is more in-depth --> + +<!-- a good guide to "audit" an existing project's design: --> +<!-- https://bluesock.org/~willkg/blog/dev/auditing_projects.html --> +<!-- the following sections are partially based on that --> + +## Installation + +Prerequisite for installing this service is an LDAP role account. + +The service is mainly deployed via the `profile::anonticket` Puppet class, +which takes care of installing dependencies, configuring a postgresql +user/database, an nginx reverse proxy and systemd user service unit file. + +A Python virtual environment must then be manually provisioned in `$HOME/.env`, +and the `ticketlobby.service` user service unit file must then be enabled and +activated. + +## Upgrades + +<!-- how upgrades are performed. preferably automated through Debian --> +<!-- packages, otherwise document how upgrades are performed. see also --> +<!-- the Testing section below --> + +## SLA + +<!-- this describes an acceptable level of service for this service --> + +## Design and architecture + +<!-- how this is built --> +<!-- should reuse and expand on the "proposed solution" discussed in --> +<!-- a previous RFC or the Discussion section below. it's a --> +<!-- "as-built" documented, whereas the "Proposed solution" is an --> +<!-- "architectural" document, which the final result might differ --> +<!-- from, sometimes significantly --> + +## Services + +The nginx reverse proxy listens on the standard HTTP and HTTPS ports, handles +TLS termination, and forwards requests to the ticketlobby application. + +## Storage + +Persistent data is stored in a PostgreSQL database. + +## Queues + +<!-- email queues, job queues, schedulers --> + +## Interfaces + +<!-- e.g. web APIs, commandline clients, etc --> + +## Authentication + +<!-- SSH? LDAP? standalone? --> + +## Implementation + +<!-- programming languages, frameworks, versions, license --> + +## Related services + +<!-- dependent services (e.g. authenticates against LDAP, or requires --> +<!-- git pushes) --> + +## Issues + +This project has its own issue tracker at https://gitlab.torproject.org/tpo/tpa/anon_ticket/-/issues + +## Maintainer + +<!-- document who deployed and operates this service, the team and --> +<!-- ideally the person inside that team --> + +## Users + +<!-- who the main users are, how they use the service. possibly reuse --> +<!-- the Personas section in the RFC, if available. --> + +## Upstream + +<!-- who the upstreams are, if they are still active, --> +<!-- collaborative, how do we keep up to date, support channels, see --> +<!-- also the "Issues" section above --> + +## Monitoring and metrics + +<!-- describe how this service is monitored, how security issues and --> +<!-- upgrades are tracked, see also "Upgrades" above. --> + +## Tests + +<!-- how the service can be tested, for example after major changes --> +<!-- like IP address changes or upgrades. describe CI, test suites, linting --> + +## Logs + +<!-- 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 -->