How to run PERL scripts

SYSTEM INFORMATION
OS type and version Ubuntu 22.04
Virtualmin version Latest

I am running virtualmin with NGINX.
I just wanted to know how to run PERL (cgi) scripts from the virtual server.

  1. Do I need to create a cgi-bin directory?
  2. Do I have to enable cgi script support somewhere from control panel?

-Josin

I can’t speak for NGINX. The default Apache2 install seems to put a default cgi-bin in the home directory. One level up from public_html.

Same is true for Nginx (Perl should already be running) - you wouldn’t get Virtualmin otherwise.

2 Likes

No. Virtualmin has its own web server (Webmin’s miniserv.pl). It does not run under Apache or nginx.

I still recommend Apache for running CGI apps (Perl has nothing to do with it…a CGI app is a CGI app). nginx does not natively support CGI, so it has to be handled via a fastcgi wrapper. Virtualmin sets that up, and handles configuring it to run as the domain owner user, so it’s mostly transparent, but if I had to run CGI, I’d use Apache on Ubuntu or Debian, which still have suexec support (we no longer support suexec on the EL distros, but Ubuntu/Debian have suexec-custom, so it’s easier)

You should be moving your apps to a modern execution mode. Plack is probably the easiest way to migrate CGI Perl scripts to something modern. https://plackperl.org/

Thank you @Joe
This is the first time, I am trying NGINX and Virtualmin. I am just playing around it.
My purpose is to run Koha (Integrated Library System), DSpace and Moodle on the server along with some wordpress websites.

As I understand your advice,

  1. It is better for me to go with Apache server than NGINX?
  2. Can I run these apps outside cgi-bin folder?
  3. Do I need Plack, if I use Apache?

If you need to run CGI scripts, Apache with suexec-custom is much better tested. Obviously you don’t care about performance, since you’re running CGI scripts. And, besides that nginx is not faster than Apache in almost any common deployment, because the web server isn’t even close to the bottleneck (there’s a dozen or more things you have to make much, much, faster in most small scale web service deployments before you start running into web server as the bottleneck). CGI is the slowest way to run a web app, so the web server is completely irrelevant in your deployment, so I recommend you use the one that is most commonly used for CGI scripts, which is Apache. nginx does not have CGI support, so it has to be wrapped in some other tool; as I mentioned we setup fcgiwrap in that case. It’s probably not worse than Apache, but it’s definitely not better, and it’s much less well-tested.

You will also find almost no documentation about running CGI scripts with nginx, because nginx does not directly support CGI. Apache, on the other hand, has mountains of documentation on the subject.

Why would you do that? You can make your apps appear on any URL you like, without moving files around. You cannot run CGI scripts from public_html, though, if that’s what you’re asking. You could make a ScriptAlias that’s anything you want (i.e. you can make cgi-bin scripts appear on /app or /koha without doing weird stuff like trying to put cgi scripts somewhere wild).

You don’t need Plack. I was offering you a solution for improving the way you’re executing your apps. Plack is a low-friction path from CGI to running apps under a long-running Perl app server (this saves significant startup time for each request). If you use Plack, you no longer need CGI script support in your web server or a wrapper (because it is the wrapper and it provides a fastcgi interface you can proxy to). If you were to use Plack, you would be able to use nginx. Performance still wouldn’t matter, but at that point I would recommend whichever web server you’re most comfortable with rather than having a relatively strong opinion that Apache is the better choice.

I don’t know anything about the app you’re running; there’s nothing I can tell you about it. But, I know how CGI works with Apache and how it doesn’t work with nginx (unless you wrap it). So, if you’re running CGI scripts, you should go the path of least resistance, unless you have a good reason to do otherwise (performance is not a good reason, because the web server cannot save you from CGIs relative poor performance).

1 Like

Thank you @Joe for such a detailed and great explanation.
It felt like I was sitting in one of my favourite professor’s class room!

@ Professor_Joe? :wink:

1 Like

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.