"ours" to avoid version bump.

"ours" to avoid version bump.

When reloading a service, we can re-register a service and thus end up again
in the metrics store initialization code path which is fine. No need to BUG()
anymore.

Fixes #40334

Signed-off-by: David Goulet <dgoulet@torproject.org>

Fixes bug #40256; bugfix on 0.2.9.4-alpha.

Use find_str_at_start_of_line(), not strstr() here: we don't want
to match "MemTotal: " if it appears in the middle of a line.

Fixes #40315; bugfix on 0.2.5.4-alpha.

Now deprecated in libc >= 2.33

Closes #40309

Signed-off-by: David Goulet <dgoulet@torproject.org>

Now deprecated in libc >= 2.33

Closes #40309

Signed-off-by: David Goulet <dgoulet@torproject.org>

The directory_fetches_from_authorities() is used to know if a client or relay
should fetch data from an authority early in the boot process.

We had a condition in that function that made a relay trigger that fetch if it
didn't know its address (so we can learn it). However, when this is called,
the address discovery has not been done yet so it would always return true for
a relay.

Furthermore, it would always trigger a log notice that the IPv4 couldn't be
found which was inevitable because the address discovery process has not been
done yet (done when building our first descriptor).

It is also important to point out that starting in 0.4.5.1-alpha, asking an
authority for an address is done during address discovery time using a one-hop
circuit thus independent from the relay deciding to fetch or not documents
from an authority.

Small fix also is to reverse the "IPv(4|6)Only" flag in the notice so that if
we can't find IPv6 it would output to use IPv4Only.

Fixes #40300

Signed-off-by: David Goulet <dgoulet@torproject.org>

When trying to find our address to publish, we would log notice if we couldn't
find it from the cache but then we would look at the suggested cache (which
contains the address from the authorities) in which we might actually have the
address.

Thus that log notice was misplaced. Move it down after the suggested address
cache lookup.

Closes #40300

Signed-off-by: David Goulet <dgoulet@torproject.org>

Back in 0.4.5.1-alpha we added an `==` comparison, which isn't
portable.

Fixes bug #40298; bugfix on 0.4.5.1-alpha.

Roger Dingledine authored 4 years ago and David Goulet committed 4 years ago

Now that exit relays don't allow exit connections to directory authority
DirPorts, the follow-up step is to make directory authorities stop doing
DirPort reachability checks.

Fixes #40287

Signed-off-by: David Goulet <dgoulet@torproject.org>

Turns out, we forgot to add the METRICS connection type fo the finished
flushing handler.

Fixes #40295

Signed-off-by: David Goulet <dgoulet@torproject.org>

The comment of that specific unit test wanted 4 ORPorts but for some reasons
we tested for 3 which before the previous commit related to #40289, test would
pass but it was in fact wrong.

Now the code is correct and 4 was in fact correct expected number of ports.

Related to #40289

Signed-off-by: David Goulet <dgoulet@torproject.org>

We were just looking at the family which is not correct because it is possible
to have two explicit ORPort for the same family but different addresses. One
example is:

  ORPort 127.0.0.1:9001 NoAdvertise
  ORPort 1.2.3.4:9001 NoListen

Thus, this patch now ignores ports that have different addresses iff they are
both explicits. That is, if we have this example, also two different
addresses:

  ORPort 9001
  ORPort 127.0.0.1:9001 NoAdvertise

The first one is implicit and second one is explicit and thus we have to
consider them for removal which in this case would remove the "ORPort 9001" in
favor of the second port.

Fixes #40289

Signe-off-by: David Goulet <dgoulet@torproject.org>