Discussion:
add device unix-char not yet implemented?
(too old to reply)
Janjaap Bos
2015-05-20 21:06:41 UTC
Permalink
Hi,

I have problems adding a /dev/net/tun device to the container.

It appears that the unix-char device is not yet supported for the command:
lxc config device add ...

Is that right? Or should I do something else?

Thanks,

-Janjaap

(Using http://ppa.launchpad.net/ubuntu-lxc/lxd-git-master/ubuntu trusty)
Serge Hallyn
2015-05-22 00:54:52 UTC
Permalink
Quoting Janjaap Bos (***@gmail.com):
> Hi,
>
> I have problems adding a /dev/net/tun device to the container.
>
> It appears that the unix-char device is not yet supported for the command:
> lxc config device add ...
>
> Is that right? Or should I do something else?

D'oh, yeah, you can add it to the configuration, but when you try
to start the container you'll see

case "unix-char":
return nil, fmt.Errorf("Not implemented")

I'm actually not sure what the best thing to do here is. lxd
doesn't mount the rootfs itself, so if it's say a lvm block device
we can't just mknod the device in there. So perhaps lxd should
mknod the device under $lxcpath/$container/devices, then add a
lxc.mount.entry line to the (ephemeral) container configuration.

Patches welcome :)
Janjaap Bos
2015-05-22 21:46:14 UTC
Permalink
2015-05-22 2:54 GMT+02:00 Serge Hallyn <***@ubuntu.com>:

>
>
> D'oh, yeah, you can add it to the configuration, but when you try
> to start the container you'll see
>
> case "unix-char":
> return nil, fmt.Errorf("Not implemented")
>
> I'm actually not sure what the best thing to do here is. lxd
> doesn't mount the rootfs itself, so if it's say a lvm block device
> we can't just mknod the device in there. So perhaps lxd should
> mknod the device under $lxcpath/$container/devices, then add a
> lxc.mount.entry line to the (ephemeral) container configuration.
>
> Patches welcome :)
>

Thanks for the feedback.
I'll have a go at it, and will send follow up on the dev list if needed.

-Janjaap
Kevin LaTona
2015-05-23 00:14:06 UTC
Permalink
This past week or so I ran into an issue of not being able to connect a test LXD rest server on my local network.

I've tested this problem out from pretty much every angle I can think of.

Every thing from fresh OS, server, SSL lib installs to upgrades of current running apps on my machines.


Pretty much unless I am missing some small fundamental piece that is preventing current shipping vivid server to allow connections to the LXD rest server.

My take is there is a bug .

If this true, what is the best way to let the LXC team know about this to see how to get to next step?


To sum it up I am able to connect to a public LXD rest server.

# from vivid container --> public LXD server ( container to public )
curl -k https://images.linuxcontainers.org/1.0/images
# {"status": "Success", "metadata": ["/1.0/images/e7ae410ee8abeb6


No matter how and from what angle I try connecting to a local test LXD rest server it is having connections issues.

# vivid container 10.0.3.5 --> 192.168.0.50:8443 ( container to host machine )
# this container can ping 192.168.0.50
curl -k https://192.168.0.50:8443/1.0/images
# curl: (35) error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate



# OS X term window --> vivid server (same 192.168.x.x network)
curl -k https://192.168.0.50:8443/1.0/images
# curl: (35) error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version



If any one has any ideas or suggestions please send them along.

-Kevin
Tycho Andersen
2015-05-23 04:13:46 UTC
Permalink
On Fri, May 22, 2015 at 05:14:06PM -0700, Kevin LaTona wrote:
>
> This past week or so I ran into an issue of not being able to connect a test LXD rest server on my local network.
>
> I've tested this problem out from pretty much every angle I can think of.
>
> Every thing from fresh OS, server, SSL lib installs to upgrades of current running apps on my machines.
>
>
> Pretty much unless I am missing some small fundamental piece that is preventing current shipping vivid server to allow connections to the LXD rest server.
>
> My take is there is a bug .
>
> If this true, what is the best way to let the LXC team know about this to see how to get to next step?
>
>
> To sum it up I am able to connect to a public LXD rest server.
>
> # from vivid container --> public LXD server ( container to public )
> curl -k https://images.linuxcontainers.org/1.0/images
> # {"status": "Success", "metadata": ["/1.0/images/e7ae410ee8abeb6
>
>
> No matter how and from what angle I try connecting to a local test LXD rest server it is having connections issues.
>
> # vivid container 10.0.3.5 --> 192.168.0.50:8443 ( container to host machine )
> # this container can ping 192.168.0.50
> curl -k https://192.168.0.50:8443/1.0/images
> # curl: (35) error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate

You probably need to pass --cert and --key to curl as well; you can
see examples of this in the /tests directory.

Tycho

>
>
> # OS X term window --> vivid server (same 192.168.x.x network)
> curl -k https://192.168.0.50:8443/1.0/images
> # curl: (35) error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
>
>
>
> If any one has any ideas or suggestions please send them along.
>
> -Kevin
>
>
>
> _______________________________________________
> lxc-users mailing list
> lxc-***@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
Kevin LaTona
2015-05-23 04:32:05 UTC
Permalink
On May 22, 2015, at 9:13 PM, Tycho Andersen <***@canonical.com> wrote:

> On Fri, May 22, 2015 at 05:14:06PM -0700, Kevin LaTona wrote:
>>
>> This past week or so I ran into an issue of not being able to connect a test LXD rest server on my local network.
>>
>> I've tested this problem out from pretty much every angle I can think of.
>>
>> Every thing from fresh OS, server, SSL lib installs to upgrades of current running apps on my machines.
>>
>>
>> Pretty much unless I am missing some small fundamental piece that is preventing current shipping vivid server to allow connections to the LXD rest server.
>>
>> My take is there is a bug .
>>
>> If this true, what is the best way to let the LXC team know about this to see how to get to next step?
>>
>>
>> To sum it up I am able to connect to a public LXD rest server.
>>
>> # from vivid container --> public LXD server ( container to public )
>> curl -k https://images.linuxcontainers.org/1.0/images
>> # {"status": "Success", "metadata": ["/1.0/images/e7ae410ee8abeb6
>>
>>
>> No matter how and from what angle I try connecting to a local test LXD rest server it is having connections issues.
>>
>> # vivid container 10.0.3.5 --> 192.168.0.50:8443 ( container to host machine )
>> # this container can ping 192.168.0.50
>> curl -k https://192.168.0.50:8443/1.0/images
>> # curl: (35) error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate
>
> You probably need to pass --cert and --key to curl as well; you can
> see examples of this in the /tests directory.


I'll look into that to see if that helps.


Yet I am able to hit the images.linuxcontainers.org server from all ….

Using OS X, Ubuntu host and from Container and all with the same Curl command calls.

Which has me wondering why that server and not my local LXD rest server?

So far makes zero sense to me and the Rest server should make things simpler in the end.



Unless I am missing something in configs or settings some where else… or there is bug.


I've chased enough code problems to know when you hammer on it from all possible ways.

And it's working part of the time….. some thing is off as it's just not making sense.

Plus I am not seeing any mention in LXD docs about need for cert and keys for this kind of call.


If I need them for the local server I would need them for the pulbic server as well since Linuxcontainers is using self signed cert on that site.


-Kevin









> Tycho
>
>>
>>
>> # OS X term window --> vivid server (same 192.168.x.x network)
>> curl -k https://192.168.0.50:8443/1.0/images
>> # curl: (35) error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
>>
>>
>>
>> If any one has any ideas or suggestions please send them along.
>>
>> -Kevin
>>
>>
>>
>> _______________________________________________
>> lxc-users mailing list
>> lxc-***@lists.linuxcontainers.org
>> http://lists.linuxcontainers.org/listinfo/lxc-users
> _______________________________________________
> lxc-users mailing list
> lxc-***@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
Tycho Andersen
2015-05-23 04:39:58 UTC
Permalink
On Fri, May 22, 2015 at 09:32:05PM -0700, Kevin LaTona wrote:
>
> On May 22, 2015, at 9:13 PM, Tycho Andersen <***@canonical.com> wrote:
>
> > On Fri, May 22, 2015 at 05:14:06PM -0700, Kevin LaTona wrote:
> >>
> >> This past week or so I ran into an issue of not being able to connect a test LXD rest server on my local network.
> >>
> >> I've tested this problem out from pretty much every angle I can think of.
> >>
> >> Every thing from fresh OS, server, SSL lib installs to upgrades of current running apps on my machines.
> >>
> >>
> >> Pretty much unless I am missing some small fundamental piece that is preventing current shipping vivid server to allow connections to the LXD rest server.
> >>
> >> My take is there is a bug .
> >>
> >> If this true, what is the best way to let the LXC team know about this to see how to get to next step?
> >>
> >>
> >> To sum it up I am able to connect to a public LXD rest server.
> >>
> >> # from vivid container --> public LXD server ( container to public )
> >> curl -k https://images.linuxcontainers.org/1.0/images
> >> # {"status": "Success", "metadata": ["/1.0/images/e7ae410ee8abeb6
> >>
> >>
> >> No matter how and from what angle I try connecting to a local test LXD rest server it is having connections issues.
> >>
> >> # vivid container 10.0.3.5 --> 192.168.0.50:8443 ( container to host machine )
> >> # this container can ping 192.168.0.50
> >> curl -k https://192.168.0.50:8443/1.0/images
> >> # curl: (35) error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate
> >
> > You probably need to pass --cert and --key to curl as well; you can
> > see examples of this in the /tests directory.
>
>
> I'll look into that to see if that helps.
>
>
> Yet I am able to hit the images.linuxcontainers.org server from all ….

