Instead of passing the template strings for subject and body when
constructing a notification, we pass only the name of a template.
When rendering the template, the name of the template is used to find
corresponding template files. For PVE, they are located at
/usr/share/proxmox-ve/templates/default. The `default` part is
the 'template namespace', which is a preparation for user-customizable
and/or translatable notifications.
Previously, the same template string was used to render HTML and
plaintext notifications. This was achieved by providing some template
helpers that 'abstract away' HTML/plaintext formatting. However,
in hindsight this turned out to be pretty finicky. Since the
current changes lay the foundations for user-customizable notification
templates, I ripped these abstractions out. Now there are simply two
templates, one for plaintext, one for HTML.
fix #5249: apt: allow parsing Packages without Priority field
it seems there are repositories out there that don't (always) include
it, and while it is required for the .deb packages themselves in Debian,
the repository "spec" doesn't make it mandatory.
fix #5249: apt: allow parsing Packages without Priority field
it seems there are repositories out there that don't (always) include
it, and while it is required for the .deb packages themselves in Debian,
the repository "spec" doesn't make it mandatory.
notify: fix #5274: also set 'X-Gotify-Key' header for authentication
Versions of Gotify < 2.2.0 only supported the 'X-Gotify-Key' header
for passing the API token. This comment sets this header in addition
to the regular 'Authorization' header in order to be compatible with
older Gotify servers.
Christoph Heiss [Fri, 12 Jan 2024 16:15:57 +0000 (17:15 +0100)]
ldap: add method for retrieving root DSE attributes
The root DSE holds common attributes about the LDAP server itself.
Needed to e.g. support Active Directory-based LDAP servers to retrieve
the base DN from the server itself, based on an valid bind.
See also RFC 4512, Section 5.1 [0] for more information about this
special object.
Gabriel Goller [Mon, 22 Jan 2024 14:23:32 +0000 (15:23 +0100)]
fix: use fragmented block size for space calculation
We currently calculate the size of a datastore using `statfs64`, which
returns the number of blocks in the fs and the two block sizes:
fragemented block size(f_frsize) and block size (f_bsize). To calculate
eg the total space in a datastore we use total_blocks * f_bsize, which
is not always correct.
`f_frsize` is the minimum unit of allocation on the filesystem (in
bytes) and in 99% of the cases equal to `f_bsize`, but in some cases
it differs. For example some filesystems allow smaller blocks for small
files, in case f_frsize < f_bsize. In that case, f_frsize * total_blocks
returns (mostly) the correct result (ceph also did some weird stuff, which is
now being fixed though [0][1]). `statvfs` also documents this as the
recommended way ('fsblkcnt_t f_blocks; /* Size of fs in f_frsize units */')[2].
This patch aligns the the behavior with the libc utilities (also used by
`df`) [3].
Use the `std::io::IsTerminal` trait introduced in Rust 1.70.
Internally it calls `libc::isatty`, see [1, 2]. Note that it switches
the comparison from `== 1` to `!= 0` which shouldn't make a difference
assuming that libc::isatty upholds the promises made in its man page.
The MSRV was set on the workspace to reflect this change.
A 'oneOf' schema is basically exactly what a rust `enum` is.
Exactly one of the possible values must match the data.
This should ultimately be the base to allow using the
`#[api]` macro on a newtype style enum as well as using this
schema as a configuration for our section config parser.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com> Reviewed-by: Lukas Wagner <l.wagner@proxmox.com>
Nightly currently produces a different output format so this command
doesn't work right now when +system is not the default cargo.
Let's hope this is just a temporary hiccup in nightly, given that
there is an explicit `--format-version=1` parameter...
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Lukas Wagner [Wed, 10 Jan 2024 09:31:21 +0000 (10:31 +0100)]
notify: api: allow resetting built-in targets if used by a matcher
In the 'delete'-handler targets, we check if a
target is still referenced by a matcher - if it is, we return an
error. For built-in targets, this is actually not necessary, since
'deleting' a built-in only resets it to its default settings - it will
continue to exist after that.
The user could easily trigger this if 'mail-to-root', which is
referenced by 'default-matcher' is modified and then reset to its
defaults: An error is shown, the built-in target is not reset.
This commit disables this check if it is a built-in target.
Renamed the helper 'ensure_unused' to 'ensure_safe_to_delete' in the
process.
Also fixed the tests in api::test - they were never executed due to a
faulty #[cfg] directive.
Lukas Wagner [Wed, 10 Jan 2024 09:52:52 +0000 (10:52 +0100)]
notify: smtp: add `Auto-Submitted` header to email body
`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.
Lukas Wagner [Wed, 10 Jan 2024 09:52:51 +0000 (10:52 +0100)]
notify: smtp: forward original message instead nesting
For mails forwarded by `proxmox-mail-forward` to an SMTP target, the
original message was nested as a 'message/rfc822' message part.
Originally this approach was chosen to avoid having to rewrite
message headers.
Good email-clients, such as Thunderbird can display these inline.
Other, more limited clients will show these messages as an attached
.eml file, which is not really a good user experience.
This patch changes the approach for message forwarding to be more like
forwarding mails in a mail client. We create a new message and
add the original message body as a body. Additionally, we also copy
over all message headers that are relevant to correctly display the
original message body (e.g. Content-Type, Content-Transfer-Encoding)
Tested with a couple of different email messages (varying in
structure, body parts, encoding, etc.) against the following SMTP
relays:
- gmail
- outlook
- our own webmail service
Originally reported in our community forum:
https://forum.proxmox.com/threads/proxmox-mail-forward-sends-mails-as-eml.137710/
Lukas Wagner [Mon, 11 Dec 2023 13:29:08 +0000 (14:29 +0100)]
sys: email: use `epoch_to_rfc2822` from proxmox_time
`strftime`'s formatting is locale-dependent. If the system locale was
set to e.g. de_DE.UTF-8, the `Date` header became invalid
(e.g Mo instead of Mon for 'Monday'), tripping up some mail clients
(e.g. KMail).
This commit should fix this by using the new `epoch_to_rfc2822`
function from proxmox_time. Under the hood, this function uses
`strftime_l` with a fixed locale (C).
projects / proxmox.git / log