通过命令行执行时,virtctl起作用,而不是从php exec()执行

发布于 2025-01-27 03:48:36 字数 1051 浏览 1 评论 0原文

我正在尝试运行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"

kubectlkubectl 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

北座城市 2025-02-03 03:48:36

当您发出临时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二进制位置并直接调用它,因此类似方法

$ssh->exec('~/.krew/bin/kubectl-virt')

方法是独自修改路径,设置path = $路径:〜/.krew/bin应该使它起作用,至少在我的情况下

ssh localhost 'PATH=$PATH:~/.krew/bin kubectl virt'

效果很好。

您可以尝试在外壳配置中强制加载.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 contains export 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 invoking which kubectl-virt you can easily know where is your virt binary located and invoke it directly, so something like

$ssh->exec('~/.krew/bin/kubectl-virt')

should work

The other way is to modify PATH all by yourself, setting PATH=$PATH:~/.krew/bin should make it work, at least in my case

ssh localhost 'PATH=$PATH:~/.krew/bin kubectl virt'

worked 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

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文