Yes, images.linuxcontainers.org is not a real LXD server, it just
implements parts of the rest API (the public bits).

> Using OS X, Ubuntu host and from Container and all with the same Curl command calls.
>
> Which has me wondering why that server and not my local LXD rest server?
>
> So far makes zero sense to me and the Rest server should make things simpler in the end.
>
>
>
> Unless I am missing something in configs or settings some where else… or there is bug.
>
>
> I've chased enough code problems to know when you hammer on it from all possible ways.
>
> And it's working part of the time….. some thing is off as it's just not making sense.
>
> Plus I am not seeing any mention in LXD docs about need for cert and keys for this kind of call.

I suppose there's no reason we couldn't allow requests without a
client cert to work for unauthenticated requests; I don't anticipate
it being a hugely common use case, though, as most people should be
using a client or API to access LXD.

>
> If I need them for the local server I would need them for the pulbic server as well since Linuxcontainers is using self signed cert on that site.

images.linuxcontainers.org shouldn't be using a self signed cert; LXD
does, though.

Tycho

>
>
> -Kevin
>
>
>
>
>
>
>
>
>
> > Tycho
> >
> >>
> >>
> >> # OS X term window --> vivid server (same 192.168.x.x network)
> >> curl -k https://192.168.0.50:8443/1.0/images
> >> # curl: (35) error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
> >>
> >>
> >>
> >> If any one has any ideas or suggestions please send them along.
> >>
> >> -Kevin
> >>
> >>
> >>
> >> _______________________________________________
> >> lxc-users mailing list
> >> lxc-***@lists.linuxcontainers.org
> >> http://lists.linuxcontainers.org/listinfo/lxc-users
> > _______________________________________________
> > lxc-users mailing list
> > lxc-***@lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-users
>
> _______________________________________________
> lxc-users mailing list
> lxc-***@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
Kevin LaTona
2015-05-23 05:06:05 UTC
Permalink
On May 22, 2015, at 9:39 PM, Tycho Andersen <***@canonical.com> wrote:

> On Fri, May 22, 2015 at 09:32:05PM -0700, Kevin LaTona wrote:
>>
>> On May 22, 2015, at 9:13 PM, Tycho Andersen <***@canonical.com> wrote:
>>
>>> On Fri, May 22, 2015 at 05:14:06PM -0700, Kevin LaTona wrote:
>>>>
>>>> This past week or so I ran into an issue of not being able to connect a test LXD rest server on my local network.
>>>>
>>>> I've tested this problem out from pretty much every angle I can think of.
>>>>
>>>> Every thing from fresh OS, server, SSL lib installs to upgrades of current running apps on my machines.
>>>>
>>>>
>>>> Pretty much unless I am missing some small fundamental piece that is preventing current shipping vivid server to allow connections to the LXD rest server.
>>>>
>>>> My take is there is a bug .
>>>>
>>>> If this true, what is the best way to let the LXC team know about this to see how to get to next step?
>>>>
>>>>
>>>> To sum it up I am able to connect to a public LXD rest server.
>>>>
>>>> # from vivid container --> public LXD server ( container to public )
>>>> curl -k https://images.linuxcontainers.org/1.0/images
>>>> # {"status": "Success", "metadata": ["/1.0/images/e7ae410ee8abeb6
>>>>
>>>>
>>>> No matter how and from what angle I try connecting to a local test LXD rest server it is having connections issues.
>>>>
>>>> # vivid container 10.0.3.5 --> 192.168.0.50:8443 ( container to host machine )
>>>> # this container can ping 192.168.0.50
>>>> curl -k https://192.168.0.50:8443/1.0/images
>>>> # curl: (35) error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate
>>>
>>> You probably need to pass --cert and --key to curl as well; you can
>>> see examples of this in the /tests directory.
>>
>>
>> I'll look into that to see if that helps.
>>
>>
>> Yet I am able to hit the images.linuxcontainers.org server from all ….
>
> Yes, images.linuxcontainers.org is not a real LXD server, it just
> implements parts of the rest API (the public bits).


There was enough of it running to help me figure out I am able to connect to a LDX server at least.

I know the Request Library has a helper app in it deal with all the various provider of certs to make it easier for folks to have to mess around.


But with self signed certs…….. all bets are off.








>
>> Using OS X, Ubuntu host and from Container and all with the same Curl command calls.
>>
>> Which has me wondering why that server and not my local LXD rest server?
>>
>> So far makes zero sense to me and the Rest server should make things simpler in the end.
>>
>>
>>
>> Unless I am missing something in configs or settings some where else… or there is bug.
>>
>>
>> I've chased enough code problems to know when you hammer on it from all possible ways.
>>
>> And it's working part of the time….. some thing is off as it's just not making sense.
>>
>> Plus I am not seeing any mention in LXD docs about need for cert and keys for this kind of call.
>
> I suppose there's no reason we couldn't allow requests without a
> client cert to work for unauthenticated requests; I don't anticipate
> it being a hugely common use case, though, as most people should be
> using a client or API to access LXD.




It was a dim light in the end of tunnel figuring out why some people must having it work and I can't so far.


Either some one is not documented something important in the publically published doc's or ?????????




>
>>
>> If I need them for the local server I would need them for the pulbic server as well since Linuxcontainers is using self signed cert on that site.
>
> images.linuxcontainers.org shouldn't be using a self signed cert; LXD
> does, though.
>


This is what info the lc.org cert shows




> Tycho
>
>>
>>
>> -Kevin
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> Tycho
>>>
>>>>
>>>>
>>>> # OS X term window --> vivid server (same 192.168.x.x network)
>>>> curl -k https://192.168.0.50:8443/1.0/images
>>>> # curl: (35) error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
>>>>
>>>>
>>>>
>>>> If any one has any ideas or suggestions please send them along.
>>>>
>>>> -Kevin
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> lxc-users mailing list
>>>> lxc-***@lists.linuxcontainers.org
>>>> http://lists.linuxcontainers.org/listinfo/lxc-users
>>> _______________________________________________
>>> lxc-users mailing list
>>> lxc-***@lists.linuxcontainers.org
>>> http://lists.linuxcontainers.org/listinfo/lxc-users
>>
>> _______________________________________________
>> lxc-users mailing list
>> lxc-***@lists.linuxcontainers.org
>> http://lists.linuxcontainers.org/listinfo/lxc-users
> _______________________________________________
> lxc-users mailing list
> lxc-***@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
Janjaap Bos
2015-05-23 04:51:34 UTC
Permalink
You should upgrade your local curl, so it uses TLS and not SSL which is no
longer secure, and therefore disabled at the server. I guess the images
repo still accepts SSL.
Op 23 mei 2015 02:14 schreef "Kevin LaTona" <***@studiosola.com>:

>
> This past week or so I ran into an issue of not being able to connect a
> test LXD rest server on my local network.
>
> I've tested this problem out from pretty much every angle I can think of.
>
> Every thing from fresh OS, server, SSL lib installs to upgrades of current
> running apps on my machines.
>
>
> Pretty much unless I am missing some small fundamental piece that is
> preventing current shipping vivid server to allow connections to the LXD
> rest server.
>
> My take is there is a bug .
>
> If this true, what is the best way to let the LXC team know about this to
> see how to get to next step?
>
>
> To sum it up I am able to connect to a public LXD rest server.
>
> # from vivid container --> public LXD server (
> container to public )
> curl -k https://images.linuxcontainers.org/1.0/images
> # {"status": "Success", "metadata": ["/1.0/images/e7ae410ee8abeb6
>
>
> No matter how and from what angle I try connecting to a local test LXD
> rest server it is having connections issues.
>
> # vivid container 10.0.3.5 --> 192.168.0.50:8443 ( container to host
> machine )
> # this container can ping 192.168.0.50
> curl -k https://192.168.0.50:8443/1.0/images
> # curl: (35) error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad
> certificate
>
>
>
> # OS X term window --> vivid server (same 192.168.x.x
> network)
> curl -k https://192.168.0.50:8443/1.0/images
> # curl: (35) error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1
> alert protocol version
>
>
>
> If any one has any ideas or suggestions please send them along.
>
> -Kevin
>
>
>
> _______________________________________________
> lxc-users mailing list
> lxc-***@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
Kevin LaTona
2015-05-23 05:12:19 UTC
Permalink
Thanks… but I actually have no plans to use Curl.

It was the only tool I had that I could test all the various connections with one common tool most folks have.

To see what LXD servers I could or could not connect to.


My core problem is I can connect to a single Public LDX rest server,

But so far after hammering away for about a week now at finding out why I can't hit my local test LXD rest server?

It's only my network and the port is open… but it keeps sending errors and alerts with the same calls to the public one that works.

I have to assume both should responded the same way to the same calls.

But one works the other not.

-Kevin



On May 22, 2015, at 9:51 PM, Janjaap Bos <***@gmail.com> wrote:

