$包装工
/usr/share/cracklib/pw_dict.pwd:权限被拒绝
/usr/share/cracklib/pw_dict: 权限被拒绝
运行从源代码构建的打包程序,但我也看到了从网站下载的 0.5.2 上的问题。
运行 packer --version, --help, build
一些系统信息:
$ uname -a
Linux localhost.localdomain 3.13.9-200.fc20.x86_64 #1 SMP Fri Apr 4 12:13:05 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
什么是cracklib?
您可以尝试附加PACKER_LOG=1 packer
的输出吗? 那可能会有所帮助。
PACKER_LOG=1 似乎没有做任何事情。 似乎系统在尝试运行打包程序时完全挂起。
[ plombardi@localhost 打包程序]$ PACKER_LOG=1 打包程序
/usr/share/cracklib/pw_dict.pwd:权限被拒绝
/usr/share/cracklib/pw_dict: 权限被拒绝
[ plombardi@localhost 打包程序]$ PACKER_LOG=1 打包程序 --version
^C
[ plombardi@localhost packer]$ PACKER_LOG=1 packer build foo
^C
在这一点上,我要说它可能以某种方式与您的系统有关。 Packer 将其记录为 _first thing_: https :
Packer 在此之前做的一件事是 fork/exec 一次。 也许就是这样?
我无法调试它,因为我无法重现它(在 Fedora 上尝试过并为我工作)。
如果您发现任何问题,请告诉我,但我将不得不在没有更多信息的情况下关闭它。
这里的问题是我之前遇到过的问题……重现“yum install cracklib-dicts”并让依赖项驱动安装完整的cracklib rpm set。
可执行文件“/usr/sbin/packer”作为Fedora/RHEL/兼容版本中的cracklib-dicts 包的一部分提供。 因此,如果您在还运行打包程序的系统上安装了具有完整字典支持的cracklib 包,则会发生可执行文件冲突。 我的解决方法一直是在 Linux 构建器系统上使用 Packer 将打包器二进制文件重命名为“packer.io”,但您可以执行一些路径变量操作。
由于我现在不是唯一遇到这个问题的人,也许是打包程序可执行文件的重命名? 如果 packer 最初被命名为“cat”或“grep”,那就更不费脑了,但这种冲突同样对“谁首先命名了一个可执行的‘packer’?” 基础…
谢谢,
麦克风
来自:Mitchell Hashimoto [mailto:[email protected]]
发送:2014 年 5 月 3 日星期六下午 1:26
收件人:mitchellh/packer
主题: Re: [packer] Packer on Fedora Crashes; Cracklib 的权限问题 (#1117)
在这一点上,我要说它可能以某种方式与您的系统有关。 Packer 做的第一件事就是记录: https :
Packer 在此之前做的一件事是 fork/exec 一次。 也许就是这样?
我无法调试它,因为我无法重现它(在 Fedora 上尝试过并为我工作)。
如果您发现任何问题,请告诉我,但我将不得不在没有更多信息的情况下关闭它。
—
直接回复本邮件或在 Gi tHub上查看
:+1: 在 centos 上也遇到同样的问题。 能够通过重命名打包机箱来解决。
也受此影响。 将 packer 重命名为 packr 怎么样? :)
我也遇到了这个问题,可以确认重命名 bin 是一种有效的解决方法。
是的。 同样的问题,CentOS 6.5。 添加了符号链接packer.io
而不是重命名。 同样出色地完成了这项工作。
刚刚在 CentOS 6.5 上遇到了同样的问题 需要更新打包程序文档以反映这种情况。
刚刚在相当干净的 Fedora 20 安装中遇到了这个问题。
echo "export PATH=/path/to/packer:\$PATH" >> ~/.bashrc
将 packer 目录放在路径解析的前面,并在 Fedora 20/CentOS7 上为我修复此问题
“挂起”实际上是等待标准输入的读取。 fwiw。
在 Fedora 20 上遇到了这个问题。
/usr/sbin/packer ->symlink->cracklib-packer
使用建议的解决方法将 /usr/sbin 中的 packer symlin 修改为 packer.io
@bala-v 重命名应该使用此(mitchellh 的打包程序)二进制文件,而不是您更改了用于修复名称冲突的 cracklib 的符号链接的 cracklib-packer 符号链接。 您可能会在您的系统中遇到异常情况,因为希望打包程序成为裂纹库打包程序的应用程序可能会失败。 目前最好的解决方案是@rcousens建议的做法,打包程序路径放在另一个之前,或者将 mitchellh 的打包程序二进制文件重命名为 packer.io。
这是一个简单的单行命令,只需更改最新版本的变量以及您想要安装的路径。
PACKER_DOWNLOAD="https://dl.bintray.com/mitchellh/packer/packer_0.7.2_linux_amd64.zip"
PACKER_PATH="/usr/local/bin/packer"
mkdir -p $PACKER_PATH; wget $PACKER_DOWNLOAD -O packer_temp_install.zip; 解压 packer_temp_install.zip -d $PACKER_PATH; echo "export PATH=$PACKER_PATH:\$PATH" >> ~/.bashrc
在干净的 CentOS 7 安装上点击这个。
请重新打开。 CentOS 7 上仍然存在命名冲突。不幸的是,我相信您应该重命名该应用程序。 CrackLib 是该领域的第一个。 “packer.io”可能是一个合理的名字。
packer.io +1
在 F20 中遇到这个完全相同的问题。 结束了这个
export PATH="$HOME/packer:$PATH:$HOME/.rvm/bin" # 将 RVM 添加到 PATH 以进行脚本编写
如果应用程序无法重命名,我相信您至少应该从 packer 的文档 - 验证安装 - 链接此页面,以便给读者/用户一个公平的警告。
仅供参考,我更改了路径解析顺序并在尝试更改/设置密码时遇到了错误。 packer.io 符号链接可能是我的解决方案。
这确实需要在文档中。 幸运的是谷歌把我带到了这里。
@mitchellh问题尚未解决。 请重新打开。 谢谢。
打开 PR 2483 以更新文档以涵盖此内容。
我怀疑人们在重现这个问题时遇到了问题,因为他们在提取它的任何地方都使用了打包程序,而不是将其放入 $PATH 中已经存在的目录中 - 在我的情况下,Fedora 22 上的/usr/local/bin
。
我不知道为什么这是关闭的。 更糟糕的是,您从字面上说,“不在我的机器上”- 在 packer.io 线程上。
此外,提供的修复程序不起作用。 我的解决方法是使用完整路径。
@luckyincode 有什么作用:
which -a packer
返回?
我从which -a packer
得到以下信息
/usr/local/bin/packer/packer
/usr/sbin/packer
My.zshrc 文件有export PATH=/usr/local/bin/packer:$PATH
来解决这个问题。
在我的 Fedora 22 机器上,packer 是来自 cracklib-dict 的程序,由 pam_cracklib 使用,我们不能直接卸载,因为 systemd 包需要包。
建议的方法来解决这个问题
@krizzo方式我还没有尝试过。 :)
packer.io +1
@rickard-von-essen 抱歉耽搁了。
[ root@q-build-01 ~]# 哪个打包程序
/usr/sbin/packer
我也很抱歉不够明确。 我应该像@udomsak一样在回复中更加勤奋
问题当然是rhel中的cracklib-packer,它到处都用于创建密码
[root@q-build-01 ~]# ls -ltr /usr/sbin/packer
lrwxrwxrwx。 1 根 2013 年 1 月 4 日 15 日 /usr/sbin/packer ->cracklib-packer
我的解决方案是使用完整路径。
-E
packer.io +1
为什么关门了? 问题仍然存在并且在最新的 CentOS 7.1 中出现
我仍然在 Fedora 23 上看到这个问题。
嘿伙计们,我们感谢对此的反馈。 由于我们没有为 RHEL 存储库打包打包程序,我们目前没有计划更改打包程序二进制名称。
当您在系统上安装 packer 时,您可以自由地重命名二进制文件或将其放在另一个位置以防止这种冲突。 此处记录
这对我来说很好,有时有人会写一个 SPEC 文件。
大家好,我为 Fedora/CentOS/RHEL 制作了 RPM,将这个名称重命名为packerio
。
看到这个 Copr:
http://copr.fedoraproject.org/coprs/jstribny/packer/
我在这里写过:
http://nts.strzibny.name/fedoracentos-rpms-for-otto-project-packer-and-vault/
@cbednarski你会考虑在https://packer.io/intro/getting-started/setup.html 上提及我的 Copr 存储库
@strzibny这太棒了。 我不知道这是否已经意味着它将被包含在 EPEL 中,但这将是双重的。
@xrow除非我们从源代码重建,否则它不会转到 EPEL...我实际上尝试为自己重建它,但是对于 Fedora/EPEL,我们必须在构建时打包所有依赖项,这可能需要大量工作.
~:% cat /etc/_release_
CentOS 6.7 版(最终版)
~:%cd ~/tmp
~:%wget https://releases.hashicorp.com/packer/0.8.6/packer_0.8.6_linux_amd64.zip
~:%sudo mkdir -p /usr/local/packer; chmod -Rfv 700 /usr/local/packer
~:%sudo unzip packer_0.8.6_linux_amd64.zip -d /usr/local/packer
~:%vim ~/.zshrc
导出路径=$PATH:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/git/bin:/usr/local/packer
~:%source ~/.zshrc
~:%sudo mv /usr/local/packer /usr/local/packer.io
~:%packer.io --version
0.8.6
这是荒谬的。 所有这些工作,以及迄今为止我使用该工具的最大问题是名称。 :-1:
@LongLiveCHIEF您最大的问题已在安装页面上为您解决。 👍
@Carstn显然你忘了阅读上面的一堆评论。
@LongLiveCHIEF但开发一个工具更有趣,当人们抱怨它不起作用时你必须捍卫它,因为你太固执而不能只选择一个没有使用的名字,对吧@carstn?
在那种情况下,我一直在做这个开源的事情
一直走错路。
我想我会把我的下一个项目命名为 _top_。
2016 年 2 月 6 日晚上 9:23,“Joe Julian” [email protected]写道:
@LongLiveCHIEF https://github.com/LongLiveCHIEF但还有更多
开发一种工具很有趣,当人们抱怨它时,您必须捍卫它
没用,因为你太固执了,不能随便选择一个不在的名字
使用,对吗@carstn https://github.com/carstn?—
直接回复此邮件或在 GitHub 上查看
https://github.com/mitchellh/packer/issues/1117#issuecomment -180929822。
我不会太担心,因为在为该目标平台(centos/rhel)打包时可以解决问题。
重命名可执行文件不是一个选项,我不知道你们中的一些人如何将其称为“解决方法”。 如果您在团队中使用它而其他人坚持使用正确的名称,它会完全破坏该工具。 我看到的唯一选择是更改您的$PATH
的顺序。
echo $PATH
显示您当前设置的顺序,它通常看起来像这样:
/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/jan/.local/bin:/home/jan/bin
因为cracklib
版本packer
为/usr/sbin
你只需要确保你的版本先于它。 这意味着要么将其放在之前的位置(在上述情况下,例如 /usr/local/bin),要么将您使用的位置重新排序在/usr/sbin
。
正如上面其他一些人所提到的
export PATH=/your/path/to/packer:\$PATH
并使其永久化,您可以将其添加到您的~/.bashrc
或您正在使用的任何 shell 中。
@PinguinXY ,简单的路径重新排序可能有一些警告。 在某些情况下,您可能希望首先为其他程序和项目调用cracklib 打包程序。 到目前为止,即使在与团队合作时,我也没有发现简单地重命名 HC 打包程序二进制文件的问题。 还有很多其他的例子,我们都遵循一个约定,尤其是在 Maven 项目中。
听起来您实际上并未尝试其他方法并在实践中看到任何问题。 我认为这两种方法都可以根据要求和特定场景工作。
@joshpadilla ,我碰巧遇到了问题,如果我更改了可执行文件的名称,我每天都会遇到问题。
在我们的团队中,我们在不同的平台上工作,并从设置环境的脚本运行打包程序,并执行一些不属于打包程序的其他逻辑。 由于我们正在跨平台工作,因此无法选择使用打包程序可执行文件的绝对路径,因为没有给出所有操作系统上的安装目录都相同。 将我机器上的可执行文件的名称更改为其他名称会破坏其他人的脚本。 或者,对我来说,因为我是个奇怪的人。
不过我确实明白你的意思,这取决于用例。 当我写我之前的回复时,我可能有点不稳定,我很抱歉。
+1 for packerio,因为我的系统出现冲突(Fedora 23)
+1 用于重命名解决 Fedora 23 上的问题。我将我的二进制文件重命名为 packer-cmd,它位于 ~/bin/packer-cmd。 现在没有问题。
请为 packer.io +1
+1 重命名地方,这对于我们 RHEL/CentOS 用户来说一直是一个持续的问题,多年来一直是/usr/sbin/packer
,因为这个二进制文件是 cracklib-dicts RPM 包的一部分,我仍然很惊讶这对 Packer 来说是新闻.io 给出下面的那个比 packer.io 更旧 :)
cracklib-dicts-2.9.0-11.el7.x86_64 : The standard CrackLib dictionaries
Repo : base
Matched from:
Filename : /usr/sbin/packer
cracklib-dicts-2.9.0-11.el7.x86_64 : The standard CrackLib dictionaries
Repo : <strong i="7">@anaconda</strong>
Matched from:
Filename : /usr/sbin/packer
@jimsmith这并不新鲜,至少从 2014 年就知道了。
恕我直言,有一个简单的解决方案。 有人担任官方 Fedora/EPEL 包维护者并创建官方 (Fedora/EPEL) 包并根据 Fedoras 命名冲突指南处理冲突。
对我们来说,更改知名产品的名称将是非常昂贵的。
如果你在 linux 机器上遇到这样的错误
/usr/share/cracklib/pw_dict.pwd:权限被拒绝
/usr/share/cracklib/pw_dict: 权限被拒绝
下载包
解压
$ mv /path/packer /usr/local/
vi ~/.bashrc
导出路径=$PATH:/usr/local/
源 ~/.bashrc
须藤 ln -s /usr/local/packer /usr/bin/packer.io
打包机
avalaboju1s 谢谢,您的解决方案对我有用。
如果你留在这里是因为你是从源代码编译的,所以你从 git 下载并放置一个命令 make dev。
问题的根源在于基于 RedHat 的 Linux 发行版默认安装了另一个名为 packer 的工具。 您可以使用 which -a 打包程序来检查这一点。 如果出现这样的错误,则表明存在名称冲突。
来源:packer.com 部分故障排除
解决方案是下载 bin : https :
复制到任何你想要的地方,例如 /usr/local/packer
cp 下载/打包程序 /usr/local/packer
然后
ln -s /usr/local/packer /usr/bin/packerum
//是的,其他名字
我将锁定此问题,因为它已关闭 _30 天_⏳。 这有助于我们的维护人员找到并关注活跃的问题。
如果您发现与此类似的问题,请打开一个新问题并完成问题模板,以便我们可以获取进一步调查所需的所有详细信息。
最有用的评论
如果你在 linux 机器上遇到这样的错误
/usr/share/cracklib/pw_dict.pwd:权限被拒绝
/usr/share/cracklib/pw_dict: 权限被拒绝
试试这个方法它会起作用
下载包
解压
将文件移动到 /usr/local/
$ mv /path/packer /usr/local/
设置打包路径
vi ~/.bashrc
导出路径=$PATH:/usr/local/
源 ~/.bashrc
linux机器已经有一个packer name package,所以你需要链接hash corp packers
须藤 ln -s /usr/local/packer /usr/bin/packer.io
你的打包机准备好了
打包机