[Glass] Gemstone 3106 with Pier and crawler

[Trussardi Dario Romano via Glass]

Ciao, thanks.

> You can block the IP with nginx (or apache if you're using it) if you want:
> 
> https://help.dreamhost.com/hc/en-us/articles/216456127-Blocking-IPs-with-Nginx
> 
> and I'm sure you could google an article that covers how to do it with
> Apache.  

	OK, i use Lighttpd server and i found the relative data entry to do it.

	Would it be interesting, at a first level, 

		to directly manage the request in Seaside without having to restart the web server?

> 
> 
> For the "daemontools thinks its working but its really not" problem you
> could add an additional daemontools monitored process that checks a url that
> is served by each fastcgi process e.g. every 30 seconds or so and then kill
> the gem if it returns the wrong thing.

	Are you saying that as I configured the system does not work?

	When the system has been subjected to a greater load of requests, everything is degraded!

	Does anyone have a Gemstone Pier site with a certain load of requests?
> 
> GLASS mailing list wrote
>> Ciao,
>> 
>> 	i have a Gemstone 3.1.0.6 environment with Seaside and Pier framework.
>> 
>> 	The Gemstone stone and the relative Fast-CGI service is managed by
>> Daemontools.
>> 
>> 	Everything works for a few years.
>> 
>> 	It's been a few days since the home server is continuously submitted to
>> requests (one every 5 seconds) made by ip 46.4.122.196  ( a crawler ?! )
>> 
>> 	Now it happens that in some situations the service relative to Fast-CGI
>> go down but is not managed ( restart )from daemontools.
>> 
>> 	These are the daemontool service entry 
>> 		/etc/service/gs_seaside-9060: up (pid 25393) 142648 seconds
>> 		/etc/service/gs_seaside-9061: up (pid 7106) 15059 seconds
>> 		/etc/service/gs_seaside-9062: up (pid 20118) 194917 seconds
>> 
>> 	Every  Fast-CGI service create 3 entry.
>> 
>> 	I report the 9062 entry with:	 lsof -n -i -P | grep 20118
>> 
>> 		topaz     20118 dario    6u  IPv6 236275      0t0  TCP
>> [::1]:40117->[::1]:42453 (ESTABLISHED)
>> 		topaz     20118 dario    8u  IPv6 236276      0t0  TCP
>> [::1]:40503->[::1]:43399 (ESTABLISHED)
>> 		topaz     20118 dario   12u  IPv4 236281      0t0  TCP *:9062 (LISTEN)
>> 
>> 	When the 20118  Fast-CGI IPv4	go down the :
>> 	
>> 		topaz     20118 dario    6u  IPv6 236275      0t0  TCP
>> [::1]:40117->[::1]:42453 (ESTABLISHED)
>> 		topaz     20118 dario    8u  IPv6 236276      0t0  TCP
>> [::1]:40503->[::1]:43399 (ESTABLISHED)
>> 
>> 	remain active and therefore i believe that the daemontools does not
>> consider service ( 20118 ) to be dead.

	So this consideration is true?

>> 
>> 	But the web request ( when all the Fast-CGI are down )is not managed by
>> any  TCP *:906[ 0 - 2 ]  (LISTEN) because all are down.
>> 
>> 	Any idea about it?
>> 
>> 	Another question:
>> 
>> 	i can intercept the requests made by	 46.4.122.196 	 before creating the
>> related WASessions and replying ...????....  - do not reply?

	Thanks,

		Dario