> You should upgrade your local curl, so it uses TLS and not SSL which is no longer secure, and therefore disabled at the server. I guess the images repo still accepts SSL.
> Op 23 mei 2015 02:14 schreef "Kevin LaTona" <***@studiosola.com>:
>
> This past week or so I ran into an issue of not being able to connect a test LXD rest server on my local network.
>
> I've tested this problem out from pretty much every angle I can think of.
>
> Every thing from fresh OS, server, SSL lib installs to upgrades of current running apps on my machines.
>
>
> Pretty much unless I am missing some small fundamental piece that is preventing current shipping vivid server to allow connections to the LXD rest server.
>
> My take is there is a bug .
>
> If this true, what is the best way to let the LXC team know about this to see how to get to next step?
>
>
> To sum it up I am able to connect to a public LXD rest server.
>
> # from vivid container --> public LXD server ( container to public )
> curl -k https://images.linuxcontainers.org/1.0/images
> # {"status": "Success", "metadata": ["/1.0/images/e7ae410ee8abeb6
>
>
> No matter how and from what angle I try connecting to a local test LXD rest server it is having connections issues.
>
> # vivid container 10.0.3.5 --> 192.168.0.50:8443 ( container to host machine )
> # this container can ping 192.168.0.50
> curl -k https://192.168.0.50:8443/1.0/images
> # curl: (35) error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate
>
>
>
> # OS X term window --> vivid server (same 192.168.x.x network)
> curl -k https://192.168.0.50:8443/1.0/images
> # curl: (35) error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
>
>
>
> If any one has any ideas or suggestions please send them along.
>
> -Kevin
>
>
>
> _______________________________________________
> lxc-users mailing list
> lxc-***@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
> _______________________________________________
> lxc-users mailing list
> lxc-***@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
Janjaap Bos
2015-05-23 05:18:01 UTC
Permalink
Ok, but you are testing with a curl that does not support TLS. That is why
you cannot connect to that particular LXD instance. Depending on the OS and
distribution, other LXD instances may still support SSL.
Op 23 mei 2015 07:12 schreef "Kevin LaTona" <***@studiosola.com>:

>
>
> Thanks
 but I actually have no plans to use Curl.
>
> It was the only tool I had that I could test all the various connections
> with one common tool most folks have.
>
> To see what LXD servers I could or could not connect to.
>
>
> My core problem is I can connect to a single Public LDX rest server,
>
> But so far after hammering away for about a week now at finding out why I
> can't hit my local test LXD rest server?
>
> It's only my network and the port is open
 but it keeps sending errors and
> alerts with the same calls to the public one that works.
>
> I have to assume both should responded the same way to the same calls.
>
> But one works the other not.
>
> -Kevin
>
>
>
> On May 22, 2015, at 9:51 PM, Janjaap Bos <***@gmail.com> wrote:
>
> You should upgrade your local curl, so it uses TLS and not SSL which is no
> longer secure, and therefore disabled at the server. I guess the images
> repo still accepts SSL.
> Op 23 mei 2015 02:14 schreef "Kevin LaTona" <***@studiosola.com>:
>
>>
>> This past week or so I ran into an issue of not being able to connect a
>> test LXD rest server on my local network.
>>
>> I've tested this problem out from pretty much every angle I can think of.
>>
>> Every thing from fresh OS, server, SSL lib installs to upgrades of
>> current running apps on my machines.
>>
>>
>> Pretty much unless I am missing some small fundamental piece that is
>> preventing current shipping vivid server to allow connections to the LXD
>> rest server.
>>
>> My take is there is a bug .
>>
>> If this true, what is the best way to let the LXC team know about this to
>> see how to get to next step?
>>
>>
>> To sum it up I am able to connect to a public LXD rest server.
>>
>> # from vivid container --> public LXD server (
>> container to public )
>> curl -k https://images.linuxcontainers.org/1.0/images
>> # {"status": "Success", "metadata": ["/1.0/images/e7ae410ee8abeb6
>>
>>
>> No matter how and from what angle I try connecting to a local test LXD
>> rest server it is having connections issues.
>>
>> # vivid container 10.0.3.5 --> 192.168.0.50:8443 ( container to host
>> machine )
>> # this container can ping 192.168.0.50
>> curl -k https://192.168.0.50:8443/1.0/images
>> # curl: (35) error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad
>> certificate
>>
>>
>>
>> # OS X term window --> vivid server (same 192.168.x.x
>> network)
>> curl -k https://192.168.0.50:8443/1.0/images
>> # curl: (35) error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1
>> alert protocol version
>>
>>
>>
>> If any one has any ideas or suggestions please send them along.
>>
>> -Kevin
>>
>>
>>
>> _______________________________________________
>> lxc-users mailing list
>> lxc-***@lists.linuxcontainers.org
>> http://lists.linuxcontainers.org/listinfo/lxc-users
>
> _______________________________________________
> lxc-users mailing list
> lxc-***@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
>
>
> _______________________________________________
> lxc-users mailing list
> lxc-***@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
Kevin LaTona
2015-05-23 05:33:08 UTC
Permalink
I see your point and that makes good sense.

I currently have no idea what version of LXD is running at images.linuxcontainers.org.

If it's older that makes sense as I am running 0.9 and was running 0.7 and had issue with both

Right now I am working on creating certs to see if that solves problem.

At this point I was thinking lc.org would be running latest version.

Thanks for your thoughts.

-Kevin



On May 22, 2015, at 10:18 PM, Janjaap Bos <***@gmail.com> wrote:

> Ok, but you are testing with a curl that does not support TLS. That is why you cannot connect to that particular LXD instance. Depending on the OS and distribution, other LXD instances may still support SSL.
> Op 23 mei 2015 07:12 schreef "Kevin LaTona" <***@studiosola.com>:
>
>
> Thanks… but I actually have no plans to use Curl.
>
> It was the only tool I had that I could test all the various connections with one common tool most folks have.
>
> To see what LXD servers I could or could not connect to.
>
>
> My core problem is I can connect to a single Public LDX rest server,
>
> But so far after hammering away for about a week now at finding out why I can't hit my local test LXD rest server?
>
> It's only my network and the port is open… but it keeps sending errors and alerts with the same calls to the public one that works.
>
> I have to assume both should responded the same way to the same calls.
>
> But one works the other not.
>
> -Kevin
>
>
>
> On May 22, 2015, at 9:51 PM, Janjaap Bos <***@gmail.com> wrote:
>
>> You should upgrade your local curl, so it uses TLS and not SSL which is no longer secure, and therefore disabled at the server. I guess the images repo still accepts SSL.
>> Op 23 mei 2015 02:14 schreef "Kevin LaTona" <***@studiosola.com>:
>>
>> This past week or so I ran into an issue of not being able to connect a test LXD rest server on my local network.
>>
>> I've tested this problem out from pretty much every angle I can think of.
>>
>> Every thing from fresh OS, server, SSL lib installs to upgrades of current running apps on my machines.
>>
>>
>> Pretty much unless I am missing some small fundamental piece that is preventing current shipping vivid server to allow connections to the LXD rest server.
>>
>> My take is there is a bug .
>>
>> If this true, what is the best way to let the LXC team know about this to see how to get to next step?
>>
>>
>> To sum it up I am able to connect to a public LXD rest server.
>>
>> # from vivid container --> public LXD server ( container to public )
>> curl -k https://images.linuxcontainers.org/1.0/images
>> # {"status": "Success", "metadata": ["/1.0/images/e7ae410ee8abeb6
>>
>>
>> No matter how and from what angle I try connecting to a local test LXD rest server it is having connections issues.
>>
>> # vivid container 10.0.3.5 --> 192.168.0.50:8443 ( container to host machine )
>> # this container can ping 192.168.0.50
>> curl -k https://192.168.0.50:8443/1.0/images
>> # curl: (35) error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate
>>
>>
>>
>> # OS X term window --> vivid server (same 192.168.x.x network)
>> curl -k https://192.168.0.50:8443/1.0/images
>> # curl: (35) error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
>>
>>
>>
>> If any one has any ideas or suggestions please send them along.
>>
>> -Kevin
>>
>>
>>
>> _______________________________________________
>> lxc-users mailing list
>> lxc-***@lists.linuxcontainers.org
>> http://lists.linuxcontainers.org/listinfo/lxc-users
>> _______________________________________________
>> lxc-users mailing list
>> lxc-***@lists.linuxcontainers.org
>> http://lists.linuxcontainers.org/listinfo/lxc-users
>
>
> _______________________________________________
> lxc-users mailing list
> lxc-***@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
> _______________________________________________
> lxc-users mailing list
> lxc-***@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
Kevin LaTona
2015-05-23 05:53:24 UTC
Permalink
On May 22, 2015, at 10:33 PM, Kevin LaTona <***@studiosola.com> wrote:

>> Ok, but you are testing with a curl that does not support TLS. That is why you cannot connect to that particular LXD instance. Depending on the OS and distribution, other LXD instances may still support SSL.
>>
>>




I did a quick upgrade of curl to 7.42.1

Now when I try it

/usr/local/Cellar/curl/7.42.1/bin/curl -s --cert server.crt --key server.key -k https://192.168.0.50:8443/1.0/images

I know I don't want to mess with Apple's install of Curl for now.


I get ………… curl: (35) SSL peer handshake failed, the server most likely requires a client certificate to connect

