Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T17:48:37Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33294Update existing Nagios plugin for OnionPerf monitoring2020-06-13T17:48:37ZAna CusturaUpdate existing Nagios plugin for OnionPerf monitoringThe plugin should alert if any of the following are true:
- The web server does not exist or does not have sane responses
- There are excessive failures in the logs
- The onion services used for measurement are not reachable
In additio...The plugin should alert if any of the following are true:
- The web server does not exist or does not have sane responses
- There are excessive failures in the logs
- The onion services used for measurement are not reachable
In addition, the plugin should use stem where appropriate.https://gitlab.torproject.org/legacy/trac/-/issues/33296Add Prometheus Node Exporter checks to Nagios2020-06-13T17:48:37ZAna CusturaAdd Prometheus Node Exporter checks to NagiosIn addition to standard CPU/RAM/Disk monitoring this could also check tgen processes.In addition to standard CPU/RAM/Disk monitoring this could also check tgen processes.https://gitlab.torproject.org/legacy/trac/-/issues/33297Tune Onionperf Nagios alerts2020-06-13T17:48:38ZAna CusturaTune Onionperf Nagios alertsEnsure we have sensible warning and critical levels, and that we rate limit notifications.Ensure we have sensible warning and critical levels, and that we rate limit notifications.https://gitlab.torproject.org/legacy/trac/-/issues/33305Determine requirements for exit scanner machine2020-06-13T17:54:34ZirlDetermine requirements for exit scanner machineWe need to ask for a machine from TPA to run the new exit scanner, but going to write it I realise I don't know what the requirements are of that machine. We know that a t2.micro is too small but a t2.small is OK for the current network ...We need to ask for a machine from TPA to run the new exit scanner, but going to write it I realise I don't know what the requirements are of that machine. We know that a t2.micro is too small but a t2.small is OK for the current network size. We should think though about planned network growth and if we should go for something we can grow in to instead of finding ourselves OOM and surprised at a bad time.https://gitlab.torproject.org/legacy/trac/-/issues/33309Add support for custom clone URL and branch selection for Onionperf2020-06-13T17:48:38ZAna CusturaAdd support for custom clone URL and branch selection for OnionperfTo support OP experiments we should allow branches/tags and alternative URLs to be specified in variables when deploying Onionperf instances.To support OP experiments we should allow branches/tags and alternative URLs to be specified in variables when deploying Onionperf instances.https://gitlab.torproject.org/legacy/trac/-/issues/33310Add support for custom clone URL and branch selection for Tor2020-06-13T17:48:38ZAna CusturaAdd support for custom clone URL and branch selection for TorTo support OP experiments we should allow branches/tags and alternative git clone URLs to be specified for Tor when deploying Onionperf instances. To enable this Tor should also be built from sources.To support OP experiments we should allow branches/tags and alternative git clone URLs to be specified for Tor when deploying Onionperf instances. To enable this Tor should also be built from sources.https://gitlab.torproject.org/legacy/trac/-/issues/33311Add custom torrc files to OP Ansible deployment2020-06-13T17:48:39ZAna CusturaAdd custom torrc files to OP Ansible deploymentAdd support for specifying custom torrc files (using templates/variables) to be used by Onionperf Ansible deployment.Add support for specifying custom torrc files (using templates/variables) to be used by Onionperf Ansible deployment.https://gitlab.torproject.org/legacy/trac/-/issues/33312Document how to add additional hosts to Nagios2020-06-13T17:48:39ZAna CusturaDocument how to add additional hosts to Nagioshttps://gitlab.torproject.org/legacy/trac/-/issues/33313Documentation on metrics-cloud for Nagios and Onionperf2020-06-13T17:48:40ZAna CusturaDocumentation on metrics-cloud for Nagios and OnionperfDocumentation needs to be produced on how to use cloudformation and ansible to bring up OP and Nagios instances, and how to tune deployment parameters.Documentation needs to be produced on how to use cloudformation and ansible to bring up OP and Nagios instances, and how to tune deployment parameters.https://gitlab.torproject.org/legacy/trac/-/issues/33318O1.1 Improve monitoring: We will produce a Nagios plugin for monitoring Onion...2020-06-13T18:04:10ZGabagaba@torproject.orgO1.1 Improve monitoring: We will produce a Nagios plugin for monitoring OnionPerf instances to ensure that they are operating correctly.Nagios is an open source software that monitors systems, networks, and infrastructure. We need such a monitoring tool because when we deploy OnionPerf instances to run experiments, they typically run for days or weeks at a time. These ex...Nagios is an open source software that monitors systems, networks, and infrastructure. We need such a monitoring tool because when we deploy OnionPerf instances to run experiments, they typically run for days or weeks at a time. These experiments often require code changes to underlying Tor processes or to network-wide parameters, which makes them susceptible to breakage. When the instances break, our experiments are disrupted and thus ineffective. It’s cumbersome to manually check these instances for breakage or errors. Having robust monitoring tools makes it possible for our small team to run experiments efficiently.https://gitlab.torproject.org/legacy/trac/-/issues/33319O1.2 Improve ease of deployment and maintenance: We will produce Ansible task...2020-06-13T18:04:11ZGabagaba@torproject.orgO1.2 Improve ease of deployment and maintenance: We will produce Ansible tasks for deploying and managing deployments of OnionPerf instances, which also allow for performing upgrades and custom configuration changes.Ansible is an open source software tool that automates and improves configuration management and application deployment. Without tools like Ansible, setting up or updating OnionPerf experiments is a fully manually process, which can be e...Ansible is an open source software tool that automates and improves configuration management and application deployment. Without tools like Ansible, setting up or updating OnionPerf experiments is a fully manually process, which can be error-prone and cumbersome. When establishing multiple OnionPerf instances, automating the setup or update process with Ansible makes it possible to run these experiments efficiently and reproducibly. In this task we will also make software changes that solve an existing disk space issue on OnionPerf instances. Right now, an OnionPerf instance keeps writing logs to its disk until that disk gets full. To solve this problem, we will sync logs to another location and delete them after a short while to keep storage requirements for OnionPerf instances constant. Ideally, we would make these logs publicly available.https://gitlab.torproject.org/legacy/trac/-/issues/33320Objective 1: Make operational improvements to existing OnionPerf deployments ...2020-06-13T18:04:11ZGabagaba@torproject.orgObjective 1: Make operational improvements to existing OnionPerf deployments and make it easier to deploy new OnionPerf instancesUnder sponsor 59's project we will improve on how OnionPerf is being deployed.
More info: https://trac.torproject.org/projects/tor/wiki/org/sponsors/Sponsor59Under sponsor 59's project we will improve on how OnionPerf is being deployed.
More info: https://trac.torproject.org/projects/tor/wiki/org/sponsors/Sponsor59https://gitlab.torproject.org/legacy/trac/-/issues/33321O1.3 Make OnionPerf more accessible to researchers and developers2020-06-13T18:04:13ZGabagaba@torproject.orgO1.3 Make OnionPerf more accessible to researchers and developersIn order to gather sufficient network measurements and conduct a variety of experiments with multiple instances of OnionPerf, it must be straightforward and easy for researchers and developers outside of the Metrics team to spin up and m...In order to gather sufficient network measurements and conduct a variety of experiments with multiple instances of OnionPerf, it must be straightforward and easy for researchers and developers outside of the Metrics team to spin up and monitor their own OnionPerfs with different configurations. With the ability for more people to run more OnionPerf instances, we can perform more experiments from more vantage points. These experiments will not happen during this project, but are only possible with these improvements to OnionPerf.https://gitlab.torproject.org/legacy/trac/-/issues/33322Objective 2: Expand the kinds of measurements OnionPerf can take by making im...2020-06-13T18:04:14ZGabagaba@torproject.orgObjective 2: Expand the kinds of measurements OnionPerf can take by making improvements to its codebase.Under sponsor 59's project we will expand kind of measurements for OnionPerf.
More info: https://trac.torproject.org/projects/tor/wiki/org/sponsors/Sponsor59Under sponsor 59's project we will expand kind of measurements for OnionPerf.
More info: https://trac.torproject.org/projects/tor/wiki/org/sponsors/Sponsor59https://gitlab.torproject.org/legacy/trac/-/issues/33323O2.1 Add instance metadata: We need a way to distinguish our current four lon...2020-06-13T18:15:33ZGabagaba@torproject.orgO2.1 Add instance metadata: We need a way to distinguish our current four long-term OnionPerf measurements that are automatically published to the Metrics portal from short-term experimental measurements.In this task, we will add instance metadata to OnionPerf’s results in order to differentiate each experiment; we will store that data along with the actual measurement data in a separate, single archive. Without this task, we will be una...In this task, we will add instance metadata to OnionPerf’s results in order to differentiate each experiment; we will store that data along with the actual measurement data in a separate, single archive. Without this task, we will be unable to distinguish the new experiments from the currently running OnionPerf instances, which makes the data collected unusable.https://gitlab.torproject.org/legacy/trac/-/issues/33324O2.2 Develop at least one new OnionPerf model: An OnionPerf model defines the...2020-06-13T18:04:15ZGabagaba@torproject.orgO2.2 Develop at least one new OnionPerf model: An OnionPerf model defines the pattern of traffic that is generated by the instances for conducting a measurement.For example, a bulk download model can be used to measure time to first byte and time to last byte simulating the download of a large file. In contrast, a ping/echo service model would be used to learn the round-trip time from a client s...For example, a bulk download model can be used to measure time to first byte and time to last byte simulating the download of a large file. In contrast, a ping/echo service model would be used to learn the round-trip time from a client sending a ping to receiving a pong back from a server, which more closely models a real-time chat application. These models allow us to evaluate distinct circumstances and collect distinct metrics, all of which are currently unavailable with the existing OnionPerf model. We will evaluate new OnionPerf models that will allow us to measure different network workloads and deploy at least one instance of these permanently. Deploying a new OnionPerf model allows us to gain new insight into the Tor network by taking measurements that are currently unavailable.https://gitlab.torproject.org/legacy/trac/-/issues/33325O2.3 Implement static guard node support for OnionPerf.2020-06-13T18:04:15ZGabagaba@torproject.orgO2.3 Implement static guard node support for OnionPerf.Tor clients generally make three-hop circuits (that is, paths that go through three relays). The first position in the path called the guard node and is always chosen as the first hop for a fixed period of time. Using static guard nodes ...Tor clients generally make three-hop circuits (that is, paths that go through three relays). The first position in the path called the guard node and is always chosen as the first hop for a fixed period of time. Using static guard nodes help protect against a certain kind of anonymity-breaking attack. The long-running OnionPerf instances that are currently deployed do not implement this mitigation because choosing a static guard at setup time would heavily influence their measured performance. Instead, they’re configured not to choose a guard for each measurement. We want to be able to measure the effects of good, bad, or average guards and compare the results, which is not possible without the opportunity to select a static guard node for an OnionPerf instance. Implementing the option to use a static guard in future OnionPerf instances will allow us to measure Tor performance closer to how clients experience it.https://gitlab.torproject.org/legacy/trac/-/issues/33326Objective 3: Make improvements to the way we analyze performance metrics.2020-06-13T18:04:16ZGabagaba@torproject.orgObjective 3: Make improvements to the way we analyze performance metrics.Under sponsor 59's project we work on a dev tool to help people to analyze performance metrics.
More info: https://trac.torproject.org/projects/tor/wiki/org/sponsors/Sponsor59Under sponsor 59's project we work on a dev tool to help people to analyze performance metrics.
More info: https://trac.torproject.org/projects/tor/wiki/org/sponsors/Sponsor59https://gitlab.torproject.org/legacy/trac/-/issues/33327O3.1 Develop developer-facing tooling to quickly graph baseline performance m...2020-06-13T18:04:17ZGabagaba@torproject.orgO3.1 Develop developer-facing tooling to quickly graph baseline performance metrics.In order for developers to evaluate performance metrics as we make network improvements, we will create developer tools that allow us to produce CDFs from snapshots of time for these OnionPerf metrics for periods of time that live networ...In order for developers to evaluate performance metrics as we make network improvements, we will create developer tools that allow us to produce CDFs from snapshots of time for these OnionPerf metrics for periods of time that live network experiments are running. These graphing tools will also work with OnionPerfs that are attached to the Tor network simulator Shadow,1 allowing us to compare the live network to the simulator.https://gitlab.torproject.org/legacy/trac/-/issues/33328O3.2 Include additional OnionPerf filters.2020-06-13T18:04:17ZGabagaba@torproject.orgO3.2 Include additional OnionPerf filters.We will add the ability to filter out arbitrary relays from arbitrary time periods of historical OnionPerf data and compare the performance metrics to the baseline for that period as CDF graphs.We will add the ability to filter out arbitrary relays from arbitrary time periods of historical OnionPerf data and compare the performance metrics to the baseline for that period as CDF graphs.https://gitlab.torproject.org/legacy/trac/-/issues/33329Set Lets Encrypt hostname dynamically using ansible facts2020-06-13T17:48:40ZirlSet Lets Encrypt hostname dynamically using ansible factsIt's hardcoded in the role right now, which is not optimal.It's hardcoded in the role right now, which is not optimal.https://gitlab.torproject.org/legacy/trac/-/issues/33335Make it possible to select every existing flag in "Advanced Search"2020-06-13T18:08:29ZTracMake it possible to select every existing flag in "Advanced Search"Currently the dropdown-list in "Advanced Search" only provide a limited amount of flags to search for.
For example missing are:
- BadExit
- HSDir
- StaleDesc
- V2Dir
- Valid
They can be searched in the "Simple Search" but are not in th...Currently the dropdown-list in "Advanced Search" only provide a limited amount of flags to search for.
For example missing are:
- BadExit
- HSDir
- StaleDesc
- V2Dir
- Valid
They can be searched in the "Simple Search" but are not in the dropdown-list of "Aggregated Search".
Additionally it might be nice to have the option to search for the "Additional Flags" as well.
So far i cant find any way to do this.
**Trac**:
**Username**: computer_freakhttps://gitlab.torproject.org/legacy/trac/-/issues/33337Release Onionoo 7.0-1.24.02020-06-13T18:03:03ZKarsten LoesingRelease Onionoo 7.0-1.24.0I'm going to put out Onionoo 7.0-1.24.0 soon to get the Onionoo side of #33008 deployed.I'm going to put out Onionoo 7.0-1.24.0 soon to get the Onionoo side of #33008 deployed.https://gitlab.torproject.org/legacy/trac/-/issues/33360IntegerDistribution breaks when given negative values2020-06-13T18:03:04ZKarsten LoesingIntegerDistribution breaks when given negative valuesAs found in #27981, our unit tests fail when being run in 1990.
The reason is that we're using a hard-coded time for sending the request (2013-04-24 12:22:22) and the current system time for determining when we handled the request. We c...As found in #27981, our unit tests fail when being run in 1990.
The reason is that we're using a hard-coded time for sending the request (2013-04-24 12:22:22) and the current system time for determining when we handled the request. We compute the difference of the two timestamps as the time needed for handling the request. But `IntegerDistribution` does not accept negative values.
That's a bug. It should either reject negative values in its `addLong` method, or it should store them and include them in the result. I'd prefer the second variant, even though we're not using it for negative values under normal circumstances.
Not blocking the upcoming 8.0 protocol update.https://gitlab.torproject.org/legacy/trac/-/issues/33382OnionPerf service file should be just a file2020-06-13T17:48:41ZirlOnionPerf service file should be just a fileI noticed that the systemd service file for the OnionPerf service doesn't actually contain any variables, so we can just copy this instead of rendering it with Jinja.I noticed that the systemd service file for the OnionPerf service doesn't actually contain any variables, so we can just copy this instead of rendering it with Jinja.https://gitlab.torproject.org/legacy/trac/-/issues/33391Add new metadata fields and definitions2020-06-13T18:15:33ZAna CusturaAdd new metadata fields and definitionsDefine the instance metadata fields to help us differentiate experimental measurements.Define the instance metadata fields to help us differentiate experimental measurements.https://gitlab.torproject.org/legacy/trac/-/issues/33392Add new metadata fields to json output2020-06-13T18:04:19ZAna CusturaAdd new metadata fields to json outputAdd new metadata fields for experimental measurements to the onionperf json output.Add new metadata fields for experimental measurements to the onionperf json output.https://gitlab.torproject.org/legacy/trac/-/issues/33393Add new metadata fields to tpf output.2020-06-13T18:15:33ZAna CusturaAdd new metadata fields to tpf output.Add new metadata fields for experimental measurements to the Onionperf tpf output.Add new metadata fields for experimental measurements to the Onionperf tpf output.https://gitlab.torproject.org/legacy/trac/-/issues/33394Automatically build Onionperf documentation from Git2020-06-13T17:48:41ZAna CusturaAutomatically build Onionperf documentation from GitThe documentation for Onionperf (https://onionperf.torproject.org/) should be built automatically from the sources in git.The documentation for Onionperf (https://onionperf.torproject.org/) should be built automatically from the sources in git.https://gitlab.torproject.org/legacy/trac/-/issues/33395Add option to replace the client and server torrc files2020-06-13T17:48:42ZAna CusturaAdd option to replace the client and server torrc filesAdd support for replacing the client and server torrc files on the command line when deploying an Onionperf measurement.Add support for replacing the client and server torrc files on the command line when deploying an Onionperf measurement.https://gitlab.torproject.org/legacy/trac/-/issues/33396Automatically compress Onionperf logs2020-06-13T18:04:20ZAna CusturaAutomatically compress Onionperf logsAutomatically compress Onionperf logs to save space. This could be done as part of the log rotation at midnight or separately.Automatically compress Onionperf logs to save space. This could be done as part of the log rotation at midnight or separately.https://gitlab.torproject.org/legacy/trac/-/issues/33397Update metrics-web to only plot "official" data2020-06-13T18:15:32ZAna CusturaUpdate metrics-web to only plot "official" dataUpdate metrics-web to only plot "official" data based on new metadata field for existing graphs. This depends on implementations described in #33323 and #33391 =>#33393Update metrics-web to only plot "official" data based on new metadata field for existing graphs. This depends on implementations described in #33323 and #33391 =>#33393https://gitlab.torproject.org/legacy/trac/-/issues/33418Remove tgen submodule from Onionperf codebase2020-06-13T18:04:21ZAna CusturaRemove tgen submodule from Onionperf codebaseWe have a leftover tgen direcotry as part of the Onionperf codebase. This is an artefact from before tgen was moved to shadow, and should be removed since we don't use it in any of the ansible/cloud deployments.We have a leftover tgen direcotry as part of the Onionperf codebase. This is an artefact from before tgen was moved to shadow, and should be removed since we don't use it in any of the ansible/cloud deployments.https://gitlab.torproject.org/legacy/trac/-/issues/33419Add analysis to support static guard measurements2020-06-13T18:04:22ZAna CusturaAdd analysis to support static guard measurementshttps://gitlab.torproject.org/legacy/trac/-/issues/33420Add CBT events to Onionperf result files2020-06-13T18:04:23ZAna CusturaAdd CBT events to Onionperf result filesAs I understand this, the results should record whether the CBT was set at the time of measurement. This could just be a CBT_SET True/False field in the tpf results file. The CBT resets in certain conditions, and this should be reflected...As I understand this, the results should record whether the CBT was set at the time of measurement. This could just be a CBT_SET True/False field in the tpf results file. The CBT resets in certain conditions, and this should be reflected in the results. The events should be parsed from the tor logs.
We should check with Mike if this meets the requirements.https://gitlab.torproject.org/legacy/trac/-/issues/33422Include more events about CBT in results2020-06-13T18:04:24ZAna CusturaInclude more events about CBT in resultshttps://gitlab.torproject.org/legacy/trac/-/issues/33424Ensure ExoneraTorDatabaseImporter closes all BufferedReader/Writer objects2020-06-13T17:55:22ZTracEnsure ExoneraTorDatabaseImporter closes all BufferedReader/Writer objectsIf Exceptions occur in ExoneraTorDatabaseImporter's readImportHistoryToMemory() and writeImportHistoryToDisk(), the BufferedReader/Writer object they each use may not be closed.
A proposed solution can be seen at
```
git@gitlab.com:743...If Exceptions occur in ExoneraTorDatabaseImporter's readImportHistoryToMemory() and writeImportHistoryToDisk(), the BufferedReader/Writer object they each use may not be closed.
A proposed solution can be seen at
```
git@gitlab.com:743zpnpGUq27GgR/exonerator.git
in the branch "close-open-bufferedreaders".
```
**Trac**:
**Username**: efgyirfe784https://gitlab.torproject.org/legacy/trac/-/issues/33433Add error handling for older stem versions2020-06-13T18:04:25ZAna CusturaAdd error handling for older stem versionsCurrently OP fails if the python-stem version required for enabling v3 services is not found. Instead, it should warn the user and either continue with v2 services only, or exit and ask the user to manually exclude v3 services on the com...Currently OP fails if the python-stem version required for enabling v3 services is not found. Instead, it should warn the user and either continue with v2 services only, or exit and ask the user to manually exclude v3 services on the command line.https://gitlab.torproject.org/legacy/trac/-/issues/33438OnionPerf: Scalability, Performance, Establishing Baseline Metrics2020-06-13T18:04:27ZGabagaba@torproject.orgOnionPerf: Scalability, Performance, Establishing Baseline MetricsIn this project, the Tor Metrics and Tor Network teams will work together to improve OnionPerf so that it is a useful tool for all developers and researchers. As a result of this project, we will be able to conduct more meaningful experi...In this project, the Tor Metrics and Tor Network teams will work together to improve OnionPerf so that it is a useful tool for all developers and researchers. As a result of this project, we will be able to conduct more meaningful experiments on the Tor network. Enhancing OnionPerf is a critical foundational step in the work to scale the Tor network.
The goals of this project are to:
* Make operational improvements to existing OnionPerf deployments and make it easier to deploy new OnionPerf instances;
* Expand the kinds of measurements OnionPerf can take by making improvements to its codebase; and
* Make improvements to the way we analyze performance metrics.
Teams involved:
network health team
network team
metrics team
research director
More information in https://trac.torproject.org/projects/tor/wiki/org/sponsors/Sponsor59https://gitlab.torproject.org/legacy/trac/-/issues/33444Minor code cleanup2020-06-13T17:55:23ZTracMinor code cleanupMinor code cleanup including:
1. display meaningful warning if lock file cannot be deleted
2. use faster method calls
3. remove unused method parameters
These changes can be viewed at https://gitlab.com/743zpnpGUq27GgR/exonerator/-/comm...Minor code cleanup including:
1. display meaningful warning if lock file cannot be deleted
2. use faster method calls
3. remove unused method parameters
These changes can be viewed at https://gitlab.com/743zpnpGUq27GgR/exonerator/-/commits/small-cleanup
or cloned via
https://gitlab.com/743zpnpGUq27GgR/exonerator.git
using branch 'small-cleanup'
Feel free to use whatever makes sense and ignore the rest. Thanks! Josh
**Trac**:
**Username**: efgyirfe784https://gitlab.torproject.org/legacy/trac/-/issues/33467Add an ant task for updating the fallback directory list2020-06-13T18:15:33ZirlAdd an ant task for updating the fallback directory listThe python script fell out of the repository, and adding an ant task should help us get these updates out more quickly.The python script fell out of the repository, and adding an ant task should help us get these updates out more quickly.https://gitlab.torproject.org/legacy/trac/-/issues/33471Restart exit scanner service on changes that would need it2020-06-13T17:48:42ZirlRestart exit scanner service on changes that would need itNeeds to split the systemd task out to a handlerNeeds to split the systemd task out to a handlerhttps://gitlab.torproject.org/legacy/trac/-/issues/33475Remove excessive logging from exitscan py2020-06-13T17:48:43ZirlRemove excessive logging from exitscan pyhttps://gitlab.torproject.org/legacy/trac/-/issues/33493Encourage operators to ignore bridge flags on relay search2020-06-13T18:08:30ZteorEncourage operators to ignore bridge flags on relay searchThe bridge flags on relay search confuse some bridge operators:
https://lists.torproject.org/pipermail/tor-relays/2020-February/018188.html
Can we grey them out, or otherwise indicate that they're not used by clients?
Can we change the...The bridge flags on relay search confuse some bridge operators:
https://lists.torproject.org/pipermail/tor-relays/2020-February/018188.html
Can we grey them out, or otherwise indicate that they're not used by clients?
Can we change the mouseover help message on the "flags" heading for bridges?
Can we also change the definition of Flags, and the Bridge Descriptors definition, so they talk about bridge flags?https://gitlab.torproject.org/legacy/trac/-/issues/33497Translation on metrics.torproject.org2020-06-13T18:15:33ZTracTranslation on metrics.torproject.orgI think it is necessary to have different translations of metrics.torproject.org.
There is an old closed ticket https://trac.torproject.org/projects/tor/ticket/20867 but there are still no translations except from https://exonerator.torp...I think it is necessary to have different translations of metrics.torproject.org.
There is an old closed ticket https://trac.torproject.org/projects/tor/ticket/20867 but there are still no translations except from https://exonerator.torproject.org/.
If we could take the content to the 'Tor Project Web' on transifex there would be volunteers for many languages which would translate it.
It's also not that much so i think one could translate the whole content in one day.
**Trac**:
**Username**: kucehttps://gitlab.torproject.org/legacy/trac/-/issues/33507Deploy new exit scanner and check combo on check-01 using metrics-cloud2020-06-13T17:54:36ZirlDeploy new exit scanner and check combo on check-01 using metrics-cloudThis is not the same project as #29650, which was a more ambitious attempt at fixing some of the shortcomings of the current setup. Instead, this project aims to keep the service running with minimal changes until we have more time/fundi...This is not the same project as #29650, which was a more ambitious attempt at fixing some of the shortcomings of the current setup. Instead, this project aims to keep the service running with minimal changes until we have more time/funding to take on the increased level of work that would be involved for the more ambitious project. For avoidance of doubt, I still believe that #29650 is going to be needed soon and is entirely valid work for the Metrics Team to do.
This ticket blocks #29399 which is of a high priority to the sysadmin team.
The parts of the existing service that can be reused will be reused, which is really just the check application. The check application is written in Go and uses local filesystem data sources (which have to be updated by a tor client). It has an embedded web server and we reverse proxy this via Apache.
The exit scanner and DNS server were written in Haskell. We can't maintain this so instead we are using exitmap wrapped in a Python script to produce exit lists compatible with the existing format (i.e. we're not going to a new format yet). A second python script runs by cron job to write out a BIND compatible zone file, which is served by bind.
The exact split between Metrics Team and Sysadmin Team responsibilities are details in the ops doc for this service (which is yet to be written).https://gitlab.torproject.org/legacy/trac/-/issues/33509Confirm that CollecTor will be happy consuming data from the new check service2020-06-13T17:52:29ZirlConfirm that CollecTor will be happy consuming data from the new check serviceThe exit addresses are available, for testing, at:
https://check-01.torproject.org/exit-addresses
This will not have a valid TLS cert though, you can also add check.tpo to /etc/hosts for that IP address and it will then have a valid cert.The exit addresses are available, for testing, at:
https://check-01.torproject.org/exit-addresses
This will not have a valid TLS cert though, you can also add check.tpo to /etc/hosts for that IP address and it will then have a valid cert.https://gitlab.torproject.org/legacy/trac/-/issues/33634Confusing JavaScript error when entering email address in Relay Search2020-06-13T18:08:30ZGeorg KoppenConfusing JavaScript error when entering email address in Relay SearchIf I enter a relay fingerprint on Relay Search I get all the info about the respective relay as a result, great. Now if I enter an email address in Relay Search I get a confusing JavaScript message:
```
JavaScript Error!
There is a prob...If I enter a relay fingerprint on Relay Search I get all the info about the respective relay as a result, great. Now if I enter an email address in Relay Search I get a confusing JavaScript message:
```
JavaScript Error!
There is a problem with your javascript environment, you may have noscript enabled on the remote onionoo backend. Try temporarily allowing noscript to connect to the backend IP address. If the problem persits consult the bugtracker.
```
Note, I did not change any of my JavaScript settings between entering the fingerprint and the email address: I have it enabled in both scenarios.
Now, ideally when entering the email address (without the "contact:" prefix which makes the whole thing work) that just give me the relay/a list of relays with the respective contact info, just like entering the plain fingerprint does.
I am fine if that's asking too much. :) But then at least the wrong JavaScript error should get replaced with something more meaningful.https://gitlab.torproject.org/legacy/trac/-/issues/33655Make all server-side modules independent of server locale or time zone2020-06-13T18:10:36ZKarsten LoesingMake all server-side modules independent of server locale or time zoneIn #24532 we made metrics-web's daily updater runs independent of server locale and time zone. We also said that if the fix looks good, we should apply the same fix to all other `main` methods in our various code bases. This includes:
`...In #24532 we made metrics-web's daily updater runs independent of server locale and time zone. We also said that if the fix looks good, we should apply the same fix to all other `main` methods in our various code bases. This includes:
```
org.torproject.metrics.collector.Main
org.torproject.metrics.exonerator.ExoneraTorDatabaseImporter
org.torproject.metrics.exonerator.ServerMain
org.torproject.metrics.onionoo.cron.Main
org.torproject.metrics.onionoo.server.ServerMain
org.torproject.metrics.web.ServerMain <- already done in #24532
org.torproject.metrics.web.UpdateNews
```
This ticket tracks progress of making the same changes in the remaining 6 places. We could create child tickets if we wanted, but maybe that's overkill.https://gitlab.torproject.org/legacy/trac/-/issues/33663Check checktest.py related errors shown by our network-health scanners2020-11-13T13:45:10ZGeorg KoppenCheck checktest.py related errors shown by our network-health scannersI often see something like
```
2020-03-17 21:03:56,973 modules.checktest [ERROR] Check thinks <https://metrics.torproject.org/rs.html#details/296B2178FD742AB35AB20C9ADF04D5DFD3D407EB> isn't Tor. Desc addr is 206.55.74.0 and check addr i...I often see something like
```
2020-03-17 21:03:56,973 modules.checktest [ERROR] Check thinks <https://metrics.torproject.org/rs.html#details/296B2178FD742AB35AB20C9ADF04D5DFD3D407EB> isn't Tor. Desc addr is 206.55.74.0 and check addr is 206.55.74.0.
```
. We should figure out a) what's up with that and b) whether we actually still need that test to be running.https://gitlab.torproject.org/legacy/trac/-/issues/33713Use Travis CI for cfn-lint2020-06-13T17:48:43ZirlUse Travis CI for cfn-lintWe are no longer using the GitLab CI service, but we do still need CI, so let's move it to Travis CI and use GitHub integration for this.We are no longer using the GitLab CI service, but we do still need CI, so let's move it to Travis CI and use GitHub integration for this.https://gitlab.torproject.org/legacy/trac/-/issues/33714Use Travis CI for ansible-lint2020-06-13T17:48:43ZirlUse Travis CI for ansible-lintWe are no longer using the GitLab CI service, but we do still need CI, so let's move it to Travis CI and use GitHub integration for this.We are no longer using the GitLab CI service, but we do still need CI, so let's move it to Travis CI and use GitHub integration for this.https://gitlab.torproject.org/legacy/trac/-/issues/33718Check check.torproject.org in Nagios2020-06-13T17:48:45ZirlCheck check.torproject.org in Nagioshttps://gitlab.torproject.org/legacy/trac/-/issues/33719Check DNSEL in Nagios2020-06-13T17:48:46ZirlCheck DNSEL in Nagioshttps://gitlab.torproject.org/legacy/trac/-/issues/33720Check exit scanner in Nagios2020-06-13T17:48:46ZirlCheck exit scanner in Nagioshttps://gitlab.torproject.org/legacy/trac/-/issues/33754I discovered a Tor node using TCP port 9999 (service: "distinct" / "abyss"). ...2020-06-13T17:54:39ZTracI discovered a Tor node using TCP port 9999 (service: "distinct" / "abyss"). Is this normal?I recently ran Netstat, a program within Network Utility (I did this while using Tor Browser). When the option "Display the state of all current socket connections" was selected, two Tor IP addresses appeared in the "Foreign address" col...I recently ran Netstat, a program within Network Utility (I did this while using Tor Browser). When the option "Display the state of all current socket connections" was selected, two Tor IP addresses appeared in the "Foreign address" column. One IP address is the Tor entry node I am currently using, and the other IP address is an IP address using TCP port 9999 -- the "distinct" service, also known as "abyss". What I'm wondering is, is it normal for a Tor node to use TCP port 9999 ("distinct") while using Tor? Is this a sign of malicious activity?
I did a terminal command to see if I could find out more information about the IP address using port 9999, and it said it is using tor.real.
In addition, the mysterious Tor IP address appears to be using the following ports on my computer: 22, 80, 110, 143, 443, 993, 995, 9998 and 9999.
The reason I know the mysterious IP address is a Tor IP address is because Terminal told me it is using tor.real, and Tor Exonerator confirmed that it is a Tor IP address.
**Trac**:
**Username**: Tor235https://gitlab.torproject.org/legacy/trac/-/issues/33887Release metrics-lib 2.11.02020-06-13T17:58:26ZKarsten LoesingRelease metrics-lib 2.11.0I'm going to put out a new metrics-lib release now.I'm going to put out a new metrics-lib release now.https://gitlab.torproject.org/legacy/trac/-/issues/33888Release ExoneraTor 4.4.02020-06-13T17:55:23ZKarsten LoesingRelease ExoneraTor 4.4.0I'm going to put out a new ExoneraTor release today.I'm going to put out a new ExoneraTor release today.https://gitlab.torproject.org/legacy/trac/-/issues/33933Bandwidth distribution graph has "0 Gbit/s" for all y axis labels2020-06-13T18:15:34ZRoger DingledineBandwidth distribution graph has "0 Gbit/s" for all y axis labelsSee e.g. https://metrics.torproject.org/advbwdist-perc.html?start=2015-01-19&end=2020-04-18&p=50
This is likely the same type of rounding bug as #33066.
(I wonder if there are other graphs that have this issue, too?)See e.g. https://metrics.torproject.org/advbwdist-perc.html?start=2015-01-19&end=2020-04-18&p=50
This is likely the same type of rounding bug as #33066.
(I wonder if there are other graphs that have this issue, too?)https://gitlab.torproject.org/legacy/trac/-/issues/34018Remove op-ab from CollecTor configuration2020-06-13T17:52:30ZirlRemove op-ab from CollecTor configurationThis is going away.This is going away.https://gitlab.torproject.org/legacy/trac/-/issues/34029Add more command-line arguments to the Nagios CollecTor check script2020-06-13T17:52:30ZKarsten LoesingAdd more command-line arguments to the Nagios CollecTor check scriptMoved here from #33972:
_I'll also look into the parameters and using argparse next week. Unfortunately, the check wouldn't work for corsicum right now anyway, because that CollecTor instance does not archive all descriptor types. It wo...Moved here from #33972:
_I'll also look into the parameters and using argparse next week. Unfortunately, the check wouldn't work for corsicum right now anyway, because that CollecTor instance does not archive all descriptor types. It would just keep shouting about timestamps being missing. Maybe we'll need to add another option to only complain about outdated timestamp, not about missing timestamps. Added to my list._
These are two changes:
- add two separate host and IP parameters as suggested on the other ticket and
- add another parameter for ignoring missing timestamps.
None of these changes are critical, but making them sooner rather than later reduces the overhead for context switching.
The check script is [here](https://gitweb.torproject.org/admin/tor-nagios.git/tree/tor-nagios-checks/checks/tor-check-collector).https://gitlab.torproject.org/legacy/trac/-/issues/34030Indexer ignores a file after moving it away and back shortly after2020-06-13T17:52:31ZKarsten LoesingIndexer ignores a file after moving it away and back shortly afterToday I tried to trigger the new Nagios CollecTor check by moving away a recent Snowflake file and moving it back a few minutes later.
The first part of moving the file away worked fine to the effect that it was not included in the `ind...Today I tried to trigger the new Nagios CollecTor check by moving away a recent Snowflake file and moving it back a few minutes later.
The first part of moving the file away worked fine to the effect that it was not included in the `index.json` file anymore.
However, the second part of moving the file back did not cause the indexer to include the file in the `index.json` file again.
What I had to do was touch the file and setting a slightly different last-modified timestamp. More precisely, changing the second was not sufficient, but changing the minute was.
I haven't looked at the code yet, but I could imagine that it's related to some optimization we did about not indexing files that we had already indexed before. Maybe it's also related to the way how we keep files available for a certain time after they dropped out of the `index.json` file. Or maybe it's caused by both.
This is not a critical bug, but it's also likely not a complex fix. It would be good to fix this, because it would probably confuse another CollecTor operator who didn't happen to write the indexer code.https://gitlab.torproject.org/legacy/trac/-/issues/34141Stop generating .tpf files2020-06-13T18:04:33ZKarsten LoesingStop generating .tpf filesAs of last week, CollecTor, metrics-lib, and metrics-web all know how to process OnionPerf's .json files. Unless anything else uses .tpf files we can now stop generating those.
Suggested process:
- Discuss any remaining uses of .tpf fi...As of last week, CollecTor, metrics-lib, and metrics-web all know how to process OnionPerf's .json files. Unless anything else uses .tpf files we can now stop generating those.
Suggested process:
- Discuss any remaining uses of .tpf files where .json files are not yet supported.
- Stop generating .tpf files on deployed instances op-{hk,nl,us}2, and if somebody complains, re-generate them from existing log files until they have switched.
- Remove the code that generates .tpf files from OnionPerf.https://gitlab.torproject.org/legacy/trac/-/issues/34208Onionperf errors when no subcommand is given (python3)2020-06-13T18:04:35ZAna CusturaOnionperf errors when no subcommand is given (python3)Not a major issue by any means, but OP errors when ran without any arguments. This seems to be a behaviour change from Python2 to Python3. The expected behaviour was previously to print help.
```
~/onionperf$ onionperf
Traceback (most re...Not a major issue by any means, but OP errors when ran without any arguments. This seems to be a behaviour change from Python2 to Python3. The expected behaviour was previously to print help.
```
~/onionperf$ onionperf
Traceback (most recent call last):
File "/usr/local/bin/onionperf", line 532, in <module>
if __name__ == '__main__': sys.exit(main())
File "/usr/local/bin/onionperf", line 351, in main
args.func(args)
AttributeError: 'Namespace' object has no attribute 'func'
```
I've attached a patch to get back that behaviour. See also https://bugs.python.org/issue16308.https://gitlab.torproject.org/legacy/trac/-/issues/34213Replace TorCtlParser with OnionTrace's control log parser2020-06-13T18:04:35ZKarsten LoesingReplace TorCtlParser with OnionTrace's control log parserSimilar to our plan to use TGen's analysis.py instead of OnionPerf's in #33974, the idea would be to avoid keeping our own copy of a Tor control even log parser in OnionPerf.
This work should start with an analysis how much work this is...Similar to our plan to use TGen's analysis.py instead of OnionPerf's in #33974, the idea would be to avoid keeping our own copy of a Tor control even log parser in OnionPerf.
This work should start with an analysis how much work this is going to save in the long run, and whether that justifies adding another dependency.
Feel free to adjust estimated points before starting to work on this if 2.0 doesn't make any sense.https://gitlab.torproject.org/legacy/trac/-/issues/34217Include partial downloads in existing TTLB graphs2020-06-13T18:04:37ZKarsten LoesingInclude partial downloads in existing TTLB graphsWith #26673 being resolved we should include partial downloads in existing TTLB graphs. Maybe there's a way to put less emphasis on the different file sizes and combine the various partial downloads in a single TTLB graph.With #26673 being resolved we should include partial downloads in existing TTLB graphs. Maybe there's a way to put less emphasis on the different file sizes and combine the various partial downloads in a single TTLB graph.https://gitlab.torproject.org/legacy/trac/-/issues/34218Split PROXY errors into whatever reasons are given in TorCtl logs2020-06-13T18:04:37ZKarsten LoesingSplit PROXY errors into whatever reasons are given in TorCtl logsIf we combine TGen transfers with Tor streams and circuits we can learn a lot more about why our proxy (Tor) failed. Including that information in visualizations might be very useful.
When we match TGen transfers with TorCtl events, we'...If we combine TGen transfers with Tor streams and circuits we can learn a lot more about why our proxy (Tor) failed. Including that information in visualizations might be very useful.
When we match TGen transfers with TorCtl events, we'll have to look [how metrics-lib does this](https://gitweb.torproject.org/metrics-lib.git/tree/src/main/java/org/torproject/descriptor/onionperf/OnionPerfAnalysisConverter.java).
Maybe we can use some ideas from #30612 where we discussed putting an error code graph on Tor Metrics.https://gitlab.torproject.org/legacy/trac/-/issues/34224Update analysis results file version to 2.02020-06-13T18:04:38ZKarsten LoesingUpdate analysis results file version to 2.0We added a new field to the analysis results file format in #26673, but we did not yet increment the format version number. The current version field is a floating point number, which doesn't work well for versioning. We should use a ver...We added a new field to the analysis results file format in #26673, but we did not yet increment the format version number. The current version field is a floating point number, which doesn't work well for versioning. We should use a version string here. Given that this change alone is going to be backward-incompatible, we'll have to call the new version 2.0. I'm preparing a patch.https://gitlab.torproject.org/legacy/trac/-/issues/34231Document and maybe improve how we're mapping TGen transfers to Tor streams/ci...2020-06-13T18:04:39ZKarsten LoesingDocument and maybe improve how we're mapping TGen transfers to Tor streams/circuitsOnionPerf uses TGen to make transfers using a local Tor client. OnionPerf also uses Stem to connect to the Tor client's control port and register for control events.
This ticket is about documenting how we can map TGen transfers to Tor ...OnionPerf uses TGen to make transfers using a local Tor client. OnionPerf also uses Stem to connect to the Tor client's control port and register for control events.
This ticket is about documenting how we can map TGen transfers to Tor streams and circuits. OnionPerf did this to produce the .tpf output format (which we just killed in #34141). But we'll also need this functionality to implement #34218 or #33260.
Here's what we're doing in [metrics-lib](https://gitweb.torproject.org/metrics-lib.git/tree/src/main/java/org/torproject/descriptor/onionperf/OnionPerfAnalysisConverter.java#n121) right now to map transfers and streams:
- Index Tor circuits by their circuit ID.
- Index Tor streams by their source port; if there are two or more streams with the same source port, remember them all.
- Go through TGen transfers one by one. For each, extract the local source port.
- Go through Tor streams with the same source port and check if transfer end and stream end happened within 150 seconds.
- If there's a match, look up the corresponding circuit by circuit ID.
Note that OnionPerf took a simpler approach for producing .tpf files by remembering just one stream by source port and not applying that 150 seconds heuristic. The result was that some mappings were wrong. The approach taken by metrics-lib leads to a few missing mappings (probably as many as OnionPerf had), and apparently no wrong mappings.
Is there a way to have an exact mapping that doesn't require a heuristic? And is there a way to do it without having to wait for transfer and stream to end?https://gitlab.torproject.org/legacy/trac/-/issues/34257Analyze unusual distribution of time to extend to first hop in circuit2020-06-13T18:04:40ZKarsten LoesingAnalyze unusual distribution of time to extend to first hop in circuitI spent some time looking at OnionPerf measurements today. I found something that I did not expect: It seems like the time required to build the first hop in a circuit has a huge variance and rather unusual distribution. I'll attach a gr...I spent some time looking at OnionPerf measurements today. I found something that I did not expect: It seems like the time required to build the first hop in a circuit has a huge variance and rather unusual distribution. I'll attach a graph shortly that visualizes that.
Looking at that graph, we can see a few things:
- The three OnionPerf instances have very different performance regarding circuit extension. (I checked the earlier instances op-hk, op-nl, and op-us, and they had the same characteristics.)
- There are huge plateaus for op-us2 and op-nl2 in the first hop graph where _some_ circuits have been successfully extended and others not. Typically, we'd expect a distribution like op-nl2's, just pulled to the right. But that's not the case here. The blue line is special at around 0.6 seconds and the red line at around 0.9 seconds. In fact, the green line is also a bit special at around 0.3 seconds when it almost flattens, only to increase linearly until it reaches 100% at around 0.6 seconds.
- If we assume that the U.S. and Hong Kong are simply far away from many relays in a geographical sense, that doesn't explain why extending to the middle node and to the exit goes relatively fast even for those two hosts. Keep in mind that extending to the second hop requires a round-trip to the first hop, and that extending to the third hop requires a round-trip to the first and the second hop.
What's going on here? What properties of these relays should we be looking at? I already looked at:
- consensus weight,
- date/time of building these circuits, and
- whether these are just a small number of guards being reused over and over;
but nothing of these explained the shape of these ECDFs. I'm going to attach the data file that this graph is based on, if others want to take a look.
And would it make sense to try out running an OnionPerf instance on another set of hosts that are geographically close to our current hosts? Maybe it's related to how these hosts are set up, including their network? (Just in case that other set of hosts produces different results, we would still have to investigate how that affects our overall measurements of things like time to first byte or throughput.)
This is relevant to Sponsor 59, because we need to make sure that our current measurements are going to be a solid baseline for future experiments. Classifying as potential defect.https://gitlab.torproject.org/legacy/trac/-/issues/34287Make the dataset accessible and downloadable2020-06-13T17:56:14ZBarkin SimsekMake the dataset accessible and downloadableThe data collected is stored in an InfluxDB database. The data needs to be stored in a more accessible/common format which can be easily downloaded.The data collected is stored in an InfluxDB database. The data needs to be stored in a more accessible/common format which can be easily downloaded.https://gitlab.torproject.org/legacy/trac/-/issues/34288Integrate more web browsers/fetchers and their older versions2020-06-13T17:56:15ZBarkin SimsekIntegrate more web browsers/fetchers and their older versionsCurrently, only the Tor Browser itself is a part of the system. We need to be able to fetch webpages with other browsers like (Firefox, Chromium, etc.) and other methods for fetching webpages (cURL, python libraries, etc.).
Additionall...Currently, only the Tor Browser itself is a part of the system. We need to be able to fetch webpages with other browsers like (Firefox, Chromium, etc.) and other methods for fetching webpages (cURL, python libraries, etc.).
Additionally, we need to be able to have multiple versions of these browsers/fetchers to see if using different versions makes a difference.https://gitlab.torproject.org/legacy/trac/-/issues/34289Integrate Cloudflare API not to change Cloudflare settings manually2020-06-13T17:56:15ZBarkin SimsekIntegrate Cloudflare API not to change Cloudflare settings manuallyUsing different zone settings and security levels makes a huge difference. So, integrate the [Cloudflare API](https://api.cloudflare.com/#zone-settings-properties) to check how these settings affect the results.Using different zone settings and security levels makes a huge difference. So, integrate the [Cloudflare API](https://api.cloudflare.com/#zone-settings-properties) to check how these settings affect the results.https://gitlab.torproject.org/legacy/trac/-/issues/34290Enhance the available visualizations on the dashboard2020-06-13T17:56:15ZBarkin SimsekEnhance the available visualizations on the dashboardThe visualizations are not easy to understand at first sight. Make them as simple and as meaningful possible.The visualizations are not easy to understand at first sight. Make them as simple and as meaningful possible.https://gitlab.torproject.org/legacy/trac/-/issues/34291Create an API for enabling 3rd party interactions with the system2020-06-13T17:56:16ZBarkin SimsekCreate an API for enabling 3rd party interactions with the systemhttps://gitlab.torproject.org/legacy/trac/-/issues/34292Create an API for people to fetch data easily2020-06-13T17:56:16ZBarkin SimsekCreate an API for people to fetch data easilyThis API might feature customized queries to get a specific part of the dataset rather than the whole dataset.This API might feature customized queries to get a specific part of the dataset rather than the whole dataset.https://gitlab.torproject.org/legacy/trac/-/issues/34293Create an API for running the system on the user-provided websites2020-06-13T17:56:17ZBarkin SimsekCreate an API for running the system on the user-provided websitesThis part of the API aims to run certain tests on user-provided websites. So that people are not limited to the types of websites provided by the CAPTCHA Monitor.This part of the API aims to run certain tests on user-provided websites. So that people are not limited to the types of websites provided by the CAPTCHA Monitor.https://gitlab.torproject.org/legacy/trac/-/issues/34294Integrate Tor Stem2020-06-13T17:56:17ZBarkin SimsekIntegrate Tor StemIntegrate [Tor Stem](https://stem.torproject.org/) to choose specific Tor exit nodes for testing.Integrate [Tor Stem](https://stem.torproject.org/) to choose specific Tor exit nodes for testing.https://gitlab.torproject.org/legacy/trac/-/issues/34295Develop a module for parsing and modifying the HTTP headers2020-06-13T17:56:18ZBarkin SimsekDevelop a module for parsing and modifying the HTTP headersWe need to develop a module for parsing and modifying the HTTP headers to test different conditions.We need to develop a module for parsing and modifying the HTTP headers to test different conditions.https://gitlab.torproject.org/legacy/trac/-/issues/34296Develop a mechanism for disabling/enabling cookie, JavaScript, etc. functiona...2020-06-13T17:56:18ZBarkin SimsekDevelop a mechanism for disabling/enabling cookie, JavaScript, etc. functionality of the web browsershttps://gitlab.torproject.org/legacy/trac/-/issues/34297Explore different options other than crontab to have a flexible scheduling sy...2020-06-13T17:56:18ZBarkin SimsekExplore different options other than crontab to have a flexible scheduling systemCurrently, I use crontab for fetching web pages at regular intervals. I believe it is not the best option, and it is worth exploring the options available.Currently, I use crontab for fetching web pages at regular intervals. I believe it is not the best option, and it is worth exploring the options available.https://gitlab.torproject.org/legacy/trac/-/issues/34352Bump OP version in setup.py2020-06-13T18:04:43ZAna CusturaBump OP version in setup.pyI ran into a weird bug where installing the latest OP on a system that already has an installation from a version prior to commit [de26da3](https://gitweb.torproject.org/onionperf.git/commit/?id=de26da351d859b64a35b81eb2d07dbf325a86960) ...I ran into a weird bug where installing the latest OP on a system that already has an installation from a version prior to commit [de26da3](https://gitweb.torproject.org/onionperf.git/commit/?id=de26da351d859b64a35b81eb2d07dbf325a86960) results in the following error message:
```
$ onionperf
Traceback (most recent call last):
File "/usr/local/bin/onionperf", line 4, in <module>
__import__('pkg_resources').run_script('OnionPerf==0.2rc0', 'onionperf')
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 667, in run_script
self.require(requires)[0].run_script(script_name, ns)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1452, in run_script
raise ResolutionError(
pkg_resources.ResolutionError: Script 'scripts/onionperf' not found in metadata at None
```
It looks like `setuptools` is renaming the OnionPerf version from `0.2.pre` (as it is currently specified in `setup.py`) to `0.2rc0` when installing, and they somehow conflict. I've tested this can be solved by bumping the version to 0.3 in `setup.py` (patch attached).https://gitlab.torproject.org/legacy/trac/-/issues/34397Onion for metrics.torproject.org makes clearnet XMLHttpRequests2020-06-13T18:15:36ZcOnion for metrics.torproject.org makes clearnet XMLHttpRequestsA query such as http://rougmnvswfsmd4dq.onion/rs.html#toprelays will send an XHR through onionoo.torproject.org rather than through tgel7v4rpcllsrk2.onion
For a hidden service, it seems preferred not to have any third-party clearnet req...A query such as http://rougmnvswfsmd4dq.onion/rs.html#toprelays will send an XHR through onionoo.torproject.org rather than through tgel7v4rpcllsrk2.onion
For a hidden service, it seems preferred not to have any third-party clearnet requests.