FOR BUGS:
Describe the problem and include the following information:
PACKER_LOG=1 packer build template.json
.The contents of private keys used for the chef client install, are displayed in packer's log output. This has the potential to migrate e.g. to log aggregators and generally be difficult to clean up. Bad security practice.
Nice catch. Looking at docs, this appears to be the default behavior for Chef: https://docs.chef.io/ctl_chef_client.html
but it also looks like we can fix it by changing the log-level from info
to warn
. If you add the config option "execute_command": "{{if .Sudo}}sudo {{end}}chef-client --no-color -c {{.ConfigPath}} -j {{.JsonPath}} -l warn",
does this still happen?
It does still happen with one of the keys. It looks like the packer
installer is trying to create a directory with the content of the secret
key as the directory name. Very strange behavior.
amazon-ebs: Executing Chef: sudo chef-client --no-color -c
/tmp/packer-chef-client/client.rb -j /tmp/packer-chef-client/first-boot.j
son -l warn
amazon-ebs: sudo: unable to resolve host ip-10-248-0-18
amazon-ebs: Starting Chef Client, version 14.5.33
amazon-ebs: Creating a new client identity for
packer-5bcf8c52-d88d-a844-bc1f-8b7040a97ecf using the validator key.
amazon-ebs:
amazon-ebs: Chef encountered an error attempting to create the client
"packer-5bcf8c52-d88d-a844-bc1f-8b7040a97ecf"
amazon-ebs:
amazon-ebs: System Info:
amazon-ebs: ------------
amazon-ebs: chef_version=14.5.33
amazon-ebs: ruby=ruby 2.5.1p57 (2018-03-29 revision 63029)
[x86_64-linux]
amazon-ebs: program_name=/usr/bin/chef-client
amazon-ebs: executable=/opt/chef/bin/chef-client
amazon-ebs:
amazon-ebs:
amazon-ebs: Running handlers:
amazon-ebs: [2018-10-23T21:02:26+00:00] ERROR: Running exception
handlers
amazon-ebs: Running handlers complete
amazon-ebs: [2018-10-23T21:02:26+00:00] ERROR: Exception handlers
complete
amazon-ebs: Chef Client failed. 0 resources updated in 01 seconds
amazon-ebs: [2018-10-23T21:02:26+00:00] FATAL: Stacktrace dumped to
/var/chef/cache/chef-stacktrace.out
amazon-ebs: [2018-10-23T21:02:26+00:00] FATAL: Please provide the
contents of the stacktrace.out file if you file a bug report
amazon-ebs: [2018-10-23T21:02:26+00:00] FATAL: Errno::ENAMETOOLONG:
File name too long @ dir_s_mkdir - /value=-----BEGIN RSA PRIVATE
KEY-----
amazon-ebs:
MIIEpAIBAAKCAQEAzAwqYBqTlcrankO9O6ZZENL5soMt8k+hf57rWYK9genuBsZM
amazon-ebs: REDACTED REDACTED REDACTED REDACTED REDACTED REDACTED
REDACTED w
amazon-ebs: REDACTED REDACTED REDACTED REDACTED REDACTED REDACTED
REDACTED +
amazon-ebs: REDACTED REDACTED REDACTED REDACTED REDACTED REDACTED
REDACTED C
amazon-ebs: REDACTED REDACTED REDACTED REDACTED REDACTED REDACTED
REDACTED e
amazon-ebs: REDACTED REDACTED REDACTED REDACTED REDACTED REDACTED
REDACTED /
amazon-ebs: REDACTED REDACTED REDACTED REDACTED REDACTED REDACTED
REDACTED v
amazon-ebs: REDACTED REDACTED REDACTED REDACTED REDACTED REDACTED
REDACTED E
amazon-ebs: REDACTED REDACTED REDACTED REDACTED REDACTED REDACTED
REDACTED h
amazon-ebs: REDACTED REDACTED REDACTED REDACTED REDACTED REDACTED
REDACTED F
amazon-ebs: REDACTED REDACTED REDACTED REDACTED REDACTED REDACTED
REDACTED Q
amazon-ebs: REDACTED REDACTED REDACTED REDACTED REDACTED REDACTED
REDACTED p
amazon-ebs: REDACTED REDACTED REDACTED REDACTED REDACTED REDACTED
REDACTED i
amazon-ebs: REDACTED REDACTED REDACTED REDACTED REDACTED REDACTED
REDACTED R
amazon-ebs: REDACTED REDACTED REDACTED REDACTED REDACTED REDACTED
REDACTED Y
amazon-ebs: REDACTED REDACTED REDACTED REDACTED REDACTED REDACTED
REDACTED f
amazon-ebs: REDACTED REDACTED REDACTED REDACTED REDACTED REDACTED
REDACTED k
amazon-ebs:
WwuvEPibkk+GGpVnpIxZUC5UUdSxvgwrJLtStwgPYWjYdOoDZ1YsLLhKBmcud
amazon-ebs: Creating configuration file 'knife.rb'
==> amazon-ebs: Cleaning up chef node...
On Wed, Oct 17, 2018 at 2:41 PM Megan Marsh notifications@github.com
wrote:
Nice catch. Looking at docs, this appears to be the default behavior for
Chef: https://docs.chef.io/ctl_chef_client.htmlbut it also looks like we can fix it by changing the log-level from info
to warn. If you add the config option "execute_command": "{{if
.Sudo}}sudo {{end}}chef-client --no-color -c {{.ConfigPath}} -j
{{.JsonPath}} -l warn", does this still happen?ā
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/packer/issues/6873#issuecomment-430799594,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ApFUr1ZhYdjsol9U6xYDjaLy89Cg_mVIks5ul6P_gaJpZM4XlKAR
.
--
CONFIDENTIALITY NOTICE: The information contained in this e-mail message
and any attachments is for the sole use of theĀ intendedĀ recipientsĀ and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not theĀ intendedĀ
recipientĀ and have received this communication in error, please contact the
sender by reply e-mail and destroy all copies of the original message.
Thank you.
I don't think this error has anything to do with a packer installer. The only command in that debug output that Packer is calling is sudo chef-client --no-color -c
/tmp/packer-chef-client/client.rb -j /tmp/packer-chef-client/first-boot.json -l warn
The rest is chef itself. Apart from changing our default log level to "warn" I really don't know what I can do to help you here.
Hold on. Are you providing the client key itself, or a path to the key? you should be providing a path.
@alex-gottschalk-roostify any update on this?
@alex-gottschalk-roostify I'm hoping to resolve this for the next release; have you had a chance to look into this further?
I'm going to close since it's been over a month since getting a response; if this is still an issue and it wasn't caused by confusion about whether to provide the key itself versus the path to a key, you can let me know here and I'll reopen.
Hi Megan, sorry I haven't been able to provide an update - we've gone with
chef-solo in packer as we don't need to track the inventory of packer
builder instances. For what it's worth, I do think that the initial
workaround of setting the client log level was a sufficient solution.
On Mon, Dec 3, 2018 at 4:19 PM Megan Marsh notifications@github.com wrote:
I'm going to close since it's been over a month since getting a response;
if this is still an issue and it wasn't caused by confusion about whether
to provide the key itself versus the path to a key, you can let me know
here and I'll reopen.ā
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/packer/issues/6873#issuecomment-443921162,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ApFUr4i63BM8MM2eaIFrHX4QHUsr-fInks5u1b-igaJpZM4XlKAR
.
--
+-----------------+
| Alex Gottschalk |
| Roostify DevOps |
+-----------------+
--
CONFIDENTIALITY NOTICE: The information contained in this e-mail message
and any attachments is for the sole use of theĀ intendedĀ recipientsĀ and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not theĀ intendedĀ
recipientĀ and have received this communication in error, please contact the
sender by reply e-mail and destroy all copies of the original message.
Thank you.
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.
Most helpful comment
Hi Megan, sorry I haven't been able to provide an update - we've gone with
chef-solo in packer as we don't need to track the inventory of packer
builder instances. For what it's worth, I do think that the initial
workaround of setting the client log level was a sufficient solution.
On Mon, Dec 3, 2018 at 4:19 PM Megan Marsh notifications@github.com wrote:
--
+-----------------+
| Alex Gottschalk |
| Roostify DevOps |
+-----------------+
--
CONFIDENTIALITY NOTICE: The information contained in this e-mail message
and any attachments is for the sole use of theĀ intendedĀ recipientsĀ and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not theĀ intendedĀ
recipientĀ and have received this communication in error, please contact the
sender by reply e-mail and destroy all copies of the original message.
Thank you.