This is basically a new install. Until now I’ve not played with the web aspect (mostly focused) on email. I installed nginx instead of apache at the outset.
Working on autoconfig, nothing is working, and then I discovered:
Expectation: CGI’s at /home/<server>/public_html/cgi-bin/
Reality: CGI’s at /home/<server>/cgi-bin
I can fake this in various ways (ln most likely?)… but what is the correct answer?
The cgi-bin is in the right place. Inside the Apache configuration there’s a directive called ScriptAlias which causes all traffic to domain.com/cgi-bin/ to read from /home/user/cgi-bin/ and for sub-servers /home/user/domains/sub.domain.com/cgi-bin/ respectively.
This model is safer since it isolates CGI scripts to a separate directory outside the “public_html” folder.
While I don’t personally use nginx, I suspect the same is true. That the virtual host in nginx is configured with a similar rule, and otherwise the note about the model also applies as it’s best to isolate CGI/Perl scripts.
nginx does not natively support CGI. If you need CGI, you should almost certainly be using Apache.
We’ve recently added support for an additional server that provides CGI to nginx (via proxying), but…if you expect a pleasant CGI experience that acts the way you’re used to, you shouldn’t be using nginx. It’s actively working against you.
The correct location for cgi-bin in a Virtualmin system (and the most common convention, historically speaking) is /home/<domain>/cgi-bin.
Yes… as I understand it, you’ve added fcgiwrap to accomplish cgi in nginx.
Lesson continually being learned: I (wrongly) assumed basic elements came preconfigured in web/virtualmin… and am learning that I need to keep my sysadmin hat on here–dfinitely not bulletproof
I’ll finish learning what I need to learn to get this going properly… and hopefully stop making invalid assumptions. I’m certainly seeing ways I can help make the experience better for others!
They do. CGI is a nearly dead protocol, it is no longer a core part of modern deployments.
But, if you want CGI, Apache supports it in the core server.
We’ve gone to some lengths to support folks who need CGI even on nginx…but, again, if CGI is a big part of what you’re deploying, nginx is almost certainly the wrong web server for it.
Oh, it’s also worth mentioning that CentOS 8 is also a poor choice if you need CGI. We no longer rebuild Apache to provide suexec support in /home on CentOS 8, which means the old way of running CGI+suexec is gone. fcgiwrap support is either coming or already there for Apache on CentOS 8, but, again…best to use an Apache that’s working with you if you have to use CGI (but the best option is to stop using CGI).
I just realized you’re maybe talking about the email autoconfig script we provide. All this talk of /public_html/cgi-bin had me confused.
Email autoconfig, I think, should work on current distros even with nginx, when enabled. I’m not sure what’s going wrong there (but it has nothing to do with cgi-bin not being in public_html). Might be worth seeing the vhost section for the domain in question.
It should be easy (well, easy-ish, though getting all the pieces working right together is challenging and involves some possibly outside pieces…DNS, in particular). But, it was impossible for most of the existence of Virtualmin nginx support and the fcgiwrap support was added mid-release (it’s recent, long after Virtualmin 6 installer went live), so it’s entirely plausible it’s not automatically setup for nginx installs.
Do you have fcgiwrap installed?
I still want to see the relevant vhost section. I’m completely in the dark about what’s not working, since it is definitely not that the cgi-bin dir is in the wrong place.
