Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T13:31:53Zhttps://gitlab.torproject.org/legacy/trac/-/issues/34449There are too many networks in the chutney networks directory.2020-06-13T13:31:53ZNick MathewsonThere are too many networks in the chutney networks directory.There are 66 "networks" files in the chutney networks directory; of these, I doubt more than a few are actually used for testing things nowadays. I believe we should move aside (or just remove) the ones that are not in current use.
Thi...There are 66 "networks" files in the chutney networks directory; of these, I doubt more than a few are actually used for testing things nowadays. I believe we should move aside (or just remove) the ones that are not in current use.
This came up for me because I will need to make a change to some networks in #34447, and for now it is very hard to tell which of these 66 files I need to make a change for.Tor: 0.4.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34448Chutney templates may need an option-fallback feature2020-06-13T13:31:53ZNick MathewsonChutney templates may need an option-fallback featureIn the parent, we want to split AssumeReachable into AssumeSelfReachable and AssumeOthersReachable. We will want Chutney authorities to set AssumeSelfReachable if that option exists, but AssumeReachable if it does not.
That's not somet...In the parent, we want to split AssumeReachable into AssumeSelfReachable and AssumeOthersReachable. We will want Chutney authorities to set AssumeSelfReachable if that option exists, but AssumeReachable if it does not.
That's not something that the chutney config system can do right now AFAICT.
It might be simpler to do this with a magic bit of code specific to assumereachable as part of the chutney system, but I'm not sure.Tor: 0.4.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34446TestingTorNetwork should not set AssumeReachable 12020-06-13T15:53:49ZNick MathewsonTestingTorNetwork should not set AssumeReachable 1For S55 we are trying to get self-tests and remote-tests working with IPv6. To make sure we've succeed, we need to try them with Chutney. But to try them with chutney, we need them to be enabled.
With #33583 we removed AssumeReachable...For S55 we are trying to get self-tests and remote-tests working with IPv6. To make sure we've succeed, we need to try them with Chutney. But to try them with chutney, we need them to be enabled.
With #33583 we removed AssumeReachable from the chutney configurations. But that didn't actually have any effect, since `AssumeReachable 1` is implicit in `TestingTorNetwork 1`.Tor: 0.4.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34445Split assumereachable into self and authority components2020-06-13T15:53:48ZNick MathewsonSplit assumereachable into self and authority componentsThis option governs both "should I check if I, a relay, reachable" and "should I, an authority, check if relays are reachable"? These should really be separated.
Calling this S55-must since we need it for chutney-ipv6 stuff.This option governs both "should I check if I, a relay, reachable" and "should I, an authority, check if relays are reachable"? These should really be separated.
Calling this S55-must since we need it for chutney-ipv6 stuff.Tor: 0.4.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34437migrate help.tpo into a gitlab wiki2020-06-13T17:02:28Zanarcatmigrate help.tpo into a gitlab wikiwe are currently using ikiwiki to host our documentation. that has served us well so far: it's available as a static site in the static mirror system and allows all sysadmins to have a static, offsite copy of the documentation when every...we are currently using ikiwiki to host our documentation. that has served us well so far: it's available as a static site in the static mirror system and allows all sysadmins to have a static, offsite copy of the documentation when everything is down.
but ikiwiki is showing its age. it's an old program written in Perl, difficult to theme and not very welcoming to new users. for example, it's impossible for a user unfamiliar with git to contribute to the documentation. it also has its own unique Markdown dialect that is not used anywhere else. and while Markdown itself is not standardized and has lots of such dialects, there is /some/ convergence around CommonMark and GFM (GitHub's markdown) as de-facto standards at least, which ikiwiki still has to catchup with. it also has powerful macros which are nice to make complex websites, but do not render in the offline documentation, making us dependent on the rendered copy (as opposed to setting up client-side tools to peruse the documentation).
gitlab wikis, in contrast, have a web interface to edit pages. it doesn't have the macros ikiwiki has, but that's nothing a few commandline hacks can't fix... or at least we should consider it. they don't have macros or any more powerful features that ikiwiki has, but maybe that's exactly what we want.
this is not blocking the trac to gitlab migration, but it would be nice to jump onboard with everyone, since we will be migrating the Trac wiki onto gitlab as well...anarcatanarcathttps://gitlab.torproject.org/legacy/trac/-/issues/34436document the static mirror network and onionbalance system better2020-06-13T17:02:28Zanarcatdocument the static mirror network and onionbalance system betterwe have some documentation on the static mirroring system here:
https://help.torproject.org/tsa/howto/static-component/
it's mostly procedural and minimal: add a component, remove a component and that's it. it doesn't explain at all ho...we have some documentation on the static mirroring system here:
https://help.torproject.org/tsa/howto/static-component/
it's mostly procedural and minimal: add a component, remove a component and that's it. it doesn't explain at all how the system works, how to create or remove a new node in the network, how onion services interact with it, and how it actually works in puppet.
all this should be better documented. for example, I should be able to resolve #34396 without asking weasel. :)anarcatanarcathttps://gitlab.torproject.org/legacy/trac/-/issues/34432Integrate fenix toolchain into tor-browser-build's master2020-06-16T01:26:35ZGeorg KoppenIntegrate fenix toolchain into tor-browser-build's masterWe decided to not create a new branch to take care of the Fenix toolchain while continuing to build nightly builds with the ESR 68 toolchains (and later ESR 78 toolchains for desktop builds). Rather, we'll follow boklm's idea of namespac...We decided to not create a new branch to take care of the Fenix toolchain while continuing to build nightly builds with the ESR 68 toolchains (and later ESR 78 toolchains for desktop builds). Rather, we'll follow boklm's idea of namespacing the projects to fenix-$project if there are Fenix specific needs and keep everything on `master`. This should avoid diverging branches and a tricky merge at the end.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/legacy/trac/-/issues/34426document ud-ldap and its architecture better2020-06-13T17:02:27Zanarcatdocument ud-ldap and its architecture betterour LDAP documentation is minimal. go through the thing and document how the different components play with each other and common tasks (like creating a user and so on).our LDAP documentation is minimal. go through the thing and document how the different components play with each other and common tasks (like creating a user and so on).anarcatanarcathttps://gitlab.torproject.org/legacy/trac/-/issues/34425document gitlab in our service docs2020-06-13T17:02:27Zanarcatdocument gitlab in our service docsin particular for backups (so linked to/from https://help.torproject.org/tsa/howto/backup/) but also our general policies and procedures.in particular for backups (so linked to/from https://help.torproject.org/tsa/howto/backup/) but also our general policies and procedures.anarcatanarcathttps://gitlab.torproject.org/legacy/trac/-/issues/34424backport fabric to debian buster2020-06-13T17:02:27Zanarcatbackport fabric to debian busterWe rely on newer features of Fabric in our configuration that are not present in Debian buster. upload a backport to the official Debian backports.We rely on newer features of Fabric in our configuration that are not present in Debian buster. upload a backport to the official Debian backports.anarcatanarcathttps://gitlab.torproject.org/legacy/trac/-/issues/34420enable Gitlab backups2020-06-13T17:02:26ZHiroenable Gitlab backupsI am configuring gitlab backups via cron and the puppet module.
Here is a MR:
https://share.riseup.net/#P2Yu4rpQubidQ0V5r7QM1Q
This does the following:
Configure gitlab backups via the puppet module.
Will create a backup file every ni...I am configuring gitlab backups via cron and the puppet module.
Here is a MR:
https://share.riseup.net/#P2Yu4rpQubidQ0V5r7QM1Q
This does the following:
Configure gitlab backups via the puppet module.
Will create a backup file every night at 2 am on /srv/backups
It will use Gitlab backup command which is a wrapper of the rake task within gitlab rails.
More information on: https://docs.gitlab.com/ee/raketasks/backup_restore.html#back-up-gitlab
It also set a cron job to backup gitlab secrets every night at 2 am and place it on /srv/backups.HiroHirohttps://gitlab.torproject.org/legacy/trac/-/issues/34419move staticiforme/static-source off kvm52020-06-13T17:02:25Zweasel (Peter Palfrader)move staticiforme/static-source off kvm5This can be done at any convenient time, but it'll take a bit due to disk sizeThis can be done at any convenient time, but it'll take a bit due to disk sizeweasel (Peter Palfrader)weasel (Peter Palfrader)https://gitlab.torproject.org/legacy/trac/-/issues/34418move colchicifolium/collector off kvm52020-06-13T17:02:25Zweasel (Peter Palfrader)move colchicifolium/collector off kvm5We would like to move the VM to our new ganeti cluster.
Karsten, Given the big disks, this might take several hours.
Are there any constraints from your end or should we just do it at a convenient time?We would like to move the VM to our new ganeti cluster.
Karsten, Given the big disks, this might take several hours.
Are there any constraints from your end or should we just do it at a convenient time?weasel (Peter Palfrader)weasel (Peter Palfrader)https://gitlab.torproject.org/legacy/trac/-/issues/34417move henryi/consensus-health off kvm52020-06-13T17:02:25Zweasel (Peter Palfrader)move henryi/consensus-health off kvm5We would like to move the VM to our new ganeti cluster.
Are there any constraints from your end or should we just do it at a convenient time?We would like to move the VM to our new ganeti cluster.
Are there any constraints from your end or should we just do it at a convenient time?weasel (Peter Palfrader)weasel (Peter Palfrader)https://gitlab.torproject.org/legacy/trac/-/issues/34416move materculae/exonerator off kvm52020-06-13T17:02:24Zweasel (Peter Palfrader)move materculae/exonerator off kvm5We would like to move the VM to our new ganeti cluster.
Karsten, Given the big disks, this might take several hours.
Are there any constraints from your end or should we just do it at a convenient time?We would like to move the VM to our new ganeti cluster.
Karsten, Given the big disks, this might take several hours.
Are there any constraints from your end or should we just do it at a convenient time?weasel (Peter Palfrader)weasel (Peter Palfrader)https://gitlab.torproject.org/legacy/trac/-/issues/34415move carinatum/doctor off kvm52020-06-13T17:02:24Zweasel (Peter Palfrader)move carinatum/doctor off kvm5weasel (Peter Palfrader)weasel (Peter Palfrader)https://gitlab.torproject.org/legacy/trac/-/issues/34396Remove or clarify atlas on onion.torproject.org2020-06-13T17:02:23ZcRemove or clarify atlas on onion.torproject.orgSince atlas.tpo is no longer running, it should be removed from the listing on onion.tpo, or a notice to take its place that it redirects to metrics.tpo (assuming the atlas onion is active and redirects).Since atlas.tpo is no longer running, it should be removed from the listing on onion.tpo, or a notice to take its place that it redirects to metrics.tpo (assuming the atlas onion is active and redirects).weasel (Peter Palfrader)weasel (Peter Palfrader)https://gitlab.torproject.org/legacy/trac/-/issues/34374put trac readonly on june 12th 20202020-06-13T17:02:22Zanarcatput trac readonly on june 12th 2020as agreed in the last all-hands meeting, trac will be readonly on june 12th 2020 for the final migration, and will remain so for 6 months, until it is permanently archived and transformed into a redirect to gitlab (#34373).as agreed in the last all-hands meeting, trac will be readonly on june 12th 2020 for the final migration, and will remain so for 6 months, until it is permanently archived and transformed into a redirect to gitlab (#34373).HiroHirohttps://gitlab.torproject.org/legacy/trac/-/issues/34318BridgeDB doesn't like non-UTF8 encoded requests2020-06-13T18:30:05ZPhilipp Winterphw@torproject.orgBridgeDB doesn't like non-UTF8 encoded requestsI stumbled upon the following exception in BridgeDB's log:
```
Traceback (most recent call last):
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/web/http.py", line 1755, in dataReceived
finishCallbac...I stumbled upon the following exception in BridgeDB's log:
```
Traceback (most recent call last):
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/web/http.py", line 1755, in dataReceived
finishCallback(data[contentLength:])
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/web/http.py", line 2171, in _finishRequestBody
self.allContentReceived()
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/web/http.py", line 2284, in allContentReceived
req.requestReceived(command, path, version)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/web/http.py", line 946, in requestReceived
self.process()
--- <exception caught here> ---
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/web/server.py", line 235, in process
self.render(resrc)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/web/server.py", line 302, in render
body = resrc.render(self)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/web/resource.py", line 265, in render
return m(request)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/bridgedb-0.10.0+34.ga6eb0d1c.dirty-py3.7.egg/bridgedb/distributors/https/server.py", line 722, in render_POST
return CaptchaProtectedResource.render_POST(self, request)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/bridgedb-0.10.0+34.ga6eb0d1c.dirty-py3.7.egg/bridgedb/distributors/https/server.py", line 573, in render_POST
request.args = stringifyRequestArgs(request.args)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/bridgedb-0.10.0+34.ga6eb0d1c.dirty-py3.7.egg/bridgedb/distributors/https/server.py", line 109, in stringifyRequestArgs
arg = arg if isinstance(arg, str) else arg.decode("utf-8")
builtins.UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc2 in position 1: invalid continuation byte
```Armin HuremagicArmin Huremagichttps://gitlab.torproject.org/legacy/trac/-/issues/34304new gnt-fsn node (fsn-node-07)2020-06-13T17:02:17Zanarcatnew gnt-fsn node (fsn-node-07)need to create one last ganeti node to replace kvm5 (#33084)need to create one last ganeti node to replace kvm5 (#33084)HiroHiro