DALnet-src

dalnet-src@lists.dal.net

182 discussions

Problem with IRCServices and bahamut ("Services is currently down..." reply missing)
by Charalampos Pournaris 14 Jun '09

14 Jun '09

Hello, I am experiencing a problem with the lastest version of bahamut - 1.8(06) (also tried the git version with ssl support) - and IRCServices 5.1.17. When services are connected to the network, everything works as expected and I get a response for commands like "NS HELP" but If for some reason services quits the network (SQUIT, Crash) and I send a command to the services, I get no response, instead of the "Services is currently down. Please wait a few moments, and then try again." message which is expected. If I restart the IRC server with no services on network, the "services are missing" message shows up normally. It's not that the services crashes too often, but it is a good indication for users to know that services are down instead of no response. Thanks and regards, Charalampos Pournaris

1 1

Re: [DALnet-src] SSL connections
by Andreas 11 Jun '09

11 Jun '09

Christoffer G. Thomsen wrote: > Andreas wrote: >> Christoffer G. Thomsen wrote: >>> Why do you not allow ssl connections on DALnet? >>> >> Probably because there is no software support for it yet. >> >> /ph0x > Unreal does. > In case you have missed this, DALnet uses their own software called Bahamut :) They probably won't change to Unreal even if hell freezes over. There are many other softwares that support SSL. /Andreas

2 1

SSL connections
by Christoffer G. Thomsen 09 Jun '09

09 Jun '09

Why do you not allow ssl connections on DALnet? -- Christoffer G. Thomsen, chris(a)cgtnet.dk Please use Firefox! Faster, more secure, better! www.getfirefox.com

3 2

bahamut-1.8.6
by Hexzone Enterprise 10 May '09

10 May '09

heloo dalnet team.. i'm already install bahamut-1.8.6 but ircd not running.. can i send copy ircd.conf to you for help? thanks Hexzone Enterprise (001825242-A) Taman Equine, 43300 Seri KembanganSelangor, MalaysiaTel : ( 010 - 2009 010 , 018 - 2405 077 , 013 - 6619 122 ) Faxs : 603 - 8943 6135 www.hexzone.net

1 0

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

← Newer
1
...
12
13
14
15
16
17
18
19
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

DALnet-src