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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Similar to other interface types, we can detect a bridge by the
presence of its bridge_ports attribute, rather than solely relying on
the "vmbr" ifname prefix heuristic. For OVS bridges we need to examine
the OVS type instead.
The check needs to be moved up since other prefixes could
theoretically be included in a bridge name and then would otherwise
get picked up wrongly.
Also added a warning for interfaces named vmbrX that are not bridges
to catch possible misconfigurations.
Originally-by: Jillian Morgan <jillian.morgan@primordial.ca>
Reviewed-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
include 'PVEAPIToken=' prefix in the example for target-endpoint which
is mainly used for remote migrations.
Signed-off-by: Folke Gleumes <f.gleumes@proxmox.com>
$1 and friends are not cleared if a RE fails to match, in which case they will
contain the captured values from a previous successful match in the same scope.
deduplicate the two branches to avoid accidental re-introduction.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
makes the behaviour easier to analyze, and also helps when testing since it
allows constructing test cases that trigger certain order of parsing.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Even with just one param it's extra work to check what it refers too,
with named ones in a hash one hasn't that issue even with many params.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
more or less a copy from the normal section config test, but now with
properties defined multiple times as well as conflicting options
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
[ TL: improve consistency with property-isolation terminology ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
When using 'init(property_isolation => 1)', the code saves the
property lists per type instead of a big one, and using
create/updateSchema creates a new schema with the options as 'oneOf'
and/or 'instance-types' (depending if the schemas match).
With that, we change how we work with the options hash:
It's not needed anymore to specify options that are specified in the
type specific propertyList, except if it's 'fixed => 1' (since that does
not exist in the schema)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
[ TL: ensure consistency with new property-isolation terminology ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
a schema can now have the 'oneOf' property which is an array of regular
schemas. In the default case any of that has to match. If the
'type-property'/'instance-types' are given, only the schema for the specific
type will be checked (and handles as 'additionalProperties' if there is
no matching type)
the field found in 'type-property' has to be on the same level
(so for oneOf the nested schemas should not include that).
Documentation is adapted so that options are grouped per `type-property=value`
after the regular options (with their individual descriptions/types/etc.)
oneOfs without 'type-property'/'instance-tyeps' simply show up twice for
now with an 'or' line in between.
command line parsing is a bit weird for now since Getopt::Long
can't have multiple variants for the same property (but works fine with
pvesh for our current use cases). it gets shown as '--foo <multiple' if
they are not optional.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
to compare nested hashes/lists and scalar values recursively.
Also includes some tests
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
by simply doing an 'is_deeply' on the generated schema with
the current generated schema
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
`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>
so that we can get a 'tar.zst' from proxmox-file-restore by passing
'--format tar --zstd' to the file-restore binary
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
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>
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>
and not other errors too.
Fixes: a6aa0ae ("run with timeout: return if timeout happened in list context")
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
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)
Suggested-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
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..
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
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>
