Stoiko Ivanov [Mon, 18 Jun 2018 08:18:01 +0000 (10:18 +0200)]
add print_text_table, print_entry to CLIHandler
These two function could serve as a generic output sub for various CLI
utilities
* print_text_table prints an array of objects in a tabular fashion,
the formating is passed as an array containg hashes with titles, maximal
lengths and default values. This way we can stay extensible, by adding other
keys to the formatting options
* print_entry prints out a single entry, handling array-refs as properties
Dietmar Maurer [Mon, 11 Jun 2018 09:23:19 +0000 (11:23 +0200)]
api_dump: add $raw_dump options
Allow to return the original tree with all refs. We use this
with our new pveclient which needs the full api definition.
Keeping refs makes it possible to store the tree more efficiently.
First: resolve_cmd no longer keeps a hash of which arguments
were expanded. This information is not required and not used
properly: For one it would conflict if the same word
appeared twice in a longer subcommand, and secondly we lose
the information when recursing into an alias anyway. And
lastly, we do not support tab completing multiple parameters
simultaneously anyway (as in, `pveum u a<tab>` does not
become `pveum user add`).
So now we simply return the expanded version of the last
command or undef if it was unknown in place of the hash we
returned previously.
The second change is how we use the new returned value:
Previously if resolve_cmd() returned a new subcommand in
$def we skipped over finishing the last word. Of course, if
the command was already fully specified (but no space put
after it), we already considered it complete and returned
the new $def.
This condition can be detected as in this case the $prev
command equals the $cur command. (Additionally, the $cur
command is either '' (after the space) or also the $prev
command (before the space), but checking this would only be
required when the same word can actually appear multiple
times in a row in a sub command chain...)
This case now takes precedence over looking through the
nested $def, so that bash will put the space after a full
command which requires another subcommand to be added.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
We cannot properly encode blessed objects as json, so
instead, we should stringify them. This happened for
instance if a VM's systemd scope wasn't cleaned up as we
got an error as a Net::DBus::Error object causing a
"malformed json string" error to appear instead of the
actual message.
Additionally, add a 'must_stringify' helper: The above error
object implements a '""' operator for stringification (as
all error should), but in theory that could die as well, in
which case we just return a generic error string we'll
hopefully never see...
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Not only because <=> is correct, but using 'cmp' also has
the side effect that it adds a string version to the
variable and the API's json output turns into a string as
well, and this only happens once a task has completed
(while it's an integer while it's still running...)
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
this implements those parts of draft-ietf-acme-acme-09 which are needed
to use Let's Encrypt's v2 API.
(based on an internal implement for the Let's Encrypt v1 API) Co-Authored-By: Wolfgang Bumiller <w.bumiller@proxmox.com> Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
cli: more generic interactive parameter definition
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>
track our command string, i.e. everything which cannot be an argument
for a specific command, in resolve_cmd, as we go through the commando
definition there anyway and know if a ARGV element is part of the
command itself or its arguments.
Fixes a problem where a invalid command had all the passed parameter
attached in the resulting USAGE output.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
the timegm(gmtime()) and timelocal(localtime(()) constructs are
problematic in the following case: - $last is such that $year gets set
to a two-digit value (e.g., the referred to timestamp is somewhere in
the range of 1900-1999) - the current date is such that the value of
$year gets interpreted wrongly (e.g., anything other than 1950).
the exact breakage depends on the actual current date AND value of
$last, since localtime/gmtime will interpret two-digit years as (perldoc
Time::Local):
[...] shorthand for years in the rolling "current century," defined
as 50 years on either side of the current year. Thus, today, in
1999, 0 would refer to 2000, and 45 to 2045, but 55 would refer to
1955. Twenty years from now, 55 would instead refer to 2055.
fix it by adding 1900 to force 4-digit $year values, as the localtime
documentation suggests.
cli: allow specifying sub commands through $cmddef
allow to use sub commands alá
# pveum user add
The new resolve_cmd traverses $cmddef, resolves one level of aliases
and returns the respective sub command, its cmddef, arguments and if
it was expanded (e.g., pveum u d ... => pveum user delete ...) which
allows quite easy integration in the usage/synopsis generator, bash
completion helper and command handler.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
fork_worker: use correct handle type for POSIX::write
$resfh can be a pipe from POSIX::pipe() or the upid output
handle, which is an IO::File, so we need to take its
fileno().
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com> Fixes: ed52a8435a6d ("fork_worker: use separate pipe for status messages") Reviewed-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thomas Lamprecht [Tue, 19 Dec 2017 10:50:16 +0000 (11:50 +0100)]
run_command: add 'quiet' parameter for omitting STD* prints
Without this patch we printed to STDOUT and STDERR, respectively, if
no $outfunc or $errfunc was passed.
Sometimes it's useful if one, or even both, of those prints can
be suppressed, currently this can only be done by either using an array
of arrays or a whole string for the command and redirecting STDOUT
and STDERR.
Add a 'quiet' option which allows to do this in an easier way.
It allows to silent STDERR or STDOUT or both.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thomas Lamprecht [Fri, 15 Dec 2017 16:00:31 +0000 (17:00 +0100)]
fork_worker: factor out synced worker output mirroring
When running in sync (CLI environment) we mirror the workers output
to both, STDOUT and th task log file, a similar function as the unix
comand line tool tee provides, thus we borrow its name for the
factored out sub method.
This moves ~60 lines of code out of the big fork_worker sub and makes
it easier to read track what happens there.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thomas Lamprecht [Fri, 15 Dec 2017 16:00:30 +0000 (17:00 +0100)]
fork_worker: use separate pipe for status messages
We forced line wise flushing of the workers STDOUT and STDERR to
capture the final status (TASK OK/TASK ERROR).
Thus, if the code executed in the worker wanted to flush explicitly,
e.g., when the last output wasn't new line terminated but needed to
reach the users eyes, the parent just ignored that.
This leads to confusing results in CLI handlers using fork_workers.
So remove the buffering logic completely and introduce a separate
pipe for sending the final status.
Said pipe gets once read after the child closes (EOF) its STDOUT.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thomas Lamprecht [Fri, 15 Dec 2017 16:00:29 +0000 (17:00 +0100)]
fork_worker: refactor passing $upid to parent for sync
STDOUT and $psync[1] are the same here, so no need to differ.
Also we do this only for letting the parent know tha we're ready, the
parent knows the UPID already as it was generated before forking.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thomas Lamprecht [Fri, 15 Dec 2017 05:41:49 +0000 (06:41 +0100)]
ticket: raise UNAUTHORIZED not FORBIDDEN in verify subs
In the ticket and CSRF prevention token verification methods we used
a raise_perm exception to tell our caller about a failure of such a
verification. raise_perm uses HTTP_FORBIDDEN (403) as code.
Earlier, all such exceptions or die's where caught when the anyevent
http server called the auth_handler method and transformed to
HTTP_UNAUTHORIZED (401).
With commit d8327719e353198a1dffad88c246fee065054a6b from
pve-http-server we gained the ability to tell a client about a server
internal 5XX error, so that clients do not get wrongly logged out if
we have a internal error.
This resulted also in the effect that the exceptions of the
verify_rsa_ticket and verify_csrf_prevention_token sub methods where
passed to the client.
If an old, now invalid, ticket was sent to the server a client got
403 (FORBIDDEN) instead of the 401 (UNAUTHORIZED) - which he was used
to, and thus meant that he did some wrong doing, instead of knowing
that he just needs to login.
As we are not yet logged in here, and thus cannot possibly know if
the call is forbidden or not, HTTP_FORBIDDEN seems the wrong code.
Change it to HTTP_UNAUTHORIZED, which restores it to the code we told
API clients since ever and is the correct one here.
Also RFC 2068 section 10.4.4 [1] defines that for the afformentioned
verify methods FORBIDDEN was not really correct:
> 403 Forbidden
>
> The server understood the request, but is refusing to fulfill it.
> Authorization will not help and the request SHOULD NOT be
> repeated. [...]
With a invalid ticket or CSRF prevention token we have a
authorization problem for the current call, not a permission problem
(we may have, but we can't tell yet).
* Cancel on Ctrl+C (die())
* Finish on Ctrl+D (eof/eot) without appending a newline
* Also finish on \n to be sure.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com> Reviewed-by: Thomas Lamprecht <t.lamprecht@proxmox.com> Tested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Most times a port was requested for a specified IP family (v4, v6)
only. Thus also ensure that the port from the respective family got
ready, else we may return on a false positive.
As we had no user setting the $timeout param we can add the $family
param as second one, it'll get used more often, so no need to put it
at the back.
As we do nothing if not defined this does not changes the behavior of
our users yet.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
projects / pve-common.git / log