Closed yardbirdsax closed 3 years ago
As per notes on #210 I ended up taking a different approach so as not to arbitrarily mess with permissions on the image's filesystem. I can imagine cases where a hardened image has very specific ACLs applied and didn't want to assume they should be undone.
Hm, something about this update is causing the Packer builds to fail at test time, at least on Amazon Linux:
TestConsulClusterWithAmazonLinuxAmi 2021-03-30T10:08:41Z command.go:168: 1617098921,,ui,error,==> amazon-linux-2-ami: 2021-03-30 10:08:41 [INFO] [install-consul] Could not find consul command. Aborting.
TestConsulClusterWithAmazonLinuxAmi 2021-03-30T10:08:41Z command.go:168: 1617098921,,ui,say,==> amazon-linux-2-ami: Provisioning step had errors: Running the cleanup provisioner%!(PACKER_COMMA) if present...
TestConsulClusterWithAmazonLinuxAmi 2021-03-30T10:08:41Z command.go:168: 1617098921,,ui,say,==> amazon-linux-2-ami: Terminating the source AWS instance...
My guess is that the path we install it into is not in PATH
on Amazon Linux for the sudo
user?
Hmmm... that's odd indeed. Is there an easy way I can run the same Packer build command locally that you do in your pipeline? I spent the last 10 minutes trying to unwind that and while I'm sure I could eventually I'm hoping there's an easier way. :)
On Tue, Mar 30, 2021 at 6:22 AM Yevgeniy Brikman @.***> wrote:
Hm, something about this update is causing the Packer builds to fail at test time, at least on Amazon Linux:
TestConsulClusterWithAmazonLinuxAmi 2021-03-30T10:08:41Z command.go:168: 1617098921,,ui,error,==> amazon-linux-2-ami: 2021-03-30 10:08:41 [INFO] [install-consul] Could not find consul command. Aborting. TestConsulClusterWithAmazonLinuxAmi 2021-03-30T10:08:41Z command.go:168: 1617098921,,ui,say,==> amazon-linux-2-ami: Provisioning step had errors: Running the cleanup provisioner%!(PACKER_COMMA) if present... TestConsulClusterWithAmazonLinuxAmi 2021-03-30T10:08:41Z command.go:168: 1617098921,,ui,say,==> amazon-linux-2-ami: Terminating the source AWS instance...
My guess is that the path we install it into is not in PATH on Amazon Linux for the sudo user?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/hashicorp/terraform-aws-consul/pull/213#issuecomment-810104830, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKN7EDLEBYLC3KMA3TBJZ3TGGQ7VANCNFSM4Z35AUMA .
It's not super obvious, but you can see the command in the logs:
TestConsulClusterWithAmazonLinuxAmi 2021-03-30T10:06:40Z packer.go:91: Running Packer to generate a custom artifact for template ../examples/consul-ami/consul.json
TestConsulClusterWithAmazonLinuxAmi 2021-03-30T10:06:40Z retry.go:72: packer [build -machine-readable -var aws_region=ap-south-1 -only=amazon-linux-2-ami ../examples/consul-ami/consul.json]
So that becomes:
packer build \
-machine-readable \
-var aws_region=ap-south-1 \
-only=amazon-linux-2-ami \
../examples/consul-ami/consul.json
Thanks, I've started looking at this. The behavior is really strange since
/usr/local/bin
is in the PATH of the sudo user.
On Wed, Mar 31, 2021 at 4:56 AM Yevgeniy Brikman @.***> wrote:
It's not super obvious, but you can see the command in the logs:
TestConsulClusterWithAmazonLinuxAmi 2021-03-30T10:06:40Z packer.go:91: Running Packer to generate a custom artifact for template ../examples/consul-ami/consul.json TestConsulClusterWithAmazonLinuxAmi 2021-03-30T10:06:40Z retry.go:72: packer [build -machine-readable -var aws_region=ap-south-1 -only=amazon-linux-2-ami ../examples/consul-ami/consul.json]
So that becomes:
packer build \ -machine-readable \ -var aws_region=ap-south-1 \ -only=amazon-linux-2-ami \ ../examples/consul-ami/consul.json
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/hashicorp/terraform-aws-consul/pull/213#issuecomment-810899481, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKN7ECOJQSNPTCEODQL5G3TGLPVPANCNFSM4Z35AUMA .
Turns out this did seem to be some kind of PATH tomfoolery. Manually passing in the user's current PATH value seems to have fixed it and was the simplest way I could determine to do so. I debated putting logic in the script to only do this under AL, but in the end it didn't appear to break other distros so I left it generic.
Hit a weird transient issue on the first test run, but it passed on re-run. The issue is unrelated to this PR, so I'm good to merge. Thanks!
The install-consul script now grants read and execute access to the directory where the Consul binary is installed. This fixes the issue reported under #210, while also allowing users who sign in under a different login to use the Consul binary for administrative purposes if necessary.