通过命令行执行时,virtctl起作用,而不是从php exec()执行
我正在尝试运行kubectl virt命令,以通过PHP管理我的虚拟机。首先,我使用phpseclib登录使用以下代码的服务器:
$ssh = new SSH2('localhost');
if (!$ssh->login('root', 'rootPassword')) {
throw new \Exception('Login failed');
}
此部分正常运行,当我尝试运行$ ssh-> exec('Whoami& echo $ path'),我将获得以下输出:
root
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
但是,每当我尝试通过PHP运行kubectl virt
时,我都会得到以下输出:
error: unknown command "virt" for "kubectl"
kubectl
和kubectl virt
当我通过终端运行它们时,工作正常,但不知何故与PHP Exec()不使用。我还尝试通过终端检查$ path
,我得到了不同的输出:
/root/.krew/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
我认为这可能是因为$ path
,但有趣的部分是我尝试尝试运行sudo kubectl virt
通过终端我也会遇到相同的错误:
error: unknown command "virt" for "kubectl"
那时,我完全迷失了,甚至不知道在哪里寻找问题。我感谢所有答案。
I am trying to run kubectl virt commands to manage my virtual machine via PHP. First, I log in to my server with phpseclib with the following code:
$ssh = new SSH2('localhost');
if (!$ssh->login('root', 'rootPassword')) {
throw new \Exception('Login failed');
}
This part works fine, and when I try to run $ssh->exec('whoami && echo $PATH')
, I get the following output:
root
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
But, whenever I try to run kubectl virt
via PHP, I get the following output:
error: unknown command "virt" for "kubectl"
kubectl
and kubectl virt
work perfectly fine when I run them via terminal but somehow do not work with PHP exec(). I also tried to check the $PATH
via terminal and I get a different output:
/root/.krew/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
I thought that it may be because of $PATH
but the interesting part is when I try to run sudo kubectl virt
via terminal I also get the same error:
error: unknown command "virt" for "kubectl"
At that point, I am completely lost and don't even know where to look for a problem. I am thankful for all the answers.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
当您发出临时SSH命令时,您不会使用Interactive shell,并且根据您的默认外壳行为,它可能会或可能不会加载.bashrc文件。请参阅 https://serverfault.com/questions/questions/936746/bashrc-is-not -sourced-on-ssh-command 和运行命令通过SSH运行.bashrc?有关更多详细信息。
因此,默认情况下,krew修改您的
路径
变量,并附加它是bin路径,即我的配置包含export path =“ $ {krew_root: - $ home/.krew}/bin: $ PATH“
。但是Kubectl插件到底是什么?通常,它只是一个二进制文件,带有kubectl- plugin_name 名称。因此,通过调用哪个kubectl-virt
您可以轻松地知道您的virt二进制位置并直接调用它,因此类似方法的
方法是独自修改路径,设置
path = $路径:〜/.krew/bin
应该使它起作用,至少在我的情况下效果很好。
您可以尝试在外壳配置中强制加载.bashrc,但是我个人认为这是一个不好的做法,而SSH命令通常不会是出于某种原因加载RC文件,命令执行速度和系统之间的一致性是第一个来源头脑。
关于sudo,实际上并不令人惊讶,因为没有
-e
或-i
标志,它不会加载您当前的环境/不会启动交互式壳。参见 https://unix.stackexchange.com/questions/questions/228314/sudo-command -doesnt-source-root-bashrc 有关更多信息When you are issuing ad-hoc ssh commands, you are not using interactive shell, and depending on your default shell behavior it may or may not load your .bashrc file . See https://serverfault.com/questions/936746/bashrc-is-not-sourced-on-ssh-command and Running command via ssh also runs .bashrc? for more details.
So by default, krew modifies your
PATH
variable, and appends it's bin path to it, i.e. my config containsexport PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH"
. But what exactly is kubectl plugin? Usually it's just a single binary, with kubectl-plugin_name name. So by invokingwhich kubectl-virt
you can easily know where is your virt binary located and invoke it directly, so something likeshould work
The other way is to modify PATH all by yourself, setting
PATH=$PATH:~/.krew/bin
should make it work, at least in my caseworked nicely.
You can try to force loading of .bashrc in your shell configuration, but personally i think it's a bad practice, and ssh commands are not usually loading rc files for a reason, command execution speed and consistency between systems are the first things that come to mind.
Regarding sudo, it's actually not that surprising, because without
-E
or-i
flags it won't load your current environment / won't start interactive shell. See https://unix.stackexchange.com/questions/228314/sudo-command-doesnt-source-root-bashrc for more info