| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The errors returned by `upload_all` are now all fatal, so we there is no
point in retrying `upload_all` on failure.
Note this will exacerbate #1155, as it will cause the seemingly
transient time skew issues to become fatal (the corresponding error type
is `Bug`, so in principle they ought to be fatal)
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
We're going to reuse this for other kinds of storage error.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is needed for the replay logs.
It's a shame that CheckedDir is (i) a bit unergonomic (ii) has an
extra bool in it, or we could pass one of those instead of these two
arguments.
Since HS's might be created after startup, TorClient must have these
fields.
|
| | | |
| | |
| | |
| | | |
create_storage_handles_from_state_mgr (fmt)
|
| | | |
| | |
| | |
| | |
| | | |
This will allow us to more faithfully model the actual Arti state
directory layout.
|
| | | |
| | |
| | |
| | |
| | | |
This is to prevent current use of the same directory of replay logs by
different instances.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This ought to have the hash algorithm name in it or we'll have trouble
if we want to change the hash algorithm in the future. (Strictly, we
could just choose a different magic but the string was rather short.)
Add a newline, which is often convenient in file headers.
And "onion" to mean "onion swervice" is improper.
|
| |/ /
| |
| |
| | |
Make `#[cfg(target_family = "unix")]` appear only once.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
The publisher now returns `FatalError`s, so we don't need `ReactorError`
anymore. Addresses a TODO HSS in publish/reactor.rs
Part of #1129
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
This is another type of fatal error.
|
| | |
| |
| |
| | |
We're about to use this (in the publisher reactor).
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The publisher logs a nice `info!` message when it receives the shutdown
signal. The publisher can infer that the service is shutting down from
the errors received on its various receiver channels (i.e. from the
errors that suggest the sender was dropped), but listening for the
shutdown signal is nicer.
|
| | |
| |
| |
| |
| |
| |
| | |
This will be used by the descriptor publisher soon (we want to abolish
its `ReactorError` altogether, and to do that, we need to get rid of
`ReactorError::ShuttingDown`. `ShuttingDown::Terminate` happens to be a
suitable replacement).
|
| | |
| |
| |
| |
| | |
This moves us one step closer to removing ReactorError in favour of
FatalError (see the TODO HSS above ReactorError for more details).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, this would return `ReactorError::PublishFailure` if the
upload failed. However, that error wasn't used for anything other than
logging.
Instead of returning the error, we now log it inside
`upload_descriptor_with_retries` and return an `UploadStatus` describing
the upload outcome. This will enable us to abolish
`ReactorError::PublishFailure` (and eventually replace `ReactorError`
with `FatalError`).
|
| |/
|
|
|
| |
The failure to build a descriptor out of seemingly valid parts is an
internal (irrecoverable) error.
|
| | |
|
| | |
|
| |
|
|
| |
This line is too long.
|
| |
|
|
|
| |
We already log the outcome of the HsDir upload in the function that
calls this code.
|
| |
|
|
| |
This also wraps the line.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, it was possible for the `IptPublishSet` used to generate the
descriptor and the `IptPublishSet` `note_publication_attempt` to
differ. Now, the publisher generates the descriptor using the same
`IptPublishSet` it calls `note_publication_attempt` on.
Note that as a consequence, the publisher generates a new descriptor
just before _each_ HsDir upload. This means each HsDir could, in theory,
receive a different descriptor (not just in terms of revision-counters,
but also with a different set of IPTs). It may seem like this could lead
to some HsDirs being left with an outdated descriptor, but that's not
the case: after the upload completes, the publisher will be notified by
the ipt_watcher of the IPT change event (if there was one to begin
with), which will trigger another upload job.
Previously, the publisher would only generate a single descriptor for
each time period (all HsDirs in a given time period would receive the
same descriptor).
Closes #1097
|
| |
|
|
|
|
| |
This was previously in `TimePeriodUploadResult`. We will soon have
different revision_counter for each `HsDirUploadResult`, so let's
preemptively move the field there.
|
| | |
|
| |
|
|
| |
We're going to need to clone it soon.
|
| |
|
|
|
|
|
|
| |
`generate_revision_counter` and `create_ope_key` don't use anything from
`self` other than `imm`, so they might as well be methods on
`Immutable`. This change is needed because we're soon going to need to
use `generate_revision_counter` from an associated `Reactor` function
(where we don't have `self`).
|
| |\
| |
| |
| |
| |
| |
| | |
tor-hsservice: Remove a publisher TODO that has been addressed.
Closes #1131
See merge request tpo/core/arti!1807
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The publisher doesn't reupload unless explicitly asked to do so by the
`IptManager` (via `await_update()`).
Also, when the consensus changes, we always trigger a reupload, but only
to those HsDirs that don't already have the descriptor (the HsDirs
marked as "clean" stay "clean", and any new HsDirs are marked "dirty"
until they get a copy of the descriptor. See !1806).
Similarly, a config change only triggers a reupload if the change means
we need to generate a new descriptor (e.g. if the `anonymity` of the
service changes). Note, however, that this logic is currently commented
out (it depends on #1028).
Closes #1131
|
| | |
| |
| |
| | |
Part of #1083
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We need to know the status of each component to be able to report the
overall status of the service. Without this change, the service (and its
components) have no way of knowing if a given transition is valid: if
the state of a component (say, the IPT manager) is `Bootstrapping`,
`Recovering` or `Broken`, a transition out of the current state is only
valid if it is initiated by the same component that caused the current
state (for example, if the publisher sets the state to `Recovering`, the
IPT manager should not be allowed to trigger an overall state transition
to `Running`).
Part of #1083
|