IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Additional properties will be parsed according to the default string
schema.
This is relevant for use cases when the full schema is not known for
some reason or another. In particular this allows support for parsing
older/newer versions of configuration files. One example of this is
the proposed proxmox-mail-forward helper binary, which currently
doesn't have access to the PBS API types for dependency reasons and
is only interested in the email field for the root user. If it can
only use a minimal schema with additional_properties set to true, it
will be robust against changes.
Writing already works, because the ObjectSchema's verify_json()
already handles additional_properties correctly and
format_section_content() handles them like all other properties
(method doesn't depend on the schema).
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
split out from proxmox-backup using `git filter-repo` including
history with the following --paths-from-file:
```
proxmox-rest-server
src/api/server.rs
src/server/command_socket.rs
src/server/config.rs
src/server/environment.rs
src/server/formatter.rs
src/server/h2service.rs
src/server/rest.rs
src/server/state.rs
src/tools/compression.rs
src/tools/daemon.rs
src/tools/file_logger.rs
src/worker_task.rs
```
no real change for PBS usage - the ApiHandler enum is marked
non_exhaustive now because it has extra values if the new (enabled by
default) "server" feature is enabled.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
signed subscription info files should always be checked to catch
attempts of invalid signatures, but the age and serverid checks only
need to apply to "active" files, else the status might switch from a
more meaningful one to "invalid" by accident.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
for use cases where the full request body is not available from the
start, or the response doesn't need to be fully read in one go.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
so we have proxmox_http::client::Client for the async, hyper-based
client and proxmox_http::client::sync::Client for the sync, ureq-based
one.
this is a breaking change.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
to allow get requests with extra headers (such as `Authorization`) and a
generic `request` fn to increase flexibility even more.
this is a breaking change.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
and rename it to HttpOptions, since it's not specific to the "Simple"
client at all.
this is a breaking change.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
these would cause failures when building the sub-crates directly from
their sub-directory.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
to reduce the creep of optional dependencies being exposed as features.
this requires cargo 0.63 (and debcargo built against at least that
version), but greatly reduces the number of binary packages and provides
generated, while still allowing sensible selection of optional
dependencies via the explicit feature meant for pulling them in.
diff stat for running `make deb` after this change:
proxmox-http/debian/control | 226 ++++--------------------------------
proxmox-router/debian/control | 74 +-----------
proxmox-schema/debian/control | 53 ++-------
proxmox-subscription/debian/control | 17 +--
proxmox-sys/debian/control | 51 +++-----
proxmox-tfa/debian/control | 110 ++----------------
6 files changed, 72 insertions(+), 459 deletions(-)
the 'dep:' prefix marks something on the RHS inside the features section
as dependency, it's only allowed if the string after it is an optional
dependency an no explicit feature of the same name exists. if all
pointers to the optional dependency in the features section are marked
as such, the optional dependency itself will not be exposed as a feature
(either on the cargo or debian/control level).
the '?' suffix marks dependencies as "weak", which only enables the
optional dependency + its feature(s) if the optional dependency itself
is also enabled. it has no effect on d/control since such a relationship
is not encodable in Debian package relations, but it does affect cargo
dependency resolution and allows skipping the build of unneeded optional
dependencies in some cases.
with no packages/crates depending on the no longer exposed automatically
generated features/packages, so these are safe to remove even though
it's technically a breaking change.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
