DALnet-src April 2009

dalnet-src@lists.dal.net

23 participants
15 discussions

Re: [DALnet-src] SVSNICK and cached ban status handling
by kevin＠buley.org 05 May '09

05 May '09

If SVSNICK is sent to the user's server is this actually an issue? A NICK sent from the user would go to the local server, which would have the correct ban information due to your patch. Or are we talking about non SVSNICK events... Where a user has changed to a nick that matches a ban on their own? ------Original Message------ From: Ned T. Crigler To: kevin(a)buley.org Cc: dalnet-src(a)lists.dal.net Sent: Apr 23, 2009 19:07 Subject: Re: [DALnet-src] SVSNICK and cached ban status handling On Thu, Apr 23, 2009 at 10:25:07PM +0000, kevin(a)buley.org wrote: > I like this! Too many times have I set a ban on guest*!*@somedomain > only to watch an endless nick->guest->nick cycle. There are times when > we don't want to remove a user from the channel, but we DO want to > stop their lame script. Currently the only options are to kick the > user or remove and re-set the ban... Both are undesdirable. > > In our off-list discussion you mentioned a case where this may still > happen... Is there a solution other than changing banserial for every > NICK event? > That problem is because SVSNICK is relayed to the person's server, which then does the forced nick change locally, and then sends out a standard NICK protocol message to the other servers. The other servers cannot tell the difference between a normal nick change and a forced nick change. This will cause remote servers to have the old user's banserial cached, since a normal NICK change doesn't change banserial right now. I think a flush of the banserial in m_nick in addition to m_svsnick is the easiest way to fix this, unless maybe SVSNICK is changed to not use a regular NICK protocol message to other servers. That unfortunately, would probably involve backwards-compatibility protocol issues. With the m_nick change, unpatched servers would just have a out-of-date banserial cached. -- Ned T. Crigler -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- Kevin Buley

6 10

umode +C
by Kobi Shmueli 01 May '09

01 May '09

Hi all, I was thinking about a new user mode (+C) to help us in our endless fight against spamming. This user mode will only allow messages/notices/invites from users who share one or more channels with you with a few exceptions: 1) It'll not work on users who are in no channels. 2) Opers (+o) will be able to bypass it. 3) With the combination of umode +R, identified users (+r) will be able to bypass it. It'll need to be enabled by default to be effective IMO (possibly together with umode +R so users will be able to get messages from either people who are identified or share the same channel with them). Thoughts? -Kobi. (Kobi_S @ DALnet)

8 13

Release of libd
by Aaron Wiebe 29 Apr '09

29 Apr '09

Greetings All, As I mentioned last week, libd is the base framework that will be used to make up Bahamut 2.0 (or possibly some yet-to-be-named ircd). I have now made the code available - you can grab it via git: git clone http://code.dal.net/libd.git Please take a look! There is quite a bit of work to be done, and I'm more than willing to accept code from anyone. Please keep in mind that this is not nearly complete, and I still see many areas which I'm not happy with. I would have felt better to have kept this under wraps for another six months to poke it, but honestly - I work too slowly by myself. The coding style is effectively the Linux Kernel style, with an exception made for line length. K&R, real tabs, etc. I WILL be enforcing coding style, so please review your patches prior to submitting them to make sure they look consistent. The package has a TODO list, but I'll include it here. I look forward to your comments and to your code contributions! Please send patches to me and dalnet-src@ Thanks! -epiphani TODO LIST --------- API: I'd like to see the API cleaned up here and there, and generally consolidated and documented. Groups: I'm having second thoughts about the supergroup/subgroup structure I originally built. Review, and possible remove the supergroup/subgroup functionality, leaving that to the application to manage. Threading: - Implement threading! Discussion ongoing - current ideas focus around... - Accept thread - poll/read/parse thread pool assigned sockets from accept thread - write thread to handle blocked sockets that cannot be written to immiedately (?) - event timer thread and interfaces to go with it Socket Handling: - SSL support, possibly encrypting prior to buffering in order to maintain vectored writes - Compression support via zlib - UDP socket support - Outbound connect support Error Handling: - The error handling and logging facilities need to be improved and properly implemented Time Syncronization: - Possibly in concert with the event threading system, time sync items need to be addressed Other than that, look up some FIXME's in the code, there are a bunch of them!

1 0

Libd Design (Bahamut 2.0)
by epiphani 27 Apr '09

27 Apr '09

