Author |
Message |
64bitguy
The Mouse Is Extension Of Arm

Joined: Mar 06, 2004
Posts: 1164
|
Posted:
Sun Oct 17, 2004 3:16 am |
|
Quote: | Warning: set_time_limit(): Cannot set time limit in safe mode in /admin/modules/sentinel/ABIP2CountryUpdateTracked.php on line 26 |
I got this after starting work in the IP2C menus in Nuke Sentinel shortly after a successful implementation. I should note that whatever happened shut down my site. I went to the NukeSentinel's Main Menu (where it showed the site as enabled in the menu) and simply clicked "save". That then re-enabled the site, though I'm baffled to figure out what caused it to be disabled in the first place.
At the time this happened, I was running the IP2C Updated Blocked IPs (which was succesful) and then was in the process of running Updated Tracked IPs when I first noticed the problem.
Thanks |
_________________ Steph Benoit
100% Section 508 and W3C HTML5 and CSS Compliant (Truly) Code, because I love compliance.
Last edited by 64bitguy on Sun Oct 17, 2004 10:44 pm; edited 1 time in total |
|
|
 |
BobMarion
Former Admin in Good Standing

Joined: Oct 30, 2002
Posts: 1037
Location: RedNeck Land (known as Kentucky)
|
Posted:
Sun Oct 17, 2004 5:10 pm |
|
The Update Blocked IP's and Update Tracked IP's aito-disables the site while that section runs and re-enables the once when it completes.
To get around the set time limit error open both admin/modules/sentinel/ABIP2CountryUpdateBlocked.php and admin/modules/sentinel/ABIP2CountryUpdateTracked.php and comment out the set_time_limit( 600 ); line. This was added to help ensure slow servers didn't time out while running these two scripts. The reason both of these scripts auto-disable your site while running is it could go into an endless loop if it's updating the Tracked IP's while your site is still getting many visitors. |
_________________ Bob Marion
Codito Ergo Sum
Only registered users can see links on this board! Get registered or login! |
|
|
 |
64bitguy

|
Posted:
Sun Oct 17, 2004 7:04 pm |
|
Cool... Thanks Bob.
It may be a good idea to put something on the screen letting users know that it will temporarily shut the site down when it runs, as well as to give Geekguy a heads-up to make sure that this information gets added into the Users guide...
It's not urgent, but I'm thinking that it may be better to let everyone know in these apps versus being like me thinking that it's a bug and subsquently filling out a bug report....
Thanks for the heads-up... I've made the change and will see if it works now.
One thing I noticed last night is that banned ranges IP2C information wasn't getting changed, instead they were all listed as Afganistan (the first item on the list)... I did a manual lookup of each range that I banned, and then went back and manually changed the IP2C information for each range. Am I right in assuming that this fix (and subsequent re-run of the feature) would have addressed that and automatically replaced those values?
Thanks! |
|
|
|
 |
BobMarion

|
Posted:
Sun Oct 17, 2004 8:19 pm |
|
It should have corrected the issue. Sounds like when it errored it just did a mass update on everything to af. |
|
|
|
 |
64bitguy

|
Posted:
Sun Oct 17, 2004 8:31 pm |
|
Cool... Thanks Bob.
When adding new banned "Ranges", will it by default identify the country when adding the new range? Or does that not happen until you re-run the "IP2C Update Blocked IP's"? I'm just trying to figure out the process and determine if I should rerun the IP2C Update Banned IPs after adding new ranges.
Finally, as a heads up, once I made the change that you noted above, running either update worked flawlessly. On the first IP2C "updater" It shuts down the site for a few seconds when the success screen comes up, and then it automatically brings you back to the menu after that. Shortly after that the site returned automatically to operational status.
Running the "Tracked" update (the second one on the list) did the same thing, only now with the change made above, it made it to a second process (before it only showed 1 or 1 when I ran this, versus now showing 2 processes, both successful) with it again shutting down the site on the success screen, and after being patient for a whopping ten seconds (LOL), having it return to the main screen after completing the second process to find the site (again) automatically restored to operational status. Or, to say it a shorter way.. Very nice... everything worked great.
Again, thanks. |
|
|
|
 |
BobMarion

|
Posted:
Sun Oct 17, 2004 9:43 pm |
|
Blocked Ranges depends on you to porperly set the country since you may not be blocking the same range that the IP2C has or blocking a range that crosses over two IP2C ranges.
What I could do for the next version is to include an "Update Blocked Ranges" option as well but it might not work well for the reasons described above.
There are four "Range" sections that you have to set the country for.
1) Reserved Ranges - These are range that are normally IANA ip ranges
2) Protected Ranges - These are ranges (like crawlers) that you don't want to get blocked.
3) Excluded Ranges - These are ranges that you don't want tracked, again like crawlers.
4) Blocked Ranges - These are jerk wad ranges you don't want on your site  |
|
|
|
 |
64bitguy

|
Posted:
Sun Oct 17, 2004 11:44 pm |
|
Cool...
I know what you mean about blocked ranges crossing over into multiple countries.
I (in fact) deleted or reduced a couple of ranges that were in Protector which I transferred over to NukeSentinel that (upon reflection) I decided were a little TOO wide.
What I did (yes, while I've blocked afghanistan, it's not fair to leave Syria's name off my list) was to use the first IP address in the range to define the country. I'm fine with that in considering what would be necessary (in terms of coding) to actually have NukeSentinel provide IP2C information on all blocked countries within any particular range. (I wouldn't want to code it, nor would I wish that task onto anyone else either.. LOL)..
One thing I found (in terms of abuse) were some users that were getting sneaky and using IP's like 10.x.x.x For that reason, I have (for example) banned that entire range in NukeSentinel. It's like someone coming in via 127.0.0.x or how I think of it... "Not bloody likely".
Thanks for the information Bob... So far everything looks terrific.
Keep up the Great work... (Gee, I wonder if I need protector anymore....) |
|
|
|
 |
BobMarion

|
Posted:
Sun Oct 17, 2004 11:52 pm |
|
If you look at the "Reserved Ranges" section you will find those both in there. When someone comes to your site it checks to see if they are masking their real ip with a "Reserved IP and if they are it looks at the next HTTP response section and if it's ip is not in hte "Reserved Ranges" then it accepts that as a valid ip whereas reserved ranges are invlaid ip's Got sneaky didn't I  |
|
|
|
 |
BobMarion

|
Posted:
Sun Oct 17, 2004 11:53 pm |
|
Quote: | (Gee, I wonder if I need protector anymore....) | In a word, NO  |
|
|
|
 |
|