An easy-to-use web service for compiling DSDL

@clydej It appears that the plain HTTP version of the site at http://nunaweb.uavcan.org does not load correctly. Perhaps we should add a redirect?

This is something we still need to decide. The problem is that Let’s Encrypt uses port 80 to check and renew the security certificate for the SSL port. If you want port 80 to redirect to 443, then we will need schedule downtime for the site periodically (say, once a week) to free up the port for the certificate check. We do this for the uavcan.org website but I am not sure if we need it for this one too.

I think it’s likely a good idea. Users might be confused if they accidentally visit the http version of the site and get a “site down” message.

Hi folks, I’ve been watching this thread silently until now – nunaweb looks to be an exciting addition to the UAVCAN ecosystem!

I had a look at the repo and deduced that certbot is the Let’s Encrypt client of choice here. We can do one better and avoid any service downtime, by using the certbot ‘webroot’ mode, as follows:

  • invoke certbot with something like certbot certonly --webroot --webroot-path /path/to/my/webroot, which is an option designed to let your existing webserver serve the HTTP-01 challenge tokens

  • mount /path/to/my/webroot/.well-known/acme-challenge/ in nunaweb-proxy to a path like /run/acme-challenge (or whatever)

  • add this to nginx.conf:

    location /.well-known/acme-challenge/ {
        alias /run/acme-challenge/;
    }

It might look a bit odd to ‘pipe in’ the challenges from the host environment into the container, but given that the proxy container is claiming port 80 already it’s probably the simplest way.

And also: one would need to reload nginx in the container, so maybe run docker exec -it nunaweb-proxy nginx -s reload on the host after renewal. This too can be automated in certbot using a hook, although I’d have to read some docs to remember how exactly.

1 Like

When I visit http://nunaweb.uavcan.org from a completely clean browser (clean cache), I am redirected to HTTPS as expected. How do you reproduce this?

It must be a client-side redirect in your browser. Curl shows the port is closed.

$ curl http://nunaweb.uavcan.org
curl: (7) Failed to connect to nunaweb.uavcan.org port 80: Connection refused

I get a blank page or an “Unable to connect” message in my browsers.

I confirm that the application is now functioning correctly.

As we just discussed with Clyde off the forum, he will be working on this now. I believe this is the last item that is holding us from calling this thing production-ready. @bbworld1 can you confirm?

Thanks Edwin. It is using the ‘standalone’ mode at the moment but we can try the ‘webroot’ mode. I will start a new branch for this.

1 Like

@ebb I have implemented your suggestions in the port80 branch. It is pending review for merging into main. The --dry-run renew was successful and I have added a deploy-hook to reload nginx after renewal. We can see how it goes when it is deployed to production.

1 Like

I believe this is the last item that is holding us from calling this thing production-ready.

I believe so! Everything else is just extra improvements and maintainability fixes, such as adding tests and features. Once it’s fully deployed everything should be good to go :slight_smile:

I have merged the changes into main and confirmed the redirection works. The scheduled certbot check ran without error. I also ran it manually with the --dry-run option and it passed successfully (although it skipped the deploy-hook).

There is a pending PR to tighten up the security of the app which will affect the production environment. If this is approved, it can be merged into main and we can do a final health check on the app. I will leave it to @bbworld1 and @pavel.kirienko to approve these changes.

2 Likes