Skip to content

Commit

Permalink
Implement workaround for packer ssh
Browse files Browse the repository at this point in the history
The new Ubuntu Server installer starts an SSH server.
The credentials are installer:<random_pw>
Packer wrongfully tries to connect to this SSH, thinking the VM is ready for further provisioning steps - which it is NOT.

Thanks to @JulyIghor we found a workaround.
We simply change the port packer expects the ssh server to run at to something else AND during cloud-init late_commands we override the servers port accordingly. That way once the cloud-init finishes and reboots the VM the ssh server will run at the new port - now packer picks up on that and continues provisiong as we are used to.

As a last step durng provision, we remove the conf file, essentially resettign the ssh server port back to default 22.

@SwampDragons:
hashicorp/packer#9115
Please check on the logic behind communicator setting "pause_before_connecting".
That setting actually does still try to connect ONCE and then waits, instead of waiting for the specified duration and then and only then trying to connect. Thanks!
  • Loading branch information
rubenst2013 committed Apr 29, 2020
1 parent 5a12172 commit 4b535fe
Show file tree
Hide file tree
Showing 2 changed files with 11 additions and 1 deletion.
11 changes: 10 additions & 1 deletion ubuntu2004/box-config.json
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,15 @@
"type": "shell",
"execute_command": "echo 'vagrant' | {{.Vars}} sudo -S -E bash '{{.Path}}'",
"script": "scripts/cleanup.sh"
},
{
"type": "shell",
"execute_command": "echo 'vagrant' | {{.Vars}} sudo -S -E bash '{{.Path}}'",
"inline_shebang": "#!/bin/bash -e",
"inline": [
"echo 'Resetting SSH port to default!'",
"rm /etc/ssh/sshd_config.d/packer-init.conf"
]
}
],
"builders": [
Expand All @@ -45,7 +54,7 @@
"iso_checksum": "caf3fd69c77c439f162e2ba6040e9c320c4ff0d69aad1340a514319a9264df9f",
"ssh_username": "vagrant",
"ssh_password": "vagrant",
"ssh_port": 22,
"ssh_port": 2222,
"ssh_wait_timeout": "1800s",
"shutdown_command": "echo 'vagrant'|sudo -S shutdown -P now",
"guest_additions_path": "VBoxGuestAdditions_{{.Version}}.iso",
Expand Down
1 change: 1 addition & 0 deletions ubuntu2004/http/user-data
100644 → 100755
Original file line number Diff line number Diff line change
Expand Up @@ -41,3 +41,4 @@ autoinstall:
late-commands:
- sed -i 's/^#*\(send dhcp-client-identifier\).*$/\1 = hardware;/' /target/etc/dhcp/dhclient.conf
- 'sed -i "s/dhcp4: true/&\n dhcp-identifier: mac/" /target/etc/netplan/00-installer-config.yaml'
- 'echo "Port 2222" > /target/etc/ssh/sshd_config.d/packer-init.conf'

4 comments on commit 4b535fe

@SwampDragons
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the ping. I'm aware of that behavior: hashicorp/packer#7430 (comment)

The idea behind doing it that way was that rather than just having an arbitrary wait that has to cover an entire preseed run, you'd be able to be a bit more specific with how long Packer has to wait around because you only have to wait between the time the server is up, and whenever you think the preseed is complete. Originally, we figured setting up SSH would be near the end of the run, which means that doing it this way would enable a shorter and more precise wait.

Is connecting, then disconnecting and waiting causing an issue that forces this workaround, or was it just unexpected?

Thanks for tagging me on this so I can see this workaround. I've been following hashicorp/packer#9115 but hadn't had a chance to research it myself yet so was waiting to comment.

@rubenst2013
Copy link
Owner Author

@rubenst2013 rubenst2013 commented on 4b535fe Apr 29, 2020 via email

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@SwampDragons
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the real issue is the logs being spammy when you increase the SSH timeout, I'd rather we adjust the verbosity of the connection attempt logging.

@rubenst2013
Copy link
Owner Author

@rubenst2013 rubenst2013 commented on 4b535fe Apr 29, 2020 via email

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please sign in to comment.