| |
| |
| |
|
<anjuta> if it was up to me, i would hide server ips, but unhide spoofed user's ip's (meybe only locally)
<anfl> ie, the logic above :)
<anjuta> umm, actually yes
<anfl> I dont see the need for a middle ground between hiding all spoof ips and not hiding them to local opers
<anfl> if it really matters to an admin, they have the config
<anfl> :p
<jilles> the final else should be return 1
<jilles> and you may need something extra for IsUnknown(target_p)
<anfl> yeah, noted that when about to commit ;-)
<anfl> and I dont particularly like hiding IsUnknown()
<jilles> opers should be able to see ips of unknowns
<jilles> but lusers probably not
<anfl> I dont know any place in ircd where we would give users a list of unknowns ;-)
<jilles> but on reading m_trace I see that only local opers can get information on unknowns
<jilles> specific traces only work on persons
<anfl> I might make hide_spoof_ips a conf option
<anfl> im hesitant to do it for servers ips tho
<anfl> because theres very very little reason to be undefining it
<anfl> reet, bed :)
<sjk> Odd, when doing /stats q the counter shows 17, but there has been no jupe-join notices sent from server
<jilles> not that odd
<jilles> trying to send to a juped channel also increments the counter
<jilles> if(MyClient(source_p) && hash_find_resv(chptr->chname) &&
<jilles> !IsOper(source_p) && !I***emptResv(source_p))
<jilles> return CAN_SEND_NO;
<jilles> this even applies for opers and exempt resv users
<jilles> and this is first in can_send() (except for the exception that servers may always send)
<jilles> joins by exempt resv users and attempts by exempt jupe users do not increment the counter
<jilles> attempts by opers (not jupe/resv exempt) do increment the counter but do not generate a notice
<anjuta> :)
<anjuta> i think i know what is the most wanted nick on my network :)
<anjuta> * Q 11607 S :services nick
<anjuta> humm, how do you maintain the file revision of each source file in the comment at the end of the gpl license?
<dougk_ff7> $Id: $ ?
<anjuta> yes
<anjuta> it should be something from cvs/svn ?
<anjuta> oh, found it.. it's trivial
<Noah[unde> on default ratbox services are in +S mode ?
<Noah[unde> (Silence mode)
<jilles> +S == service: cannot be kicked/deopped
<Noah[unde> >ns< help
<Noah[unde> * Error: NS is in silence mode and does NOT accept messages from unregistered/unidentified (too recently registered) nicknames
<Noah[unde> NS -> NICKSERV
<jilles> hmm, you're using some ircd where +S is something else
<Noah[unde> yes..
<Noah[unde> I understand now what is the problem...
<jilles> rserv will introduce clients with +iDS or +iDSo
<jilles> (depending on conf)
<Noah[unde> ahm.. a`ll try
<Noah[unde> 10x for help
<Noah[unde> :)
<jilles> your ircd has another umode to protect services from kicks/deops?
<Noah[unde> yes, but its modefied not by me and I dont now what is this mode
<anjuta> his ircd has some code stolen from my old hybrid 6.0 as far as I can see :)
<Noah[unde> hehe
<Noah[unde> :)
<Noah[unde> not so baad :)
<anjuta> his ircd performs a strcmp() or similar in order not to kick/deop services or whatever you define as services :)
<jilles> haha
<anjuta> hybrid6 coding style :)
<anjuta> it's funny but I'm still getting rid of this piece of code for the whole network..
<anjuta> Noah[unde, suggestion not to introduce services' nicknames with umode +S
<anjuta> or change the ircd..
<jilles> charybdis does several other things with +S: hiding channels in whois, hiding from oper list
<Noah[unde> yes but ratbox services are in default mode with +S
<anjuta> jilles, define charybdis ?
<jilles> a fork of ratbox 2.1 used on a network I oper on
<anjuta> humm, it's similar to what I'm pushing into ratbox atm
<jilles> svn co http://svn.atheme.org/charybdis/trunk/ charybdis
<anjuta> i think i'm in love with svn
<anjuta> played with it last night.. so easy to use..
<jilles> :)
<anjuta> eek, need to do some ritual shopping with my mother.. laters
<anjuta> i'll check charybdis this night
Return to ratbox
or
Go to some related
logs:
what colors make brown?
|
|