Gabriel Goller [Tue, 19 Sep 2023 07:35:25 +0000 (09:35 +0200)]
fix #4162: added `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.
[1]: https://www.rfc-editor.org/rfc/rfc3834.html
Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
Lukas Wagner [Wed, 30 Aug 2023 12:37:52 +0000 (14:37 +0200)]
tools: allow to force UTF-8 encoding for file_set_contents
Rationale: This is used from cfs_write_file, which is now also used to
write utf8-encoded strings that come from Rust. If no encoding is
specified while writing the file, we run into problems with certain
special characters (e.g. 'ü').
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
[FG: use flag parameter instead of encoding as a string
use stricter 'UTF-8' instaed of 'utf8' (see 'perldoc Enocode')] Suggested-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
[FE: implement changes suggested by Fabian
move binmode call to where $fh is known to be set] Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Fiona Ebner [Wed, 30 Aug 2023 13:07:52 +0000 (15:07 +0200)]
run fork with timeout: only special case timeout error in list context
run_with_timeout() will treat a timeout error differently when called
in list context and run_fork_with_timeout() should do the same. Ensure
this by calling run_with_timeout() in list context if and only if
run_fork_with_timeout() is called in list context too.
Fixes: a6aa0ae ("run with timeout: return if timeout happened in list context") Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Dominik Csapak [Wed, 16 Aug 2023 09:09:11 +0000 (11:09 +0200)]
SectionConfig: fix handling unknown sections
if we're parsing an unknown section, we cannot check the schema with
`is_array` to check if it's an array type or not, thus we have to
handle that separately.
fix this by handling data in unknown sections like an array similar to
"cb2646c7b4974e33f4148752deec71f0d589b0f3" in proxmox-section-config.
This way we can write unknown section out again like we parsed it.
Add a regression test for an unknown field not in the schema.
This fixes an issue, where calling `qm destroy ID --purge` removed much
of the configs ob backup jobs (since there we parse an 'unknown' section
and run into the `is_array` error)
(Reported in the forum: https://forum.proxmox.com/threads/132091)
Christoph Heiss [Thu, 10 Aug 2023 12:37:05 +0000 (14:37 +0200)]
ldap: handle errors explicitly everywhere instead of simply `die`ing
Most codepaths already have explicit error handling (by the means of
checking the return value), which is essential dead code due to setting
`onerror`.
As LDAP errors might get presented to users due to upcoming changes, the
error location should not be present in these error messages, thus
switch to explicit handling.
Only two calls were missing such explicit handling of errors, so these
are amended as appropriate. Further, some `die`s were missing newlines
at the end of the message, which - again - would cause the error
location to be included.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
the top-level error handling ensures the temporary downloaded file gets
removed in case of an error, so there is no need to also handle that when
decompression fails..
run with timeout: return if timeout happened in list context
This can be relevant info do differentiate if an undef return value
happened due to the closure returning it or if it happened due to a
timeout.
While for quite a few cases this could be handled by a
variable captured by the passed closure code reference, acting as
messenger, that might often require needless wrapping.
Also run_fork_with_timeout warned errors of execution, but any such
error handling for an actual timeout is better handled at the call
site, as a context-less "got timeout" at STDERR or journal is really
not helpful.
I checked all call sites of both, run_fork_with_timeout and
run_with_timeout most do not use the result at all, and the ones that
do are in scalar context.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Fiona Ebner [Wed, 14 Jun 2023 13:05:58 +0000 (15:05 +0200)]
syslog: interpret priority level 'warn' correctly
There are some use sites, e.g. HA manager, pvescheduler that
incorrectly use priority level 'warn'. Likely because that is allowed
for some other log helpers in the codebase. Instead of fixing them all
one-by-one, simply allow 'warn' as a priority too.
Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com> Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Friedrich Weber [Tue, 13 Jun 2023 13:04:25 +0000 (15:04 +0200)]
ldap: fail authentication if dn is empty
This fixes an issue with LDAP servers that accept anonymous binds with
a non-empty password: If a user exists in the PVE LDAP realm, but PVE
cannot find the corresponding LDAP entry during login, they could log
in with any non-empty password.
This issue affects only LDAP realms. AD realms are not affected
because they perform no username->dn mapping.
At least the following LDAP server configurations seem to accept a
bind with empty DN and non-empty password and are affected:
* OpenLDAP with anonymous binds and the non-default setting
`olcAllows: bind_anon_cred` enabled.
* AD (when used in an LDAP realm instead of an AD realm). However, for
the issue to trigger, the LDAP search for the username->dn mapping
has to succeed but return zero results. This can happen, for
example, if the LDAP realm has (1) a bind DN set or (2) no bind DN
set and AD was manually configured to allow anonymous LDAP searches
for user entries.
The situation that a user exists in the PVE realm but is missing in
the LDAP directory can occur, for example, (1) if the user was created
manually or (2) if the LDAP entry is deleted or the base DN is
changed, but the LDAP realm has not been re-synced with
remove-vanished.
The username->dn mapping is performed by `get_user_dn`, which performs
an LDAP search. If the LDAP search for the user entry succeeds but
returns zero results (e.g. if the entry does not exist), `get_user_dn`
returns undef. Then, `auth_user_dn` is called with $dn being undef and
the user-provided $pw and performs an LDAP simple bind with these
credentials. If $pw is empty, Net::LDAP throws an error, but if it is
non-empty, it performs an LDAP bind with an empty DN and the password
provided by the user. If the LDAP server accepts this bind, the user
is logged in.
To fix this, `auth_user_dn` now dies/returns (depending on the $noerr
parameter) if the dn is falsy, which is the case for undef and the
empty string.
The issue was originally reported by forum user ITKR [0].
[0] https://forum.proxmox.com/threads/128788/
Suggested-by: Dominik Csapak <d.csapak@proxmox.com> Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com> Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
Thomas Lamprecht [Tue, 13 Jun 2023 05:12:06 +0000 (07:12 +0200)]
read firstline: only map ENOENT to undef, raise error otherwise
Errors like permission denied or I/O ones should bubble up, otherwise
it might hide serious issues and seemingly continue to work, with a
wrong state or the like.
One could argue that the case for not existent should return undef,
while an empty file should return an empty string, but for that we
might want to check all use-sites first.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Dominik Csapak [Tue, 6 Jun 2023 13:08:45 +0000 (15:08 +0200)]
JSONSchema: add support for array parameter in api calls, cli and config
a few things were missing for it to work:
* on the cli, we have to get the option as an array if the type is an
array
* the untainting must be done recursively, otherwise, the regex matching
converts an array hash into the string 'ARRAY(0x123412341234)'
* JSONSchema::parse_config did not handle array formats specially, but
we want to allow to specify them multiple time
* the biggest point: in the RESTHandler, to be compatible with the
current gui behavior, we have to rewrite two parameter types:
- when the api defines a '-list' format for a string type, but we get
a list (because of the changes in http-server), we join the list
with a comma into a string
- when the api defines an 'array' type, but we get a scalar value,
wrap the value in an array (because for www-form-urlencoded, you
cannot send an array with a single value) add tests for this
behavior, some of which we want to deprecate and remove in the
future
Fiona Ebner [Fri, 19 May 2023 09:18:16 +0000 (11:18 +0200)]
d/control: record dependency on libanyevent-perl
It's not just a build-dependency. Noticed during an sbuild of
qemu-server that would fail with, because it couldn't locate the
AnyEvent module used in RESTEnvironment.pm.
Thomas Lamprecht [Wed, 17 May 2023 08:23:20 +0000 (10:23 +0200)]
cli usage: remove extra newlines before descriptions
Reduce wasting vertical space for both, the command description and
the property description, just print the respective text at the next
line, with no extra empty line in between.
For better visual command separation color would help more.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Dominik Csapak [Mon, 27 Mar 2023 08:26:32 +0000 (10:26 +0200)]
fix #4615: REST environment: improve AnyEvent detectíon in child cleanup
I assumed that the 'priv' and 'pub' RESTEnvironment types always
contained an AnyEvent eventloop, but this is actually not the case in
pvestatd and pvescheduler.
But it depended on the used model that AnyEvent used (and auto
detected) if this wrong assumption worked or not. With the
AnyEvent::Impl::Perl there weren't any problems and it seemingly
worked by accident, but when using AnyEvent::Impl::EV (which is
autodetected and used when libev-perl is installed) it interfered
with our SIG_CHLD handlers and only ever called them once. (Not clear
why this happens, maybe because AnyEvent is not setup correctly).
This patch uses $AnyEvent::MODEL as a detection instead since this is
`undef` until the first AnyEvent watcher is created, which should be
only the case where we really use AnyEvent, such as pveproxy and
pvedaemon.
Fixes: 6870afa ("RESTEnvironment: better SIGCHLD handling in AnyEvent event loop") Link: https://lists.proxmox.com/pipermail/pve-devel/2023-March/056057.html Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com> Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
print_errs (which is also called internally by die_now) will only
'warn' the collected error stack if the log level is set to tracing.
otherwise, it will just return the error message(s) corresponding to
the error stack as string.
while they are not always the most user-friendly ones, they do
provide additional context that might help to find out what is
actually causing a particular failure. both helpers here actually
provide a meaninful user friendly context (via $msg) as final line.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
[ T: resolve merge conflict due to dropped warn helper ] Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Dominik Csapak [Mon, 20 Feb 2023 10:08:28 +0000 (11:08 +0100)]
RESTEnvironment: better SIGCHLD handling in AnyEvent event loop
when we're in an API server that uses AnyEvent, we must postpone
the worker_reaper, since it calls 'active_workers' which might already
be called and then we're inside the lock twice (flocks are per process
for us, see PVE::Tools::lock_file)
This resulted in an error like this:
close (rename) atomic file '/var/log/pve/tasks/active' failed: No such file or directory
We use the fact that only 'pub' and 'priv' RESTEnvironment types are an
api server with anyevent. For other types we call it like before.
Christian Ebner [Wed, 11 Jan 2023 13:32:20 +0000 (14:32 +0100)]
tools: Add callback based filtering for logfile dump
This patch introduces callback based filtering functionality for logfile dumps.
Further, the `dump_logfile` function is split into a reusable part for dumps
generated based on a filehandle. The state parameter can be used to keep the
state for multiple consecutive function invocations.
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
The dump_logfile now returns the whole log file if the limit
parameter is set to 0. This must be done explicitly though, as in the
case of 'limit' being undefined, the default as before, 50 will be
used.
Signed-off-by: Daniel Tschlatscher <d.tschlatscher@proxmox.com>
Dominik Csapak [Thu, 10 Nov 2022 10:36:30 +0000 (11:36 +0100)]
PBSClient: file_restore_list: add extraParams and use timeout
under some conditions, like when calling it in the api where we have
a 30s pveproxy limit, we want to make use of the '--timeout' parameter
of the file-restore binary, but we may want to call it in the future
where we don't want add timeout.
To achieve that, add an extendable 'extra_params' hash parameter to
'file_restore_list' and use the timeout from there.
Thomas Lamprecht [Sun, 13 Nov 2022 14:48:22 +0000 (15:48 +0100)]
d/control: record breaks for older qemu-server/pve-container
as we now auto-detect if the 'bridge-disable-mac-learning' is set in
the Network::tap_plug method and disable learning if so, we need to
ensure that the qemu-server and pve-container can cope with that by
manually registering the guests MAC into the FDB.
So this certainly isn't a hard break, but as network is dead for the
guest on update, if that option is set and the new qemu-server and/or
pve-container packages ain't yet updated, it seems still worthy of a
break.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
projects / pve-common.git / log