Topic: [Request] fix cs_chanlimit (Read 52399 times)

chasingsol · « **Reply #25 on:** March 11, 2006, 02:22:32 AM »

One more request, and about the only thing I can think of, is the ability to set a max limit per channel that the module can set.

Other than that, it's running very well on my network (which is a decent size with plenty of traffic). Haven't noticed any buffer desynch after running all day, although it sometimes seems to be off by one (too low). Not a major problem, it corrects itself. It's not caused by a part, but appears to occur after a disconnect.

(Made a donation to Anope, thanks a lot guys!)

[Edited on 3-11-2006 by chasingsol]

Tom65789 · « **Reply #26 on:** March 12, 2006, 12:24:05 AM »

yer i have also told Rob about this.

i also asked him to do a special one for me if he had time, im not going to push him into making it though.

these are what i asked for:

- quits make it decrease by 1
- when a user is kicked and dont return decrease by 1
/* These Next options to be set in the Services.conf if the user wants them */
- restrict the LIMIT command to Service Admins, Staff, Roots, IRC opers (and not need SA to set it ON in someone elses channel)
- make it so its set ON default of a channel reg with the time and buffer specified in the config else 5:10

Tom65789 · « **Reply #27 on:** March 12, 2006, 07:51:08 PM »

0.5 Released:

Changes:

Now Decreases By 1 On Kick
Now Decreases By 1 On User Quit
Added Oper only access
Added to set ON when a channel is registered
Configurable .db name

--------------------------

Download From the Anope Modules Page

--------------------------

Config Options:

# CSLimitDBName [OPTIONAL]
#
# Setting this directive will make Services use the given database
# name for saving any cs_limit module settings into.

CSLimitDBName "cs_limit.db"

# CSLimitOperOnly [OPTIONAL]
#
# When defined the cs_limit module will only allow opers to modify the limit
# settings for channels

CSLimitOperOnly 1

# CSLimitDefaultBuffer [OPTIONAL]
#
# When defined the cs_limit module will apply this buffer to all new channels
# when they are registered. (note: requires CSLimitDefaultTimeout to be defined)

CSLimitDefaultBuffer 5

# CSLimitDefaultTimeout [OPTIONAL]
#
# When defined the cs_limit module will apply this timeout to all new channels
# when they are registered. (note: requires CSLimitDefaultBuffer to be defined)

CSLimitDefaultTimeout 5

[Edited on 12-3-2006 by Tom65789]

chasingsol · « **Reply #28 on:** March 13, 2006, 12:01:49 AM »

Excellent! Thank you Rob (and Tom65789 for reporting the update).

The module appears to not take in to account the presence of a BotServ bot in the channel, decreasing the available limit. With BotServ present, the buffer is off by 1 user. Solution of course is to raise the buffer by 1, but thought it should be reported.

Additionally, some method of viewing what cs_limit is currently set to (other than viewing the .db file) would be useful also.

[Edited on 3-13-2006 by chasingsol]

Tom65789 · « **Reply #29 on:** March 13, 2006, 05:03:42 PM »

These features were my Request to Rob lol. and i have payed him for doing a great job on it

so thanks Rob

There is a work around on that that is pretty simple, rather than putting the buffer at +5 put it to +6 and then its correct

i had this same problem but it makes it easier because Anope doesnt see the module joins as for the Bots this is what Rob told me out of his kind heart

"well botserv joins aint dealt with that would be a chance to the module, the line for other modules joining clients is a send_event() call"

just put the buffer to 6 rather than 5 to fix it

[Edited on 13-3-2006 by Tom65789]

chasingsol · « **Reply #30 on:** March 23, 2006, 06:22:10 AM »

Noticed a bug. On restart, it seems to change it's mind on what the limits are supposed to be. Below are contents of cs_limit.db

Before:
#GTN 6 60
#help 6 60
#p2p-irc.net 6 60
#pb.staff 5 5
#piratebits 6 60
#tpg 3 60

After:
#GTN 6 6
#help 6 6
#p2p-irc.net 6 6
#pb.staff 5 5
#piratebits 6 6
#tpg 3 3

[Edited on 3-23-2006 by chasingsol]

Tom65789 · « **Reply #31 on:** March 23, 2006, 04:05:14 PM »

hmm, yep the times reset but isnt 60 a bit too much? because if its a big channel 5 people may join within 60 seconds. i currently have mine a Buffer 6 Time 10, but its just my opinion

chasingsol · « **Reply #32 on:** March 28, 2006, 09:12:19 PM »

Depends on whether you think 10 seconds is long enough to react to a botnet joining. All you get is 10 seconds before the limit gets raised again and you get more bots joining.

