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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
`Auto-Submitted` is defined in the rfc 5436 [1] and describes how
an automatic response (f.e. ooo replies, etc.) should behave on the
emails. When using `Auto-Submitted: auto-generated` (or any value
other than `none`) automatic replies won't be triggered.
[1]: https://www.rfc-editor.org/rfc/rfc3834.html
Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
technically an empty string is not valid json, but when sending an api
request without any parameters, treating the empty body as an empty
parameter hash instead of an error, makes the the api more robust for
clients
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
note: not complete, there's other code to check and rework, but I had
this already done so commit it, better than nothing.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This moves the clean-up to happen up-front. That way one can still
inspect the test data after, e.g., a failed test.
Originally done almost like this in a patch from Fiona [0] that I just
overlooked, but now also factored out, avoid crowding the test code to
much with duplicate code.
[0]: https://lists.proxmox.com/pipermail/pve-devel/2023-June/057136.html
Suggested-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
the "main" repo only exists for Quincy to allow an easier transition
from Proxmox VE 7 to Proxmox VE 8, for when the enterprise repo got
added for ceph too.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
For now just duplicate the Ceph Quincy entries, as I want to avoid
using macros and we do not yet have support for enums inside enums
with the api macro.
Adapt and expand the tests slightly to have at least some simple
coverage there too.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Files inside CARGO_TARGET_TMPDIR are only cleaned on `cargo clean`, so
tests that expect files to not exist need to cleanup themselves.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
on other targets we print the timestamp without fractional seconds
('.xxxZ'), so we should remove that too on wasm
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
when using the client for an api call that does not return any data
(it returns '{"data":null}'), we would always get an error 'api returned
no data'. The message is technically correct, but it should not be an
error when we expect no data (e.g. most of our CRUD PUT/POST calls)
instead of having the Option<T> in the RawApiResponse type itself, move
it into to the 'nodata' function intended for api calls where we don't
expect any data.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
This commit has the aim of making template rendering a bit more
robust. It does so by a.) Accepting also strings for helpers that
expect a number, parsing the number if needed, and b.) Ignoring errors
if a template helper fails to render a value and showing an error in
the logs, instead of failing to render the whole template (leading
to no notification being sent).
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
This commit updates all helper functions, taking into account recent
developments regarding `tokio`.
In particular, the `block_in_place()` and `block_on()` functions now
don't panic anymore if used within the single-threaded `tokio` runtime
and instead behave as expected in both runtime flavours.
Furthermore, because `tokio` may add more runtime flavours in the
future, all helpers will now panic if used within an unsupported
runtime. This is to prevent unforeseen behavioural quirks and
interactions with `tokio` internals.
The above changes make `BlockingGuard` redundant; it is consequently
removed.
The documentation is also updated, describing the behaviour of the
helper functions and the purpose of the `runtime.rs` module in more
detail.
Signed-off-by: Max Carrara <m.carrara@proxmox.com>
Since the WASM client cannot actually use a `http::Request` the way we
expect it to, that is, it cannot manually along cookies, we turn the
client bit inside out:
This crate mainly defines the `HttpApiClient` trait which expects the
http client to perform *authenticated* API calls, that is, the
handling of API tokens and tickets should happen at the *implementor*
side.
The product clients will require *this* trait to be implemented, and
will not themselves offer a way to login.
As for the `Client` struct, this will now instead *implement* this
trait and will *not* be used in the `wasm` ecosystem. Rather, this is
the ticket handling http client that already exists in the PWT based
ui code.
The PVE client in `pve-api-types` will not *contain* a `Client`
anymore, but rather, it will provide PVE api call implementations for
something implementing `HttpApiClient`.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
The environment trait was useful on the CLI, but does not really
translate well to eg. the wasm ui (or pdm for that matter), so drop it
and instead have `.login` and `.login_tfa` just take the
`proxmox_login` type and handle the updating of authentication data.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Because we ultimately also want to drop the `Environment` trait since
it is not suitable for all use cases (eg. wasm ui)
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
In the uncommon circumstance that calls to `read()` end up reading any number of
bytes other than 4096, the subsequently read bytes become misaligned, causing
blocks of zeroes to be written unnecessarily.
To illustrate, imagine you have a 12KiB file:
[x][x][x][x][ ][ ][ ][ ][x][x][x][x]
└──4096──┘ └──4096──┘ └──4096──┘
The first and last block are filled with some data, whereas the middle block is
empty and will therefore result in only zeroes being read.
In order for the empty block to be skipped with `seek()`, the entire buffer has
to be filled with zeroes.
If, for example, the first `read()` ends up putting only 3KiB into the buffer,
the empty block in the middle won't be detected properly, as the buffer will
now always contain some data. What results are four misaligned reads:
[x][x][x][x][ ][ ][ ][ ][x][x][x][x]
├─────┘ ├────────┘ ├────────┘ │
1 2 3 4
This is fixed by ensuring chunks of 4KiB are always read into the buffer,
except when the last block is truncated. In order to prevent frequent small
reads, the incoming reader is also buffered via `io::BufReader`.
Signed-off-by: Max Carrara <m.carrara@proxmox.com>
this should avoid most common size limitations. the search should also
complete quicker as fewer results need to be computed. note that this
way a configuration may be accepted, but the related sync job can
fail due to and exceeded size limit warning for some ldap servers
(such as 2.5.14+dfsg-0ubuntu0.22.04.2).
Signed-off-by: Stefan Sterz <s.sterz@proxmox.com>