So maybe I am getting closer and some thing is off with the cert I just made.


Would be nice to know what version of LDX is running at linuxcontainers.org

It sure might help saving lots of time chasing after another avenue that in the end may or may not solve problem.

-Kevin
Janjaap Bos
2015-05-23 07:13:49 UTC
Permalink
Yes, you are a step further now that TLS is spoken. However, I would
suggest to first get your test working locally on the lxd server, since my
homebrew OSX curl has further restrictions. You can only use certificates
that are in the keychain:
* WARNING: SSL: CURLOPT_SSLKEY is ignored by Secure Transport. The private
key must be in the Keychain.
* WARNING: SSL: Certificate type not set, assuming PKCS#12 format.

When trying your example on my lxd server, I do the following steps (as
root user).

# cd /root/.config/lxc
# ls
client.crt client.key config.yml servercerts

Now, if you don't have these files, use can get them by doing the following:
# lxc remote add lxc-org images.linuxcontainers.org

This should also initialise the local client certificate if it does not
exist.

Then:
# lxc config trust add client.crt
# lxc config trust list
This should list the fingerprint.

And it should work:
# curl --key client.key --cert client.crt -v -k
https://localhost:8443/1.0/images

(do not use the -s option as it will suppress the output)


2015-05-23 7:53 GMT+02:00 Kevin LaTona <***@studiosola.com>:

>
> On May 22, 2015, at 10:33 PM, Kevin LaTona <***@studiosola.com> wrote:
>
> Ok, but you are testing with a curl that does not support TLS. That is why
> you cannot connect to that particular LXD instance. Depending on the OS and
> distribution, other LXD instances may still support SSL.
>
>
>
>
>
> I did a quick upgrade of curl to 7.42.1
>
> Now when I try it
>
> /usr/local/Cellar/curl/7.42.1/bin/curl -s --cert server.crt --key
> server.key -k https://192.168.0.50:8443/1.0/images
>
> I know I don't want to mess with Apple's install of Curl for now.
>
>
> I get 



 curl: (35) SSL peer handshake failed, the server most likely
> requires a client certificate to connect
>
> So maybe I am getting closer and some thing is off with the cert I just
> made.
>
>
> Would be nice to know what version of LDX is running at
> linuxcontainers.org
>
> It sure might help saving lots of time chasing after another avenue that
> in the end may or may not solve problem.
>
> -Kevin
>
> _______________________________________________
> lxc-users mailing list
> lxc-***@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
Kevin LaTona
2015-05-23 17:01:17 UTC
Permalink
On May 23, 2015, at 12:13 AM, Janjaap Bos <***@gmail.com> wrote:

> Yes, you are a step further now that TLS is spoken. However, I would suggest to first get your test working locally on the lxd server, since my homebrew OSX curl has further restrictions. You can only use certificates that are in the keychain:
> * WARNING: SSL: CURLOPT_SSLKEY is ignored by Secure Transport. The private key must be in the Keychain.
> * WARNING: SSL: Certificate type not set, assuming PKCS#12 format.


When I did all of the steps you suggested the nev version of Curl sent back

curl: (58) SSL: Can't load the certificate "server.crt" and its private key: OSStatus -50


I tried to import the server.crt into keychain and it choked.

Not sure why maybe it just didn't like how I created it or ???



>
> When trying your example on my lxd server, I do the following steps (as root user).
>
> # cd /root/.config/lxc
> # ls
> client.crt client.key config.yml servercerts


Interesting as the config.yaml and servercert where not in my folder just now.

I double checked my steps taken notes and do see I issued a call to lxc remote add lxc-org images.linuxcontainers.org

And it did not load at the the initial call set up time.




>
> Now, if you don't have these files, use can get them by doing the following:
> # lxc remote add lxc-org images.linuxcontainers.org



I did just re call this "remote add" call

And this time it added all the files and not only some of them.



>
> This should also initialise the local client certificate if it does not exist.
>
> Then:
> # lxc config trust add client.crt
> # lxc config trust list
> This should list the fingerprint.
>
> And it should work:
> # curl --key client.key --cert client.crt -v -k https://localhost:8443/1.0/images
>
> (do not use the -s option as it will suppress the output)



/usr/local/Cellar/curl/7.42.1/bin/curl --cert server.crt --key server.key -v -k https://192.168.0.50:8443/