I have several large (500+) user channels on my network (actual chat, not XDCC which isn't allowed), with a variance of 6 and timer of 60 seconds has never caused a problem with people not being able to join, but it's certainly stopped botnets.

Incidentally, we've modified the module to use the timer on both joins and parts/quit. Alleviated the complaints we got about continuous mode spam when someone would leave/quit.

Tom65789 · « **Reply #33 on:** March 28, 2006, 09:47:16 PM »

hmm, care to share it? lol

anyway, does your limit decrease on a kick chasingsol?

chasingsol · « **Reply #34 on:** March 29, 2006, 03:45:53 AM »

Hi Tom,

Yes, it does decrease on a kick. If you'd like to pm me your e-mail, I can send you the modified version. I won't post it here out of respect to Rob. Also, since you have contacted him regarding needed bug fixes, I don't want to tie myself in to being tech support for a module I didn't write!

Cheers,

Mark.

Tom65789 · « **Reply #35 on:** April 01, 2006, 07:11:42 PM »

ok must be something with our network then lol, our kick dont work right but i can fix it, i have also contacted you

chasingsol · « **Reply #36 on:** April 10, 2006, 09:09:51 PM »

One thing I have noticed, the buffer doesn't seem to stay stable after extended periods of running. I have it set for a 6 user variance in a channel, and it's now limiting at 9. Deleting the limit from that channel and reapplying it does not change this behavior.

Any word on the fixes yet Tom?

Tom65789 · « **Reply #37 on:** April 11, 2006, 03:11:57 PM »

i dont but mine has been working fine, maybe try a unedited version of it. i also edited my own so now it works in channels that arent registered too.

Have your Services split or have any of the servers?

chasingsol · « **Reply #38 on:** April 20, 2006, 04:05:27 AM »

Services has split once since using this module.. Ping timeout, which would imply a lockup. No core file, didn't crash. Unknown if it's related.

Only thing of any use was the current process state "T":

Code: [Select]

ircd 14777 0.0 1.0 17784 10792 ? T Mar25 20:02 ./services

Noticed that 0.6 is our modified version, flattered to say the least!

Rob, any update on bug fixes? The database weirdness one is the most annoying, and some limit drift occurs after a long period of use. The drift is always upward, allowing a larger limit difference than defined (other than the +1 required anyway). Perhaps an internal Anope issue?

Dave Robson · « **Reply #39 on:** April 20, 2006, 07:52:56 AM »

The database loading should have been fixed ages ago and is on whatever version is the latest on the modules web page.

chasingsol · « **Reply #40 on:** April 21, 2006, 02:02:32 AM »

Hi Rob,

Thanks for the response. The database corruption issue is not resolved as of version 0.6. For some reason, it loses trailing 0's (possibly any trailing character).

For example, a database entry of:

#p2p-irc.net 6 60

becomes

#p2p-irc.net 6 6

This occurs on a module reload or on a services restart. Does not occur during normal runtime.

Cheers,

Mark.

[Edited on 4-21-2006 by chasingsol]

Tom65789 · « **Reply #41 on:** April 21, 2006, 08:00:17 PM »

im sure that was fixed. my databases seem fine even after restart and reload

chasingsol · « **Reply #42 on:** April 21, 2006, 09:09:44 PM »

I'll check it out again. It's entirely possible I was being dense and didn't do "make clean" before doing "make modules"... wouldn't be the first time.

Tom65789 · « **Reply #43 on:** April 21, 2006, 10:42:27 PM »

lol but it works on my IRCd

chasingsol · « **Reply #44 on:** April 22, 2006, 02:14:54 AM »

Sure enough, I was obviously having a "brain lapse". Only issue I see remaining is the "drift". Otherwise, works great.

Thank you Tom for commissioning this module and Rob for writing it!

Tom65789 · « **Reply #45 on:** April 22, 2006, 04:01:30 PM »

np lol. but Rob pwns all

chasingsol · « **Reply #46 on:** April 22, 2006, 07:09:52 PM »

If anyone is interested in a patch that makes the module honor the time limit on part/quit/kick as well, you can download it here:

http://www.p2p-irc.net/downloads/cs_limit.diff

This comes with no warranties, yadda yadda. If it makes your services keel over and die, you were warned.

To patch cs_limit.c, download the above file to the same folder as cs_limit.c and do:

Code: [Select]

patch cs_limit.c < cs_limit.diff

Tom65789 · « **Reply #47 on:** April 23, 2006, 09:02:27 PM »

mmmk i did make an alernative solution too which i believe is better but i have no idea how stable it is but its been running for many weeks just fine with no downtime on my server. what my version does is it has an extra config option called CSLimitTimeout2 10 and what this does is it acts like the CSLimitDefaultTimeout 60 like it changes the limit after 60 seconds or whatever value its changed to except CSLimitTimeout2 acts on quits parts and kicks where as CSLimitDefaultTimeout is for joins so the values can be different. and i am still looking how to make it limit channels that are not registered but i think i know how i can do this but it would only be a tempory limit because when the user leaves it removes the limit and thats it.

[Edited on 23-4-2006 by Tom65789]

razr · « **Reply #48 on:** October 25, 2006, 12:20:37 AM »

anyon got a working link to this module

Jobe · « **Reply #49 on:** October 25, 2006, 01:49:13 AM »

Try on http://modules.anope.org

News:

Author Topic: [Request] fix cs_chanlimit (Read 52399 times)

chasingsol

chasingsol

chasingsol

chasingsol

chasingsol

chasingsol

chasingsol

chasingsol

chasingsol

chasingsol

chasingsol

razr