Skip to content
Snippets Groups Projects
Verified Commit 00000401 authored by Jérôme Charaoui's avatar Jérôme Charaoui :telescope:
Browse files

service/anon_ticket: add basic docs (team#40577)

parent 9b0e8a7e
No related branches found
No related tags found
No related merge requests found
Pipeline #154758 passed with warnings
......@@ -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 |
  • Owner

    this is a broken link... and it's not the first time! could you make sure you cross-reference those pages properly when you add a service? :) i'll fix it this time because i need to push something else on this page and it breaks my local hooks...

  • Author Owner

    Yeah I'll definitely try to, but I keep forgetting because I don't have proper linting for this and I rarely update this page!

  • Owner

    I encourage you to set this up:

    anarcat@angela:help.torproject.org$ cat .git/hooks/pre-commit
    #!/bin/bash
    
    ${GIT_DIR:-.git}/../bin/mdl-wrapper $(git diff --cached --name-only HEAD)

    it's not as good as a pre-commit (which would also run codespell, for example), but is a start. :)

    Alternatively, we could just have a bin/lint script or something.

  • Please register or sign in to reply
| [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 |
......
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 -->
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment