On 2022-12-18, indivC <ind...@proton.me> wrote: > On Sunday, December 18th, 2022 at 9:04 AM, Omar Polo <o...@omarpolo.com> > wrote: > >> instead of asking how to do X so that you can do Y, ask directly how >> to do Y. > > I did. The first line of my message was > "Can anyone provide a guide for this or rough instructions?", > which is in reference to the subject > "Guide for Configuring python(1) with httpd(8)".
Surely the goal is to run some particular software and make it available via an httpd(8) frontend and not just run python(1) i.e. the Python interpreter? > Did i precede to explain > how I was trying to attempt to accomplish Y with X? > Yes, but I don't see why that would be a problem. > I feel like it's better for users to actually attempt to try > and solve their problems then not to try at all. Yes but when you would like help, describe and ask about the base problem rather than something further down the line of your idea if how to do it. >> Why do you need python at all in the chroot? Installing all the >> needed files (and keeping them up-to-date!) manually in a chroot is a >> pain. > > I completely agree. > Virtually every solution I've seen online does this. Every solution for "run stuff in chroot" does this, but there are other more common ways to expose Python software to web clients. scgi is possibly the most common but openbsd's base httpd(8) doesn't support that. fastcgi is more common with other languages but also possible with Python and would often be a better fit than trying to run Python directly in a chroot via httpd->fastcgi->slowcgi->python(1). >> Since httpd speaks fastcgi, why not write some python code that >> accepts the requests over fastcgi? (assuming this is what you're >> trying to do, but you didn't tell.) > > I believe that is exactly what I'm trying to do. > The end goal is to be able access a python(1) file from httpd(8). > My understanding is you have to configure slowcgi(8), > which utilizes fastcgi, within httpd(8). The process accepting fastcgi requests would often run (or at least be started from) *outside* the chroot. Separate process waiting and listening for requests, not something executed by the httpd process. Another alternative is to use slowcgi but disable the chroot (-p /). Is chroot really buying you much if you provide an environment making it easier to run things inside that chroot anyway? -- Please keep replies on the mailing list.
