1

I’ve recently tested and deployed a flask app as the minusthemiddleman website. All of the functions tested and worked in the sandbox by multiple testing methods before deployment to nginx and uwsgi in production. For some reason page 2 of the search function causes a resource problem in app as deployed. I’ve had a chance to monitor the redis directly using $redis-cli monitor and check my pip list to make everything is installed in production correctly.

The specific error is: Internal Server Error The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.

Does anybody have ideas as to why this is malfunctioning? Thanks,

tlmtransmogrify
  • 21
  • 3
  • Which service? Have you reviewed the Cloud Logging entries for error messages? – John Hanley Apr 25 '21 at 00:21
  • Hi John, I am new to GCP Cloud Computing and appreciate the heads up on the existence of Cloud Logging. I did not realize it was available previous to your post. I found cloud.google.com/logging, and https://cloud.google.com/logging/docs/setup/python on the GCP and I am looking forward to making this available to find the nature of the malfunction. I hope these are the right ones to use. I will post once I get a more exact answer as to what is failing in the process. Thanks again for the information and quick response! – tlmtransmogrify Apr 26 '21 at 13:50
  • I have tested this further in uwsgi using the $ uwsgi dev.ini to find the problem. Apparently, one of the session variables is not available to session. I use ‘thecurrentpage’ to keep track of the current page of the search the user is executing. For some reason, this variable started working again in this uswgi test environment to port 9090 once a few print lines were added into the code. The problem persists in production. BTW, the actual error is: Apr 29 19:22:46 minusthemiddleman uwsgi[3048]: KeyError: 'thecurrentpage' Thanks all, and Have a Great Day!! – tlmtransmogrify Apr 29 '21 at 21:11
  • I've gone through the process of making the session permanent on the application and have the same result. I was wondering if using gunicorn instead of uwsgi would help to preserve the session data during execution. I'm still getting a keyerror for one of the session variables and I've run some significant debugging in production to try to find other problems and I don't see any now. You can experience the malfunction first hand at www.minusthemiddleman.com. Thanks – tlmtransmogrify Apr 30 '21 at 19:42
  • Still working on it and also exploring the use of gunicorn as a possible replacement for uwsgi. Some of the reading that I've run across seems to hint at gunicorn as more capable for a python flask app deployment than uwsgi is. Some of the articles seem to indicate that uwsgi is faster. There's definitely a lot of material out there. Thanks – tlmtransmogrify May 04 '21 at 13:47
  • There seems to be a SEO benefit to switching the website to ssl operation such as https. I will still use Nginx and some sort of public and private key pair in a seperate directory and reference by my nginx conf file. This may fix it and it's my best guess now. I have found no actual web references for whether or not this will fix the original error or if this is just a good process improvement in general. So I will push forward with it on the merits that it will be a process improvement with a chance of changing the environment that production is executed in. Maybe it will fix it. Thanks – tlmtransmogrify May 05 '21 at 15:07
  • Conversion to https operation seems to go well. Just need to incorporate the letsencrypt key pair into the nginx operation and it should be done. – tlmtransmogrify May 09 '21 at 16:50
  • It's interesting, I'm getting exactly the same error code. SSL: error:0909006C:PEM as a post on Stack overflow. After updating to crt and key Ngnix is not responding well to the changes and won't revert back to previous settings using the old er config file. It's almost working. One good point is that the ssl verifier that was mentioned states my .crt and .key file are not acceptable and that might be a good place to start from https://www.sslchecker.com/certdecoder as mentioned in thread https://stackoverflow.com/questions/63030755/error-error0909006cpem-routinesget-nameno-start-line-node. – tlmtransmogrify May 11 '21 at 17:55
  • I’ve found a new way to determine if the cert is valid on the ubuntu server from the command line. $ openssl x509 -text -noout -in /etc/letsencrypt/csr/somesslcertificate.crt This seems to validate that the certs are not working. Also nginx won’t revert back to working on http even when I change the configs back and double check my permissions and change them for ufw. I am considering uninstalling nginx and certbot and then reinstalling them. So just to recap, it worked for a moment but when I attempted to add https functions it failed and won’t reset to http operation. – tlmtransmogrify May 13 '21 at 11:31
  • I went ahead and toggled some things. The server, the firewall rules, stopped the app, and made sure no extra port 80s were open. Anydesk and google seem to burn two port 80 connections, but I got rid of the other three. I read somewhere that having them active can mess with nginx on start up. I have also created a public.key because ngnix keeps looking for it: nginx: [emerg] PEM_read_bio_X509_AUX("/etc/letsencrypt/keys/public.key") failed (SSL: error:0909006C:PEM routines:get_name:no start line:Expecting: TRUSTED CERTIFICATE) nginx: configuration file /etc/nginx/nginx.conf test failed – tlmtransmogrify May 14 '21 at 11:01
  • Changes the header in public from -----BEGIN PUBLIC KEY----- to -----BEGIN TRUSTED CERTIFICATE----- seems to give a new error. Which is promising because that’s proof that this file is significant. Although I’m not sure why. If ngnix has the fullchain.pem and a private key already then I’m pretty sure that it can create the public from the fullchain like I did. I guess it’s just more convenient to have it on hand for distribution. – tlmtransmogrify May 14 '21 at 11:02
  • sudo nginx -t nginx: [emerg] PEM_read_bio_X509_AUX("/etc/letsencrypt/keys/public.key") failed (SSL: error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag error:0D06C03A:asn1 encoding routines:asn1_d2i_ex_primitive:nested asn1 error error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:Field=serialNumber, Type=X509_CINF error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:Field=cert_info, Type=X509 error:0906700D:PEM routines:PEM_ASN1_read_bio:ASN1 lib) nginx: configuration file /etc/nginx/nginx.conf test failed – tlmtransmogrify May 14 '21 at 11:02
  • I went ahead and purged nginx and reinstalled. Made a backup of the clean nginx copy this time. HTTP only shouldn’t matter in the regular sense. The regular sense being the use of form data for login and passwords between the html5 and the python code in Flask. This site doesn’t use form in that way. SEO will be affected directly of course. I found a thread that offered some promise towards a solution using gunicorn https://stackoverflow.com/questions/67533643/nginx-doesnt-switch-from-http-to-https. Unfortunately, there is no conclusive answer so that I may find a parallelism to this issue. – tlmtransmogrify May 15 '21 at 21:32

0 Answers0