document how to run CGI scripts

[luto]

• where do I put them?
• do I need additional config?
• how do install dependencies so SELinux allows access?
• how do I debug?

[Spacelord09]

Just install nginx and fcgiwrap ;-)

[luto]

fcgiwrap replaces our CGI problem with a FastCGI one 😅

[Spacelord09]

@luto I don´t see a problem there ;D

[nichtmax]

I think that's an issue for the lab

[jonmz]

Personally I no longer think CGI as a feature we should officially support. We are dealing with permission problems (enforced by suEXEC), we are dealing with a missing $HOME enviroment variable (removed by suEXEC, making dealing with modules installed in userspace basically impossible unless you're willing to fiddle with the source or create wrappers), and we are dealing with CGI scripts being unable to access files in the home directory (thanks to SELinux). I would be okay with a lab guide on CGI scripts, but it should not become an official feature of U7 as I consider it as a support nightmare. (And FastCGI is a thing basically completely different from CGI anyway.)

[Struppi]

unfortunately I just run in this problem, because I had an long running CGI Skript, which just work since 2002 and I didn't spent much time to modernize it. Now I have to leave U6 and got some trouble.

And I even can't activate FCGI in the way it worked under U6. Is there a guide for that?

[jonmz]

Beware that CGI and FastCGI - despite the similar name - are two completely different technologies; CGI being used for scripts that receive one request, deliver a response and finish, while FastCGI is made to be a long-running process waiting for requests and serving them. You cannot simply "upgrade" CGI to FastCGI; it's a different thing and applications must be written in a different way for FastCGI.

Most applications that are long-running nowadays offer themselves by means of HTTP instead of FastCGI, which can be easily attached as a web backend: https://manual.uberspace.de/web-backends.html - there are no plans to support FastCGI as demand for it is nearly zero, given that most web applications have made their shift to HTTP and many frameworks like Django, Rails etc. use some kind of middleware that can be deployed via basically "any" technology, from CGI (which basically all frameworks consider as "deprecated") over FastCGI, wsgi, psgi... to HTTP.

I am sorry that support for CGI has been dropped with U7, and while FastCGI might probably come back as a web backend at some point, it's not really on a roadmap due to user demand barely existing.

There is no need to hurry, though; U6 will still stay supported until the end of the year, so you have still months to look after it. I don't know anything about the CGI script in question, but given that it is been in use since 18 years, maybe it is a good moment to check if it is still state of the art. (I remember that even with our very first release of U5, one of the first feedbacks was like "When you log in, you'll immediately feel like you're back in the 90's - there is even a cgi-bin directory..."). While U6 was basically U5 deployed on a newer distribution, U7 is a complete redevelopment, and it was time to cut down on some very old-fashioned and rarely-used features.

There is an - unsupported - workaround, though, which is running your own CGI-capable webserver (Apache, nginx, whatever you favor), have it run under supervisord and have it connected as a web backend. With your own webserver, you can basically do whatever you want, even running CGI scripts.

[Struppi]

Thanx, for the answer.
I did last night switch the App from CGI to FCGI in principal. But I can't use it?

But the main problem is not that the CGI script isn't running - it do - but I can't use cpan and install Perl Modules because there is no access to $HOME (that what you describe before) the place where cpan install modules. I changed all pathes in the config and cpan use them for the source and all meta data, but the place where the modules go up is still $HOME/perl5.

Now I tried to copy them by hand to var/www/virtual/... but it seems it doesn't work if the module contains non-Perl parts.

[jonmz]

I did last night switch the App from CGI to FCGI in principal. But I can't use it?

As I said, FastCGI might probably come back (as a web backend, thus implemented differently) but for now it's not available - as in "not available, really". There is no Apache module like mod_fastcgi or mod_fcgid in use. CGI is available in theory, but not documented and not supported (but it does work with some fiddling).

But the main problem is not that the CGI script isn't running - it do - but I can't use cpan and install Perl Modules because there is no access to $HOME (that what you describe before) the place where cpan install modules. I changed all pathes in the config and cpan use them for the source and all meta data, but the place where the modules go up is still $HOME/perl5.

Your best option would be to use the local::lib module, by putting this into your .bashrc:

eval $(perl -Mlocal::lib=/var/www/virtual/USERNAME/perl5)

And this into your CGI scripts:

use local::lib '/var/www/virtual/USERNAME/perl5';

The first one tells cpanm - which you should use as a more modern alternative to cpan - to install modules in this place; the latter one tells your script where to find the modules.

Anyway, this issue isn't a support thread, but referring to a manual entry regarding CGI, and it's closed already. If you have further questions, hallo@uberspace.de may help via mail, but once again, CGI is no longer officially supported.

[bong0]

Another workaround I came up with that preserves the simplicity of running a few lines of bash/python/... that gets output via the webserver you can find here: https://gist.github.com/bong0/b04977be5d4ef9fc80455beb7b2d9bdf
It uses php's proc_open to launch an interpreter (bash, perl...) on static code it's given.
Not sure whether that's a good thing or ringing alarm bells for some. Feel free to share your critics.