TPA team issueshttps://gitlab.torproject.org/tpo/tpa/team/-/issues2023-01-11T14:42:06Zhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/29663Deploy /etc/puppet as a role account2023-01-11T14:42:06ZLinus Nordberglinus@torproject.orgDeploy /etc/puppet as a role accountOn our puppet master (`pauli.tpo`), the post-receive git hook deploys the tor-puppet repo in /etc/puppet as the user pushing. As long as umask is correct and the stars are aligned, things are good. Sometimes files end up with 0644 when w...On our puppet master (`pauli.tpo`), the post-receive git hook deploys the tor-puppet repo in /etc/puppet as the user pushing. As long as umask is correct and the stars are aligned, things are good. Sometimes files end up with 0644 when we need them to be 0664 in order for other accounts (in group 'adm') to be able to change existing files.
Start using a role account instead of individual admin accounts for deploying to /etc/puppet.
* [x] determine if we need gitolite or some other access control system (no)
* [x] create a new user (`git`? in ldap? in puppet?)
* [x] populate user with admin keys (in puppet?)
* [x] remove write permissions to other users, grant only to the new user
* [x] ~~add hooks to indicate the URL change~~ `pre-receive` doesn't run soon enough
* [x] update documentation in https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/puppet/#problems-pushing-to-the-puppet-server ~~or remove that section~~
* [x] notify the team
* [x] update the mrconfigPuppet CIanarcatanarcathttps://gitlab.torproject.org/tpo/tpa/team/-/issues/33588migrate to puppetserver and Puppet agent 7 before EOL2023-02-27T21:00:32Zanarcatmigrate to puppetserver and Puppet agent 7 before EOLOur current "puppetmaster" configuration ("apache + passenger") is deprecated and will be removed in Puppet 6. we need to switch to the alternative, which is "puppetserver", a daemon written in Clojure especially for that purpose.
the t...Our current "puppetmaster" configuration ("apache + passenger") is deprecated and will be removed in Puppet 6. we need to switch to the alternative, which is "puppetserver", a daemon written in Clojure especially for that purpose.
the tool is [not yet in Debian](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830904), <del>so this can wait until then</del>. otherwise we could also use the upstream puppet debian repositories.
our "old" passenger configuration lead to at least one security issue (#33587) which was due to how complex that configuration is.
puppet 5, as a whole, is EOL in november 2020, so we should consider an upgrade path to Puppet 6 by then. the packaging work is happening in [bts #950182](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950182).
update: it might be desirable to jump directly to Puppet 7 if we're going to make such a switch, since Puppet 6 itself is going to be EOL by February 2023 ([source](https://puppet.com/docs/puppet/6/platform_lifecycle.html)).
update: we most definitely will want to jump to puppet 7 for both the server and agent components, as the 6.x series is missing support for Ruby 3.0 which is what bookworm ships currently.
note: a [puppet cluster upgrade](https://puppet.com/docs/puppet/6/upgrade_minor.html) normally goes through those two stages:
* upgrade puppetdb, because its consumers are typically more tolerant of API changes
* upgrade the server
* upgrade the agents
In other words, the server is backwards compatible with older clients, but not the reverse. and the server and puppet db need to be upgraded together. How far back the server is compatible with the clients is unclear. [this document](https://puppet.com/docs/puppet/7/server/compatibility_with_puppet_agent.html) seems to state, surprisingly, that Puppetserver 7 is backwards compatible with Puppet 4 agents. But this *other* [document](https://puppet.com/docs/pe/2021.5/component_versions_in_recent_pe_releases.html#primary-agent-compatibility) states the opposite, that even Puppet agent 5.x is not supported by 7.x. So that's still unclear.
update: bastelfreak stated that Puppet agent 5.5 should work with Server 7. one concern they had was with the "intermediate cert" created by Puppet server 7, but as long as we keep the existing cert, we should be fine.
This is the state of the Puppet packages in Debian and upstream:
| Package | buster | bullseye | testing | unstable | experimental | upstream |
|---------------|------------------|-----------|-------------|-------------|--------------|----------------|
| Puppet agent | 5.5.10-4 | 5.5.22-2 | 5.5.22-4 | 5.5.22-4 | 7.16.0-2 | 6.27.0/7.17.0 |
| Puppet master | 5.5.10-4 | 5.5.22-2 | 5.5.22-4 | 5.5.22-4 | N/A | N/A |
| Puppetserver | N/A | N/A | N/A | N/A | 6.16.0-1 | 6.19.0/7.8.0 |
| PuppetDB | 6.2.0-3 | N/A | N/A | 6.2.0-5 | N/A | 6.21.0/7.10.1 |
| Facter | 3.11.0-2+deb10u2 | 3.14.12-1 | 3.14.12-1.1 | 3.14.12-1.1 | N/A | 3.14.23/4.2.10 |
This is the different EOL dates:
* Puppet 5: November 2020 (source?)
* Puppet 6: February 2023 ([source](https://puppet.com/docs/puppet/6/platform_lifecycle.html))
* Puppet 7: unannounced?
this implies that we *could* do this:
1. upgrade pauli to bullseye, keeping the old puppetmaster 5 configuration (or rebuild with bullseye)
2. upgrade to puppet server 6 (probably using upstream packages, because the [ITP is still not resolved](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830904), [details in this post too](https://veronneau.org/puppetserver-6-a-debian-packaging-post-mortem.html))
3. eventually, upgrade all agents to puppet agent 6 (see [this bug report](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950182), fixed in experimental?), possibly part of the bookworm upgrade?
4. upgrade to puppet server 7, possibly with the Bookworm upgrade (see %"Debian 12 bookworm upgrade") with Debian packages if jruby gets their thing together
it should be noted that puppetdb is also in bad shape. it's at version 6.2.0 (while upstream is 6.20), with at least three RC bugs which kept it from shipping in bullseye and keep it from bookworm right now as well. see #40707 for that package specifically.
so that's another thing that should be fixed. according to @pollo, that is simpler to fix than the puppetserver SNAFU, fortunately. it seems it could be upgraded separately from the other as well.
there's a coding sprint coming in the clojure team to address some of the underlying issues in clojure Debian packaging that directly affect Puppet packaging, see https://wiki.debian.org/Sprints/2022/ClojureTeam. I think we should participate in this sprint to help with this effort.
finally, there's also facter to worry about. Puppet 7 seems to mention Facter 4 in its [upgrade notes](https://puppet.com/docs/puppet/7/upgrading-from-puppet6-to-puppet7.html#upgrading_from_puppet6_to_puppet7) and specifically trouble with upgrades from 6 to 7 that need to go through 6.22+ on the server side. Ugh. Update: on that front, we seem safe enough: people are apparently running Puppet 7 with Facter 3 without problems.
update: there's been some progress recently in packaging puppet agent 7 (almost ready) and puppetdb (some deps still missing). as for puppetserver its still blocking on jruby, so the outlook is uncertain currently. this ongoing work is being tracked in more detail on this [Debian wiki page](https://wiki.debian.org/Teams/Puppet/Work).Puppet CIJérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/33750Hosting BTCPayserver2023-06-22T15:47:42ZHiroHosting BTCPayserverBTCPayserver suggests to deploy and use the docker configuration in production.
The docker configuration is available via docker-compose: https://github.com/btcpayserver/btcpayserver-docker
BTCPay depends on several pieces of infrastru...BTCPayserver suggests to deploy and use the docker configuration in production.
The docker configuration is available via docker-compose: https://github.com/btcpayserver/btcpayserver-docker
BTCPay depends on several pieces of infrastructure, mainly:
- A lightweight block explorer (NBXplorer),
- A database (PostgreSQL or SQLite),
- A full node (eg. Bitcoin Core)
There can be more dependencies if you support more than just standard Bitcoin transactions, including:
- C-Lightning
- LitecoinD and other coin daemons
It seems the bitcoin client needs to be installed and synced locally, therefore I am a bit concerned about storage. On this issue the docker setup has some scripts to prune the synced data to approx 100GB: https://github.com/btcpayserver/btcpayserver-docker#how-i-can-prune-my-nodes
I am also concerned how to make this setup play nicely with our infrastructure.
It would be nice if we can have an idea of the setup that BTC is currently running for us. What are the requirements? How many coins are supported?
## checklist
Update: that service was setup at lunanode by @hiro in 2021, but never integrated properly with TPA infrastructure, so it's in an unknown state. We should rebuild it inside our infra, following this procedure:
1. [x] [backup the actual btcpayserver](https://docs.btcpayserver.org/Docker/#how-can-i-back-up-my-btcpay-server)
2. [x] create a VM inside our infra, using our normal setup procedures (so we have backups, monitoring, etc)
3. [x] deploy the thing [using their Docker procedures](https://docs.btcpayserver.org/Docker//) (which target ubuntu 18.04, but that we could possibly deploy on bullseye?), things to watch out for:
* that thing probably installs postgresql and docker and all sorts of things, maybe try to trim that down to debian packages as much as possible?
* this *generates* a docker-compose.yaml file (!?), see what it actually does?
* consider just using the `./build.sh` command to generate the compose file and start from there? see [what does btcpay-setup.sh do?](https://docs.btcpayserver.org/Docker/#again-what-does-btcpay-setupsh-do)
* note that we absolutely need to have *some* sort of "fragment" to keep the blockchain from exploding in size. the [current bitcoin blockchain is reaching 400GB](https://www.blockchain.com/charts/blocks-size) and [growing exponentially](https://www.statista.com/statistics/647523/worldwide-bitcoin-blockchain-size/). it seems like we're using the [opt-save-storage-s fragment](https://github.com/btcpayserver/btcpayserver-docker/blob/master/docker-compose-generator/docker-fragments/opt-save-storage-s.yml) which keeps it under 50GB
4. [x] restore the backup onto the new server, things to watch out for:
* will this take over payments?
5. [x] add btcpay.torproject.org to DNS, deprecate the `.net`
6. [x] flip the donate.tpo things so that they point to the `.org`, see https://gitlab.torproject.org/tpo/web/donate-static/-/merge_requests/76 and the [full migration procedure](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service/BTCpayserver#full-migration-procedure)
7. [x] test donations on new server
8. [x] retire btcpay.torproject.net (see procedure below)
9. [x] fix credentials in password manager (remove old, tweak new, possibly audit)
10. [x] automate upgrades, backups (including postgresql?) (#40763)
server retirement procedure:
1. [x] announcement
2. [x] nagios (N/A)
3. [x] retire the host in fabric (no backups, not in puppet, nothing to do)
4. [x] remove from LDAP with `ldapvi` (not in LDAP)
5. [x] power-grep (removed from torproject.net zone)
6. [x] remove from tor-passwords (done, also reset the root pass on btcpayserver-02, which was missing)
7. [x] remove from DNSwl (N/A)
8. [x] remove from docs (nothing found)
9. [x] remove from racks (let's wait two more weeks)
10. [x] remove from reverse DNS (not set)
current specs of the machine:
```
ubuntu@btcpay:~$ df -h / /dev/vdc
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 20G 9.3G 11G 49% /
/dev/vdc 59G 49G 7.0G 88% /var/lib/docker/volumes/generated_bitcoin_datadir/_data/blocks
ubuntu@btcpay:~$ uptime
19:46:00 up 37 days, 8:36, 1 user, load average: 0.13, 0.27, 0.15
ubuntu@btcpay:~$ free -h
total used free shared buff/cache available
Mem: 2.0G 1.1G 114M 9.2M 799M 684M
Swap: 1.0G 682M 341M
ubuntu@btcpay:~$ uname -a
Linux btcpay 4.4.0-210-generic #242-Ubuntu SMP Fri Apr 16 09:57:56 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
```
in other words, we might want to give it 60GB of spinning rust (which is 10GB over the "50GB" we are trimming to), but otherwise fairly standard.
in the current setup, we seem to have the following components setup (looking at `/root/btcpayserver-docker/Generated/docker-compose.generated.yml`):
* nginx 1.16 (based on the [official docker image](https://hub.docker.com/_/nginx))
* nginx-gen (which is some container based on [docker-gen](https://hub.docker.com/r/btcpayserver/docker-gen), which ... generates config files?)
* btcpayserver (based on [their image](https://hub.docker.com/r/btcpayserver/btcpayserver) of course)
* bitcoind (based on [btcpayserver/bitcoin](https://hub.docker.com/r/btcpayserver/bitcoin) docker image)
* nbx explorer 2.2.5 (based on [nicolasdorier/nbxplorer](https://hub.docker.com/r/nicolasdorier/nbxplorer)
* lnd_bitcoin (for the "lighting network", based on [their image](https://hub.docker.com/r/btcpayserver/lnd))
* bitcoin_rtl (based on [ shahanafarooqui/rtl](https://hub.docker.com/r/shahanafarooqui/rtl), a webapp for the lightning network)
* postgresql 9.6.20 (!? based on the official image
* [btcpayserver/letsencrypt-nginx-proxy-companion](https://hub.docker.com/r/btcpayserver/letsencrypt-nginx-proxy-companion)
* [btcpayserver/tor](https://hub.docker.com/r/btcpayserver/tor) (yes, they have a tor container image)
* tor-gen, also based on [docker-gen](https://hub.docker.com/r/btcpayserver/docker-gen) to generate a config for the above containeranarcatanarcat2022-06-02https://gitlab.torproject.org/tpo/tpa/team/-/issues/34185ganeti clusters don't like automatic upgrades2022-07-09T04:32:14Zanarcatganeti clusters don't like automatic upgradesthis weekend the ganeti cluster had a partial outage: nodes were reachable, but networking was broken on all instances.
this is, presumably, because of the Debian buster point release that occured on saturday (!). last time this happene...this weekend the ganeti cluster had a partial outage: nodes were reachable, but networking was broken on all instances.
this is, presumably, because of the Debian buster point release that occured on saturday (!). last time this happened, weasel identified openvswitch as the culprit, and hiro deployed a fix that would make it survive such situations. but either something else came up or the fix didn't work, because the problem happened again this weekend.
i fixed it by rebooting all nodes forcibly (without migrating first).HiroHirohttps://gitlab.torproject.org/tpo/tpa/team/-/issues/34351Please delete builders/tor-browser-build branch snowflake_android2022-07-09T04:32:14ZMatthew FinkelPlease delete builders/tor-browser-build branch snowflake_android```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Please delete branch snowflake_android from
repository builders/tor-browser-build.git
Fri 29 May 2020 07:00:00 PM GMT
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCgAdFiEEo4znE8duGsmMUJcuHp...```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Please delete branch snowflake_android from
repository builders/tor-browser-build.git
Fri 29 May 2020 07:00:00 PM GMT
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCgAdFiEEo4znE8duGsmMUJcuHp029Ma9dU4FAl7RXxUACgkQHp029Ma9
dU6o4AgAmDLypv2R2t45+aCEyIVIvv5pnaxTGQudxIpghAu5ikaW2C3vhoMLAVro
rteN2FoS3UW/KiTrCVIYKnbR/+sRj2EurU0WxzkMI4W2xXpYt2QsEagks1mFnvqg
yHGQoDC9EwPeuRB20aIFw0KNjymCbHNO9T5kXlsYCdHM53SJ71MYsJJl3yl/3SSA
NYXODAsSxCRefFMAjRCqIWOC0nEcQbq8PWru33w/Ckt4hvavAPuLuWUjxlq/c7z9
Bqj487Wx0+up2viPLz3xRC9cZOVoyFDObGuQinLVneoOxGbCwnQxkauFq1nZzTZq
shT0HctKiL/MO9GDAvJRXVjIxhU46Q==
=yCey
-----END PGP SIGNATURE-----
```
Sigh. Thanks.HiroHirohttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40013gayi should be upgraded to buster(Debian 10) or retired2021-11-17T21:35:52Zweasel (Peter Palfrader)gayi should be upgraded to buster(Debian 10) or retiredold service retirement 2022-Q1/Q2anarcatanarcathttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40022Updating my PGP key on TPO infrastructure2020-09-09T14:03:40ZAlexander Færøyahf@torproject.orgUpdating my PGP key on TPO infrastructureI need some advice on what to do here. The PGP key I have currently attached to my TPO identity is created in 2009 and I would really like to retire it once it expire in August.
Because of COVID-19, I haven't managed to run into any TPO...I need some advice on what to do here. The PGP key I have currently attached to my TPO identity is created in 2009 and I would really like to retire it once it expire in August.
Because of COVID-19, I haven't managed to run into any TPO people and thus my new key remains unsigned by any other members of TPO. I have, however, signed my new key with the old key.
Would that be okay to switch to? Or would you prefer I bump the expiry date on my old?HiroHirohttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40029fsn-node-07 SSH misconfiguration2020-07-07T15:23:16Zanarcatfsn-node-07 SSH misconfigurationThe Nagios Ganeti cluster check fails with this mysterious failure:
```
CHECK_NRPE: Receive underflow - only -1 bytes received (4 expected).
```
... but when i run the verify command on the master, the problem is clearer:
```
root@fsn...The Nagios Ganeti cluster check fails with this mysterious failure:
```
CHECK_NRPE: Receive underflow - only -1 bytes received (4 expected).
```
... but when i run the verify command on the master, the problem is clearer:
```
root@fsn-node-01:~# gnt-cluster verify
Submitted jobs 103518, 103519
Waiting for job 103518 ...
Mon Jul 6 14:19:45 2020 * Verifying cluster config
Mon Jul 6 14:19:45 2020 * Verifying cluster certificate files
Mon Jul 6 14:19:45 2020 * Verifying hypervisor parameters
Mon Jul 6 14:19:45 2020 * Verifying all nodes belong to an existing group
Waiting for job 103519 ...
Mon Jul 6 14:19:45 2020 * Verifying group 'default'
Mon Jul 6 14:19:45 2020 * Gathering data (7 nodes)
Mon Jul 6 14:19:45 2020 * Gathering information about nodes (7 nodes)
Mon Jul 6 14:19:49 2020 * Gathering disk information (7 nodes)
Mon Jul 6 14:19:50 2020 * Verifying configuration file consistency
Mon Jul 6 14:19:50 2020 * Verifying node status
Mon Jul 6 14:19:50 2020 - ERROR: node fsn-node-03.torproject.org: ssh communication with node 'fsn-node-07.torproject.org': ssh problem: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\'r\n@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @\'r\n@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\'r\nIT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!\'r\nSomeone could be eavesdropping on you right now (man-in-the-middle attack)!\'r\nIt is also possible that a host key has just been changed.\'r\nThe fingerprint for the RSA key sent by the remote host is\nSHA256:F4j2N2fSMYDYxjGf/Clj8W5moFZNhdx4mgz5zXFTPi0.\'r\nPlease contact your system administrator.\'r\nUpdate the SSHFP RR in DNS with the new host key to get rid of this message.\'r\n@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\'r\n@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @\'r\n@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\'r\nIT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!\'r\nSomeone could be eavesdropping on you right now (man-in-the-middle attack)!\'r\nIt is also possible that a host key has just been changed.\'r\nThe fingerprint for the RSA key sent by the remote host is\nSHA256:F4j2N2fSMYDYxjGf/Clj8W5moFZNhdx4mgz5zXFTPi0.\'r\nPlease contact your system administrator.\'r\nAdd correct host key in /dev/null to get rid of this message.\'r\nOffending RSA key in /var/lib/ganeti/known_hosts:1\'r\n remove with:\'r\n ssh-keygen -f "/var/lib/ganeti/known_hosts" -R "fsngnt.torproject.org"\'r\nRSA host key for fsngnt.torproject.org has changed and you have requested strict checking.\'r\nHost key verification failed.\'r\n
[...]
```
it seems the SSH configuration is hosed and the master can't talk with the new node.HiroHirohttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40050Create new mailing list for relay operators that speak french2020-09-22T21:28:41ZGabagaba@torproject.orgCreate new mailing list for relay operators that speak frenchWe are moving the mailing list from https://lists.riseup.net/www/info/tor-relays-fr to torproject mailing lists.
name: tor-relays-fr
access: public (everything the same as tor-relays)
same moderators as tor-relays plus @chre
@chre: a...We are moving the mailing list from https://lists.riseup.net/www/info/tor-relays-fr to torproject mailing lists.
name: tor-relays-fr
access: public (everything the same as tor-relays)
same moderators as tor-relays plus @chre
@chre: anybody else should be a moderator for this mailing list?
Original discussion is in https://gitlab.torproject.org/tpo/community/team/-/issues/19#note_2708975HiroHirohttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40052LetsEncrypt is changing their certs2021-03-30T13:46:55Zweasel (Peter Palfrader)LetsEncrypt is changing their certsViktor Dukhovni mentioned on [dane-users](https://mail.sys4.de/pipermail/dane-users/2020-September/000578.html) that [LetsEncrypt is rotating their intermediates](https://letsencrypt.org/2020/09/17/new-root-and-intermediates.html).
Thi...Viktor Dukhovni mentioned on [dane-users](https://mail.sys4.de/pipermail/dane-users/2020-September/000578.html) that [LetsEncrypt is rotating their intermediates](https://letsencrypt.org/2020/09/17/new-root-and-intermediates.html).
This might affect torproject.org https hosts with key pins in chrome.
* [transport_security_state_static.pins](https://chromium.googlesource.com/chromium/src/+/master/net/http/transport_security_state_static.pins)
* [transport_security_state_static.json](https://chromium.googlesource.com/chromium/src/+/master/net/http/transport_security_state_static.json)
```
{
"name": "tor",
"static_spki_hashes": [
"RapidSSL",
"DigiCertEVRoot",
"Tor1",
"Tor2",
"Tor3",
"LetsEncryptAuthorityPrimary_X1_X3",
"LetsEncryptAuthorityBackup_X2_X4"
]
},
```
```
{ "name": "torproject.org", "policy": "custom", "mode": "force-https", "pins": "tor" },
{ "name": "blog.torproject.org", "policy": "custom", "mode": "force-https", "include_subdomains": true, "pins": "tor" },
{ "name": "check.torproject.org", "policy": "custom", "mode": "force-https", "include_subdomains": true, "pins": "tor" },
{ "name": "www.torproject.org", "policy": "custom", "mode": "force-https", "include_subdomains": true, "pins": "tor" },
{ "name": "dist.torproject.org", "policy": "custom", "mode": "force-https", "include_subdomains": true, "pins": "tor" },
```
We should verify if we need to have that updated, and if yes, to what.
We also should check if firefox just copies the chrome pins, is not affected, or also needs updating.
Todo list:
* [ ] Chrome HSTS preload list
* [ ] Firefox HSTS preload list
* [x] DANE (TLSA) records (clear: we use "3 1 1" records)
* [x] CAA records (N/A)
* [x] HPKP records (N/A, disabled in #33592)
* [x] check that we'll follow the cert chain change in the letsencrypt renewal code? (we just take whatever cert let's encrypt gives us, so no change required here)
* [ ] renew certs before the switch so we have an extra 90 days grace period?weasel (Peter Palfrader)weasel (Peter Palfrader)https://gitlab.torproject.org/tpo/tpa/team/-/issues/40056Replace onionperf.torproject.org with a redirect2020-10-22T13:46:55ZAna CusturaReplace onionperf.torproject.org with a redirectAs per ticket [metrics/onionperf#40001](https://gitlab.torproject.org/tpo/metrics/onionperf/-/issues/40001), please replace the static site `onionperf.torproject.org` with a redirect to https://gitlab.torproject.org/tpo/metrics/onionperf...As per ticket [metrics/onionperf#40001](https://gitlab.torproject.org/tpo/metrics/onionperf/-/issues/40001), please replace the static site `onionperf.torproject.org` with a redirect to https://gitlab.torproject.org/tpo/metrics/onionperf/-/wikis/home
Please also remove the jenkins jobs relating to building that static site - there are two jobs, one build and one install.
Thanks for your help!HiroHirohttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40060RT forward emails aren't delivered2021-02-09T21:18:46ZGusRT forward emails aren't deliveredHi, I tried to forward tickets from RT to emails using the "Forward" function, but it's not working. It used to work, but suddenly it stopped.
You can reproduce this issue following these steps:
1. Click on a ticket, for example, https...Hi, I tried to forward tickets from RT to emails using the "Forward" function, but it's not working. It used to work, but suddenly it stopped.
You can reproduce this issue following these steps:
1. Click on a ticket, for example, https://rt.torproject.org/Ticket/Display.html?id=235190
2. Scroll down and click on "Forward."
3. For testing propose, write your own email and click "Forward message."
4. And emails aren't delivered.anarcatanarcathttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40073Delete 'release' and 'packaging' branch from nyx repo2020-11-17T16:17:15ZDamian JohnsonDelete 'release' and 'packaging' branch from nyx repoHi git admins. To cut down on confusion I'd like to delete the long obsolete 'release' and 'packaging' branches from [Nyx's repository](https://gitweb.torproject.org/nyx.git) ([upstream ticket](https://github.com/torproject/nyx/issues/29...Hi git admins. To cut down on confusion I'd like to delete the long obsolete 'release' and 'packaging' branches from [Nyx's repository](https://gitweb.torproject.org/nyx.git) ([upstream ticket](https://github.com/torproject/nyx/issues/29)).
Thanks!HiroHirohttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40098Please delete bug_40156_v2 branch in builders/tor-browser-build.git on git.tpo2020-12-08T15:42:32ZGeorg KoppenPlease delete bug_40156_v2 branch in builders/tor-browser-build.git on git.tpoI erroneously pushed a work branch to the canonical repo instead of my user one. Please delete it.I erroneously pushed a work branch to the canonical repo instead of my user one. Please delete it.HiroHirohttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40102create a new (phw) user on grafana22023-10-16T20:14:53Zanarcatcreate a new (phw) user on grafana2now that we have authentication fixed on grafana2 (#40088), we need to create a new users for @phw. and now i'm left wondering why we'd have to do this in puppet: do we really want to manage every user through trocla?
or maybe shouldn't...now that we have authentication fixed on grafana2 (#40088), we need to create a new users for @phw. and now i'm left wondering why we'd have to do this in puppet: do we really want to manage every user through trocla?
or maybe shouldn't we disable Apache-based authentication for the secondary server and instead rely on Grafana's built-in authentication?
The main reason why I setup apache-based auth here is to make it easy to manage in puppet. but if we're going to have many people accessing the server, it creates a lot more friction (e.g. password resets would need to go through us as well).
In any case (apache or grafana auth), the code will need refactoring because right now it's a hardcoded user/password list.
In particular, I think we need to take the hostname out of there:
```
$grafana_admin_password = trocla('grafana_admin_password', 'bcrypt')
if $vhost_name == 'grafana1.torproject.org' {
$grafana_htpasswd_content = "
admin:${grafana_admin_password}
tor-guest:*REDACTED*
"
} else {
$grafana_htpasswd_content = "
admin:${grafana_admin_password}
"
}
```
We should probably include the `$::fqdn` in the trocla token as well, so that the admin password varies according tot he grafana host. So, refactoring checklist:
1. [ ] create a user for @phw in Puppet, or disable apache-based authentication on grafana2. This blocks #40080.
2. [x] take the hostname out of the `profile::grafana` class (by adding a `$allow_guest` parameter or `$grafana_authentication` parameter or something)
3. [x] include the hostname inside the `trocla()` call so the password varies according to the host
Steps 2 and 3 could be split out in another ticket, but I mention them here because it might influence how step 1 is performed.
Also note that Trocla can integrate into Hiera, so it would be possible to move those passwords into Hiera directly. This would allow us to store multiple users in Hiera somewhat more sanely than hardcoding them the way we're currently doing things. See also: https://github.com/duritong/puppet-trocla#hiera-backendHiroHirohttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40109Can't unsubsubscribe people from encrypted lists2021-01-25T20:52:56ZAlexander Færøyahf@torproject.orgCan't unsubsubscribe people from encrypted listsWe have been trying to unsubscribe pili and catalyst from the CC list for a while now without success. @dgoulet tried to help today and got the following error:
```SQLite3::ReadOnlyException: attempt to write a readonly database: DELETE...We have been trying to unsubscribe pili and catalyst from the CC list for a while now without success. @dgoulet tried to help today and got the following error:
```SQLite3::ReadOnlyException: attempt to write a readonly database: DELETE FROM "subscriptions" WHERE "subscriptions"."id" = ?```
So we think we might not be able to solve this without some service/sysadmin intervention :-/
We tried to send an encrypted+signed email with:
```
x-list-name: tor-community-council@lists.torproject.org
x-unsubscribe: catalyst@torproject.org
x-unsubscribe: pili@torproject.org
```
To the -request list.HiroHirohttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40111Nextcloud membership to TPI group2020-12-08T17:21:58ZJim NewsomeNextcloud membership to TPI groupI appear to not be in the TPI group in nextcloud; could I (jnewsome) be added?I appear to not be in the TPI group in nextcloud; could I (jnewsome) be added?Gabagaba@torproject.orgGabagaba@torproject.orghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40136check research@ alias2021-01-15T18:59:02ZGabagaba@torproject.orgcheck research@ aliasCheck who is receiving mails on research@ . There are people like irl that should not be in the alias anymore.Check who is receiving mails on research@ . There are people like irl that should not be in the alias anymore.https://gitlab.torproject.org/tpo/tpa/team/-/issues/40148Install some packages on tb-build-01 and tb-build-022021-01-26T17:06:07ZboklmInstall some packages on tb-build-01 and tb-build-02We need the following two packages installed on `tb-build-01` and `tb-build-02`:
* libxml-writer-perl
* libparallel-forkmanager-perl
ThanksWe need the following two packages installed on `tb-build-01` and `tb-build-02`:
* libxml-writer-perl
* libparallel-forkmanager-perl
ThanksHiroHirohttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40158More space needed in tb-tester-01 machine2021-02-08T14:42:09ZAlex CatarineuMore space needed in tb-tester-01 machineIn order to be able to run an android emulator, we would need some more disk space. Currently, there are 900MB free and we need at least 2GB to be able to run the emulator. So, probably 4GB extra of disk should be enough.In order to be able to run an android emulator, we would need some more disk space. Currently, there are 900MB free and we need at least 2GB to be able to run the emulator. So, probably 4GB extra of disk should be enough.HiroHiro