| 3 Jun 2022 |
 michael | the paths approach is only feasible after ciarans reverse proxies are decommissioned | 08:20:46 |
| michael | * the paths approach is only feasible after ciarans reverse proxies are decommissioned | 08:20:56 |
| michael | not sure which approach is easier to maintain in the long run | 08:22:17 |
| michael | my personal preference would be keeping individual domains per service | 08:22:48 |
 jochensp | would you need to regenerate the website to change the URL to an onion one? | 08:45:56 |
| michael | no, this setup is using the nginx sub_filter module for replacing urls on the fly | 08:50:49 |
| michael | (ideally the website itself wouldn't have any fqdns, but that's sadly not the case) | 08:52:04 |
| jochensp | yeah, I think that would be nice | 08:52:28 |
| jochensp | is there anything else then search that needs the fqdn? | 08:53:00 |
| michael | technically speaking, no | 08:53:24 |
| michael | i think jekyll-fdroid or whatever is parsing index-v1 however is copying entire urls from the index to the website instead of converting them to relative paths | 08:54:57 |
| jochensp | that sounds fixable | 08:56:42 |
| michael | yes, but as I said I've configured nginx sub_filter, so there's no need to look into this straight away | 09:00:08 |
| michael | I also think it's good practice to keep sub_filter in place even when the website eventually only contains local paths just in case of accidental url-leaks | 09:01:42 |
| michael | * I also think it's good practice to keep sub_filter in place even when the website eventually only contains local paths just in case accidental url-leaks | 09:01:55 |
| jochensp | yeah | 09:02:03 |
| michael | * I also think it's good practice to keep sub_filter in place even when the website eventually only contains local paths just in case of accidental url-leaks | 09:02:16 |
| 24 Jun 2022 |
| michael | it:13 tor+http://2s4yqjx5ul6okpp3f2gaunr2syex5jgbfpfvhxxbbjwnrsvbk5v3qbid.onion/debian bullseye InRelease
Err:14 tor+http://5ajw6aqf3ep7sijnscdzw77t7xq4xjpsy335yb2wiwgouo7yfxtjlmid.onion/debian-security bullseye-security InRelease
Timed out while waiting to read 'first part of response' from proxy socks5h://127.0.0.1:9050 [IP: 127.0.0.1 9050]
Get:15 tor+http://2s4yqjx5ul6okpp3f2gaunr2syex5jgbfpfvhxxbbjwnrsvbk5v3qbid.onion/debian bullseye-updates InRelease [39.4 kB]
0% [15 InRelease 22.9 kB/39.4 kB 58%] 414 B/s 39s
| 13:51:36 |
| michael | _hc the debian repo onions you suggested seem to have troubles | 13:52:32 |
 _hc | are you sure the tor daemon is running correctly? | 13:52:59 |
| _hc |
Timed out while waiting to read 'first part of response' from proxy socks5h
| 13:53:12 |
| michael | I restarted tor.service already but that didn't make it faster | 13:53:59 |
| _hc | if that tor setup is troublesome, you could remove it | 13:54:20 |
| michael | I'll keep an eye on it maybe it's a temporary thing | 13:55:07 |
| michael | Is there anything else I can do besides restarting tor.service? | 13:55:29 |
| _hc | no, don't think so. | 13:55:38 |
| _hc | i've been seen that too, perhaps the tor network is a bit slow at the moment | 13:55:44 |
| michael | okay, thanks :) | 13:55:51 |
| _hc | I wonder if there is a way to config apt so that it tries the tor method but if it fails, it just silently fails over to one of the https mirrors. Then it would be perhaps more reliable, while leaking less data. | 13:56:54 |
| _hc | but probably not worth a lot of time, unless someone is particularly interested in tackling that problem | 13:57:16 |
