This issue was originally opened by @markododa as hashicorp/packer#7530. It was migrated here as a result of the Packer plugin split. The original body of the issue is below.

Using the lxd builder, i have a simple file provisioner decleration

{ "type": "file", "source": "/root/saltstack/reactor", "destination": "/srv/reactor" },
as per the documentation at https://www.packer.io/docs/provisioners/file.html this should create a folder /srv/reactor with the contents of the source directory.
However /srv/reactor is not created but its contents are in the /srv folder

Description

LXD supports using --profile multiple times:
lxc launch <image> <instance_name> --profile <profile> --profile <profile> ...

The plugin does, however, only support a single profile given as a string.

References

• https://linuxcontainers.org/lxd/docs/master/profiles/#apply-a-profile-to-an-instance
• https://github.com/hashicorp/packer-plugin-lxd/blob/main/builder/lxd/config.go#L33
• https://github.com/hashicorp/packer-plugin-lxd/blob/main/builder/lxd/step_lxd_launch.go#L22

Description

With LXD configured on a local machine (on which packer will run) and a pre-configured LXD remote, I can use the LXD builder to launch and provision a container on the remote LXD server by setting container_name = "remote-name:container-name".

The LXD builder then launches the image on the remote LXD server and I can use e.g. ansible with ansible_connection=lxd and ansible_lxd_remote=remote-name to provision it.

However, after the provisioning is completed, the LXD builder publishes the image on the remote LXD server but then copies it to the local machine and deletes the image on the remote server.

Even if I specify the remote server in output_image (e.g. output_image = "remote-name:output-image"), I still end up with an image on the local machine (which is named remote-name:output-image) and no image on the remote server.

Feature request:
If I launch and provision an LXD container on a remote LXD server, then I would like to be able to publish the image on the same remote LXD server instead of having it download to the local machine on which packer is running.

