The old format used 16 base32 chars or 40 hex digits. Since they have
a common subset it's hard to distinguish them without the our
previous length constraints, so prefix a 'v2-' of the format to
support arbitrary lengths properly.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
move it from qemu-server as it was also used in pve-container and
pve-manager (pvesr), while guest-commons AbstractConfig could be a
fit too, just move it here as all depending on this already use
JSONSchema and it just fits here...
Break respective qemu-server version
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
MAC-addresses having the LSB of the first octet set, are considered
multicast-addresses (see [0,1]).
the 'mac-addr' format got changed to only permit unicast addresses, which should
work for its current use-case (WOL for nodes).
additionally a default option was registered via register_standard_option to be
used in both PVE::LXC::Config and PVE::QemuServer.
[0] https://lists.linuxcontainers.org/pipermail/lxc-users/2010-August/000783.html
[1] https://en.wikipedia.org/wiki/MAC_address
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
now allows:
* addresses without tld (f.e. user@localhost per bug)
* remove limits for number of subdomains
* allow +, -, ~ in local part
* disallow double dots (.. .a. etc) and dots in the end (abc.@mail.com)
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Acked-by: Dominik Csapak <d.csapak@proxmox.com>
we have a param_mapping now, with which we can impement that
e.g. instead of using:
sub read_password {
# read password
}
we can do:
sub param_mapping {
my ($name) = @_;
my $password_map = ['password', sub{
# read password
}, '<password', 1];
my $mapping = {
'apicall1' => [$password_map],
'apicall2' => [$password_map],
...
};
return $mapping->{$name};
}
this has the advantage that we can use different subs for different
api calls (e.g. pveum passwd vs pveum ticket)
if a CLIHandler implemenation still has a read_password sub and no
param_mapping, we generate one for them with read_password as the
sub for the standard mapping 'pve-password'
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Instead of hardcoding 'password' as a special case in the
JSONSchema's getopt handling, extend the new parameter
mapping to allow defining a parameters as 'interactive'.
They also take an optional argument on the command line
directly.
This effectively deprecates the password special case which
should be replaced in pct/pveum/... and then dropped in
pve-common.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
get_options is for parsing CLI options, here we decode after using
Getopt as we are not sure how well it handles already decoded data.
But as Gettopt can produces references for the parsed data we must
handle them explictily.
So check if we have a ARRAY or SCALAR reference and decode them
respectively.
All other reference types should not get returned from Getopt so
error out on them.
This bug was seen when viewing backup jobs, as we save the job as a
comand entry in /etc/pve/vzdump.cron and parse it then with this
function on reading.
Besides the use there we use it in the RESTHandler Packages
cli_handler sub method, so some CLI tools could be possibly affected
by this.
Fixes: 24197a9f6c
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
While our code currently passes the format hashes directly,
some code gets them via the format property of a
configuration description which verifies successfully via
check_format() for named property string formats, so this
should be allowed.
The 'pattern' property has type string and format regex, so
it makes sense to allow Regexp objects to be used for it.
While check_type() doesn't know the format, Regexp objects
can be treated like strings anyway, including compared via
'eq' or matched via '=~', so we allow strings to generally
come from a Regexp object.
Since we already allow this for container IP addresses it is
reasonable to assume the host might be using such a setup as
well. (You can use an additional route to reach the gateway
and then simply have no "LAN".) Some people seem to want
this...
Use case: networks for kvm use a <model>=<macaddr> scheme
where the model represents the network card. The schema
previously could not represent this, so we now introduce a
'group' key which works similar to an alias with the
difference that the data structure also gets an entry named
after the group filled with the name of the key that was
used to fill it.
Usage:
{
virtio => { group => 'model' },
e1000 => { group => 'model' },
model => {
type => 'string',
pattern => ... # pattern for mac address
...
}
}
Now the string 'virtio=aa:bb:cc:dd:ee:ff' gets parsed into:
{
model => 'virtio',
virtio => 'aa:bb:cc:dd:ee:ff'
}
Error examples:
With bad value:
virtio: value does not match the regex pattern
Missing group:
model: property is missing and it is not optional
parse_net() however used the 'macaddr' key for the mac
address, which can be achieved by aliasing 'model' to
'macaddr':
{
virtio => { group => 'model' },
e1000 => { group => 'model' },
model => { alias => 'macaddr' },
macaddr => {
type => 'string',
pattern => ... # pattern for mac address
...
}
}
Then the above string will be parsed into:
{
model => 'virtio',
macaddr => 'aa:bb:cc:dd:ee:ff'
}
The error output now always shows the 'macaddr' key:
Error examples:
With bad value:
macaddr: value does not match the regex pattern
Missing group:
macaddr: property is missing and it is not optional
In order to support specifying no mac address we can now set
model.default_key = 1 and macaddr.optional = 1.
That way `virtio,bridge=vmbr2` gets parsed correctly into
just a model with no macaddr. This works because default
keys as aliases have previously not been supported and would
not have been aliased accordingly. This case is now also
taken into account when printing default keys, which is now
skipped if it is also an alias.
