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.
Related
This is my first post under the Apache tag, so not sure if I have posted it in the correct spot. Apologies if it's not.
We recently had an audit done on our Apache server. It's running on a Windows Server 2012 R2, and I installed Apache 2.4.27 through WAMP.
The results from the Audit are fairly specific, but I don't know where to go in the Config file to fix these. My IMIT department has gone through a number of changes and we no longer have someone who can help me, so I'm stuck.
The three areas I need to correct are:
1) MISSING SECURITY HEADERS Recommendation: Implement HTTP security headers in the web applications to prevent exploitation of vulnerabilities.
2) Recommendation: Make sure that browsable directories do not leak confidential informative or give access to sensitive resources. Additionally, use access restrictions or disable directory indexing for any that do.
3) The remote web server supports the TRACE and/or TRACK methods. TRACE and TRACK are HTTP methods that are used to debug web server connections. Recommendation: Disable these methods.
I have looked in the config and in various documentation online but the Windows install for Apache seems to be unique, and I don't want to risk screwing up something that breaks the install.
Any ideas would be greatly appreciated.
Chris
Find httpd.conf file. It should be in the conf folder in the localization where Apache is installed like for ex:
C:/Apache/Apache/conf/httpd.conf
If you're not sure where that is - open task manager, find httpd.exe and check it's properties.
Then add required configuration there.
Check out this helpful github:
https://github.com/h5bp/server-configs-apache/blob/master/dist/.htaccess
You can check your configuration files for syntax errors without starting the server by using apachectl configtest or the -t command line option.
I have some CGI scripts which are used internal to the organization. Due to some standard changes, the server/system team has commented the below line from httpd.conf (apache config file) that support the CGI scripts. Because of this change, the existing CGI scripts are affected and unable to execute them on browser.
### LoadModule cgid_module modules/mod_cgid.so
Is there a way to overcome this situation and make the scripts work as is.
NOTE : The above commented line cannot be uncommented/enabled.
Ways of circumventing your company's policy, from best to worse:
Load mod_cgi anyway.
Load mod_fcgi, and convert your CGI script into a Fast CGI daemon. It's a lot of work, but you'll can get faster code out of it!
Load your own module that does exactly the same thing as mod_cgi. mod_cgi is open source, so it should be easy to just rename it.
Load mod_fcgi, and write a Fast CGI daemon that executes your script.
Install a second apache web server with mod_cgi enabled. Link to it directly or use mod_proxy on the original server.
Write your own web server. Link to it directly or use mod_proxy on the original server.
Last time you asked this question, you talked about using mod_perl instead. The standard way to run CGI program unchanged (for some value of "unchanged") under mod_perl is by using ModPerl::Registry. Did you try that? How did it go?
Another alternative would be to convert your programs to use PSGI. You could try using Plack::App::Wrap::CGI or CGI::Emulate::PSGI. Using Plack would free you from any deployment restrictions. You could run the code under mod-perl or even as a separate service behind a proxy server.
But I can't help marvelling at how ridiculous this whole situation is. Your company has CGI programs that it (presumably) relies on to run part of its business. And they've just decided to turn off support for them. You need to find out why this decision has been made and try to buy some time in order to convert to an alternative technology.
I'm currently developing a website that's getting fairly frequent javascript updates and have just started using mod_pagespeed in an effort to ensure that customers will always have the latest code.
The docs tell me doing this will clear my pagespeed cache and force clients to get my new javascript/css:
sudo touch /var/cache/pagespeed/cache.flush
I did a test by changing some javascript code, hitting refresh on my browser to verify that I was still seeing the old code (my cache expiration is set to one day), then restarting apache, and I can indeed see my new changes.
Can I trust that a restart will always be sufficient, and that a cache.flush is not needed, or do I need to run the flush command as well? I'm reading that a restart of apache is required to clear the memory cache, but not how the file cache and/or cache.flush fits in with that.
Update:
I pulled the pagespeed code, and if I'm understanding correctly, the cache.flush process updates a timestamp.
It looks like that's happening in RewriteOptions::UpdateCacheInvalidationTimestampMs here:
http://modpagespeed.googlecode.com/svn/trunk/src/net/instaweb/rewriter/rewrite_options.cc
If I could figure out which timestamp this was updating, it seems like I could either check it/restart apache/check it again (to see if the timestamp changed) or deduce from the filename/location/who owns it somehow whether or not that's likely to happen.
Any more thoughts on this? Advice on how to figure out which timestamp is being updated? Other reasoning to make me feel better about either manually doing the extra flush command every time I update (when I'm already restarting apache for other reasons) or leaving it out?
touch the cache.flush file:
sudo touch /var/cache/mod_pagespeed/cache.flush
Reference: https://developers.google.com/speed/pagespeed/module/system#flush_cache
No restart of Apache doesnt clear the pagespeed cache. You have to do it manually by using cache.flush.
What I like to do to ensure that the whole cache on the entire web portion of the server
Apache2, this is a dry run, remove "-D" if you are sure you want to go through with it -l is for size of memory -p for path:
htcacheclean -D -p/var/cache/apache2 -l100M
mod_pagespeed:
sudo touch /var/cache/mod_pagespeed/cache.flush
A restart of Apache should flush the cache.
As part of my learning process, I thought it would be good if I expand a little more knowledge on what I know about apache. I have several questions, and while I know some of the stuff may require a rather lengthy explanation, I hope you can provide an overview so I know where to go looking. (preferably reference to mod_wsgi)I have read some resources after searching on google, and what I know arrive from there, so please bear with me.
What does the apache lifecyle looks like before, during, and after it receives a http request? Does it spawns a new child process to do the work, or creates a thread in one of the child process?
Does apache by default runs under www-data? So if that's the case, if I want a directory under my project folder to be used for logs, I can change just the folder group to www-data and allows write access?
What user will the python interpreter run under, after being invoked by apache? And what will processes created by Popen or multiprocessing from there run under?
I ran ps U www-data. Why are there so many processes with
S 0:00 /usr/sbin/apache2 -k start
The Apache mpm prefork module handles one connection in one process. To handle connections fast and not spawn processes on demand, apache maintains a process-pool. This explains why you see so many processes in the process-list. If a connection comes in, it is handed to one of the already existing processes.
Some more information is here: http://httpd.apache.org/docs/2.0/en/mod/prefork.html
The answer to question 2) is yes, apache always runs as www-data und you can grant access to any directory by changing it's group permissions to www-data.
Read:
http://www.fmc-modeling.org/category/projects/apache/amp/Apache_Modeling_Project.html
http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading
http://code.google.com/p/modwsgi/wiki/QuickConfigurationGuide#Delegation_To_Daemon_Process
http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess
The first one will tell you all the gory details of how Apache works internally. The latter relate to mod_wsgi specifically and process/threading model.
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.