I am building a cgi application, and now I would like it to be like an application that stands and parses each connection, with this, I can have all session variables saved in memory instead of saving them to file(or anyother place) and loading them again on a new connection
I am using lamp within a linux vmware but I can't seem to find how to install the module for it to work and what to change in the httpd.conf. I tried to compile the module, but I couldn't because my apache isn't a regular instalation, its a lamp already built one, and it seems that the mod needs the apache directory to be compiled. I saw some coding examples out there, so I guess is not that hard once its runing ok with Apache
Can you help me with this please?
Thanks,
Joe
Using FastCGI just means that you spawn a number of processes which will handle requests they get from the actual webserver instead of the webserver spawning a new process whenever a request arrives.
Use something like memcached if you want to keep stuff like sessions in memory.
Related
Am trying to access my website by its IP address. The site is hosted on a shared ip so, i tried including a tilde ~ and then my user name, but it doesn't seem to work.
Any idea around this?
http://serverIPaddress/~cpanelusername
Most likely this is happening because of mod_ruid2 being installed. In order to access the site via publicIPaddress/~username you have to install mod_userdir.
unfortunately you can't use mod_userdir and mod_ruid2 at the same time. So these are the steps for configuring your WHM to allow access with ip/~username
Login to WHM with your root user. Go to mod_userdir TWEAK which you can access using the search bar on the left side of the GUI.
At this point check the box to install the service. After it installs you should be able to access the site with ip/~username. It is very likely it will not install because there are conflicts with mod_ruid2 and CGI being installed. So you remove them like this,
Go back to the search bar and type EasyApache. Click the link when it pops up,
Click customize and then next or click Server Modules on the left. In the main area and your current setup will load. First type mod_ruid2 in the search bar. When it pops up click to uninstall it.
Next search for CGI and if ea-apache24-mod_cgi uninstall it as well.
Now you need to use another handler so in my case I chose suphp.
ea-apache24-mod_suphp
Once you choose to install it you will need to choose Prefork Worker or Event.
Here are the descriptions of these,
Prefork With the Prefork module installed, Apache is a non-threaded,
pre-forking web server. That means that each Apache child process
contains a single thread and handles one request at a time. Because of
that, it consumes more resources than the threaded MPMs: Worker and
Event.
Prefork is the default MPM, so if no MPM is selected in EasyApache,
Prefork will be selected. It still is the best choice if Apache has to
use non-thread safe libraries such as mod_php (DSO), and is ideal if
isolation of processes is important.
Worker The Worker MPM turns Apache into a multi-process,
multi-threaded web server. Unlike Prefork, each child process under
Worker can have multiple threads. As such, Worker can handle more
requests with fewer resources than Prefork. Worker generally is
recommended for high-traffic servers running Apache versions prior to
2.4. However, Worker is incompatible with non-thread safe libraries. If you need to run something that isn’t thread safe, you will need to
stick with Prefork.
Event Each process under Event also can contain multiple threads but,
unlike Worker, each is capable of more than one task. Apache has the
lowest resource requirements when used with the Event MPM.
Event, though, is supported only on servers running Apache 2.4. Under
Apache 2.2, Event is considered experimental and is incompatible with
some modules on older versions of Apache. Nevertheless, on
high-traffic Apache 2.2 servers where Apache has experienced issues
with memory, upgrading Apache to take advantage of the Event MPM can
yield significant results.
After you are done installing the new modules and removing the old ones you need to ssh into your server and type
For Centos 7
/usr/local/cpanel/bin/rebuild_phpconf --available
This will show you something like this,
At this point I checked my current php install like this,
php -v
PHP 5.6.27
So I decided to go with the correlating PHP version for my handler. So now you have to select the handler like this,
/usr/local/cpanel/bin/rebuild_phpconf --default=ea-php56 --ea-php56=suphp
At this point make sure you go back to mod_userdir in your whm search bar and try and install it again. If it installs with no errors then try and access the page in your browser with ipaddress/~username. If you still can not access it then go back to your mod_userdir screen and make sure you check mark the box next to your user that says exclude protection.
You should probably get in touch with your host's support team for these sort of questions.
Typically, you receive an e-mail that has your cPanel account name, password, as well as something like "Temporary Webpage URL" which you can use to access your website until your DNS resolves in the form of: http://127.0.0.1/~account.
The "account" in above url example is your user name of cpanel.
I am setting up a very simple HTTP server for the first time, am considering my options, and would appreciate any feedback on the best way to proceed. My goal is pretty simple: I'm not serving any files, I only need to respond to a very specific HTTP POST request that will contain geolocation data, run some Python code, and return the results as JSON. I do need to be able to respond to multiple simultaneous requests. I would like to use HTTPS.
In looking on stackoverflow it seems I can potentially go with BaseHTTPServer and ThreadingMixIn, or Apache and mod_wsgi. I already have Apache installed, but have never configured it. Are there compelling reasons to go the more complicated Apache route (more complicated to me, because I will need to do research on configuring Apache and getting mod_wsgi going but already have a test instance of BaseHTTPServer up and running), or is it equally safe, secure (very important), and performance-oriented to use BaseHTTPServer for something so simple?
BaseHTTPServer is not a production grade server.
If you don't understand how to set up Apache, but want to get something with mod_wsgi running quickly and easily, then you probably want to look at mod_wsgi express.
This gives you a way of installing mod_wsgi using Python 'pip' and also provides you a way of starting up Apache/mod_wsgi with a auto generated Apache and mod_wsgiconfiguration such that you don't even need to know how to configure Apache.
The next version of mod_wsgi express to be released (version 4.3.0, likely released this week), can even set up a HTTPS site for you, with you just needing to have obtained a valid certificate or generated a self signed certificate.
I would suggest if interested you use the mod_wsgi mailing list to ask for more details about using mod_wsgi express for running a HTTPS site.
http://code.google.com/p/modwsgi/wiki/WhereToGetHelp?tm=6#Asking_Your_Questions
You can start playing around though with it for a normal HTTP site by following instructions at:
https://pypi.python.org/pypi/mod_wsgi
I am running a Perl CGI tool that executes a system command (Unix) which may run for a few seconds up to an hour.
After the script is finished, the tool should display the results log on the screen (in a browser).
The problem is that after about 5 minutes I get a timeout message "Gateway Time-out" - the system command continue to run but I'm unable to display to the user the results of the run.
In the Apache config file (httpd.conf): Timeout 300.
Is there a simple way ordering the Apache to increase the timeout only for a specific run?
I don't really want to change the Apache timeout permanently (or should I?) and not dramatically update the code (a lot of regression tests).
Thanks in advance.
Mike
Make the script generate some output every once in a while. The timeout is not for running the program to completion, but is a timeout while Apache is waiting for data. So if you manage to get your program to output something regularly while running, you will be fine.
Note that HTTP clients, i.e. browsers, also have their own timeout. If your browser does not get any new data from the web server five minutes (typically), the browser will declare a timeout and give up even if the server is still processing. If your long running processing gives some output every now and then, it will help against browser timeouts too!
For completeness:
Though the accepted answer is the best (it's variously known as KeepAlive packets in TCP/IP, or Tickle packets way back in appletalk days) you did ask if you can do dynamic Apache config.
An apache module could do this. Oh, but that's a pain to write in C.
Remember that mod_perl (and to some extent mod_python, though it's deprecated) do not only handlers but wrap the internal config in perl as well. You could write something complicated to increase the timeout in certain situations. But, this would be a bear to write and test, and you're better off doing what Krisku says.
There doesn't seem to be any way to specify a timeout on the <!--#include virtual=... --> directive, but if you use mod_cgid instead of mod_cgi then starting with Apache 2.4.10 there's a configurable timeout parameter available which you can specify in httpd.conf or .htaccess:
CGIDScriptTimeout nnns
...where nnn is the number of seconds that Apache will allow a cogitating CGI script to continue to run.
Caveat: If you use PHP with Apache, then your Apache is presumably configured in /etc/httpd/conf.modules.d/00-mpm.conf to use "prefork" MPM (because PHP requires it unless built with thread-safe flags), and the default Apache installation used mod_cgi with the prefork MPM, so you'll probably need to edit /etc/httpd/conf.modules.d/01-cgi.conf to tell Apache to use mod_cgid instead of mod_cgi.
Although the comment in 01-cgi.conf says, "mod_cgid should be used with a threaded MPM; mod_cgi with the prefork MPM," that doesn't seem to be correct, because mod_cgid seems to work fine with prefork MPM and PHP, for me, with Apache 2.4.46.
Although that doesn't give you complete control over server timeouts, you could specify a different CGIDScriptTimeout setting for a particular directory (e.g., put your slow .cgi files in the ./slowstuff/ folder).
(Of course, as krisku mentioned in the accepted answer, changing CGIDScriptTimeout won't solve the problem of the user's web browser timing out.)
I have an application with some cacheing backend and I want to clear the cacheing whenever the webserver is been restarted.
Is there a apache configuration directive or any other way to execute a shell script upon webserver (re)start?
Thanks,
Phil
Adding some more information, as asked by some answers already:
Base system is ofc linux based, in this exact situation: CentOs
Modifying the startup script is unfortunately no option as pointed out by one of the comments already, due to it beeing not configuration file within the respective RPM packages and therefor beeing replaced by updates. Also I think modifying the startup script would be a bad thing in general
I see, that actually linking both "restarting the webserver" and "clearing my app cache" is not exactly what should be tied together. I will consider other alternatives
My situation is as follows: I can define how the virtual host config looks like, but I can not define how the rest of the servers configuration looks like.
The application is actually PHP based (and runs on the symfony framework). Symfony pre-compiles alot of stuff into dynamic php files from what it finds in the static configuration files. We deploy our apps via RPM and after deployment, an webserver restart is actually initiated already, so I thought it might make sense to tie the cache-cleanup to it. But I think after getting all your feedback, it looks like it is better to put the cache cleanup process into the installation process itself.
You haven't provided a lot of detail here, so it's hard to give a concrete answer, but I would suggest that your best option is to write a script which handles restarting apache, and clearing your cache. It would look something like this:
#!/bin/sh
# restart apache
/etc/init.d/httpd graceful
# whatever needs to be done to clear cache
rm -rf /my/cache/dir
Ramy suggests modifying the system startup script for Apache -- this is a bad idea! If and when you update Apache on your server, there is a good chance that your change will be lost.
Dirk suggests that what you are trying to do is probably misguided, and I think he's right. You haven't told us what platform you are running, but I can think of few situations where restarting your webserver and clearing a cache actually need to happen together.
You can modify Startup script for the Apache Web Server in /etc/init.d/httpd and write your own syntax inside it.
chattr +i /etc/init.d/httpd
If you have (root) access to the server you could do this by shell scripts but I would consider if it is the best way of cache management to rely on apache restarts.
I'm currently using Apache+Phusion quite successfully but am interested in trying out Nginx+Phusion. Although there are lots of places where I can get info on how to set up the latter none of them explain what I have to do to ensure that it is Nginx that is serving things up rather than Apache.
Ideally I would like to keep the Apache stuff available whilst trialling but I'm guessing that at a minimum I will have to stop Apache and run Nginx - or can both be running simultaneously on the same machine? If the answer to this is yes then which server will handle URL requests and how will I know?