<html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hey all, I've been working on fixing the problem(s) with deploying juju behind a proxy [1]. This involved creating kvm instances (using virt-manager), firewalling them off to only have access to the network through a proxy (squid running on the host) and bootstrapping with the manual provider. As this is a generally useful technique for testing bootstrap (etc) without using the local provider (which is a special snowflake in many ways and can't always be used for testing). There's nothing new or complex here, but it's a nice technique. I'll also describe the firewall rules needed for simulating a machine behind a proxy. Useful if you ever need to test this scenario. First of all create a new kvm instance from 14.04 server, and pre-select openssh to be installed. You shouldn't need to install anything else. If you're going to be running behind a proxy then clone the kvm instance (probably a good technique anyway) and use the clone. This is because you can't reprovision a machine with the manual provider when it's behind a proxy [2]. If you want to run behind a proxy then install squid3 on your host and edit the squid.conf to allow access from the local network (or from everywhere). The default squid port is 3128. iptables rules for the kvm instance are easiest to setup with ufw, which should be installed by default. Run the following commands as root: <div aria-haspopup="true" class="ajy"><img aria-label="Show details" data-tooltip="Show details" class="ajz" id=":24m" role="button" src="cid:part1.06000902.00000102@canonical.com" alt=""></div> ufw enable ufw default deny outgoing ufw allow out 22 ufw allow in 22 ufw allow out 17070 ufw allow in 17070 ufw allow out 67/udp ufw allow in 67/udp ufw allow out 3128/tcp ufw allow in 3128/tcp ufw allow out 53/udp This permits ssh access, the apiserver, dns and dhcp, plus access to the squid proxy, but blocks everything else. You can then edit environments.yaml as normal for the manual provider (run "ip addr" in the kvm instance to get the IP address of course): manual: type: manual bootstrap-host: 192.168.178.190 bootstrap-user: username #http-proxy: <a class="moz-txt-link-freetext" href="http://192.168.178.103:3128/">http://192.168.178.103:3128/</a> #https-proxy: <a class="moz-txt-link-freetext" href="http://192.168.178.103:3128/">http://192.168.178.103:3128/</a> Followed by: juju switch manual juju bootstrap --upload-tools This will "just work"... If you also wish to deploy units to a separate machine (you can deploy to the state server instance with "--to 0" of course) you'll need another kvm instance and use the form: juju deploy wordpress --to ssh:user@<ip addr> Warm regards, Michael Foord [1] <a class="moz-txt-link-freetext" href="https://bugs.launchpad.net/juju-core/+bug/1403225">https://bugs.launchpad.net/juju-core/+bug/1403225</a> [2] <a class="moz-txt-link-freetext" href="https://bugs.launchpad.net/juju-core/+bug/1418139">https://bugs.launchpad.net/juju-core/+bug/1418139</a> </body> </html>