(Note: this would be the same behaviour as the Amazon AMI Builder, which launches an AMI on AWS, provisions it and then publishes the new image to the AWS account's image repository).

Use Case(s)

The use-case is to use packer on a local machine to build and publish images on a remote LXD server, which can then be launched on that server with Terraform.

Potential configuration

The existing configuration could be re-used so that output_image is parsed and if the form remote-name:output-image is found, then the lxd publish command is lxc publish container-name remote-name: --alias output-image and not lxc publish remote-name:container-name --alias output-image.

E.g.

build {

  source "lxd.container" {
    container_name = "remote-name:container-name"
    output_image = "remote-name:output-image"        ### This parsed to detect and identify the LXD remote
  }

  provisioner "ansible" {
    ...
  }
}

Alternatively, a new configuration parameter could be introduced. For example remote_publish: "remote-name", so that the lxd publish command is lxc publish container-name remote-name: --alias output-image

E.g.

build {

  source "lxd.container" {
    container_name = "remote-name:container-name"
    remote_publish = "remote-name"
    output_image = "output-image"
  }

  provisioner "ansible" {
    ...
  }
}

Maybe cleaner would then be to use a single remote configuration parameter for modifying both container_name and output_image.

E.g.

build {

  source "lxd.container" {
    remote = "remote-name"
    container_name = "container-name"
    output_image = "output-image"
  }

  provisioner "ansible" {
    ...
  }
}

...but this would then force both build and publish to be on the remote machine, which may not be wanted by some users, so for full flexibility we could have, e.g.

build {

  source "lxd.container" {
    remote_build = "remote-name"
    container_name = "container-name"
    remote_publish = "remote-name"
    output_image = "output-image"
  }

  provisioner "ansible" {
    ...
  }
}

Hope that makes sense.
Thanks in advance!

This issue was originally opened by @gaetanquentin as hashicorp/packer#10023. It was migrated here as a result of the Packer plugin split. The original body of the issue is below.

Overview of the Issue

packer salt module can't copy states tree when used with lxd: bad directories

Reproduction Steps

PACKER_LOG=1 packer build -on-error=ask -var-file=../../lab/01_common/default-variables.json lxd-ubuntu-20.04-saltmaster-2020.json

Packer/salt/lxd versions

packer >= 1.6.0: currently 1.6.4
salt version: 3001.1
lxd version: 4.6 (snap)

Simplified Packer Buildfile

variables:
"salt_local_pillars_dir": "/home/gquentin/Work/repositories/git/automation/Provisionners/SaltStack/pillar",
"salt_remote_pillars_dir": "/srv/pillar",
"salt_local_states_dir": "/home/gquentin/Work/repositories/git/automation/Provisionners/SaltStack/states",
"salt_remote_states_dir": "/srv",
"salt_temp_config_dir": "/tmp/salt"

other:
{
"builders": [
{
"type": "lxd",
"name": "ubuntu-20-04",
"image": "images:ubuntu/20.04",
"output_image": "ubuntu-20-04",
"publish_properties": {
"description": "Ubuntu focal amd64 with saltmaster 3001 built with packer "
},
"profile": "default",
"launch_config": {
"security.privileged": "false"
}
}
],

[ ..]

{
"type": "salt-masterless",
"local_state_tree": "{{user salt_local_states_dir}}",
"remote_state_tree": "{{user salt_remote_states_dir}}",
"local_pillar_roots": "{{user salt_local_pillars_dir}}",
"remote_pillar_roots": "{{user salt_remote_pillars_dir}}",
"temp_config_dir": "{{user salt_temp_config_dir}}",
"custom_state": "sys.tools,sys.locale,sys.sysctl,sys.network,apps.configmanager.salt.master,apps.versioncontrol.git",
"skip_bootstrap": "true",
"bootstrap_args": "-x python3 stable 3001.1 ",
"pause_before": "20s"
},
[ ..]

Operating system and Environment details

Host: ubuntu 20.04
lxd container image: ubuntu 20.04

Log Fragments and crash.log files

    ubuntu-20-04: Uploading local state tree: /home/gquentin/Work/repositories/git/automation/Provisionners/SaltStack/states
2020/10/01 13:20:45 packer-builder-lxd plugin: lxc file push --debug -pr /home/gquentin/Work/repositories/git/automation/Provisionners/SaltStack/states packer-ubuntu-20-04/states
2020/10/01 13:20:45 packer-builder-lxd plugin: Running cp command: lxc file push --debug -pr /home/gquentin/Work/repositories/git/automation/Provisionners/SaltStack/states packer-ubuntu-20-04/states

=> here you can see packer copying states dir in the root (/) of target container

    ubuntu-20-04: Moving states to /tmp/salt/states
2020/10/01 13:20:47 packer-builder-lxd plugin: Executing with lxc exec in container: packer-ubuntu-20-04 sudo sudo mv 'states' '/tmp/salt/states'
2020/10/01 13:20:47 packer-builder-lxd plugin: Executing lxc exec: /bin/sh []string{"/bin/sh", "-c", "lxc exec packer-ubuntu-20-04 -- /bin/sh -c \"sudo sudo mv 'states' '/tmp/salt/states'\""}
==> ubuntu-20-04: mv: cannot stat 'states': No such file or directory

=> here you can see in "sudo mv states /tmp/salt/states" that packer try to move states from /root/states and not /states  since default lxc exec env is user root in /root

more theses directories are not theses specified in input variables 

Regards

The lxc exec command has many powerful flags, including

• --uid and --gid to set the user and group of the subprocess on the remote container
• --cwd to set the working directory
• --env for environment variables
• ...and more

Taking advantage of these right now requires the shell-local provisioner.

Consider this configuration snippet.

locals {
  git_script = "/tmp/git-script.sh"
}

source "lxd" "arch" {
  image = "images:archlinux/cloud"
}

build {
  source "lxd.arch" {
    name         = "arch-ci"
    output_image = "arch-ci"
  }

  provisioner "file" {
    source      = "./git-script.sh"
    destination = "${local.git_script}"
  }

  provisioner "shell" {
    inline = [
      "pacman -Syyu --noconfirm",
      "pacman -Sy --noconfirm man make cmake git python python2 ninja clang lld htop jq neovim kitty-terminfo openssh",
      "useradd -m builder",
      "systemctl enable --now sshd",
    ]
  }

  provisioner "shell-local" {
    inline = [
      "lxc exec packer-arch --env HOME=/home/builder --cwd /home/builder --user 1001 --group 1001 -- mkdir /home/builder/.ssh",
      "lxc exec packer-arch --env HOME=/home/builder --cwd /home/builder --user 1001 --group 1001 -- ${local.git_script}",
    ]
  }
}

A dedicated lxc-exec provisioner would allow reducing this duplication. It would be really useful, because if you don't set these flags, you're running as root in a pretty bare process environment.

Potential configuration

provisioner "lxc-exec" {
  environment_vars = ["HOME=/home/builder"]
  user = 1000
  group = 1000
  working_directory = "/home/builder"
  inline = [
    "echo I'm run with uid 1000 from /home/builder",
  ]
}

Potential References

Potential prior art is the Puppet Bolt plugin puppetlabs/bolt#2311

Description

Add config value no_publish. It becomes don't executing lxc publish when set true.

Use Case(s)

In a small disk environment (like a GitHub-hosted runner in GitHub Actions), I want to publish a remote LXD server.
But, packer-plugin-lxd is not supported a remote build and publish (see #25 )

So, no_publishis a simple solution to my problem.

Potential configuration

     "builders": [
         {
          "type": "lxd",
          "image": "ubuntu:focal",
          "no_publish": "true"
         }

Overview of the Issue

Publishing an image fails on an LXD cluster member, because the container might not run on the same node where packer is running. The images are replicated between cluster nodes but there's an obvious lag. Packer does not wait for the image to be replicated before checking if it was successfully published.

Another possible approach would be to add an "lxc launch" option "--target" where you can specify where to run the container, in the same node where you are running packer.

Reproduction Steps

Just build any image on an LXD cluster member and wait for it to be built and published

Plugin and Packer version

Packer: 1.8.2
packer-plugin-lxd_v1.0.1

Simplified Packer Buildfile

Operating system and Environment details

Log Fragments and crash.log files

2022/07/15 14:23:26 ui: ==> lxd.debian-ubuntu-base: Publishing container...
2022/07/15 14:23:26 packer-plugin-lxd_v1.0.1_x5.0_linux_amd64 plugin: 2022/07/15 14:23:26 Executing lxc command: []string{"publish", "packer-debian-ubuntu-base", "", "--alias", "ubuntu-focal-base", "name=ubuntu-focal-base-x86_64", "os=ubuntu", "release=focal", "serial=2022071500", "architecture=x86_64", "description=ubuntu focal base image"}
Publishing instance: Image pack: 100% (15.54MB/s) linux_amd64 plugin: 2022/07/15 14:24:53 stdout: Publishing instance: Image pack: 1% (11.69MB/s)
2022/07/15 14:24:53 packer-plugin-lxd_v1.0.1_x5.0_linux_amd64 plugin: 2022/07/15 14:24:53 stderr: Error: Failed syncing image between nodes: Failed to get nodes for the image synchronization: No such object
2022/07/15 14:24:53 ui error: ==> lxd.debian-ubuntu-base: Error publishing container: LXD command error: Error: Failed syncing image between nodes: Failed to get nodes for the image synchronization: No such object
2022/07/15 14:24:53 ui: ==> lxd.debian-ubuntu-base: Unregistering and deleting deleting container...

This issue was originally opened by @chrisoldwood as hashicorp/packer#9147. It was migrated here as a result of the Packer plugin split. The original body of the issue is below.

Overview of the Issue

When building an LXD image with 1.5.4 or 1.5.5 of packer we are seeing the file provisioner writing to the wrong directory when the source directory contains a trailing slash. The documentation states the following behaviour is to be expected:

Next, the existence of a trailing slash on the source path will determine whether the directory name will be embedded within the destination, or whether the destination will be created.
[…]
If the source, however, is /foo/ (a trailing slash is present), and the destination is /tmp , then the contents of /foo will be uploaded into /tmp directly.

Reproduction Steps

The following snippet is what we've been using fine up until now:

    {
      "type": "file",
      "source": "../",
      "destination": "/report-runner"
    }

We see the following results:

Note: for 1.5.5 / is probably equivalent to /report-runner/...

Packer version

1.5.4 or 1.5.5 appear broken while 1.4.4 appears correct (IMHO).

Operating system and Environment details

Ubuntu 18.04 64-bit.
LXC 4.0.1