Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T18:00:52Zhttps://gitlab.torproject.org/legacy/trac/-/issues/16612Support parsing of .xz compressed tarballs.2020-06-13T18:00:52ZTracSupport parsing of .xz compressed tarballs.Adding this as an Onionoo component because that's who handles importing dependencies for metrics-lib.
This ticket adds support for .xz tarball archives during import.
**Trac**:
**Username**: leeroyAdding this as an Onionoo component because that's who handles importing dependencies for metrics-lib.
This ticket adds support for .xz tarball archives during import.
**Trac**:
**Username**: leeroyhttps://gitlab.torproject.org/legacy/trac/-/issues/16540Close the the updater's shared HttpUrlConnection socket if an exception occurs.2020-06-13T18:00:49ZTracClose the the updater's shared HttpUrlConnection socket if an exception occurs.When Onionoo's updater uses a HttpUrlConnection it doesn't attempt to close the socket after an exception. An exception may occur anytime during or after the first fetchRemoteDirectory of DescriptorSource. The problem is this can leave t...When Onionoo's updater uses a HttpUrlConnection it doesn't attempt to close the socket after an exception. An exception may occur anytime during or after the first fetchRemoteDirectory of DescriptorSource. The problem is this can leave the HttpUrlConnection's shared underlying network connection in a state which blocks further requests. This has the effect of preventing reads as early as during the first fetchRemoteFiles. Onionoo's updater will then block until the problem HttpUrlConnection is handled.
To reproduce. Close the connection remotely during fetchRemoteDirectory.
**Trac**:
**Username**: leeroyKarsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/16401Fail-fast if file access permissions for out and status prevent an update2020-06-13T18:00:45ZTracFail-fast if file access permissions for out and status prevent an updateRegular backups of the _out_ and _status_ folders for an Onionoo server is encouraged. When running as a separate user it wouldn't be uncommon to have the archives owned by another user. Onionoo's updater doesn't check the access permiss...Regular backups of the _out_ and _status_ folders for an Onionoo server is encouraged. When running as a separate user it wouldn't be uncommon to have the archives owned by another user. Onionoo's updater doesn't check the access permissions for _out_ and _status_ until after rebuilding the folder _in_, and it basically fills the logs with entries for every file it failed to access. So if you didn't recursively set access permissions that's a lot of log entries before the updater finally stops.
If the Onionoo updater were to check the permissions early and fail-fast it would prevent this behavior.
**Trac**:
**Username**: leeroyhttps://gitlab.torproject.org/legacy/trac/-/issues/16371Use soft links to dependencies instead of hard links2020-06-13T18:00:44ZTracUse soft links to dependencies instead of hard linksOne thing I noticed when setting up a test Onionoo server was the use of hard links in build.xml. An improvement here would be to instead use the soft links created during installation. I don't imagine this would break anything since I'm...One thing I noticed when setting up a test Onionoo server was the use of hard links in build.xml. An improvement here would be to instead use the soft links created during installation. I don't imagine this would break anything since I'm using newer versions of many of those packages without any problems.
**Trac**:
**Username**: leeroyhttps://gitlab.torproject.org/legacy/trac/-/issues/16767Javadoc doesn't include any of the documentation.2020-06-13T17:56:50ZTracJavadoc doesn't include any of the documentation.When generating documentation using javadoc the result doesn't include any of the code documentation. The cause is some minor problems with the documentation style. This can be done using the build file to improve the generated documenta...When generating documentation using javadoc the result doesn't include any of the code documentation. The cause is some minor problems with the documentation style. This can be done using the build file to improve the generated documentation with an ant task. Otherwise it requires changing all of the non-impl to at least generate *some* documentation.
I attach a sample of the fixed documentation. With slight differences due to the origin.
**Trac**:
**Username**: leeroyKarsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/16614Improve pipelining during data-read, data-parse, parsed-write.2020-06-13T17:56:49ZTracImprove pipelining during data-read, data-parse, parsed-write.Currently metrics-lib isn't using system resources effectively. The steps data-read+data-parse block waiting for the parsed result. The result is then handed over to a queue for parsed-write. This happens in a loop until all data is read...Currently metrics-lib isn't using system resources effectively. The steps data-read+data-parse block waiting for the parsed result. The result is then handed over to a queue for parsed-write. This happens in a loop until all data is read. These three steps form a single-core bound execution.
This ticket documents the effort to improve the way these steps are performed.
**Trac**:
**Username**: leeroyKarsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/16557Minor buffering improvements reading descriptors.2020-06-13T17:56:48ZTracMinor buffering improvements reading descriptors.The reading of descriptors is usually done from a BufferedInputStream wrapping the source. The improvement is to change the read from 1k to 8k. This coincides with the stream's internal buffer size. The alternative is 1k reads from an ot...The reading of descriptors is usually done from a BufferedInputStream wrapping the source. The improvement is to change the read from 1k to 8k. This coincides with the stream's internal buffer size. The alternative is 1k reads from an otherwise 8k aligned buffer.
This patch also wraps the writing of disk files in a BufferedOutputStream.
**Trac**:
**Username**: leeroyKarsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/16308Attempts to resolve local hostname using tor2020-06-13T16:09:32ZTracAttempts to resolve local hostname using torWhen using torsocks 2.1.0 built from tarball, torsocks attempts to resolve the local machine's hostname using tor.
To reproduce: clone a git repository using torsocks
Result: clone is successful, but produces an error in torsocks after...When using torsocks 2.1.0 built from tarball, torsocks attempts to resolve the local machine's hostname using tor.
To reproduce: clone a git repository using torsocks
Result: clone is successful, but produces an error in torsocks after an attempt to resolve the machine's hostname:42 using tor.
`ERROR torsocks[pid]: Unable to resolve. Status reply: 4 (in socks5_recv_resolve_reply() at socks5.c:666)`
**Trac**:
**Username**: leeroyDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org