Greetings All, As promised, here is a basic rundown on the library that I've been working on that I see as the basis of Bahamut 2.0. I'm currently calling it libd - lib daemon, because I'm so original and creative. At the bottom of this email is the code of a simple echo server based on the library, which might be useful as a reference. I'm working on a slightly object oriented model, while still using straight C. The general idea is simple - the library implements all lower level functions regarding nonblocking socket interaction. It (will) support ipv6, compression, SSL, and threading. At current, it supports ipv6 only of those features. The API is designed based on an object model, for example: To create a listener, call the routine create_listener within the socket engine, get an "object", and set up some basic things you want associated with the listener. The minimum would be to give the library a function to identify what constitutes a message, then a function that would parse and act on that message. You could also define functions that would be called when we accept a connection and when a connection is dropped. There are four core objects - the socket engine handler itself, SockEng, the listener object, Listener, the client object, Client, and the grouping object, Group. SockEng is used to manage the "global" definitions of the library - such as defining error handling routines. Listeners are used to manage listeners, and what default settings a client has when they connect. Clients are used to interact with clients. Groups are used to group together different sets of clients, and send to sets of clients using some optimizations accordingly. This gives a very high-level overview - but I'd like to talk about the threading model I have in mind. This hasn't been implemented yet, but I've been designing a lot of the system with this in mind for the future. I've decided that threading is important to support simply because the recent crop of CPU designers hate programmers enough to effectively force it on us. Threading has always been a point of heated argument in the past - how do we do it? I've come up with the following design: 1. Poll thread - basically hosts the polling engine, whatever it happens to be. 2. Read/Write thread set(s). Watch queues and polling states, reads and writes from and to sockets, and interacts with queues. 3. Event trigger thread(s). Schedules and triggers events on timers, for anything that isn't edge-triggered from a socket read. 4. Parsing/worker thread pool. Executes actual work from event or read threads, and places data into write thread queues. I'm trying to design the library API in such a fashion that it actually handles most of the threading logic. However, getting this to work as we want will take a lot of time, but I have a feeling that IRCd will thread quite well in this method. My hope is to build a library that will be flexible enough, without being too complex, that it could be applied to other projects. So what are people thinking so far? Does this look like a good direction? Does anyone have comments on the current design? I'll try to clean up the code and get it available sometime in the next week for people to start actually poking. Talk! Discuss! Criticize! Insult! Lets get talking. -epiphani ====== test.c ======= #include "sockeng.h" int client_packet_delim(Client *c, char *buf, int len) { int i = 0; /* find a \n */ while(len > i) { if(buf[i] == '\n') return ++i; i++; } return 0; } int client_echo_parser(Client *c, char *start, int len) { char buf[BUFSIZE]; memset(buf, 0, BUFSIZE); snprintf(buf, len+1, "%s", start); c->send(c, buf, len); return 0; } void client_disconnecty(Client *s, int err) { printf("Client disconnected: %s\n", strerror(err)); } int main(int argc, char *argv[]) { SockEng *s; Listener *l; s = init_sockeng(); l = s->create_listener(s, 1111, NULL); if(!l) { printf("no listener create\n"); return -1; } else { l->set_packeter(l, client_packet_delim); l->set_parser(l, client_echo_parser); l->set_onclose(l, client_disconnecty); } while(1) { if(s->poll(s, 1)) { printf("poll error\n"); return -1; } } return 0; }

4 5

nomemo
by lionel 26 Apr '09

26 Apr '09

I know what nomemo means and it's function RE: nicks What i was asking for is this, in the next build is it possible to set nomemo for individual channels EG: nomemo from #channel1/2/3/4 but allow memos from #channel5/6/7/8 etc Ozlion/lionel Regarding nomemo, that already exists, too. On Sat, Apr 25, 2009 at 3:42 PM, Steffan Wood <steffan.wood(a)me.com> wrote: If I remember correctly something of this sort has been discussed previously. Regarding you're first proposal of being able to disable receiving nickname memos, I wouldn't say that doing this would be a hard task. Functions similar to this are already implemented in most other packages proving it to be possible.Regarding your second proposal, I'm not sure I understand what you are meaning, but if you are asking to be able to restrict which access level can send a channel memo, then that is already implemented using SET <#channel> MEMO, it's explained in greater detail using ChanServ HELP SET MEMO. On 25 Apr 2009, at 01:42, lionel wrote: Hi Gang I have no idea if the suggestion below has been covered in earlier posts Suggestion: RE: /nickserv set nomemo on/off - is it possible to code into the next upgrade: /nickserv set nomemo on/off for specific channels for founder/sop/aop? Regards Ozlion/Lionel Join me in my chat room at #auschats on DALnet http://www.mirc.com/ #auschats channel forum http://forumforfree.com/auschats.html #auschats stats pages http://www.ozlion.com/auschats.html

3 3

nomemo
by lionel 25 Apr '09

25 Apr '09

