| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I identified the cases to replace by searching for the string
`.report()`. There are a few that I didn't change:
* A couple of cases that used anyhow::Error,
* One case that reported two Errors.
* Two cases in `tor_hsclient::err` that just did
`error!("Bug: {}")`.
I have also not audited the cases in `tor-hsclient` where we're using
`tor_error::Report` manually.
Nonetheless, closes #949.
|
| |\
| |
| |
| |
| |
| |
| | |
arti: Add a `logging.time_granularity` option with 1s default.
Closes #551
See merge request tpo/core/arti!1376
|
| | |
| |
| |
| |
| |
| |
| | |
This lets us provide less information in our logs: in particular, it
lets us avoid logging with microsecond precision.
Closes #551.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The original version of our panic handler would allocate a string
for the panic `Location`. But if we're panicking we'd like to keep
allocations to a minimum: so instead format the `Location`
conditionally.
This also drops a useless `std::borrow::Cow`. (The possibility of a
"Don't have a `Cow`" commit message was considered and rejected.)
|
| | | |
|
| |/
|
|
|
|
|
| |
(Also leaves installed the default handler that sends messages to
stderr.)
Closes #921.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously we always assumed that the console was ephemeral, and so
we disabled safe logging. But the console can be piped to journald.
And even if we enforce isatty there's no guarantee that the user
isn't using some kind of terminal that logs to disk or something.
Best just to enable SafeLogging unconditionally. I've added a note
about where and how we might re-enable this.
Closes #553.
|
| |
|
|
|
|
|
|
| |
For example, see
https://tpo.pages.torproject.net/core/doc/rust/arti/fn.run.html :
this isn't labeled as `experimental-api`, but it should be.
These APIs were found by poking around in the `arti` crate.
|
| |
|
|
|
| |
Previously we logged at "debug", but that's not meant to
user-facing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The remaining unconditionally public APIs are those related to our
configuration objects, and the main_main() API.
The rationale for making main_main() public is to have an actual
entry point.
The rationale for making the config APIs public is:
1. We really do intend for others to be able to read our
configuration files using this API.
2. The structure of our configuration files is already part of our
interface.
Closes #530.
|
| | |
|
| | |
|
| |
|
|
|
| |
As per point 1 in
https://gitlab.torproject.org/tpo/core/arti/-/issues/488
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Canonicalise the `logging.journald` setting in the validated
configuration. Now it will never be `Some("")`, even if that is what
was written in the config file.
This allows us to write `journald = ""` in the example configuration.
(Without the canonicalisation the default builder produces `None` and
the example would produce `Some("")`, which are semantically identical
but fail the test.)
See https://gitlab.torproject.org/tpo/core/arti/-/issues/488 for some
background.
|
| | |
|
| |
|
|
|
| |
This deletes many handcoded impls. It also generates lots of impls
that we previously didn't have.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I have Plans for this macro. In particular:
* I have a wip branch which tests that the Builder can be
deserialised from an empty config (ie, that config reading
of a config with a blank section for this item works).
* I think we should autogenerate $Config::builder(),
and promote that, rather than $ConfigBuilder::default().
This macro could do that.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Here we add a config option to disable safe logging, and ensure that
safe logging is disabled when we are formatting an error message on
exit (since we assume it's safe to write sensitive info to stderr.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Builders additionally derive: Debug, Serialize, Deserialize.
* Validated structs no longer derive: Serialize, Deserialize
and all related attributes deleted.
* As a consequence, all the `#[serde(deny_unknown_fields)]`
are gone. That means that right now unknown fields are totally
ignored. This is good for compatibility but poor for useability.
Doing something better here is arti#417, in progress.
* As a consequence, delete tor_dirmgr::retry::default_parallelism.
(The default value was already duplicated into a builder attr.)
|
| |
|
|
| |
We want to be able to serialise as well as deserialise configurations.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new API is (roughly) as discussed in
https://gitlab.torproject.org/tpo/core/arti/-/issues/451
This is quite a large commit and it is not convenient to split it up.
It contains the following changes:
* Redo the list builder and accessor macros implemnetation,
including docs and tests.
* Change uses of define_list_config_builder. In each case:
- Move the docs about the default value to the containing field.
- Remove the other docs (which were just recapitulations, and
are now not needed since the ListBuilder is no longer public).
- Rewmove or replace `pub` in the define_list_builder_helper call,
so that the builder is no longer public.
- Change the main macro call site to use define_list_builder_helper.
- Add a call to define_list_builder_accessors.
* Make the module `list_builder` pub so that we have somewhere to
put the overview documentation.
* Consequential changes:
- Change `outer.inner().replace(X)` to `outer.set_inner(X)`
- Consequential changes to imports (`use` statements).
|
| |
|
|
|
|
|
| |
And add an imprecation in define_list_config_builder's doc comment do
do so in future for other invocations of the macro.
Add add the missing full stops.
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/471#note_2798020
|
| |
|
|
|
|
| |
This replaces two almost-identical sets of structs and impls. More
are on the way, as per
https://gitlab.torproject.org/tpo/core/arti/-/issues/447
|
| |
|
|
|
|
|
|
|
|
| |
Since "logfiles: Introduce LogfileListConfigBuilder", this code is in
LogfileListConfigBuilder::build(), which is called by derive_builder's
generated LoggingConfig::build(), and which will add a file context
itself due to the `sub_builder` feature.
So this is otiose. And, we are about to replace this whole thing with
macro_rules-generated code (which won't do this).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/462#note_2797697
we decided not to do this.
However, having looked again at the way the FallbackList works, I
think there is a lot of value in making these two things (and anything
else like them[1]) as similar as possible.
[1] At least PreemptiveCircuitConfig.initial_predicted_ports and
NetworkConfig.authorities need the same treatment, and perhaps also
GuardUsage.restrictions (although there is no
GuardRestrictionBuilder).
In the irc discussion I imagined `LogfilesConfigBuilder` as opposed to
`LogfileConfigBuilder` (differing only in the `s`) which would be bad,
but we can use `List` instead.
We do *not* need to abstract away the validated version of the config.
Providing a type alias helps the derive_builder sub_builder DTRT
without needing special overrides.
I have split this commit so that we can drop it, if we conclude it's
not wanted.
|
| |
|
|
|
|
|
|
|
| |
Change LoggingConfigBuilder to contain Vec<LogfileConfigBuilder>,
not Option<Vec<LogfileConfig>>. That makes it sane to Deserialize.
Replace LoggingConfigBuilder's file(Vec<>) setter with the methods
discussed in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/462#note_2797697
|
| |
|
|
|
| |
It's a plural, and that fact is going to be exposed via serde, if it
isn't already.
|
| |
|
|
| |
This was clumsy. Now it is brought together it can be simplified.
|
| |
|
|
|
|
|
| |
This de-duplicates the code that was in those accessors, and is now in
filt_from_opt_str.
Code motion and direct field access.
|
| |
|
|
|
|
| |
There are no longer needed, because the code that uses this
configuration now lives in the same module as the configuration
itself.
|
| |
|
|
| |
Code motion and import fixups.
|
|
|
We are going to move LoggingConfig here. We should follow the
already-public name IMO.
|