A Public LXD Image Repository

LXD
1

In order to learn more about how to create and populate an LXD remote Image repository I have created a Server on the Hetzner “cloud” and in that Server created a Public LXD Image repository.

In that repository I have created 24 initial LXD Images which, hopefully, you will be able to access and launch locally.

These images include the likes of Drupal, Joomla, WordPress, Plex, NextCloud etc.

I have uploaded a PDF (ciab-lxd-images.pdf) describing the steps to access and launch images from the server as well as a fairly detailed list and description of each of the Image’s application.

Each Image once launched by you will require you to “lxc exec cn_name bash” and initiate the installation of the actual software but I believe in all cases this should be fully automated.

In each container launched from these images you will find a short README type file, an installation script you will have to execute and possibly one or more other files that should be self-explanatory.

NOTE 1: I have launched and then installed each of these myself and from my limited testing they all seem to work.

NOTE 2: I could have pre-installed each application but I realize that others may feel more comfortable doing the actual application installation in the container them selves. I realize that my value add in this has only been to create the repository and the images and to pre-populate those images with application installation scripts which enable you to get a working application. But I hope it saves you all some time and lets you experiment with some of the applications.

NOTE 3: The NextCloud image has been pre-installed via its SNAP package BUT no NextCloud accounts have been created on it. So if you launch the NextCloud image you can access it via your Host Web Browser and as default with NextCloud … the first log-in becomes the Admin account for that NextCloud.

I am paying for this Hetzner Cloud server and will leave it up for an indeterminant time period but if costs/expense becomes too much I will let you all know before I shut if off.

You can read about the CIAB Public LXD Image repository in the PDF (ciab-lxd-images.pdf) I uploaded to github here:

https://github.com/bmullan/ciab-lxd-image-repository

Please let me know if anything is broken as this was my first attempt at doing this :slight_smile:

By the way (CIAB = cloud in a box) was an acronym I used when helping local schools with volunteer projects.

Brian

3 Likes
2

Thank you for this, I believe this can be used in the same way we use docker hub, right?

3

read the pdf on github and it should explain things (I hope).

https://github.com/bmullan/ciab-lxd-image-repository/blob/master/ciab-lxd-images.pdf

4

You should get a DNS record for that server, then get a letsencrypt.org issued certificate and use that for your server. Should all be free and will make it much easier for people to add your server as a remote.

5

Thanks Stephane

I’ve never done that before so I’d have to read about what the steps are to configure it.

Right now I’m just hoping that it all works ok for people as configuring the public repository was
new to me :wink:

Brian

6

Is not a public repository, but I actually use own xenial container image, which is a way smaller on the size, than a default one.
You could add it to your public repository, if you want.

https://github.com/cryptofuture/lxd-image-xenial-light

7

LXD has a certificate at environment.certificate that is shown with lxc info. Also shows the fingerprint of that certificate. Looks like

    Issuer: O=linuxcontainers.org, CN=root@computer
    Validity
        Not Before: Sep 29 10:55:25 2017 GMT
        Not After : Sep 27 10:55:25 2027 GMT
    Subject: O=linuxcontainers.org, CN=root@mycomputer
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            Public-Key: (4096 bit)

That’s a certificate and and has just the public key.

Further looking, shows that the keypair is (for the snap) at /var/snap/lxd/common/lxd/server.key and /var/snap/lxd/common/lxd/server.crt.

I assume that a user would

  1. Use letsencrypt with the http-01 challenge to get the certificate from Let’s Encrypt.
  2. Copy the two files (private key and certificate chain) to /var/snap/lxd/common/lxd/server.key and /var/snap/lxd/common/lxd/server.crt respectively.
  3. Restart LXD

Is that right?

1 Like
8

Yep, that’s correct, you can replace the self-generated certificate with any other valid TLS certificate.

9

I also “tried” to get this working.
I installed a letsencrypt certificate (files: /var/lib/lxd/server.crt and /var/lib/lxd/server.crt) and restarted lxd then with server lxd restart. I can access my server (the url is https://wpexpress.de:8443 - via browser and can connect and see the green closed lock, the same certificate is also used for the webpage (https://wpexpress.de/) and works there.

Does anynone understand what is going on here?
my ‘server’ is (wpexpress.de) with the certificate from letsecrypt:

root@wpexpress.de /etc/nginx/sites-enabled $ lxc info | tail -n 15
    BKzXEJp9W2yLZbNVD0LV9W3wvbcLzeZ1opcLRukMQwuf4VHiO2Ythyq8aRGVzRpr
    n6dg1Y+aphlbexIpRdE1Ps9w044SZl7Mx5QaPjQF5ulxQCMXCrvKMsurLSjuoAFD
    4YK9lFw0JhcGXyvoYDonAKv0S8tWDtvv4MgCMyng5g==
    -----END CERTIFICATE-----
  certificate_fingerprint: dbdc748bef0e32bc7d9397ed11f6610a1985c6c0ac5126fcc72bf256c2a85c6a
  driver: lxc
  driver_version: 2.1.1
  kernel: Linux
  kernel_architecture: x86_64
  kernel_version: 4.4.0-104-generic
  server: lxd
  server_pid: 28351
  server_version: "2.21"
  storage: zfs
  storage_version: 0.6.5.6-0ubuntu16

and the ‘client’ is another server in another datacenter, which I want to ‘remote add’:

root@vmd25820.contaboserver.net ~ $ lxc remote add wpexpress wpexpress.de

Certificate fingerprint: dbdc748bef0e32bc7d9397ed11f6610a1985c6c0ac5126fcc72bf256c2a85c6a
ok (y/n)? y
error: Get https://wpexpress.de:8443/1.0: x509: certificate signed by unknown authority

root@vmd25820.contaboserver.net ~ $ curl 'https://wpexpress.de:8443' -Ivv
* Rebuilt URL to: https://wpexpress.de:8443/
*   Trying 173.212.247.230...
* Connected to wpexpress.de (173.212.247.230) port 8443 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 594 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
* server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
* Closing connection 0
curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.
root@vmd25820.contaboserver.net ~ $ curl 'https://wpexpress.de:8443' -Ivvk
* Rebuilt URL to: https://wpexpress.de:8443/
*   Trying 173.212.247.230...
* Connected to wpexpress.de (173.212.247.230) port 8443 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 594 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
*        server certificate verification SKIPPED
*        server certificate status verification SKIPPED
*        common name: wpexpress.de (matched)
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #3
*        subject: CN=wpexpress.de
*        start date: Fri, 23 Feb 2018 15:44:51 GMT
*        expire date: Thu, 24 May 2018 15:44:51 GMT
*        issuer: C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
*        compression: NULL
* ALPN, server did not agree to a protocol
> HEAD / HTTP/1.1
> Host: wpexpress.de:8443
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Content-Type: application/json
Content-Type: application/json
< Date: Fri, 23 Feb 2018 18:04:32 GMT
Date: Fri, 23 Feb 2018 18:04:32 GMT
< Content-Length: 114
Content-Length: 114

Sorry for the long text-post, but I am little clueless here.

10

I answer my own question (for reference if others stumble in the future about it):

For me the problem was not related to certificate stuff, but was solved after I installed LXD Version 2.21 on my “client-server”, I did this by:

apt install lxd=2.21-0ubuntu3~16.04.1 lxd-client=2.21-0ubuntu3~16.04.1