* Trying 192.168.0.50...
* Connected to 192.168.0.50 (192.168.0.50) port 8443 (#0)
* WARNING: SSL: CURLOPT_SSLKEY is ignored by Secure Transport. The private key must be in the Keychain.
* WARNING: SSL: Certificate type not set, assuming PKCS#12 format.
* SSL: Can't load the certificate "server.crt" and its private key: OSStatus -50
* Closing connection 0
curl: (58) SSL: Can't load the certificate "server.crt" and its private key: OSStatus -50



Well it's closer to working now.

I still need to resolve how to get the private cert into to OS X's keychain.


Hopefully if any other OS X users come along and find these notes it will help them get it working or closer to finding out how to get it all going on Macs connecting to Ubuntu 15.04 Vivid.



-Kevin








>
>
> 2015-05-23 7:53 GMT+02:00 Kevin LaTona <***@studiosola.com>:
>
> On May 22, 2015, at 10:33 PM, Kevin LaTona <***@studiosola.com> wrote:
>
>>> Ok, but you are testing with a curl that does not support TLS. That is why you cannot connect to that particular LXD instance. Depending on the OS and distribution, other LXD instances may still support SSL.
>>>
>>>
>
>
>
>
> I did a quick upgrade of curl to 7.42.1
>
> Now when I try it
>
> /usr/local/Cellar/curl/7.42.1/bin/curl -s --cert server.crt --key server.key -k https://192.168.0.50:8443/1.0/images
>
> I know I don't want to mess with Apple's install of Curl for now.
>
>
> I get ………… curl: (35) SSL peer handshake failed, the server most likely requires a client certificate to connect
>
> So maybe I am getting closer and some thing is off with the cert I just made.
>
>
> Would be nice to know what version of LDX is running at linuxcontainers.org
>
> It sure might help saving lots of time chasing after another avenue that in the end may or may not solve problem.
>
> -Kevin
>
> _______________________________________________
> lxc-users mailing list
> lxc-***@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
> _______________________________________________
> lxc-users mailing list
> lxc-***@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
Kevin LaTona
2015-05-23 18:43:29 UTC
Permalink
I am still sorting out issues with OS X SSL certs OS things.

In between that I just ran a test from a LXC container running on my local Vivid host.

Earlier today I re-ran the lxc remote add lxc-org images.linuxcontainers.org call replacing all files at /root/.config/lxc with new in case something there was not in step or bad.


Next I rebooted server and fired up a new container ran a call against the host LXD server and I still am getting errors.


***@c5:~# curl -v -k https://192.168.0.50:8443/1.0/images


* Hostname was NOT found in DNS cache
* Trying 192.168.0.50...
* Connected to 192.168.0.50 (192.168.0.50) port 8443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Request CERT (13):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS alert, Server hello (2):
* error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate
* Closing connection 0


curl: (35) error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate
***@c5:~#



Ran another call against

curl -k https://images.linuxcontainers.org/1.0/images

from this container and it's working fine.


From the curl error message I assuming that the LXD image server is sending out bad certs for servers to use and work from or ????



The version and setup of curl used for test.

***@c5:~# curl -V
curl 7.35.0 (x86_64-pc-linux-gnu) libcurl/7.35.0 OpenSSL/1.0.1f zlib/1.2.8 libidn/1.28 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP




Any one have any thoughts on how to get to next step?

-Kevin
Kevin LaTona
2015-05-23 19:13:17 UTC
Permalink
I noticed I did not run the lxc config trust add client.crt call as suggested earlier.

So I

cd
/root/.config/lxc

lxc config trust add client.crt


then

lxc config trust list

and got to finger prints back



Next ran


curl -v -k https://192.168.0.50:8443/1.0/images

* Hostname was NOT found in DNS cache
* Trying 192.168.0.50...
* Connected to 192.168.0.50 (192.168.0.50) port 8443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Request CERT (13):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS alert, Server hello (2):
* error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate
* Closing connection 0
curl: (35) error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate


***@c5:~#




Unless I am missing another config step here.

Sure looks like the LDX image server is sending out bad certs into the wild.


-Kevin
Janjaap Bos
2015-05-23 19:16:51 UTC
Permalink
Before trying at OSX, make sure it works on your LXD host.

Follow the steps for hacking on:

https://github.com/lxc/lxd

It works for me.
Hacking

Sometimes it is useful to view the raw response that LXD sends; you can do
this by:

lxc config set password foo
lxc remote add local 127.0.0.1:8443
wget --no-check-certificate https://127.0.0.1:8443/1.0/finger
--certificate=$HOME/.config/lxc/client.crt
--private-key=$HOME/.config/lxc/client.key -O - -q



2015-05-23 21:13 GMT+02:00 Kevin LaTona <***@studiosola.com>:

>
>
> I noticed I did not run the lxc config trust add client.crt call as
> suggested earlier.
>
> So I
>
> cd
> /root/.config/lxc
>
> lxc config trust add client.crt
>
>
> then
>
> lxc config trust list
>
> and got to finger prints back
>
>
>
> Next ran
>
>
> curl -v -k https://192.168.0.50:8443/1.0/images
>
> * Hostname was NOT found in DNS cache
> * Trying 192.168.0.50...
> * Connected to 192.168.0.50 (192.168.0.50) port 8443 (#0)
> * successfully set certificate verify locations:
> * CAfile: none
> CApath: /etc/ssl/certs
> * SSLv3, TLS handshake, Client hello (1):
> * SSLv3, TLS handshake, Server hello (2):
> * SSLv3, TLS handshake, CERT (11):
> * SSLv3, TLS handshake, Server key exchange (12):
> * SSLv3, TLS handshake, Request CERT (13):
> * SSLv3, TLS handshake, Server finished (14):
> * SSLv3, TLS handshake, CERT (11):
> * SSLv3, TLS handshake, Client key exchange (16):
> * SSLv3, TLS change cipher, Client hello (1):
> * SSLv3, TLS handshake, Finished (20):
> * SSLv3, TLS alert, Server hello (2):
> * error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate
> * Closing connection 0
> curl: (35) error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad
> certificate
>
>
> ***@c5:~#
>
>
>
>
> Unless I am missing another config step here.
>
> Sure looks like the LDX image server is sending out bad certs into the
> wild.
>
>
> -Kevin
> _______________________________________________
> lxc-users mailing list
> lxc-***@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
Janjaap Bos
2015-05-23 19:26:41 UTC
Permalink
Remove the /finger from the url given in the example, as that is no longer
a published service.

This is from OSX, using wget.

wget --no-check-certificate https://myhost:8443/1.0 --certificate=client.crt
--private-key=client.key -O - -q

{"type":"sync","status":"Success","status_code":200,"metadata":{"api_compat":1,"auth":"trusted","config":{"trust-password":true},"environment":{"backing_fs":"ext4","driver":"lxc","kernel_version":"3.16.0-37-generic","lxc_version":"1.1.0","lxd_version":"0.9"}}}


2015-05-23 21:16 GMT+02:00 Janjaap Bos <***@gmail.com>:

> Before trying at OSX, make sure it works on your LXD host.
>
> Follow the steps for hacking on:
>
> https://github.com/lxc/lxd
>
> It works for me.
> Hacking
>
> Sometimes it is useful to view the raw response that LXD sends; you can do
> this by:
>
> lxc config set password foo
> lxc remote add local 127.0.0.1:8443
> wget --no-check-certificate https://127.0.0.1:8443/1.0/finger --certificate=$HOME/.config/lxc/client.crt --private-key=$HOME/.config/lxc/client.key -O - -q
>
>
>
> 2015-05-23 21:13 GMT+02:00 Kevin LaTona <***@studiosola.com>:
>
>>
>>
>> I noticed I did not run the lxc config trust add client.crt call as
>> suggested earlier.
>>
>> So I
>>
>> cd
>> /root/.config/lxc
>>
>> lxc config trust add client.crt
>>
>>
>> then
>>
>> lxc config trust list
>>
>> and got to finger prints back
>>
>>
>>
>> Next ran
>>
>>
>> curl -v -k https://192.168.0.50:8443/1.0/images
>>
>> * Hostname was NOT found in DNS cache
>> * Trying 192.168.0.50...
>> * Connected to 192.168.0.50 (192.168.0.50) port 8443 (#0)
>> * successfully set certificate verify locations:
>> * CAfile: none
>> CApath: /etc/ssl/certs
>> * SSLv3, TLS handshake, Client hello (1):
>> * SSLv3, TLS handshake, Server hello (2):
>> * SSLv3, TLS handshake, CERT (11):
>> * SSLv3, TLS handshake, Server key exchange (12):
>> * SSLv3, TLS handshake, Request CERT (13):
>> * SSLv3, TLS handshake, Server finished (14):
>> * SSLv3, TLS handshake, CERT (11):
>> * SSLv3, TLS handshake, Client key exchange (16):
>> * SSLv3, TLS change cipher, Client hello (1):
>> * SSLv3, TLS handshake, Finished (20):
>> * SSLv3, TLS alert, Server hello (2):
>> * error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate
>> * Closing connection 0
>> curl: (35) error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad
>> certificate
>>
>>
>> ***@c5:~#
>>
>>
>>
>>
>> Unless I am missing another config step here.
>>
>> Sure looks like the LDX image server is sending out bad certs into the
>> wild.
>>
>>
>> -Kevin
>> _______________________________________________
>> lxc-users mailing list
>> lxc-***@lists.linuxcontainers.org
>> http://lists.linuxcontainers.org/listinfo/lxc-users
>>
>
>
Kevin LaTona
2015-05-23 20:17:55 UTC
Permalink
add local sends back an error

***@kev:/home/kev# lxc remote add local 192.168.0.50:8443

error: remote local exists as <unix:///var/lib/lxd/unix.socket>




running just wget ( I've not used wget before ) so I am not sure how or if it's possible to send in the host name now or ??




***@kev:~/.config/lxc# wget --no-check-certificate https://192.168.0.50:8443/1.0/ --certificate=client.crt --private-key=client.key -O - -v

--2015-05-23 13:12:13-- https://192.168.0.50:8443/1.0/

Connecting to 192.168.0.50:8443... connected.
WARNING: cannot verify 192.168.0.50's certificate, issued by ‘O=linuxcontainer.org’:
Unable to locally verify the issuer's authority.
WARNING: certificate common name ‘’ doesn't match requested host name ‘192.168.0.50’.
HTTP request sent, awaiting response... 404 Not Found
2015-05-23 13:12:13 ERROR 404: Not Found.



Sounds like LXD server is working for you….. but still no idea why it's not for me yet.


-Kevin




On May 23, 2015, at 12:26 PM, Janjaap Bos <***@gmail.com> wrote:

> Remove the /finger from the url given in the example, as that is no longer a published service.
>
> This is from OSX, using wget.
>
> wget --no-check-certificate https://myhost:8443/1.0 --certificate=client.crt --private-key=client.key -O - -q
>
> {"type":"sync","status":"Success","status_code":200,"metadata":{"api_compat":1,"auth":"trusted","config":{"trust-password":true},"environment":{"backing_fs":"ext4","driver":"lxc","kernel_version":"3.16.0-37-generic","lxc_version":"1.1.0","lxd_version":"0.9"}}}
>
>
> 2015-05-23 21:16 GMT+02:00 Janjaap Bos <***@gmail.com>:
> Before trying at OSX, make sure it works on your LXD host.
>
> Follow the steps for hacking on:
>
> https://github.com/lxc/lxd
>
> It works for me.
> Hacking
>
> Sometimes it is useful to view the raw response that LXD sends; you can do this by:
>
> lxc config set password foo
> lxc remote add local 127.0.0.1:8443
> wget --no-check-certificate https://127.0.0.1:8443/1.0/finger --certificate=$HOME/.config/lxc/client.crt --private-key=$HOME/.config/lxc/client.key -O - -q
>
>
> 2015-05-23 21:13 GMT+02:00 Kevin LaTona <***@studiosola.com>:
>
>
> I noticed I did not run the lxc config trust add client.crt call as suggested earlier.
>
> So I
>
> cd
> /root/.config/lxc
>
> lxc config trust add client.crt
>
>
> then
>
> lxc config trust list
>
> and got to finger prints back
>
>
>
> Next ran
>
>
> curl -v -k https://192.168.0.50:8443/1.0/images
>
> * Hostname was NOT found in DNS cache
> * Trying 192.168.0.50...
> * Connected to 192.168.0.50 (192.168.0.50) port 8443 (#0)
> * successfully set certificate verify locations:
> * CAfile: none
> CApath: /etc/ssl/certs
> * SSLv3, TLS handshake, Client hello (1):
> * SSLv3, TLS handshake, Server hello (2):
> * SSLv3, TLS handshake, CERT (11):
> * SSLv3, TLS handshake, Server key exchange (12):
> * SSLv3, TLS handshake, Request CERT (13):
> * SSLv3, TLS handshake, Server finished (14):
> * SSLv3, TLS handshake, CERT (11):
> * SSLv3, TLS handshake, Client key exchange (16):
> * SSLv3, TLS change cipher, Client hello (1):
> * SSLv3, TLS handshake, Finished (20):
> * SSLv3, TLS alert, Server hello (2):
> * error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate
> * Closing connection 0
> curl: (35) error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate
>
>
> ***@c5:~#
>
>
>
>
> Unless I am missing another config step here.
>
> Sure looks like the LDX image server is sending out bad certs into the wild.
>
>
> -Kevin
> _______________________________________________
> lxc-users mailing list
> lxc-***@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
>
> _______________________________________________
> lxc-users mailing list
> lxc-***@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
Janjaap Bos
2015-05-23 20:24:37 UTC
Permalink
Try removing the trailing / from the url.

2015-05-23 22:17 GMT+02:00 Kevin LaTona <***@studiosola.com>:

>
> add local sends back an error
>
> ***@kev:/home/kev# lxc remote add local 192.168.0.50:8443
>
> error: remote local exists as <unix:///var/lib/lxd/unix.socket>
>
>
>
>
> running just wget ( I've not used wget before ) so I am not sure how or
> if it's possible to send in the host name now or ??
>
>
>
>
> ***@kev:~/.config/lxc# wget --no-check-certificate
> https://192.168.0.50:8443/1.0/ --certificate=client.crt
> --private-key=client.key -O - -v
>
> --2015-05-23 13:12:13-- https://192.168.0.50:8443/1.0/
>
> Connecting to 192.168.0.50:8443... connected.
> WARNING: cannot verify 192.168.0.50's certificate, issued by ‘O=
> linuxcontainer.org’:
> Unable to locally verify the issuer's authority.
> WARNING: certificate common name ‘’ doesn't match requested host name
> ‘192.168.0.50’.
> HTTP request sent, awaiting response... 404 Not Found
> 2015-05-23 13:12:13 ERROR 404: Not Found.
>
>
>
> Sounds like LXD server is working for you
.. but still no idea why it's
> not for me yet.
>
>
> -Kevin
>
>
>
>
> On May 23, 2015, at 12:26 PM, Janjaap Bos <***@gmail.com> wrote:
>
> Remove the /finger from the url given in the example, as that is no longer
> a published service.
>
> This is from OSX, using wget.
>
> wget --no-check-certificate https://myhost:8443/1.0 --certificate=client.crt
> --private-key=client.key -O - -q
>
>
> {"type":"sync","status":"Success","status_code":200,"metadata":{"api_compat":1,"auth":"trusted","config":{"trust-password":true},"environment":{"backing_fs":"ext4","driver":"lxc","kernel_version":"3.16.0-37-generic","lxc_version":"1.1.0","lxd_version":"0.9"}}}
>
>
> 2015-05-23 21:16 GMT+02:00 Janjaap Bos <***@gmail.com>:
>
>> Before trying at OSX, make sure it works on your LXD host.
>>
>> Follow the steps for hacking on:
>>
>> https://github.com/lxc/lxd
>>
>> It works for me.
>> Hacking
>>
>> Sometimes it is useful to view the raw response that LXD sends; you can
>> do this by:
>>
>> lxc config set password foo
>> lxc remote add local 127.0.0.1:8443
>> wget --no-check-certificate https://127.0.0.1:8443/1.0/finger --certificate=$HOME/.config/lxc/client.crt --private-key=$HOME/.config/lxc/client.key -O - -q
>>
>>
>>
>> 2015-05-23 21:13 GMT+02:00 Kevin LaTona <***@studiosola.com>:
>>
>>>
>>>
>>> I noticed I did not run the lxc config trust add client.crt call as
>>> suggested earlier.
>>>
>>> So I
>>>
>>> cd
>>> /root/.config/lxc
>>>
>>> lxc config trust add client.crt
>>>
>>>
>>> then
>>>
>>> lxc config trust list
>>>
>>> and got to finger prints back
>>>
>>>
>>>
>>> Next ran
>>>
>>>
>>> curl -v -k https://192.168.0.50:8443/1.0/images
>>>
>>> * Hostname was NOT found in DNS cache
>>> * Trying 192.168.0.50...
>>> * Connected to 192.168.0.50 (192.168.0.50) port 8443 (#0)
>>> * successfully set certificate verify locations:
>>> * CAfile: none
>>> CApath: /etc/ssl/certs
>>> * SSLv3, TLS handshake, Client hello (1):
>>> * SSLv3, TLS handshake, Server hello (2):
>>> * SSLv3, TLS handshake, CERT (11):
>>> * SSLv3, TLS handshake, Server key exchange (12):
>>> * SSLv3, TLS handshake, Request CERT (13):
>>> * SSLv3, TLS handshake, Server finished (14):
>>> * SSLv3, TLS handshake, CERT (11):
>>> * SSLv3, TLS handshake, Client key exchange (16):
>>> * SSLv3, TLS change cipher, Client hello (1):
>>> * SSLv3, TLS handshake, Finished (20):
>>> * SSLv3, TLS alert, Server hello (2):
>>> * error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate
>>> * Closing connection 0
>>> curl: (35) error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad
>>> certificate
>>>
>>>
>>> ***@c5:~#
>>>
>>>
>>>
>>>
>>> Unless I am missing another config step here.
>>>
>>> Sure looks like the LDX image server is sending out bad certs into the
>>> wild.
>>>
>>>
>>> -Kevin
>>> _______________________________________________
>>> lxc-users mailing list
>>> lxc-***@lists.linuxcontainers.org
>>> http://lists.linuxcontainers.org/listinfo/lxc-users
>>>
>>
>>
> _______________________________________________
> lxc-users mailing list
> lxc-***@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
>
>
> _______________________________________________
> lxc-users mailing list
> lxc-***@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
Kevin LaTona
2015-05-24 23:01:31 UTC
Permalink
On May 23, 2015, at 1:24 PM, Janjaap Bos <***@gmail.com> wrote:

> Try removing the trailing / from the url.


Got error message again.





>
> 2015-05-23 22:17 GMT+02:00 Kevin LaTona <***@studiosola.com>:
>
> add local sends back an error
>
> ***@kev:/home/kev# lxc remote add local 192.168.0.50:8443
>
> error: remote local exists as <unix:///var/lib/lxd/unix.socket>
>
>
>
>
> running just wget ( I've not used wget before ) so I am not sure how or if it's possible to send in the host name now or ??
>
>
>
>
> ***@kev:~/.config/lxc# wget --no-check-certificate https://192.168.0.50:8443/1.0/ --certificate=client.crt --private-key=client.key -O - -v
>
> --2015-05-23 13:12:13-- https://192.168.0.50:8443/1.0/
>
> Connecting to 192.168.0.50:8443... connected.
> WARNING: cannot verify 192.168.0.50's certificate, issued by ‘O=linuxcontainer.org’:
> Unable to locally verify the issuer's authority.
> WARNING: certificate common name ‘’ doesn't match requested host name ‘192.168.0.50’.
> HTTP request sent, awaiting response... 404 Not Found
> 2015-05-23 13:12:13 ERROR 404: Not Found.
>
>
>
> Sounds like LXD server is working for you….. but still no idea why it's not for me yet.
>
>
> -Kevin
>
>
>
>
> On May 23, 2015, at 12:26 PM, Janjaap Bos <***@gmail.com> wrote:
>
>> Remove the /finger from the url given in the example, as that is no longer a published service.
>>
>> This is from OSX, using wget.
>>
>> wget --no-check-certificate https://myhost:8443/1.0 --certificate=client.crt --private-key=client.key -O - -q
>>
>> {"type":"sync","status":"Success","status_code":200,"metadata":{"api_compat":1,"auth":"trusted","config":{"trust-password":true},"environment":{"backing_fs":"ext4","driver":"lxc","kernel_version":"3.16.0-37-generic","lxc_version":"1.1.0","lxd_version":"0.9"}}}
>>
>>
>> 2015-05-23 21:16 GMT+02:00 Janjaap Bos <***@gmail.com>:
>> Before trying at OSX, make sure it works on your LXD host.
>>
>> Follow the steps for hacking on:
>>
>> https://github.com/lxc/lxd
>>
>> It works for me.
>> Hacking
>>
>> Sometimes it is useful to view the raw response that LXD sends; you can do this by:
>>
>> lxc config set password foo
>> lxc remote add local 127.0.0.1:8443
>> wget --no-check-certificate https://127.0.0.1:8443/1.0/finger --certificate=$HOME/.config/lxc/client.crt --private-key=$HOME/.config/lxc/client.key -O - -q
>>
>>
>> 2015-05-23 21:13 GMT+02:00 Kevin LaTona <***@studiosola.com>:
>>
>>
>> I noticed I did not run the lxc config trust add client.crt call as suggested earlier.
>>
>> So I
>>
>> cd
>> /root/.config/lxc
>>
>> lxc config trust add client.crt
>>
>>
>> then
>>
>> lxc config trust list
>>
>> and got to finger prints back
>>
>>
>>
>> Next ran
>>
>>
>> curl -v -k https://192.168.0.50:8443/1.0/images
>>
>> * Hostname was NOT found in DNS cache
>> * Trying 192.168.0.50...
>> * Connected to 192.168.0.50 (192.168.0.50) port 8443 (#0)
>> * successfully set certificate verify locations:
>> * CAfile: none
>> CApath: /etc/ssl/certs
>> * SSLv3, TLS handshake, Client hello (1):
>> * SSLv3, TLS handshake, Server hello (2):
>> * SSLv3, TLS handshake, CERT (11):
>> * SSLv3, TLS handshake, Server key exchange (12):
>> * SSLv3, TLS handshake, Request CERT (13):
>> * SSLv3, TLS handshake, Server finished (14):
>> * SSLv3, TLS handshake, CERT (11):
>> * SSLv3, TLS handshake, Client key exchange (16):
>> * SSLv3, TLS change cipher, Client hello (1):
>> * SSLv3, TLS handshake, Finished (20):
>> * SSLv3, TLS alert, Server hello (2):
>> * error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate
>> * Closing connection 0
>> curl: (35) error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate
>>
>>
>> ***@c5:~#
>>
>>
>>
>>
>> Unless I am missing another config step here.
>>
>> Sure looks like the LDX image server is sending out bad certs into the wild.
>>
>>
>> -Kevin
>> _______________________________________________
>> lxc-users mailing list
>> lxc-***@lists.linuxcontainers.org
>> http://lists.linuxcontainers.org/listinfo/lxc-users
>>
>>
>> _______________________________________________
>> lxc-users mailing list
>> lxc-***@lists.linuxcontainers.org
>> http://lists.linuxcontainers.org/listinfo/lxc-users
>
>
> _______________________________________________
> lxc-users mailing list
> lxc-***@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
> _______________________________________________
> lxc-users mailing list
> lxc-***@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
Kevin LaTona
2015-05-25 19:16:54 UTC
Permalink
If one is using Mac OS X 10.8.5, Python 2.7.9, Requests or Curl, unless you can get them config'd to work with TLS1_2, the LXD rest server is not going to work for you.


The simplest way I found so far to connect from a Mac running 10.8.5 to the LDX 0.9 rest server is using a Python Subprocess call via SSH into the host machine which runs a Curl call to the LXD server which then returns the JSON/Dict object.

While it sounds like a round about way to get there, it's the only way I have found so far to bypass the surrounding issue of getting TLS1_2 to run on OS X 10.8.5 and or Python 2.7.9.


If there is any Python users on this list using the Requests module and has it working with both TLS1_2 and the LXD rest server, please share your process.

Thanks
-Kevin
Kevin LaTona
2015-05-26 02:38:12 UTC
Permalink
On May 25, 2015, at 12:16 PM, Kevin LaTona <***@studiosola.com> wrote:

> The simplest way I found so far to connect from a Mac running 10.8.5 to the LDX 0.9 rest server is using a Python Subprocess call via SSH into the host machine which runs a Curl call to the LXD server which then returns the JSON/Dict object.
>
> While it sounds like a round about way to get there, it's the only way I have found so far to bypass the surrounding issue of getting TLS1_2 to run on OS X 10.8.5 and or Python 2.7.9.
>


Well that was one really short lived idea.

Making those ssh based subprocess calls to the host is just not cutting it from me after all, even if it does work the overhead cost to do them kind of kills the idea for all but simple use.

I was really wanting to stick by and use the LXD Rest server and not have to re-invent the wheel here.


Guess it's not going to happen, so instead I've decided to create a Python based Tornado Rest server running on the host and calling the LXD Cli calls.

This way I can back the SSL library down from the TLS1_2 idea. I guess some need that level of security, for now I can live without it.


Plus Tornado opens up some other areas to look at doing some container management like ideas.

So this may turn out better over the long haul until LXD matures and becomes a bit more solid.




>
> If there is any Python users on this list using the Requests module and has it working with both TLS1_2 and the LXD rest server, please share your process.


Again if there is any Pythonista on this LXC mailing list who has been able to get TLS1_2 wrapped and working with Requests.

It would really be great if you could share a blog link or even a bit code as it's one messy thing to get all those parts working.


So in the end LXD rest server is working, but sure is one tough nut to crack right now… hopefully some of these TLS like setup issues will smooth out over time.

-Kevin
Kevin LaTona
2015-05-26 02:38:12 UTC
Permalink
On May 25, 2015, at 12:16 PM, Kevin LaTona <***@studiosola.com> wrote:

> The simplest way I found so far to connect from a Mac running 10.8.5 to the LDX 0.9 rest server is using a Python Subprocess call via SSH into the host machine which runs a Curl call to the LXD server which then returns the JSON/Dict object.
>
> While it sounds like a round about way to get there, it's the only way I have found so far to bypass the surrounding issue of getting TLS1_2 to run on OS X 10.8.5 and or Python 2.7.9.
>


Well that was one really short lived idea.

Making those ssh based subprocess calls to the host is just not cutting it from me after all, even if it does work the overhead cost to do them kind of kills the idea for all but simple use.

I was really wanting to stick by and use the LXD Rest server and not have to re-invent the wheel here.


Guess it's not going to happen, so instead I've decided to create a Python based Tornado Rest server running on the host and calling the LXD Cli calls.

This way I can back the SSL library down from the TLS1_2 idea. I guess some need that level of security, for now I can live without it.


Plus Tornado opens up some other areas to look at doing some container management like ideas.

So this may turn out better over the long haul until LXD matures and becomes a bit more solid.




>
> If there is any Python users on this list using the Requests module and has it working with both TLS1_2 and the LXD rest server, please share your process.


Again if there is any Pythonista on this LXC mailing list who has been able to get TLS1_2 wrapped and working with Requests.

It would really be great if you could share a blog link or even a bit code as it's one messy thing to get all those parts working.


So in the end LXD rest server is working, but sure is one tough nut to crack right now… hopefully some of these TLS like setup issues will smooth out over time.

-Kevin
Tycho Andersen
2015-05-26 23:37:34 UTC
Permalink
Hi Kevin,

On Mon, May 25, 2015 at 07:38:12PM -0700, Kevin LaTona wrote:
>
> On May 25, 2015, at 12:16 PM, Kevin LaTona <***@studiosola.com> wrote:
>
> > The simplest way I found so far to connect from a Mac running 10.8.5 to the LDX 0.9 rest server is using a Python Subprocess call via SSH into the host machine which runs a Curl call to the LXD server which then returns the JSON/Dict object.
> >
> > While it sounds like a round about way to get there, it's the only way I have found so far to bypass the surrounding issue of getting TLS1_2 to run on OS X 10.8.5 and or Python 2.7.9.
> >
>
>
> Well that was one really short lived idea.
>
> Making those ssh based subprocess calls to the host is just not cutting it from me after all, even if it does work the overhead cost to do them kind of kills the idea for all but simple use.
>
> I was really wanting to stick by and use the LXD Rest server and not have to re-invent the wheel here.
>
>
> Guess it's not going to happen, so instead I've decided to create a Python based Tornado Rest server running on the host and calling the LXD Cli calls.
>
> This way I can back the SSL library down from the TLS1_2 idea. I guess some need that level of security, for now I can live without it.
>
>
> Plus Tornado opens up some other areas to look at doing some container management like ideas.
>
> So this may turn out better over the long haul until LXD matures and becomes a bit more solid.
>
>
>
>
> >
> > If there is any Python users on this list using the Requests module and has it working with both TLS1_2 and the LXD rest server, please share your process.
>
>
> Again if there is any Pythonista on this LXC mailing list who has been able to get TLS1_2 wrapped and working with Requests.

I just wrote http://tycho.ws/blog/2015/05/lxd-python.html which works
fine for me on Ubuntu.

I do have an old OSX system laying around so I tried it there and got
an SSL error. It looks like the version of SSL it has only has TLS 1.0
built in. I don't really know anything about OSX, but the obvious
solution seems to be to use the above program and a version of openssl
that has TLS 1.2 compiled in. Perhaps upgrading OSX or using some
package manager to give you an new libssl would work.

Tycho

> It would really be great if you could share a blog link or even a bit code as it's one messy thing to get all those parts working.
>
>
> So in the end LXD rest server is working, but sure is one tough nut to crack right now… hopefully some of these TLS like setup issues will smooth out over time.
>
> -Kevin
>
>
>
>
>
>
> _______________________________________________
> lxc-users mailing list
> lxc-***@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
Kevin LaTona
2015-05-27 01:37:59 UTC
Permalink
On May 26, 2015, at 4:37 PM, Tycho Andersen <***@canonical.com> wrote:

> Hi Kevin,
>
> On Mon, May 25, 2015 at 07:38:12PM -0700, Kevin LaTona wrote:
>>
>> On May 25, 2015, at 12:16 PM, Kevin LaTona <***@studiosola.com> wrote:
>>
>>> The simplest way I found so far to connect from a Mac running 10.8.5 to the LDX 0.9 rest server is using a Python Subprocess call via SSH into the host machine which runs a Curl call to the LXD server which then returns the JSON/Dict object.
>>>
>>> While it sounds like a round about way to get there, it's the only way I have found so far to bypass the surrounding issue of getting TLS1_2 to run on OS X 10.8.5 and or Python 2.7.9.
>>>
>>
>>
>> Well that was one really short lived idea.
>>
>> Making those ssh based subprocess calls to the host is just not cutting it from me after all, even if it does work the overhead cost to do them kind of kills the idea for all but simple use.
>>
>> I was really wanting to stick by and use the LXD Rest server and not have to re-invent the wheel here.
>>
>>
>> Guess it's not going to happen, so instead I've decided to create a Python based Tornado Rest server running on the host and calling the LXD Cli calls.
>>
>> This way I can back the SSL library down from the TLS1_2 idea. I guess some need that level of security, for now I can live without it.
>>
>>
>> Plus Tornado opens up some other areas to look at doing some container management like ideas.
>>
>> So this may turn out better over the long haul until LXD matures and becomes a bit more solid.
>>
>>
>>
>>
>>>
>>> If there is any Python users on this list using the Requests module and has it working with both TLS1_2 and the LXD rest server, please share your process.
>>
>>
>> Again if there is any Pythonista on this LXC mailing list who has been able to get TLS1_2 wrapped and working with Requests.
>
> I just wrote http://tycho.ws/blog/2015/05/lxd-python.html which works
> fine for me on Ubuntu.


Looks good should help folks with correct machine setups to see how easy it can be.



>
> I do have an old OSX system laying around so I tried it there and got
> an SSL error. It looks like the version of SSL it has only has TLS 1.0
> built in. I don't really know anything about OSX, but the obvious
> solution seems to be to use the above program and a version of openssl
> that has TLS 1.2 compiled in. Perhaps upgrading OSX or using some
> package manager to give you an new libssl would work.


It appears the big road block here right now is Apple's use of an outdated OpenSSL library that makes using TSL1_2 impossible with out access to a newer version of OpenSSL.

Maybe that is possible with 10.10 or even 10.9, but right now I need to keep this machine frozen at 10.8.5.


The pylxd app mentioned in your blog looks interesting since it's using unix domain sockets.

If that ends up getting access to lxc calls without having to make ny kind of a subprocess call to command line, it may turn out to be a tad bit faster when interfacing with this Tornado rest server I am working on.


It's pretty clear to me now that if anyone has any client that can not use TSL1_2 that the only way to efficient access a LXD server will be by running their own server on the host as well.

Or totally bypassing LXD and go back to using legacy LXC calls.


If there is any Mac users on the list that know of a way that allows OS X 10.8.5 and Python 2.7.10 to use newer versions of OpenSSL, let me now how you did it, if you care to share.


Tycho ….thanks for looking into this and sharing what you found out.


-Kevin



>
> Tycho
>
>> It would really be great if you could share a blog link or even a bit code as it's one messy thing to get all those parts working.
>>
>>
>> So in the end LXD rest server is working, but sure is one tough nut to crack right now… hopefully some of these TLS like setup issues will smooth out over time.
>>
>> -Kevin
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> lxc-users mailing list
>> lxc-***@lists.linuxcontainers.org
>> http://lists.linuxcontainers.org/listinfo/lxc-users
> _______________________________________________
> lxc-users mailing list
> lxc-***@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
Tycho Andersen
2015-05-27 05:09:14 UTC
Permalink
On Tue, May 26, 2015 at 06:37:59PM -0700, Kevin LaTona wrote:
>
> On May 26, 2015, at 4:37 PM, Tycho Andersen <***@canonical.com> wrote:
>
> > Hi Kevin,
> >
> > On Mon, May 25, 2015 at 07:38:12PM -0700, Kevin LaTona wrote:
> >>
> >> On May 25, 2015, at 12:16 PM, Kevin LaTona <***@studiosola.com> wrote:
> >>
> >>> The simplest way I found so far to connect from a Mac running 10.8.5 to the LDX 0.9 rest server is using a Python Subprocess call via SSH into the host machine which runs a Curl call to the LXD server which then returns the JSON/Dict object.
> >>>
> >>> While it sounds like a round about way to get there, it's the only way I have found so far to bypass the surrounding issue of getting TLS1_2 to run on OS X 10.8.5 and or Python 2.7.9.
> >>>
> >>
> >>
> >> Well that was one really short lived idea.
> >>
> >> Making those ssh based subprocess calls to the host is just not cutting it from me after all, even if it does work the overhead cost to do them kind of kills the idea for all but simple use.
> >>
> >> I was really wanting to stick by and use the LXD Rest server and not have to re-invent the wheel here.
> >>
> >>
> >> Guess it's not going to happen, so instead I've decided to create a Python based Tornado Rest server running on the host and calling the LXD Cli calls.
> >>
> >> This way I can back the SSL library down from the TLS1_2 idea. I guess some need that level of security, for now I can live without it.
> >>
> >>
> >> Plus Tornado opens up some other areas to look at doing some container management like ideas.
> >>
> >> So this may turn out better over the long haul until LXD matures and becomes a bit more solid.
> >>
> >>
> >>
> >>
> >>>
> >>> If there is any Python users on this list using the Requests module and has it working with both TLS1_2 and the LXD rest server, please share your process.
> >>
> >>
> >> Again if there is any Pythonista on this LXC mailing list who has been able to get TLS1_2 wrapped and working with Requests.
> >
> > I just wrote http://tycho.ws/blog/2015/05/lxd-python.html which works
> > fine for me on Ubuntu.
>
>
> Looks good should help folks with correct machine setups to see how easy it can be.
>
>
>
> >
> > I do have an old OSX system laying around so I tried it there and got
> > an SSL error. It looks like the version of SSL it has only has TLS 1.0
> > built in. I don't really know anything about OSX, but the obvious
> > solution seems to be to use the above program and a version of openssl
> > that has TLS 1.2 compiled in. Perhaps upgrading OSX or using some
> > package manager to give you an new libssl would work.
>
>
> It appears the big road block here right now is Apple's use of an outdated OpenSSL library that makes using TSL1_2 impossible with out access to a newer version of OpenSSL.
>
> Maybe that is possible with 10.10 or even 10.9, but right now I need to keep this machine frozen at 10.8.5.
>
>
> The pylxd app mentioned in your blog looks interesting since it's using unix domain sockets.
>
> If that ends up getting access to lxc calls without having to make ny kind of a subprocess call to command line, it may turn out to be a tad bit faster when interfacing with this Tornado rest server I am working on.
>
>
> It's pretty clear to me now that if anyone has any client that can not use TSL1_2 that the only way to efficient access a LXD server will be by running their own server on the host as well.
>
> Or totally bypassing LXD and go back to using legacy LXC calls.
>
>
> If there is any Mac users on the list that know of a way that allows OS X 10.8.5 and Python 2.7.10 to use newer versions of OpenSSL, let me now how you did it, if you care to share.
>
>
> Tycho ….thanks for looking into this and sharing what you found out.

Another option would be to use socat:

https://github.com/raharper/lxd_tools/blob/master/setup.sh#L19
Kevin LaTona
2015-05-28 20:15:03 UTC
Permalink
After chasing down all kind of SSL errors coming from every which way and as it turns out for the most part not from the LDX server .

This shift to using TLSv1.2 in LDX server is a big deal at the OS level on older machines.

Save yourself loads of time and run ( openssl version ) in terminal.

If it's lower than OpenSSL 1.0.1f 6 ( Jan 2014 ) best visit OpenSSL.org to verify what verision you have running will work or not.


For Mac users on the list I ended using Brew and installed a new version of Python 2.7.9 with OpenSSL 1.0.2a 19 (Mar 2015) embedded within Python.

From all I read don't mess with the OpenSSL binary that Apple installed…. Just leave it be.

Also Mac users the LXD client.crt needs to be installed in your key chain… double click the crt and verify you trust the items you want in the popups.

Finally make sure you run a ( lxc config trust add ~/.config/lxc/client.crt ) on the server.


Thanks to all who jumped in here to lend me a hand as in a nutshell when SSL goes sideways it's one huge PITA to fix.

-Kevin




On May 26, 2015, at 10:09 PM, Tycho Andersen <***@canonical.com> wrote:

>>>> Again if there is any Pythonista on this LXC mailing list who has been able to get TLS1_2 wrapped and working with Requests.
>>>
>>> I just wrote http://tycho.ws/blog/2015/05/lxd-python.html which works
>>> fine for me on Ubuntu.
>>
>>
>> Looks good should help folks with correct machine setups to see how easy it can be.
Kevin LaTona
2015-05-27 05:12:37 UTC
Permalink
On May 26, 2015, at 4:37 PM, Tycho Andersen <***@canonical.com> wrote:

> I just wrote http://tycho.ws/blog/2015/05/lxd-python.html which works
> fine for me on Ubuntu.

In Tycho's blog post he was connecting to the LXD server locally.

When one is logging in via a remote client to a LXD rest server what files would be used by the remote client software for the SSL connection given this is a self signed cert?

-Kevin
Tycho Andersen
2015-05-27 14:40:22 UTC
Permalink
On Tue, May 26, 2015 at 10:12:37PM -0700, Kevin LaTona wrote:
>
> On May 26, 2015, at 4:37 PM, Tycho Andersen <***@canonical.com> wrote:
>
> > I just wrote http://tycho.ws/blog/2015/05/lxd-python.html which works
> > fine for me on Ubuntu.
>
> In Tycho's blog post he was connecting to the LXD server locally.
>
> When one is logging in via a remote client to a LXD rest server what files would be used by the remote client software for the SSL connection given this is a self signed cert?

I'm not sure I understand the question. The procedure should be
exactly the same over any TCP connection, whether to localhost or not.

> -Kevin
>
>
>
>

> _______________________________________________
> lxc-users mailing list
> lxc-***@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
Neil Greenwood
2015-05-23 07:52:21 UTC
Permalink
On 23 May 2015 06:53:24 BST, Kevin LaTona <***@studiosola.com> wrote:
>
>I did a quick upgrade of curl to 7.42.1
>
>Now when I try it
>
>/usr/local/Cellar/curl/7.42.1/bin/curl -s --cert server.crt --key
>server.key -k https://192.168.0.50:8443/1.0/images
>
>I know I don't want to mess with Apple's install of Curl for now.
>
>
>I get ………… curl: (35) SSL peer handshake failed, the server most likely
>requires a client certificate to connect
>
>So maybe I am getting closer and some thing is off with the cert I just
>made.
>
>
>Would be nice to know what version of LDX is running at
>linuxcontainers.org
>


Quote from Tycho in a previous response in this thread:
>Yes, images.linuxcontainers.org is not a real LXD server, it just
implements parts of the rest API (the public bits).




I know a bit about TLS/SSL, but I've done no LXD rest calls, so I could be way off below! :-)


I think the problem you are seeing is the difference between a trusted cert (linuxcontainers.org) and a self-signed cert (your server).

It looks like you passed the server certificate above when it was expecting a client one.

Neil
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Continue reading on narkive:
Loading...