On Mon, Dec 19, 2022 at 05:43:28AM +0000, indivC wrote:
> What I'm trying to do is display a python file
> that has imbedded HTML within a web browser.
...
> Within a browser, I want to be able to access this file
> and see 'Hello World' displayed.
OK, so you basically want to write a web application in Python.
It seems that you are doing this as an educational/learning
project, which was not obvious to me from your original email, and
judging from the replies you got, probably not obvious to other
people either. But no worries, let's look at what's needed.
> Where does this file need to be placed?
> What configuration changes need to be made to make this work?
The first thing to understand is that there are several ways to
do what you want to do. Quite a lot of different ways, actually.
> Currently, httpd(8) is running
> and I'm able to access HTML files via a web browser.
Good start. You've got static content working.
> I've seen mentions online that I needed to run slowcgi(8)
> in order to get this to work,
That's ONE way of doing it. Definitely NOT the best way for a
real application, but if you're just learning this then it's
probably the easiest^Wleast difficult way in.
> so I did 'rcctl enable slowcgi' and
> 'rcctl start slowcgi'.
If you've been reading stuff from different sources, some
confusion may have crept in about the whole cgi, and fastcgi stuff.
There is no real standard called 'slowcgi'. The original standard
was just called CGI, and for many years this is what webservers
implemented to run external programs that created dynamic content.
Later, the FastCGI standard was developed to avoid the shortcomings
of CGI, (such as the poor performance caused by needing to fork for
every new invocation of the external program), and webservers began
to implement the FastCGI standard.
In OpenBSD, the native httpd ONLY implements FastCGI. In order to
use the original CGI standard, a wrapper was created that invokes
the CGI program and passes it's output to httpd as if it was a
FastCGI program. That wrapper is called slowcgi.
> Then, I placed 'hello_world.py' in '/var/www/htdocs/test/'
> and then added the 'location' configuration to '/etc/httpd.conf'.
> Below is the full 'httpd.conf':
> server "test" {
> listen on 10.1.1.1 port 80
> root "/htdocs/test"
> location "*.py" {
> fastcgi
> root "/htdocs/test"
> }
> }
>
> types {
> include "/usr/share/misc/mime.types"
> }
That httpd.conf should work.
> The reason I was messing with python(1) in chroot
> was because that's what I was seeing online.
> If that doesn't need to be messed with, great.
> However, I don't know what I'd need to do to make this work.
Putting python in the chroot is ONE way of doing it.
It's not the best way in general. But it might be the best way for
you, if you're trying to get an introduction to doing these things.
Just DON'T try running a production server like this.
Basically, if you want to run _anything_ in a chroot, you need
to make sure that it has access to _all_ of the files that it
normally uses when run from outside the chroot.
I.E. you need to copy them from outside the chroot to inside.
For many simple programs, it is just a case of running ldd and
seeing what libraries it uses. But not always.
The python interpreter is a large and complicated piece of
software, and as you have discovered, just copying the libraries
that ldd reports as being needed is not enough.
The error you are getting:
> "ld.so: python3: can't load library 'libintl.so.7.0'"
Means that the specified library couldn't be found, or could
not be accessed.
But why? As you say:
> 'libintl.so.7.0' was one of the files that appeared in ldd(1).
> ldd(1) said the path was '/usr/local/lib/'
> and I've got the file copied to '/var/www/usr/local/lib/',
> so I'm unsure why python(1) is saying it can't load it.
Remember that the chroot is a minimalist environment. You have
not re-created the entire configuration of a normal OpenBSD install.
The /var/www/usr/local/lib path is not being searched for dynamic
libraries when you try to run the python interpreter within the
chroot. The easiest way to 'make it work' is to move the files
you just copied to /var/www/usr/local/lib/ to /var/www/usr/lib/
instead.
Now, when you enter the chroot and try to run your python program
you'll get further, (but it still won't work):
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Python path configuration:
PYTHONHOME = (not set)
PYTHONPATH = (not set)
program name = '/usr/local/bin/python3'
isolated = 0
environment = 1
user site = 1
import site = 1
sys._base_executable = '/usr/local/bin/python3'
sys.base_prefix = '/usr/local'
sys.base_exec_prefix = '/usr/local'
sys.platlibdir = 'lib'
sys.executable = '/usr/local/bin/python3'
sys.prefix = '/usr/local'
sys.exec_prefix = '/usr/local'
sys.path = [
'/usr/local/lib/python39.zip',
'/usr/local/lib/python3.9',
'/usr/local/lib/lib-dynload',
]
Fatal Python error: init_fs_encoding: failed to get the Python codec of the
filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'
Current thread 0x000005d51f11d900 (most recent call first):
<no Python frame>
This is because one the Python interpreter has loaded, it's then
trying to load other files itself.
Exactly which ones will depend on your application, and the
correct thing to do when setting up a chroot is to identify the
minimal files you need, and copy just those.
However, for educational purposes ONLY, you can just copy everything:
# mkdir /var/www/usr/local/lib/pyton3.9
# mkdir /var/www/usr/local/include/pyton3.9
# cp -R /usr/local/lib/python3.9/* /var/www/usr/local/lib/python3.9
# cp -R /usr/local/include/python3.9/* /var/www/usr/local/include/python3.9
Now it will work:
# ftp -o - http://10.1.1.1/hello_world.py
Trying 10.1.1.1...
Requesting http:://10.1.1.1/hello_world.py
<html>
<body>
<h1>Hello World</h1>
</body>
</html>
Good luck, and have fun learning this stuff.
Let us know how you get on.
