lismore / peerblock

Peerblock
Other
0 stars 0 forks source link

Display list-name in log-window #15

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
When logging blocked IPs, we should display which list contained the rule
causing this IP to be blocked.  See these forum-threads for more details:
(http://forums.phoenixlabs.org/showthread.php?t=17730),
(http://forums.phoenixlabs.org/showthread.php?t=15914).

This will likely require changes to the DB, and potentially drastically
increase the memory-requirements of the program.  Make sure we test
memory-usage thoroughly, and possibly make this an optional feature.  Might
even be worth NOT keeping this in memory at all times, and instead only
read it from a file while we're preparing to log it?  Especially if we
cache "recently blocked" entries, we should be able to get away with only a
minimal overhead here.  Then again, if we're only storing an index into a
string-table, this might not bloat us up too much...

Original issue reported on code.google.com by peerbloc...@gmail.com on 13 Jul 2009 at 4:23

GoogleCodeExporter commented 8 years ago

Original comment by peerbloc...@gmail.com on 24 Jul 2009 at 5:48

GoogleCodeExporter commented 8 years ago

Original comment by peerbloc...@gmail.com on 24 Jul 2009 at 5:51

GoogleCodeExporter commented 8 years ago
Removing 'After1.0' release-targetting.

Original comment by peerbloc...@gmail.com on 29 Sep 2009 at 3:58

GoogleCodeExporter commented 8 years ago

Original comment by peerbloc...@gmail.com on 30 Sep 2009 at 4:34

GoogleCodeExporter commented 8 years ago
Issue 216 has been merged into this issue.

Original comment by peerbloc...@gmail.com on 1 Dec 2009 at 4:46

GoogleCodeExporter commented 8 years ago
Don't know how I didn't catch this one.

Anyways, how would it take up so much more memory? You're already reading 
"Range" 
(a.k.a. block name), is it that much more to have it grab the list name at the 
same 
time? 

Original comment by brent.ne...@gmail.com on 2 Dec 2009 at 5:59

GoogleCodeExporter commented 8 years ago
Sorry, that was actually stream-of-consciousness writing on my part I think.  My
initial concern was that we'd be keeping an extra string in memory at all 
times, for
each range present in each of the blocklists you have activated.  Then I 
realized
that it probably wouldn't be so bad, since we'd likely just store a string 
table with
one entry for each list-name, and then with each range just store a byte or two 
worth
of an index into that list.

It's currently targetted for PeerBlock 1.1, so it should be going into the Beta
Release train sometime within the next month or two.

Original comment by peerbloc...@gmail.com on 2 Dec 2009 at 6:18

GoogleCodeExporter commented 8 years ago
Issue 241 has been merged into this issue.

Original comment by peerbloc...@gmail.com on 20 Jan 2010 at 12:00

GoogleCodeExporter commented 8 years ago
This is far and away my favorite enhancement I have seen yet. My only addendum 
would
be if there were some way to not only see which rule is blocking the IP, but 
also to
allow the entire IP range from the main screen without having to go into the 
list
manager (Sorry if this part is under another thread...I couldn't find it). 
Seriously,
I would LOVE to have this option. Even if it doubled the footprint on my hard 
drive
it would still be worth it. 

Original comment by Trinity....@gmail.com on 5 Mar 2010 at 5:58

GoogleCodeExporter commented 8 years ago
Sorry I didn't spot this one.
I just submitted a duplicate, issue 300.

This would be a great feature.
I'm not sure about listing the range though I mean it wouldn't hurt of course.

But I'd end up checking the list anyway.
Their could be more that one entry for the same thing.
I'd want to get them all, for example:
Site 1   68.100.200.1  - 68.100.200.4
Site 1   68.100.200.10 - 68.100.200.10

Thanks,

Kenny

Original comment by kenny...@gmail.com on 9 Apr 2010 at 6:50

GoogleCodeExporter commented 8 years ago
Issue 318 has been merged into this issue.

Original comment by peerbloc...@gmail.com on 20 May 2010 at 3:00

GoogleCodeExporter commented 8 years ago
Has this feature been added?

I see that it was meant to be added to the beta soon:

"It's currently targetted for PeerBlock 1.1, so it should be going into the Beta
Release train sometime within the next month or two."

I downloaded 1.0+ (r320) for this feature and it doesnt seem to be there.

Has it not been added to the beta yet?

thanks
Martin

Original comment by j0hnw3...@googlemail.com on 25 May 2010 at 4:57

GoogleCodeExporter commented 8 years ago
It's not implemented yet.

Original comment by XhmikosR on 30 May 2010 at 11:56

GoogleCodeExporter commented 8 years ago
Issue 300 has been merged into this issue.

Original comment by nightstalkerz on 29 Jul 2010 at 9:31

GoogleCodeExporter commented 8 years ago
This would be a great improvement to PB. Like to see this implemented soon. The 
memory issues not a biggie sense most user now have 4 to 6 gigs.

Original comment by robrpatt...@gmail.com on 4 Aug 2010 at 2:16

GoogleCodeExporter commented 8 years ago
I would also like to see this implemented. I can't see that assigning a "rule 
number" to each item would use that much more memory, but either way, perhaps 
the feature could be enabled/disabled at the user's preference.

Additionally, I'd really like to see this feature added to the log file. A 
"rule number" (i.e. pointer) may not work in this case unless PB assigns unique 
IDs to every rule set ever created on the host machine (which is an option if 
using at least 4-byte IDs). However, for log files, it may be better to simply 
put the filename of the list in question. It may also be useful to inclue unix 
datestamp of the file's modification time, in case a list changes over time. 
Again, these features could also be enabled/disabled at the user's preference.

Thank you for your consideration. I hope to see this soon.

Original comment by JinxD...@gmail.com on 11 Jan 2011 at 1:45

GoogleCodeExporter commented 8 years ago
@robrpatt: I suspect your sample might be a bit biased. Never take memory for 
granted.

Original comment by wearenot...@gmail.com on 14 Aug 2012 at 10:46