[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-misc
Subject:    Re: Guide for Configuring python(1) with httpd(8)
From:       Crystal Kolipe <kolipe.c () exoticsilicon ! com>
Date:       2022-12-24 15:11:58
Message-ID: Y6cWvpmpngC9UOfx () exoticsilicon ! com
[Download RAW message or body]

On Fri, Dec 23, 2022 at 07:57:56PM +0000, indivC wrote:
> However, the 'cgi' module is giving me trouble that I can't resolve.
> It simply won't import without errors.
> 
> Why am I trying to import the 'cgi' module?
> What I want to do is pass data.

...

> The above is just a simple example that has one input field ('name').
> In order to grab the 'name' inputted by the user,
> I need to use the 'cgi' module.

Firstly, you don't actually _need_ to use the Python cgi module to write a cgi
program that handles input and output from the webserver such as form
submissions, it's just one way of doing it.  CGI programs just read from
standard input and write to standard output.  If you are doing this as a
learning experience, it would be much more educational to actually study the
format that the webserver uses to send the form data and write a simple parser
for it.

But it seems that most people these days want to take all of the shortcuts.

> When I run 'chroot /var/www htdocs/test/cgi-test.py',
> I get the below:
> 
>     File "/usr/local/lib/python3.9/email/header.py", line 14,
>          in <module>
>       import binascii
>   ImportError: Cannot load specified object

This is because the chroot environment is not fully set up.  It doesn't
contain all of the files in all of the right locations for what you want to
do.

> I know, chroot is bad bad.
> I think once I can resolve this,
> I'll go back through your responses
> and attempt to move away from chroot and start using fastcgi.

Why not just start using FastCGI now?  Honestly, you are just wasting your own
time by persuing the 'python interpreter in a chroot' method.  Other people
have pointed this out.  Especially since you are starting from scratch, and
not trying to run a piece of existing software that requires it.

I showed you how to get the python interpreter itself working in a chroot,
because that is useful general knowledge to have from a technical point of
view, and helps to explain in very simple terms how things work in a chroot.

But beyond just seeing it work and writing a hello world program, it's not
worth persuing.

> I tried to troubleshoot the above error,
> but I haven't gotten anywhere.
> My first thought was where is this module located,
> so I ran 'python3' to run the Python Interpreter
> and entered the below:
>   >>> import binascii
>   >>> binascii.__file__
>   '/usr/local/lib/python3.9/lib-dynload/binascii.cpython-39.so'
> 
> So that's the location of the module.
> It is located in the same path within '/var/www/'
> and it also has the correct permissions,
> but unsure what's the problem with importing it.

If you want to set up the chroot more thoroughly so that these extra Python
modules work, why don't you just use the script that Mark sent you:

https://marc.info/?l=openbsd-misc&m=167135242321424&w=2

I know you had a few problems with it:

> I removed the parts in the script
> that dealt with touching any folder path with 'run'.
> 'slowcgi.sock' is in '/var/www/run/'
> and I didn't want to mess with it.
> Also, it doesn't look like the script does anything with files
> in these folders, so it shouldn't matter that I omitted them. 
> 
> On the first run, it wasn't able to copy 'libiconv.so.7.0'.
> On my system, it's 'libiconv.so.7.1'.

This is because Mark's script was written for an older version of OpenBSD.

I tested it on a fresh OpenBSD 7.1 installation and it applied just fine
without any changes whatsoever.  And I was able to use the python CGI module
in the chroot.

> Therefore, I updated that line in the script to 'libiconv.so.*'.
> This better matches how all the other lines are in the script.
> I'm not sure why this line and the one above it are different.
> 
> Then, I ran the script again.
> However, I still get the same 'chroot' error:
> "ldconfig: /var/run/ld.so.hints.<rand>: No such file or directory"

Are you sure that /var is not full?

> It's like something is attempting to generate a pseudorandom file
> using 'ld.so.hints' as a base.

It is :-).

man 3 mktemp
man 3 mkstemp

> These pseudorandom filenames do not exist,
> but '/var/run/ld.so.hints' does,
> so I'm not sure why it doesn't just use that file directly.

Remember that OpenBSD is a multi-user system.

Like a lot of system programs, ldconfig does not overwrite it's files
directly when updating them.  If it did then there would be a short period of
time where /var/run/ld.so.hints contained invalid or incomplete data.  What
would happen if another program tried to access it at that moment?  Or if the
system crashed?

The way to avoid this on basically any unix-like system is to write the
changed version to a new temporary file, then once it's written you rename the
temporary file to the real name, overwriting the old file.

The rename operation is atomic, I.E. it happens 'instantly', so there should
be no risk of the file becoming mangled.

If /var is not full, then you have probably made a configuration change that
you haven't told us about whilst trying to set up the chroot.

But seriously, move to FastCGI and you will be a lot happier :-).

[prev in list] [next in list] [prev in thread] [next in thread]