Hi Gang I have no idea if the suggestion below has been covered in earlier posts Suggestion: RE: /nickserv set nomemo on/off - is it possible to code into the next upgrade: /nickserv set nomemo on/off for specific channels for founder/sop/aop? Regards Ozlion/Lionel Join me in my chat room at #auschats on DALnet http://www.mirc.com/ #auschats channel forum http://forumforfree.com/auschats.html #auschats stats pages http://www.ozlion.com/auschats.html

3 2

Bahamut Coding Update / Direction
by epiphani 24 Apr '09

24 Apr '09

Greetings all, I've been meaning to write this for a while now, but I've been shamelessly delaying based on some work I wanted to get together prior to sending this. You'll understand why a little later in this email... Firstly, some short-term items for discussion. I'm currently envisioning two more updates to the Bahamut 1.x - possibly with a few little patch releases as well - but two major updates. First release: - Client side SSL support - Small functionality changes - Internal and protocol support for IPV6 addresses. Second release: - Full IPV6 support - Other possible features, such as user host masking. The logic between the two separate releases is simple - we need to support ipv6 without accepting connections from ipv6 sources. Without this first step, we will break all kinds of things. NICKIP (the server<>server capab) is a good example of this. I'm hoping we can have a lively discussion on the other items. I have no doubt user hostmasking will result in some loud opinions. Lets hear them! Second, some housekeeping. As you may have noticed, we've switched to git as our version control system. This means a few different things in how we're managing code contributions. I'd really like to encourage active participation from anyone and everyone to submit patches - I will review everything that gets posted to this list, and fold them into the master tree as things go. The coding team will also play a big part of the review process. Putting it bluntly - they're on the same footing as everyone else on their ability to get code into the master tree. I'll likely review their patches less intensely, simply because I know their work... I will also shortly be changing the git tree to send an email to this list when I update the master. I'm hoping we can get enough exposure and transparency to get more of you actively involved. If you're looking for something to do, the IPv6 stuff is high on the list! The last, and final point of discussion - the infamous Bahamut 2.0. We've had a lot of discussion and, bluntly, vaporware type statements about Bahamut 2.0 in the past. It was going to be amazing, fully modular, a complete rewrite, wash your car, satisfy your wife, etc etc. Well, until about four months ago, nothing of Bahamut 2.0 ever actually got started. Four months ago I started a small framework library I wanted to use for the basis of Bahamut 2. I haven't been working too hard on it - I haven't had a lot of time.. but this week I've got it to the point of an echo server. In the next week or so, I'll make the code available. In a separate email, I'll detail a lot of the work that I've done so far, and what direction I'd like to see on the system. The currently library is far from complete, but I'm hoping we can get some involvement from the community to jump-start this effort. Look forward to another email this morning detailing the general design goals! Thanks, -epiphani

1 0

SVSNICK and cached ban status handling
by Ned T. Crigler 23 Apr '09

23 Apr '09

After services does a SVSNICK on a user, if the new nickname is banned in a channel, they are still allowed to talk and change their nick if they were not banned previously. For example: *** Mode change "+b testing!*@*" on #test by RuneB *** Mode change "-o RuneB" on #test by RuneB <RuneB> I can talk. Now I'll force a SVSNICK on me to testing. *** RuneB is now known as testing <testing> can I still talk? <testing> yep. This is because is_banned doesn't recheck the ban list if the banserial has not changed for the user (instead it returns immediately). SVSNICK forces a nick change, but doesn't change the banserial in any of the channels the user is in. This causes is_banned to think the ban status has not changed. I have written a patch to fix this. After SVSNICK is done, it now goes through the channels the user is in and changes their cached banserial. is_banned will then recheck the ban list the next time it is called. For example, with the patch: *** Mode change "+b testing!*@*" on #test by RuneB *** Mode change "-o RuneB" on #test by RuneB <RuneB> I can talk. Now I'll force a SVSNICK on me to testing. This time, with a patch to force my banserial to be changed. *** RuneB is now known as testing <testing> can I still talk? *** #test Cannot send to channel <testing> nope. *** #test Cannot send to channel -- Ned T. Crigler

2 2

mailing list filtering
by Aaron Wiebe 23 Apr '09

23 Apr '09

Greetings all, As it stands, the dalnet-src mailing list is filtered. Back before end-user spam solutions were more prevalent, this made a fair bit of sense. These days I'm not so sure. Would anyone have any problem with moving this list to an unmoderated list? It would make discussion quicker. Thoughts, comments? -epi

6 5

need to ask some thing..
by SaLik Iqbal 20 Apr '09

20 Apr '09

hello there.. sorry for disturbance.. but have to ask something related about bahamut 1.8, is there any way to halt some specific words? like mirc can do it by remote on *:input*, but can i do it by server default? have to banned some abusive words :/.. thanking you.. salik _________________________________________________________________ Rediscover Hotmail®: Get quick friend updates right in your inbox. http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Up…

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

DALnet-src April 2009