Gunicorn, python, ubuntu

Help
1

under ubuntu 22.04.05 were using python3.10 with gunicorn and letsencrypt on ports between 15000 and 30000. this ist only for students.
using
/usr/bin/gunicorn3 --keyfile=privkey.pem --certfile=fullchain.pem --bind 0.0.0.0:15555 auth:app

the connection is secured (we've the group permission for privkey set to "r" and put the students in the group)

after an inplace upgrade to 24.04.2 (python 3.12 - same gunicorn version) the secure connection fails with SSL_ERROR_RX_RECORD_TOO_LONG
and i cannot find any hint whats wrong!

any help?

2

I see this error often when someone is trying to do HTTPS to a HTTP port. How and where did you get that error? Does gunicorn provide any logging?

4 Likes
3

I also can't reproduce your issue on Python 3.12 and Gunicorn 23.0.0 (the latest in Gentoo's repository).

1 Like
4

i started gunicorn in debug mode and the output shows no difference in 22.04 and 24.04.
in the debug file the keyfile and cerfile are mentioned so i guess they are read.

5

in the 24.04 ubuntu repository gunicorn is on 20.1.0. i will somehow try to upgrade gunicorn.
i'm not convinced thats an letsencrypt problem.

a curl -vvv shows

  • OpenSSL/3.0.13: error:0A00010B:SSL routines::wrong version number
  • Closing connection
    curl: (35) OpenSSL/3.0.13: error:0A00010B:SSL routines::wrong version number

as error..
very strange

6

I'm not convinced this is a Let's Encrypt issue at all (the cert and key haven't changed), but most likely an implementation problem at Gunicorns side.

What's the exact curl command and the exact gunicorn command at that point? With their exact outputs?

2 Likes
7

/usr/bin/gunicorn3 --keyfile=/etc/letsencrypt/live/$FQDN/privkey.pem --certfile=/etc/letsencrypt/live/FQDN/fullchain.pem --log-level debug --bind 0.0.0.0:15555 auth:app

curl -vvv https://:15555$FQDN

  • Host $FQDN:15555 was resolved.
  • IPv6: (none)
  • IPv4: xxx.xxx.xxx.xxx
  • Trying xxx.xxx.xxx.xxx:15555...
  • Connected to $FQDN (xxx.xxx.xxx.xxx) port 15555
  • ALPN: curl offers h2,http/1.1
  • TLSv1.3 (OUT), TLS handshake, Client hello (1):
  • CAfile: /etc/ssl/certs/ca-certificates.crt
  • CApath: /etc/ssl/certs
  • OpenSSL/3.0.13: error:0A00010B:SSL routines::wrong version number
  • Closing connection
    curl: (35) OpenSSL/3.0.13: error:0A00010B:SSL routines::wrong version number

thats all I got from curl (as i wrote under 22.04.5 i got an secure connection)
as i learned there seems no way to upgrade the gunicorn version on ubuntu to 23.0

thank you for your time.....

8

Well, wrong version number is something different than "SSL_ERROR_RX_RECORD_TOO_LONG" I guess.

I just downgraded my Gunicorn 23.0.0 from the Gentoo repository to your 20.1.0 using pip and now I'm getting errors too..?

Looks like something is horribly broken in Gunicorn 20.1.0.. When I run a pip install --upgrade gunicorn from the venv, everything works again suddenly.

Also, Gunicorn 20.1.0 is 4 years old and it has seen numerous changes since then, see Changelog - 2021 — Gunicorn 23.0.0 documentation or more exact, all the other more recent changelogs.

Support for Python 3.11 was added to Gunicorn 21.0.0, so your old version isn't even supported on Python 3.12 at all, that was added in 22.0.0.

3 Likes
9

ok, thank you for your effort. now its clear. unfortunately its not easy to upgrade gunicorn on ubuntu.
Again thank you very much!

1 Like
10

Sure it is, just run it in a Python virtual environment (venv). Not ideal (makes maintenance a little bit more difficult, as it's not handled by the Ubuntu packaging system), but lets you run the most recent version.

Also, these older versions of Gunicorn seem to be suffering from security flaws, which were fixed in more recent versions.. Do you have these things connected to the public internet?

2 Likes
11

yes, i will try venv an no they're not publicly accessible!

again thank you for your helo and input!

2 Likes
12

A quick comments, in addition to the excellent ones above:

  • gunicorn, uwsgi, etc servers should always be installed via the virtualenv for your Python app. This isn't unique to ubuntu deployments, but for every linux distribution. The same holds true for every library in your application. The reason is due to a mix of being current, but also being able to use version pinning and keep your application fully independent of the server architecture.

Are you terminating SSL on gunicorn for a specific reason, or is this an artifact from some departmental allocation policy on this sever? Given the higher ports, I assume this traffic is proxied - but if not a standard practice is to have something that handles high concurrency (like nginx) be the "public" connection for the appserver, and it is often easier to terminate SSL on that while you're at it.

1 Like
13

Well, I didn't really go into this, because I read "this ist only for students" and I assumed this was for some kind of IT course to learn stuff about this. Not really for production environments. But I could be wrong of course :slight_smile:

1 Like
14

I was split between thinking the setup is because of that, but also knowing how F'd-Up a lot of institutional computing systems are when it comes to provisioning server resources.

2 Likes
15

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.