The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-05-02T16:02:25Zhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40739replace the puppet agent job with a systemd timer2022-05-02T16:02:25Zanarcatreplace the puppet agent job with a systemd timerour current cron job is a little overly complicated: it has timeouts, a manual splay, and so on. in fact, it's *really* complicated. plus it doesn't retry at all, which is a problem with our recent puppetdb stuff (#40699).
the task here...our current cron job is a little overly complicated: it has timeouts, a manual splay, and so on. in fact, it's *really* complicated. plus it doesn't retry at all, which is a problem with our recent puppetdb stuff (#40699).
the task here is to convert the cron job into something more robust, maybe a script or, more likely, simply a systemd timer. the latter would have the advantage of showing failures in nagios's systemd monitoring. i think the requirements are:
- [x] progressive deployment so we only break one host at a time :p
- [x] not a daemon
- [x] "splay": don't run all jobs at once on all hosts...
- [x] ... yet still have a somewhat predictable frequency (e.g. "every four to six hours" is the current schedule, i *think*
- [x] handle timeouts?
- [x] look at the cron job to make sure we didn't miss anything elseJérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40726TPA-RFC-21: Uninstall subversion everywhere except gayi.tpo2022-04-19T13:37:53ZJérôme Charaouilavamind@torproject.orgTPA-RFC-21: Uninstall subversion everywhere except gayi.tpoThis package is installed on all our hosts but is very likely unused everywhere except `gayi.torproject.org`.
Remove it from the common packages list in Puppet and `apt remove` it from the relevant hosts.This package is installed on all our hosts but is very likely unused everywhere except `gayi.torproject.org`.
Remove it from the common packages list in Puppet and `apt remove` it from the relevant hosts.Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/network-health/metrics/timeline/-/issues/12[Turkmenistan] Shutdown 2022-04-112022-04-28T06:24:52ZDavid Fifielddcf@torproject.org[Turkmenistan] Shutdown 2022-04-11https://ntc.party/t/reported-shutdown-in-turkmenistan-2022-04-11/2224
Not sure if this is really a "shutdown". It may be extreme blocking of many services, but still with network routes functional. It may only be regional.https://ntc.party/t/reported-shutdown-in-turkmenistan-2022-04-11/2224
Not sure if this is really a "shutdown". It may be extreme blocking of many services, but still with network routes functional. It may only be regional.HiroHirohttps://gitlab.torproject.org/tpo/core/onionmasq/-/issues/9Arti runtime integration2022-04-22T13:23:36ZDavid Gouletdgoulet@torproject.orgArti runtime integrationThis is a rather large ticket but at the moment, we are able to route onionmasq traffic through the Tor network using arti.
But we need to go one step further. In particular, build a custom runtime so we can hijack any TCP connection th...This is a rather large ticket but at the moment, we are able to route onionmasq traffic through the Tor network using arti.
But we need to go one step further. In particular, build a custom runtime so we can hijack any TCP connection that arti does (Guard or Fallbackdir connections) and put those on an allowlist as in not proxied as VPN traffic.
This work is still in the exploration phase and PoC but very likely to end up in the final product hence this ticket.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40710Sunset TPO onion v2 hidden services 🌇2022-04-11T12:50:43ZJérôme Charaouilavamind@torproject.orgSunset TPO onion v2 hidden services 🌇Onion v2 hidden services have been deprecated and are not longer supported. We should remove them from our infrastructure.
* [x] stop onion.torproject.org from generating pointers to the v2 links (tpo/tpa/team#40668)
* [x] deconfigure v...Onion v2 hidden services have been deprecated and are not longer supported. We should remove them from our infrastructure.
* [x] stop onion.torproject.org from generating pointers to the v2 links (tpo/tpa/team#40668)
* [x] deconfigure v2 onions from `torrc` instances
* [x] stop/retire `onionbalance-01` machine
* [x] destroy v2 onion keys
* [x] remove all calls to `onion_global_service_hostname` in puppet
* [x] remove the `onion_global_service_hostname` function from puppet
* [x] remove the `onion::balance` class from puppet
* [x] remove all onionv2 support from the `onion` classold service retirement 2022-Q1/Q2Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40692bullseye upgrades, second batch2024-02-06T18:22:34Zanarcatbullseye upgrades, second batchupgrade the following servers to Debian bullseye:
* [x] bacula-director-01 (@lavamind)
* [x] bungei (@lavamind) psql 13 upgrade @anarcat
* [x] carinatum @anarcat (triggered #40751)
* [x] check-01 @anarcat left tpo/network-health/exi...upgrade the following servers to Debian bullseye:
* [x] bacula-director-01 (@lavamind)
* [x] bungei (@lavamind) psql 13 upgrade @anarcat
* [x] carinatum @anarcat (triggered #40751)
* [x] check-01 @anarcat left tpo/network-health/exitmap#38 also generated tpo/network-health/metrics/exit-scanner#40004, tpo/network-health/metrics/tor-check#40007
* [x] colchicifolium @lavamind
* [x] crm-ext-01 @anarcat
* [x] crm-int-01 @anarcat
* [x] fallax @anarcat
* [x] gayi (yes, it needs to be upgraded, see #17202 ) @anarcat
* [x] ~~gettor-01 - sync with @meskio, AFK on may 2nd, <= 1800UTC otherwise @anarcat~~ no need, will be retired, see #40915
* [x] gitlab-02 @anarcat, planned for Monday, May 30 @ 17:00 UTC
* [x] henryi @anarcat
* [x] majus @lavamind
* [x] mandos-01 @lavamind
* [x] materculae @anarcat led to OOM issues? see #40750
* [x] meronense ~~- do *NOT* upgrade PostgreSQL until we figure out issues with PostgreSQL 13 (#40750 and #40761 )~~ things seem to have resolved themselves @anarcat see https://gitlab.torproject.org/tpo/tpa/team/-/issues/40809 for the Postgresql 13 upgrade
* [x] neriniflorum @lavamind
* [x] nevii @lavamind
* [x] ~~onionbalance-01~~ ([retired](https://gitlab.torproject.org/tpo/tpa/team/-/issues/40710))
* [x] onionbalance-02 @lavamind
* [x] onionoo-backend-01 @lavamind
* [x] onionoo-backend-02 @lavamind
* [x] onionoo-frontend-01 @lavamind
* [x] onionoo-frontend-02 @lavamind
* [x] polyanthum - sync with @meskio, AFK on may 2nd, <= 1800UTC otherwise, also deploy backports, see tpo/tpa/team#40758 @anarcat possibly caused tpo/anti-censorship/bridgedb#40049
* [x] rude @lavamind
* [x] staticiforme @anarcat
* [x] ~~subnotabile~~ to retire? see #40810Debian 11 bullseye upgradeanarcatanarcat2022-05-31https://gitlab.torproject.org/tpo/tpa/team/-/issues/40683space to deploy OnionSproutsBot2022-06-01T14:13:52Zmeskiomeskio@torproject.orgspace to deploy OnionSproutsBot[OnionSproutsBot](https://gitlab.torproject.org/tpo/anti-censorship/gettor-project/onionsproutsbot) is becoming ready to be deployed in production. It will be maintained by the anti-censorship team. Can we have a place to deploy it?
Sho...[OnionSproutsBot](https://gitlab.torproject.org/tpo/anti-censorship/gettor-project/onionsproutsbot) is becoming ready to be deployed in production. It will be maintained by the anti-censorship team. Can we have a place to deploy it?
Should get a new user in the gettor VM? Or to deploy it in another VM? The rest of gettor is going to be integrated in rdsys in the near future, so OnionSproutsBot will be the last piece of gettor that has its own life. Might make sense to create a new VM for it so you can retire the existing gettor VM (using buster) once we move gettor to rdsys?
Is a python program with few dependencies, I guess we can deploy it in a virtualenv or if you have better ideas I'm happy to hear about it.Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/community/relays/-/issues/42Relay operator meetup (April 2)2022-04-05T12:58:18ZGusRelay operator meetup (April 2)Tasks
* [X] Confirm the meetup time with @gk and @arma and add to the nextcloud calendar - 1900 UTC
* [x] Put together an agenda with the contribution of other teams and relay op community: https://pad.riseup.net/p/tor-relay-meetup-apri...Tasks
* [X] Confirm the meetup time with @gk and @arma and add to the nextcloud calendar - 1900 UTC
* [x] Put together an agenda with the contribution of other teams and relay op community: https://pad.riseup.net/p/tor-relay-meetup-april-2022-keep
* [X] BBB room - https://tor.meet.coop/gus-og0-x74-dzn
* [x] Publish the meetup invitation where our community hangout:
* [x] tor-relays mailing list - https://lists.torproject.org/pipermail/tor-relays/2022-March/020467.html
* [x] Twitter - https://twitter.com/torproject/status/1508524036413960192
* [x] Mastodon - https://mastodon.social/@torproject/108035777254723022
* [ ] Tor Blog
* [x] r/TOR - https://www.reddit.com/r/TOR/comments/tqh4pa/torrelays_next_tor_relay_operator_meetup_april_2/
* [x] Facilitate the meetup (Saturday, April 2) (@gaba)
* [x] Send the meetup notes to the tor-relays mailing listGusGus2022-04-02https://gitlab.torproject.org/tpo/tpa/team/-/issues/40668Remove v2 onions from onion.tpo2022-04-19T18:36:56ZGusRemove v2 onions from onion.tpoAs v2 onion services were removed from Tor and are fully deprecated, we should remove it from https://onion.torproject.org/As v2 onion services were removed from Tor and are fully deprecated, we should remove it from https://onion.torproject.org/Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40667Downloading Tor Browser from the onionsite redirects to dist.tpo2022-04-27T21:13:42ZGusDownloading Tor Browser from the onionsite redirects to dist.tpoA user reports that:
When using torproject.org onionsite http://2gzyxa5ihm7nsggfxnu52rck2vv4rvmdlkiu3zzui5du4xyclen53wid.onion/download
I notice that when you click to download a file it wants to download from dist.torproject.org, rath...A user reports that:
When using torproject.org onionsite http://2gzyxa5ihm7nsggfxnu52rck2vv4rvmdlkiu3zzui5du4xyclen53wid.onion/download
I notice that when you click to download a file it wants to download from dist.torproject.org, rather than the .onion.
This differs from, say, the OnionShare website .onion, where when you download a file it downloads from the .onion.
Would it be possible to change the download behavior at the torproject.org .onion’s download
page to download from the .onion rather than pivot to downloading at dist.torproject.org?
https://forum.torproject.net/t/download-tor-from-website-onion-instead-of-dist-torproject-org/2557Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40110Move bridge to an interim faster server2022-05-17T00:24:17ZDavid Fifielddcf@torproject.orgMove bridge to an interim faster serverBackground: [\[tor-project\] More resources required for Snowflake bridge](https://forum.torproject.net/t/tor-project-more-resources-required-for-snowflake-bridge/2353)
I have or have been offered access to a faster server for the snowf...Background: [\[tor-project\] More resources required for Snowflake bridge](https://forum.torproject.net/t/tor-project-more-resources-required-for-snowflake-bridge/2353)
I have or have been offered access to a faster server for the snowflake bridge. I anticipate being able to change DNS and start using the faster server on Wednesday, 2022-03-16.
The current situation is: I have control right now of a suitable *paid* server, and I have an offer of a suitable *free* server that I am supposed to get control of on Tuesday, 2022-03-15. I will prefer to switch to the free server, but if there are any unforeseen problems with that deal, the paid server will be ready as a backup.
I expect to have to move the bridge *again*, to a more permanent home, but not before 2022-03-21 (#40111). The purpose of the migration in this ticket is to improve service until that other server is ready, and to mitigate any possible delays.
- [x] install new bridge ([installation guide](https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Bridge-Installation-Guide)), try 8 tor instances to start
- [x] copy user accounts https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40091#note_2768855
- [x] copy identity and onion keys from existing bridge
- [x] copy HTTPS TLS keys and certificates from existing bridge
- [x] test tor bootstrap on new bridge using local broker and proxy, and /etc/hosts domain name record https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40095#note_2773365
- [x] make DNS for snowflake.torproject.net point to the new bridge tpo/tpa/team#40664
- [x] monitor for a day, be ready to switch DNS back if connections fail
Cc @artDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/web/community/-/issues/262We should add Twitter's .onion to our page of services using onion2022-03-11T16:30:58ZIsabela FernandesWe should add Twitter's .onion to our page of services using onionHi we should add Twitter's .onion:
twitter3e4tixl4xyajtrzo62zg5vztmjuricljdp2c5kshju4avyoid.onion
To this page:
https://community.torproject.org/onion-services/
And this also reminds me that we should make the section Featured Onionsit...Hi we should add Twitter's .onion:
twitter3e4tixl4xyajtrzo62zg5vztmjuricljdp2c5kshju4avyoid.onion
To this page:
https://community.torproject.org/onion-services/
And this also reminds me that we should make the section Featured Onionsites as a bookmark link so we can easily share it :smile:donutsdonutshttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/72Moat process unexpected quit issue2022-09-23T20:04:10ZshelikhooMoat process unexpected quit issueLast Saturday(March 5, 2022) there is a failure observed at the moat service. The root cause of service failure is due to the unexpected quit of the moat process. @arma restored the service by restarting the moat process. However, the ro...Last Saturday(March 5, 2022) there is a failure observed at the moat service. The root cause of service failure is due to the unexpected quit of the moat process. @arma restored the service by restarting the moat process. However, the root cause of the issue is still present.
To solve this issue we have created the following roadmap:
1. Setup an automatic restart procedure like systemd to restart moat automatically when it fails
2. Setup a log collection system to capture the diagnostic output
3. redact the log file to hide the user IP address
4. Try to fix the root cause of service crashing by analyzing the diagnostic output
The relevant IRC log is as follows:
```
<n8fr8[m]> not sure where the right channel to report this, but the moat service endpoint seems to be down. can't request a bridge in TB, Orbot, OnionBrowser, etc.
<lavamind> n8fr8[m]: thanks for the heads up, usually a good place to start is #tor of forum.torproject.net
<lavamind> or*
<n8fr8[m]> well... a key part of our anti-censorship services for users in places like Russia where tor is blocked is down, and you want me to post it to the general tor forum on a message board? I suppose I will send an email to the right people instead
<lavamind> well I know there was an upgrade to bridgedb done this week, so I've poked a member of the anticensorship team responsible for it
<lavamind> I've looked at the system and couldn't find anything obviously wrong
<n8fr8[m]> thanks for checking!
<n8fr8[m]> could be something with fastly front domain, hopefully temporary
<n8fr8[m]> I am getting a TLS cert error on https://moat.torproject.org.global.prod.fastly.net/
<lavamind> oh nice catch
<lavamind> well we definitely dont generate those certificates :p
<lavamind> so yeah, maybe an issue on Fastly's end
<+armadev> n8fr8[m]: i think i might have fixed moat
<+armadev> if somebody wants to verify, please do :)
<shelikhoo> I think moat is recovered.... how did armadev fix it?
<+armadev> shelikhoo: the moat fix was 'sudo -u moat /srv/bridges.torproject.org/bin/run-moat-shim'
<+armadev> as specified in https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Moat-Survival-Guide
<+armadev> (and i had said this in #tpo-admin but i guess not in more detail here too)
<+armadev> shelikhoo: the bigger issue though is: that moat-shim thing has died at least twice now, mysteriously, for no reason
<+armadev> so somebody should debug it, set up monitoring for when it disappears, etc
<shelikhoow> Yes, so I think a systemd based solution that restart it automatically will work....
<+armadev> can you open a ticket somewhere?
<shelikhoow> Yes, consider it done.
<+armadev> i agree that using systemd to auto restart it is a good first step
<+armadev> there is definitely also a part of me that wants to know why it exits though :)
<+armadev> thanks!
<shelikhoo> That means we need to investigate the log....
<+armadev> yep. the log is full of tls complaints and ip addresses,
<+armadev> but i think the log only goes to stdout
<+armadev> i.e. when you log out from running run-moat-shim, the log now goes nowhere
<shelikhoo> Yes... If we setup a systemd based deployment, we can configure it to store the log from stdout,err
<+armadev> great. so, step one, switch to systemd and start logging stuff somewhere,
<shelikhoo> Systemd have its issues, but it is quite convenient
<shelikhoo> Yes.
<+armadev> then step two, when it dies, see if it said anything useful
<shelikhoo> The effort to do so will be tracked in the issue.
<shelikhoo> Yes
<+armadev> step one-point-five, notice that the log has a bunch of ip addresses in it and wonder if that is urgent enough to fix
<shelikhoo> Yes. I don't think it is urgent but we should fix it....
<+armadev> great
```meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/69Prepare for s28 site visit: March 25 20222022-03-29T01:45:45ZRoger DingledinePrepare for s28 site visit: March 25 2022Very similar to https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/62: "We've got to make slides, wrap up any ongoing work that we want to report, and coordinate with the rest of our group about what our story/goals are."
I...Very similar to https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/62: "We've got to make slides, wrap up any ongoing work that we want to report, and coordinate with the rest of our group about what our story/goals are."
In particular, the set of topics I want to learn about ("what did we make progress on") is the same set as listed in https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/62#note_2775653
Since the actual presentation is on March 25, it would be good to have things gathered some days earlier, e.g. by March 20 latest.Sponsor 28: ONLY PHASE 3 Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Roger DingledineRoger Dingledine2022-03-21https://gitlab.torproject.org/tpo/tpa/team/-/issues/40649TPA-RFC-19: review labels vs projects usage2022-04-07T16:36:02ZanarcatTPA-RFC-19: review labels vs projects usageafter today's all hands, I (re-)realized that we have some issues with the way we organize tickets around here. some services have their own project (e.g. `tpo/tpa/gitlab`) while some only have a label here (e.g. ~Nextcloud). and then so...after today's all hands, I (re-)realized that we have some issues with the way we organize tickets around here. some services have their own project (e.g. `tpo/tpa/gitlab`) while some only have a label here (e.g. ~Nextcloud). and then some services don't have a label at all! (e.g. there's no ~Ganeti label!).
this should really be fixed. we should:
* [x] clarify when it's appropriate to have a project vs a label for a service
* [x] add labels (or projects?) for any service that's missing one?
* [x] update the service template to make sure this decision is made when documenting the service
* [x] add a description for all labels
* [x] ~~decide what to do about the ~Schleuder and ~Gitlab labels (either move those issues to their respective projects and drop the label, or drop the projects)~~ both will be kept.
might be worth further discussion (~RFC?)anarcatanarcat2022-03-24https://gitlab.torproject.org/tpo/tpa/team/-/issues/40639get rid of procmail2022-03-10T15:14:52Zanarcatget rid of procmailprocmail gets installed as world-executable, suid `root:mail` everywhere right now, which is a huge security liability considering the software is completely dead and likely contains security issues.
see for example [this article from L...procmail gets installed as world-executable, suid `root:mail` everywhere right now, which is a huge security liability considering the software is completely dead and likely contains security issues.
see for example [this article from LWN](https://lwn.net/Articles/416901/). and consider that the "final release" of Procmail was made in *2001*, when the last maintainer publicly stated that "the code is not safe and should not be used as a basis for any further work" ([source](https://marc.info/?l=openbsd-ports&m=141634350915839&w=2)). see also [the wikipedia article](https://en.wikipedia.org/wiki/Procmail).
in #40635, i wanted to remove procmail from polyanthum but found out that I can't actually remove procmail from our systems because it's a dependency of userdir-ldap, which means it's installed *everywhere*. so we should really clean that up.
1. [x] look for .procmailrc in all homes to see if we have other configurations to deal with, explicitly check all `mail_processing` hosts:
- [x] polyanthum (#40635)
- [x] rude (was using it to file mails into the `/srv/rtmailarchive`, in the right folder, converted to `.dovecot.sieve`
- [x] egeuni (made a `find` over the whole filesystem, no `.procmailrc` found)
- [x] gettor
- [x] crm-int-01 (nothing found)
- [x] gitlab-02
- [x] alberti
- [x] submit-01
- [x] ...? still in progress
1. [x] remove the `mailbox_command` from `main.cf`, see what breaks
2. [x] find out why userdir-ldap depends on procmail: it used to use the `lockfile` command, switched to `flock` already
3. [x] if it's a hard dependency, find an alternative solution: already done, see above
4. [x] remove the dependency: needs a patch and upstream
5. [x] deploy patched userdir-ldap everywhere
6. [x] remove procmail from all our servers: might need an audit of the `lockfile` usage and some coordination
7. [x] send an announcement ([forum](https://forum.torproject.net/t/tor-project-psa-procmail-removed-from-all-torproject-org-servers/2348), [list](https://lists.torproject.org/pipermail/tor-project/2022-March/003300.html))
8. [x] remove procmail from Debian (filed [bug 1006633](https://bugs.debian.org/1006633))anarcatanarcathttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40633Migrate Puppet sudo configs to saz/sudo module2023-04-12T17:23:44ZJérôme Charaouilavamind@torproject.orgMigrate Puppet sudo configs to saz/sudo moduleCurrently in the `tor-puppet` repository, most `sudo` configurations are deployed via a single file resource that's identical across all our machines. This is less than ideal from a security standpoint since this one file reveals a great...Currently in the `tor-puppet` repository, most `sudo` configurations are deployed via a single file resource that's identical across all our machines. This is less than ideal from a security standpoint since this one file reveals a great deal about the permissions granted to users on our different machines. Furthermore, the file is deployed without any syntax checking: a single error in there is susceptible to break `sudo` for many users and systems.
I propose we deploy the 3rd party [saz/puppet-sudo](https://github.com/saz/puppet-sudo) module in our Puppet infrastructure and leverage this along with a new `profile::sudo` class to progressively migrate from the current `sudo` module.
The deployment would be staged in several steps:
* [x] audit [saz/puppet-sudo](https://github.com/saz/puppet-sudo)
* [ ] ~~rename the current `sudo` module to `sudo_legacy` and modify the base includes to use the new class name~~
* [X] pull in the new sudo module in `3rdparty/modules`
* [X] add a new `profile::sudo` class to create `sudo::conf` resources from Hiera data
* [x] move the sudoers-`file` resource in `role::network_health_relay` to Hiera
* [ ] ~~validate that `profile::sudo` and `sudo_legacy` can coexist~~
* [x] add `profile::sudo` to base classes and deploy progressively
* [x] move sudoers-`file` resource in other classes to Hiera
* [x] retire `sudo_legacy`
* [ ] ~~progressively convert monolithic `sudoers` to Hiera~~ move to a separate ticketcleanup and publish the sysadmin codebaseJérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40630convert relay-01 into a TPA-RFC-7 root exception for network-health team2022-02-23T20:30:15Zanarcatconvert relay-01 into a TPA-RFC-7 root exception for network-health teamin tpo/tpa/team#40392, we setup a box but we didn't give @dgoulet and the network-health people enough privileges.
in that ticket, it was agreed we needed a TPA-RFC-7 exception and just grant them root access. the rationale is, as state...in tpo/tpa/team#40392, we setup a box but we didn't give @dgoulet and the network-health people enough privileges.
in that ticket, it was agreed we needed a TPA-RFC-7 exception and just grant them root access. the rationale is, as stated by @dgoulet in that ticket:
> First, without root, we have to deal with `sudo` and I'll need to ask the TPA team regularly to install various packages. And that list of packages over time is ever evolving often.
>
> The second thing is that some of the tracing tool load kernel modules and these modules can change or be changed by us over time. And so, a non root situation makes things all just time consuming and lot more painful to access any files on the system or logs.
>
> Last thing is that we sometimes need to run services on the side of tor (dnsmasq, profilers, etc...) and I don't have a list and if I have to go through TPA for hours before I can get these, it is not worth it.
>
> In other words, I'm not sure this machine is of any use to us if we can't get root in order to assess and investigate a lot of things from the kernel, tor and other services we might run.
The agreement is under the following conditions:
> We'll grant you `sudo su` access (or whatever, the equivalent), but you'll still need to login with your regular user to get that access, I hope that is sufficient.
>
> We agree with this under the condition that "other services we might run" still remains in scope for this ticket. We don't want this box to become the place where you run random unrelated stuff "just because you have root" there.
>
> [...]
>
> We will disable alerting on this server so that you can break things without annoying us.
>
> Also, if things break on this box, you're on your own. From here on, if things break, you get to keep both pieces. We'll help in a best effort basis, but expect "we can reinstall the server" as an answer to some tech support requests. :)
So the actual task here is to:
1. [x] revert the `profile::tor::systemd_user` class, although we might want to keep git and build-essential installed (or at least unmanaged) since they'll need it anyways (and probably remove that code altogether)
2. [x] deploy a "sudo su" (or equivalent) to allow the users of the `network-health` team to "sudo to root" on boxes matching that role (and only those), probably reusing the code in `profile::tor::systemd_user` to deploy a snippet in `sudoers.d`
3. [x] disable altering (or monitoring?) or the server resources (but not ping?) in nagios somehow
@lavamind expressed interest in taking care of this.Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/community/support/-/issues/40062[China] Monitoring dynamic obfs4 bridges2023-01-31T22:01:53Zirl[China] Monitoring dynamic obfs4 bridgesInspired by #40054, let's use a ticket to track when we are seeing that these bridges are blocked.
We have two codenames for these bridges, Cobalt and Zinc. The current bridges can be found with these queries:
* https://metrics.torproj...Inspired by #40054, let's use a ticket to track when we are seeing that these bridges are blocked.
We have two codenames for these bridges, Cobalt and Zinc. The current bridges can be found with these queries:
* https://metrics.torproject.org/rs.html#search/Sr2Zinc%20type:bridge%20running:true
* https://metrics.torproject.org/rs.html#search/Sr2Cobalt%20type:bridge%20running:true
(Obviously these search by nickname, so it is entirely possible for someone to start spoofing bridges here.)
These bridges are distributed by moat and so when they are blocked, we will simply turn them off and deploy new bridges that will automatically be distributed by moat. All we need to coordinate here is the reachability checks. It would be good if we can do these at least weekly.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetshelikhooshelikhoohttps://gitlab.torproject.org/tpo/web/community/-/issues/249images dont appear in staging or pages because path is absolute2022-05-06T01:39:43Zemmapeelimages dont appear in staging or pages because path is absoluteThe images at https://community.torproject.org/ and it's subsection pages (as https://community.torproject.org/training/ ) have absolute links, and that makes them break when the page is published in a folder and not its own fqdn.
This...The images at https://community.torproject.org/ and it's subsection pages (as https://community.torproject.org/training/ ) have absolute links, and that makes them break when the page is published in a folder and not its own fqdn.
This is a problem in our previews, because the images are always broken, so you cannot really check when it is not going to be broken for real and it can lead to images broken in production. See for example at: https://review.torproject.net/tpo/web/community/l10n/ or https://review.torproject.net/tpo/web/community/l10n/training/
The solution is to use the `url` filter when using images in templates, which makes the link relative and adapts to be in a subfolder even with the different locales.
If instead you are writing markdown, the solution is to use the markdown filter for images:
`![here you put the alt attribute](/path/to/image)`emmapeelemmapeel