"I have set up an ec2 and pointed a public static Elastic IP to it. It is running here: http://x.x.x.x:443/
However I was not able to setup ssl certificates yet, because I don’t have the domain atm to point to it. Once I point the domain to the above IP address will certbot automatically list this domain name?
I am a bit unsure what is needed besides pointing the domain and setting up certbot to get the Server running. Atm when I try to enter the IP into Oppia App I get a connection timeout."
For the problem with connecting the app to the server, probably there are a couple of things to check:
Check the port no is also entered in the setting connection in the app
Check that it’s listed as http, not https - the default in the app will be https://
For setting up the certificates, once you’ve got the domain set up and pointing to your server, add the domain name into the apache site config file (ServerName my.domain.com), then when you run certbot it’ll pick up the domain from there for generating the certificate.
However, in this specific case, when I open the link (with the proper IP address included in original email), I get the Apache Ubuntu default page, and if I try to access with just http://x.x.x.x (without the port no), then I get a timeout - it should show the Oppia server dashboard page, like this: https://demo.oppia-mobile.org
This might be to do with the AWS security groups… if its only open for https connections (or some IP address range restriction), is just worth checking this first. It may also be best to just check everything is running on plain http and default port 80 first, then start to change to different port etc?
thank you very much I have done this and restarted the server. Is it right, that I also had to change two other entries as can be seen in the screenshot?
Ah yes, I’ve come across this issue before when first setting up the SSL access… what happens is that certbot creates a copy of the original apache conf (for the SSL version) and adds the references to the cert files/port etc. However it doesn’t also amend the WSGIDaemonProcess and WSGIDaemonGroup names, so you end up with 2 the same in the apache conf files.
There are 2 different ways around this… either:
just rename the WSGIDaemonProcess and WSGIDaemonGroup in one of the conf files, eg just adding “-ssl” at the end in the SSL conf file. The actual name is only a reference, so far as I’m aware it doesn’t need to be tied to any other references, so could be “my-ssl-process-group” or anything else you like
or (and best if you want to force everyone to be redirected to SSL connection):
Update the whole of the http apache conf file so auto redirects to SSL, like this:
The oppia.conf file is the one to edit (and totally replace the content)… but warning… only do this full replacement after certbot has auto created a new conf file for SSL.
I realise this now creates a catch-22 (don’t edit the file until after running certbot, but certbot doesn’t run until the file is changed!)… so… you should be able to comment out the WSGIDaemonProcess and WSGIProcessGroup lines in oppia.conf, then run the certbot, which will then (hopefully) create a new conf all ok (likely this will be called oppia-le-ssl.conf or similar), then you can uncomment and edit the files and restart apache
For removing the dev server message: edit the file: /home/oppia/django-oppia/oppiamobile/settings_secret.py and change DEBUG=True to be DEBUG=False (likely will need apache server restart after to take effect)
For the password changes…
MySQL - here are some instructions: https://www.mysqltutorial.org/mysql-changing-password.aspx - note that the MySQL version is 8.x and change the root and oppiauser account passwords. After changing the oppiauser password, you’ll need to update the same settings_secret.py file as above to put in the updated database password
For the django password- this is easier, just log in on the dashboard via the url and you can change the password (and other profile info) under the edit profile (drop down in top right)
Hope that helps and let me know how you get on
Cheers,
Alex
Removing dev server message worked just fine, so did changing the django user thanks a lot!
However I am not sure where to enter this SQL commands? Is the url of the db the same as the server? Thought about connecting with something like pgadmin for mysql
Thank you so much you have been a very big help for a greenhorn in devops stuff.
No worries and good to know it worked!
For the redirect, there are often lots of ways to do this! With mod_rewrite, as I understand at least, it’ll then also redirect if someone goes to a specific page, eg http://example.com/my/page would then redirect to the https version, but I don’t think only using Redirect will (though I’m not 100% sure, and also not sure what would actually happen)
For the SQL commands, we don’t have any webadmin site automatically set up for this on the AWS machine image, we just use the command line for this (as rarely need to do anything directly in the db)… so, when ssh’d into the server run:
> mysql -uroot -p
(enter password)
then you’ll see the prompt change to: “mysql>” and that’s where you can enter the sql commands (usually must have a “;” at end of command for it to then run)
To me it seems like I get always redirected to the https.
Everything else worked like a charm Thank you so much!
We will have to change the domain in the future, how do I do this without messing up the certstuff again? Can I just alter the ServerName in oppia.conf from above and rerun Certbot? Or will this cause problems because the original conf is not there anymore?
Great to know you have it all running now. Interesting to know about the redirect and making it simpler!
For changing the domain name and new certificates, I’ve not needed to do this before, so I’m not totally sure, there are probably several different options…
Update the current cert name, then re-run certbot
Update the current cert name, then re-run certbot, but with the “–certonly”" command, this generated the certs, but doesn’t update the apache conf files, so you’d just need to edit manually the paths to the certs
I’m sure it’ll be possible to have 2 different domains names in the same apache conf file at the same time, then re-run certbot.
Option 2 is the one I’m most confident about. Anyway, hope it gives some idea, and I’d be interested to know which you choose and if it all works ok.
Cheers,
Alex
Hi @alex
By Certname I assume you mean ServerName in oppia-le-ssl.conf right? and also WSGIDAEMONPROCESS & WSGIDAEMONPROCESSGROUP have to be changed accordingly and then I rerun certbot with --certonly and later change the path to the new .pem files right?
Edit: Would only make sense to update oppia.conf too right? Will do this after I ran certbot with --certonly?
Cheers,
Sirofjelly
@sirofjelly Ah yes sorry, my mistake, I meant updating the ServerName (not the CertName).
You shouldn’t need to change the WSGIDAEMONPROCESS & WSGIDAEMONPROCESSGROUP names, if they’re already running and working with the current http and https - as these names are just references. So it should only be the ServerName and the references to the .pem files that you’ll need to changes.
For the oppia.conf, yes you should update this too so that it redirects correctly to the new domain name.
Cheers,
Alex
Hi @sirofjelly
I’m not exactly sure what might be going wrong here, it looks like it might be more to do with the domain name not matching to the ip address, so you might want to check that the domain name is pointing at the correct IP address. It doesn’t look so much to do with specifically the SSL updates (but it might be)
The IP address could change if the server is taken offline in AWS, unless you’ve assigned an Elastic IP to the machine (“Elastic IP” is essentially AWSs way of saying static IP).
I looked up the IP that the domain name is pointing to (“34.248.127.184”) and this also looks to be invalid (with either non-SSL or with SSL - http://34.248.127.184)
So certainly I’d first suggest checking the IP that’s assigned to the AWS machine and making sure the domain name is pointing to that,
Let me know how you get on,
Cheers,
Alex
I have assigned an elastic IP long time ago I guess it is a probem with the SSL updates, since I can connect to 34.248.127.184 via ssh. And 34.248.127.184 is actually the right ip adress pointing to the ec2 instance.
Hi @sirofjelly,
I’ve tried just doing a ping test to that IP address and I don’t get any answer back. Like Alex said, for it to be an SSL problem, at least the webserver should be reachable (and it would only raise some issue when accessing through HTTPS).
What is weird is that you can access via SSH… Maybe you have some security rules that block any inbound request except from specific addresses?