Generalize OS Step Should Use Provisioner's Knowledge

[Christopher Boumenot]

The ARM plugin blindly executes the following command to generalize UNIX based OSs.

sudo /usr/sbin/waagent -force -deprovision+user && export HISTSIZE=0 && sync

This is an important step for Azure VMs, but this does not work for all VM images. This works well for Ubuntu based images, but not for others such as CentOS. The knowledge for how to execute remote commands is encapsulated in the packer configuration files as provisioners.

Note the difference between Ubuntu and CentOS below. CentOS injects the password, and expects sudo to read it from STDIN, whereas Ubuntu does not. The knowledge of how to execute remote commands is perfectly captured by provisioners, but there is no clear way to capture this in the code (corrections are gladly accepted).

In the interim, the best solution is to remove the generalization step, and add it directly to the list of provisioner inline commands as well as a reminder that the user must ensure it executed.

Ubuntu

    "provisioners": [
        {
            "execute_command": "chmod +x {{ .Path }}; {{ .Vars }} sudo -E sh '{{ .Path }}'",
            "inline": [
                "apt-get update"

                "echo 'Generalizing the OS...",
                "/usr/sbin/waagent -force -deprovision+user && export HISTSIZE=0 && sync"
            ],
            "inline_shebang": "/bin/sh -x",
            "type": "shell"
        }
    ]

CentOS

    "provisioners": [
        {
            "execute_command": "echo '{{user `ssh_pass`}}' | {{ .Vars }} sudo -S -E sh '{{ .Path }}'",
            "inline": [
                "yum update -y",

                "echo 'Generalizing the OS...",
                "/usr/sbin/waagent -force -deprovision+user && export HISTSIZE=0 && sync"
            ],
            "inline_shebang": "/bin/sh -x",
            "type": "shell"
        }
    ]

[Christopher Boumenot]

I've decided to leave this as a command the user has to execute explicitly instead of embedding it in the Packer workflow. There's no way to do this well if I embed the command, nor is this a supported scenario in packer. Having the user do it explicitly gives him the freedom to decide.