Comment #19 filed under:
https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1577079
Thanks for the user.vendor-data key. I'll explore that approach. All
further results will be posted to 1577079.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
will do.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1575386
Title:
Proxy issue with 16.04
To manage notifications about this bug go to:
Kinda hard to tell what's going on exactly, I can think of one of two things:
- You didn't run "lxd init" or "dpkg-reconfigure lxd" and your lxdbr0 bridge
doesn't provide the containers with an IP address. Though I believe Juju is
supposed to detect this case and refuse to run.
- Your
I'm closing the LXD bug as it turned out to be a proxy issue on your
end.
If you don't find a way out of your current proxy configuration problem,
I'd recommend you file a bug against juju. Feel free to leave a link
here so I can keep an eye on it.
--
You received this bug notification because
Oh, sorry, missed part of your message (Launchpad truncated), so yeah,
you definitely hit the second case.
And no, LXD doesn't do any direct modification to the container rootfs.
It also doesn't propagate the host environment to the container as there
are a lot of cases where this would be wrong
Our IS dept. fixed the proxy, the bootstrap process is able to download
the image. However, during the package installation, it appears to hang
at:
[15:29:41] 1 $ juju bootstrap --upload-tools lxd-test lxd
Creating Juju controller "local.lxd-test" on lxd/localhost
Bootstrapping model "admin"
I'm not surprised. Thanks for your help and insight.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1575386
Title:
Proxy issue with 16.04
To manage notifications about this bug go to:
Yep, adding the remote does connect to it to validate its SSL
certificate. it does the equivalent of a "lxc info test:"
So yeah, looks like your proxy isn't behaving the same way for port 443
and port 8443.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
I think you may have nailed it.
[14:06:10] 1 $ lxc remote add test https://images.linuxcontainers.org:443
error: Get https://images.linuxcontainers.org:443: EOF
I'm surprised the above isn't just a local action. Does this make sense
to you that it fails to add the remote? If adding the remote
Hmm, so looks like we do have a bug that images.linuxcontainers.org is
meant to be defined as 8443 in our config but isn't right now... not
that it matters very much as the server listens on both ports
identically.
I'd be surprised that your proxy actually needs the port to be included
in the
fair enough and I agree with the pickyness. As noted above, we noticed
that the remote images: URL in <2.0 installs had the 8443 port
specifically defined whereas, a fresh 2.0 install does not. We had to
add the 8443 port ourselves like so:
lxc remote set-url images
When I ran my test earlier, I had firewall rules dropping all port 443
and port 80 and I also turned off DNS for good measure to make sure that
everything was going through the proxy.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
yeah, LXD is very picky as for its TLS configuration. We only allow
those ciphers because combined with TLS 1.2, we strongly believe they
are the safest. Since we also run all the public image servers and the
daemon, we don't need backward compatibility at all.
What's odd is that the exact same
A bit more info. Using wireshark during the communication exchange, the client
begins the SSL handshake with a 'Client Hello', the wireshark Secure Sockets
Layer information is below:
Secure Sockets Layer
SSL Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake
Might be of use (I have to look through the capture before I can upload
it), but another developer here commented (if what he notes is true,
then the TCP attempt wouldn't work behind an HTTP proxy, anyway. Does
you environment block all non-proxied traffic?):
With the following remote:
I'll forward this bug along to one of the members of our IS department.
Thanks! (I'll keep watching in case I can be of help)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1575386
Title:
Proxy
So the strace shows the expected behavior as far as detecting and
connecting to your proxy, it then shows the expected "CONNECT" command
being issued, the rest after that point is a TLS discussion so not
something that can be figured out from an strace...
That combined with the fact that using
As a note, the last command seems to work for all use cases, so it
allows me to be productive. I'm still interested in narrowing down why
the cloud-images.ubuntu.com source doesn't seem to be working.
$ lxc launch images:ubuntu/xenial/amd64 mine
Creating mine
Retrieving image: 100%
Starting mine
The output of strace is attached. Output of the second command seemed to
work just fine:
$ lxc image info images:ubuntu/xenial/amd64
Fingerprint: 2c09a4b4143fa9d87f9e8399e1f1883cc11712e94a571b2f41bf68a455cd6fe7
Size: 76.92MB
Architecture: x86_64
Public: yes
Timestamps:
Created: 2016/04/27
I can't seem to reproduce this here at all...
A failure to use the proxy would result in a different message than what
you got, so best guess is that it did indeed receive an invalid response
from the proxy...
Can you attach the output of:
https_proxy=http://proxy.company.com:8080
Works fine, with and without the leading proxy variables set (pulls from
environment when not set in command). I can see the full file (trailing
lines included for reference):
"com.ubuntu.cloud:server:14.10:amd64",
"com.ubuntu.cloud:server:14.10:i386"
],
"path":
https_proxy=http://proxy.company.com:8080
http_proxy=http://proxy.company.com:8080 wget https://cloud-
images.ubuntu.com/releases/streams/v1/index.json -O /dev/null
What does that get you?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Below are the results. (The last command was running while I tried
running the first two commands in another window, but no additional log
entries were generated after startup) In case it is really just an issue
with the company's proxy configuration (blocking specific ports,
etc...), are the
What happens if you do:
https_proxy=http://proxy.company.com:8080
http_proxy=http://proxy.company.com:8080 lxc image info ubuntu:
That should cause the client to do the simplestreams query for you,
using the proxy information set in the environment, that's probably the
easiest way to confirm
24 matches
Mail list logo
