From dropper at softhome.net Fri Jan 26 06:57:28 2001 From: dropper at softhome.net (Levent OZVEREN) Date: Sat Oct 23 23:09:11 2004 Subject: [Ircservices-coding] subscribe dropper@softhome.net Message-ID: <001c01c087a8$52a870c0$a591bad5@m4l7l9> From andy at strugglers.net Sat Jan 27 04:18:06 2001 From: andy at strugglers.net (Andy Smith) Date: Sat Oct 23 23:09:11 2004 Subject: [Ircservices-coding] akill sanity checking Message-ID: Hi, There's a FIXME in the ADD section of do_akill from akill.c regarding wanting a better way to check for an insane akill mask. I've found the following idea useful: for (i = strlen(mask) - 1; i > 0 && mask[i] != '@'; i--) { if (! strchr("*?.", mask[i])) { nonwild++; } } if (AkillWildThresh && nonwild < AkillWildThresh) { notice_lang(s_OperServ, u, OPER_AKILL_MASK_TOO_GENERAL); return; } i.e. it counts from right to left in the mask checking how many characters there are which don't match '?', '*' or '.'. AkillWildThresh would be a config option, an example setting of 4 would prevent the following akills: *@* *@?* *@*?com *@*.com but would allow akills such as: *@*a.com *@foobar* Works for me, and is nicely configurable. -- Andy Smith From andy at strugglers.net Mon Jan 29 15:01:34 2001 From: andy at strugglers.net (Andy Smith) Date: Sat Oct 23 23:09:11 2004 Subject: [Ircservices-coding] Re: [IRCServices] Services 4.5pre0 released In-Reply-To: <3a74b222.15614@prima-lan.net> References: <3a74b222.15614@prima-lan.net> Message-ID: On Mon, 29 Jan 2001 08:57:09 JST, achurch@achurch.org (Andrew Church) wrote: > Services 4.5pre0 has been released, and can be downloaded from: > >ftp://ftp.esper.net/ircservices/ircservices-4.5pre0.tar.gz > * Support for the DALnet Bahamut server has been improved. Note that > only versions 1.4.1 and later are supported (support for earlier > versions has been dropped). Please note that if you are using Bahamut and ircservices-4.5 then the ChanServ UNBAN command may not work correctly, due to this bug in Bahamut: http://ircd-devel.dal.net/jitterbug/jitterbug.cgi/incoming?id=806;expression=del_banid;user=guest Bahamut's support for SVSMODE -b only works by chance on FreeBSD, and fails on Linux and probably other platforms. The result is that you see the ban being lifted but in reality it is still there. If you don't mind editing the code of your ircd then a quick fix is very simple, just read the above bug report. That also explains why Dalnet's own ChanServ UNBAN command has stopped working for users of twisted.* and tsunami.*. -- Andy Smith From andrewk at icon.co.za Thu Feb 1 00:22:09 2001 From: andrewk at icon.co.za (Andrew Kempe) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices-Coding] test Message-ID: <075e01c08c28$11d0c910$9c011ac4@africa.didata.local> From andrewk at icon.co.za Thu Feb 1 00:27:45 2001 From: andrewk at icon.co.za (Andrew Kempe) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices-Coding] New Mailing List Software Message-ID: <076601c08c28$da429130$9c011ac4@africa.didata.local> The ircservices-coding mailing list has been upgraded to mailman too. Please post to this list using ircservices-coding@ircservices.za.net from now on. You can get support for the mailing list from: http://www.ircservices.za.net/mailman/listinfo/ircservices-coding To unsubscribe mail ircservices-coding-request@ircservices.za.net with UNSUBSCRIBE in the subject of the email. Later, Andrew From ctackett at pirchplace.com Thu Mar 29 20:47:35 2001 From: ctackett at pirchplace.com (C. Tackett) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] ChanServ Question Message-ID: <5.0.2.1.0.20010329234619.00a43dd0@scican.net> Heya Folks! I have a question :-) How do you I get the ChanServ to join the channel when an IRCop asks to bring it in? I just want the IRCops to have that power no one else.. If this can be done I would love to know! Regards, Chris Tackett - ctackett@pirchplace.com The Pirch Place - http://www.PirchPlace.com The Internet's Leading Pirch Community -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20010329/feff835d/attachment.html From jpinto17 at visteon.com Thu Mar 29 22:58:03 2001 From: jpinto17 at visteon.com (Pinto, Joao luis (J.M.)) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] ChanServ Question Message-ID: <200103300658.f2U6wLX17595@dymwsm09.mailwatch.com> Just /OperServ raw :ChanServ JOIN #Chan anyway you should not play with raw command, unless you know what you are doing. Lamego@PTlink.net PTlink Tech Admin http://www.ptlink.net -----Original Message----- From: C. Tackett [mailto:ctackett@pirchplace.com] Sent: 30 March 2001 05:48 To: ircservices-coding@ircservices.za.net Subject: [IRCServices Coding] ChanServ Question Heya Folks! I have a question :-) How do you I get the ChanServ to join the channel when an IRCop asks to bring it in? I just want the IRCops to have that power no one else.. If this can be done I would love to know! Regards, Chris Tackett - ctackett@pirchplace.com The Pirch Place - http://www.PirchPlace.com The Internet's Leading Pirch Community From achurch at achurch.org Thu Dec 13 23:22:05 2001 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Version 5.0 alpha release available Message-ID: <3c18b9d4.67533@achurch.org> Well, it's taken a while, but Services 5.0 has finally begun to take a reasonable shape (other than "completely jumbled and in little teensy bits") and I've decided to release a public alpha test version. Before you all start jumping for joy, bear in mind that this is an ALPHA TEST VERSION--this means that it is known to have bugs, and quite a few of them, and is absolutely NOT for use on a production network. About the only thing that should work is compiling, and I won't even guarantee that. DO NOT DOWNLOAD THIS VERSION unless you intend to help find (and fix!) bugs, or translate the new language files. If I get any complaints about an alpha release being broken, causing problems on someone's network, or anything like that, I won't release any more alpha versions, and you'll just have to wait longer. Furthermore, all discussion on the 5.0 alpha release should go to this list, ircservices-coding. Discussion (except possibly feature requests, if I'm in a good mood) about the alpha release on this list will NOT be tolerated, and offenders may be forcibly removed from the list. If you still want to download the alpha version, visit the Services home page (http://www.ircservices.za.net/) for information. (I won't post a download link here because (1) it will change as versions go up, or if I take it down entirely, and (2) I want people to see the warnings I put up before downloading it.) Also, I'll be busy or out of town with year-end activities for most of the rest of the year, so I may not be able to respond quickly to mail; please be patient, as always. --Andrew Church achurch@achurch.org http://achurch.org/ From mark at mhetherington.demon.co.uk Thu Dec 13 14:42:45 2001 From: mark at mhetherington.demon.co.uk (Mark Hetherington) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Services 5 Message-ID: Firstly, thanks to Andrew for releasing the alpha version. Hopefully he will not feel that he has to later remove this opportunity. A few early questions that maybe Andrew or the Alpha team might be able to comment on. 1) Do we have any idea on time scale for development beyond alpha? I understand that it is a difficult question to answer given RL committments but based on work so far and this extended open test hopefully highlighting major issues quite quickly, might make it easier to provide an estimate. 2) Despite the warning not to run the alpha on a production network, it does seem to be the best place to run it since it will give a much more realistic test of the code. It is also very tempting to upgrade :) To this end, are there specific known issues at this time with the current build that would make it completely impractical to run on a small production network? The "knownbugs" file does not seem to have anything specific to Services 5 and nothing serious mentioned either way but those who have already had chance to play with Services 5 may have a good idea of things that would make it unsuitable for risking in a production environment. 3) At present we seem to be restricted to the mailing list for bug reporting and discussion which makes the process qyute closed. Has there been any thought given to providing some kind of online tracking system which would both show what bugs are currently known and their status? Maybe something on sourceforge or similar system would suffice. 4) I was wondering about the reasons for AJOIN being included in Services 5. It seems to place an overhead on NickServ that has been handled by many IRC clients for a number of years. Even clients which do not specifically support it, but that implement perform can easily provide AJOIN functionality. Any client supporting scripting could easily manage an AJOIN list. A number of clients support dynamic AJOIN lists by offering to remember hannels that a user uses on a regular basis. Since part of the ethos behind IRC Services development is not to perform tasks that really belong in IRCd or in clients or could be scripted, it seems odd that firstly this system has been implemented and secondly it is enabled in a default configuration. Is there something specific that I am missing about this services managed auto join list which makes it preferable to the existing client code which already performs this task? Anyway, back to play around with the source some more. Mark. From beng at nc.rr.com Thu Dec 13 15:04:37 2001 From: beng at nc.rr.com (Ben Goldstein) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Alpha compile error Message-ID: <005a01c1842a$8a36e1f0$0300a8c0@asi200> gcc -DCLEAN_COMPILE -O2 -Wall -Wmissing-prototypes -g -I../.. -c set.c -o set.o set.c: In function `do_set_timezone': set.c:487: wrong type argument to unary minus set.c:447: warning: `j' might be used uninitialized in this function 487: j = ngi->timezone*60 - (-timezone); I'm not sure what this is even doing, I havn't dug into the code. But it doesn't seem that "timezone" alone is the correct var you meant to use here. -- Ben Goldstein (beng@nc.rr.com) bash-2.05$ uname -a FreeBSD raider 4.4-20010827-RC2 FreeBSD 4.4-20010827-RC2 #4: Fri Nov 16 14:57:04 EST 2001 root@raider:/usr/obj/usr/src/sys/BG1 i386 bash-2.05$ gmake -ver GNU Make version 3.79, by Richard Stallman and Roland McGrath. Built for i386-unknown-freebsdelf4.4 Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Report bugs to . From griever at t2n.org Thu Dec 13 17:53:11 2001 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] REHASH help Message-ID: the restricted to services admins line has a tab char at the end. From zogg at pcisys.net Thu Dec 13 18:36:16 2001 From: zogg at pcisys.net (Ryan Riley) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] v5.0a7 - sline module Message-ID: <3C1965A0.3000409@pcisys.net> I just grabbed a copy of Alpha7 for a night of fun testing, but I've run into an issue. I did the standard install, modified the 2 example configs to fit my needs, and I get this on startup: [irc@zogg bin]$ ./services -nofork [Dec 13 21:30:09 2001] Services 5.0a7 starting up [Dec 13 21:30:09 2001] modules.conf:180: Unknown directive `LogMaxUsers' [Dec 13 21:30:09 2001] modules.conf:226: Unknown directive `WallGetpass' [Dec 13 21:30:09 2001] modules.conf:233: Unknown directive `WallSetpass' [Dec 13 21:30:09 2001] modules: Unable to load module `operserv/sline': /home/irc/devel/services/bin/lib/modules/operserv/sline.so: undefined symbol: protocol_features [Dec 13 21:30:09 2001] FATAL: Error loading modules, aborting That undefined symbol error doesn't pass by me as being a good thing, so I figured I'd mention it here. I've tried commenting out all of the operserv/sline references in modules.conf, but it attempts to load it anyway. (I haven't taken a dive into the source yet to figure out how the new module system works, so this could very well be normal.) I'm on a RedHat 7.1 machine if that makes a difference. Thanks Ryan Riley From grenday288 at geocities.com Thu Dec 13 20:36:09 2001 From: grenday288 at geocities.com (Josh) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Alpha compile error In-Reply-To: <005a01c1842a$8a36e1f0$0300a8c0@asi200> Message-ID: <3C192D59.13694.1989660C@localhost> On 13 Dec 2001, at 18:04, Ben Goldstein wrote: change like 487 in set.c to j = (ngi->timezone*60 - u->ngi->timezone); Im pretty sure thats not what its suppose to be but its only for timestamp stuff and still compiles (didnt try running it yet). > gcc -DCLEAN_COMPILE -O2 -Wall -Wmissing-prototypes -g -I../.. -c set.c -o > set.o > set.c: In function `do_set_timezone': > set.c:487: wrong type argument to unary minus > set.c:447: warning: `j' might be used uninitialized in this function > > 487: j = ngi->timezone*60 - (-timezone); > > I'm not sure what this is even doing, I havn't dug into the code. But it > doesn't seem that "timezone" alone is the correct var you meant to use here. > > -- Ben Goldstein (beng@nc.rr.com) > > bash-2.05$ uname -a > FreeBSD raider 4.4-20010827-RC2 FreeBSD 4.4-20010827-RC2 #4: Fri Nov 16 > 14:57:04 EST 2001 root@raider:/usr/obj/usr/src/sys/BG1 i386 > bash-2.05$ gmake -ver > GNU Make version 3.79, by Richard Stallman and Roland McGrath. > Built for i386-unknown-freebsdelf4.4 > Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99 > Free Software Foundation, Inc. > This is free software; see the source for copying conditions. > There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A > PARTICULAR PURPOSE. > > Report bugs to . > > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding ------------------------------------- -- Josh Kirkorian [aka Poison-X] -- Administrator - irc.insiderz.net C Code. C code run. Run, code, run... Segmentation fault (core dumped).. aww shit From andrewk at isdial.net Thu Dec 13 22:41:19 2001 From: andrewk at isdial.net (Andrew Kempe) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Services 5 References: Message-ID: <004901c1846a$56734800$9c011ac4@africa.didata.local> > 3) At present we seem to be restricted to the mailing list for bug reporting > and discussion which makes the process qyute closed. Has there been any > thought given to providing some kind of online tracking system which would > both show what bugs are currently known and their status? Maybe something on > sourceforge or similar system would suffice. I setup a very basic source forge project for services a while back, but have not been maintaining it. If Andrew is willing to use SF for bug tracking, I'm more than willing to start maintaining the project there. But it's up to Andrew, as he's the one who will be updating what has been changed/fixed. Andrew From rg at tcslon.com Fri Dec 14 01:07:59 2001 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Services 5 In-Reply-To: <004901c1846a$56734800$9c011ac4@africa.didata.local> Message-ID: Just first comments on this: For an alpha, it looks great, I would put it on my (small) production network would it be for a rather annoying bug: IRCServices 5 seems to have a few problems shutting down... on one of my servers, it dumped 16Mb of "Server Segfaulting" messages to the log before dying, and on the second attempt dumped a similar amount to SNotices (granted it gave my test network a good load test ;) On my other server, it sapped up all the CPU, and required a reboot. (I was stopping services both by /squitting and by SIGTERM). Other than that, I love it :) The mailing features look pretty swish, and although I haven't looked at the modules much, it looks good. Keep up the good work, Russ Garrett (russ@garrett.co.uk) From achurch at achurch.org Fri Dec 14 18:43:37 2001 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Services 5 Message-ID: <3c19ca25.04274@achurch.org> Looks like this didn't get through the first time, so: 1) No, because I have no clue how many bugs will turn up ;) At this point I'm tempted to say beta in February and stable release in April or so, but I have absolutely no basis for saying that, so don't quote me on it. 2) The notice is intended more for lamers who say "ooh it's version 5!" and rush to download it. Feel free to use it on your production network, as long as you take responsibility for any problems it causes. There aren't too many major issues right now that I can think of, but it's the ones I haven't found yet that worry me more. (One major issue I do know of is that rehashing modules.conf doesn't work yet and could easily break things.) 3) Not really, mostly because it would be a pain to set up and manage. I may set something up once 5.0 has gone stable, but until then it's just too much to deal with. And I want absolutely nothing to do with the piece-of-shit-formerly-known-as-Sourceforge. 4) For autojoin in particular, it was pointed out to me that not everyone always accesses IRC from the same computer, which would make client settings irrelevant. In general, though, with the module system, I'm a bit more lenient in terms of what I'll let in, since you can just disable modules you don't need. (And the reason for almost everything being enabled in the default config is so you'll all test them for me. ;) Some will probably be disabled in beta/final releases.) --Andrew Church achurch@achurch.org http://achurch.org/ >Firstly, thanks to Andrew for releasing the alpha version. Hopefully he will >not feel that he has to later remove this opportunity. > >A few early questions that maybe Andrew or the Alpha team might be able to >comment on. > >1) Do we have any idea on time scale for development beyond alpha? I >understand that it is a difficult question to answer given RL committments >but based on work so far and this extended open test hopefully highlighting >major issues quite quickly, might make it easier to provide an estimate. > >2) Despite the warning not to run the alpha on a production network, it does >seem to be the best place to run it since it will give a much more realistic >test of the code. It is also very tempting to upgrade :) To this end, are >there specific known issues at this time with the current build that would >make it completely impractical to run on a small production network? The >"knownbugs" file does not seem to have anything specific to Services 5 and >nothing serious mentioned either way but those who have already had chance >to play with Services 5 may have a good idea of things that would make it >unsuitable for risking in a production environment. > >3) At present we seem to be restricted to the mailing list for bug reporting >and discussion which makes the process qyute closed. Has there been any >thought given to providing some kind of online tracking system which would >both show what bugs are currently known and their status? Maybe something on >sourceforge or similar system would suffice. > >4) I was wondering about the reasons for AJOIN being included in Services 5. >It seems to place an overhead on NickServ that has been handled by many IRC >clients for a number of years. Even clients which do not specifically >support it, but that implement perform can easily provide AJOIN >functionality. Any client supporting scripting could easily manage an AJOIN >list. A number of clients support dynamic AJOIN lists by offering to >remember hannels that a user uses on a regular basis. > >Since part of the ethos behind IRC Services development is not to perform >tasks that really belong in IRCd or in clients or could be scripted, it >seems odd that firstly this system has been implemented and secondly it is >enabled in a default configuration. > >Is there something specific that I am missing about this services managed >auto join list which makes it preferable to the existing client code which >already performs this task? > > >Anyway, back to play around with the source some more. > >Mark. > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From jpinto17 at visteon.com Fri Dec 14 03:57:50 2001 From: jpinto17 at visteon.com (Pinto, Joao luis (J.M.)) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Services 5 Message-ID: <200112141157.fBEBvrn13721@dymwsm11.mailwatch.com> I hope other people don't know so much about ircservices as you know about sourceforge. You probably wouldn't like to see your project named as piece-of-shit-formerly-known-as-irc-services. >3) Not really, mostly because it would be a pain to set up and manage. >I may set something up once 5.0 has gone stable, but until then it's just >too much to deal with. And I want absolutely nothing to do with the >piece-of-shit-formerly-known-as-Sourceforge. Joao Pinto Lamego@PTlink.net -----Original Message----- From: achurch@achurch.org [mailto:achurch@achurch.org] Sent: 14 December 2001 09:44 To: ircservices-coding@ircservices.za.net Subject: Re: [IRCServices Coding] Services 5 Looks like this didn't get through the first time, so: 1) No, because I have no clue how many bugs will turn up ;) At this point I'm tempted to say beta in February and stable release in April or so, but I have absolutely no basis for saying that, so don't quote me on it. 2) The notice is intended more for lamers who say "ooh it's version 5!" and rush to download it. Feel free to use it on your production network, as long as you take responsibility for any problems it causes. There aren't too many major issues right now that I can think of, but it's the ones I haven't found yet that worry me more. (One major issue I do know of is that rehashing modules.conf doesn't work yet and could easily break things.) 3) Not really, mostly because it would be a pain to set up and manage. I may set something up once 5.0 has gone stable, but until then it's just too much to deal with. And I want absolutely nothing to do with the piece-of-shit-formerly-known-as-Sourceforge. 4) For autojoin in particular, it was pointed out to me that not everyone always accesses IRC from the same computer, which would make client settings irrelevant. In general, though, with the module system, I'm a bit more lenient in terms of what I'll let in, since you can just disable modules you don't need. (And the reason for almost everything being enabled in the default config is so you'll all test them for me. ;) Some will probably be disabled in beta/final releases.) --Andrew Church achurch@achurch.org http://achurch.org/ >Firstly, thanks to Andrew for releasing the alpha version. Hopefully he will >not feel that he has to later remove this opportunity. > >A few early questions that maybe Andrew or the Alpha team might be able to >comment on. > >1) Do we have any idea on time scale for development beyond alpha? I >understand that it is a difficult question to answer given RL committments >but based on work so far and this extended open test hopefully highlighting >major issues quite quickly, might make it easier to provide an estimate. > >2) Despite the warning not to run the alpha on a production network, it does >seem to be the best place to run it since it will give a much more realistic >test of the code. It is also very tempting to upgrade :) To this end, are >there specific known issues at this time with the current build that would >make it completely impractical to run on a small production network? The >"knownbugs" file does not seem to have anything specific to Services 5 and >nothing serious mentioned either way but those who have already had chance >to play with Services 5 may have a good idea of things that would make it >unsuitable for risking in a production environment. > >3) At present we seem to be restricted to the mailing list for bug reporting >and discussion which makes the process qyute closed. Has there been any >thought given to providing some kind of online tracking system which would >both show what bugs are currently known and their status? Maybe something on >sourceforge or similar system would suffice. > >4) I was wondering about the reasons for AJOIN being included in Services 5. >It seems to place an overhead on NickServ that has been handled by many IRC >clients for a number of years. Even clients which do not specifically >support it, but that implement perform can easily provide AJOIN >functionality. Any client supporting scripting could easily manage an AJOIN >list. A number of clients support dynamic AJOIN lists by offering to >remember hannels that a user uses on a regular basis. > >Since part of the ethos behind IRC Services development is not to perform >tasks that really belong in IRCd or in clients or could be scripted, it >seems odd that firstly this system has been implemented and secondly it is >enabled in a default configuration. > >Is there something specific that I am missing about this services managed >auto join list which makes it preferable to the existing client code which >already performs this task? > > >Anyway, back to play around with the source some more. > >Mark. > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding ------------------------------------------------------------------ To unsubscribe or change your subscription options, visit: http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From Georges at Berscheid.lu Fri Dec 14 05:06:05 2001 From: Georges at Berscheid.lu (Georges Berscheid) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Version 5 (feature request) Message-ID: <3C19F93D.D937F198@Berscheid.lu> Hi, 1. what about adding a command to dynamically load/unload modules without having to restart/rehash services (e.g. /operserv loadmod|unloadmod ) ? 2. would it be possible to add an include function for modules.conf so each module (evt. coming in a package) could have its own config file. 3. a dynamic way to include language files for modules would also be great, instead of having to insert your module-specific strings to a .l file and recompiling the whole stuff. Greetings Georges From achurch at achurch.org Sat Dec 15 00:02:16 2001 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Services 5 Message-ID: <3c1a14fb.04335@achurch.org> >I hope other people don't know so much about ircservices as you know about >sourceforge. You probably wouldn't like to see your project named as >piece-of-shit-formerly-known-as-irc-services. Everyone's entitled to their opinions, and I suspect someone with that opinion wouldn't be using it in the first place so I'd never have to deal with them anyway. --Andrew Church achurch@achurch.org http://achurch.org/ >>3) Not really, mostly because it would be a pain to set up and manage. >>I may set something up once 5.0 has gone stable, but until then it's just >>too much to deal with. And I want absolutely nothing to do with the >>piece-of-shit-formerly-known-as-Sourceforge. > >Joao Pinto >Lamego@PTlink.net > > >-----Original Message----- >From: achurch@achurch.org [mailto:achurch@achurch.org] >Sent: 14 December 2001 09:44 >To: ircservices-coding@ircservices.za.net >Subject: Re: [IRCServices Coding] Services 5 > > > Looks like this didn't get through the first time, so: > >1) No, because I have no clue how many bugs will turn up ;) At this point >I'm tempted to say beta in February and stable release in April or so, but >I have absolutely no basis for saying that, so don't quote me on it. > >2) The notice is intended more for lamers who say "ooh it's version 5!" and >rush to download it. Feel free to use it on your production network, as >long as you take responsibility for any problems it causes. There aren't >too many major issues right now that I can think of, but it's the ones I >haven't found yet that worry me more. (One major issue I do know of is >that rehashing modules.conf doesn't work yet and could easily break >things.) > >3) Not really, mostly because it would be a pain to set up and manage. >I may set something up once 5.0 has gone stable, but until then it's just >too much to deal with. And I want absolutely nothing to do with the >piece-of-shit-formerly-known-as-Sourceforge. > >4) For autojoin in particular, it was pointed out to me that not everyone >always accesses IRC from the same computer, which would make client >settings irrelevant. In general, though, with the module system, I'm a bit >more lenient in terms of what I'll let in, since you can just disable >modules you don't need. (And the reason for almost everything being >enabled in the default config is so you'll all test them for me. ;) Some >will probably be disabled in beta/final releases.) > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > >>Firstly, thanks to Andrew for releasing the alpha version. Hopefully he >will >>not feel that he has to later remove this opportunity. >> >>A few early questions that maybe Andrew or the Alpha team might be able to >>comment on. >> >>1) Do we have any idea on time scale for development beyond alpha? I >>understand that it is a difficult question to answer given RL committments >>but based on work so far and this extended open test hopefully highlighting >>major issues quite quickly, might make it easier to provide an estimate. >> >>2) Despite the warning not to run the alpha on a production network, it >does >>seem to be the best place to run it since it will give a much more >realistic >>test of the code. It is also very tempting to upgrade :) To this end, are >>there specific known issues at this time with the current build that would >>make it completely impractical to run on a small production network? The >>"knownbugs" file does not seem to have anything specific to Services 5 and >>nothing serious mentioned either way but those who have already had chance >>to play with Services 5 may have a good idea of things that would make it >>unsuitable for risking in a production environment. >> >>3) At present we seem to be restricted to the mailing list for bug >reporting >>and discussion which makes the process qyute closed. Has there been any >>thought given to providing some kind of online tracking system which would >>both show what bugs are currently known and their status? Maybe something >on >>sourceforge or similar system would suffice. >> >>4) I was wondering about the reasons for AJOIN being included in Services >5. >>It seems to place an overhead on NickServ that has been handled by many IRC >>clients for a number of years. Even clients which do not specifically >>support it, but that implement perform can easily provide AJOIN >>functionality. Any client supporting scripting could easily manage an AJOIN >>list. A number of clients support dynamic AJOIN lists by offering to >>remember hannels that a user uses on a regular basis. >> >>Since part of the ethos behind IRC Services development is not to perform >>tasks that really belong in IRCd or in clients or could be scripted, it >>seems odd that firstly this system has been implemented and secondly it is >>enabled in a default configuration. >> >>Is there something specific that I am missing about this services managed >>auto join list which makes it preferable to the existing client code which >>already performs this task? >> >> >>Anyway, back to play around with the source some more. >> >>Mark. >> >>------------------------------------------------------------------ >>To unsubscribe or change your subscription options, visit: >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Sat Dec 15 00:04:56 2001 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Version 5 (feature request) Message-ID: <3c1a15c3.04346@achurch.org> All of these are things I've been thinking about, but either haven't gotten around to implementing yet or have decided to hold off on for the next version. With regard to language files in particular, I haven't come up with a good implementation yet for per-module language strings, but I figure that at least initially, people who contribute modules will do so with one language only (their own) so it's not that big of a deal. --Andrew Church achurch@achurch.org http://achurch.org/ >Hi, > >1. what about adding a command to dynamically load/unload modules >without having to restart/rehash services (e.g. /operserv >loadmod|unloadmod ) ? >2. would it be possible to add an include function for modules.conf so >each module (evt. coming in a package) could have its own config file. >3. a dynamic way to include language files for modules would also be >great, instead of having to insert your module-specific strings to a .l >file and recompiling the whole stuff. > >Greetings > >Georges > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From mark at mhetherington.demon.co.uk Fri Dec 14 07:51:22 2001 From: mark at mhetherington.demon.co.uk (Mark Hetherington) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] v5.0a7 - sline module In-Reply-To: <3C1965A0.3000409@pcisys.net> Message-ID: Had similar problems myself. After some digging, it seems the reason for the 'unknown directives' is that they are stored in the table for the main configuration (services.conf parser init.c) rather than the module configuration (modules.conf parser operserv/main.c) so when parsing the operserv directives, the configuration parser has no access to their definitions. The configuration reoutine seems to ignore errors such as this so ultimately it should not stop services coming online, but I will result in those directives being ignored. Maybe the message should be altered to 'Ignored unknown directive %s' or 'Unknown directive %s ignored' It may be a rather trivial cut/paste to address the issue but I have not investigated this any further at this time. The sline problem you have experienced suggests you have not loaded a protocol for services. Check services.conf and add in an appropriate LoadModule protocol/protocolname. See the comments in that section for information. Mark. > -----Original Message----- > From: ircservices-coding-admin@ircservices.za.net > [mailto:ircservices-coding-admin@ircservices.za.net]On Behalf Of Ryan > Riley > Sent: 14 December 2001 02:36 > To: IRCServices-Coding@ircservices.za.net > Subject: [IRCServices Coding] v5.0a7 - sline module > > > I just grabbed a copy of Alpha7 for a night of fun testing, but I've run > into an issue. I did the standard install, modified the 2 example > configs to fit my needs, and I get this on startup: > [irc@zogg bin]$ ./services -nofork > [Dec 13 21:30:09 2001] Services 5.0a7 starting up > [Dec 13 21:30:09 2001] modules.conf:180: Unknown directive `LogMaxUsers' > [Dec 13 21:30:09 2001] modules.conf:226: Unknown directive `WallGetpass' > [Dec 13 21:30:09 2001] modules.conf:233: Unknown directive `WallSetpass' > [Dec 13 21:30:09 2001] modules: Unable to load module `operserv/sline': > /home/irc/devel/services/bin/lib/modules/operserv/sline.so: undefined > symbol: protocol_features > [Dec 13 21:30:09 2001] FATAL: Error loading modules, aborting > > That undefined symbol error doesn't pass by me as being a good thing, so > I figured I'd mention it here. > I've tried commenting out all of the operserv/sline references in > modules.conf, but it attempts to load it anyway. (I haven't taken a > dive into the source yet to figure out how the new module system works, > so this could very well be normal.) > I'm on a RedHat 7.1 machine if that makes a difference. > > Thanks > Ryan Riley > > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From griever at t2n.org Fri Dec 14 11:55:40 2001 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Services 5 In-Reply-To: Message-ID: On Fri, 14 Dec 2001, Russell Garrett wrote: > Just first comments on this: > > For an alpha, it looks great, I would put it on my (small) production > network would it be for a rather annoying bug: > > IRCServices 5 seems to have a few problems shutting down... on one of > my servers, it dumped 16Mb of "Server Segfaulting" messages to the > log before dying, and on the second attempt dumped a similar amount > to SNotices (granted it gave my test network a good load test ;) On > my other server, it sapped up all the CPU, and required a reboot. (I > was stopping services both by /squitting and by SIGTERM). -dumpcore (may be to dashes) to ./configure > > Other than that, I love it :) The mailing features look pretty swish, > and although I haven't looked at the modules much, it looks good. > > Keep up the good work, > > > Russ Garrett (russ@garrett.co.uk) > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From zogg at pcisys.net Fri Dec 14 12:21:59 2001 From: zogg at pcisys.net (Ryan Riley) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Services 5 References: Message-ID: <3C1A5F67.6080806@pcisys.net> Here's a backtrace from that particuliar problem. (gdb) bt #0 0x4015ccbc in ?? () #1 0x080535fb in unload_module (module=0x812a0c8) at modules.c:406 #2 0x08053135 in modules_exit () at modules.c:109 #3 0x08051b90 in main (ac=1, av=0xbffffadc, envp=0xbffffae4) at main.c:406 #4 0x4003ce5e in __libc_start_main (main=0x805177c
, argc=1, ubp_av=0xbffffadc, init=0x804b9a4 <_init>, fini=0x8057bc0 <_fini>, rtld_fini=0x4000d3c4 <_dl_fini>, stack_end=0xbffffacc) at ../sysdeps/generic/libc-start.c:129 Thanks Ryan Finny Merrill wrote: >On Fri, 14 Dec 2001, Russell Garrett wrote: > >>Just first comments on this: >> >>For an alpha, it looks great, I would put it on my (small) production >>network would it be for a rather annoying bug: >> >>IRCServices 5 seems to have a few problems shutting down... on one of >>my servers, it dumped 16Mb of "Server Segfaulting" messages to the >>log before dying, and on the second attempt dumped a similar amount >>to SNotices (granted it gave my test network a good load test ;) On >>my other server, it sapped up all the CPU, and required a reboot. (I >>was stopping services both by /squitting and by SIGTERM). >> >-dumpcore (may be to dashes) to ./configure > >>Other than that, I love it :) The mailing features look pretty swish, >>and although I haven't looked at the modules much, it looks good. >> >>Keep up the good work, >> >> >>Russ Garrett (russ@garrett.co.uk) >> >>------------------------------------------------------------------ >>To unsubscribe or change your subscription options, visit: >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding >> > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > > From v13 at priest.com Fri Dec 14 12:12:44 2001 From: v13 at priest.com (v13@priest.com) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] coding... (svcs 5) Message-ID: <200112142012.WAA03993@ppp0.the.forthnet.gr> For services 5: I believe code like this (from operserv/main.c: do_killclones() ) if (match_usermask(clonemask, user) != 0) { char killreason[32]; count++; snprintf(killreason, sizeof(killreason), "Cloning [%d]", count); kill_user(NULL, user->nick, killreason); } should exist in seperate functions like: int kill_mask(const char *mask, const char *reason) { int count=0; User *user; for (user = first_user(); user; user = next_user()) { if (match_usermask(mask, user) != 0) { char killreason[512]; count++; snprintf(killreason, sizeof(killreason), (reason == NULL ? "Cloning [%d]" : reason), count); kill_user(NULL, user->nick, killreason); } } return(count); } 3rd party modules should not use their own code for things like this, since it exists allready. <> From beng at nc.rr.com Fri Dec 14 14:37:40 2001 From: beng at nc.rr.com (Ben Goldstein) Date: Sat Oct 23 23:09:11 2004 Subject: Fw: [IRCServices Coding] Alpha compile error Message-ID: <008501c184ef$f0e600a0$0300a8c0@asi200> I don't know if Andrew meant to send this here, but it might be helpful for others. When I compiled I omitted the line completely to supress the error. -- Ben Goldstein (beng@nc.rr.com) ----- Original Message ----- From: "Andrew Church" To: Sent: Thursday, December 13, 2001 9:04 PM Subject: Re: [IRCServices Coding] Alpha compile error > >gcc -DCLEAN_COMPILE -O2 -Wall -Wmissing-prototypes -g -I../.. -c set.c -o > >set.o > >set.c: In function `do_set_timezone': > >set.c:487: wrong type argument to unary minus > >set.c:447: warning: `j' might be used uninitialized in this function > > > >487: j = ngi->timezone*60 - (-timezone); > > > >I'm not sure what this is even doing, I havn't dug into the code. But it > >doesn't seem that "timezone" alone is the correct var you meant to use here. > > Actually, it is, but it looks like it's not portable; I'll make a > workaround for the next release. In the meantime, either use Linux or just > remove the "- (-timezone)" (it's code for a case that should never happen > anyway, so it shouldn't matter too much). > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > > >-- Ben Goldstein (beng@nc.rr.com) From achurch at achurch.org Sat Dec 15 10:45:50 2001 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] coding... (svcs 5) Message-ID: <3c1aab53.04477@achurch.org> Not worth it. >For services 5: > >I believe code like this (from operserv/main.c: do_killclones() ) > > if (match_usermask(clonemask, user) != 0) { > char killreason[32]; > count++; > snprintf(killreason, sizeof(killreason), > "Cloning [%d]", count); > kill_user(NULL, user->nick, killreason); > } > >should exist in seperate functions like: > >int kill_mask(const char *mask, const char *reason) >{ > int count=0; > User *user; > > for (user = first_user(); user; user = next_user()) > { > if (match_usermask(mask, user) != 0) > { > char killreason[512]; > > count++; > snprintf(killreason, sizeof(killreason), > (reason == NULL ? "Cloning [%d]" : reason), > count); > kill_user(NULL, user->nick, killreason); > } > } > > return(count); >} > >3rd party modules should not use their own code for things like this, sin >ce >it exists allready. > ><> >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding --Andrew Church achurch@achurch.org http://achurch.org/ From stsimb at irc.gr Sat Dec 15 11:23:02 2001 From: stsimb at irc.gr (Sotiris Tsimbonis) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] coding... (svcs 5) In-Reply-To: <3c1aab53.04477@achurch.org> Message-ID: On Sat, 15 Dec 2001, Andrew Church wrote: > >For services 5: > >I believe code like this (from operserv/main.c: do_killclones() ) [...] > >should exist in seperate functions like: > >int kill_mask(const char *mask, const char *reason) [...] > >} > > Not worth it. Why not? Wouldn't this help code re-use in 3rd party modules? One wouldn't have to re-invent the wheel, and if there was an error, it would only have to be fixed in one place.. Sotiris. From v13 at priest.com Sat Dec 15 11:45:47 2001 From: v13 at priest.com (v13@priest.com) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] srvcs 5 Message-ID: <200112151945.VAA04508@ppp0.the.forthnet.gr> A note about callbacks: Callbacks are nice when someone wants to add another function to services, but are no good, when someone wants to extend an existing one. I was trying to make nickserv to send one more line for the INFO command. It is possible to return the line at the begining but not at the end. I bypassed the strtok() problem, by duplicating the buffer to something like: "A INFO nick" and then calling strtok once, for this one. This way successive calls to strtok whould return the "INFO nick" part. But it is not possible to call my function *AFTER* do_info. I tried to register my function with a higher priority and then call do_info from my function, but it was no good. get_module_symbol() cannot find do_info() (neither nickserv() ). I believe this is because of the static decleration of the functions. Using "nm -g" it seems that those functions are not exported from the nickserv module. Is this going to change, or we should prepare for patching the main services code ? <> From griever at t2n.org Sat Dec 15 12:12:48 2001 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] srvcs 5 In-Reply-To: <200112151945.VAA04508@ppp0.the.forthnet.gr> Message-ID: On Sat, 15 Dec 2001 v13@priest.com wrote: > A note about callbacks: > > Callbacks are nice when someone wants to add another function to services, > but are no good, when someone wants to extend an existing one. > > I was trying to make nickserv to send one more line for the INFO command. *snip* Command* lookup_cmd(Module* id, char* name) will return the current Command* stucture for command name which can then be removed and replaced, and you can call the function. > > Using "nm -g" it seems that those functions are not exported from the > nickserv module. > > Is this going to change, or we should prepare for patching the main services > code ? No need > <> > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From v13 at priest.com Sat Dec 15 12:34:44 2001 From: v13 at priest.com (v13@priest.com) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] srvcs 5 In-Reply-To: References: Message-ID: <200112152034.WAA04723@ppp0.the.forthnet.gr> On Saturday 15 December 2001 22:12, Finny Merrill wrote: > Command* lookup_cmd(Module* id, char* name) > will return the current Command* stucture for command name > which can then be removed and replaced, and you can call the function. Thanx. I got do_info() from (*(lookup_cmd(module_nickserv, "INFO")))->routine and put my function there, which calls the old one before sending anything to the user and it worked. <> From griever at t2n.org Sat Dec 15 12:39:16 2001 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] srvcs 5 In-Reply-To: <200112152034.WAA04723@ppp0.the.forthnet.gr> Message-ID: On Sat, 15 Dec 2001 v13@priest.com wrote: > On Saturday 15 December 2001 22:12, Finny Merrill wrote: > > Command* lookup_cmd(Module* id, char* name) > > will return the current Command* stucture for command name > > which can then be removed and replaced, and you can call the function. > > Thanx. I got do_info() from > > (*(lookup_cmd(module_nickserv, "INFO")))->routine personally I think this would be a safer way: Command *temp; temp = lookup_cmd(module_nickserv, "INFO); temp->routine(...); > > and put my function there, which calls the old one before sending > anything to the user and it worked. > > <> > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From v13 at priest.com Sun Dec 16 12:50:03 2001 From: v13 at priest.com (v13@priest.com) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] svcs 5 Message-ID: <200112162050.WAA04418@ppp0.the.forthnet.gr> The definition of "receive message" callback is wrong in the documentation It says: Parameters: char *source, int ac, char **av It should be: Parameters: char *source, char *cmd, int ac, char **av in the protocol sources, the functions for this callback are declared as: static int do_receive_message(char *source, char *cmd, int ac, char **av) <> From v13 at priest.com Sun Dec 16 14:20:32 2001 From: v13 at priest.com (v13@priest.com) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] svcs5 Message-ID: <200112162220.AAA04668@ppp0.the.forthnet.gr> in messages.c: static void m_time(char *source, int ac, char **av) { time_t t; struct tm *tm; char buf[64]; time(&t); tm = localtime(&t); strftime(buf, sizeof(buf), "%a %b %d %H:%M:%S %Y %Z", tm); send_cmd(NULL, "391 :%s", buf); } This should be: send_cmd(NULL, "391 %s %s :%s", source, ServerName, buf); or something like that... <> From achurch at achurch.org Mon Dec 17 07:17:25 2001 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] coding... (svcs 5) Message-ID: <3c1d2138.07054@achurch.org> >On Sat, 15 Dec 2001, Andrew Church wrote: >> >For services 5: >> >I believe code like this (from operserv/main.c: do_killclones() ) >[...] >> >should exist in seperate functions like: >> >int kill_mask(const char *mask, const char *reason) >[...] >> >} >> >> Not worth it. > >Why not? Wouldn't this help code re-use in 3rd party modules? One wouldn't >have to re-invent the wheel, and if there was an error, it would only have >to be fixed in one place.. If it was actually being used in multiple places, I'd agree with you, but (unless I'm forgetting somewhere) it's not, and splitting the code up anyway would be a waste of time. If this actually becomes an issue later I'll reconsider it then. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Mon Dec 17 07:33:50 2001 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Services 5 Message-ID: <3c1d216e.07065@achurch.org> >Here's a backtrace from that particuliar problem. > >(gdb) bt >#0 0x4015ccbc in ?? () >#1 0x080535fb in unload_module (module=0x812a0c8) at modules.c:406 >#2 0x08053135 in modules_exit () at modules.c:109 >#3 0x08051b90 in main (ac=1, av=0xbffffadc, envp=0xbffffae4) at main.c:406 >#4 0x4003ce5e in __libc_start_main (main=0x805177c
, argc=1, > ubp_av=0xbffffadc, init=0x804b9a4 <_init>, fini=0x8057bc0 <_fini>, > rtld_fini=0x4000d3c4 <_dl_fini>, stack_end=0xbffffacc) > at ../sysdeps/generic/libc-start.c:129 Looks like some module is forgetting to remove its callbacks. Can you play around with commenting/uncommenting your LoadModule directives in services.conf until you find the module that causes the problem? >Thanks >Ryan > >Finny Merrill wrote: > >>On Fri, 14 Dec 2001, Russell Garrett wrote: >> >>>Just first comments on this: >>> >>>For an alpha, it looks great, I would put it on my (small) production >>>network would it be for a rather annoying bug: >>> >>>IRCServices 5 seems to have a few problems shutting down... on one of >>>my servers, it dumped 16Mb of "Server Segfaulting" messages to the >>>log before dying, and on the second attempt dumped a similar amount >>>to SNotices (granted it gave my test network a good load test ;) On >>>my other server, it sapped up all the CPU, and required a reboot. (I >>>was stopping services both by /squitting and by SIGTERM). >>> >>-dumpcore (may be to dashes) to ./configure >> >>>Other than that, I love it :) The mailing features look pretty swish, >>>and although I haven't looked at the modules much, it looks good. >>> >>>Keep up the good work, >>> >>> >>>Russ Garrett (russ@garrett.co.uk) >>> >>>------------------------------------------------------------------ >>>To unsubscribe or change your subscription options, visit: >>>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding >>> >> >>------------------------------------------------------------------ >>To unsubscribe or change your subscription options, visit: >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding >> >> > > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Mon Dec 17 07:34:29 2001 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] srvcs 5 Message-ID: <3c1d21e1.07076@achurch.org> > A note about callbacks: > >Callbacks are nice when someone wants to add another function to services, >but are no good, when someone wants to extend an existing one. Don't use callbacks for this, use the command system (commands.[ch]). The next alpha will have a `next' pointer in the command record which gets filled in when you call register_commands(), so you can call the original command's function directly. >I was trying to make nickserv to send one more line for the INFO command. >It is possible to return the line at the begining but not at the end. >I bypassed the strtok() problem, by duplicating the buffer to something l >ike: >"A INFO nick" and then calling strtok once, for this one. >This way successive calls to strtok whould return the "INFO nick" part. >But it is not possible to call my function *AFTER* do_info. I tried to >register my function with a higher priority and then call do_info from my > >function, but it was no good. get_module_symbol() cannot find do_info() >(neither nickserv() ). I believe this is because of the static decleratio >n of >the functions. > >Using "nm -g" it seems that those functions are not exported from the >nickserv module. > >Is this going to change, or we should prepare for patching the main servi >ces >code ? > ><> >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding --Andrew Church achurch@achurch.org http://achurch.org/ From v13 at priest.com Sun Dec 16 14:49:58 2001 From: v13 at priest.com (v13@priest.com) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Services 5 In-Reply-To: <3c1d216e.07065@achurch.org> References: <3c1d216e.07065@achurch.org> Message-ID: <200112162249.AAA05350@ppp0.the.forthnet.gr> On Monday 17 December 2001 09:33, Andrew Church wrote: > >Here's a backtrace from that particuliar problem. > > > >(gdb) bt > >#0 0x4015ccbc in ?? () > >#1 0x080535fb in unload_module (module=0x812a0c8) at modules.c:406 > >#2 0x08053135 in modules_exit () at modules.c:109 > >#3 0x08051b90 in main (ac=1, av=0xbffffadc, envp=0xbffffae4) at main.c:406 > >#4 0x4003ce5e in __libc_start_main (main=0x805177c
, argc=1, > > ubp_av=0xbffffadc, init=0x804b9a4 <_init>, fini=0x8057bc0 <_fini>, > > rtld_fini=0x4000d3c4 <_dl_fini>, stack_end=0xbffffacc) > > at ../sysdeps/generic/libc-start.c:129 > > Looks like some module is forgetting to remove its callbacks. Can you > play around with commenting/uncommenting your LoadModule directives in > services.conf until you find the module that causes the problem? Trying an: (gdb) up (gdb) p module->name whould show the module name <> From achurch at achurch.org Mon Dec 17 07:55:16 2001 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] svcs 5 Message-ID: <3c1d265c.07147@achurch.org> >The definition of "receive message" callback is wrong in the documentatio >n >It says: > >Parameters: char *source, int ac, char **av > >It should be: >Parameters: char *source, char *cmd, int ac, char **av Thanks, fixed. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Mon Dec 17 07:57:24 2001 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Services 5 Message-ID: <3c1d2730.07170@achurch.org> >On Monday 17 December 2001 09:33, Andrew Church wrote: >> >Here's a backtrace from that particuliar problem. >> > >> >(gdb) bt >> >#0 0x4015ccbc in ?? () >> >#1 0x080535fb in unload_module (module=0x812a0c8) at modules.c:406 >> >#2 0x08053135 in modules_exit () at modules.c:109 >> >#3 0x08051b90 in main (ac=1, av=0xbffffadc, envp=0xbffffae4) at > main.c:406 >> >#4 0x4003ce5e in __libc_start_main (main=0x805177c
, argc=1 >, >> > ubp_av=0xbffffadc, init=0x804b9a4 <_init>, fini=0x8057bc0 <_ >fini>, >> > rtld_fini=0x4000d3c4 <_dl_fini>, stack_end=0xbffffacc) >> > at ../sysdeps/generic/libc-start.c:129 >> >> Looks like some module is forgetting to remove its callbacks. Can > you >> play around with commenting/uncommenting your LoadModule directives in >> services.conf until you find the module that causes the problem? > >Trying an: > >(gdb) up >(gdb) p module->name > >whould show the module name No, that would show the name of the module being unloaded, not the one whose callback was being called. --Andrew Church achurch@achurch.org http://achurch.org/ From v13 at priest.com Sun Dec 16 17:09:35 2001 From: v13 at priest.com (v13@priest.com) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] svcs5 Message-ID: <200112170109.DAA07729@ppp0.the.forthnet.gr> I don't understand this completely, but i get coredumps when doing /msg chanserv levels #chan set ignore 6 it seems that there is something wrong... in chanserv/util.c: ChannelInfo *makechan(const char *chan) { ChannelInfo *ci; ci = scalloc(sizeof(ChannelInfo), 1); strscpy(ci->name, chan, CHANMAX); ci->time_registered = time(NULL); >>>>> reset_levels(ci, 0); <<<<<< return add_channelinfo(ci); } i bellieve this should be: reset_levels(ci,1); also in chanserv/access.c: EXPORT_FUNC(reset_levels) void reset_levels(ChannelInfo *ci, int set) { int i; >>>>> free(ci->levels); <<<<< if (set) { ci->levels = scalloc(CA_SIZE, sizeof(*ci->levels)); for (i = 0; i < CA_SIZE; i++) ci->levels[i] = def_levels[i]; } else { ci->levels = NULL; } } this may try to free something that is not malloced (if i get this right) when it is called from makechan() (free(NULL) works under glibc, but i don't know how portable/standard it is) finaly in chanserv/access-levels.c, in do_levels(): for (i = 0; levelinfo[i].what >= 0; i++) { if (stricmp(levelinfo[i].name, what) == 0) { if (ci->levels) reset_levels(ci, 1); >>>>> ci->levels[levelinfo[i].what] = level; <<<<<< notice_lang(s_ChanServ, u, CHAN_LEVELS_CHANGED, levelinfo[i].name, chan, level); put_channelinfo(ci); return; } } the marked line is where i get the coredump... it doesn't make any sense.. if ci->levels is NULL, then reset_levels is not called... so it remains NULL and then ci->levels[] is used (from gdb) (not wrapped) (gdb) bt #0 do_levels (u=0x814cf0c) at access-levels.c:324 #1 0x0804df4c in run_cmd (service=0x8144bd4 "ChanServ", u=0x814cf0c, id=0x81449c4, cmd=0xbffff5f2 "levels") at commands.c:158 #2 0x401a0070 in chanserv (source=0xbffff820 "V13", target=0xbffff5e8 "chanserv", buf=0xbffff5f2 "levels") at main.c:226 #3 0x08054cba in call_callback_5 (module=0x0, id=25, arg1=0xbffff820, arg2=0xbffff5e8, arg3=0xbffff5f2, arg4=0x0, arg5=0x0) at modules.c:605 #4 0x08052f3f in m_privmsg (source=0xbffff820 "V13", ac=2, av=0x814cd8c) at messages.c:169 #5 0x08055260 in process () at process.c:131 #6 0x08056395 in check_sockets () at sockets.c:362 #7 0x080526cc in main (ac=3, av=0xbffffa54, envp=0xbffffa64) at main.c:377 #8 0x4004d823 in __libc_start_main () from /lib/libc.so.6 (gdb) l access-levels.c:324 319 } 320 for (i = 0; levelinfo[i].what >= 0; i++) { 321 if (stricmp(levelinfo[i].name, what) == 0) { 322 if (ci->levels) 323 reset_levels(ci, 1); 324 ci->levels[levelinfo[i].what] = level; 325 notice_lang(s_ChanServ, u, CHAN_LEVELS_CHANGED, 326 levelinfo[i].name, chan, level); 327 put_channelinfo(ci); 328 return; (gdb) p i $1 = 224 <> From achurch at achurch.org Mon Dec 17 16:47:05 2001 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] svcs5 Message-ID: <3c1da32d.07437@achurch.org> >in messages.c: > >static void m_time(char *source, int ac, char **av) >{ > time_t t; > struct tm *tm; > char buf[64]; > > time(&t); > tm = localtime(&t); > strftime(buf, sizeof(buf), "%a %b %d %H:%M:%S %Y %Z", tm); > send_cmd(NULL, "391 :%s", buf); >} > >This should be: > >send_cmd(NULL, "391 %s %s :%s", source, ServerName, buf); > >or something like that... I could have sworn I fixed this at least once before... oh well. Fixed (in the 4.5 branch as well), thanks. ><> >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding --Andrew Church achurch@achurch.org http://achurch.org/ From Georges at Berscheid.lu Mon Dec 17 00:43:35 2001 From: Georges at Berscheid.lu (Georges Berscheid) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Services 5 having problems to shut down Message-ID: Hi, when I started services with a little error in my config file this happened: [Dec 16 22:38:27 2001] Read error from server: Success [Dec 16 22:38:27 2001] Services terminating: Segmentation fault [Dec 16 22:38:27 2001] Services terminating: Segmentation fault [Dec 16 22:38:27 2001] Services terminating: Segmentation fault First, I didn't see that something was wrong, but suddenly many other processes on the server crashed due to 'Out of memory'. That's what services said 10 minutes later in the .log file as well. (At this point the .log file had 290MB) [Dec 16 22:48:15 2001] Out of memory! [Dec 16 22:48:15 2001] Out of memory! [Dec 16 22:48:15 2001] Out of memory! [Dec 16 22:48:15 2001] Out of memory! Seems like the get into an endless malloc-loop somewhere. Unfortunately there is no core dump, because they were still alive after 10 minutes, and I had to kill them through the console. Georges From rg at tcslon.com Mon Dec 17 01:18:02 2001 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Services 5 having problems to shut down In-Reply-To: Message-ID: > when I started services with a little error in my config > file this happened: > > [Dec 16 22:38:27 2001] Read error from server: Success > [Dec 16 22:38:27 2001] Services terminating: Segmentation fault > [Dec 16 22:38:27 2001] Services terminating: Segmentation fault > [Dec 16 22:38:27 2001] Services terminating: Segmentation fault I saw this too, I think, but I caught it before it ran out of memory... I'm still trying to find a computer to debug it on - I was previously using a colocated server which I had no physical access to - a bad move :) Russ Garrett (russ@garrett.co.uk) From achurch at achurch.org Mon Dec 17 18:28:16 2001 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Services 5 having problems to shut down Message-ID: <3c1dbaf6.12326@achurch.org> The endless loop is fixed, thanks. I'll look into the seg-fault later (I suspect it's the same problem as was reported earlier). --Andrew Church achurch@achurch.org http://achurch.org/ >Hi, > >when I started services with a little error in my config file this happened: > >[Dec 16 22:38:27 2001] Read error from server: Success >[Dec 16 22:38:27 2001] Services terminating: Segmentation fault >[Dec 16 22:38:27 2001] Services terminating: Segmentation fault >[Dec 16 22:38:27 2001] Services terminating: Segmentation fault > >First, I didn't see that something was wrong, but suddenly many other >processes on the server crashed due to 'Out of memory'. That's what services >said 10 minutes later in the .log file as well. (At this point the .log file >had 290MB) > >[Dec 16 22:48:15 2001] Out of memory! >[Dec 16 22:48:15 2001] Out of memory! >[Dec 16 22:48:15 2001] Out of memory! >[Dec 16 22:48:15 2001] Out of memory! > >Seems like the get into an endless malloc-loop somewhere. Unfortunately >there is no core dump, because they were still alive after 10 minutes, and I >had to kill them through the console. > >Georges > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From v13 at priest.com Mon Dec 17 05:47:22 2001 From: v13 at priest.com (v13@priest.com) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] akills Message-ID: <200112171348.PAA02940@ppp0.the.forthnet.gr> As of bahamut 1.4.29, s_serv.c -> m_akill() (in bahamut ircd sources) has: /* whether or not we have a length, this is still a temporary akill */ /* if the length is over a day, or nonexistant, we call this a 'forever' * akill and set ->hold to 0xFFFFFFFF to indicate such * this is a hack to prevent * forever akills from being removed unless by an explicit /rehash */ if(length>86400 || !length) aconf->hold=0xFFFFFFFF; else aconf->hold=timeset+length; which means that akills whith expire time greater than a day, will never expire, unless explicity removed. This way, netsplits may prevent akills to be removed from servers, when services send the RAKILL. This can be bypassed, by forcing services to send AKILLs, with expire time less than 86400 by changing (in operserv/akill.c send_akill() ): call_callback_5(module, cb_send_akill, username, host, akill->expires, akill->who, make_reason(AkillReason, akill)); to: call_callback_5(module, cb_send_akill, username, host, ( (akill->expires - now) > 86399 ? now + 86399 : akill->expires), akill->who, make_reason(AkillReason, akill)); or better, change the callback in the bahamut protocol module: static int do_send_akill(const char *username, const char *host, time_t expires, const char *who, const char *reason) { time_t now = time(NULL); send_cmd(ServerName, "AKILL %s %s %ld %s %ld :%s", host, username, (expires && expires > now) ? expires - now : 0, who ? who : "", now, reason); return 1; } to: static int do_send_akill(const char *username, const char *host, time_t expires, const char *who, const char *reason) { time_t now = time(NULL); if (expires>now) { expires-=now; if (expires>=86400) expires=86399; } send_cmd(ServerName, "AKILL %s %s %ld %s %ld :%s", host, username, expires, who ? who : "", now, reason); return 1; } This way akills for 5 days, will be send up to 5 times on each server (Removed after 86399 seconds and send again when a matching user tries ti use the server). This should not add much overhead and non-expiring akills will not be affected. <> From achurch at achurch.org Mon Dec 17 23:29:46 2001 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] akills Message-ID: <3c1e020e.15231@achurch.org> > if (expires>now) > { > expires-=now; > if (expires>=86400) > expires=86399; > } I see someone hasn't read the coding guidelines... >This way akills for 5 days, will be send up to 5 times on each server >(Removed after 86399 seconds and send again when a matching user tries ti > use >the server). This should not add much overhead and non-expiring akills wi >ll >not be affected. I don't see why this is needed. The autokills-don't-disappear-if- server-is-split problem existed before the AKILL message got an expiry time, and it was always solved by rehashing; I don't see why the same approach can't be used with Bahamut as well. IMNSHO, I think the current (if that's current) behavior of Bahamut is buggy; since when does "one day or more" equal "forever"? --Andrew Church achurch@achurch.org http://achurch.org/ From dooley at risanet.com Mon Dec 17 11:01:26 2001 From: dooley at risanet.com (Dooley) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Services 5 having problems to shut down References: <3c1dbaf6.12326@achurch.org> Message-ID: <006501c1872d$40e593b0$dd91a8c0@criley> Anyone know what the fix is for this as it would be nice to not have to console kill it while playing. Dooley ----- Original Message ----- From: "Andrew Church" To: Sent: Monday, December 17, 2001 3:28 AM Subject: Re: [IRCServices Coding] Services 5 having problems to shut down > The endless loop is fixed, thanks. I'll look into the seg-fault later > (I suspect it's the same problem as was reported earlier). > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > > >Hi, > > > >when I started services with a little error in my config file this happened: > > > >[Dec 16 22:38:27 2001] Read error from server: Success > >[Dec 16 22:38:27 2001] Services terminating: Segmentation fault > >[Dec 16 22:38:27 2001] Services terminating: Segmentation fault > >[Dec 16 22:38:27 2001] Services terminating: Segmentation fault > > > >First, I didn't see that something was wrong, but suddenly many other > >processes on the server crashed due to 'Out of memory'. That's what services > >said 10 minutes later in the .log file as well. (At this point the .log file > >had 290MB) > > > >[Dec 16 22:48:15 2001] Out of memory! > >[Dec 16 22:48:15 2001] Out of memory! > >[Dec 16 22:48:15 2001] Out of memory! > >[Dec 16 22:48:15 2001] Out of memory! > > > >Seems like the get into an endless malloc-loop somewhere. Unfortunately > >there is no core dump, because they were still alive after 10 minutes, and I > >had to kill them through the console. > > > >Georges > > > >------------------------------------------------------------------ > >To unsubscribe or change your subscription options, visit: > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From achurch at achurch.org Thu Dec 20 14:21:43 2001 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Services 5.0 alpha 8 released Message-ID: <3c2175d6.46663@achurch.org> I've put up a new alpha tarball, alpha 8; it can be downloaded from the same place as the last one (http://achurch.org/services/5.0-alpha/). The crashing and infinite loop bugs reported before should be fixed, and rehashing has now been added. The change log is as follows: 2001/12/20 a8 SIGHUP now re-reads the configuration files instead of restarting. 2001/12/20 SIGUSR2 no longer opens log file if it was closed before. 2001/12/20 Added reconfiguration support for modules. 2001/12/20 Renamed AkillReason config directive to AutokillReason. 2001/12/19 Fixed crash when unloading modules on exit. 2001/12/17 Fixed infinite loop on signal. Reported by Georges Berscheid 2001/12/14 Fixed various problems caused by signal timing. 2001/12/14 Fixed compile error on FreeBSD. Reported by Ben Goldstein --Andrew Church achurch@achurch.org http://achurch.org/ From Georges at Berscheid.lu Thu Dec 20 03:10:23 2001 From: Georges at Berscheid.lu (Georges Berscheid) Date: Sat Oct 23 23:09:11 2004 Subject: AW: [IRCServices Coding] Services 5.0 alpha 8 released In-Reply-To: <3c2175d6.46663@achurch.org> Message-ID: Hi, I just installed alpha8 and tried the new /operserv rehash function. But unfortunately it segfaults every time. gdb says: #0 chunk_free (ar_ptr=0x464c457f, p=0x4007b9f8) at malloc.c:3049 #1 0x40076fba in __libc_free (mem=0x4007ba00) at malloc.c:3023 #2 0x804e84c in read_config_file (modulename=0x812e888 "statserv/main", directives=0x4018444c) at conffile.c:380 #3 0x804ecbc in configure (modulename=0x812e888 "statserv/main", directives=0x4018444c, action=1) at conffile.c:523 #4 0x80536b5 in reconfigure_modules () at modules.c:507 #5 0x80500aa in reconfigure () at init.c:802 #6 0x40134445 in do_rehash (u=0x8132128) at main.c:1071 #7 0x804dcaa in run_cmd (service=0x8129f40 "OperServ", u=0x8132128, id=0x812aec0, cmd=0xbffff759 "rehash") at commands.c:175 #8 0x40132999 in operserv (source=0xbffff96c "Peiter", target=0xbffff734 "operserv", buf=0xbffff759 "rehash") at main.c:256 #9 0x80538bd in call_callback_5 (module=0x0, id=25, arg1=0xbffff96c, arg2=0xbffff734, arg3=0xbffff759, arg4=0x0, arg5=0x0) at modules.c:612 #10 0x8051d35 in m_privmsg (source=0xbffff96c "Peiter", ac=2, av=0x8132050) at messages.c:169 #11 0x8053e31 in process () at process.c:131 #12 0x8051581 in readline_callback (s=0x812f298, param_unused=0x3d) at main.c:158 #13 0x805511f in check_sockets () at sockets.c:364 #14 0x805180d in main (ac=1, av=0xbffffb64, envp=0xbffffb6c) at main.c:260 Greetings Georges -----Ursprungliche Nachricht----- Von: ircservices-coding-admin@ircservices.za.net [mailto:ircservices-coding-admin@ircservices.za.net]Im Auftrag von Andrew Church Gesendet: Donnerstag, 20. Dezember 2001 06:22 An: ircservices-coding@ircservices.za.net Betreff: [IRCServices Coding] Services 5.0 alpha 8 released I've put up a new alpha tarball, alpha 8; it can be downloaded from the same place as the last one (http://achurch.org/services/5.0-alpha/). The crashing and infinite loop bugs reported before should be fixed, and rehashing has now been added. The change log is as follows: 2001/12/20 a8 SIGHUP now re-reads the configuration files instead of restarting. 2001/12/20 SIGUSR2 no longer opens log file if it was closed before. 2001/12/20 Added reconfiguration support for modules. 2001/12/20 Renamed AkillReason config directive to AutokillReason. 2001/12/19 Fixed crash when unloading modules on exit. 2001/12/17 Fixed infinite loop on signal. Reported by Georges Berscheid 2001/12/14 Fixed various problems caused by signal timing. 2001/12/14 Fixed compile error on FreeBSD. Reported by Ben Goldstein --Andrew Church achurch@achurch.org http://achurch.org/ ------------------------------------------------------------------ To unsubscribe or change your subscription options, visit: http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Fri Dec 21 17:07:27 2001 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:11 2004 Subject: AW: [IRCServices Coding] Services 5.0 alpha 8 released Message-ID: <3c22edd9.01433@achurch.org> >Hi, > >I just installed alpha8 and tried the new /operserv rehash function. But >unfortunately it segfaults every time. Can you send me a copy of your services.conf and modules.conf? --Andrew Church achurch@achurch.org http://achurch.org/ >gdb says: > >#0 chunk_free (ar_ptr=0x464c457f, p=0x4007b9f8) at malloc.c:3049 >#1 0x40076fba in __libc_free (mem=0x4007ba00) at malloc.c:3023 >#2 0x804e84c in read_config_file (modulename=0x812e888 "statserv/main", >directives=0x4018444c) at conffile.c:380 >#3 0x804ecbc in configure (modulename=0x812e888 "statserv/main", >directives=0x4018444c, action=1) at conffile.c:523 >#4 0x80536b5 in reconfigure_modules () at modules.c:507 >#5 0x80500aa in reconfigure () at init.c:802 >#6 0x40134445 in do_rehash (u=0x8132128) at main.c:1071 >#7 0x804dcaa in run_cmd (service=0x8129f40 "OperServ", u=0x8132128, >id=0x812aec0, cmd=0xbffff759 "rehash") at commands.c:175 >#8 0x40132999 in operserv (source=0xbffff96c "Peiter", target=0xbffff734 >"operserv", buf=0xbffff759 "rehash") at main.c:256 >#9 0x80538bd in call_callback_5 (module=0x0, id=25, arg1=0xbffff96c, >arg2=0xbffff734, arg3=0xbffff759, arg4=0x0, arg5=0x0) > at modules.c:612 >#10 0x8051d35 in m_privmsg (source=0xbffff96c "Peiter", ac=2, av=0x8132050) >at messages.c:169 >#11 0x8053e31 in process () at process.c:131 >#12 0x8051581 in readline_callback (s=0x812f298, param_unused=0x3d) at >main.c:158 >#13 0x805511f in check_sockets () at sockets.c:364 >#14 0x805180d in main (ac=1, av=0xbffffb64, envp=0xbffffb6c) at main.c:260 > >Greetings > >Georges > >-----Ursprungliche Nachricht----- >Von: ircservices-coding-admin@ircservices.za.net >[mailto:ircservices-coding-admin@ircservices.za.net]Im Auftrag von Andrew >Church >Gesendet: Donnerstag, 20. Dezember 2001 06:22 >An: ircservices-coding@ircservices.za.net >Betreff: [IRCServices Coding] Services 5.0 alpha 8 released > > > I've put up a new alpha tarball, alpha 8; it can be downloaded from >the same place as the last one (http://achurch.org/services/5.0-alpha/). >The crashing and infinite loop bugs reported before should be fixed, and >rehashing has now been added. The change log is as follows: > >2001/12/20 a8 SIGHUP now re-reads the configuration files instead of > restarting. >2001/12/20 SIGUSR2 no longer opens log file if it was closed before. >2001/12/20 Added reconfiguration support for modules. >2001/12/20 Renamed AkillReason config directive to AutokillReason. >2001/12/19 Fixed crash when unloading modules on exit. >2001/12/17 Fixed infinite loop on signal. Reported by Georges > Berscheid >2001/12/14 Fixed various problems caused by signal timing. >2001/12/14 Fixed compile error on FreeBSD. Reported by Ben Goldstein > > > --Andrew Church > achurch@achurch.org > http://achurch.org/ >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From achurch at achurch.org Sat Dec 22 00:40:23 2001 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] svcs5 Message-ID: <3c235838.11277@achurch.org> >this may try to free something that is not malloced (if i get this right) >when it is called from makechan() (free(NULL) works under glibc, but i do >n't >know how portable/standard it is) I'm pretty sure that's standard, and if it turns out not to be I'll just write my own free() because the rest of the code assumes it works that way. >finaly in chanserv/access-levels.c, in do_levels(): [snip] >the marked line is where i get the coredump... >it doesn't make any sense.. >if ci->levels is NULL, then reset_levels is not called... >so it remains NULL and then ci->levels[] is used The test on ci->levels was backwards in sense. Fixed, thanks. --Andrew Church achurch@achurch.org http://achurch.org/ From griever at t2n.org Fri Dec 21 11:51:00 2001 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] svcs5 In-Reply-To: <3c235838.11277@achurch.org> Message-ID: On Sat, 22 Dec 2001, Andrew Church wrote: > >this may try to free something that is not malloced (if i get this right) > >when it is called from makechan() (free(NULL) works under glibc, but i do > >n't > >know how portable/standard it is) > > I'm pretty sure that's standard, and if it turns out not to be I'll > just write my own free() because the rest of the code assumes it works > that way. ISO C guarantees free(NULL) is safe > > >finaly in chanserv/access-levels.c, in do_levels(): > [snip] > >the marked line is where i get the coredump... > >it doesn't make any sense.. > >if ci->levels is NULL, then reset_levels is not called... > >so it remains NULL and then ci->levels[] is used > > The test on ci->levels was backwards in sense. Fixed, thanks. > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From v13 at priest.com Sat Dec 22 10:42:29 2001 From: v13 at priest.com (v13@priest.com) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] svc5 exception move Message-ID: <200112221842.UAA04340@ppp0.the.forthnet.gr> in operserv/sessions.c, do_exception_move(): char *n1str = strtok(NULL, " "); /* From index */ char *n2str = strtok(NULL, " "); /* To index */ int n1, n2; if (!n2str) { syntax_error(s_OperServ, u, "EXCEPTION", OPER_EXCEPTION_MOVE_SYNTAX); return; } n1 = atoi(n1str) - 1; n2 = atoi(n2str) - 1; >>> if (n1 == n2 || n1 <= 0 || n2 <= 0) { <<< HERE <<<<<<<<<<<<<<<<<<<< syntax_error(s_OperServ, u, "EXCEPTION", OPER_EXCEPTION_MOVE_SYNTAX); return; } I believe the noted line should not have <= When trying to move exception #1 it fails and, when there are 3 exceptions: /os exception move 4 3 gives: -OperServ- Exception for *.hell.gr (#3) moved to number 2. exception move also doesn't seem to work at all. (tested under alpha7, but alpha8 hasn't change this) <> From griever at t2n.org Sat Dec 22 17:27:28 2001 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] unknown things Message-ID: [Dec 22 19:25:41.487805 2001] debug: Loading module `operserv/main' [Dec 22 19:25:41.491171 2001] modules.conf:178: Unknown directive `LogMaxUsers' [Dec 22 19:25:41.491643 2001] modules.conf:220: Unknown directive `WallGetpass' [Dec 22 19:25:41.491805 2001] modules.conf:227: Unknown directive `WallSetpass' have those been moved? From mark at mhetherington.demon.co.uk Sat Dec 22 17:37:15 2001 From: mark at mhetherington.demon.co.uk (Mark Hetherington) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] unknown things In-Reply-To: Message-ID: I mentioned this in another email. There are checked in the wrong place (module load which does no know what they are rather than services load which does know). I meant to move the directives from one to the other but have not tried it yet. Mark. > -----Original Message----- > From: ircservices-coding-admin@ircservices.za.net > [mailto:ircservices-coding-admin@ircservices.za.net]On Behalf Of Finny > Merrill > Sent: 23 December 2001 01:27 > To: ircservices-coding@ircservices.za.net > Subject: [IRCServices Coding] unknown things > > > [Dec 22 19:25:41.487805 2001] debug: Loading module `operserv/main' > [Dec 22 19:25:41.491171 2001] modules.conf:178: Unknown directive > `LogMaxUsers' > [Dec 22 19:25:41.491643 2001] modules.conf:220: Unknown directive > `WallGetpass' > [Dec 22 19:25:41.491805 2001] modules.conf:227: Unknown directive > `WallSetpass' > > have those been moved? > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From achurch at achurch.org Sun Dec 23 16:14:05 2001 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] unknown things Message-ID: <3c258453.02003@achurch.org> >[Dec 22 19:25:41.487805 2001] debug: Loading module `operserv/main' >[Dec 22 19:25:41.491171 2001] modules.conf:178: Unknown directive >`LogMaxUsers' >[Dec 22 19:25:41.491643 2001] modules.conf:220: Unknown directive >`WallGetpass' >[Dec 22 19:25:41.491805 2001] modules.conf:227: Unknown directive >`WallSetpass' I've been meaning to do something about these for a LONG time, but there's been too much else going on. I'll take care of them eventually. --Andrew Church achurch@achurch.org http://achurch.org/ From admin at insiderZ.de Sun Dec 23 09:06:15 2001 From: admin at insiderZ.de (Christian 'HERZ' Makowski) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Hello ! Message-ID: Hello Together, I am new here and i have a Question / Compilerproblem. We work at the Momentan in our Network with Epona Services but we have many problems with stability. We want to Change to Ircservices, Coder from Unrealircd says , this is the best for Unreal. I just downloaded ircservices-5.0a8.tar.gz because we want to support ircservices with Unreal3.2 / ipv6 but i have the first error: I have tried make & gmake , what the problem here ?!? ircservices4.5.35 compiles fine. [insiderz@ns ircservices-5.0a8]$ gmake sh version.sh gcc -DCLEAN_COMPILE -O2 -Wall -Wmissing-prototypes -g -c version.c -o version.o gmake[1]: Entering directory `/home/insiderz/ircservices-5.0a8/modules' gmake[2]: Entering directory `/home/insiderz/ircservices-5.0a8/modules/chanserv' gmake[2]: *** No rule to make target `main.so', needed by `all-dynamic'. Stop. gmake[2]: Leaving directory `/home/insiderz/ircservices-5.0a8/modules/chanserv' gmake[1]: *** [all-dynamic] Error 2 gmake[1]: Leaving directory `/home/insiderz/ircservices-5.0a8/modules' gmake: *** [modules] Error 2 Thanks in advance for help and merry merry Xmas to All ! Christian -HERZ- Makowski Networkadmin InsiderZ From jbinder at kgazd.bme.hu Sun Dec 23 09:51:52 2001 From: jbinder at kgazd.bme.hu (John Binder) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Hello ! References: Message-ID: <000701c18bda$80e61be0$0d624298@kgazd.bme.hu> Hi, > I have tried make & gmake , what the problem here ?!? > ircservices4.5.35 compiles fine. > > [insiderz@ns ircservices-5.0a8]$ gmake > sh version.sh > gcc -DCLEAN_COMPILE -O2 -Wall -Wmissing-prototypes -g -c version.c -o > version.o > gmake[1]: Entering directory `/home/insiderz/ircservices-5.0a8/modules' > gmake[2]: Entering directory > `/home/insiderz/ircservices-5.0a8/modules/chanserv' > gmake[2]: *** No rule to make target `main.so', needed by `all-dynamic'. > Stop. > gmake[2]: Leaving directory > `/home/insiderz/ircservices-5.0a8/modules/chanserv' > gmake[1]: *** [all-dynamic] Error 2 > gmake[1]: Leaving directory `/home/insiderz/ircservices-5.0a8/modules' > gmake: *** [modules] Error 2 IMHO configure was forgotten, try to ./configure before it John Binder > Thanks in advance for help and merry merry Xmas to All ! > > Christian -HERZ- Makowski > Networkadmin InsiderZ > > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > > From achurch at achurch.org Mon Dec 24 10:56:31 2001 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Hello ! Message-ID: <3c268d42.02117@achurch.org> >Hello Together, > >I am new here and i have a Question / Compilerproblem. >We work at the Momentan in our Network with Epona Services >but we have many problems with stability. >We want to Change to Ircservices, Coder from Unrealircd >says , this is the best for Unreal. > >I just downloaded ircservices-5.0a8.tar.gz because we want to support >ircservices with Unreal3.2 / ipv6 but i have the first error: DO NOT use the alpha version of Services on a live network! Alpha versions are for testing ONLY. DO NOT contact either me or the mailing lists with questions about an alpha version unless you intend to help test and find bugs yourself. If you ignore this warning, I will either ban you from downloading the alpha version, or remove the alpha version from public access entirely and publicly give your name and E-mail address as the reason the alpha was removed. --Andrew Church achurch@achurch.org http://achurch.org/ >I have tried make & gmake , what the problem here ?!? >ircservices4.5.35 compiles fine. > >[insiderz@ns ircservices-5.0a8]$ gmake >sh version.sh >gcc -DCLEAN_COMPILE -O2 -Wall -Wmissing-prototypes -g -c version.c -o >version.o >gmake[1]: Entering directory `/home/insiderz/ircservices-5.0a8/modules' >gmake[2]: Entering directory >`/home/insiderz/ircservices-5.0a8/modules/chanserv' >gmake[2]: *** No rule to make target `main.so', needed by `all-dynamic'. >Stop. >gmake[2]: Leaving directory >`/home/insiderz/ircservices-5.0a8/modules/chanserv' >gmake[1]: *** [all-dynamic] Error 2 >gmake[1]: Leaving directory `/home/insiderz/ircservices-5.0a8/modules' >gmake: *** [modules] Error 2 > >Thanks in advance for help and merry merry Xmas to All ! > >Christian -HERZ- Makowski >Networkadmin InsiderZ > > >------------------------------------------------------------------ >To unsubscribe or change your subscription options, visit: >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From casper at wbss.com Sun Dec 23 20:03:37 2001 From: casper at wbss.com (CaSPeR) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] raw commands Message-ID: <017601c18c2f$f7c503c0$ace4fea9@casper> just wanted to know if there is a list of commands and their discriptions somewhere? also want to know what command to use to bring in a fake user. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20011223/56c54ad1/attachment.html From smkelly at zombie.org Sun Dec 23 20:35:49 2001 From: smkelly at zombie.org (Sean Kelly) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] raw commands In-Reply-To: <017601c18c2f$f7c503c0$ace4fea9@casper>; from casper@wbss.com on Sun, Dec 23, 2001 at 11:03:37PM -0500 References: <017601c18c2f$f7c503c0$ace4fea9@casper> Message-ID: <20011223223549.A2427@edgemaster.zombie.org> On Sun, Dec 23, 2001 at 11:03:37PM -0500, CaSPeR wrote: > just wanted to know if there is a list of commands and their discriptions somewhere? > also want to know what command to use to bring in a fake user. RAW merely passes the string on to services' uplink server. Any valid IRC command, as issued by a server, is valid. I suggest you read RFC1459 and also become familiar with the workings of ircd before you play with RAW. It isn't a toy. -- Sean Kelly | PGP KeyID: 77042C7B smkelly@zombie.org | http://www.zombie.org For PGP key, send e-mail with subject "send pgp key" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20011223/3486e5a6/attachment.pgp From chromi at cyberspace.org Sun Dec 23 20:22:16 2001 From: chromi at cyberspace.org (Jonathan Morton) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] raw commands In-Reply-To: <017601c18c2f$f7c503c0$ace4fea9@casper> References: <017601c18c2f$f7c503c0$ace4fea9@casper> Message-ID: >just wanted to know if there is a list of commands and their >discriptions somewhere? >also want to know what command to use to bring in a fake user. Consult your IRCd's documentation. Commands available via RAW are not under Services' control and can cause major problems. -- -------------------------------------------------------------- from: Jonathan "Chromatix" Morton mail: chromi@cyberspace.org (not for attachments) website: http://www.chromatix.uklinux.net/vnc/ geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) tagline: The key to knowledge is not to rely on people to teach you it. From achurch at achurch.org Mon Dec 24 22:21:35 2001 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] svc5 exception move Message-ID: <3c272c21.02247@achurch.org> >When trying to move exception #1 it fails and, when there are 3 exception >s: > >/os exception move 4 3 > >gives: > >-OperServ- Exception for *.hell.gr (#3) moved to number 2. Thanks, fixed (the problem is the -1's, which shouldn't be there). >exception move also doesn't seem to work at all. That's because the code that actually does it (in database/ver4.c) is still broken (#ifdef'd out) and I haven't had a chance to fix it yet. --Andrew Church achurch@achurch.org http://achurch.org/ From lamego at ptlink.net Tue Dec 25 12:38:28 2001 From: lamego at ptlink.net (lamego@ptlink.net) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Hello ! Message-ID: <20011225124018.3C86B1742B@snow.fingers.co.za> Is the Alpha distributed with some kind of "not public" license ? I do know the term "use it at your own risk", but this "forbidden to use on a live network" is a new one. Just a thought, Joao Pinto Andrew Church wrote : > >Hello Together, > > > >I am new here and i have a Question / Compilerproblem. > >We work at the Momentan in our Network with Epona Services > >but we have many problems with stability. > >We want to Change to Ircservices, Coder from Unrealircd > >says , this is the best for Unreal. > > > >I just downloaded ircservices-5.0a8.tar.gz because we want to support > >ircservices with Unreal3.2 / ipv6 but i have the first error: > > DO NOT use the alpha version of Services on a live network! Alpha > versions are for testing ONLY. DO NOT contact either me or the mailing > lists with questions about an alpha version unless you intend to help test > and find bugs yourself. If you ignore this warning, I will either ban you > from downloading the alpha version, or remove the alpha version from public > access entirely and publicly give your name and E-mail address as the > reason the alpha was removed. > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > > >I have tried make & gmake , what the problem here ?!? > >ircservices4.5.35 compiles fine. > > > >[insiderz@ns ircservices-5.0a8]$ gmake > >sh version.sh > >gcc -DCLEAN_COMPILE -O2 -Wall -Wmissing-prototypes -g -c version.c -o > >version.o > >gmake[1]: Entering directory `/home/insiderz/ircservices-5.0a8/modules' > >gmake[2]: Entering directory > >`/home/insiderz/ircservices-5.0a8/modules/chanserv' > >gmake[2]: *** No rule to make target `main.so', needed by `all-dynamic'. > >Stop. > >gmake[2]: Leaving directory > >`/home/insiderz/ircservices-5.0a8/modules/chanserv' > >gmake[1]: *** [all-dynamic] Error 2 > >gmake[1]: Leaving directory `/home/insiderz/ircservices-5.0a8/modules' > >gmake: *** [modules] Error 2 > > > >Thanks in advance for help and merry merry Xmas to All ! > > > >Christian -HERZ- Makowski > >Networkadmin InsiderZ > > > > > >------------------------------------------------------------------ > >To unsubscribe or change your subscription options, visit: > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From christian.makowski at t-online.de Tue Dec 25 04:44:51 2001 From: christian.makowski at t-online.de (Christian Makowski) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Hello ! Message-ID: <1009284150.3c287436d2282@webmail.t-online.de> lamego@ptlink.net schrieb: > Is the Alpha distributed with some kind of "not public" > license ? > I do know the term "use it at your own risk", but this > "forbidden to use on a live network" is a new one. > > Just a thought, > Joao Pinto > So i think too Then i ask me, why a Alpha is Released to download from a Mainsite with a BIG Advertising link. It would be better on a CVS Server for internal Use. From achurch at achurch.org Tue Dec 25 22:11:53 2001 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Hello ! Message-ID: <3c287df1.12075@achurch.org> >> Is the Alpha distributed with some kind of "not public" >> license ? >> I do know the term "use it at your own risk", but this >> "forbidden to use on a live network" is a new one. The license is the GPL, the same as it has always been, but the only reason I'm making it publicly available at all while it's still in alpha is to get help from _experienced_ users in fixing the remaining major problems before I take it to beta status and do a full-fledged release. (From the response I've seen so far I'm half inclined to take it down again.) >So i think too >Then i ask me, why a Alpha is Released to download from a Mainsite >with a BIG Advertising link. Because that's the only way to let people know who might want to help with an alpha test. You might also note that there's a fairly large and obvious warning--on two consecutive pages, no less!--before you can actually download the alpha version. Please remember that I have NO obligation whatsoever to provide any sort of "service" to you or even to publish IRC Services at all. The only thing I get out of Services is appreciation from users, which includes the recognition that I do this on my own free time without any sort of compensation other than the thanks of users for creating it. (Frankly, I would probably be a much happier person if I hadn't devoted many thousands of hours over six years to Services, but oh well.) Thus, I do NOT appreciate people ignoring warnings I put up explicitly to prevent these kinds of questions/complaints. Please try to act more responsibly in the future. (That applies to everyone.) --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Tue Dec 25 22:24:20 2001 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Services 5.0 alpha 9 released Message-ID: <3c2880d1.12116@achurch.org> Alpha 9 is up in the usual place; this is mainly a release to get accumulated changes uploaded before I leave on vacation (tomorrow). I'll be back late on 1 January, if things go according to plan, so mail will go unanswered until then. Also, happy holidays to all. This is meant seriously, for those who may be unsure: I'm not the fascist bastard I may seem in mail sometimes-- I just play one on the Internet, so to speak. (: I don't intend to let my holiday season get overwhelmed by this or any other minor matter, and I hope none of you do either. --Andrew Church achurch@achurch.org http://achurch.org/ From rg at tcslon.com Tue Dec 25 09:53:27 2001 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Services 5.0 alpha 9 released In-Reply-To: <3c2880d1.12116@achurch.org> Message-ID: OK, a few comments from me. I haven't managed to crash it yet, which is always a good sign ;). I was playing with the httpd/dbaccess/xml-export module, and IE6's usually annoying XML syntax checking pointed something out. Where there's an ampersand in a last_quit field, it replaces it with "&-" as opposed to the correct "&", which causes IE to choke :). The context is as follows: [nick] ... Quit: Peace &- Protection 4.06 ... Also, it seems to pad every or field with lots of "�" null chars: mysupass�������������& #0;�������� ���������������� ;���������������� Note: I am working with a copy of my live v4 database. Also, on my #chat channel on the v4 installation, Voice is set to level 0, so everyone is voiced when they join. However, when my AOPs join #chat on the v5 net, they get set +hq, and normal users don't get anything, which is rather odd (possibly to do with me not running the xOP module or something...). I'm continuing to investigate this one. Cheers, Russ Garrett (russ@garrett.co.uk) From achurch at achurch.org Wed Dec 26 03:08:51 2001 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Services 5.0 alpha 9 released Message-ID: <3c28c329.41041@achurch.org> >I was playing with the httpd/dbaccess/xml-export module, and IE6's >usually annoying XML syntax checking pointed something out. Where >there's an ampersand in a last_quit field, it replaces it with >"&-" as opposed to the correct "&", which causes IE to choke >:). The context is as follows: > > >[nick] >... >Quit: Peace &- Protection 4.06 >... > Okay, that was a stupid one... an off-by-one error in a memcpy() size argument. Fixed, thanks; the patch is as follows: --------------------------------------------------------------------------- --- modules/misc/xml-export.c 19 Dec 2001 16:35:13 -0000 2.2 +++ modules/misc/xml-export.c 25 Dec 2001 18:12:42 -0000 2.3 @@ -94,7 +94,7 @@ d += 4; break; case '&': - memcpy(d, "&", 4); + memcpy(d, "&", 5); d += 5; break; default: --------------------------------------------------------------------------- >Also, it seems to pad every or field with lots of >"�" null chars: >mysupass�������������& >#0;�������� >���������������� >;����������������ss> This is because the export-xml module can't know that the encryption module (if one is in use) uses a null character as a string terminator. In point of fact, the MD5 encryption module stores the passwords as 16 raw bytes rather than 32 hex characters, so null characters can very possibly appear in the middle of a password. Thus, passwords are stored as raw buffers of data (properly XML-encoded). >Also, on my #chat channel on the v4 installation, Voice is set to >level 0, so everyone is voiced when they join. However, when my AOPs >join #chat on the v5 net, they get set +hq, and normal users don't >get anything, which is rather odd (possibly to do with me not running >the xOP module or something...). I'm continuing to investigate this >one. You should probably look into what check_access_cumode() (modules/chanserv/access.c) is doing; that part of the code has been thoroughly redone and gotten almost no testing. I'm not sure what would cause the autovoice level to get set to 0. --Andrew Church achurch@achurch.org http://achurch.org/ From rg at tcslon.com Tue Dec 25 11:14:58 2001 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:11 2004 Subject: [IRCServices Coding] Services 5.0 alpha 9 released In-Reply-To: <3c28c329.41041@achurch.org> Message-ID: > Okay, that was a stupid one... an off-by-one error in > a memcpy() size > argument. Fixed, thanks; the patch is as follows: Thanks > ... > appear in the middle of a password. Thus, passwords are > stored as raw > buffers of data (properly XML-encoded). Fair enough, just wondering what they were doing :) > You should probably look into what check_access_cumode() > (modules/chanserv/access.c) is doing; that part of the > code has been > thoroughly redone and gotten almost no testing. I'm not > sure what would > cause the autovoice level to get set to 0. Ahh, I wasn't very clear there - the autovoice level was set to 0 on the version 4 services by my chanops to make it easier to silence certain users :). On the v5 net, with both the xOP and Levels modules loaded, nothing happens to level 0 users, and users previously autoopped (levels 5+) are all set mode +hq (insofar as that there is more than one +q user in the room...). Just a few more things that I've noticed: - The news.db database (imported from version 4) corrupted rather easily the first time I sent services a SIGTERM. Now I get [Oper News - Jan 01 1970] (null). - The /os rehash command doesn't seem to rehash very many configuration options. I could be wrong, but I don't think I've seen any of the modules.conf options updated using this command. - httpd/auth-password doesn't seem to work at all for me: Module httpd/auth-password AuthName "PhaseNet Test IRC Services" Protect /debug "quack:quack" Protect /dbaccess "quack:quack" EndModule No auth box is presented - The httpd/dbaccess module is very useful for debugging access/levels problems such as the above, but it would be quite handy to have a http://serviceshost/dbaccess/chanserv/chan/levels page, showing the xOP levels sometimes. That's about all for the moment ;), Russ Garrett (russ@garrett.co.uk) From lamego at ptlink.net Tue Dec 25 20:46:30 2001 From: lamego at ptlink.net (lamego@ptlink.net) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Hello ! Message-ID: <20011225204816.7C6DA17444@snow.fingers.co.za> Andrew Church wrote : > >> Is the Alpha distributed with some kind of "not public" > >> license ? > >> I do know the term "use it at your own risk", but this > >> "forbidden to use on a live network" is a new one. > > The license is the GPL, the same as it has always been, but the only > reason I'm making it publicly available at all while it's still in alpha is > to get help from _experienced_ users in fixing the remaining major problems > before I take it to beta status and do a full-fledged release. (From the > response I've seen so far I'm half inclined to take it down again.) You are getting help from _experienced_ users however making it public you should be also prepared to get *NOT* help from general users. > > >So i think too > >Then i ask me, why a Alpha is Released to download from a Mainsite > >with a BIG Advertising link. > > Because that's the only way to let people know who might want to help > with an alpha test. The guy was trying to help, but first he just needed some help :P >You might also note that there's a fairly large and > obvious warning--on two consecutive pages, no less!--before you can > actually download the alpha version. One more reason that it is user's responsability so you should not be worried with someone running it on a live network. > > Please remember that I have NO obligation whatsoever to provide any > sort of "service" to you or even to publish IRC Services at all. The only > thing I get out of Services is appreciation from users, which includes the > recognition that I do this on my own free time without any sort of > compensation other than the thanks of users for creating it. (Frankly, I > would probably be a much happier person if I hadn't devoted many thousands > of hours over six years to Services, but oh well.) You and all the guys who work on linux, gcc, gmake etc most of the software you need to compile and run ircservices. I don't remember none of them forbidding their alpha from beeing tested on "live servers". Thus, I do NOT > appreciate people ignoring warnings I put up explicitly to prevent these > kinds of questions/complaints. Sometimes the delete key is helpfull and not so stressing. > > Please try to act more responsibly in the future. (That applies to > everyone.) Doing it now, I hope :) > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding From rg at tcslon.com Tue Dec 25 13:11:22 2001 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] More bugs... :) In-Reply-To: <3c2880d1.12116@achurch.org> Message-ID: Another small XML bug, courtesy of IE6's XML parser :) Line 243 of modules/misc/xml-export.c is: writefunc(data, "\t\n"); and should be: writefunc(data, "\t\n"); with the forwardslash. After that's changed the XML checks out fine in IE. I spotted that repeated segfault-on-squit problem again, but couldn't repeat it, and coredumping wasn't on. I've turned it on, so I should be able to catch it next time :) Cheers, Russ Garrett (russ@garrett.co.uk) From ron885 at linuxfreemail.com Tue Dec 25 15:35:45 2001 From: ron885 at linuxfreemail.com (Ron ) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] A bug i think... Message-ID: <200112252335.fBPNZjb27708@superglide.netfx-2000.net> I was playing with alpha8 last night, and discovered this and wasn't quite sure if it is whats supposed to happen. The session limit was set two 3 and i had one client loaded, Ron885, and the other one connecting, Ron885_... [01:28:20] Global: OperServ - Ron885 added an SGLINE for ron (expires in 1 minute) [01:28:34] Connect: Ron885_ (ron885@ron.linux) on port 6667 [01:28:34] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ (Invalid Real Name) [01:28:34] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ (Invalid Real Name))] [01:28:37] Connect: Ron885_ (ron885@ron.linux) on port 6667 [01:28:37] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ (Invalid Real Name) [01:28:37] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ (Invalid Real Name))] [01:28:38] Connect: Ron885_ (ron885@ron.linux) on port 6667 [01:28:38] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ (Session limit exceeded) [01:28:38] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ (Session limit exceeded))] [01:28:43] Connect: Ron885_ (ron885@ron.linux) on port 6667 [01:28:43] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ (Session limit exceeded) [01:28:43] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ (Session limit exceeded))] [01:28:48] Connect: Ron885_ (ron885@ron.linux) on port 6667 [01:28:48] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ (Session limit exceeded) [01:28:48] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ (Session limit exceeded))] [01:28:52] Connect: Ron885_ (ron885@ron.linux) on port 6667 [01:28:52] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ (Session limit exceeded) [01:28:52] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ (Session limit exceeded))] [01:28:53] Connect: Ron885_ (ron885@ron.linux) on port 6667 [01:28:53] GLINE: added for *@ron.linux on Mon Dec 24 20:28:53 2001 GMT (from OperServ to expire at Mon Dec 24 20:58:53 2001 GMT: Autokilled: Exceeding session limit) [01:28:53] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ (Session limit exceeded) [01:28:53] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ (Session limit exceeded))] [01:28:53] -1.axenet.org- *** You are banned from Axenet (Autokilled: Exceeding session limit) [01:28:53] Disconnect: Ron885 (ron885@ron.linux) [User has been banned from Axenet (Autokilled: Exceeding session limit)] [01:28:53] --- Closing Link: Ron885[ron.linux] (User has been banned from Axenet (Autokilled: Exceeding session limit)) [01:28:53] --- Disconnected (Remote host closed socket). it seems as if the session list gets messed up... because afterwards i had one client connected and did /os session view and it said 3 of 3 when there was only one connected... -- Ron885 TechAdmin @ irc.axenet.org Get your own FREE E-mail address at http://www.linuxfreemail.com Linux FREE Mail is 100% FREE, 100% Linux, 100% better, and 100% yours! From griever at t2n.org Tue Dec 25 16:43:52 2001 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] A bug i think... In-Reply-To: <200112252335.fBPNZjb27708@superglide.netfx-2000.net> Message-ID: I noticed this too, I think it has something to do with +x On Tue, 25 Dec 2001, Ron wrote: > I was playing with alpha8 last night, and discovered this and wasn't > quite sure if it is whats supposed to happen. The session limit was > set two 3 and i had one client loaded, Ron885, and the other one > connecting, Ron885_... > > [01:28:20] Global: OperServ - Ron885 added an SGLINE for ron (expires > in 1 minute) > [01:28:34] Connect: Ron885_ (ron885@ron.linux) on port 6667 > [01:28:34] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ > (Invalid Real Name) > [01:28:34] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ > (Invalid Real Name))] > [01:28:37] Connect: Ron885_ (ron885@ron.linux) on port 6667 > [01:28:37] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ > (Invalid Real Name) > [01:28:37] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ > (Invalid Real Name))] > [01:28:38] Connect: Ron885_ (ron885@ron.linux) on port 6667 > [01:28:38] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ > (Session limit exceeded) > [01:28:38] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ > (Session limit exceeded))] > [01:28:43] Connect: Ron885_ (ron885@ron.linux) on port 6667 > [01:28:43] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ > (Session limit exceeded) > [01:28:43] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ > (Session limit exceeded))] > [01:28:48] Connect: Ron885_ (ron885@ron.linux) on port 6667 > [01:28:48] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ > (Session limit exceeded) > [01:28:48] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ > (Session limit exceeded))] > [01:28:52] Connect: Ron885_ (ron885@ron.linux) on port 6667 > [01:28:52] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ > (Session limit exceeded) > [01:28:52] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ > (Session limit exceeded))] > [01:28:53] Connect: Ron885_ (ron885@ron.linux) on port 6667 > [01:28:53] GLINE: added for *@ron.linux on Mon Dec 24 20:28:53 2001 GMT > (from OperServ to expire at Mon Dec 24 20:58:53 2001 GMT: Autokilled: > Exceeding session limit) > [01:28:53] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ > (Session limit exceeded) > [01:28:53] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ > (Session limit exceeded))] > [01:28:53] -1.axenet.org- *** You are banned from Axenet (Autokilled: > Exceeding session limit) > [01:28:53] Disconnect: Ron885 (ron885@ron.linux) [User has been banned > from Axenet (Autokilled: Exceeding session limit)] > [01:28:53] --- Closing Link: Ron885[ron.linux] (User has been banned > from Axenet (Autokilled: Exceeding session limit)) > [01:28:53] --- Disconnected (Remote host closed socket). > > it seems as if the session list gets messed up... because afterwards i > had one client connected and did /os session view and it said 3 of 3 > when there was only one connected... > > -- > Ron885 > TechAdmin @ irc.axenet.org > > Get your own FREE E-mail address at http://www.linuxfreemail.com > Linux FREE Mail is 100% FREE, 100% Linux, 100% better, and 100% yours! > > > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From achurch at achurch.org Wed Dec 26 10:30:20 2001 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] A bug i think... Message-ID: <3c29288e.06571@achurch.org> >I was playing with alpha8 last night, and discovered this and wasn't >quite sure if it is whats supposed to happen. The session limit was >set two 3 and i had one client loaded, Ron885, and the other one >connecting, Ron885_... [...] >it seems as if the session list gets messed up... because afterwards i >had one client connected and did /os session view and it said 3 of 3 >when there was only one connected... This is because the session/exception callback gets called before the S-line one, leaving "ghost" users in the session count. Fixed, thanks. Patch is as follows (not tested): --- modules/operserv/sessions.c 24 Dec 2001 13:20:09 -0000 2.30 +++ modules/operserv/sessions.c 26 Dec 2001 01:27:15 -0000 @@ -728,7 +728,13 @@ return 0; } - if (!add_callback(NULL, "user check", check_sessions) + /* Add user check callback at priority -10 so it runs after all the + * autokill/S-line/whatever checks (otherwise we get users added to + * sessions and then killed by S-lines, leaving the session count + * jacked up). FIXME: we really really need to document places where + * we use callback priorities. + */ + if (!add_callback_pri(NULL, "user check", check_sessions, -10) || !add_callback(NULL, "user delete", remove_session) || !add_callback(NULL, "save data", do_save_data) || !add_callback(NULL, "expire", expire_exceptions) --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Wed Dec 26 11:30:02 2001 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Services 5.0 alpha 9 released Message-ID: <3c2939c5.10626@achurch.org> >> You should probably look into what check_access_cumode() >> (modules/chanserv/access.c) is doing; that part of the >> code has been >> thoroughly redone and gotten almost no testing. I'm not >> sure what would >> cause the autovoice level to get set to 0. > >Ahh, I wasn't very clear there - the autovoice level was set to 0 on >the version 4 services by my chanops to make it easier to silence >certain users :). On the v5 net, with both the xOP and Levels modules >loaded, nothing happens to level 0 users, and users previously >autoopped (levels 5+) are all set mode +hq (insofar as that there is >more than one +q user in the room...). Hm, I'll have to take a look into that... but it will have to be after I get back from vacation, I think. (: If you want to look into it yourself, check_access_cumode() is a good place to start, as mentioned above. >- The news.db database (imported from version 4) corrupted rather >easily the first time I sent services a SIGTERM. Now I get [Oper >News - Jan 01 1970] (null). I, uh, fixed that. Really. The gremlins must have backed out my commit, or something. >- The /os rehash command doesn't seem to rehash very many >configuration options. I could be wrong, but I don't think I've seen >any of the modules.conf options updated using this command. It should get most of them, and you should get log messages for ones that can't be dynamically updated. (However, this is only since alpha 8; alpha 7 didn't have support for reconfiguration in the modules.) At the least I've been able to make OperServ dynamically change nicks here. >- httpd/auth-password doesn't seem to work at all for me: >Module httpd/auth-password > AuthName "PhaseNet Test IRC Services" > Protect /debug "quack:quack" > Protect /dbaccess "quack:quack" >EndModule > >No auth box is presented Hm, it seems to have broken somewhere. I'll look into this as well. >- The httpd/dbaccess module is very useful for debugging >access/levels problems such as the above, but it would be quite handy >to have a http://serviceshost/dbaccess/chanserv/chan/levels page, >showing the xOP levels sometimes. Added to TODO. --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Wed Dec 26 11:45:30 2001 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] More bugs... :) Message-ID: <3c2939f1.10637@achurch.org> >Another small XML bug, courtesy of IE6's XML parser :) > >Line 243 of modules/misc/xml-export.c is: > writefunc(data, "\t\n"); >and should be: > writefunc(data, "\t\n"); >with the forwardslash. Thanks, fixed. >After that's changed the XML checks out fine in IE. That's good to know... especially as it's my first attempt in doing anything at all with XML. (: --Andrew Church achurch@achurch.org http://achurch.org/ From griever at t2n.org Tue Dec 25 19:30:49 2001 From: griever at t2n.org (Finny Merrill) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Services 5.0 alpha 9 released In-Reply-To: <3c2939c5.10626@achurch.org> Message-ID: On Wed, 26 Dec 2001, Andrew Church wrote: > >> You should probably look into what check_access_cumode() > >> (modules/chanserv/access.c) is doing; that part of the > >> code has been > >> thoroughly redone and gotten almost no testing. I'm not > >> sure what would > >> cause the autovoice level to get set to 0. > > > >Ahh, I wasn't very clear there - the autovoice level was set to 0 on > >the version 4 services by my chanops to make it easier to silence > >certain users :). On the v5 net, with both the xOP and Levels modules > >loaded, nothing happens to level 0 users, and users previously > >autoopped (levels 5+) are all set mode +hq (insofar as that there is > >more than one +q user in the room...). > > Hm, I'll have to take a look into that... but it will have to be after > I get back from vacation, I think. (: If you want to look into it yourself, > check_access_cumode() is a good place to start, as mentioned above. > > >- The news.db database (imported from version 4) corrupted rather > >easily the first time I sent services a SIGTERM. Now I get [Oper > >News - Jan 01 1970] (null). > > I, uh, fixed that. Really. The gremlins must have backed out my > commit, or something. > > >- The /os rehash command doesn't seem to rehash very many > >configuration options. I could be wrong, but I don't think I've seen > >any of the modules.conf options updated using this command. > > It should get most of them, and you should get log messages for ones > that can't be dynamically updated. (However, this is only since alpha 8; > alpha 7 didn't have support for reconfiguration in the modules.) At the > least I've been able to make OperServ dynamically change nicks here. > > >- httpd/auth-password doesn't seem to work at all for me: > >Module httpd/auth-password > > AuthName "PhaseNet Test IRC Services" > > Protect /debug "quack:quack" > > Protect /dbaccess "quack:quack" > >EndModule > > > >No auth box is presented You *DO* have the LoadModule line in services.conf, right? > > Hm, it seems to have broken somewhere. I'll look into this as well. > > >- The httpd/dbaccess module is very useful for debugging > >access/levels problems such as the above, but it would be quite handy > >to have a http://serviceshost/dbaccess/chanserv/chan/levels page, > >showing the xOP levels sometimes. > > Added to TODO. > > --Andrew Church > achurch@achurch.org > http://achurch.org/ > ------------------------------------------------------------------ > To unsubscribe or change your subscription options, visit: > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding > From achurch at achurch.org Wed Dec 26 14:23:28 2001 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Services 5.0 alpha 9 released Message-ID: <3c295f7a.25341@achurch.org> >Ahh, I wasn't very clear there - the autovoice level was set to 0 on >the version 4 services by my chanops to make it easier to silence >certain users :). On the v5 net, with both the xOP and Levels modules >loaded, nothing happens to level 0 users, and users previously >autoopped (levels 5+) are all set mode +hq (insofar as that there is >more than one +q user in the room...). [...] >- The news.db database (imported from version 4) corrupted rather >easily the first time I sent services a SIGTERM. Now I get [Oper >News - Jan 01 1970] (null). [...] >- httpd/auth-password doesn't seem to work at all for me: >Module httpd/auth-password > AuthName "PhaseNet Test IRC Services" > Protect /debug "quack:quack" > Protect /dbaccess "quack:quack" >EndModule > >No auth box is presented > >- The httpd/dbaccess module is very useful for debugging >access/levels problems such as the above, but it would be quite handy >to have a http://serviceshost/dbaccess/chanserv/chan/levels page, >showing the xOP levels sometimes. Okay, these are all fixed, and I'll put out another alpha release with the fixes in a moment. Ironically, the +hq bug, which I thought would be tricky to track down, turned out to be a simple one-line fix, while the dbaccess levels addition, which seemed pretty simple at first glance, took a bit of reorganizing things. Just goes to show something or other, I guess... --Andrew Church achurch@achurch.org http://achurch.org/ From achurch at achurch.org Wed Dec 26 14:45:03 2001 From: achurch at achurch.org (Andrew Church) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Services 5.0 alpha 10 released Message-ID: <3c2963d3.41711@achurch.org> Okay, this will _really_ be the last release before I leave on vacation, because I leave in about 15 minutes. (: Patches for the recently mentioned bugs are included. Change list is below: Version 5.0 ----------- 2001/12/26 a10 Fixed bug causing strange channel user modes to be auto-set. Reported by Russ Garrett 2001/12/26 Added access levels link to ChanServ information page (httpd/dbaccess). Suggested by Russ Garrett 2001/12/26 Fixed bug in auth-password module causing Protect lines to be ignored. Reported by Russ Garrett 2001/12/26 Fixed bug in news database writing causing corruption. 2001/12/26 Fixed missing slash on closing tag in XML export module. Reported by Russ Garrett 2001/12/26 Fixed callback ordering bug causing S-line kills to leave "ghost" users in the session count. Reported by 2001/12/26 Fixed off-by-one bug causing corrupted output in XML export module. Reported by Russ Garrett --Andrew Church achurch@achurch.org http://achurch.org/ From chromi at cyberspace.org Tue Dec 25 07:16:06 2001 From: chromi at cyberspace.org (Jonathan Morton) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Hello ! In-Reply-To: <20011225124018.3C86B1742B@snow.fingers.co.za> References: <20011225124018.3C86B1742B@snow.fingers.co.za> Message-ID: >Is the Alpha distributed with some kind of "not public" license ? >I do know the term "use it at your own risk", but this "forbidden to >use on a live network" is a new one. You're not forbidden to use it on a live network. You are, however, forbidden from making a fuss when your p***ed-off users break down your front door. :) You're also forbidden from whining about how buggy it is - it'a an ALPHA release for crying out loud. -- -------------------------------------------------------------- from: Jonathan "Chromatix" Morton mail: chromi@cyberspace.org (not for attachments) website: http://www.chromatix.uklinux.net/vnc/ geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) tagline: The key to knowledge is not to rely on people to teach you it. From rg at tcslon.com Wed Dec 26 06:48:22 2001 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Services 5.0 alpha 10 released In-Reply-To: <3c2963d3.41711@achurch.org> Message-ID: > Okay, this will _really_ be the last release before I leave on > vacation, because I leave in about 15 minutes. (: Patches Ok, I'll queue some more bugs up in your inbox for when you return ;) memoserv/forward: /ms SET FORWARD [ON|OFF|COPY] doesn't work. Patch follows: modules/memoserv/forward.c: On line 152: } else if (stricmp(option, "ON") == 0) { should read: } else if (stricmp(param, "ON") == 0) { On line 156: } else if (stricmp(option, "COPY") == 0) { should read: } else if (stricmp(param, "COPY") == 0) { and on line 159: } else if (stricmp(option, "OFF") == 0) { should read: } else if (stricmp(param, "OFF") == 0) { memoserv/forward: After applying the above fix, /ms SET FORWARD [ON|COPY] returns the following: [14:11:26] Your memos will now be forwarded to your E-mail address: (null) regardless of which or whether an e-mail was set, although the actual forwarding works. Looks pretty simple to fix. Something to do with notice_lang not being told the e-mail I think. memoserv/forward: After applying the set forward fix, forwarded memo e-mails contain: Memo from (Dec 26 13:58:10 2001 GMT) without any name. Probably a similar problem to the above. nickserv/autojoin: Although the AJOIN command works a treat, it doesn't seem to appear on the /ns HELP COMMANDS list. Cheers, Russ Garrett (russ@garrett.co.uk) From rg at tcslon.com Wed Dec 26 09:20:54 2001 From: rg at tcslon.com (Russell Garrett) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] Yet more bugs In-Reply-To: <3c2963d3.41711@achurch.org> Message-ID: memoserv/main: The memo send confirmation messages appear when sending to some users, but not others. I'm not sure what determines this though. Every time, however, the memo is sent, just sometimes it isn't confirmed. Here is the fix for the missing e-mail address in the memoserv set forward message bug I reported earlier, if anyone wants it: /modules/memoserv/forward.c Line 155: notice_lang(s_MemoServ, u, MEMO_SET_FORWARD_ON); Change to: notice_lang(s_MemoServ, u, MEMO_SET_FORWARD_ON, u->ngi->email); Line 158: notice_lang(s_MemoServ, u, MEMO_SET_FORWARD_COPY); Change to: notice_lang(s_MemoServ, u, MEMO_SET_FORWARD_COPY, u->ngi->email); Russ Garrett (russ@garrett.co.uk) From dwd at buli.net Sat Dec 29 06:36:48 2001 From: dwd at buli.net (dwd@buli.net) Date: Sat Oct 23 23:09:12 2004 Subject: [IRCServices Coding] errors.log? Message-ID: Hi! errors.log: [Fri Dec 28 23:16:22 2001] - num - 1 What's this? Thanks: -- dwd ICQ#108548590 chat@dwdworld.net http://chat.dwdworld.net