Im planning to port LIGHTTPD to my embedded system. I do not have fork () system call in my environment. I could see #define HAVE_FORK in lighttpd sources, if this is not defined lighttpd will not make any fork calls. So far so good..
But in one of the lighttpd module "mod_cgi", I can see a fork() call which is not protected by the statement if (HAVE_FORK) { ...}
Is there a way to avoid this fork () call in "mod_cgi" also, can I disable this module during compilation ?
Your help is greatly appreciated, can some one comment of this please.
CGI in lighttpd is only supported by communication with an external CGI process (e.g. php-cgi) so the mod_cgi module needs to fork().
If you don't need CGI then just omit mod_cgi from the build (I'd guess in your environment that you'll be omitting almost all the modules; only a couple are mandatory). If you do need CGI then you either have a lot of work to do on lighttpd or you should look at a web server that does CGI in process.
Related
I am trying to get FastCGI to work with Perl CGI in FastCGI mode. By that I mean that I can run Perl CGI scripts on Nginix without any issues but it does not appear (based on performance measurements) that my scripts are running in FastCGI mode. I've seen mentions about spawn-fcgi but nothing recent or details on how to implement with current versions of Nginx and Ubuntu.
I am relatively new to Linux.
Environment info:
Ubuntu 22.04 hosted in the "cloud"
nginx version: nginx/1.18.0 (Ubuntu)
Tutorial I followed: https://techexpert.tips/nginx/perl-cgi-nginx/
I have installed fcgiwrap.
CGI works, HTTPS works.
I am enclosing the bulk of my Perl CGI script within
use CGI::Fast;
while(my $q = new CGI::Fast)
{
# all my code
}
My script is doing a simple write and query from a very small SQLite3 database (4 columns, 500 rows, 290k db size).
I am testing across the Internet.
Script execution performance is about half of a second (.42 seconds per page) or 345ms. That is about the same as IIS Windows CGI.
I also saw that requesting a simple HTML file only has marginally better performance.
I understand that there is a lot more to performance testing than the preceding. The point is that I think there is something missing with my FastCGI configuration. I imagine it has something to do with me needing to launch the Perl FastCGI script somehow and then somehow connect that to Nginx. If anyone can point me in the right direction or provide example config files, that would be great. Thanks all!
I have 2 different web servers on a Debian Lenny machine. One is running FastCGI (TRAC) and the other web server is running PHP and some CGI scripts. So I have currently the 2 Apache2 modules enabled (cgi and fcgi) and the 2 vhosts setup accordingly. I have no other particular interest for these both modules running at the same time.
So I want to keep ONLY Apache fastcgi module running as it looks to be the more efficient one.
Could you pls confirm the following assessments to be right or correct ?
1- I will have nothing to do/change for the TRAC site (already running fcgi)
2- I will have to tune the other web server vhost to be set with an handler to fastcgi scripts
3- I will have to change only the perl modules from "use CGI" to "use CGI::Fast"
4- I will be able to keep the rest of the perl existing CGI scripts w/o other changes
5- I do not need to use CGI::Apache but CGI::FastCGI (i/o the current CGI module) in the web server scripts
I hope my point is clear as it's all a bit foreign to me ...
Thx
EDIT:
thx for the hints to Naveed and J-16,
Here is what I did to get it working if it can help others :
hum, installed CGI::Fast with CPAN, then it works better..
On Debian with libperl already installed
perl -MCPAN -e shell
cpan> install CGI::Fast
changed filename from *.cgi to *.fcgi,
included the fastcgi while loop as adviced below by Naveed,
setup the apache concerned vhost with the right handler for fastcgi (See fastcgi doc)
enabled the Apache fastcgi module (a2enmod fastcgi) and disabled the cgi module,
checked the fastcgi.conf file in the Apache settings,
restarted Apache,
checked the fastcgi running as an Apache sub process (ps -afx),
fixed some script issues, already in.. but newly appearing when running fastcgi, as adviced (errors detected by checking the Apache logs),
EDIT: adapted the file upload code as the initial script did not work anymore (still don't understand why), so I had to replace the while loop by a such one:
open(FILE,">$upload_dir/$file_name")
while ($bytes_count = read($file_query,$buffer,2096)) {
$size += $bytes_count;
print FILE $buffer;
}
close(FILE);
done.
World is not yet perfect but it finally works.
You will have to do a little more than just change use CGI to use CGI::Fast. Make sure you wrap you CGI scripts with a while loop, as the documentation states http://p3rl.org/CGI::Fast
use CGI::Fast;
while (CGI::Fast->new()) {
# The original CGI code goes in here
}
I have managed successfully to server my Catalyst app on my development machine using Plack + Starman, using a daemon script I based on one I found in Dave Rolsky's Silki distribution.
I then set up nginx to reverse proxy to my Starman server, and aliased the static directory for nginx to serve. So far, so good. However, I am at a loss as to where my application STDERR is supposed to be logging to. It isn't reaching nginx (I suppose that makes sense) but I can't find much documentation as to where Starman may be logging it - if anywhere. I did have a look at Plack's Middleware modules but only saw options for access logs.
Can someone help me?
It's going nowhere. Catalyst::Log is sending data to STDERR, and the init script is sending STDERR to /dev/null.
You have a few basic choices:
Replace Catalyst::Log with something like Catalyst::Log::Log4perl or simply a subclass of Catalyst::Log with overridden _send_to_log -- either one will allow you to send the logging output somewhere other than STDERR.
Write some code that runs at the PSGI level to manage a logfile and reopen STDERR to it. I tried this, it wasn't very pleasant. Logfiles are harder than they look.
Use FastCGI instead, and you'll have an error stream that sends the log output back to the webserver. You can still use Plack via Plack::Handler::FCGI / Plack::Handler::FCGI::Engine (I'd recommend the latter, because the FCGI::Engine code is much newer and nicer than FCGI.pm).
I realise it is a long time since the question was asked, but I've just hit the same problem...
You actually have one more option than Hobbs mentioned.
It isn't quite the "init script" that is sending STDERR to /dev/null, it is Starman.
If you look at the source code for Starman, you would discover that, if you give it the --background flag, it uses MooseX::Daemonize::Core.
And once you know that, its documentation will tell you that it deliberately closes STDERR, STDOUT and STDIN and re-directs them to /dev/null, AND that it takes the environment variables MX_DAEMON_STDERR and MX_DAEMON_STDOUT as names of files to use instead.
So if you start your catalyst server with MX_DAEMON_STDERR set to a file name, STDERR will go to that file.
Today Starman has a --error-log command line option which allows you to redirect error messages to a file.
See documentation of starman:
--error-log
Specify the pathname of a file where the error log should be written. This enables you to still have access to the errors when using --daemonize.
Can I run my mod_perl aplication as an ordinary user similar to running a plain vanilla CGI application under suexec?
From the source:
Is it possible to run mod_perl enabled Apache as suExec?
The answer is No. The reason is that
you can't "suid" a part of a process.
mod_perl lives inside the Apache
process, so its UID and GID are the
same as the Apache process.
You have to use mod_cgi if you need
this functionality.
Another solution is to use a crontab
to call some script that will check
whether there is something to do and
will execute it. The mod_perl script
will be able to create and update this
todo list.
A more nuanced answer with some possible workarounds from "Practical mod_perl" book:
(I hope that's not a pirated content, if it is please edit it out)
mod_perl 2.0 improves the situation,
since it allows a pool of Perl
interpreters to be dedicated to a
single virtual host. It is possible to
set the UIDs and GIDs of these
interpreters to be those of the user
for which the virtual host is
configured, so users can operate
within their own protected spaces and
are unable to interfere with other
users.
Additional solutions from the sme book are in appendix C2
As mod_perl runs within the apache process, I would think the answer is generally no. You could, for example, run a separate apache process as this ordinary user and use the main apache process as a proxy for it.
I am new to FastCGI and looking to use this platform to speed up my existing vanilla CGI (perl) programs.
However in reading the FastCGI/Apache FAQ, it appears I can setup my scripts (once converted to use separate initialization/request sections) in the Apache config as one of the following:
1) dynamic
2) static "inside the scope of the SetHandler"
3) static "inside the scope of the AddHandler"
4) static "outside the scope of the Set/AddHandler" (or, I think, this can be called 'external')
I am confused about those 4 options, and am assuming the default of 'dynamic' is what I should go with, but could someone explain the pros/cons of these?
There isn't much to worry about Add/SetHandlers. They are just a way of defining which extensions are to be recognized as fcgi scripts.
What you might want to consider is dynamic, static or external.
Static is started as apache starts (possible this is the most common setup)
Dynamic is started whenever the first request is made (This is the default)
External requires the fcgi server to run separately from apache. (This is the most advanced configration)
I suggest you refer to the module documentation for more information (at least the summary):
FastCGI applications under mod_fastcgi are defined as one of three types: static, dynamic, or external. They're configured using the FastCgiServer, FastCgiConfig, and FastCgiExternalServer directives respectively. Any URI that Apache identifies as a FastCGI application and which hasn't been explicitly configured using a FastCgiServer or FastCgiExternalServer directive is handled as a dynamic application (see the FastCgiConfig directive for more information).
FastCGI static and dynamic applications are spawned and managed by the FastCGI Process Manager, fcgi-pm. The process manager is spawned by Apache at server initialization. External applications are presumed to be started and managed independently.
Of course if you are using Perl you can try mod_perl where you can start by using your CGI scripts first.