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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
There are differences for error handling in the old and new helper, in
particular when the child is signaled. But the test here does not
explicitly check for specific error conditions or messages and is
therefore still correct with the new helper.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
The exit code of the test would be the exit code of the 'rm' system
call, no matter if the test itself failed or not. Use an eval block
instead of the END block and propagate the error correctly.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
This is allowed in ifupdown2 and previously interfaces named
'vmbr\d+' were recognized as bridges even if they used this mode.
With commit e68ebda4f1 this is no longer the case.
Fixes: e68ebda4f1 ("fix #545: interfaces: allow arbitrary bridge names in network config")
Signed-off-by: Wolfgang Bumiller <w.bumiller@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>
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>
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>
enables section configs in the style of:
----
type: id
property value
property value2
property value3
----
can be combined with property strings
the provided create and update schema just pass through the array type
to the api, so the api call must always contain the complete array
also adds a test case for such array fields
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
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
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
as often only warn really makes it out of perl/our pit of std out/err
handling (e.g., I had a case where neither print STDERR nor syslog
worked, but warn did)
also, the tests are rather brittle w.r.t their expect_fail variant,
as the actual expected error should be enforced.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
by replacing the parsing code and 'compute_next_event' by their
PVE::RS::CalendarEvent equivalent
adapt the tests, since we do not have access to the internal structure
(and even if we had, it would be different) and the error messages
are different
the 'compute_next_event' and parsing tests still pass though
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
commit c86cfb8bbd dropped allow-hotplug
from the primary interfaces file completely on write, but that breaks
setups that come from plain Debian.
Instead, as stop-gap measurement, transform "allow-hotplug" to auto
in the PVE controlled config.
That avoids conflict and improves installing PVE on top of plain
Debian, as the interface still comes up after the first reboot.
But it is not ideal auto is not the same as hotplug, so we need to
also track that difference in the future, but that needs some
adaptions in the API too (change autostart from boolean to
string+enum or so=
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Currently, bond slaves are mostly working without autostart,
because bond slaves scripts from ifupdown1 && also ifupdown2
have some kind of hacks to start the slaves.
But if users want to do some tuning on the ifaces, they are not applied.
Also, with ifupdown2 + ovs, this kind of hack is not implemented (yet), so the
slaves of the bond are still down.
Debian/Ubuntu official docs always set "auto ethX" for bond slaves,
it's really more clean like this.
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
This should bring back compatibillity in the read site and one for
all clears that cidr is cidr, netmask is mask and address is address
(outgoing).
We're still very flexible on what can be written out.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
write changes some parts of the config, if this is a reference to the
config used for checking parsing it may lead to unexpected failures
due to those side effects..
For me it was "cidr" and "cidr6" getting deleted, and thus upcomming
tests for a compat change failing without any apparent reason.. :/
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
fixes commit 78c6656c9aba1d57786f916717c2622a3059fb6 which dropped
writing out the netmask but missed to add compat code for the case
where the caller did not suplly a address in CIDR format already.
Check if an address ends with /\d+, if not see if a netmask is
available and add that similar how it gets handled on read.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Reviewed-By: Stoiko Ivanov <s.ivanov@proxmox.com>
Tested-By: Stoiko Ivanov <s.ivanov@proxmox.com>
netmask/broadcast options are deprecated since buster
https://manpages.debian.org/buster/ifupdown/interfaces.5.en.html
This still read both "old address/netmask" or "address cidr" format,
but always convert it to cidr address format
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
And add eth2/3 to /proc/net/dev, that way we don't need to
create them "virtually" (which we shouldn't, for physical
interfaces).
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
also check if mtu value is lower than parent interface
fixme: vxlan interface should be 50bytes lower than outgoing interface
we need to find which interface is used (unicast/multicast/frr)
