fix #5141: network parser: fix accidental RE result re-use $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>
section config: allow full property-isolation for plugins 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>
json schema: implement 'oneOf' schema 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>
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>
pbs client: add 'tar' parameter to file_restore_extract 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>
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>
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>
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) Suggested-by: Fiona Ebner <f.ebner@proxmox.com> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
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>