CGI for the server

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: CGI for the server by polettix (Vicar) on Jun 03, 2005 at 22:06 UTC
Your question is rather confused for me and I don't understand it fully. Keep in mind that CGI scripts already work ON the server, so what? If you want something that runs on the server without the need of a trigger from a webserver, then you don't need CGI for this, just create your scripts and make them run on the server itself, e.g. using the crontab or doing the scheduling on your own with `sleep` and/or `alarm`. Last thing that comes to my mind is that you could want to always execute something for each request that arrives to the web server, but without the explicit use of CGI. In this case, you'd probably study the documentation for the webserver, and try to see if something about Apache in CPAN can help you. Flavio (perl -e 'print(scalar(reverse("\nti.xittelop\@oivalf")))') Don't fool yourself.	[reply] [d/l] [select]
Re^2: CGI for the server by Anonymous Monk on Jun 03, 2005 at 22:17 UTC
Hi Yes, I meant I want my script to load any time my domain is called WITHOUT forcefeeding CGI calls into every single one of my pages. I want to track everything without any trigger, as you said. You said sleep. Are you saying that all the scripts like this are actually running infinitely rather than just activated if any file on the server was called?	[reply]
Re^3: CGI for the server by polettix (Vicar) on Jun 03, 2005 at 22:28 UTC
No, the sleep was intended for cases where you actually were looking for some daemon application unrelated to the web server. Flavio (perl -e 'print(scalar(reverse("\nti.xittelop\@oivalf")))') Don't fool yourself.	[reply]
Re: CGI for the server by brian_d_foy (Abbot) on Jun 04, 2005 at 03:20 UTC
If you don't control the server, you're pretty much stuck with web bugs and similar techniques. Without that, you'd have to send all of your links through a single CGI sccript which then returns the right content. So, you want all the power of a server you can configure without the server part, so you're not going to be able to do it in a nice way. What problem are you trying to solve? -- brian d foy <brian@stonehenge.com>	[reply]
Re^2: CGI for the server by Anonymous Monk on Jun 04, 2005 at 03:34 UTC
No problem in particular, just wanted to see what I could do. Perhaps for starters save all IP addresses from the user who calls ANY file on the server to a text file. Then from there maybe start hacking away at a traffic analysis program like Cpanel has.	[reply]
Re^3: CGI for the server by brian_d_foy (Abbot) on Jun 04, 2005 at 05:47 UTC
For that case, you can look at the access log. -- brian d foy <brian@stonehenge.com>	[reply]
Re: CGI for the server by TedPride (Priest) on Jun 03, 2005 at 22:41 UTC
Assuming the software is Apache, you can put a .htaccess file in your main directory with the following: `ErrorDocument 403 /banned.html order allow,deny deny from 123.123.123. allow from all` [download] Where 123.123.123. is whatever part of the IP you want banned. You can put in as many deny lines as you want, though excessive use of deny will likely slow the server down. The best thing to do is run a script every so often that checks your server log for x number of requests within x number of seconds during the past 30 days or so and edits those IPs into a ban list that you can cut and paste or edit into the .htaccess using a second script (depending on whether you're running the first script on or off the server).	[reply] [d/l]
Re: CGI for the server by TedPride (Priest) on Jun 04, 2005 at 05:07 UTC
That's called your access log. I haven't seen a hosting account yet that didn't have an access log available somewhere. Just download the log every so often, run a short script on it to analyze whatever, and put the results back on the server. You could even automate the process with Net::FTP. You could also run your log parser on the server, but I wouldn't personally recommend this if it's programmed in Perl and the log is large. It'll eat up too much resources and irritate your hoster.	[reply]