something like "vzctl exec" via API

[cle.ram]

Perhaps I missed something but I can't find anything comparable to "vzctl exec" in the API documentation. Is it not intended to execute commands directly in the openvz containers via the API and is there some other approach?

It would be nice to have something like:
create /nodes/{node}/openvz/{vmid}/exec "command"
which returns the exitcode and stdout/stderr

Of course it would not make sense for interactive commandline operations but it would be very helpful for the noninteractive ones.

 

[dietmar]

Perhaps I missed something but I can't find anything comparable to "vzctl exec" in the API documentation. Is it not intended to execute commands directly in the openvz containers via the API and is there some other approach?

So far there was no need for that.

It would be nice to have something like:
create /nodes/{node}/openvz/{vmid}/exec "command"
which returns the exitcode and stdout/stderr

I guess that should return a background task ID instead.

Of course it would not make sense for interactive commandline operations but it would be very helpful for the noninteractive ones.

Please file a bug (feature request) at bugzilla.proxmox.com

or start hacking yourself ;-) (see http://pve.proxmox.com/wiki/Developer_Documentation)

 

[cle.ram]

Thanks for your reply!

I've started to try the "hacking yourself" approach (at this stage without fiddling with git etc, because I just wanted to see if I get any promising result). I quickly found a point to start (PVE/API2/OpenVZ.pm in Git) and wrote some simple modifications (diff to the current stable-release "OpenVZ.pm": http://pastebin.com/Yj09XELp) which basically do the job. I've to add that I'm fairly new to the internal structure of proxmox and have never done anything with perl.

dietmar: could you elaborate on your idea of returning a background task ID? It's not quite clear to me what the benefits would be - Especially because in this case e.g. stdout/stderr has to be redirected *somewhere* and should be retrieved *somehow* afterwards.

Edit: Filed a bug (enhancement) for this: https://bugzilla.proxmox.com/show_bug.cgi?id=145

 

[dietmar]

dietmar: could you elaborate on your idea of returning a background task ID? It's not quite clear to me what the benefits would be - Especially because in this case e.g. stdout/stderr has to be redirected *somewhere* and should be retrieved *somehow* afterwards.

You are simply not allowed to run some long running task from the API daemon, because this would block the API (the number of processes is limited). So you simply span a background task, and return the task ID.

The good thing is that you have a complete log of such task stored.

Also, if you run such API call from a CLI tool, our library automatically put the task to foreground and pipes output to stdout.

 

[cle.ram]

I agree that this makes sense, thanks for the explanation. Can you point me to some direction (e.g. in the pve-manager code) where I see some code which implements this as a reference?

 

[dietmar]

I agree that this makes sense, thanks for the explanation. Can you point me to some direction (e.g. in the pve-manager code) where I see some code which implements this as a reference?

see PVE/API2/VZDump.pm

> return $rpcenv->fork_worker('vzdump', undef, $user, $worker);

 

[cle.ram]

Thanks - trying to adapt it accordingly.

 

[Don Daniello]

I think this is a definitely wanted feature. Imagine we create OpenVZ servers for clients from specially prepared appliances with a particular software installed.
We want to incorporate various task (eg. MySQL root password change) in client area. Without this API functionality it is impossible.

 

[cle.ram]

I don't know if I have enough resources for trying to properly implement this anytime soon or if it gets implemented by the Proxmox developers itself. If you want a hackish quick shot you can take a look at my patch located here, but I wouldn't recommend this for a production system (for the reasons dietmar pointed out).

Nevertheless you can alternatively rely on SSH Public Key auth to get a similar functionality. To achieve this you have just to integrate the pubkey into your container template (e.g. in root/.ssh/authorized_keys inside the archive). After deploying a container based on that template you can just execute commands via invocation of e.g. "ssh root@somemachine <command>".

 

[prologic]

Has there been an uptake on this feature by the ProxMox Dev team lately?