Packer on Fedora Crashes; Permission issues with Cracklib

[plombardi89]

$ packer
/usr/share/cracklib/pw_dict.pwd: Permission denied
/usr/share/cracklib/pw_dict: Permission denied

Running a packer built from source, but I also saw the issue on 0.5.2 downloaded from the website.

Running packer --version, --help, build just causes packer to hang and never return.

Some system information:

$ 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

[mitchellh]

What even is cracklib?

[mitchellh]

Can you try to attach the output of PACKER_LOG=1 packer. That might help.

[plombardi89]

PACKER_LOG=1 doesn't seem to do anything. Seems the system just hangs completely when trying to run packer.

[plombardi@localhost packer]$ PACKER_LOG=1 packer
/usr/share/cracklib/pw_dict.pwd: Permission denied
/usr/share/cracklib/pw_dict: Permission denied
[plombardi@localhost packer]$ PACKER_LOG=1 packer --version
^C
[plombardi@localhost packer]$ PACKER_LOG=1 packer build foo
^C

[mitchellh]

At this point I'm going to say its likely an issue with your system somehow. Packer logs as the first thing it does: https://github.com/mitchellh/packer/blob/master/packer.go#L81 And this goes into the Go standard library.

One thing Packer does do prior to this is fork/exec once. Maybe that's it?

I can't debug this because I can't repro it (tried on Fedora and worked for me).

Please let me know if you find anything out, but I'm going to have to close this without any more info.

[Snides-MN]

The issue here is one I’ve run into before… to reproduce, “yum install cracklib-dicts” and let the dependencies drive getting the complete cracklib rpm set install.

The executable “/usr/sbin/packer” is provided as part of the cracklib-dicts package in Fedora/RHEL/compatible releases. So if you have the cracklib packages with full dictionary support installed on a system where you also run packer, executable file collision occurs. My fix has always been to rename the packer binary with Packer to “packer.io” on Linux builder systems, but you could perform some path variable manipulations.

Since I’m not the only person to run into this now, maybe an rename of the packer executable? It would be more of a no-brainer if packer had originally been named “cat” or “grep”, but this collision is no less irritating against the “who named an executable ‘packer’ first?” basis…

Thanks,
Mike

From: Mitchell Hashimoto [mailto:notifications@github.com]
Sent: Saturday, May 03, 2014 1:26 PM
To: mitchellh/packer
Subject: Re: [packer] Packer on Fedora Crashes; Permission issues with Cracklib (#1117)

At this point I'm going to say its likely an issue with your system somehow. Packer logs as the first thing it does: https://github.com/mitchellh/packer/blob/master/packer.go#L81 And this goes into the Go standard library.

One thing Packer does do prior to this is fork/exec once. Maybe that's it?

I can't debug this because I can't repro it (tried on Fedora and worked for me).

Please let me know if you find anything out, but I'm going to have to close this without any more info.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1117#issuecomment-42112584.

[bkochendorfer]

👍 Also running into this same issue on centos. Able to work around by renaming the packer bin.

[stardust85]

Also affected by this. What about renaming packer to packr? :)

[slapula]

I am also running into this and can confirm that renaming the bin is an effective workaround.

[moorooboorai-jeroen]

Yup. Same problem, CentOS 6.5. Added a symlink packer.io instead of renaming. Did the job equally well.

[gojihotsauce]

Just experienced the same issue on CentOS 6.5 The packer documentation needs to be updated to reflect this condition.

[rosstimson]

Just encountered this on a fairly clean install of Fedora 20.

[rcousens]

echo "export PATH=/path/to/packer:$PATH" >> ~/.bashrc

Puts packer directory at the front of your path resolution and fixes this for me on Fedora 20/CentOS7

[joejulian]

The "hang" is actually a read waiting on stdin. fwiw.

[bala-v]

Ran into this issue on Fedora 20.

/usr/sbin/packer ->symlink->cracklib-packer

used the workaround suggested to modify packer symlin in /usr/sbin to packer.io

[krizzo]

