1 From achurch at achurch.org Wed Jan 1 14:25:10 2003
2 From: achurch at achurch.org (Andrew Church)
3 Date: Sat Oct 23 23:09:47 2004
4 Subject: [IRCServices Coding] OperServ UPDATE suggestion
5 In-Reply-To: <012401c2aefc$9476a3f0$1400000a@patrick>
6 Message-ID: <3e127c4f.01335@crystal.achurch.org>
8 Use the Source, Luke. UPDATE (modules/operserv/main.c:do_update())
9 sets the global variable "save_data" to 1, which causes the main loop to
10 tell all modules to save their data. The do_save_data() in operserv/main.c
11 is only the OperServ part of that process, and only handles the OperServ
12 database for obvious reasons.
18 >This is a multi-part message in MIME format.
20 >--Boundary_(ID_iiHC64a6A6NdaLuY3JRsCA)
21 >Content-type: text/plain; charset=iso-8859-1
22 >Content-transfer-encoding: 7BIT
24 >I think it would be better when using OperServ UPDATE would update *all* databases. Correct me if I'm wrong, but it looks like it only updates the OperServ DB:
26 >modules/operserv/main.c:
29 >/* Callback for saving data. */
31 >static int do_save_data(void)
33 > sync_operserv_db(OperDBName);
38 >I tried to add this (with the appropriate static char's):
41 >/* Callback for saving data. */
43 >static int do_save_data(void)
45 > sync_channel_db(ChanDBName);
46 > sync_operserv_db(OperDBName);
47 > sync_statserv_db(StatDBName);
52 >and I couldn't get it to work.
62 >Outgoing mail is certified Virus Free.
63 >Checked by AVG anti-virus system (http://www.grisoft.com).
64 >Version: 6.0.427 / Virus Database: 240 - Release Date: 12/6/2002
66 >--Boundary_(ID_iiHC64a6A6NdaLuY3JRsCA)
67 >Content-type: text/html; charset=iso-8859-1
68 >Content-transfer-encoding: 7BIT
70 ><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
72 ><META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
73 ><META content="MSHTML 6.00.2800.1126" name=GENERATOR>
76 ><BODY bgColor=#ffffff>
77 ><DIV><FONT face=Arial size=2>I think it would be better when using OperServ
78 >UPDATE would update *all* databases. Correct me if I'm wrong, but it looks like
79 >it only updates the OperServ DB:</FONT></DIV>
80 ><DIV><FONT face=Arial size=2></FONT> </DIV>
81 ><DIV><FONT face=Arial size=2>modules/operserv/main.c:</FONT></DIV>
82 ><DIV><FONT face=Arial size=2></FONT> </DIV><FONT face=Arial size=2>
83 ><DIV><BR>/* Callback for saving data. */</DIV>
85 ><DIV>static int do_save_data(void)<BR>{<BR>
86 >sync_operserv_db(OperDBName);<BR> return 0;<BR>}<BR></DIV>
88 ><DIV>I tried to add this (with the appropriate static char's):</DIV>
90 ><DIV><BR>/* Callback for saving data. */</DIV>
92 ><DIV>static int do_save_data(void)<BR>{<BR>
93 >sync_channel_db(ChanDBName);<BR>
94 >sync_operserv_db(OperDBName);<BR>
95 >sync_statserv_db(StatDBName);<BR> return 0;<BR>}<BR></DIV>
97 ><DIV>and I couldn't get it to work.</DIV>
103 ><DIV>/Patrick Fish</DIV>
105 ><DIV><BR>---<BR>Outgoing mail is certified Virus Free.<BR>Checked by AVG
106 >anti-virus system (<A
107 >href="http://www.grisoft.com">http://www.grisoft.com</A>).<BR>Version: 6.0.427 /
108 >Virus Database: 240 - Release Date: 12/6/2002</DIV></FONT></BODY></HTML>
110 >--Boundary_(ID_iiHC64a6A6NdaLuY3JRsCA)--
111 >------------------------------------------------------------------
112 >To unsubscribe or change your subscription options, visit:
113 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
115 From achurch at achurch.org Wed Jan 1 14:29:44 2003
116 From: achurch at achurch.org (Andrew Church)
117 Date: Sat Oct 23 23:09:47 2004
118 Subject: [IRCServices Coding] TS3/4 Support
119 In-Reply-To: <1041162617.1021.3.camel@hermes.111balmoral.co.uk>
120 Message-ID: <3e127d42.01346@crystal.achurch.org>
122 >I'm working on monkeyircd's protocol module for services, and I've hit a
124 >As I understand it, in TS3 mode, when services loses its link/shuts
125 >down, it should send/receive QUITs for all the clients it handles. But
126 >in TS4 mode it just receives a SQUIT for the link lost, and then should
127 >calculate the QUITs and SQUITs that follow as a consequence.
129 This is already built in--look at the m_capab() handler in bahamut.c
136 From achurch at achurch.org Wed Jan 1 14:35:52 2003
137 From: achurch at achurch.org (Andrew Church)
138 Date: Sat Oct 23 23:09:47 2004
139 Subject: [IRCServices Coding] akill expire bug
140 In-Reply-To: <001701c2aea4$94c4f300$e577e518@msns.eph.ptd.net>
141 Message-ID: <3e127e42.01374@crystal.achurch.org>
143 Fixed, thanks for the report.
149 >Occasionally when several AKILLs expire at or around the same time, OperServ
152 >[14:06] -avalon.on.ca.zirc.org- *** Global -- from OperServ: AKILL on * has
154 >[14:06] -avalon.on.ca.zirc.org- *** Global -- from OperServ: AKILL on * has
156 >[14:06] -avalon.on.ca.zirc.org- *** Global -- from OperServ: AKILL on * has
158 >[14:06] -avalon.on.ca.zirc.org- *** Global -- from OperServ: AKILL on * has
160 >[14:06] -avalon.on.ca.zirc.org- *** Global -- from OperServ: AKILL on * has
163 >------------------------------------------------------------------
164 >To unsubscribe or change your subscription options, visit:
165 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
167 From chris at monkeyircd.org Wed Jan 1 11:33:25 2003
168 From: chris at monkeyircd.org (Chris Plant)
169 Date: Sat Oct 23 23:09:47 2004
170 Subject: [IRCServices Coding] TS3/4 Support
171 In-Reply-To: <3e127d42.01346@crystal.achurch.org>
172 References: <3e127d42.01346@crystal.achurch.org>
173 Message-ID: <1041449609.2796.1.camel@hermes.111balmoral.co.uk>
175 On Wed, 2003-01-01 at 14:29, Andrew Church wrote:
177 > This is already built in--look at the m_capab() handler in bahamut.c
179 Yeah, I didn't notice that, Bahamut uses NOQUIT, monkeyircd uses TS4 (in
181 Consider it fixed, and I've fixed some other niggles, I'll post you a
187 From ron885 at bloodheart.com Wed Jan 1 14:40:09 2003
188 From: ron885 at bloodheart.com (Ron)
189 Date: Sat Oct 23 23:09:47 2004
190 Subject: [IRCServices Coding] calling another module's callback
191 In-Reply-To: <3e0a89cb.66254@achurch.org>
192 References: <3e0a89cb.66254@achurch.org>
193 Message-ID: <200301011540.09988.ron885@bloodheart.com>
195 On Thursday 26 December 2002 06:33 am, Andrew Church wrote:
196 > No; the callback ID (necessary for calling the callback) is private to
197 > the NickServ module. What do you need to call it for?
199 well i know that callback basically returns a true/false if the given nick is
200 one of the services nicks... and i was thinking thats easier than if
201 irc_stricmp(nick, s_NickServ) etc...
204 From ron885 at bloodheart.com Wed Jan 1 17:04:37 2003
205 From: ron885 at bloodheart.com (Ron)
206 Date: Sat Oct 23 23:09:47 2004
207 Subject: [IRCServices Coding] local_set_cumodes
208 Message-ID: <200301011804.37810.ron885@bloodheart.com>
210 trying to understand some of this code...
212 was just curious as to something... in the function local_set_cumodes you do:
215 so that it fits 4 chars: 0 1 2 3
216 but you only use 3: 0 1 2
218 just a mistake or is there a reason for it?
222 From brain at brainbox.winbot.co.uk Wed Jan 1 17:10:12 2003
223 From: brain at brainbox.winbot.co.uk (Craig Edwards)
224 Date: Sat Oct 23 23:09:47 2004
225 Subject: [IRCServices Coding] local_set_cumodes
226 Message-ID: <200301020115.h021FQC19814@localhost.localdomain>
228 looks like the final byte is used for a null terminator?
232 >trying to understand some of this code...
234 >was just curious as to something... in the function local_set_cumodes you do:
237 >so that it fits 4 chars: 0 1 2 3
238 >but you only use 3: 0 1 2
240 >just a mistake or is there a reason for it?
243 >------------------------------------------------------------------
244 >To unsubscribe or change your subscription options, visit:
245 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
249 From patrick at pwhsnet.com Wed Jan 1 17:25:34 2003
250 From: patrick at pwhsnet.com (Patrick Fish)
251 Date: Sat Oct 23 23:09:47 2004
252 Subject: Fw: [IRCServices Coding] bahamut/Services crash
253 Message-ID: <005c01c2b1fd$e48ddda0$1400000a@patrick>
257 Update: Any time a server splits, this happens - doesn't have to be squit.
262 ----- Original Message -----
263 From: "Patrick Fish" <patrick@pwhsnet.com>
264 To: <ircservices-coding@ircservices.za.net>
265 Cc: <ircservices@ircservices.za.net>
266 Sent: Sunday, December 29, 2002 5:16 AM
267 Subject: [IRCServices Coding] bahamut/Services crash
270 | It seems IRCServices crashes every time a server gets squit:
276 | [05:14:01] -patrick.liveharmony.org- *** Routing -- from
277 | patrick.liveharmony.org: Received SQUIT patrick.dev.liveharmony.org from
278 | Patrick[(+)patrick@0.0.0.0] (Patrick)
279 | [05:14:01] -patrick.liveharmony.org- *** Notice --
280 | patrick.dev.liveharmony.org was connected for 11 seconds. 2/1
282 | [05:14:01] -patrick.liveharmony.org- *** Global -- from
283 | services.liveharmony.org: PANIC! buffer = SQUIT
284 patrick.dev.liveharmony.org
286 | [05:14:01] -patrick.liveharmony.org- *** Routing -- from
287 | patrick.liveharmony.org: Received SQUIT services.liveharmony.org from
288 | services.liveharmony.org[unknown@0.0.0.0] (Services terminating: Bus
290 | [05:14:01] -patrick.liveharmony.org- *** Notice --
291 services.liveharmony.org
292 | was connected for 749 seconds. 4/2 sendK/recvK.
293 | [05:14:01] * OperServ [service@liveharmony.org] has left IRC
296 | I cant find where the problem is. I'm running 5.0.6.
302 | patrick@pwhsnet.com
306 | Outgoing mail is certified Virus Free.
307 | Checked by AVG anti-virus system (http://www.grisoft.com).
308 | Version: 6.0.427 / Virus Database: 240 - Release Date: 12/6/2002
310 | ------------------------------------------------------------------
311 | To unsubscribe or change your subscription options, visit:
312 | http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
317 Outgoing mail is certified Virus Free.
318 Checked by AVG anti-virus system (http://www.grisoft.com).
319 Version: 6.0.435 / Virus Database: 244 - Release Date: 12/30/2002
322 From quension at softhome.net Wed Jan 1 17:45:56 2003
323 From: quension at softhome.net (Trevor Talbot)
324 Date: Sat Oct 23 23:09:47 2004
325 Subject: [IRCServices Coding] local_set_cumodes
326 In-Reply-To: <200301011804.37810.ron885@bloodheart.com>
327 Message-ID: <EFCBA7F2-1DF3-11D7-BE72-0003938D6866@softhome.net>
329 On Wednesday, Jan 1, 2003, at 17:04 US/Pacific, Ron wrote:
331 > was just curious as to something... in the function local_set_cumodes
335 > so that it fits 4 chars: 0 1 2 3
337 Might want to brush up on your C ;)
339 Array declarations are size-based: char buf[3] holds 3 chars.
340 Only indexing is zero-based.
345 From ron885 at bloodheart.com Wed Jan 1 17:50:25 2003
346 From: ron885 at bloodheart.com (Ron)
347 Date: Sat Oct 23 23:09:47 2004
348 Subject: [IRCServices Coding] local_set_cumodes
349 In-Reply-To: <EFCBA7F2-1DF3-11D7-BE72-0003938D6866@softhome.net>
350 References: <EFCBA7F2-1DF3-11D7-BE72-0003938D6866@softhome.net>
351 Message-ID: <200301011850.25135.ron885@bloodheart.com>
353 On Wednesday 01 January 2003 06:45 pm, Trevor Talbot wrote:
354 > Might want to brush up on your C ;)
356 > Array declarations are size-based: char buf[3] holds 3 chars.
357 > Only indexing is zero-based.
359 weee... hehe... thanks
361 From griever at t2n.org Thu Jan 2 02:20:37 2003
362 From: griever at t2n.org (Finny Merrill)
363 Date: Sat Oct 23 23:09:47 2004
364 Subject: [IRCServices Coding] local_set_cumodes
365 In-Reply-To: <200301011804.37810.ron885@bloodheart.com>
366 Message-ID: <Pine.LNX.4.44.0301020420030.30094-100000@linux.ircd-net.org>
368 On Wed, 1 Jan 2003, Ron wrote:
370 > trying to understand some of this code...
372 > was just curious as to something... in the function local_set_cumodes you do:
375 > so that it fits 4 chars: 0 1 2 3
376 > but you only use 3: 0 1 2
378 > just a mistake or is there a reason for it?
381 Jesus christ ron, are you snorting blocks?
383 char buf[3] declares 3 chars, buf[0], buf[1] and buf[2]
388 From prince at zirc.org Sun Jan 5 12:58:24 2003
389 From: prince at zirc.org (prince)
390 Date: Sat Oct 23 23:09:47 2004
391 Subject: [IRCServices Coding] This was supposed to be fixed.
392 Message-ID: <001801c2b4fd$30613e00$e577e518@msns.eph.ptd.net>
395 I thought you said the ...
397 "(-04:49-) (-notice:ChanServ-) Sorry, the CLEAR command is temporarily unavailable."
399 Was fixed in the last release of IRCServices? We're still having this problem, running 5.0.6. We only get this error message on certain commands, OP/DEOP/CLEAR/KICK. They work in some channels, in others they don't. I can assure you, all of our servers are configured correctly.
401 Also an update on the stylez trojan "clone" flooder, he hasn't attacked our network in a while yet, so I've gotten IRCServices recompiled and ready to restart in debug mode, just waiting for them to crash on their own for the restart. But please look into this matter about these unavailable commands, our network would very much appreciate it. :)
404 -------------- next part --------------
405 An HTML attachment was scrubbed...
406 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030105/580c1ec0/attachment.htm
407 From martin at e-tech.us Sun Jan 5 13:19:14 2003
408 From: martin at e-tech.us (Martin)
409 Date: Sat Oct 23 23:09:47 2004
410 Subject: [IRCServices Coding] This was supposed to be fixed.
411 In-Reply-To: <001801c2b4fd$30613e00$e577e518@msns.eph.ptd.net>
412 Message-ID: <009501c2b500$1fe9f910$1101a8c0@INETSERVER>
414 Yes, I still get this myself on occasion. /operserv restart and
415 everything's fine for a bit, but it eventually starts again.
419 -----Original Message-----
420 From: ircservices-coding-admin@ircservices.za.net
421 [mailto:ircservices-coding-admin@ircservices.za.net] On Behalf Of prince
422 Sent: Sunday, January 05, 2003 3:58 PM
423 To: ircservices-coding@ircservices.za.net
424 Subject: [IRCServices Coding] This was supposed to be fixed.
428 I thought you said the ...
430 "(-04:49-) (-notice:ChanServ-) Sorry, the CLEAR command is temporarily
433 Was fixed in the last release of IRCServices? We're still having
434 this problem, running 5.0.6. We only get this error message on certain
435 commands, OP/DEOP/CLEAR/KICK. They work in some channels, in others
436 they don't. I can assure you, all of our servers are configured
439 Also an update on the stylez trojan "clone" flooder, he hasn't
440 attacked our network in a while yet, so I've gotten IRCServices
441 recompiled and ready to restart in debug mode, just waiting for them to
442 crash on their own for the restart. But please look into this matter
443 about these unavailable commands, our network would very much appreciate
448 -------------- next part --------------
449 An HTML attachment was scrubbed...
450 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030105/92c91636/attachment.html
451 From cyberdems at wwirc.za.org Sun Jan 5 13:46:07 2003
452 From: cyberdems at wwirc.za.org (CyberDems)
453 Date: Sat Oct 23 23:09:47 2004
454 Subject: [IRCServices Coding] repeated bad pass on #
455 References: <009501c2b500$1fe9f910$1101a8c0@INETSERVER>
456 Message-ID: <001101c2b503$db754420$0100a8c0@dimitri>
458 MessageHey, i've noticed a lil' bug i think...
459 This is a reproduced version of the log, because I exited my mirc client
460 before i could copy and paste.
462 [00:00] -alpha.deltacore.za.org- *** Global -- from ChanServ: Warning:
463 Repeated bad password attempts for chan #chan.
465 It doesn't tell me what the nick is of the person causing the problems?
466 I'm running ircservices-5.0.6.
469 From RT.Mail at verizon.net Sun Jan 5 13:54:03 2003
470 From: RT.Mail at verizon.net (RT.Mail@verizon.net)
471 Date: Sat Oct 23 23:09:47 2004
472 Subject: [IRCServices Coding] This was supposed to be fixed.
473 In-Reply-To: <009501c2b500$1fe9f910$1101a8c0@INETSERVER>
474 Message-ID: <20030105215447.QLHJ16306.out005.verizon.net@bofh>
476 Thats the same problem I have with operserv when I try to op people with it, it stops working after a while. There was a similar
477 problem with chanserv not long ago that Andy did fix... but there does seem to be alot of features that stop working after a period
483 From aragon at phat.za.net Sun Jan 5 14:01:23 2003
484 From: aragon at phat.za.net (Aragon Gouveia)
485 Date: Sat Oct 23 23:09:48 2004
486 Subject: [IRCServices Coding] repeated bad pass on #
487 In-Reply-To: <001101c2b503$db754420$0100a8c0@dimitri>
488 References: <009501c2b500$1fe9f910$1101a8c0@INETSERVER> <001101c2b503$db754420$0100a8c0@dimitri>
489 Message-ID: <20030105220123.GE7964@phat.za.net>
491 Yea I've also noticed this. Does the same in 4.5.
494 | By CyberDems <cyberdems@wwirc.za.org>
495 | [ 2003-01-05 23:47 +0200 ]
496 > MessageHey, i've noticed a lil' bug i think...
497 > This is a reproduced version of the log, because I exited my mirc client
498 > before i could copy and paste.
500 > [00:00] -alpha.deltacore.za.org- *** Global -- from ChanServ: Warning:
501 > Repeated bad password attempts for chan #chan.
503 > It doesn't tell me what the nick is of the person causing the problems?
504 > I'm running ircservices-5.0.6.
506 > ------------------------------------------------------------------
507 > To unsubscribe or change your subscription options, visit:
508 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
510 From daan at devilish.xs4all.nl Sun Jan 5 14:19:50 2003
511 From: daan at devilish.xs4all.nl (daan@devilish.xs4all.nl)
512 Date: Sat Oct 23 23:09:48 2004
513 Subject: [IRCServices Coding] weird memoserv
514 In-Reply-To: <20030105220123.GE7964@phat.za.net>
515 References: <009501c2b500$1fe9f910$1101a8c0@INETSERVER>
516 <001101c2b503$db754420$0100a8c0@dimitri> <20030105220123.GE7964@phat.za.net>
517 Message-ID: <Pine.LNX.4.50.0301052309001.16823-100000@devilish.xs4all.nl>
519 I was strumbling along on the network when I came across memoserv,
520 this neat service only exchanges messages between users.
522 The question is, why does memoserv have +o. I cant think of any clear
523 purpose it requires +o for.
525 In the weird case that I overlooked a function, lemmie know.
534 From cij at ircchat.tk Sun Jan 5 14:32:46 2003
535 From: cij at ircchat.tk (Brian)
536 Date: Sat Oct 23 23:09:48 2004
537 Subject: [IRCServices Coding] This was supposed to be fixed.
538 Message-ID: <m18VJK2-00ETZtC@n1uro.com>
540 >Yes, I still get this myself on occasion. /operserv restart and
541 >everything's fine for a bit, but it eventually starts again.
543 This happens here too. It appears to be a time synch issue. When I join a
544 channel and the ircd gives me a synch warning, I can be rest assured that
545 some commands will fail unless I restart services...otherwise it's fine.
546 btw; I'm uing 5.0.6 on bahamut
549 Affordable Domain and Web Hosting: UROWeb http://www.n1uro.net
550 CT TCPIP Coordinator 44.88/18
551 Distribution and support site of MFNOS
552 ftp://ftp.n1uro.net/public/nos/mfnos
553 Founder: IRC CHAT TALK Network http://www.ircchat.tk
554 web: http://www.n1uro.com ftp: ftp.n1uro.com
555 Member of the Executive Guild's "Who's Who" for online services and
556 network technologies since 11/1999
562 From achurch at achurch.org Mon Jan 6 08:13:43 2003
563 From: achurch at achurch.org (Andrew Church)
564 Date: Sat Oct 23 23:09:48 2004
565 Subject: [IRCServices Coding] weird memoserv
566 In-Reply-To: <Pine.LNX.4.50.0301052309001.16823-100000@devilish.xs4all.nl>
567 Message-ID: <3e18bced.01771@crystal.achurch.org>
569 >I was strumbling along on the network when I came across memoserv,
570 >this neat service only exchanges messages between users.
572 >The question is, why does memoserv have +o. I cant think of any clear
573 >purpose it requires +o for.
575 This was added in version 3.0.4 to fix problems when running
576 straight RFC 1459 servers. It may not strictly be necessary, but I don't
577 see any problem with leaving it that way.
583 From achurch at achurch.org Mon Jan 6 08:17:40 2003
584 From: achurch at achurch.org (Andrew Church)
585 Date: Sat Oct 23 23:09:48 2004
586 Subject: [IRCServices Coding] This was supposed to be fixed.
587 In-Reply-To: <m18VJK2-00ETZtC@n1uro.com>
588 Message-ID: <3e18bd41.02001@crystal.achurch.org>
590 >>Yes, I still get this myself on occasion. /operserv restart and
591 >>everything's fine for a bit, but it eventually starts again.
593 >This happens here too. It appears to be a time synch issue. When I join a
594 >channel and the ircd gives me a synch warning, I can be rest assured that
595 >some commands will fail unless I restart services...otherwise it's fine.
596 >btw; I'm uing 5.0.6 on bahamut
598 This sounds like it might be a Bahamut bug with respect to U:lines.
599 What's the exact text of the synch warning?
605 From achurch at achurch.org Mon Jan 6 08:19:25 2003
606 From: achurch at achurch.org (Andrew Church)
607 Date: Sat Oct 23 23:09:48 2004
608 Subject: [IRCServices Coding] repeated bad pass on #
609 In-Reply-To: <001101c2b503$db754420$0100a8c0@dimitri>
610 Message-ID: <3e18bda2.02011@crystal.achurch.org>
612 >MessageHey, i've noticed a lil' bug i think...
613 >This is a reproduced version of the log, because I exited my mirc client
614 >before i could copy and paste.
616 >[00:00] -alpha.deltacore.za.org- *** Global -- from ChanServ: Warning:
617 >Repeated bad password attempts for chan #chan.
619 >It doesn't tell me what the nick is of the person causing the problems?
620 >I'm running ircservices-5.0.6.
622 This is designed behavior, but I agree that it could be improved.
628 From achurch at achurch.org Mon Jan 6 08:52:49 2003
629 From: achurch at achurch.org (Andrew Church)
630 Date: Sat Oct 23 23:09:48 2004
631 Subject: [IRCServices Coding] Unreal3.2-beta13 and the Unreal protocol
632 In-Reply-To: <200212141425.10005.r-krisztian@softhome.net>
633 Message-ID: <3e18c5c5.02134@crystal.achurch.org>
635 >Some things changed in beta13 which I don't know exactly that can cause a
636 >problem in IRCServices.
638 >* UNKLINE and UNZLINE have been removed in favor of a system like G:lines, to
639 >remove you now /kline -user@host or /zline -user@host
641 This only affects users, not Services.
643 >And this is a new one, don't know if it can be used in IRCServices:
645 >* SVSLUSERS was added to all U:lines to change local and global max user
647 > NOT meant so you can make the max count higher than it really should be.)
649 I'll think about this when Unreal 3.2 gets out of beta.
651 >Can you tell me if there would be errors if I use IRCServices with
654 There shouldn't be, but I haven't tested it myself.
660 From martin at e-tech.us Sun Jan 5 16:02:50 2003
661 From: martin at e-tech.us (Martin)
662 Date: Sat Oct 23 23:09:48 2004
663 Subject: [IRCServices Coding] This was supposed to be fixed.
664 In-Reply-To: <3e18bd41.02001@crystal.achurch.org>
665 Message-ID: <009c01c2b516$f9fc88a0$1101a8c0@INETSERVER>
667 I'm not on bahamut, I'm on unreal 3.2.13
669 -----Original Message-----
670 From: ircservices-coding-admin@ircservices.za.net
671 [mailto:ircservices-coding-admin@ircservices.za.net] On Behalf Of Andrew
673 Sent: Sunday, January 05, 2003 6:18 PM
674 To: ircservices-coding@ircservices.za.net
675 Subject: RE: [IRCServices Coding] This was supposed to be fixed.
678 >>Yes, I still get this myself on occasion. /operserv restart and
679 >>everything's fine for a bit, but it eventually starts again.
681 >This happens here too. It appears to be a time synch issue. When I join
683 >a channel and the ircd gives me a synch warning, I can be rest assured
684 >that some commands will fail unless I restart services...otherwise it's
686 >fine. btw; I'm uing 5.0.6 on bahamut
688 This sounds like it might be a Bahamut bug with respect to U:lines.
689 What's the exact text of the synch warning?
694 ------------------------------------------------------------------
695 To unsubscribe or change your subscription options, visit:
696 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
700 From achurch at achurch.org Mon Jan 6 09:07:17 2003
701 From: achurch at achurch.org (Andrew Church)
702 Date: Sat Oct 23 23:09:48 2004
703 Subject: [IRCServices Coding] Backup Services
704 In-Reply-To: <000001c2a7d7$c8d75e40$3d714fd9@thema>
705 Message-ID: <3e18c957.02146@crystal.achurch.org>
707 >I know I'm going to run into that RTFM FlamePit, but I tried and tried to
708 >understand how to run a backup Services, and I can't see it at all. Is it
710 >How can I make it so that if the main Services goes down, a backup can take
713 Services doesn't have the ability to do this built in; you'd have to
714 manually start up a copy of Services on another server. You could
715 partially automate the process by, say, having a bot that periodically
716 checks whether Services is still linked to the network, and if it
717 disappears, starts up another copy of Services on its own machine.
723 From achurch at achurch.org Mon Jan 6 14:47:22 2003
724 From: achurch at achurch.org (Andrew Church)
725 Date: Sat Oct 23 23:09:48 2004
726 Subject: Fw: [IRCServices Coding] bahamut/Services crash
727 In-Reply-To: <005c01c2b1fd$e48ddda0$1400000a@patrick>
728 Message-ID: <3e19189f.04153@crystal.achurch.org>
732 >Update: Any time a server splits, this happens - doesn't have to be squit.
734 I can't reproduce this. Can you send me a backtrace or debug log?
740 From achurch at achurch.org Mon Jan 6 14:48:38 2003
741 From: achurch at achurch.org (Andrew Church)
742 Date: Sat Oct 23 23:09:48 2004
743 Subject: [IRCServices Coding] calling another module's callback
744 In-Reply-To: <200301011540.09988.ron885@bloodheart.com>
745 Message-ID: <3e1919b2.04163@crystal.achurch.org>
747 >On Thursday 26 December 2002 06:33 am, Andrew Church wrote:
748 >> No; the callback ID (necessary for calling the callback) is privat
750 >> the NickServ module. What do you need to call it for?
752 >well i know that callback basically returns a true/false if the given nic
754 >one of the services nicks... and i was thinking thats easier than if
755 >irc_stricmp(nick, s_NickServ) etc...
757 Again, what would you need to know this for? If you want to know
758 whether a given nickname is a real user or not, one way is to just call
759 get_user() on the nick; Services' nicks aren't stored in the user table
760 (this really ought to be documented somewhere, but I'm too busy right now),
761 so you can differentiate between real users and (Services nicks + nicks not
768 From patrick at pwhsnet.com Sun Jan 5 22:08:53 2003
769 From: patrick at pwhsnet.com (Patrick Fish)
770 Date: Sat Oct 23 23:09:48 2004
771 Subject: Fw: [IRCServices Coding] bahamut/Services crash
772 References: <3e19189f.04153@crystal.achurch.org>
773 Message-ID: <001701c2b54a$16f0ea90$1400000a@patrick>
775 [Jan 05 22:03:33.342848 2003] debug: Loading language 0 from file
778 [Jan 05 22:03:33.623152 2003] debug: Loading language 10 from file
781 [Jan 05 22:03:33.907396 2003] debug: Loading language 6 from file
784 [Jan 05 22:03:34.194361 2003] debug: Loading language 9 from file
787 [Jan 05 22:03:34.482113 2003] debug: Loading language 11 from file
790 [Jan 05 22:03:34.767058 2003] debug: Loading language 8 from file
793 [Jan 05 22:03:34.874151 2003] debug: Loading language 2 from file
796 [Jan 05 22:03:35.152207 2003] debug: Loading language 3 from file
799 [Jan 05 22:03:35.430499 2003] debug: Loading language 5 from file
802 [Jan 05 22:03:35.587054 2003] debug: Loading language 4 from file
805 [Jan 05 22:03:35.871661 2003] debug: Loading language 7 from file
808 [Jan 05 22:03:36.152644 2003] debug: Loaded languages
810 [Jan 05 22:03:36.153293 2003] debug: Loading module `protocol/bahamut'
812 [Jan 05 22:03:36.156850 2003] debug: Successfully loaded module
815 [Jan 05 22:03:36.157462 2003] debug: Loading module `encryption/md5'
817 [Jan 05 22:03:36.162869 2003] debug: Successfully loaded module
820 [Jan 05 22:03:36.163464 2003] debug: Loading module `database/version4'
822 [Jan 05 22:03:36.171071 2003] debug: Successfully loaded module
825 [Jan 05 22:03:36.171705 2003] debug: Loading module `mail/main'
827 [Jan 05 22:03:36.174310 2003] debug: Successfully loaded module `mail/main'
829 [Jan 05 22:03:36.174922 2003] debug: Loading module `mail/smtp'
831 [Jan 05 22:03:36.177771 2003] debug: Successfully loaded module `mail/smtp'
833 [Jan 05 22:03:36.178358 2003] debug: Loading module `operserv/main'
835 [Jan 05 22:03:36.183289 2003] debug: Successfully loaded module
838 [Jan 05 22:03:36.183902 2003] debug: Loading module `operserv/akill'
840 [Jan 05 22:03:36.188664 2003] debug: Successfully loaded module
843 [Jan 05 22:03:36.189283 2003] debug: Loading module `operserv/sline'
845 [Jan 05 22:03:36.193665 2003] debug: Successfully loaded module
848 [Jan 05 22:03:36.194388 2003] debug: Loading module `nickserv/main'
850 [Jan 05 22:03:36.202341 2003] debug: Successfully loaded module
853 [Jan 05 22:03:36.202985 2003] debug: Loading module `nickserv/access'
855 [Jan 05 22:03:36.207122 2003] debug: Successfully loaded module
858 [Jan 05 22:03:36.208317 2003] debug: Loading module `nickserv/link'
860 [Jan 05 22:03:36.213670 2003] debug: Successfully loaded module
863 [Jan 05 22:03:36.214827 2003] debug: Loading module `nickserv/mail-auth'
865 [Jan 05 22:03:36.219697 2003] debug: Successfully loaded module
868 [Jan 05 22:03:36.221165 2003] debug: Loading module `chanserv/main'
870 [Jan 05 22:03:36.229862 2003] debug: Successfully loaded module
873 [Jan 05 22:03:36.231053 2003] debug: Loading module `chanserv/access-xop'
875 [Jan 05 22:03:36.237171 2003] debug: Successfully loaded module
876 `chanserv/access-xop'
878 [Jan 05 22:03:36.238869 2003] debug: Loading module `memoserv/main'
880 [Jan 05 22:03:36.244701 2003] debug: Successfully loaded module
883 [Jan 05 22:03:36.245864 2003] debug: Loading module `memoserv/forward'
885 [Jan 05 22:03:36.251647 2003] debug: Successfully loaded module
888 [Jan 05 22:03:36.252787 2003] debug: Loading module `memoserv/ignore'
890 [Jan 05 22:03:36.258129 2003] debug: Successfully loaded module
893 [Jan 05 22:03:36.259266 2003] debug: Loading module `statserv/main'
895 [Jan 05 22:03:36.265807 2003] debug: Successfully loaded module
898 [Jan 05 22:03:36.266954 2003] debug: Loading module `misc/helpserv'
900 [Jan 05 22:03:36.273016 2003] debug: Successfully loaded module
903 [Jan 05 22:03:36.274237 2003] debug: Loaded modules
905 [Jan 05 22:03:36.277824 2003] Initiated connection to 127.0.0.1:6667
907 [Jan 05 22:03:36.287163 2003] debug: Sent: PASS password :TS
909 [Jan 05 22:03:36.291903 2003] debug: Sent: CAPAB TS3 SSJOIN NICKIP NOQUIT
911 [Jan 05 22:03:36.293779 2003] debug: Sent: SERVER services.liveharmony.org 1
912 :liveHarmony Development Services
914 [Jan 05 22:03:36.295195 2003] debug: Sent: SVINFO 3 3 0 :1041833016
916 [Jan 05 22:03:36.296783 2003] debug: Sent: NICK OperServ 1 1041833016 +oi
917 service liveharmony.org services.liveharmony.org 0 0 :Operator Services
919 [Jan 05 22:03:36.298322 2003] debug: Sent: NICK Global 1 1041833016 +oi
920 service liveharmony.org services.liveharmony.org 0 0 :Global Noticer
922 [Jan 05 22:03:36.299530 2003] debug: Sent: NICK NickServ 1 1041833016 +o
923 service liveharmony.org services.liveharmony.org 0 0 :Nickname Services
925 [Jan 05 22:03:36.301211 2003] debug: Sent: NICK ChanServ 1 1041833016 +o
926 service liveharmony.org services.liveharmony.org 0 0 :Channel Services
928 [Jan 05 22:03:36.302418 2003] debug: Sent: NICK MemoServ 1 1041833016 +o
929 service liveharmony.org services.liveharmony.org 0 0 :Memo Services
931 [Jan 05 22:03:36.303886 2003] debug: Sent: NICK StatServ 1 1041833016 +i
932 service liveharmony.org services.liveharmony.org 0 0 :Statistics Services
934 [Jan 05 22:03:36.305085 2003] debug: Sent: NICK HelpServ 1 1041833016 +
935 service liveharmony.org services.liveharmony.org 0 0 :Help Services
937 [Jan 05 22:03:36.306639 2003] debug: Received: :patrick.liveharmony.org
938 NOTICE AUTH :*** Looking up your hostname...
940 [Jan 05 22:03:36.307782 2003] debug: Received: :patrick.liveharmony.org
941 NOTICE AUTH :*** Checking Ident
943 [Jan 05 22:03:36.308875 2003] debug: Received: :patrick.liveharmony.org
944 NOTICE AUTH :*** Found your hostname
946 [Jan 05 22:03:36.310252 2003] debug: Received: :patrick.liveharmony.org
947 NOTICE AUTH :*** No Ident response
949 [Jan 05 22:03:36.389936 2003] debug: Received: PASS password :TS
951 [Jan 05 22:03:36.395304 2003] debug: Received: CAPAB TS3 NOQUIT SSJOIN BURST
952 UNCONNECT ZIP NICKIP TSMODE
954 [Jan 05 22:03:36.396408 2003] debug: Received: SERVER
955 patrick.liveharmony.org 1 :Patrick's Development Server
957 [Jan 05 22:03:36.397711 2003] debug: Received: SVINFO 5 3 0 :1041833016
959 [Jan 05 22:03:36.398279 2003] debug: Received: :patrick.liveharmony.org
960 GNOTICE :Link with services.liveharmony.org[unknown@0.0.0.0] established: TS
963 [Jan 05 22:03:36.398859 2003] debug: Received: NICK Patrick 1 1041832554
964 +oiraA patrick patrick.pwhsnet.com patrick.liveharmony.org 2026195727
965 167772180 :Patrick Fish
967 [Jan 05 22:03:36.401046 2003] debug: new user: Patrick
969 [Jan 05 22:03:36.402187 2003] user: New maximum user count: 1
971 [Jan 05 22:03:36.403943 2003] debug: Sent: :NickServ NOTICE Patrick :This
972 nickname is registered and protected. If it is your nickname, type /msg
973 NickServ IDENTIFY password. Otherwise, please choose a different nickname.
975 [Jan 05 22:03:36.405425 2003] debug: Changing mode for Patrick to +oiraA
977 [Jan 05 22:03:36.407035 2003] debug: Sent: :services.liveharmony.org SVSMODE
980 [Jan 05 22:03:36.408256 2003] debug: Sent: :services.liveharmony.org SVSMODE
983 [Jan 05 22:03:36.409381 2003] debug: Received: PING :patrick.liveharmony.org
985 [Jan 05 22:03:36.410816 2003] debug: Sent: :services.liveharmony.org PONG
986 services.liveharmony.org patrick.liveharmony.org
988 [Jan 05 22:03:36.501718 2003] debug: Received: PING :patrick.liveharmony.org
990 [Jan 05 22:03:36.503203 2003] debug: Sent: :services.liveharmony.org PONG
991 services.liveharmony.org patrick.liveharmony.org
993 [Jan 05 22:03:36.507936 2003] debug: Received: PING :patrick.liveharmony.org
995 [Jan 05 22:03:36.509685 2003] debug: Sent: :services.liveharmony.org PONG
996 services.liveharmony.org patrick.liveharmony.org
998 [Jan 05 22:04:06.608203 2003] debug: Sent: PING :services.liveharmony.org
1000 [Jan 05 22:04:06.613477 2003] debug: Received: :patrick.liveharmony.org PONG
1001 patrick.liveharmony.org :services.liveharmony.org
1003 [Jan 05 22:04:36.708669 2003] debug: Sent: PING :services.liveharmony.org
1005 [Jan 05 22:04:36.714122 2003] debug: Received: :patrick.liveharmony.org PONG
1006 patrick.liveharmony.org :services.liveharmony.org
1008 [Jan 05 22:04:44.051024 2003] debug: Received: :patrick.liveharmony.org
1009 GNOTICE :Link with patrick.dev.liveharmony.org[unknown@0.0.0.0] established:
1012 [Jan 05 22:04:44.051708 2003] debug: Received: :patrick.liveharmony.org
1013 SERVER patrick.dev.liveharmony.org 2 :Patrick's Development Debug Server
1015 [Jan 05 22:04:44.149165 2003] debug: Received: :patrick.dev.liveharmony.org
1016 GNOTICE :Link with patrick.liveharmony.org[unknown@0.0.0.0] established: TS
1019 [Jan 05 22:04:44.248937 2003] debug: Received: :patrick.liveharmony.org
1020 GNOTICE :patrick.dev.liveharmony.org has synched to network data.
1022 [Jan 05 22:04:44.249619 2003] debug: Received: :patrick.liveharmony.org
1023 GNOTICE :synch to patrick.dev.liveharmony.org in 1 sec at 0 sendq
1025 [Jan 05 22:04:44.250203 2003] debug: Received: :patrick.dev.liveharmony.org
1026 GNOTICE :synch to patrick.liveharmony.org in 1 sec at 0 sendq
1028 [Jan 05 22:05:00.100364 2003] debug: Received: :patrick.liveharmony.org
1029 GNOTICE :Received SQUIT patrick.dev.liveharmony.org from
1030 Patrick[(+)patrick@0.0.0.0] (Patrick)
1032 [Jan 05 22:05:00.101054 2003] debug: Received: SQUIT
1033 patrick.dev.liveharmony.org :Patrick
1035 [Jan 05 22:05:00.101743 2003] PANIC! buffer = SQUIT
1036 patrick.dev.liveharmony.org :Patrick
1038 [Jan 05 22:05:00.106841 2003] debug: Sent: :services.liveharmony.org GLOBOPS
1039 :PANIC! buffer = SQUIT patrick.dev.liveharmony.org :Patrick
1041 [Jan 05 22:05:00.107611 2003] Services terminating: Bus error
1043 [Jan 05 22:05:00.114827 2003] debug: Sent: :services.liveharmony.org SQUIT
1044 services.liveharmony.org :Services terminating: Bus error
1048 Didn't create a core.
1051 ----- Original Message -----
1052 From: "Andrew Church" <achurch@achurch.org>
1053 To: <ircservices-coding@ircservices.za.net>
1054 Sent: Sunday, January 05, 2003 9:47 PM
1055 Subject: Re: Fw: [IRCServices Coding] bahamut/Services crash
1060 > >Update: Any time a server splits, this happens - doesn't have to be
1063 > I can't reproduce this. Can you send me a backtrace or debug log?
1066 > achurch@achurch.org
1067 > http://achurch.org/
1068 > ------------------------------------------------------------------
1069 > To unsubscribe or change your subscription options, visit:
1070 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
1075 Outgoing mail is certified Virus Free.
1076 Checked by AVG anti-virus system (http://www.grisoft.com).
1077 Version: 6.0.435 / Virus Database: 244 - Release Date: 12/30/2002
1080 From RT.Mail at verizon.net Mon Jan 6 01:03:47 2003
1081 From: RT.Mail at verizon.net (RT.Mail@verizon.net)
1082 Date: Sat Oct 23 23:09:48 2004
1083 Subject: [IRCServices Coding] This was supposed to be fixed.
1084 In-Reply-To: <3e18bd41.02001@crystal.achurch.org>
1085 Message-ID: <20030106090431.CDYM4558.pop018.verizon.net@bofh>
1089 < >On Mon, 06 Jan 2003 08:17:40 JST, Andrew Church wrote:
1090 < > >>Yes, I still get this myself on occasion. /operserv restart and
1091 < > >>everything's fine for a bit, but it eventually starts again.
1093 < > >This happens here too. It appears to be a time synch issue.
1095 < > >channel and the ircd gives me a synch warning, I can be rest
1097 < > >some commands will fail unless I restart services...otherwise
1099 < > >btw; I'm uing 5.0.6 on bahamut
1101 < > This sounds like it might be a Bahamut bug with respect to
1103 < > What's the exact text of the synch warning?
1106 < > achurch@achurch.org
1107 < > http://achurch.org/
1108 < > -----------------------------------------------------------------
1110 < > To unsubscribe or change your subscription options, visit:
1111 < > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
1116 From laser at musichat.net Mon Jan 6 02:52:52 2003
1117 From: laser at musichat.net (Ciappei Alessandro (las3r))
1118 Date: Sat Oct 23 23:09:48 2004
1119 Subject: [IRCServices Coding] Idea for services
1120 In-Reply-To: <20030106100002.44782.80000.Mailman@snow.fingers.co.za>
1121 Message-ID: <5.2.0.9.2.20030106114647.034acde8@mail.musichat.net>
1126 my idea, is that to be able to send an email and a global memo to everybody
1127 the recorded nick, for particular events, as for example, the move of a
1128 server or the upgrade of the software.
1129 In this way all the user also those not connected they will know what is
1130 happening, in case of a possible malfunction owed to a wanted technical
1136 -----------------------------------------------------------------------------
1137 Chi riceve il presente messaggio e` tenuto a verificare se lo stesso non gli
1138 sia pervenuto per errore. In tal caso e` pregato di avvisare immediatamente
1139 il mittente e, tenuto conto delle responsabilita` connesse all'indebito
1140 utilizzo e/o divulgazione del messaggio e/o delle informazioni in esso
1141 contenute, voglia cancellare l'originale e distruggere le varie copie o
1144 The receiver of this message is required to check if he/she has received it
1145 erroneously. If so, the receiver is requested to immediately inform the
1146 sender and - in consideration of the responsibilities arising from undue use
1147 and/or disclosure of the message and/or the information contained therein -
1148 destroy the original message and any copy or printout thereof.
1149 -----------------------------------------------------------------------------
1152 From ballsy at mystical.net Mon Jan 6 05:07:18 2003
1153 From: ballsy at mystical.net (Ballsy)
1154 Date: Sat Oct 23 23:09:48 2004
1155 Subject: [IRCServices Coding] Idea for services
1156 In-Reply-To: <5.2.0.9.2.20030106114647.034acde8@mail.musichat.net>
1157 Message-ID: <Pine.LNX.4.44.0301060804270.10962-100000@david.mail.net>
1159 This sounds to me like something an external mailing list would
1160 handle quite well. For example, users@yourdomain.com would be a mailing
1161 list that all users could (optionally) subscribe to, and you could send
1162 any notices out that way. Might I recommend Mailman (www.list.org) as a
1163 decent mailing list manager.
1168 Quoth Ciappei Alessandro (las3r) on Jan 6 at 11:52,
1174 > my idea, is that to be able to send an email and a global memo to everybody
1175 > the recorded nick, for particular events, as for example, the move of a
1176 > server or the upgrade of the software.
1177 > In this way all the user also those not connected they will know what is
1178 > happening, in case of a possible malfunction owed to a wanted technical
1184 > -----------------------------------------------------------------------------
1185 > Chi riceve il presente messaggio e` tenuto a verificare se lo stesso non gli
1186 > sia pervenuto per errore. In tal caso e` pregato di avvisare immediatamente
1187 > il mittente e, tenuto conto delle responsabilita` connesse all'indebito
1188 > utilizzo e/o divulgazione del messaggio e/o delle informazioni in esso
1189 > contenute, voglia cancellare l'originale e distruggere le varie copie o
1192 > The receiver of this message is required to check if he/she has received it
1193 > erroneously. If so, the receiver is requested to immediately inform the
1194 > sender and - in consideration of the responsibilities arising from undue use
1195 > and/or disclosure of the message and/or the information contained therein -
1196 > destroy the original message and any copy or printout thereof.
1197 > -----------------------------------------------------------------------------
1199 > ------------------------------------------------------------------
1200 > To unsubscribe or change your subscription options, visit:
1201 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
1205 From ron885 at bloodheart.com Mon Jan 6 12:16:01 2003
1206 From: ron885 at bloodheart.com (Ron)
1207 Date: Sat Oct 23 23:09:48 2004
1208 Subject: [IRCServices Coding] calling another module's callback
1209 In-Reply-To: <3e1919b2.04163@crystal.achurch.org>
1210 References: <200301011540.09988.ron885@bloodheart.com>
1211 <3e1919b2.04163@crystal.achurch.org>
1212 Message-ID: <20030106131601.168c1fbf.ron885@bloodheart.com>
1214 On Mon, 06 Jan 2003 14:48:38 JST, achurch@achurch.org (Andrew Church) wrote:
1215 > Again, what would you need to know this for? If you want to know
1216 > whether a given nickname is a real user or not, one way is to just call
1217 > get_user() on the nick; Services' nicks aren't stored in the user table
1218 > (this really ought to be documented somewhere, but I'm too busy right now),
1219 > so you can differentiate between real users and (Services nicks + nicks not
1222 i just wanted to know if a given nick is one of service's nicks... chanserv memoserv nickserv etc... it might be a real user's nick... it might be a nick not of a user
1224 From thebeast at xs4all.nl Mon Jan 6 13:01:52 2003
1225 From: thebeast at xs4all.nl (thebeast)
1226 Date: Sat Oct 23 23:09:48 2004
1227 Subject: [IRCServices Coding] Backup Services
1228 In-Reply-To: <3e18c957.02146@crystal.achurch.org>
1229 Message-ID: <002b01c2b5c6$d79f7960$0201000a@thebeastnet>
1232 >>I know I'm going to run into that RTFM FlamePit, but I tried and tried to
1233 >>understand how to run a backup Services, and I can't see it at all. Is it
1235 >>How can I make it so that if the main Services goes down, a backup can
1239 > Services doesn't have the ability to do this built in; you'd have to
1240 >manually start up a copy of Services on another server. You could
1241 >partially automate the process by, say, having a bot that periodically
1242 >checks whether Services is still linked to the network, and if it
1243 >disappears, starts up another copy of Services on its own machine.
1245 Whe have already created a small script to downloading the xml dump from the
1247 ircservices and that create a complet new database on the backup
1249 and working great for us the backup ircservices must we start by hand
1250 to exclude that the backupservices will start with a small netsplit and so
1252 not can't connect again.
1253 if you are intrested for the script mail me and i will send it to you Andrew
1259 From saturn at jetirc.net Mon Jan 6 13:59:04 2003
1260 From: saturn at jetirc.net (Saturn)
1261 Date: Sat Oct 23 23:09:48 2004
1262 Subject: [IRCServices Coding] Backup Idea...?
1263 References: <002b01c2b5c6$d79f7960$0201000a@thebeastnet>
1264 Message-ID: <000901c2b5ce$d49ffb60$316419ac@caphealth.org>
1266 An Idea... any chance of some sort of built in log/database backup
1267 function -- something that makes a daily automatic backup copy of the
1268 databases and that day's log (dated), and stuffs it into a designated
1269 location (like some other backup dir) or even better, can auto-FTP send it
1270 to another machine? I know this is something above and beyond the call of
1271 duty for Services, but it would sure make catastrophic failures of the
1272 primary machine more bearable...
1274 Just a thought... meanwhile, anyone know of a linux utility that can be bent
1275 into an automatic FTP send of files to a remote FTP server? Maybe via a
1283 From ballsy at mystical.net Mon Jan 6 14:11:55 2003
1284 From: ballsy at mystical.net (Ballsy)
1285 Date: Sat Oct 23 23:09:48 2004
1286 Subject: [IRCServices Coding] Backup Idea...?
1287 In-Reply-To: <000901c2b5ce$d49ffb60$316419ac@caphealth.org>
1288 Message-ID: <Pine.LNX.4.44.0301061703130.10962-100000@david.mail.net>
1290 It seems to me the question with respect to
1291 auto-backups via Services has come up on this list before, and I think the
1292 general concensus was that it should be done by the services
1293 administrator via small scripts in cron, etc.
1294 As for your idea about the auto-FTP'ing stuff, I used to do
1295 something very similar. Without giving away all the fun, it went
1296 something like this...
1298 1) create a file (chmod 600) containing all the FTP commands you'd like to
1299 issue....for example, assuming you're connecting to the services shell
1300 from some other unix machine....
1302 user usernamehere passwordhere
1303 cd servicesdir/data/
1307 2) now, you just issue the following, which pipes the commands above into
1308 the interactive FTP command....
1309 `cat filefromabove | ftp -in services.hostname.com`
1311 3) you can now tar/gzip the newly downloaded .dbs
1313 Naturally, you could have done this the opposite way, where you
1314 ftp TO a remote host FROM the services shell itself. Take your pick.
1315 If available, it would obviously be more secure to use the `scp`
1316 command from the SSH package to do secure transfers. These are even
1317 easier to automate, as you can avoid passwords by employing authorized
1323 Quoth Saturn on Jan 6 at 13:59,
1325 > An Idea... any chance of some sort of built in log/database backup
1326 > function -- something that makes a daily automatic backup copy of the
1327 > databases and that day's log (dated), and stuffs it into a designated
1328 > location (like some other backup dir) or even better, can auto-FTP send it
1329 > to another machine? I know this is something above and beyond the call of
1330 > duty for Services, but it would sure make catastrophic failures of the
1331 > primary machine more bearable...
1333 > Just a thought... meanwhile, anyone know of a linux utility that can be bent
1334 > into an automatic FTP send of files to a remote FTP server? Maybe via a
1341 > ------------------------------------------------------------------
1342 > To unsubscribe or change your subscription options, visit:
1343 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
1347 From Craig at chatspike.net Mon Jan 6 16:57:18 2003
1348 From: Craig at chatspike.net (Craig McLure)
1349 Date: Sat Oct 23 23:09:48 2004
1350 Subject: [IRCServices Coding] Backup Idea...?
1351 Message-ID: <20030107005403.WQJN20174.mta06-svc.ntlworld.com@i-br0ked-it>
1355 I cant really see services needing this, especially when its easier and possibly more configurable to use a crontab and a small script.
1357 -----------------------------------------------------------------------
1358 Craig McLure - Craig@chatspike.net
1359 ChatSpike - The users network: http://www.chatspike.net
1360 InspIRCd - Modular IRC server: http://www.inspircd.org
1361 -----------------------------------------------------------------------
1364 ============ Original Message ============
1365 From aragon at phat.za.net Tue Jan 7 00:16:54 2003
1366 From: aragon at phat.za.net (Aragon Gouveia)
1367 Date: Sat Oct 23 23:09:48 2004
1368 Subject: [IRCServices Coding] Backup Idea...?
1369 In-Reply-To: <000901c2b5ce$d49ffb60$316419ac@caphealth.org>
1370 References: <002b01c2b5c6$d79f7960$0201000a@thebeastnet> <000901c2b5ce$d49ffb60$316419ac@caphealth.org>
1371 Message-ID: <20030107081654.GD87331@phat.za.net>
1373 This kind of thing is best left upto shell scripts. I'd highly recommend
1374 using rsync over FTP for two reasons:
1376 1. It's secure. All file transfers are performed over ssh by default.
1378 2. It uses a differential algorithm so as to only transfer the incremental
1379 differences between files across the network, hence saving *alot* of
1380 bandwidth and making the backup procedure very quick.
1387 | By Saturn <saturn@jetirc.net>
1388 | [ 2003-01-07 00:00 +0200 ]
1389 > An Idea... any chance of some sort of built in log/database backup
1390 > function -- something that makes a daily automatic backup copy of the
1391 > databases and that day's log (dated), and stuffs it into a designated
1392 > location (like some other backup dir) or even better, can auto-FTP send it
1393 > to another machine? I know this is something above and beyond the call of
1394 > duty for Services, but it would sure make catastrophic failures of the
1395 > primary machine more bearable...
1397 > Just a thought... meanwhile, anyone know of a linux utility that can be bent
1398 > into an automatic FTP send of files to a remote FTP server? Maybe via a
1403 From laser at musichat.net Tue Jan 7 04:29:32 2003
1404 From: laser at musichat.net (laser@musichat.net)
1405 Date: Sat Oct 23 23:09:48 2004
1406 Subject: [IRCServices Coding] Idea fo services
1407 In-Reply-To: <20030107100009.23456.71141.Mailman@snow.fingers.co.za>
1408 References: <20030107100009.23456.71141.Mailman@snow.fingers.co.za>
1409 Message-ID: <20030107122932.26389.qmail@ns.myhost.it>
1411 Yes, would work as a mailinglist.
1412 However my idea was that to include all email address of the recorded nick
1413 in an inside mailinglist to the serviceses.
1416 1) to insert to hand all the emails from the serviceses admin
1417 2) to wait that the people are undersigned to a possible external
1422 > This sounds to me like something an external mailing list would
1423 > handle quite well. For example, users@yourdomain.com would be a mailing
1424 > list that all users could (optionally) subscribe to, and you could send
1425 > any notices out that way. Might I recommend Mailman (www.list.org) as a
1426 > decent mailing list manager.
1431 > Quoth Ciappei Alessandro (las3r) on Jan 6 at 11:52,
1437 >> my idea, is that to be able to send an email and a global memo to everybody
1438 >> the recorded nick, for particular events, as for example, the move of a
1439 >> server or the upgrade of the software.
1440 >> In this way all the user also those not connected they will know what is
1441 >> happening, in case of a possible malfunction owed to a wanted technical
1447 >> -----------------------------------------------------------------------------
1448 >> Chi riceve il presente messaggio e` tenuto a verificare se lo stesso non gli
1449 >> sia pervenuto per errore. In tal caso e` pregato di avvisare immediatamente
1450 >> il mittente e, tenuto conto delle responsabilita` connesse all'indebito
1451 >> utilizzo e/o divulgazione del messaggio e/o delle informazioni in esso
1452 >> contenute, voglia cancellare l'originale e distruggere le varie copie o
1455 >> The receiver of this message is required to check if he/she has received it
1456 >> erroneously. If so, the receiver is requested to immediately inform the
1457 >> sender and - in consideration of the responsibilities arising from undue use
1458 >> and/or disclosure of the message and/or the information contained therein -
1459 >> destroy the original message and any copy or printout thereof.
1460 >> -----------------------------------------------------------------------------
1462 From martinpels at hotmail.com Tue Jan 7 04:52:55 2003
1463 From: martinpels at hotmail.com (Martin Pels)
1464 Date: Sat Oct 23 23:09:48 2004
1465 Subject: [IRCServices Coding] Idea fo services
1466 Message-ID: <F57Iwa3MIoFFfLdRlKN0000dd58@hotmail.com>
1468 Some people would consider that as spam...
1471 >Yes, would work as a mailinglist.
1472 >However my idea was that to include all email address of the recorded nick
1473 >in an inside mailinglist to the serviceses.
1476 >1) to insert to hand all the emails from the serviceses admin
1477 >2) to wait that the people are undersigned to a possible external
1482 >> This sounds to me like something an external mailing list would handle
1483 >>quite well. For example, users@yourdomain.com would be a mailing list
1484 >>that all users could (optionally) subscribe to, and you could send any
1485 >>notices out that way. Might I recommend Mailman (www.list.org) as a
1486 >>decent mailing list manager.
1491 >>Quoth Ciappei Alessandro (las3r) on Jan 6 at 11:52,
1497 >>>my idea, is that to be able to send an email and a global memo to
1498 >>>everybody the recorded nick, for particular events, as for example, the
1499 >>>move of a server or the upgrade of the software.
1500 >>>In this way all the user also those not connected they will know what is
1501 >>>happening, in case of a possible malfunction owed to a wanted technical
1507 >>>-----------------------------------------------------------------------------
1508 >>>Chi riceve il presente messaggio e` tenuto a verificare se lo stesso non
1510 >>>sia pervenuto per errore. In tal caso e` pregato di avvisare
1512 >>>il mittente e, tenuto conto delle responsabilita` connesse
1514 >>>utilizzo e/o divulgazione del messaggio e/o delle informazioni in
1516 >>>contenute, voglia cancellare l'originale e distruggere le varie
1520 >>>The receiver of this message is required to check if he/she has
1522 >>>erroneously. If so, the receiver is requested to immediately inform
1524 >>>sender and - in consideration of the responsibilities arising from undue
1526 >>>and/or disclosure of the message and/or the information contained
1528 >>>destroy the original message and any copy or printout thereof.
1529 >>>-----------------------------------------------------------------------------
1530 >------------------------------------------------------------------
1531 >To unsubscribe or change your subscription options, visit:
1532 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
1535 _________________________________________________________________
1536 Protect your PC - get McAfee.com VirusScan Online
1537 http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
1540 From laser at musichat.net Wed Jan 8 02:13:50 2003
1541 From: laser at musichat.net (laser@musichat.net)
1542 Date: Sat Oct 23 23:09:48 2004
1543 Subject: [IRCServices Coding] idea for services
1544 In-Reply-To: <20030108100011.99840.29095.Mailman@snow.fingers.co.za>
1545 References: <20030108100011.99840.29095.Mailman@snow.fingers.co.za>
1546 Message-ID: <20030108101350.28568.qmail@ns.myhost.it>
1548 Some people could also see it as spam,
1549 but according to me, to be able to tell own users on things of the net IRC,
1550 would be excellent, if then, an admin wants, can take the emails from the
1551 infos of the nick and to make themselves a ml to make spam. But all
1552 intelligence of every person is not to misuse.
1555 in these days in my net we are moving the servers, and this will cause some
1556 poor service, wanting to tell all, also those that don't enter for reading
1557 the global notices or the messages of logon I am not able, causing so a
1558 further poor service
1560 This is then one idea of mine fairies you.
1566 > However my idea was that to include all email address of the recorded nick
1567 > in an inside mailinglist to the serviceses.
1568 > This way we avoid:
1570 > 1) to insert to hand all the emails from the serviceses admin
1571 > 2) to wait that the people are undersigned to a possible external
1576 >> This sounds to me like something an external mailing list would
1577 >> handle quite well. For example, users@yourdomain.com would be a mailing
1578 >> list that all users could (optionally) subscribe to, and you could send
1579 >> any notices out that way. Might I recommend Mailman (www.list.org) as a
1580 >> decent mailing list manager.
1585 >> Quoth Ciappei Alessandro (las3r) on Jan 6 at 11:52,
1591 >>> my idea, is that to be able to send an email and a global memo to everybody
1592 >>> the recorded nick, for particular events, as for example, the move of a
1593 >>> server or the upgrade of the software.
1594 >>> In this way all the user also those not connected they will know what is
1595 >>> happening, in case of a possible malfunction owed to a wanted technical
1601 >>> -----------------------------------------------------------------------------
1602 >>> Chi riceve il presente messaggio e` tenuto a verificare se lo stesso non gli
1603 >>> sia pervenuto per errore. In tal caso e` pregato di avvisare immediatamente
1604 >>> il mittente e, tenuto conto delle responsabilita` connesse all'indebito
1605 >>> utilizzo e/o divulgazione del messaggio e/o delle informazioni in esso
1606 >>> contenute, voglia cancellare l'originale e distruggere le varie copie o
1609 >>> The receiver of this message is required to check if he/she has received it
1610 >>> erroneously. If so, the receiver is requested to immediately inform the
1611 >>> sender and - in consideration of the responsibilities arising from undue use
1612 >>> and/or disclosure of the message and/or the information contained therein -
1613 >>> destroy the original message and any copy or printout thereof.
1614 >>> -----------------------------------------------------------------------------
1619 > From: "Martin Pels" <martinpels@hotmail.com>
1620 > To: ircservices-coding@ircservices.za.net
1621 > Subject: Re: [IRCServices Coding] Idea fo services
1622 > Date: Tue, 07 Jan 2003 13:52:55 +0100
1623 > Reply-To: ircservices-coding@ircservices.za.net
1625 > Some people would consider that as spam...
1628 >>Yes, would work as a mailinglist.
1629 >>However my idea was that to include all email address of the recorded nick
1630 >>in an inside mailinglist to the serviceses.
1631 >>This way we avoid:
1633 >>1) to insert to hand all the emails from the serviceses admin
1634 >>2) to wait that the people are undersigned to a possible external
1639 >>> This sounds to me like something an external mailing list would handle
1640 >>>quite well. For example, users@yourdomain.com would be a mailing list
1641 >>>that all users could (optionally) subscribe to, and you could send any
1642 >>>notices out that way. Might I recommend Mailman (www.list.org) as a
1643 >>>decent mailing list manager.
1648 >>>Quoth Ciappei Alessandro (las3r) on Jan 6 at 11:52,
1654 >>>>my idea, is that to be able to send an email and a global memo to
1655 >>>>everybody the recorded nick, for particular events, as for example, the
1656 >>>>move of a server or the upgrade of the software.
1657 >>>>In this way all the user also those not connected they will know what is
1658 >>>>happening, in case of a possible malfunction owed to a wanted technical
1665 From thebeast at xs4all.nl Thu Jan 9 12:16:32 2003
1666 From: thebeast at xs4all.nl (thebeast)
1667 Date: Sat Oct 23 23:09:48 2004
1668 Subject: [IRCServices Coding] idea for xml part
1669 Message-ID: <004101c2b81c$011d7ce0$0201000a@thebeastnet>
1673 just a idea is it possible to add a extra option in the
1674 xml dump that write the current version of the ircservices
1677 i thinking to use it than to grep this part from the xml file
1678 and check this with the current version on the backup server
1679 so that this can start a update script that will update that
1680 server if the versions are different
1683 the version check can also be used for newer release that have
1684 newer/beter options that are not in the older versions so
1685 the --import commandline option can check if the xml dump
1686 is suitable for that version of ircservices
1691 From griever at t2n.org Fri Jan 10 12:57:40 2003
1692 From: griever at t2n.org (Finny Merrill)
1693 Date: Sat Oct 23 23:09:48 2004
1694 Subject: [IRCServices Coding] Idea
1695 Message-ID: <Pine.LNX.4.44.0301101456410.9292-100000@linux.ircd-net.org>
1697 We should have an operserv command that resets modecount/bouncy_modes etc
1698 for a certain channel (or a chanserv command).
1700 Right now the only way to fix it is to restart services, which is really
1704 From ellaaa-adv at mailbox.gr Wed Jan 15 08:49:27 2003
1705 From: ellaaa-adv at mailbox.gr (ellaaa-adv@mailbox.gr)
1706 Date: Sat Oct 23 23:09:48 2004
1707 Subject: [IRCServices Coding] Snoop How-To?
1708 Message-ID: <200301151649.SAA06001@mailbox.gr>
1710 Can someone please help me to create a snoop module in IRC services or hack the nick/chan/oper servers so it send all commands in a channel?
1714 I really need this! :)
1721 ______________________________________________________________________
1722 http://www.mailbox.gr ÁðïêôÞóôå äùñåÜí ôï ìïíáäéêü óáò e-mail.
1723 http://www.thesuperweb.gr ÁðïêôÞóôå ôï äéêü óáò web site ìüíï ìå 6 Euro!
1725 From p_levesque at sympatico.ca Wed Jan 15 09:24:15 2003
1726 From: p_levesque at sympatico.ca (Philippe Levesque)
1727 Date: Sat Oct 23 23:09:48 2004
1728 Subject: [IRCServices Coding] Snoop How-To?
1729 References: <200301151649.SAA06001@mailbox.gr>
1730 Message-ID: <000501c2bcba$edaea5a0$0200a8c0@philpower>
1732 Heh, it's soo easy to do, but i dont see the point of that, just log it to
1733 file, and check if someone abuse <period>
1735 ----- Original Message -----
1736 From: <ellaaa-adv@mailbox.gr>
1737 To: <ircservices-coding@ircservices.za.net>
1738 Sent: Wednesday, January 15, 2003 11:49 AM
1739 Subject: [IRCServices Coding] Snoop How-To?
1742 > Can someone please help me to create a snoop module in IRC services or
1743 hack the nick/chan/oper servers so it send all commands in a channel?
1747 > I really need this! :)
1751 > Ph33rTheCuteOnes...
1754 > ______________________________________________________________________
1755 > http://www.mailbox.gr ????????? ?????? ?? ???????? ??? e-mail.
1756 > http://www.thesuperweb.gr ????????? ?? ???? ??? web site ???? ?? 6 Euro!
1757 > ------------------------------------------------------------------
1758 > To unsubscribe or change your subscription options, visit:
1759 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
1762 From brain at brainbox.winbot.co.uk Wed Jan 15 09:59:32 2003
1763 From: brain at brainbox.winbot.co.uk (Craig Edwards)
1764 Date: Sat Oct 23 23:09:49 2004
1765 Subject: [IRCServices Coding] Snoop How-To?
1766 Message-ID: <200301151759.h0FHxji25034@localhost.localdomain>
1768 IRCServices doesnt yet seem to log a lot of the user commands. It would be really good if there was a mask in the config file to tell it to log user commands such as /cs access modifications etc. At present as far as ive noticed it only shows identify and invalid password etc, the kind of stuff you'd see in globops messages from services.*. wasnt there a discussion on this feature before and possibility of implementing it? I would certainly use a feature that could log user access changes to channels, to resolve issues and disputes.
1770 >Heh, it's soo easy to do, but i dont see the point of that, just log it to
1771 >file, and check if someone abuse <period>
1773 >----- Original Message -----
1774 >From: <ellaaa-adv@mailbox.gr>
1775 >To: <ircservices-coding@ircservices.za.net>
1776 >Sent: Wednesday, January 15, 2003 11:49 AM
1777 >Subject: [IRCServices Coding] Snoop How-To?
1780 >> Can someone please help me to create a snoop module in IRC services or
1781 >hack the nick/chan/oper servers so it send all commands in a channel?
1785 >> I really need this! :)
1789 >> Ph33rTheCuteOnes...
1792 >> ______________________________________________________________________
1793 >> http://www.mailbox.gr ÁðïêôÞóôå äùñåÜí ôï ìïíáäéêü óáò e-mail.
1794 >> http://www.thesuperweb.gr ÁðïêôÞóôå ôï äéêü óáò web site ìüíï ìå 6 Euro!
1795 >> ------------------------------------------------------------------
1796 >> To unsubscribe or change your subscription options, visit:
1797 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
1799 >------------------------------------------------------------------
1800 >To unsubscribe or change your subscription options, visit:
1801 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
1805 From ellaaa-adv at mailbox.gr Wed Jan 15 12:34:11 2003
1806 From: ellaaa-adv at mailbox.gr (Ph33rTheCuteOnes(...))
1807 Date: Sat Oct 23 23:09:49 2004
1808 Subject: [IRCServices Coding] Module Help on NullServ...
1809 Message-ID: <200301152034.WAA02568@mailbox.gr>
1811 I want to alter NullServ do he replies a msg to the user instead of just killing it!
1812 (To be exact I want to create a psudo-bot :)) by tempering with NullServ! ;P)
1816 /* Handler for PRIVMSGs. */
1818 static int do_privmsg(const char *source, const char *target, char *buf)
1820 send_cmd(ServerName, "PRIVMSG %s :Hello World!", source);
1824 what's wrong with it? I havn't changed anything else!
1827 ______________________________________________________________________
1828 http://www.mailbox.gr ÁðïêôÞóôå äùñåÜí ôï ìïíáäéêü óáò e-mail.
1829 http://www.thesuperweb.gr ÁðïêôÞóôå ôï äéêü óáò web site ìüíï ìå 6 Euro!
1831 From ron885 at bloodheart.com Wed Jan 15 12:35:02 2003
1832 From: ron885 at bloodheart.com (Ron)
1833 Date: Sat Oct 23 23:09:49 2004
1834 Subject: [IRCServices Coding] Module Help on NullServ...
1835 In-Reply-To: <200301152034.WAA02568@mailbox.gr>
1836 References: <200301152034.WAA02568@mailbox.gr>
1837 Message-ID: <200301151335.02274.ron885@bloodheart.com>
1839 On Wednesday 15 January 2003 01:34 pm, Ph33rTheCuteOnes(...) wrote:
1840 > what's wrong with it? I havn't changed anything else!
1842 its alot more complex than that... did you read the documentation? you have to
1843 run add_callback and stuff
1845 From ellaaa-adv at mailbox.gr Wed Jan 15 12:49:51 2003
1846 From: ellaaa-adv at mailbox.gr (Ph33rTheCuteOnes(...))
1847 Date: Sat Oct 23 23:09:49 2004
1848 Subject: [IRCServices Coding] Module Help on NullServ...
1849 Message-ID: <200301152049.WAA31515@mailbox.gr>
1851 I couldn't understand how it works...
1852 and I couldn't find some sample code...
1854 can you please show me an example?
1856 I just want to reply with a msg... (or generraly sent a RAW command)
1857 after that I think I can manage most of the rest...
1861 ______________________________________________________________________
1862 http://www.mailbox.gr ÁðïêôÞóôå äùñåÜí ôï ìïíáäéêü óáò e-mail.
1863 http://www.thesuperweb.gr ÁðïêôÞóôå ôï äéêü óáò web site ìüíï ìå 6 Euro!
1865 From ron885 at bloodheart.com Wed Jan 15 12:47:29 2003
1866 From: ron885 at bloodheart.com (Ron)
1867 Date: Sat Oct 23 23:09:49 2004
1868 Subject: [IRCServices Coding] Module Help on NullServ...
1869 In-Reply-To: <200301152049.WAA31515@mailbox.gr>
1870 References: <200301152049.WAA31515@mailbox.gr>
1871 Message-ID: <200301151347.29285.ron885@bloodheart.com>
1873 On Wednesday 15 January 2003 01:49 pm, Ph33rTheCuteOnes(...) wrote:
1874 > can you please show me an example?
1876 ircservices come with many modules with which you can look for examples..
1877 also... read the documentation... it cleary talks about modules in there and
1878 where you can find examples
1880 From serdar at konuk.net Thu Jan 16 05:00:56 2003
1881 From: serdar at konuk.net (serdar@konuk.net)
1882 Date: Sat Oct 23 23:09:49 2004
1883 Subject: [IRCServices Coding] Hi Are You There
1884 Message-ID: <39632.81.212.90.251.1042722056.bayposta@mail.konuk.net>
1886 I have sirv2.9.0 services databases But I cant convert it to irc-services
1889 I am using ./convert-db -v +sirv /home/user/services/data
1890 but it is making convert for 30 min. but I cant find where the converted
1891 databases and they dont work beacouse a problem like Version 4.
1892 Help me How can I do it?
1895 Bu e-mail BayPosta.Com webmail servisi ile g?nderilmektedir.
1897 http://www.bayposta.com
1899 Izhost Hosting Hizmetleri; Ekonomik 4 Paketi, 150 Mb. Web alan?, 50 POP3 mail hesabi %20 indirimli! http://www.izhost.com
1902 From serdar at konuk.net Thu Jan 16 05:01:16 2003
1903 From: serdar at konuk.net (serdar@konuk.net)
1904 Date: Sat Oct 23 23:09:49 2004
1905 Subject: [IRCServices Coding] Hi About DB converts
1906 Message-ID: <39637.81.212.90.251.1042722076.bayposta@mail.konuk.net>
1908 I have sirv2.9.0 services databases But I cant convert it to irc-services
1911 I am using ./convert-db -v +sirv /home/user/services/data
1912 but it is making convert for 30 min. but I cant find where the converted
1913 databases and they dont work beacouse a problem like Version 4.
1914 Help me How can I do it?
1917 Bu e-mail BayPosta.Com webmail servisi ile g?nderilmektedir.
1919 http://www.bayposta.com
1921 Izhost Hosting Hizmetleri; Ekonomik 4 Paketi, 150 Mb. Web alan?, 50 POP3 mail hesabi %20 indirimli! http://www.izhost.com
1924 From ellaaa-adv at mailbox.gr Thu Jan 16 06:13:19 2003
1925 From: ellaaa-adv at mailbox.gr (Ph33rTheCuteOnes(...))
1926 Date: Sat Oct 23 23:09:49 2004
1927 Subject: [IRCServices Coding] httpd module question?
1928 Message-ID: <200301161413.QAA03789@mailbox.gr>
1930 With the use of the httpd module can we print in a website the number of the users in a channel???
1935 ______________________________________________________________________
1936 http://www.mailbox.gr ÁðïêôÞóôå äùñåÜí ôï ìïíáäéêü óáò e-mail.
1937 http://www.thesuperweb.gr ÁðïêôÞóôå ôï äéêü óáò web site ìüíï ìå 6 Euro!
1939 From olly at avansys.co.uk Thu Jan 16 09:34:54 2003
1940 From: olly at avansys.co.uk (Olly)
1941 Date: Sat Oct 23 23:09:49 2004
1942 Subject: [IRCServices Coding] httpd module question?
1943 In-Reply-To: <200301161413.QAA03789@mailbox.gr>
1944 Message-ID: <000201c2bd85$95829be0$3d714fd9@thema>
1946 *This message was transferred with a trial version of CommuniGate(tm) Pro*
1947 That is something already done outside of IRCServices.
1948 Send me a personal email and I will show you how. Especially if you have
1952 -----Original Message-----
1953 From: ircservices-coding-admin@ircservices.za.net
1954 [mailto:ircservices-coding-admin@ircservices.za.net]On Behalf Of
1955 Ph33rTheCuteOnes(...)
1956 Sent: 16 January 2003 14:13
1957 To: ircservices-coding@ircservices.za.net
1958 Subject: [IRCServices Coding] httpd module question?
1961 *This message was transferred with a trial version of CommuniGate(tm) Pro*
1962 With the use of the httpd module can we print in a website the number of the
1963 users in a channel???
1968 ______________________________________________________________________
1969 http://www.mailbox.gr ????????? ?????? ?? ???????? ??? e-mail.
1970 http://www.thesuperweb.gr ????????? ?? ???? ??? web site ???? ?? 6 Euro!
1971 ------------------------------------------------------------------
1972 To unsubscribe or change your subscription options, visit:
1973 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
1975 Incoming mail is certified Virus Free.
1976 Checked by AVG anti-virus system (http://www.grisoft.com).
1977 Version: 6.0.435 / Virus Database: 244 - Release Date: 30/12/2002
1980 Outgoing mail is certified Virus Free.
1981 Checked by AVG anti-virus system (http://www.grisoft.com).
1982 Version: 6.0.435 / Virus Database: 244 - Release Date: 30/12/2002
1986 From aragon at phat.za.net Thu Jan 16 12:03:30 2003
1987 From: aragon at phat.za.net (Aragon Gouveia)
1988 Date: Sat Oct 23 23:09:49 2004
1989 Subject: [IRCServices Coding] ircservices 5.0.6 possible bug...
1990 Message-ID: <20030116200330.GA75681@phat.za.net>
1994 I've spotted something of some concern. If ircservices' uplink dies (ircd
1995 dies) causing ircservices to shutdown, some (possibly all) data that has not
1996 yet been updated to disk is lost.
1998 I first noticed it when I added a gzline which caused the ircd to core dump
1999 (heh) and ircservices to consequently shutdown. When I brought it all back
2000 up the gzline was not recorded in operserv's database. I then tried
2001 registering a nick and killing the ircd. When I brought it all back up, the
2002 nickname was not registered.
2004 Shutting services down gracefully via a SIGTERM or the shutdown command
2005 doesn't have the same effect. Please look into this...
2011 From aragon at phat.za.net Thu Jan 16 12:12:55 2003
2012 From: aragon at phat.za.net (Aragon Gouveia)
2013 Date: Sat Oct 23 23:09:49 2004
2014 Subject: [IRCServices Coding] ircservices 5.0.6 ImmediatelySendSline refinement for Unreal
2015 Message-ID: <20030116201255.GC75681@phat.za.net>
2019 5.0.6's inclusion of GZLINE management is really funky. As you know, in the
2020 case of Unreal, ImmediatelySendSline is a must. However, it follows the same
2021 behaviour as GLINEs. That being, if ircds and ircservices are restarted,
2022 ircservices does not implicitly re-add any GZLINEs upon starting. This is
2023 fine for GLINEs, but will not work correctly for GZLINEs on Unreal.
2025 Would it be possible to change the behaviour of ImmediatelySendSline for
2026 Unreal so that it checks and re-adds any GZLINEs that are not present when it
2034 From aragon at phat.za.net Thu Jan 16 12:26:08 2003
2035 From: aragon at phat.za.net (Aragon Gouveia)
2036 Date: Sat Oct 23 23:09:49 2004
2037 Subject: [IRCServices Coding] ircservices 5.0.6 GZLINE reason not shown on Unreal
2038 Message-ID: <20030116202608.GD75681@phat.za.net>
2044 When adding a GZLINE via ircservices linked to Unreal, the GZLINE is not
2045 added with the reason stipulated to ircservices :
2047 *** Permanent Global Z:line added for *@1.2.3.4 on Thu Jan 16 20:22:57 2003 GMT
2048 (from services.blabber.net: You are banned from this network)
2050 -OperServ- 1.2.3.4 (by Aragon on Jan 16 2003, never used; does not expire)
2057 From aragon at phat.za.net Thu Jan 16 13:47:57 2003
2058 From: aragon at phat.za.net (Aragon Gouveia)
2059 Date: Sat Oct 23 23:09:49 2004
2060 Subject: [IRCServices Coding] ircservices 5.0.6 ImmediatelySendSline refinement for Unreal
2061 In-Reply-To: <20030116201255.GC75681@phat.za.net>
2062 References: <20030116201255.GC75681@phat.za.net>
2063 Message-ID: <20030116214757.GA82504@phat.za.net>
2065 Sorry I meant explicitly, not implicitly :P
2068 | By Aragon Gouveia <aragon@phat.za.net>
2069 | [ 2003-01-16 22:13 +0200 ]
2072 > 5.0.6's inclusion of GZLINE management is really funky. As you know, in the
2073 > case of Unreal, ImmediatelySendSline is a must. However, it follows the same
2074 > behaviour as GLINEs. That being, if ircds and ircservices are restarted,
2075 > ircservices does not implicitly re-add any GZLINEs upon starting. This is
2076 > fine for GLINEs, but will not work correctly for GZLINEs on Unreal.
2078 > Would it be possible to change the behaviour of ImmediatelySendSline for
2079 > Unreal so that it checks and re-adds any GZLINEs that are not present when it
2080 > ircservices starts?
2087 From ellaaa-adv at mailbox.gr Fri Jan 17 06:53:22 2003
2088 From: ellaaa-adv at mailbox.gr (Ph33rTheCuteOnes(...))
2089 Date: Sat Oct 23 23:09:49 2004
2090 Subject: [IRCServices Coding] xxxserv help instead of xxxserv help commands
2091 Message-ID: <200301171453.QAA06699@mailbox.gr>
2093 How can I change the xxxserv help so it is the same with xxxserv help ?
2095 I want with the xxxserv help to return the list with the commands and not just to say type help commands!
2097 I tried to do it by altering in the lang file NICK_HELP and NICK_HELP_COMMANDS (only this text), compiling it with ./complang -w ... and puting the compiled file in the language dir but didn't work...
2105 ______________________________________________________________________
2106 http://www.mailbox.gr ÁðïêôÞóôå äùñåÜí ôï ìïíáäéêü óáò e-mail.
2107 http://www.thesuperweb.gr ÁðïêôÞóôå ôï äéêü óáò web site ìüíï ìå 6 Euro!
2109 From script at eroin.net Sun Jan 19 15:03:15 2003
2110 From: script at eroin.net (script@eroin.net)
2111 Date: Sat Oct 23 23:09:49 2004
2112 Subject: [IRCServices Coding] =?iso-8859-9?Q?ircservices_bug=3F?=
2113 Message-ID: <1233.62.29.120.16.1043017395.bayposta@mail.bayposta.com>
2115 I have a question regarding Operserv which is when I issued an /operserv
2116 update command I encounter (Internal error--unable to process request)
2117 error. Does anyone know how I overcome this problem. Anyhelp would be
2120 www.eroin.net & irc.eroin.net
2123 Bu e-mail BayPosta.Com webmail servisi ile g?nderilmektedir.
2124 http://www.bayposta.com
2126 Izhost Hosting Hizmetleri; Ekonomik 4 Paketi, 150 Mb. Web alan?, 50 POP3 mail hesabi %20 indirimli! http://www.izhost.com
2129 From mjgreen at euphony.net Sun Jan 19 19:41:48 2003
2130 From: mjgreen at euphony.net (Martin J. Green)
2131 Date: Sat Oct 23 23:09:49 2004
2132 Subject: [IRCServices Coding] hybrid 7 patch
2133 Message-ID: <008501c2c035$dcb93480$2b9d8651@morpheus>
2135 you mention a patch previously received for hybrid 7, but which couldn't be
2136 used for other reasons. does anyone know where I might get this patch?
2139 From ellaaa-adv at mailbox.gr Mon Jan 20 11:22:43 2003
2140 From: ellaaa-adv at mailbox.gr (Ph33rTheCuteOnes(...))
2141 Date: Sat Oct 23 23:09:49 2004
2142 Subject: [IRCServices Coding] xxxserv help instead of xxxserv help commands PLEASE HELP!
2143 Message-ID: <200301201922.VAA18780@mailbox.gr>
2145 How can I change the xxxserv help so it is the same with xxxserv help ?
2147 I want with the xxxserv help to return the list with the commands and not just to say type help commands!
2149 I tried to do it by altering in the lang file NICK_HELP and NICK_HELP_COMMANDS (only this text), compiling it with ./complang -w ... and puting the compiled file in the language dir but didn't work...
2157 ______________________________________________________________________
2158 http://www.mailbox.gr ÁðïêôÞóôå äùñåÜí ôï ìïíáäéêü óáò e-mail.
2159 http://www.thesuperweb.gr ÁðïêôÞóôå ôï äéêü óáò web site ìüíï ìå 6 Euro!
2161 From ellaaa-adv at mailbox.gr Tue Jan 21 12:36:46 2003
2162 From: ellaaa-adv at mailbox.gr (George A.)
2163 Date: Sat Oct 23 23:09:49 2004
2164 Subject: [IRCServices Coding] Log function? where?
2165 Message-ID: <200301212036.WAA03471@mailbox.gr>
2167 Where is the log function that operserv and the services call in order to
2168 write somthing it the .log file?
2170 Can this be altered to it also send the error to a channel?
2172 Do I have to create a psudoclient first or can it send directly to the channel?
2174 Thank you very much!
2177 ______________________________________________________________________
2178 http://www.mailbox.gr ÁðïêôÞóôå äùñåÜí ôï ìïíáäéêü óáò e-mail.
2179 http://www.thesuperweb.gr ÁðïêôÞóôå ôï äéêü óáò web site ìüíï ìå 6 Euro!
2181 From ron885 at bloodheart.com Tue Jan 21 13:16:07 2003
2182 From: ron885 at bloodheart.com (Ron)
2183 Date: Sat Oct 23 23:09:49 2004
2184 Subject: [IRCServices Coding] Log function? where?
2185 In-Reply-To: <200301212036.WAA03471@mailbox.gr>
2186 References: <200301212036.WAA03471@mailbox.gr>
2187 Message-ID: <200301211416.07694.ron885@bloodheart.com>
2189 On Tuesday 21 January 2003 01:36 pm, George A. wrote:
2190 > Where is the log function that operserv and the services call in order to
2191 > write somthing it the .log file?
2195 From pfribeiro at hotmail.com Tue Jan 21 15:00:22 2003
2196 From: pfribeiro at hotmail.com (Pedro Ribeiro)
2197 Date: Sat Oct 23 23:09:49 2004
2198 Subject: [IRCServices Coding] IRC Services crash (segmentation fault)
2199 Message-ID: <BAY2-F155ztxc1o8yfo0001587e@hotmail.com>
2201 I've been experiencing some instability in IRCservices for several times
2202 relating an unknown error that i still didnt figure it out.
2204 Anyway, I didn't have the time to look over the source.
2208 [Jan 21 23:06:49 2003] PANIC! buffer = & Dread_Pn 2 1043192563 Dread_Pn
2209 217.129.53.147 nix.exaur.net 0 +wx DE06EC9.7310DEBF.4B1570C9.IP :Dread
2210 [Jan 21 23:06:49 2003] Services terminating: Segmentation fault
2216 --------------------------------------
2222 _________________________________________________________________
2223 Tired of spam? Get advanced junk mail protection with MSN 8.
2224 http://join.msn.com/?page=features/junkmail
2227 From achurch at achurch.org Thu Jan 23 13:25:24 2003
2228 From: achurch at achurch.org (Andrew Church)
2229 Date: Sat Oct 23 23:09:49 2004
2230 Subject: [IRCServices Coding] xxxserv help instead of xxxserv help commands
2231 In-Reply-To: <200301171453.QAA06699@mailbox.gr>
2232 Message-ID: <3e2f6efc.01746@crystal.achurch.org>
2234 >How can I change the xxxserv help so it is the same with xxxserv help ?
2236 >I want with the xxxserv help to return the list with the commands and not just to say type help commands!
2238 The HELP COMMANDS text is dynamically generated. You'll have to edit
2239 the source code if you want to do this.
2245 From achurch at achurch.org Thu Jan 23 13:27:10 2003
2246 From: achurch at achurch.org (Andrew Church)
2247 Date: Sat Oct 23 23:09:49 2004
2248 Subject: [IRCServices Coding] Log function? where?
2249 In-Reply-To: <200301212036.WAA03471@mailbox.gr>
2250 Message-ID: <3e2f7000.01763@crystal.achurch.org>
2252 >Where is the log function that operserv and the services call in order to
2253 >write somthing it the .log file?
2255 The logging functions are in log.c.
2257 >Can this be altered to it also send the error to a channel?
2259 Yes, but if you do this don't run in debug mode or you'll get into an
2260 infinite loop (debug mode logs each line sent to the server).
2262 >Do I have to create a psudoclient first or can it send directly to the channel?
2264 That depends on whether your particular IRC server allows servers to
2265 send to channels, but it's probably safer to create one just in case. See
2266 the *Serv modules for examples of introducing a pseudoclient.
2272 From achurch at achurch.org Thu Jan 23 13:32:23 2003
2273 From: achurch at achurch.org (Andrew Church)
2274 Date: Sat Oct 23 23:09:49 2004
2275 Subject: [IRCServices Coding] Hi About DB converts
2276 In-Reply-To: <39637.81.212.90.251.1042722076.bayposta@mail.konuk.net>
2277 Message-ID: <3e2f70a3.01775@crystal.achurch.org>
2279 >I have sirv2.9.0 services databases But I cant convert it to irc-services
2282 >I am using ./convert-db -v +sirv /home/user/services/data
2283 >but it is making convert for 30 min. but I cant find where the converted
2286 Send me (privately) a copy of your database files and I'll take a
2293 From achurch at achurch.org Thu Jan 23 13:38:02 2003
2294 From: achurch at achurch.org (Andrew Church)
2295 Date: Sat Oct 23 23:09:49 2004
2296 Subject: [IRCServices Coding] ircservices_bug?
2297 In-Reply-To: <1233.62.29.120.16.1043017395.bayposta@mail.bayposta.com>
2298 Message-ID: <3e2f71bf.02022@crystal.achurch.org>
2306 > I have a question regarding Operserv which is when I issued an /operserv
2307 >update command I encounter (Internal error--unable to process request)
2308 >error. Does anyone know how I overcome this problem. Anyhelp would be
2311 >www.eroin.net & irc.eroin.net
2314 >Bu e-mail BayPosta.Com webmail servisi ile gönderilmektedir.
2315 >http://www.bayposta.com
2317 >Izhost Hosting Hizmetleri; Ekonomik 4 Paketi, 150 Mb. Web alaný, 50 POP3 mail hesabi %20 indirimli! http://www.izhost.com
2319 >------------------------------------------------------------------
2320 >To unsubscribe or change your subscription options, visit:
2321 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
2323 From achurch at achurch.org Thu Jan 23 13:42:14 2003
2324 From: achurch at achurch.org (Andrew Church)
2325 Date: Sat Oct 23 23:09:49 2004
2326 Subject: [IRCServices Coding] IRC Services crash (segmentation fault)
2327 In-Reply-To: <BAY2-F155ztxc1o8yfo0001587e@hotmail.com>
2328 Message-ID: <3e2f7304.02034@crystal.achurch.org>
2330 >I've been experiencing some instability in IRCservices for several times
2331 >relating an unknown error that i still didnt figure it out.
2333 >Anyway, I didn't have the time to look over the source.
2337 >[Jan 21 23:06:49 2003] PANIC! buffer = & Dread_Pn 2 1043192563 Dread_Pn
2338 >217.129.53.147 nix.exaur.net 0 +wx DE06EC9.7310DEBF.4B1570C9.IP :Dread
2339 >[Jan 21 23:06:49 2003] Services terminating: Segmentation fault
2343 Send me privately a debug log (a log of Services started with the
2344 -debug option, from startup to the occurrence of the error) along with a
2345 copy of your database files.
2351 From achurch at achurch.org Thu Jan 23 13:51:45 2003
2352 From: achurch at achurch.org (Andrew Church)
2353 Date: Sat Oct 23 23:09:49 2004
2354 Subject: [IRCServices Coding] ircservices 5.0.6 possible bug...
2355 In-Reply-To: <20030116200330.GA75681@phat.za.net>
2356 Message-ID: <3e2f74eb.02055@crystal.achurch.org>
2358 >I've spotted something of some concern. If ircservices' uplink dies (ircd
2359 >dies) causing ircservices to shutdown, some (possibly all) data that has not
2360 >yet been updated to disk is lost.
2362 Fixed, thanks for the report.
2368 From achurch at achurch.org Thu Jan 23 14:39:47 2003
2369 From: achurch at achurch.org (Andrew Church)
2370 Date: Sat Oct 23 23:09:49 2004
2371 Subject: [IRCServices Coding] ircservices 5.0.6 ImmediatelySendSline refinement for Unreal
2372 In-Reply-To: <20030116201255.GC75681@phat.za.net>
2373 Message-ID: <3e2f80dc.15465@crystal.achurch.org>
2377 >5.0.6's inclusion of GZLINE management is really funky. As you know, in the
2378 >case of Unreal, ImmediatelySendSline is a must. However, it follows the same
2379 >behaviour as GLINEs. That being, if ircds and ircservices are restarted,
2380 >ircservices does not implicitly re-add any GZLINEs upon starting. This is
2381 >fine for GLINEs, but will not work correctly for GZLINEs on Unreal.
2383 >Would it be possible to change the behaviour of ImmediatelySendSline for
2384 >Unreal so that it checks and re-adds any GZLINEs that are not present when it
2385 >ircservices starts?
2387 It was supposed to work this way already, but my logic was messed up.
2388 Fixed, thanks for the report.
2394 From achurch at achurch.org Thu Jan 23 14:43:26 2003
2395 From: achurch at achurch.org (Andrew Church)
2396 Date: Sat Oct 23 23:09:49 2004
2397 Subject: [IRCServices Coding] ircservices 5.0.6 GZLINE reason not shown on Unreal
2398 In-Reply-To: <20030116202608.GD75681@phat.za.net>
2399 Message-ID: <3e2f8110.15476@crystal.achurch.org>
2403 >One more thing.. :)
2405 >When adding a GZLINE via ircservices linked to Unreal, the GZLINE is not
2406 >added with the reason stipulated to ircservices :
2408 >*** Permanent Global Z:line added for *@1.2.3.4 on Thu Jan 16 20:22:57 2003 GMT
2409 >(from services.blabber.net: You are banned from this network)
2411 >-OperServ- 1.2.3.4 (by Aragon on Jan 16 2003, never used; does not expire)
2414 Check your modules.conf (SZlineReason).
2420 From aragon at phat.za.net Thu Jan 23 00:18:22 2003
2421 From: aragon at phat.za.net (Aragon Gouveia)
2422 Date: Sat Oct 23 23:09:49 2004
2423 Subject: [IRCServices Coding] ircservices 5.0.6 GZLINE reason not shown on Unreal
2424 In-Reply-To: <3e2f8110.15476@crystal.achurch.org>
2425 References: <20030116202608.GD75681@phat.za.net> <3e2f8110.15476@crystal.achurch.org>
2426 Message-ID: <20030123081822.GA75282@phat.za.net>
2428 Aah, doh. Thanks. :)
2431 | By Andrew Church <achurch@achurch.org>
2432 | [ 2003-01-23 07:44 +0200 ]
2435 > >One more thing.. :)
2437 > >When adding a GZLINE via ircservices linked to Unreal, the GZLINE is not
2438 > >added with the reason stipulated to ircservices :
2440 > >*** Permanent Global Z:line added for *@1.2.3.4 on Thu Jan 16 20:22:57 2003 GMT
2441 > >(from services.blabber.net: You are banned from this network)
2443 > >-OperServ- 1.2.3.4 (by Aragon on Jan 16 2003, never used; does not expire)
2446 > Check your modules.conf (SZlineReason).
2449 > achurch@achurch.org
2450 > http://achurch.org/
2452 From aragon at phat.za.net Thu Jan 23 00:22:37 2003
2453 From: aragon at phat.za.net (Aragon Gouveia)
2454 Date: Sat Oct 23 23:09:49 2004
2455 Subject: [IRCServices Coding] ircservices 5.0.6 ImmediatelySendSline refinement for Unreal
2456 In-Reply-To: <3e2f80dc.15465@crystal.achurch.org>
2457 References: <20030116201255.GC75681@phat.za.net> <3e2f80dc.15465@crystal.achurch.org>
2458 Message-ID: <20030123082237.GB75282@phat.za.net>
2460 Thanks. For both fixes. :)
2463 | By Andrew Church <achurch@achurch.org>
2464 | [ 2003-01-23 07:43 +0200 ]
2467 > >5.0.6's inclusion of GZLINE management is really funky. As you know, in the
2468 > >case of Unreal, ImmediatelySendSline is a must. However, it follows the same
2469 > >behaviour as GLINEs. That being, if ircds and ircservices are restarted,
2470 > >ircservices does not implicitly re-add any GZLINEs upon starting. This is
2471 > >fine for GLINEs, but will not work correctly for GZLINEs on Unreal.
2473 > >Would it be possible to change the behaviour of ImmediatelySendSline for
2474 > >Unreal so that it checks and re-adds any GZLINEs that are not present when it
2475 > >ircservices starts?
2477 > It was supposed to work this way already, but my logic was messed up.
2478 > Fixed, thanks for the report.
2481 > achurch@achurch.org
2482 > http://achurch.org/
2484 From georges at berscheid.lu Thu Jan 23 01:05:27 2003
2485 From: georges at berscheid.lu (Georges Berscheid)
2486 Date: Sat Oct 23 23:09:49 2004
2487 Subject: [IRCServices Coding] Timeouts
2488 Message-ID: <000001c2c2be$924f98e0$4dbbf683@globi>
2492 while talking about writing new modules, what was the exact reason for
2493 not allowing coders to loop through the list of timeouts (since *prev
2494 and *next are private to the timeout.c functions) ?
2495 Since timeouts already have ->data, they could also have a ->type, which
2496 whould allow to find a specific timeout in the list using data and type.
2497 I now implemented my own list adding the type property to a timeout (as
2498 in modules/nickserv/collide.c), but it could have been much easier using
2499 predefined timeout-browse-functions :)
2504 From achurch at achurch.org Thu Jan 23 18:09:43 2003
2505 From: achurch at achurch.org (Andrew Church)
2506 Date: Sat Oct 23 23:09:49 2004
2507 Subject: [IRCServices Coding] Timeouts
2508 In-Reply-To: <000001c2c2be$924f98e0$4dbbf683@globi>
2509 Message-ID: <3e2fb1cd.15601@crystal.achurch.org>
2511 >while talking about writing new modules, what was the exact reason for
2512 >not allowing coders to loop through the list of timeouts (since *prev
2513 >and *next are private to the timeout.c functions) ?
2515 You shouldn't need to loop through them; the routine called when the
2516 timeout occurs and the arbitrary data passed to it are all you should need
2517 to know. If you need anything else then you need to use a better design.
2523 From georges at berscheid.lu Thu Jan 23 01:17:45 2003
2524 From: georges at berscheid.lu (Georges Berscheid)
2525 Date: Sat Oct 23 23:09:49 2004
2526 Subject: AW: [IRCServices Coding] Timeouts
2527 In-Reply-To: <3e2fb1cd.15601@crystal.achurch.org>
2528 Message-ID: <000101c2c2c0$4a97ffe0$4dbbf683@globi>
2530 Well, taking the example of colliding nicks.
2531 If a user identifies within 1 minute, you need to remove the timeout
2532 before it occurs, which makes it necessary to find it in the list :)
2536 -----Urspr?ngliche Nachricht-----
2537 Von: ircservices-coding-admin@ircservices.za.net
2538 [mailto:ircservices-coding-admin@ircservices.za.net] Im Auftrag von
2540 Gesendet: Donnerstag, 23. Januar 2003 10:10
2541 An: ircservices-coding@ircservices.za.net
2542 Betreff: Re: [IRCServices Coding] Timeouts
2545 >while talking about writing new modules, what was the exact reason for
2546 >not allowing coders to loop through the list of timeouts (since *prev
2547 >and *next are private to the timeout.c functions) ?
2549 You shouldn't need to loop through them; the routine called when
2551 timeout occurs and the arbitrary data passed to it are all you should
2553 to know. If you need anything else then you need to use a better
2559 ------------------------------------------------------------------
2560 To unsubscribe or change your subscription options, visit:
2561 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
2565 From achurch at achurch.org Thu Jan 23 18:23:29 2003
2566 From: achurch at achurch.org (Andrew Church)
2567 Date: Sat Oct 23 23:09:49 2004
2568 Subject: AW: [IRCServices Coding] Timeouts
2569 In-Reply-To: <000101c2c2c0$4a97ffe0$4dbbf683@globi>
2570 Message-ID: <3e2fb527.15642@crystal.achurch.org>
2572 >Well, taking the example of colliding nicks.
2573 >If a user identifies within 1 minute, you need to remove the timeout
2574 >before it occurs, which makes it necessary to find it in the list :)
2576 You have the pointer returned from add_timeout(); just store it
2577 somewhere. (This is what the code actually does.)
2583 From stefan at netconta.com.br Thu Jan 23 03:11:16 2003
2584 From: stefan at netconta.com.br (Stefan Horochovec)
2585 Date: Sat Oct 23 23:09:49 2004
2586 Subject: [IRCServices Coding] export to xml
2587 Message-ID: <001e01c2c2d0$27608be0$05640a0a@piii700>
2591 i using the convert-db but my encription on old databases is md5() and
2592 the pass on xml is a diferent encription and i don?t understand her...
2594 what encription is used on convert-db?
2599 lordao - Stefan Horochovec
2600 Francisco Beltrao, PR - Brazil
2603 From RT.Mail at verizon.net Thu Jan 23 09:25:57 2003
2604 From: RT.Mail at verizon.net (RT.Mail@verizon.net)
2605 Date: Sat Oct 23 23:09:49 2004
2606 Subject: [IRCServices Coding] globla message
2607 Message-ID: <20030123172558.MSKV23484.out001.verizon.net@bofh>
2609 When sending a global notice, such as the following, if its to long a : gets inserted into it, you can see it got inserted right before
2612 "We would like to remind everyone if you ever have trouble connecting you should contact an oper. You should never have trouble
2613 connecting while using irc.linkirc.net to connect. In addition an anti lamer device has been added to #linkirc. Anyone who comes
2614 in to #linkirc and types !list or :@find gets a complimentary kill."
2616 Other people have also had problems with this.
2619 From mjgreen at euphony.net Thu Jan 23 09:28:32 2003
2620 From: mjgreen at euphony.net (Martin J. Green)
2621 Date: Sat Oct 23 23:09:49 2004
2622 Subject: [IRCServices Coding] globla message
2623 References: <20030123172558.MSKV23484.out001.verizon.net@bofh>
2624 Message-ID: <001501c2c304$da8092e0$e3a38651@morpheus>
2626 using /kill for channel reasons? that sound mature...
2628 ----- Original Message -----
2629 From: <RT.Mail@verizon.net>
2630 To: "IRC Services" <ircservices-coding@ircservices.za.net>
2631 Sent: Thursday, January 23, 2003 5:25 PM
2632 Subject: [IRCServices Coding] globla message
2635 When sending a global notice, such as the following, if its to long a : gets
2636 inserted into it, you can see it got inserted right before
2639 "We would like to remind everyone if you ever have trouble connecting you
2640 should contact an oper. You should never have trouble
2641 connecting while using irc.linkirc.net to connect. In addition an anti lamer
2642 device has been added to #linkirc. Anyone who comes
2643 in to #linkirc and types !list or :@find gets a complimentary kill."
2645 Other people have also had problems with this.
2647 ------------------------------------------------------------------
2648 To unsubscribe or change your subscription options, visit:
2649 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
2652 From RT.Mail at verizon.net Thu Jan 23 09:32:11 2003
2653 From: RT.Mail at verizon.net (RT.Mail@verizon.net)
2654 Date: Sat Oct 23 23:09:50 2004
2655 Subject: [IRCServices Coding] globla message
2656 In-Reply-To: <001501c2c304$da8092e0$e3a38651@morpheus>
2657 Message-ID: <20030123173212.BDHL21001.pop015.verizon.net@bofh>
2659 spamming the mailing list with your opinions? thats mature...
2661 < >On Thu, 23 Jan 2003 17:28:32 -0000, Martin J. Green wrote:
2662 < > using /kill for channel reasons? that sound mature...
2664 < > ----- Original Message -----
2665 < > From: <RT.Mail@verizon.net>
2666 < > To: "IRC Services" <ircservices-coding@ircservices.za.net>
2667 < > Sent: Thursday, January 23, 2003 5:25 PM
2668 < > Subject: [IRCServices Coding] globla message
2671 < > When sending a global notice, such as the following, if its to
2673 < > inserted into it, you can see it got inserted right before
2676 < > "We would like to remind everyone if you ever have trouble
2678 < > should contact an oper. You should never have trouble
2679 < > connecting while using irc.linkirc.net to connect. In addition
2681 < > device has been added to #linkirc. Anyone who comes
2682 < > in to #linkirc and types !list or :@find gets a complimentary
2685 < > Other people have also had problems with this.
2687 < > -----------------------------------------------------------------
2689 < > To unsubscribe or change your subscription options, visit:
2690 < > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
2692 < > -----------------------------------------------------------------
2694 < > To unsubscribe or change your subscription options, visit:
2695 < > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
2700 From mjgreen at euphony.net Thu Jan 23 09:38:02 2003
2701 From: mjgreen at euphony.net (Martin J. Green)
2702 Date: Sat Oct 23 23:09:50 2004
2703 Subject: [IRCServices Coding] globla message
2704 References: <20030123173212.BDHL21001.pop015.verizon.net@bofh>
2705 Message-ID: <002d01c2c306$2de3f750$e3a38651@morpheus>
2707 technically spamming is unsolicited bulk e-mail. flaming perhaps, but
2710 Anyone who misuses /kill needs any raped by a black felon named bubba. I bet
2711 you run unreal too...
2713 ----- Original Message -----
2714 From: <RT.Mail@verizon.net>
2715 To: <ircservices-coding@ircservices.za.net>
2716 Sent: Thursday, January 23, 2003 5:32 PM
2717 Subject: Re: [IRCServices Coding] globla message
2720 spamming the mailing list with your opinions? thats mature...
2722 < >On Thu, 23 Jan 2003 17:28:32 -0000, Martin J. Green wrote:
2723 < > using /kill for channel reasons? that sound mature...
2725 < > ----- Original Message -----
2726 < > From: <RT.Mail@verizon.net>
2727 < > To: "IRC Services" <ircservices-coding@ircservices.za.net>
2728 < > Sent: Thursday, January 23, 2003 5:25 PM
2729 < > Subject: [IRCServices Coding] globla message
2732 < > When sending a global notice, such as the following, if its to
2734 < > inserted into it, you can see it got inserted right before
2737 < > "We would like to remind everyone if you ever have trouble
2739 < > should contact an oper. You should never have trouble
2740 < > connecting while using irc.linkirc.net to connect. In addition
2742 < > device has been added to #linkirc. Anyone who comes
2743 < > in to #linkirc and types !list or :@find gets a complimentary
2746 < > Other people have also had problems with this.
2748 < > -----------------------------------------------------------------
2750 < > To unsubscribe or change your subscription options, visit:
2751 < > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
2753 < > -----------------------------------------------------------------
2755 < > To unsubscribe or change your subscription options, visit:
2756 < > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
2760 ------------------------------------------------------------------
2761 To unsubscribe or change your subscription options, visit:
2762 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
2765 From RT.Mail at verizon.net Thu Jan 23 09:45:59 2003
2766 From: RT.Mail at verizon.net (RT.Mail@verizon.net)
2767 Date: Sat Oct 23 23:09:50 2004
2768 Subject: [IRCServices Coding] globla message
2769 In-Reply-To: <002d01c2c306$2de3f750$e3a38651@morpheus>
2770 Message-ID: <20030123174600.RIIF10203.pop017.verizon.net@bofh>
2772 First off did it ever occur to you that maybe I tried kicking and banning first? EIther way this list isn't for you to comment on how I
2773 run my network. You emails have nothing to do with helping to fix a bug or reporting a bug and therefore do not belong on this list.
2777 spam P Pronunciation Key (spm)
2780 Unsolicited e-mail, often of a commercial nature, sent indiscriminately to multiple mailing lists, individuals, or newsgroups; junk e-
2784 From Craig at chatspike.net Thu Jan 23 09:54:29 2003
2785 From: Craig at chatspike.net (Craig McLure)
2786 Date: Sat Oct 23 23:09:50 2004
2787 Subject: [IRCServices Coding] globla message
2788 Message-ID: <20030123175119.WOXH4699.mta03-svc.ntlworld.com@i-br0ked-it>
2790 Agreed, the message in question isnt the issue here, what is the problem is that services will put a : in it, it happens on my network too.
2792 -----------------------------------------------------------------------
2793 Craig McLure - Craig@chatspike.net
2794 ChatSpike - The users network: http://www.chatspike.net
2795 InspIRCd - Modular IRC server: http://www.inspircd.org
2796 -----------------------------------------------------------------------
2799 ============ Original Message ============
2800 >From : "RT.Mail" <RT.Mail@verizon.net>
2803 >Subject : Re: [IRCServices Coding] globla message
2806 >spamming the mailing list with your opinions? thats mature...
2808 >< >On Thu, 23 Jan 2003 17:28:32 -0000, Martin J. Green wrote:
2809 >< > using /kill for channel reasons? that sound mature...
2811 >< > ----- Original Message -----
2812 >< > From: <RT.Mail@verizon.net>
2813 >< > To: "IRC Services" <ircservices-coding@ircservices.za.net>
2814 >< > Sent: Thursday, January 23, 2003 5:25 PM
2815 >< > Subject: [IRCServices Coding] globla message
2818 >< > When sending a global notice, such as the following, if its to
2820 >< > inserted into it, you can see it got inserted right before
2823 >< > "We would like to remind everyone if you ever have trouble
2825 >< > should contact an oper. You should never have trouble
2826 >< > connecting while using irc.linkirc.net to connect. In addition
2828 >< > device has been added to #linkirc. Anyone who comes
2829 >< > in to #linkirc and types !list or :@find gets a complimentary
2832 >< > Other people have also had problems with this.
2834 >< > -----------------------------------------------------------------
2836 >< > To unsubscribe or change your subscription options, visit:
2837 >< > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
2839 >< > -----------------------------------------------------------------
2841 >< > To unsubscribe or change your subscription options, visit:
2842 >< > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
2846 >------------------------------------------------------------------
2847 >To unsubscribe or change your subscription options, visit:
2848 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
2851 ========= End of Original Message =========
2856 From aragon at phat.za.net Thu Jan 23 11:15:15 2003
2857 From: aragon at phat.za.net (Aragon Gouveia)
2858 Date: Sat Oct 23 23:09:50 2004
2859 Subject: [IRCServices Coding] globla message
2860 In-Reply-To: <002d01c2c306$2de3f750$e3a38651@morpheus>
2861 References: <20030123173212.BDHL21001.pop015.verizon.net@bofh> <002d01c2c306$2de3f750$e3a38651@morpheus>
2862 Message-ID: <20030123191515.GA19772@phat.za.net>
2864 | By Martin J. Green <mjgreen@euphony.net>
2865 | [ 2003-01-23 19:39 +0200 ]
2866 > technically spamming is unsolicited bulk e-mail. flaming perhaps, but
2869 > Anyone who misuses /kill needs any raped by a black felon named bubba. I bet
2870 > you run unreal too...
2872 Your irrelevant, off-topic, discriminatory, pubescent comments really aren't
2873 appreciated here. If you have such opinions, please keep them off the list.
2879 From achurch at achurch.org Fri Jan 24 08:59:34 2003
2880 From: achurch at achurch.org (Andrew Church)
2881 Date: Sat Oct 23 23:09:50 2004
2882 Subject: [IRCServices Coding] globla message
2883 In-Reply-To: <20030123172558.MSKV23484.out001.verizon.net@bofh>
2884 Message-ID: <3e30822e.22373@crystal.achurch.org>
2886 >When sending a global notice, such as the following, if its to
2887 >long a : gets inserted into it, you can see it got inserted
2888 >right before @find.
2890 >"We would like to remind everyone if you ever have trouble
2891 >connecting you should contact an oper. You should never have
2893 >connecting while using irc.linkirc.net to connect. In addition an
2894 >anti lamer device has been added to #linkirc. Anyone who comes
2895 >in to #linkirc and types !list or :@find gets a complimentary
2898 I can't reproduce this. Are you sure this isn't an ircd or script
2905 From Ganja51 at lcirc.net Thu Jan 23 16:58:33 2003
2906 From: Ganja51 at lcirc.net (Ganja51)
2907 Date: Sat Oct 23 23:09:50 2004
2908 Subject: [IRCServices Coding] globla message
2909 References: <3e30822e.22373@crystal.achurch.org>
2910 Message-ID: <004801c2c343$c7867c60$1402a8c0@monte>
2912 it wasn't reproduced on my network either.
2915 ----- Original Message -----
2916 From: "Andrew Church" <achurch@achurch.org>
2917 To: <ircservices-coding@ircservices.za.net>
2918 Sent: Thursday, January 23, 2003 5:59 PM
2919 Subject: Re: [IRCServices Coding] globla message
2922 > >When sending a global notice, such as the following, if its to
2923 > >long a : gets inserted into it, you can see it got inserted
2924 > >right before @find.
2926 > >"We would like to remind everyone if you ever have trouble
2927 > >connecting you should contact an oper. You should never have
2929 > >connecting while using irc.linkirc.net to connect. In addition an
2930 > >anti lamer device has been added to #linkirc. Anyone who comes
2931 > >in to #linkirc and types !list or :@find gets a complimentary
2934 > I can't reproduce this. Are you sure this isn't an ircd or script
2938 > achurch@achurch.org
2939 > http://achurch.org/
2940 > ------------------------------------------------------------------
2941 > To unsubscribe or change your subscription options, visit:
2942 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
2944 From Craig at chatspike.net Thu Jan 23 19:35:28 2003
2945 From: Craig at chatspike.net (Craig McLure)
2946 Date: Sat Oct 23 23:09:50 2004
2947 Subject: [IRCServices Coding] globla message
2948 Message-ID: <20030124033218.OSYF22267.mta01-svc.ntlworld.com@i-br0ked-it>
2950 i think it may be a bug in UnrealIRCds aliases, it was only re-producable when i used /os global, and not when i used /msg operserv global.
2952 -----------------------------------------------------------------------
2953 Craig McLure - Craig@chatspike.net
2954 ChatSpike - The users network: http://www.chatspike.net
2955 InspIRCd - Modular IRC server: http://www.inspircd.org
2956 -----------------------------------------------------------------------
2959 ============ Original Message ============
2960 >From : "Ganja51" <Ganja51@lcirc.net>
2963 >Subject : Re: [IRCServices Coding] globla message
2966 >it wasn't reproduced on my network either.
2969 >----- Original Message -----
2970 >From: "Andrew Church" <achurch@achurch.org>
2971 >To: <ircservices-coding@ircservices.za.net>
2972 >Sent: Thursday, January 23, 2003 5:59 PM
2973 >Subject: Re: [IRCServices Coding] globla message
2976 >> >When sending a global notice, such as the following, if its to
2977 >> >long a : gets inserted into it, you can see it got inserted
2978 >> >right before @find.
2980 >> >"We would like to remind everyone if you ever have trouble
2981 >> >connecting you should contact an oper. You should never have
2983 >> >connecting while using irc.linkirc.net to connect. In addition an
2984 >> >anti lamer device has been added to #linkirc. Anyone who comes
2985 >> >in to #linkirc and types !list or :@find gets a complimentary
2988 >> I can't reproduce this. Are you sure this isn't an ircd or script
2992 >> achurch@achurch.org
2993 >> http://achurch.org/
2994 >> ------------------------------------------------------------------
2995 >> To unsubscribe or change your subscription options, visit:
2996 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
2997 >------------------------------------------------------------------
2998 >To unsubscribe or change your subscription options, visit:
2999 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
3002 ========= End of Original Message =========
3007 From r-krisztian at softhome.net Thu Jan 23 21:31:02 2003
3008 From: r-krisztian at softhome.net (Krisztian Romek)
3009 Date: Sat Oct 23 23:09:50 2004
3010 Subject: [IRCServices Coding] globla message
3011 In-Reply-To: <20030124033218.OSYF22267.mta01-svc.ntlworld.com@i-br0ked-it>
3012 References: <20030124033218.OSYF22267.mta01-svc.ntlworld.com@i-br0ked-it>
3013 Message-ID: <200301240631.02925.r-krisztian@softhome.net>
3015 "Craig McLure" <Craig@chatspike.net> wrote:
3016 > i think it may be a bug in UnrealIRCds aliases, it was only re-producable
3017 > when i used /os global, and not when i used /msg operserv global.
3019 If /os global doesn't work, there might be a wrong value for
3020 set::services-server...
3024 r-krisztian@softhome.net
3027 From Craig at chatspike.net Thu Jan 23 23:31:54 2003
3028 From: Craig at chatspike.net (Craig McLure)
3029 Date: Sat Oct 23 23:09:50 2004
3030 Subject: [IRCServices Coding] globla message
3031 Message-ID: <20030124072840.VKLI20174.mta06-svc.ntlworld.com@i-br0ked-it>
3033 umm, are you reading whats being said? the : will only appear when using an Unreal alias, i wasnt saying that /os raw doesnt work.
3035 -----------------------------------------------------------------------
3036 Craig McLure - Craig@chatspike.net
3037 ChatSpike - The users network: http://www.chatspike.net
3038 InspIRCd - Modular IRC server: http://www.inspircd.org
3039 -----------------------------------------------------------------------
3042 ============ Original Message ============
3043 >From : "Krisztian Romek" <r-krisztian@softhome.net>
3046 >Subject : Re: Re: [IRCServices Coding] globla message
3049 >"Craig McLure" <Craig@chatspike.net> wrote:
3050 >> i think it may be a bug in UnrealIRCds aliases, it was only re-producable
3051 >> when i used /os global, and not when i used /msg operserv global.
3053 >If /os global doesn't work, there might be a wrong value for
3054 >set::services-server...
3058 >r-krisztian@softhome.net
3060 >------------------------------------------------------------------
3061 >To unsubscribe or change your subscription options, visit:
3062 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
3065 ========= End of Original Message =========
3070 From Ganja51 at lcirc.net Fri Jan 31 22:00:26 2003
3071 From: Ganja51 at lcirc.net (Ganja51)
3072 Date: Sat Oct 23 23:09:50 2004
3073 Subject: [IRCServices Coding] Additional Removal Methods
3074 Message-ID: <004201c2c9b7$38df4670$1402a8c0@monte>
3076 I just recently had a bot flood and there's a few functions which I think
3077 may have helped tremendously in the removal of the bots. First off an akill
3078 which can akill the realname AND support wildcards. Example:
3079 ... fritz is lilah@lcirc-590F41A.hkcable.com.hk (here)
3080 ... fritz is ?]Z[-22091? on Edge.lcirc.net (2 hops)
3081 ... marzec is vxvmn797@15B84C5E.8EBB203E.3260E6B0.IP (here)
3082 ... marzec is ?]Z[-46173? on Edge.lcirc.net (2 hops)
3083 Those were 2 bots. An akill of the realname of ]Z[-* would have removed all
3084 of those ones. UnrealIRCd supports this sort of ban, but it'd have to be
3085 added to each server which is a hassle in a flood situation.
3087 The other type is if the ident matches the realname. Example:
3088 ... Flinch01 is ~TooL@lcirc-206714C5.bbd16tcl.dsl.pol.co.uk (here)
3089 ... Flinch01 is ?TooL? on Gimcrack.lcirc.net (0 hops)
3090 ... Aitziver is ~00537@22BD02E.2482453B.4F4CDF9A.IP (here)
3091 ... Aitziver is ?00537? on Gimcrack.lcirc.net (0 hops)
3092 This one is probably less likely seeing as how services would have to run
3093 that check. But lots of bots are poorly coded in the respect that they use
3094 the same random word/number generated for both the ident and realname.
3096 Just a few suggestions which I think would help out a ton. Thanks for your
3101 From achurch at achurch.org Sun Feb 2 12:17:24 2003
3102 From: achurch at achurch.org (Andrew Church)
3103 Date: Sat Oct 23 23:09:50 2004
3104 Subject: [IRCServices Coding] Additional Removal Methods
3105 In-Reply-To: <004201c2c9b7$38df4670$1402a8c0@monte>
3106 Message-ID: <3e3c8e03.34167@mail.achurch.org>
3108 Try SGLINE with SQlineKill (modules.conf).
3114 >I just recently had a bot flood and there's a few functions which I think
3115 >may have helped tremendously in the removal of the bots. First off an aki
3117 >which can akill the realname AND support wildcards. Example:
3118 >... fritz is lilah@lcirc-590F41A.hkcable.com.hk (here)
3119 >... fritz is
\8e«]Z[-22091
\8e» on Edge.lcirc.net (2 hops)
3120 >... marzec is vxvmn797@15B84C5E.8EBB203E.3260E6B0.IP (here)
3121 >... marzec is
\8e«]Z[-46173
\8e» on Edge.lcirc.net (2 hops)
3122 >Those were 2 bots. An akill of the realname of ]Z[-* would have removed a
3124 >of those ones. UnrealIRCd supports this sort of ban, but it'd have to be
3125 >added to each server which is a hassle in a flood situation.
3127 >The other type is if the ident matches the realname. Example:
3128 >... Flinch01 is ~TooL@lcirc-206714C5.bbd16tcl.dsl.pol.co.uk (here)
3129 >... Flinch01 is
\8e«TooL
\8e» on Gimcrack.lcirc.net (0 hops)
3130 >... Aitziver is ~00537@22BD02E.2482453B.4F4CDF9A.IP (here)
3131 >... Aitziver is
\8e«00537
\8e» on Gimcrack.lcirc.net (0 hops)
3132 >This one is probably less likely seeing as how services would have to run
3133 >that check. But lots of bots are poorly coded in the respect that they us
3135 >the same random word/number generated for both the ident and realname.
3137 >Just a few suggestions which I think would help out a ton. Thanks for you
3143 >------------------------------------------------------------------
3144 >To unsubscribe or change your subscription options, visit:
3145 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
3146 From rg at tcslon.com Mon Feb 10 10:22:52 2003
3147 From: rg at tcslon.com (Russell Garrett)
3148 Date: Sat Oct 23 23:09:50 2004
3149 Subject: [IRCServices Coding] Site
3150 Message-ID: <NDBBLDHKLKMANPGMACIGMELDDEAA.rg@tcslon.com>
3152 Just a note, the front page of www.ircservices.za.net still shows 5.0.6 as
3153 the latest build, at least for me.
3155 ----------------------------------------------------------------------------
3156 Russ Garrett russ@garrett.co.uk.
3157 http://russ.garrett.co.uk.
3160 From aragon at phat.za.net Mon Feb 10 11:10:51 2003
3161 From: aragon at phat.za.net (Aragon Gouveia)
3162 Date: Sat Oct 23 23:09:50 2004
3163 Subject: [IRCServices Coding] Site
3164 In-Reply-To: <NDBBLDHKLKMANPGMACIGMELDDEAA.rg@tcslon.com>
3165 References: <NDBBLDHKLKMANPGMACIGMELDDEAA.rg@tcslon.com>
3166 Message-ID: <20030210191051.GA92561@phat.za.net>
3168 Didn't even know 5.0.7 was out, let alone 5.0.9. Thanks for pointing it
3172 | By Russell Garrett <rg@tcslon.com>
3173 | [ 2003-02-10 20:23 +0200 ]
3174 > Just a note, the front page of www.ircservices.za.net still shows 5.0.6 as
3175 > the latest build, at least for me.
3177 > ----------------------------------------------------------------------------
3178 > Russ Garrett russ@garrett.co.uk.
3179 > http://russ.garrett.co.uk.
3180 From aragon at phat.za.net Mon Feb 10 11:19:30 2003
3181 From: aragon at phat.za.net (Aragon Gouveia)
3182 Date: Sat Oct 23 23:09:50 2004
3183 Subject: [IRCServices Coding] Site
3184 In-Reply-To: <20030210191051.GA92561@phat.za.net>
3185 References: <NDBBLDHKLKMANPGMACIGMELDDEAA.rg@tcslon.com>
3186 <20030210191051.GA92561@phat.za.net>
3187 Message-ID: <20030210191930.GA93221@phat.za.net>
3191 Something I just noticed - ftp.ircservices.za.net isn't quite upto speed
3192 with ftp.esper.net. It's missing 5.0.8 diff for one. :)
3199 | By Aragon Gouveia <aragon@phat.za.net>
3200 | [ 2003-02-10 21:10 +0200 ]
3201 > Didn't even know 5.0.7 was out, let alone 5.0.9. Thanks for pointing it
3205 > | By Russell Garrett <rg@tcslon.com>
3206 > | [ 2003-02-10 20:23 +0200 ]
3207 > > Just a note, the front page of www.ircservices.za.net still shows 5.0.6 as
3208 > > the latest build, at least for me.
3210 > > ----------------------------------------------------------------------------
3211 > > Russ Garrett russ@garrett.co.uk.
3212 > > http://russ.garrett.co.uk.
3213 From dan at viaraix.net Mon Feb 10 11:46:14 2003
3214 From: dan at viaraix.net (Dan Jones)
3215 Date: Sat Oct 23 23:09:50 2004
3216 Subject: [IRCServices Coding] Channel registration limit:Default (2)
3217 Message-ID: <3E480186.8060209@viaraix.net>
3221 I emailed a few months ago about the "Channel registration limit:Default
3222 (2)" part and was told this was on todo list (allowing users a different
3223 ammount of channels)
3225 Has this been done yet?
3227 cant check myself...
3230 You don't have permission to access /Changes on this server.
3232 Apache/1.3.27 Server at www.ircservices.za.net Port 80
3237 From aragon at phat.za.net Mon Feb 10 13:22:02 2003
3238 From: aragon at phat.za.net (Aragon Gouveia)
3239 Date: Sat Oct 23 23:09:50 2004
3240 Subject: [IRCServices Coding] problems with 5.0.9
3241 Message-ID: <20030210212202.GB97537@phat.za.net>
3245 The other day I reported the database save bug when ircservices looses its
3246 uplink. Just upgraded to 5.0.9 and am having another problem...
3248 When the uplink server closes the connection ircservices does not exit.
3249 Neither is there any log of such activity. Further more, issuing a SIGTERM
3250 to the process after the uplink has died only results in "Received SIGTERM,
3251 exiting." being logged, but the process does not die. It takes a SIGKILL to
3252 kill it off. And of course a SIGKILL doesn't go down well with saving the
3253 database to disk! :)
3255 Running Unreal 3.2 btw.
3260 From arathorn at theonering.net Mon Feb 10 13:43:42 2003
3261 From: arathorn at theonering.net (Arathorn)
3262 Date: Sat Oct 23 23:09:50 2004
3263 Subject: [IRCServices Coding] problems with 5.0.9
3264 References: <20030210212202.GB97537@phat.za.net>
3265 Message-ID: <00fa01c2d14d$7aaf21e0$0600a8c0@mjh75>
3267 I've had this problem too (although I cannot reproduce it at the moment) -
3268 I've reported it on the non-coding list. Andrew's suggestion there is to
3269 attach to the hung process with gdb and see what's going on (which I'm going
3270 to do when it next happens to me).
3272 That said, I have a suspicion that I may have somehow prevented it; although
3273 so many variables have been changed I'm not sure what may have helped.
3275 Off the top of my head:
3277 1) I changed services to connect to unreal 3.2 on localhost - explicitly
3278 specifying the binding port (i.e. connecting from 127.0.0.1:7028 to
3281 2) enabled a PingFrequency of 30s across the link to try to keep things
3282 alive and healthy (i've also had problems with 3.2 complaining about Bad
3283 File Descriptors on the Services socket when select()ing the FDLIST),
3285 3) Tried running services 'plain' from the commandline rather than from a
3287 start-stop-daemon --start --quiet --pidfile
3288 /usr/local/lib/ircservices/ircservices.pid \
3289 --chuid irc:irc --exec /usr/local/sbin/ircservices >
3292 in a Debian /etc/init.d script.
3294 Somewhere along there, it's decided to start behaving absolutely fine (after
3295 consistently hanging after the ircd closed its connection). Services die
3296 cleanly on a /restart and /die work fine - and for that matter, so does
3297 /operserv restart, quit & shutdown. With the proviso of some thoroughly
3298 screwed up intermittent faults with +k modelocks disappearing on registered
3299 channels after services restarts - and xml-export doing some very mangled
3300 things. c.f. ircservices@ircservices.za.net.
3302 ________________________________________________________________
3303 Matthew Hodgson arathorn@theonering.net Tel: +44 7968 722968
3304 Arathorn: Co-Sysadmin, TheOneRing.net?
3307 ----- Original Message -----
3308 From: "Aragon Gouveia" <aragon@phat.za.net>
3309 To: <ircservices-coding@ircservices.za.net>
3310 Sent: Monday, February 10, 2003 9:22 PM
3311 Subject: [IRCServices Coding] problems with 5.0.9
3316 > The other day I reported the database save bug when ircservices looses its
3317 > uplink. Just upgraded to 5.0.9 and am having another problem...
3319 > When the uplink server closes the connection ircservices does not exit.
3320 > Neither is there any log of such activity. Further more, issuing a
3322 > to the process after the uplink has died only results in "Received
3324 > exiting." being logged, but the process does not die. It takes a SIGKILL
3326 > kill it off. And of course a SIGKILL doesn't go down well with saving the
3327 > database to disk! :)
3329 > Running Unreal 3.2 btw.
3334 > ------------------------------------------------------------------
3335 > To unsubscribe or change your subscription options, visit:
3336 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
3339 From aragon at phat.za.net Mon Feb 10 14:24:48 2003
3340 From: aragon at phat.za.net (Aragon Gouveia)
3341 Date: Sat Oct 23 23:09:50 2004
3342 Subject: [IRCServices Coding] problems with 5.0.9
3343 In-Reply-To: <00fa01c2d14d$7aaf21e0$0600a8c0@mjh75>
3344 References: <20030210212202.GB97537@phat.za.net>
3345 <00fa01c2d14d$7aaf21e0$0600a8c0@mjh75>
3346 Message-ID: <20030210222448.GA3519@phat.za.net>
3348 I can definately reproduce it. It happens every time.
3350 I'm also connecting to localhost (from localhost) to a specified port. I
3351 haven't defined a binding port though.
3353 Can anyone help me debug this? Can attach to a running process with gdb,
3354 but from there I'm not sure what I should be doing.. :)
3361 | By Arathorn <arathorn@theonering.net>
3362 | [ 2003-02-10 23:43 +0200 ]
3363 > I've had this problem too (although I cannot reproduce it at the moment) -
3364 > I've reported it on the non-coding list. Andrew's suggestion there is to
3365 > attach to the hung process with gdb and see what's going on (which I'm going
3366 > to do when it next happens to me).
3368 > That said, I have a suspicion that I may have somehow prevented it; although
3369 > so many variables have been changed I'm not sure what may have helped.
3371 > Off the top of my head:
3373 > 1) I changed services to connect to unreal 3.2 on localhost - explicitly
3374 > specifying the binding port (i.e. connecting from 127.0.0.1:7028 to
3377 > 2) enabled a PingFrequency of 30s across the link to try to keep things
3378 > alive and healthy (i've also had problems with 3.2 complaining about Bad
3379 > File Descriptors on the Services socket when select()ing the FDLIST),
3381 > 3) Tried running services 'plain' from the commandline rather than from a
3383 > start-stop-daemon --start --quiet --pidfile
3384 > /usr/local/lib/ircservices/ircservices.pid \
3385 > --chuid irc:irc --exec /usr/local/sbin/ircservices >
3388 > in a Debian /etc/init.d script.
3390 > Somewhere along there, it's decided to start behaving absolutely fine (after
3391 > consistently hanging after the ircd closed its connection). Services die
3392 > cleanly on a /restart and /die work fine - and for that matter, so does
3393 > /operserv restart, quit & shutdown. With the proviso of some thoroughly
3394 > screwed up intermittent faults with +k modelocks disappearing on registered
3395 > channels after services restarts - and xml-export doing some very mangled
3396 > things. c.f. ircservices@ircservices.za.net.
3398 > ________________________________________________________________
3399 > Matthew Hodgson arathorn@theonering.net Tel: +44 7968 722968
3400 > Arathorn: Co-Sysadmin, TheOneRing.net?
3403 > ----- Original Message -----
3404 > From: "Aragon Gouveia" <aragon@phat.za.net>
3405 > To: <ircservices-coding@ircservices.za.net>
3406 > Sent: Monday, February 10, 2003 9:22 PM
3407 > Subject: [IRCServices Coding] problems with 5.0.9
3412 > > The other day I reported the database save bug when ircservices looses its
3413 > > uplink. Just upgraded to 5.0.9 and am having another problem...
3415 > > When the uplink server closes the connection ircservices does not exit.
3416 > > Neither is there any log of such activity. Further more, issuing a
3418 > > to the process after the uplink has died only results in "Received
3420 > > exiting." being logged, but the process does not die. It takes a SIGKILL
3422 > > kill it off. And of course a SIGKILL doesn't go down well with saving the
3423 > > database to disk! :)
3425 > > Running Unreal 3.2 btw.
3430 > > ------------------------------------------------------------------
3431 > > To unsubscribe or change your subscription options, visit:
3432 > > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
3435 > ------------------------------------------------------------------
3436 > To unsubscribe or change your subscription options, visit:
3437 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
3438 From RT.Mail at verizon.net Mon Feb 10 14:42:13 2003
3439 From: RT.Mail at verizon.net (RT.Mail@verizon.net)
3440 Date: Sat Oct 23 23:09:50 2004
3441 Subject: [IRCServices Coding] problems with 5.0.9
3442 In-Reply-To: <20030210222448.GA3519@phat.za.net>
3443 Message-ID: <20030210224222.OUJT1680.pop018.verizon.net@bofh>
3445 We are having problems also, we are running Unreal3.1.5.1 and the other day the hub died and the services never died, just
3448 < >On Tue, 11 Feb 2003 00:24:48 +0200, Aragon Gouveia wrote:
3449 < > I can definately reproduce it. It happens every time.
3451 < > I'm also connecting to localhost (from localhost) to a specified
3453 < > haven't defined a binding port though.
3455 < > Can anyone help me debug this? Can attach to a running process
3457 < > but from there I'm not sure what I should be doing.. :)
3464 < > | By Arathorn <arathorn@theonering.net>
3465 < > | [ 2003-02-10 23:43
3467 < > > I've had this problem too (although I cannot reproduce it at
3469 < > > I've reported it on the non-coding list. Andrew's suggestion
3471 < > > attach to the hung process with gdb and see what's going on
3472 < > (which I'm going
3473 < > > to do when it next happens to me).
3475 < > > That said, I have a suspicion that I may have somehow
3476 < > prevented it; although
3477 < > > so many variables have been changed I'm not sure what may have
3480 < > > Off the top of my head:
3482 < > > 1) I changed services to connect to unreal 3.2 on localhost -
3484 < > > specifying the binding port (i.e. connecting from
3485 < > 127.0.0.1:7028 to
3486 < > > 127.0.0.1:7029),
3488 < > > 2) enabled a PingFrequency of 30s across the link to try to
3490 < > > alive and healthy (i've also had problems with 3.2 complaining
3492 < > > File Descriptors on the Services socket when select()ing the
3495 < > > 3) Tried running services 'plain' from the commandline rather
3498 < > > start-stop-daemon --start --quiet --pidfile
3499 < > > /usr/local/lib/ircservices/ircservices.pid \
3500 < > > --chuid irc:irc --exec
3501 < > /usr/local/sbin/ircservices >
3502 < > > /dev/null 2>&1
3504 < > > in a Debian /etc/init.d script.
3506 < > > Somewhere along there, it's decided to start behaving
3507 < > absolutely fine (after
3508 < > > consistently hanging after the ircd closed its connection).
3510 < > > cleanly on a /restart and /die work fine - and for that
3512 < > > /operserv restart, quit & shutdown. With the proviso of some
3514 < > > screwed up intermittent faults with +k modelocks disappearing
3516 < > > channels after services restarts - and xml-export doing some
3518 < > > things. c.f. ircservices@ircservices.za.net.
3521 < > ________________________________________________________________
3522 < > > Matthew Hodgson arathorn@theonering.net Tel: +44 7968
3524 < > > Arathorn: Co-Sysadmin, TheOneRing.net?
3527 < > > ----- Original Message -----
3528 < > > From: "Aragon Gouveia" <aragon@phat.za.net>
3529 < > > To: <ircservices-coding@ircservices.za.net>
3530 < > > Sent: Monday, February 10, 2003 9:22 PM
3531 < > > Subject: [IRCServices Coding] problems with 5.0.9
3536 < > > > The other day I reported the database save bug when
3537 < > ircservices looses its
3538 < > > > uplink. Just upgraded to 5.0.9 and am having another
3541 < > > > When the uplink server closes the connection ircservices
3543 < > > > Neither is there any log of such activity. Further more,
3546 < > > > to the process after the uplink has died only results in
3549 < > > > exiting." being logged, but the process does not die. It
3552 < > > > kill it off. And of course a SIGKILL doesn't go down well
3554 < > > > database to disk! :)
3556 < > > > Running Unreal 3.2 btw.
3561 < > > > -------------------------------------------------------------
3563 < > > > To unsubscribe or change your subscription options, visit:
3564 < > > > http://www.ircservices.za.net/mailman/listinfo/ircservices-
3568 < > > ---------------------------------------------------------------
3570 < > > To unsubscribe or change your subscription options, visit:
3571 < > > http://www.ircservices.za.net/mailman/listinfo/ircservices-
3573 < > -----------------------------------------------------------------
3575 < > To unsubscribe or change your subscription options, visit:
3576 < > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
3580 From john at cosmicfire.net Mon Feb 10 16:47:18 2003
3581 From: john at cosmicfire.net (John Edrington)
3582 Date: Sat Oct 23 23:09:50 2004
3583 Subject: [IRCServices Coding] clear channel modes
3584 Message-ID: <000101c2d167$23ebae40$020010ac@paladin>
3587 I don't know if this topic has been discussed, so please pardon me if it has.
3589 My observation is that when a clear channel modes command is issued, either via chanserv or operserv, chanserv will automatically reset the channel modes to whatever the mlock is set to. (See below)
3591 Certainly, I can see the reasoning behind chanserv prohibiting a non-ircop from effectively disabling the mlocks. Conversely, I feel that if an ircop has to issue the clearmodes command, perhaps the ircop needs to evade the modes that are set by chanserv mlock.
3593 I purpose that, if possible, when operserv clearmodes is used, services does not enforce the mlock, perhaps for a certain amount of time, until someone changes the channel modes, or some other determining factor.
3597 [msg(chanserv)] clear #bopm modes
3598 ??? mode/#bopm [-sO] by ChanServ
3599 ??? mode/#bopm [+sO] by ChanServ
3600 -ChanServ(services@abc.net)- All modes on channel #bopm have been reset. [msg(operserv)] clearmodes #bopm
3601 ??? mode/#bopm [-sO] by OperServ
3602 ??? mode/#bopm [+sO] by ChanServ
3603 -OperServ(services@abc.net)- Binary modes, bans, and exceptions cleared from channel #bopm.
3611 From achurch at achurch.org Tue Feb 11 18:18:02 2003
3612 From: achurch at achurch.org (Andrew Church)
3613 Date: Sat Oct 23 23:09:50 2004
3614 Subject: [IRCServices Coding] Channel registration limit:Default (2)
3615 In-Reply-To: <3E480186.8060209@viaraix.net>
3616 Message-ID: <3e48c010.36750@mail.achurch.org>
3618 This is being considered for a future version, but is fairly low on
3627 >I emailed a few months ago about the "Channel registration limit:Default
3628 >(2)" part and was told this was on todo list (allowing users a different
3629 >ammount of channels)
3631 >Has this been done yet?
3633 >cant check myself...
3636 >You don't have permission to access /Changes on this server.
3638 >Apache/1.3.27 Server at www.ircservices.za.net Port 80
3643 >------------------------------------------------------------------
3644 >To unsubscribe or change your subscription options, visit:
3645 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
3646 From achurch at achurch.org Tue Feb 11 18:20:23 2003
3647 From: achurch at achurch.org (Andrew Church)
3648 Date: Sat Oct 23 23:09:50 2004
3649 Subject: [IRCServices Coding] clear channel modes
3650 In-Reply-To: <000101c2d167$23ebae40$020010ac@paladin>
3651 Message-ID: <3e48c0ba.36761@mail.achurch.org>
3653 This has been discussed before; it's designed behavior.
3660 >I don't know if this topic has been discussed, so please pardon me if it
3663 >My observation is that when a clear channel modes command is issued,
3664 >either via chanserv or operserv, chanserv will automatically reset the
3665 >channel modes to whatever the mlock is set to. (See below)
3667 >Certainly, I can see the reasoning behind chanserv prohibiting a
3668 >non-ircop from effectively disabling the mlocks. Conversely, I feel that
3669 >if an ircop has to issue the clearmodes command, perhaps the ircop needs
3670 >to evade the modes that are set by chanserv mlock.
3672 >I purpose that, if possible, when operserv clearmodes is used, services
3673 >does not enforce the mlock, perhaps for a certain amount of time, until
3674 >someone changes the channel modes, or some other determining factor.
3678 >[msg(chanserv)] clear #bopm modes
3679 >
\e$BchRQ,d/y
\e(B mode/#bopm [-sO] by ChanServ
3680 >
\e$BchRQ,d/y
\e(B mode/#bopm [+sO] by ChanServ
3681 >-ChanServ(services@abc.net)- All modes on channel #bopm have been reset.
3682 >[msg(operserv)] clearmodes #bopm
3683 >
\e$BchRQ,d/y
\e(B mode/#bopm [-sO] by OperServ
3684 >
\e$BchRQ,d/y
\e(B mode/#bopm [+sO] by ChanServ
3685 >-OperServ(services@abc.net)- Binary modes, bans, and exceptions cleared
3686 >from channel #bopm.
3692 >john@cosmicfire.net
3694 >------------------------------------------------------------------
3695 >To unsubscribe or change your subscription options, visit:
3696 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
3697 From alisor at softhome.net Tue Feb 11 06:18:00 2003
3698 From: alisor at softhome.net (Ali Sor)
3699 Date: Sat Oct 23 23:09:50 2004
3700 Subject: [IRCServices Coding] problems with 5.0.9
3701 References: <20030210224222.OUJT1680.pop018.verizon.net@bofh>
3702 Message-ID: <001801c2d1d8$6c94afe0$0100a8c0@control>
3705 We have the same problem too. We are using Unreal3.2 as ircd. But cant
3706 reproduce it. Hub stops but services continues. We cant connect it or
3707 anything else after ircd come back. Services stays alone.
3709 ----- Original Message -----
3710 From: <RT.Mail@verizon.net>
3711 To: "IRC Services Coding Mailing List"
3712 <ircservices-coding@ircservices.za.net>
3713 Sent: Tuesday, February 11, 2003 12:42 AM
3714 Subject: Re: [IRCServices Coding] problems with 5.0.9
3717 We are having problems also, we are running Unreal3.1.5.1 and the other day
3718 the hub died and the services never died, just
3721 < >On Tue, 11 Feb 2003 00:24:48 +0200, Aragon Gouveia wrote:
3722 < > I can definately reproduce it. It happens every time.
3724 < > I'm also connecting to localhost (from localhost) to a specified
3726 < > haven't defined a binding port though.
3728 < > Can anyone help me debug this? Can attach to a running process
3730 < > but from there I'm not sure what I should be doing.. :)
3737 < > | By Arathorn <arathorn@theonering.net>
3738 < > | [ 2003-02-10 23:43
3740 < > > I've had this problem too (although I cannot reproduce it at
3742 < > > I've reported it on the non-coding list. Andrew's suggestion
3744 < > > attach to the hung process with gdb and see what's going on
3745 < > (which I'm going
3746 < > > to do when it next happens to me).
3748 < > > That said, I have a suspicion that I may have somehow
3749 < > prevented it; although
3750 < > > so many variables have been changed I'm not sure what may have
3753 < > > Off the top of my head:
3755 < > > 1) I changed services to connect to unreal 3.2 on localhost -
3757 < > > specifying the binding port (i.e. connecting from
3758 < > 127.0.0.1:7028 to
3759 < > > 127.0.0.1:7029),
3761 < > > 2) enabled a PingFrequency of 30s across the link to try to
3763 < > > alive and healthy (i've also had problems with 3.2 complaining
3765 < > > File Descriptors on the Services socket when select()ing the
3768 < > > 3) Tried running services 'plain' from the commandline rather
3771 < > > start-stop-daemon --start --quiet --pidfile
3772 < > > /usr/local/lib/ircservices/ircservices.pid \
3773 < > > --chuid irc:irc --exec
3774 < > /usr/local/sbin/ircservices >
3775 < > > /dev/null 2>&1
3777 < > > in a Debian /etc/init.d script.
3779 < > > Somewhere along there, it's decided to start behaving
3780 < > absolutely fine (after
3781 < > > consistently hanging after the ircd closed its connection).
3783 < > > cleanly on a /restart and /die work fine - and for that
3785 < > > /operserv restart, quit & shutdown. With the proviso of some
3787 < > > screwed up intermittent faults with +k modelocks disappearing
3789 < > > channels after services restarts - and xml-export doing some
3791 < > > things. c.f. ircservices@ircservices.za.net.
3794 < > ________________________________________________________________
3795 < > > Matthew Hodgson arathorn@theonering.net Tel: +44 7968
3797 < > > Arathorn: Co-Sysadmin, TheOneRing.net?
3800 < > > ----- Original Message -----
3801 < > > From: "Aragon Gouveia" <aragon@phat.za.net>
3802 < > > To: <ircservices-coding@ircservices.za.net>
3803 < > > Sent: Monday, February 10, 2003 9:22 PM
3804 < > > Subject: [IRCServices Coding] problems with 5.0.9
3809 < > > > The other day I reported the database save bug when
3810 < > ircservices looses its
3811 < > > > uplink. Just upgraded to 5.0.9 and am having another
3814 < > > > When the uplink server closes the connection ircservices
3816 < > > > Neither is there any log of such activity. Further more,
3819 < > > > to the process after the uplink has died only results in
3822 < > > > exiting." being logged, but the process does not die. It
3825 < > > > kill it off. And of course a SIGKILL doesn't go down well
3827 < > > > database to disk! :)
3829 < > > > Running Unreal 3.2 btw.
3834 < > > > -------------------------------------------------------------
3836 < > > > To unsubscribe or change your subscription options, visit:
3837 < > > > http://www.ircservices.za.net/mailman/listinfo/ircservices-
3841 < > > ---------------------------------------------------------------
3843 < > > To unsubscribe or change your subscription options, visit:
3844 < > > http://www.ircservices.za.net/mailman/listinfo/ircservices-
3846 < > -----------------------------------------------------------------
3848 < > To unsubscribe or change your subscription options, visit:
3849 < > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
3853 ------------------------------------------------------------------
3854 To unsubscribe or change your subscription options, visit:
3855 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
3859 Outgoing mail is certified Virus Free.
3860 Checked by AVG anti-virus system (http://www.grisoft.com).
3861 Version: 6.0.449 / Virus Database: 251 - Release Date: 27.01.2003
3863 From irc at kgn.ru Wed Feb 12 21:03:23 2003
3864 From: irc at kgn.ru (KriegSnake)
3865 Date: Sat Oct 23 23:09:50 2004
3866 Subject: [IRCServices Coding] logonnews list = services crash
3867 Message-ID: <6887528138.20030213100323@kgn.ru>
3870 I have a some problem
3872 [Feb 13 04:47:03 2003] operserv/main: Sert: logonnews
3873 [Feb 13 04:47:07 2003] operserv/main: Sert: logonnews list
3874 [Feb 13 04:47:07 2003] PANIC! buffer = :Sert ! operserv :logonnews list
3875 [Feb 13 04:47:07 2003] Services terminating: Segmentation fault
3877 I am using ircservices 5.0.6
3882 From achurch at achurch.org Fri Feb 14 21:17:10 2003
3883 From: achurch at achurch.org (Andrew Church)
3884 Date: Sat Oct 23 23:09:50 2004
3885 Subject: [IRCServices Coding] problems with 5.0.9
3886 In-Reply-To: <001801c2d1d8$6c94afe0$0100a8c0@control>
3887 Message-ID: <3e4ce44e.43577@mail.achurch.org>
3889 Fixed, thanks (to you and everyone else who reported it) for the
3897 >We have the same problem too. We are using Unreal3.2 as ircd. But cant
3898 >reproduce it. Hub stops but services continues. We cant connect it or
3899 >anything else after ircd come back. Services stays alone.
3901 >----- Original Message -----
3902 >From: <RT.Mail@verizon.net>
3903 >To: "IRC Services Coding Mailing List"
3904 ><ircservices-coding@ircservices.za.net>
3905 >Sent: Tuesday, February 11, 2003 12:42 AM
3906 >Subject: Re: [IRCServices Coding] problems with 5.0.9
3909 >We are having problems also, we are running Unreal3.1.5.1 and the other day
3910 >the hub died and the services never died, just
3913 >< >On Tue, 11 Feb 2003 00:24:48 +0200, Aragon Gouveia wrote:
3914 >< > I can definately reproduce it. It happens every time.
3916 >< > I'm also connecting to localhost (from localhost) to a specified
3918 >< > haven't defined a binding port though.
3920 >< > Can anyone help me debug this? Can attach to a running process
3922 >< > but from there I'm not sure what I should be doing.. :)
3929 >< > | By Arathorn <arathorn@theonering.net>
3930 >< > | [ 2003-02-10 23:43
3932 >< > > I've had this problem too (although I cannot reproduce it at
3934 >< > > I've reported it on the non-coding list. Andrew's suggestion
3936 >< > > attach to the hung process with gdb and see what's going on
3937 >< > (which I'm going
3938 >< > > to do when it next happens to me).
3940 >< > > That said, I have a suspicion that I may have somehow
3941 >< > prevented it; although
3942 >< > > so many variables have been changed I'm not sure what may have
3945 >< > > Off the top of my head:
3947 >< > > 1) I changed services to connect to unreal 3.2 on localhost -
3949 >< > > specifying the binding port (i.e. connecting from
3950 >< > 127.0.0.1:7028 to
3951 >< > > 127.0.0.1:7029),
3953 >< > > 2) enabled a PingFrequency of 30s across the link to try to
3955 >< > > alive and healthy (i've also had problems with 3.2 complaining
3957 >< > > File Descriptors on the Services socket when select()ing the
3960 >< > > 3) Tried running services 'plain' from the commandline rather
3963 >< > > start-stop-daemon --start --quiet --pidfile
3964 >< > > /usr/local/lib/ircservices/ircservices.pid \
3965 >< > > --chuid irc:irc --exec
3966 >< > /usr/local/sbin/ircservices >
3967 >< > > /dev/null 2>&1
3969 >< > > in a Debian /etc/init.d script.
3971 >< > > Somewhere along there, it's decided to start behaving
3972 >< > absolutely fine (after
3973 >< > > consistently hanging after the ircd closed its connection).
3975 >< > > cleanly on a /restart and /die work fine - and for that
3976 >< > matter, so does
3977 >< > > /operserv restart, quit & shutdown. With the proviso of some
3979 >< > > screwed up intermittent faults with +k modelocks disappearing
3981 >< > > channels after services restarts - and xml-export doing some
3983 >< > > things. c.f. ircservices@ircservices.za.net.
3986 >< > ________________________________________________________________
3987 >< > > Matthew Hodgson arathorn@theonering.net Tel: +44 7968
3989 >< > > Arathorn: Co-Sysadmin, TheOneRing.net?
3992 >< > > ----- Original Message -----
3993 >< > > From: "Aragon Gouveia" <aragon@phat.za.net>
3994 >< > > To: <ircservices-coding@ircservices.za.net>
3995 >< > > Sent: Monday, February 10, 2003 9:22 PM
3996 >< > > Subject: [IRCServices Coding] problems with 5.0.9
4001 >< > > > The other day I reported the database save bug when
4002 >< > ircservices looses its
4003 >< > > > uplink. Just upgraded to 5.0.9 and am having another
4006 >< > > > When the uplink server closes the connection ircservices
4008 >< > > > Neither is there any log of such activity. Further more,
4011 >< > > > to the process after the uplink has died only results in
4014 >< > > > exiting." being logged, but the process does not die. It
4015 >< > takes a SIGKILL
4017 >< > > > kill it off. And of course a SIGKILL doesn't go down well
4018 >< > with saving the
4019 >< > > > database to disk! :)
4021 >< > > > Running Unreal 3.2 btw.
4026 >< > > > -------------------------------------------------------------
4028 >< > > > To unsubscribe or change your subscription options, visit:
4029 >< > > > http://www.ircservices.za.net/mailman/listinfo/ircservices-
4033 >< > > ---------------------------------------------------------------
4035 >< > > To unsubscribe or change your subscription options, visit:
4036 >< > > http://www.ircservices.za.net/mailman/listinfo/ircservices-
4038 >< > -----------------------------------------------------------------
4040 >< > To unsubscribe or change your subscription options, visit:
4041 >< > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4045 >------------------------------------------------------------------
4046 >To unsubscribe or change your subscription options, visit:
4047 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4051 >Outgoing mail is certified Virus Free.
4052 >Checked by AVG anti-virus system (http://www.grisoft.com).
4053 >Version: 6.0.449 / Virus Database: 251 - Release Date: 27.01.2003
4055 >------------------------------------------------------------------
4056 >To unsubscribe or change your subscription options, visit:
4057 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4058 From Craig at chatspike.net Wed Feb 19 01:52:17 2003
4059 From: Craig at chatspike.net (Craig McLure)
4060 Date: Sat Oct 23 23:09:50 2004
4061 Subject: [IRCServices Coding] Connection Protocols..
4062 Message-ID: <20030219095223.KUWK2341.mta05-svc.ntlworld.com@i-br0ked-it>
4064 After a lot of discussion amongst our coders and supporters, the InspIRCd project has decided to use "Redundant Linking" (aka, Dynamic routing (http://www.inspircd.org/forum/index.php?act=ST&f=13&t=9&s=70a4cc18402781a33b2b5c238acfc558)) via the UDP port type as our main server -> server connection, reasons at previous URL.
4066 Our main problem, is looking through the protocol modules, there is no way to specify the type of port used, have we over looked anything, if not, would it be somehow possible to move how services connects to a server to the protocol files, or possibly a way to override the default?
4068 -----------------------------------------------------------------------
4069 Craig McLure - Craig@chatspike.net
4070 ChatSpike - The users network: http://www.chatspike.net
4071 InspIRCd - Modular IRC server: http://www.inspircd.org
4072 -----------------------------------------------------------------------
4076 From achurch at achurch.org Wed Feb 19 20:27:25 2003
4077 From: achurch at achurch.org (Andrew Church)
4078 Date: Sat Oct 23 23:09:50 2004
4079 Subject: [IRCServices Coding] Connection Protocols..
4080 In-Reply-To: <20030219095223.KUWK2341.mta05-svc.ntlworld.com@i-br0ked-it>
4081 Message-ID: <3e536af8.72754@mail.achurch.org>
4083 Before you even get to the connection type (and UDP is probably more
4084 trouble than it's worth unless you really do it right), Services can't
4085 handle cycles in the IRC server network. I'm not going to touch this--you
4086 can try if you want, but if it blows up in your face you get to clean up
4087 the mess while we all laugh at you. ;)
4093 >After a lot of discussion amongst our coders and supporters, the InspIRCd project has decided to use "Redundant Linking" (aka, Dynamic routing (http://www.inspircd.org/forum/index.php?act=ST&f=13&t=9&s=70a4cc18402781a33b2b5c238acfc558)) via the UDP port t
4094 >ype as our main server -> server connection, reasons at previous URL.
4096 >Our main problem, is looking through the protocol modules, there is no way to specify the type of port used, have we over looked anything, if not, would it be somehow possible to move how services connects to a server to the protocol files, or possibly a
4097 >way to override the default?
4099 >-----------------------------------------------------------------------
4100 >Craig McLure - Craig@chatspike.net
4101 >ChatSpike - The users network: http://www.chatspike.net
4102 >InspIRCd - Modular IRC server: http://www.inspircd.org
4103 >-----------------------------------------------------------------------
4107 >------------------------------------------------------------------
4108 From chris at monkeyircd.org Wed Feb 19 05:52:38 2003
4109 From: chris at monkeyircd.org (Chris Plant)
4110 Date: Sat Oct 23 23:09:50 2004
4111 Subject: [IRCServices Coding] Connection Protocols..
4112 In-Reply-To: <20030219095223.KUWK2341.mta05-svc.ntlworld.com@i-br0ked-it>
4113 References: <20030219095223.KUWK2341.mta05-svc.ntlworld.com@i-br0ked-it>
4114 Message-ID: <1045662758.1395.0.camel@hermes>
4116 On Wed, 2003-02-19 at 09:52, Craig McLure wrote:
4117 > After a lot of discussion amongst our coders and supporters, the InspIRCd project has decided to use "Redundant Linking" (aka, Dynamic routing (http://www.inspircd.org/forum/index.php?act=ST&f=13&t=9&s=70a4cc18402781a33b2b5c238acfc558)) via the UDP port type as our main server -> server connection, reasons at previous URL.
4119 > Our main problem, is looking through the protocol modules, there is no way to specify the type of port used, have we over looked anything, if not, would it be somehow possible to move how services connects to a server to the protocol files, or possibly a way to override the default?
4120 MonkeyIRCD is looking to support something like that in the next
4121 version, though its planned to handle servers that don't support this
4122 feature using limited reporting of links. IE we only tell non-complient
4123 servers about our current link.
4126 > -----------------------------------------------------------------------
4127 > Craig McLure - Craig@chatspike.net
4128 > ChatSpike - The users network: http://www.chatspike.net
4129 > InspIRCd - Modular IRC server: http://www.inspircd.org
4130 > -----------------------------------------------------------------------
4134 > ------------------------------------------------------------------
4135 > To unsubscribe or change your subscription options, visit:
4136 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4138 Chris Plant <chris@monkeyircd.org>
4141 From RT.Mail at verizon.net Sat Feb 22 11:32:41 2003
4142 From: RT.Mail at verizon.net (RT.Mail@verizon.net)
4143 Date: Sat Oct 23 23:09:50 2004
4144 Subject: [IRCServices Coding] None
4145 In-Reply-To: <3e4ce44e.43577@mail.achurch.org>
4146 Message-ID: <20030222193246.NMMC16306.out005.verizon.net@bofh>
4148 This is the third time this has happened. I kill about 400 spam bots in a few seconds and the services die. [Feb 22 13:06:45
4149 2003] FATAL: introduce_user() loop detected. Thats all that is in the logfile. We are running Unreal3.1.5.1. (it just happend again
4150 with a lot less then 400) it seems to just happen when you issue a bunch of kills at once.
4152 From aragon at phat.za.net Sun Feb 23 02:42:03 2003
4153 From: aragon at phat.za.net (Aragon Gouveia)
4154 Date: Sat Oct 23 23:09:50 2004
4155 Subject: [IRCServices Coding] lockfile problem..
4156 Message-ID: <20030223104203.GA20750@phat.za.net>
4160 Just upgraded to 5.0.11. My previous problems have been solved, but now
4161 something else is not working..
4163 If I kill ircservices' uplink it tries to write to its databases but fails
4164 with this log entry:
4166 [Feb 23 12:35:43 2003] warning: unable to lock data directory, not updating databases: Undefined error: 0
4167 [Feb 23 12:35:43 2003] Read error from server: Connection reset by peer
4170 Looking in the libdir there's a .lock file with no permissions:
4172 ---------- 1 blabber irc 0 Feb 23 12:35 .lock
4175 Starting it all up again and trying the same thing results in failure of
4178 [Feb 23 12:29:42 2003] warning: data directory is locked, not updating databases
4180 Lockfile needs to be removed manually...
4183 When performing a manual update via operserv this doesn't happen. Neither
4184 when shutting down ircservices gracefully. Only when the uplink dies
4190 From RT.Mail at verizon.net Sun Feb 23 11:22:31 2003
4191 From: RT.Mail at verizon.net (RT.Mail@verizon.net)
4192 Date: Sat Oct 23 23:09:50 2004
4193 Subject: [IRCServices Coding] None
4194 In-Reply-To: <20030223104203.GA20750@phat.za.net>
4195 Message-ID: <20030223192236.QUDP2505.out004.verizon.net@bofh>
4197 Andrew are you adding support for additional IRCd's at all? We want to switch to a new IRCd, however the one we are thinking of
4198 isn't supported right now.
4201 From kfiresun at ix.netcom.com Sun Feb 23 13:22:50 2003
4202 From: kfiresun at ix.netcom.com (Kelmar K. Firesun)
4203 Date: Sat Oct 23 23:09:50 2004
4204 Subject: [IRCServices Coding] None
4205 References: <20030223192236.QUDP2505.out004.verizon.net@bofh>
4206 Message-ID: <004601c2db81$b83ee930$6ed387d8@bahamut>
4208 Just out of curiosity, which IRCd are you planing to move to?
4210 Kelmar K. Firesun (IRL: Bryce Simonds)
4211 Assistant Admin: dream.esper.net (www.esper.net)
4213 ----- Original Message -----
4214 From: <RT.Mail@verizon.net>
4215 To: "IRC Services Coding Mailing List"
4216 <ircservices-coding@ircservices.za.net>
4217 Sent: Sunday, February 23, 2003 1:22 PM
4218 Subject: [IRCServices Coding] None
4221 Andrew are you adding support for additional IRCd's at all? We want to
4222 switch to a new IRCd, however the one we are thinking of
4223 isn't supported right now.
4226 ------------------------------------------------------------------
4227 To unsubscribe or change your subscription options, visit:
4228 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4230 From achurch at achurch.org Mon Feb 24 09:15:21 2003
4231 From: achurch at achurch.org (Andrew Church)
4232 Date: Sat Oct 23 23:09:50 2004
4233 Subject: [IRCServices Coding] lockfile problem..
4234 In-Reply-To: <20030223104203.GA20750@phat.za.net>
4235 Message-ID: <3e596429.27304@mail.achurch.org>
4237 Fixed, thanks for the report.
4245 >Just upgraded to 5.0.11. My previous problems have been solved, but now
4246 >something else is not working..
4248 >If I kill ircservices' uplink it tries to write to its databases but fails
4249 >with this log entry:
4251 >[Feb 23 12:35:43 2003] warning: unable to lock data directory, not updating databases: Undefined error: 0
4252 >[Feb 23 12:35:43 2003] Read error from server: Connection reset by peer
4255 >Looking in the libdir there's a .lock file with no permissions:
4257 >---------- 1 blabber irc 0 Feb 23 12:35 .lock
4260 >Starting it all up again and trying the same thing results in failure of
4263 >[Feb 23 12:29:42 2003] warning: data directory is locked, not updating databases
4265 >Lockfile needs to be removed manually...
4268 >When performing a manual update via operserv this doesn't happen. Neither
4269 >when shutting down ircservices gracefully. Only when the uplink dies
4275 >------------------------------------------------------------------
4276 >To unsubscribe or change your subscription options, visit:
4277 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4278 From achurch at achurch.org Mon Feb 24 09:52:16 2003
4279 From: achurch at achurch.org (Andrew Church)
4280 Date: Sat Oct 23 23:09:50 2004
4281 Subject: [IRCServices Coding] idea for xml part
4282 In-Reply-To: <004101c2b81c$011d7ce0$0201000a@thebeastnet>
4283 Message-ID: <3e59f898.30523@mail.achurch.org>
4286 >i thinking to use it than to grep this part from the xml file
4287 >and check this with the current version on the backup server
4288 >so that this can start a update script that will update that
4289 >server if the versions are different
4291 I don't know about you, but I'd be very, very afraid to have a script
4292 that automatically compiled and installed programs on my server. Even
4293 setting aside the threat of someone tricking your script into doing nasty
4294 things, I might accidentally release a version that corrupts your data
4295 files, and then boom, you're screwed. (I wouldn't do this intentionally,
4296 of course, but I'm only human, and I make mistakes occasionally.)
4299 >the version check can also be used for newer release that have
4300 >newer/beter options that are not in the older versions so
4301 >the --import commandline option can check if the xml dump
4302 >is suitable for that version of ircservices
4304 It's already designed so that missing information will be set to
4305 appropriate values (unless I screwed up somewhere). There's no need for
4306 an extra check of this kind.
4311 From master at xchat.gr Tue Feb 25 05:27:15 2003
4312 From: master at xchat.gr (George Stamatiou)
4313 Date: Sat Oct 23 23:09:50 2004
4314 Subject: [IRCServices Coding] SQLINE request
4315 Message-ID: <002601c2dcd1$a0d2cb80$0100a8c0@zeus>
4318 When i add a channel in SQLINE list, users trying to join get the error...
4319 #testing Cannot join channel (Reserved nickname: Reserved for Ircoperators).
4320 I think that the Reserved nickname shouldn't be.
4331 From nothing at psychopat.org Tue Feb 25 08:06:48 2003
4332 From: nothing at psychopat.org (Marc-Andre A. Fuentes)
4333 Date: Sat Oct 23 23:09:50 2004
4334 Subject: [IRCServices Coding] SQLINE request
4335 In-Reply-To: <002601c2dcd1$a0d2cb80$0100a8c0@zeus>
4336 Message-ID: <Pine.LNX.4.44.0302251105010.16385-100000@psychopat.org>
4340 isn't a problem of the ircd and not of the ircservices? ....
4341 the reply you got is from the server, not from the services
4342 and also, maybe your ircserver send the same raw number for qlined nick
4343 and channel and your irc-client show it as being only an error for
4348 On Tue, 25 Feb 2003, George Stamatiou wrote:
4351 > When i add a channel in SQLINE list, users trying to join get the error...
4352 > #testing Cannot join channel (Reserved nickname: Reserved for Ircoperators).
4353 > I think that the Reserved nickname shouldn't be.
4364 > ------------------------------------------------------------------
4365 > To unsubscribe or change your subscription options, visit:
4366 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4369 From master at xchat.gr Tue Feb 25 09:28:48 2003
4370 From: master at xchat.gr (George Stamatiou)
4371 Date: Sat Oct 23 23:09:50 2004
4372 Subject: [IRCServices Coding] SQLINE request
4373 References: <Pine.LNX.4.44.0302251105010.16385-100000@psychopat.org>
4374 Message-ID: <001001c2dcf3$5d004e60$0100a8c0@zeus>
4376 I don't think that it's my ircd (bahamut 1.4.35) problem.
4377 I tried /os raw sqline #testing :reserved for ircoperators,
4378 and after i receive,
4379 #testing Cannot join channel (reserved for Ircoperators)
4385 ----- Original Message -----
4386 From: "Marc-Andre A. Fuentes" <nothing@psychopat.org>
4387 To: "IRC Services Coding Mailing List" <ircservices-coding@ircservices.za.net>
4388 Sent: Tuesday, February 25, 2003 6:06 PM
4389 Subject: Re: [IRCServices Coding] SQLINE request
4394 : isn't a problem of the ircd and not of the ircservices? ....
4395 : the reply you got is from the server, not from the services
4396 : and also, maybe your ircserver send the same raw number for qlined nick
4397 : and channel and your irc-client show it as being only an error for
4402 : On Tue, 25 Feb 2003, George Stamatiou wrote:
4405 : > When i add a channel in SQLINE list, users trying to join get the error...
4406 : > #testing Cannot join channel (Reserved nickname: Reserved for Ircoperators).
4407 : > I think that the Reserved nickname shouldn't be.
4412 : > George Stamatiou
4418 : > ------------------------------------------------------------------
4419 : > To unsubscribe or change your subscription options, visit:
4420 : > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4423 : ------------------------------------------------------------------
4424 : To unsubscribe or change your subscription options, visit:
4425 : http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4429 From master at xchat.gr Tue Feb 25 10:19:37 2003
4430 From: master at xchat.gr (George Stamatiou)
4431 Date: Sat Oct 23 23:09:50 2004
4432 Subject: [IRCServices Coding] global notice
4433 Message-ID: <000701c2dcfa$7f477780$0100a8c0@zeus>
4435 Another problem is that services does not send global notice.
4436 Nothing happens at all.
4437 I'm using ircservices 5.0.11 and bahamut 1.4.35
4445 From RT.Mail at verizon.net Tue Feb 25 10:23:43 2003
4446 From: RT.Mail at verizon.net (RT.Mail@verizon.net)
4447 Date: Sat Oct 23 23:09:50 2004
4448 Subject: [IRCServices Coding] global notice
4449 In-Reply-To: <000701c2dcfa$7f477780$0100a8c0@zeus>
4450 Message-ID: <20030225182349.LHQK6884.pop018.verizon.net@bofh>
4452 We are using that, global works for us. However we are having a problem with szline, it doesn't seem to work at all.
4454 From master at xchat.gr Tue Feb 25 10:45:19 2003
4455 From: master at xchat.gr (George Stamatiou)
4456 Date: Sat Oct 23 23:09:50 2004
4457 Subject: [IRCServices Coding] global notice
4458 References: <20030225182349.LHQK6884.pop018.verizon.net@bofh>
4459 Message-ID: <001101c2dcfe$0cb18680$0100a8c0@zeus>
4461 SZLINES works fine on me.
4462 *** Global -- from OperServ: Pr|nCe added an SZLINE for 212.205.240.48 (expires in 1 minute)
4463 -OperServ- 212.205.240.48 added to SZLINE list.
4464 *** Notice -- Received KILL message for George!zeus@212.205.240.48. From OperServ Path: OperServ
4465 (Z-lined.Send an email to webmaster@xchat.gr .Reason: test)
4467 ----- Original Message -----
4468 From: <RT.Mail@verizon.net>
4469 To: "IRC Services Coding Mailing List" <ircservices-coding@ircservices.za.net>
4470 Sent: Tuesday, February 25, 2003 8:23 PM
4471 Subject: Re: [IRCServices Coding] global notice
4474 We are using that, global works for us. However we are having a problem with szline, it doesn't seem
4477 ------------------------------------------------------------------
4478 To unsubscribe or change your subscription options, visit:
4479 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4483 From rg at tcslon.com Tue Feb 25 11:02:07 2003
4484 From: rg at tcslon.com (Russell Garrett)
4485 Date: Sat Oct 23 23:09:50 2004
4486 Subject: [IRCServices Coding] global notice
4487 In-Reply-To: <001101c2dcfe$0cb18680$0100a8c0@zeus>
4488 Message-ID: <NDBBLDHKLKMANPGMACIGCEGJDFAA.rg@tcslon.com>
4490 Note that SZLINES are removed in bahamut 1.4.35, because akills now have all
4491 the capabilities of them.
4493 > -----Original Message-----
4494 > From: ircservices-coding-bounces@ircservices.za.net
4495 > [mailto:ircservices-coding-bounces@ircservices.za.net]On Behalf Of
4497 > Sent: 25 February 2003 18:45
4498 > To: RT.Mail@verizon.net; ircservices-coding@ircservices.za.net
4499 > Subject: Re: [IRCServices Coding] global notice
4502 > SZLINES works fine on me.
4503 > *** Global -- from OperServ: Pr|nCe added an SZLINE for
4504 > 212.205.240.48 (expires in 1 minute)
4505 > -OperServ- 212.205.240.48 added to SZLINE list.
4506 > *** Notice -- Received KILL message for
4507 > George!zeus@212.205.240.48. From OperServ Path: OperServ
4508 > (Z-lined.Send an email to webmaster@xchat.gr .Reason: test)
4510 > ----- Original Message -----
4511 > From: <RT.Mail@verizon.net>
4512 > To: "IRC Services Coding Mailing List"
4513 > <ircservices-coding@ircservices.za.net>
4514 > Sent: Tuesday, February 25, 2003 8:23 PM
4515 > Subject: Re: [IRCServices Coding] global notice
4518 > We are using that, global works for us. However we are having a
4519 > problem with szline, it doesn't seem
4522 > ------------------------------------------------------------------
4523 > To unsubscribe or change your subscription options, visit:
4524 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4528 > ------------------------------------------------------------------
4529 > To unsubscribe or change your subscription options, visit:
4530 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4533 From RT.Mail at verizon.net Tue Feb 25 16:35:10 2003
4534 From: RT.Mail at verizon.net (RT.Mail@verizon.net)
4535 Date: Sat Oct 23 23:09:50 2004
4536 Subject: [IRCServices Coding] global notice
4537 In-Reply-To: <NDBBLDHKLKMANPGMACIGCEGJDFAA.rg@tcslon.com>
4538 Message-ID: <20030226003511.GBBL8663.out003.verizon.net@bofh>
4540 We are running bahamut-1.4(35). However ircservices is doing all the killing its not adding akills to the ircd... I'm not sure what
4541 it is supposed to do exactly cause we just switched to bahamut but if somebody could give me some help id appreciate it.
4543 < >On Tue, 25 Feb 2003 19:02:07 -0000, Russell Garrett wrote:
4544 < > Note that SZLINES are removed in bahamut 1.4.35, because akills
4546 < > the capabilities of them.
4548 < > > -----Original Message-----
4549 < > > From: ircservices-coding-bounces@ircservices.za.net
4550 < > > [mailto:ircservices-coding-bounces@ircservices.za.net]On
4552 < > > George Stamatiou
4553 < > > Sent: 25 February 2003 18:45
4554 < > > To: RT.Mail@verizon.net; ircservices-coding@ircservices.za.net
4555 < > > Subject: Re: [IRCServices Coding] global notice
4558 < > > SZLINES works fine on me.
4559 < > > *** Global -- from OperServ: Pr|nCe added an SZLINE for
4560 < > > 212.205.240.48 (expires in 1 minute)
4561 < > > -OperServ- 212.205.240.48 added to SZLINE list.
4562 < > > *** Notice -- Received KILL message for
4563 < > > George!zeus@212.205.240.48. From OperServ Path: OperServ
4564 < > > (Z-lined.Send an email to webmaster@xchat.gr .Reason: test)
4566 < > > ----- Original Message -----
4567 < > > From: <RT.Mail@verizon.net>
4568 < > > To: "IRC Services Coding Mailing List"
4569 < > > <ircservices-coding@ircservices.za.net>
4570 < > > Sent: Tuesday, February 25, 2003 8:23 PM
4571 < > > Subject: Re: [IRCServices Coding] global notice
4574 < > > We are using that, global works for us. However we are having a
4575 < > > problem with szline, it doesn't seem
4576 < > > to work at all.
4578 < > > ---------------------------------------------------------------
4580 < > > To unsubscribe or change your subscription options, visit:
4581 < > > http://www.ircservices.za.net/mailman/listinfo/ircservices-
4586 < > > ---------------------------------------------------------------
4588 < > > To unsubscribe or change your subscription options, visit:
4589 < > > http://www.ircservices.za.net/mailman/listinfo/ircservices-
4593 < > -----------------------------------------------------------------
4595 < > To unsubscribe or change your subscription options, visit:
4596 < > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4600 From achurch at achurch.org Wed Feb 26 09:44:39 2003
4601 From: achurch at achurch.org (Andrew Church)
4602 Date: Sat Oct 23 23:09:50 2004
4603 Subject: [IRCServices Coding] SQLINE request
4604 In-Reply-To: <002601c2dcd1$a0d2cb80$0100a8c0@zeus>
4605 Message-ID: <3e5c0e0d.75447@mail.achurch.org>
4608 >When i add a channel in SQLINE list, users trying to join get the error...
4609 >#testing Cannot join channel (Reserved nickname: Reserved for Ircoperators).
4610 >I think that the Reserved nickname shouldn't be.
4612 SQLINE for channels is not supported.
4617 From achurch at achurch.org Wed Feb 26 09:45:30 2003
4618 From: achurch at achurch.org (Andrew Church)
4619 Date: Sat Oct 23 23:09:50 2004
4620 Subject: [IRCServices Coding] global notice
4621 In-Reply-To: <NDBBLDHKLKMANPGMACIGCEGJDFAA.rg@tcslon.com>
4622 Message-ID: <3e5c0e5a.75460@mail.achurch.org>
4624 >Note that SZLINES are removed in bahamut 1.4.35, because akills now have all
4625 >the capabilities of them.
4627 Also note that Bahamut 1.4.34+ are not (and will not be for the near
4628 future) supported by Services.
4633 From RT.Mail at verizon.net Tue Feb 25 16:48:40 2003
4634 From: RT.Mail at verizon.net (RT.Mail@verizon.net)
4635 Date: Sat Oct 23 23:09:50 2004
4636 Subject: [IRCServices Coding] global notice
4637 In-Reply-To: <3e5c0e5a.75460@mail.achurch.org>
4638 Message-ID: <20030226004841.GKWG16831.out001.verizon.net@bofh>
4640 So if we downgraded and used akill it would work correctly right?
4642 < >On Wed, 26 Feb 2003 09:45:30 JST, Andrew Church wrote:
4643 < > Also note that Bahamut 1.4.34+ are not (and will not be for
4645 < > future) supported by Services.
4649 From rzhe at ircd.ru Tue Feb 25 16:59:46 2003
4650 From: rzhe at ircd.ru (Dmitry Agaphonov)
4651 Date: Sat Oct 23 23:09:50 2004
4652 Subject: [IRCServices Coding] global notice
4653 In-Reply-To: <3e5c0e5a.75460@mail.achurch.org>
4654 References: <3e5c0e5a.75460@mail.achurch.org>
4655 Message-ID: <20030226035430.V12935@rzhe.domain>
4657 On Wed, 26 Feb 2003, Andrew Church wrote:
4659 AC> Also note that Bahamut 1.4.34+ are not (and will not be for the near
4660 AC> future) supported by Services.
4662 Andrew, could you please give the list of incompatibilities. It would be
4663 useful for people willing to run Services with latest Bahamut.
4668 From achurch at achurch.org Wed Feb 26 10:01:59 2003
4669 From: achurch at achurch.org (Andrew Church)
4670 Date: Sat Oct 23 23:09:50 2004
4671 Subject: [IRCServices Coding] global notice
4672 In-Reply-To: <20030226035430.V12935@rzhe.domain>
4673 Message-ID: <3e5c12ac.75630@mail.achurch.org>
4675 >On Wed, 26 Feb 2003, Andrew Church wrote:
4677 >AC> Also note that Bahamut 1.4.34+ are not (and will not be for the near
4678 >AC> future) supported by Services.
4680 >Andrew, could you please give the list of incompatibilities. It would be
4681 >useful for people willing to run Services with latest Bahamut.
4683 I haven't looked into the changes enough to make a definitive list.
4684 SZlines not working is the only one that comes to mind at the moment, but I
4685 think one or two others were mentioned at some point. At any rate, I don't
4686 have time to spare on coders that can't even keep a protocol stable within
4692 From rg at tcslon.com Wed Feb 26 02:02:30 2003
4693 From: rg at tcslon.com (Russell Garrett)
4694 Date: Sat Oct 23 23:09:50 2004
4695 Subject: [IRCServices Coding] global notice
4696 In-Reply-To: <20030226004841.GKWG16831.out001.verizon.net@bofh>
4697 Message-ID: <NDBBLDHKLKMANPGMACIGOEHADFAA.rg@tcslon.com>
4699 I think your akill problem could be fixed by disabling Akill exceptions in
4700 the services config. Bahamut doesn't seem to like those.
4702 > -----Original Message-----
4703 > From: ircservices-coding-bounces@ircservices.za.net
4704 > [mailto:ircservices-coding-bounces@ircservices.za.net]On Behalf
4705 > Of RT.Mail@verizon.net
4706 > Sent: 26 February 2003 00:49
4707 > To: IRC Services Coding Mailing List
4708 > Subject: RE: [IRCServices Coding] global notice
4711 > So if we downgraded and used akill it would work correctly right?
4713 > < >On Wed, 26 Feb 2003 09:45:30 JST, Andrew Church wrote:
4714 > < > Also note that Bahamut 1.4.34+ are not (and will not be for
4716 > < > future) supported by Services.
4720 > ------------------------------------------------------------------
4721 > To unsubscribe or change your subscription options, visit:
4722 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4725 From achurch at achurch.org Thu Feb 27 19:36:52 2003
4726 From: achurch at achurch.org (Andrew Church)
4727 Date: Sat Oct 23 23:09:50 2004
4728 Subject: [IRCServices Coding] Notice regarding v5.0.12 (fwd)
4729 Message-ID: <3e5deaa1.04371@mail.achurch.org>
4731 I broke my own rules by posting detailed technical info to the
4732 general-use list. Oops. Anyway, if you missed it there, here's the post:
4734 I should have mentioned it explicitly in the release notes, but one of
4735 the fixes in version 5.0.12 is a workaround for a bug, possibly a security
4736 hole, which can crash Services, and anyone using version 5.0.0 through 11
4737 should upgrade to 5.0.12 immediately. (4.5 and earlier versions may be
4738 affected as well, though I have not heard any reports of 4.5.x crashing due
4739 to this particular problem.)
4741 The reason I say "possibly" a security hole is because the direct
4742 cause of the crash is a case which should not be able to occur in the first
4743 place, which probably means I screwed up somewhere and haven't found it
4744 yet, and in any case means that I can't say for certain whether the bug is
4745 limited to crashing Services or can be abused in other ways.
4747 For the curious, it seems to be possible to get a nickname's language,
4748 NickGroupInfo.language, set to 12 (which is the value of NUM_LANGS, the
4749 constant defining the number of languages Services supports, though I don't
4750 know whether this is related to the problem); since this value is used to
4751 index an array of size NUM_LANGS (12), it should never be outside the range
4752 0 through NUM_LANGS-1 (11), and when the 12 is used to index the language
4753 text array, Services tries to read through a NULL pointer and crashes.
4754 There was supposed to be a check on the language value at database load
4755 time, to make certain that both the value is in range and that the language
4756 selected is actually available, but this check was only being applied to
4757 the language value in the version 4.5 compatibility data, and not to the
4758 value stored in the 5.0-specific data area. This oversight was corrected
4759 in version 5.0.12, and the language value is now properly checked on
4760 database load; invalid values will be set to LANG_DEFAULT (-1), which means
4761 "use the value of DEF_LANGUAGE in defs.h".
4763 If anyone can pinpoint how NickGroupInfo.language can get set out of
4764 range, you'll have my gratitude.
4769 From admin at nevernet.net Thu Feb 27 02:41:50 2003
4770 From: admin at nevernet.net (Elijah)
4771 Date: Sat Oct 23 23:09:50 2004
4772 Subject: [IRCServices Coding] Notice regarding v5.0.12 (fwd)
4773 In-Reply-To: <3e5deaa1.04371@mail.achurch.org>
4774 Message-ID: <000301c2de4c$d5be1440$826a3a44@noc7>
4776 I think it's forgivable just this once :P
4778 -----Original Message-----
4779 From: ircservices-coding-bounces@ircservices.za.net
4780 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of Andrew
4782 Sent: Thursday, February 27, 2003 5:37 AM
4783 To: ircservices-coding@ircservices.za.net
4784 Subject: [IRCServices Coding] Notice regarding v5.0.12 (fwd)
4787 I broke my own rules by posting detailed technical info to the
4788 general-use list. Oops. Anyway, if you missed it there, here's the post:
4790 I should have mentioned it explicitly in the release notes, but one of
4791 the fixes in version 5.0.12 is a workaround for a bug, possibly a security
4792 hole, which can crash Services, and anyone using version 5.0.0 through 11
4793 should upgrade to 5.0.12 immediately. (4.5 and earlier versions may be
4794 affected as well, though I have not heard any reports of 4.5.x crashing due
4795 to this particular problem.)
4797 The reason I say "possibly" a security hole is because the direct cause
4798 of the crash is a case which should not be able to occur in the first place,
4799 which probably means I screwed up somewhere and haven't found it yet, and in
4800 any case means that I can't say for certain whether the bug is limited to
4801 crashing Services or can be abused in other ways.
4803 For the curious, it seems to be possible to get a nickname's language,
4804 NickGroupInfo.language, set to 12 (which is the value of NUM_LANGS, the
4805 constant defining the number of languages Services supports, though I don't
4806 know whether this is related to the problem); since this value is used to
4807 index an array of size NUM_LANGS (12), it should never be outside the range
4808 0 through NUM_LANGS-1 (11), and when the 12 is used to index the language
4809 text array, Services tries to read through a NULL pointer and crashes. There
4810 was supposed to be a check on the language value at database load time, to
4811 make certain that both the value is in range and that the language selected
4812 is actually available, but this check was only being applied to the language
4813 value in the version 4.5 compatibility data, and not to the value stored in
4814 the 5.0-specific data area. This oversight was corrected in version 5.0.12,
4815 and the language value is now properly checked on database load; invalid
4816 values will be set to LANG_DEFAULT (-1), which means "use the value of
4817 DEF_LANGUAGE in defs.h".
4819 If anyone can pinpoint how NickGroupInfo.language can get set out of
4820 range, you'll have my gratitude.
4825 ------------------------------------------------------------------
4826 To unsubscribe or change your subscription options, visit:
4827 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4830 From thebeast at xs4all.nl Fri Feb 28 16:10:48 2003
4831 From: thebeast at xs4all.nl (J v Steenbergen)
4832 Date: Sat Oct 23 23:09:50 2004
4833 Subject: [IRCServices Coding] mistake in http module
4834 Message-ID: <000001c2df87$03b83ca0$0101000a@amdxp1700>
4839 I was just chacking some nick in on the http module
4840 and found a nick that begins with a \ and was selecting it to
4841 view the details of it and than the error came
4844 The requested resource could not be found.
4846 just to check it a registerd a new nick that also begins
4847 with a \ and there was the same error then checked the
4848 the urls the nicks are pointing to
4850 this is a normale link
4851 http://password:Secret@rc5proxy.mp3crew.nu:8888/dbaccess/nickserv/The_Beast
4853 and the wrong nicks are pointing to
4854 http://More:Secrets@rc5proxy.mp3crew.nu:8888/LiNuX
4856 so because of the produced html code's the url is wrong it looks
4858 I Hope you can think of a option to correct it
4863 From waterflamez at hotmail.com Sat Mar 1 17:15:06 2003
4864 From: waterflamez at hotmail.com (Jack Neils)
4865 Date: Sat Oct 23 23:09:50 2004
4866 Subject: [IRCServices Coding] can services change user ident on connect ?
4867 Message-ID: <F434yEGlgxur4HasvW30002403b@hotmail.com>
4869 Hi, i've been trying to modify ircservices 5.0.12 to make my irc network
4872 i'm using UnrealIRCD (3.2beta14), and i wanted the services to do this:
4874 when a user connects, there are commands passed between the server, the
4875 services, and the client, right?
4876 and services can say that something has to change, right?
4878 so, instead of having the user connect with his real ident and host,
4879 i'd like for services (either directly, or through UnrealIRCD's chgident and
4880 chghost) to change the ident and host into something else.
4882 but i'm new at this, and though i understand the basics,
4883 i really can't figure where i have to put what.
4885 anyone that can help?
4891 _________________________________________________________________
4892 MSN Search, for relevant search results! http://search.msn.be
4894 From georges at berscheid.lu Sun Mar 2 08:38:22 2003
4895 From: georges at berscheid.lu (Georges Berscheid)
4896 Date: Sat Oct 23 23:09:50 2004
4897 Subject: AW: [IRCServices Coding] can services change user ident on connect ?
4898 In-Reply-To: <F434yEGlgxur4HasvW30002403b@hotmail.com>
4899 Message-ID: <000701c2e0da$27448710$69c918d4@gizmo>
4903 You could write a module implementing this.
4904 Services can use IRCd's /chgident and /chghost (e.g.
4905 send_cmd(s_OperServ, "CHGHOST %s :%s", theuser->nick, somehost); where
4906 theuser is a User struct from get_user(nick_as_string)).
4907 You will also have set theuser->fakehost and theuser->username
4908 correctly. Services don't like to be desynched :)
4909 If you browse a little the existing code, you will easily understand :)
4917 -----Urspr?ngliche Nachricht-----
4918 Von: ircservices-coding-bounces@ircservices.za.net
4919 [mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
4921 Gesendet: Sonntag, 2. M?rz 2003 02:15
4922 An: ircservices-coding@ircservices.za.net
4923 Betreff: [IRCServices Coding] can services change user ident on connect
4927 Hi, i've been trying to modify ircservices 5.0.12 to make my irc network
4931 i'm using UnrealIRCD (3.2beta14), and i wanted the services to do this:
4933 when a user connects, there are commands passed between the server, the
4934 services, and the client, right?
4935 and services can say that something has to change, right?
4937 so, instead of having the user connect with his real ident and host,
4938 i'd like for services (either directly, or through UnrealIRCD's chgident
4940 chghost) to change the ident and host into something else.
4942 but i'm new at this, and though i understand the basics,
4943 i really can't figure where i have to put what.
4945 anyone that can help?
4951 _________________________________________________________________
4952 MSN Search, for relevant search results! http://search.msn.be
4954 ------------------------------------------------------------------
4955 To unsubscribe or change your subscription options, visit:
4956 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4960 From achurch at achurch.org Mon Mar 3 02:57:28 2003
4961 From: achurch at achurch.org (Andrew Church)
4962 Date: Sat Oct 23 23:09:50 2004
4963 Subject: [IRCServices Coding] can services change user ident on connect ?
4964 In-Reply-To: <F434yEGlgxur4HasvW30002403b@hotmail.com>
4965 Message-ID: <3e6248a3.52610@mail.achurch.org>
4967 >so, instead of having the user connect with his real ident and host,
4968 >i'd like for services (either directly, or through UnrealIRCD's chgident and
4969 >chghost) to change the ident and host into something else.
4971 You'll want to use the "user create" callback; see section 6 of the
4972 manual for details. Inside the callback function, you can use send_cmd()
4973 to send CHGIDENT/CHGHOST commands, as Georges suggests (and don't forget to
4974 set user->username and user->fakehost appropriately, or the real username
4975 and hostname will appear in NickServ INFO replies).
4980 From achurch at achurch.org Mon Mar 3 03:14:17 2003
4981 From: achurch at achurch.org (Andrew Church)
4982 Date: Sat Oct 23 23:09:50 2004
4983 Subject: [IRCServices Coding] mistake in http module
4984 In-Reply-To: <000001c2df87$03b83ca0$0101000a@amdxp1700>
4985 Message-ID: <3e624cab.55051@mail.achurch.org>
4987 WFM with Mozilla 1.2.1, but I'll add a workaround for the next
4997 >I was just chacking some nick in on the http module
4998 >and found a nick that begins with a \ and was selecting it to
4999 >view the details of it and than the error came
5002 >The requested resource could not be found.
5004 >just to check it a registerd a new nick that also begins
5005 >with a \ and there was the same error then checked the
5006 >the urls the nicks are pointing to
5008 >this is a normale link
5009 >http://password:Secret@rc5proxy.mp3crew.nu:8888/dbaccess/nickserv/The_Beast
5011 >and the wrong nicks are pointing to
5012 >http://More:Secrets@rc5proxy.mp3crew.nu:8888/LiNuX
5014 >so because of the produced html code's the url is wrong it looks
5016 >I Hope you can think of a option to correct it
5021 >------------------------------------------------------------------
5022 >To unsubscribe or change your subscription options, visit:
5023 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
5024 From monolith at orblivion.com Wed Mar 5 19:46:52 2003
5025 From: monolith at orblivion.com (monolith)
5026 Date: Sat Oct 23 23:09:50 2004
5027 Subject: [IRCServices Coding] english language file typo....
5028 Message-ID: <000c01c2e393$093410e0$6401a8c0@quasar>
5030 Found a typo in /msg chanserv help access levels
5032 [21:36:09] -ChanServ- Founder Full access to ChanServ functions;
5035 [21:36:09] -ChanServ- opping upon entering channel. Note
5038 [21:36:09] -ChanServ- only one person may have founder
5041 [21:36:09] -ChanServ- status (it cannot be given using the
5044 [21:36:09] -ChanServ- command).
5048 [21:41:59] -ChanServ- Founder Full access to ChanServ functions;
5051 [21:41:59] -ChanServ- opping upon entering channel. Note
5054 [21:41:59] -ChanServ- only one person may have founder
5057 [21:41:59] -ChanServ- (it cannot be given using the ACCESS
5059 [21:41:59] -ChanServ- command).
5062 Updated en_us.l here:
5064 http://www.orblivion.com/~ircd/en_us.l
5068 -------------- next part --------------
5069 A non-text attachment was scrubbed...
5071 Type: application/ms-tnef
5074 Url : http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030305/3a679a0d/winmail.bin
5075 From master at xchat.gr Sat Mar 8 04:39:35 2003
5076 From: master at xchat.gr (George Stamatiou)
5077 Date: Sat Oct 23 23:09:50 2004
5078 Subject: [IRCServices Coding] JUPE and bahamut-1.4(35)
5079 Message-ID: <001701c2e56f$c8cbb880$0100a8c0@zeus>
5081 I found another possible bug.
5082 When i do /os squit server and the server is active, then services crashes.
5083 I have to do squit and after to use the jupe command.
5084 -chat.xchat.gr- *** Global -- from OperServ: Juping matrix.voxnet.gr by request of KillServ.
5085 -chat.xchat.gr- *** Routing -- from chat.xchat.gr: Link services.xchat.gr[(+)something@0.0.0.0]
5086 cancelled, server matrix.voxnet.gr already exists
5087 -chat.xchat.gr- *** Notice -- services.xchat.gr was connected for 5 seconds. 24/62 sendK/recvK.
5089 I don't know if it is another problem with bahamut 1.4(35), but it happens only with version
5090 of bahamut and not bahamut-1.4(35)
5100 From master at xchat.gr Sat Mar 8 04:45:15 2003
5101 From: master at xchat.gr (George Stamatiou)
5102 Date: Sat Oct 23 23:09:50 2004
5103 Subject: [IRCServices Coding] JUPE and bahamut-1.4(35)
5104 Message-ID: <002501c2e570$92330430$0100a8c0@zeus>
5108 This happens with bahamut 1.4(35), and not bahamut-1.4(34)
5117 From hudson at mbay.net Wed Mar 12 15:04:41 2003
5118 From: hudson at mbay.net (Stefan Hudson)
5119 Date: Sat Oct 23 23:09:51 2004
5120 Subject: [IRCServices Coding] Chanserv patch for reg chans only
5121 Message-ID: <20030312150441.A19757@mbay.net>
5123 Here's a patch to add an option for forbiding use unregistered channels
5124 by normal users. Yeah, it's a bit fascist, but sometimes this much control
5125 is needed - on IRC servers that are used for commercial support, where it
5126 would not be appropriate to have someone create #hotgaysex, for example.
5128 This is the first hack I've done on ircservices, so someone please check
5129 to make sure I didn't miss something. I tried to cover all bases.
5131 diff -c -r ircservices-5.0.13/data/example-modules.conf ircservices-5.0.13-local/data/example-modules.conf
5132 *** ircservices-5.0.13/data/example-modules.conf Mon Mar 3 01:54:47 2003
5133 --- ircservices-5.0.13-local/data/example-modules.conf Wed Mar 12 16:41:23 2003
5138 #CSForbidShortChannel
5140 + # CSRegisteredOnly [OPTIONAL]
5141 + # When enabled, treats unregistered channels as forbidden, not
5142 + # allowing normal users to join. If enabled, services opers will
5143 + # need to create any new channels on the network. For this option
5144 + # to be effective, CSEnableRegister should generally NOT be enabled.
5150 ################################ SENDPASS module
5151 diff -c -r ircservices-5.0.13/docs/a.html ircservices-5.0.13-local/docs/a.html
5152 *** ircservices-5.0.13/docs/a.html Sun Mar 2 21:18:48 2003
5153 --- ircservices-5.0.13-local/docs/a.html Wed Mar 12 16:50:04 2003
5158 <p>Example: <tt>CSForbidShortChannel</tt>
5161 + <a name="chanserv/main.CSRegisteredOnly"></a>
5163 + <tt><b>CSRegisteredOnly</b></tt> [OPTIONAL]
5164 + <p>When enabled, treats unregistered channels as forbidden, not
5165 + allowing normal users to join. If enabled, services opers will
5166 + need to create any new channels on the network. For this option
5167 + to be effective, CSEnableRegister should generally NOT be enabled.
5169 + <p>Example: <tt>CSRegisteredOnly</tt>
5172 <a name="chanserv/sendpass"></a>
5173 <p><font size="+1"><b>chanserv/sendpass</b> (SENDPASS module)</font>
5175 diff -c -r ircservices-5.0.13/modules/chanserv/check.c ircservices-5.0.13-local/modules/chanserv/check.c
5176 *** ircservices-5.0.13/modules/chanserv/check.c Mon Mar 3 01:54:48 2003
5177 --- ircservices-5.0.13-local/modules/chanserv/check.c Wed Mar 12 04:55:35 2003
5186 if (is_services_admin(user))
5193 ! if(CSRegisteredOnly && !is_oper(user)) {
5194 ! mask = sstrdup("*!*@*");
5195 ! reason = getstring(user->ngi, CHAN_MAY_NOT_BE_USED);
5202 if (is_services_admin(user))
5204 diff -c -r ircservices-5.0.13/modules/chanserv/cs-local.h ircservices-5.0.13-local/modules/chanserv/cs-local.h
5205 *** ircservices-5.0.13/modules/chanserv/cs-local.h Mon Mar 3 01:54:48 2003
5206 --- ircservices-5.0.13-local/modules/chanserv/cs-local.h Wed Mar 12 04:45:02 2003
5210 E time_t CSSuspendExpire;
5211 E time_t CSSuspendGrace;
5212 E int CSForbidShortChannel;
5213 + E int CSRegisteredOnly;
5214 E ChanOpt chanopts[];
5217 diff -c -r ircservices-5.0.13/modules/chanserv/main.c ircservices-5.0.13-local/modules/chanserv/main.c
5218 *** ircservices-5.0.13/modules/chanserv/main.c Mon Mar 3 01:54:48 2003
5219 --- ircservices-5.0.13-local/modules/chanserv/main.c Wed Mar 12 03:47:23 2003
5223 time_t CSSuspendExpire;
5224 time_t CSSuspendGrace;
5225 int CSForbidShortChannel;
5226 + int CSRegisteredOnly;
5227 EXPORT_VAR(int32,CSMaxReg)
5229 /*************************************************************************/
5233 { "CSEnableRegister", { { CD_SET, 0, &CSEnableRegister } } },
5234 { "CSExpire", { { CD_TIME, 0, &CSExpire } } },
5235 { "CSForbidShortChannel",{{CD_SET, 0, &CSForbidShortChannel } } },
5236 + { "CSRegisteredOnly", { { CD_SET, 0, &CSRegisteredOnly } } },
5237 { "CSInhabit", { { CD_TIME, CF_DIRREQ, &CSInhabit } } },
5238 { "CSListMax", { { CD_POSINT, CF_DIRREQ, &CSListMax } } },
5239 { "CSListOpersOnly", { { CD_SET, 0, &CSListOpersOnly } } },
5240 From Craig at chatspike.net Wed Mar 12 16:41:49 2003
5241 From: Craig at chatspike.net (Craig McLure)
5242 Date: Sat Oct 23 23:09:51 2004
5243 Subject: [IRCServices Coding] Chanserv patch for reg chans only
5244 Message-ID: <20030313004158.SXAN24160.mta02-svc.ntlworld.com@i-br0ked-it>
5246 Good Job, i've checked thru it quickly, and dont see any immediate probs, This will be useful for people whos IRCds dont support the ability to "forbid all channels except.." and has been requested a couple of times. it also makes enabeling new channels easier as well, although, you may wanna add is_services_oper or maybe just is_oper support as well, meaning opers or services opers can join.
5248 -----------------------------------------------------------------------
5249 Craig McLure - Craig@chatspike.net
5250 ChatSpike - The users network: http://www.chatspike.net
5251 InspIRCd - Modular IRC server: http://www.inspircd.org
5252 <`RaSh> how do i install linux i got the cd and i dont see the setup.exe or install.exe
5253 -----------------------------------------------------------------------
5255 ============ Original Message ============
5256 >From : "Stefan Hudson" <hudson@mbay.net>
5257 >Reply-To : ircservices-coding@ircservices.za.net
5258 >To : ircservices-coding@ircservices.za.net
5259 >Subject : [IRCServices Coding] Chanserv patch for reg chans only
5263 >Here's a patch to add an option for forbiding use unregistered channels
5264 >by normal users. Yeah, it's a bit fascist, but sometimes this much control
5265 >is needed - on IRC servers that are used for commercial support, where it
5266 >would not be appropriate to have someone create #hotgaysex, for example.
5268 >This is the first hack I've done on ircservices, so someone please check
5269 >to make sure I didn't miss something. I tried to cover all bases.
5271 >diff -c -r ircservices-5.0.13/data/example-modules.conf ircservices-5.0.13-local/data/example-modules.conf
5272 >*** ircservices-5.0.13/data/example-modules.conf Mon Mar 3 01:54:47 2003
5273 >--- ircservices-5.0.13-local/data/example-modules.conf Wed Mar 12 16:41:23 2003
5278 > #CSForbidShortChannel
5280 >+ # CSRegisteredOnly [OPTIONAL]
5281 >+ # When enabled, treats unregistered channels as forbidden, not
5282 >+ # allowing normal users to join. If enabled, services opers will
5283 >+ # need to create any new channels on the network. For this option
5284 >+ # to be effective, CSEnableRegister should generally NOT be enabled.
5286 >+ #CSRegisteredOnly
5290 > ################################ SENDPASS module
5291 >diff -c -r ircservices-5.0.13/docs/a.html ircservices-5.0.13-local/docs/a.html
5292 >*** ircservices-5.0.13/docs/a.html Sun Mar 2 21:18:48 2003
5293 >--- ircservices-5.0.13-local/docs/a.html Wed Mar 12 16:50:04 2003
5298 > <p>Example: <tt>CSForbidShortChannel</tt>
5301 >+ <a name="chanserv/main.CSRegisteredOnly"></a>
5303 >+ <tt><b>CSRegisteredOnly</b></tt> [OPTIONAL]
5304 >+ <p>When enabled, treats unregistered channels as forbidden, not
5305 >+ allowing normal users to join. If enabled, services opers will
5306 >+ need to create any new channels on the network. For this option
5307 >+ to be effective, CSEnableRegister should generally NOT be enabled.
5309 >+ <p>Example: <tt>CSRegisteredOnly</tt>
5312 > <a name="chanserv/sendpass"></a>
5313 > <p><font size="+1"><b>chanserv/sendpass</b> (SENDPASS module)</font>
5315 >diff -c -r ircservices-5.0.13/modules/chanserv/check.c ircservices-5.0.13-local/modules/chanserv/check.c
5316 >*** ircservices-5.0.13/modules/chanserv/check.c Mon Mar 3 01:54:48 2003
5317 >--- ircservices-5.0.13-local/modules/chanserv/check.c Wed Mar 12 04:55:35 2003
5326 > if (is_services_admin(user))
5333 >! if(CSRegisteredOnly && !is_oper(user)) {
5334 >! mask = sstrdup("*!*@*");
5335 >! reason = getstring(user->ngi, CHAN_MAY_NOT_BE_USED);
5342 > if (is_services_admin(user))
5344 >diff -c -r ircservices-5.0.13/modules/chanserv/cs-local.h ircservices-5.0.13-local/modules/chanserv/cs-local.h
5345 >*** ircservices-5.0.13/modules/chanserv/cs-local.h Mon Mar 3 01:54:48 2003
5346 >--- ircservices-5.0.13-local/modules/chanserv/cs-local.h Wed Mar 12 04:45:02 2003
5350 > E time_t CSSuspendExpire;
5351 > E time_t CSSuspendGrace;
5352 > E int CSForbidShortChannel;
5353 >+ E int CSRegisteredOnly;
5354 > E ChanOpt chanopts[];
5357 >diff -c -r ircservices-5.0.13/modules/chanserv/main.c ircservices-5.0.13-local/modules/chanserv/main.c
5358 >*** ircservices-5.0.13/modules/chanserv/main.c Mon Mar 3 01:54:48 2003
5359 >--- ircservices-5.0.13-local/modules/chanserv/main.c Wed Mar 12 03:47:23 2003
5363 > time_t CSSuspendExpire;
5364 > time_t CSSuspendGrace;
5365 > int CSForbidShortChannel;
5366 >+ int CSRegisteredOnly;
5367 > EXPORT_VAR(int32,CSMaxReg)
5369 > /*************************************************************************/
5373 > { "CSEnableRegister", { { CD_SET, 0, &CSEnableRegister } } },
5374 > { "CSExpire", { { CD_TIME, 0, &CSExpire } } },
5375 > { "CSForbidShortChannel",{{CD_SET, 0, &CSForbidShortChannel } } },
5376 >+ { "CSRegisteredOnly", { { CD_SET, 0, &CSRegisteredOnly } } },
5377 > { "CSInhabit", { { CD_TIME, CF_DIRREQ, &CSInhabit } } },
5378 > { "CSListMax", { { CD_POSINT, CF_DIRREQ, &CSListMax } } },
5379 > { "CSListOpersOnly", { { CD_SET, 0, &CSListOpersOnly } } },
5380 >------------------------------------------------------------------
5381 >To unsubscribe or change your subscription options, visit:
5382 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
5384 ========= End of Original Message =========
5388 From hudson at mbay.net Wed Mar 12 19:22:51 2003
5389 From: hudson at mbay.net (Stefan Hudson)
5390 Date: Sat Oct 23 23:09:51 2004
5391 Subject: [IRCServices Coding] Chanserv patch for reg chans only
5392 In-Reply-To: <20030313004158.SXAN24160.mta02-svc.ntlworld.com@i-br0ked-it>;
5393 from Craig McLure on Thu, Mar 13, 2003 at 12:41:49AM +0000
5394 References: <20030313004158.SXAN24160.mta02-svc.ntlworld.com@i-br0ked-it>
5395 Message-ID: <20030312192251.A3632@mbay.net>
5397 On Thu, Mar 13, 2003 at 12:41:49AM +0000, Craig McLure wrote:
5398 > Good Job, i've checked thru it quickly, and dont see any immediate probs, This will be useful for people whos IRCds dont support the ability to "forbid all channels except.." and has been requested a couple of times. it also makes enabeling new channels easier as well, although, you may wanna add is_services_oper or maybe just is_oper support as well, meaning opers or services opers can join.
5400 That was one of the questions I had when I was working on it. I
5401 decided on is_oper() because it seemed be used elsewhere for general
5402 server-related exceptions - is_services_oper() only appears in
5403 operserv. I assume it also includes is_services_admin(), but that
5404 already has an exception above my patch so it doesn't really matter.
5406 The other question I had was if I should depend on the result from
5407 get_channelinfo() or get_channel() to determine if a channel is
5408 registered. I found the code for get_channelinfo() in tools/convert-db.c,
5409 and it seems to be a good bet for this, but I can't find the code for
5410 get_channel() anywhere. The text shows up in channels.o, but I can't
5411 find the code in channels.c. I feel a bit silly about this - I always
5412 thought I was fairly good at C.
5414 Also, I can think of a pathological case where the +b *!*@* might be a
5415 problem. It would show up if one oper joins an unregistered channel and
5416 idles, then a normal user tries to join and services sets the +b. With
5417 some servers (unreal), this will prevent other opers from joining that
5418 channel, since opers can't break bans and they can't use chanserv to
5419 remove them, since the channel isn't registered.
5421 This is a fairly unusual situation, but it might be more consistant if
5422 the ban wasn't set. However, does this open services up for a DOS from
5423 a user repeatedly trying to join and getting kicked by chanserv?
5426 From idontwantthisshit at hotmail.com Wed Mar 12 19:36:52 2003
5427 From: idontwantthisshit at hotmail.com (DeadNotBuried)
5428 Date: Sat Oct 23 23:09:51 2004
5429 Subject: [IRCServices Coding] Chanserv patch for reg chans only
5430 References: <20030313004158.SXAN24160.mta02-svc.ntlworld.com@i-br0ked-it>
5431 <20030312192251.A3632@mbay.net>
5432 Message-ID: <BAY1-DAV27pBJdxxTgH000157eb@hotmail.com>
5434 > Also, I can think of a pathological case where the +b *!*@* might be a
5435 > problem. It would show up if one oper joins an unregistered channel and
5436 > idles, then a normal user tries to join and services sets the +b. With
5437 > some servers (unreal), this will prevent other opers from joining that
5438 > channel, since opers can't break bans and they can't use chanserv to
5439 > remove them, since the channel isn't registered.
5441 on unreal 3.2 opers can get around the ban by inviting themselves into the
5443 From achurch at achurch.org Thu Mar 13 13:09:56 2003
5444 From: achurch at achurch.org (Andrew Church)
5445 Date: Sat Oct 23 23:09:51 2004
5446 Subject: [IRCServices Coding] Chanserv patch for reg chans only
5447 In-Reply-To: <20030312192251.A3632@mbay.net>
5448 Message-ID: <3e7005e8.01102@mail.achurch.org>
5450 Thanks for the suggestion. I generally try to avoid adding features
5451 into a stable branch, but I'll consider it.
5453 >The other question I had was if I should depend on the result from
5454 >get_channelinfo() or get_channel() to determine if a channel is
5455 >registered. I found the code for get_channelinfo() in tools/convert-db.c,
5456 >and it seems to be a good bet for this, but I can't find the code for
5457 >get_channel() anywhere. The text shows up in channels.o, but I can't
5458 >find the code in channels.c. I feel a bit silly about this - I always
5459 >thought I was fairly good at C.
5461 Both get_channel() and get_channelinfo() are defined by macros in
5462 hash.h (the get_channelinfo() in convert-db.c is designed for the
5463 convert-db tool and is not included in the main program). get_channel()
5464 looks up channels on the network, while get_channelinfo() looks them up in
5465 the Services database, so you'll want to use the latter.
5467 >This is a fairly unusual situation, but it might be more consistant if
5468 >the ban wasn't set. However, does this open services up for a DOS from
5469 >a user repeatedly trying to join and getting kicked by chanserv?
5471 Unlikely, since the ircd would probably drop them for flooding before
5472 Services took any serious performance hit.
5477 From RT.Mail at verizon.net Thu Mar 13 02:03:58 2003
5478 From: RT.Mail at verizon.net (RT.Mail@verizon.net)
5479 Date: Sat Oct 23 23:09:51 2004
5480 Subject: [IRCServices Coding] None
5481 In-Reply-To: <3e7005e8.01102@mail.achurch.org>
5482 Message-ID: <20030313100403.TWKY14460.pop015.verizon.net@bofh>
5484 We have about 19,000 autokills on the akill list. When trying to view them on the web it seems services only shows about 17,200
5485 before it stops loading the page. I have tried to view it in both Opera and IE, both have the same problem.
5487 From john at cosmicfire.net Thu Mar 13 07:32:13 2003
5488 From: john at cosmicfire.net (John Edrington)
5489 Date: Sat Oct 23 23:09:51 2004
5490 Subject: [IRCServices Coding] None
5491 References: <20030313100403.TWKY14460.pop015.verizon.net@bofh>
5492 Message-ID: <002001c2e975$cb0c46a0$fc0110ac@paladin>
5494 I have had a similar problem while exporting the database in xml format via
5497 When using lynx, the file size is about 6MB, when using wget, the file size
5498 is 9MB. When using a non-local, graphical brower, I get about a 1MB.
5500 Just a little more info that might make the difference: my swap space is
5501 totally used up, and I have 45 MB of memory free)
5505 ----- Original Message -----
5506 From: <RT.Mail@verizon.net>
5507 To: "IRC Services Coding Mailing List"
5508 <ircservices-coding@ircservices.za.net>
5509 Sent: Thursday, March 13, 2003 5:03 AM
5510 Subject: [IRCServices Coding] None
5513 We have about 19,000 autokills on the akill list. When trying to view them
5514 on the web it seems services only shows about 17,200
5515 before it stops loading the page. I have tried to view it in both Opera and
5516 IE, both have the same problem.
5518 ------------------------------------------------------------------
5519 To unsubscribe or change your subscription options, visit:
5520 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
5522 From rg at tcslon.com Thu Mar 13 12:39:47 2003
5523 From: rg at tcslon.com (Russell Garrett)
5524 Date: Sat Oct 23 23:09:51 2004
5525 Subject: [IRCServices Coding] None
5526 In-Reply-To: <20030313100403.TWKY14460.pop015.verizon.net@bofh>
5527 Message-ID: <NDBBLDHKLKMANPGMACIGKEFNDGAA.rg@tcslon.com>
5529 Out of interest, how does Services perform with this many akills? And, if
5530 you don't mind me asking, how did you accumulate so many? In my experience
5531 offenders almost certainly give up after a month or so, and so setting
5532 unlimited-timed akills is usually a pointless exercise. But it's just me
5537 > -----Original Message-----
5538 > From: ircservices-coding-bounces@ircservices.za.net
5539 > [mailto:ircservices-coding-bounces@ircservices.za.net]On Behalf
5540 > Of RT.Mail@verizon.net
5541 > Sent: 13 March 2003 10:04
5542 > To: IRC Services Coding Mailing List
5543 > Subject: [IRCServices Coding] None
5546 > We have about 19,000 autokills on the akill list. When trying to
5547 > view them on the web it seems services only shows about 17,200
5548 > before it stops loading the page. I have tried to view it in both
5549 > Opera and IE, both have the same problem.
5551 > ------------------------------------------------------------------
5552 > To unsubscribe or change your subscription options, visit:
5553 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
5557 From Craig at chatspike.net Thu Mar 13 13:06:47 2003
5558 From: Craig at chatspike.net (Craig McLure)
5559 Date: Sat Oct 23 23:09:51 2004
5560 Subject: [IRCServices Coding] None
5561 Message-ID: <20030313210649.SOWA11246.mta03-svc.ntlworld.com@i-br0ked-it>
5563 Russell has been subject to a large number of botfloods recently and has scripts to add akills when bots connect, last time i spoke to him he said that the services databases mess up after a certain ammount, but performance wise, its fine.
5565 -----------------------------------------------------------------------
5566 Craig McLure - Craig@chatspike.net
5567 ChatSpike - The users network: http://www.chatspike.net
5568 InspIRCd - Modular IRC server: http://www.inspircd.org
5569 <`RaSh> how do i install linux i got the cd and i dont see the setup.exe or install.exe
5570 -----------------------------------------------------------------------
5572 ============ Original Message ============
5573 >From : "Russell Garrett" <rg@tcslon.com>
5574 >Reply-To : ircservices-coding@ircservices.za.net
5575 >To : RT.Mail@verizon.net
5576 >Subject : RE: [IRCServices Coding] None
5580 >Out of interest, how does Services perform with this many akills? And, if
5581 >you don't mind me asking, how did you accumulate so many? In my experience
5582 >offenders almost certainly give up after a month or so, and so setting
5583 >unlimited-timed akills is usually a pointless exercise. But it's just me
5588 >> -----Original Message-----
5589 >> From: ircservices-coding-bounces@ircservices.za.net
5590 >> [mailto:ircservices-coding-bounces@ircservices.za.net]On Behalf
5591 >> Of RT.Mail@verizon.net
5592 >> Sent: 13 March 2003 10:04
5593 >> To: IRC Services Coding Mailing List
5594 >> Subject: [IRCServices Coding] None
5597 >> We have about 19,000 autokills on the akill list. When trying to
5598 >> view them on the web it seems services only shows about 17,200
5599 >> before it stops loading the page. I have tried to view it in both
5600 >> Opera and IE, both have the same problem.
5602 >> ------------------------------------------------------------------
5603 >> To unsubscribe or change your subscription options, visit:
5604 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
5608 >------------------------------------------------------------------
5609 >To unsubscribe or change your subscription options, visit:
5610 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
5612 ========= End of Original Message =========
5616 From ballsy at mystical.net Thu Mar 13 13:21:57 2003
5617 From: ballsy at mystical.net (Ballsy)
5618 Date: Sat Oct 23 23:09:51 2004
5619 Subject: [IRCServices Coding] None
5620 In-Reply-To: <20030313210649.SOWA11246.mta03-svc.ntlworld.com@i-br0ked-it>
5621 Message-ID: <Pine.LNX.4.44.0303131620110.27230-100000@david.mail.net>
5623 If you would be willing to share your methods of handling bot
5624 floods with the rest of us, I know some of us could sure use the ideas.
5625 Nothing short of a probability analysis bot seems to be required to
5626 determine what is and isn't a bot when they connect.
5631 Quoth Craig McLure on Mar 13 at 21:06,
5633 > Russell has been subject to a large number of botfloods recently and has scripts to add akills when bots connect, last time i spoke to him he said that the services databases mess up after a certain ammount, but performance wise, its fine.
5635 > -----------------------------------------------------------------------
5636 > Craig McLure - Craig@chatspike.net
5637 > ChatSpike - The users network: http://www.chatspike.net
5638 > InspIRCd - Modular IRC server: http://www.inspircd.org
5639 > <`RaSh> how do i install linux i got the cd and i dont see the setup.exe or install.exe
5640 > -----------------------------------------------------------------------
5642 > ============ Original Message ============
5643 > >>From : "Russell Garrett" <rg@tcslon.com>
5644 > >Reply-To : ircservices-coding@ircservices.za.net
5645 > >To : RT.Mail@verizon.net
5646 > >Subject : RE: [IRCServices Coding] None
5647 > >Date : 2003-03-13
5650 > >Out of interest, how does Services perform with this many akills? And, if
5651 > >you don't mind me asking, how did you accumulate so many? In my experience
5652 > >offenders almost certainly give up after a month or so, and so setting
5653 > >unlimited-timed akills is usually a pointless exercise. But it's just me
5658 > >> -----Original Message-----
5659 > >> From: ircservices-coding-bounces@ircservices.za.net
5660 > >> [mailto:ircservices-coding-bounces@ircservices.za.net]On Behalf
5661 > >> Of RT.Mail@verizon.net
5662 > >> Sent: 13 March 2003 10:04
5663 > >> To: IRC Services Coding Mailing List
5664 > >> Subject: [IRCServices Coding] None
5667 > >> We have about 19,000 autokills on the akill list. When trying to
5668 > >> view them on the web it seems services only shows about 17,200
5669 > >> before it stops loading the page. I have tried to view it in both
5670 > >> Opera and IE, both have the same problem.
5672 > >> ------------------------------------------------------------------
5673 > >> To unsubscribe or change your subscription options, visit:
5674 > >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
5678 > >------------------------------------------------------------------
5679 > >To unsubscribe or change your subscription options, visit:
5680 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
5682 > ========= End of Original Message =========
5686 > ------------------------------------------------------------------
5687 > To unsubscribe or change your subscription options, visit:
5688 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
5691 From RT.Mail at verizon.net Thu Mar 13 13:19:45 2003
5692 From: RT.Mail at verizon.net (RT.Mail@verizon.net)
5693 Date: Sat Oct 23 23:09:51 2004
5694 Subject: [IRCServices Coding] None
5695 In-Reply-To: <20030313210649.SOWA11246.mta03-svc.ntlworld.com@i-br0ked-it>
5696 Message-ID: <20030313211951.QIYQ2095.pop017.verizon.net@bofh>
5698 Craig is correct, however the DB has not had any more problems.... might have just been a freak thing. The only problem now
5699 is the page not loading. FYI those 19,000 akills were from a 36 hour period, if it werent for the damn bots we would have about
5702 < >On Thu, 13 Mar 2003 21:6:47 +0000, Craig McLure wrote:
5703 < > Russell has been subject to a large number of botfloods recently
5704 < > and has scripts to add akills when bots connect, last time i
5705 < > spoke to him he said that the services databases mess up after a
5706 < > certain ammount, but performance wise, its fine.
5708 < > -----------------------------------------------------------------
5710 < > Craig McLure - Craig@chatspike.net
5711 < > ChatSpike - The users network: http://www.chatspike.net
5712 < > InspIRCd - Modular IRC server: http://www.inspircd.org
5713 < > <`RaSh> how do i install linux i got the cd and i dont see the
5714 < > setup.exe or install.exe
5715 < > -----------------------------------------------------------------
5718 < > ============ Original Message ============
5719 < > >From : "Russell Garrett" <rg@tcslon.com>
5720 < > >Reply-To : ircservices-coding@ircservices.za.net
5721 < > >To : RT.Mail@verizon.net
5722 < > >Subject : RE: [IRCServices Coding] None
5723 < > >Date : 2003-03-13
5726 < > >Out of interest, how does Services perform with this many
5728 < > >you don't mind me asking, how did you accumulate so many? In my
5730 < > >offenders almost certainly give up after a month or so, and so
5732 < > >unlimited-timed akills is usually a pointless exercise. But
5738 < > >> -----Original Message-----
5739 < > >> From: ircservices-coding-bounces@ircservices.za.net
5740 < > >> [mailto:ircservices-coding-bounces@ircservices.za.net]On
5742 < > >> Of RT.Mail@verizon.net
5743 < > >> Sent: 13 March 2003 10:04
5744 < > >> To: IRC Services Coding Mailing List
5745 < > >> Subject: [IRCServices Coding] None
5748 < > >> We have about 19,000 autokills on the akill list. When trying
5750 < > >> view them on the web it seems services only shows about 17,200
5751 < > >> before it stops loading the page. I have tried to view it in
5753 < > >> Opera and IE, both have the same problem.
5755 < > >> --------------------------------------------------------------
5757 < > >> To unsubscribe or change your subscription options, visit:
5758 < > >> http://www.ircservices.za.net/mailman/listinfo/ircservices-
5763 < > >----------------------------------------------------------------
5765 < > >To unsubscribe or change your subscription options, visit:
5766 < > >http://www.ircservices.za.net/mailman/listinfo/ircservices-
5769 < > ========= End of Original Message =========
5773 < > -----------------------------------------------------------------
5775 < > To unsubscribe or change your subscription options, visit:
5776 < > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
5780 From RT.Mail at verizon.net Thu Mar 13 13:25:30 2003
5781 From: RT.Mail at verizon.net (RT.Mail@verizon.net)
5782 Date: Sat Oct 23 23:09:51 2004
5783 Subject: [IRCServices Coding] None
5784 In-Reply-To: <20030313211951.QIYQ2095.pop017.verizon.net@bofh>
5785 Message-ID: <20030313212535.ZDJH6546.out002.verizon.net@bofh>
5787 Well, there really is no good way that I know of... however it seems the bots we have all join a bunch of channels, so i have a
5788 bot sit in there and kill anyone who joins. We keep them mode +s so no real users join... as for bots that just join the server
5789 and not channels.. good luck :P Though there is something called floodworld, its supposed to help control those types of bots,
5790 I havent tried it so I dont know how, however the guy who codes it idles on my net.. he is working on the new version which
5793 < >On Thu, 13 Mar 2003 16:19:45 -0500, RT.Mail@verizon.net wrote:
5794 < > Craig is correct, however the DB has not had any more
5795 < > problems.... might have just been a freak thing. The only
5797 < > is the page not loading. FYI those 19,000 akills were from a 36
5798 < > hour period, if it werent for the damn bots we would have about
5801 < > < >On Thu, 13 Mar 2003 21:6:47 +0000, Craig McLure wrote:
5802 < > < > Russell has been subject to a large number of botfloods
5804 < > < > and has scripts to add akills when bots connect, last time i
5805 < > < > spoke to him he said that the services databases mess up
5807 < > < > certain ammount, but performance wise, its fine.
5809 < > < > -------------------------------------------------------------
5812 < > < > Craig McLure - Craig@chatspike.net
5813 < > < > ChatSpike - The users network: http://www.chatspike.net
5814 < > < > InspIRCd - Modular IRC server: http://www.inspircd.org
5815 < > < > <`RaSh> how do i install linux i got the cd and i dont see
5817 < > < > setup.exe or install.exe
5818 < > < > -------------------------------------------------------------
5822 < > < > ============ Original Message ============
5823 < > < > >From : "Russell Garrett" <rg@tcslon.com>
5824 < > < > >Reply-To : ircservices-coding@ircservices.za.net
5825 < > < > >To : RT.Mail@verizon.net
5826 < > < > >Subject : RE: [IRCServices Coding] None
5827 < > < > >Date : 2003-03-13
5830 < > < > >Out of interest, how does Services perform with this many
5831 < > < > akills? And, if
5832 < > < > >you don't mind me asking, how did you accumulate so many?
5835 < > < > >offenders almost certainly give up after a month or so, and
5838 < > < > >unlimited-timed akills is usually a pointless exercise. But
5839 < > < > it's just me
5840 < > < > >being nosy :).
5844 < > < > >> -----Original Message-----
5845 < > < > >> From: ircservices-coding-bounces@ircservices.za.net
5846 < > < > >> [mailto:ircservices-coding-bounces@ircservices.za.net]On
5848 < > < > >> Of RT.Mail@verizon.net
5849 < > < > >> Sent: 13 March 2003 10:04
5850 < > < > >> To: IRC Services Coding Mailing List
5851 < > < > >> Subject: [IRCServices Coding] None
5854 < > < > >> We have about 19,000 autokills on the akill list. When
5857 < > < > >> view them on the web it seems services only shows about
5859 < > < > >> before it stops loading the page. I have tried to view it
5862 < > < > >> Opera and IE, both have the same problem.
5864 < > < > >> ----------------------------------------------------------
5867 < > < > >> To unsubscribe or change your subscription options, visit:
5869 < > http://www.ircservices.za.net/mailman/listinfo/ircservices-
5874 < > < > >------------------------------------------------------------
5877 < > < > >To unsubscribe or change your subscription options, visit:
5878 < > < > >http://www.ircservices.za.net/mailman/listinfo/ircservices-
5881 < > < > ========= End of Original Message =========
5885 < > < > -------------------------------------------------------------
5888 < > < > To unsubscribe or change your subscription options, visit:
5889 < > < > http://www.ircservices.za.net/mailman/listinfo/ircservices-
5894 < > -----------------------------------------------------------------
5896 < > To unsubscribe or change your subscription options, visit:
5897 < > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
5901 From prince at zirc.org Sun Mar 23 20:13:33 2003
5902 From: prince at zirc.org (prince)
5903 Date: Sat Oct 23 23:09:51 2004
5904 Subject: [IRCServices Coding] session limit bug
5905 Message-ID: <000c01c2f1bb$bc4c71a0$e577e518@msns.eph.ptd.net>
5907 I've found a bug. Hoooray!
5909 When you use /msg OperServ raw svskill nickname :reason
5911 It kills the user with whatever reason -- however, when you use /msg OperServ session limit <number>
5913 it lists the person there as using multiple sessions as the number. For example, if I use OperServ to SVSKILL a nickname by the nick of X with the hostname blahblah.com three times, and I try to get a list of people using 3 sessions at once via (/msg OperServ session list 3), it will list that hostname blablah.com is using 3 sessions.
5916 -------------- next part --------------
5917 An HTML attachment was scrubbed...
5918 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030323/3ba6e089/attachment.html
5919 From quension at mac.com Sun Mar 23 20:46:47 2003
5920 From: quension at mac.com (Trevor Talbot)
5921 Date: Sat Oct 23 23:09:51 2004
5922 Subject: [IRCServices Coding] session limit bug
5923 In-Reply-To: <000c01c2f1bb$bc4c71a0$e577e518@msns.eph.ptd.net>
5924 Message-ID: <9EBB61AA-5DB3-11D7-8F95-0003938D6866@mac.com>
5926 On Sunday, Mar 23, 2003, at 20:13 US/Pacific, prince wrote:
5928 > I've found a bug. Hoooray!
5932 > When you use /msg OperServ raw svskill nickname :reason
5934 RTFM, or hell, even just /msg operserv help raw.
5938 From prince at zirc.org Sun Mar 23 20:41:27 2003
5939 From: prince at zirc.org (prince)
5940 Date: Sat Oct 23 23:09:51 2004
5941 Subject: [IRCServices Coding] session limit bug
5942 References: <9EBB61AA-5DB3-11D7-8F95-0003938D6866@mac.com>
5943 Message-ID: <001a01c2f1bf$a21f4100$e577e518@msns.eph.ptd.net>
5945 Well, I hate to break it to you...but OS help mentions *nothing* of this,
5946 and when I read the fine manual, or fucking manual, however you want to put
5947 it, it also said nothing of this. So I felt like I should report it. If
5948 you have a problem with such "lame emails" or "lame comments" about
5949 IRCServices, perhaps you should remove yourself from the mailing list or
5950 stop replying with comments such as yours? heh.
5952 ----- Original Message -----
5953 From: "Trevor Talbot" <quension@mac.com>
5954 To: "IRC Services Coding Mailing List"
5955 <ircservices-coding@ircservices.za.net>
5956 Sent: Sunday, March 23, 2003 11:46 PM
5957 Subject: Re: [IRCServices Coding] session limit bug
5960 > On Sunday, Mar 23, 2003, at 20:13 US/Pacific, prince wrote:
5962 > > I've found a bug. Hoooray!
5966 > > When you use /msg OperServ raw svskill nickname :reason
5968 > RTFM, or hell, even just /msg operserv help raw.
5972 > ------------------------------------------------------------------
5973 > To unsubscribe or change your subscription options, visit:
5974 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
5977 From quension at mac.com Sun Mar 23 21:03:13 2003
5978 From: quension at mac.com (Trevor Talbot)
5979 Date: Sat Oct 23 23:09:51 2004
5980 Subject: [IRCServices Coding] session limit bug
5981 In-Reply-To: <001a01c2f1bf$a21f4100$e577e518@msns.eph.ptd.net>
5982 Message-ID: <EA93A0FA-5DB5-11D7-8F95-0003938D6866@mac.com>
5984 On Sunday, Mar 23, 2003, at 20:41 US/Pacific, prince wrote:
5986 > Well, I hate to break it to you...but OS help mentions *nothing* of
5988 > and when I read the fine manual, or fucking manual, however you want
5990 > it, it also said nothing of this. So I felt like I should report it.
5993 It says, "This command has a very limited range of uses, and can wreak
5994 havoc on a network or cause Services to crash if used improperly. DO
5996 USE THIS COMMAND unless you are absolutely certain you know what you are
5999 The reason why you are experiencing the issue you are is related to the
6000 ircd's handling of SVSKILL. ircservices does not do any processing on
6001 the operserv raw command itself; it simply sends it to its uplink
6003 Therefore, if the ircd does not tell services that the user is gone,
6004 services never knows.
6006 To put it bluntly, you do not know what you are doing.
6008 > you have a problem with such "lame emails" or "lame comments" about
6009 > IRCServices, perhaps you should remove yourself from the mailing list
6011 > stop replying with comments such as yours? heh.
6013 That is not my problem. I replied bluntly and simply because this issue
6014 has been answered several times before. Mailing list archives exist and
6017 Even if not understanding the manual/help text completely, a bit of
6018 effort on your part could have avoided this entire email exchange.
6020 > ----- Original Message -----
6021 > From: "Trevor Talbot" <quension@mac.com>
6023 >> On Sunday, Mar 23, 2003, at 20:13 US/Pacific, prince wrote:
6025 >>> I've found a bug. Hoooray!
6029 >>> When you use /msg OperServ raw svskill nickname :reason
6031 >> RTFM, or hell, even just /msg operserv help raw.
6035 From quension at mac.com Sun Mar 23 21:11:07 2003
6036 From: quension at mac.com (Trevor Talbot)
6037 Date: Sat Oct 23 23:09:51 2004
6038 Subject: [IRCServices Coding] session limit bug
6039 In-Reply-To: <EA93A0FA-5DB5-11D7-8F95-0003938D6866@mac.com>
6040 Message-ID: <051288BA-5DB7-11D7-8F95-0003938D6866@mac.com>
6042 > Mailing list archives exist and are searchable.
6044 I should revise that a bit: there is no direct search interface
6045 to the archives (I had thought there was, apologies), but Google
6046 is aware of them, so searches via Google will work.
6050 From prince at zirc.org Sun Mar 23 21:01:08 2003
6051 From: prince at zirc.org (prince)
6052 Date: Sat Oct 23 23:09:51 2004
6053 Subject: [IRCServices Coding] session limit bug
6054 References: <EA93A0FA-5DB5-11D7-8F95-0003938D6866@mac.com>
6055 Message-ID: <002d01c2f1c2$61d51860$e577e518@msns.eph.ptd.net>
6057 Right, it does not say "This command will cause multiple session limits if
6058 you use SVSKILL on a user" - and I very much do know what I'm doing. I
6059 think, perhaps, instead of commenting on people's messages you should let
6060 somebody who runs this list do so, instead of filling people's inbox up with
6061 your pointless ramblings. I rarely use this list, except when I find
6062 something wrong. I wasn't asking for your comments, I was asking if a fix
6063 could be made, I guess you missed that part, eh? But I'm not here to bicker
6064 back and forth with you, my question still stands - can a fix be made?
6065 So, Trevor Talbot, don't reply to this, as I'm not insterested in reading
6066 what you have to say, yet I'm interested in knowing if it can be fixed. So
6067 please refrain from your comments that do not fix or help this problem in
6070 ----- Original Message -----
6071 From: "Trevor Talbot" <quension@mac.com>
6072 To: "IRC Services Coding Mailing List"
6073 <ircservices-coding@ircservices.za.net>
6074 Sent: Monday, March 24, 2003 12:03 AM
6075 Subject: Re: [IRCServices Coding] session limit bug
6078 > On Sunday, Mar 23, 2003, at 20:41 US/Pacific, prince wrote:
6080 > > Well, I hate to break it to you...but OS help mentions *nothing* of
6082 > > and when I read the fine manual, or fucking manual, however you want
6084 > > it, it also said nothing of this. So I felt like I should report it.
6087 > It says, "This command has a very limited range of uses, and can wreak
6088 > havoc on a network or cause Services to crash if used improperly. DO
6090 > USE THIS COMMAND unless you are absolutely certain you know what you are
6093 > The reason why you are experiencing the issue you are is related to the
6094 > ircd's handling of SVSKILL. ircservices does not do any processing on
6095 > the operserv raw command itself; it simply sends it to its uplink
6097 > Therefore, if the ircd does not tell services that the user is gone,
6098 > services never knows.
6100 > To put it bluntly, you do not know what you are doing.
6102 > > you have a problem with such "lame emails" or "lame comments" about
6103 > > IRCServices, perhaps you should remove yourself from the mailing list
6105 > > stop replying with comments such as yours? heh.
6107 > That is not my problem. I replied bluntly and simply because this issue
6108 > has been answered several times before. Mailing list archives exist and
6111 > Even if not understanding the manual/help text completely, a bit of
6112 > effort on your part could have avoided this entire email exchange.
6114 > > ----- Original Message -----
6115 > > From: "Trevor Talbot" <quension@mac.com>
6117 > >> On Sunday, Mar 23, 2003, at 20:13 US/Pacific, prince wrote:
6119 > >>> I've found a bug. Hoooray!
6121 > >> No, you haven't.
6123 > >>> When you use /msg OperServ raw svskill nickname :reason
6125 > >> RTFM, or hell, even just /msg operserv help raw.
6129 > ------------------------------------------------------------------
6130 > To unsubscribe or change your subscription options, visit:
6131 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6134 From RT.Mail at verizon.net Sun Mar 23 21:22:20 2003
6135 From: RT.Mail at verizon.net (RT.Mail@verizon.net)
6136 Date: Sat Oct 23 23:09:51 2004
6137 Subject: [IRCServices Coding] session limit bug
6138 In-Reply-To: <002d01c2f1c2$61d51860$e577e518@msns.eph.ptd.net>
6139 Message-ID: <20030324052225.DTWH24156.pop015.verizon.net@bofh>
6141 It doesn't need a fix, it tells you not to use it. It's supposed to send a raw command to the ircd thru the services, that's what it
6142 does. If it makes the services not function correctly then you should not be using it for killing people.
6144 < >On Mon, 24 Mar 2003 00:01:08 -0500, prince wrote:
6145 < > Right, it does not say "This command will cause multiple session
6147 < > you use SVSKILL on a user" - and I very much do know what I'm
6149 < > think, perhaps, instead of commenting on people's messages you
6151 < > somebody who runs this list do so, instead of filling people's
6153 < > your pointless ramblings. I rarely use this list, except when I
6155 < > something wrong. I wasn't asking for your comments, I was
6157 < > could be made, I guess you missed that part, eh? But I'm not
6159 < > back and forth with you, my question still stands - can a fix be
6161 < > So, Trevor Talbot, don't reply to this, as I'm not insterested
6163 < > what you have to say, yet I'm interested in knowing if it can be
6165 < > please refrain from your comments that do not fix or help this
6169 < > ----- Original Message -----
6170 < > From: "Trevor Talbot" <quension@mac.com>
6171 < > To: "IRC Services Coding Mailing List"
6172 < > <ircservices-coding@ircservices.za.net>
6173 < > Sent: Monday, March 24, 2003 12:03 AM
6174 < > Subject: Re: [IRCServices Coding] session limit bug
6177 < > > On Sunday, Mar 23, 2003, at 20:41 US/Pacific, prince wrote:
6179 < > > > Well, I hate to break it to you...but OS help mentions *
6182 < > > > and when I read the fine manual, or fucking manual, however
6185 < > > > it, it also said nothing of this. So I felt like I should
6189 < > > It says, "This command has a very limited range of uses, and
6191 < > > havoc on a network or cause Services to crash if used
6194 < > > USE THIS COMMAND unless you are absolutely certain you know
6198 < > > The reason why you are experiencing the issue you are is
6200 < > > ircd's handling of SVSKILL. ircservices does not do any
6202 < > > the operserv raw command itself; it simply sends it to its
6205 < > > Therefore, if the ircd does not tell services that the user is
6207 < > > services never knows.
6209 < > > To put it bluntly, you do not know what you are doing.
6211 < > > > you have a problem with such "lame emails" or "lame
6213 < > > > IRCServices, perhaps you should remove yourself from the
6216 < > > > stop replying with comments such as yours? heh.
6218 < > > That is not my problem. I replied bluntly and simply because
6220 < > > has been answered several times before. Mailing list archives
6222 < > > are searchable.
6224 < > > Even if not understanding the manual/help text completely, a
6226 < > > effort on your part could have avoided this entire email
6229 < > > > ----- Original Message -----
6230 < > > > From: "Trevor Talbot" <quension@mac.com>
6232 < > > >> On Sunday, Mar 23, 2003, at 20:13 US/Pacific, prince wrote:
6234 < > > >>> I've found a bug. Hoooray!
6236 < > > >> No, you haven't.
6238 < > > >>> When you use /msg OperServ raw svskill nickname :reason
6240 < > > >> RTFM, or hell, even just /msg operserv help raw.
6244 < > > ---------------------------------------------------------------
6246 < > > To unsubscribe or change your subscription options, visit:
6247 < > > http://www.ircservices.za.net/mailman/listinfo/ircservices-
6251 < > -----------------------------------------------------------------
6253 < > To unsubscribe or change your subscription options, visit:
6254 < > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6258 From prince at zirc.org Sun Mar 23 21:21:10 2003
6259 From: prince at zirc.org (prince)
6260 Date: Sat Oct 23 23:09:51 2004
6261 Subject: [IRCServices Coding] session limit bug
6262 References: <20030324052225.DTWH24156.pop015.verizon.net@bofh>
6263 Message-ID: <005701c2f1c5$2e803280$e577e518@msns.eph.ptd.net>
6265 I disagree. I think it does need a fix. I do not need to sit and explain
6266 why the command was used, but obviously it's not going to drop at that so I
6267 suppose I must explain a little bit. I'm not asking all of you people out
6268 there to comment on what I've sent in, but apparently all of you must get in
6269 my business. I'm asking the coder of this program and list if a fix can be
6270 made or not and if he is willing to do it, not all of you.
6271 If you'd like to know why the command was used I suggest you log on my
6272 network and find out, we have other custom perl services made which use the
6273 SVSKILL command. Which creates a problem with this "bug" which none of you
6274 seem to think is a bug. Now, if you could all kindly stop treating me like
6275 a moron which I'm not I'd kindly stop replying to these pointless emails,
6276 which, are very much rather pointless, but for some odd reason I feel the
6277 need to defend myself. All I would like is a simple yes or no reply from
6278 andrew church and I'll be on my way. ;)
6280 ----- Original Message -----
6281 From: <RT.Mail@verizon.net>
6282 To: "IRC Services Coding Mailing List"
6283 <ircservices-coding@ircservices.za.net>
6284 Sent: Monday, March 24, 2003 12:22 AM
6285 Subject: Re: [IRCServices Coding] session limit bug
6288 It doesn't need a fix, it tells you not to use it. It's supposed to send a
6289 raw command to the ircd thru the services, that's what it
6290 does. If it makes the services not function correctly then you should not be
6291 using it for killing people.
6293 < >On Mon, 24 Mar 2003 00:01:08 -0500, prince wrote:
6294 < > Right, it does not say "This command will cause multiple session
6296 < > you use SVSKILL on a user" - and I very much do know what I'm
6298 < > think, perhaps, instead of commenting on people's messages you
6300 < > somebody who runs this list do so, instead of filling people's
6302 < > your pointless ramblings. I rarely use this list, except when I
6304 < > something wrong. I wasn't asking for your comments, I was
6306 < > could be made, I guess you missed that part, eh? But I'm not
6308 < > back and forth with you, my question still stands - can a fix be
6310 < > So, Trevor Talbot, don't reply to this, as I'm not insterested
6312 < > what you have to say, yet I'm interested in knowing if it can be
6314 < > please refrain from your comments that do not fix or help this
6318 < > ----- Original Message -----
6319 < > From: "Trevor Talbot" <quension@mac.com>
6320 < > To: "IRC Services Coding Mailing List"
6321 < > <ircservices-coding@ircservices.za.net>
6322 < > Sent: Monday, March 24, 2003 12:03 AM
6323 < > Subject: Re: [IRCServices Coding] session limit bug
6326 < > > On Sunday, Mar 23, 2003, at 20:41 US/Pacific, prince wrote:
6328 < > > > Well, I hate to break it to you...but OS help mentions *
6331 < > > > and when I read the fine manual, or fucking manual, however
6334 < > > > it, it also said nothing of this. So I felt like I should
6338 < > > It says, "This command has a very limited range of uses, and
6340 < > > havoc on a network or cause Services to crash if used
6343 < > > USE THIS COMMAND unless you are absolutely certain you know
6347 < > > The reason why you are experiencing the issue you are is
6349 < > > ircd's handling of SVSKILL. ircservices does not do any
6351 < > > the operserv raw command itself; it simply sends it to its
6354 < > > Therefore, if the ircd does not tell services that the user is
6356 < > > services never knows.
6358 < > > To put it bluntly, you do not know what you are doing.
6360 < > > > you have a problem with such "lame emails" or "lame
6362 < > > > IRCServices, perhaps you should remove yourself from the
6365 < > > > stop replying with comments such as yours? heh.
6367 < > > That is not my problem. I replied bluntly and simply because
6369 < > > has been answered several times before. Mailing list archives
6371 < > > are searchable.
6373 < > > Even if not understanding the manual/help text completely, a
6375 < > > effort on your part could have avoided this entire email
6378 < > > > ----- Original Message -----
6379 < > > > From: "Trevor Talbot" <quension@mac.com>
6381 < > > >> On Sunday, Mar 23, 2003, at 20:13 US/Pacific, prince wrote:
6383 < > > >>> I've found a bug. Hoooray!
6385 < > > >> No, you haven't.
6387 < > > >>> When you use /msg OperServ raw svskill nickname :reason
6389 < > > >> RTFM, or hell, even just /msg operserv help raw.
6393 < > > ---------------------------------------------------------------
6395 < > > To unsubscribe or change your subscription options, visit:
6396 < > > http://www.ircservices.za.net/mailman/listinfo/ircservices-
6400 < > -----------------------------------------------------------------
6402 < > To unsubscribe or change your subscription options, visit:
6403 < > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6407 ------------------------------------------------------------------
6408 To unsubscribe or change your subscription options, visit:
6409 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6411 From achurch at achurch.org Mon Mar 24 14:50:35 2003
6412 From: achurch at achurch.org (Andrew Church)
6413 Date: Sat Oct 23 23:09:51 2004
6414 Subject: [IRCServices Coding] session limit bug
6415 In-Reply-To: <001a01c2f1bf$a21f4100$e577e518@msns.eph.ptd.net>
6416 Message-ID: <3e7e9cb3.03420@mail.achurch.org>
6424 >Well, I hate to break it to you...but OS help mentions *nothing* of this,
6425 >and when I read the fine manual, or fucking manual, however you want to put
6426 >it, it also said nothing of this. So I felt like I should report it. If
6427 >you have a problem with such "lame emails" or "lame comments" about
6428 >IRCServices, perhaps you should remove yourself from the mailing list or
6429 >stop replying with comments such as yours? heh.
6431 >----- Original Message -----
6432 >From: "Trevor Talbot" <quension@mac.com>
6433 >To: "IRC Services Coding Mailing List"
6434 ><ircservices-coding@ircservices.za.net>
6435 >Sent: Sunday, March 23, 2003 11:46 PM
6436 >Subject: Re: [IRCServices Coding] session limit bug
6439 >> On Sunday, Mar 23, 2003, at 20:13 US/Pacific, prince wrote:
6441 >> > I've found a bug. Hoooray!
6445 >> > When you use /msg OperServ raw svskill nickname :reason
6447 >> RTFM, or hell, even just /msg operserv help raw.
6451 >> ------------------------------------------------------------------
6452 >> To unsubscribe or change your subscription options, visit:
6453 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6456 >------------------------------------------------------------------
6457 >To unsubscribe or change your subscription options, visit:
6458 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6459 From prince at zirc.org Sun Mar 23 21:45:04 2003
6460 From: prince at zirc.org (prince)
6461 Date: Sat Oct 23 23:09:51 2004
6462 Subject: [IRCServices Coding] session limit bug
6463 References: <3e7e9cb3.03420@mail.achurch.org>
6464 Message-ID: <007101c2f1c8$84de2760$e577e518@msns.eph.ptd.net>
6466 Thanks, I'll have our custom services coded to kill a different way. :)
6468 Just out of curiousity, why does the RAW command screw with the servers to
6471 ----- Original Message -----
6472 From: "Andrew Church" <achurch@achurch.org>
6473 To: <ircservices-coding@ircservices.za.net>
6474 Sent: Monday, March 24, 2003 12:50 AM
6475 Subject: Re: [IRCServices Coding] session limit bug
6481 > achurch@achurch.org
6482 > http://achurch.org/
6484 > >Well, I hate to break it to you...but OS help mentions *nothing* of this,
6485 > >and when I read the fine manual, or fucking manual, however you want to
6487 > >it, it also said nothing of this. So I felt like I should report it. If
6488 > >you have a problem with such "lame emails" or "lame comments" about
6489 > >IRCServices, perhaps you should remove yourself from the mailing list or
6490 > >stop replying with comments such as yours? heh.
6492 > >----- Original Message -----
6493 > >From: "Trevor Talbot" <quension@mac.com>
6494 > >To: "IRC Services Coding Mailing List"
6495 > ><ircservices-coding@ircservices.za.net>
6496 > >Sent: Sunday, March 23, 2003 11:46 PM
6497 > >Subject: Re: [IRCServices Coding] session limit bug
6500 > >> On Sunday, Mar 23, 2003, at 20:13 US/Pacific, prince wrote:
6502 > >> > I've found a bug. Hoooray!
6504 > >> No, you haven't.
6506 > >> > When you use /msg OperServ raw svskill nickname :reason
6508 > >> RTFM, or hell, even just /msg operserv help raw.
6512 > >> ------------------------------------------------------------------
6513 > >> To unsubscribe or change your subscription options, visit:
6514 > >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6517 > >------------------------------------------------------------------
6518 > >To unsubscribe or change your subscription options, visit:
6519 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6520 > ------------------------------------------------------------------
6521 > To unsubscribe or change your subscription options, visit:
6522 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6525 From ShadowMaster at Shadow-Realm.org Sun Mar 23 22:04:40 2003
6526 From: ShadowMaster at Shadow-Realm.org (Thomas J. =?iso-8859-1?q?Stens=E5s?=)
6527 Date: Sat Oct 23 23:09:51 2004
6528 Subject: [IRCServices Coding] session limit bug
6529 In-Reply-To: <007101c2f1c8$84de2760$e577e518@msns.eph.ptd.net>
6530 References: <3e7e9cb3.03420@mail.achurch.org>
6531 <007101c2f1c8$84de2760$e577e518@msns.eph.ptd.net>
6532 Message-ID: <200303240704.46250.ShadowMaster@Shadow-Realm.org>
6534 -----BEGIN PGP SIGNED MESSAGE-----
6537 On Monday 24 March 2003 06:45, prince wrote:
6538 > Thanks, I'll have our custom services coded to kill a different way. :)
6540 > Just out of curiousity, why does the RAW command screw with the servers to
6543 This has already been answered, and is also answered in the FAQ section just
6548 Thomas Juberg Stens?s
6550 - -- What we do in life echoes in eternity
6552 -----BEGIN PGP SIGNATURE-----
6553 Version: GnuPG v1.2.1 (GNU/Linux)
6555 iD8DBQE+fp/7m5JSuDogRncRAhi8AJ9gbfTmsIQD3smxc3ovSShpTIdQcQCfY+As
6556 hm2CETBlKqLgfMiKqfU20IA=
6558 -----END PGP SIGNATURE-----
6560 From griever at t2n.org Sun Mar 23 22:06:51 2003
6561 From: griever at t2n.org (Finny Merrill)
6562 Date: Sat Oct 23 23:09:51 2004
6563 Subject: [IRCServices Coding] session limit bug
6564 In-Reply-To: <005701c2f1c5$2e803280$e577e518@msns.eph.ptd.net>
6565 References: <20030324052225.DTWH24156.pop015.verizon.net@bofh>
6566 <005701c2f1c5$2e803280$e577e518@msns.eph.ptd.net>
6567 Message-ID: <oprmiy9p083wwnu9@mail-hub.optonline.net>
6569 On Mon, 24 Mar 2003 00:21:10 -0500, prince <prince@zirc.org> wrote:
6571 > I disagree. I think it does need a fix. I do not need to sit and
6576 If you REALLY need to use svskill, write a module that does it and handles
6578 properly rather than using raw. Andrew church, as you can see from the
6580 gives the exact same answer as the others already have when it comes to
6583 Raw does exactly what it's designed to do, and the bug here is the way that
6587 Also, see FAQ question F.8
6588 From achurch at achurch.org Mon Mar 24 15:01:00 2003
6589 From: achurch at achurch.org (Andrew Church)
6590 Date: Sat Oct 23 23:09:51 2004
6591 Subject: [IRCServices Coding] session limit bug
6592 In-Reply-To: <007101c2f1c8$84de2760$e577e518@msns.eph.ptd.net>
6593 Message-ID: <3e7ea030.03437@mail.achurch.org>
6595 >Thanks, I'll have our custom services coded to kill a different way. :)
6597 >Just out of curiousity, why does the RAW command screw with the servers to
6600 Well, there are two answers to the question "why is the RAW command
6601 bad?", which is what I think you mean. One is that some IRC servers are
6602 *ahem* less than robust with respect to bad input, and if you send a badly
6603 formed message with the RAW command, you could end up crashing your uplink
6604 server, or even the entire network.
6606 The other answer relates to Services itself; Services does not process
6607 the RAW command because there are times (such as when testing a new IRC
6608 protocol feature) when it would be inappropriate for Services to process
6609 the message itself, and the RAW command is intended for use in those cases.
6614 From achurch at achurch.org Mon Mar 24 15:05:51 2003
6615 From: achurch at achurch.org (Andrew Church)
6616 Date: Sat Oct 23 23:09:51 2004
6617 Subject: Top posting (was Re: [IRCServices Coding] session limit bug)
6618 In-Reply-To: <oprmiy9p083wwnu9@mail-hub.optonline.net>
6619 Message-ID: <3e7ea15d.03457@mail.achurch.org>
6623 I've refrained from mentioning this until now, but (as should be
6624 obvious from my own messages) top posting is perfectly fine on _this_
6625 mailing list, regardless of what RFC 1855 has to say on the matter.
6626 Period, end of discussion. Don't bring this up again.
6631 From noam_m at bezeqint.net Sun Mar 23 23:42:31 2003
6632 From: noam_m at bezeqint.net (Noam M.)
6633 Date: Sat Oct 23 23:09:51 2004
6634 Subject: [IRCServices Coding] session limit bug
6635 In-Reply-To: <007101c2f1c8$84de2760$e577e518@msns.eph.ptd.net>
6636 References: <3e7e9cb3.03420@mail.achurch.org>
6637 <007101c2f1c8$84de2760$e577e518@msns.eph.ptd.net>
6638 Message-ID: <3E7EB6E7.4070301@bezeqint.net>
6641 > Thanks, I'll have our custom services coded to kill a different way. :)
6643 it still doesnt seem you understood the problem. your custom services
6644 can kill using the SVSKILL command, aslong as they act asif they just
6645 got the SVSKILL msg from their uplink server too.
6646 if you send an SVSKILL from a Ulined server which isnt services,
6647 services will see it too and it is not the same as using operserv raw.
6649 I am very wrong if your custom services are doing 'os raw svskill ...' ,
6650 then ofcourse you should kill in a diffrent way :p
6652 From brain at brainbox.winbot.co.uk Mon Mar 24 10:14:25 2003
6653 From: brain at brainbox.winbot.co.uk (Craig Edwards)
6654 Date: Sat Oct 23 23:09:51 2004
6655 Subject: [IRCServices Coding] session limit bug
6656 Message-ID: <200303241814.h2OIEXV11701@localhost.localdomain>
6658 I know people will probably ignore or shoot down this request but, here goes....
6660 Is there a way to keep services in sync if its desynced, by resyncing it at fixed intervals? This would not only fix problems caused by (ab)use of operserv raw, but would also fix problems caused in other ways (ive had a couple of desyncs before caused by buggy server software etc) - it could be set from config to say resync once every 24h or once every week or whenever the admin prefers, by simulating a form of "warm reboot" where it could somehow retrieve all network information again from the uplink and redo its lists from scratch, kinda like a rehash.... or maybe do this on /os rehash if a commandline option is given? Just an idea...
6662 >I've found a bug. Hoooray!
6664 >When you use /msg OperServ raw svskill nickname :reason
6666 >It kills the user with whatever reason -- however, when you use /msg OperServ session limit <number>
6668 >it lists the person there as using multiple sessions as the number. For example, if I use OperServ to SVSKILL a nickname by the nick of X with the hostname blahblah.com three times, and I try to get a list of people using 3 sessions at once via (/msg OperServ session list 3), it will list that hostname blablah.com is using 3 sessions.
6671 >------------------------------------------------------------------
6672 >To unsubscribe or change your subscription options, visit:
6673 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6676 From RT.Mail at verizon.net Mon Mar 24 10:15:14 2003
6677 From: RT.Mail at verizon.net (RT.Mail@verizon.net)
6678 Date: Sat Oct 23 23:09:51 2004
6679 Subject: [IRCServices Coding] session limit bug
6680 In-Reply-To: <200303241814.h2OIEXV11701@localhost.localdomain>
6681 Message-ID: <20030324181519.GZVP9562.out002.verizon.net@bofh>
6683 That would be nice if that could be done at an interval the admin defines.
6685 < >On Mon, 24 Mar 2003 18:14:25 +0000, Craig Edwards wrote:
6686 < > know people will probably ignore or shoot down this request
6687 < > but, here goes....
6689 < > Is there a way to keep services in sync if its desynced, by
6690 < > resyncing it at fixed intervals? This would not only fix
6691 < > problems caused by (ab)use of operserv raw, but would also fix
6692 < > problems caused in other ways (ive had a couple
6693 < > of desyncs before caused by buggy server software etc) - it
6694 < > could be set from config to say resync once every 24h
6695 < > or once every week or whenever the admin prefers, by simulating
6696 < > a form of "warm reboot" where it could somehow
6697 < > retrieve all network information again from the uplink and redo
6698 < > its lists from scratch, kinda like a rehash.... or
6699 < > maybe do this on /os rehash if a commandline option is given?
6704 From georges at berscheid.lu Mon Mar 24 10:22:30 2003
6705 From: georges at berscheid.lu (Georges Berscheid)
6706 Date: Sat Oct 23 23:09:51 2004
6707 Subject: AW: [IRCServices Coding] session limit bug
6708 In-Reply-To: <200303241814.h2OIEXV11701@localhost.localdomain>
6709 Message-ID: <000301c2f232$56b8bf70$4dbbf683@globi>
6713 the requested command exists: /os restart
6714 How do you think services could possibly make the uplink send all the
6715 information again, as if services just joined the network? This
6716 'simulated-net-merge-situation' would have to be supported by the
6721 P.S. The original problem is not a services issue anyway...
6724 -----Urspr?ngliche Nachricht-----
6725 Von: ircservices-coding-bounces@ircservices.za.net
6726 [mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
6728 Gesendet: Montag, 24. M?rz 2003 19:14
6729 An: IRC Services Coding Mailing List
6730 Betreff: Re: [IRCServices Coding] session limit bug
6733 I know people will probably ignore or shoot down this request but, here
6736 Is there a way to keep services in sync if its desynced, by resyncing it
6737 at fixed intervals? This would not only fix problems caused by (ab)use
6738 of operserv raw, but would also fix problems caused in other ways (ive
6739 had a couple of desyncs before caused by buggy server software etc) - it
6740 could be set from config to say resync once every 24h or once every week
6741 or whenever the admin prefers, by simulating a form of "warm reboot"
6742 where it could somehow retrieve all network information again from the
6743 uplink and redo its lists from scratch, kinda like a rehash.... or maybe
6744 do this on /os rehash if a commandline option is given? Just an idea...
6746 >I've found a bug. Hoooray!
6748 >When you use /msg OperServ raw svskill nickname :reason
6750 >It kills the user with whatever reason -- however, when you use /msg
6751 OperServ session limit <number>
6753 >it lists the person there as using multiple sessions as the number.
6754 For example, if I use OperServ to SVSKILL a nickname by the nick of X
6755 with the hostname blahblah.com three times, and I try to get a list of
6756 people using 3 sessions at once via (/msg OperServ session list 3), it
6757 will list that hostname blablah.com is using 3 sessions.
6760 >------------------------------------------------------------------
6761 >To unsubscribe or change your subscription options, visit:
6762 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6765 ------------------------------------------------------------------
6766 To unsubscribe or change your subscription options, visit:
6767 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6770 From brain at brainbox.winbot.co.uk Mon Mar 24 10:41:21 2003
6771 From: brain at brainbox.winbot.co.uk (Craig Edwards)
6772 Date: Sat Oct 23 23:09:51 2004
6773 Subject: AW: [IRCServices Coding] session limit bug
6774 Message-ID: <200303241841.h2OIfTV12087@localhost.localdomain>
6776 True, unless it was to disconnect then reconnect, without need for a restart. SQUIT and /os restart terminates the process as well as the connection to the uplink, correct? I've written a bot that manages to resync this way... admittedly thats a client and here we're talking about a server but you never know, anythings possible :-)
6780 >the requested command exists: /os restart
6781 >How do you think services could possibly make the uplink send all the
6782 >information again, as if services just joined the network? This
6783 >'simulated-net-merge-situation' would have to be supported by the
6788 >P.S. The original problem is not a services issue anyway...
6791 >-----Ursprüngliche Nachricht-----
6792 >Von: ircservices-coding-bounces@ircservices.za.net
6793 >[mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
6795 >Gesendet: Montag, 24. März 2003 19:14
6796 >An: IRC Services Coding Mailing List
6797 >Betreff: Re: [IRCServices Coding] session limit bug
6800 >I know people will probably ignore or shoot down this request but, here
6803 >Is there a way to keep services in sync if its desynced, by resyncing it
6804 >at fixed intervals? This would not only fix problems caused by (ab)use
6805 >of operserv raw, but would also fix problems caused in other ways (ive
6806 >had a couple of desyncs before caused by buggy server software etc) - it
6807 >could be set from config to say resync once every 24h or once every week
6808 >or whenever the admin prefers, by simulating a form of "warm reboot"
6809 >where it could somehow retrieve all network information again from the
6810 >uplink and redo its lists from scratch, kinda like a rehash.... or maybe
6811 >do this on /os rehash if a commandline option is given? Just an idea...
6813 >>I've found a bug. Hoooray!
6815 >>When you use /msg OperServ raw svskill nickname :reason
6817 >>It kills the user with whatever reason -- however, when you use /msg
6818 >OperServ session limit <number>
6820 >>it lists the person there as using multiple sessions as the number.
6821 >For example, if I use OperServ to SVSKILL a nickname by the nick of X
6822 >with the hostname blahblah.com three times, and I try to get a list of
6823 >people using 3 sessions at once via (/msg OperServ session list 3), it
6824 >will list that hostname blablah.com is using 3 sessions.
6826 >>Can this be fixed?
6827 >>------------------------------------------------------------------
6828 >>To unsubscribe or change your subscription options, visit:
6829 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6832 >------------------------------------------------------------------
6833 >To unsubscribe or change your subscription options, visit:
6834 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6837 >------------------------------------------------------------------
6838 >To unsubscribe or change your subscription options, visit:
6839 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6842 From gastaman at azzurra.org Mon Mar 24 10:28:23 2003
6843 From: gastaman at azzurra.org (Gastaman)
6844 Date: Sat Oct 23 23:09:51 2004
6845 Subject: [IRCServices Coding] session limit bug
6846 In-Reply-To: <200303241814.h2OIEXV11701@localhost.localdomain>
6847 Message-ID: <5.1.0.14.2.20030324192145.031578d8@mail.telvia.it>
6849 It was 06:14 PM 3/24/2003 +0000 when Craig Edwards came up
6851 >Is there a way to keep services in sync if its desynced, by
6852 >resyncing it at fixed intervals? This would not only fix
6853 >problems caused by (ab)use of operserv raw, but would also fix
6854 >problems caused in other ways (ive had a couple of desyncs
6855 >before caused by buggy server software etc) - it could be set
6856 >from config to say resync once every 24h or once every week or
6857 >whenever the admin prefers, by simulating a form of "warm
6858 >reboot" where it could somehow retrieve all network
6859 >information again from the uplink and redo its lists from
6860 >scratch, kinda like a rehash.... or maybe do this on /os
6861 >rehash if a commandline option is given? Just an idea...
6863 Not if the ircd doesn't support it, and as far
6864 as I know none does (certainly not Bahamut,
6865 any version), unless you squit and reconnect.
6867 And besides, use of the RAW command is not
6868 recommended for the very reason it can lead
6869 to desynchs, and IMHO any services should not
6870 waste time/cpu/memory/whatever to try and
6871 fix input errors, it should be left to whoever
6872 inputs the wrong commands to refrain from
6875 As for buggy server software (are you running
6876 Unreal? =P), bugs should be fixed on the server's
6877 side, not on the services' if they do their job.
6880 From dylanvdm at icon.co.za Mon Mar 24 11:40:23 2003
6881 From: dylanvdm at icon.co.za (Dylan v.d Merwe)
6882 Date: Sat Oct 23 23:09:51 2004
6883 Subject: [IRCServices Coding] session limit bug
6884 References: <5.1.0.14.2.20030324192145.031578d8@mail.telvia.it>
6885 Message-ID: <006a01c2f23d$37b1a0f0$56ccef9b@dylan>
6887 Please don't diss people's work (aka the Unreal comment). It's not called
6888 for and a lot of hard work has gone into it. Sorry to fill up peoples'
6893 ----- Original Message -----
6894 From: "Gastaman" <gastaman@azzurra.org>
6895 To: "IRC Services Coding Mailing List"
6896 <ircservices-coding@ircservices.za.net>
6897 Sent: Monday, March 24, 2003 8:28 PM
6898 Subject: Re: [IRCServices Coding] session limit bug
6901 > It was 06:14 PM 3/24/2003 +0000 when Craig Edwards came up
6903 > >Is there a way to keep services in sync if its desynced, by
6904 > >resyncing it at fixed intervals? This would not only fix
6905 > >problems caused by (ab)use of operserv raw, but would also fix
6906 > >problems caused in other ways (ive had a couple of desyncs
6907 > >before caused by buggy server software etc) - it could be set
6908 > >from config to say resync once every 24h or once every week or
6909 > >whenever the admin prefers, by simulating a form of "warm
6910 > >reboot" where it could somehow retrieve all network
6911 > >information again from the uplink and redo its lists from
6912 > >scratch, kinda like a rehash.... or maybe do this on /os
6913 > >rehash if a commandline option is given? Just an idea...
6915 > Not if the ircd doesn't support it, and as far
6916 > as I know none does (certainly not Bahamut,
6917 > any version), unless you squit and reconnect.
6919 > And besides, use of the RAW command is not
6920 > recommended for the very reason it can lead
6921 > to desynchs, and IMHO any services should not
6922 > waste time/cpu/memory/whatever to try and
6923 > fix input errors, it should be left to whoever
6924 > inputs the wrong commands to refrain from
6927 > As for buggy server software (are you running
6928 > Unreal? =P), bugs should be fixed on the server's
6929 > side, not on the services' if they do their job.
6932 > ------------------------------------------------------------------
6933 > To unsubscribe or change your subscription options, visit:
6934 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6936 From brain at brainbox.winbot.co.uk Mon Mar 24 11:51:11 2003
6937 From: brain at brainbox.winbot.co.uk (Craig Edwards)
6938 Date: Sat Oct 23 23:09:51 2004
6939 Subject: [IRCServices Coding] session limit bug
6940 Message-ID: <200303241951.h2OJpKV13038@localhost.localdomain>
6942 Im sure there will be pleanty of room for bugs when i throw my own custom server software into the mix ;-) Not to mention that if i can get away with it the socket code for that will be within the protocol module for ircservices, which andy probably wont like but oh well, hes not forced to ship our module with the official release of ircservices :-)
6943 But yes, we do use unreal right now... and we havent had a desync for many a version, it seemed to be the early ircservices 5 pre-releases that caused them (plus "out of resources" style errors) and andy has fixed all of these now as far as i can tell.
6945 >It was 06:14 PM 3/24/2003 +0000 when Craig Edwards came up
6947 >>Is there a way to keep services in sync if its desynced, by
6948 >>resyncing it at fixed intervals? This would not only fix
6949 >>problems caused by (ab)use of operserv raw, but would also fix
6950 >>problems caused in other ways (ive had a couple of desyncs
6951 >>before caused by buggy server software etc) - it could be set
6952 >>from config to say resync once every 24h or once every week or
6953 >>whenever the admin prefers, by simulating a form of "warm
6954 >>reboot" where it could somehow retrieve all network
6955 >>information again from the uplink and redo its lists from
6956 >>scratch, kinda like a rehash.... or maybe do this on /os
6957 >>rehash if a commandline option is given? Just an idea...
6959 >Not if the ircd doesn't support it, and as far
6960 >as I know none does (certainly not Bahamut,
6961 >any version), unless you squit and reconnect.
6963 >And besides, use of the RAW command is not
6964 >recommended for the very reason it can lead
6965 >to desynchs, and IMHO any services should not
6966 >waste time/cpu/memory/whatever to try and
6967 >fix input errors, it should be left to whoever
6968 >inputs the wrong commands to refrain from
6971 >As for buggy server software (are you running
6972 >Unreal? =P), bugs should be fixed on the server's
6973 >side, not on the services' if they do their job.
6976 >------------------------------------------------------------------
6977 >To unsubscribe or change your subscription options, visit:
6978 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6981 From griever at t2n.org Tue Mar 25 13:00:32 2003
6982 From: griever at t2n.org (Finny Merrill)
6983 Date: Sat Oct 23 23:09:51 2004
6984 Subject: Top posting (was Re: [IRCServices Coding] session limit bug)
6985 In-Reply-To: <3e7ea15d.03457@mail.achurch.org>
6986 References: <3e7ea15d.03457@mail.achurch.org>
6987 Message-ID: <oprmlza6r23wwnu9@mail-hub.optonline.net>
6989 On Mon, 24 Mar 2003 15:05:51 JST, Andrew Church <achurch@achurch.org>
6994 > I've refrained from mentioning this until now, but (as should be
6995 > obvious from my own messages) top posting is perfectly fine on _this_
6996 > mailing list, regardless of what RFC 1855 has to say on the matter.
6997 > Period, end of discussion. Don't bring this up again.
7001 just kidding, don't hurt me
7002 From v13 at it.teithe.gr Wed Mar 26 07:46:04 2003
7003 From: v13 at it.teithe.gr (V13)
7004 Date: Sat Oct 23 23:09:51 2004
7005 Subject: AW: [IRCServices Coding] session limit bug
7006 In-Reply-To: <000301c2f232$56b8bf70$4dbbf683@globi>
7007 References: <000301c2f232$56b8bf70$4dbbf683@globi>
7008 Message-ID: <200303261746.05152.v13@it.teithe.gr>
7010 On Monday 24 March 2003 20:22, Georges Berscheid wrote:
7013 > the requested command exists: /os restart
7014 > How do you think services could possibly make the uplink send all the
7015 > information again, as if services just joined the network? This
7016 > 'simulated-net-merge-situation' would have to be supported by the
7019 I know that this is complicated but if services could squit and reconnect
7020 themselves without restarting would be great. This whould prevent all kind of
7021 notices they send to users and they will not require users to identify
7022 themselves or reset modes to channels etc...
7024 This can be almost transparent to the entire network.
7029 From georges at berscheid.lu Wed Mar 26 08:22:59 2003
7030 From: georges at berscheid.lu (Georges Berscheid)
7031 Date: Sat Oct 23 23:09:51 2004
7032 Subject: AW: [IRCServices Coding] session limit bug
7033 References: <000301c2f232$56b8bf70$4dbbf683@globi>
7034 <200303261746.05152.v13@it.teithe.gr>
7035 Message-ID: <3E81D3E3.2040106@berscheid.lu>
7037 If you want to resynchronize services (which was the starting point of
7038 this discussion, as far as I remember), you will have to flush services
7039 databases kept in memory, before synchronizing, to make sure you really
7040 get to exactly the same state as your uplink server.
7041 But, this means you lose all information you had so far. (E.g. you must
7042 clear channel modes on resynchronization, because you assume you don't
7043 know the correct ones, and refetch them from your uplink server.)
7044 I'll stop the discussion at this point, because IMO it's really the
7045 wrong approach to handle this problem.
7053 >On Monday 24 March 2003 20:22, Georges Berscheid wrote:
7058 >>the requested command exists: /os restart
7059 >>How do you think services could possibly make the uplink send all the
7060 >>information again, as if services just joined the network? This
7061 >>'simulated-net-merge-situation' would have to be supported by the
7066 >I know that this is complicated but if services could squit and reconnect
7067 >themselves without restarting would be great. This whould prevent all kind of
7068 >notices they send to users and they will not require users to identify
7069 >themselves or reset modes to channels etc...
7071 >This can be almost transparent to the entire network.
7087 From achurch at achurch.org Thu Mar 27 08:51:59 2003
7088 From: achurch at achurch.org (Andrew Church)
7089 Date: Sat Oct 23 23:09:51 2004
7090 Subject: AW: [IRCServices Coding] session limit bug
7091 In-Reply-To: <200303261746.05152.v13@it.teithe.gr>
7092 Message-ID: <3e823f1c.14063@mail.achurch.org>
7094 There seems to be a lot of (mis)information floating around, so let me
7097 - There is NO WAY to resynchronize a desynched server, Services
7098 included, without disconnecting, throwing away all old information, and
7099 reconnecting. In the case of Services, that means that logon news messages
7100 get sent again, channel modes get reset, etc. Whether the program restarts
7101 itself or not is completely irrelevant to this.
7103 - Services is, on the other hand, already capable of recognizing users
7104 who have identified for their nicknames across a restart (unless you
7105 uncommented NoSplitRecovery in ircservices.conf).
7111 >On Monday 24 March 2003 20:22, Georges Berscheid wrote:
7114 >> the requested command exists: /os restart
7115 >> How do you think services could possibly make the uplink send all the
7116 >> information again, as if services just joined the network? This
7117 >> 'simulated-net-merge-situation' would have to be supported by the
7120 >I know that this is complicated but if services could squit and reconnect
7121 >themselves without restarting would be great. This whould prevent all kind of
7122 >notices they send to users and they will not require users to identify
7123 >themselves or reset modes to channels etc...
7125 >This can be almost transparent to the entire network.
7130 >------------------------------------------------------------------
7131 >To unsubscribe or change your subscription options, visit:
7132 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
7133 From diego at redesul.net Tue Apr 1 22:41:25 2003
7134 From: diego at redesul.net (diego@redesul.net)
7135 Date: Sat Oct 23 23:09:51 2004
7136 Subject: [IRCServices Coding] HELP!!!
7137 Message-ID: <20030402064125.4540.qmail@mail.interpira.com.br>
7139 I have some bug similar to this....
7140 I run ircservices 5.0.9 on a network with 30 registers....
7141 It run right, but sometimes i have 2 bugs
7142 the first, is that it enter on __select(), problably some loop and stops, than i have this message:
7143 [Apr 02 16:34:30 2003] sockets: flush_write_buffer(0): Broken pipe
7144 [Apr 02 16:34:30 2003] sockets: flush_write_buffer(0): Broken pipe
7145 [Apr 02 16:34:30 2003] sockets: flush_write_buffer(0): Broken pipe
7146 [Apr 02 16:34:30 2003] sockets: flush_write_buffer(0): Broken pipe
7147 [Apr 02 16:34:30 2003] unknown message from server (ERROR :Closing Link: 0.0.0.0
7149 [Apr 02 16:34:30 2003] sockets: flush_write_buffer(0): Broken pipe
7150 [Apr 02 16:34:30 2003] sockets: flush_write_buffer(0): Broken pipe
7151 [Apr 02 16:34:30 2003] sockets: flush_write_buffer(0): Broken pipe
7153 other bug, is when its restarting (and have lot of ppl on the same time on internet, and its somme lagged (seconds), than happen that bug with introducing user loop(), exiting...
7155 im running it with bahamut.. i compiled it TO BAHAMUT! ;-)
7156 if someone can help me... please, send me a mail
7157 and send too how to subscribe on this mail-list, will help a lot
7162 Diego Bitencourt Contezini aka destruct_ @ irc.redesul.net
7164 From monolith at orblivion.com Thu Apr 3 17:53:11 2003
7165 From: monolith at orblivion.com (monolith)
7166 Date: Sat Oct 23 23:09:51 2004
7167 Subject: [IRCServices Coding] HELP!!!
7168 In-Reply-To: <20030402064125.4540.qmail@mail.interpira.com.br>
7169 Message-ID: <000801c2fa4c$f2ae8fa0$6401a8c0@quasar>
7171 Get a newer version.
7175 -----Original Message-----
7176 From: ircservices-coding-bounces@ircservices.za.net
7177 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of
7179 Sent: Wednesday, April 02, 2003 12:41 AM
7180 To: ircservices-coding@ircservices.za.net
7181 Subject: [IRCServices Coding] HELP!!!
7183 I have some bug similar to this....
7184 I run ircservices 5.0.9 on a network with 30 registers....
7185 It run right, but sometimes i have 2 bugs
7186 the first, is that it enter on __select(), problably some loop and stops,
7187 than i have this message:
7188 [Apr 02 16:34:30 2003] sockets: flush_write_buffer(0): Broken pipe
7189 [Apr 02 16:34:30 2003] sockets: flush_write_buffer(0): Broken pipe
7190 [Apr 02 16:34:30 2003] sockets: flush_write_buffer(0): Broken pipe
7191 [Apr 02 16:34:30 2003] sockets: flush_write_buffer(0): Broken pipe
7192 [Apr 02 16:34:30 2003] unknown message from server (ERROR :Closing Link:
7195 [Apr 02 16:34:30 2003] sockets: flush_write_buffer(0): Broken pipe
7196 [Apr 02 16:34:30 2003] sockets: flush_write_buffer(0): Broken pipe
7197 [Apr 02 16:34:30 2003] sockets: flush_write_buffer(0): Broken pipe
7199 other bug, is when its restarting (and have lot of ppl on the same time on
7200 internet, and its somme lagged (seconds), than happen that bug with
7201 introducing user loop(), exiting...
7203 im running it with bahamut.. i compiled it TO BAHAMUT! ;-)
7204 if someone can help me... please, send me a mail
7205 and send too how to subscribe on this mail-list, will help a lot
7210 Diego Bitencourt Contezini aka destruct_ @ irc.redesul.net
7212 ------------------------------------------------------------------
7213 To unsubscribe or change your subscription options, visit:
7214 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
7216 From laser at musichat.net Fri Apr 4 10:15:05 2003
7217 From: laser at musichat.net (Ciappei Alessandro (las3r))
7218 Date: Sat Oct 23 23:09:51 2004
7219 Subject: [IRCServices Coding] gcc
7220 In-Reply-To: <20030404100006.40B4B1754A@snow.fingers.co.za>
7221 Message-ID: <5.2.0.9.2.20030404201337.03368b88@mail.musichat.net>
7225 I've a problem, all my server runs gcc 2.9.6 on redhat 7.3, and i can't
7226 compile services 5.0.14
7227 Some one can help me?
7232 From dylanvdm at icon.co.za Fri Apr 4 11:12:31 2003
7233 From: dylanvdm at icon.co.za (Dylan v.d Merwe)
7234 Date: Sat Oct 23 23:09:51 2004
7235 Subject: [IRCServices Coding] gcc
7236 References: <5.2.0.9.2.20030404201337.03368b88@mail.musichat.net>
7237 Message-ID: <001601c2fade$264ab870$0100a8c0@dylan>
7239 This is a question which should go unanswered as you are provided with all
7240 the info you need to deduct what's wrong. Let me help you, and everyone else
7243 Briefly gcc 2.96 is an unofficial release of the gcc compiler and
7244 ircservices does not work on it. To get them to work either upgrade to gcc
7245 3.x or downgrade to 2.95.3.
7247 There is a work around though. Though I really do recommend that you upgrade
7248 or downgrade your compiler because if you follow the workaround we will
7249 *not* help you with any problems you may experience.
7251 Okay so now you have the latest version under your belt. You have done
7252 ./configure and you are given this message:
7256 Your system seems to have gcc 2.96 installed.
7257 This is an unofficial release of the GCC compiler which
7258 contains serious bugs and cannot compile Services correctly.
7260 Please upgrade GCC to a newer version, or downgrade to
7261 version 2.95.3, before compiling Services.
7263 See question B.1 in the FAQ for details.
7266 To save you the time of checking up in the FAQ, read below.
7268 B.1. When I run "make", I get an error message like "missing separator",
7269 "Need an operator", "Unexpected end of line seen", etc.
7271 Your make program isn't compatible with the Makefile for Services.
7272 The Makefile was designed to work with GNU make, and as such may
7273 not work on other systems' "make" programs. If you get an error
7274 from "make", obtain GNU make from ftp://prep.ai.mit.edu/pub/gnu/
7275 (or wherever you prefer) and use it instead of your system's
7276 default "make". Note that GNU make may already be installed on
7277 your system; try using the command "gmake" instead of "make".
7279 The make programs bundled with SunOS/Solaris and FreeBSD have been
7280 reported not to work; you will need to use GNU make on these
7284 Right now that you know what you're getting yourself into, lets make
7285 services work with gcc 2.96. Remember that if you do this we will not
7286 provide any assistance to you.
7288 Run the ./configure script with the following suffix:
7290 ./configure -force-gcc-2.96
7292 This will bypass the gcc 2.96 check and you can carry on with setting up
7293 your services. Again this is not recommended and is unsupported, though I do
7299 ----- Original Message -----
7300 From: "Ciappei Alessandro (las3r)" <laser@musichat.net>
7301 To: <ircservices-coding@ircservices.za.net>
7302 Sent: Friday, April 04, 2003 8:15 PM
7303 Subject: [IRCServices Coding] gcc
7308 > I've a problem, all my server runs gcc 2.9.6 on redhat 7.3, and i can't
7309 > compile services 5.0.14
7310 > Some one can help me?
7315 > ------------------------------------------------------------------
7316 > To unsubscribe or change your subscription options, visit:
7317 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
7319 From achurch at achurch.org Sat Apr 5 09:37:42 2003
7320 From: achurch at achurch.org (Andrew Church)
7321 Date: Sat Oct 23 23:09:51 2004
7322 Subject: [IRCServices Coding] gcc
7323 In-Reply-To: <001601c2fade$264ab870$0100a8c0@dylan>
7324 Message-ID: <3e8e25b0.20661@mail.achurch.org>
7326 >To save you the time of checking up in the FAQ, read below.
7328 >B.1. When I run "make", I get an error message like "missing separator",
7329 > "Need an operator", "Unexpected end of line seen", etc.
7331 Just for the record, this is B.2. B.1 reads as follows:
7333 B.1. Red Hat says GCC 2.96 doesn't have bugs anymore [www.redhat.com]. Why
7334 don't you allow it to be used with Services?
7336 Because, as Red Hat themselves admit (and just about anyone
7337 involved in Linux development can tell you), some releases of
7338 GCC 2.96 did have serious bugs in them, and I have personally
7339 verified that at least some releases of 2.96 fail to compile
7340 Services correctly. Since Red Hat, in one of their many stupid
7341 decisions, chose not to change the version string in the fixed
7342 releases, I have no way to tell whether a given release of GCC
7343 2.96 is a "fixed" one or not. Rather than have to wade through
7344 assembly listings for every case of a bad GCC release, I've
7345 chosen to disallow the use of GCC 2.96 entirely. The previous
7346 version of GCC, 2.95.3, is known to work correctly with
7347 Services, as are more recent versions (3.2 in particular);
7348 either downgrade or upgrade before compiling Services, or
7349 install from a binary distribution instead of the source code.
7351 If you absolutely must compile Services using GCC 2.96, you can
7352 override the configure check with the -force-gcc-2.96 option.
7353 However, the author will not provide support for any problems
7354 which occur if you override this check.
7356 Incidentally, Services is believed to not have any of the
7357 programming bugs Red Hat discusses on the page referenced
7358 above. The one exception is pointer aliasing optimization (the
7359 "int i; *(float *)&i = 2.0;" example), which is a bug in the C
7360 standard, and is disabled when compiling Services anyway.
7365 From achurch at achurch.org Sun Apr 6 23:16:27 2003
7366 From: achurch at achurch.org (Andrew Church)
7367 Date: Sat Oct 23 23:09:51 2004
7368 Subject: [IRCServices Coding] Re: [IRCServices] channel KICK - Callback
7369 In-Reply-To: <000401c2fa8b$b0abea50$4dbbf683@globi>
7370 Message-ID: <3e9036f8.01376@mail.achurch.org>
7372 (Moved to the coding list--please keep technical discussion off of the main
7375 >I'm trying to use the 'channel KICK' core callback but I don't know how
7376 >to find out both the user that kicked and the user that has been kicked.
7377 >Any help available on this ?
7379 The user that sent the KICK is not currently sent to the callback.
7380 I'll see about changing this at some point.
7385 From georges at berscheid.lu Mon Apr 7 10:51:09 2003
7386 From: georges at berscheid.lu (Georges Berscheid)
7387 Date: Sat Oct 23 23:09:51 2004
7388 Subject: AW: [IRCServices Coding] Re: [IRCServices] channel KICK - Callback
7389 In-Reply-To: <3e9036f8.01376@mail.achurch.org>
7390 Message-ID: <000401c2fd2e$4562a1d0$4dbbf683@globi>
7394 ok, I added this parameter to the callback myself. Just wanted to make
7395 sure it's not already there and I was too blind to see it.
7400 P.S. Sorry for having posted to the wrong list :-/
7402 -----Urspr?ngliche Nachricht-----
7403 Von: ircservices-coding-bounces@ircservices.za.net
7404 [mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
7406 Gesendet: Sonntag, 6. April 2003 16:16
7407 An: ircservices-coding@ircservices.za.net
7408 Cc: georges@berscheid.lu
7409 Betreff: [IRCServices Coding] Re: [IRCServices] channel KICK - Callback
7412 (Moved to the coding list--please keep technical discussion off of the
7416 >I'm trying to use the 'channel KICK' core callback but I don't know how
7417 >to find out both the user that kicked and the user that has been
7419 >Any help available on this ?
7421 The user that sent the KICK is not currently sent to the callback.
7422 I'll see about changing this at some point.
7427 ------------------------------------------------------------------
7428 To unsubscribe or change your subscription options, visit:
7429 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
7432 From rayfordp at mhonline.net Mon Apr 7 11:08:40 2003
7433 From: rayfordp at mhonline.net (Rayford Pomeroy)
7434 Date: Sat Oct 23 23:09:51 2004
7435 Subject: [IRCServices Coding] SQL
7436 Message-ID: <JBELJOOEGDOHPGPENBHJKEBOCAAA.rayfordp@mhonline.net>
7438 I realize that SQL support is planned but I was wondering if anyone has
7439 successfully modified their own copy of services to use SQL or if anyone has
7440 started to do it. If so could you send me what you have so far? I would like
7441 to mess around with it, if I happen to get something to actually function
7442 (doubtful as my C skills are a joke) I would gladly release it to all. So
7443 please send me anything you have regarding the implementation of SQL into
7448 From georges at berscheid.lu Mon Apr 7 12:03:51 2003
7449 From: georges at berscheid.lu (Georges Berscheid)
7450 Date: Sat Oct 23 23:09:51 2004
7451 Subject: AW: [IRCServices Coding] SQL
7452 In-Reply-To: <JBELJOOEGDOHPGPENBHJKEBOCAAA.rayfordp@mhonline.net>
7453 Message-ID: <000501c2fd38$6d7ade80$4dbbf683@globi>
7457 we are using a modified partially MySQL-capable version of ircservices.
7458 The source files are at
7459 http://www.luxusbuerg.lu/data/ircservices-luxusbuerg.tgz. The needed
7460 database-layout files are at http://www.luxusbuerg.lu/data/sql.tgz.
7461 Please note that these modules are *really* badly documented (as they
7462 were not supposed to be used by anyone else than us), plus I am not
7463 willing to provide any support for these modules.
7464 You will also have to set up some paths... but you'll find out :)
7466 These are the directives for modules.conf:
7469 MySQLConfig Hostname Port Usename Password Database
7471 Module seenserv/main
7472 SeenServName SeenServ "Seen Service"
7475 AdServName AdServ "Advertisement Service"
7477 Module quizserv/main
7478 QuizServName QuizServ "Luxusbuerg Quiz Service"
7481 LogServName LogServ "Channel Logging Service"
7489 -----Urspr?ngliche Nachricht-----
7490 Von: ircservices-coding-bounces@ircservices.za.net
7491 [mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
7493 Gesendet: Montag, 7. April 2003 20:09
7494 An: ircservices-coding@ircservices.za.net
7495 Betreff: [IRCServices Coding] SQL
7498 I realize that SQL support is planned but I was wondering if anyone has
7499 successfully modified their own copy of services to use SQL or if anyone
7501 started to do it. If so could you send me what you have so far? I would
7503 to mess around with it, if I happen to get something to actually
7505 (doubtful as my C skills are a joke) I would gladly release it to all.
7507 please send me anything you have regarding the implementation of SQL
7513 ------------------------------------------------------------------
7514 To unsubscribe or change your subscription options, visit:
7515 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
7518 From diego at redesul.net Tue Apr 8 06:03:14 2003
7519 From: diego at redesul.net (Diego Bitencourt Contezini)
7520 Date: Sat Oct 23 23:09:51 2004
7521 Subject: [IRCServices Coding] XML/ ircservices4db
7522 Message-ID: <003b01c2fdcf$38341470$4506000a@dauphin.com.br>
7524 Have some converser from ircservices4db to xml?
7525 That convert on tools just convert from other types of services...
7527 Someone coded it, or have some idea about how to do it?
7529 Diego B. Contezini aka destruct_
7530 -------------- next part --------------
7531 An HTML attachment was scrubbed...
7532 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030408/5171344a/attachment.htm
7533 From georges at berscheid.lu Tue Apr 8 06:30:55 2003
7534 From: georges at berscheid.lu (Georges Berscheid)
7535 Date: Sat Oct 23 23:09:51 2004
7536 Subject: [IRCServices Coding] XML/ ircservices4db
7537 References: <003b01c2fdcf$38341470$4506000a@dauphin.com.br>
7538 Message-ID: <3E92CF0F.5060800@berscheid.lu>
7542 import your ircservices 4 databases into ircservices 5, and use the
7543 included xml export .
7549 Diego Bitencourt Contezini wrote:
7551 > Have some converser from ircservices4db to xml?
7553 > That convert on tools just convert from other types of services?..
7555 > Someone coded it, or have some idea about how to do it?
7557 > Diego B. Contezini aka destruct_
7559 >------------------------------------------------------------------------
7561 >------------------------------------------------------------------
7562 >To unsubscribe or change your subscription options, visit:
7563 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
7569 From laser at musichat.net Thu Apr 10 01:16:22 2003
7570 From: laser at musichat.net (Ciappei Alessandro (las3r))
7571 Date: Sat Oct 23 23:09:51 2004
7572 Subject: [IRCServices Coding] Mail problem
7573 Message-ID: <5.2.0.9.2.20030410101309.0341d090@mail.musichat.net>
7577 I would like change a template of AUTH mail and other.
7578 I chenge it in my language file for test, but services crash when i would
7579 like register a new nick.
7581 I write a long mail template, where I describe my network and services.
7584 Sorry for my english
7589 -----------------------------------------------------------------------------
7590 Chi riceve il presente messaggio e` tenuto a verificare se lo stesso non gli
7591 sia pervenuto per errore. In tal caso e` pregato di avvisare immediatamente
7592 il mittente e, tenuto conto delle responsabilita` connesse all'indebito
7593 utilizzo e/o divulgazione del messaggio e/o delle informazioni in esso
7594 contenute, voglia cancellare l'originale e distruggere le varie copie o
7597 The receiver of this message is required to check if he/she has received it
7598 erroneously. If so, the receiver is requested to immediately inform the
7599 sender and - in consideration of the responsibilities arising from undue use
7600 and/or disclosure of the message and/or the information contained therein -
7601 destroy the original message and any copy or printout thereof.
7602 -----------------------------------------------------------------------------
7605 From georges at berscheid.lu Thu Apr 10 01:31:01 2003
7606 From: georges at berscheid.lu (Georges Berscheid)
7607 Date: Sat Oct 23 23:09:51 2004
7608 Subject: AW: [IRCServices Coding] Mail problem
7609 In-Reply-To: <5.2.0.9.2.20030410101309.0341d090@mail.musichat.net>
7610 Message-ID: <000101c2ff3b$85b61050$4dbbf683@globi>
7614 if you change language files you need to watch (at least) 2 important
7616 1. you MUST respect the format of language files (each identifier starts
7617 with a capital letter at the very first columns of the line, subsequent
7618 text lines referenced by this identifier must start with a tab (\t)
7619 char. the end of the text and the next identifier is delimited by
7620 exactly one newline (\n).
7621 2. You MUST respect the order of parameters (%s, %d etc.) as it was in
7622 the original text. Changing the order might cause services to crash.
7629 -----Urspr?ngliche Nachricht-----
7630 Von: ircservices-coding-bounces@ircservices.za.net
7631 [mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
7632 Ciappei Alessandro (las3r)
7633 Gesendet: Donnerstag, 10. April 2003 10:16
7634 An: ircservices-coding@ircservices.za.net
7635 Betreff: [IRCServices Coding] Mail problem
7640 I would like change a template of AUTH mail and other.
7641 I chenge it in my language file for test, but services crash when i
7643 like register a new nick.
7645 I write a long mail template, where I describe my network and services.
7648 Sorry for my english
7653 ------------------------------------------------------------------------
7655 Chi riceve il presente messaggio e` tenuto a verificare se lo stesso
7657 sia pervenuto per errore. In tal caso e` pregato di avvisare
7659 il mittente e, tenuto conto delle responsabilita` connesse
7661 utilizzo e/o divulgazione del messaggio e/o delle informazioni in
7663 contenute, voglia cancellare l'originale e distruggere le varie
7667 The receiver of this message is required to check if he/she has
7669 erroneously. If so, the receiver is requested to immediately
7671 sender and - in consideration of the responsibilities arising from
7673 and/or disclosure of the message and/or the information contained
7675 destroy the original message and any copy or printout thereof.
7676 ------------------------------------------------------------------------
7680 ------------------------------------------------------------------
7681 To unsubscribe or change your subscription options, visit:
7682 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
7685 From laser at musichat.net Thu Apr 10 03:30:35 2003
7686 From: laser at musichat.net (Ciappei Alessandro (las3r))
7687 Date: Sat Oct 23 23:09:51 2004
7688 Subject: [IRCServices Coding] Re: IRCServices-Coding Digest, Vol 3, Issue 6
7689 In-Reply-To: <20030410100008.3837A174F0@snow.fingers.co.za>
7690 Message-ID: <5.2.0.9.2.20030410122956.0358bf78@mail.musichat.net>
7692 I respect all things, but my mail is long i think
7698 At 12.00 10/04/2003 +0200, you wrote:
7699 >respect the order of parameters (%s, %d etc.) as it was in
7700 >the original text. Changing the order might cause services to crash.
7703 -----------------------------------------------------------------------------
7704 Chi riceve il presente messaggio e` tenuto a verificare se lo stesso non gli
7705 sia pervenuto per errore. In tal caso e` pregato di avvisare immediatamente
7706 il mittente e, tenuto conto delle responsabilita` connesse all'indebito
7707 utilizzo e/o divulgazione del messaggio e/o delle informazioni in esso
7708 contenute, voglia cancellare l'originale e distruggere le varie copie o
7711 The receiver of this message is required to check if he/she has received it
7712 erroneously. If so, the receiver is requested to immediately inform the
7713 sender and - in consideration of the responsibilities arising from undue use
7714 and/or disclosure of the message and/or the information contained therein -
7715 destroy the original message and any copy or printout thereof.
7716 -----------------------------------------------------------------------------
7719 From waterflamez at hotmail.com Fri Apr 11 16:37:04 2003
7720 From: waterflamez at hotmail.com (Jack Neils)
7721 Date: Sat Oct 23 23:09:51 2004
7722 Subject: [IRCServices Coding] Services joining a channel
7723 Message-ID: <F92FVlq0ZOVKkF5GKdX0001d004@hotmail.com>
7725 Is it possible to have all services (operserv, nickserv, memoserv, helpserv,
7726 statserv, chanserv) join a channel ?
7728 they don't really have to report anything to the channel, just sit there so
7729 i can check if they are all working (though reporting some minimal info
7738 _________________________________________________________________
7741 From waterflamez at hotmail.com Fri Apr 11 16:52:12 2003
7742 From: waterflamez at hotmail.com (Jack Neils)
7743 Date: Sat Oct 23 23:09:51 2004
7744 Subject: [IRCServices Coding] Services joining a channel
7745 Message-ID: <F81Xez2NoKMHG0eg3er00004078@hotmail.com>
7747 Sorry for taking up space on the list, i found the answer :)
7748 maybe in the feature there could be a feature added to have them join a
7749 channel on startup ?
7750 (and possibly report things)
7755 >From: "Jack Neils" <waterflamez@hotmail.com>
7756 >Reply-To: IRC Services Coding Mailing List
7757 ><ircservices-coding@ircservices.za.net>
7758 >To: ircservices-coding@ircservices.za.net
7759 >Subject: [IRCServices Coding] Services joining a channel
7760 >Date: Sat, 12 Apr 2003 01:37:04 +0200
7762 >Is it possible to have all services (operserv, nickserv, memoserv,
7763 >helpserv, statserv, chanserv) join a channel ?
7765 >they don't really have to report anything to the channel, just sit there so
7766 >i can check if they are all working (though reporting some minimal info
7775 >_________________________________________________________________
7778 >------------------------------------------------------------------
7779 >To unsubscribe or change your subscription options, visit:
7780 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
7783 _________________________________________________________________
7784 Chat with your online buddies with MSN Messenger http://messenger.msn.be
7786 From laser at musichat.net Sun Apr 13 14:03:37 2003
7787 From: laser at musichat.net (Ciappei Alessandro (las3r))
7788 Date: Sat Oct 23 23:09:51 2004
7789 Subject: [IRCServices Coding] Mail from services
7790 Message-ID: <5.2.0.9.2.20030413225918.02ddde10@mail.musichat.net>
7794 I resolve a previous problem with crash of services.
7795 But now i ask how i can separate lines in auth mail?
7796 Because servces send auth mail and other mail without a separate lines.
7801 Your code is: 168724492
7811 Your code is: 168724492
7824 -----------------------------------------------------------------------------
7825 Chi riceve il presente messaggio e` tenuto a verificare se lo stesso non gli
7826 sia pervenuto per errore. In tal caso e` pregato di avvisare immediatamente
7827 il mittente e, tenuto conto delle responsabilita` connesse all'indebito
7828 utilizzo e/o divulgazione del messaggio e/o delle informazioni in esso
7829 contenute, voglia cancellare l'originale e distruggere le varie copie o
7832 The receiver of this message is required to check if he/she has received it
7833 erroneously. If so, the receiver is requested to immediately inform the
7834 sender and - in consideration of the responsibilities arising from undue use
7835 and/or disclosure of the message and/or the information contained therein -
7836 destroy the original message and any copy or printout thereof.
7837 -----------------------------------------------------------------------------
7840 From waterflamez at hotmail.com Sun Apr 13 14:29:09 2003
7841 From: waterflamez at hotmail.com (Jack Neils)
7842 Date: Sat Oct 23 23:09:51 2004
7843 Subject: [IRCServices Coding] join channel on register
7844 Message-ID: <F113warf3nMx5AONLfw0001ecf2@hotmail.com>
7848 I've got this PHP bot, B.
7849 Now when i register a channel with services, could i get services to send a
7850 command to B so he'd join a channel?
7852 example; if i register #test the command to B would be /msg B B join #test
7854 and ofcourse when dropping a channel, B would have to leave this channel.
7856 example; dropping #test => /msg B B part #test
7858 anyone that can give me a push in the right direction?
7866 _________________________________________________________________
7867 MSN Search, for relevant search results! http://search.msn.be
7869 From brain at brainbox.winbot.co.uk Tue Apr 22 08:24:03 2003
7870 From: brain at brainbox.winbot.co.uk (Craig Edwards)
7871 Date: Sat Oct 23 23:09:51 2004
7872 Subject: [IRCServices Coding]
7873 Associating NickGroupInfo with two nicks at once
7874 Message-ID: <200304221424.h3MEO4A24908@localhost.localdomain>
7876 Hi, we're writing a module which allows a web interface to "su" to a nickname, similar to the way the unix "su" command (dont ask! :)) heres how it works:
7878 basically, /msg somepseudoclient su <nick> <pass>
7880 ..and you gain the privilages of that nick, wether or not they are using it at the time. What we're doing at the moment is associating the user's ngi and ni fields with the nickgroupinfo of the registered nickname, e.g.
7882 NickInfo* MyNickInf = get_nickinfo(somenick);
7883 NickGroupInfo* MyNGroupInf = get_ngi(MyNickInf);
7885 u->ngi = MyNGroupInf;
7887 /* user u is now logged in with privilages of "ngi" nick, send +r as a raw if neccessary */
7889 sorry for any errors in this code, im typing it off the top of my head.
7890 Basically, the problem we have is, that only one nick can have "ownership" of a groupinfo at any one time, if we associate user 'u' with MyNGroupInf, then if some other user online at the time (lets call them u2) has this same association (u2->ngi == MyNGroupInf) than u2 is logged out (and has to re-identify using /msg nickserv identify <pass>). Basically we cant give two people ownership of the same nickgroup at the same time. Is there any way we can get around this, e.g. by memcpy'ing the NickGroupInfo? The ownership of the nick by the second user only needs to be temporary, until disconnect, so there shouldnt be any corruption of services DB's by having two people pointing at the same nickgroup in the file, or anything as weird as that :)
7892 If theres any way to solve this problem simply, without needing andy to rewrite the core, or for us to approach the problem a different way, we'd be grateful of anyone could tell us how :)
7896 ChatSpike Services-dev
7900 From georges at berscheid.lu Tue Apr 22 07:40:25 2003
7901 From: georges at berscheid.lu (Georges Berscheid)
7902 Date: Sat Oct 23 23:09:51 2004
7903 Subject: [IRCServices Coding] Associating NickGroupInfo with two nicks
7905 References: <200304221424.h3MEO4A24908@localhost.localdomain>
7906 Message-ID: <3EA55459.9000200@berscheid.lu>
7910 you might need to add the user that you want to get the privileges of
7911 one NickGroupInfo to the id_users array in that specific struct. This
7912 could help making the user being recognized as owner of the ngi.
7913 Please note that this is a mere speculation, and that it is not based on
7915 Furthermore I don't think you should associate the ni reference to the
7916 user that does a SU, but only the ngi (which contains the privileges
7917 data), since the ni struct has a user member which can only be set to
7918 one specific user. So you will get in trouble if the real owner of the
7919 nick is online as well when any other use wants to get his privileges
7926 Craig Edwards wrote:
7928 >Hi, we're writing a module which allows a web interface to "su" to a nickname, similar to the way the unix "su" command (dont ask! :)) heres how it works:
7930 >basically, /msg somepseudoclient su <nick> <pass>
7932 >..and you gain the privilages of that nick, wether or not they are using it at the time. What we're doing at the moment is associating the user's ngi and ni fields with the nickgroupinfo of the registered nickname, e.g.
7934 >NickInfo* MyNickInf = get_nickinfo(somenick);
7935 >NickGroupInfo* MyNGroupInf = get_ngi(MyNickInf);
7937 >u->ngi = MyNGroupInf;
7939 >/* user u is now logged in with privilages of "ngi" nick, send +r as a raw if neccessary */
7941 >sorry for any errors in this code, im typing it off the top of my head.
7942 >Basically, the problem we have is, that only one nick can have "ownership" of a groupinfo at any one time, if we associate user 'u' with MyNGroupInf, then if some other user online at the time (lets call them u2) has this same association (u2->ngi == MyNGroupInf) than u2 is logged out (and has to re-identify using /msg nickserv identify <pass>). Basically we cant give two people ownership of the same nickgroup at the same time. Is there any way we can get around this, e.g. by memcpy'ing the NickGroupInfo? The ownership of the nick by the second user only needs to be temporary, until disconnect, so there shouldnt be any corruption of services DB's by having two people pointing at the same nickgroup in the file, or anything as weird as that :)
7944 >If theres any way to solve this problem simply, without needing andy to rewrite the core, or for us to approach the problem a different way, we'd be grateful of anyone could tell us how :)
7948 >ChatSpike Services-dev
7952 >------------------------------------------------------------------
7953 >To unsubscribe or change your subscription options, visit:
7954 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
7962 From achurch at achurch.org Wed Apr 23 10:17:37 2003
7963 From: achurch at achurch.org (Andrew Church)
7964 Date: Sat Oct 23 23:09:51 2004
7965 Subject: [IRCServices Coding] Associating NickGroupInfo with two nicks at
7967 In-Reply-To: <200304221424.h3MEO4A24908@localhost.localdomain>
7968 Message-ID: <3ea5ec02.17430@mail.achurch.org>
7970 The code currently assumes that at most one user will be associated
7971 with any particular nickname, that NickInfo.user will point at the user
7972 with nickname NickInfo.nick, that User.ni will point at the NickInfo with
7973 nickname User.nick (or NULL if the nickname is not registered), and that
7974 User.ngi will point to a nickname group containing User.ni (or NULL or
7975 NICKGROUPINFO_INVALID). Breaking any of these assumptions will probably
7976 cause many weird and dangerous things to happen.
7978 Note that two or more users can be associated with a single nick group
7979 (if, for example, someone has two clients open and using two linked nicks).
7980 However, if the user's nick is not in NickGroupInfo.nicks[], things will
7983 I'd strongly suggest finding another way to accomplish whatever you're
7984 trying to do without an "su"-like command.
7990 >Hi, we're writing a module which allows a web interface to "su" to a nickname, similar to the way the unix "su" command (dont ask! :)) heres how it works:
7992 >basically, /msg somepseudoclient su <nick> <pass>
7994 >..and you gain the privilages of that nick, wether or not they are using it at the time. What we're doing at the moment is associating the user's ngi and ni fields with the nickgroupinfo of the registered nickname, e.g.
7996 >NickInfo* MyNickInf = get_nickinfo(somenick);
7997 >NickGroupInfo* MyNGroupInf = get_ngi(MyNickInf);
7999 >u->ngi = MyNGroupInf;
8001 >/* user u is now logged in with privilages of "ngi" nick, send +r as a raw if neccessary */
8003 >sorry for any errors in this code, im typing it off the top of my head.
8004 >Basically, the problem we have is, that only one nick can have "ownership" of a groupinfo at any one time, if we associate user 'u' with MyNGroupInf, then if some other user online at the time (lets call them u2) has this same association (u2->ngi == MyNG
8005 >roupInf) than u2 is logged out (and has to re-identify using /msg nickserv identify <pass>). Basically we cant give two people ownership of the same nickgroup at the same time. Is there any way we can get around this, e.g. by memcpy'ing the NickGroupInfo?
8006 > The ownership of the nick by the second user only needs to be temporary, until disconnect, so there shouldnt be any corruption of services DB's by having two people pointing at the same nickgroup in the file, or anything as weird as that :)
8008 >If theres any way to solve this problem simply, without needing andy to rewrite the core, or for us to approach the problem a different way, we'd be grateful of anyone could tell us how :)
8012 >ChatSpike Services-dev
8016 >------------------------------------------------------------------
8017 From Craig at chatspike.net Wed Apr 23 23:22:10 2003
8018 From: Craig at chatspike.net (Craig McLure)
8019 Date: Sat Oct 23 23:09:52 2004
8020 Subject: [IRCServices Coding] Associating NickGroupInfo with two
8022 Message-ID: <20030424052202.QLHP12018.mta06-svc.ntlworld.com@i-br0ked-it>
8024 Could you give any other suggestions on how this could be done? I'll go into a few details on what is trying to be accomplished...
8026 For years now, people have been acking for use of MySQL databases, so that they can have "Web Interfaces" to services, basically, we are creating a module that allows this "su" type command, which will allow use of the command from specific hosts to gain information on nicknames, then parse them into HTML, and be able to display on a website.. it would also be allowed to change some settings on the nickname (example, access lists, passwords) without having to talk to the service itself.
8028 Theres an alpha running at http://www.chatspike.net/?page=ircadmin
8029 Currently, you need to have a registered nickname on irc.chatspike.net to use it.. If you wanna try exploiting it in some way.. feel free :p
8031 So yeah, any other solutions would be great :)
8033 -----------------------------------------------------------------------
8034 Craig McLure - Craig@chatspike.net
8035 ChatSpike - The users network: http://www.chatspike.net
8036 InspIRCd - Modular IRC server: http://www.inspircd.org
8037 <`RaSh> how do i install linux i got the cd and i dont see the setup.exe or install.exe
8038 -----------------------------------------------------------------------
8040 ============ Original Message ============
8041 >From : "Andrew Church" <achurch@achurch.org>
8042 >Reply-To : ircservices-coding@ircservices.za.net
8043 >To : ircservices-coding@ircservices.za.net
8044 >Subject : Re: [IRCServices Coding] Associating NickGroupInfo with two nicks atonce
8048 > The code currently assumes that at most one user will be associated
8049 >with any particular nickname, that NickInfo.user will point at the user
8050 >with nickname NickInfo.nick, that User.ni will point at the NickInfo with
8051 >nickname User.nick (or NULL if the nickname is not registered), and that
8052 >User.ngi will point to a nickname group containing User.ni (or NULL or
8053 >NICKGROUPINFO_INVALID). Breaking any of these assumptions will probably
8054 >cause many weird and dangerous things to happen.
8056 > Note that two or more users can be associated with a single nick group
8057 >(if, for example, someone has two clients open and using two linked nicks).
8058 >However, if the user's nick is not in NickGroupInfo.nicks[], things will
8061 > I'd strongly suggest finding another way to accomplish whatever you're
8062 >trying to do without an "su"-like command.
8065 > achurch@achurch.org
8066 > http://achurch.org/
8068 >>Hi, we're writing a module which allows a web interface to "su" to a nickname, similar to the way the unix "su" command (dont ask! :)) heres how it works:
8070 >>basically, /msg somepseudoclient su <nick> <pass>
8072 >>..and you gain the privilages of that nick, wether or not they are using it at the time. What we're doing at the moment is associating the user's ngi and ni fields with the nickgroupinfo of the registered nickname, e.g.
8074 >>NickInfo* MyNickInf = get_nickinfo(somenick);
8075 >>NickGroupInfo* MyNGroupInf = get_ngi(MyNickInf);
8077 >>u->ngi = MyNGroupInf;
8078 >>u->ni = MyNickInf;
8079 >>/* user u is now logged in with privilages of "ngi" nick, send +r as a raw if neccessary */
8081 >>sorry for any errors in this code, im typing it off the top of my head.
8082 >>Basically, the problem we have is, that only one nick can have "ownership" of a groupinfo at any one time, if we associate user 'u' with MyNGroupInf, then if some other user online at the time (lets call them u2) has this same association (u2->ngi == MyNG
8083 >>roupInf) than u2 is logged out (and has to re-identify using /msg nickserv identify <pass>). Basically we cant give two people ownership of the same nickgroup at the same time. Is there any way we can get around this, e.g. by memcpy'ing the NickGroupInfo?
8084 >> The ownership of the nick by the second user only needs to be temporary, until disconnect, so there shouldnt be any corruption of services DB's by having two people pointing at the same nickgroup in the file, or anything as weird as that :)
8086 >>If theres any way to solve this problem simply, without needing andy to rewrite the core, or for us to approach the problem a different way, we'd be grateful of anyone could tell us how :)
8090 >>ChatSpike Services-dev
8094 >>------------------------------------------------------------------
8095 >------------------------------------------------------------------
8096 >To unsubscribe or change your subscription options, visit:
8097 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
8099 ========= End of Original Message =========
8103 From georges at berscheid.lu Thu Apr 24 01:25:17 2003
8104 From: georges at berscheid.lu (Georges Berscheid)
8105 Date: Sat Oct 23 23:09:52 2004
8106 Subject: [IRCServices Coding] Associating NickGroupInfo with two nicks
8108 References: <20030424052202.QLHP12018.mta06-svc.ntlworld.com@i-br0ked-it>
8109 Message-ID: <3EA79F6D.6080504@berscheid.lu>
8113 we disabled all /ns {register|drop|link} etc. commands in services and
8114 force our users to register their nicknames via a web-interface (90% of
8115 our users use a java-web-interface to chat anyway). Services have a
8116 module that connects to the MySQL database and retrieves information
8117 from there, without needing any interaction of bots with services.
8118 To retrieve services-internal information, we use http-modules which
8119 output simple PHP-scripts that can be included using <?php
8120 include("http://your.services.host/moduleurl") ?> Again, you won't need
8121 a bot that connects to your network, use any (possibly exploitable)
8122 commands and parse the output.
8130 >Could you give any other suggestions on how this could be done? I'll go into a few details on what is trying to be accomplished...
8132 >For years now, people have been acking for use of MySQL databases, so that they can have "Web Interfaces" to services, basically, we are creating a module that allows this "su" type command, which will allow use of the command from specific hosts to gain information on nicknames, then parse them into HTML, and be able to display on a website.. it would also be allowed to change some settings on the nickname (example, access lists, passwords) without having to talk to the service itself.
8134 >Theres an alpha running at http://www.chatspike.net/?page=ircadmin
8135 >Currently, you need to have a registered nickname on irc.chatspike.net to use it.. If you wanna try exploiting it in some way.. feel free :p
8137 >So yeah, any other solutions would be great :)
8139 >-----------------------------------------------------------------------
8140 >Craig McLure - Craig@chatspike.net
8141 >ChatSpike - The users network: http://www.chatspike.net
8142 >InspIRCd - Modular IRC server: http://www.inspircd.org
8143 ><`RaSh> how do i install linux i got the cd and i dont see the setup.exe or install.exe
8144 >-----------------------------------------------------------------------
8146 >============ Original Message ============
8147 >>From : "Andrew Church" <achurch@achurch.org>
8150 >>Reply-To : ircservices-coding@ircservices.za.net
8151 >>To : ircservices-coding@ircservices.za.net
8152 >>Subject : Re: [IRCServices Coding] Associating NickGroupInfo with two nicks atonce
8156 >> The code currently assumes that at most one user will be associated
8157 >>with any particular nickname, that NickInfo.user will point at the user
8158 >>with nickname NickInfo.nick, that User.ni will point at the NickInfo with
8159 >>nickname User.nick (or NULL if the nickname is not registered), and that
8160 >>User.ngi will point to a nickname group containing User.ni (or NULL or
8161 >>NICKGROUPINFO_INVALID). Breaking any of these assumptions will probably
8162 >>cause many weird and dangerous things to happen.
8164 >> Note that two or more users can be associated with a single nick group
8165 >>(if, for example, someone has two clients open and using two linked nicks).
8166 >>However, if the user's nick is not in NickGroupInfo.nicks[], things will
8169 >> I'd strongly suggest finding another way to accomplish whatever you're
8170 >>trying to do without an "su"-like command.
8173 >> achurch@achurch.org
8174 >> http://achurch.org/
8178 >>>Hi, we're writing a module which allows a web interface to "su" to a nickname, similar to the way the unix "su" command (dont ask! :)) heres how it works:
8180 >>>basically, /msg somepseudoclient su <nick> <pass>
8182 >>>..and you gain the privilages of that nick, wether or not they are using it at the time. What we're doing at the moment is associating the user's ngi and ni fields with the nickgroupinfo of the registered nickname, e.g.
8184 >>>NickInfo* MyNickInf = get_nickinfo(somenick);
8185 >>>NickGroupInfo* MyNGroupInf = get_ngi(MyNickInf);
8187 >>>u->ngi = MyNGroupInf;
8188 >>>u->ni = MyNickInf;
8189 >>>/* user u is now logged in with privilages of "ngi" nick, send +r as a raw if neccessary */
8191 >>>sorry for any errors in this code, im typing it off the top of my head.
8192 >>>Basically, the problem we have is, that only one nick can have "ownership" of a groupinfo at any one time, if we associate user 'u' with MyNGroupInf, then if some other user online at the time (lets call them u2) has this same association (u2->ngi == MyNG
8193 >>>roupInf) than u2 is logged out (and has to re-identify using /msg nickserv identify <pass>). Basically we cant give two people ownership of the same nickgroup at the same time. Is there any way we can get around this, e.g. by memcpy'ing the NickGroupInfo?
8194 >>>The ownership of the nick by the second user only needs to be temporary, until disconnect, so there shouldnt be any corruption of services DB's by having two people pointing at the same nickgroup in the file, or anything as weird as that :)
8196 >>>If theres any way to solve this problem simply, without needing andy to rewrite the core, or for us to approach the problem a different way, we'd be grateful of anyone could tell us how :)
8200 >>>ChatSpike Services-dev
8204 >>>------------------------------------------------------------------
8207 >>------------------------------------------------------------------
8208 >>To unsubscribe or change your subscription options, visit:
8209 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
8213 >========= End of Original Message =========
8217 >------------------------------------------------------------------
8218 >To unsubscribe or change your subscription options, visit:
8219 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
8227 From achurch at achurch.org Thu Apr 24 21:24:57 2003
8228 From: achurch at achurch.org (Andrew Church)
8229 Date: Sat Oct 23 23:09:52 2004
8230 Subject: [IRCServices Coding] Associating NickGroupInfo with two
8232 In-Reply-To: <20030424052202.QLHP12018.mta06-svc.ntlworld.com@i-br0ked-it>
8233 Message-ID: <3ea7d994.01413@mail.achurch.org>
8235 >For years now, people have been acking for use of MySQL databases, so that they can have "Web Interfaces" to services, basically, we are creating a module that allows this "su" type command, which will allow use of the command from specific hosts to gain
8236 >information on nicknames, then parse them into HTML, and be able to display on a website.. it would also be allowed to change some settings on the nickname (example, access lists, passwords) without having to talk to the service itself.
8238 Would an HTTP server module similar to the dbaccess module (but
8239 having additional access checks in place, obviously) work?
8244 From brain at brainbox.winbot.co.uk Fri Apr 25 14:09:51 2003
8245 From: brain at brainbox.winbot.co.uk (Craig Edwards)
8246 Date: Sat Oct 23 23:09:52 2004
8247 Subject: [IRCServices Coding] Associating NickGroupInfo with two
8249 Message-ID: <200304252009.h3PK9pA25637@localhost.localdomain>
8251 Good idea. We're taking the opposite route, only allowing users to register on irc. We believe that on our network, given the option to register on the website would create a whole bunch of pointless never-used nicks that are just used by clueless web users who have no idea what theyre doing with irc ;-)
8253 We're using our service to fetch certain information that is particular to the ircd and not services, e.g. output of /list, etc, so if there was a way to output this too -- i noticed chanserv only keeps a linked list of *registered* channels, which is the reverse of how our modified statserv works :)
8260 >we disabled all /ns {register|drop|link} etc. commands in services and
8261 >force our users to register their nicknames via a web-interface (90 of
8262 >our users use a java-web-interface to chat anyway). Services have a
8263 >module that connects to the MySQL database and retrieves information
8264 >from there, without needing any interaction of bots with services.
8265 >To retrieve services-internal information, we use http-modules which
8266 >output simple PHP-scripts that can be included using <?php
8267 >include("http://your.services.host/moduleurl") ?> Again, you won't need
8268 >a bot that connects to your network, use any (possibly exploitable)
8269 >commands and parse the output.
8275 >Craig McLure wrote:
8277 >>Could you give any other suggestions on how this could be done? I'll go into a few details on what is trying to be accomplished...
8279 >>For years now, people have been acking for use of MySQL databases, so that they can have "Web Interfaces" to services, basically, we are creating a module that allows this "su" type command, which will allow use of the command from specific hosts to gain information on nicknames, then parse them into HTML, and be able to display on a website.. it would also be allowed to change some settings on the nickname (example, access lists, passwords) without having to talk to the service itself.
8281 >>Theres an alpha running at http://www.chatspike.net/?page=ircadmin
8282 >>Currently, you need to have a registered nickname on irc.chatspike.net to use it.. If you wanna try exploiting it in some way.. feel free :p
8284 >>So yeah, any other solutions would be great :)
8286 >>-----------------------------------------------------------------------
8287 >>Craig McLure - Craig@chatspike.net
8288 >>ChatSpike - The users network: http://www.chatspike.net
8289 >>InspIRCd - Modular IRC server: http://www.inspircd.org
8290 >><`RaSh> how do i install linux i got the cd and i dont see the setup.exe or install.exe
8291 >>-----------------------------------------------------------------------
8293 >>============ Original Message ============
8294 >>>From : "Andrew Church" <achurch@achurch.org>
8297 >>>Reply-To : ircservices-coding@ircservices.za.net
8298 >>>To : ircservices-coding@ircservices.za.net
8299 >>>Subject : Re: [IRCServices Coding] Associating NickGroupInfo with two nicks atonce
8300 >>>Date : 2003-04-23
8303 >>> The code currently assumes that at most one user will be associated
8304 >>>with any particular nickname, that NickInfo.user will point at the user
8305 >>>with nickname NickInfo.nick, that User.ni will point at the NickInfo with
8306 >>>nickname User.nick (or NULL if the nickname is not registered), and that
8307 >>>User.ngi will point to a nickname group containing User.ni (or NULL or
8308 >>>NICKGROUPINFO_INVALID). Breaking any of these assumptions will probably
8309 >>>cause many weird and dangerous things to happen.
8311 >>> Note that two or more users can be associated with a single nick group
8312 >>>(if, for example, someone has two clients open and using two linked nicks).
8313 >>>However, if the user's nick is not in NickGroupInfo.nicks[], things will
8316 >>> I'd strongly suggest finding another way to accomplish whatever you're
8317 >>>trying to do without an "su"-like command.
8320 >>> achurch@achurch.org
8321 >>> http://achurch.org/
8325 >>>>Hi, we're writing a module which allows a web interface to "su" to a nickname, similar to the way the unix "su" command (dont ask! :)) heres how it works:
8327 >>>>basically, /msg somepseudoclient su <nick> <pass>
8329 >>>>..and you gain the privilages of that nick, wether or not they are using it at the time. What we're doing at the moment is associating the user's ngi and ni fields with the nickgroupinfo of the registered nickname, e.g.
8331 >>>>NickInfo* MyNickInf = get_nickinfo(somenick);
8332 >>>>NickGroupInfo* MyNGroupInf = get_ngi(MyNickInf);
8334 >>>>u->ngi = MyNGroupInf;
8335 >>>>u->ni = MyNickInf;
8336 >>>>/* user u is now logged in with privilages of "ngi" nick, send +r as a raw if neccessary */
8338 >>>>sorry for any errors in this code, im typing it off the top of my head.
8339 >>>>Basically, the problem we have is, that only one nick can have "ownership" of a groupinfo at any one time, if we associate user 'u' with MyNGroupInf, then if some other user online at the time (lets call them u2) has this same association (u2->ngi == MyNG
8340 >>>>roupInf) than u2 is logged out (and has to re-identify using /msg nickserv identify <pass>). Basically we cant give two people ownership of the same nickgroup at the same time. Is there any way we can get around this, e.g. by memcpy'ing the NickGroupInfo?
8341 >>>>The ownership of the nick by the second user only needs to be temporary, until disconnect, so there shouldnt be any corruption of services DB's by having two people pointing at the same nickgroup in the file, or anything as weird as that :)
8343 >>>>If theres any way to solve this problem simply, without needing andy to rewrite the core, or for us to approach the problem a different way, we'd be grateful of anyone could tell us how :)
8347 >>>>ChatSpike Services-dev
8351 >>>>------------------------------------------------------------------
8354 >>>------------------------------------------------------------------
8355 >>>To unsubscribe or change your subscription options, visit:
8356 >>>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
8360 >>========= End of Original Message =========
8364 >>------------------------------------------------------------------
8365 >>To unsubscribe or change your subscription options, visit:
8366 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
8374 >------------------------------------------------------------------
8375 >To unsubscribe or change your subscription options, visit:
8376 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
8379 From georges at berscheid.lu Sat Apr 26 02:54:37 2003
8380 From: georges at berscheid.lu (Georges Berscheid)
8381 Date: Sat Oct 23 23:09:52 2004
8382 Subject: AW: Re: [IRCServices Coding] Associating NickGroupInfo with
8384 In-Reply-To: <200304252009.h3PK9pA25637@localhost.localdomain>
8385 Message-ID: <000b01c30bd9$dc86b3d0$45c918d4@gizmo>
8389 since services are a almost-regular server linked to your network, they
8390 know all of the network-relevant information, including /list. Just use
8393 for(chan = first_channel(); chan; chan = next_channel()) {
8397 to get a list of all channels. There are similar commands for users,
8398 registered channels, registered nicks etc. Note that chan->users is a
8399 linked list of all users currently in the channel. Refer to channels.h,
8400 users.h, modules/nickserv/nickserv.h and modules/chanserv/chanserv.h for
8401 more information on structs.
8403 I suggest you have a look at
8404 http://www.luxusbuerg.lu/data/ircservices-luxusbuerg.tgz in
8405 modules/httpd/accesslist.c. This is an example of how to dynamically
8406 include the accesslist of all registered channels into a php-script.
8407 Another example is modules/httpd/banlist.c.
8408 modules/nickserv/dbsynch.c shows how we linked services to the mysql
8409 database. This could also be a possibility, to write all information you
8410 need in constant intervals into a mysql table which you can read with
8411 you php script anytime you want. Choose what fits your needs the best
8417 -----Urspr?ngliche Nachricht-----
8418 Von: ircservices-coding-bounces@ircservices.za.net
8419 [mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
8421 Gesendet: Freitag, 25. April 2003 23:01
8422 An: IRC Services Coding Mailing List
8423 Betreff: Re: Re: [IRCServices Coding] Associating NickGroupInfo with
8427 Good idea. We're taking the opposite route, only allowing users to
8428 register on irc. We believe that on our network, given the option to
8429 register on the website would create a whole bunch of pointless
8430 never-used nicks that are just used by clueless web users who have no
8431 idea what theyre doing with irc ;-)
8433 We're using our service to fetch certain information that is particular
8434 to the ircd and not services, e.g. output of /list, etc, so if there was
8435 a way to output this too -- i noticed chanserv only keeps a linked list
8436 of *registered* channels, which is the reverse of how our modified
8444 >we disabled all /ns {register|drop|link} etc. commands in services and
8445 >force our users to register their nicknames via a web-interface (90 of
8446 >our users use a java-web-interface to chat anyway). Services have a
8447 >module that connects to the MySQL database and retrieves information
8448 >from there, without needing any interaction of bots with services.
8449 >To retrieve services-internal information, we use http-modules which
8450 >output simple PHP-scripts that can be included using <?php
8451 >include("http://your.services.host/moduleurl") ?> Again, you won't need
8453 >a bot that connects to your network, use any (possibly exploitable)
8454 >commands and parse the output.
8460 >Craig McLure wrote:
8462 >>Could you give any other suggestions on how this could be done? I'll
8463 go into a few details on what is trying to be accomplished...
8465 >>For years now, people have been acking for use of MySQL databases, so
8466 that they can have "Web Interfaces" to services, basically, we are
8467 creating a module that allows this "su" type command, which will allow
8468 use of the command from specific hosts to gain information on nicknames,
8469 then parse them into HTML, and be able to display on a website.. it
8470 would also be allowed to change some settings on the nickname (example,
8471 access lists, passwords) without having to talk to the service itself.
8473 >>Theres an alpha running at http://www.chatspike.net/?page=ircadmin
8474 >>Currently, you need to have a registered nickname on irc.chatspike.net
8475 to use it.. If you wanna try exploiting it in some way.. feel free :p
8477 >>So yeah, any other solutions would be great :)
8479 >>----------------------------------------------------------------------
8481 >>Craig McLure - Craig@chatspike.net
8482 >>ChatSpike - The users network: http://www.chatspike.net
8483 >>InspIRCd - Modular IRC server: http://www.inspircd.org
8484 >><`RaSh> how do i install linux i got the cd and i dont see the
8485 setup.exe or install.exe
8486 >>----------------------------------------------------------------------
8489 >>============ Original Message ============
8490 >>>From : "Andrew Church" <achurch@achurch.org>
8493 >>>Reply-To : ircservices-coding@ircservices.za.net
8494 >>>To : ircservices-coding@ircservices.za.net
8495 >>>Subject : Re: [IRCServices Coding] Associating NickGroupInfo with
8497 >>>Date : 2003-04-23
8500 >>> The code currently assumes that at most one user will be
8502 >>>with any particular nickname, that NickInfo.user will point at the
8504 >>>with nickname NickInfo.nick, that User.ni will point at the NickInfo
8506 >>>nickname User.nick (or NULL if the nickname is not registered), and
8508 >>>User.ngi will point to a nickname group containing User.ni (or NULL
8510 >>>NICKGROUPINFO_INVALID). Breaking any of these assumptions will
8512 >>>cause many weird and dangerous things to happen.
8514 >>> Note that two or more users can be associated with a single nick
8516 >>>(if, for example, someone has two clients open and using two linked
8518 >>>However, if the user's nick is not in NickGroupInfo.nicks[], things
8522 >>> I'd strongly suggest finding another way to accomplish whatever
8524 >>>trying to do without an "su"-like command.
8527 >>> achurch@achurch.org
8528 >>> http://achurch.org/
8532 >>>>Hi, we're writing a module which allows a web interface to "su" to a
8533 nickname, similar to the way the unix "su" command (dont ask! :)) heres
8536 >>>>basically, /msg somepseudoclient su <nick> <pass>
8538 >>>>..and you gain the privilages of that nick, wether or not they are
8539 using it at the time. What we're doing at the moment is associating the
8540 user's ngi and ni fields with the nickgroupinfo of the registered
8543 >>>>NickInfo* MyNickInf = get_nickinfo(somenick);
8544 >>>>NickGroupInfo* MyNGroupInf = get_ngi(MyNickInf);
8546 >>>>u->ngi = MyNGroupInf;
8547 >>>>u->ni = MyNickInf;
8548 >>>>/* user u is now logged in with privilages of "ngi" nick, send +r as
8549 a raw if neccessary */
8551 >>>>sorry for any errors in this code, im typing it off the top of my
8553 >>>>Basically, the problem we have is, that only one nick can have
8554 "ownership" of a groupinfo at any one time, if we associate user 'u'
8555 with MyNGroupInf, then if some other user online at the time (lets call
8556 them u2) has this same association (u2->ngi == MyNG
8557 >>>>roupInf) than u2 is logged out (and has to re-identify using /msg
8558 nickserv identify <pass>). Basically we cant give two people ownership
8559 of the same nickgroup at the same time. Is there any way we can get
8560 around this, e.g. by memcpy'ing the NickGroupInfo?
8561 >>>>The ownership of the nick by the second user only needs to be
8562 temporary, until disconnect, so there shouldnt be any corruption of
8563 services DB's by having two people pointing at the same nickgroup in the
8564 file, or anything as weird as that :)
8566 >>>>If theres any way to solve this problem simply, without needing andy
8567 to rewrite the core, or for us to approach the problem a different way,
8568 we'd be grateful of anyone could tell us how :)
8572 >>>>ChatSpike Services-dev
8576 >>>>------------------------------------------------------------------
8579 >>>------------------------------------------------------------------
8580 >>>To unsubscribe or change your subscription options, visit:
8581 >>>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
8585 >>========= End of Original Message =========
8589 >>------------------------------------------------------------------
8590 >>To unsubscribe or change your subscription options, visit:
8591 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
8599 >------------------------------------------------------------------
8600 >To unsubscribe or change your subscription options, visit:
8601 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
8604 ------------------------------------------------------------------
8605 To unsubscribe or change your subscription options, visit:
8606 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
8611 From wahoo at cyberdreamers.org Sat Apr 26 10:03:16 2003
8612 From: wahoo at cyberdreamers.org (wahoo)
8613 Date: Sat Oct 23 23:09:52 2004
8614 Subject: [IRCServices Coding] feature suggestion...
8615 Message-ID: <165113385345.20030426190316@cyberdreamers.org>
8620 I've been using IRCServices in conjunction with UnrealIRCd for over
8621 3 years now and I'd like to suggest some features to make IRCServices
8622 even more comfortable and user-friendly than it already is :)...
8624 Unreal (and perhaps some other ircds) support virtual hosts these
8625 days. Wouldn't it be a good idea to allow users to store a vhost
8626 whithin their NickServ-account? So, whenever a user identify's
8627 himself, his ident and hostname will be changed by services to
8628 the one previously defined f.e. with 'SET VHOST <user@host>'? (for
8629 security reasons, changing of the vhost-entry could be restricted
8630 to Service Admins only). There could also be an option to define
8631 whether the users host should be changed automatically or not when
8634 Of course, there would always be the possibility to enhance
8635 services by an extra HostServ-module or whatever. But then users
8636 would have to additionally use a specific HostServ-command to
8637 change their host to the (self-)defined one. Furthermore, there
8638 is already the /VHOST command (at least in unreal) - but the
8639 vhost.conf has to be edited manually by Server Admins. So, you
8640 (as a user) have to give them a passwd for it - which means,
8641 you can either define (and remember) just another new one or
8642 you have to give away your NickServ-pass.
8644 Sorry, if this feature-request hasn't been mentioned for the
8645 first time and/or has already been discussed/rejected/planned-
8646 for-future-versions :)...
8655 B.O.F.H @ cyb.net ;D
8657 From r-krisztian at softhome.net Sat Apr 26 11:00:34 2003
8658 From: r-krisztian at softhome.net (Krisztian Romek)
8659 Date: Sat Oct 23 23:09:52 2004
8660 Subject: [IRCServices Coding] feature suggestion...
8661 In-Reply-To: <165113385345.20030426190316@cyberdreamers.org>
8662 References: <165113385345.20030426190316@cyberdreamers.org>
8663 Message-ID: <200304262000.34012.r-krisztian@softhome.net>
8667 > Unreal (and perhaps some other ircds) support virtual hosts these
8668 > days. Wouldn't it be a good idea to allow users to store a vhost
8669 > whithin their NickServ-account?
8671 You are lucky, here is a patch (it isn't mine, don't think that):
8673 http://www.nikhok.hu/~xanco/download/vhost.html
8677 r-krisztian@softhome.net
8679 From wahoo at cyberdreamers.org Sat Apr 26 10:56:35 2003
8680 From: wahoo at cyberdreamers.org (wahoo)
8681 Date: Sat Oct 23 23:09:52 2004
8682 Subject: [IRCServices Coding] feature suggestion...
8683 In-Reply-To: <200304262000.34012.r-krisztian@softhome.net>
8684 References: <165113385345.20030426190316@cyberdreamers.org>
8685 <200304262000.34012.r-krisztian@softhome.net>
8686 Message-ID: <153116585387.20030426195635@cyberdreamers.org>
8692 >> Unreal (and perhaps some other ircds) support virtual hosts these
8693 >> days. Wouldn't it be a good idea to allow users to store a vhost
8694 >> whithin their NickServ-account?
8696 > You are lucky, here is a patch (it isn't mine, don't think that):
8698 > http://www.nikhok.hu/~xanco/download/vhost.html
8701 Thx alot ...I'll give it a try :)
8706 From brain at brainbox.winbot.co.uk Sun Apr 27 04:24:37 2003
8707 From: brain at brainbox.winbot.co.uk (Craig Edwards)
8708 Date: Sat Oct 23 23:09:52 2004
8709 Subject: [IRCServices Coding] feature suggestion...
8710 Message-ID: <200304271024.h3RAOcA30234@localhost.localdomain>
8712 We are considering writing a hostserv module that gives a user a vhost when they identify. We were also considering some other things like allowing users to pick their own vhosts on a credits basis, they get X credits a month and each credit allows them to change their vhost, if theyre out of credits they cant change their host, generally to stop people using it to evade bans... This was just an idea that was passed around though, no fixed ideas yet.
8714 If we develop this module before it finds its way into the ircservices distro (if it does) then drop us a line and we may give you our module :-)
8719 >I've been using IRCServices in conjunction with UnrealIRCd for over
8720 >3 years now and I'd like to suggest some features to make IRCServices
8721 >even more comfortable and user-friendly than it already is :)...
8723 >Unreal (and perhaps some other ircds) support virtual hosts these
8724 >days. Wouldn't it be a good idea to allow users to store a vhost
8725 >whithin their NickServ-account? So, whenever a user identify's
8726 >himself, his ident and hostname will be changed by services to
8727 >the one previously defined f.e. with 'SET VHOST <user@host>'? (for
8728 >security reasons, changing of the vhost-entry could be restricted
8729 >to Service Admins only). There could also be an option to define
8730 >whether the users host should be changed automatically or not when
8733 > Of course, there would always be the possibility to enhance
8734 >services by an extra HostServ-module or whatever. But then users
8735 >would have to additionally use a specific HostServ-command to
8736 >change their host to the (self-)defined one. Furthermore, there
8737 >is already the /VHOST command (at least in unreal) - but the
8738 >vhost.conf has to be edited manually by Server Admins. So, you
8739 >(as a user) have to give them a passwd for it - which means,
8740 >you can either define (and remember) just another new one or
8741 >you have to give away your NickServ-pass.
8743 >Sorry, if this feature-request hasn't been mentioned for the
8744 >first time and/or has already been discussed/rejected/planned-
8745 >for-future-versions :)...
8754 >B.O.F.H @ cyb.net ;D
8756 >------------------------------------------------------------------
8757 >To unsubscribe or change your subscription options, visit:
8758 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
8761 From jskam at shaw.ca Sun Apr 27 14:29:19 2003
8762 From: jskam at shaw.ca (Jeffery Kam)
8763 Date: Sat Oct 23 23:09:52 2004
8764 Subject: [IRCServices Coding] Probably real easy coding, but please help...
8765 Message-ID: <000001c30d04$10487480$f64f9144@weed>
8767 What I'm trying to do is make a Backup command in operserv that will
8768 back up the databases into a separate directory. But I would also like
8769 some insight on how to make it back up the databases automatically, that
8774 If someone could show me some examples of both those ways, would be a
8783 -------------- next part --------------
8784 An HTML attachment was scrubbed...
8785 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030427/f0088b39/attachment.html
8786 From achurch at achurch.org Wed Apr 30 14:06:30 2003
8787 From: achurch at achurch.org (Andrew Church)
8788 Date: Sat Oct 23 23:09:52 2004
8789 Subject: [IRCServices Coding] Chanserv patch for reg chans only
8790 In-Reply-To: <20030312150441.A19757@mbay.net>
8791 Message-ID: <3eaf59e5.62753@mail.achurch.org>
8799 >Here's a patch to add an option for forbiding use unregistered channels
8800 >by normal users. Yeah, it's a bit fascist, but sometimes this much control
8801 >is needed - on IRC servers that are used for commercial support, where it
8802 >would not be appropriate to have someone create #hotgaysex, for example.
8804 >This is the first hack I've done on ircservices, so someone please check
8805 >to make sure I didn't miss something. I tried to cover all bases.
8807 >diff -c -r ircservices-5.0.13/data/example-modules.conf ircservices-5.0.13-local/data/example-modules.conf
8808 >*** ircservices-5.0.13/data/example-modules.conf Mon Mar 3 01:54:47 2003
8809 >--- ircservices-5.0.13-local/data/example-modules.conf Wed Mar 12 16:41:23 2003
8814 > #CSForbidShortChannel
8816 >+ # CSRegisteredOnly [OPTIONAL]
8817 >+ # When enabled, treats unregistered channels as forbidden, not
8818 >+ # allowing normal users to join. If enabled, services opers will
8819 >+ # need to create any new channels on the network. For this option
8820 >+ # to be effective, CSEnableRegister should generally NOT be enabled.
8822 >+ #CSRegisteredOnly
8826 > ################################ SENDPASS module
8827 >diff -c -r ircservices-5.0.13/docs/a.html ircservices-5.0.13-local/docs/a.html
8828 >*** ircservices-5.0.13/docs/a.html Sun Mar 2 21:18:48 2003
8829 >--- ircservices-5.0.13-local/docs/a.html Wed Mar 12 16:50:04 2003
8834 > <p>Example: <tt>CSForbidShortChannel</tt>
8837 >+ <a name="chanserv/main.CSRegisteredOnly"></a>
8839 >+ <tt><b>CSRegisteredOnly</b></tt> [OPTIONAL]
8840 >+ <p>When enabled, treats unregistered channels as forbidden, not
8841 >+ allowing normal users to join. If enabled, services opers will
8842 >+ need to create any new channels on the network. For this option
8843 >+ to be effective, CSEnableRegister should generally NOT be enabled.
8845 >+ <p>Example: <tt>CSRegisteredOnly</tt>
8848 > <a name="chanserv/sendpass"></a>
8849 > <p><font size="+1"><b>chanserv/sendpass</b> (SENDPASS module)</font>
8851 >diff -c -r ircservices-5.0.13/modules/chanserv/check.c ircservices-5.0.13-local/modules/chanserv/check.c
8852 >*** ircservices-5.0.13/modules/chanserv/check.c Mon Mar 3 01:54:48 2003
8853 >--- ircservices-5.0.13-local/modules/chanserv/check.c Wed Mar 12 04:55:35 2003
8862 > if (is_services_admin(user))
8869 >! if(CSRegisteredOnly && !is_oper(user)) {
8870 >! mask = sstrdup("*!*@*");
8871 >! reason = getstring(user->ngi, CHAN_MAY_NOT_BE_USED);
8878 > if (is_services_admin(user))
8880 >diff -c -r ircservices-5.0.13/modules/chanserv/cs-local.h ircservices-5.0.13-local/modules/chanserv/cs-local.h
8881 >*** ircservices-5.0.13/modules/chanserv/cs-local.h Mon Mar 3 01:54:48 2003
8882 >--- ircservices-5.0.13-local/modules/chanserv/cs-local.h Wed Mar 12 04:45:02 2003
8886 > E time_t CSSuspendExpire;
8887 > E time_t CSSuspendGrace;
8888 > E int CSForbidShortChannel;
8889 >+ E int CSRegisteredOnly;
8890 > E ChanOpt chanopts[];
8893 >diff -c -r ircservices-5.0.13/modules/chanserv/main.c ircservices-5.0.13-local/modules/chanserv/main.c
8894 >*** ircservices-5.0.13/modules/chanserv/main.c Mon Mar 3 01:54:48 2003
8895 >--- ircservices-5.0.13-local/modules/chanserv/main.c Wed Mar 12 03:47:23 2003
8899 > time_t CSSuspendExpire;
8900 > time_t CSSuspendGrace;
8901 > int CSForbidShortChannel;
8902 >+ int CSRegisteredOnly;
8903 > EXPORT_VAR(int32,CSMaxReg)
8905 > /*************************************************************************/
8909 > { "CSEnableRegister", { { CD_SET, 0, &CSEnableRegister } } },
8910 > { "CSExpire", { { CD_TIME, 0, &CSExpire } } },
8911 > { "CSForbidShortChannel",{{CD_SET, 0, &CSForbidShortChannel } } },
8912 >+ { "CSRegisteredOnly", { { CD_SET, 0, &CSRegisteredOnly } } },
8913 > { "CSInhabit", { { CD_TIME, CF_DIRREQ, &CSInhabit } } },
8914 > { "CSListMax", { { CD_POSINT, CF_DIRREQ, &CSListMax } } },
8915 > { "CSListOpersOnly", { { CD_SET, 0, &CSListOpersOnly } } },
8916 >------------------------------------------------------------------
8917 >To unsubscribe or change your subscription options, visit:
8918 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
8919 From achurch at achurch.org Wed Apr 30 14:19:18 2003
8920 From: achurch at achurch.org (Andrew Church)
8921 Date: Sat Oct 23 23:09:52 2004
8922 Subject: [IRCServices Coding] JUPE and bahamut-1.4(35)
8923 In-Reply-To: <001701c2e56f$c8cbb880$0100a8c0@zeus>
8924 Message-ID: <3eaf5d1d.66456@mail.achurch.org>
8932 >I found another possible bug.
8933 >When i do /os squit server and the server is active, then services crashes.
8934 >I have to do squit and after to use the jupe command.
8935 >-chat.xchat.gr- *** Global -- from OperServ: Juping matrix.voxnet.gr by request of KillServ.
8936 >-chat.xchat.gr- *** Routing -- from chat.xchat.gr: Link services.xchat.gr[(+)something@0.0.0.0]
8937 >cancelled, server matrix.voxnet.gr already exists
8938 >-chat.xchat.gr- *** Notice -- services.xchat.gr was connected for 5 seconds. 24/62 sendK/recvK.
8940 >I don't know if it is another problem with bahamut 1.4(35), but it happens only with version
8941 >of bahamut and not bahamut-1.4(35)
8951 >------------------------------------------------------------------
8952 >To unsubscribe or change your subscription options, visit:
8953 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
8954 From chris at unreal-irc.net Wed Apr 30 12:25:08 2003
8955 From: chris at unreal-irc.net (chris@unreal-irc.net)
8956 Date: Sat Oct 23 23:09:52 2004
8957 Subject: [IRCServices Coding] Unknown Error
8958 Message-ID: <000e01c30f4e$3a08b220$236dbbac@iceinferno>
8962 Just checked my ircservices log and I found something I have not seen so far, I was wondering if anyone could please shed some light onto it? This is happening consistently.
8964 We are using Unreal3.2b15
8966 [Apr 30 18:40:02 2003] protocol/unreal: m_sethost: user record for asli not found
8967 [Apr 30 18:40:16 2003] protocol/unreal: m_sethost: user record for |Jeff| not found
8968 [Apr 30 18:40:52 2003] protocol/unreal: m_sethost: user record for dsgtg not found
8969 [Apr 30 18:41:03 2003] protocol/unreal: m_sethost: user record for ^KnOc^ not found
8970 [Apr 30 18:41:50 2003] protocol/unreal: m_sethost: user record for kddnt not found
8971 [Apr 30 18:44:46 2003] protocol/unreal: m_sethost: user record for ombha not found
8972 [Apr 30 18:45:00 2003] protocol/unreal: m_sethost: user record for fAnself not found
8973 [Apr 30 18:45:20 2003] protocol/unreal: m_sethost: user record for xqejtw not found
8974 [Apr 30 18:45:27 2003] protocol/unreal: m_sethost: user record for Nikolaus not found
8975 [Apr 30 18:46:10 2003] protocol/unreal: m_sethost: user record for adsur not found
8976 [Apr 30 18:46:43 2003] protocol/unreal: m_sethost: user record for dAdrianc not found
8977 [Apr 30 18:48:35 2003] protocol/unreal: m_sethost: user record for cmjdjm2 not found
8978 [Apr 30 18:49:35 2003] protocol/unreal: m_sethost: user record for [Theo] not found
8979 [Apr 30 18:50:00 2003] protocol/unreal: m_sethost: user record for ybemj not found
8980 [Apr 30 18:50:04 2003] protocol/unreal: m_sethost: user record for Hardie not found
8981 [Apr 30 18:50:22 2003] protocol/unreal: m_sethost: user record for [Odolf] not found
8982 [Apr 30 18:51:12 2003] protocol/unreal: m_sethost: user record for Tino not found
8983 -------------- next part --------------
8984 An HTML attachment was scrubbed...
8985 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030430/5e951de6/attachment.htm
8986 From Slowking50 at aol.com Wed Apr 30 17:24:00 2003
8987 From: Slowking50 at aol.com (Slowking50@aol.com)
8988 Date: Sat Oct 23 23:09:52 2004
8989 Subject: [IRCServices Coding] Hybrid support
8990 Message-ID: <026572BE.2337F8D0.0CD45FDB@aol.com>
8992 Here's a protocol/hybrid.c that can be used for hyb7. Issues include:
8994 1) Keeptopic doesn't work right unless m_topic and do_topic are modified directly :/ Hybrid propogates user topics in the same way it recieves them (:user TOPIC channel :topic). Probably just needs some av=2 checking.
8996 2) Services aliases(/cs and friends) are hard to come by o.- However, I do have an m_services.c that can be loaded into Hybrid if anyone wants to take a look.
8998 3) In modules.conf, aside from NetworkDomain, disable pretty much everything non-essential under protocol/hybrid. CSSetChannelTime works but makes Hybrid complain like an old grandma on steroids. :/
9000 Aside from those, the file works pretty well :) I'm currently running Hybrid 7.0rc9 and IRCServices 5.0.16 and I've tested every command to make sure they work. I'm not sure about tricky little stuff, so if someone wants to give this file some strenuous testing, be my guest.
9001 -------------- next part --------------
9002 A non-text attachment was scrubbed...
9004 Type: application/octet-stream
9007 Url : http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030430/d4ab25b5/hybrid.obj
9008 From andrewk at isdial.net Thu May 1 01:18:54 2003
9009 From: andrewk at isdial.net (Andrew Kempe)
9010 Date: Sat Oct 23 23:09:52 2004
9011 Subject: [IRCServices Coding] Hybrid support
9012 References: <026572BE.2337F8D0.0CD45FDB@aol.com>
9013 Message-ID: <012101c30fba$4e4def90$1f0912ac@espotting.com>
9017 In future, please do not post attachments to this list. Please post the URL
9018 where files can be downloaded.
9022 ----- Original Message -----
9023 From: <Slowking50@aol.com>
9024 To: <ircservices-coding@ircservices.za.net>
9025 Sent: Thursday, May 01, 2003 1:24 AM
9026 Subject: [IRCServices Coding] Hybrid support
9029 > Here's a protocol/hybrid.c that can be used for hyb7. Issues include:
9031 > 1) Keeptopic doesn't work right unless m_topic and do_topic are modified
9032 directly :/ Hybrid propogates user topics in the same way it recieves them
9033 (:user TOPIC channel :topic). Probably just needs some av=2 checking.
9035 > 2) Services aliases(/cs and friends) are hard to come by o.- However, I do
9036 have an m_services.c that can be loaded into Hybrid if anyone wants to take
9039 > 3) In modules.conf, aside from NetworkDomain, disable pretty much
9040 everything non-essential under protocol/hybrid. CSSetChannelTime works but
9041 makes Hybrid complain like an old grandma on steroids. :/
9043 > Aside from those, the file works pretty well :) I'm currently running
9044 Hybrid 7.0rc9 and IRCServices 5.0.16 and I've tested every command to make
9045 sure they work. I'm not sure about tricky little stuff, so if someone wants
9046 to give this file some strenuous testing, be my guest.
9050 ----------------------------------------------------------------------------
9054 > ------------------------------------------------------------------
9055 > To unsubscribe or change your subscription options, visit:
9056 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
9059 From Slowking50 at aol.com Thu May 1 07:37:30 2003
9060 From: Slowking50 at aol.com (Slowking50@aol.com)
9061 Date: Sat Oct 23 23:09:52 2004
9062 Subject: [IRCServices Coding] Hybrid support
9063 Message-ID: <670886DF.2D2930DD.0CD45FDB@aol.com>
9067 Anyway, few corrections, I had some leftover stuff("Bahamut" protocol and a leftover useless SJOIN modifier), which I fixed. New release:
9069 http://www.angelfire.com/az3/d-mstats/hybrid.c
9070 From andrewk at isdial.net Thu May 1 07:47:28 2003
9071 From: andrewk at isdial.net (Andrew Kempe)
9072 Date: Sat Oct 23 23:09:52 2004
9073 Subject: [IRCServices Coding] Hybrid support
9074 References: <670886DF.2D2930DD.0CD45FDB@aol.com>
9075 Message-ID: <015001c30ff0$969f5d20$1f0912ac@espotting.com>
9081 ----- Original Message -----
9082 From: <Slowking50@aol.com>
9083 To: "IRC Services Coding Mailing List"
9084 <ircservices-coding@ircservices.za.net>
9085 Sent: Thursday, May 01, 2003 3:37 PM
9086 Subject: Re: [IRCServices Coding] Hybrid support
9091 > Anyway, few corrections, I had some leftover stuff("Bahamut" protocol and
9092 a leftover useless SJOIN modifier), which I fixed. New release:
9094 > http://www.angelfire.com/az3/d-mstats/hybrid.c
9095 > ------------------------------------------------------------------
9096 > To unsubscribe or change your subscription options, visit:
9097 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
9101 From aragon at phat.za.net Thu May 1 08:11:17 2003
9102 From: aragon at phat.za.net (Aragon Gouveia)
9103 Date: Sat Oct 23 23:09:52 2004
9104 Subject: [IRCServices Coding] Feature request
9105 Message-ID: <20030501151117.GA38560@phat.za.net>
9109 Would it be possible to add a configurable option that makes services add
9110 SQLINE entries for each and every forbidden and/or suspended nickname? I
9111 think it's a much better way of preventing a nick's use if the ircd supports
9119 From diego at redesul.net Fri May 2 05:56:46 2003
9120 From: diego at redesul.net (Diego Bitencourt Contezini)
9121 Date: Sat Oct 23 23:09:52 2004
9122 Subject: [IRCServices Coding] IRCServices HTTPD MODULE
9123 In-Reply-To: <200304262000.34012.r-krisztian@softhome.net>
9124 Message-ID: <003301c310aa$4a67fec0$4506000a@dauphin.com.br>
9126 Hello, I am building some addons about httpd+xml, and need to used post
9127 to can build on modules the possibility of import/change database.
9128 I was testing, and what I seen is that just the first variables of POST
9129 are being copyed to c->variables (casually "xml" is it).
9130 (here is my request post:
9131 <form action=http://127.0.0.1:8066/dbaccess/xml-import-nick/blabla
9133 <input type="hidden" name="xml"
9134 value="<nicknamefock>blabla</nicknamefock>">
9135 <input type="Submit" value="Send">
9140 someone used/tested how works the POST? Where I can get the variables?
9141 It should be on c->variables and c->variables_count (its what I
9142 understud.. possible im wrong, than please I need a help ;)
9146 Diego Bitencourt Contezini aka destruct_ @irc.redesul.net
9148 From Slowking50 at aol.com Fri May 2 08:29:53 2003
9149 From: Slowking50 at aol.com (Slowking50@aol.com)
9150 Date: Sat Oct 23 23:09:52 2004
9151 Subject: [IRCServices Coding] Hybrid support - Hopefully final :)
9152 Message-ID: <072D62BC.3F95CF2D.0CD45FDB@aol.com>
9154 Okay, I now have this patch running on a 1500-user Hyb7 net and it appears to be stable :) Final corrections and notes -
9156 1) In do_send_akill I had s_OperServ instead of who. Don't ask what I was smoking. >.>
9158 2) Services need a reference in the shared {} block of all ircd.conf files in order to set akills. Services will still work without this, but they won't be able to stop banned users; they'll just keep doing repeated kills.
9160 3) Makefile modifications are as follows:
9162 MODULES = bahamut.so dalnet.so dreamforge.so monkey.so ptlink.so \
9163 rfc1459.so trircd.so ts8.so undernet-p9.so unreal.so hybrid.so
9165 OBJECTS-dreamforge.so = svsnick.o
9166 OBJECTS-hybrid.so = banexcept.o halfop.o sjoin.o
9167 OBJECTS-monkey.so = halfop.o sjoin.o
9169 $(TOPDIR)/modules/nickserv/nickserv.h
9170 INCLUDES-hybrid.o = banexcept.h sjoin.h halfop.h \
9171 $(TOPDIR)/messages.h $(TOPDIR)/language.h \
9172 $(TOPDIR)/modules/operserv/operserv.h \
9173 $(TOPDIR)/modules/nickserv/nickserv.h
9174 INCLUDES-monkey.o = halfop.h sjoin.h \
9177 Anyone want to make a decent Makefile patch? :)
9179 http://www.angelfire.com/az3/d-mstats/hybrid.c
9180 From jskam at shaw.ca Sat May 3 06:53:49 2003
9181 From: jskam at shaw.ca (Jeffery Kam)
9182 Date: Sat Oct 23 23:09:52 2004
9183 Subject: [IRCServices Coding] Recognizing ServicesRoot for UMODE Change
9184 Message-ID: <000401c3117b$6ca3f580$f64f9144@weed>
9186 Ok, this used to work before, but for some reason it just stopped. I
9187 use the dreamforge.c protocol, and I've added a UMODE to my ircd and
9188 services to change the umode for ServicesRoot to +R. But for some
9189 reason, I can't get it to recognize when ServicesRoot is oper'd and
9190 ready for the mode change. In the same way as +a. This is not an IRCD
9191 problem because I have gotten other modes working, such as +C (Services
9196 If someone can give me some insight, it would be greatly appreciated.
9200 ### Modules/protocol/dreamforge.c ###
9202 --- WORKING UMODE +C CODE ---
9206 if (is_oper(user)) {
9208 if (user->ngi->os_priv == NP_SERVOPER) {
9212 send_cmd(ServerName, "SVSMODE %s +C", user->nick);
9218 send_cmd(ServerName, "SVSMODE %s -C", user->nick);
9228 --- NOT WORKING UMODE +R CODE ---
9232 if (is_oper(user)) {
9234 if (stricmp(user->nick, ServicesRoot) == 0) {
9238 send_cmd(ServerName, "SVSMODE %s +R", user->nick);
9244 send_cmd(ServerName, "SVSMODE %s -R", user->nick);
9252 -------------- next part --------------
9253 An HTML attachment was scrubbed...
9254 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030503/6d69d425/attachment.htm
9255 From bytor at tribes2maps.com Tue May 6 16:07:17 2003
9256 From: bytor at tribes2maps.com (Ross Carlson)
9257 Date: Sat Oct 23 23:09:52 2004
9258 Subject: [IRCServices Coding] Issues with converting PTlink databases
9259 Message-ID: <58753.216.204.85.34.1052262437.squirrel@www.metacraft.com>
9261 I have a decent sized network (about 7000 registered users) running ptlink
9262 ircd and services. I am going to be converting to Unreal ircd and IRC
9263 Services soon. I have run a test, and read the docs, and I see that the
9264 convert-db will not carry over custom channel access levels.
9266 I would like to inquire about the possibility of modifying the convert-db
9267 to fix this. I'm not much of a C coder, but I could probably do the work
9268 myself if I had something resembling a specification for the ptlink
9269 database format. I thought someone here might have that ... especially the
9270 person that wrote the convert-db functions to begin with. Was that Andrew?
9272 Anyway, part of the issue is the maximum and minimum levels assignable in
9273 IRC Services. I see that they are 999/-999. In PTLink, they are 9999/-9999.
9274 Would I "break" anything by changing those to 9999 in IRC Services?
9276 Also, I see in the XML spec that there are fields defined for carrying over
9277 custom access level settings for each channel. That makes me wonder why the
9278 convert-db doesn't actually convert them. I don't want to try to add the
9279 feature if there is a reason (other than lack of time) that it wasn't added
9282 Thanks for any help anyone has to offer!
9284 *-----------------------------------*
9285 | Tribes 1 & 2 Chat Server Admin |
9286 | Email: bytor@tribes2maps.com |
9287 | bytor@sierra.com |
9288 | Server: irc.dynamix.com Port 6667 |
9289 | Visit http://www.Tribes2Maps.com |
9290 *-----------------------------------*
9293 From draco at silverdragonden.com Wed May 7 22:43:40 2003
9294 From: draco at silverdragonden.com (Benjamin Higginbotham)
9295 Date: Sat Oct 23 23:09:52 2004
9296 Subject: [IRCServices Coding] Help installing IRC Services
9297 Message-ID: <05B4A104-8118-11D7-AA20-000393D570BA@silverdragonden.com>
9299 I have a question, hopefully someone can help...
9301 I'm trying to get Services to run with an unsupported IRCD, cyclone.
9302 The Cyclone distribution has version 4.49 of Services with a diff file.
9303 I'm able to make the changes and compile everything just fine. When I
9304 attempt to start services with a ./services my IRCD spits out an error
9305 about an N line (which I have, along with a C line), and in the
9306 services.log file she spits out an error in connecting to the server.
9308 I know Cyclone is not a supported IRCD. I don't suppose by chance
9309 anyone has a copy working with a Cyclone IRCD. If so, how did you make
9310 it work. If this is not the appropriate place to ask such questions, I
9311 would greatly appreciate a pointer in the right place to go. I'm new
9312 to IRCD, so please forgive my ignorance.
9316 Benjamin Higginbotham
9317 draco@silverdragonden.com
9318 www.silverdragonden.com
9321 From Slowking50 at aol.com Thu May 8 11:24:31 2003
9322 From: Slowking50 at aol.com (Slowking50@aol.com)
9323 Date: Sat Oct 23 23:09:52 2004
9324 Subject: [IRCServices Coding] Hybrid patch - This should be it.
9325 Message-ID: <1EA71DE7.7237227C.0CD45FDB@aol.com>
9327 Okay, here are the issues and solutions:
9329 1) Hybrid requires an online nick to set remote klines. So I imported s_OperServ to set all akills.
9331 2) In order to cut down on patches, I put the topic handler in hybrid.c via register_messages. This turns out to be a bad hack, since I can't find a way to call cb_topic.
9333 3) Remote JOINs need a timestamp. Use the following patch on modules/chanserv/check.c:
9335 http://www.angelfire.com/az3/d-mstats/check.diff
9337 4) Implementing into modules/protocol/Makefile:
9339 http://www.angelfire.com/az3/d-mstats/make.diff
9343 http://www.angelfire.com/az3/d-mstats/hybrid.c
9345 I hope this works this time :) It's been tested plenty, thanks to kryptik and animenetworks for the help.
9346 From diego at redesul.net Fri May 9 12:14:21 2003
9347 From: diego at redesul.net (Diego Bitencourt Contezini)
9348 Date: Sat Oct 23 23:09:52 2004
9349 Subject: [IRCServices Coding] ircservices bug....
9350 Message-ID: <000901c3165f$32d2b600$4506000a@dauphin.com.br>
9352 Hello... this is a bug that happens 6 months ago...
9353 I'm with a db with 40.000 nicks, and when it get some days of uptime
9354 happens it, specially when the network are full. (5000 users on the same
9356 It happens sometimes, this is the basic debugging that I'm posting here
9357 for if someone have any idea about why it happens, help me. I don't have
9358 skills on ircservices-coding for now to help much, but I think that who
9359 built it can understand it more easily :-).
9363 [May 07 22:41:27 2003] nickserv/main:
9364 AndreGoes!~BBFC_toki@200.193.105.231
9365 identified for nick AndreGoes
9366 [May 07 22:41:29 2003] nickserv/main: bash!~bash@200.206.72.16
9370 Program received signal SIGSEGV, Segmentation fault.
9371 do_cmode (source=0x8065368 "ChanServ", ac=-3, av=0xbfffed68) at
9375 #0 do_cmode (source=0x8065368 "ChanServ", ac=-3, av=0xbfffed68)
9377 source = 0x8065368 "ChanServ"
9379 av = (char **) 0xbfffed68
9380 chan = (Channel *) 0x88e9218
9381 s = 0x2e646165 <Address 0x2e646165 out of bounds>
9383 modestr = 0x2e646165 <Address 0x2e646165 out of bounds> #1
9384 0x0804d32d in flush_cmode (md=0x8065360) at actions.c:554
9385 . continue next mail..
9386 -------------- next part --------------
9387 An HTML attachment was scrubbed...
9388 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030509/d87ae059/attachment.html
9389 From diego at redesul.net Fri May 9 12:17:04 2003
9390 From: diego at redesul.net (Diego Bitencourt Contezini)
9391 Date: Sat Oct 23 23:09:52 2004
9392 Subject: [IRCServices Coding] continuing... part 2 of 3 BUG SERVICES
9393 Message-ID: <001801c3165f$936d1690$4506000a@dauphin.com.br>
9395 buf = "-impsl LaMm3rZ iN
9396 AcTiON\000rO\00312\002,\002\00314LoKaUmM\00312
9397 \002)\002 \00314p\037a\037\002r\002c\002e\002\037r\037ia\037s\037
9398 \00312\002- \002 \00312#\00314RzO \00312#\00314MaStErS
9400 \00312#\00314DrEaM \00312#\00314LoCkS\017\017\000VINDOS:::...\00011
9401 \0377.\002hp\037g.\037co\002m.\037br\017 \0032\037eh
9402 \00313w\002ww.\037em"...
9403 s = 0xbfffed80 "-impsl LaMm3rZ iN AcTiON"
9404 argv = {0x88e9220 "#insano",
9405 0x2e646165 <Address 0x2e646165 out of bounds>,
9406 0x76202d20 <Address 0x76202d20 out of bounds>,
9407 0x74697369 <Address 0x74697369 out of bounds>,
9408 0x23206d65 <Address 0x23206d65 out of bounds>,
9409 0x2076746d <Address 0x2076746d out of bounds>,
9410 0x76757323 <Address 0x76757323 out of bounds>,
9411 ---Type <return> to continue, or q <return> to quit---
9412 0x206f6361 <Address 0x206f6361 out of bounds>}
9416 #2 0x0804d113 in set_cmode (sender=0x0, channel=0x0) at actions.c:284
9418 modes = 0xbffff4b8 "\030???jr\005\bX?3\n\037"
9419 modes_orig = 0xbffff460 "{Cris}"
9420 md = (struct modedata *) 0x0
9425 s = 0xffffffff <Address 0xffffffff out of bounds>
9427 modes = 0xbffff4b8 "\030???jr\005\bX?3\n\037"
9428 modes_orig = 0xbffff460 "{Cris}"
9432 -------------- next part --------------
9433 An HTML attachment was scrubbed...
9434 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030509/80e5fe49/attachment.htm
9435 From diego at redesul.net Fri May 9 12:17:47 2003
9436 From: diego at redesul.net (Diego Bitencourt Contezini)
9437 Date: Sat Oct 23 23:09:52 2004
9438 Subject: [IRCServices Coding] part 3 finally.. BUG SERVICES
9439 Message-ID: <001d01c3165f$adb859b0$4506000a@dauphin.com.br>
9442 #3 0x08052ddc in main (ac=2, av=0xbffff6a4, envp=0xbffff6b0) at
9444 last_update = 1052356199
9445 last_expire = 1052358046
9446 last_check = 91115037
9447 ---Type <return> to continue, or q <return> to quit---
9448 last_update = 1052356199
9449 last_expire = 1052358046
9450 last_check = 91115037
9451 #4 0x4003a74f in __libc_start_main (main=0x8052b68 <main>, argc=2,
9452 ubp_av=0xbffff6a4, init=0x804be70 <_init>, fini=0x805a54c <_fini>,
9453 rtld_fini=0x4000aa00 <_dl_fini>, stack_end=0xbffff69c)
9454 at ../sysdeps/generic/libc-start.c:129
9455 ubp_av = (char **) 0xbffff6a4
9456 fini = (void (*)()) 0x4001490c <_dl_debug_mask>
9457 rtld_fini = (void (*)()) 0x88e9227
9458 ubp_ev = (char **) 0x2e646165
9460 (gdb) info registers
9461 eax 0x2e646165 778330469
9462 ecx 0x88e9227 143561255
9465 esp 0xbfffed00 0xbfffed00
9466 ebp 0xbfffed38 0xbfffed38
9468 edi 0x88e9218 143561240
9469 eip 0x804daf3 0x804daf3
9470 eflags 0x10282 66178
9481 fioff 0x40157be1 1075149793
9484 ---Type <return> to continue, or q <return> to quit---
9486 xmm0 0xffffffffffffffffffffffffffffffff
9487 xmm1 0xffffffffffffffffffffffffffffffff
9488 xmm2 0xffffffffffffffffffffffffffffffff
9489 xmm3 0xffffffffffffffffffffffffffffffff
9490 xmm4 0xffffffffffffffffffffffffffffffff
9491 xmm5 0xffffffffffffffffffffffffffffffff
9492 xmm6 0xffffffffffffffffffffffffffffffff
9493 xmm7 0xffffffffffffffffffffffffffffffff
9498 If i can do something more to help, please give me ideas and I will to
9499 all to help on debugging :]
9502 (sorry for my fucking dumb bad English :-)
9503 Diego Bitencourt Contezini aka destruct_ @ irc.redesul.net
9505 -------------- next part --------------
9506 An HTML attachment was scrubbed...
9507 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030509/660b081b/attachment.html
9508 From diego at redesul.net Mon May 12 10:21:48 2003
9509 From: diego at redesul.net (Diego Bitencourt Contezini)
9510 Date: Sat Oct 23 23:09:52 2004
9511 Subject: [IRCServices Coding] bugs...
9512 Message-ID: <000201c318aa$f96ec900$4506000a@dauphin.com.br>
9514 Andrew, or someone.. have any idea about what can be this bug?
9520 -------------- next part --------------
9521 An HTML attachment was scrubbed...
9522 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030512/f4ee7f6d/attachment.htm
9523 From master at xchat.gr Sat May 17 11:49:36 2003
9524 From: master at xchat.gr (George Stamatiou)
9525 Date: Sat Oct 23 23:09:52 2004
9526 Subject: [IRCServices Coding] XOP List
9527 References: <58753.216.204.85.34.1052262437.squirrel@www.metacraft.com>
9528 Message-ID: <000f01c31ca5$138fd240$6bfecdd4@zeus>
9531 Is there any way to avoid users with no access in that channel to do /cs aop/sop #channel list ?
9533 Now, all users are able to do that.
9534 I think that only users with AOP or SOP access should be able to do that.
9541 From uhc0 at rz.uni-karlsruhe.de Sat May 17 12:14:33 2003
9542 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu)
9543 Date: Sat Oct 23 23:09:52 2004
9544 Subject: [IRCServices Coding] XOP List
9545 In-Reply-To: <000f01c31ca5$138fd240$6bfecdd4@zeus>
9546 References: <58753.216.204.85.34.1052262437.squirrel@www.metacraft.com>
9547 <000f01c31ca5$138fd240$6bfecdd4@zeus>
9548 Message-ID: <1053198873.4151.7.camel@dreadnought.hadiko.de>
9556 /cs help levels desc
9557 /cs levels #channel list
9559 To accomplish that what you are willing to do:
9560 /cs levels #channel set acc-change 50
9567 On Sat, 2003-05-17 at 20:49, George Stamatiou wrote:
9569 > Is there any way to avoid users with no access in that channel to do /cs aop/sop #channel list ?
9571 > Now, all users are able to do that.
9572 > I think that only users with AOP or SOP access should be able to do that.
9579 > ------------------------------------------------------------------
9580 > To unsubscribe or change your subscription options, visit:
9581 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
9583 ------------------------------------------------------------------
9584 | Yusuf Iskenderoglu | You get to meet all sorts, |
9585 | eMail - uhc0@stud.uni-karlsruhe.de| in this line of work... |
9586 | eMail - s_iskend@ira.uka.de | |
9587 | ICQ UIN : 20587464 \ TimeMr14C | |
9588 ------------------------------------------------------------------
9590 From achurch at achurch.org Tue May 6 12:03:00 2003
9591 From: achurch at achurch.org (Andrew Church)
9592 Date: Sat Oct 23 23:09:52 2004
9593 Subject: [IRCServices Coding] Unknown Error
9594 In-Reply-To: <000e01c30f4e$3a08b220$236dbbac@iceinferno>
9595 Message-ID: <3eb72600.57560@mail.achurch.org>
9597 I can't find any obvious reason for this. Can you provide a debug
9604 >This is a multi-part message in MIME format.
9606 >--===============22718851767480919==
9607 >Content-Type: multipart/alternative;
9608 > boundary="----=_NextPart_000_0009_01C30F56.97D971C0"
9610 >This is a multi-part message in MIME format.
9612 >------=_NextPart_000_0009_01C30F56.97D971C0
9613 >Content-Type: text/plain;
9614 > charset="iso-8859-1"
9615 >Content-Transfer-Encoding: quoted-printable
9619 >Just checked my ircservices log and I found something I have not seen so =
9620 >far, I was wondering if anyone could please shed some light onto it? =
9621 >This is happening consistently.
9623 >We are using Unreal3.2b15
9625 >[Apr 30 18:40:02 2003] protocol/unreal: m_sethost: user record for asli =
9627 >[Apr 30 18:40:16 2003] protocol/unreal: m_sethost: user record for =
9628 >|Jeff| not found =20
9629 >[Apr 30 18:40:52 2003] protocol/unreal: m_sethost: user record for dsgtg =
9631 >[Apr 30 18:41:03 2003] protocol/unreal: m_sethost: user record for =
9633 >[Apr 30 18:41:50 2003] protocol/unreal: m_sethost: user record for kddnt =
9635 >[Apr 30 18:44:46 2003] protocol/unreal: m_sethost: user record for ombha =
9637 >[Apr 30 18:45:00 2003] protocol/unreal: m_sethost: user record for =
9639 >[Apr 30 18:45:20 2003] protocol/unreal: m_sethost: user record for =
9641 >[Apr 30 18:45:27 2003] protocol/unreal: m_sethost: user record for =
9643 >[Apr 30 18:46:10 2003] protocol/unreal: m_sethost: user record for adsur =
9645 >[Apr 30 18:46:43 2003] protocol/unreal: m_sethost: user record for =
9647 >[Apr 30 18:48:35 2003] protocol/unreal: m_sethost: user record for =
9649 >[Apr 30 18:49:35 2003] protocol/unreal: m_sethost: user record for =
9651 >[Apr 30 18:50:00 2003] protocol/unreal: m_sethost: user record for ybemj =
9653 >[Apr 30 18:50:04 2003] protocol/unreal: m_sethost: user record for =
9655 >[Apr 30 18:50:22 2003] protocol/unreal: m_sethost: user record for =
9657 >[Apr 30 18:51:12 2003] protocol/unreal: m_sethost: user record for Tino =
9659 >------=_NextPart_000_0009_01C30F56.97D971C0
9660 >Content-Type: text/html;
9661 > charset="iso-8859-1"
9662 >Content-Transfer-Encoding: quoted-printable
9664 ><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
9666 ><META http-equiv=3DContent-Type content=3D"text/html; =
9667 >charset=3Diso-8859-1">
9668 ><META content=3D"MSHTML 6.00.2800.1126" name=3DGENERATOR>
9671 ><BODY bgColor=3D#ffffff>
9672 ><DIV><FONT face=3DArial size=3D2>Hi there,</FONT></DIV>
9673 ><DIV><FONT face=3DArial size=3D2></FONT> </DIV>
9674 ><DIV><FONT face=3DArial size=3D2>Just checked my ircservices log and I =
9676 >something I have not seen so far, I was wondering if anyone could please =
9678 >some light onto it? This is happening consistently.</FONT></DIV>
9679 ><DIV><FONT face=3DArial size=3D2></FONT> </DIV>
9680 ><DIV><FONT face=3DArial size=3D2>We are using Unreal3.2b15</FONT></DIV>
9681 ><DIV><FONT face=3DArial size=3D2></FONT> </DIV>
9682 ><DIV><FONT face=3DArial size=3D2>[Apr 30 18:40:02 2003] protocol/unreal: =
9684 >user record for asli not found<BR>[Apr 30 18:40:16 2003] =
9685 >protocol/unreal:=20
9686 >m_sethost: user record for |Jeff| not found <BR>[Apr 30 =
9688 >2003] protocol/unreal: m_sethost: user record for dsgtg not =
9689 >found<BR>[Apr 30=20
9690 >18:41:03 2003] protocol/unreal: m_sethost: user record for ^KnOc^ not=20
9691 >found<BR>[Apr 30 18:41:50 2003] protocol/unreal: m_sethost: user record =
9693 >kddnt not found<BR>[Apr 30 18:44:46 2003] protocol/unreal: m_sethost: =
9695 >record for ombha not found<BR>[Apr 30 18:45:00 2003] protocol/unreal: =
9697 >user record for fAnself not found<BR>[Apr 30 18:45:20 2003] =
9698 >protocol/unreal:=20
9699 >m_sethost: user record for xqejtw not found<BR>[Apr 30 18:45:27 2003]=20
9700 >protocol/unreal: m_sethost: user record for Nikolaus not found<BR>[Apr =
9702 >18:46:10 2003] protocol/unreal: m_sethost: user record for adsur not=20
9703 >found<BR>[Apr 30 18:46:43 2003] protocol/unreal: m_sethost: user record =
9705 >dAdrianc not found<BR>[Apr 30 18:48:35 2003] protocol/unreal: m_sethost: =
9707 >record for cmjdjm2 not found<BR>[Apr 30 18:49:35 2003] protocol/unreal:=20
9708 >m_sethost: user record for [Theo] not found<BR>[Apr 30 18:50:00 2003]=20
9709 >protocol/unreal: m_sethost: user record for ybemj not found =
9711 >30 18:50:04 2003] protocol/unreal: m_sethost: user record for Hardie not =
9713 >found<BR>[Apr 30 18:50:22 2003] protocol/unreal: m_sethost: user record =
9715 >[Odolf] not found<BR>[Apr 30 18:51:12 2003] protocol/unreal: m_sethost: =
9717 >record for Tino not found</FONT></DIV></BODY></HTML>
9719 >------=_NextPart_000_0009_01C30F56.97D971C0--
9722 >--===============22718851767480919==
9723 >Content-Type: text/plain; charset="us-ascii"
9725 >Content-Transfer-Encoding: 7bit
9726 >Content-Disposition: inline
9728 >------------------------------------------------------------------
9729 >To unsubscribe or change your subscription options, visit:
9730 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
9732 >--===============22718851767480919==--
9734 From master at xchat.gr Sat May 17 23:06:47 2003
9735 From: master at xchat.gr (George Stamatiou)
9736 Date: Sat Oct 23 23:09:52 2004
9737 Subject: [IRCServices Coding] XOP List
9738 References: <58753.216.204.85.34.1052262437.squirrel@www.metacraft.com>
9739 <000f01c31ca5$138fd240$6bfecdd4@zeus>
9740 <1053198873.4151.7.camel@dreadnought.hadiko.de>
9741 Message-ID: <001801c31d03$acf460f0$92fc673e@zeus>
9744 But i said in access-xop there is no way doing that :-)
9745 It is working only in access-levels.I have enabled only the access-xop and not the access-levels.
9749 ----- Original Message -----
9750 From: "Yusuf Iskenderoglu" <uhc0@rz.uni-karlsruhe.de>
9751 To: "IRC Services Coding Mailing List" <ircservices-coding@ircservices.za.net>
9752 Sent: Saturday, May 17, 2003 10:14 PM
9753 Subject: Re: [IRCServices Coding] XOP List
9762 : /cs help levels desc
9763 : /cs levels #channel list
9765 : To accomplish that what you are willing to do:
9766 : /cs levels #channel set acc-change 50
9773 : On Sat, 2003-05-17 at 20:49, George Stamatiou wrote:
9775 : > Is there any way to avoid users with no access in that channel to do /cs aop/sop #channel list ?
9777 : > Now, all users are able to do that.
9778 : > I think that only users with AOP or SOP access should be able to do that.
9782 : > George Stamatiou
9785 : > ------------------------------------------------------------------
9786 : > To unsubscribe or change your subscription options, visit:
9787 : > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
9789 : ------------------------------------------------------------------
9790 : | Yusuf Iskenderoglu | You get to meet all sorts, |
9791 : | eMail - uhc0@stud.uni-karlsruhe.de| in this line of work... |
9792 : | eMail - s_iskend@ira.uka.de | |
9793 : | ICQ UIN : 20587464 \ TimeMr14C | |
9794 : ------------------------------------------------------------------
9796 : ------------------------------------------------------------------
9797 : To unsubscribe or change your subscription options, visit:
9798 : http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
9802 From rayfordp at mhonline.net Mon May 19 09:45:38 2003
9803 From: rayfordp at mhonline.net (Rayford Pomeroy)
9804 Date: Sat Oct 23 23:09:52 2004
9805 Subject: [IRCServices Coding] NickServ Callbacks
9806 Message-ID: <JBELJOOEGDOHPGPENBHJOEFFCAAA.rayfordp@mhonline.net>
9810 Im writing a module for services that uses several callbacks. Is there a
9811 call back like nickserv's SET call back but would only get called after the
9812 nick structures have been updated? Ive tried using the NickServ SET
9813 callback but unfortuneatly the structures are not updated and some checks
9814 (such as password length) aren't performed when my module gets called. I
9815 suppose I could mess in nickserv/set.c but I want to avoid modifying any
9816 other modules in order to get mine to work, I suppose I could also have my
9817 module do the checks but I would like to avoid that since nickserv does it
9824 From achurch at achurch.org Mon May 26 14:55:46 2003
9825 From: achurch at achurch.org (Andrew Church)
9826 Date: Sat Oct 23 23:09:52 2004
9827 Subject: [IRCServices Coding] Hybrid support
9828 In-Reply-To: <026572BE.2337F8D0.0CD45FDB@aol.com>
9829 Message-ID: <3ed1ad3f.53514@mail.achurch.org>
9831 >Here's a protocol/hybrid.c that can be used for hyb7. Issues include:
9833 Thanks, I'll look into adding it in when I fork the source for 5.1.
9835 >1) Keeptopic doesn't work right unless m_topic and do_topic are modified =
9836 >directly :/ Hybrid propogates user topics in the same way it recieves the=
9837 >m (:user TOPIC channel :topic). Probably just needs some av=3D2 checking.
9839 You can override the m_xxx() functions in messages.c by adding an
9840 appropriate entry to the protocol's message table:
9842 static void m_hybrid_topic(...) { ... }
9843 static Message hybrid_messages[] = {
9845 { "TOPIC", m_hybrid_topic },
9848 Then just write m_hybrid_topic() so that it passes parameters as do_topic()
9854 From saturn at jetirc.net Wed May 28 12:50:39 2003
9855 From: saturn at jetirc.net (Saturn)
9856 Date: Sat Oct 23 23:09:52 2004
9857 Subject: [IRCServices Coding] Joining empty registered channels
9858 Message-ID: <002101c32552$6ab88750$316419ac@caphealth.org>
9860 Something odd a user reported...... When he joins an EMPTY channel (registered, though), it deops, then ops, then does the topic, then sets a whole mess of modes -- it PROTECTS him, but DEOPS him again!! This makes no sense (AutoOP is set for level 50 on this channel, and the user is level 100).
9867 <+Pyro> [21:07:23] * You have joined #presidenten
9868 <+Pyro> [21:07:23] * services.jetirc.net sets mode: -o Pyro
9869 <+Pyro> [21:07:23] * services.jetirc.net sets mode: +o Pyro
9870 <+Pyro> [21:07:23] * services.jetirc.net changes topic to ' (ChanServ)'
9871 <+Pyro> [21:07:26] * ChanServ sets mode: +ntr-o+a Pyro Pyro
9872 [12:46] -ChanServ- Access list for #presidenten:
9873 [12:46] -ChanServ- Num Lev Nickname
9874 [12:46] -ChanServ- 1 100 Pyro
9876 -------------- next part --------------
9877 An HTML attachment was scrubbed...
9878 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030528/b8dca9d6/attachment.html
9879 From Slowking50 at aol.com Wed May 28 16:04:03 2003
9880 From: Slowking50 at aol.com (Slowking50@aol.com)
9881 Date: Sat Oct 23 23:09:52 2004
9882 Subject: [IRCServices Coding] Joining empty registered channels
9883 Message-ID: <5CD25F81.4D8A6D0E.0CD45FDB@aol.com>
9885 Unreal3.1.5.1-Valek(JetIRC). wdi.jetirc.net CFhiIpnROoXSs [*=2302(H)]
9887 Ew, I hate Unreal 3.1 :P but that's another story.
9889 Anyway, let's parse this:
9891 <+Pyro> [21:07:23] * services.jetirc.net sets mode: -o Pyro
9893 Probably joined before he identified to his nickname, so he wasn't recognized as having access.
9895 <+Pyro> [21:07:23] * services.jetirc.net sets mode: +o Pyro
9899 <+Pyro> [21:07:23] * services.jetirc.net changes topic to ' (ChanServ)'
9903 <+Pyro> [21:07:26] * ChanServ sets mode: +ntr-o+a Pyro Pyro
9905 +ntr is the modelock... +a is level 100... The -o thing is weird though.
9907 I'm trying to recreate it on your network, but unfortunately your services won't send me an auth code :P
9908 From saturn at jetirc.net Wed May 28 16:31:38 2003
9909 From: saturn at jetirc.net (Saturn)
9910 Date: Sat Oct 23 23:09:52 2004
9911 Subject: [IRCServices Coding] Joining empty registered channels
9912 References: <5CD25F81.4D8A6D0E.0CD45FDB@aol.com>
9913 Message-ID: <004a01c32571$493ef220$6401a8c0@turby>
9915 3.1.5.1 is a heckuvalot more stable than 3.2... nevermind that though ok?
9917 I tried it myself too as him. We had both identified ahead of time. It
9918 does this for any channel when you are the first to join... the -o and +o
9919 happens within 1 second of each other.
9921 and yes, the -o thing at the end is the suspected bug ... the services
9922 should be leaving the +o alone, since he is designated level 100 and +o is
9925 As for the auth code, perhaps you typoed the email address? The auth system
9926 is working perfectly, I just tested it.
9931 ----- Original Message -----
9932 From: <Slowking50@aol.com>
9933 To: "IRC Services Coding Mailing List"
9934 <ircservices-coding@ircservices.za.net>
9935 Sent: Wednesday, May 28, 2003 4:04 PM
9936 Subject: Re: [IRCServices Coding] Joining empty registered channels
9939 Unreal3.1.5.1-Valek(JetIRC). wdi.jetirc.net CFhiIpnROoXSs [*=2302(H)]
9941 Ew, I hate Unreal 3.1 :P but that's another story.
9943 Anyway, let's parse this:
9945 <+Pyro> [21:07:23] * services.jetirc.net sets mode: -o Pyro
9947 Probably joined before he identified to his nickname, so he wasn't
9948 recognized as having access.
9950 <+Pyro> [21:07:23] * services.jetirc.net sets mode: +o Pyro
9954 <+Pyro> [21:07:23] * services.jetirc.net changes topic to ' (ChanServ)'
9958 <+Pyro> [21:07:26] * ChanServ sets mode: +ntr-o+a Pyro Pyro
9960 +ntr is the modelock... +a is level 100... The -o thing is weird though.
9962 I'm trying to recreate it on your network, but unfortunately your services
9963 won't send me an auth code :P
9964 ------------------------------------------------------------------
9965 To unsubscribe or change your subscription options, visit:
9966 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
9970 From achurch at achurch.org Thu May 29 08:31:56 2003
9971 From: achurch at achurch.org (Andrew Church)
9972 Date: Sat Oct 23 23:09:52 2004
9973 Subject: [IRCServices Coding] Joining empty registered channels
9974 In-Reply-To: <002101c32552$6ab88750$316419ac@caphealth.org>
9975 Message-ID: <3ed5481a.44471@mail.achurch.org>
9977 >Something odd a user reported...... When he joins an EMPTY channel =
9978 >(registered, though), it deops, then ops, then does the topic, then sets =
9979 >a whole mess of modes -- it PROTECTS him, but DEOPS him again!! This =
9980 >makes no sense (AutoOP is set for level 50 on this channel, and the user =
9983 I can't reproduce this with 5.0.18. (The initial -o and +o are due
9984 to channel time setting, CSSetChannelTime in modules.conf.) What options
9985 are set for the channel?
9990 From saturn at jetirc.net Wed May 28 16:39:43 2003
9991 From: saturn at jetirc.net (Saturn)
9992 Date: Sat Oct 23 23:09:52 2004
9993 Subject: [IRCServices Coding] Joining empty registered channels
9994 References: <3ed5481a.44471@mail.achurch.org>
9995 Message-ID: <006801c32572$6a892c60$6401a8c0@turby>
9997 I am runnign 5.0.16 ... I will try updating to 18 and see if that solves it
10000 options for channel are just the default ones.
10002 ----- Original Message -----
10003 From: "Andrew Church" <achurch@achurch.org>
10004 To: <ircservices-coding@ircservices.za.net>
10005 Sent: Wednesday, May 28, 2003 4:31 PM
10006 Subject: Re: [IRCServices Coding] Joining empty registered channels
10009 >Something odd a user reported...... When he joins an EMPTY channel =
10010 >(registered, though), it deops, then ops, then does the topic, then sets =
10011 >a whole mess of modes -- it PROTECTS him, but DEOPS him again!! This =
10012 >makes no sense (AutoOP is set for level 50 on this channel, and the user =
10015 I can't reproduce this with 5.0.18. (The initial -o and +o are due
10016 to channel time setting, CSSetChannelTime in modules.conf.) What options
10017 are set for the channel?
10020 achurch@achurch.org
10021 http://achurch.org/
10022 ------------------------------------------------------------------
10023 To unsubscribe or change your subscription options, visit:
10024 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
10028 From saturn at jetirc.net Wed May 28 17:09:48 2003
10029 From: saturn at jetirc.net (Saturn)
10030 Date: Sat Oct 23 23:09:52 2004
10031 Subject: [IRCServices Coding] Joining empty registered channels
10032 References: <3ed5481a.44471@mail.achurch.org>
10033 Message-ID: <007001c32576$9e595890$6401a8c0@turby>
10035 Upgrading to 5.0.18 solved it... sorry, I'll be sure to update to the latest
10036 version next time before I start complaining =)
10038 ----- Original Message -----
10039 From: "Andrew Church" <achurch@achurch.org>
10040 To: <ircservices-coding@ircservices.za.net>
10041 Sent: Wednesday, May 28, 2003 4:31 PM
10042 Subject: Re: [IRCServices Coding] Joining empty registered channels
10045 >Something odd a user reported...... When he joins an EMPTY channel =
10046 >(registered, though), it deops, then ops, then does the topic, then sets =
10047 >a whole mess of modes -- it PROTECTS him, but DEOPS him again!! This =
10048 >makes no sense (AutoOP is set for level 50 on this channel, and the user =
10051 I can't reproduce this with 5.0.18. (The initial -o and +o are due
10052 to channel time setting, CSSetChannelTime in modules.conf.) What options
10053 are set for the channel?
10056 achurch@achurch.org
10057 http://achurch.org/
10058 ------------------------------------------------------------------
10059 To unsubscribe or change your subscription options, visit:
10060 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
10064 From griever at t2n.org Wed May 28 23:32:39 2003
10065 From: griever at t2n.org (Finny Merrill)
10066 Date: Sat Oct 23 23:09:52 2004
10067 Subject: [IRCServices Coding] Joining empty registered channels
10068 In-Reply-To: <5CD25F81.4D8A6D0E.0CD45FDB@aol.com>
10069 References: <5CD25F81.4D8A6D0E.0CD45FDB@aol.com>
10070 Message-ID: <oprpw8gpka3wwnu9@mail-hub.optonline.net>
10072 On Wed, 28 May 2003 19:04:03 -0400, <Slowking50@aol.com> wrote:
10074 > Unreal3.1.5.1-Valek(JetIRC). wdi.jetirc.net CFhiIpnROoXSs [*=2302(H)]
10076 > Ew, I hate Unreal 3.1 :P but that's another story.
10078 > Anyway, let's parse this:
10080 > <+Pyro> [21:07:23] * services.jetirc.net sets mode: -o Pyro
10082 > Probably joined before he identified to his nickname, so he wasn't
10083 > recognized as having access.
10086 Notice the next line happens the same second. Also notice that the mode
10087 setter is not chanserv but services.jetirc.net.
10089 From laser at musichat.net Thu May 29 04:21:11 2003
10090 From: laser at musichat.net (Alessandro Ciappei)
10091 Date: Sat Oct 23 23:09:52 2004
10092 Subject: [IRCServices Coding] mysql
10093 In-Reply-To: <20030529100003.DE17317098@snow.fingers.co.za>
10094 Message-ID: <BNEPLNAFODLPMAECJEOBOEBPCAAA.laser@musichat.net>
10099 services now, not support database mysql, someone have some patch for this?
10104 From Gizm0 at ad2u.gr Fri May 30 00:31:01 2003
10105 From: Gizm0 at ad2u.gr (Gizm0)
10106 Date: Sat Oct 23 23:09:52 2004
10107 Subject: [IRCServices Coding] mysql
10108 In-Reply-To: <BNEPLNAFODLPMAECJEOBOEBPCAAA.laser@musichat.net>
10109 References: <BNEPLNAFODLPMAECJEOBOEBPCAAA.laser@musichat.net>
10110 Message-ID: <1054279861.3ed708b585f67@webmail.ad2u.gr>
10112 Quoting Alessandro Ciappei <laser@musichat.net>:
10117 > services now, not support database mysql, someone have some patch for this?
10122 Just read the mailing list's archive file... we've discussed this 100 of
10123 times..as far as i know there is only one patch in the wild.. read the archive
10124 and you'll come over the url.. (:
10128 Brain? No route to host...
10130 From laser at musichat.net Sat May 31 06:10:50 2003
10131 From: laser at musichat.net (Alessandro Ciappei)
10132 Date: Sat Oct 23 23:09:52 2004
10133 Subject: [IRCServices Coding] Mysql Modules
10134 Message-ID: <BNEPLNAFODLPMAECJEOBIECCCAAA.laser@musichat.net>
10138 I try to compile services with mysql module, I found in list-archive, but I
10141 make[2]: Entering directory
10142 `/home/services/ircservices-5.0.19/modules/mysql'
10143 gcc -DSTATIC_MODULES -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes
10144 -I../.. -Dmodule_version=module_version_mysql_main -Dmodule_config=module_co
10145 nfig_mysql_main -Dinit_module=init_module_mysql_main -Dexit_module=exit_modu
10146 le_mysql_main -c main.c -o main_static.o
10148 make[4]: Nothing to be done for `/usr/lib/mysql/libmysqlclient.a'.
10149 ar -cru .mysql.a main_static.o /usr/lib/mysql/libmysqlclient.a
10150 /usr/lib/mysql/libmysqlclient.a: invalid use of EXPORT_xxx
10151 make[3]: *** [main.a] Error 1
10152 make[2]: *** [main.a] Error 2
10153 make[2]: Leaving directory `/home/services/ircservices-5.0.19/modules/mysql'
10154 make[1]: *** [all-static] Error 2
10155 make[1]: Leaving directory `/home/services/ircservices-5.0.19/modules'
10156 make: *** [modules] Error 2
10157 [services@lists ircservices-5.0.19]$
10160 someone can helpme?
10166 From griever at t2n.org Sat May 31 13:41:34 2003
10167 From: griever at t2n.org (Finny Merrill)
10168 Date: Sat Oct 23 23:09:52 2004
10169 Subject: [IRCServices Coding] Mysql Modules
10170 In-Reply-To: <BNEPLNAFODLPMAECJEOBIECCCAAA.laser@musichat.net>
10171 References: <BNEPLNAFODLPMAECJEOBIECCCAAA.laser@musichat.net>
10172 Message-ID: <oprp103ks63wwnu9@mail-hub.optonline.net>
10174 On Sat, 31 May 2003 15:10:50 +0200, Alessandro Ciappei <laser@musichat.net>
10179 > I try to compile services with mysql module, I found in list-archive, but
10183 > someone can helpme?
10190 maybe telling us which mysql module would help, and perhaps emailing the
10194 From laser at musichat.net Sun Jun 1 08:19:04 2003
10195 From: laser at musichat.net (Alessandro Ciappei)
10196 Date: Sat Oct 23 23:09:52 2004
10197 Subject: [IRCServices Coding] Mysql Module
10198 In-Reply-To: <20030601100007.A419217095@snow.fingers.co.za>
10199 Message-ID: <BNEPLNAFODLPMAECJEOBMECDCAAA.laser@musichat.net>
10201 The services souce from here
10203 http://www.luxusbuerg.lu/data/ircservices-luxusbuerg.tgz
10205 The mysql table from here
10207 http://www.luxusbuerg.lu/data/sql.tgz
10214 Date: Sat, 31 May 2003 15:10:50 +0200
10215 From: "Alessandro Ciappei" <laser@musichat.net>
10216 Subject: [IRCServices Coding] Mysql Modules
10217 To: "Ircservices-Coding@Ircservices. Za. Net"
10218 <ircservices-coding@ircservices.za.net>
10219 Message-ID: <BNEPLNAFODLPMAECJEOBIECCCAAA.laser@musichat.net>
10220 Content-Type: text/plain; charset="iso-8859-1"
10224 I try to compile services with mysql module, I found in list-archive, but I
10227 make[2]: Entering directory
10228 `/home/services/ircservices-5.0.19/modules/mysql'
10229 gcc -DSTATIC_MODULES -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes
10230 -I../.. -Dmodule_version=module_version_mysql_main -Dmodule_config=module_co
10231 nfig_mysql_main -Dinit_module=init_module_mysql_main -Dexit_module=exit_modu
10232 le_mysql_main -c main.c -o main_static.o
10234 make[4]: Nothing to be done for `/usr/lib/mysql/libmysqlclient.a'.
10235 ar -cru .mysql.a main_static.o /usr/lib/mysql/libmysqlclient.a
10236 /usr/lib/mysql/libmysqlclient.a: invalid use of EXPORT_xxx
10237 make[3]: *** [main.a] Error 1
10238 make[2]: *** [main.a] Error 2
10239 make[2]: Leaving directory `/home/services/ircservices-5.0.19/modules/mysql'
10240 make[1]: *** [all-static] Error 2
10241 make[1]: Leaving directory `/home/services/ircservices-5.0.19/modules'
10242 make: *** [modules] Error 2
10243 [services@lists ircservices-5.0.19]$
10246 someone can helpme?
10252 From georges at berscheid.lu Sun Jun 1 09:50:12 2003
10253 From: georges at berscheid.lu (Georges Berscheid)
10254 Date: Sat Oct 23 23:09:52 2004
10255 Subject: AW: [IRCServices Coding] Mysql Module
10256 In-Reply-To: <BNEPLNAFODLPMAECJEOBMECDCAAA.laser@musichat.net>
10257 Message-ID: <001001c3285d$df5a9130$3ec918d4@gizmo>
10261 maybe you should try to build services with dynamic modules, because the
10262 mysql module is known to compile as a dynamic module.
10266 -----Urspr?ngliche Nachricht-----
10267 Von: ircservices-coding-bounces@ircservices.za.net
10268 [mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
10270 Gesendet: Sonntag, 1. Juni 2003 17:19
10271 An: ircservices-coding@ircservices.za.net
10272 Betreff: [IRCServices Coding] Mysql Module
10275 The services souce from here
10277 http://www.luxusbuerg.lu/data/ircservices-luxusbuerg.tgz
10279 The mysql table from here
10281 http://www.luxusbuerg.lu/data/sql.tgz
10288 Date: Sat, 31 May 2003 15:10:50 +0200
10289 From: "Alessandro Ciappei" <laser@musichat.net>
10290 Subject: [IRCServices Coding] Mysql Modules
10291 To: "Ircservices-Coding@Ircservices. Za. Net"
10292 <ircservices-coding@ircservices.za.net>
10293 Message-ID: <BNEPLNAFODLPMAECJEOBIECCCAAA.laser@musichat.net>
10294 Content-Type: text/plain; charset="iso-8859-1"
10298 I try to compile services with mysql module, I found in list-archive,
10302 make[2]: Entering directory
10303 `/home/services/ircservices-5.0.19/modules/mysql'
10304 gcc -DSTATIC_MODULES -O2 -fno-strict-aliasing -g -Wall
10305 -Wmissing-prototypes
10306 -I../.. -Dmodule_version=module_version_mysql_main
10307 -Dmodule_config=module_co
10308 nfig_mysql_main -Dinit_module=init_module_mysql_main
10309 -Dexit_module=exit_modu
10310 le_mysql_main -c main.c -o main_static.o
10312 make[4]: Nothing to be done for `/usr/lib/mysql/libmysqlclient.a'.
10313 ar -cru .mysql.a main_static.o /usr/lib/mysql/libmysqlclient.a
10314 /usr/lib/mysql/libmysqlclient.a: invalid use of EXPORT_xxx
10315 make[3]: *** [main.a] Error 1
10316 make[2]: *** [main.a] Error 2
10317 make[2]: Leaving directory
10318 `/home/services/ircservices-5.0.19/modules/mysql'
10319 make[1]: *** [all-static] Error 2
10320 make[1]: Leaving directory `/home/services/ircservices-5.0.19/modules'
10321 make: *** [modules] Error 2
10322 [services@lists ircservices-5.0.19]$
10325 someone can helpme?
10331 ------------------------------------------------------------------
10332 To unsubscribe or change your subscription options, visit:
10333 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
10336 From laser at musichat.net Mon Jun 2 05:35:14 2003
10337 From: laser at musichat.net (Alessandro Ciappei)
10338 Date: Sat Oct 23 23:09:52 2004
10339 Subject: [IRCServices Coding] mysql modules
10340 In-Reply-To: <20030602100003.83CC11706E@snow.fingers.co.za>
10341 Message-ID: <BNEPLNAFODLPMAECJEOBMECECAAA.laser@musichat.net>
10343 It's compiling, but i see this:
10346 make[2]: Entering directory
10347 `/home/services/ircservices-5.0.19/modules/mysql'
10348 gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -I../.. -c
10351 make[4]: Nothing to be done for `/usr/lib/mysql/libmysqlclient.a'.
10352 gcc -shared main.o /usr/lib/mysql/libmysqlclient.a -o main.so
10353 make[2]: Leaving directory `/home/services/ircservices-5.0.19/modules/mysql'
10358 make[2]: Entering directory
10359 `/home/services/ircservices-5.0.19/modules/mysql'
10360 make[4]: Nothing to be done for `/usr/lib/mysql/libmysqlclient.a'.
10361 make[2]: Leaving directory `/home/services/ircservices-5.0.19/modules/mysql'
10364 and when i start services in log i see:
10366 [Jun 02 14:26:20 2003] IRC Services 5.0.19 starting up
10367 [Jun 02 14:26:21 2003] modules: Unable to load module `mysql/main':
10368 /home/services/sviluppo/lib/modules/mysql/main.so: undefined symbol: unco$
10369 [Jun 02 14:26:21 2003] Error loading modules, aborting
10377 Date: Sun, 1 Jun 2003 17:19:04 +0200
10378 From: "Alessandro Ciappei" <laser@musichat.net>
10379 Subject: [IRCServices Coding] Mysql Module
10380 To: <ircservices-coding@ircservices.za.net>
10381 Message-ID: <BNEPLNAFODLPMAECJEOBMECDCAAA.laser@musichat.net>
10382 Content-Type: text/plain; charset="us-ascii"
10384 The services souce from here
10386 http://www.luxusbuerg.lu/data/ircservices-luxusbuerg.tgz
10388 The mysql table from here
10390 http://www.luxusbuerg.lu/data/sql.tgz
10397 Date: Sat, 31 May 2003 15:10:50 +0200
10398 From: "Alessandro Ciappei" <laser@musichat.net>
10399 Subject: [IRCServices Coding] Mysql Modules
10400 To: "Ircservices-Coding@Ircservices. Za. Net"
10401 <ircservices-coding@ircservices.za.net>
10402 Message-ID: <BNEPLNAFODLPMAECJEOBIECCCAAA.laser@musichat.net>
10403 Content-Type: text/plain; charset="iso-8859-1"
10407 I try to compile services with mysql module, I found in list-archive, but I
10410 make[2]: Entering directory
10411 `/home/services/ircservices-5.0.19/modules/mysql'
10412 gcc -DSTATIC_MODULES -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes
10413 -I../.. -Dmodule_version=module_version_mysql_main -Dmodule_config=module_co
10414 nfig_mysql_main -Dinit_module=init_module_mysql_main -Dexit_module=exit_modu
10415 le_mysql_main -c main.c -o main_static.o
10417 make[4]: Nothing to be done for `/usr/lib/mysql/libmysqlclient.a'.
10418 ar -cru .mysql.a main_static.o /usr/lib/mysql/libmysqlclient.a
10419 /usr/lib/mysql/libmysqlclient.a: invalid use of EXPORT_xxx
10420 make[3]: *** [main.a] Error 1
10421 make[2]: *** [main.a] Error 2
10422 make[2]: Leaving directory `/home/services/ircservices-5.0.19/modules/mysql'
10423 make[1]: *** [all-static] Error 2
10424 make[1]: Leaving directory `/home/services/ircservices-5.0.19/modules'
10425 make: *** [modules] Error 2
10426 [services@lists ircservices-5.0.19]$
10429 someone can helpme?
10436 ------------------------------
10439 Date: Sun, 1 Jun 2003 18:50:12 +0200
10440 From: "Georges Berscheid" <georges@berscheid.lu>
10441 Subject: AW: [IRCServices Coding] Mysql Module
10442 To: "'IRC Services Coding Mailing List'"
10443 <ircservices-coding@ircservices.za.net>
10444 Message-ID: <001001c3285d$df5a9130$3ec918d4@gizmo>
10445 Content-Type: text/plain; charset="iso-8859-1"
10449 maybe you should try to build services with dynamic modules, because the
10450 mysql module is known to compile as a dynamic module.
10454 -----Urspr|ngliche Nachricht-----
10455 Von: ircservices-coding-bounces@ircservices.za.net
10456 [mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
10458 Gesendet: Sonntag, 1. Juni 2003 17:19
10459 An: ircservices-coding@ircservices.za.net
10460 Betreff: [IRCServices Coding] Mysql Module
10463 The services souce from here
10465 http://www.luxusbuerg.lu/data/ircservices-luxusbuerg.tgz
10467 The mysql table from here
10469 http://www.luxusbuerg.lu/data/sql.tgz
10476 Date: Sat, 31 May 2003 15:10:50 +0200
10477 From: "Alessandro Ciappei" <laser@musichat.net>
10478 Subject: [IRCServices Coding] Mysql Modules
10479 To: "Ircservices-Coding@Ircservices. Za. Net"
10480 <ircservices-coding@ircservices.za.net>
10481 Message-ID: <BNEPLNAFODLPMAECJEOBIECCCAAA.laser@musichat.net>
10482 Content-Type: text/plain; charset="iso-8859-1"
10486 I try to compile services with mysql module, I found in list-archive,
10490 make[2]: Entering directory
10491 `/home/services/ircservices-5.0.19/modules/mysql'
10492 gcc -DSTATIC_MODULES -O2 -fno-strict-aliasing -g -Wall
10493 -Wmissing-prototypes
10494 -I../.. -Dmodule_version=module_version_mysql_main
10495 -Dmodule_config=module_co
10496 nfig_mysql_main -Dinit_module=init_module_mysql_main
10497 -Dexit_module=exit_modu
10498 le_mysql_main -c main.c -o main_static.o
10500 make[4]: Nothing to be done for `/usr/lib/mysql/libmysqlclient.a'.
10501 ar -cru .mysql.a main_static.o /usr/lib/mysql/libmysqlclient.a
10502 /usr/lib/mysql/libmysqlclient.a: invalid use of EXPORT_xxx
10503 make[3]: *** [main.a] Error 1
10504 make[2]: *** [main.a] Error 2
10505 make[2]: Leaving directory
10506 `/home/services/ircservices-5.0.19/modules/mysql'
10507 make[1]: *** [all-static] Error 2
10508 make[1]: Leaving directory `/home/services/ircservices-5.0.19/modules'
10509 make: *** [modules] Error 2
10510 [services@lists ircservices-5.0.19]$
10513 someone can helpme?
10519 ------------------------------------------------------------------
10520 To unsubscribe or change your subscription options, visit:
10521 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
10525 ------------------------------
10527 _______________________________________________
10528 IRCServices-Coding mailing list
10529 IRCServices-Coding@ircservices.za.net
10530 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
10533 End of IRCServices-Coding Digest, Vol 5, Issue 2
10534 ************************************************
10536 From georges at berscheid.lu Mon Jun 2 05:32:52 2003
10537 From: georges at berscheid.lu (Georges Berscheid)
10538 Date: Sat Oct 23 23:09:52 2004
10539 Subject: [IRCServices Coding] mysql modules
10540 References: <BNEPLNAFODLPMAECJEOBMECECAAA.laser@musichat.net>
10541 Message-ID: <3EDB43F4.5070306@berscheid.lu>
10548 >/home/services/sviluppo/lib/modules/mysql/main.so: undefined symbol: unco$
10553 I suppose that line says: undefined symbol: uncompress.
10554 Just link zlib to your binary by adding -lz to the LIBS line in
10555 Makefile.inc. Some newer mysqlclient libraries need compress/uncompress
10560 From laser at musichat.net Wed Jun 4 09:41:16 2003
10561 From: laser at musichat.net (Alessandro Ciappei)
10562 Date: Sat Oct 23 23:09:52 2004
10563 Subject: [IRCServices Coding] R: IRCServices-Coding Digest, Vol 5, Issue 3
10564 In-Reply-To: <20030603100005.145A717078@snow.fingers.co.za>
10565 Message-ID: <BNEPLNAFODLPMAECJEOBGECGCAAA.laser@musichat.net>
10567 i try with flag -lz but this is the error:
10569 /usr/bin/ld: cannot find -lz
10570 collect2: ld returned 1 exit status
10571 make: *** [ircservices] Error 1
10578 Date: Mon, 2 Jun 2003 14:35:14 +0200
10579 From: "Alessandro Ciappei" <laser@musichat.net>
10580 Subject: [IRCServices Coding] mysql modules
10581 To: <ircservices-coding@ircservices.za.net>
10582 Message-ID: <BNEPLNAFODLPMAECJEOBMECECAAA.laser@musichat.net>
10583 Content-Type: text/plain; charset="us-ascii"
10585 It's compiling, but i see this:
10588 make[2]: Entering directory
10589 `/home/services/ircservices-5.0.19/modules/mysql'
10590 gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -I../.. -c
10593 make[4]: Nothing to be done for `/usr/lib/mysql/libmysqlclient.a'.
10594 gcc -shared main.o /usr/lib/mysql/libmysqlclient.a -o main.so
10595 make[2]: Leaving directory `/home/services/ircservices-5.0.19/modules/mysql'
10600 make[2]: Entering directory
10601 `/home/services/ircservices-5.0.19/modules/mysql'
10602 make[4]: Nothing to be done for `/usr/lib/mysql/libmysqlclient.a'.
10603 make[2]: Leaving directory `/home/services/ircservices-5.0.19/modules/mysql'
10606 and when i start services in log i see:
10608 [Jun 02 14:26:20 2003] IRC Services 5.0.19 starting up
10609 [Jun 02 14:26:21 2003] modules: Unable to load module `mysql/main':
10610 /home/services/sviluppo/lib/modules/mysql/main.so: undefined symbol: unco$
10611 [Jun 02 14:26:21 2003] Error loading modules, aborting
10619 Date: Sun, 1 Jun 2003 17:19:04 +0200
10620 From: "Alessandro Ciappei" <laser@musichat.net>
10621 Subject: [IRCServices Coding] Mysql Module
10622 To: <ircservices-coding@ircservices.za.net>
10623 Message-ID: <BNEPLNAFODLPMAECJEOBMECDCAAA.laser@musichat.net>
10624 Content-Type: text/plain; charset="us-ascii"
10626 The services souce from here
10628 http://www.luxusbuerg.lu/data/ircservices-luxusbuerg.tgz
10630 The mysql table from here
10632 http://www.luxusbuerg.lu/data/sql.tgz
10639 Date: Sat, 31 May 2003 15:10:50 +0200
10640 From: "Alessandro Ciappei" <laser@musichat.net>
10641 Subject: [IRCServices Coding] Mysql Modules
10642 To: "Ircservices-Coding@Ircservices. Za. Net"
10643 <ircservices-coding@ircservices.za.net>
10644 Message-ID: <BNEPLNAFODLPMAECJEOBIECCCAAA.laser@musichat.net>
10645 Content-Type: text/plain; charset="iso-8859-1"
10649 I try to compile services with mysql module, I found in list-archive, but I
10652 make[2]: Entering directory
10653 `/home/services/ircservices-5.0.19/modules/mysql'
10654 gcc -DSTATIC_MODULES -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes
10655 -I../.. -Dmodule_version=module_version_mysql_main -Dmodule_config=module_co
10656 nfig_mysql_main -Dinit_module=init_module_mysql_main -Dexit_module=exit_modu
10657 le_mysql_main -c main.c -o main_static.o
10659 make[4]: Nothing to be done for `/usr/lib/mysql/libmysqlclient.a'.
10660 ar -cru .mysql.a main_static.o /usr/lib/mysql/libmysqlclient.a
10661 /usr/lib/mysql/libmysqlclient.a: invalid use of EXPORT_xxx
10662 make[3]: *** [main.a] Error 1
10663 make[2]: *** [main.a] Error 2
10664 make[2]: Leaving directory `/home/services/ircservices-5.0.19/modules/mysql'
10665 make[1]: *** [all-static] Error 2
10666 make[1]: Leaving directory `/home/services/ircservices-5.0.19/modules'
10667 make: *** [modules] Error 2
10668 [services@lists ircservices-5.0.19]$
10671 someone can helpme?
10678 ------------------------------
10681 Date: Sun, 1 Jun 2003 18:50:12 +0200
10682 From: "Georges Berscheid" <georges@berscheid.lu>
10683 Subject: AW: [IRCServices Coding] Mysql Module
10684 To: "'IRC Services Coding Mailing List'"
10685 <ircservices-coding@ircservices.za.net>
10686 Message-ID: <001001c3285d$df5a9130$3ec918d4@gizmo>
10687 Content-Type: text/plain; charset="iso-8859-1"
10691 maybe you should try to build services with dynamic modules, because the
10692 mysql module is known to compile as a dynamic module.
10696 -----Urspr|ngliche Nachricht-----
10697 Von: ircservices-coding-bounces@ircservices.za.net
10698 [mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
10700 Gesendet: Sonntag, 1. Juni 2003 17:19
10701 An: ircservices-coding@ircservices.za.net
10702 Betreff: [IRCServices Coding] Mysql Module
10705 The services souce from here
10707 http://www.luxusbuerg.lu/data/ircservices-luxusbuerg.tgz
10709 The mysql table from here
10711 http://www.luxusbuerg.lu/data/sql.tgz
10718 Date: Sat, 31 May 2003 15:10:50 +0200
10719 From: "Alessandro Ciappei" <laser@musichat.net>
10720 Subject: [IRCServices Coding] Mysql Modules
10721 To: "Ircservices-Coding@Ircservices. Za. Net"
10722 <ircservices-coding@ircservices.za.net>
10723 Message-ID: <BNEPLNAFODLPMAECJEOBIECCCAAA.laser@musichat.net>
10724 Content-Type: text/plain; charset="iso-8859-1"
10728 I try to compile services with mysql module, I found in list-archive,
10732 make[2]: Entering directory
10733 `/home/services/ircservices-5.0.19/modules/mysql'
10734 gcc -DSTATIC_MODULES -O2 -fno-strict-aliasing -g -Wall
10735 -Wmissing-prototypes
10736 -I../.. -Dmodule_version=module_version_mysql_main
10737 -Dmodule_config=module_co
10738 nfig_mysql_main -Dinit_module=init_module_mysql_main
10739 -Dexit_module=exit_modu
10740 le_mysql_main -c main.c -o main_static.o
10742 make[4]: Nothing to be done for `/usr/lib/mysql/libmysqlclient.a'.
10743 ar -cru .mysql.a main_static.o /usr/lib/mysql/libmysqlclient.a
10744 /usr/lib/mysql/libmysqlclient.a: invalid use of EXPORT_xxx
10745 make[3]: *** [main.a] Error 1
10746 make[2]: *** [main.a] Error 2
10747 make[2]: Leaving directory
10748 `/home/services/ircservices-5.0.19/modules/mysql'
10749 make[1]: *** [all-static] Error 2
10750 make[1]: Leaving directory `/home/services/ircservices-5.0.19/modules'
10751 make: *** [modules] Error 2
10752 [services@lists ircservices-5.0.19]$
10755 someone can helpme?
10761 ------------------------------------------------------------------
10762 To unsubscribe or change your subscription options, visit:
10763 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
10767 ------------------------------
10769 _______________________________________________
10770 IRCServices-Coding mailing list
10771 IRCServices-Coding@ircservices.za.net
10772 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
10775 End of IRCServices-Coding Digest, Vol 5, Issue 2
10776 ************************************************
10779 ------------------------------
10782 Date: Mon, 02 Jun 2003 14:32:52 +0200
10783 From: Georges Berscheid <georges@berscheid.lu>
10784 Subject: Re: [IRCServices Coding] mysql modules
10785 To: IRC Services Coding Mailing List
10786 <ircservices-coding@ircservices.za.net>
10787 Message-ID: <3EDB43F4.5070306@berscheid.lu>
10788 Content-Type: text/plain; charset=us-ascii; format=flowed
10795 >/home/services/sviluppo/lib/modules/mysql/main.so: undefined symbol: unco$
10800 I suppose that line says: undefined symbol: uncompress.
10801 Just link zlib to your binary by adding -lz to the LIBS line in
10802 Makefile.inc. Some newer mysqlclient libraries need compress/uncompress
10808 ------------------------------
10810 _______________________________________________
10811 IRCServices-Coding mailing list
10812 IRCServices-Coding@ircservices.za.net
10813 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
10816 End of IRCServices-Coding Digest, Vol 5, Issue 3
10817 ************************************************
10819 From georges at berscheid.lu Wed Jun 4 11:17:57 2003
10820 From: georges at berscheid.lu (Georges Berscheid)
10821 Date: Sat Oct 23 23:09:53 2004
10822 Subject: AW: [IRCServices Coding] R: IRCServices-Coding Digest, Vol 5, Issue 3
10823 In-Reply-To: <BNEPLNAFODLPMAECJEOBGECGCAAA.laser@musichat.net>
10824 Message-ID: <000001c32ac5$9feae080$4dbbf683@globi>
10826 Install zlib from http://www.gzip.org/zlib/.
10827 But I must admin that I have not seen a system without zlib for a very
10832 -----Urspr?ngliche Nachricht-----
10833 Von: ircservices-coding-bounces@ircservices.za.net
10834 [mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
10836 Gesendet: Mittwoch, 4. Juni 2003 18:41
10837 An: ircservices-coding@ircservices.za.net
10838 Betreff: [IRCServices Coding] R: IRCServices-Coding Digest, Vol 5, Issue
10842 i try with flag -lz but this is the error:
10844 /usr/bin/ld: cannot find -lz
10845 collect2: ld returned 1 exit status
10846 make: *** [ircservices] Error 1
10853 Date: Mon, 2 Jun 2003 14:35:14 +0200
10854 From: "Alessandro Ciappei" <laser@musichat.net>
10855 Subject: [IRCServices Coding] mysql modules
10856 To: <ircservices-coding@ircservices.za.net>
10857 Message-ID: <BNEPLNAFODLPMAECJEOBMECECAAA.laser@musichat.net>
10858 Content-Type: text/plain; charset="us-ascii"
10860 It's compiling, but i see this:
10863 make[2]: Entering directory
10864 `/home/services/ircservices-5.0.19/modules/mysql'
10865 gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -I../.. -c
10868 make[4]: Nothing to be done for `/usr/lib/mysql/libmysqlclient.a'.
10869 gcc -shared main.o /usr/lib/mysql/libmysqlclient.a -o main.so
10870 make[2]: Leaving directory
10871 `/home/services/ircservices-5.0.19/modules/mysql'
10876 make[2]: Entering directory
10877 `/home/services/ircservices-5.0.19/modules/mysql'
10878 make[4]: Nothing to be done for `/usr/lib/mysql/libmysqlclient.a'.
10879 make[2]: Leaving directory
10880 `/home/services/ircservices-5.0.19/modules/mysql'
10883 and when i start services in log i see:
10885 [Jun 02 14:26:20 2003] IRC Services 5.0.19 starting up
10886 [Jun 02 14:26:21 2003] modules: Unable to load module `mysql/main':
10887 /home/services/sviluppo/lib/modules/mysql/main.so: undefined symbol:
10889 [Jun 02 14:26:21 2003] Error loading modules, aborting
10897 Date: Sun, 1 Jun 2003 17:19:04 +0200
10898 From: "Alessandro Ciappei" <laser@musichat.net>
10899 Subject: [IRCServices Coding] Mysql Module
10900 To: <ircservices-coding@ircservices.za.net>
10901 Message-ID: <BNEPLNAFODLPMAECJEOBMECDCAAA.laser@musichat.net>
10902 Content-Type: text/plain; charset="us-ascii"
10904 The services souce from here
10906 http://www.luxusbuerg.lu/data/ircservices-luxusbuerg.tgz
10908 The mysql table from here
10910 http://www.luxusbuerg.lu/data/sql.tgz
10917 Date: Sat, 31 May 2003 15:10:50 +0200
10918 From: "Alessandro Ciappei" <laser@musichat.net>
10919 Subject: [IRCServices Coding] Mysql Modules
10920 To: "Ircservices-Coding@Ircservices. Za. Net"
10921 <ircservices-coding@ircservices.za.net>
10922 Message-ID: <BNEPLNAFODLPMAECJEOBIECCCAAA.laser@musichat.net>
10923 Content-Type: text/plain; charset="iso-8859-1"
10927 I try to compile services with mysql module, I found in list-archive,
10931 make[2]: Entering directory
10932 `/home/services/ircservices-5.0.19/modules/mysql'
10933 gcc -DSTATIC_MODULES -O2 -fno-strict-aliasing -g -Wall
10934 -Wmissing-prototypes
10935 -I../.. -Dmodule_version=module_version_mysql_main
10936 -Dmodule_config=module_co
10937 nfig_mysql_main -Dinit_module=init_module_mysql_main
10938 -Dexit_module=exit_modu
10939 le_mysql_main -c main.c -o main_static.o
10941 make[4]: Nothing to be done for `/usr/lib/mysql/libmysqlclient.a'.
10942 ar -cru .mysql.a main_static.o /usr/lib/mysql/libmysqlclient.a
10943 /usr/lib/mysql/libmysqlclient.a: invalid use of EXPORT_xxx
10944 make[3]: *** [main.a] Error 1
10945 make[2]: *** [main.a] Error 2
10946 make[2]: Leaving directory
10947 `/home/services/ircservices-5.0.19/modules/mysql'
10948 make[1]: *** [all-static] Error 2
10949 make[1]: Leaving directory `/home/services/ircservices-5.0.19/modules'
10950 make: *** [modules] Error 2
10951 [services@lists ircservices-5.0.19]$
10954 someone can helpme?
10961 ------------------------------
10964 Date: Sun, 1 Jun 2003 18:50:12 +0200
10965 From: "Georges Berscheid" <georges@berscheid.lu>
10966 Subject: AW: [IRCServices Coding] Mysql Module
10967 To: "'IRC Services Coding Mailing List'"
10968 <ircservices-coding@ircservices.za.net>
10969 Message-ID: <001001c3285d$df5a9130$3ec918d4@gizmo>
10970 Content-Type: text/plain; charset="iso-8859-1"
10974 maybe you should try to build services with dynamic modules, because the
10975 mysql module is known to compile as a dynamic module.
10979 -----Urspr|ngliche Nachricht-----
10980 Von: ircservices-coding-bounces@ircservices.za.net
10981 [mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
10983 Gesendet: Sonntag, 1. Juni 2003 17:19
10984 An: ircservices-coding@ircservices.za.net
10985 Betreff: [IRCServices Coding] Mysql Module
10988 The services souce from here
10990 http://www.luxusbuerg.lu/data/ircservices-luxusbuerg.tgz
10992 The mysql table from here
10994 http://www.luxusbuerg.lu/data/sql.tgz
11001 Date: Sat, 31 May 2003 15:10:50 +0200
11002 From: "Alessandro Ciappei" <laser@musichat.net>
11003 Subject: [IRCServices Coding] Mysql Modules
11004 To: "Ircservices-Coding@Ircservices. Za. Net"
11005 <ircservices-coding@ircservices.za.net>
11006 Message-ID: <BNEPLNAFODLPMAECJEOBIECCCAAA.laser@musichat.net>
11007 Content-Type: text/plain; charset="iso-8859-1"
11011 I try to compile services with mysql module, I found in list-archive,
11015 make[2]: Entering directory
11016 `/home/services/ircservices-5.0.19/modules/mysql'
11017 gcc -DSTATIC_MODULES -O2 -fno-strict-aliasing -g -Wall
11018 -Wmissing-prototypes
11019 -I../.. -Dmodule_version=module_version_mysql_main
11020 -Dmodule_config=module_co
11021 nfig_mysql_main -Dinit_module=init_module_mysql_main
11022 -Dexit_module=exit_modu
11023 le_mysql_main -c main.c -o main_static.o
11025 make[4]: Nothing to be done for `/usr/lib/mysql/libmysqlclient.a'.
11026 ar -cru .mysql.a main_static.o /usr/lib/mysql/libmysqlclient.a
11027 /usr/lib/mysql/libmysqlclient.a: invalid use of EXPORT_xxx
11028 make[3]: *** [main.a] Error 1
11029 make[2]: *** [main.a] Error 2
11030 make[2]: Leaving directory
11031 `/home/services/ircservices-5.0.19/modules/mysql'
11032 make[1]: *** [all-static] Error 2
11033 make[1]: Leaving directory `/home/services/ircservices-5.0.19/modules'
11034 make: *** [modules] Error 2
11035 [services@lists ircservices-5.0.19]$
11038 someone can helpme?
11044 ------------------------------------------------------------------
11045 To unsubscribe or change your subscription options, visit:
11046 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
11050 ------------------------------
11052 _______________________________________________
11053 IRCServices-Coding mailing list
11054 IRCServices-Coding@ircservices.za.net
11055 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
11058 End of IRCServices-Coding Digest, Vol 5, Issue 2
11059 ************************************************
11062 ------------------------------
11065 Date: Mon, 02 Jun 2003 14:32:52 +0200
11066 From: Georges Berscheid <georges@berscheid.lu>
11067 Subject: Re: [IRCServices Coding] mysql modules
11068 To: IRC Services Coding Mailing List
11069 <ircservices-coding@ircservices.za.net>
11070 Message-ID: <3EDB43F4.5070306@berscheid.lu>
11071 Content-Type: text/plain; charset=us-ascii; format=flowed
11078 >/home/services/sviluppo/lib/modules/mysql/main.so: undefined symbol:
11084 I suppose that line says: undefined symbol: uncompress.
11085 Just link zlib to your binary by adding -lz to the LIBS line in
11086 Makefile.inc. Some newer mysqlclient libraries need compress/uncompress
11092 ------------------------------
11094 _______________________________________________
11095 IRCServices-Coding mailing list
11096 IRCServices-Coding@ircservices.za.net
11097 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
11100 End of IRCServices-Coding Digest, Vol 5, Issue 3
11101 ************************************************
11103 ------------------------------------------------------------------
11104 To unsubscribe or change your subscription options, visit:
11105 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
11108 From laser at musichat.net Thu Jun 5 03:28:39 2003
11109 From: laser at musichat.net (Alessandro Ciappei)
11110 Date: Sat Oct 23 23:09:53 2004
11111 Subject: [IRCServices Coding] R: IRCServices-Coding Digest, Vol 5, Issue 4
11112 In-Reply-To: <20030605100004.001D317054@snow.fingers.co.za>
11113 Message-ID: <BNEPLNAFODLPMAECJEOBKECHCAAA.laser@musichat.net>
11117 my OS is RH 9.0, this is my zlib
11119 [root@lists root]# rpm -qa | grep zlib
11124 Possible this zlib is corrupted?
11129 Date: Wed, 4 Jun 2003 18:41:16 +0200
11130 From: "Alessandro Ciappei" <laser@musichat.net>
11131 Subject: [IRCServices Coding] R: IRCServices-Coding Digest, Vol 5,
11133 To: <ircservices-coding@ircservices.za.net>
11134 Message-ID: <BNEPLNAFODLPMAECJEOBGECGCAAA.laser@musichat.net>
11135 Content-Type: text/plain; charset="us-ascii"
11137 i try with flag -lz but this is the error:
11139 /usr/bin/ld: cannot find -lz
11140 collect2: ld returned 1 exit status
11141 make: *** [ircservices] Error 1
11148 Date: Mon, 2 Jun 2003 14:35:14 +0200
11149 From: "Alessandro Ciappei" <laser@musichat.net>
11150 Subject: [IRCServices Coding] mysql modules
11151 To: <ircservices-coding@ircservices.za.net>
11152 Message-ID: <BNEPLNAFODLPMAECJEOBMECECAAA.laser@musichat.net>
11153 Content-Type: text/plain; charset="us-ascii"
11155 It's compiling, but i see this:
11158 make[2]: Entering directory
11159 `/home/services/ircservices-5.0.19/modules/mysql'
11160 gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -I../.. -c
11163 make[4]: Nothing to be done for `/usr/lib/mysql/libmysqlclient.a'.
11164 gcc -shared main.o /usr/lib/mysql/libmysqlclient.a -o main.so
11165 make[2]: Leaving directory `/home/services/ircservices-5.0.19/modules/mysql'
11170 make[2]: Entering directory
11171 `/home/services/ircservices-5.0.19/modules/mysql'
11172 make[4]: Nothing to be done for `/usr/lib/mysql/libmysqlclient.a'.
11173 make[2]: Leaving directory `/home/services/ircservices-5.0.19/modules/mysql'
11176 and when i start services in log i see:
11178 [Jun 02 14:26:20 2003] IRC Services 5.0.19 starting up
11179 [Jun 02 14:26:21 2003] modules: Unable to load module `mysql/main':
11180 /home/services/sviluppo/lib/modules/mysql/main.so: undefined symbol: unco$
11181 [Jun 02 14:26:21 2003] Error loading modules, aborting
11189 Date: Sun, 1 Jun 2003 17:19:04 +0200
11190 From: "Alessandro Ciappei" <laser@musichat.net>
11191 Subject: [IRCServices Coding] Mysql Module
11192 To: <ircservices-coding@ircservices.za.net>
11193 Message-ID: <BNEPLNAFODLPMAECJEOBMECDCAAA.laser@musichat.net>
11194 Content-Type: text/plain; charset="us-ascii"
11196 The services souce from here
11198 http://www.luxusbuerg.lu/data/ircservices-luxusbuerg.tgz
11200 The mysql table from here
11202 http://www.luxusbuerg.lu/data/sql.tgz
11209 Date: Sat, 31 May 2003 15:10:50 +0200
11210 From: "Alessandro Ciappei" <laser@musichat.net>
11211 Subject: [IRCServices Coding] Mysql Modules
11212 To: "Ircservices-Coding@Ircservices. Za. Net"
11213 <ircservices-coding@ircservices.za.net>
11214 Message-ID: <BNEPLNAFODLPMAECJEOBIECCCAAA.laser@musichat.net>
11215 Content-Type: text/plain; charset="iso-8859-1"
11219 I try to compile services with mysql module, I found in list-archive, but I
11222 make[2]: Entering directory
11223 `/home/services/ircservices-5.0.19/modules/mysql'
11224 gcc -DSTATIC_MODULES -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes
11225 -I../.. -Dmodule_version=module_version_mysql_main -Dmodule_config=module_co
11226 nfig_mysql_main -Dinit_module=init_module_mysql_main -Dexit_module=exit_modu
11227 le_mysql_main -c main.c -o main_static.o
11229 make[4]: Nothing to be done for `/usr/lib/mysql/libmysqlclient.a'.
11230 ar -cru .mysql.a main_static.o /usr/lib/mysql/libmysqlclient.a
11231 /usr/lib/mysql/libmysqlclient.a: invalid use of EXPORT_xxx
11232 make[3]: *** [main.a] Error 1
11233 make[2]: *** [main.a] Error 2
11234 make[2]: Leaving directory `/home/services/ircservices-5.0.19/modules/mysql'
11235 make[1]: *** [all-static] Error 2
11236 make[1]: Leaving directory `/home/services/ircservices-5.0.19/modules'
11237 make: *** [modules] Error 2
11238 [services@lists ircservices-5.0.19]$
11241 someone can helpme?
11248 ------------------------------
11251 Date: Sun, 1 Jun 2003 18:50:12 +0200
11252 From: "Georges Berscheid" <georges@berscheid.lu>
11253 Subject: AW: [IRCServices Coding] Mysql Module
11254 To: "'IRC Services Coding Mailing List'"
11255 <ircservices-coding@ircservices.za.net>
11256 Message-ID: <001001c3285d$df5a9130$3ec918d4@gizmo>
11257 Content-Type: text/plain; charset="iso-8859-1"
11261 maybe you should try to build services with dynamic modules, because the
11262 mysql module is known to compile as a dynamic module.
11266 -----Urspr|ngliche Nachricht-----
11267 Von: ircservices-coding-bounces@ircservices.za.net
11268 [mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
11270 Gesendet: Sonntag, 1. Juni 2003 17:19
11271 An: ircservices-coding@ircservices.za.net
11272 Betreff: [IRCServices Coding] Mysql Module
11275 The services souce from here
11277 http://www.luxusbuerg.lu/data/ircservices-luxusbuerg.tgz
11279 The mysql table from here
11281 http://www.luxusbuerg.lu/data/sql.tgz
11288 Date: Sat, 31 May 2003 15:10:50 +0200
11289 From: "Alessandro Ciappei" <laser@musichat.net>
11290 Subject: [IRCServices Coding] Mysql Modules
11291 To: "Ircservices-Coding@Ircservices. Za. Net"
11292 <ircservices-coding@ircservices.za.net>
11293 Message-ID: <BNEPLNAFODLPMAECJEOBIECCCAAA.laser@musichat.net>
11294 Content-Type: text/plain; charset="iso-8859-1"
11298 I try to compile services with mysql module, I found in list-archive,
11302 make[2]: Entering directory
11303 `/home/services/ircservices-5.0.19/modules/mysql'
11304 gcc -DSTATIC_MODULES -O2 -fno-strict-aliasing -g -Wall
11305 -Wmissing-prototypes
11306 -I../.. -Dmodule_version=module_version_mysql_main
11307 -Dmodule_config=module_co
11308 nfig_mysql_main -Dinit_module=init_module_mysql_main
11309 -Dexit_module=exit_modu
11310 le_mysql_main -c main.c -o main_static.o
11312 make[4]: Nothing to be done for `/usr/lib/mysql/libmysqlclient.a'.
11313 ar -cru .mysql.a main_static.o /usr/lib/mysql/libmysqlclient.a
11314 /usr/lib/mysql/libmysqlclient.a: invalid use of EXPORT_xxx
11315 make[3]: *** [main.a] Error 1
11316 make[2]: *** [main.a] Error 2
11317 make[2]: Leaving directory
11318 `/home/services/ircservices-5.0.19/modules/mysql'
11319 make[1]: *** [all-static] Error 2
11320 make[1]: Leaving directory `/home/services/ircservices-5.0.19/modules'
11321 make: *** [modules] Error 2
11322 [services@lists ircservices-5.0.19]$
11325 someone can helpme?
11331 ------------------------------------------------------------------
11332 To unsubscribe or change your subscription options, visit:
11333 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
11337 ------------------------------
11339 _______________________________________________
11340 IRCServices-Coding mailing list
11341 IRCServices-Coding@ircservices.za.net
11342 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
11345 End of IRCServices-Coding Digest, Vol 5, Issue 2
11346 ************************************************
11349 ------------------------------
11352 Date: Mon, 02 Jun 2003 14:32:52 +0200
11353 From: Georges Berscheid <georges@berscheid.lu>
11354 Subject: Re: [IRCServices Coding] mysql modules
11355 To: IRC Services Coding Mailing List
11356 <ircservices-coding@ircservices.za.net>
11357 Message-ID: <3EDB43F4.5070306@berscheid.lu>
11358 Content-Type: text/plain; charset=us-ascii; format=flowed
11365 >/home/services/sviluppo/lib/modules/mysql/main.so: undefined symbol: unco$
11370 I suppose that line says: undefined symbol: uncompress.
11371 Just link zlib to your binary by adding -lz to the LIBS line in
11372 Makefile.inc. Some newer mysqlclient libraries need compress/uncompress
11378 ------------------------------
11380 _______________________________________________
11381 IRCServices-Coding mailing list
11382 IRCServices-Coding@ircservices.za.net
11383 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
11386 End of IRCServices-Coding Digest, Vol 5, Issue 3
11387 ************************************************
11390 ------------------------------
11393 Date: Wed, 4 Jun 2003 20:17:57 +0200
11394 From: "Georges Berscheid" <georges@berscheid.lu>
11395 Subject: AW: [IRCServices Coding] R: IRCServices-Coding Digest, Vol 5,
11397 To: "'IRC Services Coding Mailing List'"
11398 <ircservices-coding@ircservices.za.net>
11399 Message-ID: <000001c32ac5$9feae080$4dbbf683@globi>
11400 Content-Type: text/plain; charset="iso-8859-1"
11402 Install zlib from http://www.gzip.org/zlib/.
11403 But I must admin that I have not seen a system without zlib for a very
11408 -----Urspr|ngliche Nachricht-----
11409 Von: ircservices-coding-bounces@ircservices.za.net
11410 [mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
11412 Gesendet: Mittwoch, 4. Juni 2003 18:41
11413 An: ircservices-coding@ircservices.za.net
11414 Betreff: [IRCServices Coding] R: IRCServices-Coding Digest, Vol 5, Issue
11418 i try with flag -lz but this is the error:
11420 /usr/bin/ld: cannot find -lz
11421 collect2: ld returned 1 exit status
11422 make: *** [ircservices] Error 1
11429 Date: Mon, 2 Jun 2003 14:35:14 +0200
11430 From: "Alessandro Ciappei" <laser@musichat.net>
11431 Subject: [IRCServices Coding] mysql modules
11432 To: <ircservices-coding@ircservices.za.net>
11433 Message-ID: <BNEPLNAFODLPMAECJEOBMECECAAA.laser@musichat.net>
11434 Content-Type: text/plain; charset="us-ascii"
11436 It's compiling, but i see this:
11439 make[2]: Entering directory
11440 `/home/services/ircservices-5.0.19/modules/mysql'
11441 gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -I../.. -c
11444 make[4]: Nothing to be done for `/usr/lib/mysql/libmysqlclient.a'.
11445 gcc -shared main.o /usr/lib/mysql/libmysqlclient.a -o main.so
11446 make[2]: Leaving directory
11447 `/home/services/ircservices-5.0.19/modules/mysql'
11452 make[2]: Entering directory
11453 `/home/services/ircservices-5.0.19/modules/mysql'
11454 make[4]: Nothing to be done for `/usr/lib/mysql/libmysqlclient.a'.
11455 make[2]: Leaving directory
11456 `/home/services/ircservices-5.0.19/modules/mysql'
11459 and when i start services in log i see:
11461 [Jun 02 14:26:20 2003] IRC Services 5.0.19 starting up
11462 [Jun 02 14:26:21 2003] modules: Unable to load module `mysql/main':
11463 /home/services/sviluppo/lib/modules/mysql/main.so: undefined symbol:
11465 [Jun 02 14:26:21 2003] Error loading modules, aborting
11473 Date: Sun, 1 Jun 2003 17:19:04 +0200
11474 From: "Alessandro Ciappei" <laser@musichat.net>
11475 Subject: [IRCServices Coding] Mysql Module
11476 To: <ircservices-coding@ircservices.za.net>
11477 Message-ID: <BNEPLNAFODLPMAECJEOBMECDCAAA.laser@musichat.net>
11478 Content-Type: text/plain; charset="us-ascii"
11480 The services souce from here
11482 http://www.luxusbuerg.lu/data/ircservices-luxusbuerg.tgz
11484 The mysql table from here
11486 http://www.luxusbuerg.lu/data/sql.tgz
11493 Date: Sat, 31 May 2003 15:10:50 +0200
11494 From: "Alessandro Ciappei" <laser@musichat.net>
11495 Subject: [IRCServices Coding] Mysql Modules
11496 To: "Ircservices-Coding@Ircservices. Za. Net"
11497 <ircservices-coding@ircservices.za.net>
11498 Message-ID: <BNEPLNAFODLPMAECJEOBIECCCAAA.laser@musichat.net>
11499 Content-Type: text/plain; charset="iso-8859-1"
11503 I try to compile services with mysql module, I found in list-archive,
11507 make[2]: Entering directory
11508 `/home/services/ircservices-5.0.19/modules/mysql'
11509 gcc -DSTATIC_MODULES -O2 -fno-strict-aliasing -g -Wall
11510 -Wmissing-prototypes
11511 -I../.. -Dmodule_version=module_version_mysql_main
11512 -Dmodule_config=module_co
11513 nfig_mysql_main -Dinit_module=init_module_mysql_main
11514 -Dexit_module=exit_modu
11515 le_mysql_main -c main.c -o main_static.o
11517 make[4]: Nothing to be done for `/usr/lib/mysql/libmysqlclient.a'.
11518 ar -cru .mysql.a main_static.o /usr/lib/mysql/libmysqlclient.a
11519 /usr/lib/mysql/libmysqlclient.a: invalid use of EXPORT_xxx
11520 make[3]: *** [main.a] Error 1
11521 make[2]: *** [main.a] Error 2
11522 make[2]: Leaving directory
11523 `/home/services/ircservices-5.0.19/modules/mysql'
11524 make[1]: *** [all-static] Error 2
11525 make[1]: Leaving directory `/home/services/ircservices-5.0.19/modules'
11526 make: *** [modules] Error 2
11527 [services@lists ircservices-5.0.19]$
11530 someone can helpme?
11537 ------------------------------
11540 Date: Sun, 1 Jun 2003 18:50:12 +0200
11541 From: "Georges Berscheid" <georges@berscheid.lu>
11542 Subject: AW: [IRCServices Coding] Mysql Module
11543 To: "'IRC Services Coding Mailing List'"
11544 <ircservices-coding@ircservices.za.net>
11545 Message-ID: <001001c3285d$df5a9130$3ec918d4@gizmo>
11546 Content-Type: text/plain; charset="iso-8859-1"
11550 maybe you should try to build services with dynamic modules, because the
11551 mysql module is known to compile as a dynamic module.
11555 -----Urspr|ngliche Nachricht-----
11556 Von: ircservices-coding-bounces@ircservices.za.net
11557 [mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
11559 Gesendet: Sonntag, 1. Juni 2003 17:19
11560 An: ircservices-coding@ircservices.za.net
11561 Betreff: [IRCServices Coding] Mysql Module
11564 The services souce from here
11566 http://www.luxusbuerg.lu/data/ircservices-luxusbuerg.tgz
11568 The mysql table from here
11570 http://www.luxusbuerg.lu/data/sql.tgz
11577 Date: Sat, 31 May 2003 15:10:50 +0200
11578 From: "Alessandro Ciappei" <laser@musichat.net>
11579 Subject: [IRCServices Coding] Mysql Modules
11580 To: "Ircservices-Coding@Ircservices. Za. Net"
11581 <ircservices-coding@ircservices.za.net>
11582 Message-ID: <BNEPLNAFODLPMAECJEOBIECCCAAA.laser@musichat.net>
11583 Content-Type: text/plain; charset="iso-8859-1"
11587 I try to compile services with mysql module, I found in list-archive,
11591 make[2]: Entering directory
11592 `/home/services/ircservices-5.0.19/modules/mysql'
11593 gcc -DSTATIC_MODULES -O2 -fno-strict-aliasing -g -Wall
11594 -Wmissing-prototypes
11595 -I../.. -Dmodule_version=module_version_mysql_main
11596 -Dmodule_config=module_co
11597 nfig_mysql_main -Dinit_module=init_module_mysql_main
11598 -Dexit_module=exit_modu
11599 le_mysql_main -c main.c -o main_static.o
11601 make[4]: Nothing to be done for `/usr/lib/mysql/libmysqlclient.a'.
11602 ar -cru .mysql.a main_static.o /usr/lib/mysql/libmysqlclient.a
11603 /usr/lib/mysql/libmysqlclient.a: invalid use of EXPORT_xxx
11604 make[3]: *** [main.a] Error 1
11605 make[2]: *** [main.a] Error 2
11606 make[2]: Leaving directory
11607 `/home/services/ircservices-5.0.19/modules/mysql'
11608 make[1]: *** [all-static] Error 2
11609 make[1]: Leaving directory `/home/services/ircservices-5.0.19/modules'
11610 make: *** [modules] Error 2
11611 [services@lists ircservices-5.0.19]$
11614 someone can helpme?
11620 ------------------------------------------------------------------
11621 To unsubscribe or change your subscription options, visit:
11622 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
11626 ------------------------------
11628 _______________________________________________
11629 IRCServices-Coding mailing list
11630 IRCServices-Coding@ircservices.za.net
11631 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
11634 End of IRCServices-Coding Digest, Vol 5, Issue 2
11635 ************************************************
11638 ------------------------------
11641 Date: Mon, 02 Jun 2003 14:32:52 +0200
11642 From: Georges Berscheid <georges@berscheid.lu>
11643 Subject: Re: [IRCServices Coding] mysql modules
11644 To: IRC Services Coding Mailing List
11645 <ircservices-coding@ircservices.za.net>
11646 Message-ID: <3EDB43F4.5070306@berscheid.lu>
11647 Content-Type: text/plain; charset=us-ascii; format=flowed
11654 >/home/services/sviluppo/lib/modules/mysql/main.so: undefined symbol:
11660 I suppose that line says: undefined symbol: uncompress.
11661 Just link zlib to your binary by adding -lz to the LIBS line in
11662 Makefile.inc. Some newer mysqlclient libraries need compress/uncompress
11669 From chris at monkeyircd.org Thu Jun 5 12:43:57 2003
11670 From: chris at monkeyircd.org (Chris Plant)
11671 Date: Sat Oct 23 23:09:53 2004
11672 Subject: [IRCServices Coding] IRCServices "Losing" channels
11673 Message-ID: <1054842237.2199.2.camel@hermes>
11677 This is a pretty wierd problem, so I'm wondering if its something to do
11678 with the protocol module I've put together for MonkeyIRCD.
11680 On MonkeyIRCD.org, we have a small network, with ircservices providing
11681 services (duh?). Now, from time to time, and during a reload of
11682 services, we appear to "lose" a channel from the file on disk. I can
11683 ensure that its written out, and then I look and it has been added to
11684 channel.db, but when we reload services its gone.
11686 Any Ideas, I'm kinda stuck.
11690 From uhc0 at rz.uni-karlsruhe.de Thu Jun 5 12:48:16 2003
11691 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu)
11692 Date: Sat Oct 23 23:09:53 2004
11693 Subject: [IRCServices Coding] IRCServices "Losing" channels
11694 In-Reply-To: <1054842237.2199.2.camel@hermes>
11695 References: <1054842237.2199.2.camel@hermes>
11696 Message-ID: <1054842495.3294.0.camel@dreadnought.hadiko.de>
11700 Please ensure yourself that the channel is not expiring.
11701 You can notice this in the logfile services is generating.
11706 On Thu, 2003-06-05 at 21:43, Chris Plant wrote:
11709 > This is a pretty wierd problem, so I'm wondering if its something to do
11710 > with the protocol module I've put together for MonkeyIRCD.
11712 > On MonkeyIRCD.org, we have a small network, with ircservices providing
11713 > services (duh?). Now, from time to time, and during a reload of
11714 > services, we appear to "lose" a channel from the file on disk. I can
11715 > ensure that its written out, and then I look and it has been added to
11716 > channel.db, but when we reload services its gone.
11718 > Any Ideas, I'm kinda stuck.
11722 > ------------------------------------------------------------------
11723 > To unsubscribe or change your subscription options, visit:
11724 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
11726 ------------------------------------------------------------------
11727 | Yusuf Iskenderoglu | You get to meet all sorts, |
11728 | eMail - uhc0@stud.uni-karlsruhe.de| in this line of work... |
11729 | eMail - s_iskend@ira.uka.de | |
11730 | ICQ UIN : 20587464 \ TimeMr14C | |
11731 ------------------------------------------------------------------
11733 From curtismacaulay at ns.sympatico.ca Tue Jun 10 14:32:05 2003
11734 From: curtismacaulay at ns.sympatico.ca (Curtis MacAulay)
11735 Date: Sat Oct 23 23:09:53 2004
11736 Subject: [IRCServices Coding] ircservices noobie help
11737 Message-ID: <000701c32f97$c0262b80$0a00a8c0@upstairs>
11739 i get services running and connected to my unreal daemon but i get this
11740 message when i try to register my nickname
11742 [18:19] -irc.squirreltech.com- *** Global -- from
11743 services.squirreltech.com: PANIC! buffer = :squirrel !
11744 NickServ@services.squirreltech.com :register Friday13TH
11745 curtismacaulay@ns.sympatico.ca
11747 [18:19] -irc.squirreltech.com- *** LocOps -- Received SQUIT
11748 services.squirreltech.com from services.squirreltech.com[127.0.0.1]
11749 (Services terminating: Segmentation fault)
11752 then i check the logs and i see this
11754 [Jun 10 18:17:27 2003] IRC Services 5.0.19 starting up
11755 [Jun 10 18:17:28 2003] httpd/main: Listening on 127.0.0.1:12701
11756 [Jun 10 18:17:34 2003] operserv/sline: warning: client IP addresses not
11757 available with this IRC server
11758 [Jun 10 18:17:34 2003] user: New maximum user count: 1
11759 [Jun 10 18:18:11 2003] operserv/main: squirrel: help commands
11760 [Jun 10 18:18:44 2003] operserv/main: squirrel: admin add squirrel
11761 [Jun 10 18:18:44 2003] operserv/main: warning: ServicesRoot nickname not
11763 [Jun 10 18:19:21 2003] PANIC! buffer = :squirrel !
11764 NickServ@services.squirreltech.com :register Friday13TH
11765 curtismacaulay@ns.sympatico.ca
11766 [Jun 10 18:19:21 2003] Services terminating: Segmentation fault
11768 if someone has an answer it would be great and if you need to see more
11769 info (ie modules.conf or ircservices.conf) just ask if you are willing
11771 -------------- next part --------------
11772 An HTML attachment was scrubbed...
11773 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030610/fdb3c7c0/attachment.htm
11774 From zarin at VPShellZ.net Wed Jun 11 13:23:40 2003
11775 From: zarin at VPShellZ.net (Robert Day)
11776 Date: Sat Oct 23 23:09:53 2004
11777 Subject: [IRCServices Coding] MySQL
11778 Message-ID: <1055363020.3955.211.camel@goliath.dscn.net>
11780 I assume MySQL support will be built as a module, same as most
11781 everything else yes?
11782 I am not much of a Programmer, but I want to lend a hand if I can to
11783 this... It would be nice to finally get a Database backed services
11784 going that would be easier to port and migrate....
11785 I can also see the potential for a services backup server if this is
11786 done right.... Example:
11788 Services-Master connects to hub.us.yournetwork.net
11789 Services-Slave connects to hub.uk.yournetwork.net
11791 If the hubs split, or if services-master dies for some reason, given X
11792 amount of time, services-slave would come online and, using the MySQL
11793 Replicated database, maintain channel and user control. Once
11794 services-master returned, or the split was fixed, services-slave would
11795 send updated information to services-master, and stop running services,
11796 allowing the master to regain control...
11798 I know this is not a very in-demand feature, but it should be easy to
11799 add that as a module later on after the database backend is done... and
11800 I would like to be able to code some web based apps that can read and
11801 write the MySQL database... allow users to query the database for
11802 unused names from the network home page, find unused channel names, make
11803 changes to the services from a browser instead of the irc interface..
11804 (adding AOPs and VOPs for example, changing channel descriptions, or
11805 just browsing the channel database in a confortable web interface...
11807 So, where does the MySql support stand, or is there anything at all yet?
11811 --==:: Robert Day, Network Administrator ::==--
11812 --= VPShellZ.Net =--
11813 --= Shell and Web Hosting =--
11814 --= Quality Service =--
11815 --= Affordable Prices =--
11816 -------------- next part --------------
11817 A non-text attachment was scrubbed...
11818 Name: not available
11819 Type: application/pgp-signature
11821 Desc: This is a digitally signed message part
11822 Url : http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030611/e4323706/attachment.pgp
11823 From jskam at shaw.ca Thu Jun 12 17:38:47 2003
11824 From: jskam at shaw.ca (Jeffery Kam)
11825 Date: Sat Oct 23 23:09:53 2004
11826 Subject: [IRCServices Coding] Serious Bug, Probaby should be fixed
11827 Message-ID: <000001c33144$26bddca0$f64f9144@weed>
11829 Ok, I don't know if this is happening to anyone else, but here is the
11830 problem. I've loaded the http module to allow opers to view registered
11831 nicknames, channels, and network statistics. All password protected of
11832 course. Anyways, when you go into the List of Registered Nicknames, and
11833 look at more than one users nickserv info, services will segfault and
11834 crash. I have not changed the http module in anyway. Just thought I'd
11835 give everyone a heads up before using that module.
11837 -------------- next part --------------
11838 An HTML attachment was scrubbed...
11839 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030612/1c4d0589/attachment.htm
11840 From achurch at achurch.org Fri Jun 13 12:08:14 2003
11841 From: achurch at achurch.org (Andrew Church)
11842 Date: Sat Oct 23 23:09:54 2004
11843 Subject: [IRCServices Coding] Serious Bug, Probaby should be fixed
11844 In-Reply-To: <000001c33144$26bddca0$f64f9144@weed>
11845 Message-ID: <3ee9402b.20753@mail.achurch.org>
11847 I can't reproduce this.
11850 achurch@achurch.org
11851 http://achurch.org/
11853 >This is a multi-part message in MIME format.
11855 >--===============5325410492838385==
11856 >Content-type: multipart/alternative;
11857 > boundary="Boundary_(ID_YCOpLsbO0fK3uQV6a0w+JQ)"
11859 >This is a multi-part message in MIME format.
11861 >--Boundary_(ID_YCOpLsbO0fK3uQV6a0w+JQ)
11862 >Content-type: text/plain; charset=us-ascii
11863 >Content-transfer-encoding: 7BIT
11865 >Ok, I don't know if this is happening to anyone else, but here is the
11866 >problem. I've loaded the http module to allow opers to view registered
11867 >nicknames, channels, and network statistics. All password protected of
11868 >course. Anyways, when you go into the List of Registered Nicknames, and
11869 >look at more than one users nickserv info, services will segfault and
11870 >crash. I have not changed the http module in anyway. Just thought I'd
11871 >give everyone a heads up before using that module.
11874 >--Boundary_(ID_YCOpLsbO0fK3uQV6a0w+JQ)
11875 >Content-type: text/html; charset=us-ascii
11876 >Content-transfer-encoding: 7BIT
11881 ><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
11884 ><meta name=Generator content="Microsoft Word 10 (filtered)">
11888 > /* Style Definitions */
11889 > p.MsoNormal, li.MsoNormal, div.MsoNormal
11891 > margin-bottom:.0001pt;
11892 > font-size:12.0pt;
11893 > font-family:"Times New Roman";}
11894 >a:link, span.MsoHyperlink
11896 > text-decoration:underline;}
11897 >a:visited, span.MsoHyperlinkFollowed
11899 > text-decoration:underline;}
11901 > {font-family:Arial;
11902 > color:windowtext;}
11904 > {size:8.5in 11.0in;
11905 > margin:1.0in 1.25in 1.0in 1.25in;}
11913 ><body lang=EN-US link=blue vlink=purple>
11915 ><div class=Section1>
11917 ><p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
11918 >font-family:Arial'>Ok, I don’t know if this is happening to anyone else,
11919 >but here is the problem. I’ve loaded the http module to allow opers to
11920 >view registered nicknames, channels, and network statistics. All password
11921 >protected of course. Anyways, when you go into the List of Registered
11922 >Nicknames, and look at more than one users nickserv info, services will segfault
11923 >and crash. I have not changed the http module in anyway. Just thought I’d
11924 >give everyone a heads up before using that module.</span></font></p>
11932 >--Boundary_(ID_YCOpLsbO0fK3uQV6a0w+JQ)--
11934 >--===============5325410492838385==
11935 >Content-Type: text/plain; charset="us-ascii"
11937 >Content-Transfer-Encoding: 7bit
11938 >Content-Disposition: inline
11940 >------------------------------------------------------------------
11941 >To unsubscribe or change your subscription options, visit:
11942 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
11944 >--===============5325410492838385==--
11945 From jskam at shaw.ca Fri Jun 13 05:43:38 2003
11946 From: jskam at shaw.ca (Jeffery Kam)
11947 Date: Sat Oct 23 23:09:54 2004
11948 Subject: [IRCServices Coding] Serious Bug, Probaby should be fixed
11949 In-Reply-To: <3ee9402b.20753@mail.achurch.org>
11950 Message-ID: <000001c331a9$69b109f0$f64f9144@weed>
11952 If you can tell me the best way to debug this, I can try and get some
11953 logs for you. I also have the .core file if need be. Please let me
11956 -----Original Message-----
11957 From: ircservices-coding-bounces@ircservices.za.net
11958 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of
11960 Sent: Thursday, June 12, 2003 9:08 PM
11961 To: ircservices-coding@ircservices.za.net
11962 Subject: Re: [IRCServices Coding] Serious Bug, Probaby should be fixed
11964 I can't reproduce this.
11967 achurch@achurch.org
11968 http://achurch.org/
11970 >Ok, I don't know if this is happening to anyone else, but here is the
11971 >problem. I've loaded the http module to allow opers to view registered
11972 >nicknames, channels, and network statistics. All password protected of
11973 >course. Anyways, when you go into the List of Registered Nicknames,
11975 >look at more than one users nickserv info, services will segfault and
11976 >crash. I have not changed the http module in anyway. Just thought I'd
11977 >give everyone a heads up before using that module.
11980 From achurch at achurch.org Sat Jun 14 01:49:59 2003
11981 From: achurch at achurch.org (Andrew Church)
11982 Date: Sat Oct 23 23:09:54 2004
11983 Subject: [IRCServices Coding] Serious Bug, Probaby should be fixed
11984 In-Reply-To: <000001c331a9$69b109f0$f64f9144@weed>
11985 Message-ID: <3eea0261.21441@mail.achurch.org>
11987 A GDB backtrace would be helpful:
11989 gdb /usr/local/bin/ircservices /usr/local/lib/ircservices/core
11990 [or whatever your pathnames are]
11993 ------------- clip/copy and send from here --------------
11994 #0 ... at somefile.c:NNN
11997 ----------------------- to here -------------------------
12000 If you don't get the "at somefile:NNN" in the backtrace, your executable
12001 is missing debugging information--recompile (make sure you haven't removed
12002 the "-g" in MORE_CFLAGS in the makefile) and don't strip the executable
12005 Also, are you using a SPARC, i.e. Sun system? GCC on SPARC systems
12006 has at least one bug that is triggered by Services and causes Services to
12007 crash for apparently random reasons.
12010 achurch@achurch.org
12011 http://achurch.org/
12013 >If you can tell me the best way to debug this, I can try and get some
12014 >logs for you. I also have the .core file if need be. Please let me
12017 >-----Original Message-----
12018 >From: ircservices-coding-bounces@ircservices.za.net
12019 >[mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of
12021 >Sent: Thursday, June 12, 2003 9:08 PM
12022 >To: ircservices-coding@ircservices.za.net
12023 >Subject: Re: [IRCServices Coding] Serious Bug, Probaby should be fixed
12025 > I can't reproduce this.
12028 > achurch@achurch.org
12029 > http://achurch.org/
12031 >>Ok, I don't know if this is happening to anyone else, but here is the
12032 >>problem. I've loaded the http module to allow opers to view registered
12033 >>nicknames, channels, and network statistics. All password protected of
12034 >>course. Anyways, when you go into the List of Registered Nicknames,
12036 >>look at more than one users nickserv info, services will segfault and
12037 >>crash. I have not changed the http module in anyway. Just thought I'd
12038 >>give everyone a heads up before using that module.
12041 >------------------------------------------------------------------
12042 >To unsubscribe or change your subscription options, visit:
12043 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
12044 From jskam at shaw.ca Fri Jun 13 15:35:32 2003
12045 From: jskam at shaw.ca (Jeffery Kam)
12046 Date: Sat Oct 23 23:09:54 2004
12047 Subject: [IRCServices Coding] Serious Bug, Probaby should be fixed
12048 In-Reply-To: <3eea0261.21441@mail.achurch.org>
12049 Message-ID: <000501c331fc$199b65c0$f64f9144@weed>
12052 #0 0x08053076 in irc_stricmp (s1=0x81c9f10 "Azheman|School", s2=0x0) at
12054 #1 0x281d804d in handle_nickserv (c=0x81ee100, close_ptr=0x41,
12055 path=0x81ef00e "Azheman|School") at dbaccess.c:679
12056 #2 0x281d6e5b in do_request (c=0x81ee100, close_ptr=0xbfbfe9ec) at
12058 #3 0x08054b6e in call_callback_5 (module=0x81c8600, id=97,
12059 arg1=0x81ee100, arg2=0xbfbfe9ec, arg3=0x0, arg4=0x0, arg5=0x0)
12061 #4 0x281cd226 in handle_request (c=0x81ee100) at main.c:694
12062 #5 0x281cc826 in do_readline (socket=0x8076000, param_unused=0x2) at
12064 #6 0x08056739 in check_sockets () at sockets.c:392
12065 #7 0x08052569 in main (ac=1, av=0xbfbffbf4, envp=0xbfbffbfc) at
12067 #8 0x0804c0b5 in _start ()
12070 And I am currently running FreeBSD 5.0-Release. As for the
12071 Azheman|School nickname, that is the nickname I clicked on that made it
12072 crash, however, if I click on any nickname, it does the same thing.
12073 Hope this helps Andrew.
12077 -----Original Message-----
12078 From: ircservices-coding-bounces@ircservices.za.net
12079 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of
12081 Sent: Friday, June 13, 2003 10:50 AM
12082 To: ircservices-coding@ircservices.za.net
12083 Subject: RE: [IRCServices Coding] Serious Bug, Probaby should be fixed
12085 A GDB backtrace would be helpful:
12087 gdb /usr/local/bin/ircservices /usr/local/lib/ircservices/core
12088 [or whatever your pathnames are]
12091 ------------- clip/copy and send from here --------------
12092 #0 ... at somefile.c:NNN
12095 ----------------------- to here -------------------------
12098 If you don't get the "at somefile:NNN" in the backtrace, your executable
12099 is missing debugging information--recompile (make sure you haven't
12101 the "-g" in MORE_CFLAGS in the makefile) and don't strip the executable
12104 Also, are you using a SPARC, i.e. Sun system? GCC on SPARC systems
12105 has at least one bug that is triggered by Services and causes Services
12107 crash for apparently random reasons.
12110 achurch@achurch.org
12111 http://achurch.org/
12113 From achurch at achurch.org Thu Jun 19 13:53:50 2003
12114 From: achurch at achurch.org (Andrew Church)
12115 Date: Sat Oct 23 23:09:54 2004
12116 Subject: [IRCServices Coding] Serious Bug, Probaby should be fixed
12117 In-Reply-To: <000501c331fc$199b65c0$f64f9144@weed>
12118 Message-ID: <3ef14200.74743@achurch.org>
12120 This can't happen unless your compiler is broken or you've modified
12124 achurch@achurch.org
12125 http://achurch.org/
12128 >#0 0x08053076 in irc_stricmp (s1=0x81c9f10 "Azheman|School", s2=0x0) at
12130 >#1 0x281d804d in handle_nickserv (c=0x81ee100, close_ptr=0x41,
12131 >path=0x81ef00e "Azheman|School") at dbaccess.c:679
12132 >#2 0x281d6e5b in do_request (c=0x81ee100, close_ptr=0xbfbfe9ec) at
12134 >#3 0x08054b6e in call_callback_5 (module=0x81c8600, id=97,
12135 >arg1=0x81ee100, arg2=0xbfbfe9ec, arg3=0x0, arg4=0x0, arg5=0x0)
12137 >#4 0x281cd226 in handle_request (c=0x81ee100) at main.c:694
12138 >#5 0x281cc826 in do_readline (socket=0x8076000, param_unused=0x2) at
12140 >#6 0x08056739 in check_sockets () at sockets.c:392
12141 >#7 0x08052569 in main (ac=1, av=0xbfbffbf4, envp=0xbfbffbfc) at
12143 >#8 0x0804c0b5 in _start ()
12146 >And I am currently running FreeBSD 5.0-Release. As for the
12147 >Azheman|School nickname, that is the nickname I clicked on that made it
12148 >crash, however, if I click on any nickname, it does the same thing.
12149 >Hope this helps Andrew.
12153 >-----Original Message-----
12154 >From: ircservices-coding-bounces@ircservices.za.net
12155 >[mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of
12157 >Sent: Friday, June 13, 2003 10:50 AM
12158 >To: ircservices-coding@ircservices.za.net
12159 >Subject: RE: [IRCServices Coding] Serious Bug, Probaby should be fixed
12161 > A GDB backtrace would be helpful:
12163 >gdb /usr/local/bin/ircservices /usr/local/lib/ircservices/core
12164 > [or whatever your pathnames are]
12167 >------------- clip/copy and send from here --------------
12168 >#0 ... at somefile.c:NNN
12171 >----------------------- to here -------------------------
12174 >If you don't get the "at somefile:NNN" in the backtrace, your executable
12175 >is missing debugging information--recompile (make sure you haven't
12177 >the "-g" in MORE_CFLAGS in the makefile) and don't strip the executable
12178 >before running it.
12180 > Also, are you using a SPARC, i.e. Sun system? GCC on SPARC systems
12181 >has at least one bug that is triggered by Services and causes Services
12183 >crash for apparently random reasons.
12186 > achurch@achurch.org
12187 > http://achurch.org/
12189 >------------------------------------------------------------------
12190 >To unsubscribe or change your subscription options, visit:
12191 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
12192 From jskam at shaw.ca Thu Jun 19 05:42:14 2003
12193 From: jskam at shaw.ca (Jeffery Kam)
12194 Date: Sat Oct 23 23:09:54 2004
12195 Subject: [IRCServices Coding] Serious Bug, Probaby should be fixed
12196 In-Reply-To: <3ef14200.74743@achurch.org>
12197 Message-ID: <000401c33660$35b76e80$f64f9144@weed>
12199 I have modified services, I haven't modified any of the http modules.
12200 Can you tell the problem from that? Maybe a fix?
12202 -----Original Message-----
12203 From: ircservices-coding-bounces@ircservices.za.net
12204 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of
12206 Sent: Wednesday, June 18, 2003 10:54 PM
12207 To: ircservices-coding@ircservices.za.net
12208 Subject: RE: [IRCServices Coding] Serious Bug, Probaby should be fixed
12210 This can't happen unless your compiler is broken or you've modified
12214 achurch@achurch.org
12215 http://achurch.org/
12218 >#0 0x08053076 in irc_stricmp (s1=0x81c9f10 "Azheman|School", s2=0x0)
12221 >#1 0x281d804d in handle_nickserv (c=0x81ee100, close_ptr=0x41,
12222 >path=0x81ef00e "Azheman|School") at dbaccess.c:679
12223 >#2 0x281d6e5b in do_request (c=0x81ee100, close_ptr=0xbfbfe9ec) at
12225 >#3 0x08054b6e in call_callback_5 (module=0x81c8600, id=97,
12226 >arg1=0x81ee100, arg2=0xbfbfe9ec, arg3=0x0, arg4=0x0, arg5=0x0)
12228 >#4 0x281cd226 in handle_request (c=0x81ee100) at main.c:694
12229 >#5 0x281cc826 in do_readline (socket=0x8076000, param_unused=0x2) at
12231 >#6 0x08056739 in check_sockets () at sockets.c:392
12232 >#7 0x08052569 in main (ac=1, av=0xbfbffbf4, envp=0xbfbffbfc) at
12234 >#8 0x0804c0b5 in _start ()
12237 >And I am currently running FreeBSD 5.0-Release. As for the
12238 >Azheman|School nickname, that is the nickname I clicked on that made it
12239 >crash, however, if I click on any nickname, it does the same thing.
12240 >Hope this helps Andrew.
12244 >-----Original Message-----
12245 >From: ircservices-coding-bounces@ircservices.za.net
12246 >[mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of
12248 >Sent: Friday, June 13, 2003 10:50 AM
12249 >To: ircservices-coding@ircservices.za.net
12250 >Subject: RE: [IRCServices Coding] Serious Bug, Probaby should be fixed
12252 > A GDB backtrace would be helpful:
12254 >gdb /usr/local/bin/ircservices /usr/local/lib/ircservices/core
12255 > [or whatever your pathnames are]
12258 >------------- clip/copy and send from here --------------
12259 >#0 ... at somefile.c:NNN
12262 >----------------------- to here -------------------------
12265 >If you don't get the "at somefile:NNN" in the backtrace, your
12267 >is missing debugging information--recompile (make sure you haven't
12269 >the "-g" in MORE_CFLAGS in the makefile) and don't strip the executable
12270 >before running it.
12272 > Also, are you using a SPARC, i.e. Sun system? GCC on SPARC
12274 >has at least one bug that is triggered by Services and causes Services
12276 >crash for apparently random reasons.
12279 > achurch@achurch.org
12280 > http://achurch.org/
12282 >------------------------------------------------------------------
12283 >To unsubscribe or change your subscription options, visit:
12284 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
12285 ------------------------------------------------------------------
12286 To unsubscribe or change your subscription options, visit:
12287 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
12289 From achurch at achurch.org Thu Jun 19 23:54:06 2003
12290 From: achurch at achurch.org (Andrew Church)
12291 Date: Sat Oct 23 23:09:54 2004
12292 Subject: [IRCServices Coding] Serious Bug, Probaby should be fixed
12293 In-Reply-To: <000401c33660$35b76e80$f64f9144@weed>
12294 Message-ID: <3ef1cf16.37251@achurch.org>
12296 If anyone else wants to look at this, go ahead, but as far as I'm
12297 concerned it's unreproduceable and therefore there's nothing I can do.
12298 The backtrace below says ServicesRoot is NULL, but that line isn't reached
12299 unless NickServ is loaded, NickServ won't load if OperServ isn't loaded,
12300 and OperServ won't load if ServicesRoot is NULL, therefore this case
12304 achurch@achurch.org
12305 http://achurch.org/
12307 >I have modified services, I haven't modified any of the http modules.
12308 >Can you tell the problem from that? Maybe a fix?
12310 >-----Original Message-----
12311 >From: ircservices-coding-bounces@ircservices.za.net
12312 >[mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of
12314 >Sent: Wednesday, June 18, 2003 10:54 PM
12315 >To: ircservices-coding@ircservices.za.net
12316 >Subject: RE: [IRCServices Coding] Serious Bug, Probaby should be fixed
12318 > This can't happen unless your compiler is broken or you've modified
12322 > achurch@achurch.org
12323 > http://achurch.org/
12326 >>#0 0x08053076 in irc_stricmp (s1=0x81c9f10 "Azheman|School", s2=0x0)
12329 >>#1 0x281d804d in handle_nickserv (c=0x81ee100, close_ptr=0x41,
12330 >>path=0x81ef00e "Azheman|School") at dbaccess.c:679
12331 >>#2 0x281d6e5b in do_request (c=0x81ee100, close_ptr=0xbfbfe9ec) at
12333 >>#3 0x08054b6e in call_callback_5 (module=0x81c8600, id=97,
12334 >>arg1=0x81ee100, arg2=0xbfbfe9ec, arg3=0x0, arg4=0x0, arg5=0x0)
12335 >> at modules.c:658
12336 >>#4 0x281cd226 in handle_request (c=0x81ee100) at main.c:694
12337 >>#5 0x281cc826 in do_readline (socket=0x8076000, param_unused=0x2) at
12339 >>#6 0x08056739 in check_sockets () at sockets.c:392
12340 >>#7 0x08052569 in main (ac=1, av=0xbfbffbf4, envp=0xbfbffbfc) at
12342 >>#8 0x0804c0b5 in _start ()
12345 >>And I am currently running FreeBSD 5.0-Release. As for the
12346 >>Azheman|School nickname, that is the nickname I clicked on that made it
12347 >>crash, however, if I click on any nickname, it does the same thing.
12348 >>Hope this helps Andrew.
12352 >>-----Original Message-----
12353 >>From: ircservices-coding-bounces@ircservices.za.net
12354 >>[mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of
12356 >>Sent: Friday, June 13, 2003 10:50 AM
12357 >>To: ircservices-coding@ircservices.za.net
12358 >>Subject: RE: [IRCServices Coding] Serious Bug, Probaby should be fixed
12360 >> A GDB backtrace would be helpful:
12362 >>gdb /usr/local/bin/ircservices /usr/local/lib/ircservices/core
12363 >> [or whatever your pathnames are]
12366 >>------------- clip/copy and send from here --------------
12367 >>#0 ... at somefile.c:NNN
12370 >>----------------------- to here -------------------------
12373 >>If you don't get the "at somefile:NNN" in the backtrace, your
12375 >>is missing debugging information--recompile (make sure you haven't
12377 >>the "-g" in MORE_CFLAGS in the makefile) and don't strip the executable
12378 >>before running it.
12380 >> Also, are you using a SPARC, i.e. Sun system? GCC on SPARC
12382 >>has at least one bug that is triggered by Services and causes Services
12384 >>crash for apparently random reasons.
12387 >> achurch@achurch.org
12388 >> http://achurch.org/
12390 >>------------------------------------------------------------------
12391 >>To unsubscribe or change your subscription options, visit:
12392 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
12393 >------------------------------------------------------------------
12394 >To unsubscribe or change your subscription options, visit:
12395 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
12397 >------------------------------------------------------------------
12398 >To unsubscribe or change your subscription options, visit:
12399 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
12400 From obi_wan at no.script-irc.de Tue Jun 24 13:06:01 2003
12401 From: obi_wan at no.script-irc.de (Obi Wan)
12402 Date: Sat Oct 23 23:09:54 2004
12403 Subject: [IRCServices Coding]
12404 Building ircservices 5.0.20 on OpenBSD 3.3 fails
12405 Message-ID: <Pine.LNX.4.44.0306242200160.10120-100000@no.script-irc.de>
12408 Hi to all you. I experienced a little Problem builduing
12409 ircservices on an OpenBSD machine.
12411 Yes i use gnu make > 3.79 :)
12413 configure works. gmake ist starting to build the services.
12414 But in the modules/ it fails telling
12416 gmake[1]: Leaving directory `/home/ircd/source/ircservices-5.0.20/modules'
12419 gcc -DSTATIC_MODULES -O2 -fno-strict-aliasing -g -Wall
12420 -Wmissing-prototypes -c version.c -o version.o
12421 gcc actions.o channels.o commands.o compat.o conffile.o encrypt.o
12422 ignore.o init.o language.o log.o main.o memory.o messages.o misc.o modes.o
12423 modules.o process.o send.o servers.o signals.o sockets.o timeout.o users.o
12424 version.o modules/modules.a -o ircservices
12426 modlist.o: Undefined symbol `_module_version_chanserv_access_levels'
12427 referenced from data segment
12428 modlist.o: Undefined symbol `_module_config_chanserv_access_levels'
12429 referenced from data segment
12430 modlist.o: Undefined symbol `_init_module_chanserv_access_levels'
12431 referenced from data segment
12432 modlist.o: Undefined symbol `_exit_module_chanserv_access_levels'
12433 referenced from data segment
12434 modlist.o: Undefined symbol `_module_version_chanserv_access_xop'
12435 referenced from data segment
12436 modlist.o: Undefined symbol `_module_config_chanserv_access_xop'
12437 referenced from data segment
12438 modlist.o: Undefined symbol `_init_module_chanserv_access_xop' referenced
12440 modlist.o: Undefined symbol `_exit_module_chanserv_access_xop' referenced
12447 From obi_wan at no.script-irc.de Tue Jun 24 13:08:41 2003
12448 From: obi_wan at no.script-irc.de (Obi Wan)
12449 Date: Sat Oct 23 23:09:54 2004
12450 Subject: [IRCServices Coding] Building ircservices 5.0.20 on OpenBSD
12452 In-Reply-To: <Pine.LNX.4.44.0306242200160.10120-100000@no.script-irc.de>
12453 Message-ID: <Pine.LNX.4.44.0306242208090.10120-100000@no.script-irc.de>
12456 Sorry forgott something :))
12460 modlist.o: Undefined symbol `_init_module_statserv_main' referenced from
12462 modlist.o: Undefined symbol `_exit_module_statserv_main' referenced from
12464 modlist.o: Undefined symbol `_new_serverstats' referenced from data
12466 modlist.o: Undefined symbol `_free_serverstats' referenced from data
12468 collect2: ld returned 1 exit status
12469 gmake: *** [ircservices] Error 1
12473 From griever at t2n.org Tue Jun 24 14:59:10 2003
12474 From: griever at t2n.org (Finny Merrill)
12475 Date: Sat Oct 23 23:09:54 2004
12476 Subject: [IRCServices Coding] get_nickinfo like functions suggestion
12477 Message-ID: <oprrakowbo3wwnu9@mail-hub.optonline.net>
12480 After discussing mysql module design it occurred to me that it would make
12482 caching database module for mysql much easier if the get_ functions had
12486 I figure that if we create functions like get_readonly_nickinfo, it would
12488 for more efficient caching of data. The reasoning behind this is that
12490 which modify a nick/channel/nickgroup need to have a more updated version
12492 data in order to figure out whether it can be modified the way it wants to.
12494 On the other hand, many functions that only read from these pieces of data
12495 would not have to have the most recent version and could use the cached
12497 since it would cause little harm to simply display out-of-date information
12500 If we cached all pieces of data (including read-write), then it would
12502 that either the data in the database would be locked for too long and no
12504 program could ever modify it, or if we didn't lock the entries in the
12506 we would end up overwriting any changes another program made once we
12510 So basically I propose creating database functions using names like
12511 get_readonly_nickinfo
12512 or get_readonly_chaninfo, which would be used by commands such as INFO,
12514 AKICK LIST, AKILL LIST, and for determining access etc. The regular
12516 functions would retain the same functionality for backwards compatibility
12520 These new get_readonly_* (or if you want, get_cache_*) would be implemented
12522 that cache nick information in memory. In modules where either a)
12523 information is ALWAYS
12524 read from database on get_* or b) all information is always in memory, they
12526 synonyms for the regular get_* functions (i.e. in version4, they would be
12529 The info returned by these functions would generally not be modified (save
12531 that aren't saved to database such as the locked field) and wouldn't be
12533 put_* functions. Also, it would be a bad idea to use the info returned from
12535 readonly/cache functions to conditionally modify other data (example, you
12537 use these functions to check someone's access so that they could change
12539 since another program could recently have removed them from the access list
12541 us knowing it. It would be safe however to check someone's access to join
12543 use INVITE UNBAN OP etc, because that doesn't involve changing the
12546 If I seem to be spouting gibberish, by all means ask me to clarify.
12547 From achurch at achurch.org Wed Jun 25 10:35:53 2003
12548 From: achurch at achurch.org (Andrew Church)
12549 Date: Sat Oct 23 23:09:54 2004
12550 Subject: [IRCServices Coding] get_nickinfo like functions suggestion
12551 In-Reply-To: <oprrakowbo3wwnu9@mail-hub.optonline.net>
12552 Message-ID: <3ef8fcc7.76410@achurch.org>
12554 Easy counterexample: /os akill add luser@*.example.com (where it
12555 would definitely _not_ be proper to use out-of-date data)
12558 achurch@achurch.org
12559 http://achurch.org/
12562 >After discussing mysql module design it occurred to me that it would make
12564 >caching database module for mysql much easier if the get_ functions had
12568 >I figure that if we create functions like get_readonly_nickinfo, it would
12570 >for more efficient caching of data. The reasoning behind this is that
12572 >which modify a nick/channel/nickgroup need to have a more updated version
12574 >data in order to figure out whether it can be modified the way it wants to.
12576 >On the other hand, many functions that only read from these pieces of data
12577 >would not have to have the most recent version and could use the cached
12579 >since it would cause little harm to simply display out-of-date information
12582 >If we cached all pieces of data (including read-write), then it would
12584 >that either the data in the database would be locked for too long and no
12586 >program could ever modify it, or if we didn't lock the entries in the
12588 >we would end up overwriting any changes another program made once we
12592 >So basically I propose creating database functions using names like
12593 >get_readonly_nickinfo
12594 >or get_readonly_chaninfo, which would be used by commands such as INFO,
12596 >AKICK LIST, AKILL LIST, and for determining access etc. The regular
12598 >functions would retain the same functionality for backwards compatibility
12602 >These new get_readonly_* (or if you want, get_cache_*) would be implemented
12604 >that cache nick information in memory. In modules where either a)
12605 >information is ALWAYS
12606 >read from database on get_* or b) all information is always in memory, they
12608 >synonyms for the regular get_* functions (i.e. in version4, they would be
12611 >The info returned by these functions would generally not be modified (save
12613 >that aren't saved to database such as the locked field) and wouldn't be
12615 >put_* functions. Also, it would be a bad idea to use the info returned from
12617 >readonly/cache functions to conditionally modify other data (example, you
12619 >use these functions to check someone's access so that they could change
12621 >since another program could recently have removed them from the access list
12623 >us knowing it. It would be safe however to check someone's access to join
12625 >use INVITE UNBAN OP etc, because that doesn't involve changing the
12628 >If I seem to be spouting gibberish, by all means ask me to clarify.
12629 >------------------------------------------------------------------
12630 >To unsubscribe or change your subscription options, visit:
12631 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
12632 From achurch at achurch.org Wed Jun 25 15:03:56 2003
12633 From: achurch at achurch.org (Andrew Church)
12634 Date: Sat Oct 23 23:09:54 2004
12635 Subject: [IRCServices Coding] Building ircservices 5.0.20 on OpenBSD 3.3
12637 In-Reply-To: <Pine.LNX.4.44.0306242200160.10120-100000@no.script-irc.de>
12638 Message-ID: <3ef93b88.02311@achurch.org>
12640 >gcc actions.o channels.o commands.o compat.o conffile.o encrypt.o
12641 >ignore.o init.o language.o log.o main.o memory.o messages.o misc.o modes.o
12642 >modules.o process.o send.o servers.o signals.o sockets.o timeout.o users.o
12643 >version.o modules/modules.a -o ircservices
12645 >modlist.o: Undefined symbol `_module_version_chanserv_access_levels'
12646 >referenced from data segment
12648 Fixed for the next release, thanks for the report. In the meantime,
12649 run the command "ranlib modules/modules.a" from the top source directory
12650 and then run gmake again.
12653 achurch@achurch.org
12654 http://achurch.org/
12655 From obi_wan at no.script-irc.de Wed Jun 25 03:22:19 2003
12656 From: obi_wan at no.script-irc.de (Obi Wan)
12657 Date: Sat Oct 23 23:09:54 2004
12658 Subject: [IRCServices Coding] Building ircservices 5.0.20 on OpenBSD
12660 In-Reply-To: <3ef93b88.02311@achurch.org>
12661 Message-ID: <Pine.LNX.4.44.0306251219450.14961-100000@no.script-irc.de>
12663 On Wed, 25 Jun 2003, Andrew Church wrote:
12665 > Fixed for the next release, thanks for the report. In the meantime,
12666 > run the command "ranlib modules/modules.a" from the top source directory
12667 > and then run gmake again.
12670 > achurch@achurch.org
12671 > http://achurch.org/
12673 Don't forget in the FAQ that ircservices have to be compiled with:
12675 ./configure -cc /usr/local/bin/egcc
12680 Compiling with standard gcc from OpenBSD 3.3 i ran into a few seqfaults.
12684 From jeff.kent at myrealbox.com Wed Jun 25 11:37:04 2003
12685 From: jeff.kent at myrealbox.com (Jeffrey A. Kent)
12686 Date: Sat Oct 23 23:09:54 2004
12687 Subject: [IRCServices Coding]
12688 Bug: Socket not connected/Bus error, IRCServices 5.0.20, UnrealIRCd
12689 3.2-Beta17, FreeBSD 5.1
12690 Message-ID: <3EF9EBD0.60808@myrealbox.com>
12692 Happened after an upgrade from IRCServices 5.0.19.
12694 I've tried to get the services to dump a core so I could get you a
12695 backtrace, but even after ./configure -dumpcore and ./ircservices
12696 -debug, no core file was dropped. I checked the syslog just to be sure,
12697 and it didn't even attempt...
12699 So, the ./ircservices -debug log output is all I can provide. I'd be
12700 glad to modify/apply a patch to force a dump...
12702 [Jun 25 13:27:10.120686 2003] IRC Services 5.0.20 starting up (options:
12704 [Jun 25 13:27:10.121090 2003] debug: Loading language 0 from file
12706 [Jun 25 13:27:10.165071 2003] debug: Loading language 10 from file
12708 [Jun 25 13:27:10.209443 2003] debug: Loading language 6 from file
12710 [Jun 25 13:27:10.254186 2003] debug: Loading language 9 from file
12712 [Jun 25 13:27:10.298960 2003] debug: Loading language 11 from file
12714 [Jun 25 13:27:10.343411 2003] debug: Loading language 8 from file
12716 [Jun 25 13:27:10.360265 2003] debug: Loading language 2 from file
12718 [Jun 25 13:27:10.403532 2003] debug: Loading language 3 from file
12719 `languages/ja_sjis'
12720 [Jun 25 13:27:10.446849 2003] debug: Loading language 5 from file
12722 [Jun 25 13:27:10.471159 2003] debug: Loading language 4 from file
12724 [Jun 25 13:27:10.515700 2003] debug: Loading language 7 from file
12726 [Jun 25 13:27:10.559361 2003] debug: Loaded languages
12727 [Jun 25 13:27:10.559531 2003] debug: Loading module `protocol/unreal'
12728 [Jun 25 13:27:10.562006 2003] debug: Successfully loaded module
12730 [Jun 25 13:27:10.562200 2003] debug: Loading module `encryption/md5'
12731 [Jun 25 13:27:10.563386 2003] debug: Successfully loaded module
12733 [Jun 25 13:27:10.563555 2003] debug: Loading module `database/version4'
12734 [Jun 25 13:27:10.565182 2003] debug: Successfully loaded module
12735 `database/version4'
12736 [Jun 25 13:27:10.565321 2003] debug: Loading module `mail/main'
12737 [Jun 25 13:27:10.565886 2003] debug: Successfully loaded module `mail/main'
12738 [Jun 25 13:27:10.565998 2003] debug: Loading module `mail/smtp'
12739 [Jun 25 13:27:10.566600 2003] debug: Successfully loaded module `mail/smtp'
12740 [Jun 25 13:27:10.566712 2003] debug: Loading module `operserv/main'
12741 [Jun 25 13:27:10.568051 2003] debug: Successfully loaded module
12743 [Jun 25 13:27:10.568191 2003] debug: Loading module `operserv/akill'
12744 [Jun 25 13:27:10.569081 2003] debug: Successfully loaded module
12746 [Jun 25 13:27:10.569285 2003] debug: Loading module `operserv/news'
12747 [Jun 25 13:27:10.570094 2003] debug: Successfully loaded module
12749 [Jun 25 13:27:10.570217 2003] debug: Loading module `operserv/sessions'
12750 [Jun 25 13:27:10.571125 2003] debug: Successfully loaded module
12751 `operserv/sessions'
12752 [Jun 25 13:27:10.571247 2003] debug: Loading module `operserv/sline'
12753 [Jun 25 13:27:10.572163 2003] debug: Successfully loaded module
12755 [Jun 25 13:27:10.572288 2003] debug: Loading module `nickserv/main'
12756 [Jun 25 13:27:10.574355 2003] debug: Successfully loaded module
12758 [Jun 25 13:27:10.574531 2003] debug: Loading module `nickserv/access'
12759 [Jun 25 13:27:10.575374 2003] debug: Successfully loaded module
12761 [Jun 25 13:27:10.575521 2003] debug: Loading module `nickserv/autojoin'
12762 [Jun 25 13:27:10.576321 2003] debug: Successfully loaded module
12763 `nickserv/autojoin'
12764 [Jun 25 13:27:10.576467 2003] debug: Loading module `nickserv/link'
12765 [Jun 25 13:27:10.577361 2003] debug: Successfully loaded module
12767 [Jun 25 13:27:10.577510 2003] debug: Loading module `nickserv/mail-auth'
12768 [Jun 25 13:27:10.578414 2003] debug: Successfully loaded module
12769 `nickserv/mail-auth'
12770 [Jun 25 13:27:10.578562 2003] debug: Loading module `chanserv/main'
12771 [Jun 25 13:27:10.580860 2003] debug: Successfully loaded module
12773 [Jun 25 13:27:10.581009 2003] debug: Loading module `chanserv/access-levels'
12774 [Jun 25 13:27:10.582262 2003] debug: Successfully loaded module
12775 `chanserv/access-levels'
12776 [Jun 25 13:27:10.582385 2003] debug: Loading module `memoserv/main'
12777 [Jun 25 13:27:10.583605 2003] debug: Successfully loaded module
12779 [Jun 25 13:27:10.583733 2003] debug: Loading module `memoserv/forward'
12780 [Jun 25 13:27:10.584712 2003] debug: Successfully loaded module
12782 [Jun 25 13:27:10.584832 2003] debug: Loading module `memoserv/ignore'
12783 [Jun 25 13:27:10.585836 2003] debug: Successfully loaded module
12785 [Jun 25 13:27:10.585957 2003] debug: Loading module `statserv/main'
12786 [Jun 25 13:27:10.587225 2003] debug: Successfully loaded module
12788 [Jun 25 13:27:10.587352 2003] debug: Loading module `httpd/main'
12789 [Jun 25 13:27:10.588752 2003] httpd/main: Listening on :8080
12790 [Jun 25 13:27:10.588905 2003] debug: Successfully loaded module `httpd/main'
12791 [Jun 25 13:27:10.589006 2003] debug: Loading module `httpd/auth-ip'
12792 [Jun 25 13:27:10.590039 2003] debug: Successfully loaded module
12794 [Jun 25 13:27:10.590163 2003] debug: Loading module `httpd/auth-password'
12795 [Jun 25 13:27:10.591195 2003] debug: Successfully loaded module
12796 `httpd/auth-password'
12797 [Jun 25 13:27:10.591315 2003] debug: Loading module `httpd/dbaccess'
12798 [Jun 25 13:27:10.592712 2003] debug: Successfully loaded module
12800 [Jun 25 13:27:10.592847 2003] debug: Loading module `httpd/debug'
12801 [Jun 25 13:27:10.593900 2003] debug: Successfully loaded module
12803 [Jun 25 13:27:10.594018 2003] debug: Loading module `httpd/redirect'
12804 [Jun 25 13:27:10.595108 2003] debug: Successfully loaded module
12806 [Jun 25 13:27:10.595229 2003] debug: Loading module `httpd/top-page'
12807 [Jun 25 13:27:10.596254 2003] debug: Successfully loaded module
12809 [Jun 25 13:27:10.596372 2003] debug: Loaded modules
12810 [Jun 25 13:27:10.603249 2003] Initiated connection to 127.0.0.1:7000
12811 [Jun 25 13:27:10.603561 2003] sockets: flush_write_buffer(0): Socket is
12813 [Jun 25 13:27:10.603807 2003] Services terminating: Bus error
12814 [Jun 25 13:27:10.603905 2003] debug: Unloading module `httpd/top-page'
12815 [Jun 25 13:27:10.604211 2003] debug: Unloading module `httpd/redirect'
12816 [Jun 25 13:27:10.604380 2003] debug: Unloading module `httpd/debug'
12817 [Jun 25 13:27:10.604561 2003] debug: Unloading module `httpd/dbaccess'
12818 [Jun 25 13:27:10.604727 2003] debug: Unloading module `httpd/auth-password'
12819 [Jun 25 13:27:10.604883 2003] debug: Unloading module `httpd/auth-ip'
12820 [Jun 25 13:27:10.605038 2003] debug: Unloading module `httpd/main'
12821 [Jun 25 13:27:10.605225 2003] debug: Unloading module `statserv/main'
12822 [Jun 25 13:27:10.605531 2003] debug: Unloading module `memoserv/ignore'
12823 [Jun 25 13:27:10.605734 2003] debug: Unloading module `memoserv/forward'
12824 [Jun 25 13:27:10.605890 2003] debug: Unloading module `memoserv/main'
12825 [Jun 25 13:27:10.606075 2003] debug: Unloading module
12826 `chanserv/access-levels'
12827 [Jun 25 13:27:10.606238 2003] debug: Unloading module `chanserv/main'
12828 [Jun 25 13:27:10.606537 2003] debug: Unloading module `nickserv/mail-auth'
12829 [Jun 25 13:27:10.606717 2003] debug: Unloading module `nickserv/link'
12830 [Jun 25 13:27:10.606872 2003] debug: Unloading module `nickserv/autojoin'
12831 [Jun 25 13:27:10.607017 2003] debug: Unloading module `nickserv/access'
12832 [Jun 25 13:27:10.607170 2003] debug: Unloading module `nickserv/main'
12833 [Jun 25 13:27:10.607411 2003] debug: Unloading module `operserv/sline'
12834 [Jun 25 13:27:10.607636 2003] debug: Unloading module `operserv/sessions'
12835 [Jun 25 13:27:10.607804 2003] debug: Unloading module `operserv/news'
12836 [Jun 25 13:27:10.607956 2003] debug: Unloading module `operserv/akill'
12837 [Jun 25 13:27:10.608114 2003] debug: Unloading module `operserv/main'
12838 [Jun 25 13:27:10.608280 2003] debug: Unloading module `mail/smtp'
12839 [Jun 25 13:27:10.608460 2003] debug: Unloading module `mail/main'
12840 [Jun 25 13:27:10.608613 2003] debug: Unloading module `database/version4'
12841 [Jun 25 13:27:10.608790 2003] debug: Unloading module `encryption/md5'
12842 [Jun 25 13:27:10.608948 2003] debug: Unloading module `protocol/unreal'
12845 From griever at t2n.org Wed Jun 25 15:44:14 2003
12846 From: griever at t2n.org (Finny Merrill)
12847 Date: Sat Oct 23 23:09:54 2004
12848 Subject: [IRCServices Coding] get_nickinfo like functions suggestion
12849 In-Reply-To: <3ef8fcc7.76410@achurch.org>
12850 References: <3ef8fcc7.76410@achurch.org>
12851 Message-ID: <oprrchf0qy3wwnu9@mail-hub.optonline.net>
12853 On Wed, 25 Jun 2003 10:35:53 JST, Andrew Church <achurch@achurch.org>
12856 > Easy counterexample: /os akill add luser@*.example.com (where it
12857 > would definitely _not_ be proper to use out-of-date data)
12860 I know, that's why one wouldn't use those functions in akill add.
12861 From griever at t2n.org Wed Jun 25 15:49:27 2003
12862 From: griever at t2n.org (Finny Merrill)
12863 Date: Sat Oct 23 23:09:54 2004
12864 Subject: [IRCServices Coding] get_nickinfo like functions suggestion
12865 In-Reply-To: <oprrchf0qy3wwnu9@mail-hub.optonline.net>
12866 References: <3ef8fcc7.76410@achurch.org>
12867 <oprrchf0qy3wwnu9@mail-hub.optonline.net>
12868 Message-ID: <oprrchopxm3wwnu9@mail-hub.optonline.net>
12870 > On Wed, 25 Jun 2003 10:35:53 JST, Andrew Church <achurch@achurch.org>
12873 >> Easy counterexample: /os akill add luser@*.example.com (where it
12874 >> would definitely _not_ be proper to use out-of-date data)
12877 > I know, that's why one wouldn't use those functions in akill add.
12879 My point is that there ARE times when it wouldn't cause any damage
12880 to use out-of-date data, such times are relatively common, and doing
12881 so would definitely speed up caching.
12883 In retrospect, I think that get_cache_* would be a much better
12884 name, because there are times where even if you AREN'T modifying it,
12885 it would be better to use the regular get_*. The name would be up
12887 From jeff.kent at myrealbox.com Fri Jun 27 14:38:18 2003
12888 From: jeff.kent at myrealbox.com (Jeffrey A. Kent)
12889 Date: Sat Oct 23 23:09:54 2004
12890 Subject: [IRCServices Coding] Bug: Socket not connected/Bus error,
12891 IRCServices 5.0.20, UnrealIRCd 3.2-Beta17, FreeBSD 5.1
12892 In-Reply-To: <3EF9EBD0.60808@myrealbox.com>
12893 References: <3EF9EBD0.60808@myrealbox.com>
12894 Message-ID: <3EFCB94A.9080407@myrealbox.com>
12896 Interesting, I just tried it on another system, with the same exact
12897 configuration, and the services started up fine. Maybe it was just a
12898 fluke? I'm going to try it again on my main server... fresh. I sure am
12903 From jeff.kent at myrealbox.com Fri Jun 27 15:10:54 2003
12904 From: jeff.kent at myrealbox.com (Jeffrey A. Kent)
12905 Date: Sat Oct 23 23:09:54 2004
12906 Subject: [IRCServices Coding] Bug: Socket not connected/Bus error,
12907 IRCServices 5.0.20, UnrealIRCd 3.2-Beta17, FreeBSD 5.1
12908 In-Reply-To: <3EFCB94A.9080407@myrealbox.com>
12909 References: <3EF9EBD0.60808@myrealbox.com> <3EFCB94A.9080407@myrealbox.com>
12910 Message-ID: <3EFCC0EE.2060104@myrealbox.com>
12912 Problem discovered. For some reason, version 5.0.19 dosen't mind
12913 FreeBSD's ipfw/dummynet bandwith limiting. 5.0.20 only starts with it
12914 disabled. I fixed my ipfw settings so that localhost (oopps) dosen't
12915 get bandwith limited, and it seems fine. I'll check if ipfw/dummynet
12916 bandwith limiting causes problems with remote a remote host running
12917 IRCServices 5.0.20 to another host running the IRCd.
12921 > Interesting, I just tried it on another system, with the same exact
12922 > configuration, and the services started up fine. Maybe it was just a
12923 > fluke? I'm going to try it again on my main server... fresh. I sure
12924 > am confused. Heh.
12929 From achurch at achurch.org Sat Jun 28 11:23:24 2003
12930 From: achurch at achurch.org (Andrew Church)
12931 Date: Sat Oct 23 23:09:54 2004
12932 Subject: [IRCServices Coding] Bug: Socket not connected/Bus error,
12933 IRCServices 5.0.20, UnrealIRCd 3.2-Beta17, FreeBSD 5.1
12934 In-Reply-To: <3EFCC0EE.2060104@myrealbox.com>
12935 Message-ID: <3efcfc96.06323@achurch.org>
12937 >Problem discovered. For some reason, version 5.0.19 dosen't mind
12938 >FreeBSD's ipfw/dummynet bandwith limiting. 5.0.20 only starts with it
12939 >disabled. I fixed my ipfw settings so that localhost (oopps) dosen't
12940 >get bandwith limited, and it seems fine. I'll check if ipfw/dummynet
12941 >bandwith limiting causes problems with remote a remote host running
12942 >IRCServices 5.0.20 to another host running the IRCd.
12944 The bus error was due to a bug in error handling, now fixed, but if
12945 your system is returning an error on socket writes, then 5.0.19 shouldn't
12946 have worked either; I can't find any other reason for the "not connected"
12950 achurch@achurch.org
12951 http://achurch.org/
12952 From Ganja51 at lcirc.net Fri Jan 31 22:00:43 2003
12953 From: Ganja51 at lcirc.net (Ganja51)
12954 Date: Sat Oct 23 23:09:54 2004
12955 Subject: [IRCServices Coding] Additional Removal Methods
12956 Message-ID: <004201c2c9b7$38df4670$1402a8c0@monte>
12958 I just recently had a bot flood and there's a few functions which I think
12959 may have helped tremendously in the removal of the bots. First off an akill
12960 which can akill the realname AND support wildcards. Example:
12961 ... fritz is lilah@lcirc-590F41A.hkcable.com.hk (here)
12962 ... fritz is ?]Z[-22091? on Edge.lcirc.net (2 hops)
12963 ... marzec is vxvmn797@15B84C5E.8EBB203E.3260E6B0.IP (here)
12964 ... marzec is ?]Z[-46173? on Edge.lcirc.net (2 hops)
12965 Those were 2 bots. An akill of the realname of ]Z[-* would have removed all
12966 of those ones. UnrealIRCd supports this sort of ban, but it'd have to be
12967 added to each server which is a hassle in a flood situation.
12969 The other type is if the ident matches the realname. Example:
12970 ... Flinch01 is ~TooL@lcirc-206714C5.bbd16tcl.dsl.pol.co.uk (here)
12971 ... Flinch01 is ?TooL? on Gimcrack.lcirc.net (0 hops)
12972 ... Aitziver is ~00537@22BD02E.2482453B.4F4CDF9A.IP (here)
12973 ... Aitziver is ?00537? on Gimcrack.lcirc.net (0 hops)
12974 This one is probably less likely seeing as how services would have to run
12975 that check. But lots of bots are poorly coded in the respect that they use
12976 the same random word/number generated for both the ident and realname.
12978 Just a few suggestions which I think would help out a ton. Thanks for your
12983 From achurch at achurch.org Sat Feb 1 19:18:53 2003
12984 From: achurch at achurch.org (Andrew Church)
12985 Date: Sat Oct 23 23:09:54 2004
12986 Subject: [IRCServices Coding] Additional Removal Methods
12987 In-Reply-To: <004201c2c9b7$38df4670$1402a8c0@monte>
12988 Message-ID: <3e3c8e03.34167@mail.achurch.org>
12990 Try SGLINE with SQlineKill (modules.conf).
12993 achurch@achurch.org
12994 http://achurch.org/
12996 >I just recently had a bot flood and there's a few functions which I think
12997 >may have helped tremendously in the removal of the bots. First off an aki
12999 >which can akill the realname AND support wildcards. Example:
13000 >... fritz is lilah@lcirc-590F41A.hkcable.com.hk (here)
13001 >... fritz is
\8e«]Z[-22091
\8e» on Edge.lcirc.net (2 hops)
13002 >... marzec is vxvmn797@15B84C5E.8EBB203E.3260E6B0.IP (here)
13003 >... marzec is
\8e«]Z[-46173
\8e» on Edge.lcirc.net (2 hops)
13004 >Those were 2 bots. An akill of the realname of ]Z[-* would have removed a
13006 >of those ones. UnrealIRCd supports this sort of ban, but it'd have to be
13007 >added to each server which is a hassle in a flood situation.
13009 >The other type is if the ident matches the realname. Example:
13010 >... Flinch01 is ~TooL@lcirc-206714C5.bbd16tcl.dsl.pol.co.uk (here)
13011 >... Flinch01 is
\8e«TooL
\8e» on Gimcrack.lcirc.net (0 hops)
13012 >... Aitziver is ~00537@22BD02E.2482453B.4F4CDF9A.IP (here)
13013 >... Aitziver is
\8e«00537
\8e» on Gimcrack.lcirc.net (0 hops)
13014 >This one is probably less likely seeing as how services would have to run
13015 >that check. But lots of bots are poorly coded in the respect that they us
13017 >the same random word/number generated for both the ident and realname.
13019 >Just a few suggestions which I think would help out a ton. Thanks for you
13025 >------------------------------------------------------------------
13026 >To unsubscribe or change your subscription options, visit:
13027 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
13028 From andrewk at isdial.net Fri Jul 4 01:20:02 2003
13029 From: andrewk at isdial.net (Andrew Kempe)
13030 Date: Sat Oct 23 23:09:54 2004
13031 Subject: [IRCServices Coding] mailing list problems - fixed
13032 Message-ID: <02ad01c34205$113791b0$1f0912ac@espotting.com>
13036 There were a few problems with the mail daemon on the server which hosts the
13037 mailing lists over the past few days. Basically it got it's knickers in a
13038 knot over IPv6 and decided it would be a good thing to route the mail to
13039 Mars, rather than Earth.
13041 The quantum fisure has been knitted closed and the displacement field
13042 re-aligned, so mail should once again be reaching your mailboxes.
13044 Sorry for any problems this may have caused.
13046 Please direct and ill fealings, comments or just plain bad language to RIAA.
13050 Oh, and have yourselves a fantastic weekend!
13052 From griever at t2n.org Fri Jul 4 05:17:35 2003
13053 From: griever at t2n.org (Finny Merrill)
13054 Date: Sat Oct 23 23:09:54 2004
13055 Subject: [IRCServices Coding] Re: get_cache_nickinfo etc
13056 Message-ID: <oprrscflgy3wwnu9@mail-hub.optonline.net>
13058 Does anyone have any comments on this idea?
13060 (referring to this thread:
13061 http://www.ircservices.za.net/pipermail/ircservices-
13062 coding/2003/003670.html)
13065 From Gizm0 at ad2u.gr Tue Jul 8 16:17:48 2003
13066 From: Gizm0 at ad2u.gr (Gizm0)
13067 Date: Sat Oct 23 23:09:54 2004
13068 Subject: [IRCServices Coding] Minor ChanServ bug
13069 Message-ID: <1057706268.3f0b511c933d1@webmail.ad2u.gr>
13071 Ok, think about this.. /chanserv access #channel del all, deletes all channel's
13072 access records..but if there is a nick "All" it does the same, instead of
13073 deleting the "All" access record..I think that there are 2 things that we should
13074 consider and do..add an "if" statement to check if there is a nick "All" in the
13075 channel's access list or forbid the use of nick "All".If we choose the first
13076 one, we can change a little bit the command from "del all" to "del all records"
13077 or "del all nicks" or "del all access(es)"..C u all (: -- :)
13080 IRL: Panagiotis Kefalidis
13081 Brain? No route to host...
13083 From griever at t2n.org Tue Jul 8 18:47:41 2003
13084 From: griever at t2n.org (Finny Merrill)
13085 Date: Sat Oct 23 23:09:54 2004
13086 Subject: [IRCServices Coding] Serious Bug, Probaby should be fixed
13087 In-Reply-To: <000001c33144$26bddca0$f64f9144@weed>
13088 References: <000001c33144$26bddca0$f64f9144@weed>
13089 Message-ID: <oprr0slruk3wwnu9@mail-hub.optonline.net>
13091 On Thu, 12 Jun 2003 18:38:47 -0600, Jeffery Kam <jskam@shaw.ca> wrote:
13093 > Ok, I don't know if this is happening to anyone else, but here is the
13094 > problem. I've loaded the http module to allow opers to view registered
13095 > nicknames, channels, and network statistics. All password protected of
13096 > course. Anyways, when you go into the List of Registered Nicknames, and
13097 > look at more than one users nickserv info, services will segfault and
13098 > crash. I have not changed the http module in anyway. Just thought I'd
13099 > give everyone a heads up before using that module.
13103 Don't send HTML email please.
13104 From griever at t2n.org Fri Jul 11 09:44:16 2003
13105 From: griever at t2n.org (Finny Merrill)
13106 Date: Sat Oct 23 23:09:54 2004
13107 Subject: [IRCServices Coding] DUMPCORE only unhandles SIGSEGV?
13108 Message-ID: <oprr5nf2tg3wwnu9@mail-hub.optonline.net>
13111 Why does DUMPCORE only turn off the SIGSEGV handler? there are other
13112 signals that cause core dumps
13113 (like SIGFPE, SIGQUIT, SIGABRT, SIGILL etc) that we definitely would want
13114 to dump core if we want
13116 From achurch at achurch.org Sat Jul 12 03:19:34 2003
13117 From: achurch at achurch.org (Andrew Church)
13118 Date: Sat Oct 23 23:09:54 2004
13119 Subject: [IRCServices Coding] DUMPCORE only unhandles SIGSEGV?
13120 In-Reply-To: <oprr5nf2tg3wwnu9@mail-hub.optonline.net>
13121 Message-ID: <3f0f0060.56561@achurch.org>
13123 SIGFPE only happens on divide by zero, and in the few places where
13124 Services divides by a variable the variable is already tested for being
13125 nonzero. SIGQUIT is user-generated. SIGABRT isn't generated at all.
13126 SIGILL only occurs if your compiler is broken or you run a binary compiled
13130 achurch@achurch.org
13131 http://achurch.org/
13134 >Why does DUMPCORE only turn off the SIGSEGV handler? there are other
13135 >signals that cause core dumps
13136 >(like SIGFPE, SIGQUIT, SIGABRT, SIGILL etc) that we definitely would want
13137 >to dump core if we want
13139 >------------------------------------------------------------------
13140 >To unsubscribe or change your subscription options, visit:
13141 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
13142 From griever at t2n.org Fri Jul 11 11:25:02 2003
13143 From: griever at t2n.org (Finny Merrill)
13144 Date: Sat Oct 23 23:09:54 2004
13145 Subject: [IRCServices Coding] DUMPCORE only unhandles SIGSEGV?
13146 In-Reply-To: <3f0f0060.56561@achurch.org>
13147 References: <3f0f0060.56561@achurch.org>
13148 Message-ID: <oprr5r30jg3wwnu9@mail-hub.optonline.net>
13150 On Sat, 12 Jul 2003 03:19:34 JST, Andrew Church <achurch@achurch.org>
13153 > SIGFPE only happens on divide by zero, and in the few places where
13154 > Services divides by a variable the variable is already tested for being
13155 > nonzero. SIGQUIT is user-generated. SIGABRT isn't generated at all.
13156 > SIGILL only occurs if your compiler is broken or you run a binary
13158 > for the wrong CPU.
13161 Well, we recently had a problem where our services (not ircservices but
13163 went into a spinlock, and there was no way we could even find out what it
13165 as soon as it happened the process monitor killed it for eating CPU, and
13167 way we could get it to core. This has never happened to me with
13168 ircservices, but what
13169 if it did one day? The same problems would occur.
13170 From griever at t2n.org Fri Jul 11 11:26:47 2003
13171 From: griever at t2n.org (Finny Merrill)
13172 Date: Sat Oct 23 23:09:54 2004
13173 Subject: [IRCServices Coding] DUMPCORE only unhandles SIGSEGV?
13174 In-Reply-To: <3f0f0060.56561@achurch.org>
13175 References: <3f0f0060.56561@achurch.org>
13176 Message-ID: <oprr5r6xjq3wwnu9@mail-hub.optonline.net>
13178 On Sat, 12 Jul 2003 03:19:34 JST, Andrew Church <achurch@achurch.org>
13181 > SIGFPE only happens on divide by zero, and in the few places where
13182 > Services divides by a variable the variable is already tested for being
13183 > nonzero. SIGQUIT is user-generated. SIGABRT isn't generated at all.
13184 > SIGILL only occurs if your compiler is broken or you run a binary
13186 > for the wrong CPU.
13188 As an alternate way to reply to this, if someone uses SIGQUIT on a process,
13189 it's because they WANT it to dump core (otherwise they would use SIGTERM
13190 or SIGKILL), so why make it do otherwise?
13191 From achurch at achurch.org Sat Jul 12 03:38:01 2003
13192 From: achurch at achurch.org (Andrew Church)
13193 Date: Sat Oct 23 23:09:54 2004
13194 Subject: [IRCServices Coding] DUMPCORE only unhandles SIGSEGV?
13195 In-Reply-To: <oprr5r6xjq3wwnu9@mail-hub.optonline.net>
13196 Message-ID: <3f0f042a.56601@achurch.org>
13198 (1) Not everyone thinks the same way you do and (2) just use GDB on
13199 the process and ^C it.
13201 >On Sat, 12 Jul 2003 03:19:34 JST, Andrew Church <achurch@achurch.org>
13204 >> SIGFPE only happens on divide by zero, and in the few places where
13205 >> Services divides by a variable the variable is already tested for being
13206 >> nonzero. SIGQUIT is user-generated. SIGABRT isn't generated at all.
13207 >> SIGILL only occurs if your compiler is broken or you run a binary
13209 >> for the wrong CPU.
13211 >As an alternate way to reply to this, if someone uses SIGQUIT on a process,
13212 >it's because they WANT it to dump core (otherwise they would use SIGTERM
13213 >or SIGKILL), so why make it do otherwise?
13214 >------------------------------------------------------------------
13215 >To unsubscribe or change your subscription options, visit:
13216 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
13219 achurch@achurch.org
13220 http://achurch.org/
13221 From griever at t2n.org Fri Jul 11 11:38:37 2003
13222 From: griever at t2n.org (Finny Merrill)
13223 Date: Sat Oct 23 23:09:54 2004
13224 Subject: [IRCServices Coding] DUMPCORE only unhandles SIGSEGV?
13225 In-Reply-To: <3f0f0060.56561@achurch.org>
13226 References: <3f0f0060.56561@achurch.org>
13227 Message-ID: <oprr5sqnnc3wwnu9@mail-hub.optonline.net>
13229 Also, (sorry for bugging you), why not make DUMPCORE a runtime option? it's
13231 that the simple act of recompiling the program might make a bug go dormant
13233 From achurch at achurch.org Sat Jul 12 10:43:05 2003
13234 From: achurch at achurch.org (Andrew Church)
13235 Date: Sat Oct 23 23:09:55 2004
13236 Subject: [IRCServices Coding] DUMPCORE only unhandles SIGSEGV?
13237 In-Reply-To: <oprr5sqnnc3wwnu9@mail-hub.optonline.net>
13238 Message-ID: <3f0f67fb.56672@achurch.org>
13240 Conceivable, but highly unlikely; and if you want to make that
13241 argument, then the same can be said for running with DUMPCORE enabled or
13242 disabled even if you don't recompile. Most such bugs are usually due to
13243 memory corruption (double free(), stomping on the malloc() arena, etc.),
13244 and even the slightest breeze will change their behavior.
13246 >Also, (sorry for bugging you), why not make DUMPCORE a runtime option? it's
13248 >that the simple act of recompiling the program might make a bug go dormant
13250 >------------------------------------------------------------------
13251 >To unsubscribe or change your subscription options, visit:
13252 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
13255 achurch@achurch.org
13256 http://achurch.org/
13257 From phan70m at hotmail.com Thu Jul 17 11:15:16 2003
13258 From: phan70m at hotmail.com (Anton Volkov)
13259 Date: Sat Oct 23 23:09:55 2004
13260 Subject: [IRCServices Coding] the ignore error
13261 Message-ID: <001101c34c8f$5f9b6680$527eda51@anton>
13263 For some reason, twice today I started receiving a new error
13265 *** Global -- from services.nix.org.il: Network buffer size exceeded ignore threshold (95%), ignoring PRIVMSGs
13267 After witch I needed to restart my services in order for them to stop ignoring users.
13269 Why on earth am I getting this in the first place and how can I fix this?
13271 I am running unreal 3.2 beta 17 with ircservices-5.0.20
13273 (on irc.nix.org.il)
13277 If you'll come across our network, talk to PHANTOm or S7 in #operhelp
13279 -------------- next part --------------
13280 An HTML attachment was scrubbed...
13281 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030717/492cadff/attachment.html
13282 From ballsy at mystical.net Thu Jul 17 11:22:56 2003
13283 From: ballsy at mystical.net (Ballsy)
13284 Date: Sat Oct 23 23:09:55 2004
13285 Subject: [IRCServices Coding] the ignore error
13286 In-Reply-To: <001101c34c8f$5f9b6680$527eda51@anton>
13287 Message-ID: <Pine.LNX.4.44.0307171420470.28392-100000@david.mail.net>
13289 Look for NetBufferSize and NetBufferLimit in your ircservices.conf
13290 file. It's also in the docs/a.html file, with a bit more verbosity.
13293 Quoth Anton Volkov on Jul 17 at 21:15,
13295 > For some reason, twice today I started receiving a new error
13297 > *** Global -- from services.nix.org.il: Network buffer size exceeded ignore threshold (95%), ignoring PRIVMSGs
13299 > After witch I needed to restart my services in order for them to stop ignoring users.
13301 > Why on earth am I getting this in the first place and how can I fix this?
13303 > I am running unreal 3.2 beta 17 with ircservices-5.0.20
13305 > (on irc.nix.org.il)
13309 > If you'll come across our network, talk to PHANTOm or S7 in #operhelp
13313 From pekem at clanarena.net Thu Jul 17 12:15:50 2003
13314 From: pekem at clanarena.net (pekem)
13315 Date: Sat Oct 23 23:09:55 2004
13316 Subject: [IRCServices Coding]
13317 Why does IRC Services take mode +r when linking to the hub?
13318 Message-ID: <000501c34c97$d5f87b30$6fc381d9@ptw2778jqpx77c>
13320 When I link IRCServices4.5.45 to hub (bahamut 1.4.35), all users lose +r
13321 umode. By consequence, away users became killed or guested. I don't know
13322 how to solve this problem. Can you help me?
13326 -------------- next part --------------
13327 An HTML attachment was scrubbed...
13328 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030717/060a83a3/attachment.htm
13329 From Gizm0 at ad2u.gr Fri Jul 18 02:31:36 2003
13330 From: Gizm0 at ad2u.gr (Gizm0)
13331 Date: Sat Oct 23 23:09:55 2004
13332 Subject: [IRCServices Coding] Why does IRC Services take mode +r when
13333 linking to the hub?
13334 In-Reply-To: <000501c34c97$d5f87b30$6fc381d9@ptw2778jqpx77c>
13335 References: <000501c34c97$d5f87b30$6fc381d9@ptw2778jqpx77c>
13336 Message-ID: <1058520696.3f17be784caab@webmail.ad2u.gr>
13338 Quoting message from pekem <pekem@clanarena.net>:
13340 > When I link IRCServices4.5.45 to hub (bahamut 1.4.35), all users lose +r
13341 That's why they are not registered or identified to the services.Try /msg
13342 nickserv register command.
13343 > umode. By consequence, away users became killed or guested. I don't know
13344 These are registered users that they haven't identified their nicks so they
13345 become guested.Now.. if they get killed.. what's the message? I mean if you
13346 have enabled to kill the users instead of guesting them, this is absolutely
13348 > how to solve this problem. Can you help me?
13356 Brain? No route to host...
13358 From martinpels at hotmail.com Thu Jul 24 03:02:41 2003
13359 From: martinpels at hotmail.com (Martin Pels)
13360 Date: Sat Oct 23 23:09:55 2004
13361 Subject: [IRCServices Coding] 2 feature requests
13362 Message-ID: <BAY8-DAV26ZaendgjvM0000135e@hotmail.com>
13366 On our network we're currently taking a look on how we can make things more
13367 secure. And while doiung that we came up with a couple of ideas to improve
13370 One of the things we did is link all of our servers through SSL, and gave
13371 clients the option to connect through SSL as well. Now the only thing on our
13372 net that isn't connected through SSL is Services.
13373 Are there any plans to add this to IRCServices? I didn't see anything about
13376 The second idea is about the encrypted passwords. As stated in the
13377 IRCServices documentation SENDPASS and GETPASS won't work with encryption
13378 enabled because of the way md5 works.
13379 This introduces the problem that users will have to contact an Oper in case
13380 they lose their password.
13381 Would it be possible to, when encryption is enabled, change the behaviour of
13382 SENDPASS so that it won't send the user's password (because this is not
13383 possible), but generate a new random password for the user and send that to
13384 the user's e-mail address instead?
13388 From uhc0 at rz.uni-karlsruhe.de Thu Jul 24 03:32:24 2003
13389 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu)
13390 Date: Sat Oct 23 23:09:55 2004
13391 Subject: [IRCServices Coding] 2 feature requests
13392 In-Reply-To: <BAY8-DAV26ZaendgjvM0000135e@hotmail.com>
13393 References: <BAY8-DAV26ZaendgjvM0000135e@hotmail.com>
13394 Message-ID: <1059042744.15354.1.camel@dreadnought.hadiko.de>
13398 Link your services using 127.0.0.1; no packet is sent to the network, no
13399 additional CPU time will be required to encrypt/decrypt via ssl.
13406 On Thu, 2003-07-24 at 12:02, Martin Pels wrote:
13409 > On our network we're currently taking a look on how we can make things more
13410 > secure. And while doiung that we came up with a couple of ideas to improve
13413 > One of the things we did is link all of our servers through SSL, and gave
13414 > clients the option to connect through SSL as well. Now the only thing on our
13415 > net that isn't connected through SSL is Services.
13416 > Are there any plans to add this to IRCServices? I didn't see anything about
13419 > The second idea is about the encrypted passwords. As stated in the
13420 > IRCServices documentation SENDPASS and GETPASS won't work with encryption
13421 > enabled because of the way md5 works.
13422 > This introduces the problem that users will have to contact an Oper in case
13423 > they lose their password.
13424 > Would it be possible to, when encryption is enabled, change the behaviour of
13425 > SENDPASS so that it won't send the user's password (because this is not
13426 > possible), but generate a new random password for the user and send that to
13427 > the user's e-mail address instead?
13431 > ------------------------------------------------------------------
13432 > To unsubscribe or change your subscription options, visit:
13433 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
13435 ------------------------------------------------------------------
13436 | Yusuf Iskenderoglu | You get to meet all sorts, |
13437 | eMail - uhc0@stud.uni-karlsruhe.de| in this line of work... |
13438 | eMail - s_iskend@ira.uka.de | |
13439 | ICQ UIN : 20587464 \ TimeMr14C | |
13440 ------------------------------------------------------------------
13442 From dylanvdm at icon.co.za Thu Jul 24 12:54:43 2003
13443 From: dylanvdm at icon.co.za (Dylan v.d Merwe)
13444 Date: Sat Oct 23 23:09:55 2004
13445 Subject: [IRCServices Coding] 2 feature requests
13446 References: <BAY8-DAV26ZaendgjvM0000135e@hotmail.com>
13447 Message-ID: <000801c3521d$6eb15330$15ccef9b@dylan>
13449 I have connected my services package through an ssl connection to my ircd.
13453 ----- Original Message -----
13454 From: "Martin Pels" <martinpels@hotmail.com>
13455 To: <ircservices-coding@ircservices.za.net>
13456 Sent: Thursday, July 24, 2003 12:02 PM
13457 Subject: [IRCServices Coding] 2 feature requests
13462 > On our network we're currently taking a look on how we can make things
13464 > secure. And while doiung that we came up with a couple of ideas to improve
13467 > One of the things we did is link all of our servers through SSL, and gave
13468 > clients the option to connect through SSL as well. Now the only thing on
13470 > net that isn't connected through SSL is Services.
13471 > Are there any plans to add this to IRCServices? I didn't see anything
13475 > The second idea is about the encrypted passwords. As stated in the
13476 > IRCServices documentation SENDPASS and GETPASS won't work with encryption
13477 > enabled because of the way md5 works.
13478 > This introduces the problem that users will have to contact an Oper in
13480 > they lose their password.
13481 > Would it be possible to, when encryption is enabled, change the behaviour
13483 > SENDPASS so that it won't send the user's password (because this is not
13484 > possible), but generate a new random password for the user and send that
13486 > the user's e-mail address instead?
13490 > ------------------------------------------------------------------
13491 > To unsubscribe or change your subscription options, visit:
13492 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
13495 From Craig at chatspike.net Thu Jul 24 20:30:21 2003
13496 From: Craig at chatspike.net (Craig McLure)
13497 Date: Sat Oct 23 23:09:55 2004
13498 Subject: [IRCServices Coding] 2 feature requests
13499 Message-ID: <20030725023028.EGGS13147.mta7-svc.business.ntl.com@i-br0ked-it>
13501 thats not really any help, details of how would be useful.. if you use an SSL tunneler thou, surely it would be easier to directly connect it to the IRCd? :P
13503 /****************************************
13504 * Craig "FrostyCoolSlug" McLure
13505 ************* - SpamBox - **************
13506 * InspIRCd - http://www.inspircd.org
13507 * ChatSpike - http://www.chatspike.net
13508 * WinBot - http://www.winbot.co.uk
13509 ****************************************/
13511 /****************************************
13512 * From - Dylan v.d Merwe <dylanvdm@icon.co.za>
13513 * To - IRC Services Coding Mailing List <ircservices-coding@ircservices.za.net>
13514 * Sent - 2003-07-24 @ 21:54:00
13515 * Subject - Re: [IRCServices Coding] 2 feature requests
13516 ****************************************/
13518 /****** - Begin Original Message - ******/
13520 >I have connected my services package through an ssl connection to my ircd.
13524 >----- Original Message -----
13525 >From: "Martin Pels" <martinpels@hotmail.com>
13526 >To: <ircservices-coding@ircservices.za.net>
13527 >Sent: Thursday, July 24, 2003 12:02 PM
13528 >Subject: [IRCServices Coding] 2 feature requests
13533 >> On our network we're currently taking a look on how we can make things
13535 >> secure. And while doiung that we came up with a couple of ideas to improve
13538 >> One of the things we did is link all of our servers through SSL, and gave
13539 >> clients the option to connect through SSL as well. Now the only thing on
13541 >> net that isn't connected through SSL is Services.
13542 >> Are there any plans to add this to IRCServices? I didn't see anything
13546 >> The second idea is about the encrypted passwords. As stated in the
13547 >> IRCServices documentation SENDPASS and GETPASS won't work with encryption
13548 >> enabled because of the way md5 works.
13549 >> This introduces the problem that users will have to contact an Oper in
13551 >> they lose their password.
13552 >> Would it be possible to, when encryption is enabled, change the behaviour
13554 >> SENDPASS so that it won't send the user's password (because this is not
13555 >> possible), but generate a new random password for the user and send that
13557 >> the user's e-mail address instead?
13561 >> ------------------------------------------------------------------
13562 >> To unsubscribe or change your subscription options, visit:
13563 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
13566 >------------------------------------------------------------------
13567 >To unsubscribe or change your subscription options, visit:
13568 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
13571 /******* - End Original Message - *******/
13575 From martinpels at hotmail.com Fri Jul 25 02:28:33 2003
13576 From: martinpels at hotmail.com (Martin Pels)
13577 Date: Sat Oct 23 23:09:55 2004
13578 Subject: [IRCServices Coding] 2 feature requests
13579 References: <BAY8-DAV26ZaendgjvM0000135e@hotmail.com>
13580 <1059042744.15354.1.camel@dreadnought.hadiko.de>
13581 Message-ID: <BAY8-DAV281UjdSkleU00004285@hotmail.com>
13583 Good idea, but that won't work if Services is on a different machine than
13586 ----- Original Message -----
13587 From: "Yusuf Iskenderoglu" <uhc0@rz.uni-karlsruhe.de>
13588 To: "IRC Services Coding Mailing List"
13589 <ircservices-coding@ircservices.za.net>
13590 Sent: Thursday, July 24, 2003 12:32 PM
13591 Subject: Re: [IRCServices Coding] 2 feature requests
13596 > Link your services using 127.0.0.1; no packet is sent to the network, no
13597 > additional CPU time will be required to encrypt/decrypt via ssl.
13604 > On Thu, 2003-07-24 at 12:02, Martin Pels wrote:
13607 > > On our network we're currently taking a look on how we can make things
13609 > > secure. And while doiung that we came up with a couple of ideas to
13613 > > One of the things we did is link all of our servers through SSL, and
13615 > > clients the option to connect through SSL as well. Now the only thing on
13617 > > net that isn't connected through SSL is Services.
13618 > > Are there any plans to add this to IRCServices? I didn't see anything
13620 > > it in the TODO.
13622 > > The second idea is about the encrypted passwords. As stated in the
13623 > > IRCServices documentation SENDPASS and GETPASS won't work with
13625 > > enabled because of the way md5 works.
13626 > > This introduces the problem that users will have to contact an Oper in
13628 > > they lose their password.
13629 > > Would it be possible to, when encryption is enabled, change the
13631 > > SENDPASS so that it won't send the user's password (because this is not
13632 > > possible), but generate a new random password for the user and send that
13634 > > the user's e-mail address instead?
13638 > > ------------------------------------------------------------------
13639 > > To unsubscribe or change your subscription options, visit:
13640 > > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
13642 > ------------------------------------------------------------------
13643 > | Yusuf Iskenderoglu | You get to meet all sorts, |
13644 > | eMail - uhc0@stud.uni-karlsruhe.de| in this line of work... |
13645 > | eMail - s_iskend@ira.uka.de | |
13646 > | ICQ UIN : 20587464 \ TimeMr14C | |
13647 > ------------------------------------------------------------------
13649 > ------------------------------------------------------------------
13650 > To unsubscribe or change your subscription options, visit:
13651 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
13653 From Craig at chatspike.net Fri Jul 25 06:31:32 2003
13654 From: Craig at chatspike.net (Craig McLure)
13655 Date: Sat Oct 23 23:09:55 2004
13656 Subject: [IRCServices Coding] 2 feature requests
13657 Message-ID: <20030725123134.JXZN392.mta6-svc.business.ntl.com@i-br0ked-it>
13659 actually, it would.. configure the tunneler to the external IP, and connect services via 127.0.0.1...
13660 What i'm saying, is that if services were on the same machine as the IRCd, a tunneler would be pointless :)
13662 /****************************************
13663 * Craig "FrostyCoolSlug" McLure
13664 ************* - SpamBox - **************
13665 * InspIRCd - http://www.inspircd.org
13666 * ChatSpike - http://www.chatspike.net
13667 * WinBot - http://www.winbot.co.uk
13668 ****************************************/
13670 /****************************************
13671 * From - Martin Pels <martinpels@hotmail.com>
13672 * To - IRC Services Coding Mailing List <ircservices-coding@ircservices.za.net>
13673 * Sent - 2003-07-25 @ 11:28:00
13674 * Subject - Re: [IRCServices Coding] 2 feature requests
13675 ****************************************/
13677 /****** - Begin Original Message - ******/
13679 >Good idea, but that won't work if Services is on a different machine than
13682 >----- Original Message -----
13683 >From: "Yusuf Iskenderoglu" <uhc0@rz.uni-karlsruhe.de>
13684 >To: "IRC Services Coding Mailing List"
13685 ><ircservices-coding@ircservices.za.net>
13686 >Sent: Thursday, July 24, 2003 12:32 PM
13687 >Subject: Re: [IRCServices Coding] 2 feature requests
13692 >> Link your services using 127.0.0.1; no packet is sent to the network, no
13693 >> additional CPU time will be required to encrypt/decrypt via ssl.
13695 >> Fast. Efficient.
13700 >> On Thu, 2003-07-24 at 12:02, Martin Pels wrote:
13703 >> > On our network we're currently taking a look on how we can make things
13705 >> > secure. And while doiung that we came up with a couple of ideas to
13709 >> > One of the things we did is link all of our servers through SSL, and
13711 >> > clients the option to connect through SSL as well. Now the only thing on
13713 >> > net that isn't connected through SSL is Services.
13714 >> > Are there any plans to add this to IRCServices? I didn't see anything
13716 >> > it in the TODO.
13718 >> > The second idea is about the encrypted passwords. As stated in the
13719 >> > IRCServices documentation SENDPASS and GETPASS won't work with
13721 >> > enabled because of the way md5 works.
13722 >> > This introduces the problem that users will have to contact an Oper in
13724 >> > they lose their password.
13725 >> > Would it be possible to, when encryption is enabled, change the
13727 >> > SENDPASS so that it won't send the user's password (because this is not
13728 >> > possible), but generate a new random password for the user and send that
13730 >> > the user's e-mail address instead?
13734 >> > ------------------------------------------------------------------
13735 >> > To unsubscribe or change your subscription options, visit:
13736 >> > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
13738 >> ------------------------------------------------------------------
13739 >> | Yusuf Iskenderoglu | You get to meet all sorts, |
13740 >> | eMail - uhc0@stud.uni-karlsruhe.de| in this line of work... |
13741 >> | eMail - s_iskend@ira.uka.de | |
13742 >> | ICQ UIN : 20587464 \ TimeMr14C | |
13743 >> ------------------------------------------------------------------
13745 >> ------------------------------------------------------------------
13746 >> To unsubscribe or change your subscription options, visit:
13747 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
13749 >------------------------------------------------------------------
13750 >To unsubscribe or change your subscription options, visit:
13751 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
13754 /******* - End Original Message - *******/
13758 From achurch at achurch.org Fri Jul 25 22:25:58 2003
13759 From: achurch at achurch.org (Andrew Church)
13760 Date: Sat Oct 23 23:09:55 2004
13761 Subject: [IRCServices Coding] 2 feature requests
13762 In-Reply-To: <BAY8-DAV26ZaendgjvM0000135e@hotmail.com>
13763 Message-ID: <3f2131e4.17623@achurch.org>
13765 I'm not seriously considering SSL because I assume that if you're
13766 running Services and the ircd on separate machines, it's because you don't
13767 have enough CPU power to run them both, and adding SSL processing wouldn't
13768 help that condition. If you do want to encrypt the data, I'd assume you
13769 could use tunnelling software to do it. (Poor man's tunnel:
13770 ssh -L localport:remotehost:remoteport remotehost)
13772 The suggestion of making SENDPASS generate a new password has been
13773 suggested before, and I'm considering it as a possibility for 5.1.
13776 achurch@achurch.org
13777 http://achurch.org/
13781 >On our network we're currently taking a look on how we can make things more
13782 >secure. And while doiung that we came up with a couple of ideas to improve
13785 >One of the things we did is link all of our servers through SSL, and gave
13786 >clients the option to connect through SSL as well. Now the only thing on our
13787 >net that isn't connected through SSL is Services.
13788 >Are there any plans to add this to IRCServices? I didn't see anything about
13791 >The second idea is about the encrypted passwords. As stated in the
13792 >IRCServices documentation SENDPASS and GETPASS won't work with encryption
13793 >enabled because of the way md5 works.
13794 >This introduces the problem that users will have to contact an Oper in case
13795 >they lose their password.
13796 >Would it be possible to, when encryption is enabled, change the behaviour of
13797 >SENDPASS so that it won't send the user's password (because this is not
13798 >possible), but generate a new random password for the user and send that to
13799 >the user's e-mail address instead?
13803 >------------------------------------------------------------------
13804 >To unsubscribe or change your subscription options, visit:
13805 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
13806 From Gizm0 at ad2u.gr Sat Aug 2 14:12:32 2003
13807 From: Gizm0 at ad2u.gr (Gizm0)
13808 Date: Sat Oct 23 23:09:55 2004
13809 Subject: [IRCServices Coding] Minor ChanServ bug
13810 In-Reply-To: <1057706268.3f0b511c933d1@webmail.ad2u.gr>
13811 References: <1057706268.3f0b511c933d1@webmail.ad2u.gr>
13812 Message-ID: <1059858752.3f2c29402cdb7@webmail.ad2u.gr>
13814 I don't if anyone got this under his attention but since there was no reply ,
13815 i'm sending the mail again... here it goes...
13818 Ok, think about this.. /chanserv access #channel del all, deletes all channel's
13819 access records..but if there is a nick "All" it does the same, instead of
13820 deleting the "All" access record..I think that there are 2 things that we should
13821 consider and do..add an "if" statement to check if there is a nick "All" in the
13822 channel's access list or forbid the use of nick "All".If we choose the first
13823 one, we can change a little bit the command from "del all" to "del all records"
13824 or "del all nicks" or "del all access(es)"..C u all (: -- :)
13827 IRL: Panagiotis Kefalidis
13828 Brain? No route to host...
13831 From aycan at core.gen.tr Tue Aug 5 13:34:49 2003
13832 From: aycan at core.gen.tr (Aycan iRiCAN)
13833 Date: Sat Oct 23 23:09:55 2004
13834 Subject: [IRCServices Coding] MySQL db module work
13835 Message-ID: <20030805203449.GB13904@core.gen.tr>
13839 I worked on a new mysql db module for ircservices but have no
13840 time to complete the work. So if you wanna look at it:
13842 http://www.core.gen.tr/projeler/ircservices-mysql/
13844 There is a source file, a db dump and my modified Makefile for database
13845 directory of ircservices modules.
13847 PS: note that it's far from a complete module.
13853 | Core Computer Security Group (Member)
13854 | Security Architect & SysAdm
13855 | http://www.core.gen.tr
13856 | GPG KEY = 0x2D002BBF
13857 | Fingerprint = 308E 2721 5E27 3213 975E E92D 2592 7083 2D00 2BBF
13861 "I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'"
13862 --Mike Godwin, Electronic Frontier Foundation
13863 -------------- next part --------------
13864 A non-text attachment was scrubbed...
13865 Name: not available
13866 Type: application/pgp-signature
13868 Desc: not available
13869 Url : http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030805/602cc0b8/attachment.pgp
13870 From playa at dreamchat.org Wed Aug 13 11:54:05 2003
13871 From: playa at dreamchat.org (playa)
13872 Date: Sat Oct 23 23:09:55 2004
13873 Subject: [IRCServices Coding] MARK Command
13874 Message-ID: <3208.66.181.69.244.1060800845.squirrel@dreamchat.org>
13876 First off, i would like to say that IRCservices are the best services out
13877 there, by FAR! Anyways, i was wondering if the MARK command will be in
13878 the next relase? Its kind of a pointless command, its only used to mark
13879 nicks or channels, but it is very useful for when passwords to channels
13882 /chanserv MARK <channel> <reason>
13884 /chanserv info #channel would read the following.
13885 *#channel has been MARKED by playa - <reason>
13887 Of course only IRCops would be able to view it.
13889 Just an idea i thought of :)
13894 Network Founder/CEO
13895 DreamChat IRC Network - irc.dreamchat.org
13896 http://www.dreamchat.org
13898 From saturn at jetirc.net Wed Aug 13 13:22:40 2003
13899 From: saturn at jetirc.net (Saturn)
13900 Date: Sat Oct 23 23:09:55 2004
13901 Subject: [IRCServices Coding] Mass memos
13902 References: <3208.66.181.69.244.1060800845.squirrel@dreamchat.org>
13903 Message-ID: <001601c361d8$a5312f00$6401a8c0@turby>
13905 I put in this request before, and have recently been bombarded by users
13906 requesting thjis feature on my network... Many (if not most) other services
13907 that feature a Memo function also have a Mass memo function.
13909 I have worked around this with IRCServices by creating an mIRC bot that
13912 and then sends a memo to everyone inthe results. Problem is, it sends 2, 3,
13913 4, (even 9 in one case) memos to the same person, because the /ns list *
13914 lists ALL the nicks, and doesn't seem to indicate duplicate, or linked
13915 nicks..... so my poor simple script sends copies to all listed nicks,
13916 resulting in dupes.
13918 Here's the question(s):
13920 Can we reconsider adding a Mass memo function for the next release?
13922 If not, or even if so... one thing puzzles me: In the /ns list * command,
13923 the listings have occasional punctuation... a ! or ? in front of the nick.
13924 There is nothing in the docs anywhere that seems to address this, and I'm
13925 curious as to what those mean.... an explanation would be helpful there too.
13927 Additionally, perhaps we can have some way to glag a nick name as
13928 "Linked" -- not necessarily the Primary name, but the linked nicks... liek
13929 another puntuation in the listing that indicates linked names, so I can
13930 script around it, havign it ignore the marked nicks....
13932 Any ideas you all have to share would be of great help.
13934 And yes, I know at least one person out there is going to suggest Logonnews
13935 as an alternative, but frankly, this does not meet our needs. The news
13936 displays too fast, and has scrolled past before the user even hits the
13937 channels.. I want it as memo, so they can keep them, save them as
13938 reminders, whatever... new memos are more noticeable than a blanket news ...
13940 on that note, a possible suggestion for Logonnews... How about something I
13941 saw on Dalnet once: When new news is added, you get a notice. Until you
13942 read the news, it keeps bugging you when you log on. After you read it, it
13943 stops. Some sort of flag so users know when there IS new news would be
13944 useful... the main reason nobody read the logonnews is that 90% of the time
13945 for them, it is unchanged........
13947 Anyhow, I appreciate your takign the time to read this long request...
13949 I await your replies =)
13955 From mark at ctcp.net Wed Aug 13 14:22:30 2003
13956 From: mark at ctcp.net (M)
13957 Date: Sat Oct 23 23:09:55 2004
13958 Subject: [IRCServices Coding] Mass memos
13959 In-Reply-To: <001601c361d8$a5312f00$6401a8c0@turby>
13960 Message-ID: <000d01c361e1$013a7510$6282edc1@mark2k>
13963 > Can we reconsider adding a Mass memo function for the next release?
13965 I do not think services should include spam functionality. Spam is
13966 enough of a problem without adding features to make it easier to annoy
13969 > If not, or even if so... one thing puzzles me: In the /ns
13970 > list * command, the listings have occasional punctuation...
13971 > a ! or ? in front of the nick. There is nothing in the docs
13972 > anywhere that seems to address this, and I'm curious as to
13973 > what those mean.... an explanation would be helpful there too.
13975 Do an info on the nick. It will explain the purpose of the symbol
13976 (forbidden/noexpire).
13978 > Additionally, perhaps we can have some way to glag a nick
13979 > name as "Linked" -- not necessarily the Primary name, but the
13980 > linked nicks... liek another puntuation in the listing that
13981 > indicates linked names, so I can script around it, havign it
13982 > ignore the marked nicks....
13984 As an SA you can list links for a nick. A user has no need to determine
13985 links of other users.
13987 > the main reason nobody read the logonnews is that
13988 > 90% of the time for them, it is unchanged........
13990 That is why it includes a date and you should delete old news to avoid
13991 vast amounts of useless text. I assume you have a website, so you can
13992 use this to display information that you want people to be able to
13998 Outgoing mail is certified Virus Free.
13999 Checked by AVG anti-virus system (http://www.grisoft.com).
14000 Version: 6.0.507 / Virus Database: 304 - Release Date: 04/08/2003
14003 From saturn at jetirc.net Wed Aug 13 14:49:02 2003
14004 From: saturn at jetirc.net (Saturn)
14005 Date: Sat Oct 23 23:09:55 2004
14006 Subject: [IRCServices Coding] Mass memos
14007 References: <000d01c361e1$013a7510$6282edc1@mark2k>
14008 Message-ID: <001e01c361e4$b60c8f20$6401a8c0@turby>
14013 >> Can we reconsider adding a Mass memo function for the next release?
14015 >I do not think services should include spam functionality. Spam is
14016 >enough of a problem without adding features to make it easier to annoy
14019 This is not spam, and should probably be only accessible by either Services
14020 Admins or Services OPs. The intention is to announce outages, important
14023 >> If not, or even if so... one thing puzzles me: In the /ns
14024 >> list * command, the listings have occasional punctuation...
14025 >> a ! or ? in front of the nick. There is nothing in the docs
14026 >> anywhere that seems to address this, and I'm curious as to
14027 >> what those mean.... an explanation would be helpful there too.
14029 >Do an info on the nick. It will explain the purpose of the symbol
14030 >(forbidden/noexpire).
14032 I did come across that after sending the email to the group. Sadly, it
14033 provides no help whatsoever to the memo question.. but it did shed light on
14034 the question i asked.....
14036 >> Additionally, perhaps we can have some way to glag a nick
14037 >> name as "Linked" -- not necessarily the Primary name, but the
14038 >> linked nicks... liek another puntuation in the listing that
14039 >> indicates linked names, so I can script around it, havign it
14040 >> ignore the marked nicks....
14042 >As an SA you can list links for a nick. A user has no need to determine
14043 >links of other users.
14045 Who decided that? you? Perhaps I would like my users to be able to see the
14046 links for each other... Either way the command is only useful when you
14047 have a "starting point" - a nick that you want to look up...
14049 >> the main reason nobody read the logonnews is that
14050 >> 90% of the time for them, it is unchanged........
14052 >That is why it includes a date and you should delete old news to avoid
14053 >vast amounts of useless text. I assume you have a website, so you can
14054 >use this to display information that you want people to be able to
14057 Frankly, logonnews is useless, and most of my users and opers agree. It
14058 scrolls off too fast. Ideally, it shoudl have a delay to prevent it being
14059 lost in the system notices on connection. Maybe a 10 second delay beforee
14060 it flashes by, to give the user time to connect, etc, and then they might
14061 actually SEE it. Most users I know don't tend to make a habit of readin gth
14062 ebacklog in their status windows when they connect to the network......
14064 Anyhow these were just friendly suggestions, tryign to solve a problem I
14065 have. I don't plan to simply go "OK well, since one or two others out there
14066 think my ideas are dumb for them, obviously I ought to abandon them, because
14067 they MUST be dumb" That attitude is ignorant, and I think my suggestions
14068 had weight and merit. Your objections have merit too, but I see you did not
14069 suggest any useful alternatives or workarounds... Thanks for the input!
14074 From mark at ctcp.net Wed Aug 13 15:10:10 2003
14075 From: mark at ctcp.net (M)
14076 Date: Sat Oct 23 23:09:55 2004
14077 Subject: [IRCServices Coding] Mass memos
14078 In-Reply-To: <001e01c361e4$b60c8f20$6401a8c0@turby>
14079 Message-ID: <000e01c361e7$a9d8c040$6282edc1@mark2k>
14082 > This is not spam, and should probably be only accessible by
14083 > either Services Admins or Services OPs. The intention is to
14084 > announce outages, important events, etc
14086 /os global <message>
14088 > I did come across that after sending the email to the group.
14089 > Sadly, it provides no help whatsoever to the memo question..
14090 > but it did shed light on the question i asked.....
14092 You did not ask a memo question that has an answer, you made a feature
14093 request. The nick prefix has nothing to do with memos.
14095 > >As an SA you can list links for a nick. A user has no need
14097 > >links of other users.
14099 > Who decided that? you? Perhaps I would like my users to be
14101 > links for each other...
14103 I assume the developer decided that but I am more than happy for it to
14104 be that way and would request it to be so or avoid the package if it was
14105 not. Users may have linked nicks that they do not want everybody to know
14106 of. Allowing access to any user will mean they just register separate
14107 nicks again which is more work for them and defeats the advantages of
14110 > Frankly, logonnews is useless, and most of my users and opers
14111 > agree. It scrolls off too fast. Ideally, it shoudl have a
14112 > delay to prevent it being lost in the system notices on
14113 > connection. Maybe a 10 second delay beforee it flashes by,
14114 > to give the user time to connect, etc, and then they might
14117 That is hardly a services issue. The IRCd would be the place to add
14118 false delays into the login process.
14120 I doubt users would welcome having a connection to the network paused
14123 > Most users I know don't tend to make a
14124 > habit of readin gth ebacklog in their status windows when
14125 > they connect to the network......
14127 Many users do not check memos on a regular basis either so spamming via
14128 memoserv would just fill their memo box and they are still are not
14129 guaranteed to be read. They could also add you to their ignore list so
14130 your message would not get through in any case.
14132 > Anyhow these were just friendly suggestions, tryign to solve
14133 > a problem I have. I don't plan to simply go "OK well, since
14134 > one or two others out there think my ideas are dumb for them,
14135 > obviously I ought to abandon them, because they MUST be dumb"
14136 > That attitude is ignorant, and I think my suggestions had
14137 > weight and merit. Your objections have merit too, but I see
14138 > you did not suggest any useful alternatives or workarounds...
14140 You stated in your original message that there were alternative services
14141 packages that provide this. You also said you would not consider using
14142 logonnews. Pointing out the obvious seemed a pointless exercise.
14144 As suggested above, "mass memos" would not solve your "problem".
14149 Outgoing mail is certified Virus Free.
14150 Checked by AVG anti-virus system (http://www.grisoft.com).
14151 Version: 6.0.507 / Virus Database: 304 - Release Date: 04/08/2003
14154 From rg at tcslon.com Wed Aug 13 15:16:55 2003
14155 From: rg at tcslon.com (Russell Garrett)
14156 Date: Sat Oct 23 23:09:55 2004
14157 Subject: [IRCServices Coding] Mass memos
14158 In-Reply-To: <000e01c361e7$a9d8c040$6282edc1@mark2k>
14159 Message-ID: <MKEGJINFADFODDNOKEJCKEPKDOAA.rg@tcslon.com>
14161 >> Frankly, logonnews is useless, and most of my users and opers
14162 >> agree. It scrolls off too fast. Ideally, it shoudl have a
14163 >> delay to prevent it being lost in the system notices on
14164 >> connection. Maybe a 10 second delay beforee it flashes by,
14165 >> to give the user time to connect, etc, and then they might
14166 >> actually SEE it.
14168 > That is hardly a services issue. The IRCd would be the place to add
14169 > false delays into the login process.
14171 > I doubt users would welcome having a connection to the network paused
14172 > for such a reason.
14174 I think he's suggesting introducing a pause before services sends the
14175 notice, so that a user can have all their registration and channel joining
14176 out of the way, so that it appears at the bottom of a window full of
14177 rubbish. Which doesn't sound like such a bad idea.
14181 From quension at mac.com Wed Aug 13 15:30:41 2003
14182 From: quension at mac.com (Trevor Talbot)
14183 Date: Sat Oct 23 23:09:55 2004
14184 Subject: [IRCServices Coding] Mass memos
14185 In-Reply-To: <000e01c361e7$a9d8c040$6282edc1@mark2k>
14186 Message-ID: <C5875B1F-CDDD-11D7-979C-0003938D6866@mac.com>
14188 On Wednesday, Aug 13, 2003, at 15:10 US/Pacific, M wrote:
14191 >> This is not spam, and should probably be only accessible by either
14192 >> Services Admins or Services OPs. The intention is to announce
14193 >> outages, important events, etc
14195 > /os global <message>
14197 That doesn't cover people who aren't online at the time.
14199 >> I did come across that after sending the email to the group. Sadly,
14200 >> it provides no help whatsoever to the memo question.. but it did shed
14201 >> light on the question i asked.....
14203 > You did not ask a memo question that has an answer, you made a feature
14204 > request. The nick prefix has nothing to do with memos.
14206 He described a visibility problem as a reason for the feature request.
14207 He also described a nick linking issue while attempting to handle a
14208 "mass memo" feature on his own. While technically not questions, I
14209 would think it was obvious that responses were desired in those
14212 >> Frankly, logonnews is useless, and most of my users and opers agree.
14213 >> It scrolls off too fast. Ideally, it shoudl have a delay to prevent
14214 >> it being lost in the system notices on connection. Maybe a 10 second
14215 >> delay beforee it flashes by, to give the user time to connect, etc,
14216 >> and then they might actually SEE it.
14218 > That is hardly a services issue. The IRCd would be the place to add
14219 > false delays into the login process.
14221 Logonnews is not part of the ircd's login process.
14223 >> Most users I know don't tend to make a habit of readin gth ebacklog
14224 >> in their status windows when they connect to the network......
14226 > Many users do not check memos on a regular basis either so spamming
14227 > via memoserv would just fill their memo box and they are still are not
14228 > guaranteed to be read. They could also add you to their ignore list so
14229 > your message would not get through in any case.
14231 Memos generally have a much higher visibility than logonnews. You're
14232 welcome to provide very thorough examples to the contrary, but you'll
14233 be working against the tide of experience from a lot of people on a lot
14234 of different networks, apparently including Saturn.
14238 From mark at ctcp.net Wed Aug 13 15:38:09 2003
14239 From: mark at ctcp.net (M)
14240 Date: Sat Oct 23 23:09:55 2004
14241 Subject: [IRCServices Coding] Mass memos
14242 In-Reply-To: <MKEGJINFADFODDNOKEJCKEPKDOAA.rg@tcslon.com>
14243 Message-ID: <000f01c361eb$92aee490$6282edc1@mark2k>
14245 Russell Garrett wrote:
14246 > I think he's suggesting introducing a pause before services
14247 > sends the notice, so that a user can have all their
14248 > registration and channel joining out of the way, so that it
14249 > appears at the bottom of a window full of rubbish. Which
14250 > doesn't sound like such a bad idea.
14252 But an impossible one. What about unregistered users - do they never get
14253 the news? Users that join a channel manually rather than in perform so
14254 would potentially join at this "delay" point?
14256 Such a delay would be unlikely to make any difference but would make an
14257 additional overhead on services while it maintains a list of recently
14258 connected users in order to later send a message to them.
14260 A lot of things that might not sound like a bad idea need a lot more
14261 thought before considering for implementation.
14266 Outgoing mail is certified Virus Free.
14267 Checked by AVG anti-virus system (http://www.grisoft.com).
14268 Version: 6.0.507 / Virus Database: 304 - Release Date: 04/08/2003
14271 From mark at ctcp.net Wed Aug 13 15:48:26 2003
14272 From: mark at ctcp.net (M)
14273 Date: Sat Oct 23 23:09:55 2004
14274 Subject: [IRCServices Coding] Mass memos
14275 In-Reply-To: <C5875B1F-CDDD-11D7-979C-0003938D6866@mac.com>
14276 Message-ID: <001001c361ed$028267f0$6282edc1@mark2k>
14278 Trevor Talbot wrote:
14279 > >> This is not spam, and should probably be only accessible by either
14280 > >> Services Admins or Services OPs. The intention is to announce
14281 > >> outages, important events, etc
14283 > > /os global <message>
14285 > That doesn't cover people who aren't online at the time.
14287 Outages are generally transient. If they involve services, memoserv
14288 would be just as useless as logon news and an /os global if they are
14289 offline when a given user comes online. There are enough ways to warn
14290 users of pre planned outages that will last some time including the
14291 associated web site for the network.
14293 Let us say servies will be upgraded in an hour's time. Ignoring the fact
14294 that we can do this in version 5 with zero effect on connected users,
14295 whatever online system employed will only work for those users connected
14296 at that time. If services was restarted a few times with memos, a number
14297 of users would end up with an "inbox" of pointless notices. /os global
14298 would be the correct place to accounce such things.
14300 > > You did not ask a memo question that has an answer, you
14302 > > request. The nick prefix has nothing to do with memos.
14304 > He described a visibility problem as a reason for the feature
14306 > He also described a nick linking issue while attempting to handle a
14307 > "mass memo" feature on his own. While technically not questions, I
14308 > would think it was obvious that responses were desired in those
14311 This was covered in depth during my response.
14313 > >> Frankly, logonnews is useless, and most of my users and
14315 > >> It scrolls off too fast. Ideally, it shoudl have a delay
14317 > >> it being lost in the system notices on connection. Maybe
14319 > >> delay beforee it flashes by, to give the user time to
14321 > >> and then they might actually SEE it.
14323 > > That is hardly a services issue. The IRCd would be the place to add
14324 > > false delays into the login process.
14326 > Logonnews is not part of the ircd's login process.
14328 But since services uses the IRCd to issue it's messages, introduction of
14329 delay's in the process is an IRCd issue, not a services one. If the IRCd
14330 will not delay, services cannot.
14332 > >> Most users I know don't tend to make a habit of readin gth ebacklog
14333 > >> in their status windows when they connect to the network......
14335 > > Many users do not check memos on a regular basis either so spamming
14336 > > via memoserv would just fill their memo box and they are
14338 > > guaranteed to be read. They could also add you to their
14340 > > your message would not get through in any case.
14342 > Memos generally have a much higher visibility than logonnews.
14344 Really? At logon, the notice of new memos is just as lost as logon news.
14348 > welcome to provide very thorough examples to the contrary, but you'll
14349 > be working against the tide of experience from a lot of
14351 > of different networks, apparently including Saturn.
14353 Without examples supporting the original suggestion, there is no need to
14354 provide contrary ones.
14356 Client configuration has a huge effect on visibility of any information
14357 presented to the user and is beyond the scope of both IRCd and services.
14358 No solution for memo notification or logon news (or indeed /os global)
14359 will defeat client configuration.
14364 Outgoing mail is certified Virus Free.
14365 Checked by AVG anti-virus system (http://www.grisoft.com).
14366 Version: 6.0.507 / Virus Database: 304 - Release Date: 04/08/2003
14369 From saturn at jetirc.net Wed Aug 13 15:51:16 2003
14370 From: saturn at jetirc.net (Saturn)
14371 Date: Sat Oct 23 23:09:55 2004
14372 Subject: [IRCServices Coding] Mass memos
14373 References: <000f01c361eb$92aee490$6282edc1@mark2k>
14374 Message-ID: <003501c361ed$6759fd00$6401a8c0@turby>
14376 OK apparently you just don't read the meaning of my words very well, let me
14379 As to the mass memo function, I did request it as a feature, but also
14380 implied that I would like a suggestion for solutions to my problem...
14381 telling me all the reasons why it is no so, is no help to ANYONE....
14383 As to the delay, you misunderstand me (but apparently at least 2 other
14384 people got it on the first blush): I mean have services delay displaying
14385 the logonnews for 10 seconds (or maybe delay defined in the config); The
14386 whole point is to allow the user to be fully logged in, join a channel, etc,
14387 before the news is displayed to them, so that they will actually NOTICE it.
14389 The global message works just fine, yes, however, if you stop to think about
14390 it, it does NOT notify every user, rather only those that happen to be
14391 online RIGHT NOW. What about the 3/4 to 4/5 of my users who just happen to
14392 be at work, asleep in another time zone, or simply offline today? Shall I
14393 global message every 30 minutes for 24 hours perhaps? sheesh
14395 As for those unregistered users not getting the news: On my network, they
14396 are unregistered, and therefore can go get the news off the website or by
14397 asking around. News is for regulars, and regulars register their nicks.
14398 Registration is there for a reason: You get to keep your nick your own, you
14399 get to have the network remember your access levels on channels, you get
14400 ownership of channels if you wish, and you get access to memo functions,
14401 among many other features. If you choose not to register, then you choose
14402 not to be involved in news memos, channel access lists, and you also choose
14403 not to reserve your nick. That is the choice of the user, and my mass memos
14404 are intended for the network "regulars" -- those that care enough to
14405 register, because they are regulars on the network. I frankly don't care
14406 about getting the news to those who do not wish to register.
14408 If you want to be 100% equal to all users, then why not simply not run
14409 services in the first place? The whole point is that everyone registers.
14410 Those that don't, do so of their own choice, and I think most users know
14411 what they're giving up.
14413 And for the record, mass memos as I've been forced to do them thus far, have
14414 been met with good reviews and do, in fact, solve my problem. The only
14415 hitch is that people with linked nicks end up with multiple copies, and I
14416 would appreciate an easier way to a) send a memo to all users, and b) avoid
14417 users receiving multiple copies if they have linked nicks. Is this really
14418 so much to ask for?
14420 Your condescending attitude is certainly not appreciated, and I will be
14421 ignoring any future posts you make to this discussion group, but will be
14422 eagerly reading any other suggestions anyone else does post.
14424 Thanks to Trevor and Russell for the support on my suggestions -- at least I
14425 know the friendly folks in the group can understand what I meant...
14430 ----- Original Message -----
14431 From: "M" <mark@ctcp.net>
14432 To: "'IRC Services Coding Mailing List'"
14433 <ircservices-coding@ircservices.za.net>
14434 Sent: Wednesday, August 13, 2003 3:38 PM
14435 Subject: RE: [IRCServices Coding] Mass memos
14438 Russell Garrett wrote:
14439 > I think he's suggesting introducing a pause before services
14440 > sends the notice, so that a user can have all their
14441 > registration and channel joining out of the way, so that it
14442 > appears at the bottom of a window full of rubbish. Which
14443 > doesn't sound like such a bad idea.
14445 But an impossible one. What about unregistered users - do they never get
14446 the news? Users that join a channel manually rather than in perform so
14447 would potentially join at this "delay" point?
14449 Such a delay would be unlikely to make any difference but would make an
14450 additional overhead on services while it maintains a list of recently
14451 connected users in order to later send a message to them.
14453 A lot of things that might not sound like a bad idea need a lot more
14454 thought before considering for implementation.
14459 Outgoing mail is certified Virus Free.
14460 Checked by AVG anti-virus system (http://www.grisoft.com).
14461 Version: 6.0.507 / Virus Database: 304 - Release Date: 04/08/2003
14464 ------------------------------------------------------------------
14465 To unsubscribe or change your subscription options, visit:
14466 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
14469 From mark at ctcp.net Wed Aug 13 16:21:57 2003
14470 From: mark at ctcp.net (M)
14471 Date: Sat Oct 23 23:09:55 2004
14472 Subject: [IRCServices Coding] Mass memos
14473 In-Reply-To: <003501c361ed$6759fd00$6401a8c0@turby>
14474 Message-ID: <001301c361f1$b128a770$6282edc1@mark2k>
14477 > As to the mass memo function, I did request it as a feature,
14478 > but also implied that I would like a suggestion for solutions
14479 > to my problem... telling me all the reasons why it is no so,
14480 > is no help to ANYONE....
14482 Is every response to a post required to address every single one of a
14483 the posted questions or suggestions? That is not the nature of a mailing
14484 list. Members are free to respond to all/some/none of a post.
14486 Discussion, particularly for new features has to include all aspects
14487 whether or not they agree with you.
14489 > As to the delay, you misunderstand me (but apparently at
14490 > least 2 other people got it on the first blush): I mean have
14491 > services delay displaying the logonnews for 10 seconds (or
14492 > maybe delay defined in the config); The whole point is to
14493 > allow the user to be fully logged in, join a channel, etc,
14494 > before the news is displayed to them, so that they will
14495 > actually NOTICE it.
14497 You are assuming that people will switch back to their status window
14498 after having joined channels and started chatting in them. This IME does
14499 not happen at the moment so why would a delay make it happen.
14501 > The global message works just fine, yes, however, if you stop
14502 > to think about it, it does NOT notify every user, rather only
14503 > those that happen to be online RIGHT NOW. What about the 3/4
14504 > to 4/5 of my users who just happen to be at work, asleep in
14505 > another time zone, or simply offline today? Shall I global
14506 > message every 30 minutes for 24 hours perhaps? sheesh
14508 Did I suggest that? No.
14510 If you have outages which take a long time to correct, then I suggest
14511 that is the problem to address. A services upgrade (with the 5.0 series)
14512 can be done within seconds with no impact on online users and no need to
14513 spam every user of the network to warn of it. An /os global in such a
14514 case is merely polite.
14516 Outages generally only affect online users, so /os global is a useful
14517 way to let them know of an upcoming outage. Pre planning every outage is
14518 not feasible IRL. What if you plan a particular outage, then have to
14519 cancel and replan. Three memos - one for first plan, second to cancel,
14520 third to rebook. Similar for an outage that does not achieve the desired
14523 As with logon news, users can choose to read their memos or not. If they
14524 choose not to or to ignore messages from you, you do not achieve the
14525 effect you desire. Logon news is not optional. Memos are.
14527 There are various options available to you with current systems. A
14528 mailing list in conjunction with the web site would be far better and
14529 would be opt in. Any system which a user has to opt out of or in this
14530 case has no option to and must ignore the user (in this case you and any
14531 other mass memo senders) is spam.
14533 > As for those unregistered users not getting the news: On my
14534 > network, they are unregistered, and therefore can go get the
14535 > news off the website or by asking around. News is for
14536 > regulars, and regulars register their nicks.
14538 A user who does not have a registered nick, is not necessarily someone
14539 who has chosen not to register. It may be a new user (to the network or
14540 to IRC). In this case, the server they just joined (or maybe services)
14541 is about to go to outage and their lack of registration means they are
14542 unaware of it from mass memo so just go elsewhere.
14544 Personally I do not discriminate against unregistered users.
14545 Registration provides more features but is not a requirement.
14547 It looks like you are requesting an "on /ns identify news" rather than
14548 logon news. This is somewhat simpler to implement but a different
14549 request. It does not remove the requirement for logon news for all users
14550 whether new users that are not yet registered or registered users on an
14551 auto connect that have not identified.
14553 > If you want to be 100% equal to all users, then why not
14554 > simply not run services in the first place? The whole point
14555 > is that everyone registers. Those that don't, do so of their
14556 > own choice, and I think most users know what they're giving up.
14558 Not at all. It is a service provided for the users that they can choose
14561 > And for the record, mass memos as I've been forced to do them
14562 > thus far, have been met with good reviews and do, in fact,
14563 > solve my problem. The only hitch is that people with linked
14564 > nicks end up with multiple copies, and I would appreciate an
14565 > easier way to a) send a memo to all users, and b) avoid users
14566 > receiving multiple copies if they have linked nicks. Is this
14567 > really so much to ask for?
14569 I have stated my opinions on this in previous posts and this one.
14571 > Your condescending attitude is certainly not appreciated, and
14575 > I will be ignoring any future posts you make to this
14576 > discussion group, but will be eagerly reading any other
14577 > suggestions anyone else does post.
14581 Would you care to share publicly how inaccurate the above statement you
14584 > Thanks to Trevor and Russell for the support on my
14585 > suggestions -- at least I know the friendly folks in the
14586 > group can understand what I meant...
14593 Outgoing mail is certified Virus Free.
14594 Checked by AVG anti-virus system (http://www.grisoft.com).
14595 Version: 6.0.507 / Virus Database: 304 - Release Date: 04/08/2003
14598 From quension at mac.com Wed Aug 13 17:28:05 2003
14599 From: quension at mac.com (Trevor Talbot)
14600 Date: Sat Oct 23 23:09:55 2004
14601 Subject: [IRCServices Coding] Mass memos
14602 In-Reply-To: <001001c361ed$028267f0$6282edc1@mark2k>
14603 Message-ID: <2C31F186-CDEE-11D7-979C-0003938D6866@mac.com>
14605 On Wednesday, Aug 13, 2003, at 15:48 US/Pacific, M wrote:
14607 > Trevor Talbot wrote:
14608 >>>> This is not spam, and should probably be only accessible by either
14609 >>>> Services Admins or Services OPs. The intention is to announce
14610 >>>> outages, important events, etc
14612 >>> /os global <message>
14614 >> That doesn't cover people who aren't online at the time.
14616 > Outages are generally transient. If they involve services, memoserv
14617 > would be just as useless as logon news and an /os global if they are
14618 > offline when a given user comes online. There are enough ways to warn
14619 > users of pre planned outages that will last some time including the
14620 > associated web site for the network.
14622 I agree with you on the specific case of outages, but I was speaking
14625 >>>> Frankly, logonnews is useless, and most of my users and opers
14626 >>>> agree. It scrolls off too fast. Ideally, it shoudl have a delay
14627 >>>> to prevent it being lost in the system notices on connection.
14628 >>>> Maybe a 10 second delay beforee it flashes by, to give the user
14629 >>>> time to connect, etc, and then they might actually SEE it.
14631 >>> That is hardly a services issue. The IRCd would be the place to add
14632 >>> false delays into the login process.
14634 >> Logonnews is not part of the ircd's login process.
14636 > But since services uses the IRCd to issue it's messages, introduction
14637 > of delay's in the process is an IRCd issue, not a services one. If the
14638 > IRCd will not delay, services cannot.
14640 Services issues the messages itself. The only sense in which it uses
14641 the ircd is the same as for any other entity on the network: the ircd
14642 is a relay point. Services' issuance of messages is not tied to any
14643 part of the ircd's login process, nor is it affected by any delays
14646 >>>> Most users I know don't tend to make a habit of readin gth ebacklog
14647 >>>> in their status windows when they connect to the network......
14649 >>> Many users do not check memos on a regular basis either so
14650 >>> spammingvia memoserv would just fill their memo box and they are
14651 >>> still are not guaranteed to be read. They could also add you to
14652 >>> their ignore list so your message would not get through in any case.
14654 >> Memos generally have a much higher visibility than logonnews.
14656 > Really? At logon, the notice of new memos is just as lost as logon
14659 Yes, but this a psychological issue, not a logical one. Many people
14660 deal with large amounts of information, and so may notice the memo
14661 notification while unconsciously ignoring the login news (much like
14662 motds are ignored). This is just speculation, of course.
14664 Memo visibility is logically heightened by notification in other
14665 circumstances: nick changes, identification, etc.
14667 > Client configuration has a huge effect on visibility of any
14668 > information presented to the user and is beyond the scope of both IRCd
14669 > and services. No solution for memo notification or logon news (or
14670 > indeed /os global) will defeat client configuration.
14672 The best solution for this issue in general would be to have clients
14673 become "information managers", where they could do things such as
14674 deciding if the motd or logonnews has changed since last connect,
14675 providing alerts if necessary, and so on. The ircd and services would
14676 need to provide standard formats for this information. Unfortunately
14677 we're nowhere near the point where this would be useful, especially
14678 considering the motd format has been standard for a very long time, and
14679 clients haven't done much with it.
14681 In the meantime, things such as mass memos are useful for a variety of
14686 From Craig at chatspike.net Wed Aug 13 21:15:10 2003
14687 From: Craig at chatspike.net (Craig McLure)
14688 Date: Sat Oct 23 23:09:55 2004
14689 Subject: [IRCServices Coding] Mass memos
14690 Message-ID: <20030814031524.KRJE14751.mta1-svc.business.ntl.com@i-br0ked-it>
14692 I'd have to agree that this is a much better idea than a mass memo, soley for the fact that many of our users come once, dissappear for a few weeks, then come back.. To come back to a box full of memos which no longer regard them could be a problem, and would cause complaints. To have logonnews somewhere where all the users can see it, and where it wont prompty be hidden by IRCd spam would be a much better alternative.
14694 If you really wanted mass memo, it shouldnt really be too hard to make a simple module that did it...
14697 Craig "FrostyCoolSlug" McLure..
14698 Netadmin of the ChatSpike IRC Network..
14699 ChatSpike.. Now with Web-Based Services frontend! http://www.chatspike.net
14701 /****************************************
14702 * From - Russell Garrett <rg@tcslon.com>
14703 * To - mark <mark@ctcp.net>
14704 * Sent - 2003-08-13 @ 23:16:00
14705 * Subject - RE: [IRCServices Coding] Mass memos
14706 ****************************************/
14708 /****** - Begin Original Message - ******/
14710 >>> Frankly, logonnews is useless, and most of my users and opers
14711 >>> agree. It scrolls off too fast. Ideally, it shoudl have a
14712 >>> delay to prevent it being lost in the system notices on
14713 >>> connection. Maybe a 10 second delay beforee it flashes by,
14714 >>> to give the user time to connect, etc, and then they might
14715 >>> actually SEE it.
14717 >> That is hardly a services issue. The IRCd would be the place to add
14718 >> false delays into the login process.
14720 >> I doubt users would welcome having a connection to the network paused
14721 >> for such a reason.
14723 >I think he's suggesting introducing a pause before services sends the
14724 >notice, so that a user can have all their registration and channel joining
14725 >out of the way, so that it appears at the bottom of a window full of
14726 >rubbish. Which doesn't sound like such a bad idea.
14730 >------------------------------------------------------------------
14731 >To unsubscribe or change your subscription options, visit:
14732 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
14735 /******* - End Original Message - *******/
14739 From mark at ctcp.net Thu Aug 14 14:38:24 2003
14740 From: mark at ctcp.net (M)
14741 Date: Sat Oct 23 23:09:55 2004
14742 Subject: [IRCServices Coding] Mass memos
14743 In-Reply-To: <2C31F186-CDEE-11D7-979C-0003938D6866@mac.com>
14744 Message-ID: <001201c362ac$64109090$6282edc1@mark2k>
14746 Trevor Talbot wrote:
14747 > Services issues the messages itself. The only sense in which it uses
14748 > the ircd is the same as for any other entity on the network: the ircd
14749 > is a relay point. Services' issuance of messages is not tied to any
14750 > part of the ircd's login process, nor is it affected by any delays
14753 Merely issuing logonnews messages later in the process would be unlikely
14754 to make any difference to visibility. The delay picked will likely
14755 still conflict with other incoming messages and likely relies on the
14756 user returning to the status window after whatever they fill the gap
14757 with prior to the message. Neither the IRCd nor services can accurately
14758 predict a point at which logon news would not be placed amid other
14759 messages so merely issuing it later will not solve the issue. It will
14760 merely put it into a different place during the process that users who
14761 do read it will not expect.
14763 I originally assumed that the proposal was to force users to see it by
14764 pausing at that point (time delay or press any key style AKA telnet
14765 login notices) which would be an IRCd issue to support such a delay, not
14766 a services one. I would not support this system either since users
14767 generally want to get onto the network and chatting ASAP.
14770 > deal with large amounts of information, and so may notice the memo
14771 > notification while unconsciously ignoring the login news (much like
14772 > motds are ignored). This is just speculation, of course.
14774 I see what you are saying but disagree with the conclusion. It is not
14775 supported by the number of users who incorrectly identify for a nickname
14776 then are most surprised when they are "guested". If they miss the
14777 failure notice, they are equally likely to miss the memoserv notice.
14779 We only use logon news to announce important events so it is immediately
14780 obvious to people when it changes since there is normally nothing
14781 displayed at that point and the logon process looks different when it is
14782 displayed. Conversely, I have found a number of users (particularly
14783 newcomers) tend not to notice any message from memoserv since the
14784 message occurs at every logon and the pattern is so familiar to them
14785 they tend not to read the notice closely.
14787 One thought does occur with the mention of MOTD, a client can issue this
14788 command to retrieve the message whenever they desire but they cannot do
14789 this with logon news (IRCops aside). Maybe the solution is not messing
14790 around with delays, but thinking of a new way to propagate this
14791 information. The quick way would of course be to allow /os logonnews
14792 list to all users. However, I favour keeping OperServ solely accessible
14793 to opers so would suggest "NewsServ" or similar as a way to allow end
14794 users to access current news on demand.
14796 > Memo visibility is logically heightened by notification in other
14797 > circumstances: nick changes, identification, etc.
14799 IME, a great number of clients do not change nickname that often (if at
14800 all) and once identified tend to remain that way. IIRC, the new linked
14801 nick system, means that those that do tend to use multiple nicks do not
14802 have to identify for the change should it be so linked. Increasingly
14803 users use clients or additional scripts to automatically identify to
14804 services. The lack of user input into the process further decreases the
14805 notice a user will take of notices in response to identification etc.
14807 > The best solution for this issue in general would be to have clients
14808 > become "information managers", where they could do things such as
14809 > deciding if the motd or logonnews has changed since last connect,
14810 > providing alerts if necessary, and so on. The ircd and services would
14811 > need to provide standard formats for this information. Unfortunately
14812 > we're nowhere near the point where this would be useful, especially
14813 > considering the motd format has been standard for a very long
14815 > clients haven't done much with it.
14817 ISTR at least a couple clients that tried to do something with it such
14818 as routing it to a separate window. There are ways to improve the
14819 process but as you suggest, they really require changes to both the IRCd
14820 (or at least adding some field(s) to the MOTD file) along with client
14823 /os global tends to suffer from visibility for similar reasons to logon
14824 news and other notices. However, IME sufficient users are aware of them
14825 and paste within channels so that those others see them. Similar occurs
14826 with logon news with it being discussed in channels in front of those
14827 users that do not bother to read it.
14829 Much of the visibility is down to clients and the way that a user uses
14830 IRC. These things are beyond our control. However, approaching the
14831 writers of the more common clients/scripts may be the way to get the
14832 clients to perform better in this regard. Trapping the MOTD is
14833 relatively trivial for a client. For IRCServices at least, trapping
14834 logon news should be similarly trivial (given the format of the notice).
14837 Some IRCd packages are now implementing a dual MOTD system. At logon,
14838 the user is presented only with a "short MOTD" which can act as a
14839 "headline" that the user can further read by requesting the full MOTD.
14840 This helps reduce the redundant information passed to a user on connect
14841 and clean up the connection process as well as saving some bandwidth.
14843 > In the meantime, things such as mass memos are useful for a variety of
14846 I disagree. A mailing list would be a much better system to employ. It
14847 is opt in, creates no additional load on services and is more likely to
14848 be read than a memo by all users who subscribe. Couple this with web
14849 based information and you cover users who choose not to have the
14850 additional emails and do not read logon news.
14852 A user unable to receive memos from friends because their memo box is
14853 full of messages about stuff on the network that they may have no
14854 interest in reading is not IMO a useful feature. As another poster
14855 mentioned, those users who visit infrequently are the most likely to
14856 suffer in this scenario. Filling the memo box via mass memos will for
14857 all practical purposes destroy the memoserv facility for a number of
14860 Since a mass memo system should really be opt in, it is a simple matter
14861 for those interested to register their name in some manner with whoever
14862 wants to send mass memos, then the sender use a simple script to message
14863 only those users. This can be done without any required change to
14864 services and would not be subject to the problems in the OP's original
14865 script wrt linked nicknames. Such a script merely needs to parse the
14866 response from memoserv to automatically delete expired nicknames
14867 registered with the system.
14872 Outgoing mail is certified Virus Free.
14873 Checked by AVG anti-virus system (http://www.grisoft.com).
14874 Version: 6.0.507 / Virus Database: 304 - Release Date: 04/08/2003
14877 From playa at dreamchat.org Fri Aug 15 15:38:44 2003
14878 From: playa at dreamchat.org (playa)
14879 Date: Sat Oct 23 23:09:55 2004
14880 Subject: [Fwd: [IRCServices Coding] MARK Command]
14881 Message-ID: <11258.64.108.85.48.1060987125.squirrel@dreamchat.org>
14883 I didnt know if anyone got my last e-mail, or if they were ignoring
14884 me...but i was wondering if the MARK command could be added in the next
14888 First off, i would like to say that IRCservices are the best services out
14889 there, by FAR! Anyways, i was wondering if the MARK command will be in
14890 the next relase? Its kind of a pointless command, its only used to mark
14891 nicks or channels, but it is very useful for when passwords to channels
14894 /chanserv MARK <channel> <reason>
14896 /chanserv info #channel would read the following.
14897 *#channel has been MARKED by playa - <reason>
14899 Of course only IRCops would be able to view it.
14901 Just an idea i thought of :)
14906 Network Founder/CEO
14907 DreamChat IRC Network - irc.dreamchat.org
14908 http://www.dreamchat.org
14912 From Craig at chatspike.net Sat Aug 16 09:28:53 2003
14913 From: Craig at chatspike.net (Craig McLure)
14914 Date: Sat Oct 23 23:09:55 2004
14915 Subject: [Fwd: [IRCServices Coding] MARK Command]
14916 Message-ID: <20030816152909.XKRN2678.mta4-svc.business.ntl.com@i-br0ked-it>
14918 we all saw the first email.. and personally, i dont see a point..
14922 /****************************************
14923 * Craig "FrostyCoolSlug" McLure
14924 ************* - SpamBox - **************
14925 * InspIRCd - http://www.inspircd.org
14926 * ChatSpike - http://www.chatspike.net
14927 * WinBot - http://www.winbot.co.uk
14928 ****************************************/
14930 /****************************************
14931 * From - playa <playa@dreamchat.org>
14932 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
14933 * Sent - 2003-08-15 @ 18:38:00
14934 * Subject - [Fwd: [IRCServices Coding] MARK Command]
14935 ****************************************/
14937 /****** - Begin Original Message - ******/
14939 >I didnt know if anyone got my last e-mail, or if they were ignoring
14940 >me...but i was wondering if the MARK command could be added in the next
14944 >First off, i would like to say that IRCservices are the best services out
14945 >there, by FAR! Anyways, i was wondering if the MARK command will be in
14946 >the next relase? Its kind of a pointless command, its only used to mark
14947 >nicks or channels, but it is very useful for when passwords to channels
14950 >/chanserv MARK <channel> <reason>
14952 >/chanserv info #channel would read the following.
14953 >*#channel has been MARKED by playa - <reason>
14955 >Of course only IRCops would be able to view it.
14957 >Just an idea i thought of :)
14962 >Network Founder/CEO
14963 >DreamChat IRC Network - irc.dreamchat.org
14964 >http://www.dreamchat.org
14968 >------------------------------------------------------------------
14969 >To unsubscribe or change your subscription options, visit:
14970 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
14973 /******* - End Original Message - *******/
14977 From aragon at phat.za.net Sat Aug 16 11:37:31 2003
14978 From: aragon at phat.za.net (Aragon Gouveia)
14979 Date: Sat Oct 23 23:09:55 2004
14980 Subject: [Fwd: [IRCServices Coding] MARK Command]
14981 In-Reply-To: <20030816152909.XKRN2678.mta4-svc.business.ntl.com@i-br0ked-it>
14982 References: <20030816152909.XKRN2678.mta4-svc.business.ntl.com@i-br0ked-it>
14983 Message-ID: <20030816183731.GE8135@phat.za.net>
14985 It may be useful for keeping track/history of abuse.
14988 | By Craig McLure <Craig@chatspike.net>
14989 | [ 2003-08-16 17:29 +0200 ]
14990 > we all saw the first email.. and personally, i dont see a point..
14992 > But thats just me.
14994 > /****************************************
14995 > * Craig "FrostyCoolSlug" McLure
14996 > ************* - SpamBox - **************
14997 > * InspIRCd - http://www.inspircd.org
14998 > * ChatSpike - http://www.chatspike.net
14999 > * WinBot - http://www.winbot.co.uk
15000 > ****************************************/
15002 > /****************************************
15003 > * From - playa <playa@dreamchat.org>
15004 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
15005 > * Sent - 2003-08-15 @ 18:38:00
15006 > * Subject - [Fwd: [IRCServices Coding] MARK Command]
15007 > ****************************************/
15009 > /****** - Begin Original Message - ******/
15011 > >I didnt know if anyone got my last e-mail, or if they were ignoring
15012 > >me...but i was wondering if the MARK command could be added in the next
15015 > >Original E-mail:
15016 > >First off, i would like to say that IRCservices are the best services out
15017 > >there, by FAR! Anyways, i was wondering if the MARK command will be in
15018 > >the next relase? Its kind of a pointless command, its only used to mark
15019 > >nicks or channels, but it is very useful for when passwords to channels
15020 > >have been denied.
15022 > >/chanserv MARK <channel> <reason>
15024 > >/chanserv info #channel would read the following.
15025 > >*#channel has been MARKED by playa - <reason>
15027 > >Of course only IRCops would be able to view it.
15029 > >Just an idea i thought of :)
15034 > >Network Founder/CEO
15035 > >DreamChat IRC Network - irc.dreamchat.org
15036 > >http://www.dreamchat.org
15040 > >------------------------------------------------------------------
15041 > >To unsubscribe or change your subscription options, visit:
15042 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
15045 > /******* - End Original Message - *******/
15049 > ------------------------------------------------------------------
15050 > To unsubscribe or change your subscription options, visit:
15051 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
15052 From simorgh at dataphone.se Sun Aug 17 08:27:31 2003
15053 From: simorgh at dataphone.se (Ali Simorgh)
15054 Date: Sat Oct 23 23:09:55 2004
15055 Subject: [IRCServices Coding] OP/Voice upon identify
15056 Message-ID: <Pine.GSO.4.31.0308171723030.4569-100000@nikson.dataphone.se>
15060 I wonder if its possible to make some modification that:
15061 when someone has already joined a few channels, and then identifies to its
15062 nickname, chanserv gives Voice and/or Op to the user is s/he is in the
15063 channel list (+o; aop or above & +v when vop)
15065 this is very usefull to not privmsg chanserv for every op or voice
15066 request, when user has not identified to its nick before joining channels.
15068 Thanks for any help
15072 ______________________________________________________
15073 Many of life's failures are people who did not realize
15074 how close they were to success when they gave up.
15076 ______________________________________________________
15079 From rg at tcslon.com Sun Aug 17 11:20:58 2003
15080 From: rg at tcslon.com (Russell Garrett)
15081 Date: Sat Oct 23 23:09:55 2004
15082 Subject: [IRCServices Coding] OP/Voice upon identify
15083 In-Reply-To: <Pine.GSO.4.31.0308171723030.4569-100000@nikson.dataphone.se>
15084 Message-ID: <MKEGJINFADFODDNOKEJCMEEADPAA.rg@tcslon.com>
15086 Eh? This has been implemented since IRCServices 5a31.
15090 > I wonder if its possible to make some modification that:
15091 > when someone has already joined a few channels, and then identifies
15092 > to its nickname, chanserv gives Voice and/or Op to the user is s/he
15093 > is in the channel list (+o; aop or above & +v when vop)
15095 > this is very usefull to not privmsg chanserv for every op or voice
15096 > request, when user has not identified to its nick before joining
15099 > Thanks for any help
15101 From simorgh at dataphone.se Sun Aug 17 12:28:48 2003
15102 From: simorgh at dataphone.se (Ali Simorgh)
15103 Date: Sat Oct 23 23:09:55 2004
15104 Subject: [IRCServices Coding] Language
15105 Message-ID: <Pine.GSO.4.31.0308172127300.9882-100000@nikson.dataphone.se>
15109 Is there any tool (silly question) or something or guid to make a language
15112 I have decided to make a Persian (Farsi) language file.
15114 Thanks for any ideas
15118 ______________________________________________________
15119 Many of life's failures are people who did not realize
15120 how close they were to success when they gave up.
15122 ______________________________________________________
15125 From Craig at chatspike.net Sun Aug 17 15:00:22 2003
15126 From: Craig at chatspike.net (Craig McLure)
15127 Date: Sat Oct 23 23:09:55 2004
15128 Subject: [IRCServices Coding] Language
15129 Message-ID: <20030817210034.LASX27989.mta1-svc.business.ntl.com@i-br0ked-it>
15131 Find the english language file in the source..
15133 Read the warnings about format etc, and work with that :)
15135 /****************************************
15136 * Craig "FrostyCoolSlug" McLure
15137 ************* - SpamBox - **************
15138 * InspIRCd - http://www.inspircd.org
15139 * ChatSpike - http://www.chatspike.net
15140 * WinBot - http://www.winbot.co.uk
15141 ****************************************/
15143 /****************************************
15144 * From - Ali Simorgh <simorgh@dataphone.se>
15145 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
15146 * Sent - 2003-08-17 @ 21:28:00
15147 * Subject - [IRCServices Coding] Language
15148 ****************************************/
15150 /****** - Begin Original Message - ******/
15154 >Is there any tool (silly question) or something or guid to make a language
15157 >I have decided to make a Persian (Farsi) language file.
15159 >Thanks for any ideas
15163 > ______________________________________________________
15164 > Many of life's failures are people who did not realize
15165 > how close they were to success when they gave up.
15167 > ______________________________________________________
15170 >------------------------------------------------------------------
15171 >To unsubscribe or change your subscription options, visit:
15172 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
15174 /******* - End Original Message - *******/
15178 From rg at tcslon.com Sun Aug 17 14:09:42 2003
15179 From: rg at tcslon.com (Russell Garrett)
15180 Date: Sat Oct 23 23:09:55 2004
15181 Subject: [IRCServices Coding] Language
15182 In-Reply-To: <20030817210034.LASX27989.mta1-svc.business.ntl.com@i-br0ked-it>
15183 Message-ID: <MKEGJINFADFODDNOKEJCKEEDDPAA.rg@tcslon.com>
15185 > Find the english language file in the source..
15187 > Read the warnings about format etc, and work with that :)
15189 A sort-of-related matter - I have a few patches against the English language
15190 file to change such stuff as /msg nickserv to /nickserv, partly for neatness
15191 and partly because /msging services is generally bad practice where networks
15192 have more secure aliases. It's sort of painful to keep up to date though,
15193 since every time the language file changes I have to fiddle about patching
15196 I wonder if it would be worth integrating such a thing into services as an
15197 option (compile-time maybe?). I think it would be good for the irc community
15198 as a whole to get away from the habit of msging services directly if at all
15199 possible. Opinions?
15203 From Ganja51 at lcirc.net Sun Aug 17 19:04:33 2003
15204 From: Ganja51 at lcirc.net (Ganja51)
15205 Date: Sat Oct 23 23:09:55 2004
15206 Subject: [IRCServices Coding] Language
15207 References: <MKEGJINFADFODDNOKEJCKEEDDPAA.rg@tcslon.com>
15208 Message-ID: <002301c3652d$115d80a0$1402a8c0@monte>
15210 this is primarily handled at the ircd level and IMHO it's fine staying that
15211 way. on my network i have aliases setup so you could /msg nickserv,
15212 /nickserv, or /ns. all of them work just fine because the ircd handles all
15213 the aliases. personally i see no need for a change.
15216 ----- Original Message -----
15217 From: "Russell Garrett" <rg@tcslon.com>
15218 To: "IRC Services Coding Mailing List"
15219 <ircservices-coding@ircservices.za.net>
15220 Sent: Sunday, August 17, 2003 4:09 PM
15221 Subject: RE: [IRCServices Coding] Language
15224 > > Find the english language file in the source..
15226 > > Read the warnings about format etc, and work with that :)
15228 > A sort-of-related matter - I have a few patches against the English
15230 > file to change such stuff as /msg nickserv to /nickserv, partly for
15232 > and partly because /msging services is generally bad practice where
15234 > have more secure aliases. It's sort of painful to keep up to date though,
15235 > since every time the language file changes I have to fiddle about patching
15238 > I wonder if it would be worth integrating such a thing into services as an
15239 > option (compile-time maybe?). I think it would be good for the irc
15241 > as a whole to get away from the habit of msging services directly if at
15243 > possible. Opinions?
15247 > ------------------------------------------------------------------
15248 > To unsubscribe or change your subscription options, visit:
15249 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
15251 From Craig at chatspike.net Sun Aug 17 20:40:03 2003
15252 From: Craig at chatspike.net (Craig McLure)
15253 Date: Sat Oct 23 23:09:55 2004
15254 Subject: [IRCServices Coding] Language
15255 Message-ID: <20030818024020.LUZS29825.mta5-svc.business.ntl.com@i-br0ked-it>
15257 I'd have to agree, i encourage all my users to use /nickserv or /ns, however, the services help files keep telling them to use /msg nickserv.. maybe something like, MSG_NICKSERV, MSG_CHANSERV, etc in the config files, and in the help files, just a %s to signify where it would go.. means anyone can change it to say whatever they want :)
15259 /****************************************
15260 * Craig "FrostyCoolSlug" McLure
15261 ************* - SpamBox - **************
15262 * InspIRCd - http://www.inspircd.org
15263 * ChatSpike - http://www.chatspike.net
15264 * WinBot - http://www.winbot.co.uk
15265 ****************************************/
15267 /****************************************
15268 * From - Russell Garrett <rg@tcslon.com>
15269 * To - IRC Services Coding Mailing List <ircservices-coding@ircservices.za.net>
15270 * Sent - 2003-08-17 @ 22:09:00
15271 * Subject - RE: [IRCServices Coding] Language
15272 ****************************************/
15274 /****** - Begin Original Message - ******/
15276 >> Find the english language file in the source..
15278 >> Read the warnings about format etc, and work with that :)
15280 >A sort-of-related matter - I have a few patches against the English language
15281 >file to change such stuff as /msg nickserv to /nickserv, partly for neatness
15282 >and partly because /msging services is generally bad practice where networks
15283 >have more secure aliases. It's sort of painful to keep up to date though,
15284 >since every time the language file changes I have to fiddle about patching
15287 >I wonder if it would be worth integrating such a thing into services as an
15288 >option (compile-time maybe?). I think it would be good for the irc community
15289 >as a whole to get away from the habit of msging services directly if at all
15290 >possible. Opinions?
15294 >------------------------------------------------------------------
15295 >To unsubscribe or change your subscription options, visit:
15296 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
15299 /******* - End Original Message - *******/
15303 From waterflamez at hotmail.com Tue Aug 19 17:16:25 2003
15304 From: waterflamez at hotmail.com (Jack Neils)
15305 Date: Sat Oct 23 23:09:55 2004
15306 Subject: [IRCServices Coding] encrypt hostnames
15307 Message-ID: <Law14-F109aJWJVUn700006a187@hotmail.com>
15311 i'm using unrealircd with ircservices 5.0.21, and i already modified the
15314 in modules/nickserv/main.c :
15316 /* Callback for users connecting to the network. */
15317 /* MODIFIED CALLBACK */
15318 static int do_user_create(User *user, int ac, char **av)
15320 validate_user(user);
15321 send_cmd(s_OperServ, "CHGHOST %s :%s", user->nick, "domain.net");
15322 send_cmd(s_OperServ, "CHGIDENT %s :%s", user->nick, "user");
15326 good to start with and hide userhosts, but soon i found out 1 big problem:
15327 try banning 1 person from a channel... +b *!user@domain.net ...
15328 ironic, isn't it? you'd be banning everyone at once.
15329 and banning with nick isn't very effective.
15331 so now i was wondering if anyonce could help me use the encrypt function,
15332 which is used on the passwords with nickserv, to encrypt the hostmask.
15333 and, after the hostmask has been encrypted, send that as the new hostmask.
15335 anyone that can help me, please ?
15339 _________________________________________________________________
15340 MSN Search, for relevant search results! http://search.msn.be
15342 From Craig at chatspike.net Wed Aug 20 18:55:52 2003
15343 From: Craig at chatspike.net (Craig McLure)
15344 Date: Sat Oct 23 23:09:55 2004
15345 Subject: [IRCServices Coding] encrypt hostnames
15346 Message-ID: <20030821005612.JBII29825.mta5-svc.business.ntl.com@i-br0ked-it>
15348 as a note.. we aint supposed to support modified versions of services.. (i'm not sure if this includes the module source..)
15350 Havnt you concidered using Unreals built in host masking instead? it seems like a better alternative :/
15352 /****************************************
15353 * Craig "FrostyCoolSlug" McLure
15354 ************* - SpamBox - **************
15355 * InspIRCd - http://www.inspircd.org
15356 * ChatSpike - http://www.chatspike.net
15357 * WinBot - http://www.winbot.co.uk
15358 ****************************************/
15360 /****************************************
15361 * From - Jack Neils <waterflamez@hotmail.com>
15362 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
15363 * Sent - 2003-08-20 @ 02:16:00
15364 * Subject - [IRCServices Coding] encrypt hostnames
15365 ****************************************/
15367 /****** - Begin Original Message - ******/
15371 >i'm using unrealircd with ircservices 5.0.21, and i already modified the
15374 >in modules/nickserv/main.c :
15376 >/* Callback for users connecting to the network. */
15377 >/* MODIFIED CALLBACK */
15378 >static int do_user_create(User *user, int ac, char **av)
15380 > validate_user(user);
15381 > send_cmd(s_OperServ, "CHGHOST s :s", user->nick, "domain.net");
15382 > send_cmd(s_OperServ, "CHGIDENT s :s", user->nick, "user");
15386 >good to start with and hide userhosts, but soon i found out 1 big problem:
15387 >try banning 1 person from a channel... +b *!user@domain.net ...
15388 >ironic, isn't it? you'd be banning everyone at once.
15389 >and banning with nick isn't very effective.
15391 >so now i was wondering if anyonce could help me use the encrypt function,
15392 >which is used on the passwords with nickserv, to encrypt the hostmask.
15393 >and, after the hostmask has been encrypted, send that as the new hostmask.
15395 >anyone that can help me, please ?
15399 >_________________________________________________________________
15400 >MSN Search, for relevant search results! http://search.msn.be
15402 >------------------------------------------------------------------
15403 >To unsubscribe or change your subscription options, visit:
15404 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
15407 /******* - End Original Message - *******/
15411 From nothing at psychopat.org Wed Aug 20 20:25:07 2003
15412 From: nothing at psychopat.org (=?iso-8859-1?Q?Marc-Andr=E9_A._Fuentes?=)
15413 Date: Sat Oct 23 23:09:55 2004
15414 Subject: [IRCServices Coding] segfault on expiring ?
15415 Message-ID: <001201c36793$d26e4000$0101a8c0@nothing>
15417 [Aug 20 20:49:05 2003] chanserv/main: Expiring channel #acid_jazz
15418 [Aug 20 20:49:05 2003] nickserv/main: Expiring suspension for SeBa_KoBe (nick group 17805)
15419 [Aug 20 20:49:05 2003] nickserv/main: Expiring nickname SeBa_KoBe
15420 [Aug 20 20:49:05 2003] nickserv/main: [Aug 20 20:49:05 2003] Services terminating: Segmentation Faul
15421 [Aug 20 20:50:00 2003] IRC Services 5.0.21 starting up
15422 [Aug 20 20:50:02 2003] nickserv/main: Expiring nickname Kanon
15423 [Aug 20 20:50:02 2003] nickserv/main: Expiring suspension for SeBa_KoBe (nick group 17805)
15424 [Aug 20 20:50:02 2003] nickserv/main: Expiring nickname SeBa_KoBe
15425 [Aug 20 20:50:02 2003] nickserv/main: unsuspend: unable to retrieve NickInfo for [Aug 20 20:55:01 20
15428 and then services crashed....
15429 don't have a core file
15430 but maybe something's wrong?
15431 this is a small part of thelog...
15432 but it repeat the same thing again before to crash
15439 ircservices-5.0.21 services.terra.cl
15440 -------------- next part --------------
15441 An HTML attachment was scrubbed...
15442 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030820/2e59ccf4/attachment.htm
15443 From simorgh at dataphone.se Thu Aug 21 01:33:23 2003
15444 From: simorgh at dataphone.se (Ali Simorgh)
15445 Date: Sat Oct 23 23:09:55 2004
15446 Subject: [IRCServices Coding] OP/Voice upon identify
15447 In-Reply-To: <MKEGJINFADFODDNOKEJCMEEADPAA.rg@tcslon.com>
15448 Message-ID: <Pine.GSO.4.31.0308211027350.6118-100000@nikson.dataphone.se>
15451 Its nice with this option. but I dont se any set command that ChanServ
15452 wont automatically op or voice you in any channel.
15456 When NOAUTO is on, ChanServ will not
15457 automatically op or voice you in any channels.
15459 Maybe some user(s) wont get auto op/voice then they can set this option ON
15460 but it sould be OFF in default.
15467 ______________________________________________________
15468 Many of life's failures are people who did not realize
15469 how close they were to success when they gave up.
15471 ______________________________________________________
15474 On Sun, 17 Aug 2003, Russell Garrett wrote:
15476 > Eh? This has been implemented since IRCServices 5a31.
15480 > > I wonder if its possible to make some modification that:
15481 > > when someone has already joined a few channels, and then identifies
15482 > > to its nickname, chanserv gives Voice and/or Op to the user is s/he
15483 > > is in the channel list (+o; aop or above & +v when vop)
15485 > > this is very usefull to not privmsg chanserv for every op or voice
15486 > > request, when user has not identified to its nick before joining
15489 > > Thanks for any help
15491 > ------------------------------------------------------------------
15492 > To unsubscribe or change your subscription options, visit:
15493 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
15496 From georges at berscheid.de Thu Aug 21 01:56:15 2003
15497 From: georges at berscheid.de (Georges Berscheid)
15498 Date: Sat Oct 23 23:09:55 2004
15499 Subject: [IRCServices Coding] OP/Voice upon identify
15500 References: <Pine.GSO.4.31.0308211027350.6118-100000@nikson.dataphone.se>
15501 Message-ID: <3F44892F.7090205@berscheid.de>
15504 If you want to disable it, add a return 0; to the very beginning of the
15505 do_nick_identified function in modules/chanserv/main.c :-/
15506 I already suggested that feature a time ago, but Andrew got upset that
15507 once he had implemented a new feature requested by many people, there
15508 are still some jerks who want to have it removed again ;-)
15509 But maybe he will consider it this time ;-)
15519 >Its nice with this option. but I dont se any set command that ChanServ
15520 >wont automatically op or voice you in any channel.
15523 > SET NOAUTO ON|OFF
15524 > When NOAUTO is on, ChanServ will not
15525 > automatically op or voice you in any channels.
15527 >Maybe some user(s) wont get auto op/voice then they can set this option ON
15528 >but it sould be OFF in default.
15535 > ______________________________________________________
15536 > Many of life's failures are people who did not realize
15537 > how close they were to success when they gave up.
15539 > ______________________________________________________
15542 >On Sun, 17 Aug 2003, Russell Garrett wrote:
15546 >>Eh? This has been implemented since IRCServices 5a31.
15552 >>>I wonder if its possible to make some modification that:
15553 >>>when someone has already joined a few channels, and then identifies
15554 >>>to its nickname, chanserv gives Voice and/or Op to the user is s/he
15555 >>>is in the channel list (+o; aop or above & +v when vop)
15557 >>>this is very usefull to not privmsg chanserv for every op or voice
15558 >>>request, when user has not identified to its nick before joining
15561 >>>Thanks for any help
15564 >>------------------------------------------------------------------
15565 >>To unsubscribe or change your subscription options, visit:
15566 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
15571 >------------------------------------------------------------------
15572 >To unsubscribe or change your subscription options, visit:
15573 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
15581 From simorgh at dataphone.se Thu Aug 21 15:20:15 2003
15582 From: simorgh at dataphone.se (Ali Simorgh)
15583 Date: Sat Oct 23 23:09:55 2004
15584 Subject: [IRCServices Coding] ircservices wont run
15585 In-Reply-To: <3F44892F.7090205@berscheid.de>
15586 Message-ID: <Pine.GSO.4.31.0308220016280.26036-100000@nikson.dataphone.se>
15589 What does this mean: (log file)
15591 [Aug 21 18:13:34 2003] sockets: flush_write_buffer(0): Socket is not connected
15596 ______________________________________________________
15597 Many of life's failures are people who did not realize
15598 how close they were to success when they gave up.
15600 ______________________________________________________
15604 From Craig at chatspike.net Thu Aug 21 18:52:12 2003
15605 From: Craig at chatspike.net (Craig McLure)
15606 Date: Sat Oct 23 23:09:55 2004
15607 Subject: [IRCServices Coding] ircservices wont run
15608 Message-ID: <20030822005228.XBSO2678.mta4-svc.business.ntl.com@i-br0ked-it>
15610 I'm assuming it means the socket is not connected..
15612 Make sure its able to connect to your IRCd through the ports provided.
15614 /****************************************
15615 * Craig "FrostyCoolSlug" McLure
15616 ************* - SpamBox - **************
15617 * InspIRCd - http://www.inspircd.org
15618 * ChatSpike - http://www.chatspike.net
15619 * WinBot - http://www.winbot.co.uk
15620 ****************************************/
15622 /****************************************
15623 * From - Ali Simorgh <simorgh@dataphone.se>
15624 * To - IRC Services Coding Mailing List <ircservices-coding@ircservices.za.net>
15625 * Sent - 2003-08-22 @ 00:20:00
15626 * Subject - [IRCServices Coding] ircservices wont run
15627 ****************************************/
15629 /****** - Begin Original Message - ******/
15631 >What does this mean: (log file)
15633 >[Aug 21 18:13:34 2003] sockets: flush_write_buffer(0): Socket is not connected
15638 > ______________________________________________________
15639 > Many of life's failures are people who did not realize
15640 > how close they were to success when they gave up.
15642 > ______________________________________________________
15646 >------------------------------------------------------------------
15647 >To unsubscribe or change your subscription options, visit:
15648 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
15651 /******* - End Original Message - *******/
15655 From andrewk at isdial.net Tue Aug 26 02:43:36 2003
15656 From: andrewk at isdial.net (Andrew Kempe)
15657 Date: Sat Oct 23 23:09:55 2004
15658 Subject: [IRCServices Coding] test
15659 Message-ID: <005801c36bb6$85bbc080$1f0912ac@espotting.com>
15663 From us44ever at hotmail.com Thu Aug 28 09:45:38 2003
15664 From: us44ever at hotmail.com (us44ever .)
15665 Date: Sat Oct 23 23:09:55 2004
15666 Subject: [IRCServices Coding] Yet, another great suggestion
15667 Message-ID: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
15671 it would be really great to add another new line to the "/nickserv info"
15672 command, for example, when some one types: "/nickserv info nick", the
15673 following will be shown:
15675 ***************************
15677 -NickServ- nick is hello world
15679 -NickServ- Is online from: ~test@just.a.test.co.za
15681 -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
15683 -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
15685 -NickServ- Last quit message: anythinggggg
15687 -NickServ- Options: Kill protection, Security
15689 ***************************
15691 the new line I'm suggesting is something like:
15693 ***************************
15694 -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
15695 ***************************
15697 This will help our users to compare the time that user was last seen and the
15698 time right now *it's very important, many many of our users asked us for
15699 this option*, also it would even be more great to show how long last time
15700 the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003 GMT
15701 (last seen time was before: 10 days, 3hours and 24 sec ago).
15703 Note that I saw both of these features, in other services I don't remember
15704 there names (but they aren't as stable as ircservices5) (it was something
15705 like ptlink services, and magik II)
15707 That's all, I would really like to see it on the next version (or if you can
15708 show me how to do it, as I'm not a programmer)
15710 Many thanks to all of who developed IRCservices ...etc ...etc ...etc
15715 _________________________________________________________________
15716 Get MSN 8 and enjoy automatic e-mail virus protection.
15717 http://join.msn.com/?page=features/virus
15720 From aragon at phat.za.net Thu Aug 28 11:36:15 2003
15721 From: aragon at phat.za.net (Aragon Gouveia)
15722 Date: Sat Oct 23 23:09:55 2004
15723 Subject: [IRCServices Coding] Yet, another great suggestion
15724 In-Reply-To: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
15725 References: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
15726 Message-ID: <20030828183615.GB32204@phat.za.net>
15728 Or how about rather letting users decide what timezone they're in and
15729 services outputs all timestamps in their local time?
15732 | By us44ever . <us44ever@hotmail.com>
15733 | [ 2003-08-28 18:45 +0200 ]
15736 > it would be really great to add another new line to the "/nickserv info"
15737 > command, for example, when some one types: "/nickserv info nick", the
15738 > following will be shown:
15740 > ***************************
15742 > -NickServ- nick is hello world
15744 > -NickServ- Is online from: ~test@just.a.test.co.za
15746 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
15748 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
15750 > -NickServ- Last quit message: anythinggggg
15752 > -NickServ- Options: Kill protection, Security
15754 > ***************************
15756 > the new line I'm suggesting is something like:
15758 > ***************************
15759 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
15760 > ***************************
15762 > This will help our users to compare the time that user was last seen and
15763 > the time right now *it's very important, many many of our users asked us
15764 > for this option*, also it would even be more great to show how long last
15765 > time the user was seen (some thing like: Last seen time: Aug 28 15:51:14
15766 > 2003 GMT (last seen time was before: 10 days, 3hours and 24 sec ago).
15768 > Note that I saw both of these features, in other services I don't remember
15769 > there names (but they aren't as stable as ircservices5) (it was something
15770 > like ptlink services, and magik II)
15772 > That's all, I would really like to see it on the next version (or if you
15773 > can show me how to do it, as I'm not a programmer)
15775 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
15780 > _________________________________________________________________
15781 > Get MSN 8 and enjoy automatic e-mail virus protection.
15782 > http://join.msn.com/?page=features/virus
15784 > ------------------------------------------------------------------
15785 > To unsubscribe or change your subscription options, visit:
15786 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
15788 From saturn at jetirc.net Thu Aug 28 11:39:10 2003
15789 From: saturn at jetirc.net (Saturn)
15790 Date: Sat Oct 23 23:09:55 2004
15791 Subject: [IRCServices Coding] Yet, another great suggestion
15792 References: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
15793 <20030828183615.GB32204@phat.za.net>
15794 Message-ID: <003201c36d93$abf77fd0$6401a8c0@turby>
15796 Oooo now I like that option... have it default to a default timezone, set in
15797 the conf file, and give them the option of SETting a different UTC code
15798 (have it as GMT + or - x wheer x is the offset from UTC)... It may not
15799 sound liek much, but I bet people will use it, and what's more, it IS useful
15800 information, especially on international servers like mine.. we have people
15801 from all over the place, and we keep services set on Pacific time... but for
15802 those in, say, Belgium... that's not very helpful
15804 ----- Original Message -----
15805 From: "Aragon Gouveia" <aragon@phat.za.net>
15806 To: <ircservices-coding@ircservices.za.net>
15807 Sent: Thursday, August 28, 2003 11:36 AM
15808 Subject: Re: [IRCServices Coding] Yet, another great suggestion
15811 Or how about rather letting users decide what timezone they're in and
15812 services outputs all timestamps in their local time?
15815 | By us44ever . <us44ever@hotmail.com>
15816 | [ 2003-08-28 18:45 +0200 ]
15819 > it would be really great to add another new line to the "/nickserv info"
15820 > command, for example, when some one types: "/nickserv info nick", the
15821 > following will be shown:
15823 > ***************************
15825 > -NickServ- nick is hello world
15827 > -NickServ- Is online from: ~test@just.a.test.co.za
15829 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
15831 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
15833 > -NickServ- Last quit message: anythinggggg
15835 > -NickServ- Options: Kill protection, Security
15837 > ***************************
15839 > the new line I'm suggesting is something like:
15841 > ***************************
15842 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
15843 > ***************************
15845 > This will help our users to compare the time that user was last seen and
15846 > the time right now *it's very important, many many of our users asked us
15847 > for this option*, also it would even be more great to show how long last
15848 > time the user was seen (some thing like: Last seen time: Aug 28 15:51:14
15849 > 2003 GMT (last seen time was before: 10 days, 3hours and 24 sec ago).
15851 > Note that I saw both of these features, in other services I don't remember
15852 > there names (but they aren't as stable as ircservices5) (it was something
15853 > like ptlink services, and magik II)
15855 > That's all, I would really like to see it on the next version (or if you
15856 > can show me how to do it, as I'm not a programmer)
15858 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
15863 > _________________________________________________________________
15864 > Get MSN 8 and enjoy automatic e-mail virus protection.
15865 > http://join.msn.com/?page=features/virus
15867 > ------------------------------------------------------------------
15868 > To unsubscribe or change your subscription options, visit:
15869 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
15870 ------------------------------------------------------------------
15871 To unsubscribe or change your subscription options, visit:
15872 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
15876 From Craig at chatspike.net Thu Aug 28 15:29:21 2003
15877 From: Craig at chatspike.net (Craig McLure)
15878 Date: Sat Oct 23 23:09:55 2004
15879 Subject: [IRCServices Coding] Yet, another great suggestion
15880 Message-ID: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
15882 Please dont post to both the services main list, and the services coding list. Choose one, or the other, especially concidering i dont think this is a great suggestion either..
15884 /time services.chatspike.net
15885 [22:28]
\95\95\95 Date / time at services.chatspike.net- Thu Aug 28 17:28:57 2003 EDT
15889 /****************************************
15890 * Craig "FrostyCoolSlug" McLure
15891 ************* - SpamBox - **************
15892 * InspIRCd - http://www.inspircd.org
15893 * ChatSpike - http://www.chatspike.net
15894 * WinBot - http://www.winbot.co.uk
15895 ****************************************/
15897 /****************************************
15898 * From - us44ever . <us44ever@hotmail.com>
15899 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
15900 * Sent - 2003-08-28 @ 16:45:00
15901 * Subject - [IRCServices Coding] Yet, another great suggestion
15902 ****************************************/
15904 /****** - Begin Original Message - ******/
15908 >it would be really great to add another new line to the "/nickserv info"
15909 >command, for example, when some one types: "/nickserv info nick", the
15910 >following will be shown:
15912 >***************************
15914 >-NickServ- nick is hello world
15916 >-NickServ- Is online from: ~test@just.a.test.co.za
15918 >-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
15920 >-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
15922 >-NickServ- Last quit message: anythinggggg
15924 >-NickServ- Options: Kill protection, Security
15926 >***************************
15928 >the new line I'm suggesting is something like:
15930 >***************************
15931 >-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
15932 >***************************
15934 >This will help our users to compare the time that user was last seen and the
15935 >time right now *it's very important, many many of our users asked us for
15936 >this option*, also it would even be more great to show how long last time
15937 >the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003 GMT
15938 >(last seen time was before: 10 days, 3hours and 24 sec ago).
15940 >Note that I saw both of these features, in other services I don't remember
15941 >there names (but they aren't as stable as ircservices5) (it was something
15942 >like ptlink services, and magik II)
15944 >That's all, I would really like to see it on the next version (or if you can
15945 >show me how to do it, as I'm not a programmer)
15947 >Many thanks to all of who developed IRCservices ...etc ...etc ...etc
15952 >_________________________________________________________________
15953 >Get MSN 8 and enjoy automatic e-mail virus protection.
15954 >http://join.msn.com/?page=features/virus
15956 >------------------------------------------------------------------
15957 >To unsubscribe or change your subscription options, visit:
15958 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
15960 /******* - End Original Message - *******/
15965 From nothing at psychopat.org Thu Aug 28 15:00:24 2003
15966 From: nothing at psychopat.org (Marc-Andre A. Fuentes)
15967 Date: Sat Oct 23 23:09:55 2004
15968 Subject: [IRCServices Coding] BUG Report
15969 Message-ID: <001501c36daf$c8cba700$0101a8c0@house>
15971 We're having a small problem with suspended channel.
15973 we suspended channel #kavala, and someone has identified itself has the founder and apply a DROP to the channel.
15974 then we got a panic from the services and... crash.
15976 Also with suspended nick , when the suspencion expire, the services crash
15979 ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
15984 -------------- next part --------------
15985 An HTML attachment was scrubbed...
15986 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030828/1f31ccf5/attachment.html
15987 From Craig at chatspike.net Thu Aug 28 16:23:41 2003
15988 From: Craig at chatspike.net (Craig McLure)
15989 Date: Sat Oct 23 23:09:55 2004
15990 Subject: [IRCServices Coding] BUG Report
15991 Message-ID: <20030828222401.JVQE12036.mta4-svc.business.ntl.com@i-br0ked-it>
15993 hmm.. what OS, compiler version etc are you using?
15995 after a test, i got the following:
15997 /cs id #abc 00376370
15998 -ChanServ- Channel #abc is suspended and may not be used or identified for.
16001 [23:20] -ChanServ- Channel is suspended and may not be used or identified for.
16003 only prob i got was it missed the channel name in the second message :)
16006 /****************************************
16007 * Craig "FrostyCoolSlug" McLure
16008 ************* - SpamBox - **************
16009 * InspIRCd - http://www.inspircd.org
16010 * ChatSpike - http://www.chatspike.net
16011 * WinBot - http://www.winbot.co.uk
16012 ****************************************/
16014 /****************************************
16015 * From - Marc-Andre A. Fuentes <nothing@psychopat.org>
16016 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
16017 * Sent - 2003-08-28 @ 18:00:00
16018 * Subject - [IRCServices Coding] BUG Report
16019 ****************************************/
16021 /****** - Begin Original Message - ******/
16023 >We're having a small problem with suspended channel.
16025 >we suspended channel #kavala, and someone has identified itself has the founder and apply a DROP to the channel.
16026 >then we got a panic from the services and... crash.
16028 >Also with suspended nick , when the suspencion expire, the services crash
16031 >ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
16036 >------------------------------------------------------------------
16037 >To unsubscribe or change your subscription options, visit:
16038 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
16040 /******* - End Original Message - *******/
16045 From saturn at jetirc.net Thu Aug 28 17:13:37 2003
16046 From: saturn at jetirc.net (Saturn)
16047 Date: Sat Oct 23 23:09:55 2004
16048 Subject: [IRCServices Coding] AKill suggestion
16049 References: <2C31F186-CDEE-11D7-979C-0003938D6866@mac.com>
16050 Message-ID: <009001c36dc2$64b56b80$6401a8c0@turby>
16052 Would it be possible to have it announce to the user when they are akilled,
16053 either the expiry date and time, or "Expires in 3days, 4hours, 6minutes" or
16054 something similar. I find that usually we just have to do 24hour bans, but
16055 the user has no way to know when the ban was set, and when it expires...
16057 Just an idea... I now await the half dozen people who will proceed to tell
16058 me how stupid my idea is....
16065 From playa at dreamchat.org Thu Aug 28 20:46:14 2003
16066 From: playa at dreamchat.org (playa)
16067 Date: Sat Oct 23 23:09:55 2004
16068 Subject: [IRCServices Coding] Yet, another great suggestion
16069 In-Reply-To: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
16070 References: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
16071 Message-ID: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
16073 Is this /time command only supposed to work via RAW? Cause when i type
16074 /time services.dreamchat.org i get No Such User, but if i do /raw time
16075 services.dreamchat.org, it works. Just wondering if its just me, or if
16076 its supposed to be that way.
16078 > Please dont post to both the services main list, and the services coding
16079 > list. Choose one, or the other, especially concidering i dont think this
16080 > is a great suggestion either..
16082 > /time services.chatspike.net
16083 > [22:28] ??? Date / time at services.chatspike.net- Thu Aug 28 17:28:57
16088 > /****************************************
16089 > * Craig "FrostyCoolSlug" McLure
16090 > ************* - SpamBox - **************
16091 > * InspIRCd - http://www.inspircd.org
16092 > * ChatSpike - http://www.chatspike.net
16093 > * WinBot - http://www.winbot.co.uk
16094 > ****************************************/
16096 > /****************************************
16097 > * From - us44ever . <us44ever@hotmail.com>
16098 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
16099 > * Sent - 2003-08-28 @ 16:45:00
16100 > * Subject - [IRCServices Coding] Yet, another great suggestion
16101 > ****************************************/
16103 > /****** - Begin Original Message - ******/
16107 >>it would be really great to add another new line to the "/nickserv info"
16108 >>command, for example, when some one types: "/nickserv info nick", the
16109 >>following will be shown:
16111 >>***************************
16113 >>-NickServ- nick is hello world
16115 >>-NickServ- Is online from: ~test@just.a.test.co.za
16117 >>-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
16119 >>-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
16121 >>-NickServ- Last quit message: anythinggggg
16123 >>-NickServ- Options: Kill protection, Security
16125 >>***************************
16127 >>the new line I'm suggesting is something like:
16129 >>***************************
16130 >>-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
16131 >>***************************
16133 >>This will help our users to compare the time that user was last seen and
16135 >>time right now *it's very important, many many of our users asked us for
16136 >>this option*, also it would even be more great to show how long last time
16137 >>the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003
16139 >>(last seen time was before: 10 days, 3hours and 24 sec ago).
16141 >>Note that I saw both of these features, in other services I don't
16143 >>there names (but they aren't as stable as ircservices5) (it was something
16144 >>like ptlink services, and magik II)
16146 >>That's all, I would really like to see it on the next version (or if you
16148 >>show me how to do it, as I'm not a programmer)
16150 >>Many thanks to all of who developed IRCservices ...etc ...etc ...etc
16155 >>_________________________________________________________________
16156 >>Get MSN 8 and enjoy automatic e-mail virus protection.
16157 >>http://join.msn.com/?page=features/virus
16159 >>------------------------------------------------------------------
16160 >>To unsubscribe or change your subscription options, visit:
16161 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
16163 > /******* - End Original Message - *******/
16167 > ------------------------------------------------------------------
16168 > To unsubscribe or change your subscription options, visit:
16169 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
16176 Network Founder/CEO
16177 DreamChat IRC Network - irc.dreamchat.org
16178 http://www.dreamchat.org
16181 From quension at mac.com Thu Aug 28 21:12:53 2003
16182 From: quension at mac.com (Trevor Talbot)
16183 Date: Sat Oct 23 23:09:55 2004
16184 Subject: [IRCServices Coding] Yet, another great suggestion
16185 In-Reply-To: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
16186 Message-ID: <0F823090-D9D7-11D7-8513-0003938D6866@mac.com>
16188 On Thursday, Aug 28, 2003, at 20:46 US/Pacific, playa wrote:
16190 > Is this /time command only supposed to work via RAW? Cause when i
16191 > type /time services.dreamchat.org i get No Such User, but if i do /raw
16192 > time services.dreamchat.org, it works. Just wondering if its just me,
16193 > or if its supposed to be that way.
16195 That's a client thing. Some clients might alias /time as a CTCP TIME
16196 for a specific user, or similar.
16201 From r-krisztian at softhome.net Thu Aug 28 22:13:29 2003
16202 From: r-krisztian at softhome.net (Krisztian Romek)
16203 Date: Sat Oct 23 23:09:55 2004
16204 Subject: [IRCServices Coding] Yet, another great suggestion
16205 In-Reply-To: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
16206 References: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
16207 <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
16208 Message-ID: <200308290713.29423.r-krisztian@softhome.net>
16210 > Is this /time command only supposed to work via RAW? Cause when i type
16211 > /time services.dreamchat.org i get No Such User, but if i do /raw time
16212 > services.dreamchat.org, it works. Just wondering if its just me, or if
16213 > its supposed to be that way.
16215 Some clients use stupid aliases for CTCP commands, for example:
16217 /version <nick> = /CTCP <nick> VERSION,
16218 /time <nick> = /CTCP <nick> TIME,
16219 /finger <nick> = /CTCP <nick> TIME
16221 This is why nothing works the way you expected.
16225 r-krisztian@softhome.net
16228 From us44ever at hotmail.com Fri Aug 29 13:01:59 2003
16229 From: us44ever at hotmail.com (us44ever .)
16230 Date: Sat Oct 23 23:09:56 2004
16231 Subject: [IRCServices Coding] AKill suggestion
16232 Message-ID: <Sea1-F108cM3oryKFRJ0000eb75@hotmail.com>
16234 Pretty good idea, specially is it would be implemented as an option (because
16235 some admins might won't like the idea of displaying the time of when the
16236 akill will expire to the user who has been akilled).
16238 _________________________________________________________________
16239 Help protect your PC: Get a free online virus scan at McAfee.com.
16240 http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
16243 From us44ever at hotmail.com Fri Aug 29 13:09:38 2003
16244 From: us44ever at hotmail.com (us44ever .)
16245 Date: Sat Oct 23 23:09:56 2004
16246 Subject: [IRCServices Coding] Yet, another great suggestion
16247 Message-ID: <Sea1-F127z33hqSnMGE000094b3@hotmail.com>
16250 Since most people want to see this feature(s) in the next version, it would
16251 be great to implement it as an optional feature , where it can be disabled
16252 from the .conf file(s) or enable it easily. I don't think that there is
16253 anything that the authors will lose if this feature can be added, in fact,
16254 it will add another nice feature to the features list of IRCservices5.
16256 _________________________________________________________________
16257 Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
16258 using MSN Messenger http://entertainment.msn.com/imastar
16261 From Craig at chatspike.net Fri Aug 29 14:41:23 2003
16262 From: Craig at chatspike.net (Craig McLure)
16263 Date: Sat Oct 23 23:09:56 2004
16264 Subject: [IRCServices Coding] Yet, another great suggestion
16265 Message-ID: <20030829204143.NNNT26404.mta1-svc.business.ntl.com@i-br0ked-it>
16267 I'll ask again.. can you please stop posting to both the IRCServices mailing list, and the IRCd coding mailing list, getting your mail 2ce is beginning to annoy me.
16269 And i'll Quote Elijah:
16271 "Except it's already been said in the FAQ that it's not going to happen, and
16272 if that made it into the FAQ it would seem the answer is frequently going to
16276 /****************************************
16277 * Craig "FrostyCoolSlug" McLure
16278 ************* - SpamBox - **************
16279 * InspIRCd - http://www.inspircd.org
16280 * ChatSpike - http://www.chatspike.net
16281 * WinBot - http://www.winbot.co.uk
16282 ****************************************/
16284 /****************************************
16285 * From - us44ever . <us44ever@hotmail.com>
16286 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
16287 * Sent - 2003-08-29 @ 20:09:00
16288 * Subject - Re: [IRCServices Coding] Yet, another great suggestion
16289 ****************************************/
16291 /****** - Begin Original Message - ******/
16293 >Since most people want to see this feature(s) in the next version, it would
16294 >be great to implement it as an optional feature , where it can be disabled
16295 >from the .conf file(s) or enable it easily. I don't think that there is
16296 >anything that the authors will lose if this feature can be added, in fact,
16297 >it will add another nice feature to the features list of IRCservices5.
16299 >_________________________________________________________________
16300 >Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
16301 >using MSN Messenger http://entertainment.msn.com/imastar
16303 >------------------------------------------------------------------
16304 >To unsubscribe or change your subscription options, visit:
16305 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
16308 /******* - End Original Message - *******/
16313 From Craig at chatspike.net Fri Aug 29 14:42:51 2003
16314 From: Craig at chatspike.net (Craig McLure)
16315 Date: Sat Oct 23 23:09:56 2004
16316 Subject: [IRCServices Coding] AKill suggestion
16317 Message-ID: <20030829204311.GHCL29825.mta5-svc.business.ntl.com@i-br0ked-it>
16319 its a stupid idea!!! :p
16321 j/k.. I think its a great idea.. i'd rather have services telling users when their akills expire, than them spamming my mailbox with 'when does my akill expire?' every 20mins :p
16323 /****************************************
16324 * Craig "FrostyCoolSlug" McLure
16325 ************* - SpamBox - **************
16326 * InspIRCd - http://www.inspircd.org
16327 * ChatSpike - http://www.chatspike.net
16328 * WinBot - http://www.winbot.co.uk
16329 ****************************************/
16331 /****************************************
16332 * From - Saturn <saturn@jetirc.net>
16333 * To - IRC Services Coding Mailing List <ircservices-coding@ircservices.za.net>
16334 * Sent - 2003-08-28 @ 17:13:00
16335 * Subject - [IRCServices Coding] AKill suggestion
16336 ****************************************/
16338 /****** - Begin Original Message - ******/
16340 >Would it be possible to have it announce to the user when they are akilled,
16341 >either the expiry date and time, or "Expires in 3days, 4hours, 6minutes" or
16342 >something similar. I find that usually we just have to do 24hour bans, but
16343 >the user has no way to know when the ban was set, and when it expires...
16345 >Just an idea... I now await the half dozen people who will proceed to tell
16346 >me how stupid my idea is....
16352 >------------------------------------------------------------------
16353 >To unsubscribe or change your subscription options, visit:
16354 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
16356 /******* - End Original Message - *******/
16361 From admin at nevernet.net Fri Aug 29 13:45:36 2003
16362 From: admin at nevernet.net (Elijah)
16363 Date: Sat Oct 23 23:09:56 2004
16364 Subject: [IRCServices Coding] Yet, another great suggestion
16365 In-Reply-To: <20030829204143.NNNT26404.mta1-svc.business.ntl.com@i-br0ked-it>
16366 Message-ID: <008f01c36e6e$83158770$436a3a44@slytherin>
16370 -----Original Message-----
16371 From: ircservices-coding-bounces@ircservices.za.net
16372 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of Craig
16374 Sent: Friday, August 29, 2003 4:41 PM
16375 To: IRC Services Coding Mailing List
16376 Subject: Re: Re: [IRCServices Coding] Yet, another great suggestion
16379 I'll ask again.. can you please stop posting to both the IRCServices mailing
16380 list, and the IRCd coding mailing list, getting your mail 2ce is beginning
16383 And i'll Quote Elijah:
16385 "Except it's already been said in the FAQ that it's not going to happen, and
16386 if that made it into the FAQ it would seem the answer is frequently going to
16391 From us44ever at hotmail.com Fri Aug 29 16:59:19 2003
16392 From: us44ever at hotmail.com (us44ever .)
16393 Date: Sat Oct 23 23:09:56 2004
16394 Subject: [IRCServices Coding] Yet, another great suggestion
16395 Message-ID: <Sea1-F30z1oyZF58m3O00035b82@hotmail.com>
16397 woops, ok sorry I thought the two e-mails is completely different.
16400 >From: "Craig McLure" <Craig@chatspike.net>
16401 >Reply-To: IRC Services Coding Mailing List
16402 ><ircservices-coding@ircservices.za.net>
16403 >To: IRC Services Coding Mailing List
16404 ><ircservices-coding@ircservices.za.net>
16405 >Subject: Re: Re: [IRCServices Coding] Yet, another great suggestion
16406 >Date: Fri, 29 Aug 2003 21:41:23 +0000
16408 >I'll ask again.. can you please stop posting to both the IRCServices
16409 >mailing list, and the IRCd coding mailing list, getting your mail 2ce is
16410 >beginning to annoy me.
16412 >And i'll Quote Elijah:
16414 >"Except it's already been said in the FAQ that it's not going to happen,
16416 >if that made it into the FAQ it would seem the answer is frequently going
16421 >/****************************************
16422 > * Craig "FrostyCoolSlug" McLure
16423 > ************* - SpamBox - **************
16424 > * InspIRCd - http://www.inspircd.org
16425 > * ChatSpike - http://www.chatspike.net
16426 > * WinBot - http://www.winbot.co.uk
16427 > ****************************************/
16429 >/****************************************
16430 > * From - us44ever . <us44ever@hotmail.com>
16431 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
16432 > * Sent - 2003-08-29 @ 20:09:00
16433 > * Subject - Re: [IRCServices Coding] Yet, another great suggestion
16434 > ****************************************/
16436 >/****** - Begin Original Message - ******/
16438 > >Since most people want to see this feature(s) in the next version, it
16440 > >be great to implement it as an optional feature , where it can be
16442 > >from the .conf file(s) or enable it easily. I don't think that there is
16443 > >anything that the authors will lose if this feature can be added, in
16445 > >it will add another nice feature to the features list of IRCservices5.
16447 > >_________________________________________________________________
16448 > >Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
16449 > >using MSN Messenger http://entertainment.msn.com/imastar
16451 > >------------------------------------------------------------------
16452 > >To unsubscribe or change your subscription options, visit:
16453 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
16456 >/******* - End Original Message - *******/
16460 >------------------------------------------------------------------
16461 >To unsubscribe or change your subscription options, visit:
16462 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
16464 _________________________________________________________________
16465 MSN 8: Get 6 months for $9.95/month. http://join.msn.com/?page=dept/dialup
16468 From simorgh at dataphone.se Sat Aug 30 08:26:54 2003
16469 From: simorgh at dataphone.se (Ali Simorgh)
16470 Date: Sat Oct 23 23:09:56 2004
16471 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
16472 In-Reply-To: <MKEGJINFADFODDNOKEJCMEEADPAA.rg@tcslon.com>
16473 Message-ID: <Pine.GSO.4.31.0308301716410.15629-100000@nikson.dataphone.se>
16476 I run ircservices 5.0.21 on FreeBSD 4.8-STABLE. and Ultimate 3.*
16477 I get this in logfile:
16479 [Aug 30 10:51:19 2003] unknown message from server
16480 (NETCTRL 0 0 0 0 0 0 0 0 0 0 0 0 0)
16481 [Aug 30 10:51:19 2003] user: New maximum user count: 1
16482 [Aug 30 10:51:19 2003] unknown message from server
16483 (:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
16484 [Aug 30 10:51:19 2003] user: New maximum user count: 2
16485 [Aug 30 10:51:19 2003] unknown message from server
16486 (:irc.MyNet.Net SETHOST pedarkhAnde 6b45bb2.26d9672f.dataphone.se)
16487 [Aug 30 10:56:18 2003] mail/sendmail:
16488 /usr/sbin/sendmail exited with code 25600
16489 [Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
16490 registration (Simorgh)
16492 and how can I do so that nickserv dont show the realhost of a user in
16499 ______________________________________________________
16500 Many of life's failures are people who did not realize
16501 how close they were to success when they gave up.
16503 ______________________________________________________
16508 From jskam at shaw.ca Sat Aug 30 11:34:27 2003
16509 From: jskam at shaw.ca (Jeffery Kam)
16510 Date: Sat Oct 23 23:09:56 2004
16511 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
16512 In-Reply-To: <Pine.GSO.4.31.0308301716410.15629-100000@nikson.dataphone.se>
16513 Message-ID: <000001c36f25$58464860$f64f9144@weed>
16515 "and how can I do so that nickserv dont show the realhost of a user in
16516 'ns info nick all'"
16518 This would be a great feature for sure. I know on my network, there is
16519 a custom user mode +d, which will disguise a user's host in a /whois
16520 reply, but services info doesn't show it disguised unless the HIDE
16525 From achurch at achurch.org Sun Aug 31 08:14:01 2003
16526 From: achurch at achurch.org (Andrew Church)
16527 Date: Sat Oct 23 23:09:56 2004
16528 Subject: [IRCServices Coding] MARK Command
16529 In-Reply-To: <3208.66.181.69.244.1060800845.squirrel@dreamchat.org>
16530 Message-ID: <3f512fdb.01666@achurch.org>
16532 Use E-mail if you need communication of that sort.
16535 achurch@achurch.org
16536 http://achurch.org/
16538 >First off, i would like to say that IRCservices are the best services out
16539 >there, by FAR! Anyways, i was wondering if the MARK command will be in
16540 >the next relase? Its kind of a pointless command, its only used to mark
16541 >nicks or channels, but it is very useful for when passwords to channels
16544 >/chanserv MARK <channel> <reason>
16546 >/chanserv info #channel would read the following.
16547 >*#channel has been MARKED by playa - <reason>
16549 >Of course only IRCops would be able to view it.
16551 >Just an idea i thought of :)
16556 >Network Founder/CEO
16557 >DreamChat IRC Network - irc.dreamchat.org
16558 >http://www.dreamchat.org
16560 >------------------------------------------------------------------
16561 >To unsubscribe or change your subscription options, visit:
16562 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
16564 From achurch at achurch.org Sun Aug 31 08:16:34 2003
16565 From: achurch at achurch.org (Andrew Church)
16566 Date: Sat Oct 23 23:09:56 2004
16567 Subject: [IRCServices Coding] OP/Voice upon identify
16568 In-Reply-To: <Pine.GSO.4.31.0308211027350.6118-100000@nikson.dataphone.se>
16569 Message-ID: <3f513092.01677@achurch.org>
16571 Needless complexity. If you don't want yourself autoopped, then don't
16572 be an auto-op. It's that simple.
16575 achurch@achurch.org
16576 http://achurch.org/
16579 >Its nice with this option. but I dont se any set command that ChanServ
16580 >wont automatically op or voice you in any channel.
16583 > SET NOAUTO ON|OFF
16584 > When NOAUTO is on, ChanServ will not
16585 > automatically op or voice you in any channels.
16587 >Maybe some user(s) wont get auto op/voice then they can set this option ON
16588 >but it sould be OFF in default.
16595 > ______________________________________________________
16596 > Many of life's failures are people who did not realize
16597 > how close they were to success when they gave up.
16599 > ______________________________________________________
16602 >On Sun, 17 Aug 2003, Russell Garrett wrote:
16604 >> Eh? This has been implemented since IRCServices 5a31.
16608 >> > I wonder if its possible to make some modification that:
16609 >> > when someone has already joined a few channels, and then identifies
16610 >> > to its nickname, chanserv gives Voice and/or Op to the user is s/he
16611 >> > is in the channel list (+o; aop or above & +v when vop)
16613 >> > this is very usefull to not privmsg chanserv for every op or voice
16614 >> > request, when user has not identified to its nick before joining
16617 >> > Thanks for any help
16619 >> ------------------------------------------------------------------
16620 >> To unsubscribe or change your subscription options, visit:
16621 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
16624 >------------------------------------------------------------------
16625 >To unsubscribe or change your subscription options, visit:
16626 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
16628 From l8nite at l8nite.net Sat Aug 30 16:58:05 2003
16629 From: l8nite at l8nite.net (Shaun Guth)
16630 Date: Sat Oct 23 23:09:56 2004
16631 Subject: [IRCServices Coding] OP/Voice upon identify
16632 In-Reply-To: <3f513092.01677@achurch.org>
16633 References: <3f513092.01677@achurch.org>
16634 Message-ID: <1062287885.21924.6.camel@localhost>
16636 On Sun, 2003-08-31 at 01:16, Andrew Church wrote:
16637 > Needless complexity. If you don't want yourself autoopped, then don't
16638 > be an auto-op. It's that simple.
16640 I disagree. In my case, I wanted to create a channel where there were
16641 no ops so users don't have to endure lame op-wars, etc. However, I did
16642 need to maintain a level of control over the channel to protect from
16643 extremely obnoxious behavior or lame bots, etc. By registering as
16644 founder of the channel I induced the unwanted 'auto-op' behavior. My
16645 only solution was to register another fake user to become channel
16646 founder and set their nick to noexpire. That to me seems like needless
16647 complexity. A simple check to see if the user wishes to be opped or not
16653 From Craig at chatspike.net Sat Aug 30 18:06:58 2003
16654 From: Craig at chatspike.net (Craig McLure)
16655 Date: Sat Oct 23 23:09:56 2004
16656 Subject: [IRCServices Coding] OP/Voice upon identify
16657 Message-ID: <20030831000719.ELIJ19019.mta3-svc.business.ntl.com@i-br0ked-it>
16659 it would thou.. they would have to be able to switch off auto-op for a single channel..
16660 you could always use /cs levels to change the 'auto op' level up.. so that no one is auto-opped..
16662 or /cs levels #channels DISABLE autoop
16664 /****************************************
16665 * Craig "FrostyCoolSlug" McLure
16666 ************* - SpamBox - **************
16667 * InspIRCd - http://www.inspircd.org
16668 * ChatSpike - http://www.chatspike.net
16669 * WinBot - http://www.winbot.co.uk
16670 ****************************************/
16672 /****************************************
16673 * From - Shaun Guth <l8nite@l8nite.net>
16674 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
16675 * Sent - 2003-08-30 @ 16:58:00
16676 * Subject - RE: [IRCServices Coding] OP/Voice upon identify
16677 ****************************************/
16679 /****** - Begin Original Message - ******/
16681 >On Sun, 2003-08-31 at 01:16, Andrew Church wrote:
16682 >> Needless complexity. If you don't want yourself autoopped, then don't
16683 >> be an auto-op. It's that simple.
16685 >I disagree. In my case, I wanted to create a channel where there were
16686 >no ops so users don't have to endure lame op-wars, etc. However, I did
16687 >need to maintain a level of control over the channel to protect from
16688 >extremely obnoxious behavior or lame bots, etc. By registering as
16689 >founder of the channel I induced the unwanted 'auto-op' behavior. My
16690 >only solution was to register another fake user to become channel
16691 >founder and set their nick to noexpire. That to me seems like needless
16692 >complexity. A simple check to see if the user wishes to be opped or not
16697 >------------------------------------------------------------------
16698 >To unsubscribe or change your subscription options, visit:
16699 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
16702 /******* - End Original Message - *******/
16707 From l8nite at l8nite.net Sat Aug 30 17:14:41 2003
16708 From: l8nite at l8nite.net (Shaun Guth)
16709 Date: Sat Oct 23 23:09:56 2004
16710 Subject: [IRCServices Coding] OP/Voice upon identify
16711 In-Reply-To: <20030831000719.ELIJ19019.mta3-svc.business.ntl.com@i-br0ked-it>
16712 References: <20030831000719.ELIJ19019.mta3-svc.business.ntl.com@i-br0ked-it>
16713 Message-ID: <1062288881.21924.17.camel@localhost>
16715 On Sat, 2003-08-30 at 18:06, Craig McLure wrote:
16716 > it would thou.. they would have to be able to switch off auto-op for a single channel..
16718 For each channel we already store an access list, one extra bit to
16719 indicate auto-anything status or not is not really asking too much.
16721 > you could always use /cs levels to change the 'auto op' level up.. so that no one is auto-opped..
16722 > or /cs levels #channels DISABLE autoop
16724 -ChanServ- Channel #foobar registered under your nickname: l8
16725 -ChanServ- AUTOOP disabled on channel #foobar.
16726 --- You have left channel #foobar
16727 --> You are now talking on #foobar
16728 --- services.topgamers.net removes channel operator status from l8
16729 --- services.topgamers.net gives channel operator status to l8
16731 Same with ENFORCE set to off as well.
16733 > [snipped obnoxiously long sig]
16738 From achurch at achurch.org Sun Aug 31 18:55:28 2003
16739 From: achurch at achurch.org (Andrew Church)
16740 Date: Sat Oct 23 23:09:56 2004
16741 Subject: [IRCServices Coding] OP/Voice upon identify
16742 In-Reply-To: <1062288881.21924.17.camel@localhost>
16743 Message-ID: <3f51c6b5.07402@achurch.org>
16745 >> you could always use /cs levels to change the 'auto op' level up.. so that no one is auto-opped..
16746 >> or /cs levels #channels DISABLE autoop
16748 >-ChanServ- Channel #foobar registered under your nickname: l8
16749 >-ChanServ- AUTOOP disabled on channel #foobar.
16750 >--- You have left channel #foobar
16751 >--> You are now talking on #foobar
16752 >--- services.topgamers.net removes channel operator status from l8
16753 >--- services.topgamers.net gives channel operator status to l8
16755 This is definitely confusing behavior. Fixed for 5.0.22, thanks for
16756 the report. Note that you will also want to disable the other AUTOxxx
16757 levels as well if you don't want any automatic modes.
16760 achurch@achurch.org
16761 http://achurch.org/
16763 From achurch at achurch.org Sun Aug 31 23:17:56 2003
16764 From: achurch at achurch.org (Andrew Church)
16765 Date: Sat Oct 23 23:09:56 2004
16766 Subject: [IRCServices Coding] Mass memos
16767 In-Reply-To: <001601c361d8$a5312f00$6401a8c0@turby>
16768 Message-ID: <3f5205f0.15057@achurch.org>
16770 >Can we reconsider adding a Mass memo function for the next release?
16772 No, for all the reasons others have mentioned. I'll also draw an
16773 example from my experience with cellphone mail in Japan, which is
16774 remarkably similar to Services memos: Automated messages are annoying,
16775 period. The primary use for cellphone mail is to communicate with friends;
16776 having automatic messages interfere with that is annoying in the extreme.
16777 Yes, 10% or 20% of your users might be willing to accept mass memos, but
16778 the remaining 80% or 90% will get quite upset with you.
16780 I might also point out that people who care about what happens on the
16781 network will actively check that information, whether you make it available
16782 through logon news, through a website, or whatever; and people who don't
16783 care will ignore anything you send them. The method you use to inform them
16784 won't really make a difference.
16786 >If not, or even if so... one thing puzzles me: In the /ns list * command,
16787 >the listings have occasional punctuation... a ! or ? in front of the nick.
16788 >There is nothing in the docs anywhere that seems to address this, and I'm
16789 >curious as to what those mean.... an explanation would be helpful there too.
16791 This should be available through /ns help list, but there appears to
16792 be a bug there. I'll fix it for the next version.
16794 >on that note, a possible suggestion for Logonnews... How about something I
16795 >saw on Dalnet once: When new news is added, you get a notice. Until you
16796 >read the news, it keeps bugging you when you log on. After you read it, it
16797 >stops. Some sort of flag so users know when there IS new news would be
16798 >useful... the main reason nobody read the logonnews is that 90% of the time
16799 >for them, it is unchanged........
16801 This is an interesting thought; I'll think about it for a future
16805 achurch@achurch.org
16806 http://achurch.org/
16808 From achurch at achurch.org Sun Aug 31 23:37:39 2003
16809 From: achurch at achurch.org (Andrew Church)
16810 Date: Sat Oct 23 23:09:56 2004
16811 Subject: [IRCServices Coding] Language
16812 In-Reply-To: <MKEGJINFADFODDNOKEJCKEEDDPAA.rg@tcslon.com>
16813 Message-ID: <3f52094e.17046@achurch.org>
16815 [/msg nickserv vs. /nickserv]
16816 >I wonder if it would be worth integrating such a thing into services as an
16817 >option (compile-time maybe?). I think it would be good for the irc community
16818 >as a whole to get away from the habit of msging services directly if at all
16819 >possible. Opinions?
16821 /msg NickServ is the one format that's guaranteed to work on every
16822 ircd (except for administrative decisions a la DALnet). Get an RFC
16823 published--and implemented; 2811-3 were remarkable failures in that area--
16824 and I'll consider changing it.
16827 achurch@achurch.org
16828 http://achurch.org/
16830 From achurch at achurch.org Sun Aug 31 23:42:27 2003
16831 From: achurch at achurch.org (Andrew Church)
16832 Date: Sat Oct 23 23:09:56 2004
16833 Subject: [IRCServices Coding] Language
16834 In-Reply-To: <Pine.GSO.4.31.0308172127300.9882-100000@nikson.dataphone.se>
16835 Message-ID: <3f520a18.17063@achurch.org>
16837 >Is there any tool (silly question) or something or guid to make a language
16840 >I have decided to make a Persian (Farsi) language file.
16842 Language files are just plain text files; as another reply said, read
16843 the comments at the top of lang/en_us.l, and work from there. Be warned
16844 that the amount of text is huge; expect to spend at least two to three
16845 months on the initial translation.
16847 Also, if you'd be willing to continue maintaining the language file as
16848 it is updated in future versions, please let me know privately.
16851 achurch@achurch.org
16852 http://achurch.org/
16854 From achurch at achurch.org Sun Aug 31 23:52:09 2003
16855 From: achurch at achurch.org (Andrew Church)
16856 Date: Sat Oct 23 23:09:56 2004
16857 Subject: [IRCServices Coding] segfault on expiring ?
16858 In-Reply-To: <001201c36793$d26e4000$0101a8c0@nothing>
16859 Message-ID: <3f520bd8.17715@achurch.org>
16861 >[Aug 20 20:49:05 2003] nickserv/main: Expiring suspension for SeBa_KoBe (nick group 17805)
16862 >[Aug 20 20:49:05 2003] nickserv/main: Expiring nickname SeBa_KoBe
16863 >[Aug 20 20:49:05 2003] nickserv/main: [Aug 20 20:49:05 2003] Services terminating: Segmentation Faul
16865 I can't reproduce this problem. If this is still occurring, can you
16866 send me your databases privately so that I can investigate it?
16869 achurch@achurch.org
16870 http://achurch.org/
16872 From achurch at achurch.org Sun Aug 31 23:54:39 2003
16873 From: achurch at achurch.org (Andrew Church)
16874 Date: Sat Oct 23 23:09:56 2004
16875 Subject: [IRCServices Coding] BUG Report
16876 In-Reply-To: <001501c36daf$c8cba700$0101a8c0@house>
16877 Message-ID: <3f520c48.17731@achurch.org>
16879 >we suspended channel #kavala, and someone has identified itself has the =
16880 >founder and apply a DROP to the channel.
16881 >then we got a panic from the services and... crash.
16883 This is a bug in the DROP function, and has been fixed; thanks for the
16887 achurch@achurch.org
16888 http://achurch.org/
16890 From achurch at achurch.org Mon Sep 1 00:06:07 2003
16891 From: achurch at achurch.org (Andrew Church)
16892 Date: Sat Oct 23 23:09:56 2004
16893 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
16894 In-Reply-To: <Pine.GSO.4.31.0308301716410.15629-100000@nikson.dataphone.se>
16895 Message-ID: <3f520f38.21076@achurch.org>
16897 >[Aug 30 10:56:18 2003] mail/sendmail:
16898 > /usr/sbin/sendmail exited with code 25600
16900 Use the SMTP module instead (mail/smtp).
16902 >[Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
16903 >registration (Simorgh)
16905 >and how can I do so that nickserv dont show the realhost of a user in
16906 >'ns info nick all'
16908 It doesn't. However:
16910 >[Aug 30 10:51:19 2003] unknown message from server
16911 >(:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
16913 You're using the wrong protocol, since it doesn't recognize the
16914 SETHOST command and therefore has no idea about fake hosts. I might
16915 remind you that Ultimate 3.x is not supported.
16918 achurch@achurch.org
16919 http://achurch.org/
16921 From achurch at achurch.org Mon Sep 1 00:09:41 2003
16922 From: achurch at achurch.org (Andrew Church)
16923 Date: Sat Oct 23 23:09:56 2004
16924 Subject: [IRCServices Coding] Yet, another great suggestion
16925 In-Reply-To: <20030828183615.GB32204@phat.za.net>
16926 Message-ID: <3f52100e.21116@achurch.org>
16928 >Or how about rather letting users decide what timezone they're in and
16929 >services outputs all timestamps in their local time?
16931 /ns help set timezone (since 5.0 alpha)
16934 achurch@achurch.org
16935 http://achurch.org/
16937 From saturn at jetirc.net Sun Aug 31 12:29:07 2003
16938 From: saturn at jetirc.net (Saturn)
16939 Date: Sat Oct 23 23:09:56 2004
16940 Subject: [IRCServices Coding]
16941 Re: [IRCServices] Yet, another great suggestion
16942 References: <3f5202a3.15001@achurch.org>
16943 Message-ID: <003201c36ff6$25ae6550$6401a8c0@turby>
16945 I think it is... consider an international Network like mine: every server
16946 is in a different time zone -- How are users supposed to know what time zone
16947 the Services (pickign on Services' clock because Services are whats giving
16948 these notices!) is in?? Sure, they can do the /time command, if they even
16949 know abotu it. But the vast majority of IRC users are ignorant of those
16950 sorts of commands, or even if they know about /time, they most likely have
16951 no idea they can specify a server with the command.
16953 I realize that programmers for IRC-related software seem always to be of the
16954 universal opinion that ALL irc users should take the time to become elite
16955 experts abotu everything PC, however that is simply NOT reality. Services
16956 is specificly there to SERVE the users and the ircops. Its sole function is
16957 to police access and provide information to the users -- what use is it to
16958 say that a certain piece of information is "not useful" or "not needed" when
16959 you can plainly see that it is in this case, given the argument above?
16961 Obviously, it is your project, not mine, and I certainly cannot force you to
16962 do anythign you don't want to do, but I and my staff and users all agree it
16963 would be extremely useful... "Handy" was the word most used. I've had quite
16964 a few queries about it, and so I'm asking for it. If you don't feel that
16965 non-techie users deserve any consideration, then ignore the request. It's
16966 really up to you anyhow....
16971 ----- Original Message -----
16972 From: "Andrew Church" <achurch@achurch.org>
16973 To: <saturn@jetirc.net>
16974 Sent: Sunday, August 31, 2003 7:13 AM
16975 Subject: Re: [IRCServices] Yet, another great suggestion
16978 >So how do you get the current time from Services then? The actual time that
16979 >SERVICES thinks it is, not the server, and not my local clock...
16981 If there's any significant difference between your local clock, your
16982 IRC server's clock, and Services' clock, then at least one of them needs to
16983 be fixed. That's not Services' problem.
16986 achurch@achurch.org
16987 http://achurch.org/
16991 From aragon at phat.za.net Sun Aug 31 13:23:24 2003
16992 From: aragon at phat.za.net (Aragon Gouveia)
16993 Date: Sat Oct 23 23:09:56 2004
16994 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
16995 another great suggestion
16996 In-Reply-To: <003201c36ff6$25ae6550$6401a8c0@turby>
16997 References: <3f5202a3.15001@achurch.org> <003201c36ff6$25ae6550$6401a8c0@turby>
16998 Message-ID: <20030831202324.GB8731@phat.za.net>
17000 | By Saturn <saturn@jetirc.net>
17001 | [ 2003-08-31 21:29 +0200 ]
17002 > I think it is... consider an international Network like mine: every server
17003 > is in a different time zone -- How are users supposed to know what time zone
17004 > the Services (pickign on Services' clock because Services are whats giving
17005 > these notices!) is in?? Sure, they can do the /time command, if they even
17006 > know abotu it. But the vast majority of IRC users are ignorant of those
17007 > sorts of commands, or even if they know about /time, they most likely have
17008 > no idea they can specify a server with the command.
17010 Erm, what's the argument here? Services stipulates its timezone in its
17011 timestamps. As do all the other servers on the network.
17019 From saturn at jetirc.net Sun Aug 31 13:47:16 2003
17020 From: saturn at jetirc.net (Saturn)
17021 Date: Sat Oct 23 23:09:56 2004
17022 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
17023 another great suggestion
17024 References: <3f5202a3.15001@achurch.org> <003201c36ff6$25ae6550$6401a8c0@turby>
17025 <20030831202324.GB8731@phat.za.net>
17026 Message-ID: <000701c37001$10a62cf0$6401a8c0@turby>
17028 The argument is that the overwhelming majority of IRC users have no idea the
17029 /time command exists, and even fewer are aware that they can specify a
17030 server name after the /time command. How would these people find out the
17031 Services time zone? Why does it all have to be so complicated??
17033 ----- Original Message -----
17034 From: "Aragon Gouveia" <aragon@phat.za.net>
17035 To: <ircservices-coding@ircservices.za.net>
17036 Sent: Sunday, August 31, 2003 1:23 PM
17037 Subject: Re: [IRCServices Coding] Re: [IRCServices] Yet,another great
17041 | By Saturn <saturn@jetirc.net>
17042 | [ 2003-08-31 21:29 +0200 ]
17043 > I think it is... consider an international Network like mine: every
17045 > is in a different time zone -- How are users supposed to know what time
17047 > the Services (pickign on Services' clock because Services are whats giving
17048 > these notices!) is in?? Sure, they can do the /time command, if they even
17049 > know abotu it. But the vast majority of IRC users are ignorant of those
17050 > sorts of commands, or even if they know about /time, they most likely have
17051 > no idea they can specify a server with the command.
17053 Erm, what's the argument here? Services stipulates its timezone in its
17054 timestamps. As do all the other servers on the network.
17061 ------------------------------------------------------------------
17062 To unsubscribe or change your subscription options, visit:
17063 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
17067 From quension at mac.com Sun Aug 31 14:10:45 2003
17068 From: quension at mac.com (Trevor Talbot)
17069 Date: Sat Oct 23 23:09:56 2004
17070 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
17071 another great suggestion
17072 In-Reply-To: <000701c37001$10a62cf0$6401a8c0@turby>
17073 Message-ID: <962546B6-DBF7-11D7-8505-0003938D6866@mac.com>
17075 On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
17077 > The argument is that the overwhelming majority of IRC users have no
17078 > idea the /time command exists, and even fewer are aware that they can
17079 > specify a server name after the /time command. How would these people
17080 > find out the Services time zone?
17082 You missed the point. Services shows the time zone wherever it uses a
17083 readable time -- i.e. in the nickserv/chanserv info displays. Unless
17084 you've changed your language file, in which case you can simply change
17087 > Why does it all have to be so complicated??
17089 It isn't. Your users can even use the handy-dandy /nickserv set
17090 timezone command to make it even easier.
17092 > ----- Original Message -----
17093 > From: "Aragon Gouveia" <aragon@phat.za.net>
17095 > | By Saturn <saturn@jetirc.net>
17096 > | [ 2003-08-31 21:29 +0200 ]
17097 >> I think it is... consider an international Network like mine: every
17098 >> server is in a different time zone -- How are users supposed to know
17099 >> what time zone the Services (pickign on Services' clock because
17100 >> Services are whats giving these notices!) is in?? Sure, they can do
17101 >> the /time command, if they even know abotu it. But the vast majority
17102 >> of IRC users are ignorant of those sorts of commands, or even if they
17103 >> know about /time, they most likely have no idea they can specify a
17104 >> server with the command.
17106 > Erm, what's the argument here? Services stipulates its timezone in
17107 > its timestamps. As do all the other servers on the network.
17112 From us44ever at hotmail.com Sun Aug 31 14:40:36 2003
17113 From: us44ever at hotmail.com (us44ever .)
17114 Date: Sat Oct 23 23:09:56 2004
17115 Subject: [IRCServices Coding]
17116 Re: [IRCServices] Yet, another great suggestion
17117 Message-ID: <Sea1-F8siZAPG4vEjaG0000fb20@hotmail.com>
17120 or even the idea of adding an additional info (exact info) something like:
17121 Last seen time : Aug 22 14:20:16 2003 GMT (9 days, 51 minutes and 21
17123 Time registered : Jul 25 22:19:20 2003 GMT (** days, ** minutes and **
17125 wouldn't even a greater idea?
17127 _________________________________________________________________
17128 Get MSN 8 and enjoy automatic e-mail virus protection.
17129 http://join.msn.com/?page=features/virus
17132 From saturn at jetirc.net Sun Aug 31 16:47:48 2003
17133 From: saturn at jetirc.net (Saturn)
17134 Date: Sat Oct 23 23:09:56 2004
17135 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
17136 another great suggestion
17137 References: <962546B6-DBF7-11D7-8505-0003938D6866@mac.com>
17138 Message-ID: <000e01c3701a$48faea50$6401a8c0@turby>
17140 [16:41] -NickServ- Time registered: Jul 27 13:09:08 2002 PDT
17142 That's what I see when I use it. Yes, it does say "PDT" .. how many people
17143 in, say Belgium, are going to know exactly what PDT is? How about "PDT
17144 (GMT-8)" as the format....? Also, you'll note that it STILL gives no
17145 indication as to the CURRENT time ... this is why the proper UTC code or
17146 GMT+/-## is the best way to go IMHO. I do also like the idea suggested by
17147 us44ever ... the "(** days, ** minutes, and ** seconds ago)" idea... that
17148 would be handy in any event.... and would eliminate the need for the current
17149 time to be displayed....
17151 On another note, I had forgotten the set timezone option, which certainly
17152 would put more clarity on the output... however, I think my points above are
17155 Unless of course I've missed a config setting that will tell it to report
17156 the tiome zone as a function of GMT (plus or minus x hours, rather than zone
17159 ----- Original Message -----
17160 From: "Trevor Talbot" <quension@mac.com>
17161 To: "IRC Services Coding Mailing List"
17162 <ircservices-coding@ircservices.za.net>
17163 Sent: Sunday, August 31, 2003 2:10 PM
17164 Subject: Re: [IRCServices Coding] Re: [IRCServices] Yet,another great
17168 On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
17170 > The argument is that the overwhelming majority of IRC users have no
17171 > idea the /time command exists, and even fewer are aware that they can
17172 > specify a server name after the /time command. How would these people
17173 > find out the Services time zone?
17175 You missed the point. Services shows the time zone wherever it uses a
17176 readable time -- i.e. in the nickserv/chanserv info displays. Unless
17177 you've changed your language file, in which case you can simply change
17180 > Why does it all have to be so complicated??
17182 It isn't. Your users can even use the handy-dandy /nickserv set
17183 timezone command to make it even easier.
17185 > ----- Original Message -----
17186 > From: "Aragon Gouveia" <aragon@phat.za.net>
17188 > | By Saturn <saturn@jetirc.net>
17189 > | [ 2003-08-31 21:29 +0200 ]
17190 >> I think it is... consider an international Network like mine: every
17191 >> server is in a different time zone -- How are users supposed to know
17192 >> what time zone the Services (pickign on Services' clock because
17193 >> Services are whats giving these notices!) is in?? Sure, they can do
17194 >> the /time command, if they even know abotu it. But the vast majority
17195 >> of IRC users are ignorant of those sorts of commands, or even if they
17196 >> know about /time, they most likely have no idea they can specify a
17197 >> server with the command.
17199 > Erm, what's the argument here? Services stipulates its timezone in
17200 > its timestamps. As do all the other servers on the network.
17204 ------------------------------------------------------------------
17205 To unsubscribe or change your subscription options, visit:
17206 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
17210 From quension at mac.com Sun Aug 31 18:24:50 2003
17211 From: quension at mac.com (Trevor Talbot)
17212 Date: Sat Oct 23 23:09:56 2004
17213 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
17214 another great suggestion
17215 In-Reply-To: <000e01c3701a$48faea50$6401a8c0@turby>
17216 Message-ID: <14C7EDD0-DC1B-11D7-8505-0003938D6866@mac.com>
17218 On Sunday, Aug 31, 2003, at 16:47 US/Pacific, Saturn wrote:
17220 > Unless of course I've missed a config setting that will tell it to
17221 > report the tiome zone as a function of GMT (plus or minus x hours,
17222 > rather than zone codes like PDT)...
17224 You could modify the language file, using something like "(GMT%z)"
17225 instead of %Z in the STRFTIME_DATE_TIME_FORMAT string. "man 3
17226 strftime" for the available options.
17231 From achurch at achurch.org Mon Sep 1 10:58:00 2003
17232 From: achurch at achurch.org (Andrew Church)
17233 Date: Sat Oct 23 23:09:56 2004
17234 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
17235 another great suggestion
17236 In-Reply-To: <000e01c3701a$48faea50$6401a8c0@turby>
17237 Message-ID: <3f52a815.21363@achurch.org>
17239 "Use /ns set timezone" is the official answer on this. Please take
17240 all further discussion to the ircservices list.
17243 achurch@achurch.org
17244 http://achurch.org/
17246 >[16:41] -NickServ- Time registered: Jul 27 13:09:08 2002 PDT
17248 >That's what I see when I use it. Yes, it does say "PDT" .. how many people
17249 >in, say Belgium, are going to know exactly what PDT is? How about "PDT
17250 >(GMT-8)" as the format....? Also, you'll note that it STILL gives no
17251 >indication as to the CURRENT time ... this is why the proper UTC code or
17252 >GMT+/-## is the best way to go IMHO. I do also like the idea suggested by
17253 >us44ever ... the "(** days, ** minutes, and ** seconds ago)" idea... that
17254 >would be handy in any event.... and would eliminate the need for the current
17255 >time to be displayed....
17257 >On another note, I had forgotten the set timezone option, which certainly
17258 >would put more clarity on the output... however, I think my points above are
17261 >Unless of course I've missed a config setting that will tell it to report
17262 >the tiome zone as a function of GMT (plus or minus x hours, rather than zone
17263 >codes like PDT)...
17265 >----- Original Message -----
17266 >From: "Trevor Talbot" <quension@mac.com>
17267 >To: "IRC Services Coding Mailing List"
17268 ><ircservices-coding@ircservices.za.net>
17269 >Sent: Sunday, August 31, 2003 2:10 PM
17270 >Subject: Re: [IRCServices Coding] Re: [IRCServices] Yet,another great
17274 >On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
17276 >> The argument is that the overwhelming majority of IRC users have no
17277 >> idea the /time command exists, and even fewer are aware that they can
17278 >> specify a server name after the /time command. How would these people
17279 >> find out the Services time zone?
17281 >You missed the point. Services shows the time zone wherever it uses a
17282 >readable time -- i.e. in the nickserv/chanserv info displays. Unless
17283 >you've changed your language file, in which case you can simply change
17286 >> Why does it all have to be so complicated??
17288 >It isn't. Your users can even use the handy-dandy /nickserv set
17289 >timezone command to make it even easier.
17291 >> ----- Original Message -----
17292 >> From: "Aragon Gouveia" <aragon@phat.za.net>
17294 >> | By Saturn <saturn@jetirc.net>
17295 >> | [ 2003-08-31 21:29 +0200 ]
17296 >>> I think it is... consider an international Network like mine: every
17297 >>> server is in a different time zone -- How are users supposed to know
17298 >>> what time zone the Services (pickign on Services' clock because
17299 >>> Services are whats giving these notices!) is in?? Sure, they can do
17300 >>> the /time command, if they even know abotu it. But the vast majority
17301 >>> of IRC users are ignorant of those sorts of commands, or even if they
17302 >>> know about /time, they most likely have no idea they can specify a
17303 >>> server with the command.
17305 >> Erm, what's the argument here? Services stipulates its timezone in
17306 >> its timestamps. As do all the other servers on the network.
17310 >------------------------------------------------------------------
17311 >To unsubscribe or change your subscription options, visit:
17312 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
17315 >------------------------------------------------------------------
17316 >To unsubscribe or change your subscription options, visit:
17317 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
17319 From simorgh at dataphone.se Sun Aug 31 22:31:35 2003
17320 From: simorgh at dataphone.se (Ali Simorgh)
17321 Date: Sat Oct 23 23:09:56 2004
17322 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
17323 In-Reply-To: <3f520f38.21076@achurch.org>
17324 Message-ID: <Pine.GSO.4.31.0309010728040.7173-100000@nikson.dataphone.se>
17326 Thanks for your help.
17328 I thought if I set nickserv to not be an ircop, then it maybe dosent se
17329 the real host name, and maybe shows the crypted hostname to other users
17330 or should I change this line in language files:
17331 NICK_INFO_ADDRESS_ONLINE
17334 NICK_INFO_ADDRESS_ONLINE
17335 Is online from: N/A ?
17339 ______________________________________________________
17340 Many of life's failures are people who did not realize
17341 how close they were to success when they gave up.
17343 ______________________________________________________
17346 On Mon, 1 Sep 2003, Andrew Church wrote:
17348 > >[Aug 30 10:56:18 2003] mail/sendmail:
17349 > > /usr/sbin/sendmail exited with code 25600
17351 > Use the SMTP module instead (mail/smtp).
17353 > >[Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
17354 > >registration (Simorgh)
17356 > >and how can I do so that nickserv dont show the realhost of a user in
17357 > >'ns info nick all'
17359 > It doesn't. However:
17361 > >[Aug 30 10:51:19 2003] unknown message from server
17362 > >(:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
17364 > You're using the wrong protocol, since it doesn't recognize the
17365 > SETHOST command and therefore has no idea about fake hosts. I might
17366 > remind you that Ultimate 3.x is not supported.
17369 > achurch@achurch.org
17370 > http://achurch.org/
17371 > ------------------------------------------------------------------
17372 > To unsubscribe or change your subscription options, visit:
17373 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
17377 From achurch at achurch.org Mon Sep 1 15:21:08 2003
17378 From: achurch at achurch.org (Andrew Church)
17379 Date: Sat Oct 23 23:09:56 2004
17380 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
17381 In-Reply-To: <Pine.GSO.4.31.0309010728040.7173-100000@nikson.dataphone.se>
17382 Message-ID: <3f52e5fe.41203@achurch.org>
17384 >I thought if I set nickserv to not be an ircop, then it maybe dosent se
17385 >the real host name, and maybe shows the crypted hostname to other users
17387 It isn't a matter of NickServ having operator privileges or not;
17388 Services, as a server, always sees the real hostname. The problem is that
17389 Services and your IRC server aren't using the same protocol, so Services
17390 can't recognize the fake hosts. Try using a different IRC server.
17393 achurch@achurch.org
17394 http://achurch.org/
17396 From laser at musichat.net Wed Sep 3 06:49:54 2003
17397 From: laser at musichat.net (Alessandro Ciappei)
17398 Date: Sat Oct 23 23:09:56 2004
17399 Subject: [IRCServices Coding] New Features
17400 Message-ID: <001b01c37222$428f54d0$e2c0fea9@alexxa3il9cxpx>
17404 I have an idea for next release.
17405 A secure link between services and ircd.
17406 Now many ircd, like Unreal, tr-ircd, bahamut supports a ssl link.
17411 -------------- next part --------------
17412 An HTML attachment was scrubbed...
17413 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030903/a25ee68d/attachment.htm
17414 From r-krisztian at softhome.net Wed Sep 3 07:17:38 2003
17415 From: r-krisztian at softhome.net (Krisztian Romek)
17416 Date: Sat Oct 23 23:09:56 2004
17417 Subject: [IRCServices Coding] New Features
17418 In-Reply-To: <001b01c37222$428f54d0$e2c0fea9@alexxa3il9cxpx>
17419 References: <001b01c37222$428f54d0$e2c0fea9@alexxa3il9cxpx>
17420 Message-ID: <200309031617.38876.r-krisztian@softhome.net>
17425 > I have an idea for next release.
17426 > A secure link between services and ircd.
17427 > Now many ircd, like Unreal, tr-ircd, bahamut supports a ssl link.
17429 I think a ZIP link support (like in Unreal) should also be fine. :-) I don't
17430 know what you will reply for these feature requests, but I agree that they
17431 aren't so important, since in most cases ircd and services run on the same
17436 r-krisztian@softhome.net
17439 From Craig at chatspike.net Wed Sep 3 14:34:29 2003
17440 From: Craig at chatspike.net (Craig McLure)
17441 Date: Sat Oct 23 23:09:56 2004
17442 Subject: [IRCServices Coding] New Features
17443 Message-ID: <20030903203453.ITMO19019.mta3-svc.business.ntl.com@i-br0ked-it>
17445 If you read the archive, you will find that this has already been discussed (fairly recently if i recall..), and was thrown out, if you want services SSL support, i recommend you use a SSL tunnel.
17447 When it comes to ZIP links, this would require editing the services protocol module accordingly.. and IMO, shouldnt been needed, as in most cases, services run on the same box as a server.
17449 /****************************************
17450 * Craig "FrostyCoolSlug" McLure
17451 ************* - SpamBox - **************
17452 * InspIRCd - http://www.inspircd.org
17453 * ChatSpike - http://www.chatspike.net
17454 * WinBot - http://www.winbot.co.uk
17455 ****************************************/
17457 /****************************************
17458 * From - Alessandro Ciappei <laser@musichat.net>
17459 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
17460 * Sent - 2003-09-03 @ 15:49:00
17461 * Subject - [IRCServices Coding] New Features
17462 ****************************************/
17464 /****** - Begin Original Message - ******/
17468 >I have an idea for next release.
17469 >A secure link between services and ircd.
17470 >Now many ircd, like Unreal, tr-ircd, bahamut supports a ssl link.
17475 >------------------------------------------------------------------
17476 >To unsubscribe or change your subscription options, visit:
17477 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
17479 /******* - End Original Message - *******/
17484 From ircserv at elric.net Wed Sep 3 20:49:07 2003
17485 From: ircserv at elric.net (Brent DiNicola)
17486 Date: Sat Oct 23 23:09:56 2004
17487 Subject: [IRCServices Coding] Which route to take - Module?
17488 Message-ID: <5.2.1.1.0.20030903223929.016e4648@mail.elric.net>
17490 It wasn't an easy subject to sum up in just a few words.
17492 I am wanting to do something to the ircservices code, I want to change
17493 the way the notice() works. I know that modifying the send.c would be
17494 very frowned upon and then I got to thinking and had suggested that I
17495 maybe make a module to keep the information for me. I know it's against
17496 the RFC, but I am pressed against a brick wall here, I have to give the users
17497 an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
17498 I would like to give them the option of turning on PRIVMSG but have NOTICE
17499 be the default, that would get the lazy people to use NOTICE. Eventually
17500 getting rid of this problem. In the mean time, I was thinking what is the best
17501 way to go about this without causing trouble for me and anyone else who has
17502 to deal with this code. Is it possible or even suggested to make a module that
17503 would replace the notice() from send.c with it's own, leaving the code in
17505 alone and not causing troubles down the road. Suggestions were that I make a
17506 module that kept the info for each nick's setting and then if I could override
17507 the notice() and notice_lang() and notice_help() in send.c that would keep
17509 other code clean and not cause other troubles. I want to know what the best
17510 way to do this would be, I know it's against RFC but I want to move to newer
17511 services than the 1.4.3pre4 that we are using now and add modules so that I
17512 can do things down the line. They are used to having PRIVMSG and I can't just
17513 change it without running people off, so if I can make PRIVMSG an option
17514 then I can't be blamed if they are lazy. Opinions on how to go about this? I
17515 know this topic has been asked before and I know your not going to make it
17516 part of your code, I just wanted to know from the people who know the code
17517 really well what the best route to take would be to do the least amount of
17518 damage. (And if someone has done this.. please let me know what you did,
17519 examples would rock)
17527 ----------------------------------------------------------
17529 | The Whitewolf of Immyrr |
17530 | <elric@elric.net> |
17531 | http://www.melnibone.net |
17532 | Disclaimer: Any opinions expressed here are |
17533 | from my dog. Any liabilities fall to the dog. |
17534 -----------------------------------------------------------
17537 From Craig at chatspike.net Wed Sep 3 22:17:55 2003
17538 From: Craig at chatspike.net (Craig McLure)
17539 Date: Sat Oct 23 23:09:56 2004
17540 Subject: [IRCServices Coding] Which route to take - Module?
17541 Message-ID: <20030904041818.TXAK19019.mta3-svc.business.ntl.com@i-br0ked-it>
17543 lol, Our help no good? :P
17545 i still say module with seperate database (with the nickgroup, and if this option is on or off (This saves having to modify the main nick.db) , somehow extending the /ns SET command to include a new option.. and replacing what ever function sends notices with something that uses an if to query your new database..
17547 Dont ask me for source on this.. i'm just theorising :)
17549 /****************************************
17550 * Craig "FrostyCoolSlug" McLure
17551 ************* - SpamBox - **************
17552 * InspIRCd - http://www.inspircd.org
17553 * ChatSpike - http://www.chatspike.net
17554 * WinBot - http://www.winbot.co.uk
17555 ****************************************/
17557 /****************************************
17558 * From - Brent DiNicola <ircserv@elric.net>
17559 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
17560 * Sent - 2003-09-03 @ 22:49:00
17561 * Subject - [IRCServices Coding] Which route to take - Module?
17562 ****************************************/
17564 /****** - Begin Original Message - ******/
17566 >It wasn't an easy subject to sum up in just a few words.
17568 >I am wanting to do something to the ircservices code, I want to change
17569 >the way the notice() works. I know that modifying the send.c would be
17570 >very frowned upon and then I got to thinking and had suggested that I
17571 >maybe make a module to keep the information for me. I know it's against
17572 >the RFC, but I am pressed against a brick wall here, I have to give the users
17573 >an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
17574 >I would like to give them the option of turning on PRIVMSG but have NOTICE
17575 >be the default, that would get the lazy people to use NOTICE. Eventually
17576 >getting rid of this problem. In the mean time, I was thinking what is the best
17577 >way to go about this without causing trouble for me and anyone else who has
17578 >to deal with this code. Is it possible or even suggested to make a module that
17579 >would replace the notice() from send.c with it's own, leaving the code in
17581 >alone and not causing troubles down the road. Suggestions were that I make a
17582 >module that kept the info for each nick's setting and then if I could override
17583 >the notice() and notice_lang() and notice_help() in send.c that would keep
17585 >other code clean and not cause other troubles. I want to know what the best
17586 >way to do this would be, I know it's against RFC but I want to move to newer
17587 >services than the 1.4.3pre4 that we are using now and add modules so that I
17588 >can do things down the line. They are used to having PRIVMSG and I can't just
17589 >change it without running people off, so if I can make PRIVMSG an option
17590 >then I can't be blamed if they are lazy. Opinions on how to go about this? I
17591 >know this topic has been asked before and I know your not going to make it
17592 >part of your code, I just wanted to know from the people who know the code
17593 >really well what the best route to take would be to do the least amount of
17594 >damage. (And if someone has done this.. please let me know what you did,
17595 >examples would rock)
17603 >----------------------------------------------------------
17604 >| Brent DiNicola |
17605 >| The Whitewolf of Immyrr |
17606 >| <elric@elric.net> |
17607 >| http://www.melnibone.net |
17608 >| Disclaimer: Any opinions expressed here are |
17609 >| from my dog. Any liabilities fall to the dog. |
17610 >-----------------------------------------------------------
17612 >------------------------------------------------------------------
17613 >To unsubscribe or change your subscription options, visit:
17614 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
17617 /******* - End Original Message - *******/
17622 From uhc0 at rz.uni-karlsruhe.de Thu Sep 4 01:33:03 2003
17623 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu)
17624 Date: Sat Oct 23 23:09:56 2004
17625 Subject: [IRCServices Coding] Which route to take - Module?
17626 In-Reply-To: <5.2.1.1.0.20030903223929.016e4648@mail.elric.net>
17627 References: <5.2.1.1.0.20030903223929.016e4648@mail.elric.net>
17628 Message-ID: <1062664383.1917.15.camel@dreadnought.hadiko.de>
17632 Long question; long answer.
17633 First of all, you must come off the thoughts of "Against the RFC".
17634 Why? Because, tons of irc servers available do provide techniques, which
17635 do not appear, or appear differently on the irc RFC, so that by design
17636 these ircds are also against it. In most of the cases, these changes
17637 reflect themselves in their appropriate server-to-server protocols, and
17638 become transient to the clients, so that on client side, the protocol
17639 remains original. This is also the only way of ensuring that all of the
17640 clients can work with a specific irc daemon.
17642 The issue, why PRIVMSG instead of NOTICE is bad, does also result from
17643 the client-to-server part of the RFC. And it has a reason. Consider two
17644 automated clients (bots, services, etc) talking to each other with
17645 PRIVMSG, and saying things like:
17646 <NickServ> otherwise, I change your nick.
17647 <MyBot> Unknown command otherwise. Please repeat your query.
17648 <NickServ> Unknown command UNKNOWN.
17649 <MyBot> Unknown command unknown. Please repeat your query.
17650 <NickServ> Unknown command UNKNOWN.
17651 <MyBot> Unknown command unknown. Please repeat your query.
17652 <NickServ> Unknown command UNKNOWN.
17653 <MyBot> Unknown command unknown. Please repeat your query.
17654 <NickServ> Unknown command UNKNOWN.
17655 <MyBot> Unknown command unknown. Please repeat your query.
17658 Do you understand, what problem may conclude due to PRIVMSG? RFC says
17659 clearly, that clients shall not generate automatic replies to NOTICES.
17660 That way, your bot would not "talk" to NickServ after a NOTICE anymore.
17663 The most easy implementation of this is creating a NF_USE_PRIVMSG flag,
17664 with a value far greater than any of the built-in, so that in future
17665 this flag does not collide with any of the original flags.
17667 Then you create the new SET command for this, as well as its help text,
17668 primarily in the english language file. That part of the work is
17671 Afterwards, you should modify notice_lang, and check for the
17672 NF_USE_PRIVMSG flag of the "ngi" being used; and if true, send PRIVMSG
17673 instead. The same for notice_help. And your case could be marked as
17676 Do keep in mind that requesting support for modified services versions
17677 are subject to be ignored.
17682 On Thu, 2003-09-04 at 05:49, Brent DiNicola wrote:
17683 > It wasn't an easy subject to sum up in just a few words.
17685 > I am wanting to do something to the ircservices code, I want to change
17686 > the way the notice() works. I know that modifying the send.c would be
17687 > very frowned upon and then I got to thinking and had suggested that I
17688 > maybe make a module to keep the information for me. I know it's against
17689 > the RFC, but I am pressed against a brick wall here, I have to give the users
17690 > an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
17691 > I would like to give them the option of turning on PRIVMSG but have NOTICE
17692 > be the default, that would get the lazy people to use NOTICE. Eventually
17693 > getting rid of this problem. In the mean time, I was thinking what is the best
17694 > way to go about this without causing trouble for me and anyone else who has
17695 > to deal with this code. Is it possible or even suggested to make a module that
17696 > would replace the notice() from send.c with it's own, leaving the code in
17698 > alone and not causing troubles down the road. Suggestions were that I make a
17699 > module that kept the info for each nick's setting and then if I could override
17700 > the notice() and notice_lang() and notice_help() in send.c that would keep
17702 > other code clean and not cause other troubles. I want to know what the best
17703 > way to do this would be, I know it's against RFC but I want to move to newer
17704 > services than the 1.4.3pre4 that we are using now and add modules so that I
17705 > can do things down the line. They are used to having PRIVMSG and I can't just
17706 > change it without running people off, so if I can make PRIVMSG an option
17707 > then I can't be blamed if they are lazy. Opinions on how to go about this? I
17708 > know this topic has been asked before and I know your not going to make it
17709 > part of your code, I just wanted to know from the people who know the code
17710 > really well what the best route to take would be to do the least amount of
17711 > damage. (And if someone has done this.. please let me know what you did,
17712 > examples would rock)
17720 > ----------------------------------------------------------
17721 > | Brent DiNicola |
17722 > | The Whitewolf of Immyrr |
17723 > | <elric@elric.net> |
17724 > | http://www.melnibone.net |
17725 > | Disclaimer: Any opinions expressed here are |
17726 > | from my dog. Any liabilities fall to the dog. |
17727 > -----------------------------------------------------------
17729 > ------------------------------------------------------------------
17730 > To unsubscribe or change your subscription options, visit:
17731 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
17733 ------------------------------------------------------------------
17734 | Yusuf Iskenderoglu | You get to meet all sorts, |
17735 | eMail - uhc0@stud.uni-karlsruhe.de| in this line of work... |
17736 | eMail - s_iskend@ira.uka.de | |
17737 | ICQ UIN : 20587464 \ TimeMr14C | |
17738 ------------------------------------------------------------------
17741 From griever at t2n.org Thu Sep 4 13:29:46 2003
17742 From: griever at t2n.org (Robert F Merrill)
17743 Date: Sat Oct 23 23:09:56 2004
17744 Subject: [IRCServices Coding] Which route to take - Module?
17745 References: <5.2.1.1.0.20030903223929.016e4648@mail.elric.net>
17746 Message-ID: <3F57A0BA.9080909@t2n.org>
17748 Brent DiNicola wrote:
17750 > It wasn't an easy subject to sum up in just a few words.
17752 > I am wanting to do something to the ircservices code, I want to change
17753 > the way the notice() works. I know that modifying the send.c would be
17754 > very frowned upon and then I got to thinking and had suggested that I
17755 > maybe make a module to keep the information for me. I know it's against
17756 > the RFC, but I am pressed against a brick wall here, I have to give
17758 > an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
17759 > I would like to give them the option of turning on PRIVMSG but have
17761 > be the default, that would get the lazy people to use NOTICE. Eventually
17762 > getting rid of this problem. In the mean time, I was thinking what is
17764 > way to go about this without causing trouble for me and anyone else
17766 > to deal with this code. Is it possible or even suggested to make a
17768 > would replace the notice() from send.c with it's own, leaving the code
17770 > alone and not causing troubles down the road. Suggestions were that I
17772 > module that kept the info for each nick's setting and then if I could
17774 > the notice() and notice_lang() and notice_help() in send.c that would
17776 > other code clean and not cause other troubles. I want to know what the
17778 > way to do this would be, I know it's against RFC but I want to move to
17780 > services than the 1.4.3pre4 that we are using now and add modules so
17782 > can do things down the line. They are used to having PRIVMSG and I
17784 > change it without running people off, so if I can make PRIVMSG an option
17785 > then I can't be blamed if they are lazy. Opinions on how to go about
17787 > know this topic has been asked before and I know your not going to
17789 > part of your code, I just wanted to know from the people who know the
17791 > really well what the best route to take would be to do the least
17793 > damage. (And if someone has done this.. please let me know what you did,
17794 > examples would rock)
17802 > ----------------------------------------------------------
17803 > | Brent DiNicola |
17804 > | The Whitewolf of Immyrr |
17805 > | <elric@elric.net> |
17806 > | http://www.melnibone.net |
17807 > | Disclaimer: Any opinions expressed here are |
17808 > | from my dog. Any liabilities fall to the dog. |
17809 > -----------------------------------------------------------
17810 > ------------------------------------------------------------------
17811 > To unsubscribe or change your subscription options, visit:
17812 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
17816 Services is not the place to fix broken clients, and any client which
17817 doesn't display notices correctly is broken. If someone wants to see
17818 notices differently, they can either
17819 a) change their client or in the case of webtv b) change the ircd
17821 services is the wrong thing to change
17824 From Craig at chatspike.net Thu Sep 4 14:52:09 2003
17825 From: Craig at chatspike.net (Craig McLure)
17826 Date: Sat Oct 23 23:09:56 2004
17827 Subject: [IRCServices Coding] Which route to take - Module?
17828 Message-ID: <20030904205232.SDRM23096.mta6-svc.business.ntl.com@i-br0ked-it>
17830 dont mean to sound rude, but this isnt a 'moral' discussion, as it were, rather than saying 'I dont think this needs done', i think it would be best to help him.. its not a discussion on if its right or wrong, its a 'How to do it' discussion.. If you cant contribute to this.. please ignore this 'thread' :p
17832 /****************************************
17833 * Craig "FrostyCoolSlug" McLure
17834 ************* - SpamBox - **************
17835 * InspIRCd - http://www.inspircd.org
17836 * ChatSpike - http://www.chatspike.net
17837 * WinBot - http://www.winbot.co.uk
17838 ****************************************/
17840 /****************************************
17841 * From - Robert F Merrill <griever@t2n.org>
17842 * To - IRC Services Coding Mailing List <ircservices-coding@ircservices.za.net>
17843 * Sent - 2003-09-04 @ 16:29:00
17844 * Subject - Re: [IRCServices Coding] Which route to take - Module?
17845 ****************************************/
17847 /****** - Begin Original Message - ******/
17849 >Brent DiNicola wrote:
17851 >> It wasn't an easy subject to sum up in just a few words.
17853 >> I am wanting to do something to the ircservices code, I want to change
17854 >> the way the notice() works. I know that modifying the send.c would be
17855 >> very frowned upon and then I got to thinking and had suggested that I
17856 >> maybe make a module to keep the information for me. I know it's against
17857 >> the RFC, but I am pressed against a brick wall here, I have to give
17859 >> an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
17860 >> I would like to give them the option of turning on PRIVMSG but have
17862 >> be the default, that would get the lazy people to use NOTICE. Eventually
17863 >> getting rid of this problem. In the mean time, I was thinking what is
17865 >> way to go about this without causing trouble for me and anyone else
17867 >> to deal with this code. Is it possible or even suggested to make a
17869 >> would replace the notice() from send.c with it's own, leaving the code
17871 >> alone and not causing troubles down the road. Suggestions were that I
17873 >> module that kept the info for each nick's setting and then if I could
17875 >> the notice() and notice_lang() and notice_help() in send.c that would
17877 >> other code clean and not cause other troubles. I want to know what the
17879 >> way to do this would be, I know it's against RFC but I want to move to
17881 >> services than the 1.4.3pre4 that we are using now and add modules so
17883 >> can do things down the line. They are used to having PRIVMSG and I
17885 >> change it without running people off, so if I can make PRIVMSG an option
17886 >> then I can't be blamed if they are lazy. Opinions on how to go about
17888 >> know this topic has been asked before and I know your not going to
17890 >> part of your code, I just wanted to know from the people who know the
17892 >> really well what the best route to take would be to do the least
17894 >> damage. (And if someone has done this.. please let me know what you did,
17895 >> examples would rock)
17903 >> ----------------------------------------------------------
17904 >> | Brent DiNicola |
17905 >> | The Whitewolf of Immyrr |
17906 >> | <elric@elric.net> |
17907 >> | http://www.melnibone.net |
17908 >> | Disclaimer: Any opinions expressed here are |
17909 >> | from my dog. Any liabilities fall to the dog. |
17910 >> -----------------------------------------------------------
17911 >> ------------------------------------------------------------------
17912 >> To unsubscribe or change your subscription options, visit:
17913 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
17917 >Services is not the place to fix broken clients, and any client which
17918 >doesn't display notices correctly is broken. If someone wants to see
17919 >notices differently, they can either
17920 >a) change their client or in the case of webtv b) change the ircd
17922 >services is the wrong thing to change
17924 >------------------------------------------------------------------
17925 >To unsubscribe or change your subscription options, visit:
17926 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
17929 /******* - End Original Message - *******/
17934 From quension at mac.com Thu Sep 4 13:54:00 2003
17935 From: quension at mac.com (Trevor Talbot)
17936 Date: Sat Oct 23 23:09:56 2004
17937 Subject: [IRCServices Coding] Which route to take - Module?
17938 In-Reply-To: <3F57A0BA.9080909@t2n.org>
17939 Message-ID: <E8AC4DDC-DF19-11D7-905C-0003938D6866@mac.com>
17941 On Thursday, Sep 4, 2003, at 13:29 US/Pacific, Robert F Merrill wrote:
17943 > Brent DiNicola wrote:
17945 >> It wasn't an easy subject to sum up in just a few words.
17949 > Services is not the place to fix broken clients, and any client which
17950 > doesn't display notices correctly is broken. If someone wants to see
17951 > notices differently, they can either a) change their client or in the
17952 > case of webtv b) change the ircd
17954 > services is the wrong thing to change
17956 And telling someone what they obviously already know is generally not a
17957 good idea. Especially when they spent a very long paragraph defending
17958 their decision in the first place.
17960 This is the coding list, not the feature request list. He asked for
17961 code design approaches, not for political insight.
17966 From diego at redesul.net Thu Sep 18 14:42:39 2003
17967 From: diego at redesul.net (Diego B. Contezini)
17968 Date: Sat Oct 23 23:09:56 2004
17969 Subject: [IRCServices Coding] Re: How to get a core..
17970 Message-ID: <001c01c37e2d$c95d7840$3cc8a8c0@angel>
17972 Oooopz, im answering my ask...
17973 Looking in FAQ, where i should look before ask (sorry), I seen that you need
17974 to change ./configure to drop a core.
17975 If someone more is needing it, is just configure with:
17976 ./configure -dumpcore -cflags -g -defaults
17982 ----- Original Message -----
17983 From: "Diego B. Contezini" <diego@redesul.net>
17984 To: <ircservices-coding@ircservices.za.net>
17985 Sent: Thursday, September 18, 2003 6:35 PM
17986 Subject: How to get a core..
17989 > Hello, im destruct_, im the administrator of the RedeSul Network.
17990 > (irc.redesul.net).
17991 > I'm with 28000 nick registers, sometimes our network get 5500 simultaneous
17992 > users, and we are very happy with your services.
17993 > Im wanting to help to search and stops bugs on ircservices, but i never
17996 > I tryed ulimit -c unlimited before run it, but it never drop a core...
17997 > Someone have any idea about how i can get it, to debug without need to
17999 > the services while debugging?
18000 > Its segfaulting approx. all days, one time for day.. sometimes get 2 days
18001 > without to go down.
18002 > Im with a redhat 9.
18006 > Diego B. Contezini aka destruct_ | irc.redesul.net
18007 > (Sorry for my confuse english.)
18011 From diego at redesul.net Thu Sep 18 14:35:02 2003
18012 From: diego at redesul.net (Diego B. Contezini)
18013 Date: Sat Oct 23 23:09:56 2004
18014 Subject: [IRCServices Coding] How to get a core..
18015 References: <Law14-F109aJWJVUn700006a187@hotmail.com>
18016 Message-ID: <000901c37e2c$b8bd9980$3cc8a8c0@angel>
18018 Hello, im destruct_, im the administrator of the RedeSul Network.
18020 I'm with 28000 nick registers, sometimes our network get 5500 simultaneous
18021 users, and we are very happy with your services.
18022 Im wanting to help to search and stops bugs on ircservices, but i never get
18024 I tryed ulimit -c unlimited before run it, but it never drop a core...
18025 Someone have any idea about how i can get it, to debug without need to break
18026 the services while debugging?
18027 Its segfaulting approx. all days, one time for day.. sometimes get 2 days
18028 without to go down.
18029 Im with a redhat 9.
18033 Diego B. Contezini aka destruct_ | irc.redesul.net
18034 (Sorry for my confuse english.)
18037 From engin at piratetv.net Sun Sep 21 09:40:15 2003
18038 From: engin at piratetv.net (engin@piratetv)
18039 Date: Sat Oct 23 23:09:56 2004
18040 Subject: [IRCServices Coding] operserv
18041 Message-ID: <002101c3805f$0910a4c0$c7cf87d4@ptv91i58zrrpyd>
18045 can anyone help or point me to some good documentation regarding a
18046 version of unreal ircd we are running on a mandrake linux box..im mailing
18047 on behalf of the administrator who usually uses ssh to get into the box
18048 and make changes so im not super technical myself.the issue is with
18049 operserv..i cant access any operserv commands from my machine ( which
18050 is on the same local network as the box running the irc server ) always
18051 get operserv - access denied message..so im assuming it doesent
18052 recognise my remote ip address at an administrator..does anyone know
18053 the right sort of commands to use to set my remote machine to be
18054 recognised as admin or can they point me to any good support docs
18055 as i havent been able to find any yet
18059 -------------- next part --------------
18060 An HTML attachment was scrubbed...
18061 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030921/fdc12b4e/attachment.html
18062 From Craig at chatspike.net Sun Sep 21 15:28:13 2003
18063 From: Craig at chatspike.net (Craig McLure)
18064 Date: Sat Oct 23 23:09:56 2004
18065 Subject: [IRCServices Coding] operserv
18066 Message-ID: <E1A1Bk4-0001Xo-00@ptb-mailc04.plus.net>
18068 make sure you are on the services administrator list, if you are not, get the root administrator to add you using the command:
18070 [22:27] -OperServ- Syntax: ADMIN ADD nickname
18071 [22:27] -OperServ- ADMIN DEL nickname
18072 [22:27] -OperServ- ADMIN LIST
18074 [22:27] -OperServ- Allows the Services super-user to add or remove nicknames
18075 [22:27] -OperServ- to or from the Services admin list. A user whose nickname
18076 [22:27] -OperServ- is on the Services admin list and who has identified to
18077 [22:27] -OperServ- NickServ will be able to access Services admin commands.
18079 [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the command.
18080 [22:27] -OperServ- All other use limited to Services super-user.
18084 /****************************************
18085 * Craig "FrostyCoolSlug" McLure
18086 ************* - SpamBox - **************
18087 * InspIRCd - http://www.inspircd.org
18088 * ChatSpike - http://www.chatspike.net
18089 * WinBot - http://www.winbot.co.uk
18090 ****************************************/
18092 /****************************************
18093 * From - engin <engin@piratetv.net>
18094 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
18095 * Sent - 2003-09-21 @ 17:40:00
18096 * Subject - [IRCServices Coding] operserv
18097 ****************************************/
18099 /****** - Begin Original Message - ******/
18103 >can anyone help or point me to some good documentation regarding a
18104 >version of unreal ircd we are running on a mandrake linux box..im mailing
18105 >on behalf of the administrator who usually uses ssh to get into the box
18106 >and make changes so im not super technical myself.the issue is with
18107 >operserv..i cant access any operserv commands from my machine ( which
18108 >is on the same local network as the box running the irc server ) always
18109 >get operserv - access denied message..so im assuming it doesent
18110 >recognise my remote ip address at an administrator..does anyone know
18111 >the right sort of commands to use to set my remote machine to be
18112 >recognised as admin or can they point me to any good support docs
18113 >as i havent been able to find any yet
18117 >------------------------------------------------------------------
18118 >To unsubscribe or change your subscription options, visit:
18119 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
18121 /******* - End Original Message - *******/
18125 From saturn at jetirc.net Sun Sep 21 15:23:13 2003
18126 From: saturn at jetirc.net (Saturn)
18127 Date: Sat Oct 23 23:09:56 2004
18128 Subject: [IRCServices Coding] operserv
18129 References: <002101c3805f$0910a4c0$c7cf87d4@ptv91i58zrrpyd>
18130 Message-ID: <002b01c3808e$f2590ee0$6401a8c0@turby>
18132 Contact me directly... I have quite a bit of experience with unreal and these services...
18136 ----- Original Message -----
18137 From: engin@piratetv
18138 To: ircservices-coding@ircservices.za.net
18139 Sent: Sunday, September 21, 2003 9:40 AM
18140 Subject: [IRCServices Coding] operserv
18145 can anyone help or point me to some good documentation regarding a
18146 version of unreal ircd we are running on a mandrake linux box..im mailing
18147 on behalf of the administrator who usually uses ssh to get into the box
18148 and make changes so im not super technical myself.the issue is with
18149 operserv..i cant access any operserv commands from my machine ( which
18150 is on the same local network as the box running the irc server ) always
18151 get operserv - access denied message..so im assuming it doesent
18152 recognise my remote ip address at an administrator..does anyone know
18153 the right sort of commands to use to set my remote machine to be
18154 recognised as admin or can they point me to any good support docs
18155 as i havent been able to find any yet
18162 ------------------------------------------------------------------------------
18165 ------------------------------------------------------------------
18166 To unsubscribe or change your subscription options, visit:
18167 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
18168 -------------- next part --------------
18169 An HTML attachment was scrubbed...
18170 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030921/ca188e06/attachment.htm
18171 From saturn at jetirc.net Sun Sep 21 17:13:31 2003
18172 From: saturn at jetirc.net (Saturn)
18173 Date: Sat Oct 23 23:09:56 2004
18174 Subject: [IRCServices Coding] operserv
18175 References: <E1A1Bk4-0001Xo-00@ptb-mailc04.plus.net>
18176 Message-ID: <000d01c3809e$5b9d2800$6401a8c0@turby>
18178 Not to mention the obvious: You need to have an O:line and be opered up
18179 before Operserv will even listen to your commands without access denied....
18181 ----- Original Message -----
18182 From: "Craig McLure" <Craig@chatspike.net>
18183 To: "IRC Services Coding Mailing List"
18184 <ircservices-coding@ircservices.za.net>
18185 Sent: Sunday, September 21, 2003 3:28 PM
18186 Subject: Re: [IRCServices Coding] operserv
18189 make sure you are on the services administrator list, if you are not, get
18190 the root administrator to add you using the command:
18192 [22:27] -OperServ- Syntax: ADMIN ADD nickname
18193 [22:27] -OperServ- ADMIN DEL nickname
18194 [22:27] -OperServ- ADMIN LIST
18196 [22:27] -OperServ- Allows the Services super-user to add or remove nicknames
18197 [22:27] -OperServ- to or from the Services admin list. A user whose nickname
18198 [22:27] -OperServ- is on the Services admin list and who has identified to
18199 [22:27] -OperServ- NickServ will be able to access Services admin commands.
18201 [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
18203 [22:27] -OperServ- All other use limited to Services super-user.
18207 /****************************************
18208 * Craig "FrostyCoolSlug" McLure
18209 ************* - SpamBox - **************
18210 * InspIRCd - http://www.inspircd.org
18211 * ChatSpike - http://www.chatspike.net
18212 * WinBot - http://www.winbot.co.uk
18213 ****************************************/
18215 /****************************************
18216 * From - engin <engin@piratetv.net>
18217 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
18218 * Sent - 2003-09-21 @ 17:40:00
18219 * Subject - [IRCServices Coding] operserv
18220 ****************************************/
18222 /****** - Begin Original Message - ******/
18226 >can anyone help or point me to some good documentation regarding a
18227 >version of unreal ircd we are running on a mandrake linux box..im mailing
18228 >on behalf of the administrator who usually uses ssh to get into the box
18229 >and make changes so im not super technical myself.the issue is with
18230 >operserv..i cant access any operserv commands from my machine ( which
18231 >is on the same local network as the box running the irc server ) always
18232 >get operserv - access denied message..so im assuming it doesent
18233 >recognise my remote ip address at an administrator..does anyone know
18234 >the right sort of commands to use to set my remote machine to be
18235 >recognised as admin or can they point me to any good support docs
18236 >as i havent been able to find any yet
18240 >------------------------------------------------------------------
18241 >To unsubscribe or change your subscription options, visit:
18242 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
18244 /******* - End Original Message - *******/
18247 ------------------------------------------------------------------
18248 To unsubscribe or change your subscription options, visit:
18249 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
18252 From engin at piratetv.net Mon Sep 22 05:17:11 2003
18253 From: engin at piratetv.net (engin@piratetv)
18254 Date: Sat Oct 23 23:09:56 2004
18255 Subject: [IRCServices Coding] Re: IRCServices-Coding Digest, Vol 8, Issue 5
18256 References: <20030922120923.425971706D@snow.fingers.co.za>
18257 Message-ID: <003c01c38103$73a516f0$c7cf87d4@ptv91i58zrrpyd>
18259 many thanks for the replies..im going to get the info to the
18260 root administrator now and ill let you know how i get
18267 ----- Original Message -----
18268 From: <ircservices-coding-request@ircservices.za.net>
18269 To: <ircservices-coding@ircservices.za.net>
18270 Sent: Monday, September 22, 2003 1:09 PM
18271 Subject: IRCServices-Coding Digest, Vol 8, Issue 5
18274 > Send IRCServices-Coding mailing list submissions to
18275 > ircservices-coding@ircservices.za.net
18277 > To subscribe or unsubscribe via the World Wide Web, visit
18278 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
18279 > or, via email, send a message with subject or body 'help' to
18280 > ircservices-coding-request@ircservices.za.net
18282 > You can reach the person managing the list at
18283 > ircservices-coding-owner@ircservices.za.net
18285 > When replying, please edit your Subject line so it is more specific
18286 > than "Re: Contents of IRCServices-Coding digest..."
18291 > 1. operserv (engin@piratetv)
18292 > 2. Re: operserv (Craig McLure)
18293 > 3. Re: operserv (Saturn)
18294 > 4. Re: operserv (Saturn)
18297 > ----------------------------------------------------------------------
18300 > Date: Sun, 21 Sep 2003 17:40:15 +0100
18301 > From: "engin@piratetv" <engin@piratetv.net>
18302 > Subject: [IRCServices Coding] operserv
18303 > To: <ircservices-coding@ircservices.za.net>
18304 > Message-ID: <002101c3805f$0910a4c0$c7cf87d4@ptv91i58zrrpyd>
18305 > Content-Type: text/plain; charset="iso-8859-1"
18309 > can anyone help or point me to some good documentation regarding a
18310 > version of unreal ircd we are running on a mandrake linux box..im mailing
18311 > on behalf of the administrator who usually uses ssh to get into the box
18312 > and make changes so im not super technical myself.the issue is with
18313 > operserv..i cant access any operserv commands from my machine ( which
18314 > is on the same local network as the box running the irc server ) always
18315 > get operserv - access denied message..so im assuming it doesent
18316 > recognise my remote ip address at an administrator..does anyone know
18317 > the right sort of commands to use to set my remote machine to be
18318 > recognised as admin or can they point me to any good support docs
18319 > as i havent been able to find any yet
18323 > -------------- next part --------------
18324 > An HTML attachment was scrubbed...
18326 http://snow.fingers.co.za/pipermail/ircservices-coding/attachments/20030921/
18327 fdc12b4e/attachment-0001.htm
18329 > ------------------------------
18332 > Date: Sun, 21 Sep 2003 22:28:13 +0000
18333 > From: "Craig McLure" <Craig@chatspike.net>
18334 > Subject: Re: [IRCServices Coding] operserv
18335 > To: IRC Services Coding Mailing List
18336 > <ircservices-coding@ircservices.za.net>
18337 > Message-ID: <E1A1Bk4-0001Xo-00@ptb-mailc04.plus.net>
18338 > Content-Type: text/plain; charset="us-ascii"
18340 > make sure you are on the services administrator list, if you are not, get
18341 the root administrator to add you using the command:
18343 > [22:27] -OperServ- Syntax: ADMIN ADD nickname
18344 > [22:27] -OperServ- ADMIN DEL nickname
18345 > [22:27] -OperServ- ADMIN LIST
18346 > [22:27] -OperServ-
18347 > [22:27] -OperServ- Allows the Services super-user to add or remove
18349 > [22:27] -OperServ- to or from the Services admin list. A user whose
18351 > [22:27] -OperServ- is on the Services admin list and who has identified to
18352 > [22:27] -OperServ- NickServ will be able to access Services admin
18354 > [22:27] -OperServ-
18355 > [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
18357 > [22:27] -OperServ- All other use limited to Services super-user.
18361 > /****************************************
18362 > * Craig "FrostyCoolSlug" McLure
18363 > ************* - SpamBox - **************
18364 > * InspIRCd - http://www.inspircd.org
18365 > * ChatSpike - http://www.chatspike.net
18366 > * WinBot - http://www.winbot.co.uk
18367 > ****************************************/
18369 > /****************************************
18370 > * From - engin <engin@piratetv.net>
18371 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
18372 > * Sent - 2003-09-21 @ 17:40:00
18373 > * Subject - [IRCServices Coding] operserv
18374 > ****************************************/
18376 > /****** - Begin Original Message - ******/
18380 > >can anyone help or point me to some good documentation regarding a
18381 > >version of unreal ircd we are running on a mandrake linux box..im mailing
18382 > >on behalf of the administrator who usually uses ssh to get into the box
18383 > >and make changes so im not super technical myself.the issue is with
18384 > >operserv..i cant access any operserv commands from my machine ( which
18385 > >is on the same local network as the box running the irc server ) always
18386 > >get operserv - access denied message..so im assuming it doesent
18387 > >recognise my remote ip address at an administrator..does anyone know
18388 > >the right sort of commands to use to set my remote machine to be
18389 > >recognised as admin or can they point me to any good support docs
18390 > >as i havent been able to find any yet
18394 > >------------------------------------------------------------------
18395 > >To unsubscribe or change your subscription options, visit:
18396 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
18398 > /******* - End Original Message - *******/
18402 > ------------------------------
18405 > Date: Sun, 21 Sep 2003 15:23:13 -0700
18406 > From: "Saturn" <saturn@jetirc.net>
18407 > Subject: Re: [IRCServices Coding] operserv
18408 > To: "IRC Services Coding Mailing List"
18409 > <ircservices-coding@ircservices.za.net>
18410 > Message-ID: <002b01c3808e$f2590ee0$6401a8c0@turby>
18411 > Content-Type: text/plain; charset="iso-8859-1"
18413 > Contact me directly... I have quite a bit of experience with unreal and
18418 > ----- Original Message -----
18419 > From: engin@piratetv
18420 > To: ircservices-coding@ircservices.za.net
18421 > Sent: Sunday, September 21, 2003 9:40 AM
18422 > Subject: [IRCServices Coding] operserv
18427 > can anyone help or point me to some good documentation regarding a
18428 > version of unreal ircd we are running on a mandrake linux box..im
18430 > on behalf of the administrator who usually uses ssh to get into the box
18431 > and make changes so im not super technical myself.the issue is with
18432 > operserv..i cant access any operserv commands from my machine ( which
18433 > is on the same local network as the box running the irc server ) always
18434 > get operserv - access denied message..so im assuming it doesent
18435 > recognise my remote ip address at an administrator..does anyone know
18436 > the right sort of commands to use to set my remote machine to be
18437 > recognised as admin or can they point me to any good support docs
18438 > as i havent been able to find any yet
18445 > --------------------------------------------------------------------------
18449 > ------------------------------------------------------------------
18450 > To unsubscribe or change your subscription options, visit:
18451 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
18452 > -------------- next part --------------
18453 > An HTML attachment was scrubbed...
18455 http://snow.fingers.co.za/pipermail/ircservices-coding/attachments/20030921/
18456 ca188e06/attachment-0001.htm
18458 > ------------------------------
18461 > Date: Sun, 21 Sep 2003 17:13:31 -0700
18462 > From: "Saturn" <saturn@jetirc.net>
18463 > Subject: Re: [IRCServices Coding] operserv
18464 > To: "IRC Services Coding Mailing List"
18465 > <ircservices-coding@ircservices.za.net>
18466 > Message-ID: <000d01c3809e$5b9d2800$6401a8c0@turby>
18467 > Content-Type: text/plain; charset="iso-8859-1"
18469 > Not to mention the obvious: You need to have an O:line and be opered up
18470 > before Operserv will even listen to your commands without access
18473 > ----- Original Message -----
18474 > From: "Craig McLure" <Craig@chatspike.net>
18475 > To: "IRC Services Coding Mailing List"
18476 > <ircservices-coding@ircservices.za.net>
18477 > Sent: Sunday, September 21, 2003 3:28 PM
18478 > Subject: Re: [IRCServices Coding] operserv
18481 > make sure you are on the services administrator list, if you are not, get
18482 > the root administrator to add you using the command:
18484 > [22:27] -OperServ- Syntax: ADMIN ADD nickname
18485 > [22:27] -OperServ- ADMIN DEL nickname
18486 > [22:27] -OperServ- ADMIN LIST
18487 > [22:27] -OperServ-
18488 > [22:27] -OperServ- Allows the Services super-user to add or remove
18490 > [22:27] -OperServ- to or from the Services admin list. A user whose
18492 > [22:27] -OperServ- is on the Services admin list and who has identified to
18493 > [22:27] -OperServ- NickServ will be able to access Services admin
18495 > [22:27] -OperServ-
18496 > [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
18498 > [22:27] -OperServ- All other use limited to Services super-user.
18502 > /****************************************
18503 > * Craig "FrostyCoolSlug" McLure
18504 > ************* - SpamBox - **************
18505 > * InspIRCd - http://www.inspircd.org
18506 > * ChatSpike - http://www.chatspike.net
18507 > * WinBot - http://www.winbot.co.uk
18508 > ****************************************/
18510 > /****************************************
18511 > * From - engin <engin@piratetv.net>
18512 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
18513 > * Sent - 2003-09-21 @ 17:40:00
18514 > * Subject - [IRCServices Coding] operserv
18515 > ****************************************/
18517 > /****** - Begin Original Message - ******/
18521 > >can anyone help or point me to some good documentation regarding a
18522 > >version of unreal ircd we are running on a mandrake linux box..im mailing
18523 > >on behalf of the administrator who usually uses ssh to get into the box
18524 > >and make changes so im not super technical myself.the issue is with
18525 > >operserv..i cant access any operserv commands from my machine ( which
18526 > >is on the same local network as the box running the irc server ) always
18527 > >get operserv - access denied message..so im assuming it doesent
18528 > >recognise my remote ip address at an administrator..does anyone know
18529 > >the right sort of commands to use to set my remote machine to be
18530 > >recognised as admin or can they point me to any good support docs
18531 > >as i havent been able to find any yet
18535 > >------------------------------------------------------------------
18536 > >To unsubscribe or change your subscription options, visit:
18537 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
18539 > /******* - End Original Message - *******/
18542 > ------------------------------------------------------------------
18543 > To unsubscribe or change your subscription options, visit:
18544 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
18547 > ------------------------------
18549 > _______________________________________________
18550 > IRCServices-Coding mailing list
18551 > IRCServices-Coding@ircservices.za.net
18552 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
18555 > End of IRCServices-Coding Digest, Vol 8, Issue 5
18556 > ************************************************
18559 From diego at redesul.net Sun Oct 5 15:38:11 2003
18560 From: diego at redesul.net (Diego B. Contezini)
18561 Date: Sat Oct 23 23:09:56 2004
18562 Subject: [IRCServices Coding] Bug....
18563 References: <E1A1Bk4-0001Xo-00@ptb-mailc04.plus.net>
18564 <000d01c3809e$5b9d2800$6401a8c0@turby>
18565 Message-ID: <003b01c38b91$5f6a32e0$3cc8a8c0@angel>
18567 Sometimes has occur this bug, last 1 year....
18568 on a network with 30k registers, its happening with latency of 3.. 4
18571 someone have any idea?
18573 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
18574 av=0xbfffeec8) at channels.c:278
18577 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
18578 av=0xbfffeec8) at channels.c:278
18579 chan = (Channel *) 0xa97b6b8
18580 s = 0x20656c62 <Address 0x20656c62 out of bounds>
18582 modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
18583 #1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:680
18585 "-isl\000\037\006\bp?????????@???\006\b\000\000\000\000\000\000\000B\000\000
18586 \000\0007 \006\b\003\000\000\000TZ\000\000????????????
18587 ?????????\001\200??????@???\006\b@???\006\b@???\006\b@???\006\bO???\006\b@\0
18588 02\a\b@???\006\b@\002\a\b", '\0' <repeats 20 times>,
18589 "\027\000\000\000\000\000\000\000W???\022B\000\000\000\000\000\000\000\000\0
18590 05\000\000\000\210o\a\bTZ\000\000\000\000\000\000???????????????<\023B\001\0
18591 00\000\000???????????????m\tBd???\022B???q\a\b\v???\006B\024\032\023B\024\03
18592 2\023B3\035\rB\024\032\023B??????\006B\003\000\000\000????????????\027\000\0
18593 00\000\000\000\000\000\024\032"...
18594 s = 0xbfffeef0 "-isl"
18595 argv = {0xa97b6c0 "#young", 0x20656c62 <Address 0x20656c62 out of
18597 0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 out
18598 of bounds>, 0x42133cec "\004", 0xbffff1fc "",
18599 0x4204533d "\201?????????\016", 0x42131a14 " \031\023B???h\001@`???"}
18603 #2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
18607 md = (struct modedata *) 0x0
18612 #3 0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at main.c:269
18614 now_msec = 241253125
18615 last_update = 1065392973
18616 last_check = 241252363
18617 #4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
18618 No symbol table info available.
18623 From achurch at achurch.org Mon Oct 6 16:41:15 2003
18624 From: achurch at achurch.org (Andrew Church)
18625 Date: Sat Oct 23 23:09:56 2004
18626 Subject: [IRCServices Coding] Bug....
18627 In-Reply-To: <003b01c38b91$5f6a32e0$3cc8a8c0@angel>
18628 Message-ID: <3f811cad.24262@achurch.org>
18633 achurch@achurch.org
18634 http://achurch.org/
18636 >Sometimes has occur this bug, last 1 year....
18637 >on a network with 30k registers, its happening with latency of 3.. 4
18640 >someone have any idea?
18642 >#0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
18643 >av=0xbfffeec8) at channels.c:278
18646 >#0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
18647 >av=0xbfffeec8) at channels.c:278
18648 > chan = (Channel *) 0xa97b6b8
18649 > s = 0x20656c62 <Address 0x20656c62 out of bounds>
18651 > modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
18652 >#1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:68
18655 >"-isl\000\037\006\bp���@�\006\b\000\000\0
18656 >00\000\000\000\000B\000\000
18657 >\000\0007 \006\b\003\000\000\000TZ\000\000���ï¿
18659 >���\001\200��@�\006\b@ï
18660 >¿½\006\b@�\006\b@�\006\bO�\006\b@\0
18661 >02\a\b@�\006\b@\002\a\b", '\0' <repeats 20 times>,
18662 >"\027\000\000\000\000\000\000\000W�\022B\000\000\000\000\000\000\
18664 >05\000\000\000\210o\a\bTZ\000\000\000\000\000\000��ï¿
18665 >½ï¿½ï¿½<\023B\001\0
18666 >00\000\000�����m\tBd�\022
18667 >B�q\a\b\v�\006B\024\032\023B\024\03
18668 >2\023B3\035\rB\024\032\023B��\006B\003\000\000\000�
18670 >00\000\000\000\000\000\024\032"...
18671 > s = 0xbfffeef0 "-isl"
18672 > argv = {0xa97b6c0 "#young", 0x20656c62 <Address 0x20656c62 out
18675 > 0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 o
18677 >of bounds>, 0x42133cec "\004", 0xbffff1fc "",
18678 > 0x4204533d "\201���\016", 0x42131a14 " \031\023
18683 >#2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:32
18688 > md = (struct modedata *) 0x0
18693 >#3 0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at ma
18696 > now_msec = 241253125
18697 > last_update = 1065392973
18698 > last_check = 241252363
18699 >#4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
18700 >No symbol table info available.
18704 >------------------------------------------------------------------
18705 >To unsubscribe or change your subscription options, visit:
18706 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
18708 From diego at redesul.net Mon Oct 6 02:36:19 2003
18709 From: diego at redesul.net (Diego B. Contezini)
18710 Date: Sat Oct 23 23:09:56 2004
18711 Subject: [IRCServices Coding] Bug....
18712 References: <3f811cad.24262@achurch.org>
18713 Message-ID: <005501c38bed$4c9b1dd0$3cc8a8c0@angel>
18716 ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
18720 Its the last version.......
18723 ----- Original Message -----
18724 From: "Andrew Church" <achurch@achurch.org>
18725 To: <ircservices-coding@ircservices.za.net>
18726 Sent: Monday, October 06, 2003 4:41 AM
18727 Subject: Re: [IRCServices Coding] Bug....
18733 > achurch@achurch.org
18734 > http://achurch.org/
18736 > >Sometimes has occur this bug, last 1 year....
18737 > >on a network with 30k registers, its happening with latency of 3.. 4
18740 > >someone have any idea?
18742 > >#0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
18743 > >av=0xbfffeec8) at channels.c:278
18744 > >278 while (*s) {
18746 > >#0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
18747 > >av=0xbfffeec8) at channels.c:278
18748 > > chan = (Channel *) 0xa97b6b8
18749 > > s = 0x20656c62 <Address 0x20656c62 out of bounds>
18751 > > modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
18752 > >#1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:68
18755 > >"-isl\000\037\006\bp?????????@???\006\b\000\000\0
18756 > >00\000\000\000\000B\000\000
18757 > >\000\0007 \006\b\003\000\000\000TZ\000\000???????????
18759 > >?????????\001\200??????@???\006\b@?
18760 > >??\006\b@???\006\b@???\006\bO???\006\b@\0
18761 > >02\a\b@???\006\b@\002\a\b", '\0' <repeats 20 times>,
18762 > >"\027\000\000\000\000\000\000\000W???\022B\000\000\000\000\000\000\
18764 > >05\000\000\000\210o\a\bTZ\000\000\000\000\000\000????????
18765 > >???????<\023B\001\0
18766 > >00\000\000???????????????m\tBd???\022
18767 > >B???q\a\b\v???\006B\024\032\023B\024\03
18768 > >2\023B3\035\rB\024\032\023B??????\006B\003\000\000\000???
18769 > >?????????\027\000\0
18770 > >00\000\000\000\000\000\024\032"...
18771 > > s = 0xbfffeef0 "-isl"
18772 > > argv = {0xa97b6c0 "#young", 0x20656c62 <Address 0x20656c62 out
18775 > > 0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 o
18777 > >of bounds>, 0x42133cec "\004", 0xbffff1fc "",
18778 > > 0x4204533d "\201?????????\016", 0x42131a14 " \031\023
18779 > >B???h\001@`???"}
18783 > >#2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:32
18787 > > modes_orig = 0x0
18788 > > md = (struct modedata *) 0x0
18793 > >#3 0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at ma
18795 > > now = 1065393142
18796 > > now_msec = 241253125
18797 > > last_update = 1065392973
18798 > > last_check = 241252363
18799 > >#4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
18800 > >No symbol table info available.
18804 > >------------------------------------------------------------------
18805 > >To unsubscribe or change your subscription options, visit:
18806 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
18807 > ------------------------------------------------------------------
18808 > To unsubscribe or change your subscription options, visit:
18809 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
18813 From achurch at achurch.org Mon Oct 6 22:44:19 2003
18814 From: achurch at achurch.org (Andrew Church)
18815 Date: Sat Oct 23 23:09:56 2004
18816 Subject: [IRCServices Coding] Bug....
18817 In-Reply-To: <005501c38bed$4c9b1dd0$3cc8a8c0@angel>
18818 Message-ID: <3f8171f9.25006@achurch.org>
18821 >ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
18825 >Its the last version.......
18827 Then send a full debug log (from startup to crash), or I can't help.
18830 achurch@achurch.org
18831 http://achurch.org/
18833 From diego at redesul.net Mon Oct 6 17:15:43 2003
18834 From: diego at redesul.net (Diego B. Contezini)
18835 Date: Sat Oct 23 23:09:56 2004
18836 Subject: [IRCServices Coding] Bug....
18837 References: <3f8171f9.25006@achurch.org>
18838 Message-ID: <010601c38c68$2e6dc8a0$3cc8a8c0@angel>
18840 And how should be this log? i sent a backtrace......
18843 ----- Original Message -----
18844 From: "Andrew Church" <achurch@achurch.org>
18845 To: <ircservices-coding@ircservices.za.net>
18846 Sent: Monday, October 06, 2003 10:44 AM
18847 Subject: Re: [IRCServices Coding] Bug....
18851 > >ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
18852 > >18:41:36 BRT 2003
18855 > >Its the last version.......
18857 > Then send a full debug log (from startup to crash), or I can't help.
18860 > achurch@achurch.org
18861 > http://achurch.org/
18862 > ------------------------------------------------------------------
18863 > To unsubscribe or change your subscription options, visit:
18864 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
18868 From achurch at achurch.org Tue Oct 7 11:31:41 2003
18869 From: achurch at achurch.org (Andrew Church)
18870 Date: Sat Oct 23 23:09:56 2004
18871 Subject: [IRCServices Coding] Bug....
18872 In-Reply-To: <010601c38c68$2e6dc8a0$3cc8a8c0@angel>
18873 Message-ID: <3f822598.26100@achurch.org>
18875 >And how should be this log? i sent a backtrace......
18880 achurch@achurch.org
18881 http://achurch.org/
18883 From diego at redesul.net Mon Oct 6 22:36:12 2003
18884 From: diego at redesul.net (Diego B. Contezini)
18885 Date: Sat Oct 23 23:09:56 2004
18886 Subject: [IRCServices Coding] Bug....
18887 References: <3f822598.26100@achurch.org>
18888 Message-ID: <011601c38c94$ebc3ec00$3cc8a8c0@angel>
18891 If i start it with -debug it will get me gb's of information. This occur
18892 after days with services up, i will try to run it into a screen.... with
18897 ----- Original Message -----
18898 From: "Andrew Church" <achurch@achurch.org>
18899 To: <ircservices-coding@ircservices.za.net>
18900 Sent: Monday, October 06, 2003 11:31 PM
18901 Subject: Re: [IRCServices Coding] Bug....
18904 > >And how should be this log? i sent a backtrace......
18909 > achurch@achurch.org
18910 > http://achurch.org/
18911 > ------------------------------------------------------------------
18912 > To unsubscribe or change your subscription options, visit:
18913 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
18917 From saturn at jetirc.net Fri Oct 10 15:48:27 2003
18918 From: saturn at jetirc.net (Saturn)
18919 Date: Sat Oct 23 23:09:56 2004
18920 Subject: [IRCServices Coding] Akill problem in 5.0.22
18921 References: <14C7EDD0-DC1B-11D7-8505-0003938D6866@mac.com>
18922 Message-ID: <004001c38f80$9f635960$6401a8c0@turby>
18924 Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
18925 duplicate exit system notice that happens in 3.1.6).
18927 I just today added an akill (+0 time) .. I DO have the immediate auto kill
18928 option un-commented in the modules.conf, but it still didn't bother scanning
18929 for victims matching my akill mask nor did it actually KILL anyone... It
18930 works if they are manually killed and then try to re-connect, but I thought
18931 that new option was so Services will immediately scan for and kill anyone
18932 online that matches the mask as soon as the new akill is added...
18934 First: IS that what it's supposed to do?
18936 Second: If so, it's not working...
18942 From laser at musichat.net Sat Oct 11 00:56:45 2003
18943 From: laser at musichat.net (Alessandro Ciappei)
18944 Date: Sat Oct 23 23:09:56 2004
18945 Subject: [IRCServices Coding] Problem with auth mail
18946 In-Reply-To: <20031007101106.2701D1703F@snow.fingers.co.za>
18947 Message-ID: <GMEFIDBHIMPENBMIJNFEEEGDCAAA.laser@musichat.net>
18950 Hi all, I've ircservices 5.0.22, and I would like to costumize auth-mail.
18951 I would like describe my irc network in this mail, but when someone register
18952 nick, services go in segfault.
18954 I copy the sintaz of mail-auth ( it's in italian )
18956 # Mail text. The last "%s" (before the user@host) in the body text is
18957 # replaced by one of the NICK_AUTH_MAIL_TEXT_* messages.
18958 NICK_AUTH_MAIL_SUBJECT
18959 Conferma della registrazione del nick %s
18960 NICK_AUTH_MAIL_BODY
18961 Grazie per aver scelto MusiChat Net Community!
18962 Il codice di autorizzazione del tuo nick (%s) e': %09d
18963 Identificati su MusiChat digitando:
18966 La registrazione del tuo nick sara' confermata e il tuo nickname
18967 sara' protetto da eventuali tentativi di abuso o furto.
18969 Il sito ufficiale della rete e' http://www.musichat.net/
18970 I regolamenti della rete e i documenti ufficiali sono
18971 disponibili all'interno del sito.
18973 Per ricevere assistenza sui servizi della rete
18974 in generale puoi rivolgerti sul canale ufficiale #IRCHelp
18975 oppure tramite email all'indirizzo irchelp@musichat.net.
18978 Sono inoltre disponibili i seguenti servizi:
18981 Forum di discussione di MusiChat, raggiungibile
18982 all'indirizzo http://forum.musichat.net
18983 Sul forum, oltre a poter esprimere la tua opinione,
18984 potrai informarti sulle novita' e sui nuovi servizi
18985 offerti dalla rete.
18987 - MusiChat Mailing List
18988 Per iscriversi e' sufficiente visitare il sito
18989 http://lists.musichat.net/mailman/listinfo/irchelp
18990 e inserire il proprio indirizzo E-Mail e la
18991 password desiderata.
18994 Per una connessione piu' veloce e sicura e' vivamente
18995 consigliato l'utilizzo del seguente server: irc.musichat.net
18997 MusiChat Net Community
18999 Questo messaggio e stato inviato su richiesta di %s in risposta a %s
19005 I read the istruction for translate.
19009 [Oct 11 09:48:30 2003] PANIC! buffer = :alpha_omega ! nickserv :register
19010 pippo laser@musichat.net
19011 [Oct 11 09:48:30 2003] Services terminating: Segmentation fault
19014 Some one can help me?
19015 the email body is too long?
19023 From achurch at achurch.org Fri Oct 17 15:57:50 2003
19024 From: achurch at achurch.org (Andrew Church)
19025 Date: Sat Oct 23 23:09:56 2004
19026 Subject: [IRCServices Coding] Problem with auth mail
19027 In-Reply-To: <GMEFIDBHIMPENBMIJNFEEEGDCAAA.laser@musichat.net>
19028 Message-ID: <3f8f9304.20227@achurch.org>
19030 You have the wrong number of %-tokens in your message.
19033 achurch@achurch.org
19034 http://achurch.org/
19037 >Hi all, I've ircservices 5.0.22, and I would like to costumize auth-mail.
19038 >I would like describe my irc network in this mail, but when someone register
19039 >nick, services go in segfault.
19041 >I copy the sintaz of mail-auth ( it's in italian )
19043 ># Mail text. The last "%s" (before the user@host) in the body text is
19044 ># replaced by one of the NICK_AUTH_MAIL_TEXT_* messages.
19045 >NICK_AUTH_MAIL_SUBJECT
19046 > Conferma della registrazione del nick %s
19047 >NICK_AUTH_MAIL_BODY
19048 > Grazie per aver scelto MusiChat Net Community!
19049 > Il codice di autorizzazione del tuo nick (%s) e': %09d
19050 > Identificati su MusiChat digitando:
19051 > /msg %s AUTH %09d
19053 > La registrazione del tuo nick sara' confermata e il tuo nickname
19054 > sara' protetto da eventuali tentativi di abuso o furto.
19056 > Il sito ufficiale della rete e' http://www.musichat.net/
19057 > I regolamenti della rete e i documenti ufficiali sono
19058 > disponibili all'interno del sito.
19060 > Per ricevere assistenza sui servizi della rete
19061 > in generale puoi rivolgerti sul canale ufficiale #IRCHelp
19062 > oppure tramite email all'indirizzo irchelp@musichat.net.
19065 > Sono inoltre disponibili i seguenti servizi:
19068 > Forum di discussione di MusiChat, raggiungibile
19069 > all'indirizzo http://forum.musichat.net
19070 > Sul forum, oltre a poter esprimere la tua opinione,
19071 > potrai informarti sulle novita' e sui nuovi servizi
19072 > offerti dalla rete.
19074 > - MusiChat Mailing List
19075 > Per iscriversi e' sufficiente visitare il sito
19076 > http://lists.musichat.net/mailman/listinfo/irchelp
19077 > e inserire il proprio indirizzo E-Mail e la
19078 > password desiderata.
19081 > Per una connessione piu' veloce e sicura e' vivamente
19082 > consigliato l'utilizzo del seguente server: irc.musichat.net
19084 > MusiChat Net Community
19086 > Questo messaggio e stato inviato su richiesta di %s in risposta a %s
19092 >I read the istruction for translate.
19096 >[Oct 11 09:48:30 2003] PANIC! buffer = :alpha_omega ! nickserv :register
19097 >pippo laser@musichat.net
19098 >[Oct 11 09:48:30 2003] Services terminating: Segmentation fault
19101 >Some one can help me?
19102 >the email body is too long?
19109 >------------------------------------------------------------------
19110 >To unsubscribe or change your subscription options, visit:
19111 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
19113 From saman at alkol.org Fri Oct 17 03:07:15 2003
19114 From: saman at alkol.org (|SaMaN|)
19115 Date: Sat Oct 23 23:09:56 2004
19116 Subject: [IRCServices Coding] Bug or misunderstood ?
19117 Message-ID: <000901c39496$71764f10$a37faec3@coder>
19119 Im using unreal ircd. When channel is empty and if channel owner joins
19120 his/her registered channel it does
19121 (ChanServ sets mode: +ntrq nick) but when channel is not empty and if
19122 channel owner joins his/her registered channel it does (ChanServ sets mode:
19123 +oq nick nick). As you see on the first one there is no +o and because of
19124 this chanserv does not update the last_used time because chanserv is set to
19125 update last_used time with +o (CUMODE_o) so channels drop while channel
19126 owners use them. Is this a bug or my misunderstood ?
19128 ######################################################
19129 modules/chanserv/check.c
19131 void check_chan_user_modes(const char *source, struct c_userlist *u,
19132 Channel *c, int32 oldmodes)
19134 if ((res & ~modes) & CUMODE_o) {
19135 ci->last_used = time(NULL);
19136 put_channelinfo(ci);
19139 ######################################################
19145 From saman at alkol.org Fri Oct 17 04:52:50 2003
19146 From: saman at alkol.org (|SaMaN|)
19147 Date: Sat Oct 23 23:09:57 2004
19148 Subject: [IRCServices Coding] Re: Bug or misunderstood ?
19149 Message-ID: <002001c394a5$31c059b0$a37faec3@coder>
19151 Also it does not update last_used time on +a flag.
19156 edit /modules/chanserv/check.c
19159 -------------------------------------------------------------------------
19160 local_set_cumodes(c, '+', res & ~modes, user->nick);
19161 -------------------------------------------------------------------------
19163 ------------------------------------------------------------------------
19164 int16 cumode_q = mode_char_to_flag('q',MODE_CHANUSER);
19165 int16 cumode_a = mode_char_to_flag('a',MODE_CHANUSER);
19167 if ((res & ~modes) & cumode_q) {
19168 ci->last_used = time(NULL);
19169 put_channelinfo(ci);
19172 if ((res & ~modes) & cumode_a) {
19173 ci->last_used = time(NULL);
19174 put_channelinfo(ci);
19176 -------------------------------------------------------------------------
19177 save and compile and run and enjoy :)
19178 -------------------------------------------------------------------------
19182 ----- Original Message -----
19183 From: "|SaMaN|" <saman@alkol.org>
19184 To: <IRCServices-Coding@ircservices.za.net>
19185 Sent: Friday, October 17, 2003 1:07 PM
19186 Subject: Bug or misunderstood ?
19189 > Im using unreal ircd. When channel is empty and if channel owner joins
19190 > his/her registered channel it does
19191 > (ChanServ sets mode: +ntrq nick) but when channel is not empty and if
19192 > channel owner joins his/her registered channel it does (ChanServ sets
19194 > +oq nick nick). As you see on the first one there is no +o and because of
19195 > this chanserv does not update the last_used time because chanserv is set
19197 > update last_used time with +o (CUMODE_o) so channels drop while channel
19198 > owners use them. Is this a bug or my misunderstood ?
19200 > ######################################################
19201 > modules/chanserv/check.c
19203 > void check_chan_user_modes(const char *source, struct c_userlist *u,
19204 > Channel *c, int32 oldmodes)
19206 > if ((res & ~modes) & CUMODE_o) {
19207 > ci->last_used = time(NULL);
19208 > put_channelinfo(ci);
19211 > ######################################################
19218 From saturn at jetirc.net Fri Oct 17 08:47:29 2003
19219 From: saturn at jetirc.net (Saturn)
19220 Date: Sat Oct 23 23:09:57 2004
19221 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
19222 Message-ID: <002501c394c5$f8dce480$6401a8c0@turby>
19224 Haven't seen a reply to this one, so thought I'd better make sure this went
19227 ----- Original Message -----
19228 Sent: Friday, October 10, 2003 3:48 PM
19229 Subject: Akill problem in 5.0.22
19232 Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
19233 duplicate exit system notice that happens in 3.1.6).
19235 I just today added an akill (+0 time) .. I DO have the immediate auto kill
19236 option un-commented in the modules.conf, but it still didn't bother scanning
19237 for victims matching my akill mask nor did it actually KILL anyone... It
19238 works if they are manually killed and then try to re-connect, but I thought
19239 that new option was so Services will immediately scan for and kill anyone
19240 online that matches the mask as soon as the new akill is added...
19242 First: IS that what it's supposed to do?
19244 Second: If so, it's not working...
19250 From achurch at achurch.org Sat Oct 18 01:02:58 2003
19251 From: achurch at achurch.org (Andrew Church)
19252 Date: Sat Oct 23 23:09:57 2004
19253 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
19254 In-Reply-To: <002501c394c5$f8dce480$6401a8c0@turby>
19255 Message-ID: <3f9012b8.23176@achurch.org>
19260 achurch@achurch.org
19261 http://achurch.org/
19263 >Haven't seen a reply to this one, so thought I'd better make sure this went
19266 >----- Original Message -----
19267 >Sent: Friday, October 10, 2003 3:48 PM
19268 >Subject: Akill problem in 5.0.22
19271 >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
19272 >duplicate exit system notice that happens in 3.1.6).
19274 >I just today added an akill (+0 time) .. I DO have the immediate auto kill
19275 >option un-commented in the modules.conf, but it still didn't bother scanning
19276 >for victims matching my akill mask nor did it actually KILL anyone... It
19277 >works if they are manually killed and then try to re-connect, but I thought
19278 >that new option was so Services will immediately scan for and kill anyone
19279 >online that matches the mask as soon as the new akill is added...
19281 >First: IS that what it's supposed to do?
19283 >Second: If so, it's not working...
19288 >------------------------------------------------------------------
19289 >To unsubscribe or change your subscription options, visit:
19290 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
19292 From saturn at jetirc.net Fri Oct 17 09:18:09 2003
19293 From: saturn at jetirc.net (Saturn)
19294 Date: Sat Oct 23 23:09:57 2004
19295 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
19296 References: <3f9012b8.23176@achurch.org>
19297 Message-ID: <027401c394ca$443ae180$6401a8c0@turby>
19299 Well, Andrew, I did read TFM. For what it's worth, all I found was this
19300 entry under the description of the module options
19302 ImmediatelySendAutokill [OPTIONAL]
19303 Causes OperServ to inform all servers of a new autokill or autokill
19304 exclusion the moment it is added, rather than waiting for someone to match
19306 Example: ImmediatelySendAutokill
19308 I read through the section about AKILLs and SQline, SGline, SZline, etc,
19309 however all of what I read indicates that simply enabling the
19310 ImmediatelySendAutokill option in the modules.conf (coupled with the fact
19311 that everything ELSE is set up and workign properly) SHOULD cause services
19312 to immediately scan the network for clients matching the akill mask, and
19315 My point, sir, is that IT DOES NOT DO THIS. Thus, I'm sure you'll find, I
19316 HAVE in fact read the f___ manual, and the manual does not address this
19317 problem. If it doesn't matter to you, fine, but if it does, let's try and
19318 get on with maybe solving the problem?
19323 ----- Original Message -----
19324 From: "Andrew Church" <achurch@achurch.org>
19325 To: <ircservices-coding@ircservices.za.net>
19326 Sent: Friday, October 17, 2003 9:02 AM
19327 Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
19333 achurch@achurch.org
19334 http://achurch.org/
19336 >Haven't seen a reply to this one, so thought I'd better make sure this went
19339 >----- Original Message -----
19340 >Sent: Friday, October 10, 2003 3:48 PM
19341 >Subject: Akill problem in 5.0.22
19344 >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
19345 >duplicate exit system notice that happens in 3.1.6).
19347 >I just today added an akill (+0 time) .. I DO have the immediate auto kill
19348 >option un-commented in the modules.conf, but it still didn't bother
19350 >for victims matching my akill mask nor did it actually KILL anyone... It
19351 >works if they are manually killed and then try to re-connect, but I thought
19352 >that new option was so Services will immediately scan for and kill anyone
19353 >online that matches the mask as soon as the new akill is added...
19355 >First: IS that what it's supposed to do?
19357 >Second: If so, it's not working...
19362 >------------------------------------------------------------------
19363 >To unsubscribe or change your subscription options, visit:
19364 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
19365 ------------------------------------------------------------------
19366 To unsubscribe or change your subscription options, visit:
19367 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
19370 From achurch at achurch.org Sat Oct 18 01:34:15 2003
19371 From: achurch at achurch.org (Andrew Church)
19372 Date: Sat Oct 23 23:09:57 2004
19373 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
19374 In-Reply-To: <027401c394ca$443ae180$6401a8c0@turby>
19375 Message-ID: <3f901a20.23266@achurch.org>
19377 >however all of what I read indicates that simply enabling the
19378 >ImmediatelySendAutokill option in the modules.conf (coupled with the fact
19379 >that everything ELSE is set up and workign properly) SHOULD cause services
19380 >to immediately scan the network for clients matching the akill mask, and
19383 The documentation says nothing about this. RTFM again.
19386 achurch@achurch.org
19387 http://achurch.org/
19389 From ballsy at mystical.net Fri Oct 17 11:20:16 2003
19390 From: ballsy at mystical.net (Ballsy)
19391 Date: Sat Oct 23 23:09:57 2004
19392 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
19393 In-Reply-To: <027401c394ca$443ae180$6401a8c0@turby>
19394 References: <3f9012b8.23176@achurch.org> <027401c394ca$443ae180$6401a8c0@turby>
19395 Message-ID: <6.0.0.22.0.20031017121557.01b63ac0@127.0.0.1>
19397 To save the rest of us from having to put up with more bickering,
19398 it may be of note that I had to comment out 'EnableExclude' in order for my
19399 immediate-kill functionality to work under bahamut (I know, you're using
19400 Unreal). All the ImmediatelySendAkill does is informs all linked services
19401 that they should add an Akill. It's then up to those servers to decide how
19407 At 10:18 AM 17/10/2003, Saturn wrote:
19408 >Well, Andrew, I did read TFM. For what it's worth, all I found was this
19409 >entry under the description of the module options
19411 >ImmediatelySendAutokill [OPTIONAL]
19412 > Causes OperServ to inform all servers of a new autokill or autokill
19413 >exclusion the moment it is added, rather than waiting for someone to match
19415 > Example: ImmediatelySendAutokill
19417 >I read through the section about AKILLs and SQline, SGline, SZline, etc,
19418 >however all of what I read indicates that simply enabling the
19419 >ImmediatelySendAutokill option in the modules.conf (coupled with the fact
19420 >that everything ELSE is set up and workign properly) SHOULD cause services
19421 >to immediately scan the network for clients matching the akill mask, and
19424 >My point, sir, is that IT DOES NOT DO THIS. Thus, I'm sure you'll find, I
19425 >HAVE in fact read the f___ manual, and the manual does not address this
19426 >problem. If it doesn't matter to you, fine, but if it does, let's try and
19427 >get on with maybe solving the problem?
19432 >----- Original Message -----
19433 >From: "Andrew Church" <achurch@achurch.org>
19434 >To: <ircservices-coding@ircservices.za.net>
19435 >Sent: Friday, October 17, 2003 9:02 AM
19436 >Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
19442 > achurch@achurch.org
19443 > http://achurch.org/
19445 > >Haven't seen a reply to this one, so thought I'd better make sure this went
19448 > >----- Original Message -----
19449 > >Sent: Friday, October 10, 2003 3:48 PM
19450 > >Subject: Akill problem in 5.0.22
19453 > >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
19454 > >duplicate exit system notice that happens in 3.1.6).
19456 > >I just today added an akill (+0 time) .. I DO have the immediate auto kill
19457 > >option un-commented in the modules.conf, but it still didn't bother
19459 > >for victims matching my akill mask nor did it actually KILL anyone... It
19460 > >works if they are manually killed and then try to re-connect, but I thought
19461 > >that new option was so Services will immediately scan for and kill anyone
19462 > >online that matches the mask as soon as the new akill is added...
19464 > >First: IS that what it's supposed to do?
19466 > >Second: If so, it's not working...
19471 > >------------------------------------------------------------------
19472 > >To unsubscribe or change your subscription options, visit:
19473 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
19474 >------------------------------------------------------------------
19475 >To unsubscribe or change your subscription options, visit:
19476 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
19478 >------------------------------------------------------------------
19479 >To unsubscribe or change your subscription options, visit:
19480 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
19484 From saturn at jetirc.net Fri Oct 17 17:15:14 2003
19485 From: saturn at jetirc.net (Saturn)
19486 Date: Sat Oct 23 23:09:57 2004
19487 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
19488 References: <3f901a20.23266@achurch.org>
19489 Message-ID: <02d401c3950c$e762bda0$6401a8c0@turby>
19491 >From a.html in the /docs directory:
19493 operserv/akill (Autokill module settings)
19494 ImmediatelySendAutokill [OPTIONAL]
19495 Causes OperServ to inform all servers of a new autokill or autokill
19496 exclusion the moment it is added, rather than waiting for someone to match
19498 Example: ImmediatelySendAutokill
19501 3.html#4-3 in the /docs directory does not speak to the
19502 ImmediatelySendAutokill option except for the mention that:
19503 "(If the ImmediatelySendAutokill option in modules.conf is enabled, the
19504 last-used time will never be set at all on these servers.)"
19505 However, this is in the context of talking about Slines, etc, and as far as
19506 I can tell has no new useful information to impart regarding my stated
19507 problem: that services is NOT "Immediately sending the autokill" on my
19508 network and thus when a new AKILL is added, the matching users/masks are not
19509 being killed off, unless they are killed manually by an IRCop. Yes, it IS
19510 catching them when they attempt to re-connect, that was never a problem. It
19511 would make sense that if an autokill is added, that Services would
19512 immediately trace the network and kill off any matches to that akill... at
19513 least, it makes sense if this option is enabled.... (to me)
19514 ------------------------
19516 4.html#oper.akill doesn't mention it at all.
19520 I really don't see where else I'm supposed to be looking here. I've scoured
19521 the docs and can see no other reference to it. If there's something I'm
19522 missing, perhaps instead of rudely, repeatedly telling me to RTFM, maybe
19523 just tell me what it is I'm supposed to find! I've already spend a few
19524 hours reading through the docs (which I've already read about a dozen times
19525 over the past year alone), and I'm telling you, there's nothing else about
19526 it that I can find!!!
19528 The ONLY thing I can come up with is that the feature name is misleading and
19529 the option doesn't in fact do what it SEEMS it should do. Could it be that
19530 all that does is send the S/G/Z line (whatever is appropriate) to the
19531 servers and that's all??? NOW I have to ask, why bother, if it'll do that
19532 if/when they re-connect anyhow?
19534 Additionally, if the reason I can't find the answer in the manual is because
19535 the option DOESN'T make services kill all matches when the akill is added,
19536 then Imust ask WHY that isn't an option, since it seems logically useful to
19537 me and my staff. Also, that being the case, why couldn't you simply SAY
19538 that it's not designed to do that, instead of sending me hunting (TWICE) for
19539 non-existant information in the docs???????
19541 I'm very interested to hear the answer to these questions. To put it
19542 bluntly, I have been an extremely enthusiastic advocate of IRCServices for
19543 over 3 years now, have turned many network owners onto them, and love them
19544 to death. The way you "talk" to your supporters on this forum sometimes
19545 leaves a LOT to be desired. If the feature doesn't exist as I understand
19546 it, just SAY SO and save us all a lot of trouble -- don't just tell me to go
19547 RTFM when the info I seek isn't IN it. Having said that, if you can point
19548 me to the info in the docs in the 5.0.22 distro and prove my claims as
19549 baseless, I will offer my sincere apologies. Until then, my opinion stands.
19553 ----- Original Message -----
19554 From: "Andrew Church" <achurch@achurch.org>
19555 To: <ircservices-coding@ircservices.za.net>
19556 Sent: Friday, October 17, 2003 9:34 AM
19557 Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
19560 >however all of what I read indicates that simply enabling the
19561 >ImmediatelySendAutokill option in the modules.conf (coupled with the fact
19562 >that everything ELSE is set up and workign properly) SHOULD cause services
19563 >to immediately scan the network for clients matching the akill mask, and
19566 The documentation says nothing about this. RTFM again.
19569 achurch@achurch.org
19570 http://achurch.org/
19571 ------------------------------------------------------------------
19572 To unsubscribe or change your subscription options, visit:
19573 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
19576 From saturn at jetirc.net Fri Oct 17 17:31:53 2003
19577 From: saturn at jetirc.net (Saturn)
19578 Date: Sat Oct 23 23:09:57 2004
19579 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
19580 References: <3f9012b8.23176@achurch.org> <027401c394ca$443ae180$6401a8c0@turby>
19581 <6.0.0.22.0.20031017121557.01b63ac0@127.0.0.1>
19582 Message-ID: <030801c3950f$3cb55270$6401a8c0@turby>
19584 Would have been nice if someone had mentioned that (about the
19585 ImmediatelySendAutokill) from the start. I would say the flag is misleading
19586 in title then, because I (and 8 other people on my staff -- none of us are
19587 dummies, either) read that as meaning it will Immediately send the auto
19588 kill... "ImmediatelyUpdateServers" might be more fitting from an intuitive
19589 standpoint, not that I'm suggesting changing the name, but at least the
19590 documentation of it could be a bit more explicit IMHO.
19592 and yes, I know there will be about 50 people (probably all of them
19593 hard-core coders) shaking their heads in disbelief at what I've said, but
19594 let's face it: If we were ALL hard-core coders, we wouldn't need Andrew and
19595 his IRCServices, would we? We'd all be making our own. So all I'm saying
19596 is how about a little slack for those of us with OTHER important skills that
19597 might fall outside the scope of being the "world's greatest expert" on IRC
19600 ----- Original Message -----
19601 From: "Ballsy" <ballsy@mystical.net>
19602 To: "IRC Services Coding Mailing List"
19603 <ircservices-coding@ircservices.za.net>; "IRC Services Coding Mailing List"
19604 <ircservices-coding@ircservices.za.net>
19605 Sent: Friday, October 17, 2003 11:20 AM
19606 Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
19609 To save the rest of us from having to put up with more bickering,
19610 it may be of note that I had to comment out 'EnableExclude' in order for my
19611 immediate-kill functionality to work under bahamut (I know, you're using
19612 Unreal). All the ImmediatelySendAkill does is informs all linked services
19613 that they should add an Akill. It's then up to those servers to decide how
19619 At 10:18 AM 17/10/2003, Saturn wrote:
19620 >Well, Andrew, I did read TFM. For what it's worth, all I found was this
19621 >entry under the description of the module options
19623 >ImmediatelySendAutokill [OPTIONAL]
19624 > Causes OperServ to inform all servers of a new autokill or autokill
19625 >exclusion the moment it is added, rather than waiting for someone to match
19627 > Example: ImmediatelySendAutokill
19629 >I read through the section about AKILLs and SQline, SGline, SZline, etc,
19630 >however all of what I read indicates that simply enabling the
19631 >ImmediatelySendAutokill option in the modules.conf (coupled with the fact
19632 >that everything ELSE is set up and workign properly) SHOULD cause services
19633 >to immediately scan the network for clients matching the akill mask, and
19636 >My point, sir, is that IT DOES NOT DO THIS. Thus, I'm sure you'll find, I
19637 >HAVE in fact read the f___ manual, and the manual does not address this
19638 >problem. If it doesn't matter to you, fine, but if it does, let's try and
19639 >get on with maybe solving the problem?
19644 >----- Original Message -----
19645 >From: "Andrew Church" <achurch@achurch.org>
19646 >To: <ircservices-coding@ircservices.za.net>
19647 >Sent: Friday, October 17, 2003 9:02 AM
19648 >Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
19654 > achurch@achurch.org
19655 > http://achurch.org/
19657 > >Haven't seen a reply to this one, so thought I'd better make sure this
19661 > >----- Original Message -----
19662 > >Sent: Friday, October 10, 2003 3:48 PM
19663 > >Subject: Akill problem in 5.0.22
19666 > >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
19667 > >duplicate exit system notice that happens in 3.1.6).
19669 > >I just today added an akill (+0 time) .. I DO have the immediate auto
19671 > >option un-commented in the modules.conf, but it still didn't bother
19673 > >for victims matching my akill mask nor did it actually KILL anyone... It
19674 > >works if they are manually killed and then try to re-connect, but I
19676 > >that new option was so Services will immediately scan for and kill anyone
19677 > >online that matches the mask as soon as the new akill is added...
19679 > >First: IS that what it's supposed to do?
19681 > >Second: If so, it's not working...
19686 > >------------------------------------------------------------------
19687 > >To unsubscribe or change your subscription options, visit:
19688 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
19689 >------------------------------------------------------------------
19690 >To unsubscribe or change your subscription options, visit:
19691 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
19693 >------------------------------------------------------------------
19694 >To unsubscribe or change your subscription options, visit:
19695 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
19698 ------------------------------------------------------------------
19699 To unsubscribe or change your subscription options, visit:
19700 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
19703 From Craig at chatspike.net Fri Oct 17 20:07:46 2003
19704 From: Craig at chatspike.net (Craig McLure)
19705 Date: Sat Oct 23 23:09:57 2004
19706 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
19707 Message-ID: <E1AAgV1-0008ae-00@ptb-mailc04.plus.net>
19709 Theres no need for flaming ffs.. just because something makes less sence to you than to everyone else, doesnt instantly mean that it has to be changed.. i seemed to understand it ok, and i'm sure that there are several hundred other IRCServices users who didnt have any problems with this directive.
19711 I'm sure andy will concider documenting it more "accuratly" (I wont speak for him thou, his choice :p), but theres no need for the flaming, if you have such a big problem with something that (apparently just) you dont understand, just make a passing mention on it, dont go on talking about "Hard-core coders" and "worlds biggest expert"s cause you are upset with something. If the last paragraph wasnt made, i'm sure there _WOUDLNT_ be "about 50 people (probably all of them hard-core coders) shaking their heads in disbelief", cause it doesnt happen. And to clarify.. theres no such thing as a "world biggest expert" when it comes to IRC programming, people have different preferances, and ways of doing things, to the point that you cant compair something like InspIRCd to UnrealIRCd, as they are totally different in almost every way. :p
19713 Please just calm down, and talk this out rationally before you start jumping down ppls throats :p
19715 /*****************************************
19716 * Craig "FrostyCoolSlug" McLure
19717 * InspIRCd - http://www.inspircd.org
19718 * ChatSpike - http://www.chatspike.net
19719 ****************************************/
19722 /****************************************
19723 * From - Saturn <saturn@jetirc.net>
19724 * To - IRC Services Coding Mailing List <ircservices-coding@ircservices.za.net>
19725 * Sent - 2003-10-17 17:31:00
19726 * Subject - Re: [IRCServices Coding] Re: Akill problem in 5.0.22
19727 ****************************************/
19729 /****** - Begin Original Message - ******/
19731 >Would have been nice if someone had mentioned that (about the
19732 >ImmediatelySendAutokill) from the start. I would say the flag is misleading
19733 >in title then, because I (and 8 other people on my staff -- none of us are
19734 >dummies, either) read that as meaning it will Immediately send the auto
19735 >kill... "ImmediatelyUpdateServers" might be more fitting from an intuitive
19736 >standpoint, not that I'm suggesting changing the name, but at least the
19737 >documentation of it could be a bit more explicit IMHO.
19739 >and yes, I know there will be about 50 people (probably all of them
19740 >hard-core coders) shaking their heads in disbelief at what I've said, but
19741 >let's face it: If we were ALL hard-core coders, we wouldn't need Andrew and
19742 >his IRCServices, would we? We'd all be making our own. So all I'm saying
19743 >is how about a little slack for those of us with OTHER important skills that
19744 >might fall outside the scope of being the "world's greatest expert" on IRC
19747 >----- Original Message -----
19748 >From: "Ballsy" <ballsy@mystical.net>
19749 >To: "IRC Services Coding Mailing List"
19750 ><ircservices-coding@ircservices.za.net>; "IRC Services Coding Mailing List"
19751 ><ircservices-coding@ircservices.za.net>
19752 >Sent: Friday, October 17, 2003 11:20 AM
19753 >Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
19756 > To save the rest of us from having to put up with more bickering,
19757 >it may be of note that I had to comment out 'EnableExclude' in order for my
19758 >immediate-kill functionality to work under bahamut (I know, you're using
19759 >Unreal). All the ImmediatelySendAkill does is informs all linked services
19760 >that they should add an Akill. It's then up to those servers to decide how
19766 >At 10:18 AM 17/10/2003, Saturn wrote:
19767 >>Well, Andrew, I did read TFM. For what it's worth, all I found was this
19768 >>entry under the description of the module options
19770 >>ImmediatelySendAutokill [OPTIONAL]
19771 >> Causes OperServ to inform all servers of a new autokill or autokill
19772 >>exclusion the moment it is added, rather than waiting for someone to match
19774 >> Example: ImmediatelySendAutokill
19776 >>I read through the section about AKILLs and SQline, SGline, SZline, etc,
19777 >>however all of what I read indicates that simply enabling the
19778 >>ImmediatelySendAutokill option in the modules.conf (coupled with the fact
19779 >>that everything ELSE is set up and workign properly) SHOULD cause services
19780 >>to immediately scan the network for clients matching the akill mask, and
19783 >>My point, sir, is that IT DOES NOT DO THIS. Thus, I'm sure you'll find, I
19784 >>HAVE in fact read the f___ manual, and the manual does not address this
19785 >>problem. If it doesn't matter to you, fine, but if it does, let's try and
19786 >>get on with maybe solving the problem?
19791 >>----- Original Message -----
19792 >>From: "Andrew Church" <achurch@achurch.org>
19793 >>To: <ircservices-coding@ircservices.za.net>
19794 >>Sent: Friday, October 17, 2003 9:02 AM
19795 >>Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
19801 >> achurch@achurch.org
19802 >> http://achurch.org/
19804 >> >Haven't seen a reply to this one, so thought I'd better make sure this
19808 >> >----- Original Message -----
19809 >> >Sent: Friday, October 10, 2003 3:48 PM
19810 >> >Subject: Akill problem in 5.0.22
19813 >> >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
19814 >> >duplicate exit system notice that happens in 3.1.6).
19816 >> >I just today added an akill (+0 time) .. I DO have the immediate auto
19818 >> >option un-commented in the modules.conf, but it still didn't bother
19820 >> >for victims matching my akill mask nor did it actually KILL anyone... It
19821 >> >works if they are manually killed and then try to re-connect, but I
19823 >> >that new option was so Services will immediately scan for and kill anyone
19824 >> >online that matches the mask as soon as the new akill is added...
19826 >> >First: IS that what it's supposed to do?
19828 >> >Second: If so, it's not working...
19833 >> >------------------------------------------------------------------
19834 >> >To unsubscribe or change your subscription options, visit:
19835 >> >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
19836 >>------------------------------------------------------------------
19837 >>To unsubscribe or change your subscription options, visit:
19838 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
19840 >>------------------------------------------------------------------
19841 >>To unsubscribe or change your subscription options, visit:
19842 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
19845 >------------------------------------------------------------------
19846 >To unsubscribe or change your subscription options, visit:
19847 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
19849 >------------------------------------------------------------------
19850 >To unsubscribe or change your subscription options, visit:
19851 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
19855 /******* - End Original Message - *******/
19860 From achurch at achurch.org Sat Oct 18 11:57:43 2003
19861 From: achurch at achurch.org (Andrew Church)
19862 Date: Sat Oct 23 23:09:57 2004
19863 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
19864 In-Reply-To: <02d401c3950c$e762bda0$6401a8c0@turby>
19865 Message-ID: <3f90afdf.23477@achurch.org>
19867 You know, I might have been more forgiving if this hadn't been gone
19868 over on this list (twice!) before:
19870 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/002305.html
19871 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/003215.html
19873 However, since you seem to have trouble both comprehending the
19874 documentation and reading the archives, I have added FAQ F.10 for your
19877 F.10. Services doesn't kill users matching a newly-added autokill mask even
19878 if ImmediatelySendAutokill is set.
19880 Services never kills users when a new autokill is added; the
19881 ImmediatelySendAutokill configuration directive only causes
19882 Services to send the autokill itself (that is, the user/host mask
19883 to prohibit new connections from) to the IRC servers on your
19884 network. This is a safety feature intended to limit the damage
19885 caused by a mistyped autokill.
19887 Note that some IRC servers will themselves kill users matching a
19888 newly-added autokill; this is unrelated to Services.
19891 achurch@achurch.org
19892 http://achurch.org/
19894 From griever at t2n.org Fri Oct 17 21:20:07 2003
19895 From: griever at t2n.org (Robert F Merrill)
19896 Date: Sat Oct 23 23:09:57 2004
19897 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
19898 In-Reply-To: <030801c3950f$3cb55270$6401a8c0@turby>
19899 References: <3f9012b8.23176@achurch.org> <027401c394ca$443ae180$6401a8c0@turby>
19900 <6.0.0.22.0.20031017121557.01b63ac0@127.0.0.1>
19901 <030801c3950f$3cb55270$6401a8c0@turby>
19902 Message-ID: <3F90BF77.2010706@t2n.org>
19906 >Would have been nice if someone had mentioned that (about the
19907 >ImmediatelySendAutokill) from the start. I would say the flag is misleading
19908 >in title then, because I (and 8 other people on my staff -- none of us are
19909 >dummies, either) read that as meaning it will Immediately send the auto
19910 >kill... "ImmediatelyUpdateServers" might be more fitting from an intuitive
19911 >standpoint, not that I'm suggesting changing the name, but at least the
19912 >documentation of it could be a bit more explicit IMHO.
19915 It DOES immediately send the autokill. You just don't grasp the meaning
19916 of sending the autokill.
19917 It literally sends an AKILL (or TKL in the case of unreal) message to
19918 the servers. At least unreal
19919 and bahamut will then scan for matching clients and disconnect them,
19920 however not all servers
19923 If you are using unreal and it doesn't disconnect the matching users,
19924 then it is either a bug in
19925 unreal (not uncommon) or the services really *aren't* sending the tkl
19926 message (doubt it).
19928 Try adding an akill for a connected client. If the client doesn't die,
19929 do a /stats g on their server.
19930 You should see a g-line added for them.
19932 Also note that if you have akill exclusions enabled (bad idea most of
19933 the time), services will NEVER add an akill
19934 or gline on servers that don't support akill or gline exclusions (I
19935 don't know of any that do), but rather
19936 manually kill everyone that matches as they connect. In this case, you
19937 should disable akill exclusions and
19938 it should start working.
19942 From v13 at it.teithe.gr Sat Oct 18 11:49:18 2003
19943 From: v13 at it.teithe.gr (V13)
19944 Date: Sat Oct 23 23:09:57 2004
19945 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
19946 In-Reply-To: <3F90BF77.2010706@t2n.org>
19947 References: <3f9012b8.23176@achurch.org> <030801c3950f$3cb55270$6401a8c0@turby>
19948 <3F90BF77.2010706@t2n.org>
19949 Message-ID: <200310182149.18600.v13@it.teithe.gr>
19951 On Saturday 18 October 2003 07:20, Robert F Merrill wrote:
19953 > >Would have been nice if someone had mentioned that (about the
19954 > >ImmediatelySendAutokill) from the start. I would say the flag is
19955 > > misleading in title then, because I (and 8 other people on my staff --
19956 > > none of us are dummies, either) read that as meaning it will Immediately
19957 > > send the auto kill... "ImmediatelyUpdateServers" might be more fitting
19958 > > from an intuitive standpoint, not that I'm suggesting changing the name,
19959 > > but at least the documentation of it could be a bit more explicit IMHO.
19961 > It DOES immediately send the autokill. You just don't grasp the meaning
19962 > of sending the autokill.
19963 > It literally sends an AKILL (or TKL in the case of unreal) message to
19964 > the servers. At least unreal
19965 > and bahamut will then scan for matching clients and disconnect them,
19966 > however not all servers
19969 FYI bahamut doesn't do this. It will only do it whenever a new client that
19970 matches the akill connects to the server.
19972 i.e. if you set an akill for *.com noone will be disconnected untill a new
19973 client from *.com gets connected (at that moment, all matching clients will
19974 be killed). In the mean time, anyone from other domains can connect to the
19975 server without having any user killed.
19979 From diego at redesul.net Sat Oct 18 12:16:38 2003
19980 From: diego at redesul.net (Diego B. Contezini)
19981 Date: Sat Oct 23 23:09:57 2004
19982 Subject: [IRCServices Coding] CORE DUMPED! BUG!
19983 References: <3f8f9304.20227@achurch.org>
19984 Message-ID: <000e01c395ac$5b773b40$3cc8a8c0@angel>
19986 Andrew, you told me about debugging.. now i got it ;]
19987 here is the debugging:
19988 [Oct 18 16:05:31.288944 2003] debug: Sent: :ChanServ TOPIC #EMOCORE reffer
19989 1066055037 :1i?? Festival HARDcoCOREcore dia 25 de outubro em blumenau no
19990 rio bravo bar (proximo a resima agua verde), com as bandas: Zero Ltda
19991 (curitiba), Swallow the Waffle (bc), chymia(bnu), crazy frogs (lages),
19992 surpise set e slipper (bnu)...3 pila entrada inicio as 15:00 horas'
19993 [Oct 18 16:05:31.289032 2003] debug: Received: :|-Frango-| MODE
19994 #EMOCORE -oooooo CHoPP CbRS-oFF caroll BRYAN brunaH balsanelli
19995 Segmentation fault (core dumped)
19997 root@irc(/home/ircadmin/services/lib)# ls -la core.12631
19998 -rw------- 1 ircadmin ircadmin 47374336 Oct 18 16:05 core.12631
20001 continue on the next message......
20004 From diego at redesul.net Sat Oct 18 12:17:16 2003
20005 From: diego at redesul.net (Diego B. Contezini)
20006 Date: Sat Oct 23 23:09:57 2004
20007 Subject: [IRCServices Coding] CORE DUMPED... continue...
20008 References: <3f8f9304.20227@achurch.org>
20009 Message-ID: <001201c395ac$71b42210$3cc8a8c0@angel>
20011 #0 0x0804d830 in add_mode_with_params (md=0x806aa00, mode=111 'o',
20012 is_add=1, params=1, parambuf=0xbfffe280 "balsanelli",
20013 len=10) at actions.c:568
20014 568 md->params[md->nopmodes][len] = 0;
20016 #0 0x0804d830 in add_mode_with_params (md=0x806aa00, mode=111 'o',
20017 is_add=1, params=1, parambuf=0xbfffe280 "balsanelli",
20018 len=10) at actions.c:568
20020 #1 0x0804d342 in set_cmode (sender=0x81db058 "ChanServ", channel=0xa905d00)
20023 "balsanelli\000\b\025\225\002BWi??\022B\024\032\023Bi??i??i??i??\000\000\000
20024 \000\034 \006\bi??i??i??i??hi??i??i??i??i??i??i??\025\224\004B\034
20025 \006\b\000\000\000\000i??m\tBdi??\022Bi??q\a\b\000\000\000\000eR :\0037[
20026 \0034#\003di??\022B\000\000\000\000i??\037\006\bi??\037\006\bi??i??i??i??$i?
20027 ?\006Bi??i??i??i??\bi??i??i??\000\000\000\000Hi??i??i??\025\224\004B@\002\a\
20028 b8i??i??i??6\020\aBpi??i??i??@i??\006\b@\002\a\b\000\000\000\000i??<\023BLi?
20029 ?i??i??=S\004B\024\032\023B\001\020\000\000@i??\006\bhi??i??i??\204i??\006Bp
20030 i??i??i??i??\037\006\b"...
20035 args = 0xbfffe6d0 "RDcoCOREcorei??i??i??i??o"
20036 modes = 0xbfffeae2 ""
20037 modes_orig = 0xbfffeae0 "+o"
20038 md = (struct modedata *) 0x806aa00
20043 #2 0x400895ff in local_set_cumodes (c=0xa905d00, plusminus=43 '+', modes=1,
20044 nick=0xab7f2e8 "balsanelli") at check.c:432
20046 modestr = "o\000\000 de outubro em blumenau no rio bravo bar
20047 (proximo a resima agua verde), com as bandas: Zero
20048 L\v\000\000\000(curitiba), \000\000\000\000low the Waff\000\000\000\000bc),
20049 chymia(bnu), crazy frogs (lages), surpise set e slipper (bnu).."...
20051 #3 0x40088d74 in check_chan_user_modes (source=0xbfffeed0 "|-Frango-|",
20052 u=0xab34ff0, c=0xa905d00, oldmodes=1)
20054 user = (User *) 0xab7f2d8
20055 ci = (ChannelInfo *) 0xa571940
20059 #4 0x400820ed in do_channel_umode_change (source=0xbfffeed0 "|-Frango-|",
20060 c=0xa905d00, u=0xab34ff0, oldmodes=1)
20063 #5 0x0805890d in call_callback_5 (module=0x806a5c0, id=23, arg1=0xbfffeed0,
20064 arg2=0xa905d00, arg3=0xab34ff0, arg4=0x1,
20065 arg5=0x0) at modules.c:666
20066 cl = (CallbackList *) 0x8077cb8
20069 #6 0x0804edc8 in do_cumode (source=0xbfffeed0 "|-Frango-|", chan=0xa905d00,
20070 flag=1, add=0, nick=0xbfffecc9 "balsanelli")
20071 ---Type <return> to continue, or q <return> to quit---
20073 u = (struct c_userlist *) 0xab34ff0
20074 user = (User *) 0xab7f2d8
20076 #7 0x0804e97e in do_cmode (source=0xbfffeed0 "|-Frango-|", ac=0,
20077 av=0xa853130) at channels.c:302
20080 params = -1073746288
20081 chan = (Channel *) 0xa905d00
20084 modestr = 0xbfffec9e "-oooooo"
20085 #8 0x080557ff in m_mode (source=0xbfffeed0 "|-Frango-|", ac=8,
20086 av=0xa853110) at messages.c:101
20088 #9 0x0805920e in process () at process.c:133
20089 m = (Message *) 0x8067dd8
20091 "|-Frango-|\000\000G\000\000\000Y\e\205\n\t+\205\n\bi??i??i??i??i??\005\b@j\
20092 a\b\000\004\000\000i??\032\205\n\t\000\000\000@j\a\b\216j\a\b(i??i??i??qP\00
20095 "MODE\000\000\000i??8i??i??i??i??\005\b\000\000\000\000i??i??i??i??\000\000\
20096 000\000\000\000\000\000\001H\000\000Pi??i??i??\000Y\a\bVi??\005\b\207j\a\bP\
20097 e\205\n\t\000\000\000i??i??\005\b"
20099 "MODE\000#EMOCORE\000-oooooo\000CHoPP\000CbRS-oFF\000caroll\000BRYAN\000brun
20100 aH\000balsanelli\000 balsanelli\000\000ai\00314ser \0030]\00315=\00314-
20101 S\00315c\0030ri\00315p\00314t \00315\037v\0373.8 \003\000\00315\037v\0373.8
20102 \003\000\000\0003)\000\0006\037\002Pi??Ti??\00313\037\002]\037\002\0036i??i?
20103 ? \000i??Ti??\00313\037\002]\037\002\0036i??i?? \000\000\003\000\000r
20104 \003", '\0' <repeats 11 times>...
20105 s = 0xbfffec95 "#EMOCORE"
20107 av = (char **) 0xa853110
20108 #10 0x0805507d in readline_callback (s=0xa851ae0, param_unused=0x50) at
20111 #11 0x0805b617 in check_sockets () at sockets.c:491
20112 newline = 0xa851b58 "\nrct-sc.br irc.creativenet.com.br 0 3364349034
20113 :aNiNhHa[du]DoNaTeLo\n:Toh_Pensanu PART #ilheus\n:_LoKo_SuL_ SJOIN
20114 1063565447 #elias\n:_MoRgAnA_ PRIVMSG NickServ@services.redesul.net :set
20115 nomemo off\n:irc."...
20118 rfds = {fds_bits = {16, 0 <repeats 31 times>}}
20119 wfds = {fds_bits = {0 <repeats 32 times>}}
20120 tv = {tv_sec = 2, tv_usec = 980000}
20123 s = (Socket *) 0xa851ae0
20124 s2 = (Socket *) 0x0
20125 #12 0x0805538a in main (ac=3, av=0xbffff164, envp=0xbffff174) at main.c:266
20126 ---Type <return> to continue, or q <return> to quit---
20128 now_msec = 1348441861
20129 last_update = 1066500208
20130 last_check = 1348441182
20131 #13 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
20132 No symbol table info available.
20137 From saturn at jetirc.net Sat Oct 18 12:18:34 2003
20138 From: saturn at jetirc.net (Saturn)
20139 Date: Sat Oct 23 23:09:57 2004
20140 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
20141 References: <3f90afdf.23477@achurch.org>
20142 Message-ID: <003701c395ac$9ff9fd20$6401a8c0@turby>
20144 I thank you for finally just coming out and telling me what I needed to know
20145 in the first place. Had you stated that it has been discussed before (even
20146 without the hyperlinks) I would have at least known to go look through the
20147 archives. However, all you said (then repeated) was RTFM. I DID read it,
20148 once before I asked, and twice more, at your instruction, and found nothing
20149 to answer my questions. Had I known it had already been discussed, I would
20150 certainly have tried to locate the answer that way.
20152 Thank you to all the others who've posted to try and explain what I was
20153 missing in my understanding of this directive. I got it now, and realize
20154 where my misinterpretation was. Seems obvious now, but frankly that
20155 directive managed to fool myself and 8 of my staff into thinking of it as I
20156 have previously described. Regardless, my apologies for any harsh words...
20157 I do stand by the fact that Andrew could have responded with a bit less
20158 apathy to the concerns raised; with something a bit less useless than RTFM
20159 (twice! even AFTER I said I had, THAT'S what pissed me off), and I hope that
20160 maybe Andrew will remember this chain of events for the next time someone
20161 has a problem that might be immediately obvious to Andrew, but not the
20162 person with the problem. I think most of us KNOW by now to read the docs
20163 before asking questions; but if the question arises due to misinterpretation
20164 of the docs, how would reading them over and over help?
20166 Thank you all for your time.
20170 ----- Original Message -----
20171 From: "Andrew Church" <achurch@achurch.org>
20172 To: <ircservices-coding@ircservices.za.net>
20173 Sent: Friday, October 17, 2003 7:57 PM
20174 Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
20177 You know, I might have been more forgiving if this hadn't been gone
20178 over on this list (twice!) before:
20180 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/002305.html
20181 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/003215.html
20183 However, since you seem to have trouble both comprehending the
20184 documentation and reading the archives, I have added FAQ F.10 for your
20187 F.10. Services doesn't kill users matching a newly-added autokill mask even
20188 if ImmediatelySendAutokill is set.
20190 Services never kills users when a new autokill is added; the
20191 ImmediatelySendAutokill configuration directive only causes
20192 Services to send the autokill itself (that is, the user/host mask
20193 to prohibit new connections from) to the IRC servers on your
20194 network. This is a safety feature intended to limit the damage
20195 caused by a mistyped autokill.
20197 Note that some IRC servers will themselves kill users matching a
20198 newly-added autokill; this is unrelated to Services.
20201 achurch@achurch.org
20202 http://achurch.org/
20203 ------------------------------------------------------------------
20204 To unsubscribe or change your subscription options, visit:
20205 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
20208 From diego at redesul.net Sat Oct 18 14:37:31 2003
20209 From: diego at redesul.net (Diego B. Contezini)
20210 Date: Sat Oct 23 23:09:57 2004
20211 Subject: [IRCServices Coding] CORE DUMPED... Debuging
20212 Message-ID: <003f01c395c0$09a31cd0$3cc8a8c0@angel>
20214 If it helps, more lines up.. of debugging...
20217 ChanServ@services.redesul.net :op #manaus paulinhu-dissi-q-mi-ama
20218 [Oct 18 16:05:31.152195 2003] debug: Sent: :ChanServ NOTICE paulinhu-dissi-q-mi-ama :Permission denied.
20219 [Oct 18 16:05:31.152274 2003] debug: Received: :pRiCkLy SJOIN 1066501295 #Euevc
20220 [Oct 18 16:05:31.152353 2003] protocol/bahamut: debug: pRiCkLy SJOINs #Euevc
20221 [Oct 18 16:05:31.152490 2003] debug: Sent: :ChanServ MODE #EUeVC +o pRiCkLy
20222 [Oct 18 16:05:31.269153 2003] debug: Received: :Hellskitty PRIVMSG ChanServ@services.redesul.net :unban #EMOCORE
20223 [Oct 18 16:05:31.269425 2003] debug: Sent: :ChanServ NOTICE Hellskitty :Permission denied.
20224 [Oct 18 16:05:31.288596 2003] debug: Received: :|-Frango-| MODE #EMOCORE +stmipl 1
20225 [Oct 18 16:05:31.288768 2003] debug: Received: :|-Frango-| TOPIC #EMOCORE |-Frango-| 1066460927 :TakeOver by 14,1 -15=0[ 14He15l0lR15ai14ser 0]15=14- S15c0ri15p14t 15v3.8
20226 [Oct 18 16:05:31.288944 2003] debug: Sent: :ChanServ TOPIC #EMOCORE reffer 1066055037 :1??? Festival HARDcoCOREcore dia 25 de outubro em blumenau no rio bravo bar (proximo a resima agua verde), com as bandas: Zero Ltda (curitiba), Swallow the Waffle (bc), chymia(bnu), crazy frogs (lages), surpise set e slipper (bnu)...3 pila entrada inicio as 15:00 horas'
20227 [Oct 18 16:05:31.289032 2003] debug: Received: :|-Frango-| MODE #EMOCORE -oooooo CHoPP CbRS-oFF caroll BRYAN brunaH balsanelli
20228 Segmentation fault (core dumped)
20230 -------------- next part --------------
20231 An HTML attachment was scrubbed...
20232 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20031018/667c67fa/attachment.html
20233 From ballsy at mystical.net Mon Oct 20 08:19:25 2003
20234 From: ballsy at mystical.net (Ballsy)
20235 Date: Sat Oct 23 23:09:57 2004
20236 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
20237 In-Reply-To: <200310182149.18600.v13@it.teithe.gr>
20238 References: <3f9012b8.23176@achurch.org> <030801c3950f$3cb55270$6401a8c0@turby>
20239 <3F90BF77.2010706@t2n.org> <200310182149.18600.v13@it.teithe.gr>
20240 Message-ID: <6.0.0.22.0.20031020091611.01b47318@127.0.0.1>
20242 Yes, Bahamut will immediately kill users matching an Akill. It
20243 won't wait for another client from that host to connect. My setup of IRC
20244 Services 5.0.22 and bahamut-1.4.30 is doing it right now. As alluded to in
20245 a previous email, however, you may need to commented out EnableExclude in
20246 the services config to have this work.
20251 At 12:49 PM 18/10/2003, V13 wrote:
20252 >On Saturday 18 October 2003 07:20, Robert F Merrill wrote:
20254 > > >Would have been nice if someone had mentioned that (about the
20255 > > >ImmediatelySendAutokill) from the start. I would say the flag is
20256 > > > misleading in title then, because I (and 8 other people on my staff --
20257 > > > none of us are dummies, either) read that as meaning it will Immediately
20258 > > > send the auto kill... "ImmediatelyUpdateServers" might be more fitting
20259 > > > from an intuitive standpoint, not that I'm suggesting changing the name,
20260 > > > but at least the documentation of it could be a bit more explicit IMHO.
20262 > > It DOES immediately send the autokill. You just don't grasp the meaning
20263 > > of sending the autokill.
20264 > > It literally sends an AKILL (or TKL in the case of unreal) message to
20265 > > the servers. At least unreal
20266 > > and bahamut will then scan for matching clients and disconnect them,
20267 > > however not all servers
20270 >FYI bahamut doesn't do this. It will only do it whenever a new client that
20271 >matches the akill connects to the server.
20273 >i.e. if you set an akill for *.com noone will be disconnected untill a new
20274 >client from *.com gets connected (at that moment, all matching clients will
20275 >be killed). In the mean time, anyone from other domains can connect to the
20276 >server without having any user killed.
20279 >------------------------------------------------------------------
20280 >To unsubscribe or change your subscription options, visit:
20281 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
20285 From oska at mynet.com Tue Oct 21 22:25:25 2003
20286 From: oska at mynet.com (oska)
20287 Date: Sat Oct 23 23:09:57 2004
20288 Subject: [IRCServices Coding] "Re: Contents of IRCServices-Coding digest..."
20289 Message-ID: <HN58ED$I890Q9pEOh0UN3QcHkNkg1Bm2fHspFZq@mynet.com>
20291 An HTML attachment was scrubbed...
20292 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20031022/9c540c11/attachment.htm
20293 From laser at musichat.net Fri Oct 24 10:36:30 2003
20294 From: laser at musichat.net (laser@musichat.net)
20295 Date: Sat Oct 23 23:09:57 2004
20296 Subject: [IRCServices Coding] Il momento e' catartico
20297 Message-ID: <20031024173545.9ACA817038@snow.fingers.co.za>
20299 Ricevo e cortesemente inoltro,.... un premio per la genialit?
20300 hanno reso mitico un salva schermo scaricalo, "poesie catartiche", che non sai cosa ti perdi
20303 -------------- next part --------------
20304 An HTML attachment was scrubbed...
20305 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20031024/97501fa5/attachment.html
20306 From diego at redesul.net Fri Oct 24 17:02:47 2003
20307 From: diego at redesul.net (Diego B. Contezini)
20308 Date: Sat Oct 23 23:09:57 2004
20309 Subject: [IRCServices Coding] CORE DUMPED! BUG!
20310 References: <3f8f9304.20227@achurch.org> <000e01c395ac$5b773b40$3cc8a8c0@angel>
20311 Message-ID: <012e01c39a8b$531829d0$3cc8a8c0@angel>
20313 Andrew, have anything more of dumping/debugging that i can do/give for helps
20315 (if it helps, here its rh9.0, libc 2.3.2, linux x86, kernel 2.4.20-8,
20316 Pentium III 1ghz 512mb ram DDR)....
20326 From andrew at wtfigo.co.uk Tue Nov 4 02:15:03 2003
20327 From: andrew at wtfigo.co.uk (Andrew Kempe)
20328 Date: Sat Oct 23 23:09:57 2004
20329 Subject: [IRCServices Coding] test
20330 Message-ID: <E1AGyDD-0001mX-00@smtp.mailbox.co.uk>
20334 From diego at redesul.net Tue Nov 4 16:43:45 2003
20335 From: diego at redesul.net (Diego B. Contezini)
20336 Date: Sat Oct 23 23:09:57 2004
20337 Subject: [IRCServices Coding] CORE DUMPED! BUG!
20338 Message-ID: <014f01c3a335$e1e08dd0$3cc8a8c0@angel>
20340 I found a bug (occuring on the old-last vesion of ircservices -
20341 ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
20343 yes, 5.0.23 is the last.. but nothing has changed about the bug...
20345 here is the debugging:
20347 ChanServ@services.redesul.net :op #manaus paulinhu-dissi-q-mi-ama
20348 [Oct 18 16:05:31.152195 2003] debug: Sent: :ChanServ NOTICE
20349 paulinhu-dissi-q-mi-ama :Permission denied.
20350 [Oct 18 16:05:31.152274 2003] debug: Received: :pRiCkLy SJOIN 1066501295
20352 [Oct 18 16:05:31.152353 2003] protocol/bahamut: debug: pRiCkLy SJOINs #Euevc
20353 [Oct 18 16:05:31.152490 2003] debug: Sent: :ChanServ MODE #EUeVC +o pRiCkLy
20354 [Oct 18 16:05:31.269153 2003] debug: Received: :Hellskitty PRIVMSG
20355 ChanServ@services.redesul.net :unban #EMOCORE
20356 [Oct 18 16:05:31.269425 2003] debug: Sent: :ChanServ NOTICE Hellskitty
20357 :Permission denied.
20358 [Oct 18 16:05:31.288596 2003] debug: Received: :|-Frango-| MODE #EMOCORE
20360 [Oct 18 16:05:31.288768 2003] debug: Received: :|-Frango-| TOPIC #EMOCORE
20361 |-Frango-| 1066460927 :TakeOver by 14,1 -15=0[ 14He15l0lR15ai14ser 0]15=14-
20362 S15c0ri15p14t 15v3.8
20363 [Oct 18 16:05:31.288944 2003] debug: Sent: :ChanServ TOPIC #EMOCORE reffer
20364 1066055037 :1i?? Festival HARDcoCOREcore dia 25 de outubro em blumenau no
20365 rio bravo bar (proximo a resima agua verde), com as bandas: Zero Ltda
20366 (curitiba), Swallow the Waffle (bc), chymia(bnu), crazy frogs (lages),
20367 surpise set e slipper (bnu)...3 pila entrada inicio as 15:00 horas'
20368 [Oct 18 16:05:31.289032 2003] debug: Received: :|-Frango-| MODE
20369 #EMOCORE -oooooo CHoPP CbRS-oFF caroll BRYAN brunaH balsanelli
20370 Segmentation fault (core dumped)
20373 Debugging my core... i can found:
20374 #0 0x0804d830 in add_mode_with_params (md=0x806aa00, mode=111 'o',
20375 is_add=1, params=1, parambuf=0xbfffe280 "balsanelli",
20376 len=10) at actions.c:568
20377 568 md->params[md->nopmodes][len] = 0;
20379 #0 0x0804d830 in add_mode_with_params (md=0x806aa00, mode=111 'o',
20380 is_add=1, params=1, parambuf=0xbfffe280 "balsanelli",
20381 len=10) at actions.c:568
20383 #1 0x0804d342 in set_cmode (sender=0x81db058 "ChanServ", channel=0xa905d00)
20386 "balsanelli\000\b\025\225\002BWi??\022B\024\032\023Bi??i??i??i??\000\000\000
20387 \000\034 \006\bi??i??i??i??hi??i??i??i??i??i??i??\025\224\004B\034
20388 \006\b\000\000\000\000i??m\tBdi??\022Bi??q\a\b\000\000\000\000eR :\0037[
20389 \0034#\003di??\022B\000\000\000\000i??\037\006\bi??\037\006\bi??i??i??i??$i?
20390 ?\006Bi??i??i??i??\bi??i??i??\000\000\000\000Hi??i??i??\025\224\004B@\002\a\
20391 b8i??i??i??6\020\aBpi??i??i??@i??\006\b@\002\a\b\000\000\000\000i??<\023BLi?
20392 ?i??i??=S\004B\024\032\023B\001\020\000\000@i??\006\bhi??i??i??\204i??\006Bp
20393 i??i??i??i??\037\006\b"...
20398 args = 0xbfffe6d0 "RDcoCOREcorei??i??i??i??o"
20399 modes = 0xbfffeae2 ""
20400 modes_orig = 0xbfffeae0 "+o"
20401 md = (struct modedata *) 0x806aa00
20406 #2 0x400895ff in local_set_cumodes (c=0xa905d00, plusminus=43 '+', modes=1,
20407 nick=0xab7f2e8 "balsanelli") at check.c:432
20409 modestr = "o\000\000 de outubro em blumenau no rio bravo bar
20410 (proximo a resima agua verde), com as bandas: Zero
20411 L\v\000\000\000(curitiba), \000\000\000\000low the Waff\000\000\000\000bc),
20412 chymia(bnu), crazy frogs (lages), surpise set e slipper (bnu).."...
20414 #3 0x40088d74 in check_chan_user_modes (source=0xbfffeed0 "|-Frango-|",
20415 u=0xab34ff0, c=0xa905d00, oldmodes=1)
20417 user = (User *) 0xab7f2d8
20418 ci = (ChannelInfo *) 0xa571940
20422 #4 0x400820ed in do_channel_umode_change (source=0xbfffeed0 "|-Frango-|",
20423 c=0xa905d00, u=0xab34ff0, oldmodes=1)
20426 #5 0x0805890d in call_callback_5 (module=0x806a5c0, id=23, arg1=0xbfffeed0,
20427 arg2=0xa905d00, arg3=0xab34ff0, arg4=0x1,
20428 arg5=0x0) at modules.c:666
20429 cl = (CallbackList *) 0x8077cb8
20432 #6 0x0804edc8 in do_cumode (source=0xbfffeed0 "|-Frango-|", chan=0xa905d00,
20433 flag=1, add=0, nick=0xbfffecc9 "balsanelli")
20434 ---Type <return> to continue, or q <return> to quit---
20436 u = (struct c_userlist *) 0xab34ff0
20437 user = (User *) 0xab7f2d8
20439 #7 0x0804e97e in do_cmode (source=0xbfffeed0 "|-Frango-|", ac=0,
20440 av=0xa853130) at channels.c:302
20443 params = -1073746288
20444 chan = (Channel *) 0xa905d00
20447 modestr = 0xbfffec9e "-oooooo"
20448 #8 0x080557ff in m_mode (source=0xbfffeed0 "|-Frango-|", ac=8,
20449 av=0xa853110) at messages.c:101
20451 #9 0x0805920e in process () at process.c:133
20452 m = (Message *) 0x8067dd8
20454 "|-Frango-|\000\000G\000\000\000Y\e\205\n\t+\205\n\bi??i??i??i??i??\005\b@j\
20455 a\b\000\004\000\000i??\032\205\n\t\000\000\000@j\a\b\216j\a\b(i??i??i??qP\00
20458 "MODE\000\000\000i??8i??i??i??i??\005\b\000\000\000\000i??i??i??i??\000\000\
20459 000\000\000\000\000\000\001H\000\000Pi??i??i??\000Y\a\bVi??\005\b\207j\a\bP\
20460 e\205\n\t\000\000\000i??i??\005\b"
20462 "MODE\000#EMOCORE\000-oooooo\000CHoPP\000CbRS-oFF\000caroll\000BRYAN\000brun
20463 aH\000balsanelli\000 balsanelli\000\000ai\00314ser \0030]\00315=\00314-
20464 S\00315c\0030ri\00315p\00314t \00315\037v\0373.8 \003\000\00315\037v\0373.8
20465 \003\000\000\0003)\000\0006\037\002Pi??Ti??\00313\037\002]\037\002\0036i??i?
20466 ? \000i??Ti??\00313\037\002]\037\002\0036i??i?? \000\000\003\000\000r
20467 \003", '\0' <repeats 11 times>...
20468 s = 0xbfffec95 "#EMOCORE"
20470 av = (char **) 0xa853110
20471 #10 0x0805507d in readline_callback (s=0xa851ae0, param_unused=0x50) at
20474 #11 0x0805b617 in check_sockets () at sockets.c:491
20475 newline = 0xa851b58 "\nrct-sc.br irc.creativenet.com.br 0 3364349034
20476 :aNiNhHa[du]DoNaTeLo\n:Toh_Pensanu PART #ilheus\n:_LoKo_SuL_ SJOIN
20477 1063565447 #elias\n:_MoRgAnA_ PRIVMSG NickServ@services.redesul.net :set
20478 nomemo off\n:irc."...
20481 rfds = {fds_bits = {16, 0 <repeats 31 times>}}
20482 wfds = {fds_bits = {0 <repeats 32 times>}}
20483 tv = {tv_sec = 2, tv_usec = 980000}
20486 s = (Socket *) 0xa851ae0
20487 s2 = (Socket *) 0x0
20488 #12 0x0805538a in main (ac=3, av=0xbffff164, envp=0xbffff174) at main.c:266
20489 ---Type <return> to continue, or q <return> to quit---
20491 now_msec = 1348441861
20492 last_update = 1066500208
20493 last_check = 1348441182
20494 #13 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
20495 No symbol table info available.
20496 (gdb) info registers
20497 eax 0xd6b2bf8a -692928630
20498 ecx 0x806aa00 134654464
20499 edx 0x656e6173 1701732723
20500 ebx 0x42131a14 1108548116
20501 esp 0xbfffd910 0xbfffd910
20502 ebp 0xbfffe238 0xbfffe238
20503 esi 0x8075900 134699264
20504 edi 0xbffff050 -1073745840
20505 eip 0x804d830 0x804d830
20506 eflags 0x10282 66178
20516 root@irc(/home/ircadmin/services/lib)# ls -la core.12631
20517 -rw------- 1 ircadmin ircadmin 47374336 Oct 18 16:05 core.12631
20518 root@irc(/home/ircadmin/services)# ldd ircservices
20519 libdl.so.2 => /lib/libdl.so.2 (0x4001e000)
20520 libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
20521 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
20522 root@irc(/home/ircadmin/services)# uname -a
20523 Linux XXXXXX.xyz.0xdeadbeef 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686
20524 i686 i386 GNU/Linux
20525 root@irc(/home/ircadmin/services)# cat /etc/redhat-release
20526 Red Hat Linux release 9 (Shrike)
20527 root@irc(/home/ircadmin/services)# cat /proc/cpuinfo
20529 model name : Pentium III (Coppermine)
20532 cache size : 256 KB
20534 root@irc(/home/ircadmin/services)# free
20535 total used free shared buffers cached
20536 Mem: 513792 482248 31544 0 69492 274980
20538 I changed version of linux, runned it on 3 different machines, on
20539 slackware/redhat, pentiumIII, K5, P200.
20540 This bug is as older as i run services... dont know if its the same of the
20541 4.X (that i changed to 5.X to "solve" this bug), but from 5.12 to now, it
20542 continue happening... aways...
20543 Dont have a exactly time to happen, its insane... i think that its a
20544 coincidence of some commands that on the memory ends fucking some variable.
20545 if you want look the incidence, here its:
20546 root@irc(/home/ircadmin/services/lib)# ls -la core*
20548 -rw------- 1 ircadmin ircadmin 49025024 Oct 5 19:32 core.27214
20549 -rw------- 1 ircadmin ircadmin 45932544 Oct 5 21:01 core.14414
20550 -rw------- 1 ircadmin ircadmin 46948352 Oct 6 14:00 core.18016
20551 -rw------- 1 ircadmin ircadmin 45936640 Oct 11 04:30 core.1347
20552 -rw------- 1 ircadmin ircadmin 50479104 Oct 14 01:29 core.16481
20553 -rw------- 1 ircadmin ircadmin 44982272 Oct 15 13:54 core.22332
20554 -rw------- 1 ircadmin ircadmin 47374336 Oct 18 16:05 core.12631
20555 -rw------- 1 ircadmin ircadmin 48099328 Oct 19 14:16 core.5362
20556 -rw------- 1 ircadmin ircadmin 44863488 Oct 19 14:22 core.32708
20557 -rw------- 1 ircadmin ircadmin 45355008 Nov 1 15:13 core.28309
20558 -rw------- 1 ircadmin ircadmin 50360320 Nov 3 18:24 core.5160
20561 If it helps, here is the debugging of the last two cores, on gdb:
20564 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
20569 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
20572 chan = (Channel *) 0xa87d1e0
20573 s = 0x1f73746f <Address 0x1f73746f out of bounds>
20575 modestr = 0x1f73746f <Address 0x1f73746f out of bounds>
20576 #1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:680
20577 buf = "-imsl\000HA___\000\000\000\000\000W
20578 \022B\000\000\000L\000\000\000\000\000y\000nossaTZ\000\000\000\000\000\000yy
20579 yyA<\023B\001\000\000\000\bYy?Om\tBd
20580 \022BDq\a\bOUy?NO\006B\210o\a\b3\035\rB\024\032\023BAa\006B\003\000\000\000a
20581 Yy?\027\000\000\000\024\032\023B\024\032\023BTZ\000\000\004\000\000\000\005\
20582 000\000\000\210o\a\baYy?\030Yy?NO\006B\210o\a\baYy?\027\000\000\000$u\006B\2
20583 10o\a\bIo\a\b\vO\006B\024\032\023B\024\032\023B@\002\a\bHYy?$u\006B\200Yy?@o
20585 s = 0xbfffdc60 "-imsl"
20586 argv = {0xa87d1e8 "#soad",
20587 0x1f73746f <Address 0x1f73746f out of bounds>,
20588 0x5303200f <Address 0x5303200f out of bounds>,
20589 0x6c6c6568 <Address 0x6c6c6568 out of bounds>,
20590 0x4323203a <Address 0x4323203a out of bounds>,
20591 0x65746e65 <Address 0x65746e65 out of bounds>,
20592 0x65685372 <Address 0x65685372 out of bounds>,
20593 0x52426c6c <Address 0x52426c6c out of bounds>}
20595 ---Type <return> to continue, or q <return> to quit---
20598 #2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
20602 md = (struct modedata *) 0x0
20607 #3 0x080553a3 in main (ac=1, av=0xbfffe574, envp=0xbfffe57c) at main.c:269
20609 now_msec = -1555790286
20610 last_update = 1067890538
20611 last_check = 2739174210
20612 #4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
20613 No symbol table info available.
20617 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
20622 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
20625 chan = (Channel *) 0xa9be840
20626 s = 0xbf000000 <Address 0xbf000000 out of bounds>
20628 modestr = 0xbf000000 <Address 0xbf000000 out of bounds>
20629 #1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:680
20630 buf = "-imsl\000\a\b\000len\000\000\000\000W
20631 \022B3\035\rB\024\032\023BAa\006B\003\000\000\000
20632 oy?\027\000\000\000yyyyA<\023BTZ\000\000\004\000\000\000\005\000\000\000\210
20633 o\a\b oy?Xoy?NO\006B\210o\a\b
20634 oy?\027\000\000\000$u\006B\210o\a\bIo\a\b\vO\006B\024\032\023B\024\032\023B@
20635 \002\a\b\210oy?$u\006BAoy?@o\006\b@\002\a\b\000\000\000\000\024\032\023B@\00
20636 2\a\b?oy?6\020\aBaoy?@o\006\b@\002\a\b\000\000\000\000Aoy?I\037\006\b=S\004B
20637 \024\032\023B\001\020\000\000@o\006\b"...
20638 s = 0xbffff2e0 "-imsl"
20639 argv = {0xa9be848 "#zoera",
20640 0xbf000000 <Address 0xbf000000 out of bounds>, 0x0,
20641 0x806f240 "ircservices.log", 0x806f240 "ircservices.log",
20642 0x5a54 <Address 0x5a54 out of bounds>, 0x0,
20643 0xffffffff <Address 0xffffffff out of bounds>}
20647 #2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
20648 ---Type <return> to continue, or q <return> to quit---
20652 md = (struct modedata *) 0x0
20657 #3 0x080553a3 in main (ac=1, av=0xbffffbf4, envp=0xbffffbfc) at main.c:269
20659 now_msec = -1740061222
20660 last_update = 1067706282
20661 last_check = 2554904000
20662 #4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
20663 No symbol table info available.
20666 Im running it more a time on Screen to can get exactly where occur the bug
20667 (with -nofork -debug), to look for more examples of commands that causes
20669 if have something (more) that i can to add/do to helps on debugging, please,
20670 tell me.. i have the core (i cant send it, for secure reasons... have all my
20671 db on the core... ), but im open to helps anytime anywhere... with
20674 Thanks for all development, this is really a bealtifull software...
20675 (and sorry for my bad english)
20677 Diego B. Contezini aka destruct_ #irc.redesul.net
20681 From diego at redesul.net Tue Nov 4 16:46:53 2003
20682 From: diego at redesul.net (Diego B. Contezini)
20683 Date: Sat Oct 23 23:09:57 2004
20684 Subject: [IRCServices Coding] about.. CORE DUMPED! BUG!
20685 Message-ID: <01fa01c3a336$4e884220$3cc8a8c0@angel>
20687 If it helps, im using Bahamut here....
20690 From achurch at achurch.org Wed Nov 5 13:20:15 2003
20691 From: achurch at achurch.org (Andrew Church)
20692 Date: Sat Oct 23 23:09:57 2004
20693 Subject: [IRCServices Coding] Bug or misunderstood ?
20694 In-Reply-To: <000901c39496$71764f10$a37faec3@coder>
20695 Message-ID: <3fa87c99.57222@achurch.org>
20697 >Im using unreal ircd. When channel is empty and if channel owner joins
20698 >his/her registered channel it does
20699 >(ChanServ sets mode: +ntrq nick) but when channel is not empty and if
20700 >channel owner joins his/her registered channel it does (ChanServ sets mode:
20701 >+oq nick nick). As you see on the first one there is no +o and because of
20702 >this chanserv does not update the last_used time because chanserv is set to
20703 >update last_used time with +o (CUMODE_o) so channels drop while channel
20704 >owners use them. Is this a bug or my misunderstood ?
20706 This is a bug; I've fixed it for the next release, thanks for the
20707 report. As regards your other message, not setting the last-used time for
20708 +a/+q users is designed behavior (see section 3-2-1 of the manual: "`used'
20709 means that a user with auto-op privileges ... has entered the channel"), as
20710 well as unnecessary in typical channel settings (where +a users are a
20711 subset of +o users), but if you have any better suggestions on how to
20712 determine when a channel is being used by proper users as opposed to (for
20713 example) spammers or people just entering to see if the channel is
20714 available, I'm willing to listen.
20717 achurch@achurch.org
20718 http://achurch.org/
20720 From andrewk at isdial.net Tue Aug 26 02:43:45 2003
20721 From: andrewk at isdial.net (Andrew Kempe)
20722 Date: Sat Oct 23 23:09:57 2004
20723 Subject: [IRCServices Coding] test
20724 Message-ID: <005801c36bb6$85bbc080$1f0912ac@espotting.com>
20728 From us44ever at hotmail.com Thu Aug 28 09:45:48 2003
20729 From: us44ever at hotmail.com (us44ever .)
20730 Date: Sat Oct 23 23:09:57 2004
20731 Subject: [IRCServices Coding] Yet, another great suggestion
20732 Message-ID: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
20736 it would be really great to add another new line to the "/nickserv info"
20737 command, for example, when some one types: "/nickserv info nick", the
20738 following will be shown:
20740 ***************************
20742 -NickServ- nick is hello world
20744 -NickServ- Is online from: ~test@just.a.test.co.za
20746 -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
20748 -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
20750 -NickServ- Last quit message: anythinggggg
20752 -NickServ- Options: Kill protection, Security
20754 ***************************
20756 the new line I'm suggesting is something like:
20758 ***************************
20759 -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
20760 ***************************
20762 This will help our users to compare the time that user was last seen and the
20763 time right now *it's very important, many many of our users asked us for
20764 this option*, also it would even be more great to show how long last time
20765 the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003 GMT
20766 (last seen time was before: 10 days, 3hours and 24 sec ago).
20768 Note that I saw both of these features, in other services I don't remember
20769 there names (but they aren't as stable as ircservices5) (it was something
20770 like ptlink services, and magik II)
20772 That's all, I would really like to see it on the next version (or if you can
20773 show me how to do it, as I'm not a programmer)
20775 Many thanks to all of who developed IRCservices ...etc ...etc ...etc
20780 _________________________________________________________________
20781 Get MSN 8 and enjoy automatic e-mail virus protection.
20782 http://join.msn.com/?page=features/virus
20785 From aragon at phat.za.net Thu Aug 28 11:36:22 2003
20786 From: aragon at phat.za.net (Aragon Gouveia)
20787 Date: Sat Oct 23 23:09:57 2004
20788 Subject: [IRCServices Coding] Yet, another great suggestion
20789 In-Reply-To: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
20790 References: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
20791 Message-ID: <20030828183615.GB32204@phat.za.net>
20793 Or how about rather letting users decide what timezone they're in and
20794 services outputs all timestamps in their local time?
20797 | By us44ever . <us44ever@hotmail.com>
20798 | [ 2003-08-28 18:45 +0200 ]
20801 > it would be really great to add another new line to the "/nickserv info"
20802 > command, for example, when some one types: "/nickserv info nick", the
20803 > following will be shown:
20805 > ***************************
20807 > -NickServ- nick is hello world
20809 > -NickServ- Is online from: ~test@just.a.test.co.za
20811 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
20813 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
20815 > -NickServ- Last quit message: anythinggggg
20817 > -NickServ- Options: Kill protection, Security
20819 > ***************************
20821 > the new line I'm suggesting is something like:
20823 > ***************************
20824 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
20825 > ***************************
20827 > This will help our users to compare the time that user was last seen and
20828 > the time right now *it's very important, many many of our users asked us
20829 > for this option*, also it would even be more great to show how long last
20830 > time the user was seen (some thing like: Last seen time: Aug 28 15:51:14
20831 > 2003 GMT (last seen time was before: 10 days, 3hours and 24 sec ago).
20833 > Note that I saw both of these features, in other services I don't remember
20834 > there names (but they aren't as stable as ircservices5) (it was something
20835 > like ptlink services, and magik II)
20837 > That's all, I would really like to see it on the next version (or if you
20838 > can show me how to do it, as I'm not a programmer)
20840 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
20845 > _________________________________________________________________
20846 > Get MSN 8 and enjoy automatic e-mail virus protection.
20847 > http://join.msn.com/?page=features/virus
20849 > ------------------------------------------------------------------
20850 > To unsubscribe or change your subscription options, visit:
20851 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
20853 From saturn at jetirc.net Thu Aug 28 11:39:41 2003
20854 From: saturn at jetirc.net (Saturn)
20855 Date: Sat Oct 23 23:09:57 2004
20856 Subject: [IRCServices Coding] Yet, another great suggestion
20857 References: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
20858 <20030828183615.GB32204@phat.za.net>
20859 Message-ID: <003201c36d93$abf77fd0$6401a8c0@turby>
20861 Oooo now I like that option... have it default to a default timezone, set in
20862 the conf file, and give them the option of SETting a different UTC code
20863 (have it as GMT + or - x wheer x is the offset from UTC)... It may not
20864 sound liek much, but I bet people will use it, and what's more, it IS useful
20865 information, especially on international servers like mine.. we have people
20866 from all over the place, and we keep services set on Pacific time... but for
20867 those in, say, Belgium... that's not very helpful
20869 ----- Original Message -----
20870 From: "Aragon Gouveia" <aragon@phat.za.net>
20871 To: <ircservices-coding@ircservices.za.net>
20872 Sent: Thursday, August 28, 2003 11:36 AM
20873 Subject: Re: [IRCServices Coding] Yet, another great suggestion
20876 Or how about rather letting users decide what timezone they're in and
20877 services outputs all timestamps in their local time?
20880 | By us44ever . <us44ever@hotmail.com>
20881 | [ 2003-08-28 18:45 +0200 ]
20884 > it would be really great to add another new line to the "/nickserv info"
20885 > command, for example, when some one types: "/nickserv info nick", the
20886 > following will be shown:
20888 > ***************************
20890 > -NickServ- nick is hello world
20892 > -NickServ- Is online from: ~test@just.a.test.co.za
20894 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
20896 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
20898 > -NickServ- Last quit message: anythinggggg
20900 > -NickServ- Options: Kill protection, Security
20902 > ***************************
20904 > the new line I'm suggesting is something like:
20906 > ***************************
20907 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
20908 > ***************************
20910 > This will help our users to compare the time that user was last seen and
20911 > the time right now *it's very important, many many of our users asked us
20912 > for this option*, also it would even be more great to show how long last
20913 > time the user was seen (some thing like: Last seen time: Aug 28 15:51:14
20914 > 2003 GMT (last seen time was before: 10 days, 3hours and 24 sec ago).
20916 > Note that I saw both of these features, in other services I don't remember
20917 > there names (but they aren't as stable as ircservices5) (it was something
20918 > like ptlink services, and magik II)
20920 > That's all, I would really like to see it on the next version (or if you
20921 > can show me how to do it, as I'm not a programmer)
20923 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
20928 > _________________________________________________________________
20929 > Get MSN 8 and enjoy automatic e-mail virus protection.
20930 > http://join.msn.com/?page=features/virus
20932 > ------------------------------------------------------------------
20933 > To unsubscribe or change your subscription options, visit:
20934 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
20935 ------------------------------------------------------------------
20936 To unsubscribe or change your subscription options, visit:
20937 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
20941 From Craig at chatspike.net Thu Aug 28 14:29:54 2003
20942 From: Craig at chatspike.net (Craig McLure)
20943 Date: Sat Oct 23 23:09:57 2004
20944 Subject: [IRCServices Coding] Yet, another great suggestion
20945 Message-ID: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
20947 Please dont post to both the services main list, and the services coding list. Choose one, or the other, especially concidering i dont think this is a great suggestion either..
20949 /time services.chatspike.net
20950 [22:28]
\95\95\95 Date / time at services.chatspike.net- Thu Aug 28 17:28:57 2003 EDT
20954 /****************************************
20955 * Craig "FrostyCoolSlug" McLure
20956 ************* - SpamBox - **************
20957 * InspIRCd - http://www.inspircd.org
20958 * ChatSpike - http://www.chatspike.net
20959 * WinBot - http://www.winbot.co.uk
20960 ****************************************/
20962 /****************************************
20963 * From - us44ever . <us44ever@hotmail.com>
20964 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
20965 * Sent - 2003-08-28 @ 16:45:00
20966 * Subject - [IRCServices Coding] Yet, another great suggestion
20967 ****************************************/
20969 /****** - Begin Original Message - ******/
20973 >it would be really great to add another new line to the "/nickserv info"
20974 >command, for example, when some one types: "/nickserv info nick", the
20975 >following will be shown:
20977 >***************************
20979 >-NickServ- nick is hello world
20981 >-NickServ- Is online from: ~test@just.a.test.co.za
20983 >-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
20985 >-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
20987 >-NickServ- Last quit message: anythinggggg
20989 >-NickServ- Options: Kill protection, Security
20991 >***************************
20993 >the new line I'm suggesting is something like:
20995 >***************************
20996 >-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
20997 >***************************
20999 >This will help our users to compare the time that user was last seen and the
21000 >time right now *it's very important, many many of our users asked us for
21001 >this option*, also it would even be more great to show how long last time
21002 >the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003 GMT
21003 >(last seen time was before: 10 days, 3hours and 24 sec ago).
21005 >Note that I saw both of these features, in other services I don't remember
21006 >there names (but they aren't as stable as ircservices5) (it was something
21007 >like ptlink services, and magik II)
21009 >That's all, I would really like to see it on the next version (or if you can
21010 >show me how to do it, as I'm not a programmer)
21012 >Many thanks to all of who developed IRCservices ...etc ...etc ...etc
21017 >_________________________________________________________________
21018 >Get MSN 8 and enjoy automatic e-mail virus protection.
21019 >http://join.msn.com/?page=features/virus
21021 >------------------------------------------------------------------
21022 >To unsubscribe or change your subscription options, visit:
21023 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
21025 /******* - End Original Message - *******/
21030 From nothing at psychopat.org Thu Aug 28 14:57:31 2003
21031 From: nothing at psychopat.org (Marc-Andre A. Fuentes)
21032 Date: Sat Oct 23 23:09:57 2004
21033 Subject: [IRCServices Coding] BUG Report
21034 Message-ID: <001501c36daf$c8cba700$0101a8c0@house>
21036 We're having a small problem with suspended channel.
21038 we suspended channel #kavala, and someone has identified itself has the founder and apply a DROP to the channel.
21039 then we got a panic from the services and... crash.
21041 Also with suspended nick , when the suspencion expire, the services crash
21044 ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
21049 -------------- next part --------------
21050 An HTML attachment was scrubbed...
21051 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030828/1f31ccf5/attachment.htm
21052 From Craig at chatspike.net Thu Aug 28 15:24:36 2003
21053 From: Craig at chatspike.net (Craig McLure)
21054 Date: Sat Oct 23 23:09:57 2004
21055 Subject: [IRCServices Coding] BUG Report
21056 Message-ID: <20030828222401.JVQE12036.mta4-svc.business.ntl.com@i-br0ked-it>
21058 hmm.. what OS, compiler version etc are you using?
21060 after a test, i got the following:
21062 /cs id #abc 00376370
21063 -ChanServ- Channel #abc is suspended and may not be used or identified for.
21066 [23:20] -ChanServ- Channel is suspended and may not be used or identified for.
21068 only prob i got was it missed the channel name in the second message :)
21071 /****************************************
21072 * Craig "FrostyCoolSlug" McLure
21073 ************* - SpamBox - **************
21074 * InspIRCd - http://www.inspircd.org
21075 * ChatSpike - http://www.chatspike.net
21076 * WinBot - http://www.winbot.co.uk
21077 ****************************************/
21079 /****************************************
21080 * From - Marc-Andre A. Fuentes <nothing@psychopat.org>
21081 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
21082 * Sent - 2003-08-28 @ 18:00:00
21083 * Subject - [IRCServices Coding] BUG Report
21084 ****************************************/
21086 /****** - Begin Original Message - ******/
21088 >We're having a small problem with suspended channel.
21090 >we suspended channel #kavala, and someone has identified itself has the founder and apply a DROP to the channel.
21091 >then we got a panic from the services and... crash.
21093 >Also with suspended nick , when the suspencion expire, the services crash
21096 >ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
21101 >------------------------------------------------------------------
21102 >To unsubscribe or change your subscription options, visit:
21103 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
21105 /******* - End Original Message - *******/
21110 From saturn at jetirc.net Thu Aug 28 17:13:48 2003
21111 From: saturn at jetirc.net (Saturn)
21112 Date: Sat Oct 23 23:09:57 2004
21113 Subject: [IRCServices Coding] AKill suggestion
21114 References: <2C31F186-CDEE-11D7-979C-0003938D6866@mac.com>
21115 Message-ID: <009001c36dc2$64b56b80$6401a8c0@turby>
21117 Would it be possible to have it announce to the user when they are akilled,
21118 either the expiry date and time, or "Expires in 3days, 4hours, 6minutes" or
21119 something similar. I find that usually we just have to do 24hour bans, but
21120 the user has no way to know when the ban was set, and when it expires...
21122 Just an idea... I now await the half dozen people who will proceed to tell
21123 me how stupid my idea is....
21130 From playa at dreamchat.org Thu Aug 28 20:46:19 2003
21131 From: playa at dreamchat.org (playa)
21132 Date: Sat Oct 23 23:09:57 2004
21133 Subject: [IRCServices Coding] Yet, another great suggestion
21134 In-Reply-To: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
21135 References: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
21136 Message-ID: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
21138 Is this /time command only supposed to work via RAW? Cause when i type
21139 /time services.dreamchat.org i get No Such User, but if i do /raw time
21140 services.dreamchat.org, it works. Just wondering if its just me, or if
21141 its supposed to be that way.
21143 > Please dont post to both the services main list, and the services coding
21144 > list. Choose one, or the other, especially concidering i dont think this
21145 > is a great suggestion either..
21147 > /time services.chatspike.net
21148 > [22:28] ??? Date / time at services.chatspike.net- Thu Aug 28 17:28:57
21153 > /****************************************
21154 > * Craig "FrostyCoolSlug" McLure
21155 > ************* - SpamBox - **************
21156 > * InspIRCd - http://www.inspircd.org
21157 > * ChatSpike - http://www.chatspike.net
21158 > * WinBot - http://www.winbot.co.uk
21159 > ****************************************/
21161 > /****************************************
21162 > * From - us44ever . <us44ever@hotmail.com>
21163 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
21164 > * Sent - 2003-08-28 @ 16:45:00
21165 > * Subject - [IRCServices Coding] Yet, another great suggestion
21166 > ****************************************/
21168 > /****** - Begin Original Message - ******/
21172 >>it would be really great to add another new line to the "/nickserv info"
21173 >>command, for example, when some one types: "/nickserv info nick", the
21174 >>following will be shown:
21176 >>***************************
21178 >>-NickServ- nick is hello world
21180 >>-NickServ- Is online from: ~test@just.a.test.co.za
21182 >>-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
21184 >>-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
21186 >>-NickServ- Last quit message: anythinggggg
21188 >>-NickServ- Options: Kill protection, Security
21190 >>***************************
21192 >>the new line I'm suggesting is something like:
21194 >>***************************
21195 >>-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
21196 >>***************************
21198 >>This will help our users to compare the time that user was last seen and
21200 >>time right now *it's very important, many many of our users asked us for
21201 >>this option*, also it would even be more great to show how long last time
21202 >>the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003
21204 >>(last seen time was before: 10 days, 3hours and 24 sec ago).
21206 >>Note that I saw both of these features, in other services I don't
21208 >>there names (but they aren't as stable as ircservices5) (it was something
21209 >>like ptlink services, and magik II)
21211 >>That's all, I would really like to see it on the next version (or if you
21213 >>show me how to do it, as I'm not a programmer)
21215 >>Many thanks to all of who developed IRCservices ...etc ...etc ...etc
21220 >>_________________________________________________________________
21221 >>Get MSN 8 and enjoy automatic e-mail virus protection.
21222 >>http://join.msn.com/?page=features/virus
21224 >>------------------------------------------------------------------
21225 >>To unsubscribe or change your subscription options, visit:
21226 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
21228 > /******* - End Original Message - *******/
21232 > ------------------------------------------------------------------
21233 > To unsubscribe or change your subscription options, visit:
21234 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
21241 Network Founder/CEO
21242 DreamChat IRC Network - irc.dreamchat.org
21243 http://www.dreamchat.org
21246 From quension at mac.com Thu Aug 28 21:13:48 2003
21247 From: quension at mac.com (Trevor Talbot)
21248 Date: Sat Oct 23 23:09:57 2004
21249 Subject: [IRCServices Coding] Yet, another great suggestion
21250 In-Reply-To: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
21251 Message-ID: <0F823090-D9D7-11D7-8513-0003938D6866@mac.com>
21253 On Thursday, Aug 28, 2003, at 20:46 US/Pacific, playa wrote:
21255 > Is this /time command only supposed to work via RAW? Cause when i
21256 > type /time services.dreamchat.org i get No Such User, but if i do /raw
21257 > time services.dreamchat.org, it works. Just wondering if its just me,
21258 > or if its supposed to be that way.
21260 That's a client thing. Some clients might alias /time as a CTCP TIME
21261 for a specific user, or similar.
21266 From r-krisztian at softhome.net Thu Aug 28 22:12:51 2003
21267 From: r-krisztian at softhome.net (Krisztian Romek)
21268 Date: Sat Oct 23 23:09:57 2004
21269 Subject: [IRCServices Coding] Yet, another great suggestion
21270 In-Reply-To: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
21271 References: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
21272 <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
21273 Message-ID: <200308290713.29423.r-krisztian@softhome.net>
21275 > Is this /time command only supposed to work via RAW? Cause when i type
21276 > /time services.dreamchat.org i get No Such User, but if i do /raw time
21277 > services.dreamchat.org, it works. Just wondering if its just me, or if
21278 > its supposed to be that way.
21280 Some clients use stupid aliases for CTCP commands, for example:
21282 /version <nick> = /CTCP <nick> VERSION,
21283 /time <nick> = /CTCP <nick> TIME,
21284 /finger <nick> = /CTCP <nick> TIME
21286 This is why nothing works the way you expected.
21290 r-krisztian@softhome.net
21293 From us44ever at hotmail.com Fri Aug 29 13:02:19 2003
21294 From: us44ever at hotmail.com (us44ever .)
21295 Date: Sat Oct 23 23:09:57 2004
21296 Subject: [IRCServices Coding] AKill suggestion
21297 Message-ID: <Sea1-F108cM3oryKFRJ0000eb75@hotmail.com>
21299 Pretty good idea, specially is it would be implemented as an option (because
21300 some admins might won't like the idea of displaying the time of when the
21301 akill will expire to the user who has been akilled).
21303 _________________________________________________________________
21304 Help protect your PC: Get a free online virus scan at McAfee.com.
21305 http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
21308 From us44ever at hotmail.com Fri Aug 29 13:09:51 2003
21309 From: us44ever at hotmail.com (us44ever .)
21310 Date: Sat Oct 23 23:09:57 2004
21311 Subject: [IRCServices Coding] Yet, another great suggestion
21312 Message-ID: <Sea1-F127z33hqSnMGE000094b3@hotmail.com>
21315 Since most people want to see this feature(s) in the next version, it would
21316 be great to implement it as an optional feature , where it can be disabled
21317 from the .conf file(s) or enable it easily. I don't think that there is
21318 anything that the authors will lose if this feature can be added, in fact,
21319 it will add another nice feature to the features list of IRCservices5.
21321 _________________________________________________________________
21322 Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
21323 using MSN Messenger http://entertainment.msn.com/imastar
21326 From Craig at chatspike.net Fri Aug 29 13:41:59 2003
21327 From: Craig at chatspike.net (Craig McLure)
21328 Date: Sat Oct 23 23:09:57 2004
21329 Subject: [IRCServices Coding] Yet, another great suggestion
21330 Message-ID: <20030829204143.NNNT26404.mta1-svc.business.ntl.com@i-br0ked-it>
21332 I'll ask again.. can you please stop posting to both the IRCServices mailing list, and the IRCd coding mailing list, getting your mail 2ce is beginning to annoy me.
21334 And i'll Quote Elijah:
21336 "Except it's already been said in the FAQ that it's not going to happen, and
21337 if that made it into the FAQ it would seem the answer is frequently going to
21341 /****************************************
21342 * Craig "FrostyCoolSlug" McLure
21343 ************* - SpamBox - **************
21344 * InspIRCd - http://www.inspircd.org
21345 * ChatSpike - http://www.chatspike.net
21346 * WinBot - http://www.winbot.co.uk
21347 ****************************************/
21349 /****************************************
21350 * From - us44ever . <us44ever@hotmail.com>
21351 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
21352 * Sent - 2003-08-29 @ 20:09:00
21353 * Subject - Re: [IRCServices Coding] Yet, another great suggestion
21354 ****************************************/
21356 /****** - Begin Original Message - ******/
21358 >Since most people want to see this feature(s) in the next version, it would
21359 >be great to implement it as an optional feature , where it can be disabled
21360 >from the .conf file(s) or enable it easily. I don't think that there is
21361 >anything that the authors will lose if this feature can be added, in fact,
21362 >it will add another nice feature to the features list of IRCservices5.
21364 >_________________________________________________________________
21365 >Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
21366 >using MSN Messenger http://entertainment.msn.com/imastar
21368 >------------------------------------------------------------------
21369 >To unsubscribe or change your subscription options, visit:
21370 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
21373 /******* - End Original Message - *******/
21378 From Craig at chatspike.net Fri Aug 29 13:43:24 2003
21379 From: Craig at chatspike.net (Craig McLure)
21380 Date: Sat Oct 23 23:09:57 2004
21381 Subject: [IRCServices Coding] AKill suggestion
21382 Message-ID: <20030829204311.GHCL29825.mta5-svc.business.ntl.com@i-br0ked-it>
21384 its a stupid idea!!! :p
21386 j/k.. I think its a great idea.. i'd rather have services telling users when their akills expire, than them spamming my mailbox with 'when does my akill expire?' every 20mins :p
21388 /****************************************
21389 * Craig "FrostyCoolSlug" McLure
21390 ************* - SpamBox - **************
21391 * InspIRCd - http://www.inspircd.org
21392 * ChatSpike - http://www.chatspike.net
21393 * WinBot - http://www.winbot.co.uk
21394 ****************************************/
21396 /****************************************
21397 * From - Saturn <saturn@jetirc.net>
21398 * To - IRC Services Coding Mailing List <ircservices-coding@ircservices.za.net>
21399 * Sent - 2003-08-28 @ 17:13:00
21400 * Subject - [IRCServices Coding] AKill suggestion
21401 ****************************************/
21403 /****** - Begin Original Message - ******/
21405 >Would it be possible to have it announce to the user when they are akilled,
21406 >either the expiry date and time, or "Expires in 3days, 4hours, 6minutes" or
21407 >something similar. I find that usually we just have to do 24hour bans, but
21408 >the user has no way to know when the ban was set, and when it expires...
21410 >Just an idea... I now await the half dozen people who will proceed to tell
21411 >me how stupid my idea is....
21417 >------------------------------------------------------------------
21418 >To unsubscribe or change your subscription options, visit:
21419 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
21421 /******* - End Original Message - *******/
21426 From admin at nevernet.net Fri Aug 29 13:48:01 2003
21427 From: admin at nevernet.net (Elijah)
21428 Date: Sat Oct 23 23:09:57 2004
21429 Subject: [IRCServices Coding] Yet, another great suggestion
21430 In-Reply-To: <20030829204143.NNNT26404.mta1-svc.business.ntl.com@i-br0ked-it>
21431 Message-ID: <008f01c36e6e$83158770$436a3a44@slytherin>
21435 -----Original Message-----
21436 From: ircservices-coding-bounces@ircservices.za.net
21437 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of Craig
21439 Sent: Friday, August 29, 2003 4:41 PM
21440 To: IRC Services Coding Mailing List
21441 Subject: Re: Re: [IRCServices Coding] Yet, another great suggestion
21444 I'll ask again.. can you please stop posting to both the IRCServices mailing
21445 list, and the IRCd coding mailing list, getting your mail 2ce is beginning
21448 And i'll Quote Elijah:
21450 "Except it's already been said in the FAQ that it's not going to happen, and
21451 if that made it into the FAQ it would seem the answer is frequently going to
21456 From us44ever at hotmail.com Fri Aug 29 16:59:31 2003
21457 From: us44ever at hotmail.com (us44ever .)
21458 Date: Sat Oct 23 23:09:57 2004
21459 Subject: [IRCServices Coding] Yet, another great suggestion
21460 Message-ID: <Sea1-F30z1oyZF58m3O00035b82@hotmail.com>
21462 woops, ok sorry I thought the two e-mails is completely different.
21465 >From: "Craig McLure" <Craig@chatspike.net>
21466 >Reply-To: IRC Services Coding Mailing List
21467 ><ircservices-coding@ircservices.za.net>
21468 >To: IRC Services Coding Mailing List
21469 ><ircservices-coding@ircservices.za.net>
21470 >Subject: Re: Re: [IRCServices Coding] Yet, another great suggestion
21471 >Date: Fri, 29 Aug 2003 21:41:23 +0000
21473 >I'll ask again.. can you please stop posting to both the IRCServices
21474 >mailing list, and the IRCd coding mailing list, getting your mail 2ce is
21475 >beginning to annoy me.
21477 >And i'll Quote Elijah:
21479 >"Except it's already been said in the FAQ that it's not going to happen,
21481 >if that made it into the FAQ it would seem the answer is frequently going
21486 >/****************************************
21487 > * Craig "FrostyCoolSlug" McLure
21488 > ************* - SpamBox - **************
21489 > * InspIRCd - http://www.inspircd.org
21490 > * ChatSpike - http://www.chatspike.net
21491 > * WinBot - http://www.winbot.co.uk
21492 > ****************************************/
21494 >/****************************************
21495 > * From - us44ever . <us44ever@hotmail.com>
21496 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
21497 > * Sent - 2003-08-29 @ 20:09:00
21498 > * Subject - Re: [IRCServices Coding] Yet, another great suggestion
21499 > ****************************************/
21501 >/****** - Begin Original Message - ******/
21503 > >Since most people want to see this feature(s) in the next version, it
21505 > >be great to implement it as an optional feature , where it can be
21507 > >from the .conf file(s) or enable it easily. I don't think that there is
21508 > >anything that the authors will lose if this feature can be added, in
21510 > >it will add another nice feature to the features list of IRCservices5.
21512 > >_________________________________________________________________
21513 > >Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
21514 > >using MSN Messenger http://entertainment.msn.com/imastar
21516 > >------------------------------------------------------------------
21517 > >To unsubscribe or change your subscription options, visit:
21518 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
21521 >/******* - End Original Message - *******/
21525 >------------------------------------------------------------------
21526 >To unsubscribe or change your subscription options, visit:
21527 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
21529 _________________________________________________________________
21530 MSN 8: Get 6 months for $9.95/month. http://join.msn.com/?page=dept/dialup
21533 From simorgh at dataphone.se Sat Aug 30 08:27:11 2003
21534 From: simorgh at dataphone.se (Ali Simorgh)
21535 Date: Sat Oct 23 23:09:57 2004
21536 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
21537 In-Reply-To: <MKEGJINFADFODDNOKEJCMEEADPAA.rg@tcslon.com>
21538 Message-ID: <Pine.GSO.4.31.0308301716410.15629-100000@nikson.dataphone.se>
21541 I run ircservices 5.0.21 on FreeBSD 4.8-STABLE. and Ultimate 3.*
21542 I get this in logfile:
21544 [Aug 30 10:51:19 2003] unknown message from server
21545 (NETCTRL 0 0 0 0 0 0 0 0 0 0 0 0 0)
21546 [Aug 30 10:51:19 2003] user: New maximum user count: 1
21547 [Aug 30 10:51:19 2003] unknown message from server
21548 (:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
21549 [Aug 30 10:51:19 2003] user: New maximum user count: 2
21550 [Aug 30 10:51:19 2003] unknown message from server
21551 (:irc.MyNet.Net SETHOST pedarkhAnde 6b45bb2.26d9672f.dataphone.se)
21552 [Aug 30 10:56:18 2003] mail/sendmail:
21553 /usr/sbin/sendmail exited with code 25600
21554 [Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
21555 registration (Simorgh)
21557 and how can I do so that nickserv dont show the realhost of a user in
21564 ______________________________________________________
21565 Many of life's failures are people who did not realize
21566 how close they were to success when they gave up.
21568 ______________________________________________________
21573 From jskam at shaw.ca Sat Aug 30 11:34:35 2003
21574 From: jskam at shaw.ca (Jeffery Kam)
21575 Date: Sat Oct 23 23:09:57 2004
21576 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
21577 In-Reply-To: <Pine.GSO.4.31.0308301716410.15629-100000@nikson.dataphone.se>
21578 Message-ID: <000001c36f25$58464860$f64f9144@weed>
21580 "and how can I do so that nickserv dont show the realhost of a user in
21581 'ns info nick all'"
21583 This would be a great feature for sure. I know on my network, there is
21584 a custom user mode +d, which will disguise a user's host in a /whois
21585 reply, but services info doesn't show it disguised unless the HIDE
21590 From achurch at achurch.org Sat Aug 30 16:14:47 2003
21591 From: achurch at achurch.org (Andrew Church)
21592 Date: Sat Oct 23 23:09:57 2004
21593 Subject: [IRCServices Coding] MARK Command
21594 In-Reply-To: <3208.66.181.69.244.1060800845.squirrel@dreamchat.org>
21595 Message-ID: <3f512fdb.01666@achurch.org>
21597 Use E-mail if you need communication of that sort.
21600 achurch@achurch.org
21601 http://achurch.org/
21603 >First off, i would like to say that IRCservices are the best services out
21604 >there, by FAR! Anyways, i was wondering if the MARK command will be in
21605 >the next relase? Its kind of a pointless command, its only used to mark
21606 >nicks or channels, but it is very useful for when passwords to channels
21609 >/chanserv MARK <channel> <reason>
21611 >/chanserv info #channel would read the following.
21612 >*#channel has been MARKED by playa - <reason>
21614 >Of course only IRCops would be able to view it.
21616 >Just an idea i thought of :)
21621 >Network Founder/CEO
21622 >DreamChat IRC Network - irc.dreamchat.org
21623 >http://www.dreamchat.org
21625 >------------------------------------------------------------------
21626 >To unsubscribe or change your subscription options, visit:
21627 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
21629 From achurch at achurch.org Sat Aug 30 16:17:44 2003
21630 From: achurch at achurch.org (Andrew Church)
21631 Date: Sat Oct 23 23:09:57 2004
21632 Subject: [IRCServices Coding] OP/Voice upon identify
21633 In-Reply-To: <Pine.GSO.4.31.0308211027350.6118-100000@nikson.dataphone.se>
21634 Message-ID: <3f513092.01677@achurch.org>
21636 Needless complexity. If you don't want yourself autoopped, then don't
21637 be an auto-op. It's that simple.
21640 achurch@achurch.org
21641 http://achurch.org/
21644 >Its nice with this option. but I dont se any set command that ChanServ
21645 >wont automatically op or voice you in any channel.
21648 > SET NOAUTO ON|OFF
21649 > When NOAUTO is on, ChanServ will not
21650 > automatically op or voice you in any channels.
21652 >Maybe some user(s) wont get auto op/voice then they can set this option ON
21653 >but it sould be OFF in default.
21660 > ______________________________________________________
21661 > Many of life's failures are people who did not realize
21662 > how close they were to success when they gave up.
21664 > ______________________________________________________
21667 >On Sun, 17 Aug 2003, Russell Garrett wrote:
21669 >> Eh? This has been implemented since IRCServices 5a31.
21673 >> > I wonder if its possible to make some modification that:
21674 >> > when someone has already joined a few channels, and then identifies
21675 >> > to its nickname, chanserv gives Voice and/or Op to the user is s/he
21676 >> > is in the channel list (+o; aop or above & +v when vop)
21678 >> > this is very usefull to not privmsg chanserv for every op or voice
21679 >> > request, when user has not identified to its nick before joining
21682 >> > Thanks for any help
21684 >> ------------------------------------------------------------------
21685 >> To unsubscribe or change your subscription options, visit:
21686 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
21689 >------------------------------------------------------------------
21690 >To unsubscribe or change your subscription options, visit:
21691 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
21693 From l8nite at l8nite.net Sat Aug 30 16:58:16 2003
21694 From: l8nite at l8nite.net (Shaun Guth)
21695 Date: Sat Oct 23 23:09:57 2004
21696 Subject: [IRCServices Coding] OP/Voice upon identify
21697 In-Reply-To: <3f513092.01677@achurch.org>
21698 References: <3f513092.01677@achurch.org>
21699 Message-ID: <1062287885.21924.6.camel@localhost>
21701 On Sun, 2003-08-31 at 01:16, Andrew Church wrote:
21702 > Needless complexity. If you don't want yourself autoopped, then don't
21703 > be an auto-op. It's that simple.
21705 I disagree. In my case, I wanted to create a channel where there were
21706 no ops so users don't have to endure lame op-wars, etc. However, I did
21707 need to maintain a level of control over the channel to protect from
21708 extremely obnoxious behavior or lame bots, etc. By registering as
21709 founder of the channel I induced the unwanted 'auto-op' behavior. My
21710 only solution was to register another fake user to become channel
21711 founder and set their nick to noexpire. That to me seems like needless
21712 complexity. A simple check to see if the user wishes to be opped or not
21718 From Craig at chatspike.net Sat Aug 30 17:07:32 2003
21719 From: Craig at chatspike.net (Craig McLure)
21720 Date: Sat Oct 23 23:09:57 2004
21721 Subject: [IRCServices Coding] OP/Voice upon identify
21722 Message-ID: <20030831000719.ELIJ19019.mta3-svc.business.ntl.com@i-br0ked-it>
21724 it would thou.. they would have to be able to switch off auto-op for a single channel..
21725 you could always use /cs levels to change the 'auto op' level up.. so that no one is auto-opped..
21727 or /cs levels #channels DISABLE autoop
21729 /****************************************
21730 * Craig "FrostyCoolSlug" McLure
21731 ************* - SpamBox - **************
21732 * InspIRCd - http://www.inspircd.org
21733 * ChatSpike - http://www.chatspike.net
21734 * WinBot - http://www.winbot.co.uk
21735 ****************************************/
21737 /****************************************
21738 * From - Shaun Guth <l8nite@l8nite.net>
21739 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
21740 * Sent - 2003-08-30 @ 16:58:00
21741 * Subject - RE: [IRCServices Coding] OP/Voice upon identify
21742 ****************************************/
21744 /****** - Begin Original Message - ******/
21746 >On Sun, 2003-08-31 at 01:16, Andrew Church wrote:
21747 >> Needless complexity. If you don't want yourself autoopped, then don't
21748 >> be an auto-op. It's that simple.
21750 >I disagree. In my case, I wanted to create a channel where there were
21751 >no ops so users don't have to endure lame op-wars, etc. However, I did
21752 >need to maintain a level of control over the channel to protect from
21753 >extremely obnoxious behavior or lame bots, etc. By registering as
21754 >founder of the channel I induced the unwanted 'auto-op' behavior. My
21755 >only solution was to register another fake user to become channel
21756 >founder and set their nick to noexpire. That to me seems like needless
21757 >complexity. A simple check to see if the user wishes to be opped or not
21762 >------------------------------------------------------------------
21763 >To unsubscribe or change your subscription options, visit:
21764 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
21767 /******* - End Original Message - *******/
21772 From l8nite at l8nite.net Sat Aug 30 17:14:44 2003
21773 From: l8nite at l8nite.net (Shaun Guth)
21774 Date: Sat Oct 23 23:09:57 2004
21775 Subject: [IRCServices Coding] OP/Voice upon identify
21776 In-Reply-To: <20030831000719.ELIJ19019.mta3-svc.business.ntl.com@i-br0ked-it>
21777 References: <20030831000719.ELIJ19019.mta3-svc.business.ntl.com@i-br0ked-it>
21778 Message-ID: <1062288881.21924.17.camel@localhost>
21780 On Sat, 2003-08-30 at 18:06, Craig McLure wrote:
21781 > it would thou.. they would have to be able to switch off auto-op for a single channel..
21783 For each channel we already store an access list, one extra bit to
21784 indicate auto-anything status or not is not really asking too much.
21786 > you could always use /cs levels to change the 'auto op' level up.. so that no one is auto-opped..
21787 > or /cs levels #channels DISABLE autoop
21789 -ChanServ- Channel #foobar registered under your nickname: l8
21790 -ChanServ- AUTOOP disabled on channel #foobar.
21791 --- You have left channel #foobar
21792 --> You are now talking on #foobar
21793 --- services.topgamers.net removes channel operator status from l8
21794 --- services.topgamers.net gives channel operator status to l8
21796 Same with ENFORCE set to off as well.
21798 > [snipped obnoxiously long sig]
21803 From achurch at achurch.org Sun Aug 31 02:58:23 2003
21804 From: achurch at achurch.org (Andrew Church)
21805 Date: Sat Oct 23 23:09:57 2004
21806 Subject: [IRCServices Coding] OP/Voice upon identify
21807 In-Reply-To: <1062288881.21924.17.camel@localhost>
21808 Message-ID: <3f51c6b5.07402@achurch.org>
21810 >> you could always use /cs levels to change the 'auto op' level up.. so that no one is auto-opped..
21811 >> or /cs levels #channels DISABLE autoop
21813 >-ChanServ- Channel #foobar registered under your nickname: l8
21814 >-ChanServ- AUTOOP disabled on channel #foobar.
21815 >--- You have left channel #foobar
21816 >--> You are now talking on #foobar
21817 >--- services.topgamers.net removes channel operator status from l8
21818 >--- services.topgamers.net gives channel operator status to l8
21820 This is definitely confusing behavior. Fixed for 5.0.22, thanks for
21821 the report. Note that you will also want to disable the other AUTOxxx
21822 levels as well if you don't want any automatic modes.
21825 achurch@achurch.org
21826 http://achurch.org/
21828 From achurch at achurch.org Sun Aug 31 07:28:11 2003
21829 From: achurch at achurch.org (Andrew Church)
21830 Date: Sat Oct 23 23:09:57 2004
21831 Subject: [IRCServices Coding] Mass memos
21832 In-Reply-To: <001601c361d8$a5312f00$6401a8c0@turby>
21833 Message-ID: <3f5205f0.15057@achurch.org>
21835 >Can we reconsider adding a Mass memo function for the next release?
21837 No, for all the reasons others have mentioned. I'll also draw an
21838 example from my experience with cellphone mail in Japan, which is
21839 remarkably similar to Services memos: Automated messages are annoying,
21840 period. The primary use for cellphone mail is to communicate with friends;
21841 having automatic messages interfere with that is annoying in the extreme.
21842 Yes, 10% or 20% of your users might be willing to accept mass memos, but
21843 the remaining 80% or 90% will get quite upset with you.
21845 I might also point out that people who care about what happens on the
21846 network will actively check that information, whether you make it available
21847 through logon news, through a website, or whatever; and people who don't
21848 care will ignore anything you send them. The method you use to inform them
21849 won't really make a difference.
21851 >If not, or even if so... one thing puzzles me: In the /ns list * command,
21852 >the listings have occasional punctuation... a ! or ? in front of the nick.
21853 >There is nothing in the docs anywhere that seems to address this, and I'm
21854 >curious as to what those mean.... an explanation would be helpful there too.
21856 This should be available through /ns help list, but there appears to
21857 be a bug there. I'll fix it for the next version.
21859 >on that note, a possible suggestion for Logonnews... How about something I
21860 >saw on Dalnet once: When new news is added, you get a notice. Until you
21861 >read the news, it keeps bugging you when you log on. After you read it, it
21862 >stops. Some sort of flag so users know when there IS new news would be
21863 >useful... the main reason nobody read the logonnews is that 90% of the time
21864 >for them, it is unchanged........
21866 This is an interesting thought; I'll think about it for a future
21870 achurch@achurch.org
21871 http://achurch.org/
21873 From achurch at achurch.org Sun Aug 31 07:42:30 2003
21874 From: achurch at achurch.org (Andrew Church)
21875 Date: Sat Oct 23 23:09:57 2004
21876 Subject: [IRCServices Coding] Language
21877 In-Reply-To: <MKEGJINFADFODDNOKEJCKEEDDPAA.rg@tcslon.com>
21878 Message-ID: <3f52094e.17046@achurch.org>
21880 [/msg nickserv vs. /nickserv]
21881 >I wonder if it would be worth integrating such a thing into services as an
21882 >option (compile-time maybe?). I think it would be good for the irc community
21883 >as a whole to get away from the habit of msging services directly if at all
21884 >possible. Opinions?
21886 /msg NickServ is the one format that's guaranteed to work on every
21887 ircd (except for administrative decisions a la DALnet). Get an RFC
21888 published--and implemented; 2811-3 were remarkable failures in that area--
21889 and I'll consider changing it.
21892 achurch@achurch.org
21893 http://achurch.org/
21895 From achurch at achurch.org Sun Aug 31 07:45:49 2003
21896 From: achurch at achurch.org (Andrew Church)
21897 Date: Sat Oct 23 23:09:57 2004
21898 Subject: [IRCServices Coding] Language
21899 In-Reply-To: <Pine.GSO.4.31.0308172127300.9882-100000@nikson.dataphone.se>
21900 Message-ID: <3f520a18.17063@achurch.org>
21902 >Is there any tool (silly question) or something or guid to make a language
21905 >I have decided to make a Persian (Farsi) language file.
21907 Language files are just plain text files; as another reply said, read
21908 the comments at the top of lang/en_us.l, and work from there. Be warned
21909 that the amount of text is huge; expect to spend at least two to three
21910 months on the initial translation.
21912 Also, if you'd be willing to continue maintaining the language file as
21913 it is updated in future versions, please let me know privately.
21916 achurch@achurch.org
21917 http://achurch.org/
21919 From achurch at achurch.org Sun Aug 31 07:53:21 2003
21920 From: achurch at achurch.org (Andrew Church)
21921 Date: Sat Oct 23 23:09:57 2004
21922 Subject: [IRCServices Coding] segfault on expiring ?
21923 In-Reply-To: <001201c36793$d26e4000$0101a8c0@nothing>
21924 Message-ID: <3f520bd8.17715@achurch.org>
21926 >[Aug 20 20:49:05 2003] nickserv/main: Expiring suspension for SeBa_KoBe (nick group 17805)
21927 >[Aug 20 20:49:05 2003] nickserv/main: Expiring nickname SeBa_KoBe
21928 >[Aug 20 20:49:05 2003] nickserv/main: [Aug 20 20:49:05 2003] Services terminating: Segmentation Faul
21930 I can't reproduce this problem. If this is still occurring, can you
21931 send me your databases privately so that I can investigate it?
21934 achurch@achurch.org
21935 http://achurch.org/
21937 From achurch at achurch.org Sun Aug 31 07:55:10 2003
21938 From: achurch at achurch.org (Andrew Church)
21939 Date: Sat Oct 23 23:09:57 2004
21940 Subject: [IRCServices Coding] BUG Report
21941 In-Reply-To: <001501c36daf$c8cba700$0101a8c0@house>
21942 Message-ID: <3f520c48.17731@achurch.org>
21944 >we suspended channel #kavala, and someone has identified itself has the =
21945 >founder and apply a DROP to the channel.
21946 >then we got a panic from the services and... crash.
21948 This is a bug in the DROP function, and has been fixed; thanks for the
21952 achurch@achurch.org
21953 http://achurch.org/
21955 From achurch at achurch.org Sun Aug 31 08:07:44 2003
21956 From: achurch at achurch.org (Andrew Church)
21957 Date: Sat Oct 23 23:09:57 2004
21958 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
21959 In-Reply-To: <Pine.GSO.4.31.0308301716410.15629-100000@nikson.dataphone.se>
21960 Message-ID: <3f520f38.21076@achurch.org>
21962 >[Aug 30 10:56:18 2003] mail/sendmail:
21963 > /usr/sbin/sendmail exited with code 25600
21965 Use the SMTP module instead (mail/smtp).
21967 >[Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
21968 >registration (Simorgh)
21970 >and how can I do so that nickserv dont show the realhost of a user in
21971 >'ns info nick all'
21973 It doesn't. However:
21975 >[Aug 30 10:51:19 2003] unknown message from server
21976 >(:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
21978 You're using the wrong protocol, since it doesn't recognize the
21979 SETHOST command and therefore has no idea about fake hosts. I might
21980 remind you that Ultimate 3.x is not supported.
21983 achurch@achurch.org
21984 http://achurch.org/
21986 From achurch at achurch.org Sun Aug 31 08:11:22 2003
21987 From: achurch at achurch.org (Andrew Church)
21988 Date: Sat Oct 23 23:09:57 2004
21989 Subject: [IRCServices Coding] Yet, another great suggestion
21990 In-Reply-To: <20030828183615.GB32204@phat.za.net>
21991 Message-ID: <3f52100e.21116@achurch.org>
21993 >Or how about rather letting users decide what timezone they're in and
21994 >services outputs all timestamps in their local time?
21996 /ns help set timezone (since 5.0 alpha)
21999 achurch@achurch.org
22000 http://achurch.org/
22002 From saturn at jetirc.net Sun Aug 31 12:28:59 2003
22003 From: saturn at jetirc.net (Saturn)
22004 Date: Sat Oct 23 23:09:57 2004
22005 Subject: [IRCServices Coding]
22006 Re: [IRCServices] Yet, another great suggestion
22007 References: <3f5202a3.15001@achurch.org>
22008 Message-ID: <003201c36ff6$25ae6550$6401a8c0@turby>
22010 I think it is... consider an international Network like mine: every server
22011 is in a different time zone -- How are users supposed to know what time zone
22012 the Services (pickign on Services' clock because Services are whats giving
22013 these notices!) is in?? Sure, they can do the /time command, if they even
22014 know abotu it. But the vast majority of IRC users are ignorant of those
22015 sorts of commands, or even if they know about /time, they most likely have
22016 no idea they can specify a server with the command.
22018 I realize that programmers for IRC-related software seem always to be of the
22019 universal opinion that ALL irc users should take the time to become elite
22020 experts abotu everything PC, however that is simply NOT reality. Services
22021 is specificly there to SERVE the users and the ircops. Its sole function is
22022 to police access and provide information to the users -- what use is it to
22023 say that a certain piece of information is "not useful" or "not needed" when
22024 you can plainly see that it is in this case, given the argument above?
22026 Obviously, it is your project, not mine, and I certainly cannot force you to
22027 do anythign you don't want to do, but I and my staff and users all agree it
22028 would be extremely useful... "Handy" was the word most used. I've had quite
22029 a few queries about it, and so I'm asking for it. If you don't feel that
22030 non-techie users deserve any consideration, then ignore the request. It's
22031 really up to you anyhow....
22036 ----- Original Message -----
22037 From: "Andrew Church" <achurch@achurch.org>
22038 To: <saturn@jetirc.net>
22039 Sent: Sunday, August 31, 2003 7:13 AM
22040 Subject: Re: [IRCServices] Yet, another great suggestion
22043 >So how do you get the current time from Services then? The actual time that
22044 >SERVICES thinks it is, not the server, and not my local clock...
22046 If there's any significant difference between your local clock, your
22047 IRC server's clock, and Services' clock, then at least one of them needs to
22048 be fixed. That's not Services' problem.
22051 achurch@achurch.org
22052 http://achurch.org/
22056 From aragon at phat.za.net Sun Aug 31 13:23:29 2003
22057 From: aragon at phat.za.net (Aragon Gouveia)
22058 Date: Sat Oct 23 23:09:57 2004
22059 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
22060 another great suggestion
22061 In-Reply-To: <003201c36ff6$25ae6550$6401a8c0@turby>
22062 References: <3f5202a3.15001@achurch.org> <003201c36ff6$25ae6550$6401a8c0@turby>
22063 Message-ID: <20030831202324.GB8731@phat.za.net>
22065 | By Saturn <saturn@jetirc.net>
22066 | [ 2003-08-31 21:29 +0200 ]
22067 > I think it is... consider an international Network like mine: every server
22068 > is in a different time zone -- How are users supposed to know what time zone
22069 > the Services (pickign on Services' clock because Services are whats giving
22070 > these notices!) is in?? Sure, they can do the /time command, if they even
22071 > know abotu it. But the vast majority of IRC users are ignorant of those
22072 > sorts of commands, or even if they know about /time, they most likely have
22073 > no idea they can specify a server with the command.
22075 Erm, what's the argument here? Services stipulates its timezone in its
22076 timestamps. As do all the other servers on the network.
22084 From saturn at jetirc.net Sun Aug 31 13:47:37 2003
22085 From: saturn at jetirc.net (Saturn)
22086 Date: Sat Oct 23 23:09:57 2004
22087 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
22088 another great suggestion
22089 References: <3f5202a3.15001@achurch.org> <003201c36ff6$25ae6550$6401a8c0@turby>
22090 <20030831202324.GB8731@phat.za.net>
22091 Message-ID: <000701c37001$10a62cf0$6401a8c0@turby>
22093 The argument is that the overwhelming majority of IRC users have no idea the
22094 /time command exists, and even fewer are aware that they can specify a
22095 server name after the /time command. How would these people find out the
22096 Services time zone? Why does it all have to be so complicated??
22098 ----- Original Message -----
22099 From: "Aragon Gouveia" <aragon@phat.za.net>
22100 To: <ircservices-coding@ircservices.za.net>
22101 Sent: Sunday, August 31, 2003 1:23 PM
22102 Subject: Re: [IRCServices Coding] Re: [IRCServices] Yet,another great
22106 | By Saturn <saturn@jetirc.net>
22107 | [ 2003-08-31 21:29 +0200 ]
22108 > I think it is... consider an international Network like mine: every
22110 > is in a different time zone -- How are users supposed to know what time
22112 > the Services (pickign on Services' clock because Services are whats giving
22113 > these notices!) is in?? Sure, they can do the /time command, if they even
22114 > know abotu it. But the vast majority of IRC users are ignorant of those
22115 > sorts of commands, or even if they know about /time, they most likely have
22116 > no idea they can specify a server with the command.
22118 Erm, what's the argument here? Services stipulates its timezone in its
22119 timestamps. As do all the other servers on the network.
22126 ------------------------------------------------------------------
22127 To unsubscribe or change your subscription options, visit:
22128 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
22132 From quension at mac.com Sun Aug 31 14:11:28 2003
22133 From: quension at mac.com (Trevor Talbot)
22134 Date: Sat Oct 23 23:09:57 2004
22135 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
22136 another great suggestion
22137 In-Reply-To: <000701c37001$10a62cf0$6401a8c0@turby>
22138 Message-ID: <962546B6-DBF7-11D7-8505-0003938D6866@mac.com>
22140 On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
22142 > The argument is that the overwhelming majority of IRC users have no
22143 > idea the /time command exists, and even fewer are aware that they can
22144 > specify a server name after the /time command. How would these people
22145 > find out the Services time zone?
22147 You missed the point. Services shows the time zone wherever it uses a
22148 readable time -- i.e. in the nickserv/chanserv info displays. Unless
22149 you've changed your language file, in which case you can simply change
22152 > Why does it all have to be so complicated??
22154 It isn't. Your users can even use the handy-dandy /nickserv set
22155 timezone command to make it even easier.
22157 > ----- Original Message -----
22158 > From: "Aragon Gouveia" <aragon@phat.za.net>
22160 > | By Saturn <saturn@jetirc.net>
22161 > | [ 2003-08-31 21:29 +0200 ]
22162 >> I think it is... consider an international Network like mine: every
22163 >> server is in a different time zone -- How are users supposed to know
22164 >> what time zone the Services (pickign on Services' clock because
22165 >> Services are whats giving these notices!) is in?? Sure, they can do
22166 >> the /time command, if they even know abotu it. But the vast majority
22167 >> of IRC users are ignorant of those sorts of commands, or even if they
22168 >> know about /time, they most likely have no idea they can specify a
22169 >> server with the command.
22171 > Erm, what's the argument here? Services stipulates its timezone in
22172 > its timestamps. As do all the other servers on the network.
22177 From us44ever at hotmail.com Sun Aug 31 14:40:48 2003
22178 From: us44ever at hotmail.com (us44ever .)
22179 Date: Sat Oct 23 23:09:57 2004
22180 Subject: [IRCServices Coding]
22181 Re: [IRCServices] Yet, another great suggestion
22182 Message-ID: <Sea1-F8siZAPG4vEjaG0000fb20@hotmail.com>
22185 or even the idea of adding an additional info (exact info) something like:
22186 Last seen time : Aug 22 14:20:16 2003 GMT (9 days, 51 minutes and 21
22188 Time registered : Jul 25 22:19:20 2003 GMT (** days, ** minutes and **
22190 wouldn't even a greater idea?
22192 _________________________________________________________________
22193 Get MSN 8 and enjoy automatic e-mail virus protection.
22194 http://join.msn.com/?page=features/virus
22197 From saturn at jetirc.net Sun Aug 31 16:49:07 2003
22198 From: saturn at jetirc.net (Saturn)
22199 Date: Sat Oct 23 23:09:58 2004
22200 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
22201 another great suggestion
22202 References: <962546B6-DBF7-11D7-8505-0003938D6866@mac.com>
22203 Message-ID: <000e01c3701a$48faea50$6401a8c0@turby>
22205 [16:41] -NickServ- Time registered: Jul 27 13:09:08 2002 PDT
22207 That's what I see when I use it. Yes, it does say "PDT" .. how many people
22208 in, say Belgium, are going to know exactly what PDT is? How about "PDT
22209 (GMT-8)" as the format....? Also, you'll note that it STILL gives no
22210 indication as to the CURRENT time ... this is why the proper UTC code or
22211 GMT+/-## is the best way to go IMHO. I do also like the idea suggested by
22212 us44ever ... the "(** days, ** minutes, and ** seconds ago)" idea... that
22213 would be handy in any event.... and would eliminate the need for the current
22214 time to be displayed....
22216 On another note, I had forgotten the set timezone option, which certainly
22217 would put more clarity on the output... however, I think my points above are
22220 Unless of course I've missed a config setting that will tell it to report
22221 the tiome zone as a function of GMT (plus or minus x hours, rather than zone
22224 ----- Original Message -----
22225 From: "Trevor Talbot" <quension@mac.com>
22226 To: "IRC Services Coding Mailing List"
22227 <ircservices-coding@ircservices.za.net>
22228 Sent: Sunday, August 31, 2003 2:10 PM
22229 Subject: Re: [IRCServices Coding] Re: [IRCServices] Yet,another great
22233 On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
22235 > The argument is that the overwhelming majority of IRC users have no
22236 > idea the /time command exists, and even fewer are aware that they can
22237 > specify a server name after the /time command. How would these people
22238 > find out the Services time zone?
22240 You missed the point. Services shows the time zone wherever it uses a
22241 readable time -- i.e. in the nickserv/chanserv info displays. Unless
22242 you've changed your language file, in which case you can simply change
22245 > Why does it all have to be so complicated??
22247 It isn't. Your users can even use the handy-dandy /nickserv set
22248 timezone command to make it even easier.
22250 > ----- Original Message -----
22251 > From: "Aragon Gouveia" <aragon@phat.za.net>
22253 > | By Saturn <saturn@jetirc.net>
22254 > | [ 2003-08-31 21:29 +0200 ]
22255 >> I think it is... consider an international Network like mine: every
22256 >> server is in a different time zone -- How are users supposed to know
22257 >> what time zone the Services (pickign on Services' clock because
22258 >> Services are whats giving these notices!) is in?? Sure, they can do
22259 >> the /time command, if they even know abotu it. But the vast majority
22260 >> of IRC users are ignorant of those sorts of commands, or even if they
22261 >> know about /time, they most likely have no idea they can specify a
22262 >> server with the command.
22264 > Erm, what's the argument here? Services stipulates its timezone in
22265 > its timestamps. As do all the other servers on the network.
22269 ------------------------------------------------------------------
22270 To unsubscribe or change your subscription options, visit:
22271 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
22275 From quension at mac.com Sun Aug 31 18:25:05 2003
22276 From: quension at mac.com (Trevor Talbot)
22277 Date: Sat Oct 23 23:09:58 2004
22278 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
22279 another great suggestion
22280 In-Reply-To: <000e01c3701a$48faea50$6401a8c0@turby>
22281 Message-ID: <14C7EDD0-DC1B-11D7-8505-0003938D6866@mac.com>
22283 On Sunday, Aug 31, 2003, at 16:47 US/Pacific, Saturn wrote:
22285 > Unless of course I've missed a config setting that will tell it to
22286 > report the tiome zone as a function of GMT (plus or minus x hours,
22287 > rather than zone codes like PDT)...
22289 You could modify the language file, using something like "(GMT%z)"
22290 instead of %Z in the STRFTIME_DATE_TIME_FORMAT string. "man 3
22291 strftime" for the available options.
22296 From achurch at achurch.org Sun Aug 31 19:00:00 2003
22297 From: achurch at achurch.org (Andrew Church)
22298 Date: Sat Oct 23 23:09:58 2004
22299 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
22300 another great suggestion
22301 In-Reply-To: <000e01c3701a$48faea50$6401a8c0@turby>
22302 Message-ID: <3f52a815.21363@achurch.org>
22304 "Use /ns set timezone" is the official answer on this. Please take
22305 all further discussion to the ircservices list.
22308 achurch@achurch.org
22309 http://achurch.org/
22311 >[16:41] -NickServ- Time registered: Jul 27 13:09:08 2002 PDT
22313 >That's what I see when I use it. Yes, it does say "PDT" .. how many people
22314 >in, say Belgium, are going to know exactly what PDT is? How about "PDT
22315 >(GMT-8)" as the format....? Also, you'll note that it STILL gives no
22316 >indication as to the CURRENT time ... this is why the proper UTC code or
22317 >GMT+/-## is the best way to go IMHO. I do also like the idea suggested by
22318 >us44ever ... the "(** days, ** minutes, and ** seconds ago)" idea... that
22319 >would be handy in any event.... and would eliminate the need for the current
22320 >time to be displayed....
22322 >On another note, I had forgotten the set timezone option, which certainly
22323 >would put more clarity on the output... however, I think my points above are
22326 >Unless of course I've missed a config setting that will tell it to report
22327 >the tiome zone as a function of GMT (plus or minus x hours, rather than zone
22328 >codes like PDT)...
22330 >----- Original Message -----
22331 >From: "Trevor Talbot" <quension@mac.com>
22332 >To: "IRC Services Coding Mailing List"
22333 ><ircservices-coding@ircservices.za.net>
22334 >Sent: Sunday, August 31, 2003 2:10 PM
22335 >Subject: Re: [IRCServices Coding] Re: [IRCServices] Yet,another great
22339 >On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
22341 >> The argument is that the overwhelming majority of IRC users have no
22342 >> idea the /time command exists, and even fewer are aware that they can
22343 >> specify a server name after the /time command. How would these people
22344 >> find out the Services time zone?
22346 >You missed the point. Services shows the time zone wherever it uses a
22347 >readable time -- i.e. in the nickserv/chanserv info displays. Unless
22348 >you've changed your language file, in which case you can simply change
22351 >> Why does it all have to be so complicated??
22353 >It isn't. Your users can even use the handy-dandy /nickserv set
22354 >timezone command to make it even easier.
22356 >> ----- Original Message -----
22357 >> From: "Aragon Gouveia" <aragon@phat.za.net>
22359 >> | By Saturn <saturn@jetirc.net>
22360 >> | [ 2003-08-31 21:29 +0200 ]
22361 >>> I think it is... consider an international Network like mine: every
22362 >>> server is in a different time zone -- How are users supposed to know
22363 >>> what time zone the Services (pickign on Services' clock because
22364 >>> Services are whats giving these notices!) is in?? Sure, they can do
22365 >>> the /time command, if they even know abotu it. But the vast majority
22366 >>> of IRC users are ignorant of those sorts of commands, or even if they
22367 >>> know about /time, they most likely have no idea they can specify a
22368 >>> server with the command.
22370 >> Erm, what's the argument here? Services stipulates its timezone in
22371 >> its timestamps. As do all the other servers on the network.
22375 >------------------------------------------------------------------
22376 >To unsubscribe or change your subscription options, visit:
22377 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
22380 >------------------------------------------------------------------
22381 >To unsubscribe or change your subscription options, visit:
22382 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
22384 From simorgh at dataphone.se Sun Aug 31 22:34:32 2003
22385 From: simorgh at dataphone.se (Ali Simorgh)
22386 Date: Sat Oct 23 23:09:58 2004
22387 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
22388 In-Reply-To: <3f520f38.21076@achurch.org>
22389 Message-ID: <Pine.GSO.4.31.0309010728040.7173-100000@nikson.dataphone.se>
22391 Thanks for your help.
22393 I thought if I set nickserv to not be an ircop, then it maybe dosent se
22394 the real host name, and maybe shows the crypted hostname to other users
22395 or should I change this line in language files:
22396 NICK_INFO_ADDRESS_ONLINE
22399 NICK_INFO_ADDRESS_ONLINE
22400 Is online from: N/A ?
22404 ______________________________________________________
22405 Many of life's failures are people who did not realize
22406 how close they were to success when they gave up.
22408 ______________________________________________________
22411 On Mon, 1 Sep 2003, Andrew Church wrote:
22413 > >[Aug 30 10:56:18 2003] mail/sendmail:
22414 > > /usr/sbin/sendmail exited with code 25600
22416 > Use the SMTP module instead (mail/smtp).
22418 > >[Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
22419 > >registration (Simorgh)
22421 > >and how can I do so that nickserv dont show the realhost of a user in
22422 > >'ns info nick all'
22424 > It doesn't. However:
22426 > >[Aug 30 10:51:19 2003] unknown message from server
22427 > >(:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
22429 > You're using the wrong protocol, since it doesn't recognize the
22430 > SETHOST command and therefore has no idea about fake hosts. I might
22431 > remind you that Ultimate 3.x is not supported.
22434 > achurch@achurch.org
22435 > http://achurch.org/
22436 > ------------------------------------------------------------------
22437 > To unsubscribe or change your subscription options, visit:
22438 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
22442 From achurch at achurch.org Sun Aug 31 23:24:09 2003
22443 From: achurch at achurch.org (Andrew Church)
22444 Date: Sat Oct 23 23:09:58 2004
22445 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
22446 In-Reply-To: <Pine.GSO.4.31.0309010728040.7173-100000@nikson.dataphone.se>
22447 Message-ID: <3f52e5fe.41203@achurch.org>
22449 >I thought if I set nickserv to not be an ircop, then it maybe dosent se
22450 >the real host name, and maybe shows the crypted hostname to other users
22452 It isn't a matter of NickServ having operator privileges or not;
22453 Services, as a server, always sees the real hostname. The problem is that
22454 Services and your IRC server aren't using the same protocol, so Services
22455 can't recognize the fake hosts. Try using a different IRC server.
22458 achurch@achurch.org
22459 http://achurch.org/
22461 From laser at musichat.net Wed Sep 3 06:49:40 2003
22462 From: laser at musichat.net (Alessandro Ciappei)
22463 Date: Sat Oct 23 23:09:58 2004
22464 Subject: [IRCServices Coding] New Features
22465 Message-ID: <001b01c37222$428f54d0$e2c0fea9@alexxa3il9cxpx>
22469 I have an idea for next release.
22470 A secure link between services and ircd.
22471 Now many ircd, like Unreal, tr-ircd, bahamut supports a ssl link.
22476 -------------- next part --------------
22477 An HTML attachment was scrubbed...
22478 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030903/a25ee68d/attachment.html
22479 From r-krisztian at softhome.net Wed Sep 3 07:16:45 2003
22480 From: r-krisztian at softhome.net (Krisztian Romek)
22481 Date: Sat Oct 23 23:09:58 2004
22482 Subject: [IRCServices Coding] New Features
22483 In-Reply-To: <001b01c37222$428f54d0$e2c0fea9@alexxa3il9cxpx>
22484 References: <001b01c37222$428f54d0$e2c0fea9@alexxa3il9cxpx>
22485 Message-ID: <200309031617.38876.r-krisztian@softhome.net>
22490 > I have an idea for next release.
22491 > A secure link between services and ircd.
22492 > Now many ircd, like Unreal, tr-ircd, bahamut supports a ssl link.
22494 I think a ZIP link support (like in Unreal) should also be fine. :-) I don't
22495 know what you will reply for these feature requests, but I agree that they
22496 aren't so important, since in most cases ircd and services run on the same
22501 r-krisztian@softhome.net
22504 From Craig at chatspike.net Wed Sep 3 13:35:04 2003
22505 From: Craig at chatspike.net (Craig McLure)
22506 Date: Sat Oct 23 23:09:58 2004
22507 Subject: [IRCServices Coding] New Features
22508 Message-ID: <20030903203453.ITMO19019.mta3-svc.business.ntl.com@i-br0ked-it>
22510 If you read the archive, you will find that this has already been discussed (fairly recently if i recall..), and was thrown out, if you want services SSL support, i recommend you use a SSL tunnel.
22512 When it comes to ZIP links, this would require editing the services protocol module accordingly.. and IMO, shouldnt been needed, as in most cases, services run on the same box as a server.
22514 /****************************************
22515 * Craig "FrostyCoolSlug" McLure
22516 ************* - SpamBox - **************
22517 * InspIRCd - http://www.inspircd.org
22518 * ChatSpike - http://www.chatspike.net
22519 * WinBot - http://www.winbot.co.uk
22520 ****************************************/
22522 /****************************************
22523 * From - Alessandro Ciappei <laser@musichat.net>
22524 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
22525 * Sent - 2003-09-03 @ 15:49:00
22526 * Subject - [IRCServices Coding] New Features
22527 ****************************************/
22529 /****** - Begin Original Message - ******/
22533 >I have an idea for next release.
22534 >A secure link between services and ircd.
22535 >Now many ircd, like Unreal, tr-ircd, bahamut supports a ssl link.
22540 >------------------------------------------------------------------
22541 >To unsubscribe or change your subscription options, visit:
22542 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
22544 /******* - End Original Message - *******/
22549 From ircserv at elric.net Wed Sep 3 20:49:47 2003
22550 From: ircserv at elric.net (Brent DiNicola)
22551 Date: Sat Oct 23 23:09:58 2004
22552 Subject: [IRCServices Coding] Which route to take - Module?
22553 Message-ID: <5.2.1.1.0.20030903223929.016e4648@mail.elric.net>
22555 It wasn't an easy subject to sum up in just a few words.
22557 I am wanting to do something to the ircservices code, I want to change
22558 the way the notice() works. I know that modifying the send.c would be
22559 very frowned upon and then I got to thinking and had suggested that I
22560 maybe make a module to keep the information for me. I know it's against
22561 the RFC, but I am pressed against a brick wall here, I have to give the users
22562 an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
22563 I would like to give them the option of turning on PRIVMSG but have NOTICE
22564 be the default, that would get the lazy people to use NOTICE. Eventually
22565 getting rid of this problem. In the mean time, I was thinking what is the best
22566 way to go about this without causing trouble for me and anyone else who has
22567 to deal with this code. Is it possible or even suggested to make a module that
22568 would replace the notice() from send.c with it's own, leaving the code in
22570 alone and not causing troubles down the road. Suggestions were that I make a
22571 module that kept the info for each nick's setting and then if I could override
22572 the notice() and notice_lang() and notice_help() in send.c that would keep
22574 other code clean and not cause other troubles. I want to know what the best
22575 way to do this would be, I know it's against RFC but I want to move to newer
22576 services than the 1.4.3pre4 that we are using now and add modules so that I
22577 can do things down the line. They are used to having PRIVMSG and I can't just
22578 change it without running people off, so if I can make PRIVMSG an option
22579 then I can't be blamed if they are lazy. Opinions on how to go about this? I
22580 know this topic has been asked before and I know your not going to make it
22581 part of your code, I just wanted to know from the people who know the code
22582 really well what the best route to take would be to do the least amount of
22583 damage. (And if someone has done this.. please let me know what you did,
22584 examples would rock)
22592 ----------------------------------------------------------
22594 | The Whitewolf of Immyrr |
22595 | <elric@elric.net> |
22596 | http://www.melnibone.net |
22597 | Disclaimer: Any opinions expressed here are |
22598 | from my dog. Any liabilities fall to the dog. |
22599 -----------------------------------------------------------
22602 From Craig at chatspike.net Wed Sep 3 21:18:29 2003
22603 From: Craig at chatspike.net (Craig McLure)
22604 Date: Sat Oct 23 23:09:58 2004
22605 Subject: [IRCServices Coding] Which route to take - Module?
22606 Message-ID: <20030904041818.TXAK19019.mta3-svc.business.ntl.com@i-br0ked-it>
22608 lol, Our help no good? :P
22610 i still say module with seperate database (with the nickgroup, and if this option is on or off (This saves having to modify the main nick.db) , somehow extending the /ns SET command to include a new option.. and replacing what ever function sends notices with something that uses an if to query your new database..
22612 Dont ask me for source on this.. i'm just theorising :)
22614 /****************************************
22615 * Craig "FrostyCoolSlug" McLure
22616 ************* - SpamBox - **************
22617 * InspIRCd - http://www.inspircd.org
22618 * ChatSpike - http://www.chatspike.net
22619 * WinBot - http://www.winbot.co.uk
22620 ****************************************/
22622 /****************************************
22623 * From - Brent DiNicola <ircserv@elric.net>
22624 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
22625 * Sent - 2003-09-03 @ 22:49:00
22626 * Subject - [IRCServices Coding] Which route to take - Module?
22627 ****************************************/
22629 /****** - Begin Original Message - ******/
22631 >It wasn't an easy subject to sum up in just a few words.
22633 >I am wanting to do something to the ircservices code, I want to change
22634 >the way the notice() works. I know that modifying the send.c would be
22635 >very frowned upon and then I got to thinking and had suggested that I
22636 >maybe make a module to keep the information for me. I know it's against
22637 >the RFC, but I am pressed against a brick wall here, I have to give the users
22638 >an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
22639 >I would like to give them the option of turning on PRIVMSG but have NOTICE
22640 >be the default, that would get the lazy people to use NOTICE. Eventually
22641 >getting rid of this problem. In the mean time, I was thinking what is the best
22642 >way to go about this without causing trouble for me and anyone else who has
22643 >to deal with this code. Is it possible or even suggested to make a module that
22644 >would replace the notice() from send.c with it's own, leaving the code in
22646 >alone and not causing troubles down the road. Suggestions were that I make a
22647 >module that kept the info for each nick's setting and then if I could override
22648 >the notice() and notice_lang() and notice_help() in send.c that would keep
22650 >other code clean and not cause other troubles. I want to know what the best
22651 >way to do this would be, I know it's against RFC but I want to move to newer
22652 >services than the 1.4.3pre4 that we are using now and add modules so that I
22653 >can do things down the line. They are used to having PRIVMSG and I can't just
22654 >change it without running people off, so if I can make PRIVMSG an option
22655 >then I can't be blamed if they are lazy. Opinions on how to go about this? I
22656 >know this topic has been asked before and I know your not going to make it
22657 >part of your code, I just wanted to know from the people who know the code
22658 >really well what the best route to take would be to do the least amount of
22659 >damage. (And if someone has done this.. please let me know what you did,
22660 >examples would rock)
22668 >----------------------------------------------------------
22669 >| Brent DiNicola |
22670 >| The Whitewolf of Immyrr |
22671 >| <elric@elric.net> |
22672 >| http://www.melnibone.net |
22673 >| Disclaimer: Any opinions expressed here are |
22674 >| from my dog. Any liabilities fall to the dog. |
22675 >-----------------------------------------------------------
22677 >------------------------------------------------------------------
22678 >To unsubscribe or change your subscription options, visit:
22679 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
22682 /******* - End Original Message - *******/
22687 From uhc0 at rz.uni-karlsruhe.de Thu Sep 4 01:34:06 2003
22688 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu)
22689 Date: Sat Oct 23 23:09:58 2004
22690 Subject: [IRCServices Coding] Which route to take - Module?
22691 In-Reply-To: <5.2.1.1.0.20030903223929.016e4648@mail.elric.net>
22692 References: <5.2.1.1.0.20030903223929.016e4648@mail.elric.net>
22693 Message-ID: <1062664383.1917.15.camel@dreadnought.hadiko.de>
22697 Long question; long answer.
22698 First of all, you must come off the thoughts of "Against the RFC".
22699 Why? Because, tons of irc servers available do provide techniques, which
22700 do not appear, or appear differently on the irc RFC, so that by design
22701 these ircds are also against it. In most of the cases, these changes
22702 reflect themselves in their appropriate server-to-server protocols, and
22703 become transient to the clients, so that on client side, the protocol
22704 remains original. This is also the only way of ensuring that all of the
22705 clients can work with a specific irc daemon.
22707 The issue, why PRIVMSG instead of NOTICE is bad, does also result from
22708 the client-to-server part of the RFC. And it has a reason. Consider two
22709 automated clients (bots, services, etc) talking to each other with
22710 PRIVMSG, and saying things like:
22711 <NickServ> otherwise, I change your nick.
22712 <MyBot> Unknown command otherwise. Please repeat your query.
22713 <NickServ> Unknown command UNKNOWN.
22714 <MyBot> Unknown command unknown. Please repeat your query.
22715 <NickServ> Unknown command UNKNOWN.
22716 <MyBot> Unknown command unknown. Please repeat your query.
22717 <NickServ> Unknown command UNKNOWN.
22718 <MyBot> Unknown command unknown. Please repeat your query.
22719 <NickServ> Unknown command UNKNOWN.
22720 <MyBot> Unknown command unknown. Please repeat your query.
22723 Do you understand, what problem may conclude due to PRIVMSG? RFC says
22724 clearly, that clients shall not generate automatic replies to NOTICES.
22725 That way, your bot would not "talk" to NickServ after a NOTICE anymore.
22728 The most easy implementation of this is creating a NF_USE_PRIVMSG flag,
22729 with a value far greater than any of the built-in, so that in future
22730 this flag does not collide with any of the original flags.
22732 Then you create the new SET command for this, as well as its help text,
22733 primarily in the english language file. That part of the work is
22736 Afterwards, you should modify notice_lang, and check for the
22737 NF_USE_PRIVMSG flag of the "ngi" being used; and if true, send PRIVMSG
22738 instead. The same for notice_help. And your case could be marked as
22741 Do keep in mind that requesting support for modified services versions
22742 are subject to be ignored.
22747 On Thu, 2003-09-04 at 05:49, Brent DiNicola wrote:
22748 > It wasn't an easy subject to sum up in just a few words.
22750 > I am wanting to do something to the ircservices code, I want to change
22751 > the way the notice() works. I know that modifying the send.c would be
22752 > very frowned upon and then I got to thinking and had suggested that I
22753 > maybe make a module to keep the information for me. I know it's against
22754 > the RFC, but I am pressed against a brick wall here, I have to give the users
22755 > an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
22756 > I would like to give them the option of turning on PRIVMSG but have NOTICE
22757 > be the default, that would get the lazy people to use NOTICE. Eventually
22758 > getting rid of this problem. In the mean time, I was thinking what is the best
22759 > way to go about this without causing trouble for me and anyone else who has
22760 > to deal with this code. Is it possible or even suggested to make a module that
22761 > would replace the notice() from send.c with it's own, leaving the code in
22763 > alone and not causing troubles down the road. Suggestions were that I make a
22764 > module that kept the info for each nick's setting and then if I could override
22765 > the notice() and notice_lang() and notice_help() in send.c that would keep
22767 > other code clean and not cause other troubles. I want to know what the best
22768 > way to do this would be, I know it's against RFC but I want to move to newer
22769 > services than the 1.4.3pre4 that we are using now and add modules so that I
22770 > can do things down the line. They are used to having PRIVMSG and I can't just
22771 > change it without running people off, so if I can make PRIVMSG an option
22772 > then I can't be blamed if they are lazy. Opinions on how to go about this? I
22773 > know this topic has been asked before and I know your not going to make it
22774 > part of your code, I just wanted to know from the people who know the code
22775 > really well what the best route to take would be to do the least amount of
22776 > damage. (And if someone has done this.. please let me know what you did,
22777 > examples would rock)
22785 > ----------------------------------------------------------
22786 > | Brent DiNicola |
22787 > | The Whitewolf of Immyrr |
22788 > | <elric@elric.net> |
22789 > | http://www.melnibone.net |
22790 > | Disclaimer: Any opinions expressed here are |
22791 > | from my dog. Any liabilities fall to the dog. |
22792 > -----------------------------------------------------------
22794 > ------------------------------------------------------------------
22795 > To unsubscribe or change your subscription options, visit:
22796 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
22798 ------------------------------------------------------------------
22799 | Yusuf Iskenderoglu | You get to meet all sorts, |
22800 | eMail - uhc0@stud.uni-karlsruhe.de| in this line of work... |
22801 | eMail - s_iskend@ira.uka.de | |
22802 | ICQ UIN : 20587464 \ TimeMr14C | |
22803 ------------------------------------------------------------------
22806 From griever at t2n.org Thu Sep 4 13:31:44 2003
22807 From: griever at t2n.org (Robert F Merrill)
22808 Date: Sat Oct 23 23:09:59 2004
22809 Subject: [IRCServices Coding] Which route to take - Module?
22810 References: <5.2.1.1.0.20030903223929.016e4648@mail.elric.net>
22811 Message-ID: <3F57A0BA.9080909@t2n.org>
22813 Brent DiNicola wrote:
22815 > It wasn't an easy subject to sum up in just a few words.
22817 > I am wanting to do something to the ircservices code, I want to change
22818 > the way the notice() works. I know that modifying the send.c would be
22819 > very frowned upon and then I got to thinking and had suggested that I
22820 > maybe make a module to keep the information for me. I know it's against
22821 > the RFC, but I am pressed against a brick wall here, I have to give
22823 > an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
22824 > I would like to give them the option of turning on PRIVMSG but have
22826 > be the default, that would get the lazy people to use NOTICE. Eventually
22827 > getting rid of this problem. In the mean time, I was thinking what is
22829 > way to go about this without causing trouble for me and anyone else
22831 > to deal with this code. Is it possible or even suggested to make a
22833 > would replace the notice() from send.c with it's own, leaving the code
22835 > alone and not causing troubles down the road. Suggestions were that I
22837 > module that kept the info for each nick's setting and then if I could
22839 > the notice() and notice_lang() and notice_help() in send.c that would
22841 > other code clean and not cause other troubles. I want to know what the
22843 > way to do this would be, I know it's against RFC but I want to move to
22845 > services than the 1.4.3pre4 that we are using now and add modules so
22847 > can do things down the line. They are used to having PRIVMSG and I
22849 > change it without running people off, so if I can make PRIVMSG an option
22850 > then I can't be blamed if they are lazy. Opinions on how to go about
22852 > know this topic has been asked before and I know your not going to
22854 > part of your code, I just wanted to know from the people who know the
22856 > really well what the best route to take would be to do the least
22858 > damage. (And if someone has done this.. please let me know what you did,
22859 > examples would rock)
22867 > ----------------------------------------------------------
22868 > | Brent DiNicola |
22869 > | The Whitewolf of Immyrr |
22870 > | <elric@elric.net> |
22871 > | http://www.melnibone.net |
22872 > | Disclaimer: Any opinions expressed here are |
22873 > | from my dog. Any liabilities fall to the dog. |
22874 > -----------------------------------------------------------
22875 > ------------------------------------------------------------------
22876 > To unsubscribe or change your subscription options, visit:
22877 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
22881 Services is not the place to fix broken clients, and any client which
22882 doesn't display notices correctly is broken. If someone wants to see
22883 notices differently, they can either
22884 a) change their client or in the case of webtv b) change the ircd
22886 services is the wrong thing to change
22889 From Craig at chatspike.net Thu Sep 4 13:52:48 2003
22890 From: Craig at chatspike.net (Craig McLure)
22891 Date: Sat Oct 23 23:09:59 2004
22892 Subject: [IRCServices Coding] Which route to take - Module?
22893 Message-ID: <20030904205232.SDRM23096.mta6-svc.business.ntl.com@i-br0ked-it>
22895 dont mean to sound rude, but this isnt a 'moral' discussion, as it were, rather than saying 'I dont think this needs done', i think it would be best to help him.. its not a discussion on if its right or wrong, its a 'How to do it' discussion.. If you cant contribute to this.. please ignore this 'thread' :p
22897 /****************************************
22898 * Craig "FrostyCoolSlug" McLure
22899 ************* - SpamBox - **************
22900 * InspIRCd - http://www.inspircd.org
22901 * ChatSpike - http://www.chatspike.net
22902 * WinBot - http://www.winbot.co.uk
22903 ****************************************/
22905 /****************************************
22906 * From - Robert F Merrill <griever@t2n.org>
22907 * To - IRC Services Coding Mailing List <ircservices-coding@ircservices.za.net>
22908 * Sent - 2003-09-04 @ 16:29:00
22909 * Subject - Re: [IRCServices Coding] Which route to take - Module?
22910 ****************************************/
22912 /****** - Begin Original Message - ******/
22914 >Brent DiNicola wrote:
22916 >> It wasn't an easy subject to sum up in just a few words.
22918 >> I am wanting to do something to the ircservices code, I want to change
22919 >> the way the notice() works. I know that modifying the send.c would be
22920 >> very frowned upon and then I got to thinking and had suggested that I
22921 >> maybe make a module to keep the information for me. I know it's against
22922 >> the RFC, but I am pressed against a brick wall here, I have to give
22924 >> an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
22925 >> I would like to give them the option of turning on PRIVMSG but have
22927 >> be the default, that would get the lazy people to use NOTICE. Eventually
22928 >> getting rid of this problem. In the mean time, I was thinking what is
22930 >> way to go about this without causing trouble for me and anyone else
22932 >> to deal with this code. Is it possible or even suggested to make a
22934 >> would replace the notice() from send.c with it's own, leaving the code
22936 >> alone and not causing troubles down the road. Suggestions were that I
22938 >> module that kept the info for each nick's setting and then if I could
22940 >> the notice() and notice_lang() and notice_help() in send.c that would
22942 >> other code clean and not cause other troubles. I want to know what the
22944 >> way to do this would be, I know it's against RFC but I want to move to
22946 >> services than the 1.4.3pre4 that we are using now and add modules so
22948 >> can do things down the line. They are used to having PRIVMSG and I
22950 >> change it without running people off, so if I can make PRIVMSG an option
22951 >> then I can't be blamed if they are lazy. Opinions on how to go about
22953 >> know this topic has been asked before and I know your not going to
22955 >> part of your code, I just wanted to know from the people who know the
22957 >> really well what the best route to take would be to do the least
22959 >> damage. (And if someone has done this.. please let me know what you did,
22960 >> examples would rock)
22968 >> ----------------------------------------------------------
22969 >> | Brent DiNicola |
22970 >> | The Whitewolf of Immyrr |
22971 >> | <elric@elric.net> |
22972 >> | http://www.melnibone.net |
22973 >> | Disclaimer: Any opinions expressed here are |
22974 >> | from my dog. Any liabilities fall to the dog. |
22975 >> -----------------------------------------------------------
22976 >> ------------------------------------------------------------------
22977 >> To unsubscribe or change your subscription options, visit:
22978 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
22982 >Services is not the place to fix broken clients, and any client which
22983 >doesn't display notices correctly is broken. If someone wants to see
22984 >notices differently, they can either
22985 >a) change their client or in the case of webtv b) change the ircd
22987 >services is the wrong thing to change
22989 >------------------------------------------------------------------
22990 >To unsubscribe or change your subscription options, visit:
22991 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
22994 /******* - End Original Message - *******/
22999 From quension at mac.com Thu Sep 4 13:54:21 2003
23000 From: quension at mac.com (Trevor Talbot)
23001 Date: Sat Oct 23 23:09:59 2004
23002 Subject: [IRCServices Coding] Which route to take - Module?
23003 In-Reply-To: <3F57A0BA.9080909@t2n.org>
23004 Message-ID: <E8AC4DDC-DF19-11D7-905C-0003938D6866@mac.com>
23006 On Thursday, Sep 4, 2003, at 13:29 US/Pacific, Robert F Merrill wrote:
23008 > Brent DiNicola wrote:
23010 >> It wasn't an easy subject to sum up in just a few words.
23014 > Services is not the place to fix broken clients, and any client which
23015 > doesn't display notices correctly is broken. If someone wants to see
23016 > notices differently, they can either a) change their client or in the
23017 > case of webtv b) change the ircd
23019 > services is the wrong thing to change
23021 And telling someone what they obviously already know is generally not a
23022 good idea. Especially when they spent a very long paragraph defending
23023 their decision in the first place.
23025 This is the coding list, not the feature request list. He asked for
23026 code design approaches, not for political insight.
23031 From diego at redesul.net Thu Sep 18 16:29:40 2003
23032 From: diego at redesul.net (Diego B. Contezini)
23033 Date: Sat Oct 23 23:09:59 2004
23034 Subject: [IRCServices Coding] Re: How to get a core..
23035 Message-ID: <001c01c37e2d$c95d7840$3cc8a8c0@angel>
23037 Oooopz, im answering my ask...
23038 Looking in FAQ, where i should look before ask (sorry), I seen that you need
23039 to change ./configure to drop a core.
23040 If someone more is needing it, is just configure with:
23041 ./configure -dumpcore -cflags -g -defaults
23047 ----- Original Message -----
23048 From: "Diego B. Contezini" <diego@redesul.net>
23049 To: <ircservices-coding@ircservices.za.net>
23050 Sent: Thursday, September 18, 2003 6:35 PM
23051 Subject: How to get a core..
23054 > Hello, im destruct_, im the administrator of the RedeSul Network.
23055 > (irc.redesul.net).
23056 > I'm with 28000 nick registers, sometimes our network get 5500 simultaneous
23057 > users, and we are very happy with your services.
23058 > Im wanting to help to search and stops bugs on ircservices, but i never
23061 > I tryed ulimit -c unlimited before run it, but it never drop a core...
23062 > Someone have any idea about how i can get it, to debug without need to
23064 > the services while debugging?
23065 > Its segfaulting approx. all days, one time for day.. sometimes get 2 days
23066 > without to go down.
23067 > Im with a redhat 9.
23071 > Diego B. Contezini aka destruct_ | irc.redesul.net
23072 > (Sorry for my confuse english.)
23076 From diego at redesul.net Thu Sep 18 17:12:05 2003
23077 From: diego at redesul.net (Diego B. Contezini)
23078 Date: Sat Oct 23 23:09:59 2004
23079 Subject: [IRCServices Coding] How to get a core..
23080 References: <Law14-F109aJWJVUn700006a187@hotmail.com>
23081 Message-ID: <000901c37e2c$b8bd9980$3cc8a8c0@angel>
23083 Hello, im destruct_, im the administrator of the RedeSul Network.
23085 I'm with 28000 nick registers, sometimes our network get 5500 simultaneous
23086 users, and we are very happy with your services.
23087 Im wanting to help to search and stops bugs on ircservices, but i never get
23089 I tryed ulimit -c unlimited before run it, but it never drop a core...
23090 Someone have any idea about how i can get it, to debug without need to break
23091 the services while debugging?
23092 Its segfaulting approx. all days, one time for day.. sometimes get 2 days
23093 without to go down.
23094 Im with a redhat 9.
23098 Diego B. Contezini aka destruct_ | irc.redesul.net
23099 (Sorry for my confuse english.)
23102 From engin at piratetv.net Sun Sep 21 09:37:08 2003
23103 From: engin at piratetv.net (engin@piratetv)
23104 Date: Sat Oct 23 23:09:59 2004
23105 Subject: [IRCServices Coding] operserv
23106 Message-ID: <002101c3805f$0910a4c0$c7cf87d4@ptv91i58zrrpyd>
23110 can anyone help or point me to some good documentation regarding a
23111 version of unreal ircd we are running on a mandrake linux box..im mailing
23112 on behalf of the administrator who usually uses ssh to get into the box
23113 and make changes so im not super technical myself.the issue is with
23114 operserv..i cant access any operserv commands from my machine ( which
23115 is on the same local network as the box running the irc server ) always
23116 get operserv - access denied message..so im assuming it doesent
23117 recognise my remote ip address at an administrator..does anyone know
23118 the right sort of commands to use to set my remote machine to be
23119 recognised as admin or can they point me to any good support docs
23120 as i havent been able to find any yet
23124 -------------- next part --------------
23125 An HTML attachment was scrubbed...
23126 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030921/fdc12b4e/attachment.htm
23127 From Craig at chatspike.net Sun Sep 21 14:28:23 2003
23128 From: Craig at chatspike.net (Craig McLure)
23129 Date: Sat Oct 23 23:09:59 2004
23130 Subject: [IRCServices Coding] operserv
23131 Message-ID: <E1A1Bk4-0001Xo-00@ptb-mailc04.plus.net>
23133 make sure you are on the services administrator list, if you are not, get the root administrator to add you using the command:
23135 [22:27] -OperServ- Syntax: ADMIN ADD nickname
23136 [22:27] -OperServ- ADMIN DEL nickname
23137 [22:27] -OperServ- ADMIN LIST
23139 [22:27] -OperServ- Allows the Services super-user to add or remove nicknames
23140 [22:27] -OperServ- to or from the Services admin list. A user whose nickname
23141 [22:27] -OperServ- is on the Services admin list and who has identified to
23142 [22:27] -OperServ- NickServ will be able to access Services admin commands.
23144 [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the command.
23145 [22:27] -OperServ- All other use limited to Services super-user.
23149 /****************************************
23150 * Craig "FrostyCoolSlug" McLure
23151 ************* - SpamBox - **************
23152 * InspIRCd - http://www.inspircd.org
23153 * ChatSpike - http://www.chatspike.net
23154 * WinBot - http://www.winbot.co.uk
23155 ****************************************/
23157 /****************************************
23158 * From - engin <engin@piratetv.net>
23159 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
23160 * Sent - 2003-09-21 @ 17:40:00
23161 * Subject - [IRCServices Coding] operserv
23162 ****************************************/
23164 /****** - Begin Original Message - ******/
23168 >can anyone help or point me to some good documentation regarding a
23169 >version of unreal ircd we are running on a mandrake linux box..im mailing
23170 >on behalf of the administrator who usually uses ssh to get into the box
23171 >and make changes so im not super technical myself.the issue is with
23172 >operserv..i cant access any operserv commands from my machine ( which
23173 >is on the same local network as the box running the irc server ) always
23174 >get operserv - access denied message..so im assuming it doesent
23175 >recognise my remote ip address at an administrator..does anyone know
23176 >the right sort of commands to use to set my remote machine to be
23177 >recognised as admin or can they point me to any good support docs
23178 >as i havent been able to find any yet
23182 >------------------------------------------------------------------
23183 >To unsubscribe or change your subscription options, visit:
23184 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
23186 /******* - End Original Message - *******/
23190 From saturn at jetirc.net Sun Sep 21 15:24:25 2003
23191 From: saturn at jetirc.net (Saturn)
23192 Date: Sat Oct 23 23:09:59 2004
23193 Subject: [IRCServices Coding] operserv
23194 References: <002101c3805f$0910a4c0$c7cf87d4@ptv91i58zrrpyd>
23195 Message-ID: <002b01c3808e$f2590ee0$6401a8c0@turby>
23197 Contact me directly... I have quite a bit of experience with unreal and these services...
23201 ----- Original Message -----
23202 From: engin@piratetv
23203 To: ircservices-coding@ircservices.za.net
23204 Sent: Sunday, September 21, 2003 9:40 AM
23205 Subject: [IRCServices Coding] operserv
23210 can anyone help or point me to some good documentation regarding a
23211 version of unreal ircd we are running on a mandrake linux box..im mailing
23212 on behalf of the administrator who usually uses ssh to get into the box
23213 and make changes so im not super technical myself.the issue is with
23214 operserv..i cant access any operserv commands from my machine ( which
23215 is on the same local network as the box running the irc server ) always
23216 get operserv - access denied message..so im assuming it doesent
23217 recognise my remote ip address at an administrator..does anyone know
23218 the right sort of commands to use to set my remote machine to be
23219 recognised as admin or can they point me to any good support docs
23220 as i havent been able to find any yet
23227 ------------------------------------------------------------------------------
23230 ------------------------------------------------------------------
23231 To unsubscribe or change your subscription options, visit:
23232 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
23233 -------------- next part --------------
23234 An HTML attachment was scrubbed...
23235 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030921/ca188e06/attachment.html
23236 From saturn at jetirc.net Sun Sep 21 17:14:42 2003
23237 From: saturn at jetirc.net (Saturn)
23238 Date: Sat Oct 23 23:09:59 2004
23239 Subject: [IRCServices Coding] operserv
23240 References: <E1A1Bk4-0001Xo-00@ptb-mailc04.plus.net>
23241 Message-ID: <000d01c3809e$5b9d2800$6401a8c0@turby>
23243 Not to mention the obvious: You need to have an O:line and be opered up
23244 before Operserv will even listen to your commands without access denied....
23246 ----- Original Message -----
23247 From: "Craig McLure" <Craig@chatspike.net>
23248 To: "IRC Services Coding Mailing List"
23249 <ircservices-coding@ircservices.za.net>
23250 Sent: Sunday, September 21, 2003 3:28 PM
23251 Subject: Re: [IRCServices Coding] operserv
23254 make sure you are on the services administrator list, if you are not, get
23255 the root administrator to add you using the command:
23257 [22:27] -OperServ- Syntax: ADMIN ADD nickname
23258 [22:27] -OperServ- ADMIN DEL nickname
23259 [22:27] -OperServ- ADMIN LIST
23261 [22:27] -OperServ- Allows the Services super-user to add or remove nicknames
23262 [22:27] -OperServ- to or from the Services admin list. A user whose nickname
23263 [22:27] -OperServ- is on the Services admin list and who has identified to
23264 [22:27] -OperServ- NickServ will be able to access Services admin commands.
23266 [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
23268 [22:27] -OperServ- All other use limited to Services super-user.
23272 /****************************************
23273 * Craig "FrostyCoolSlug" McLure
23274 ************* - SpamBox - **************
23275 * InspIRCd - http://www.inspircd.org
23276 * ChatSpike - http://www.chatspike.net
23277 * WinBot - http://www.winbot.co.uk
23278 ****************************************/
23280 /****************************************
23281 * From - engin <engin@piratetv.net>
23282 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
23283 * Sent - 2003-09-21 @ 17:40:00
23284 * Subject - [IRCServices Coding] operserv
23285 ****************************************/
23287 /****** - Begin Original Message - ******/
23291 >can anyone help or point me to some good documentation regarding a
23292 >version of unreal ircd we are running on a mandrake linux box..im mailing
23293 >on behalf of the administrator who usually uses ssh to get into the box
23294 >and make changes so im not super technical myself.the issue is with
23295 >operserv..i cant access any operserv commands from my machine ( which
23296 >is on the same local network as the box running the irc server ) always
23297 >get operserv - access denied message..so im assuming it doesent
23298 >recognise my remote ip address at an administrator..does anyone know
23299 >the right sort of commands to use to set my remote machine to be
23300 >recognised as admin or can they point me to any good support docs
23301 >as i havent been able to find any yet
23305 >------------------------------------------------------------------
23306 >To unsubscribe or change your subscription options, visit:
23307 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
23309 /******* - End Original Message - *******/
23312 ------------------------------------------------------------------
23313 To unsubscribe or change your subscription options, visit:
23314 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
23317 From engin at piratetv.net Mon Sep 22 05:13:57 2003
23318 From: engin at piratetv.net (engin@piratetv)
23319 Date: Sat Oct 23 23:09:59 2004
23320 Subject: [IRCServices Coding] Re: IRCServices-Coding Digest, Vol 8, Issue 5
23321 References: <20030922120923.425971706D@snow.fingers.co.za>
23322 Message-ID: <003c01c38103$73a516f0$c7cf87d4@ptv91i58zrrpyd>
23324 many thanks for the replies..im going to get the info to the
23325 root administrator now and ill let you know how i get
23332 ----- Original Message -----
23333 From: <ircservices-coding-request@ircservices.za.net>
23334 To: <ircservices-coding@ircservices.za.net>
23335 Sent: Monday, September 22, 2003 1:09 PM
23336 Subject: IRCServices-Coding Digest, Vol 8, Issue 5
23339 > Send IRCServices-Coding mailing list submissions to
23340 > ircservices-coding@ircservices.za.net
23342 > To subscribe or unsubscribe via the World Wide Web, visit
23343 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
23344 > or, via email, send a message with subject or body 'help' to
23345 > ircservices-coding-request@ircservices.za.net
23347 > You can reach the person managing the list at
23348 > ircservices-coding-owner@ircservices.za.net
23350 > When replying, please edit your Subject line so it is more specific
23351 > than "Re: Contents of IRCServices-Coding digest..."
23356 > 1. operserv (engin@piratetv)
23357 > 2. Re: operserv (Craig McLure)
23358 > 3. Re: operserv (Saturn)
23359 > 4. Re: operserv (Saturn)
23362 > ----------------------------------------------------------------------
23365 > Date: Sun, 21 Sep 2003 17:40:15 +0100
23366 > From: "engin@piratetv" <engin@piratetv.net>
23367 > Subject: [IRCServices Coding] operserv
23368 > To: <ircservices-coding@ircservices.za.net>
23369 > Message-ID: <002101c3805f$0910a4c0$c7cf87d4@ptv91i58zrrpyd>
23370 > Content-Type: text/plain; charset="iso-8859-1"
23374 > can anyone help or point me to some good documentation regarding a
23375 > version of unreal ircd we are running on a mandrake linux box..im mailing
23376 > on behalf of the administrator who usually uses ssh to get into the box
23377 > and make changes so im not super technical myself.the issue is with
23378 > operserv..i cant access any operserv commands from my machine ( which
23379 > is on the same local network as the box running the irc server ) always
23380 > get operserv - access denied message..so im assuming it doesent
23381 > recognise my remote ip address at an administrator..does anyone know
23382 > the right sort of commands to use to set my remote machine to be
23383 > recognised as admin or can they point me to any good support docs
23384 > as i havent been able to find any yet
23388 > -------------- next part --------------
23389 > An HTML attachment was scrubbed...
23391 http://snow.fingers.co.za/pipermail/ircservices-coding/attachments/20030921/
23392 fdc12b4e/attachment-0001.htm
23394 > ------------------------------
23397 > Date: Sun, 21 Sep 2003 22:28:13 +0000
23398 > From: "Craig McLure" <Craig@chatspike.net>
23399 > Subject: Re: [IRCServices Coding] operserv
23400 > To: IRC Services Coding Mailing List
23401 > <ircservices-coding@ircservices.za.net>
23402 > Message-ID: <E1A1Bk4-0001Xo-00@ptb-mailc04.plus.net>
23403 > Content-Type: text/plain; charset="us-ascii"
23405 > make sure you are on the services administrator list, if you are not, get
23406 the root administrator to add you using the command:
23408 > [22:27] -OperServ- Syntax: ADMIN ADD nickname
23409 > [22:27] -OperServ- ADMIN DEL nickname
23410 > [22:27] -OperServ- ADMIN LIST
23411 > [22:27] -OperServ-
23412 > [22:27] -OperServ- Allows the Services super-user to add or remove
23414 > [22:27] -OperServ- to or from the Services admin list. A user whose
23416 > [22:27] -OperServ- is on the Services admin list and who has identified to
23417 > [22:27] -OperServ- NickServ will be able to access Services admin
23419 > [22:27] -OperServ-
23420 > [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
23422 > [22:27] -OperServ- All other use limited to Services super-user.
23426 > /****************************************
23427 > * Craig "FrostyCoolSlug" McLure
23428 > ************* - SpamBox - **************
23429 > * InspIRCd - http://www.inspircd.org
23430 > * ChatSpike - http://www.chatspike.net
23431 > * WinBot - http://www.winbot.co.uk
23432 > ****************************************/
23434 > /****************************************
23435 > * From - engin <engin@piratetv.net>
23436 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
23437 > * Sent - 2003-09-21 @ 17:40:00
23438 > * Subject - [IRCServices Coding] operserv
23439 > ****************************************/
23441 > /****** - Begin Original Message - ******/
23445 > >can anyone help or point me to some good documentation regarding a
23446 > >version of unreal ircd we are running on a mandrake linux box..im mailing
23447 > >on behalf of the administrator who usually uses ssh to get into the box
23448 > >and make changes so im not super technical myself.the issue is with
23449 > >operserv..i cant access any operserv commands from my machine ( which
23450 > >is on the same local network as the box running the irc server ) always
23451 > >get operserv - access denied message..so im assuming it doesent
23452 > >recognise my remote ip address at an administrator..does anyone know
23453 > >the right sort of commands to use to set my remote machine to be
23454 > >recognised as admin or can they point me to any good support docs
23455 > >as i havent been able to find any yet
23459 > >------------------------------------------------------------------
23460 > >To unsubscribe or change your subscription options, visit:
23461 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
23463 > /******* - End Original Message - *******/
23467 > ------------------------------
23470 > Date: Sun, 21 Sep 2003 15:23:13 -0700
23471 > From: "Saturn" <saturn@jetirc.net>
23472 > Subject: Re: [IRCServices Coding] operserv
23473 > To: "IRC Services Coding Mailing List"
23474 > <ircservices-coding@ircservices.za.net>
23475 > Message-ID: <002b01c3808e$f2590ee0$6401a8c0@turby>
23476 > Content-Type: text/plain; charset="iso-8859-1"
23478 > Contact me directly... I have quite a bit of experience with unreal and
23483 > ----- Original Message -----
23484 > From: engin@piratetv
23485 > To: ircservices-coding@ircservices.za.net
23486 > Sent: Sunday, September 21, 2003 9:40 AM
23487 > Subject: [IRCServices Coding] operserv
23492 > can anyone help or point me to some good documentation regarding a
23493 > version of unreal ircd we are running on a mandrake linux box..im
23495 > on behalf of the administrator who usually uses ssh to get into the box
23496 > and make changes so im not super technical myself.the issue is with
23497 > operserv..i cant access any operserv commands from my machine ( which
23498 > is on the same local network as the box running the irc server ) always
23499 > get operserv - access denied message..so im assuming it doesent
23500 > recognise my remote ip address at an administrator..does anyone know
23501 > the right sort of commands to use to set my remote machine to be
23502 > recognised as admin or can they point me to any good support docs
23503 > as i havent been able to find any yet
23510 > --------------------------------------------------------------------------
23514 > ------------------------------------------------------------------
23515 > To unsubscribe or change your subscription options, visit:
23516 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
23517 > -------------- next part --------------
23518 > An HTML attachment was scrubbed...
23520 http://snow.fingers.co.za/pipermail/ircservices-coding/attachments/20030921/
23521 ca188e06/attachment-0001.htm
23523 > ------------------------------
23526 > Date: Sun, 21 Sep 2003 17:13:31 -0700
23527 > From: "Saturn" <saturn@jetirc.net>
23528 > Subject: Re: [IRCServices Coding] operserv
23529 > To: "IRC Services Coding Mailing List"
23530 > <ircservices-coding@ircservices.za.net>
23531 > Message-ID: <000d01c3809e$5b9d2800$6401a8c0@turby>
23532 > Content-Type: text/plain; charset="iso-8859-1"
23534 > Not to mention the obvious: You need to have an O:line and be opered up
23535 > before Operserv will even listen to your commands without access
23538 > ----- Original Message -----
23539 > From: "Craig McLure" <Craig@chatspike.net>
23540 > To: "IRC Services Coding Mailing List"
23541 > <ircservices-coding@ircservices.za.net>
23542 > Sent: Sunday, September 21, 2003 3:28 PM
23543 > Subject: Re: [IRCServices Coding] operserv
23546 > make sure you are on the services administrator list, if you are not, get
23547 > the root administrator to add you using the command:
23549 > [22:27] -OperServ- Syntax: ADMIN ADD nickname
23550 > [22:27] -OperServ- ADMIN DEL nickname
23551 > [22:27] -OperServ- ADMIN LIST
23552 > [22:27] -OperServ-
23553 > [22:27] -OperServ- Allows the Services super-user to add or remove
23555 > [22:27] -OperServ- to or from the Services admin list. A user whose
23557 > [22:27] -OperServ- is on the Services admin list and who has identified to
23558 > [22:27] -OperServ- NickServ will be able to access Services admin
23560 > [22:27] -OperServ-
23561 > [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
23563 > [22:27] -OperServ- All other use limited to Services super-user.
23567 > /****************************************
23568 > * Craig "FrostyCoolSlug" McLure
23569 > ************* - SpamBox - **************
23570 > * InspIRCd - http://www.inspircd.org
23571 > * ChatSpike - http://www.chatspike.net
23572 > * WinBot - http://www.winbot.co.uk
23573 > ****************************************/
23575 > /****************************************
23576 > * From - engin <engin@piratetv.net>
23577 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
23578 > * Sent - 2003-09-21 @ 17:40:00
23579 > * Subject - [IRCServices Coding] operserv
23580 > ****************************************/
23582 > /****** - Begin Original Message - ******/
23586 > >can anyone help or point me to some good documentation regarding a
23587 > >version of unreal ircd we are running on a mandrake linux box..im mailing
23588 > >on behalf of the administrator who usually uses ssh to get into the box
23589 > >and make changes so im not super technical myself.the issue is with
23590 > >operserv..i cant access any operserv commands from my machine ( which
23591 > >is on the same local network as the box running the irc server ) always
23592 > >get operserv - access denied message..so im assuming it doesent
23593 > >recognise my remote ip address at an administrator..does anyone know
23594 > >the right sort of commands to use to set my remote machine to be
23595 > >recognised as admin or can they point me to any good support docs
23596 > >as i havent been able to find any yet
23600 > >------------------------------------------------------------------
23601 > >To unsubscribe or change your subscription options, visit:
23602 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
23604 > /******* - End Original Message - *******/
23607 > ------------------------------------------------------------------
23608 > To unsubscribe or change your subscription options, visit:
23609 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
23612 > ------------------------------
23614 > _______________________________________________
23615 > IRCServices-Coding mailing list
23616 > IRCServices-Coding@ircservices.za.net
23617 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
23620 > End of IRCServices-Coding Digest, Vol 8, Issue 5
23621 > ************************************************
23624 From diego at redesul.net Sun Oct 5 22:45:19 2003
23625 From: diego at redesul.net (Diego B. Contezini)
23626 Date: Sat Oct 23 23:09:59 2004
23627 Subject: [IRCServices Coding] Bug....
23628 References: <E1A1Bk4-0001Xo-00@ptb-mailc04.plus.net>
23629 <000d01c3809e$5b9d2800$6401a8c0@turby>
23630 Message-ID: <003b01c38b91$5f6a32e0$3cc8a8c0@angel>
23632 Sometimes has occur this bug, last 1 year....
23633 on a network with 30k registers, its happening with latency of 3.. 4
23636 someone have any idea?
23638 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
23639 av=0xbfffeec8) at channels.c:278
23642 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
23643 av=0xbfffeec8) at channels.c:278
23644 chan = (Channel *) 0xa97b6b8
23645 s = 0x20656c62 <Address 0x20656c62 out of bounds>
23647 modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
23648 #1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:680
23650 "-isl\000\037\006\bp?????????@???\006\b\000\000\000\000\000\000\000B\000\000
23651 \000\0007 \006\b\003\000\000\000TZ\000\000????????????
23652 ?????????\001\200??????@???\006\b@???\006\b@???\006\b@???\006\bO???\006\b@\0
23653 02\a\b@???\006\b@\002\a\b", '\0' <repeats 20 times>,
23654 "\027\000\000\000\000\000\000\000W???\022B\000\000\000\000\000\000\000\000\0
23655 05\000\000\000\210o\a\bTZ\000\000\000\000\000\000???????????????<\023B\001\0
23656 00\000\000???????????????m\tBd???\022B???q\a\b\v???\006B\024\032\023B\024\03
23657 2\023B3\035\rB\024\032\023B??????\006B\003\000\000\000????????????\027\000\0
23658 00\000\000\000\000\000\024\032"...
23659 s = 0xbfffeef0 "-isl"
23660 argv = {0xa97b6c0 "#young", 0x20656c62 <Address 0x20656c62 out of
23662 0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 out
23663 of bounds>, 0x42133cec "\004", 0xbffff1fc "",
23664 0x4204533d "\201?????????\016", 0x42131a14 " \031\023B???h\001@`???"}
23668 #2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
23672 md = (struct modedata *) 0x0
23677 #3 0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at main.c:269
23679 now_msec = 241253125
23680 last_update = 1065392973
23681 last_check = 241252363
23682 #4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
23683 No symbol table info available.
23688 From achurch at achurch.org Mon Oct 6 00:41:54 2003
23689 From: achurch at achurch.org (Andrew Church)
23690 Date: Sat Oct 23 23:09:59 2004
23691 Subject: [IRCServices Coding] Bug....
23692 In-Reply-To: <003b01c38b91$5f6a32e0$3cc8a8c0@angel>
23693 Message-ID: <3f811cad.24262@achurch.org>
23698 achurch@achurch.org
23699 http://achurch.org/
23701 >Sometimes has occur this bug, last 1 year....
23702 >on a network with 30k registers, its happening with latency of 3.. 4
23705 >someone have any idea?
23707 >#0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
23708 >av=0xbfffeec8) at channels.c:278
23711 >#0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
23712 >av=0xbfffeec8) at channels.c:278
23713 > chan = (Channel *) 0xa97b6b8
23714 > s = 0x20656c62 <Address 0x20656c62 out of bounds>
23716 > modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
23717 >#1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:68
23720 >"-isl\000\037\006\bp���@�\006\b\000\000\0
23721 >00\000\000\000\000B\000\000
23722 >\000\0007 \006\b\003\000\000\000TZ\000\000���ï¿
23724 >���\001\200��@�\006\b@ï
23725 >¿½\006\b@�\006\b@�\006\bO�\006\b@\0
23726 >02\a\b@�\006\b@\002\a\b", '\0' <repeats 20 times>,
23727 >"\027\000\000\000\000\000\000\000W�\022B\000\000\000\000\000\000\
23729 >05\000\000\000\210o\a\bTZ\000\000\000\000\000\000��ï¿
23730 >½ï¿½ï¿½<\023B\001\0
23731 >00\000\000�����m\tBd�\022
23732 >B�q\a\b\v�\006B\024\032\023B\024\03
23733 >2\023B3\035\rB\024\032\023B��\006B\003\000\000\000�
23735 >00\000\000\000\000\000\024\032"...
23736 > s = 0xbfffeef0 "-isl"
23737 > argv = {0xa97b6c0 "#young", 0x20656c62 <Address 0x20656c62 out
23740 > 0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 o
23742 >of bounds>, 0x42133cec "\004", 0xbffff1fc "",
23743 > 0x4204533d "\201���\016", 0x42131a14 " \031\023
23748 >#2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:32
23753 > md = (struct modedata *) 0x0
23758 >#3 0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at ma
23761 > now_msec = 241253125
23762 > last_update = 1065392973
23763 > last_check = 241252363
23764 >#4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
23765 >No symbol table info available.
23769 >------------------------------------------------------------------
23770 >To unsubscribe or change your subscription options, visit:
23771 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
23773 From diego at redesul.net Mon Oct 6 02:36:40 2003
23774 From: diego at redesul.net (Diego B. Contezini)
23775 Date: Sat Oct 23 23:09:59 2004
23776 Subject: [IRCServices Coding] Bug....
23777 References: <3f811cad.24262@achurch.org>
23778 Message-ID: <005501c38bed$4c9b1dd0$3cc8a8c0@angel>
23781 ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
23785 Its the last version.......
23788 ----- Original Message -----
23789 From: "Andrew Church" <achurch@achurch.org>
23790 To: <ircservices-coding@ircservices.za.net>
23791 Sent: Monday, October 06, 2003 4:41 AM
23792 Subject: Re: [IRCServices Coding] Bug....
23798 > achurch@achurch.org
23799 > http://achurch.org/
23801 > >Sometimes has occur this bug, last 1 year....
23802 > >on a network with 30k registers, its happening with latency of 3.. 4
23805 > >someone have any idea?
23807 > >#0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
23808 > >av=0xbfffeec8) at channels.c:278
23809 > >278 while (*s) {
23811 > >#0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
23812 > >av=0xbfffeec8) at channels.c:278
23813 > > chan = (Channel *) 0xa97b6b8
23814 > > s = 0x20656c62 <Address 0x20656c62 out of bounds>
23816 > > modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
23817 > >#1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:68
23820 > >"-isl\000\037\006\bp?????????@???\006\b\000\000\0
23821 > >00\000\000\000\000B\000\000
23822 > >\000\0007 \006\b\003\000\000\000TZ\000\000???????????
23824 > >?????????\001\200??????@???\006\b@?
23825 > >??\006\b@???\006\b@???\006\bO???\006\b@\0
23826 > >02\a\b@???\006\b@\002\a\b", '\0' <repeats 20 times>,
23827 > >"\027\000\000\000\000\000\000\000W???\022B\000\000\000\000\000\000\
23829 > >05\000\000\000\210o\a\bTZ\000\000\000\000\000\000????????
23830 > >???????<\023B\001\0
23831 > >00\000\000???????????????m\tBd???\022
23832 > >B???q\a\b\v???\006B\024\032\023B\024\03
23833 > >2\023B3\035\rB\024\032\023B??????\006B\003\000\000\000???
23834 > >?????????\027\000\0
23835 > >00\000\000\000\000\000\024\032"...
23836 > > s = 0xbfffeef0 "-isl"
23837 > > argv = {0xa97b6c0 "#young", 0x20656c62 <Address 0x20656c62 out
23840 > > 0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 o
23842 > >of bounds>, 0x42133cec "\004", 0xbffff1fc "",
23843 > > 0x4204533d "\201?????????\016", 0x42131a14 " \031\023
23844 > >B???h\001@`???"}
23848 > >#2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:32
23852 > > modes_orig = 0x0
23853 > > md = (struct modedata *) 0x0
23858 > >#3 0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at ma
23860 > > now = 1065393142
23861 > > now_msec = 241253125
23862 > > last_update = 1065392973
23863 > > last_check = 241252363
23864 > >#4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
23865 > >No symbol table info available.
23869 > >------------------------------------------------------------------
23870 > >To unsubscribe or change your subscription options, visit:
23871 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
23872 > ------------------------------------------------------------------
23873 > To unsubscribe or change your subscription options, visit:
23874 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
23878 From achurch at achurch.org Mon Oct 6 06:45:43 2003
23879 From: achurch at achurch.org (Andrew Church)
23880 Date: Sat Oct 23 23:09:59 2004
23881 Subject: [IRCServices Coding] Bug....
23882 In-Reply-To: <005501c38bed$4c9b1dd0$3cc8a8c0@angel>
23883 Message-ID: <3f8171f9.25006@achurch.org>
23886 >ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
23890 >Its the last version.......
23892 Then send a full debug log (from startup to crash), or I can't help.
23895 achurch@achurch.org
23896 http://achurch.org/
23898 From diego at redesul.net Mon Oct 6 17:16:29 2003
23899 From: diego at redesul.net (Diego B. Contezini)
23900 Date: Sat Oct 23 23:09:59 2004
23901 Subject: [IRCServices Coding] Bug....
23902 References: <3f8171f9.25006@achurch.org>
23903 Message-ID: <010601c38c68$2e6dc8a0$3cc8a8c0@angel>
23905 And how should be this log? i sent a backtrace......
23908 ----- Original Message -----
23909 From: "Andrew Church" <achurch@achurch.org>
23910 To: <ircservices-coding@ircservices.za.net>
23911 Sent: Monday, October 06, 2003 10:44 AM
23912 Subject: Re: [IRCServices Coding] Bug....
23916 > >ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
23917 > >18:41:36 BRT 2003
23920 > >Its the last version.......
23922 > Then send a full debug log (from startup to crash), or I can't help.
23925 > achurch@achurch.org
23926 > http://achurch.org/
23927 > ------------------------------------------------------------------
23928 > To unsubscribe or change your subscription options, visit:
23929 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
23933 From achurch at achurch.org Mon Oct 6 19:32:07 2003
23934 From: achurch at achurch.org (Andrew Church)
23935 Date: Sat Oct 23 23:09:59 2004
23936 Subject: [IRCServices Coding] Bug....
23937 In-Reply-To: <010601c38c68$2e6dc8a0$3cc8a8c0@angel>
23938 Message-ID: <3f822598.26100@achurch.org>
23940 >And how should be this log? i sent a backtrace......
23945 achurch@achurch.org
23946 http://achurch.org/
23948 From diego at redesul.net Mon Oct 6 22:36:40 2003
23949 From: diego at redesul.net (Diego B. Contezini)
23950 Date: Sat Oct 23 23:09:59 2004
23951 Subject: [IRCServices Coding] Bug....
23952 References: <3f822598.26100@achurch.org>
23953 Message-ID: <011601c38c94$ebc3ec00$3cc8a8c0@angel>
23956 If i start it with -debug it will get me gb's of information. This occur
23957 after days with services up, i will try to run it into a screen.... with
23962 ----- Original Message -----
23963 From: "Andrew Church" <achurch@achurch.org>
23964 To: <ircservices-coding@ircservices.za.net>
23965 Sent: Monday, October 06, 2003 11:31 PM
23966 Subject: Re: [IRCServices Coding] Bug....
23969 > >And how should be this log? i sent a backtrace......
23974 > achurch@achurch.org
23975 > http://achurch.org/
23976 > ------------------------------------------------------------------
23977 > To unsubscribe or change your subscription options, visit:
23978 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
23982 From saturn at jetirc.net Fri Oct 10 15:48:47 2003
23983 From: saturn at jetirc.net (Saturn)
23984 Date: Sat Oct 23 23:09:59 2004
23985 Subject: [IRCServices Coding] Akill problem in 5.0.22
23986 References: <14C7EDD0-DC1B-11D7-8505-0003938D6866@mac.com>
23987 Message-ID: <004001c38f80$9f635960$6401a8c0@turby>
23989 Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
23990 duplicate exit system notice that happens in 3.1.6).
23992 I just today added an akill (+0 time) .. I DO have the immediate auto kill
23993 option un-commented in the modules.conf, but it still didn't bother scanning
23994 for victims matching my akill mask nor did it actually KILL anyone... It
23995 works if they are manually killed and then try to re-connect, but I thought
23996 that new option was so Services will immediately scan for and kill anyone
23997 online that matches the mask as soon as the new akill is added...
23999 First: IS that what it's supposed to do?
24001 Second: If so, it's not working...
24007 From laser at musichat.net Sat Oct 11 00:56:04 2003
24008 From: laser at musichat.net (Alessandro Ciappei)
24009 Date: Sat Oct 23 23:09:59 2004
24010 Subject: [IRCServices Coding] Problem with auth mail
24011 In-Reply-To: <20031007101106.2701D1703F@snow.fingers.co.za>
24012 Message-ID: <GMEFIDBHIMPENBMIJNFEEEGDCAAA.laser@musichat.net>
24015 Hi all, I've ircservices 5.0.22, and I would like to costumize auth-mail.
24016 I would like describe my irc network in this mail, but when someone register
24017 nick, services go in segfault.
24019 I copy the sintaz of mail-auth ( it's in italian )
24021 # Mail text. The last "%s" (before the user@host) in the body text is
24022 # replaced by one of the NICK_AUTH_MAIL_TEXT_* messages.
24023 NICK_AUTH_MAIL_SUBJECT
24024 Conferma della registrazione del nick %s
24025 NICK_AUTH_MAIL_BODY
24026 Grazie per aver scelto MusiChat Net Community!
24027 Il codice di autorizzazione del tuo nick (%s) e': %09d
24028 Identificati su MusiChat digitando:
24031 La registrazione del tuo nick sara' confermata e il tuo nickname
24032 sara' protetto da eventuali tentativi di abuso o furto.
24034 Il sito ufficiale della rete e' http://www.musichat.net/
24035 I regolamenti della rete e i documenti ufficiali sono
24036 disponibili all'interno del sito.
24038 Per ricevere assistenza sui servizi della rete
24039 in generale puoi rivolgerti sul canale ufficiale #IRCHelp
24040 oppure tramite email all'indirizzo irchelp@musichat.net.
24043 Sono inoltre disponibili i seguenti servizi:
24046 Forum di discussione di MusiChat, raggiungibile
24047 all'indirizzo http://forum.musichat.net
24048 Sul forum, oltre a poter esprimere la tua opinione,
24049 potrai informarti sulle novita' e sui nuovi servizi
24050 offerti dalla rete.
24052 - MusiChat Mailing List
24053 Per iscriversi e' sufficiente visitare il sito
24054 http://lists.musichat.net/mailman/listinfo/irchelp
24055 e inserire il proprio indirizzo E-Mail e la
24056 password desiderata.
24059 Per una connessione piu' veloce e sicura e' vivamente
24060 consigliato l'utilizzo del seguente server: irc.musichat.net
24062 MusiChat Net Community
24064 Questo messaggio e stato inviato su richiesta di %s in risposta a %s
24070 I read the istruction for translate.
24074 [Oct 11 09:48:30 2003] PANIC! buffer = :alpha_omega ! nickserv :register
24075 pippo laser@musichat.net
24076 [Oct 11 09:48:30 2003] Services terminating: Segmentation fault
24079 Some one can help me?
24080 the email body is too long?
24088 From achurch at achurch.org Thu Oct 16 23:58:34 2003
24089 From: achurch at achurch.org (Andrew Church)
24090 Date: Sat Oct 23 23:09:59 2004
24091 Subject: [IRCServices Coding] Problem with auth mail
24092 In-Reply-To: <GMEFIDBHIMPENBMIJNFEEEGDCAAA.laser@musichat.net>
24093 Message-ID: <3f8f9304.20227@achurch.org>
24095 You have the wrong number of %-tokens in your message.
24098 achurch@achurch.org
24099 http://achurch.org/
24102 >Hi all, I've ircservices 5.0.22, and I would like to costumize auth-mail.
24103 >I would like describe my irc network in this mail, but when someone register
24104 >nick, services go in segfault.
24106 >I copy the sintaz of mail-auth ( it's in italian )
24108 ># Mail text. The last "%s" (before the user@host) in the body text is
24109 ># replaced by one of the NICK_AUTH_MAIL_TEXT_* messages.
24110 >NICK_AUTH_MAIL_SUBJECT
24111 > Conferma della registrazione del nick %s
24112 >NICK_AUTH_MAIL_BODY
24113 > Grazie per aver scelto MusiChat Net Community!
24114 > Il codice di autorizzazione del tuo nick (%s) e': %09d
24115 > Identificati su MusiChat digitando:
24116 > /msg %s AUTH %09d
24118 > La registrazione del tuo nick sara' confermata e il tuo nickname
24119 > sara' protetto da eventuali tentativi di abuso o furto.
24121 > Il sito ufficiale della rete e' http://www.musichat.net/
24122 > I regolamenti della rete e i documenti ufficiali sono
24123 > disponibili all'interno del sito.
24125 > Per ricevere assistenza sui servizi della rete
24126 > in generale puoi rivolgerti sul canale ufficiale #IRCHelp
24127 > oppure tramite email all'indirizzo irchelp@musichat.net.
24130 > Sono inoltre disponibili i seguenti servizi:
24133 > Forum di discussione di MusiChat, raggiungibile
24134 > all'indirizzo http://forum.musichat.net
24135 > Sul forum, oltre a poter esprimere la tua opinione,
24136 > potrai informarti sulle novita' e sui nuovi servizi
24137 > offerti dalla rete.
24139 > - MusiChat Mailing List
24140 > Per iscriversi e' sufficiente visitare il sito
24141 > http://lists.musichat.net/mailman/listinfo/irchelp
24142 > e inserire il proprio indirizzo E-Mail e la
24143 > password desiderata.
24146 > Per una connessione piu' veloce e sicura e' vivamente
24147 > consigliato l'utilizzo del seguente server: irc.musichat.net
24149 > MusiChat Net Community
24151 > Questo messaggio e stato inviato su richiesta di %s in risposta a %s
24157 >I read the istruction for translate.
24161 >[Oct 11 09:48:30 2003] PANIC! buffer = :alpha_omega ! nickserv :register
24162 >pippo laser@musichat.net
24163 >[Oct 11 09:48:30 2003] Services terminating: Segmentation fault
24166 >Some one can help me?
24167 >the email body is too long?
24174 >------------------------------------------------------------------
24175 >To unsubscribe or change your subscription options, visit:
24176 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
24178 From saman at alkol.org Fri Oct 17 03:07:31 2003
24179 From: saman at alkol.org (|SaMaN|)
24180 Date: Sat Oct 23 23:09:59 2004
24181 Subject: [IRCServices Coding] Bug or misunderstood ?
24182 Message-ID: <000901c39496$71764f10$a37faec3@coder>
24184 Im using unreal ircd. When channel is empty and if channel owner joins
24185 his/her registered channel it does
24186 (ChanServ sets mode: +ntrq nick) but when channel is not empty and if
24187 channel owner joins his/her registered channel it does (ChanServ sets mode:
24188 +oq nick nick). As you see on the first one there is no +o and because of
24189 this chanserv does not update the last_used time because chanserv is set to
24190 update last_used time with +o (CUMODE_o) so channels drop while channel
24191 owners use them. Is this a bug or my misunderstood ?
24193 ######################################################
24194 modules/chanserv/check.c
24196 void check_chan_user_modes(const char *source, struct c_userlist *u,
24197 Channel *c, int32 oldmodes)
24199 if ((res & ~modes) & CUMODE_o) {
24200 ci->last_used = time(NULL);
24201 put_channelinfo(ci);
24204 ######################################################
24210 From saman at alkol.org Fri Oct 17 04:53:04 2003
24211 From: saman at alkol.org (|SaMaN|)
24212 Date: Sat Oct 23 23:09:59 2004
24213 Subject: [IRCServices Coding] Re: Bug or misunderstood ?
24214 Message-ID: <002001c394a5$31c059b0$a37faec3@coder>
24216 Also it does not update last_used time on +a flag.
24221 edit /modules/chanserv/check.c
24224 -------------------------------------------------------------------------
24225 local_set_cumodes(c, '+', res & ~modes, user->nick);
24226 -------------------------------------------------------------------------
24228 ------------------------------------------------------------------------
24229 int16 cumode_q = mode_char_to_flag('q',MODE_CHANUSER);
24230 int16 cumode_a = mode_char_to_flag('a',MODE_CHANUSER);
24232 if ((res & ~modes) & cumode_q) {
24233 ci->last_used = time(NULL);
24234 put_channelinfo(ci);
24237 if ((res & ~modes) & cumode_a) {
24238 ci->last_used = time(NULL);
24239 put_channelinfo(ci);
24241 -------------------------------------------------------------------------
24242 save and compile and run and enjoy :)
24243 -------------------------------------------------------------------------
24247 ----- Original Message -----
24248 From: "|SaMaN|" <saman@alkol.org>
24249 To: <IRCServices-Coding@ircservices.za.net>
24250 Sent: Friday, October 17, 2003 1:07 PM
24251 Subject: Bug or misunderstood ?
24254 > Im using unreal ircd. When channel is empty and if channel owner joins
24255 > his/her registered channel it does
24256 > (ChanServ sets mode: +ntrq nick) but when channel is not empty and if
24257 > channel owner joins his/her registered channel it does (ChanServ sets
24259 > +oq nick nick). As you see on the first one there is no +o and because of
24260 > this chanserv does not update the last_used time because chanserv is set
24262 > update last_used time with +o (CUMODE_o) so channels drop while channel
24263 > owners use them. Is this a bug or my misunderstood ?
24265 > ######################################################
24266 > modules/chanserv/check.c
24268 > void check_chan_user_modes(const char *source, struct c_userlist *u,
24269 > Channel *c, int32 oldmodes)
24271 > if ((res & ~modes) & CUMODE_o) {
24272 > ci->last_used = time(NULL);
24273 > put_channelinfo(ci);
24276 > ######################################################
24283 From saturn at jetirc.net Fri Oct 17 08:47:59 2003
24284 From: saturn at jetirc.net (Saturn)
24285 Date: Sat Oct 23 23:09:59 2004
24286 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
24287 Message-ID: <002501c394c5$f8dce480$6401a8c0@turby>
24289 Haven't seen a reply to this one, so thought I'd better make sure this went
24292 ----- Original Message -----
24293 Sent: Friday, October 10, 2003 3:48 PM
24294 Subject: Akill problem in 5.0.22
24297 Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
24298 duplicate exit system notice that happens in 3.1.6).
24300 I just today added an akill (+0 time) .. I DO have the immediate auto kill
24301 option un-commented in the modules.conf, but it still didn't bother scanning
24302 for victims matching my akill mask nor did it actually KILL anyone... It
24303 works if they are manually killed and then try to re-connect, but I thought
24304 that new option was so Services will immediately scan for and kill anyone
24305 online that matches the mask as soon as the new akill is added...
24307 First: IS that what it's supposed to do?
24309 Second: If so, it's not working...
24315 From achurch at achurch.org Fri Oct 17 09:03:19 2003
24316 From: achurch at achurch.org (Andrew Church)
24317 Date: Sat Oct 23 23:09:59 2004
24318 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
24319 In-Reply-To: <002501c394c5$f8dce480$6401a8c0@turby>
24320 Message-ID: <3f9012b8.23176@achurch.org>
24325 achurch@achurch.org
24326 http://achurch.org/
24328 >Haven't seen a reply to this one, so thought I'd better make sure this went
24331 >----- Original Message -----
24332 >Sent: Friday, October 10, 2003 3:48 PM
24333 >Subject: Akill problem in 5.0.22
24336 >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
24337 >duplicate exit system notice that happens in 3.1.6).
24339 >I just today added an akill (+0 time) .. I DO have the immediate auto kill
24340 >option un-commented in the modules.conf, but it still didn't bother scanning
24341 >for victims matching my akill mask nor did it actually KILL anyone... It
24342 >works if they are manually killed and then try to re-connect, but I thought
24343 >that new option was so Services will immediately scan for and kill anyone
24344 >online that matches the mask as soon as the new akill is added...
24346 >First: IS that what it's supposed to do?
24348 >Second: If so, it's not working...
24353 >------------------------------------------------------------------
24354 >To unsubscribe or change your subscription options, visit:
24355 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
24357 From saturn at jetirc.net Fri Oct 17 09:19:32 2003
24358 From: saturn at jetirc.net (Saturn)
24359 Date: Sat Oct 23 23:10:00 2004
24360 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
24361 References: <3f9012b8.23176@achurch.org>
24362 Message-ID: <027401c394ca$443ae180$6401a8c0@turby>
24364 Well, Andrew, I did read TFM. For what it's worth, all I found was this
24365 entry under the description of the module options
24367 ImmediatelySendAutokill [OPTIONAL]
24368 Causes OperServ to inform all servers of a new autokill or autokill
24369 exclusion the moment it is added, rather than waiting for someone to match
24371 Example: ImmediatelySendAutokill
24373 I read through the section about AKILLs and SQline, SGline, SZline, etc,
24374 however all of what I read indicates that simply enabling the
24375 ImmediatelySendAutokill option in the modules.conf (coupled with the fact
24376 that everything ELSE is set up and workign properly) SHOULD cause services
24377 to immediately scan the network for clients matching the akill mask, and
24380 My point, sir, is that IT DOES NOT DO THIS. Thus, I'm sure you'll find, I
24381 HAVE in fact read the f___ manual, and the manual does not address this
24382 problem. If it doesn't matter to you, fine, but if it does, let's try and
24383 get on with maybe solving the problem?
24388 ----- Original Message -----
24389 From: "Andrew Church" <achurch@achurch.org>
24390 To: <ircservices-coding@ircservices.za.net>
24391 Sent: Friday, October 17, 2003 9:02 AM
24392 Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
24398 achurch@achurch.org
24399 http://achurch.org/
24401 >Haven't seen a reply to this one, so thought I'd better make sure this went
24404 >----- Original Message -----
24405 >Sent: Friday, October 10, 2003 3:48 PM
24406 >Subject: Akill problem in 5.0.22
24409 >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
24410 >duplicate exit system notice that happens in 3.1.6).
24412 >I just today added an akill (+0 time) .. I DO have the immediate auto kill
24413 >option un-commented in the modules.conf, but it still didn't bother
24415 >for victims matching my akill mask nor did it actually KILL anyone... It
24416 >works if they are manually killed and then try to re-connect, but I thought
24417 >that new option was so Services will immediately scan for and kill anyone
24418 >online that matches the mask as soon as the new akill is added...
24420 >First: IS that what it's supposed to do?
24422 >Second: If so, it's not working...
24427 >------------------------------------------------------------------
24428 >To unsubscribe or change your subscription options, visit:
24429 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
24430 ------------------------------------------------------------------
24431 To unsubscribe or change your subscription options, visit:
24432 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
24435 From achurch at achurch.org Fri Oct 17 09:34:48 2003
24436 From: achurch at achurch.org (Andrew Church)
24437 Date: Sat Oct 23 23:10:00 2004
24438 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
24439 In-Reply-To: <027401c394ca$443ae180$6401a8c0@turby>
24440 Message-ID: <3f901a20.23266@achurch.org>
24442 >however all of what I read indicates that simply enabling the
24443 >ImmediatelySendAutokill option in the modules.conf (coupled with the fact
24444 >that everything ELSE is set up and workign properly) SHOULD cause services
24445 >to immediately scan the network for clients matching the akill mask, and
24448 The documentation says nothing about this. RTFM again.
24451 achurch@achurch.org
24452 http://achurch.org/
24454 From ballsy at mystical.net Fri Oct 17 11:20:33 2003
24455 From: ballsy at mystical.net (Ballsy)
24456 Date: Sat Oct 23 23:10:00 2004
24457 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
24458 In-Reply-To: <027401c394ca$443ae180$6401a8c0@turby>
24459 References: <3f9012b8.23176@achurch.org> <027401c394ca$443ae180$6401a8c0@turby>
24460 Message-ID: <6.0.0.22.0.20031017121557.01b63ac0@127.0.0.1>
24462 To save the rest of us from having to put up with more bickering,
24463 it may be of note that I had to comment out 'EnableExclude' in order for my
24464 immediate-kill functionality to work under bahamut (I know, you're using
24465 Unreal). All the ImmediatelySendAkill does is informs all linked services
24466 that they should add an Akill. It's then up to those servers to decide how
24472 At 10:18 AM 17/10/2003, Saturn wrote:
24473 >Well, Andrew, I did read TFM. For what it's worth, all I found was this
24474 >entry under the description of the module options
24476 >ImmediatelySendAutokill [OPTIONAL]
24477 > Causes OperServ to inform all servers of a new autokill or autokill
24478 >exclusion the moment it is added, rather than waiting for someone to match
24480 > Example: ImmediatelySendAutokill
24482 >I read through the section about AKILLs and SQline, SGline, SZline, etc,
24483 >however all of what I read indicates that simply enabling the
24484 >ImmediatelySendAutokill option in the modules.conf (coupled with the fact
24485 >that everything ELSE is set up and workign properly) SHOULD cause services
24486 >to immediately scan the network for clients matching the akill mask, and
24489 >My point, sir, is that IT DOES NOT DO THIS. Thus, I'm sure you'll find, I
24490 >HAVE in fact read the f___ manual, and the manual does not address this
24491 >problem. If it doesn't matter to you, fine, but if it does, let's try and
24492 >get on with maybe solving the problem?
24497 >----- Original Message -----
24498 >From: "Andrew Church" <achurch@achurch.org>
24499 >To: <ircservices-coding@ircservices.za.net>
24500 >Sent: Friday, October 17, 2003 9:02 AM
24501 >Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
24507 > achurch@achurch.org
24508 > http://achurch.org/
24510 > >Haven't seen a reply to this one, so thought I'd better make sure this went
24513 > >----- Original Message -----
24514 > >Sent: Friday, October 10, 2003 3:48 PM
24515 > >Subject: Akill problem in 5.0.22
24518 > >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
24519 > >duplicate exit system notice that happens in 3.1.6).
24521 > >I just today added an akill (+0 time) .. I DO have the immediate auto kill
24522 > >option un-commented in the modules.conf, but it still didn't bother
24524 > >for victims matching my akill mask nor did it actually KILL anyone... It
24525 > >works if they are manually killed and then try to re-connect, but I thought
24526 > >that new option was so Services will immediately scan for and kill anyone
24527 > >online that matches the mask as soon as the new akill is added...
24529 > >First: IS that what it's supposed to do?
24531 > >Second: If so, it's not working...
24536 > >------------------------------------------------------------------
24537 > >To unsubscribe or change your subscription options, visit:
24538 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
24539 >------------------------------------------------------------------
24540 >To unsubscribe or change your subscription options, visit:
24541 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
24543 >------------------------------------------------------------------
24544 >To unsubscribe or change your subscription options, visit:
24545 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
24549 From saturn at jetirc.net Fri Oct 17 17:16:26 2003
24550 From: saturn at jetirc.net (Saturn)
24551 Date: Sat Oct 23 23:10:00 2004
24552 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
24553 References: <3f901a20.23266@achurch.org>
24554 Message-ID: <02d401c3950c$e762bda0$6401a8c0@turby>
24556 >From a.html in the /docs directory:
24558 operserv/akill (Autokill module settings)
24559 ImmediatelySendAutokill [OPTIONAL]
24560 Causes OperServ to inform all servers of a new autokill or autokill
24561 exclusion the moment it is added, rather than waiting for someone to match
24563 Example: ImmediatelySendAutokill
24566 3.html#4-3 in the /docs directory does not speak to the
24567 ImmediatelySendAutokill option except for the mention that:
24568 "(If the ImmediatelySendAutokill option in modules.conf is enabled, the
24569 last-used time will never be set at all on these servers.)"
24570 However, this is in the context of talking about Slines, etc, and as far as
24571 I can tell has no new useful information to impart regarding my stated
24572 problem: that services is NOT "Immediately sending the autokill" on my
24573 network and thus when a new AKILL is added, the matching users/masks are not
24574 being killed off, unless they are killed manually by an IRCop. Yes, it IS
24575 catching them when they attempt to re-connect, that was never a problem. It
24576 would make sense that if an autokill is added, that Services would
24577 immediately trace the network and kill off any matches to that akill... at
24578 least, it makes sense if this option is enabled.... (to me)
24579 ------------------------
24581 4.html#oper.akill doesn't mention it at all.
24585 I really don't see where else I'm supposed to be looking here. I've scoured
24586 the docs and can see no other reference to it. If there's something I'm
24587 missing, perhaps instead of rudely, repeatedly telling me to RTFM, maybe
24588 just tell me what it is I'm supposed to find! I've already spend a few
24589 hours reading through the docs (which I've already read about a dozen times
24590 over the past year alone), and I'm telling you, there's nothing else about
24591 it that I can find!!!
24593 The ONLY thing I can come up with is that the feature name is misleading and
24594 the option doesn't in fact do what it SEEMS it should do. Could it be that
24595 all that does is send the S/G/Z line (whatever is appropriate) to the
24596 servers and that's all??? NOW I have to ask, why bother, if it'll do that
24597 if/when they re-connect anyhow?
24599 Additionally, if the reason I can't find the answer in the manual is because
24600 the option DOESN'T make services kill all matches when the akill is added,
24601 then Imust ask WHY that isn't an option, since it seems logically useful to
24602 me and my staff. Also, that being the case, why couldn't you simply SAY
24603 that it's not designed to do that, instead of sending me hunting (TWICE) for
24604 non-existant information in the docs???????
24606 I'm very interested to hear the answer to these questions. To put it
24607 bluntly, I have been an extremely enthusiastic advocate of IRCServices for
24608 over 3 years now, have turned many network owners onto them, and love them
24609 to death. The way you "talk" to your supporters on this forum sometimes
24610 leaves a LOT to be desired. If the feature doesn't exist as I understand
24611 it, just SAY SO and save us all a lot of trouble -- don't just tell me to go
24612 RTFM when the info I seek isn't IN it. Having said that, if you can point
24613 me to the info in the docs in the 5.0.22 distro and prove my claims as
24614 baseless, I will offer my sincere apologies. Until then, my opinion stands.
24618 ----- Original Message -----
24619 From: "Andrew Church" <achurch@achurch.org>
24620 To: <ircservices-coding@ircservices.za.net>
24621 Sent: Friday, October 17, 2003 9:34 AM
24622 Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
24625 >however all of what I read indicates that simply enabling the
24626 >ImmediatelySendAutokill option in the modules.conf (coupled with the fact
24627 >that everything ELSE is set up and workign properly) SHOULD cause services
24628 >to immediately scan the network for clients matching the akill mask, and
24631 The documentation says nothing about this. RTFM again.
24634 achurch@achurch.org
24635 http://achurch.org/
24636 ------------------------------------------------------------------
24637 To unsubscribe or change your subscription options, visit:
24638 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
24641 From saturn at jetirc.net Fri Oct 17 17:33:57 2003
24642 From: saturn at jetirc.net (Saturn)
24643 Date: Sat Oct 23 23:10:00 2004
24644 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
24645 References: <3f9012b8.23176@achurch.org> <027401c394ca$443ae180$6401a8c0@turby>
24646 <6.0.0.22.0.20031017121557.01b63ac0@127.0.0.1>
24647 Message-ID: <030801c3950f$3cb55270$6401a8c0@turby>
24649 Would have been nice if someone had mentioned that (about the
24650 ImmediatelySendAutokill) from the start. I would say the flag is misleading
24651 in title then, because I (and 8 other people on my staff -- none of us are
24652 dummies, either) read that as meaning it will Immediately send the auto
24653 kill... "ImmediatelyUpdateServers" might be more fitting from an intuitive
24654 standpoint, not that I'm suggesting changing the name, but at least the
24655 documentation of it could be a bit more explicit IMHO.
24657 and yes, I know there will be about 50 people (probably all of them
24658 hard-core coders) shaking their heads in disbelief at what I've said, but
24659 let's face it: If we were ALL hard-core coders, we wouldn't need Andrew and
24660 his IRCServices, would we? We'd all be making our own. So all I'm saying
24661 is how about a little slack for those of us with OTHER important skills that
24662 might fall outside the scope of being the "world's greatest expert" on IRC
24665 ----- Original Message -----
24666 From: "Ballsy" <ballsy@mystical.net>
24667 To: "IRC Services Coding Mailing List"
24668 <ircservices-coding@ircservices.za.net>; "IRC Services Coding Mailing List"
24669 <ircservices-coding@ircservices.za.net>
24670 Sent: Friday, October 17, 2003 11:20 AM
24671 Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
24674 To save the rest of us from having to put up with more bickering,
24675 it may be of note that I had to comment out 'EnableExclude' in order for my
24676 immediate-kill functionality to work under bahamut (I know, you're using
24677 Unreal). All the ImmediatelySendAkill does is informs all linked services
24678 that they should add an Akill. It's then up to those servers to decide how
24684 At 10:18 AM 17/10/2003, Saturn wrote:
24685 >Well, Andrew, I did read TFM. For what it's worth, all I found was this
24686 >entry under the description of the module options
24688 >ImmediatelySendAutokill [OPTIONAL]
24689 > Causes OperServ to inform all servers of a new autokill or autokill
24690 >exclusion the moment it is added, rather than waiting for someone to match
24692 > Example: ImmediatelySendAutokill
24694 >I read through the section about AKILLs and SQline, SGline, SZline, etc,
24695 >however all of what I read indicates that simply enabling the
24696 >ImmediatelySendAutokill option in the modules.conf (coupled with the fact
24697 >that everything ELSE is set up and workign properly) SHOULD cause services
24698 >to immediately scan the network for clients matching the akill mask, and
24701 >My point, sir, is that IT DOES NOT DO THIS. Thus, I'm sure you'll find, I
24702 >HAVE in fact read the f___ manual, and the manual does not address this
24703 >problem. If it doesn't matter to you, fine, but if it does, let's try and
24704 >get on with maybe solving the problem?
24709 >----- Original Message -----
24710 >From: "Andrew Church" <achurch@achurch.org>
24711 >To: <ircservices-coding@ircservices.za.net>
24712 >Sent: Friday, October 17, 2003 9:02 AM
24713 >Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
24719 > achurch@achurch.org
24720 > http://achurch.org/
24722 > >Haven't seen a reply to this one, so thought I'd better make sure this
24726 > >----- Original Message -----
24727 > >Sent: Friday, October 10, 2003 3:48 PM
24728 > >Subject: Akill problem in 5.0.22
24731 > >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
24732 > >duplicate exit system notice that happens in 3.1.6).
24734 > >I just today added an akill (+0 time) .. I DO have the immediate auto
24736 > >option un-commented in the modules.conf, but it still didn't bother
24738 > >for victims matching my akill mask nor did it actually KILL anyone... It
24739 > >works if they are manually killed and then try to re-connect, but I
24741 > >that new option was so Services will immediately scan for and kill anyone
24742 > >online that matches the mask as soon as the new akill is added...
24744 > >First: IS that what it's supposed to do?
24746 > >Second: If so, it's not working...
24751 > >------------------------------------------------------------------
24752 > >To unsubscribe or change your subscription options, visit:
24753 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
24754 >------------------------------------------------------------------
24755 >To unsubscribe or change your subscription options, visit:
24756 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
24758 >------------------------------------------------------------------
24759 >To unsubscribe or change your subscription options, visit:
24760 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
24763 ------------------------------------------------------------------
24764 To unsubscribe or change your subscription options, visit:
24765 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
24768 From Craig at chatspike.net Fri Oct 17 19:07:33 2003
24769 From: Craig at chatspike.net (Craig McLure)
24770 Date: Sat Oct 23 23:10:00 2004
24771 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
24772 Message-ID: <E1AAgV1-0008ae-00@ptb-mailc04.plus.net>
24774 Theres no need for flaming ffs.. just because something makes less sence to you than to everyone else, doesnt instantly mean that it has to be changed.. i seemed to understand it ok, and i'm sure that there are several hundred other IRCServices users who didnt have any problems with this directive.
24776 I'm sure andy will concider documenting it more "accuratly" (I wont speak for him thou, his choice :p), but theres no need for the flaming, if you have such a big problem with something that (apparently just) you dont understand, just make a passing mention on it, dont go on talking about "Hard-core coders" and "worlds biggest expert"s cause you are upset with something. If the last paragraph wasnt made, i'm sure there _WOUDLNT_ be "about 50 people (probably all of them hard-core coders) shaking their heads in disbelief", cause it doesnt happen. And to clarify.. theres no such thing as a "world biggest expert" when it comes to IRC programming, people have different preferances, and ways of doing things, to the point that you cant compair something like InspIRCd to UnrealIRCd, as they are totally different in almost every way. :p
24778 Please just calm down, and talk this out rationally before you start jumping down ppls throats :p
24780 /*****************************************
24781 * Craig "FrostyCoolSlug" McLure
24782 * InspIRCd - http://www.inspircd.org
24783 * ChatSpike - http://www.chatspike.net
24784 ****************************************/
24787 /****************************************
24788 * From - Saturn <saturn@jetirc.net>
24789 * To - IRC Services Coding Mailing List <ircservices-coding@ircservices.za.net>
24790 * Sent - 2003-10-17 17:31:00
24791 * Subject - Re: [IRCServices Coding] Re: Akill problem in 5.0.22
24792 ****************************************/
24794 /****** - Begin Original Message - ******/
24796 >Would have been nice if someone had mentioned that (about the
24797 >ImmediatelySendAutokill) from the start. I would say the flag is misleading
24798 >in title then, because I (and 8 other people on my staff -- none of us are
24799 >dummies, either) read that as meaning it will Immediately send the auto
24800 >kill... "ImmediatelyUpdateServers" might be more fitting from an intuitive
24801 >standpoint, not that I'm suggesting changing the name, but at least the
24802 >documentation of it could be a bit more explicit IMHO.
24804 >and yes, I know there will be about 50 people (probably all of them
24805 >hard-core coders) shaking their heads in disbelief at what I've said, but
24806 >let's face it: If we were ALL hard-core coders, we wouldn't need Andrew and
24807 >his IRCServices, would we? We'd all be making our own. So all I'm saying
24808 >is how about a little slack for those of us with OTHER important skills that
24809 >might fall outside the scope of being the "world's greatest expert" on IRC
24812 >----- Original Message -----
24813 >From: "Ballsy" <ballsy@mystical.net>
24814 >To: "IRC Services Coding Mailing List"
24815 ><ircservices-coding@ircservices.za.net>; "IRC Services Coding Mailing List"
24816 ><ircservices-coding@ircservices.za.net>
24817 >Sent: Friday, October 17, 2003 11:20 AM
24818 >Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
24821 > To save the rest of us from having to put up with more bickering,
24822 >it may be of note that I had to comment out 'EnableExclude' in order for my
24823 >immediate-kill functionality to work under bahamut (I know, you're using
24824 >Unreal). All the ImmediatelySendAkill does is informs all linked services
24825 >that they should add an Akill. It's then up to those servers to decide how
24831 >At 10:18 AM 17/10/2003, Saturn wrote:
24832 >>Well, Andrew, I did read TFM. For what it's worth, all I found was this
24833 >>entry under the description of the module options
24835 >>ImmediatelySendAutokill [OPTIONAL]
24836 >> Causes OperServ to inform all servers of a new autokill or autokill
24837 >>exclusion the moment it is added, rather than waiting for someone to match
24839 >> Example: ImmediatelySendAutokill
24841 >>I read through the section about AKILLs and SQline, SGline, SZline, etc,
24842 >>however all of what I read indicates that simply enabling the
24843 >>ImmediatelySendAutokill option in the modules.conf (coupled with the fact
24844 >>that everything ELSE is set up and workign properly) SHOULD cause services
24845 >>to immediately scan the network for clients matching the akill mask, and
24848 >>My point, sir, is that IT DOES NOT DO THIS. Thus, I'm sure you'll find, I
24849 >>HAVE in fact read the f___ manual, and the manual does not address this
24850 >>problem. If it doesn't matter to you, fine, but if it does, let's try and
24851 >>get on with maybe solving the problem?
24856 >>----- Original Message -----
24857 >>From: "Andrew Church" <achurch@achurch.org>
24858 >>To: <ircservices-coding@ircservices.za.net>
24859 >>Sent: Friday, October 17, 2003 9:02 AM
24860 >>Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
24866 >> achurch@achurch.org
24867 >> http://achurch.org/
24869 >> >Haven't seen a reply to this one, so thought I'd better make sure this
24873 >> >----- Original Message -----
24874 >> >Sent: Friday, October 10, 2003 3:48 PM
24875 >> >Subject: Akill problem in 5.0.22
24878 >> >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
24879 >> >duplicate exit system notice that happens in 3.1.6).
24881 >> >I just today added an akill (+0 time) .. I DO have the immediate auto
24883 >> >option un-commented in the modules.conf, but it still didn't bother
24885 >> >for victims matching my akill mask nor did it actually KILL anyone... It
24886 >> >works if they are manually killed and then try to re-connect, but I
24888 >> >that new option was so Services will immediately scan for and kill anyone
24889 >> >online that matches the mask as soon as the new akill is added...
24891 >> >First: IS that what it's supposed to do?
24893 >> >Second: If so, it's not working...
24898 >> >------------------------------------------------------------------
24899 >> >To unsubscribe or change your subscription options, visit:
24900 >> >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
24901 >>------------------------------------------------------------------
24902 >>To unsubscribe or change your subscription options, visit:
24903 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
24905 >>------------------------------------------------------------------
24906 >>To unsubscribe or change your subscription options, visit:
24907 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
24910 >------------------------------------------------------------------
24911 >To unsubscribe or change your subscription options, visit:
24912 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
24914 >------------------------------------------------------------------
24915 >To unsubscribe or change your subscription options, visit:
24916 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
24920 /******* - End Original Message - *******/
24925 From achurch at achurch.org Fri Oct 17 20:13:46 2003
24926 From: achurch at achurch.org (Andrew Church)
24927 Date: Sat Oct 23 23:10:00 2004
24928 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
24929 In-Reply-To: <02d401c3950c$e762bda0$6401a8c0@turby>
24930 Message-ID: <3f90afdf.23477@achurch.org>
24932 You know, I might have been more forgiving if this hadn't been gone
24933 over on this list (twice!) before:
24935 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/002305.html
24936 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/003215.html
24938 However, since you seem to have trouble both comprehending the
24939 documentation and reading the archives, I have added FAQ F.10 for your
24942 F.10. Services doesn't kill users matching a newly-added autokill mask even
24943 if ImmediatelySendAutokill is set.
24945 Services never kills users when a new autokill is added; the
24946 ImmediatelySendAutokill configuration directive only causes
24947 Services to send the autokill itself (that is, the user/host mask
24948 to prohibit new connections from) to the IRC servers on your
24949 network. This is a safety feature intended to limit the damage
24950 caused by a mistyped autokill.
24952 Note that some IRC servers will themselves kill users matching a
24953 newly-added autokill; this is unrelated to Services.
24956 achurch@achurch.org
24957 http://achurch.org/
24959 From griever at t2n.org Fri Oct 17 21:23:14 2003
24960 From: griever at t2n.org (Robert F Merrill)
24961 Date: Sat Oct 23 23:10:00 2004
24962 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
24963 In-Reply-To: <030801c3950f$3cb55270$6401a8c0@turby>
24964 References: <3f9012b8.23176@achurch.org> <027401c394ca$443ae180$6401a8c0@turby>
24965 <6.0.0.22.0.20031017121557.01b63ac0@127.0.0.1>
24966 <030801c3950f$3cb55270$6401a8c0@turby>
24967 Message-ID: <3F90BF77.2010706@t2n.org>
24971 >Would have been nice if someone had mentioned that (about the
24972 >ImmediatelySendAutokill) from the start. I would say the flag is misleading
24973 >in title then, because I (and 8 other people on my staff -- none of us are
24974 >dummies, either) read that as meaning it will Immediately send the auto
24975 >kill... "ImmediatelyUpdateServers" might be more fitting from an intuitive
24976 >standpoint, not that I'm suggesting changing the name, but at least the
24977 >documentation of it could be a bit more explicit IMHO.
24980 It DOES immediately send the autokill. You just don't grasp the meaning
24981 of sending the autokill.
24982 It literally sends an AKILL (or TKL in the case of unreal) message to
24983 the servers. At least unreal
24984 and bahamut will then scan for matching clients and disconnect them,
24985 however not all servers
24988 If you are using unreal and it doesn't disconnect the matching users,
24989 then it is either a bug in
24990 unreal (not uncommon) or the services really *aren't* sending the tkl
24991 message (doubt it).
24993 Try adding an akill for a connected client. If the client doesn't die,
24994 do a /stats g on their server.
24995 You should see a g-line added for them.
24997 Also note that if you have akill exclusions enabled (bad idea most of
24998 the time), services will NEVER add an akill
24999 or gline on servers that don't support akill or gline exclusions (I
25000 don't know of any that do), but rather
25001 manually kill everyone that matches as they connect. In this case, you
25002 should disable akill exclusions and
25003 it should start working.
25007 From v13 at it.teithe.gr Sat Oct 18 11:47:23 2003
25008 From: v13 at it.teithe.gr (V13)
25009 Date: Sat Oct 23 23:10:00 2004
25010 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
25011 In-Reply-To: <3F90BF77.2010706@t2n.org>
25012 References: <3f9012b8.23176@achurch.org> <030801c3950f$3cb55270$6401a8c0@turby>
25013 <3F90BF77.2010706@t2n.org>
25014 Message-ID: <200310182149.18600.v13@it.teithe.gr>
25016 On Saturday 18 October 2003 07:20, Robert F Merrill wrote:
25018 > >Would have been nice if someone had mentioned that (about the
25019 > >ImmediatelySendAutokill) from the start. I would say the flag is
25020 > > misleading in title then, because I (and 8 other people on my staff --
25021 > > none of us are dummies, either) read that as meaning it will Immediately
25022 > > send the auto kill... "ImmediatelyUpdateServers" might be more fitting
25023 > > from an intuitive standpoint, not that I'm suggesting changing the name,
25024 > > but at least the documentation of it could be a bit more explicit IMHO.
25026 > It DOES immediately send the autokill. You just don't grasp the meaning
25027 > of sending the autokill.
25028 > It literally sends an AKILL (or TKL in the case of unreal) message to
25029 > the servers. At least unreal
25030 > and bahamut will then scan for matching clients and disconnect them,
25031 > however not all servers
25034 FYI bahamut doesn't do this. It will only do it whenever a new client that
25035 matches the akill connects to the server.
25037 i.e. if you set an akill for *.com noone will be disconnected untill a new
25038 client from *.com gets connected (at that moment, all matching clients will
25039 be killed). In the mean time, anyone from other domains can connect to the
25040 server without having any user killed.
25044 From diego at redesul.net Sat Oct 18 12:17:04 2003
25045 From: diego at redesul.net (Diego B. Contezini)
25046 Date: Sat Oct 23 23:10:00 2004
25047 Subject: [IRCServices Coding] CORE DUMPED! BUG!
25048 References: <3f8f9304.20227@achurch.org>
25049 Message-ID: <000e01c395ac$5b773b40$3cc8a8c0@angel>
25051 Andrew, you told me about debugging.. now i got it ;]
25052 here is the debugging:
25053 [Oct 18 16:05:31.288944 2003] debug: Sent: :ChanServ TOPIC #EMOCORE reffer
25054 1066055037 :1i?? Festival HARDcoCOREcore dia 25 de outubro em blumenau no
25055 rio bravo bar (proximo a resima agua verde), com as bandas: Zero Ltda
25056 (curitiba), Swallow the Waffle (bc), chymia(bnu), crazy frogs (lages),
25057 surpise set e slipper (bnu)...3 pila entrada inicio as 15:00 horas'
25058 [Oct 18 16:05:31.289032 2003] debug: Received: :|-Frango-| MODE
25059 #EMOCORE -oooooo CHoPP CbRS-oFF caroll BRYAN brunaH balsanelli
25060 Segmentation fault (core dumped)
25062 root@irc(/home/ircadmin/services/lib)# ls -la core.12631
25063 -rw------- 1 ircadmin ircadmin 47374336 Oct 18 16:05 core.12631
25066 continue on the next message......
25069 From diego at redesul.net Sat Oct 18 12:17:32 2003
25070 From: diego at redesul.net (Diego B. Contezini)
25071 Date: Sat Oct 23 23:10:00 2004
25072 Subject: [IRCServices Coding] CORE DUMPED... continue...
25073 References: <3f8f9304.20227@achurch.org>
25074 Message-ID: <001201c395ac$71b42210$3cc8a8c0@angel>
25076 #0 0x0804d830 in add_mode_with_params (md=0x806aa00, mode=111 'o',
25077 is_add=1, params=1, parambuf=0xbfffe280 "balsanelli",
25078 len=10) at actions.c:568
25079 568 md->params[md->nopmodes][len] = 0;
25081 #0 0x0804d830 in add_mode_with_params (md=0x806aa00, mode=111 'o',
25082 is_add=1, params=1, parambuf=0xbfffe280 "balsanelli",
25083 len=10) at actions.c:568
25085 #1 0x0804d342 in set_cmode (sender=0x81db058 "ChanServ", channel=0xa905d00)
25088 "balsanelli\000\b\025\225\002BWi??\022B\024\032\023Bi??i??i??i??\000\000\000
25089 \000\034 \006\bi??i??i??i??hi??i??i??i??i??i??i??\025\224\004B\034
25090 \006\b\000\000\000\000i??m\tBdi??\022Bi??q\a\b\000\000\000\000eR :\0037[
25091 \0034#\003di??\022B\000\000\000\000i??\037\006\bi??\037\006\bi??i??i??i??$i?
25092 ?\006Bi??i??i??i??\bi??i??i??\000\000\000\000Hi??i??i??\025\224\004B@\002\a\
25093 b8i??i??i??6\020\aBpi??i??i??@i??\006\b@\002\a\b\000\000\000\000i??<\023BLi?
25094 ?i??i??=S\004B\024\032\023B\001\020\000\000@i??\006\bhi??i??i??\204i??\006Bp
25095 i??i??i??i??\037\006\b"...
25100 args = 0xbfffe6d0 "RDcoCOREcorei??i??i??i??o"
25101 modes = 0xbfffeae2 ""
25102 modes_orig = 0xbfffeae0 "+o"
25103 md = (struct modedata *) 0x806aa00
25108 #2 0x400895ff in local_set_cumodes (c=0xa905d00, plusminus=43 '+', modes=1,
25109 nick=0xab7f2e8 "balsanelli") at check.c:432
25111 modestr = "o\000\000 de outubro em blumenau no rio bravo bar
25112 (proximo a resima agua verde), com as bandas: Zero
25113 L\v\000\000\000(curitiba), \000\000\000\000low the Waff\000\000\000\000bc),
25114 chymia(bnu), crazy frogs (lages), surpise set e slipper (bnu).."...
25116 #3 0x40088d74 in check_chan_user_modes (source=0xbfffeed0 "|-Frango-|",
25117 u=0xab34ff0, c=0xa905d00, oldmodes=1)
25119 user = (User *) 0xab7f2d8
25120 ci = (ChannelInfo *) 0xa571940
25124 #4 0x400820ed in do_channel_umode_change (source=0xbfffeed0 "|-Frango-|",
25125 c=0xa905d00, u=0xab34ff0, oldmodes=1)
25128 #5 0x0805890d in call_callback_5 (module=0x806a5c0, id=23, arg1=0xbfffeed0,
25129 arg2=0xa905d00, arg3=0xab34ff0, arg4=0x1,
25130 arg5=0x0) at modules.c:666
25131 cl = (CallbackList *) 0x8077cb8
25134 #6 0x0804edc8 in do_cumode (source=0xbfffeed0 "|-Frango-|", chan=0xa905d00,
25135 flag=1, add=0, nick=0xbfffecc9 "balsanelli")
25136 ---Type <return> to continue, or q <return> to quit---
25138 u = (struct c_userlist *) 0xab34ff0
25139 user = (User *) 0xab7f2d8
25141 #7 0x0804e97e in do_cmode (source=0xbfffeed0 "|-Frango-|", ac=0,
25142 av=0xa853130) at channels.c:302
25145 params = -1073746288
25146 chan = (Channel *) 0xa905d00
25149 modestr = 0xbfffec9e "-oooooo"
25150 #8 0x080557ff in m_mode (source=0xbfffeed0 "|-Frango-|", ac=8,
25151 av=0xa853110) at messages.c:101
25153 #9 0x0805920e in process () at process.c:133
25154 m = (Message *) 0x8067dd8
25156 "|-Frango-|\000\000G\000\000\000Y\e\205\n\t+\205\n\bi??i??i??i??i??\005\b@j\
25157 a\b\000\004\000\000i??\032\205\n\t\000\000\000@j\a\b\216j\a\b(i??i??i??qP\00
25160 "MODE\000\000\000i??8i??i??i??i??\005\b\000\000\000\000i??i??i??i??\000\000\
25161 000\000\000\000\000\000\001H\000\000Pi??i??i??\000Y\a\bVi??\005\b\207j\a\bP\
25162 e\205\n\t\000\000\000i??i??\005\b"
25164 "MODE\000#EMOCORE\000-oooooo\000CHoPP\000CbRS-oFF\000caroll\000BRYAN\000brun
25165 aH\000balsanelli\000 balsanelli\000\000ai\00314ser \0030]\00315=\00314-
25166 S\00315c\0030ri\00315p\00314t \00315\037v\0373.8 \003\000\00315\037v\0373.8
25167 \003\000\000\0003)\000\0006\037\002Pi??Ti??\00313\037\002]\037\002\0036i??i?
25168 ? \000i??Ti??\00313\037\002]\037\002\0036i??i?? \000\000\003\000\000r
25169 \003", '\0' <repeats 11 times>...
25170 s = 0xbfffec95 "#EMOCORE"
25172 av = (char **) 0xa853110
25173 #10 0x0805507d in readline_callback (s=0xa851ae0, param_unused=0x50) at
25176 #11 0x0805b617 in check_sockets () at sockets.c:491
25177 newline = 0xa851b58 "\nrct-sc.br irc.creativenet.com.br 0 3364349034
25178 :aNiNhHa[du]DoNaTeLo\n:Toh_Pensanu PART #ilheus\n:_LoKo_SuL_ SJOIN
25179 1063565447 #elias\n:_MoRgAnA_ PRIVMSG NickServ@services.redesul.net :set
25180 nomemo off\n:irc."...
25183 rfds = {fds_bits = {16, 0 <repeats 31 times>}}
25184 wfds = {fds_bits = {0 <repeats 32 times>}}
25185 tv = {tv_sec = 2, tv_usec = 980000}
25188 s = (Socket *) 0xa851ae0
25189 s2 = (Socket *) 0x0
25190 #12 0x0805538a in main (ac=3, av=0xbffff164, envp=0xbffff174) at main.c:266
25191 ---Type <return> to continue, or q <return> to quit---
25193 now_msec = 1348441861
25194 last_update = 1066500208
25195 last_check = 1348441182
25196 #13 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
25197 No symbol table info available.
25202 From saturn at jetirc.net Sat Oct 18 12:18:40 2003
25203 From: saturn at jetirc.net (Saturn)
25204 Date: Sat Oct 23 23:10:00 2004
25205 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
25206 References: <3f90afdf.23477@achurch.org>
25207 Message-ID: <003701c395ac$9ff9fd20$6401a8c0@turby>
25209 I thank you for finally just coming out and telling me what I needed to know
25210 in the first place. Had you stated that it has been discussed before (even
25211 without the hyperlinks) I would have at least known to go look through the
25212 archives. However, all you said (then repeated) was RTFM. I DID read it,
25213 once before I asked, and twice more, at your instruction, and found nothing
25214 to answer my questions. Had I known it had already been discussed, I would
25215 certainly have tried to locate the answer that way.
25217 Thank you to all the others who've posted to try and explain what I was
25218 missing in my understanding of this directive. I got it now, and realize
25219 where my misinterpretation was. Seems obvious now, but frankly that
25220 directive managed to fool myself and 8 of my staff into thinking of it as I
25221 have previously described. Regardless, my apologies for any harsh words...
25222 I do stand by the fact that Andrew could have responded with a bit less
25223 apathy to the concerns raised; with something a bit less useless than RTFM
25224 (twice! even AFTER I said I had, THAT'S what pissed me off), and I hope that
25225 maybe Andrew will remember this chain of events for the next time someone
25226 has a problem that might be immediately obvious to Andrew, but not the
25227 person with the problem. I think most of us KNOW by now to read the docs
25228 before asking questions; but if the question arises due to misinterpretation
25229 of the docs, how would reading them over and over help?
25231 Thank you all for your time.
25235 ----- Original Message -----
25236 From: "Andrew Church" <achurch@achurch.org>
25237 To: <ircservices-coding@ircservices.za.net>
25238 Sent: Friday, October 17, 2003 7:57 PM
25239 Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
25242 You know, I might have been more forgiving if this hadn't been gone
25243 over on this list (twice!) before:
25245 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/002305.html
25246 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/003215.html
25248 However, since you seem to have trouble both comprehending the
25249 documentation and reading the archives, I have added FAQ F.10 for your
25252 F.10. Services doesn't kill users matching a newly-added autokill mask even
25253 if ImmediatelySendAutokill is set.
25255 Services never kills users when a new autokill is added; the
25256 ImmediatelySendAutokill configuration directive only causes
25257 Services to send the autokill itself (that is, the user/host mask
25258 to prohibit new connections from) to the IRC servers on your
25259 network. This is a safety feature intended to limit the damage
25260 caused by a mistyped autokill.
25262 Note that some IRC servers will themselves kill users matching a
25263 newly-added autokill; this is unrelated to Services.
25266 achurch@achurch.org
25267 http://achurch.org/
25268 ------------------------------------------------------------------
25269 To unsubscribe or change your subscription options, visit:
25270 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
25273 From diego at redesul.net Sat Oct 18 14:38:17 2003
25274 From: diego at redesul.net (Diego B. Contezini)
25275 Date: Sat Oct 23 23:10:00 2004
25276 Subject: [IRCServices Coding] CORE DUMPED... Debuging
25277 Message-ID: <003f01c395c0$09a31cd0$3cc8a8c0@angel>
25279 If it helps, more lines up.. of debugging...
25282 ChanServ@services.redesul.net :op #manaus paulinhu-dissi-q-mi-ama
25283 [Oct 18 16:05:31.152195 2003] debug: Sent: :ChanServ NOTICE paulinhu-dissi-q-mi-ama :Permission denied.
25284 [Oct 18 16:05:31.152274 2003] debug: Received: :pRiCkLy SJOIN 1066501295 #Euevc
25285 [Oct 18 16:05:31.152353 2003] protocol/bahamut: debug: pRiCkLy SJOINs #Euevc
25286 [Oct 18 16:05:31.152490 2003] debug: Sent: :ChanServ MODE #EUeVC +o pRiCkLy
25287 [Oct 18 16:05:31.269153 2003] debug: Received: :Hellskitty PRIVMSG ChanServ@services.redesul.net :unban #EMOCORE
25288 [Oct 18 16:05:31.269425 2003] debug: Sent: :ChanServ NOTICE Hellskitty :Permission denied.
25289 [Oct 18 16:05:31.288596 2003] debug: Received: :|-Frango-| MODE #EMOCORE +stmipl 1
25290 [Oct 18 16:05:31.288768 2003] debug: Received: :|-Frango-| TOPIC #EMOCORE |-Frango-| 1066460927 :TakeOver by 14,1 -15=0[ 14He15l0lR15ai14ser 0]15=14- S15c0ri15p14t 15v3.8
25291 [Oct 18 16:05:31.288944 2003] debug: Sent: :ChanServ TOPIC #EMOCORE reffer 1066055037 :1??? Festival HARDcoCOREcore dia 25 de outubro em blumenau no rio bravo bar (proximo a resima agua verde), com as bandas: Zero Ltda (curitiba), Swallow the Waffle (bc), chymia(bnu), crazy frogs (lages), surpise set e slipper (bnu)...3 pila entrada inicio as 15:00 horas'
25292 [Oct 18 16:05:31.289032 2003] debug: Received: :|-Frango-| MODE #EMOCORE -oooooo CHoPP CbRS-oFF caroll BRYAN brunaH balsanelli
25293 Segmentation fault (core dumped)
25295 -------------- next part --------------
25296 An HTML attachment was scrubbed...
25297 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20031018/667c67fa/attachment.htm
25298 From ballsy at mystical.net Mon Oct 20 08:19:44 2003
25299 From: ballsy at mystical.net (Ballsy)
25300 Date: Sat Oct 23 23:10:00 2004
25301 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
25302 In-Reply-To: <200310182149.18600.v13@it.teithe.gr>
25303 References: <3f9012b8.23176@achurch.org> <030801c3950f$3cb55270$6401a8c0@turby>
25304 <3F90BF77.2010706@t2n.org> <200310182149.18600.v13@it.teithe.gr>
25305 Message-ID: <6.0.0.22.0.20031020091611.01b47318@127.0.0.1>
25307 Yes, Bahamut will immediately kill users matching an Akill. It
25308 won't wait for another client from that host to connect. My setup of IRC
25309 Services 5.0.22 and bahamut-1.4.30 is doing it right now. As alluded to in
25310 a previous email, however, you may need to commented out EnableExclude in
25311 the services config to have this work.
25316 At 12:49 PM 18/10/2003, V13 wrote:
25317 >On Saturday 18 October 2003 07:20, Robert F Merrill wrote:
25319 > > >Would have been nice if someone had mentioned that (about the
25320 > > >ImmediatelySendAutokill) from the start. I would say the flag is
25321 > > > misleading in title then, because I (and 8 other people on my staff --
25322 > > > none of us are dummies, either) read that as meaning it will Immediately
25323 > > > send the auto kill... "ImmediatelyUpdateServers" might be more fitting
25324 > > > from an intuitive standpoint, not that I'm suggesting changing the name,
25325 > > > but at least the documentation of it could be a bit more explicit IMHO.
25327 > > It DOES immediately send the autokill. You just don't grasp the meaning
25328 > > of sending the autokill.
25329 > > It literally sends an AKILL (or TKL in the case of unreal) message to
25330 > > the servers. At least unreal
25331 > > and bahamut will then scan for matching clients and disconnect them,
25332 > > however not all servers
25335 >FYI bahamut doesn't do this. It will only do it whenever a new client that
25336 >matches the akill connects to the server.
25338 >i.e. if you set an akill for *.com noone will be disconnected untill a new
25339 >client from *.com gets connected (at that moment, all matching clients will
25340 >be killed). In the mean time, anyone from other domains can connect to the
25341 >server without having any user killed.
25344 >------------------------------------------------------------------
25345 >To unsubscribe or change your subscription options, visit:
25346 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
25350 From oska at mynet.com Tue Oct 21 22:24:34 2003
25351 From: oska at mynet.com (oska)
25352 Date: Sat Oct 23 23:10:00 2004
25353 Subject: [IRCServices Coding] "Re: Contents of IRCServices-Coding digest..."
25354 Message-ID: <HN58ED$I890Q9pEOh0UN3QcHkNkg1Bm2fHspFZq@mynet.com>
25356 An HTML attachment was scrubbed...
25357 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20031022/9c540c11/attachment.html
25358 From laser at musichat.net Fri Oct 24 10:36:30 2003
25359 From: laser at musichat.net (laser@musichat.net)
25360 Date: Sat Oct 23 23:10:00 2004
25361 Subject: [IRCServices Coding] Il momento e' catartico
25362 Message-ID: <20031024173545.9ACA817038@snow.fingers.co.za>
25364 Ricevo e cortesemente inoltro,.... un premio per la genialit?
25365 hanno reso mitico un salva schermo scaricalo, "poesie catartiche", che non sai cosa ti perdi
25368 -------------- next part --------------
25369 An HTML attachment was scrubbed...
25370 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20031024/97501fa5/attachment.htm
25371 From diego at redesul.net Fri Oct 24 17:02:47 2003
25372 From: diego at redesul.net (Diego B. Contezini)
25373 Date: Sat Oct 23 23:10:00 2004
25374 Subject: [IRCServices Coding] CORE DUMPED! BUG!
25375 References: <3f8f9304.20227@achurch.org> <000e01c395ac$5b773b40$3cc8a8c0@angel>
25376 Message-ID: <012e01c39a8b$531829d0$3cc8a8c0@angel>
25378 Andrew, have anything more of dumping/debugging that i can do/give for helps
25380 (if it helps, here its rh9.0, libc 2.3.2, linux x86, kernel 2.4.20-8,
25381 Pentium III 1ghz 512mb ram DDR)....
25391 From andrew at wtfigo.co.uk Tue Nov 4 02:15:03 2003
25392 From: andrew at wtfigo.co.uk (Andrew Kempe)
25393 Date: Sat Oct 23 23:10:00 2004
25394 Subject: [IRCServices Coding] test
25395 Message-ID: <E1AGyDD-0001mX-00@smtp.mailbox.co.uk>
25399 From diego at redesul.net Tue Nov 4 16:43:45 2003
25400 From: diego at redesul.net (Diego B. Contezini)
25401 Date: Sat Oct 23 23:10:00 2004
25402 Subject: [IRCServices Coding] CORE DUMPED! BUG!
25403 Message-ID: <014f01c3a335$e1e08dd0$3cc8a8c0@angel>
25405 I found a bug (occuring on the old-last vesion of ircservices -
25406 ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
25408 yes, 5.0.23 is the last.. but nothing has changed about the bug...
25410 here is the debugging:
25412 ChanServ@services.redesul.net :op #manaus paulinhu-dissi-q-mi-ama
25413 [Oct 18 16:05:31.152195 2003] debug: Sent: :ChanServ NOTICE
25414 paulinhu-dissi-q-mi-ama :Permission denied.
25415 [Oct 18 16:05:31.152274 2003] debug: Received: :pRiCkLy SJOIN 1066501295
25417 [Oct 18 16:05:31.152353 2003] protocol/bahamut: debug: pRiCkLy SJOINs #Euevc
25418 [Oct 18 16:05:31.152490 2003] debug: Sent: :ChanServ MODE #EUeVC +o pRiCkLy
25419 [Oct 18 16:05:31.269153 2003] debug: Received: :Hellskitty PRIVMSG
25420 ChanServ@services.redesul.net :unban #EMOCORE
25421 [Oct 18 16:05:31.269425 2003] debug: Sent: :ChanServ NOTICE Hellskitty
25422 :Permission denied.
25423 [Oct 18 16:05:31.288596 2003] debug: Received: :|-Frango-| MODE #EMOCORE
25425 [Oct 18 16:05:31.288768 2003] debug: Received: :|-Frango-| TOPIC #EMOCORE
25426 |-Frango-| 1066460927 :TakeOver by 14,1 -15=0[ 14He15l0lR15ai14ser 0]15=14-
25427 S15c0ri15p14t 15v3.8
25428 [Oct 18 16:05:31.288944 2003] debug: Sent: :ChanServ TOPIC #EMOCORE reffer
25429 1066055037 :1i?? Festival HARDcoCOREcore dia 25 de outubro em blumenau no
25430 rio bravo bar (proximo a resima agua verde), com as bandas: Zero Ltda
25431 (curitiba), Swallow the Waffle (bc), chymia(bnu), crazy frogs (lages),
25432 surpise set e slipper (bnu)...3 pila entrada inicio as 15:00 horas'
25433 [Oct 18 16:05:31.289032 2003] debug: Received: :|-Frango-| MODE
25434 #EMOCORE -oooooo CHoPP CbRS-oFF caroll BRYAN brunaH balsanelli
25435 Segmentation fault (core dumped)
25438 Debugging my core... i can found:
25439 #0 0x0804d830 in add_mode_with_params (md=0x806aa00, mode=111 'o',
25440 is_add=1, params=1, parambuf=0xbfffe280 "balsanelli",
25441 len=10) at actions.c:568
25442 568 md->params[md->nopmodes][len] = 0;
25444 #0 0x0804d830 in add_mode_with_params (md=0x806aa00, mode=111 'o',
25445 is_add=1, params=1, parambuf=0xbfffe280 "balsanelli",
25446 len=10) at actions.c:568
25448 #1 0x0804d342 in set_cmode (sender=0x81db058 "ChanServ", channel=0xa905d00)
25451 "balsanelli\000\b\025\225\002BWi??\022B\024\032\023Bi??i??i??i??\000\000\000
25452 \000\034 \006\bi??i??i??i??hi??i??i??i??i??i??i??\025\224\004B\034
25453 \006\b\000\000\000\000i??m\tBdi??\022Bi??q\a\b\000\000\000\000eR :\0037[
25454 \0034#\003di??\022B\000\000\000\000i??\037\006\bi??\037\006\bi??i??i??i??$i?
25455 ?\006Bi??i??i??i??\bi??i??i??\000\000\000\000Hi??i??i??\025\224\004B@\002\a\
25456 b8i??i??i??6\020\aBpi??i??i??@i??\006\b@\002\a\b\000\000\000\000i??<\023BLi?
25457 ?i??i??=S\004B\024\032\023B\001\020\000\000@i??\006\bhi??i??i??\204i??\006Bp
25458 i??i??i??i??\037\006\b"...
25463 args = 0xbfffe6d0 "RDcoCOREcorei??i??i??i??o"
25464 modes = 0xbfffeae2 ""
25465 modes_orig = 0xbfffeae0 "+o"
25466 md = (struct modedata *) 0x806aa00
25471 #2 0x400895ff in local_set_cumodes (c=0xa905d00, plusminus=43 '+', modes=1,
25472 nick=0xab7f2e8 "balsanelli") at check.c:432
25474 modestr = "o\000\000 de outubro em blumenau no rio bravo bar
25475 (proximo a resima agua verde), com as bandas: Zero
25476 L\v\000\000\000(curitiba), \000\000\000\000low the Waff\000\000\000\000bc),
25477 chymia(bnu), crazy frogs (lages), surpise set e slipper (bnu).."...
25479 #3 0x40088d74 in check_chan_user_modes (source=0xbfffeed0 "|-Frango-|",
25480 u=0xab34ff0, c=0xa905d00, oldmodes=1)
25482 user = (User *) 0xab7f2d8
25483 ci = (ChannelInfo *) 0xa571940
25487 #4 0x400820ed in do_channel_umode_change (source=0xbfffeed0 "|-Frango-|",
25488 c=0xa905d00, u=0xab34ff0, oldmodes=1)
25491 #5 0x0805890d in call_callback_5 (module=0x806a5c0, id=23, arg1=0xbfffeed0,
25492 arg2=0xa905d00, arg3=0xab34ff0, arg4=0x1,
25493 arg5=0x0) at modules.c:666
25494 cl = (CallbackList *) 0x8077cb8
25497 #6 0x0804edc8 in do_cumode (source=0xbfffeed0 "|-Frango-|", chan=0xa905d00,
25498 flag=1, add=0, nick=0xbfffecc9 "balsanelli")
25499 ---Type <return> to continue, or q <return> to quit---
25501 u = (struct c_userlist *) 0xab34ff0
25502 user = (User *) 0xab7f2d8
25504 #7 0x0804e97e in do_cmode (source=0xbfffeed0 "|-Frango-|", ac=0,
25505 av=0xa853130) at channels.c:302
25508 params = -1073746288
25509 chan = (Channel *) 0xa905d00
25512 modestr = 0xbfffec9e "-oooooo"
25513 #8 0x080557ff in m_mode (source=0xbfffeed0 "|-Frango-|", ac=8,
25514 av=0xa853110) at messages.c:101
25516 #9 0x0805920e in process () at process.c:133
25517 m = (Message *) 0x8067dd8
25519 "|-Frango-|\000\000G\000\000\000Y\e\205\n\t+\205\n\bi??i??i??i??i??\005\b@j\
25520 a\b\000\004\000\000i??\032\205\n\t\000\000\000@j\a\b\216j\a\b(i??i??i??qP\00
25523 "MODE\000\000\000i??8i??i??i??i??\005\b\000\000\000\000i??i??i??i??\000\000\
25524 000\000\000\000\000\000\001H\000\000Pi??i??i??\000Y\a\bVi??\005\b\207j\a\bP\
25525 e\205\n\t\000\000\000i??i??\005\b"
25527 "MODE\000#EMOCORE\000-oooooo\000CHoPP\000CbRS-oFF\000caroll\000BRYAN\000brun
25528 aH\000balsanelli\000 balsanelli\000\000ai\00314ser \0030]\00315=\00314-
25529 S\00315c\0030ri\00315p\00314t \00315\037v\0373.8 \003\000\00315\037v\0373.8
25530 \003\000\000\0003)\000\0006\037\002Pi??Ti??\00313\037\002]\037\002\0036i??i?
25531 ? \000i??Ti??\00313\037\002]\037\002\0036i??i?? \000\000\003\000\000r
25532 \003", '\0' <repeats 11 times>...
25533 s = 0xbfffec95 "#EMOCORE"
25535 av = (char **) 0xa853110
25536 #10 0x0805507d in readline_callback (s=0xa851ae0, param_unused=0x50) at
25539 #11 0x0805b617 in check_sockets () at sockets.c:491
25540 newline = 0xa851b58 "\nrct-sc.br irc.creativenet.com.br 0 3364349034
25541 :aNiNhHa[du]DoNaTeLo\n:Toh_Pensanu PART #ilheus\n:_LoKo_SuL_ SJOIN
25542 1063565447 #elias\n:_MoRgAnA_ PRIVMSG NickServ@services.redesul.net :set
25543 nomemo off\n:irc."...
25546 rfds = {fds_bits = {16, 0 <repeats 31 times>}}
25547 wfds = {fds_bits = {0 <repeats 32 times>}}
25548 tv = {tv_sec = 2, tv_usec = 980000}
25551 s = (Socket *) 0xa851ae0
25552 s2 = (Socket *) 0x0
25553 #12 0x0805538a in main (ac=3, av=0xbffff164, envp=0xbffff174) at main.c:266
25554 ---Type <return> to continue, or q <return> to quit---
25556 now_msec = 1348441861
25557 last_update = 1066500208
25558 last_check = 1348441182
25559 #13 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
25560 No symbol table info available.
25561 (gdb) info registers
25562 eax 0xd6b2bf8a -692928630
25563 ecx 0x806aa00 134654464
25564 edx 0x656e6173 1701732723
25565 ebx 0x42131a14 1108548116
25566 esp 0xbfffd910 0xbfffd910
25567 ebp 0xbfffe238 0xbfffe238
25568 esi 0x8075900 134699264
25569 edi 0xbffff050 -1073745840
25570 eip 0x804d830 0x804d830
25571 eflags 0x10282 66178
25581 root@irc(/home/ircadmin/services/lib)# ls -la core.12631
25582 -rw------- 1 ircadmin ircadmin 47374336 Oct 18 16:05 core.12631
25583 root@irc(/home/ircadmin/services)# ldd ircservices
25584 libdl.so.2 => /lib/libdl.so.2 (0x4001e000)
25585 libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
25586 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
25587 root@irc(/home/ircadmin/services)# uname -a
25588 Linux XXXXXX.xyz.0xdeadbeef 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686
25589 i686 i386 GNU/Linux
25590 root@irc(/home/ircadmin/services)# cat /etc/redhat-release
25591 Red Hat Linux release 9 (Shrike)
25592 root@irc(/home/ircadmin/services)# cat /proc/cpuinfo
25594 model name : Pentium III (Coppermine)
25597 cache size : 256 KB
25599 root@irc(/home/ircadmin/services)# free
25600 total used free shared buffers cached
25601 Mem: 513792 482248 31544 0 69492 274980
25603 I changed version of linux, runned it on 3 different machines, on
25604 slackware/redhat, pentiumIII, K5, P200.
25605 This bug is as older as i run services... dont know if its the same of the
25606 4.X (that i changed to 5.X to "solve" this bug), but from 5.12 to now, it
25607 continue happening... aways...
25608 Dont have a exactly time to happen, its insane... i think that its a
25609 coincidence of some commands that on the memory ends fucking some variable.
25610 if you want look the incidence, here its:
25611 root@irc(/home/ircadmin/services/lib)# ls -la core*
25613 -rw------- 1 ircadmin ircadmin 49025024 Oct 5 19:32 core.27214
25614 -rw------- 1 ircadmin ircadmin 45932544 Oct 5 21:01 core.14414
25615 -rw------- 1 ircadmin ircadmin 46948352 Oct 6 14:00 core.18016
25616 -rw------- 1 ircadmin ircadmin 45936640 Oct 11 04:30 core.1347
25617 -rw------- 1 ircadmin ircadmin 50479104 Oct 14 01:29 core.16481
25618 -rw------- 1 ircadmin ircadmin 44982272 Oct 15 13:54 core.22332
25619 -rw------- 1 ircadmin ircadmin 47374336 Oct 18 16:05 core.12631
25620 -rw------- 1 ircadmin ircadmin 48099328 Oct 19 14:16 core.5362
25621 -rw------- 1 ircadmin ircadmin 44863488 Oct 19 14:22 core.32708
25622 -rw------- 1 ircadmin ircadmin 45355008 Nov 1 15:13 core.28309
25623 -rw------- 1 ircadmin ircadmin 50360320 Nov 3 18:24 core.5160
25626 If it helps, here is the debugging of the last two cores, on gdb:
25629 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
25634 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
25637 chan = (Channel *) 0xa87d1e0
25638 s = 0x1f73746f <Address 0x1f73746f out of bounds>
25640 modestr = 0x1f73746f <Address 0x1f73746f out of bounds>
25641 #1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:680
25642 buf = "-imsl\000HA___\000\000\000\000\000W
25643 \022B\000\000\000L\000\000\000\000\000y\000nossaTZ\000\000\000\000\000\000yy
25644 yyA<\023B\001\000\000\000\bYy?Om\tBd
25645 \022BDq\a\bOUy?NO\006B\210o\a\b3\035\rB\024\032\023BAa\006B\003\000\000\000a
25646 Yy?\027\000\000\000\024\032\023B\024\032\023BTZ\000\000\004\000\000\000\005\
25647 000\000\000\210o\a\baYy?\030Yy?NO\006B\210o\a\baYy?\027\000\000\000$u\006B\2
25648 10o\a\bIo\a\b\vO\006B\024\032\023B\024\032\023B@\002\a\bHYy?$u\006B\200Yy?@o
25650 s = 0xbfffdc60 "-imsl"
25651 argv = {0xa87d1e8 "#soad",
25652 0x1f73746f <Address 0x1f73746f out of bounds>,
25653 0x5303200f <Address 0x5303200f out of bounds>,
25654 0x6c6c6568 <Address 0x6c6c6568 out of bounds>,
25655 0x4323203a <Address 0x4323203a out of bounds>,
25656 0x65746e65 <Address 0x65746e65 out of bounds>,
25657 0x65685372 <Address 0x65685372 out of bounds>,
25658 0x52426c6c <Address 0x52426c6c out of bounds>}
25660 ---Type <return> to continue, or q <return> to quit---
25663 #2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
25667 md = (struct modedata *) 0x0
25672 #3 0x080553a3 in main (ac=1, av=0xbfffe574, envp=0xbfffe57c) at main.c:269
25674 now_msec = -1555790286
25675 last_update = 1067890538
25676 last_check = 2739174210
25677 #4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
25678 No symbol table info available.
25682 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
25687 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
25690 chan = (Channel *) 0xa9be840
25691 s = 0xbf000000 <Address 0xbf000000 out of bounds>
25693 modestr = 0xbf000000 <Address 0xbf000000 out of bounds>
25694 #1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:680
25695 buf = "-imsl\000\a\b\000len\000\000\000\000W
25696 \022B3\035\rB\024\032\023BAa\006B\003\000\000\000
25697 oy?\027\000\000\000yyyyA<\023BTZ\000\000\004\000\000\000\005\000\000\000\210
25698 o\a\b oy?Xoy?NO\006B\210o\a\b
25699 oy?\027\000\000\000$u\006B\210o\a\bIo\a\b\vO\006B\024\032\023B\024\032\023B@
25700 \002\a\b\210oy?$u\006BAoy?@o\006\b@\002\a\b\000\000\000\000\024\032\023B@\00
25701 2\a\b?oy?6\020\aBaoy?@o\006\b@\002\a\b\000\000\000\000Aoy?I\037\006\b=S\004B
25702 \024\032\023B\001\020\000\000@o\006\b"...
25703 s = 0xbffff2e0 "-imsl"
25704 argv = {0xa9be848 "#zoera",
25705 0xbf000000 <Address 0xbf000000 out of bounds>, 0x0,
25706 0x806f240 "ircservices.log", 0x806f240 "ircservices.log",
25707 0x5a54 <Address 0x5a54 out of bounds>, 0x0,
25708 0xffffffff <Address 0xffffffff out of bounds>}
25712 #2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
25713 ---Type <return> to continue, or q <return> to quit---
25717 md = (struct modedata *) 0x0
25722 #3 0x080553a3 in main (ac=1, av=0xbffffbf4, envp=0xbffffbfc) at main.c:269
25724 now_msec = -1740061222
25725 last_update = 1067706282
25726 last_check = 2554904000
25727 #4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
25728 No symbol table info available.
25731 Im running it more a time on Screen to can get exactly where occur the bug
25732 (with -nofork -debug), to look for more examples of commands that causes
25734 if have something (more) that i can to add/do to helps on debugging, please,
25735 tell me.. i have the core (i cant send it, for secure reasons... have all my
25736 db on the core... ), but im open to helps anytime anywhere... with
25739 Thanks for all development, this is really a bealtifull software...
25740 (and sorry for my bad english)
25742 Diego B. Contezini aka destruct_ #irc.redesul.net
25746 From diego at redesul.net Tue Nov 4 16:46:53 2003
25747 From: diego at redesul.net (Diego B. Contezini)
25748 Date: Sat Oct 23 23:10:00 2004
25749 Subject: [IRCServices Coding] about.. CORE DUMPED! BUG!
25750 Message-ID: <01fa01c3a336$4e884220$3cc8a8c0@angel>
25752 If it helps, im using Bahamut here....
25755 From achurch at achurch.org Wed Nov 5 13:20:15 2003
25756 From: achurch at achurch.org (Andrew Church)
25757 Date: Sat Oct 23 23:10:00 2004
25758 Subject: [IRCServices Coding] Bug or misunderstood ?
25759 In-Reply-To: <000901c39496$71764f10$a37faec3@coder>
25760 Message-ID: <3fa87c99.57222@achurch.org>
25762 >Im using unreal ircd. When channel is empty and if channel owner joins
25763 >his/her registered channel it does
25764 >(ChanServ sets mode: +ntrq nick) but when channel is not empty and if
25765 >channel owner joins his/her registered channel it does (ChanServ sets mode:
25766 >+oq nick nick). As you see on the first one there is no +o and because of
25767 >this chanserv does not update the last_used time because chanserv is set to
25768 >update last_used time with +o (CUMODE_o) so channels drop while channel
25769 >owners use them. Is this a bug or my misunderstood ?
25771 This is a bug; I've fixed it for the next release, thanks for the
25772 report. As regards your other message, not setting the last-used time for
25773 +a/+q users is designed behavior (see section 3-2-1 of the manual: "`used'
25774 means that a user with auto-op privileges ... has entered the channel"), as
25775 well as unnecessary in typical channel settings (where +a users are a
25776 subset of +o users), but if you have any better suggestions on how to
25777 determine when a channel is being used by proper users as opposed to (for
25778 example) spammers or people just entering to see if the channel is
25779 available, I'm willing to listen.
25782 achurch@achurch.org
25783 http://achurch.org/
25785 From andrewk at isdial.net Tue Aug 26 02:43:45 2003
25786 From: andrewk at isdial.net (Andrew Kempe)
25787 Date: Sat Oct 23 23:10:00 2004
25788 Subject: [IRCServices Coding] test
25789 Message-ID: <005801c36bb6$85bbc080$1f0912ac@espotting.com>
25793 From us44ever at hotmail.com Thu Aug 28 09:45:48 2003
25794 From: us44ever at hotmail.com (us44ever .)
25795 Date: Sat Oct 23 23:10:00 2004
25796 Subject: [IRCServices Coding] Yet, another great suggestion
25797 Message-ID: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
25801 it would be really great to add another new line to the "/nickserv info"
25802 command, for example, when some one types: "/nickserv info nick", the
25803 following will be shown:
25805 ***************************
25807 -NickServ- nick is hello world
25809 -NickServ- Is online from: ~test@just.a.test.co.za
25811 -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
25813 -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
25815 -NickServ- Last quit message: anythinggggg
25817 -NickServ- Options: Kill protection, Security
25819 ***************************
25821 the new line I'm suggesting is something like:
25823 ***************************
25824 -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
25825 ***************************
25827 This will help our users to compare the time that user was last seen and the
25828 time right now *it's very important, many many of our users asked us for
25829 this option*, also it would even be more great to show how long last time
25830 the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003 GMT
25831 (last seen time was before: 10 days, 3hours and 24 sec ago).
25833 Note that I saw both of these features, in other services I don't remember
25834 there names (but they aren't as stable as ircservices5) (it was something
25835 like ptlink services, and magik II)
25837 That's all, I would really like to see it on the next version (or if you can
25838 show me how to do it, as I'm not a programmer)
25840 Many thanks to all of who developed IRCservices ...etc ...etc ...etc
25845 _________________________________________________________________
25846 Get MSN 8 and enjoy automatic e-mail virus protection.
25847 http://join.msn.com/?page=features/virus
25850 From aragon at phat.za.net Thu Aug 28 11:36:22 2003
25851 From: aragon at phat.za.net (Aragon Gouveia)
25852 Date: Sat Oct 23 23:10:00 2004
25853 Subject: [IRCServices Coding] Yet, another great suggestion
25854 In-Reply-To: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
25855 References: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
25856 Message-ID: <20030828183615.GB32204@phat.za.net>
25858 Or how about rather letting users decide what timezone they're in and
25859 services outputs all timestamps in their local time?
25862 | By us44ever . <us44ever@hotmail.com>
25863 | [ 2003-08-28 18:45 +0200 ]
25866 > it would be really great to add another new line to the "/nickserv info"
25867 > command, for example, when some one types: "/nickserv info nick", the
25868 > following will be shown:
25870 > ***************************
25872 > -NickServ- nick is hello world
25874 > -NickServ- Is online from: ~test@just.a.test.co.za
25876 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
25878 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
25880 > -NickServ- Last quit message: anythinggggg
25882 > -NickServ- Options: Kill protection, Security
25884 > ***************************
25886 > the new line I'm suggesting is something like:
25888 > ***************************
25889 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
25890 > ***************************
25892 > This will help our users to compare the time that user was last seen and
25893 > the time right now *it's very important, many many of our users asked us
25894 > for this option*, also it would even be more great to show how long last
25895 > time the user was seen (some thing like: Last seen time: Aug 28 15:51:14
25896 > 2003 GMT (last seen time was before: 10 days, 3hours and 24 sec ago).
25898 > Note that I saw both of these features, in other services I don't remember
25899 > there names (but they aren't as stable as ircservices5) (it was something
25900 > like ptlink services, and magik II)
25902 > That's all, I would really like to see it on the next version (or if you
25903 > can show me how to do it, as I'm not a programmer)
25905 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
25910 > _________________________________________________________________
25911 > Get MSN 8 and enjoy automatic e-mail virus protection.
25912 > http://join.msn.com/?page=features/virus
25914 > ------------------------------------------------------------------
25915 > To unsubscribe or change your subscription options, visit:
25916 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
25918 From saturn at jetirc.net Thu Aug 28 11:39:41 2003
25919 From: saturn at jetirc.net (Saturn)
25920 Date: Sat Oct 23 23:10:00 2004
25921 Subject: [IRCServices Coding] Yet, another great suggestion
25922 References: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
25923 <20030828183615.GB32204@phat.za.net>
25924 Message-ID: <003201c36d93$abf77fd0$6401a8c0@turby>
25926 Oooo now I like that option... have it default to a default timezone, set in
25927 the conf file, and give them the option of SETting a different UTC code
25928 (have it as GMT + or - x wheer x is the offset from UTC)... It may not
25929 sound liek much, but I bet people will use it, and what's more, it IS useful
25930 information, especially on international servers like mine.. we have people
25931 from all over the place, and we keep services set on Pacific time... but for
25932 those in, say, Belgium... that's not very helpful
25934 ----- Original Message -----
25935 From: "Aragon Gouveia" <aragon@phat.za.net>
25936 To: <ircservices-coding@ircservices.za.net>
25937 Sent: Thursday, August 28, 2003 11:36 AM
25938 Subject: Re: [IRCServices Coding] Yet, another great suggestion
25941 Or how about rather letting users decide what timezone they're in and
25942 services outputs all timestamps in their local time?
25945 | By us44ever . <us44ever@hotmail.com>
25946 | [ 2003-08-28 18:45 +0200 ]
25949 > it would be really great to add another new line to the "/nickserv info"
25950 > command, for example, when some one types: "/nickserv info nick", the
25951 > following will be shown:
25953 > ***************************
25955 > -NickServ- nick is hello world
25957 > -NickServ- Is online from: ~test@just.a.test.co.za
25959 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
25961 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
25963 > -NickServ- Last quit message: anythinggggg
25965 > -NickServ- Options: Kill protection, Security
25967 > ***************************
25969 > the new line I'm suggesting is something like:
25971 > ***************************
25972 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
25973 > ***************************
25975 > This will help our users to compare the time that user was last seen and
25976 > the time right now *it's very important, many many of our users asked us
25977 > for this option*, also it would even be more great to show how long last
25978 > time the user was seen (some thing like: Last seen time: Aug 28 15:51:14
25979 > 2003 GMT (last seen time was before: 10 days, 3hours and 24 sec ago).
25981 > Note that I saw both of these features, in other services I don't remember
25982 > there names (but they aren't as stable as ircservices5) (it was something
25983 > like ptlink services, and magik II)
25985 > That's all, I would really like to see it on the next version (or if you
25986 > can show me how to do it, as I'm not a programmer)
25988 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
25993 > _________________________________________________________________
25994 > Get MSN 8 and enjoy automatic e-mail virus protection.
25995 > http://join.msn.com/?page=features/virus
25997 > ------------------------------------------------------------------
25998 > To unsubscribe or change your subscription options, visit:
25999 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
26000 ------------------------------------------------------------------
26001 To unsubscribe or change your subscription options, visit:
26002 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
26006 From Craig at chatspike.net Thu Aug 28 14:29:54 2003
26007 From: Craig at chatspike.net (Craig McLure)
26008 Date: Sat Oct 23 23:10:00 2004
26009 Subject: [IRCServices Coding] Yet, another great suggestion
26010 Message-ID: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
26012 Please dont post to both the services main list, and the services coding list. Choose one, or the other, especially concidering i dont think this is a great suggestion either..
26014 /time services.chatspike.net
26015 [22:28]
\95\95\95 Date / time at services.chatspike.net- Thu Aug 28 17:28:57 2003 EDT
26019 /****************************************
26020 * Craig "FrostyCoolSlug" McLure
26021 ************* - SpamBox - **************
26022 * InspIRCd - http://www.inspircd.org
26023 * ChatSpike - http://www.chatspike.net
26024 * WinBot - http://www.winbot.co.uk
26025 ****************************************/
26027 /****************************************
26028 * From - us44ever . <us44ever@hotmail.com>
26029 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
26030 * Sent - 2003-08-28 @ 16:45:00
26031 * Subject - [IRCServices Coding] Yet, another great suggestion
26032 ****************************************/
26034 /****** - Begin Original Message - ******/
26038 >it would be really great to add another new line to the "/nickserv info"
26039 >command, for example, when some one types: "/nickserv info nick", the
26040 >following will be shown:
26042 >***************************
26044 >-NickServ- nick is hello world
26046 >-NickServ- Is online from: ~test@just.a.test.co.za
26048 >-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
26050 >-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
26052 >-NickServ- Last quit message: anythinggggg
26054 >-NickServ- Options: Kill protection, Security
26056 >***************************
26058 >the new line I'm suggesting is something like:
26060 >***************************
26061 >-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
26062 >***************************
26064 >This will help our users to compare the time that user was last seen and the
26065 >time right now *it's very important, many many of our users asked us for
26066 >this option*, also it would even be more great to show how long last time
26067 >the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003 GMT
26068 >(last seen time was before: 10 days, 3hours and 24 sec ago).
26070 >Note that I saw both of these features, in other services I don't remember
26071 >there names (but they aren't as stable as ircservices5) (it was something
26072 >like ptlink services, and magik II)
26074 >That's all, I would really like to see it on the next version (or if you can
26075 >show me how to do it, as I'm not a programmer)
26077 >Many thanks to all of who developed IRCservices ...etc ...etc ...etc
26082 >_________________________________________________________________
26083 >Get MSN 8 and enjoy automatic e-mail virus protection.
26084 >http://join.msn.com/?page=features/virus
26086 >------------------------------------------------------------------
26087 >To unsubscribe or change your subscription options, visit:
26088 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
26090 /******* - End Original Message - *******/
26095 From nothing at psychopat.org Thu Aug 28 14:57:31 2003
26096 From: nothing at psychopat.org (Marc-Andre A. Fuentes)
26097 Date: Sat Oct 23 23:10:00 2004
26098 Subject: [IRCServices Coding] BUG Report
26099 Message-ID: <001501c36daf$c8cba700$0101a8c0@house>
26101 We're having a small problem with suspended channel.
26103 we suspended channel #kavala, and someone has identified itself has the founder and apply a DROP to the channel.
26104 then we got a panic from the services and... crash.
26106 Also with suspended nick , when the suspencion expire, the services crash
26109 ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
26114 -------------- next part --------------
26115 An HTML attachment was scrubbed...
26116 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030828/1f31ccf5/attachment-0001.html
26117 From Craig at chatspike.net Thu Aug 28 15:24:36 2003
26118 From: Craig at chatspike.net (Craig McLure)
26119 Date: Sat Oct 23 23:10:00 2004
26120 Subject: [IRCServices Coding] BUG Report
26121 Message-ID: <20030828222401.JVQE12036.mta4-svc.business.ntl.com@i-br0ked-it>
26123 hmm.. what OS, compiler version etc are you using?
26125 after a test, i got the following:
26127 /cs id #abc 00376370
26128 -ChanServ- Channel #abc is suspended and may not be used or identified for.
26131 [23:20] -ChanServ- Channel is suspended and may not be used or identified for.
26133 only prob i got was it missed the channel name in the second message :)
26136 /****************************************
26137 * Craig "FrostyCoolSlug" McLure
26138 ************* - SpamBox - **************
26139 * InspIRCd - http://www.inspircd.org
26140 * ChatSpike - http://www.chatspike.net
26141 * WinBot - http://www.winbot.co.uk
26142 ****************************************/
26144 /****************************************
26145 * From - Marc-Andre A. Fuentes <nothing@psychopat.org>
26146 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
26147 * Sent - 2003-08-28 @ 18:00:00
26148 * Subject - [IRCServices Coding] BUG Report
26149 ****************************************/
26151 /****** - Begin Original Message - ******/
26153 >We're having a small problem with suspended channel.
26155 >we suspended channel #kavala, and someone has identified itself has the founder and apply a DROP to the channel.
26156 >then we got a panic from the services and... crash.
26158 >Also with suspended nick , when the suspencion expire, the services crash
26161 >ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
26166 >------------------------------------------------------------------
26167 >To unsubscribe or change your subscription options, visit:
26168 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
26170 /******* - End Original Message - *******/
26175 From saturn at jetirc.net Thu Aug 28 17:13:48 2003
26176 From: saturn at jetirc.net (Saturn)
26177 Date: Sat Oct 23 23:10:00 2004
26178 Subject: [IRCServices Coding] AKill suggestion
26179 References: <2C31F186-CDEE-11D7-979C-0003938D6866@mac.com>
26180 Message-ID: <009001c36dc2$64b56b80$6401a8c0@turby>
26182 Would it be possible to have it announce to the user when they are akilled,
26183 either the expiry date and time, or "Expires in 3days, 4hours, 6minutes" or
26184 something similar. I find that usually we just have to do 24hour bans, but
26185 the user has no way to know when the ban was set, and when it expires...
26187 Just an idea... I now await the half dozen people who will proceed to tell
26188 me how stupid my idea is....
26195 From playa at dreamchat.org Thu Aug 28 20:46:19 2003
26196 From: playa at dreamchat.org (playa)
26197 Date: Sat Oct 23 23:10:00 2004
26198 Subject: [IRCServices Coding] Yet, another great suggestion
26199 In-Reply-To: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
26200 References: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
26201 Message-ID: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
26203 Is this /time command only supposed to work via RAW? Cause when i type
26204 /time services.dreamchat.org i get No Such User, but if i do /raw time
26205 services.dreamchat.org, it works. Just wondering if its just me, or if
26206 its supposed to be that way.
26208 > Please dont post to both the services main list, and the services coding
26209 > list. Choose one, or the other, especially concidering i dont think this
26210 > is a great suggestion either..
26212 > /time services.chatspike.net
26213 > [22:28] ??? Date / time at services.chatspike.net- Thu Aug 28 17:28:57
26218 > /****************************************
26219 > * Craig "FrostyCoolSlug" McLure
26220 > ************* - SpamBox - **************
26221 > * InspIRCd - http://www.inspircd.org
26222 > * ChatSpike - http://www.chatspike.net
26223 > * WinBot - http://www.winbot.co.uk
26224 > ****************************************/
26226 > /****************************************
26227 > * From - us44ever . <us44ever@hotmail.com>
26228 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
26229 > * Sent - 2003-08-28 @ 16:45:00
26230 > * Subject - [IRCServices Coding] Yet, another great suggestion
26231 > ****************************************/
26233 > /****** - Begin Original Message - ******/
26237 >>it would be really great to add another new line to the "/nickserv info"
26238 >>command, for example, when some one types: "/nickserv info nick", the
26239 >>following will be shown:
26241 >>***************************
26243 >>-NickServ- nick is hello world
26245 >>-NickServ- Is online from: ~test@just.a.test.co.za
26247 >>-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
26249 >>-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
26251 >>-NickServ- Last quit message: anythinggggg
26253 >>-NickServ- Options: Kill protection, Security
26255 >>***************************
26257 >>the new line I'm suggesting is something like:
26259 >>***************************
26260 >>-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
26261 >>***************************
26263 >>This will help our users to compare the time that user was last seen and
26265 >>time right now *it's very important, many many of our users asked us for
26266 >>this option*, also it would even be more great to show how long last time
26267 >>the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003
26269 >>(last seen time was before: 10 days, 3hours and 24 sec ago).
26271 >>Note that I saw both of these features, in other services I don't
26273 >>there names (but they aren't as stable as ircservices5) (it was something
26274 >>like ptlink services, and magik II)
26276 >>That's all, I would really like to see it on the next version (or if you
26278 >>show me how to do it, as I'm not a programmer)
26280 >>Many thanks to all of who developed IRCservices ...etc ...etc ...etc
26285 >>_________________________________________________________________
26286 >>Get MSN 8 and enjoy automatic e-mail virus protection.
26287 >>http://join.msn.com/?page=features/virus
26289 >>------------------------------------------------------------------
26290 >>To unsubscribe or change your subscription options, visit:
26291 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
26293 > /******* - End Original Message - *******/
26297 > ------------------------------------------------------------------
26298 > To unsubscribe or change your subscription options, visit:
26299 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
26306 Network Founder/CEO
26307 DreamChat IRC Network - irc.dreamchat.org
26308 http://www.dreamchat.org
26311 From quension at mac.com Thu Aug 28 21:13:48 2003
26312 From: quension at mac.com (Trevor Talbot)
26313 Date: Sat Oct 23 23:10:00 2004
26314 Subject: [IRCServices Coding] Yet, another great suggestion
26315 In-Reply-To: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
26316 Message-ID: <0F823090-D9D7-11D7-8513-0003938D6866@mac.com>
26318 On Thursday, Aug 28, 2003, at 20:46 US/Pacific, playa wrote:
26320 > Is this /time command only supposed to work via RAW? Cause when i
26321 > type /time services.dreamchat.org i get No Such User, but if i do /raw
26322 > time services.dreamchat.org, it works. Just wondering if its just me,
26323 > or if its supposed to be that way.
26325 That's a client thing. Some clients might alias /time as a CTCP TIME
26326 for a specific user, or similar.
26331 From r-krisztian at softhome.net Thu Aug 28 22:12:51 2003
26332 From: r-krisztian at softhome.net (Krisztian Romek)
26333 Date: Sat Oct 23 23:10:00 2004
26334 Subject: [IRCServices Coding] Yet, another great suggestion
26335 In-Reply-To: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
26336 References: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
26337 <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
26338 Message-ID: <200308290713.29423.r-krisztian@softhome.net>
26340 > Is this /time command only supposed to work via RAW? Cause when i type
26341 > /time services.dreamchat.org i get No Such User, but if i do /raw time
26342 > services.dreamchat.org, it works. Just wondering if its just me, or if
26343 > its supposed to be that way.
26345 Some clients use stupid aliases for CTCP commands, for example:
26347 /version <nick> = /CTCP <nick> VERSION,
26348 /time <nick> = /CTCP <nick> TIME,
26349 /finger <nick> = /CTCP <nick> TIME
26351 This is why nothing works the way you expected.
26355 r-krisztian@softhome.net
26358 From us44ever at hotmail.com Fri Aug 29 13:02:19 2003
26359 From: us44ever at hotmail.com (us44ever .)
26360 Date: Sat Oct 23 23:10:00 2004
26361 Subject: [IRCServices Coding] AKill suggestion
26362 Message-ID: <Sea1-F108cM3oryKFRJ0000eb75@hotmail.com>
26364 Pretty good idea, specially is it would be implemented as an option (because
26365 some admins might won't like the idea of displaying the time of when the
26366 akill will expire to the user who has been akilled).
26368 _________________________________________________________________
26369 Help protect your PC: Get a free online virus scan at McAfee.com.
26370 http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
26373 From us44ever at hotmail.com Fri Aug 29 13:09:51 2003
26374 From: us44ever at hotmail.com (us44ever .)
26375 Date: Sat Oct 23 23:10:00 2004
26376 Subject: [IRCServices Coding] Yet, another great suggestion
26377 Message-ID: <Sea1-F127z33hqSnMGE000094b3@hotmail.com>
26380 Since most people want to see this feature(s) in the next version, it would
26381 be great to implement it as an optional feature , where it can be disabled
26382 from the .conf file(s) or enable it easily. I don't think that there is
26383 anything that the authors will lose if this feature can be added, in fact,
26384 it will add another nice feature to the features list of IRCservices5.
26386 _________________________________________________________________
26387 Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
26388 using MSN Messenger http://entertainment.msn.com/imastar
26391 From Craig at chatspike.net Fri Aug 29 13:41:59 2003
26392 From: Craig at chatspike.net (Craig McLure)
26393 Date: Sat Oct 23 23:10:00 2004
26394 Subject: [IRCServices Coding] Yet, another great suggestion
26395 Message-ID: <20030829204143.NNNT26404.mta1-svc.business.ntl.com@i-br0ked-it>
26397 I'll ask again.. can you please stop posting to both the IRCServices mailing list, and the IRCd coding mailing list, getting your mail 2ce is beginning to annoy me.
26399 And i'll Quote Elijah:
26401 "Except it's already been said in the FAQ that it's not going to happen, and
26402 if that made it into the FAQ it would seem the answer is frequently going to
26406 /****************************************
26407 * Craig "FrostyCoolSlug" McLure
26408 ************* - SpamBox - **************
26409 * InspIRCd - http://www.inspircd.org
26410 * ChatSpike - http://www.chatspike.net
26411 * WinBot - http://www.winbot.co.uk
26412 ****************************************/
26414 /****************************************
26415 * From - us44ever . <us44ever@hotmail.com>
26416 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
26417 * Sent - 2003-08-29 @ 20:09:00
26418 * Subject - Re: [IRCServices Coding] Yet, another great suggestion
26419 ****************************************/
26421 /****** - Begin Original Message - ******/
26423 >Since most people want to see this feature(s) in the next version, it would
26424 >be great to implement it as an optional feature , where it can be disabled
26425 >from the .conf file(s) or enable it easily. I don't think that there is
26426 >anything that the authors will lose if this feature can be added, in fact,
26427 >it will add another nice feature to the features list of IRCservices5.
26429 >_________________________________________________________________
26430 >Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
26431 >using MSN Messenger http://entertainment.msn.com/imastar
26433 >------------------------------------------------------------------
26434 >To unsubscribe or change your subscription options, visit:
26435 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
26438 /******* - End Original Message - *******/
26443 From Craig at chatspike.net Fri Aug 29 13:43:24 2003
26444 From: Craig at chatspike.net (Craig McLure)
26445 Date: Sat Oct 23 23:10:00 2004
26446 Subject: [IRCServices Coding] AKill suggestion
26447 Message-ID: <20030829204311.GHCL29825.mta5-svc.business.ntl.com@i-br0ked-it>
26449 its a stupid idea!!! :p
26451 j/k.. I think its a great idea.. i'd rather have services telling users when their akills expire, than them spamming my mailbox with 'when does my akill expire?' every 20mins :p
26453 /****************************************
26454 * Craig "FrostyCoolSlug" McLure
26455 ************* - SpamBox - **************
26456 * InspIRCd - http://www.inspircd.org
26457 * ChatSpike - http://www.chatspike.net
26458 * WinBot - http://www.winbot.co.uk
26459 ****************************************/
26461 /****************************************
26462 * From - Saturn <saturn@jetirc.net>
26463 * To - IRC Services Coding Mailing List <ircservices-coding@ircservices.za.net>
26464 * Sent - 2003-08-28 @ 17:13:00
26465 * Subject - [IRCServices Coding] AKill suggestion
26466 ****************************************/
26468 /****** - Begin Original Message - ******/
26470 >Would it be possible to have it announce to the user when they are akilled,
26471 >either the expiry date and time, or "Expires in 3days, 4hours, 6minutes" or
26472 >something similar. I find that usually we just have to do 24hour bans, but
26473 >the user has no way to know when the ban was set, and when it expires...
26475 >Just an idea... I now await the half dozen people who will proceed to tell
26476 >me how stupid my idea is....
26482 >------------------------------------------------------------------
26483 >To unsubscribe or change your subscription options, visit:
26484 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
26486 /******* - End Original Message - *******/
26491 From admin at nevernet.net Fri Aug 29 13:48:01 2003
26492 From: admin at nevernet.net (Elijah)
26493 Date: Sat Oct 23 23:10:00 2004
26494 Subject: [IRCServices Coding] Yet, another great suggestion
26495 In-Reply-To: <20030829204143.NNNT26404.mta1-svc.business.ntl.com@i-br0ked-it>
26496 Message-ID: <008f01c36e6e$83158770$436a3a44@slytherin>
26500 -----Original Message-----
26501 From: ircservices-coding-bounces@ircservices.za.net
26502 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of Craig
26504 Sent: Friday, August 29, 2003 4:41 PM
26505 To: IRC Services Coding Mailing List
26506 Subject: Re: Re: [IRCServices Coding] Yet, another great suggestion
26509 I'll ask again.. can you please stop posting to both the IRCServices mailing
26510 list, and the IRCd coding mailing list, getting your mail 2ce is beginning
26513 And i'll Quote Elijah:
26515 "Except it's already been said in the FAQ that it's not going to happen, and
26516 if that made it into the FAQ it would seem the answer is frequently going to
26521 From us44ever at hotmail.com Fri Aug 29 16:59:31 2003
26522 From: us44ever at hotmail.com (us44ever .)
26523 Date: Sat Oct 23 23:10:00 2004
26524 Subject: [IRCServices Coding] Yet, another great suggestion
26525 Message-ID: <Sea1-F30z1oyZF58m3O00035b82@hotmail.com>
26527 woops, ok sorry I thought the two e-mails is completely different.
26530 >From: "Craig McLure" <Craig@chatspike.net>
26531 >Reply-To: IRC Services Coding Mailing List
26532 ><ircservices-coding@ircservices.za.net>
26533 >To: IRC Services Coding Mailing List
26534 ><ircservices-coding@ircservices.za.net>
26535 >Subject: Re: Re: [IRCServices Coding] Yet, another great suggestion
26536 >Date: Fri, 29 Aug 2003 21:41:23 +0000
26538 >I'll ask again.. can you please stop posting to both the IRCServices
26539 >mailing list, and the IRCd coding mailing list, getting your mail 2ce is
26540 >beginning to annoy me.
26542 >And i'll Quote Elijah:
26544 >"Except it's already been said in the FAQ that it's not going to happen,
26546 >if that made it into the FAQ it would seem the answer is frequently going
26551 >/****************************************
26552 > * Craig "FrostyCoolSlug" McLure
26553 > ************* - SpamBox - **************
26554 > * InspIRCd - http://www.inspircd.org
26555 > * ChatSpike - http://www.chatspike.net
26556 > * WinBot - http://www.winbot.co.uk
26557 > ****************************************/
26559 >/****************************************
26560 > * From - us44ever . <us44ever@hotmail.com>
26561 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
26562 > * Sent - 2003-08-29 @ 20:09:00
26563 > * Subject - Re: [IRCServices Coding] Yet, another great suggestion
26564 > ****************************************/
26566 >/****** - Begin Original Message - ******/
26568 > >Since most people want to see this feature(s) in the next version, it
26570 > >be great to implement it as an optional feature , where it can be
26572 > >from the .conf file(s) or enable it easily. I don't think that there is
26573 > >anything that the authors will lose if this feature can be added, in
26575 > >it will add another nice feature to the features list of IRCservices5.
26577 > >_________________________________________________________________
26578 > >Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
26579 > >using MSN Messenger http://entertainment.msn.com/imastar
26581 > >------------------------------------------------------------------
26582 > >To unsubscribe or change your subscription options, visit:
26583 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
26586 >/******* - End Original Message - *******/
26590 >------------------------------------------------------------------
26591 >To unsubscribe or change your subscription options, visit:
26592 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
26594 _________________________________________________________________
26595 MSN 8: Get 6 months for $9.95/month. http://join.msn.com/?page=dept/dialup
26598 From simorgh at dataphone.se Sat Aug 30 08:27:11 2003
26599 From: simorgh at dataphone.se (Ali Simorgh)
26600 Date: Sat Oct 23 23:10:00 2004
26601 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
26602 In-Reply-To: <MKEGJINFADFODDNOKEJCMEEADPAA.rg@tcslon.com>
26603 Message-ID: <Pine.GSO.4.31.0308301716410.15629-100000@nikson.dataphone.se>
26606 I run ircservices 5.0.21 on FreeBSD 4.8-STABLE. and Ultimate 3.*
26607 I get this in logfile:
26609 [Aug 30 10:51:19 2003] unknown message from server
26610 (NETCTRL 0 0 0 0 0 0 0 0 0 0 0 0 0)
26611 [Aug 30 10:51:19 2003] user: New maximum user count: 1
26612 [Aug 30 10:51:19 2003] unknown message from server
26613 (:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
26614 [Aug 30 10:51:19 2003] user: New maximum user count: 2
26615 [Aug 30 10:51:19 2003] unknown message from server
26616 (:irc.MyNet.Net SETHOST pedarkhAnde 6b45bb2.26d9672f.dataphone.se)
26617 [Aug 30 10:56:18 2003] mail/sendmail:
26618 /usr/sbin/sendmail exited with code 25600
26619 [Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
26620 registration (Simorgh)
26622 and how can I do so that nickserv dont show the realhost of a user in
26629 ______________________________________________________
26630 Many of life's failures are people who did not realize
26631 how close they were to success when they gave up.
26633 ______________________________________________________
26638 From jskam at shaw.ca Sat Aug 30 11:34:35 2003
26639 From: jskam at shaw.ca (Jeffery Kam)
26640 Date: Sat Oct 23 23:10:00 2004
26641 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
26642 In-Reply-To: <Pine.GSO.4.31.0308301716410.15629-100000@nikson.dataphone.se>
26643 Message-ID: <000001c36f25$58464860$f64f9144@weed>
26645 "and how can I do so that nickserv dont show the realhost of a user in
26646 'ns info nick all'"
26648 This would be a great feature for sure. I know on my network, there is
26649 a custom user mode +d, which will disguise a user's host in a /whois
26650 reply, but services info doesn't show it disguised unless the HIDE
26655 From achurch at achurch.org Sat Aug 30 16:14:47 2003
26656 From: achurch at achurch.org (Andrew Church)
26657 Date: Sat Oct 23 23:10:00 2004
26658 Subject: [IRCServices Coding] MARK Command
26659 In-Reply-To: <3208.66.181.69.244.1060800845.squirrel@dreamchat.org>
26660 Message-ID: <3f512fdb.01666@achurch.org>
26662 Use E-mail if you need communication of that sort.
26665 achurch@achurch.org
26666 http://achurch.org/
26668 >First off, i would like to say that IRCservices are the best services out
26669 >there, by FAR! Anyways, i was wondering if the MARK command will be in
26670 >the next relase? Its kind of a pointless command, its only used to mark
26671 >nicks or channels, but it is very useful for when passwords to channels
26674 >/chanserv MARK <channel> <reason>
26676 >/chanserv info #channel would read the following.
26677 >*#channel has been MARKED by playa - <reason>
26679 >Of course only IRCops would be able to view it.
26681 >Just an idea i thought of :)
26686 >Network Founder/CEO
26687 >DreamChat IRC Network - irc.dreamchat.org
26688 >http://www.dreamchat.org
26690 >------------------------------------------------------------------
26691 >To unsubscribe or change your subscription options, visit:
26692 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
26694 From achurch at achurch.org Sat Aug 30 16:17:44 2003
26695 From: achurch at achurch.org (Andrew Church)
26696 Date: Sat Oct 23 23:10:00 2004
26697 Subject: [IRCServices Coding] OP/Voice upon identify
26698 In-Reply-To: <Pine.GSO.4.31.0308211027350.6118-100000@nikson.dataphone.se>
26699 Message-ID: <3f513092.01677@achurch.org>
26701 Needless complexity. If you don't want yourself autoopped, then don't
26702 be an auto-op. It's that simple.
26705 achurch@achurch.org
26706 http://achurch.org/
26709 >Its nice with this option. but I dont se any set command that ChanServ
26710 >wont automatically op or voice you in any channel.
26713 > SET NOAUTO ON|OFF
26714 > When NOAUTO is on, ChanServ will not
26715 > automatically op or voice you in any channels.
26717 >Maybe some user(s) wont get auto op/voice then they can set this option ON
26718 >but it sould be OFF in default.
26725 > ______________________________________________________
26726 > Many of life's failures are people who did not realize
26727 > how close they were to success when they gave up.
26729 > ______________________________________________________
26732 >On Sun, 17 Aug 2003, Russell Garrett wrote:
26734 >> Eh? This has been implemented since IRCServices 5a31.
26738 >> > I wonder if its possible to make some modification that:
26739 >> > when someone has already joined a few channels, and then identifies
26740 >> > to its nickname, chanserv gives Voice and/or Op to the user is s/he
26741 >> > is in the channel list (+o; aop or above & +v when vop)
26743 >> > this is very usefull to not privmsg chanserv for every op or voice
26744 >> > request, when user has not identified to its nick before joining
26747 >> > Thanks for any help
26749 >> ------------------------------------------------------------------
26750 >> To unsubscribe or change your subscription options, visit:
26751 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
26754 >------------------------------------------------------------------
26755 >To unsubscribe or change your subscription options, visit:
26756 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
26758 From l8nite at l8nite.net Sat Aug 30 16:58:16 2003
26759 From: l8nite at l8nite.net (Shaun Guth)
26760 Date: Sat Oct 23 23:10:00 2004
26761 Subject: [IRCServices Coding] OP/Voice upon identify
26762 In-Reply-To: <3f513092.01677@achurch.org>
26763 References: <3f513092.01677@achurch.org>
26764 Message-ID: <1062287885.21924.6.camel@localhost>
26766 On Sun, 2003-08-31 at 01:16, Andrew Church wrote:
26767 > Needless complexity. If you don't want yourself autoopped, then don't
26768 > be an auto-op. It's that simple.
26770 I disagree. In my case, I wanted to create a channel where there were
26771 no ops so users don't have to endure lame op-wars, etc. However, I did
26772 need to maintain a level of control over the channel to protect from
26773 extremely obnoxious behavior or lame bots, etc. By registering as
26774 founder of the channel I induced the unwanted 'auto-op' behavior. My
26775 only solution was to register another fake user to become channel
26776 founder and set their nick to noexpire. That to me seems like needless
26777 complexity. A simple check to see if the user wishes to be opped or not
26783 From andrewk at isdial.net Tue Aug 26 02:43:45 2003
26784 From: andrewk at isdial.net (Andrew Kempe)
26785 Date: Sat Oct 23 23:10:00 2004
26786 Subject: [IRCServices Coding] test
26787 Message-ID: <005801c36bb6$85bbc080$1f0912ac@espotting.com>
26791 From us44ever at hotmail.com Thu Aug 28 09:45:48 2003
26792 From: us44ever at hotmail.com (us44ever .)
26793 Date: Sat Oct 23 23:10:00 2004
26794 Subject: [IRCServices Coding] Yet, another great suggestion
26795 Message-ID: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
26799 it would be really great to add another new line to the "/nickserv info"
26800 command, for example, when some one types: "/nickserv info nick", the
26801 following will be shown:
26803 ***************************
26805 -NickServ- nick is hello world
26807 -NickServ- Is online from: ~test@just.a.test.co.za
26809 -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
26811 -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
26813 -NickServ- Last quit message: anythinggggg
26815 -NickServ- Options: Kill protection, Security
26817 ***************************
26819 the new line I'm suggesting is something like:
26821 ***************************
26822 -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
26823 ***************************
26825 This will help our users to compare the time that user was last seen and the
26826 time right now *it's very important, many many of our users asked us for
26827 this option*, also it would even be more great to show how long last time
26828 the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003 GMT
26829 (last seen time was before: 10 days, 3hours and 24 sec ago).
26831 Note that I saw both of these features, in other services I don't remember
26832 there names (but they aren't as stable as ircservices5) (it was something
26833 like ptlink services, and magik II)
26835 That's all, I would really like to see it on the next version (or if you can
26836 show me how to do it, as I'm not a programmer)
26838 Many thanks to all of who developed IRCservices ...etc ...etc ...etc
26843 _________________________________________________________________
26844 Get MSN 8 and enjoy automatic e-mail virus protection.
26845 http://join.msn.com/?page=features/virus
26848 From aragon at phat.za.net Thu Aug 28 11:36:22 2003
26849 From: aragon at phat.za.net (Aragon Gouveia)
26850 Date: Sat Oct 23 23:10:00 2004
26851 Subject: [IRCServices Coding] Yet, another great suggestion
26852 In-Reply-To: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
26853 References: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
26854 Message-ID: <20030828183615.GB32204@phat.za.net>
26856 Or how about rather letting users decide what timezone they're in and
26857 services outputs all timestamps in their local time?
26860 | By us44ever . <us44ever@hotmail.com>
26861 | [ 2003-08-28 18:45 +0200 ]
26864 > it would be really great to add another new line to the "/nickserv info"
26865 > command, for example, when some one types: "/nickserv info nick", the
26866 > following will be shown:
26868 > ***************************
26870 > -NickServ- nick is hello world
26872 > -NickServ- Is online from: ~test@just.a.test.co.za
26874 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
26876 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
26878 > -NickServ- Last quit message: anythinggggg
26880 > -NickServ- Options: Kill protection, Security
26882 > ***************************
26884 > the new line I'm suggesting is something like:
26886 > ***************************
26887 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
26888 > ***************************
26890 > This will help our users to compare the time that user was last seen and
26891 > the time right now *it's very important, many many of our users asked us
26892 > for this option*, also it would even be more great to show how long last
26893 > time the user was seen (some thing like: Last seen time: Aug 28 15:51:14
26894 > 2003 GMT (last seen time was before: 10 days, 3hours and 24 sec ago).
26896 > Note that I saw both of these features, in other services I don't remember
26897 > there names (but they aren't as stable as ircservices5) (it was something
26898 > like ptlink services, and magik II)
26900 > That's all, I would really like to see it on the next version (or if you
26901 > can show me how to do it, as I'm not a programmer)
26903 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
26908 > _________________________________________________________________
26909 > Get MSN 8 and enjoy automatic e-mail virus protection.
26910 > http://join.msn.com/?page=features/virus
26912 > ------------------------------------------------------------------
26913 > To unsubscribe or change your subscription options, visit:
26914 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
26916 From saturn at jetirc.net Thu Aug 28 11:39:41 2003
26917 From: saturn at jetirc.net (Saturn)
26918 Date: Sat Oct 23 23:10:00 2004
26919 Subject: [IRCServices Coding] Yet, another great suggestion
26920 References: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
26921 <20030828183615.GB32204@phat.za.net>
26922 Message-ID: <003201c36d93$abf77fd0$6401a8c0@turby>
26924 Oooo now I like that option... have it default to a default timezone, set in
26925 the conf file, and give them the option of SETting a different UTC code
26926 (have it as GMT + or - x wheer x is the offset from UTC)... It may not
26927 sound liek much, but I bet people will use it, and what's more, it IS useful
26928 information, especially on international servers like mine.. we have people
26929 from all over the place, and we keep services set on Pacific time... but for
26930 those in, say, Belgium... that's not very helpful
26932 ----- Original Message -----
26933 From: "Aragon Gouveia" <aragon@phat.za.net>
26934 To: <ircservices-coding@ircservices.za.net>
26935 Sent: Thursday, August 28, 2003 11:36 AM
26936 Subject: Re: [IRCServices Coding] Yet, another great suggestion
26939 Or how about rather letting users decide what timezone they're in and
26940 services outputs all timestamps in their local time?
26943 | By us44ever . <us44ever@hotmail.com>
26944 | [ 2003-08-28 18:45 +0200 ]
26947 > it would be really great to add another new line to the "/nickserv info"
26948 > command, for example, when some one types: "/nickserv info nick", the
26949 > following will be shown:
26951 > ***************************
26953 > -NickServ- nick is hello world
26955 > -NickServ- Is online from: ~test@just.a.test.co.za
26957 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
26959 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
26961 > -NickServ- Last quit message: anythinggggg
26963 > -NickServ- Options: Kill protection, Security
26965 > ***************************
26967 > the new line I'm suggesting is something like:
26969 > ***************************
26970 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
26971 > ***************************
26973 > This will help our users to compare the time that user was last seen and
26974 > the time right now *it's very important, many many of our users asked us
26975 > for this option*, also it would even be more great to show how long last
26976 > time the user was seen (some thing like: Last seen time: Aug 28 15:51:14
26977 > 2003 GMT (last seen time was before: 10 days, 3hours and 24 sec ago).
26979 > Note that I saw both of these features, in other services I don't remember
26980 > there names (but they aren't as stable as ircservices5) (it was something
26981 > like ptlink services, and magik II)
26983 > That's all, I would really like to see it on the next version (or if you
26984 > can show me how to do it, as I'm not a programmer)
26986 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
26991 > _________________________________________________________________
26992 > Get MSN 8 and enjoy automatic e-mail virus protection.
26993 > http://join.msn.com/?page=features/virus
26995 > ------------------------------------------------------------------
26996 > To unsubscribe or change your subscription options, visit:
26997 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
26998 ------------------------------------------------------------------
26999 To unsubscribe or change your subscription options, visit:
27000 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
27004 From Craig at chatspike.net Thu Aug 28 14:29:54 2003
27005 From: Craig at chatspike.net (Craig McLure)
27006 Date: Sat Oct 23 23:10:00 2004
27007 Subject: [IRCServices Coding] Yet, another great suggestion
27008 Message-ID: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
27010 Please dont post to both the services main list, and the services coding list. Choose one, or the other, especially concidering i dont think this is a great suggestion either..
27012 /time services.chatspike.net
27013 [22:28]
\95\95\95 Date / time at services.chatspike.net- Thu Aug 28 17:28:57 2003 EDT
27017 /****************************************
27018 * Craig "FrostyCoolSlug" McLure
27019 ************* - SpamBox - **************
27020 * InspIRCd - http://www.inspircd.org
27021 * ChatSpike - http://www.chatspike.net
27022 * WinBot - http://www.winbot.co.uk
27023 ****************************************/
27025 /****************************************
27026 * From - us44ever . <us44ever@hotmail.com>
27027 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
27028 * Sent - 2003-08-28 @ 16:45:00
27029 * Subject - [IRCServices Coding] Yet, another great suggestion
27030 ****************************************/
27032 /****** - Begin Original Message - ******/
27036 >it would be really great to add another new line to the "/nickserv info"
27037 >command, for example, when some one types: "/nickserv info nick", the
27038 >following will be shown:
27040 >***************************
27042 >-NickServ- nick is hello world
27044 >-NickServ- Is online from: ~test@just.a.test.co.za
27046 >-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
27048 >-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
27050 >-NickServ- Last quit message: anythinggggg
27052 >-NickServ- Options: Kill protection, Security
27054 >***************************
27056 >the new line I'm suggesting is something like:
27058 >***************************
27059 >-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
27060 >***************************
27062 >This will help our users to compare the time that user was last seen and the
27063 >time right now *it's very important, many many of our users asked us for
27064 >this option*, also it would even be more great to show how long last time
27065 >the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003 GMT
27066 >(last seen time was before: 10 days, 3hours and 24 sec ago).
27068 >Note that I saw both of these features, in other services I don't remember
27069 >there names (but they aren't as stable as ircservices5) (it was something
27070 >like ptlink services, and magik II)
27072 >That's all, I would really like to see it on the next version (or if you can
27073 >show me how to do it, as I'm not a programmer)
27075 >Many thanks to all of who developed IRCservices ...etc ...etc ...etc
27080 >_________________________________________________________________
27081 >Get MSN 8 and enjoy automatic e-mail virus protection.
27082 >http://join.msn.com/?page=features/virus
27084 >------------------------------------------------------------------
27085 >To unsubscribe or change your subscription options, visit:
27086 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
27088 /******* - End Original Message - *******/
27093 From nothing at psychopat.org Thu Aug 28 14:57:31 2003
27094 From: nothing at psychopat.org (Marc-Andre A. Fuentes)
27095 Date: Sat Oct 23 23:10:00 2004
27096 Subject: [IRCServices Coding] BUG Report
27097 Message-ID: <001501c36daf$c8cba700$0101a8c0@house>
27099 We're having a small problem with suspended channel.
27101 we suspended channel #kavala, and someone has identified itself has the founder and apply a DROP to the channel.
27102 then we got a panic from the services and... crash.
27104 Also with suspended nick , when the suspencion expire, the services crash
27107 ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
27112 -------------- next part --------------
27113 An HTML attachment was scrubbed...
27114 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030828/1f31ccf5/attachment-0001.htm
27115 From Craig at chatspike.net Thu Aug 28 15:24:36 2003
27116 From: Craig at chatspike.net (Craig McLure)
27117 Date: Sat Oct 23 23:10:00 2004
27118 Subject: [IRCServices Coding] BUG Report
27119 Message-ID: <20030828222401.JVQE12036.mta4-svc.business.ntl.com@i-br0ked-it>
27121 hmm.. what OS, compiler version etc are you using?
27123 after a test, i got the following:
27125 /cs id #abc 00376370
27126 -ChanServ- Channel #abc is suspended and may not be used or identified for.
27129 [23:20] -ChanServ- Channel is suspended and may not be used or identified for.
27131 only prob i got was it missed the channel name in the second message :)
27134 /****************************************
27135 * Craig "FrostyCoolSlug" McLure
27136 ************* - SpamBox - **************
27137 * InspIRCd - http://www.inspircd.org
27138 * ChatSpike - http://www.chatspike.net
27139 * WinBot - http://www.winbot.co.uk
27140 ****************************************/
27142 /****************************************
27143 * From - Marc-Andre A. Fuentes <nothing@psychopat.org>
27144 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
27145 * Sent - 2003-08-28 @ 18:00:00
27146 * Subject - [IRCServices Coding] BUG Report
27147 ****************************************/
27149 /****** - Begin Original Message - ******/
27151 >We're having a small problem with suspended channel.
27153 >we suspended channel #kavala, and someone has identified itself has the founder and apply a DROP to the channel.
27154 >then we got a panic from the services and... crash.
27156 >Also with suspended nick , when the suspencion expire, the services crash
27159 >ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
27164 >------------------------------------------------------------------
27165 >To unsubscribe or change your subscription options, visit:
27166 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
27168 /******* - End Original Message - *******/
27173 From saturn at jetirc.net Thu Aug 28 17:13:48 2003
27174 From: saturn at jetirc.net (Saturn)
27175 Date: Sat Oct 23 23:10:00 2004
27176 Subject: [IRCServices Coding] AKill suggestion
27177 References: <2C31F186-CDEE-11D7-979C-0003938D6866@mac.com>
27178 Message-ID: <009001c36dc2$64b56b80$6401a8c0@turby>
27180 Would it be possible to have it announce to the user when they are akilled,
27181 either the expiry date and time, or "Expires in 3days, 4hours, 6minutes" or
27182 something similar. I find that usually we just have to do 24hour bans, but
27183 the user has no way to know when the ban was set, and when it expires...
27185 Just an idea... I now await the half dozen people who will proceed to tell
27186 me how stupid my idea is....
27193 From playa at dreamchat.org Thu Aug 28 20:46:19 2003
27194 From: playa at dreamchat.org (playa)
27195 Date: Sat Oct 23 23:10:00 2004
27196 Subject: [IRCServices Coding] Yet, another great suggestion
27197 In-Reply-To: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
27198 References: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
27199 Message-ID: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
27201 Is this /time command only supposed to work via RAW? Cause when i type
27202 /time services.dreamchat.org i get No Such User, but if i do /raw time
27203 services.dreamchat.org, it works. Just wondering if its just me, or if
27204 its supposed to be that way.
27206 > Please dont post to both the services main list, and the services coding
27207 > list. Choose one, or the other, especially concidering i dont think this
27208 > is a great suggestion either..
27210 > /time services.chatspike.net
27211 > [22:28] ??? Date / time at services.chatspike.net- Thu Aug 28 17:28:57
27216 > /****************************************
27217 > * Craig "FrostyCoolSlug" McLure
27218 > ************* - SpamBox - **************
27219 > * InspIRCd - http://www.inspircd.org
27220 > * ChatSpike - http://www.chatspike.net
27221 > * WinBot - http://www.winbot.co.uk
27222 > ****************************************/
27224 > /****************************************
27225 > * From - us44ever . <us44ever@hotmail.com>
27226 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
27227 > * Sent - 2003-08-28 @ 16:45:00
27228 > * Subject - [IRCServices Coding] Yet, another great suggestion
27229 > ****************************************/
27231 > /****** - Begin Original Message - ******/
27235 >>it would be really great to add another new line to the "/nickserv info"
27236 >>command, for example, when some one types: "/nickserv info nick", the
27237 >>following will be shown:
27239 >>***************************
27241 >>-NickServ- nick is hello world
27243 >>-NickServ- Is online from: ~test@just.a.test.co.za
27245 >>-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
27247 >>-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
27249 >>-NickServ- Last quit message: anythinggggg
27251 >>-NickServ- Options: Kill protection, Security
27253 >>***************************
27255 >>the new line I'm suggesting is something like:
27257 >>***************************
27258 >>-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
27259 >>***************************
27261 >>This will help our users to compare the time that user was last seen and
27263 >>time right now *it's very important, many many of our users asked us for
27264 >>this option*, also it would even be more great to show how long last time
27265 >>the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003
27267 >>(last seen time was before: 10 days, 3hours and 24 sec ago).
27269 >>Note that I saw both of these features, in other services I don't
27271 >>there names (but they aren't as stable as ircservices5) (it was something
27272 >>like ptlink services, and magik II)
27274 >>That's all, I would really like to see it on the next version (or if you
27276 >>show me how to do it, as I'm not a programmer)
27278 >>Many thanks to all of who developed IRCservices ...etc ...etc ...etc
27283 >>_________________________________________________________________
27284 >>Get MSN 8 and enjoy automatic e-mail virus protection.
27285 >>http://join.msn.com/?page=features/virus
27287 >>------------------------------------------------------------------
27288 >>To unsubscribe or change your subscription options, visit:
27289 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
27291 > /******* - End Original Message - *******/
27295 > ------------------------------------------------------------------
27296 > To unsubscribe or change your subscription options, visit:
27297 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
27304 Network Founder/CEO
27305 DreamChat IRC Network - irc.dreamchat.org
27306 http://www.dreamchat.org
27309 From quension at mac.com Thu Aug 28 21:13:48 2003
27310 From: quension at mac.com (Trevor Talbot)
27311 Date: Sat Oct 23 23:10:00 2004
27312 Subject: [IRCServices Coding] Yet, another great suggestion
27313 In-Reply-To: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
27314 Message-ID: <0F823090-D9D7-11D7-8513-0003938D6866@mac.com>
27316 On Thursday, Aug 28, 2003, at 20:46 US/Pacific, playa wrote:
27318 > Is this /time command only supposed to work via RAW? Cause when i
27319 > type /time services.dreamchat.org i get No Such User, but if i do /raw
27320 > time services.dreamchat.org, it works. Just wondering if its just me,
27321 > or if its supposed to be that way.
27323 That's a client thing. Some clients might alias /time as a CTCP TIME
27324 for a specific user, or similar.
27329 From r-krisztian at softhome.net Thu Aug 28 22:12:51 2003
27330 From: r-krisztian at softhome.net (Krisztian Romek)
27331 Date: Sat Oct 23 23:10:00 2004
27332 Subject: [IRCServices Coding] Yet, another great suggestion
27333 In-Reply-To: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
27334 References: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
27335 <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
27336 Message-ID: <200308290713.29423.r-krisztian@softhome.net>
27338 > Is this /time command only supposed to work via RAW? Cause when i type
27339 > /time services.dreamchat.org i get No Such User, but if i do /raw time
27340 > services.dreamchat.org, it works. Just wondering if its just me, or if
27341 > its supposed to be that way.
27343 Some clients use stupid aliases for CTCP commands, for example:
27345 /version <nick> = /CTCP <nick> VERSION,
27346 /time <nick> = /CTCP <nick> TIME,
27347 /finger <nick> = /CTCP <nick> TIME
27349 This is why nothing works the way you expected.
27353 r-krisztian@softhome.net
27356 From us44ever at hotmail.com Fri Aug 29 13:02:19 2003
27357 From: us44ever at hotmail.com (us44ever .)
27358 Date: Sat Oct 23 23:10:00 2004
27359 Subject: [IRCServices Coding] AKill suggestion
27360 Message-ID: <Sea1-F108cM3oryKFRJ0000eb75@hotmail.com>
27362 Pretty good idea, specially is it would be implemented as an option (because
27363 some admins might won't like the idea of displaying the time of when the
27364 akill will expire to the user who has been akilled).
27366 _________________________________________________________________
27367 Help protect your PC: Get a free online virus scan at McAfee.com.
27368 http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
27371 From us44ever at hotmail.com Fri Aug 29 13:09:51 2003
27372 From: us44ever at hotmail.com (us44ever .)
27373 Date: Sat Oct 23 23:10:00 2004
27374 Subject: [IRCServices Coding] Yet, another great suggestion
27375 Message-ID: <Sea1-F127z33hqSnMGE000094b3@hotmail.com>
27378 Since most people want to see this feature(s) in the next version, it would
27379 be great to implement it as an optional feature , where it can be disabled
27380 from the .conf file(s) or enable it easily. I don't think that there is
27381 anything that the authors will lose if this feature can be added, in fact,
27382 it will add another nice feature to the features list of IRCservices5.
27384 _________________________________________________________________
27385 Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
27386 using MSN Messenger http://entertainment.msn.com/imastar
27389 From Craig at chatspike.net Fri Aug 29 13:41:59 2003
27390 From: Craig at chatspike.net (Craig McLure)
27391 Date: Sat Oct 23 23:10:00 2004
27392 Subject: [IRCServices Coding] Yet, another great suggestion
27393 Message-ID: <20030829204143.NNNT26404.mta1-svc.business.ntl.com@i-br0ked-it>
27395 I'll ask again.. can you please stop posting to both the IRCServices mailing list, and the IRCd coding mailing list, getting your mail 2ce is beginning to annoy me.
27397 And i'll Quote Elijah:
27399 "Except it's already been said in the FAQ that it's not going to happen, and
27400 if that made it into the FAQ it would seem the answer is frequently going to
27404 /****************************************
27405 * Craig "FrostyCoolSlug" McLure
27406 ************* - SpamBox - **************
27407 * InspIRCd - http://www.inspircd.org
27408 * ChatSpike - http://www.chatspike.net
27409 * WinBot - http://www.winbot.co.uk
27410 ****************************************/
27412 /****************************************
27413 * From - us44ever . <us44ever@hotmail.com>
27414 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
27415 * Sent - 2003-08-29 @ 20:09:00
27416 * Subject - Re: [IRCServices Coding] Yet, another great suggestion
27417 ****************************************/
27419 /****** - Begin Original Message - ******/
27421 >Since most people want to see this feature(s) in the next version, it would
27422 >be great to implement it as an optional feature , where it can be disabled
27423 >from the .conf file(s) or enable it easily. I don't think that there is
27424 >anything that the authors will lose if this feature can be added, in fact,
27425 >it will add another nice feature to the features list of IRCservices5.
27427 >_________________________________________________________________
27428 >Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
27429 >using MSN Messenger http://entertainment.msn.com/imastar
27431 >------------------------------------------------------------------
27432 >To unsubscribe or change your subscription options, visit:
27433 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
27436 /******* - End Original Message - *******/
27441 From Craig at chatspike.net Fri Aug 29 13:43:24 2003
27442 From: Craig at chatspike.net (Craig McLure)
27443 Date: Sat Oct 23 23:10:00 2004
27444 Subject: [IRCServices Coding] AKill suggestion
27445 Message-ID: <20030829204311.GHCL29825.mta5-svc.business.ntl.com@i-br0ked-it>
27447 its a stupid idea!!! :p
27449 j/k.. I think its a great idea.. i'd rather have services telling users when their akills expire, than them spamming my mailbox with 'when does my akill expire?' every 20mins :p
27451 /****************************************
27452 * Craig "FrostyCoolSlug" McLure
27453 ************* - SpamBox - **************
27454 * InspIRCd - http://www.inspircd.org
27455 * ChatSpike - http://www.chatspike.net
27456 * WinBot - http://www.winbot.co.uk
27457 ****************************************/
27459 /****************************************
27460 * From - Saturn <saturn@jetirc.net>
27461 * To - IRC Services Coding Mailing List <ircservices-coding@ircservices.za.net>
27462 * Sent - 2003-08-28 @ 17:13:00
27463 * Subject - [IRCServices Coding] AKill suggestion
27464 ****************************************/
27466 /****** - Begin Original Message - ******/
27468 >Would it be possible to have it announce to the user when they are akilled,
27469 >either the expiry date and time, or "Expires in 3days, 4hours, 6minutes" or
27470 >something similar. I find that usually we just have to do 24hour bans, but
27471 >the user has no way to know when the ban was set, and when it expires...
27473 >Just an idea... I now await the half dozen people who will proceed to tell
27474 >me how stupid my idea is....
27480 >------------------------------------------------------------------
27481 >To unsubscribe or change your subscription options, visit:
27482 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
27484 /******* - End Original Message - *******/
27489 From Craig at chatspike.net Sat Aug 30 17:07:32 2003
27490 From: Craig at chatspike.net (Craig McLure)
27491 Date: Sat Oct 23 23:10:00 2004
27492 Subject: [IRCServices Coding] OP/Voice upon identify
27493 Message-ID: <20030831000719.ELIJ19019.mta3-svc.business.ntl.com@i-br0ked-it>
27495 it would thou.. they would have to be able to switch off auto-op for a single channel..
27496 you could always use /cs levels to change the 'auto op' level up.. so that no one is auto-opped..
27498 or /cs levels #channels DISABLE autoop
27500 /****************************************
27501 * Craig "FrostyCoolSlug" McLure
27502 ************* - SpamBox - **************
27503 * InspIRCd - http://www.inspircd.org
27504 * ChatSpike - http://www.chatspike.net
27505 * WinBot - http://www.winbot.co.uk
27506 ****************************************/
27508 /****************************************
27509 * From - Shaun Guth <l8nite@l8nite.net>
27510 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
27511 * Sent - 2003-08-30 @ 16:58:00
27512 * Subject - RE: [IRCServices Coding] OP/Voice upon identify
27513 ****************************************/
27515 /****** - Begin Original Message - ******/
27517 >On Sun, 2003-08-31 at 01:16, Andrew Church wrote:
27518 >> Needless complexity. If you don't want yourself autoopped, then don't
27519 >> be an auto-op. It's that simple.
27521 >I disagree. In my case, I wanted to create a channel where there were
27522 >no ops so users don't have to endure lame op-wars, etc. However, I did
27523 >need to maintain a level of control over the channel to protect from
27524 >extremely obnoxious behavior or lame bots, etc. By registering as
27525 >founder of the channel I induced the unwanted 'auto-op' behavior. My
27526 >only solution was to register another fake user to become channel
27527 >founder and set their nick to noexpire. That to me seems like needless
27528 >complexity. A simple check to see if the user wishes to be opped or not
27533 >------------------------------------------------------------------
27534 >To unsubscribe or change your subscription options, visit:
27535 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
27538 /******* - End Original Message - *******/
27543 From l8nite at l8nite.net Sat Aug 30 17:14:44 2003
27544 From: l8nite at l8nite.net (Shaun Guth)
27545 Date: Sat Oct 23 23:10:00 2004
27546 Subject: [IRCServices Coding] OP/Voice upon identify
27547 In-Reply-To: <20030831000719.ELIJ19019.mta3-svc.business.ntl.com@i-br0ked-it>
27548 References: <20030831000719.ELIJ19019.mta3-svc.business.ntl.com@i-br0ked-it>
27549 Message-ID: <1062288881.21924.17.camel@localhost>
27551 On Sat, 2003-08-30 at 18:06, Craig McLure wrote:
27552 > it would thou.. they would have to be able to switch off auto-op for a single channel..
27554 For each channel we already store an access list, one extra bit to
27555 indicate auto-anything status or not is not really asking too much.
27557 > you could always use /cs levels to change the 'auto op' level up.. so that no one is auto-opped..
27558 > or /cs levels #channels DISABLE autoop
27560 -ChanServ- Channel #foobar registered under your nickname: l8
27561 -ChanServ- AUTOOP disabled on channel #foobar.
27562 --- You have left channel #foobar
27563 --> You are now talking on #foobar
27564 --- services.topgamers.net removes channel operator status from l8
27565 --- services.topgamers.net gives channel operator status to l8
27567 Same with ENFORCE set to off as well.
27569 > [snipped obnoxiously long sig]
27574 From achurch at achurch.org Sun Aug 31 02:58:23 2003
27575 From: achurch at achurch.org (Andrew Church)
27576 Date: Sat Oct 23 23:10:01 2004
27577 Subject: [IRCServices Coding] OP/Voice upon identify
27578 In-Reply-To: <1062288881.21924.17.camel@localhost>
27579 Message-ID: <3f51c6b5.07402@achurch.org>
27581 >> you could always use /cs levels to change the 'auto op' level up.. so that no one is auto-opped..
27582 >> or /cs levels #channels DISABLE autoop
27584 >-ChanServ- Channel #foobar registered under your nickname: l8
27585 >-ChanServ- AUTOOP disabled on channel #foobar.
27586 >--- You have left channel #foobar
27587 >--> You are now talking on #foobar
27588 >--- services.topgamers.net removes channel operator status from l8
27589 >--- services.topgamers.net gives channel operator status to l8
27591 This is definitely confusing behavior. Fixed for 5.0.22, thanks for
27592 the report. Note that you will also want to disable the other AUTOxxx
27593 levels as well if you don't want any automatic modes.
27596 achurch@achurch.org
27597 http://achurch.org/
27599 From achurch at achurch.org Sun Aug 31 07:28:11 2003
27600 From: achurch at achurch.org (Andrew Church)
27601 Date: Sat Oct 23 23:10:01 2004
27602 Subject: [IRCServices Coding] Mass memos
27603 In-Reply-To: <001601c361d8$a5312f00$6401a8c0@turby>
27604 Message-ID: <3f5205f0.15057@achurch.org>
27606 >Can we reconsider adding a Mass memo function for the next release?
27608 No, for all the reasons others have mentioned. I'll also draw an
27609 example from my experience with cellphone mail in Japan, which is
27610 remarkably similar to Services memos: Automated messages are annoying,
27611 period. The primary use for cellphone mail is to communicate with friends;
27612 having automatic messages interfere with that is annoying in the extreme.
27613 Yes, 10% or 20% of your users might be willing to accept mass memos, but
27614 the remaining 80% or 90% will get quite upset with you.
27616 I might also point out that people who care about what happens on the
27617 network will actively check that information, whether you make it available
27618 through logon news, through a website, or whatever; and people who don't
27619 care will ignore anything you send them. The method you use to inform them
27620 won't really make a difference.
27622 >If not, or even if so... one thing puzzles me: In the /ns list * command,
27623 >the listings have occasional punctuation... a ! or ? in front of the nick.
27624 >There is nothing in the docs anywhere that seems to address this, and I'm
27625 >curious as to what those mean.... an explanation would be helpful there too.
27627 This should be available through /ns help list, but there appears to
27628 be a bug there. I'll fix it for the next version.
27630 >on that note, a possible suggestion for Logonnews... How about something I
27631 >saw on Dalnet once: When new news is added, you get a notice. Until you
27632 >read the news, it keeps bugging you when you log on. After you read it, it
27633 >stops. Some sort of flag so users know when there IS new news would be
27634 >useful... the main reason nobody read the logonnews is that 90% of the time
27635 >for them, it is unchanged........
27637 This is an interesting thought; I'll think about it for a future
27641 achurch@achurch.org
27642 http://achurch.org/
27644 From achurch at achurch.org Sun Aug 31 07:42:30 2003
27645 From: achurch at achurch.org (Andrew Church)
27646 Date: Sat Oct 23 23:10:01 2004
27647 Subject: [IRCServices Coding] Language
27648 In-Reply-To: <MKEGJINFADFODDNOKEJCKEEDDPAA.rg@tcslon.com>
27649 Message-ID: <3f52094e.17046@achurch.org>
27651 [/msg nickserv vs. /nickserv]
27652 >I wonder if it would be worth integrating such a thing into services as an
27653 >option (compile-time maybe?). I think it would be good for the irc community
27654 >as a whole to get away from the habit of msging services directly if at all
27655 >possible. Opinions?
27657 /msg NickServ is the one format that's guaranteed to work on every
27658 ircd (except for administrative decisions a la DALnet). Get an RFC
27659 published--and implemented; 2811-3 were remarkable failures in that area--
27660 and I'll consider changing it.
27663 achurch@achurch.org
27664 http://achurch.org/
27666 From achurch at achurch.org Sun Aug 31 07:45:49 2003
27667 From: achurch at achurch.org (Andrew Church)
27668 Date: Sat Oct 23 23:10:01 2004
27669 Subject: [IRCServices Coding] Language
27670 In-Reply-To: <Pine.GSO.4.31.0308172127300.9882-100000@nikson.dataphone.se>
27671 Message-ID: <3f520a18.17063@achurch.org>
27673 >Is there any tool (silly question) or something or guid to make a language
27676 >I have decided to make a Persian (Farsi) language file.
27678 Language files are just plain text files; as another reply said, read
27679 the comments at the top of lang/en_us.l, and work from there. Be warned
27680 that the amount of text is huge; expect to spend at least two to three
27681 months on the initial translation.
27683 Also, if you'd be willing to continue maintaining the language file as
27684 it is updated in future versions, please let me know privately.
27687 achurch@achurch.org
27688 http://achurch.org/
27690 From achurch at achurch.org Sun Aug 31 07:53:21 2003
27691 From: achurch at achurch.org (Andrew Church)
27692 Date: Sat Oct 23 23:10:01 2004
27693 Subject: [IRCServices Coding] segfault on expiring ?
27694 In-Reply-To: <001201c36793$d26e4000$0101a8c0@nothing>
27695 Message-ID: <3f520bd8.17715@achurch.org>
27697 >[Aug 20 20:49:05 2003] nickserv/main: Expiring suspension for SeBa_KoBe (nick group 17805)
27698 >[Aug 20 20:49:05 2003] nickserv/main: Expiring nickname SeBa_KoBe
27699 >[Aug 20 20:49:05 2003] nickserv/main: [Aug 20 20:49:05 2003] Services terminating: Segmentation Faul
27701 I can't reproduce this problem. If this is still occurring, can you
27702 send me your databases privately so that I can investigate it?
27705 achurch@achurch.org
27706 http://achurch.org/
27708 From achurch at achurch.org Sun Aug 31 07:55:10 2003
27709 From: achurch at achurch.org (Andrew Church)
27710 Date: Sat Oct 23 23:10:01 2004
27711 Subject: [IRCServices Coding] BUG Report
27712 In-Reply-To: <001501c36daf$c8cba700$0101a8c0@house>
27713 Message-ID: <3f520c48.17731@achurch.org>
27715 >we suspended channel #kavala, and someone has identified itself has the =
27716 >founder and apply a DROP to the channel.
27717 >then we got a panic from the services and... crash.
27719 This is a bug in the DROP function, and has been fixed; thanks for the
27723 achurch@achurch.org
27724 http://achurch.org/
27726 From achurch at achurch.org Sun Aug 31 08:07:44 2003
27727 From: achurch at achurch.org (Andrew Church)
27728 Date: Sat Oct 23 23:10:01 2004
27729 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
27730 In-Reply-To: <Pine.GSO.4.31.0308301716410.15629-100000@nikson.dataphone.se>
27731 Message-ID: <3f520f38.21076@achurch.org>
27733 >[Aug 30 10:56:18 2003] mail/sendmail:
27734 > /usr/sbin/sendmail exited with code 25600
27736 Use the SMTP module instead (mail/smtp).
27738 >[Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
27739 >registration (Simorgh)
27741 >and how can I do so that nickserv dont show the realhost of a user in
27742 >'ns info nick all'
27744 It doesn't. However:
27746 >[Aug 30 10:51:19 2003] unknown message from server
27747 >(:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
27749 You're using the wrong protocol, since it doesn't recognize the
27750 SETHOST command and therefore has no idea about fake hosts. I might
27751 remind you that Ultimate 3.x is not supported.
27754 achurch@achurch.org
27755 http://achurch.org/
27757 From achurch at achurch.org Sun Aug 31 08:11:22 2003
27758 From: achurch at achurch.org (Andrew Church)
27759 Date: Sat Oct 23 23:10:01 2004
27760 Subject: [IRCServices Coding] Yet, another great suggestion
27761 In-Reply-To: <20030828183615.GB32204@phat.za.net>
27762 Message-ID: <3f52100e.21116@achurch.org>
27764 >Or how about rather letting users decide what timezone they're in and
27765 >services outputs all timestamps in their local time?
27767 /ns help set timezone (since 5.0 alpha)
27770 achurch@achurch.org
27771 http://achurch.org/
27773 From saturn at jetirc.net Sun Aug 31 12:28:59 2003
27774 From: saturn at jetirc.net (Saturn)
27775 Date: Sat Oct 23 23:10:01 2004
27776 Subject: [IRCServices Coding]
27777 Re: [IRCServices] Yet, another great suggestion
27778 References: <3f5202a3.15001@achurch.org>
27779 Message-ID: <003201c36ff6$25ae6550$6401a8c0@turby>
27781 I think it is... consider an international Network like mine: every server
27782 is in a different time zone -- How are users supposed to know what time zone
27783 the Services (pickign on Services' clock because Services are whats giving
27784 these notices!) is in?? Sure, they can do the /time command, if they even
27785 know abotu it. But the vast majority of IRC users are ignorant of those
27786 sorts of commands, or even if they know about /time, they most likely have
27787 no idea they can specify a server with the command.
27789 I realize that programmers for IRC-related software seem always to be of the
27790 universal opinion that ALL irc users should take the time to become elite
27791 experts abotu everything PC, however that is simply NOT reality. Services
27792 is specificly there to SERVE the users and the ircops. Its sole function is
27793 to police access and provide information to the users -- what use is it to
27794 say that a certain piece of information is "not useful" or "not needed" when
27795 you can plainly see that it is in this case, given the argument above?
27797 Obviously, it is your project, not mine, and I certainly cannot force you to
27798 do anythign you don't want to do, but I and my staff and users all agree it
27799 would be extremely useful... "Handy" was the word most used. I've had quite
27800 a few queries about it, and so I'm asking for it. If you don't feel that
27801 non-techie users deserve any consideration, then ignore the request. It's
27802 really up to you anyhow....
27807 ----- Original Message -----
27808 From: "Andrew Church" <achurch@achurch.org>
27809 To: <saturn@jetirc.net>
27810 Sent: Sunday, August 31, 2003 7:13 AM
27811 Subject: Re: [IRCServices] Yet, another great suggestion
27814 >So how do you get the current time from Services then? The actual time that
27815 >SERVICES thinks it is, not the server, and not my local clock...
27817 If there's any significant difference between your local clock, your
27818 IRC server's clock, and Services' clock, then at least one of them needs to
27819 be fixed. That's not Services' problem.
27822 achurch@achurch.org
27823 http://achurch.org/
27827 From aragon at phat.za.net Sun Aug 31 13:23:29 2003
27828 From: aragon at phat.za.net (Aragon Gouveia)
27829 Date: Sat Oct 23 23:10:01 2004
27830 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
27831 another great suggestion
27832 In-Reply-To: <003201c36ff6$25ae6550$6401a8c0@turby>
27833 References: <3f5202a3.15001@achurch.org> <003201c36ff6$25ae6550$6401a8c0@turby>
27834 Message-ID: <20030831202324.GB8731@phat.za.net>
27836 | By Saturn <saturn@jetirc.net>
27837 | [ 2003-08-31 21:29 +0200 ]
27838 > I think it is... consider an international Network like mine: every server
27839 > is in a different time zone -- How are users supposed to know what time zone
27840 > the Services (pickign on Services' clock because Services are whats giving
27841 > these notices!) is in?? Sure, they can do the /time command, if they even
27842 > know abotu it. But the vast majority of IRC users are ignorant of those
27843 > sorts of commands, or even if they know about /time, they most likely have
27844 > no idea they can specify a server with the command.
27846 Erm, what's the argument here? Services stipulates its timezone in its
27847 timestamps. As do all the other servers on the network.
27855 From saturn at jetirc.net Sun Aug 31 13:47:37 2003
27856 From: saturn at jetirc.net (Saturn)
27857 Date: Sat Oct 23 23:10:01 2004
27858 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
27859 another great suggestion
27860 References: <3f5202a3.15001@achurch.org> <003201c36ff6$25ae6550$6401a8c0@turby>
27861 <20030831202324.GB8731@phat.za.net>
27862 Message-ID: <000701c37001$10a62cf0$6401a8c0@turby>
27864 The argument is that the overwhelming majority of IRC users have no idea the
27865 /time command exists, and even fewer are aware that they can specify a
27866 server name after the /time command. How would these people find out the
27867 Services time zone? Why does it all have to be so complicated??
27869 ----- Original Message -----
27870 From: "Aragon Gouveia" <aragon@phat.za.net>
27871 To: <ircservices-coding@ircservices.za.net>
27872 Sent: Sunday, August 31, 2003 1:23 PM
27873 Subject: Re: [IRCServices Coding] Re: [IRCServices] Yet,another great
27877 | By Saturn <saturn@jetirc.net>
27878 | [ 2003-08-31 21:29 +0200 ]
27879 > I think it is... consider an international Network like mine: every
27881 > is in a different time zone -- How are users supposed to know what time
27883 > the Services (pickign on Services' clock because Services are whats giving
27884 > these notices!) is in?? Sure, they can do the /time command, if they even
27885 > know abotu it. But the vast majority of IRC users are ignorant of those
27886 > sorts of commands, or even if they know about /time, they most likely have
27887 > no idea they can specify a server with the command.
27889 Erm, what's the argument here? Services stipulates its timezone in its
27890 timestamps. As do all the other servers on the network.
27897 ------------------------------------------------------------------
27898 To unsubscribe or change your subscription options, visit:
27899 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
27903 From quension at mac.com Sun Aug 31 14:11:28 2003
27904 From: quension at mac.com (Trevor Talbot)
27905 Date: Sat Oct 23 23:10:01 2004
27906 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
27907 another great suggestion
27908 In-Reply-To: <000701c37001$10a62cf0$6401a8c0@turby>
27909 Message-ID: <962546B6-DBF7-11D7-8505-0003938D6866@mac.com>
27911 On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
27913 > The argument is that the overwhelming majority of IRC users have no
27914 > idea the /time command exists, and even fewer are aware that they can
27915 > specify a server name after the /time command. How would these people
27916 > find out the Services time zone?
27918 You missed the point. Services shows the time zone wherever it uses a
27919 readable time -- i.e. in the nickserv/chanserv info displays. Unless
27920 you've changed your language file, in which case you can simply change
27923 > Why does it all have to be so complicated??
27925 It isn't. Your users can even use the handy-dandy /nickserv set
27926 timezone command to make it even easier.
27928 > ----- Original Message -----
27929 > From: "Aragon Gouveia" <aragon@phat.za.net>
27931 > | By Saturn <saturn@jetirc.net>
27932 > | [ 2003-08-31 21:29 +0200 ]
27933 >> I think it is... consider an international Network like mine: every
27934 >> server is in a different time zone -- How are users supposed to know
27935 >> what time zone the Services (pickign on Services' clock because
27936 >> Services are whats giving these notices!) is in?? Sure, they can do
27937 >> the /time command, if they even know abotu it. But the vast majority
27938 >> of IRC users are ignorant of those sorts of commands, or even if they
27939 >> know about /time, they most likely have no idea they can specify a
27940 >> server with the command.
27942 > Erm, what's the argument here? Services stipulates its timezone in
27943 > its timestamps. As do all the other servers on the network.
27948 From us44ever at hotmail.com Sun Aug 31 14:40:48 2003
27949 From: us44ever at hotmail.com (us44ever .)
27950 Date: Sat Oct 23 23:10:01 2004
27951 Subject: [IRCServices Coding]
27952 Re: [IRCServices] Yet, another great suggestion
27953 Message-ID: <Sea1-F8siZAPG4vEjaG0000fb20@hotmail.com>
27956 or even the idea of adding an additional info (exact info) something like:
27957 Last seen time : Aug 22 14:20:16 2003 GMT (9 days, 51 minutes and 21
27959 Time registered : Jul 25 22:19:20 2003 GMT (** days, ** minutes and **
27961 wouldn't even a greater idea?
27963 _________________________________________________________________
27964 Get MSN 8 and enjoy automatic e-mail virus protection.
27965 http://join.msn.com/?page=features/virus
27968 From saturn at jetirc.net Sun Aug 31 16:49:07 2003
27969 From: saturn at jetirc.net (Saturn)
27970 Date: Sat Oct 23 23:10:01 2004
27971 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
27972 another great suggestion
27973 References: <962546B6-DBF7-11D7-8505-0003938D6866@mac.com>
27974 Message-ID: <000e01c3701a$48faea50$6401a8c0@turby>
27976 [16:41] -NickServ- Time registered: Jul 27 13:09:08 2002 PDT
27978 That's what I see when I use it. Yes, it does say "PDT" .. how many people
27979 in, say Belgium, are going to know exactly what PDT is? How about "PDT
27980 (GMT-8)" as the format....? Also, you'll note that it STILL gives no
27981 indication as to the CURRENT time ... this is why the proper UTC code or
27982 GMT+/-## is the best way to go IMHO. I do also like the idea suggested by
27983 us44ever ... the "(** days, ** minutes, and ** seconds ago)" idea... that
27984 would be handy in any event.... and would eliminate the need for the current
27985 time to be displayed....
27987 On another note, I had forgotten the set timezone option, which certainly
27988 would put more clarity on the output... however, I think my points above are
27991 Unless of course I've missed a config setting that will tell it to report
27992 the tiome zone as a function of GMT (plus or minus x hours, rather than zone
27995 ----- Original Message -----
27996 From: "Trevor Talbot" <quension@mac.com>
27997 To: "IRC Services Coding Mailing List"
27998 <ircservices-coding@ircservices.za.net>
27999 Sent: Sunday, August 31, 2003 2:10 PM
28000 Subject: Re: [IRCServices Coding] Re: [IRCServices] Yet,another great
28004 On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
28006 > The argument is that the overwhelming majority of IRC users have no
28007 > idea the /time command exists, and even fewer are aware that they can
28008 > specify a server name after the /time command. How would these people
28009 > find out the Services time zone?
28011 You missed the point. Services shows the time zone wherever it uses a
28012 readable time -- i.e. in the nickserv/chanserv info displays. Unless
28013 you've changed your language file, in which case you can simply change
28016 > Why does it all have to be so complicated??
28018 It isn't. Your users can even use the handy-dandy /nickserv set
28019 timezone command to make it even easier.
28021 > ----- Original Message -----
28022 > From: "Aragon Gouveia" <aragon@phat.za.net>
28024 > | By Saturn <saturn@jetirc.net>
28025 > | [ 2003-08-31 21:29 +0200 ]
28026 >> I think it is... consider an international Network like mine: every
28027 >> server is in a different time zone -- How are users supposed to know
28028 >> what time zone the Services (pickign on Services' clock because
28029 >> Services are whats giving these notices!) is in?? Sure, they can do
28030 >> the /time command, if they even know abotu it. But the vast majority
28031 >> of IRC users are ignorant of those sorts of commands, or even if they
28032 >> know about /time, they most likely have no idea they can specify a
28033 >> server with the command.
28035 > Erm, what's the argument here? Services stipulates its timezone in
28036 > its timestamps. As do all the other servers on the network.
28040 ------------------------------------------------------------------
28041 To unsubscribe or change your subscription options, visit:
28042 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
28046 From quension at mac.com Sun Aug 31 18:25:05 2003
28047 From: quension at mac.com (Trevor Talbot)
28048 Date: Sat Oct 23 23:10:01 2004
28049 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
28050 another great suggestion
28051 In-Reply-To: <000e01c3701a$48faea50$6401a8c0@turby>
28052 Message-ID: <14C7EDD0-DC1B-11D7-8505-0003938D6866@mac.com>
28054 On Sunday, Aug 31, 2003, at 16:47 US/Pacific, Saturn wrote:
28056 > Unless of course I've missed a config setting that will tell it to
28057 > report the tiome zone as a function of GMT (plus or minus x hours,
28058 > rather than zone codes like PDT)...
28060 You could modify the language file, using something like "(GMT%z)"
28061 instead of %Z in the STRFTIME_DATE_TIME_FORMAT string. "man 3
28062 strftime" for the available options.
28067 From achurch at achurch.org Sun Aug 31 19:00:00 2003
28068 From: achurch at achurch.org (Andrew Church)
28069 Date: Sat Oct 23 23:10:01 2004
28070 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
28071 another great suggestion
28072 In-Reply-To: <000e01c3701a$48faea50$6401a8c0@turby>
28073 Message-ID: <3f52a815.21363@achurch.org>
28075 "Use /ns set timezone" is the official answer on this. Please take
28076 all further discussion to the ircservices list.
28079 achurch@achurch.org
28080 http://achurch.org/
28082 >[16:41] -NickServ- Time registered: Jul 27 13:09:08 2002 PDT
28084 >That's what I see when I use it. Yes, it does say "PDT" .. how many people
28085 >in, say Belgium, are going to know exactly what PDT is? How about "PDT
28086 >(GMT-8)" as the format....? Also, you'll note that it STILL gives no
28087 >indication as to the CURRENT time ... this is why the proper UTC code or
28088 >GMT+/-## is the best way to go IMHO. I do also like the idea suggested by
28089 >us44ever ... the "(** days, ** minutes, and ** seconds ago)" idea... that
28090 >would be handy in any event.... and would eliminate the need for the current
28091 >time to be displayed....
28093 >On another note, I had forgotten the set timezone option, which certainly
28094 >would put more clarity on the output... however, I think my points above are
28097 >Unless of course I've missed a config setting that will tell it to report
28098 >the tiome zone as a function of GMT (plus or minus x hours, rather than zone
28099 >codes like PDT)...
28101 >----- Original Message -----
28102 >From: "Trevor Talbot" <quension@mac.com>
28103 >To: "IRC Services Coding Mailing List"
28104 ><ircservices-coding@ircservices.za.net>
28105 >Sent: Sunday, August 31, 2003 2:10 PM
28106 >Subject: Re: [IRCServices Coding] Re: [IRCServices] Yet,another great
28110 >On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
28112 >> The argument is that the overwhelming majority of IRC users have no
28113 >> idea the /time command exists, and even fewer are aware that they can
28114 >> specify a server name after the /time command. How would these people
28115 >> find out the Services time zone?
28117 >You missed the point. Services shows the time zone wherever it uses a
28118 >readable time -- i.e. in the nickserv/chanserv info displays. Unless
28119 >you've changed your language file, in which case you can simply change
28122 >> Why does it all have to be so complicated??
28124 >It isn't. Your users can even use the handy-dandy /nickserv set
28125 >timezone command to make it even easier.
28127 >> ----- Original Message -----
28128 >> From: "Aragon Gouveia" <aragon@phat.za.net>
28130 >> | By Saturn <saturn@jetirc.net>
28131 >> | [ 2003-08-31 21:29 +0200 ]
28132 >>> I think it is... consider an international Network like mine: every
28133 >>> server is in a different time zone -- How are users supposed to know
28134 >>> what time zone the Services (pickign on Services' clock because
28135 >>> Services are whats giving these notices!) is in?? Sure, they can do
28136 >>> the /time command, if they even know abotu it. But the vast majority
28137 >>> of IRC users are ignorant of those sorts of commands, or even if they
28138 >>> know about /time, they most likely have no idea they can specify a
28139 >>> server with the command.
28141 >> Erm, what's the argument here? Services stipulates its timezone in
28142 >> its timestamps. As do all the other servers on the network.
28146 >------------------------------------------------------------------
28147 >To unsubscribe or change your subscription options, visit:
28148 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
28151 >------------------------------------------------------------------
28152 >To unsubscribe or change your subscription options, visit:
28153 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
28155 From simorgh at dataphone.se Sun Aug 31 22:34:32 2003
28156 From: simorgh at dataphone.se (Ali Simorgh)
28157 Date: Sat Oct 23 23:10:01 2004
28158 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
28159 In-Reply-To: <3f520f38.21076@achurch.org>
28160 Message-ID: <Pine.GSO.4.31.0309010728040.7173-100000@nikson.dataphone.se>
28162 Thanks for your help.
28164 I thought if I set nickserv to not be an ircop, then it maybe dosent se
28165 the real host name, and maybe shows the crypted hostname to other users
28166 or should I change this line in language files:
28167 NICK_INFO_ADDRESS_ONLINE
28170 NICK_INFO_ADDRESS_ONLINE
28171 Is online from: N/A ?
28175 ______________________________________________________
28176 Many of life's failures are people who did not realize
28177 how close they were to success when they gave up.
28179 ______________________________________________________
28182 On Mon, 1 Sep 2003, Andrew Church wrote:
28184 > >[Aug 30 10:56:18 2003] mail/sendmail:
28185 > > /usr/sbin/sendmail exited with code 25600
28187 > Use the SMTP module instead (mail/smtp).
28189 > >[Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
28190 > >registration (Simorgh)
28192 > >and how can I do so that nickserv dont show the realhost of a user in
28193 > >'ns info nick all'
28195 > It doesn't. However:
28197 > >[Aug 30 10:51:19 2003] unknown message from server
28198 > >(:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
28200 > You're using the wrong protocol, since it doesn't recognize the
28201 > SETHOST command and therefore has no idea about fake hosts. I might
28202 > remind you that Ultimate 3.x is not supported.
28205 > achurch@achurch.org
28206 > http://achurch.org/
28207 > ------------------------------------------------------------------
28208 > To unsubscribe or change your subscription options, visit:
28209 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
28213 From achurch at achurch.org Sun Aug 31 23:24:09 2003
28214 From: achurch at achurch.org (Andrew Church)
28215 Date: Sat Oct 23 23:10:01 2004
28216 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
28217 In-Reply-To: <Pine.GSO.4.31.0309010728040.7173-100000@nikson.dataphone.se>
28218 Message-ID: <3f52e5fe.41203@achurch.org>
28220 >I thought if I set nickserv to not be an ircop, then it maybe dosent se
28221 >the real host name, and maybe shows the crypted hostname to other users
28223 It isn't a matter of NickServ having operator privileges or not;
28224 Services, as a server, always sees the real hostname. The problem is that
28225 Services and your IRC server aren't using the same protocol, so Services
28226 can't recognize the fake hosts. Try using a different IRC server.
28229 achurch@achurch.org
28230 http://achurch.org/
28232 From laser at musichat.net Wed Sep 3 06:49:40 2003
28233 From: laser at musichat.net (Alessandro Ciappei)
28234 Date: Sat Oct 23 23:10:01 2004
28235 Subject: [IRCServices Coding] New Features
28236 Message-ID: <001b01c37222$428f54d0$e2c0fea9@alexxa3il9cxpx>
28240 I have an idea for next release.
28241 A secure link between services and ircd.
28242 Now many ircd, like Unreal, tr-ircd, bahamut supports a ssl link.
28247 -------------- next part --------------
28248 An HTML attachment was scrubbed...
28249 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030903/a25ee68d/attachment-0001.html
28250 From r-krisztian at softhome.net Wed Sep 3 07:16:45 2003
28251 From: r-krisztian at softhome.net (Krisztian Romek)
28252 Date: Sat Oct 23 23:10:01 2004
28253 Subject: [IRCServices Coding] New Features
28254 In-Reply-To: <001b01c37222$428f54d0$e2c0fea9@alexxa3il9cxpx>
28255 References: <001b01c37222$428f54d0$e2c0fea9@alexxa3il9cxpx>
28256 Message-ID: <200309031617.38876.r-krisztian@softhome.net>
28261 > I have an idea for next release.
28262 > A secure link between services and ircd.
28263 > Now many ircd, like Unreal, tr-ircd, bahamut supports a ssl link.
28265 I think a ZIP link support (like in Unreal) should also be fine. :-) I don't
28266 know what you will reply for these feature requests, but I agree that they
28267 aren't so important, since in most cases ircd and services run on the same
28272 r-krisztian@softhome.net
28275 From Craig at chatspike.net Wed Sep 3 13:35:04 2003
28276 From: Craig at chatspike.net (Craig McLure)
28277 Date: Sat Oct 23 23:10:01 2004
28278 Subject: [IRCServices Coding] New Features
28279 Message-ID: <20030903203453.ITMO19019.mta3-svc.business.ntl.com@i-br0ked-it>
28281 If you read the archive, you will find that this has already been discussed (fairly recently if i recall..), and was thrown out, if you want services SSL support, i recommend you use a SSL tunnel.
28283 When it comes to ZIP links, this would require editing the services protocol module accordingly.. and IMO, shouldnt been needed, as in most cases, services run on the same box as a server.
28285 /****************************************
28286 * Craig "FrostyCoolSlug" McLure
28287 ************* - SpamBox - **************
28288 * InspIRCd - http://www.inspircd.org
28289 * ChatSpike - http://www.chatspike.net
28290 * WinBot - http://www.winbot.co.uk
28291 ****************************************/
28293 /****************************************
28294 * From - Alessandro Ciappei <laser@musichat.net>
28295 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
28296 * Sent - 2003-09-03 @ 15:49:00
28297 * Subject - [IRCServices Coding] New Features
28298 ****************************************/
28300 /****** - Begin Original Message - ******/
28304 >I have an idea for next release.
28305 >A secure link between services and ircd.
28306 >Now many ircd, like Unreal, tr-ircd, bahamut supports a ssl link.
28311 >------------------------------------------------------------------
28312 >To unsubscribe or change your subscription options, visit:
28313 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
28315 /******* - End Original Message - *******/
28320 From ircserv at elric.net Wed Sep 3 20:49:47 2003
28321 From: ircserv at elric.net (Brent DiNicola)
28322 Date: Sat Oct 23 23:10:01 2004
28323 Subject: [IRCServices Coding] Which route to take - Module?
28324 Message-ID: <5.2.1.1.0.20030903223929.016e4648@mail.elric.net>
28326 It wasn't an easy subject to sum up in just a few words.
28328 I am wanting to do something to the ircservices code, I want to change
28329 the way the notice() works. I know that modifying the send.c would be
28330 very frowned upon and then I got to thinking and had suggested that I
28331 maybe make a module to keep the information for me. I know it's against
28332 the RFC, but I am pressed against a brick wall here, I have to give the users
28333 an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
28334 I would like to give them the option of turning on PRIVMSG but have NOTICE
28335 be the default, that would get the lazy people to use NOTICE. Eventually
28336 getting rid of this problem. In the mean time, I was thinking what is the best
28337 way to go about this without causing trouble for me and anyone else who has
28338 to deal with this code. Is it possible or even suggested to make a module that
28339 would replace the notice() from send.c with it's own, leaving the code in
28341 alone and not causing troubles down the road. Suggestions were that I make a
28342 module that kept the info for each nick's setting and then if I could override
28343 the notice() and notice_lang() and notice_help() in send.c that would keep
28345 other code clean and not cause other troubles. I want to know what the best
28346 way to do this would be, I know it's against RFC but I want to move to newer
28347 services than the 1.4.3pre4 that we are using now and add modules so that I
28348 can do things down the line. They are used to having PRIVMSG and I can't just
28349 change it without running people off, so if I can make PRIVMSG an option
28350 then I can't be blamed if they are lazy. Opinions on how to go about this? I
28351 know this topic has been asked before and I know your not going to make it
28352 part of your code, I just wanted to know from the people who know the code
28353 really well what the best route to take would be to do the least amount of
28354 damage. (And if someone has done this.. please let me know what you did,
28355 examples would rock)
28363 ----------------------------------------------------------
28365 | The Whitewolf of Immyrr |
28366 | <elric@elric.net> |
28367 | http://www.melnibone.net |
28368 | Disclaimer: Any opinions expressed here are |
28369 | from my dog. Any liabilities fall to the dog. |
28370 -----------------------------------------------------------
28373 From Craig at chatspike.net Wed Sep 3 21:18:29 2003
28374 From: Craig at chatspike.net (Craig McLure)
28375 Date: Sat Oct 23 23:10:01 2004
28376 Subject: [IRCServices Coding] Which route to take - Module?
28377 Message-ID: <20030904041818.TXAK19019.mta3-svc.business.ntl.com@i-br0ked-it>
28379 lol, Our help no good? :P
28381 i still say module with seperate database (with the nickgroup, and if this option is on or off (This saves having to modify the main nick.db) , somehow extending the /ns SET command to include a new option.. and replacing what ever function sends notices with something that uses an if to query your new database..
28383 Dont ask me for source on this.. i'm just theorising :)
28385 /****************************************
28386 * Craig "FrostyCoolSlug" McLure
28387 ************* - SpamBox - **************
28388 * InspIRCd - http://www.inspircd.org
28389 * ChatSpike - http://www.chatspike.net
28390 * WinBot - http://www.winbot.co.uk
28391 ****************************************/
28393 /****************************************
28394 * From - Brent DiNicola <ircserv@elric.net>
28395 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
28396 * Sent - 2003-09-03 @ 22:49:00
28397 * Subject - [IRCServices Coding] Which route to take - Module?
28398 ****************************************/
28400 /****** - Begin Original Message - ******/
28402 >It wasn't an easy subject to sum up in just a few words.
28404 >I am wanting to do something to the ircservices code, I want to change
28405 >the way the notice() works. I know that modifying the send.c would be
28406 >very frowned upon and then I got to thinking and had suggested that I
28407 >maybe make a module to keep the information for me. I know it's against
28408 >the RFC, but I am pressed against a brick wall here, I have to give the users
28409 >an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
28410 >I would like to give them the option of turning on PRIVMSG but have NOTICE
28411 >be the default, that would get the lazy people to use NOTICE. Eventually
28412 >getting rid of this problem. In the mean time, I was thinking what is the best
28413 >way to go about this without causing trouble for me and anyone else who has
28414 >to deal with this code. Is it possible or even suggested to make a module that
28415 >would replace the notice() from send.c with it's own, leaving the code in
28417 >alone and not causing troubles down the road. Suggestions were that I make a
28418 >module that kept the info for each nick's setting and then if I could override
28419 >the notice() and notice_lang() and notice_help() in send.c that would keep
28421 >other code clean and not cause other troubles. I want to know what the best
28422 >way to do this would be, I know it's against RFC but I want to move to newer
28423 >services than the 1.4.3pre4 that we are using now and add modules so that I
28424 >can do things down the line. They are used to having PRIVMSG and I can't just
28425 >change it without running people off, so if I can make PRIVMSG an option
28426 >then I can't be blamed if they are lazy. Opinions on how to go about this? I
28427 >know this topic has been asked before and I know your not going to make it
28428 >part of your code, I just wanted to know from the people who know the code
28429 >really well what the best route to take would be to do the least amount of
28430 >damage. (And if someone has done this.. please let me know what you did,
28431 >examples would rock)
28439 >----------------------------------------------------------
28440 >| Brent DiNicola |
28441 >| The Whitewolf of Immyrr |
28442 >| <elric@elric.net> |
28443 >| http://www.melnibone.net |
28444 >| Disclaimer: Any opinions expressed here are |
28445 >| from my dog. Any liabilities fall to the dog. |
28446 >-----------------------------------------------------------
28448 >------------------------------------------------------------------
28449 >To unsubscribe or change your subscription options, visit:
28450 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
28453 /******* - End Original Message - *******/
28458 From uhc0 at rz.uni-karlsruhe.de Thu Sep 4 01:34:06 2003
28459 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu)
28460 Date: Sat Oct 23 23:10:01 2004
28461 Subject: [IRCServices Coding] Which route to take - Module?
28462 In-Reply-To: <5.2.1.1.0.20030903223929.016e4648@mail.elric.net>
28463 References: <5.2.1.1.0.20030903223929.016e4648@mail.elric.net>
28464 Message-ID: <1062664383.1917.15.camel@dreadnought.hadiko.de>
28468 Long question; long answer.
28469 First of all, you must come off the thoughts of "Against the RFC".
28470 Why? Because, tons of irc servers available do provide techniques, which
28471 do not appear, or appear differently on the irc RFC, so that by design
28472 these ircds are also against it. In most of the cases, these changes
28473 reflect themselves in their appropriate server-to-server protocols, and
28474 become transient to the clients, so that on client side, the protocol
28475 remains original. This is also the only way of ensuring that all of the
28476 clients can work with a specific irc daemon.
28478 The issue, why PRIVMSG instead of NOTICE is bad, does also result from
28479 the client-to-server part of the RFC. And it has a reason. Consider two
28480 automated clients (bots, services, etc) talking to each other with
28481 PRIVMSG, and saying things like:
28482 <NickServ> otherwise, I change your nick.
28483 <MyBot> Unknown command otherwise. Please repeat your query.
28484 <NickServ> Unknown command UNKNOWN.
28485 <MyBot> Unknown command unknown. Please repeat your query.
28486 <NickServ> Unknown command UNKNOWN.
28487 <MyBot> Unknown command unknown. Please repeat your query.
28488 <NickServ> Unknown command UNKNOWN.
28489 <MyBot> Unknown command unknown. Please repeat your query.
28490 <NickServ> Unknown command UNKNOWN.
28491 <MyBot> Unknown command unknown. Please repeat your query.
28494 Do you understand, what problem may conclude due to PRIVMSG? RFC says
28495 clearly, that clients shall not generate automatic replies to NOTICES.
28496 That way, your bot would not "talk" to NickServ after a NOTICE anymore.
28499 The most easy implementation of this is creating a NF_USE_PRIVMSG flag,
28500 with a value far greater than any of the built-in, so that in future
28501 this flag does not collide with any of the original flags.
28503 Then you create the new SET command for this, as well as its help text,
28504 primarily in the english language file. That part of the work is
28507 Afterwards, you should modify notice_lang, and check for the
28508 NF_USE_PRIVMSG flag of the "ngi" being used; and if true, send PRIVMSG
28509 instead. The same for notice_help. And your case could be marked as
28512 Do keep in mind that requesting support for modified services versions
28513 are subject to be ignored.
28518 On Thu, 2003-09-04 at 05:49, Brent DiNicola wrote:
28519 > It wasn't an easy subject to sum up in just a few words.
28521 > I am wanting to do something to the ircservices code, I want to change
28522 > the way the notice() works. I know that modifying the send.c would be
28523 > very frowned upon and then I got to thinking and had suggested that I
28524 > maybe make a module to keep the information for me. I know it's against
28525 > the RFC, but I am pressed against a brick wall here, I have to give the users
28526 > an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
28527 > I would like to give them the option of turning on PRIVMSG but have NOTICE
28528 > be the default, that would get the lazy people to use NOTICE. Eventually
28529 > getting rid of this problem. In the mean time, I was thinking what is the best
28530 > way to go about this without causing trouble for me and anyone else who has
28531 > to deal with this code. Is it possible or even suggested to make a module that
28532 > would replace the notice() from send.c with it's own, leaving the code in
28534 > alone and not causing troubles down the road. Suggestions were that I make a
28535 > module that kept the info for each nick's setting and then if I could override
28536 > the notice() and notice_lang() and notice_help() in send.c that would keep
28538 > other code clean and not cause other troubles. I want to know what the best
28539 > way to do this would be, I know it's against RFC but I want to move to newer
28540 > services than the 1.4.3pre4 that we are using now and add modules so that I
28541 > can do things down the line. They are used to having PRIVMSG and I can't just
28542 > change it without running people off, so if I can make PRIVMSG an option
28543 > then I can't be blamed if they are lazy. Opinions on how to go about this? I
28544 > know this topic has been asked before and I know your not going to make it
28545 > part of your code, I just wanted to know from the people who know the code
28546 > really well what the best route to take would be to do the least amount of
28547 > damage. (And if someone has done this.. please let me know what you did,
28548 > examples would rock)
28556 > ----------------------------------------------------------
28557 > | Brent DiNicola |
28558 > | The Whitewolf of Immyrr |
28559 > | <elric@elric.net> |
28560 > | http://www.melnibone.net |
28561 > | Disclaimer: Any opinions expressed here are |
28562 > | from my dog. Any liabilities fall to the dog. |
28563 > -----------------------------------------------------------
28565 > ------------------------------------------------------------------
28566 > To unsubscribe or change your subscription options, visit:
28567 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
28569 ------------------------------------------------------------------
28570 | Yusuf Iskenderoglu | You get to meet all sorts, |
28571 | eMail - uhc0@stud.uni-karlsruhe.de| in this line of work... |
28572 | eMail - s_iskend@ira.uka.de | |
28573 | ICQ UIN : 20587464 \ TimeMr14C | |
28574 ------------------------------------------------------------------
28577 From griever at t2n.org Thu Sep 4 13:31:44 2003
28578 From: griever at t2n.org (Robert F Merrill)
28579 Date: Sat Oct 23 23:10:01 2004
28580 Subject: [IRCServices Coding] Which route to take - Module?
28581 References: <5.2.1.1.0.20030903223929.016e4648@mail.elric.net>
28582 Message-ID: <3F57A0BA.9080909@t2n.org>
28584 Brent DiNicola wrote:
28586 > It wasn't an easy subject to sum up in just a few words.
28588 > I am wanting to do something to the ircservices code, I want to change
28589 > the way the notice() works. I know that modifying the send.c would be
28590 > very frowned upon and then I got to thinking and had suggested that I
28591 > maybe make a module to keep the information for me. I know it's against
28592 > the RFC, but I am pressed against a brick wall here, I have to give
28594 > an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
28595 > I would like to give them the option of turning on PRIVMSG but have
28597 > be the default, that would get the lazy people to use NOTICE. Eventually
28598 > getting rid of this problem. In the mean time, I was thinking what is
28600 > way to go about this without causing trouble for me and anyone else
28602 > to deal with this code. Is it possible or even suggested to make a
28604 > would replace the notice() from send.c with it's own, leaving the code
28606 > alone and not causing troubles down the road. Suggestions were that I
28608 > module that kept the info for each nick's setting and then if I could
28610 > the notice() and notice_lang() and notice_help() in send.c that would
28612 > other code clean and not cause other troubles. I want to know what the
28614 > way to do this would be, I know it's against RFC but I want to move to
28616 > services than the 1.4.3pre4 that we are using now and add modules so
28618 > can do things down the line. They are used to having PRIVMSG and I
28620 > change it without running people off, so if I can make PRIVMSG an option
28621 > then I can't be blamed if they are lazy. Opinions on how to go about
28623 > know this topic has been asked before and I know your not going to
28625 > part of your code, I just wanted to know from the people who know the
28627 > really well what the best route to take would be to do the least
28629 > damage. (And if someone has done this.. please let me know what you did,
28630 > examples would rock)
28638 > ----------------------------------------------------------
28639 > | Brent DiNicola |
28640 > | The Whitewolf of Immyrr |
28641 > | <elric@elric.net> |
28642 > | http://www.melnibone.net |
28643 > | Disclaimer: Any opinions expressed here are |
28644 > | from my dog. Any liabilities fall to the dog. |
28645 > -----------------------------------------------------------
28646 > ------------------------------------------------------------------
28647 > To unsubscribe or change your subscription options, visit:
28648 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
28652 Services is not the place to fix broken clients, and any client which
28653 doesn't display notices correctly is broken. If someone wants to see
28654 notices differently, they can either
28655 a) change their client or in the case of webtv b) change the ircd
28657 services is the wrong thing to change
28660 From Craig at chatspike.net Thu Sep 4 13:52:48 2003
28661 From: Craig at chatspike.net (Craig McLure)
28662 Date: Sat Oct 23 23:10:01 2004
28663 Subject: [IRCServices Coding] Which route to take - Module?
28664 Message-ID: <20030904205232.SDRM23096.mta6-svc.business.ntl.com@i-br0ked-it>
28666 dont mean to sound rude, but this isnt a 'moral' discussion, as it were, rather than saying 'I dont think this needs done', i think it would be best to help him.. its not a discussion on if its right or wrong, its a 'How to do it' discussion.. If you cant contribute to this.. please ignore this 'thread' :p
28668 /****************************************
28669 * Craig "FrostyCoolSlug" McLure
28670 ************* - SpamBox - **************
28671 * InspIRCd - http://www.inspircd.org
28672 * ChatSpike - http://www.chatspike.net
28673 * WinBot - http://www.winbot.co.uk
28674 ****************************************/
28676 /****************************************
28677 * From - Robert F Merrill <griever@t2n.org>
28678 * To - IRC Services Coding Mailing List <ircservices-coding@ircservices.za.net>
28679 * Sent - 2003-09-04 @ 16:29:00
28680 * Subject - Re: [IRCServices Coding] Which route to take - Module?
28681 ****************************************/
28683 /****** - Begin Original Message - ******/
28685 >Brent DiNicola wrote:
28687 >> It wasn't an easy subject to sum up in just a few words.
28689 >> I am wanting to do something to the ircservices code, I want to change
28690 >> the way the notice() works. I know that modifying the send.c would be
28691 >> very frowned upon and then I got to thinking and had suggested that I
28692 >> maybe make a module to keep the information for me. I know it's against
28693 >> the RFC, but I am pressed against a brick wall here, I have to give
28695 >> an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
28696 >> I would like to give them the option of turning on PRIVMSG but have
28698 >> be the default, that would get the lazy people to use NOTICE. Eventually
28699 >> getting rid of this problem. In the mean time, I was thinking what is
28701 >> way to go about this without causing trouble for me and anyone else
28703 >> to deal with this code. Is it possible or even suggested to make a
28705 >> would replace the notice() from send.c with it's own, leaving the code
28707 >> alone and not causing troubles down the road. Suggestions were that I
28709 >> module that kept the info for each nick's setting and then if I could
28711 >> the notice() and notice_lang() and notice_help() in send.c that would
28713 >> other code clean and not cause other troubles. I want to know what the
28715 >> way to do this would be, I know it's against RFC but I want to move to
28717 >> services than the 1.4.3pre4 that we are using now and add modules so
28719 >> can do things down the line. They are used to having PRIVMSG and I
28721 >> change it without running people off, so if I can make PRIVMSG an option
28722 >> then I can't be blamed if they are lazy. Opinions on how to go about
28724 >> know this topic has been asked before and I know your not going to
28726 >> part of your code, I just wanted to know from the people who know the
28728 >> really well what the best route to take would be to do the least
28730 >> damage. (And if someone has done this.. please let me know what you did,
28731 >> examples would rock)
28739 >> ----------------------------------------------------------
28740 >> | Brent DiNicola |
28741 >> | The Whitewolf of Immyrr |
28742 >> | <elric@elric.net> |
28743 >> | http://www.melnibone.net |
28744 >> | Disclaimer: Any opinions expressed here are |
28745 >> | from my dog. Any liabilities fall to the dog. |
28746 >> -----------------------------------------------------------
28747 >> ------------------------------------------------------------------
28748 >> To unsubscribe or change your subscription options, visit:
28749 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
28753 >Services is not the place to fix broken clients, and any client which
28754 >doesn't display notices correctly is broken. If someone wants to see
28755 >notices differently, they can either
28756 >a) change their client or in the case of webtv b) change the ircd
28758 >services is the wrong thing to change
28760 >------------------------------------------------------------------
28761 >To unsubscribe or change your subscription options, visit:
28762 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
28765 /******* - End Original Message - *******/
28770 From quension at mac.com Thu Sep 4 13:54:21 2003
28771 From: quension at mac.com (Trevor Talbot)
28772 Date: Sat Oct 23 23:10:01 2004
28773 Subject: [IRCServices Coding] Which route to take - Module?
28774 In-Reply-To: <3F57A0BA.9080909@t2n.org>
28775 Message-ID: <E8AC4DDC-DF19-11D7-905C-0003938D6866@mac.com>
28777 On Thursday, Sep 4, 2003, at 13:29 US/Pacific, Robert F Merrill wrote:
28779 > Brent DiNicola wrote:
28781 >> It wasn't an easy subject to sum up in just a few words.
28785 > Services is not the place to fix broken clients, and any client which
28786 > doesn't display notices correctly is broken. If someone wants to see
28787 > notices differently, they can either a) change their client or in the
28788 > case of webtv b) change the ircd
28790 > services is the wrong thing to change
28792 And telling someone what they obviously already know is generally not a
28793 good idea. Especially when they spent a very long paragraph defending
28794 their decision in the first place.
28796 This is the coding list, not the feature request list. He asked for
28797 code design approaches, not for political insight.
28802 From diego at redesul.net Thu Sep 18 16:29:40 2003
28803 From: diego at redesul.net (Diego B. Contezini)
28804 Date: Sat Oct 23 23:10:01 2004
28805 Subject: [IRCServices Coding] Re: How to get a core..
28806 Message-ID: <001c01c37e2d$c95d7840$3cc8a8c0@angel>
28808 Oooopz, im answering my ask...
28809 Looking in FAQ, where i should look before ask (sorry), I seen that you need
28810 to change ./configure to drop a core.
28811 If someone more is needing it, is just configure with:
28812 ./configure -dumpcore -cflags -g -defaults
28818 ----- Original Message -----
28819 From: "Diego B. Contezini" <diego@redesul.net>
28820 To: <ircservices-coding@ircservices.za.net>
28821 Sent: Thursday, September 18, 2003 6:35 PM
28822 Subject: How to get a core..
28825 > Hello, im destruct_, im the administrator of the RedeSul Network.
28826 > (irc.redesul.net).
28827 > I'm with 28000 nick registers, sometimes our network get 5500 simultaneous
28828 > users, and we are very happy with your services.
28829 > Im wanting to help to search and stops bugs on ircservices, but i never
28832 > I tryed ulimit -c unlimited before run it, but it never drop a core...
28833 > Someone have any idea about how i can get it, to debug without need to
28835 > the services while debugging?
28836 > Its segfaulting approx. all days, one time for day.. sometimes get 2 days
28837 > without to go down.
28838 > Im with a redhat 9.
28842 > Diego B. Contezini aka destruct_ | irc.redesul.net
28843 > (Sorry for my confuse english.)
28847 From diego at redesul.net Thu Sep 18 17:12:05 2003
28848 From: diego at redesul.net (Diego B. Contezini)
28849 Date: Sat Oct 23 23:10:01 2004
28850 Subject: [IRCServices Coding] How to get a core..
28851 References: <Law14-F109aJWJVUn700006a187@hotmail.com>
28852 Message-ID: <000901c37e2c$b8bd9980$3cc8a8c0@angel>
28854 Hello, im destruct_, im the administrator of the RedeSul Network.
28856 I'm with 28000 nick registers, sometimes our network get 5500 simultaneous
28857 users, and we are very happy with your services.
28858 Im wanting to help to search and stops bugs on ircservices, but i never get
28860 I tryed ulimit -c unlimited before run it, but it never drop a core...
28861 Someone have any idea about how i can get it, to debug without need to break
28862 the services while debugging?
28863 Its segfaulting approx. all days, one time for day.. sometimes get 2 days
28864 without to go down.
28865 Im with a redhat 9.
28869 Diego B. Contezini aka destruct_ | irc.redesul.net
28870 (Sorry for my confuse english.)
28873 From engin at piratetv.net Sun Sep 21 09:37:08 2003
28874 From: engin at piratetv.net (engin@piratetv)
28875 Date: Sat Oct 23 23:10:01 2004
28876 Subject: [IRCServices Coding] operserv
28877 Message-ID: <002101c3805f$0910a4c0$c7cf87d4@ptv91i58zrrpyd>
28881 can anyone help or point me to some good documentation regarding a
28882 version of unreal ircd we are running on a mandrake linux box..im mailing
28883 on behalf of the administrator who usually uses ssh to get into the box
28884 and make changes so im not super technical myself.the issue is with
28885 operserv..i cant access any operserv commands from my machine ( which
28886 is on the same local network as the box running the irc server ) always
28887 get operserv - access denied message..so im assuming it doesent
28888 recognise my remote ip address at an administrator..does anyone know
28889 the right sort of commands to use to set my remote machine to be
28890 recognised as admin or can they point me to any good support docs
28891 as i havent been able to find any yet
28895 -------------- next part --------------
28896 An HTML attachment was scrubbed...
28897 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030921/fdc12b4e/attachment-0001.htm
28898 From Craig at chatspike.net Sun Sep 21 14:28:23 2003
28899 From: Craig at chatspike.net (Craig McLure)
28900 Date: Sat Oct 23 23:10:01 2004
28901 Subject: [IRCServices Coding] operserv
28902 Message-ID: <E1A1Bk4-0001Xo-00@ptb-mailc04.plus.net>
28904 make sure you are on the services administrator list, if you are not, get the root administrator to add you using the command:
28906 [22:27] -OperServ- Syntax: ADMIN ADD nickname
28907 [22:27] -OperServ- ADMIN DEL nickname
28908 [22:27] -OperServ- ADMIN LIST
28910 [22:27] -OperServ- Allows the Services super-user to add or remove nicknames
28911 [22:27] -OperServ- to or from the Services admin list. A user whose nickname
28912 [22:27] -OperServ- is on the Services admin list and who has identified to
28913 [22:27] -OperServ- NickServ will be able to access Services admin commands.
28915 [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the command.
28916 [22:27] -OperServ- All other use limited to Services super-user.
28920 /****************************************
28921 * Craig "FrostyCoolSlug" McLure
28922 ************* - SpamBox - **************
28923 * InspIRCd - http://www.inspircd.org
28924 * ChatSpike - http://www.chatspike.net
28925 * WinBot - http://www.winbot.co.uk
28926 ****************************************/
28928 /****************************************
28929 * From - engin <engin@piratetv.net>
28930 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
28931 * Sent - 2003-09-21 @ 17:40:00
28932 * Subject - [IRCServices Coding] operserv
28933 ****************************************/
28935 /****** - Begin Original Message - ******/
28939 >can anyone help or point me to some good documentation regarding a
28940 >version of unreal ircd we are running on a mandrake linux box..im mailing
28941 >on behalf of the administrator who usually uses ssh to get into the box
28942 >and make changes so im not super technical myself.the issue is with
28943 >operserv..i cant access any operserv commands from my machine ( which
28944 >is on the same local network as the box running the irc server ) always
28945 >get operserv - access denied message..so im assuming it doesent
28946 >recognise my remote ip address at an administrator..does anyone know
28947 >the right sort of commands to use to set my remote machine to be
28948 >recognised as admin or can they point me to any good support docs
28949 >as i havent been able to find any yet
28953 >------------------------------------------------------------------
28954 >To unsubscribe or change your subscription options, visit:
28955 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
28957 /******* - End Original Message - *******/
28961 From saturn at jetirc.net Sun Sep 21 15:24:25 2003
28962 From: saturn at jetirc.net (Saturn)
28963 Date: Sat Oct 23 23:10:02 2004
28964 Subject: [IRCServices Coding] operserv
28965 References: <002101c3805f$0910a4c0$c7cf87d4@ptv91i58zrrpyd>
28966 Message-ID: <002b01c3808e$f2590ee0$6401a8c0@turby>
28968 Contact me directly... I have quite a bit of experience with unreal and these services...
28972 ----- Original Message -----
28973 From: engin@piratetv
28974 To: ircservices-coding@ircservices.za.net
28975 Sent: Sunday, September 21, 2003 9:40 AM
28976 Subject: [IRCServices Coding] operserv
28981 can anyone help or point me to some good documentation regarding a
28982 version of unreal ircd we are running on a mandrake linux box..im mailing
28983 on behalf of the administrator who usually uses ssh to get into the box
28984 and make changes so im not super technical myself.the issue is with
28985 operserv..i cant access any operserv commands from my machine ( which
28986 is on the same local network as the box running the irc server ) always
28987 get operserv - access denied message..so im assuming it doesent
28988 recognise my remote ip address at an administrator..does anyone know
28989 the right sort of commands to use to set my remote machine to be
28990 recognised as admin or can they point me to any good support docs
28991 as i havent been able to find any yet
28998 ------------------------------------------------------------------------------
29001 ------------------------------------------------------------------
29002 To unsubscribe or change your subscription options, visit:
29003 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
29004 -------------- next part --------------
29005 An HTML attachment was scrubbed...
29006 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030921/ca188e06/attachment-0001.html
29007 From saturn at jetirc.net Sun Sep 21 17:14:42 2003
29008 From: saturn at jetirc.net (Saturn)
29009 Date: Sat Oct 23 23:10:02 2004
29010 Subject: [IRCServices Coding] operserv
29011 References: <E1A1Bk4-0001Xo-00@ptb-mailc04.plus.net>
29012 Message-ID: <000d01c3809e$5b9d2800$6401a8c0@turby>
29014 Not to mention the obvious: You need to have an O:line and be opered up
29015 before Operserv will even listen to your commands without access denied....
29017 ----- Original Message -----
29018 From: "Craig McLure" <Craig@chatspike.net>
29019 To: "IRC Services Coding Mailing List"
29020 <ircservices-coding@ircservices.za.net>
29021 Sent: Sunday, September 21, 2003 3:28 PM
29022 Subject: Re: [IRCServices Coding] operserv
29025 make sure you are on the services administrator list, if you are not, get
29026 the root administrator to add you using the command:
29028 [22:27] -OperServ- Syntax: ADMIN ADD nickname
29029 [22:27] -OperServ- ADMIN DEL nickname
29030 [22:27] -OperServ- ADMIN LIST
29032 [22:27] -OperServ- Allows the Services super-user to add or remove nicknames
29033 [22:27] -OperServ- to or from the Services admin list. A user whose nickname
29034 [22:27] -OperServ- is on the Services admin list and who has identified to
29035 [22:27] -OperServ- NickServ will be able to access Services admin commands.
29037 [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
29039 [22:27] -OperServ- All other use limited to Services super-user.
29043 /****************************************
29044 * Craig "FrostyCoolSlug" McLure
29045 ************* - SpamBox - **************
29046 * InspIRCd - http://www.inspircd.org
29047 * ChatSpike - http://www.chatspike.net
29048 * WinBot - http://www.winbot.co.uk
29049 ****************************************/
29051 /****************************************
29052 * From - engin <engin@piratetv.net>
29053 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
29054 * Sent - 2003-09-21 @ 17:40:00
29055 * Subject - [IRCServices Coding] operserv
29056 ****************************************/
29058 /****** - Begin Original Message - ******/
29062 >can anyone help or point me to some good documentation regarding a
29063 >version of unreal ircd we are running on a mandrake linux box..im mailing
29064 >on behalf of the administrator who usually uses ssh to get into the box
29065 >and make changes so im not super technical myself.the issue is with
29066 >operserv..i cant access any operserv commands from my machine ( which
29067 >is on the same local network as the box running the irc server ) always
29068 >get operserv - access denied message..so im assuming it doesent
29069 >recognise my remote ip address at an administrator..does anyone know
29070 >the right sort of commands to use to set my remote machine to be
29071 >recognised as admin or can they point me to any good support docs
29072 >as i havent been able to find any yet
29076 >------------------------------------------------------------------
29077 >To unsubscribe or change your subscription options, visit:
29078 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
29080 /******* - End Original Message - *******/
29083 ------------------------------------------------------------------
29084 To unsubscribe or change your subscription options, visit:
29085 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
29088 From engin at piratetv.net Mon Sep 22 05:13:57 2003
29089 From: engin at piratetv.net (engin@piratetv)
29090 Date: Sat Oct 23 23:10:02 2004
29091 Subject: [IRCServices Coding] Re: IRCServices-Coding Digest, Vol 8, Issue 5
29092 References: <20030922120923.425971706D@snow.fingers.co.za>
29093 Message-ID: <003c01c38103$73a516f0$c7cf87d4@ptv91i58zrrpyd>
29095 many thanks for the replies..im going to get the info to the
29096 root administrator now and ill let you know how i get
29103 ----- Original Message -----
29104 From: <ircservices-coding-request@ircservices.za.net>
29105 To: <ircservices-coding@ircservices.za.net>
29106 Sent: Monday, September 22, 2003 1:09 PM
29107 Subject: IRCServices-Coding Digest, Vol 8, Issue 5
29110 > Send IRCServices-Coding mailing list submissions to
29111 > ircservices-coding@ircservices.za.net
29113 > To subscribe or unsubscribe via the World Wide Web, visit
29114 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
29115 > or, via email, send a message with subject or body 'help' to
29116 > ircservices-coding-request@ircservices.za.net
29118 > You can reach the person managing the list at
29119 > ircservices-coding-owner@ircservices.za.net
29121 > When replying, please edit your Subject line so it is more specific
29122 > than "Re: Contents of IRCServices-Coding digest..."
29127 > 1. operserv (engin@piratetv)
29128 > 2. Re: operserv (Craig McLure)
29129 > 3. Re: operserv (Saturn)
29130 > 4. Re: operserv (Saturn)
29133 > ----------------------------------------------------------------------
29136 > Date: Sun, 21 Sep 2003 17:40:15 +0100
29137 > From: "engin@piratetv" <engin@piratetv.net>
29138 > Subject: [IRCServices Coding] operserv
29139 > To: <ircservices-coding@ircservices.za.net>
29140 > Message-ID: <002101c3805f$0910a4c0$c7cf87d4@ptv91i58zrrpyd>
29141 > Content-Type: text/plain; charset="iso-8859-1"
29145 > can anyone help or point me to some good documentation regarding a
29146 > version of unreal ircd we are running on a mandrake linux box..im mailing
29147 > on behalf of the administrator who usually uses ssh to get into the box
29148 > and make changes so im not super technical myself.the issue is with
29149 > operserv..i cant access any operserv commands from my machine ( which
29150 > is on the same local network as the box running the irc server ) always
29151 > get operserv - access denied message..so im assuming it doesent
29152 > recognise my remote ip address at an administrator..does anyone know
29153 > the right sort of commands to use to set my remote machine to be
29154 > recognised as admin or can they point me to any good support docs
29155 > as i havent been able to find any yet
29159 > -------------- next part --------------
29160 > An HTML attachment was scrubbed...
29162 http://snow.fingers.co.za/pipermail/ircservices-coding/attachments/20030921/
29163 fdc12b4e/attachment-0001.htm
29165 > ------------------------------
29168 > Date: Sun, 21 Sep 2003 22:28:13 +0000
29169 > From: "Craig McLure" <Craig@chatspike.net>
29170 > Subject: Re: [IRCServices Coding] operserv
29171 > To: IRC Services Coding Mailing List
29172 > <ircservices-coding@ircservices.za.net>
29173 > Message-ID: <E1A1Bk4-0001Xo-00@ptb-mailc04.plus.net>
29174 > Content-Type: text/plain; charset="us-ascii"
29176 > make sure you are on the services administrator list, if you are not, get
29177 the root administrator to add you using the command:
29179 > [22:27] -OperServ- Syntax: ADMIN ADD nickname
29180 > [22:27] -OperServ- ADMIN DEL nickname
29181 > [22:27] -OperServ- ADMIN LIST
29182 > [22:27] -OperServ-
29183 > [22:27] -OperServ- Allows the Services super-user to add or remove
29185 > [22:27] -OperServ- to or from the Services admin list. A user whose
29187 > [22:27] -OperServ- is on the Services admin list and who has identified to
29188 > [22:27] -OperServ- NickServ will be able to access Services admin
29190 > [22:27] -OperServ-
29191 > [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
29193 > [22:27] -OperServ- All other use limited to Services super-user.
29197 > /****************************************
29198 > * Craig "FrostyCoolSlug" McLure
29199 > ************* - SpamBox - **************
29200 > * InspIRCd - http://www.inspircd.org
29201 > * ChatSpike - http://www.chatspike.net
29202 > * WinBot - http://www.winbot.co.uk
29203 > ****************************************/
29205 > /****************************************
29206 > * From - engin <engin@piratetv.net>
29207 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
29208 > * Sent - 2003-09-21 @ 17:40:00
29209 > * Subject - [IRCServices Coding] operserv
29210 > ****************************************/
29212 > /****** - Begin Original Message - ******/
29216 > >can anyone help or point me to some good documentation regarding a
29217 > >version of unreal ircd we are running on a mandrake linux box..im mailing
29218 > >on behalf of the administrator who usually uses ssh to get into the box
29219 > >and make changes so im not super technical myself.the issue is with
29220 > >operserv..i cant access any operserv commands from my machine ( which
29221 > >is on the same local network as the box running the irc server ) always
29222 > >get operserv - access denied message..so im assuming it doesent
29223 > >recognise my remote ip address at an administrator..does anyone know
29224 > >the right sort of commands to use to set my remote machine to be
29225 > >recognised as admin or can they point me to any good support docs
29226 > >as i havent been able to find any yet
29230 > >------------------------------------------------------------------
29231 > >To unsubscribe or change your subscription options, visit:
29232 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
29234 > /******* - End Original Message - *******/
29238 > ------------------------------
29241 > Date: Sun, 21 Sep 2003 15:23:13 -0700
29242 > From: "Saturn" <saturn@jetirc.net>
29243 > Subject: Re: [IRCServices Coding] operserv
29244 > To: "IRC Services Coding Mailing List"
29245 > <ircservices-coding@ircservices.za.net>
29246 > Message-ID: <002b01c3808e$f2590ee0$6401a8c0@turby>
29247 > Content-Type: text/plain; charset="iso-8859-1"
29249 > Contact me directly... I have quite a bit of experience with unreal and
29254 > ----- Original Message -----
29255 > From: engin@piratetv
29256 > To: ircservices-coding@ircservices.za.net
29257 > Sent: Sunday, September 21, 2003 9:40 AM
29258 > Subject: [IRCServices Coding] operserv
29263 > can anyone help or point me to some good documentation regarding a
29264 > version of unreal ircd we are running on a mandrake linux box..im
29266 > on behalf of the administrator who usually uses ssh to get into the box
29267 > and make changes so im not super technical myself.the issue is with
29268 > operserv..i cant access any operserv commands from my machine ( which
29269 > is on the same local network as the box running the irc server ) always
29270 > get operserv - access denied message..so im assuming it doesent
29271 > recognise my remote ip address at an administrator..does anyone know
29272 > the right sort of commands to use to set my remote machine to be
29273 > recognised as admin or can they point me to any good support docs
29274 > as i havent been able to find any yet
29281 > --------------------------------------------------------------------------
29285 > ------------------------------------------------------------------
29286 > To unsubscribe or change your subscription options, visit:
29287 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
29288 > -------------- next part --------------
29289 > An HTML attachment was scrubbed...
29291 http://snow.fingers.co.za/pipermail/ircservices-coding/attachments/20030921/
29292 ca188e06/attachment-0001.htm
29294 > ------------------------------
29297 > Date: Sun, 21 Sep 2003 17:13:31 -0700
29298 > From: "Saturn" <saturn@jetirc.net>
29299 > Subject: Re: [IRCServices Coding] operserv
29300 > To: "IRC Services Coding Mailing List"
29301 > <ircservices-coding@ircservices.za.net>
29302 > Message-ID: <000d01c3809e$5b9d2800$6401a8c0@turby>
29303 > Content-Type: text/plain; charset="iso-8859-1"
29305 > Not to mention the obvious: You need to have an O:line and be opered up
29306 > before Operserv will even listen to your commands without access
29309 > ----- Original Message -----
29310 > From: "Craig McLure" <Craig@chatspike.net>
29311 > To: "IRC Services Coding Mailing List"
29312 > <ircservices-coding@ircservices.za.net>
29313 > Sent: Sunday, September 21, 2003 3:28 PM
29314 > Subject: Re: [IRCServices Coding] operserv
29317 > make sure you are on the services administrator list, if you are not, get
29318 > the root administrator to add you using the command:
29320 > [22:27] -OperServ- Syntax: ADMIN ADD nickname
29321 > [22:27] -OperServ- ADMIN DEL nickname
29322 > [22:27] -OperServ- ADMIN LIST
29323 > [22:27] -OperServ-
29324 > [22:27] -OperServ- Allows the Services super-user to add or remove
29326 > [22:27] -OperServ- to or from the Services admin list. A user whose
29328 > [22:27] -OperServ- is on the Services admin list and who has identified to
29329 > [22:27] -OperServ- NickServ will be able to access Services admin
29331 > [22:27] -OperServ-
29332 > [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
29334 > [22:27] -OperServ- All other use limited to Services super-user.
29338 > /****************************************
29339 > * Craig "FrostyCoolSlug" McLure
29340 > ************* - SpamBox - **************
29341 > * InspIRCd - http://www.inspircd.org
29342 > * ChatSpike - http://www.chatspike.net
29343 > * WinBot - http://www.winbot.co.uk
29344 > ****************************************/
29346 > /****************************************
29347 > * From - engin <engin@piratetv.net>
29348 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
29349 > * Sent - 2003-09-21 @ 17:40:00
29350 > * Subject - [IRCServices Coding] operserv
29351 > ****************************************/
29353 > /****** - Begin Original Message - ******/
29357 > >can anyone help or point me to some good documentation regarding a
29358 > >version of unreal ircd we are running on a mandrake linux box..im mailing
29359 > >on behalf of the administrator who usually uses ssh to get into the box
29360 > >and make changes so im not super technical myself.the issue is with
29361 > >operserv..i cant access any operserv commands from my machine ( which
29362 > >is on the same local network as the box running the irc server ) always
29363 > >get operserv - access denied message..so im assuming it doesent
29364 > >recognise my remote ip address at an administrator..does anyone know
29365 > >the right sort of commands to use to set my remote machine to be
29366 > >recognised as admin or can they point me to any good support docs
29367 > >as i havent been able to find any yet
29371 > >------------------------------------------------------------------
29372 > >To unsubscribe or change your subscription options, visit:
29373 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
29375 > /******* - End Original Message - *******/
29378 > ------------------------------------------------------------------
29379 > To unsubscribe or change your subscription options, visit:
29380 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
29383 > ------------------------------
29385 > _______________________________________________
29386 > IRCServices-Coding mailing list
29387 > IRCServices-Coding@ircservices.za.net
29388 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
29391 > End of IRCServices-Coding Digest, Vol 8, Issue 5
29392 > ************************************************
29395 From diego at redesul.net Sun Oct 5 22:45:19 2003
29396 From: diego at redesul.net (Diego B. Contezini)
29397 Date: Sat Oct 23 23:10:02 2004
29398 Subject: [IRCServices Coding] Bug....
29399 References: <E1A1Bk4-0001Xo-00@ptb-mailc04.plus.net>
29400 <000d01c3809e$5b9d2800$6401a8c0@turby>
29401 Message-ID: <003b01c38b91$5f6a32e0$3cc8a8c0@angel>
29403 Sometimes has occur this bug, last 1 year....
29404 on a network with 30k registers, its happening with latency of 3.. 4
29407 someone have any idea?
29409 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
29410 av=0xbfffeec8) at channels.c:278
29413 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
29414 av=0xbfffeec8) at channels.c:278
29415 chan = (Channel *) 0xa97b6b8
29416 s = 0x20656c62 <Address 0x20656c62 out of bounds>
29418 modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
29419 #1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:680
29421 "-isl\000\037\006\bp?????????@???\006\b\000\000\000\000\000\000\000B\000\000
29422 \000\0007 \006\b\003\000\000\000TZ\000\000????????????
29423 ?????????\001\200??????@???\006\b@???\006\b@???\006\b@???\006\bO???\006\b@\0
29424 02\a\b@???\006\b@\002\a\b", '\0' <repeats 20 times>,
29425 "\027\000\000\000\000\000\000\000W???\022B\000\000\000\000\000\000\000\000\0
29426 05\000\000\000\210o\a\bTZ\000\000\000\000\000\000???????????????<\023B\001\0
29427 00\000\000???????????????m\tBd???\022B???q\a\b\v???\006B\024\032\023B\024\03
29428 2\023B3\035\rB\024\032\023B??????\006B\003\000\000\000????????????\027\000\0
29429 00\000\000\000\000\000\024\032"...
29430 s = 0xbfffeef0 "-isl"
29431 argv = {0xa97b6c0 "#young", 0x20656c62 <Address 0x20656c62 out of
29433 0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 out
29434 of bounds>, 0x42133cec "\004", 0xbffff1fc "",
29435 0x4204533d "\201?????????\016", 0x42131a14 " \031\023B???h\001@`???"}
29439 #2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
29443 md = (struct modedata *) 0x0
29448 #3 0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at main.c:269
29450 now_msec = 241253125
29451 last_update = 1065392973
29452 last_check = 241252363
29453 #4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
29454 No symbol table info available.
29459 From achurch at achurch.org Mon Oct 6 00:41:54 2003
29460 From: achurch at achurch.org (Andrew Church)
29461 Date: Sat Oct 23 23:10:02 2004
29462 Subject: [IRCServices Coding] Bug....
29463 In-Reply-To: <003b01c38b91$5f6a32e0$3cc8a8c0@angel>
29464 Message-ID: <3f811cad.24262@achurch.org>
29469 achurch@achurch.org
29470 http://achurch.org/
29472 >Sometimes has occur this bug, last 1 year....
29473 >on a network with 30k registers, its happening with latency of 3.. 4
29476 >someone have any idea?
29478 >#0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
29479 >av=0xbfffeec8) at channels.c:278
29482 >#0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
29483 >av=0xbfffeec8) at channels.c:278
29484 > chan = (Channel *) 0xa97b6b8
29485 > s = 0x20656c62 <Address 0x20656c62 out of bounds>
29487 > modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
29488 >#1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:68
29491 >"-isl\000\037\006\bp���@�\006\b\000\000\0
29492 >00\000\000\000\000B\000\000
29493 >\000\0007 \006\b\003\000\000\000TZ\000\000���ï¿
29495 >���\001\200��@�\006\b@ï
29496 >¿½\006\b@�\006\b@�\006\bO�\006\b@\0
29497 >02\a\b@�\006\b@\002\a\b", '\0' <repeats 20 times>,
29498 >"\027\000\000\000\000\000\000\000W�\022B\000\000\000\000\000\000\
29500 >05\000\000\000\210o\a\bTZ\000\000\000\000\000\000��ï¿
29501 >½ï¿½ï¿½<\023B\001\0
29502 >00\000\000�����m\tBd�\022
29503 >B�q\a\b\v�\006B\024\032\023B\024\03
29504 >2\023B3\035\rB\024\032\023B��\006B\003\000\000\000�
29506 >00\000\000\000\000\000\024\032"...
29507 > s = 0xbfffeef0 "-isl"
29508 > argv = {0xa97b6c0 "#young", 0x20656c62 <Address 0x20656c62 out
29511 > 0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 o
29513 >of bounds>, 0x42133cec "\004", 0xbffff1fc "",
29514 > 0x4204533d "\201���\016", 0x42131a14 " \031\023
29519 >#2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:32
29524 > md = (struct modedata *) 0x0
29529 >#3 0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at ma
29532 > now_msec = 241253125
29533 > last_update = 1065392973
29534 > last_check = 241252363
29535 >#4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
29536 >No symbol table info available.
29540 >------------------------------------------------------------------
29541 >To unsubscribe or change your subscription options, visit:
29542 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
29544 From diego at redesul.net Mon Oct 6 02:36:40 2003
29545 From: diego at redesul.net (Diego B. Contezini)
29546 Date: Sat Oct 23 23:10:02 2004
29547 Subject: [IRCServices Coding] Bug....
29548 References: <3f811cad.24262@achurch.org>
29549 Message-ID: <005501c38bed$4c9b1dd0$3cc8a8c0@angel>
29552 ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
29556 Its the last version.......
29559 ----- Original Message -----
29560 From: "Andrew Church" <achurch@achurch.org>
29561 To: <ircservices-coding@ircservices.za.net>
29562 Sent: Monday, October 06, 2003 4:41 AM
29563 Subject: Re: [IRCServices Coding] Bug....
29569 > achurch@achurch.org
29570 > http://achurch.org/
29572 > >Sometimes has occur this bug, last 1 year....
29573 > >on a network with 30k registers, its happening with latency of 3.. 4
29576 > >someone have any idea?
29578 > >#0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
29579 > >av=0xbfffeec8) at channels.c:278
29580 > >278 while (*s) {
29582 > >#0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
29583 > >av=0xbfffeec8) at channels.c:278
29584 > > chan = (Channel *) 0xa97b6b8
29585 > > s = 0x20656c62 <Address 0x20656c62 out of bounds>
29587 > > modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
29588 > >#1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:68
29591 > >"-isl\000\037\006\bp?????????@???\006\b\000\000\0
29592 > >00\000\000\000\000B\000\000
29593 > >\000\0007 \006\b\003\000\000\000TZ\000\000???????????
29595 > >?????????\001\200??????@???\006\b@?
29596 > >??\006\b@???\006\b@???\006\bO???\006\b@\0
29597 > >02\a\b@???\006\b@\002\a\b", '\0' <repeats 20 times>,
29598 > >"\027\000\000\000\000\000\000\000W???\022B\000\000\000\000\000\000\
29600 > >05\000\000\000\210o\a\bTZ\000\000\000\000\000\000????????
29601 > >???????<\023B\001\0
29602 > >00\000\000???????????????m\tBd???\022
29603 > >B???q\a\b\v???\006B\024\032\023B\024\03
29604 > >2\023B3\035\rB\024\032\023B??????\006B\003\000\000\000???
29605 > >?????????\027\000\0
29606 > >00\000\000\000\000\000\024\032"...
29607 > > s = 0xbfffeef0 "-isl"
29608 > > argv = {0xa97b6c0 "#young", 0x20656c62 <Address 0x20656c62 out
29611 > > 0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 o
29613 > >of bounds>, 0x42133cec "\004", 0xbffff1fc "",
29614 > > 0x4204533d "\201?????????\016", 0x42131a14 " \031\023
29615 > >B???h\001@`???"}
29619 > >#2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:32
29623 > > modes_orig = 0x0
29624 > > md = (struct modedata *) 0x0
29629 > >#3 0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at ma
29631 > > now = 1065393142
29632 > > now_msec = 241253125
29633 > > last_update = 1065392973
29634 > > last_check = 241252363
29635 > >#4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
29636 > >No symbol table info available.
29640 > >------------------------------------------------------------------
29641 > >To unsubscribe or change your subscription options, visit:
29642 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
29643 > ------------------------------------------------------------------
29644 > To unsubscribe or change your subscription options, visit:
29645 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
29649 From achurch at achurch.org Mon Oct 6 06:45:43 2003
29650 From: achurch at achurch.org (Andrew Church)
29651 Date: Sat Oct 23 23:10:02 2004
29652 Subject: [IRCServices Coding] Bug....
29653 In-Reply-To: <005501c38bed$4c9b1dd0$3cc8a8c0@angel>
29654 Message-ID: <3f8171f9.25006@achurch.org>
29657 >ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
29661 >Its the last version.......
29663 Then send a full debug log (from startup to crash), or I can't help.
29666 achurch@achurch.org
29667 http://achurch.org/
29669 From diego at redesul.net Mon Oct 6 17:16:29 2003
29670 From: diego at redesul.net (Diego B. Contezini)
29671 Date: Sat Oct 23 23:10:02 2004
29672 Subject: [IRCServices Coding] Bug....
29673 References: <3f8171f9.25006@achurch.org>
29674 Message-ID: <010601c38c68$2e6dc8a0$3cc8a8c0@angel>
29676 And how should be this log? i sent a backtrace......
29679 ----- Original Message -----
29680 From: "Andrew Church" <achurch@achurch.org>
29681 To: <ircservices-coding@ircservices.za.net>
29682 Sent: Monday, October 06, 2003 10:44 AM
29683 Subject: Re: [IRCServices Coding] Bug....
29687 > >ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
29688 > >18:41:36 BRT 2003
29691 > >Its the last version.......
29693 > Then send a full debug log (from startup to crash), or I can't help.
29696 > achurch@achurch.org
29697 > http://achurch.org/
29698 > ------------------------------------------------------------------
29699 > To unsubscribe or change your subscription options, visit:
29700 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
29704 From achurch at achurch.org Mon Oct 6 19:32:07 2003
29705 From: achurch at achurch.org (Andrew Church)
29706 Date: Sat Oct 23 23:10:02 2004
29707 Subject: [IRCServices Coding] Bug....
29708 In-Reply-To: <010601c38c68$2e6dc8a0$3cc8a8c0@angel>
29709 Message-ID: <3f822598.26100@achurch.org>
29711 >And how should be this log? i sent a backtrace......
29716 achurch@achurch.org
29717 http://achurch.org/
29719 From diego at redesul.net Mon Oct 6 22:36:40 2003
29720 From: diego at redesul.net (Diego B. Contezini)
29721 Date: Sat Oct 23 23:10:02 2004
29722 Subject: [IRCServices Coding] Bug....
29723 References: <3f822598.26100@achurch.org>
29724 Message-ID: <011601c38c94$ebc3ec00$3cc8a8c0@angel>
29727 If i start it with -debug it will get me gb's of information. This occur
29728 after days with services up, i will try to run it into a screen.... with
29733 ----- Original Message -----
29734 From: "Andrew Church" <achurch@achurch.org>
29735 To: <ircservices-coding@ircservices.za.net>
29736 Sent: Monday, October 06, 2003 11:31 PM
29737 Subject: Re: [IRCServices Coding] Bug....
29740 > >And how should be this log? i sent a backtrace......
29745 > achurch@achurch.org
29746 > http://achurch.org/
29747 > ------------------------------------------------------------------
29748 > To unsubscribe or change your subscription options, visit:
29749 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
29753 From saturn at jetirc.net Fri Oct 10 15:48:47 2003
29754 From: saturn at jetirc.net (Saturn)
29755 Date: Sat Oct 23 23:10:02 2004
29756 Subject: [IRCServices Coding] Akill problem in 5.0.22
29757 References: <14C7EDD0-DC1B-11D7-8505-0003938D6866@mac.com>
29758 Message-ID: <004001c38f80$9f635960$6401a8c0@turby>
29760 Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
29761 duplicate exit system notice that happens in 3.1.6).
29763 I just today added an akill (+0 time) .. I DO have the immediate auto kill
29764 option un-commented in the modules.conf, but it still didn't bother scanning
29765 for victims matching my akill mask nor did it actually KILL anyone... It
29766 works if they are manually killed and then try to re-connect, but I thought
29767 that new option was so Services will immediately scan for and kill anyone
29768 online that matches the mask as soon as the new akill is added...
29770 First: IS that what it's supposed to do?
29772 Second: If so, it's not working...
29778 From laser at musichat.net Sat Oct 11 00:56:04 2003
29779 From: laser at musichat.net (Alessandro Ciappei)
29780 Date: Sat Oct 23 23:10:02 2004
29781 Subject: [IRCServices Coding] Problem with auth mail
29782 In-Reply-To: <20031007101106.2701D1703F@snow.fingers.co.za>
29783 Message-ID: <GMEFIDBHIMPENBMIJNFEEEGDCAAA.laser@musichat.net>
29786 Hi all, I've ircservices 5.0.22, and I would like to costumize auth-mail.
29787 I would like describe my irc network in this mail, but when someone register
29788 nick, services go in segfault.
29790 I copy the sintaz of mail-auth ( it's in italian )
29792 # Mail text. The last "%s" (before the user@host) in the body text is
29793 # replaced by one of the NICK_AUTH_MAIL_TEXT_* messages.
29794 NICK_AUTH_MAIL_SUBJECT
29795 Conferma della registrazione del nick %s
29796 NICK_AUTH_MAIL_BODY
29797 Grazie per aver scelto MusiChat Net Community!
29798 Il codice di autorizzazione del tuo nick (%s) e': %09d
29799 Identificati su MusiChat digitando:
29802 La registrazione del tuo nick sara' confermata e il tuo nickname
29803 sara' protetto da eventuali tentativi di abuso o furto.
29805 Il sito ufficiale della rete e' http://www.musichat.net/
29806 I regolamenti della rete e i documenti ufficiali sono
29807 disponibili all'interno del sito.
29809 Per ricevere assistenza sui servizi della rete
29810 in generale puoi rivolgerti sul canale ufficiale #IRCHelp
29811 oppure tramite email all'indirizzo irchelp@musichat.net.
29814 Sono inoltre disponibili i seguenti servizi:
29817 Forum di discussione di MusiChat, raggiungibile
29818 all'indirizzo http://forum.musichat.net
29819 Sul forum, oltre a poter esprimere la tua opinione,
29820 potrai informarti sulle novita' e sui nuovi servizi
29821 offerti dalla rete.
29823 - MusiChat Mailing List
29824 Per iscriversi e' sufficiente visitare il sito
29825 http://lists.musichat.net/mailman/listinfo/irchelp
29826 e inserire il proprio indirizzo E-Mail e la
29827 password desiderata.
29830 Per una connessione piu' veloce e sicura e' vivamente
29831 consigliato l'utilizzo del seguente server: irc.musichat.net
29833 MusiChat Net Community
29835 Questo messaggio e stato inviato su richiesta di %s in risposta a %s
29841 I read the istruction for translate.
29845 [Oct 11 09:48:30 2003] PANIC! buffer = :alpha_omega ! nickserv :register
29846 pippo laser@musichat.net
29847 [Oct 11 09:48:30 2003] Services terminating: Segmentation fault
29850 Some one can help me?
29851 the email body is too long?
29859 From achurch at achurch.org Thu Oct 16 23:58:34 2003
29860 From: achurch at achurch.org (Andrew Church)
29861 Date: Sat Oct 23 23:10:02 2004
29862 Subject: [IRCServices Coding] Problem with auth mail
29863 In-Reply-To: <GMEFIDBHIMPENBMIJNFEEEGDCAAA.laser@musichat.net>
29864 Message-ID: <3f8f9304.20227@achurch.org>
29866 You have the wrong number of %-tokens in your message.
29869 achurch@achurch.org
29870 http://achurch.org/
29873 >Hi all, I've ircservices 5.0.22, and I would like to costumize auth-mail.
29874 >I would like describe my irc network in this mail, but when someone register
29875 >nick, services go in segfault.
29877 >I copy the sintaz of mail-auth ( it's in italian )
29879 ># Mail text. The last "%s" (before the user@host) in the body text is
29880 ># replaced by one of the NICK_AUTH_MAIL_TEXT_* messages.
29881 >NICK_AUTH_MAIL_SUBJECT
29882 > Conferma della registrazione del nick %s
29883 >NICK_AUTH_MAIL_BODY
29884 > Grazie per aver scelto MusiChat Net Community!
29885 > Il codice di autorizzazione del tuo nick (%s) e': %09d
29886 > Identificati su MusiChat digitando:
29887 > /msg %s AUTH %09d
29889 > La registrazione del tuo nick sara' confermata e il tuo nickname
29890 > sara' protetto da eventuali tentativi di abuso o furto.
29892 > Il sito ufficiale della rete e' http://www.musichat.net/
29893 > I regolamenti della rete e i documenti ufficiali sono
29894 > disponibili all'interno del sito.
29896 > Per ricevere assistenza sui servizi della rete
29897 > in generale puoi rivolgerti sul canale ufficiale #IRCHelp
29898 > oppure tramite email all'indirizzo irchelp@musichat.net.
29901 > Sono inoltre disponibili i seguenti servizi:
29904 > Forum di discussione di MusiChat, raggiungibile
29905 > all'indirizzo http://forum.musichat.net
29906 > Sul forum, oltre a poter esprimere la tua opinione,
29907 > potrai informarti sulle novita' e sui nuovi servizi
29908 > offerti dalla rete.
29910 > - MusiChat Mailing List
29911 > Per iscriversi e' sufficiente visitare il sito
29912 > http://lists.musichat.net/mailman/listinfo/irchelp
29913 > e inserire il proprio indirizzo E-Mail e la
29914 > password desiderata.
29917 > Per una connessione piu' veloce e sicura e' vivamente
29918 > consigliato l'utilizzo del seguente server: irc.musichat.net
29920 > MusiChat Net Community
29922 > Questo messaggio e stato inviato su richiesta di %s in risposta a %s
29928 >I read the istruction for translate.
29932 >[Oct 11 09:48:30 2003] PANIC! buffer = :alpha_omega ! nickserv :register
29933 >pippo laser@musichat.net
29934 >[Oct 11 09:48:30 2003] Services terminating: Segmentation fault
29937 >Some one can help me?
29938 >the email body is too long?
29945 >------------------------------------------------------------------
29946 >To unsubscribe or change your subscription options, visit:
29947 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
29949 From saman at alkol.org Fri Oct 17 03:07:31 2003
29950 From: saman at alkol.org (|SaMaN|)
29951 Date: Sat Oct 23 23:10:02 2004
29952 Subject: [IRCServices Coding] Bug or misunderstood ?
29953 Message-ID: <000901c39496$71764f10$a37faec3@coder>
29955 Im using unreal ircd. When channel is empty and if channel owner joins
29956 his/her registered channel it does
29957 (ChanServ sets mode: +ntrq nick) but when channel is not empty and if
29958 channel owner joins his/her registered channel it does (ChanServ sets mode:
29959 +oq nick nick). As you see on the first one there is no +o and because of
29960 this chanserv does not update the last_used time because chanserv is set to
29961 update last_used time with +o (CUMODE_o) so channels drop while channel
29962 owners use them. Is this a bug or my misunderstood ?
29964 ######################################################
29965 modules/chanserv/check.c
29967 void check_chan_user_modes(const char *source, struct c_userlist *u,
29968 Channel *c, int32 oldmodes)
29970 if ((res & ~modes) & CUMODE_o) {
29971 ci->last_used = time(NULL);
29972 put_channelinfo(ci);
29975 ######################################################
29981 From saman at alkol.org Fri Oct 17 04:53:04 2003
29982 From: saman at alkol.org (|SaMaN|)
29983 Date: Sat Oct 23 23:10:02 2004
29984 Subject: [IRCServices Coding] Re: Bug or misunderstood ?
29985 Message-ID: <002001c394a5$31c059b0$a37faec3@coder>
29987 Also it does not update last_used time on +a flag.
29992 edit /modules/chanserv/check.c
29995 -------------------------------------------------------------------------
29996 local_set_cumodes(c, '+', res & ~modes, user->nick);
29997 -------------------------------------------------------------------------
29999 ------------------------------------------------------------------------
30000 int16 cumode_q = mode_char_to_flag('q',MODE_CHANUSER);
30001 int16 cumode_a = mode_char_to_flag('a',MODE_CHANUSER);
30003 if ((res & ~modes) & cumode_q) {
30004 ci->last_used = time(NULL);
30005 put_channelinfo(ci);
30008 if ((res & ~modes) & cumode_a) {
30009 ci->last_used = time(NULL);
30010 put_channelinfo(ci);
30012 -------------------------------------------------------------------------
30013 save and compile and run and enjoy :)
30014 -------------------------------------------------------------------------
30018 ----- Original Message -----
30019 From: "|SaMaN|" <saman@alkol.org>
30020 To: <IRCServices-Coding@ircservices.za.net>
30021 Sent: Friday, October 17, 2003 1:07 PM
30022 Subject: Bug or misunderstood ?
30025 > Im using unreal ircd. When channel is empty and if channel owner joins
30026 > his/her registered channel it does
30027 > (ChanServ sets mode: +ntrq nick) but when channel is not empty and if
30028 > channel owner joins his/her registered channel it does (ChanServ sets
30030 > +oq nick nick). As you see on the first one there is no +o and because of
30031 > this chanserv does not update the last_used time because chanserv is set
30033 > update last_used time with +o (CUMODE_o) so channels drop while channel
30034 > owners use them. Is this a bug or my misunderstood ?
30036 > ######################################################
30037 > modules/chanserv/check.c
30039 > void check_chan_user_modes(const char *source, struct c_userlist *u,
30040 > Channel *c, int32 oldmodes)
30042 > if ((res & ~modes) & CUMODE_o) {
30043 > ci->last_used = time(NULL);
30044 > put_channelinfo(ci);
30047 > ######################################################
30054 From saturn at jetirc.net Fri Oct 17 08:47:59 2003
30055 From: saturn at jetirc.net (Saturn)
30056 Date: Sat Oct 23 23:10:02 2004
30057 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
30058 Message-ID: <002501c394c5$f8dce480$6401a8c0@turby>
30060 Haven't seen a reply to this one, so thought I'd better make sure this went
30063 ----- Original Message -----
30064 Sent: Friday, October 10, 2003 3:48 PM
30065 Subject: Akill problem in 5.0.22
30068 Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
30069 duplicate exit system notice that happens in 3.1.6).
30071 I just today added an akill (+0 time) .. I DO have the immediate auto kill
30072 option un-commented in the modules.conf, but it still didn't bother scanning
30073 for victims matching my akill mask nor did it actually KILL anyone... It
30074 works if they are manually killed and then try to re-connect, but I thought
30075 that new option was so Services will immediately scan for and kill anyone
30076 online that matches the mask as soon as the new akill is added...
30078 First: IS that what it's supposed to do?
30080 Second: If so, it's not working...
30086 From achurch at achurch.org Fri Oct 17 09:03:19 2003
30087 From: achurch at achurch.org (Andrew Church)
30088 Date: Sat Oct 23 23:10:02 2004
30089 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
30090 In-Reply-To: <002501c394c5$f8dce480$6401a8c0@turby>
30091 Message-ID: <3f9012b8.23176@achurch.org>
30096 achurch@achurch.org
30097 http://achurch.org/
30099 >Haven't seen a reply to this one, so thought I'd better make sure this went
30102 >----- Original Message -----
30103 >Sent: Friday, October 10, 2003 3:48 PM
30104 >Subject: Akill problem in 5.0.22
30107 >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
30108 >duplicate exit system notice that happens in 3.1.6).
30110 >I just today added an akill (+0 time) .. I DO have the immediate auto kill
30111 >option un-commented in the modules.conf, but it still didn't bother scanning
30112 >for victims matching my akill mask nor did it actually KILL anyone... It
30113 >works if they are manually killed and then try to re-connect, but I thought
30114 >that new option was so Services will immediately scan for and kill anyone
30115 >online that matches the mask as soon as the new akill is added...
30117 >First: IS that what it's supposed to do?
30119 >Second: If so, it's not working...
30124 >------------------------------------------------------------------
30125 >To unsubscribe or change your subscription options, visit:
30126 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
30128 From saturn at jetirc.net Fri Oct 17 09:19:32 2003
30129 From: saturn at jetirc.net (Saturn)
30130 Date: Sat Oct 23 23:10:02 2004
30131 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
30132 References: <3f9012b8.23176@achurch.org>
30133 Message-ID: <027401c394ca$443ae180$6401a8c0@turby>
30135 Well, Andrew, I did read TFM. For what it's worth, all I found was this
30136 entry under the description of the module options
30138 ImmediatelySendAutokill [OPTIONAL]
30139 Causes OperServ to inform all servers of a new autokill or autokill
30140 exclusion the moment it is added, rather than waiting for someone to match
30142 Example: ImmediatelySendAutokill
30144 I read through the section about AKILLs and SQline, SGline, SZline, etc,
30145 however all of what I read indicates that simply enabling the
30146 ImmediatelySendAutokill option in the modules.conf (coupled with the fact
30147 that everything ELSE is set up and workign properly) SHOULD cause services
30148 to immediately scan the network for clients matching the akill mask, and
30151 My point, sir, is that IT DOES NOT DO THIS. Thus, I'm sure you'll find, I
30152 HAVE in fact read the f___ manual, and the manual does not address this
30153 problem. If it doesn't matter to you, fine, but if it does, let's try and
30154 get on with maybe solving the problem?
30159 ----- Original Message -----
30160 From: "Andrew Church" <achurch@achurch.org>
30161 To: <ircservices-coding@ircservices.za.net>
30162 Sent: Friday, October 17, 2003 9:02 AM
30163 Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
30169 achurch@achurch.org
30170 http://achurch.org/
30172 >Haven't seen a reply to this one, so thought I'd better make sure this went
30175 >----- Original Message -----
30176 >Sent: Friday, October 10, 2003 3:48 PM
30177 >Subject: Akill problem in 5.0.22
30180 >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
30181 >duplicate exit system notice that happens in 3.1.6).
30183 >I just today added an akill (+0 time) .. I DO have the immediate auto kill
30184 >option un-commented in the modules.conf, but it still didn't bother
30186 >for victims matching my akill mask nor did it actually KILL anyone... It
30187 >works if they are manually killed and then try to re-connect, but I thought
30188 >that new option was so Services will immediately scan for and kill anyone
30189 >online that matches the mask as soon as the new akill is added...
30191 >First: IS that what it's supposed to do?
30193 >Second: If so, it's not working...
30198 >------------------------------------------------------------------
30199 >To unsubscribe or change your subscription options, visit:
30200 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
30201 ------------------------------------------------------------------
30202 To unsubscribe or change your subscription options, visit:
30203 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
30206 From achurch at achurch.org Fri Oct 17 09:34:48 2003
30207 From: achurch at achurch.org (Andrew Church)
30208 Date: Sat Oct 23 23:10:02 2004
30209 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
30210 In-Reply-To: <027401c394ca$443ae180$6401a8c0@turby>
30211 Message-ID: <3f901a20.23266@achurch.org>
30213 >however all of what I read indicates that simply enabling the
30214 >ImmediatelySendAutokill option in the modules.conf (coupled with the fact
30215 >that everything ELSE is set up and workign properly) SHOULD cause services
30216 >to immediately scan the network for clients matching the akill mask, and
30219 The documentation says nothing about this. RTFM again.
30222 achurch@achurch.org
30223 http://achurch.org/
30225 From ballsy at mystical.net Fri Oct 17 11:20:33 2003
30226 From: ballsy at mystical.net (Ballsy)
30227 Date: Sat Oct 23 23:10:02 2004
30228 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
30229 In-Reply-To: <027401c394ca$443ae180$6401a8c0@turby>
30230 References: <3f9012b8.23176@achurch.org> <027401c394ca$443ae180$6401a8c0@turby>
30231 Message-ID: <6.0.0.22.0.20031017121557.01b63ac0@127.0.0.1>
30233 To save the rest of us from having to put up with more bickering,
30234 it may be of note that I had to comment out 'EnableExclude' in order for my
30235 immediate-kill functionality to work under bahamut (I know, you're using
30236 Unreal). All the ImmediatelySendAkill does is informs all linked services
30237 that they should add an Akill. It's then up to those servers to decide how
30243 At 10:18 AM 17/10/2003, Saturn wrote:
30244 >Well, Andrew, I did read TFM. For what it's worth, all I found was this
30245 >entry under the description of the module options
30247 >ImmediatelySendAutokill [OPTIONAL]
30248 > Causes OperServ to inform all servers of a new autokill or autokill
30249 >exclusion the moment it is added, rather than waiting for someone to match
30251 > Example: ImmediatelySendAutokill
30253 >I read through the section about AKILLs and SQline, SGline, SZline, etc,
30254 >however all of what I read indicates that simply enabling the
30255 >ImmediatelySendAutokill option in the modules.conf (coupled with the fact
30256 >that everything ELSE is set up and workign properly) SHOULD cause services
30257 >to immediately scan the network for clients matching the akill mask, and
30260 >My point, sir, is that IT DOES NOT DO THIS. Thus, I'm sure you'll find, I
30261 >HAVE in fact read the f___ manual, and the manual does not address this
30262 >problem. If it doesn't matter to you, fine, but if it does, let's try and
30263 >get on with maybe solving the problem?
30268 >----- Original Message -----
30269 >From: "Andrew Church" <achurch@achurch.org>
30270 >To: <ircservices-coding@ircservices.za.net>
30271 >Sent: Friday, October 17, 2003 9:02 AM
30272 >Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
30278 > achurch@achurch.org
30279 > http://achurch.org/
30281 > >Haven't seen a reply to this one, so thought I'd better make sure this went
30284 > >----- Original Message -----
30285 > >Sent: Friday, October 10, 2003 3:48 PM
30286 > >Subject: Akill problem in 5.0.22
30289 > >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
30290 > >duplicate exit system notice that happens in 3.1.6).
30292 > >I just today added an akill (+0 time) .. I DO have the immediate auto kill
30293 > >option un-commented in the modules.conf, but it still didn't bother
30295 > >for victims matching my akill mask nor did it actually KILL anyone... It
30296 > >works if they are manually killed and then try to re-connect, but I thought
30297 > >that new option was so Services will immediately scan for and kill anyone
30298 > >online that matches the mask as soon as the new akill is added...
30300 > >First: IS that what it's supposed to do?
30302 > >Second: If so, it's not working...
30307 > >------------------------------------------------------------------
30308 > >To unsubscribe or change your subscription options, visit:
30309 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
30310 >------------------------------------------------------------------
30311 >To unsubscribe or change your subscription options, visit:
30312 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
30314 >------------------------------------------------------------------
30315 >To unsubscribe or change your subscription options, visit:
30316 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
30320 From saturn at jetirc.net Fri Oct 17 17:16:26 2003
30321 From: saturn at jetirc.net (Saturn)
30322 Date: Sat Oct 23 23:10:02 2004
30323 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
30324 References: <3f901a20.23266@achurch.org>
30325 Message-ID: <02d401c3950c$e762bda0$6401a8c0@turby>
30327 >From a.html in the /docs directory:
30329 operserv/akill (Autokill module settings)
30330 ImmediatelySendAutokill [OPTIONAL]
30331 Causes OperServ to inform all servers of a new autokill or autokill
30332 exclusion the moment it is added, rather than waiting for someone to match
30334 Example: ImmediatelySendAutokill
30337 3.html#4-3 in the /docs directory does not speak to the
30338 ImmediatelySendAutokill option except for the mention that:
30339 "(If the ImmediatelySendAutokill option in modules.conf is enabled, the
30340 last-used time will never be set at all on these servers.)"
30341 However, this is in the context of talking about Slines, etc, and as far as
30342 I can tell has no new useful information to impart regarding my stated
30343 problem: that services is NOT "Immediately sending the autokill" on my
30344 network and thus when a new AKILL is added, the matching users/masks are not
30345 being killed off, unless they are killed manually by an IRCop. Yes, it IS
30346 catching them when they attempt to re-connect, that was never a problem. It
30347 would make sense that if an autokill is added, that Services would
30348 immediately trace the network and kill off any matches to that akill... at
30349 least, it makes sense if this option is enabled.... (to me)
30350 ------------------------
30352 4.html#oper.akill doesn't mention it at all.
30356 I really don't see where else I'm supposed to be looking here. I've scoured
30357 the docs and can see no other reference to it. If there's something I'm
30358 missing, perhaps instead of rudely, repeatedly telling me to RTFM, maybe
30359 just tell me what it is I'm supposed to find! I've already spend a few
30360 hours reading through the docs (which I've already read about a dozen times
30361 over the past year alone), and I'm telling you, there's nothing else about
30362 it that I can find!!!
30364 The ONLY thing I can come up with is that the feature name is misleading and
30365 the option doesn't in fact do what it SEEMS it should do. Could it be that
30366 all that does is send the S/G/Z line (whatever is appropriate) to the
30367 servers and that's all??? NOW I have to ask, why bother, if it'll do that
30368 if/when they re-connect anyhow?
30370 Additionally, if the reason I can't find the answer in the manual is because
30371 the option DOESN'T make services kill all matches when the akill is added,
30372 then Imust ask WHY that isn't an option, since it seems logically useful to
30373 me and my staff. Also, that being the case, why couldn't you simply SAY
30374 that it's not designed to do that, instead of sending me hunting (TWICE) for
30375 non-existant information in the docs???????
30377 I'm very interested to hear the answer to these questions. To put it
30378 bluntly, I have been an extremely enthusiastic advocate of IRCServices for
30379 over 3 years now, have turned many network owners onto them, and love them
30380 to death. The way you "talk" to your supporters on this forum sometimes
30381 leaves a LOT to be desired. If the feature doesn't exist as I understand
30382 it, just SAY SO and save us all a lot of trouble -- don't just tell me to go
30383 RTFM when the info I seek isn't IN it. Having said that, if you can point
30384 me to the info in the docs in the 5.0.22 distro and prove my claims as
30385 baseless, I will offer my sincere apologies. Until then, my opinion stands.
30389 ----- Original Message -----
30390 From: "Andrew Church" <achurch@achurch.org>
30391 To: <ircservices-coding@ircservices.za.net>
30392 Sent: Friday, October 17, 2003 9:34 AM
30393 Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
30396 >however all of what I read indicates that simply enabling the
30397 >ImmediatelySendAutokill option in the modules.conf (coupled with the fact
30398 >that everything ELSE is set up and workign properly) SHOULD cause services
30399 >to immediately scan the network for clients matching the akill mask, and
30402 The documentation says nothing about this. RTFM again.
30405 achurch@achurch.org
30406 http://achurch.org/
30407 ------------------------------------------------------------------
30408 To unsubscribe or change your subscription options, visit:
30409 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
30412 From saturn at jetirc.net Fri Oct 17 17:33:57 2003
30413 From: saturn at jetirc.net (Saturn)
30414 Date: Sat Oct 23 23:10:02 2004
30415 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
30416 References: <3f9012b8.23176@achurch.org> <027401c394ca$443ae180$6401a8c0@turby>
30417 <6.0.0.22.0.20031017121557.01b63ac0@127.0.0.1>
30418 Message-ID: <030801c3950f$3cb55270$6401a8c0@turby>
30420 Would have been nice if someone had mentioned that (about the
30421 ImmediatelySendAutokill) from the start. I would say the flag is misleading
30422 in title then, because I (and 8 other people on my staff -- none of us are
30423 dummies, either) read that as meaning it will Immediately send the auto
30424 kill... "ImmediatelyUpdateServers" might be more fitting from an intuitive
30425 standpoint, not that I'm suggesting changing the name, but at least the
30426 documentation of it could be a bit more explicit IMHO.
30428 and yes, I know there will be about 50 people (probably all of them
30429 hard-core coders) shaking their heads in disbelief at what I've said, but
30430 let's face it: If we were ALL hard-core coders, we wouldn't need Andrew and
30431 his IRCServices, would we? We'd all be making our own. So all I'm saying
30432 is how about a little slack for those of us with OTHER important skills that
30433 might fall outside the scope of being the "world's greatest expert" on IRC
30436 ----- Original Message -----
30437 From: "Ballsy" <ballsy@mystical.net>
30438 To: "IRC Services Coding Mailing List"
30439 <ircservices-coding@ircservices.za.net>; "IRC Services Coding Mailing List"
30440 <ircservices-coding@ircservices.za.net>
30441 Sent: Friday, October 17, 2003 11:20 AM
30442 Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
30445 To save the rest of us from having to put up with more bickering,
30446 it may be of note that I had to comment out 'EnableExclude' in order for my
30447 immediate-kill functionality to work under bahamut (I know, you're using
30448 Unreal). All the ImmediatelySendAkill does is informs all linked services
30449 that they should add an Akill. It's then up to those servers to decide how
30455 At 10:18 AM 17/10/2003, Saturn wrote:
30456 >Well, Andrew, I did read TFM. For what it's worth, all I found was this
30457 >entry under the description of the module options
30459 >ImmediatelySendAutokill [OPTIONAL]
30460 > Causes OperServ to inform all servers of a new autokill or autokill
30461 >exclusion the moment it is added, rather than waiting for someone to match
30463 > Example: ImmediatelySendAutokill
30465 >I read through the section about AKILLs and SQline, SGline, SZline, etc,
30466 >however all of what I read indicates that simply enabling the
30467 >ImmediatelySendAutokill option in the modules.conf (coupled with the fact
30468 >that everything ELSE is set up and workign properly) SHOULD cause services
30469 >to immediately scan the network for clients matching the akill mask, and
30472 >My point, sir, is that IT DOES NOT DO THIS. Thus, I'm sure you'll find, I
30473 >HAVE in fact read the f___ manual, and the manual does not address this
30474 >problem. If it doesn't matter to you, fine, but if it does, let's try and
30475 >get on with maybe solving the problem?
30480 >----- Original Message -----
30481 >From: "Andrew Church" <achurch@achurch.org>
30482 >To: <ircservices-coding@ircservices.za.net>
30483 >Sent: Friday, October 17, 2003 9:02 AM
30484 >Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
30490 > achurch@achurch.org
30491 > http://achurch.org/
30493 > >Haven't seen a reply to this one, so thought I'd better make sure this
30497 > >----- Original Message -----
30498 > >Sent: Friday, October 10, 2003 3:48 PM
30499 > >Subject: Akill problem in 5.0.22
30502 > >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
30503 > >duplicate exit system notice that happens in 3.1.6).
30505 > >I just today added an akill (+0 time) .. I DO have the immediate auto
30507 > >option un-commented in the modules.conf, but it still didn't bother
30509 > >for victims matching my akill mask nor did it actually KILL anyone... It
30510 > >works if they are manually killed and then try to re-connect, but I
30512 > >that new option was so Services will immediately scan for and kill anyone
30513 > >online that matches the mask as soon as the new akill is added...
30515 > >First: IS that what it's supposed to do?
30517 > >Second: If so, it's not working...
30522 > >------------------------------------------------------------------
30523 > >To unsubscribe or change your subscription options, visit:
30524 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
30525 >------------------------------------------------------------------
30526 >To unsubscribe or change your subscription options, visit:
30527 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
30529 >------------------------------------------------------------------
30530 >To unsubscribe or change your subscription options, visit:
30531 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
30534 ------------------------------------------------------------------
30535 To unsubscribe or change your subscription options, visit:
30536 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
30539 From Craig at chatspike.net Fri Oct 17 19:07:33 2003
30540 From: Craig at chatspike.net (Craig McLure)
30541 Date: Sat Oct 23 23:10:02 2004
30542 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
30543 Message-ID: <E1AAgV1-0008ae-00@ptb-mailc04.plus.net>
30545 Theres no need for flaming ffs.. just because something makes less sence to you than to everyone else, doesnt instantly mean that it has to be changed.. i seemed to understand it ok, and i'm sure that there are several hundred other IRCServices users who didnt have any problems with this directive.
30547 I'm sure andy will concider documenting it more "accuratly" (I wont speak for him thou, his choice :p), but theres no need for the flaming, if you have such a big problem with something that (apparently just) you dont understand, just make a passing mention on it, dont go on talking about "Hard-core coders" and "worlds biggest expert"s cause you are upset with something. If the last paragraph wasnt made, i'm sure there _WOUDLNT_ be "about 50 people (probably all of them hard-core coders) shaking their heads in disbelief", cause it doesnt happen. And to clarify.. theres no such thing as a "world biggest expert" when it comes to IRC programming, people have different preferances, and ways of doing things, to the point that you cant compair something like InspIRCd to UnrealIRCd, as they are totally different in almost every way. :p
30549 Please just calm down, and talk this out rationally before you start jumping down ppls throats :p
30551 /*****************************************
30552 * Craig "FrostyCoolSlug" McLure
30553 * InspIRCd - http://www.inspircd.org
30554 * ChatSpike - http://www.chatspike.net
30555 ****************************************/
30558 /****************************************
30559 * From - Saturn <saturn@jetirc.net>
30560 * To - IRC Services Coding Mailing List <ircservices-coding@ircservices.za.net>
30561 * Sent - 2003-10-17 17:31:00
30562 * Subject - Re: [IRCServices Coding] Re: Akill problem in 5.0.22
30563 ****************************************/
30565 /****** - Begin Original Message - ******/
30567 >Would have been nice if someone had mentioned that (about the
30568 >ImmediatelySendAutokill) from the start. I would say the flag is misleading
30569 >in title then, because I (and 8 other people on my staff -- none of us are
30570 >dummies, either) read that as meaning it will Immediately send the auto
30571 >kill... "ImmediatelyUpdateServers" might be more fitting from an intuitive
30572 >standpoint, not that I'm suggesting changing the name, but at least the
30573 >documentation of it could be a bit more explicit IMHO.
30575 >and yes, I know there will be about 50 people (probably all of them
30576 >hard-core coders) shaking their heads in disbelief at what I've said, but
30577 >let's face it: If we were ALL hard-core coders, we wouldn't need Andrew and
30578 >his IRCServices, would we? We'd all be making our own. So all I'm saying
30579 >is how about a little slack for those of us with OTHER important skills that
30580 >might fall outside the scope of being the "world's greatest expert" on IRC
30583 >----- Original Message -----
30584 >From: "Ballsy" <ballsy@mystical.net>
30585 >To: "IRC Services Coding Mailing List"
30586 ><ircservices-coding@ircservices.za.net>; "IRC Services Coding Mailing List"
30587 ><ircservices-coding@ircservices.za.net>
30588 >Sent: Friday, October 17, 2003 11:20 AM
30589 >Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
30592 > To save the rest of us from having to put up with more bickering,
30593 >it may be of note that I had to comment out 'EnableExclude' in order for my
30594 >immediate-kill functionality to work under bahamut (I know, you're using
30595 >Unreal). All the ImmediatelySendAkill does is informs all linked services
30596 >that they should add an Akill. It's then up to those servers to decide how
30602 >At 10:18 AM 17/10/2003, Saturn wrote:
30603 >>Well, Andrew, I did read TFM. For what it's worth, all I found was this
30604 >>entry under the description of the module options
30606 >>ImmediatelySendAutokill [OPTIONAL]
30607 >> Causes OperServ to inform all servers of a new autokill or autokill
30608 >>exclusion the moment it is added, rather than waiting for someone to match
30610 >> Example: ImmediatelySendAutokill
30612 >>I read through the section about AKILLs and SQline, SGline, SZline, etc,
30613 >>however all of what I read indicates that simply enabling the
30614 >>ImmediatelySendAutokill option in the modules.conf (coupled with the fact
30615 >>that everything ELSE is set up and workign properly) SHOULD cause services
30616 >>to immediately scan the network for clients matching the akill mask, and
30619 >>My point, sir, is that IT DOES NOT DO THIS. Thus, I'm sure you'll find, I
30620 >>HAVE in fact read the f___ manual, and the manual does not address this
30621 >>problem. If it doesn't matter to you, fine, but if it does, let's try and
30622 >>get on with maybe solving the problem?
30627 >>----- Original Message -----
30628 >>From: "Andrew Church" <achurch@achurch.org>
30629 >>To: <ircservices-coding@ircservices.za.net>
30630 >>Sent: Friday, October 17, 2003 9:02 AM
30631 >>Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
30637 >> achurch@achurch.org
30638 >> http://achurch.org/
30640 >> >Haven't seen a reply to this one, so thought I'd better make sure this
30644 >> >----- Original Message -----
30645 >> >Sent: Friday, October 10, 2003 3:48 PM
30646 >> >Subject: Akill problem in 5.0.22
30649 >> >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
30650 >> >duplicate exit system notice that happens in 3.1.6).
30652 >> >I just today added an akill (+0 time) .. I DO have the immediate auto
30654 >> >option un-commented in the modules.conf, but it still didn't bother
30656 >> >for victims matching my akill mask nor did it actually KILL anyone... It
30657 >> >works if they are manually killed and then try to re-connect, but I
30659 >> >that new option was so Services will immediately scan for and kill anyone
30660 >> >online that matches the mask as soon as the new akill is added...
30662 >> >First: IS that what it's supposed to do?
30664 >> >Second: If so, it's not working...
30669 >> >------------------------------------------------------------------
30670 >> >To unsubscribe or change your subscription options, visit:
30671 >> >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
30672 >>------------------------------------------------------------------
30673 >>To unsubscribe or change your subscription options, visit:
30674 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
30676 >>------------------------------------------------------------------
30677 >>To unsubscribe or change your subscription options, visit:
30678 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
30681 >------------------------------------------------------------------
30682 >To unsubscribe or change your subscription options, visit:
30683 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
30685 >------------------------------------------------------------------
30686 >To unsubscribe or change your subscription options, visit:
30687 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
30691 /******* - End Original Message - *******/
30696 From achurch at achurch.org Fri Oct 17 20:13:46 2003
30697 From: achurch at achurch.org (Andrew Church)
30698 Date: Sat Oct 23 23:10:02 2004
30699 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
30700 In-Reply-To: <02d401c3950c$e762bda0$6401a8c0@turby>
30701 Message-ID: <3f90afdf.23477@achurch.org>
30703 You know, I might have been more forgiving if this hadn't been gone
30704 over on this list (twice!) before:
30706 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/002305.html
30707 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/003215.html
30709 However, since you seem to have trouble both comprehending the
30710 documentation and reading the archives, I have added FAQ F.10 for your
30713 F.10. Services doesn't kill users matching a newly-added autokill mask even
30714 if ImmediatelySendAutokill is set.
30716 Services never kills users when a new autokill is added; the
30717 ImmediatelySendAutokill configuration directive only causes
30718 Services to send the autokill itself (that is, the user/host mask
30719 to prohibit new connections from) to the IRC servers on your
30720 network. This is a safety feature intended to limit the damage
30721 caused by a mistyped autokill.
30723 Note that some IRC servers will themselves kill users matching a
30724 newly-added autokill; this is unrelated to Services.
30727 achurch@achurch.org
30728 http://achurch.org/
30730 From griever at t2n.org Fri Oct 17 21:23:14 2003
30731 From: griever at t2n.org (Robert F Merrill)
30732 Date: Sat Oct 23 23:10:02 2004
30733 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
30734 In-Reply-To: <030801c3950f$3cb55270$6401a8c0@turby>
30735 References: <3f9012b8.23176@achurch.org> <027401c394ca$443ae180$6401a8c0@turby>
30736 <6.0.0.22.0.20031017121557.01b63ac0@127.0.0.1>
30737 <030801c3950f$3cb55270$6401a8c0@turby>
30738 Message-ID: <3F90BF77.2010706@t2n.org>
30742 >Would have been nice if someone had mentioned that (about the
30743 >ImmediatelySendAutokill) from the start. I would say the flag is misleading
30744 >in title then, because I (and 8 other people on my staff -- none of us are
30745 >dummies, either) read that as meaning it will Immediately send the auto
30746 >kill... "ImmediatelyUpdateServers" might be more fitting from an intuitive
30747 >standpoint, not that I'm suggesting changing the name, but at least the
30748 >documentation of it could be a bit more explicit IMHO.
30751 It DOES immediately send the autokill. You just don't grasp the meaning
30752 of sending the autokill.
30753 It literally sends an AKILL (or TKL in the case of unreal) message to
30754 the servers. At least unreal
30755 and bahamut will then scan for matching clients and disconnect them,
30756 however not all servers
30759 If you are using unreal and it doesn't disconnect the matching users,
30760 then it is either a bug in
30761 unreal (not uncommon) or the services really *aren't* sending the tkl
30762 message (doubt it).
30764 Try adding an akill for a connected client. If the client doesn't die,
30765 do a /stats g on their server.
30766 You should see a g-line added for them.
30768 Also note that if you have akill exclusions enabled (bad idea most of
30769 the time), services will NEVER add an akill
30770 or gline on servers that don't support akill or gline exclusions (I
30771 don't know of any that do), but rather
30772 manually kill everyone that matches as they connect. In this case, you
30773 should disable akill exclusions and
30774 it should start working.
30778 From v13 at it.teithe.gr Sat Oct 18 11:47:23 2003
30779 From: v13 at it.teithe.gr (V13)
30780 Date: Sat Oct 23 23:10:02 2004
30781 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
30782 In-Reply-To: <3F90BF77.2010706@t2n.org>
30783 References: <3f9012b8.23176@achurch.org> <030801c3950f$3cb55270$6401a8c0@turby>
30784 <3F90BF77.2010706@t2n.org>
30785 Message-ID: <200310182149.18600.v13@it.teithe.gr>
30787 On Saturday 18 October 2003 07:20, Robert F Merrill wrote:
30789 > >Would have been nice if someone had mentioned that (about the
30790 > >ImmediatelySendAutokill) from the start. I would say the flag is
30791 > > misleading in title then, because I (and 8 other people on my staff --
30792 > > none of us are dummies, either) read that as meaning it will Immediately
30793 > > send the auto kill... "ImmediatelyUpdateServers" might be more fitting
30794 > > from an intuitive standpoint, not that I'm suggesting changing the name,
30795 > > but at least the documentation of it could be a bit more explicit IMHO.
30797 > It DOES immediately send the autokill. You just don't grasp the meaning
30798 > of sending the autokill.
30799 > It literally sends an AKILL (or TKL in the case of unreal) message to
30800 > the servers. At least unreal
30801 > and bahamut will then scan for matching clients and disconnect them,
30802 > however not all servers
30805 FYI bahamut doesn't do this. It will only do it whenever a new client that
30806 matches the akill connects to the server.
30808 i.e. if you set an akill for *.com noone will be disconnected untill a new
30809 client from *.com gets connected (at that moment, all matching clients will
30810 be killed). In the mean time, anyone from other domains can connect to the
30811 server without having any user killed.
30815 From diego at redesul.net Sat Oct 18 12:17:04 2003
30816 From: diego at redesul.net (Diego B. Contezini)
30817 Date: Sat Oct 23 23:10:02 2004
30818 Subject: [IRCServices Coding] CORE DUMPED! BUG!
30819 References: <3f8f9304.20227@achurch.org>
30820 Message-ID: <000e01c395ac$5b773b40$3cc8a8c0@angel>
30822 Andrew, you told me about debugging.. now i got it ;]
30823 here is the debugging:
30824 [Oct 18 16:05:31.288944 2003] debug: Sent: :ChanServ TOPIC #EMOCORE reffer
30825 1066055037 :1i?? Festival HARDcoCOREcore dia 25 de outubro em blumenau no
30826 rio bravo bar (proximo a resima agua verde), com as bandas: Zero Ltda
30827 (curitiba), Swallow the Waffle (bc), chymia(bnu), crazy frogs (lages),
30828 surpise set e slipper (bnu)...3 pila entrada inicio as 15:00 horas'
30829 [Oct 18 16:05:31.289032 2003] debug: Received: :|-Frango-| MODE
30830 #EMOCORE -oooooo CHoPP CbRS-oFF caroll BRYAN brunaH balsanelli
30831 Segmentation fault (core dumped)
30833 root@irc(/home/ircadmin/services/lib)# ls -la core.12631
30834 -rw------- 1 ircadmin ircadmin 47374336 Oct 18 16:05 core.12631
30837 continue on the next message......
30840 From diego at redesul.net Sat Oct 18 12:17:32 2003
30841 From: diego at redesul.net (Diego B. Contezini)
30842 Date: Sat Oct 23 23:10:02 2004
30843 Subject: [IRCServices Coding] CORE DUMPED... continue...
30844 References: <3f8f9304.20227@achurch.org>
30845 Message-ID: <001201c395ac$71b42210$3cc8a8c0@angel>
30847 #0 0x0804d830 in add_mode_with_params (md=0x806aa00, mode=111 'o',
30848 is_add=1, params=1, parambuf=0xbfffe280 "balsanelli",
30849 len=10) at actions.c:568
30850 568 md->params[md->nopmodes][len] = 0;
30852 #0 0x0804d830 in add_mode_with_params (md=0x806aa00, mode=111 'o',
30853 is_add=1, params=1, parambuf=0xbfffe280 "balsanelli",
30854 len=10) at actions.c:568
30856 #1 0x0804d342 in set_cmode (sender=0x81db058 "ChanServ", channel=0xa905d00)
30859 "balsanelli\000\b\025\225\002BWi??\022B\024\032\023Bi??i??i??i??\000\000\000
30860 \000\034 \006\bi??i??i??i??hi??i??i??i??i??i??i??\025\224\004B\034
30861 \006\b\000\000\000\000i??m\tBdi??\022Bi??q\a\b\000\000\000\000eR :\0037[
30862 \0034#\003di??\022B\000\000\000\000i??\037\006\bi??\037\006\bi??i??i??i??$i?
30863 ?\006Bi??i??i??i??\bi??i??i??\000\000\000\000Hi??i??i??\025\224\004B@\002\a\
30864 b8i??i??i??6\020\aBpi??i??i??@i??\006\b@\002\a\b\000\000\000\000i??<\023BLi?
30865 ?i??i??=S\004B\024\032\023B\001\020\000\000@i??\006\bhi??i??i??\204i??\006Bp
30866 i??i??i??i??\037\006\b"...
30871 args = 0xbfffe6d0 "RDcoCOREcorei??i??i??i??o"
30872 modes = 0xbfffeae2 ""
30873 modes_orig = 0xbfffeae0 "+o"
30874 md = (struct modedata *) 0x806aa00
30879 #2 0x400895ff in local_set_cumodes (c=0xa905d00, plusminus=43 '+', modes=1,
30880 nick=0xab7f2e8 "balsanelli") at check.c:432
30882 modestr = "o\000\000 de outubro em blumenau no rio bravo bar
30883 (proximo a resima agua verde), com as bandas: Zero
30884 L\v\000\000\000(curitiba), \000\000\000\000low the Waff\000\000\000\000bc),
30885 chymia(bnu), crazy frogs (lages), surpise set e slipper (bnu).."...
30887 #3 0x40088d74 in check_chan_user_modes (source=0xbfffeed0 "|-Frango-|",
30888 u=0xab34ff0, c=0xa905d00, oldmodes=1)
30890 user = (User *) 0xab7f2d8
30891 ci = (ChannelInfo *) 0xa571940
30895 #4 0x400820ed in do_channel_umode_change (source=0xbfffeed0 "|-Frango-|",
30896 c=0xa905d00, u=0xab34ff0, oldmodes=1)
30899 #5 0x0805890d in call_callback_5 (module=0x806a5c0, id=23, arg1=0xbfffeed0,
30900 arg2=0xa905d00, arg3=0xab34ff0, arg4=0x1,
30901 arg5=0x0) at modules.c:666
30902 cl = (CallbackList *) 0x8077cb8
30905 #6 0x0804edc8 in do_cumode (source=0xbfffeed0 "|-Frango-|", chan=0xa905d00,
30906 flag=1, add=0, nick=0xbfffecc9 "balsanelli")
30907 ---Type <return> to continue, or q <return> to quit---
30909 u = (struct c_userlist *) 0xab34ff0
30910 user = (User *) 0xab7f2d8
30912 #7 0x0804e97e in do_cmode (source=0xbfffeed0 "|-Frango-|", ac=0,
30913 av=0xa853130) at channels.c:302
30916 params = -1073746288
30917 chan = (Channel *) 0xa905d00
30920 modestr = 0xbfffec9e "-oooooo"
30921 #8 0x080557ff in m_mode (source=0xbfffeed0 "|-Frango-|", ac=8,
30922 av=0xa853110) at messages.c:101
30924 #9 0x0805920e in process () at process.c:133
30925 m = (Message *) 0x8067dd8
30927 "|-Frango-|\000\000G\000\000\000Y\e\205\n\t+\205\n\bi??i??i??i??i??\005\b@j\
30928 a\b\000\004\000\000i??\032\205\n\t\000\000\000@j\a\b\216j\a\b(i??i??i??qP\00
30931 "MODE\000\000\000i??8i??i??i??i??\005\b\000\000\000\000i??i??i??i??\000\000\
30932 000\000\000\000\000\000\001H\000\000Pi??i??i??\000Y\a\bVi??\005\b\207j\a\bP\
30933 e\205\n\t\000\000\000i??i??\005\b"
30935 "MODE\000#EMOCORE\000-oooooo\000CHoPP\000CbRS-oFF\000caroll\000BRYAN\000brun
30936 aH\000balsanelli\000 balsanelli\000\000ai\00314ser \0030]\00315=\00314-
30937 S\00315c\0030ri\00315p\00314t \00315\037v\0373.8 \003\000\00315\037v\0373.8
30938 \003\000\000\0003)\000\0006\037\002Pi??Ti??\00313\037\002]\037\002\0036i??i?
30939 ? \000i??Ti??\00313\037\002]\037\002\0036i??i?? \000\000\003\000\000r
30940 \003", '\0' <repeats 11 times>...
30941 s = 0xbfffec95 "#EMOCORE"
30943 av = (char **) 0xa853110
30944 #10 0x0805507d in readline_callback (s=0xa851ae0, param_unused=0x50) at
30947 #11 0x0805b617 in check_sockets () at sockets.c:491
30948 newline = 0xa851b58 "\nrct-sc.br irc.creativenet.com.br 0 3364349034
30949 :aNiNhHa[du]DoNaTeLo\n:Toh_Pensanu PART #ilheus\n:_LoKo_SuL_ SJOIN
30950 1063565447 #elias\n:_MoRgAnA_ PRIVMSG NickServ@services.redesul.net :set
30951 nomemo off\n:irc."...
30954 rfds = {fds_bits = {16, 0 <repeats 31 times>}}
30955 wfds = {fds_bits = {0 <repeats 32 times>}}
30956 tv = {tv_sec = 2, tv_usec = 980000}
30959 s = (Socket *) 0xa851ae0
30960 s2 = (Socket *) 0x0
30961 #12 0x0805538a in main (ac=3, av=0xbffff164, envp=0xbffff174) at main.c:266
30962 ---Type <return> to continue, or q <return> to quit---
30964 now_msec = 1348441861
30965 last_update = 1066500208
30966 last_check = 1348441182
30967 #13 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
30968 No symbol table info available.
30973 From saturn at jetirc.net Sat Oct 18 12:18:40 2003
30974 From: saturn at jetirc.net (Saturn)
30975 Date: Sat Oct 23 23:10:02 2004
30976 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
30977 References: <3f90afdf.23477@achurch.org>
30978 Message-ID: <003701c395ac$9ff9fd20$6401a8c0@turby>
30980 I thank you for finally just coming out and telling me what I needed to know
30981 in the first place. Had you stated that it has been discussed before (even
30982 without the hyperlinks) I would have at least known to go look through the
30983 archives. However, all you said (then repeated) was RTFM. I DID read it,
30984 once before I asked, and twice more, at your instruction, and found nothing
30985 to answer my questions. Had I known it had already been discussed, I would
30986 certainly have tried to locate the answer that way.
30988 Thank you to all the others who've posted to try and explain what I was
30989 missing in my understanding of this directive. I got it now, and realize
30990 where my misinterpretation was. Seems obvious now, but frankly that
30991 directive managed to fool myself and 8 of my staff into thinking of it as I
30992 have previously described. Regardless, my apologies for any harsh words...
30993 I do stand by the fact that Andrew could have responded with a bit less
30994 apathy to the concerns raised; with something a bit less useless than RTFM
30995 (twice! even AFTER I said I had, THAT'S what pissed me off), and I hope that
30996 maybe Andrew will remember this chain of events for the next time someone
30997 has a problem that might be immediately obvious to Andrew, but not the
30998 person with the problem. I think most of us KNOW by now to read the docs
30999 before asking questions; but if the question arises due to misinterpretation
31000 of the docs, how would reading them over and over help?
31002 Thank you all for your time.
31006 ----- Original Message -----
31007 From: "Andrew Church" <achurch@achurch.org>
31008 To: <ircservices-coding@ircservices.za.net>
31009 Sent: Friday, October 17, 2003 7:57 PM
31010 Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
31013 You know, I might have been more forgiving if this hadn't been gone
31014 over on this list (twice!) before:
31016 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/002305.html
31017 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/003215.html
31019 However, since you seem to have trouble both comprehending the
31020 documentation and reading the archives, I have added FAQ F.10 for your
31023 F.10. Services doesn't kill users matching a newly-added autokill mask even
31024 if ImmediatelySendAutokill is set.
31026 Services never kills users when a new autokill is added; the
31027 ImmediatelySendAutokill configuration directive only causes
31028 Services to send the autokill itself (that is, the user/host mask
31029 to prohibit new connections from) to the IRC servers on your
31030 network. This is a safety feature intended to limit the damage
31031 caused by a mistyped autokill.
31033 Note that some IRC servers will themselves kill users matching a
31034 newly-added autokill; this is unrelated to Services.
31037 achurch@achurch.org
31038 http://achurch.org/
31039 ------------------------------------------------------------------
31040 To unsubscribe or change your subscription options, visit:
31041 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
31044 From diego at redesul.net Sat Oct 18 14:38:17 2003
31045 From: diego at redesul.net (Diego B. Contezini)
31046 Date: Sat Oct 23 23:10:02 2004
31047 Subject: [IRCServices Coding] CORE DUMPED... Debuging
31048 Message-ID: <003f01c395c0$09a31cd0$3cc8a8c0@angel>
31050 If it helps, more lines up.. of debugging...
31053 ChanServ@services.redesul.net :op #manaus paulinhu-dissi-q-mi-ama
31054 [Oct 18 16:05:31.152195 2003] debug: Sent: :ChanServ NOTICE paulinhu-dissi-q-mi-ama :Permission denied.
31055 [Oct 18 16:05:31.152274 2003] debug: Received: :pRiCkLy SJOIN 1066501295 #Euevc
31056 [Oct 18 16:05:31.152353 2003] protocol/bahamut: debug: pRiCkLy SJOINs #Euevc
31057 [Oct 18 16:05:31.152490 2003] debug: Sent: :ChanServ MODE #EUeVC +o pRiCkLy
31058 [Oct 18 16:05:31.269153 2003] debug: Received: :Hellskitty PRIVMSG ChanServ@services.redesul.net :unban #EMOCORE
31059 [Oct 18 16:05:31.269425 2003] debug: Sent: :ChanServ NOTICE Hellskitty :Permission denied.
31060 [Oct 18 16:05:31.288596 2003] debug: Received: :|-Frango-| MODE #EMOCORE +stmipl 1
31061 [Oct 18 16:05:31.288768 2003] debug: Received: :|-Frango-| TOPIC #EMOCORE |-Frango-| 1066460927 :TakeOver by 14,1 -15=0[ 14He15l0lR15ai14ser 0]15=14- S15c0ri15p14t 15v3.8
31062 [Oct 18 16:05:31.288944 2003] debug: Sent: :ChanServ TOPIC #EMOCORE reffer 1066055037 :1??? Festival HARDcoCOREcore dia 25 de outubro em blumenau no rio bravo bar (proximo a resima agua verde), com as bandas: Zero Ltda (curitiba), Swallow the Waffle (bc), chymia(bnu), crazy frogs (lages), surpise set e slipper (bnu)...3 pila entrada inicio as 15:00 horas'
31063 [Oct 18 16:05:31.289032 2003] debug: Received: :|-Frango-| MODE #EMOCORE -oooooo CHoPP CbRS-oFF caroll BRYAN brunaH balsanelli
31064 Segmentation fault (core dumped)
31066 -------------- next part --------------
31067 An HTML attachment was scrubbed...
31068 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20031018/667c67fa/attachment-0001.htm
31069 From ballsy at mystical.net Mon Oct 20 08:19:44 2003
31070 From: ballsy at mystical.net (Ballsy)
31071 Date: Sat Oct 23 23:10:02 2004
31072 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
31073 In-Reply-To: <200310182149.18600.v13@it.teithe.gr>
31074 References: <3f9012b8.23176@achurch.org> <030801c3950f$3cb55270$6401a8c0@turby>
31075 <3F90BF77.2010706@t2n.org> <200310182149.18600.v13@it.teithe.gr>
31076 Message-ID: <6.0.0.22.0.20031020091611.01b47318@127.0.0.1>
31078 Yes, Bahamut will immediately kill users matching an Akill. It
31079 won't wait for another client from that host to connect. My setup of IRC
31080 Services 5.0.22 and bahamut-1.4.30 is doing it right now. As alluded to in
31081 a previous email, however, you may need to commented out EnableExclude in
31082 the services config to have this work.
31087 At 12:49 PM 18/10/2003, V13 wrote:
31088 >On Saturday 18 October 2003 07:20, Robert F Merrill wrote:
31090 > > >Would have been nice if someone had mentioned that (about the
31091 > > >ImmediatelySendAutokill) from the start. I would say the flag is
31092 > > > misleading in title then, because I (and 8 other people on my staff --
31093 > > > none of us are dummies, either) read that as meaning it will Immediately
31094 > > > send the auto kill... "ImmediatelyUpdateServers" might be more fitting
31095 > > > from an intuitive standpoint, not that I'm suggesting changing the name,
31096 > > > but at least the documentation of it could be a bit more explicit IMHO.
31098 > > It DOES immediately send the autokill. You just don't grasp the meaning
31099 > > of sending the autokill.
31100 > > It literally sends an AKILL (or TKL in the case of unreal) message to
31101 > > the servers. At least unreal
31102 > > and bahamut will then scan for matching clients and disconnect them,
31103 > > however not all servers
31106 >FYI bahamut doesn't do this. It will only do it whenever a new client that
31107 >matches the akill connects to the server.
31109 >i.e. if you set an akill for *.com noone will be disconnected untill a new
31110 >client from *.com gets connected (at that moment, all matching clients will
31111 >be killed). In the mean time, anyone from other domains can connect to the
31112 >server without having any user killed.
31115 >------------------------------------------------------------------
31116 >To unsubscribe or change your subscription options, visit:
31117 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
31121 From oska at mynet.com Tue Oct 21 22:24:34 2003
31122 From: oska at mynet.com (oska)
31123 Date: Sat Oct 23 23:10:02 2004
31124 Subject: [IRCServices Coding] "Re: Contents of IRCServices-Coding digest..."
31125 Message-ID: <HN58ED$I890Q9pEOh0UN3QcHkNkg1Bm2fHspFZq@mynet.com>
31127 An HTML attachment was scrubbed...
31128 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20031022/9c540c11/attachment-0001.html
31129 From laser at musichat.net Fri Oct 24 10:36:30 2003
31130 From: laser at musichat.net (laser@musichat.net)
31131 Date: Sat Oct 23 23:10:02 2004
31132 Subject: [IRCServices Coding] Il momento e' catartico
31133 Message-ID: <20031024173545.9ACA817038@snow.fingers.co.za>
31135 Ricevo e cortesemente inoltro,.... un premio per la genialit?
31136 hanno reso mitico un salva schermo scaricalo, "poesie catartiche", che non sai cosa ti perdi
31139 -------------- next part --------------
31140 An HTML attachment was scrubbed...
31141 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20031024/97501fa5/attachment-0001.htm
31142 From diego at redesul.net Fri Oct 24 17:02:47 2003
31143 From: diego at redesul.net (Diego B. Contezini)
31144 Date: Sat Oct 23 23:10:02 2004
31145 Subject: [IRCServices Coding] CORE DUMPED! BUG!
31146 References: <3f8f9304.20227@achurch.org> <000e01c395ac$5b773b40$3cc8a8c0@angel>
31147 Message-ID: <012e01c39a8b$531829d0$3cc8a8c0@angel>
31149 Andrew, have anything more of dumping/debugging that i can do/give for helps
31151 (if it helps, here its rh9.0, libc 2.3.2, linux x86, kernel 2.4.20-8,
31152 Pentium III 1ghz 512mb ram DDR)....
31162 From andrew at wtfigo.co.uk Tue Nov 4 02:15:03 2003
31163 From: andrew at wtfigo.co.uk (Andrew Kempe)
31164 Date: Sat Oct 23 23:10:02 2004
31165 Subject: [IRCServices Coding] test
31166 Message-ID: <E1AGyDD-0001mX-00@smtp.mailbox.co.uk>
31170 From diego at redesul.net Tue Nov 4 16:43:45 2003
31171 From: diego at redesul.net (Diego B. Contezini)
31172 Date: Sat Oct 23 23:10:02 2004
31173 Subject: [IRCServices Coding] CORE DUMPED! BUG!
31174 Message-ID: <014f01c3a335$e1e08dd0$3cc8a8c0@angel>
31176 I found a bug (occuring on the old-last vesion of ircservices -
31177 ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
31179 yes, 5.0.23 is the last.. but nothing has changed about the bug...
31181 here is the debugging:
31183 ChanServ@services.redesul.net :op #manaus paulinhu-dissi-q-mi-ama
31184 [Oct 18 16:05:31.152195 2003] debug: Sent: :ChanServ NOTICE
31185 paulinhu-dissi-q-mi-ama :Permission denied.
31186 [Oct 18 16:05:31.152274 2003] debug: Received: :pRiCkLy SJOIN 1066501295
31188 [Oct 18 16:05:31.152353 2003] protocol/bahamut: debug: pRiCkLy SJOINs #Euevc
31189 [Oct 18 16:05:31.152490 2003] debug: Sent: :ChanServ MODE #EUeVC +o pRiCkLy
31190 [Oct 18 16:05:31.269153 2003] debug: Received: :Hellskitty PRIVMSG
31191 ChanServ@services.redesul.net :unban #EMOCORE
31192 [Oct 18 16:05:31.269425 2003] debug: Sent: :ChanServ NOTICE Hellskitty
31193 :Permission denied.
31194 [Oct 18 16:05:31.288596 2003] debug: Received: :|-Frango-| MODE #EMOCORE
31196 [Oct 18 16:05:31.288768 2003] debug: Received: :|-Frango-| TOPIC #EMOCORE
31197 |-Frango-| 1066460927 :TakeOver by 14,1 -15=0[ 14He15l0lR15ai14ser 0]15=14-
31198 S15c0ri15p14t 15v3.8
31199 [Oct 18 16:05:31.288944 2003] debug: Sent: :ChanServ TOPIC #EMOCORE reffer
31200 1066055037 :1i?? Festival HARDcoCOREcore dia 25 de outubro em blumenau no
31201 rio bravo bar (proximo a resima agua verde), com as bandas: Zero Ltda
31202 (curitiba), Swallow the Waffle (bc), chymia(bnu), crazy frogs (lages),
31203 surpise set e slipper (bnu)...3 pila entrada inicio as 15:00 horas'
31204 [Oct 18 16:05:31.289032 2003] debug: Received: :|-Frango-| MODE
31205 #EMOCORE -oooooo CHoPP CbRS-oFF caroll BRYAN brunaH balsanelli
31206 Segmentation fault (core dumped)
31209 Debugging my core... i can found:
31210 #0 0x0804d830 in add_mode_with_params (md=0x806aa00, mode=111 'o',
31211 is_add=1, params=1, parambuf=0xbfffe280 "balsanelli",
31212 len=10) at actions.c:568
31213 568 md->params[md->nopmodes][len] = 0;
31215 #0 0x0804d830 in add_mode_with_params (md=0x806aa00, mode=111 'o',
31216 is_add=1, params=1, parambuf=0xbfffe280 "balsanelli",
31217 len=10) at actions.c:568
31219 #1 0x0804d342 in set_cmode (sender=0x81db058 "ChanServ", channel=0xa905d00)
31222 "balsanelli\000\b\025\225\002BWi??\022B\024\032\023Bi??i??i??i??\000\000\000
31223 \000\034 \006\bi??i??i??i??hi??i??i??i??i??i??i??\025\224\004B\034
31224 \006\b\000\000\000\000i??m\tBdi??\022Bi??q\a\b\000\000\000\000eR :\0037[
31225 \0034#\003di??\022B\000\000\000\000i??\037\006\bi??\037\006\bi??i??i??i??$i?
31226 ?\006Bi??i??i??i??\bi??i??i??\000\000\000\000Hi??i??i??\025\224\004B@\002\a\
31227 b8i??i??i??6\020\aBpi??i??i??@i??\006\b@\002\a\b\000\000\000\000i??<\023BLi?
31228 ?i??i??=S\004B\024\032\023B\001\020\000\000@i??\006\bhi??i??i??\204i??\006Bp
31229 i??i??i??i??\037\006\b"...
31234 args = 0xbfffe6d0 "RDcoCOREcorei??i??i??i??o"
31235 modes = 0xbfffeae2 ""
31236 modes_orig = 0xbfffeae0 "+o"
31237 md = (struct modedata *) 0x806aa00
31242 #2 0x400895ff in local_set_cumodes (c=0xa905d00, plusminus=43 '+', modes=1,
31243 nick=0xab7f2e8 "balsanelli") at check.c:432
31245 modestr = "o\000\000 de outubro em blumenau no rio bravo bar
31246 (proximo a resima agua verde), com as bandas: Zero
31247 L\v\000\000\000(curitiba), \000\000\000\000low the Waff\000\000\000\000bc),
31248 chymia(bnu), crazy frogs (lages), surpise set e slipper (bnu).."...
31250 #3 0x40088d74 in check_chan_user_modes (source=0xbfffeed0 "|-Frango-|",
31251 u=0xab34ff0, c=0xa905d00, oldmodes=1)
31253 user = (User *) 0xab7f2d8
31254 ci = (ChannelInfo *) 0xa571940
31258 #4 0x400820ed in do_channel_umode_change (source=0xbfffeed0 "|-Frango-|",
31259 c=0xa905d00, u=0xab34ff0, oldmodes=1)
31262 #5 0x0805890d in call_callback_5 (module=0x806a5c0, id=23, arg1=0xbfffeed0,
31263 arg2=0xa905d00, arg3=0xab34ff0, arg4=0x1,
31264 arg5=0x0) at modules.c:666
31265 cl = (CallbackList *) 0x8077cb8
31268 #6 0x0804edc8 in do_cumode (source=0xbfffeed0 "|-Frango-|", chan=0xa905d00,
31269 flag=1, add=0, nick=0xbfffecc9 "balsanelli")
31270 ---Type <return> to continue, or q <return> to quit---
31272 u = (struct c_userlist *) 0xab34ff0
31273 user = (User *) 0xab7f2d8
31275 #7 0x0804e97e in do_cmode (source=0xbfffeed0 "|-Frango-|", ac=0,
31276 av=0xa853130) at channels.c:302
31279 params = -1073746288
31280 chan = (Channel *) 0xa905d00
31283 modestr = 0xbfffec9e "-oooooo"
31284 #8 0x080557ff in m_mode (source=0xbfffeed0 "|-Frango-|", ac=8,
31285 av=0xa853110) at messages.c:101
31287 #9 0x0805920e in process () at process.c:133
31288 m = (Message *) 0x8067dd8
31290 "|-Frango-|\000\000G\000\000\000Y\e\205\n\t+\205\n\bi??i??i??i??i??\005\b@j\
31291 a\b\000\004\000\000i??\032\205\n\t\000\000\000@j\a\b\216j\a\b(i??i??i??qP\00
31294 "MODE\000\000\000i??8i??i??i??i??\005\b\000\000\000\000i??i??i??i??\000\000\
31295 000\000\000\000\000\000\001H\000\000Pi??i??i??\000Y\a\bVi??\005\b\207j\a\bP\
31296 e\205\n\t\000\000\000i??i??\005\b"
31298 "MODE\000#EMOCORE\000-oooooo\000CHoPP\000CbRS-oFF\000caroll\000BRYAN\000brun
31299 aH\000balsanelli\000 balsanelli\000\000ai\00314ser \0030]\00315=\00314-
31300 S\00315c\0030ri\00315p\00314t \00315\037v\0373.8 \003\000\00315\037v\0373.8
31301 \003\000\000\0003)\000\0006\037\002Pi??Ti??\00313\037\002]\037\002\0036i??i?
31302 ? \000i??Ti??\00313\037\002]\037\002\0036i??i?? \000\000\003\000\000r
31303 \003", '\0' <repeats 11 times>...
31304 s = 0xbfffec95 "#EMOCORE"
31306 av = (char **) 0xa853110
31307 #10 0x0805507d in readline_callback (s=0xa851ae0, param_unused=0x50) at
31310 #11 0x0805b617 in check_sockets () at sockets.c:491
31311 newline = 0xa851b58 "\nrct-sc.br irc.creativenet.com.br 0 3364349034
31312 :aNiNhHa[du]DoNaTeLo\n:Toh_Pensanu PART #ilheus\n:_LoKo_SuL_ SJOIN
31313 1063565447 #elias\n:_MoRgAnA_ PRIVMSG NickServ@services.redesul.net :set
31314 nomemo off\n:irc."...
31317 rfds = {fds_bits = {16, 0 <repeats 31 times>}}
31318 wfds = {fds_bits = {0 <repeats 32 times>}}
31319 tv = {tv_sec = 2, tv_usec = 980000}
31322 s = (Socket *) 0xa851ae0
31323 s2 = (Socket *) 0x0
31324 #12 0x0805538a in main (ac=3, av=0xbffff164, envp=0xbffff174) at main.c:266
31325 ---Type <return> to continue, or q <return> to quit---
31327 now_msec = 1348441861
31328 last_update = 1066500208
31329 last_check = 1348441182
31330 #13 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
31331 No symbol table info available.
31332 (gdb) info registers
31333 eax 0xd6b2bf8a -692928630
31334 ecx 0x806aa00 134654464
31335 edx 0x656e6173 1701732723
31336 ebx 0x42131a14 1108548116
31337 esp 0xbfffd910 0xbfffd910
31338 ebp 0xbfffe238 0xbfffe238
31339 esi 0x8075900 134699264
31340 edi 0xbffff050 -1073745840
31341 eip 0x804d830 0x804d830
31342 eflags 0x10282 66178
31352 root@irc(/home/ircadmin/services/lib)# ls -la core.12631
31353 -rw------- 1 ircadmin ircadmin 47374336 Oct 18 16:05 core.12631
31354 root@irc(/home/ircadmin/services)# ldd ircservices
31355 libdl.so.2 => /lib/libdl.so.2 (0x4001e000)
31356 libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
31357 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
31358 root@irc(/home/ircadmin/services)# uname -a
31359 Linux XXXXXX.xyz.0xdeadbeef 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686
31360 i686 i386 GNU/Linux
31361 root@irc(/home/ircadmin/services)# cat /etc/redhat-release
31362 Red Hat Linux release 9 (Shrike)
31363 root@irc(/home/ircadmin/services)# cat /proc/cpuinfo
31365 model name : Pentium III (Coppermine)
31368 cache size : 256 KB
31370 root@irc(/home/ircadmin/services)# free
31371 total used free shared buffers cached
31372 Mem: 513792 482248 31544 0 69492 274980
31374 I changed version of linux, runned it on 3 different machines, on
31375 slackware/redhat, pentiumIII, K5, P200.
31376 This bug is as older as i run services... dont know if its the same of the
31377 4.X (that i changed to 5.X to "solve" this bug), but from 5.12 to now, it
31378 continue happening... aways...
31379 Dont have a exactly time to happen, its insane... i think that its a
31380 coincidence of some commands that on the memory ends fucking some variable.
31381 if you want look the incidence, here its:
31382 root@irc(/home/ircadmin/services/lib)# ls -la core*
31384 -rw------- 1 ircadmin ircadmin 49025024 Oct 5 19:32 core.27214
31385 -rw------- 1 ircadmin ircadmin 45932544 Oct 5 21:01 core.14414
31386 -rw------- 1 ircadmin ircadmin 46948352 Oct 6 14:00 core.18016
31387 -rw------- 1 ircadmin ircadmin 45936640 Oct 11 04:30 core.1347
31388 -rw------- 1 ircadmin ircadmin 50479104 Oct 14 01:29 core.16481
31389 -rw------- 1 ircadmin ircadmin 44982272 Oct 15 13:54 core.22332
31390 -rw------- 1 ircadmin ircadmin 47374336 Oct 18 16:05 core.12631
31391 -rw------- 1 ircadmin ircadmin 48099328 Oct 19 14:16 core.5362
31392 -rw------- 1 ircadmin ircadmin 44863488 Oct 19 14:22 core.32708
31393 -rw------- 1 ircadmin ircadmin 45355008 Nov 1 15:13 core.28309
31394 -rw------- 1 ircadmin ircadmin 50360320 Nov 3 18:24 core.5160
31397 If it helps, here is the debugging of the last two cores, on gdb:
31400 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
31405 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
31408 chan = (Channel *) 0xa87d1e0
31409 s = 0x1f73746f <Address 0x1f73746f out of bounds>
31411 modestr = 0x1f73746f <Address 0x1f73746f out of bounds>
31412 #1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:680
31413 buf = "-imsl\000HA___\000\000\000\000\000W
31414 \022B\000\000\000L\000\000\000\000\000y\000nossaTZ\000\000\000\000\000\000yy
31415 yyA<\023B\001\000\000\000\bYy?Om\tBd
31416 \022BDq\a\bOUy?NO\006B\210o\a\b3\035\rB\024\032\023BAa\006B\003\000\000\000a
31417 Yy?\027\000\000\000\024\032\023B\024\032\023BTZ\000\000\004\000\000\000\005\
31418 000\000\000\210o\a\baYy?\030Yy?NO\006B\210o\a\baYy?\027\000\000\000$u\006B\2
31419 10o\a\bIo\a\b\vO\006B\024\032\023B\024\032\023B@\002\a\bHYy?$u\006B\200Yy?@o
31421 s = 0xbfffdc60 "-imsl"
31422 argv = {0xa87d1e8 "#soad",
31423 0x1f73746f <Address 0x1f73746f out of bounds>,
31424 0x5303200f <Address 0x5303200f out of bounds>,
31425 0x6c6c6568 <Address 0x6c6c6568 out of bounds>,
31426 0x4323203a <Address 0x4323203a out of bounds>,
31427 0x65746e65 <Address 0x65746e65 out of bounds>,
31428 0x65685372 <Address 0x65685372 out of bounds>,
31429 0x52426c6c <Address 0x52426c6c out of bounds>}
31431 ---Type <return> to continue, or q <return> to quit---
31434 #2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
31438 md = (struct modedata *) 0x0
31443 #3 0x080553a3 in main (ac=1, av=0xbfffe574, envp=0xbfffe57c) at main.c:269
31445 now_msec = -1555790286
31446 last_update = 1067890538
31447 last_check = 2739174210
31448 #4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
31449 No symbol table info available.
31453 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
31458 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
31461 chan = (Channel *) 0xa9be840
31462 s = 0xbf000000 <Address 0xbf000000 out of bounds>
31464 modestr = 0xbf000000 <Address 0xbf000000 out of bounds>
31465 #1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:680
31466 buf = "-imsl\000\a\b\000len\000\000\000\000W
31467 \022B3\035\rB\024\032\023BAa\006B\003\000\000\000
31468 oy?\027\000\000\000yyyyA<\023BTZ\000\000\004\000\000\000\005\000\000\000\210
31469 o\a\b oy?Xoy?NO\006B\210o\a\b
31470 oy?\027\000\000\000$u\006B\210o\a\bIo\a\b\vO\006B\024\032\023B\024\032\023B@
31471 \002\a\b\210oy?$u\006BAoy?@o\006\b@\002\a\b\000\000\000\000\024\032\023B@\00
31472 2\a\b?oy?6\020\aBaoy?@o\006\b@\002\a\b\000\000\000\000Aoy?I\037\006\b=S\004B
31473 \024\032\023B\001\020\000\000@o\006\b"...
31474 s = 0xbffff2e0 "-imsl"
31475 argv = {0xa9be848 "#zoera",
31476 0xbf000000 <Address 0xbf000000 out of bounds>, 0x0,
31477 0x806f240 "ircservices.log", 0x806f240 "ircservices.log",
31478 0x5a54 <Address 0x5a54 out of bounds>, 0x0,
31479 0xffffffff <Address 0xffffffff out of bounds>}
31483 #2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
31484 ---Type <return> to continue, or q <return> to quit---
31488 md = (struct modedata *) 0x0
31493 #3 0x080553a3 in main (ac=1, av=0xbffffbf4, envp=0xbffffbfc) at main.c:269
31495 now_msec = -1740061222
31496 last_update = 1067706282
31497 last_check = 2554904000
31498 #4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
31499 No symbol table info available.
31502 Im running it more a time on Screen to can get exactly where occur the bug
31503 (with -nofork -debug), to look for more examples of commands that causes
31505 if have something (more) that i can to add/do to helps on debugging, please,
31506 tell me.. i have the core (i cant send it, for secure reasons... have all my
31507 db on the core... ), but im open to helps anytime anywhere... with
31510 Thanks for all development, this is really a bealtifull software...
31511 (and sorry for my bad english)
31513 Diego B. Contezini aka destruct_ #irc.redesul.net
31517 From diego at redesul.net Tue Nov 4 16:46:53 2003
31518 From: diego at redesul.net (Diego B. Contezini)
31519 Date: Sat Oct 23 23:10:02 2004
31520 Subject: [IRCServices Coding] about.. CORE DUMPED! BUG!
31521 Message-ID: <01fa01c3a336$4e884220$3cc8a8c0@angel>
31523 If it helps, im using Bahamut here....
31526 From achurch at achurch.org Wed Nov 5 13:20:15 2003
31527 From: achurch at achurch.org (Andrew Church)
31528 Date: Sat Oct 23 23:10:02 2004
31529 Subject: [IRCServices Coding] Bug or misunderstood ?
31530 In-Reply-To: <000901c39496$71764f10$a37faec3@coder>
31531 Message-ID: <3fa87c99.57222@achurch.org>
31533 >Im using unreal ircd. When channel is empty and if channel owner joins
31534 >his/her registered channel it does
31535 >(ChanServ sets mode: +ntrq nick) but when channel is not empty and if
31536 >channel owner joins his/her registered channel it does (ChanServ sets mode:
31537 >+oq nick nick). As you see on the first one there is no +o and because of
31538 >this chanserv does not update the last_used time because chanserv is set to
31539 >update last_used time with +o (CUMODE_o) so channels drop while channel
31540 >owners use them. Is this a bug or my misunderstood ?
31542 This is a bug; I've fixed it for the next release, thanks for the
31543 report. As regards your other message, not setting the last-used time for
31544 +a/+q users is designed behavior (see section 3-2-1 of the manual: "`used'
31545 means that a user with auto-op privileges ... has entered the channel"), as
31546 well as unnecessary in typical channel settings (where +a users are a
31547 subset of +o users), but if you have any better suggestions on how to
31548 determine when a channel is being used by proper users as opposed to (for
31549 example) spammers or people just entering to see if the channel is
31550 available, I'm willing to listen.
31553 achurch@achurch.org
31554 http://achurch.org/
31556 From rg at tcslon.com Fri Nov 7 02:03:27 2003
31557 From: rg at tcslon.com (Russell Garrett)
31558 Date: Sat Oct 23 23:10:02 2004
31559 Subject: [IRCServices Coding] Badly punctuated parameter list in `#define'
31560 Message-ID: <MKEGJINFADFODDNOKEJCMELPEGAA.rg@tcslon.com>
31562 I'm getting this too - it's just started happening in 5.0.23:
31564 gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -fno-builtin-log
31565 -I.. -DCONVERT_DB -c convert-cygnus.c -o convert-cygnus.o
31566 convert-cygnus.c:35: badly punctuated parameter list in `#define'
31567 convert-cygnus.c:48: badly punctuated parameter list in `#define'
31569 gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
31574 From rayfordp at mhcable.com Sat Nov 8 16:42:18 2003
31575 From: rayfordp at mhcable.com (Rayford Pomeroy)
31576 Date: Sat Oct 23 23:10:02 2004
31577 Subject: [IRCServices Coding] Akill type?
31578 Message-ID: <20031109055605.A7BAF17104@snow.fingers.co.za>
31580 Where is the akill type used in some of AutoKill functions listed in
31581 modules/database/readme defined?
31583 ________________________________________________
31584 Message sent using MHCABLE Webmail
31587 From andrewk at isdial.net Tue Aug 26 02:43:45 2003
31588 From: andrewk at isdial.net (Andrew Kempe)
31589 Date: Sat Oct 23 23:10:02 2004
31590 Subject: [IRCServices Coding] test
31591 Message-ID: <005801c36bb6$85bbc080$1f0912ac@espotting.com>
31595 From us44ever at hotmail.com Thu Aug 28 09:45:48 2003
31596 From: us44ever at hotmail.com (us44ever .)
31597 Date: Sat Oct 23 23:10:02 2004
31598 Subject: [IRCServices Coding] Yet, another great suggestion
31599 Message-ID: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
31603 it would be really great to add another new line to the "/nickserv info"
31604 command, for example, when some one types: "/nickserv info nick", the
31605 following will be shown:
31607 ***************************
31609 -NickServ- nick is hello world
31611 -NickServ- Is online from: ~test@just.a.test.co.za
31613 -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
31615 -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
31617 -NickServ- Last quit message: anythinggggg
31619 -NickServ- Options: Kill protection, Security
31621 ***************************
31623 the new line I'm suggesting is something like:
31625 ***************************
31626 -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
31627 ***************************
31629 This will help our users to compare the time that user was last seen and the
31630 time right now *it's very important, many many of our users asked us for
31631 this option*, also it would even be more great to show how long last time
31632 the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003 GMT
31633 (last seen time was before: 10 days, 3hours and 24 sec ago).
31635 Note that I saw both of these features, in other services I don't remember
31636 there names (but they aren't as stable as ircservices5) (it was something
31637 like ptlink services, and magik II)
31639 That's all, I would really like to see it on the next version (or if you can
31640 show me how to do it, as I'm not a programmer)
31642 Many thanks to all of who developed IRCservices ...etc ...etc ...etc
31647 _________________________________________________________________
31648 Get MSN 8 and enjoy automatic e-mail virus protection.
31649 http://join.msn.com/?page=features/virus
31652 From aragon at phat.za.net Thu Aug 28 11:36:22 2003
31653 From: aragon at phat.za.net (Aragon Gouveia)
31654 Date: Sat Oct 23 23:10:03 2004
31655 Subject: [IRCServices Coding] Yet, another great suggestion
31656 In-Reply-To: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
31657 References: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
31658 Message-ID: <20030828183615.GB32204@phat.za.net>
31660 Or how about rather letting users decide what timezone they're in and
31661 services outputs all timestamps in their local time?
31664 | By us44ever . <us44ever@hotmail.com>
31665 | [ 2003-08-28 18:45 +0200 ]
31668 > it would be really great to add another new line to the "/nickserv info"
31669 > command, for example, when some one types: "/nickserv info nick", the
31670 > following will be shown:
31672 > ***************************
31674 > -NickServ- nick is hello world
31676 > -NickServ- Is online from: ~test@just.a.test.co.za
31678 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
31680 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
31682 > -NickServ- Last quit message: anythinggggg
31684 > -NickServ- Options: Kill protection, Security
31686 > ***************************
31688 > the new line I'm suggesting is something like:
31690 > ***************************
31691 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
31692 > ***************************
31694 > This will help our users to compare the time that user was last seen and
31695 > the time right now *it's very important, many many of our users asked us
31696 > for this option*, also it would even be more great to show how long last
31697 > time the user was seen (some thing like: Last seen time: Aug 28 15:51:14
31698 > 2003 GMT (last seen time was before: 10 days, 3hours and 24 sec ago).
31700 > Note that I saw both of these features, in other services I don't remember
31701 > there names (but they aren't as stable as ircservices5) (it was something
31702 > like ptlink services, and magik II)
31704 > That's all, I would really like to see it on the next version (or if you
31705 > can show me how to do it, as I'm not a programmer)
31707 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
31712 > _________________________________________________________________
31713 > Get MSN 8 and enjoy automatic e-mail virus protection.
31714 > http://join.msn.com/?page=features/virus
31716 > ------------------------------------------------------------------
31717 > To unsubscribe or change your subscription options, visit:
31718 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
31720 From saturn at jetirc.net Thu Aug 28 11:39:41 2003
31721 From: saturn at jetirc.net (Saturn)
31722 Date: Sat Oct 23 23:10:03 2004
31723 Subject: [IRCServices Coding] Yet, another great suggestion
31724 References: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
31725 <20030828183615.GB32204@phat.za.net>
31726 Message-ID: <003201c36d93$abf77fd0$6401a8c0@turby>
31728 Oooo now I like that option... have it default to a default timezone, set in
31729 the conf file, and give them the option of SETting a different UTC code
31730 (have it as GMT + or - x wheer x is the offset from UTC)... It may not
31731 sound liek much, but I bet people will use it, and what's more, it IS useful
31732 information, especially on international servers like mine.. we have people
31733 from all over the place, and we keep services set on Pacific time... but for
31734 those in, say, Belgium... that's not very helpful
31736 ----- Original Message -----
31737 From: "Aragon Gouveia" <aragon@phat.za.net>
31738 To: <ircservices-coding@ircservices.za.net>
31739 Sent: Thursday, August 28, 2003 11:36 AM
31740 Subject: Re: [IRCServices Coding] Yet, another great suggestion
31743 Or how about rather letting users decide what timezone they're in and
31744 services outputs all timestamps in their local time?
31747 | By us44ever . <us44ever@hotmail.com>
31748 | [ 2003-08-28 18:45 +0200 ]
31751 > it would be really great to add another new line to the "/nickserv info"
31752 > command, for example, when some one types: "/nickserv info nick", the
31753 > following will be shown:
31755 > ***************************
31757 > -NickServ- nick is hello world
31759 > -NickServ- Is online from: ~test@just.a.test.co.za
31761 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
31763 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
31765 > -NickServ- Last quit message: anythinggggg
31767 > -NickServ- Options: Kill protection, Security
31769 > ***************************
31771 > the new line I'm suggesting is something like:
31773 > ***************************
31774 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
31775 > ***************************
31777 > This will help our users to compare the time that user was last seen and
31778 > the time right now *it's very important, many many of our users asked us
31779 > for this option*, also it would even be more great to show how long last
31780 > time the user was seen (some thing like: Last seen time: Aug 28 15:51:14
31781 > 2003 GMT (last seen time was before: 10 days, 3hours and 24 sec ago).
31783 > Note that I saw both of these features, in other services I don't remember
31784 > there names (but they aren't as stable as ircservices5) (it was something
31785 > like ptlink services, and magik II)
31787 > That's all, I would really like to see it on the next version (or if you
31788 > can show me how to do it, as I'm not a programmer)
31790 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
31795 > _________________________________________________________________
31796 > Get MSN 8 and enjoy automatic e-mail virus protection.
31797 > http://join.msn.com/?page=features/virus
31799 > ------------------------------------------------------------------
31800 > To unsubscribe or change your subscription options, visit:
31801 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
31802 ------------------------------------------------------------------
31803 To unsubscribe or change your subscription options, visit:
31804 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
31808 From Craig at chatspike.net Thu Aug 28 14:29:54 2003
31809 From: Craig at chatspike.net (Craig McLure)
31810 Date: Sat Oct 23 23:10:03 2004
31811 Subject: [IRCServices Coding] Yet, another great suggestion
31812 Message-ID: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
31814 Please dont post to both the services main list, and the services coding list. Choose one, or the other, especially concidering i dont think this is a great suggestion either..
31816 /time services.chatspike.net
31817 [22:28]
\95\95\95 Date / time at services.chatspike.net- Thu Aug 28 17:28:57 2003 EDT
31821 /****************************************
31822 * Craig "FrostyCoolSlug" McLure
31823 ************* - SpamBox - **************
31824 * InspIRCd - http://www.inspircd.org
31825 * ChatSpike - http://www.chatspike.net
31826 * WinBot - http://www.winbot.co.uk
31827 ****************************************/
31829 /****************************************
31830 * From - us44ever . <us44ever@hotmail.com>
31831 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
31832 * Sent - 2003-08-28 @ 16:45:00
31833 * Subject - [IRCServices Coding] Yet, another great suggestion
31834 ****************************************/
31836 /****** - Begin Original Message - ******/
31840 >it would be really great to add another new line to the "/nickserv info"
31841 >command, for example, when some one types: "/nickserv info nick", the
31842 >following will be shown:
31844 >***************************
31846 >-NickServ- nick is hello world
31848 >-NickServ- Is online from: ~test@just.a.test.co.za
31850 >-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
31852 >-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
31854 >-NickServ- Last quit message: anythinggggg
31856 >-NickServ- Options: Kill protection, Security
31858 >***************************
31860 >the new line I'm suggesting is something like:
31862 >***************************
31863 >-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
31864 >***************************
31866 >This will help our users to compare the time that user was last seen and the
31867 >time right now *it's very important, many many of our users asked us for
31868 >this option*, also it would even be more great to show how long last time
31869 >the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003 GMT
31870 >(last seen time was before: 10 days, 3hours and 24 sec ago).
31872 >Note that I saw both of these features, in other services I don't remember
31873 >there names (but they aren't as stable as ircservices5) (it was something
31874 >like ptlink services, and magik II)
31876 >That's all, I would really like to see it on the next version (or if you can
31877 >show me how to do it, as I'm not a programmer)
31879 >Many thanks to all of who developed IRCservices ...etc ...etc ...etc
31884 >_________________________________________________________________
31885 >Get MSN 8 and enjoy automatic e-mail virus protection.
31886 >http://join.msn.com/?page=features/virus
31888 >------------------------------------------------------------------
31889 >To unsubscribe or change your subscription options, visit:
31890 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
31892 /******* - End Original Message - *******/
31897 From nothing at psychopat.org Thu Aug 28 14:57:31 2003
31898 From: nothing at psychopat.org (Marc-Andre A. Fuentes)
31899 Date: Sat Oct 23 23:10:03 2004
31900 Subject: [IRCServices Coding] BUG Report
31901 Message-ID: <001501c36daf$c8cba700$0101a8c0@house>
31903 We're having a small problem with suspended channel.
31905 we suspended channel #kavala, and someone has identified itself has the founder and apply a DROP to the channel.
31906 then we got a panic from the services and... crash.
31908 Also with suspended nick , when the suspencion expire, the services crash
31911 ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
31916 -------------- next part --------------
31917 An HTML attachment was scrubbed...
31918 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030828/1f31ccf5/attachment-0002.html
31919 From Craig at chatspike.net Thu Aug 28 15:24:36 2003
31920 From: Craig at chatspike.net (Craig McLure)
31921 Date: Sat Oct 23 23:10:03 2004
31922 Subject: [IRCServices Coding] BUG Report
31923 Message-ID: <20030828222401.JVQE12036.mta4-svc.business.ntl.com@i-br0ked-it>
31925 hmm.. what OS, compiler version etc are you using?
31927 after a test, i got the following:
31929 /cs id #abc 00376370
31930 -ChanServ- Channel #abc is suspended and may not be used or identified for.
31933 [23:20] -ChanServ- Channel is suspended and may not be used or identified for.
31935 only prob i got was it missed the channel name in the second message :)
31938 /****************************************
31939 * Craig "FrostyCoolSlug" McLure
31940 ************* - SpamBox - **************
31941 * InspIRCd - http://www.inspircd.org
31942 * ChatSpike - http://www.chatspike.net
31943 * WinBot - http://www.winbot.co.uk
31944 ****************************************/
31946 /****************************************
31947 * From - Marc-Andre A. Fuentes <nothing@psychopat.org>
31948 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
31949 * Sent - 2003-08-28 @ 18:00:00
31950 * Subject - [IRCServices Coding] BUG Report
31951 ****************************************/
31953 /****** - Begin Original Message - ******/
31955 >We're having a small problem with suspended channel.
31957 >we suspended channel #kavala, and someone has identified itself has the founder and apply a DROP to the channel.
31958 >then we got a panic from the services and... crash.
31960 >Also with suspended nick , when the suspencion expire, the services crash
31963 >ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
31968 >------------------------------------------------------------------
31969 >To unsubscribe or change your subscription options, visit:
31970 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
31972 /******* - End Original Message - *******/
31977 From saturn at jetirc.net Thu Aug 28 17:13:48 2003
31978 From: saturn at jetirc.net (Saturn)
31979 Date: Sat Oct 23 23:10:03 2004
31980 Subject: [IRCServices Coding] AKill suggestion
31981 References: <2C31F186-CDEE-11D7-979C-0003938D6866@mac.com>
31982 Message-ID: <009001c36dc2$64b56b80$6401a8c0@turby>
31984 Would it be possible to have it announce to the user when they are akilled,
31985 either the expiry date and time, or "Expires in 3days, 4hours, 6minutes" or
31986 something similar. I find that usually we just have to do 24hour bans, but
31987 the user has no way to know when the ban was set, and when it expires...
31989 Just an idea... I now await the half dozen people who will proceed to tell
31990 me how stupid my idea is....
31997 From playa at dreamchat.org Thu Aug 28 20:46:19 2003
31998 From: playa at dreamchat.org (playa)
31999 Date: Sat Oct 23 23:10:03 2004
32000 Subject: [IRCServices Coding] Yet, another great suggestion
32001 In-Reply-To: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
32002 References: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
32003 Message-ID: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
32005 Is this /time command only supposed to work via RAW? Cause when i type
32006 /time services.dreamchat.org i get No Such User, but if i do /raw time
32007 services.dreamchat.org, it works. Just wondering if its just me, or if
32008 its supposed to be that way.
32010 > Please dont post to both the services main list, and the services coding
32011 > list. Choose one, or the other, especially concidering i dont think this
32012 > is a great suggestion either..
32014 > /time services.chatspike.net
32015 > [22:28] ??? Date / time at services.chatspike.net- Thu Aug 28 17:28:57
32020 > /****************************************
32021 > * Craig "FrostyCoolSlug" McLure
32022 > ************* - SpamBox - **************
32023 > * InspIRCd - http://www.inspircd.org
32024 > * ChatSpike - http://www.chatspike.net
32025 > * WinBot - http://www.winbot.co.uk
32026 > ****************************************/
32028 > /****************************************
32029 > * From - us44ever . <us44ever@hotmail.com>
32030 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
32031 > * Sent - 2003-08-28 @ 16:45:00
32032 > * Subject - [IRCServices Coding] Yet, another great suggestion
32033 > ****************************************/
32035 > /****** - Begin Original Message - ******/
32039 >>it would be really great to add another new line to the "/nickserv info"
32040 >>command, for example, when some one types: "/nickserv info nick", the
32041 >>following will be shown:
32043 >>***************************
32045 >>-NickServ- nick is hello world
32047 >>-NickServ- Is online from: ~test@just.a.test.co.za
32049 >>-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
32051 >>-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
32053 >>-NickServ- Last quit message: anythinggggg
32055 >>-NickServ- Options: Kill protection, Security
32057 >>***************************
32059 >>the new line I'm suggesting is something like:
32061 >>***************************
32062 >>-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
32063 >>***************************
32065 >>This will help our users to compare the time that user was last seen and
32067 >>time right now *it's very important, many many of our users asked us for
32068 >>this option*, also it would even be more great to show how long last time
32069 >>the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003
32071 >>(last seen time was before: 10 days, 3hours and 24 sec ago).
32073 >>Note that I saw both of these features, in other services I don't
32075 >>there names (but they aren't as stable as ircservices5) (it was something
32076 >>like ptlink services, and magik II)
32078 >>That's all, I would really like to see it on the next version (or if you
32080 >>show me how to do it, as I'm not a programmer)
32082 >>Many thanks to all of who developed IRCservices ...etc ...etc ...etc
32087 >>_________________________________________________________________
32088 >>Get MSN 8 and enjoy automatic e-mail virus protection.
32089 >>http://join.msn.com/?page=features/virus
32091 >>------------------------------------------------------------------
32092 >>To unsubscribe or change your subscription options, visit:
32093 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
32095 > /******* - End Original Message - *******/
32099 > ------------------------------------------------------------------
32100 > To unsubscribe or change your subscription options, visit:
32101 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
32108 Network Founder/CEO
32109 DreamChat IRC Network - irc.dreamchat.org
32110 http://www.dreamchat.org
32113 From quension at mac.com Thu Aug 28 21:13:48 2003
32114 From: quension at mac.com (Trevor Talbot)
32115 Date: Sat Oct 23 23:10:03 2004
32116 Subject: [IRCServices Coding] Yet, another great suggestion
32117 In-Reply-To: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
32118 Message-ID: <0F823090-D9D7-11D7-8513-0003938D6866@mac.com>
32120 On Thursday, Aug 28, 2003, at 20:46 US/Pacific, playa wrote:
32122 > Is this /time command only supposed to work via RAW? Cause when i
32123 > type /time services.dreamchat.org i get No Such User, but if i do /raw
32124 > time services.dreamchat.org, it works. Just wondering if its just me,
32125 > or if its supposed to be that way.
32127 That's a client thing. Some clients might alias /time as a CTCP TIME
32128 for a specific user, or similar.
32133 From r-krisztian at softhome.net Thu Aug 28 22:12:51 2003
32134 From: r-krisztian at softhome.net (Krisztian Romek)
32135 Date: Sat Oct 23 23:10:03 2004
32136 Subject: [IRCServices Coding] Yet, another great suggestion
32137 In-Reply-To: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
32138 References: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
32139 <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
32140 Message-ID: <200308290713.29423.r-krisztian@softhome.net>
32142 > Is this /time command only supposed to work via RAW? Cause when i type
32143 > /time services.dreamchat.org i get No Such User, but if i do /raw time
32144 > services.dreamchat.org, it works. Just wondering if its just me, or if
32145 > its supposed to be that way.
32147 Some clients use stupid aliases for CTCP commands, for example:
32149 /version <nick> = /CTCP <nick> VERSION,
32150 /time <nick> = /CTCP <nick> TIME,
32151 /finger <nick> = /CTCP <nick> TIME
32153 This is why nothing works the way you expected.
32157 r-krisztian@softhome.net
32160 From us44ever at hotmail.com Fri Aug 29 13:02:19 2003
32161 From: us44ever at hotmail.com (us44ever .)
32162 Date: Sat Oct 23 23:10:03 2004
32163 Subject: [IRCServices Coding] AKill suggestion
32164 Message-ID: <Sea1-F108cM3oryKFRJ0000eb75@hotmail.com>
32166 Pretty good idea, specially is it would be implemented as an option (because
32167 some admins might won't like the idea of displaying the time of when the
32168 akill will expire to the user who has been akilled).
32170 _________________________________________________________________
32171 Help protect your PC: Get a free online virus scan at McAfee.com.
32172 http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
32175 From us44ever at hotmail.com Fri Aug 29 13:09:51 2003
32176 From: us44ever at hotmail.com (us44ever .)
32177 Date: Sat Oct 23 23:10:03 2004
32178 Subject: [IRCServices Coding] Yet, another great suggestion
32179 Message-ID: <Sea1-F127z33hqSnMGE000094b3@hotmail.com>
32182 Since most people want to see this feature(s) in the next version, it would
32183 be great to implement it as an optional feature , where it can be disabled
32184 from the .conf file(s) or enable it easily. I don't think that there is
32185 anything that the authors will lose if this feature can be added, in fact,
32186 it will add another nice feature to the features list of IRCservices5.
32188 _________________________________________________________________
32189 Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
32190 using MSN Messenger http://entertainment.msn.com/imastar
32193 From Craig at chatspike.net Fri Aug 29 13:41:59 2003
32194 From: Craig at chatspike.net (Craig McLure)
32195 Date: Sat Oct 23 23:10:03 2004
32196 Subject: [IRCServices Coding] Yet, another great suggestion
32197 Message-ID: <20030829204143.NNNT26404.mta1-svc.business.ntl.com@i-br0ked-it>
32199 I'll ask again.. can you please stop posting to both the IRCServices mailing list, and the IRCd coding mailing list, getting your mail 2ce is beginning to annoy me.
32201 And i'll Quote Elijah:
32203 "Except it's already been said in the FAQ that it's not going to happen, and
32204 if that made it into the FAQ it would seem the answer is frequently going to
32208 /****************************************
32209 * Craig "FrostyCoolSlug" McLure
32210 ************* - SpamBox - **************
32211 * InspIRCd - http://www.inspircd.org
32212 * ChatSpike - http://www.chatspike.net
32213 * WinBot - http://www.winbot.co.uk
32214 ****************************************/
32216 /****************************************
32217 * From - us44ever . <us44ever@hotmail.com>
32218 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
32219 * Sent - 2003-08-29 @ 20:09:00
32220 * Subject - Re: [IRCServices Coding] Yet, another great suggestion
32221 ****************************************/
32223 /****** - Begin Original Message - ******/
32225 >Since most people want to see this feature(s) in the next version, it would
32226 >be great to implement it as an optional feature , where it can be disabled
32227 >from the .conf file(s) or enable it easily. I don't think that there is
32228 >anything that the authors will lose if this feature can be added, in fact,
32229 >it will add another nice feature to the features list of IRCservices5.
32231 >_________________________________________________________________
32232 >Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
32233 >using MSN Messenger http://entertainment.msn.com/imastar
32235 >------------------------------------------------------------------
32236 >To unsubscribe or change your subscription options, visit:
32237 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
32240 /******* - End Original Message - *******/
32245 From Craig at chatspike.net Fri Aug 29 13:43:24 2003
32246 From: Craig at chatspike.net (Craig McLure)
32247 Date: Sat Oct 23 23:10:03 2004
32248 Subject: [IRCServices Coding] AKill suggestion
32249 Message-ID: <20030829204311.GHCL29825.mta5-svc.business.ntl.com@i-br0ked-it>
32251 its a stupid idea!!! :p
32253 j/k.. I think its a great idea.. i'd rather have services telling users when their akills expire, than them spamming my mailbox with 'when does my akill expire?' every 20mins :p
32255 /****************************************
32256 * Craig "FrostyCoolSlug" McLure
32257 ************* - SpamBox - **************
32258 * InspIRCd - http://www.inspircd.org
32259 * ChatSpike - http://www.chatspike.net
32260 * WinBot - http://www.winbot.co.uk
32261 ****************************************/
32263 /****************************************
32264 * From - Saturn <saturn@jetirc.net>
32265 * To - IRC Services Coding Mailing List <ircservices-coding@ircservices.za.net>
32266 * Sent - 2003-08-28 @ 17:13:00
32267 * Subject - [IRCServices Coding] AKill suggestion
32268 ****************************************/
32270 /****** - Begin Original Message - ******/
32272 >Would it be possible to have it announce to the user when they are akilled,
32273 >either the expiry date and time, or "Expires in 3days, 4hours, 6minutes" or
32274 >something similar. I find that usually we just have to do 24hour bans, but
32275 >the user has no way to know when the ban was set, and when it expires...
32277 >Just an idea... I now await the half dozen people who will proceed to tell
32278 >me how stupid my idea is....
32284 >------------------------------------------------------------------
32285 >To unsubscribe or change your subscription options, visit:
32286 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
32288 /******* - End Original Message - *******/
32293 From andrewk at isdial.net Tue Aug 26 02:43:45 2003
32294 From: andrewk at isdial.net (Andrew Kempe)
32295 Date: Sat Oct 23 23:10:03 2004
32296 Subject: [IRCServices Coding] test
32297 Message-ID: <005801c36bb6$85bbc080$1f0912ac@espotting.com>
32301 From us44ever at hotmail.com Thu Aug 28 09:45:48 2003
32302 From: us44ever at hotmail.com (us44ever .)
32303 Date: Sat Oct 23 23:10:03 2004
32304 Subject: [IRCServices Coding] Yet, another great suggestion
32305 Message-ID: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
32309 it would be really great to add another new line to the "/nickserv info"
32310 command, for example, when some one types: "/nickserv info nick", the
32311 following will be shown:
32313 ***************************
32315 -NickServ- nick is hello world
32317 -NickServ- Is online from: ~test@just.a.test.co.za
32319 -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
32321 -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
32323 -NickServ- Last quit message: anythinggggg
32325 -NickServ- Options: Kill protection, Security
32327 ***************************
32329 the new line I'm suggesting is something like:
32331 ***************************
32332 -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
32333 ***************************
32335 This will help our users to compare the time that user was last seen and the
32336 time right now *it's very important, many many of our users asked us for
32337 this option*, also it would even be more great to show how long last time
32338 the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003 GMT
32339 (last seen time was before: 10 days, 3hours and 24 sec ago).
32341 Note that I saw both of these features, in other services I don't remember
32342 there names (but they aren't as stable as ircservices5) (it was something
32343 like ptlink services, and magik II)
32345 That's all, I would really like to see it on the next version (or if you can
32346 show me how to do it, as I'm not a programmer)
32348 Many thanks to all of who developed IRCservices ...etc ...etc ...etc
32353 _________________________________________________________________
32354 Get MSN 8 and enjoy automatic e-mail virus protection.
32355 http://join.msn.com/?page=features/virus
32358 From aragon at phat.za.net Thu Aug 28 11:36:22 2003
32359 From: aragon at phat.za.net (Aragon Gouveia)
32360 Date: Sat Oct 23 23:10:03 2004
32361 Subject: [IRCServices Coding] Yet, another great suggestion
32362 In-Reply-To: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
32363 References: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
32364 Message-ID: <20030828183615.GB32204@phat.za.net>
32366 Or how about rather letting users decide what timezone they're in and
32367 services outputs all timestamps in their local time?
32370 | By us44ever . <us44ever@hotmail.com>
32371 | [ 2003-08-28 18:45 +0200 ]
32374 > it would be really great to add another new line to the "/nickserv info"
32375 > command, for example, when some one types: "/nickserv info nick", the
32376 > following will be shown:
32378 > ***************************
32380 > -NickServ- nick is hello world
32382 > -NickServ- Is online from: ~test@just.a.test.co.za
32384 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
32386 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
32388 > -NickServ- Last quit message: anythinggggg
32390 > -NickServ- Options: Kill protection, Security
32392 > ***************************
32394 > the new line I'm suggesting is something like:
32396 > ***************************
32397 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
32398 > ***************************
32400 > This will help our users to compare the time that user was last seen and
32401 > the time right now *it's very important, many many of our users asked us
32402 > for this option*, also it would even be more great to show how long last
32403 > time the user was seen (some thing like: Last seen time: Aug 28 15:51:14
32404 > 2003 GMT (last seen time was before: 10 days, 3hours and 24 sec ago).
32406 > Note that I saw both of these features, in other services I don't remember
32407 > there names (but they aren't as stable as ircservices5) (it was something
32408 > like ptlink services, and magik II)
32410 > That's all, I would really like to see it on the next version (or if you
32411 > can show me how to do it, as I'm not a programmer)
32413 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
32418 > _________________________________________________________________
32419 > Get MSN 8 and enjoy automatic e-mail virus protection.
32420 > http://join.msn.com/?page=features/virus
32422 > ------------------------------------------------------------------
32423 > To unsubscribe or change your subscription options, visit:
32424 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
32426 From saturn at jetirc.net Thu Aug 28 11:39:41 2003
32427 From: saturn at jetirc.net (Saturn)
32428 Date: Sat Oct 23 23:10:03 2004
32429 Subject: [IRCServices Coding] Yet, another great suggestion
32430 References: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
32431 <20030828183615.GB32204@phat.za.net>
32432 Message-ID: <003201c36d93$abf77fd0$6401a8c0@turby>
32434 Oooo now I like that option... have it default to a default timezone, set in
32435 the conf file, and give them the option of SETting a different UTC code
32436 (have it as GMT + or - x wheer x is the offset from UTC)... It may not
32437 sound liek much, but I bet people will use it, and what's more, it IS useful
32438 information, especially on international servers like mine.. we have people
32439 from all over the place, and we keep services set on Pacific time... but for
32440 those in, say, Belgium... that's not very helpful
32442 ----- Original Message -----
32443 From: "Aragon Gouveia" <aragon@phat.za.net>
32444 To: <ircservices-coding@ircservices.za.net>
32445 Sent: Thursday, August 28, 2003 11:36 AM
32446 Subject: Re: [IRCServices Coding] Yet, another great suggestion
32449 Or how about rather letting users decide what timezone they're in and
32450 services outputs all timestamps in their local time?
32453 | By us44ever . <us44ever@hotmail.com>
32454 | [ 2003-08-28 18:45 +0200 ]
32457 > it would be really great to add another new line to the "/nickserv info"
32458 > command, for example, when some one types: "/nickserv info nick", the
32459 > following will be shown:
32461 > ***************************
32463 > -NickServ- nick is hello world
32465 > -NickServ- Is online from: ~test@just.a.test.co.za
32467 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
32469 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
32471 > -NickServ- Last quit message: anythinggggg
32473 > -NickServ- Options: Kill protection, Security
32475 > ***************************
32477 > the new line I'm suggesting is something like:
32479 > ***************************
32480 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
32481 > ***************************
32483 > This will help our users to compare the time that user was last seen and
32484 > the time right now *it's very important, many many of our users asked us
32485 > for this option*, also it would even be more great to show how long last
32486 > time the user was seen (some thing like: Last seen time: Aug 28 15:51:14
32487 > 2003 GMT (last seen time was before: 10 days, 3hours and 24 sec ago).
32489 > Note that I saw both of these features, in other services I don't remember
32490 > there names (but they aren't as stable as ircservices5) (it was something
32491 > like ptlink services, and magik II)
32493 > That's all, I would really like to see it on the next version (or if you
32494 > can show me how to do it, as I'm not a programmer)
32496 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
32501 > _________________________________________________________________
32502 > Get MSN 8 and enjoy automatic e-mail virus protection.
32503 > http://join.msn.com/?page=features/virus
32505 > ------------------------------------------------------------------
32506 > To unsubscribe or change your subscription options, visit:
32507 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
32508 ------------------------------------------------------------------
32509 To unsubscribe or change your subscription options, visit:
32510 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
32514 From Craig at chatspike.net Thu Aug 28 14:29:54 2003
32515 From: Craig at chatspike.net (Craig McLure)
32516 Date: Sat Oct 23 23:10:03 2004
32517 Subject: [IRCServices Coding] Yet, another great suggestion
32518 Message-ID: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
32520 Please dont post to both the services main list, and the services coding list. Choose one, or the other, especially concidering i dont think this is a great suggestion either..
32522 /time services.chatspike.net
32523 [22:28]
\95\95\95 Date / time at services.chatspike.net- Thu Aug 28 17:28:57 2003 EDT
32527 /****************************************
32528 * Craig "FrostyCoolSlug" McLure
32529 ************* - SpamBox - **************
32530 * InspIRCd - http://www.inspircd.org
32531 * ChatSpike - http://www.chatspike.net
32532 * WinBot - http://www.winbot.co.uk
32533 ****************************************/
32535 /****************************************
32536 * From - us44ever . <us44ever@hotmail.com>
32537 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
32538 * Sent - 2003-08-28 @ 16:45:00
32539 * Subject - [IRCServices Coding] Yet, another great suggestion
32540 ****************************************/
32542 /****** - Begin Original Message - ******/
32546 >it would be really great to add another new line to the "/nickserv info"
32547 >command, for example, when some one types: "/nickserv info nick", the
32548 >following will be shown:
32550 >***************************
32552 >-NickServ- nick is hello world
32554 >-NickServ- Is online from: ~test@just.a.test.co.za
32556 >-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
32558 >-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
32560 >-NickServ- Last quit message: anythinggggg
32562 >-NickServ- Options: Kill protection, Security
32564 >***************************
32566 >the new line I'm suggesting is something like:
32568 >***************************
32569 >-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
32570 >***************************
32572 >This will help our users to compare the time that user was last seen and the
32573 >time right now *it's very important, many many of our users asked us for
32574 >this option*, also it would even be more great to show how long last time
32575 >the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003 GMT
32576 >(last seen time was before: 10 days, 3hours and 24 sec ago).
32578 >Note that I saw both of these features, in other services I don't remember
32579 >there names (but they aren't as stable as ircservices5) (it was something
32580 >like ptlink services, and magik II)
32582 >That's all, I would really like to see it on the next version (or if you can
32583 >show me how to do it, as I'm not a programmer)
32585 >Many thanks to all of who developed IRCservices ...etc ...etc ...etc
32590 >_________________________________________________________________
32591 >Get MSN 8 and enjoy automatic e-mail virus protection.
32592 >http://join.msn.com/?page=features/virus
32594 >------------------------------------------------------------------
32595 >To unsubscribe or change your subscription options, visit:
32596 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
32598 /******* - End Original Message - *******/
32603 From nothing at psychopat.org Thu Aug 28 14:57:31 2003
32604 From: nothing at psychopat.org (Marc-Andre A. Fuentes)
32605 Date: Sat Oct 23 23:10:03 2004
32606 Subject: [IRCServices Coding] BUG Report
32607 Message-ID: <001501c36daf$c8cba700$0101a8c0@house>
32609 We're having a small problem with suspended channel.
32611 we suspended channel #kavala, and someone has identified itself has the founder and apply a DROP to the channel.
32612 then we got a panic from the services and... crash.
32614 Also with suspended nick , when the suspencion expire, the services crash
32617 ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
32622 -------------- next part --------------
32623 An HTML attachment was scrubbed...
32624 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030828/1f31ccf5/attachment-0002.htm
32625 From Craig at chatspike.net Thu Aug 28 15:24:36 2003
32626 From: Craig at chatspike.net (Craig McLure)
32627 Date: Sat Oct 23 23:10:03 2004
32628 Subject: [IRCServices Coding] BUG Report
32629 Message-ID: <20030828222401.JVQE12036.mta4-svc.business.ntl.com@i-br0ked-it>
32631 hmm.. what OS, compiler version etc are you using?
32633 after a test, i got the following:
32635 /cs id #abc 00376370
32636 -ChanServ- Channel #abc is suspended and may not be used or identified for.
32639 [23:20] -ChanServ- Channel is suspended and may not be used or identified for.
32641 only prob i got was it missed the channel name in the second message :)
32644 /****************************************
32645 * Craig "FrostyCoolSlug" McLure
32646 ************* - SpamBox - **************
32647 * InspIRCd - http://www.inspircd.org
32648 * ChatSpike - http://www.chatspike.net
32649 * WinBot - http://www.winbot.co.uk
32650 ****************************************/
32652 /****************************************
32653 * From - Marc-Andre A. Fuentes <nothing@psychopat.org>
32654 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
32655 * Sent - 2003-08-28 @ 18:00:00
32656 * Subject - [IRCServices Coding] BUG Report
32657 ****************************************/
32659 /****** - Begin Original Message - ******/
32661 >We're having a small problem with suspended channel.
32663 >we suspended channel #kavala, and someone has identified itself has the founder and apply a DROP to the channel.
32664 >then we got a panic from the services and... crash.
32666 >Also with suspended nick , when the suspencion expire, the services crash
32669 >ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
32674 >------------------------------------------------------------------
32675 >To unsubscribe or change your subscription options, visit:
32676 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
32678 /******* - End Original Message - *******/
32683 From saturn at jetirc.net Thu Aug 28 17:13:48 2003
32684 From: saturn at jetirc.net (Saturn)
32685 Date: Sat Oct 23 23:10:03 2004
32686 Subject: [IRCServices Coding] AKill suggestion
32687 References: <2C31F186-CDEE-11D7-979C-0003938D6866@mac.com>
32688 Message-ID: <009001c36dc2$64b56b80$6401a8c0@turby>
32690 Would it be possible to have it announce to the user when they are akilled,
32691 either the expiry date and time, or "Expires in 3days, 4hours, 6minutes" or
32692 something similar. I find that usually we just have to do 24hour bans, but
32693 the user has no way to know when the ban was set, and when it expires...
32695 Just an idea... I now await the half dozen people who will proceed to tell
32696 me how stupid my idea is....
32703 From playa at dreamchat.org Thu Aug 28 20:46:19 2003
32704 From: playa at dreamchat.org (playa)
32705 Date: Sat Oct 23 23:10:03 2004
32706 Subject: [IRCServices Coding] Yet, another great suggestion
32707 In-Reply-To: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
32708 References: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
32709 Message-ID: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
32711 Is this /time command only supposed to work via RAW? Cause when i type
32712 /time services.dreamchat.org i get No Such User, but if i do /raw time
32713 services.dreamchat.org, it works. Just wondering if its just me, or if
32714 its supposed to be that way.
32716 > Please dont post to both the services main list, and the services coding
32717 > list. Choose one, or the other, especially concidering i dont think this
32718 > is a great suggestion either..
32720 > /time services.chatspike.net
32721 > [22:28] ??? Date / time at services.chatspike.net- Thu Aug 28 17:28:57
32726 > /****************************************
32727 > * Craig "FrostyCoolSlug" McLure
32728 > ************* - SpamBox - **************
32729 > * InspIRCd - http://www.inspircd.org
32730 > * ChatSpike - http://www.chatspike.net
32731 > * WinBot - http://www.winbot.co.uk
32732 > ****************************************/
32734 > /****************************************
32735 > * From - us44ever . <us44ever@hotmail.com>
32736 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
32737 > * Sent - 2003-08-28 @ 16:45:00
32738 > * Subject - [IRCServices Coding] Yet, another great suggestion
32739 > ****************************************/
32741 > /****** - Begin Original Message - ******/
32745 >>it would be really great to add another new line to the "/nickserv info"
32746 >>command, for example, when some one types: "/nickserv info nick", the
32747 >>following will be shown:
32749 >>***************************
32751 >>-NickServ- nick is hello world
32753 >>-NickServ- Is online from: ~test@just.a.test.co.za
32755 >>-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
32757 >>-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
32759 >>-NickServ- Last quit message: anythinggggg
32761 >>-NickServ- Options: Kill protection, Security
32763 >>***************************
32765 >>the new line I'm suggesting is something like:
32767 >>***************************
32768 >>-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
32769 >>***************************
32771 >>This will help our users to compare the time that user was last seen and
32773 >>time right now *it's very important, many many of our users asked us for
32774 >>this option*, also it would even be more great to show how long last time
32775 >>the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003
32777 >>(last seen time was before: 10 days, 3hours and 24 sec ago).
32779 >>Note that I saw both of these features, in other services I don't
32781 >>there names (but they aren't as stable as ircservices5) (it was something
32782 >>like ptlink services, and magik II)
32784 >>That's all, I would really like to see it on the next version (or if you
32786 >>show me how to do it, as I'm not a programmer)
32788 >>Many thanks to all of who developed IRCservices ...etc ...etc ...etc
32793 >>_________________________________________________________________
32794 >>Get MSN 8 and enjoy automatic e-mail virus protection.
32795 >>http://join.msn.com/?page=features/virus
32797 >>------------------------------------------------------------------
32798 >>To unsubscribe or change your subscription options, visit:
32799 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
32801 > /******* - End Original Message - *******/
32805 > ------------------------------------------------------------------
32806 > To unsubscribe or change your subscription options, visit:
32807 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
32814 Network Founder/CEO
32815 DreamChat IRC Network - irc.dreamchat.org
32816 http://www.dreamchat.org
32819 From quension at mac.com Thu Aug 28 21:13:48 2003
32820 From: quension at mac.com (Trevor Talbot)
32821 Date: Sat Oct 23 23:10:03 2004
32822 Subject: [IRCServices Coding] Yet, another great suggestion
32823 In-Reply-To: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
32824 Message-ID: <0F823090-D9D7-11D7-8513-0003938D6866@mac.com>
32826 On Thursday, Aug 28, 2003, at 20:46 US/Pacific, playa wrote:
32828 > Is this /time command only supposed to work via RAW? Cause when i
32829 > type /time services.dreamchat.org i get No Such User, but if i do /raw
32830 > time services.dreamchat.org, it works. Just wondering if its just me,
32831 > or if its supposed to be that way.
32833 That's a client thing. Some clients might alias /time as a CTCP TIME
32834 for a specific user, or similar.
32839 From r-krisztian at softhome.net Thu Aug 28 22:12:51 2003
32840 From: r-krisztian at softhome.net (Krisztian Romek)
32841 Date: Sat Oct 23 23:10:03 2004
32842 Subject: [IRCServices Coding] Yet, another great suggestion
32843 In-Reply-To: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
32844 References: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
32845 <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
32846 Message-ID: <200308290713.29423.r-krisztian@softhome.net>
32848 > Is this /time command only supposed to work via RAW? Cause when i type
32849 > /time services.dreamchat.org i get No Such User, but if i do /raw time
32850 > services.dreamchat.org, it works. Just wondering if its just me, or if
32851 > its supposed to be that way.
32853 Some clients use stupid aliases for CTCP commands, for example:
32855 /version <nick> = /CTCP <nick> VERSION,
32856 /time <nick> = /CTCP <nick> TIME,
32857 /finger <nick> = /CTCP <nick> TIME
32859 This is why nothing works the way you expected.
32863 r-krisztian@softhome.net
32866 From us44ever at hotmail.com Fri Aug 29 13:02:19 2003
32867 From: us44ever at hotmail.com (us44ever .)
32868 Date: Sat Oct 23 23:10:03 2004
32869 Subject: [IRCServices Coding] AKill suggestion
32870 Message-ID: <Sea1-F108cM3oryKFRJ0000eb75@hotmail.com>
32872 Pretty good idea, specially is it would be implemented as an option (because
32873 some admins might won't like the idea of displaying the time of when the
32874 akill will expire to the user who has been akilled).
32876 _________________________________________________________________
32877 Help protect your PC: Get a free online virus scan at McAfee.com.
32878 http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
32881 From us44ever at hotmail.com Fri Aug 29 13:09:51 2003
32882 From: us44ever at hotmail.com (us44ever .)
32883 Date: Sat Oct 23 23:10:03 2004
32884 Subject: [IRCServices Coding] Yet, another great suggestion
32885 Message-ID: <Sea1-F127z33hqSnMGE000094b3@hotmail.com>
32888 Since most people want to see this feature(s) in the next version, it would
32889 be great to implement it as an optional feature , where it can be disabled
32890 from the .conf file(s) or enable it easily. I don't think that there is
32891 anything that the authors will lose if this feature can be added, in fact,
32892 it will add another nice feature to the features list of IRCservices5.
32894 _________________________________________________________________
32895 Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
32896 using MSN Messenger http://entertainment.msn.com/imastar
32899 From Craig at chatspike.net Fri Aug 29 13:41:59 2003
32900 From: Craig at chatspike.net (Craig McLure)
32901 Date: Sat Oct 23 23:10:03 2004
32902 Subject: [IRCServices Coding] Yet, another great suggestion
32903 Message-ID: <20030829204143.NNNT26404.mta1-svc.business.ntl.com@i-br0ked-it>
32905 I'll ask again.. can you please stop posting to both the IRCServices mailing list, and the IRCd coding mailing list, getting your mail 2ce is beginning to annoy me.
32907 And i'll Quote Elijah:
32909 "Except it's already been said in the FAQ that it's not going to happen, and
32910 if that made it into the FAQ it would seem the answer is frequently going to
32914 /****************************************
32915 * Craig "FrostyCoolSlug" McLure
32916 ************* - SpamBox - **************
32917 * InspIRCd - http://www.inspircd.org
32918 * ChatSpike - http://www.chatspike.net
32919 * WinBot - http://www.winbot.co.uk
32920 ****************************************/
32922 /****************************************
32923 * From - us44ever . <us44ever@hotmail.com>
32924 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
32925 * Sent - 2003-08-29 @ 20:09:00
32926 * Subject - Re: [IRCServices Coding] Yet, another great suggestion
32927 ****************************************/
32929 /****** - Begin Original Message - ******/
32931 >Since most people want to see this feature(s) in the next version, it would
32932 >be great to implement it as an optional feature , where it can be disabled
32933 >from the .conf file(s) or enable it easily. I don't think that there is
32934 >anything that the authors will lose if this feature can be added, in fact,
32935 >it will add another nice feature to the features list of IRCservices5.
32937 >_________________________________________________________________
32938 >Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
32939 >using MSN Messenger http://entertainment.msn.com/imastar
32941 >------------------------------------------------------------------
32942 >To unsubscribe or change your subscription options, visit:
32943 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
32946 /******* - End Original Message - *******/
32951 From Craig at chatspike.net Fri Aug 29 13:43:24 2003
32952 From: Craig at chatspike.net (Craig McLure)
32953 Date: Sat Oct 23 23:10:03 2004
32954 Subject: [IRCServices Coding] AKill suggestion
32955 Message-ID: <20030829204311.GHCL29825.mta5-svc.business.ntl.com@i-br0ked-it>
32957 its a stupid idea!!! :p
32959 j/k.. I think its a great idea.. i'd rather have services telling users when their akills expire, than them spamming my mailbox with 'when does my akill expire?' every 20mins :p
32961 /****************************************
32962 * Craig "FrostyCoolSlug" McLure
32963 ************* - SpamBox - **************
32964 * InspIRCd - http://www.inspircd.org
32965 * ChatSpike - http://www.chatspike.net
32966 * WinBot - http://www.winbot.co.uk
32967 ****************************************/
32969 /****************************************
32970 * From - Saturn <saturn@jetirc.net>
32971 * To - IRC Services Coding Mailing List <ircservices-coding@ircservices.za.net>
32972 * Sent - 2003-08-28 @ 17:13:00
32973 * Subject - [IRCServices Coding] AKill suggestion
32974 ****************************************/
32976 /****** - Begin Original Message - ******/
32978 >Would it be possible to have it announce to the user when they are akilled,
32979 >either the expiry date and time, or "Expires in 3days, 4hours, 6minutes" or
32980 >something similar. I find that usually we just have to do 24hour bans, but
32981 >the user has no way to know when the ban was set, and when it expires...
32983 >Just an idea... I now await the half dozen people who will proceed to tell
32984 >me how stupid my idea is....
32990 >------------------------------------------------------------------
32991 >To unsubscribe or change your subscription options, visit:
32992 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
32994 /******* - End Original Message - *******/
32999 From admin at nevernet.net Fri Aug 29 13:48:01 2003
33000 From: admin at nevernet.net (Elijah)
33001 Date: Sat Oct 23 23:10:03 2004
33002 Subject: [IRCServices Coding] Yet, another great suggestion
33003 In-Reply-To: <20030829204143.NNNT26404.mta1-svc.business.ntl.com@i-br0ked-it>
33004 Message-ID: <008f01c36e6e$83158770$436a3a44@slytherin>
33008 -----Original Message-----
33009 From: ircservices-coding-bounces@ircservices.za.net
33010 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of Craig
33012 Sent: Friday, August 29, 2003 4:41 PM
33013 To: IRC Services Coding Mailing List
33014 Subject: Re: Re: [IRCServices Coding] Yet, another great suggestion
33017 I'll ask again.. can you please stop posting to both the IRCServices mailing
33018 list, and the IRCd coding mailing list, getting your mail 2ce is beginning
33021 And i'll Quote Elijah:
33023 "Except it's already been said in the FAQ that it's not going to happen, and
33024 if that made it into the FAQ it would seem the answer is frequently going to
33029 From us44ever at hotmail.com Fri Aug 29 16:59:31 2003
33030 From: us44ever at hotmail.com (us44ever .)
33031 Date: Sat Oct 23 23:10:03 2004
33032 Subject: [IRCServices Coding] Yet, another great suggestion
33033 Message-ID: <Sea1-F30z1oyZF58m3O00035b82@hotmail.com>
33035 woops, ok sorry I thought the two e-mails is completely different.
33038 >From: "Craig McLure" <Craig@chatspike.net>
33039 >Reply-To: IRC Services Coding Mailing List
33040 ><ircservices-coding@ircservices.za.net>
33041 >To: IRC Services Coding Mailing List
33042 ><ircservices-coding@ircservices.za.net>
33043 >Subject: Re: Re: [IRCServices Coding] Yet, another great suggestion
33044 >Date: Fri, 29 Aug 2003 21:41:23 +0000
33046 >I'll ask again.. can you please stop posting to both the IRCServices
33047 >mailing list, and the IRCd coding mailing list, getting your mail 2ce is
33048 >beginning to annoy me.
33050 >And i'll Quote Elijah:
33052 >"Except it's already been said in the FAQ that it's not going to happen,
33054 >if that made it into the FAQ it would seem the answer is frequently going
33059 >/****************************************
33060 > * Craig "FrostyCoolSlug" McLure
33061 > ************* - SpamBox - **************
33062 > * InspIRCd - http://www.inspircd.org
33063 > * ChatSpike - http://www.chatspike.net
33064 > * WinBot - http://www.winbot.co.uk
33065 > ****************************************/
33067 >/****************************************
33068 > * From - us44ever . <us44ever@hotmail.com>
33069 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
33070 > * Sent - 2003-08-29 @ 20:09:00
33071 > * Subject - Re: [IRCServices Coding] Yet, another great suggestion
33072 > ****************************************/
33074 >/****** - Begin Original Message - ******/
33076 > >Since most people want to see this feature(s) in the next version, it
33078 > >be great to implement it as an optional feature , where it can be
33080 > >from the .conf file(s) or enable it easily. I don't think that there is
33081 > >anything that the authors will lose if this feature can be added, in
33083 > >it will add another nice feature to the features list of IRCservices5.
33085 > >_________________________________________________________________
33086 > >Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
33087 > >using MSN Messenger http://entertainment.msn.com/imastar
33089 > >------------------------------------------------------------------
33090 > >To unsubscribe or change your subscription options, visit:
33091 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
33094 >/******* - End Original Message - *******/
33098 >------------------------------------------------------------------
33099 >To unsubscribe or change your subscription options, visit:
33100 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
33102 _________________________________________________________________
33103 MSN 8: Get 6 months for $9.95/month. http://join.msn.com/?page=dept/dialup
33106 From simorgh at dataphone.se Sat Aug 30 08:27:11 2003
33107 From: simorgh at dataphone.se (Ali Simorgh)
33108 Date: Sat Oct 23 23:10:03 2004
33109 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
33110 In-Reply-To: <MKEGJINFADFODDNOKEJCMEEADPAA.rg@tcslon.com>
33111 Message-ID: <Pine.GSO.4.31.0308301716410.15629-100000@nikson.dataphone.se>
33114 I run ircservices 5.0.21 on FreeBSD 4.8-STABLE. and Ultimate 3.*
33115 I get this in logfile:
33117 [Aug 30 10:51:19 2003] unknown message from server
33118 (NETCTRL 0 0 0 0 0 0 0 0 0 0 0 0 0)
33119 [Aug 30 10:51:19 2003] user: New maximum user count: 1
33120 [Aug 30 10:51:19 2003] unknown message from server
33121 (:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
33122 [Aug 30 10:51:19 2003] user: New maximum user count: 2
33123 [Aug 30 10:51:19 2003] unknown message from server
33124 (:irc.MyNet.Net SETHOST pedarkhAnde 6b45bb2.26d9672f.dataphone.se)
33125 [Aug 30 10:56:18 2003] mail/sendmail:
33126 /usr/sbin/sendmail exited with code 25600
33127 [Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
33128 registration (Simorgh)
33130 and how can I do so that nickserv dont show the realhost of a user in
33137 ______________________________________________________
33138 Many of life's failures are people who did not realize
33139 how close they were to success when they gave up.
33141 ______________________________________________________
33146 From jskam at shaw.ca Sat Aug 30 11:34:35 2003
33147 From: jskam at shaw.ca (Jeffery Kam)
33148 Date: Sat Oct 23 23:10:03 2004
33149 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
33150 In-Reply-To: <Pine.GSO.4.31.0308301716410.15629-100000@nikson.dataphone.se>
33151 Message-ID: <000001c36f25$58464860$f64f9144@weed>
33153 "and how can I do so that nickserv dont show the realhost of a user in
33154 'ns info nick all'"
33156 This would be a great feature for sure. I know on my network, there is
33157 a custom user mode +d, which will disguise a user's host in a /whois
33158 reply, but services info doesn't show it disguised unless the HIDE
33163 From achurch at achurch.org Sat Aug 30 16:14:47 2003
33164 From: achurch at achurch.org (Andrew Church)
33165 Date: Sat Oct 23 23:10:03 2004
33166 Subject: [IRCServices Coding] MARK Command
33167 In-Reply-To: <3208.66.181.69.244.1060800845.squirrel@dreamchat.org>
33168 Message-ID: <3f512fdb.01666@achurch.org>
33170 Use E-mail if you need communication of that sort.
33173 achurch@achurch.org
33174 http://achurch.org/
33176 >First off, i would like to say that IRCservices are the best services out
33177 >there, by FAR! Anyways, i was wondering if the MARK command will be in
33178 >the next relase? Its kind of a pointless command, its only used to mark
33179 >nicks or channels, but it is very useful for when passwords to channels
33182 >/chanserv MARK <channel> <reason>
33184 >/chanserv info #channel would read the following.
33185 >*#channel has been MARKED by playa - <reason>
33187 >Of course only IRCops would be able to view it.
33189 >Just an idea i thought of :)
33194 >Network Founder/CEO
33195 >DreamChat IRC Network - irc.dreamchat.org
33196 >http://www.dreamchat.org
33198 >------------------------------------------------------------------
33199 >To unsubscribe or change your subscription options, visit:
33200 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
33202 From achurch at achurch.org Sat Aug 30 16:17:44 2003
33203 From: achurch at achurch.org (Andrew Church)
33204 Date: Sat Oct 23 23:10:03 2004
33205 Subject: [IRCServices Coding] OP/Voice upon identify
33206 In-Reply-To: <Pine.GSO.4.31.0308211027350.6118-100000@nikson.dataphone.se>
33207 Message-ID: <3f513092.01677@achurch.org>
33209 Needless complexity. If you don't want yourself autoopped, then don't
33210 be an auto-op. It's that simple.
33213 achurch@achurch.org
33214 http://achurch.org/
33217 >Its nice with this option. but I dont se any set command that ChanServ
33218 >wont automatically op or voice you in any channel.
33221 > SET NOAUTO ON|OFF
33222 > When NOAUTO is on, ChanServ will not
33223 > automatically op or voice you in any channels.
33225 >Maybe some user(s) wont get auto op/voice then they can set this option ON
33226 >but it sould be OFF in default.
33233 > ______________________________________________________
33234 > Many of life's failures are people who did not realize
33235 > how close they were to success when they gave up.
33237 > ______________________________________________________
33240 >On Sun, 17 Aug 2003, Russell Garrett wrote:
33242 >> Eh? This has been implemented since IRCServices 5a31.
33246 >> > I wonder if its possible to make some modification that:
33247 >> > when someone has already joined a few channels, and then identifies
33248 >> > to its nickname, chanserv gives Voice and/or Op to the user is s/he
33249 >> > is in the channel list (+o; aop or above & +v when vop)
33251 >> > this is very usefull to not privmsg chanserv for every op or voice
33252 >> > request, when user has not identified to its nick before joining
33255 >> > Thanks for any help
33257 >> ------------------------------------------------------------------
33258 >> To unsubscribe or change your subscription options, visit:
33259 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
33262 >------------------------------------------------------------------
33263 >To unsubscribe or change your subscription options, visit:
33264 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
33266 From l8nite at l8nite.net Sat Aug 30 16:58:16 2003
33267 From: l8nite at l8nite.net (Shaun Guth)
33268 Date: Sat Oct 23 23:10:03 2004
33269 Subject: [IRCServices Coding] OP/Voice upon identify
33270 In-Reply-To: <3f513092.01677@achurch.org>
33271 References: <3f513092.01677@achurch.org>
33272 Message-ID: <1062287885.21924.6.camel@localhost>
33274 On Sun, 2003-08-31 at 01:16, Andrew Church wrote:
33275 > Needless complexity. If you don't want yourself autoopped, then don't
33276 > be an auto-op. It's that simple.
33278 I disagree. In my case, I wanted to create a channel where there were
33279 no ops so users don't have to endure lame op-wars, etc. However, I did
33280 need to maintain a level of control over the channel to protect from
33281 extremely obnoxious behavior or lame bots, etc. By registering as
33282 founder of the channel I induced the unwanted 'auto-op' behavior. My
33283 only solution was to register another fake user to become channel
33284 founder and set their nick to noexpire. That to me seems like needless
33285 complexity. A simple check to see if the user wishes to be opped or not
33291 From Craig at chatspike.net Sat Aug 30 17:07:32 2003
33292 From: Craig at chatspike.net (Craig McLure)
33293 Date: Sat Oct 23 23:10:03 2004
33294 Subject: [IRCServices Coding] OP/Voice upon identify
33295 Message-ID: <20030831000719.ELIJ19019.mta3-svc.business.ntl.com@i-br0ked-it>
33297 it would thou.. they would have to be able to switch off auto-op for a single channel..
33298 you could always use /cs levels to change the 'auto op' level up.. so that no one is auto-opped..
33300 or /cs levels #channels DISABLE autoop
33302 /****************************************
33303 * Craig "FrostyCoolSlug" McLure
33304 ************* - SpamBox - **************
33305 * InspIRCd - http://www.inspircd.org
33306 * ChatSpike - http://www.chatspike.net
33307 * WinBot - http://www.winbot.co.uk
33308 ****************************************/
33310 /****************************************
33311 * From - Shaun Guth <l8nite@l8nite.net>
33312 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
33313 * Sent - 2003-08-30 @ 16:58:00
33314 * Subject - RE: [IRCServices Coding] OP/Voice upon identify
33315 ****************************************/
33317 /****** - Begin Original Message - ******/
33319 >On Sun, 2003-08-31 at 01:16, Andrew Church wrote:
33320 >> Needless complexity. If you don't want yourself autoopped, then don't
33321 >> be an auto-op. It's that simple.
33323 >I disagree. In my case, I wanted to create a channel where there were
33324 >no ops so users don't have to endure lame op-wars, etc. However, I did
33325 >need to maintain a level of control over the channel to protect from
33326 >extremely obnoxious behavior or lame bots, etc. By registering as
33327 >founder of the channel I induced the unwanted 'auto-op' behavior. My
33328 >only solution was to register another fake user to become channel
33329 >founder and set their nick to noexpire. That to me seems like needless
33330 >complexity. A simple check to see if the user wishes to be opped or not
33335 >------------------------------------------------------------------
33336 >To unsubscribe or change your subscription options, visit:
33337 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
33340 /******* - End Original Message - *******/
33345 From l8nite at l8nite.net Sat Aug 30 17:14:44 2003
33346 From: l8nite at l8nite.net (Shaun Guth)
33347 Date: Sat Oct 23 23:10:03 2004
33348 Subject: [IRCServices Coding] OP/Voice upon identify
33349 In-Reply-To: <20030831000719.ELIJ19019.mta3-svc.business.ntl.com@i-br0ked-it>
33350 References: <20030831000719.ELIJ19019.mta3-svc.business.ntl.com@i-br0ked-it>
33351 Message-ID: <1062288881.21924.17.camel@localhost>
33353 On Sat, 2003-08-30 at 18:06, Craig McLure wrote:
33354 > it would thou.. they would have to be able to switch off auto-op for a single channel..
33356 For each channel we already store an access list, one extra bit to
33357 indicate auto-anything status or not is not really asking too much.
33359 > you could always use /cs levels to change the 'auto op' level up.. so that no one is auto-opped..
33360 > or /cs levels #channels DISABLE autoop
33362 -ChanServ- Channel #foobar registered under your nickname: l8
33363 -ChanServ- AUTOOP disabled on channel #foobar.
33364 --- You have left channel #foobar
33365 --> You are now talking on #foobar
33366 --- services.topgamers.net removes channel operator status from l8
33367 --- services.topgamers.net gives channel operator status to l8
33369 Same with ENFORCE set to off as well.
33371 > [snipped obnoxiously long sig]
33376 From achurch at achurch.org Sun Aug 31 02:58:23 2003
33377 From: achurch at achurch.org (Andrew Church)
33378 Date: Sat Oct 23 23:10:03 2004
33379 Subject: [IRCServices Coding] OP/Voice upon identify
33380 In-Reply-To: <1062288881.21924.17.camel@localhost>
33381 Message-ID: <3f51c6b5.07402@achurch.org>
33383 >> you could always use /cs levels to change the 'auto op' level up.. so that no one is auto-opped..
33384 >> or /cs levels #channels DISABLE autoop
33386 >-ChanServ- Channel #foobar registered under your nickname: l8
33387 >-ChanServ- AUTOOP disabled on channel #foobar.
33388 >--- You have left channel #foobar
33389 >--> You are now talking on #foobar
33390 >--- services.topgamers.net removes channel operator status from l8
33391 >--- services.topgamers.net gives channel operator status to l8
33393 This is definitely confusing behavior. Fixed for 5.0.22, thanks for
33394 the report. Note that you will also want to disable the other AUTOxxx
33395 levels as well if you don't want any automatic modes.
33398 achurch@achurch.org
33399 http://achurch.org/
33401 From achurch at achurch.org Sun Aug 31 07:28:11 2003
33402 From: achurch at achurch.org (Andrew Church)
33403 Date: Sat Oct 23 23:10:03 2004
33404 Subject: [IRCServices Coding] Mass memos
33405 In-Reply-To: <001601c361d8$a5312f00$6401a8c0@turby>
33406 Message-ID: <3f5205f0.15057@achurch.org>
33408 >Can we reconsider adding a Mass memo function for the next release?
33410 No, for all the reasons others have mentioned. I'll also draw an
33411 example from my experience with cellphone mail in Japan, which is
33412 remarkably similar to Services memos: Automated messages are annoying,
33413 period. The primary use for cellphone mail is to communicate with friends;
33414 having automatic messages interfere with that is annoying in the extreme.
33415 Yes, 10% or 20% of your users might be willing to accept mass memos, but
33416 the remaining 80% or 90% will get quite upset with you.
33418 I might also point out that people who care about what happens on the
33419 network will actively check that information, whether you make it available
33420 through logon news, through a website, or whatever; and people who don't
33421 care will ignore anything you send them. The method you use to inform them
33422 won't really make a difference.
33424 >If not, or even if so... one thing puzzles me: In the /ns list * command,
33425 >the listings have occasional punctuation... a ! or ? in front of the nick.
33426 >There is nothing in the docs anywhere that seems to address this, and I'm
33427 >curious as to what those mean.... an explanation would be helpful there too.
33429 This should be available through /ns help list, but there appears to
33430 be a bug there. I'll fix it for the next version.
33432 >on that note, a possible suggestion for Logonnews... How about something I
33433 >saw on Dalnet once: When new news is added, you get a notice. Until you
33434 >read the news, it keeps bugging you when you log on. After you read it, it
33435 >stops. Some sort of flag so users know when there IS new news would be
33436 >useful... the main reason nobody read the logonnews is that 90% of the time
33437 >for them, it is unchanged........
33439 This is an interesting thought; I'll think about it for a future
33443 achurch@achurch.org
33444 http://achurch.org/
33446 From achurch at achurch.org Sun Aug 31 07:42:30 2003
33447 From: achurch at achurch.org (Andrew Church)
33448 Date: Sat Oct 23 23:10:03 2004
33449 Subject: [IRCServices Coding] Language
33450 In-Reply-To: <MKEGJINFADFODDNOKEJCKEEDDPAA.rg@tcslon.com>
33451 Message-ID: <3f52094e.17046@achurch.org>
33453 [/msg nickserv vs. /nickserv]
33454 >I wonder if it would be worth integrating such a thing into services as an
33455 >option (compile-time maybe?). I think it would be good for the irc community
33456 >as a whole to get away from the habit of msging services directly if at all
33457 >possible. Opinions?
33459 /msg NickServ is the one format that's guaranteed to work on every
33460 ircd (except for administrative decisions a la DALnet). Get an RFC
33461 published--and implemented; 2811-3 were remarkable failures in that area--
33462 and I'll consider changing it.
33465 achurch@achurch.org
33466 http://achurch.org/
33468 From achurch at achurch.org Sun Aug 31 07:45:49 2003
33469 From: achurch at achurch.org (Andrew Church)
33470 Date: Sat Oct 23 23:10:03 2004
33471 Subject: [IRCServices Coding] Language
33472 In-Reply-To: <Pine.GSO.4.31.0308172127300.9882-100000@nikson.dataphone.se>
33473 Message-ID: <3f520a18.17063@achurch.org>
33475 >Is there any tool (silly question) or something or guid to make a language
33478 >I have decided to make a Persian (Farsi) language file.
33480 Language files are just plain text files; as another reply said, read
33481 the comments at the top of lang/en_us.l, and work from there. Be warned
33482 that the amount of text is huge; expect to spend at least two to three
33483 months on the initial translation.
33485 Also, if you'd be willing to continue maintaining the language file as
33486 it is updated in future versions, please let me know privately.
33489 achurch@achurch.org
33490 http://achurch.org/
33492 From achurch at achurch.org Sun Aug 31 07:53:21 2003
33493 From: achurch at achurch.org (Andrew Church)
33494 Date: Sat Oct 23 23:10:03 2004
33495 Subject: [IRCServices Coding] segfault on expiring ?
33496 In-Reply-To: <001201c36793$d26e4000$0101a8c0@nothing>
33497 Message-ID: <3f520bd8.17715@achurch.org>
33499 >[Aug 20 20:49:05 2003] nickserv/main: Expiring suspension for SeBa_KoBe (nick group 17805)
33500 >[Aug 20 20:49:05 2003] nickserv/main: Expiring nickname SeBa_KoBe
33501 >[Aug 20 20:49:05 2003] nickserv/main: [Aug 20 20:49:05 2003] Services terminating: Segmentation Faul
33503 I can't reproduce this problem. If this is still occurring, can you
33504 send me your databases privately so that I can investigate it?
33507 achurch@achurch.org
33508 http://achurch.org/
33510 From achurch at achurch.org Sun Aug 31 07:55:10 2003
33511 From: achurch at achurch.org (Andrew Church)
33512 Date: Sat Oct 23 23:10:03 2004
33513 Subject: [IRCServices Coding] BUG Report
33514 In-Reply-To: <001501c36daf$c8cba700$0101a8c0@house>
33515 Message-ID: <3f520c48.17731@achurch.org>
33517 >we suspended channel #kavala, and someone has identified itself has the =
33518 >founder and apply a DROP to the channel.
33519 >then we got a panic from the services and... crash.
33521 This is a bug in the DROP function, and has been fixed; thanks for the
33525 achurch@achurch.org
33526 http://achurch.org/
33528 From achurch at achurch.org Sun Aug 31 08:07:44 2003
33529 From: achurch at achurch.org (Andrew Church)
33530 Date: Sat Oct 23 23:10:03 2004
33531 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
33532 In-Reply-To: <Pine.GSO.4.31.0308301716410.15629-100000@nikson.dataphone.se>
33533 Message-ID: <3f520f38.21076@achurch.org>
33535 >[Aug 30 10:56:18 2003] mail/sendmail:
33536 > /usr/sbin/sendmail exited with code 25600
33538 Use the SMTP module instead (mail/smtp).
33540 >[Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
33541 >registration (Simorgh)
33543 >and how can I do so that nickserv dont show the realhost of a user in
33544 >'ns info nick all'
33546 It doesn't. However:
33548 >[Aug 30 10:51:19 2003] unknown message from server
33549 >(:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
33551 You're using the wrong protocol, since it doesn't recognize the
33552 SETHOST command and therefore has no idea about fake hosts. I might
33553 remind you that Ultimate 3.x is not supported.
33556 achurch@achurch.org
33557 http://achurch.org/
33559 From achurch at achurch.org Sun Aug 31 08:11:22 2003
33560 From: achurch at achurch.org (Andrew Church)
33561 Date: Sat Oct 23 23:10:03 2004
33562 Subject: [IRCServices Coding] Yet, another great suggestion
33563 In-Reply-To: <20030828183615.GB32204@phat.za.net>
33564 Message-ID: <3f52100e.21116@achurch.org>
33566 >Or how about rather letting users decide what timezone they're in and
33567 >services outputs all timestamps in their local time?
33569 /ns help set timezone (since 5.0 alpha)
33572 achurch@achurch.org
33573 http://achurch.org/
33575 From saturn at jetirc.net Sun Aug 31 12:28:59 2003
33576 From: saturn at jetirc.net (Saturn)
33577 Date: Sat Oct 23 23:10:03 2004
33578 Subject: [IRCServices Coding]
33579 Re: [IRCServices] Yet, another great suggestion
33580 References: <3f5202a3.15001@achurch.org>
33581 Message-ID: <003201c36ff6$25ae6550$6401a8c0@turby>
33583 I think it is... consider an international Network like mine: every server
33584 is in a different time zone -- How are users supposed to know what time zone
33585 the Services (pickign on Services' clock because Services are whats giving
33586 these notices!) is in?? Sure, they can do the /time command, if they even
33587 know abotu it. But the vast majority of IRC users are ignorant of those
33588 sorts of commands, or even if they know about /time, they most likely have
33589 no idea they can specify a server with the command.
33591 I realize that programmers for IRC-related software seem always to be of the
33592 universal opinion that ALL irc users should take the time to become elite
33593 experts abotu everything PC, however that is simply NOT reality. Services
33594 is specificly there to SERVE the users and the ircops. Its sole function is
33595 to police access and provide information to the users -- what use is it to
33596 say that a certain piece of information is "not useful" or "not needed" when
33597 you can plainly see that it is in this case, given the argument above?
33599 Obviously, it is your project, not mine, and I certainly cannot force you to
33600 do anythign you don't want to do, but I and my staff and users all agree it
33601 would be extremely useful... "Handy" was the word most used. I've had quite
33602 a few queries about it, and so I'm asking for it. If you don't feel that
33603 non-techie users deserve any consideration, then ignore the request. It's
33604 really up to you anyhow....
33609 ----- Original Message -----
33610 From: "Andrew Church" <achurch@achurch.org>
33611 To: <saturn@jetirc.net>
33612 Sent: Sunday, August 31, 2003 7:13 AM
33613 Subject: Re: [IRCServices] Yet, another great suggestion
33616 >So how do you get the current time from Services then? The actual time that
33617 >SERVICES thinks it is, not the server, and not my local clock...
33619 If there's any significant difference between your local clock, your
33620 IRC server's clock, and Services' clock, then at least one of them needs to
33621 be fixed. That's not Services' problem.
33624 achurch@achurch.org
33625 http://achurch.org/
33629 From aragon at phat.za.net Sun Aug 31 13:23:29 2003
33630 From: aragon at phat.za.net (Aragon Gouveia)
33631 Date: Sat Oct 23 23:10:03 2004
33632 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
33633 another great suggestion
33634 In-Reply-To: <003201c36ff6$25ae6550$6401a8c0@turby>
33635 References: <3f5202a3.15001@achurch.org> <003201c36ff6$25ae6550$6401a8c0@turby>
33636 Message-ID: <20030831202324.GB8731@phat.za.net>
33638 | By Saturn <saturn@jetirc.net>
33639 | [ 2003-08-31 21:29 +0200 ]
33640 > I think it is... consider an international Network like mine: every server
33641 > is in a different time zone -- How are users supposed to know what time zone
33642 > the Services (pickign on Services' clock because Services are whats giving
33643 > these notices!) is in?? Sure, they can do the /time command, if they even
33644 > know abotu it. But the vast majority of IRC users are ignorant of those
33645 > sorts of commands, or even if they know about /time, they most likely have
33646 > no idea they can specify a server with the command.
33648 Erm, what's the argument here? Services stipulates its timezone in its
33649 timestamps. As do all the other servers on the network.
33657 From saturn at jetirc.net Sun Aug 31 13:47:37 2003
33658 From: saturn at jetirc.net (Saturn)
33659 Date: Sat Oct 23 23:10:03 2004
33660 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
33661 another great suggestion
33662 References: <3f5202a3.15001@achurch.org> <003201c36ff6$25ae6550$6401a8c0@turby>
33663 <20030831202324.GB8731@phat.za.net>
33664 Message-ID: <000701c37001$10a62cf0$6401a8c0@turby>
33666 The argument is that the overwhelming majority of IRC users have no idea the
33667 /time command exists, and even fewer are aware that they can specify a
33668 server name after the /time command. How would these people find out the
33669 Services time zone? Why does it all have to be so complicated??
33671 ----- Original Message -----
33672 From: "Aragon Gouveia" <aragon@phat.za.net>
33673 To: <ircservices-coding@ircservices.za.net>
33674 Sent: Sunday, August 31, 2003 1:23 PM
33675 Subject: Re: [IRCServices Coding] Re: [IRCServices] Yet,another great
33679 | By Saturn <saturn@jetirc.net>
33680 | [ 2003-08-31 21:29 +0200 ]
33681 > I think it is... consider an international Network like mine: every
33683 > is in a different time zone -- How are users supposed to know what time
33685 > the Services (pickign on Services' clock because Services are whats giving
33686 > these notices!) is in?? Sure, they can do the /time command, if they even
33687 > know abotu it. But the vast majority of IRC users are ignorant of those
33688 > sorts of commands, or even if they know about /time, they most likely have
33689 > no idea they can specify a server with the command.
33691 Erm, what's the argument here? Services stipulates its timezone in its
33692 timestamps. As do all the other servers on the network.
33699 ------------------------------------------------------------------
33700 To unsubscribe or change your subscription options, visit:
33701 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
33705 From quension at mac.com Sun Aug 31 14:11:28 2003
33706 From: quension at mac.com (Trevor Talbot)
33707 Date: Sat Oct 23 23:10:03 2004
33708 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
33709 another great suggestion
33710 In-Reply-To: <000701c37001$10a62cf0$6401a8c0@turby>
33711 Message-ID: <962546B6-DBF7-11D7-8505-0003938D6866@mac.com>
33713 On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
33715 > The argument is that the overwhelming majority of IRC users have no
33716 > idea the /time command exists, and even fewer are aware that they can
33717 > specify a server name after the /time command. How would these people
33718 > find out the Services time zone?
33720 You missed the point. Services shows the time zone wherever it uses a
33721 readable time -- i.e. in the nickserv/chanserv info displays. Unless
33722 you've changed your language file, in which case you can simply change
33725 > Why does it all have to be so complicated??
33727 It isn't. Your users can even use the handy-dandy /nickserv set
33728 timezone command to make it even easier.
33730 > ----- Original Message -----
33731 > From: "Aragon Gouveia" <aragon@phat.za.net>
33733 > | By Saturn <saturn@jetirc.net>
33734 > | [ 2003-08-31 21:29 +0200 ]
33735 >> I think it is... consider an international Network like mine: every
33736 >> server is in a different time zone -- How are users supposed to know
33737 >> what time zone the Services (pickign on Services' clock because
33738 >> Services are whats giving these notices!) is in?? Sure, they can do
33739 >> the /time command, if they even know abotu it. But the vast majority
33740 >> of IRC users are ignorant of those sorts of commands, or even if they
33741 >> know about /time, they most likely have no idea they can specify a
33742 >> server with the command.
33744 > Erm, what's the argument here? Services stipulates its timezone in
33745 > its timestamps. As do all the other servers on the network.
33750 From us44ever at hotmail.com Sun Aug 31 14:40:48 2003
33751 From: us44ever at hotmail.com (us44ever .)
33752 Date: Sat Oct 23 23:10:03 2004
33753 Subject: [IRCServices Coding]
33754 Re: [IRCServices] Yet, another great suggestion
33755 Message-ID: <Sea1-F8siZAPG4vEjaG0000fb20@hotmail.com>
33758 or even the idea of adding an additional info (exact info) something like:
33759 Last seen time : Aug 22 14:20:16 2003 GMT (9 days, 51 minutes and 21
33761 Time registered : Jul 25 22:19:20 2003 GMT (** days, ** minutes and **
33763 wouldn't even a greater idea?
33765 _________________________________________________________________
33766 Get MSN 8 and enjoy automatic e-mail virus protection.
33767 http://join.msn.com/?page=features/virus
33770 From saturn at jetirc.net Sun Aug 31 16:49:07 2003
33771 From: saturn at jetirc.net (Saturn)
33772 Date: Sat Oct 23 23:10:03 2004
33773 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
33774 another great suggestion
33775 References: <962546B6-DBF7-11D7-8505-0003938D6866@mac.com>
33776 Message-ID: <000e01c3701a$48faea50$6401a8c0@turby>
33778 [16:41] -NickServ- Time registered: Jul 27 13:09:08 2002 PDT
33780 That's what I see when I use it. Yes, it does say "PDT" .. how many people
33781 in, say Belgium, are going to know exactly what PDT is? How about "PDT
33782 (GMT-8)" as the format....? Also, you'll note that it STILL gives no
33783 indication as to the CURRENT time ... this is why the proper UTC code or
33784 GMT+/-## is the best way to go IMHO. I do also like the idea suggested by
33785 us44ever ... the "(** days, ** minutes, and ** seconds ago)" idea... that
33786 would be handy in any event.... and would eliminate the need for the current
33787 time to be displayed....
33789 On another note, I had forgotten the set timezone option, which certainly
33790 would put more clarity on the output... however, I think my points above are
33793 Unless of course I've missed a config setting that will tell it to report
33794 the tiome zone as a function of GMT (plus or minus x hours, rather than zone
33797 ----- Original Message -----
33798 From: "Trevor Talbot" <quension@mac.com>
33799 To: "IRC Services Coding Mailing List"
33800 <ircservices-coding@ircservices.za.net>
33801 Sent: Sunday, August 31, 2003 2:10 PM
33802 Subject: Re: [IRCServices Coding] Re: [IRCServices] Yet,another great
33806 On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
33808 > The argument is that the overwhelming majority of IRC users have no
33809 > idea the /time command exists, and even fewer are aware that they can
33810 > specify a server name after the /time command. How would these people
33811 > find out the Services time zone?
33813 You missed the point. Services shows the time zone wherever it uses a
33814 readable time -- i.e. in the nickserv/chanserv info displays. Unless
33815 you've changed your language file, in which case you can simply change
33818 > Why does it all have to be so complicated??
33820 It isn't. Your users can even use the handy-dandy /nickserv set
33821 timezone command to make it even easier.
33823 > ----- Original Message -----
33824 > From: "Aragon Gouveia" <aragon@phat.za.net>
33826 > | By Saturn <saturn@jetirc.net>
33827 > | [ 2003-08-31 21:29 +0200 ]
33828 >> I think it is... consider an international Network like mine: every
33829 >> server is in a different time zone -- How are users supposed to know
33830 >> what time zone the Services (pickign on Services' clock because
33831 >> Services are whats giving these notices!) is in?? Sure, they can do
33832 >> the /time command, if they even know abotu it. But the vast majority
33833 >> of IRC users are ignorant of those sorts of commands, or even if they
33834 >> know about /time, they most likely have no idea they can specify a
33835 >> server with the command.
33837 > Erm, what's the argument here? Services stipulates its timezone in
33838 > its timestamps. As do all the other servers on the network.
33842 ------------------------------------------------------------------
33843 To unsubscribe or change your subscription options, visit:
33844 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
33848 From quension at mac.com Sun Aug 31 18:25:05 2003
33849 From: quension at mac.com (Trevor Talbot)
33850 Date: Sat Oct 23 23:10:03 2004
33851 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
33852 another great suggestion
33853 In-Reply-To: <000e01c3701a$48faea50$6401a8c0@turby>
33854 Message-ID: <14C7EDD0-DC1B-11D7-8505-0003938D6866@mac.com>
33856 On Sunday, Aug 31, 2003, at 16:47 US/Pacific, Saturn wrote:
33858 > Unless of course I've missed a config setting that will tell it to
33859 > report the tiome zone as a function of GMT (plus or minus x hours,
33860 > rather than zone codes like PDT)...
33862 You could modify the language file, using something like "(GMT%z)"
33863 instead of %Z in the STRFTIME_DATE_TIME_FORMAT string. "man 3
33864 strftime" for the available options.
33869 From achurch at achurch.org Sun Aug 31 19:00:00 2003
33870 From: achurch at achurch.org (Andrew Church)
33871 Date: Sat Oct 23 23:10:03 2004
33872 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
33873 another great suggestion
33874 In-Reply-To: <000e01c3701a$48faea50$6401a8c0@turby>
33875 Message-ID: <3f52a815.21363@achurch.org>
33877 "Use /ns set timezone" is the official answer on this. Please take
33878 all further discussion to the ircservices list.
33881 achurch@achurch.org
33882 http://achurch.org/
33884 >[16:41] -NickServ- Time registered: Jul 27 13:09:08 2002 PDT
33886 >That's what I see when I use it. Yes, it does say "PDT" .. how many people
33887 >in, say Belgium, are going to know exactly what PDT is? How about "PDT
33888 >(GMT-8)" as the format....? Also, you'll note that it STILL gives no
33889 >indication as to the CURRENT time ... this is why the proper UTC code or
33890 >GMT+/-## is the best way to go IMHO. I do also like the idea suggested by
33891 >us44ever ... the "(** days, ** minutes, and ** seconds ago)" idea... that
33892 >would be handy in any event.... and would eliminate the need for the current
33893 >time to be displayed....
33895 >On another note, I had forgotten the set timezone option, which certainly
33896 >would put more clarity on the output... however, I think my points above are
33899 >Unless of course I've missed a config setting that will tell it to report
33900 >the tiome zone as a function of GMT (plus or minus x hours, rather than zone
33901 >codes like PDT)...
33903 >----- Original Message -----
33904 >From: "Trevor Talbot" <quension@mac.com>
33905 >To: "IRC Services Coding Mailing List"
33906 ><ircservices-coding@ircservices.za.net>
33907 >Sent: Sunday, August 31, 2003 2:10 PM
33908 >Subject: Re: [IRCServices Coding] Re: [IRCServices] Yet,another great
33912 >On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
33914 >> The argument is that the overwhelming majority of IRC users have no
33915 >> idea the /time command exists, and even fewer are aware that they can
33916 >> specify a server name after the /time command. How would these people
33917 >> find out the Services time zone?
33919 >You missed the point. Services shows the time zone wherever it uses a
33920 >readable time -- i.e. in the nickserv/chanserv info displays. Unless
33921 >you've changed your language file, in which case you can simply change
33924 >> Why does it all have to be so complicated??
33926 >It isn't. Your users can even use the handy-dandy /nickserv set
33927 >timezone command to make it even easier.
33929 >> ----- Original Message -----
33930 >> From: "Aragon Gouveia" <aragon@phat.za.net>
33932 >> | By Saturn <saturn@jetirc.net>
33933 >> | [ 2003-08-31 21:29 +0200 ]
33934 >>> I think it is... consider an international Network like mine: every
33935 >>> server is in a different time zone -- How are users supposed to know
33936 >>> what time zone the Services (pickign on Services' clock because
33937 >>> Services are whats giving these notices!) is in?? Sure, they can do
33938 >>> the /time command, if they even know abotu it. But the vast majority
33939 >>> of IRC users are ignorant of those sorts of commands, or even if they
33940 >>> know about /time, they most likely have no idea they can specify a
33941 >>> server with the command.
33943 >> Erm, what's the argument here? Services stipulates its timezone in
33944 >> its timestamps. As do all the other servers on the network.
33948 >------------------------------------------------------------------
33949 >To unsubscribe or change your subscription options, visit:
33950 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
33953 >------------------------------------------------------------------
33954 >To unsubscribe or change your subscription options, visit:
33955 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
33957 From simorgh at dataphone.se Sun Aug 31 22:34:32 2003
33958 From: simorgh at dataphone.se (Ali Simorgh)
33959 Date: Sat Oct 23 23:10:03 2004
33960 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
33961 In-Reply-To: <3f520f38.21076@achurch.org>
33962 Message-ID: <Pine.GSO.4.31.0309010728040.7173-100000@nikson.dataphone.se>
33964 Thanks for your help.
33966 I thought if I set nickserv to not be an ircop, then it maybe dosent se
33967 the real host name, and maybe shows the crypted hostname to other users
33968 or should I change this line in language files:
33969 NICK_INFO_ADDRESS_ONLINE
33972 NICK_INFO_ADDRESS_ONLINE
33973 Is online from: N/A ?
33977 ______________________________________________________
33978 Many of life's failures are people who did not realize
33979 how close they were to success when they gave up.
33981 ______________________________________________________
33984 On Mon, 1 Sep 2003, Andrew Church wrote:
33986 > >[Aug 30 10:56:18 2003] mail/sendmail:
33987 > > /usr/sbin/sendmail exited with code 25600
33989 > Use the SMTP module instead (mail/smtp).
33991 > >[Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
33992 > >registration (Simorgh)
33994 > >and how can I do so that nickserv dont show the realhost of a user in
33995 > >'ns info nick all'
33997 > It doesn't. However:
33999 > >[Aug 30 10:51:19 2003] unknown message from server
34000 > >(:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
34002 > You're using the wrong protocol, since it doesn't recognize the
34003 > SETHOST command and therefore has no idea about fake hosts. I might
34004 > remind you that Ultimate 3.x is not supported.
34007 > achurch@achurch.org
34008 > http://achurch.org/
34009 > ------------------------------------------------------------------
34010 > To unsubscribe or change your subscription options, visit:
34011 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
34015 From achurch at achurch.org Sun Aug 31 23:24:09 2003
34016 From: achurch at achurch.org (Andrew Church)
34017 Date: Sat Oct 23 23:10:03 2004
34018 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
34019 In-Reply-To: <Pine.GSO.4.31.0309010728040.7173-100000@nikson.dataphone.se>
34020 Message-ID: <3f52e5fe.41203@achurch.org>
34022 >I thought if I set nickserv to not be an ircop, then it maybe dosent se
34023 >the real host name, and maybe shows the crypted hostname to other users
34025 It isn't a matter of NickServ having operator privileges or not;
34026 Services, as a server, always sees the real hostname. The problem is that
34027 Services and your IRC server aren't using the same protocol, so Services
34028 can't recognize the fake hosts. Try using a different IRC server.
34031 achurch@achurch.org
34032 http://achurch.org/
34034 From laser at musichat.net Wed Sep 3 06:49:40 2003
34035 From: laser at musichat.net (Alessandro Ciappei)
34036 Date: Sat Oct 23 23:10:03 2004
34037 Subject: [IRCServices Coding] New Features
34038 Message-ID: <001b01c37222$428f54d0$e2c0fea9@alexxa3il9cxpx>
34042 I have an idea for next release.
34043 A secure link between services and ircd.
34044 Now many ircd, like Unreal, tr-ircd, bahamut supports a ssl link.
34049 -------------- next part --------------
34050 An HTML attachment was scrubbed...
34051 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030903/a25ee68d/attachment-0002.html
34052 From r-krisztian at softhome.net Wed Sep 3 07:16:45 2003
34053 From: r-krisztian at softhome.net (Krisztian Romek)
34054 Date: Sat Oct 23 23:10:03 2004
34055 Subject: [IRCServices Coding] New Features
34056 In-Reply-To: <001b01c37222$428f54d0$e2c0fea9@alexxa3il9cxpx>
34057 References: <001b01c37222$428f54d0$e2c0fea9@alexxa3il9cxpx>
34058 Message-ID: <200309031617.38876.r-krisztian@softhome.net>
34063 > I have an idea for next release.
34064 > A secure link between services and ircd.
34065 > Now many ircd, like Unreal, tr-ircd, bahamut supports a ssl link.
34067 I think a ZIP link support (like in Unreal) should also be fine. :-) I don't
34068 know what you will reply for these feature requests, but I agree that they
34069 aren't so important, since in most cases ircd and services run on the same
34074 r-krisztian@softhome.net
34077 From Craig at chatspike.net Wed Sep 3 13:35:04 2003
34078 From: Craig at chatspike.net (Craig McLure)
34079 Date: Sat Oct 23 23:10:03 2004
34080 Subject: [IRCServices Coding] New Features
34081 Message-ID: <20030903203453.ITMO19019.mta3-svc.business.ntl.com@i-br0ked-it>
34083 If you read the archive, you will find that this has already been discussed (fairly recently if i recall..), and was thrown out, if you want services SSL support, i recommend you use a SSL tunnel.
34085 When it comes to ZIP links, this would require editing the services protocol module accordingly.. and IMO, shouldnt been needed, as in most cases, services run on the same box as a server.
34087 /****************************************
34088 * Craig "FrostyCoolSlug" McLure
34089 ************* - SpamBox - **************
34090 * InspIRCd - http://www.inspircd.org
34091 * ChatSpike - http://www.chatspike.net
34092 * WinBot - http://www.winbot.co.uk
34093 ****************************************/
34095 /****************************************
34096 * From - Alessandro Ciappei <laser@musichat.net>
34097 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
34098 * Sent - 2003-09-03 @ 15:49:00
34099 * Subject - [IRCServices Coding] New Features
34100 ****************************************/
34102 /****** - Begin Original Message - ******/
34106 >I have an idea for next release.
34107 >A secure link between services and ircd.
34108 >Now many ircd, like Unreal, tr-ircd, bahamut supports a ssl link.
34113 >------------------------------------------------------------------
34114 >To unsubscribe or change your subscription options, visit:
34115 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
34117 /******* - End Original Message - *******/
34122 From ircserv at elric.net Wed Sep 3 20:49:47 2003
34123 From: ircserv at elric.net (Brent DiNicola)
34124 Date: Sat Oct 23 23:10:03 2004
34125 Subject: [IRCServices Coding] Which route to take - Module?
34126 Message-ID: <5.2.1.1.0.20030903223929.016e4648@mail.elric.net>
34128 It wasn't an easy subject to sum up in just a few words.
34130 I am wanting to do something to the ircservices code, I want to change
34131 the way the notice() works. I know that modifying the send.c would be
34132 very frowned upon and then I got to thinking and had suggested that I
34133 maybe make a module to keep the information for me. I know it's against
34134 the RFC, but I am pressed against a brick wall here, I have to give the users
34135 an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
34136 I would like to give them the option of turning on PRIVMSG but have NOTICE
34137 be the default, that would get the lazy people to use NOTICE. Eventually
34138 getting rid of this problem. In the mean time, I was thinking what is the best
34139 way to go about this without causing trouble for me and anyone else who has
34140 to deal with this code. Is it possible or even suggested to make a module that
34141 would replace the notice() from send.c with it's own, leaving the code in
34143 alone and not causing troubles down the road. Suggestions were that I make a
34144 module that kept the info for each nick's setting and then if I could override
34145 the notice() and notice_lang() and notice_help() in send.c that would keep
34147 other code clean and not cause other troubles. I want to know what the best
34148 way to do this would be, I know it's against RFC but I want to move to newer
34149 services than the 1.4.3pre4 that we are using now and add modules so that I
34150 can do things down the line. They are used to having PRIVMSG and I can't just
34151 change it without running people off, so if I can make PRIVMSG an option
34152 then I can't be blamed if they are lazy. Opinions on how to go about this? I
34153 know this topic has been asked before and I know your not going to make it
34154 part of your code, I just wanted to know from the people who know the code
34155 really well what the best route to take would be to do the least amount of
34156 damage. (And if someone has done this.. please let me know what you did,
34157 examples would rock)
34165 ----------------------------------------------------------
34167 | The Whitewolf of Immyrr |
34168 | <elric@elric.net> |
34169 | http://www.melnibone.net |
34170 | Disclaimer: Any opinions expressed here are |
34171 | from my dog. Any liabilities fall to the dog. |
34172 -----------------------------------------------------------
34175 From Craig at chatspike.net Wed Sep 3 21:18:29 2003
34176 From: Craig at chatspike.net (Craig McLure)
34177 Date: Sat Oct 23 23:10:03 2004
34178 Subject: [IRCServices Coding] Which route to take - Module?
34179 Message-ID: <20030904041818.TXAK19019.mta3-svc.business.ntl.com@i-br0ked-it>
34181 lol, Our help no good? :P
34183 i still say module with seperate database (with the nickgroup, and if this option is on or off (This saves having to modify the main nick.db) , somehow extending the /ns SET command to include a new option.. and replacing what ever function sends notices with something that uses an if to query your new database..
34185 Dont ask me for source on this.. i'm just theorising :)
34187 /****************************************
34188 * Craig "FrostyCoolSlug" McLure
34189 ************* - SpamBox - **************
34190 * InspIRCd - http://www.inspircd.org
34191 * ChatSpike - http://www.chatspike.net
34192 * WinBot - http://www.winbot.co.uk
34193 ****************************************/
34195 /****************************************
34196 * From - Brent DiNicola <ircserv@elric.net>
34197 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
34198 * Sent - 2003-09-03 @ 22:49:00
34199 * Subject - [IRCServices Coding] Which route to take - Module?
34200 ****************************************/
34202 /****** - Begin Original Message - ******/
34204 >It wasn't an easy subject to sum up in just a few words.
34206 >I am wanting to do something to the ircservices code, I want to change
34207 >the way the notice() works. I know that modifying the send.c would be
34208 >very frowned upon and then I got to thinking and had suggested that I
34209 >maybe make a module to keep the information for me. I know it's against
34210 >the RFC, but I am pressed against a brick wall here, I have to give the users
34211 >an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
34212 >I would like to give them the option of turning on PRIVMSG but have NOTICE
34213 >be the default, that would get the lazy people to use NOTICE. Eventually
34214 >getting rid of this problem. In the mean time, I was thinking what is the best
34215 >way to go about this without causing trouble for me and anyone else who has
34216 >to deal with this code. Is it possible or even suggested to make a module that
34217 >would replace the notice() from send.c with it's own, leaving the code in
34219 >alone and not causing troubles down the road. Suggestions were that I make a
34220 >module that kept the info for each nick's setting and then if I could override
34221 >the notice() and notice_lang() and notice_help() in send.c that would keep
34223 >other code clean and not cause other troubles. I want to know what the best
34224 >way to do this would be, I know it's against RFC but I want to move to newer
34225 >services than the 1.4.3pre4 that we are using now and add modules so that I
34226 >can do things down the line. They are used to having PRIVMSG and I can't just
34227 >change it without running people off, so if I can make PRIVMSG an option
34228 >then I can't be blamed if they are lazy. Opinions on how to go about this? I
34229 >know this topic has been asked before and I know your not going to make it
34230 >part of your code, I just wanted to know from the people who know the code
34231 >really well what the best route to take would be to do the least amount of
34232 >damage. (And if someone has done this.. please let me know what you did,
34233 >examples would rock)
34241 >----------------------------------------------------------
34242 >| Brent DiNicola |
34243 >| The Whitewolf of Immyrr |
34244 >| <elric@elric.net> |
34245 >| http://www.melnibone.net |
34246 >| Disclaimer: Any opinions expressed here are |
34247 >| from my dog. Any liabilities fall to the dog. |
34248 >-----------------------------------------------------------
34250 >------------------------------------------------------------------
34251 >To unsubscribe or change your subscription options, visit:
34252 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
34255 /******* - End Original Message - *******/
34260 From uhc0 at rz.uni-karlsruhe.de Thu Sep 4 01:34:06 2003
34261 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu)
34262 Date: Sat Oct 23 23:10:03 2004
34263 Subject: [IRCServices Coding] Which route to take - Module?
34264 In-Reply-To: <5.2.1.1.0.20030903223929.016e4648@mail.elric.net>
34265 References: <5.2.1.1.0.20030903223929.016e4648@mail.elric.net>
34266 Message-ID: <1062664383.1917.15.camel@dreadnought.hadiko.de>
34270 Long question; long answer.
34271 First of all, you must come off the thoughts of "Against the RFC".
34272 Why? Because, tons of irc servers available do provide techniques, which
34273 do not appear, or appear differently on the irc RFC, so that by design
34274 these ircds are also against it. In most of the cases, these changes
34275 reflect themselves in their appropriate server-to-server protocols, and
34276 become transient to the clients, so that on client side, the protocol
34277 remains original. This is also the only way of ensuring that all of the
34278 clients can work with a specific irc daemon.
34280 The issue, why PRIVMSG instead of NOTICE is bad, does also result from
34281 the client-to-server part of the RFC. And it has a reason. Consider two
34282 automated clients (bots, services, etc) talking to each other with
34283 PRIVMSG, and saying things like:
34284 <NickServ> otherwise, I change your nick.
34285 <MyBot> Unknown command otherwise. Please repeat your query.
34286 <NickServ> Unknown command UNKNOWN.
34287 <MyBot> Unknown command unknown. Please repeat your query.
34288 <NickServ> Unknown command UNKNOWN.
34289 <MyBot> Unknown command unknown. Please repeat your query.
34290 <NickServ> Unknown command UNKNOWN.
34291 <MyBot> Unknown command unknown. Please repeat your query.
34292 <NickServ> Unknown command UNKNOWN.
34293 <MyBot> Unknown command unknown. Please repeat your query.
34296 Do you understand, what problem may conclude due to PRIVMSG? RFC says
34297 clearly, that clients shall not generate automatic replies to NOTICES.
34298 That way, your bot would not "talk" to NickServ after a NOTICE anymore.
34301 The most easy implementation of this is creating a NF_USE_PRIVMSG flag,
34302 with a value far greater than any of the built-in, so that in future
34303 this flag does not collide with any of the original flags.
34305 Then you create the new SET command for this, as well as its help text,
34306 primarily in the english language file. That part of the work is
34309 Afterwards, you should modify notice_lang, and check for the
34310 NF_USE_PRIVMSG flag of the "ngi" being used; and if true, send PRIVMSG
34311 instead. The same for notice_help. And your case could be marked as
34314 Do keep in mind that requesting support for modified services versions
34315 are subject to be ignored.
34320 On Thu, 2003-09-04 at 05:49, Brent DiNicola wrote:
34321 > It wasn't an easy subject to sum up in just a few words.
34323 > I am wanting to do something to the ircservices code, I want to change
34324 > the way the notice() works. I know that modifying the send.c would be
34325 > very frowned upon and then I got to thinking and had suggested that I
34326 > maybe make a module to keep the information for me. I know it's against
34327 > the RFC, but I am pressed against a brick wall here, I have to give the users
34328 > an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
34329 > I would like to give them the option of turning on PRIVMSG but have NOTICE
34330 > be the default, that would get the lazy people to use NOTICE. Eventually
34331 > getting rid of this problem. In the mean time, I was thinking what is the best
34332 > way to go about this without causing trouble for me and anyone else who has
34333 > to deal with this code. Is it possible or even suggested to make a module that
34334 > would replace the notice() from send.c with it's own, leaving the code in
34336 > alone and not causing troubles down the road. Suggestions were that I make a
34337 > module that kept the info for each nick's setting and then if I could override
34338 > the notice() and notice_lang() and notice_help() in send.c that would keep
34340 > other code clean and not cause other troubles. I want to know what the best
34341 > way to do this would be, I know it's against RFC but I want to move to newer
34342 > services than the 1.4.3pre4 that we are using now and add modules so that I
34343 > can do things down the line. They are used to having PRIVMSG and I can't just
34344 > change it without running people off, so if I can make PRIVMSG an option
34345 > then I can't be blamed if they are lazy. Opinions on how to go about this? I
34346 > know this topic has been asked before and I know your not going to make it
34347 > part of your code, I just wanted to know from the people who know the code
34348 > really well what the best route to take would be to do the least amount of
34349 > damage. (And if someone has done this.. please let me know what you did,
34350 > examples would rock)
34358 > ----------------------------------------------------------
34359 > | Brent DiNicola |
34360 > | The Whitewolf of Immyrr |
34361 > | <elric@elric.net> |
34362 > | http://www.melnibone.net |
34363 > | Disclaimer: Any opinions expressed here are |
34364 > | from my dog. Any liabilities fall to the dog. |
34365 > -----------------------------------------------------------
34367 > ------------------------------------------------------------------
34368 > To unsubscribe or change your subscription options, visit:
34369 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
34371 ------------------------------------------------------------------
34372 | Yusuf Iskenderoglu | You get to meet all sorts, |
34373 | eMail - uhc0@stud.uni-karlsruhe.de| in this line of work... |
34374 | eMail - s_iskend@ira.uka.de | |
34375 | ICQ UIN : 20587464 \ TimeMr14C | |
34376 ------------------------------------------------------------------
34379 From griever at t2n.org Thu Sep 4 13:31:44 2003
34380 From: griever at t2n.org (Robert F Merrill)
34381 Date: Sat Oct 23 23:10:03 2004
34382 Subject: [IRCServices Coding] Which route to take - Module?
34383 References: <5.2.1.1.0.20030903223929.016e4648@mail.elric.net>
34384 Message-ID: <3F57A0BA.9080909@t2n.org>
34386 Brent DiNicola wrote:
34388 > It wasn't an easy subject to sum up in just a few words.
34390 > I am wanting to do something to the ircservices code, I want to change
34391 > the way the notice() works. I know that modifying the send.c would be
34392 > very frowned upon and then I got to thinking and had suggested that I
34393 > maybe make a module to keep the information for me. I know it's against
34394 > the RFC, but I am pressed against a brick wall here, I have to give
34396 > an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
34397 > I would like to give them the option of turning on PRIVMSG but have
34399 > be the default, that would get the lazy people to use NOTICE. Eventually
34400 > getting rid of this problem. In the mean time, I was thinking what is
34402 > way to go about this without causing trouble for me and anyone else
34404 > to deal with this code. Is it possible or even suggested to make a
34406 > would replace the notice() from send.c with it's own, leaving the code
34408 > alone and not causing troubles down the road. Suggestions were that I
34410 > module that kept the info for each nick's setting and then if I could
34412 > the notice() and notice_lang() and notice_help() in send.c that would
34414 > other code clean and not cause other troubles. I want to know what the
34416 > way to do this would be, I know it's against RFC but I want to move to
34418 > services than the 1.4.3pre4 that we are using now and add modules so
34420 > can do things down the line. They are used to having PRIVMSG and I
34422 > change it without running people off, so if I can make PRIVMSG an option
34423 > then I can't be blamed if they are lazy. Opinions on how to go about
34425 > know this topic has been asked before and I know your not going to
34427 > part of your code, I just wanted to know from the people who know the
34429 > really well what the best route to take would be to do the least
34431 > damage. (And if someone has done this.. please let me know what you did,
34432 > examples would rock)
34440 > ----------------------------------------------------------
34441 > | Brent DiNicola |
34442 > | The Whitewolf of Immyrr |
34443 > | <elric@elric.net> |
34444 > | http://www.melnibone.net |
34445 > | Disclaimer: Any opinions expressed here are |
34446 > | from my dog. Any liabilities fall to the dog. |
34447 > -----------------------------------------------------------
34448 > ------------------------------------------------------------------
34449 > To unsubscribe or change your subscription options, visit:
34450 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
34454 Services is not the place to fix broken clients, and any client which
34455 doesn't display notices correctly is broken. If someone wants to see
34456 notices differently, they can either
34457 a) change their client or in the case of webtv b) change the ircd
34459 services is the wrong thing to change
34462 From Craig at chatspike.net Thu Sep 4 13:52:48 2003
34463 From: Craig at chatspike.net (Craig McLure)
34464 Date: Sat Oct 23 23:10:03 2004
34465 Subject: [IRCServices Coding] Which route to take - Module?
34466 Message-ID: <20030904205232.SDRM23096.mta6-svc.business.ntl.com@i-br0ked-it>
34468 dont mean to sound rude, but this isnt a 'moral' discussion, as it were, rather than saying 'I dont think this needs done', i think it would be best to help him.. its not a discussion on if its right or wrong, its a 'How to do it' discussion.. If you cant contribute to this.. please ignore this 'thread' :p
34470 /****************************************
34471 * Craig "FrostyCoolSlug" McLure
34472 ************* - SpamBox - **************
34473 * InspIRCd - http://www.inspircd.org
34474 * ChatSpike - http://www.chatspike.net
34475 * WinBot - http://www.winbot.co.uk
34476 ****************************************/
34478 /****************************************
34479 * From - Robert F Merrill <griever@t2n.org>
34480 * To - IRC Services Coding Mailing List <ircservices-coding@ircservices.za.net>
34481 * Sent - 2003-09-04 @ 16:29:00
34482 * Subject - Re: [IRCServices Coding] Which route to take - Module?
34483 ****************************************/
34485 /****** - Begin Original Message - ******/
34487 >Brent DiNicola wrote:
34489 >> It wasn't an easy subject to sum up in just a few words.
34491 >> I am wanting to do something to the ircservices code, I want to change
34492 >> the way the notice() works. I know that modifying the send.c would be
34493 >> very frowned upon and then I got to thinking and had suggested that I
34494 >> maybe make a module to keep the information for me. I know it's against
34495 >> the RFC, but I am pressed against a brick wall here, I have to give
34497 >> an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
34498 >> I would like to give them the option of turning on PRIVMSG but have
34500 >> be the default, that would get the lazy people to use NOTICE. Eventually
34501 >> getting rid of this problem. In the mean time, I was thinking what is
34503 >> way to go about this without causing trouble for me and anyone else
34505 >> to deal with this code. Is it possible or even suggested to make a
34507 >> would replace the notice() from send.c with it's own, leaving the code
34509 >> alone and not causing troubles down the road. Suggestions were that I
34511 >> module that kept the info for each nick's setting and then if I could
34513 >> the notice() and notice_lang() and notice_help() in send.c that would
34515 >> other code clean and not cause other troubles. I want to know what the
34517 >> way to do this would be, I know it's against RFC but I want to move to
34519 >> services than the 1.4.3pre4 that we are using now and add modules so
34521 >> can do things down the line. They are used to having PRIVMSG and I
34523 >> change it without running people off, so if I can make PRIVMSG an option
34524 >> then I can't be blamed if they are lazy. Opinions on how to go about
34526 >> know this topic has been asked before and I know your not going to
34528 >> part of your code, I just wanted to know from the people who know the
34530 >> really well what the best route to take would be to do the least
34532 >> damage. (And if someone has done this.. please let me know what you did,
34533 >> examples would rock)
34541 >> ----------------------------------------------------------
34542 >> | Brent DiNicola |
34543 >> | The Whitewolf of Immyrr |
34544 >> | <elric@elric.net> |
34545 >> | http://www.melnibone.net |
34546 >> | Disclaimer: Any opinions expressed here are |
34547 >> | from my dog. Any liabilities fall to the dog. |
34548 >> -----------------------------------------------------------
34549 >> ------------------------------------------------------------------
34550 >> To unsubscribe or change your subscription options, visit:
34551 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
34555 >Services is not the place to fix broken clients, and any client which
34556 >doesn't display notices correctly is broken. If someone wants to see
34557 >notices differently, they can either
34558 >a) change their client or in the case of webtv b) change the ircd
34560 >services is the wrong thing to change
34562 >------------------------------------------------------------------
34563 >To unsubscribe or change your subscription options, visit:
34564 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
34567 /******* - End Original Message - *******/
34572 From quension at mac.com Thu Sep 4 13:54:21 2003
34573 From: quension at mac.com (Trevor Talbot)
34574 Date: Sat Oct 23 23:10:03 2004
34575 Subject: [IRCServices Coding] Which route to take - Module?
34576 In-Reply-To: <3F57A0BA.9080909@t2n.org>
34577 Message-ID: <E8AC4DDC-DF19-11D7-905C-0003938D6866@mac.com>
34579 On Thursday, Sep 4, 2003, at 13:29 US/Pacific, Robert F Merrill wrote:
34581 > Brent DiNicola wrote:
34583 >> It wasn't an easy subject to sum up in just a few words.
34587 > Services is not the place to fix broken clients, and any client which
34588 > doesn't display notices correctly is broken. If someone wants to see
34589 > notices differently, they can either a) change their client or in the
34590 > case of webtv b) change the ircd
34592 > services is the wrong thing to change
34594 And telling someone what they obviously already know is generally not a
34595 good idea. Especially when they spent a very long paragraph defending
34596 their decision in the first place.
34598 This is the coding list, not the feature request list. He asked for
34599 code design approaches, not for political insight.
34604 From diego at redesul.net Thu Sep 18 16:29:40 2003
34605 From: diego at redesul.net (Diego B. Contezini)
34606 Date: Sat Oct 23 23:10:03 2004
34607 Subject: [IRCServices Coding] Re: How to get a core..
34608 Message-ID: <001c01c37e2d$c95d7840$3cc8a8c0@angel>
34610 Oooopz, im answering my ask...
34611 Looking in FAQ, where i should look before ask (sorry), I seen that you need
34612 to change ./configure to drop a core.
34613 If someone more is needing it, is just configure with:
34614 ./configure -dumpcore -cflags -g -defaults
34620 ----- Original Message -----
34621 From: "Diego B. Contezini" <diego@redesul.net>
34622 To: <ircservices-coding@ircservices.za.net>
34623 Sent: Thursday, September 18, 2003 6:35 PM
34624 Subject: How to get a core..
34627 > Hello, im destruct_, im the administrator of the RedeSul Network.
34628 > (irc.redesul.net).
34629 > I'm with 28000 nick registers, sometimes our network get 5500 simultaneous
34630 > users, and we are very happy with your services.
34631 > Im wanting to help to search and stops bugs on ircservices, but i never
34634 > I tryed ulimit -c unlimited before run it, but it never drop a core...
34635 > Someone have any idea about how i can get it, to debug without need to
34637 > the services while debugging?
34638 > Its segfaulting approx. all days, one time for day.. sometimes get 2 days
34639 > without to go down.
34640 > Im with a redhat 9.
34644 > Diego B. Contezini aka destruct_ | irc.redesul.net
34645 > (Sorry for my confuse english.)
34649 From diego at redesul.net Thu Sep 18 17:12:05 2003
34650 From: diego at redesul.net (Diego B. Contezini)
34651 Date: Sat Oct 23 23:10:04 2004
34652 Subject: [IRCServices Coding] How to get a core..
34653 References: <Law14-F109aJWJVUn700006a187@hotmail.com>
34654 Message-ID: <000901c37e2c$b8bd9980$3cc8a8c0@angel>
34656 Hello, im destruct_, im the administrator of the RedeSul Network.
34658 I'm with 28000 nick registers, sometimes our network get 5500 simultaneous
34659 users, and we are very happy with your services.
34660 Im wanting to help to search and stops bugs on ircservices, but i never get
34662 I tryed ulimit -c unlimited before run it, but it never drop a core...
34663 Someone have any idea about how i can get it, to debug without need to break
34664 the services while debugging?
34665 Its segfaulting approx. all days, one time for day.. sometimes get 2 days
34666 without to go down.
34667 Im with a redhat 9.
34671 Diego B. Contezini aka destruct_ | irc.redesul.net
34672 (Sorry for my confuse english.)
34675 From engin at piratetv.net Sun Sep 21 09:37:08 2003
34676 From: engin at piratetv.net (engin@piratetv)
34677 Date: Sat Oct 23 23:10:04 2004
34678 Subject: [IRCServices Coding] operserv
34679 Message-ID: <002101c3805f$0910a4c0$c7cf87d4@ptv91i58zrrpyd>
34683 can anyone help or point me to some good documentation regarding a
34684 version of unreal ircd we are running on a mandrake linux box..im mailing
34685 on behalf of the administrator who usually uses ssh to get into the box
34686 and make changes so im not super technical myself.the issue is with
34687 operserv..i cant access any operserv commands from my machine ( which
34688 is on the same local network as the box running the irc server ) always
34689 get operserv - access denied message..so im assuming it doesent
34690 recognise my remote ip address at an administrator..does anyone know
34691 the right sort of commands to use to set my remote machine to be
34692 recognised as admin or can they point me to any good support docs
34693 as i havent been able to find any yet
34697 -------------- next part --------------
34698 An HTML attachment was scrubbed...
34699 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030921/fdc12b4e/attachment-0002.htm
34700 From Craig at chatspike.net Sun Sep 21 14:28:23 2003
34701 From: Craig at chatspike.net (Craig McLure)
34702 Date: Sat Oct 23 23:10:04 2004
34703 Subject: [IRCServices Coding] operserv
34704 Message-ID: <E1A1Bk4-0001Xo-00@ptb-mailc04.plus.net>
34706 make sure you are on the services administrator list, if you are not, get the root administrator to add you using the command:
34708 [22:27] -OperServ- Syntax: ADMIN ADD nickname
34709 [22:27] -OperServ- ADMIN DEL nickname
34710 [22:27] -OperServ- ADMIN LIST
34712 [22:27] -OperServ- Allows the Services super-user to add or remove nicknames
34713 [22:27] -OperServ- to or from the Services admin list. A user whose nickname
34714 [22:27] -OperServ- is on the Services admin list and who has identified to
34715 [22:27] -OperServ- NickServ will be able to access Services admin commands.
34717 [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the command.
34718 [22:27] -OperServ- All other use limited to Services super-user.
34722 /****************************************
34723 * Craig "FrostyCoolSlug" McLure
34724 ************* - SpamBox - **************
34725 * InspIRCd - http://www.inspircd.org
34726 * ChatSpike - http://www.chatspike.net
34727 * WinBot - http://www.winbot.co.uk
34728 ****************************************/
34730 /****************************************
34731 * From - engin <engin@piratetv.net>
34732 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
34733 * Sent - 2003-09-21 @ 17:40:00
34734 * Subject - [IRCServices Coding] operserv
34735 ****************************************/
34737 /****** - Begin Original Message - ******/
34741 >can anyone help or point me to some good documentation regarding a
34742 >version of unreal ircd we are running on a mandrake linux box..im mailing
34743 >on behalf of the administrator who usually uses ssh to get into the box
34744 >and make changes so im not super technical myself.the issue is with
34745 >operserv..i cant access any operserv commands from my machine ( which
34746 >is on the same local network as the box running the irc server ) always
34747 >get operserv - access denied message..so im assuming it doesent
34748 >recognise my remote ip address at an administrator..does anyone know
34749 >the right sort of commands to use to set my remote machine to be
34750 >recognised as admin or can they point me to any good support docs
34751 >as i havent been able to find any yet
34755 >------------------------------------------------------------------
34756 >To unsubscribe or change your subscription options, visit:
34757 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
34759 /******* - End Original Message - *******/
34763 From saturn at jetirc.net Sun Sep 21 15:24:25 2003
34764 From: saturn at jetirc.net (Saturn)
34765 Date: Sat Oct 23 23:10:04 2004
34766 Subject: [IRCServices Coding] operserv
34767 References: <002101c3805f$0910a4c0$c7cf87d4@ptv91i58zrrpyd>
34768 Message-ID: <002b01c3808e$f2590ee0$6401a8c0@turby>
34770 Contact me directly... I have quite a bit of experience with unreal and these services...
34774 ----- Original Message -----
34775 From: engin@piratetv
34776 To: ircservices-coding@ircservices.za.net
34777 Sent: Sunday, September 21, 2003 9:40 AM
34778 Subject: [IRCServices Coding] operserv
34783 can anyone help or point me to some good documentation regarding a
34784 version of unreal ircd we are running on a mandrake linux box..im mailing
34785 on behalf of the administrator who usually uses ssh to get into the box
34786 and make changes so im not super technical myself.the issue is with
34787 operserv..i cant access any operserv commands from my machine ( which
34788 is on the same local network as the box running the irc server ) always
34789 get operserv - access denied message..so im assuming it doesent
34790 recognise my remote ip address at an administrator..does anyone know
34791 the right sort of commands to use to set my remote machine to be
34792 recognised as admin or can they point me to any good support docs
34793 as i havent been able to find any yet
34800 ------------------------------------------------------------------------------
34803 ------------------------------------------------------------------
34804 To unsubscribe or change your subscription options, visit:
34805 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
34806 -------------- next part --------------
34807 An HTML attachment was scrubbed...
34808 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030921/ca188e06/attachment-0002.html
34809 From saturn at jetirc.net Sun Sep 21 17:14:42 2003
34810 From: saturn at jetirc.net (Saturn)
34811 Date: Sat Oct 23 23:10:04 2004
34812 Subject: [IRCServices Coding] operserv
34813 References: <E1A1Bk4-0001Xo-00@ptb-mailc04.plus.net>
34814 Message-ID: <000d01c3809e$5b9d2800$6401a8c0@turby>
34816 Not to mention the obvious: You need to have an O:line and be opered up
34817 before Operserv will even listen to your commands without access denied....
34819 ----- Original Message -----
34820 From: "Craig McLure" <Craig@chatspike.net>
34821 To: "IRC Services Coding Mailing List"
34822 <ircservices-coding@ircservices.za.net>
34823 Sent: Sunday, September 21, 2003 3:28 PM
34824 Subject: Re: [IRCServices Coding] operserv
34827 make sure you are on the services administrator list, if you are not, get
34828 the root administrator to add you using the command:
34830 [22:27] -OperServ- Syntax: ADMIN ADD nickname
34831 [22:27] -OperServ- ADMIN DEL nickname
34832 [22:27] -OperServ- ADMIN LIST
34834 [22:27] -OperServ- Allows the Services super-user to add or remove nicknames
34835 [22:27] -OperServ- to or from the Services admin list. A user whose nickname
34836 [22:27] -OperServ- is on the Services admin list and who has identified to
34837 [22:27] -OperServ- NickServ will be able to access Services admin commands.
34839 [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
34841 [22:27] -OperServ- All other use limited to Services super-user.
34845 /****************************************
34846 * Craig "FrostyCoolSlug" McLure
34847 ************* - SpamBox - **************
34848 * InspIRCd - http://www.inspircd.org
34849 * ChatSpike - http://www.chatspike.net
34850 * WinBot - http://www.winbot.co.uk
34851 ****************************************/
34853 /****************************************
34854 * From - engin <engin@piratetv.net>
34855 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
34856 * Sent - 2003-09-21 @ 17:40:00
34857 * Subject - [IRCServices Coding] operserv
34858 ****************************************/
34860 /****** - Begin Original Message - ******/
34864 >can anyone help or point me to some good documentation regarding a
34865 >version of unreal ircd we are running on a mandrake linux box..im mailing
34866 >on behalf of the administrator who usually uses ssh to get into the box
34867 >and make changes so im not super technical myself.the issue is with
34868 >operserv..i cant access any operserv commands from my machine ( which
34869 >is on the same local network as the box running the irc server ) always
34870 >get operserv - access denied message..so im assuming it doesent
34871 >recognise my remote ip address at an administrator..does anyone know
34872 >the right sort of commands to use to set my remote machine to be
34873 >recognised as admin or can they point me to any good support docs
34874 >as i havent been able to find any yet
34878 >------------------------------------------------------------------
34879 >To unsubscribe or change your subscription options, visit:
34880 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
34882 /******* - End Original Message - *******/
34885 ------------------------------------------------------------------
34886 To unsubscribe or change your subscription options, visit:
34887 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
34890 From engin at piratetv.net Mon Sep 22 05:13:57 2003
34891 From: engin at piratetv.net (engin@piratetv)
34892 Date: Sat Oct 23 23:10:04 2004
34893 Subject: [IRCServices Coding] Re: IRCServices-Coding Digest, Vol 8, Issue 5
34894 References: <20030922120923.425971706D@snow.fingers.co.za>
34895 Message-ID: <003c01c38103$73a516f0$c7cf87d4@ptv91i58zrrpyd>
34897 many thanks for the replies..im going to get the info to the
34898 root administrator now and ill let you know how i get
34905 ----- Original Message -----
34906 From: <ircservices-coding-request@ircservices.za.net>
34907 To: <ircservices-coding@ircservices.za.net>
34908 Sent: Monday, September 22, 2003 1:09 PM
34909 Subject: IRCServices-Coding Digest, Vol 8, Issue 5
34912 > Send IRCServices-Coding mailing list submissions to
34913 > ircservices-coding@ircservices.za.net
34915 > To subscribe or unsubscribe via the World Wide Web, visit
34916 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
34917 > or, via email, send a message with subject or body 'help' to
34918 > ircservices-coding-request@ircservices.za.net
34920 > You can reach the person managing the list at
34921 > ircservices-coding-owner@ircservices.za.net
34923 > When replying, please edit your Subject line so it is more specific
34924 > than "Re: Contents of IRCServices-Coding digest..."
34929 > 1. operserv (engin@piratetv)
34930 > 2. Re: operserv (Craig McLure)
34931 > 3. Re: operserv (Saturn)
34932 > 4. Re: operserv (Saturn)
34935 > ----------------------------------------------------------------------
34938 > Date: Sun, 21 Sep 2003 17:40:15 +0100
34939 > From: "engin@piratetv" <engin@piratetv.net>
34940 > Subject: [IRCServices Coding] operserv
34941 > To: <ircservices-coding@ircservices.za.net>
34942 > Message-ID: <002101c3805f$0910a4c0$c7cf87d4@ptv91i58zrrpyd>
34943 > Content-Type: text/plain; charset="iso-8859-1"
34947 > can anyone help or point me to some good documentation regarding a
34948 > version of unreal ircd we are running on a mandrake linux box..im mailing
34949 > on behalf of the administrator who usually uses ssh to get into the box
34950 > and make changes so im not super technical myself.the issue is with
34951 > operserv..i cant access any operserv commands from my machine ( which
34952 > is on the same local network as the box running the irc server ) always
34953 > get operserv - access denied message..so im assuming it doesent
34954 > recognise my remote ip address at an administrator..does anyone know
34955 > the right sort of commands to use to set my remote machine to be
34956 > recognised as admin or can they point me to any good support docs
34957 > as i havent been able to find any yet
34961 > -------------- next part --------------
34962 > An HTML attachment was scrubbed...
34964 http://snow.fingers.co.za/pipermail/ircservices-coding/attachments/20030921/
34965 fdc12b4e/attachment-0001.htm
34967 > ------------------------------
34970 > Date: Sun, 21 Sep 2003 22:28:13 +0000
34971 > From: "Craig McLure" <Craig@chatspike.net>
34972 > Subject: Re: [IRCServices Coding] operserv
34973 > To: IRC Services Coding Mailing List
34974 > <ircservices-coding@ircservices.za.net>
34975 > Message-ID: <E1A1Bk4-0001Xo-00@ptb-mailc04.plus.net>
34976 > Content-Type: text/plain; charset="us-ascii"
34978 > make sure you are on the services administrator list, if you are not, get
34979 the root administrator to add you using the command:
34981 > [22:27] -OperServ- Syntax: ADMIN ADD nickname
34982 > [22:27] -OperServ- ADMIN DEL nickname
34983 > [22:27] -OperServ- ADMIN LIST
34984 > [22:27] -OperServ-
34985 > [22:27] -OperServ- Allows the Services super-user to add or remove
34987 > [22:27] -OperServ- to or from the Services admin list. A user whose
34989 > [22:27] -OperServ- is on the Services admin list and who has identified to
34990 > [22:27] -OperServ- NickServ will be able to access Services admin
34992 > [22:27] -OperServ-
34993 > [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
34995 > [22:27] -OperServ- All other use limited to Services super-user.
34999 > /****************************************
35000 > * Craig "FrostyCoolSlug" McLure
35001 > ************* - SpamBox - **************
35002 > * InspIRCd - http://www.inspircd.org
35003 > * ChatSpike - http://www.chatspike.net
35004 > * WinBot - http://www.winbot.co.uk
35005 > ****************************************/
35007 > /****************************************
35008 > * From - engin <engin@piratetv.net>
35009 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
35010 > * Sent - 2003-09-21 @ 17:40:00
35011 > * Subject - [IRCServices Coding] operserv
35012 > ****************************************/
35014 > /****** - Begin Original Message - ******/
35018 > >can anyone help or point me to some good documentation regarding a
35019 > >version of unreal ircd we are running on a mandrake linux box..im mailing
35020 > >on behalf of the administrator who usually uses ssh to get into the box
35021 > >and make changes so im not super technical myself.the issue is with
35022 > >operserv..i cant access any operserv commands from my machine ( which
35023 > >is on the same local network as the box running the irc server ) always
35024 > >get operserv - access denied message..so im assuming it doesent
35025 > >recognise my remote ip address at an administrator..does anyone know
35026 > >the right sort of commands to use to set my remote machine to be
35027 > >recognised as admin or can they point me to any good support docs
35028 > >as i havent been able to find any yet
35032 > >------------------------------------------------------------------
35033 > >To unsubscribe or change your subscription options, visit:
35034 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
35036 > /******* - End Original Message - *******/
35040 > ------------------------------
35043 > Date: Sun, 21 Sep 2003 15:23:13 -0700
35044 > From: "Saturn" <saturn@jetirc.net>
35045 > Subject: Re: [IRCServices Coding] operserv
35046 > To: "IRC Services Coding Mailing List"
35047 > <ircservices-coding@ircservices.za.net>
35048 > Message-ID: <002b01c3808e$f2590ee0$6401a8c0@turby>
35049 > Content-Type: text/plain; charset="iso-8859-1"
35051 > Contact me directly... I have quite a bit of experience with unreal and
35056 > ----- Original Message -----
35057 > From: engin@piratetv
35058 > To: ircservices-coding@ircservices.za.net
35059 > Sent: Sunday, September 21, 2003 9:40 AM
35060 > Subject: [IRCServices Coding] operserv
35065 > can anyone help or point me to some good documentation regarding a
35066 > version of unreal ircd we are running on a mandrake linux box..im
35068 > on behalf of the administrator who usually uses ssh to get into the box
35069 > and make changes so im not super technical myself.the issue is with
35070 > operserv..i cant access any operserv commands from my machine ( which
35071 > is on the same local network as the box running the irc server ) always
35072 > get operserv - access denied message..so im assuming it doesent
35073 > recognise my remote ip address at an administrator..does anyone know
35074 > the right sort of commands to use to set my remote machine to be
35075 > recognised as admin or can they point me to any good support docs
35076 > as i havent been able to find any yet
35083 > --------------------------------------------------------------------------
35087 > ------------------------------------------------------------------
35088 > To unsubscribe or change your subscription options, visit:
35089 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
35090 > -------------- next part --------------
35091 > An HTML attachment was scrubbed...
35093 http://snow.fingers.co.za/pipermail/ircservices-coding/attachments/20030921/
35094 ca188e06/attachment-0001.htm
35096 > ------------------------------
35099 > Date: Sun, 21 Sep 2003 17:13:31 -0700
35100 > From: "Saturn" <saturn@jetirc.net>
35101 > Subject: Re: [IRCServices Coding] operserv
35102 > To: "IRC Services Coding Mailing List"
35103 > <ircservices-coding@ircservices.za.net>
35104 > Message-ID: <000d01c3809e$5b9d2800$6401a8c0@turby>
35105 > Content-Type: text/plain; charset="iso-8859-1"
35107 > Not to mention the obvious: You need to have an O:line and be opered up
35108 > before Operserv will even listen to your commands without access
35111 > ----- Original Message -----
35112 > From: "Craig McLure" <Craig@chatspike.net>
35113 > To: "IRC Services Coding Mailing List"
35114 > <ircservices-coding@ircservices.za.net>
35115 > Sent: Sunday, September 21, 2003 3:28 PM
35116 > Subject: Re: [IRCServices Coding] operserv
35119 > make sure you are on the services administrator list, if you are not, get
35120 > the root administrator to add you using the command:
35122 > [22:27] -OperServ- Syntax: ADMIN ADD nickname
35123 > [22:27] -OperServ- ADMIN DEL nickname
35124 > [22:27] -OperServ- ADMIN LIST
35125 > [22:27] -OperServ-
35126 > [22:27] -OperServ- Allows the Services super-user to add or remove
35128 > [22:27] -OperServ- to or from the Services admin list. A user whose
35130 > [22:27] -OperServ- is on the Services admin list and who has identified to
35131 > [22:27] -OperServ- NickServ will be able to access Services admin
35133 > [22:27] -OperServ-
35134 > [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
35136 > [22:27] -OperServ- All other use limited to Services super-user.
35140 > /****************************************
35141 > * Craig "FrostyCoolSlug" McLure
35142 > ************* - SpamBox - **************
35143 > * InspIRCd - http://www.inspircd.org
35144 > * ChatSpike - http://www.chatspike.net
35145 > * WinBot - http://www.winbot.co.uk
35146 > ****************************************/
35148 > /****************************************
35149 > * From - engin <engin@piratetv.net>
35150 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
35151 > * Sent - 2003-09-21 @ 17:40:00
35152 > * Subject - [IRCServices Coding] operserv
35153 > ****************************************/
35155 > /****** - Begin Original Message - ******/
35159 > >can anyone help or point me to some good documentation regarding a
35160 > >version of unreal ircd we are running on a mandrake linux box..im mailing
35161 > >on behalf of the administrator who usually uses ssh to get into the box
35162 > >and make changes so im not super technical myself.the issue is with
35163 > >operserv..i cant access any operserv commands from my machine ( which
35164 > >is on the same local network as the box running the irc server ) always
35165 > >get operserv - access denied message..so im assuming it doesent
35166 > >recognise my remote ip address at an administrator..does anyone know
35167 > >the right sort of commands to use to set my remote machine to be
35168 > >recognised as admin or can they point me to any good support docs
35169 > >as i havent been able to find any yet
35173 > >------------------------------------------------------------------
35174 > >To unsubscribe or change your subscription options, visit:
35175 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
35177 > /******* - End Original Message - *******/
35180 > ------------------------------------------------------------------
35181 > To unsubscribe or change your subscription options, visit:
35182 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
35185 > ------------------------------
35187 > _______________________________________________
35188 > IRCServices-Coding mailing list
35189 > IRCServices-Coding@ircservices.za.net
35190 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
35193 > End of IRCServices-Coding Digest, Vol 8, Issue 5
35194 > ************************************************
35197 From diego at redesul.net Sun Oct 5 22:45:19 2003
35198 From: diego at redesul.net (Diego B. Contezini)
35199 Date: Sat Oct 23 23:10:04 2004
35200 Subject: [IRCServices Coding] Bug....
35201 References: <E1A1Bk4-0001Xo-00@ptb-mailc04.plus.net>
35202 <000d01c3809e$5b9d2800$6401a8c0@turby>
35203 Message-ID: <003b01c38b91$5f6a32e0$3cc8a8c0@angel>
35205 Sometimes has occur this bug, last 1 year....
35206 on a network with 30k registers, its happening with latency of 3.. 4
35209 someone have any idea?
35211 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
35212 av=0xbfffeec8) at channels.c:278
35215 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
35216 av=0xbfffeec8) at channels.c:278
35217 chan = (Channel *) 0xa97b6b8
35218 s = 0x20656c62 <Address 0x20656c62 out of bounds>
35220 modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
35221 #1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:680
35223 "-isl\000\037\006\bp?????????@???\006\b\000\000\000\000\000\000\000B\000\000
35224 \000\0007 \006\b\003\000\000\000TZ\000\000????????????
35225 ?????????\001\200??????@???\006\b@???\006\b@???\006\b@???\006\bO???\006\b@\0
35226 02\a\b@???\006\b@\002\a\b", '\0' <repeats 20 times>,
35227 "\027\000\000\000\000\000\000\000W???\022B\000\000\000\000\000\000\000\000\0
35228 05\000\000\000\210o\a\bTZ\000\000\000\000\000\000???????????????<\023B\001\0
35229 00\000\000???????????????m\tBd???\022B???q\a\b\v???\006B\024\032\023B\024\03
35230 2\023B3\035\rB\024\032\023B??????\006B\003\000\000\000????????????\027\000\0
35231 00\000\000\000\000\000\024\032"...
35232 s = 0xbfffeef0 "-isl"
35233 argv = {0xa97b6c0 "#young", 0x20656c62 <Address 0x20656c62 out of
35235 0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 out
35236 of bounds>, 0x42133cec "\004", 0xbffff1fc "",
35237 0x4204533d "\201?????????\016", 0x42131a14 " \031\023B???h\001@`???"}
35241 #2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
35245 md = (struct modedata *) 0x0
35250 #3 0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at main.c:269
35252 now_msec = 241253125
35253 last_update = 1065392973
35254 last_check = 241252363
35255 #4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
35256 No symbol table info available.
35261 From achurch at achurch.org Mon Oct 6 00:41:54 2003
35262 From: achurch at achurch.org (Andrew Church)
35263 Date: Sat Oct 23 23:10:04 2004
35264 Subject: [IRCServices Coding] Bug....
35265 In-Reply-To: <003b01c38b91$5f6a32e0$3cc8a8c0@angel>
35266 Message-ID: <3f811cad.24262@achurch.org>
35271 achurch@achurch.org
35272 http://achurch.org/
35274 >Sometimes has occur this bug, last 1 year....
35275 >on a network with 30k registers, its happening with latency of 3.. 4
35278 >someone have any idea?
35280 >#0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
35281 >av=0xbfffeec8) at channels.c:278
35284 >#0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
35285 >av=0xbfffeec8) at channels.c:278
35286 > chan = (Channel *) 0xa97b6b8
35287 > s = 0x20656c62 <Address 0x20656c62 out of bounds>
35289 > modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
35290 >#1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:68
35293 >"-isl\000\037\006\bp���@�\006\b\000\000\0
35294 >00\000\000\000\000B\000\000
35295 >\000\0007 \006\b\003\000\000\000TZ\000\000���ï¿
35297 >���\001\200��@�\006\b@ï
35298 >¿½\006\b@�\006\b@�\006\bO�\006\b@\0
35299 >02\a\b@�\006\b@\002\a\b", '\0' <repeats 20 times>,
35300 >"\027\000\000\000\000\000\000\000W�\022B\000\000\000\000\000\000\
35302 >05\000\000\000\210o\a\bTZ\000\000\000\000\000\000��ï¿
35303 >½ï¿½ï¿½<\023B\001\0
35304 >00\000\000�����m\tBd�\022
35305 >B�q\a\b\v�\006B\024\032\023B\024\03
35306 >2\023B3\035\rB\024\032\023B��\006B\003\000\000\000�
35308 >00\000\000\000\000\000\024\032"...
35309 > s = 0xbfffeef0 "-isl"
35310 > argv = {0xa97b6c0 "#young", 0x20656c62 <Address 0x20656c62 out
35313 > 0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 o
35315 >of bounds>, 0x42133cec "\004", 0xbffff1fc "",
35316 > 0x4204533d "\201���\016", 0x42131a14 " \031\023
35321 >#2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:32
35326 > md = (struct modedata *) 0x0
35331 >#3 0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at ma
35334 > now_msec = 241253125
35335 > last_update = 1065392973
35336 > last_check = 241252363
35337 >#4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
35338 >No symbol table info available.
35342 >------------------------------------------------------------------
35343 >To unsubscribe or change your subscription options, visit:
35344 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
35346 From diego at redesul.net Mon Oct 6 02:36:40 2003
35347 From: diego at redesul.net (Diego B. Contezini)
35348 Date: Sat Oct 23 23:10:04 2004
35349 Subject: [IRCServices Coding] Bug....
35350 References: <3f811cad.24262@achurch.org>
35351 Message-ID: <005501c38bed$4c9b1dd0$3cc8a8c0@angel>
35354 ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
35358 Its the last version.......
35361 ----- Original Message -----
35362 From: "Andrew Church" <achurch@achurch.org>
35363 To: <ircservices-coding@ircservices.za.net>
35364 Sent: Monday, October 06, 2003 4:41 AM
35365 Subject: Re: [IRCServices Coding] Bug....
35371 > achurch@achurch.org
35372 > http://achurch.org/
35374 > >Sometimes has occur this bug, last 1 year....
35375 > >on a network with 30k registers, its happening with latency of 3.. 4
35378 > >someone have any idea?
35380 > >#0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
35381 > >av=0xbfffeec8) at channels.c:278
35382 > >278 while (*s) {
35384 > >#0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
35385 > >av=0xbfffeec8) at channels.c:278
35386 > > chan = (Channel *) 0xa97b6b8
35387 > > s = 0x20656c62 <Address 0x20656c62 out of bounds>
35389 > > modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
35390 > >#1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:68
35393 > >"-isl\000\037\006\bp?????????@???\006\b\000\000\0
35394 > >00\000\000\000\000B\000\000
35395 > >\000\0007 \006\b\003\000\000\000TZ\000\000???????????
35397 > >?????????\001\200??????@???\006\b@?
35398 > >??\006\b@???\006\b@???\006\bO???\006\b@\0
35399 > >02\a\b@???\006\b@\002\a\b", '\0' <repeats 20 times>,
35400 > >"\027\000\000\000\000\000\000\000W???\022B\000\000\000\000\000\000\
35402 > >05\000\000\000\210o\a\bTZ\000\000\000\000\000\000????????
35403 > >???????<\023B\001\0
35404 > >00\000\000???????????????m\tBd???\022
35405 > >B???q\a\b\v???\006B\024\032\023B\024\03
35406 > >2\023B3\035\rB\024\032\023B??????\006B\003\000\000\000???
35407 > >?????????\027\000\0
35408 > >00\000\000\000\000\000\024\032"...
35409 > > s = 0xbfffeef0 "-isl"
35410 > > argv = {0xa97b6c0 "#young", 0x20656c62 <Address 0x20656c62 out
35413 > > 0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 o
35415 > >of bounds>, 0x42133cec "\004", 0xbffff1fc "",
35416 > > 0x4204533d "\201?????????\016", 0x42131a14 " \031\023
35417 > >B???h\001@`???"}
35421 > >#2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:32
35425 > > modes_orig = 0x0
35426 > > md = (struct modedata *) 0x0
35431 > >#3 0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at ma
35433 > > now = 1065393142
35434 > > now_msec = 241253125
35435 > > last_update = 1065392973
35436 > > last_check = 241252363
35437 > >#4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
35438 > >No symbol table info available.
35442 > >------------------------------------------------------------------
35443 > >To unsubscribe or change your subscription options, visit:
35444 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
35445 > ------------------------------------------------------------------
35446 > To unsubscribe or change your subscription options, visit:
35447 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
35451 From achurch at achurch.org Mon Oct 6 06:45:43 2003
35452 From: achurch at achurch.org (Andrew Church)
35453 Date: Sat Oct 23 23:10:04 2004
35454 Subject: [IRCServices Coding] Bug....
35455 In-Reply-To: <005501c38bed$4c9b1dd0$3cc8a8c0@angel>
35456 Message-ID: <3f8171f9.25006@achurch.org>
35459 >ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
35463 >Its the last version.......
35465 Then send a full debug log (from startup to crash), or I can't help.
35468 achurch@achurch.org
35469 http://achurch.org/
35471 From diego at redesul.net Mon Oct 6 17:16:29 2003
35472 From: diego at redesul.net (Diego B. Contezini)
35473 Date: Sat Oct 23 23:10:04 2004
35474 Subject: [IRCServices Coding] Bug....
35475 References: <3f8171f9.25006@achurch.org>
35476 Message-ID: <010601c38c68$2e6dc8a0$3cc8a8c0@angel>
35478 And how should be this log? i sent a backtrace......
35481 ----- Original Message -----
35482 From: "Andrew Church" <achurch@achurch.org>
35483 To: <ircservices-coding@ircservices.za.net>
35484 Sent: Monday, October 06, 2003 10:44 AM
35485 Subject: Re: [IRCServices Coding] Bug....
35489 > >ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
35490 > >18:41:36 BRT 2003
35493 > >Its the last version.......
35495 > Then send a full debug log (from startup to crash), or I can't help.
35498 > achurch@achurch.org
35499 > http://achurch.org/
35500 > ------------------------------------------------------------------
35501 > To unsubscribe or change your subscription options, visit:
35502 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
35506 From achurch at achurch.org Mon Oct 6 19:32:07 2003
35507 From: achurch at achurch.org (Andrew Church)
35508 Date: Sat Oct 23 23:10:04 2004
35509 Subject: [IRCServices Coding] Bug....
35510 In-Reply-To: <010601c38c68$2e6dc8a0$3cc8a8c0@angel>
35511 Message-ID: <3f822598.26100@achurch.org>
35513 >And how should be this log? i sent a backtrace......
35518 achurch@achurch.org
35519 http://achurch.org/
35521 From diego at redesul.net Mon Oct 6 22:36:40 2003
35522 From: diego at redesul.net (Diego B. Contezini)
35523 Date: Sat Oct 23 23:10:04 2004
35524 Subject: [IRCServices Coding] Bug....
35525 References: <3f822598.26100@achurch.org>
35526 Message-ID: <011601c38c94$ebc3ec00$3cc8a8c0@angel>
35529 If i start it with -debug it will get me gb's of information. This occur
35530 after days with services up, i will try to run it into a screen.... with
35535 ----- Original Message -----
35536 From: "Andrew Church" <achurch@achurch.org>
35537 To: <ircservices-coding@ircservices.za.net>
35538 Sent: Monday, October 06, 2003 11:31 PM
35539 Subject: Re: [IRCServices Coding] Bug....
35542 > >And how should be this log? i sent a backtrace......
35547 > achurch@achurch.org
35548 > http://achurch.org/
35549 > ------------------------------------------------------------------
35550 > To unsubscribe or change your subscription options, visit:
35551 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
35555 From saturn at jetirc.net Fri Oct 10 15:48:47 2003
35556 From: saturn at jetirc.net (Saturn)
35557 Date: Sat Oct 23 23:10:04 2004
35558 Subject: [IRCServices Coding] Akill problem in 5.0.22
35559 References: <14C7EDD0-DC1B-11D7-8505-0003938D6866@mac.com>
35560 Message-ID: <004001c38f80$9f635960$6401a8c0@turby>
35562 Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
35563 duplicate exit system notice that happens in 3.1.6).
35565 I just today added an akill (+0 time) .. I DO have the immediate auto kill
35566 option un-commented in the modules.conf, but it still didn't bother scanning
35567 for victims matching my akill mask nor did it actually KILL anyone... It
35568 works if they are manually killed and then try to re-connect, but I thought
35569 that new option was so Services will immediately scan for and kill anyone
35570 online that matches the mask as soon as the new akill is added...
35572 First: IS that what it's supposed to do?
35574 Second: If so, it's not working...
35580 From laser at musichat.net Sat Oct 11 00:56:04 2003
35581 From: laser at musichat.net (Alessandro Ciappei)
35582 Date: Sat Oct 23 23:10:04 2004
35583 Subject: [IRCServices Coding] Problem with auth mail
35584 In-Reply-To: <20031007101106.2701D1703F@snow.fingers.co.za>
35585 Message-ID: <GMEFIDBHIMPENBMIJNFEEEGDCAAA.laser@musichat.net>
35588 Hi all, I've ircservices 5.0.22, and I would like to costumize auth-mail.
35589 I would like describe my irc network in this mail, but when someone register
35590 nick, services go in segfault.
35592 I copy the sintaz of mail-auth ( it's in italian )
35594 # Mail text. The last "%s" (before the user@host) in the body text is
35595 # replaced by one of the NICK_AUTH_MAIL_TEXT_* messages.
35596 NICK_AUTH_MAIL_SUBJECT
35597 Conferma della registrazione del nick %s
35598 NICK_AUTH_MAIL_BODY
35599 Grazie per aver scelto MusiChat Net Community!
35600 Il codice di autorizzazione del tuo nick (%s) e': %09d
35601 Identificati su MusiChat digitando:
35604 La registrazione del tuo nick sara' confermata e il tuo nickname
35605 sara' protetto da eventuali tentativi di abuso o furto.
35607 Il sito ufficiale della rete e' http://www.musichat.net/
35608 I regolamenti della rete e i documenti ufficiali sono
35609 disponibili all'interno del sito.
35611 Per ricevere assistenza sui servizi della rete
35612 in generale puoi rivolgerti sul canale ufficiale #IRCHelp
35613 oppure tramite email all'indirizzo irchelp@musichat.net.
35616 Sono inoltre disponibili i seguenti servizi:
35619 Forum di discussione di MusiChat, raggiungibile
35620 all'indirizzo http://forum.musichat.net
35621 Sul forum, oltre a poter esprimere la tua opinione,
35622 potrai informarti sulle novita' e sui nuovi servizi
35623 offerti dalla rete.
35625 - MusiChat Mailing List
35626 Per iscriversi e' sufficiente visitare il sito
35627 http://lists.musichat.net/mailman/listinfo/irchelp
35628 e inserire il proprio indirizzo E-Mail e la
35629 password desiderata.
35632 Per una connessione piu' veloce e sicura e' vivamente
35633 consigliato l'utilizzo del seguente server: irc.musichat.net
35635 MusiChat Net Community
35637 Questo messaggio e stato inviato su richiesta di %s in risposta a %s
35643 I read the istruction for translate.
35647 [Oct 11 09:48:30 2003] PANIC! buffer = :alpha_omega ! nickserv :register
35648 pippo laser@musichat.net
35649 [Oct 11 09:48:30 2003] Services terminating: Segmentation fault
35652 Some one can help me?
35653 the email body is too long?
35661 From achurch at achurch.org Thu Oct 16 23:58:34 2003
35662 From: achurch at achurch.org (Andrew Church)
35663 Date: Sat Oct 23 23:10:04 2004
35664 Subject: [IRCServices Coding] Problem with auth mail
35665 In-Reply-To: <GMEFIDBHIMPENBMIJNFEEEGDCAAA.laser@musichat.net>
35666 Message-ID: <3f8f9304.20227@achurch.org>
35668 You have the wrong number of %-tokens in your message.
35671 achurch@achurch.org
35672 http://achurch.org/
35675 >Hi all, I've ircservices 5.0.22, and I would like to costumize auth-mail.
35676 >I would like describe my irc network in this mail, but when someone register
35677 >nick, services go in segfault.
35679 >I copy the sintaz of mail-auth ( it's in italian )
35681 ># Mail text. The last "%s" (before the user@host) in the body text is
35682 ># replaced by one of the NICK_AUTH_MAIL_TEXT_* messages.
35683 >NICK_AUTH_MAIL_SUBJECT
35684 > Conferma della registrazione del nick %s
35685 >NICK_AUTH_MAIL_BODY
35686 > Grazie per aver scelto MusiChat Net Community!
35687 > Il codice di autorizzazione del tuo nick (%s) e': %09d
35688 > Identificati su MusiChat digitando:
35689 > /msg %s AUTH %09d
35691 > La registrazione del tuo nick sara' confermata e il tuo nickname
35692 > sara' protetto da eventuali tentativi di abuso o furto.
35694 > Il sito ufficiale della rete e' http://www.musichat.net/
35695 > I regolamenti della rete e i documenti ufficiali sono
35696 > disponibili all'interno del sito.
35698 > Per ricevere assistenza sui servizi della rete
35699 > in generale puoi rivolgerti sul canale ufficiale #IRCHelp
35700 > oppure tramite email all'indirizzo irchelp@musichat.net.
35703 > Sono inoltre disponibili i seguenti servizi:
35706 > Forum di discussione di MusiChat, raggiungibile
35707 > all'indirizzo http://forum.musichat.net
35708 > Sul forum, oltre a poter esprimere la tua opinione,
35709 > potrai informarti sulle novita' e sui nuovi servizi
35710 > offerti dalla rete.
35712 > - MusiChat Mailing List
35713 > Per iscriversi e' sufficiente visitare il sito
35714 > http://lists.musichat.net/mailman/listinfo/irchelp
35715 > e inserire il proprio indirizzo E-Mail e la
35716 > password desiderata.
35719 > Per una connessione piu' veloce e sicura e' vivamente
35720 > consigliato l'utilizzo del seguente server: irc.musichat.net
35722 > MusiChat Net Community
35724 > Questo messaggio e stato inviato su richiesta di %s in risposta a %s
35730 >I read the istruction for translate.
35734 >[Oct 11 09:48:30 2003] PANIC! buffer = :alpha_omega ! nickserv :register
35735 >pippo laser@musichat.net
35736 >[Oct 11 09:48:30 2003] Services terminating: Segmentation fault
35739 >Some one can help me?
35740 >the email body is too long?
35747 >------------------------------------------------------------------
35748 >To unsubscribe or change your subscription options, visit:
35749 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
35751 From saman at alkol.org Fri Oct 17 03:07:31 2003
35752 From: saman at alkol.org (|SaMaN|)
35753 Date: Sat Oct 23 23:10:04 2004
35754 Subject: [IRCServices Coding] Bug or misunderstood ?
35755 Message-ID: <000901c39496$71764f10$a37faec3@coder>
35757 Im using unreal ircd. When channel is empty and if channel owner joins
35758 his/her registered channel it does
35759 (ChanServ sets mode: +ntrq nick) but when channel is not empty and if
35760 channel owner joins his/her registered channel it does (ChanServ sets mode:
35761 +oq nick nick). As you see on the first one there is no +o and because of
35762 this chanserv does not update the last_used time because chanserv is set to
35763 update last_used time with +o (CUMODE_o) so channels drop while channel
35764 owners use them. Is this a bug or my misunderstood ?
35766 ######################################################
35767 modules/chanserv/check.c
35769 void check_chan_user_modes(const char *source, struct c_userlist *u,
35770 Channel *c, int32 oldmodes)
35772 if ((res & ~modes) & CUMODE_o) {
35773 ci->last_used = time(NULL);
35774 put_channelinfo(ci);
35777 ######################################################
35783 From saman at alkol.org Fri Oct 17 04:53:04 2003
35784 From: saman at alkol.org (|SaMaN|)
35785 Date: Sat Oct 23 23:10:04 2004
35786 Subject: [IRCServices Coding] Re: Bug or misunderstood ?
35787 Message-ID: <002001c394a5$31c059b0$a37faec3@coder>
35789 Also it does not update last_used time on +a flag.
35794 edit /modules/chanserv/check.c
35797 -------------------------------------------------------------------------
35798 local_set_cumodes(c, '+', res & ~modes, user->nick);
35799 -------------------------------------------------------------------------
35801 ------------------------------------------------------------------------
35802 int16 cumode_q = mode_char_to_flag('q',MODE_CHANUSER);
35803 int16 cumode_a = mode_char_to_flag('a',MODE_CHANUSER);
35805 if ((res & ~modes) & cumode_q) {
35806 ci->last_used = time(NULL);
35807 put_channelinfo(ci);
35810 if ((res & ~modes) & cumode_a) {
35811 ci->last_used = time(NULL);
35812 put_channelinfo(ci);
35814 -------------------------------------------------------------------------
35815 save and compile and run and enjoy :)
35816 -------------------------------------------------------------------------
35820 ----- Original Message -----
35821 From: "|SaMaN|" <saman@alkol.org>
35822 To: <IRCServices-Coding@ircservices.za.net>
35823 Sent: Friday, October 17, 2003 1:07 PM
35824 Subject: Bug or misunderstood ?
35827 > Im using unreal ircd. When channel is empty and if channel owner joins
35828 > his/her registered channel it does
35829 > (ChanServ sets mode: +ntrq nick) but when channel is not empty and if
35830 > channel owner joins his/her registered channel it does (ChanServ sets
35832 > +oq nick nick). As you see on the first one there is no +o and because of
35833 > this chanserv does not update the last_used time because chanserv is set
35835 > update last_used time with +o (CUMODE_o) so channels drop while channel
35836 > owners use them. Is this a bug or my misunderstood ?
35838 > ######################################################
35839 > modules/chanserv/check.c
35841 > void check_chan_user_modes(const char *source, struct c_userlist *u,
35842 > Channel *c, int32 oldmodes)
35844 > if ((res & ~modes) & CUMODE_o) {
35845 > ci->last_used = time(NULL);
35846 > put_channelinfo(ci);
35849 > ######################################################
35856 From saturn at jetirc.net Fri Oct 17 08:47:59 2003
35857 From: saturn at jetirc.net (Saturn)
35858 Date: Sat Oct 23 23:10:04 2004
35859 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
35860 Message-ID: <002501c394c5$f8dce480$6401a8c0@turby>
35862 Haven't seen a reply to this one, so thought I'd better make sure this went
35865 ----- Original Message -----
35866 Sent: Friday, October 10, 2003 3:48 PM
35867 Subject: Akill problem in 5.0.22
35870 Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
35871 duplicate exit system notice that happens in 3.1.6).
35873 I just today added an akill (+0 time) .. I DO have the immediate auto kill
35874 option un-commented in the modules.conf, but it still didn't bother scanning
35875 for victims matching my akill mask nor did it actually KILL anyone... It
35876 works if they are manually killed and then try to re-connect, but I thought
35877 that new option was so Services will immediately scan for and kill anyone
35878 online that matches the mask as soon as the new akill is added...
35880 First: IS that what it's supposed to do?
35882 Second: If so, it's not working...
35888 From achurch at achurch.org Fri Oct 17 09:03:19 2003
35889 From: achurch at achurch.org (Andrew Church)
35890 Date: Sat Oct 23 23:10:04 2004
35891 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
35892 In-Reply-To: <002501c394c5$f8dce480$6401a8c0@turby>
35893 Message-ID: <3f9012b8.23176@achurch.org>
35898 achurch@achurch.org
35899 http://achurch.org/
35901 >Haven't seen a reply to this one, so thought I'd better make sure this went
35904 >----- Original Message -----
35905 >Sent: Friday, October 10, 2003 3:48 PM
35906 >Subject: Akill problem in 5.0.22
35909 >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
35910 >duplicate exit system notice that happens in 3.1.6).
35912 >I just today added an akill (+0 time) .. I DO have the immediate auto kill
35913 >option un-commented in the modules.conf, but it still didn't bother scanning
35914 >for victims matching my akill mask nor did it actually KILL anyone... It
35915 >works if they are manually killed and then try to re-connect, but I thought
35916 >that new option was so Services will immediately scan for and kill anyone
35917 >online that matches the mask as soon as the new akill is added...
35919 >First: IS that what it's supposed to do?
35921 >Second: If so, it's not working...
35926 >------------------------------------------------------------------
35927 >To unsubscribe or change your subscription options, visit:
35928 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
35930 From saturn at jetirc.net Fri Oct 17 09:19:32 2003
35931 From: saturn at jetirc.net (Saturn)
35932 Date: Sat Oct 23 23:10:04 2004
35933 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
35934 References: <3f9012b8.23176@achurch.org>
35935 Message-ID: <027401c394ca$443ae180$6401a8c0@turby>
35937 Well, Andrew, I did read TFM. For what it's worth, all I found was this
35938 entry under the description of the module options
35940 ImmediatelySendAutokill [OPTIONAL]
35941 Causes OperServ to inform all servers of a new autokill or autokill
35942 exclusion the moment it is added, rather than waiting for someone to match
35944 Example: ImmediatelySendAutokill
35946 I read through the section about AKILLs and SQline, SGline, SZline, etc,
35947 however all of what I read indicates that simply enabling the
35948 ImmediatelySendAutokill option in the modules.conf (coupled with the fact
35949 that everything ELSE is set up and workign properly) SHOULD cause services
35950 to immediately scan the network for clients matching the akill mask, and
35953 My point, sir, is that IT DOES NOT DO THIS. Thus, I'm sure you'll find, I
35954 HAVE in fact read the f___ manual, and the manual does not address this
35955 problem. If it doesn't matter to you, fine, but if it does, let's try and
35956 get on with maybe solving the problem?
35961 ----- Original Message -----
35962 From: "Andrew Church" <achurch@achurch.org>
35963 To: <ircservices-coding@ircservices.za.net>
35964 Sent: Friday, October 17, 2003 9:02 AM
35965 Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
35971 achurch@achurch.org
35972 http://achurch.org/
35974 >Haven't seen a reply to this one, so thought I'd better make sure this went
35977 >----- Original Message -----
35978 >Sent: Friday, October 10, 2003 3:48 PM
35979 >Subject: Akill problem in 5.0.22
35982 >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
35983 >duplicate exit system notice that happens in 3.1.6).
35985 >I just today added an akill (+0 time) .. I DO have the immediate auto kill
35986 >option un-commented in the modules.conf, but it still didn't bother
35988 >for victims matching my akill mask nor did it actually KILL anyone... It
35989 >works if they are manually killed and then try to re-connect, but I thought
35990 >that new option was so Services will immediately scan for and kill anyone
35991 >online that matches the mask as soon as the new akill is added...
35993 >First: IS that what it's supposed to do?
35995 >Second: If so, it's not working...
36000 >------------------------------------------------------------------
36001 >To unsubscribe or change your subscription options, visit:
36002 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
36003 ------------------------------------------------------------------
36004 To unsubscribe or change your subscription options, visit:
36005 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
36008 From achurch at achurch.org Fri Oct 17 09:34:48 2003
36009 From: achurch at achurch.org (Andrew Church)
36010 Date: Sat Oct 23 23:10:04 2004
36011 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
36012 In-Reply-To: <027401c394ca$443ae180$6401a8c0@turby>
36013 Message-ID: <3f901a20.23266@achurch.org>
36015 >however all of what I read indicates that simply enabling the
36016 >ImmediatelySendAutokill option in the modules.conf (coupled with the fact
36017 >that everything ELSE is set up and workign properly) SHOULD cause services
36018 >to immediately scan the network for clients matching the akill mask, and
36021 The documentation says nothing about this. RTFM again.
36024 achurch@achurch.org
36025 http://achurch.org/
36027 From ballsy at mystical.net Fri Oct 17 11:20:33 2003
36028 From: ballsy at mystical.net (Ballsy)
36029 Date: Sat Oct 23 23:10:04 2004
36030 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
36031 In-Reply-To: <027401c394ca$443ae180$6401a8c0@turby>
36032 References: <3f9012b8.23176@achurch.org> <027401c394ca$443ae180$6401a8c0@turby>
36033 Message-ID: <6.0.0.22.0.20031017121557.01b63ac0@127.0.0.1>
36035 To save the rest of us from having to put up with more bickering,
36036 it may be of note that I had to comment out 'EnableExclude' in order for my
36037 immediate-kill functionality to work under bahamut (I know, you're using
36038 Unreal). All the ImmediatelySendAkill does is informs all linked services
36039 that they should add an Akill. It's then up to those servers to decide how
36045 At 10:18 AM 17/10/2003, Saturn wrote:
36046 >Well, Andrew, I did read TFM. For what it's worth, all I found was this
36047 >entry under the description of the module options
36049 >ImmediatelySendAutokill [OPTIONAL]
36050 > Causes OperServ to inform all servers of a new autokill or autokill
36051 >exclusion the moment it is added, rather than waiting for someone to match
36053 > Example: ImmediatelySendAutokill
36055 >I read through the section about AKILLs and SQline, SGline, SZline, etc,
36056 >however all of what I read indicates that simply enabling the
36057 >ImmediatelySendAutokill option in the modules.conf (coupled with the fact
36058 >that everything ELSE is set up and workign properly) SHOULD cause services
36059 >to immediately scan the network for clients matching the akill mask, and
36062 >My point, sir, is that IT DOES NOT DO THIS. Thus, I'm sure you'll find, I
36063 >HAVE in fact read the f___ manual, and the manual does not address this
36064 >problem. If it doesn't matter to you, fine, but if it does, let's try and
36065 >get on with maybe solving the problem?
36070 >----- Original Message -----
36071 >From: "Andrew Church" <achurch@achurch.org>
36072 >To: <ircservices-coding@ircservices.za.net>
36073 >Sent: Friday, October 17, 2003 9:02 AM
36074 >Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
36080 > achurch@achurch.org
36081 > http://achurch.org/
36083 > >Haven't seen a reply to this one, so thought I'd better make sure this went
36086 > >----- Original Message -----
36087 > >Sent: Friday, October 10, 2003 3:48 PM
36088 > >Subject: Akill problem in 5.0.22
36091 > >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
36092 > >duplicate exit system notice that happens in 3.1.6).
36094 > >I just today added an akill (+0 time) .. I DO have the immediate auto kill
36095 > >option un-commented in the modules.conf, but it still didn't bother
36097 > >for victims matching my akill mask nor did it actually KILL anyone... It
36098 > >works if they are manually killed and then try to re-connect, but I thought
36099 > >that new option was so Services will immediately scan for and kill anyone
36100 > >online that matches the mask as soon as the new akill is added...
36102 > >First: IS that what it's supposed to do?
36104 > >Second: If so, it's not working...
36109 > >------------------------------------------------------------------
36110 > >To unsubscribe or change your subscription options, visit:
36111 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
36112 >------------------------------------------------------------------
36113 >To unsubscribe or change your subscription options, visit:
36114 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
36116 >------------------------------------------------------------------
36117 >To unsubscribe or change your subscription options, visit:
36118 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
36122 From saturn at jetirc.net Fri Oct 17 17:16:26 2003
36123 From: saturn at jetirc.net (Saturn)
36124 Date: Sat Oct 23 23:10:04 2004
36125 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
36126 References: <3f901a20.23266@achurch.org>
36127 Message-ID: <02d401c3950c$e762bda0$6401a8c0@turby>
36129 >From a.html in the /docs directory:
36131 operserv/akill (Autokill module settings)
36132 ImmediatelySendAutokill [OPTIONAL]
36133 Causes OperServ to inform all servers of a new autokill or autokill
36134 exclusion the moment it is added, rather than waiting for someone to match
36136 Example: ImmediatelySendAutokill
36139 3.html#4-3 in the /docs directory does not speak to the
36140 ImmediatelySendAutokill option except for the mention that:
36141 "(If the ImmediatelySendAutokill option in modules.conf is enabled, the
36142 last-used time will never be set at all on these servers.)"
36143 However, this is in the context of talking about Slines, etc, and as far as
36144 I can tell has no new useful information to impart regarding my stated
36145 problem: that services is NOT "Immediately sending the autokill" on my
36146 network and thus when a new AKILL is added, the matching users/masks are not
36147 being killed off, unless they are killed manually by an IRCop. Yes, it IS
36148 catching them when they attempt to re-connect, that was never a problem. It
36149 would make sense that if an autokill is added, that Services would
36150 immediately trace the network and kill off any matches to that akill... at
36151 least, it makes sense if this option is enabled.... (to me)
36152 ------------------------
36154 4.html#oper.akill doesn't mention it at all.
36158 I really don't see where else I'm supposed to be looking here. I've scoured
36159 the docs and can see no other reference to it. If there's something I'm
36160 missing, perhaps instead of rudely, repeatedly telling me to RTFM, maybe
36161 just tell me what it is I'm supposed to find! I've already spend a few
36162 hours reading through the docs (which I've already read about a dozen times
36163 over the past year alone), and I'm telling you, there's nothing else about
36164 it that I can find!!!
36166 The ONLY thing I can come up with is that the feature name is misleading and
36167 the option doesn't in fact do what it SEEMS it should do. Could it be that
36168 all that does is send the S/G/Z line (whatever is appropriate) to the
36169 servers and that's all??? NOW I have to ask, why bother, if it'll do that
36170 if/when they re-connect anyhow?
36172 Additionally, if the reason I can't find the answer in the manual is because
36173 the option DOESN'T make services kill all matches when the akill is added,
36174 then Imust ask WHY that isn't an option, since it seems logically useful to
36175 me and my staff. Also, that being the case, why couldn't you simply SAY
36176 that it's not designed to do that, instead of sending me hunting (TWICE) for
36177 non-existant information in the docs???????
36179 I'm very interested to hear the answer to these questions. To put it
36180 bluntly, I have been an extremely enthusiastic advocate of IRCServices for
36181 over 3 years now, have turned many network owners onto them, and love them
36182 to death. The way you "talk" to your supporters on this forum sometimes
36183 leaves a LOT to be desired. If the feature doesn't exist as I understand
36184 it, just SAY SO and save us all a lot of trouble -- don't just tell me to go
36185 RTFM when the info I seek isn't IN it. Having said that, if you can point
36186 me to the info in the docs in the 5.0.22 distro and prove my claims as
36187 baseless, I will offer my sincere apologies. Until then, my opinion stands.
36191 ----- Original Message -----
36192 From: "Andrew Church" <achurch@achurch.org>
36193 To: <ircservices-coding@ircservices.za.net>
36194 Sent: Friday, October 17, 2003 9:34 AM
36195 Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
36198 >however all of what I read indicates that simply enabling the
36199 >ImmediatelySendAutokill option in the modules.conf (coupled with the fact
36200 >that everything ELSE is set up and workign properly) SHOULD cause services
36201 >to immediately scan the network for clients matching the akill mask, and
36204 The documentation says nothing about this. RTFM again.
36207 achurch@achurch.org
36208 http://achurch.org/
36209 ------------------------------------------------------------------
36210 To unsubscribe or change your subscription options, visit:
36211 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
36214 From saturn at jetirc.net Fri Oct 17 17:33:57 2003
36215 From: saturn at jetirc.net (Saturn)
36216 Date: Sat Oct 23 23:10:06 2004
36217 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
36218 References: <3f9012b8.23176@achurch.org> <027401c394ca$443ae180$6401a8c0@turby>
36219 <6.0.0.22.0.20031017121557.01b63ac0@127.0.0.1>
36220 Message-ID: <030801c3950f$3cb55270$6401a8c0@turby>
36222 Would have been nice if someone had mentioned that (about the
36223 ImmediatelySendAutokill) from the start. I would say the flag is misleading
36224 in title then, because I (and 8 other people on my staff -- none of us are
36225 dummies, either) read that as meaning it will Immediately send the auto
36226 kill... "ImmediatelyUpdateServers" might be more fitting from an intuitive
36227 standpoint, not that I'm suggesting changing the name, but at least the
36228 documentation of it could be a bit more explicit IMHO.
36230 and yes, I know there will be about 50 people (probably all of them
36231 hard-core coders) shaking their heads in disbelief at what I've said, but
36232 let's face it: If we were ALL hard-core coders, we wouldn't need Andrew and
36233 his IRCServices, would we? We'd all be making our own. So all I'm saying
36234 is how about a little slack for those of us with OTHER important skills that
36235 might fall outside the scope of being the "world's greatest expert" on IRC
36238 ----- Original Message -----
36239 From: "Ballsy" <ballsy@mystical.net>
36240 To: "IRC Services Coding Mailing List"
36241 <ircservices-coding@ircservices.za.net>; "IRC Services Coding Mailing List"
36242 <ircservices-coding@ircservices.za.net>
36243 Sent: Friday, October 17, 2003 11:20 AM
36244 Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
36247 To save the rest of us from having to put up with more bickering,
36248 it may be of note that I had to comment out 'EnableExclude' in order for my
36249 immediate-kill functionality to work under bahamut (I know, you're using
36250 Unreal). All the ImmediatelySendAkill does is informs all linked services
36251 that they should add an Akill. It's then up to those servers to decide how
36257 At 10:18 AM 17/10/2003, Saturn wrote:
36258 >Well, Andrew, I did read TFM. For what it's worth, all I found was this
36259 >entry under the description of the module options
36261 >ImmediatelySendAutokill [OPTIONAL]
36262 > Causes OperServ to inform all servers of a new autokill or autokill
36263 >exclusion the moment it is added, rather than waiting for someone to match
36265 > Example: ImmediatelySendAutokill
36267 >I read through the section about AKILLs and SQline, SGline, SZline, etc,
36268 >however all of what I read indicates that simply enabling the
36269 >ImmediatelySendAutokill option in the modules.conf (coupled with the fact
36270 >that everything ELSE is set up and workign properly) SHOULD cause services
36271 >to immediately scan the network for clients matching the akill mask, and
36274 >My point, sir, is that IT DOES NOT DO THIS. Thus, I'm sure you'll find, I
36275 >HAVE in fact read the f___ manual, and the manual does not address this
36276 >problem. If it doesn't matter to you, fine, but if it does, let's try and
36277 >get on with maybe solving the problem?
36282 >----- Original Message -----
36283 >From: "Andrew Church" <achurch@achurch.org>
36284 >To: <ircservices-coding@ircservices.za.net>
36285 >Sent: Friday, October 17, 2003 9:02 AM
36286 >Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
36292 > achurch@achurch.org
36293 > http://achurch.org/
36295 > >Haven't seen a reply to this one, so thought I'd better make sure this
36299 > >----- Original Message -----
36300 > >Sent: Friday, October 10, 2003 3:48 PM
36301 > >Subject: Akill problem in 5.0.22
36304 > >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
36305 > >duplicate exit system notice that happens in 3.1.6).
36307 > >I just today added an akill (+0 time) .. I DO have the immediate auto
36309 > >option un-commented in the modules.conf, but it still didn't bother
36311 > >for victims matching my akill mask nor did it actually KILL anyone... It
36312 > >works if they are manually killed and then try to re-connect, but I
36314 > >that new option was so Services will immediately scan for and kill anyone
36315 > >online that matches the mask as soon as the new akill is added...
36317 > >First: IS that what it's supposed to do?
36319 > >Second: If so, it's not working...
36324 > >------------------------------------------------------------------
36325 > >To unsubscribe or change your subscription options, visit:
36326 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
36327 >------------------------------------------------------------------
36328 >To unsubscribe or change your subscription options, visit:
36329 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
36331 >------------------------------------------------------------------
36332 >To unsubscribe or change your subscription options, visit:
36333 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
36336 ------------------------------------------------------------------
36337 To unsubscribe or change your subscription options, visit:
36338 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
36341 From Craig at chatspike.net Fri Oct 17 19:07:33 2003
36342 From: Craig at chatspike.net (Craig McLure)
36343 Date: Sat Oct 23 23:10:06 2004
36344 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
36345 Message-ID: <E1AAgV1-0008ae-00@ptb-mailc04.plus.net>
36347 Theres no need for flaming ffs.. just because something makes less sence to you than to everyone else, doesnt instantly mean that it has to be changed.. i seemed to understand it ok, and i'm sure that there are several hundred other IRCServices users who didnt have any problems with this directive.
36349 I'm sure andy will concider documenting it more "accuratly" (I wont speak for him thou, his choice :p), but theres no need for the flaming, if you have such a big problem with something that (apparently just) you dont understand, just make a passing mention on it, dont go on talking about "Hard-core coders" and "worlds biggest expert"s cause you are upset with something. If the last paragraph wasnt made, i'm sure there _WOUDLNT_ be "about 50 people (probably all of them hard-core coders) shaking their heads in disbelief", cause it doesnt happen. And to clarify.. theres no such thing as a "world biggest expert" when it comes to IRC programming, people have different preferances, and ways of doing things, to the point that you cant compair something like InspIRCd to UnrealIRCd, as they are totally different in almost every way. :p
36351 Please just calm down, and talk this out rationally before you start jumping down ppls throats :p
36353 /*****************************************
36354 * Craig "FrostyCoolSlug" McLure
36355 * InspIRCd - http://www.inspircd.org
36356 * ChatSpike - http://www.chatspike.net
36357 ****************************************/
36360 /****************************************
36361 * From - Saturn <saturn@jetirc.net>
36362 * To - IRC Services Coding Mailing List <ircservices-coding@ircservices.za.net>
36363 * Sent - 2003-10-17 17:31:00
36364 * Subject - Re: [IRCServices Coding] Re: Akill problem in 5.0.22
36365 ****************************************/
36367 /****** - Begin Original Message - ******/
36369 >Would have been nice if someone had mentioned that (about the
36370 >ImmediatelySendAutokill) from the start. I would say the flag is misleading
36371 >in title then, because I (and 8 other people on my staff -- none of us are
36372 >dummies, either) read that as meaning it will Immediately send the auto
36373 >kill... "ImmediatelyUpdateServers" might be more fitting from an intuitive
36374 >standpoint, not that I'm suggesting changing the name, but at least the
36375 >documentation of it could be a bit more explicit IMHO.
36377 >and yes, I know there will be about 50 people (probably all of them
36378 >hard-core coders) shaking their heads in disbelief at what I've said, but
36379 >let's face it: If we were ALL hard-core coders, we wouldn't need Andrew and
36380 >his IRCServices, would we? We'd all be making our own. So all I'm saying
36381 >is how about a little slack for those of us with OTHER important skills that
36382 >might fall outside the scope of being the "world's greatest expert" on IRC
36385 >----- Original Message -----
36386 >From: "Ballsy" <ballsy@mystical.net>
36387 >To: "IRC Services Coding Mailing List"
36388 ><ircservices-coding@ircservices.za.net>; "IRC Services Coding Mailing List"
36389 ><ircservices-coding@ircservices.za.net>
36390 >Sent: Friday, October 17, 2003 11:20 AM
36391 >Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
36394 > To save the rest of us from having to put up with more bickering,
36395 >it may be of note that I had to comment out 'EnableExclude' in order for my
36396 >immediate-kill functionality to work under bahamut (I know, you're using
36397 >Unreal). All the ImmediatelySendAkill does is informs all linked services
36398 >that they should add an Akill. It's then up to those servers to decide how
36404 >At 10:18 AM 17/10/2003, Saturn wrote:
36405 >>Well, Andrew, I did read TFM. For what it's worth, all I found was this
36406 >>entry under the description of the module options
36408 >>ImmediatelySendAutokill [OPTIONAL]
36409 >> Causes OperServ to inform all servers of a new autokill or autokill
36410 >>exclusion the moment it is added, rather than waiting for someone to match
36412 >> Example: ImmediatelySendAutokill
36414 >>I read through the section about AKILLs and SQline, SGline, SZline, etc,
36415 >>however all of what I read indicates that simply enabling the
36416 >>ImmediatelySendAutokill option in the modules.conf (coupled with the fact
36417 >>that everything ELSE is set up and workign properly) SHOULD cause services
36418 >>to immediately scan the network for clients matching the akill mask, and
36421 >>My point, sir, is that IT DOES NOT DO THIS. Thus, I'm sure you'll find, I
36422 >>HAVE in fact read the f___ manual, and the manual does not address this
36423 >>problem. If it doesn't matter to you, fine, but if it does, let's try and
36424 >>get on with maybe solving the problem?
36429 >>----- Original Message -----
36430 >>From: "Andrew Church" <achurch@achurch.org>
36431 >>To: <ircservices-coding@ircservices.za.net>
36432 >>Sent: Friday, October 17, 2003 9:02 AM
36433 >>Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
36439 >> achurch@achurch.org
36440 >> http://achurch.org/
36442 >> >Haven't seen a reply to this one, so thought I'd better make sure this
36446 >> >----- Original Message -----
36447 >> >Sent: Friday, October 10, 2003 3:48 PM
36448 >> >Subject: Akill problem in 5.0.22
36451 >> >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
36452 >> >duplicate exit system notice that happens in 3.1.6).
36454 >> >I just today added an akill (+0 time) .. I DO have the immediate auto
36456 >> >option un-commented in the modules.conf, but it still didn't bother
36458 >> >for victims matching my akill mask nor did it actually KILL anyone... It
36459 >> >works if they are manually killed and then try to re-connect, but I
36461 >> >that new option was so Services will immediately scan for and kill anyone
36462 >> >online that matches the mask as soon as the new akill is added...
36464 >> >First: IS that what it's supposed to do?
36466 >> >Second: If so, it's not working...
36471 >> >------------------------------------------------------------------
36472 >> >To unsubscribe or change your subscription options, visit:
36473 >> >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
36474 >>------------------------------------------------------------------
36475 >>To unsubscribe or change your subscription options, visit:
36476 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
36478 >>------------------------------------------------------------------
36479 >>To unsubscribe or change your subscription options, visit:
36480 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
36483 >------------------------------------------------------------------
36484 >To unsubscribe or change your subscription options, visit:
36485 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
36487 >------------------------------------------------------------------
36488 >To unsubscribe or change your subscription options, visit:
36489 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
36493 /******* - End Original Message - *******/
36498 From achurch at achurch.org Fri Oct 17 20:13:46 2003
36499 From: achurch at achurch.org (Andrew Church)
36500 Date: Sat Oct 23 23:10:06 2004
36501 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
36502 In-Reply-To: <02d401c3950c$e762bda0$6401a8c0@turby>
36503 Message-ID: <3f90afdf.23477@achurch.org>
36505 You know, I might have been more forgiving if this hadn't been gone
36506 over on this list (twice!) before:
36508 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/002305.html
36509 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/003215.html
36511 However, since you seem to have trouble both comprehending the
36512 documentation and reading the archives, I have added FAQ F.10 for your
36515 F.10. Services doesn't kill users matching a newly-added autokill mask even
36516 if ImmediatelySendAutokill is set.
36518 Services never kills users when a new autokill is added; the
36519 ImmediatelySendAutokill configuration directive only causes
36520 Services to send the autokill itself (that is, the user/host mask
36521 to prohibit new connections from) to the IRC servers on your
36522 network. This is a safety feature intended to limit the damage
36523 caused by a mistyped autokill.
36525 Note that some IRC servers will themselves kill users matching a
36526 newly-added autokill; this is unrelated to Services.
36529 achurch@achurch.org
36530 http://achurch.org/
36532 From griever at t2n.org Fri Oct 17 21:23:14 2003
36533 From: griever at t2n.org (Robert F Merrill)
36534 Date: Sat Oct 23 23:10:06 2004
36535 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
36536 In-Reply-To: <030801c3950f$3cb55270$6401a8c0@turby>
36537 References: <3f9012b8.23176@achurch.org> <027401c394ca$443ae180$6401a8c0@turby>
36538 <6.0.0.22.0.20031017121557.01b63ac0@127.0.0.1>
36539 <030801c3950f$3cb55270$6401a8c0@turby>
36540 Message-ID: <3F90BF77.2010706@t2n.org>
36544 >Would have been nice if someone had mentioned that (about the
36545 >ImmediatelySendAutokill) from the start. I would say the flag is misleading
36546 >in title then, because I (and 8 other people on my staff -- none of us are
36547 >dummies, either) read that as meaning it will Immediately send the auto
36548 >kill... "ImmediatelyUpdateServers" might be more fitting from an intuitive
36549 >standpoint, not that I'm suggesting changing the name, but at least the
36550 >documentation of it could be a bit more explicit IMHO.
36553 It DOES immediately send the autokill. You just don't grasp the meaning
36554 of sending the autokill.
36555 It literally sends an AKILL (or TKL in the case of unreal) message to
36556 the servers. At least unreal
36557 and bahamut will then scan for matching clients and disconnect them,
36558 however not all servers
36561 If you are using unreal and it doesn't disconnect the matching users,
36562 then it is either a bug in
36563 unreal (not uncommon) or the services really *aren't* sending the tkl
36564 message (doubt it).
36566 Try adding an akill for a connected client. If the client doesn't die,
36567 do a /stats g on their server.
36568 You should see a g-line added for them.
36570 Also note that if you have akill exclusions enabled (bad idea most of
36571 the time), services will NEVER add an akill
36572 or gline on servers that don't support akill or gline exclusions (I
36573 don't know of any that do), but rather
36574 manually kill everyone that matches as they connect. In this case, you
36575 should disable akill exclusions and
36576 it should start working.
36580 From v13 at it.teithe.gr Sat Oct 18 11:47:23 2003
36581 From: v13 at it.teithe.gr (V13)
36582 Date: Sat Oct 23 23:10:06 2004
36583 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
36584 In-Reply-To: <3F90BF77.2010706@t2n.org>
36585 References: <3f9012b8.23176@achurch.org> <030801c3950f$3cb55270$6401a8c0@turby>
36586 <3F90BF77.2010706@t2n.org>
36587 Message-ID: <200310182149.18600.v13@it.teithe.gr>
36589 On Saturday 18 October 2003 07:20, Robert F Merrill wrote:
36591 > >Would have been nice if someone had mentioned that (about the
36592 > >ImmediatelySendAutokill) from the start. I would say the flag is
36593 > > misleading in title then, because I (and 8 other people on my staff --
36594 > > none of us are dummies, either) read that as meaning it will Immediately
36595 > > send the auto kill... "ImmediatelyUpdateServers" might be more fitting
36596 > > from an intuitive standpoint, not that I'm suggesting changing the name,
36597 > > but at least the documentation of it could be a bit more explicit IMHO.
36599 > It DOES immediately send the autokill. You just don't grasp the meaning
36600 > of sending the autokill.
36601 > It literally sends an AKILL (or TKL in the case of unreal) message to
36602 > the servers. At least unreal
36603 > and bahamut will then scan for matching clients and disconnect them,
36604 > however not all servers
36607 FYI bahamut doesn't do this. It will only do it whenever a new client that
36608 matches the akill connects to the server.
36610 i.e. if you set an akill for *.com noone will be disconnected untill a new
36611 client from *.com gets connected (at that moment, all matching clients will
36612 be killed). In the mean time, anyone from other domains can connect to the
36613 server without having any user killed.
36617 From diego at redesul.net Sat Oct 18 12:17:04 2003
36618 From: diego at redesul.net (Diego B. Contezini)
36619 Date: Sat Oct 23 23:10:06 2004
36620 Subject: [IRCServices Coding] CORE DUMPED! BUG!
36621 References: <3f8f9304.20227@achurch.org>
36622 Message-ID: <000e01c395ac$5b773b40$3cc8a8c0@angel>
36624 Andrew, you told me about debugging.. now i got it ;]
36625 here is the debugging:
36626 [Oct 18 16:05:31.288944 2003] debug: Sent: :ChanServ TOPIC #EMOCORE reffer
36627 1066055037 :1i?? Festival HARDcoCOREcore dia 25 de outubro em blumenau no
36628 rio bravo bar (proximo a resima agua verde), com as bandas: Zero Ltda
36629 (curitiba), Swallow the Waffle (bc), chymia(bnu), crazy frogs (lages),
36630 surpise set e slipper (bnu)...3 pila entrada inicio as 15:00 horas'
36631 [Oct 18 16:05:31.289032 2003] debug: Received: :|-Frango-| MODE
36632 #EMOCORE -oooooo CHoPP CbRS-oFF caroll BRYAN brunaH balsanelli
36633 Segmentation fault (core dumped)
36635 root@irc(/home/ircadmin/services/lib)# ls -la core.12631
36636 -rw------- 1 ircadmin ircadmin 47374336 Oct 18 16:05 core.12631
36639 continue on the next message......
36642 From diego at redesul.net Sat Oct 18 12:17:32 2003
36643 From: diego at redesul.net (Diego B. Contezini)
36644 Date: Sat Oct 23 23:10:06 2004
36645 Subject: [IRCServices Coding] CORE DUMPED... continue...
36646 References: <3f8f9304.20227@achurch.org>
36647 Message-ID: <001201c395ac$71b42210$3cc8a8c0@angel>
36649 #0 0x0804d830 in add_mode_with_params (md=0x806aa00, mode=111 'o',
36650 is_add=1, params=1, parambuf=0xbfffe280 "balsanelli",
36651 len=10) at actions.c:568
36652 568 md->params[md->nopmodes][len] = 0;
36654 #0 0x0804d830 in add_mode_with_params (md=0x806aa00, mode=111 'o',
36655 is_add=1, params=1, parambuf=0xbfffe280 "balsanelli",
36656 len=10) at actions.c:568
36658 #1 0x0804d342 in set_cmode (sender=0x81db058 "ChanServ", channel=0xa905d00)
36661 "balsanelli\000\b\025\225\002BWi??\022B\024\032\023Bi??i??i??i??\000\000\000
36662 \000\034 \006\bi??i??i??i??hi??i??i??i??i??i??i??\025\224\004B\034
36663 \006\b\000\000\000\000i??m\tBdi??\022Bi??q\a\b\000\000\000\000eR :\0037[
36664 \0034#\003di??\022B\000\000\000\000i??\037\006\bi??\037\006\bi??i??i??i??$i?
36665 ?\006Bi??i??i??i??\bi??i??i??\000\000\000\000Hi??i??i??\025\224\004B@\002\a\
36666 b8i??i??i??6\020\aBpi??i??i??@i??\006\b@\002\a\b\000\000\000\000i??<\023BLi?
36667 ?i??i??=S\004B\024\032\023B\001\020\000\000@i??\006\bhi??i??i??\204i??\006Bp
36668 i??i??i??i??\037\006\b"...
36673 args = 0xbfffe6d0 "RDcoCOREcorei??i??i??i??o"
36674 modes = 0xbfffeae2 ""
36675 modes_orig = 0xbfffeae0 "+o"
36676 md = (struct modedata *) 0x806aa00
36681 #2 0x400895ff in local_set_cumodes (c=0xa905d00, plusminus=43 '+', modes=1,
36682 nick=0xab7f2e8 "balsanelli") at check.c:432
36684 modestr = "o\000\000 de outubro em blumenau no rio bravo bar
36685 (proximo a resima agua verde), com as bandas: Zero
36686 L\v\000\000\000(curitiba), \000\000\000\000low the Waff\000\000\000\000bc),
36687 chymia(bnu), crazy frogs (lages), surpise set e slipper (bnu).."...
36689 #3 0x40088d74 in check_chan_user_modes (source=0xbfffeed0 "|-Frango-|",
36690 u=0xab34ff0, c=0xa905d00, oldmodes=1)
36692 user = (User *) 0xab7f2d8
36693 ci = (ChannelInfo *) 0xa571940
36697 #4 0x400820ed in do_channel_umode_change (source=0xbfffeed0 "|-Frango-|",
36698 c=0xa905d00, u=0xab34ff0, oldmodes=1)
36701 #5 0x0805890d in call_callback_5 (module=0x806a5c0, id=23, arg1=0xbfffeed0,
36702 arg2=0xa905d00, arg3=0xab34ff0, arg4=0x1,
36703 arg5=0x0) at modules.c:666
36704 cl = (CallbackList *) 0x8077cb8
36707 #6 0x0804edc8 in do_cumode (source=0xbfffeed0 "|-Frango-|", chan=0xa905d00,
36708 flag=1, add=0, nick=0xbfffecc9 "balsanelli")
36709 ---Type <return> to continue, or q <return> to quit---
36711 u = (struct c_userlist *) 0xab34ff0
36712 user = (User *) 0xab7f2d8
36714 #7 0x0804e97e in do_cmode (source=0xbfffeed0 "|-Frango-|", ac=0,
36715 av=0xa853130) at channels.c:302
36718 params = -1073746288
36719 chan = (Channel *) 0xa905d00
36722 modestr = 0xbfffec9e "-oooooo"
36723 #8 0x080557ff in m_mode (source=0xbfffeed0 "|-Frango-|", ac=8,
36724 av=0xa853110) at messages.c:101
36726 #9 0x0805920e in process () at process.c:133
36727 m = (Message *) 0x8067dd8
36729 "|-Frango-|\000\000G\000\000\000Y\e\205\n\t+\205\n\bi??i??i??i??i??\005\b@j\
36730 a\b\000\004\000\000i??\032\205\n\t\000\000\000@j\a\b\216j\a\b(i??i??i??qP\00
36733 "MODE\000\000\000i??8i??i??i??i??\005\b\000\000\000\000i??i??i??i??\000\000\
36734 000\000\000\000\000\000\001H\000\000Pi??i??i??\000Y\a\bVi??\005\b\207j\a\bP\
36735 e\205\n\t\000\000\000i??i??\005\b"
36737 "MODE\000#EMOCORE\000-oooooo\000CHoPP\000CbRS-oFF\000caroll\000BRYAN\000brun
36738 aH\000balsanelli\000 balsanelli\000\000ai\00314ser \0030]\00315=\00314-
36739 S\00315c\0030ri\00315p\00314t \00315\037v\0373.8 \003\000\00315\037v\0373.8
36740 \003\000\000\0003)\000\0006\037\002Pi??Ti??\00313\037\002]\037\002\0036i??i?
36741 ? \000i??Ti??\00313\037\002]\037\002\0036i??i?? \000\000\003\000\000r
36742 \003", '\0' <repeats 11 times>...
36743 s = 0xbfffec95 "#EMOCORE"
36745 av = (char **) 0xa853110
36746 #10 0x0805507d in readline_callback (s=0xa851ae0, param_unused=0x50) at
36749 #11 0x0805b617 in check_sockets () at sockets.c:491
36750 newline = 0xa851b58 "\nrct-sc.br irc.creativenet.com.br 0 3364349034
36751 :aNiNhHa[du]DoNaTeLo\n:Toh_Pensanu PART #ilheus\n:_LoKo_SuL_ SJOIN
36752 1063565447 #elias\n:_MoRgAnA_ PRIVMSG NickServ@services.redesul.net :set
36753 nomemo off\n:irc."...
36756 rfds = {fds_bits = {16, 0 <repeats 31 times>}}
36757 wfds = {fds_bits = {0 <repeats 32 times>}}
36758 tv = {tv_sec = 2, tv_usec = 980000}
36761 s = (Socket *) 0xa851ae0
36762 s2 = (Socket *) 0x0
36763 #12 0x0805538a in main (ac=3, av=0xbffff164, envp=0xbffff174) at main.c:266
36764 ---Type <return> to continue, or q <return> to quit---
36766 now_msec = 1348441861
36767 last_update = 1066500208
36768 last_check = 1348441182
36769 #13 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
36770 No symbol table info available.
36775 From saturn at jetirc.net Sat Oct 18 12:18:40 2003
36776 From: saturn at jetirc.net (Saturn)
36777 Date: Sat Oct 23 23:10:06 2004
36778 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
36779 References: <3f90afdf.23477@achurch.org>
36780 Message-ID: <003701c395ac$9ff9fd20$6401a8c0@turby>
36782 I thank you for finally just coming out and telling me what I needed to know
36783 in the first place. Had you stated that it has been discussed before (even
36784 without the hyperlinks) I would have at least known to go look through the
36785 archives. However, all you said (then repeated) was RTFM. I DID read it,
36786 once before I asked, and twice more, at your instruction, and found nothing
36787 to answer my questions. Had I known it had already been discussed, I would
36788 certainly have tried to locate the answer that way.
36790 Thank you to all the others who've posted to try and explain what I was
36791 missing in my understanding of this directive. I got it now, and realize
36792 where my misinterpretation was. Seems obvious now, but frankly that
36793 directive managed to fool myself and 8 of my staff into thinking of it as I
36794 have previously described. Regardless, my apologies for any harsh words...
36795 I do stand by the fact that Andrew could have responded with a bit less
36796 apathy to the concerns raised; with something a bit less useless than RTFM
36797 (twice! even AFTER I said I had, THAT'S what pissed me off), and I hope that
36798 maybe Andrew will remember this chain of events for the next time someone
36799 has a problem that might be immediately obvious to Andrew, but not the
36800 person with the problem. I think most of us KNOW by now to read the docs
36801 before asking questions; but if the question arises due to misinterpretation
36802 of the docs, how would reading them over and over help?
36804 Thank you all for your time.
36808 ----- Original Message -----
36809 From: "Andrew Church" <achurch@achurch.org>
36810 To: <ircservices-coding@ircservices.za.net>
36811 Sent: Friday, October 17, 2003 7:57 PM
36812 Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
36815 You know, I might have been more forgiving if this hadn't been gone
36816 over on this list (twice!) before:
36818 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/002305.html
36819 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/003215.html
36821 However, since you seem to have trouble both comprehending the
36822 documentation and reading the archives, I have added FAQ F.10 for your
36825 F.10. Services doesn't kill users matching a newly-added autokill mask even
36826 if ImmediatelySendAutokill is set.
36828 Services never kills users when a new autokill is added; the
36829 ImmediatelySendAutokill configuration directive only causes
36830 Services to send the autokill itself (that is, the user/host mask
36831 to prohibit new connections from) to the IRC servers on your
36832 network. This is a safety feature intended to limit the damage
36833 caused by a mistyped autokill.
36835 Note that some IRC servers will themselves kill users matching a
36836 newly-added autokill; this is unrelated to Services.
36839 achurch@achurch.org
36840 http://achurch.org/
36841 ------------------------------------------------------------------
36842 To unsubscribe or change your subscription options, visit:
36843 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
36846 From diego at redesul.net Sat Oct 18 14:38:17 2003
36847 From: diego at redesul.net (Diego B. Contezini)
36848 Date: Sat Oct 23 23:10:06 2004
36849 Subject: [IRCServices Coding] CORE DUMPED... Debuging
36850 Message-ID: <003f01c395c0$09a31cd0$3cc8a8c0@angel>
36852 If it helps, more lines up.. of debugging...
36855 ChanServ@services.redesul.net :op #manaus paulinhu-dissi-q-mi-ama
36856 [Oct 18 16:05:31.152195 2003] debug: Sent: :ChanServ NOTICE paulinhu-dissi-q-mi-ama :Permission denied.
36857 [Oct 18 16:05:31.152274 2003] debug: Received: :pRiCkLy SJOIN 1066501295 #Euevc
36858 [Oct 18 16:05:31.152353 2003] protocol/bahamut: debug: pRiCkLy SJOINs #Euevc
36859 [Oct 18 16:05:31.152490 2003] debug: Sent: :ChanServ MODE #EUeVC +o pRiCkLy
36860 [Oct 18 16:05:31.269153 2003] debug: Received: :Hellskitty PRIVMSG ChanServ@services.redesul.net :unban #EMOCORE
36861 [Oct 18 16:05:31.269425 2003] debug: Sent: :ChanServ NOTICE Hellskitty :Permission denied.
36862 [Oct 18 16:05:31.288596 2003] debug: Received: :|-Frango-| MODE #EMOCORE +stmipl 1
36863 [Oct 18 16:05:31.288768 2003] debug: Received: :|-Frango-| TOPIC #EMOCORE |-Frango-| 1066460927 :TakeOver by 14,1 -15=0[ 14He15l0lR15ai14ser 0]15=14- S15c0ri15p14t 15v3.8
36864 [Oct 18 16:05:31.288944 2003] debug: Sent: :ChanServ TOPIC #EMOCORE reffer 1066055037 :1??? Festival HARDcoCOREcore dia 25 de outubro em blumenau no rio bravo bar (proximo a resima agua verde), com as bandas: Zero Ltda (curitiba), Swallow the Waffle (bc), chymia(bnu), crazy frogs (lages), surpise set e slipper (bnu)...3 pila entrada inicio as 15:00 horas'
36865 [Oct 18 16:05:31.289032 2003] debug: Received: :|-Frango-| MODE #EMOCORE -oooooo CHoPP CbRS-oFF caroll BRYAN brunaH balsanelli
36866 Segmentation fault (core dumped)
36868 -------------- next part --------------
36869 An HTML attachment was scrubbed...
36870 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20031018/667c67fa/attachment-0002.htm
36871 From ballsy at mystical.net Mon Oct 20 08:19:44 2003
36872 From: ballsy at mystical.net (Ballsy)
36873 Date: Sat Oct 23 23:10:06 2004
36874 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
36875 In-Reply-To: <200310182149.18600.v13@it.teithe.gr>
36876 References: <3f9012b8.23176@achurch.org> <030801c3950f$3cb55270$6401a8c0@turby>
36877 <3F90BF77.2010706@t2n.org> <200310182149.18600.v13@it.teithe.gr>
36878 Message-ID: <6.0.0.22.0.20031020091611.01b47318@127.0.0.1>
36880 Yes, Bahamut will immediately kill users matching an Akill. It
36881 won't wait for another client from that host to connect. My setup of IRC
36882 Services 5.0.22 and bahamut-1.4.30 is doing it right now. As alluded to in
36883 a previous email, however, you may need to commented out EnableExclude in
36884 the services config to have this work.
36889 At 12:49 PM 18/10/2003, V13 wrote:
36890 >On Saturday 18 October 2003 07:20, Robert F Merrill wrote:
36892 > > >Would have been nice if someone had mentioned that (about the
36893 > > >ImmediatelySendAutokill) from the start. I would say the flag is
36894 > > > misleading in title then, because I (and 8 other people on my staff --
36895 > > > none of us are dummies, either) read that as meaning it will Immediately
36896 > > > send the auto kill... "ImmediatelyUpdateServers" might be more fitting
36897 > > > from an intuitive standpoint, not that I'm suggesting changing the name,
36898 > > > but at least the documentation of it could be a bit more explicit IMHO.
36900 > > It DOES immediately send the autokill. You just don't grasp the meaning
36901 > > of sending the autokill.
36902 > > It literally sends an AKILL (or TKL in the case of unreal) message to
36903 > > the servers. At least unreal
36904 > > and bahamut will then scan for matching clients and disconnect them,
36905 > > however not all servers
36908 >FYI bahamut doesn't do this. It will only do it whenever a new client that
36909 >matches the akill connects to the server.
36911 >i.e. if you set an akill for *.com noone will be disconnected untill a new
36912 >client from *.com gets connected (at that moment, all matching clients will
36913 >be killed). In the mean time, anyone from other domains can connect to the
36914 >server without having any user killed.
36917 >------------------------------------------------------------------
36918 >To unsubscribe or change your subscription options, visit:
36919 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
36923 From oska at mynet.com Tue Oct 21 22:24:34 2003
36924 From: oska at mynet.com (oska)
36925 Date: Sat Oct 23 23:10:06 2004
36926 Subject: [IRCServices Coding] "Re: Contents of IRCServices-Coding digest..."
36927 Message-ID: <HN58ED$I890Q9pEOh0UN3QcHkNkg1Bm2fHspFZq@mynet.com>
36929 An HTML attachment was scrubbed...
36930 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20031022/9c540c11/attachment-0002.html
36931 From laser at musichat.net Fri Oct 24 10:35:48 2003
36932 From: laser at musichat.net (laser@musichat.net)
36933 Date: Sat Oct 23 23:10:06 2004
36934 Subject: [IRCServices Coding] Il momento e' catartico
36935 Message-ID: <20031024173545.9ACA817038@snow.fingers.co.za>
36937 Ricevo e cortesemente inoltro,.... un premio per la genialit?
36938 hanno reso mitico un salva schermo scaricalo, "poesie catartiche", che non sai cosa ti perdi
36941 -------------- next part --------------
36942 An HTML attachment was scrubbed...
36943 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20031024/97501fa5/attachment-0002.htm
36944 From diego at redesul.net Fri Oct 24 16:03:05 2003
36945 From: diego at redesul.net (Diego B. Contezini)
36946 Date: Sat Oct 23 23:10:06 2004
36947 Subject: [IRCServices Coding] CORE DUMPED! BUG!
36948 References: <3f8f9304.20227@achurch.org> <000e01c395ac$5b773b40$3cc8a8c0@angel>
36949 Message-ID: <012e01c39a8b$531829d0$3cc8a8c0@angel>
36951 Andrew, have anything more of dumping/debugging that i can do/give for helps
36953 (if it helps, here its rh9.0, libc 2.3.2, linux x86, kernel 2.4.20-8,
36954 Pentium III 1ghz 512mb ram DDR)....
36964 From andrew at wtfigo.co.uk Tue Nov 4 02:15:03 2003
36965 From: andrew at wtfigo.co.uk (Andrew Kempe)
36966 Date: Sat Oct 23 23:10:06 2004
36967 Subject: [IRCServices Coding] test
36968 Message-ID: <E1AGyDD-0001mX-00@smtp.mailbox.co.uk>
36972 From diego at redesul.net Tue Nov 4 16:43:45 2003
36973 From: diego at redesul.net (Diego B. Contezini)
36974 Date: Sat Oct 23 23:10:06 2004
36975 Subject: [IRCServices Coding] CORE DUMPED! BUG!
36976 Message-ID: <014f01c3a335$e1e08dd0$3cc8a8c0@angel>
36978 I found a bug (occuring on the old-last vesion of ircservices -
36979 ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
36981 yes, 5.0.23 is the last.. but nothing has changed about the bug...
36983 here is the debugging:
36985 ChanServ@services.redesul.net :op #manaus paulinhu-dissi-q-mi-ama
36986 [Oct 18 16:05:31.152195 2003] debug: Sent: :ChanServ NOTICE
36987 paulinhu-dissi-q-mi-ama :Permission denied.
36988 [Oct 18 16:05:31.152274 2003] debug: Received: :pRiCkLy SJOIN 1066501295
36990 [Oct 18 16:05:31.152353 2003] protocol/bahamut: debug: pRiCkLy SJOINs #Euevc
36991 [Oct 18 16:05:31.152490 2003] debug: Sent: :ChanServ MODE #EUeVC +o pRiCkLy
36992 [Oct 18 16:05:31.269153 2003] debug: Received: :Hellskitty PRIVMSG
36993 ChanServ@services.redesul.net :unban #EMOCORE
36994 [Oct 18 16:05:31.269425 2003] debug: Sent: :ChanServ NOTICE Hellskitty
36995 :Permission denied.
36996 [Oct 18 16:05:31.288596 2003] debug: Received: :|-Frango-| MODE #EMOCORE
36998 [Oct 18 16:05:31.288768 2003] debug: Received: :|-Frango-| TOPIC #EMOCORE
36999 |-Frango-| 1066460927 :TakeOver by 14,1 -15=0[ 14He15l0lR15ai14ser 0]15=14-
37000 S15c0ri15p14t 15v3.8
37001 [Oct 18 16:05:31.288944 2003] debug: Sent: :ChanServ TOPIC #EMOCORE reffer
37002 1066055037 :1i?? Festival HARDcoCOREcore dia 25 de outubro em blumenau no
37003 rio bravo bar (proximo a resima agua verde), com as bandas: Zero Ltda
37004 (curitiba), Swallow the Waffle (bc), chymia(bnu), crazy frogs (lages),
37005 surpise set e slipper (bnu)...3 pila entrada inicio as 15:00 horas'
37006 [Oct 18 16:05:31.289032 2003] debug: Received: :|-Frango-| MODE
37007 #EMOCORE -oooooo CHoPP CbRS-oFF caroll BRYAN brunaH balsanelli
37008 Segmentation fault (core dumped)
37011 Debugging my core... i can found:
37012 #0 0x0804d830 in add_mode_with_params (md=0x806aa00, mode=111 'o',
37013 is_add=1, params=1, parambuf=0xbfffe280 "balsanelli",
37014 len=10) at actions.c:568
37015 568 md->params[md->nopmodes][len] = 0;
37017 #0 0x0804d830 in add_mode_with_params (md=0x806aa00, mode=111 'o',
37018 is_add=1, params=1, parambuf=0xbfffe280 "balsanelli",
37019 len=10) at actions.c:568
37021 #1 0x0804d342 in set_cmode (sender=0x81db058 "ChanServ", channel=0xa905d00)
37024 "balsanelli\000\b\025\225\002BWi??\022B\024\032\023Bi??i??i??i??\000\000\000
37025 \000\034 \006\bi??i??i??i??hi??i??i??i??i??i??i??\025\224\004B\034
37026 \006\b\000\000\000\000i??m\tBdi??\022Bi??q\a\b\000\000\000\000eR :\0037[
37027 \0034#\003di??\022B\000\000\000\000i??\037\006\bi??\037\006\bi??i??i??i??$i?
37028 ?\006Bi??i??i??i??\bi??i??i??\000\000\000\000Hi??i??i??\025\224\004B@\002\a\
37029 b8i??i??i??6\020\aBpi??i??i??@i??\006\b@\002\a\b\000\000\000\000i??<\023BLi?
37030 ?i??i??=S\004B\024\032\023B\001\020\000\000@i??\006\bhi??i??i??\204i??\006Bp
37031 i??i??i??i??\037\006\b"...
37036 args = 0xbfffe6d0 "RDcoCOREcorei??i??i??i??o"
37037 modes = 0xbfffeae2 ""
37038 modes_orig = 0xbfffeae0 "+o"
37039 md = (struct modedata *) 0x806aa00
37044 #2 0x400895ff in local_set_cumodes (c=0xa905d00, plusminus=43 '+', modes=1,
37045 nick=0xab7f2e8 "balsanelli") at check.c:432
37047 modestr = "o\000\000 de outubro em blumenau no rio bravo bar
37048 (proximo a resima agua verde), com as bandas: Zero
37049 L\v\000\000\000(curitiba), \000\000\000\000low the Waff\000\000\000\000bc),
37050 chymia(bnu), crazy frogs (lages), surpise set e slipper (bnu).."...
37052 #3 0x40088d74 in check_chan_user_modes (source=0xbfffeed0 "|-Frango-|",
37053 u=0xab34ff0, c=0xa905d00, oldmodes=1)
37055 user = (User *) 0xab7f2d8
37056 ci = (ChannelInfo *) 0xa571940
37060 #4 0x400820ed in do_channel_umode_change (source=0xbfffeed0 "|-Frango-|",
37061 c=0xa905d00, u=0xab34ff0, oldmodes=1)
37064 #5 0x0805890d in call_callback_5 (module=0x806a5c0, id=23, arg1=0xbfffeed0,
37065 arg2=0xa905d00, arg3=0xab34ff0, arg4=0x1,
37066 arg5=0x0) at modules.c:666
37067 cl = (CallbackList *) 0x8077cb8
37070 #6 0x0804edc8 in do_cumode (source=0xbfffeed0 "|-Frango-|", chan=0xa905d00,
37071 flag=1, add=0, nick=0xbfffecc9 "balsanelli")
37072 ---Type <return> to continue, or q <return> to quit---
37074 u = (struct c_userlist *) 0xab34ff0
37075 user = (User *) 0xab7f2d8
37077 #7 0x0804e97e in do_cmode (source=0xbfffeed0 "|-Frango-|", ac=0,
37078 av=0xa853130) at channels.c:302
37081 params = -1073746288
37082 chan = (Channel *) 0xa905d00
37085 modestr = 0xbfffec9e "-oooooo"
37086 #8 0x080557ff in m_mode (source=0xbfffeed0 "|-Frango-|", ac=8,
37087 av=0xa853110) at messages.c:101
37089 #9 0x0805920e in process () at process.c:133
37090 m = (Message *) 0x8067dd8
37092 "|-Frango-|\000\000G\000\000\000Y\e\205\n\t+\205\n\bi??i??i??i??i??\005\b@j\
37093 a\b\000\004\000\000i??\032\205\n\t\000\000\000@j\a\b\216j\a\b(i??i??i??qP\00
37096 "MODE\000\000\000i??8i??i??i??i??\005\b\000\000\000\000i??i??i??i??\000\000\
37097 000\000\000\000\000\000\001H\000\000Pi??i??i??\000Y\a\bVi??\005\b\207j\a\bP\
37098 e\205\n\t\000\000\000i??i??\005\b"
37100 "MODE\000#EMOCORE\000-oooooo\000CHoPP\000CbRS-oFF\000caroll\000BRYAN\000brun
37101 aH\000balsanelli\000 balsanelli\000\000ai\00314ser \0030]\00315=\00314-
37102 S\00315c\0030ri\00315p\00314t \00315\037v\0373.8 \003\000\00315\037v\0373.8
37103 \003\000\000\0003)\000\0006\037\002Pi??Ti??\00313\037\002]\037\002\0036i??i?
37104 ? \000i??Ti??\00313\037\002]\037\002\0036i??i?? \000\000\003\000\000r
37105 \003", '\0' <repeats 11 times>...
37106 s = 0xbfffec95 "#EMOCORE"
37108 av = (char **) 0xa853110
37109 #10 0x0805507d in readline_callback (s=0xa851ae0, param_unused=0x50) at
37112 #11 0x0805b617 in check_sockets () at sockets.c:491
37113 newline = 0xa851b58 "\nrct-sc.br irc.creativenet.com.br 0 3364349034
37114 :aNiNhHa[du]DoNaTeLo\n:Toh_Pensanu PART #ilheus\n:_LoKo_SuL_ SJOIN
37115 1063565447 #elias\n:_MoRgAnA_ PRIVMSG NickServ@services.redesul.net :set
37116 nomemo off\n:irc."...
37119 rfds = {fds_bits = {16, 0 <repeats 31 times>}}
37120 wfds = {fds_bits = {0 <repeats 32 times>}}
37121 tv = {tv_sec = 2, tv_usec = 980000}
37124 s = (Socket *) 0xa851ae0
37125 s2 = (Socket *) 0x0
37126 #12 0x0805538a in main (ac=3, av=0xbffff164, envp=0xbffff174) at main.c:266
37127 ---Type <return> to continue, or q <return> to quit---
37129 now_msec = 1348441861
37130 last_update = 1066500208
37131 last_check = 1348441182
37132 #13 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
37133 No symbol table info available.
37134 (gdb) info registers
37135 eax 0xd6b2bf8a -692928630
37136 ecx 0x806aa00 134654464
37137 edx 0x656e6173 1701732723
37138 ebx 0x42131a14 1108548116
37139 esp 0xbfffd910 0xbfffd910
37140 ebp 0xbfffe238 0xbfffe238
37141 esi 0x8075900 134699264
37142 edi 0xbffff050 -1073745840
37143 eip 0x804d830 0x804d830
37144 eflags 0x10282 66178
37154 root@irc(/home/ircadmin/services/lib)# ls -la core.12631
37155 -rw------- 1 ircadmin ircadmin 47374336 Oct 18 16:05 core.12631
37156 root@irc(/home/ircadmin/services)# ldd ircservices
37157 libdl.so.2 => /lib/libdl.so.2 (0x4001e000)
37158 libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
37159 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
37160 root@irc(/home/ircadmin/services)# uname -a
37161 Linux XXXXXX.xyz.0xdeadbeef 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686
37162 i686 i386 GNU/Linux
37163 root@irc(/home/ircadmin/services)# cat /etc/redhat-release
37164 Red Hat Linux release 9 (Shrike)
37165 root@irc(/home/ircadmin/services)# cat /proc/cpuinfo
37167 model name : Pentium III (Coppermine)
37170 cache size : 256 KB
37172 root@irc(/home/ircadmin/services)# free
37173 total used free shared buffers cached
37174 Mem: 513792 482248 31544 0 69492 274980
37176 I changed version of linux, runned it on 3 different machines, on
37177 slackware/redhat, pentiumIII, K5, P200.
37178 This bug is as older as i run services... dont know if its the same of the
37179 4.X (that i changed to 5.X to "solve" this bug), but from 5.12 to now, it
37180 continue happening... aways...
37181 Dont have a exactly time to happen, its insane... i think that its a
37182 coincidence of some commands that on the memory ends fucking some variable.
37183 if you want look the incidence, here its:
37184 root@irc(/home/ircadmin/services/lib)# ls -la core*
37186 -rw------- 1 ircadmin ircadmin 49025024 Oct 5 19:32 core.27214
37187 -rw------- 1 ircadmin ircadmin 45932544 Oct 5 21:01 core.14414
37188 -rw------- 1 ircadmin ircadmin 46948352 Oct 6 14:00 core.18016
37189 -rw------- 1 ircadmin ircadmin 45936640 Oct 11 04:30 core.1347
37190 -rw------- 1 ircadmin ircadmin 50479104 Oct 14 01:29 core.16481
37191 -rw------- 1 ircadmin ircadmin 44982272 Oct 15 13:54 core.22332
37192 -rw------- 1 ircadmin ircadmin 47374336 Oct 18 16:05 core.12631
37193 -rw------- 1 ircadmin ircadmin 48099328 Oct 19 14:16 core.5362
37194 -rw------- 1 ircadmin ircadmin 44863488 Oct 19 14:22 core.32708
37195 -rw------- 1 ircadmin ircadmin 45355008 Nov 1 15:13 core.28309
37196 -rw------- 1 ircadmin ircadmin 50360320 Nov 3 18:24 core.5160
37199 If it helps, here is the debugging of the last two cores, on gdb:
37202 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
37207 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
37210 chan = (Channel *) 0xa87d1e0
37211 s = 0x1f73746f <Address 0x1f73746f out of bounds>
37213 modestr = 0x1f73746f <Address 0x1f73746f out of bounds>
37214 #1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:680
37215 buf = "-imsl\000HA___\000\000\000\000\000W
37216 \022B\000\000\000L\000\000\000\000\000y\000nossaTZ\000\000\000\000\000\000yy
37217 yyA<\023B\001\000\000\000\bYy?Om\tBd
37218 \022BDq\a\bOUy?NO\006B\210o\a\b3\035\rB\024\032\023BAa\006B\003\000\000\000a
37219 Yy?\027\000\000\000\024\032\023B\024\032\023BTZ\000\000\004\000\000\000\005\
37220 000\000\000\210o\a\baYy?\030Yy?NO\006B\210o\a\baYy?\027\000\000\000$u\006B\2
37221 10o\a\bIo\a\b\vO\006B\024\032\023B\024\032\023B@\002\a\bHYy?$u\006B\200Yy?@o
37223 s = 0xbfffdc60 "-imsl"
37224 argv = {0xa87d1e8 "#soad",
37225 0x1f73746f <Address 0x1f73746f out of bounds>,
37226 0x5303200f <Address 0x5303200f out of bounds>,
37227 0x6c6c6568 <Address 0x6c6c6568 out of bounds>,
37228 0x4323203a <Address 0x4323203a out of bounds>,
37229 0x65746e65 <Address 0x65746e65 out of bounds>,
37230 0x65685372 <Address 0x65685372 out of bounds>,
37231 0x52426c6c <Address 0x52426c6c out of bounds>}
37233 ---Type <return> to continue, or q <return> to quit---
37236 #2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
37240 md = (struct modedata *) 0x0
37245 #3 0x080553a3 in main (ac=1, av=0xbfffe574, envp=0xbfffe57c) at main.c:269
37247 now_msec = -1555790286
37248 last_update = 1067890538
37249 last_check = 2739174210
37250 #4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
37251 No symbol table info available.
37255 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
37260 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
37263 chan = (Channel *) 0xa9be840
37264 s = 0xbf000000 <Address 0xbf000000 out of bounds>
37266 modestr = 0xbf000000 <Address 0xbf000000 out of bounds>
37267 #1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:680
37268 buf = "-imsl\000\a\b\000len\000\000\000\000W
37269 \022B3\035\rB\024\032\023BAa\006B\003\000\000\000
37270 oy?\027\000\000\000yyyyA<\023BTZ\000\000\004\000\000\000\005\000\000\000\210
37271 o\a\b oy?Xoy?NO\006B\210o\a\b
37272 oy?\027\000\000\000$u\006B\210o\a\bIo\a\b\vO\006B\024\032\023B\024\032\023B@
37273 \002\a\b\210oy?$u\006BAoy?@o\006\b@\002\a\b\000\000\000\000\024\032\023B@\00
37274 2\a\b?oy?6\020\aBaoy?@o\006\b@\002\a\b\000\000\000\000Aoy?I\037\006\b=S\004B
37275 \024\032\023B\001\020\000\000@o\006\b"...
37276 s = 0xbffff2e0 "-imsl"
37277 argv = {0xa9be848 "#zoera",
37278 0xbf000000 <Address 0xbf000000 out of bounds>, 0x0,
37279 0x806f240 "ircservices.log", 0x806f240 "ircservices.log",
37280 0x5a54 <Address 0x5a54 out of bounds>, 0x0,
37281 0xffffffff <Address 0xffffffff out of bounds>}
37285 #2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
37286 ---Type <return> to continue, or q <return> to quit---
37290 md = (struct modedata *) 0x0
37295 #3 0x080553a3 in main (ac=1, av=0xbffffbf4, envp=0xbffffbfc) at main.c:269
37297 now_msec = -1740061222
37298 last_update = 1067706282
37299 last_check = 2554904000
37300 #4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
37301 No symbol table info available.
37304 Im running it more a time on Screen to can get exactly where occur the bug
37305 (with -nofork -debug), to look for more examples of commands that causes
37307 if have something (more) that i can to add/do to helps on debugging, please,
37308 tell me.. i have the core (i cant send it, for secure reasons... have all my
37309 db on the core... ), but im open to helps anytime anywhere... with
37312 Thanks for all development, this is really a bealtifull software...
37313 (and sorry for my bad english)
37315 Diego B. Contezini aka destruct_ #irc.redesul.net
37319 From diego at redesul.net Tue Nov 4 16:46:53 2003
37320 From: diego at redesul.net (Diego B. Contezini)
37321 Date: Sat Oct 23 23:10:06 2004
37322 Subject: [IRCServices Coding] about.. CORE DUMPED! BUG!
37323 Message-ID: <01fa01c3a336$4e884220$3cc8a8c0@angel>
37325 If it helps, im using Bahamut here....
37328 From achurch at achurch.org Wed Nov 5 13:20:15 2003
37329 From: achurch at achurch.org (Andrew Church)
37330 Date: Sat Oct 23 23:10:06 2004
37331 Subject: [IRCServices Coding] Bug or misunderstood ?
37332 In-Reply-To: <000901c39496$71764f10$a37faec3@coder>
37333 Message-ID: <3fa87c99.57222@achurch.org>
37335 >Im using unreal ircd. When channel is empty and if channel owner joins
37336 >his/her registered channel it does
37337 >(ChanServ sets mode: +ntrq nick) but when channel is not empty and if
37338 >channel owner joins his/her registered channel it does (ChanServ sets mode:
37339 >+oq nick nick). As you see on the first one there is no +o and because of
37340 >this chanserv does not update the last_used time because chanserv is set to
37341 >update last_used time with +o (CUMODE_o) so channels drop while channel
37342 >owners use them. Is this a bug or my misunderstood ?
37344 This is a bug; I've fixed it for the next release, thanks for the
37345 report. As regards your other message, not setting the last-used time for
37346 +a/+q users is designed behavior (see section 3-2-1 of the manual: "`used'
37347 means that a user with auto-op privileges ... has entered the channel"), as
37348 well as unnecessary in typical channel settings (where +a users are a
37349 subset of +o users), but if you have any better suggestions on how to
37350 determine when a channel is being used by proper users as opposed to (for
37351 example) spammers or people just entering to see if the channel is
37352 available, I'm willing to listen.
37355 achurch@achurch.org
37356 http://achurch.org/
37358 From rg at tcslon.com Fri Nov 7 02:03:27 2003
37359 From: rg at tcslon.com (Russell Garrett)
37360 Date: Sat Oct 23 23:10:06 2004
37361 Subject: [IRCServices Coding] Badly punctuated parameter list in `#define'
37362 Message-ID: <MKEGJINFADFODDNOKEJCMELPEGAA.rg@tcslon.com>
37364 I'm getting this too - it's just started happening in 5.0.23:
37366 gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -fno-builtin-log
37367 -I.. -DCONVERT_DB -c convert-cygnus.c -o convert-cygnus.o
37368 convert-cygnus.c:35: badly punctuated parameter list in `#define'
37369 convert-cygnus.c:48: badly punctuated parameter list in `#define'
37371 gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
37376 From andrewk at isdial.net Tue Aug 26 02:43:45 2003
37377 From: andrewk at isdial.net (Andrew Kempe)
37378 Date: Sat Oct 23 23:10:06 2004
37379 Subject: [IRCServices Coding] test
37380 Message-ID: <005801c36bb6$85bbc080$1f0912ac@espotting.com>
37384 From us44ever at hotmail.com Thu Aug 28 09:45:48 2003
37385 From: us44ever at hotmail.com (us44ever .)
37386 Date: Sat Oct 23 23:10:06 2004
37387 Subject: [IRCServices Coding] Yet, another great suggestion
37388 Message-ID: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
37392 it would be really great to add another new line to the "/nickserv info"
37393 command, for example, when some one types: "/nickserv info nick", the
37394 following will be shown:
37396 ***************************
37398 -NickServ- nick is hello world
37400 -NickServ- Is online from: ~test@just.a.test.co.za
37402 -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
37404 -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
37406 -NickServ- Last quit message: anythinggggg
37408 -NickServ- Options: Kill protection, Security
37410 ***************************
37412 the new line I'm suggesting is something like:
37414 ***************************
37415 -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
37416 ***************************
37418 This will help our users to compare the time that user was last seen and the
37419 time right now *it's very important, many many of our users asked us for
37420 this option*, also it would even be more great to show how long last time
37421 the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003 GMT
37422 (last seen time was before: 10 days, 3hours and 24 sec ago).
37424 Note that I saw both of these features, in other services I don't remember
37425 there names (but they aren't as stable as ircservices5) (it was something
37426 like ptlink services, and magik II)
37428 That's all, I would really like to see it on the next version (or if you can
37429 show me how to do it, as I'm not a programmer)
37431 Many thanks to all of who developed IRCservices ...etc ...etc ...etc
37436 _________________________________________________________________
37437 Get MSN 8 and enjoy automatic e-mail virus protection.
37438 http://join.msn.com/?page=features/virus
37441 From aragon at phat.za.net Thu Aug 28 11:36:22 2003
37442 From: aragon at phat.za.net (Aragon Gouveia)
37443 Date: Sat Oct 23 23:10:06 2004
37444 Subject: [IRCServices Coding] Yet, another great suggestion
37445 In-Reply-To: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
37446 References: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
37447 Message-ID: <20030828183615.GB32204@phat.za.net>
37449 Or how about rather letting users decide what timezone they're in and
37450 services outputs all timestamps in their local time?
37453 | By us44ever . <us44ever@hotmail.com>
37454 | [ 2003-08-28 18:45 +0200 ]
37457 > it would be really great to add another new line to the "/nickserv info"
37458 > command, for example, when some one types: "/nickserv info nick", the
37459 > following will be shown:
37461 > ***************************
37463 > -NickServ- nick is hello world
37465 > -NickServ- Is online from: ~test@just.a.test.co.za
37467 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
37469 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
37471 > -NickServ- Last quit message: anythinggggg
37473 > -NickServ- Options: Kill protection, Security
37475 > ***************************
37477 > the new line I'm suggesting is something like:
37479 > ***************************
37480 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
37481 > ***************************
37483 > This will help our users to compare the time that user was last seen and
37484 > the time right now *it's very important, many many of our users asked us
37485 > for this option*, also it would even be more great to show how long last
37486 > time the user was seen (some thing like: Last seen time: Aug 28 15:51:14
37487 > 2003 GMT (last seen time was before: 10 days, 3hours and 24 sec ago).
37489 > Note that I saw both of these features, in other services I don't remember
37490 > there names (but they aren't as stable as ircservices5) (it was something
37491 > like ptlink services, and magik II)
37493 > That's all, I would really like to see it on the next version (or if you
37494 > can show me how to do it, as I'm not a programmer)
37496 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
37501 > _________________________________________________________________
37502 > Get MSN 8 and enjoy automatic e-mail virus protection.
37503 > http://join.msn.com/?page=features/virus
37505 > ------------------------------------------------------------------
37506 > To unsubscribe or change your subscription options, visit:
37507 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
37509 From saturn at jetirc.net Thu Aug 28 11:39:41 2003
37510 From: saturn at jetirc.net (Saturn)
37511 Date: Sat Oct 23 23:10:06 2004
37512 Subject: [IRCServices Coding] Yet, another great suggestion
37513 References: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
37514 <20030828183615.GB32204@phat.za.net>
37515 Message-ID: <003201c36d93$abf77fd0$6401a8c0@turby>
37517 Oooo now I like that option... have it default to a default timezone, set in
37518 the conf file, and give them the option of SETting a different UTC code
37519 (have it as GMT + or - x wheer x is the offset from UTC)... It may not
37520 sound liek much, but I bet people will use it, and what's more, it IS useful
37521 information, especially on international servers like mine.. we have people
37522 from all over the place, and we keep services set on Pacific time... but for
37523 those in, say, Belgium... that's not very helpful
37525 ----- Original Message -----
37526 From: "Aragon Gouveia" <aragon@phat.za.net>
37527 To: <ircservices-coding@ircservices.za.net>
37528 Sent: Thursday, August 28, 2003 11:36 AM
37529 Subject: Re: [IRCServices Coding] Yet, another great suggestion
37532 Or how about rather letting users decide what timezone they're in and
37533 services outputs all timestamps in their local time?
37536 | By us44ever . <us44ever@hotmail.com>
37537 | [ 2003-08-28 18:45 +0200 ]
37540 > it would be really great to add another new line to the "/nickserv info"
37541 > command, for example, when some one types: "/nickserv info nick", the
37542 > following will be shown:
37544 > ***************************
37546 > -NickServ- nick is hello world
37548 > -NickServ- Is online from: ~test@just.a.test.co.za
37550 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
37552 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
37554 > -NickServ- Last quit message: anythinggggg
37556 > -NickServ- Options: Kill protection, Security
37558 > ***************************
37560 > the new line I'm suggesting is something like:
37562 > ***************************
37563 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
37564 > ***************************
37566 > This will help our users to compare the time that user was last seen and
37567 > the time right now *it's very important, many many of our users asked us
37568 > for this option*, also it would even be more great to show how long last
37569 > time the user was seen (some thing like: Last seen time: Aug 28 15:51:14
37570 > 2003 GMT (last seen time was before: 10 days, 3hours and 24 sec ago).
37572 > Note that I saw both of these features, in other services I don't remember
37573 > there names (but they aren't as stable as ircservices5) (it was something
37574 > like ptlink services, and magik II)
37576 > That's all, I would really like to see it on the next version (or if you
37577 > can show me how to do it, as I'm not a programmer)
37579 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
37584 > _________________________________________________________________
37585 > Get MSN 8 and enjoy automatic e-mail virus protection.
37586 > http://join.msn.com/?page=features/virus
37588 > ------------------------------------------------------------------
37589 > To unsubscribe or change your subscription options, visit:
37590 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
37591 ------------------------------------------------------------------
37592 To unsubscribe or change your subscription options, visit:
37593 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
37597 From Craig at chatspike.net Thu Aug 28 14:29:54 2003
37598 From: Craig at chatspike.net (Craig McLure)
37599 Date: Sat Oct 23 23:10:06 2004
37600 Subject: [IRCServices Coding] Yet, another great suggestion
37601 Message-ID: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
37603 Please dont post to both the services main list, and the services coding list. Choose one, or the other, especially concidering i dont think this is a great suggestion either..
37605 /time services.chatspike.net
37606 [22:28]
\95\95\95 Date / time at services.chatspike.net- Thu Aug 28 17:28:57 2003 EDT
37610 /****************************************
37611 * Craig "FrostyCoolSlug" McLure
37612 ************* - SpamBox - **************
37613 * InspIRCd - http://www.inspircd.org
37614 * ChatSpike - http://www.chatspike.net
37615 * WinBot - http://www.winbot.co.uk
37616 ****************************************/
37618 /****************************************
37619 * From - us44ever . <us44ever@hotmail.com>
37620 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
37621 * Sent - 2003-08-28 @ 16:45:00
37622 * Subject - [IRCServices Coding] Yet, another great suggestion
37623 ****************************************/
37625 /****** - Begin Original Message - ******/
37629 >it would be really great to add another new line to the "/nickserv info"
37630 >command, for example, when some one types: "/nickserv info nick", the
37631 >following will be shown:
37633 >***************************
37635 >-NickServ- nick is hello world
37637 >-NickServ- Is online from: ~test@just.a.test.co.za
37639 >-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
37641 >-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
37643 >-NickServ- Last quit message: anythinggggg
37645 >-NickServ- Options: Kill protection, Security
37647 >***************************
37649 >the new line I'm suggesting is something like:
37651 >***************************
37652 >-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
37653 >***************************
37655 >This will help our users to compare the time that user was last seen and the
37656 >time right now *it's very important, many many of our users asked us for
37657 >this option*, also it would even be more great to show how long last time
37658 >the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003 GMT
37659 >(last seen time was before: 10 days, 3hours and 24 sec ago).
37661 >Note that I saw both of these features, in other services I don't remember
37662 >there names (but they aren't as stable as ircservices5) (it was something
37663 >like ptlink services, and magik II)
37665 >That's all, I would really like to see it on the next version (or if you can
37666 >show me how to do it, as I'm not a programmer)
37668 >Many thanks to all of who developed IRCservices ...etc ...etc ...etc
37673 >_________________________________________________________________
37674 >Get MSN 8 and enjoy automatic e-mail virus protection.
37675 >http://join.msn.com/?page=features/virus
37677 >------------------------------------------------------------------
37678 >To unsubscribe or change your subscription options, visit:
37679 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
37681 /******* - End Original Message - *******/
37686 From nothing at psychopat.org Thu Aug 28 14:57:31 2003
37687 From: nothing at psychopat.org (Marc-Andre A. Fuentes)
37688 Date: Sat Oct 23 23:10:06 2004
37689 Subject: [IRCServices Coding] BUG Report
37690 Message-ID: <001501c36daf$c8cba700$0101a8c0@house>
37692 We're having a small problem with suspended channel.
37694 we suspended channel #kavala, and someone has identified itself has the founder and apply a DROP to the channel.
37695 then we got a panic from the services and... crash.
37697 Also with suspended nick , when the suspencion expire, the services crash
37700 ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
37705 -------------- next part --------------
37706 An HTML attachment was scrubbed...
37707 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030828/1f31ccf5/attachment-0003.html
37708 From Craig at chatspike.net Thu Aug 28 15:24:36 2003
37709 From: Craig at chatspike.net (Craig McLure)
37710 Date: Sat Oct 23 23:10:06 2004
37711 Subject: [IRCServices Coding] BUG Report
37712 Message-ID: <20030828222401.JVQE12036.mta4-svc.business.ntl.com@i-br0ked-it>
37714 hmm.. what OS, compiler version etc are you using?
37716 after a test, i got the following:
37718 /cs id #abc 00376370
37719 -ChanServ- Channel #abc is suspended and may not be used or identified for.
37722 [23:20] -ChanServ- Channel is suspended and may not be used or identified for.
37724 only prob i got was it missed the channel name in the second message :)
37727 /****************************************
37728 * Craig "FrostyCoolSlug" McLure
37729 ************* - SpamBox - **************
37730 * InspIRCd - http://www.inspircd.org
37731 * ChatSpike - http://www.chatspike.net
37732 * WinBot - http://www.winbot.co.uk
37733 ****************************************/
37735 /****************************************
37736 * From - Marc-Andre A. Fuentes <nothing@psychopat.org>
37737 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
37738 * Sent - 2003-08-28 @ 18:00:00
37739 * Subject - [IRCServices Coding] BUG Report
37740 ****************************************/
37742 /****** - Begin Original Message - ******/
37744 >We're having a small problem with suspended channel.
37746 >we suspended channel #kavala, and someone has identified itself has the founder and apply a DROP to the channel.
37747 >then we got a panic from the services and... crash.
37749 >Also with suspended nick , when the suspencion expire, the services crash
37752 >ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
37757 >------------------------------------------------------------------
37758 >To unsubscribe or change your subscription options, visit:
37759 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
37761 /******* - End Original Message - *******/
37766 From saturn at jetirc.net Thu Aug 28 17:13:48 2003
37767 From: saturn at jetirc.net (Saturn)
37768 Date: Sat Oct 23 23:10:06 2004
37769 Subject: [IRCServices Coding] AKill suggestion
37770 References: <2C31F186-CDEE-11D7-979C-0003938D6866@mac.com>
37771 Message-ID: <009001c36dc2$64b56b80$6401a8c0@turby>
37773 Would it be possible to have it announce to the user when they are akilled,
37774 either the expiry date and time, or "Expires in 3days, 4hours, 6minutes" or
37775 something similar. I find that usually we just have to do 24hour bans, but
37776 the user has no way to know when the ban was set, and when it expires...
37778 Just an idea... I now await the half dozen people who will proceed to tell
37779 me how stupid my idea is....
37786 From playa at dreamchat.org Thu Aug 28 20:46:19 2003
37787 From: playa at dreamchat.org (playa)
37788 Date: Sat Oct 23 23:10:07 2004
37789 Subject: [IRCServices Coding] Yet, another great suggestion
37790 In-Reply-To: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
37791 References: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
37792 Message-ID: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
37794 Is this /time command only supposed to work via RAW? Cause when i type
37795 /time services.dreamchat.org i get No Such User, but if i do /raw time
37796 services.dreamchat.org, it works. Just wondering if its just me, or if
37797 its supposed to be that way.
37799 > Please dont post to both the services main list, and the services coding
37800 > list. Choose one, or the other, especially concidering i dont think this
37801 > is a great suggestion either..
37803 > /time services.chatspike.net
37804 > [22:28] ??? Date / time at services.chatspike.net- Thu Aug 28 17:28:57
37809 > /****************************************
37810 > * Craig "FrostyCoolSlug" McLure
37811 > ************* - SpamBox - **************
37812 > * InspIRCd - http://www.inspircd.org
37813 > * ChatSpike - http://www.chatspike.net
37814 > * WinBot - http://www.winbot.co.uk
37815 > ****************************************/
37817 > /****************************************
37818 > * From - us44ever . <us44ever@hotmail.com>
37819 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
37820 > * Sent - 2003-08-28 @ 16:45:00
37821 > * Subject - [IRCServices Coding] Yet, another great suggestion
37822 > ****************************************/
37824 > /****** - Begin Original Message - ******/
37828 >>it would be really great to add another new line to the "/nickserv info"
37829 >>command, for example, when some one types: "/nickserv info nick", the
37830 >>following will be shown:
37832 >>***************************
37834 >>-NickServ- nick is hello world
37836 >>-NickServ- Is online from: ~test@just.a.test.co.za
37838 >>-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
37840 >>-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
37842 >>-NickServ- Last quit message: anythinggggg
37844 >>-NickServ- Options: Kill protection, Security
37846 >>***************************
37848 >>the new line I'm suggesting is something like:
37850 >>***************************
37851 >>-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
37852 >>***************************
37854 >>This will help our users to compare the time that user was last seen and
37856 >>time right now *it's very important, many many of our users asked us for
37857 >>this option*, also it would even be more great to show how long last time
37858 >>the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003
37860 >>(last seen time was before: 10 days, 3hours and 24 sec ago).
37862 >>Note that I saw both of these features, in other services I don't
37864 >>there names (but they aren't as stable as ircservices5) (it was something
37865 >>like ptlink services, and magik II)
37867 >>That's all, I would really like to see it on the next version (or if you
37869 >>show me how to do it, as I'm not a programmer)
37871 >>Many thanks to all of who developed IRCservices ...etc ...etc ...etc
37876 >>_________________________________________________________________
37877 >>Get MSN 8 and enjoy automatic e-mail virus protection.
37878 >>http://join.msn.com/?page=features/virus
37880 >>------------------------------------------------------------------
37881 >>To unsubscribe or change your subscription options, visit:
37882 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
37884 > /******* - End Original Message - *******/
37888 > ------------------------------------------------------------------
37889 > To unsubscribe or change your subscription options, visit:
37890 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
37897 Network Founder/CEO
37898 DreamChat IRC Network - irc.dreamchat.org
37899 http://www.dreamchat.org
37902 From quension at mac.com Thu Aug 28 21:13:48 2003
37903 From: quension at mac.com (Trevor Talbot)
37904 Date: Sat Oct 23 23:10:07 2004
37905 Subject: [IRCServices Coding] Yet, another great suggestion
37906 In-Reply-To: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
37907 Message-ID: <0F823090-D9D7-11D7-8513-0003938D6866@mac.com>
37909 On Thursday, Aug 28, 2003, at 20:46 US/Pacific, playa wrote:
37911 > Is this /time command only supposed to work via RAW? Cause when i
37912 > type /time services.dreamchat.org i get No Such User, but if i do /raw
37913 > time services.dreamchat.org, it works. Just wondering if its just me,
37914 > or if its supposed to be that way.
37916 That's a client thing. Some clients might alias /time as a CTCP TIME
37917 for a specific user, or similar.
37922 From r-krisztian at softhome.net Thu Aug 28 22:12:51 2003
37923 From: r-krisztian at softhome.net (Krisztian Romek)
37924 Date: Sat Oct 23 23:10:07 2004
37925 Subject: [IRCServices Coding] Yet, another great suggestion
37926 In-Reply-To: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
37927 References: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
37928 <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
37929 Message-ID: <200308290713.29423.r-krisztian@softhome.net>
37931 > Is this /time command only supposed to work via RAW? Cause when i type
37932 > /time services.dreamchat.org i get No Such User, but if i do /raw time
37933 > services.dreamchat.org, it works. Just wondering if its just me, or if
37934 > its supposed to be that way.
37936 Some clients use stupid aliases for CTCP commands, for example:
37938 /version <nick> = /CTCP <nick> VERSION,
37939 /time <nick> = /CTCP <nick> TIME,
37940 /finger <nick> = /CTCP <nick> TIME
37942 This is why nothing works the way you expected.
37946 r-krisztian@softhome.net
37949 From us44ever at hotmail.com Fri Aug 29 13:02:19 2003
37950 From: us44ever at hotmail.com (us44ever .)
37951 Date: Sat Oct 23 23:10:07 2004
37952 Subject: [IRCServices Coding] AKill suggestion
37953 Message-ID: <Sea1-F108cM3oryKFRJ0000eb75@hotmail.com>
37955 Pretty good idea, specially is it would be implemented as an option (because
37956 some admins might won't like the idea of displaying the time of when the
37957 akill will expire to the user who has been akilled).
37959 _________________________________________________________________
37960 Help protect your PC: Get a free online virus scan at McAfee.com.
37961 http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
37964 From us44ever at hotmail.com Fri Aug 29 13:09:51 2003
37965 From: us44ever at hotmail.com (us44ever .)
37966 Date: Sat Oct 23 23:10:07 2004
37967 Subject: [IRCServices Coding] Yet, another great suggestion
37968 Message-ID: <Sea1-F127z33hqSnMGE000094b3@hotmail.com>
37971 Since most people want to see this feature(s) in the next version, it would
37972 be great to implement it as an optional feature , where it can be disabled
37973 from the .conf file(s) or enable it easily. I don't think that there is
37974 anything that the authors will lose if this feature can be added, in fact,
37975 it will add another nice feature to the features list of IRCservices5.
37977 _________________________________________________________________
37978 Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
37979 using MSN Messenger http://entertainment.msn.com/imastar
37982 From Craig at chatspike.net Fri Aug 29 13:41:59 2003
37983 From: Craig at chatspike.net (Craig McLure)
37984 Date: Sat Oct 23 23:10:07 2004
37985 Subject: [IRCServices Coding] Yet, another great suggestion
37986 Message-ID: <20030829204143.NNNT26404.mta1-svc.business.ntl.com@i-br0ked-it>
37988 I'll ask again.. can you please stop posting to both the IRCServices mailing list, and the IRCd coding mailing list, getting your mail 2ce is beginning to annoy me.
37990 And i'll Quote Elijah:
37992 "Except it's already been said in the FAQ that it's not going to happen, and
37993 if that made it into the FAQ it would seem the answer is frequently going to
37997 /****************************************
37998 * Craig "FrostyCoolSlug" McLure
37999 ************* - SpamBox - **************
38000 * InspIRCd - http://www.inspircd.org
38001 * ChatSpike - http://www.chatspike.net
38002 * WinBot - http://www.winbot.co.uk
38003 ****************************************/
38005 /****************************************
38006 * From - us44ever . <us44ever@hotmail.com>
38007 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
38008 * Sent - 2003-08-29 @ 20:09:00
38009 * Subject - Re: [IRCServices Coding] Yet, another great suggestion
38010 ****************************************/
38012 /****** - Begin Original Message - ******/
38014 >Since most people want to see this feature(s) in the next version, it would
38015 >be great to implement it as an optional feature , where it can be disabled
38016 >from the .conf file(s) or enable it easily. I don't think that there is
38017 >anything that the authors will lose if this feature can be added, in fact,
38018 >it will add another nice feature to the features list of IRCservices5.
38020 >_________________________________________________________________
38021 >Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
38022 >using MSN Messenger http://entertainment.msn.com/imastar
38024 >------------------------------------------------------------------
38025 >To unsubscribe or change your subscription options, visit:
38026 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
38029 /******* - End Original Message - *******/
38034 From Craig at chatspike.net Fri Aug 29 13:43:24 2003
38035 From: Craig at chatspike.net (Craig McLure)
38036 Date: Sat Oct 23 23:10:07 2004
38037 Subject: [IRCServices Coding] AKill suggestion
38038 Message-ID: <20030829204311.GHCL29825.mta5-svc.business.ntl.com@i-br0ked-it>
38040 its a stupid idea!!! :p
38042 j/k.. I think its a great idea.. i'd rather have services telling users when their akills expire, than them spamming my mailbox with 'when does my akill expire?' every 20mins :p
38044 /****************************************
38045 * Craig "FrostyCoolSlug" McLure
38046 ************* - SpamBox - **************
38047 * InspIRCd - http://www.inspircd.org
38048 * ChatSpike - http://www.chatspike.net
38049 * WinBot - http://www.winbot.co.uk
38050 ****************************************/
38052 /****************************************
38053 * From - Saturn <saturn@jetirc.net>
38054 * To - IRC Services Coding Mailing List <ircservices-coding@ircservices.za.net>
38055 * Sent - 2003-08-28 @ 17:13:00
38056 * Subject - [IRCServices Coding] AKill suggestion
38057 ****************************************/
38059 /****** - Begin Original Message - ******/
38061 >Would it be possible to have it announce to the user when they are akilled,
38062 >either the expiry date and time, or "Expires in 3days, 4hours, 6minutes" or
38063 >something similar. I find that usually we just have to do 24hour bans, but
38064 >the user has no way to know when the ban was set, and when it expires...
38066 >Just an idea... I now await the half dozen people who will proceed to tell
38067 >me how stupid my idea is....
38073 >------------------------------------------------------------------
38074 >To unsubscribe or change your subscription options, visit:
38075 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
38077 /******* - End Original Message - *******/
38082 From admin at nevernet.net Fri Aug 29 13:48:01 2003
38083 From: admin at nevernet.net (Elijah)
38084 Date: Sat Oct 23 23:10:07 2004
38085 Subject: [IRCServices Coding] Yet, another great suggestion
38086 In-Reply-To: <20030829204143.NNNT26404.mta1-svc.business.ntl.com@i-br0ked-it>
38087 Message-ID: <008f01c36e6e$83158770$436a3a44@slytherin>
38091 -----Original Message-----
38092 From: ircservices-coding-bounces@ircservices.za.net
38093 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of Craig
38095 Sent: Friday, August 29, 2003 4:41 PM
38096 To: IRC Services Coding Mailing List
38097 Subject: Re: Re: [IRCServices Coding] Yet, another great suggestion
38100 I'll ask again.. can you please stop posting to both the IRCServices mailing
38101 list, and the IRCd coding mailing list, getting your mail 2ce is beginning
38104 And i'll Quote Elijah:
38106 "Except it's already been said in the FAQ that it's not going to happen, and
38107 if that made it into the FAQ it would seem the answer is frequently going to
38112 From us44ever at hotmail.com Fri Aug 29 16:59:31 2003
38113 From: us44ever at hotmail.com (us44ever .)
38114 Date: Sat Oct 23 23:10:07 2004
38115 Subject: [IRCServices Coding] Yet, another great suggestion
38116 Message-ID: <Sea1-F30z1oyZF58m3O00035b82@hotmail.com>
38118 woops, ok sorry I thought the two e-mails is completely different.
38121 >From: "Craig McLure" <Craig@chatspike.net>
38122 >Reply-To: IRC Services Coding Mailing List
38123 ><ircservices-coding@ircservices.za.net>
38124 >To: IRC Services Coding Mailing List
38125 ><ircservices-coding@ircservices.za.net>
38126 >Subject: Re: Re: [IRCServices Coding] Yet, another great suggestion
38127 >Date: Fri, 29 Aug 2003 21:41:23 +0000
38129 >I'll ask again.. can you please stop posting to both the IRCServices
38130 >mailing list, and the IRCd coding mailing list, getting your mail 2ce is
38131 >beginning to annoy me.
38133 >And i'll Quote Elijah:
38135 >"Except it's already been said in the FAQ that it's not going to happen,
38137 >if that made it into the FAQ it would seem the answer is frequently going
38142 >/****************************************
38143 > * Craig "FrostyCoolSlug" McLure
38144 > ************* - SpamBox - **************
38145 > * InspIRCd - http://www.inspircd.org
38146 > * ChatSpike - http://www.chatspike.net
38147 > * WinBot - http://www.winbot.co.uk
38148 > ****************************************/
38150 >/****************************************
38151 > * From - us44ever . <us44ever@hotmail.com>
38152 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
38153 > * Sent - 2003-08-29 @ 20:09:00
38154 > * Subject - Re: [IRCServices Coding] Yet, another great suggestion
38155 > ****************************************/
38157 >/****** - Begin Original Message - ******/
38159 > >Since most people want to see this feature(s) in the next version, it
38161 > >be great to implement it as an optional feature , where it can be
38163 > >from the .conf file(s) or enable it easily. I don't think that there is
38164 > >anything that the authors will lose if this feature can be added, in
38166 > >it will add another nice feature to the features list of IRCservices5.
38168 > >_________________________________________________________________
38169 > >Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
38170 > >using MSN Messenger http://entertainment.msn.com/imastar
38172 > >------------------------------------------------------------------
38173 > >To unsubscribe or change your subscription options, visit:
38174 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
38177 >/******* - End Original Message - *******/
38181 >------------------------------------------------------------------
38182 >To unsubscribe or change your subscription options, visit:
38183 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
38185 _________________________________________________________________
38186 MSN 8: Get 6 months for $9.95/month. http://join.msn.com/?page=dept/dialup
38189 From simorgh at dataphone.se Sat Aug 30 08:27:11 2003
38190 From: simorgh at dataphone.se (Ali Simorgh)
38191 Date: Sat Oct 23 23:10:07 2004
38192 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
38193 In-Reply-To: <MKEGJINFADFODDNOKEJCMEEADPAA.rg@tcslon.com>
38194 Message-ID: <Pine.GSO.4.31.0308301716410.15629-100000@nikson.dataphone.se>
38197 I run ircservices 5.0.21 on FreeBSD 4.8-STABLE. and Ultimate 3.*
38198 I get this in logfile:
38200 [Aug 30 10:51:19 2003] unknown message from server
38201 (NETCTRL 0 0 0 0 0 0 0 0 0 0 0 0 0)
38202 [Aug 30 10:51:19 2003] user: New maximum user count: 1
38203 [Aug 30 10:51:19 2003] unknown message from server
38204 (:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
38205 [Aug 30 10:51:19 2003] user: New maximum user count: 2
38206 [Aug 30 10:51:19 2003] unknown message from server
38207 (:irc.MyNet.Net SETHOST pedarkhAnde 6b45bb2.26d9672f.dataphone.se)
38208 [Aug 30 10:56:18 2003] mail/sendmail:
38209 /usr/sbin/sendmail exited with code 25600
38210 [Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
38211 registration (Simorgh)
38213 and how can I do so that nickserv dont show the realhost of a user in
38220 ______________________________________________________
38221 Many of life's failures are people who did not realize
38222 how close they were to success when they gave up.
38224 ______________________________________________________
38229 From jskam at shaw.ca Sat Aug 30 11:34:35 2003
38230 From: jskam at shaw.ca (Jeffery Kam)
38231 Date: Sat Oct 23 23:10:07 2004
38232 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
38233 In-Reply-To: <Pine.GSO.4.31.0308301716410.15629-100000@nikson.dataphone.se>
38234 Message-ID: <000001c36f25$58464860$f64f9144@weed>
38236 "and how can I do so that nickserv dont show the realhost of a user in
38237 'ns info nick all'"
38239 This would be a great feature for sure. I know on my network, there is
38240 a custom user mode +d, which will disguise a user's host in a /whois
38241 reply, but services info doesn't show it disguised unless the HIDE
38246 From achurch at achurch.org Sat Aug 30 16:14:47 2003
38247 From: achurch at achurch.org (Andrew Church)
38248 Date: Sat Oct 23 23:10:07 2004
38249 Subject: [IRCServices Coding] MARK Command
38250 In-Reply-To: <3208.66.181.69.244.1060800845.squirrel@dreamchat.org>
38251 Message-ID: <3f512fdb.01666@achurch.org>
38253 Use E-mail if you need communication of that sort.
38256 achurch@achurch.org
38257 http://achurch.org/
38259 >First off, i would like to say that IRCservices are the best services out
38260 >there, by FAR! Anyways, i was wondering if the MARK command will be in
38261 >the next relase? Its kind of a pointless command, its only used to mark
38262 >nicks or channels, but it is very useful for when passwords to channels
38265 >/chanserv MARK <channel> <reason>
38267 >/chanserv info #channel would read the following.
38268 >*#channel has been MARKED by playa - <reason>
38270 >Of course only IRCops would be able to view it.
38272 >Just an idea i thought of :)
38277 >Network Founder/CEO
38278 >DreamChat IRC Network - irc.dreamchat.org
38279 >http://www.dreamchat.org
38281 >------------------------------------------------------------------
38282 >To unsubscribe or change your subscription options, visit:
38283 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
38285 From achurch at achurch.org Sat Aug 30 16:17:44 2003
38286 From: achurch at achurch.org (Andrew Church)
38287 Date: Sat Oct 23 23:10:07 2004
38288 Subject: [IRCServices Coding] OP/Voice upon identify
38289 In-Reply-To: <Pine.GSO.4.31.0308211027350.6118-100000@nikson.dataphone.se>
38290 Message-ID: <3f513092.01677@achurch.org>
38292 Needless complexity. If you don't want yourself autoopped, then don't
38293 be an auto-op. It's that simple.
38296 achurch@achurch.org
38297 http://achurch.org/
38300 >Its nice with this option. but I dont se any set command that ChanServ
38301 >wont automatically op or voice you in any channel.
38304 > SET NOAUTO ON|OFF
38305 > When NOAUTO is on, ChanServ will not
38306 > automatically op or voice you in any channels.
38308 >Maybe some user(s) wont get auto op/voice then they can set this option ON
38309 >but it sould be OFF in default.
38316 > ______________________________________________________
38317 > Many of life's failures are people who did not realize
38318 > how close they were to success when they gave up.
38320 > ______________________________________________________
38323 >On Sun, 17 Aug 2003, Russell Garrett wrote:
38325 >> Eh? This has been implemented since IRCServices 5a31.
38329 >> > I wonder if its possible to make some modification that:
38330 >> > when someone has already joined a few channels, and then identifies
38331 >> > to its nickname, chanserv gives Voice and/or Op to the user is s/he
38332 >> > is in the channel list (+o; aop or above & +v when vop)
38334 >> > this is very usefull to not privmsg chanserv for every op or voice
38335 >> > request, when user has not identified to its nick before joining
38338 >> > Thanks for any help
38340 >> ------------------------------------------------------------------
38341 >> To unsubscribe or change your subscription options, visit:
38342 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
38345 >------------------------------------------------------------------
38346 >To unsubscribe or change your subscription options, visit:
38347 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
38349 From l8nite at l8nite.net Sat Aug 30 16:58:16 2003
38350 From: l8nite at l8nite.net (Shaun Guth)
38351 Date: Sat Oct 23 23:10:07 2004
38352 Subject: [IRCServices Coding] OP/Voice upon identify
38353 In-Reply-To: <3f513092.01677@achurch.org>
38354 References: <3f513092.01677@achurch.org>
38355 Message-ID: <1062287885.21924.6.camel@localhost>
38357 On Sun, 2003-08-31 at 01:16, Andrew Church wrote:
38358 > Needless complexity. If you don't want yourself autoopped, then don't
38359 > be an auto-op. It's that simple.
38361 I disagree. In my case, I wanted to create a channel where there were
38362 no ops so users don't have to endure lame op-wars, etc. However, I did
38363 need to maintain a level of control over the channel to protect from
38364 extremely obnoxious behavior or lame bots, etc. By registering as
38365 founder of the channel I induced the unwanted 'auto-op' behavior. My
38366 only solution was to register another fake user to become channel
38367 founder and set their nick to noexpire. That to me seems like needless
38368 complexity. A simple check to see if the user wishes to be opped or not
38374 From Craig at chatspike.net Sat Aug 30 17:07:32 2003
38375 From: Craig at chatspike.net (Craig McLure)
38376 Date: Sat Oct 23 23:10:07 2004
38377 Subject: [IRCServices Coding] OP/Voice upon identify
38378 Message-ID: <20030831000719.ELIJ19019.mta3-svc.business.ntl.com@i-br0ked-it>
38380 it would thou.. they would have to be able to switch off auto-op for a single channel..
38381 you could always use /cs levels to change the 'auto op' level up.. so that no one is auto-opped..
38383 or /cs levels #channels DISABLE autoop
38385 /****************************************
38386 * Craig "FrostyCoolSlug" McLure
38387 ************* - SpamBox - **************
38388 * InspIRCd - http://www.inspircd.org
38389 * ChatSpike - http://www.chatspike.net
38390 * WinBot - http://www.winbot.co.uk
38391 ****************************************/
38393 /****************************************
38394 * From - Shaun Guth <l8nite@l8nite.net>
38395 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
38396 * Sent - 2003-08-30 @ 16:58:00
38397 * Subject - RE: [IRCServices Coding] OP/Voice upon identify
38398 ****************************************/
38400 /****** - Begin Original Message - ******/
38402 >On Sun, 2003-08-31 at 01:16, Andrew Church wrote:
38403 >> Needless complexity. If you don't want yourself autoopped, then don't
38404 >> be an auto-op. It's that simple.
38406 >I disagree. In my case, I wanted to create a channel where there were
38407 >no ops so users don't have to endure lame op-wars, etc. However, I did
38408 >need to maintain a level of control over the channel to protect from
38409 >extremely obnoxious behavior or lame bots, etc. By registering as
38410 >founder of the channel I induced the unwanted 'auto-op' behavior. My
38411 >only solution was to register another fake user to become channel
38412 >founder and set their nick to noexpire. That to me seems like needless
38413 >complexity. A simple check to see if the user wishes to be opped or not
38418 >------------------------------------------------------------------
38419 >To unsubscribe or change your subscription options, visit:
38420 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
38423 /******* - End Original Message - *******/
38428 From l8nite at l8nite.net Sat Aug 30 17:14:44 2003
38429 From: l8nite at l8nite.net (Shaun Guth)
38430 Date: Sat Oct 23 23:10:07 2004
38431 Subject: [IRCServices Coding] OP/Voice upon identify
38432 In-Reply-To: <20030831000719.ELIJ19019.mta3-svc.business.ntl.com@i-br0ked-it>
38433 References: <20030831000719.ELIJ19019.mta3-svc.business.ntl.com@i-br0ked-it>
38434 Message-ID: <1062288881.21924.17.camel@localhost>
38436 On Sat, 2003-08-30 at 18:06, Craig McLure wrote:
38437 > it would thou.. they would have to be able to switch off auto-op for a single channel..
38439 For each channel we already store an access list, one extra bit to
38440 indicate auto-anything status or not is not really asking too much.
38442 > you could always use /cs levels to change the 'auto op' level up.. so that no one is auto-opped..
38443 > or /cs levels #channels DISABLE autoop
38445 -ChanServ- Channel #foobar registered under your nickname: l8
38446 -ChanServ- AUTOOP disabled on channel #foobar.
38447 --- You have left channel #foobar
38448 --> You are now talking on #foobar
38449 --- services.topgamers.net removes channel operator status from l8
38450 --- services.topgamers.net gives channel operator status to l8
38452 Same with ENFORCE set to off as well.
38454 > [snipped obnoxiously long sig]
38459 From achurch at achurch.org Sun Aug 31 02:58:23 2003
38460 From: achurch at achurch.org (Andrew Church)
38461 Date: Sat Oct 23 23:10:07 2004
38462 Subject: [IRCServices Coding] OP/Voice upon identify
38463 In-Reply-To: <1062288881.21924.17.camel@localhost>
38464 Message-ID: <3f51c6b5.07402@achurch.org>
38466 >> you could always use /cs levels to change the 'auto op' level up.. so that no one is auto-opped..
38467 >> or /cs levels #channels DISABLE autoop
38469 >-ChanServ- Channel #foobar registered under your nickname: l8
38470 >-ChanServ- AUTOOP disabled on channel #foobar.
38471 >--- You have left channel #foobar
38472 >--> You are now talking on #foobar
38473 >--- services.topgamers.net removes channel operator status from l8
38474 >--- services.topgamers.net gives channel operator status to l8
38476 This is definitely confusing behavior. Fixed for 5.0.22, thanks for
38477 the report. Note that you will also want to disable the other AUTOxxx
38478 levels as well if you don't want any automatic modes.
38481 achurch@achurch.org
38482 http://achurch.org/
38484 From achurch at achurch.org Sun Aug 31 07:28:11 2003
38485 From: achurch at achurch.org (Andrew Church)
38486 Date: Sat Oct 23 23:10:07 2004
38487 Subject: [IRCServices Coding] Mass memos
38488 In-Reply-To: <001601c361d8$a5312f00$6401a8c0@turby>
38489 Message-ID: <3f5205f0.15057@achurch.org>
38491 >Can we reconsider adding a Mass memo function for the next release?
38493 No, for all the reasons others have mentioned. I'll also draw an
38494 example from my experience with cellphone mail in Japan, which is
38495 remarkably similar to Services memos: Automated messages are annoying,
38496 period. The primary use for cellphone mail is to communicate with friends;
38497 having automatic messages interfere with that is annoying in the extreme.
38498 Yes, 10% or 20% of your users might be willing to accept mass memos, but
38499 the remaining 80% or 90% will get quite upset with you.
38501 I might also point out that people who care about what happens on the
38502 network will actively check that information, whether you make it available
38503 through logon news, through a website, or whatever; and people who don't
38504 care will ignore anything you send them. The method you use to inform them
38505 won't really make a difference.
38507 >If not, or even if so... one thing puzzles me: In the /ns list * command,
38508 >the listings have occasional punctuation... a ! or ? in front of the nick.
38509 >There is nothing in the docs anywhere that seems to address this, and I'm
38510 >curious as to what those mean.... an explanation would be helpful there too.
38512 This should be available through /ns help list, but there appears to
38513 be a bug there. I'll fix it for the next version.
38515 >on that note, a possible suggestion for Logonnews... How about something I
38516 >saw on Dalnet once: When new news is added, you get a notice. Until you
38517 >read the news, it keeps bugging you when you log on. After you read it, it
38518 >stops. Some sort of flag so users know when there IS new news would be
38519 >useful... the main reason nobody read the logonnews is that 90% of the time
38520 >for them, it is unchanged........
38522 This is an interesting thought; I'll think about it for a future
38526 achurch@achurch.org
38527 http://achurch.org/
38529 From achurch at achurch.org Sun Aug 31 07:42:30 2003
38530 From: achurch at achurch.org (Andrew Church)
38531 Date: Sat Oct 23 23:10:07 2004
38532 Subject: [IRCServices Coding] Language
38533 In-Reply-To: <MKEGJINFADFODDNOKEJCKEEDDPAA.rg@tcslon.com>
38534 Message-ID: <3f52094e.17046@achurch.org>
38536 [/msg nickserv vs. /nickserv]
38537 >I wonder if it would be worth integrating such a thing into services as an
38538 >option (compile-time maybe?). I think it would be good for the irc community
38539 >as a whole to get away from the habit of msging services directly if at all
38540 >possible. Opinions?
38542 /msg NickServ is the one format that's guaranteed to work on every
38543 ircd (except for administrative decisions a la DALnet). Get an RFC
38544 published--and implemented; 2811-3 were remarkable failures in that area--
38545 and I'll consider changing it.
38548 achurch@achurch.org
38549 http://achurch.org/
38551 From achurch at achurch.org Sun Aug 31 07:45:49 2003
38552 From: achurch at achurch.org (Andrew Church)
38553 Date: Sat Oct 23 23:10:07 2004
38554 Subject: [IRCServices Coding] Language
38555 In-Reply-To: <Pine.GSO.4.31.0308172127300.9882-100000@nikson.dataphone.se>
38556 Message-ID: <3f520a18.17063@achurch.org>
38558 >Is there any tool (silly question) or something or guid to make a language
38561 >I have decided to make a Persian (Farsi) language file.
38563 Language files are just plain text files; as another reply said, read
38564 the comments at the top of lang/en_us.l, and work from there. Be warned
38565 that the amount of text is huge; expect to spend at least two to three
38566 months on the initial translation.
38568 Also, if you'd be willing to continue maintaining the language file as
38569 it is updated in future versions, please let me know privately.
38572 achurch@achurch.org
38573 http://achurch.org/
38575 From achurch at achurch.org Sun Aug 31 07:53:21 2003
38576 From: achurch at achurch.org (Andrew Church)
38577 Date: Sat Oct 23 23:10:07 2004
38578 Subject: [IRCServices Coding] segfault on expiring ?
38579 In-Reply-To: <001201c36793$d26e4000$0101a8c0@nothing>
38580 Message-ID: <3f520bd8.17715@achurch.org>
38582 >[Aug 20 20:49:05 2003] nickserv/main: Expiring suspension for SeBa_KoBe (nick group 17805)
38583 >[Aug 20 20:49:05 2003] nickserv/main: Expiring nickname SeBa_KoBe
38584 >[Aug 20 20:49:05 2003] nickserv/main: [Aug 20 20:49:05 2003] Services terminating: Segmentation Faul
38586 I can't reproduce this problem. If this is still occurring, can you
38587 send me your databases privately so that I can investigate it?
38590 achurch@achurch.org
38591 http://achurch.org/
38593 From andrewk at isdial.net Tue Aug 26 02:43:45 2003
38594 From: andrewk at isdial.net (Andrew Kempe)
38595 Date: Sat Oct 23 23:10:07 2004
38596 Subject: [IRCServices Coding] test
38597 Message-ID: <005801c36bb6$85bbc080$1f0912ac@espotting.com>
38601 From us44ever at hotmail.com Thu Aug 28 09:45:48 2003
38602 From: us44ever at hotmail.com (us44ever .)
38603 Date: Sat Oct 23 23:10:07 2004
38604 Subject: [IRCServices Coding] Yet, another great suggestion
38605 Message-ID: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
38609 it would be really great to add another new line to the "/nickserv info"
38610 command, for example, when some one types: "/nickserv info nick", the
38611 following will be shown:
38613 ***************************
38615 -NickServ- nick is hello world
38617 -NickServ- Is online from: ~test@just.a.test.co.za
38619 -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
38621 -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
38623 -NickServ- Last quit message: anythinggggg
38625 -NickServ- Options: Kill protection, Security
38627 ***************************
38629 the new line I'm suggesting is something like:
38631 ***************************
38632 -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
38633 ***************************
38635 This will help our users to compare the time that user was last seen and the
38636 time right now *it's very important, many many of our users asked us for
38637 this option*, also it would even be more great to show how long last time
38638 the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003 GMT
38639 (last seen time was before: 10 days, 3hours and 24 sec ago).
38641 Note that I saw both of these features, in other services I don't remember
38642 there names (but they aren't as stable as ircservices5) (it was something
38643 like ptlink services, and magik II)
38645 That's all, I would really like to see it on the next version (or if you can
38646 show me how to do it, as I'm not a programmer)
38648 Many thanks to all of who developed IRCservices ...etc ...etc ...etc
38653 _________________________________________________________________
38654 Get MSN 8 and enjoy automatic e-mail virus protection.
38655 http://join.msn.com/?page=features/virus
38658 From aragon at phat.za.net Thu Aug 28 11:36:22 2003
38659 From: aragon at phat.za.net (Aragon Gouveia)
38660 Date: Sat Oct 23 23:10:07 2004
38661 Subject: [IRCServices Coding] Yet, another great suggestion
38662 In-Reply-To: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
38663 References: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
38664 Message-ID: <20030828183615.GB32204@phat.za.net>
38666 Or how about rather letting users decide what timezone they're in and
38667 services outputs all timestamps in their local time?
38670 | By us44ever . <us44ever@hotmail.com>
38671 | [ 2003-08-28 18:45 +0200 ]
38674 > it would be really great to add another new line to the "/nickserv info"
38675 > command, for example, when some one types: "/nickserv info nick", the
38676 > following will be shown:
38678 > ***************************
38680 > -NickServ- nick is hello world
38682 > -NickServ- Is online from: ~test@just.a.test.co.za
38684 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
38686 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
38688 > -NickServ- Last quit message: anythinggggg
38690 > -NickServ- Options: Kill protection, Security
38692 > ***************************
38694 > the new line I'm suggesting is something like:
38696 > ***************************
38697 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
38698 > ***************************
38700 > This will help our users to compare the time that user was last seen and
38701 > the time right now *it's very important, many many of our users asked us
38702 > for this option*, also it would even be more great to show how long last
38703 > time the user was seen (some thing like: Last seen time: Aug 28 15:51:14
38704 > 2003 GMT (last seen time was before: 10 days, 3hours and 24 sec ago).
38706 > Note that I saw both of these features, in other services I don't remember
38707 > there names (but they aren't as stable as ircservices5) (it was something
38708 > like ptlink services, and magik II)
38710 > That's all, I would really like to see it on the next version (or if you
38711 > can show me how to do it, as I'm not a programmer)
38713 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
38718 > _________________________________________________________________
38719 > Get MSN 8 and enjoy automatic e-mail virus protection.
38720 > http://join.msn.com/?page=features/virus
38722 > ------------------------------------------------------------------
38723 > To unsubscribe or change your subscription options, visit:
38724 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
38726 From saturn at jetirc.net Thu Aug 28 11:39:41 2003
38727 From: saturn at jetirc.net (Saturn)
38728 Date: Sat Oct 23 23:10:07 2004
38729 Subject: [IRCServices Coding] Yet, another great suggestion
38730 References: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
38731 <20030828183615.GB32204@phat.za.net>
38732 Message-ID: <003201c36d93$abf77fd0$6401a8c0@turby>
38734 Oooo now I like that option... have it default to a default timezone, set in
38735 the conf file, and give them the option of SETting a different UTC code
38736 (have it as GMT + or - x wheer x is the offset from UTC)... It may not
38737 sound liek much, but I bet people will use it, and what's more, it IS useful
38738 information, especially on international servers like mine.. we have people
38739 from all over the place, and we keep services set on Pacific time... but for
38740 those in, say, Belgium... that's not very helpful
38742 ----- Original Message -----
38743 From: "Aragon Gouveia" <aragon@phat.za.net>
38744 To: <ircservices-coding@ircservices.za.net>
38745 Sent: Thursday, August 28, 2003 11:36 AM
38746 Subject: Re: [IRCServices Coding] Yet, another great suggestion
38749 Or how about rather letting users decide what timezone they're in and
38750 services outputs all timestamps in their local time?
38753 | By us44ever . <us44ever@hotmail.com>
38754 | [ 2003-08-28 18:45 +0200 ]
38757 > it would be really great to add another new line to the "/nickserv info"
38758 > command, for example, when some one types: "/nickserv info nick", the
38759 > following will be shown:
38761 > ***************************
38763 > -NickServ- nick is hello world
38765 > -NickServ- Is online from: ~test@just.a.test.co.za
38767 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
38769 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
38771 > -NickServ- Last quit message: anythinggggg
38773 > -NickServ- Options: Kill protection, Security
38775 > ***************************
38777 > the new line I'm suggesting is something like:
38779 > ***************************
38780 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
38781 > ***************************
38783 > This will help our users to compare the time that user was last seen and
38784 > the time right now *it's very important, many many of our users asked us
38785 > for this option*, also it would even be more great to show how long last
38786 > time the user was seen (some thing like: Last seen time: Aug 28 15:51:14
38787 > 2003 GMT (last seen time was before: 10 days, 3hours and 24 sec ago).
38789 > Note that I saw both of these features, in other services I don't remember
38790 > there names (but they aren't as stable as ircservices5) (it was something
38791 > like ptlink services, and magik II)
38793 > That's all, I would really like to see it on the next version (or if you
38794 > can show me how to do it, as I'm not a programmer)
38796 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
38801 > _________________________________________________________________
38802 > Get MSN 8 and enjoy automatic e-mail virus protection.
38803 > http://join.msn.com/?page=features/virus
38805 > ------------------------------------------------------------------
38806 > To unsubscribe or change your subscription options, visit:
38807 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
38808 ------------------------------------------------------------------
38809 To unsubscribe or change your subscription options, visit:
38810 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
38814 From Craig at chatspike.net Thu Aug 28 14:29:54 2003
38815 From: Craig at chatspike.net (Craig McLure)
38816 Date: Sat Oct 23 23:10:07 2004
38817 Subject: [IRCServices Coding] Yet, another great suggestion
38818 Message-ID: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
38820 Please dont post to both the services main list, and the services coding list. Choose one, or the other, especially concidering i dont think this is a great suggestion either..
38822 /time services.chatspike.net
38823 [22:28]
\95\95\95 Date / time at services.chatspike.net- Thu Aug 28 17:28:57 2003 EDT
38827 /****************************************
38828 * Craig "FrostyCoolSlug" McLure
38829 ************* - SpamBox - **************
38830 * InspIRCd - http://www.inspircd.org
38831 * ChatSpike - http://www.chatspike.net
38832 * WinBot - http://www.winbot.co.uk
38833 ****************************************/
38835 /****************************************
38836 * From - us44ever . <us44ever@hotmail.com>
38837 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
38838 * Sent - 2003-08-28 @ 16:45:00
38839 * Subject - [IRCServices Coding] Yet, another great suggestion
38840 ****************************************/
38842 /****** - Begin Original Message - ******/
38846 >it would be really great to add another new line to the "/nickserv info"
38847 >command, for example, when some one types: "/nickserv info nick", the
38848 >following will be shown:
38850 >***************************
38852 >-NickServ- nick is hello world
38854 >-NickServ- Is online from: ~test@just.a.test.co.za
38856 >-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
38858 >-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
38860 >-NickServ- Last quit message: anythinggggg
38862 >-NickServ- Options: Kill protection, Security
38864 >***************************
38866 >the new line I'm suggesting is something like:
38868 >***************************
38869 >-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
38870 >***************************
38872 >This will help our users to compare the time that user was last seen and the
38873 >time right now *it's very important, many many of our users asked us for
38874 >this option*, also it would even be more great to show how long last time
38875 >the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003 GMT
38876 >(last seen time was before: 10 days, 3hours and 24 sec ago).
38878 >Note that I saw both of these features, in other services I don't remember
38879 >there names (but they aren't as stable as ircservices5) (it was something
38880 >like ptlink services, and magik II)
38882 >That's all, I would really like to see it on the next version (or if you can
38883 >show me how to do it, as I'm not a programmer)
38885 >Many thanks to all of who developed IRCservices ...etc ...etc ...etc
38890 >_________________________________________________________________
38891 >Get MSN 8 and enjoy automatic e-mail virus protection.
38892 >http://join.msn.com/?page=features/virus
38894 >------------------------------------------------------------------
38895 >To unsubscribe or change your subscription options, visit:
38896 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
38898 /******* - End Original Message - *******/
38903 From nothing at psychopat.org Thu Aug 28 14:57:31 2003
38904 From: nothing at psychopat.org (Marc-Andre A. Fuentes)
38905 Date: Sat Oct 23 23:10:07 2004
38906 Subject: [IRCServices Coding] BUG Report
38907 Message-ID: <001501c36daf$c8cba700$0101a8c0@house>
38909 We're having a small problem with suspended channel.
38911 we suspended channel #kavala, and someone has identified itself has the founder and apply a DROP to the channel.
38912 then we got a panic from the services and... crash.
38914 Also with suspended nick , when the suspencion expire, the services crash
38917 ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
38922 -------------- next part --------------
38923 An HTML attachment was scrubbed...
38924 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030828/1f31ccf5/attachment-0003.htm
38925 From Craig at chatspike.net Thu Aug 28 15:24:36 2003
38926 From: Craig at chatspike.net (Craig McLure)
38927 Date: Sat Oct 23 23:10:07 2004
38928 Subject: [IRCServices Coding] BUG Report
38929 Message-ID: <20030828222401.JVQE12036.mta4-svc.business.ntl.com@i-br0ked-it>
38931 hmm.. what OS, compiler version etc are you using?
38933 after a test, i got the following:
38935 /cs id #abc 00376370
38936 -ChanServ- Channel #abc is suspended and may not be used or identified for.
38939 [23:20] -ChanServ- Channel is suspended and may not be used or identified for.
38941 only prob i got was it missed the channel name in the second message :)
38944 /****************************************
38945 * Craig "FrostyCoolSlug" McLure
38946 ************* - SpamBox - **************
38947 * InspIRCd - http://www.inspircd.org
38948 * ChatSpike - http://www.chatspike.net
38949 * WinBot - http://www.winbot.co.uk
38950 ****************************************/
38952 /****************************************
38953 * From - Marc-Andre A. Fuentes <nothing@psychopat.org>
38954 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
38955 * Sent - 2003-08-28 @ 18:00:00
38956 * Subject - [IRCServices Coding] BUG Report
38957 ****************************************/
38959 /****** - Begin Original Message - ******/
38961 >We're having a small problem with suspended channel.
38963 >we suspended channel #kavala, and someone has identified itself has the founder and apply a DROP to the channel.
38964 >then we got a panic from the services and... crash.
38966 >Also with suspended nick , when the suspencion expire, the services crash
38969 >ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
38974 >------------------------------------------------------------------
38975 >To unsubscribe or change your subscription options, visit:
38976 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
38978 /******* - End Original Message - *******/
38983 From saturn at jetirc.net Thu Aug 28 17:13:48 2003
38984 From: saturn at jetirc.net (Saturn)
38985 Date: Sat Oct 23 23:10:07 2004
38986 Subject: [IRCServices Coding] AKill suggestion
38987 References: <2C31F186-CDEE-11D7-979C-0003938D6866@mac.com>
38988 Message-ID: <009001c36dc2$64b56b80$6401a8c0@turby>
38990 Would it be possible to have it announce to the user when they are akilled,
38991 either the expiry date and time, or "Expires in 3days, 4hours, 6minutes" or
38992 something similar. I find that usually we just have to do 24hour bans, but
38993 the user has no way to know when the ban was set, and when it expires...
38995 Just an idea... I now await the half dozen people who will proceed to tell
38996 me how stupid my idea is....
39003 From playa at dreamchat.org Thu Aug 28 20:46:19 2003
39004 From: playa at dreamchat.org (playa)
39005 Date: Sat Oct 23 23:10:07 2004
39006 Subject: [IRCServices Coding] Yet, another great suggestion
39007 In-Reply-To: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
39008 References: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
39009 Message-ID: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
39011 Is this /time command only supposed to work via RAW? Cause when i type
39012 /time services.dreamchat.org i get No Such User, but if i do /raw time
39013 services.dreamchat.org, it works. Just wondering if its just me, or if
39014 its supposed to be that way.
39016 > Please dont post to both the services main list, and the services coding
39017 > list. Choose one, or the other, especially concidering i dont think this
39018 > is a great suggestion either..
39020 > /time services.chatspike.net
39021 > [22:28] ??? Date / time at services.chatspike.net- Thu Aug 28 17:28:57
39026 > /****************************************
39027 > * Craig "FrostyCoolSlug" McLure
39028 > ************* - SpamBox - **************
39029 > * InspIRCd - http://www.inspircd.org
39030 > * ChatSpike - http://www.chatspike.net
39031 > * WinBot - http://www.winbot.co.uk
39032 > ****************************************/
39034 > /****************************************
39035 > * From - us44ever . <us44ever@hotmail.com>
39036 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
39037 > * Sent - 2003-08-28 @ 16:45:00
39038 > * Subject - [IRCServices Coding] Yet, another great suggestion
39039 > ****************************************/
39041 > /****** - Begin Original Message - ******/
39045 >>it would be really great to add another new line to the "/nickserv info"
39046 >>command, for example, when some one types: "/nickserv info nick", the
39047 >>following will be shown:
39049 >>***************************
39051 >>-NickServ- nick is hello world
39053 >>-NickServ- Is online from: ~test@just.a.test.co.za
39055 >>-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
39057 >>-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
39059 >>-NickServ- Last quit message: anythinggggg
39061 >>-NickServ- Options: Kill protection, Security
39063 >>***************************
39065 >>the new line I'm suggesting is something like:
39067 >>***************************
39068 >>-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
39069 >>***************************
39071 >>This will help our users to compare the time that user was last seen and
39073 >>time right now *it's very important, many many of our users asked us for
39074 >>this option*, also it would even be more great to show how long last time
39075 >>the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003
39077 >>(last seen time was before: 10 days, 3hours and 24 sec ago).
39079 >>Note that I saw both of these features, in other services I don't
39081 >>there names (but they aren't as stable as ircservices5) (it was something
39082 >>like ptlink services, and magik II)
39084 >>That's all, I would really like to see it on the next version (or if you
39086 >>show me how to do it, as I'm not a programmer)
39088 >>Many thanks to all of who developed IRCservices ...etc ...etc ...etc
39093 >>_________________________________________________________________
39094 >>Get MSN 8 and enjoy automatic e-mail virus protection.
39095 >>http://join.msn.com/?page=features/virus
39097 >>------------------------------------------------------------------
39098 >>To unsubscribe or change your subscription options, visit:
39099 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
39101 > /******* - End Original Message - *******/
39105 > ------------------------------------------------------------------
39106 > To unsubscribe or change your subscription options, visit:
39107 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
39114 Network Founder/CEO
39115 DreamChat IRC Network - irc.dreamchat.org
39116 http://www.dreamchat.org
39119 From quension at mac.com Thu Aug 28 21:13:48 2003
39120 From: quension at mac.com (Trevor Talbot)
39121 Date: Sat Oct 23 23:10:07 2004
39122 Subject: [IRCServices Coding] Yet, another great suggestion
39123 In-Reply-To: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
39124 Message-ID: <0F823090-D9D7-11D7-8513-0003938D6866@mac.com>
39126 On Thursday, Aug 28, 2003, at 20:46 US/Pacific, playa wrote:
39128 > Is this /time command only supposed to work via RAW? Cause when i
39129 > type /time services.dreamchat.org i get No Such User, but if i do /raw
39130 > time services.dreamchat.org, it works. Just wondering if its just me,
39131 > or if its supposed to be that way.
39133 That's a client thing. Some clients might alias /time as a CTCP TIME
39134 for a specific user, or similar.
39139 From r-krisztian at softhome.net Thu Aug 28 22:12:51 2003
39140 From: r-krisztian at softhome.net (Krisztian Romek)
39141 Date: Sat Oct 23 23:10:07 2004
39142 Subject: [IRCServices Coding] Yet, another great suggestion
39143 In-Reply-To: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
39144 References: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
39145 <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
39146 Message-ID: <200308290713.29423.r-krisztian@softhome.net>
39148 > Is this /time command only supposed to work via RAW? Cause when i type
39149 > /time services.dreamchat.org i get No Such User, but if i do /raw time
39150 > services.dreamchat.org, it works. Just wondering if its just me, or if
39151 > its supposed to be that way.
39153 Some clients use stupid aliases for CTCP commands, for example:
39155 /version <nick> = /CTCP <nick> VERSION,
39156 /time <nick> = /CTCP <nick> TIME,
39157 /finger <nick> = /CTCP <nick> TIME
39159 This is why nothing works the way you expected.
39163 r-krisztian@softhome.net
39166 From us44ever at hotmail.com Fri Aug 29 13:02:19 2003
39167 From: us44ever at hotmail.com (us44ever .)
39168 Date: Sat Oct 23 23:10:07 2004
39169 Subject: [IRCServices Coding] AKill suggestion
39170 Message-ID: <Sea1-F108cM3oryKFRJ0000eb75@hotmail.com>
39172 Pretty good idea, specially is it would be implemented as an option (because
39173 some admins might won't like the idea of displaying the time of when the
39174 akill will expire to the user who has been akilled).
39176 _________________________________________________________________
39177 Help protect your PC: Get a free online virus scan at McAfee.com.
39178 http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
39181 From us44ever at hotmail.com Fri Aug 29 13:09:51 2003
39182 From: us44ever at hotmail.com (us44ever .)
39183 Date: Sat Oct 23 23:10:07 2004
39184 Subject: [IRCServices Coding] Yet, another great suggestion
39185 Message-ID: <Sea1-F127z33hqSnMGE000094b3@hotmail.com>
39188 Since most people want to see this feature(s) in the next version, it would
39189 be great to implement it as an optional feature , where it can be disabled
39190 from the .conf file(s) or enable it easily. I don't think that there is
39191 anything that the authors will lose if this feature can be added, in fact,
39192 it will add another nice feature to the features list of IRCservices5.
39194 _________________________________________________________________
39195 Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
39196 using MSN Messenger http://entertainment.msn.com/imastar
39199 From Craig at chatspike.net Fri Aug 29 13:41:59 2003
39200 From: Craig at chatspike.net (Craig McLure)
39201 Date: Sat Oct 23 23:10:07 2004
39202 Subject: [IRCServices Coding] Yet, another great suggestion
39203 Message-ID: <20030829204143.NNNT26404.mta1-svc.business.ntl.com@i-br0ked-it>
39205 I'll ask again.. can you please stop posting to both the IRCServices mailing list, and the IRCd coding mailing list, getting your mail 2ce is beginning to annoy me.
39207 And i'll Quote Elijah:
39209 "Except it's already been said in the FAQ that it's not going to happen, and
39210 if that made it into the FAQ it would seem the answer is frequently going to
39214 /****************************************
39215 * Craig "FrostyCoolSlug" McLure
39216 ************* - SpamBox - **************
39217 * InspIRCd - http://www.inspircd.org
39218 * ChatSpike - http://www.chatspike.net
39219 * WinBot - http://www.winbot.co.uk
39220 ****************************************/
39222 /****************************************
39223 * From - us44ever . <us44ever@hotmail.com>
39224 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
39225 * Sent - 2003-08-29 @ 20:09:00
39226 * Subject - Re: [IRCServices Coding] Yet, another great suggestion
39227 ****************************************/
39229 /****** - Begin Original Message - ******/
39231 >Since most people want to see this feature(s) in the next version, it would
39232 >be great to implement it as an optional feature , where it can be disabled
39233 >from the .conf file(s) or enable it easily. I don't think that there is
39234 >anything that the authors will lose if this feature can be added, in fact,
39235 >it will add another nice feature to the features list of IRCservices5.
39237 >_________________________________________________________________
39238 >Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
39239 >using MSN Messenger http://entertainment.msn.com/imastar
39241 >------------------------------------------------------------------
39242 >To unsubscribe or change your subscription options, visit:
39243 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
39246 /******* - End Original Message - *******/
39251 From Craig at chatspike.net Fri Aug 29 13:43:24 2003
39252 From: Craig at chatspike.net (Craig McLure)
39253 Date: Sat Oct 23 23:10:07 2004
39254 Subject: [IRCServices Coding] AKill suggestion
39255 Message-ID: <20030829204311.GHCL29825.mta5-svc.business.ntl.com@i-br0ked-it>
39257 its a stupid idea!!! :p
39259 j/k.. I think its a great idea.. i'd rather have services telling users when their akills expire, than them spamming my mailbox with 'when does my akill expire?' every 20mins :p
39261 /****************************************
39262 * Craig "FrostyCoolSlug" McLure
39263 ************* - SpamBox - **************
39264 * InspIRCd - http://www.inspircd.org
39265 * ChatSpike - http://www.chatspike.net
39266 * WinBot - http://www.winbot.co.uk
39267 ****************************************/
39269 /****************************************
39270 * From - Saturn <saturn@jetirc.net>
39271 * To - IRC Services Coding Mailing List <ircservices-coding@ircservices.za.net>
39272 * Sent - 2003-08-28 @ 17:13:00
39273 * Subject - [IRCServices Coding] AKill suggestion
39274 ****************************************/
39276 /****** - Begin Original Message - ******/
39278 >Would it be possible to have it announce to the user when they are akilled,
39279 >either the expiry date and time, or "Expires in 3days, 4hours, 6minutes" or
39280 >something similar. I find that usually we just have to do 24hour bans, but
39281 >the user has no way to know when the ban was set, and when it expires...
39283 >Just an idea... I now await the half dozen people who will proceed to tell
39284 >me how stupid my idea is....
39290 >------------------------------------------------------------------
39291 >To unsubscribe or change your subscription options, visit:
39292 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
39294 /******* - End Original Message - *******/
39299 From admin at nevernet.net Fri Aug 29 13:48:01 2003
39300 From: admin at nevernet.net (Elijah)
39301 Date: Sat Oct 23 23:10:07 2004
39302 Subject: [IRCServices Coding] Yet, another great suggestion
39303 In-Reply-To: <20030829204143.NNNT26404.mta1-svc.business.ntl.com@i-br0ked-it>
39304 Message-ID: <008f01c36e6e$83158770$436a3a44@slytherin>
39308 -----Original Message-----
39309 From: ircservices-coding-bounces@ircservices.za.net
39310 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of Craig
39312 Sent: Friday, August 29, 2003 4:41 PM
39313 To: IRC Services Coding Mailing List
39314 Subject: Re: Re: [IRCServices Coding] Yet, another great suggestion
39317 I'll ask again.. can you please stop posting to both the IRCServices mailing
39318 list, and the IRCd coding mailing list, getting your mail 2ce is beginning
39321 And i'll Quote Elijah:
39323 "Except it's already been said in the FAQ that it's not going to happen, and
39324 if that made it into the FAQ it would seem the answer is frequently going to
39329 From us44ever at hotmail.com Fri Aug 29 16:59:31 2003
39330 From: us44ever at hotmail.com (us44ever .)
39331 Date: Sat Oct 23 23:10:07 2004
39332 Subject: [IRCServices Coding] Yet, another great suggestion
39333 Message-ID: <Sea1-F30z1oyZF58m3O00035b82@hotmail.com>
39335 woops, ok sorry I thought the two e-mails is completely different.
39338 >From: "Craig McLure" <Craig@chatspike.net>
39339 >Reply-To: IRC Services Coding Mailing List
39340 ><ircservices-coding@ircservices.za.net>
39341 >To: IRC Services Coding Mailing List
39342 ><ircservices-coding@ircservices.za.net>
39343 >Subject: Re: Re: [IRCServices Coding] Yet, another great suggestion
39344 >Date: Fri, 29 Aug 2003 21:41:23 +0000
39346 >I'll ask again.. can you please stop posting to both the IRCServices
39347 >mailing list, and the IRCd coding mailing list, getting your mail 2ce is
39348 >beginning to annoy me.
39350 >And i'll Quote Elijah:
39352 >"Except it's already been said in the FAQ that it's not going to happen,
39354 >if that made it into the FAQ it would seem the answer is frequently going
39359 >/****************************************
39360 > * Craig "FrostyCoolSlug" McLure
39361 > ************* - SpamBox - **************
39362 > * InspIRCd - http://www.inspircd.org
39363 > * ChatSpike - http://www.chatspike.net
39364 > * WinBot - http://www.winbot.co.uk
39365 > ****************************************/
39367 >/****************************************
39368 > * From - us44ever . <us44ever@hotmail.com>
39369 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
39370 > * Sent - 2003-08-29 @ 20:09:00
39371 > * Subject - Re: [IRCServices Coding] Yet, another great suggestion
39372 > ****************************************/
39374 >/****** - Begin Original Message - ******/
39376 > >Since most people want to see this feature(s) in the next version, it
39378 > >be great to implement it as an optional feature , where it can be
39380 > >from the .conf file(s) or enable it easily. I don't think that there is
39381 > >anything that the authors will lose if this feature can be added, in
39383 > >it will add another nice feature to the features list of IRCservices5.
39385 > >_________________________________________________________________
39386 > >Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
39387 > >using MSN Messenger http://entertainment.msn.com/imastar
39389 > >------------------------------------------------------------------
39390 > >To unsubscribe or change your subscription options, visit:
39391 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
39394 >/******* - End Original Message - *******/
39398 >------------------------------------------------------------------
39399 >To unsubscribe or change your subscription options, visit:
39400 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
39402 _________________________________________________________________
39403 MSN 8: Get 6 months for $9.95/month. http://join.msn.com/?page=dept/dialup
39406 From simorgh at dataphone.se Sat Aug 30 08:27:11 2003
39407 From: simorgh at dataphone.se (Ali Simorgh)
39408 Date: Sat Oct 23 23:10:07 2004
39409 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
39410 In-Reply-To: <MKEGJINFADFODDNOKEJCMEEADPAA.rg@tcslon.com>
39411 Message-ID: <Pine.GSO.4.31.0308301716410.15629-100000@nikson.dataphone.se>
39414 I run ircservices 5.0.21 on FreeBSD 4.8-STABLE. and Ultimate 3.*
39415 I get this in logfile:
39417 [Aug 30 10:51:19 2003] unknown message from server
39418 (NETCTRL 0 0 0 0 0 0 0 0 0 0 0 0 0)
39419 [Aug 30 10:51:19 2003] user: New maximum user count: 1
39420 [Aug 30 10:51:19 2003] unknown message from server
39421 (:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
39422 [Aug 30 10:51:19 2003] user: New maximum user count: 2
39423 [Aug 30 10:51:19 2003] unknown message from server
39424 (:irc.MyNet.Net SETHOST pedarkhAnde 6b45bb2.26d9672f.dataphone.se)
39425 [Aug 30 10:56:18 2003] mail/sendmail:
39426 /usr/sbin/sendmail exited with code 25600
39427 [Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
39428 registration (Simorgh)
39430 and how can I do so that nickserv dont show the realhost of a user in
39437 ______________________________________________________
39438 Many of life's failures are people who did not realize
39439 how close they were to success when they gave up.
39441 ______________________________________________________
39446 From jskam at shaw.ca Sat Aug 30 11:34:35 2003
39447 From: jskam at shaw.ca (Jeffery Kam)
39448 Date: Sat Oct 23 23:10:07 2004
39449 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
39450 In-Reply-To: <Pine.GSO.4.31.0308301716410.15629-100000@nikson.dataphone.se>
39451 Message-ID: <000001c36f25$58464860$f64f9144@weed>
39453 "and how can I do so that nickserv dont show the realhost of a user in
39454 'ns info nick all'"
39456 This would be a great feature for sure. I know on my network, there is
39457 a custom user mode +d, which will disguise a user's host in a /whois
39458 reply, but services info doesn't show it disguised unless the HIDE
39463 From achurch at achurch.org Sat Aug 30 16:14:47 2003
39464 From: achurch at achurch.org (Andrew Church)
39465 Date: Sat Oct 23 23:10:07 2004
39466 Subject: [IRCServices Coding] MARK Command
39467 In-Reply-To: <3208.66.181.69.244.1060800845.squirrel@dreamchat.org>
39468 Message-ID: <3f512fdb.01666@achurch.org>
39470 Use E-mail if you need communication of that sort.
39473 achurch@achurch.org
39474 http://achurch.org/
39476 >First off, i would like to say that IRCservices are the best services out
39477 >there, by FAR! Anyways, i was wondering if the MARK command will be in
39478 >the next relase? Its kind of a pointless command, its only used to mark
39479 >nicks or channels, but it is very useful for when passwords to channels
39482 >/chanserv MARK <channel> <reason>
39484 >/chanserv info #channel would read the following.
39485 >*#channel has been MARKED by playa - <reason>
39487 >Of course only IRCops would be able to view it.
39489 >Just an idea i thought of :)
39494 >Network Founder/CEO
39495 >DreamChat IRC Network - irc.dreamchat.org
39496 >http://www.dreamchat.org
39498 >------------------------------------------------------------------
39499 >To unsubscribe or change your subscription options, visit:
39500 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
39502 From l8nite at l8nite.net Sat Aug 30 16:58:16 2003
39503 From: l8nite at l8nite.net (Shaun Guth)
39504 Date: Sat Oct 23 23:10:07 2004
39505 Subject: [IRCServices Coding] OP/Voice upon identify
39506 In-Reply-To: <3f513092.01677@achurch.org>
39507 References: <3f513092.01677@achurch.org>
39508 Message-ID: <1062287885.21924.6.camel@localhost>
39510 On Sun, 2003-08-31 at 01:16, Andrew Church wrote:
39511 > Needless complexity. If you don't want yourself autoopped, then don't
39512 > be an auto-op. It's that simple.
39514 I disagree. In my case, I wanted to create a channel where there were
39515 no ops so users don't have to endure lame op-wars, etc. However, I did
39516 need to maintain a level of control over the channel to protect from
39517 extremely obnoxious behavior or lame bots, etc. By registering as
39518 founder of the channel I induced the unwanted 'auto-op' behavior. My
39519 only solution was to register another fake user to become channel
39520 founder and set their nick to noexpire. That to me seems like needless
39521 complexity. A simple check to see if the user wishes to be opped or not
39527 From Craig at chatspike.net Sat Aug 30 17:07:32 2003
39528 From: Craig at chatspike.net (Craig McLure)
39529 Date: Sat Oct 23 23:10:07 2004
39530 Subject: [IRCServices Coding] OP/Voice upon identify
39531 Message-ID: <20030831000719.ELIJ19019.mta3-svc.business.ntl.com@i-br0ked-it>
39533 it would thou.. they would have to be able to switch off auto-op for a single channel..
39534 you could always use /cs levels to change the 'auto op' level up.. so that no one is auto-opped..
39536 or /cs levels #channels DISABLE autoop
39538 /****************************************
39539 * Craig "FrostyCoolSlug" McLure
39540 ************* - SpamBox - **************
39541 * InspIRCd - http://www.inspircd.org
39542 * ChatSpike - http://www.chatspike.net
39543 * WinBot - http://www.winbot.co.uk
39544 ****************************************/
39546 /****************************************
39547 * From - Shaun Guth <l8nite@l8nite.net>
39548 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
39549 * Sent - 2003-08-30 @ 16:58:00
39550 * Subject - RE: [IRCServices Coding] OP/Voice upon identify
39551 ****************************************/
39553 /****** - Begin Original Message - ******/
39555 >On Sun, 2003-08-31 at 01:16, Andrew Church wrote:
39556 >> Needless complexity. If you don't want yourself autoopped, then don't
39557 >> be an auto-op. It's that simple.
39559 >I disagree. In my case, I wanted to create a channel where there were
39560 >no ops so users don't have to endure lame op-wars, etc. However, I did
39561 >need to maintain a level of control over the channel to protect from
39562 >extremely obnoxious behavior or lame bots, etc. By registering as
39563 >founder of the channel I induced the unwanted 'auto-op' behavior. My
39564 >only solution was to register another fake user to become channel
39565 >founder and set their nick to noexpire. That to me seems like needless
39566 >complexity. A simple check to see if the user wishes to be opped or not
39571 >------------------------------------------------------------------
39572 >To unsubscribe or change your subscription options, visit:
39573 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
39576 /******* - End Original Message - *******/
39581 From l8nite at l8nite.net Sat Aug 30 17:14:44 2003
39582 From: l8nite at l8nite.net (Shaun Guth)
39583 Date: Sat Oct 23 23:10:07 2004
39584 Subject: [IRCServices Coding] OP/Voice upon identify
39585 In-Reply-To: <20030831000719.ELIJ19019.mta3-svc.business.ntl.com@i-br0ked-it>
39586 References: <20030831000719.ELIJ19019.mta3-svc.business.ntl.com@i-br0ked-it>
39587 Message-ID: <1062288881.21924.17.camel@localhost>
39589 On Sat, 2003-08-30 at 18:06, Craig McLure wrote:
39590 > it would thou.. they would have to be able to switch off auto-op for a single channel..
39592 For each channel we already store an access list, one extra bit to
39593 indicate auto-anything status or not is not really asking too much.
39595 > you could always use /cs levels to change the 'auto op' level up.. so that no one is auto-opped..
39596 > or /cs levels #channels DISABLE autoop
39598 -ChanServ- Channel #foobar registered under your nickname: l8
39599 -ChanServ- AUTOOP disabled on channel #foobar.
39600 --- You have left channel #foobar
39601 --> You are now talking on #foobar
39602 --- services.topgamers.net removes channel operator status from l8
39603 --- services.topgamers.net gives channel operator status to l8
39605 Same with ENFORCE set to off as well.
39607 > [snipped obnoxiously long sig]
39612 From achurch at achurch.org Sun Aug 31 02:58:23 2003
39613 From: achurch at achurch.org (Andrew Church)
39614 Date: Sat Oct 23 23:10:07 2004
39615 Subject: [IRCServices Coding] OP/Voice upon identify
39616 In-Reply-To: <1062288881.21924.17.camel@localhost>
39617 Message-ID: <3f51c6b5.07402@achurch.org>
39619 >> you could always use /cs levels to change the 'auto op' level up.. so that no one is auto-opped..
39620 >> or /cs levels #channels DISABLE autoop
39622 >-ChanServ- Channel #foobar registered under your nickname: l8
39623 >-ChanServ- AUTOOP disabled on channel #foobar.
39624 >--- You have left channel #foobar
39625 >--> You are now talking on #foobar
39626 >--- services.topgamers.net removes channel operator status from l8
39627 >--- services.topgamers.net gives channel operator status to l8
39629 This is definitely confusing behavior. Fixed for 5.0.22, thanks for
39630 the report. Note that you will also want to disable the other AUTOxxx
39631 levels as well if you don't want any automatic modes.
39634 achurch@achurch.org
39635 http://achurch.org/
39637 From achurch at achurch.org Sun Aug 31 07:28:11 2003
39638 From: achurch at achurch.org (Andrew Church)
39639 Date: Sat Oct 23 23:10:07 2004
39640 Subject: [IRCServices Coding] Mass memos
39641 In-Reply-To: <001601c361d8$a5312f00$6401a8c0@turby>
39642 Message-ID: <3f5205f0.15057@achurch.org>
39644 >Can we reconsider adding a Mass memo function for the next release?
39646 No, for all the reasons others have mentioned. I'll also draw an
39647 example from my experience with cellphone mail in Japan, which is
39648 remarkably similar to Services memos: Automated messages are annoying,
39649 period. The primary use for cellphone mail is to communicate with friends;
39650 having automatic messages interfere with that is annoying in the extreme.
39651 Yes, 10% or 20% of your users might be willing to accept mass memos, but
39652 the remaining 80% or 90% will get quite upset with you.
39654 I might also point out that people who care about what happens on the
39655 network will actively check that information, whether you make it available
39656 through logon news, through a website, or whatever; and people who don't
39657 care will ignore anything you send them. The method you use to inform them
39658 won't really make a difference.
39660 >If not, or even if so... one thing puzzles me: In the /ns list * command,
39661 >the listings have occasional punctuation... a ! or ? in front of the nick.
39662 >There is nothing in the docs anywhere that seems to address this, and I'm
39663 >curious as to what those mean.... an explanation would be helpful there too.
39665 This should be available through /ns help list, but there appears to
39666 be a bug there. I'll fix it for the next version.
39668 >on that note, a possible suggestion for Logonnews... How about something I
39669 >saw on Dalnet once: When new news is added, you get a notice. Until you
39670 >read the news, it keeps bugging you when you log on. After you read it, it
39671 >stops. Some sort of flag so users know when there IS new news would be
39672 >useful... the main reason nobody read the logonnews is that 90% of the time
39673 >for them, it is unchanged........
39675 This is an interesting thought; I'll think about it for a future
39679 achurch@achurch.org
39680 http://achurch.org/
39682 From achurch at achurch.org Sun Aug 31 07:42:30 2003
39683 From: achurch at achurch.org (Andrew Church)
39684 Date: Sat Oct 23 23:10:07 2004
39685 Subject: [IRCServices Coding] Language
39686 In-Reply-To: <MKEGJINFADFODDNOKEJCKEEDDPAA.rg@tcslon.com>
39687 Message-ID: <3f52094e.17046@achurch.org>
39689 [/msg nickserv vs. /nickserv]
39690 >I wonder if it would be worth integrating such a thing into services as an
39691 >option (compile-time maybe?). I think it would be good for the irc community
39692 >as a whole to get away from the habit of msging services directly if at all
39693 >possible. Opinions?
39695 /msg NickServ is the one format that's guaranteed to work on every
39696 ircd (except for administrative decisions a la DALnet). Get an RFC
39697 published--and implemented; 2811-3 were remarkable failures in that area--
39698 and I'll consider changing it.
39701 achurch@achurch.org
39702 http://achurch.org/
39704 From achurch at achurch.org Sun Aug 31 07:45:49 2003
39705 From: achurch at achurch.org (Andrew Church)
39706 Date: Sat Oct 23 23:10:07 2004
39707 Subject: [IRCServices Coding] Language
39708 In-Reply-To: <Pine.GSO.4.31.0308172127300.9882-100000@nikson.dataphone.se>
39709 Message-ID: <3f520a18.17063@achurch.org>
39711 >Is there any tool (silly question) or something or guid to make a language
39714 >I have decided to make a Persian (Farsi) language file.
39716 Language files are just plain text files; as another reply said, read
39717 the comments at the top of lang/en_us.l, and work from there. Be warned
39718 that the amount of text is huge; expect to spend at least two to three
39719 months on the initial translation.
39721 Also, if you'd be willing to continue maintaining the language file as
39722 it is updated in future versions, please let me know privately.
39725 achurch@achurch.org
39726 http://achurch.org/
39728 From achurch at achurch.org Sun Aug 31 07:53:21 2003
39729 From: achurch at achurch.org (Andrew Church)
39730 Date: Sat Oct 23 23:10:07 2004
39731 Subject: [IRCServices Coding] segfault on expiring ?
39732 In-Reply-To: <001201c36793$d26e4000$0101a8c0@nothing>
39733 Message-ID: <3f520bd8.17715@achurch.org>
39735 >[Aug 20 20:49:05 2003] nickserv/main: Expiring suspension for SeBa_KoBe (nick group 17805)
39736 >[Aug 20 20:49:05 2003] nickserv/main: Expiring nickname SeBa_KoBe
39737 >[Aug 20 20:49:05 2003] nickserv/main: [Aug 20 20:49:05 2003] Services terminating: Segmentation Faul
39739 I can't reproduce this problem. If this is still occurring, can you
39740 send me your databases privately so that I can investigate it?
39743 achurch@achurch.org
39744 http://achurch.org/
39746 From achurch at achurch.org Sun Aug 31 07:55:10 2003
39747 From: achurch at achurch.org (Andrew Church)
39748 Date: Sat Oct 23 23:10:07 2004
39749 Subject: [IRCServices Coding] BUG Report
39750 In-Reply-To: <001501c36daf$c8cba700$0101a8c0@house>
39751 Message-ID: <3f520c48.17731@achurch.org>
39753 >we suspended channel #kavala, and someone has identified itself has the =
39754 >founder and apply a DROP to the channel.
39755 >then we got a panic from the services and... crash.
39757 This is a bug in the DROP function, and has been fixed; thanks for the
39761 achurch@achurch.org
39762 http://achurch.org/
39764 From achurch at achurch.org Sun Aug 31 08:07:44 2003
39765 From: achurch at achurch.org (Andrew Church)
39766 Date: Sat Oct 23 23:10:07 2004
39767 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
39768 In-Reply-To: <Pine.GSO.4.31.0308301716410.15629-100000@nikson.dataphone.se>
39769 Message-ID: <3f520f38.21076@achurch.org>
39771 >[Aug 30 10:56:18 2003] mail/sendmail:
39772 > /usr/sbin/sendmail exited with code 25600
39774 Use the SMTP module instead (mail/smtp).
39776 >[Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
39777 >registration (Simorgh)
39779 >and how can I do so that nickserv dont show the realhost of a user in
39780 >'ns info nick all'
39782 It doesn't. However:
39784 >[Aug 30 10:51:19 2003] unknown message from server
39785 >(:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
39787 You're using the wrong protocol, since it doesn't recognize the
39788 SETHOST command and therefore has no idea about fake hosts. I might
39789 remind you that Ultimate 3.x is not supported.
39792 achurch@achurch.org
39793 http://achurch.org/
39795 From achurch at achurch.org Sun Aug 31 08:11:22 2003
39796 From: achurch at achurch.org (Andrew Church)
39797 Date: Sat Oct 23 23:10:07 2004
39798 Subject: [IRCServices Coding] Yet, another great suggestion
39799 In-Reply-To: <20030828183615.GB32204@phat.za.net>
39800 Message-ID: <3f52100e.21116@achurch.org>
39802 >Or how about rather letting users decide what timezone they're in and
39803 >services outputs all timestamps in their local time?
39805 /ns help set timezone (since 5.0 alpha)
39808 achurch@achurch.org
39809 http://achurch.org/
39811 From saturn at jetirc.net Sun Aug 31 12:28:59 2003
39812 From: saturn at jetirc.net (Saturn)
39813 Date: Sat Oct 23 23:10:07 2004
39814 Subject: [IRCServices Coding]
39815 Re: [IRCServices] Yet, another great suggestion
39816 References: <3f5202a3.15001@achurch.org>
39817 Message-ID: <003201c36ff6$25ae6550$6401a8c0@turby>
39819 I think it is... consider an international Network like mine: every server
39820 is in a different time zone -- How are users supposed to know what time zone
39821 the Services (pickign on Services' clock because Services are whats giving
39822 these notices!) is in?? Sure, they can do the /time command, if they even
39823 know abotu it. But the vast majority of IRC users are ignorant of those
39824 sorts of commands, or even if they know about /time, they most likely have
39825 no idea they can specify a server with the command.
39827 I realize that programmers for IRC-related software seem always to be of the
39828 universal opinion that ALL irc users should take the time to become elite
39829 experts abotu everything PC, however that is simply NOT reality. Services
39830 is specificly there to SERVE the users and the ircops. Its sole function is
39831 to police access and provide information to the users -- what use is it to
39832 say that a certain piece of information is "not useful" or "not needed" when
39833 you can plainly see that it is in this case, given the argument above?
39835 Obviously, it is your project, not mine, and I certainly cannot force you to
39836 do anythign you don't want to do, but I and my staff and users all agree it
39837 would be extremely useful... "Handy" was the word most used. I've had quite
39838 a few queries about it, and so I'm asking for it. If you don't feel that
39839 non-techie users deserve any consideration, then ignore the request. It's
39840 really up to you anyhow....
39845 ----- Original Message -----
39846 From: "Andrew Church" <achurch@achurch.org>
39847 To: <saturn@jetirc.net>
39848 Sent: Sunday, August 31, 2003 7:13 AM
39849 Subject: Re: [IRCServices] Yet, another great suggestion
39852 >So how do you get the current time from Services then? The actual time that
39853 >SERVICES thinks it is, not the server, and not my local clock...
39855 If there's any significant difference between your local clock, your
39856 IRC server's clock, and Services' clock, then at least one of them needs to
39857 be fixed. That's not Services' problem.
39860 achurch@achurch.org
39861 http://achurch.org/
39865 From aragon at phat.za.net Sun Aug 31 13:23:29 2003
39866 From: aragon at phat.za.net (Aragon Gouveia)
39867 Date: Sat Oct 23 23:10:07 2004
39868 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
39869 another great suggestion
39870 In-Reply-To: <003201c36ff6$25ae6550$6401a8c0@turby>
39871 References: <3f5202a3.15001@achurch.org> <003201c36ff6$25ae6550$6401a8c0@turby>
39872 Message-ID: <20030831202324.GB8731@phat.za.net>
39874 | By Saturn <saturn@jetirc.net>
39875 | [ 2003-08-31 21:29 +0200 ]
39876 > I think it is... consider an international Network like mine: every server
39877 > is in a different time zone -- How are users supposed to know what time zone
39878 > the Services (pickign on Services' clock because Services are whats giving
39879 > these notices!) is in?? Sure, they can do the /time command, if they even
39880 > know abotu it. But the vast majority of IRC users are ignorant of those
39881 > sorts of commands, or even if they know about /time, they most likely have
39882 > no idea they can specify a server with the command.
39884 Erm, what's the argument here? Services stipulates its timezone in its
39885 timestamps. As do all the other servers on the network.
39893 From saturn at jetirc.net Sun Aug 31 13:47:37 2003
39894 From: saturn at jetirc.net (Saturn)
39895 Date: Sat Oct 23 23:10:07 2004
39896 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
39897 another great suggestion
39898 References: <3f5202a3.15001@achurch.org> <003201c36ff6$25ae6550$6401a8c0@turby>
39899 <20030831202324.GB8731@phat.za.net>
39900 Message-ID: <000701c37001$10a62cf0$6401a8c0@turby>
39902 The argument is that the overwhelming majority of IRC users have no idea the
39903 /time command exists, and even fewer are aware that they can specify a
39904 server name after the /time command. How would these people find out the
39905 Services time zone? Why does it all have to be so complicated??
39907 ----- Original Message -----
39908 From: "Aragon Gouveia" <aragon@phat.za.net>
39909 To: <ircservices-coding@ircservices.za.net>
39910 Sent: Sunday, August 31, 2003 1:23 PM
39911 Subject: Re: [IRCServices Coding] Re: [IRCServices] Yet,another great
39915 | By Saturn <saturn@jetirc.net>
39916 | [ 2003-08-31 21:29 +0200 ]
39917 > I think it is... consider an international Network like mine: every
39919 > is in a different time zone -- How are users supposed to know what time
39921 > the Services (pickign on Services' clock because Services are whats giving
39922 > these notices!) is in?? Sure, they can do the /time command, if they even
39923 > know abotu it. But the vast majority of IRC users are ignorant of those
39924 > sorts of commands, or even if they know about /time, they most likely have
39925 > no idea they can specify a server with the command.
39927 Erm, what's the argument here? Services stipulates its timezone in its
39928 timestamps. As do all the other servers on the network.
39935 ------------------------------------------------------------------
39936 To unsubscribe or change your subscription options, visit:
39937 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
39941 From quension at mac.com Sun Aug 31 14:11:28 2003
39942 From: quension at mac.com (Trevor Talbot)
39943 Date: Sat Oct 23 23:10:07 2004
39944 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
39945 another great suggestion
39946 In-Reply-To: <000701c37001$10a62cf0$6401a8c0@turby>
39947 Message-ID: <962546B6-DBF7-11D7-8505-0003938D6866@mac.com>
39949 On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
39951 > The argument is that the overwhelming majority of IRC users have no
39952 > idea the /time command exists, and even fewer are aware that they can
39953 > specify a server name after the /time command. How would these people
39954 > find out the Services time zone?
39956 You missed the point. Services shows the time zone wherever it uses a
39957 readable time -- i.e. in the nickserv/chanserv info displays. Unless
39958 you've changed your language file, in which case you can simply change
39961 > Why does it all have to be so complicated??
39963 It isn't. Your users can even use the handy-dandy /nickserv set
39964 timezone command to make it even easier.
39966 > ----- Original Message -----
39967 > From: "Aragon Gouveia" <aragon@phat.za.net>
39969 > | By Saturn <saturn@jetirc.net>
39970 > | [ 2003-08-31 21:29 +0200 ]
39971 >> I think it is... consider an international Network like mine: every
39972 >> server is in a different time zone -- How are users supposed to know
39973 >> what time zone the Services (pickign on Services' clock because
39974 >> Services are whats giving these notices!) is in?? Sure, they can do
39975 >> the /time command, if they even know abotu it. But the vast majority
39976 >> of IRC users are ignorant of those sorts of commands, or even if they
39977 >> know about /time, they most likely have no idea they can specify a
39978 >> server with the command.
39980 > Erm, what's the argument here? Services stipulates its timezone in
39981 > its timestamps. As do all the other servers on the network.
39986 From us44ever at hotmail.com Sun Aug 31 14:40:48 2003
39987 From: us44ever at hotmail.com (us44ever .)
39988 Date: Sat Oct 23 23:10:07 2004
39989 Subject: [IRCServices Coding]
39990 Re: [IRCServices] Yet, another great suggestion
39991 Message-ID: <Sea1-F8siZAPG4vEjaG0000fb20@hotmail.com>
39994 or even the idea of adding an additional info (exact info) something like:
39995 Last seen time : Aug 22 14:20:16 2003 GMT (9 days, 51 minutes and 21
39997 Time registered : Jul 25 22:19:20 2003 GMT (** days, ** minutes and **
39999 wouldn't even a greater idea?
40001 _________________________________________________________________
40002 Get MSN 8 and enjoy automatic e-mail virus protection.
40003 http://join.msn.com/?page=features/virus
40006 From saturn at jetirc.net Sun Aug 31 16:49:07 2003
40007 From: saturn at jetirc.net (Saturn)
40008 Date: Sat Oct 23 23:10:07 2004
40009 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
40010 another great suggestion
40011 References: <962546B6-DBF7-11D7-8505-0003938D6866@mac.com>
40012 Message-ID: <000e01c3701a$48faea50$6401a8c0@turby>
40014 [16:41] -NickServ- Time registered: Jul 27 13:09:08 2002 PDT
40016 That's what I see when I use it. Yes, it does say "PDT" .. how many people
40017 in, say Belgium, are going to know exactly what PDT is? How about "PDT
40018 (GMT-8)" as the format....? Also, you'll note that it STILL gives no
40019 indication as to the CURRENT time ... this is why the proper UTC code or
40020 GMT+/-## is the best way to go IMHO. I do also like the idea suggested by
40021 us44ever ... the "(** days, ** minutes, and ** seconds ago)" idea... that
40022 would be handy in any event.... and would eliminate the need for the current
40023 time to be displayed....
40025 On another note, I had forgotten the set timezone option, which certainly
40026 would put more clarity on the output... however, I think my points above are
40029 Unless of course I've missed a config setting that will tell it to report
40030 the tiome zone as a function of GMT (plus or minus x hours, rather than zone
40033 ----- Original Message -----
40034 From: "Trevor Talbot" <quension@mac.com>
40035 To: "IRC Services Coding Mailing List"
40036 <ircservices-coding@ircservices.za.net>
40037 Sent: Sunday, August 31, 2003 2:10 PM
40038 Subject: Re: [IRCServices Coding] Re: [IRCServices] Yet,another great
40042 On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
40044 > The argument is that the overwhelming majority of IRC users have no
40045 > idea the /time command exists, and even fewer are aware that they can
40046 > specify a server name after the /time command. How would these people
40047 > find out the Services time zone?
40049 You missed the point. Services shows the time zone wherever it uses a
40050 readable time -- i.e. in the nickserv/chanserv info displays. Unless
40051 you've changed your language file, in which case you can simply change
40054 > Why does it all have to be so complicated??
40056 It isn't. Your users can even use the handy-dandy /nickserv set
40057 timezone command to make it even easier.
40059 > ----- Original Message -----
40060 > From: "Aragon Gouveia" <aragon@phat.za.net>
40062 > | By Saturn <saturn@jetirc.net>
40063 > | [ 2003-08-31 21:29 +0200 ]
40064 >> I think it is... consider an international Network like mine: every
40065 >> server is in a different time zone -- How are users supposed to know
40066 >> what time zone the Services (pickign on Services' clock because
40067 >> Services are whats giving these notices!) is in?? Sure, they can do
40068 >> the /time command, if they even know abotu it. But the vast majority
40069 >> of IRC users are ignorant of those sorts of commands, or even if they
40070 >> know about /time, they most likely have no idea they can specify a
40071 >> server with the command.
40073 > Erm, what's the argument here? Services stipulates its timezone in
40074 > its timestamps. As do all the other servers on the network.
40078 ------------------------------------------------------------------
40079 To unsubscribe or change your subscription options, visit:
40080 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
40084 From quension at mac.com Sun Aug 31 18:25:05 2003
40085 From: quension at mac.com (Trevor Talbot)
40086 Date: Sat Oct 23 23:10:07 2004
40087 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
40088 another great suggestion
40089 In-Reply-To: <000e01c3701a$48faea50$6401a8c0@turby>
40090 Message-ID: <14C7EDD0-DC1B-11D7-8505-0003938D6866@mac.com>
40092 On Sunday, Aug 31, 2003, at 16:47 US/Pacific, Saturn wrote:
40094 > Unless of course I've missed a config setting that will tell it to
40095 > report the tiome zone as a function of GMT (plus or minus x hours,
40096 > rather than zone codes like PDT)...
40098 You could modify the language file, using something like "(GMT%z)"
40099 instead of %Z in the STRFTIME_DATE_TIME_FORMAT string. "man 3
40100 strftime" for the available options.
40105 From achurch at achurch.org Sun Aug 31 19:00:00 2003
40106 From: achurch at achurch.org (Andrew Church)
40107 Date: Sat Oct 23 23:10:07 2004
40108 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
40109 another great suggestion
40110 In-Reply-To: <000e01c3701a$48faea50$6401a8c0@turby>
40111 Message-ID: <3f52a815.21363@achurch.org>
40113 "Use /ns set timezone" is the official answer on this. Please take
40114 all further discussion to the ircservices list.
40117 achurch@achurch.org
40118 http://achurch.org/
40120 >[16:41] -NickServ- Time registered: Jul 27 13:09:08 2002 PDT
40122 >That's what I see when I use it. Yes, it does say "PDT" .. how many people
40123 >in, say Belgium, are going to know exactly what PDT is? How about "PDT
40124 >(GMT-8)" as the format....? Also, you'll note that it STILL gives no
40125 >indication as to the CURRENT time ... this is why the proper UTC code or
40126 >GMT+/-## is the best way to go IMHO. I do also like the idea suggested by
40127 >us44ever ... the "(** days, ** minutes, and ** seconds ago)" idea... that
40128 >would be handy in any event.... and would eliminate the need for the current
40129 >time to be displayed....
40131 >On another note, I had forgotten the set timezone option, which certainly
40132 >would put more clarity on the output... however, I think my points above are
40135 >Unless of course I've missed a config setting that will tell it to report
40136 >the tiome zone as a function of GMT (plus or minus x hours, rather than zone
40137 >codes like PDT)...
40139 >----- Original Message -----
40140 >From: "Trevor Talbot" <quension@mac.com>
40141 >To: "IRC Services Coding Mailing List"
40142 ><ircservices-coding@ircservices.za.net>
40143 >Sent: Sunday, August 31, 2003 2:10 PM
40144 >Subject: Re: [IRCServices Coding] Re: [IRCServices] Yet,another great
40148 >On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
40150 >> The argument is that the overwhelming majority of IRC users have no
40151 >> idea the /time command exists, and even fewer are aware that they can
40152 >> specify a server name after the /time command. How would these people
40153 >> find out the Services time zone?
40155 >You missed the point. Services shows the time zone wherever it uses a
40156 >readable time -- i.e. in the nickserv/chanserv info displays. Unless
40157 >you've changed your language file, in which case you can simply change
40160 >> Why does it all have to be so complicated??
40162 >It isn't. Your users can even use the handy-dandy /nickserv set
40163 >timezone command to make it even easier.
40165 >> ----- Original Message -----
40166 >> From: "Aragon Gouveia" <aragon@phat.za.net>
40168 >> | By Saturn <saturn@jetirc.net>
40169 >> | [ 2003-08-31 21:29 +0200 ]
40170 >>> I think it is... consider an international Network like mine: every
40171 >>> server is in a different time zone -- How are users supposed to know
40172 >>> what time zone the Services (pickign on Services' clock because
40173 >>> Services are whats giving these notices!) is in?? Sure, they can do
40174 >>> the /time command, if they even know abotu it. But the vast majority
40175 >>> of IRC users are ignorant of those sorts of commands, or even if they
40176 >>> know about /time, they most likely have no idea they can specify a
40177 >>> server with the command.
40179 >> Erm, what's the argument here? Services stipulates its timezone in
40180 >> its timestamps. As do all the other servers on the network.
40184 >------------------------------------------------------------------
40185 >To unsubscribe or change your subscription options, visit:
40186 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
40189 >------------------------------------------------------------------
40190 >To unsubscribe or change your subscription options, visit:
40191 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
40193 From simorgh at dataphone.se Sun Aug 31 22:34:32 2003
40194 From: simorgh at dataphone.se (Ali Simorgh)
40195 Date: Sat Oct 23 23:10:07 2004
40196 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
40197 In-Reply-To: <3f520f38.21076@achurch.org>
40198 Message-ID: <Pine.GSO.4.31.0309010728040.7173-100000@nikson.dataphone.se>
40200 Thanks for your help.
40202 I thought if I set nickserv to not be an ircop, then it maybe dosent se
40203 the real host name, and maybe shows the crypted hostname to other users
40204 or should I change this line in language files:
40205 NICK_INFO_ADDRESS_ONLINE
40208 NICK_INFO_ADDRESS_ONLINE
40209 Is online from: N/A ?
40213 ______________________________________________________
40214 Many of life's failures are people who did not realize
40215 how close they were to success when they gave up.
40217 ______________________________________________________
40220 On Mon, 1 Sep 2003, Andrew Church wrote:
40222 > >[Aug 30 10:56:18 2003] mail/sendmail:
40223 > > /usr/sbin/sendmail exited with code 25600
40225 > Use the SMTP module instead (mail/smtp).
40227 > >[Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
40228 > >registration (Simorgh)
40230 > >and how can I do so that nickserv dont show the realhost of a user in
40231 > >'ns info nick all'
40233 > It doesn't. However:
40235 > >[Aug 30 10:51:19 2003] unknown message from server
40236 > >(:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
40238 > You're using the wrong protocol, since it doesn't recognize the
40239 > SETHOST command and therefore has no idea about fake hosts. I might
40240 > remind you that Ultimate 3.x is not supported.
40243 > achurch@achurch.org
40244 > http://achurch.org/
40245 > ------------------------------------------------------------------
40246 > To unsubscribe or change your subscription options, visit:
40247 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
40251 From achurch at achurch.org Sun Aug 31 23:24:09 2003
40252 From: achurch at achurch.org (Andrew Church)
40253 Date: Sat Oct 23 23:10:07 2004
40254 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
40255 In-Reply-To: <Pine.GSO.4.31.0309010728040.7173-100000@nikson.dataphone.se>
40256 Message-ID: <3f52e5fe.41203@achurch.org>
40258 >I thought if I set nickserv to not be an ircop, then it maybe dosent se
40259 >the real host name, and maybe shows the crypted hostname to other users
40261 It isn't a matter of NickServ having operator privileges or not;
40262 Services, as a server, always sees the real hostname. The problem is that
40263 Services and your IRC server aren't using the same protocol, so Services
40264 can't recognize the fake hosts. Try using a different IRC server.
40267 achurch@achurch.org
40268 http://achurch.org/
40270 From laser at musichat.net Wed Sep 3 06:49:40 2003
40271 From: laser at musichat.net (Alessandro Ciappei)
40272 Date: Sat Oct 23 23:10:07 2004
40273 Subject: [IRCServices Coding] New Features
40274 Message-ID: <001b01c37222$428f54d0$e2c0fea9@alexxa3il9cxpx>
40278 I have an idea for next release.
40279 A secure link between services and ircd.
40280 Now many ircd, like Unreal, tr-ircd, bahamut supports a ssl link.
40285 -------------- next part --------------
40286 An HTML attachment was scrubbed...
40287 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030903/a25ee68d/attachment-0003.html
40288 From r-krisztian at softhome.net Wed Sep 3 07:16:45 2003
40289 From: r-krisztian at softhome.net (Krisztian Romek)
40290 Date: Sat Oct 23 23:10:07 2004
40291 Subject: [IRCServices Coding] New Features
40292 In-Reply-To: <001b01c37222$428f54d0$e2c0fea9@alexxa3il9cxpx>
40293 References: <001b01c37222$428f54d0$e2c0fea9@alexxa3il9cxpx>
40294 Message-ID: <200309031617.38876.r-krisztian@softhome.net>
40299 > I have an idea for next release.
40300 > A secure link between services and ircd.
40301 > Now many ircd, like Unreal, tr-ircd, bahamut supports a ssl link.
40303 I think a ZIP link support (like in Unreal) should also be fine. :-) I don't
40304 know what you will reply for these feature requests, but I agree that they
40305 aren't so important, since in most cases ircd and services run on the same
40310 r-krisztian@softhome.net
40313 From Craig at chatspike.net Wed Sep 3 13:35:04 2003
40314 From: Craig at chatspike.net (Craig McLure)
40315 Date: Sat Oct 23 23:10:07 2004
40316 Subject: [IRCServices Coding] New Features
40317 Message-ID: <20030903203453.ITMO19019.mta3-svc.business.ntl.com@i-br0ked-it>
40319 If you read the archive, you will find that this has already been discussed (fairly recently if i recall..), and was thrown out, if you want services SSL support, i recommend you use a SSL tunnel.
40321 When it comes to ZIP links, this would require editing the services protocol module accordingly.. and IMO, shouldnt been needed, as in most cases, services run on the same box as a server.
40323 /****************************************
40324 * Craig "FrostyCoolSlug" McLure
40325 ************* - SpamBox - **************
40326 * InspIRCd - http://www.inspircd.org
40327 * ChatSpike - http://www.chatspike.net
40328 * WinBot - http://www.winbot.co.uk
40329 ****************************************/
40331 /****************************************
40332 * From - Alessandro Ciappei <laser@musichat.net>
40333 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
40334 * Sent - 2003-09-03 @ 15:49:00
40335 * Subject - [IRCServices Coding] New Features
40336 ****************************************/
40338 /****** - Begin Original Message - ******/
40342 >I have an idea for next release.
40343 >A secure link between services and ircd.
40344 >Now many ircd, like Unreal, tr-ircd, bahamut supports a ssl link.
40349 >------------------------------------------------------------------
40350 >To unsubscribe or change your subscription options, visit:
40351 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
40353 /******* - End Original Message - *******/
40358 From ircserv at elric.net Wed Sep 3 20:49:47 2003
40359 From: ircserv at elric.net (Brent DiNicola)
40360 Date: Sat Oct 23 23:10:07 2004
40361 Subject: [IRCServices Coding] Which route to take - Module?
40362 Message-ID: <5.2.1.1.0.20030903223929.016e4648@mail.elric.net>
40364 It wasn't an easy subject to sum up in just a few words.
40366 I am wanting to do something to the ircservices code, I want to change
40367 the way the notice() works. I know that modifying the send.c would be
40368 very frowned upon and then I got to thinking and had suggested that I
40369 maybe make a module to keep the information for me. I know it's against
40370 the RFC, but I am pressed against a brick wall here, I have to give the users
40371 an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
40372 I would like to give them the option of turning on PRIVMSG but have NOTICE
40373 be the default, that would get the lazy people to use NOTICE. Eventually
40374 getting rid of this problem. In the mean time, I was thinking what is the best
40375 way to go about this without causing trouble for me and anyone else who has
40376 to deal with this code. Is it possible or even suggested to make a module that
40377 would replace the notice() from send.c with it's own, leaving the code in
40379 alone and not causing troubles down the road. Suggestions were that I make a
40380 module that kept the info for each nick's setting and then if I could override
40381 the notice() and notice_lang() and notice_help() in send.c that would keep
40383 other code clean and not cause other troubles. I want to know what the best
40384 way to do this would be, I know it's against RFC but I want to move to newer
40385 services than the 1.4.3pre4 that we are using now and add modules so that I
40386 can do things down the line. They are used to having PRIVMSG and I can't just
40387 change it without running people off, so if I can make PRIVMSG an option
40388 then I can't be blamed if they are lazy. Opinions on how to go about this? I
40389 know this topic has been asked before and I know your not going to make it
40390 part of your code, I just wanted to know from the people who know the code
40391 really well what the best route to take would be to do the least amount of
40392 damage. (And if someone has done this.. please let me know what you did,
40393 examples would rock)
40401 ----------------------------------------------------------
40403 | The Whitewolf of Immyrr |
40404 | <elric@elric.net> |
40405 | http://www.melnibone.net |
40406 | Disclaimer: Any opinions expressed here are |
40407 | from my dog. Any liabilities fall to the dog. |
40408 -----------------------------------------------------------
40411 From Craig at chatspike.net Wed Sep 3 21:18:29 2003
40412 From: Craig at chatspike.net (Craig McLure)
40413 Date: Sat Oct 23 23:10:07 2004
40414 Subject: [IRCServices Coding] Which route to take - Module?
40415 Message-ID: <20030904041818.TXAK19019.mta3-svc.business.ntl.com@i-br0ked-it>
40417 lol, Our help no good? :P
40419 i still say module with seperate database (with the nickgroup, and if this option is on or off (This saves having to modify the main nick.db) , somehow extending the /ns SET command to include a new option.. and replacing what ever function sends notices with something that uses an if to query your new database..
40421 Dont ask me for source on this.. i'm just theorising :)
40423 /****************************************
40424 * Craig "FrostyCoolSlug" McLure
40425 ************* - SpamBox - **************
40426 * InspIRCd - http://www.inspircd.org
40427 * ChatSpike - http://www.chatspike.net
40428 * WinBot - http://www.winbot.co.uk
40429 ****************************************/
40431 /****************************************
40432 * From - Brent DiNicola <ircserv@elric.net>
40433 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
40434 * Sent - 2003-09-03 @ 22:49:00
40435 * Subject - [IRCServices Coding] Which route to take - Module?
40436 ****************************************/
40438 /****** - Begin Original Message - ******/
40440 >It wasn't an easy subject to sum up in just a few words.
40442 >I am wanting to do something to the ircservices code, I want to change
40443 >the way the notice() works. I know that modifying the send.c would be
40444 >very frowned upon and then I got to thinking and had suggested that I
40445 >maybe make a module to keep the information for me. I know it's against
40446 >the RFC, but I am pressed against a brick wall here, I have to give the users
40447 >an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
40448 >I would like to give them the option of turning on PRIVMSG but have NOTICE
40449 >be the default, that would get the lazy people to use NOTICE. Eventually
40450 >getting rid of this problem. In the mean time, I was thinking what is the best
40451 >way to go about this without causing trouble for me and anyone else who has
40452 >to deal with this code. Is it possible or even suggested to make a module that
40453 >would replace the notice() from send.c with it's own, leaving the code in
40455 >alone and not causing troubles down the road. Suggestions were that I make a
40456 >module that kept the info for each nick's setting and then if I could override
40457 >the notice() and notice_lang() and notice_help() in send.c that would keep
40459 >other code clean and not cause other troubles. I want to know what the best
40460 >way to do this would be, I know it's against RFC but I want to move to newer
40461 >services than the 1.4.3pre4 that we are using now and add modules so that I
40462 >can do things down the line. They are used to having PRIVMSG and I can't just
40463 >change it without running people off, so if I can make PRIVMSG an option
40464 >then I can't be blamed if they are lazy. Opinions on how to go about this? I
40465 >know this topic has been asked before and I know your not going to make it
40466 >part of your code, I just wanted to know from the people who know the code
40467 >really well what the best route to take would be to do the least amount of
40468 >damage. (And if someone has done this.. please let me know what you did,
40469 >examples would rock)
40477 >----------------------------------------------------------
40478 >| Brent DiNicola |
40479 >| The Whitewolf of Immyrr |
40480 >| <elric@elric.net> |
40481 >| http://www.melnibone.net |
40482 >| Disclaimer: Any opinions expressed here are |
40483 >| from my dog. Any liabilities fall to the dog. |
40484 >-----------------------------------------------------------
40486 >------------------------------------------------------------------
40487 >To unsubscribe or change your subscription options, visit:
40488 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
40491 /******* - End Original Message - *******/
40496 From uhc0 at rz.uni-karlsruhe.de Thu Sep 4 01:34:06 2003
40497 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu)
40498 Date: Sat Oct 23 23:10:07 2004
40499 Subject: [IRCServices Coding] Which route to take - Module?
40500 In-Reply-To: <5.2.1.1.0.20030903223929.016e4648@mail.elric.net>
40501 References: <5.2.1.1.0.20030903223929.016e4648@mail.elric.net>
40502 Message-ID: <1062664383.1917.15.camel@dreadnought.hadiko.de>
40506 Long question; long answer.
40507 First of all, you must come off the thoughts of "Against the RFC".
40508 Why? Because, tons of irc servers available do provide techniques, which
40509 do not appear, or appear differently on the irc RFC, so that by design
40510 these ircds are also against it. In most of the cases, these changes
40511 reflect themselves in their appropriate server-to-server protocols, and
40512 become transient to the clients, so that on client side, the protocol
40513 remains original. This is also the only way of ensuring that all of the
40514 clients can work with a specific irc daemon.
40516 The issue, why PRIVMSG instead of NOTICE is bad, does also result from
40517 the client-to-server part of the RFC. And it has a reason. Consider two
40518 automated clients (bots, services, etc) talking to each other with
40519 PRIVMSG, and saying things like:
40520 <NickServ> otherwise, I change your nick.
40521 <MyBot> Unknown command otherwise. Please repeat your query.
40522 <NickServ> Unknown command UNKNOWN.
40523 <MyBot> Unknown command unknown. Please repeat your query.
40524 <NickServ> Unknown command UNKNOWN.
40525 <MyBot> Unknown command unknown. Please repeat your query.
40526 <NickServ> Unknown command UNKNOWN.
40527 <MyBot> Unknown command unknown. Please repeat your query.
40528 <NickServ> Unknown command UNKNOWN.
40529 <MyBot> Unknown command unknown. Please repeat your query.
40532 Do you understand, what problem may conclude due to PRIVMSG? RFC says
40533 clearly, that clients shall not generate automatic replies to NOTICES.
40534 That way, your bot would not "talk" to NickServ after a NOTICE anymore.
40537 The most easy implementation of this is creating a NF_USE_PRIVMSG flag,
40538 with a value far greater than any of the built-in, so that in future
40539 this flag does not collide with any of the original flags.
40541 Then you create the new SET command for this, as well as its help text,
40542 primarily in the english language file. That part of the work is
40545 Afterwards, you should modify notice_lang, and check for the
40546 NF_USE_PRIVMSG flag of the "ngi" being used; and if true, send PRIVMSG
40547 instead. The same for notice_help. And your case could be marked as
40550 Do keep in mind that requesting support for modified services versions
40551 are subject to be ignored.
40556 On Thu, 2003-09-04 at 05:49, Brent DiNicola wrote:
40557 > It wasn't an easy subject to sum up in just a few words.
40559 > I am wanting to do something to the ircservices code, I want to change
40560 > the way the notice() works. I know that modifying the send.c would be
40561 > very frowned upon and then I got to thinking and had suggested that I
40562 > maybe make a module to keep the information for me. I know it's against
40563 > the RFC, but I am pressed against a brick wall here, I have to give the users
40564 > an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
40565 > I would like to give them the option of turning on PRIVMSG but have NOTICE
40566 > be the default, that would get the lazy people to use NOTICE. Eventually
40567 > getting rid of this problem. In the mean time, I was thinking what is the best
40568 > way to go about this without causing trouble for me and anyone else who has
40569 > to deal with this code. Is it possible or even suggested to make a module that
40570 > would replace the notice() from send.c with it's own, leaving the code in
40572 > alone and not causing troubles down the road. Suggestions were that I make a
40573 > module that kept the info for each nick's setting and then if I could override
40574 > the notice() and notice_lang() and notice_help() in send.c that would keep
40576 > other code clean and not cause other troubles. I want to know what the best
40577 > way to do this would be, I know it's against RFC but I want to move to newer
40578 > services than the 1.4.3pre4 that we are using now and add modules so that I
40579 > can do things down the line. They are used to having PRIVMSG and I can't just
40580 > change it without running people off, so if I can make PRIVMSG an option
40581 > then I can't be blamed if they are lazy. Opinions on how to go about this? I
40582 > know this topic has been asked before and I know your not going to make it
40583 > part of your code, I just wanted to know from the people who know the code
40584 > really well what the best route to take would be to do the least amount of
40585 > damage. (And if someone has done this.. please let me know what you did,
40586 > examples would rock)
40594 > ----------------------------------------------------------
40595 > | Brent DiNicola |
40596 > | The Whitewolf of Immyrr |
40597 > | <elric@elric.net> |
40598 > | http://www.melnibone.net |
40599 > | Disclaimer: Any opinions expressed here are |
40600 > | from my dog. Any liabilities fall to the dog. |
40601 > -----------------------------------------------------------
40603 > ------------------------------------------------------------------
40604 > To unsubscribe or change your subscription options, visit:
40605 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
40607 ------------------------------------------------------------------
40608 | Yusuf Iskenderoglu | You get to meet all sorts, |
40609 | eMail - uhc0@stud.uni-karlsruhe.de| in this line of work... |
40610 | eMail - s_iskend@ira.uka.de | |
40611 | ICQ UIN : 20587464 \ TimeMr14C | |
40612 ------------------------------------------------------------------
40615 From griever at t2n.org Thu Sep 4 13:31:44 2003
40616 From: griever at t2n.org (Robert F Merrill)
40617 Date: Sat Oct 23 23:10:07 2004
40618 Subject: [IRCServices Coding] Which route to take - Module?
40619 References: <5.2.1.1.0.20030903223929.016e4648@mail.elric.net>
40620 Message-ID: <3F57A0BA.9080909@t2n.org>
40622 Brent DiNicola wrote:
40624 > It wasn't an easy subject to sum up in just a few words.
40626 > I am wanting to do something to the ircservices code, I want to change
40627 > the way the notice() works. I know that modifying the send.c would be
40628 > very frowned upon and then I got to thinking and had suggested that I
40629 > maybe make a module to keep the information for me. I know it's against
40630 > the RFC, but I am pressed against a brick wall here, I have to give
40632 > an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
40633 > I would like to give them the option of turning on PRIVMSG but have
40635 > be the default, that would get the lazy people to use NOTICE. Eventually
40636 > getting rid of this problem. In the mean time, I was thinking what is
40638 > way to go about this without causing trouble for me and anyone else
40640 > to deal with this code. Is it possible or even suggested to make a
40642 > would replace the notice() from send.c with it's own, leaving the code
40644 > alone and not causing troubles down the road. Suggestions were that I
40646 > module that kept the info for each nick's setting and then if I could
40648 > the notice() and notice_lang() and notice_help() in send.c that would
40650 > other code clean and not cause other troubles. I want to know what the
40652 > way to do this would be, I know it's against RFC but I want to move to
40654 > services than the 1.4.3pre4 that we are using now and add modules so
40656 > can do things down the line. They are used to having PRIVMSG and I
40658 > change it without running people off, so if I can make PRIVMSG an option
40659 > then I can't be blamed if they are lazy. Opinions on how to go about
40661 > know this topic has been asked before and I know your not going to
40663 > part of your code, I just wanted to know from the people who know the
40665 > really well what the best route to take would be to do the least
40667 > damage. (And if someone has done this.. please let me know what you did,
40668 > examples would rock)
40676 > ----------------------------------------------------------
40677 > | Brent DiNicola |
40678 > | The Whitewolf of Immyrr |
40679 > | <elric@elric.net> |
40680 > | http://www.melnibone.net |
40681 > | Disclaimer: Any opinions expressed here are |
40682 > | from my dog. Any liabilities fall to the dog. |
40683 > -----------------------------------------------------------
40684 > ------------------------------------------------------------------
40685 > To unsubscribe or change your subscription options, visit:
40686 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
40690 Services is not the place to fix broken clients, and any client which
40691 doesn't display notices correctly is broken. If someone wants to see
40692 notices differently, they can either
40693 a) change their client or in the case of webtv b) change the ircd
40695 services is the wrong thing to change
40698 From Craig at chatspike.net Thu Sep 4 13:52:48 2003
40699 From: Craig at chatspike.net (Craig McLure)
40700 Date: Sat Oct 23 23:10:08 2004
40701 Subject: [IRCServices Coding] Which route to take - Module?
40702 Message-ID: <20030904205232.SDRM23096.mta6-svc.business.ntl.com@i-br0ked-it>
40704 dont mean to sound rude, but this isnt a 'moral' discussion, as it were, rather than saying 'I dont think this needs done', i think it would be best to help him.. its not a discussion on if its right or wrong, its a 'How to do it' discussion.. If you cant contribute to this.. please ignore this 'thread' :p
40706 /****************************************
40707 * Craig "FrostyCoolSlug" McLure
40708 ************* - SpamBox - **************
40709 * InspIRCd - http://www.inspircd.org
40710 * ChatSpike - http://www.chatspike.net
40711 * WinBot - http://www.winbot.co.uk
40712 ****************************************/
40714 /****************************************
40715 * From - Robert F Merrill <griever@t2n.org>
40716 * To - IRC Services Coding Mailing List <ircservices-coding@ircservices.za.net>
40717 * Sent - 2003-09-04 @ 16:29:00
40718 * Subject - Re: [IRCServices Coding] Which route to take - Module?
40719 ****************************************/
40721 /****** - Begin Original Message - ******/
40723 >Brent DiNicola wrote:
40725 >> It wasn't an easy subject to sum up in just a few words.
40727 >> I am wanting to do something to the ircservices code, I want to change
40728 >> the way the notice() works. I know that modifying the send.c would be
40729 >> very frowned upon and then I got to thinking and had suggested that I
40730 >> maybe make a module to keep the information for me. I know it's against
40731 >> the RFC, but I am pressed against a brick wall here, I have to give
40733 >> an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
40734 >> I would like to give them the option of turning on PRIVMSG but have
40736 >> be the default, that would get the lazy people to use NOTICE. Eventually
40737 >> getting rid of this problem. In the mean time, I was thinking what is
40739 >> way to go about this without causing trouble for me and anyone else
40741 >> to deal with this code. Is it possible or even suggested to make a
40743 >> would replace the notice() from send.c with it's own, leaving the code
40745 >> alone and not causing troubles down the road. Suggestions were that I
40747 >> module that kept the info for each nick's setting and then if I could
40749 >> the notice() and notice_lang() and notice_help() in send.c that would
40751 >> other code clean and not cause other troubles. I want to know what the
40753 >> way to do this would be, I know it's against RFC but I want to move to
40755 >> services than the 1.4.3pre4 that we are using now and add modules so
40757 >> can do things down the line. They are used to having PRIVMSG and I
40759 >> change it without running people off, so if I can make PRIVMSG an option
40760 >> then I can't be blamed if they are lazy. Opinions on how to go about
40762 >> know this topic has been asked before and I know your not going to
40764 >> part of your code, I just wanted to know from the people who know the
40766 >> really well what the best route to take would be to do the least
40768 >> damage. (And if someone has done this.. please let me know what you did,
40769 >> examples would rock)
40777 >> ----------------------------------------------------------
40778 >> | Brent DiNicola |
40779 >> | The Whitewolf of Immyrr |
40780 >> | <elric@elric.net> |
40781 >> | http://www.melnibone.net |
40782 >> | Disclaimer: Any opinions expressed here are |
40783 >> | from my dog. Any liabilities fall to the dog. |
40784 >> -----------------------------------------------------------
40785 >> ------------------------------------------------------------------
40786 >> To unsubscribe or change your subscription options, visit:
40787 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
40791 >Services is not the place to fix broken clients, and any client which
40792 >doesn't display notices correctly is broken. If someone wants to see
40793 >notices differently, they can either
40794 >a) change their client or in the case of webtv b) change the ircd
40796 >services is the wrong thing to change
40798 >------------------------------------------------------------------
40799 >To unsubscribe or change your subscription options, visit:
40800 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
40803 /******* - End Original Message - *******/
40808 From quension at mac.com Thu Sep 4 13:54:21 2003
40809 From: quension at mac.com (Trevor Talbot)
40810 Date: Sat Oct 23 23:10:08 2004
40811 Subject: [IRCServices Coding] Which route to take - Module?
40812 In-Reply-To: <3F57A0BA.9080909@t2n.org>
40813 Message-ID: <E8AC4DDC-DF19-11D7-905C-0003938D6866@mac.com>
40815 On Thursday, Sep 4, 2003, at 13:29 US/Pacific, Robert F Merrill wrote:
40817 > Brent DiNicola wrote:
40819 >> It wasn't an easy subject to sum up in just a few words.
40823 > Services is not the place to fix broken clients, and any client which
40824 > doesn't display notices correctly is broken. If someone wants to see
40825 > notices differently, they can either a) change their client or in the
40826 > case of webtv b) change the ircd
40828 > services is the wrong thing to change
40830 And telling someone what they obviously already know is generally not a
40831 good idea. Especially when they spent a very long paragraph defending
40832 their decision in the first place.
40834 This is the coding list, not the feature request list. He asked for
40835 code design approaches, not for political insight.
40840 From diego at redesul.net Thu Sep 18 16:29:40 2003
40841 From: diego at redesul.net (Diego B. Contezini)
40842 Date: Sat Oct 23 23:10:08 2004
40843 Subject: [IRCServices Coding] Re: How to get a core..
40844 Message-ID: <001c01c37e2d$c95d7840$3cc8a8c0@angel>
40846 Oooopz, im answering my ask...
40847 Looking in FAQ, where i should look before ask (sorry), I seen that you need
40848 to change ./configure to drop a core.
40849 If someone more is needing it, is just configure with:
40850 ./configure -dumpcore -cflags -g -defaults
40856 ----- Original Message -----
40857 From: "Diego B. Contezini" <diego@redesul.net>
40858 To: <ircservices-coding@ircservices.za.net>
40859 Sent: Thursday, September 18, 2003 6:35 PM
40860 Subject: How to get a core..
40863 > Hello, im destruct_, im the administrator of the RedeSul Network.
40864 > (irc.redesul.net).
40865 > I'm with 28000 nick registers, sometimes our network get 5500 simultaneous
40866 > users, and we are very happy with your services.
40867 > Im wanting to help to search and stops bugs on ircservices, but i never
40870 > I tryed ulimit -c unlimited before run it, but it never drop a core...
40871 > Someone have any idea about how i can get it, to debug without need to
40873 > the services while debugging?
40874 > Its segfaulting approx. all days, one time for day.. sometimes get 2 days
40875 > without to go down.
40876 > Im with a redhat 9.
40880 > Diego B. Contezini aka destruct_ | irc.redesul.net
40881 > (Sorry for my confuse english.)
40885 From diego at redesul.net Thu Sep 18 17:12:05 2003
40886 From: diego at redesul.net (Diego B. Contezini)
40887 Date: Sat Oct 23 23:10:08 2004
40888 Subject: [IRCServices Coding] How to get a core..
40889 References: <Law14-F109aJWJVUn700006a187@hotmail.com>
40890 Message-ID: <000901c37e2c$b8bd9980$3cc8a8c0@angel>
40892 Hello, im destruct_, im the administrator of the RedeSul Network.
40894 I'm with 28000 nick registers, sometimes our network get 5500 simultaneous
40895 users, and we are very happy with your services.
40896 Im wanting to help to search and stops bugs on ircservices, but i never get
40898 I tryed ulimit -c unlimited before run it, but it never drop a core...
40899 Someone have any idea about how i can get it, to debug without need to break
40900 the services while debugging?
40901 Its segfaulting approx. all days, one time for day.. sometimes get 2 days
40902 without to go down.
40903 Im with a redhat 9.
40907 Diego B. Contezini aka destruct_ | irc.redesul.net
40908 (Sorry for my confuse english.)
40911 From engin at piratetv.net Sun Sep 21 09:37:08 2003
40912 From: engin at piratetv.net (engin@piratetv)
40913 Date: Sat Oct 23 23:10:08 2004
40914 Subject: [IRCServices Coding] operserv
40915 Message-ID: <002101c3805f$0910a4c0$c7cf87d4@ptv91i58zrrpyd>
40919 can anyone help or point me to some good documentation regarding a
40920 version of unreal ircd we are running on a mandrake linux box..im mailing
40921 on behalf of the administrator who usually uses ssh to get into the box
40922 and make changes so im not super technical myself.the issue is with
40923 operserv..i cant access any operserv commands from my machine ( which
40924 is on the same local network as the box running the irc server ) always
40925 get operserv - access denied message..so im assuming it doesent
40926 recognise my remote ip address at an administrator..does anyone know
40927 the right sort of commands to use to set my remote machine to be
40928 recognised as admin or can they point me to any good support docs
40929 as i havent been able to find any yet
40933 -------------- next part --------------
40934 An HTML attachment was scrubbed...
40935 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030921/fdc12b4e/attachment-0003.htm
40936 From Craig at chatspike.net Sun Sep 21 14:28:23 2003
40937 From: Craig at chatspike.net (Craig McLure)
40938 Date: Sat Oct 23 23:10:08 2004
40939 Subject: [IRCServices Coding] operserv
40940 Message-ID: <E1A1Bk4-0001Xo-00@ptb-mailc04.plus.net>
40942 make sure you are on the services administrator list, if you are not, get the root administrator to add you using the command:
40944 [22:27] -OperServ- Syntax: ADMIN ADD nickname
40945 [22:27] -OperServ- ADMIN DEL nickname
40946 [22:27] -OperServ- ADMIN LIST
40948 [22:27] -OperServ- Allows the Services super-user to add or remove nicknames
40949 [22:27] -OperServ- to or from the Services admin list. A user whose nickname
40950 [22:27] -OperServ- is on the Services admin list and who has identified to
40951 [22:27] -OperServ- NickServ will be able to access Services admin commands.
40953 [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the command.
40954 [22:27] -OperServ- All other use limited to Services super-user.
40958 /****************************************
40959 * Craig "FrostyCoolSlug" McLure
40960 ************* - SpamBox - **************
40961 * InspIRCd - http://www.inspircd.org
40962 * ChatSpike - http://www.chatspike.net
40963 * WinBot - http://www.winbot.co.uk
40964 ****************************************/
40966 /****************************************
40967 * From - engin <engin@piratetv.net>
40968 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
40969 * Sent - 2003-09-21 @ 17:40:00
40970 * Subject - [IRCServices Coding] operserv
40971 ****************************************/
40973 /****** - Begin Original Message - ******/
40977 >can anyone help or point me to some good documentation regarding a
40978 >version of unreal ircd we are running on a mandrake linux box..im mailing
40979 >on behalf of the administrator who usually uses ssh to get into the box
40980 >and make changes so im not super technical myself.the issue is with
40981 >operserv..i cant access any operserv commands from my machine ( which
40982 >is on the same local network as the box running the irc server ) always
40983 >get operserv - access denied message..so im assuming it doesent
40984 >recognise my remote ip address at an administrator..does anyone know
40985 >the right sort of commands to use to set my remote machine to be
40986 >recognised as admin or can they point me to any good support docs
40987 >as i havent been able to find any yet
40991 >------------------------------------------------------------------
40992 >To unsubscribe or change your subscription options, visit:
40993 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
40995 /******* - End Original Message - *******/
40999 From saturn at jetirc.net Sun Sep 21 15:24:25 2003
41000 From: saturn at jetirc.net (Saturn)
41001 Date: Sat Oct 23 23:10:08 2004
41002 Subject: [IRCServices Coding] operserv
41003 References: <002101c3805f$0910a4c0$c7cf87d4@ptv91i58zrrpyd>
41004 Message-ID: <002b01c3808e$f2590ee0$6401a8c0@turby>
41006 Contact me directly... I have quite a bit of experience with unreal and these services...
41010 ----- Original Message -----
41011 From: engin@piratetv
41012 To: ircservices-coding@ircservices.za.net
41013 Sent: Sunday, September 21, 2003 9:40 AM
41014 Subject: [IRCServices Coding] operserv
41019 can anyone help or point me to some good documentation regarding a
41020 version of unreal ircd we are running on a mandrake linux box..im mailing
41021 on behalf of the administrator who usually uses ssh to get into the box
41022 and make changes so im not super technical myself.the issue is with
41023 operserv..i cant access any operserv commands from my machine ( which
41024 is on the same local network as the box running the irc server ) always
41025 get operserv - access denied message..so im assuming it doesent
41026 recognise my remote ip address at an administrator..does anyone know
41027 the right sort of commands to use to set my remote machine to be
41028 recognised as admin or can they point me to any good support docs
41029 as i havent been able to find any yet
41036 ------------------------------------------------------------------------------
41039 ------------------------------------------------------------------
41040 To unsubscribe or change your subscription options, visit:
41041 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
41042 -------------- next part --------------
41043 An HTML attachment was scrubbed...
41044 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030921/ca188e06/attachment-0003.html
41045 From saturn at jetirc.net Sun Sep 21 17:14:42 2003
41046 From: saturn at jetirc.net (Saturn)
41047 Date: Sat Oct 23 23:10:08 2004
41048 Subject: [IRCServices Coding] operserv
41049 References: <E1A1Bk4-0001Xo-00@ptb-mailc04.plus.net>
41050 Message-ID: <000d01c3809e$5b9d2800$6401a8c0@turby>
41052 Not to mention the obvious: You need to have an O:line and be opered up
41053 before Operserv will even listen to your commands without access denied....
41055 ----- Original Message -----
41056 From: "Craig McLure" <Craig@chatspike.net>
41057 To: "IRC Services Coding Mailing List"
41058 <ircservices-coding@ircservices.za.net>
41059 Sent: Sunday, September 21, 2003 3:28 PM
41060 Subject: Re: [IRCServices Coding] operserv
41063 make sure you are on the services administrator list, if you are not, get
41064 the root administrator to add you using the command:
41066 [22:27] -OperServ- Syntax: ADMIN ADD nickname
41067 [22:27] -OperServ- ADMIN DEL nickname
41068 [22:27] -OperServ- ADMIN LIST
41070 [22:27] -OperServ- Allows the Services super-user to add or remove nicknames
41071 [22:27] -OperServ- to or from the Services admin list. A user whose nickname
41072 [22:27] -OperServ- is on the Services admin list and who has identified to
41073 [22:27] -OperServ- NickServ will be able to access Services admin commands.
41075 [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
41077 [22:27] -OperServ- All other use limited to Services super-user.
41081 /****************************************
41082 * Craig "FrostyCoolSlug" McLure
41083 ************* - SpamBox - **************
41084 * InspIRCd - http://www.inspircd.org
41085 * ChatSpike - http://www.chatspike.net
41086 * WinBot - http://www.winbot.co.uk
41087 ****************************************/
41089 /****************************************
41090 * From - engin <engin@piratetv.net>
41091 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
41092 * Sent - 2003-09-21 @ 17:40:00
41093 * Subject - [IRCServices Coding] operserv
41094 ****************************************/
41096 /****** - Begin Original Message - ******/
41100 >can anyone help or point me to some good documentation regarding a
41101 >version of unreal ircd we are running on a mandrake linux box..im mailing
41102 >on behalf of the administrator who usually uses ssh to get into the box
41103 >and make changes so im not super technical myself.the issue is with
41104 >operserv..i cant access any operserv commands from my machine ( which
41105 >is on the same local network as the box running the irc server ) always
41106 >get operserv - access denied message..so im assuming it doesent
41107 >recognise my remote ip address at an administrator..does anyone know
41108 >the right sort of commands to use to set my remote machine to be
41109 >recognised as admin or can they point me to any good support docs
41110 >as i havent been able to find any yet
41114 >------------------------------------------------------------------
41115 >To unsubscribe or change your subscription options, visit:
41116 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
41118 /******* - End Original Message - *******/
41121 ------------------------------------------------------------------
41122 To unsubscribe or change your subscription options, visit:
41123 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
41126 From engin at piratetv.net Mon Sep 22 05:13:57 2003
41127 From: engin at piratetv.net (engin@piratetv)
41128 Date: Sat Oct 23 23:10:08 2004
41129 Subject: [IRCServices Coding] Re: IRCServices-Coding Digest, Vol 8, Issue 5
41130 References: <20030922120923.425971706D@snow.fingers.co.za>
41131 Message-ID: <003c01c38103$73a516f0$c7cf87d4@ptv91i58zrrpyd>
41133 many thanks for the replies..im going to get the info to the
41134 root administrator now and ill let you know how i get
41141 ----- Original Message -----
41142 From: <ircservices-coding-request@ircservices.za.net>
41143 To: <ircservices-coding@ircservices.za.net>
41144 Sent: Monday, September 22, 2003 1:09 PM
41145 Subject: IRCServices-Coding Digest, Vol 8, Issue 5
41148 > Send IRCServices-Coding mailing list submissions to
41149 > ircservices-coding@ircservices.za.net
41151 > To subscribe or unsubscribe via the World Wide Web, visit
41152 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
41153 > or, via email, send a message with subject or body 'help' to
41154 > ircservices-coding-request@ircservices.za.net
41156 > You can reach the person managing the list at
41157 > ircservices-coding-owner@ircservices.za.net
41159 > When replying, please edit your Subject line so it is more specific
41160 > than "Re: Contents of IRCServices-Coding digest..."
41165 > 1. operserv (engin@piratetv)
41166 > 2. Re: operserv (Craig McLure)
41167 > 3. Re: operserv (Saturn)
41168 > 4. Re: operserv (Saturn)
41171 > ----------------------------------------------------------------------
41174 > Date: Sun, 21 Sep 2003 17:40:15 +0100
41175 > From: "engin@piratetv" <engin@piratetv.net>
41176 > Subject: [IRCServices Coding] operserv
41177 > To: <ircservices-coding@ircservices.za.net>
41178 > Message-ID: <002101c3805f$0910a4c0$c7cf87d4@ptv91i58zrrpyd>
41179 > Content-Type: text/plain; charset="iso-8859-1"
41183 > can anyone help or point me to some good documentation regarding a
41184 > version of unreal ircd we are running on a mandrake linux box..im mailing
41185 > on behalf of the administrator who usually uses ssh to get into the box
41186 > and make changes so im not super technical myself.the issue is with
41187 > operserv..i cant access any operserv commands from my machine ( which
41188 > is on the same local network as the box running the irc server ) always
41189 > get operserv - access denied message..so im assuming it doesent
41190 > recognise my remote ip address at an administrator..does anyone know
41191 > the right sort of commands to use to set my remote machine to be
41192 > recognised as admin or can they point me to any good support docs
41193 > as i havent been able to find any yet
41197 > -------------- next part --------------
41198 > An HTML attachment was scrubbed...
41200 http://snow.fingers.co.za/pipermail/ircservices-coding/attachments/20030921/
41201 fdc12b4e/attachment-0001.htm
41203 > ------------------------------
41206 > Date: Sun, 21 Sep 2003 22:28:13 +0000
41207 > From: "Craig McLure" <Craig@chatspike.net>
41208 > Subject: Re: [IRCServices Coding] operserv
41209 > To: IRC Services Coding Mailing List
41210 > <ircservices-coding@ircservices.za.net>
41211 > Message-ID: <E1A1Bk4-0001Xo-00@ptb-mailc04.plus.net>
41212 > Content-Type: text/plain; charset="us-ascii"
41214 > make sure you are on the services administrator list, if you are not, get
41215 the root administrator to add you using the command:
41217 > [22:27] -OperServ- Syntax: ADMIN ADD nickname
41218 > [22:27] -OperServ- ADMIN DEL nickname
41219 > [22:27] -OperServ- ADMIN LIST
41220 > [22:27] -OperServ-
41221 > [22:27] -OperServ- Allows the Services super-user to add or remove
41223 > [22:27] -OperServ- to or from the Services admin list. A user whose
41225 > [22:27] -OperServ- is on the Services admin list and who has identified to
41226 > [22:27] -OperServ- NickServ will be able to access Services admin
41228 > [22:27] -OperServ-
41229 > [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
41231 > [22:27] -OperServ- All other use limited to Services super-user.
41235 > /****************************************
41236 > * Craig "FrostyCoolSlug" McLure
41237 > ************* - SpamBox - **************
41238 > * InspIRCd - http://www.inspircd.org
41239 > * ChatSpike - http://www.chatspike.net
41240 > * WinBot - http://www.winbot.co.uk
41241 > ****************************************/
41243 > /****************************************
41244 > * From - engin <engin@piratetv.net>
41245 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
41246 > * Sent - 2003-09-21 @ 17:40:00
41247 > * Subject - [IRCServices Coding] operserv
41248 > ****************************************/
41250 > /****** - Begin Original Message - ******/
41254 > >can anyone help or point me to some good documentation regarding a
41255 > >version of unreal ircd we are running on a mandrake linux box..im mailing
41256 > >on behalf of the administrator who usually uses ssh to get into the box
41257 > >and make changes so im not super technical myself.the issue is with
41258 > >operserv..i cant access any operserv commands from my machine ( which
41259 > >is on the same local network as the box running the irc server ) always
41260 > >get operserv - access denied message..so im assuming it doesent
41261 > >recognise my remote ip address at an administrator..does anyone know
41262 > >the right sort of commands to use to set my remote machine to be
41263 > >recognised as admin or can they point me to any good support docs
41264 > >as i havent been able to find any yet
41268 > >------------------------------------------------------------------
41269 > >To unsubscribe or change your subscription options, visit:
41270 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
41272 > /******* - End Original Message - *******/
41276 > ------------------------------
41279 > Date: Sun, 21 Sep 2003 15:23:13 -0700
41280 > From: "Saturn" <saturn@jetirc.net>
41281 > Subject: Re: [IRCServices Coding] operserv
41282 > To: "IRC Services Coding Mailing List"
41283 > <ircservices-coding@ircservices.za.net>
41284 > Message-ID: <002b01c3808e$f2590ee0$6401a8c0@turby>
41285 > Content-Type: text/plain; charset="iso-8859-1"
41287 > Contact me directly... I have quite a bit of experience with unreal and
41292 > ----- Original Message -----
41293 > From: engin@piratetv
41294 > To: ircservices-coding@ircservices.za.net
41295 > Sent: Sunday, September 21, 2003 9:40 AM
41296 > Subject: [IRCServices Coding] operserv
41301 > can anyone help or point me to some good documentation regarding a
41302 > version of unreal ircd we are running on a mandrake linux box..im
41304 > on behalf of the administrator who usually uses ssh to get into the box
41305 > and make changes so im not super technical myself.the issue is with
41306 > operserv..i cant access any operserv commands from my machine ( which
41307 > is on the same local network as the box running the irc server ) always
41308 > get operserv - access denied message..so im assuming it doesent
41309 > recognise my remote ip address at an administrator..does anyone know
41310 > the right sort of commands to use to set my remote machine to be
41311 > recognised as admin or can they point me to any good support docs
41312 > as i havent been able to find any yet
41319 > --------------------------------------------------------------------------
41323 > ------------------------------------------------------------------
41324 > To unsubscribe or change your subscription options, visit:
41325 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
41326 > -------------- next part --------------
41327 > An HTML attachment was scrubbed...
41329 http://snow.fingers.co.za/pipermail/ircservices-coding/attachments/20030921/
41330 ca188e06/attachment-0001.htm
41332 > ------------------------------
41335 > Date: Sun, 21 Sep 2003 17:13:31 -0700
41336 > From: "Saturn" <saturn@jetirc.net>
41337 > Subject: Re: [IRCServices Coding] operserv
41338 > To: "IRC Services Coding Mailing List"
41339 > <ircservices-coding@ircservices.za.net>
41340 > Message-ID: <000d01c3809e$5b9d2800$6401a8c0@turby>
41341 > Content-Type: text/plain; charset="iso-8859-1"
41343 > Not to mention the obvious: You need to have an O:line and be opered up
41344 > before Operserv will even listen to your commands without access
41347 > ----- Original Message -----
41348 > From: "Craig McLure" <Craig@chatspike.net>
41349 > To: "IRC Services Coding Mailing List"
41350 > <ircservices-coding@ircservices.za.net>
41351 > Sent: Sunday, September 21, 2003 3:28 PM
41352 > Subject: Re: [IRCServices Coding] operserv
41355 > make sure you are on the services administrator list, if you are not, get
41356 > the root administrator to add you using the command:
41358 > [22:27] -OperServ- Syntax: ADMIN ADD nickname
41359 > [22:27] -OperServ- ADMIN DEL nickname
41360 > [22:27] -OperServ- ADMIN LIST
41361 > [22:27] -OperServ-
41362 > [22:27] -OperServ- Allows the Services super-user to add or remove
41364 > [22:27] -OperServ- to or from the Services admin list. A user whose
41366 > [22:27] -OperServ- is on the Services admin list and who has identified to
41367 > [22:27] -OperServ- NickServ will be able to access Services admin
41369 > [22:27] -OperServ-
41370 > [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
41372 > [22:27] -OperServ- All other use limited to Services super-user.
41376 > /****************************************
41377 > * Craig "FrostyCoolSlug" McLure
41378 > ************* - SpamBox - **************
41379 > * InspIRCd - http://www.inspircd.org
41380 > * ChatSpike - http://www.chatspike.net
41381 > * WinBot - http://www.winbot.co.uk
41382 > ****************************************/
41384 > /****************************************
41385 > * From - engin <engin@piratetv.net>
41386 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
41387 > * Sent - 2003-09-21 @ 17:40:00
41388 > * Subject - [IRCServices Coding] operserv
41389 > ****************************************/
41391 > /****** - Begin Original Message - ******/
41395 > >can anyone help or point me to some good documentation regarding a
41396 > >version of unreal ircd we are running on a mandrake linux box..im mailing
41397 > >on behalf of the administrator who usually uses ssh to get into the box
41398 > >and make changes so im not super technical myself.the issue is with
41399 > >operserv..i cant access any operserv commands from my machine ( which
41400 > >is on the same local network as the box running the irc server ) always
41401 > >get operserv - access denied message..so im assuming it doesent
41402 > >recognise my remote ip address at an administrator..does anyone know
41403 > >the right sort of commands to use to set my remote machine to be
41404 > >recognised as admin or can they point me to any good support docs
41405 > >as i havent been able to find any yet
41409 > >------------------------------------------------------------------
41410 > >To unsubscribe or change your subscription options, visit:
41411 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
41413 > /******* - End Original Message - *******/
41416 > ------------------------------------------------------------------
41417 > To unsubscribe or change your subscription options, visit:
41418 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
41421 > ------------------------------
41423 > _______________________________________________
41424 > IRCServices-Coding mailing list
41425 > IRCServices-Coding@ircservices.za.net
41426 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
41429 > End of IRCServices-Coding Digest, Vol 8, Issue 5
41430 > ************************************************
41433 From diego at redesul.net Sun Oct 5 22:45:19 2003
41434 From: diego at redesul.net (Diego B. Contezini)
41435 Date: Sat Oct 23 23:10:08 2004
41436 Subject: [IRCServices Coding] Bug....
41437 References: <E1A1Bk4-0001Xo-00@ptb-mailc04.plus.net>
41438 <000d01c3809e$5b9d2800$6401a8c0@turby>
41439 Message-ID: <003b01c38b91$5f6a32e0$3cc8a8c0@angel>
41441 Sometimes has occur this bug, last 1 year....
41442 on a network with 30k registers, its happening with latency of 3.. 4
41445 someone have any idea?
41447 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
41448 av=0xbfffeec8) at channels.c:278
41451 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
41452 av=0xbfffeec8) at channels.c:278
41453 chan = (Channel *) 0xa97b6b8
41454 s = 0x20656c62 <Address 0x20656c62 out of bounds>
41456 modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
41457 #1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:680
41459 "-isl\000\037\006\bp?????????@???\006\b\000\000\000\000\000\000\000B\000\000
41460 \000\0007 \006\b\003\000\000\000TZ\000\000????????????
41461 ?????????\001\200??????@???\006\b@???\006\b@???\006\b@???\006\bO???\006\b@\0
41462 02\a\b@???\006\b@\002\a\b", '\0' <repeats 20 times>,
41463 "\027\000\000\000\000\000\000\000W???\022B\000\000\000\000\000\000\000\000\0
41464 05\000\000\000\210o\a\bTZ\000\000\000\000\000\000???????????????<\023B\001\0
41465 00\000\000???????????????m\tBd???\022B???q\a\b\v???\006B\024\032\023B\024\03
41466 2\023B3\035\rB\024\032\023B??????\006B\003\000\000\000????????????\027\000\0
41467 00\000\000\000\000\000\024\032"...
41468 s = 0xbfffeef0 "-isl"
41469 argv = {0xa97b6c0 "#young", 0x20656c62 <Address 0x20656c62 out of
41471 0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 out
41472 of bounds>, 0x42133cec "\004", 0xbffff1fc "",
41473 0x4204533d "\201?????????\016", 0x42131a14 " \031\023B???h\001@`???"}
41477 #2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
41481 md = (struct modedata *) 0x0
41486 #3 0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at main.c:269
41488 now_msec = 241253125
41489 last_update = 1065392973
41490 last_check = 241252363
41491 #4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
41492 No symbol table info available.
41497 From achurch at achurch.org Mon Oct 6 00:41:54 2003
41498 From: achurch at achurch.org (Andrew Church)
41499 Date: Sat Oct 23 23:10:08 2004
41500 Subject: [IRCServices Coding] Bug....
41501 In-Reply-To: <003b01c38b91$5f6a32e0$3cc8a8c0@angel>
41502 Message-ID: <3f811cad.24262@achurch.org>
41507 achurch@achurch.org
41508 http://achurch.org/
41510 >Sometimes has occur this bug, last 1 year....
41511 >on a network with 30k registers, its happening with latency of 3.. 4
41514 >someone have any idea?
41516 >#0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
41517 >av=0xbfffeec8) at channels.c:278
41520 >#0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
41521 >av=0xbfffeec8) at channels.c:278
41522 > chan = (Channel *) 0xa97b6b8
41523 > s = 0x20656c62 <Address 0x20656c62 out of bounds>
41525 > modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
41526 >#1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:68
41529 >"-isl\000\037\006\bp���@�\006\b\000\000\0
41530 >00\000\000\000\000B\000\000
41531 >\000\0007 \006\b\003\000\000\000TZ\000\000���ï¿
41533 >���\001\200��@�\006\b@ï
41534 >¿½\006\b@�\006\b@�\006\bO�\006\b@\0
41535 >02\a\b@�\006\b@\002\a\b", '\0' <repeats 20 times>,
41536 >"\027\000\000\000\000\000\000\000W�\022B\000\000\000\000\000\000\
41538 >05\000\000\000\210o\a\bTZ\000\000\000\000\000\000��ï¿
41539 >½ï¿½ï¿½<\023B\001\0
41540 >00\000\000�����m\tBd�\022
41541 >B�q\a\b\v�\006B\024\032\023B\024\03
41542 >2\023B3\035\rB\024\032\023B��\006B\003\000\000\000�
41544 >00\000\000\000\000\000\024\032"...
41545 > s = 0xbfffeef0 "-isl"
41546 > argv = {0xa97b6c0 "#young", 0x20656c62 <Address 0x20656c62 out
41549 > 0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 o
41551 >of bounds>, 0x42133cec "\004", 0xbffff1fc "",
41552 > 0x4204533d "\201���\016", 0x42131a14 " \031\023
41557 >#2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:32
41562 > md = (struct modedata *) 0x0
41567 >#3 0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at ma
41570 > now_msec = 241253125
41571 > last_update = 1065392973
41572 > last_check = 241252363
41573 >#4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
41574 >No symbol table info available.
41578 >------------------------------------------------------------------
41579 >To unsubscribe or change your subscription options, visit:
41580 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
41582 From diego at redesul.net Mon Oct 6 02:36:40 2003
41583 From: diego at redesul.net (Diego B. Contezini)
41584 Date: Sat Oct 23 23:10:08 2004
41585 Subject: [IRCServices Coding] Bug....
41586 References: <3f811cad.24262@achurch.org>
41587 Message-ID: <005501c38bed$4c9b1dd0$3cc8a8c0@angel>
41590 ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
41594 Its the last version.......
41597 ----- Original Message -----
41598 From: "Andrew Church" <achurch@achurch.org>
41599 To: <ircservices-coding@ircservices.za.net>
41600 Sent: Monday, October 06, 2003 4:41 AM
41601 Subject: Re: [IRCServices Coding] Bug....
41607 > achurch@achurch.org
41608 > http://achurch.org/
41610 > >Sometimes has occur this bug, last 1 year....
41611 > >on a network with 30k registers, its happening with latency of 3.. 4
41614 > >someone have any idea?
41616 > >#0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
41617 > >av=0xbfffeec8) at channels.c:278
41618 > >278 while (*s) {
41620 > >#0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
41621 > >av=0xbfffeec8) at channels.c:278
41622 > > chan = (Channel *) 0xa97b6b8
41623 > > s = 0x20656c62 <Address 0x20656c62 out of bounds>
41625 > > modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
41626 > >#1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:68
41629 > >"-isl\000\037\006\bp?????????@???\006\b\000\000\0
41630 > >00\000\000\000\000B\000\000
41631 > >\000\0007 \006\b\003\000\000\000TZ\000\000???????????
41633 > >?????????\001\200??????@???\006\b@?
41634 > >??\006\b@???\006\b@???\006\bO???\006\b@\0
41635 > >02\a\b@???\006\b@\002\a\b", '\0' <repeats 20 times>,
41636 > >"\027\000\000\000\000\000\000\000W???\022B\000\000\000\000\000\000\
41638 > >05\000\000\000\210o\a\bTZ\000\000\000\000\000\000????????
41639 > >???????<\023B\001\0
41640 > >00\000\000???????????????m\tBd???\022
41641 > >B???q\a\b\v???\006B\024\032\023B\024\03
41642 > >2\023B3\035\rB\024\032\023B??????\006B\003\000\000\000???
41643 > >?????????\027\000\0
41644 > >00\000\000\000\000\000\024\032"...
41645 > > s = 0xbfffeef0 "-isl"
41646 > > argv = {0xa97b6c0 "#young", 0x20656c62 <Address 0x20656c62 out
41649 > > 0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 o
41651 > >of bounds>, 0x42133cec "\004", 0xbffff1fc "",
41652 > > 0x4204533d "\201?????????\016", 0x42131a14 " \031\023
41653 > >B???h\001@`???"}
41657 > >#2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:32
41661 > > modes_orig = 0x0
41662 > > md = (struct modedata *) 0x0
41667 > >#3 0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at ma
41669 > > now = 1065393142
41670 > > now_msec = 241253125
41671 > > last_update = 1065392973
41672 > > last_check = 241252363
41673 > >#4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
41674 > >No symbol table info available.
41678 > >------------------------------------------------------------------
41679 > >To unsubscribe or change your subscription options, visit:
41680 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
41681 > ------------------------------------------------------------------
41682 > To unsubscribe or change your subscription options, visit:
41683 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
41687 From achurch at achurch.org Mon Oct 6 06:45:43 2003
41688 From: achurch at achurch.org (Andrew Church)
41689 Date: Sat Oct 23 23:10:08 2004
41690 Subject: [IRCServices Coding] Bug....
41691 In-Reply-To: <005501c38bed$4c9b1dd0$3cc8a8c0@angel>
41692 Message-ID: <3f8171f9.25006@achurch.org>
41695 >ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
41699 >Its the last version.......
41701 Then send a full debug log (from startup to crash), or I can't help.
41704 achurch@achurch.org
41705 http://achurch.org/
41707 From diego at redesul.net Mon Oct 6 17:16:29 2003
41708 From: diego at redesul.net (Diego B. Contezini)
41709 Date: Sat Oct 23 23:10:08 2004
41710 Subject: [IRCServices Coding] Bug....
41711 References: <3f8171f9.25006@achurch.org>
41712 Message-ID: <010601c38c68$2e6dc8a0$3cc8a8c0@angel>
41714 And how should be this log? i sent a backtrace......
41717 ----- Original Message -----
41718 From: "Andrew Church" <achurch@achurch.org>
41719 To: <ircservices-coding@ircservices.za.net>
41720 Sent: Monday, October 06, 2003 10:44 AM
41721 Subject: Re: [IRCServices Coding] Bug....
41725 > >ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
41726 > >18:41:36 BRT 2003
41729 > >Its the last version.......
41731 > Then send a full debug log (from startup to crash), or I can't help.
41734 > achurch@achurch.org
41735 > http://achurch.org/
41736 > ------------------------------------------------------------------
41737 > To unsubscribe or change your subscription options, visit:
41738 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
41742 From achurch at achurch.org Mon Oct 6 19:32:07 2003
41743 From: achurch at achurch.org (Andrew Church)
41744 Date: Sat Oct 23 23:10:08 2004
41745 Subject: [IRCServices Coding] Bug....
41746 In-Reply-To: <010601c38c68$2e6dc8a0$3cc8a8c0@angel>
41747 Message-ID: <3f822598.26100@achurch.org>
41749 >And how should be this log? i sent a backtrace......
41754 achurch@achurch.org
41755 http://achurch.org/
41757 From diego at redesul.net Mon Oct 6 22:36:40 2003
41758 From: diego at redesul.net (Diego B. Contezini)
41759 Date: Sat Oct 23 23:10:08 2004
41760 Subject: [IRCServices Coding] Bug....
41761 References: <3f822598.26100@achurch.org>
41762 Message-ID: <011601c38c94$ebc3ec00$3cc8a8c0@angel>
41765 If i start it with -debug it will get me gb's of information. This occur
41766 after days with services up, i will try to run it into a screen.... with
41771 ----- Original Message -----
41772 From: "Andrew Church" <achurch@achurch.org>
41773 To: <ircservices-coding@ircservices.za.net>
41774 Sent: Monday, October 06, 2003 11:31 PM
41775 Subject: Re: [IRCServices Coding] Bug....
41778 > >And how should be this log? i sent a backtrace......
41783 > achurch@achurch.org
41784 > http://achurch.org/
41785 > ------------------------------------------------------------------
41786 > To unsubscribe or change your subscription options, visit:
41787 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
41791 From saturn at jetirc.net Fri Oct 10 15:48:47 2003
41792 From: saturn at jetirc.net (Saturn)
41793 Date: Sat Oct 23 23:10:08 2004
41794 Subject: [IRCServices Coding] Akill problem in 5.0.22
41795 References: <14C7EDD0-DC1B-11D7-8505-0003938D6866@mac.com>
41796 Message-ID: <004001c38f80$9f635960$6401a8c0@turby>
41798 Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
41799 duplicate exit system notice that happens in 3.1.6).
41801 I just today added an akill (+0 time) .. I DO have the immediate auto kill
41802 option un-commented in the modules.conf, but it still didn't bother scanning
41803 for victims matching my akill mask nor did it actually KILL anyone... It
41804 works if they are manually killed and then try to re-connect, but I thought
41805 that new option was so Services will immediately scan for and kill anyone
41806 online that matches the mask as soon as the new akill is added...
41808 First: IS that what it's supposed to do?
41810 Second: If so, it's not working...
41816 From laser at musichat.net Sat Oct 11 00:56:04 2003
41817 From: laser at musichat.net (Alessandro Ciappei)
41818 Date: Sat Oct 23 23:10:08 2004
41819 Subject: [IRCServices Coding] Problem with auth mail
41820 In-Reply-To: <20031007101106.2701D1703F@snow.fingers.co.za>
41821 Message-ID: <GMEFIDBHIMPENBMIJNFEEEGDCAAA.laser@musichat.net>
41824 Hi all, I've ircservices 5.0.22, and I would like to costumize auth-mail.
41825 I would like describe my irc network in this mail, but when someone register
41826 nick, services go in segfault.
41828 I copy the sintaz of mail-auth ( it's in italian )
41830 # Mail text. The last "%s" (before the user@host) in the body text is
41831 # replaced by one of the NICK_AUTH_MAIL_TEXT_* messages.
41832 NICK_AUTH_MAIL_SUBJECT
41833 Conferma della registrazione del nick %s
41834 NICK_AUTH_MAIL_BODY
41835 Grazie per aver scelto MusiChat Net Community!
41836 Il codice di autorizzazione del tuo nick (%s) e': %09d
41837 Identificati su MusiChat digitando:
41840 La registrazione del tuo nick sara' confermata e il tuo nickname
41841 sara' protetto da eventuali tentativi di abuso o furto.
41843 Il sito ufficiale della rete e' http://www.musichat.net/
41844 I regolamenti della rete e i documenti ufficiali sono
41845 disponibili all'interno del sito.
41847 Per ricevere assistenza sui servizi della rete
41848 in generale puoi rivolgerti sul canale ufficiale #IRCHelp
41849 oppure tramite email all'indirizzo irchelp@musichat.net.
41852 Sono inoltre disponibili i seguenti servizi:
41855 Forum di discussione di MusiChat, raggiungibile
41856 all'indirizzo http://forum.musichat.net
41857 Sul forum, oltre a poter esprimere la tua opinione,
41858 potrai informarti sulle novita' e sui nuovi servizi
41859 offerti dalla rete.
41861 - MusiChat Mailing List
41862 Per iscriversi e' sufficiente visitare il sito
41863 http://lists.musichat.net/mailman/listinfo/irchelp
41864 e inserire il proprio indirizzo E-Mail e la
41865 password desiderata.
41868 Per una connessione piu' veloce e sicura e' vivamente
41869 consigliato l'utilizzo del seguente server: irc.musichat.net
41871 MusiChat Net Community
41873 Questo messaggio e stato inviato su richiesta di %s in risposta a %s
41879 I read the istruction for translate.
41883 [Oct 11 09:48:30 2003] PANIC! buffer = :alpha_omega ! nickserv :register
41884 pippo laser@musichat.net
41885 [Oct 11 09:48:30 2003] Services terminating: Segmentation fault
41888 Some one can help me?
41889 the email body is too long?
41897 From achurch at achurch.org Thu Oct 16 23:58:34 2003
41898 From: achurch at achurch.org (Andrew Church)
41899 Date: Sat Oct 23 23:10:08 2004
41900 Subject: [IRCServices Coding] Problem with auth mail
41901 In-Reply-To: <GMEFIDBHIMPENBMIJNFEEEGDCAAA.laser@musichat.net>
41902 Message-ID: <3f8f9304.20227@achurch.org>
41904 You have the wrong number of %-tokens in your message.
41907 achurch@achurch.org
41908 http://achurch.org/
41911 >Hi all, I've ircservices 5.0.22, and I would like to costumize auth-mail.
41912 >I would like describe my irc network in this mail, but when someone register
41913 >nick, services go in segfault.
41915 >I copy the sintaz of mail-auth ( it's in italian )
41917 ># Mail text. The last "%s" (before the user@host) in the body text is
41918 ># replaced by one of the NICK_AUTH_MAIL_TEXT_* messages.
41919 >NICK_AUTH_MAIL_SUBJECT
41920 > Conferma della registrazione del nick %s
41921 >NICK_AUTH_MAIL_BODY
41922 > Grazie per aver scelto MusiChat Net Community!
41923 > Il codice di autorizzazione del tuo nick (%s) e': %09d
41924 > Identificati su MusiChat digitando:
41925 > /msg %s AUTH %09d
41927 > La registrazione del tuo nick sara' confermata e il tuo nickname
41928 > sara' protetto da eventuali tentativi di abuso o furto.
41930 > Il sito ufficiale della rete e' http://www.musichat.net/
41931 > I regolamenti della rete e i documenti ufficiali sono
41932 > disponibili all'interno del sito.
41934 > Per ricevere assistenza sui servizi della rete
41935 > in generale puoi rivolgerti sul canale ufficiale #IRCHelp
41936 > oppure tramite email all'indirizzo irchelp@musichat.net.
41939 > Sono inoltre disponibili i seguenti servizi:
41942 > Forum di discussione di MusiChat, raggiungibile
41943 > all'indirizzo http://forum.musichat.net
41944 > Sul forum, oltre a poter esprimere la tua opinione,
41945 > potrai informarti sulle novita' e sui nuovi servizi
41946 > offerti dalla rete.
41948 > - MusiChat Mailing List
41949 > Per iscriversi e' sufficiente visitare il sito
41950 > http://lists.musichat.net/mailman/listinfo/irchelp
41951 > e inserire il proprio indirizzo E-Mail e la
41952 > password desiderata.
41955 > Per una connessione piu' veloce e sicura e' vivamente
41956 > consigliato l'utilizzo del seguente server: irc.musichat.net
41958 > MusiChat Net Community
41960 > Questo messaggio e stato inviato su richiesta di %s in risposta a %s
41966 >I read the istruction for translate.
41970 >[Oct 11 09:48:30 2003] PANIC! buffer = :alpha_omega ! nickserv :register
41971 >pippo laser@musichat.net
41972 >[Oct 11 09:48:30 2003] Services terminating: Segmentation fault
41975 >Some one can help me?
41976 >the email body is too long?
41983 >------------------------------------------------------------------
41984 >To unsubscribe or change your subscription options, visit:
41985 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
41987 From saman at alkol.org Fri Oct 17 03:07:31 2003
41988 From: saman at alkol.org (|SaMaN|)
41989 Date: Sat Oct 23 23:10:08 2004
41990 Subject: [IRCServices Coding] Bug or misunderstood ?
41991 Message-ID: <000901c39496$71764f10$a37faec3@coder>
41993 Im using unreal ircd. When channel is empty and if channel owner joins
41994 his/her registered channel it does
41995 (ChanServ sets mode: +ntrq nick) but when channel is not empty and if
41996 channel owner joins his/her registered channel it does (ChanServ sets mode:
41997 +oq nick nick). As you see on the first one there is no +o and because of
41998 this chanserv does not update the last_used time because chanserv is set to
41999 update last_used time with +o (CUMODE_o) so channels drop while channel
42000 owners use them. Is this a bug or my misunderstood ?
42002 ######################################################
42003 modules/chanserv/check.c
42005 void check_chan_user_modes(const char *source, struct c_userlist *u,
42006 Channel *c, int32 oldmodes)
42008 if ((res & ~modes) & CUMODE_o) {
42009 ci->last_used = time(NULL);
42010 put_channelinfo(ci);
42013 ######################################################
42019 From saman at alkol.org Fri Oct 17 04:53:04 2003
42020 From: saman at alkol.org (|SaMaN|)
42021 Date: Sat Oct 23 23:10:08 2004
42022 Subject: [IRCServices Coding] Re: Bug or misunderstood ?
42023 Message-ID: <002001c394a5$31c059b0$a37faec3@coder>
42025 Also it does not update last_used time on +a flag.
42030 edit /modules/chanserv/check.c
42033 -------------------------------------------------------------------------
42034 local_set_cumodes(c, '+', res & ~modes, user->nick);
42035 -------------------------------------------------------------------------
42037 ------------------------------------------------------------------------
42038 int16 cumode_q = mode_char_to_flag('q',MODE_CHANUSER);
42039 int16 cumode_a = mode_char_to_flag('a',MODE_CHANUSER);
42041 if ((res & ~modes) & cumode_q) {
42042 ci->last_used = time(NULL);
42043 put_channelinfo(ci);
42046 if ((res & ~modes) & cumode_a) {
42047 ci->last_used = time(NULL);
42048 put_channelinfo(ci);
42050 -------------------------------------------------------------------------
42051 save and compile and run and enjoy :)
42052 -------------------------------------------------------------------------
42056 ----- Original Message -----
42057 From: "|SaMaN|" <saman@alkol.org>
42058 To: <IRCServices-Coding@ircservices.za.net>
42059 Sent: Friday, October 17, 2003 1:07 PM
42060 Subject: Bug or misunderstood ?
42063 > Im using unreal ircd. When channel is empty and if channel owner joins
42064 > his/her registered channel it does
42065 > (ChanServ sets mode: +ntrq nick) but when channel is not empty and if
42066 > channel owner joins his/her registered channel it does (ChanServ sets
42068 > +oq nick nick). As you see on the first one there is no +o and because of
42069 > this chanserv does not update the last_used time because chanserv is set
42071 > update last_used time with +o (CUMODE_o) so channels drop while channel
42072 > owners use them. Is this a bug or my misunderstood ?
42074 > ######################################################
42075 > modules/chanserv/check.c
42077 > void check_chan_user_modes(const char *source, struct c_userlist *u,
42078 > Channel *c, int32 oldmodes)
42080 > if ((res & ~modes) & CUMODE_o) {
42081 > ci->last_used = time(NULL);
42082 > put_channelinfo(ci);
42085 > ######################################################
42092 From saturn at jetirc.net Fri Oct 17 08:47:59 2003
42093 From: saturn at jetirc.net (Saturn)
42094 Date: Sat Oct 23 23:10:08 2004
42095 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
42096 Message-ID: <002501c394c5$f8dce480$6401a8c0@turby>
42098 Haven't seen a reply to this one, so thought I'd better make sure this went
42101 ----- Original Message -----
42102 Sent: Friday, October 10, 2003 3:48 PM
42103 Subject: Akill problem in 5.0.22
42106 Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
42107 duplicate exit system notice that happens in 3.1.6).
42109 I just today added an akill (+0 time) .. I DO have the immediate auto kill
42110 option un-commented in the modules.conf, but it still didn't bother scanning
42111 for victims matching my akill mask nor did it actually KILL anyone... It
42112 works if they are manually killed and then try to re-connect, but I thought
42113 that new option was so Services will immediately scan for and kill anyone
42114 online that matches the mask as soon as the new akill is added...
42116 First: IS that what it's supposed to do?
42118 Second: If so, it's not working...
42124 From achurch at achurch.org Fri Oct 17 09:03:19 2003
42125 From: achurch at achurch.org (Andrew Church)
42126 Date: Sat Oct 23 23:10:08 2004
42127 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
42128 In-Reply-To: <002501c394c5$f8dce480$6401a8c0@turby>
42129 Message-ID: <3f9012b8.23176@achurch.org>
42134 achurch@achurch.org
42135 http://achurch.org/
42137 >Haven't seen a reply to this one, so thought I'd better make sure this went
42140 >----- Original Message -----
42141 >Sent: Friday, October 10, 2003 3:48 PM
42142 >Subject: Akill problem in 5.0.22
42145 >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
42146 >duplicate exit system notice that happens in 3.1.6).
42148 >I just today added an akill (+0 time) .. I DO have the immediate auto kill
42149 >option un-commented in the modules.conf, but it still didn't bother scanning
42150 >for victims matching my akill mask nor did it actually KILL anyone... It
42151 >works if they are manually killed and then try to re-connect, but I thought
42152 >that new option was so Services will immediately scan for and kill anyone
42153 >online that matches the mask as soon as the new akill is added...
42155 >First: IS that what it's supposed to do?
42157 >Second: If so, it's not working...
42162 >------------------------------------------------------------------
42163 >To unsubscribe or change your subscription options, visit:
42164 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
42166 From saturn at jetirc.net Fri Oct 17 09:19:32 2003
42167 From: saturn at jetirc.net (Saturn)
42168 Date: Sat Oct 23 23:10:08 2004
42169 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
42170 References: <3f9012b8.23176@achurch.org>
42171 Message-ID: <027401c394ca$443ae180$6401a8c0@turby>
42173 Well, Andrew, I did read TFM. For what it's worth, all I found was this
42174 entry under the description of the module options
42176 ImmediatelySendAutokill [OPTIONAL]
42177 Causes OperServ to inform all servers of a new autokill or autokill
42178 exclusion the moment it is added, rather than waiting for someone to match
42180 Example: ImmediatelySendAutokill
42182 I read through the section about AKILLs and SQline, SGline, SZline, etc,
42183 however all of what I read indicates that simply enabling the
42184 ImmediatelySendAutokill option in the modules.conf (coupled with the fact
42185 that everything ELSE is set up and workign properly) SHOULD cause services
42186 to immediately scan the network for clients matching the akill mask, and
42189 My point, sir, is that IT DOES NOT DO THIS. Thus, I'm sure you'll find, I
42190 HAVE in fact read the f___ manual, and the manual does not address this
42191 problem. If it doesn't matter to you, fine, but if it does, let's try and
42192 get on with maybe solving the problem?
42197 ----- Original Message -----
42198 From: "Andrew Church" <achurch@achurch.org>
42199 To: <ircservices-coding@ircservices.za.net>
42200 Sent: Friday, October 17, 2003 9:02 AM
42201 Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
42207 achurch@achurch.org
42208 http://achurch.org/
42210 >Haven't seen a reply to this one, so thought I'd better make sure this went
42213 >----- Original Message -----
42214 >Sent: Friday, October 10, 2003 3:48 PM
42215 >Subject: Akill problem in 5.0.22
42218 >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
42219 >duplicate exit system notice that happens in 3.1.6).
42221 >I just today added an akill (+0 time) .. I DO have the immediate auto kill
42222 >option un-commented in the modules.conf, but it still didn't bother
42224 >for victims matching my akill mask nor did it actually KILL anyone... It
42225 >works if they are manually killed and then try to re-connect, but I thought
42226 >that new option was so Services will immediately scan for and kill anyone
42227 >online that matches the mask as soon as the new akill is added...
42229 >First: IS that what it's supposed to do?
42231 >Second: If so, it's not working...
42236 >------------------------------------------------------------------
42237 >To unsubscribe or change your subscription options, visit:
42238 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
42239 ------------------------------------------------------------------
42240 To unsubscribe or change your subscription options, visit:
42241 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
42244 From achurch at achurch.org Fri Oct 17 09:34:48 2003
42245 From: achurch at achurch.org (Andrew Church)
42246 Date: Sat Oct 23 23:10:08 2004
42247 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
42248 In-Reply-To: <027401c394ca$443ae180$6401a8c0@turby>
42249 Message-ID: <3f901a20.23266@achurch.org>
42251 >however all of what I read indicates that simply enabling the
42252 >ImmediatelySendAutokill option in the modules.conf (coupled with the fact
42253 >that everything ELSE is set up and workign properly) SHOULD cause services
42254 >to immediately scan the network for clients matching the akill mask, and
42257 The documentation says nothing about this. RTFM again.
42260 achurch@achurch.org
42261 http://achurch.org/
42263 From ballsy at mystical.net Fri Oct 17 11:20:33 2003
42264 From: ballsy at mystical.net (Ballsy)
42265 Date: Sat Oct 23 23:10:08 2004
42266 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
42267 In-Reply-To: <027401c394ca$443ae180$6401a8c0@turby>
42268 References: <3f9012b8.23176@achurch.org> <027401c394ca$443ae180$6401a8c0@turby>
42269 Message-ID: <6.0.0.22.0.20031017121557.01b63ac0@127.0.0.1>
42271 To save the rest of us from having to put up with more bickering,
42272 it may be of note that I had to comment out 'EnableExclude' in order for my
42273 immediate-kill functionality to work under bahamut (I know, you're using
42274 Unreal). All the ImmediatelySendAkill does is informs all linked services
42275 that they should add an Akill. It's then up to those servers to decide how
42281 At 10:18 AM 17/10/2003, Saturn wrote:
42282 >Well, Andrew, I did read TFM. For what it's worth, all I found was this
42283 >entry under the description of the module options
42285 >ImmediatelySendAutokill [OPTIONAL]
42286 > Causes OperServ to inform all servers of a new autokill or autokill
42287 >exclusion the moment it is added, rather than waiting for someone to match
42289 > Example: ImmediatelySendAutokill
42291 >I read through the section about AKILLs and SQline, SGline, SZline, etc,
42292 >however all of what I read indicates that simply enabling the
42293 >ImmediatelySendAutokill option in the modules.conf (coupled with the fact
42294 >that everything ELSE is set up and workign properly) SHOULD cause services
42295 >to immediately scan the network for clients matching the akill mask, and
42298 >My point, sir, is that IT DOES NOT DO THIS. Thus, I'm sure you'll find, I
42299 >HAVE in fact read the f___ manual, and the manual does not address this
42300 >problem. If it doesn't matter to you, fine, but if it does, let's try and
42301 >get on with maybe solving the problem?
42306 >----- Original Message -----
42307 >From: "Andrew Church" <achurch@achurch.org>
42308 >To: <ircservices-coding@ircservices.za.net>
42309 >Sent: Friday, October 17, 2003 9:02 AM
42310 >Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
42316 > achurch@achurch.org
42317 > http://achurch.org/
42319 > >Haven't seen a reply to this one, so thought I'd better make sure this went
42322 > >----- Original Message -----
42323 > >Sent: Friday, October 10, 2003 3:48 PM
42324 > >Subject: Akill problem in 5.0.22
42327 > >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
42328 > >duplicate exit system notice that happens in 3.1.6).
42330 > >I just today added an akill (+0 time) .. I DO have the immediate auto kill
42331 > >option un-commented in the modules.conf, but it still didn't bother
42333 > >for victims matching my akill mask nor did it actually KILL anyone... It
42334 > >works if they are manually killed and then try to re-connect, but I thought
42335 > >that new option was so Services will immediately scan for and kill anyone
42336 > >online that matches the mask as soon as the new akill is added...
42338 > >First: IS that what it's supposed to do?
42340 > >Second: If so, it's not working...
42345 > >------------------------------------------------------------------
42346 > >To unsubscribe or change your subscription options, visit:
42347 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
42348 >------------------------------------------------------------------
42349 >To unsubscribe or change your subscription options, visit:
42350 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
42352 >------------------------------------------------------------------
42353 >To unsubscribe or change your subscription options, visit:
42354 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
42358 From saturn at jetirc.net Fri Oct 17 17:16:26 2003
42359 From: saturn at jetirc.net (Saturn)
42360 Date: Sat Oct 23 23:10:08 2004
42361 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
42362 References: <3f901a20.23266@achurch.org>
42363 Message-ID: <02d401c3950c$e762bda0$6401a8c0@turby>
42365 >From a.html in the /docs directory:
42367 operserv/akill (Autokill module settings)
42368 ImmediatelySendAutokill [OPTIONAL]
42369 Causes OperServ to inform all servers of a new autokill or autokill
42370 exclusion the moment it is added, rather than waiting for someone to match
42372 Example: ImmediatelySendAutokill
42375 3.html#4-3 in the /docs directory does not speak to the
42376 ImmediatelySendAutokill option except for the mention that:
42377 "(If the ImmediatelySendAutokill option in modules.conf is enabled, the
42378 last-used time will never be set at all on these servers.)"
42379 However, this is in the context of talking about Slines, etc, and as far as
42380 I can tell has no new useful information to impart regarding my stated
42381 problem: that services is NOT "Immediately sending the autokill" on my
42382 network and thus when a new AKILL is added, the matching users/masks are not
42383 being killed off, unless they are killed manually by an IRCop. Yes, it IS
42384 catching them when they attempt to re-connect, that was never a problem. It
42385 would make sense that if an autokill is added, that Services would
42386 immediately trace the network and kill off any matches to that akill... at
42387 least, it makes sense if this option is enabled.... (to me)
42388 ------------------------
42390 4.html#oper.akill doesn't mention it at all.
42394 I really don't see where else I'm supposed to be looking here. I've scoured
42395 the docs and can see no other reference to it. If there's something I'm
42396 missing, perhaps instead of rudely, repeatedly telling me to RTFM, maybe
42397 just tell me what it is I'm supposed to find! I've already spend a few
42398 hours reading through the docs (which I've already read about a dozen times
42399 over the past year alone), and I'm telling you, there's nothing else about
42400 it that I can find!!!
42402 The ONLY thing I can come up with is that the feature name is misleading and
42403 the option doesn't in fact do what it SEEMS it should do. Could it be that
42404 all that does is send the S/G/Z line (whatever is appropriate) to the
42405 servers and that's all??? NOW I have to ask, why bother, if it'll do that
42406 if/when they re-connect anyhow?
42408 Additionally, if the reason I can't find the answer in the manual is because
42409 the option DOESN'T make services kill all matches when the akill is added,
42410 then Imust ask WHY that isn't an option, since it seems logically useful to
42411 me and my staff. Also, that being the case, why couldn't you simply SAY
42412 that it's not designed to do that, instead of sending me hunting (TWICE) for
42413 non-existant information in the docs???????
42415 I'm very interested to hear the answer to these questions. To put it
42416 bluntly, I have been an extremely enthusiastic advocate of IRCServices for
42417 over 3 years now, have turned many network owners onto them, and love them
42418 to death. The way you "talk" to your supporters on this forum sometimes
42419 leaves a LOT to be desired. If the feature doesn't exist as I understand
42420 it, just SAY SO and save us all a lot of trouble -- don't just tell me to go
42421 RTFM when the info I seek isn't IN it. Having said that, if you can point
42422 me to the info in the docs in the 5.0.22 distro and prove my claims as
42423 baseless, I will offer my sincere apologies. Until then, my opinion stands.
42427 ----- Original Message -----
42428 From: "Andrew Church" <achurch@achurch.org>
42429 To: <ircservices-coding@ircservices.za.net>
42430 Sent: Friday, October 17, 2003 9:34 AM
42431 Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
42434 >however all of what I read indicates that simply enabling the
42435 >ImmediatelySendAutokill option in the modules.conf (coupled with the fact
42436 >that everything ELSE is set up and workign properly) SHOULD cause services
42437 >to immediately scan the network for clients matching the akill mask, and
42440 The documentation says nothing about this. RTFM again.
42443 achurch@achurch.org
42444 http://achurch.org/
42445 ------------------------------------------------------------------
42446 To unsubscribe or change your subscription options, visit:
42447 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
42450 From saturn at jetirc.net Fri Oct 17 17:33:57 2003
42451 From: saturn at jetirc.net (Saturn)
42452 Date: Sat Oct 23 23:10:08 2004
42453 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
42454 References: <3f9012b8.23176@achurch.org> <027401c394ca$443ae180$6401a8c0@turby>
42455 <6.0.0.22.0.20031017121557.01b63ac0@127.0.0.1>
42456 Message-ID: <030801c3950f$3cb55270$6401a8c0@turby>
42458 Would have been nice if someone had mentioned that (about the
42459 ImmediatelySendAutokill) from the start. I would say the flag is misleading
42460 in title then, because I (and 8 other people on my staff -- none of us are
42461 dummies, either) read that as meaning it will Immediately send the auto
42462 kill... "ImmediatelyUpdateServers" might be more fitting from an intuitive
42463 standpoint, not that I'm suggesting changing the name, but at least the
42464 documentation of it could be a bit more explicit IMHO.
42466 and yes, I know there will be about 50 people (probably all of them
42467 hard-core coders) shaking their heads in disbelief at what I've said, but
42468 let's face it: If we were ALL hard-core coders, we wouldn't need Andrew and
42469 his IRCServices, would we? We'd all be making our own. So all I'm saying
42470 is how about a little slack for those of us with OTHER important skills that
42471 might fall outside the scope of being the "world's greatest expert" on IRC
42474 ----- Original Message -----
42475 From: "Ballsy" <ballsy@mystical.net>
42476 To: "IRC Services Coding Mailing List"
42477 <ircservices-coding@ircservices.za.net>; "IRC Services Coding Mailing List"
42478 <ircservices-coding@ircservices.za.net>
42479 Sent: Friday, October 17, 2003 11:20 AM
42480 Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
42483 To save the rest of us from having to put up with more bickering,
42484 it may be of note that I had to comment out 'EnableExclude' in order for my
42485 immediate-kill functionality to work under bahamut (I know, you're using
42486 Unreal). All the ImmediatelySendAkill does is informs all linked services
42487 that they should add an Akill. It's then up to those servers to decide how
42493 At 10:18 AM 17/10/2003, Saturn wrote:
42494 >Well, Andrew, I did read TFM. For what it's worth, all I found was this
42495 >entry under the description of the module options
42497 >ImmediatelySendAutokill [OPTIONAL]
42498 > Causes OperServ to inform all servers of a new autokill or autokill
42499 >exclusion the moment it is added, rather than waiting for someone to match
42501 > Example: ImmediatelySendAutokill
42503 >I read through the section about AKILLs and SQline, SGline, SZline, etc,
42504 >however all of what I read indicates that simply enabling the
42505 >ImmediatelySendAutokill option in the modules.conf (coupled with the fact
42506 >that everything ELSE is set up and workign properly) SHOULD cause services
42507 >to immediately scan the network for clients matching the akill mask, and
42510 >My point, sir, is that IT DOES NOT DO THIS. Thus, I'm sure you'll find, I
42511 >HAVE in fact read the f___ manual, and the manual does not address this
42512 >problem. If it doesn't matter to you, fine, but if it does, let's try and
42513 >get on with maybe solving the problem?
42518 >----- Original Message -----
42519 >From: "Andrew Church" <achurch@achurch.org>
42520 >To: <ircservices-coding@ircservices.za.net>
42521 >Sent: Friday, October 17, 2003 9:02 AM
42522 >Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
42528 > achurch@achurch.org
42529 > http://achurch.org/
42531 > >Haven't seen a reply to this one, so thought I'd better make sure this
42535 > >----- Original Message -----
42536 > >Sent: Friday, October 10, 2003 3:48 PM
42537 > >Subject: Akill problem in 5.0.22
42540 > >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
42541 > >duplicate exit system notice that happens in 3.1.6).
42543 > >I just today added an akill (+0 time) .. I DO have the immediate auto
42545 > >option un-commented in the modules.conf, but it still didn't bother
42547 > >for victims matching my akill mask nor did it actually KILL anyone... It
42548 > >works if they are manually killed and then try to re-connect, but I
42550 > >that new option was so Services will immediately scan for and kill anyone
42551 > >online that matches the mask as soon as the new akill is added...
42553 > >First: IS that what it's supposed to do?
42555 > >Second: If so, it's not working...
42560 > >------------------------------------------------------------------
42561 > >To unsubscribe or change your subscription options, visit:
42562 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
42563 >------------------------------------------------------------------
42564 >To unsubscribe or change your subscription options, visit:
42565 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
42567 >------------------------------------------------------------------
42568 >To unsubscribe or change your subscription options, visit:
42569 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
42572 ------------------------------------------------------------------
42573 To unsubscribe or change your subscription options, visit:
42574 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
42577 From Craig at chatspike.net Fri Oct 17 19:07:33 2003
42578 From: Craig at chatspike.net (Craig McLure)
42579 Date: Sat Oct 23 23:10:08 2004
42580 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
42581 Message-ID: <E1AAgV1-0008ae-00@ptb-mailc04.plus.net>
42583 Theres no need for flaming ffs.. just because something makes less sence to you than to everyone else, doesnt instantly mean that it has to be changed.. i seemed to understand it ok, and i'm sure that there are several hundred other IRCServices users who didnt have any problems with this directive.
42585 I'm sure andy will concider documenting it more "accuratly" (I wont speak for him thou, his choice :p), but theres no need for the flaming, if you have such a big problem with something that (apparently just) you dont understand, just make a passing mention on it, dont go on talking about "Hard-core coders" and "worlds biggest expert"s cause you are upset with something. If the last paragraph wasnt made, i'm sure there _WOUDLNT_ be "about 50 people (probably all of them hard-core coders) shaking their heads in disbelief", cause it doesnt happen. And to clarify.. theres no such thing as a "world biggest expert" when it comes to IRC programming, people have different preferances, and ways of doing things, to the point that you cant compair something like InspIRCd to UnrealIRCd, as they are totally different in almost every way. :p
42587 Please just calm down, and talk this out rationally before you start jumping down ppls throats :p
42589 /*****************************************
42590 * Craig "FrostyCoolSlug" McLure
42591 * InspIRCd - http://www.inspircd.org
42592 * ChatSpike - http://www.chatspike.net
42593 ****************************************/
42596 /****************************************
42597 * From - Saturn <saturn@jetirc.net>
42598 * To - IRC Services Coding Mailing List <ircservices-coding@ircservices.za.net>
42599 * Sent - 2003-10-17 17:31:00
42600 * Subject - Re: [IRCServices Coding] Re: Akill problem in 5.0.22
42601 ****************************************/
42603 /****** - Begin Original Message - ******/
42605 >Would have been nice if someone had mentioned that (about the
42606 >ImmediatelySendAutokill) from the start. I would say the flag is misleading
42607 >in title then, because I (and 8 other people on my staff -- none of us are
42608 >dummies, either) read that as meaning it will Immediately send the auto
42609 >kill... "ImmediatelyUpdateServers" might be more fitting from an intuitive
42610 >standpoint, not that I'm suggesting changing the name, but at least the
42611 >documentation of it could be a bit more explicit IMHO.
42613 >and yes, I know there will be about 50 people (probably all of them
42614 >hard-core coders) shaking their heads in disbelief at what I've said, but
42615 >let's face it: If we were ALL hard-core coders, we wouldn't need Andrew and
42616 >his IRCServices, would we? We'd all be making our own. So all I'm saying
42617 >is how about a little slack for those of us with OTHER important skills that
42618 >might fall outside the scope of being the "world's greatest expert" on IRC
42621 >----- Original Message -----
42622 >From: "Ballsy" <ballsy@mystical.net>
42623 >To: "IRC Services Coding Mailing List"
42624 ><ircservices-coding@ircservices.za.net>; "IRC Services Coding Mailing List"
42625 ><ircservices-coding@ircservices.za.net>
42626 >Sent: Friday, October 17, 2003 11:20 AM
42627 >Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
42630 > To save the rest of us from having to put up with more bickering,
42631 >it may be of note that I had to comment out 'EnableExclude' in order for my
42632 >immediate-kill functionality to work under bahamut (I know, you're using
42633 >Unreal). All the ImmediatelySendAkill does is informs all linked services
42634 >that they should add an Akill. It's then up to those servers to decide how
42640 >At 10:18 AM 17/10/2003, Saturn wrote:
42641 >>Well, Andrew, I did read TFM. For what it's worth, all I found was this
42642 >>entry under the description of the module options
42644 >>ImmediatelySendAutokill [OPTIONAL]
42645 >> Causes OperServ to inform all servers of a new autokill or autokill
42646 >>exclusion the moment it is added, rather than waiting for someone to match
42648 >> Example: ImmediatelySendAutokill
42650 >>I read through the section about AKILLs and SQline, SGline, SZline, etc,
42651 >>however all of what I read indicates that simply enabling the
42652 >>ImmediatelySendAutokill option in the modules.conf (coupled with the fact
42653 >>that everything ELSE is set up and workign properly) SHOULD cause services
42654 >>to immediately scan the network for clients matching the akill mask, and
42657 >>My point, sir, is that IT DOES NOT DO THIS. Thus, I'm sure you'll find, I
42658 >>HAVE in fact read the f___ manual, and the manual does not address this
42659 >>problem. If it doesn't matter to you, fine, but if it does, let's try and
42660 >>get on with maybe solving the problem?
42665 >>----- Original Message -----
42666 >>From: "Andrew Church" <achurch@achurch.org>
42667 >>To: <ircservices-coding@ircservices.za.net>
42668 >>Sent: Friday, October 17, 2003 9:02 AM
42669 >>Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
42675 >> achurch@achurch.org
42676 >> http://achurch.org/
42678 >> >Haven't seen a reply to this one, so thought I'd better make sure this
42682 >> >----- Original Message -----
42683 >> >Sent: Friday, October 10, 2003 3:48 PM
42684 >> >Subject: Akill problem in 5.0.22
42687 >> >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
42688 >> >duplicate exit system notice that happens in 3.1.6).
42690 >> >I just today added an akill (+0 time) .. I DO have the immediate auto
42692 >> >option un-commented in the modules.conf, but it still didn't bother
42694 >> >for victims matching my akill mask nor did it actually KILL anyone... It
42695 >> >works if they are manually killed and then try to re-connect, but I
42697 >> >that new option was so Services will immediately scan for and kill anyone
42698 >> >online that matches the mask as soon as the new akill is added...
42700 >> >First: IS that what it's supposed to do?
42702 >> >Second: If so, it's not working...
42707 >> >------------------------------------------------------------------
42708 >> >To unsubscribe or change your subscription options, visit:
42709 >> >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
42710 >>------------------------------------------------------------------
42711 >>To unsubscribe or change your subscription options, visit:
42712 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
42714 >>------------------------------------------------------------------
42715 >>To unsubscribe or change your subscription options, visit:
42716 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
42719 >------------------------------------------------------------------
42720 >To unsubscribe or change your subscription options, visit:
42721 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
42723 >------------------------------------------------------------------
42724 >To unsubscribe or change your subscription options, visit:
42725 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
42729 /******* - End Original Message - *******/
42734 From achurch at achurch.org Fri Oct 17 20:13:46 2003
42735 From: achurch at achurch.org (Andrew Church)
42736 Date: Sat Oct 23 23:10:08 2004
42737 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
42738 In-Reply-To: <02d401c3950c$e762bda0$6401a8c0@turby>
42739 Message-ID: <3f90afdf.23477@achurch.org>
42741 You know, I might have been more forgiving if this hadn't been gone
42742 over on this list (twice!) before:
42744 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/002305.html
42745 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/003215.html
42747 However, since you seem to have trouble both comprehending the
42748 documentation and reading the archives, I have added FAQ F.10 for your
42751 F.10. Services doesn't kill users matching a newly-added autokill mask even
42752 if ImmediatelySendAutokill is set.
42754 Services never kills users when a new autokill is added; the
42755 ImmediatelySendAutokill configuration directive only causes
42756 Services to send the autokill itself (that is, the user/host mask
42757 to prohibit new connections from) to the IRC servers on your
42758 network. This is a safety feature intended to limit the damage
42759 caused by a mistyped autokill.
42761 Note that some IRC servers will themselves kill users matching a
42762 newly-added autokill; this is unrelated to Services.
42765 achurch@achurch.org
42766 http://achurch.org/
42768 From griever at t2n.org Fri Oct 17 21:23:14 2003
42769 From: griever at t2n.org (Robert F Merrill)
42770 Date: Sat Oct 23 23:10:08 2004
42771 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
42772 In-Reply-To: <030801c3950f$3cb55270$6401a8c0@turby>
42773 References: <3f9012b8.23176@achurch.org> <027401c394ca$443ae180$6401a8c0@turby>
42774 <6.0.0.22.0.20031017121557.01b63ac0@127.0.0.1>
42775 <030801c3950f$3cb55270$6401a8c0@turby>
42776 Message-ID: <3F90BF77.2010706@t2n.org>
42780 >Would have been nice if someone had mentioned that (about the
42781 >ImmediatelySendAutokill) from the start. I would say the flag is misleading
42782 >in title then, because I (and 8 other people on my staff -- none of us are
42783 >dummies, either) read that as meaning it will Immediately send the auto
42784 >kill... "ImmediatelyUpdateServers" might be more fitting from an intuitive
42785 >standpoint, not that I'm suggesting changing the name, but at least the
42786 >documentation of it could be a bit more explicit IMHO.
42789 It DOES immediately send the autokill. You just don't grasp the meaning
42790 of sending the autokill.
42791 It literally sends an AKILL (or TKL in the case of unreal) message to
42792 the servers. At least unreal
42793 and bahamut will then scan for matching clients and disconnect them,
42794 however not all servers
42797 If you are using unreal and it doesn't disconnect the matching users,
42798 then it is either a bug in
42799 unreal (not uncommon) or the services really *aren't* sending the tkl
42800 message (doubt it).
42802 Try adding an akill for a connected client. If the client doesn't die,
42803 do a /stats g on their server.
42804 You should see a g-line added for them.
42806 Also note that if you have akill exclusions enabled (bad idea most of
42807 the time), services will NEVER add an akill
42808 or gline on servers that don't support akill or gline exclusions (I
42809 don't know of any that do), but rather
42810 manually kill everyone that matches as they connect. In this case, you
42811 should disable akill exclusions and
42812 it should start working.
42816 From v13 at it.teithe.gr Sat Oct 18 11:47:23 2003
42817 From: v13 at it.teithe.gr (V13)
42818 Date: Sat Oct 23 23:10:08 2004
42819 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
42820 In-Reply-To: <3F90BF77.2010706@t2n.org>
42821 References: <3f9012b8.23176@achurch.org> <030801c3950f$3cb55270$6401a8c0@turby>
42822 <3F90BF77.2010706@t2n.org>
42823 Message-ID: <200310182149.18600.v13@it.teithe.gr>
42825 On Saturday 18 October 2003 07:20, Robert F Merrill wrote:
42827 > >Would have been nice if someone had mentioned that (about the
42828 > >ImmediatelySendAutokill) from the start. I would say the flag is
42829 > > misleading in title then, because I (and 8 other people on my staff --
42830 > > none of us are dummies, either) read that as meaning it will Immediately
42831 > > send the auto kill... "ImmediatelyUpdateServers" might be more fitting
42832 > > from an intuitive standpoint, not that I'm suggesting changing the name,
42833 > > but at least the documentation of it could be a bit more explicit IMHO.
42835 > It DOES immediately send the autokill. You just don't grasp the meaning
42836 > of sending the autokill.
42837 > It literally sends an AKILL (or TKL in the case of unreal) message to
42838 > the servers. At least unreal
42839 > and bahamut will then scan for matching clients and disconnect them,
42840 > however not all servers
42843 FYI bahamut doesn't do this. It will only do it whenever a new client that
42844 matches the akill connects to the server.
42846 i.e. if you set an akill for *.com noone will be disconnected untill a new
42847 client from *.com gets connected (at that moment, all matching clients will
42848 be killed). In the mean time, anyone from other domains can connect to the
42849 server without having any user killed.
42853 From diego at redesul.net Sat Oct 18 12:17:04 2003
42854 From: diego at redesul.net (Diego B. Contezini)
42855 Date: Sat Oct 23 23:10:08 2004
42856 Subject: [IRCServices Coding] CORE DUMPED! BUG!
42857 References: <3f8f9304.20227@achurch.org>
42858 Message-ID: <000e01c395ac$5b773b40$3cc8a8c0@angel>
42860 Andrew, you told me about debugging.. now i got it ;]
42861 here is the debugging:
42862 [Oct 18 16:05:31.288944 2003] debug: Sent: :ChanServ TOPIC #EMOCORE reffer
42863 1066055037 :1i?? Festival HARDcoCOREcore dia 25 de outubro em blumenau no
42864 rio bravo bar (proximo a resima agua verde), com as bandas: Zero Ltda
42865 (curitiba), Swallow the Waffle (bc), chymia(bnu), crazy frogs (lages),
42866 surpise set e slipper (bnu)...3 pila entrada inicio as 15:00 horas'
42867 [Oct 18 16:05:31.289032 2003] debug: Received: :|-Frango-| MODE
42868 #EMOCORE -oooooo CHoPP CbRS-oFF caroll BRYAN brunaH balsanelli
42869 Segmentation fault (core dumped)
42871 root@irc(/home/ircadmin/services/lib)# ls -la core.12631
42872 -rw------- 1 ircadmin ircadmin 47374336 Oct 18 16:05 core.12631
42875 continue on the next message......
42878 From diego at redesul.net Sat Oct 18 12:17:32 2003
42879 From: diego at redesul.net (Diego B. Contezini)
42880 Date: Sat Oct 23 23:10:08 2004
42881 Subject: [IRCServices Coding] CORE DUMPED... continue...
42882 References: <3f8f9304.20227@achurch.org>
42883 Message-ID: <001201c395ac$71b42210$3cc8a8c0@angel>
42885 #0 0x0804d830 in add_mode_with_params (md=0x806aa00, mode=111 'o',
42886 is_add=1, params=1, parambuf=0xbfffe280 "balsanelli",
42887 len=10) at actions.c:568
42888 568 md->params[md->nopmodes][len] = 0;
42890 #0 0x0804d830 in add_mode_with_params (md=0x806aa00, mode=111 'o',
42891 is_add=1, params=1, parambuf=0xbfffe280 "balsanelli",
42892 len=10) at actions.c:568
42894 #1 0x0804d342 in set_cmode (sender=0x81db058 "ChanServ", channel=0xa905d00)
42897 "balsanelli\000\b\025\225\002BWi??\022B\024\032\023Bi??i??i??i??\000\000\000
42898 \000\034 \006\bi??i??i??i??hi??i??i??i??i??i??i??\025\224\004B\034
42899 \006\b\000\000\000\000i??m\tBdi??\022Bi??q\a\b\000\000\000\000eR :\0037[
42900 \0034#\003di??\022B\000\000\000\000i??\037\006\bi??\037\006\bi??i??i??i??$i?
42901 ?\006Bi??i??i??i??\bi??i??i??\000\000\000\000Hi??i??i??\025\224\004B@\002\a\
42902 b8i??i??i??6\020\aBpi??i??i??@i??\006\b@\002\a\b\000\000\000\000i??<\023BLi?
42903 ?i??i??=S\004B\024\032\023B\001\020\000\000@i??\006\bhi??i??i??\204i??\006Bp
42904 i??i??i??i??\037\006\b"...
42909 args = 0xbfffe6d0 "RDcoCOREcorei??i??i??i??o"
42910 modes = 0xbfffeae2 ""
42911 modes_orig = 0xbfffeae0 "+o"
42912 md = (struct modedata *) 0x806aa00
42917 #2 0x400895ff in local_set_cumodes (c=0xa905d00, plusminus=43 '+', modes=1,
42918 nick=0xab7f2e8 "balsanelli") at check.c:432
42920 modestr = "o\000\000 de outubro em blumenau no rio bravo bar
42921 (proximo a resima agua verde), com as bandas: Zero
42922 L\v\000\000\000(curitiba), \000\000\000\000low the Waff\000\000\000\000bc),
42923 chymia(bnu), crazy frogs (lages), surpise set e slipper (bnu).."...
42925 #3 0x40088d74 in check_chan_user_modes (source=0xbfffeed0 "|-Frango-|",
42926 u=0xab34ff0, c=0xa905d00, oldmodes=1)
42928 user = (User *) 0xab7f2d8
42929 ci = (ChannelInfo *) 0xa571940
42933 #4 0x400820ed in do_channel_umode_change (source=0xbfffeed0 "|-Frango-|",
42934 c=0xa905d00, u=0xab34ff0, oldmodes=1)
42937 #5 0x0805890d in call_callback_5 (module=0x806a5c0, id=23, arg1=0xbfffeed0,
42938 arg2=0xa905d00, arg3=0xab34ff0, arg4=0x1,
42939 arg5=0x0) at modules.c:666
42940 cl = (CallbackList *) 0x8077cb8
42943 #6 0x0804edc8 in do_cumode (source=0xbfffeed0 "|-Frango-|", chan=0xa905d00,
42944 flag=1, add=0, nick=0xbfffecc9 "balsanelli")
42945 ---Type <return> to continue, or q <return> to quit---
42947 u = (struct c_userlist *) 0xab34ff0
42948 user = (User *) 0xab7f2d8
42950 #7 0x0804e97e in do_cmode (source=0xbfffeed0 "|-Frango-|", ac=0,
42951 av=0xa853130) at channels.c:302
42954 params = -1073746288
42955 chan = (Channel *) 0xa905d00
42958 modestr = 0xbfffec9e "-oooooo"
42959 #8 0x080557ff in m_mode (source=0xbfffeed0 "|-Frango-|", ac=8,
42960 av=0xa853110) at messages.c:101
42962 #9 0x0805920e in process () at process.c:133
42963 m = (Message *) 0x8067dd8
42965 "|-Frango-|\000\000G\000\000\000Y\e\205\n\t+\205\n\bi??i??i??i??i??\005\b@j\
42966 a\b\000\004\000\000i??\032\205\n\t\000\000\000@j\a\b\216j\a\b(i??i??i??qP\00
42969 "MODE\000\000\000i??8i??i??i??i??\005\b\000\000\000\000i??i??i??i??\000\000\
42970 000\000\000\000\000\000\001H\000\000Pi??i??i??\000Y\a\bVi??\005\b\207j\a\bP\
42971 e\205\n\t\000\000\000i??i??\005\b"
42973 "MODE\000#EMOCORE\000-oooooo\000CHoPP\000CbRS-oFF\000caroll\000BRYAN\000brun
42974 aH\000balsanelli\000 balsanelli\000\000ai\00314ser \0030]\00315=\00314-
42975 S\00315c\0030ri\00315p\00314t \00315\037v\0373.8 \003\000\00315\037v\0373.8
42976 \003\000\000\0003)\000\0006\037\002Pi??Ti??\00313\037\002]\037\002\0036i??i?
42977 ? \000i??Ti??\00313\037\002]\037\002\0036i??i?? \000\000\003\000\000r
42978 \003", '\0' <repeats 11 times>...
42979 s = 0xbfffec95 "#EMOCORE"
42981 av = (char **) 0xa853110
42982 #10 0x0805507d in readline_callback (s=0xa851ae0, param_unused=0x50) at
42985 #11 0x0805b617 in check_sockets () at sockets.c:491
42986 newline = 0xa851b58 "\nrct-sc.br irc.creativenet.com.br 0 3364349034
42987 :aNiNhHa[du]DoNaTeLo\n:Toh_Pensanu PART #ilheus\n:_LoKo_SuL_ SJOIN
42988 1063565447 #elias\n:_MoRgAnA_ PRIVMSG NickServ@services.redesul.net :set
42989 nomemo off\n:irc."...
42992 rfds = {fds_bits = {16, 0 <repeats 31 times>}}
42993 wfds = {fds_bits = {0 <repeats 32 times>}}
42994 tv = {tv_sec = 2, tv_usec = 980000}
42997 s = (Socket *) 0xa851ae0
42998 s2 = (Socket *) 0x0
42999 #12 0x0805538a in main (ac=3, av=0xbffff164, envp=0xbffff174) at main.c:266
43000 ---Type <return> to continue, or q <return> to quit---
43002 now_msec = 1348441861
43003 last_update = 1066500208
43004 last_check = 1348441182
43005 #13 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
43006 No symbol table info available.
43011 From saturn at jetirc.net Sat Oct 18 12:18:40 2003
43012 From: saturn at jetirc.net (Saturn)
43013 Date: Sat Oct 23 23:10:08 2004
43014 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
43015 References: <3f90afdf.23477@achurch.org>
43016 Message-ID: <003701c395ac$9ff9fd20$6401a8c0@turby>
43018 I thank you for finally just coming out and telling me what I needed to know
43019 in the first place. Had you stated that it has been discussed before (even
43020 without the hyperlinks) I would have at least known to go look through the
43021 archives. However, all you said (then repeated) was RTFM. I DID read it,
43022 once before I asked, and twice more, at your instruction, and found nothing
43023 to answer my questions. Had I known it had already been discussed, I would
43024 certainly have tried to locate the answer that way.
43026 Thank you to all the others who've posted to try and explain what I was
43027 missing in my understanding of this directive. I got it now, and realize
43028 where my misinterpretation was. Seems obvious now, but frankly that
43029 directive managed to fool myself and 8 of my staff into thinking of it as I
43030 have previously described. Regardless, my apologies for any harsh words...
43031 I do stand by the fact that Andrew could have responded with a bit less
43032 apathy to the concerns raised; with something a bit less useless than RTFM
43033 (twice! even AFTER I said I had, THAT'S what pissed me off), and I hope that
43034 maybe Andrew will remember this chain of events for the next time someone
43035 has a problem that might be immediately obvious to Andrew, but not the
43036 person with the problem. I think most of us KNOW by now to read the docs
43037 before asking questions; but if the question arises due to misinterpretation
43038 of the docs, how would reading them over and over help?
43040 Thank you all for your time.
43044 ----- Original Message -----
43045 From: "Andrew Church" <achurch@achurch.org>
43046 To: <ircservices-coding@ircservices.za.net>
43047 Sent: Friday, October 17, 2003 7:57 PM
43048 Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
43051 You know, I might have been more forgiving if this hadn't been gone
43052 over on this list (twice!) before:
43054 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/002305.html
43055 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/003215.html
43057 However, since you seem to have trouble both comprehending the
43058 documentation and reading the archives, I have added FAQ F.10 for your
43061 F.10. Services doesn't kill users matching a newly-added autokill mask even
43062 if ImmediatelySendAutokill is set.
43064 Services never kills users when a new autokill is added; the
43065 ImmediatelySendAutokill configuration directive only causes
43066 Services to send the autokill itself (that is, the user/host mask
43067 to prohibit new connections from) to the IRC servers on your
43068 network. This is a safety feature intended to limit the damage
43069 caused by a mistyped autokill.
43071 Note that some IRC servers will themselves kill users matching a
43072 newly-added autokill; this is unrelated to Services.
43075 achurch@achurch.org
43076 http://achurch.org/
43077 ------------------------------------------------------------------
43078 To unsubscribe or change your subscription options, visit:
43079 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
43082 From diego at redesul.net Sat Oct 18 14:38:17 2003
43083 From: diego at redesul.net (Diego B. Contezini)
43084 Date: Sat Oct 23 23:10:08 2004
43085 Subject: [IRCServices Coding] CORE DUMPED... Debuging
43086 Message-ID: <003f01c395c0$09a31cd0$3cc8a8c0@angel>
43088 If it helps, more lines up.. of debugging...
43091 ChanServ@services.redesul.net :op #manaus paulinhu-dissi-q-mi-ama
43092 [Oct 18 16:05:31.152195 2003] debug: Sent: :ChanServ NOTICE paulinhu-dissi-q-mi-ama :Permission denied.
43093 [Oct 18 16:05:31.152274 2003] debug: Received: :pRiCkLy SJOIN 1066501295 #Euevc
43094 [Oct 18 16:05:31.152353 2003] protocol/bahamut: debug: pRiCkLy SJOINs #Euevc
43095 [Oct 18 16:05:31.152490 2003] debug: Sent: :ChanServ MODE #EUeVC +o pRiCkLy
43096 [Oct 18 16:05:31.269153 2003] debug: Received: :Hellskitty PRIVMSG ChanServ@services.redesul.net :unban #EMOCORE
43097 [Oct 18 16:05:31.269425 2003] debug: Sent: :ChanServ NOTICE Hellskitty :Permission denied.
43098 [Oct 18 16:05:31.288596 2003] debug: Received: :|-Frango-| MODE #EMOCORE +stmipl 1
43099 [Oct 18 16:05:31.288768 2003] debug: Received: :|-Frango-| TOPIC #EMOCORE |-Frango-| 1066460927 :TakeOver by 14,1 -15=0[ 14He15l0lR15ai14ser 0]15=14- S15c0ri15p14t 15v3.8
43100 [Oct 18 16:05:31.288944 2003] debug: Sent: :ChanServ TOPIC #EMOCORE reffer 1066055037 :1??? Festival HARDcoCOREcore dia 25 de outubro em blumenau no rio bravo bar (proximo a resima agua verde), com as bandas: Zero Ltda (curitiba), Swallow the Waffle (bc), chymia(bnu), crazy frogs (lages), surpise set e slipper (bnu)...3 pila entrada inicio as 15:00 horas'
43101 [Oct 18 16:05:31.289032 2003] debug: Received: :|-Frango-| MODE #EMOCORE -oooooo CHoPP CbRS-oFF caroll BRYAN brunaH balsanelli
43102 Segmentation fault (core dumped)
43104 -------------- next part --------------
43105 An HTML attachment was scrubbed...
43106 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20031018/667c67fa/attachment-0003.htm
43107 From ballsy at mystical.net Mon Oct 20 08:19:44 2003
43108 From: ballsy at mystical.net (Ballsy)
43109 Date: Sat Oct 23 23:10:08 2004
43110 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
43111 In-Reply-To: <200310182149.18600.v13@it.teithe.gr>
43112 References: <3f9012b8.23176@achurch.org> <030801c3950f$3cb55270$6401a8c0@turby>
43113 <3F90BF77.2010706@t2n.org> <200310182149.18600.v13@it.teithe.gr>
43114 Message-ID: <6.0.0.22.0.20031020091611.01b47318@127.0.0.1>
43116 Yes, Bahamut will immediately kill users matching an Akill. It
43117 won't wait for another client from that host to connect. My setup of IRC
43118 Services 5.0.22 and bahamut-1.4.30 is doing it right now. As alluded to in
43119 a previous email, however, you may need to commented out EnableExclude in
43120 the services config to have this work.
43125 At 12:49 PM 18/10/2003, V13 wrote:
43126 >On Saturday 18 October 2003 07:20, Robert F Merrill wrote:
43128 > > >Would have been nice if someone had mentioned that (about the
43129 > > >ImmediatelySendAutokill) from the start. I would say the flag is
43130 > > > misleading in title then, because I (and 8 other people on my staff --
43131 > > > none of us are dummies, either) read that as meaning it will Immediately
43132 > > > send the auto kill... "ImmediatelyUpdateServers" might be more fitting
43133 > > > from an intuitive standpoint, not that I'm suggesting changing the name,
43134 > > > but at least the documentation of it could be a bit more explicit IMHO.
43136 > > It DOES immediately send the autokill. You just don't grasp the meaning
43137 > > of sending the autokill.
43138 > > It literally sends an AKILL (or TKL in the case of unreal) message to
43139 > > the servers. At least unreal
43140 > > and bahamut will then scan for matching clients and disconnect them,
43141 > > however not all servers
43144 >FYI bahamut doesn't do this. It will only do it whenever a new client that
43145 >matches the akill connects to the server.
43147 >i.e. if you set an akill for *.com noone will be disconnected untill a new
43148 >client from *.com gets connected (at that moment, all matching clients will
43149 >be killed). In the mean time, anyone from other domains can connect to the
43150 >server without having any user killed.
43153 >------------------------------------------------------------------
43154 >To unsubscribe or change your subscription options, visit:
43155 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
43159 From oska at mynet.com Tue Oct 21 22:24:34 2003
43160 From: oska at mynet.com (oska)
43161 Date: Sat Oct 23 23:10:08 2004
43162 Subject: [IRCServices Coding] "Re: Contents of IRCServices-Coding digest..."
43163 Message-ID: <HN58ED$I890Q9pEOh0UN3QcHkNkg1Bm2fHspFZq@mynet.com>
43165 An HTML attachment was scrubbed...
43166 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20031022/9c540c11/attachment-0003.html
43167 From laser at musichat.net Fri Oct 24 10:35:48 2003
43168 From: laser at musichat.net (laser@musichat.net)
43169 Date: Sat Oct 23 23:10:08 2004
43170 Subject: [IRCServices Coding] Il momento e' catartico
43171 Message-ID: <20031024173545.9ACA817038@snow.fingers.co.za>
43173 Ricevo e cortesemente inoltro,.... un premio per la genialit?
43174 hanno reso mitico un salva schermo scaricalo, "poesie catartiche", che non sai cosa ti perdi
43177 -------------- next part --------------
43178 An HTML attachment was scrubbed...
43179 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20031024/97501fa5/attachment-0003.htm
43180 From diego at redesul.net Fri Oct 24 16:03:05 2003
43181 From: diego at redesul.net (Diego B. Contezini)
43182 Date: Sat Oct 23 23:10:08 2004
43183 Subject: [IRCServices Coding] CORE DUMPED! BUG!
43184 References: <3f8f9304.20227@achurch.org> <000e01c395ac$5b773b40$3cc8a8c0@angel>
43185 Message-ID: <012e01c39a8b$531829d0$3cc8a8c0@angel>
43187 Andrew, have anything more of dumping/debugging that i can do/give for helps
43189 (if it helps, here its rh9.0, libc 2.3.2, linux x86, kernel 2.4.20-8,
43190 Pentium III 1ghz 512mb ram DDR)....
43200 From andrew at wtfigo.co.uk Tue Nov 4 02:15:03 2003
43201 From: andrew at wtfigo.co.uk (Andrew Kempe)
43202 Date: Sat Oct 23 23:10:08 2004
43203 Subject: [IRCServices Coding] test
43204 Message-ID: <E1AGyDD-0001mX-00@smtp.mailbox.co.uk>
43208 From diego at redesul.net Tue Nov 4 16:43:45 2003
43209 From: diego at redesul.net (Diego B. Contezini)
43210 Date: Sat Oct 23 23:10:08 2004
43211 Subject: [IRCServices Coding] CORE DUMPED! BUG!
43212 Message-ID: <014f01c3a335$e1e08dd0$3cc8a8c0@angel>
43214 I found a bug (occuring on the old-last vesion of ircservices -
43215 ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
43217 yes, 5.0.23 is the last.. but nothing has changed about the bug...
43219 here is the debugging:
43221 ChanServ@services.redesul.net :op #manaus paulinhu-dissi-q-mi-ama
43222 [Oct 18 16:05:31.152195 2003] debug: Sent: :ChanServ NOTICE
43223 paulinhu-dissi-q-mi-ama :Permission denied.
43224 [Oct 18 16:05:31.152274 2003] debug: Received: :pRiCkLy SJOIN 1066501295
43226 [Oct 18 16:05:31.152353 2003] protocol/bahamut: debug: pRiCkLy SJOINs #Euevc
43227 [Oct 18 16:05:31.152490 2003] debug: Sent: :ChanServ MODE #EUeVC +o pRiCkLy
43228 [Oct 18 16:05:31.269153 2003] debug: Received: :Hellskitty PRIVMSG
43229 ChanServ@services.redesul.net :unban #EMOCORE
43230 [Oct 18 16:05:31.269425 2003] debug: Sent: :ChanServ NOTICE Hellskitty
43231 :Permission denied.
43232 [Oct 18 16:05:31.288596 2003] debug: Received: :|-Frango-| MODE #EMOCORE
43234 [Oct 18 16:05:31.288768 2003] debug: Received: :|-Frango-| TOPIC #EMOCORE
43235 |-Frango-| 1066460927 :TakeOver by 14,1 -15=0[ 14He15l0lR15ai14ser 0]15=14-
43236 S15c0ri15p14t 15v3.8
43237 [Oct 18 16:05:31.288944 2003] debug: Sent: :ChanServ TOPIC #EMOCORE reffer
43238 1066055037 :1i?? Festival HARDcoCOREcore dia 25 de outubro em blumenau no
43239 rio bravo bar (proximo a resima agua verde), com as bandas: Zero Ltda
43240 (curitiba), Swallow the Waffle (bc), chymia(bnu), crazy frogs (lages),
43241 surpise set e slipper (bnu)...3 pila entrada inicio as 15:00 horas'
43242 [Oct 18 16:05:31.289032 2003] debug: Received: :|-Frango-| MODE
43243 #EMOCORE -oooooo CHoPP CbRS-oFF caroll BRYAN brunaH balsanelli
43244 Segmentation fault (core dumped)
43247 Debugging my core... i can found:
43248 #0 0x0804d830 in add_mode_with_params (md=0x806aa00, mode=111 'o',
43249 is_add=1, params=1, parambuf=0xbfffe280 "balsanelli",
43250 len=10) at actions.c:568
43251 568 md->params[md->nopmodes][len] = 0;
43253 #0 0x0804d830 in add_mode_with_params (md=0x806aa00, mode=111 'o',
43254 is_add=1, params=1, parambuf=0xbfffe280 "balsanelli",
43255 len=10) at actions.c:568
43257 #1 0x0804d342 in set_cmode (sender=0x81db058 "ChanServ", channel=0xa905d00)
43260 "balsanelli\000\b\025\225\002BWi??\022B\024\032\023Bi??i??i??i??\000\000\000
43261 \000\034 \006\bi??i??i??i??hi??i??i??i??i??i??i??\025\224\004B\034
43262 \006\b\000\000\000\000i??m\tBdi??\022Bi??q\a\b\000\000\000\000eR :\0037[
43263 \0034#\003di??\022B\000\000\000\000i??\037\006\bi??\037\006\bi??i??i??i??$i?
43264 ?\006Bi??i??i??i??\bi??i??i??\000\000\000\000Hi??i??i??\025\224\004B@\002\a\
43265 b8i??i??i??6\020\aBpi??i??i??@i??\006\b@\002\a\b\000\000\000\000i??<\023BLi?
43266 ?i??i??=S\004B\024\032\023B\001\020\000\000@i??\006\bhi??i??i??\204i??\006Bp
43267 i??i??i??i??\037\006\b"...
43272 args = 0xbfffe6d0 "RDcoCOREcorei??i??i??i??o"
43273 modes = 0xbfffeae2 ""
43274 modes_orig = 0xbfffeae0 "+o"
43275 md = (struct modedata *) 0x806aa00
43280 #2 0x400895ff in local_set_cumodes (c=0xa905d00, plusminus=43 '+', modes=1,
43281 nick=0xab7f2e8 "balsanelli") at check.c:432
43283 modestr = "o\000\000 de outubro em blumenau no rio bravo bar
43284 (proximo a resima agua verde), com as bandas: Zero
43285 L\v\000\000\000(curitiba), \000\000\000\000low the Waff\000\000\000\000bc),
43286 chymia(bnu), crazy frogs (lages), surpise set e slipper (bnu).."...
43288 #3 0x40088d74 in check_chan_user_modes (source=0xbfffeed0 "|-Frango-|",
43289 u=0xab34ff0, c=0xa905d00, oldmodes=1)
43291 user = (User *) 0xab7f2d8
43292 ci = (ChannelInfo *) 0xa571940
43296 #4 0x400820ed in do_channel_umode_change (source=0xbfffeed0 "|-Frango-|",
43297 c=0xa905d00, u=0xab34ff0, oldmodes=1)
43300 #5 0x0805890d in call_callback_5 (module=0x806a5c0, id=23, arg1=0xbfffeed0,
43301 arg2=0xa905d00, arg3=0xab34ff0, arg4=0x1,
43302 arg5=0x0) at modules.c:666
43303 cl = (CallbackList *) 0x8077cb8
43306 #6 0x0804edc8 in do_cumode (source=0xbfffeed0 "|-Frango-|", chan=0xa905d00,
43307 flag=1, add=0, nick=0xbfffecc9 "balsanelli")
43308 ---Type <return> to continue, or q <return> to quit---
43310 u = (struct c_userlist *) 0xab34ff0
43311 user = (User *) 0xab7f2d8
43313 #7 0x0804e97e in do_cmode (source=0xbfffeed0 "|-Frango-|", ac=0,
43314 av=0xa853130) at channels.c:302
43317 params = -1073746288
43318 chan = (Channel *) 0xa905d00
43321 modestr = 0xbfffec9e "-oooooo"
43322 #8 0x080557ff in m_mode (source=0xbfffeed0 "|-Frango-|", ac=8,
43323 av=0xa853110) at messages.c:101
43325 #9 0x0805920e in process () at process.c:133
43326 m = (Message *) 0x8067dd8
43328 "|-Frango-|\000\000G\000\000\000Y\e\205\n\t+\205\n\bi??i??i??i??i??\005\b@j\
43329 a\b\000\004\000\000i??\032\205\n\t\000\000\000@j\a\b\216j\a\b(i??i??i??qP\00
43332 "MODE\000\000\000i??8i??i??i??i??\005\b\000\000\000\000i??i??i??i??\000\000\
43333 000\000\000\000\000\000\001H\000\000Pi??i??i??\000Y\a\bVi??\005\b\207j\a\bP\
43334 e\205\n\t\000\000\000i??i??\005\b"
43336 "MODE\000#EMOCORE\000-oooooo\000CHoPP\000CbRS-oFF\000caroll\000BRYAN\000brun
43337 aH\000balsanelli\000 balsanelli\000\000ai\00314ser \0030]\00315=\00314-
43338 S\00315c\0030ri\00315p\00314t \00315\037v\0373.8 \003\000\00315\037v\0373.8
43339 \003\000\000\0003)\000\0006\037\002Pi??Ti??\00313\037\002]\037\002\0036i??i?
43340 ? \000i??Ti??\00313\037\002]\037\002\0036i??i?? \000\000\003\000\000r
43341 \003", '\0' <repeats 11 times>...
43342 s = 0xbfffec95 "#EMOCORE"
43344 av = (char **) 0xa853110
43345 #10 0x0805507d in readline_callback (s=0xa851ae0, param_unused=0x50) at
43348 #11 0x0805b617 in check_sockets () at sockets.c:491
43349 newline = 0xa851b58 "\nrct-sc.br irc.creativenet.com.br 0 3364349034
43350 :aNiNhHa[du]DoNaTeLo\n:Toh_Pensanu PART #ilheus\n:_LoKo_SuL_ SJOIN
43351 1063565447 #elias\n:_MoRgAnA_ PRIVMSG NickServ@services.redesul.net :set
43352 nomemo off\n:irc."...
43355 rfds = {fds_bits = {16, 0 <repeats 31 times>}}
43356 wfds = {fds_bits = {0 <repeats 32 times>}}
43357 tv = {tv_sec = 2, tv_usec = 980000}
43360 s = (Socket *) 0xa851ae0
43361 s2 = (Socket *) 0x0
43362 #12 0x0805538a in main (ac=3, av=0xbffff164, envp=0xbffff174) at main.c:266
43363 ---Type <return> to continue, or q <return> to quit---
43365 now_msec = 1348441861
43366 last_update = 1066500208
43367 last_check = 1348441182
43368 #13 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
43369 No symbol table info available.
43370 (gdb) info registers
43371 eax 0xd6b2bf8a -692928630
43372 ecx 0x806aa00 134654464
43373 edx 0x656e6173 1701732723
43374 ebx 0x42131a14 1108548116
43375 esp 0xbfffd910 0xbfffd910
43376 ebp 0xbfffe238 0xbfffe238
43377 esi 0x8075900 134699264
43378 edi 0xbffff050 -1073745840
43379 eip 0x804d830 0x804d830
43380 eflags 0x10282 66178
43390 root@irc(/home/ircadmin/services/lib)# ls -la core.12631
43391 -rw------- 1 ircadmin ircadmin 47374336 Oct 18 16:05 core.12631
43392 root@irc(/home/ircadmin/services)# ldd ircservices
43393 libdl.so.2 => /lib/libdl.so.2 (0x4001e000)
43394 libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
43395 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
43396 root@irc(/home/ircadmin/services)# uname -a
43397 Linux XXXXXX.xyz.0xdeadbeef 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686
43398 i686 i386 GNU/Linux
43399 root@irc(/home/ircadmin/services)# cat /etc/redhat-release
43400 Red Hat Linux release 9 (Shrike)
43401 root@irc(/home/ircadmin/services)# cat /proc/cpuinfo
43403 model name : Pentium III (Coppermine)
43406 cache size : 256 KB
43408 root@irc(/home/ircadmin/services)# free
43409 total used free shared buffers cached
43410 Mem: 513792 482248 31544 0 69492 274980
43412 I changed version of linux, runned it on 3 different machines, on
43413 slackware/redhat, pentiumIII, K5, P200.
43414 This bug is as older as i run services... dont know if its the same of the
43415 4.X (that i changed to 5.X to "solve" this bug), but from 5.12 to now, it
43416 continue happening... aways...
43417 Dont have a exactly time to happen, its insane... i think that its a
43418 coincidence of some commands that on the memory ends fucking some variable.
43419 if you want look the incidence, here its:
43420 root@irc(/home/ircadmin/services/lib)# ls -la core*
43422 -rw------- 1 ircadmin ircadmin 49025024 Oct 5 19:32 core.27214
43423 -rw------- 1 ircadmin ircadmin 45932544 Oct 5 21:01 core.14414
43424 -rw------- 1 ircadmin ircadmin 46948352 Oct 6 14:00 core.18016
43425 -rw------- 1 ircadmin ircadmin 45936640 Oct 11 04:30 core.1347
43426 -rw------- 1 ircadmin ircadmin 50479104 Oct 14 01:29 core.16481
43427 -rw------- 1 ircadmin ircadmin 44982272 Oct 15 13:54 core.22332
43428 -rw------- 1 ircadmin ircadmin 47374336 Oct 18 16:05 core.12631
43429 -rw------- 1 ircadmin ircadmin 48099328 Oct 19 14:16 core.5362
43430 -rw------- 1 ircadmin ircadmin 44863488 Oct 19 14:22 core.32708
43431 -rw------- 1 ircadmin ircadmin 45355008 Nov 1 15:13 core.28309
43432 -rw------- 1 ircadmin ircadmin 50360320 Nov 3 18:24 core.5160
43435 If it helps, here is the debugging of the last two cores, on gdb:
43438 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
43443 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
43446 chan = (Channel *) 0xa87d1e0
43447 s = 0x1f73746f <Address 0x1f73746f out of bounds>
43449 modestr = 0x1f73746f <Address 0x1f73746f out of bounds>
43450 #1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:680
43451 buf = "-imsl\000HA___\000\000\000\000\000W
43452 \022B\000\000\000L\000\000\000\000\000y\000nossaTZ\000\000\000\000\000\000yy
43453 yyA<\023B\001\000\000\000\bYy?Om\tBd
43454 \022BDq\a\bOUy?NO\006B\210o\a\b3\035\rB\024\032\023BAa\006B\003\000\000\000a
43455 Yy?\027\000\000\000\024\032\023B\024\032\023BTZ\000\000\004\000\000\000\005\
43456 000\000\000\210o\a\baYy?\030Yy?NO\006B\210o\a\baYy?\027\000\000\000$u\006B\2
43457 10o\a\bIo\a\b\vO\006B\024\032\023B\024\032\023B@\002\a\bHYy?$u\006B\200Yy?@o
43459 s = 0xbfffdc60 "-imsl"
43460 argv = {0xa87d1e8 "#soad",
43461 0x1f73746f <Address 0x1f73746f out of bounds>,
43462 0x5303200f <Address 0x5303200f out of bounds>,
43463 0x6c6c6568 <Address 0x6c6c6568 out of bounds>,
43464 0x4323203a <Address 0x4323203a out of bounds>,
43465 0x65746e65 <Address 0x65746e65 out of bounds>,
43466 0x65685372 <Address 0x65685372 out of bounds>,
43467 0x52426c6c <Address 0x52426c6c out of bounds>}
43469 ---Type <return> to continue, or q <return> to quit---
43472 #2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
43476 md = (struct modedata *) 0x0
43481 #3 0x080553a3 in main (ac=1, av=0xbfffe574, envp=0xbfffe57c) at main.c:269
43483 now_msec = -1555790286
43484 last_update = 1067890538
43485 last_check = 2739174210
43486 #4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
43487 No symbol table info available.
43491 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
43496 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
43499 chan = (Channel *) 0xa9be840
43500 s = 0xbf000000 <Address 0xbf000000 out of bounds>
43502 modestr = 0xbf000000 <Address 0xbf000000 out of bounds>
43503 #1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:680
43504 buf = "-imsl\000\a\b\000len\000\000\000\000W
43505 \022B3\035\rB\024\032\023BAa\006B\003\000\000\000
43506 oy?\027\000\000\000yyyyA<\023BTZ\000\000\004\000\000\000\005\000\000\000\210
43507 o\a\b oy?Xoy?NO\006B\210o\a\b
43508 oy?\027\000\000\000$u\006B\210o\a\bIo\a\b\vO\006B\024\032\023B\024\032\023B@
43509 \002\a\b\210oy?$u\006BAoy?@o\006\b@\002\a\b\000\000\000\000\024\032\023B@\00
43510 2\a\b?oy?6\020\aBaoy?@o\006\b@\002\a\b\000\000\000\000Aoy?I\037\006\b=S\004B
43511 \024\032\023B\001\020\000\000@o\006\b"...
43512 s = 0xbffff2e0 "-imsl"
43513 argv = {0xa9be848 "#zoera",
43514 0xbf000000 <Address 0xbf000000 out of bounds>, 0x0,
43515 0x806f240 "ircservices.log", 0x806f240 "ircservices.log",
43516 0x5a54 <Address 0x5a54 out of bounds>, 0x0,
43517 0xffffffff <Address 0xffffffff out of bounds>}
43521 #2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
43522 ---Type <return> to continue, or q <return> to quit---
43526 md = (struct modedata *) 0x0
43531 #3 0x080553a3 in main (ac=1, av=0xbffffbf4, envp=0xbffffbfc) at main.c:269
43533 now_msec = -1740061222
43534 last_update = 1067706282
43535 last_check = 2554904000
43536 #4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
43537 No symbol table info available.
43540 Im running it more a time on Screen to can get exactly where occur the bug
43541 (with -nofork -debug), to look for more examples of commands that causes
43543 if have something (more) that i can to add/do to helps on debugging, please,
43544 tell me.. i have the core (i cant send it, for secure reasons... have all my
43545 db on the core... ), but im open to helps anytime anywhere... with
43548 Thanks for all development, this is really a bealtifull software...
43549 (and sorry for my bad english)
43551 Diego B. Contezini aka destruct_ #irc.redesul.net
43555 From diego at redesul.net Tue Nov 4 16:46:53 2003
43556 From: diego at redesul.net (Diego B. Contezini)
43557 Date: Sat Oct 23 23:10:08 2004
43558 Subject: [IRCServices Coding] about.. CORE DUMPED! BUG!
43559 Message-ID: <01fa01c3a336$4e884220$3cc8a8c0@angel>
43561 If it helps, im using Bahamut here....
43564 From achurch at achurch.org Wed Nov 5 13:20:15 2003
43565 From: achurch at achurch.org (Andrew Church)
43566 Date: Sat Oct 23 23:10:08 2004
43567 Subject: [IRCServices Coding] Bug or misunderstood ?
43568 In-Reply-To: <000901c39496$71764f10$a37faec3@coder>
43569 Message-ID: <3fa87c99.57222@achurch.org>
43571 >Im using unreal ircd. When channel is empty and if channel owner joins
43572 >his/her registered channel it does
43573 >(ChanServ sets mode: +ntrq nick) but when channel is not empty and if
43574 >channel owner joins his/her registered channel it does (ChanServ sets mode:
43575 >+oq nick nick). As you see on the first one there is no +o and because of
43576 >this chanserv does not update the last_used time because chanserv is set to
43577 >update last_used time with +o (CUMODE_o) so channels drop while channel
43578 >owners use them. Is this a bug or my misunderstood ?
43580 This is a bug; I've fixed it for the next release, thanks for the
43581 report. As regards your other message, not setting the last-used time for
43582 +a/+q users is designed behavior (see section 3-2-1 of the manual: "`used'
43583 means that a user with auto-op privileges ... has entered the channel"), as
43584 well as unnecessary in typical channel settings (where +a users are a
43585 subset of +o users), but if you have any better suggestions on how to
43586 determine when a channel is being used by proper users as opposed to (for
43587 example) spammers or people just entering to see if the channel is
43588 available, I'm willing to listen.
43591 achurch@achurch.org
43592 http://achurch.org/
43594 From rg at tcslon.com Fri Nov 7 02:03:27 2003
43595 From: rg at tcslon.com (Russell Garrett)
43596 Date: Sat Oct 23 23:10:08 2004
43597 Subject: [IRCServices Coding] Badly punctuated parameter list in `#define'
43598 Message-ID: <MKEGJINFADFODDNOKEJCMELPEGAA.rg@tcslon.com>
43600 I'm getting this too - it's just started happening in 5.0.23:
43602 gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -fno-builtin-log
43603 -I.. -DCONVERT_DB -c convert-cygnus.c -o convert-cygnus.o
43604 convert-cygnus.c:35: badly punctuated parameter list in `#define'
43605 convert-cygnus.c:48: badly punctuated parameter list in `#define'
43607 gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
43612 From andrewk at isdial.net Tue Aug 26 02:43:45 2003
43613 From: andrewk at isdial.net (Andrew Kempe)
43614 Date: Sat Oct 23 23:10:08 2004
43615 Subject: [IRCServices Coding] test
43616 Message-ID: <005801c36bb6$85bbc080$1f0912ac@espotting.com>
43620 From us44ever at hotmail.com Thu Aug 28 09:45:48 2003
43621 From: us44ever at hotmail.com (us44ever .)
43622 Date: Sat Oct 23 23:10:08 2004
43623 Subject: [IRCServices Coding] Yet, another great suggestion
43624 Message-ID: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
43628 it would be really great to add another new line to the "/nickserv info"
43629 command, for example, when some one types: "/nickserv info nick", the
43630 following will be shown:
43632 ***************************
43634 -NickServ- nick is hello world
43636 -NickServ- Is online from: ~test@just.a.test.co.za
43638 -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
43640 -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
43642 -NickServ- Last quit message: anythinggggg
43644 -NickServ- Options: Kill protection, Security
43646 ***************************
43648 the new line I'm suggesting is something like:
43650 ***************************
43651 -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
43652 ***************************
43654 This will help our users to compare the time that user was last seen and the
43655 time right now *it's very important, many many of our users asked us for
43656 this option*, also it would even be more great to show how long last time
43657 the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003 GMT
43658 (last seen time was before: 10 days, 3hours and 24 sec ago).
43660 Note that I saw both of these features, in other services I don't remember
43661 there names (but they aren't as stable as ircservices5) (it was something
43662 like ptlink services, and magik II)
43664 That's all, I would really like to see it on the next version (or if you can
43665 show me how to do it, as I'm not a programmer)
43667 Many thanks to all of who developed IRCservices ...etc ...etc ...etc
43672 _________________________________________________________________
43673 Get MSN 8 and enjoy automatic e-mail virus protection.
43674 http://join.msn.com/?page=features/virus
43677 From aragon at phat.za.net Thu Aug 28 11:36:22 2003
43678 From: aragon at phat.za.net (Aragon Gouveia)
43679 Date: Sat Oct 23 23:10:08 2004
43680 Subject: [IRCServices Coding] Yet, another great suggestion
43681 In-Reply-To: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
43682 References: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
43683 Message-ID: <20030828183615.GB32204@phat.za.net>
43685 Or how about rather letting users decide what timezone they're in and
43686 services outputs all timestamps in their local time?
43689 | By us44ever . <us44ever@hotmail.com>
43690 | [ 2003-08-28 18:45 +0200 ]
43693 > it would be really great to add another new line to the "/nickserv info"
43694 > command, for example, when some one types: "/nickserv info nick", the
43695 > following will be shown:
43697 > ***************************
43699 > -NickServ- nick is hello world
43701 > -NickServ- Is online from: ~test@just.a.test.co.za
43703 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
43705 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
43707 > -NickServ- Last quit message: anythinggggg
43709 > -NickServ- Options: Kill protection, Security
43711 > ***************************
43713 > the new line I'm suggesting is something like:
43715 > ***************************
43716 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
43717 > ***************************
43719 > This will help our users to compare the time that user was last seen and
43720 > the time right now *it's very important, many many of our users asked us
43721 > for this option*, also it would even be more great to show how long last
43722 > time the user was seen (some thing like: Last seen time: Aug 28 15:51:14
43723 > 2003 GMT (last seen time was before: 10 days, 3hours and 24 sec ago).
43725 > Note that I saw both of these features, in other services I don't remember
43726 > there names (but they aren't as stable as ircservices5) (it was something
43727 > like ptlink services, and magik II)
43729 > That's all, I would really like to see it on the next version (or if you
43730 > can show me how to do it, as I'm not a programmer)
43732 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
43737 > _________________________________________________________________
43738 > Get MSN 8 and enjoy automatic e-mail virus protection.
43739 > http://join.msn.com/?page=features/virus
43741 > ------------------------------------------------------------------
43742 > To unsubscribe or change your subscription options, visit:
43743 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
43745 From saturn at jetirc.net Thu Aug 28 11:39:41 2003
43746 From: saturn at jetirc.net (Saturn)
43747 Date: Sat Oct 23 23:10:08 2004
43748 Subject: [IRCServices Coding] Yet, another great suggestion
43749 References: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
43750 <20030828183615.GB32204@phat.za.net>
43751 Message-ID: <003201c36d93$abf77fd0$6401a8c0@turby>
43753 Oooo now I like that option... have it default to a default timezone, set in
43754 the conf file, and give them the option of SETting a different UTC code
43755 (have it as GMT + or - x wheer x is the offset from UTC)... It may not
43756 sound liek much, but I bet people will use it, and what's more, it IS useful
43757 information, especially on international servers like mine.. we have people
43758 from all over the place, and we keep services set on Pacific time... but for
43759 those in, say, Belgium... that's not very helpful
43761 ----- Original Message -----
43762 From: "Aragon Gouveia" <aragon@phat.za.net>
43763 To: <ircservices-coding@ircservices.za.net>
43764 Sent: Thursday, August 28, 2003 11:36 AM
43765 Subject: Re: [IRCServices Coding] Yet, another great suggestion
43768 Or how about rather letting users decide what timezone they're in and
43769 services outputs all timestamps in their local time?
43772 | By us44ever . <us44ever@hotmail.com>
43773 | [ 2003-08-28 18:45 +0200 ]
43776 > it would be really great to add another new line to the "/nickserv info"
43777 > command, for example, when some one types: "/nickserv info nick", the
43778 > following will be shown:
43780 > ***************************
43782 > -NickServ- nick is hello world
43784 > -NickServ- Is online from: ~test@just.a.test.co.za
43786 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
43788 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
43790 > -NickServ- Last quit message: anythinggggg
43792 > -NickServ- Options: Kill protection, Security
43794 > ***************************
43796 > the new line I'm suggesting is something like:
43798 > ***************************
43799 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
43800 > ***************************
43802 > This will help our users to compare the time that user was last seen and
43803 > the time right now *it's very important, many many of our users asked us
43804 > for this option*, also it would even be more great to show how long last
43805 > time the user was seen (some thing like: Last seen time: Aug 28 15:51:14
43806 > 2003 GMT (last seen time was before: 10 days, 3hours and 24 sec ago).
43808 > Note that I saw both of these features, in other services I don't remember
43809 > there names (but they aren't as stable as ircservices5) (it was something
43810 > like ptlink services, and magik II)
43812 > That's all, I would really like to see it on the next version (or if you
43813 > can show me how to do it, as I'm not a programmer)
43815 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
43820 > _________________________________________________________________
43821 > Get MSN 8 and enjoy automatic e-mail virus protection.
43822 > http://join.msn.com/?page=features/virus
43824 > ------------------------------------------------------------------
43825 > To unsubscribe or change your subscription options, visit:
43826 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
43827 ------------------------------------------------------------------
43828 To unsubscribe or change your subscription options, visit:
43829 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
43833 From Craig at chatspike.net Thu Aug 28 14:29:54 2003
43834 From: Craig at chatspike.net (Craig McLure)
43835 Date: Sat Oct 23 23:10:08 2004
43836 Subject: [IRCServices Coding] Yet, another great suggestion
43837 Message-ID: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
43839 Please dont post to both the services main list, and the services coding list. Choose one, or the other, especially concidering i dont think this is a great suggestion either..
43841 /time services.chatspike.net
43842 [22:28]
\95\95\95 Date / time at services.chatspike.net- Thu Aug 28 17:28:57 2003 EDT
43846 /****************************************
43847 * Craig "FrostyCoolSlug" McLure
43848 ************* - SpamBox - **************
43849 * InspIRCd - http://www.inspircd.org
43850 * ChatSpike - http://www.chatspike.net
43851 * WinBot - http://www.winbot.co.uk
43852 ****************************************/
43854 /****************************************
43855 * From - us44ever . <us44ever@hotmail.com>
43856 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
43857 * Sent - 2003-08-28 @ 16:45:00
43858 * Subject - [IRCServices Coding] Yet, another great suggestion
43859 ****************************************/
43861 /****** - Begin Original Message - ******/
43865 >it would be really great to add another new line to the "/nickserv info"
43866 >command, for example, when some one types: "/nickserv info nick", the
43867 >following will be shown:
43869 >***************************
43871 >-NickServ- nick is hello world
43873 >-NickServ- Is online from: ~test@just.a.test.co.za
43875 >-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
43877 >-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
43879 >-NickServ- Last quit message: anythinggggg
43881 >-NickServ- Options: Kill protection, Security
43883 >***************************
43885 >the new line I'm suggesting is something like:
43887 >***************************
43888 >-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
43889 >***************************
43891 >This will help our users to compare the time that user was last seen and the
43892 >time right now *it's very important, many many of our users asked us for
43893 >this option*, also it would even be more great to show how long last time
43894 >the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003 GMT
43895 >(last seen time was before: 10 days, 3hours and 24 sec ago).
43897 >Note that I saw both of these features, in other services I don't remember
43898 >there names (but they aren't as stable as ircservices5) (it was something
43899 >like ptlink services, and magik II)
43901 >That's all, I would really like to see it on the next version (or if you can
43902 >show me how to do it, as I'm not a programmer)
43904 >Many thanks to all of who developed IRCservices ...etc ...etc ...etc
43909 >_________________________________________________________________
43910 >Get MSN 8 and enjoy automatic e-mail virus protection.
43911 >http://join.msn.com/?page=features/virus
43913 >------------------------------------------------------------------
43914 >To unsubscribe or change your subscription options, visit:
43915 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
43917 /******* - End Original Message - *******/
43922 From nothing at psychopat.org Thu Aug 28 14:57:31 2003
43923 From: nothing at psychopat.org (Marc-Andre A. Fuentes)
43924 Date: Sat Oct 23 23:10:08 2004
43925 Subject: [IRCServices Coding] BUG Report
43926 Message-ID: <001501c36daf$c8cba700$0101a8c0@house>
43928 We're having a small problem with suspended channel.
43930 we suspended channel #kavala, and someone has identified itself has the founder and apply a DROP to the channel.
43931 then we got a panic from the services and... crash.
43933 Also with suspended nick , when the suspencion expire, the services crash
43936 ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
43941 -------------- next part --------------
43942 An HTML attachment was scrubbed...
43943 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030828/1f31ccf5/attachment-0004.html
43944 From Craig at chatspike.net Thu Aug 28 15:24:36 2003
43945 From: Craig at chatspike.net (Craig McLure)
43946 Date: Sat Oct 23 23:10:08 2004
43947 Subject: [IRCServices Coding] BUG Report
43948 Message-ID: <20030828222401.JVQE12036.mta4-svc.business.ntl.com@i-br0ked-it>
43950 hmm.. what OS, compiler version etc are you using?
43952 after a test, i got the following:
43954 /cs id #abc 00376370
43955 -ChanServ- Channel #abc is suspended and may not be used or identified for.
43958 [23:20] -ChanServ- Channel is suspended and may not be used or identified for.
43960 only prob i got was it missed the channel name in the second message :)
43963 /****************************************
43964 * Craig "FrostyCoolSlug" McLure
43965 ************* - SpamBox - **************
43966 * InspIRCd - http://www.inspircd.org
43967 * ChatSpike - http://www.chatspike.net
43968 * WinBot - http://www.winbot.co.uk
43969 ****************************************/
43971 /****************************************
43972 * From - Marc-Andre A. Fuentes <nothing@psychopat.org>
43973 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
43974 * Sent - 2003-08-28 @ 18:00:00
43975 * Subject - [IRCServices Coding] BUG Report
43976 ****************************************/
43978 /****** - Begin Original Message - ******/
43980 >We're having a small problem with suspended channel.
43982 >we suspended channel #kavala, and someone has identified itself has the founder and apply a DROP to the channel.
43983 >then we got a panic from the services and... crash.
43985 >Also with suspended nick , when the suspencion expire, the services crash
43988 >ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
43993 >------------------------------------------------------------------
43994 >To unsubscribe or change your subscription options, visit:
43995 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
43997 /******* - End Original Message - *******/
44002 From saturn at jetirc.net Thu Aug 28 17:13:48 2003
44003 From: saturn at jetirc.net (Saturn)
44004 Date: Sat Oct 23 23:10:08 2004
44005 Subject: [IRCServices Coding] AKill suggestion
44006 References: <2C31F186-CDEE-11D7-979C-0003938D6866@mac.com>
44007 Message-ID: <009001c36dc2$64b56b80$6401a8c0@turby>
44009 Would it be possible to have it announce to the user when they are akilled,
44010 either the expiry date and time, or "Expires in 3days, 4hours, 6minutes" or
44011 something similar. I find that usually we just have to do 24hour bans, but
44012 the user has no way to know when the ban was set, and when it expires...
44014 Just an idea... I now await the half dozen people who will proceed to tell
44015 me how stupid my idea is....
44022 From playa at dreamchat.org Thu Aug 28 20:46:19 2003
44023 From: playa at dreamchat.org (playa)
44024 Date: Sat Oct 23 23:10:08 2004
44025 Subject: [IRCServices Coding] Yet, another great suggestion
44026 In-Reply-To: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
44027 References: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
44028 Message-ID: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
44030 Is this /time command only supposed to work via RAW? Cause when i type
44031 /time services.dreamchat.org i get No Such User, but if i do /raw time
44032 services.dreamchat.org, it works. Just wondering if its just me, or if
44033 its supposed to be that way.
44035 > Please dont post to both the services main list, and the services coding
44036 > list. Choose one, or the other, especially concidering i dont think this
44037 > is a great suggestion either..
44039 > /time services.chatspike.net
44040 > [22:28] ??? Date / time at services.chatspike.net- Thu Aug 28 17:28:57
44045 > /****************************************
44046 > * Craig "FrostyCoolSlug" McLure
44047 > ************* - SpamBox - **************
44048 > * InspIRCd - http://www.inspircd.org
44049 > * ChatSpike - http://www.chatspike.net
44050 > * WinBot - http://www.winbot.co.uk
44051 > ****************************************/
44053 > /****************************************
44054 > * From - us44ever . <us44ever@hotmail.com>
44055 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
44056 > * Sent - 2003-08-28 @ 16:45:00
44057 > * Subject - [IRCServices Coding] Yet, another great suggestion
44058 > ****************************************/
44060 > /****** - Begin Original Message - ******/
44064 >>it would be really great to add another new line to the "/nickserv info"
44065 >>command, for example, when some one types: "/nickserv info nick", the
44066 >>following will be shown:
44068 >>***************************
44070 >>-NickServ- nick is hello world
44072 >>-NickServ- Is online from: ~test@just.a.test.co.za
44074 >>-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
44076 >>-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
44078 >>-NickServ- Last quit message: anythinggggg
44080 >>-NickServ- Options: Kill protection, Security
44082 >>***************************
44084 >>the new line I'm suggesting is something like:
44086 >>***************************
44087 >>-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
44088 >>***************************
44090 >>This will help our users to compare the time that user was last seen and
44092 >>time right now *it's very important, many many of our users asked us for
44093 >>this option*, also it would even be more great to show how long last time
44094 >>the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003
44096 >>(last seen time was before: 10 days, 3hours and 24 sec ago).
44098 >>Note that I saw both of these features, in other services I don't
44100 >>there names (but they aren't as stable as ircservices5) (it was something
44101 >>like ptlink services, and magik II)
44103 >>That's all, I would really like to see it on the next version (or if you
44105 >>show me how to do it, as I'm not a programmer)
44107 >>Many thanks to all of who developed IRCservices ...etc ...etc ...etc
44112 >>_________________________________________________________________
44113 >>Get MSN 8 and enjoy automatic e-mail virus protection.
44114 >>http://join.msn.com/?page=features/virus
44116 >>------------------------------------------------------------------
44117 >>To unsubscribe or change your subscription options, visit:
44118 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
44120 > /******* - End Original Message - *******/
44124 > ------------------------------------------------------------------
44125 > To unsubscribe or change your subscription options, visit:
44126 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
44133 Network Founder/CEO
44134 DreamChat IRC Network - irc.dreamchat.org
44135 http://www.dreamchat.org
44138 From quension at mac.com Thu Aug 28 21:13:48 2003
44139 From: quension at mac.com (Trevor Talbot)
44140 Date: Sat Oct 23 23:10:09 2004
44141 Subject: [IRCServices Coding] Yet, another great suggestion
44142 In-Reply-To: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
44143 Message-ID: <0F823090-D9D7-11D7-8513-0003938D6866@mac.com>
44145 On Thursday, Aug 28, 2003, at 20:46 US/Pacific, playa wrote:
44147 > Is this /time command only supposed to work via RAW? Cause when i
44148 > type /time services.dreamchat.org i get No Such User, but if i do /raw
44149 > time services.dreamchat.org, it works. Just wondering if its just me,
44150 > or if its supposed to be that way.
44152 That's a client thing. Some clients might alias /time as a CTCP TIME
44153 for a specific user, or similar.
44158 From r-krisztian at softhome.net Thu Aug 28 22:12:51 2003
44159 From: r-krisztian at softhome.net (Krisztian Romek)
44160 Date: Sat Oct 23 23:10:09 2004
44161 Subject: [IRCServices Coding] Yet, another great suggestion
44162 In-Reply-To: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
44163 References: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
44164 <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
44165 Message-ID: <200308290713.29423.r-krisztian@softhome.net>
44167 > Is this /time command only supposed to work via RAW? Cause when i type
44168 > /time services.dreamchat.org i get No Such User, but if i do /raw time
44169 > services.dreamchat.org, it works. Just wondering if its just me, or if
44170 > its supposed to be that way.
44172 Some clients use stupid aliases for CTCP commands, for example:
44174 /version <nick> = /CTCP <nick> VERSION,
44175 /time <nick> = /CTCP <nick> TIME,
44176 /finger <nick> = /CTCP <nick> TIME
44178 This is why nothing works the way you expected.
44182 r-krisztian@softhome.net
44185 From us44ever at hotmail.com Fri Aug 29 13:02:19 2003
44186 From: us44ever at hotmail.com (us44ever .)
44187 Date: Sat Oct 23 23:10:09 2004
44188 Subject: [IRCServices Coding] AKill suggestion
44189 Message-ID: <Sea1-F108cM3oryKFRJ0000eb75@hotmail.com>
44191 Pretty good idea, specially is it would be implemented as an option (because
44192 some admins might won't like the idea of displaying the time of when the
44193 akill will expire to the user who has been akilled).
44195 _________________________________________________________________
44196 Help protect your PC: Get a free online virus scan at McAfee.com.
44197 http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
44200 From us44ever at hotmail.com Fri Aug 29 13:09:51 2003
44201 From: us44ever at hotmail.com (us44ever .)
44202 Date: Sat Oct 23 23:10:09 2004
44203 Subject: [IRCServices Coding] Yet, another great suggestion
44204 Message-ID: <Sea1-F127z33hqSnMGE000094b3@hotmail.com>
44207 Since most people want to see this feature(s) in the next version, it would
44208 be great to implement it as an optional feature , where it can be disabled
44209 from the .conf file(s) or enable it easily. I don't think that there is
44210 anything that the authors will lose if this feature can be added, in fact,
44211 it will add another nice feature to the features list of IRCservices5.
44213 _________________________________________________________________
44214 Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
44215 using MSN Messenger http://entertainment.msn.com/imastar
44218 From Craig at chatspike.net Fri Aug 29 13:41:59 2003
44219 From: Craig at chatspike.net (Craig McLure)
44220 Date: Sat Oct 23 23:10:09 2004
44221 Subject: [IRCServices Coding] Yet, another great suggestion
44222 Message-ID: <20030829204143.NNNT26404.mta1-svc.business.ntl.com@i-br0ked-it>
44224 I'll ask again.. can you please stop posting to both the IRCServices mailing list, and the IRCd coding mailing list, getting your mail 2ce is beginning to annoy me.
44226 And i'll Quote Elijah:
44228 "Except it's already been said in the FAQ that it's not going to happen, and
44229 if that made it into the FAQ it would seem the answer is frequently going to
44233 /****************************************
44234 * Craig "FrostyCoolSlug" McLure
44235 ************* - SpamBox - **************
44236 * InspIRCd - http://www.inspircd.org
44237 * ChatSpike - http://www.chatspike.net
44238 * WinBot - http://www.winbot.co.uk
44239 ****************************************/
44241 /****************************************
44242 * From - us44ever . <us44ever@hotmail.com>
44243 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
44244 * Sent - 2003-08-29 @ 20:09:00
44245 * Subject - Re: [IRCServices Coding] Yet, another great suggestion
44246 ****************************************/
44248 /****** - Begin Original Message - ******/
44250 >Since most people want to see this feature(s) in the next version, it would
44251 >be great to implement it as an optional feature , where it can be disabled
44252 >from the .conf file(s) or enable it easily. I don't think that there is
44253 >anything that the authors will lose if this feature can be added, in fact,
44254 >it will add another nice feature to the features list of IRCservices5.
44256 >_________________________________________________________________
44257 >Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
44258 >using MSN Messenger http://entertainment.msn.com/imastar
44260 >------------------------------------------------------------------
44261 >To unsubscribe or change your subscription options, visit:
44262 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
44265 /******* - End Original Message - *******/
44270 From Craig at chatspike.net Fri Aug 29 13:43:24 2003
44271 From: Craig at chatspike.net (Craig McLure)
44272 Date: Sat Oct 23 23:10:09 2004
44273 Subject: [IRCServices Coding] AKill suggestion
44274 Message-ID: <20030829204311.GHCL29825.mta5-svc.business.ntl.com@i-br0ked-it>
44276 its a stupid idea!!! :p
44278 j/k.. I think its a great idea.. i'd rather have services telling users when their akills expire, than them spamming my mailbox with 'when does my akill expire?' every 20mins :p
44280 /****************************************
44281 * Craig "FrostyCoolSlug" McLure
44282 ************* - SpamBox - **************
44283 * InspIRCd - http://www.inspircd.org
44284 * ChatSpike - http://www.chatspike.net
44285 * WinBot - http://www.winbot.co.uk
44286 ****************************************/
44288 /****************************************
44289 * From - Saturn <saturn@jetirc.net>
44290 * To - IRC Services Coding Mailing List <ircservices-coding@ircservices.za.net>
44291 * Sent - 2003-08-28 @ 17:13:00
44292 * Subject - [IRCServices Coding] AKill suggestion
44293 ****************************************/
44295 /****** - Begin Original Message - ******/
44297 >Would it be possible to have it announce to the user when they are akilled,
44298 >either the expiry date and time, or "Expires in 3days, 4hours, 6minutes" or
44299 >something similar. I find that usually we just have to do 24hour bans, but
44300 >the user has no way to know when the ban was set, and when it expires...
44302 >Just an idea... I now await the half dozen people who will proceed to tell
44303 >me how stupid my idea is....
44309 >------------------------------------------------------------------
44310 >To unsubscribe or change your subscription options, visit:
44311 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
44313 /******* - End Original Message - *******/
44318 From admin at nevernet.net Fri Aug 29 13:48:01 2003
44319 From: admin at nevernet.net (Elijah)
44320 Date: Sat Oct 23 23:10:09 2004
44321 Subject: [IRCServices Coding] Yet, another great suggestion
44322 In-Reply-To: <20030829204143.NNNT26404.mta1-svc.business.ntl.com@i-br0ked-it>
44323 Message-ID: <008f01c36e6e$83158770$436a3a44@slytherin>
44327 -----Original Message-----
44328 From: ircservices-coding-bounces@ircservices.za.net
44329 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of Craig
44331 Sent: Friday, August 29, 2003 4:41 PM
44332 To: IRC Services Coding Mailing List
44333 Subject: Re: Re: [IRCServices Coding] Yet, another great suggestion
44336 I'll ask again.. can you please stop posting to both the IRCServices mailing
44337 list, and the IRCd coding mailing list, getting your mail 2ce is beginning
44340 And i'll Quote Elijah:
44342 "Except it's already been said in the FAQ that it's not going to happen, and
44343 if that made it into the FAQ it would seem the answer is frequently going to
44348 From us44ever at hotmail.com Fri Aug 29 16:59:31 2003
44349 From: us44ever at hotmail.com (us44ever .)
44350 Date: Sat Oct 23 23:10:09 2004
44351 Subject: [IRCServices Coding] Yet, another great suggestion
44352 Message-ID: <Sea1-F30z1oyZF58m3O00035b82@hotmail.com>
44354 woops, ok sorry I thought the two e-mails is completely different.
44357 >From: "Craig McLure" <Craig@chatspike.net>
44358 >Reply-To: IRC Services Coding Mailing List
44359 ><ircservices-coding@ircservices.za.net>
44360 >To: IRC Services Coding Mailing List
44361 ><ircservices-coding@ircservices.za.net>
44362 >Subject: Re: Re: [IRCServices Coding] Yet, another great suggestion
44363 >Date: Fri, 29 Aug 2003 21:41:23 +0000
44365 >I'll ask again.. can you please stop posting to both the IRCServices
44366 >mailing list, and the IRCd coding mailing list, getting your mail 2ce is
44367 >beginning to annoy me.
44369 >And i'll Quote Elijah:
44371 >"Except it's already been said in the FAQ that it's not going to happen,
44373 >if that made it into the FAQ it would seem the answer is frequently going
44378 >/****************************************
44379 > * Craig "FrostyCoolSlug" McLure
44380 > ************* - SpamBox - **************
44381 > * InspIRCd - http://www.inspircd.org
44382 > * ChatSpike - http://www.chatspike.net
44383 > * WinBot - http://www.winbot.co.uk
44384 > ****************************************/
44386 >/****************************************
44387 > * From - us44ever . <us44ever@hotmail.com>
44388 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
44389 > * Sent - 2003-08-29 @ 20:09:00
44390 > * Subject - Re: [IRCServices Coding] Yet, another great suggestion
44391 > ****************************************/
44393 >/****** - Begin Original Message - ******/
44395 > >Since most people want to see this feature(s) in the next version, it
44397 > >be great to implement it as an optional feature , where it can be
44399 > >from the .conf file(s) or enable it easily. I don't think that there is
44400 > >anything that the authors will lose if this feature can be added, in
44402 > >it will add another nice feature to the features list of IRCservices5.
44404 > >_________________________________________________________________
44405 > >Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
44406 > >using MSN Messenger http://entertainment.msn.com/imastar
44408 > >------------------------------------------------------------------
44409 > >To unsubscribe or change your subscription options, visit:
44410 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
44413 >/******* - End Original Message - *******/
44417 >------------------------------------------------------------------
44418 >To unsubscribe or change your subscription options, visit:
44419 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
44421 _________________________________________________________________
44422 MSN 8: Get 6 months for $9.95/month. http://join.msn.com/?page=dept/dialup
44425 From simorgh at dataphone.se Sat Aug 30 08:27:11 2003
44426 From: simorgh at dataphone.se (Ali Simorgh)
44427 Date: Sat Oct 23 23:10:09 2004
44428 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
44429 In-Reply-To: <MKEGJINFADFODDNOKEJCMEEADPAA.rg@tcslon.com>
44430 Message-ID: <Pine.GSO.4.31.0308301716410.15629-100000@nikson.dataphone.se>
44433 I run ircservices 5.0.21 on FreeBSD 4.8-STABLE. and Ultimate 3.*
44434 I get this in logfile:
44436 [Aug 30 10:51:19 2003] unknown message from server
44437 (NETCTRL 0 0 0 0 0 0 0 0 0 0 0 0 0)
44438 [Aug 30 10:51:19 2003] user: New maximum user count: 1
44439 [Aug 30 10:51:19 2003] unknown message from server
44440 (:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
44441 [Aug 30 10:51:19 2003] user: New maximum user count: 2
44442 [Aug 30 10:51:19 2003] unknown message from server
44443 (:irc.MyNet.Net SETHOST pedarkhAnde 6b45bb2.26d9672f.dataphone.se)
44444 [Aug 30 10:56:18 2003] mail/sendmail:
44445 /usr/sbin/sendmail exited with code 25600
44446 [Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
44447 registration (Simorgh)
44449 and how can I do so that nickserv dont show the realhost of a user in
44456 ______________________________________________________
44457 Many of life's failures are people who did not realize
44458 how close they were to success when they gave up.
44460 ______________________________________________________
44465 From jskam at shaw.ca Sat Aug 30 11:34:35 2003
44466 From: jskam at shaw.ca (Jeffery Kam)
44467 Date: Sat Oct 23 23:10:09 2004
44468 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
44469 In-Reply-To: <Pine.GSO.4.31.0308301716410.15629-100000@nikson.dataphone.se>
44470 Message-ID: <000001c36f25$58464860$f64f9144@weed>
44472 "and how can I do so that nickserv dont show the realhost of a user in
44473 'ns info nick all'"
44475 This would be a great feature for sure. I know on my network, there is
44476 a custom user mode +d, which will disguise a user's host in a /whois
44477 reply, but services info doesn't show it disguised unless the HIDE
44482 From achurch at achurch.org Sat Aug 30 16:17:44 2003
44483 From: achurch at achurch.org (Andrew Church)
44484 Date: Sat Oct 23 23:10:09 2004
44485 Subject: [IRCServices Coding] OP/Voice upon identify
44486 In-Reply-To: <Pine.GSO.4.31.0308211027350.6118-100000@nikson.dataphone.se>
44487 Message-ID: <3f513092.01677@achurch.org>
44489 Needless complexity. If you don't want yourself autoopped, then don't
44490 be an auto-op. It's that simple.
44493 achurch@achurch.org
44494 http://achurch.org/
44497 >Its nice with this option. but I dont se any set command that ChanServ
44498 >wont automatically op or voice you in any channel.
44501 > SET NOAUTO ON|OFF
44502 > When NOAUTO is on, ChanServ will not
44503 > automatically op or voice you in any channels.
44505 >Maybe some user(s) wont get auto op/voice then they can set this option ON
44506 >but it sould be OFF in default.
44513 > ______________________________________________________
44514 > Many of life's failures are people who did not realize
44515 > how close they were to success when they gave up.
44517 > ______________________________________________________
44520 >On Sun, 17 Aug 2003, Russell Garrett wrote:
44522 >> Eh? This has been implemented since IRCServices 5a31.
44526 >> > I wonder if its possible to make some modification that:
44527 >> > when someone has already joined a few channels, and then identifies
44528 >> > to its nickname, chanserv gives Voice and/or Op to the user is s/he
44529 >> > is in the channel list (+o; aop or above & +v when vop)
44531 >> > this is very usefull to not privmsg chanserv for every op or voice
44532 >> > request, when user has not identified to its nick before joining
44535 >> > Thanks for any help
44537 >> ------------------------------------------------------------------
44538 >> To unsubscribe or change your subscription options, visit:
44539 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
44542 >------------------------------------------------------------------
44543 >To unsubscribe or change your subscription options, visit:
44544 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
44546 From rayfordp at mhcable.com Thu Nov 13 17:08:11 2003
44547 From: rayfordp at mhcable.com (Rayford Pomeroy)
44548 Date: Sat Oct 23 23:10:09 2004
44549 Subject: [IRCServices Coding] Akill type?
44550 Message-ID: <20031114062307.4856C170E7@snow.fingers.co.za>
44552 Where is the akill type used in some of the AutoKill functions listed in the
44553 modules/database/readme file defined?
44555 ________________________________________________
44556 Message sent using MHCABLE Webmail
44559 From arathorn at theonering.net Fri Nov 14 14:32:39 2003
44560 From: arathorn at theonering.net (Arathorn)
44561 Date: Sat Oct 23 23:10:09 2004
44562 Subject: [IRCServices Coding] [PATCH] Fix of rogue unescaped backtick in
44563 configure in 5.0.24
44564 In-Reply-To: <Pine.LNX.4.56L0.0311122252050.7240@phoenix.siarch.net>
44565 References: <3fb090ea.04554@achurch.org>
44566 <Pine.LNX.4.56L0.0311122252050.7240@phoenix.siarch.net>
44567 Message-ID: <Pine.LNX.4.56L0.0311142227470.15812@phoenix.siarch.net>
44569 Well, I just had another chance to look more carefully at the configure
44570 script - looks like there's a rogue unescaped backtick in the deprecation
44571 warning text block; I hope the attached patch will save others unfortunate
44572 enough to still be running 2.95 from trauma in ./configure :)
44574 diff -ur ircservices-5.0.24-orig/configure ircservices-5.0.24/configure
44575 --- ircservices-5.0.24-orig/configure Wed Nov 5 01:46:59 2003
44576 +++ ircservices-5.0.24/configure Fri Nov 14 17:04:08 2003
44577 @@ -875,7 +875,7 @@
44578 elif test $vmajor -lt 3 -a $version != 2.95.3 || test $vmajor = 3 -a $vminor -lt 2 ; then
44581 -WARNING: Your version of GCC was detected as `$version'. As of Services
44582 +WARNING: Your version of GCC was detected as \`$version'. As of Services
44583 5.0.23, versions of GCC earlier than 3.2, other than 2.95.3,
44584 have been deprecated. This and future releases of Services 5.0
44585 will still work, though some error messages will lose
44588 ________________________________________________________________
44589 Matthew Hodgson arathorn@theonering.net Tel: +44 7968 722968
44590 Arathorn: Co-Sysadmin, TheOneRing.net?
44592 On Wed, 12 Nov 2003, Arathorn wrote:
44596 > Just tried to upgrade to 5.0.24 on my Debian Woody production server
44597 > running gcc 2.95.4. I appreciate that this is <3.2 and !=2.95.3, but I
44598 > didn't expect ./configure to completely keel over on me (and hoped to be
44599 > able to use a -force configure option of some kind to get it to compile
44602 > Here's the stderr & stdio - the configure.log is attached:
44604 > pe1650 18# gcc -v
44605 > Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
44606 > gcc version 2.95.4 20011002 (Debian prerelease)
44607 > pe1650 19# ./configure -ignore-cache
44609 > Beginning IRC Services configuration.
44611 > In what directory do you want the binaries to be installed?
44612 > Press Return for the default, or enter a new value.
44613 > [/usr/local/sbin] /usr/local/sbin/ircservices-5.0.24-unr
44615 > Where do you want the data files to be installed?
44616 > [/usr/local/sbin/ircservices-5.0.24-unr/lib] /usr/local/lib/ircservices-5.0
44618 > End of interactive configuration.
44620 > Checking sanity of /bin/sh... high.
44621 > Searching for a suitable compiler... ./configure: command substitution:
44622 > line 1: unexpected EOF while looking for matching `''
44623 > ./configure: command substitution: line 8: syntax error: unexpected end of file
44625 > WARNING: Your version of GCC was detected as Press Enter to continue:
44629 > Testing default compiler flags ()... no luck! Using no flags.
44630 > If you know what flags you want, use the -cflags option to configure.
44631 > Let's see what libraries we need...
44632 > Checking if we can use dynamic modules... no.
44633 > Checking whether ranlib exists... yes.
44634 > Looking for an 8-bit integer type...
44635 > *** WHOA THERE! ***
44637 > We suddenly couldn't compile using the C compiler we already tested!
44638 > The command line we used was:
44639 > conf-tmp/test.c -o conf-tmp/test
44640 > Please try to fix this; if you can't, mail achurch@achurch.org
44641 > with information about your system, the output from this script,
44642 > and the `configure.log' file generated by this script.
44644 > ________________________________________________________________
44645 > Matthew Hodgson arathorn@theonering.net Tel: +44 7968 722968
44646 > Arathorn: Co-Sysadmin, TheOneRing.net?
44648 > On Tue, 11 Nov 2003, Andrew Church wrote:
44650 > > Services 5.0.24 has been released, and can be downloaded from:
44652 > > ftp://ftp.esper.net/ircservices/ (USA, California)
44654 > > d8f808b04744e9db365ebb23f7d04078 ircservices-5.0.24.tar.gz
44655 > > e2415db90e2c9f3391268b8d48ef40d1 ircservices-5.0.24.diff.gz
44656 > > 07d0785f095de88f87de8b4d97024558 ircservices-5.0.24-1.i386.rpm
44657 > > 0235352278f534a818699281fcc7ba83 ircservices_5.0.24-1_i386.deb
44659 > > ftp.ircservices.za.net and the other mirrors should have it shortly.
44661 > > This release includes a workaround for those who were unable to
44662 > > compile 5.0.23; however, please note that being unable to compile means
44663 > > that your compiler is outdated, and you should upgrade it (or have the
44664 > > server administrator upgrade it) as soon as possible. Support for such
44665 > > compilers will be removed entirely in a future version.
44667 > > Changes in version 5.0.24
44668 > > -------------------------
44669 > > 2003/11/11 Fixed a warning in convert-db compilation.
44670 > > 2003/11/11 Fixed bugs in convert-db causing some nickname and channel
44671 > > settings (timezone, language, channel and memo limits)
44672 > > to not be initialized properly.
44673 > > 2003/11/11 Added -tzfile, -no-timezones, and -reset-memo-limits
44674 > > options to the Cygnus database converter in convert-db.
44675 > > 2003/11/05 Databases can now be exported in XML from the command line
44676 > > (-export option).
44677 > > 2003/11/05 GCC versions earlier than 3.2 (except 2.95.3) are now
44678 > > deprecated. Variadic macros workaround added for
44679 > > problem reported by Ali Sor <alisor@softhome.net>
44680 > > 2003/11/05 Channel last-used time is now updated properly for the
44681 > > first user to enter the channel if the user has auto-op
44682 > > privileges. Reported by <saman@alkol.org>
44684 > > --Andrew Church
44685 > > achurch@achurch.org
44686 > > http://achurch.org/
44687 > > ------------------------------------------------------------------
44688 > > To unsubscribe or change your subscription options, visit:
44689 > > http://www.ircservices.za.net/mailman/listinfo/ircservices
44692 -------------- next part --------------
44693 diff -ur ircservices-5.0.24-orig/configure ircservices-5.0.24/configure
44694 --- ircservices-5.0.24-orig/configure Wed Nov 5 01:46:59 2003
44695 +++ ircservices-5.0.24/configure Fri Nov 14 17:04:08 2003
44696 @@ -875,7 +875,7 @@
44697 elif test $vmajor -lt 3 -a $version != 2.95.3 || test $vmajor = 3 -a $vminor -lt 2 ; then
44700 -WARNING: Your version of GCC was detected as `$version'. As of Services
44701 +WARNING: Your version of GCC was detected as \`$version'. As of Services
44702 5.0.23, versions of GCC earlier than 3.2, other than 2.95.3,
44703 have been deprecated. This and future releases of Services 5.0
44704 will still work, though some error messages will lose
44705 From arathorn at theonering.net Fri Nov 14 14:56:49 2003
44706 From: arathorn at theonering.net (Arathorn)
44707 Date: Sat Oct 23 23:10:09 2004
44708 Subject: [IRCServices Coding] [PATCH] Fix of rogue unescaped backtick in
44709 configure in 5.0.24
44710 Message-ID: <Pine.LNX.4.56L0.0311142254250.16502@phoenix.siarch.net>
44712 Well, I just had another chance to look more carefully at the configure
44713 script - looks like there's a rogue unescaped backtick in the deprecation
44714 warning text block:
44717 diff -ur ircservices-5.0.24-orig/configure ircservices-5.0.24/configure
44718 --- ircservices-5.0.24-orig/configure Wed Nov 5 01:46:59 2003
44719 +++ ircservices-5.0.24/configure Fri Nov 14 17:04:08 2003
44720 @@ -875,7 +875,7 @@
44721 elif test $vmajor -lt 3 -a $version != 2.95.3 || test $vmajor = 3 -a $vminor -lt 2 ; then
44724 -WARNING: Your version of GCC was detected as `$version'. As of Services
44725 +WARNING: Your version of GCC was detected as \`$version'. As of Services
44726 5.0.23, versions of GCC earlier than 3.2, other than 2.95.3,
44727 have been deprecated. This and future releases of Services 5.0
44728 will still work, though some error messages will lose
44732 (due to pine insisting on base64'ing mime attachments, i haven't attached
44733 the file as Andrew's mail system doesn't seem to approve of base64. -
44734 apologies if this mail shows up twice for anyone.)
44736 ________________________________________________________________
44737 Matthew Hodgson arathorn@theonering.net Tel: +44 7968 722968
44738 Arathorn: Co-Sysadmin, TheOneRing.net?
44740 On Wed, 12 Nov 2003, Arathorn wrote:
44744 > Just tried to upgrade to 5.0.24 on my Debian Woody production server
44745 > running gcc 2.95.4. I appreciate that this is <3.2 and !=2.95.3, but I
44746 > didn't expect ./configure to completely keel over on me (and hoped to be
44747 > able to use a -force configure option of some kind to get it to compile
44750 > Here's the stderr & stdio - the configure.log is attached:
44752 > pe1650 18# gcc -v
44753 > Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
44754 > gcc version 2.95.4 20011002 (Debian prerelease)
44755 > pe1650 19# ./configure -ignore-cache
44757 > Beginning IRC Services configuration.
44759 > In what directory do you want the binaries to be installed?
44760 > Press Return for the default, or enter a new value.
44761 > [/usr/local/sbin] /usr/local/sbin/ircservices-5.0.24-unr
44763 > Where do you want the data files to be installed?
44764 > [/usr/local/sbin/ircservices-5.0.24-unr/lib] /usr/local/lib/ircservices-5.0
44766 > End of interactive configuration.
44768 > Checking sanity of /bin/sh... high.
44769 > Searching for a suitable compiler... ./configure: command substitution:
44770 > line 1: unexpected EOF while looking for matching `''
44771 > ./configure: command substitution: line 8: syntax error: unexpected end of file
44773 > WARNING: Your version of GCC was detected as Press Enter to continue:
44777 > Testing default compiler flags ()... no luck! Using no flags.
44778 > If you know what flags you want, use the -cflags option to configure.
44779 > Let's see what libraries we need...
44780 > Checking if we can use dynamic modules... no.
44781 > Checking whether ranlib exists... yes.
44782 > Looking for an 8-bit integer type...
44783 > *** WHOA THERE! ***
44785 > We suddenly couldn't compile using the C compiler we already tested!
44786 > The command line we used was:
44787 > conf-tmp/test.c -o conf-tmp/test
44788 > Please try to fix this; if you can't, mail achurch@achurch.org
44789 > with information about your system, the output from this script,
44790 > and the `configure.log' file generated by this script.
44792 > ________________________________________________________________
44793 > Matthew Hodgson arathorn@theonering.net Tel: +44 7968 722968
44794 > Arathorn: Co-Sysadmin, TheOneRing.net?
44796 > On Tue, 11 Nov 2003, Andrew Church wrote:
44798 > > Services 5.0.24 has been released, and can be downloaded from:
44800 > > ftp://ftp.esper.net/ircservices/ (USA, California)
44802 > > d8f808b04744e9db365ebb23f7d04078 ircservices-5.0.24.tar.gz
44803 > > e2415db90e2c9f3391268b8d48ef40d1 ircservices-5.0.24.diff.gz
44804 > > 07d0785f095de88f87de8b4d97024558 ircservices-5.0.24-1.i386.rpm
44805 > > 0235352278f534a818699281fcc7ba83 ircservices_5.0.24-1_i386.deb
44807 > > ftp.ircservices.za.net and the other mirrors should have it shortly.
44809 > > This release includes a workaround for those who were unable to
44810 > > compile 5.0.23; however, please note that being unable to compile means
44811 > > that your compiler is outdated, and you should upgrade it (or have the
44812 > > server administrator upgrade it) as soon as possible. Support for such
44813 > > compilers will be removed entirely in a future version.
44815 > > Changes in version 5.0.24
44816 > > -------------------------
44817 > > 2003/11/11 Fixed a warning in convert-db compilation.
44818 > > 2003/11/11 Fixed bugs in convert-db causing some nickname and channel
44819 > > settings (timezone, language, channel and memo limits)
44820 > > to not be initialized properly.
44821 > > 2003/11/11 Added -tzfile, -no-timezones, and -reset-memo-limits
44822 > > options to the Cygnus database converter in convert-db.
44823 > > 2003/11/05 Databases can now be exported in XML from the command line
44824 > > (-export option).
44825 > > 2003/11/05 GCC versions earlier than 3.2 (except 2.95.3) are now
44826 > > deprecated. Variadic macros workaround added for
44827 > > problem reported by Ali Sor <alisor@softhome.net>
44828 > > 2003/11/05 Channel last-used time is now updated properly for the
44829 > > first user to enter the channel if the user has auto-op
44830 > > privileges. Reported by <saman@alkol.org>
44832 > > --Andrew Church
44833 > > achurch@achurch.org
44834 > > http://achurch.org/
44835 > > ------------------------------------------------------------------
44836 > > To unsubscribe or change your subscription options, visit:
44837 > > http://www.ircservices.za.net/mailman/listinfo/ircservices
44841 From arathorn at theonering.net Fri Nov 14 18:05:19 2003
44842 From: arathorn at theonering.net (Arathorn)
44843 Date: Sat Oct 23 23:10:09 2004
44844 Subject: [IRCServices Coding] Re: [PATCH] Fix of rogue unescaped backtick in
44845 configure in 5.0.24
44846 In-Reply-To: <3fb57b85.45153@achurch.org>
44847 References: <3fb57b85.45153@achurch.org>
44848 Message-ID: <Pine.LNX.4.56L0.0311150154580.16999@phoenix.siarch.net>
44850 Hmm, turns out that I was a little premature in sending in that one-line
44851 patch - unless I'm completely missing something, the configure script
44852 doesn't actually end up setting the CC or DEF_CC_FLAGS variables after
44853 warning about deprecation. Not sure whether this is because the
44854 deprecation is being enforced more strongly than the warnings suggest, but
44855 I expanded the tweak to the following in order to get it to build
44856 sensibly. For what it's worth, gcc 2.95.4 has never presented any
44857 problems for me with ircservices (since 4.3.3 or so) - so perhaps it might
44858 also be considerable as 'officially supported' in addition to 2.95.3 and
44859 >3.2? Debian stable has a fairly decent reputation, after all.
44861 diff -ur ircservices-5.0.24/configure ircservices-5.0.24-fixed/configure
44862 --- ircservices-5.0.24/configure Wed Nov 5 01:46:59 2003
44863 +++ ircservices-5.0.24-fixed/configure Fri Nov 14 21:01:23 2003
44864 @@ -875,7 +875,7 @@
44865 elif test $vmajor -lt 3 -a $version != 2.95.3 || test $vmajor = 3 -a $vminor -lt 2 ; then
44868 -WARNING: Your version of GCC was detected as `$version'. As of Services
44869 +WARNING: Your version of GCC was detected as \`$version'. As of Services
44870 5.0.23, versions of GCC earlier than 3.2, other than 2.95.3,
44871 have been deprecated. This and future releases of Services 5.0
44872 will still work, though some error messages will lose
44873 @@ -885,6 +885,9 @@
44875 echo2 "Press Enter to continue: "
44878 + DEF_CC_FLAGS=`def_cc_flags $CC`
44879 + log using \`gcc\'
44881 else # version okay
44882 echo "great, found gcc!"
44885 ________________________________________________________________
44886 Matthew Hodgson arathorn@theonering.net Tel: +44 7968 722968
44887 Arathorn: Co-Sysadmin, TheOneRing.net?
44889 On Sat, 15 Nov 2003, Andrew Church wrote:
44891 > Thanks, fixed. Silly little details...
44893 > (For the record, I use a homebrew mail reader which can't handle
44894 > attachments. If I do get attachments I can decode them with pine, but I
44895 > prefer patches inline so I can look at them without having to do so.)
44898 > achurch@achurch.org
44899 > http://achurch.org/
44901 > >Well, I just had another chance to look more carefully at the configure
44902 > >script - looks like there's a rogue unescaped backtick in the deprecation
44903 > >warning text block:
44906 > >diff -ur ircservices-5.0.24-orig/configure ircservices-5.0.24/configure
44907 > >--- ircservices-5.0.24-orig/configure Wed Nov 5 01:46:59 2003
44908 > >+++ ircservices-5.0.24/configure Fri Nov 14 17:04:08 2003
44909 > >@@ -875,7 +875,7 @@
44910 > > elif test $vmajor -lt 3 -a $version != 2.95.3 || test $vmajor = 3 -a $vminor -lt 2 ; then
44913 > >-WARNING: Your version of GCC was detected as `$version'. As of Services
44914 > >+WARNING: Your version of GCC was detected as \`$version'. As of Services
44915 > > 5.0.23, versions of GCC earlier than 3.2, other than 2.95.3,
44916 > > have been deprecated. This and future releases of Services 5.0
44917 > > will still work, though some error messages will lose
44921 > >(due to pine insisting on base64'ing mime attachments, i haven't attached
44922 > >the file as Andrew's mail system doesn't seem to approve of base64. -
44923 > >apologies if this mail shows up twice for anyone.)
44925 > >________________________________________________________________
44926 > >Matthew Hodgson arathorn@theonering.net Tel: +44 7968 722968
44927 > > Arathorn: Co-Sysadmin, TheOneRing.net??
44929 > >On Wed, 12 Nov 2003, Arathorn wrote:
44933 > >> Just tried to upgrade to 5.0.24 on my Debian Woody production server
44934 > >> running gcc 2.95.4. I appreciate that this is <3.2 and !=2.95.3, but I
44935 > >> didn't expect ./configure to completely keel over on me (and hoped to be
44936 > >> able to use a -force configure option of some kind to get it to compile
44939 > >> Here's the stderr & stdio - the configure.log is attached:
44941 > >> pe1650 18# gcc -v
44942 > >> Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
44943 > >> gcc version 2.95.4 20011002 (Debian prerelease)
44944 > >> pe1650 19# ./configure -ignore-cache
44946 > >> Beginning IRC Services configuration.
44948 > >> In what directory do you want the binaries to be installed?
44949 > >> Press Return for the default, or enter a new value.
44950 > >> [/usr/local/sbin] /usr/local/sbin/ircservices-5.0.24-unr
44952 > >> Where do you want the data files to be installed?
44953 > >> [/usr/local/sbin/ircservices-5.0.24-unr/lib] /usr/local/lib/ircservices-5.0
44955 > >> End of interactive configuration.
44957 > >> Checking sanity of /bin/sh... high.
44958 > >> Searching for a suitable compiler... ./configure: command substitution:
44959 > >> line 1: unexpected EOF while looking for matching `''
44960 > >> ./configure: command substitution: line 8: syntax error: unexpected end of file
44962 > >> WARNING: Your version of GCC was detected as Press Enter to continue:
44966 > >> Testing default compiler flags ()... no luck! Using no flags.
44967 > >> If you know what flags you want, use the -cflags option to configure.
44968 > >> Let's see what libraries we need...
44969 > >> Checking if we can use dynamic modules... no.
44970 > >> Checking whether ranlib exists... yes.
44971 > >> Looking for an 8-bit integer type...
44972 > >> *** WHOA THERE! ***
44974 > >> We suddenly couldn't compile using the C compiler we already tested!
44975 > >> The command line we used was:
44976 > >> conf-tmp/test.c -o conf-tmp/test
44977 > >> Please try to fix this; if you can't, mail achurch@achurch.org
44978 > >> with information about your system, the output from this script,
44979 > >> and the `configure.log' file generated by this script.
44981 > >> ________________________________________________________________
44982 > >> Matthew Hodgson arathorn@theonering.net Tel: +44 7968 722968
44983 > >> Arathorn: Co-Sysadmin, TheOneRing.net??
44985 > >> On Tue, 11 Nov 2003, Andrew Church wrote:
44987 > >> > Services 5.0.24 has been released, and can be downloaded from:
44989 > >> > ftp://ftp.esper.net/ircservices/ (USA, California)
44991 > >> > d8f808b04744e9db365ebb23f7d04078 ircservices-5.0.24.tar.gz
44992 > >> > e2415db90e2c9f3391268b8d48ef40d1 ircservices-5.0.24.diff.gz
44993 > >> > 07d0785f095de88f87de8b4d97024558 ircservices-5.0.24-1.i386.rpm
44994 > >> > 0235352278f534a818699281fcc7ba83 ircservices_5.0.24-1_i386.deb
44996 > >> > ftp.ircservices.za.net and the other mirrors should have it shortly.
44998 > >> > This release includes a workaround for those who were unable to
44999 > >> > compile 5.0.23; however, please note that being unable to compile means
45000 > >> > that your compiler is outdated, and you should upgrade it (or have the
45001 > >> > server administrator upgrade it) as soon as possible. Support for such
45002 > >> > compilers will be removed entirely in a future version.
45004 > >> > Changes in version 5.0.24
45005 > >> > -------------------------
45006 > >> > 2003/11/11 Fixed a warning in convert-db compilation.
45007 > >> > 2003/11/11 Fixed bugs in convert-db causing some nickname and channel
45008 > >> > settings (timezone, language, channel and memo limits)
45009 > >> > to not be initialized properly.
45010 > >> > 2003/11/11 Added -tzfile, -no-timezones, and -reset-memo-limits
45011 > >> > options to the Cygnus database converter in convert-db.
45012 > >> > 2003/11/05 Databases can now be exported in XML from the command line
45013 > >> > (-export option).
45014 > >> > 2003/11/05 GCC versions earlier than 3.2 (except 2.95.3) are now
45015 > >> > deprecated. Variadic macros workaround added for
45016 > >> > problem reported by Ali Sor <alisor@softhome.net>
45017 > >> > 2003/11/05 Channel last-used time is now updated properly for the
45018 > >> > first user to enter the channel if the user has auto-op
45019 > >> > privileges. Reported by <saman@alkol.org>
45021 > >> > --Andrew Church
45022 > >> > achurch@achurch.org
45023 > >> > http://achurch.org/
45024 > >> > ------------------------------------------------------------------
45025 > >> > To unsubscribe or change your subscription options, visit:
45026 > >> > http://www.ircservices.za.net/mailman/listinfo/ircservices
45032 From Craig at chatspike.net Sat Nov 15 12:26:22 2003
45033 From: Craig at chatspike.net (Craig McLure)
45034 Date: Sat Oct 23 23:10:09 2004
45035 Subject: [IRCServices Coding] Database API?
45036 Message-ID: <E1AL6zu-000HlY-00@ptb-mailc05.plus.net>
45038 Recently, I have been making modules for services, for use with our network (including HostServ, IdleServ, an 'improved' Statserv and loveserv), However, with each we have been forced to make our own databases, and was wondering if you plan on adding a proper Database API at some point, which could be used with all 3rd Pary modules? it seems the current one is heavily pointed towards the use of the 'main' services.
45040 I know you planned on restructuring the databases for version 5, however, as i recall, this didnt get started. Maybe what i'm suggesting was concidered before and dropped.. Anyway, some info on this would be appreciated. Thanks :)
45045 From ballsy at mystical.net Mon Nov 17 13:52:17 2003
45046 From: ballsy at mystical.net (Ballsy)
45047 Date: Sat Oct 23 23:10:09 2004
45048 Subject: [IRCServices Coding] EOF in backquote substitution error during
45050 Message-ID: <6.0.0.22.0.20031117144131.0481a8c0@127.0.0.1>
45052 Was Arathorn the only one to run across the backquote substitution error
45053 when configuring 5.0.24 ? I just patched from 5.0.22 to 5.0.24 and am
45054 getting the following during ./configure:
45056 Checking sanity of /bin/sh... high.
45057 Searching for a suitable compiler... ./configure: 29: Syntax error: EOF in
45058 backquote substitution
45060 I'm not familiar enough with 'patch' to know if it supports 'rollbacks' to
45061 previous versions (didn't see anyting in the man page), and 5.0.22's .tgz
45062 isn't on the ftp sites. Ideas ? (other than patching from 5.0.0 --> 5.0.24)
45063 As I didn't configure/make/make install after going from 5.0.22 -> 5.0.23,
45064 I'm not sure which patch was responsible (ie. I did both patches, then ran
45065 configure after a gmake clean).
45074 From arathorn at theonering.net Tue Nov 18 03:54:17 2003
45075 From: arathorn at theonering.net (Arathorn)
45076 Date: Sat Oct 23 23:10:09 2004
45077 Subject: [IRCServices Coding] Re: EOF in backquote substitution error during
45079 Message-ID: <Pine.LNX.4.56L0.0311181144590.6789@phoenix.siarch.net>
45083 Andrew confirmed that there are some bugs in ./configure which only
45084 surface if you're using a deprecated compiler. The IRC Services Coding
45085 list seems to have swallowed the remainder of the mails on the subject -
45086 i'm forwarding the most relevant one again. 5.0.24 has this problem, no
45087 matter how you came to it (either by patching from whatever version or
45088 by expanding the neat tarball).
45090 The below patch fixes the problem for me, but it's completely unsupported
45091 of course - to apply it, copy the text starting at the line that begins
45092 'diff -ur' through to just above my .sig - and paste it into a text file
45093 (making sure the lines don't wrap or anything). Save the file as
45094 ircservices-5.0.24-gccfix.patch or similar, and then apply to your 5.0.24
45095 source tree with a:
45097 cd /usr/local/src/ircservices-5.0.24 (or wherever it lives)
45098 patch -p1 < ~/ircservices-5.0.24-gccfix.patch (or wherever the patch is)
45100 and then you should be able to configure; make; make install correctly.
45101 Or alternatively wait until the official fix in the next version :)
45105 ________________________________________________________________
45106 Matthew Hodgson arathorn@theonering.net Tel: +44 7968 722968
45107 Arathorn: Co-Sysadmin, TheOneRing.net?
45109 ---------- Forwarded message ----------
45110 Date: Sat, 15 Nov 2003 02:05:19 +0000 (GMT)
45111 From: Arathorn <arathorn@theonering.net>
45112 To: Andrew Church <achurch@achurch.org>
45113 Cc: arathorn@theonering.net, ircservices-coding@ircservices.za.net
45114 Subject: Re: [PATCH] Fix of rogue unescaped backtick in configure in 5.0.24
45116 Hmm, turns out that I was a little premature in sending in that one-line
45117 patch - unless I'm completely missing something, the configure script
45118 doesn't actually end up setting the CC or DEF_CC_FLAGS variables after
45119 warning about deprecation. Not sure whether this is because the
45120 deprecation is being enforced more strongly than the warnings suggest, but
45121 I expanded the tweak to the following in order to get it to build
45122 sensibly. For what it's worth, gcc 2.95.4 has never presented any
45123 problems for me with ircservices (since 4.3.3 or so) - so perhaps it might
45124 also be considerable as 'officially supported' in addition to 2.95.3 and
45125 >3.2? Debian stable has a fairly decent reputation, after all.
45127 diff -ur ircservices-5.0.24/configure ircservices-5.0.24-fixed/configure
45128 --- ircservices-5.0.24/configure Wed Nov 5 01:46:59 2003
45129 +++ ircservices-5.0.24-fixed/configure Fri Nov 14 21:01:23 2003
45130 @@ -875,7 +875,7 @@
45131 elif test $vmajor -lt 3 -a $version != 2.95.3 || test $vmajor = 3 -a $vminor -lt 2 ; then
45134 -WARNING: Your version of GCC was detected as `$version'. As of Services
45135 +WARNING: Your version of GCC was detected as \`$version'. As of Services
45136 5.0.23, versions of GCC earlier than 3.2, other than 2.95.3,
45137 have been deprecated. This and future releases of Services 5.0
45138 will still work, though some error messages will lose
45139 @@ -885,6 +885,9 @@
45141 echo2 "Press Enter to continue: "
45144 + DEF_CC_FLAGS=`def_cc_flags $CC`
45145 + log using \`gcc\'
45147 else # version okay
45148 echo "great, found gcc!"
45151 ________________________________________________________________
45152 Matthew Hodgson arathorn@theonering.net Tel: +44 7968 722968
45153 Arathorn: Co-Sysadmin, TheOneRing.net?
45155 On Sat, 15 Nov 2003, Andrew Church wrote:
45157 > Thanks, fixed. Silly little details...
45159 > (For the record, I use a homebrew mail reader which can't handle
45160 > attachments. If I do get attachments I can decode them with pine, but I
45161 > prefer patches inline so I can look at them without having to do so.)
45164 > achurch@achurch.org
45165 > http://achurch.org/
45167 > >Well, I just had another chance to look more carefully at the configure
45168 > >script - looks like there's a rogue unescaped backtick in the deprecation
45169 > >warning text block:
45172 > >diff -ur ircservices-5.0.24-orig/configure ircservices-5.0.24/configure
45173 > >--- ircservices-5.0.24-orig/configure Wed Nov 5 01:46:59 2003
45174 > >+++ ircservices-5.0.24/configure Fri Nov 14 17:04:08 2003
45175 > >@@ -875,7 +875,7 @@
45176 > > elif test $vmajor -lt 3 -a $version != 2.95.3 || test $vmajor = 3 -a $vminor -lt 2 ; then
45179 > >-WARNING: Your version of GCC was detected as `$version'. As of Services
45180 > >+WARNING: Your version of GCC was detected as \`$version'. As of Services
45181 > > 5.0.23, versions of GCC earlier than 3.2, other than 2.95.3,
45182 > > have been deprecated. This and future releases of Services 5.0
45183 > > will still work, though some error messages will lose
45187 > >(due to pine insisting on base64'ing mime attachments, i haven't attached
45188 > >the file as Andrew's mail system doesn't seem to approve of base64. -
45189 > >apologies if this mail shows up twice for anyone.)
45191 > >________________________________________________________________
45192 > >Matthew Hodgson arathorn@theonering.net Tel: +44 7968 722968
45193 > > Arathorn: Co-Sysadmin, TheOneRing.net??
45195 > >On Wed, 12 Nov 2003, Arathorn wrote:
45199 > >> Just tried to upgrade to 5.0.24 on my Debian Woody production server
45200 > >> running gcc 2.95.4. I appreciate that this is <3.2 and !=2.95.3, but I
45201 > >> didn't expect ./configure to completely keel over on me (and hoped to be
45202 > >> able to use a -force configure option of some kind to get it to compile
45205 > >> Here's the stderr & stdio - the configure.log is attached:
45207 > >> pe1650 18# gcc -v
45208 > >> Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
45209 > >> gcc version 2.95.4 20011002 (Debian prerelease)
45210 > >> pe1650 19# ./configure -ignore-cache
45212 > >> Beginning IRC Services configuration.
45214 > >> In what directory do you want the binaries to be installed?
45215 > >> Press Return for the default, or enter a new value.
45216 > >> [/usr/local/sbin] /usr/local/sbin/ircservices-5.0.24-unr
45218 > >> Where do you want the data files to be installed?
45219 > >> [/usr/local/sbin/ircservices-5.0.24-unr/lib] /usr/local/lib/ircservices-5.0
45221 > >> End of interactive configuration.
45223 > >> Checking sanity of /bin/sh... high.
45224 > >> Searching for a suitable compiler... ./configure: command substitution:
45225 > >> line 1: unexpected EOF while looking for matching `''
45226 > >> ./configure: command substitution: line 8: syntax error: unexpected end of file
45228 > >> WARNING: Your version of GCC was detected as Press Enter to continue:
45232 > >> Testing default compiler flags ()... no luck! Using no flags.
45233 > >> If you know what flags you want, use the -cflags option to configure.
45234 > >> Let's see what libraries we need...
45235 > >> Checking if we can use dynamic modules... no.
45236 > >> Checking whether ranlib exists... yes.
45237 > >> Looking for an 8-bit integer type...
45238 > >> *** WHOA THERE! ***
45240 > >> We suddenly couldn't compile using the C compiler we already tested!
45241 > >> The command line we used was:
45242 > >> conf-tmp/test.c -o conf-tmp/test
45243 > >> Please try to fix this; if you can't, mail achurch@achurch.org
45244 > >> with information about your system, the output from this script,
45245 > >> and the `configure.log' file generated by this script.
45247 > >> ________________________________________________________________
45248 > >> Matthew Hodgson arathorn@theonering.net Tel: +44 7968 722968
45249 > >> Arathorn: Co-Sysadmin, TheOneRing.net??
45251 > >> On Tue, 11 Nov 2003, Andrew Church wrote:
45253 > >> > Services 5.0.24 has been released, and can be downloaded from:
45255 > >> > ftp://ftp.esper.net/ircservices/ (USA, California)
45257 > >> > d8f808b04744e9db365ebb23f7d04078 ircservices-5.0.24.tar.gz
45258 > >> > e2415db90e2c9f3391268b8d48ef40d1 ircservices-5.0.24.diff.gz
45259 > >> > 07d0785f095de88f87de8b4d97024558 ircservices-5.0.24-1.i386.rpm
45260 > >> > 0235352278f534a818699281fcc7ba83 ircservices_5.0.24-1_i386.deb
45262 > >> > ftp.ircservices.za.net and the other mirrors should have it shortly.
45264 > >> > This release includes a workaround for those who were unable to
45265 > >> > compile 5.0.23; however, please note that being unable to compile means
45266 > >> > that your compiler is outdated, and you should upgrade it (or have the
45267 > >> > server administrator upgrade it) as soon as possible. Support for such
45268 > >> > compilers will be removed entirely in a future version.
45270 > >> > Changes in version 5.0.24
45271 > >> > -------------------------
45272 > >> > 2003/11/11 Fixed a warning in convert-db compilation.
45273 > >> > 2003/11/11 Fixed bugs in convert-db causing some nickname and channel
45274 > >> > settings (timezone, language, channel and memo limits)
45275 > >> > to not be initialized properly.
45276 > >> > 2003/11/11 Added -tzfile, -no-timezones, and -reset-memo-limits
45277 > >> > options to the Cygnus database converter in convert-db.
45278 > >> > 2003/11/05 Databases can now be exported in XML from the command line
45279 > >> > (-export option).
45280 > >> > 2003/11/05 GCC versions earlier than 3.2 (except 2.95.3) are now
45281 > >> > deprecated. Variadic macros workaround added for
45282 > >> > problem reported by Ali Sor <alisor@softhome.net>
45283 > >> > 2003/11/05 Channel last-used time is now updated properly for the
45284 > >> > first user to enter the channel if the user has auto-op
45285 > >> > privileges. Reported by <saman@alkol.org>
45287 > >> > --Andrew Church
45288 > >> > achurch@achurch.org
45289 > >> > http://achurch.org/
45290 > >> > ------------------------------------------------------------------
45291 > >> > To unsubscribe or change your subscription options, visit:
45292 > >> > http://www.ircservices.za.net/mailman/listinfo/ircservices
45298 From andrewk at isdial.net Tue Aug 26 02:43:45 2003
45299 From: andrewk at isdial.net (Andrew Kempe)
45300 Date: Sat Oct 23 23:10:09 2004
45301 Subject: [IRCServices Coding] test
45302 Message-ID: <005801c36bb6$85bbc080$1f0912ac@espotting.com>
45306 From us44ever at hotmail.com Thu Aug 28 09:45:48 2003
45307 From: us44ever at hotmail.com (us44ever .)
45308 Date: Sat Oct 23 23:10:09 2004
45309 Subject: [IRCServices Coding] Yet, another great suggestion
45310 Message-ID: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
45314 it would be really great to add another new line to the "/nickserv info"
45315 command, for example, when some one types: "/nickserv info nick", the
45316 following will be shown:
45318 ***************************
45320 -NickServ- nick is hello world
45322 -NickServ- Is online from: ~test@just.a.test.co.za
45324 -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
45326 -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
45328 -NickServ- Last quit message: anythinggggg
45330 -NickServ- Options: Kill protection, Security
45332 ***************************
45334 the new line I'm suggesting is something like:
45336 ***************************
45337 -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
45338 ***************************
45340 This will help our users to compare the time that user was last seen and the
45341 time right now *it's very important, many many of our users asked us for
45342 this option*, also it would even be more great to show how long last time
45343 the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003 GMT
45344 (last seen time was before: 10 days, 3hours and 24 sec ago).
45346 Note that I saw both of these features, in other services I don't remember
45347 there names (but they aren't as stable as ircservices5) (it was something
45348 like ptlink services, and magik II)
45350 That's all, I would really like to see it on the next version (or if you can
45351 show me how to do it, as I'm not a programmer)
45353 Many thanks to all of who developed IRCservices ...etc ...etc ...etc
45358 _________________________________________________________________
45359 Get MSN 8 and enjoy automatic e-mail virus protection.
45360 http://join.msn.com/?page=features/virus
45363 From aragon at phat.za.net Thu Aug 28 11:36:22 2003
45364 From: aragon at phat.za.net (Aragon Gouveia)
45365 Date: Sat Oct 23 23:10:09 2004
45366 Subject: [IRCServices Coding] Yet, another great suggestion
45367 In-Reply-To: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
45368 References: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
45369 Message-ID: <20030828183615.GB32204@phat.za.net>
45371 Or how about rather letting users decide what timezone they're in and
45372 services outputs all timestamps in their local time?
45375 | By us44ever . <us44ever@hotmail.com>
45376 | [ 2003-08-28 18:45 +0200 ]
45379 > it would be really great to add another new line to the "/nickserv info"
45380 > command, for example, when some one types: "/nickserv info nick", the
45381 > following will be shown:
45383 > ***************************
45385 > -NickServ- nick is hello world
45387 > -NickServ- Is online from: ~test@just.a.test.co.za
45389 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
45391 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
45393 > -NickServ- Last quit message: anythinggggg
45395 > -NickServ- Options: Kill protection, Security
45397 > ***************************
45399 > the new line I'm suggesting is something like:
45401 > ***************************
45402 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
45403 > ***************************
45405 > This will help our users to compare the time that user was last seen and
45406 > the time right now *it's very important, many many of our users asked us
45407 > for this option*, also it would even be more great to show how long last
45408 > time the user was seen (some thing like: Last seen time: Aug 28 15:51:14
45409 > 2003 GMT (last seen time was before: 10 days, 3hours and 24 sec ago).
45411 > Note that I saw both of these features, in other services I don't remember
45412 > there names (but they aren't as stable as ircservices5) (it was something
45413 > like ptlink services, and magik II)
45415 > That's all, I would really like to see it on the next version (or if you
45416 > can show me how to do it, as I'm not a programmer)
45418 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
45423 > _________________________________________________________________
45424 > Get MSN 8 and enjoy automatic e-mail virus protection.
45425 > http://join.msn.com/?page=features/virus
45427 > ------------------------------------------------------------------
45428 > To unsubscribe or change your subscription options, visit:
45429 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
45431 From saturn at jetirc.net Thu Aug 28 11:39:41 2003
45432 From: saturn at jetirc.net (Saturn)
45433 Date: Sat Oct 23 23:10:09 2004
45434 Subject: [IRCServices Coding] Yet, another great suggestion
45435 References: <Sea1-F942gu59Vvjvxo0000efdf@hotmail.com>
45436 <20030828183615.GB32204@phat.za.net>
45437 Message-ID: <003201c36d93$abf77fd0$6401a8c0@turby>
45439 Oooo now I like that option... have it default to a default timezone, set in
45440 the conf file, and give them the option of SETting a different UTC code
45441 (have it as GMT + or - x wheer x is the offset from UTC)... It may not
45442 sound liek much, but I bet people will use it, and what's more, it IS useful
45443 information, especially on international servers like mine.. we have people
45444 from all over the place, and we keep services set on Pacific time... but for
45445 those in, say, Belgium... that's not very helpful
45447 ----- Original Message -----
45448 From: "Aragon Gouveia" <aragon@phat.za.net>
45449 To: <ircservices-coding@ircservices.za.net>
45450 Sent: Thursday, August 28, 2003 11:36 AM
45451 Subject: Re: [IRCServices Coding] Yet, another great suggestion
45454 Or how about rather letting users decide what timezone they're in and
45455 services outputs all timestamps in their local time?
45458 | By us44ever . <us44ever@hotmail.com>
45459 | [ 2003-08-28 18:45 +0200 ]
45462 > it would be really great to add another new line to the "/nickserv info"
45463 > command, for example, when some one types: "/nickserv info nick", the
45464 > following will be shown:
45466 > ***************************
45468 > -NickServ- nick is hello world
45470 > -NickServ- Is online from: ~test@just.a.test.co.za
45472 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
45474 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
45476 > -NickServ- Last quit message: anythinggggg
45478 > -NickServ- Options: Kill protection, Security
45480 > ***************************
45482 > the new line I'm suggesting is something like:
45484 > ***************************
45485 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
45486 > ***************************
45488 > This will help our users to compare the time that user was last seen and
45489 > the time right now *it's very important, many many of our users asked us
45490 > for this option*, also it would even be more great to show how long last
45491 > time the user was seen (some thing like: Last seen time: Aug 28 15:51:14
45492 > 2003 GMT (last seen time was before: 10 days, 3hours and 24 sec ago).
45494 > Note that I saw both of these features, in other services I don't remember
45495 > there names (but they aren't as stable as ircservices5) (it was something
45496 > like ptlink services, and magik II)
45498 > That's all, I would really like to see it on the next version (or if you
45499 > can show me how to do it, as I'm not a programmer)
45501 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
45506 > _________________________________________________________________
45507 > Get MSN 8 and enjoy automatic e-mail virus protection.
45508 > http://join.msn.com/?page=features/virus
45510 > ------------------------------------------------------------------
45511 > To unsubscribe or change your subscription options, visit:
45512 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
45513 ------------------------------------------------------------------
45514 To unsubscribe or change your subscription options, visit:
45515 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
45519 From Craig at chatspike.net Thu Aug 28 14:29:54 2003
45520 From: Craig at chatspike.net (Craig McLure)
45521 Date: Sat Oct 23 23:10:09 2004
45522 Subject: [IRCServices Coding] Yet, another great suggestion
45523 Message-ID: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
45525 Please dont post to both the services main list, and the services coding list. Choose one, or the other, especially concidering i dont think this is a great suggestion either..
45527 /time services.chatspike.net
45528 [22:28]
\95\95\95 Date / time at services.chatspike.net- Thu Aug 28 17:28:57 2003 EDT
45532 /****************************************
45533 * Craig "FrostyCoolSlug" McLure
45534 ************* - SpamBox - **************
45535 * InspIRCd - http://www.inspircd.org
45536 * ChatSpike - http://www.chatspike.net
45537 * WinBot - http://www.winbot.co.uk
45538 ****************************************/
45540 /****************************************
45541 * From - us44ever . <us44ever@hotmail.com>
45542 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
45543 * Sent - 2003-08-28 @ 16:45:00
45544 * Subject - [IRCServices Coding] Yet, another great suggestion
45545 ****************************************/
45547 /****** - Begin Original Message - ******/
45551 >it would be really great to add another new line to the "/nickserv info"
45552 >command, for example, when some one types: "/nickserv info nick", the
45553 >following will be shown:
45555 >***************************
45557 >-NickServ- nick is hello world
45559 >-NickServ- Is online from: ~test@just.a.test.co.za
45561 >-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
45563 >-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
45565 >-NickServ- Last quit message: anythinggggg
45567 >-NickServ- Options: Kill protection, Security
45569 >***************************
45571 >the new line I'm suggesting is something like:
45573 >***************************
45574 >-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
45575 >***************************
45577 >This will help our users to compare the time that user was last seen and the
45578 >time right now *it's very important, many many of our users asked us for
45579 >this option*, also it would even be more great to show how long last time
45580 >the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003 GMT
45581 >(last seen time was before: 10 days, 3hours and 24 sec ago).
45583 >Note that I saw both of these features, in other services I don't remember
45584 >there names (but they aren't as stable as ircservices5) (it was something
45585 >like ptlink services, and magik II)
45587 >That's all, I would really like to see it on the next version (or if you can
45588 >show me how to do it, as I'm not a programmer)
45590 >Many thanks to all of who developed IRCservices ...etc ...etc ...etc
45595 >_________________________________________________________________
45596 >Get MSN 8 and enjoy automatic e-mail virus protection.
45597 >http://join.msn.com/?page=features/virus
45599 >------------------------------------------------------------------
45600 >To unsubscribe or change your subscription options, visit:
45601 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
45603 /******* - End Original Message - *******/
45608 From nothing at psychopat.org Thu Aug 28 14:57:31 2003
45609 From: nothing at psychopat.org (Marc-Andre A. Fuentes)
45610 Date: Sat Oct 23 23:10:09 2004
45611 Subject: [IRCServices Coding] BUG Report
45612 Message-ID: <001501c36daf$c8cba700$0101a8c0@house>
45614 We're having a small problem with suspended channel.
45616 we suspended channel #kavala, and someone has identified itself has the founder and apply a DROP to the channel.
45617 then we got a panic from the services and... crash.
45619 Also with suspended nick , when the suspencion expire, the services crash
45622 ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
45627 -------------- next part --------------
45628 An HTML attachment was scrubbed...
45629 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030828/1f31ccf5/attachment-0004.htm
45630 From Craig at chatspike.net Thu Aug 28 15:24:36 2003
45631 From: Craig at chatspike.net (Craig McLure)
45632 Date: Sat Oct 23 23:10:09 2004
45633 Subject: [IRCServices Coding] BUG Report
45634 Message-ID: <20030828222401.JVQE12036.mta4-svc.business.ntl.com@i-br0ked-it>
45636 hmm.. what OS, compiler version etc are you using?
45638 after a test, i got the following:
45640 /cs id #abc 00376370
45641 -ChanServ- Channel #abc is suspended and may not be used or identified for.
45644 [23:20] -ChanServ- Channel is suspended and may not be used or identified for.
45646 only prob i got was it missed the channel name in the second message :)
45649 /****************************************
45650 * Craig "FrostyCoolSlug" McLure
45651 ************* - SpamBox - **************
45652 * InspIRCd - http://www.inspircd.org
45653 * ChatSpike - http://www.chatspike.net
45654 * WinBot - http://www.winbot.co.uk
45655 ****************************************/
45657 /****************************************
45658 * From - Marc-Andre A. Fuentes <nothing@psychopat.org>
45659 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
45660 * Sent - 2003-08-28 @ 18:00:00
45661 * Subject - [IRCServices Coding] BUG Report
45662 ****************************************/
45664 /****** - Begin Original Message - ******/
45666 >We're having a small problem with suspended channel.
45668 >we suspended channel #kavala, and someone has identified itself has the founder and apply a DROP to the channel.
45669 >then we got a panic from the services and... crash.
45671 >Also with suspended nick , when the suspencion expire, the services crash
45674 >ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
45679 >------------------------------------------------------------------
45680 >To unsubscribe or change your subscription options, visit:
45681 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
45683 /******* - End Original Message - *******/
45688 From saturn at jetirc.net Thu Aug 28 17:13:48 2003
45689 From: saturn at jetirc.net (Saturn)
45690 Date: Sat Oct 23 23:10:09 2004
45691 Subject: [IRCServices Coding] AKill suggestion
45692 References: <2C31F186-CDEE-11D7-979C-0003938D6866@mac.com>
45693 Message-ID: <009001c36dc2$64b56b80$6401a8c0@turby>
45695 Would it be possible to have it announce to the user when they are akilled,
45696 either the expiry date and time, or "Expires in 3days, 4hours, 6minutes" or
45697 something similar. I find that usually we just have to do 24hour bans, but
45698 the user has no way to know when the ban was set, and when it expires...
45700 Just an idea... I now await the half dozen people who will proceed to tell
45701 me how stupid my idea is....
45708 From playa at dreamchat.org Thu Aug 28 20:46:19 2003
45709 From: playa at dreamchat.org (playa)
45710 Date: Sat Oct 23 23:10:09 2004
45711 Subject: [IRCServices Coding] Yet, another great suggestion
45712 In-Reply-To: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
45713 References: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
45714 Message-ID: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
45716 Is this /time command only supposed to work via RAW? Cause when i type
45717 /time services.dreamchat.org i get No Such User, but if i do /raw time
45718 services.dreamchat.org, it works. Just wondering if its just me, or if
45719 its supposed to be that way.
45721 > Please dont post to both the services main list, and the services coding
45722 > list. Choose one, or the other, especially concidering i dont think this
45723 > is a great suggestion either..
45725 > /time services.chatspike.net
45726 > [22:28] ??? Date / time at services.chatspike.net- Thu Aug 28 17:28:57
45731 > /****************************************
45732 > * Craig "FrostyCoolSlug" McLure
45733 > ************* - SpamBox - **************
45734 > * InspIRCd - http://www.inspircd.org
45735 > * ChatSpike - http://www.chatspike.net
45736 > * WinBot - http://www.winbot.co.uk
45737 > ****************************************/
45739 > /****************************************
45740 > * From - us44ever . <us44ever@hotmail.com>
45741 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
45742 > * Sent - 2003-08-28 @ 16:45:00
45743 > * Subject - [IRCServices Coding] Yet, another great suggestion
45744 > ****************************************/
45746 > /****** - Begin Original Message - ******/
45750 >>it would be really great to add another new line to the "/nickserv info"
45751 >>command, for example, when some one types: "/nickserv info nick", the
45752 >>following will be shown:
45754 >>***************************
45756 >>-NickServ- nick is hello world
45758 >>-NickServ- Is online from: ~test@just.a.test.co.za
45760 >>-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
45762 >>-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
45764 >>-NickServ- Last quit message: anythinggggg
45766 >>-NickServ- Options: Kill protection, Security
45768 >>***************************
45770 >>the new line I'm suggesting is something like:
45772 >>***************************
45773 >>-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
45774 >>***************************
45776 >>This will help our users to compare the time that user was last seen and
45778 >>time right now *it's very important, many many of our users asked us for
45779 >>this option*, also it would even be more great to show how long last time
45780 >>the user was seen (some thing like: Last seen time: Aug 28 15:51:14 2003
45782 >>(last seen time was before: 10 days, 3hours and 24 sec ago).
45784 >>Note that I saw both of these features, in other services I don't
45786 >>there names (but they aren't as stable as ircservices5) (it was something
45787 >>like ptlink services, and magik II)
45789 >>That's all, I would really like to see it on the next version (or if you
45791 >>show me how to do it, as I'm not a programmer)
45793 >>Many thanks to all of who developed IRCservices ...etc ...etc ...etc
45798 >>_________________________________________________________________
45799 >>Get MSN 8 and enjoy automatic e-mail virus protection.
45800 >>http://join.msn.com/?page=features/virus
45802 >>------------------------------------------------------------------
45803 >>To unsubscribe or change your subscription options, visit:
45804 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
45806 > /******* - End Original Message - *******/
45810 > ------------------------------------------------------------------
45811 > To unsubscribe or change your subscription options, visit:
45812 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
45819 Network Founder/CEO
45820 DreamChat IRC Network - irc.dreamchat.org
45821 http://www.dreamchat.org
45824 From quension at mac.com Thu Aug 28 21:13:48 2003
45825 From: quension at mac.com (Trevor Talbot)
45826 Date: Sat Oct 23 23:10:09 2004
45827 Subject: [IRCServices Coding] Yet, another great suggestion
45828 In-Reply-To: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
45829 Message-ID: <0F823090-D9D7-11D7-8513-0003938D6866@mac.com>
45831 On Thursday, Aug 28, 2003, at 20:46 US/Pacific, playa wrote:
45833 > Is this /time command only supposed to work via RAW? Cause when i
45834 > type /time services.dreamchat.org i get No Such User, but if i do /raw
45835 > time services.dreamchat.org, it works. Just wondering if its just me,
45836 > or if its supposed to be that way.
45838 That's a client thing. Some clients might alias /time as a CTCP TIME
45839 for a specific user, or similar.
45844 From r-krisztian at softhome.net Thu Aug 28 22:12:51 2003
45845 From: r-krisztian at softhome.net (Krisztian Romek)
45846 Date: Sat Oct 23 23:10:09 2004
45847 Subject: [IRCServices Coding] Yet, another great suggestion
45848 In-Reply-To: <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
45849 References: <20030828212943.KEKN29825.mta5-svc.business.ntl.com@i-br0ked-it>
45850 <29047.68.21.137.36.1062128774.squirrel@dreamchat.org>
45851 Message-ID: <200308290713.29423.r-krisztian@softhome.net>
45853 > Is this /time command only supposed to work via RAW? Cause when i type
45854 > /time services.dreamchat.org i get No Such User, but if i do /raw time
45855 > services.dreamchat.org, it works. Just wondering if its just me, or if
45856 > its supposed to be that way.
45858 Some clients use stupid aliases for CTCP commands, for example:
45860 /version <nick> = /CTCP <nick> VERSION,
45861 /time <nick> = /CTCP <nick> TIME,
45862 /finger <nick> = /CTCP <nick> TIME
45864 This is why nothing works the way you expected.
45868 r-krisztian@softhome.net
45871 From us44ever at hotmail.com Fri Aug 29 13:02:19 2003
45872 From: us44ever at hotmail.com (us44ever .)
45873 Date: Sat Oct 23 23:10:09 2004
45874 Subject: [IRCServices Coding] AKill suggestion
45875 Message-ID: <Sea1-F108cM3oryKFRJ0000eb75@hotmail.com>
45877 Pretty good idea, specially is it would be implemented as an option (because
45878 some admins might won't like the idea of displaying the time of when the
45879 akill will expire to the user who has been akilled).
45881 _________________________________________________________________
45882 Help protect your PC: Get a free online virus scan at McAfee.com.
45883 http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
45886 From us44ever at hotmail.com Fri Aug 29 13:09:51 2003
45887 From: us44ever at hotmail.com (us44ever .)
45888 Date: Sat Oct 23 23:10:09 2004
45889 Subject: [IRCServices Coding] Yet, another great suggestion
45890 Message-ID: <Sea1-F127z33hqSnMGE000094b3@hotmail.com>
45893 Since most people want to see this feature(s) in the next version, it would
45894 be great to implement it as an optional feature , where it can be disabled
45895 from the .conf file(s) or enable it easily. I don't think that there is
45896 anything that the authors will lose if this feature can be added, in fact,
45897 it will add another nice feature to the features list of IRCservices5.
45899 _________________________________________________________________
45900 Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
45901 using MSN Messenger http://entertainment.msn.com/imastar
45904 From Craig at chatspike.net Fri Aug 29 13:41:59 2003
45905 From: Craig at chatspike.net (Craig McLure)
45906 Date: Sat Oct 23 23:10:09 2004
45907 Subject: [IRCServices Coding] Yet, another great suggestion
45908 Message-ID: <20030829204143.NNNT26404.mta1-svc.business.ntl.com@i-br0ked-it>
45910 I'll ask again.. can you please stop posting to both the IRCServices mailing list, and the IRCd coding mailing list, getting your mail 2ce is beginning to annoy me.
45912 And i'll Quote Elijah:
45914 "Except it's already been said in the FAQ that it's not going to happen, and
45915 if that made it into the FAQ it would seem the answer is frequently going to
45919 /****************************************
45920 * Craig "FrostyCoolSlug" McLure
45921 ************* - SpamBox - **************
45922 * InspIRCd - http://www.inspircd.org
45923 * ChatSpike - http://www.chatspike.net
45924 * WinBot - http://www.winbot.co.uk
45925 ****************************************/
45927 /****************************************
45928 * From - us44ever . <us44ever@hotmail.com>
45929 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
45930 * Sent - 2003-08-29 @ 20:09:00
45931 * Subject - Re: [IRCServices Coding] Yet, another great suggestion
45932 ****************************************/
45934 /****** - Begin Original Message - ******/
45936 >Since most people want to see this feature(s) in the next version, it would
45937 >be great to implement it as an optional feature , where it can be disabled
45938 >from the .conf file(s) or enable it easily. I don't think that there is
45939 >anything that the authors will lose if this feature can be added, in fact,
45940 >it will add another nice feature to the features list of IRCservices5.
45942 >_________________________________________________________________
45943 >Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
45944 >using MSN Messenger http://entertainment.msn.com/imastar
45946 >------------------------------------------------------------------
45947 >To unsubscribe or change your subscription options, visit:
45948 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
45951 /******* - End Original Message - *******/
45956 From Craig at chatspike.net Fri Aug 29 13:43:24 2003
45957 From: Craig at chatspike.net (Craig McLure)
45958 Date: Sat Oct 23 23:10:09 2004
45959 Subject: [IRCServices Coding] AKill suggestion
45960 Message-ID: <20030829204311.GHCL29825.mta5-svc.business.ntl.com@i-br0ked-it>
45962 its a stupid idea!!! :p
45964 j/k.. I think its a great idea.. i'd rather have services telling users when their akills expire, than them spamming my mailbox with 'when does my akill expire?' every 20mins :p
45966 /****************************************
45967 * Craig "FrostyCoolSlug" McLure
45968 ************* - SpamBox - **************
45969 * InspIRCd - http://www.inspircd.org
45970 * ChatSpike - http://www.chatspike.net
45971 * WinBot - http://www.winbot.co.uk
45972 ****************************************/
45974 /****************************************
45975 * From - Saturn <saturn@jetirc.net>
45976 * To - IRC Services Coding Mailing List <ircservices-coding@ircservices.za.net>
45977 * Sent - 2003-08-28 @ 17:13:00
45978 * Subject - [IRCServices Coding] AKill suggestion
45979 ****************************************/
45981 /****** - Begin Original Message - ******/
45983 >Would it be possible to have it announce to the user when they are akilled,
45984 >either the expiry date and time, or "Expires in 3days, 4hours, 6minutes" or
45985 >something similar. I find that usually we just have to do 24hour bans, but
45986 >the user has no way to know when the ban was set, and when it expires...
45988 >Just an idea... I now await the half dozen people who will proceed to tell
45989 >me how stupid my idea is....
45995 >------------------------------------------------------------------
45996 >To unsubscribe or change your subscription options, visit:
45997 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
45999 /******* - End Original Message - *******/
46004 From admin at nevernet.net Fri Aug 29 13:48:01 2003
46005 From: admin at nevernet.net (Elijah)
46006 Date: Sat Oct 23 23:10:09 2004
46007 Subject: [IRCServices Coding] Yet, another great suggestion
46008 In-Reply-To: <20030829204143.NNNT26404.mta1-svc.business.ntl.com@i-br0ked-it>
46009 Message-ID: <008f01c36e6e$83158770$436a3a44@slytherin>
46013 -----Original Message-----
46014 From: ircservices-coding-bounces@ircservices.za.net
46015 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of Craig
46017 Sent: Friday, August 29, 2003 4:41 PM
46018 To: IRC Services Coding Mailing List
46019 Subject: Re: Re: [IRCServices Coding] Yet, another great suggestion
46022 I'll ask again.. can you please stop posting to both the IRCServices mailing
46023 list, and the IRCd coding mailing list, getting your mail 2ce is beginning
46026 And i'll Quote Elijah:
46028 "Except it's already been said in the FAQ that it's not going to happen, and
46029 if that made it into the FAQ it would seem the answer is frequently going to
46034 From us44ever at hotmail.com Fri Aug 29 16:59:31 2003
46035 From: us44ever at hotmail.com (us44ever .)
46036 Date: Sat Oct 23 23:10:09 2004
46037 Subject: [IRCServices Coding] Yet, another great suggestion
46038 Message-ID: <Sea1-F30z1oyZF58m3O00035b82@hotmail.com>
46040 woops, ok sorry I thought the two e-mails is completely different.
46043 >From: "Craig McLure" <Craig@chatspike.net>
46044 >Reply-To: IRC Services Coding Mailing List
46045 ><ircservices-coding@ircservices.za.net>
46046 >To: IRC Services Coding Mailing List
46047 ><ircservices-coding@ircservices.za.net>
46048 >Subject: Re: Re: [IRCServices Coding] Yet, another great suggestion
46049 >Date: Fri, 29 Aug 2003 21:41:23 +0000
46051 >I'll ask again.. can you please stop posting to both the IRCServices
46052 >mailing list, and the IRCd coding mailing list, getting your mail 2ce is
46053 >beginning to annoy me.
46055 >And i'll Quote Elijah:
46057 >"Except it's already been said in the FAQ that it's not going to happen,
46059 >if that made it into the FAQ it would seem the answer is frequently going
46064 >/****************************************
46065 > * Craig "FrostyCoolSlug" McLure
46066 > ************* - SpamBox - **************
46067 > * InspIRCd - http://www.inspircd.org
46068 > * ChatSpike - http://www.chatspike.net
46069 > * WinBot - http://www.winbot.co.uk
46070 > ****************************************/
46072 >/****************************************
46073 > * From - us44ever . <us44ever@hotmail.com>
46074 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
46075 > * Sent - 2003-08-29 @ 20:09:00
46076 > * Subject - Re: [IRCServices Coding] Yet, another great suggestion
46077 > ****************************************/
46079 >/****** - Begin Original Message - ******/
46081 > >Since most people want to see this feature(s) in the next version, it
46083 > >be great to implement it as an optional feature , where it can be
46085 > >from the .conf file(s) or enable it easily. I don't think that there is
46086 > >anything that the authors will lose if this feature can be added, in
46088 > >it will add another nice feature to the features list of IRCservices5.
46090 > >_________________________________________________________________
46091 > >Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
46092 > >using MSN Messenger http://entertainment.msn.com/imastar
46094 > >------------------------------------------------------------------
46095 > >To unsubscribe or change your subscription options, visit:
46096 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
46099 >/******* - End Original Message - *******/
46103 >------------------------------------------------------------------
46104 >To unsubscribe or change your subscription options, visit:
46105 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
46107 _________________________________________________________________
46108 MSN 8: Get 6 months for $9.95/month. http://join.msn.com/?page=dept/dialup
46111 From simorgh at dataphone.se Sat Aug 30 08:27:11 2003
46112 From: simorgh at dataphone.se (Ali Simorgh)
46113 Date: Sat Oct 23 23:10:09 2004
46114 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
46115 In-Reply-To: <MKEGJINFADFODDNOKEJCMEEADPAA.rg@tcslon.com>
46116 Message-ID: <Pine.GSO.4.31.0308301716410.15629-100000@nikson.dataphone.se>
46119 I run ircservices 5.0.21 on FreeBSD 4.8-STABLE. and Ultimate 3.*
46120 I get this in logfile:
46122 [Aug 30 10:51:19 2003] unknown message from server
46123 (NETCTRL 0 0 0 0 0 0 0 0 0 0 0 0 0)
46124 [Aug 30 10:51:19 2003] user: New maximum user count: 1
46125 [Aug 30 10:51:19 2003] unknown message from server
46126 (:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
46127 [Aug 30 10:51:19 2003] user: New maximum user count: 2
46128 [Aug 30 10:51:19 2003] unknown message from server
46129 (:irc.MyNet.Net SETHOST pedarkhAnde 6b45bb2.26d9672f.dataphone.se)
46130 [Aug 30 10:56:18 2003] mail/sendmail:
46131 /usr/sbin/sendmail exited with code 25600
46132 [Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
46133 registration (Simorgh)
46135 and how can I do so that nickserv dont show the realhost of a user in
46142 ______________________________________________________
46143 Many of life's failures are people who did not realize
46144 how close they were to success when they gave up.
46146 ______________________________________________________
46151 From jskam at shaw.ca Sat Aug 30 11:34:35 2003
46152 From: jskam at shaw.ca (Jeffery Kam)
46153 Date: Sat Oct 23 23:10:09 2004
46154 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
46155 In-Reply-To: <Pine.GSO.4.31.0308301716410.15629-100000@nikson.dataphone.se>
46156 Message-ID: <000001c36f25$58464860$f64f9144@weed>
46158 "and how can I do so that nickserv dont show the realhost of a user in
46159 'ns info nick all'"
46161 This would be a great feature for sure. I know on my network, there is
46162 a custom user mode +d, which will disguise a user's host in a /whois
46163 reply, but services info doesn't show it disguised unless the HIDE
46168 From achurch at achurch.org Sat Aug 30 16:14:47 2003
46169 From: achurch at achurch.org (Andrew Church)
46170 Date: Sat Oct 23 23:10:09 2004
46171 Subject: [IRCServices Coding] MARK Command
46172 In-Reply-To: <3208.66.181.69.244.1060800845.squirrel@dreamchat.org>
46173 Message-ID: <3f512fdb.01666@achurch.org>
46175 Use E-mail if you need communication of that sort.
46178 achurch@achurch.org
46179 http://achurch.org/
46181 >First off, i would like to say that IRCservices are the best services out
46182 >there, by FAR! Anyways, i was wondering if the MARK command will be in
46183 >the next relase? Its kind of a pointless command, its only used to mark
46184 >nicks or channels, but it is very useful for when passwords to channels
46187 >/chanserv MARK <channel> <reason>
46189 >/chanserv info #channel would read the following.
46190 >*#channel has been MARKED by playa - <reason>
46192 >Of course only IRCops would be able to view it.
46194 >Just an idea i thought of :)
46199 >Network Founder/CEO
46200 >DreamChat IRC Network - irc.dreamchat.org
46201 >http://www.dreamchat.org
46203 >------------------------------------------------------------------
46204 >To unsubscribe or change your subscription options, visit:
46205 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
46207 From achurch at achurch.org Sat Aug 30 16:17:44 2003
46208 From: achurch at achurch.org (Andrew Church)
46209 Date: Sat Oct 23 23:10:09 2004
46210 Subject: [IRCServices Coding] OP/Voice upon identify
46211 In-Reply-To: <Pine.GSO.4.31.0308211027350.6118-100000@nikson.dataphone.se>
46212 Message-ID: <3f513092.01677@achurch.org>
46214 Needless complexity. If you don't want yourself autoopped, then don't
46215 be an auto-op. It's that simple.
46218 achurch@achurch.org
46219 http://achurch.org/
46222 >Its nice with this option. but I dont se any set command that ChanServ
46223 >wont automatically op or voice you in any channel.
46226 > SET NOAUTO ON|OFF
46227 > When NOAUTO is on, ChanServ will not
46228 > automatically op or voice you in any channels.
46230 >Maybe some user(s) wont get auto op/voice then they can set this option ON
46231 >but it sould be OFF in default.
46238 > ______________________________________________________
46239 > Many of life's failures are people who did not realize
46240 > how close they were to success when they gave up.
46242 > ______________________________________________________
46245 >On Sun, 17 Aug 2003, Russell Garrett wrote:
46247 >> Eh? This has been implemented since IRCServices 5a31.
46251 >> > I wonder if its possible to make some modification that:
46252 >> > when someone has already joined a few channels, and then identifies
46253 >> > to its nickname, chanserv gives Voice and/or Op to the user is s/he
46254 >> > is in the channel list (+o; aop or above & +v when vop)
46256 >> > this is very usefull to not privmsg chanserv for every op or voice
46257 >> > request, when user has not identified to its nick before joining
46260 >> > Thanks for any help
46262 >> ------------------------------------------------------------------
46263 >> To unsubscribe or change your subscription options, visit:
46264 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
46267 >------------------------------------------------------------------
46268 >To unsubscribe or change your subscription options, visit:
46269 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
46271 From l8nite at l8nite.net Sat Aug 30 16:58:16 2003
46272 From: l8nite at l8nite.net (Shaun Guth)
46273 Date: Sat Oct 23 23:10:09 2004
46274 Subject: [IRCServices Coding] OP/Voice upon identify
46275 In-Reply-To: <3f513092.01677@achurch.org>
46276 References: <3f513092.01677@achurch.org>
46277 Message-ID: <1062287885.21924.6.camel@localhost>
46279 On Sun, 2003-08-31 at 01:16, Andrew Church wrote:
46280 > Needless complexity. If you don't want yourself autoopped, then don't
46281 > be an auto-op. It's that simple.
46283 I disagree. In my case, I wanted to create a channel where there were
46284 no ops so users don't have to endure lame op-wars, etc. However, I did
46285 need to maintain a level of control over the channel to protect from
46286 extremely obnoxious behavior or lame bots, etc. By registering as
46287 founder of the channel I induced the unwanted 'auto-op' behavior. My
46288 only solution was to register another fake user to become channel
46289 founder and set their nick to noexpire. That to me seems like needless
46290 complexity. A simple check to see if the user wishes to be opped or not
46296 From Craig at chatspike.net Sat Aug 30 17:07:32 2003
46297 From: Craig at chatspike.net (Craig McLure)
46298 Date: Sat Oct 23 23:10:09 2004
46299 Subject: [IRCServices Coding] OP/Voice upon identify
46300 Message-ID: <20030831000719.ELIJ19019.mta3-svc.business.ntl.com@i-br0ked-it>
46302 it would thou.. they would have to be able to switch off auto-op for a single channel..
46303 you could always use /cs levels to change the 'auto op' level up.. so that no one is auto-opped..
46305 or /cs levels #channels DISABLE autoop
46307 /****************************************
46308 * Craig "FrostyCoolSlug" McLure
46309 ************* - SpamBox - **************
46310 * InspIRCd - http://www.inspircd.org
46311 * ChatSpike - http://www.chatspike.net
46312 * WinBot - http://www.winbot.co.uk
46313 ****************************************/
46315 /****************************************
46316 * From - Shaun Guth <l8nite@l8nite.net>
46317 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
46318 * Sent - 2003-08-30 @ 16:58:00
46319 * Subject - RE: [IRCServices Coding] OP/Voice upon identify
46320 ****************************************/
46322 /****** - Begin Original Message - ******/
46324 >On Sun, 2003-08-31 at 01:16, Andrew Church wrote:
46325 >> Needless complexity. If you don't want yourself autoopped, then don't
46326 >> be an auto-op. It's that simple.
46328 >I disagree. In my case, I wanted to create a channel where there were
46329 >no ops so users don't have to endure lame op-wars, etc. However, I did
46330 >need to maintain a level of control over the channel to protect from
46331 >extremely obnoxious behavior or lame bots, etc. By registering as
46332 >founder of the channel I induced the unwanted 'auto-op' behavior. My
46333 >only solution was to register another fake user to become channel
46334 >founder and set their nick to noexpire. That to me seems like needless
46335 >complexity. A simple check to see if the user wishes to be opped or not
46340 >------------------------------------------------------------------
46341 >To unsubscribe or change your subscription options, visit:
46342 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
46345 /******* - End Original Message - *******/
46350 From l8nite at l8nite.net Sat Aug 30 17:14:44 2003
46351 From: l8nite at l8nite.net (Shaun Guth)
46352 Date: Sat Oct 23 23:10:09 2004
46353 Subject: [IRCServices Coding] OP/Voice upon identify
46354 In-Reply-To: <20030831000719.ELIJ19019.mta3-svc.business.ntl.com@i-br0ked-it>
46355 References: <20030831000719.ELIJ19019.mta3-svc.business.ntl.com@i-br0ked-it>
46356 Message-ID: <1062288881.21924.17.camel@localhost>
46358 On Sat, 2003-08-30 at 18:06, Craig McLure wrote:
46359 > it would thou.. they would have to be able to switch off auto-op for a single channel..
46361 For each channel we already store an access list, one extra bit to
46362 indicate auto-anything status or not is not really asking too much.
46364 > you could always use /cs levels to change the 'auto op' level up.. so that no one is auto-opped..
46365 > or /cs levels #channels DISABLE autoop
46367 -ChanServ- Channel #foobar registered under your nickname: l8
46368 -ChanServ- AUTOOP disabled on channel #foobar.
46369 --- You have left channel #foobar
46370 --> You are now talking on #foobar
46371 --- services.topgamers.net removes channel operator status from l8
46372 --- services.topgamers.net gives channel operator status to l8
46374 Same with ENFORCE set to off as well.
46376 > [snipped obnoxiously long sig]
46381 From achurch at achurch.org Sun Aug 31 02:58:23 2003
46382 From: achurch at achurch.org (Andrew Church)
46383 Date: Sat Oct 23 23:10:09 2004
46384 Subject: [IRCServices Coding] OP/Voice upon identify
46385 In-Reply-To: <1062288881.21924.17.camel@localhost>
46386 Message-ID: <3f51c6b5.07402@achurch.org>
46388 >> you could always use /cs levels to change the 'auto op' level up.. so that no one is auto-opped..
46389 >> or /cs levels #channels DISABLE autoop
46391 >-ChanServ- Channel #foobar registered under your nickname: l8
46392 >-ChanServ- AUTOOP disabled on channel #foobar.
46393 >--- You have left channel #foobar
46394 >--> You are now talking on #foobar
46395 >--- services.topgamers.net removes channel operator status from l8
46396 >--- services.topgamers.net gives channel operator status to l8
46398 This is definitely confusing behavior. Fixed for 5.0.22, thanks for
46399 the report. Note that you will also want to disable the other AUTOxxx
46400 levels as well if you don't want any automatic modes.
46403 achurch@achurch.org
46404 http://achurch.org/
46406 From achurch at achurch.org Sun Aug 31 07:28:11 2003
46407 From: achurch at achurch.org (Andrew Church)
46408 Date: Sat Oct 23 23:10:09 2004
46409 Subject: [IRCServices Coding] Mass memos
46410 In-Reply-To: <001601c361d8$a5312f00$6401a8c0@turby>
46411 Message-ID: <3f5205f0.15057@achurch.org>
46413 >Can we reconsider adding a Mass memo function for the next release?
46415 No, for all the reasons others have mentioned. I'll also draw an
46416 example from my experience with cellphone mail in Japan, which is
46417 remarkably similar to Services memos: Automated messages are annoying,
46418 period. The primary use for cellphone mail is to communicate with friends;
46419 having automatic messages interfere with that is annoying in the extreme.
46420 Yes, 10% or 20% of your users might be willing to accept mass memos, but
46421 the remaining 80% or 90% will get quite upset with you.
46423 I might also point out that people who care about what happens on the
46424 network will actively check that information, whether you make it available
46425 through logon news, through a website, or whatever; and people who don't
46426 care will ignore anything you send them. The method you use to inform them
46427 won't really make a difference.
46429 >If not, or even if so... one thing puzzles me: In the /ns list * command,
46430 >the listings have occasional punctuation... a ! or ? in front of the nick.
46431 >There is nothing in the docs anywhere that seems to address this, and I'm
46432 >curious as to what those mean.... an explanation would be helpful there too.
46434 This should be available through /ns help list, but there appears to
46435 be a bug there. I'll fix it for the next version.
46437 >on that note, a possible suggestion for Logonnews... How about something I
46438 >saw on Dalnet once: When new news is added, you get a notice. Until you
46439 >read the news, it keeps bugging you when you log on. After you read it, it
46440 >stops. Some sort of flag so users know when there IS new news would be
46441 >useful... the main reason nobody read the logonnews is that 90% of the time
46442 >for them, it is unchanged........
46444 This is an interesting thought; I'll think about it for a future
46448 achurch@achurch.org
46449 http://achurch.org/
46451 From achurch at achurch.org Sun Aug 31 07:42:30 2003
46452 From: achurch at achurch.org (Andrew Church)
46453 Date: Sat Oct 23 23:10:09 2004
46454 Subject: [IRCServices Coding] Language
46455 In-Reply-To: <MKEGJINFADFODDNOKEJCKEEDDPAA.rg@tcslon.com>
46456 Message-ID: <3f52094e.17046@achurch.org>
46458 [/msg nickserv vs. /nickserv]
46459 >I wonder if it would be worth integrating such a thing into services as an
46460 >option (compile-time maybe?). I think it would be good for the irc community
46461 >as a whole to get away from the habit of msging services directly if at all
46462 >possible. Opinions?
46464 /msg NickServ is the one format that's guaranteed to work on every
46465 ircd (except for administrative decisions a la DALnet). Get an RFC
46466 published--and implemented; 2811-3 were remarkable failures in that area--
46467 and I'll consider changing it.
46470 achurch@achurch.org
46471 http://achurch.org/
46473 From achurch at achurch.org Sun Aug 31 07:45:49 2003
46474 From: achurch at achurch.org (Andrew Church)
46475 Date: Sat Oct 23 23:10:09 2004
46476 Subject: [IRCServices Coding] Language
46477 In-Reply-To: <Pine.GSO.4.31.0308172127300.9882-100000@nikson.dataphone.se>
46478 Message-ID: <3f520a18.17063@achurch.org>
46480 >Is there any tool (silly question) or something or guid to make a language
46483 >I have decided to make a Persian (Farsi) language file.
46485 Language files are just plain text files; as another reply said, read
46486 the comments at the top of lang/en_us.l, and work from there. Be warned
46487 that the amount of text is huge; expect to spend at least two to three
46488 months on the initial translation.
46490 Also, if you'd be willing to continue maintaining the language file as
46491 it is updated in future versions, please let me know privately.
46494 achurch@achurch.org
46495 http://achurch.org/
46497 From achurch at achurch.org Sun Aug 31 07:53:21 2003
46498 From: achurch at achurch.org (Andrew Church)
46499 Date: Sat Oct 23 23:10:09 2004
46500 Subject: [IRCServices Coding] segfault on expiring ?
46501 In-Reply-To: <001201c36793$d26e4000$0101a8c0@nothing>
46502 Message-ID: <3f520bd8.17715@achurch.org>
46504 >[Aug 20 20:49:05 2003] nickserv/main: Expiring suspension for SeBa_KoBe (nick group 17805)
46505 >[Aug 20 20:49:05 2003] nickserv/main: Expiring nickname SeBa_KoBe
46506 >[Aug 20 20:49:05 2003] nickserv/main: [Aug 20 20:49:05 2003] Services terminating: Segmentation Faul
46508 I can't reproduce this problem. If this is still occurring, can you
46509 send me your databases privately so that I can investigate it?
46512 achurch@achurch.org
46513 http://achurch.org/
46515 From achurch at achurch.org Sun Aug 31 07:55:10 2003
46516 From: achurch at achurch.org (Andrew Church)
46517 Date: Sat Oct 23 23:10:09 2004
46518 Subject: [IRCServices Coding] BUG Report
46519 In-Reply-To: <001501c36daf$c8cba700$0101a8c0@house>
46520 Message-ID: <3f520c48.17731@achurch.org>
46522 >we suspended channel #kavala, and someone has identified itself has the =
46523 >founder and apply a DROP to the channel.
46524 >then we got a panic from the services and... crash.
46526 This is a bug in the DROP function, and has been fixed; thanks for the
46530 achurch@achurch.org
46531 http://achurch.org/
46533 From achurch at achurch.org Sun Aug 31 08:07:44 2003
46534 From: achurch at achurch.org (Andrew Church)
46535 Date: Sat Oct 23 23:10:09 2004
46536 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
46537 In-Reply-To: <Pine.GSO.4.31.0308301716410.15629-100000@nikson.dataphone.se>
46538 Message-ID: <3f520f38.21076@achurch.org>
46540 >[Aug 30 10:56:18 2003] mail/sendmail:
46541 > /usr/sbin/sendmail exited with code 25600
46543 Use the SMTP module instead (mail/smtp).
46545 >[Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
46546 >registration (Simorgh)
46548 >and how can I do so that nickserv dont show the realhost of a user in
46549 >'ns info nick all'
46551 It doesn't. However:
46553 >[Aug 30 10:51:19 2003] unknown message from server
46554 >(:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
46556 You're using the wrong protocol, since it doesn't recognize the
46557 SETHOST command and therefore has no idea about fake hosts. I might
46558 remind you that Ultimate 3.x is not supported.
46561 achurch@achurch.org
46562 http://achurch.org/
46564 From achurch at achurch.org Sun Aug 31 08:11:22 2003
46565 From: achurch at achurch.org (Andrew Church)
46566 Date: Sat Oct 23 23:10:09 2004
46567 Subject: [IRCServices Coding] Yet, another great suggestion
46568 In-Reply-To: <20030828183615.GB32204@phat.za.net>
46569 Message-ID: <3f52100e.21116@achurch.org>
46571 >Or how about rather letting users decide what timezone they're in and
46572 >services outputs all timestamps in their local time?
46574 /ns help set timezone (since 5.0 alpha)
46577 achurch@achurch.org
46578 http://achurch.org/
46580 From saturn at jetirc.net Sun Aug 31 12:28:59 2003
46581 From: saturn at jetirc.net (Saturn)
46582 Date: Sat Oct 23 23:10:09 2004
46583 Subject: [IRCServices Coding]
46584 Re: [IRCServices] Yet, another great suggestion
46585 References: <3f5202a3.15001@achurch.org>
46586 Message-ID: <003201c36ff6$25ae6550$6401a8c0@turby>
46588 I think it is... consider an international Network like mine: every server
46589 is in a different time zone -- How are users supposed to know what time zone
46590 the Services (pickign on Services' clock because Services are whats giving
46591 these notices!) is in?? Sure, they can do the /time command, if they even
46592 know abotu it. But the vast majority of IRC users are ignorant of those
46593 sorts of commands, or even if they know about /time, they most likely have
46594 no idea they can specify a server with the command.
46596 I realize that programmers for IRC-related software seem always to be of the
46597 universal opinion that ALL irc users should take the time to become elite
46598 experts abotu everything PC, however that is simply NOT reality. Services
46599 is specificly there to SERVE the users and the ircops. Its sole function is
46600 to police access and provide information to the users -- what use is it to
46601 say that a certain piece of information is "not useful" or "not needed" when
46602 you can plainly see that it is in this case, given the argument above?
46604 Obviously, it is your project, not mine, and I certainly cannot force you to
46605 do anythign you don't want to do, but I and my staff and users all agree it
46606 would be extremely useful... "Handy" was the word most used. I've had quite
46607 a few queries about it, and so I'm asking for it. If you don't feel that
46608 non-techie users deserve any consideration, then ignore the request. It's
46609 really up to you anyhow....
46614 ----- Original Message -----
46615 From: "Andrew Church" <achurch@achurch.org>
46616 To: <saturn@jetirc.net>
46617 Sent: Sunday, August 31, 2003 7:13 AM
46618 Subject: Re: [IRCServices] Yet, another great suggestion
46621 >So how do you get the current time from Services then? The actual time that
46622 >SERVICES thinks it is, not the server, and not my local clock...
46624 If there's any significant difference between your local clock, your
46625 IRC server's clock, and Services' clock, then at least one of them needs to
46626 be fixed. That's not Services' problem.
46629 achurch@achurch.org
46630 http://achurch.org/
46634 From aragon at phat.za.net Sun Aug 31 13:23:29 2003
46635 From: aragon at phat.za.net (Aragon Gouveia)
46636 Date: Sat Oct 23 23:10:09 2004
46637 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
46638 another great suggestion
46639 In-Reply-To: <003201c36ff6$25ae6550$6401a8c0@turby>
46640 References: <3f5202a3.15001@achurch.org> <003201c36ff6$25ae6550$6401a8c0@turby>
46641 Message-ID: <20030831202324.GB8731@phat.za.net>
46643 | By Saturn <saturn@jetirc.net>
46644 | [ 2003-08-31 21:29 +0200 ]
46645 > I think it is... consider an international Network like mine: every server
46646 > is in a different time zone -- How are users supposed to know what time zone
46647 > the Services (pickign on Services' clock because Services are whats giving
46648 > these notices!) is in?? Sure, they can do the /time command, if they even
46649 > know abotu it. But the vast majority of IRC users are ignorant of those
46650 > sorts of commands, or even if they know about /time, they most likely have
46651 > no idea they can specify a server with the command.
46653 Erm, what's the argument here? Services stipulates its timezone in its
46654 timestamps. As do all the other servers on the network.
46662 From saturn at jetirc.net Sun Aug 31 13:47:37 2003
46663 From: saturn at jetirc.net (Saturn)
46664 Date: Sat Oct 23 23:10:09 2004
46665 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
46666 another great suggestion
46667 References: <3f5202a3.15001@achurch.org> <003201c36ff6$25ae6550$6401a8c0@turby>
46668 <20030831202324.GB8731@phat.za.net>
46669 Message-ID: <000701c37001$10a62cf0$6401a8c0@turby>
46671 The argument is that the overwhelming majority of IRC users have no idea the
46672 /time command exists, and even fewer are aware that they can specify a
46673 server name after the /time command. How would these people find out the
46674 Services time zone? Why does it all have to be so complicated??
46676 ----- Original Message -----
46677 From: "Aragon Gouveia" <aragon@phat.za.net>
46678 To: <ircservices-coding@ircservices.za.net>
46679 Sent: Sunday, August 31, 2003 1:23 PM
46680 Subject: Re: [IRCServices Coding] Re: [IRCServices] Yet,another great
46684 | By Saturn <saturn@jetirc.net>
46685 | [ 2003-08-31 21:29 +0200 ]
46686 > I think it is... consider an international Network like mine: every
46688 > is in a different time zone -- How are users supposed to know what time
46690 > the Services (pickign on Services' clock because Services are whats giving
46691 > these notices!) is in?? Sure, they can do the /time command, if they even
46692 > know abotu it. But the vast majority of IRC users are ignorant of those
46693 > sorts of commands, or even if they know about /time, they most likely have
46694 > no idea they can specify a server with the command.
46696 Erm, what's the argument here? Services stipulates its timezone in its
46697 timestamps. As do all the other servers on the network.
46704 ------------------------------------------------------------------
46705 To unsubscribe or change your subscription options, visit:
46706 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
46710 From quension at mac.com Sun Aug 31 14:11:28 2003
46711 From: quension at mac.com (Trevor Talbot)
46712 Date: Sat Oct 23 23:10:09 2004
46713 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
46714 another great suggestion
46715 In-Reply-To: <000701c37001$10a62cf0$6401a8c0@turby>
46716 Message-ID: <962546B6-DBF7-11D7-8505-0003938D6866@mac.com>
46718 On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
46720 > The argument is that the overwhelming majority of IRC users have no
46721 > idea the /time command exists, and even fewer are aware that they can
46722 > specify a server name after the /time command. How would these people
46723 > find out the Services time zone?
46725 You missed the point. Services shows the time zone wherever it uses a
46726 readable time -- i.e. in the nickserv/chanserv info displays. Unless
46727 you've changed your language file, in which case you can simply change
46730 > Why does it all have to be so complicated??
46732 It isn't. Your users can even use the handy-dandy /nickserv set
46733 timezone command to make it even easier.
46735 > ----- Original Message -----
46736 > From: "Aragon Gouveia" <aragon@phat.za.net>
46738 > | By Saturn <saturn@jetirc.net>
46739 > | [ 2003-08-31 21:29 +0200 ]
46740 >> I think it is... consider an international Network like mine: every
46741 >> server is in a different time zone -- How are users supposed to know
46742 >> what time zone the Services (pickign on Services' clock because
46743 >> Services are whats giving these notices!) is in?? Sure, they can do
46744 >> the /time command, if they even know abotu it. But the vast majority
46745 >> of IRC users are ignorant of those sorts of commands, or even if they
46746 >> know about /time, they most likely have no idea they can specify a
46747 >> server with the command.
46749 > Erm, what's the argument here? Services stipulates its timezone in
46750 > its timestamps. As do all the other servers on the network.
46755 From us44ever at hotmail.com Sun Aug 31 14:40:48 2003
46756 From: us44ever at hotmail.com (us44ever .)
46757 Date: Sat Oct 23 23:10:09 2004
46758 Subject: [IRCServices Coding]
46759 Re: [IRCServices] Yet, another great suggestion
46760 Message-ID: <Sea1-F8siZAPG4vEjaG0000fb20@hotmail.com>
46763 or even the idea of adding an additional info (exact info) something like:
46764 Last seen time : Aug 22 14:20:16 2003 GMT (9 days, 51 minutes and 21
46766 Time registered : Jul 25 22:19:20 2003 GMT (** days, ** minutes and **
46768 wouldn't even a greater idea?
46770 _________________________________________________________________
46771 Get MSN 8 and enjoy automatic e-mail virus protection.
46772 http://join.msn.com/?page=features/virus
46775 From saturn at jetirc.net Sun Aug 31 16:49:07 2003
46776 From: saturn at jetirc.net (Saturn)
46777 Date: Sat Oct 23 23:10:09 2004
46778 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
46779 another great suggestion
46780 References: <962546B6-DBF7-11D7-8505-0003938D6866@mac.com>
46781 Message-ID: <000e01c3701a$48faea50$6401a8c0@turby>
46783 [16:41] -NickServ- Time registered: Jul 27 13:09:08 2002 PDT
46785 That's what I see when I use it. Yes, it does say "PDT" .. how many people
46786 in, say Belgium, are going to know exactly what PDT is? How about "PDT
46787 (GMT-8)" as the format....? Also, you'll note that it STILL gives no
46788 indication as to the CURRENT time ... this is why the proper UTC code or
46789 GMT+/-## is the best way to go IMHO. I do also like the idea suggested by
46790 us44ever ... the "(** days, ** minutes, and ** seconds ago)" idea... that
46791 would be handy in any event.... and would eliminate the need for the current
46792 time to be displayed....
46794 On another note, I had forgotten the set timezone option, which certainly
46795 would put more clarity on the output... however, I think my points above are
46798 Unless of course I've missed a config setting that will tell it to report
46799 the tiome zone as a function of GMT (plus or minus x hours, rather than zone
46802 ----- Original Message -----
46803 From: "Trevor Talbot" <quension@mac.com>
46804 To: "IRC Services Coding Mailing List"
46805 <ircservices-coding@ircservices.za.net>
46806 Sent: Sunday, August 31, 2003 2:10 PM
46807 Subject: Re: [IRCServices Coding] Re: [IRCServices] Yet,another great
46811 On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
46813 > The argument is that the overwhelming majority of IRC users have no
46814 > idea the /time command exists, and even fewer are aware that they can
46815 > specify a server name after the /time command. How would these people
46816 > find out the Services time zone?
46818 You missed the point. Services shows the time zone wherever it uses a
46819 readable time -- i.e. in the nickserv/chanserv info displays. Unless
46820 you've changed your language file, in which case you can simply change
46823 > Why does it all have to be so complicated??
46825 It isn't. Your users can even use the handy-dandy /nickserv set
46826 timezone command to make it even easier.
46828 > ----- Original Message -----
46829 > From: "Aragon Gouveia" <aragon@phat.za.net>
46831 > | By Saturn <saturn@jetirc.net>
46832 > | [ 2003-08-31 21:29 +0200 ]
46833 >> I think it is... consider an international Network like mine: every
46834 >> server is in a different time zone -- How are users supposed to know
46835 >> what time zone the Services (pickign on Services' clock because
46836 >> Services are whats giving these notices!) is in?? Sure, they can do
46837 >> the /time command, if they even know abotu it. But the vast majority
46838 >> of IRC users are ignorant of those sorts of commands, or even if they
46839 >> know about /time, they most likely have no idea they can specify a
46840 >> server with the command.
46842 > Erm, what's the argument here? Services stipulates its timezone in
46843 > its timestamps. As do all the other servers on the network.
46847 ------------------------------------------------------------------
46848 To unsubscribe or change your subscription options, visit:
46849 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
46853 From quension at mac.com Sun Aug 31 18:25:05 2003
46854 From: quension at mac.com (Trevor Talbot)
46855 Date: Sat Oct 23 23:10:09 2004
46856 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
46857 another great suggestion
46858 In-Reply-To: <000e01c3701a$48faea50$6401a8c0@turby>
46859 Message-ID: <14C7EDD0-DC1B-11D7-8505-0003938D6866@mac.com>
46861 On Sunday, Aug 31, 2003, at 16:47 US/Pacific, Saturn wrote:
46863 > Unless of course I've missed a config setting that will tell it to
46864 > report the tiome zone as a function of GMT (plus or minus x hours,
46865 > rather than zone codes like PDT)...
46867 You could modify the language file, using something like "(GMT%z)"
46868 instead of %Z in the STRFTIME_DATE_TIME_FORMAT string. "man 3
46869 strftime" for the available options.
46874 From achurch at achurch.org Sun Aug 31 19:00:00 2003
46875 From: achurch at achurch.org (Andrew Church)
46876 Date: Sat Oct 23 23:10:09 2004
46877 Subject: [IRCServices Coding] Re: [IRCServices] Yet,
46878 another great suggestion
46879 In-Reply-To: <000e01c3701a$48faea50$6401a8c0@turby>
46880 Message-ID: <3f52a815.21363@achurch.org>
46882 "Use /ns set timezone" is the official answer on this. Please take
46883 all further discussion to the ircservices list.
46886 achurch@achurch.org
46887 http://achurch.org/
46889 >[16:41] -NickServ- Time registered: Jul 27 13:09:08 2002 PDT
46891 >That's what I see when I use it. Yes, it does say "PDT" .. how many people
46892 >in, say Belgium, are going to know exactly what PDT is? How about "PDT
46893 >(GMT-8)" as the format....? Also, you'll note that it STILL gives no
46894 >indication as to the CURRENT time ... this is why the proper UTC code or
46895 >GMT+/-## is the best way to go IMHO. I do also like the idea suggested by
46896 >us44ever ... the "(** days, ** minutes, and ** seconds ago)" idea... that
46897 >would be handy in any event.... and would eliminate the need for the current
46898 >time to be displayed....
46900 >On another note, I had forgotten the set timezone option, which certainly
46901 >would put more clarity on the output... however, I think my points above are
46904 >Unless of course I've missed a config setting that will tell it to report
46905 >the tiome zone as a function of GMT (plus or minus x hours, rather than zone
46906 >codes like PDT)...
46908 >----- Original Message -----
46909 >From: "Trevor Talbot" <quension@mac.com>
46910 >To: "IRC Services Coding Mailing List"
46911 ><ircservices-coding@ircservices.za.net>
46912 >Sent: Sunday, August 31, 2003 2:10 PM
46913 >Subject: Re: [IRCServices Coding] Re: [IRCServices] Yet,another great
46917 >On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
46919 >> The argument is that the overwhelming majority of IRC users have no
46920 >> idea the /time command exists, and even fewer are aware that they can
46921 >> specify a server name after the /time command. How would these people
46922 >> find out the Services time zone?
46924 >You missed the point. Services shows the time zone wherever it uses a
46925 >readable time -- i.e. in the nickserv/chanserv info displays. Unless
46926 >you've changed your language file, in which case you can simply change
46929 >> Why does it all have to be so complicated??
46931 >It isn't. Your users can even use the handy-dandy /nickserv set
46932 >timezone command to make it even easier.
46934 >> ----- Original Message -----
46935 >> From: "Aragon Gouveia" <aragon@phat.za.net>
46937 >> | By Saturn <saturn@jetirc.net>
46938 >> | [ 2003-08-31 21:29 +0200 ]
46939 >>> I think it is... consider an international Network like mine: every
46940 >>> server is in a different time zone -- How are users supposed to know
46941 >>> what time zone the Services (pickign on Services' clock because
46942 >>> Services are whats giving these notices!) is in?? Sure, they can do
46943 >>> the /time command, if they even know abotu it. But the vast majority
46944 >>> of IRC users are ignorant of those sorts of commands, or even if they
46945 >>> know about /time, they most likely have no idea they can specify a
46946 >>> server with the command.
46948 >> Erm, what's the argument here? Services stipulates its timezone in
46949 >> its timestamps. As do all the other servers on the network.
46953 >------------------------------------------------------------------
46954 >To unsubscribe or change your subscription options, visit:
46955 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
46958 >------------------------------------------------------------------
46959 >To unsubscribe or change your subscription options, visit:
46960 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
46962 From simorgh at dataphone.se Sun Aug 31 22:34:32 2003
46963 From: simorgh at dataphone.se (Ali Simorgh)
46964 Date: Sat Oct 23 23:10:09 2004
46965 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
46966 In-Reply-To: <3f520f38.21076@achurch.org>
46967 Message-ID: <Pine.GSO.4.31.0309010728040.7173-100000@nikson.dataphone.se>
46969 Thanks for your help.
46971 I thought if I set nickserv to not be an ircop, then it maybe dosent se
46972 the real host name, and maybe shows the crypted hostname to other users
46973 or should I change this line in language files:
46974 NICK_INFO_ADDRESS_ONLINE
46977 NICK_INFO_ADDRESS_ONLINE
46978 Is online from: N/A ?
46982 ______________________________________________________
46983 Many of life's failures are people who did not realize
46984 how close they were to success when they gave up.
46986 ______________________________________________________
46989 On Mon, 1 Sep 2003, Andrew Church wrote:
46991 > >[Aug 30 10:56:18 2003] mail/sendmail:
46992 > > /usr/sbin/sendmail exited with code 25600
46994 > Use the SMTP module instead (mail/smtp).
46996 > >[Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
46997 > >registration (Simorgh)
46999 > >and how can I do so that nickserv dont show the realhost of a user in
47000 > >'ns info nick all'
47002 > It doesn't. However:
47004 > >[Aug 30 10:51:19 2003] unknown message from server
47005 > >(:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
47007 > You're using the wrong protocol, since it doesn't recognize the
47008 > SETHOST command and therefore has no idea about fake hosts. I might
47009 > remind you that Ultimate 3.x is not supported.
47012 > achurch@achurch.org
47013 > http://achurch.org/
47014 > ------------------------------------------------------------------
47015 > To unsubscribe or change your subscription options, visit:
47016 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
47020 From achurch at achurch.org Sun Aug 31 23:24:09 2003
47021 From: achurch at achurch.org (Andrew Church)
47022 Date: Sat Oct 23 23:10:09 2004
47023 Subject: [IRCServices Coding] SETHOST, SENDMAIL and 'ns info all'
47024 In-Reply-To: <Pine.GSO.4.31.0309010728040.7173-100000@nikson.dataphone.se>
47025 Message-ID: <3f52e5fe.41203@achurch.org>
47027 >I thought if I set nickserv to not be an ircop, then it maybe dosent se
47028 >the real host name, and maybe shows the crypted hostname to other users
47030 It isn't a matter of NickServ having operator privileges or not;
47031 Services, as a server, always sees the real hostname. The problem is that
47032 Services and your IRC server aren't using the same protocol, so Services
47033 can't recognize the fake hosts. Try using a different IRC server.
47036 achurch@achurch.org
47037 http://achurch.org/
47039 From laser at musichat.net Wed Sep 3 06:49:40 2003
47040 From: laser at musichat.net (Alessandro Ciappei)
47041 Date: Sat Oct 23 23:10:10 2004
47042 Subject: [IRCServices Coding] New Features
47043 Message-ID: <001b01c37222$428f54d0$e2c0fea9@alexxa3il9cxpx>
47047 I have an idea for next release.
47048 A secure link between services and ircd.
47049 Now many ircd, like Unreal, tr-ircd, bahamut supports a ssl link.
47054 -------------- next part --------------
47055 An HTML attachment was scrubbed...
47056 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030903/a25ee68d/attachment-0004.html
47057 From r-krisztian at softhome.net Wed Sep 3 07:16:45 2003
47058 From: r-krisztian at softhome.net (Krisztian Romek)
47059 Date: Sat Oct 23 23:10:10 2004
47060 Subject: [IRCServices Coding] New Features
47061 In-Reply-To: <001b01c37222$428f54d0$e2c0fea9@alexxa3il9cxpx>
47062 References: <001b01c37222$428f54d0$e2c0fea9@alexxa3il9cxpx>
47063 Message-ID: <200309031617.38876.r-krisztian@softhome.net>
47068 > I have an idea for next release.
47069 > A secure link between services and ircd.
47070 > Now many ircd, like Unreal, tr-ircd, bahamut supports a ssl link.
47072 I think a ZIP link support (like in Unreal) should also be fine. :-) I don't
47073 know what you will reply for these feature requests, but I agree that they
47074 aren't so important, since in most cases ircd and services run on the same
47079 r-krisztian@softhome.net
47082 From Craig at chatspike.net Wed Sep 3 13:35:04 2003
47083 From: Craig at chatspike.net (Craig McLure)
47084 Date: Sat Oct 23 23:10:10 2004
47085 Subject: [IRCServices Coding] New Features
47086 Message-ID: <20030903203453.ITMO19019.mta3-svc.business.ntl.com@i-br0ked-it>
47088 If you read the archive, you will find that this has already been discussed (fairly recently if i recall..), and was thrown out, if you want services SSL support, i recommend you use a SSL tunnel.
47090 When it comes to ZIP links, this would require editing the services protocol module accordingly.. and IMO, shouldnt been needed, as in most cases, services run on the same box as a server.
47092 /****************************************
47093 * Craig "FrostyCoolSlug" McLure
47094 ************* - SpamBox - **************
47095 * InspIRCd - http://www.inspircd.org
47096 * ChatSpike - http://www.chatspike.net
47097 * WinBot - http://www.winbot.co.uk
47098 ****************************************/
47100 /****************************************
47101 * From - Alessandro Ciappei <laser@musichat.net>
47102 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
47103 * Sent - 2003-09-03 @ 15:49:00
47104 * Subject - [IRCServices Coding] New Features
47105 ****************************************/
47107 /****** - Begin Original Message - ******/
47111 >I have an idea for next release.
47112 >A secure link between services and ircd.
47113 >Now many ircd, like Unreal, tr-ircd, bahamut supports a ssl link.
47118 >------------------------------------------------------------------
47119 >To unsubscribe or change your subscription options, visit:
47120 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
47122 /******* - End Original Message - *******/
47127 From ircserv at elric.net Wed Sep 3 20:49:47 2003
47128 From: ircserv at elric.net (Brent DiNicola)
47129 Date: Sat Oct 23 23:10:10 2004
47130 Subject: [IRCServices Coding] Which route to take - Module?
47131 Message-ID: <5.2.1.1.0.20030903223929.016e4648@mail.elric.net>
47133 It wasn't an easy subject to sum up in just a few words.
47135 I am wanting to do something to the ircservices code, I want to change
47136 the way the notice() works. I know that modifying the send.c would be
47137 very frowned upon and then I got to thinking and had suggested that I
47138 maybe make a module to keep the information for me. I know it's against
47139 the RFC, but I am pressed against a brick wall here, I have to give the users
47140 an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
47141 I would like to give them the option of turning on PRIVMSG but have NOTICE
47142 be the default, that would get the lazy people to use NOTICE. Eventually
47143 getting rid of this problem. In the mean time, I was thinking what is the best
47144 way to go about this without causing trouble for me and anyone else who has
47145 to deal with this code. Is it possible or even suggested to make a module that
47146 would replace the notice() from send.c with it's own, leaving the code in
47148 alone and not causing troubles down the road. Suggestions were that I make a
47149 module that kept the info for each nick's setting and then if I could override
47150 the notice() and notice_lang() and notice_help() in send.c that would keep
47152 other code clean and not cause other troubles. I want to know what the best
47153 way to do this would be, I know it's against RFC but I want to move to newer
47154 services than the 1.4.3pre4 that we are using now and add modules so that I
47155 can do things down the line. They are used to having PRIVMSG and I can't just
47156 change it without running people off, so if I can make PRIVMSG an option
47157 then I can't be blamed if they are lazy. Opinions on how to go about this? I
47158 know this topic has been asked before and I know your not going to make it
47159 part of your code, I just wanted to know from the people who know the code
47160 really well what the best route to take would be to do the least amount of
47161 damage. (And if someone has done this.. please let me know what you did,
47162 examples would rock)
47170 ----------------------------------------------------------
47172 | The Whitewolf of Immyrr |
47173 | <elric@elric.net> |
47174 | http://www.melnibone.net |
47175 | Disclaimer: Any opinions expressed here are |
47176 | from my dog. Any liabilities fall to the dog. |
47177 -----------------------------------------------------------
47180 From Craig at chatspike.net Wed Sep 3 21:18:29 2003
47181 From: Craig at chatspike.net (Craig McLure)
47182 Date: Sat Oct 23 23:10:10 2004
47183 Subject: [IRCServices Coding] Which route to take - Module?
47184 Message-ID: <20030904041818.TXAK19019.mta3-svc.business.ntl.com@i-br0ked-it>
47186 lol, Our help no good? :P
47188 i still say module with seperate database (with the nickgroup, and if this option is on or off (This saves having to modify the main nick.db) , somehow extending the /ns SET command to include a new option.. and replacing what ever function sends notices with something that uses an if to query your new database..
47190 Dont ask me for source on this.. i'm just theorising :)
47192 /****************************************
47193 * Craig "FrostyCoolSlug" McLure
47194 ************* - SpamBox - **************
47195 * InspIRCd - http://www.inspircd.org
47196 * ChatSpike - http://www.chatspike.net
47197 * WinBot - http://www.winbot.co.uk
47198 ****************************************/
47200 /****************************************
47201 * From - Brent DiNicola <ircserv@elric.net>
47202 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
47203 * Sent - 2003-09-03 @ 22:49:00
47204 * Subject - [IRCServices Coding] Which route to take - Module?
47205 ****************************************/
47207 /****** - Begin Original Message - ******/
47209 >It wasn't an easy subject to sum up in just a few words.
47211 >I am wanting to do something to the ircservices code, I want to change
47212 >the way the notice() works. I know that modifying the send.c would be
47213 >very frowned upon and then I got to thinking and had suggested that I
47214 >maybe make a module to keep the information for me. I know it's against
47215 >the RFC, but I am pressed against a brick wall here, I have to give the users
47216 >an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
47217 >I would like to give them the option of turning on PRIVMSG but have NOTICE
47218 >be the default, that would get the lazy people to use NOTICE. Eventually
47219 >getting rid of this problem. In the mean time, I was thinking what is the best
47220 >way to go about this without causing trouble for me and anyone else who has
47221 >to deal with this code. Is it possible or even suggested to make a module that
47222 >would replace the notice() from send.c with it's own, leaving the code in
47224 >alone and not causing troubles down the road. Suggestions were that I make a
47225 >module that kept the info for each nick's setting and then if I could override
47226 >the notice() and notice_lang() and notice_help() in send.c that would keep
47228 >other code clean and not cause other troubles. I want to know what the best
47229 >way to do this would be, I know it's against RFC but I want to move to newer
47230 >services than the 1.4.3pre4 that we are using now and add modules so that I
47231 >can do things down the line. They are used to having PRIVMSG and I can't just
47232 >change it without running people off, so if I can make PRIVMSG an option
47233 >then I can't be blamed if they are lazy. Opinions on how to go about this? I
47234 >know this topic has been asked before and I know your not going to make it
47235 >part of your code, I just wanted to know from the people who know the code
47236 >really well what the best route to take would be to do the least amount of
47237 >damage. (And if someone has done this.. please let me know what you did,
47238 >examples would rock)
47246 >----------------------------------------------------------
47247 >| Brent DiNicola |
47248 >| The Whitewolf of Immyrr |
47249 >| <elric@elric.net> |
47250 >| http://www.melnibone.net |
47251 >| Disclaimer: Any opinions expressed here are |
47252 >| from my dog. Any liabilities fall to the dog. |
47253 >-----------------------------------------------------------
47255 >------------------------------------------------------------------
47256 >To unsubscribe or change your subscription options, visit:
47257 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
47260 /******* - End Original Message - *******/
47265 From uhc0 at rz.uni-karlsruhe.de Thu Sep 4 01:34:06 2003
47266 From: uhc0 at rz.uni-karlsruhe.de (Yusuf Iskenderoglu)
47267 Date: Sat Oct 23 23:10:10 2004
47268 Subject: [IRCServices Coding] Which route to take - Module?
47269 In-Reply-To: <5.2.1.1.0.20030903223929.016e4648@mail.elric.net>
47270 References: <5.2.1.1.0.20030903223929.016e4648@mail.elric.net>
47271 Message-ID: <1062664383.1917.15.camel@dreadnought.hadiko.de>
47275 Long question; long answer.
47276 First of all, you must come off the thoughts of "Against the RFC".
47277 Why? Because, tons of irc servers available do provide techniques, which
47278 do not appear, or appear differently on the irc RFC, so that by design
47279 these ircds are also against it. In most of the cases, these changes
47280 reflect themselves in their appropriate server-to-server protocols, and
47281 become transient to the clients, so that on client side, the protocol
47282 remains original. This is also the only way of ensuring that all of the
47283 clients can work with a specific irc daemon.
47285 The issue, why PRIVMSG instead of NOTICE is bad, does also result from
47286 the client-to-server part of the RFC. And it has a reason. Consider two
47287 automated clients (bots, services, etc) talking to each other with
47288 PRIVMSG, and saying things like:
47289 <NickServ> otherwise, I change your nick.
47290 <MyBot> Unknown command otherwise. Please repeat your query.
47291 <NickServ> Unknown command UNKNOWN.
47292 <MyBot> Unknown command unknown. Please repeat your query.
47293 <NickServ> Unknown command UNKNOWN.
47294 <MyBot> Unknown command unknown. Please repeat your query.
47295 <NickServ> Unknown command UNKNOWN.
47296 <MyBot> Unknown command unknown. Please repeat your query.
47297 <NickServ> Unknown command UNKNOWN.
47298 <MyBot> Unknown command unknown. Please repeat your query.
47301 Do you understand, what problem may conclude due to PRIVMSG? RFC says
47302 clearly, that clients shall not generate automatic replies to NOTICES.
47303 That way, your bot would not "talk" to NickServ after a NOTICE anymore.
47306 The most easy implementation of this is creating a NF_USE_PRIVMSG flag,
47307 with a value far greater than any of the built-in, so that in future
47308 this flag does not collide with any of the original flags.
47310 Then you create the new SET command for this, as well as its help text,
47311 primarily in the english language file. That part of the work is
47314 Afterwards, you should modify notice_lang, and check for the
47315 NF_USE_PRIVMSG flag of the "ngi" being used; and if true, send PRIVMSG
47316 instead. The same for notice_help. And your case could be marked as
47319 Do keep in mind that requesting support for modified services versions
47320 are subject to be ignored.
47325 On Thu, 2003-09-04 at 05:49, Brent DiNicola wrote:
47326 > It wasn't an easy subject to sum up in just a few words.
47328 > I am wanting to do something to the ircservices code, I want to change
47329 > the way the notice() works. I know that modifying the send.c would be
47330 > very frowned upon and then I got to thinking and had suggested that I
47331 > maybe make a module to keep the information for me. I know it's against
47332 > the RFC, but I am pressed against a brick wall here, I have to give the users
47333 > an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
47334 > I would like to give them the option of turning on PRIVMSG but have NOTICE
47335 > be the default, that would get the lazy people to use NOTICE. Eventually
47336 > getting rid of this problem. In the mean time, I was thinking what is the best
47337 > way to go about this without causing trouble for me and anyone else who has
47338 > to deal with this code. Is it possible or even suggested to make a module that
47339 > would replace the notice() from send.c with it's own, leaving the code in
47341 > alone and not causing troubles down the road. Suggestions were that I make a
47342 > module that kept the info for each nick's setting and then if I could override
47343 > the notice() and notice_lang() and notice_help() in send.c that would keep
47345 > other code clean and not cause other troubles. I want to know what the best
47346 > way to do this would be, I know it's against RFC but I want to move to newer
47347 > services than the 1.4.3pre4 that we are using now and add modules so that I
47348 > can do things down the line. They are used to having PRIVMSG and I can't just
47349 > change it without running people off, so if I can make PRIVMSG an option
47350 > then I can't be blamed if they are lazy. Opinions on how to go about this? I
47351 > know this topic has been asked before and I know your not going to make it
47352 > part of your code, I just wanted to know from the people who know the code
47353 > really well what the best route to take would be to do the least amount of
47354 > damage. (And if someone has done this.. please let me know what you did,
47355 > examples would rock)
47363 > ----------------------------------------------------------
47364 > | Brent DiNicola |
47365 > | The Whitewolf of Immyrr |
47366 > | <elric@elric.net> |
47367 > | http://www.melnibone.net |
47368 > | Disclaimer: Any opinions expressed here are |
47369 > | from my dog. Any liabilities fall to the dog. |
47370 > -----------------------------------------------------------
47372 > ------------------------------------------------------------------
47373 > To unsubscribe or change your subscription options, visit:
47374 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
47376 ------------------------------------------------------------------
47377 | Yusuf Iskenderoglu | You get to meet all sorts, |
47378 | eMail - uhc0@stud.uni-karlsruhe.de| in this line of work... |
47379 | eMail - s_iskend@ira.uka.de | |
47380 | ICQ UIN : 20587464 \ TimeMr14C | |
47381 ------------------------------------------------------------------
47384 From griever at t2n.org Thu Sep 4 13:31:44 2003
47385 From: griever at t2n.org (Robert F Merrill)
47386 Date: Sat Oct 23 23:10:10 2004
47387 Subject: [IRCServices Coding] Which route to take - Module?
47388 References: <5.2.1.1.0.20030903223929.016e4648@mail.elric.net>
47389 Message-ID: <3F57A0BA.9080909@t2n.org>
47391 Brent DiNicola wrote:
47393 > It wasn't an easy subject to sum up in just a few words.
47395 > I am wanting to do something to the ircservices code, I want to change
47396 > the way the notice() works. I know that modifying the send.c would be
47397 > very frowned upon and then I got to thinking and had suggested that I
47398 > maybe make a module to keep the information for me. I know it's against
47399 > the RFC, but I am pressed against a brick wall here, I have to give
47401 > an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
47402 > I would like to give them the option of turning on PRIVMSG but have
47404 > be the default, that would get the lazy people to use NOTICE. Eventually
47405 > getting rid of this problem. In the mean time, I was thinking what is
47407 > way to go about this without causing trouble for me and anyone else
47409 > to deal with this code. Is it possible or even suggested to make a
47411 > would replace the notice() from send.c with it's own, leaving the code
47413 > alone and not causing troubles down the road. Suggestions were that I
47415 > module that kept the info for each nick's setting and then if I could
47417 > the notice() and notice_lang() and notice_help() in send.c that would
47419 > other code clean and not cause other troubles. I want to know what the
47421 > way to do this would be, I know it's against RFC but I want to move to
47423 > services than the 1.4.3pre4 that we are using now and add modules so
47425 > can do things down the line. They are used to having PRIVMSG and I
47427 > change it without running people off, so if I can make PRIVMSG an option
47428 > then I can't be blamed if they are lazy. Opinions on how to go about
47430 > know this topic has been asked before and I know your not going to
47432 > part of your code, I just wanted to know from the people who know the
47434 > really well what the best route to take would be to do the least
47436 > damage. (And if someone has done this.. please let me know what you did,
47437 > examples would rock)
47445 > ----------------------------------------------------------
47446 > | Brent DiNicola |
47447 > | The Whitewolf of Immyrr |
47448 > | <elric@elric.net> |
47449 > | http://www.melnibone.net |
47450 > | Disclaimer: Any opinions expressed here are |
47451 > | from my dog. Any liabilities fall to the dog. |
47452 > -----------------------------------------------------------
47453 > ------------------------------------------------------------------
47454 > To unsubscribe or change your subscription options, visit:
47455 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
47459 Services is not the place to fix broken clients, and any client which
47460 doesn't display notices correctly is broken. If someone wants to see
47461 notices differently, they can either
47462 a) change their client or in the case of webtv b) change the ircd
47464 services is the wrong thing to change
47467 From Craig at chatspike.net Thu Sep 4 13:52:48 2003
47468 From: Craig at chatspike.net (Craig McLure)
47469 Date: Sat Oct 23 23:10:10 2004
47470 Subject: [IRCServices Coding] Which route to take - Module?
47471 Message-ID: <20030904205232.SDRM23096.mta6-svc.business.ntl.com@i-br0ked-it>
47473 dont mean to sound rude, but this isnt a 'moral' discussion, as it were, rather than saying 'I dont think this needs done', i think it would be best to help him.. its not a discussion on if its right or wrong, its a 'How to do it' discussion.. If you cant contribute to this.. please ignore this 'thread' :p
47475 /****************************************
47476 * Craig "FrostyCoolSlug" McLure
47477 ************* - SpamBox - **************
47478 * InspIRCd - http://www.inspircd.org
47479 * ChatSpike - http://www.chatspike.net
47480 * WinBot - http://www.winbot.co.uk
47481 ****************************************/
47483 /****************************************
47484 * From - Robert F Merrill <griever@t2n.org>
47485 * To - IRC Services Coding Mailing List <ircservices-coding@ircservices.za.net>
47486 * Sent - 2003-09-04 @ 16:29:00
47487 * Subject - Re: [IRCServices Coding] Which route to take - Module?
47488 ****************************************/
47490 /****** - Begin Original Message - ******/
47492 >Brent DiNicola wrote:
47494 >> It wasn't an easy subject to sum up in just a few words.
47496 >> I am wanting to do something to the ircservices code, I want to change
47497 >> the way the notice() works. I know that modifying the send.c would be
47498 >> very frowned upon and then I got to thinking and had suggested that I
47499 >> maybe make a module to keep the information for me. I know it's against
47500 >> the RFC, but I am pressed against a brick wall here, I have to give
47502 >> an option to use PRIVMSG or NOTICE. Now, to help people move to NOTICE
47503 >> I would like to give them the option of turning on PRIVMSG but have
47505 >> be the default, that would get the lazy people to use NOTICE. Eventually
47506 >> getting rid of this problem. In the mean time, I was thinking what is
47508 >> way to go about this without causing trouble for me and anyone else
47510 >> to deal with this code. Is it possible or even suggested to make a
47512 >> would replace the notice() from send.c with it's own, leaving the code
47514 >> alone and not causing troubles down the road. Suggestions were that I
47516 >> module that kept the info for each nick's setting and then if I could
47518 >> the notice() and notice_lang() and notice_help() in send.c that would
47520 >> other code clean and not cause other troubles. I want to know what the
47522 >> way to do this would be, I know it's against RFC but I want to move to
47524 >> services than the 1.4.3pre4 that we are using now and add modules so
47526 >> can do things down the line. They are used to having PRIVMSG and I
47528 >> change it without running people off, so if I can make PRIVMSG an option
47529 >> then I can't be blamed if they are lazy. Opinions on how to go about
47531 >> know this topic has been asked before and I know your not going to
47533 >> part of your code, I just wanted to know from the people who know the
47535 >> really well what the best route to take would be to do the least
47537 >> damage. (And if someone has done this.. please let me know what you did,
47538 >> examples would rock)
47546 >> ----------------------------------------------------------
47547 >> | Brent DiNicola |
47548 >> | The Whitewolf of Immyrr |
47549 >> | <elric@elric.net> |
47550 >> | http://www.melnibone.net |
47551 >> | Disclaimer: Any opinions expressed here are |
47552 >> | from my dog. Any liabilities fall to the dog. |
47553 >> -----------------------------------------------------------
47554 >> ------------------------------------------------------------------
47555 >> To unsubscribe or change your subscription options, visit:
47556 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
47560 >Services is not the place to fix broken clients, and any client which
47561 >doesn't display notices correctly is broken. If someone wants to see
47562 >notices differently, they can either
47563 >a) change their client or in the case of webtv b) change the ircd
47565 >services is the wrong thing to change
47567 >------------------------------------------------------------------
47568 >To unsubscribe or change your subscription options, visit:
47569 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
47572 /******* - End Original Message - *******/
47577 From quension at mac.com Thu Sep 4 13:54:21 2003
47578 From: quension at mac.com (Trevor Talbot)
47579 Date: Sat Oct 23 23:10:10 2004
47580 Subject: [IRCServices Coding] Which route to take - Module?
47581 In-Reply-To: <3F57A0BA.9080909@t2n.org>
47582 Message-ID: <E8AC4DDC-DF19-11D7-905C-0003938D6866@mac.com>
47584 On Thursday, Sep 4, 2003, at 13:29 US/Pacific, Robert F Merrill wrote:
47586 > Brent DiNicola wrote:
47588 >> It wasn't an easy subject to sum up in just a few words.
47592 > Services is not the place to fix broken clients, and any client which
47593 > doesn't display notices correctly is broken. If someone wants to see
47594 > notices differently, they can either a) change their client or in the
47595 > case of webtv b) change the ircd
47597 > services is the wrong thing to change
47599 And telling someone what they obviously already know is generally not a
47600 good idea. Especially when they spent a very long paragraph defending
47601 their decision in the first place.
47603 This is the coding list, not the feature request list. He asked for
47604 code design approaches, not for political insight.
47609 From diego at redesul.net Thu Sep 18 16:29:40 2003
47610 From: diego at redesul.net (Diego B. Contezini)
47611 Date: Sat Oct 23 23:10:10 2004
47612 Subject: [IRCServices Coding] Re: How to get a core..
47613 Message-ID: <001c01c37e2d$c95d7840$3cc8a8c0@angel>
47615 Oooopz, im answering my ask...
47616 Looking in FAQ, where i should look before ask (sorry), I seen that you need
47617 to change ./configure to drop a core.
47618 If someone more is needing it, is just configure with:
47619 ./configure -dumpcore -cflags -g -defaults
47625 ----- Original Message -----
47626 From: "Diego B. Contezini" <diego@redesul.net>
47627 To: <ircservices-coding@ircservices.za.net>
47628 Sent: Thursday, September 18, 2003 6:35 PM
47629 Subject: How to get a core..
47632 > Hello, im destruct_, im the administrator of the RedeSul Network.
47633 > (irc.redesul.net).
47634 > I'm with 28000 nick registers, sometimes our network get 5500 simultaneous
47635 > users, and we are very happy with your services.
47636 > Im wanting to help to search and stops bugs on ircservices, but i never
47639 > I tryed ulimit -c unlimited before run it, but it never drop a core...
47640 > Someone have any idea about how i can get it, to debug without need to
47642 > the services while debugging?
47643 > Its segfaulting approx. all days, one time for day.. sometimes get 2 days
47644 > without to go down.
47645 > Im with a redhat 9.
47649 > Diego B. Contezini aka destruct_ | irc.redesul.net
47650 > (Sorry for my confuse english.)
47654 From diego at redesul.net Thu Sep 18 17:12:05 2003
47655 From: diego at redesul.net (Diego B. Contezini)
47656 Date: Sat Oct 23 23:10:10 2004
47657 Subject: [IRCServices Coding] How to get a core..
47658 References: <Law14-F109aJWJVUn700006a187@hotmail.com>
47659 Message-ID: <000901c37e2c$b8bd9980$3cc8a8c0@angel>
47661 Hello, im destruct_, im the administrator of the RedeSul Network.
47663 I'm with 28000 nick registers, sometimes our network get 5500 simultaneous
47664 users, and we are very happy with your services.
47665 Im wanting to help to search and stops bugs on ircservices, but i never get
47667 I tryed ulimit -c unlimited before run it, but it never drop a core...
47668 Someone have any idea about how i can get it, to debug without need to break
47669 the services while debugging?
47670 Its segfaulting approx. all days, one time for day.. sometimes get 2 days
47671 without to go down.
47672 Im with a redhat 9.
47676 Diego B. Contezini aka destruct_ | irc.redesul.net
47677 (Sorry for my confuse english.)
47680 From engin at piratetv.net Sun Sep 21 09:37:08 2003
47681 From: engin at piratetv.net (engin@piratetv)
47682 Date: Sat Oct 23 23:10:10 2004
47683 Subject: [IRCServices Coding] operserv
47684 Message-ID: <002101c3805f$0910a4c0$c7cf87d4@ptv91i58zrrpyd>
47688 can anyone help or point me to some good documentation regarding a
47689 version of unreal ircd we are running on a mandrake linux box..im mailing
47690 on behalf of the administrator who usually uses ssh to get into the box
47691 and make changes so im not super technical myself.the issue is with
47692 operserv..i cant access any operserv commands from my machine ( which
47693 is on the same local network as the box running the irc server ) always
47694 get operserv - access denied message..so im assuming it doesent
47695 recognise my remote ip address at an administrator..does anyone know
47696 the right sort of commands to use to set my remote machine to be
47697 recognised as admin or can they point me to any good support docs
47698 as i havent been able to find any yet
47702 -------------- next part --------------
47703 An HTML attachment was scrubbed...
47704 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030921/fdc12b4e/attachment-0004.htm
47705 From Craig at chatspike.net Sun Sep 21 14:28:23 2003
47706 From: Craig at chatspike.net (Craig McLure)
47707 Date: Sat Oct 23 23:10:10 2004
47708 Subject: [IRCServices Coding] operserv
47709 Message-ID: <E1A1Bk4-0001Xo-00@ptb-mailc04.plus.net>
47711 make sure you are on the services administrator list, if you are not, get the root administrator to add you using the command:
47713 [22:27] -OperServ- Syntax: ADMIN ADD nickname
47714 [22:27] -OperServ- ADMIN DEL nickname
47715 [22:27] -OperServ- ADMIN LIST
47717 [22:27] -OperServ- Allows the Services super-user to add or remove nicknames
47718 [22:27] -OperServ- to or from the Services admin list. A user whose nickname
47719 [22:27] -OperServ- is on the Services admin list and who has identified to
47720 [22:27] -OperServ- NickServ will be able to access Services admin commands.
47722 [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the command.
47723 [22:27] -OperServ- All other use limited to Services super-user.
47727 /****************************************
47728 * Craig "FrostyCoolSlug" McLure
47729 ************* - SpamBox - **************
47730 * InspIRCd - http://www.inspircd.org
47731 * ChatSpike - http://www.chatspike.net
47732 * WinBot - http://www.winbot.co.uk
47733 ****************************************/
47735 /****************************************
47736 * From - engin <engin@piratetv.net>
47737 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
47738 * Sent - 2003-09-21 @ 17:40:00
47739 * Subject - [IRCServices Coding] operserv
47740 ****************************************/
47742 /****** - Begin Original Message - ******/
47746 >can anyone help or point me to some good documentation regarding a
47747 >version of unreal ircd we are running on a mandrake linux box..im mailing
47748 >on behalf of the administrator who usually uses ssh to get into the box
47749 >and make changes so im not super technical myself.the issue is with
47750 >operserv..i cant access any operserv commands from my machine ( which
47751 >is on the same local network as the box running the irc server ) always
47752 >get operserv - access denied message..so im assuming it doesent
47753 >recognise my remote ip address at an administrator..does anyone know
47754 >the right sort of commands to use to set my remote machine to be
47755 >recognised as admin or can they point me to any good support docs
47756 >as i havent been able to find any yet
47760 >------------------------------------------------------------------
47761 >To unsubscribe or change your subscription options, visit:
47762 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
47764 /******* - End Original Message - *******/
47768 From saturn at jetirc.net Sun Sep 21 15:24:25 2003
47769 From: saturn at jetirc.net (Saturn)
47770 Date: Sat Oct 23 23:10:10 2004
47771 Subject: [IRCServices Coding] operserv
47772 References: <002101c3805f$0910a4c0$c7cf87d4@ptv91i58zrrpyd>
47773 Message-ID: <002b01c3808e$f2590ee0$6401a8c0@turby>
47775 Contact me directly... I have quite a bit of experience with unreal and these services...
47779 ----- Original Message -----
47780 From: engin@piratetv
47781 To: ircservices-coding@ircservices.za.net
47782 Sent: Sunday, September 21, 2003 9:40 AM
47783 Subject: [IRCServices Coding] operserv
47788 can anyone help or point me to some good documentation regarding a
47789 version of unreal ircd we are running on a mandrake linux box..im mailing
47790 on behalf of the administrator who usually uses ssh to get into the box
47791 and make changes so im not super technical myself.the issue is with
47792 operserv..i cant access any operserv commands from my machine ( which
47793 is on the same local network as the box running the irc server ) always
47794 get operserv - access denied message..so im assuming it doesent
47795 recognise my remote ip address at an administrator..does anyone know
47796 the right sort of commands to use to set my remote machine to be
47797 recognised as admin or can they point me to any good support docs
47798 as i havent been able to find any yet
47805 ------------------------------------------------------------------------------
47808 ------------------------------------------------------------------
47809 To unsubscribe or change your subscription options, visit:
47810 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
47811 -------------- next part --------------
47812 An HTML attachment was scrubbed...
47813 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20030921/ca188e06/attachment-0004.html
47814 From saturn at jetirc.net Sun Sep 21 17:14:42 2003
47815 From: saturn at jetirc.net (Saturn)
47816 Date: Sat Oct 23 23:10:10 2004
47817 Subject: [IRCServices Coding] operserv
47818 References: <E1A1Bk4-0001Xo-00@ptb-mailc04.plus.net>
47819 Message-ID: <000d01c3809e$5b9d2800$6401a8c0@turby>
47821 Not to mention the obvious: You need to have an O:line and be opered up
47822 before Operserv will even listen to your commands without access denied....
47824 ----- Original Message -----
47825 From: "Craig McLure" <Craig@chatspike.net>
47826 To: "IRC Services Coding Mailing List"
47827 <ircservices-coding@ircservices.za.net>
47828 Sent: Sunday, September 21, 2003 3:28 PM
47829 Subject: Re: [IRCServices Coding] operserv
47832 make sure you are on the services administrator list, if you are not, get
47833 the root administrator to add you using the command:
47835 [22:27] -OperServ- Syntax: ADMIN ADD nickname
47836 [22:27] -OperServ- ADMIN DEL nickname
47837 [22:27] -OperServ- ADMIN LIST
47839 [22:27] -OperServ- Allows the Services super-user to add or remove nicknames
47840 [22:27] -OperServ- to or from the Services admin list. A user whose nickname
47841 [22:27] -OperServ- is on the Services admin list and who has identified to
47842 [22:27] -OperServ- NickServ will be able to access Services admin commands.
47844 [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
47846 [22:27] -OperServ- All other use limited to Services super-user.
47850 /****************************************
47851 * Craig "FrostyCoolSlug" McLure
47852 ************* - SpamBox - **************
47853 * InspIRCd - http://www.inspircd.org
47854 * ChatSpike - http://www.chatspike.net
47855 * WinBot - http://www.winbot.co.uk
47856 ****************************************/
47858 /****************************************
47859 * From - engin <engin@piratetv.net>
47860 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
47861 * Sent - 2003-09-21 @ 17:40:00
47862 * Subject - [IRCServices Coding] operserv
47863 ****************************************/
47865 /****** - Begin Original Message - ******/
47869 >can anyone help or point me to some good documentation regarding a
47870 >version of unreal ircd we are running on a mandrake linux box..im mailing
47871 >on behalf of the administrator who usually uses ssh to get into the box
47872 >and make changes so im not super technical myself.the issue is with
47873 >operserv..i cant access any operserv commands from my machine ( which
47874 >is on the same local network as the box running the irc server ) always
47875 >get operserv - access denied message..so im assuming it doesent
47876 >recognise my remote ip address at an administrator..does anyone know
47877 >the right sort of commands to use to set my remote machine to be
47878 >recognised as admin or can they point me to any good support docs
47879 >as i havent been able to find any yet
47883 >------------------------------------------------------------------
47884 >To unsubscribe or change your subscription options, visit:
47885 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
47887 /******* - End Original Message - *******/
47890 ------------------------------------------------------------------
47891 To unsubscribe or change your subscription options, visit:
47892 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
47895 From engin at piratetv.net Mon Sep 22 05:13:57 2003
47896 From: engin at piratetv.net (engin@piratetv)
47897 Date: Sat Oct 23 23:10:10 2004
47898 Subject: [IRCServices Coding] Re: IRCServices-Coding Digest, Vol 8, Issue 5
47899 References: <20030922120923.425971706D@snow.fingers.co.za>
47900 Message-ID: <003c01c38103$73a516f0$c7cf87d4@ptv91i58zrrpyd>
47902 many thanks for the replies..im going to get the info to the
47903 root administrator now and ill let you know how i get
47910 ----- Original Message -----
47911 From: <ircservices-coding-request@ircservices.za.net>
47912 To: <ircservices-coding@ircservices.za.net>
47913 Sent: Monday, September 22, 2003 1:09 PM
47914 Subject: IRCServices-Coding Digest, Vol 8, Issue 5
47917 > Send IRCServices-Coding mailing list submissions to
47918 > ircservices-coding@ircservices.za.net
47920 > To subscribe or unsubscribe via the World Wide Web, visit
47921 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
47922 > or, via email, send a message with subject or body 'help' to
47923 > ircservices-coding-request@ircservices.za.net
47925 > You can reach the person managing the list at
47926 > ircservices-coding-owner@ircservices.za.net
47928 > When replying, please edit your Subject line so it is more specific
47929 > than "Re: Contents of IRCServices-Coding digest..."
47934 > 1. operserv (engin@piratetv)
47935 > 2. Re: operserv (Craig McLure)
47936 > 3. Re: operserv (Saturn)
47937 > 4. Re: operserv (Saturn)
47940 > ----------------------------------------------------------------------
47943 > Date: Sun, 21 Sep 2003 17:40:15 +0100
47944 > From: "engin@piratetv" <engin@piratetv.net>
47945 > Subject: [IRCServices Coding] operserv
47946 > To: <ircservices-coding@ircservices.za.net>
47947 > Message-ID: <002101c3805f$0910a4c0$c7cf87d4@ptv91i58zrrpyd>
47948 > Content-Type: text/plain; charset="iso-8859-1"
47952 > can anyone help or point me to some good documentation regarding a
47953 > version of unreal ircd we are running on a mandrake linux box..im mailing
47954 > on behalf of the administrator who usually uses ssh to get into the box
47955 > and make changes so im not super technical myself.the issue is with
47956 > operserv..i cant access any operserv commands from my machine ( which
47957 > is on the same local network as the box running the irc server ) always
47958 > get operserv - access denied message..so im assuming it doesent
47959 > recognise my remote ip address at an administrator..does anyone know
47960 > the right sort of commands to use to set my remote machine to be
47961 > recognised as admin or can they point me to any good support docs
47962 > as i havent been able to find any yet
47966 > -------------- next part --------------
47967 > An HTML attachment was scrubbed...
47969 http://snow.fingers.co.za/pipermail/ircservices-coding/attachments/20030921/
47970 fdc12b4e/attachment-0001.htm
47972 > ------------------------------
47975 > Date: Sun, 21 Sep 2003 22:28:13 +0000
47976 > From: "Craig McLure" <Craig@chatspike.net>
47977 > Subject: Re: [IRCServices Coding] operserv
47978 > To: IRC Services Coding Mailing List
47979 > <ircservices-coding@ircservices.za.net>
47980 > Message-ID: <E1A1Bk4-0001Xo-00@ptb-mailc04.plus.net>
47981 > Content-Type: text/plain; charset="us-ascii"
47983 > make sure you are on the services administrator list, if you are not, get
47984 the root administrator to add you using the command:
47986 > [22:27] -OperServ- Syntax: ADMIN ADD nickname
47987 > [22:27] -OperServ- ADMIN DEL nickname
47988 > [22:27] -OperServ- ADMIN LIST
47989 > [22:27] -OperServ-
47990 > [22:27] -OperServ- Allows the Services super-user to add or remove
47992 > [22:27] -OperServ- to or from the Services admin list. A user whose
47994 > [22:27] -OperServ- is on the Services admin list and who has identified to
47995 > [22:27] -OperServ- NickServ will be able to access Services admin
47997 > [22:27] -OperServ-
47998 > [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
48000 > [22:27] -OperServ- All other use limited to Services super-user.
48004 > /****************************************
48005 > * Craig "FrostyCoolSlug" McLure
48006 > ************* - SpamBox - **************
48007 > * InspIRCd - http://www.inspircd.org
48008 > * ChatSpike - http://www.chatspike.net
48009 > * WinBot - http://www.winbot.co.uk
48010 > ****************************************/
48012 > /****************************************
48013 > * From - engin <engin@piratetv.net>
48014 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
48015 > * Sent - 2003-09-21 @ 17:40:00
48016 > * Subject - [IRCServices Coding] operserv
48017 > ****************************************/
48019 > /****** - Begin Original Message - ******/
48023 > >can anyone help or point me to some good documentation regarding a
48024 > >version of unreal ircd we are running on a mandrake linux box..im mailing
48025 > >on behalf of the administrator who usually uses ssh to get into the box
48026 > >and make changes so im not super technical myself.the issue is with
48027 > >operserv..i cant access any operserv commands from my machine ( which
48028 > >is on the same local network as the box running the irc server ) always
48029 > >get operserv - access denied message..so im assuming it doesent
48030 > >recognise my remote ip address at an administrator..does anyone know
48031 > >the right sort of commands to use to set my remote machine to be
48032 > >recognised as admin or can they point me to any good support docs
48033 > >as i havent been able to find any yet
48037 > >------------------------------------------------------------------
48038 > >To unsubscribe or change your subscription options, visit:
48039 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
48041 > /******* - End Original Message - *******/
48045 > ------------------------------
48048 > Date: Sun, 21 Sep 2003 15:23:13 -0700
48049 > From: "Saturn" <saturn@jetirc.net>
48050 > Subject: Re: [IRCServices Coding] operserv
48051 > To: "IRC Services Coding Mailing List"
48052 > <ircservices-coding@ircservices.za.net>
48053 > Message-ID: <002b01c3808e$f2590ee0$6401a8c0@turby>
48054 > Content-Type: text/plain; charset="iso-8859-1"
48056 > Contact me directly... I have quite a bit of experience with unreal and
48061 > ----- Original Message -----
48062 > From: engin@piratetv
48063 > To: ircservices-coding@ircservices.za.net
48064 > Sent: Sunday, September 21, 2003 9:40 AM
48065 > Subject: [IRCServices Coding] operserv
48070 > can anyone help or point me to some good documentation regarding a
48071 > version of unreal ircd we are running on a mandrake linux box..im
48073 > on behalf of the administrator who usually uses ssh to get into the box
48074 > and make changes so im not super technical myself.the issue is with
48075 > operserv..i cant access any operserv commands from my machine ( which
48076 > is on the same local network as the box running the irc server ) always
48077 > get operserv - access denied message..so im assuming it doesent
48078 > recognise my remote ip address at an administrator..does anyone know
48079 > the right sort of commands to use to set my remote machine to be
48080 > recognised as admin or can they point me to any good support docs
48081 > as i havent been able to find any yet
48088 > --------------------------------------------------------------------------
48092 > ------------------------------------------------------------------
48093 > To unsubscribe or change your subscription options, visit:
48094 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
48095 > -------------- next part --------------
48096 > An HTML attachment was scrubbed...
48098 http://snow.fingers.co.za/pipermail/ircservices-coding/attachments/20030921/
48099 ca188e06/attachment-0001.htm
48101 > ------------------------------
48104 > Date: Sun, 21 Sep 2003 17:13:31 -0700
48105 > From: "Saturn" <saturn@jetirc.net>
48106 > Subject: Re: [IRCServices Coding] operserv
48107 > To: "IRC Services Coding Mailing List"
48108 > <ircservices-coding@ircservices.za.net>
48109 > Message-ID: <000d01c3809e$5b9d2800$6401a8c0@turby>
48110 > Content-Type: text/plain; charset="iso-8859-1"
48112 > Not to mention the obvious: You need to have an O:line and be opered up
48113 > before Operserv will even listen to your commands without access
48116 > ----- Original Message -----
48117 > From: "Craig McLure" <Craig@chatspike.net>
48118 > To: "IRC Services Coding Mailing List"
48119 > <ircservices-coding@ircservices.za.net>
48120 > Sent: Sunday, September 21, 2003 3:28 PM
48121 > Subject: Re: [IRCServices Coding] operserv
48124 > make sure you are on the services administrator list, if you are not, get
48125 > the root administrator to add you using the command:
48127 > [22:27] -OperServ- Syntax: ADMIN ADD nickname
48128 > [22:27] -OperServ- ADMIN DEL nickname
48129 > [22:27] -OperServ- ADMIN LIST
48130 > [22:27] -OperServ-
48131 > [22:27] -OperServ- Allows the Services super-user to add or remove
48133 > [22:27] -OperServ- to or from the Services admin list. A user whose
48135 > [22:27] -OperServ- is on the Services admin list and who has identified to
48136 > [22:27] -OperServ- NickServ will be able to access Services admin
48138 > [22:27] -OperServ-
48139 > [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
48141 > [22:27] -OperServ- All other use limited to Services super-user.
48145 > /****************************************
48146 > * Craig "FrostyCoolSlug" McLure
48147 > ************* - SpamBox - **************
48148 > * InspIRCd - http://www.inspircd.org
48149 > * ChatSpike - http://www.chatspike.net
48150 > * WinBot - http://www.winbot.co.uk
48151 > ****************************************/
48153 > /****************************************
48154 > * From - engin <engin@piratetv.net>
48155 > * To - ircservices-coding <ircservices-coding@ircservices.za.net>
48156 > * Sent - 2003-09-21 @ 17:40:00
48157 > * Subject - [IRCServices Coding] operserv
48158 > ****************************************/
48160 > /****** - Begin Original Message - ******/
48164 > >can anyone help or point me to some good documentation regarding a
48165 > >version of unreal ircd we are running on a mandrake linux box..im mailing
48166 > >on behalf of the administrator who usually uses ssh to get into the box
48167 > >and make changes so im not super technical myself.the issue is with
48168 > >operserv..i cant access any operserv commands from my machine ( which
48169 > >is on the same local network as the box running the irc server ) always
48170 > >get operserv - access denied message..so im assuming it doesent
48171 > >recognise my remote ip address at an administrator..does anyone know
48172 > >the right sort of commands to use to set my remote machine to be
48173 > >recognised as admin or can they point me to any good support docs
48174 > >as i havent been able to find any yet
48178 > >------------------------------------------------------------------
48179 > >To unsubscribe or change your subscription options, visit:
48180 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
48182 > /******* - End Original Message - *******/
48185 > ------------------------------------------------------------------
48186 > To unsubscribe or change your subscription options, visit:
48187 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
48190 > ------------------------------
48192 > _______________________________________________
48193 > IRCServices-Coding mailing list
48194 > IRCServices-Coding@ircservices.za.net
48195 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
48198 > End of IRCServices-Coding Digest, Vol 8, Issue 5
48199 > ************************************************
48202 From diego at redesul.net Sun Oct 5 22:45:19 2003
48203 From: diego at redesul.net (Diego B. Contezini)
48204 Date: Sat Oct 23 23:10:10 2004
48205 Subject: [IRCServices Coding] Bug....
48206 References: <E1A1Bk4-0001Xo-00@ptb-mailc04.plus.net>
48207 <000d01c3809e$5b9d2800$6401a8c0@turby>
48208 Message-ID: <003b01c38b91$5f6a32e0$3cc8a8c0@angel>
48210 Sometimes has occur this bug, last 1 year....
48211 on a network with 30k registers, its happening with latency of 3.. 4
48214 someone have any idea?
48216 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
48217 av=0xbfffeec8) at channels.c:278
48220 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
48221 av=0xbfffeec8) at channels.c:278
48222 chan = (Channel *) 0xa97b6b8
48223 s = 0x20656c62 <Address 0x20656c62 out of bounds>
48225 modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
48226 #1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:680
48228 "-isl\000\037\006\bp?????????@???\006\b\000\000\000\000\000\000\000B\000\000
48229 \000\0007 \006\b\003\000\000\000TZ\000\000????????????
48230 ?????????\001\200??????@???\006\b@???\006\b@???\006\b@???\006\bO???\006\b@\0
48231 02\a\b@???\006\b@\002\a\b", '\0' <repeats 20 times>,
48232 "\027\000\000\000\000\000\000\000W???\022B\000\000\000\000\000\000\000\000\0
48233 05\000\000\000\210o\a\bTZ\000\000\000\000\000\000???????????????<\023B\001\0
48234 00\000\000???????????????m\tBd???\022B???q\a\b\v???\006B\024\032\023B\024\03
48235 2\023B3\035\rB\024\032\023B??????\006B\003\000\000\000????????????\027\000\0
48236 00\000\000\000\000\000\024\032"...
48237 s = 0xbfffeef0 "-isl"
48238 argv = {0xa97b6c0 "#young", 0x20656c62 <Address 0x20656c62 out of
48240 0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 out
48241 of bounds>, 0x42133cec "\004", 0xbffff1fc "",
48242 0x4204533d "\201?????????\016", 0x42131a14 " \031\023B???h\001@`???"}
48246 #2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
48250 md = (struct modedata *) 0x0
48255 #3 0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at main.c:269
48257 now_msec = 241253125
48258 last_update = 1065392973
48259 last_check = 241252363
48260 #4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
48261 No symbol table info available.
48266 From achurch at achurch.org Mon Oct 6 00:41:54 2003
48267 From: achurch at achurch.org (Andrew Church)
48268 Date: Sat Oct 23 23:10:10 2004
48269 Subject: [IRCServices Coding] Bug....
48270 In-Reply-To: <003b01c38b91$5f6a32e0$3cc8a8c0@angel>
48271 Message-ID: <3f811cad.24262@achurch.org>
48276 achurch@achurch.org
48277 http://achurch.org/
48279 >Sometimes has occur this bug, last 1 year....
48280 >on a network with 30k registers, its happening with latency of 3.. 4
48283 >someone have any idea?
48285 >#0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
48286 >av=0xbfffeec8) at channels.c:278
48289 >#0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
48290 >av=0xbfffeec8) at channels.c:278
48291 > chan = (Channel *) 0xa97b6b8
48292 > s = 0x20656c62 <Address 0x20656c62 out of bounds>
48294 > modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
48295 >#1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:68
48298 >"-isl\000\037\006\bp���@�\006\b\000\000\0
48299 >00\000\000\000\000B\000\000
48300 >\000\0007 \006\b\003\000\000\000TZ\000\000���ï¿
48302 >���\001\200��@�\006\b@ï
48303 >¿½\006\b@�\006\b@�\006\bO�\006\b@\0
48304 >02\a\b@�\006\b@\002\a\b", '\0' <repeats 20 times>,
48305 >"\027\000\000\000\000\000\000\000W�\022B\000\000\000\000\000\000\
48307 >05\000\000\000\210o\a\bTZ\000\000\000\000\000\000��ï¿
48308 >½ï¿½ï¿½<\023B\001\0
48309 >00\000\000�����m\tBd�\022
48310 >B�q\a\b\v�\006B\024\032\023B\024\03
48311 >2\023B3\035\rB\024\032\023B��\006B\003\000\000\000�
48313 >00\000\000\000\000\000\024\032"...
48314 > s = 0xbfffeef0 "-isl"
48315 > argv = {0xa97b6c0 "#young", 0x20656c62 <Address 0x20656c62 out
48318 > 0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 o
48320 >of bounds>, 0x42133cec "\004", 0xbffff1fc "",
48321 > 0x4204533d "\201���\016", 0x42131a14 " \031\023
48326 >#2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:32
48331 > md = (struct modedata *) 0x0
48336 >#3 0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at ma
48339 > now_msec = 241253125
48340 > last_update = 1065392973
48341 > last_check = 241252363
48342 >#4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
48343 >No symbol table info available.
48347 >------------------------------------------------------------------
48348 >To unsubscribe or change your subscription options, visit:
48349 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
48351 From diego at redesul.net Mon Oct 6 02:36:40 2003
48352 From: diego at redesul.net (Diego B. Contezini)
48353 Date: Sat Oct 23 23:10:10 2004
48354 Subject: [IRCServices Coding] Bug....
48355 References: <3f811cad.24262@achurch.org>
48356 Message-ID: <005501c38bed$4c9b1dd0$3cc8a8c0@angel>
48359 ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
48363 Its the last version.......
48366 ----- Original Message -----
48367 From: "Andrew Church" <achurch@achurch.org>
48368 To: <ircservices-coding@ircservices.za.net>
48369 Sent: Monday, October 06, 2003 4:41 AM
48370 Subject: Re: [IRCServices Coding] Bug....
48376 > achurch@achurch.org
48377 > http://achurch.org/
48379 > >Sometimes has occur this bug, last 1 year....
48380 > >on a network with 30k registers, its happening with latency of 3.. 4
48383 > >someone have any idea?
48385 > >#0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
48386 > >av=0xbfffeec8) at channels.c:278
48387 > >278 while (*s) {
48389 > >#0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
48390 > >av=0xbfffeec8) at channels.c:278
48391 > > chan = (Channel *) 0xa97b6b8
48392 > > s = 0x20656c62 <Address 0x20656c62 out of bounds>
48394 > > modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
48395 > >#1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:68
48398 > >"-isl\000\037\006\bp?????????@???\006\b\000\000\0
48399 > >00\000\000\000\000B\000\000
48400 > >\000\0007 \006\b\003\000\000\000TZ\000\000???????????
48402 > >?????????\001\200??????@???\006\b@?
48403 > >??\006\b@???\006\b@???\006\bO???\006\b@\0
48404 > >02\a\b@???\006\b@\002\a\b", '\0' <repeats 20 times>,
48405 > >"\027\000\000\000\000\000\000\000W???\022B\000\000\000\000\000\000\
48407 > >05\000\000\000\210o\a\bTZ\000\000\000\000\000\000????????
48408 > >???????<\023B\001\0
48409 > >00\000\000???????????????m\tBd???\022
48410 > >B???q\a\b\v???\006B\024\032\023B\024\03
48411 > >2\023B3\035\rB\024\032\023B??????\006B\003\000\000\000???
48412 > >?????????\027\000\0
48413 > >00\000\000\000\000\000\024\032"...
48414 > > s = 0xbfffeef0 "-isl"
48415 > > argv = {0xa97b6c0 "#young", 0x20656c62 <Address 0x20656c62 out
48418 > > 0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 o
48420 > >of bounds>, 0x42133cec "\004", 0xbffff1fc "",
48421 > > 0x4204533d "\201?????????\016", 0x42131a14 " \031\023
48422 > >B???h\001@`???"}
48426 > >#2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:32
48430 > > modes_orig = 0x0
48431 > > md = (struct modedata *) 0x0
48436 > >#3 0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at ma
48438 > > now = 1065393142
48439 > > now_msec = 241253125
48440 > > last_update = 1065392973
48441 > > last_check = 241252363
48442 > >#4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
48443 > >No symbol table info available.
48447 > >------------------------------------------------------------------
48448 > >To unsubscribe or change your subscription options, visit:
48449 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
48450 > ------------------------------------------------------------------
48451 > To unsubscribe or change your subscription options, visit:
48452 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
48456 From achurch at achurch.org Mon Oct 6 06:45:43 2003
48457 From: achurch at achurch.org (Andrew Church)
48458 Date: Sat Oct 23 23:10:10 2004
48459 Subject: [IRCServices Coding] Bug....
48460 In-Reply-To: <005501c38bed$4c9b1dd0$3cc8a8c0@angel>
48461 Message-ID: <3f8171f9.25006@achurch.org>
48464 >ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
48468 >Its the last version.......
48470 Then send a full debug log (from startup to crash), or I can't help.
48473 achurch@achurch.org
48474 http://achurch.org/
48476 From diego at redesul.net Mon Oct 6 17:16:29 2003
48477 From: diego at redesul.net (Diego B. Contezini)
48478 Date: Sat Oct 23 23:10:10 2004
48479 Subject: [IRCServices Coding] Bug....
48480 References: <3f8171f9.25006@achurch.org>
48481 Message-ID: <010601c38c68$2e6dc8a0$3cc8a8c0@angel>
48483 And how should be this log? i sent a backtrace......
48486 ----- Original Message -----
48487 From: "Andrew Church" <achurch@achurch.org>
48488 To: <ircservices-coding@ircservices.za.net>
48489 Sent: Monday, October 06, 2003 10:44 AM
48490 Subject: Re: [IRCServices Coding] Bug....
48494 > >ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
48495 > >18:41:36 BRT 2003
48498 > >Its the last version.......
48500 > Then send a full debug log (from startup to crash), or I can't help.
48503 > achurch@achurch.org
48504 > http://achurch.org/
48505 > ------------------------------------------------------------------
48506 > To unsubscribe or change your subscription options, visit:
48507 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
48511 From achurch at achurch.org Mon Oct 6 19:32:07 2003
48512 From: achurch at achurch.org (Andrew Church)
48513 Date: Sat Oct 23 23:10:10 2004
48514 Subject: [IRCServices Coding] Bug....
48515 In-Reply-To: <010601c38c68$2e6dc8a0$3cc8a8c0@angel>
48516 Message-ID: <3f822598.26100@achurch.org>
48518 >And how should be this log? i sent a backtrace......
48523 achurch@achurch.org
48524 http://achurch.org/
48526 From diego at redesul.net Mon Oct 6 22:36:40 2003
48527 From: diego at redesul.net (Diego B. Contezini)
48528 Date: Sat Oct 23 23:10:10 2004
48529 Subject: [IRCServices Coding] Bug....
48530 References: <3f822598.26100@achurch.org>
48531 Message-ID: <011601c38c94$ebc3ec00$3cc8a8c0@angel>
48534 If i start it with -debug it will get me gb's of information. This occur
48535 after days with services up, i will try to run it into a screen.... with
48540 ----- Original Message -----
48541 From: "Andrew Church" <achurch@achurch.org>
48542 To: <ircservices-coding@ircservices.za.net>
48543 Sent: Monday, October 06, 2003 11:31 PM
48544 Subject: Re: [IRCServices Coding] Bug....
48547 > >And how should be this log? i sent a backtrace......
48552 > achurch@achurch.org
48553 > http://achurch.org/
48554 > ------------------------------------------------------------------
48555 > To unsubscribe or change your subscription options, visit:
48556 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
48560 From saturn at jetirc.net Fri Oct 10 15:48:47 2003
48561 From: saturn at jetirc.net (Saturn)
48562 Date: Sat Oct 23 23:10:10 2004
48563 Subject: [IRCServices Coding] Akill problem in 5.0.22
48564 References: <14C7EDD0-DC1B-11D7-8505-0003938D6866@mac.com>
48565 Message-ID: <004001c38f80$9f635960$6401a8c0@turby>
48567 Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
48568 duplicate exit system notice that happens in 3.1.6).
48570 I just today added an akill (+0 time) .. I DO have the immediate auto kill
48571 option un-commented in the modules.conf, but it still didn't bother scanning
48572 for victims matching my akill mask nor did it actually KILL anyone... It
48573 works if they are manually killed and then try to re-connect, but I thought
48574 that new option was so Services will immediately scan for and kill anyone
48575 online that matches the mask as soon as the new akill is added...
48577 First: IS that what it's supposed to do?
48579 Second: If so, it's not working...
48585 From laser at musichat.net Sat Oct 11 00:56:04 2003
48586 From: laser at musichat.net (Alessandro Ciappei)
48587 Date: Sat Oct 23 23:10:10 2004
48588 Subject: [IRCServices Coding] Problem with auth mail
48589 In-Reply-To: <20031007101106.2701D1703F@snow.fingers.co.za>
48590 Message-ID: <GMEFIDBHIMPENBMIJNFEEEGDCAAA.laser@musichat.net>
48593 Hi all, I've ircservices 5.0.22, and I would like to costumize auth-mail.
48594 I would like describe my irc network in this mail, but when someone register
48595 nick, services go in segfault.
48597 I copy the sintaz of mail-auth ( it's in italian )
48599 # Mail text. The last "%s" (before the user@host) in the body text is
48600 # replaced by one of the NICK_AUTH_MAIL_TEXT_* messages.
48601 NICK_AUTH_MAIL_SUBJECT
48602 Conferma della registrazione del nick %s
48603 NICK_AUTH_MAIL_BODY
48604 Grazie per aver scelto MusiChat Net Community!
48605 Il codice di autorizzazione del tuo nick (%s) e': %09d
48606 Identificati su MusiChat digitando:
48609 La registrazione del tuo nick sara' confermata e il tuo nickname
48610 sara' protetto da eventuali tentativi di abuso o furto.
48612 Il sito ufficiale della rete e' http://www.musichat.net/
48613 I regolamenti della rete e i documenti ufficiali sono
48614 disponibili all'interno del sito.
48616 Per ricevere assistenza sui servizi della rete
48617 in generale puoi rivolgerti sul canale ufficiale #IRCHelp
48618 oppure tramite email all'indirizzo irchelp@musichat.net.
48621 Sono inoltre disponibili i seguenti servizi:
48624 Forum di discussione di MusiChat, raggiungibile
48625 all'indirizzo http://forum.musichat.net
48626 Sul forum, oltre a poter esprimere la tua opinione,
48627 potrai informarti sulle novita' e sui nuovi servizi
48628 offerti dalla rete.
48630 - MusiChat Mailing List
48631 Per iscriversi e' sufficiente visitare il sito
48632 http://lists.musichat.net/mailman/listinfo/irchelp
48633 e inserire il proprio indirizzo E-Mail e la
48634 password desiderata.
48637 Per una connessione piu' veloce e sicura e' vivamente
48638 consigliato l'utilizzo del seguente server: irc.musichat.net
48640 MusiChat Net Community
48642 Questo messaggio e stato inviato su richiesta di %s in risposta a %s
48648 I read the istruction for translate.
48652 [Oct 11 09:48:30 2003] PANIC! buffer = :alpha_omega ! nickserv :register
48653 pippo laser@musichat.net
48654 [Oct 11 09:48:30 2003] Services terminating: Segmentation fault
48657 Some one can help me?
48658 the email body is too long?
48666 From achurch at achurch.org Thu Oct 16 23:58:34 2003
48667 From: achurch at achurch.org (Andrew Church)
48668 Date: Sat Oct 23 23:10:10 2004
48669 Subject: [IRCServices Coding] Problem with auth mail
48670 In-Reply-To: <GMEFIDBHIMPENBMIJNFEEEGDCAAA.laser@musichat.net>
48671 Message-ID: <3f8f9304.20227@achurch.org>
48673 You have the wrong number of %-tokens in your message.
48676 achurch@achurch.org
48677 http://achurch.org/
48680 >Hi all, I've ircservices 5.0.22, and I would like to costumize auth-mail.
48681 >I would like describe my irc network in this mail, but when someone register
48682 >nick, services go in segfault.
48684 >I copy the sintaz of mail-auth ( it's in italian )
48686 ># Mail text. The last "%s" (before the user@host) in the body text is
48687 ># replaced by one of the NICK_AUTH_MAIL_TEXT_* messages.
48688 >NICK_AUTH_MAIL_SUBJECT
48689 > Conferma della registrazione del nick %s
48690 >NICK_AUTH_MAIL_BODY
48691 > Grazie per aver scelto MusiChat Net Community!
48692 > Il codice di autorizzazione del tuo nick (%s) e': %09d
48693 > Identificati su MusiChat digitando:
48694 > /msg %s AUTH %09d
48696 > La registrazione del tuo nick sara' confermata e il tuo nickname
48697 > sara' protetto da eventuali tentativi di abuso o furto.
48699 > Il sito ufficiale della rete e' http://www.musichat.net/
48700 > I regolamenti della rete e i documenti ufficiali sono
48701 > disponibili all'interno del sito.
48703 > Per ricevere assistenza sui servizi della rete
48704 > in generale puoi rivolgerti sul canale ufficiale #IRCHelp
48705 > oppure tramite email all'indirizzo irchelp@musichat.net.
48708 > Sono inoltre disponibili i seguenti servizi:
48711 > Forum di discussione di MusiChat, raggiungibile
48712 > all'indirizzo http://forum.musichat.net
48713 > Sul forum, oltre a poter esprimere la tua opinione,
48714 > potrai informarti sulle novita' e sui nuovi servizi
48715 > offerti dalla rete.
48717 > - MusiChat Mailing List
48718 > Per iscriversi e' sufficiente visitare il sito
48719 > http://lists.musichat.net/mailman/listinfo/irchelp
48720 > e inserire il proprio indirizzo E-Mail e la
48721 > password desiderata.
48724 > Per una connessione piu' veloce e sicura e' vivamente
48725 > consigliato l'utilizzo del seguente server: irc.musichat.net
48727 > MusiChat Net Community
48729 > Questo messaggio e stato inviato su richiesta di %s in risposta a %s
48735 >I read the istruction for translate.
48739 >[Oct 11 09:48:30 2003] PANIC! buffer = :alpha_omega ! nickserv :register
48740 >pippo laser@musichat.net
48741 >[Oct 11 09:48:30 2003] Services terminating: Segmentation fault
48744 >Some one can help me?
48745 >the email body is too long?
48752 >------------------------------------------------------------------
48753 >To unsubscribe or change your subscription options, visit:
48754 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
48756 From saman at alkol.org Fri Oct 17 03:07:31 2003
48757 From: saman at alkol.org (|SaMaN|)
48758 Date: Sat Oct 23 23:10:10 2004
48759 Subject: [IRCServices Coding] Bug or misunderstood ?
48760 Message-ID: <000901c39496$71764f10$a37faec3@coder>
48762 Im using unreal ircd. When channel is empty and if channel owner joins
48763 his/her registered channel it does
48764 (ChanServ sets mode: +ntrq nick) but when channel is not empty and if
48765 channel owner joins his/her registered channel it does (ChanServ sets mode:
48766 +oq nick nick). As you see on the first one there is no +o and because of
48767 this chanserv does not update the last_used time because chanserv is set to
48768 update last_used time with +o (CUMODE_o) so channels drop while channel
48769 owners use them. Is this a bug or my misunderstood ?
48771 ######################################################
48772 modules/chanserv/check.c
48774 void check_chan_user_modes(const char *source, struct c_userlist *u,
48775 Channel *c, int32 oldmodes)
48777 if ((res & ~modes) & CUMODE_o) {
48778 ci->last_used = time(NULL);
48779 put_channelinfo(ci);
48782 ######################################################
48788 From saman at alkol.org Fri Oct 17 04:53:04 2003
48789 From: saman at alkol.org (|SaMaN|)
48790 Date: Sat Oct 23 23:10:10 2004
48791 Subject: [IRCServices Coding] Re: Bug or misunderstood ?
48792 Message-ID: <002001c394a5$31c059b0$a37faec3@coder>
48794 Also it does not update last_used time on +a flag.
48799 edit /modules/chanserv/check.c
48802 -------------------------------------------------------------------------
48803 local_set_cumodes(c, '+', res & ~modes, user->nick);
48804 -------------------------------------------------------------------------
48806 ------------------------------------------------------------------------
48807 int16 cumode_q = mode_char_to_flag('q',MODE_CHANUSER);
48808 int16 cumode_a = mode_char_to_flag('a',MODE_CHANUSER);
48810 if ((res & ~modes) & cumode_q) {
48811 ci->last_used = time(NULL);
48812 put_channelinfo(ci);
48815 if ((res & ~modes) & cumode_a) {
48816 ci->last_used = time(NULL);
48817 put_channelinfo(ci);
48819 -------------------------------------------------------------------------
48820 save and compile and run and enjoy :)
48821 -------------------------------------------------------------------------
48825 ----- Original Message -----
48826 From: "|SaMaN|" <saman@alkol.org>
48827 To: <IRCServices-Coding@ircservices.za.net>
48828 Sent: Friday, October 17, 2003 1:07 PM
48829 Subject: Bug or misunderstood ?
48832 > Im using unreal ircd. When channel is empty and if channel owner joins
48833 > his/her registered channel it does
48834 > (ChanServ sets mode: +ntrq nick) but when channel is not empty and if
48835 > channel owner joins his/her registered channel it does (ChanServ sets
48837 > +oq nick nick). As you see on the first one there is no +o and because of
48838 > this chanserv does not update the last_used time because chanserv is set
48840 > update last_used time with +o (CUMODE_o) so channels drop while channel
48841 > owners use them. Is this a bug or my misunderstood ?
48843 > ######################################################
48844 > modules/chanserv/check.c
48846 > void check_chan_user_modes(const char *source, struct c_userlist *u,
48847 > Channel *c, int32 oldmodes)
48849 > if ((res & ~modes) & CUMODE_o) {
48850 > ci->last_used = time(NULL);
48851 > put_channelinfo(ci);
48854 > ######################################################
48861 From saturn at jetirc.net Fri Oct 17 08:47:59 2003
48862 From: saturn at jetirc.net (Saturn)
48863 Date: Sat Oct 23 23:10:10 2004
48864 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
48865 Message-ID: <002501c394c5$f8dce480$6401a8c0@turby>
48867 Haven't seen a reply to this one, so thought I'd better make sure this went
48870 ----- Original Message -----
48871 Sent: Friday, October 10, 2003 3:48 PM
48872 Subject: Akill problem in 5.0.22
48875 Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
48876 duplicate exit system notice that happens in 3.1.6).
48878 I just today added an akill (+0 time) .. I DO have the immediate auto kill
48879 option un-commented in the modules.conf, but it still didn't bother scanning
48880 for victims matching my akill mask nor did it actually KILL anyone... It
48881 works if they are manually killed and then try to re-connect, but I thought
48882 that new option was so Services will immediately scan for and kill anyone
48883 online that matches the mask as soon as the new akill is added...
48885 First: IS that what it's supposed to do?
48887 Second: If so, it's not working...
48893 From achurch at achurch.org Fri Oct 17 09:03:19 2003
48894 From: achurch at achurch.org (Andrew Church)
48895 Date: Sat Oct 23 23:10:10 2004
48896 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
48897 In-Reply-To: <002501c394c5$f8dce480$6401a8c0@turby>
48898 Message-ID: <3f9012b8.23176@achurch.org>
48903 achurch@achurch.org
48904 http://achurch.org/
48906 >Haven't seen a reply to this one, so thought I'd better make sure this went
48909 >----- Original Message -----
48910 >Sent: Friday, October 10, 2003 3:48 PM
48911 >Subject: Akill problem in 5.0.22
48914 >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
48915 >duplicate exit system notice that happens in 3.1.6).
48917 >I just today added an akill (+0 time) .. I DO have the immediate auto kill
48918 >option un-commented in the modules.conf, but it still didn't bother scanning
48919 >for victims matching my akill mask nor did it actually KILL anyone... It
48920 >works if they are manually killed and then try to re-connect, but I thought
48921 >that new option was so Services will immediately scan for and kill anyone
48922 >online that matches the mask as soon as the new akill is added...
48924 >First: IS that what it's supposed to do?
48926 >Second: If so, it's not working...
48931 >------------------------------------------------------------------
48932 >To unsubscribe or change your subscription options, visit:
48933 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
48935 From saturn at jetirc.net Fri Oct 17 09:19:32 2003
48936 From: saturn at jetirc.net (Saturn)
48937 Date: Sat Oct 23 23:10:10 2004
48938 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
48939 References: <3f9012b8.23176@achurch.org>
48940 Message-ID: <027401c394ca$443ae180$6401a8c0@turby>
48942 Well, Andrew, I did read TFM. For what it's worth, all I found was this
48943 entry under the description of the module options
48945 ImmediatelySendAutokill [OPTIONAL]
48946 Causes OperServ to inform all servers of a new autokill or autokill
48947 exclusion the moment it is added, rather than waiting for someone to match
48949 Example: ImmediatelySendAutokill
48951 I read through the section about AKILLs and SQline, SGline, SZline, etc,
48952 however all of what I read indicates that simply enabling the
48953 ImmediatelySendAutokill option in the modules.conf (coupled with the fact
48954 that everything ELSE is set up and workign properly) SHOULD cause services
48955 to immediately scan the network for clients matching the akill mask, and
48958 My point, sir, is that IT DOES NOT DO THIS. Thus, I'm sure you'll find, I
48959 HAVE in fact read the f___ manual, and the manual does not address this
48960 problem. If it doesn't matter to you, fine, but if it does, let's try and
48961 get on with maybe solving the problem?
48966 ----- Original Message -----
48967 From: "Andrew Church" <achurch@achurch.org>
48968 To: <ircservices-coding@ircservices.za.net>
48969 Sent: Friday, October 17, 2003 9:02 AM
48970 Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
48976 achurch@achurch.org
48977 http://achurch.org/
48979 >Haven't seen a reply to this one, so thought I'd better make sure this went
48982 >----- Original Message -----
48983 >Sent: Friday, October 10, 2003 3:48 PM
48984 >Subject: Akill problem in 5.0.22
48987 >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
48988 >duplicate exit system notice that happens in 3.1.6).
48990 >I just today added an akill (+0 time) .. I DO have the immediate auto kill
48991 >option un-commented in the modules.conf, but it still didn't bother
48993 >for victims matching my akill mask nor did it actually KILL anyone... It
48994 >works if they are manually killed and then try to re-connect, but I thought
48995 >that new option was so Services will immediately scan for and kill anyone
48996 >online that matches the mask as soon as the new akill is added...
48998 >First: IS that what it's supposed to do?
49000 >Second: If so, it's not working...
49005 >------------------------------------------------------------------
49006 >To unsubscribe or change your subscription options, visit:
49007 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
49008 ------------------------------------------------------------------
49009 To unsubscribe or change your subscription options, visit:
49010 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
49013 From achurch at achurch.org Fri Oct 17 09:34:48 2003
49014 From: achurch at achurch.org (Andrew Church)
49015 Date: Sat Oct 23 23:10:10 2004
49016 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
49017 In-Reply-To: <027401c394ca$443ae180$6401a8c0@turby>
49018 Message-ID: <3f901a20.23266@achurch.org>
49020 >however all of what I read indicates that simply enabling the
49021 >ImmediatelySendAutokill option in the modules.conf (coupled with the fact
49022 >that everything ELSE is set up and workign properly) SHOULD cause services
49023 >to immediately scan the network for clients matching the akill mask, and
49026 The documentation says nothing about this. RTFM again.
49029 achurch@achurch.org
49030 http://achurch.org/
49032 From ballsy at mystical.net Fri Oct 17 11:20:33 2003
49033 From: ballsy at mystical.net (Ballsy)
49034 Date: Sat Oct 23 23:10:10 2004
49035 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
49036 In-Reply-To: <027401c394ca$443ae180$6401a8c0@turby>
49037 References: <3f9012b8.23176@achurch.org> <027401c394ca$443ae180$6401a8c0@turby>
49038 Message-ID: <6.0.0.22.0.20031017121557.01b63ac0@127.0.0.1>
49040 To save the rest of us from having to put up with more bickering,
49041 it may be of note that I had to comment out 'EnableExclude' in order for my
49042 immediate-kill functionality to work under bahamut (I know, you're using
49043 Unreal). All the ImmediatelySendAkill does is informs all linked services
49044 that they should add an Akill. It's then up to those servers to decide how
49050 At 10:18 AM 17/10/2003, Saturn wrote:
49051 >Well, Andrew, I did read TFM. For what it's worth, all I found was this
49052 >entry under the description of the module options
49054 >ImmediatelySendAutokill [OPTIONAL]
49055 > Causes OperServ to inform all servers of a new autokill or autokill
49056 >exclusion the moment it is added, rather than waiting for someone to match
49058 > Example: ImmediatelySendAutokill
49060 >I read through the section about AKILLs and SQline, SGline, SZline, etc,
49061 >however all of what I read indicates that simply enabling the
49062 >ImmediatelySendAutokill option in the modules.conf (coupled with the fact
49063 >that everything ELSE is set up and workign properly) SHOULD cause services
49064 >to immediately scan the network for clients matching the akill mask, and
49067 >My point, sir, is that IT DOES NOT DO THIS. Thus, I'm sure you'll find, I
49068 >HAVE in fact read the f___ manual, and the manual does not address this
49069 >problem. If it doesn't matter to you, fine, but if it does, let's try and
49070 >get on with maybe solving the problem?
49075 >----- Original Message -----
49076 >From: "Andrew Church" <achurch@achurch.org>
49077 >To: <ircservices-coding@ircservices.za.net>
49078 >Sent: Friday, October 17, 2003 9:02 AM
49079 >Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
49085 > achurch@achurch.org
49086 > http://achurch.org/
49088 > >Haven't seen a reply to this one, so thought I'd better make sure this went
49091 > >----- Original Message -----
49092 > >Sent: Friday, October 10, 2003 3:48 PM
49093 > >Subject: Akill problem in 5.0.22
49096 > >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
49097 > >duplicate exit system notice that happens in 3.1.6).
49099 > >I just today added an akill (+0 time) .. I DO have the immediate auto kill
49100 > >option un-commented in the modules.conf, but it still didn't bother
49102 > >for victims matching my akill mask nor did it actually KILL anyone... It
49103 > >works if they are manually killed and then try to re-connect, but I thought
49104 > >that new option was so Services will immediately scan for and kill anyone
49105 > >online that matches the mask as soon as the new akill is added...
49107 > >First: IS that what it's supposed to do?
49109 > >Second: If so, it's not working...
49114 > >------------------------------------------------------------------
49115 > >To unsubscribe or change your subscription options, visit:
49116 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
49117 >------------------------------------------------------------------
49118 >To unsubscribe or change your subscription options, visit:
49119 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
49121 >------------------------------------------------------------------
49122 >To unsubscribe or change your subscription options, visit:
49123 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
49127 From saturn at jetirc.net Fri Oct 17 17:16:26 2003
49128 From: saturn at jetirc.net (Saturn)
49129 Date: Sat Oct 23 23:10:10 2004
49130 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
49131 References: <3f901a20.23266@achurch.org>
49132 Message-ID: <02d401c3950c$e762bda0$6401a8c0@turby>
49134 >From a.html in the /docs directory:
49136 operserv/akill (Autokill module settings)
49137 ImmediatelySendAutokill [OPTIONAL]
49138 Causes OperServ to inform all servers of a new autokill or autokill
49139 exclusion the moment it is added, rather than waiting for someone to match
49141 Example: ImmediatelySendAutokill
49144 3.html#4-3 in the /docs directory does not speak to the
49145 ImmediatelySendAutokill option except for the mention that:
49146 "(If the ImmediatelySendAutokill option in modules.conf is enabled, the
49147 last-used time will never be set at all on these servers.)"
49148 However, this is in the context of talking about Slines, etc, and as far as
49149 I can tell has no new useful information to impart regarding my stated
49150 problem: that services is NOT "Immediately sending the autokill" on my
49151 network and thus when a new AKILL is added, the matching users/masks are not
49152 being killed off, unless they are killed manually by an IRCop. Yes, it IS
49153 catching them when they attempt to re-connect, that was never a problem. It
49154 would make sense that if an autokill is added, that Services would
49155 immediately trace the network and kill off any matches to that akill... at
49156 least, it makes sense if this option is enabled.... (to me)
49157 ------------------------
49159 4.html#oper.akill doesn't mention it at all.
49163 I really don't see where else I'm supposed to be looking here. I've scoured
49164 the docs and can see no other reference to it. If there's something I'm
49165 missing, perhaps instead of rudely, repeatedly telling me to RTFM, maybe
49166 just tell me what it is I'm supposed to find! I've already spend a few
49167 hours reading through the docs (which I've already read about a dozen times
49168 over the past year alone), and I'm telling you, there's nothing else about
49169 it that I can find!!!
49171 The ONLY thing I can come up with is that the feature name is misleading and
49172 the option doesn't in fact do what it SEEMS it should do. Could it be that
49173 all that does is send the S/G/Z line (whatever is appropriate) to the
49174 servers and that's all??? NOW I have to ask, why bother, if it'll do that
49175 if/when they re-connect anyhow?
49177 Additionally, if the reason I can't find the answer in the manual is because
49178 the option DOESN'T make services kill all matches when the akill is added,
49179 then Imust ask WHY that isn't an option, since it seems logically useful to
49180 me and my staff. Also, that being the case, why couldn't you simply SAY
49181 that it's not designed to do that, instead of sending me hunting (TWICE) for
49182 non-existant information in the docs???????
49184 I'm very interested to hear the answer to these questions. To put it
49185 bluntly, I have been an extremely enthusiastic advocate of IRCServices for
49186 over 3 years now, have turned many network owners onto them, and love them
49187 to death. The way you "talk" to your supporters on this forum sometimes
49188 leaves a LOT to be desired. If the feature doesn't exist as I understand
49189 it, just SAY SO and save us all a lot of trouble -- don't just tell me to go
49190 RTFM when the info I seek isn't IN it. Having said that, if you can point
49191 me to the info in the docs in the 5.0.22 distro and prove my claims as
49192 baseless, I will offer my sincere apologies. Until then, my opinion stands.
49196 ----- Original Message -----
49197 From: "Andrew Church" <achurch@achurch.org>
49198 To: <ircservices-coding@ircservices.za.net>
49199 Sent: Friday, October 17, 2003 9:34 AM
49200 Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
49203 >however all of what I read indicates that simply enabling the
49204 >ImmediatelySendAutokill option in the modules.conf (coupled with the fact
49205 >that everything ELSE is set up and workign properly) SHOULD cause services
49206 >to immediately scan the network for clients matching the akill mask, and
49209 The documentation says nothing about this. RTFM again.
49212 achurch@achurch.org
49213 http://achurch.org/
49214 ------------------------------------------------------------------
49215 To unsubscribe or change your subscription options, visit:
49216 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
49219 From saturn at jetirc.net Fri Oct 17 17:33:57 2003
49220 From: saturn at jetirc.net (Saturn)
49221 Date: Sat Oct 23 23:10:10 2004
49222 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
49223 References: <3f9012b8.23176@achurch.org> <027401c394ca$443ae180$6401a8c0@turby>
49224 <6.0.0.22.0.20031017121557.01b63ac0@127.0.0.1>
49225 Message-ID: <030801c3950f$3cb55270$6401a8c0@turby>
49227 Would have been nice if someone had mentioned that (about the
49228 ImmediatelySendAutokill) from the start. I would say the flag is misleading
49229 in title then, because I (and 8 other people on my staff -- none of us are
49230 dummies, either) read that as meaning it will Immediately send the auto
49231 kill... "ImmediatelyUpdateServers" might be more fitting from an intuitive
49232 standpoint, not that I'm suggesting changing the name, but at least the
49233 documentation of it could be a bit more explicit IMHO.
49235 and yes, I know there will be about 50 people (probably all of them
49236 hard-core coders) shaking their heads in disbelief at what I've said, but
49237 let's face it: If we were ALL hard-core coders, we wouldn't need Andrew and
49238 his IRCServices, would we? We'd all be making our own. So all I'm saying
49239 is how about a little slack for those of us with OTHER important skills that
49240 might fall outside the scope of being the "world's greatest expert" on IRC
49243 ----- Original Message -----
49244 From: "Ballsy" <ballsy@mystical.net>
49245 To: "IRC Services Coding Mailing List"
49246 <ircservices-coding@ircservices.za.net>; "IRC Services Coding Mailing List"
49247 <ircservices-coding@ircservices.za.net>
49248 Sent: Friday, October 17, 2003 11:20 AM
49249 Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
49252 To save the rest of us from having to put up with more bickering,
49253 it may be of note that I had to comment out 'EnableExclude' in order for my
49254 immediate-kill functionality to work under bahamut (I know, you're using
49255 Unreal). All the ImmediatelySendAkill does is informs all linked services
49256 that they should add an Akill. It's then up to those servers to decide how
49262 At 10:18 AM 17/10/2003, Saturn wrote:
49263 >Well, Andrew, I did read TFM. For what it's worth, all I found was this
49264 >entry under the description of the module options
49266 >ImmediatelySendAutokill [OPTIONAL]
49267 > Causes OperServ to inform all servers of a new autokill or autokill
49268 >exclusion the moment it is added, rather than waiting for someone to match
49270 > Example: ImmediatelySendAutokill
49272 >I read through the section about AKILLs and SQline, SGline, SZline, etc,
49273 >however all of what I read indicates that simply enabling the
49274 >ImmediatelySendAutokill option in the modules.conf (coupled with the fact
49275 >that everything ELSE is set up and workign properly) SHOULD cause services
49276 >to immediately scan the network for clients matching the akill mask, and
49279 >My point, sir, is that IT DOES NOT DO THIS. Thus, I'm sure you'll find, I
49280 >HAVE in fact read the f___ manual, and the manual does not address this
49281 >problem. If it doesn't matter to you, fine, but if it does, let's try and
49282 >get on with maybe solving the problem?
49287 >----- Original Message -----
49288 >From: "Andrew Church" <achurch@achurch.org>
49289 >To: <ircservices-coding@ircservices.za.net>
49290 >Sent: Friday, October 17, 2003 9:02 AM
49291 >Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
49297 > achurch@achurch.org
49298 > http://achurch.org/
49300 > >Haven't seen a reply to this one, so thought I'd better make sure this
49304 > >----- Original Message -----
49305 > >Sent: Friday, October 10, 2003 3:48 PM
49306 > >Subject: Akill problem in 5.0.22
49309 > >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
49310 > >duplicate exit system notice that happens in 3.1.6).
49312 > >I just today added an akill (+0 time) .. I DO have the immediate auto
49314 > >option un-commented in the modules.conf, but it still didn't bother
49316 > >for victims matching my akill mask nor did it actually KILL anyone... It
49317 > >works if they are manually killed and then try to re-connect, but I
49319 > >that new option was so Services will immediately scan for and kill anyone
49320 > >online that matches the mask as soon as the new akill is added...
49322 > >First: IS that what it's supposed to do?
49324 > >Second: If so, it's not working...
49329 > >------------------------------------------------------------------
49330 > >To unsubscribe or change your subscription options, visit:
49331 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
49332 >------------------------------------------------------------------
49333 >To unsubscribe or change your subscription options, visit:
49334 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
49336 >------------------------------------------------------------------
49337 >To unsubscribe or change your subscription options, visit:
49338 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
49341 ------------------------------------------------------------------
49342 To unsubscribe or change your subscription options, visit:
49343 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
49346 From Craig at chatspike.net Fri Oct 17 19:07:33 2003
49347 From: Craig at chatspike.net (Craig McLure)
49348 Date: Sat Oct 23 23:10:10 2004
49349 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
49350 Message-ID: <E1AAgV1-0008ae-00@ptb-mailc04.plus.net>
49352 Theres no need for flaming ffs.. just because something makes less sence to you than to everyone else, doesnt instantly mean that it has to be changed.. i seemed to understand it ok, and i'm sure that there are several hundred other IRCServices users who didnt have any problems with this directive.
49354 I'm sure andy will concider documenting it more "accuratly" (I wont speak for him thou, his choice :p), but theres no need for the flaming, if you have such a big problem with something that (apparently just) you dont understand, just make a passing mention on it, dont go on talking about "Hard-core coders" and "worlds biggest expert"s cause you are upset with something. If the last paragraph wasnt made, i'm sure there _WOUDLNT_ be "about 50 people (probably all of them hard-core coders) shaking their heads in disbelief", cause it doesnt happen. And to clarify.. theres no such thing as a "world biggest expert" when it comes to IRC programming, people have different preferances, and ways of doing things, to the point that you cant compair something like InspIRCd to UnrealIRCd, as they are totally different in almost every way. :p
49356 Please just calm down, and talk this out rationally before you start jumping down ppls throats :p
49358 /*****************************************
49359 * Craig "FrostyCoolSlug" McLure
49360 * InspIRCd - http://www.inspircd.org
49361 * ChatSpike - http://www.chatspike.net
49362 ****************************************/
49365 /****************************************
49366 * From - Saturn <saturn@jetirc.net>
49367 * To - IRC Services Coding Mailing List <ircservices-coding@ircservices.za.net>
49368 * Sent - 2003-10-17 17:31:00
49369 * Subject - Re: [IRCServices Coding] Re: Akill problem in 5.0.22
49370 ****************************************/
49372 /****** - Begin Original Message - ******/
49374 >Would have been nice if someone had mentioned that (about the
49375 >ImmediatelySendAutokill) from the start. I would say the flag is misleading
49376 >in title then, because I (and 8 other people on my staff -- none of us are
49377 >dummies, either) read that as meaning it will Immediately send the auto
49378 >kill... "ImmediatelyUpdateServers" might be more fitting from an intuitive
49379 >standpoint, not that I'm suggesting changing the name, but at least the
49380 >documentation of it could be a bit more explicit IMHO.
49382 >and yes, I know there will be about 50 people (probably all of them
49383 >hard-core coders) shaking their heads in disbelief at what I've said, but
49384 >let's face it: If we were ALL hard-core coders, we wouldn't need Andrew and
49385 >his IRCServices, would we? We'd all be making our own. So all I'm saying
49386 >is how about a little slack for those of us with OTHER important skills that
49387 >might fall outside the scope of being the "world's greatest expert" on IRC
49390 >----- Original Message -----
49391 >From: "Ballsy" <ballsy@mystical.net>
49392 >To: "IRC Services Coding Mailing List"
49393 ><ircservices-coding@ircservices.za.net>; "IRC Services Coding Mailing List"
49394 ><ircservices-coding@ircservices.za.net>
49395 >Sent: Friday, October 17, 2003 11:20 AM
49396 >Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
49399 > To save the rest of us from having to put up with more bickering,
49400 >it may be of note that I had to comment out 'EnableExclude' in order for my
49401 >immediate-kill functionality to work under bahamut (I know, you're using
49402 >Unreal). All the ImmediatelySendAkill does is informs all linked services
49403 >that they should add an Akill. It's then up to those servers to decide how
49409 >At 10:18 AM 17/10/2003, Saturn wrote:
49410 >>Well, Andrew, I did read TFM. For what it's worth, all I found was this
49411 >>entry under the description of the module options
49413 >>ImmediatelySendAutokill [OPTIONAL]
49414 >> Causes OperServ to inform all servers of a new autokill or autokill
49415 >>exclusion the moment it is added, rather than waiting for someone to match
49417 >> Example: ImmediatelySendAutokill
49419 >>I read through the section about AKILLs and SQline, SGline, SZline, etc,
49420 >>however all of what I read indicates that simply enabling the
49421 >>ImmediatelySendAutokill option in the modules.conf (coupled with the fact
49422 >>that everything ELSE is set up and workign properly) SHOULD cause services
49423 >>to immediately scan the network for clients matching the akill mask, and
49426 >>My point, sir, is that IT DOES NOT DO THIS. Thus, I'm sure you'll find, I
49427 >>HAVE in fact read the f___ manual, and the manual does not address this
49428 >>problem. If it doesn't matter to you, fine, but if it does, let's try and
49429 >>get on with maybe solving the problem?
49434 >>----- Original Message -----
49435 >>From: "Andrew Church" <achurch@achurch.org>
49436 >>To: <ircservices-coding@ircservices.za.net>
49437 >>Sent: Friday, October 17, 2003 9:02 AM
49438 >>Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
49444 >> achurch@achurch.org
49445 >> http://achurch.org/
49447 >> >Haven't seen a reply to this one, so thought I'd better make sure this
49451 >> >----- Original Message -----
49452 >> >Sent: Friday, October 10, 2003 3:48 PM
49453 >> >Subject: Akill problem in 5.0.22
49456 >> >Running 5.0.22 on Unreal 3.1.7b1 (same as 3.1.6 except they fixed that
49457 >> >duplicate exit system notice that happens in 3.1.6).
49459 >> >I just today added an akill (+0 time) .. I DO have the immediate auto
49461 >> >option un-commented in the modules.conf, but it still didn't bother
49463 >> >for victims matching my akill mask nor did it actually KILL anyone... It
49464 >> >works if they are manually killed and then try to re-connect, but I
49466 >> >that new option was so Services will immediately scan for and kill anyone
49467 >> >online that matches the mask as soon as the new akill is added...
49469 >> >First: IS that what it's supposed to do?
49471 >> >Second: If so, it's not working...
49476 >> >------------------------------------------------------------------
49477 >> >To unsubscribe or change your subscription options, visit:
49478 >> >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
49479 >>------------------------------------------------------------------
49480 >>To unsubscribe or change your subscription options, visit:
49481 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
49483 >>------------------------------------------------------------------
49484 >>To unsubscribe or change your subscription options, visit:
49485 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
49488 >------------------------------------------------------------------
49489 >To unsubscribe or change your subscription options, visit:
49490 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
49492 >------------------------------------------------------------------
49493 >To unsubscribe or change your subscription options, visit:
49494 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
49498 /******* - End Original Message - *******/
49503 From achurch at achurch.org Fri Oct 17 20:13:46 2003
49504 From: achurch at achurch.org (Andrew Church)
49505 Date: Sat Oct 23 23:10:10 2004
49506 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
49507 In-Reply-To: <02d401c3950c$e762bda0$6401a8c0@turby>
49508 Message-ID: <3f90afdf.23477@achurch.org>
49510 You know, I might have been more forgiving if this hadn't been gone
49511 over on this list (twice!) before:
49513 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/002305.html
49514 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/003215.html
49516 However, since you seem to have trouble both comprehending the
49517 documentation and reading the archives, I have added FAQ F.10 for your
49520 F.10. Services doesn't kill users matching a newly-added autokill mask even
49521 if ImmediatelySendAutokill is set.
49523 Services never kills users when a new autokill is added; the
49524 ImmediatelySendAutokill configuration directive only causes
49525 Services to send the autokill itself (that is, the user/host mask
49526 to prohibit new connections from) to the IRC servers on your
49527 network. This is a safety feature intended to limit the damage
49528 caused by a mistyped autokill.
49530 Note that some IRC servers will themselves kill users matching a
49531 newly-added autokill; this is unrelated to Services.
49534 achurch@achurch.org
49535 http://achurch.org/
49537 From griever at t2n.org Fri Oct 17 21:23:14 2003
49538 From: griever at t2n.org (Robert F Merrill)
49539 Date: Sat Oct 23 23:10:10 2004
49540 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
49541 In-Reply-To: <030801c3950f$3cb55270$6401a8c0@turby>
49542 References: <3f9012b8.23176@achurch.org> <027401c394ca$443ae180$6401a8c0@turby>
49543 <6.0.0.22.0.20031017121557.01b63ac0@127.0.0.1>
49544 <030801c3950f$3cb55270$6401a8c0@turby>
49545 Message-ID: <3F90BF77.2010706@t2n.org>
49549 >Would have been nice if someone had mentioned that (about the
49550 >ImmediatelySendAutokill) from the start. I would say the flag is misleading
49551 >in title then, because I (and 8 other people on my staff -- none of us are
49552 >dummies, either) read that as meaning it will Immediately send the auto
49553 >kill... "ImmediatelyUpdateServers" might be more fitting from an intuitive
49554 >standpoint, not that I'm suggesting changing the name, but at least the
49555 >documentation of it could be a bit more explicit IMHO.
49558 It DOES immediately send the autokill. You just don't grasp the meaning
49559 of sending the autokill.
49560 It literally sends an AKILL (or TKL in the case of unreal) message to
49561 the servers. At least unreal
49562 and bahamut will then scan for matching clients and disconnect them,
49563 however not all servers
49566 If you are using unreal and it doesn't disconnect the matching users,
49567 then it is either a bug in
49568 unreal (not uncommon) or the services really *aren't* sending the tkl
49569 message (doubt it).
49571 Try adding an akill for a connected client. If the client doesn't die,
49572 do a /stats g on their server.
49573 You should see a g-line added for them.
49575 Also note that if you have akill exclusions enabled (bad idea most of
49576 the time), services will NEVER add an akill
49577 or gline on servers that don't support akill or gline exclusions (I
49578 don't know of any that do), but rather
49579 manually kill everyone that matches as they connect. In this case, you
49580 should disable akill exclusions and
49581 it should start working.
49585 From v13 at it.teithe.gr Sat Oct 18 11:47:23 2003
49586 From: v13 at it.teithe.gr (V13)
49587 Date: Sat Oct 23 23:10:10 2004
49588 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
49589 In-Reply-To: <3F90BF77.2010706@t2n.org>
49590 References: <3f9012b8.23176@achurch.org> <030801c3950f$3cb55270$6401a8c0@turby>
49591 <3F90BF77.2010706@t2n.org>
49592 Message-ID: <200310182149.18600.v13@it.teithe.gr>
49594 On Saturday 18 October 2003 07:20, Robert F Merrill wrote:
49596 > >Would have been nice if someone had mentioned that (about the
49597 > >ImmediatelySendAutokill) from the start. I would say the flag is
49598 > > misleading in title then, because I (and 8 other people on my staff --
49599 > > none of us are dummies, either) read that as meaning it will Immediately
49600 > > send the auto kill... "ImmediatelyUpdateServers" might be more fitting
49601 > > from an intuitive standpoint, not that I'm suggesting changing the name,
49602 > > but at least the documentation of it could be a bit more explicit IMHO.
49604 > It DOES immediately send the autokill. You just don't grasp the meaning
49605 > of sending the autokill.
49606 > It literally sends an AKILL (or TKL in the case of unreal) message to
49607 > the servers. At least unreal
49608 > and bahamut will then scan for matching clients and disconnect them,
49609 > however not all servers
49612 FYI bahamut doesn't do this. It will only do it whenever a new client that
49613 matches the akill connects to the server.
49615 i.e. if you set an akill for *.com noone will be disconnected untill a new
49616 client from *.com gets connected (at that moment, all matching clients will
49617 be killed). In the mean time, anyone from other domains can connect to the
49618 server without having any user killed.
49622 From diego at redesul.net Sat Oct 18 12:17:04 2003
49623 From: diego at redesul.net (Diego B. Contezini)
49624 Date: Sat Oct 23 23:10:10 2004
49625 Subject: [IRCServices Coding] CORE DUMPED! BUG!
49626 References: <3f8f9304.20227@achurch.org>
49627 Message-ID: <000e01c395ac$5b773b40$3cc8a8c0@angel>
49629 Andrew, you told me about debugging.. now i got it ;]
49630 here is the debugging:
49631 [Oct 18 16:05:31.288944 2003] debug: Sent: :ChanServ TOPIC #EMOCORE reffer
49632 1066055037 :1i?? Festival HARDcoCOREcore dia 25 de outubro em blumenau no
49633 rio bravo bar (proximo a resima agua verde), com as bandas: Zero Ltda
49634 (curitiba), Swallow the Waffle (bc), chymia(bnu), crazy frogs (lages),
49635 surpise set e slipper (bnu)...3 pila entrada inicio as 15:00 horas'
49636 [Oct 18 16:05:31.289032 2003] debug: Received: :|-Frango-| MODE
49637 #EMOCORE -oooooo CHoPP CbRS-oFF caroll BRYAN brunaH balsanelli
49638 Segmentation fault (core dumped)
49640 root@irc(/home/ircadmin/services/lib)# ls -la core.12631
49641 -rw------- 1 ircadmin ircadmin 47374336 Oct 18 16:05 core.12631
49644 continue on the next message......
49647 From diego at redesul.net Sat Oct 18 12:17:32 2003
49648 From: diego at redesul.net (Diego B. Contezini)
49649 Date: Sat Oct 23 23:10:10 2004
49650 Subject: [IRCServices Coding] CORE DUMPED... continue...
49651 References: <3f8f9304.20227@achurch.org>
49652 Message-ID: <001201c395ac$71b42210$3cc8a8c0@angel>
49654 #0 0x0804d830 in add_mode_with_params (md=0x806aa00, mode=111 'o',
49655 is_add=1, params=1, parambuf=0xbfffe280 "balsanelli",
49656 len=10) at actions.c:568
49657 568 md->params[md->nopmodes][len] = 0;
49659 #0 0x0804d830 in add_mode_with_params (md=0x806aa00, mode=111 'o',
49660 is_add=1, params=1, parambuf=0xbfffe280 "balsanelli",
49661 len=10) at actions.c:568
49663 #1 0x0804d342 in set_cmode (sender=0x81db058 "ChanServ", channel=0xa905d00)
49666 "balsanelli\000\b\025\225\002BWi??\022B\024\032\023Bi??i??i??i??\000\000\000
49667 \000\034 \006\bi??i??i??i??hi??i??i??i??i??i??i??\025\224\004B\034
49668 \006\b\000\000\000\000i??m\tBdi??\022Bi??q\a\b\000\000\000\000eR :\0037[
49669 \0034#\003di??\022B\000\000\000\000i??\037\006\bi??\037\006\bi??i??i??i??$i?
49670 ?\006Bi??i??i??i??\bi??i??i??\000\000\000\000Hi??i??i??\025\224\004B@\002\a\
49671 b8i??i??i??6\020\aBpi??i??i??@i??\006\b@\002\a\b\000\000\000\000i??<\023BLi?
49672 ?i??i??=S\004B\024\032\023B\001\020\000\000@i??\006\bhi??i??i??\204i??\006Bp
49673 i??i??i??i??\037\006\b"...
49678 args = 0xbfffe6d0 "RDcoCOREcorei??i??i??i??o"
49679 modes = 0xbfffeae2 ""
49680 modes_orig = 0xbfffeae0 "+o"
49681 md = (struct modedata *) 0x806aa00
49686 #2 0x400895ff in local_set_cumodes (c=0xa905d00, plusminus=43 '+', modes=1,
49687 nick=0xab7f2e8 "balsanelli") at check.c:432
49689 modestr = "o\000\000 de outubro em blumenau no rio bravo bar
49690 (proximo a resima agua verde), com as bandas: Zero
49691 L\v\000\000\000(curitiba), \000\000\000\000low the Waff\000\000\000\000bc),
49692 chymia(bnu), crazy frogs (lages), surpise set e slipper (bnu).."...
49694 #3 0x40088d74 in check_chan_user_modes (source=0xbfffeed0 "|-Frango-|",
49695 u=0xab34ff0, c=0xa905d00, oldmodes=1)
49697 user = (User *) 0xab7f2d8
49698 ci = (ChannelInfo *) 0xa571940
49702 #4 0x400820ed in do_channel_umode_change (source=0xbfffeed0 "|-Frango-|",
49703 c=0xa905d00, u=0xab34ff0, oldmodes=1)
49706 #5 0x0805890d in call_callback_5 (module=0x806a5c0, id=23, arg1=0xbfffeed0,
49707 arg2=0xa905d00, arg3=0xab34ff0, arg4=0x1,
49708 arg5=0x0) at modules.c:666
49709 cl = (CallbackList *) 0x8077cb8
49712 #6 0x0804edc8 in do_cumode (source=0xbfffeed0 "|-Frango-|", chan=0xa905d00,
49713 flag=1, add=0, nick=0xbfffecc9 "balsanelli")
49714 ---Type <return> to continue, or q <return> to quit---
49716 u = (struct c_userlist *) 0xab34ff0
49717 user = (User *) 0xab7f2d8
49719 #7 0x0804e97e in do_cmode (source=0xbfffeed0 "|-Frango-|", ac=0,
49720 av=0xa853130) at channels.c:302
49723 params = -1073746288
49724 chan = (Channel *) 0xa905d00
49727 modestr = 0xbfffec9e "-oooooo"
49728 #8 0x080557ff in m_mode (source=0xbfffeed0 "|-Frango-|", ac=8,
49729 av=0xa853110) at messages.c:101
49731 #9 0x0805920e in process () at process.c:133
49732 m = (Message *) 0x8067dd8
49734 "|-Frango-|\000\000G\000\000\000Y\e\205\n\t+\205\n\bi??i??i??i??i??\005\b@j\
49735 a\b\000\004\000\000i??\032\205\n\t\000\000\000@j\a\b\216j\a\b(i??i??i??qP\00
49738 "MODE\000\000\000i??8i??i??i??i??\005\b\000\000\000\000i??i??i??i??\000\000\
49739 000\000\000\000\000\000\001H\000\000Pi??i??i??\000Y\a\bVi??\005\b\207j\a\bP\
49740 e\205\n\t\000\000\000i??i??\005\b"
49742 "MODE\000#EMOCORE\000-oooooo\000CHoPP\000CbRS-oFF\000caroll\000BRYAN\000brun
49743 aH\000balsanelli\000 balsanelli\000\000ai\00314ser \0030]\00315=\00314-
49744 S\00315c\0030ri\00315p\00314t \00315\037v\0373.8 \003\000\00315\037v\0373.8
49745 \003\000\000\0003)\000\0006\037\002Pi??Ti??\00313\037\002]\037\002\0036i??i?
49746 ? \000i??Ti??\00313\037\002]\037\002\0036i??i?? \000\000\003\000\000r
49747 \003", '\0' <repeats 11 times>...
49748 s = 0xbfffec95 "#EMOCORE"
49750 av = (char **) 0xa853110
49751 #10 0x0805507d in readline_callback (s=0xa851ae0, param_unused=0x50) at
49754 #11 0x0805b617 in check_sockets () at sockets.c:491
49755 newline = 0xa851b58 "\nrct-sc.br irc.creativenet.com.br 0 3364349034
49756 :aNiNhHa[du]DoNaTeLo\n:Toh_Pensanu PART #ilheus\n:_LoKo_SuL_ SJOIN
49757 1063565447 #elias\n:_MoRgAnA_ PRIVMSG NickServ@services.redesul.net :set
49758 nomemo off\n:irc."...
49761 rfds = {fds_bits = {16, 0 <repeats 31 times>}}
49762 wfds = {fds_bits = {0 <repeats 32 times>}}
49763 tv = {tv_sec = 2, tv_usec = 980000}
49766 s = (Socket *) 0xa851ae0
49767 s2 = (Socket *) 0x0
49768 #12 0x0805538a in main (ac=3, av=0xbffff164, envp=0xbffff174) at main.c:266
49769 ---Type <return> to continue, or q <return> to quit---
49771 now_msec = 1348441861
49772 last_update = 1066500208
49773 last_check = 1348441182
49774 #13 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
49775 No symbol table info available.
49780 From saturn at jetirc.net Sat Oct 18 12:18:40 2003
49781 From: saturn at jetirc.net (Saturn)
49782 Date: Sat Oct 23 23:10:10 2004
49783 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
49784 References: <3f90afdf.23477@achurch.org>
49785 Message-ID: <003701c395ac$9ff9fd20$6401a8c0@turby>
49787 I thank you for finally just coming out and telling me what I needed to know
49788 in the first place. Had you stated that it has been discussed before (even
49789 without the hyperlinks) I would have at least known to go look through the
49790 archives. However, all you said (then repeated) was RTFM. I DID read it,
49791 once before I asked, and twice more, at your instruction, and found nothing
49792 to answer my questions. Had I known it had already been discussed, I would
49793 certainly have tried to locate the answer that way.
49795 Thank you to all the others who've posted to try and explain what I was
49796 missing in my understanding of this directive. I got it now, and realize
49797 where my misinterpretation was. Seems obvious now, but frankly that
49798 directive managed to fool myself and 8 of my staff into thinking of it as I
49799 have previously described. Regardless, my apologies for any harsh words...
49800 I do stand by the fact that Andrew could have responded with a bit less
49801 apathy to the concerns raised; with something a bit less useless than RTFM
49802 (twice! even AFTER I said I had, THAT'S what pissed me off), and I hope that
49803 maybe Andrew will remember this chain of events for the next time someone
49804 has a problem that might be immediately obvious to Andrew, but not the
49805 person with the problem. I think most of us KNOW by now to read the docs
49806 before asking questions; but if the question arises due to misinterpretation
49807 of the docs, how would reading them over and over help?
49809 Thank you all for your time.
49813 ----- Original Message -----
49814 From: "Andrew Church" <achurch@achurch.org>
49815 To: <ircservices-coding@ircservices.za.net>
49816 Sent: Friday, October 17, 2003 7:57 PM
49817 Subject: Re: [IRCServices Coding] Re: Akill problem in 5.0.22
49820 You know, I might have been more forgiving if this hadn't been gone
49821 over on this list (twice!) before:
49823 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/002305.html
49824 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/003215.html
49826 However, since you seem to have trouble both comprehending the
49827 documentation and reading the archives, I have added FAQ F.10 for your
49830 F.10. Services doesn't kill users matching a newly-added autokill mask even
49831 if ImmediatelySendAutokill is set.
49833 Services never kills users when a new autokill is added; the
49834 ImmediatelySendAutokill configuration directive only causes
49835 Services to send the autokill itself (that is, the user/host mask
49836 to prohibit new connections from) to the IRC servers on your
49837 network. This is a safety feature intended to limit the damage
49838 caused by a mistyped autokill.
49840 Note that some IRC servers will themselves kill users matching a
49841 newly-added autokill; this is unrelated to Services.
49844 achurch@achurch.org
49845 http://achurch.org/
49846 ------------------------------------------------------------------
49847 To unsubscribe or change your subscription options, visit:
49848 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
49851 From diego at redesul.net Sat Oct 18 14:38:17 2003
49852 From: diego at redesul.net (Diego B. Contezini)
49853 Date: Sat Oct 23 23:10:10 2004
49854 Subject: [IRCServices Coding] CORE DUMPED... Debuging
49855 Message-ID: <003f01c395c0$09a31cd0$3cc8a8c0@angel>
49857 If it helps, more lines up.. of debugging...
49860 ChanServ@services.redesul.net :op #manaus paulinhu-dissi-q-mi-ama
49861 [Oct 18 16:05:31.152195 2003] debug: Sent: :ChanServ NOTICE paulinhu-dissi-q-mi-ama :Permission denied.
49862 [Oct 18 16:05:31.152274 2003] debug: Received: :pRiCkLy SJOIN 1066501295 #Euevc
49863 [Oct 18 16:05:31.152353 2003] protocol/bahamut: debug: pRiCkLy SJOINs #Euevc
49864 [Oct 18 16:05:31.152490 2003] debug: Sent: :ChanServ MODE #EUeVC +o pRiCkLy
49865 [Oct 18 16:05:31.269153 2003] debug: Received: :Hellskitty PRIVMSG ChanServ@services.redesul.net :unban #EMOCORE
49866 [Oct 18 16:05:31.269425 2003] debug: Sent: :ChanServ NOTICE Hellskitty :Permission denied.
49867 [Oct 18 16:05:31.288596 2003] debug: Received: :|-Frango-| MODE #EMOCORE +stmipl 1
49868 [Oct 18 16:05:31.288768 2003] debug: Received: :|-Frango-| TOPIC #EMOCORE |-Frango-| 1066460927 :TakeOver by 14,1 -15=0[ 14He15l0lR15ai14ser 0]15=14- S15c0ri15p14t 15v3.8
49869 [Oct 18 16:05:31.288944 2003] debug: Sent: :ChanServ TOPIC #EMOCORE reffer 1066055037 :1??? Festival HARDcoCOREcore dia 25 de outubro em blumenau no rio bravo bar (proximo a resima agua verde), com as bandas: Zero Ltda (curitiba), Swallow the Waffle (bc), chymia(bnu), crazy frogs (lages), surpise set e slipper (bnu)...3 pila entrada inicio as 15:00 horas'
49870 [Oct 18 16:05:31.289032 2003] debug: Received: :|-Frango-| MODE #EMOCORE -oooooo CHoPP CbRS-oFF caroll BRYAN brunaH balsanelli
49871 Segmentation fault (core dumped)
49873 -------------- next part --------------
49874 An HTML attachment was scrubbed...
49875 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20031018/667c67fa/attachment-0004.htm
49876 From ballsy at mystical.net Mon Oct 20 08:19:44 2003
49877 From: ballsy at mystical.net (Ballsy)
49878 Date: Sat Oct 23 23:10:10 2004
49879 Subject: [IRCServices Coding] Re: Akill problem in 5.0.22
49880 In-Reply-To: <200310182149.18600.v13@it.teithe.gr>
49881 References: <3f9012b8.23176@achurch.org> <030801c3950f$3cb55270$6401a8c0@turby>
49882 <3F90BF77.2010706@t2n.org> <200310182149.18600.v13@it.teithe.gr>
49883 Message-ID: <6.0.0.22.0.20031020091611.01b47318@127.0.0.1>
49885 Yes, Bahamut will immediately kill users matching an Akill. It
49886 won't wait for another client from that host to connect. My setup of IRC
49887 Services 5.0.22 and bahamut-1.4.30 is doing it right now. As alluded to in
49888 a previous email, however, you may need to commented out EnableExclude in
49889 the services config to have this work.
49894 At 12:49 PM 18/10/2003, V13 wrote:
49895 >On Saturday 18 October 2003 07:20, Robert F Merrill wrote:
49897 > > >Would have been nice if someone had mentioned that (about the
49898 > > >ImmediatelySendAutokill) from the start. I would say the flag is
49899 > > > misleading in title then, because I (and 8 other people on my staff --
49900 > > > none of us are dummies, either) read that as meaning it will Immediately
49901 > > > send the auto kill... "ImmediatelyUpdateServers" might be more fitting
49902 > > > from an intuitive standpoint, not that I'm suggesting changing the name,
49903 > > > but at least the documentation of it could be a bit more explicit IMHO.
49905 > > It DOES immediately send the autokill. You just don't grasp the meaning
49906 > > of sending the autokill.
49907 > > It literally sends an AKILL (or TKL in the case of unreal) message to
49908 > > the servers. At least unreal
49909 > > and bahamut will then scan for matching clients and disconnect them,
49910 > > however not all servers
49913 >FYI bahamut doesn't do this. It will only do it whenever a new client that
49914 >matches the akill connects to the server.
49916 >i.e. if you set an akill for *.com noone will be disconnected untill a new
49917 >client from *.com gets connected (at that moment, all matching clients will
49918 >be killed). In the mean time, anyone from other domains can connect to the
49919 >server without having any user killed.
49922 >------------------------------------------------------------------
49923 >To unsubscribe or change your subscription options, visit:
49924 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
49928 From oska at mynet.com Tue Oct 21 22:24:34 2003
49929 From: oska at mynet.com (oska)
49930 Date: Sat Oct 23 23:10:10 2004
49931 Subject: [IRCServices Coding] "Re: Contents of IRCServices-Coding digest..."
49932 Message-ID: <HN58ED$I890Q9pEOh0UN3QcHkNkg1Bm2fHspFZq@mynet.com>
49934 An HTML attachment was scrubbed...
49935 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20031022/9c540c11/attachment-0004.html
49936 From laser at musichat.net Fri Oct 24 10:35:48 2003
49937 From: laser at musichat.net (laser@musichat.net)
49938 Date: Sat Oct 23 23:10:10 2004
49939 Subject: [IRCServices Coding] Il momento e' catartico
49940 Message-ID: <20031024173545.9ACA817038@snow.fingers.co.za>
49942 Ricevo e cortesemente inoltro,.... un premio per la genialit?
49943 hanno reso mitico un salva schermo scaricalo, "poesie catartiche", che non sai cosa ti perdi
49946 -------------- next part --------------
49947 An HTML attachment was scrubbed...
49948 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20031024/97501fa5/attachment-0004.htm
49949 From diego at redesul.net Fri Oct 24 16:03:05 2003
49950 From: diego at redesul.net (Diego B. Contezini)
49951 Date: Sat Oct 23 23:10:10 2004
49952 Subject: [IRCServices Coding] CORE DUMPED! BUG!
49953 References: <3f8f9304.20227@achurch.org> <000e01c395ac$5b773b40$3cc8a8c0@angel>
49954 Message-ID: <012e01c39a8b$531829d0$3cc8a8c0@angel>
49956 Andrew, have anything more of dumping/debugging that i can do/give for helps
49958 (if it helps, here its rh9.0, libc 2.3.2, linux x86, kernel 2.4.20-8,
49959 Pentium III 1ghz 512mb ram DDR)....
49969 From andrew at wtfigo.co.uk Tue Nov 4 02:15:11 2003
49970 From: andrew at wtfigo.co.uk (Andrew Kempe)
49971 Date: Sat Oct 23 23:10:10 2004
49972 Subject: [IRCServices Coding] test
49973 Message-ID: <E1AGyDD-0001mX-00@smtp.mailbox.co.uk>
49977 From diego at redesul.net Tue Nov 4 16:43:45 2003
49978 From: diego at redesul.net (Diego B. Contezini)
49979 Date: Sat Oct 23 23:10:10 2004
49980 Subject: [IRCServices Coding] CORE DUMPED! BUG!
49981 Message-ID: <014f01c3a335$e1e08dd0$3cc8a8c0@angel>
49983 I found a bug (occuring on the old-last vesion of ircservices -
49984 ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
49986 yes, 5.0.23 is the last.. but nothing has changed about the bug...
49988 here is the debugging:
49990 ChanServ@services.redesul.net :op #manaus paulinhu-dissi-q-mi-ama
49991 [Oct 18 16:05:31.152195 2003] debug: Sent: :ChanServ NOTICE
49992 paulinhu-dissi-q-mi-ama :Permission denied.
49993 [Oct 18 16:05:31.152274 2003] debug: Received: :pRiCkLy SJOIN 1066501295
49995 [Oct 18 16:05:31.152353 2003] protocol/bahamut: debug: pRiCkLy SJOINs #Euevc
49996 [Oct 18 16:05:31.152490 2003] debug: Sent: :ChanServ MODE #EUeVC +o pRiCkLy
49997 [Oct 18 16:05:31.269153 2003] debug: Received: :Hellskitty PRIVMSG
49998 ChanServ@services.redesul.net :unban #EMOCORE
49999 [Oct 18 16:05:31.269425 2003] debug: Sent: :ChanServ NOTICE Hellskitty
50000 :Permission denied.
50001 [Oct 18 16:05:31.288596 2003] debug: Received: :|-Frango-| MODE #EMOCORE
50003 [Oct 18 16:05:31.288768 2003] debug: Received: :|-Frango-| TOPIC #EMOCORE
50004 |-Frango-| 1066460927 :TakeOver by 14,1 -15=0[ 14He15l0lR15ai14ser 0]15=14-
50005 S15c0ri15p14t 15v3.8
50006 [Oct 18 16:05:31.288944 2003] debug: Sent: :ChanServ TOPIC #EMOCORE reffer
50007 1066055037 :1i?? Festival HARDcoCOREcore dia 25 de outubro em blumenau no
50008 rio bravo bar (proximo a resima agua verde), com as bandas: Zero Ltda
50009 (curitiba), Swallow the Waffle (bc), chymia(bnu), crazy frogs (lages),
50010 surpise set e slipper (bnu)...3 pila entrada inicio as 15:00 horas'
50011 [Oct 18 16:05:31.289032 2003] debug: Received: :|-Frango-| MODE
50012 #EMOCORE -oooooo CHoPP CbRS-oFF caroll BRYAN brunaH balsanelli
50013 Segmentation fault (core dumped)
50016 Debugging my core... i can found:
50017 #0 0x0804d830 in add_mode_with_params (md=0x806aa00, mode=111 'o',
50018 is_add=1, params=1, parambuf=0xbfffe280 "balsanelli",
50019 len=10) at actions.c:568
50020 568 md->params[md->nopmodes][len] = 0;
50022 #0 0x0804d830 in add_mode_with_params (md=0x806aa00, mode=111 'o',
50023 is_add=1, params=1, parambuf=0xbfffe280 "balsanelli",
50024 len=10) at actions.c:568
50026 #1 0x0804d342 in set_cmode (sender=0x81db058 "ChanServ", channel=0xa905d00)
50029 "balsanelli\000\b\025\225\002BWi??\022B\024\032\023Bi??i??i??i??\000\000\000
50030 \000\034 \006\bi??i??i??i??hi??i??i??i??i??i??i??\025\224\004B\034
50031 \006\b\000\000\000\000i??m\tBdi??\022Bi??q\a\b\000\000\000\000eR :\0037[
50032 \0034#\003di??\022B\000\000\000\000i??\037\006\bi??\037\006\bi??i??i??i??$i?
50033 ?\006Bi??i??i??i??\bi??i??i??\000\000\000\000Hi??i??i??\025\224\004B@\002\a\
50034 b8i??i??i??6\020\aBpi??i??i??@i??\006\b@\002\a\b\000\000\000\000i??<\023BLi?
50035 ?i??i??=S\004B\024\032\023B\001\020\000\000@i??\006\bhi??i??i??\204i??\006Bp
50036 i??i??i??i??\037\006\b"...
50041 args = 0xbfffe6d0 "RDcoCOREcorei??i??i??i??o"
50042 modes = 0xbfffeae2 ""
50043 modes_orig = 0xbfffeae0 "+o"
50044 md = (struct modedata *) 0x806aa00
50049 #2 0x400895ff in local_set_cumodes (c=0xa905d00, plusminus=43 '+', modes=1,
50050 nick=0xab7f2e8 "balsanelli") at check.c:432
50052 modestr = "o\000\000 de outubro em blumenau no rio bravo bar
50053 (proximo a resima agua verde), com as bandas: Zero
50054 L\v\000\000\000(curitiba), \000\000\000\000low the Waff\000\000\000\000bc),
50055 chymia(bnu), crazy frogs (lages), surpise set e slipper (bnu).."...
50057 #3 0x40088d74 in check_chan_user_modes (source=0xbfffeed0 "|-Frango-|",
50058 u=0xab34ff0, c=0xa905d00, oldmodes=1)
50060 user = (User *) 0xab7f2d8
50061 ci = (ChannelInfo *) 0xa571940
50065 #4 0x400820ed in do_channel_umode_change (source=0xbfffeed0 "|-Frango-|",
50066 c=0xa905d00, u=0xab34ff0, oldmodes=1)
50069 #5 0x0805890d in call_callback_5 (module=0x806a5c0, id=23, arg1=0xbfffeed0,
50070 arg2=0xa905d00, arg3=0xab34ff0, arg4=0x1,
50071 arg5=0x0) at modules.c:666
50072 cl = (CallbackList *) 0x8077cb8
50075 #6 0x0804edc8 in do_cumode (source=0xbfffeed0 "|-Frango-|", chan=0xa905d00,
50076 flag=1, add=0, nick=0xbfffecc9 "balsanelli")
50077 ---Type <return> to continue, or q <return> to quit---
50079 u = (struct c_userlist *) 0xab34ff0
50080 user = (User *) 0xab7f2d8
50082 #7 0x0804e97e in do_cmode (source=0xbfffeed0 "|-Frango-|", ac=0,
50083 av=0xa853130) at channels.c:302
50086 params = -1073746288
50087 chan = (Channel *) 0xa905d00
50090 modestr = 0xbfffec9e "-oooooo"
50091 #8 0x080557ff in m_mode (source=0xbfffeed0 "|-Frango-|", ac=8,
50092 av=0xa853110) at messages.c:101
50094 #9 0x0805920e in process () at process.c:133
50095 m = (Message *) 0x8067dd8
50097 "|-Frango-|\000\000G\000\000\000Y\e\205\n\t+\205\n\bi??i??i??i??i??\005\b@j\
50098 a\b\000\004\000\000i??\032\205\n\t\000\000\000@j\a\b\216j\a\b(i??i??i??qP\00
50101 "MODE\000\000\000i??8i??i??i??i??\005\b\000\000\000\000i??i??i??i??\000\000\
50102 000\000\000\000\000\000\001H\000\000Pi??i??i??\000Y\a\bVi??\005\b\207j\a\bP\
50103 e\205\n\t\000\000\000i??i??\005\b"
50105 "MODE\000#EMOCORE\000-oooooo\000CHoPP\000CbRS-oFF\000caroll\000BRYAN\000brun
50106 aH\000balsanelli\000 balsanelli\000\000ai\00314ser \0030]\00315=\00314-
50107 S\00315c\0030ri\00315p\00314t \00315\037v\0373.8 \003\000\00315\037v\0373.8
50108 \003\000\000\0003)\000\0006\037\002Pi??Ti??\00313\037\002]\037\002\0036i??i?
50109 ? \000i??Ti??\00313\037\002]\037\002\0036i??i?? \000\000\003\000\000r
50110 \003", '\0' <repeats 11 times>...
50111 s = 0xbfffec95 "#EMOCORE"
50113 av = (char **) 0xa853110
50114 #10 0x0805507d in readline_callback (s=0xa851ae0, param_unused=0x50) at
50117 #11 0x0805b617 in check_sockets () at sockets.c:491
50118 newline = 0xa851b58 "\nrct-sc.br irc.creativenet.com.br 0 3364349034
50119 :aNiNhHa[du]DoNaTeLo\n:Toh_Pensanu PART #ilheus\n:_LoKo_SuL_ SJOIN
50120 1063565447 #elias\n:_MoRgAnA_ PRIVMSG NickServ@services.redesul.net :set
50121 nomemo off\n:irc."...
50124 rfds = {fds_bits = {16, 0 <repeats 31 times>}}
50125 wfds = {fds_bits = {0 <repeats 32 times>}}
50126 tv = {tv_sec = 2, tv_usec = 980000}
50129 s = (Socket *) 0xa851ae0
50130 s2 = (Socket *) 0x0
50131 #12 0x0805538a in main (ac=3, av=0xbffff164, envp=0xbffff174) at main.c:266
50132 ---Type <return> to continue, or q <return> to quit---
50134 now_msec = 1348441861
50135 last_update = 1066500208
50136 last_check = 1348441182
50137 #13 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
50138 No symbol table info available.
50139 (gdb) info registers
50140 eax 0xd6b2bf8a -692928630
50141 ecx 0x806aa00 134654464
50142 edx 0x656e6173 1701732723
50143 ebx 0x42131a14 1108548116
50144 esp 0xbfffd910 0xbfffd910
50145 ebp 0xbfffe238 0xbfffe238
50146 esi 0x8075900 134699264
50147 edi 0xbffff050 -1073745840
50148 eip 0x804d830 0x804d830
50149 eflags 0x10282 66178
50159 root@irc(/home/ircadmin/services/lib)# ls -la core.12631
50160 -rw------- 1 ircadmin ircadmin 47374336 Oct 18 16:05 core.12631
50161 root@irc(/home/ircadmin/services)# ldd ircservices
50162 libdl.so.2 => /lib/libdl.so.2 (0x4001e000)
50163 libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
50164 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
50165 root@irc(/home/ircadmin/services)# uname -a
50166 Linux XXXXXX.xyz.0xdeadbeef 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686
50167 i686 i386 GNU/Linux
50168 root@irc(/home/ircadmin/services)# cat /etc/redhat-release
50169 Red Hat Linux release 9 (Shrike)
50170 root@irc(/home/ircadmin/services)# cat /proc/cpuinfo
50172 model name : Pentium III (Coppermine)
50175 cache size : 256 KB
50177 root@irc(/home/ircadmin/services)# free
50178 total used free shared buffers cached
50179 Mem: 513792 482248 31544 0 69492 274980
50181 I changed version of linux, runned it on 3 different machines, on
50182 slackware/redhat, pentiumIII, K5, P200.
50183 This bug is as older as i run services... dont know if its the same of the
50184 4.X (that i changed to 5.X to "solve" this bug), but from 5.12 to now, it
50185 continue happening... aways...
50186 Dont have a exactly time to happen, its insane... i think that its a
50187 coincidence of some commands that on the memory ends fucking some variable.
50188 if you want look the incidence, here its:
50189 root@irc(/home/ircadmin/services/lib)# ls -la core*
50191 -rw------- 1 ircadmin ircadmin 49025024 Oct 5 19:32 core.27214
50192 -rw------- 1 ircadmin ircadmin 45932544 Oct 5 21:01 core.14414
50193 -rw------- 1 ircadmin ircadmin 46948352 Oct 6 14:00 core.18016
50194 -rw------- 1 ircadmin ircadmin 45936640 Oct 11 04:30 core.1347
50195 -rw------- 1 ircadmin ircadmin 50479104 Oct 14 01:29 core.16481
50196 -rw------- 1 ircadmin ircadmin 44982272 Oct 15 13:54 core.22332
50197 -rw------- 1 ircadmin ircadmin 47374336 Oct 18 16:05 core.12631
50198 -rw------- 1 ircadmin ircadmin 48099328 Oct 19 14:16 core.5362
50199 -rw------- 1 ircadmin ircadmin 44863488 Oct 19 14:22 core.32708
50200 -rw------- 1 ircadmin ircadmin 45355008 Nov 1 15:13 core.28309
50201 -rw------- 1 ircadmin ircadmin 50360320 Nov 3 18:24 core.5160
50204 If it helps, here is the debugging of the last two cores, on gdb:
50207 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
50212 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
50215 chan = (Channel *) 0xa87d1e0
50216 s = 0x1f73746f <Address 0x1f73746f out of bounds>
50218 modestr = 0x1f73746f <Address 0x1f73746f out of bounds>
50219 #1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:680
50220 buf = "-imsl\000HA___\000\000\000\000\000W
50221 \022B\000\000\000L\000\000\000\000\000y\000nossaTZ\000\000\000\000\000\000yy
50222 yyA<\023B\001\000\000\000\bYy?Om\tBd
50223 \022BDq\a\bOUy?NO\006B\210o\a\b3\035\rB\024\032\023BAa\006B\003\000\000\000a
50224 Yy?\027\000\000\000\024\032\023B\024\032\023BTZ\000\000\004\000\000\000\005\
50225 000\000\000\210o\a\baYy?\030Yy?NO\006B\210o\a\baYy?\027\000\000\000$u\006B\2
50226 10o\a\bIo\a\b\vO\006B\024\032\023B\024\032\023B@\002\a\bHYy?$u\006B\200Yy?@o
50228 s = 0xbfffdc60 "-imsl"
50229 argv = {0xa87d1e8 "#soad",
50230 0x1f73746f <Address 0x1f73746f out of bounds>,
50231 0x5303200f <Address 0x5303200f out of bounds>,
50232 0x6c6c6568 <Address 0x6c6c6568 out of bounds>,
50233 0x4323203a <Address 0x4323203a out of bounds>,
50234 0x65746e65 <Address 0x65746e65 out of bounds>,
50235 0x65685372 <Address 0x65685372 out of bounds>,
50236 0x52426c6c <Address 0x52426c6c out of bounds>}
50238 ---Type <return> to continue, or q <return> to quit---
50241 #2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
50245 md = (struct modedata *) 0x0
50250 #3 0x080553a3 in main (ac=1, av=0xbfffe574, envp=0xbfffe57c) at main.c:269
50252 now_msec = -1555790286
50253 last_update = 1067890538
50254 last_check = 2739174210
50255 #4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
50256 No symbol table info available.
50260 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
50265 #0 0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
50268 chan = (Channel *) 0xa9be840
50269 s = 0xbf000000 <Address 0xbf000000 out of bounds>
50271 modestr = 0xbf000000 <Address 0xbf000000 out of bounds>
50272 #1 0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:680
50273 buf = "-imsl\000\a\b\000len\000\000\000\000W
50274 \022B3\035\rB\024\032\023BAa\006B\003\000\000\000
50275 oy?\027\000\000\000yyyyA<\023BTZ\000\000\004\000\000\000\005\000\000\000\210
50276 o\a\b oy?Xoy?NO\006B\210o\a\b
50277 oy?\027\000\000\000$u\006B\210o\a\bIo\a\b\vO\006B\024\032\023B\024\032\023B@
50278 \002\a\b\210oy?$u\006BAoy?@o\006\b@\002\a\b\000\000\000\000\024\032\023B@\00
50279 2\a\b?oy?6\020\aBaoy?@o\006\b@\002\a\b\000\000\000\000Aoy?I\037\006\b=S\004B
50280 \024\032\023B\001\020\000\000@o\006\b"...
50281 s = 0xbffff2e0 "-imsl"
50282 argv = {0xa9be848 "#zoera",
50283 0xbf000000 <Address 0xbf000000 out of bounds>, 0x0,
50284 0x806f240 "ircservices.log", 0x806f240 "ircservices.log",
50285 0x5a54 <Address 0x5a54 out of bounds>, 0x0,
50286 0xffffffff <Address 0xffffffff out of bounds>}
50290 #2 0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
50291 ---Type <return> to continue, or q <return> to quit---
50295 md = (struct modedata *) 0x0
50300 #3 0x080553a3 in main (ac=1, av=0xbffffbf4, envp=0xbffffbfc) at main.c:269
50302 now_msec = -1740061222
50303 last_update = 1067706282
50304 last_check = 2554904000
50305 #4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
50306 No symbol table info available.
50309 Im running it more a time on Screen to can get exactly where occur the bug
50310 (with -nofork -debug), to look for more examples of commands that causes
50312 if have something (more) that i can to add/do to helps on debugging, please,
50313 tell me.. i have the core (i cant send it, for secure reasons... have all my
50314 db on the core... ), but im open to helps anytime anywhere... with
50317 Thanks for all development, this is really a bealtifull software...
50318 (and sorry for my bad english)
50320 Diego B. Contezini aka destruct_ #irc.redesul.net
50324 From diego at redesul.net Tue Nov 4 16:46:53 2003
50325 From: diego at redesul.net (Diego B. Contezini)
50326 Date: Sat Oct 23 23:10:10 2004
50327 Subject: [IRCServices Coding] about.. CORE DUMPED! BUG!
50328 Message-ID: <01fa01c3a336$4e884220$3cc8a8c0@angel>
50330 If it helps, im using Bahamut here....
50333 From achurch at achurch.org Wed Nov 5 13:20:15 2003
50334 From: achurch at achurch.org (Andrew Church)
50335 Date: Sat Oct 23 23:10:10 2004
50336 Subject: [IRCServices Coding] Bug or misunderstood ?
50337 In-Reply-To: <000901c39496$71764f10$a37faec3@coder>
50338 Message-ID: <3fa87c99.57222@achurch.org>
50340 >Im using unreal ircd. When channel is empty and if channel owner joins
50341 >his/her registered channel it does
50342 >(ChanServ sets mode: +ntrq nick) but when channel is not empty and if
50343 >channel owner joins his/her registered channel it does (ChanServ sets mode:
50344 >+oq nick nick). As you see on the first one there is no +o and because of
50345 >this chanserv does not update the last_used time because chanserv is set to
50346 >update last_used time with +o (CUMODE_o) so channels drop while channel
50347 >owners use them. Is this a bug or my misunderstood ?
50349 This is a bug; I've fixed it for the next release, thanks for the
50350 report. As regards your other message, not setting the last-used time for
50351 +a/+q users is designed behavior (see section 3-2-1 of the manual: "`used'
50352 means that a user with auto-op privileges ... has entered the channel"), as
50353 well as unnecessary in typical channel settings (where +a users are a
50354 subset of +o users), but if you have any better suggestions on how to
50355 determine when a channel is being used by proper users as opposed to (for
50356 example) spammers or people just entering to see if the channel is
50357 available, I'm willing to listen.
50360 achurch@achurch.org
50361 http://achurch.org/
50363 From rg at tcslon.com Fri Nov 7 02:03:27 2003
50364 From: rg at tcslon.com (Russell Garrett)
50365 Date: Sat Oct 23 23:10:10 2004
50366 Subject: [IRCServices Coding] Badly punctuated parameter list in `#define'
50367 Message-ID: <MKEGJINFADFODDNOKEJCMELPEGAA.rg@tcslon.com>
50369 I'm getting this too - it's just started happening in 5.0.23:
50371 gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -fno-builtin-log
50372 -I.. -DCONVERT_DB -c convert-cygnus.c -o convert-cygnus.o
50373 convert-cygnus.c:35: badly punctuated parameter list in `#define'
50374 convert-cygnus.c:48: badly punctuated parameter list in `#define'
50376 gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
50381 From rayfordp at mhcable.com Thu Nov 13 17:08:11 2003
50382 From: rayfordp at mhcable.com (Rayford Pomeroy)
50383 Date: Sat Oct 23 23:10:11 2004
50384 Subject: [IRCServices Coding] Akill type?
50385 Message-ID: <20031114062307.4856C170E7@snow.fingers.co.za>
50387 Where is the akill type used in some of the AutoKill functions listed in the
50388 modules/database/readme file defined?
50390 ________________________________________________
50391 Message sent using MHCABLE Webmail
50394 From arathorn at theonering.net Fri Nov 14 14:32:39 2003
50395 From: arathorn at theonering.net (Arathorn)
50396 Date: Sat Oct 23 23:10:11 2004
50397 Subject: [IRCServices Coding] [PATCH] Fix of rogue unescaped backtick in
50398 configure in 5.0.24
50399 In-Reply-To: <Pine.LNX.4.56L0.0311122252050.7240@phoenix.siarch.net>
50400 References: <3fb090ea.04554@achurch.org>
50401 <Pine.LNX.4.56L0.0311122252050.7240@phoenix.siarch.net>
50402 Message-ID: <Pine.LNX.4.56L0.0311142227470.15812@phoenix.siarch.net>
50404 Well, I just had another chance to look more carefully at the configure
50405 script - looks like there's a rogue unescaped backtick in the deprecation
50406 warning text block; I hope the attached patch will save others unfortunate
50407 enough to still be running 2.95 from trauma in ./configure :)
50409 diff -ur ircservices-5.0.24-orig/configure ircservices-5.0.24/configure
50410 --- ircservices-5.0.24-orig/configure Wed Nov 5 01:46:59 2003
50411 +++ ircservices-5.0.24/configure Fri Nov 14 17:04:08 2003
50412 @@ -875,7 +875,7 @@
50413 elif test $vmajor -lt 3 -a $version != 2.95.3 || test $vmajor = 3 -a $vminor -lt 2 ; then
50416 -WARNING: Your version of GCC was detected as `$version'. As of Services
50417 +WARNING: Your version of GCC was detected as \`$version'. As of Services
50418 5.0.23, versions of GCC earlier than 3.2, other than 2.95.3,
50419 have been deprecated. This and future releases of Services 5.0
50420 will still work, though some error messages will lose
50423 ________________________________________________________________
50424 Matthew Hodgson arathorn@theonering.net Tel: +44 7968 722968
50425 Arathorn: Co-Sysadmin, TheOneRing.net?
50427 On Wed, 12 Nov 2003, Arathorn wrote:
50431 > Just tried to upgrade to 5.0.24 on my Debian Woody production server
50432 > running gcc 2.95.4. I appreciate that this is <3.2 and !=2.95.3, but I
50433 > didn't expect ./configure to completely keel over on me (and hoped to be
50434 > able to use a -force configure option of some kind to get it to compile
50437 > Here's the stderr & stdio - the configure.log is attached:
50439 > pe1650 18# gcc -v
50440 > Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
50441 > gcc version 2.95.4 20011002 (Debian prerelease)
50442 > pe1650 19# ./configure -ignore-cache
50444 > Beginning IRC Services configuration.
50446 > In what directory do you want the binaries to be installed?
50447 > Press Return for the default, or enter a new value.
50448 > [/usr/local/sbin] /usr/local/sbin/ircservices-5.0.24-unr
50450 > Where do you want the data files to be installed?
50451 > [/usr/local/sbin/ircservices-5.0.24-unr/lib] /usr/local/lib/ircservices-5.0
50453 > End of interactive configuration.
50455 > Checking sanity of /bin/sh... high.
50456 > Searching for a suitable compiler... ./configure: command substitution:
50457 > line 1: unexpected EOF while looking for matching `''
50458 > ./configure: command substitution: line 8: syntax error: unexpected end of file
50460 > WARNING: Your version of GCC was detected as Press Enter to continue:
50464 > Testing default compiler flags ()... no luck! Using no flags.
50465 > If you know what flags you want, use the -cflags option to configure.
50466 > Let's see what libraries we need...
50467 > Checking if we can use dynamic modules... no.
50468 > Checking whether ranlib exists... yes.
50469 > Looking for an 8-bit integer type...
50470 > *** WHOA THERE! ***
50472 > We suddenly couldn't compile using the C compiler we already tested!
50473 > The command line we used was:
50474 > conf-tmp/test.c -o conf-tmp/test
50475 > Please try to fix this; if you can't, mail achurch@achurch.org
50476 > with information about your system, the output from this script,
50477 > and the `configure.log' file generated by this script.
50479 > ________________________________________________________________
50480 > Matthew Hodgson arathorn@theonering.net Tel: +44 7968 722968
50481 > Arathorn: Co-Sysadmin, TheOneRing.net?
50483 > On Tue, 11 Nov 2003, Andrew Church wrote:
50485 > > Services 5.0.24 has been released, and can be downloaded from:
50487 > > ftp://ftp.esper.net/ircservices/ (USA, California)
50489 > > d8f808b04744e9db365ebb23f7d04078 ircservices-5.0.24.tar.gz
50490 > > e2415db90e2c9f3391268b8d48ef40d1 ircservices-5.0.24.diff.gz
50491 > > 07d0785f095de88f87de8b4d97024558 ircservices-5.0.24-1.i386.rpm
50492 > > 0235352278f534a818699281fcc7ba83 ircservices_5.0.24-1_i386.deb
50494 > > ftp.ircservices.za.net and the other mirrors should have it shortly.
50496 > > This release includes a workaround for those who were unable to
50497 > > compile 5.0.23; however, please note that being unable to compile means
50498 > > that your compiler is outdated, and you should upgrade it (or have the
50499 > > server administrator upgrade it) as soon as possible. Support for such
50500 > > compilers will be removed entirely in a future version.
50502 > > Changes in version 5.0.24
50503 > > -------------------------
50504 > > 2003/11/11 Fixed a warning in convert-db compilation.
50505 > > 2003/11/11 Fixed bugs in convert-db causing some nickname and channel
50506 > > settings (timezone, language, channel and memo limits)
50507 > > to not be initialized properly.
50508 > > 2003/11/11 Added -tzfile, -no-timezones, and -reset-memo-limits
50509 > > options to the Cygnus database converter in convert-db.
50510 > > 2003/11/05 Databases can now be exported in XML from the command line
50511 > > (-export option).
50512 > > 2003/11/05 GCC versions earlier than 3.2 (except 2.95.3) are now
50513 > > deprecated. Variadic macros workaround added for
50514 > > problem reported by Ali Sor <alisor@softhome.net>
50515 > > 2003/11/05 Channel last-used time is now updated properly for the
50516 > > first user to enter the channel if the user has auto-op
50517 > > privileges. Reported by <saman@alkol.org>
50519 > > --Andrew Church
50520 > > achurch@achurch.org
50521 > > http://achurch.org/
50522 > > ------------------------------------------------------------------
50523 > > To unsubscribe or change your subscription options, visit:
50524 > > http://www.ircservices.za.net/mailman/listinfo/ircservices
50527 -------------- next part --------------
50528 diff -ur ircservices-5.0.24-orig/configure ircservices-5.0.24/configure
50529 --- ircservices-5.0.24-orig/configure Wed Nov 5 01:46:59 2003
50530 +++ ircservices-5.0.24/configure Fri Nov 14 17:04:08 2003
50531 @@ -875,7 +875,7 @@
50532 elif test $vmajor -lt 3 -a $version != 2.95.3 || test $vmajor = 3 -a $vminor -lt 2 ; then
50535 -WARNING: Your version of GCC was detected as `$version'. As of Services
50536 +WARNING: Your version of GCC was detected as \`$version'. As of Services
50537 5.0.23, versions of GCC earlier than 3.2, other than 2.95.3,
50538 have been deprecated. This and future releases of Services 5.0
50539 will still work, though some error messages will lose
50540 From arathorn at theonering.net Fri Nov 14 14:56:49 2003
50541 From: arathorn at theonering.net (Arathorn)
50542 Date: Sat Oct 23 23:10:11 2004
50543 Subject: [IRCServices Coding] [PATCH] Fix of rogue unescaped backtick in
50544 configure in 5.0.24
50545 Message-ID: <Pine.LNX.4.56L0.0311142254250.16502@phoenix.siarch.net>
50547 Well, I just had another chance to look more carefully at the configure
50548 script - looks like there's a rogue unescaped backtick in the deprecation
50549 warning text block:
50552 diff -ur ircservices-5.0.24-orig/configure ircservices-5.0.24/configure
50553 --- ircservices-5.0.24-orig/configure Wed Nov 5 01:46:59 2003
50554 +++ ircservices-5.0.24/configure Fri Nov 14 17:04:08 2003
50555 @@ -875,7 +875,7 @@
50556 elif test $vmajor -lt 3 -a $version != 2.95.3 || test $vmajor = 3 -a $vminor -lt 2 ; then
50559 -WARNING: Your version of GCC was detected as `$version'. As of Services
50560 +WARNING: Your version of GCC was detected as \`$version'. As of Services
50561 5.0.23, versions of GCC earlier than 3.2, other than 2.95.3,
50562 have been deprecated. This and future releases of Services 5.0
50563 will still work, though some error messages will lose
50567 (due to pine insisting on base64'ing mime attachments, i haven't attached
50568 the file as Andrew's mail system doesn't seem to approve of base64. -
50569 apologies if this mail shows up twice for anyone.)
50571 ________________________________________________________________
50572 Matthew Hodgson arathorn@theonering.net Tel: +44 7968 722968
50573 Arathorn: Co-Sysadmin, TheOneRing.net?
50575 On Wed, 12 Nov 2003, Arathorn wrote:
50579 > Just tried to upgrade to 5.0.24 on my Debian Woody production server
50580 > running gcc 2.95.4. I appreciate that this is <3.2 and !=2.95.3, but I
50581 > didn't expect ./configure to completely keel over on me (and hoped to be
50582 > able to use a -force configure option of some kind to get it to compile
50585 > Here's the stderr & stdio - the configure.log is attached:
50587 > pe1650 18# gcc -v
50588 > Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
50589 > gcc version 2.95.4 20011002 (Debian prerelease)
50590 > pe1650 19# ./configure -ignore-cache
50592 > Beginning IRC Services configuration.
50594 > In what directory do you want the binaries to be installed?
50595 > Press Return for the default, or enter a new value.
50596 > [/usr/local/sbin] /usr/local/sbin/ircservices-5.0.24-unr
50598 > Where do you want the data files to be installed?
50599 > [/usr/local/sbin/ircservices-5.0.24-unr/lib] /usr/local/lib/ircservices-5.0
50601 > End of interactive configuration.
50603 > Checking sanity of /bin/sh... high.
50604 > Searching for a suitable compiler... ./configure: command substitution:
50605 > line 1: unexpected EOF while looking for matching `''
50606 > ./configure: command substitution: line 8: syntax error: unexpected end of file
50608 > WARNING: Your version of GCC was detected as Press Enter to continue:
50612 > Testing default compiler flags ()... no luck! Using no flags.
50613 > If you know what flags you want, use the -cflags option to configure.
50614 > Let's see what libraries we need...
50615 > Checking if we can use dynamic modules... no.
50616 > Checking whether ranlib exists... yes.
50617 > Looking for an 8-bit integer type...
50618 > *** WHOA THERE! ***
50620 > We suddenly couldn't compile using the C compiler we already tested!
50621 > The command line we used was:
50622 > conf-tmp/test.c -o conf-tmp/test
50623 > Please try to fix this; if you can't, mail achurch@achurch.org
50624 > with information about your system, the output from this script,
50625 > and the `configure.log' file generated by this script.
50627 > ________________________________________________________________
50628 > Matthew Hodgson arathorn@theonering.net Tel: +44 7968 722968
50629 > Arathorn: Co-Sysadmin, TheOneRing.net?
50631 > On Tue, 11 Nov 2003, Andrew Church wrote:
50633 > > Services 5.0.24 has been released, and can be downloaded from:
50635 > > ftp://ftp.esper.net/ircservices/ (USA, California)
50637 > > d8f808b04744e9db365ebb23f7d04078 ircservices-5.0.24.tar.gz
50638 > > e2415db90e2c9f3391268b8d48ef40d1 ircservices-5.0.24.diff.gz
50639 > > 07d0785f095de88f87de8b4d97024558 ircservices-5.0.24-1.i386.rpm
50640 > > 0235352278f534a818699281fcc7ba83 ircservices_5.0.24-1_i386.deb
50642 > > ftp.ircservices.za.net and the other mirrors should have it shortly.
50644 > > This release includes a workaround for those who were unable to
50645 > > compile 5.0.23; however, please note that being unable to compile means
50646 > > that your compiler is outdated, and you should upgrade it (or have the
50647 > > server administrator upgrade it) as soon as possible. Support for such
50648 > > compilers will be removed entirely in a future version.
50650 > > Changes in version 5.0.24
50651 > > -------------------------
50652 > > 2003/11/11 Fixed a warning in convert-db compilation.
50653 > > 2003/11/11 Fixed bugs in convert-db causing some nickname and channel
50654 > > settings (timezone, language, channel and memo limits)
50655 > > to not be initialized properly.
50656 > > 2003/11/11 Added -tzfile, -no-timezones, and -reset-memo-limits
50657 > > options to the Cygnus database converter in convert-db.
50658 > > 2003/11/05 Databases can now be exported in XML from the command line
50659 > > (-export option).
50660 > > 2003/11/05 GCC versions earlier than 3.2 (except 2.95.3) are now
50661 > > deprecated. Variadic macros workaround added for
50662 > > problem reported by Ali Sor <alisor@softhome.net>
50663 > > 2003/11/05 Channel last-used time is now updated properly for the
50664 > > first user to enter the channel if the user has auto-op
50665 > > privileges. Reported by <saman@alkol.org>
50667 > > --Andrew Church
50668 > > achurch@achurch.org
50669 > > http://achurch.org/
50670 > > ------------------------------------------------------------------
50671 > > To unsubscribe or change your subscription options, visit:
50672 > > http://www.ircservices.za.net/mailman/listinfo/ircservices
50676 From arathorn at theonering.net Fri Nov 14 18:05:19 2003
50677 From: arathorn at theonering.net (Arathorn)
50678 Date: Sat Oct 23 23:10:11 2004
50679 Subject: [IRCServices Coding] Re: [PATCH] Fix of rogue unescaped backtick in
50680 configure in 5.0.24
50681 In-Reply-To: <3fb57b85.45153@achurch.org>
50682 References: <3fb57b85.45153@achurch.org>
50683 Message-ID: <Pine.LNX.4.56L0.0311150154580.16999@phoenix.siarch.net>
50685 Hmm, turns out that I was a little premature in sending in that one-line
50686 patch - unless I'm completely missing something, the configure script
50687 doesn't actually end up setting the CC or DEF_CC_FLAGS variables after
50688 warning about deprecation. Not sure whether this is because the
50689 deprecation is being enforced more strongly than the warnings suggest, but
50690 I expanded the tweak to the following in order to get it to build
50691 sensibly. For what it's worth, gcc 2.95.4 has never presented any
50692 problems for me with ircservices (since 4.3.3 or so) - so perhaps it might
50693 also be considerable as 'officially supported' in addition to 2.95.3 and
50694 >3.2? Debian stable has a fairly decent reputation, after all.
50696 diff -ur ircservices-5.0.24/configure ircservices-5.0.24-fixed/configure
50697 --- ircservices-5.0.24/configure Wed Nov 5 01:46:59 2003
50698 +++ ircservices-5.0.24-fixed/configure Fri Nov 14 21:01:23 2003
50699 @@ -875,7 +875,7 @@
50700 elif test $vmajor -lt 3 -a $version != 2.95.3 || test $vmajor = 3 -a $vminor -lt 2 ; then
50703 -WARNING: Your version of GCC was detected as `$version'. As of Services
50704 +WARNING: Your version of GCC was detected as \`$version'. As of Services
50705 5.0.23, versions of GCC earlier than 3.2, other than 2.95.3,
50706 have been deprecated. This and future releases of Services 5.0
50707 will still work, though some error messages will lose
50708 @@ -885,6 +885,9 @@
50710 echo2 "Press Enter to continue: "
50713 + DEF_CC_FLAGS=`def_cc_flags $CC`
50714 + log using \`gcc\'
50716 else # version okay
50717 echo "great, found gcc!"
50720 ________________________________________________________________
50721 Matthew Hodgson arathorn@theonering.net Tel: +44 7968 722968
50722 Arathorn: Co-Sysadmin, TheOneRing.net?
50724 On Sat, 15 Nov 2003, Andrew Church wrote:
50726 > Thanks, fixed. Silly little details...
50728 > (For the record, I use a homebrew mail reader which can't handle
50729 > attachments. If I do get attachments I can decode them with pine, but I
50730 > prefer patches inline so I can look at them without having to do so.)
50733 > achurch@achurch.org
50734 > http://achurch.org/
50736 > >Well, I just had another chance to look more carefully at the configure
50737 > >script - looks like there's a rogue unescaped backtick in the deprecation
50738 > >warning text block:
50741 > >diff -ur ircservices-5.0.24-orig/configure ircservices-5.0.24/configure
50742 > >--- ircservices-5.0.24-orig/configure Wed Nov 5 01:46:59 2003
50743 > >+++ ircservices-5.0.24/configure Fri Nov 14 17:04:08 2003
50744 > >@@ -875,7 +875,7 @@
50745 > > elif test $vmajor -lt 3 -a $version != 2.95.3 || test $vmajor = 3 -a $vminor -lt 2 ; then
50748 > >-WARNING: Your version of GCC was detected as `$version'. As of Services
50749 > >+WARNING: Your version of GCC was detected as \`$version'. As of Services
50750 > > 5.0.23, versions of GCC earlier than 3.2, other than 2.95.3,
50751 > > have been deprecated. This and future releases of Services 5.0
50752 > > will still work, though some error messages will lose
50756 > >(due to pine insisting on base64'ing mime attachments, i haven't attached
50757 > >the file as Andrew's mail system doesn't seem to approve of base64. -
50758 > >apologies if this mail shows up twice for anyone.)
50760 > >________________________________________________________________
50761 > >Matthew Hodgson arathorn@theonering.net Tel: +44 7968 722968
50762 > > Arathorn: Co-Sysadmin, TheOneRing.net??
50764 > >On Wed, 12 Nov 2003, Arathorn wrote:
50768 > >> Just tried to upgrade to 5.0.24 on my Debian Woody production server
50769 > >> running gcc 2.95.4. I appreciate that this is <3.2 and !=2.95.3, but I
50770 > >> didn't expect ./configure to completely keel over on me (and hoped to be
50771 > >> able to use a -force configure option of some kind to get it to compile
50774 > >> Here's the stderr & stdio - the configure.log is attached:
50776 > >> pe1650 18# gcc -v
50777 > >> Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
50778 > >> gcc version 2.95.4 20011002 (Debian prerelease)
50779 > >> pe1650 19# ./configure -ignore-cache
50781 > >> Beginning IRC Services configuration.
50783 > >> In what directory do you want the binaries to be installed?
50784 > >> Press Return for the default, or enter a new value.
50785 > >> [/usr/local/sbin] /usr/local/sbin/ircservices-5.0.24-unr
50787 > >> Where do you want the data files to be installed?
50788 > >> [/usr/local/sbin/ircservices-5.0.24-unr/lib] /usr/local/lib/ircservices-5.0
50790 > >> End of interactive configuration.
50792 > >> Checking sanity of /bin/sh... high.
50793 > >> Searching for a suitable compiler... ./configure: command substitution:
50794 > >> line 1: unexpected EOF while looking for matching `''
50795 > >> ./configure: command substitution: line 8: syntax error: unexpected end of file
50797 > >> WARNING: Your version of GCC was detected as Press Enter to continue:
50801 > >> Testing default compiler flags ()... no luck! Using no flags.
50802 > >> If you know what flags you want, use the -cflags option to configure.
50803 > >> Let's see what libraries we need...
50804 > >> Checking if we can use dynamic modules... no.
50805 > >> Checking whether ranlib exists... yes.
50806 > >> Looking for an 8-bit integer type...
50807 > >> *** WHOA THERE! ***
50809 > >> We suddenly couldn't compile using the C compiler we already tested!
50810 > >> The command line we used was:
50811 > >> conf-tmp/test.c -o conf-tmp/test
50812 > >> Please try to fix this; if you can't, mail achurch@achurch.org
50813 > >> with information about your system, the output from this script,
50814 > >> and the `configure.log' file generated by this script.
50816 > >> ________________________________________________________________
50817 > >> Matthew Hodgson arathorn@theonering.net Tel: +44 7968 722968
50818 > >> Arathorn: Co-Sysadmin, TheOneRing.net??
50820 > >> On Tue, 11 Nov 2003, Andrew Church wrote:
50822 > >> > Services 5.0.24 has been released, and can be downloaded from:
50824 > >> > ftp://ftp.esper.net/ircservices/ (USA, California)
50826 > >> > d8f808b04744e9db365ebb23f7d04078 ircservices-5.0.24.tar.gz
50827 > >> > e2415db90e2c9f3391268b8d48ef40d1 ircservices-5.0.24.diff.gz
50828 > >> > 07d0785f095de88f87de8b4d97024558 ircservices-5.0.24-1.i386.rpm
50829 > >> > 0235352278f534a818699281fcc7ba83 ircservices_5.0.24-1_i386.deb
50831 > >> > ftp.ircservices.za.net and the other mirrors should have it shortly.
50833 > >> > This release includes a workaround for those who were unable to
50834 > >> > compile 5.0.23; however, please note that being unable to compile means
50835 > >> > that your compiler is outdated, and you should upgrade it (or have the
50836 > >> > server administrator upgrade it) as soon as possible. Support for such
50837 > >> > compilers will be removed entirely in a future version.
50839 > >> > Changes in version 5.0.24
50840 > >> > -------------------------
50841 > >> > 2003/11/11 Fixed a warning in convert-db compilation.
50842 > >> > 2003/11/11 Fixed bugs in convert-db causing some nickname and channel
50843 > >> > settings (timezone, language, channel and memo limits)
50844 > >> > to not be initialized properly.
50845 > >> > 2003/11/11 Added -tzfile, -no-timezones, and -reset-memo-limits
50846 > >> > options to the Cygnus database converter in convert-db.
50847 > >> > 2003/11/05 Databases can now be exported in XML from the command line
50848 > >> > (-export option).
50849 > >> > 2003/11/05 GCC versions earlier than 3.2 (except 2.95.3) are now
50850 > >> > deprecated. Variadic macros workaround added for
50851 > >> > problem reported by Ali Sor <alisor@softhome.net>
50852 > >> > 2003/11/05 Channel last-used time is now updated properly for the
50853 > >> > first user to enter the channel if the user has auto-op
50854 > >> > privileges. Reported by <saman@alkol.org>
50856 > >> > --Andrew Church
50857 > >> > achurch@achurch.org
50858 > >> > http://achurch.org/
50859 > >> > ------------------------------------------------------------------
50860 > >> > To unsubscribe or change your subscription options, visit:
50861 > >> > http://www.ircservices.za.net/mailman/listinfo/ircservices
50867 From Craig at chatspike.net Sat Nov 15 12:26:22 2003
50868 From: Craig at chatspike.net (Craig McLure)
50869 Date: Sat Oct 23 23:10:11 2004
50870 Subject: [IRCServices Coding] Database API?
50871 Message-ID: <E1AL6zu-000HlY-00@ptb-mailc05.plus.net>
50873 Recently, I have been making modules for services, for use with our network (including HostServ, IdleServ, an 'improved' Statserv and loveserv), However, with each we have been forced to make our own databases, and was wondering if you plan on adding a proper Database API at some point, which could be used with all 3rd Pary modules? it seems the current one is heavily pointed towards the use of the 'main' services.
50875 I know you planned on restructuring the databases for version 5, however, as i recall, this didnt get started. Maybe what i'm suggesting was concidered before and dropped.. Anyway, some info on this would be appreciated. Thanks :)
50880 From ballsy at mystical.net Mon Nov 17 13:52:17 2003
50881 From: ballsy at mystical.net (Ballsy)
50882 Date: Sat Oct 23 23:10:12 2004
50883 Subject: [IRCServices Coding] EOF in backquote substitution error during
50885 Message-ID: <6.0.0.22.0.20031117144131.0481a8c0@127.0.0.1>
50887 Was Arathorn the only one to run across the backquote substitution error
50888 when configuring 5.0.24 ? I just patched from 5.0.22 to 5.0.24 and am
50889 getting the following during ./configure:
50891 Checking sanity of /bin/sh... high.
50892 Searching for a suitable compiler... ./configure: 29: Syntax error: EOF in
50893 backquote substitution
50895 I'm not familiar enough with 'patch' to know if it supports 'rollbacks' to
50896 previous versions (didn't see anyting in the man page), and 5.0.22's .tgz
50897 isn't on the ftp sites. Ideas ? (other than patching from 5.0.0 --> 5.0.24)
50898 As I didn't configure/make/make install after going from 5.0.22 -> 5.0.23,
50899 I'm not sure which patch was responsible (ie. I did both patches, then ran
50900 configure after a gmake clean).
50909 From arathorn at theonering.net Tue Nov 18 03:54:17 2003
50910 From: arathorn at theonering.net (Arathorn)
50911 Date: Sat Oct 23 23:10:12 2004
50912 Subject: [IRCServices Coding] Re: EOF in backquote substitution error during
50914 Message-ID: <Pine.LNX.4.56L0.0311181144590.6789@phoenix.siarch.net>
50918 Andrew confirmed that there are some bugs in ./configure which only
50919 surface if you're using a deprecated compiler. The IRC Services Coding
50920 list seems to have swallowed the remainder of the mails on the subject -
50921 i'm forwarding the most relevant one again. 5.0.24 has this problem, no
50922 matter how you came to it (either by patching from whatever version or
50923 by expanding the neat tarball).
50925 The below patch fixes the problem for me, but it's completely unsupported
50926 of course - to apply it, copy the text starting at the line that begins
50927 'diff -ur' through to just above my .sig - and paste it into a text file
50928 (making sure the lines don't wrap or anything). Save the file as
50929 ircservices-5.0.24-gccfix.patch or similar, and then apply to your 5.0.24
50930 source tree with a:
50932 cd /usr/local/src/ircservices-5.0.24 (or wherever it lives)
50933 patch -p1 < ~/ircservices-5.0.24-gccfix.patch (or wherever the patch is)
50935 and then you should be able to configure; make; make install correctly.
50936 Or alternatively wait until the official fix in the next version :)
50940 ________________________________________________________________
50941 Matthew Hodgson arathorn@theonering.net Tel: +44 7968 722968
50942 Arathorn: Co-Sysadmin, TheOneRing.net?
50944 ---------- Forwarded message ----------
50945 Date: Sat, 15 Nov 2003 02:05:19 +0000 (GMT)
50946 From: Arathorn <arathorn@theonering.net>
50947 To: Andrew Church <achurch@achurch.org>
50948 Cc: arathorn@theonering.net, ircservices-coding@ircservices.za.net
50949 Subject: Re: [PATCH] Fix of rogue unescaped backtick in configure in 5.0.24
50951 Hmm, turns out that I was a little premature in sending in that one-line
50952 patch - unless I'm completely missing something, the configure script
50953 doesn't actually end up setting the CC or DEF_CC_FLAGS variables after
50954 warning about deprecation. Not sure whether this is because the
50955 deprecation is being enforced more strongly than the warnings suggest, but
50956 I expanded the tweak to the following in order to get it to build
50957 sensibly. For what it's worth, gcc 2.95.4 has never presented any
50958 problems for me with ircservices (since 4.3.3 or so) - so perhaps it might
50959 also be considerable as 'officially supported' in addition to 2.95.3 and
50960 >3.2? Debian stable has a fairly decent reputation, after all.
50962 diff -ur ircservices-5.0.24/configure ircservices-5.0.24-fixed/configure
50963 --- ircservices-5.0.24/configure Wed Nov 5 01:46:59 2003
50964 +++ ircservices-5.0.24-fixed/configure Fri Nov 14 21:01:23 2003
50965 @@ -875,7 +875,7 @@
50966 elif test $vmajor -lt 3 -a $version != 2.95.3 || test $vmajor = 3 -a $vminor -lt 2 ; then
50969 -WARNING: Your version of GCC was detected as `$version'. As of Services
50970 +WARNING: Your version of GCC was detected as \`$version'. As of Services
50971 5.0.23, versions of GCC earlier than 3.2, other than 2.95.3,
50972 have been deprecated. This and future releases of Services 5.0
50973 will still work, though some error messages will lose
50974 @@ -885,6 +885,9 @@
50976 echo2 "Press Enter to continue: "
50979 + DEF_CC_FLAGS=`def_cc_flags $CC`
50980 + log using \`gcc\'
50982 else # version okay
50983 echo "great, found gcc!"
50986 ________________________________________________________________
50987 Matthew Hodgson arathorn@theonering.net Tel: +44 7968 722968
50988 Arathorn: Co-Sysadmin, TheOneRing.net?
50990 On Sat, 15 Nov 2003, Andrew Church wrote:
50992 > Thanks, fixed. Silly little details...
50994 > (For the record, I use a homebrew mail reader which can't handle
50995 > attachments. If I do get attachments I can decode them with pine, but I
50996 > prefer patches inline so I can look at them without having to do so.)
50999 > achurch@achurch.org
51000 > http://achurch.org/
51002 > >Well, I just had another chance to look more carefully at the configure
51003 > >script - looks like there's a rogue unescaped backtick in the deprecation
51004 > >warning text block:
51007 > >diff -ur ircservices-5.0.24-orig/configure ircservices-5.0.24/configure
51008 > >--- ircservices-5.0.24-orig/configure Wed Nov 5 01:46:59 2003
51009 > >+++ ircservices-5.0.24/configure Fri Nov 14 17:04:08 2003
51010 > >@@ -875,7 +875,7 @@
51011 > > elif test $vmajor -lt 3 -a $version != 2.95.3 || test $vmajor = 3 -a $vminor -lt 2 ; then
51014 > >-WARNING: Your version of GCC was detected as `$version'. As of Services
51015 > >+WARNING: Your version of GCC was detected as \`$version'. As of Services
51016 > > 5.0.23, versions of GCC earlier than 3.2, other than 2.95.3,
51017 > > have been deprecated. This and future releases of Services 5.0
51018 > > will still work, though some error messages will lose
51022 > >(due to pine insisting on base64'ing mime attachments, i haven't attached
51023 > >the file as Andrew's mail system doesn't seem to approve of base64. -
51024 > >apologies if this mail shows up twice for anyone.)
51026 > >________________________________________________________________
51027 > >Matthew Hodgson arathorn@theonering.net Tel: +44 7968 722968
51028 > > Arathorn: Co-Sysadmin, TheOneRing.net??
51030 > >On Wed, 12 Nov 2003, Arathorn wrote:
51034 > >> Just tried to upgrade to 5.0.24 on my Debian Woody production server
51035 > >> running gcc 2.95.4. I appreciate that this is <3.2 and !=2.95.3, but I
51036 > >> didn't expect ./configure to completely keel over on me (and hoped to be
51037 > >> able to use a -force configure option of some kind to get it to compile
51040 > >> Here's the stderr & stdio - the configure.log is attached:
51042 > >> pe1650 18# gcc -v
51043 > >> Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
51044 > >> gcc version 2.95.4 20011002 (Debian prerelease)
51045 > >> pe1650 19# ./configure -ignore-cache
51047 > >> Beginning IRC Services configuration.
51049 > >> In what directory do you want the binaries to be installed?
51050 > >> Press Return for the default, or enter a new value.
51051 > >> [/usr/local/sbin] /usr/local/sbin/ircservices-5.0.24-unr
51053 > >> Where do you want the data files to be installed?
51054 > >> [/usr/local/sbin/ircservices-5.0.24-unr/lib] /usr/local/lib/ircservices-5.0
51056 > >> End of interactive configuration.
51058 > >> Checking sanity of /bin/sh... high.
51059 > >> Searching for a suitable compiler... ./configure: command substitution:
51060 > >> line 1: unexpected EOF while looking for matching `''
51061 > >> ./configure: command substitution: line 8: syntax error: unexpected end of file
51063 > >> WARNING: Your version of GCC was detected as Press Enter to continue:
51067 > >> Testing default compiler flags ()... no luck! Using no flags.
51068 > >> If you know what flags you want, use the -cflags option to configure.
51069 > >> Let's see what libraries we need...
51070 > >> Checking if we can use dynamic modules... no.
51071 > >> Checking whether ranlib exists... yes.
51072 > >> Looking for an 8-bit integer type...
51073 > >> *** WHOA THERE! ***
51075 > >> We suddenly couldn't compile using the C compiler we already tested!
51076 > >> The command line we used was:
51077 > >> conf-tmp/test.c -o conf-tmp/test
51078 > >> Please try to fix this; if you can't, mail achurch@achurch.org
51079 > >> with information about your system, the output from this script,
51080 > >> and the `configure.log' file generated by this script.
51082 > >> ________________________________________________________________
51083 > >> Matthew Hodgson arathorn@theonering.net Tel: +44 7968 722968
51084 > >> Arathorn: Co-Sysadmin, TheOneRing.net??
51086 > >> On Tue, 11 Nov 2003, Andrew Church wrote:
51088 > >> > Services 5.0.24 has been released, and can be downloaded from:
51090 > >> > ftp://ftp.esper.net/ircservices/ (USA, California)
51092 > >> > d8f808b04744e9db365ebb23f7d04078 ircservices-5.0.24.tar.gz
51093 > >> > e2415db90e2c9f3391268b8d48ef40d1 ircservices-5.0.24.diff.gz
51094 > >> > 07d0785f095de88f87de8b4d97024558 ircservices-5.0.24-1.i386.rpm
51095 > >> > 0235352278f534a818699281fcc7ba83 ircservices_5.0.24-1_i386.deb
51097 > >> > ftp.ircservices.za.net and the other mirrors should have it shortly.
51099 > >> > This release includes a workaround for those who were unable to
51100 > >> > compile 5.0.23; however, please note that being unable to compile means
51101 > >> > that your compiler is outdated, and you should upgrade it (or have the
51102 > >> > server administrator upgrade it) as soon as possible. Support for such
51103 > >> > compilers will be removed entirely in a future version.
51105 > >> > Changes in version 5.0.24
51106 > >> > -------------------------
51107 > >> > 2003/11/11 Fixed a warning in convert-db compilation.
51108 > >> > 2003/11/11 Fixed bugs in convert-db causing some nickname and channel
51109 > >> > settings (timezone, language, channel and memo limits)
51110 > >> > to not be initialized properly.
51111 > >> > 2003/11/11 Added -tzfile, -no-timezones, and -reset-memo-limits
51112 > >> > options to the Cygnus database converter in convert-db.
51113 > >> > 2003/11/05 Databases can now be exported in XML from the command line
51114 > >> > (-export option).
51115 > >> > 2003/11/05 GCC versions earlier than 3.2 (except 2.95.3) are now
51116 > >> > deprecated. Variadic macros workaround added for
51117 > >> > problem reported by Ali Sor <alisor@softhome.net>
51118 > >> > 2003/11/05 Channel last-used time is now updated properly for the
51119 > >> > first user to enter the channel if the user has auto-op
51120 > >> > privileges. Reported by <saman@alkol.org>
51122 > >> > --Andrew Church
51123 > >> > achurch@achurch.org
51124 > >> > http://achurch.org/
51125 > >> > ------------------------------------------------------------------
51126 > >> > To unsubscribe or change your subscription options, visit:
51127 > >> > http://www.ircservices.za.net/mailman/listinfo/ircservices
51133 From ballsy at mystical.net Wed Nov 19 12:24:53 2003
51134 From: ballsy at mystical.net (Ballsy)
51135 Date: Sat Oct 23 23:10:12 2004
51136 Subject: [IRCServices Coding] REHASH functionality question
51137 Message-ID: <6.0.0.22.0.20031119130825.01e963d8@127.0.0.1>
51139 Perhaps I don't have a complete understanding of its functionality, so
51140 correct me if I'm wrong.
51146 I recently upgraded from 5.0.22 to 5.0.25 (using patches) but after
51147 starting services again (successfully), I realized I hadn't put the new
51148 AkillChanExpiry directive into modules.conf. When I issued a 'msg operserv
51149 help Akillchan', the help message indicated that if no expiry was
51150 specified, it would default to "(null)". I then added the AkillChanExpiry
51151 to modules.conf (set to 7d) and issued a REHASH via OperServ. The HELP
51152 message for Akillchan still indicates an expiry of "(null)", though I
51153 expected it to say 7d. I found the following in the log, which didn't
51154 really provide an answer...
51156 [Nov 19 14:52:07 2003] operserv/main: Ballsy: help akillchan
51157 [Nov 19 14:57:44 2003] operserv/main: Ballsy: rehash
51158 [Nov 19 14:57:44 2003] ircservices.conf:295: Deprecated directive
51161 [Nov 19 14:57:44 2003] conffile: do_all_directives BUG: don't know how to copy
51162 type -2 (ExpireTimeout/0)
51163 [Nov 19 14:57:50 2003] operserv/main: Ballsy: help akillchan
51165 I have since removed the ExpireTimeout, as it has been deprecated since
51166 around 5.0.19 or so.
51167 I imagined that modules.conf is reloaded during a REHASH as well, so was
51168 wondering why the HELP hadn't been updated. Obviously a pretty small deal,
51169 but was wondering nonetheless.
51175 From freakycomputer at global.co.za Sat Nov 22 01:04:58 2003
51176 From: freakycomputer at global.co.za (FreakyComputer)
51177 Date: Sat Oct 23 23:10:12 2004
51178 Subject: [IRCServices Coding] Converting DB from Magick
51179 Message-ID: <000d01c3b0d7$ba5648e0$0100a8c0@blauwhome>
51183 I know this was discussed several years ago, but I couldn't get in touch
51184 with the people who posted then, so I'm going to try and ask this again.
51186 Our network is running Magick-1.4 and, quite frankly, we're getting tired of
51187 it and the "big bosses" FINALLY decided that we can upgrade our services to
51188 something less Jurassic! But, we've got a problem while trying to convert
51189 our databases, it doesn't even go past the nick.db. It just says: 'loading
51190 nick.db' and that's it. I discovered it's stuck in an endless loop just
51191 before "ni = makenick(oldni.nick, &ngi);" after the 3rd nick is gets. (I got
51192 this by adding some fprintf's in and around the code to see where it gets
51195 If someone knows of this problem and also know how to fix it, please reply,
51196 since NOW our "big bosses" are getting restless to upgrade (sometimes one
51197 just doesn't understand them :-/)
51203 From saman at alkol.org Sat Nov 22 01:39:12 2003
51204 From: saman at alkol.org (|SaMaN|)
51205 Date: Sat Oct 23 23:10:12 2004
51206 Subject: [IRCServices Coding] Set topic before chanserv deops you on a
51208 References: <000d01c3b0d7$ba5648e0$0100a8c0@blauwhome>
51209 Message-ID: <001101c3b0dc$7cc22da0$a37faec3@coder>
51213 If the channel is registered, topiclock is off and is empty when you do
51214 /timer 1 0 hop #channel | /topic #channel <message>, it lets you to set
51215 topic before chanserv deops you. This seems like a problem to me. Any
51222 . [total users 1] [ops 1(100%)] [halfops 0(0%)] [voice 0(0%)] [regular
51224 [11:28am] (..topic..) ChanServ changes topic to "Death is N/A (Zombie)"
51225 [11:28am] (..notice..) ChanServ: Bu kanal ChanServ ile kaydedilmistir.
51226 [11:28am] (..mode..) ChanServ changes mode(s) to +ntrRVCf-o 3:4 |SaMaN|
51227 [11:28am] (..deop..) ChanServ deops |SaMaN| in #geyik
51228 . mode(s) +ntrRVCf 3:4
51229 . channel born Sat Nov 22 12:27:22 2003
51232 -------------------
51233 I did /timer 1 0 hop #geyik | /topic #geyik geyik
51234 -------------------
51235 * Timer 1 activated
51236 [11:32am] * Attempting to rejoin channel #geyik
51239 . [total users 1] [ops 1(100%)] [halfops 0(0%)] [voice 0(0%)] [regular
51241 [11:32am] (..topic..) |SaMaN| changes topic to "geyik"
51242 [11:32am] (..notice..) ChanServ: Bu kanal ChanServ ile kaydedilmistir.
51243 [11:32am] (..mode..) ChanServ changes mode(s) to +ntrRVCf-o 3:4 |SaMaN|
51244 [11:32am] (..deop..) ChanServ deops |SaMaN| in #geyik
51245 . mode(s) +ntrRVCf 3:4
51246 . last join 11:32:39am Saturday Nov 22 2003 joined 2 times
51247 . channel born Sat Nov 22 12:31:44 2003
51250 -------------------
51253 From achurch at achurch.org Mon Nov 24 17:41:28 2003
51254 From: achurch at achurch.org (Andrew Church)
51255 Date: Sat Oct 23 23:10:12 2004
51256 Subject: [IRCServices Coding] Set topic before chanserv deops you on a
51258 In-Reply-To: <001101c3b0dc$7cc22da0$a37faec3@coder>
51259 Message-ID: <3fc1c44f.13432@achurch.org>
51261 This is an artifact of the way IRC works. If this is a problem, turn
51265 achurch@achurch.org
51266 http://achurch.org/
51270 >If the channel is registered, topiclock is off and is empty when you do
51271 >/timer 1 0 hop #channel | /topic #channel <message>, it lets you to set
51272 >topic before chanserv deops you. This seems like a problem to me. Any
51279 > . [total users 1] [ops 1(100%)] [halfops 0(0%)] [voice 0(0%)] [regular
51281 >[11:28am] (..topic..) ChanServ changes topic to "Death is N/A (Zombie)"
51282 >[11:28am] (..notice..) ChanServ: Bu kanal ChanServ ile kaydedilmistir.
51283 >[11:28am] (..mode..) ChanServ changes mode(s) to +ntrRVCf-o 3:4 |SaMaN|
51284 >[11:28am] (..deop..) ChanServ deops |SaMaN| in #geyik
51285 > . mode(s) +ntrRVCf 3:4
51286 > . channel born Sat Nov 22 12:27:22 2003
51287 > . synched in 1sec
51289 >-------------------
51290 >I did /timer 1 0 hop #geyik | /topic #geyik geyik
51291 >-------------------
51292 >* Timer 1 activated
51293 >[11:32am] * Attempting to rejoin channel #geyik
51296 > . [total users 1] [ops 1(100%)] [halfops 0(0%)] [voice 0(0%)] [regular
51298 >[11:32am] (..topic..) |SaMaN| changes topic to "geyik"
51299 >[11:32am] (..notice..) ChanServ: Bu kanal ChanServ ile kaydedilmistir.
51300 >[11:32am] (..mode..) ChanServ changes mode(s) to +ntrRVCf-o 3:4 |SaMaN|
51301 >[11:32am] (..deop..) ChanServ deops |SaMaN| in #geyik
51302 > . mode(s) +ntrRVCf 3:4
51303 > . last join 11:32:39am Saturday Nov 22 2003 joined 2 times
51304 > . channel born Sat Nov 22 12:31:44 2003
51305 > . synched in 1sec
51307 >-------------------
51309 >------------------------------------------------------------------
51310 >To unsubscribe or change your subscription options, visit:
51311 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
51313 From achurch at achurch.org Tue Nov 18 12:32:39 2003
51314 From: achurch at achurch.org (Andrew Church)
51315 Date: Sat Oct 23 23:10:12 2004
51316 Subject: [IRCServices Coding] EOF in backquote substitution error during
51318 In-Reply-To: <6.0.0.22.0.20031117144131.0481a8c0@127.0.0.1>
51319 Message-ID: <200311250831.hAP8VaMi012034@ariadni.forthnet.gr>
51322 Message-ID: <3fb9930b.03510@achurch.org>
51324 (private CC because the mailing list seems to be broken)
51326 I'll be releasing 5.0.25 soon with a fix for the backquote problem.
51327 In the meantime, use patch -R (reverse) to go back to an earlier version.
51330 achurch@achurch.org
51331 http://achurch.org/
51333 > Was Arathorn the only one to run across the backquote substitution error
51334 >when configuring 5.0.24 ? I just patched from 5.0.22 to 5.0.24 and am
51335 >getting the following during ./configure:
51337 >Checking sanity of /bin/sh... high.
51338 >Searching for a suitable compiler... ./configure: 29: Syntax error: EOF in
51339 >backquote substitution
51341 > I'm not familiar enough with 'patch' to know if it supports 'rollbacks' to
51342 >previous versions (didn't see anyting in the man page), and 5.0.22's .tgz
51343 >isn't on the ftp sites. Ideas ? (other than patching from 5.0.0 --> 5.0.24)
51344 > As I didn't configure/make/make install after going from 5.0.22 -> 5.0.23,
51345 >I'm not sure which patch was responsible (ie. I did both patches, then ran
51346 >configure after a gmake clean).
51349 >FreeBSD 4.9-STABLE
51354 >------------------------------------------------------------------
51355 >To unsubscribe or change your subscription options, visit:
51356 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
51358 From achurch at achurch.org Mon Nov 17 11:21:50 2003
51359 From: achurch at achurch.org (Andrew Church)
51360 Date: Sat Oct 23 23:10:12 2004
51361 Subject: [IRCServices Coding] Database API?
51362 In-Reply-To: <E1AL6zu-000HlY-00@ptb-mailc05.plus.net>
51363 Message-ID: <200311250831.hAP8VdMi012035@ariadni.forthnet.gr>
51366 Message-ID: <3fb8311e.60353@achurch.org>
51368 As the manual says, the details of database modules are still in flux,
51369 and are very likely to change for 5.1, so I've deliberately not documented
51370 them. You're welcome to read the source for details, but be prepared to
51371 make changes later on if you start implementing now.
51374 achurch@achurch.org
51375 http://achurch.org/
51377 >Recently, I have been making modules for services, for use with our network (including HostServ, IdleServ, an 'improved' Statserv and loveserv), However, with each we have been forced to make our own databases, and was wondering if you plan on adding a pr
51378 >oper Database API at some point, which could be used with all 3rd Pary modules? it seems the current one is heavily pointed towards the use of the 'main' services.
51380 >I know you planned on restructuring the databases for version 5, however, as i recall, this didnt get started. Maybe what i'm suggesting was concidered before and dropped.. Anyway, some info on this would be appreciated. Thanks :)
51384 >------------------------------------------------------------------
51385 >To unsubscribe or change your subscription options, visit:
51387 From achurch at achurch.org Thu Nov 20 22:07:39 2003
51388 From: achurch at achurch.org (Andrew Church)
51389 Date: Sat Oct 23 23:10:12 2004
51390 Subject: [IRCServices Coding] REHASH functionality question
51391 In-Reply-To: <6.0.0.22.0.20031119130825.01e963d8@127.0.0.1>
51392 Message-ID: <200311250831.hAP8VkMi012048@ariadni.forthnet.gr>
51395 Message-ID: <3fbcbd0d.72522@achurch.org>
51397 (CC'd privately because my mail doesn't seem to be going through to the
51400 > I recently upgraded from 5.0.22 to 5.0.25 (using patches) but after
51401 >starting services again (successfully), I realized I hadn't put the new
51402 >AkillChanExpiry directive into modules.conf. When I issued a 'msg operserv
51403 >help Akillchan', the help message indicated that if no expiry was
51404 >specified, it would default to "(null)". I then added the AkillChanExpiry
51405 >to modules.conf (set to 7d) and issued a REHASH via OperServ. The HELP
51406 >message for Akillchan still indicates an expiry of "(null)", though I
51407 >expected it to say 7d.
51409 That's a bug, not a feature! ...oh, wait...
51411 Fixed for 5.0.26, thanks for the report.
51414 achurch@achurch.org
51415 http://achurch.org/
51417 From phant0m at myrealbox.com Tue Nov 25 03:07:06 2003
51418 From: phant0m at myrealbox.com (Anton Volkov)
51419 Date: Sat Oct 23 23:10:12 2004
51420 Subject: [IRCServices Coding] improvment in unreal protocol
51421 Message-ID: <20031125110733.F41B2170E7@snow.fingers.co.za>
51425 I would like to recommend a change in /modules/protocol/unreal.c
51427 module_log("m_sethost: user record for %s not found", source);
51429 This line generates useless log lines and since this situations is handled well I recommend it?s removal.
51431 This is tested and services run more then fine without it.
51433 -------------- next part --------------
51434 An HTML attachment was scrubbed...
51435 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20031125/654f320d/attachment.html
51436 From achurch at achurch.org Tue Nov 25 20:23:49 2003
51437 From: achurch at achurch.org (Andrew Church)
51438 Date: Sat Oct 23 23:10:13 2004
51439 Subject: [IRCServices Coding] improvment in unreal protocol
51440 In-Reply-To: <20031125110733.F41B2170E7@snow.fingers.co.za>
51441 Message-ID: <3fc33bde.60621@achurch.org>
51443 This is a bug in Unreal, and I'm not going to work around it. And
51444 don't send HTML mail.
51447 achurch@achurch.org
51448 http://achurch.org/
51450 >This is a multi-part message in MIME format.
51452 >--===============1880783837==
51453 >Content-Type: multipart/alternative;
51454 > boundary="----=_NextPart_000_0016_01C3B355.0FC92B60"
51456 >This is a multi-part message in MIME format.
51458 >------=_NextPart_000_0016_01C3B355.0FC92B60
51459 >Content-Type: text/plain;
51461 >Content-Transfer-Encoding: quoted-printable
51465 >I would like to recommend a change in /modules/protocol/unreal.c
51467 >module_log("m_sethost: user record for %s not found", source);
51469 >This line generates useless log lines and since this situations is =
51470 >handled well I recommend it=E2=80=99s removal.
51472 >This is tested and services run more then fine without it.
51475 >------=_NextPart_000_0016_01C3B355.0FC92B60
51476 >Content-Type: text/html;
51478 >Content-Transfer-Encoding: quoted-printable
51480 ><html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
51481 >xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
51482 >xmlns=3D"http://www.w3.org/TR/REC-html40">
51485 ><meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8">
51486 ><meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
51489 > /* Font Definitions */
51491 > {font-family:"Cordia New";
51492 > panose-1:2 11 3 4 2 2 2 2 2 4;}
51493 > /* Style Definitions */
51494 > p.MsoNormal, li.MsoNormal, div.MsoNormal
51496 > margin-bottom:.0001pt;
51497 > font-size:12.0pt;
51498 > font-family:"Times New Roman";}
51499 >a:link, span.MsoHyperlink
51501 > text-decoration:underline;}
51502 >a:visited, span.MsoHyperlinkFollowed
51504 > text-decoration:underline;}
51506 > {mso-style-type:personal-compose;
51507 > font-family:Arial;
51508 > color:windowtext;}
51510 > {size:612.0pt 792.0pt;
51511 > margin:72.0pt 90.0pt 72.0pt 90.0pt;}
51519 ><body lang=3DEN-US link=3Dblue vlink=3Dpurple>
51521 ><div class=3DSection1>
51523 ><p class=3DMsoNormal><font size=3D2 face=3DArial><span =
51524 >style=3D'font-size:10.0pt;
51525 >font-family:Arial'>Hi,<o:p></o:p></span></font></p>
51527 ><p class=3DMsoNormal><font size=3D2 face=3DArial><span =
51528 >style=3D'font-size:10.0pt;
51529 >font-family:Arial'>I would like to recommend a change in =
51530 >/modules/protocol/unreal.c<o:p></o:p></span></font></p>
51532 ><p class=3DMsoNormal><font size=3D4 face=3D"Cordia New"><span =
51533 >style=3D'font-size:14.0pt;
51534 >font-family:"Cordia New"'>module_log("m_sethost: user record for %s =
51536 >found", source);<o:p></o:p></span></font></p>
51538 ><p class=3DMsoNormal><font size=3D2 face=3DArial><span =
51539 >style=3D'font-size:10.0pt;
51540 >font-family:Arial'>This line generates useless log lines and since this
51541 >situations is handled well I recommend it=E2=80=99s =
51542 >removal.<o:p></o:p></span></font></p>
51544 ><p class=3DMsoNormal><font size=3D2 face=3DArial><span =
51545 >style=3D'font-size:10.0pt;
51546 >font-family:Arial'>This is tested and services run more then fine =
51547 >without it.<o:p></o:p></span></font></p>
51555 >------=_NextPart_000_0016_01C3B355.0FC92B60--
51558 >--===============1880783837==
51559 >Content-Type: text/plain; charset="us-ascii"
51561 >Content-Transfer-Encoding: 7bit
51562 >Content-Disposition: inline
51564 >------------------------------------------------------------------
51565 >To unsubscribe or change your subscription options, visit:
51566 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
51568 >--===============1880783837==--
51571 From realcfc at chatfirst.com Tue Nov 25 18:27:00 2003
51572 From: realcfc at chatfirst.com (realcfc@chatfirst.com)
51573 Date: Sat Oct 23 23:10:13 2004
51574 Subject: [IRCServices Coding] Re: Re: Services translation request (short)
51575 Message-ID: <20031126022650.VXPG14203.imf25aec.mail.bellsouth.net@CHATFIRST>
51577 An HTML attachment was scrubbed...
51578 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20031125/73ad5493/attachment.htm
51579 -------------- next part --------------
51580 Thank you for contacting the ChatFIRST staff about your problem, someone will soon take care of your message and reply in the order in which it was received, sometimes we get a very high volume of help requests, then your e-mail might take a little bit more time for us to respond, but no need to worry, it will be.
51582 If you are just getting an error message about: Reconnecting too fast" please wait around 50 seconds to connect again to CF then try again, this is normal server self defense against flooders, You should be fine if you wait just 50 seconds before simultaneous attempts to connect.
51584 If you are getting an error message about: Nick Flooding or Join Flooding or even about Notice Flooding Please wait about 4 minutes then try to connect again to CF, This is normal server self defense against flood, Any bans caused by the anti-flood system usually don't last more than 5 minutes, be patient and try reconnecting after waiting for about 4 minutes.
51586 You can also check the ChatFIRST.COM homepage for answers to the most popular asked questions by users like you, Be sure to check the following sites:
51588 For info on and solutions to login problems visit:
51590 http://www.chatfirst.com/login.html
51592 For info on how to stop flooders and get rid of trouble makers:
51594 http://www.chatfirst.com/control.html
51596 For info regarding a ban that is preventing you from connecting to ChatFIRST.COM servers please visit:
51598 http://www.chatfirst.com/passport.html
51600 For help related to commands sent to NickServ, ChanServ, MemoServ etc:
51602 http://www.chatfirst.com/services.html
51604 For WebTV commands visit:
51605 http://www.chatfirst.com/services.html#TVcommands
51607 http://www.chatfirst.com/users/chatfirst/webtv/index.html
51609 Again, thank you for contacting us and we hope to be of help to you in the next couple of hours or minutes if possible.
51610 Please hang in there.
51615 PS: Please DO NOT reply to this message, this was an automatic reply, someone will soon respond to the message you sent to us earlier.
51616 From dooley at risanet.com Wed Nov 26 09:23:30 2003
51617 From: dooley at risanet.com (Dooley)
51618 Date: Sat Oct 23 23:10:13 2004
51619 Subject: [IRCServices Coding] Confused.....
51620 Message-ID: <000c01c3b442$0a1511a0$dd91a8c0@criley>
51622 Confusion is setting in and I am hoping to get clarification so I have a few questions.
51624 According to the webpage the latest version of services is 5.0.23 which is what I see on fftp.ircservices.za.net yet on ftp.esper.net the current version is 5.0.25. Which is the correct current version?
51626 When playing around with a new download of the 5.0.25 and running in conjunction with Bahamut I get the following on a operserv restart:
51628 [Nov 26 11:04:45.527125 2003] Services terminating: Segmentation fault
51629 ircservices in free(): error: junk pointer, too high to make sense
51630 [Nov 26 11:04:45.527688 2003] FATAL: Caught signal 6 (Abort trap) while shutting down
51632 This occurs right after the SQUIT is sent. I have tried versions bahamut-1.4.33-release.tar.gz through bahamut-1.4.35-release.tar.gz and get the same error and there is no core file to review...ideas?
51634 I then decided that I would walk through things one at a time downloaded a fresh 23 version then tried it again worked fine. Patched to version 24 and tried it and it too worked fine after fixing the configure script. I then proceeded to patch up to 25 and wham I ran into the error again. I didn't see anything in the Changes file that jumps out at me that could cause this problem and was wondering if there is something I am missing?
51645 Outgoing mail is certified Virus Free.
51646 Checked by AVG anti-virus system (http://www.grisoft.com).
51647 Version: 6.0.537 / Virus Database: 332 - Release Date: 11/6/2003
51648 From dooley at risanet.com Wed Nov 26 10:32:37 2003
51649 From: dooley at risanet.com (Dooley)
51650 Date: Sat Oct 23 23:10:13 2004
51651 Subject: [IRCServices Coding] Confused.....
51652 References: <000c01c3b442$0a1511a0$dd91a8c0@criley>
51653 Message-ID: <001e01c3b44b$afb2bfa0$dd91a8c0@criley>
51655 Went ahead and created a core file and did a backtrace on it here is the
51658 #0 0x00000000 in ?? ()
51659 #1 0x080559f4 in call_callback_5 (module=0x808c300, id=13, arg1=0x0,
51660 arg2=0x2815b018, arg3=0x8087370, arg4=0x11, arg5=0x8087000) at modules.c:698
51661 #2 0x08059cae in quit_user (user=0x808c300, quitmsg=0x805f39e
51662 "server_cleanup", is_kill=0) at users.c:163
51663 #3 0x08056955 in squit_server (server=0x8088d00, reason=0x805f39e
51664 "server_cleanup") at servers.c:77
51665 #4 0x080569c6 in recursive_squit (parent=0x8082780, reason=0x805f39e
51666 "server_cleanup") at servers.c:103
51667 #5 0x08056932 in squit_server (server=0x8088040, reason=0x805f39e
51668 "server_cleanup") at servers.c:72
51669 #6 0x08056c53 in server_cleanup () at servers.c:235
51670 #7 0x08051675 in cleanup () at init.c:1112
51671 #8 0x08052e76 in main (ac=3, av=0xbfbffaa8, envp=0xbfbffab8) at main.c:275
51672 #9 0x0804c335 in _start ()
51682 Outgoing mail is certified Virus Free.
51683 Checked by AVG anti-virus system (http://www.grisoft.com).
51684 Version: 6.0.537 / Virus Database: 332 - Release Date: 11/6/2003
51687 From ballsy at mystical.net Fri Nov 28 12:40:12 2003
51688 From: ballsy at mystical.net (Ballsy)
51689 Date: Sat Oct 23 23:10:13 2004
51690 Subject: [IRCServices Coding] unparsed server messages
51691 Message-ID: <6.0.0.22.0.20031128133440.01b3ee38@127.0.0.1>
51696 A very minor thing I noticed in my logs is that IRCServices don't seem to
51697 recognize global Zlines when synching network data. Several messages
51698 resembling this end up in the log...
51700 [Nov 28 15:25:15 2003] unknown message from server (:myserver.name SZLINE
51701 www.xxx.yyy.zzz :IP address is banned (Z-lined): Fizzer Trojan Infected)
51703 Incredibly minor issue, unless you have a ton of global Zlines I
51704 suppose. It was just quiet on the -coding list today, so I figured what
51705 the hell. I haven't looked at the code, but perhaps there's a list of
51706 "don't parse these messages" that the SZLINE one could be added to.
51712 From junkmail at cyberchatnet.com Fri Nov 28 04:46:47 2003
51713 From: junkmail at cyberchatnet.com (Phil)
51714 Date: Sat Oct 23 23:10:13 2004
51715 Subject: [IRCServices Coding] Using your current version of services with
51717 Message-ID: <00bf01c3b5ad$b0a15a80$0500a8c0@cyberchatnet.com>
51719 I am using the current version of Unreal3.2 Beta 18 and when I use /msg operserv akill add +30m *@ipaddress is not killing the user off the ircd. I have to issue a /kill nick then it works. Do know how I can fix this please?
51723 -------------- next part --------------
51724 An HTML attachment was scrubbed...
51725 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20031128/d03d340d/attachment.html
51726 From dylanvdm at icon.co.za Sat Nov 29 02:04:58 2003
51727 From: dylanvdm at icon.co.za (Dylan v.d Merwe)
51728 Date: Sat Oct 23 23:10:13 2004
51729 Subject: [IRCServices Coding] Using your current version of services
51731 References: <00bf01c3b5ad$b0a15a80$0500a8c0@cyberchatnet.com>
51732 Message-ID: <001c01c3b660$44e6adf0$f4a6ef9b@dylan>
51734 # ImmediatelySendAutokill [OPTIONAL]
51735 # Causes OperServ to inform all servers of a new autokill or
51736 # autokill exclusion the moment it is added, rather than waiting
51737 # for someone to match it first.
51739 ImmediatelySendAutokill
51743 ----- Original Message -----
51745 To: ircservices-coding@ircservices.za.net
51746 Sent: Friday, November 28, 2003 2:46 PM
51747 Subject: [IRCServices Coding] Using your current version of services withUnreal
51750 I am using the current version of Unreal3.2 Beta 18 and when I use /msg operserv akill add +30m *@ipaddress is not killing the user off the ircd. I have to issue a /kill nick then it works. Do know how I can fix this please?
51756 ------------------------------------------------------------------------------
51759 ------------------------------------------------------------------
51760 To unsubscribe or change your subscription options, visit:
51761 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
51763 -------------- next part --------------
51764 An HTML attachment was scrubbed...
51765 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20031129/62946040/attachment.htm
51766 From achurch at achurch.org Mon Dec 1 13:29:30 2003
51767 From: achurch at achurch.org (Andrew Church)
51768 Date: Sat Oct 23 23:10:13 2004
51769 Subject: [IRCServices Coding] unparsed server messages
51770 In-Reply-To: <6.0.0.22.0.20031128133440.01b3ee38@127.0.0.1>
51771 Message-ID: <3fcac3b9.01744@achurch.org>
51773 > A very minor thing I noticed in my logs is that IRCServices don't seem to
51774 >recognize global Zlines when synching network data. Several messages
51775 >resembling this end up in the log...
51777 >[Nov 28 15:25:15 2003] unknown message from server (:myserver.name SZLINE
51778 >www.xxx.yyy.zzz :IP address is banned (Z-lined): Fizzer Trojan Infected)
51780 Fixed, thanks for the report.
51783 achurch@achurch.org
51784 http://achurch.org/
51786 From phant0m at myrealbox.com Mon Dec 8 03:54:09 2003
51787 From: phant0m at myrealbox.com (Anton Volkov)
51788 Date: Sat Oct 23 23:10:13 2004
51789 Subject: [IRCServices Coding] sjoin unreal hack
51790 Message-ID: <20031208115458.87E7917033@snow.fingers.co.za>
51792 As I understand to set the timestamp of a chanserv registered channel unreal needs a mode too,
51794 If I understood right this is done by doing ?o and +o to the joining user which might be a bit annoying,
51796 Is it possible to let?s say set +r to the channel instead?
51798 -------------- next part --------------
51799 An HTML attachment was scrubbed...
51800 URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20031208/ee0cc448/attachment.html
51801 From freakycomputer at global.co.za Mon Dec 8 04:03:07 2003
51802 From: freakycomputer at global.co.za (FreakyComputer)
51803 Date: Sat Oct 23 23:10:13 2004
51804 Subject: [IRCServices Coding] HostServ Module
51805 Message-ID: <000001c3bdb9$c276c970$0100a8c0@blauwhome>
51809 After a long search, I found that there isn't any obvious HostServ modules
51810 available for IRCServices. So I was wondering if anyone here might know of
51811 such a module or maybe if it's planned for any future versions of
51814 This HostServ module doesn't have to be complicated. Just the basic Add,
51815 remove, list and login commands.
51821 From Craig at chatspike.net Mon Dec 8 13:00:51 2003
51822 From: Craig at chatspike.net (Craig McLure)
51823 Date: Sat Oct 23 23:10:13 2004
51824 Subject: [IRCServices Coding] HostServ Module
51825 Message-ID: <E1ATSUa-000196-TP@ptb-relay01.plus.net>
51827 as far as i know, there is no official module, only a 3rd party one (strangly enough, made by me..) although we kinda concider it unique to our network atm.. i'll speak to my other opers about releasing it at some point. it has add and delete, although no list command, we cant be bothered to code on, unless someone can make a simple function that open files in the filesystem names with ngids, read the contents, attach the contents to a nickname, and display Nick -> Vhost :p
51829 /****************************************
51830 * Craig "FrostyCoolSlug" McLure
51831 * InspIRCd - http://www.inspircd.org
51832 * ChatSpike - http://www.chatspike.net
51833 ****************************************/
51836 /****************************************
51837 * From - FreakyComputer <freakycomputer@global.co.za>
51838 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
51839 * Sent - 2003-12-08 14:03:00
51840 * Subject - [IRCServices Coding] HostServ Module
51841 ****************************************/
51843 /****** - Begin Original Message - ******/
51847 >After a long search, I found that there isn't any obvious HostServ modules
51848 >available for IRCServices. So I was wondering if anyone here might know of
51849 >such a module or maybe if it's planned for any future versions of
51852 >This HostServ module doesn't have to be complicated. Just the basic Add,
51853 >remove, list and login commands.
51858 >------------------------------------------------------------------
51859 >To unsubscribe or change your subscription options, visit:
51860 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
51863 /******* - End Original Message - *******/
51868 From ganja51 at lcirc.net Mon Dec 8 13:21:15 2003
51869 From: ganja51 at lcirc.net (Ganja51)
51870 Date: Sat Oct 23 23:10:13 2004
51871 Subject: [IRCServices Coding] HostServ Module
51872 References: <000001c3bdb9$c276c970$0100a8c0@blauwhome>
51873 Message-ID: <002601c3bdd1$3709ceb0$1402a8c0@monte>
51875 You may possibly want to look at NeoStats's HostServ module. Running
51876 NeoStats would require an additional bg process though.
51879 ----- Original Message -----
51880 From: "FreakyComputer" <freakycomputer@global.co.za>
51881 To: <ircservices-coding@ircservices.za.net>
51882 Sent: Monday, December 08, 2003 6:03 AM
51883 Subject: [IRCServices Coding] HostServ Module
51888 > After a long search, I found that there isn't any obvious HostServ modules
51889 > available for IRCServices. So I was wondering if anyone here might know of
51890 > such a module or maybe if it's planned for any future versions of
51893 > This HostServ module doesn't have to be complicated. Just the basic Add,
51894 > remove, list and login commands.
51899 > ------------------------------------------------------------------
51900 > To unsubscribe or change your subscription options, visit:
51901 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
51906 From Craig at chatspike.net Mon Dec 8 20:50:45 2003
51907 From: Craig at chatspike.net (Craig McLure)
51908 Date: Sat Oct 23 23:10:13 2004
51909 Subject: [IRCServices Coding] Getting Main nickname from a nickgroup ID..
51910 Message-ID: <E1ATZpI-0007hQ-7X@ptb-relay01.plus.net>
51912 i was trying to do this today, some files for my hostserv module have the filenames of that users nickgroup, so the vhost sets on ID.. however, when i did a get_ngi_id(filename), it somehow came out with the error:
51913 [Dec 09 04:19:01 2003] nickserv/main: Unable to get NickGroupInfo (id 136191691) at hostserv.c:155
51914 then seg-faulted.. which i thought was kinda bizare, especially concidering the nickgroup in question was 3.. could this be caused by bad casting? or am i doing something wrong? if its either of these, whats the best way to solve it?
51916 thanks in advance :)
51919 /****************************************
51920 * Craig "FrostyCoolSlug" McLure
51921 * InspIRCd - http://www.inspircd.org
51922 * ChatSpike - http://www.chatspike.net
51923 ****************************************/
51927 From achurch at achurch.org Tue Dec 9 14:38:05 2003
51928 From: achurch at achurch.org (Andrew Church)
51929 Date: Sat Oct 23 23:10:13 2004
51930 Subject: [IRCServices Coding] Getting Main nickname from a nickgroup ID..
51931 In-Reply-To: <E1ATZpI-0007hQ-7X@ptb-relay01.plus.net>
51932 Message-ID: <3fd55feb.60442@achurch.org>
51934 >i was trying to do this today, some files for my hostserv module have the filenames of that users nickgroup, so the vhost sets on ID.. however, when i did a get_ngi_id(filename), it somehow came out with the error:
51935 >[Dec 09 04:19:01 2003] nickserv/main: Unable to get NickGroupInfo (id 136191691) at hostserv.c:155
51936 >then seg-faulted.. which i thought was kinda bizare, especially concidering the nickgroup in question was 3.. could this be caused by bad casting? or am i doing something wrong? if its either of these, whats the best way to solve it?
51938 get_ngi_id() takes the numeric nickgroup ID; it looks like you're
51939 passing a string. The crash is probably you not checking for a NULL
51943 achurch@achurch.org
51944 http://achurch.org/
51946 From brain at brainbox.winbot.co.uk Wed Dec 10 09:18:14 2003
51947 From: brain at brainbox.winbot.co.uk (Craig Edwards)
51948 Date: Sat Oct 23 23:10:13 2004
51949 Subject: [IRCServices Coding] Event ordering
51950 Message-ID: <200312101718.hBAHIEv10185@localhost.localdomain>
51954 We've developed a simple hostserv module, and we have hooked onto the 'nickserv identify' event... however....
51955 because of the ordering of callbacks etc, the hostserv system is called AFTER nickserv autojoin etc, meaning that users using nickserv autojoin join channels with their 'normal' hostmask. Would it be possible in a future version of ircservices to have some way to alter the priorities of modules/callbacks and/or have some form of event queue, so in this case we could set the priority of hostserv above that of nickserv/autojoin etc? It might be useful in other circumstances too :-)
51961 http://www.chatspike.net
51965 From achurch at achurch.org Thu Dec 11 09:45:28 2003
51966 From: achurch at achurch.org (Andrew Church)
51967 Date: Sat Oct 23 23:10:13 2004
51968 Subject: [IRCServices Coding] Event ordering
51969 In-Reply-To: <200312101718.hBAHIEv10185@localhost.localdomain>
51970 Message-ID: <3fd7be4a.73420@achurch.org>
51972 RTFM (6-1-4) and use add_callback_pri().
51975 achurch@achurch.org
51976 http://achurch.org/
51980 >We've developed a simple hostserv module, and we have hooked onto the 'nickserv identify' event... however....
51981 >because of the ordering of callbacks etc, the hostserv system is called AFTER nickserv autojoin etc, meaning that users using nickserv autojoin join channels with their 'normal' hostmask. Would it be possible in a future version of ircservices to have som
51982 >e way to alter the priorities of modules/callbacks and/or have some form of event queue, so in this case we could set the priority of hostserv above that of nickserv/autojoin etc? It might be useful in other circumstances too :-)
51988 >http://www.chatspike.net
51991 >------------------------------------------------------------------
51992 >To unsubscribe or change your subscription options, visit:
51994 From freakycomputer at global.co.za Fri Dec 12 09:31:57 2003
51995 From: freakycomputer at global.co.za (FreakyComputer)
51996 Date: Sat Oct 23 23:10:13 2004
51997 Subject: [IRCServices Coding] UnrealIRCd - PREFIX_AQ
51998 Message-ID: <000a01c3c0d5$d941a1b0$0100a8c0@blauwhome>
52000 Hiya, it's me again!
52002 As, some of you, might know, UnrealIRCd has a new option for PREFIX_AQ,
52003 which gives all Protected users and Channel owners new prefixes. You also
52004 don't require +o if you have +a/q to perform Channel operations like Kicking
52007 I was wondering, how does IRCServices cope with these new prefixes? Is there
52008 something I drastically need change in the protocol setup. Also, does
52009 IRCServices still set +ao when a user's got AUTOPROTECT and also +qo when a
52010 user is the OWNER. Since this is no longer needed in Unreal with the
52011 PREFIX_AQ enabled, is there a way to stop IRCServices from setting both o
52012 and q/a when a user has sufficient access.
52014 Thanks for any help,
52018 From achurch at achurch.org Sat Dec 13 02:34:46 2003
52019 From: achurch at achurch.org (Andrew Church)
52020 Date: Sat Oct 23 23:10:13 2004
52021 Subject: [IRCServices Coding] UnrealIRCd - PREFIX_AQ
52022 In-Reply-To: <000a01c3c0d5$d941a1b0$0100a8c0@blauwhome>
52023 Message-ID: <3fd9fcec.51614@achurch.org>
52025 >As, some of you, might know, UnrealIRCd has a new option for PREFIX_AQ,
52026 >which gives all Protected users and Channel owners new prefixes. You also
52027 >don't require +o if you have +a/q to perform Channel operations like Kicking
52030 >I was wondering, how does IRCServices cope with these new prefixes? Is there
52031 >something I drastically need change in the protocol setup.
52033 I don't know how these prefixes are implemented; assuming they use
52034 ordinary nickname change commands, Services will recognize them, but users
52035 will need to link the prefixed nicknames to their regular nicknames or they
52036 will lose privileges on the channel (which could potentially result in mode
52037 change loops). I have no plans to add specific support for such prefixes.
52040 >IRCServices still set +ao when a user's got AUTOPROTECT and also +qo when a
52041 >user is the OWNER. Since this is no longer needed in Unreal with the
52042 >PREFIX_AQ enabled, is there a way to stop IRCServices from setting both o
52043 >and q/a when a user has sufficient access.
52048 achurch@achurch.org
52049 http://achurch.org/
52051 From freakycomputer at global.co.za Sat Dec 13 07:38:24 2003
52052 From: freakycomputer at global.co.za (FreakyComputer)
52053 Date: Sat Oct 23 23:10:13 2004
52054 Subject: [IRCServices Coding] UnrealIRCd - PREFIX_AQ
52055 References: <3fd9fcec.51614@achurch.org>
52056 Message-ID: <002001c3c18f$2ba825f0$0100a8c0@blauwhome>
52058 Actually, all it is, is that people with chumode +a and +q just get a symbol
52059 in front of their nicks in the channel, ~ to owners and & protected users
52060 (just like @ is to ops and % is to halfops). The thing about only receiving
52061 the +q/a without the +o isn't a major thing, and there was just little
52062 changes made to the unreal protocol (new_chanusermodes) to accomodate the
52063 change of prefixes/symbol. But there is another thing I found. There isn't a
52064 way for the founder/owner to set him/herself -q in the channel. We have
52065 tried several things, such as with and without the new prefixes, with or
52066 without identifying, everything. I would think the services would set -q
52067 when the user issues a DEPROTECT command, but the services just say that the
52068 user is already not a protected user, so if there can be a fix to that
52069 command, or perhaps a new command: FOUNDER, DEFOUNDER, it might make it
52070 easier for channels where some rule of "deopping yourself while offduty"
52073 Thanks for the prompt replies thusfar :D
52076 ----- Original Message -----
52077 From: "Andrew Church" <achurch@achurch.org>
52078 To: "serv-coding" <ircservices-coding@ircservices.za.net>
52079 Sent: Friday, December 12, 2003 7:34 PM
52080 Subject: Re: [IRCServices Coding] UnrealIRCd - PREFIX_AQ
52083 > >As, some of you, might know, UnrealIRCd has a new option for PREFIX_AQ,
52084 > >which gives all Protected users and Channel owners new prefixes. You also
52085 > >don't require +o if you have +a/q to perform Channel operations like
52089 > >I was wondering, how does IRCServices cope with these new prefixes? Is
52091 > >something I drastically need change in the protocol setup.
52093 > I don't know how these prefixes are implemented; assuming they use
52094 > ordinary nickname change commands, Services will recognize them, but users
52095 > will need to link the prefixed nicknames to their regular nicknames or
52097 > will lose privileges on the channel (which could potentially result in
52099 > change loops). I have no plans to add specific support for such prefixes.
52102 > >IRCServices still set +ao when a user's got AUTOPROTECT and also +qo when
52104 > >user is the OWNER. Since this is no longer needed in Unreal with the
52105 > >PREFIX_AQ enabled, is there a way to stop IRCServices from setting both o
52106 > >and q/a when a user has sufficient access.
52111 > achurch@achurch.org
52112 > http://achurch.org/
52113 > ------------------------------------------------------------------
52114 > To unsubscribe or change your subscription options, visit:
52115 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
52119 From phant0m at myrealbox.com Sun Dec 28 15:33:47 2003
52120 From: phant0m at myrealbox.com (Anton Volkov)
52121 Date: Sat Oct 23 23:10:13 2004
52122 Subject: [IRCServices Coding] feature request: instant messanger fields
52123 Message-ID: <20031228233401.408B01705B@snow.fingers.co.za>
52125 The memo forward is a useful feature though it is kind of bulky to go open your mail for 10 bytes of text.
52126 I would like to suggest to add ICQ (and yahoo, msn, AOL too I guess), to the user group database structure and to add an option on memo/forward to send the memos to ICQ pager for example.
52129 From Craig at chatspike.net Sun Dec 28 16:23:32 2003
52130 From: Craig at chatspike.net (Craig McLure)
52131 Date: Sat Oct 23 23:10:13 2004
52132 Subject: [IRCServices Coding] feature request: instant messanger fields
52133 Message-ID: <E1AalBh-000Dxg-8y@ptb-relay01.plus.net>
52135 (Sorry this went to the wrong list..)
52137 i think that 'IM Fields' is a very significant change for something so minor. The MSN, AOL and Y! protocols arnt documented, yet those and the ICQ protocol are _VERY_ complex in the way they work, and it all seems kinda pointless.
52139 /****************************************
52140 * Craig "FrostyCoolSlug" McLure
52141 * InspIRCd - http://www.inspircd.org
52142 * ChatSpike - http://www.chatspike.net
52143 ****************************************/
52146 /****************************************
52147 * From - Anton Volkov <phant0m@myrealbox.com>
52148 * To - ircservices-coding <ircservices-coding@ircservices.za.net>
52149 * Sent - 2003-12-29 01:33:00
52150 * Subject - [IRCServices Coding] feature request: instant messanger fields
52151 ****************************************/
52153 /****** - Begin Original Message - ******/
52155 >The memo forward is a useful feature though it is kind of bulky to go open your mail for 10 bytes of text.
52156 >I would like to suggest to add ICQ (and yahoo, msn, AOL too I guess), to the user group database structure and to add an option on memo/forward to send the memos to ICQ pager for example.
52158 >------------------------------------------------------------------
52159 >To unsubscribe or change your subscription options, visit:
52160 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
52163 /******* - End Original Message - *******/
52168 From phant0m at myrealbox.com Mon Dec 29 15:59:45 2003
52169 From: phant0m at myrealbox.com (Anton Volkov)
52170 Date: Sat Oct 23 23:10:13 2004
52171 Subject: [IRCServices Coding] feature request: instant messanger fields
52172 In-Reply-To: <E1AalBh-000Dxg-8y@ptb-relay01.plus.net>
52173 Message-ID: <20031230000000.21DB117040@snow.fingers.co.za>
52176 I think you have not understood my proposal, and even if this is a major change the way you judge its usefulness is totally wrong, plus what's protocol documentation has to do with a simple email?
52177 And unless you got something smart to say don't say it.
52179 -----Original Message-----
52180 From: ircservices-coding-bounces@ircservices.za.net [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of Craig McLure
52181 Sent: Monday, December 29, 2003 2:24 AM
52182 To: ircservices-coding@ircservices.za.net
52183 Subject: Re: [IRCServices Coding] feature request: instant messanger fields
52185 (Sorry this went to the wrong list..)
52187 i think that 'IM Fields' is a very significant change for something so minor. The MSN, AOL and Y! protocols arnt documented, yet those and the ICQ protocol are _VERY_ complex in the way they work, and it all seems kinda pointless.
52191 From Craig at chatspike.net Mon Dec 29 16:21:32 2003
52192 From: Craig at chatspike.net (Craig McLure)
52193 Date: Sat Oct 23 23:10:13 2004
52194 Subject: [IRCServices Coding] feature request: instant messanger fields
52195 Message-ID: <E1Ab7da-000Aka-3Z@ptb-relay02.plus.net>
52197 well, i regard it as 'totally useful' and i'm sure others would do the same, and this has nothing to do with the email protocol.. what it _DOES_ have to do with is the ICQ / YIM / MSN / AIM protocols, all complex, and most undocumented. ICQ Pager works by taking a HTTP POST from a website, and has been prooven un-reliable, as its simple enouigh for users to press an 'Off' button on them, as they are mostly used for spam. Also there is a high chance that you will get a page informing you that the message send has failed. And as i was saying, this would take a conciderable ammount of coding, for something that will rarely be used.
52199 /****************************************
52200 * Craig "FrostyCoolSlug" McLure
52201 * InspIRCd - http://www.inspircd.org
52202 * ChatSpike - http://www.chatspike.net
52203 ****************************************/
52206 /****************************************
52207 * From - Anton Volkov <phant0m@myrealbox.com>
52208 * To - 'IRC Services Coding Mailing List' <ircservices-coding@ircservices.za.net>
52209 * Sent - 2003-12-30 01:59:00
52210 * Subject - RE: [IRCServices Coding] feature request: instant messanger fields
52211 ****************************************/
52213 /****** - Begin Original Message - ******/
52215 >I think you have not understood my proposal, and even if this is a major change the way you judge its usefulness is totally wrong, plus what's protocol documentation has to do with a simple email?
52216 >And unless you got something smart to say don't say it.
52218 >-----Original Message-----
52219 >From: ircservices-coding-bounces@ircservices.za.net [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of Craig McLure
52220 >Sent: Monday, December 29, 2003 2:24 AM
52221 >To: ircservices-coding@ircservices.za.net
52222 >Subject: Re: [IRCServices Coding] feature request: instant messanger fields
52224 >(Sorry this went to the wrong list..)
52226 >i think that 'IM Fields' is a very significant change for something so minor. The MSN, AOL and Y! protocols arnt documented, yet those and the ICQ protocol are _VERY_ complex in the way they work, and it all seems kinda pointless.
52229 >------------------------------------------------------------------
52230 >To unsubscribe or change your subscription options, visit:
52231 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
52234 /******* - End Original Message - *******/
52239 From ganja51 at lcirc.net Mon Dec 29 16:30:12 2003
52240 From: ganja51 at lcirc.net (Ganja51)
52241 Date: Sat Oct 23 23:10:13 2004
52242 Subject: [IRCServices Coding] feature request: instant messanger fields
52243 References: <E1Ab7da-000Aka-3Z@ptb-relay02.plus.net>
52244 Message-ID: <000c01c3ce6c$16e8c810$1402a8c0@monte>
52246 And protocols such as these often change as well. I know IMServ often has
52247 problems working with AIM simply due to the fact AIM keeps changing it's
52248 protocols. These protocols are undocumented as well, which makes it a lot of
52249 work for so very little. I'm not saying it's a useless feature, but I agree
52250 that it would be far to much work to incorporate and maintain.
52254 ----- Original Message -----
52255 From: "Craig McLure" <Craig@chatspike.net>
52256 To: <ircservices-coding@ircservices.za.net>
52257 Sent: Monday, December 29, 2003 6:21 PM
52258 Subject: Re: RE: [IRCServices Coding] feature request: instant messanger
52262 > well, i regard it as 'totally useful' and i'm sure others would do the
52263 same, and this has nothing to do with the email protocol.. what it _DOES_
52264 have to do with is the ICQ / YIM / MSN / AIM protocols, all complex, and
52265 most undocumented. ICQ Pager works by taking a HTTP POST from a website, and
52266 has been prooven un-reliable, as its simple enouigh for users to press an
52267 'Off' button on them, as they are mostly used for spam. Also there is a high
52268 chance that you will get a page informing you that the message send has
52269 failed. And as i was saying, this would take a conciderable ammount of
52270 coding, for something that will rarely be used.
52272 > /****************************************
52273 > * Craig "FrostyCoolSlug" McLure
52274 > * InspIRCd - http://www.inspircd.org
52275 > * ChatSpike - http://www.chatspike.net
52276 > ****************************************/
52279 > /****************************************
52280 > * From - Anton Volkov <phant0m@myrealbox.com>
52281 > * To - 'IRC Services Coding Mailing List'
52282 <ircservices-coding@ircservices.za.net>
52283 > * Sent - 2003-12-30 01:59:00
52284 > * Subject - RE: [IRCServices Coding] feature request: instant messanger
52286 > ****************************************/
52288 > /****** - Begin Original Message - ******/
52290 > >I think you have not understood my proposal, and even if this is a major
52291 change the way you judge its usefulness is totally wrong, plus what's
52292 protocol documentation has to do with a simple email?
52293 > >And unless you got something smart to say don't say it.
52295 > >-----Original Message-----
52296 > >From: ircservices-coding-bounces@ircservices.za.net
52297 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of Craig
52299 > >Sent: Monday, December 29, 2003 2:24 AM
52300 > >To: ircservices-coding@ircservices.za.net
52301 > >Subject: Re: [IRCServices Coding] feature request: instant messanger
52304 > >(Sorry this went to the wrong list..)
52306 > >i think that 'IM Fields' is a very significant change for something so
52307 minor. The MSN, AOL and Y! protocols arnt documented, yet those and the ICQ
52308 protocol are _VERY_ complex in the way they work, and it all seems kinda
52312 > >------------------------------------------------------------------
52313 > >To unsubscribe or change your subscription options, visit:
52314 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
52317 > /******* - End Original Message - *******/
52321 > ------------------------------------------------------------------
52322 > To unsubscribe or change your subscription options, visit:
52323 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
52328 From phantom at phntm.nix.org.il Tue Dec 30 05:56:47 2003
52329 From: phantom at phntm.nix.org.il (PHANTOm)
52330 Date: Sat Oct 23 23:10:13 2004
52331 Subject: [IRCServices Coding] feature request: instant messanger fields
52332 In-Reply-To: <000c01c3ce6c$16e8c810$1402a8c0@monte>
52333 Message-ID: <20031230135704.E6C251704A@snow.fingers.co.za>
52335 ICQ supports getting uin@pager.icq.com email and almost everyone will get it, as for yahoo and hotmail I agree it takes coding to a specific protocol with SSL and other stuff but in that case you could just email to the @yahoo or @hotmail email and the user would get a notice (this could be simple an alternative email address).
52339 From Craig at chatspike.net Tue Dec 30 12:32:10 2003
52340 From: Craig at chatspike.net (Craig McLure)
52341 Date: Sat Oct 23 23:10:13 2004
52342 Subject: [IRCServices Coding] feature request: instant messanger fields
52343 Message-ID: <E1AbQX6-0000fR-Fu@ptb-relay01.plus.net>
52345 so register your nickname with one of those email addresses? :/
52347 /****************************************
52348 * Craig "FrostyCoolSlug" McLure
52349 * InspIRCd - http://www.inspircd.org
52350 * ChatSpike - http://www.chatspike.net
52351 ****************************************/
52354 /****************************************
52355 * From - PHANTOm <phantom@phntm.nix.org.il>
52356 * To - 'IRC Services Coding Mailing List' <ircservices-coding@ircservices.za.net>
52357 * Sent - 2003-12-30 15:56:00
52358 * Subject - RE: [IRCServices Coding] feature request: instant messanger fields
52359 ****************************************/
52361 /****** - Begin Original Message - ******/
52363 >ICQ supports getting uin@pager.icq.com email and almost everyone will get it, as for yahoo and hotmail I agree it takes coding to a specific protocol with SSL and other stuff but in that case you could just email to the @yahoo or @hotmail email and the user would get a notice (this could be simple an alternative email address).
52366 >------------------------------------------------------------------
52367 >To unsubscribe or change your subscription options, visit:
52368 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
52371 /******* - End Original Message - *******/
52376 From phantom at phntm.nix.org.il Tue Dec 30 12:49:41 2003
52377 From: phantom at phntm.nix.org.il (PHANTOm)
52378 Date: Sat Oct 23 23:10:13 2004
52379 Subject: [IRCServices Coding] feature request: instant messanger fields
52380 In-Reply-To: <E1AbQX6-0000fR-Fu@ptb-relay01.plus.net>
52381 Message-ID: <20031230204959.F042B17035@snow.fingers.co.za>
52383 Thanks for that genius, now be quiet.
52385 /*************************************
52386 * I SPAM MY CRAPPY STUPID WEBSITE TOO
52387 * AND SEND IT IN MY SHITTY MAIL
52388 *************************************/
52390 -----Original Message-----
52391 From: ircservices-coding-bounces@ircservices.za.net [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of Craig McLure
52392 Sent: Tuesday, December 30, 2003 10:32 PM
52393 To: ircservices-coding@ircservices.za.net
52394 Subject: Re: [IRCServices Coding] feature request: instant messanger fields
52396 so register your nickname with one of those email addresses? :/
52398 /****************************************
52399 * Craig "FrostyCoolSlug" McLure
52400 * InspIRCd - http://www.inspircd.org
52401 * ChatSpike - http://www.chatspike.net
52402 ****************************************/
52406 From quension at mac.com Tue Dec 30 13:24:34 2003
52407 From: quension at mac.com (Trevor Talbot)
52408 Date: Sat Oct 23 23:10:13 2004
52409 Subject: [IRCServices Coding] feature request: instant messanger fields
52410 In-Reply-To: <20031230204959.F042B17035@snow.fingers.co.za>
52411 Message-ID: <9095D3A6-3B0E-11D8-B10D-0003938D6866@mac.com>
52413 On Tuesday, Dec 30, 2003, at 12:49 US/Pacific, PHANTOm wrote:
52415 > Thanks for that genius, now be quiet.
52417 > /*************************************
52418 > * I SPAM MY CRAPPY STUPID WEBSITE TOO
52419 > * AND SEND IT IN MY SHITTY MAIL
52420 > *************************************/
52422 This kind of thing isn't called for. If you can't handle calm
52423 observations about your suggestions, do everyone a favor and stay away
52424 from mailing lists.
52426 If you must have this feature, despite all of the difficulties and
52427 disadvantages others have pointed out, a constructive response at this
52428 point would be creating a proof-of-concept modification and posting a
52429 link to it. After all, this is the coding list.
52434 From jamie at silverdream.org Wed Dec 31 01:10:29 2003
52435 From: jamie at silverdream.org (Jamie Penman-Smithson)
52436 Date: Sat Oct 23 23:10:13 2004
52437 Subject: [IRCServices Coding] feature request: instant messanger fields
52438 In-Reply-To: <20031230204959.F042B17035@snow.fingers.co.za>
52439 References: <20031230204959.F042B17035@snow.fingers.co.za>
52440 Message-ID: <1072861829.4571.168.camel@localhost>
52442 On Tue, 2003-12-30 at 20:49, PHANTOm wrote:
52443 > Thanks for that genius, now be quiet.
52445 > /*************************************
52446 > * I SPAM MY CRAPPY STUPID WEBSITE TOO
52447 > * AND SEND IT IN MY SHITTY MAIL
52448 > *************************************/
52451 This is a forum for discussion, not pointless flaming. Learn to show
52452 some respect for other peoples opinions, even if they contrast with
52455 Yes, your idea may hold some merit, however the time it would take up to
52456 implement could be much better used elsewhere, on sorting out the
52457 database format, for example.
52459 If you want this feature so bad, then write a patch to achieve it. Don't
52460 throw a tantrum and throw your toys around the room just because
52461 (*shock* *horror*) someone actually disagrees with you.
52466 -jamie <jamie@silverdream.org>
52467 w: http://silverdream.org | p: sms@silverdream.org
52468 pgp key @ http://silverdream.org/~jps/pub.key
52469 08:33:49 up 12:08, 3 users, load average: 0.02, 0.15, 0.33
52470 -------------- next part --------------
52471 A non-text attachment was scrubbed...
52472 Name: not available
52473 Type: application/pgp-signature
52475 Desc: This is a digitally signed message part
52476 Url : http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20031231/2707d8d9/attachment.pgp
52477 From phantom at phntm.nix.org.il Wed Dec 31 01:51:31 2003
52478 From: phantom at phntm.nix.org.il (PHANTOm)
52479 Date: Sat Oct 23 23:10:13 2004
52480 Subject: [IRCServices Coding] feature request: instant messanger fields
52481 In-Reply-To: <1072861829.4571.168.camel@localhost>
52482 Message-ID: <20031231095152.00C9817071@snow.fingers.co.za>
52484 What I said was inappropriate and I am sorry for that,
52485 I agree that this is not a priority feature and I'd sure like see mysql databases in ircservices a lot more then this, which would also make patching and modding so much easier.
52486 I did code this little thing myself and now I am doomed with an incompatible database but since I already had this with vhosts it's not that big a change.
52488 -----Original Message-----
52489 From: ircservices-coding-bounces@ircservices.za.net [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of Jamie Penman-Smithson
52490 Sent: Wednesday, December 31, 2003 11:10 AM
52491 To: ircservices-coding@ircservices.za.net
52492 Subject: RE: [IRCServices Coding] feature request: instant messanger fields
52497 This is a forum for discussion, not pointless flaming. Learn to show
52498 some respect for other peoples opinions, even if they contrast with
52501 Yes, your idea may hold some merit, however the time it would take up to
52502 implement could be much better used elsewhere, on sorting out the
52503 database format, for example.
52505 If you want this feature so bad, then write a patch to achieve it. Don't
52506 throw a tantrum and throw your toys around the room just because
52507 (*shock* *horror*) someone actually disagrees with you.
52512 -jamie <jamie@silverdream.org>
52513 w: http://silverdream.org | p: sms@silverdream.org
52514 pgp key @ http://silverdream.org/~jps/pub.key
52515 08:33:49 up 12:08, 3 users, load average: 0.02, 0.15, 0.33