This used to be supported, as we explicitly call std::fs::create_dir_all
when initializing these, but it was broken in
b01b70fc20, which attempts to canonicalize
the paths to check for overlap before creating them.
For example, if the database path is `/foo` and the media path is
`/foo/bar`, but `/foo/bar` is a symlink or hardlink to `/baz`, the
previous check would pass. The whole point of this check is to ensure
that the database and media data can't step on each other, so this check
is needed to deny that kind of situation as well.
It would probably be good to add a test for this behavior.
The primary motivation for this change is to support databases that
don't take a path, e.g. out of process databases.
This configuration structure leaves the door open for other media
storage mechanisms in the future, such as S3.
It's also structured to avoid `#[serde(flatten)]` so that we can use
`#[serde(deny_unknown_fields)]`.
This will break backwards compatibility of configurations, but
ensures that a previously-configured setting won't get dropped
arbitrarily. Pretty much worth it, I think.
The previous code used `server_name` as a fallback but in reality there
is no real relationship between `server_name` and the location clients
are supposed to make requests to.
Additionally, the `insecure` option is gone, because we now allow users
to control the entire URL, so they're free to choose the scheme.
This way users can have a simpler time configuring this stuff and we can
worry about the spec compliance parts and specifying the same thing over
and over parts.
The following are now configurable:
- the OpenTelemetry endpoint,
- the tracing-flame filename, and
- whether the log output should include timestamps (useful to disable if
it goes straight into journald).
This renames:
database_backend -> database.backend
database_path -> database.path
db_cache_capacity_mb -> database.cache_capacity_mb
rocksdb_max_open_files -> database.rocksdb_max_open_files
Charles updated the NixOS module.
Co-authored-by: Charles Hall <charles@computer.surgery>
The vast majority of spans are at the info level, so increasing the log
level to info will greatly increase the amount of (useful!) inforamtion
included in the logs.
However, `ruma_state_res` generates a substantial amount of logs, so
that one gets to stay fixed at `warn` for now.
We want to be able to disable colors for complement logs (since they
are likely to be opened in a text editor). There's no pressing need for
alternative log formats, but I'm interested in whether the 'pretty'
format will be easier for debugging.
I chose to add 'log_*' options rather than making a separate 'log'
section for now. There's been some discussion about trying to separate
the tracing/logging stuff into more structured sections, but that can
happen later.
The "listening for incoming traffic on ..." log line is new, but
something I've wanted even when we only supported one listener.
I considered getting rid of `clippy::too_many_lines` by factoring out
the construction of `app` to a separate function, but found that
specifying it's type (or relevant traits) got quite hairy.
This is a config compatibility break.
The ability to listen on multiple ports, including both TLS and non-TLS,
is necessary for running complement against grapevine.
This allows the error handling to be done upfront instead of for each
use. In particular, the `toml` error now points to the span of text in
the config file where the misconfigured EnvFilter value is. This is much
better than the previous error that did not indicate what was actually
causing it to happen.
This separates concerns a bit more. We will probably want to extend the
logic for config loading in the future, and that stuff should all live
in the relevant place. This change points us in the right direction.
Just `cat` the config file. Also this code would be very annoying to
maintain. Getting rid of this also revealed that another config option
is specific to RocksDB, so `cfg`s for that have been added.