@bala-v the rename should be with this (mitchellh's packer) binary not the cracklib-packer symlink you changed the symlink for cracklib which did fix the name collision. You may experience anomalies in your system as applications expecting packer to be the cracklib-packer may fail. The best solution for now is what @rcousens suggested by putting the mitchellh packer path for your user ahead of the other one or renaming mitchellh's packer binary to packer.io.

Here is a simple one line command just change the variables for the latest version and also the path you want it installed.

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; unzip packer_temp_install.zip -d $PACKER_PATH; echo "export PATH=$PACKER_PATH:$PATH" >> ~/.bashrc

[dregin]

Hit this on a clean CentOS 7 install.

[xrow]

Please reopen. The naming conflict still exsits on CentOS 7. Unfortunatelly I would believe you shall rename the application. CrackLib was first in the space. "packer.io" might be a resonable name.

[e419]

packer.io +1

[SohamChakraborty]

Hit this exact same issue in F20. Ended up doing this

export PATH="$HOME/packer:$PATH:$HOME/.rvm/bin" # Add RVM to PATH for scripting

If the application cannot be renamed, I believe at least you should link this page from the documentation - Verifying The Installation - of packer, so as to give a fair warning to the readers/users.

[cbwest3]

FYI, I changed the path resolution order and ran into errors when attempting change/set passwords. A packer.io symlink will likely be my solution.

[Xiol]

This really needs to be in the documentation. Luckily Google brought me here.

[xrow]

@mitchellh Issue is not solved yet. Please reopen. Thanks.

[Xiol]

Opened PR 2483 to update docs to cover this.

I suspect that people are having issues reproducing this because they're using packer from wherever they extracted it, rather than dropping it into a directory that already exists in $PATH - in my case, /usr/local/bin on Fedora 22.

[ghost]

I have no idea why this is closed. Even worse you literally say, "not on my machine" - on a packer.io thread.
Furthermore, the fix presented doesn't work. My workaround is to use the full path.

[rickard-von-essen]

@luckyincode what does:

which -a packer

return?

[cbednarski]

Hey folks, we appreciate the feedback on this. Since we do not package packer for RHEL repos, we currently do not have plans to change the packer binary name.

When you install packer on your system you're free to rename the binary or place it another location to prevent this conflict. The name conflict and workaround is documented here.

[xrow]

This is fine with me someone shall write a SPEC file sometimes.

[strzibny]

Hi all, I made RPMs for Fedora/CentOS/RHEL that have this name renamed to packerio.

See this Copr:
http://copr.fedoraproject.org/coprs/jstribny/packer/

I wrote about it here:
http://nts.strzibny.name/fedoracentos-rpms-for-otto-project-packer-and-vault/

[strzibny]

@cbednarski Would you consider mentioning my Copr repos at https://packer.io/intro/getting-started/setup.html? Its essentially the same binaries you released but without the name conflict and coming as nice RPM packages.

[xrow]

@strzibny This is awesome. I don`t know if this already means that it will get included in EPEL, but that would be double awesome.

[strzibny]

@xrow it won't go to EPEL unless we do rebuilding from source...I actually tried to rebuild it for myself, but for Fedora/EPEL we would have to package all dependencies for the build time which might be a lot of work.

[joshpadilla]

#Steps to get Packer 0.8+ working
#Confirm OS platform (optional)
~:% cat /etc/release
CentOS release 6.7 (Final)

#Navigate to a dir for download
~:%cd ~/tmp

#Download Packer (Link changes w/ version numbers)
~:%wget https://releases.hashicorp.com/packer/0.8.6/packer_0.8.6_linux_amd64.zip

#Create Packer install directory, install it
~:%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

#Update your environment path, persistently
#Add Packer Path Location, append to end of existing path export
~:%vim ~/.zshrc

#Usually towards the end of my zshrc
export PATH=$PATH:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/git/bin:/usr/local/packer

#Source your ZSH session, don't have to logout
~:%source ~/.zshrc

#Rename Packer binary file due to name conflicts
#with CrackLib password packer packages
~:%sudo mv /usr/local/packer /usr/local/packer.io
~:%packer.io --version
0.8.6

#Perhaps in the future, Packer functionality will be rolled into Otto so at this point they may not think re-working the whole Packer namespace and file names is worth it. These work arounds may be necessary for a while, I guess.

[LongLiveCHIEF]

This is absurd. All this work, and the biggest problem I have using the tool so far is in the name. 👎

[carstn]

@LongLiveCHIEF Your biggest problem has been solved for you on the Install page. 👍

[LongLiveCHIEF]

@carstn apparently you forgot to read the pile of comments above.

[joejulian]

@LongLiveCHIEF but it's so much more fun to develop a tool that you have to defend when people complain that it doesn't work because you're too stubborn to just pick a name that isn't in use, right @carstn?

[LongLiveCHIEF]

In that case, I've totally been going about this open source thing the
wrong way the whole time.

I think I'll name my next project top.
On Feb 6, 2016 9:23 PM, "Joe Julian" notifications@github.com wrote:

@LongLiveCHIEF https://github.com/LongLiveCHIEF but it's so much more
fun to develop a tool that you have to defend when people complain that it
doesn't work because you're too stubborn to just pick a name that isn't in
use, right @carstn https://github.com/carstn?

—
Reply to this email directly or view it on GitHub
#1117 (comment).

[xrow]

I would no worry so much, since the problem can be fixed when being packed for that target platform (centos/rhel).

[jan-xyz]

Renaming the executable is not an option and I don't know how some of you can call it a "workaround". It completely breaks the tool if you use it in a team and others stick to the correct name. The only option I see is change the order of your $PATH.

echo $PATH shows you the order of your current setup and it usually looks something like that:
/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/jan/.local/bin:/home/jan/bin
since the cracklib version of packer is in /usr/sbin you just have to make sure that your version precedes it. That means either put it in a location that is before that (in the above case that is for example /usr/local/bin) or reorder the location that you are using to precede /usr/sbin.

As mentioned above by a few others you can achieve the reorder with:
export PATH=/your/path/to/packer:\$PATH and to make it permanent you can add this to your ~/.bashrc or whatever shell you are using.

[joshpadilla]

@PinguinXY, it's possible that a simple path re-order has some caveats. There may be some instances where you want to call the cracklib packer first for other programs and projects. I've found no problems so far with simply renaming the HC packer binary even when working with a team. There's plenty of other examples where we all follow a convention, especially in Maven projects.

It doesn't sound like you've actually tried other methods and seen any issues in practice. I think either method will work based on requirements and specific scenarios.

[jan-xyz]

@joshpadilla, I happened to run into problems and I would be running into problems every day if I had changed the name of the executable.

In our team we're working on different platforms and run packer from scripts that set up the environment and do some other logic that isn't part of packer. Since we are working cross platform it's no option to use absolute paths to the packer executable since it's not given that the install directory is the same on all operating systems. Changing the name of the executable on my machine to something else would break the script for others. Or, well, for me because I am the odd one.

I do see your point though, it depends on the use case. I was probably a bit volatile when I wrote my previous reply, my apologies.

[plaurin84]

+1 for packerio, as I got the conflict on my system (Fedora 23)

[ghost]

+1 for renaming solving the problem on Fedora 23. I renamed my binary to packer-cmd and it is located at ~/bin/packer-cmd. No issues now.

[malwarenights]

+1 for packer.io please

[jimsmith]

+1 rename place this has been an ongoing issue for us RHEL/CentOS users as /usr/sbin/packer for many many years as this binary is part of the cracklib-dicts RPM package, I'm still surprised this is news to Packer.io given the one below is older that 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        : @anaconda
Matched from:
Filename    : /usr/sbin/packer

[rickard-von-essen]

@jimsmith this is not new, it has been known since at least 2014.

IMHO there is a simple solution. Someone takes on to be the official Fedora/EPEL package maintainer and create a official (Fedora/EPEL) package and handles the conflict according to Fedoras guidelines for naming conflicts.

For us to change the name of a well known product would be very costly.

[avalaboju1s]

if you getting error like this in linux machines
/usr/share/cracklib/pw_dict.pwd: Permission denied
/usr/share/cracklib/pw_dict: Permission denied

try this method it will work

download the package
unzip it

move the file to /usr/local/

$ mv /path/packer /usr/local/

setting the packer path

vi ~/.bashrc
export PATH=$PATH:/usr/local/
source ~/.bashrc

linux machines already have a packer name package so you need to link the hash corp packers

sudo ln -s /usr/local/packer /usr/bin/packer.io

your packer is ready

packer.io

[manishsharma83]

avalaboju1s thanks, your solution worked for me.

[trmave]

if your stay here is because your are compiling from the source so you download from git and put a command make dev.
the origin of the problem is RedHat-based Linux distributions there is another tool named packer installed by default. You can check for this using which -a packer. If you get an error like this it indicates there is a name conflict.
source: packer.com part troubleshooting

the solution is download bin :https://www.packer.io/downloads.html
copy wherever you want for e.g /usr/local/packer
cp download/packer /usr/local/packer
and later
ln -s /usr/local/packer /usr/bin/packerum
//yes is other name

and fix it

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.