- Joined
- Mar 7, 2024
- Messages
- 11
- Reaction score
- 1
Hello, and good morning, good afternoon, or good evening wherever you are.
Let's begin anew with testing the Python abilities of SSD cloud hosting provided by HostMaria in collaboration with 20i after my initial attempt failed.
Before starting, I would like you to familiarize yourself with the way the web server is hosted in this cloud. For the web server, the host uses Apache, and there are apparently separate servers for databases & FTP. The panel automatically updates the Apache config file to point the domain to the specified folder.
Now that the introduction is complete, let's begin with the story.
As soon as I got the host and linked it with the domain, I rushed my way into the file system of the cloud and uploaded the most basic Flask web server you can write.
As I guessed Apache was running on port 80, I opted for port 8000. And the "0.0.0.0" for the default address indicates the server should listen on all available network interfaces. These are all the assumptions I made.
Additionally, I dragged in the requirements.txt file, consisting of the following dependencies:
If you don't know, you can install a bunch of Python packages at once using pip's -r flag and specifying the file. The file must contain packages in the same format as above, one package on a line. Also, you require Python 3.8 for the newer Flask 3.x, and the cloud only provides us with Python 3.6.8. So, we have to stick with Flask 2.x.
To install the packages mentioned in the file, run:
There, I encountered my first problem. I got a "Permission denied: '/usr/local/lib64/python3.6'" error. After a bit of googling, it turns out I was a complete idiot and forgot I didn't have sudo access. Rerunning the command with an extra `--user` flag solved my issue. (The `--user` flag localizes the package install to the user.)
Here's the modified command:
Finally, it was time to run the script, and, voila, the Flask web server was running. But, what? The server was running on the 10.3.4.130 host(the 10.?.?.? IP is for private hosts). Yes, I learned the hard way that 0.0.0.0:8000 serves the only the internal network the cloud is connected with. This was the whole output.
Running it on port 80 had an even worse result, as I got PermissionError: [Errno 13] Permission denied. I should have expected it without administrator permission. I was convinced that the SSD hosting plan wouldn't allow any of the shenanigans with Python web server hosting or even Ruby & Perl hosting, even though they come pre-installed.
Then it hit me. I had a different problem on the NGINX server and got a fix. Maybe, the same approach could be taken for this. The fix was 'reverse proxy'. And it seems like you can do it on the Apache server too. Here's the tutorial from Digital Ocean for anyone wondering. However, you need access to the Apache config file, which I am not allowed to do.
So, I conclude that this hosting plan doesn't allow for Python web server hosting in a domain unless there is a workaround, which you can let me know in the comments, and I'll try it.
Let's begin anew with testing the Python abilities of SSD cloud hosting provided by HostMaria in collaboration with 20i after my initial attempt failed.
Before starting, I would like you to familiarize yourself with the way the web server is hosted in this cloud. For the web server, the host uses Apache, and there are apparently separate servers for databases & FTP. The panel automatically updates the Apache config file to point the domain to the specified folder.
Now that the introduction is complete, let's begin with the story.
As soon as I got the host and linked it with the domain, I rushed my way into the file system of the cloud and uploaded the most basic Flask web server you can write.
Code:
from flask import Flask
app = Flask(__name__)
@app.route('/')
def home():
return 'hello'
app.run("0.0.0.0", 8000)
As I guessed Apache was running on port 80, I opted for port 8000. And the "0.0.0.0" for the default address indicates the server should listen on all available network interfaces. These are all the assumptions I made.
Additionally, I dragged in the requirements.txt file, consisting of the following dependencies:
Code:
Flask==2.0.3
Jinja2==3.0.3
MarkupSafe==2.0.1
typing-extensions==4.1.1
Werkzeug==2.0.3
If you don't know, you can install a bunch of Python packages at once using pip's -r flag and specifying the file. The file must contain packages in the same format as above, one package on a line. Also, you require Python 3.8 for the newer Flask 3.x, and the cloud only provides us with Python 3.6.8. So, we have to stick with Flask 2.x.
To install the packages mentioned in the file, run:
Code:
pip3 install -r requirements.txt
Here's the modified command:
Code:
pip3 install -r requirements.txt --user
Finally, it was time to run the script, and, voila, the Flask web server was running. But, what? The server was running on the 10.3.4.130 host(the 10.?.?.? IP is for private hosts). Yes, I learned the hard way that 0.0.0.0:8000 serves the only the internal network the cloud is connected with. This was the whole output.
Code:
* Serving Flask app 'app' (lazy loading)
* Environment: production
WARNING: This is a development server. Do not use it in a production deployment.
Use a production WSGI server instead.
* Debug mode: off
* Running on all addresses.
WARNING: This is a development server. Do not use it in a production deployment.
* Running on http://10.3.4.130:8000/ (Press CTRL+C to quit)
Running it on port 80 had an even worse result, as I got PermissionError: [Errno 13] Permission denied. I should have expected it without administrator permission. I was convinced that the SSD hosting plan wouldn't allow any of the shenanigans with Python web server hosting or even Ruby & Perl hosting, even though they come pre-installed.
Then it hit me. I had a different problem on the NGINX server and got a fix. Maybe, the same approach could be taken for this. The fix was 'reverse proxy'. And it seems like you can do it on the Apache server too. Here's the tutorial from Digital Ocean for anyone wondering. However, you need access to the Apache config file, which I am not allowed to do.
So, I conclude that this hosting plan doesn't allow for Python web server hosting in a domain unless there is a workaround, which you can let me know in the comments, and I'll try it.