The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-07-02T19:46:43Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33262Prop 313: 3. Write a Script that Counts IPv6 Relays in the Consensus2020-07-02T19:46:43ZteorProp 313: 3. Write a Script that Counts IPv6 Relays in the ConsensusWe want to write a script that generates statistics for relays that:
1. have an IPv6 ORPort,
2. support IPv6 clients,
3. support IPv6 reachability checks, and
4. support IPv6 reachability checks, and IPv6 clients.
The first two ...We want to write a script that generates statistics for relays that:
1. have an IPv6 ORPort,
2. support IPv6 clients,
3. support IPv6 reachability checks, and
4. support IPv6 reachability checks, and IPv6 clients.
The first two statistics have no dependencies. The last two statistics depend on the "Relay=3" subprotocol in legacy/trac#33226.
The script should calculate:
* the number of relays, and
* the consensus weight fraction of relays.
In order to provide easy access to these statistics, we propose
that the script should:
* download a consensus (or read an existing consensus), and
* calculate and report these statistics.
We could write this script using Python 3 and Stem:
https://stem.torproject.org
The following consensus weight fractions should divide by the total
consensus weight:
* have an IPv6 ORPort (all relays have an IPv4 ORPort), and
* support IPv6 reachability checks (all relays support IPv4 reachability).
The following consensus weight fractions should divide by the
"usable Guard" consensus weight:
* support IPv6 clients, and
* support IPv6 reachability checks and IPv6 clients.
"Usable Guards" have the Guard flag, but do not have the Exit flag. If the
Guard also has the BadExit flag, the Exit flag should be ignored.
The script should check that Wgd is 0. If it is not, the script
should log a warning about the accuracy of the "Usable Guard" statistics.
See proposal 313, section 3:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n82Sponsor 55: Improving the Tor network’s IPv6 supportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33052O1.5 - Measure the number of connections, and consumed bandwidth, using IPv4 ...2020-08-14T12:38:04ZGabagaba@torproject.orgO1.5 - Measure the number of connections, and consumed bandwidth, using IPv4 and IPv6See Proposal 313: Relay IPv6 Statistics:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt
The child tickets are in proposal section order, but they will probably be implemented in this order:
Pre-Implem...See Proposal 313: Relay IPv6 Statistics:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt
The child tickets are in proposal section order, but they will probably be implemented in this order:
Pre-Implementation Bugs:
* Fix: Tor relays ignore some local bytes in their statistics
* Diagnose: ConnDirectionStatistics is off by default, but most relays report it
Dependencies:
* (None)
Implementation:
* Collect IPv6 Bandwidth Stats on Relays and Bridges
* Collect IPv6 Connection Stats on Relays
* Update Directory Spec for IPv6 Stats
Internal Testing:
* Test IPv6 Statistics using Chutney (O1.3, legacy/trac#33271)
Public Tor Network Testing:
* Test IPv6 Stats on the Tor Network
Metrics Analysis:
* Analyse and Monitor IPv6 Stats
Children:
* [x] tor#33159 Write a proposal for monitoring IPv6
* [x] tor#33263 Prop 313: 4. Collect IPv6 Bandwidth Stats on Relays and Bridges
* [x] tor#33264 Prop 313: 5. Collect IPv6 Connection Stats on Relays
* [x] tor#33201 Tor relays ignore some local bytes in their statistics
* [x] tor#33265 Prop 313: 6. Update Directory Spec for IPv6 Stats
* [ ] tor#33617 Add a BandwidthStatistics option and consensus parameter
* [x] tor#33272 Prop 313: 8.2. Test IPv6 Stats on the Tor Network
* [ ] #33273 [Prop 313: 8.2. Analyse and Monitor IPv6 Stats ](https://gitlab.torproject.org/tpo/metrics/analysis/-/issues/33273)
* [x] tor#33214 ConnDirectionStatistics is off by default, but most relays report itSponsor 55: Improving the Tor network’s IPv6 supporthttps://gitlab.torproject.org/tpo/core/tor/-/issues/33051O1.4 - Measure the number of Tor relays that support IPv6 reachability checks2020-08-14T12:34:03ZGabagaba@torproject.orgO1.4 - Measure the number of Tor relays that support IPv6 reachability checksSee Proposal 313: Relay IPv6 Statistics:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt
Tor's IPv6 reachability checks are described in:
Proposal 311: Tor Relay IPv6 Reachability:
https://gitweb.torpro...See Proposal 313: Relay IPv6 Statistics:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt
Tor's IPv6 reachability checks are described in:
Proposal 311: Tor Relay IPv6 Reachability:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt
The child tickets are in proposal section order, but they will probably be implemented in this order:
Dependencies:
* Prop 311: 5. Declare Support for Subprotocol Version "Relay=3" (O1.1, legacy/trac#33226)
Implementation:
* Write a Script that Counts IPv6 Relays in the Consensus
Metrics Review:
* Check IPv6 Relay Consensus Counts Script
Internal Testing:
* Test IPv6 Relay Consensus Counts using Chutney (O1.3, legacy/trac#33267)
Public Tor Network Testing:
* Test IPv6 Relay Consensus Counts on the Tor Network
Monitoring:
* Monitor IPv6 Relay Counts in the Consensus
Children:
* [x] tor#33262 Prop 313: 3. Write a Script that Counts IPv6 Relays in the Consensus
* [x] trac#33266 [Prop 313: 7.2. Show IPv6 Relay Counts on Consensus Health ](https://gitlab.torproject.org/tpo/metrics/consensus-health/-/issues/33266)
* [x] tor#33268 Prop 313: 8.1. Test IPv6 Relay Consensus Counts on the Tor Network
* [x] trac#33269 [Prop 313: 8.1. Check IPv6 Relay Consensus Counts Script](https://gitlab.torproject.org/tpo/metrics/analysis/-/issues/33269)
* [x] tor#33270 Prop 313: 8.1. Monitor IPv6 Relay Counts in the ConsensusSponsor 55: Improving the Tor network’s IPv6 supporthttps://gitlab.torproject.org/tpo/core/tor/-/issues/40117Onion service rendezvous cell statistics don't count client->service traffic.2022-07-07T00:48:31ZGeorge KadianakisOnion service rendezvous cell statistics don't count client->service traffic.While working on #23126 we found that v2 rendezvous cell stats don't count client->service traffic.
The patch is pretty simple, but will probably influence the shape of the graphs at https://metrics.torproject.org/hidserv-rend-relayed-c...While working on #23126 we found that v2 rendezvous cell stats don't count client->service traffic.
The patch is pretty simple, but will probably influence the shape of the graphs at https://metrics.torproject.org/hidserv-rend-relayed-cells.html .Tor: 0.4.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/network-health/team/-/issues/74Come up with a plan to make past descriptors etc. easier available and querya...2021-09-10T22:09:16ZGeorg KoppenCome up with a plan to make past descriptors etc. easier available and queryable (giant database)We should make past descriptors and other network status documents easier available at least for dev purposes (maybe in a giant database) as this would help a lot with all sorts of tasks (e.g. analyzing bw measurement anomalies, bad-rela...We should make past descriptors and other network status documents easier available at least for dev purposes (maybe in a giant database) as this would help a lot with all sorts of tasks (e.g. analyzing bw measurement anomalies, bad-relay work , bwauthealthetc.). This ticket is for all the planning work. Once we've found a good way forward we'll open new tickets for the actual work.Metrics OKRs 2021HiroHirohttps://gitlab.torproject.org/tpo/core/tor/-/issues/26829torspec: bandwidth file generators should write the file atomically2021-07-22T16:20:36Zteortorspec: bandwidth file generators should write the file atomicallyGenerators should either:
* write the file to a temporary location, then rename it to the final path, or
* write the file to an archival location, then symlink it to the final pathGenerators should either:
* write the file to a temporary location, then rename it to the final path, or
* write the file to an archival location, then symlink it to the final pathTor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26827torspec: DirAuths should only read the V3BandwidthsFile once per vote2021-07-22T16:20:36Zteortorspec: DirAuths should only read the V3BandwidthsFile once per voteOnce legacy/trac#26797 is implemented, we should document it in the spec.Once legacy/trac#26797 is implemented, we should document it in the spec.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40158Specify overload relay descriptors for load balancing and network health2023-03-17T11:44:35ZMike PerrySpecify overload relay descriptors for load balancing and network healthWe need to specify descriptor fields to signify when relays:
1. [ ] Are at or near CPU overload
2. [ ] Are at or near OOM killer invocation
3. [ ] Are at or near connection count limits
4. [ ] At or near their token bucket limit
5. [ ] ...We need to specify descriptor fields to signify when relays:
1. [ ] Are at or near CPU overload
2. [ ] Are at or near OOM killer invocation
3. [ ] Are at or near connection count limits
4. [ ] At or near their token bucket limit
5. [ ] Accumulating too many cells in queues (circuitmux, tls outbuf, aes)
6. [ ] Are failing too many onionskins, tls handshakes, other things?
7. [ ] Flag/checks to signify which relays are on the same machine
The specification should only emit enough information to determine if relays are at or near various forms of overload. They should *not* report detailed statistics, as these may aid in DoS attacks and traffic analysis.
With this information, we will use sbws to avoid allocating extra load to these relays, as well as use these fields to report unhealthy relays on the metrics portal, and investigate other misbehavior.
I can work on this spec but I will need much input from @dgoulet.Sponsor 61 - Making the Tor network faster & more reliable for users in Internet-repressive placesDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/onion-services/onionprobe/-/issues/74Make it easier to setup Tor's MetricsPort2023-03-30T18:27:51ZSilvio RhattoMake it easier to setup Tor's MetricsPortRight now there are a number of files to be edited in order to have Tor metrics into Prometheus.
Make it easier to setup `MetricsPort` at the standalone monitoring node.Right now there are a number of files to be edited in order to have Tor metrics into Prometheus.
Make it easier to setup `MetricsPort` at the standalone monitoring node.Sponsor 123: Tor Secure Access Package for USAGM [First Phase]Silvio RhattoSilvio Rhatto2023-04-03https://gitlab.torproject.org/tpo/onion-services/onionprobe/-/issues/71Tor metrics Prometheus exporter2023-03-30T17:04:06ZSilvio RhattoTor metrics Prometheus exporterSetup a Tor metrics Prometheus exporter, so Onionprobe could have two distinct
Prometheus exporters:
1. The default, existing one with Onionprobe metrics.
2. Another with the Tor process metrics.
Tasks:
* [x] Add an Option to setup a ...Setup a Tor metrics Prometheus exporter, so Onionprobe could have two distinct
Prometheus exporters:
1. The default, existing one with Onionprobe metrics.
2. Another with the Tor process metrics.
Tasks:
* [x] Add an Option to setup a `MetricsPort` and `MetricsPortPolicy`
on the spawned Tor process, but disabled by default.
* [x] Include it also on the Prometheus collection and make it
available as a Grafana dashboard, but disabled by default.
* [x] Add a warning/document somewhere that this setting should be used with care.
* [x] Document how to enable the feature in the standalone monitoring node,
including again the warnings about this setting.
Documentation: https://gitlab.torproject.org/tpo/core/tor/-/issues/40762Sponsor 123: Tor Secure Access Package for USAGM [First Phase]Silvio RhattoSilvio Rhatto2023-04-04https://gitlab.torproject.org/tpo/onion-services/onion-launchpad/-/issues/66Frontend support for Matomo analytics2023-05-16T14:34:32ZSilvio RhattoFrontend support for Matomo analyticsOnion Launchpad implementation of Matomo analytics according to [this proposal][].
## Requirements
1. [x] The feature MUST be *disabled* by default, and enabled only if some
environment variables are set (like the analytics endp...Onion Launchpad implementation of Matomo analytics according to [this proposal][].
## Requirements
1. [x] The feature MUST be *disabled* by default, and enabled only if some
environment variables are set (like the analytics endpoint and a site ID/key).
2. [x] There MUST be documentation stating that this feature, even with a better
configuration in terms of privacy, could still be a point of collecting
access data without passing to the Tor network for better anonymization. And
also would rely on additional JavaScript code embedded in the landing page.
3. [x] Services operators MUST be recommended to host the backend only behind an
HTTPS proxy without IP logging (and without passing the source IP to the
backend, so if there's any backend vulnerability it won't be possible to
attackers to discover user's IP addresses). ___Or even better: leave the
backend behind an Onion Service___.
4. [x] There MUST be a [consent UX][] informing users what and how it's collected,
and asking for authorization. No cookies should reside in the client machine.
## Implementation details
* [x] Plug the [Clean Insights JS SDK][] or the [Matomo JS SDK][] into [Onion Launchpad][].
* [x] Enable the metrics collection only if explicitly set by an environment variable during build time.
* [x] Implement a [consent UX][].
* [x] Implement the page hits collection.
* [x] Document the [analytics collection threat model][] (subsection "Landing page metrics" of this link/comment).
[analytics collection threat model]: https://gitlab.torproject.org/tpo/onion-services/onion-launchpad/-/issues/39#note_2854486
## Scope
This ticket covers:
* Basic functionality without censorship protection for the metrics system.
* Description: in this phase, the whole implementation is completed.
This ticket does not cover:
* The backend development.
* Implementing censorship protection for the metrics system.
* Content and styling for the consent UX (handled in a [distinct ticket][]).
[this proposal]: https://gitlab.torproject.org/tpo/onion-services/onion-launchpad/-/issues/39#note_2854486
[Onion Launchpad]: https://gitlab.torproject.org/tpo/onion-services/onion-launchpad
[distinct ticket]: tpo/onion-services/onion-launchpad#67
[Clean Insights JS SDK]: https://gitlab.com/cleaninsights/clean-insights-js-sdk
[Matomo JS SDK]: https://developer.matomo.org/guides/tracking-javascript-guide
[consent UX]: https://okthanks.com/blog/2021/5/14/clean-consent-uxSponsor 123: Tor Secure Access Package for USAGM [First Phase]Silvio RhattoSilvio Rhatto2023-01-20https://gitlab.torproject.org/tpo/onion-services/onion-support/-/issues/162Get EOTK stats for Sponsor 123 during November 20222022-12-08T19:28:07ZSilvio RhattoGet EOTK stats for Sponsor 123 during November 2022* [x] Get statistics for the November 2022 Narrative Report as [per contract](https://nc.torproject.net/apps/onlyoffice/242116?filePath=%2FSponsors%2FS123%20-%20USAGM%2FSubmitted%20Documents%2F2021-09-17%20Tor%20Secure%20Access%20-%20OTF...* [x] Get statistics for the November 2022 Narrative Report as [per contract](https://nc.torproject.net/apps/onlyoffice/242116?filePath=%2FSponsors%2FS123%20-%20USAGM%2FSubmitted%20Documents%2F2021-09-17%20Tor%20Secure%20Access%20-%20OTF%20TaS%20Narrative-1-20-2022_203_PM.docx):
* [x] Uptime of USAGM .onion addresses.
* [x] Number of visitors to USAGM .onion addresses (page hits, if `HiddenServiceExportCircuitID` data is not available).
* [x] Make sure that Onionprobe data is filtered out.
* [x] [Progress Tracker](https://nc.torproject.net/apps/onlyoffice/296583?filePath=%2FOnion%20Services%2FOnion%20Support%2FS123%20Progress%20Tracker.ods) (or a standalone sheet): statistics subsheet built from [eotk-log-parser](https://gitlab.torproject.org/tpo/onion-services/eotk-log-parser).
* [x] Create the ticket for the next stats gathering.
/cc @rayaSponsor 123: Tor Secure Access Package for USAGM [First Phase]Silvio RhattoSilvio Rhatto2022-12-01https://gitlab.torproject.org/tpo/onion-services/onion-launchpad/-/issues/39Create a privacy-preserving landing page analytics roadmap for S1232022-11-23T15:08:02ZrayaCreate a privacy-preserving landing page analytics roadmap for S123Following on from the discussion which started in the July 2022 narrative report [ticket](https://gitlab.torproject.org/tpo/onion-services/onion-support/-/issues/130#note_2823857), we need to discuss next steps for implementing a method ...Following on from the discussion which started in the July 2022 narrative report [ticket](https://gitlab.torproject.org/tpo/onion-services/onion-support/-/issues/130#note_2823857), we need to discuss next steps for implementing a method to collect the number of visitors per S123 landing page.
Copy-pasting the 4 steps suggested by @rhatto to plug Clean Insights (which is based on Matomo and built by The Guardian Project):
> 1. Frontend modifications into the existing landing page code to plug [Clean Insights JS SDK](https://gitlab.com/cleaninsights/clean-insights-js-sdk).
> 2. Consider that this will need some [consent UX](https://okthanks.com/blog/2021/5/14/clean-consent-ux).
> 3. Setting up [Clean Insights Infrastructure](https://gitlab.com/cleaninsights/clean-insights-infrastructure) in a new virtual machine (and maintaining that machine).
> 4. Making sure that landing page deployments from the same service always use the same `siteId` (so stats will be gathered no matter how many mirrors exists and where they're hosted).
I made the issue confidential but I don't believe it needs to be!
cc: @rhattoSponsor 123: Tor Secure Access Package for USAGM [First Phase]Silvio RhattoSilvio Rhatto2022-11-30https://gitlab.torproject.org/tpo/onion-services/onionprobe/-/issues/55Setup Onionprobe meeting to evaluate next steps2022-08-12T23:38:06ZSilvio RhattoSetup Onionprobe meeting to evaluate next stepsAs discussed with @gus in our 2022-06-01 1:1 meeting, we could setup a meeting to discuss:
1. What we've done so far with Onionprobe. What it can do (now and in the future).
2. Gather new ideas.
3. Think about how to integrate with metr...As discussed with @gus in our 2022-06-01 1:1 meeting, we could setup a meeting to discuss:
1. What we've done so far with Onionprobe. What it can do (now and in the future).
2. Gather new ideas.
3. Think about how to integrate with metrics, like:
* Monitoring the health of Onion Service descriptors (reachability and latency).
Who to invite:
* Someone from the Network Team.
* Someone from the Network Health Team.
* Someone from TPA.Sponsor 123: Tor Secure Access Package for USAGM [First Phase]Silvio RhattoSilvio Rhattohttps://gitlab.torproject.org/tpo/onion-services/onion-support/-/issues/109Write a script to gather EOTK stats from logs hosted on AWS S3 buckets2022-06-03T12:44:53ZSilvio RhattoWrite a script to gather EOTK stats from logs hosted on AWS S3 bucketsWrite a script to gather EOTK stats. Related to [this Bypass Censorship Dashboard issue](https://gitlab.com/guardianproject/bypass-censorship/analytics-dashboard/-/issues/1).Write a script to gather EOTK stats. Related to [this Bypass Censorship Dashboard issue](https://gitlab.com/guardianproject/bypass-censorship/analytics-dashboard/-/issues/1).Sponsor 123: Tor Secure Access Package for USAGM [First Phase]Silvio RhattoSilvio Rhatto2022-06-08https://gitlab.torproject.org/tpo/onion-services/onionprobe/-/issues/52Create separate metrics for HSDir info and timestamp of last update2022-05-27T17:54:18ZSilvio RhattoCreate separate metrics for HSDir info and timestamp of last updateCreate separate metrics for HSDir info (`hsdir` and `reason`) and timestamp of last update instead of using labels for both, as labels for such variable information creates additional time series.Create separate metrics for HSDir info (`hsdir` and `reason`) and timestamp of last update instead of using labels for both, as labels for such variable information creates additional time series.Sponsor 123: Tor Secure Access Package for USAGM [First Phase]Silvio RhattoSilvio Rhattohttps://gitlab.torproject.org/tpo/onion-services/onion-support/-/issues/99General policy on how the Onion Support team should respond to Onionprobe alerts2022-09-27T09:49:18ZSilvio RhattoGeneral policy on how the Onion Support team should respond to Onionprobe alertsWrite a small quick policy in what to do when an incident happen and are detected/notified by Onionprobe, including:
* Inform the interested parties (like Sponsors and/or users) of the issue, if needed.
* Check agreement when/where admi...Write a small quick policy in what to do when an incident happen and are detected/notified by Onionprobe, including:
* Inform the interested parties (like Sponsors and/or users) of the issue, if needed.
* Check agreement when/where admins allow to be notified.
* Then check if admins online (or on shift) can work on it (depends on agreed channels and current time):
* Ping on IRC.
* Ping on email.
* Ping on Signal.
* Ping on X.
This policy should be available at the Onion Support wiki.Sponsor 123: Tor Secure Access Package for USAGM [First Phase]Silvio RhattoSilvio Rhatto2022-08-31https://gitlab.torproject.org/tpo/onion-services/onionprobe/-/issues/15Review metrics names and types2022-06-02T18:31:59ZSilvio RhattoReview metrics names and typesReview metrics names and types (use "elapsed" instead of "latency", "query" instead of "fetch" etc).Review metrics names and types (use "elapsed" instead of "latency", "query" instead of "fetch" etc).Sponsor 123: Tor Secure Access Package for USAGM [First Phase]Silvio RhattoSilvio Rhattohttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40750materculae hits the OOM killer since bullseye upgrade2022-06-27T15:00:11Zanarcatmaterculae hits the OOM killer since bullseye upgradelast night (from my perspective), PostgreSQL crashed on materculae. in systemd's logs, we see:
```
May 05 05:25:33 materculae systemd[1]: postgresql@13-main.service: A process of this unit has been killed by the OOM killer.
```
then a ...last night (from my perspective), PostgreSQL crashed on materculae. in systemd's logs, we see:
```
May 05 05:25:33 materculae systemd[1]: postgresql@13-main.service: A process of this unit has been killed by the OOM killer.
```
then a bunch of errors happened in the postgresql log:
```
2022-05-05 05:25:33 GMT LOG: server process (PID 16279) was terminated by signal 9: Killed
2022-05-05 05:25:33 GMT DETAIL: Failed process was running: select * from search_by_date_address24($1, $2) as result
2022-05-05 05:25:33 GMT LOG: terminating any other active server processes
2022-05-05 05:25:33 GMT WARNING: terminating connection because of crash of another server process
2022-05-05 05:25:33 GMT DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.
2022-05-05 05:25:33 GMT HINT: In a moment you should be able to reconnect to the database and repeat your command.
```
it's unclear why this is happening, but it's clearly a regression from the upgrade. here's a memory graph from the last 3 days:
![image](/uploads/839a371de3d308807d2f3394d39977c7/image.png)
https://grafana.torproject.org/d/xfpJB9FGz/1-node-exporter-for-prometheus-dashboard-en-v20201010?orgId=1&var-origin_prometheus=&var-job=node&var-hostname=All&var-node=materculae.torproject.org:9100&var-device=All&var-interval=2m&var-maxmount=%2Fhome&var-show_hostname=materculae&var-total=93&viewPanel=156&from=now-3d&to=now&refresh=1m
i *think* the upgrade completed at about 15:26 UTC yesterday, at least according to the graph. (this comment is later, but that's probably just me reporting after the fact: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40692#note_2799945).
then we can see the server restarting (the blank), and slowly reclaiming memory. then there's this unusual jump at 22:18 and things go a little out of whack for a few hours, but seem to stabilise at a somewhat reasonable pattern at 11:00 next day. that's about 1GB more memory usage than the previous normal though, so that's already a little worrisome.
but then, at 22:46UTC, memory usage just starts to grown linearly, eventually hitting the above OOM at around 5:30 or so.
it seems we don't have prometheus instrumentation for postgresql on that host at all right now, so i guess that would be one next step.
/cc @hiroDebian 11 bullseye upgradeanarcatanarcathttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40809upgrade meronense to PostgreSQL 132022-07-22T17:19:13Zanarcatupgrade meronense to PostgreSQL 13as part of the second batch of upgrades (tpo/tpa/team#40692), we need to upgrade meronense to PostgreSQL 13
opening a ticket because the standard procedure failedas part of the second batch of upgrades (tpo/tpa/team#40692), we need to upgrade meronense to PostgreSQL 13
opening a ticket because the standard procedure failedDebian 11 bullseye upgradeanarcatanarcat