Bug: Google Compute Builder failing for newer Debian-based images

[clounie]

With the Google Compute Builder, any builds with a Debian 7 or Debian 8 source_image later than these versions will error, when trying to SSH for provisioning:

• debian-8-jessie-v20160329
• debian-7-wheezy-v20160329

I've tried ssh_username of:

• google
• debian
• root (scp starts erroring if you use this)

But none of them work. Is this similar to #788, or was I barking up the wrong tree?

I looked, as well, in the release notes for Google Compute, but didn't see anything directly related/obvious.

---

Debug Info:

• Packer Version: 0.10.1
• Host platform: macOS 10.11.5
• Debug output: packer-gce-debian-error.log
• Simplest reproducible template:

{
  "provisioners": [
    {
        "type": "file",
        "source": "./myTestFile.log",
        "destination": "/etc/myTestFile.log",
        "direction": "upload"
    }
  ],
  "builders": [
    {
      "type": "googlecompute",
      "image_name": "debian-ssh-test-image",
      "project_id": "my-gce-project",
      "zone": "us-east1-d",
      "account_file": "gce-service-account-creds.json",
      "source_image": "debian-8-jessie-v20160418"
    }
  ]
}

[rickard-von-essen]

@ido #3587 doesn't really change anything for this issue.

[clounie]

Note that adding the metadata they specify to add in the article for creating a user account at least gets you a successful ssh connection. However, it then has problems actually doing anything on the instance.

Maybe because the only scopes it uses are:

2016/07/14 11:12:30 packer: 2016/07/14 11:12:30 [INFO]   -- Scopes: [https://www.googleapis.com/auth/compute https://www.googleapis.com/auth/devstorage.full_control]

...with no cloud.useraccounts.readonly scope. And thus it doesn't properly setup the user account on the instance? (Well, that and it overrides the sshKeys metadata)

Gist for what I'm talking about: https://gist.github.com/clounie/dce56ad8107a33cf60b3c362e17210cf

[clounie]

Am I on the right track with any of this? I'd be more than willing to do a PR if it's something that needs to be added/changed in Packer.

[bivald]

@clounie did you ever get closer to solving this issue? I'm seeing it as well.

Update: I've asked for help on the GCE mailing list as well, https://groups.google.com/forum/#!topic/gce-discussion/mJP4X_TnqDo

[rickard-von-essen]

This works for me:

{
  "builders": [
    {
      "type": "googlecompute",
      "project_id": "<project>",
      "zone": "europe-west1-b",
      "ssh_username": "debian",
      "source_image": "debian-8-jessie-v20160418"
    }
  ]
}

Try adding "ssh_username": "debian".

[crunk1]

I have tried repro'ing this with a few templates. Here are some interesting results:
Packer version: 0.10.1_linux_amd64
Host: Ubuntu 14.04

{
  "provisioners": [
    {
        "type": "file",
        "source": "foo.txt",
        "destination": "/etc/foo.txt",
        "direction": "upload"
    }
  ],
  "builders": [
    {
      "type": "googlecompute",
      "image_name": "debian-ssh-test-image",
      "project_id": "my-gce-project",
      "zone": "us-east1-d",
      "account_file": "creds.json",
      "source_image": "debian-8-jessie-v20160418",
      "ssh_username": "foo"
    }
  ]
}

Result: Build 'googlecompute' errored: scp: /etc/foo.txt: Permission denied
In other words, it looks like the created SSH user does not have root permissions.

I tried it again with the same template, but I modified /etc/foo.txt to be /home/foo/foo.txt.
Result: /home/foo/foo.txt was created.

[crunk1]

Update: I have repro'ed that root access is denied on centos-7 as well.

[rickard-von-essen]

I'm closing this since this seems to be working as it should and mostly be a usage question. Use IRC #packer-tool on Freenode or the mailing list to ask for help on how to use Packer.

See https://www.packer.io/community/

If you are describing a bug or a feature request please reopen and try to add some more details to make it clearer.

[bivald]

I can confirm that adding "ssh_username": "debian" is working for me. I can sudo using either sudo in each command, or by adding sudo in execute_command (for shell scripts). For file provisioner, I haven't tried it yet but I assume I simply need to use the technique described in the docs:

If you want to upload files to locations that require elevated privileges, we recommend uploading them to temporary locations and then using the shell provisioner to move them into place.

[crunk1]

If you want to upload files to locations that require elevated privileges, we recommend uploading them to temporary locations and then using the shell provisioner to move them into place.

I was not aware of that. Good to know.

[bivald]

@crunk1 It's a fairly new requirement (at least on GCE)

[clounie]

Follow-up on my end: Looks like something must have changed on GCE's side.

It works with both Packer v0.10.1 and v0.10.2 now, using the same examples that failed for me before.

Thanks for checking it out rickard.