GitLab

Issue/14

See merge request !6

Issue/12

See merge request !5

So far, bridgestrap would only consume Tor's controller events from
c.eventChan as long as the main execution flow was in TestBridgeLines.
Outside of that function, controller events would keep on coming but not
be consumed.  That worked fine for a while because c.eventChan has a
buffer of 100 events but occasionally it would result in the buffer
filling up, which would cause a deadlock because bulb, our controller
library, would block on sending bridgestrap its events.

This patch fixes the issue by also consuming events outside of
TestBridgeLines.  The patch further adds a new Prometheus time series
called pending_events, which captures the number of pending events.  The
time series will help us monitor if this patch got the job done.

This should fix a race condition that we ran into in deployment:

    fatal error: concurrent map iteration and map write

    goroutine 98984 [running]:
    runtime.throw(0x95bb18, 0x26)
            /home/phw/sw/go/src/runtime/panic.go:1116 +0x72 fp=0xc0001735a8 sp=0xc000173578 pc=0x437e32
    runtime.mapiternext(0xc000173650)
            /home/phw/sw/go/src/runtime/map.go:853 +0x554 fp=0xc000173628 sp=0xc0001735a8 pc=0x412534
    main.(*TestCache).FracFunctional(0xc00016e960, 0xc00014a990)
            /home/phw/rcs/bridgestrap/cache.go:64 +0xbb fp=0xc0001736c0 sp=0xc000173628 pc=0x8610db
    main.(*TestCache).AddEntry(0xc00016e960, 0xc00031caa0, 0x98, 0x9dab00, 0xc00002e060, 0x13d5c8c, 0xed78148dc, 0x0)
            /home/phw/rcs/bridgestrap/cache.go:161 +0x17c fp=0xc000173730 sp=0xc0001736c0 pc=0x861c5c
    main.testBridgeLines(0xc00000f500, 0x1c)

When bridgestrap read its cache from disk, it wouldn't only read the
cache entries but also the cache timeout, overriding whatever we
provided over the command line.  In other words, if bridgestrap saved a
cache whose timeout was set to 24h, and we later restart bridgestrap
with a given cache timeout of 18h, it would use 24h because that's what
it read from disk.

This patch fixes this bug in two ways: 1) we no longer write the cache
timeout to disk and 2) we set the cache timeout after reading the cached
entries from disk.

This patch is a follow-up commit to #10.

It's important that bridgestrap's cache timeout is less than or equal to
rdsys's pluggable transport expiry time.  If bridgestrap expires cache
entries after 24 hours and rdsys wants to re-test bridges after 18
hours, then there's a worst case of a 6 hour window within which
bridgestrap will refuse to re-test rdsys's bridges because they're still
in the cache.  Rdsys will keep bothering bridgestrap because it wants a
more recent test result.

This patch reduces bridgestrap's default cache timeout to 18 hours,
which is the number of hours after which bridges should re-upload their
descriptors to the bridge authority:
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt?id=c2a584144330239d6aa032b0acfb8b5ba26719fb#n369

This patch 1) makes obfs4proxy log its output to file and 2) adds a log
message that prints the error message (if any) after sending a "SIGNAL
ACTIVE" tor tor.

By default, tor goes to sleep after 24 hours of no user activity.
Bridgestrap's control port interaction does not count as user activity,
which means that tor effectively stops working after 24 hours.  To work
around this, we're sending tor a SIGNAL ACTIVE, which wakes up tor in
case it went to sleep.  This is a cheap thing to do, so we might as well
do it before each SETCONF.

This patch fixes #12.

Make metrics more idiomatic to Prometheus.

Closes #10

See merge request !4

Our metrics aren't implemented in the way Prometheus recommends.  This
patch makes use of labels and renames our metrics to change that.  For
example, instead of having two metrics called cache_hits and
cache_misses, we now have a single metric called cache_total and it
accepts a "type" label that can take on the values "hit" or "miss".

This patch fixes #10.

Our timeout is set to 60 by default, so the actual execution time is 60
+ a few milliseconds.  Adding +1 to the final bucket covers that case.

Export Prometheus-based metrics

Closes #4

See merge request !3

The way Prometheus works is that a central instance scrapes metrics from
various endpoints, bridgestrap being one of them.  We expose a new HTTP
handler for /metrics and let our Prometheus library do the rest.

This patch fixes #4

So far, bridgestrap would serialise requests by relying on a mutex's
locking mechanism.  That's dirty.  This patch implements a channel-based
dispatching mechanism that guarantees order (mutexes don't).  In
addition to that, we can now log the number of outstanding requests,
which is good to know.

Having tor log at 'info' level makes its log files grow significantly
faster.

So far, our cache timeout was hard-coded to be one week.  Now that
bridgestrap is more efficient, we can afford to test resources more
often, so this patch changes the default timeout to 24 hours.  The patch
also makes this timeout configurable through the new -cache-timeout
switch.

While at it, the patch also refactored our cache mechanism a bit and
renamed -timeout to -test-timeout.

This patch fixes #8

This patch adds the -log command line switch, which instructs
bridgestrap to log to the given file.

This patch bumps our code coverage to 48.6%.

For reasons outlined in #2, we want to be
able to use a custom tor for now.  This patch introduces a new command
line switch, -tor, which makes this possible.

Issue/6

Closes #6

See merge request !2

This patch fixes #6

...and start with version 0.0.1.

If our event channel is closed, our last read results in nil.  This
patch makes bridgestrap check for this condition before accessing the
result's struct members.