Best way to implement perl

[edwardsmarkf]

hello all -

Joe Cooper just informed me that CGI is not used that much anymore. i really only chose CGI on my last server install because I didn’t know any better (and honestly still don’t)

what is everybody’s preferred method for running perl with Virtualmin?

Joe suggested I might look at fcgiwrap although I am not finding any examples of running it with Apache, only Nginx. I do have a question in the Apache lounge asking for any help.

SYSTEM INFORMATION
OS type and version	RL 9.5
Webmin version	not installed yet
Virtualmin version	not installed yet
Webserver version	Apache not installed yet
Related packages	SUGGESTED

[Joe]

You shouldn’t need to do anything. Virtualmin theoretically sets up fcgiwrap for running CGI applications on any current EL system (those without custom suexec). It barely gets tested because nobody uses CGI, but if you have problems we can fix them.

fcgiwrap was written for nginx to solve the problem of nginx not supporting CGI, but it works for Apache, too, in the situation where suexec is annoying on EL systems. I doubt you’ll find any docs on using fcgiwrap with Apache, because most people don’t run CGI anymore, and those that do use suexec and run things out of /var/www. We had to figure out fcgiwrap ourselves, we didn’t find any docs for Apache.

[Joe]

And, the answer to the question of best way to implement Perl is the same as any other language: Use an app server and proxy to it. There are many app servers for Perl. Consider https://plackperl.org/ (Especially, in the short term, Plack::App::CGIBin - cgi-bin replacement for Plack servers - metacpan.org )

fcgiwrap is basically that, but slower (as any CGI implementation will be). It runs an app server that knows how to run CGI scripts.

[Joe]

And, one more note: You almost certainly should not use mod_perl. (Any mod_lang is a smell to be avoided in almost all cases.)

[Joe]

Found this concise and correct (still is, AFAIK, though it’s a few years old) post on reddit: https://www.reddit.com/r/perl/comments/8b9rnq/comment/dx65n7z/

To repeat it here:

If you’re thinking “web apps” and “Perl”, you should be thinking “PSGI”. Running your code in a PSGI environment gives you three immediate advantages.

• Your code is immediately decoupled from your deployment environment. You can take exactly the same code and run it as a CGI program, under mod_perl or even as a separate service behind a proxy.
• You get access to great testing and debugging tools.
• You get access to the Plack Middleware ecosystem.

Getting legacy CGI programs into a PSGI environment isn’t hard. There are three steps you can take.

• Use CGI::Emulate::CGI to get your existing code running under PSGI.
• Use the techniques I describe in this blog post to move to a more “pure PSGI” approach.
• Rewrite your code to use a PSGI-based framework like Dancer2 or Catalyst.

CGI::Alternatives is an interesting and useful discussion of some other simple approaches you can take.

[Joe]

Finally, if you’re doing something manually (not just letting Virtualmin set it up for you), you should try to do the optimal thing, and the optimal thing is certainly not fcgiwrap. That’s just a generic and lightweight way for us to handle CGI safely (running as a domain owner) without suexec.

Running Perl under a Perl application server (even if you just use a CGI wrapping thing like Plack::App::CGIBin, rather than modifying your application to be a proper PSGI application or whatever) is likely to return the best performance.

[verne]

I may catch a lot of flack as perhaps I have made a bunch of mistakes … but I set this up all by hand on a RedHat 8 server back in 2021 after the initial Virtualmin virtual server creation – I did:

created a unique subdirectory

/var/www/web_ill/cgi-bin2/

incorporating the linux userid web_ill along with the unique name cgi-bin2

This subdirectory holds the perl files, all with a .CGI suffix (these forms were migrated As-IS from the previous webserver, the .CGI suffix might not be a requirement)

Both the web_ill and cgi-bin2 directories are owned by the user web_ill in case that user wishes to edit the files located there.

then added/adjusted httpd.conf in the proper virtualserver stanza to have:

ScriptAlias /cgi-bin2/ /var/www/web_ill/cgi-bin2/

and

<Directory /var/www/web_ill/cgi-bin2>
    allow from all
    AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch
    AddHandler cgi-script .pl
    Require all granted
</Directory>

for our environment, we are processing a form — an simplified example (not tested):

<html>
<p>
If information needs to be updated on the page, please fill out the form below.

<form method="post" action="/cgi-bin2/ILL_Update_Form.cgi">
<p>
Library Name: <input name="libraryname" type="text" style="width:400px;"/>
<p>
Contact Individual: <input name="contact" type="text" style="width:400px;"/>
<p>
Phone: <input name="phone" type="text" style="width:140px;"/>
<p>
E-mail: <input name="email" type="text" style="width:350px"/>
<p>
<br>
<p>
<input value="Submit" type="submit"/>&nbsp;&nbsp;
<input value="Reset" type="reset"/>

</form>
</html>

when we migrated this from a very old server, we just didn’t have the time to rewrite it in php or some other language or framework Our perl scripts eventually send out an email message.

And all our perl files have as their first line:

#!/usr/bin/perl -wT

While its been working OK as far as we know since we implemented it, I welcome any suggestions on how to make it better.

[Joe]

That moves the CGI files outside of where a user can mess with them. So, it’s not appropriate for a shared hosting system.

A better solution if you want to keep using suexec (instead of fcgiwrap, as we do in Virtualmin for the past year or so, or any of the better options I just discussed) is to simply bind mount /home to /var/www, so they have the same contents and then you just have to change the ScriptAlias and Directory in each VirtualHost that needs CGI to use the /var/www path. The files will still be accessible to the user in /home (because of the bind mount) and suexec will be happy because the path is in /var/www.

This is only relevant on EL systems (Debian and Ubuntu can still use suexec-custom, and Virtualmin will do that by default).

And, it is only relevant if none of the better options work for some reason. But, I can’t imagine these hoops are easier than simply using CGI::Emulate::CGIBin and proxying to that (or just using the fcgiwrap configuration that Virtualmin should, AFAIK, set up for you).