I’m having an issue with the packer provisioner using HTTP, even when the firewalls are off the host VM running Windows Server 2025 cant find the host path hosted by the HTTP Server
It keeps saying either
PACKER_HTTP_URL environment variable is not set or empty when its not
or it says
An error occurred: Invalid URI: The hostname could not be parsed.
Can I get any help with this one ? this is stopping my scripts being downloaded or run.
I validated the environment variables being set during provisioning using the following provisioner block:
provisioner "powershell" {
inline = [
"Get-ChildItem Env: | Sort-Object Name | Format-Table Name,Value -AutoSize"
]
}
This confirmed I was referencing the correct variables, specifically PACKER_HTTP_ADDR
. However, despite using the correct variable, it is not being translated or passed into the OS environment during provisioning as expected.
I’ve also confirmed that the Windows Firewall is fully disabled to rule out local interference, yet I’m still encountering consistent errors such as “unable to reach URI”. Additionally, I discovered a nearly identical issue already reported on Packer’s GitHub back in April, suggesting this could be a broader problem with how contextual variables are injected into the guest environment.
To aid visibility, here’s the current PowerShell inline provisioner I’m attempting to use (which still fails):
# Extract and prepare IP/port
"$urlRoot = \"http://$env:PACKER_HTTP_ADDR\"",
"$ip, $port = $env:PACKER_HTTP_ADDR -split ':'",
# Open Windows Firewall inbound + outbound for dynamic HTTP port
"New-NetFirewallRule -DisplayName 'Packer HTTP Inbound' -Direction Inbound -Action Allow -RemoteAddress $ip -Protocol TCP -LocalPort $port",
"New-NetFirewallRule -DisplayName 'Packer HTTP Outbound' -Direction Outbound -Action Allow -RemoteAddress $ip -Protocol TCP -RemotePort $port",
# Corrected echo with subexpression
"Write-Host \"Firewall rules created for Packer HTTP on $($ip):$($port)\""
This code should dynamically open the required ports for the HTTP server started by Packer’s built-in http_directory
mechanism, but it currently fails due to the $env:PACKER_HTTP_ADDR
variable not resolving inside the provisioned environment.