Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2023-11-22T17:25:39Zhttps://gitlab.torproject.org/legacy/trac/-/issues/29399Retire host and services for tordnsel and check (chiwui)2023-11-22T17:25:39ZLinus Nordberglinus@torproject.orgRetire host and services for tordnsel and check (chiwui)Metrics team will re-implement the tordnsel and check services and have them deployment ready by end of March 2019. Once up on a new host, retire chiwui.tpo.Metrics team will re-implement the tordnsel and check services and have them deployment ready by end of March 2019. Once up on a new host, retire chiwui.tpo.anarcatanarcathttps://gitlab.torproject.org/legacy/trac/-/issues/29817dead disk on moly2023-03-22T20:59:23Zanarcatdead disk on molyone of the hard drives on moly has died. this was spotted by cymru's staff and confirmed when smartd was installed (#29709).
i have done some research on the machine to figure out what's up, and wrote the following reply to Cymru's peop...one of the hard drives on moly has died. this was spotted by cymru's staff and confirmed when smartd was installed (#29709).
i have done some research on the machine to figure out what's up, and wrote the following reply to Cymru's people:
> [...] I can confirm that one of the hard drives in Moly has failed, according to SMART metrics we have available.
>
> According to smartd, that disk is:
>
> [SEAGATE ST3600057SS 0008], lu id: 0x5000c5003b5bc36f, S/N: 6SL1G7Q60000N1497K0E, 600 GB
>
> It's a 600GB SAS drive. It's part of a megaraid RAID-10 array that has marked the drive as "Firmware state: Failed". I'll go under the assertiont his means the drive is dead.
>
> Being new here, I'm not familiar with the machine either. From what I can tell, it's a Supermicro X8DTU motherboard, and possibly an iXsystems iX1204-R700UB case. Does it look like this this picture?
>
> https://static.ixsystems.co/uploads/2017/08/1204h-t_front.png
>
> If so, the only datasheet I could find is this limited PDF:
>
> https://www.ixsystems.com/wp-content/uploads/2017/09/Server_Line_2017_WEB.pdf
>
> It *does* say the hard drives are hot-swappable, so in theory, it should just be a matter of replacing the hard drive.
>
> It looks like each drive has its own LED, hopefully the one with the amber warning light should be the dead disk. I've issued a command to the RAID controller to make it "flash" the drive LED, so hopefully that will allow you to locate it better.
>
> I *think* the disk controller is new enough for you to simply hot swap the drive with a new one without any other intervention on our part. But it might be better if we are available during the operation. [...]
I've created some documentation on the hardware RAID stuff here:
https://help.torproject.org/tsa/howto/raid/
we're at the waiting step now - we'll see if Cymru can do the replacement and when. i'm still not quite certain we can just hotswap the drive, but I'm hoping we can.anarcatanarcathttps://gitlab.torproject.org/legacy/trac/-/issues/32519improve user onboard/offboarding procedures2023-01-23T21:43:54Zanarcatimprove user onboard/offboarding procedureswhile working on the nextcloud project, we realized it wasn't exactly trivial to setup the LDAP bridge because of our specific requirements (no direct connexion, offline support). so we just didn't implement it yet (#32332). i added a no...while working on the nextcloud project, we realized it wasn't exactly trivial to setup the LDAP bridge because of our specific requirements (no direct connexion, offline support). so we just didn't implement it yet (#32332). i added a note about this in the [retire a user](https://help.torproject.org/tsa/howto/retire-a-user/) procedure, but then i realized there are probably many other such services that do *not* connect with LDAP.
On the top of my head, there's at least Trac and mailing lists, for example, which are managed completely separarely. Audit [[org/operations/services]] and see which services are manager manually and which aren't. Those services have been identified as particularly out of sync:
* blog.torproject.org, see also #33109
* email, see also #32558
* IRC, the @tor-tpomember group
* Nagios contacts (almost cleaned up, but will still need checking for sysadmins arriving/departing)
* Nextcloud (#32332)
* rt.torproject.org, see #34036 for an example audit
That list is not exhaustive.
Then make sure there's an automated way to add/remove users to services, either by hooking up the service with LDAP, or by creating a wrapper script that will manage those accesses.
So the following needs to be done here:
* [ ] document, in [new-person](https://help.torproject.org/tsa/howto/new-person/) and [retire-a-user](https://help.torproject.org/tsa/howto/retire-a-user), the various services to add/remove people to
* [ ] automate the above with a script or LDAP
Note that the two pages have different scope: `new-person` is about TSA while `retire-a-user` is broader. This should also be converged, probably in the broader sense.
Also note that a particularly tricky situation is when we want to do a *partial* removal. For example, maybe the person needs to be removed from tor-internal, but keep access to some servers. Or removed from server, but keep an email alias.
The latter case is especially sensitive: some people feel keeping their email alias around forever is an inalienable right and that we should keep forwarding their email even after they are fully retired from Tor. This policy needs to be clarified, see #32558 for that particularly tricky problem.https://gitlab.torproject.org/legacy/trac/-/issues/33412ganeti cluster backend is IPv4-only2022-11-07T15:51:02Zanarcatganeti cluster backend is IPv4-onlyI tried to reboot the ganeti cluster yesterday and it failed with:
```
root@fsn-node-04.torproject.org: Permission denied (publickey).
```
weasel diagnosed this as:
```
16:57:08 <weasel> etc/ssh/userkeys/root only has v4 addresses in ...I tried to reboot the ganeti cluster yesterday and it failed with:
```
root@fsn-node-04.torproject.org: Permission denied (publickey).
```
weasel diagnosed this as:
```
16:57:08 <weasel> etc/ssh/userkeys/root only has v4 addresses in from=..
16:57:22 <weasel> that is probably a bug.
```https://gitlab.torproject.org/legacy/trac/-/issues/31957automate upgrades2022-11-07T15:51:01Zanarcatautomate upgradesupgrades take up a significant chunk of time every week and distract sysadmins (or at least me) from focusing on other projects.
upgrades should be therefore automated, as much as possible.
see also #31239 about auomated installs and t...upgrades take up a significant chunk of time every week and distract sysadmins (or at least me) from focusing on other projects.
upgrades should be therefore automated, as much as possible.
see also #31239 about auomated installs and this is part of the wider "ops card questionnaire", where we answered no to a question about this, see #30881.
checklist:
* [x] install needrestart everywhere, in interactive mode
* [x] switch needrestart to automatic mode
* [x] install unattended-upgrades everywhere
* [ ] fix major upgrades docs to disable unattended-upgrades during the upgrade run
* ~~[ ] automate reboots~~ see #33406 insteadHiroHirohttps://gitlab.torproject.org/legacy/trac/-/issues/33751WKD: Error running auto-key-locate wkd in Windows 102021-10-26T17:45:14ZGusWKD: Error running auto-key-locate wkd in Windows 10I'm reviewing our instructions to verify Tor Browser[1] and it looks like looks like our wkd has some issues with Windows. It works fine with macOS and Linux.
I asked in gnupg-users mailing list[2], and Werner Koch suggested that
"A r...I'm reviewing our instructions to verify Tor Browser[1] and it looks like looks like our wkd has some issues with Windows. It works fine with macOS and Linux.
I asked in gnupg-users mailing list[2], and Werner Koch suggested that
"A reason for the failed handhake might be that no common parameters
could be found. We would need to look at the server log or run tests
with that server to see what it expects. I copy the full TLS log below.
I have no GNUTLS based build currently available, if that works, it log
could give also some conclusion. However, on Windows we always use
NTBTLS."
Here's the log:
```
DBG: ntbtls(2): handshake
DBG: ntbtls(2): client state: 0 (hello_request)
DBG: ntbtls(3): flush output
DBG: ntbtls(2): client state: 1 (client_hello)
DBG: ntbtls(3): flush output
DBG: ntbtls(2): write client_hello
DBG: ntbtls(3): client_hello, max version: [3:3]
DBG: ntbtls(3): client_hello, current time: 1585298512
DBG: client_hello, random bytes: 5e7dbc5008b76aa83d09c4393a4bdbe792ad9fee5198c6d9f88357ad16020156
DBG: ntbtls(3): client_hello, session id len.: 0
DBG: client_hello, session id:
DBG: ntbtls(5): client_hello, add ciphersuite: 49192 TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384
DBG: ntbtls(5): client_hello, add ciphersuite: 107 TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite: 49172 TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 57 TLS-DHE-RSA-WITH-AES-256-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 49271 TLS-ECDHE-RSA-WITH-CAMELLIA-256-CBC-SHA384
DBG: ntbtls(5): client_hello, add ciphersuite: 196 TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite: 136 TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 49191 TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite: 103 TLS-DHE-RSA-WITH-AES-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite: 49171 TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 51 TLS-DHE-RSA-WITH-AES-128-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 49270 TLS-ECDHE-RSA-WITH-CAMELLIA-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite: 190 TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite: 69 TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 49170 TLS-ECDHE-RSA-WITH-3DES-EDE-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 22 TLS-DHE-RSA-WITH-3DES-EDE-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 49208 TLS-ECDHE-PSK-WITH-AES-256-CBC-SHA384
DBG: ntbtls(5): client_hello, add ciphersuite: 179 TLS-DHE-PSK-WITH-AES-256-CBC-SHA384
DBG: ntbtls(5): client_hello, add ciphersuite: 49206 TLS-ECDHE-PSK-WITH-AES-256-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 145 TLS-DHE-PSK-WITH-AES-256-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 49307 TLS-ECDHE-PSK-WITH-CAMELLIA-256-CBC-SHA384
DBG: ntbtls(5): client_hello, add ciphersuite: 49303 TLS-DHE-PSK-WITH-CAMELLIA-256-CBC-SHA384
DBG: ntbtls(5): client_hello, add ciphersuite: 49207 TLS-ECDHE-PSK-WITH-AES-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite: 178 TLS-DHE-PSK-WITH-AES-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite: 49205 TLS-ECDHE-PSK-WITH-AES-128-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 144 TLS-DHE-PSK-WITH-AES-128-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 49302 TLS-DHE-PSK-WITH-CAMELLIA-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite: 49306 TLS-ECDHE-PSK-WITH-CAMELLIA-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite: 49204 TLS-ECDHE-PSK-WITH-3DES-EDE-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 143 TLS-DHE-PSK-WITH-3DES-EDE-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 61 TLS-RSA-WITH-AES-256-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite: 53 TLS-RSA-WITH-AES-256-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 192 TLS-RSA-WITH-CAMELLIA-256-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite: 132 TLS-RSA-WITH-CAMELLIA-256-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 60 TLS-RSA-WITH-AES-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite: 47 TLS-RSA-WITH-AES-128-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 186 TLS-RSA-WITH-CAMELLIA-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite: 65 TLS-RSA-WITH-CAMELLIA-128-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 10 TLS-RSA-WITH-3DES-EDE-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 183 TLS-RSA-PSK-WITH-AES-256-CBC-SHA384
DBG: ntbtls(5): client_hello, add ciphersuite: 149 TLS-RSA-PSK-WITH-AES-256-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 49305 TLS-RSA-PSK-WITH-CAMELLIA-256-CBC-SHA384
DBG: ntbtls(5): client_hello, add ciphersuite: 182 TLS-RSA-PSK-WITH-AES-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite: 148 TLS-RSA-PSK-WITH-AES-128-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 49304 TLS-RSA-PSK-WITH-CAMELLIA-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite: 147 TLS-RSA-PSK-WITH-3DES-EDE-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 175 TLS-PSK-WITH-AES-256-CBC-SHA384
DBG: ntbtls(5): client_hello, add ciphersuite: 141 TLS-PSK-WITH-AES-256-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 49301 TLS-PSK-WITH-CAMELLIA-256-CBC-SHA384
DBG: ntbtls(5): client_hello, add ciphersuite: 174 TLS-PSK-WITH-AES-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite: 140 TLS-PSK-WITH-AES-128-CBC-SHA
DBG: ntbtls(5): client_hello, add ciphersuite: 49300 TLS-PSK-WITH-CAMELLIA-128-CBC-SHA256
DBG: ntbtls(5): client_hello, add ciphersuite: 139 TLS-PSK-WITH-3DES-EDE-CBC-SHA
DBG: ntbtls(3): client_hello, got 54 ciphersuites
DBG: ntbtls(3): client_hello, compress len.: 2
DBG: ntbtls(3): client_hello, compress alg.: 1 0
DBG: ntbtls(3): client_hello, adding server name extension: 'openpgpkey.torproject.org'
DBG: ntbtls(3): client_hello, adding signature_algorithms extension
DBG: ntbtls(3): client hello, adding supported_elliptic_curves extension
DBG: ntbtls(3): client hello, adding supported_point_formats extension
DBG: ntbtls(3): client_hello, adding session ticket extension
DBG: ntbtls(3): client_hello, total extension length: 88
DBG: ntbtls(3): write record
DBG: ntbtls(3): output record: msgtype = 22, version = [3:3], msglen = 242
DBG: output record sent to network: 16030300f2010000ee03035e7dbc5008b76aa83d09c4393a4bdbe792ad9fee51 \
DBG: 98c6d9f88357ad1602015600006c00ffc028006bc0140039c07700c40088c027 \
DBG: 0067c0130033c07600be0045c0120016c03800b3c0360091c09bc097c03700b2 \
DBG: c0350090c096c09ac034008f003d003500c00084003c002f00ba0041000a00b7 \
DBG: 0095c09900b60094c098009300af008dc09500ae008cc094008b020100005800 \
DBG: 00001e001c0000196f70656e7067706b65792e746f7270726f6a6563742e6f72 \
DBG: 67000d001600140601050104010301020106030503040303030203000a000e00 \
DBG: 0c001700180019001a001b001c000b0002010000230000
DBG: ntbtls(3): flush output
DBG: ntbtls(3): message length: 247, out_left: 247
DBG: ntbtls(3): es_write returned: success
DBG: ntbtls(2): client state: 2 (server_hello)
DBG: ntbtls(3): flush output
DBG: ntbtls(2): read server_hello
DBG: ntbtls(3): read record
DBG: ntbtls(3): fetch input
DBG: ntbtls(3): in_left: 0, nb_want: 5
DBG: ntbtls(3): es_read returned: success
DBG: ntbtls(3): input record: msgtype = 21, version = [3:3], msglen = 2
DBG: ntbtls(3): fetch input
DBG: ntbtls(3): in_left: 5, nb_want: 7
DBG: ntbtls(3): es_read returned: success
DBG: input record from network: 15030300020228
DBG: ntbtls(2): got an alert message, type: [2:40]
DBG: ntbtls(1): is a fatal alert message (msg 40)
DBG: ntbtls(1): (handshake failed)
DBG: ntbtls(1): read_record returned: Fatal alert message received <TLS>
DBG: ntbtls(2): handshake ready
TLS handshake failed: Fatal alert message received <TLS>
error connecting to 'https://openpgpkey.torproject.org/.well-known/openpgpkey/torproject.org/hu/kounek7zrdx745qydx6p59t9mqjpuhdf?l=torbrowser': Fatal alert message received
DBG: ntbtls(2): release
command 'WKD_GET' failed: Fatal alert message received <TLS>
```
[1] gpg --auto-key-locate nodefault,wkd --locate-keys torbrowser at torproject.org https://support.torproject.org/tbb/how-to-verify-signature/
[2] https://lists.gnupg.org/pipermail/gnupg-users/2020-March/063385.htmlanarcatanarcathttps://gitlab.torproject.org/legacy/trac/-/issues/28306Please add signing keys to db.torproject.org2020-10-19T16:05:39ZtraumschulePlease add signing keys to db.torproject.orgNot entirely sure of this is in the scope of db.torproject.org:
For #22637 it would be useful to have all keys in the db which are listed on
https://www.torproject.org/docs/signing-keys.html.en
Then we could link to it instead of pgp.m...Not entirely sure of this is in the scope of db.torproject.org:
For #22637 it would be useful to have all keys in the db which are listed on
https://www.torproject.org/docs/signing-keys.html.en
Then we could link to it instead of pgp.mit.edu which sometimes gives errors.https://gitlab.torproject.org/legacy/trac/-/issues/29677evaluate password management options2020-10-19T16:05:39Zanarcatevaluate password management optionsduring the [[org/meetings/2017Montreal/Notes/BusFactor]] session, one of the things that was discussed was the password management system that is (was?) stored in SVN. Specifically:
* We need a better password management solution than ...during the [[org/meetings/2017Montreal/Notes/BusFactor]] session, one of the things that was discussed was the password management system that is (was?) stored in SVN. Specifically:
* We need a better password management solution than the one we have in corporate SVN right now.
* We should look over if the password's in this database should be rotated.
* Figure out if the passwords for paypal have been rotated by Jon et al and ensure that it will be put in the password database. We should also look into the "paypal dongle" or 2-step authentication?
I have some experience reviewing password managers, so I might be able to provide some advice here if someone expands on the requirements and problems with the current approach.https://gitlab.torproject.org/legacy/trac/-/issues/29455Please update karsten's new PGP subkey2020-10-19T16:05:39ZKarsten LoesingPlease update karsten's new PGP subkeyPlease update karsten's new PGP subkey that is I'm going to attach in a minute. Uploading to the MIT PGP key server and a couple other keyservers failed. Thanks in advance!Please update karsten's new PGP subkey that is I'm going to attach in a minute. Uploading to the MIT PGP key server and a couple other keyservers failed. Thanks in advance!https://gitlab.torproject.org/legacy/trac/-/issues/28138Please refresh my PGP key.2020-10-19T16:05:39ZYawning AngelPlease refresh my PGP key.I decided to generate new sub-keys when they expired a few months ago, instead of extending the expiration for another year like I always do. I would appreciate it if my PGP key could be refreshed at your convenience.
My offline master...I decided to generate new sub-keys when they expired a few months ago, instead of extending the expiration for another year like I always do. I would appreciate it if my PGP key could be refreshed at your convenience.
My offline master key is unchanged.https://gitlab.torproject.org/legacy/trac/-/issues/28150Update legind's PGP key2020-10-19T16:05:39ZJacob Hoffman-AndrewsUpdate legind's PGP key```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Username: legind
Old OpenPGP Fingerprint: 977A04EC512A9D0DB4A56E0ECDCAE8ED6842C592
New OpenPGP Fingerprint: 1073E74EB38BD6D19476CBF8EA9DBF9FB761A677
-----BEGIN PGP SIGNATURE-----
iQIz...```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Username: legind
Old OpenPGP Fingerprint: 977A04EC512A9D0DB4A56E0ECDCAE8ED6842C592
New OpenPGP Fingerprint: 1073E74EB38BD6D19476CBF8EA9DBF9FB761A677
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEfD6+xfAwwR8vpU1fpzOtltUrJSEFAlvOQrMACgkQpzOtltUr
JSGPCxAAg53Z5rCB/VRTbnKPCeDPMUSaQwaP6cL3kJbU6IDIkBQBIQQ00+z+i5LK
uiT9F31QudH4rmsOwHl7enBSXMSVOM2Gk9au2zPmr9b0h1N2l286SFKB49eeFwm3
L8ZB+JB3soAjcF3RX+wP1nP/DnM4GlNzQbjcw4gC3Dgk5UXQt16ABNi+JZQokt3n
+g2ifhoZjGWMQKmRWLq3w7X/4Pz9skikONh1ZmBrLQk378ENwt5h1FdC2V2UvbIE
AFMNmM1qieMTDOPvz8BzovqhAvrvxDrBgkV6/cQdeS9E8f6uv9FCG+v+yfGDHuMh
/pg5EwWPtKSKr32Udrqg6H1CPaHw6kpKiDSWfg7dzYH8U8hADA+dj9Hea9BsKEWL
qCHQZv9gDu7XdcDLJI6+eq4skqotU3fT1edQK3vGBvaht+Gzm0IixrBs0GtbWQH9
c+oNW4O9OvWWmSddL5ndx5ujnsLIvWjvxd1uhFgTOw/lSYXCmlljpJGiLJNkE+jG
yHuaubRusXE1fz8d1h281JJcFcUk1PS+Xga9kv/vWvdqbawUitNmgy88p6UL7CL/
BZTwxltRwqmWig5R+wuoRYFR3lfT2aofju0TGuWQZTGxPWct1rT4ZR4umne7dmK1
XemhSfYpXYhc5TqMbiuXWZ1M+ySYZIdSInCQK9LccwBrl+TFQKs=
=bl7r
-----END PGP SIGNATURE-----
```https://gitlab.torproject.org/legacy/trac/-/issues/28891Please refresh sysrqb's PGP key2020-10-19T16:05:38ZMatthew FinkelPlease refresh sysrqb's PGP keyThe expiration date is extended on the master key and there are new subkeys.
```
$ gpg -k CB8FC772D1AA1D30
pub rsa4096 2014-06-26 [SC] [expires: 2019-12-18]
CE1782624600EE98764C6D9CCB8FC772D1AA1D30
uid [ unknown] Matth...The expiration date is extended on the master key and there are new subkeys.
```
$ gpg -k CB8FC772D1AA1D30
pub rsa4096 2014-06-26 [SC] [expires: 2019-12-18]
CE1782624600EE98764C6D9CCB8FC772D1AA1D30
uid [ unknown] Matthew Finkel <Matthew.Finkel@gmail.com>
uid [ unknown] Matthew Finkel <sysrqb@torproject.org>
uid [ unknown] Matthew Finkel <sysrqb@protonmail.com>
uid [ unknown] Matthew Finkel <sysrqb@riseup.net>
sub rsa4096 2018-06-13 [S] [expires: 2018-12-21]
sub rsa4096 2018-06-13 [E] [expires: 2018-12-21]
sub rsa4096 2018-06-13 [A] [expires: 2018-12-21]
sub rsa4096 2018-12-18 [S] [expires: 2019-06-16]
sub rsa4096 2018-12-18 [E] [expires: 2019-06-16]
sub rsa4096 2018-12-18 [A] [expires: 2019-06-16]
```https://gitlab.torproject.org/legacy/trac/-/issues/27600Please update my PGP public key (2018 edition)2020-10-19T16:05:38ZGeorg KoppenPlease update my PGP public key (2018 edition)Another year, another subkey update. Please fetch the new subkeys for LDAP.Another year, another subkey update. Please fetch the new subkeys for LDAP.https://gitlab.torproject.org/legacy/trac/-/issues/27726Please, update my OpenPGP key in LDAP2020-10-19T16:05:38ZjugaPlease, update my OpenPGP key in LDAP```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Please, update my OpenPGP key in LDAP.
gpg --keyserver hkp://jirk5u4osbsr34t5.onion --recv-key 2DA81D01455C3A0032198850F305447AF806D46B
(in case other servers are not update yet)
---...```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Please, update my OpenPGP key in LDAP.
gpg --keyserver hkp://jirk5u4osbsr34t5.onion --recv-key 2DA81D01455C3A0032198850F305447AF806D46B
(in case other servers are not update yet)
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE8dks+zLJootHUvobovpe/Q2oaYQFAlueRiEACgkQovpe/Q2o
aYQxTRAAxoz+a8jdicDg7rMhzaFg0JRXMEyHM40W/XW3k4ZSNd7nxrNui0oEhv/f
Q4DGekSW3y21N7uEesMLAuV1EP32p1momZD41ko/Zp1AKyiIcGR7xvZpKd+PQk6m
BhkhwU+4c0BEZAGv2AEiNGB7sFu231Y/48oV2sw1UwJF1idAFkTTy6V4lgwEIY5q
6sGMTl4wNS/fWcKhaJqSe7s1kIKrPD25M1Lf/Yysqbr0lP6ewzBrXBZdg6pOLejl
5BlfFabl8UQMhE9uUfJ9mfgz1Acxd8yiDURGnbRxJFZBM4aGrTYzNCJXKY92Iz+P
kW9bu6uIuiN9tbV66cOYn6RZQNZSbCG9UWeIdQUcRJq6YaTGI+zpRzGnIlie+cPw
Jr46CSSKCaQABcNFuEDkMnnD3bXkDH+LIgBi8ODiSsqw0cs87H8K+b8ITS1hgEop
ymwYf/CBpzTChEDSmmXgsVpx1+BBJGQQSruRJDCAY3SKfd1HcLJuDjkSZ6u8ArlL
dwFg8WnFTfX8vGzypzociPL+OW9YnKXmFHyORexkfOtTZK6aY7s0m3UXrb0s5sBT
PC3fvd0yc3HI9CkcV947ZaOB2DN/gepO2bhZvwLEJe1xJWrnxzDI4P+QUJrWuFug
t2W3Mm3bjqot4nvp4sqaxoDZ+H8LsP0u5GLCuDKaML2xIQhhkNw=
=byEU
-----END PGP SIGNATURE-----
```
Edit: remove quote from body, add quote outside body, with the correct symbolhttps://gitlab.torproject.org/legacy/trac/-/issues/27748Updated PGP expiration for nickm2020-10-19T16:05:38ZNick MathewsonUpdated PGP expiration for nickm```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
17 September 2018
Hello. Please update my PGP key -- I have issued new expiration dates for
the primary key and subkeys.
pub 4096R/FE43009C4607B1FB 2016-09-21 [expires: 2020-09-16]...```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
17 September 2018
Hello. Please update my PGP key -- I have issued new expiration dates for
the primary key and subkeys.
pub 4096R/FE43009C4607B1FB 2016-09-21 [expires: 2020-09-16]
Key fingerprint = 2133 BC60 0AB1 33E1 D826 D173 FE43 009C 4607 B1FB
uid Nick Mathewson <nickm@alum.mit.edu>
uid Nick Mathewson <nickm@wangafu.net>
uid Nick Mathewson <nickm@torproject.org>
uid Nick Mathewson <nickm@freehaven.net>
sub 4096R/6AFEE6D49E92B601 2016-09-23 [expires: 2020-09-16]
sub 4096R/91DDED0286AC8BFF 2016-09-23 [expires: 2020-09-16]
Thanks,
Nick Mathewson
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJbn5z3AAoJEGr+5tSekrYBoa0QAIQR9vpCN0Dbx6ZDe0EXrqlR
mFF+US+PXX1plCXGOwQjY2C+VwxNmAyrf/p+KS4pcOei1/g3TI1GJUstiYplqFN/
ODQWLZV7O3wq7ky8QedYvnbEn6jGH2z1WOP0itMbzXwxoEJd6RyL6+fvq6JQ9CBa
ulNtRN/CBg+pO+JENuSnkgXHFbNk9vd9YklhWu2GsZr6cfiuEn7eU+44AVzazE8o
gXgHa3RFbc6BWYL37x4csUy2j+1+cLBvBC6xPDii/Cj1yJt8EqQhbOu2t7586SKj
tRQUJUVhUHBUFuE4ps3wGsaWBbatPem8b5KJCCiH9vV0Qa+YH1FJGf0/CbjTghHx
orL52skQR9LYZZg31CLJErcUHY4ZsZqz+muMW3tYfqHMkMpY+ppxJ/tfOFvMqkt8
bz8eHUYyWHfh1mTsfJlImK66agrMDDWISk0JFrXAeapyaVPgoMhKaxe2uBjxd1hL
m8zcJX//N5QSrQAf6YOFI8Cjh1TZ6OH6kVqIUxJ5EB/oK5m/pbpFWFHR4Qg+Tykq
4Vc7O/Romngqv7HE16pJ3+Fu4OpDsnf8dQIvx3Ubk26L+2RGQmMskKo27r6qBlsV
4T0UFptddzr/XTJf8MVgH8SgXgyPj21Ahrjt6H9/eO/3w2sEBnkBTn9B3PgU/7ya
FQcyd9RRfKLVYZblFwwR
=KoIv
-----END PGP SIGNATURE-----
```https://gitlab.torproject.org/legacy/trac/-/issues/30881answer the opsreportcard questionnaire, AKA the "limoncelli test"2020-07-06T17:41:35Zanarcatanswer the opsreportcard questionnaire, AKA the "limoncelli test"Tom Limoncelli is the reknowned author of [Time management for sysadmins](https://www.tomontime.com/) and [practice of network and system administration](https://the-sysadmin-book.com/), two excellent books I recommend every sysadmin rea...Tom Limoncelli is the reknowned author of [Time management for sysadmins](https://www.tomontime.com/) and [practice of network and system administration](https://the-sysadmin-book.com/), two excellent books I recommend every sysadmin reads attentively.
He made up a [32-question test](https://everythingsysadmin.com/the-test.pdf) (PDF, website version on [opsreportcard.com](http://opsreportcard.com/) or the [previous one-page HTML version](http://web.archive.org/web/20120827040816/http://everythingsysadmin.com:80/the-test.html)) that covers the basic of a well-rounded setup. I believe we will get a good score, but going through the list will make sure we don't miss anything.anarcatanarcathttps://gitlab.torproject.org/legacy/trac/-/issues/30009consider trocla for secrets management in puppet2020-07-06T14:05:06Zanarcatconsider trocla for secrets management in puppetsecrets generated by puppet currently use a custom hkdf function that is homegrown. the ad-hoc standard for this in the puppet community i'm usually working with is [trocla](https://github.com/duritong/trocla) which is [well integrated w...secrets generated by puppet currently use a custom hkdf function that is homegrown. the ad-hoc standard for this in the puppet community i'm usually working with is [trocla](https://github.com/duritong/trocla) which is [well integrated with puppet](https://github.com/duritong/puppet-trocla).
Trocla generates, on the fly, a strong random password for each key you ask it. It also supports various hashing mechanisms (bcrypt, pgsql, x509, etc) so that the Puppet client never actually sees the cleartext. It seems like a better approach than sending the cleartext like we currently do.
So I'd like to start using this for new code and possibly convert existing code to this, if that's acceptable.anarcatanarcathttps://gitlab.torproject.org/legacy/trac/-/issues/29684setup a grafana server somewhere2020-07-06T14:05:05Zanarcatsetup a grafana server somewherePrometheus on its own is nice, but the graphs are not that great. We should setup Grafana on top of that instead.
Grafana is a pain in the bottom to install in Debian: there are upstream packages, but they are [a mess](https://bugs.debi...Prometheus on its own is nice, but the graphs are not that great. We should setup Grafana on top of that instead.
Grafana is a pain in the bottom to install in Debian: there are upstream packages, but they are [a mess](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835210#42) so my approach has been to use Docker so far.
I guess we can use the test server for this for now.
note there is a puppet module for grafana, which supports deploying both with the upstream debian package and docker: https://forge.puppet.com/puppet/grafanaanarcatanarcathttps://gitlab.torproject.org/legacy/trac/-/issues/29816replace "Tor VM hosts" spreadsheet with Grafana dashboard2020-06-25T21:16:43Zanarcatreplace "Tor VM hosts" spreadsheet with Grafana dashboardOur KVM allocation strategy is currently managed through a Google spreadsheet. This is suboptimal for a few reasons:
1. it is hard to keep up to date - for example, moly is not listed in there even though it's in LDAP as a "KVM host"
...Our KVM allocation strategy is currently managed through a Google spreadsheet. This is suboptimal for a few reasons:
1. it is hard to keep up to date - for example, moly is not listed in there even though it's in LDAP as a "KVM host"
2. it's not real time data - for example, even if a host is allocated one vCPU, it might be totally idle most of the time and doing mostly network or disk, while another one might hit the CPU hard. actual load is what matters
3. it's hosted by Google - that has a few problems, the most important of which is that some TPA do not actually *want* to use Google services and might be reluctant to update it, worsening problem 1
I propose we shift this to a Grafana dashboard. I already have a prototype in the form of the [Node exporter server metrics Grafana Dashboard](https://grafana.com/dashboards/405) which shows multiple hosts basic stats in parallel. I set the default of the dashboard in Grafana to show the 6 KVM hosts:
<https://grafana.torproject.org/d/ER3U2cqmk/node-exporter-server-metrics?orgId=1&from=now-12h&to=now&var-node=kvm4.torproject.org:9100&var-node=kvm5.torproject.org:9100&var-node=macrum.torproject.org:9100&var-node=moly.torproject.org:9100&var-node=textile.torproject.org:9100&var-node=unifolium.torproject.org:9100>
That looks like this:
![https://paste.anarc.at/snaps/snap-2019.04.17-16.48.43.png, 700px](https://paste.anarc.at/snaps/snap-2019.04.17-16.48.43.png, 700px)
.. but it's not ideal:
* it's showing irrelevant stats for this purpose like context switches or detailed disk or memory stats
* it's missing critical information like the number of KVM guests hosted on the machine, how many CPUs and disk space is allocated and so on
This is the information we should be showing:
* disk capacity vs allocation
* disk utilization
* CPU count vs allocation
* actual CPU utilization
* load?
* memory capacity vs allocation
* actual memory usage
Some of that information currently lives *only* in the spreadsheet. For example, disk allocations are only available there, as the KVM guests run on QCOW (Qemu Copy On Write) filesystems that only take space when actually used by the guest. This has the advantage of allowing us to over-provision, but means we must keep that metadata somewhere else.
So for now it's in the spreadsheet, but we could find a way to move it somewhere Prometheus can scrape. One trick that Prometheus has is that it can expose metrics stored as text files in `/var/lib/prometheus/node-exporter/*.prom`. This is how the smartctl and APT metrics get shipped for example: a cron job (well, a systemd timer) regularly writes that file, atomically. So one option could be to move this information to (say) LDAP or Puppet/Hiera and write that information into that file using a cronjob (LDAP) or Puppet (Hiera).
Then we'd build a custom Grafana dashboard and get rid of the other spreadsheet.
A stop-gap measure might be to simplify the spreadsheet and move it to a plain text markdown file. We would lose the automatic calculations the spreadsheet provide, in exchange for easier updating and transparency.https://gitlab.torproject.org/legacy/trac/-/issues/32558clarify what happens to email when we retire a user2020-06-25T20:36:20Zanarcatclarify what happens to email when we retire a userAs part of improving the offboarding process (#32519), we should especially look at how email works.
Right now, when we [retire a user](https://help.torproject.org/tsa/howto/retire-a-user/), their account is first "locked" which means t...As part of improving the offboarding process (#32519), we should especially look at how email works.
Right now, when we [retire a user](https://help.torproject.org/tsa/howto/retire-a-user/), their account is first "locked" which means their access to various services is disabled. But their email still works for 186 days (~6 months). After that date, in theory, their email aliases start completely dropping email (needs to be onfirmed).
It's unclear if that's the right policy to follow. Some people feel that an email alias should stay around forever, as it is an inalienable human right.
Others feel that certain administrative roles should be forwarded when a person leave. If, say, "Alice" (fictive name) was doing fundraising but was using `alice@torproject.org` for that work. When they leave, should we forward `alice@` to `fundraising@torproject.org`?
But then what if Alice was using their work email for private correspondance either? Maybe the fundraising team shouldn't be able to see *those* communications.
One proposal could be that the default policy is this:
1. email @torproject.org is "function" email and is destined only for torproject.org related work
2. when a person leave their position, that email gets deactivated after a 6 months delay
3. in extreme cases, some forward may be *temporarily* enabled to reset accesses or re-establish contacts with a provider or third-party
It is also possible that there could be *two* policies, one for TPI employees and one for other TPO people.