software/!RELEASES/ircservices/achurch.org/services/lists/ircservices-coding/2003.txt

   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>
   7
   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.
  13
  14   --Andrew Church
  15     achurch@achurch.org
  16     http://achurch.org/
  17
  18 >This is a multi-part message in MIME format.
  19 >
  20 >--Boundary_(ID_iiHC64a6A6NdaLuY3JRsCA)
  21 >Content-type: text/plain; charset=iso-8859-1
  22 >Content-transfer-encoding: 7BIT
  23 >
  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:
  25 >
  26 >modules/operserv/main.c:
  27 >
  28 >
  29 >/* Callback for saving data. */
  30 >
  31 >static int do_save_data(void)
  32 >{
  33 >    sync_operserv_db(OperDBName);
  34 >    return 0;
  35 >}
  36 >
  37 >
  38 >I tried to add this (with the appropriate static char's):
  39 >
  40 >
  41 >/* Callback for saving data. */
  42 >
  43 >static int do_save_data(void)
  44 >{
  45 >    sync_channel_db(ChanDBName);
  46 >    sync_operserv_db(OperDBName);
  47 >    sync_statserv_db(StatDBName);
  48 >    return 0;
  49 >}
  50 >
  51 >
  52 >and I couldn't get it to work.
  53 >
  54 >Ideas?
  55 >
  56 >
  57 >
  58 >/Patrick Fish
  59 >
  60 >
  61 >---
  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
  65 >
  66 >--Boundary_(ID_iiHC64a6A6NdaLuY3JRsCA)
  67 >Content-type: text/html; charset=iso-8859-1
  68 >Content-transfer-encoding: 7BIT
  69 >
  70 ><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
  71 ><HTML><HEAD>
  72 ><META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
  73 ><META content="MSHTML 6.00.2800.1126" name=GENERATOR>
  74 ><STYLE></STYLE>
  75 ></HEAD>
  76 ><BODY bgColor=#ffffff>
  77 ><DIV><FONT face=Arial size=2>I think it would be better when using&nbsp;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>&nbsp;</DIV>
  81 ><DIV><FONT face=Arial size=2>modules/operserv/main.c:</FONT></DIV>
  82 ><DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV><FONT face=Arial size=2>
  83 ><DIV><BR>/* Callback for saving data. */</DIV>
  84 ><DIV>&nbsp;</DIV>
  85 ><DIV>static int do_save_data(void)<BR>{<BR>&nbsp;&nbsp;&nbsp;
  86 >sync_operserv_db(OperDBName);<BR>&nbsp;&nbsp;&nbsp; return 0;<BR>}<BR></DIV>
  87 ><DIV>&nbsp;</DIV>
  88 ><DIV>I tried to add this (with the appropriate static char's):</DIV>
  89 ><DIV>&nbsp;</DIV>
  90 ><DIV><BR>/* Callback for saving data. */</DIV>
  91 ><DIV>&nbsp;</DIV>
  92 ><DIV>static int do_save_data(void)<BR>{<BR>&nbsp;&nbsp;&nbsp;
  93 >sync_channel_db(ChanDBName);<BR>&nbsp;&nbsp;&nbsp;
  94 >sync_operserv_db(OperDBName);<BR>&nbsp;&nbsp;&nbsp;
  95 >sync_statserv_db(StatDBName);<BR>&nbsp;&nbsp;&nbsp; return 0;<BR>}<BR></DIV>
  96 ><DIV>&nbsp;</DIV>
  97 ><DIV>and I couldn't get it to work.</DIV>
  98 ><DIV>&nbsp;</DIV>
  99 ><DIV>Ideas?</DIV>
 100 ><DIV>&nbsp;</DIV>
 101 ><DIV>&nbsp;</DIV>
 102 ><DIV>&nbsp;</DIV>
 103 ><DIV>/Patrick Fish</DIV>
 104 ><DIV>&nbsp;</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>
 109 >
 110 >--Boundary_(ID_iiHC64a6A6NdaLuY3JRsCA)--
 111 >------------------------------------------------------------------
 112 >To unsubscribe or change your subscription options, visit:
 113 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
 114
 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>
 121
 122 >I'm working on monkeyircd's protocol module for services, and I've hit a
 123 >problem.
 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.
 128
 129      This is already built in--look at the m_capab() handler in bahamut.c
 130 for an example.
 131
 132   --Andrew Church
 133     achurch@achurch.org
 134     http://achurch.org/
 135
 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>
 142
 143      Fixed, thanks for the report.
 144
 145   --Andrew Church
 146     achurch@achurch.org
 147     http://achurch.org/
 148
 149 >Occasionally when several AKILLs expire at or around the same time, OperServ
 150 >will do this:
 151 >
 152 >[14:06] -avalon.on.ca.zirc.org- *** Global -- from OperServ: AKILL on * has
 153 >expired
 154 >[14:06] -avalon.on.ca.zirc.org- *** Global -- from OperServ: AKILL on * has
 155 >expired
 156 >[14:06] -avalon.on.ca.zirc.org- *** Global -- from OperServ: AKILL on * has
 157 >expired
 158 >[14:06] -avalon.on.ca.zirc.org- *** Global -- from OperServ: AKILL on * has
 159 >expired
 160 >[14:06] -avalon.on.ca.zirc.org- *** Global -- from OperServ: AKILL on * has
 161 >expired
 162 >
 163 >------------------------------------------------------------------
 164 >To unsubscribe or change your subscription options, visit:
 165 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
 166
 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>
 174
 175 On Wed, 2003-01-01 at 14:29, Andrew Church wrote:
 176 >
 177 >      This is already built in--look at the m_capab() handler in bahamut.c
 178 > for an example.
 179 Yeah, I didn't notice that, Bahamut uses NOQUIT, monkeyircd uses TS4 (in
 180 the CAPAB bit).
 181 Consider it fixed, and I've fixed some other niggles, I'll post you a
 182 patch for 5.0.7.
 183
 184 Chris
 185
 186
 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>
 194
 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?
 198
 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...
 202
 203
 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>
 209
 210 trying to understand some of this code...
 211
 212 was just curious as to something... in the function local_set_cumodes you do:
 213         char buf[3]
 214
 215 so that it fits 4 chars: 0 1 2 3
 216 but you only use 3: 0 1 2
 217
 218 just a mistake or is there a reason for it?
 219
 220 thanks
 221
 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>
 227
 228 looks like the final byte is used for a null terminator?
 229
 230 0 1 2 0x00
 231
 232 >trying to understand some of this code...
 233 >
 234 >was just curious as to something... in the function local_set_cumodes you do:
 235 >       char buf[3]
 236 >
 237 >so that it fits 4 chars: 0 1 2 3
 238 >but you only use 3: 0 1 2
 239 >
 240 >just a mistake or is there a reason for it?
 241 >
 242 >thanks
 243 >------------------------------------------------------------------
 244 >To unsubscribe or change your subscription options, visit:
 245 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
 246
 247
 248
 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>
 254
 255 Any takers?
 256
 257 Update: Any time a server splits, this happens - doesn't have to be squit.
 258
 259
 260 -p
 261
 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
 268
 269
 270 | It seems IRCServices crashes every time a server gets squit:
 271 | (bahamut-1.4(35))
 272 |
 273 |
 274 |
 275 |
 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
 281 sendK/recvK.
 282 | [05:14:01] -patrick.liveharmony.org- *** Global -- from
 283 | services.liveharmony.org: PANIC! buffer = SQUIT
 284 patrick.dev.liveharmony.org
 285 | :Patrick
 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
 289 error)
 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
 294 |
 295 |
 296 | I cant find where the problem is. I'm running 5.0.6.
 297 |
 298 |
 299 |
 300 | ===========
 301 | Patrick Fish
 302 | patrick@pwhsnet.com
 303 |
 304 |
 305 | ---
 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
 309 |
 310 | ------------------------------------------------------------------
 311 | To unsubscribe or change your subscription options, visit:
 312 | http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
 313 |
 314
 315
 316 ---
 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
 320
 321
 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>
 328
 329 On Wednesday, Jan 1, 2003, at 17:04 US/Pacific, Ron wrote:
 330
 331 > was just curious as to something... in the function local_set_cumodes
 332 > you do:
 333 >       char buf[3]
 334 >
 335 > so that it fits 4 chars: 0 1 2 3
 336
 337 Might want to brush up on your C ;)
 338
 339 Array declarations are size-based: char buf[3] holds 3 chars.
 340 Only indexing is zero-based.
 341
 342 -- Quension
 343
 344
 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>
 352
 353 On Wednesday 01 January 2003 06:45 pm, Trevor Talbot wrote:
 354 > Might want to brush up on your C ;)
 355 >
 356 > Array declarations are size-based: char buf[3] holds 3 chars.
 357 > Only indexing is zero-based.
 358
 359 weee... hehe... thanks
 360
 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>
 367
 368 On Wed, 1 Jan 2003, Ron wrote:
 369
 370 > trying to understand some of this code...
 371 >
 372 > was just curious as to something... in the function local_set_cumodes you do:
 373 >       char buf[3]
 374 >
 375 > so that it fits 4 chars: 0 1 2 3
 376 > but you only use 3: 0 1 2
 377 >
 378 > just a mistake or is there a reason for it?
 379 >
 380
 381 Jesus christ ron, are you snorting blocks?
 382
 383 char buf[3] declares 3 chars, buf[0], buf[1] and buf[2]
 384
 385 Go to rehab
 386
 387
 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>
 393
 394 Church,
 395     I thought you said the ...
 396
 397 "(-04:49-) (-notice:ChanServ-) Sorry, the CLEAR command is temporarily unavailable."
 398
 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.
 400
 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. :)
 402
 403 -prince
 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>
 413
 414 Yes, I still get this myself on occasion. /operserv restart and
 415 everything's fine for a bit, but it eventually starts again.
 416
 417 Bah.
 418
 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.
 425
 426
 427 Church,
 428     I thought you said the ...
 429
 430 "(-04:49-) (-notice:ChanServ-) Sorry, the CLEAR command is temporarily
 431 unavailable."
 432
 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
 437 correctly.
 438
 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
 444 it. :)
 445
 446 -prince
 447
 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>
 457
 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.
 461
 462 [00:00] -alpha.deltacore.za.org- *** Global -- from ChanServ: Warning:
 463 Repeated bad password attempts for chan #chan.
 464
 465 It doesn't tell me what the nick is of the person causing the problems?
 466 I'm running ircservices-5.0.6.
 467
 468
 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>
 475
 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
 478 of time.
 479
 480
 481
 482
 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>
 490
 491 Yea I've also noticed this.  Does the same in 4.5.
 492
 493
 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.
 499 >
 500 > [00:00] -alpha.deltacore.za.org- *** Global -- from ChanServ: Warning:
 501 > Repeated bad password attempts for chan #chan.
 502 >
 503 > It doesn't tell me what the nick is of the person causing the problems?
 504 > I'm running ircservices-5.0.6.
 505 >
 506 > ------------------------------------------------------------------
 507 > To unsubscribe or change your subscription options, visit:
 508 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
 509
 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>
 518
 519 I was strumbling along on the network when I came across memoserv,
 520 this neat service only exchanges messages between users.
 521
 522 The question is, why does memoserv have +o. I cant think of any clear
 523 purpose it requires +o for.
 524
 525 In the weird case that I overlooked a function, lemmie know.
 526
 527 Info:
 528 IRCservices 5.0.6
 529 UnrealIRCd 3.1.5
 530
 531
 532 --Daan
 533
 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>
 539
 540 >Yes, I still get this myself on occasion. /operserv restart and
 541 >everything's fine for a bit, but it eventually starts again.
 542
 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
 547
 548
 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
 557
 558 >>eof
 559
 560
 561
 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>
 568
 569 >I was strumbling along on the network when I came across memoserv,
 570 >this neat service only exchanges messages between users.
 571 >
 572 >The question is, why does memoserv have +o. I cant think of any clear
 573 >purpose it requires +o for.
 574
 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.
 578
 579   --Andrew Church
 580     achurch@achurch.org
 581     http://achurch.org/
 582
 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>
 589
 590 >>Yes, I still get this myself on occasion. /operserv restart and
 591 >>everything's fine for a bit, but it eventually starts again.
 592 >
 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
 597
 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?
 600
 601   --Andrew Church
 602     achurch@achurch.org
 603     http://achurch.org/
 604
 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>
 611
 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.
 615 >
 616 >[00:00] -alpha.deltacore.za.org- *** Global -- from ChanServ: Warning:
 617 >Repeated bad password attempts for chan #chan.
 618 >
 619 >It doesn't tell me what the nick is of the person causing the problems?
 620 >I'm running ircservices-5.0.6.
 621
 622      This is designed behavior, but I agree that it could be improved.
 623
 624   --Andrew Church
 625     achurch@achurch.org
 626     http://achurch.org/
 627
 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>
 634
 635 >Some things changed in beta13 which I don't know exactly that can cause a
 636 >problem in IRCServices.
 637 >
 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
 640
 641      This only affects users, not Services.
 642
 643 >And this is a new one, don't know if it can be used in IRCServices:
 644 >
 645 >* SVSLUSERS was added to all U:lines to change local and global max user
 646 >counts (this is
 647 >  NOT meant so you can make the max count higher than it really should be.)
 648
 649      I'll think about this when Unreal 3.2 gets out of beta.
 650
 651 >Can you tell me if there would be errors if I use IRCServices with
 652 >Unreal3.2-beta13?
 653
 654      There shouldn't be, but I haven't tested it myself.
 655
 656   --Andrew Church
 657     achurch@achurch.org
 658     http://achurch.org/
 659
 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>
 666
 667 I'm not on bahamut, I'm on unreal 3.2.13
 668
 669 -----Original Message-----
 670 From: ircservices-coding-admin@ircservices.za.net
 671 [mailto:ircservices-coding-admin@ircservices.za.net] On Behalf Of Andrew
 672 Church
 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.
 676
 677
 678 >>Yes, I still get this myself on occasion. /operserv restart and
 679 >>everything's fine for a bit, but it eventually starts again.
 680 >
 681 >This happens here too. It appears to be a time synch issue. When I join
 682
 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
 685
 686 >fine. btw; I'm uing 5.0.6 on bahamut
 687
 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?
 690
 691   --Andrew Church
 692     achurch@achurch.org
 693     http://achurch.org/
 694 ------------------------------------------------------------------
 695 To unsubscribe or change your subscription options, visit:
 696 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
 697
 698
 699
 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>
 706
 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
 709 >possible?
 710 >How can I make it so that if the main Services goes down, a backup can take
 711 >over?
 712
 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.
 718
 719   --Andrew Church
 720     achurch@achurch.org
 721     http://achurch.org/
 722
 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>
 729
 730 >Any takers?
 731 >
 732 >Update: Any time a server splits, this happens - doesn't have to be squit.
 733
 734      I can't reproduce this.  Can you send me a backtrace or debug log?
 735
 736   --Andrew Church
 737     achurch@achurch.org
 738     http://achurch.org/
 739
 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>
 746
 747 >On Thursday 26 December 2002 06:33 am, Andrew Church wrote:
 748 >>      No; the callback ID (necessary for calling the callback) is privat
 749 >e to
 750 >> the NickServ module.  What do you need to call it for?
 751 >
 752 >well i know that callback basically returns a true/false if the given nic
 753 >k is
 754 >one of the services nicks... and i was thinking thats easier than if
 755 >irc_stricmp(nick, s_NickServ) etc...
 756
 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
 762 in use).
 763
 764   --Andrew Church
 765     achurch@achurch.org
 766     http://achurch.org/
 767
 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>
 774
 775 [Jan 05 22:03:33.342848 2003] debug: Loading language 0 from file
 776 `languages/en_us'
 777
 778 [Jan 05 22:03:33.623152 2003] debug: Loading language 10 from file
 779 `languages/nl'
 780
 781 [Jan 05 22:03:33.907396 2003] debug: Loading language 6 from file
 782 `languages/fr'
 783
 784 [Jan 05 22:03:34.194361 2003] debug: Loading language 9 from file
 785 `languages/de'
 786
 787 [Jan 05 22:03:34.482113 2003] debug: Loading language 11 from file
 788 `languages/hu'
 789
 790 [Jan 05 22:03:34.767058 2003] debug: Loading language 8 from file
 791 `languages/it'
 792
 793 [Jan 05 22:03:34.874151 2003] debug: Loading language 2 from file
 794 `languages/ja_euc'
 795
 796 [Jan 05 22:03:35.152207 2003] debug: Loading language 3 from file
 797 `languages/ja_sjis'
 798
 799 [Jan 05 22:03:35.430499 2003] debug: Loading language 5 from file
 800 `languages/pt'
 801
 802 [Jan 05 22:03:35.587054 2003] debug: Loading language 4 from file
 803 `languages/es'
 804
 805 [Jan 05 22:03:35.871661 2003] debug: Loading language 7 from file
 806 `languages/tr'
 807
 808 [Jan 05 22:03:36.152644 2003] debug: Loaded languages
 809
 810 [Jan 05 22:03:36.153293 2003] debug: Loading module `protocol/bahamut'
 811
 812 [Jan 05 22:03:36.156850 2003] debug: Successfully loaded module
 813 `protocol/bahamut'
 814
 815 [Jan 05 22:03:36.157462 2003] debug: Loading module `encryption/md5'
 816
 817 [Jan 05 22:03:36.162869 2003] debug: Successfully loaded module
 818 `encryption/md5'
 819
 820 [Jan 05 22:03:36.163464 2003] debug: Loading module `database/version4'
 821
 822 [Jan 05 22:03:36.171071 2003] debug: Successfully loaded module
 823 `database/version4'
 824
 825 [Jan 05 22:03:36.171705 2003] debug: Loading module `mail/main'
 826
 827 [Jan 05 22:03:36.174310 2003] debug: Successfully loaded module `mail/main'
 828
 829 [Jan 05 22:03:36.174922 2003] debug: Loading module `mail/smtp'
 830
 831 [Jan 05 22:03:36.177771 2003] debug: Successfully loaded module `mail/smtp'
 832
 833 [Jan 05 22:03:36.178358 2003] debug: Loading module `operserv/main'
 834
 835 [Jan 05 22:03:36.183289 2003] debug: Successfully loaded module
 836 `operserv/main'
 837
 838 [Jan 05 22:03:36.183902 2003] debug: Loading module `operserv/akill'
 839
 840 [Jan 05 22:03:36.188664 2003] debug: Successfully loaded module
 841 `operserv/akill'
 842
 843 [Jan 05 22:03:36.189283 2003] debug: Loading module `operserv/sline'
 844
 845 [Jan 05 22:03:36.193665 2003] debug: Successfully loaded module
 846 `operserv/sline'
 847
 848 [Jan 05 22:03:36.194388 2003] debug: Loading module `nickserv/main'
 849
 850 [Jan 05 22:03:36.202341 2003] debug: Successfully loaded module
 851 `nickserv/main'
 852
 853 [Jan 05 22:03:36.202985 2003] debug: Loading module `nickserv/access'
 854
 855 [Jan 05 22:03:36.207122 2003] debug: Successfully loaded module
 856 `nickserv/access'
 857
 858 [Jan 05 22:03:36.208317 2003] debug: Loading module `nickserv/link'
 859
 860 [Jan 05 22:03:36.213670 2003] debug: Successfully loaded module
 861 `nickserv/link'
 862
 863 [Jan 05 22:03:36.214827 2003] debug: Loading module `nickserv/mail-auth'
 864
 865 [Jan 05 22:03:36.219697 2003] debug: Successfully loaded module
 866 `nickserv/mail-auth'
 867
 868 [Jan 05 22:03:36.221165 2003] debug: Loading module `chanserv/main'
 869
 870 [Jan 05 22:03:36.229862 2003] debug: Successfully loaded module
 871 `chanserv/main'
 872
 873 [Jan 05 22:03:36.231053 2003] debug: Loading module `chanserv/access-xop'
 874
 875 [Jan 05 22:03:36.237171 2003] debug: Successfully loaded module
 876 `chanserv/access-xop'
 877
 878 [Jan 05 22:03:36.238869 2003] debug: Loading module `memoserv/main'
 879
 880 [Jan 05 22:03:36.244701 2003] debug: Successfully loaded module
 881 `memoserv/main'
 882
 883 [Jan 05 22:03:36.245864 2003] debug: Loading module `memoserv/forward'
 884
 885 [Jan 05 22:03:36.251647 2003] debug: Successfully loaded module
 886 `memoserv/forward'
 887
 888 [Jan 05 22:03:36.252787 2003] debug: Loading module `memoserv/ignore'
 889
 890 [Jan 05 22:03:36.258129 2003] debug: Successfully loaded module
 891 `memoserv/ignore'
 892
 893 [Jan 05 22:03:36.259266 2003] debug: Loading module `statserv/main'
 894
 895 [Jan 05 22:03:36.265807 2003] debug: Successfully loaded module
 896 `statserv/main'
 897
 898 [Jan 05 22:03:36.266954 2003] debug: Loading module `misc/helpserv'
 899
 900 [Jan 05 22:03:36.273016 2003] debug: Successfully loaded module
 901 `misc/helpserv'
 902
 903 [Jan 05 22:03:36.274237 2003] debug: Loaded modules
 904
 905 [Jan 05 22:03:36.277824 2003] Initiated connection to 127.0.0.1:6667
 906
 907 [Jan 05 22:03:36.287163 2003] debug: Sent: PASS password :TS
 908
 909 [Jan 05 22:03:36.291903 2003] debug: Sent: CAPAB TS3 SSJOIN NICKIP NOQUIT
 910
 911 [Jan 05 22:03:36.293779 2003] debug: Sent: SERVER services.liveharmony.org 1
 912 :liveHarmony Development Services
 913
 914 [Jan 05 22:03:36.295195 2003] debug: Sent: SVINFO 3 3 0 :1041833016
 915
 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
 918
 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
 921
 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
 924
 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
 927
 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
 930
 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
 933
 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
 936
 937 [Jan 05 22:03:36.306639 2003] debug: Received: :patrick.liveharmony.org
 938 NOTICE AUTH :*** Looking up your hostname...
 939
 940 [Jan 05 22:03:36.307782 2003] debug: Received: :patrick.liveharmony.org
 941 NOTICE AUTH :*** Checking Ident
 942
 943 [Jan 05 22:03:36.308875 2003] debug: Received: :patrick.liveharmony.org
 944 NOTICE AUTH :*** Found your hostname
 945
 946 [Jan 05 22:03:36.310252 2003] debug: Received: :patrick.liveharmony.org
 947 NOTICE AUTH :*** No Ident response
 948
 949 [Jan 05 22:03:36.389936 2003] debug: Received: PASS password :TS
 950
 951 [Jan 05 22:03:36.395304 2003] debug: Received: CAPAB TS3 NOQUIT SSJOIN BURST
 952 UNCONNECT ZIP NICKIP TSMODE
 953
 954 [Jan 05 22:03:36.396408 2003] debug: Received: SERVER
 955 patrick.liveharmony.org 1 :Patrick's Development Server
 956
 957 [Jan 05 22:03:36.397711 2003] debug: Received: SVINFO 5 3 0 :1041833016
 958
 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
 961 link
 962
 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
 966
 967 [Jan 05 22:03:36.401046 2003] debug: new user: Patrick
 968
 969 [Jan 05 22:03:36.402187 2003] user: New maximum user count: 1
 970
 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.
 974
 975 [Jan 05 22:03:36.405425 2003] debug: Changing mode for Patrick to +oiraA
 976
 977 [Jan 05 22:03:36.407035 2003] debug: Sent: :services.liveharmony.org SVSMODE
 978 Patrick -r
 979
 980 [Jan 05 22:03:36.408256 2003] debug: Sent: :services.liveharmony.org SVSMODE
 981 Patrick -a
 982
 983 [Jan 05 22:03:36.409381 2003] debug: Received: PING :patrick.liveharmony.org
 984
 985 [Jan 05 22:03:36.410816 2003] debug: Sent: :services.liveharmony.org PONG
 986 services.liveharmony.org patrick.liveharmony.org
 987
 988 [Jan 05 22:03:36.501718 2003] debug: Received: PING :patrick.liveharmony.org
 989
 990 [Jan 05 22:03:36.503203 2003] debug: Sent: :services.liveharmony.org PONG
 991 services.liveharmony.org patrick.liveharmony.org
 992
 993 [Jan 05 22:03:36.507936 2003] debug: Received: PING :patrick.liveharmony.org
 994
 995 [Jan 05 22:03:36.509685 2003] debug: Sent: :services.liveharmony.org PONG
 996 services.liveharmony.org patrick.liveharmony.org
 997
 998 [Jan 05 22:04:06.608203 2003] debug: Sent: PING :services.liveharmony.org
 999
1000 [Jan 05 22:04:06.613477 2003] debug: Received: :patrick.liveharmony.org PONG
1001 patrick.liveharmony.org :services.liveharmony.org
1002
1003 [Jan 05 22:04:36.708669 2003] debug: Sent: PING :services.liveharmony.org
1004
1005 [Jan 05 22:04:36.714122 2003] debug: Received: :patrick.liveharmony.org PONG
1006 patrick.liveharmony.org :services.liveharmony.org
1007
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:
1010 TS link
1011
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
1014
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
1017 link
1018
1019 [Jan 05 22:04:44.248937 2003] debug: Received: :patrick.liveharmony.org
1020 GNOTICE :patrick.dev.liveharmony.org has synched to network data.
1021
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
1024
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
1027
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)
1031
1032 [Jan 05 22:05:00.101054 2003] debug: Received: SQUIT
1033 patrick.dev.liveharmony.org :Patrick
1034
1035 [Jan 05 22:05:00.101743 2003] PANIC! buffer = SQUIT
1036 patrick.dev.liveharmony.org :Patrick
1037
1038 [Jan 05 22:05:00.106841 2003] debug: Sent: :services.liveharmony.org GLOBOPS
1039 :PANIC! buffer = SQUIT patrick.dev.liveharmony.org :Patrick
1040
1041 [Jan 05 22:05:00.107611 2003] Services terminating: Bus error
1042
1043 [Jan 05 22:05:00.114827 2003] debug: Sent: :services.liveharmony.org SQUIT
1044 services.liveharmony.org :Services terminating: Bus error
1045 -bash-2.05b$
1046
1047
1048 Didn't create a core.
1049
1050
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
1056
1057
1058 > >Any takers?
1059 > >
1060 > >Update: Any time a server splits, this happens - doesn't have to be
1061 squit.
1062 >
1063 >      I can't reproduce this.  Can you send me a backtrace or debug log?
1064 >
1065 >   --Andrew Church
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
1071 >
1072
1073
1074 ---
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
1078
1079
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>
1086
1087 I'm on Unreal 3.1.5
1088
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.
1092 < > >
1093 < > >This happens here too. It appears to be a time synch issue.
1094 < > When I join a
1095 < > >channel and the ircd gives me a synch warning, I can be rest
1096 < > assured that
1097 < > >some commands will fail unless I restart services...otherwise
1098 < > it's fine.
1099 < > >btw; I'm uing 5.0.6 on bahamut
1100 < >
1101 < >    This sounds like it might be a Bahamut bug with respect to
1102 < > U:lines.
1103 < > What's the exact text of the synch warning?
1104 < >
1105 < >  --Andrew Church
1106 < >   achurch@achurch.org
1107 < >   http://achurch.org/
1108 < > -----------------------------------------------------------------
1109 < > -
1110 < > To unsubscribe or change your subscription options, visit:
1111 < > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
1112
1113
1114
1115
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>
1122
1123
1124 Hi all,
1125
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
1131 intervention.
1132
1133 regards
1134
1135 Alex
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
1142 stampe.
1143
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 -----------------------------------------------------------------------------
1150
1151
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>
1158
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.
1164
1165 David
1166
1167
1168 Quoth Ciappei Alessandro (las3r) on Jan 6 at 11:52,
1169
1170 >
1171 >
1172 > Hi all,
1173 >
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
1179 > intervention.
1180 >
1181 > regards
1182 >
1183 > Alex
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
1190 > stampe.
1191 >
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 > -----------------------------------------------------------------------------
1198 >
1199 > ------------------------------------------------------------------
1200 > To unsubscribe or change your subscription options, visit:
1201 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
1202 >
1203
1204
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>
1213
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
1220 > in use).
1221
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
1223
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>
1230
1231
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
1234 >>possible?
1235 >>How can I make it so that if the main Services goes down, a backup can
1236 take
1237 >>over?
1238
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.
1244
1245 Whe have already created a small script to downloading the xml dump from the
1246 online
1247 ircservices and that create  a complet new database on the backup
1248 ircservices
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
1251 the ircd servers
1252 not can't connect again.
1253 if you are intrested for the script mail me and i will send it to you Andrew
1254
1255
1256
1257
1258
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>
1265
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...
1273
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
1276 script?  Thanks
1277
1278 Saturn
1279
1280
1281
1282
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>
1289
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...
1297
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....
1301
1302 user usernamehere passwordhere
1303 cd servicesdir/data/
1304 mget *.db
1305 bye
1306
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`
1310
1311 3) you can now tar/gzip the newly downloaded .dbs
1312
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
1318 keys, etc.
1319
1320 David
1321
1322
1323 Quoth Saturn on Jan 6 at 13:59,
1324
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...
1332 >
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
1335 > script?  Thanks
1336 >
1337 > Saturn
1338 >
1339 >
1340 >
1341 > ------------------------------------------------------------------
1342 > To unsubscribe or change your subscription options, visit:
1343 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
1344 >
1345
1346
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>
1352
1353 Use a crontab.
1354
1355 I cant really see services needing this, especially when its easier and possibly more configurable to use a crontab and a small script.
1356
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 -----------------------------------------------------------------------
1362
1363
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>
1372
1373 This kind of thing is best left upto shell scripts.  I'd highly recommend
1374 using rsync over FTP for two reasons:
1375
1376 1.  It's secure.  All file transfers are performed over ssh by default.
1377
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.
1381
1382
1383 Regards,
1384 Aragon
1385
1386
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...
1396 >
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
1399 > script?  Thanks
1400 >
1401 > Saturn
1402
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>
1410
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.
1414 This way we avoid:
1415
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
1418 mailinglist
1419
1420 Alex
1421
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.
1427 >
1428 > David
1429 >
1430 >
1431 > Quoth Ciappei Alessandro (las3r) on Jan 6 at 11:52,
1432 >
1433 >>
1434 >>
1435 >> Hi all,
1436 >>
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
1442 >> intervention.
1443 >>
1444 >> regards
1445 >>
1446 >> Alex
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
1453 >> stampe.
1454 >>
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 >> -----------------------------------------------------------------------------
1461
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>
1467
1468 Some people would consider that as spam...
1469
1470 >
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.
1474 >This way we avoid:
1475 >
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
1478 >mailinglist
1479 >
1480 >Alex
1481 >
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.
1487 >>
1488 >>David
1489 >>
1490 >>
1491 >>Quoth Ciappei Alessandro (las3r) on Jan 6 at 11:52,
1492 >>
1493 >>>
1494 >>>
1495 >>>Hi all,
1496 >>>
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
1502 >>>intervention.
1503 >>>
1504 >>>regards
1505 >>>
1506 >>>Alex
1507 >>>-----------------------------------------------------------------------------
1508 >>>Chi riceve il presente  messaggio e` tenuto a verificare se lo stesso non
1509 >>>gli
1510 >>>sia pervenuto per  errore.  In tal caso e` pregato di avvisare
1511 >>>immediatamente
1512 >>>il mittente  e,  tenuto  conto  delle  responsabilita` connesse
1513 >>>all'indebito
1514 >>>utilizzo e/o  divulgazione  del  messaggio  e/o  delle  informazioni  in
1515 >>>esso
1516 >>>contenute,  voglia  cancellare  l'originale  e distruggere  le varie
1517 >>>copie  o
1518 >>>stampe.
1519 >>>
1520 >>>The receiver  of this message is required to check if  he/she has
1521 >>>received it
1522 >>>erroneously.  If  so,  the  receiver  is  requested to immediately inform
1523 >>>the
1524 >>>sender and - in consideration of the responsibilities  arising from undue
1525 >>>use
1526 >>>and/or disclosure of the message  and/or  the information contained
1527 >>>therein -
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
1533
1534
1535 _________________________________________________________________
1536 Protect your PC - get McAfee.com VirusScan Online
1537 http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
1538
1539
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>
1547
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.
1553 For example:
1554
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
1559
1560 This is then one idea of mine fairies you.
1561
1562 regards
1563
1564 Alex
1565
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:
1569 >
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
1572 > mailinglist
1573 >
1574 > Alex
1575 >
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.
1581 >>
1582 >> David
1583 >>
1584 >>
1585 >> Quoth Ciappei Alessandro (las3r) on Jan 6 at 11:52,
1586 >>
1587 >>>
1588 >>>
1589 >>> Hi all,
1590 >>>
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
1596 >>> intervention.
1597 >>>
1598 >>> regards
1599 >>>
1600 >>> Alex
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
1607 >>> stampe.
1608 >>>
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 >>> -----------------------------------------------------------------------------
1615 >
1616 > --__--__--
1617 >
1618 > Message: 2
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
1624 >
1625 > Some people would consider that as spam...
1626 >
1627 >>
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:
1632 >>
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
1635 >>mailinglist
1636 >>
1637 >>Alex
1638 >>
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.
1644 >>>
1645 >>>David
1646 >>>
1647 >>>
1648 >>>Quoth Ciappei Alessandro (las3r) on Jan 6 at 11:52,
1649 >>>
1650 >>>>
1651 >>>>
1652 >>>>Hi all,
1653 >>>>
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
1659 >>>>intervention.
1660 >>>>
1661 >>>>regards
1662 >>>>
1663 >>>>Alex
1664
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>
1670
1671 Hello All
1672
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
1675
1676 Idea from thebeast
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
1681
1682 Idea from Rodecker
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
1687
1688 Grtzz
1689 Thebeast@xs4all.nl
1690
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>
1696
1697 We should have an operserv command that resets modecount/bouncy_modes etc
1698 for a certain channel (or a chanserv command).
1699
1700 Right now the only way to fix it is to restart services, which is really
1701 silly.
1702
1703
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>
1709
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?
1711
1712 please?
1713
1714 I really need this! :)
1715
1716 Thanksss!!!
1717
1718 Ph33rTheCuteOnes...
1719
1720
1721 ______________________________________________________________________
1722 http://www.mailbox.gr ÁðïêôÞóôå äùñåÜí ôï ìïíáäéêü óáò e-mail.
1723 http://www.thesuperweb.gr ÁðïêôÞóôå ôï äéêü óáò web site ìüíï ìå 6 Euro!
1724
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>
1731
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>
1734
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?
1740
1741
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?
1744 >
1745 > please?
1746 >
1747 > I really need this! :)
1748 >
1749 > Thanksss!!!
1750 >
1751 > Ph33rTheCuteOnes...
1752 >
1753 >
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
1760
1761
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>
1767
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.
1769
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>
1772 >
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?
1778 >
1779 >
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?
1782 >>
1783 >> please?
1784 >>
1785 >> I really need this! :)
1786 >>
1787 >> Thanksss!!!
1788 >>
1789 >> Ph33rTheCuteOnes...
1790 >>
1791 >>
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
1798 >
1799 >------------------------------------------------------------------
1800 >To unsubscribe or change your subscription options, visit:
1801 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
1802
1803
1804
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>
1810
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)
1813
1814 so...
1815
1816 /* Handler for PRIVMSGs. */
1817
1818 static int do_privmsg(const char *source, const char *target, char *buf)
1819 {
1820         send_cmd(ServerName, "PRIVMSG %s :Hello World!", source);
1821         return 1;
1822 }
1823
1824 what's wrong with it? I havn't changed anything else!
1825
1826
1827 ______________________________________________________________________
1828 http://www.mailbox.gr ÁðïêôÞóôå äùñåÜí ôï ìïíáäéêü óáò e-mail.
1829 http://www.thesuperweb.gr ÁðïêôÞóôå ôï äéêü óáò web site ìüíï ìå 6 Euro!
1830
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>
1838
1839 On Wednesday 15 January 2003 01:34 pm, Ph33rTheCuteOnes(...) wrote:
1840 > what's wrong with it? I havn't changed anything else!
1841
1842 its alot more complex than that... did you read the documentation? you have to
1843 run add_callback and stuff
1844
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>
1850
1851 I couldn't understand how it works...
1852 and I couldn't find some sample code...
1853
1854 can you please show me an example?
1855
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...
1858
1859
1860
1861 ______________________________________________________________________
1862 http://www.mailbox.gr ÁðïêôÞóôå äùñåÜí ôï ìïíáäéêü óáò e-mail.
1863 http://www.thesuperweb.gr ÁðïêôÞóôå ôï äéêü óáò web site ìüíï ìå 6 Euro!
1864
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>
1872
1873 On Wednesday 15 January 2003 01:49 pm, Ph33rTheCuteOnes(...) wrote:
1874 > can you please show me an example?
1875
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
1879
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>
1885
1886 I have sirv2.9.0 services databases But I cant convert it to irc-services
1887 5.06
1888
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?
1893
1894
1895 Bu e-mail BayPosta.Com webmail servisi ile g?nderilmektedir.
1896
1897 http://www.bayposta.com
1898
1899 Izhost Hosting Hizmetleri; Ekonomik 4 Paketi, 150 Mb. Web alan?, 50 POP3 mail hesabi %20 indirimli! http://www.izhost.com
1900
1901
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>
1907
1908 I have sirv2.9.0 services databases But I cant convert it to irc-services
1909 5.06
1910
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?
1915
1916
1917 Bu e-mail BayPosta.Com webmail servisi ile g?nderilmektedir.
1918
1919 http://www.bayposta.com
1920
1921 Izhost Hosting Hizmetleri; Ekonomik 4 Paketi, 150 Mb. Web alan?, 50 POP3 mail hesabi %20 indirimli! http://www.izhost.com
1922
1923
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>
1929
1930 With the use of the httpd module can we print in a website the number of the users in a channel???
1931
1932 thanxxx! :)
1933
1934
1935 ______________________________________________________________________
1936 http://www.mailbox.gr ÁðïêôÞóôå äùñåÜí ôï ìïíáäéêü óáò e-mail.
1937 http://www.thesuperweb.gr ÁðïêôÞóôå ôï äéêü óáò web site ìüíï ìå 6 Euro!
1938
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>
1945
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
1949 Unreal3.x
1950
1951
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?
1959
1960
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???
1964
1965 thanxxx! :)
1966
1967
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
1974 ---
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
1978
1979 ---
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
1983
1984
1985
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>
1991
1992 Hi,
1993
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.
1997
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.
2003
2004 Shutting services down gracefully via a SIGTERM or the shutdown command
2005 doesn't have the same effect.  Please look into this...
2006
2007
2008 Thanks,
2009 Aragon
2010
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>
2016
2017 Hi,
2018
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.
2024
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
2027 ircservices starts?
2028
2029
2030 Thanks,
2031 Aragon
2032
2033
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>
2039
2040 Hi,
2041
2042 One more thing.. :)
2043
2044 When adding a GZLINE via ircservices linked to Unreal, the GZLINE is not
2045 added with the reason stipulated to ircservices :
2046
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)
2049
2050 -OperServ- 1.2.3.4 (by Aragon on Jan 16 2003, never used; does not expire)
2051 -OperServ-     test
2052
2053
2054 Thanks,
2055 Aragon
2056
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>
2064
2065 Sorry I meant explicitly, not implicitly :P
2066
2067
2068 | By Aragon Gouveia <aragon@phat.za.net>
2069 |                                          [ 2003-01-16 22:13 +0200 ]
2070 > Hi,
2071 >
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.
2077 >
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?
2081 >
2082 >
2083 > Thanks,
2084 > Aragon
2085 >
2086
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>
2092
2093 How can I change the xxxserv help so it is the same with xxxserv help ?
2094
2095 I want with the xxxserv help to return the list with the commands and not just to say type help commands!
2096
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...
2098
2099 please help!
2100
2101 Thank you!
2102
2103
2104
2105 ______________________________________________________________________
2106 http://www.mailbox.gr ÁðïêôÞóôå äùñåÜí ôï ìïíáäéêü óáò e-mail.
2107 http://www.thesuperweb.gr ÁðïêôÞóôå ôï äéêü óáò web site ìüíï ìå 6 Euro!
2108
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>
2114
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
2118 appreciated
2119 --
2120 www.eroin.net & irc.eroin.net
2121
2122
2123 Bu e-mail BayPosta.Com webmail servisi ile g?nderilmektedir.
2124 http://www.bayposta.com
2125
2126 Izhost Hosting Hizmetleri; Ekonomik 4 Paketi, 150 Mb. Web alan?, 50 POP3 mail hesabi %20 indirimli! http://www.izhost.com
2127
2128
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>
2134
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?
2137
2138
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>
2144
2145 How can I change the xxxserv help so it is the same with xxxserv help ?
2146
2147 I want with the xxxserv help to return the list with the commands and not just to say type help commands!
2148
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...
2150
2151 please help!
2152
2153 Thank you!
2154
2155
2156
2157 ______________________________________________________________________
2158 http://www.mailbox.gr ÁðïêôÞóôå äùñåÜí ôï ìïíáäéêü óáò e-mail.
2159 http://www.thesuperweb.gr ÁðïêôÞóôå ôï äéêü óáò web site ìüíï ìå 6 Euro!
2160
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>
2166
2167 Where is the log function that operserv and the services call in order to
2168 write somthing it the .log file?
2169
2170 Can this be altered to it also send the error to a channel?
2171
2172 Do I have to create a psudoclient first or can it send directly to the channel?
2173
2174 Thank you very much!
2175
2176
2177 ______________________________________________________________________
2178 http://www.mailbox.gr ÁðïêôÞóôå äùñåÜí ôï ìïíáäéêü óáò e-mail.
2179 http://www.thesuperweb.gr ÁðïêôÞóôå ôï äéêü óáò web site ìüíï ìå 6 Euro!
2180
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>
2188
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?
2192
2193 module_log
2194
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>
2200
2201 I've been experiencing some instability in IRCservices for several times
2202 relating an unknown error that i still didnt figure it out.
2203
2204 Anyway, I didn't have the time to look over the source.
2205
2206 The .log shows:
2207
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
2211
2212 What can I do ?
2213
2214 Pedro Ribeiro
2215
2216 --------------------------------------
2217 eXaur
2218
2219
2220
2221
2222 _________________________________________________________________
2223 Tired of spam? Get advanced junk mail protection with MSN 8.
2224 http://join.msn.com/?page=features/junkmail
2225
2226
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>
2233
2234 >How can I change the xxxserv help so it is the same with xxxserv help ?
2235 >
2236 >I want with the xxxserv help to return the list with the commands and not just to say type help commands!
2237
2238      The HELP COMMANDS text is dynamically generated.  You'll have to edit
2239 the source code if you want to do this.
2240
2241   --Andrew Church
2242     achurch@achurch.org
2243     http://achurch.org/
2244
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>
2251
2252 >Where is the log function that operserv and the services call in order to
2253 >write somthing it the .log file?
2254
2255      The logging functions are in log.c.
2256
2257 >Can this be altered to it also send the error to a channel?
2258
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).
2261
2262 >Do I have to create a psudoclient first or can it send directly to the channel?
2263
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.
2267
2268   --Andrew Church
2269     achurch@achurch.org
2270     http://achurch.org/
2271
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>
2278
2279 >I have sirv2.9.0 services databases But I cant convert it to irc-services
2280 >5.06
2281 >
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
2284 >databases
2285
2286      Send me (privately) a copy of your database files and I'll take a
2287 look into it.
2288
2289   --Andrew Church
2290     achurch@achurch.org
2291     http://achurch.org/
2292
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>
2299
2300 RTFM (FAQ C.3).
2301
2302   --Andrew Church
2303     achurch@achurch.org
2304     http://achurch.org/
2305
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
2309 >appreciated
2310 >--
2311 >www.eroin.net & irc.eroin.net
2312 >
2313 >
2314 >Bu e-mail BayPosta.Com webmail servisi ile gönderilmektedir.
2315 >http://www.bayposta.com
2316 >
2317 >Izhost Hosting Hizmetleri; Ekonomik 4 Paketi, 150 Mb. Web alaný, 50 POP3 mail hesabi %20 indirimli! http://www.izhost.com
2318 >
2319 >------------------------------------------------------------------
2320 >To unsubscribe or change your subscription options, visit:
2321 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
2322
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>
2329
2330 >I've been experiencing some instability in IRCservices for several times
2331 >relating an unknown error that i still didnt figure it out.
2332 >
2333 >Anyway, I didn't have the time to look over the source.
2334 >
2335 >The .log shows:
2336 >
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
2340 >
2341 >What can I do ?
2342
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.
2346
2347   --Andrew Church
2348     achurch@achurch.org
2349     http://achurch.org/
2350
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>
2357
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.
2361
2362      Fixed, thanks for the report.
2363
2364   --Andrew Church
2365     achurch@achurch.org
2366     http://achurch.org/
2367
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>
2374
2375 >Hi,
2376 >
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.
2382 >
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?
2386
2387      It was supposed to work this way already, but my logic was messed up.
2388 Fixed, thanks for the report.
2389
2390   --Andrew Church
2391     achurch@achurch.org
2392     http://achurch.org/
2393
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>
2400
2401 >Hi,
2402 >
2403 >One more thing.. :)
2404 >
2405 >When adding a GZLINE via ircservices linked to Unreal, the GZLINE is not
2406 >added with the reason stipulated to ircservices :
2407 >
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)
2410 >
2411 >-OperServ- 1.2.3.4 (by Aragon on Jan 16 2003, never used; does not expire)
2412 >-OperServ-     test
2413
2414      Check your modules.conf (SZlineReason).
2415
2416   --Andrew Church
2417     achurch@achurch.org
2418     http://achurch.org/
2419
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>
2427
2428 Aah, doh.  Thanks. :)
2429
2430
2431 | By Andrew Church <achurch@achurch.org>
2432 |                                          [ 2003-01-23 07:44 +0200 ]
2433 > >Hi,
2434 > >
2435 > >One more thing.. :)
2436 > >
2437 > >When adding a GZLINE via ircservices linked to Unreal, the GZLINE is not
2438 > >added with the reason stipulated to ircservices :
2439 > >
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)
2442 > >
2443 > >-OperServ- 1.2.3.4 (by Aragon on Jan 16 2003, never used; does not expire)
2444 > >-OperServ-     test
2445 >
2446 >      Check your modules.conf (SZlineReason).
2447 >
2448 >   --Andrew Church
2449 >     achurch@achurch.org
2450 >     http://achurch.org/
2451
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>
2459
2460 Thanks.  For both fixes. :)
2461
2462
2463 | By Andrew Church <achurch@achurch.org>
2464 |                                          [ 2003-01-23 07:43 +0200 ]
2465 > >Hi,
2466 > >
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.
2472 > >
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?
2476 >
2477 >      It was supposed to work this way already, but my logic was messed up.
2478 > Fixed, thanks for the report.
2479 >
2480 >   --Andrew Church
2481 >     achurch@achurch.org
2482 >     http://achurch.org/
2483
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>
2489
2490 Hi,
2491
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 :)
2500
2501 Georges
2502
2503
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>
2510
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) ?
2514
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.
2518
2519   --Andrew Church
2520     achurch@achurch.org
2521     http://achurch.org/
2522
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>
2529
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 :)
2533
2534 Georges
2535
2536 -----Urspr?ngliche Nachricht-----
2537 Von: ircservices-coding-admin@ircservices.za.net
2538 [mailto:ircservices-coding-admin@ircservices.za.net] Im Auftrag von
2539 Andrew Church
2540 Gesendet: Donnerstag, 23. Januar 2003 10:10
2541 An: ircservices-coding@ircservices.za.net
2542 Betreff: Re: [IRCServices Coding] Timeouts
2543
2544
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) ?
2548
2549      You shouldn't need to loop through them; the routine called when
2550 the
2551 timeout occurs and the arbitrary data passed to it are all you should
2552 need
2553 to know.  If you need anything else then you need to use a better
2554 design.
2555
2556   --Andrew Church
2557     achurch@achurch.org
2558     http://achurch.org/
2559 ------------------------------------------------------------------
2560 To unsubscribe or change your subscription options, visit:
2561 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
2562
2563
2564
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>
2571
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 :)
2575
2576      You have the pointer returned from add_timeout(); just store it
2577 somewhere.  (This is what the code actually does.)
2578
2579   --Andrew Church
2580     achurch@achurch.org
2581     http://achurch.org/
2582
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>
2588
2589 hello everybody
2590
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...
2593
2594     what encription is used on convert-db?
2595
2596     tks
2597
2598
2599 lordao - Stefan Horochovec
2600 Francisco Beltrao, PR - Brazil
2601
2602
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>
2608
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
2610 @find.
2611
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."
2615
2616 Other people have also had problems with this.
2617
2618
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>
2625
2626 using /kill for channel reasons? that sound mature...
2627
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
2633
2634
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
2637 @find.
2638
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."
2644
2645 Other people have also had problems with this.
2646
2647 ------------------------------------------------------------------
2648 To unsubscribe or change your subscription options, visit:
2649 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
2650
2651
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>
2658
2659 spamming the mailing list with your opinions? thats mature...
2660
2661 < >On Thu, 23 Jan 2003 17:28:32 -0000, Martin J. Green wrote:
2662 < > using /kill for channel reasons? that sound mature...
2663 < >
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
2669 < >
2670 < >
2671 < > When sending a global notice, such as the following, if its to
2672 < > long a : gets
2673 < > inserted into it, you can see it got inserted right before
2674 < > @find.
2675 < >
2676 < > "We would like to remind everyone if you ever have trouble
2677 < > connecting you
2678 < > should contact an oper. You should never have trouble
2679 < > connecting while using irc.linkirc.net to connect. In addition
2680 < > an anti lamer
2681 < > device has been added to #linkirc. Anyone who comes
2682 < > in to #linkirc and types !list or :@find gets a complimentary
2683 < > kill."
2684 < >
2685 < > Other people have also had problems with this.
2686 < >
2687 < > -----------------------------------------------------------------
2688 < > -
2689 < > To unsubscribe or change your subscription options, visit:
2690 < > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
2691 < >
2692 < > -----------------------------------------------------------------
2693 < > -
2694 < > To unsubscribe or change your subscription options, visit:
2695 < > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
2696
2697
2698
2699
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>
2706
2707 technically spamming is unsolicited bulk e-mail. flaming perhaps, but
2708 spamming....
2709
2710 Anyone who misuses /kill needs any raped by a black felon named bubba. I bet
2711 you run unreal too...
2712
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
2718
2719
2720 spamming the mailing list with your opinions? thats mature...
2721
2722 < >On Thu, 23 Jan 2003 17:28:32 -0000, Martin J. Green wrote:
2723 < > using /kill for channel reasons? that sound mature...
2724 < >
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
2730 < >
2731 < >
2732 < > When sending a global notice, such as the following, if its to
2733 < > long a : gets
2734 < > inserted into it, you can see it got inserted right before
2735 < > @find.
2736 < >
2737 < > "We would like to remind everyone if you ever have trouble
2738 < > connecting you
2739 < > should contact an oper. You should never have trouble
2740 < > connecting while using irc.linkirc.net to connect. In addition
2741 < > an anti lamer
2742 < > device has been added to #linkirc. Anyone who comes
2743 < > in to #linkirc and types !list or :@find gets a complimentary
2744 < > kill."
2745 < >
2746 < > Other people have also had problems with this.
2747 < >
2748 < > -----------------------------------------------------------------
2749 < > -
2750 < > To unsubscribe or change your subscription options, visit:
2751 < > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
2752 < >
2753 < > -----------------------------------------------------------------
2754 < > -
2755 < > To unsubscribe or change your subscription options, visit:
2756 < > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
2757
2758
2759
2760 ------------------------------------------------------------------
2761 To unsubscribe or change your subscription options, visit:
2762 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
2763
2764
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>
2771
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.
2774 End of story
2775
2776
2777 spam    P   Pronunciation Key  (spm)
2778 n.
2779
2780 Unsolicited e-mail, often of a commercial nature, sent indiscriminately to multiple mailing lists, individuals, or newsgroups; junk e-
2781 mail.
2782
2783
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>
2789
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.
2791
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 -----------------------------------------------------------------------
2797
2798
2799 ============ Original Message ============
2800 >From     : "RT.Mail" <RT.Mail@verizon.net>
2801 >Reply-To :
2802 >To       :
2803 >Subject  : Re: [IRCServices Coding] globla message
2804 >Date     : 2003-01-23
2805 >
2806 >spamming the mailing list with your opinions? thats mature...
2807 >
2808 >< >On Thu, 23 Jan 2003 17:28:32 -0000, Martin J. Green wrote:
2809 >< > using /kill for channel reasons? that sound mature...
2810 >< >
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
2816 >< >
2817 >< >
2818 >< > When sending a global notice, such as the following, if its to
2819 >< > long a : gets
2820 >< > inserted into it, you can see it got inserted right before
2821 >< > @find.
2822 >< >
2823 >< > "We would like to remind everyone if you ever have trouble
2824 >< > connecting you
2825 >< > should contact an oper. You should never have trouble
2826 >< > connecting while using irc.linkirc.net to connect. In addition
2827 >< > an anti lamer
2828 >< > device has been added to #linkirc. Anyone who comes
2829 >< > in to #linkirc and types !list or :@find gets a complimentary
2830 >< > kill."
2831 >< >
2832 >< > Other people have also had problems with this.
2833 >< >
2834 >< > -----------------------------------------------------------------
2835 >< > -
2836 >< > To unsubscribe or change your subscription options, visit:
2837 >< > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
2838 >< >
2839 >< > -----------------------------------------------------------------
2840 >< > -
2841 >< > To unsubscribe or change your subscription options, visit:
2842 >< > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
2843 >
2844 >
2845 >
2846 >------------------------------------------------------------------
2847 >To unsubscribe or change your subscription options, visit:
2848 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
2849 >.
2850
2851 ========= End of Original Message =========
2852
2853
2854
2855
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>
2863
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
2867 > spamming....
2868 >
2869 > Anyone who misuses /kill needs any raped by a black felon named bubba. I bet
2870 > you run unreal too...
2871
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.
2874
2875
2876 Regards,
2877 Aragon
2878
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>
2885
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.
2889 >
2890 >"We would like to remind everyone if you ever have trouble
2891 >connecting you should contact an oper. You should never have
2892 >trouble
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
2896 >kill."
2897
2898      I can't reproduce this.  Are you sure this isn't an ircd or script
2899 issue?
2900
2901   --Andrew Church
2902     achurch@achurch.org
2903     http://achurch.org/
2904
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>
2911
2912 it wasn't reproduced on my network either.
2913
2914 ~Ganja51
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
2920
2921
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.
2925 > >
2926 > >"We would like to remind everyone if you ever have trouble
2927 > >connecting you should contact an oper. You should never have
2928 > >trouble
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
2932 > >kill."
2933 >
2934 >      I can't reproduce this.  Are you sure this isn't an ircd or script
2935 > issue?
2936 >
2937 >   --Andrew Church
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
2943
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>
2949
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.
2951
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 -----------------------------------------------------------------------
2957
2958
2959 ============ Original Message ============
2960 >From     : "Ganja51" <Ganja51@lcirc.net>
2961 >Reply-To :
2962 >To       :
2963 >Subject  : Re: [IRCServices Coding] globla message
2964 >Date     : 2003-01-23
2965 >
2966 >it wasn't reproduced on my network either.
2967 >
2968 >~Ganja51
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
2974 >
2975 >
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.
2979 >> >
2980 >> >"We would like to remind everyone if you ever have trouble
2981 >> >connecting you should contact an oper. You should never have
2982 >> >trouble
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
2986 >> >kill."
2987 >>
2988 >>      I can't reproduce this.  Are you sure this isn't an ircd or script
2989 >> issue?
2990 >>
2991 >>   --Andrew Church
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
3000 >.
3001
3002 ========= End of Original Message =========
3003
3004
3005
3006
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>
3014
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.
3018
3019 If /os global doesn't work, there might be a wrong value for
3020 set::services-server...
3021
3022 --
3023 Krisztian Romek
3024 r-krisztian@softhome.net
3025
3026
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>
3032
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.
3034
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 -----------------------------------------------------------------------
3040
3041
3042 ============ Original Message ============
3043 >From     : "Krisztian Romek" <r-krisztian@softhome.net>
3044 >Reply-To :
3045 >To       :
3046 >Subject  : Re: Re: [IRCServices Coding] globla message
3047 >Date     : 2003-01-24
3048 >
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.
3052 >
3053 >If /os global doesn't work, there might be a wrong value for
3054 >set::services-server...
3055 >
3056 >--
3057 >Krisztian Romek
3058 >r-krisztian@softhome.net
3059 >
3060 >------------------------------------------------------------------
3061 >To unsubscribe or change your subscription options, visit:
3062 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
3063 >.
3064
3065 ========= End of Original Message =========
3066
3067
3068
3069
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>
3075
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.
3086
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.
3095
3096 Just a few suggestions which I think would help out a ton. Thanks for your
3097 time.
3098
3099 ~Ganja51
3100
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>
3107
3108      Try SGLINE with SQlineKill (modules.conf).
3109
3110   --Andrew Church
3111     achurch@achurch.org
3112     http://achurch.org/
3113
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
3116 >ll
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
3123 >ll
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.
3126 >
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
3134 >e
3135 >the same random word/number generated for both the ident and realname.
3136 >
3137 >Just a few suggestions which I think would help out a ton. Thanks for you
3138 >r
3139 >time.
3140 >
3141 >~Ganja51
3142 >
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>
3151
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.
3154
3155 ----------------------------------------------------------------------------
3156 Russ Garrett                                             russ@garrett.co.uk.
3157                                                   http://russ.garrett.co.uk.
3158
3159
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>
3167
3168 Didn't even know 5.0.7 was out, let alone 5.0.9.  Thanks for pointing it
3169 out!
3170
3171
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.
3176 >
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>
3188
3189 Hi,
3190
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. :)
3193
3194
3195 Regards,
3196 Aragon
3197
3198
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
3202 > out!
3203 >
3204 >
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.
3209 > >
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>
3218
3219 Hi,
3220
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)
3224
3225 Has this been done yet?
3226
3227 cant check myself...
3228
3229 Forbidden
3230 You don't have permission to access /Changes on this server.
3231
3232 Apache/1.3.27 Server at www.ircservices.za.net Port 80
3233
3234
3235 Best Regards
3236
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>
3242
3243 Hi,
3244
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...
3247
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! :)
3254
3255 Running Unreal 3.2 btw.
3256
3257
3258 Regards,
3259 Aragon
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>
3266
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).
3271
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.
3274
3275 Off the top of my head:
3276
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
3279 127.0.0.1:7029),
3280
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),
3284
3285 3) Tried running services 'plain' from the commandline rather than from a
3286
3287 start-stop-daemon --start --quiet --pidfile
3288 /usr/local/lib/ircservices/ircservices.pid \
3289                   --chuid irc:irc --exec /usr/local/sbin/ircservices >
3290 /dev/null 2>&1
3291
3292 in a Debian /etc/init.d script.
3293
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.
3301
3302 ________________________________________________________________
3303 Matthew Hodgson   arathorn@theonering.net   Tel: +44 7968 722968
3304              Arathorn: Co-Sysadmin, TheOneRing.net?
3305
3306
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
3312
3313
3314 > Hi,
3315 >
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...
3318 >
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
3321 SIGTERM
3322 > to the process after the uplink has died only results in "Received
3323 SIGTERM,
3324 > exiting." being logged, but the process does not die.  It takes a SIGKILL
3325 to
3326 > kill it off.  And of course a SIGKILL doesn't go down well with saving the
3327 > database to disk! :)
3328 >
3329 > Running Unreal 3.2 btw.
3330 >
3331 >
3332 > Regards,
3333 > Aragon
3334 > ------------------------------------------------------------------
3335 > To unsubscribe or change your subscription options, visit:
3336 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
3337
3338
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>
3347
3348 I can definately reproduce it.  It happens every time.
3349
3350 I'm also connecting to localhost (from localhost) to a specified port.  I
3351 haven't defined a binding port though.
3352
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.. :)
3355
3356
3357 Thanks,
3358 Aragon
3359
3360
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).
3367 >
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.
3370 >
3371 > Off the top of my head:
3372 >
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
3375 > 127.0.0.1:7029),
3376 >
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),
3380 >
3381 > 3) Tried running services 'plain' from the commandline rather than from a
3382 >
3383 > start-stop-daemon --start --quiet --pidfile
3384 > /usr/local/lib/ircservices/ircservices.pid \
3385 >                   --chuid irc:irc --exec /usr/local/sbin/ircservices >
3386 > /dev/null 2>&1
3387 >
3388 > in a Debian /etc/init.d script.
3389 >
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.
3397 >
3398 > ________________________________________________________________
3399 > Matthew Hodgson   arathorn@theonering.net   Tel: +44 7968 722968
3400 >              Arathorn: Co-Sysadmin, TheOneRing.net?
3401 >
3402 >
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
3408 >
3409 >
3410 > > Hi,
3411 > >
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...
3414 > >
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
3417 > SIGTERM
3418 > > to the process after the uplink has died only results in "Received
3419 > SIGTERM,
3420 > > exiting." being logged, but the process does not die.  It takes a SIGKILL
3421 > to
3422 > > kill it off.  And of course a SIGKILL doesn't go down well with saving the
3423 > > database to disk! :)
3424 > >
3425 > > Running Unreal 3.2 btw.
3426 > >
3427 > >
3428 > > Regards,
3429 > > Aragon
3430 > > ------------------------------------------------------------------
3431 > > To unsubscribe or change your subscription options, visit:
3432 > > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
3433 >
3434 >
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>
3444
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
3446 kept running.
3447
3448 < >On Tue, 11 Feb 2003 00:24:48 +0200, Aragon Gouveia wrote:
3449 < > I can definately reproduce it.  It happens every time.
3450 < >
3451 < > I'm also connecting to localhost (from localhost) to a specified
3452 < > port.  I
3453 < > haven't defined a binding port though.
3454 < >
3455 < > Can anyone help me debug this?  Can attach to a running process
3456 < > with gdb,
3457 < > but from there I'm not sure what I should be doing.. :)
3458 < >
3459 < >
3460 < > Thanks,
3461 < > Aragon
3462 < >
3463 < >
3464 < > | By Arathorn <arathorn@theonering.net>
3465 < > |                                          [ 2003-02-10 23:43
3466 < > +0200 ]
3467 < > > I've had this problem too (although I cannot reproduce it at
3468 < > the moment) -
3469 < > > I've reported it on the non-coding list.  Andrew's suggestion
3470 < > there is to
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).
3474 < > >
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
3478 < > helped.
3479 < > >
3480 < > > Off the top of my head:
3481 < > >
3482 < > > 1) I changed services to connect to unreal 3.2 on localhost -
3483 < > explicitly
3484 < > > specifying the binding port (i.e. connecting from
3485 < > 127.0.0.1:7028 to
3486 < > > 127.0.0.1:7029),
3487 < > >
3488 < > > 2) enabled a PingFrequency of 30s across the link to try to
3489 < > keep things
3490 < > > alive and healthy (i've also had problems with 3.2 complaining
3491 < > about Bad
3492 < > > File Descriptors on the Services socket when select()ing the
3493 < > FDLIST),
3494 < > >
3495 < > > 3) Tried running services 'plain' from the commandline rather
3496 < > than from a
3497 < > >
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
3503 < > >
3504 < > > in a Debian /etc/init.d script.
3505 < > >
3506 < > > Somewhere along there, it's decided to start behaving
3507 < > absolutely fine (after
3508 < > > consistently hanging after the ircd closed its connection).
3509 < > Services die
3510 < > > cleanly on a /restart and /die work fine - and for that
3511 < > matter, so does
3512 < > > /operserv restart, quit & shutdown.  With the proviso of some
3513 < > thoroughly
3514 < > > screwed up intermittent faults with +k modelocks disappearing
3515 < > on registered
3516 < > > channels after services restarts - and xml-export doing some
3517 < > very mangled
3518 < > > things. c.f. ircservices@ircservices.za.net.
3519 < > >
3520 < > >
3521 < > ________________________________________________________________
3522 < > > Matthew Hodgson   arathorn@theonering.net   Tel: +44 7968
3523 < > 722968
3524 < > >       Arathorn: Co-Sysadmin, TheOneRing.net?
3525 < > >
3526 < > >
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
3532 < > >
3533 < > >
3534 < > > > Hi,
3535 < > > >
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
3539 < > problem...
3540 < > > >
3541 < > > > When the uplink server closes the connection ircservices
3542 < > does not exit.
3543 < > > > Neither is there any log of such activity.  Further more,
3544 < > issuing a
3545 < > > SIGTERM
3546 < > > > to the process after the uplink has died only results in
3547 < > "Received
3548 < > > SIGTERM,
3549 < > > > exiting." being logged, but the process does not die.  It
3550 < > takes a SIGKILL
3551 < > > to
3552 < > > > kill it off.  And of course a SIGKILL doesn't go down well
3553 < > with saving the
3554 < > > > database to disk! :)
3555 < > > >
3556 < > > > Running Unreal 3.2 btw.
3557 < > > >
3558 < > > >
3559 < > > > Regards,
3560 < > > > Aragon
3561 < > > > -------------------------------------------------------------
3562 < > -----
3563 < > > > To unsubscribe or change your subscription options, visit:
3564 < > > > http://www.ircservices.za.net/mailman/listinfo/ircservices-
3565 < > coding
3566 < > >
3567 < > >
3568 < > > ---------------------------------------------------------------
3569 < > ---
3570 < > > To unsubscribe or change your subscription options, visit:
3571 < > > http://www.ircservices.za.net/mailman/listinfo/ircservices-
3572 < > coding
3573 < > -----------------------------------------------------------------
3574 < > -
3575 < > To unsubscribe or change your subscription options, visit:
3576 < > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
3577
3578
3579
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>
3585
3586
3587 I don't know if this topic has been discussed, so please pardon me if it has.
3588
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)
3590
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.
3592
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.
3594
3595 {Example}
3596
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.
3604
3605
3606 Comments anyone?
3607
3608 John Edrington
3609 john@cosmicfire.net
3610
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>
3617
3618      This is being considered for a future version, but is fairly low on
3619 the priority list.
3620
3621   --Andrew Church
3622     achurch@achurch.org
3623     http://achurch.org/
3624
3625 >Hi,
3626 >
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)
3630 >
3631 >Has this been done yet?
3632 >
3633 >cant check myself...
3634 >
3635 >Forbidden
3636 >You don't have permission to access /Changes on this server.
3637 >
3638 >Apache/1.3.27 Server at www.ircservices.za.net Port 80
3639 >
3640 >
3641 >Best Regards
3642 >
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>
3652
3653      This has been discussed before; it's designed behavior.
3654
3655   --Andrew Church
3656     achurch@achurch.org
3657     http://achurch.org/
3658
3659 >
3660 >I don't know if this topic has been discussed, so please pardon me if it
3661 >has.
3662 >
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)
3666 >
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.
3671 >
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.
3675 >
3676 >{Example}
3677 >
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.
3687 >
3688 >
3689 >Comments anyone?
3690 >
3691 >John Edrington
3692 >john@cosmicfire.net
3693 >
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>
3703
3704 Hello;
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.
3708
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
3715
3716
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
3719 kept running.
3720
3721 < >On Tue, 11 Feb 2003 00:24:48 +0200, Aragon Gouveia wrote:
3722 < > I can definately reproduce it.  It happens every time.
3723 < >
3724 < > I'm also connecting to localhost (from localhost) to a specified
3725 < > port.  I
3726 < > haven't defined a binding port though.
3727 < >
3728 < > Can anyone help me debug this?  Can attach to a running process
3729 < > with gdb,
3730 < > but from there I'm not sure what I should be doing.. :)
3731 < >
3732 < >
3733 < > Thanks,
3734 < > Aragon
3735 < >
3736 < >
3737 < > | By Arathorn <arathorn@theonering.net>
3738 < > |                                          [ 2003-02-10 23:43
3739 < > +0200 ]
3740 < > > I've had this problem too (although I cannot reproduce it at
3741 < > the moment) -
3742 < > > I've reported it on the non-coding list.  Andrew's suggestion
3743 < > there is to
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).
3747 < > >
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
3751 < > helped.
3752 < > >
3753 < > > Off the top of my head:
3754 < > >
3755 < > > 1) I changed services to connect to unreal 3.2 on localhost -
3756 < > explicitly
3757 < > > specifying the binding port (i.e. connecting from
3758 < > 127.0.0.1:7028 to
3759 < > > 127.0.0.1:7029),
3760 < > >
3761 < > > 2) enabled a PingFrequency of 30s across the link to try to
3762 < > keep things
3763 < > > alive and healthy (i've also had problems with 3.2 complaining
3764 < > about Bad
3765 < > > File Descriptors on the Services socket when select()ing the
3766 < > FDLIST),
3767 < > >
3768 < > > 3) Tried running services 'plain' from the commandline rather
3769 < > than from a
3770 < > >
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
3776 < > >
3777 < > > in a Debian /etc/init.d script.
3778 < > >
3779 < > > Somewhere along there, it's decided to start behaving
3780 < > absolutely fine (after
3781 < > > consistently hanging after the ircd closed its connection).
3782 < > Services die
3783 < > > cleanly on a /restart and /die work fine - and for that
3784 < > matter, so does
3785 < > > /operserv restart, quit & shutdown.  With the proviso of some
3786 < > thoroughly
3787 < > > screwed up intermittent faults with +k modelocks disappearing
3788 < > on registered
3789 < > > channels after services restarts - and xml-export doing some
3790 < > very mangled
3791 < > > things. c.f. ircservices@ircservices.za.net.
3792 < > >
3793 < > >
3794 < > ________________________________________________________________
3795 < > > Matthew Hodgson   arathorn@theonering.net   Tel: +44 7968
3796 < > 722968
3797 < > >       Arathorn: Co-Sysadmin, TheOneRing.net?
3798 < > >
3799 < > >
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
3805 < > >
3806 < > >
3807 < > > > Hi,
3808 < > > >
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
3812 < > problem...
3813 < > > >
3814 < > > > When the uplink server closes the connection ircservices
3815 < > does not exit.
3816 < > > > Neither is there any log of such activity.  Further more,
3817 < > issuing a
3818 < > > SIGTERM
3819 < > > > to the process after the uplink has died only results in
3820 < > "Received
3821 < > > SIGTERM,
3822 < > > > exiting." being logged, but the process does not die.  It
3823 < > takes a SIGKILL
3824 < > > to
3825 < > > > kill it off.  And of course a SIGKILL doesn't go down well
3826 < > with saving the
3827 < > > > database to disk! :)
3828 < > > >
3829 < > > > Running Unreal 3.2 btw.
3830 < > > >
3831 < > > >
3832 < > > > Regards,
3833 < > > > Aragon
3834 < > > > -------------------------------------------------------------
3835 < > -----
3836 < > > > To unsubscribe or change your subscription options, visit:
3837 < > > > http://www.ircservices.za.net/mailman/listinfo/ircservices-
3838 < > coding
3839 < > >
3840 < > >
3841 < > > ---------------------------------------------------------------
3842 < > ---
3843 < > > To unsubscribe or change your subscription options, visit:
3844 < > > http://www.ircservices.za.net/mailman/listinfo/ircservices-
3845 < > coding
3846 < > -----------------------------------------------------------------
3847 < > -
3848 < > To unsubscribe or change your subscription options, visit:
3849 < > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
3850
3851
3852
3853 ------------------------------------------------------------------
3854 To unsubscribe or change your subscription options, visit:
3855 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
3856
3857
3858 ---
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
3862
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>
3868
3869 Hello!
3870 I have a some problem
3871
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
3876
3877 I am using ircservices 5.0.6
3878 Can you help me?
3879 Thanks
3880
3881
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>
3888
3889      Fixed, thanks (to you and everyone else who reported it) for the
3890 report.
3891
3892   --Andrew Church
3893     achurch@achurch.org
3894     http://achurch.org/
3895
3896 >Hello;
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.
3900 >
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
3907 >
3908 >
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
3911 >kept running.
3912 >
3913 >< >On Tue, 11 Feb 2003 00:24:48 +0200, Aragon Gouveia wrote:
3914 >< > I can definately reproduce it.  It happens every time.
3915 >< >
3916 >< > I'm also connecting to localhost (from localhost) to a specified
3917 >< > port.  I
3918 >< > haven't defined a binding port though.
3919 >< >
3920 >< > Can anyone help me debug this?  Can attach to a running process
3921 >< > with gdb,
3922 >< > but from there I'm not sure what I should be doing.. :)
3923 >< >
3924 >< >
3925 >< > Thanks,
3926 >< > Aragon
3927 >< >
3928 >< >
3929 >< > | By Arathorn <arathorn@theonering.net>
3930 >< > |                                          [ 2003-02-10 23:43
3931 >< > +0200 ]
3932 >< > > I've had this problem too (although I cannot reproduce it at
3933 >< > the moment) -
3934 >< > > I've reported it on the non-coding list.  Andrew's suggestion
3935 >< > there is to
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).
3939 >< > >
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
3943 >< > helped.
3944 >< > >
3945 >< > > Off the top of my head:
3946 >< > >
3947 >< > > 1) I changed services to connect to unreal 3.2 on localhost -
3948 >< > explicitly
3949 >< > > specifying the binding port (i.e. connecting from
3950 >< > 127.0.0.1:7028 to
3951 >< > > 127.0.0.1:7029),
3952 >< > >
3953 >< > > 2) enabled a PingFrequency of 30s across the link to try to
3954 >< > keep things
3955 >< > > alive and healthy (i've also had problems with 3.2 complaining
3956 >< > about Bad
3957 >< > > File Descriptors on the Services socket when select()ing the
3958 >< > FDLIST),
3959 >< > >
3960 >< > > 3) Tried running services 'plain' from the commandline rather
3961 >< > than from a
3962 >< > >
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
3968 >< > >
3969 >< > > in a Debian /etc/init.d script.
3970 >< > >
3971 >< > > Somewhere along there, it's decided to start behaving
3972 >< > absolutely fine (after
3973 >< > > consistently hanging after the ircd closed its connection).
3974 >< > Services die
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
3978 >< > thoroughly
3979 >< > > screwed up intermittent faults with +k modelocks disappearing
3980 >< > on registered
3981 >< > > channels after services restarts - and xml-export doing some
3982 >< > very mangled
3983 >< > > things. c.f. ircservices@ircservices.za.net.
3984 >< > >
3985 >< > >
3986 >< > ________________________________________________________________
3987 >< > > Matthew Hodgson   arathorn@theonering.net   Tel: +44 7968
3988 >< > 722968
3989 >< > >       Arathorn: Co-Sysadmin, TheOneRing.net?
3990 >< > >
3991 >< > >
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
3997 >< > >
3998 >< > >
3999 >< > > > Hi,
4000 >< > > >
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
4004 >< > problem...
4005 >< > > >
4006 >< > > > When the uplink server closes the connection ircservices
4007 >< > does not exit.
4008 >< > > > Neither is there any log of such activity.  Further more,
4009 >< > issuing a
4010 >< > > SIGTERM
4011 >< > > > to the process after the uplink has died only results in
4012 >< > "Received
4013 >< > > SIGTERM,
4014 >< > > > exiting." being logged, but the process does not die.  It
4015 >< > takes a SIGKILL
4016 >< > > to
4017 >< > > > kill it off.  And of course a SIGKILL doesn't go down well
4018 >< > with saving the
4019 >< > > > database to disk! :)
4020 >< > > >
4021 >< > > > Running Unreal 3.2 btw.
4022 >< > > >
4023 >< > > >
4024 >< > > > Regards,
4025 >< > > > Aragon
4026 >< > > > -------------------------------------------------------------
4027 >< > -----
4028 >< > > > To unsubscribe or change your subscription options, visit:
4029 >< > > > http://www.ircservices.za.net/mailman/listinfo/ircservices-
4030 >< > coding
4031 >< > >
4032 >< > >
4033 >< > > ---------------------------------------------------------------
4034 >< > ---
4035 >< > > To unsubscribe or change your subscription options, visit:
4036 >< > > http://www.ircservices.za.net/mailman/listinfo/ircservices-
4037 >< > coding
4038 >< > -----------------------------------------------------------------
4039 >< > -
4040 >< > To unsubscribe or change your subscription options, visit:
4041 >< > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4042 >
4043 >
4044 >
4045 >------------------------------------------------------------------
4046 >To unsubscribe or change your subscription options, visit:
4047 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4048 >
4049 >
4050 >---
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
4054 >
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>
4063
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.
4065
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?
4067
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 -----------------------------------------------------------------------
4073
4074
4075
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>
4082
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. ;)
4088
4089   --Andrew Church
4090     achurch@achurch.org
4091     http://achurch.org/
4092
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.
4095 >
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?
4098 >
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 >-----------------------------------------------------------------------
4104 >
4105 >
4106 >
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>
4115
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.
4118 >
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.
4124
4125 >
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 > -----------------------------------------------------------------------
4131 >
4132 >
4133 >
4134 > ------------------------------------------------------------------
4135 > To unsubscribe or change your subscription options, visit:
4136 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4137 --
4138 Chris Plant <chris@monkeyircd.org>
4139 Personal
4140
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>
4147
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.
4151
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>
4157
4158 Hi,
4159
4160 Just upgraded to 5.0.11.  My previous problems have been solved, but now
4161 something else is not working..
4162
4163 If I kill ircservices' uplink it tries to write to its databases but fails
4164 with this log entry:
4165
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
4168
4169
4170 Looking in the libdir there's a .lock file with no permissions:
4171
4172 ----------   1 blabber  irc             0 Feb 23 12:35 .lock
4173
4174
4175 Starting it all up again and trying the same thing results in failure of
4176 course:
4177
4178 [Feb 23 12:29:42 2003] warning: data directory is locked, not updating databases
4179
4180 Lockfile needs to be removed manually...
4181
4182
4183 When performing a manual update via operserv this doesn't happen.  Neither
4184 when shutting down ircservices gracefully.  Only when the uplink dies
4185 unexpectedly.
4186
4187
4188 Regards,
4189 Aragon
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>
4196
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.
4199
4200
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>
4207
4208 Just out of curiosity, which IRCd are you planing to move to?
4209
4210 Kelmar K. Firesun (IRL: Bryce Simonds)
4211 Assistant Admin: dream.esper.net (www.esper.net)
4212
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
4219
4220
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.
4224
4225
4226 ------------------------------------------------------------------
4227 To unsubscribe or change your subscription options, visit:
4228 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4229
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>
4236
4237      Fixed, thanks for the report.
4238
4239   --Andrew Church
4240     achurch@achurch.org
4241     http://achurch.org/
4242
4243 >Hi,
4244 >
4245 >Just upgraded to 5.0.11.  My previous problems have been solved, but now
4246 >something else is not working..
4247 >
4248 >If I kill ircservices' uplink it tries to write to its databases but fails
4249 >with this log entry:
4250 >
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
4253 >
4254 >
4255 >Looking in the libdir there's a .lock file with no permissions:
4256 >
4257 >----------   1 blabber  irc             0 Feb 23 12:35 .lock
4258 >
4259 >
4260 >Starting it all up again and trying the same thing results in failure of
4261 >course:
4262 >
4263 >[Feb 23 12:29:42 2003] warning: data directory is locked, not updating databases
4264 >
4265 >Lockfile needs to be removed manually...
4266 >
4267 >
4268 >When performing a manual update via operserv this doesn't happen.  Neither
4269 >when shutting down ircservices gracefully.  Only when the uplink dies
4270 >unexpectedly.
4271 >
4272 >
4273 >Regards,
4274 >Aragon
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>
4284
4285 >Idea from thebeast
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
4290
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.)
4297
4298 >Idea from Rodecker
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
4303
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.
4307
4308   --Andrew Church
4309     achurch@achurch.org
4310     http://achurch.org/
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>
4316
4317 Hello.
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.
4321
4322
4323 Regards,
4324
4325 George Stamatiou
4326
4327
4328
4329
4330
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>
4337
4338
4339
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
4344 qlined nickname.
4345
4346
4347
4348 On Tue, 25 Feb 2003, George Stamatiou wrote:
4349
4350 > Hello.
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.
4354 >
4355 >
4356 > Regards,
4357 >
4358 > George Stamatiou
4359 >
4360 >
4361 >
4362 >
4363 >
4364 > ------------------------------------------------------------------
4365 > To unsubscribe or change your subscription options, visit:
4366 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4367 >
4368
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>
4375
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)
4380
4381 regards,
4382
4383 George Stamatiou
4384
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
4390
4391
4392 :
4393 :
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
4398 : qlined nickname.
4399 :
4400 :
4401 :
4402 : On Tue, 25 Feb 2003, George Stamatiou wrote:
4403 :
4404 : > Hello.
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.
4408 : >
4409 : >
4410 : > Regards,
4411 : >
4412 : > George Stamatiou
4413 : >
4414 : >
4415 : >
4416 : >
4417 : >
4418 : > ------------------------------------------------------------------
4419 : > To unsubscribe or change your subscription options, visit:
4420 : > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4421 : >
4422 :
4423 : ------------------------------------------------------------------
4424 : To unsubscribe or change your subscription options, visit:
4425 : http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4426 :
4427
4428
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>
4434
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
4438
4439 Regards,
4440 George Stamatiou
4441
4442
4443
4444
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>
4451
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.
4453
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>
4460
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)
4466
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
4472
4473
4474 We are using that, global works for us. However we are having a problem with szline, it doesn't seem
4475 to work at all.
4476
4477 ------------------------------------------------------------------
4478 To unsubscribe or change your subscription options, visit:
4479 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4480
4481
4482
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>
4489
4490 Note that SZLINES are removed in bahamut 1.4.35, because akills now have all
4491 the capabilities of them.
4492
4493 > -----Original Message-----
4494 > From: ircservices-coding-bounces@ircservices.za.net
4495 > [mailto:ircservices-coding-bounces@ircservices.za.net]On Behalf Of
4496 > George Stamatiou
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
4500 >
4501 >
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)
4509 >
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
4516 >
4517 >
4518 > We are using that, global works for us. However we are having a
4519 > problem with szline, it doesn't seem
4520 > to work at all.
4521 >
4522 > ------------------------------------------------------------------
4523 > To unsubscribe or change your subscription options, visit:
4524 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4525 >
4526 >
4527 >
4528 > ------------------------------------------------------------------
4529 > To unsubscribe or change your subscription options, visit:
4530 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4531 >
4532
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>
4539
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.
4542
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
4545 < > now have all
4546 < > the capabilities of them.
4547 < >
4548 < > > -----Original Message-----
4549 < > > From: ircservices-coding-bounces@ircservices.za.net
4550 < > > [mailto:ircservices-coding-bounces@ircservices.za.net]On
4551 < > Behalf Of
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
4556 < > >
4557 < > >
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)
4565 < > >
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
4572 < > >
4573 < > >
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.
4577 < > >
4578 < > > ---------------------------------------------------------------
4579 < > ---
4580 < > > To unsubscribe or change your subscription options, visit:
4581 < > > http://www.ircservices.za.net/mailman/listinfo/ircservices-
4582 < > coding
4583 < > >
4584 < > >
4585 < > >
4586 < > > ---------------------------------------------------------------
4587 < > ---
4588 < > > To unsubscribe or change your subscription options, visit:
4589 < > > http://www.ircservices.za.net/mailman/listinfo/ircservices-
4590 < > coding
4591 < > >
4592 < >
4593 < > -----------------------------------------------------------------
4594 < > -
4595 < > To unsubscribe or change your subscription options, visit:
4596 < > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4597
4598
4599
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>
4606
4607 >Hello.
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.
4611
4612      SQLINE for channels is not supported.
4613
4614   --Andrew Church
4615     achurch@achurch.org
4616     http://achurch.org/
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>
4623
4624 >Note that SZLINES are removed in bahamut 1.4.35, because akills now have all
4625 >the capabilities of them.
4626
4627      Also note that Bahamut 1.4.34+ are not (and will not be for the near
4628 future) supported by Services.
4629
4630   --Andrew Church
4631     achurch@achurch.org
4632     http://achurch.org/
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>
4639
4640 So if we downgraded and used akill it would work correctly right?
4641
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
4644 < > the near
4645 < > future) supported by Services.
4646
4647
4648
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>
4656
4657 On Wed, 26 Feb 2003, Andrew Church wrote:
4658
4659 AC>      Also note that Bahamut 1.4.34+ are not (and will not be for the near
4660 AC> future) supported by Services.
4661
4662 Andrew, could you please give the list of incompatibilities.  It would be
4663 useful for people willing to run Services with latest Bahamut.
4664
4665
4666 --
4667 Dmitry Agaphonov
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>
4674
4675 >On Wed, 26 Feb 2003, Andrew Church wrote:
4676 >
4677 >AC>      Also note that Bahamut 1.4.34+ are not (and will not be for the near
4678 >AC> future) supported by Services.
4679 >
4680 >Andrew, could you please give the list of incompatibilities.  It would be
4681 >useful for people willing to run Services with latest Bahamut.
4682
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
4687 a single version.
4688
4689   --Andrew Church
4690     achurch@achurch.org
4691     http://achurch.org/
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>
4698
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.
4701
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
4709 >
4710 >
4711 > So if we downgraded and used akill it would work correctly right?
4712 >
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
4715 > < > the near
4716 > < > future) supported by Services.
4717 >
4718 >
4719 >
4720 > ------------------------------------------------------------------
4721 > To unsubscribe or change your subscription options, visit:
4722 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4723 >
4724
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>
4730
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:
4733
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.)
4740
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.
4746
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".
4762
4763      If anyone can pinpoint how NickGroupInfo.language can get set out of
4764 range, you'll have my gratitude.
4765
4766   --Andrew Church
4767     achurch@achurch.org
4768     http://achurch.org/
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>
4775
4776 I think it's forgivable just this once :P
4777
4778 -----Original Message-----
4779 From: ircservices-coding-bounces@ircservices.za.net
4780 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of Andrew
4781 Church
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)
4785
4786
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:
4789
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.)
4796
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.
4802
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".
4818
4819      If anyone can pinpoint how NickGroupInfo.language can get set out of
4820 range, you'll have my gratitude.
4821
4822   --Andrew Church
4823     achurch@achurch.org
4824     http://achurch.org/
4825 ------------------------------------------------------------------
4826 To unsubscribe or change your subscription options, visit:
4827 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4828
4829
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>
4835
4836
4837 Hello Andrew
4838
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
4842
4843 Not Found
4844 The requested resource could not be found.
4845
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
4849
4850 this is a normale link
4851 http://password:Secret@rc5proxy.mp3crew.nu:8888/dbaccess/nickserv/The_Beast
4852
4853 and the wrong nicks are pointing to
4854 http://More:Secrets@rc5proxy.mp3crew.nu:8888/LiNuX
4855
4856 so because of the produced html code's the url is wrong it looks
4857
4858 I Hope you can think of a option to correct it
4859
4860 Grtzz Thebeast
4861         irc.mp3crew.nu
4862
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>
4868
4869 Hi, i've been trying to modify ircservices 5.0.12 to make my irc network
4870 more secure.
4871
4872 i'm using UnrealIRCD (3.2beta14), and i wanted the services to do this:
4873
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?
4877
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.
4881
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.
4884
4885 anyone that can help?
4886
4887
4888 Thx in advance,
4889 Bjorn
4890
4891 _________________________________________________________________
4892 MSN Search, for relevant search results! http://search.msn.be
4893
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>
4900
4901 Hi,
4902
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 :)
4910
4911 Greets,
4912
4913 Georges
4914
4915
4916
4917 -----Urspr?ngliche Nachricht-----
4918 Von: ircservices-coding-bounces@ircservices.za.net
4919 [mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
4920 Jack Neils
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
4924 ?
4925
4926
4927 Hi, i've been trying to modify ircservices 5.0.12 to make my irc network
4928
4929 more secure.
4930
4931 i'm using UnrealIRCD (3.2beta14), and i wanted the services to do this:
4932
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?
4936
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
4939 and
4940 chghost) to change the ident and host into something else.
4941
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.
4944
4945 anyone that can help?
4946
4947
4948 Thx in advance,
4949 Bjorn
4950
4951 _________________________________________________________________
4952 MSN Search, for relevant search results! http://search.msn.be
4953
4954 ------------------------------------------------------------------
4955 To unsubscribe or change your subscription options, visit:
4956 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
4957
4958
4959
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>
4966
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.
4970
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).
4976
4977   --Andrew Church
4978     achurch@achurch.org
4979     http://achurch.org/
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>
4986
4987      WFM with Mozilla 1.2.1, but I'll add a workaround for the next
4988 release.
4989
4990   --Andrew Church
4991     achurch@achurch.org
4992     http://achurch.org/
4993
4994 >
4995 >Hello Andrew
4996 >
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
5000 >
5001 >Not Found
5002 >The requested resource could not be found.
5003 >
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
5007 >
5008 >this is a normale link
5009 >http://password:Secret@rc5proxy.mp3crew.nu:8888/dbaccess/nickserv/The_Beast
5010 >
5011 >and the wrong nicks are pointing to
5012 >http://More:Secrets@rc5proxy.mp3crew.nu:8888/LiNuX
5013 >
5014 >so because of the produced html code's the url is wrong it looks
5015 >
5016 >I Hope you can think of a option to correct it
5017 >
5018 >Grtzz Thebeast
5019 >       irc.mp3crew.nu
5020 >
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>
5029
5030 Found a typo in /msg chanserv help access levels
5031
5032 [21:36:09] -ChanServ-    Founder   Full access to ChanServ functions;
5033 automatic
5034 -
5035 [21:36:09] -ChanServ-                  opping upon entering channel.  Note
5036 that
5037 -
5038 [21:36:09] -ChanServ-                  only one person may have founder
5039 status (it
5040 -
5041 [21:36:09] -ChanServ-                  status (it cannot be given using the
5042 ACCESS
5043 -
5044 [21:36:09] -ChanServ-                  command).
5045
5046 Now:
5047
5048 [21:41:59] -ChanServ-    Founder   Full access to ChanServ functions;
5049 automatic
5050 -
5051 [21:41:59] -ChanServ-                  opping upon entering channel.  Note
5052 that
5053 -
5054 [21:41:59] -ChanServ-                  only one person may have founder
5055 status
5056 -
5057 [21:41:59] -ChanServ-                  (it cannot be given using the ACCESS
5058 -
5059 [21:41:59] -ChanServ-                  command).
5060
5061
5062 Updated en_us.l here:
5063
5064 http://www.orblivion.com/~ircd/en_us.l
5065
5066 Cheers,
5067 David
5068 -------------- next part --------------
5069 A non-text attachment was scrubbed...
5070 Name: winmail.dat
5071 Type: application/ms-tnef
5072 Size: 3508 bytes
5073 Desc: not available
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>
5080
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.
5088
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)
5091
5092 Regards,
5093
5094 George Stamatiou
5095 master@xchat.gr
5096
5097
5098
5099
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>
5105
5106 A typo mistake.
5107
5108 This happens with bahamut 1.4(35),  and not bahamut-1.4(34)
5109
5110 Regards,
5111
5112 George Stamatiou
5113 master@xchat.gr
5114
5115
5116
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>
5122
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.
5127
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.
5130
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
5134 ***************
5135 *** 919,924 ****
5136 --- 919,932 ----
5137
5138       #CSForbidShortChannel
5139
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.
5145 +
5146 +     #CSRegisteredOnly
5147 +
5148   EndModule
5149
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
5154 ***************
5155 *** 1722,1727 ****
5156 --- 1722,1739 ----
5157
5158   <p>Example: <tt>CSForbidShortChannel</tt>
5159   </ul>
5160 +
5161 + <a name="chanserv/main.CSRegisteredOnly"></a>
5162 + <p><ul><li>
5163 + <tt><b>CSRegisteredOnly</b></tt>&nbsp;&nbsp;&nbsp;&nbsp;[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.
5168 +
5169 + <p>Example: <tt>CSRegisteredOnly</tt>
5170 + </ul>
5171 +
5172   <a name="chanserv/sendpass"></a>
5173   <p><font size="+1"><b>chanserv/sendpass</b> (SENDPASS module)</font>
5174
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
5178 ***************
5179 *** 274,281 ****
5180         goto kick;
5181       }
5182
5183 !     if (!ci)
5184 !       return 0;
5185
5186       if (is_services_admin(user))
5187         return 0;
5188 --- 274,288 ----
5189         goto kick;
5190       }
5191
5192 !     if (!ci) {
5193 !       if(CSRegisteredOnly && !is_oper(user)) {
5194 !           mask = sstrdup("*!*@*");
5195 !           reason = getstring(user->ngi, CHAN_MAY_NOT_BE_USED);
5196 !           goto kick;
5197 !       } else {
5198 !           return 0;
5199 !       }
5200 !     }
5201
5202       if (is_services_admin(user))
5203         return 0;
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
5207 ***************
5208 *** 93,98 ****
5209 --- 93,99 ----
5210   E time_t CSSuspendExpire;
5211   E time_t CSSuspendGrace;
5212   E int    CSForbidShortChannel;
5213 + E int    CSRegisteredOnly;
5214   E ChanOpt chanopts[];
5215
5216
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
5220 ***************
5221 *** 57,62 ****
5222 --- 57,63 ----
5223          time_t CSSuspendExpire;
5224          time_t CSSuspendGrace;
5225          int    CSForbidShortChannel;
5226 +        int    CSRegisteredOnly;
5227   EXPORT_VAR(int32,CSMaxReg)
5228
5229   /*************************************************************************/
5230 ***************
5231 *** 1606,1611 ****
5232 --- 1607,1613 ----
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>
5245
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.
5247
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 -----------------------------------------------------------------------
5254
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
5260 >Date     : 2003-03-12
5261 >
5262 >
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.
5267 >
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.
5270 >
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
5274 >***************
5275 >*** 919,924 ****
5276 >--- 919,932 ----
5277 >
5278 >      #CSForbidShortChannel
5279 >
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.
5285 >+
5286 >+     #CSRegisteredOnly
5287 >+
5288 >  EndModule
5289 >
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
5294 >***************
5295 >*** 1722,1727 ****
5296 >--- 1722,1739 ----
5297 >
5298 >  <p>Example: <tt>CSForbidShortChannel</tt>
5299 >  </ul>
5300 >+
5301 >+ <a name="chanserv/main.CSRegisteredOnly"></a>
5302 >+ <p><ul><li>
5303 >+ <tt><b>CSRegisteredOnly</b></tt>&nbsp;&nbsp;&nbsp;&nbsp;[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.
5308 >+
5309 >+ <p>Example: <tt>CSRegisteredOnly</tt>
5310 >+ </ul>
5311 >+
5312 >  <a name="chanserv/sendpass"></a>
5313 >  <p><font size="+1"><b>chanserv/sendpass</b> (SENDPASS module)</font>
5314 >
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
5318 >***************
5319 >*** 274,281 ****
5320 >       goto kick;
5321 >      }
5322 >
5323 >!     if (!ci)
5324 >!      return 0;
5325 >
5326 >      if (is_services_admin(user))
5327 >       return 0;
5328 >--- 274,288 ----
5329 >       goto kick;
5330 >      }
5331 >
5332 >!     if (!ci) {
5333 >!      if(CSRegisteredOnly && !is_oper(user)) {
5334 >!          mask = sstrdup("*!*@*");
5335 >!          reason = getstring(user->ngi, CHAN_MAY_NOT_BE_USED);
5336 >!          goto kick;
5337 >!      } else {
5338 >!          return 0;
5339 >!      }
5340 >!     }
5341 >
5342 >      if (is_services_admin(user))
5343 >       return 0;
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
5347 >***************
5348 >*** 93,98 ****
5349 >--- 93,99 ----
5350 >  E time_t CSSuspendExpire;
5351 >  E time_t CSSuspendGrace;
5352 >  E int    CSForbidShortChannel;
5353 >+ E int    CSRegisteredOnly;
5354 >  E ChanOpt chanopts[];
5355 >
5356 >
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
5360 >***************
5361 >*** 57,62 ****
5362 >--- 57,63 ----
5363 >         time_t CSSuspendExpire;
5364 >         time_t CSSuspendGrace;
5365 >         int    CSForbidShortChannel;
5366 >+        int    CSRegisteredOnly;
5367 >  EXPORT_VAR(int32,CSMaxReg)
5368 >
5369 >  /*************************************************************************/
5370 >***************
5371 >*** 1606,1611 ****
5372 >--- 1607,1613 ----
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
5383 >.
5384 ========= End of Original Message =========
5385
5386
5387
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>
5396
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.
5399
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.
5405
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.
5413
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.
5420
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?
5424
5425 Stefan
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>
5433
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.
5440
5441 on unreal 3.2 opers can get around the ban by inviting themselves into the
5442 channel
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>
5449
5450      Thanks for the suggestion.  I generally try to avoid adding features
5451 into a stable branch, but I'll consider it.
5452
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.
5460
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.
5466
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?
5470
5471      Unlikely, since the ircd would probably drop them for flooding before
5472 Services took any serious performance hit.
5473
5474   --Andrew Church
5475     achurch@achurch.org
5476     http://achurch.org/
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>
5483
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.
5486
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>
5493
5494 I have had a similar problem while exporting the database in xml format via
5495 the html module.
5496
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.
5499
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)
5502
5503 John
5504
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
5511
5512
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.
5517
5518 ------------------------------------------------------------------
5519 To unsubscribe or change your subscription options, visit:
5520 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
5521
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>
5528
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
5533 being nosy :).
5534
5535 Russ
5536
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
5544 >
5545 >
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.
5550 >
5551 > ------------------------------------------------------------------
5552 > To unsubscribe or change your subscription options, visit:
5553 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
5554 >
5555 >
5556
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>
5562
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.
5564
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 -----------------------------------------------------------------------
5571
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
5577 >Date     : 2003-03-13
5578 >
5579 >
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
5584 >being nosy :).
5585 >
5586 >Russ
5587 >
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
5595 >>
5596 >>
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.
5601 >>
5602 >> ------------------------------------------------------------------
5603 >> To unsubscribe or change your subscription options, visit:
5604 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
5605 >>
5606 >>
5607 >
5608 >------------------------------------------------------------------
5609 >To unsubscribe or change your subscription options, visit:
5610 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
5611 >.
5612 ========= End of Original Message =========
5613
5614
5615
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>
5622
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.
5627
5628 David
5629
5630
5631 Quoth Craig McLure on Mar 13 at 21:06,
5632
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.
5634 >
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 > -----------------------------------------------------------------------
5641 >
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
5648 > >
5649 > >
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
5654 > >being nosy :).
5655 > >
5656 > >Russ
5657 > >
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
5665 > >>
5666 > >>
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.
5671 > >>
5672 > >> ------------------------------------------------------------------
5673 > >> To unsubscribe or change your subscription options, visit:
5674 > >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
5675 > >>
5676 > >>
5677 > >
5678 > >------------------------------------------------------------------
5679 > >To unsubscribe or change your subscription options, visit:
5680 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
5681 > >.
5682 > ========= End of Original Message =========
5683 >
5684 >
5685 >
5686 > ------------------------------------------------------------------
5687 > To unsubscribe or change your subscription options, visit:
5688 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
5689 >
5690
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>
5697
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
5700 2.
5701
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.
5707 < >
5708 < > -----------------------------------------------------------------
5709 < > ------
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 < > -----------------------------------------------------------------
5716 < > ------
5717 < >
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
5724 < > >
5725 < > >
5726 < > >Out of interest, how does Services perform with this many
5727 < > akills? And, if
5728 < > >you don't mind me asking, how did you accumulate so many? In my
5729 < > experience
5730 < > >offenders almost certainly give up after a month or so, and so
5731 < > setting
5732 < > >unlimited-timed akills is usually a pointless exercise. But
5733 < > it's just me
5734 < > >being nosy :).
5735 < > >
5736 < > >Russ
5737 < > >
5738 < > >> -----Original Message-----
5739 < > >> From: ircservices-coding-bounces@ircservices.za.net
5740 < > >> [mailto:ircservices-coding-bounces@ircservices.za.net]On
5741 < > Behalf
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
5746 < > >>
5747 < > >>
5748 < > >> We have about 19,000 autokills on the akill list. When trying
5749 < > to
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
5752 < > both
5753 < > >> Opera and IE, both have the same problem.
5754 < > >>
5755 < > >> --------------------------------------------------------------
5756 < > ----
5757 < > >> To unsubscribe or change your subscription options, visit:
5758 < > >> http://www.ircservices.za.net/mailman/listinfo/ircservices-
5759 < > coding
5760 < > >>
5761 < > >>
5762 < > >
5763 < > >----------------------------------------------------------------
5764 < > --
5765 < > >To unsubscribe or change your subscription options, visit:
5766 < > >http://www.ircservices.za.net/mailman/listinfo/ircservices-
5767 < > coding
5768 < > >.
5769 < > ========= End of Original Message =========
5770 < >
5771 < >
5772 < >
5773 < > -----------------------------------------------------------------
5774 < > -
5775 < > To unsubscribe or change your subscription options, visit:
5776 < > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
5777
5778
5779
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>
5786
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
5791 looks really good.
5792
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
5796 < > problem now
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
5799 < > 2.
5800 < >
5801 < > < >On Thu, 13 Mar 2003 21:6:47 +0000, Craig McLure wrote:
5802 < > < > Russell has been subject to a large number of botfloods
5803 < > recently
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
5806 < > after a
5807 < > < > certain ammount, but performance wise, its fine.
5808 < > < >
5809 < > < > -------------------------------------------------------------
5810 < > ----
5811 < > < > ------
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
5816 < > the
5817 < > < > setup.exe or install.exe
5818 < > < > -------------------------------------------------------------
5819 < > ----
5820 < > < > ------
5821 < > < >
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
5828 < > < > >
5829 < > < > >
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?
5833 < > In my
5834 < > < > experience
5835 < > < > >offenders almost certainly give up after a month or so, and
5836 < > so
5837 < > < > setting
5838 < > < > >unlimited-timed akills is usually a pointless exercise. But
5839 < > < > it's just me
5840 < > < > >being nosy :).
5841 < > < > >
5842 < > < > >Russ
5843 < > < > >
5844 < > < > >> -----Original Message-----
5845 < > < > >> From: ircservices-coding-bounces@ircservices.za.net
5846 < > < > >> [mailto:ircservices-coding-bounces@ircservices.za.net]On
5847 < > < > Behalf
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
5852 < > < > >>
5853 < > < > >>
5854 < > < > >> We have about 19,000 autokills on the akill list. When
5855 < > trying
5856 < > < > to
5857 < > < > >> view them on the web it seems services only shows about
5858 < > 17,200
5859 < > < > >> before it stops loading the page. I have tried to view it
5860 < > in
5861 < > < > both
5862 < > < > >> Opera and IE, both have the same problem.
5863 < > < > >>
5864 < > < > >> ----------------------------------------------------------
5865 < > ----
5866 < > < > ----
5867 < > < > >> To unsubscribe or change your subscription options, visit:
5868 < > < > >>
5869 < > http://www.ircservices.za.net/mailman/listinfo/ircservices-
5870 < > < > coding
5871 < > < > >>
5872 < > < > >>
5873 < > < > >
5874 < > < > >------------------------------------------------------------
5875 < > ----
5876 < > < > --
5877 < > < > >To unsubscribe or change your subscription options, visit:
5878 < > < > >http://www.ircservices.za.net/mailman/listinfo/ircservices-
5879 < > < > coding
5880 < > < > >.
5881 < > < > ========= End of Original Message =========
5882 < > < >
5883 < > < >
5884 < > < >
5885 < > < > -------------------------------------------------------------
5886 < > ----
5887 < > < > -
5888 < > < > To unsubscribe or change your subscription options, visit:
5889 < > < > http://www.ircservices.za.net/mailman/listinfo/ircservices-
5890 < > coding
5891 < >
5892 < >
5893 < >
5894 < > -----------------------------------------------------------------
5895 < > -
5896 < > To unsubscribe or change your subscription options, visit:
5897 < > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
5898
5899
5900
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>
5906
5907 I've found a bug.  Hoooray!
5908
5909 When you use /msg OperServ raw svskill nickname :reason
5910
5911 It kills the user with whatever reason -- however, when you use /msg OperServ session limit <number>
5912
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.
5914
5915 Can this be fixed?
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>
5925
5926 On Sunday, Mar 23, 2003, at 20:13 US/Pacific, prince wrote:
5927
5928 > I've found a bug.  Hoooray!
5929
5930 No, you haven't.
5931
5932 > When you use /msg OperServ raw svskill nickname :reason
5933
5934 RTFM, or hell, even just /msg operserv help raw.
5935
5936 -- Quension
5937
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>
5944
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.
5951
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
5958
5959
5960 > On Sunday, Mar 23, 2003, at 20:13 US/Pacific, prince wrote:
5961 >
5962 > > I've found a bug.  Hoooray!
5963 >
5964 > No, you haven't.
5965 >
5966 > > When you use /msg OperServ raw svskill nickname :reason
5967 >
5968 > RTFM, or hell, even just /msg operserv help raw.
5969 >
5970 > -- Quension
5971 >
5972 > ------------------------------------------------------------------
5973 > To unsubscribe or change your subscription options, visit:
5974 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
5975 >
5976
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>
5983
5984 On Sunday, Mar 23, 2003, at 20:41 US/Pacific, prince wrote:
5985
5986 > Well, I hate to break it to you...but OS help mentions *nothing* of
5987 > this,
5988 > and when I read the fine manual, or fucking manual, however you want
5989 > to put
5990 > it, it also said nothing of this.  So I felt like I should report it.
5991 > If
5992
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
5995 NOT
5996 USE THIS COMMAND unless you are absolutely certain you know what you are
5997 doing!"
5998
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
6002 server.
6003 Therefore, if the ircd does not tell services that the user is gone,
6004 services never knows.
6005
6006 To put it bluntly, you do not know what you are doing.
6007
6008 > you have a problem with such "lame emails" or "lame comments" about
6009 > IRCServices, perhaps you should remove yourself from the mailing list
6010 > or
6011 > stop replying with comments such as yours? heh.
6012
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
6015 are searchable.
6016
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.
6019
6020 > ----- Original Message -----
6021 > From: "Trevor Talbot" <quension@mac.com>
6022 >
6023 >> On Sunday, Mar 23, 2003, at 20:13 US/Pacific, prince wrote:
6024 >>
6025 >>> I've found a bug.  Hoooray!
6026 >>
6027 >> No, you haven't.
6028 >>
6029 >>> When you use /msg OperServ raw svskill nickname :reason
6030 >>
6031 >> RTFM, or hell, even just /msg operserv help raw.
6032
6033 -- Quension
6034
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>
6041
6042 > Mailing list archives exist and are searchable.
6043
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.
6047
6048 -- Quension
6049
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>
6056
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
6068 any way. ;)
6069
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
6076
6077
6078 > On Sunday, Mar 23, 2003, at 20:41 US/Pacific, prince wrote:
6079 >
6080 > > Well, I hate to break it to you...but OS help mentions *nothing* of
6081 > > this,
6082 > > and when I read the fine manual, or fucking manual, however you want
6083 > > to put
6084 > > it, it also said nothing of this.  So I felt like I should report it.
6085 > > If
6086 >
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
6089 > NOT
6090 > USE THIS COMMAND unless you are absolutely certain you know what you are
6091 > doing!"
6092 >
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
6096 > server.
6097 > Therefore, if the ircd does not tell services that the user is gone,
6098 > services never knows.
6099 >
6100 > To put it bluntly, you do not know what you are doing.
6101 >
6102 > > you have a problem with such "lame emails" or "lame comments" about
6103 > > IRCServices, perhaps you should remove yourself from the mailing list
6104 > > or
6105 > > stop replying with comments such as yours? heh.
6106 >
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
6109 > are searchable.
6110 >
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.
6113 >
6114 > > ----- Original Message -----
6115 > > From: "Trevor Talbot" <quension@mac.com>
6116 > >
6117 > >> On Sunday, Mar 23, 2003, at 20:13 US/Pacific, prince wrote:
6118 > >>
6119 > >>> I've found a bug.  Hoooray!
6120 > >>
6121 > >> No, you haven't.
6122 > >>
6123 > >>> When you use /msg OperServ raw svskill nickname :reason
6124 > >>
6125 > >> RTFM, or hell, even just /msg operserv help raw.
6126 >
6127 > -- Quension
6128 >
6129 > ------------------------------------------------------------------
6130 > To unsubscribe or change your subscription options, visit:
6131 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6132 >
6133
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>
6140
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.
6143
6144 < >On Mon, 24 Mar 2003 00:01:08 -0500, prince wrote:
6145 < > Right, it does not say "This command will cause multiple session
6146 < > limits if
6147 < > you use SVSKILL on a user" - and I very much do know what I'm
6148 < > doing.  I
6149 < > think, perhaps, instead of commenting on people's messages you
6150 < > should let
6151 < > somebody who runs this list do so, instead of filling people's
6152 < > inbox up with
6153 < > your pointless ramblings.  I rarely use this list, except when I
6154 < > find
6155 < > something wrong.  I wasn't asking for your comments, I was
6156 < > asking if a fix
6157 < > could be made, I guess you missed that part, eh?  But I'm not
6158 < > here to bicker
6159 < > back and forth with you, my question still stands - can a fix be
6160 < > made?
6161 < > So, Trevor Talbot, don't reply to this, as I'm not insterested
6162 < > in reading
6163 < > what you have to say, yet I'm interested in knowing if it can be
6164 < > fixed.  So
6165 < > please refrain from your comments that do not fix or help this
6166 < > problem in
6167 < > any way. ;)
6168 < >
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
6175 < >
6176 < >
6177 < > > On Sunday, Mar 23, 2003, at 20:41 US/Pacific, prince wrote:
6178 < > >
6179 < > > > Well, I hate to break it to you...but OS help mentions *
6180 < > nothing* of
6181 < > > > this,
6182 < > > > and when I read the fine manual, or fucking manual, however
6183 < > you want
6184 < > > > to put
6185 < > > > it, it also said nothing of this.  So I felt like I should
6186 < > report it.
6187 < > > > If
6188 < > >
6189 < > > It says, "This command has a very limited range of uses, and
6190 < > can wreak
6191 < > > havoc on a network or cause Services to crash if used
6192 < > improperly.  DO
6193 < > > NOT
6194 < > > USE THIS COMMAND unless you are absolutely certain you know
6195 < > what you are
6196 < > > doing!"
6197 < > >
6198 < > > The reason why you are experiencing the issue you are is
6199 < > related to the
6200 < > > ircd's handling of SVSKILL.  ircservices does not do any
6201 < > processing on
6202 < > > the operserv raw command itself; it simply sends it to its
6203 < > uplink
6204 < > > server.
6205 < > > Therefore, if the ircd does not tell services that the user is
6206 < > gone,
6207 < > > services never knows.
6208 < > >
6209 < > > To put it bluntly, you do not know what you are doing.
6210 < > >
6211 < > > > you have a problem with such "lame emails" or "lame
6212 < > comments" about
6213 < > > > IRCServices, perhaps you should remove yourself from the
6214 < > mailing list
6215 < > > > or
6216 < > > > stop replying with comments such as yours? heh.
6217 < > >
6218 < > > That is not my problem.  I replied bluntly and simply because
6219 < > this issue
6220 < > > has been answered several times before.  Mailing list archives
6221 < > exist and
6222 < > > are searchable.
6223 < > >
6224 < > > Even if not understanding the manual/help text completely, a
6225 < > bit of
6226 < > > effort on your part could have avoided this entire email
6227 < > exchange.
6228 < > >
6229 < > > > ----- Original Message -----
6230 < > > > From: "Trevor Talbot" <quension@mac.com>
6231 < > > >
6232 < > > >> On Sunday, Mar 23, 2003, at 20:13 US/Pacific, prince wrote:
6233 < > > >>
6234 < > > >>> I've found a bug.  Hoooray!
6235 < > > >>
6236 < > > >> No, you haven't.
6237 < > > >>
6238 < > > >>> When you use /msg OperServ raw svskill nickname :reason
6239 < > > >>
6240 < > > >> RTFM, or hell, even just /msg operserv help raw.
6241 < > >
6242 < > > -- Quension
6243 < > >
6244 < > > ---------------------------------------------------------------
6245 < > ---
6246 < > > To unsubscribe or change your subscription options, visit:
6247 < > > http://www.ircservices.za.net/mailman/listinfo/ircservices-
6248 < > coding
6249 < > >
6250 < >
6251 < > -----------------------------------------------------------------
6252 < > -
6253 < > To unsubscribe or change your subscription options, visit:
6254 < > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6255
6256
6257
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>
6264
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. ;)
6279
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
6286
6287
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.
6292
6293 < >On Mon, 24 Mar 2003 00:01:08 -0500, prince wrote:
6294 < > Right, it does not say "This command will cause multiple session
6295 < > limits if
6296 < > you use SVSKILL on a user" - and I very much do know what I'm
6297 < > doing.  I
6298 < > think, perhaps, instead of commenting on people's messages you
6299 < > should let
6300 < > somebody who runs this list do so, instead of filling people's
6301 < > inbox up with
6302 < > your pointless ramblings.  I rarely use this list, except when I
6303 < > find
6304 < > something wrong.  I wasn't asking for your comments, I was
6305 < > asking if a fix
6306 < > could be made, I guess you missed that part, eh?  But I'm not
6307 < > here to bicker
6308 < > back and forth with you, my question still stands - can a fix be
6309 < > made?
6310 < > So, Trevor Talbot, don't reply to this, as I'm not insterested
6311 < > in reading
6312 < > what you have to say, yet I'm interested in knowing if it can be
6313 < > fixed.  So
6314 < > please refrain from your comments that do not fix or help this
6315 < > problem in
6316 < > any way. ;)
6317 < >
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
6324 < >
6325 < >
6326 < > > On Sunday, Mar 23, 2003, at 20:41 US/Pacific, prince wrote:
6327 < > >
6328 < > > > Well, I hate to break it to you...but OS help mentions *
6329 < > nothing* of
6330 < > > > this,
6331 < > > > and when I read the fine manual, or fucking manual, however
6332 < > you want
6333 < > > > to put
6334 < > > > it, it also said nothing of this.  So I felt like I should
6335 < > report it.
6336 < > > > If
6337 < > >
6338 < > > It says, "This command has a very limited range of uses, and
6339 < > can wreak
6340 < > > havoc on a network or cause Services to crash if used
6341 < > improperly.  DO
6342 < > > NOT
6343 < > > USE THIS COMMAND unless you are absolutely certain you know
6344 < > what you are
6345 < > > doing!"
6346 < > >
6347 < > > The reason why you are experiencing the issue you are is
6348 < > related to the
6349 < > > ircd's handling of SVSKILL.  ircservices does not do any
6350 < > processing on
6351 < > > the operserv raw command itself; it simply sends it to its
6352 < > uplink
6353 < > > server.
6354 < > > Therefore, if the ircd does not tell services that the user is
6355 < > gone,
6356 < > > services never knows.
6357 < > >
6358 < > > To put it bluntly, you do not know what you are doing.
6359 < > >
6360 < > > > you have a problem with such "lame emails" or "lame
6361 < > comments" about
6362 < > > > IRCServices, perhaps you should remove yourself from the
6363 < > mailing list
6364 < > > > or
6365 < > > > stop replying with comments such as yours? heh.
6366 < > >
6367 < > > That is not my problem.  I replied bluntly and simply because
6368 < > this issue
6369 < > > has been answered several times before.  Mailing list archives
6370 < > exist and
6371 < > > are searchable.
6372 < > >
6373 < > > Even if not understanding the manual/help text completely, a
6374 < > bit of
6375 < > > effort on your part could have avoided this entire email
6376 < > exchange.
6377 < > >
6378 < > > > ----- Original Message -----
6379 < > > > From: "Trevor Talbot" <quension@mac.com>
6380 < > > >
6381 < > > >> On Sunday, Mar 23, 2003, at 20:13 US/Pacific, prince wrote:
6382 < > > >>
6383 < > > >>> I've found a bug.  Hoooray!
6384 < > > >>
6385 < > > >> No, you haven't.
6386 < > > >>
6387 < > > >>> When you use /msg OperServ raw svskill nickname :reason
6388 < > > >>
6389 < > > >> RTFM, or hell, even just /msg operserv help raw.
6390 < > >
6391 < > > -- Quension
6392 < > >
6393 < > > ---------------------------------------------------------------
6394 < > ---
6395 < > > To unsubscribe or change your subscription options, visit:
6396 < > > http://www.ircservices.za.net/mailman/listinfo/ircservices-
6397 < > coding
6398 < > >
6399 < >
6400 < > -----------------------------------------------------------------
6401 < > -
6402 < > To unsubscribe or change your subscription options, visit:
6403 < > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6404
6405
6406
6407 ------------------------------------------------------------------
6408 To unsubscribe or change your subscription options, visit:
6409 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6410
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>
6417
6418 FAQ F.7
6419
6420   --Andrew Church
6421     achurch@achurch.org
6422     http://achurch.org/
6423
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.
6430 >
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
6437 >
6438 >
6439 >> On Sunday, Mar 23, 2003, at 20:13 US/Pacific, prince wrote:
6440 >>
6441 >> > I've found a bug.  Hoooray!
6442 >>
6443 >> No, you haven't.
6444 >>
6445 >> > When you use /msg OperServ raw svskill nickname :reason
6446 >>
6447 >> RTFM, or hell, even just /msg operserv help raw.
6448 >>
6449 >> -- Quension
6450 >>
6451 >> ------------------------------------------------------------------
6452 >> To unsubscribe or change your subscription options, visit:
6453 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6454 >>
6455 >
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>
6465
6466 Thanks, I'll have our custom services coded to kill a different way. :)
6467
6468 Just out of curiousity, why does the RAW command screw with the servers to
6469 badly?
6470
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
6476
6477
6478 > FAQ F.7
6479 >
6480 >   --Andrew Church
6481 >     achurch@achurch.org
6482 >     http://achurch.org/
6483 >
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
6486 put
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.
6491 > >
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
6498 > >
6499 > >
6500 > >> On Sunday, Mar 23, 2003, at 20:13 US/Pacific, prince wrote:
6501 > >>
6502 > >> > I've found a bug.  Hoooray!
6503 > >>
6504 > >> No, you haven't.
6505 > >>
6506 > >> > When you use /msg OperServ raw svskill nickname :reason
6507 > >>
6508 > >> RTFM, or hell, even just /msg operserv help raw.
6509 > >>
6510 > >> -- Quension
6511 > >>
6512 > >> ------------------------------------------------------------------
6513 > >> To unsubscribe or change your subscription options, visit:
6514 > >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6515 > >>
6516 > >
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
6523 >
6524
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>
6533
6534 -----BEGIN PGP SIGNED MESSAGE-----
6535 Hash: SHA1
6536
6537 On Monday 24 March 2003 06:45, prince wrote:
6538 > Thanks, I'll have our custom services coded to kill a different way. :)
6539 >
6540 > Just out of curiousity, why does the RAW command screw with the servers to
6541 > badly?
6542
6543 This has already been answered, and is also answered in the FAQ section just
6544 pointed out to you.
6545 - --
6546 Yours Sincerely
6547
6548 Thomas Juberg Stens?s
6549
6550 - -- What we do in life echoes in eternity
6551
6552 -----BEGIN PGP SIGNATURE-----
6553 Version: GnuPG v1.2.1 (GNU/Linux)
6554
6555 iD8DBQE+fp/7m5JSuDogRncRAhi8AJ9gbfTmsIQD3smxc3ovSShpTIdQcQCfY+As
6556 hm2CETBlKqLgfMiKqfU20IA=
6557 =etIP
6558 -----END PGP SIGNATURE-----
6559
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>
6568
6569 On Mon, 24 Mar 2003 00:21:10 -0500, prince <prince@zirc.org> wrote:
6570
6571 > I disagree.  I think it does need a fix.  I do not need to sit and
6572 *snip ranting*
6573
6574 Don't top post.
6575
6576 If you REALLY need to use svskill, write a module that does it and handles
6577 it
6578 properly rather than using raw. Andrew church, as you can see from the
6579 archives,
6580 gives the exact same answer as the others already have when it comes to
6581 raw.
6582
6583 Raw does exactly what it's designed to do, and the bug here is the way that
6584 you
6585 are using it.
6586
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>
6594
6595 >Thanks, I'll have our custom services coded to kill a different way. :)
6596 >
6597 >Just out of curiousity, why does the RAW command screw with the servers to
6598 >badly?
6599
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.
6605
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.
6610
6611   --Andrew Church
6612     achurch@achurch.org
6613     http://achurch.org/
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>
6620
6621 >Don't top post.
6622
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.
6627
6628   --Andrew Church
6629     achurch@achurch.org
6630     http://achurch.org/
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>
6639
6640 prince wrote:
6641 > Thanks, I'll have our custom services coded to kill a different way. :)
6642 >
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.
6648
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
6651
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>
6657
6658 I know people will probably ignore or shoot down this request but, here goes....
6659
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...
6661
6662 >I've found a bug.  Hoooray!
6663 >
6664 >When you use /msg OperServ raw svskill nickname :reason
6665 >
6666 >It kills the user with whatever reason -- however, when you use /msg OperServ session limit <number>
6667 >
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.
6669 >
6670 >Can this be fixed?
6671 >------------------------------------------------------------------
6672 >To unsubscribe or change your subscription options, visit:
6673 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6674
6675
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>
6682
6683 That would be nice if that could be done at an interval the admin defines.
6684
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....
6688 < >
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?
6700 < > Just an idea...
6701
6702
6703
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>
6710
6711 Hi,
6712
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
6717 uplink-IRCd.
6718
6719 Georges
6720
6721 P.S. The original problem is not a services issue anyway...
6722
6723
6724 -----Urspr?ngliche Nachricht-----
6725 Von: ircservices-coding-bounces@ircservices.za.net
6726 [mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
6727 Craig Edwards
6728 Gesendet: Montag, 24. M?rz 2003 19:14
6729 An: IRC Services Coding Mailing List
6730 Betreff: Re: [IRCServices Coding] session limit bug
6731
6732
6733 I know people will probably ignore or shoot down this request but, here
6734 goes....
6735
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...
6745
6746 >I've found a bug.  Hoooray!
6747 >
6748 >When you use /msg OperServ raw svskill nickname :reason
6749 >
6750 >It kills the user with whatever reason -- however, when you use /msg
6751 OperServ session limit <number>
6752 >
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.
6758 >
6759 >Can this be fixed?
6760 >------------------------------------------------------------------
6761 >To unsubscribe or change your subscription options, visit:
6762 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6763
6764
6765 ------------------------------------------------------------------
6766 To unsubscribe or change your subscription options, visit:
6767 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6768
6769
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>
6775
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 :-)
6777
6778 >Hi,
6779 >
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
6784 >uplink-IRCd.
6785 >
6786 >Georges
6787 >
6788 >P.S. The original problem is not a services issue anyway...
6789 >
6790 >
6791 >-----Ursprüngliche Nachricht-----
6792 >Von: ircservices-coding-bounces@ircservices.za.net
6793 >[mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
6794 >Craig Edwards
6795 >Gesendet: Montag, 24. März 2003 19:14
6796 >An: IRC Services Coding Mailing List
6797 >Betreff: Re: [IRCServices Coding] session limit bug
6798 >
6799 >
6800 >I know people will probably ignore or shoot down this request but, here
6801 >goes....
6802 >
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...
6812 >
6813 >>I've found a bug.  Hoooray!
6814 >>
6815 >>When you use /msg OperServ raw svskill nickname :reason
6816 >>
6817 >>It kills the user with whatever reason -- however, when you use /msg
6818 >OperServ session limit <number>
6819 >>
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.
6825 >>
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
6830 >
6831 >
6832 >------------------------------------------------------------------
6833 >To unsubscribe or change your subscription options, visit:
6834 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6835 >
6836 >
6837 >------------------------------------------------------------------
6838 >To unsubscribe or change your subscription options, visit:
6839 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6840
6841
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>
6848
6849 It was 06:14 PM 3/24/2003 +0000 when Craig Edwards came up
6850 with:
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...
6862
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.
6866
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
6873 doing so.
6874
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.
6878
6879
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>
6886
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'
6889 inboxes.
6890
6891 Dylan.
6892
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
6899
6900
6901 > It was 06:14 PM 3/24/2003 +0000 when Craig Edwards came up
6902 > with:
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...
6914 >
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.
6918 >
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
6925 > doing so.
6926 >
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.
6930 >
6931 >
6932 > ------------------------------------------------------------------
6933 > To unsubscribe or change your subscription options, visit:
6934 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6935
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>
6941
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.
6944
6945 >It was 06:14 PM 3/24/2003 +0000 when Craig Edwards came up
6946 >with:
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...
6958 >
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.
6962 >
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
6969 >doing so.
6970 >
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.
6974 >
6975 >
6976 >------------------------------------------------------------------
6977 >To unsubscribe or change your subscription options, visit:
6978 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
6979
6980
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>
6988
6989 On Mon, 24 Mar 2003 15:05:51 JST, Andrew Church <achurch@achurch.org>
6990 wrote:
6991
6992 >> Don't top post.
6993 >
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.
6998 >
6999
7000 Okay, IJ :P
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>
7009
7010 On Monday 24 March 2003 20:22, Georges Berscheid wrote:
7011 > Hi,
7012 >
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
7017 > uplink-IRCd.
7018
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...
7023
7024 This can be almost transparent to the entire network.
7025
7026 > Georges
7027 <<V13>>
7028
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>
7036
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.
7046
7047 Georges
7048
7049
7050
7051 V13 wrote:
7052
7053 >On Monday 24 March 2003 20:22, Georges Berscheid wrote:
7054 >
7055 >
7056 >>Hi,
7057 >>
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
7062 >>uplink-IRCd.
7063 >>
7064 >>
7065 >
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...
7070 >
7071 >This can be almost transparent to the entire network.
7072 >
7073 >
7074 >
7075 >>Georges
7076 >>
7077 >>
7078 ><<V13>>
7079 >
7080 >
7081 >
7082 >
7083 >
7084
7085
7086
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>
7093
7094      There seems to be a lot of (mis)information floating around, so let me
7095 clear things up:
7096
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.
7102
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).
7106
7107   --Andrew Church
7108     achurch@achurch.org
7109     http://achurch.org/
7110
7111 >On Monday 24 March 2003 20:22, Georges Berscheid wrote:
7112 >> Hi,
7113 >>
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
7118 >> uplink-IRCd.
7119 >
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...
7124 >
7125 >This can be almost transparent to the entire network.
7126 >
7127 >> Georges
7128 ><<V13>>
7129 >
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>
7138
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
7148  (Ping timeout))
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
7152
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...
7154
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
7158
7159
7160 Cya
7161
7162 Diego Bitencourt Contezini aka destruct_ @ irc.redesul.net
7163
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>
7170
7171 Get a newer version.
7172
7173 David
7174
7175 -----Original Message-----
7176 From: ircservices-coding-bounces@ircservices.za.net
7177 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of
7178 diego@redesul.net
7179 Sent: Wednesday, April 02, 2003 12:41 AM
7180 To: ircservices-coding@ircservices.za.net
7181 Subject: [IRCServices Coding] HELP!!!
7182
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:
7193 0.0.0.0
7194  (Ping timeout))
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
7198
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...
7202
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
7206
7207
7208 Cya
7209
7210 Diego Bitencourt Contezini aka destruct_ @ irc.redesul.net
7211
7212 ------------------------------------------------------------------
7213 To unsubscribe or change your subscription options, visit:
7214 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
7215
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>
7222
7223 Hi all,
7224
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?
7228
7229 Alex
7230
7231
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>
7238
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
7241 quickly.
7242
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.
7246
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.
7250
7251 Okay so now you have the latest version under your belt. You have done
7252 ./configure and you are given this message:
7253
7254 *** WHOA THERE! ***
7255
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.
7259
7260 Please upgrade GCC to a newer version, or downgrade to
7261 version 2.95.3, before compiling Services.
7262
7263 See question B.1 in the FAQ for details.
7264
7265
7266 To save you the time of checking up in the FAQ, read below.
7267
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.
7270
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".
7278
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
7281         systems.
7282
7283
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.
7287
7288 Run the ./configure script with the following suffix:
7289
7290 ./configure -force-gcc-2.96
7291
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
7294 wish you luck.
7295
7296 Dylan.
7297
7298
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
7304
7305
7306 > Hi all,
7307 >
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?
7311 >
7312 > Alex
7313 >
7314 >
7315 > ------------------------------------------------------------------
7316 > To unsubscribe or change your subscription options, visit:
7317 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
7318
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>
7325
7326 >To save you the time of checking up in the FAQ, read below.
7327 >
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.
7330
7331      Just for the record, this is B.2.  B.1 reads as follows:
7332
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?
7335
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.
7350
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.
7355
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.
7361
7362   --Andrew Church
7363     achurch@achurch.org
7364     http://achurch.org/
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>
7371
7372 (Moved to the coding list--please keep technical discussion off of the main
7373 list.)
7374
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 ?
7378
7379      The user that sent the KICK is not currently sent to the callback.
7380 I'll see about changing this at some point.
7381
7382   --Andrew Church
7383     achurch@achurch.org
7384     http://achurch.org/
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>
7391
7392 Hi,
7393
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.
7396 Thanks :)
7397
7398 Georges
7399
7400 P.S. Sorry for having posted to the wrong list :-/
7401
7402 -----Urspr?ngliche Nachricht-----
7403 Von: ircservices-coding-bounces@ircservices.za.net
7404 [mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
7405 Andrew Church
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
7410
7411
7412 (Moved to the coding list--please keep technical discussion off of the
7413 main
7414 list.)
7415
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
7418 kicked.
7419 >Any help available on this ?
7420
7421      The user that sent the KICK is not currently sent to the callback.
7422 I'll see about changing this at some point.
7423
7424   --Andrew Church
7425     achurch@achurch.org
7426     http://achurch.org/
7427 ------------------------------------------------------------------
7428 To unsubscribe or change your subscription options, visit:
7429 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
7430
7431
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>
7437
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
7444 services.
7445
7446 Thank You.
7447
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>
7454
7455 Hi,
7456
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 :)
7465
7466 These are the directives for modules.conf:
7467
7468 Module mysql/main
7469     MySQLConfig Hostname Port Usename Password Database
7470 EndModule
7471 Module seenserv/main
7472     SeenServName SeenServ "Seen Service"
7473 EndModule
7474 Module adserv/main
7475     AdServName AdServ "Advertisement Service"
7476 EndModule
7477 Module quizserv/main
7478     QuizServName QuizServ "Luxusbuerg Quiz Service"
7479 EndModule
7480 Module logserv/main
7481     LogServName LogServ "Channel Logging Service"
7482 EndModule
7483
7484
7485 Good luck :)
7486
7487 Georges
7488
7489 -----Urspr?ngliche Nachricht-----
7490 Von: ircservices-coding-bounces@ircservices.za.net
7491 [mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
7492 Rayford Pomeroy
7493 Gesendet: Montag, 7. April 2003 20:09
7494 An: ircservices-coding@ircservices.za.net
7495 Betreff: [IRCServices Coding] SQL
7496
7497
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
7500 has
7501 started to do it. If so could you send me what you have so far? I would
7502 like
7503 to mess around with it, if I happen to get something to actually
7504 function
7505 (doubtful as my C skills are a joke) I would gladly release it to all.
7506 So
7507 please send me anything you have regarding the implementation of SQL
7508 into
7509 services.
7510
7511 Thank You.
7512
7513 ------------------------------------------------------------------
7514 To unsubscribe or change your subscription options, visit:
7515 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
7516
7517
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>
7523
7524 Have some converser from ircservices4db to xml?
7525 That convert on tools just convert from other types of services...
7526
7527 Someone coded it, or have some idea about how to do it?
7528
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>
7539
7540 Hi,
7541
7542 import your ircservices 4 databases into ircservices 5, and use the
7543 included xml export .
7544
7545 Georges
7546
7547
7548
7549 Diego Bitencourt Contezini wrote:
7550
7551 > Have some converser from ircservices4db to xml?
7552 >
7553 > That convert on tools just convert from other types of services?..
7554 >
7555 > Someone coded it, or have some idea about how to do it?
7556 >
7557 > Diego B. Contezini aka destruct_
7558 >
7559 >------------------------------------------------------------------------
7560 >
7561 >------------------------------------------------------------------
7562 >To unsubscribe or change your subscription options, visit:
7563 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
7564 >
7565 >
7566
7567
7568
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>
7574
7575 Hi all,
7576
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.
7580
7581 I write a long mail template, where I describe my network and services.
7582
7583
7584 Sorry for my english
7585
7586 Alex
7587
7588
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
7595 stampe.
7596
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 -----------------------------------------------------------------------------
7603
7604
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>
7611
7612 Hi,
7613
7614 if you change language files you need to watch (at least) 2 important
7615 things:
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.
7623
7624 Greets,
7625
7626 Georges
7627
7628
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
7636
7637
7638 Hi all,
7639
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
7642 would
7643 like register a new nick.
7644
7645 I write a long mail template, where I describe my network and services.
7646
7647
7648 Sorry for my english
7649
7650 Alex
7651
7652
7653 ------------------------------------------------------------------------
7654 -----
7655 Chi riceve il presente  messaggio e` tenuto a verificare se lo stesso
7656 non gli
7657 sia pervenuto per  errore.  In tal caso e` pregato di avvisare
7658 immediatamente
7659 il mittente  e,  tenuto  conto  delle  responsabilita` connesse
7660 all'indebito
7661 utilizzo e/o  divulgazione  del  messaggio  e/o  delle  informazioni  in
7662 esso
7663 contenute,  voglia  cancellare  l'originale  e distruggere  le varie
7664 copie  o
7665 stampe.
7666
7667 The receiver  of this message is required to check if  he/she has
7668 received it
7669 erroneously.  If  so,  the  receiver  is  requested to immediately
7670 inform the
7671 sender and - in consideration of the responsibilities  arising from
7672 undue use
7673 and/or disclosure of the message  and/or  the information contained
7674 therein -
7675 destroy the original message and any copy or printout thereof.
7676 ------------------------------------------------------------------------
7677 -----
7678
7679
7680 ------------------------------------------------------------------
7681 To unsubscribe or change your subscription options, visit:
7682 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
7683
7684
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>
7691
7692 I respect all things, but my mail is long i think
7693
7694 Regards
7695
7696 Alex
7697
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.
7701
7702
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
7709 stampe.
7710
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 -----------------------------------------------------------------------------
7717
7718
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>
7724
7725 Is it possible to have all services (operserv, nickserv, memoserv, helpserv,
7726 statserv, chanserv) join a channel ?
7727
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
7730 would be nice)
7731
7732 Thanks
7733
7734
7735
7736
7737
7738 _________________________________________________________________
7739
7740
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>
7746
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)
7751
7752 Bye
7753
7754
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
7761 >
7762 >Is it possible to have all services (operserv, nickserv, memoserv,
7763 >helpserv, statserv, chanserv) join a channel ?
7764 >
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
7767 >would be nice)
7768 >
7769 >Thanks
7770 >
7771 >
7772 >
7773 >
7774 >
7775 >_________________________________________________________________
7776 >
7777 >
7778 >------------------------------------------------------------------
7779 >To unsubscribe or change your subscription options, visit:
7780 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
7781
7782
7783 _________________________________________________________________
7784 Chat with your online buddies with MSN Messenger http://messenger.msn.be
7785
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>
7791
7792 Hi,
7793
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.
7797
7798 For ex:
7799
7800 Welcome
7801 Your code is: 168724492
7802 bla bla bla bla
7803 bla bla bla bla
7804 bla bla bla bla
7805
7806 I would like make:
7807
7808
7809 Welcome
7810
7811 Your code is: 168724492
7812
7813 bla bla bla bla
7814 bla bla bla bla
7815
7816 bla bla bla bla
7817
7818
7819 Thx
7820
7821 Alex
7822
7823
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
7830 stampe.
7831
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 -----------------------------------------------------------------------------
7838
7839
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>
7845
7846 Hi.
7847
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?
7851
7852 example; if i register #test the command to B would be /msg B B join #test
7853
7854 and ofcourse when dropping a channel, B would have to leave this channel.
7855
7856 example; dropping #test => /msg B B part #test
7857
7858 anyone that can give me a push in the right direction?
7859
7860 Thx
7861
7862
7863
7864
7865
7866 _________________________________________________________________
7867 MSN Search, for relevant search results! http://search.msn.be
7868
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>
7875
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:
7877
7878 basically, /msg somepseudoclient su <nick> <pass>
7879
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.
7881
7882 NickInfo* MyNickInf = get_nickinfo(somenick);
7883 NickGroupInfo* MyNGroupInf = get_ngi(MyNickInf);
7884
7885 u->ngi = MyNGroupInf;
7886 u->ni = MyNickInf;
7887 /* user u is now logged in with privilages of "ngi" nick, send +r as a raw if neccessary */
7888
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 :)
7891
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 :)
7893
7894 Thanks,
7895 Brain
7896 ChatSpike Services-dev
7897
7898
7899
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
7904         at once
7905 References: <200304221424.h3MEO4A24908@localhost.localdomain>
7906 Message-ID: <3EA55459.9000200@berscheid.lu>
7907
7908 Hi,
7909
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
7914 any experience :)
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
7920 using SU.
7921
7922 Georges
7923
7924
7925
7926 Craig Edwards wrote:
7927
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:
7929 >
7930 >basically, /msg somepseudoclient su <nick> <pass>
7931 >
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.
7933 >
7934 >NickInfo* MyNickInf = get_nickinfo(somenick);
7935 >NickGroupInfo* MyNGroupInf = get_ngi(MyNickInf);
7936 >
7937 >u->ngi = MyNGroupInf;
7938 >u->ni = MyNickInf;
7939 >/* user u is now logged in with privilages of "ngi" nick, send +r as a raw if neccessary */
7940 >
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 :)
7943 >
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 :)
7945 >
7946 >Thanks,
7947 >Brain
7948 >ChatSpike Services-dev
7949 >
7950 >
7951 >
7952 >------------------------------------------------------------------
7953 >To unsubscribe or change your subscription options, visit:
7954 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
7955 >
7956 >
7957 >
7958 >
7959
7960
7961
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
7966         once
7967 In-Reply-To: <200304221424.h3MEO4A24908@localhost.localdomain>
7968 Message-ID: <3ea5ec02.17430@mail.achurch.org>
7969
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.
7977
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
7981 probably break.
7982
7983      I'd strongly suggest finding another way to accomplish whatever you're
7984 trying to do without an "su"-like command.
7985
7986   --Andrew Church
7987     achurch@achurch.org
7988     http://achurch.org/
7989
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:
7991 >
7992 >basically, /msg somepseudoclient su <nick> <pass>
7993 >
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.
7995 >
7996 >NickInfo* MyNickInf = get_nickinfo(somenick);
7997 >NickGroupInfo* MyNGroupInf = get_ngi(MyNickInf);
7998 >
7999 >u->ngi = MyNGroupInf;
8000 >u->ni = MyNickInf;
8001 >/* user u is now logged in with privilages of "ngi" nick, send +r as a raw if neccessary */
8002 >
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 :)
8007 >
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 :)
8009 >
8010 >Thanks,
8011 >Brain
8012 >ChatSpike Services-dev
8013 >
8014 >
8015 >
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
8021         nicks atonce
8022 Message-ID: <20030424052202.QLHP12018.mta06-svc.ntlworld.com@i-br0ked-it>
8023
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...
8025
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.
8027
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
8030
8031 So yeah, any other solutions would be great :)
8032
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 -----------------------------------------------------------------------
8039
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
8045 >Date     : 2003-04-23
8046 >
8047 >
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.
8055 >
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
8059 >probably break.
8060 >
8061 >     I'd strongly suggest finding another way to accomplish whatever you're
8062 >trying to do without an "su"-like command.
8063 >
8064 >  --Andrew Church
8065 >    achurch@achurch.org
8066 >    http://achurch.org/
8067 >
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:
8069 >>
8070 >>basically, /msg somepseudoclient su <nick> <pass>
8071 >>
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.
8073 >>
8074 >>NickInfo* MyNickInf = get_nickinfo(somenick);
8075 >>NickGroupInfo* MyNGroupInf = get_ngi(MyNickInf);
8076 >>
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 */
8080 >>
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 :)
8085 >>
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 :)
8087 >>
8088 >>Thanks,
8089 >>Brain
8090 >>ChatSpike Services-dev
8091 >>
8092 >>
8093 >>
8094 >>------------------------------------------------------------------
8095 >------------------------------------------------------------------
8096 >To unsubscribe or change your subscription options, visit:
8097 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
8098 >.
8099 ========= End of Original Message =========
8100
8101
8102
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
8107         atonce
8108 References: <20030424052202.QLHP12018.mta06-svc.ntlworld.com@i-br0ked-it>
8109 Message-ID: <3EA79F6D.6080504@berscheid.lu>
8110
8111 Hi,
8112
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.
8123
8124 Georges
8125
8126
8127
8128 Craig McLure wrote:
8129
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...
8131 >
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.
8133 >
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
8136 >
8137 >So yeah, any other solutions would be great :)
8138 >
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 >-----------------------------------------------------------------------
8145 >
8146 >============ Original Message ============
8147 >>From     : "Andrew Church" <achurch@achurch.org>
8148 >
8149 >
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
8153 >>Date     : 2003-04-23
8154 >>
8155 >>
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.
8163 >>
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
8167 >>probably break.
8168 >>
8169 >>    I'd strongly suggest finding another way to accomplish whatever you're
8170 >>trying to do without an "su"-like command.
8171 >>
8172 >> --Andrew Church
8173 >>   achurch@achurch.org
8174 >>   http://achurch.org/
8175 >>
8176 >>
8177 >>
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:
8179 >>>
8180 >>>basically, /msg somepseudoclient su <nick> <pass>
8181 >>>
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.
8183 >>>
8184 >>>NickInfo* MyNickInf = get_nickinfo(somenick);
8185 >>>NickGroupInfo* MyNGroupInf = get_ngi(MyNickInf);
8186 >>>
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 */
8190 >>>
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 :)
8195 >>>
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 :)
8197 >>>
8198 >>>Thanks,
8199 >>>Brain
8200 >>>ChatSpike Services-dev
8201 >>>
8202 >>>
8203 >>>
8204 >>>------------------------------------------------------------------
8205 >>>
8206 >>>
8207 >>------------------------------------------------------------------
8208 >>To unsubscribe or change your subscription options, visit:
8209 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
8210 >>.
8211 >>
8212 >>
8213 >========= End of Original Message =========
8214 >
8215 >
8216 >
8217 >------------------------------------------------------------------
8218 >To unsubscribe or change your subscription options, visit:
8219 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
8220 >
8221 >
8222 >
8223 >
8224
8225
8226
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
8231         nicks atonce
8232 In-Reply-To: <20030424052202.QLHP12018.mta06-svc.ntlworld.com@i-br0ked-it>
8233 Message-ID: <3ea7d994.01413@mail.achurch.org>
8234
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.
8237
8238      Would an HTTP server module similar to the dbaccess module (but
8239 having additional access checks in place, obviously) work?
8240
8241   --Andrew Church
8242     achurch@achurch.org
8243     http://achurch.org/
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
8248         nicksatonce
8249 Message-ID: <200304252009.h3PK9pA25637@localhost.localdomain>
8250
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 ;-)
8252
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 :)
8254
8255 Anyhow, have fun,
8256 Brain :-)
8257
8258 >Hi,
8259 >
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.
8270 >
8271 >Georges
8272 >
8273 >
8274 >
8275 >Craig McLure wrote:
8276 >
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...
8278 >>
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.
8280 >>
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
8283 >>
8284 >>So yeah, any other solutions would be great :)
8285 >>
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 >>-----------------------------------------------------------------------
8292 >>
8293 >>============ Original Message ============
8294 >>>From     : "Andrew Church" <achurch@achurch.org>
8295 >>
8296 >>
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
8301 >>>
8302 >>>
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.
8310 >>>
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
8314 >>>probably break.
8315 >>>
8316 >>>    I'd strongly suggest finding another way to accomplish whatever you're
8317 >>>trying to do without an "su"-like command.
8318 >>>
8319 >>> --Andrew Church
8320 >>>   achurch@achurch.org
8321 >>>   http://achurch.org/
8322 >>>
8323 >>>
8324 >>>
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:
8326 >>>>
8327 >>>>basically, /msg somepseudoclient su <nick> <pass>
8328 >>>>
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.
8330 >>>>
8331 >>>>NickInfo* MyNickInf = get_nickinfo(somenick);
8332 >>>>NickGroupInfo* MyNGroupInf = get_ngi(MyNickInf);
8333 >>>>
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 */
8337 >>>>
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 :)
8342 >>>>
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 :)
8344 >>>>
8345 >>>>Thanks,
8346 >>>>Brain
8347 >>>>ChatSpike Services-dev
8348 >>>>
8349 >>>>
8350 >>>>
8351 >>>>------------------------------------------------------------------
8352 >>>>
8353 >>>>
8354 >>>------------------------------------------------------------------
8355 >>>To unsubscribe or change your subscription options, visit:
8356 >>>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
8357 >>>.
8358 >>>
8359 >>>
8360 >>========= End of Original Message =========
8361 >>
8362 >>
8363 >>
8364 >>------------------------------------------------------------------
8365 >>To unsubscribe or change your subscription options, visit:
8366 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
8367 >>
8368 >>
8369 >>
8370 >>
8371 >
8372 >
8373 >
8374 >------------------------------------------------------------------
8375 >To unsubscribe or change your subscription options, visit:
8376 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
8377
8378
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
8383  twonicksatonce
8384 In-Reply-To: <200304252009.h3PK9pA25637@localhost.localdomain>
8385 Message-ID: <000b01c30bd9$dc86b3d0$45c918d4@gizmo>
8386
8387 Hi,
8388
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
8391
8392 Channel *chan;
8393 for(chan = first_channel(); chan; chan = next_channel()) {
8394     <your code>
8395 }
8396
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.
8402
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
8412 ;-)
8413
8414 Georges
8415
8416
8417 -----Urspr?ngliche Nachricht-----
8418 Von: ircservices-coding-bounces@ircservices.za.net
8419 [mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
8420 Craig Edwards
8421 Gesendet: Freitag, 25. April 2003 23:01
8422 An: IRC Services Coding Mailing List
8423 Betreff: Re: Re: [IRCServices Coding] Associating NickGroupInfo with
8424 twonicksatonce
8425
8426
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 ;-)
8432
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
8437 statserv works :)
8438
8439 Anyhow, have fun,
8440 Brain :-)
8441
8442 >Hi,
8443 >
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
8452
8453 >a bot that connects to your network, use any (possibly exploitable)
8454 >commands and parse the output.
8455 >
8456 >Georges
8457 >
8458 >
8459 >
8460 >Craig McLure wrote:
8461 >
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...
8464 >>
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.
8472 >>
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
8476 >>
8477 >>So yeah, any other solutions would be great :)
8478 >>
8479 >>----------------------------------------------------------------------
8480 -
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 >>----------------------------------------------------------------------
8487 -
8488 >>
8489 >>============ Original Message ============
8490 >>>From     : "Andrew Church" <achurch@achurch.org>
8491 >>
8492 >>
8493 >>>Reply-To : ircservices-coding@ircservices.za.net
8494 >>>To       : ircservices-coding@ircservices.za.net
8495 >>>Subject  : Re: [IRCServices Coding]  Associating NickGroupInfo with
8496 two nicks atonce
8497 >>>Date     : 2003-04-23
8498 >>>
8499 >>>
8500 >>>    The code currently assumes that at most one user will be
8501 associated
8502 >>>with any particular nickname, that NickInfo.user will point at the
8503 user
8504 >>>with nickname NickInfo.nick, that User.ni will point at the NickInfo
8505 with
8506 >>>nickname User.nick (or NULL if the nickname is not registered), and
8507 that
8508 >>>User.ngi will point to a nickname group containing User.ni (or NULL
8509 or
8510 >>>NICKGROUPINFO_INVALID).  Breaking any of these assumptions will
8511 probably
8512 >>>cause many weird and dangerous things to happen.
8513 >>>
8514 >>>    Note that two or more users can be associated with a single nick
8515 group
8516 >>>(if, for example, someone has two clients open and using two linked
8517 nicks).
8518 >>>However, if the user's nick is not in NickGroupInfo.nicks[], things
8519 will
8520 >>>probably break.
8521 >>>
8522 >>>    I'd strongly suggest finding another way to accomplish whatever
8523 you're
8524 >>>trying to do without an "su"-like command.
8525 >>>
8526 >>> --Andrew Church
8527 >>>   achurch@achurch.org
8528 >>>   http://achurch.org/
8529 >>>
8530 >>>
8531 >>>
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
8534 how it works:
8535 >>>>
8536 >>>>basically, /msg somepseudoclient su <nick> <pass>
8537 >>>>
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
8541 nickname, e.g.
8542 >>>>
8543 >>>>NickInfo* MyNickInf = get_nickinfo(somenick);
8544 >>>>NickGroupInfo* MyNGroupInf = get_ngi(MyNickInf);
8545 >>>>
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 */
8550 >>>>
8551 >>>>sorry for any errors in this code, im typing it off the top of my
8552 head.
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 :)
8565 >>>>
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 :)
8569 >>>>
8570 >>>>Thanks,
8571 >>>>Brain
8572 >>>>ChatSpike Services-dev
8573 >>>>
8574 >>>>
8575 >>>>
8576 >>>>------------------------------------------------------------------
8577 >>>>
8578 >>>>
8579 >>>------------------------------------------------------------------
8580 >>>To unsubscribe or change your subscription options, visit:
8581 >>>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
8582 >>>.
8583 >>>
8584 >>>
8585 >>========= End of Original Message =========
8586 >>
8587 >>
8588 >>
8589 >>------------------------------------------------------------------
8590 >>To unsubscribe or change your subscription options, visit:
8591 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
8592 >>
8593 >>
8594 >>
8595 >>
8596 >
8597 >
8598 >
8599 >------------------------------------------------------------------
8600 >To unsubscribe or change your subscription options, visit:
8601 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
8602
8603
8604 ------------------------------------------------------------------
8605 To unsubscribe or change your subscription options, visit:
8606 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
8607
8608
8609
8610
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>
8616
8617 Hello there :),
8618
8619
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 :)...
8623
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
8632 identify'ing.
8633
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.
8643
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 :)...
8647
8648 RFC please =)...
8649
8650
8651 best regards,
8652 - wahoo -
8653
8654 --
8655 B.O.F.H @ cyb.net ;D
8656
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>
8664
8665 Hello4
8666
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?
8670
8671 You are lucky, here is a patch (it isn't mine, don't think that):
8672
8673 http://www.nikhok.hu/~xanco/download/vhost.html
8674
8675 --
8676 Krisztian Romek
8677 r-krisztian@softhome.net
8678
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>
8687
8688 Hello Krisztian,
8689
8690
8691
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?
8695
8696 > You are lucky, here is a patch (it isn't mine, don't think that):
8697
8698 > http://www.nikhok.hu/~xanco/download/vhost.html
8699
8700
8701 Thx alot ...I'll give it a try :)
8702
8703 best regards,
8704 - wahoo -
8705
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>
8711
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.
8713
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 :-)
8715
8716 >Hello there :),
8717 >
8718 >
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 :)...
8722 >
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
8731 >identify'ing.
8732 >
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.
8742 >
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 :)...
8746 >
8747 >RFC please =)...
8748 >
8749 >
8750 >best regards,
8751 >- wahoo -
8752 >
8753 >--
8754 >B.O.F.H @ cyb.net ;D
8755 >
8756 >------------------------------------------------------------------
8757 >To unsubscribe or change your subscription options, visit:
8758 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
8759
8760
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>
8766
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
8770 would be good too.
8771
8772
8773
8774 If someone could show me some examples of both those ways, would be a
8775 great help
8776
8777
8778
8779
8780
8781 Thanks
8782
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>
8792
8793      Added for 5.0.19.
8794
8795   --Andrew Church
8796     achurch@achurch.org
8797     http://achurch.org/
8798
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.
8803 >
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.
8806 >
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
8810 >***************
8811 >*** 919,924 ****
8812 >--- 919,932 ----
8813 >
8814 >      #CSForbidShortChannel
8815 >
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.
8821 >+
8822 >+     #CSRegisteredOnly
8823 >+
8824 >  EndModule
8825 >
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
8830 >***************
8831 >*** 1722,1727 ****
8832 >--- 1722,1739 ----
8833 >
8834 >  <p>Example: <tt>CSForbidShortChannel</tt>
8835 >  </ul>
8836 >+
8837 >+ <a name="chanserv/main.CSRegisteredOnly"></a>
8838 >+ <p><ul><li>
8839 >+ <tt><b>CSRegisteredOnly</b></tt>&nbsp;&nbsp;&nbsp;&nbsp;[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.
8844 >+
8845 >+ <p>Example: <tt>CSRegisteredOnly</tt>
8846 >+ </ul>
8847 >+
8848 >  <a name="chanserv/sendpass"></a>
8849 >  <p><font size="+1"><b>chanserv/sendpass</b> (SENDPASS module)</font>
8850 >
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
8854 >***************
8855 >*** 274,281 ****
8856 >       goto kick;
8857 >      }
8858 >
8859 >!     if (!ci)
8860 >!      return 0;
8861 >
8862 >      if (is_services_admin(user))
8863 >       return 0;
8864 >--- 274,288 ----
8865 >       goto kick;
8866 >      }
8867 >
8868 >!     if (!ci) {
8869 >!      if(CSRegisteredOnly && !is_oper(user)) {
8870 >!          mask = sstrdup("*!*@*");
8871 >!          reason = getstring(user->ngi, CHAN_MAY_NOT_BE_USED);
8872 >!          goto kick;
8873 >!      } else {
8874 >!          return 0;
8875 >!      }
8876 >!     }
8877 >
8878 >      if (is_services_admin(user))
8879 >       return 0;
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
8883 >***************
8884 >*** 93,98 ****
8885 >--- 93,99 ----
8886 >  E time_t CSSuspendExpire;
8887 >  E time_t CSSuspendGrace;
8888 >  E int    CSForbidShortChannel;
8889 >+ E int    CSRegisteredOnly;
8890 >  E ChanOpt chanopts[];
8891 >
8892 >
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
8896 >***************
8897 >*** 57,62 ****
8898 >--- 57,63 ----
8899 >         time_t CSSuspendExpire;
8900 >         time_t CSSuspendGrace;
8901 >         int    CSForbidShortChannel;
8902 >+        int    CSRegisteredOnly;
8903 >  EXPORT_VAR(int32,CSMaxReg)
8904 >
8905 >  /*************************************************************************/
8906 >***************
8907 >*** 1606,1611 ****
8908 >--- 1607,1613 ----
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>
8925
8926      Fixed for 5.0.19.
8927
8928   --Andrew Church
8929     achurch@achurch.org
8930     http://achurch.org/
8931
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.
8939 >
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)
8942 >
8943 >Regards,
8944 >
8945 >George Stamatiou
8946 >master@xchat.gr
8947 >
8948 >
8949 >
8950 >
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>
8959
8960 Hi there,
8961
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.
8963
8964 We are using Unreal3.2b15
8965
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>
8991
8992 Here's a protocol/hybrid.c that can be used for hyb7. Issues include:
8993
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.
8995
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.
8997
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. :/
8999
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...
9003 Name: hybrid.c
9004 Type: application/octet-stream
9005 Size: 11492 bytes
9006 Desc: hybrid.c
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>
9014
9015 Hi there,
9016
9017 In future, please do not post attachments to this list. Please post the URL
9018 where files can be downloaded.
9019
9020 Thanks, Andrew
9021
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
9027
9028
9029 > Here's a protocol/hybrid.c that can be used for hyb7. Issues include:
9030 >
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.
9034 >
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
9037 a look.
9038 >
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. :/
9042 >
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.
9047 >
9048
9049
9050 ----------------------------------------------------------------------------
9051 ----
9052
9053
9054 > ------------------------------------------------------------------
9055 > To unsubscribe or change your subscription options, visit:
9056 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
9057 >
9058
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>
9064
9065 Sorry :/
9066
9067 Anyway, few corrections, I had some leftover stuff("Bahamut" protocol and a leftover useless SJOIN modifier), which I fixed. New release:
9068
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>
9076
9077 Thanks :)
9078
9079 Andrew
9080
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
9087
9088
9089 > Sorry :/
9090 >
9091 > Anyway, few corrections, I had some leftover stuff("Bahamut" protocol and
9092 a leftover useless SJOIN modifier), which I fixed. New release:
9093 >
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
9098 >
9099 >
9100
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>
9106
9107 Hi,
9108
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
9112 sqlines.
9113
9114 Any comments?
9115
9116
9117 Thanks,
9118 Aragon
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>
9125
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
9132 method=post>
9133 <input type="hidden"  name="xml"
9134 value="<nicknamefock>blabla</nicknamefock>">
9135 <input type="Submit" value="Send">
9136 </form>
9137
9138
9139 ....... .. ..
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 ;)
9143
9144 Thanks for all
9145
9146 Diego Bitencourt Contezini aka destruct_ @irc.redesul.net
9147
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>
9153
9154 Okay, I now have this patch running on a 1500-user Hyb7 net and it appears to be stable :) Final corrections and notes -
9155
9156 1) In do_send_akill I had s_OperServ instead of who. Don't ask what I was smoking. >.>
9157
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.
9159
9160 3) Makefile modifications are as follows:
9161
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
9164 [..]
9165 OBJECTS-dreamforge.so = svsnick.o
9166 OBJECTS-hybrid.so = banexcept.o halfop.o sjoin.o
9167 OBJECTS-monkey.so = halfop.o sjoin.o
9168 [..]
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 \
9175 [..]
9176
9177 Anyone want to make a decent Makefile patch? :)
9178
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>
9185
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
9192 Operator).
9193
9194
9195
9196 If someone can give me some insight, it would be greatly appreciated.
9197
9198
9199
9200 ### Modules/protocol/dreamforge.c ###
9201
9202 --- WORKING UMODE +C CODE ---
9203
9204       case 'C':
9205
9206         if (is_oper(user)) {
9207
9208             if (user->ngi->os_priv == NP_SERVOPER) {
9209
9210                 if (!add)
9211
9212                     send_cmd(ServerName, "SVSMODE %s +C", user->nick);
9213
9214             } else {
9215
9216                 if (add)
9217
9218                     send_cmd(ServerName, "SVSMODE %s -C", user->nick);
9219
9220             }
9221
9222             return 1;
9223
9224         }
9225
9226
9227
9228 --- NOT WORKING UMODE +R CODE ---
9229
9230       case 'R':
9231
9232         if (is_oper(user)) {
9233
9234             if (stricmp(user->nick, ServicesRoot) == 0) {
9235
9236                 if (!add)
9237
9238                     send_cmd(ServerName, "SVSMODE %s +R", user->nick);
9239
9240             } else {
9241
9242                 if (add)
9243
9244                     send_cmd(ServerName, "SVSMODE %s -R", user->nick);
9245
9246             }
9247
9248             return 1;
9249
9250         }
9251
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>
9260
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.
9265
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?
9271
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?
9275
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
9280 to begin with.
9281
9282 Thanks for any help anyone has to offer!
9283
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 *-----------------------------------*
9291
9292
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>
9298
9299 I have a question, hopefully someone can help...
9300
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.
9307
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.
9313
9314 Thanks,
9315
9316 Benjamin Higginbotham
9317 draco@silverdragonden.com
9318 www.silverdragonden.com
9319
9320
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>
9326
9327 Okay, here are the issues and solutions:
9328
9329 1) Hybrid requires an online nick to set remote klines. So I imported s_OperServ to set all akills.
9330
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.
9332
9333 3) Remote JOINs need a timestamp. Use the following patch on modules/chanserv/check.c:
9334
9335 http://www.angelfire.com/az3/d-mstats/check.diff
9336
9337 4) Implementing into modules/protocol/Makefile:
9338
9339 http://www.angelfire.com/az3/d-mstats/make.diff
9340
9341 And finally:
9342
9343 http://www.angelfire.com/az3/d-mstats/hybrid.c
9344
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>
9351
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
9355 time).
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 :-).
9360
9361 Is it:
9362
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
9367 identified for
9368 nick bash
9369
9370 Program received signal SIGSEGV, Segmentation fault.
9371 do_cmode (source=0x8065368 "ChanServ", ac=-3, av=0xbfffed68) at
9372 channels.c:251
9373 251         while (*s) {
9374 (gdb) bt'
9375 #0  do_cmode (source=0x8065368 "ChanServ", ac=-3, av=0xbfffed68)
9376     at channels.c:251
9377         source = 0x8065368 "ChanServ"
9378         ac = -3
9379         av = (char **) 0xbfffed68
9380         chan = (Channel *) 0x88e9218
9381         s = 0x2e646165 <Address 0x2e646165 out of bounds>
9382        add = 1
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>
9394
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
9399 \00312#\00314FoRbId
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>}
9413         len = 24
9414         i = 0
9415         lastc = 45 '-'
9416 #2  0x0804d113 in set_cmode (sender=0x0, channel=0x0) at actions.c:284
9417         args = 0xbffff420
9418         modes = 0xbffff4b8 "\030???jr\005\bX?3\n\037"
9419         modes_orig = 0xbffff460 "{Cris}"
9420         md = (struct modedata *) 0x0
9421         which = -1
9422         add = 2
9423         i = 0
9424         c = -65 '?'
9425         s = 0xffffffff <Address 0xffffffff out of bounds>
9426         args = 0xbffff420
9427         modes = 0xbffff4b8 "\030???jr\005\bX?3\n\037"
9428         modes_orig = 0xbffff460 "{Cris}"
9429         add = 2
9430         c = -65 '?'
9431
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>
9440
9441 I HATE LIMITS!
9442 #3  0x08052ddc in main (ac=2, av=0xbffff6a4, envp=0xbffff6b0) at
9443 main.c:277
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
9459 (gdb)
9460 (gdb) info registers
9461 eax            0x2e646165       778330469
9462 ecx            0x88e9227        143561255
9463 edx            0xffffffff       -1
9464 ebx            0x1      1
9465 esp            0xbfffed00       0xbfffed00
9466 ebp            0xbfffed38       0xbfffed38
9467 esi            0x0      0
9468 edi            0x88e9218        143561240
9469 eip            0x804daf3        0x804daf3
9470 eflags         0x10282  66178
9471 cs             0x23     35
9472 ss             0x2b     43
9473 ds             0x2b     43
9474 es             0x2b     43
9475 fs             0x0      0
9476 gs             0x0      0
9477 fctrl          0x37f    895
9478 fstat          0x841    2113
9479 ftag           0xffff   65535
9480 fiseg          0x23     35
9481 fioff          0x40157be1       1075149793
9482 foseg          0x2b     43
9483 fooff          0x0      0
9484 ---Type <return> to continue, or q <return> to quit---
9485 fop            0x5d8    1496
9486 xmm0           0xffffffffffffffffffffffffffffffff
9487 xmm1           0xffffffffffffffffffffffffffffffff
9488 xmm2           0xffffffffffffffffffffffffffffffff
9489 xmm3           0xffffffffffffffffffffffffffffffff
9490 xmm4           0xffffffffffffffffffffffffffffffff
9491 xmm5           0xffffffffffffffffffffffffffffffff
9492 xmm6           0xffffffffffffffffffffffffffffffff
9493 xmm7           0xffffffffffffffffffffffffffffffff
9494 mxcsr          0x1f80   8064
9495 (gdb)
9496
9497
9498 If i can do something more to help, please give me ideas and I will to
9499 all to help on debugging :]
9500
9501 Great.
9502 (sorry for my fucking dumb bad English :-)
9503 Diego Bitencourt Contezini aka destruct_ @ irc.redesul.net
9504
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>
9513
9514 Andrew, or someone.. have any idea about what can be this bug?
9515
9516 Thanks for all.
9517
9518
9519 Diego
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>
9529
9530 Hello.
9531 Is there any way to avoid users with no access in that channel to do /cs aop/sop #channel list ?
9532
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.
9535
9536 Thanks
9537
9538 George Stamatiou
9539
9540
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>
9549
9550
9551 Hello;
9552
9553 For info:
9554
9555 /cs help levels
9556 /cs help levels desc
9557 /cs levels #channel list
9558
9559 To accomplish that what you are willing to do:
9560 /cs levels #channel set acc-change 50
9561
9562 Regards;
9563 yusuf
9564
9565
9566
9567 On Sat, 2003-05-17 at 20:49, George Stamatiou wrote:
9568 > Hello.
9569 > Is there any way to avoid users with no access in that channel to do /cs aop/sop #channel list ?
9570 >
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.
9573 >
9574 > Thanks
9575 >
9576 > George Stamatiou
9577 >
9578 >
9579 > ------------------------------------------------------------------
9580 > To unsubscribe or change your subscription options, visit:
9581 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
9582 --
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 ------------------------------------------------------------------
9589
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>
9596
9597      I can't find any obvious reason for this.  Can you provide a debug
9598 log?
9599
9600   --Andrew Church
9601     achurch@achurch.org
9602     http://achurch.org/
9603
9604 >This is a multi-part message in MIME format.
9605 >
9606 >--===============22718851767480919==
9607 >Content-Type: multipart/alternative;
9608 >       boundary="----=_NextPart_000_0009_01C30F56.97D971C0"
9609 >
9610 >This is a multi-part message in MIME format.
9611 >
9612 >------=_NextPart_000_0009_01C30F56.97D971C0
9613 >Content-Type: text/plain;
9614 >       charset="iso-8859-1"
9615 >Content-Transfer-Encoding: quoted-printable
9616 >
9617 >Hi there,
9618 >
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.
9622 >
9623 >We are using Unreal3.2b15
9624 >
9625 >[Apr 30 18:40:02 2003] protocol/unreal: m_sethost: user record for asli =
9626 >not found
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 =
9630 >not found
9631 >[Apr 30 18:41:03 2003] protocol/unreal: m_sethost: user record for =
9632 >^KnOc^ not found
9633 >[Apr 30 18:41:50 2003] protocol/unreal: m_sethost: user record for kddnt =
9634 >not found
9635 >[Apr 30 18:44:46 2003] protocol/unreal: m_sethost: user record for ombha =
9636 >not found
9637 >[Apr 30 18:45:00 2003] protocol/unreal: m_sethost: user record for =
9638 >fAnself not found
9639 >[Apr 30 18:45:20 2003] protocol/unreal: m_sethost: user record for =
9640 >xqejtw not found
9641 >[Apr 30 18:45:27 2003] protocol/unreal: m_sethost: user record for =
9642 >Nikolaus not found
9643 >[Apr 30 18:46:10 2003] protocol/unreal: m_sethost: user record for adsur =
9644 >not found
9645 >[Apr 30 18:46:43 2003] protocol/unreal: m_sethost: user record for =
9646 >dAdrianc not found
9647 >[Apr 30 18:48:35 2003] protocol/unreal: m_sethost: user record for =
9648 >cmjdjm2 not found
9649 >[Apr 30 18:49:35 2003] protocol/unreal: m_sethost: user record for =
9650 >[Theo] not found
9651 >[Apr 30 18:50:00 2003] protocol/unreal: m_sethost: user record for ybemj =
9652 >not found  =20
9653 >[Apr 30 18:50:04 2003] protocol/unreal: m_sethost: user record for =
9654 >Hardie not found
9655 >[Apr 30 18:50:22 2003] protocol/unreal: m_sethost: user record for =
9656 >[Odolf] not found
9657 >[Apr 30 18:51:12 2003] protocol/unreal: m_sethost: user record for Tino =
9658 >not found
9659 >------=_NextPart_000_0009_01C30F56.97D971C0
9660 >Content-Type: text/html;
9661 >       charset="iso-8859-1"
9662 >Content-Transfer-Encoding: quoted-printable
9663 >
9664 ><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
9665 ><HTML><HEAD>
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>
9669 ><STYLE></STYLE>
9670 ></HEAD>
9671 ><BODY bgColor=3D#ffffff>
9672 ><DIV><FONT face=3DArial size=3D2>Hi there,</FONT></DIV>
9673 ><DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
9674 ><DIV><FONT face=3DArial size=3D2>Just checked my ircservices log and I =
9675 >found=20
9676 >something I have not seen so far, I was wondering if anyone could please =
9677 >shed=20
9678 >some light onto it?&nbsp; This is happening consistently.</FONT></DIV>
9679 ><DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
9680 ><DIV><FONT face=3DArial size=3D2>We are using Unreal3.2b15</FONT></DIV>
9681 ><DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
9682 ><DIV><FONT face=3DArial size=3D2>[Apr 30 18:40:02 2003] protocol/unreal: =
9683 >m_sethost:=20
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&nbsp;&nbsp; <BR>[Apr 30 =
9687 >18:40:52=20
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 =
9692 >for=20
9693 >kddnt not found<BR>[Apr 30 18:44:46 2003] protocol/unreal: m_sethost: =
9694 >user=20
9695 >record for ombha not found<BR>[Apr 30 18:45:00 2003] protocol/unreal: =
9696 >m_sethost:=20
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 =
9701 >30=20
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 =
9704 >for=20
9705 >dAdrianc not found<BR>[Apr 30 18:48:35 2003] protocol/unreal: m_sethost: =
9706 >user=20
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&nbsp;&nbsp; =
9710 ><BR>[Apr=20
9711 >30 18:50:04 2003] protocol/unreal: m_sethost: user record for Hardie not =
9712 >
9713 >found<BR>[Apr 30 18:50:22 2003] protocol/unreal: m_sethost: user record =
9714 >for=20
9715 >[Odolf] not found<BR>[Apr 30 18:51:12 2003] protocol/unreal: m_sethost: =
9716 >user=20
9717 >record for Tino not found</FONT></DIV></BODY></HTML>
9718 >
9719 >------=_NextPart_000_0009_01C30F56.97D971C0--
9720 >
9721 >
9722 >--===============22718851767480919==
9723 >Content-Type: text/plain; charset="us-ascii"
9724 >MIME-Version: 1.0
9725 >Content-Transfer-Encoding: 7bit
9726 >Content-Disposition: inline
9727 >
9728 >------------------------------------------------------------------
9729 >To unsubscribe or change your subscription options, visit:
9730 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
9731 >
9732 >--===============22718851767480919==--
9733 >
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>
9742
9743 I know that :-).
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.
9746 Any idea ?
9747
9748
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
9754
9755
9756 :
9757 : Hello;
9758 :
9759 : For info:
9760 :
9761 : /cs help levels
9762 : /cs help levels desc
9763 : /cs levels #channel list
9764 :
9765 : To accomplish that what you are willing to do:
9766 : /cs levels #channel set acc-change 50
9767 :
9768 : Regards;
9769 : yusuf
9770 :
9771 :
9772 :
9773 : On Sat, 2003-05-17 at 20:49, George Stamatiou wrote:
9774 : > Hello.
9775 : > Is there any way to avoid users with no access in that channel to do /cs aop/sop #channel list ?
9776 : >
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.
9779 : >
9780 : > Thanks
9781 : >
9782 : > George Stamatiou
9783 : >
9784 : >
9785 : > ------------------------------------------------------------------
9786 : > To unsubscribe or change your subscription options, visit:
9787 : > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
9788 : --
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 : ------------------------------------------------------------------
9795 :
9796 : ------------------------------------------------------------------
9797 : To unsubscribe or change your subscription options, visit:
9798 : http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
9799 :
9800
9801
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>
9807
9808 Hello,
9809
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
9818 already.
9819
9820
9821 Thanks,
9822 Rayford Pomeroy
9823
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>
9830
9831 >Here's a protocol/hybrid.c that can be used for hyb7. Issues include:
9832
9833      Thanks, I'll look into adding it in when I fork the source for 5.1.
9834
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.
9838
9839      You can override the m_xxx() functions in messages.c by adding an
9840 appropriate entry to the protocol's message table:
9841
9842 static void m_hybrid_topic(...) { ... }
9843 static Message hybrid_messages[] = {
9844     /* ... */
9845     { "TOPIC",     m_hybrid_topic },
9846 };
9847
9848 Then just write m_hybrid_topic() so that it passes parameters as do_topic()
9849 expects.
9850
9851   --Andrew Church
9852     achurch@achurch.org
9853     http://achurch.org/
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>
9859
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).
9861
9862 Possible bug?
9863
9864 Saturn
9865
9866
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
9875
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>
9884
9885 Unreal3.1.5.1-Valek(JetIRC). wdi.jetirc.net CFhiIpnROoXSs [*=2302(H)]
9886
9887 Ew, I hate Unreal 3.1 :P but that's another story.
9888
9889 Anyway, let's parse this:
9890
9891 <+Pyro> [21:07:23] * services.jetirc.net sets mode: -o Pyro
9892
9893 Probably joined before he identified to his nickname, so he wasn't recognized as having access.
9894
9895 <+Pyro> [21:07:23] * services.jetirc.net sets mode: +o Pyro
9896
9897 Identification.
9898
9899 <+Pyro> [21:07:23] * services.jetirc.net changes topic to ' (ChanServ)'
9900
9901 Topic.
9902
9903 <+Pyro> [21:07:26] * ChanServ sets mode: +ntr-o+a Pyro Pyro
9904
9905 +ntr is the modelock... +a is level 100... The -o thing is weird though.
9906
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>
9914
9915 3.1.5.1 is a heckuvalot more stable than 3.2... nevermind that though ok?
9916
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.
9920
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
9923 at 50.....
9924
9925 As for the auth code, perhaps you typoed the email address?  The auth system
9926 is working perfectly, I just tested it.
9927
9928 Saturn
9929 irc.jetirc.net
9930
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
9937
9938
9939 Unreal3.1.5.1-Valek(JetIRC). wdi.jetirc.net CFhiIpnROoXSs [*=2302(H)]
9940
9941 Ew, I hate Unreal 3.1 :P but that's another story.
9942
9943 Anyway, let's parse this:
9944
9945 <+Pyro> [21:07:23] * services.jetirc.net sets mode: -o Pyro
9946
9947 Probably joined before he identified to his nickname, so he wasn't
9948 recognized as having access.
9949
9950 <+Pyro> [21:07:23] * services.jetirc.net sets mode: +o Pyro
9951
9952 Identification.
9953
9954 <+Pyro> [21:07:23] * services.jetirc.net changes topic to ' (ChanServ)'
9955
9956 Topic.
9957
9958 <+Pyro> [21:07:26] * ChanServ sets mode: +ntr-o+a Pyro Pyro
9959
9960 +ntr is the modelock... +a is level 100... The -o thing is weird though.
9961
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
9967
9968
9969
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>
9976
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 =
9981 >is level 100).
9982
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?
9986
9987   --Andrew Church
9988     achurch@achurch.org
9989     http://achurch.org/
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>
9996
9997 I am runnign 5.0.16 ... I will try updating to 18 and see if that solves it
9998 then...
9999
10000 options for channel are just the default ones.
10001
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
10007
10008
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 =
10013 >is level 100).
10014
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?
10018
10019   --Andrew Church
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
10025
10026
10027
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>
10034
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 =)
10037
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
10043
10044
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 =
10049 >is level 100).
10050
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?
10054
10055   --Andrew Church
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
10061
10062
10063
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>
10071
10072 On Wed, 28 May 2003 19:04:03 -0400, <Slowking50@aol.com> wrote:
10073
10074 > Unreal3.1.5.1-Valek(JetIRC). wdi.jetirc.net CFhiIpnROoXSs [*=2302(H)]
10075 >
10076 > Ew, I hate Unreal 3.1 :P but that's another story.
10077 >
10078 > Anyway, let's parse this:
10079 >
10080 > <+Pyro> [21:07:23] * services.jetirc.net sets mode: -o Pyro
10081 >
10082 > Probably joined before he identified to his nickname, so he wasn't
10083 > recognized as having access.
10084
10085 Er, no.
10086 Notice the next line happens the same second. Also notice that the mode
10087 setter is not chanserv but services.jetirc.net.
10088
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>
10095
10096
10097 Hi,
10098
10099 services now, not support database mysql, someone have some patch for this?
10100
10101 Regards
10102
10103 Alex
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>
10111
10112 Quoting Alessandro Ciappei <laser@musichat.net>:
10113
10114 >
10115 > Hi,
10116 >
10117 > services now, not support database mysql, someone have some patch for this?
10118 >
10119 > Regards
10120 >
10121 > Alex
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.. (:
10125
10126
10127 ---------
10128 Brain? No route to host...
10129 Gizm0.-
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>
10135
10136 Hi all,
10137
10138 I try to compile services with mysql module, I found in list-archive, but I
10139 have a problem.
10140
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
10147 touch .stamp
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]$
10158
10159
10160 someone can helpme?
10161
10162 Thx
10163
10164 Alex
10165
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>
10173
10174 On Sat, 31 May 2003 15:10:50 +0200, Alessandro Ciappei <laser@musichat.net>
10175 wrote:
10176
10177 > Hi all,
10178 >
10179 > I try to compile services with mysql module, I found in list-archive, but
10180 > I
10181 > have a problem.
10182 *snip*
10183 > someone can helpme?
10184 >
10185 > Thx
10186 >
10187 > Alex
10188 >
10189
10190 maybe telling us which mysql module would help, and perhaps emailing the
10191 author
10192 would help more.
10193
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>
10200
10201 The services souce from here
10202
10203 http://www.luxusbuerg.lu/data/ircservices-luxusbuerg.tgz
10204
10205 The mysql table from here
10206
10207 http://www.luxusbuerg.lu/data/sql.tgz
10208
10209 thx a lot
10210
10211 Alex
10212
10213 Message: 1
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"
10221
10222 Hi all,
10223
10224 I try to compile services with mysql module, I found in list-archive, but I
10225 have a problem.
10226
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
10233 touch .stamp
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]$
10244
10245
10246 someone can helpme?
10247
10248 Thx
10249
10250 ALex
10251
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>
10258
10259 Hi,
10260
10261 maybe you should try to build services with dynamic modules, because the
10262 mysql module is known to compile as a dynamic module.
10263
10264 Georges
10265
10266 -----Urspr?ngliche Nachricht-----
10267 Von: ircservices-coding-bounces@ircservices.za.net
10268 [mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
10269 Alessandro Ciappei
10270 Gesendet: Sonntag, 1. Juni 2003 17:19
10271 An: ircservices-coding@ircservices.za.net
10272 Betreff: [IRCServices Coding] Mysql Module
10273
10274
10275 The services souce from here
10276
10277 http://www.luxusbuerg.lu/data/ircservices-luxusbuerg.tgz
10278
10279 The mysql table from here
10280
10281 http://www.luxusbuerg.lu/data/sql.tgz
10282
10283 thx a lot
10284
10285 Alex
10286
10287 Message: 1
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"
10295
10296 Hi all,
10297
10298 I try to compile services with mysql module, I found in list-archive,
10299 but I
10300 have a problem.
10301
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
10311 touch .stamp
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]$
10323
10324
10325 someone can helpme?
10326
10327 Thx
10328
10329 ALex
10330
10331 ------------------------------------------------------------------
10332 To unsubscribe or change your subscription options, visit:
10333 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
10334
10335
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>
10342
10343 It's compiling, but i see this:
10344 when i compile:
10345
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
10349 main.c -o main.o
10350 touch .stamp
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'
10354 touch .stamp
10355
10356 when i install:
10357
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'
10362
10363
10364 and when i start services in log i see:
10365
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
10370
10371 Thx a lot
10372
10373 ALex
10374
10375
10376 Message: 1
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"
10383
10384 The services souce from here
10385
10386 http://www.luxusbuerg.lu/data/ircservices-luxusbuerg.tgz
10387
10388 The mysql table from here
10389
10390 http://www.luxusbuerg.lu/data/sql.tgz
10391
10392 thx a lot
10393
10394 Alex
10395
10396 Message: 1
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"
10404
10405 Hi all,
10406
10407 I try to compile services with mysql module, I found in list-archive, but I
10408 have a problem.
10409
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
10416 touch .stamp
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]$
10427
10428
10429 someone can helpme?
10430
10431 Thx
10432
10433 ALex
10434
10435
10436 ------------------------------
10437
10438 Message: 2
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"
10446
10447 Hi,
10448
10449 maybe you should try to build services with dynamic modules, because the
10450 mysql module is known to compile as a dynamic module.
10451
10452 Georges
10453
10454 -----Urspr|ngliche Nachricht-----
10455 Von: ircservices-coding-bounces@ircservices.za.net
10456 [mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
10457 Alessandro Ciappei
10458 Gesendet: Sonntag, 1. Juni 2003 17:19
10459 An: ircservices-coding@ircservices.za.net
10460 Betreff: [IRCServices Coding] Mysql Module
10461
10462
10463 The services souce from here
10464
10465 http://www.luxusbuerg.lu/data/ircservices-luxusbuerg.tgz
10466
10467 The mysql table from here
10468
10469 http://www.luxusbuerg.lu/data/sql.tgz
10470
10471 thx a lot
10472
10473 Alex
10474
10475 Message: 1
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"
10483
10484 Hi all,
10485
10486 I try to compile services with mysql module, I found in list-archive,
10487 but I
10488 have a problem.
10489
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
10499 touch .stamp
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]$
10511
10512
10513 someone can helpme?
10514
10515 Thx
10516
10517 ALex
10518
10519 ------------------------------------------------------------------
10520 To unsubscribe or change your subscription options, visit:
10521 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
10522
10523
10524
10525 ------------------------------
10526
10527 _______________________________________________
10528 IRCServices-Coding mailing list
10529 IRCServices-Coding@ircservices.za.net
10530 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
10531
10532
10533 End of IRCServices-Coding Digest, Vol 5, Issue 2
10534 ************************************************
10535
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>
10542
10543 Hi,
10544
10545
10546 [snip]
10547
10548 >/home/services/sviluppo/lib/modules/mysql/main.so: undefined symbol: unco$
10549 >
10550 >
10551 [/snip]
10552
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
10556 functions to run.
10557
10558 Georges
10559
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>
10566
10567 i try with flag -lz but this is the error:
10568
10569 /usr/bin/ld: cannot find -lz
10570 collect2: ld returned 1 exit status
10571 make: *** [ircservices] Error 1
10572
10573 Thx
10574
10575 Alex
10576
10577 Message: 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"
10584
10585 It's compiling, but i see this:
10586 when i compile:
10587
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
10591 main.c -o main.o
10592 touch .stamp
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'
10596 touch .stamp
10597
10598 when i install:
10599
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'
10604
10605
10606 and when i start services in log i see:
10607
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
10612
10613 Thx a lot
10614
10615 ALex
10616
10617
10618 Message: 1
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"
10625
10626 The services souce from here
10627
10628 http://www.luxusbuerg.lu/data/ircservices-luxusbuerg.tgz
10629
10630 The mysql table from here
10631
10632 http://www.luxusbuerg.lu/data/sql.tgz
10633
10634 thx a lot
10635
10636 Alex
10637
10638 Message: 1
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"
10646
10647 Hi all,
10648
10649 I try to compile services with mysql module, I found in list-archive, but I
10650 have a problem.
10651
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
10658 touch .stamp
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]$
10669
10670
10671 someone can helpme?
10672
10673 Thx
10674
10675 ALex
10676
10677
10678 ------------------------------
10679
10680 Message: 2
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"
10688
10689 Hi,
10690
10691 maybe you should try to build services with dynamic modules, because the
10692 mysql module is known to compile as a dynamic module.
10693
10694 Georges
10695
10696 -----Urspr|ngliche Nachricht-----
10697 Von: ircservices-coding-bounces@ircservices.za.net
10698 [mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
10699 Alessandro Ciappei
10700 Gesendet: Sonntag, 1. Juni 2003 17:19
10701 An: ircservices-coding@ircservices.za.net
10702 Betreff: [IRCServices Coding] Mysql Module
10703
10704
10705 The services souce from here
10706
10707 http://www.luxusbuerg.lu/data/ircservices-luxusbuerg.tgz
10708
10709 The mysql table from here
10710
10711 http://www.luxusbuerg.lu/data/sql.tgz
10712
10713 thx a lot
10714
10715 Alex
10716
10717 Message: 1
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"
10725
10726 Hi all,
10727
10728 I try to compile services with mysql module, I found in list-archive,
10729 but I
10730 have a problem.
10731
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
10741 touch .stamp
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]$
10753
10754
10755 someone can helpme?
10756
10757 Thx
10758
10759 ALex
10760
10761 ------------------------------------------------------------------
10762 To unsubscribe or change your subscription options, visit:
10763 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
10764
10765
10766
10767 ------------------------------
10768
10769 _______________________________________________
10770 IRCServices-Coding mailing list
10771 IRCServices-Coding@ircservices.za.net
10772 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
10773
10774
10775 End of IRCServices-Coding Digest, Vol 5, Issue 2
10776 ************************************************
10777
10778
10779 ------------------------------
10780
10781 Message: 2
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
10789
10790 Hi,
10791
10792
10793 [snip]
10794
10795 >/home/services/sviluppo/lib/modules/mysql/main.so: undefined symbol: unco$
10796 >
10797 >
10798 [/snip]
10799
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
10803 functions to run.
10804
10805 Georges
10806
10807
10808 ------------------------------
10809
10810 _______________________________________________
10811 IRCServices-Coding mailing list
10812 IRCServices-Coding@ircservices.za.net
10813 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
10814
10815
10816 End of IRCServices-Coding Digest, Vol 5, Issue 3
10817 ************************************************
10818
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>
10825
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
10828 long time...
10829
10830 Georges
10831
10832 -----Urspr?ngliche Nachricht-----
10833 Von: ircservices-coding-bounces@ircservices.za.net
10834 [mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
10835 Alessandro Ciappei
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
10839 3
10840
10841
10842 i try with flag -lz but this is the error:
10843
10844 /usr/bin/ld: cannot find -lz
10845 collect2: ld returned 1 exit status
10846 make: *** [ircservices] Error 1
10847
10848 Thx
10849
10850 Alex
10851
10852 Message: 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"
10859
10860 It's compiling, but i see this:
10861 when i compile:
10862
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
10866 main.c -o main.o
10867 touch .stamp
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'
10872 touch .stamp
10873
10874 when i install:
10875
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'
10881
10882
10883 and when i start services in log i see:
10884
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:
10888 unco$
10889 [Jun 02 14:26:21 2003] Error loading modules, aborting
10890
10891 Thx a lot
10892
10893 ALex
10894
10895
10896 Message: 1
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"
10903
10904 The services souce from here
10905
10906 http://www.luxusbuerg.lu/data/ircservices-luxusbuerg.tgz
10907
10908 The mysql table from here
10909
10910 http://www.luxusbuerg.lu/data/sql.tgz
10911
10912 thx a lot
10913
10914 Alex
10915
10916 Message: 1
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"
10924
10925 Hi all,
10926
10927 I try to compile services with mysql module, I found in list-archive,
10928 but I
10929 have a problem.
10930
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
10940 touch .stamp
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]$
10952
10953
10954 someone can helpme?
10955
10956 Thx
10957
10958 ALex
10959
10960
10961 ------------------------------
10962
10963 Message: 2
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"
10971
10972 Hi,
10973
10974 maybe you should try to build services with dynamic modules, because the
10975 mysql module is known to compile as a dynamic module.
10976
10977 Georges
10978
10979 -----Urspr|ngliche Nachricht-----
10980 Von: ircservices-coding-bounces@ircservices.za.net
10981 [mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
10982 Alessandro Ciappei
10983 Gesendet: Sonntag, 1. Juni 2003 17:19
10984 An: ircservices-coding@ircservices.za.net
10985 Betreff: [IRCServices Coding] Mysql Module
10986
10987
10988 The services souce from here
10989
10990 http://www.luxusbuerg.lu/data/ircservices-luxusbuerg.tgz
10991
10992 The mysql table from here
10993
10994 http://www.luxusbuerg.lu/data/sql.tgz
10995
10996 thx a lot
10997
10998 Alex
10999
11000 Message: 1
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"
11008
11009 Hi all,
11010
11011 I try to compile services with mysql module, I found in list-archive,
11012 but I
11013 have a problem.
11014
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
11024 touch .stamp
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]$
11036
11037
11038 someone can helpme?
11039
11040 Thx
11041
11042 ALex
11043
11044 ------------------------------------------------------------------
11045 To unsubscribe or change your subscription options, visit:
11046 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
11047
11048
11049
11050 ------------------------------
11051
11052 _______________________________________________
11053 IRCServices-Coding mailing list
11054 IRCServices-Coding@ircservices.za.net
11055 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
11056
11057
11058 End of IRCServices-Coding Digest, Vol 5, Issue 2
11059 ************************************************
11060
11061
11062 ------------------------------
11063
11064 Message: 2
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
11072
11073 Hi,
11074
11075
11076 [snip]
11077
11078 >/home/services/sviluppo/lib/modules/mysql/main.so: undefined symbol:
11079 unco$
11080 >
11081 >
11082 [/snip]
11083
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
11087 functions to run.
11088
11089 Georges
11090
11091
11092 ------------------------------
11093
11094 _______________________________________________
11095 IRCServices-Coding mailing list
11096 IRCServices-Coding@ircservices.za.net
11097 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
11098
11099
11100 End of IRCServices-Coding Digest, Vol 5, Issue 3
11101 ************************************************
11102
11103 ------------------------------------------------------------------
11104 To unsubscribe or change your subscription options, visit:
11105 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
11106
11107
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>
11114
11115 But, I had Zlib
11116
11117 my OS is RH 9.0, this is my zlib
11118
11119 [root@lists root]# rpm -qa | grep zlib
11120 zlib-devel-1.1.4-8
11121 zlib-1.1.4-8
11122 [root@lists root]#
11123
11124 Possible this zlib is corrupted?
11125
11126 ALex
11127
11128 Message: 1
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,
11132         Issue 3
11133 To: <ircservices-coding@ircservices.za.net>
11134 Message-ID: <BNEPLNAFODLPMAECJEOBGECGCAAA.laser@musichat.net>
11135 Content-Type: text/plain;       charset="us-ascii"
11136
11137 i try with flag -lz but this is the error:
11138
11139 /usr/bin/ld: cannot find -lz
11140 collect2: ld returned 1 exit status
11141 make: *** [ircservices] Error 1
11142
11143 Thx
11144
11145 Alex
11146
11147 Message: 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"
11154
11155 It's compiling, but i see this:
11156 when i compile:
11157
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
11161 main.c -o main.o
11162 touch .stamp
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'
11166 touch .stamp
11167
11168 when i install:
11169
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'
11174
11175
11176 and when i start services in log i see:
11177
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
11182
11183 Thx a lot
11184
11185 ALex
11186
11187
11188 Message: 1
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"
11195
11196 The services souce from here
11197
11198 http://www.luxusbuerg.lu/data/ircservices-luxusbuerg.tgz
11199
11200 The mysql table from here
11201
11202 http://www.luxusbuerg.lu/data/sql.tgz
11203
11204 thx a lot
11205
11206 Alex
11207
11208 Message: 1
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"
11216
11217 Hi all,
11218
11219 I try to compile services with mysql module, I found in list-archive, but I
11220 have a problem.
11221
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
11228 touch .stamp
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]$
11239
11240
11241 someone can helpme?
11242
11243 Thx
11244
11245 ALex
11246
11247
11248 ------------------------------
11249
11250 Message: 2
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"
11258
11259 Hi,
11260
11261 maybe you should try to build services with dynamic modules, because the
11262 mysql module is known to compile as a dynamic module.
11263
11264 Georges
11265
11266 -----Urspr|ngliche Nachricht-----
11267 Von: ircservices-coding-bounces@ircservices.za.net
11268 [mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
11269 Alessandro Ciappei
11270 Gesendet: Sonntag, 1. Juni 2003 17:19
11271 An: ircservices-coding@ircservices.za.net
11272 Betreff: [IRCServices Coding] Mysql Module
11273
11274
11275 The services souce from here
11276
11277 http://www.luxusbuerg.lu/data/ircservices-luxusbuerg.tgz
11278
11279 The mysql table from here
11280
11281 http://www.luxusbuerg.lu/data/sql.tgz
11282
11283 thx a lot
11284
11285 Alex
11286
11287 Message: 1
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"
11295
11296 Hi all,
11297
11298 I try to compile services with mysql module, I found in list-archive,
11299 but I
11300 have a problem.
11301
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
11311 touch .stamp
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]$
11323
11324
11325 someone can helpme?
11326
11327 Thx
11328
11329 ALex
11330
11331 ------------------------------------------------------------------
11332 To unsubscribe or change your subscription options, visit:
11333 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
11334
11335
11336
11337 ------------------------------
11338
11339 _______________________________________________
11340 IRCServices-Coding mailing list
11341 IRCServices-Coding@ircservices.za.net
11342 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
11343
11344
11345 End of IRCServices-Coding Digest, Vol 5, Issue 2
11346 ************************************************
11347
11348
11349 ------------------------------
11350
11351 Message: 2
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
11359
11360 Hi,
11361
11362
11363 [snip]
11364
11365 >/home/services/sviluppo/lib/modules/mysql/main.so: undefined symbol: unco$
11366 >
11367 >
11368 [/snip]
11369
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
11373 functions to run.
11374
11375 Georges
11376
11377
11378 ------------------------------
11379
11380 _______________________________________________
11381 IRCServices-Coding mailing list
11382 IRCServices-Coding@ircservices.za.net
11383 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
11384
11385
11386 End of IRCServices-Coding Digest, Vol 5, Issue 3
11387 ************************************************
11388
11389
11390 ------------------------------
11391
11392 Message: 2
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,
11396         Issue 3
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"
11401
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
11404 long time...
11405
11406 Georges
11407
11408 -----Urspr|ngliche Nachricht-----
11409 Von: ircservices-coding-bounces@ircservices.za.net
11410 [mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
11411 Alessandro Ciappei
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
11415 3
11416
11417
11418 i try with flag -lz but this is the error:
11419
11420 /usr/bin/ld: cannot find -lz
11421 collect2: ld returned 1 exit status
11422 make: *** [ircservices] Error 1
11423
11424 Thx
11425
11426 Alex
11427
11428 Message: 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"
11435
11436 It's compiling, but i see this:
11437 when i compile:
11438
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
11442 main.c -o main.o
11443 touch .stamp
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'
11448 touch .stamp
11449
11450 when i install:
11451
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'
11457
11458
11459 and when i start services in log i see:
11460
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:
11464 unco$
11465 [Jun 02 14:26:21 2003] Error loading modules, aborting
11466
11467 Thx a lot
11468
11469 ALex
11470
11471
11472 Message: 1
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"
11479
11480 The services souce from here
11481
11482 http://www.luxusbuerg.lu/data/ircservices-luxusbuerg.tgz
11483
11484 The mysql table from here
11485
11486 http://www.luxusbuerg.lu/data/sql.tgz
11487
11488 thx a lot
11489
11490 Alex
11491
11492 Message: 1
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"
11500
11501 Hi all,
11502
11503 I try to compile services with mysql module, I found in list-archive,
11504 but I
11505 have a problem.
11506
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
11516 touch .stamp
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]$
11528
11529
11530 someone can helpme?
11531
11532 Thx
11533
11534 ALex
11535
11536
11537 ------------------------------
11538
11539 Message: 2
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"
11547
11548 Hi,
11549
11550 maybe you should try to build services with dynamic modules, because the
11551 mysql module is known to compile as a dynamic module.
11552
11553 Georges
11554
11555 -----Urspr|ngliche Nachricht-----
11556 Von: ircservices-coding-bounces@ircservices.za.net
11557 [mailto:ircservices-coding-bounces@ircservices.za.net] Im Auftrag von
11558 Alessandro Ciappei
11559 Gesendet: Sonntag, 1. Juni 2003 17:19
11560 An: ircservices-coding@ircservices.za.net
11561 Betreff: [IRCServices Coding] Mysql Module
11562
11563
11564 The services souce from here
11565
11566 http://www.luxusbuerg.lu/data/ircservices-luxusbuerg.tgz
11567
11568 The mysql table from here
11569
11570 http://www.luxusbuerg.lu/data/sql.tgz
11571
11572 thx a lot
11573
11574 Alex
11575
11576 Message: 1
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"
11584
11585 Hi all,
11586
11587 I try to compile services with mysql module, I found in list-archive,
11588 but I
11589 have a problem.
11590
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
11600 touch .stamp
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]$
11612
11613
11614 someone can helpme?
11615
11616 Thx
11617
11618 ALex
11619
11620 ------------------------------------------------------------------
11621 To unsubscribe or change your subscription options, visit:
11622 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
11623
11624
11625
11626 ------------------------------
11627
11628 _______________________________________________
11629 IRCServices-Coding mailing list
11630 IRCServices-Coding@ircservices.za.net
11631 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
11632
11633
11634 End of IRCServices-Coding Digest, Vol 5, Issue 2
11635 ************************************************
11636
11637
11638 ------------------------------
11639
11640 Message: 2
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
11648
11649 Hi,
11650
11651
11652 [snip]
11653
11654 >/home/services/sviluppo/lib/modules/mysql/main.so: undefined symbol:
11655 unco$
11656 >
11657 >
11658 [/snip]
11659
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
11663 functions to run.
11664
11665 Georges
11666
11667
11668
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>
11674
11675 Hey,
11676
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.
11679
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.
11685
11686 Any Ideas, I'm kinda stuck.
11687
11688 Chris
11689
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>
11697
11698 Hello;
11699
11700 Please ensure yourself that the channel is not expiring.
11701 You can notice this in the logfile services is generating.
11702
11703 Regards;
11704 yusuf
11705
11706 On Thu, 2003-06-05 at 21:43, Chris Plant wrote:
11707 > Hey,
11708 >
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.
11711 >
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.
11717 >
11718 > Any Ideas, I'm kinda stuck.
11719 >
11720 > Chris
11721 >
11722 > ------------------------------------------------------------------
11723 > To unsubscribe or change your subscription options, visit:
11724 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
11725 --
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 ------------------------------------------------------------------
11732
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>
11738
11739 i get services running and connected to my unreal daemon but i get this
11740 message when i try to register my nickname
11741
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
11746 -
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)
11750
11751
11752 then i check the logs and i see this
11753
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
11762 registered
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
11767
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
11770 to help me. thanks
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>
11779
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:
11787
11788 Services-Master connects to hub.us.yournetwork.net
11789 Services-Slave connects to hub.uk.yournetwork.net
11790
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...
11797
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...
11806
11807 So, where does the MySql support stand, or is there anything at all yet?
11808
11809
11810 --
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
11820 Size: 189 bytes
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>
11828
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.
11836
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>
11846
11847      I can't reproduce this.
11848
11849   --Andrew Church
11850     achurch@achurch.org
11851     http://achurch.org/
11852
11853 >This is a multi-part message in MIME format.
11854 >
11855 >--===============5325410492838385==
11856 >Content-type: multipart/alternative;
11857 > boundary="Boundary_(ID_YCOpLsbO0fK3uQV6a0w+JQ)"
11858 >
11859 >This is a multi-part message in MIME format.
11860 >
11861 >--Boundary_(ID_YCOpLsbO0fK3uQV6a0w+JQ)
11862 >Content-type: text/plain; charset=us-ascii
11863 >Content-transfer-encoding: 7BIT
11864 >
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.
11872 >
11873 >
11874 >--Boundary_(ID_YCOpLsbO0fK3uQV6a0w+JQ)
11875 >Content-type: text/html; charset=us-ascii
11876 >Content-transfer-encoding: 7BIT
11877 >
11878 ><html>
11879 >
11880 ><head>
11881 ><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
11882 >
11883 >
11884 ><meta name=Generator content="Microsoft Word 10 (filtered)">
11885 >
11886 ><style>
11887 ><!--
11888 > /* Style Definitions */
11889 > p.MsoNormal, li.MsoNormal, div.MsoNormal
11890 >       {margin:0in;
11891 >       margin-bottom:.0001pt;
11892 >       font-size:12.0pt;
11893 >       font-family:"Times New Roman";}
11894 >a:link, span.MsoHyperlink
11895 >       {color:blue;
11896 >       text-decoration:underline;}
11897 >a:visited, span.MsoHyperlinkFollowed
11898 >       {color:purple;
11899 >       text-decoration:underline;}
11900 >span.EmailStyle17
11901 >       {font-family:Arial;
11902 >       color:windowtext;}
11903 >@page Section1
11904 >       {size:8.5in 11.0in;
11905 >       margin:1.0in 1.25in 1.0in 1.25in;}
11906 >div.Section1
11907 >       {page:Section1;}
11908 >-->
11909 ></style>
11910 >
11911 ></head>
11912 >
11913 ><body lang=EN-US link=blue vlink=purple>
11914 >
11915 ><div class=Section1>
11916 >
11917 ><p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
11918 >font-family:Arial'>Ok, I don&#8217;t know if this is happening to anyone else,
11919 >but here is the problem.&nbsp; I&#8217;ve loaded the http module to allow opers to
11920 >view registered nicknames, channels, and network statistics.&nbsp; All password
11921 >protected of course.&nbsp; 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.&nbsp; I have not changed the http module in anyway.&nbsp; Just thought I&#8217;d
11924 >give everyone a heads up before using that module.</span></font></p>
11925 >
11926 ></div>
11927 >
11928 ></body>
11929 >
11930 ></html>
11931 >
11932 >--Boundary_(ID_YCOpLsbO0fK3uQV6a0w+JQ)--
11933 >
11934 >--===============5325410492838385==
11935 >Content-Type: text/plain; charset="us-ascii"
11936 >MIME-Version: 1.0
11937 >Content-Transfer-Encoding: 7bit
11938 >Content-Disposition: inline
11939 >
11940 >------------------------------------------------------------------
11941 >To unsubscribe or change your subscription options, visit:
11942 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
11943 >
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>
11951
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
11954 know :)
11955
11956 -----Original Message-----
11957 From: ircservices-coding-bounces@ircservices.za.net
11958 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of
11959 Andrew Church
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
11963
11964      I can't reproduce this.
11965
11966   --Andrew Church
11967     achurch@achurch.org
11968     http://achurch.org/
11969
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,
11974 and
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.
11978
11979
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>
11986
11987      A GDB backtrace would be helpful:
11988
11989 gdb /usr/local/bin/ircservices /usr/local/lib/ircservices/core
11990     [or whatever your pathnames are]
11991 ...
11992 (gdb) bt
11993 ------------- clip/copy and send from here --------------
11994 #0  ... at somefile.c:NNN
11995 #1  ...
11996 ...
11997 ----------------------- to here -------------------------
11998 (gdb) quit
11999
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
12003 before running it.
12004
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.
12008
12009   --Andrew Church
12010     achurch@achurch.org
12011     http://achurch.org/
12012
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
12015 >know :)
12016 >
12017 >-----Original Message-----
12018 >From: ircservices-coding-bounces@ircservices.za.net
12019 >[mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of
12020 >Andrew Church
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
12024 >
12025 >     I can't reproduce this.
12026 >
12027 >  --Andrew Church
12028 >    achurch@achurch.org
12029 >    http://achurch.org/
12030 >
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,
12035 >and
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.
12039 >
12040 >
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>
12050
12051 (gdb) bt
12052 #0  0x08053076 in irc_stricmp (s1=0x81c9f10 "Azheman|School", s2=0x0) at
12053 misc.c:70
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
12057 dbaccess.c:128
12058 #3  0x08054b6e in call_callback_5 (module=0x81c8600, id=97,
12059 arg1=0x81ee100, arg2=0xbfbfe9ec, arg3=0x0, arg4=0x0, arg5=0x0)
12060     at modules.c:658
12061 #4  0x281cd226 in handle_request (c=0x81ee100) at main.c:694
12062 #5  0x281cc826 in do_readline (socket=0x8076000, param_unused=0x2) at
12063 main.c:314
12064 #6  0x08056739 in check_sockets () at sockets.c:392
12065 #7  0x08052569 in main (ac=1, av=0xbfbffbf4, envp=0xbfbffbfc) at
12066 main.c:248
12067 #8  0x0804c0b5 in _start ()
12068 (gdb) quit
12069
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.
12074
12075 Thanks
12076
12077 -----Original Message-----
12078 From: ircservices-coding-bounces@ircservices.za.net
12079 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of
12080 Andrew Church
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
12084
12085      A GDB backtrace would be helpful:
12086
12087 gdb /usr/local/bin/ircservices /usr/local/lib/ircservices/core
12088     [or whatever your pathnames are]
12089 ...
12090 (gdb) bt
12091 ------------- clip/copy and send from here --------------
12092 #0  ... at somefile.c:NNN
12093 #1  ...
12094 ...
12095 ----------------------- to here -------------------------
12096 (gdb) quit
12097
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
12100 removed
12101 the "-g" in MORE_CFLAGS in the makefile) and don't strip the executable
12102 before running it.
12103
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
12106 to
12107 crash for apparently random reasons.
12108
12109   --Andrew Church
12110     achurch@achurch.org
12111     http://achurch.org/
12112
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>
12119
12120      This can't happen unless your compiler is broken or you've modified
12121 Services.
12122
12123   --Andrew Church
12124     achurch@achurch.org
12125     http://achurch.org/
12126
12127 >(gdb) bt
12128 >#0  0x08053076 in irc_stricmp (s1=0x81c9f10 "Azheman|School", s2=0x0) at
12129 >misc.c:70
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
12133 >dbaccess.c:128
12134 >#3  0x08054b6e in call_callback_5 (module=0x81c8600, id=97,
12135 >arg1=0x81ee100, arg2=0xbfbfe9ec, arg3=0x0, arg4=0x0, arg5=0x0)
12136 >    at modules.c:658
12137 >#4  0x281cd226 in handle_request (c=0x81ee100) at main.c:694
12138 >#5  0x281cc826 in do_readline (socket=0x8076000, param_unused=0x2) at
12139 >main.c:314
12140 >#6  0x08056739 in check_sockets () at sockets.c:392
12141 >#7  0x08052569 in main (ac=1, av=0xbfbffbf4, envp=0xbfbffbfc) at
12142 >main.c:248
12143 >#8  0x0804c0b5 in _start ()
12144 >(gdb) quit
12145 >
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.
12150 >
12151 >Thanks
12152 >
12153 >-----Original Message-----
12154 >From: ircservices-coding-bounces@ircservices.za.net
12155 >[mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of
12156 >Andrew Church
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
12160 >
12161 >     A GDB backtrace would be helpful:
12162 >
12163 >gdb /usr/local/bin/ircservices /usr/local/lib/ircservices/core
12164 >    [or whatever your pathnames are]
12165 >...
12166 >(gdb) bt
12167 >------------- clip/copy and send from here --------------
12168 >#0  ... at somefile.c:NNN
12169 >#1  ...
12170 >...
12171 >----------------------- to here -------------------------
12172 >(gdb) quit
12173 >
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
12176 >removed
12177 >the "-g" in MORE_CFLAGS in the makefile) and don't strip the executable
12178 >before running it.
12179 >
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
12182 >to
12183 >crash for apparently random reasons.
12184 >
12185 >  --Andrew Church
12186 >    achurch@achurch.org
12187 >    http://achurch.org/
12188 >
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>
12198
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?
12201
12202 -----Original Message-----
12203 From: ircservices-coding-bounces@ircservices.za.net
12204 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of
12205 Andrew Church
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
12209
12210      This can't happen unless your compiler is broken or you've modified
12211 Services.
12212
12213   --Andrew Church
12214     achurch@achurch.org
12215     http://achurch.org/
12216
12217 >(gdb) bt
12218 >#0  0x08053076 in irc_stricmp (s1=0x81c9f10 "Azheman|School", s2=0x0)
12219 at
12220 >misc.c:70
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
12224 >dbaccess.c:128
12225 >#3  0x08054b6e in call_callback_5 (module=0x81c8600, id=97,
12226 >arg1=0x81ee100, arg2=0xbfbfe9ec, arg3=0x0, arg4=0x0, arg5=0x0)
12227 >    at modules.c:658
12228 >#4  0x281cd226 in handle_request (c=0x81ee100) at main.c:694
12229 >#5  0x281cc826 in do_readline (socket=0x8076000, param_unused=0x2) at
12230 >main.c:314
12231 >#6  0x08056739 in check_sockets () at sockets.c:392
12232 >#7  0x08052569 in main (ac=1, av=0xbfbffbf4, envp=0xbfbffbfc) at
12233 >main.c:248
12234 >#8  0x0804c0b5 in _start ()
12235 >(gdb) quit
12236 >
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.
12241 >
12242 >Thanks
12243 >
12244 >-----Original Message-----
12245 >From: ircservices-coding-bounces@ircservices.za.net
12246 >[mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of
12247 >Andrew Church
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
12251 >
12252 >     A GDB backtrace would be helpful:
12253 >
12254 >gdb /usr/local/bin/ircservices /usr/local/lib/ircservices/core
12255 >    [or whatever your pathnames are]
12256 >...
12257 >(gdb) bt
12258 >------------- clip/copy and send from here --------------
12259 >#0  ... at somefile.c:NNN
12260 >#1  ...
12261 >...
12262 >----------------------- to here -------------------------
12263 >(gdb) quit
12264 >
12265 >If you don't get the "at somefile:NNN" in the backtrace, your
12266 executable
12267 >is missing debugging information--recompile (make sure you haven't
12268 >removed
12269 >the "-g" in MORE_CFLAGS in the makefile) and don't strip the executable
12270 >before running it.
12271 >
12272 >     Also, are you using a SPARC, i.e. Sun system?  GCC on SPARC
12273 systems
12274 >has at least one bug that is triggered by Services and causes Services
12275 >to
12276 >crash for apparently random reasons.
12277 >
12278 >  --Andrew Church
12279 >    achurch@achurch.org
12280 >    http://achurch.org/
12281 >
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
12288
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>
12295
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
12301 cannot happen.
12302
12303   --Andrew Church
12304     achurch@achurch.org
12305     http://achurch.org/
12306
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?
12309 >
12310 >-----Original Message-----
12311 >From: ircservices-coding-bounces@ircservices.za.net
12312 >[mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of
12313 >Andrew Church
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
12317 >
12318 >     This can't happen unless your compiler is broken or you've modified
12319 >Services.
12320 >
12321 >  --Andrew Church
12322 >    achurch@achurch.org
12323 >    http://achurch.org/
12324 >
12325 >>(gdb) bt
12326 >>#0  0x08053076 in irc_stricmp (s1=0x81c9f10 "Azheman|School", s2=0x0)
12327 >at
12328 >>misc.c:70
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
12332 >>dbaccess.c:128
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
12338 >>main.c:314
12339 >>#6  0x08056739 in check_sockets () at sockets.c:392
12340 >>#7  0x08052569 in main (ac=1, av=0xbfbffbf4, envp=0xbfbffbfc) at
12341 >>main.c:248
12342 >>#8  0x0804c0b5 in _start ()
12343 >>(gdb) quit
12344 >>
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.
12349 >>
12350 >>Thanks
12351 >>
12352 >>-----Original Message-----
12353 >>From: ircservices-coding-bounces@ircservices.za.net
12354 >>[mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of
12355 >>Andrew Church
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
12359 >>
12360 >>     A GDB backtrace would be helpful:
12361 >>
12362 >>gdb /usr/local/bin/ircservices /usr/local/lib/ircservices/core
12363 >>    [or whatever your pathnames are]
12364 >>...
12365 >>(gdb) bt
12366 >>------------- clip/copy and send from here --------------
12367 >>#0  ... at somefile.c:NNN
12368 >>#1  ...
12369 >>...
12370 >>----------------------- to here -------------------------
12371 >>(gdb) quit
12372 >>
12373 >>If you don't get the "at somefile:NNN" in the backtrace, your
12374 >executable
12375 >>is missing debugging information--recompile (make sure you haven't
12376 >>removed
12377 >>the "-g" in MORE_CFLAGS in the makefile) and don't strip the executable
12378 >>before running it.
12379 >>
12380 >>     Also, are you using a SPARC, i.e. Sun system?  GCC on SPARC
12381 >systems
12382 >>has at least one bug that is triggered by Services and causes Services
12383 >>to
12384 >>crash for apparently random reasons.
12385 >>
12386 >>  --Andrew Church
12387 >>    achurch@achurch.org
12388 >>    http://achurch.org/
12389 >>
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
12396 >
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>
12406
12407
12408 Hi to all you. I experienced a little Problem builduing
12409 ircservices on an OpenBSD machine.
12410
12411 Yes i use gnu make > 3.79  :)
12412
12413 configure works. gmake ist starting to build the services.
12414 But in the modules/ it fails telling
12415
12416 gmake[1]: Leaving directory `/home/ircd/source/ircservices-5.0.20/modules'
12417 sh version.sh
12418
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
12425
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
12439 from data segment
12440 modlist.o: Undefined symbol `_exit_module_chanserv_access_xop' referenced
12441 from data segment
12442 .................
12443
12444 any hint?
12445
12446
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
12451         3.3 fails
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>
12454
12455
12456 Sorry forgott something :))
12457
12458 ..........
12459
12460 modlist.o: Undefined symbol `_init_module_statserv_main' referenced from
12461 data segment
12462 modlist.o: Undefined symbol `_exit_module_statserv_main' referenced from
12463 data segment
12464 modlist.o: Undefined symbol `_new_serverstats' referenced from data
12465 segment
12466 modlist.o: Undefined symbol `_free_serverstats' referenced from data
12467 segment
12468 collect2: ld returned 1 exit status
12469 gmake: *** [ircservices] Error 1
12470
12471
12472
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>
12478
12479
12480 After discussing mysql module design it occurred to me that it would make
12481 designing a
12482 caching database module for mysql much easier if the get_ functions had
12483 analogs for
12484 read-only use.
12485
12486 I figure that if we create functions like get_readonly_nickinfo, it would
12487 allow
12488 for more efficient caching of data. The reasoning behind this is that
12489 procedures
12490 which modify a nick/channel/nickgroup need to have a more updated version
12491 of the
12492 data in order to figure out whether it can be modified the way it wants to.
12493
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
12496 version
12497 since it would cause little harm to simply display out-of-date information
12498 to the user.
12499
12500 If we cached all pieces of data (including read-write), then it would
12501 happen
12502 that either the data in the database would be locked for too long and no
12503 outside
12504 program could ever modify it, or if we didn't lock the entries in the
12505 database,
12506 we would end up overwriting any changes another program made once we
12507 invalidated
12508 the cache.
12509
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,
12513 ACCESS LIST,
12514 AKICK LIST, AKILL LIST, and for determining access etc. The regular
12515 get_nickinfo etc
12516 functions would retain the same functionality for backwards compatibility
12517 and nothing
12518 would break.
12519
12520 These new get_readonly_* (or if you want, get_cache_*) would be implemented
12521 in modules
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
12525 would be
12526 synonyms for the regular get_* functions (i.e. in version4, they would be
12527 synonyms).
12528
12529 The info returned by these functions would generally not be modified (save
12530 for things
12531 that aren't saved to database such as the locked field) and wouldn't be
12532 passed to
12533 put_* functions. Also, it would be a bad idea to use the info returned from
12534 the
12535 readonly/cache functions to conditionally modify other data (example, you
12536 wouldn't
12537 use these functions to check someone's access so that they could change
12538 channel options,
12539 since another program could recently have removed them from the access list
12540 without
12541 us knowing it. It would be safe however to check someone's access to join
12542 the channel,
12543 use INVITE UNBAN OP etc, because that doesn't involve changing the
12544 ChannelInfo).
12545
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>
12553
12554      Easy counterexample: /os akill add luser@*.example.com (where it
12555 would definitely _not_ be proper to use out-of-date data)
12556
12557   --Andrew Church
12558     achurch@achurch.org
12559     http://achurch.org/
12560
12561 >
12562 >After discussing mysql module design it occurred to me that it would make
12563 >designing a
12564 >caching database module for mysql much easier if the get_ functions had
12565 >analogs for
12566 >read-only use.
12567 >
12568 >I figure that if we create functions like get_readonly_nickinfo, it would
12569 >allow
12570 >for more efficient caching of data. The reasoning behind this is that
12571 >procedures
12572 >which modify a nick/channel/nickgroup need to have a more updated version
12573 >of the
12574 >data in order to figure out whether it can be modified the way it wants to.
12575 >
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
12578 >version
12579 >since it would cause little harm to simply display out-of-date information
12580 >to the user.
12581 >
12582 >If we cached all pieces of data (including read-write), then it would
12583 >happen
12584 >that either the data in the database would be locked for too long and no
12585 >outside
12586 >program could ever modify it, or if we didn't lock the entries in the
12587 >database,
12588 >we would end up overwriting any changes another program made once we
12589 >invalidated
12590 >the cache.
12591 >
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,
12595 >ACCESS LIST,
12596 >AKICK LIST, AKILL LIST, and for determining access etc. The regular
12597 >get_nickinfo etc
12598 >functions would retain the same functionality for backwards compatibility
12599 >and nothing
12600 >would break.
12601 >
12602 >These new get_readonly_* (or if you want, get_cache_*) would be implemented
12603 >in modules
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
12607 >would be
12608 >synonyms for the regular get_* functions (i.e. in version4, they would be
12609 >synonyms).
12610 >
12611 >The info returned by these functions would generally not be modified (save
12612 >for things
12613 >that aren't saved to database such as the locked field) and wouldn't be
12614 >passed to
12615 >put_* functions. Also, it would be a bad idea to use the info returned from
12616 >the
12617 >readonly/cache functions to conditionally modify other data (example, you
12618 >wouldn't
12619 >use these functions to check someone's access so that they could change
12620 >channel options,
12621 >since another program could recently have removed them from the access list
12622 >without
12623 >us knowing it. It would be safe however to check someone's access to join
12624 >the channel,
12625 >use INVITE UNBAN OP etc, because that doesn't involve changing the
12626 >ChannelInfo).
12627 >
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
12636         fails
12637 In-Reply-To: <Pine.LNX.4.44.0306242200160.10120-100000@no.script-irc.de>
12638 Message-ID: <3ef93b88.02311@achurch.org>
12639
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
12644 >
12645 >modlist.o: Undefined symbol `_module_version_chanserv_access_levels'
12646 >referenced from data segment
12647
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.
12651
12652   --Andrew Church
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
12659  3.3    fails
12660 In-Reply-To: <3ef93b88.02311@achurch.org>
12661 Message-ID: <Pine.LNX.4.44.0306251219450.14961-100000@no.script-irc.de>
12662
12663 On Wed, 25 Jun 2003, Andrew Church wrote:
12664
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.
12668 >
12669 >   --Andrew Church
12670 >     achurch@achurch.org
12671 >     http://achurch.org/
12672
12673 Don't forget in the FAQ that ircservices have to be compiled with:
12674
12675 ./configure -cc /usr/local/bin/egcc
12676
12677
12678 :))
12679
12680 Compiling with standard gcc from OpenBSD 3.3 i ran into a few seqfaults.
12681
12682
12683
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>
12691
12692 Happened after an upgrade from IRCServices 5.0.19.
12693
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...
12698
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...
12701
12702 [Jun 25 13:27:10.120686 2003] IRC Services 5.0.20 starting up (options:
12703 debug)
12704 [Jun 25 13:27:10.121090 2003] debug: Loading language 0 from file
12705 `languages/en_us'
12706 [Jun 25 13:27:10.165071 2003] debug: Loading language 10 from file
12707 `languages/nl'
12708 [Jun 25 13:27:10.209443 2003] debug: Loading language 6 from file
12709 `languages/fr'
12710 [Jun 25 13:27:10.254186 2003] debug: Loading language 9 from file
12711 `languages/de'
12712 [Jun 25 13:27:10.298960 2003] debug: Loading language 11 from file
12713 `languages/hu'
12714 [Jun 25 13:27:10.343411 2003] debug: Loading language 8 from file
12715 `languages/it'
12716 [Jun 25 13:27:10.360265 2003] debug: Loading language 2 from file
12717 `languages/ja_euc'
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
12721 `languages/pt'
12722 [Jun 25 13:27:10.471159 2003] debug: Loading language 4 from file
12723 `languages/es'
12724 [Jun 25 13:27:10.515700 2003] debug: Loading language 7 from file
12725 `languages/tr'
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
12729 `protocol/unreal'
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
12732 `encryption/md5'
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
12742 `operserv/main'
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
12745 `operserv/akill'
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
12748 `operserv/news'
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
12754 `operserv/sline'
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
12757 `nickserv/main'
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
12760 `nickserv/access'
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
12766 `nickserv/link'
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
12772 `chanserv/main'
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
12778 `memoserv/main'
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
12781 `memoserv/forward'
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
12784 `memoserv/ignore'
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
12787 `statserv/main'
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
12793 `httpd/auth-ip'
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
12799 `httpd/dbaccess'
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
12802 `httpd/debug'
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
12805 `httpd/redirect'
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
12808 `httpd/top-page'
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
12812 not connected
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'
12843
12844
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>
12852
12853 On Wed, 25 Jun 2003 10:35:53 JST, Andrew Church <achurch@achurch.org>
12854 wrote:
12855
12856 > Easy counterexample: /os akill add luser@*.example.com (where it
12857 > would definitely _not_ be proper to use out-of-date data)
12858 >
12859
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>
12869
12870 > On Wed, 25 Jun 2003 10:35:53 JST, Andrew Church <achurch@achurch.org>
12871 > wrote:
12872 >
12873 >> Easy counterexample: /os akill add luser@*.example.com (where it
12874 >> would definitely _not_ be proper to use out-of-date data)
12875 >>
12876 >
12877 > I know, that's why one wouldn't use those functions in akill add.
12878
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.
12882
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
12886 to you.
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>
12895
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
12899 confused. Heh.
12900
12901 -- Jeff Kent
12902
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>
12911
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.
12918
12919 -- Jeff Kent
12920
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.
12925 >
12926 > -- Jeff Kent
12927
12928
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>
12936
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.
12943
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"
12947 error message.
12948
12949   --Andrew Church
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>
12957
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.
12968
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.
12977
12978 Just a few suggestions which I think would help out a ton. Thanks for your
12979 time.
12980
12981 ~Ganja51
12982
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>
12989
12990      Try SGLINE with SQlineKill (modules.conf).
12991
12992   --Andrew Church
12993     achurch@achurch.org
12994     http://achurch.org/
12995
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
12998 >ll
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
13005 >ll
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.
13008 >
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
13016 >e
13017 >the same random word/number generated for both the ident and realname.
13018 >
13019 >Just a few suggestions which I think would help out a ton. Thanks for you
13020 >r
13021 >time.
13022 >
13023 >~Ganja51
13024 >
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>
13033
13034 Hi all,
13035
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.
13040
13041 The quantum fisure has been knitted closed and the displacement field
13042 re-aligned, so mail should once again be reaching your mailboxes.
13043
13044 Sorry for any problems this may have caused.
13045
13046 Please direct and ill fealings, comments or just plain bad language to RIAA.
13047
13048 Thanks, Andrew
13049
13050 Oh, and have yourselves a fantastic weekend!
13051
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>
13057
13058 Does anyone have any comments on this idea?
13059
13060 (referring to this thread:
13061 http://www.ircservices.za.net/pipermail/ircservices-
13062 coding/2003/003670.html)
13063
13064
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>
13070
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 (: -- :)
13078
13079 ---------
13080 IRL: Panagiotis Kefalidis
13081 Brain? No route to host...
13082 Gizm0.-
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>
13090
13091 On Thu, 12 Jun 2003 18:38:47 -0600, Jeffery Kam <jskam@shaw.ca> wrote:
13092
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.
13100 >
13101 >
13102
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>
13109
13110
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
13115 SIGSEGV to do so.
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>
13122
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
13127 for the wrong CPU.
13128
13129   --Andrew Church
13130     achurch@achurch.org
13131     http://achurch.org/
13132
13133 >
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
13138 >SIGSEGV to do so.
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>
13149
13150 On Sat, 12 Jul 2003 03:19:34 JST, Andrew Church <achurch@achurch.org>
13151 wrote:
13152
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
13157 > compiled
13158 > for the wrong CPU.
13159 >
13160
13161 Well, we recently had a problem where our services (not ircservices but
13162 based on it)
13163 went into a spinlock, and there was no way we could even find out what it
13164 was because
13165 as soon as it happened the process monitor killed it for eating CPU, and
13166 there was no
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>
13177
13178 On Sat, 12 Jul 2003 03:19:34 JST, Andrew Church <achurch@achurch.org>
13179 wrote:
13180
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
13185 > compiled
13186 > for the wrong CPU.
13187
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>
13197
13198      (1) Not everyone thinks the same way you do and (2) just use GDB on
13199 the process and ^C it.
13200
13201 >On Sat, 12 Jul 2003 03:19:34 JST, Andrew Church <achurch@achurch.org>
13202 >wrote:
13203 >
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
13208 >> compiled
13209 >> for the wrong CPU.
13210 >
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
13217
13218   --Andrew Church
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>
13228
13229 Also, (sorry for bugging you), why not make DUMPCORE a runtime option? it's
13230 conceivable
13231 that the simple act of recompiling the program might make a bug go dormant
13232 or change.
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>
13239
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.
13245
13246 >Also, (sorry for bugging you), why not make DUMPCORE a runtime option? it's
13247 >conceivable
13248 >that the simple act of recompiling the program might make a bug go dormant
13249 >or change.
13250 >------------------------------------------------------------------
13251 >To unsubscribe or change your subscription options, visit:
13252 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
13253
13254   --Andrew Church
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>
13262
13263 For some reason, twice today I started receiving a new error
13264
13265 *** Global -- from services.nix.org.il: Network buffer size exceeded ignore threshold (95%), ignoring PRIVMSGs
13266
13267 After witch I needed to restart my services in order for them to stop ignoring users.
13268
13269 Why on earth am I getting this in the first place and how can I fix this?
13270
13271 I am running unreal 3.2 beta 17 with ircservices-5.0.20
13272
13273 (on irc.nix.org.il)
13274
13275 what to do?
13276
13277 If you'll come across our network, talk to PHANTOm or S7 in #operhelp
13278
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>
13288
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.
13291
13292
13293 Quoth Anton Volkov on Jul 17 at 21:15,
13294
13295 > For some reason, twice today I started receiving a new error
13296 >
13297 > *** Global -- from services.nix.org.il: Network buffer size exceeded ignore threshold (95%), ignoring PRIVMSGs
13298 >
13299 > After witch I needed to restart my services in order for them to stop ignoring users.
13300 >
13301 > Why on earth am I getting this in the first place and how can I fix this?
13302 >
13303 > I am running unreal 3.2 beta 17 with ircservices-5.0.20
13304 >
13305 > (on irc.nix.org.il)
13306 >
13307 > what to do?
13308 >
13309 > If you'll come across our network, talk to PHANTOm or S7 in #operhelp
13310 >
13311 >
13312
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>
13319
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?
13323
13324 Regards:
13325 pekem
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>
13337
13338 Quoting message from  pekem <pekem@clanarena.net>:
13339
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
13347 reasonable..
13348 > how to solve this problem. Can you help me?
13349 >
13350 > Regards:
13351 > pekem
13352 >
13353
13354
13355 ---------
13356 Brain? No route to host...
13357 Gizm0.-
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>
13363
13364 Hello,
13365
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
13368 IRCServices.
13369
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
13374 it in the TODO.
13375
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?
13385
13386 Grtz,
13387 Rodecker
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>
13395
13396 Hi,
13397
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.
13400
13401 Fast. Efficient.
13402
13403 Regards;
13404 yusuf
13405
13406 On Thu, 2003-07-24 at 12:02, Martin Pels wrote:
13407 > Hello,
13408 >
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
13411 > IRCServices.
13412 >
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
13417 > it in the TODO.
13418 >
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?
13428 >
13429 > Grtz,
13430 > Rodecker
13431 > ------------------------------------------------------------------
13432 > To unsubscribe or change your subscription options, visit:
13433 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
13434 --
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 ------------------------------------------------------------------
13441
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>
13448
13449 I have connected my services package through an ssl connection to my ircd.
13450
13451 Dylan.
13452
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
13458
13459
13460 > Hello,
13461 >
13462 > On our network we're currently taking a look on how we can make things
13463 more
13464 > secure. And while doiung that we came up with a couple of ideas to improve
13465 > IRCServices.
13466 >
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
13469 our
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
13472 about
13473 > it in the TODO.
13474 >
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
13479 case
13480 > they lose their password.
13481 > Would it be possible to, when encryption is enabled, change the behaviour
13482 of
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
13485 to
13486 > the user's e-mail address instead?
13487 >
13488 > Grtz,
13489 > Rodecker
13490 > ------------------------------------------------------------------
13491 > To unsubscribe or change your subscription options, visit:
13492 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
13493 >
13494
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>
13500
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
13502
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  ****************************************/
13510
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  ****************************************/
13517
13518 /****** - Begin Original Message - ******/
13519
13520 >I have connected my services package through an ssl connection to my ircd.
13521 >
13522 >Dylan.
13523 >
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
13529 >
13530 >
13531 >> Hello,
13532 >>
13533 >> On our network we're currently taking a look on how we can make things
13534 >more
13535 >> secure. And while doiung that we came up with a couple of ideas to improve
13536 >> IRCServices.
13537 >>
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
13540 >our
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
13543 >about
13544 >> it in the TODO.
13545 >>
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
13550 >case
13551 >> they lose their password.
13552 >> Would it be possible to, when encryption is enabled, change the behaviour
13553 >of
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
13556 >to
13557 >> the user's e-mail address instead?
13558 >>
13559 >> Grtz,
13560 >> Rodecker
13561 >> ------------------------------------------------------------------
13562 >> To unsubscribe or change your subscription options, visit:
13563 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
13564 >>
13565 >
13566 >------------------------------------------------------------------
13567 >To unsubscribe or change your subscription options, visit:
13568 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
13569 >.
13570
13571 /******* - End Original Message - *******/
13572
13573
13574
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>
13582
13583 Good idea, but that won't work if Services is on a different machine than
13584 the IRCd :-)
13585
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
13592
13593
13594 > Hi,
13595 >
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.
13598 >
13599 > Fast. Efficient.
13600 >
13601 > Regards;
13602 > yusuf
13603 >
13604 > On Thu, 2003-07-24 at 12:02, Martin Pels wrote:
13605 > > Hello,
13606 > >
13607 > > On our network we're currently taking a look on how we can make things
13608 more
13609 > > secure. And while doiung that we came up with a couple of ideas to
13610 improve
13611 > > IRCServices.
13612 > >
13613 > > One of the things we did is link all of our servers through SSL, and
13614 gave
13615 > > clients the option to connect through SSL as well. Now the only thing on
13616 our
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
13619 about
13620 > > it in the TODO.
13621 > >
13622 > > The second idea is about the encrypted passwords. As stated in the
13623 > > IRCServices documentation SENDPASS and GETPASS won't work with
13624 encryption
13625 > > enabled because of the way md5 works.
13626 > > This introduces the problem that users will have to contact an Oper in
13627 case
13628 > > they lose their password.
13629 > > Would it be possible to, when encryption is enabled, change the
13630 behaviour of
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
13633 to
13634 > > the user's e-mail address instead?
13635 > >
13636 > > Grtz,
13637 > > Rodecker
13638 > > ------------------------------------------------------------------
13639 > > To unsubscribe or change your subscription options, visit:
13640 > > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
13641 > --
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 > ------------------------------------------------------------------
13648 >
13649 > ------------------------------------------------------------------
13650 > To unsubscribe or change your subscription options, visit:
13651 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
13652 >
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>
13658
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 :)
13661
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  ****************************************/
13669
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  ****************************************/
13676
13677 /****** - Begin Original Message - ******/
13678
13679 >Good idea, but that won't work if Services is on a different machine than
13680 >the IRCd :-)
13681 >
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
13688 >
13689 >
13690 >> Hi,
13691 >>
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.
13694 >>
13695 >> Fast. Efficient.
13696 >>
13697 >> Regards;
13698 >> yusuf
13699 >>
13700 >> On Thu, 2003-07-24 at 12:02, Martin Pels wrote:
13701 >> > Hello,
13702 >> >
13703 >> > On our network we're currently taking a look on how we can make things
13704 >more
13705 >> > secure. And while doiung that we came up with a couple of ideas to
13706 >improve
13707 >> > IRCServices.
13708 >> >
13709 >> > One of the things we did is link all of our servers through SSL, and
13710 >gave
13711 >> > clients the option to connect through SSL as well. Now the only thing on
13712 >our
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
13715 >about
13716 >> > it in the TODO.
13717 >> >
13718 >> > The second idea is about the encrypted passwords. As stated in the
13719 >> > IRCServices documentation SENDPASS and GETPASS won't work with
13720 >encryption
13721 >> > enabled because of the way md5 works.
13722 >> > This introduces the problem that users will have to contact an Oper in
13723 >case
13724 >> > they lose their password.
13725 >> > Would it be possible to, when encryption is enabled, change the
13726 >behaviour of
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
13729 >to
13730 >> > the user's e-mail address instead?
13731 >> >
13732 >> > Grtz,
13733 >> > Rodecker
13734 >> > ------------------------------------------------------------------
13735 >> > To unsubscribe or change your subscription options, visit:
13736 >> > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
13737 >> --
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 >> ------------------------------------------------------------------
13744 >>
13745 >> ------------------------------------------------------------------
13746 >> To unsubscribe or change your subscription options, visit:
13747 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
13748 >>
13749 >------------------------------------------------------------------
13750 >To unsubscribe or change your subscription options, visit:
13751 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
13752 >.
13753
13754 /******* - End Original Message - *******/
13755
13756
13757
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>
13764
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)
13771
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.
13774
13775   --Andrew Church
13776     achurch@achurch.org
13777     http://achurch.org/
13778
13779 >Hello,
13780 >
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
13783 >IRCServices.
13784 >
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
13789 >it in the TODO.
13790 >
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?
13800 >
13801 >Grtz,
13802 >Rodecker
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>
13813
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...
13816
13817
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 (: -- :)
13825
13826 ---------
13827 IRL: Panagiotis Kefalidis
13828 Brain? No route to host...
13829 Gizm0.-
13830
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>
13836
13837 Hi there,
13838
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:
13841
13842     http://www.core.gen.tr/projeler/ircservices-mysql/
13843
13844 There is a source file, a db dump and my modified Makefile for database
13845 directory of ircservices modules.
13846
13847 PS: note that it's far from a complete module.
13848
13849 cheerz.
13850
13851 --
13852 | Aycan iRiCAN
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
13858
13859 Quote:
13860
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
13867 Size: 189 bytes
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>
13875
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
13880 have been denied.
13881
13882 /chanserv MARK <channel> <reason>
13883
13884 /chanserv info #channel would read the following.
13885 *#channel has been MARKED by playa - <reason>
13886
13887 Of course only IRCops would be able to view it.
13888
13889 Just an idea i thought of :)
13890
13891 --
13892 Best Regards,
13893 playa
13894 Network Founder/CEO
13895 DreamChat IRC Network - irc.dreamchat.org
13896 http://www.dreamchat.org
13897
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>
13904
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.
13908
13909 I have worked around this with IRCServices by creating an mIRC bot that
13910 performs a
13911 /nickserv list *
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.
13917
13918 Here's the question(s):
13919
13920 Can we reconsider adding a Mass memo function for the next release?
13921
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.
13926
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....
13931
13932 Any ideas you all have to share would be of great help.
13933
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 ...
13939
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........
13946
13947 Anyhow, I appreciate your takign the time to read this long request...
13948
13949 I await your replies =)
13950
13951 Saturn
13952 www.jetirc.net
13953
13954
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>
13961
13962 Saturn wrote:
13963 > Can we reconsider adding a Mass memo function for the next release?
13964
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
13967 users.
13968
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.
13974
13975 Do an info on the nick. It will explain the purpose of the symbol
13976 (forbidden/noexpire).
13977
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....
13983
13984 As an SA you can list links for a nick. A user has no need to determine
13985 links of other users.
13986
13987 > the main reason nobody read the logonnews is that
13988 > 90% of the time for them, it is unchanged........
13989
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
13993 "keep".
13994
13995 M.
13996
13997 ---
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
14001
14002
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>
14009
14010 M wrote:
14011
14012 Saturn wrote:
14013 >> Can we reconsider adding a Mass memo function for the next release?
14014
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
14017 >users.
14018
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
14021 events, etc
14022
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.
14028
14029 >Do an info on the nick. It will explain the purpose of the symbol
14030 >(forbidden/noexpire).
14031
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.....
14035
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....
14041
14042 >As an SA you can list links for a nick. A user has no need to determine
14043 >links of other users.
14044
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...
14048
14049 >> the main reason nobody read the logonnews is that
14050 >> 90% of the time for them, it is unchanged........
14051
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
14055 >"keep".
14056
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......
14063
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!
14070
14071 >M.
14072
14073
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>
14080
14081 Saturn wrote:
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
14085
14086 /os global <message>
14087
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.....
14091
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.
14094
14095 > >As an SA you can list links for a nick. A user has no need
14096 > to determine
14097 > >links of other users.
14098 >
14099 > Who decided that? you? Perhaps I would like my users to be
14100 > able to see the
14101 > links for each other...
14102
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
14108 the link system.
14109
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
14115 > actually SEE it.
14116
14117 That is hardly a services issue. The IRCd would be the place to add
14118 false delays into the login process.
14119
14120 I doubt users would welcome having a connection to the network paused
14121 for such a reason.
14122
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......
14126
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.
14131
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...
14139
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.
14143
14144 As suggested above, "mass memos" would not solve your "problem".
14145
14146 M.
14147
14148 ---
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
14152
14153
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>
14160
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.
14167 >
14168 > That is hardly a services issue. The IRCd would be the place to add
14169 > false delays into the login process.
14170 >
14171 > I doubt users would welcome having a connection to the network paused
14172 > for such a reason.
14173
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.
14178
14179 Russ
14180
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>
14187
14188 On Wednesday, Aug 13, 2003, at 15:10 US/Pacific, M wrote:
14189
14190 > Saturn 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
14194 >
14195 > /os global <message>
14196
14197 That doesn't cover people who aren't online at the time.
14198
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.....
14202 >
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.
14205
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
14210 contexts.
14211
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.
14217 >
14218 > That is hardly a services issue. The IRCd would be the place to add
14219 > false delays into the login process.
14220
14221 Logonnews is not part of the ircd's login process.
14222
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......
14225 >
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.
14230
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.
14235
14236 -- Quension
14237
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>
14244
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.
14251
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?
14255
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.
14259
14260 A lot of things that might not sound like a bad idea need a lot more
14261 thought before considering for implementation.
14262
14263 M.
14264
14265 ---
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
14269
14270
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>
14277
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
14282 > >
14283 > > /os global <message>
14284 >
14285 > That doesn't cover people who aren't online at the time.
14286
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.
14292
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.
14299
14300 > > You did not ask a memo question that has an answer, you
14301 > made a feature
14302 > > request. The nick prefix has nothing to do with memos.
14303 >
14304 > He described a visibility problem as a reason for the feature
14305 > request.
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
14309 > contexts.
14310
14311 This was covered in depth during my response.
14312
14313 > >> Frankly, logonnews is useless, and most of my users and
14314 > opers agree.
14315 > >> It scrolls off too fast.  Ideally, it shoudl have a delay
14316 > to prevent
14317 > >> it being lost in the system notices on connection.  Maybe
14318 > a 10 second
14319 > >> delay beforee it flashes by, to give the user time to
14320 > connect, etc,
14321 > >> and then they might actually SEE it.
14322 > >
14323 > > That is hardly a services issue. The IRCd would be the place to add
14324 > > false delays into the login process.
14325 >
14326 > Logonnews is not part of the ircd's login process.
14327
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.
14331
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......
14334 > >
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
14337 > still are not
14338 > > guaranteed to be read. They could also add you to their
14339 > ignore list so
14340 > > your message would not get through in any case.
14341 >
14342 > Memos generally have a much higher visibility than logonnews.
14343
14344 Really? At logon, the notice of new memos is just as lost as logon news.
14345
14346
14347 > You're
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
14350 > people on a lot
14351 > of different networks, apparently including Saturn.
14352
14353 Without examples supporting the original suggestion, there is no need to
14354 provide contrary ones.
14355
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.
14360
14361 M.
14362
14363 ---
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
14367
14368
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>
14375
14376 OK apparently you just don't read the meaning of my words very well, let me
14377 reiterate:
14378
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....
14382
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.
14388
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
14394
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.
14407
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.
14412
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?
14419
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.
14423
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...
14426
14427 Saturn
14428
14429
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
14436
14437
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.
14444
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?
14448
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.
14452
14453 A lot of things that might not sound like a bad idea need a lot more
14454 thought before considering for implementation.
14455
14456 M.
14457
14458 ---
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
14462
14463
14464 ------------------------------------------------------------------
14465 To unsubscribe or change your subscription options, visit:
14466 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
14467
14468
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>
14475
14476 Saturn wrote:
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....
14481
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.
14485
14486 Discussion, particularly for new features has to include all aspects
14487 whether or not they agree with you.
14488
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.
14496
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.
14500
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
14507
14508 Did I suggest that? No.
14509
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.
14515
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
14521 effect.
14522
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.
14526
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.
14532
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.
14537
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.
14543
14544 Personally I do not discriminate against unregistered users.
14545 Registration provides more features but is not a requirement.
14546
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.
14552
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.
14557
14558 Not at all. It is a service provided for the users that they can choose
14559 to use or not use.
14560
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?
14568
14569 I have stated my opinions on this in previous posts and this one.
14570
14571 > Your condescending attitude is certainly not appreciated, and
14572
14573 LOL. Glass houses.
14574
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.
14578
14579 Should I care?
14580
14581 Would you care to share publicly how inaccurate the above statement you
14582 made was?
14583
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...
14587
14588 Interesting POV.
14589
14590 M.
14591
14592 ---
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
14596
14597
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>
14604
14605 On Wednesday, Aug 13, 2003, at 15:48 US/Pacific, M wrote:
14606
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
14611 >>>
14612 >>> /os global <message>
14613 >>
14614 >> That doesn't cover people who aren't online at the time.
14615 >
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.
14621
14622 I agree with you on the specific case of outages, but I was speaking
14623 for general usage.
14624
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.
14630 >>>
14631 >>> That is hardly a services issue. The IRCd would be the place to add
14632 >>> false delays into the login process.
14633 >>
14634 >> Logonnews is not part of the ircd's login process.
14635 >
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.
14639
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
14644 present there.
14645
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......
14648 >>>
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.
14653 >>
14654 >> Memos generally have a much higher visibility than logonnews.
14655 >
14656 > Really? At logon, the notice of new memos is just as lost as logon
14657 > news.
14658
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.
14663
14664 Memo visibility is logically heightened by notification in other
14665 circumstances: nick changes, identification, etc.
14666
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.
14671
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.
14680
14681 In the meantime, things such as mass memos are useful for a variety of
14682 reasons.
14683
14684 -- Quension
14685
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>
14691
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.
14693
14694 If you really wanted mass memo, it shouldnt really be too hard to make a simple module that did it...
14695
14696 --
14697 Craig "FrostyCoolSlug" McLure..
14698 Netadmin of the ChatSpike IRC Network..
14699 ChatSpike.. Now with Web-Based Services frontend! http://www.chatspike.net
14700
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  ****************************************/
14707
14708 /****** - Begin Original Message - ******/
14709
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.
14716 >>
14717 >> That is hardly a services issue. The IRCd would be the place to add
14718 >> false delays into the login process.
14719 >>
14720 >> I doubt users would welcome having a connection to the network paused
14721 >> for such a reason.
14722 >
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.
14727 >
14728 >Russ
14729 >
14730 >------------------------------------------------------------------
14731 >To unsubscribe or change your subscription options, visit:
14732 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
14733 >.
14734
14735 /******* - End Original Message - *******/
14736
14737
14738
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>
14745
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
14751 > present there.
14752
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.
14762
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.
14768
14769 > Many people
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.
14773
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.
14778
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.
14786
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.
14795
14796 > Memo visibility is logically heightened by notification in other
14797 > circumstances: nick changes, identification, etc.
14798
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.
14806
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
14814 > time, and
14815 > clients haven't done much with it.
14816
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
14821 changes.
14822
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.
14828
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).
14835
14836
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.
14842
14843 > In the meantime, things such as mass memos are useful for a variety of
14844 > reasons.
14845
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.
14851
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
14858 users.
14859
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.
14868
14869 M.
14870
14871 ---
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
14875
14876
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>
14882
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
14885 relase?
14886 -----
14887 Original E-mail:
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
14892 have been denied.
14893
14894 /chanserv MARK <channel> <reason>
14895
14896 /chanserv info #channel would read the following.
14897 *#channel has been MARKED by playa - <reason>
14898
14899 Of course only IRCops would be able to view it.
14900
14901 Just an idea i thought of :)
14902
14903 --
14904 Best Regards,
14905 playa
14906 Network Founder/CEO
14907 DreamChat IRC Network - irc.dreamchat.org
14908 http://www.dreamchat.org
14909
14910
14911
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>
14917
14918 we all saw the first email.. and personally, i dont see a point..
14919
14920 But thats just me.
14921
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  ****************************************/
14929
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  ****************************************/
14936
14937 /****** - Begin Original Message - ******/
14938
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
14941 >relase?
14942 >-----
14943 >Original E-mail:
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
14948 >have been denied.
14949 >
14950 >/chanserv MARK <channel> <reason>
14951 >
14952 >/chanserv info #channel would read the following.
14953 >*#channel has been MARKED by playa - <reason>
14954 >
14955 >Of course only IRCops would be able to view it.
14956 >
14957 >Just an idea i thought of :)
14958 >
14959 >--
14960 >Best Regards,
14961 >playa
14962 >Network Founder/CEO
14963 >DreamChat IRC Network - irc.dreamchat.org
14964 >http://www.dreamchat.org
14965 >
14966 >
14967 >
14968 >------------------------------------------------------------------
14969 >To unsubscribe or change your subscription options, visit:
14970 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
14971 >.
14972
14973 /******* - End Original Message - *******/
14974
14975
14976
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>
14984
14985 It may be useful for keeping track/history of abuse.
14986
14987
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..
14991 >
14992 > But thats just me.
14993 >
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 >  ****************************************/
15001 >
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 >  ****************************************/
15008 >
15009 > /****** - Begin Original Message - ******/
15010 >
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
15013 > >relase?
15014 > >-----
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.
15021 > >
15022 > >/chanserv MARK <channel> <reason>
15023 > >
15024 > >/chanserv info #channel would read the following.
15025 > >*#channel has been MARKED by playa - <reason>
15026 > >
15027 > >Of course only IRCops would be able to view it.
15028 > >
15029 > >Just an idea i thought of :)
15030 > >
15031 > >--
15032 > >Best Regards,
15033 > >playa
15034 > >Network Founder/CEO
15035 > >DreamChat IRC Network - irc.dreamchat.org
15036 > >http://www.dreamchat.org
15037 > >
15038 > >
15039 > >
15040 > >------------------------------------------------------------------
15041 > >To unsubscribe or change your subscription options, visit:
15042 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
15043 > >.
15044 >
15045 > /******* - End Original Message - *******/
15046 >
15047 >
15048 >
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>
15057
15058 Hi
15059
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)
15064
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.
15067
15068 Thanks for any help
15069
15070
15071                            Ali "Simorgh"
15072  ______________________________________________________
15073  Many of life's failures are people who did not realize
15074  how close they were to success when they gave up.
15075  Thomas A. Edison
15076  ______________________________________________________
15077
15078
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>
15085
15086 Eh? This has been implemented since IRCServices 5a31.
15087
15088 Russ
15089
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)
15094 >
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
15097 > channels.
15098 >
15099 > Thanks for any help
15100
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>
15106
15107 Hi again
15108
15109 Is there any tool (silly question) or something or guid to make a language
15110 file.
15111
15112 I have decided to make a Persian (Farsi) language file.
15113
15114 Thanks for any ideas
15115
15116
15117                            Ali "Simorgh"
15118  ______________________________________________________
15119  Many of life's failures are people who did not realize
15120  how close they were to success when they gave up.
15121  Thomas A. Edison
15122  ______________________________________________________
15123
15124
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>
15130
15131 Find the english language file in the source..
15132
15133 Read the warnings about format etc, and work with that :)
15134
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  ****************************************/
15142
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  ****************************************/
15149
15150 /****** - Begin Original Message - ******/
15151
15152 >Hi again
15153 >
15154 >Is there any tool (silly question) or something or guid to make a language
15155 >file.
15156 >
15157 >I have decided to make a Persian (Farsi) language file.
15158 >
15159 >Thanks for any ideas
15160 >
15161 >
15162 >                           Ali "Simorgh"
15163 > ______________________________________________________
15164 > Many of life's failures are people who did not realize
15165 > how close they were to success when they gave up.
15166 > Thomas A. Edison
15167 > ______________________________________________________
15168 >
15169 >
15170 >------------------------------------------------------------------
15171 >To unsubscribe or change your subscription options, visit:
15172 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
15173
15174 /******* - End Original Message - *******/
15175
15176
15177
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>
15184
15185 > Find the english language file in the source..
15186 >
15187 > Read the warnings about format etc, and work with that :)
15188
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
15194 it.
15195
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?
15200
15201 Russ
15202
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>
15209
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.
15214
15215 ~Ganja51
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
15222
15223
15224 > > Find the english language file in the source..
15225 > >
15226 > > Read the warnings about format etc, and work with that :)
15227 >
15228 > A sort-of-related matter - I have a few patches against the English
15229 language
15230 > file to change such stuff as /msg nickserv to /nickserv, partly for
15231 neatness
15232 > and partly because /msging services is generally bad practice where
15233 networks
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
15236 > it.
15237 >
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
15240 community
15241 > as a whole to get away from the habit of msging services directly if at
15242 all
15243 > possible. Opinions?
15244 >
15245 > Russ
15246 >
15247 > ------------------------------------------------------------------
15248 > To unsubscribe or change your subscription options, visit:
15249 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
15250
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>
15256
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 :)
15258
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  ****************************************/
15266
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  ****************************************/
15273
15274 /****** - Begin Original Message - ******/
15275
15276 >> Find the english language file in the source..
15277 >>
15278 >> Read the warnings about format etc, and work with that :)
15279 >
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
15285 >it.
15286 >
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?
15291 >
15292 >Russ
15293 >
15294 >------------------------------------------------------------------
15295 >To unsubscribe or change your subscription options, visit:
15296 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
15297 >.
15298
15299 /******* - End Original Message - *******/
15300
15301
15302
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>
15308
15309 hi all.
15310
15311 i'm using unrealircd with ircservices 5.0.21, and i already modified the
15312 code like this:
15313
15314 in modules/nickserv/main.c :
15315
15316 /* Callback for users connecting to the network. */
15317 /* MODIFIED CALLBACK */
15318 static int do_user_create(User *user, int ac, char **av)
15319 {
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");
15323     return 0;
15324 }
15325
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.
15330
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.
15334
15335 anyone that can help me, please ?
15336
15337 thx
15338
15339 _________________________________________________________________
15340 MSN Search, for relevant search results! http://search.msn.be
15341
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>
15347
15348 as a note.. we aint supposed to support modified versions of services.. (i'm not sure if this includes the module source..)
15349
15350 Havnt you concidered using Unreals built in host masking instead? it seems like a better alternative :/
15351
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  ****************************************/
15359
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  ****************************************/
15366
15367 /****** - Begin Original Message - ******/
15368
15369 >hi all.
15370 >
15371 >i'm using unrealircd with ircservices 5.0.21, and i already modified the
15372 >code like this:
15373 >
15374 >in modules/nickserv/main.c :
15375 >
15376 >/* Callback for users connecting to the network. */
15377 >/* MODIFIED CALLBACK */
15378 >static int do_user_create(User *user, int ac, char **av)
15379 >{
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");
15383 >    return 0;
15384 >}
15385 >
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.
15390 >
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.
15394 >
15395 >anyone that can help me, please ?
15396 >
15397 >thx
15398 >
15399 >_________________________________________________________________
15400 >MSN Search, for relevant search results! http://search.msn.be
15401 >
15402 >------------------------------------------------------------------
15403 >To unsubscribe or change your subscription options, visit:
15404 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
15405 >.
15406
15407 /******* - End Original Message - *******/
15408
15409
15410
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>
15416
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
15426
15427
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
15433 Marc
15434
15435 PsYcHoPaT
15436 irc.terra.cl
15437
15438 services version:
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>
15449
15450 Hi again
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.
15453
15454 Like:
15455  SET NOAUTO ON|OFF
15456   When NOAUTO is on, ChanServ will not
15457   automatically op or voice you in any channels.
15458
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.
15461
15462 Or did I miss it?
15463
15464 Thanks
15465
15466                            Ali "Simorgh"
15467  ______________________________________________________
15468  Many of life's failures are people who did not realize
15469  how close they were to success when they gave up.
15470  Thomas A. Edison
15471  ______________________________________________________
15472
15473
15474 On Sun, 17 Aug 2003, Russell Garrett wrote:
15475
15476 > Eh? This has been implemented since IRCServices 5a31.
15477 >
15478 > Russ
15479 >
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)
15484 > >
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
15487 > > channels.
15488 > >
15489 > > Thanks for any help
15490 >
15491 > ------------------------------------------------------------------
15492 > To unsubscribe or change your subscription options, visit:
15493 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
15494 >
15495
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>
15502
15503 You can't.
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 ;-)
15510
15511 Georges
15512
15513
15514
15515
15516 Ali Simorgh wrote:
15517
15518 >Hi again
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.
15521 >
15522 >Like:
15523 > SET NOAUTO ON|OFF
15524 >  When NOAUTO is on, ChanServ will not
15525 >  automatically op or voice you in any channels.
15526 >
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.
15529 >
15530 >Or did I miss it?
15531 >
15532 >Thanks
15533 >
15534 >                           Ali "Simorgh"
15535 > ______________________________________________________
15536 > Many of life's failures are people who did not realize
15537 > how close they were to success when they gave up.
15538 > Thomas A. Edison
15539 > ______________________________________________________
15540 >
15541 >
15542 >On Sun, 17 Aug 2003, Russell Garrett wrote:
15543 >
15544 >
15545 >
15546 >>Eh? This has been implemented since IRCServices 5a31.
15547 >>
15548 >>Russ
15549 >>
15550 >>
15551 >>
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)
15556 >>>
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
15559 >>>channels.
15560 >>>
15561 >>>Thanks for any help
15562 >>>
15563 >>>
15564 >>------------------------------------------------------------------
15565 >>To unsubscribe or change your subscription options, visit:
15566 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
15567 >>
15568 >>
15569 >>
15570 >
15571 >------------------------------------------------------------------
15572 >To unsubscribe or change your subscription options, visit:
15573 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
15574 >
15575 >
15576 >
15577 >
15578
15579
15580
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>
15587
15588
15589 What does this mean: (log file)
15590
15591 [Aug 21 18:13:34 2003] sockets: flush_write_buffer(0): Socket is not connected
15592
15593 Thanks
15594
15595                            Ali "Simorgh"
15596  ______________________________________________________
15597  Many of life's failures are people who did not realize
15598  how close they were to success when they gave up.
15599  Thomas A. Edison
15600  ______________________________________________________
15601
15602
15603
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>
15609
15610 I'm assuming it means the socket is not connected..
15611
15612 Make sure its able to connect to your IRCd through the ports provided.
15613
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  ****************************************/
15621
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  ****************************************/
15628
15629 /****** - Begin Original Message - ******/
15630
15631 >What does this mean: (log file)
15632 >
15633 >[Aug 21 18:13:34 2003] sockets: flush_write_buffer(0): Socket is not connected
15634 >
15635 >Thanks
15636 >
15637 >                           Ali "Simorgh"
15638 > ______________________________________________________
15639 > Many of life's failures are people who did not realize
15640 > how close they were to success when they gave up.
15641 > Thomas A. Edison
15642 > ______________________________________________________
15643 >
15644 >
15645 >
15646 >------------------------------------------------------------------
15647 >To unsubscribe or change your subscription options, visit:
15648 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
15649 >.
15650
15651 /******* - End Original Message - *******/
15652
15653
15654
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>
15660
15661
15662
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>
15668
15669 Hi,
15670
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:
15674
15675 ***************************
15676 -
15677 -NickServ- nick is hello world
15678 -
15679 -NickServ- Is online from: ~test@just.a.test.co.za
15680 -
15681 -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
15682 -
15683 -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
15684 -
15685 -NickServ- Last quit message: anythinggggg
15686 -
15687 -NickServ- Options: Kill protection, Security
15688 -
15689 ***************************
15690
15691 the new line I'm suggesting is something like:
15692
15693 ***************************
15694 -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
15695 ***************************
15696
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).
15702
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)
15706
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)
15709
15710 Many thanks to all of who developed IRCservices ...etc ...etc ...etc
15711
15712 sincerely,
15713 David
15714
15715 _________________________________________________________________
15716 Get MSN 8 and enjoy automatic e-mail virus protection.
15717 http://join.msn.com/?page=features/virus
15718
15719
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>
15727
15728 Or how about rather letting users decide what timezone they're in and
15729 services outputs all timestamps in their local time?
15730
15731
15732 | By us44ever . <us44ever@hotmail.com>
15733 |                                          [ 2003-08-28 18:45 +0200 ]
15734 > Hi,
15735 >
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:
15739 >
15740 > ***************************
15741 > -
15742 > -NickServ- nick is hello world
15743 > -
15744 > -NickServ- Is online from: ~test@just.a.test.co.za
15745 > -
15746 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
15747 > -
15748 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
15749 > -
15750 > -NickServ- Last quit message: anythinggggg
15751 > -
15752 > -NickServ- Options: Kill protection, Security
15753 > -
15754 > ***************************
15755 >
15756 > the new line I'm suggesting is something like:
15757 >
15758 > ***************************
15759 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
15760 > ***************************
15761 >
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).
15767 >
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)
15771 >
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)
15774 >
15775 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
15776 >
15777 > sincerely,
15778 > David
15779 >
15780 > _________________________________________________________________
15781 > Get MSN 8 and enjoy automatic e-mail virus protection.
15782 > http://join.msn.com/?page=features/virus
15783 >
15784 > ------------------------------------------------------------------
15785 > To unsubscribe or change your subscription options, visit:
15786 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
15787
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>
15795
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
15803
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
15809
15810
15811 Or how about rather letting users decide what timezone they're in and
15812 services outputs all timestamps in their local time?
15813
15814
15815 | By us44ever . <us44ever@hotmail.com>
15816 |                                          [ 2003-08-28 18:45 +0200 ]
15817 > Hi,
15818 >
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:
15822 >
15823 > ***************************
15824 > -
15825 > -NickServ- nick is hello world
15826 > -
15827 > -NickServ- Is online from: ~test@just.a.test.co.za
15828 > -
15829 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
15830 > -
15831 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
15832 > -
15833 > -NickServ- Last quit message: anythinggggg
15834 > -
15835 > -NickServ- Options: Kill protection, Security
15836 > -
15837 > ***************************
15838 >
15839 > the new line I'm suggesting is something like:
15840 >
15841 > ***************************
15842 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
15843 > ***************************
15844 >
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).
15850 >
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)
15854 >
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)
15857 >
15858 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
15859 >
15860 > sincerely,
15861 > David
15862 >
15863 > _________________________________________________________________
15864 > Get MSN 8 and enjoy automatic e-mail virus protection.
15865 > http://join.msn.com/?page=features/virus
15866 >
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
15873
15874
15875
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>
15881
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..
15883
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
15886
15887 *shock*
15888
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  ****************************************/
15896
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  ****************************************/
15903
15904 /****** - Begin Original Message - ******/
15905
15906 >Hi,
15907 >
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:
15911 >
15912 >***************************
15913 >-
15914 >-NickServ- nick is hello world
15915 >-
15916 >-NickServ- Is online from: ~test@just.a.test.co.za
15917 >-
15918 >-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
15919 >-
15920 >-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
15921 >-
15922 >-NickServ- Last quit message: anythinggggg
15923 >-
15924 >-NickServ- Options: Kill protection, Security
15925 >-
15926 >***************************
15927 >
15928 >the new line I'm suggesting is something like:
15929 >
15930 >***************************
15931 >-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
15932 >***************************
15933 >
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).
15939 >
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)
15943 >
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)
15946 >
15947 >Many thanks to all of who developed IRCservices ...etc ...etc ...etc
15948 >
15949 >sincerely,
15950 >David
15951 >
15952 >_________________________________________________________________
15953 >Get MSN 8 and enjoy automatic e-mail virus protection.
15954 >http://join.msn.com/?page=features/virus
15955 >
15956 >------------------------------------------------------------------
15957 >To unsubscribe or change your subscription options, visit:
15958 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
15959
15960 /******* - End Original Message - *******/
15961
15962
15963
15964
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>
15970
15971 We're having a small problem with suspended channel.
15972
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.
15975
15976 Also with suspended nick , when the suspencion expire, the services crash
15977 We're using:
15978
15979 ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
15980
15981
15982 Thanks
15983 Marc
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>
15992
15993 hmm.. what OS, compiler version etc are you using?
15994
15995 after a test, i got the following:
15996
15997 /cs id #abc 00376370
15998 -ChanServ- Channel #abc is suspended and may not be used or identified for.
15999
16000 /cs drop #abc
16001 [23:20] -ChanServ- Channel  is suspended and may not be used or identified for.
16002
16003 only prob i got was it missed the channel name in the second message :)
16004
16005 /cs drop #abc
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  ****************************************/
16013
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  ****************************************/
16020
16021 /****** - Begin Original Message - ******/
16022
16023 >We're having a small problem with suspended channel.
16024 >
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.
16027 >
16028 >Also with suspended nick , when the suspencion expire, the services crash
16029 >We're using:
16030 >
16031 >ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
16032 >
16033 >
16034 >Thanks
16035 >Marc
16036 >------------------------------------------------------------------
16037 >To unsubscribe or change your subscription options, visit:
16038 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
16039
16040 /******* - End Original Message - *******/
16041
16042
16043
16044
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>
16051
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...
16056
16057 Just an idea... I now await the half dozen people who will proceed to tell
16058 me how stupid my idea is....
16059
16060 Saturn
16061 irc.jetirc.net
16062
16063
16064
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>
16072
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.
16077
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..
16081 >
16082 > /time services.chatspike.net
16083 > [22:28] ??? Date / time at services.chatspike.net- Thu Aug 28 17:28:57
16084 > 2003 EDT
16085 >
16086 > *shock*
16087 >
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 >  ****************************************/
16095 >
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 >  ****************************************/
16102 >
16103 > /****** - Begin Original Message - ******/
16104 >
16105 >>Hi,
16106 >>
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:
16110 >>
16111 >>***************************
16112 >>-
16113 >>-NickServ- nick is hello world
16114 >>-
16115 >>-NickServ- Is online from: ~test@just.a.test.co.za
16116 >>-
16117 >>-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
16118 >>-
16119 >>-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
16120 >>-
16121 >>-NickServ- Last quit message: anythinggggg
16122 >>-
16123 >>-NickServ- Options: Kill protection, Security
16124 >>-
16125 >>***************************
16126 >>
16127 >>the new line I'm suggesting is something like:
16128 >>
16129 >>***************************
16130 >>-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
16131 >>***************************
16132 >>
16133 >>This will help our users to compare the time that user was last seen and
16134 >> the
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
16138 >> GMT
16139 >>(last seen time was before: 10 days, 3hours and 24 sec ago).
16140 >>
16141 >>Note that I saw both of these features, in other services I don't
16142 >> remember
16143 >>there names (but they aren't as stable as ircservices5) (it was something
16144 >>like ptlink services, and magik II)
16145 >>
16146 >>That's all, I would really like to see it on the next version (or if you
16147 >> can
16148 >>show me how to do it, as I'm not a programmer)
16149 >>
16150 >>Many thanks to all of who developed IRCservices ...etc ...etc ...etc
16151 >>
16152 >>sincerely,
16153 >>David
16154 >>
16155 >>_________________________________________________________________
16156 >>Get MSN 8 and enjoy automatic e-mail virus protection.
16157 >>http://join.msn.com/?page=features/virus
16158 >>
16159 >>------------------------------------------------------------------
16160 >>To unsubscribe or change your subscription options, visit:
16161 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
16162 >
16163 > /******* - End Original Message - *******/
16164 >
16165 >
16166 >
16167 > ------------------------------------------------------------------
16168 > To unsubscribe or change your subscription options, visit:
16169 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
16170 >
16171
16172
16173 --
16174 Best Regards,
16175 playa
16176 Network Founder/CEO
16177 DreamChat IRC Network - irc.dreamchat.org
16178 http://www.dreamchat.org
16179
16180
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>
16187
16188 On Thursday, Aug 28, 2003, at 20:46 US/Pacific, playa wrote:
16189
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.
16194
16195 That's a client thing.  Some clients might alias /time as a CTCP TIME
16196 for a specific user, or similar.
16197
16198 -- Quension
16199
16200
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>
16209
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.
16214
16215 Some clients use stupid aliases for CTCP commands, for example:
16216
16217 /version <nick> = /CTCP <nick> VERSION,
16218 /time <nick> = /CTCP <nick> TIME,
16219 /finger <nick> = /CTCP <nick> TIME
16220
16221 This is why nothing works the way you expected.
16222
16223 --
16224 Krisztian Romek
16225 r-krisztian@softhome.net
16226
16227
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>
16233
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).
16237
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
16241
16242
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>
16248
16249
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.
16255
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
16259
16260
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>
16266
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.
16268
16269 And i'll Quote Elijah:
16270
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
16273 be 'no.'"
16274
16275
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  ****************************************/
16283
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  ****************************************/
16290
16291 /****** - Begin Original Message - ******/
16292
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.
16298 >
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
16302 >
16303 >------------------------------------------------------------------
16304 >To unsubscribe or change your subscription options, visit:
16305 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
16306 >.
16307
16308 /******* - End Original Message - *******/
16309
16310
16311
16312
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>
16318
16319 its a stupid idea!!! :p
16320
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
16322
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  ****************************************/
16330
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  ****************************************/
16337
16338 /****** - Begin Original Message - ******/
16339
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...
16344 >
16345 >Just an idea... I now await the half dozen people who will proceed to tell
16346 >me how stupid my idea is....
16347 >
16348 >Saturn
16349 >irc.jetirc.net
16350 >
16351 >
16352 >------------------------------------------------------------------
16353 >To unsubscribe or change your subscription options, visit:
16354 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
16355
16356 /******* - End Original Message - *******/
16357
16358
16359
16360
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>
16367
16368 Cheers.
16369
16370 -----Original Message-----
16371 From: ircservices-coding-bounces@ircservices.za.net
16372 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of Craig
16373 McLure
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
16377
16378
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
16381 to annoy me.
16382
16383 And i'll Quote Elijah:
16384
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
16387 be 'no.'"
16388
16389
16390
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>
16396
16397 woops, ok sorry I thought the two e-mails is completely different.
16398
16399
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
16407 >
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.
16411 >
16412 >And i'll Quote Elijah:
16413 >
16414 >"Except it's already been said in the FAQ that it's not going to happen,
16415 >and
16416 >if that made it into the FAQ it would seem the answer is frequently going
16417 >to
16418 >be 'no.'"
16419 >
16420 >
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 >  ****************************************/
16428 >
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 >  ****************************************/
16435 >
16436 >/****** - Begin Original Message - ******/
16437 >
16438 > >Since most people want to see this feature(s) in the next version, it
16439 >would
16440 > >be great to implement it as an optional feature , where it can be
16441 >disabled
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
16444 >fact,
16445 > >it will add another nice feature to the features list of IRCservices5.
16446 > >
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
16450 > >
16451 > >------------------------------------------------------------------
16452 > >To unsubscribe or change your subscription options, visit:
16453 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
16454 > >.
16455 >
16456 >/******* - End Original Message - *******/
16457 >
16458 >
16459 >
16460 >------------------------------------------------------------------
16461 >To unsubscribe or change your subscription options, visit:
16462 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
16463
16464 _________________________________________________________________
16465 MSN 8: Get 6 months for $9.95/month. http://join.msn.com/?page=dept/dialup
16466
16467
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>
16474
16475 Hi
16476 I run ircservices 5.0.21 on FreeBSD 4.8-STABLE. and Ultimate 3.*
16477 I get this in logfile:
16478
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)
16491
16492 and how can I do so that nickserv dont show the realhost of a user in
16493 'ns info nick all'
16494
16495
16496 thanks for help
16497
16498                            Ali "Simorgh"
16499  ______________________________________________________
16500  Many of life's failures are people who did not realize
16501  how close they were to success when they gave up.
16502  Thomas A. Edison
16503  ______________________________________________________
16504
16505
16506
16507
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>
16514
16515 "and how can I do so that nickserv dont show the realhost of a user in
16516 'ns info nick all'"
16517
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
16521 option is set.
16522
16523
16524
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>
16531
16532      Use E-mail if you need communication of that sort.
16533
16534   --Andrew Church
16535     achurch@achurch.org
16536     http://achurch.org/
16537
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
16542 >have been denied.
16543 >
16544 >/chanserv MARK <channel> <reason>
16545 >
16546 >/chanserv info #channel would read the following.
16547 >*#channel has been MARKED by playa - <reason>
16548 >
16549 >Of course only IRCops would be able to view it.
16550 >
16551 >Just an idea i thought of :)
16552 >
16553 >--
16554 >Best Regards,
16555 >playa
16556 >Network Founder/CEO
16557 >DreamChat IRC Network - irc.dreamchat.org
16558 >http://www.dreamchat.org
16559 >
16560 >------------------------------------------------------------------
16561 >To unsubscribe or change your subscription options, visit:
16562 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
16563
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>
16570
16571      Needless complexity.  If you don't want yourself autoopped, then don't
16572 be an auto-op.  It's that simple.
16573
16574   --Andrew Church
16575     achurch@achurch.org
16576     http://achurch.org/
16577
16578 >Hi again
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.
16581 >
16582 >Like:
16583 > SET NOAUTO ON|OFF
16584 >  When NOAUTO is on, ChanServ will not
16585 >  automatically op or voice you in any channels.
16586 >
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.
16589 >
16590 >Or did I miss it?
16591 >
16592 >Thanks
16593 >
16594 >                           Ali "Simorgh"
16595 > ______________________________________________________
16596 > Many of life's failures are people who did not realize
16597 > how close they were to success when they gave up.
16598 > Thomas A. Edison
16599 > ______________________________________________________
16600 >
16601 >
16602 >On Sun, 17 Aug 2003, Russell Garrett wrote:
16603 >
16604 >> Eh? This has been implemented since IRCServices 5a31.
16605 >>
16606 >> Russ
16607 >>
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)
16612 >> >
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
16615 >> > channels.
16616 >> >
16617 >> > Thanks for any help
16618 >>
16619 >> ------------------------------------------------------------------
16620 >> To unsubscribe or change your subscription options, visit:
16621 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
16622 >>
16623 >
16624 >------------------------------------------------------------------
16625 >To unsubscribe or change your subscription options, visit:
16626 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
16627
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>
16635
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.
16639
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
16648 is not complex.
16649
16650 Shaun
16651
16652
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>
16658
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..
16661
16662 or /cs levels #channels DISABLE autoop
16663
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  ****************************************/
16671
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  ****************************************/
16678
16679 /****** - Begin Original Message - ******/
16680
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.
16684 >
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
16693 >is not complex.
16694 >
16695 >Shaun
16696 >
16697 >------------------------------------------------------------------
16698 >To unsubscribe or change your subscription options, visit:
16699 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
16700 >.
16701
16702 /******* - End Original Message - *******/
16703
16704
16705
16706
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>
16714
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..
16717
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.
16720
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
16723
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
16730
16731 Same with ENFORCE set to off as well.
16732
16733 > [snipped obnoxiously long sig]
16734
16735 Shaun Guth
16736
16737
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>
16744
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
16747 >
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
16754
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.
16758
16759   --Andrew Church
16760     achurch@achurch.org
16761     http://achurch.org/
16762
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>
16769
16770 >Can we reconsider adding a Mass memo function for the next release?
16771
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.
16779
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.
16785
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.
16790
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.
16793
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........
16800
16801      This is an interesting thought; I'll think about it for a future
16802 version.
16803
16804   --Andrew Church
16805     achurch@achurch.org
16806     http://achurch.org/
16807
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>
16814
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?
16820
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.
16825
16826   --Andrew Church
16827     achurch@achurch.org
16828     http://achurch.org/
16829
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>
16836
16837 >Is there any tool (silly question) or something or guid to make a language
16838 >file.
16839 >
16840 >I have decided to make a Persian (Farsi) language file.
16841
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.
16846
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.
16849
16850   --Andrew Church
16851     achurch@achurch.org
16852     http://achurch.org/
16853
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>
16860
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
16864
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?
16867
16868   --Andrew Church
16869     achurch@achurch.org
16870     http://achurch.org/
16871
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>
16878
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.
16882
16883      This is a bug in the DROP function, and has been fixed; thanks for the
16884 report.
16885
16886   --Andrew Church
16887     achurch@achurch.org
16888     http://achurch.org/
16889
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>
16896
16897 >[Aug 30 10:56:18 2003] mail/sendmail:
16898 > /usr/sbin/sendmail exited with code 25600
16899
16900      Use the SMTP module instead (mail/smtp).
16901
16902 >[Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
16903 >registration (Simorgh)
16904 >
16905 >and how can I do so that nickserv dont show the realhost of a user in
16906 >'ns info nick all'
16907
16908      It doesn't.  However:
16909
16910 >[Aug 30 10:51:19 2003] unknown message from server
16911 >(:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
16912
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.
16916
16917   --Andrew Church
16918     achurch@achurch.org
16919     http://achurch.org/
16920
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>
16927
16928 >Or how about rather letting users decide what timezone they're in and
16929 >services outputs all timestamps in their local time?
16930
16931 /ns help set timezone (since 5.0 alpha)
16932
16933   --Andrew Church
16934     achurch@achurch.org
16935     http://achurch.org/
16936
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>
16944
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.
16952
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?
16960
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....
16967
16968 Saturn
16969 irc.jetirc.net
16970
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
16976
16977
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...
16980
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.
16984
16985   --Andrew Church
16986     achurch@achurch.org
16987     http://achurch.org/
16988
16989
16990
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>
16999
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.
17009
17010 Erm, what's the argument here?  Services stipulates its timezone in its
17011 timestamps.  As do all the other servers on the network.
17012
17013 Atleast mine do...
17014
17015
17016 Regards,
17017 Aragon
17018
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>
17027
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??
17032
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
17038 suggestion
17039
17040
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
17044 server
17045 > is in a different time zone -- How are users supposed to know what time
17046 zone
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.
17052
17053 Erm, what's the argument here?  Services stipulates its timezone in its
17054 timestamps.  As do all the other servers on the network.
17055
17056 Atleast mine do...
17057
17058
17059 Regards,
17060 Aragon
17061 ------------------------------------------------------------------
17062 To unsubscribe or change your subscription options, visit:
17063 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
17064
17065
17066
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>
17074
17075 On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
17076
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?
17081
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
17085 it back.
17086
17087 >   Why does it all have to be so complicated??
17088
17089 It isn't.  Your users can even use the handy-dandy /nickserv set
17090 timezone command to make it even easier.
17091
17092 > ----- Original Message -----
17093 > From: "Aragon Gouveia" <aragon@phat.za.net>
17094
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.
17105 >
17106 > Erm, what's the argument here?  Services stipulates its timezone in
17107 > its timestamps.  As do all the other servers on the network.
17108
17109 -- Quension
17110
17111
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>
17118
17119
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
17122 seconds ago)
17123 Time registered  : Jul 25 22:19:20 2003 GMT (** days, ** minutes and **
17124 seconds ago)
17125 wouldn't even a greater idea?
17126
17127 _________________________________________________________________
17128 Get MSN 8 and enjoy automatic e-mail virus protection.
17129 http://join.msn.com/?page=features/virus
17130
17131
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>
17139
17140 [16:41] -NickServ-   Time registered: Jul 27 13:09:08 2002 PDT
17141
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....
17150
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
17153 valid ones...
17154
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
17157 codes like PDT)...
17158
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
17165 suggestion
17166
17167
17168 On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
17169
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?
17174
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
17178 it back.
17179
17180 >   Why does it all have to be so complicated??
17181
17182 It isn't.  Your users can even use the handy-dandy /nickserv set
17183 timezone command to make it even easier.
17184
17185 > ----- Original Message -----
17186 > From: "Aragon Gouveia" <aragon@phat.za.net>
17187
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.
17198 >
17199 > Erm, what's the argument here?  Services stipulates its timezone in
17200 > its timestamps.  As do all the other servers on the network.
17201
17202 -- Quension
17203
17204 ------------------------------------------------------------------
17205 To unsubscribe or change your subscription options, visit:
17206 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
17207
17208
17209
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>
17217
17218 On Sunday, Aug 31, 2003, at 16:47 US/Pacific, Saturn wrote:
17219
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)...
17223
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.
17227
17228 -- Quension
17229
17230
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>
17238
17239      "Use /ns set timezone" is the official answer on this.  Please take
17240 all further discussion to the ircservices list.
17241
17242   --Andrew Church
17243     achurch@achurch.org
17244     http://achurch.org/
17245
17246 >[16:41] -NickServ-   Time registered: Jul 27 13:09:08 2002 PDT
17247 >
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....
17256 >
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
17259 >valid ones...
17260 >
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)...
17264 >
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
17271 >suggestion
17272 >
17273 >
17274 >On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
17275 >
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?
17280 >
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
17284 >it back.
17285 >
17286 >>   Why does it all have to be so complicated??
17287 >
17288 >It isn't.  Your users can even use the handy-dandy /nickserv set
17289 >timezone command to make it even easier.
17290 >
17291 >> ----- Original Message -----
17292 >> From: "Aragon Gouveia" <aragon@phat.za.net>
17293 >
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.
17304 >>
17305 >> Erm, what's the argument here?  Services stipulates its timezone in
17306 >> its timestamps.  As do all the other servers on the network.
17307 >
17308 >-- Quension
17309 >
17310 >------------------------------------------------------------------
17311 >To unsubscribe or change your subscription options, visit:
17312 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
17313 >
17314 >
17315 >------------------------------------------------------------------
17316 >To unsubscribe or change your subscription options, visit:
17317 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
17318
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>
17325
17326 Thanks for your help.
17327
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
17332            Is online from: %s
17333 to:
17334 NICK_INFO_ADDRESS_ONLINE
17335            Is online from: N/A ?
17336
17337
17338                            Ali "Simorgh"
17339  ______________________________________________________
17340  Many of life's failures are people who did not realize
17341  how close they were to success when they gave up.
17342  Thomas A. Edison
17343  ______________________________________________________
17344
17345
17346 On Mon, 1 Sep 2003, Andrew Church wrote:
17347
17348 > >[Aug 30 10:56:18 2003] mail/sendmail:
17349 > > /usr/sbin/sendmail exited with code 25600
17350 >
17351 >      Use the SMTP module instead (mail/smtp).
17352 >
17353 > >[Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
17354 > >registration (Simorgh)
17355 > >
17356 > >and how can I do so that nickserv dont show the realhost of a user in
17357 > >'ns info nick all'
17358 >
17359 >      It doesn't.  However:
17360 >
17361 > >[Aug 30 10:51:19 2003] unknown message from server
17362 > >(:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
17363 >
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.
17367 >
17368 >   --Andrew Church
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
17374 >
17375
17376
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>
17383
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
17386
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.
17391
17392   --Andrew Church
17393     achurch@achurch.org
17394     http://achurch.org/
17395
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>
17401
17402 Hi all,
17403
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.
17407
17408 Regards
17409
17410 alex
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>
17421
17422 Hello,
17423
17424 alex wrote:
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.
17428
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
17432 computer.
17433
17434 --
17435 Krisztian Romek
17436 r-krisztian@softhome.net
17437
17438
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>
17444
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.
17446
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.
17448
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  ****************************************/
17456
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  ****************************************/
17463
17464 /****** - Begin Original Message - ******/
17465
17466 >Hi all,
17467 >
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.
17471 >
17472 >Regards
17473 >
17474 >alex
17475 >------------------------------------------------------------------
17476 >To unsubscribe or change your subscription options, visit:
17477 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
17478
17479 /******* - End Original Message - *******/
17480
17481
17482
17483
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>
17489
17490 It wasn't an easy subject to sum up in just a few words.
17491
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
17504 send.c
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
17508 all the
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)
17520
17521 Thanks
17522
17523 Brent
17524
17525
17526
17527 ----------------------------------------------------------
17528 |               Brent DiNicola                                  |
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 -----------------------------------------------------------
17535
17536
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>
17542
17543 lol, Our help no good? :P
17544
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..
17546
17547 Dont ask me for source on this.. i'm just theorising :)
17548
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  ****************************************/
17556
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  ****************************************/
17563
17564 /****** - Begin Original Message - ******/
17565
17566 >It wasn't an easy subject to sum up in just a few words.
17567 >
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
17580 >send.c
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
17584 >all the
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)
17596 >
17597 >Thanks
17598 >
17599 >Brent
17600 >
17601 >
17602 >
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 >-----------------------------------------------------------
17611 >
17612 >------------------------------------------------------------------
17613 >To unsubscribe or change your subscription options, visit:
17614 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
17615 >.
17616
17617 /******* - End Original Message - *******/
17618
17619
17620
17621
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>
17629
17630 Hello;
17631
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.
17641
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.
17656 ...
17657
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.
17661
17662 To your case.
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.
17666
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
17669 trivial.
17670
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
17674 closed.
17675
17676 Do keep in mind that requesting support for modified services versions
17677 are subject to be ignored.
17678
17679 I hope it helps,
17680 yusuf
17681
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.
17684 >
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
17697 > send.c
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
17701 > all the
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)
17713 >
17714 > Thanks
17715 >
17716 > Brent
17717 >
17718 >
17719 >
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 > -----------------------------------------------------------
17728 >
17729 > ------------------------------------------------------------------
17730 > To unsubscribe or change your subscription options, visit:
17731 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
17732 --
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 ------------------------------------------------------------------
17739
17740
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>
17747
17748 Brent DiNicola wrote:
17749
17750 > It wasn't an easy subject to sum up in just a few words.
17751 >
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
17757 > the users
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
17760 > NOTICE
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
17763 > the best
17764 > way to go about this without causing trouble for me and anyone else
17765 > who has
17766 > to deal with this code. Is it possible or even suggested to make a
17767 > module that
17768 > would replace the notice() from send.c with it's own, leaving the code
17769 > in send.c
17770 > alone and not causing troubles down the road. Suggestions were that I
17771 > make a
17772 > module that kept the info for each nick's setting and then if I could
17773 > override
17774 > the notice() and notice_lang() and notice_help() in send.c that would
17775 > keep all the
17776 > other code clean and not cause other troubles. I want to know what the
17777 > best
17778 > way to do this would be, I know it's against RFC but I want to move to
17779 > newer
17780 > services than the 1.4.3pre4 that we are using now and add modules so
17781 > that I
17782 > can do things down the line. They are used to having PRIVMSG and I
17783 > can't just
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
17786 > this? I
17787 > know this topic has been asked before and I know your not going to
17788 > make it
17789 > part of your code, I just wanted to know from the people who know the
17790 > code
17791 > really well what the best route to take would be to do the least
17792 > amount of
17793 > damage. (And if someone has done this.. please let me know what you did,
17794 > examples would rock)
17795 >
17796 > Thanks
17797 >
17798 > Brent
17799 >
17800 >
17801 >
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
17813 >
17814 >
17815
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
17820
17821 services is the wrong thing to change
17822
17823
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>
17829
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
17831
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  ****************************************/
17839
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  ****************************************/
17846
17847 /****** - Begin Original Message - ******/
17848
17849 >Brent DiNicola wrote:
17850 >
17851 >> It wasn't an easy subject to sum up in just a few words.
17852 >>
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
17858 >> the users
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
17861 >> NOTICE
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
17864 >> the best
17865 >> way to go about this without causing trouble for me and anyone else
17866 >> who has
17867 >> to deal with this code. Is it possible or even suggested to make a
17868 >> module that
17869 >> would replace the notice() from send.c with it's own, leaving the code
17870 >> in send.c
17871 >> alone and not causing troubles down the road. Suggestions were that I
17872 >> make a
17873 >> module that kept the info for each nick's setting and then if I could
17874 >> override
17875 >> the notice() and notice_lang() and notice_help() in send.c that would
17876 >> keep all the
17877 >> other code clean and not cause other troubles. I want to know what the
17878 >> best
17879 >> way to do this would be, I know it's against RFC but I want to move to
17880 >> newer
17881 >> services than the 1.4.3pre4 that we are using now and add modules so
17882 >> that I
17883 >> can do things down the line. They are used to having PRIVMSG and I
17884 >> can't just
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
17887 >> this? I
17888 >> know this topic has been asked before and I know your not going to
17889 >> make it
17890 >> part of your code, I just wanted to know from the people who know the
17891 >> code
17892 >> really well what the best route to take would be to do the least
17893 >> amount of
17894 >> damage. (And if someone has done this.. please let me know what you did,
17895 >> examples would rock)
17896 >>
17897 >> Thanks
17898 >>
17899 >> Brent
17900 >>
17901 >>
17902 >>
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
17914 >>
17915 >>
17916 >
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
17921 >
17922 >services is the wrong thing to change
17923 >
17924 >------------------------------------------------------------------
17925 >To unsubscribe or change your subscription options, visit:
17926 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
17927 >.
17928
17929 /******* - End Original Message - *******/
17930
17931
17932
17933
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>
17940
17941 On Thursday, Sep 4, 2003, at 13:29 US/Pacific, Robert F Merrill wrote:
17942
17943 > Brent DiNicola wrote:
17944 >
17945 >> It wasn't an easy subject to sum up in just a few words.
17946
17947 [...]
17948
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
17953 >
17954 > services is the wrong thing to change
17955
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.
17959
17960 This is the coding list, not the feature request list.  He asked for
17961 code design approaches, not for political insight.
17962
17963 -- Quension
17964
17965
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>
17971
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
17977
17978 Thanks for all
17979
17980 Diego B. Contezini
17981
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..
17987
17988
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
17994 get
17995 > a core.
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
17998 break
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.
18003 >
18004 > Thanks for all
18005 >
18006 > Diego B. Contezini aka destruct_ | irc.redesul.net
18007 > (Sorry for my confuse english.)
18008 >
18009
18010
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>
18017
18018 Hello, im destruct_, im the administrator of the RedeSul Network.
18019 (irc.redesul.net).
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
18023 a core.
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.
18030
18031 Thanks for all
18032
18033 Diego B. Contezini aka destruct_ | irc.redesul.net
18034 (Sorry for my confuse english.)
18035
18036
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>
18042
18043 Hi All
18044
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
18056
18057 many thanks
18058 Engin
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>
18067
18068 make sure you are on the services administrator list, if you are not, get the root administrator to add you using the command:
18069
18070 [22:27] -OperServ- Syntax: ADMIN ADD nickname
18071 [22:27] -OperServ- ADMIN DEL nickname
18072 [22:27] -OperServ- ADMIN LIST
18073 [22:27] -OperServ-
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.
18078 [22:27] -OperServ-
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.
18081
18082
18083
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  ****************************************/
18091
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  ****************************************/
18098
18099 /****** - Begin Original Message - ******/
18100
18101 >Hi All
18102 >
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
18114 >
18115 >many thanks
18116 >Engin
18117 >------------------------------------------------------------------
18118 >To unsubscribe or change your subscription options, visit:
18119 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
18120
18121 /******* - End Original Message - *******/
18122
18123
18124
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>
18131
18132 Contact me directly... I have quite a bit of experience with unreal and these services...
18133
18134 Saturn
18135 irc.jetirc.net
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
18141
18142
18143   Hi All
18144
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
18156
18157   many thanks
18158   Engin
18159
18160
18161
18162 ------------------------------------------------------------------------------
18163
18164
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>
18177
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....
18180
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
18187
18188
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:
18191
18192 [22:27] -OperServ- Syntax: ADMIN ADD nickname
18193 [22:27] -OperServ- ADMIN DEL nickname
18194 [22:27] -OperServ- ADMIN LIST
18195 [22:27] -OperServ-
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.
18200 [22:27] -OperServ-
18201 [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
18202 command.
18203 [22:27] -OperServ- All other use limited to Services super-user.
18204
18205
18206
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  ****************************************/
18214
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  ****************************************/
18221
18222 /****** - Begin Original Message - ******/
18223
18224 >Hi All
18225 >
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
18237 >
18238 >many thanks
18239 >Engin
18240 >------------------------------------------------------------------
18241 >To unsubscribe or change your subscription options, visit:
18242 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
18243
18244 /******* - End Original Message - *******/
18245
18246
18247 ------------------------------------------------------------------
18248 To unsubscribe or change your subscription options, visit:
18249 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
18250
18251
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>
18258
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
18261 one
18262
18263 cheers
18264 Engin
18265
18266
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
18272
18273
18274 > Send IRCServices-Coding mailing list submissions to
18275 > ircservices-coding@ircservices.za.net
18276 >
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
18281 >
18282 > You can reach the person managing the list at
18283 > ircservices-coding-owner@ircservices.za.net
18284 >
18285 > When replying, please edit your Subject line so it is more specific
18286 > than "Re: Contents of IRCServices-Coding digest..."
18287 >
18288 >
18289 > Today's Topics:
18290 >
18291 >    1. operserv (engin@piratetv)
18292 >    2. Re: operserv (Craig McLure)
18293 >    3. Re: operserv (Saturn)
18294 >    4. Re: operserv (Saturn)
18295 >
18296 >
18297 > ----------------------------------------------------------------------
18298 >
18299 > Message: 1
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"
18306 >
18307 > Hi All
18308 >
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
18320 >
18321 > many thanks
18322 > Engin
18323 > -------------- next part --------------
18324 > An HTML attachment was scrubbed...
18325 > URL:
18326 http://snow.fingers.co.za/pipermail/ircservices-coding/attachments/20030921/
18327 fdc12b4e/attachment-0001.htm
18328 >
18329 > ------------------------------
18330 >
18331 > Message: 2
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"
18339 >
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:
18342 >
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
18348 nicknames
18349 > [22:27] -OperServ- to or from the Services admin list. A user whose
18350 nickname
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
18353 commands.
18354 > [22:27] -OperServ-
18355 > [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
18356 command.
18357 > [22:27] -OperServ- All other use limited to Services super-user.
18358 >
18359 >
18360 >
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 >  ****************************************/
18368 >
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 >  ****************************************/
18375 >
18376 > /****** - Begin Original Message - ******/
18377 >
18378 > >Hi All
18379 > >
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
18391 > >
18392 > >many thanks
18393 > >Engin
18394 > >------------------------------------------------------------------
18395 > >To unsubscribe or change your subscription options, visit:
18396 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
18397 >
18398 > /******* - End Original Message - *******/
18399 >
18400 >
18401 >
18402 > ------------------------------
18403 >
18404 > Message: 3
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"
18412 >
18413 > Contact me directly... I have quite a bit of experience with unreal and
18414 these services...
18415 >
18416 > Saturn
18417 > irc.jetirc.net
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
18423 >
18424 >
18425 >   Hi All
18426 >
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
18429 mailing
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
18439 >
18440 >   many thanks
18441 >   Engin
18442 >
18443 >
18444 >
18445 > --------------------------------------------------------------------------
18446 ----
18447 >
18448 >
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...
18454 > URL:
18455 http://snow.fingers.co.za/pipermail/ircservices-coding/attachments/20030921/
18456 ca188e06/attachment-0001.htm
18457 >
18458 > ------------------------------
18459 >
18460 > Message: 4
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"
18468 >
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
18471 denied....
18472 >
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
18479 >
18480 >
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:
18483 >
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
18489 nicknames
18490 > [22:27] -OperServ- to or from the Services admin list. A user whose
18491 nickname
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
18494 commands.
18495 > [22:27] -OperServ-
18496 > [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
18497 > command.
18498 > [22:27] -OperServ- All other use limited to Services super-user.
18499 >
18500 >
18501 >
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 >  ****************************************/
18509 >
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 >  ****************************************/
18516 >
18517 > /****** - Begin Original Message - ******/
18518 >
18519 > >Hi All
18520 > >
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
18532 > >
18533 > >many thanks
18534 > >Engin
18535 > >------------------------------------------------------------------
18536 > >To unsubscribe or change your subscription options, visit:
18537 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
18538 >
18539 > /******* - End Original Message - *******/
18540 >
18541 >
18542 > ------------------------------------------------------------------
18543 > To unsubscribe or change your subscription options, visit:
18544 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
18545 >
18546 >
18547 > ------------------------------
18548 >
18549 > _______________________________________________
18550 > IRCServices-Coding mailing list
18551 > IRCServices-Coding@ircservices.za.net
18552 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
18553 >
18554 >
18555 > End of IRCServices-Coding Digest, Vol 8, Issue 5
18556 > ************************************************
18557
18558
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>
18566
18567 Sometimes has occur this bug, last 1 year....
18568 on a network with 30k registers, its happening with latency of 3.. 4
18569 days....
18570
18571 someone have any idea?
18572
18573 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
18574 av=0xbfffeec8) at channels.c:278
18575 278         while (*s) {
18576 (gdb) bt'
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>
18581         add = 1
18582         modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
18583 #1  0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:680
18584         buf =
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
18596 bounds>,
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@`???"}
18600         len = 4
18601         i = 0
18602         lastc = 45 '-'
18603 #2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
18604         args = 0x0
18605         modes = 0x0
18606         modes_orig = 0x0
18607         md = (struct modedata *) 0x0
18608         which = -1
18609         add = 0
18610         i = 0
18611         c = 0 '\0'
18612 #3  0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at main.c:269
18613         now = 1065393142
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.
18619 (gdb)
18620
18621
18622
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>
18629
18630 Upgrade.
18631
18632   --Andrew Church
18633     achurch@achurch.org
18634     http://achurch.org/
18635
18636 >Sometimes has occur this bug, last 1 year....
18637 >on a network with 30k registers, its happening with latency of 3.. 4
18638 >days....
18639 >
18640 >someone have any idea?
18641 >
18642 >#0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
18643 >av=0xbfffeec8) at channels.c:278
18644 >278         while (*s) {
18645 >(gdb) bt'
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>
18650 >        add = 1
18651 >        modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
18652 >#1  0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:68
18653 >0
18654 >        buf =
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ï¿½ï¿½ï¿½ï¿
18658 >½
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\
18663 >000\000\0
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�
18669 >���\027\000\0
18670 >00\000\000\000\000\000\024\032"...
18671 >        s = 0xbfffeef0 "-isl"
18672 >        argv = {0xa97b6c0 "#young", 0x20656c62 <Address 0x20656c62 out
18673 >of
18674 >bounds>,
18675 >  0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 o
18676 >ut
18677 >of bounds>, 0x42133cec "\004", 0xbffff1fc "",
18678 >  0x4204533d "\201���\016", 0x42131a14 " \031\023
18679 >B�h\001@`�"}
18680 >        len = 4
18681 >        i = 0
18682 >        lastc = 45 '-'
18683 >#2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:32
18684 >1
18685 >        args = 0x0
18686 >        modes = 0x0
18687 >        modes_orig = 0x0
18688 >        md = (struct modedata *) 0x0
18689 >        which = -1
18690 >        add = 0
18691 >        i = 0
18692 >        c = 0 '\0'
18693 >#3  0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at ma
18694 >in.c:269
18695 >        now = 1065393142
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.
18701 >(gdb)
18702 >
18703 >
18704 >------------------------------------------------------------------
18705 >To unsubscribe or change your subscription options, visit:
18706 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
18707
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>
18714
18715 Upgrade?
18716 ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
18717 18:41:36 BRT 2003
18718 -
18719
18720 Its the last version.......
18721
18722 Diego B. Contezini
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....
18728
18729
18730 > Upgrade.
18731 >
18732 >   --Andrew Church
18733 >     achurch@achurch.org
18734 >     http://achurch.org/
18735 >
18736 > >Sometimes has occur this bug, last 1 year....
18737 > >on a network with 30k registers, its happening with latency of 3.. 4
18738 > >days....
18739 > >
18740 > >someone have any idea?
18741 > >
18742 > >#0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
18743 > >av=0xbfffeec8) at channels.c:278
18744 > >278         while (*s) {
18745 > >(gdb) bt'
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>
18750 > >        add = 1
18751 > >        modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
18752 > >#1  0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:68
18753 > >0
18754 > >        buf =
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???????????
18758 > >?
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\
18763 > >000\000\0
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
18773 > >of
18774 > >bounds>,
18775 > >  0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 o
18776 > >ut
18777 > >of bounds>, 0x42133cec "\004", 0xbffff1fc "",
18778 > >  0x4204533d "\201?????????\016", 0x42131a14 " \031\023
18779 > >B???h\001@`???"}
18780 > >        len = 4
18781 > >        i = 0
18782 > >        lastc = 45 '-'
18783 > >#2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:32
18784 > >1
18785 > >        args = 0x0
18786 > >        modes = 0x0
18787 > >        modes_orig = 0x0
18788 > >        md = (struct modedata *) 0x0
18789 > >        which = -1
18790 > >        add = 0
18791 > >        i = 0
18792 > >        c = 0 '\0'
18793 > >#3  0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at ma
18794 > >in.c:269
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.
18801 > >(gdb)
18802 > >
18803 > >
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
18810 >
18811
18812
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>
18819
18820 >Upgrade?
18821 >ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
18822 >18:41:36 BRT 2003
18823 >-
18824 >
18825 >Its the last version.......
18826
18827      Then send a full debug log (from startup to crash), or I can't help.
18828
18829   --Andrew Church
18830     achurch@achurch.org
18831     http://achurch.org/
18832
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>
18839
18840 And how should be this log? i sent a backtrace......
18841
18842 Diego B. Contezini
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....
18848
18849
18850 > >Upgrade?
18851 > >ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
18852 > >18:41:36 BRT 2003
18853 > >-
18854 > >
18855 > >Its the last version.......
18856 >
18857 >      Then send a full debug log (from startup to crash), or I can't help.
18858 >
18859 >   --Andrew Church
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
18865 >
18866
18867
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>
18874
18875 >And how should be this log? i sent a backtrace......
18876
18877 RTFM (FAQ Z.3)
18878
18879   --Andrew Church
18880     achurch@achurch.org
18881     http://achurch.org/
18882
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>
18889
18890 Read....
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
18893 nofork.....
18894
18895 Cya
18896 Diego B. Contezini
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....
18902
18903
18904 > >And how should be this log? i sent a backtrace......
18905 >
18906 > RTFM (FAQ Z.3)
18907 >
18908 >   --Andrew Church
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
18914 >
18915
18916
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>
18923
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).
18926
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...
18933
18934 First: IS that what it's supposed to do?
18935
18936 Second: If so, it's not working...
18937
18938 Saturn
18939 www.jetirc.net
18940
18941
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>
18948
18949
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.
18953
18954 I copy the sintaz of mail-auth ( it's in italian )
18955
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:
18964             /msg %s AUTH %09d
18965
18966         La registrazione del tuo nick sara' confermata e il tuo nickname
18967         sara' protetto da eventuali tentativi di abuso o furto.
18968
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.
18972
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.
18976
18977
18978         Sono inoltre disponibili i seguenti servizi:
18979
18980         - MusiChat Forum
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.
18986
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.
18992
18993
18994         Per una connessione piu' veloce e sicura e' vivamente
18995         consigliato l'utilizzo del seguente server: irc.musichat.net
18996
18997         MusiChat Net Community
18998
18999         Questo messaggio e stato inviato su richiesta di %s in risposta a %s
19000         %s@%s.
19001
19002
19003
19004
19005 I read the istruction for translate.
19006
19007 The error is:
19008
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
19012
19013
19014 Some one can help me?
19015 the email body is too long?
19016
19017 Thx
19018
19019 Alex
19020
19021
19022
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>
19029
19030      You have the wrong number of %-tokens in your message.
19031
19032   --Andrew Church
19033     achurch@achurch.org
19034     http://achurch.org/
19035
19036 >
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.
19040 >
19041 >I copy the sintaz of mail-auth ( it's in italian )
19042 >
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
19052 >
19053 >        La registrazione del tuo nick sara' confermata e il tuo nickname
19054 >        sara' protetto da eventuali tentativi di abuso o furto.
19055 >
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.
19059 >
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.
19063 >
19064 >
19065 >        Sono inoltre disponibili i seguenti servizi:
19066 >
19067 >        - MusiChat Forum
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.
19073 >
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.
19079 >
19080 >
19081 >        Per una connessione piu' veloce e sicura e' vivamente
19082 >        consigliato l'utilizzo del seguente server: irc.musichat.net
19083 >
19084 >        MusiChat Net Community
19085 >
19086 >        Questo messaggio e stato inviato su richiesta di %s in risposta a %s
19087 >        %s@%s.
19088 >
19089 >
19090 >
19091 >
19092 >I read the istruction for translate.
19093 >
19094 >The error is:
19095 >
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
19099 >
19100 >
19101 >Some one can help me?
19102 >the email body is too long?
19103 >
19104 >Thx
19105 >
19106 >Alex
19107 >
19108 >
19109 >------------------------------------------------------------------
19110 >To unsubscribe or change your subscription options, visit:
19111 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
19112
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>
19118
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 ?
19127
19128 ######################################################
19129 modules/chanserv/check.c
19130 ...
19131 void check_chan_user_modes(const char *source, struct c_userlist *u,
19132                            Channel *c, int32 oldmodes)
19133 ...
19134         if ((res & ~modes) & CUMODE_o) {
19135             ci->last_used = time(NULL);
19136             put_channelinfo(ci);
19137         }
19138 ...
19139 ######################################################
19140
19141 |SaMaN|
19142
19143
19144
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>
19150
19151 Also it does not update last_used time on +a flag.
19152
19153 Temporary fix
19154 ---------------
19155
19156 edit /modules/chanserv/check.c
19157
19158 find line
19159 -------------------------------------------------------------------------
19160         local_set_cumodes(c, '+', res & ~modes, user->nick);
19161 -------------------------------------------------------------------------
19162 add below
19163 ------------------------------------------------------------------------
19164         int16 cumode_q = mode_char_to_flag('q',MODE_CHANUSER);
19165         int16 cumode_a = mode_char_to_flag('a',MODE_CHANUSER);
19166
19167         if ((res & ~modes) & cumode_q) {
19168             ci->last_used = time(NULL);
19169             put_channelinfo(ci);
19170         }
19171
19172         if ((res & ~modes) & cumode_a) {
19173             ci->last_used = time(NULL);
19174             put_channelinfo(ci);
19175         }
19176 -------------------------------------------------------------------------
19177 save and compile and run and enjoy :)
19178 -------------------------------------------------------------------------
19179
19180 |SaMaN|
19181
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 ?
19187
19188
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
19193 mode:
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
19196 to
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 ?
19199 >
19200 > ######################################################
19201 > modules/chanserv/check.c
19202 > ...
19203 > void check_chan_user_modes(const char *source, struct c_userlist *u,
19204 >                            Channel *c, int32 oldmodes)
19205 > ...
19206 >         if ((res & ~modes) & CUMODE_o) {
19207 >             ci->last_used = time(NULL);
19208 >             put_channelinfo(ci);
19209 >         }
19210 > ...
19211 > ######################################################
19212 >
19213 > |SaMaN|
19214 >
19215 >
19216
19217
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>
19223
19224 Haven't seen a reply to this one, so thought I'd better make sure this went
19225 through....
19226
19227 ----- Original Message -----
19228 Sent: Friday, October 10, 2003 3:48 PM
19229 Subject: Akill problem in 5.0.22
19230
19231
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).
19234
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...
19241
19242 First: IS that what it's supposed to do?
19243
19244 Second: If so, it's not working...
19245
19246 Saturn
19247 www.jetirc.net
19248
19249
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>
19256
19257 RTFM
19258
19259   --Andrew Church
19260     achurch@achurch.org
19261     http://achurch.org/
19262
19263 >Haven't seen a reply to this one, so thought I'd better make sure this went
19264 >through....
19265 >
19266 >----- Original Message -----
19267 >Sent: Friday, October 10, 2003 3:48 PM
19268 >Subject: Akill problem in 5.0.22
19269 >
19270 >
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).
19273 >
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...
19280 >
19281 >First: IS that what it's supposed to do?
19282 >
19283 >Second: If so, it's not working...
19284 >
19285 >Saturn
19286 >www.jetirc.net
19287 >
19288 >------------------------------------------------------------------
19289 >To unsubscribe or change your subscription options, visit:
19290 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
19291
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>
19298
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
19301
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
19305 it first.
19306     Example: ImmediatelySendAutokill
19307
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
19313 kill them.
19314
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?
19319
19320 Thanks
19321 Saturn
19322
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
19328
19329
19330 RTFM
19331
19332   --Andrew Church
19333     achurch@achurch.org
19334     http://achurch.org/
19335
19336 >Haven't seen a reply to this one, so thought I'd better make sure this went
19337 >through....
19338 >
19339 >----- Original Message -----
19340 >Sent: Friday, October 10, 2003 3:48 PM
19341 >Subject: Akill problem in 5.0.22
19342 >
19343 >
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).
19346 >
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
19349 scanning
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...
19354 >
19355 >First: IS that what it's supposed to do?
19356 >
19357 >Second: If so, it's not working...
19358 >
19359 >Saturn
19360 >www.jetirc.net
19361 >
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
19368
19369
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>
19376
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
19381 >kill them.
19382
19383      The documentation says nothing about this.  RTFM again.
19384
19385   --Andrew Church
19386     achurch@achurch.org
19387     http://achurch.org/
19388
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>
19396
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
19402 to deal with it.
19403
19404 Ballsy
19405
19406
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
19410 >
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
19414 >it first.
19415 >     Example: ImmediatelySendAutokill
19416 >
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
19422 >kill them.
19423 >
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?
19428 >
19429 >Thanks
19430 >Saturn
19431 >
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
19437 >
19438 >
19439 >RTFM
19440 >
19441 >   --Andrew Church
19442 >     achurch@achurch.org
19443 >     http://achurch.org/
19444 >
19445 > >Haven't seen a reply to this one, so thought I'd better make sure this went
19446 > >through....
19447 > >
19448 > >----- Original Message -----
19449 > >Sent: Friday, October 10, 2003 3:48 PM
19450 > >Subject: Akill problem in 5.0.22
19451 > >
19452 > >
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).
19455 > >
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
19458 >scanning
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...
19463 > >
19464 > >First: IS that what it's supposed to do?
19465 > >
19466 > >Second: If so, it's not working...
19467 > >
19468 > >Saturn
19469 > >www.jetirc.net
19470 > >
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
19477 >
19478 >------------------------------------------------------------------
19479 >To unsubscribe or change your subscription options, visit:
19480 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
19481
19482
19483
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>
19490
19491 >From a.html in the /docs directory:
19492 ---------------
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
19497 it first.
19498     Example: ImmediatelySendAutokill
19499 --------------
19500
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 ------------------------
19515
19516 4.html#oper.akill doesn't mention it at all.
19517
19518 -----------------
19519
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!!!
19527
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?
19533
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???????
19540
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.
19550
19551 Saturn
19552
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
19558
19559
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
19564 >kill them.
19565
19566      The documentation says nothing about this.  RTFM again.
19567
19568   --Andrew Church
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
19574
19575
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>
19583
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.
19591
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
19598 programming...
19599
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
19607
19608
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
19614 to deal with it.
19615
19616 Ballsy
19617
19618
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
19622 >
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
19626 >it first.
19627 >     Example: ImmediatelySendAutokill
19628 >
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
19634 >kill them.
19635 >
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?
19640 >
19641 >Thanks
19642 >Saturn
19643 >
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
19649 >
19650 >
19651 >RTFM
19652 >
19653 >   --Andrew Church
19654 >     achurch@achurch.org
19655 >     http://achurch.org/
19656 >
19657 > >Haven't seen a reply to this one, so thought I'd better make sure this
19658 went
19659 > >through....
19660 > >
19661 > >----- Original Message -----
19662 > >Sent: Friday, October 10, 2003 3:48 PM
19663 > >Subject: Akill problem in 5.0.22
19664 > >
19665 > >
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).
19668 > >
19669 > >I just today added an akill (+0 time) .. I DO have the immediate auto
19670 kill
19671 > >option un-commented in the modules.conf, but it still didn't bother
19672 >scanning
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
19675 thought
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...
19678 > >
19679 > >First: IS that what it's supposed to do?
19680 > >
19681 > >Second: If so, it's not working...
19682 > >
19683 > >Saturn
19684 > >www.jetirc.net
19685 > >
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
19692 >
19693 >------------------------------------------------------------------
19694 >To unsubscribe or change your subscription options, visit:
19695 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
19696
19697
19698 ------------------------------------------------------------------
19699 To unsubscribe or change your subscription options, visit:
19700 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
19701
19702
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>
19708
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.
19710
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
19712
19713 Please just calm down, and talk this out rationally before you start jumping down ppls throats :p
19714
19715 /*****************************************
19716  *     Craig "FrostyCoolSlug" McLure
19717  * InspIRCd   - http://www.inspircd.org
19718  * ChatSpike  - http://www.chatspike.net
19719  ****************************************/
19720
19721
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  ****************************************/
19728
19729 /****** - Begin Original Message - ******/
19730
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.
19738 >
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
19745 >programming...
19746 >
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
19754 >
19755 >
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
19761 >to deal with it.
19762 >
19763 >Ballsy
19764 >
19765 >
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
19769 >>
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
19773 >>it first.
19774 >>     Example: ImmediatelySendAutokill
19775 >>
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
19781 >>kill them.
19782 >>
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?
19787 >>
19788 >>Thanks
19789 >>Saturn
19790 >>
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
19796 >>
19797 >>
19798 >>RTFM
19799 >>
19800 >>   --Andrew Church
19801 >>     achurch@achurch.org
19802 >>     http://achurch.org/
19803 >>
19804 >> >Haven't seen a reply to this one, so thought I'd better make sure this
19805 >went
19806 >> >through....
19807 >> >
19808 >> >----- Original Message -----
19809 >> >Sent: Friday, October 10, 2003 3:48 PM
19810 >> >Subject: Akill problem in 5.0.22
19811 >> >
19812 >> >
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).
19815 >> >
19816 >> >I just today added an akill (+0 time) .. I DO have the immediate auto
19817 >kill
19818 >> >option un-commented in the modules.conf, but it still didn't bother
19819 >>scanning
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
19822 >thought
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...
19825 >> >
19826 >> >First: IS that what it's supposed to do?
19827 >> >
19828 >> >Second: If so, it's not working...
19829 >> >
19830 >> >Saturn
19831 >> >www.jetirc.net
19832 >> >
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
19839 >>
19840 >>------------------------------------------------------------------
19841 >>To unsubscribe or change your subscription options, visit:
19842 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
19843 >
19844 >
19845 >------------------------------------------------------------------
19846 >To unsubscribe or change your subscription options, visit:
19847 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
19848 >
19849 >------------------------------------------------------------------
19850 >To unsubscribe or change your subscription options, visit:
19851 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
19852 >
19853 >.
19854
19855 /******* - End Original Message - *******/
19856
19857
19858
19859
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>
19866
19867      You know, I might have been more forgiving if this hadn't been gone
19868 over on this list (twice!) before:
19869
19870 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/002305.html
19871 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/003215.html
19872
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
19875 edification:
19876
19877 F.10. Services doesn't kill users matching a newly-added autokill mask even
19878 if ImmediatelySendAutokill is set.
19879
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.
19886
19887         Note that some IRC servers will themselves kill users matching a
19888         newly-added autokill; this is unrelated to Services.
19889
19890   --Andrew Church
19891     achurch@achurch.org
19892     http://achurch.org/
19893
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>
19903
19904 Saturn wrote:
19905
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.
19913 >
19914 >
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
19921 do this.
19922
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).
19927
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.
19931
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.
19939
19940
19941
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>
19950
19951 On Saturday 18 October 2003 07:20, Robert F Merrill wrote:
19952 > Saturn 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.
19960 >
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
19967 > do this.
19968
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.
19971
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.
19976
19977 <<V13>>
19978
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>
19985
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)
19996
19997 root@irc(/home/ircadmin/services/lib)# ls -la core.12631
19998 -rw-------    1 ircadmin ircadmin 47374336 Oct 18 16:05 core.12631
19999
20000
20001 continue on the next message......
20002
20003
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>
20010
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;
20015 (gdb) bt'
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
20019         s = 0x806aa3e ""
20020 #1  0x0804d342 in set_cmode (sender=0x81db058 "ChanServ", channel=0xa905d00)
20021 at actions.c:446
20022         parambuf =
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"...
20031         len = 10
20032         flag = 1
20033         params = 1
20034         is_chanuser = 1
20035         args = 0xbfffe6d0 "RDcoCOREcorei??i??i??i??o"
20036         modes = 0xbfffeae2 ""
20037         modes_orig = 0xbfffeae0 "+o"
20038         md = (struct modedata *) 0x806aa00
20039         which = 0
20040         add = 1
20041         i = 1
20042         c = 111 'o'
20043 #2  0x400895ff in local_set_cumodes (c=0xa905d00, plusminus=43 '+', modes=1,
20044 nick=0xab7f2e8 "balsanelli") at check.c:432
20045         buf = "+o"
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).."...
20050         s = 0xbfffe6e1 ""
20051 #3  0x40088d74 in check_chan_user_modes (source=0xbfffeed0 "|-Frango-|",
20052 u=0xab34ff0, c=0xa905d00, oldmodes=1)
20053     at check.c:214
20054         user = (User *) 0xab7f2d8
20055         ci = (ChannelInfo *) 0xa571940
20056         modes = 0
20057         is_servermode = 0
20058         res = 1
20059 #4  0x400820ed in do_channel_umode_change (source=0xbfffeed0 "|-Frango-|",
20060 c=0xa905d00, u=0xab34ff0, oldmodes=1)
20061     at main.c:354
20062 No locals.
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
20067         res = 0
20068         i = 0
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---
20072     at channels.c:409
20073         u = (struct c_userlist *) 0xab34ff0
20074         user = (User *) 0xab7f2d8
20075         oldmode = 1
20076 #7  0x0804e97e in do_cmode (source=0xbfffeed0 "|-Frango-|", ac=0,
20077 av=0xa853130) at channels.c:302
20078         modechar = 111 'o'
20079         flag = 1
20080         params = -1073746288
20081         chan = (Channel *) 0xa905d00
20082         s = 0xbfffeca5 ""
20083         add = 0
20084         modestr = 0xbfffec9e "-oooooo"
20085 #8  0x080557ff in m_mode (source=0xbfffeed0 "|-Frango-|", ac=8,
20086 av=0xa853110) at messages.c:101
20087 No locals.
20088 #9  0x0805920e in process () at process.c:133
20089         m = (Message *) 0x8067dd8
20090         source =
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
20093 5\b"
20094         cmd =
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"
20098         buf =
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"
20106         ac = 8
20107         av = (char **) 0xa853110
20108 #10 0x0805507d in readline_callback (s=0xa851ae0, param_unused=0x50) at
20109 main.c:177
20110 No locals.
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."...
20116         left = 80
20117         newleft = 80
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}
20121         i = 4
20122         res = 260
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---
20127         now = 1066500331
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.
20133 (gdb)
20134
20135
20136
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>
20143
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.
20151
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?
20165
20166 Thank you all for your time.
20167
20168 Saturn
20169
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
20175
20176
20177      You know, I might have been more forgiving if this hadn't been gone
20178 over on this list (twice!) before:
20179
20180 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/002305.html
20181 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/003215.html
20182
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
20185 edification:
20186
20187 F.10. Services doesn't kill users matching a newly-added autokill mask even
20188 if ImmediatelySendAutokill is set.
20189
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.
20196
20197 Note that some IRC servers will themselves kill users matching a
20198 newly-added autokill; this is unrelated to Services.
20199
20200   --Andrew Church
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
20206
20207
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>
20213
20214 If it helps, more lines up.. of debugging...
20215
20216
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)
20229
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>
20241
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.
20247
20248 Ballsy
20249
20250
20251 At 12:49 PM 18/10/2003, V13 wrote:
20252 >On Saturday 18 October 2003 07:20, Robert F Merrill wrote:
20253 > > Saturn 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.
20261 > >
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
20268 > > do this.
20269 >
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.
20272 >
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.
20277 >
20278 ><<V13>>
20279 >------------------------------------------------------------------
20280 >To unsubscribe or change your subscription options, visit:
20281 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
20282
20283
20284
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>
20290
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>
20298
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
20301
20302 ciao
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>
20312
20313 Andrew, have anything more of dumping/debugging that i can do/give for helps
20314 fixing this bug..?
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)....
20317 anything more?
20318
20319
20320 Thanks for all
20321
20322
20323 Diego B. Contezini
20324
20325
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>
20331
20332
20333
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>
20339
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
20342 18:41:36 BRT 2003)
20343 yes, 5.0.23 is the last.. but nothing has changed about the bug...
20344
20345  here is the debugging:
20346
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
20351 #Euevc
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
20359 +stmipl 1
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)
20371
20372
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;
20378 (gdb) bt'
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
20382         s = 0x806aa3e ""
20383 #1  0x0804d342 in set_cmode (sender=0x81db058 "ChanServ", channel=0xa905d00)
20384 at actions.c:446
20385         parambuf =
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"...
20394         len = 10
20395         flag = 1
20396         params = 1
20397         is_chanuser = 1
20398         args = 0xbfffe6d0 "RDcoCOREcorei??i??i??i??o"
20399         modes = 0xbfffeae2 ""
20400         modes_orig = 0xbfffeae0 "+o"
20401         md = (struct modedata *) 0x806aa00
20402         which = 0
20403         add = 1
20404         i = 1
20405         c = 111 'o'
20406 #2  0x400895ff in local_set_cumodes (c=0xa905d00, plusminus=43 '+', modes=1,
20407 nick=0xab7f2e8 "balsanelli") at check.c:432
20408         buf = "+o"
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).."...
20413         s = 0xbfffe6e1 ""
20414 #3  0x40088d74 in check_chan_user_modes (source=0xbfffeed0 "|-Frango-|",
20415 u=0xab34ff0, c=0xa905d00, oldmodes=1)
20416     at check.c:214
20417         user = (User *) 0xab7f2d8
20418         ci = (ChannelInfo *) 0xa571940
20419         modes = 0
20420         is_servermode = 0
20421         res = 1
20422 #4  0x400820ed in do_channel_umode_change (source=0xbfffeed0 "|-Frango-|",
20423 c=0xa905d00, u=0xab34ff0, oldmodes=1)
20424     at main.c:354
20425 No locals.
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
20430         res = 0
20431         i = 0
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---
20435     at channels.c:409
20436         u = (struct c_userlist *) 0xab34ff0
20437         user = (User *) 0xab7f2d8
20438         oldmode = 1
20439 #7  0x0804e97e in do_cmode (source=0xbfffeed0 "|-Frango-|", ac=0,
20440 av=0xa853130) at channels.c:302
20441         modechar = 111 'o'
20442         flag = 1
20443         params = -1073746288
20444         chan = (Channel *) 0xa905d00
20445         s = 0xbfffeca5 ""
20446         add = 0
20447         modestr = 0xbfffec9e "-oooooo"
20448 #8  0x080557ff in m_mode (source=0xbfffeed0 "|-Frango-|", ac=8,
20449 av=0xa853110) at messages.c:101
20450 No locals.
20451 #9  0x0805920e in process () at process.c:133
20452         m = (Message *) 0x8067dd8
20453         source =
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
20456 5\b"
20457         cmd =
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"
20461         buf =
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"
20469         ac = 8
20470         av = (char **) 0xa853110
20471 #10 0x0805507d in readline_callback (s=0xa851ae0, param_unused=0x50) at
20472 main.c:177
20473 No locals.
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."...
20479         left = 80
20480         newleft = 80
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}
20484         i = 4
20485         res = 260
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---
20490         now = 1066500331
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
20507 cs             0x23     35
20508 ss             0x2b     43
20509 ds             0x2b     43
20510 es             0x2b     43
20511 fs             0x0      0
20512 gs             0x33     51
20513 (gdb)
20514
20515
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
20528 ...
20529 model name      : Pentium III (Coppermine)
20530 stepping        : 10
20531 cpu MHz         : 999.752
20532 cache size      : 256 KB
20533 ...
20534 root@irc(/home/ircadmin/services)# free
20535              total       used       free     shared    buffers     cached
20536 Mem:        513792     482248      31544          0      69492     274980
20537
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*
20547
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
20559
20560
20561 If it helps, here is the debugging of the last two cores, on gdb:
20562 ----------------
20563 FIRST:
20564 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
20565 av=0xbfffdc38)
20566     at channels.c:278
20567 278         while (*s) {
20568 (gdb) bt'
20569 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
20570 av=0xbfffdc38)
20571     at channels.c:278
20572         chan = (Channel *) 0xa87d1e0
20573         s = 0x1f73746f <Address 0x1f73746f out of bounds>
20574         add = 1
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
20584 \006\b"...
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>}
20594         len = 5
20595 ---Type <return> to continue, or q <return> to quit---
20596         i = 0
20597         lastc = 45 '-'
20598 #2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
20599         args = 0x0
20600         modes = 0x0
20601         modes_orig = 0x0
20602         md = (struct modedata *) 0x0
20603         which = -1
20604         add = 0
20605         i = 0
20606         c = 0 '\0'
20607 #3  0x080553a3 in main (ac=1, av=0xbfffe574, envp=0xbfffe57c) at main.c:269
20608         now = 1067891066
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.
20614 -----------
20615
20616 SECOND:
20617 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
20618 av=0xbffff2b8)
20619     at channels.c:278
20620 278         while (*s) {
20621 (gdb) bt'
20622 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
20623 av=0xbffff2b8)
20624     at channels.c:278
20625         chan = (Channel *) 0xa9be840
20626         s = 0xbf000000 <Address 0xbf000000 out of bounds>
20627         add = 1
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>}
20644         len = 5
20645         i = 0
20646         lastc = 45 '-'
20647 #2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
20648 ---Type <return> to continue, or q <return> to quit---
20649         args = 0x0
20650         modes = 0x0
20651         modes_orig = 0x0
20652         md = (struct modedata *) 0x0
20653         which = -1
20654         add = 0
20655         i = 0
20656         c = 0 '\0'
20657 #3  0x080553a3 in main (ac=1, av=0xbffffbf4, envp=0xbffffbfc) at main.c:269
20658         now = 1067706795
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.
20664 (gdb)
20665 -------
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
20668 this bug...
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
20672 anything....
20673
20674 Thanks for all development, this is really a bealtifull software...
20675 (and sorry for my bad english)
20676
20677 Diego B. Contezini aka destruct_ #irc.redesul.net
20678
20679
20680
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>
20686
20687 If it helps, im using Bahamut here....
20688
20689
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>
20696
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 ?
20705
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.
20715
20716   --Andrew Church
20717     achurch@achurch.org
20718     http://achurch.org/
20719
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>
20725
20726
20727
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>
20733
20734 Hi,
20735
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:
20739
20740 ***************************
20741 -
20742 -NickServ- nick is hello world
20743 -
20744 -NickServ- Is online from: ~test@just.a.test.co.za
20745 -
20746 -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
20747 -
20748 -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
20749 -
20750 -NickServ- Last quit message: anythinggggg
20751 -
20752 -NickServ- Options: Kill protection, Security
20753 -
20754 ***************************
20755
20756 the new line I'm suggesting is something like:
20757
20758 ***************************
20759 -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
20760 ***************************
20761
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).
20767
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)
20771
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)
20774
20775 Many thanks to all of who developed IRCservices ...etc ...etc ...etc
20776
20777 sincerely,
20778 David
20779
20780 _________________________________________________________________
20781 Get MSN 8 and enjoy automatic e-mail virus protection.
20782 http://join.msn.com/?page=features/virus
20783
20784
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>
20792
20793 Or how about rather letting users decide what timezone they're in and
20794 services outputs all timestamps in their local time?
20795
20796
20797 | By us44ever . <us44ever@hotmail.com>
20798 |                                          [ 2003-08-28 18:45 +0200 ]
20799 > Hi,
20800 >
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:
20804 >
20805 > ***************************
20806 > -
20807 > -NickServ- nick is hello world
20808 > -
20809 > -NickServ- Is online from: ~test@just.a.test.co.za
20810 > -
20811 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
20812 > -
20813 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
20814 > -
20815 > -NickServ- Last quit message: anythinggggg
20816 > -
20817 > -NickServ- Options: Kill protection, Security
20818 > -
20819 > ***************************
20820 >
20821 > the new line I'm suggesting is something like:
20822 >
20823 > ***************************
20824 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
20825 > ***************************
20826 >
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).
20832 >
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)
20836 >
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)
20839 >
20840 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
20841 >
20842 > sincerely,
20843 > David
20844 >
20845 > _________________________________________________________________
20846 > Get MSN 8 and enjoy automatic e-mail virus protection.
20847 > http://join.msn.com/?page=features/virus
20848 >
20849 > ------------------------------------------------------------------
20850 > To unsubscribe or change your subscription options, visit:
20851 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
20852
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>
20860
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
20868
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
20874
20875
20876 Or how about rather letting users decide what timezone they're in and
20877 services outputs all timestamps in their local time?
20878
20879
20880 | By us44ever . <us44ever@hotmail.com>
20881 |                                          [ 2003-08-28 18:45 +0200 ]
20882 > Hi,
20883 >
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:
20887 >
20888 > ***************************
20889 > -
20890 > -NickServ- nick is hello world
20891 > -
20892 > -NickServ- Is online from: ~test@just.a.test.co.za
20893 > -
20894 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
20895 > -
20896 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
20897 > -
20898 > -NickServ- Last quit message: anythinggggg
20899 > -
20900 > -NickServ- Options: Kill protection, Security
20901 > -
20902 > ***************************
20903 >
20904 > the new line I'm suggesting is something like:
20905 >
20906 > ***************************
20907 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
20908 > ***************************
20909 >
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).
20915 >
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)
20919 >
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)
20922 >
20923 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
20924 >
20925 > sincerely,
20926 > David
20927 >
20928 > _________________________________________________________________
20929 > Get MSN 8 and enjoy automatic e-mail virus protection.
20930 > http://join.msn.com/?page=features/virus
20931 >
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
20938
20939
20940
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>
20946
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..
20948
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
20951
20952 *shock*
20953
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  ****************************************/
20961
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  ****************************************/
20968
20969 /****** - Begin Original Message - ******/
20970
20971 >Hi,
20972 >
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:
20976 >
20977 >***************************
20978 >-
20979 >-NickServ- nick is hello world
20980 >-
20981 >-NickServ- Is online from: ~test@just.a.test.co.za
20982 >-
20983 >-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
20984 >-
20985 >-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
20986 >-
20987 >-NickServ- Last quit message: anythinggggg
20988 >-
20989 >-NickServ- Options: Kill protection, Security
20990 >-
20991 >***************************
20992 >
20993 >the new line I'm suggesting is something like:
20994 >
20995 >***************************
20996 >-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
20997 >***************************
20998 >
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).
21004 >
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)
21008 >
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)
21011 >
21012 >Many thanks to all of who developed IRCservices ...etc ...etc ...etc
21013 >
21014 >sincerely,
21015 >David
21016 >
21017 >_________________________________________________________________
21018 >Get MSN 8 and enjoy automatic e-mail virus protection.
21019 >http://join.msn.com/?page=features/virus
21020 >
21021 >------------------------------------------------------------------
21022 >To unsubscribe or change your subscription options, visit:
21023 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
21024
21025 /******* - End Original Message - *******/
21026
21027
21028
21029
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>
21035
21036 We're having a small problem with suspended channel.
21037
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.
21040
21041 Also with suspended nick , when the suspencion expire, the services crash
21042 We're using:
21043
21044 ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
21045
21046
21047 Thanks
21048 Marc
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>
21057
21058 hmm.. what OS, compiler version etc are you using?
21059
21060 after a test, i got the following:
21061
21062 /cs id #abc 00376370
21063 -ChanServ- Channel #abc is suspended and may not be used or identified for.
21064
21065 /cs drop #abc
21066 [23:20] -ChanServ- Channel  is suspended and may not be used or identified for.
21067
21068 only prob i got was it missed the channel name in the second message :)
21069
21070 /cs drop #abc
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  ****************************************/
21078
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  ****************************************/
21085
21086 /****** - Begin Original Message - ******/
21087
21088 >We're having a small problem with suspended channel.
21089 >
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.
21092 >
21093 >Also with suspended nick , when the suspencion expire, the services crash
21094 >We're using:
21095 >
21096 >ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
21097 >
21098 >
21099 >Thanks
21100 >Marc
21101 >------------------------------------------------------------------
21102 >To unsubscribe or change your subscription options, visit:
21103 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
21104
21105 /******* - End Original Message - *******/
21106
21107
21108
21109
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>
21116
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...
21121
21122 Just an idea... I now await the half dozen people who will proceed to tell
21123 me how stupid my idea is....
21124
21125 Saturn
21126 irc.jetirc.net
21127
21128
21129
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>
21137
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.
21142
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..
21146 >
21147 > /time services.chatspike.net
21148 > [22:28] ??? Date / time at services.chatspike.net- Thu Aug 28 17:28:57
21149 > 2003 EDT
21150 >
21151 > *shock*
21152 >
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 >  ****************************************/
21160 >
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 >  ****************************************/
21167 >
21168 > /****** - Begin Original Message - ******/
21169 >
21170 >>Hi,
21171 >>
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:
21175 >>
21176 >>***************************
21177 >>-
21178 >>-NickServ- nick is hello world
21179 >>-
21180 >>-NickServ- Is online from: ~test@just.a.test.co.za
21181 >>-
21182 >>-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
21183 >>-
21184 >>-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
21185 >>-
21186 >>-NickServ- Last quit message: anythinggggg
21187 >>-
21188 >>-NickServ- Options: Kill protection, Security
21189 >>-
21190 >>***************************
21191 >>
21192 >>the new line I'm suggesting is something like:
21193 >>
21194 >>***************************
21195 >>-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
21196 >>***************************
21197 >>
21198 >>This will help our users to compare the time that user was last seen and
21199 >> the
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
21203 >> GMT
21204 >>(last seen time was before: 10 days, 3hours and 24 sec ago).
21205 >>
21206 >>Note that I saw both of these features, in other services I don't
21207 >> remember
21208 >>there names (but they aren't as stable as ircservices5) (it was something
21209 >>like ptlink services, and magik II)
21210 >>
21211 >>That's all, I would really like to see it on the next version (or if you
21212 >> can
21213 >>show me how to do it, as I'm not a programmer)
21214 >>
21215 >>Many thanks to all of who developed IRCservices ...etc ...etc ...etc
21216 >>
21217 >>sincerely,
21218 >>David
21219 >>
21220 >>_________________________________________________________________
21221 >>Get MSN 8 and enjoy automatic e-mail virus protection.
21222 >>http://join.msn.com/?page=features/virus
21223 >>
21224 >>------------------------------------------------------------------
21225 >>To unsubscribe or change your subscription options, visit:
21226 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
21227 >
21228 > /******* - End Original Message - *******/
21229 >
21230 >
21231 >
21232 > ------------------------------------------------------------------
21233 > To unsubscribe or change your subscription options, visit:
21234 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
21235 >
21236
21237
21238 --
21239 Best Regards,
21240 playa
21241 Network Founder/CEO
21242 DreamChat IRC Network - irc.dreamchat.org
21243 http://www.dreamchat.org
21244
21245
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>
21252
21253 On Thursday, Aug 28, 2003, at 20:46 US/Pacific, playa wrote:
21254
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.
21259
21260 That's a client thing.  Some clients might alias /time as a CTCP TIME
21261 for a specific user, or similar.
21262
21263 -- Quension
21264
21265
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>
21274
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.
21279
21280 Some clients use stupid aliases for CTCP commands, for example:
21281
21282 /version <nick> = /CTCP <nick> VERSION,
21283 /time <nick> = /CTCP <nick> TIME,
21284 /finger <nick> = /CTCP <nick> TIME
21285
21286 This is why nothing works the way you expected.
21287
21288 --
21289 Krisztian Romek
21290 r-krisztian@softhome.net
21291
21292
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>
21298
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).
21302
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
21306
21307
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>
21313
21314
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.
21320
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
21324
21325
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>
21331
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.
21333
21334 And i'll Quote Elijah:
21335
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
21338 be 'no.'"
21339
21340
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  ****************************************/
21348
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  ****************************************/
21355
21356 /****** - Begin Original Message - ******/
21357
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.
21363 >
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
21367 >
21368 >------------------------------------------------------------------
21369 >To unsubscribe or change your subscription options, visit:
21370 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
21371 >.
21372
21373 /******* - End Original Message - *******/
21374
21375
21376
21377
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>
21383
21384 its a stupid idea!!! :p
21385
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
21387
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  ****************************************/
21395
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  ****************************************/
21402
21403 /****** - Begin Original Message - ******/
21404
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...
21409 >
21410 >Just an idea... I now await the half dozen people who will proceed to tell
21411 >me how stupid my idea is....
21412 >
21413 >Saturn
21414 >irc.jetirc.net
21415 >
21416 >
21417 >------------------------------------------------------------------
21418 >To unsubscribe or change your subscription options, visit:
21419 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
21420
21421 /******* - End Original Message - *******/
21422
21423
21424
21425
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>
21432
21433 Cheers.
21434
21435 -----Original Message-----
21436 From: ircservices-coding-bounces@ircservices.za.net
21437 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of Craig
21438 McLure
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
21442
21443
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
21446 to annoy me.
21447
21448 And i'll Quote Elijah:
21449
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
21452 be 'no.'"
21453
21454
21455
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>
21461
21462 woops, ok sorry I thought the two e-mails is completely different.
21463
21464
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
21472 >
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.
21476 >
21477 >And i'll Quote Elijah:
21478 >
21479 >"Except it's already been said in the FAQ that it's not going to happen,
21480 >and
21481 >if that made it into the FAQ it would seem the answer is frequently going
21482 >to
21483 >be 'no.'"
21484 >
21485 >
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 >  ****************************************/
21493 >
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 >  ****************************************/
21500 >
21501 >/****** - Begin Original Message - ******/
21502 >
21503 > >Since most people want to see this feature(s) in the next version, it
21504 >would
21505 > >be great to implement it as an optional feature , where it can be
21506 >disabled
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
21509 >fact,
21510 > >it will add another nice feature to the features list of IRCservices5.
21511 > >
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
21515 > >
21516 > >------------------------------------------------------------------
21517 > >To unsubscribe or change your subscription options, visit:
21518 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
21519 > >.
21520 >
21521 >/******* - End Original Message - *******/
21522 >
21523 >
21524 >
21525 >------------------------------------------------------------------
21526 >To unsubscribe or change your subscription options, visit:
21527 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
21528
21529 _________________________________________________________________
21530 MSN 8: Get 6 months for $9.95/month. http://join.msn.com/?page=dept/dialup
21531
21532
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>
21539
21540 Hi
21541 I run ircservices 5.0.21 on FreeBSD 4.8-STABLE. and Ultimate 3.*
21542 I get this in logfile:
21543
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)
21556
21557 and how can I do so that nickserv dont show the realhost of a user in
21558 'ns info nick all'
21559
21560
21561 thanks for help
21562
21563                            Ali "Simorgh"
21564  ______________________________________________________
21565  Many of life's failures are people who did not realize
21566  how close they were to success when they gave up.
21567  Thomas A. Edison
21568  ______________________________________________________
21569
21570
21571
21572
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>
21579
21580 "and how can I do so that nickserv dont show the realhost of a user in
21581 'ns info nick all'"
21582
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
21586 option is set.
21587
21588
21589
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>
21596
21597      Use E-mail if you need communication of that sort.
21598
21599   --Andrew Church
21600     achurch@achurch.org
21601     http://achurch.org/
21602
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
21607 >have been denied.
21608 >
21609 >/chanserv MARK <channel> <reason>
21610 >
21611 >/chanserv info #channel would read the following.
21612 >*#channel has been MARKED by playa - <reason>
21613 >
21614 >Of course only IRCops would be able to view it.
21615 >
21616 >Just an idea i thought of :)
21617 >
21618 >--
21619 >Best Regards,
21620 >playa
21621 >Network Founder/CEO
21622 >DreamChat IRC Network - irc.dreamchat.org
21623 >http://www.dreamchat.org
21624 >
21625 >------------------------------------------------------------------
21626 >To unsubscribe or change your subscription options, visit:
21627 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
21628
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>
21635
21636      Needless complexity.  If you don't want yourself autoopped, then don't
21637 be an auto-op.  It's that simple.
21638
21639   --Andrew Church
21640     achurch@achurch.org
21641     http://achurch.org/
21642
21643 >Hi again
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.
21646 >
21647 >Like:
21648 > SET NOAUTO ON|OFF
21649 >  When NOAUTO is on, ChanServ will not
21650 >  automatically op or voice you in any channels.
21651 >
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.
21654 >
21655 >Or did I miss it?
21656 >
21657 >Thanks
21658 >
21659 >                           Ali "Simorgh"
21660 > ______________________________________________________
21661 > Many of life's failures are people who did not realize
21662 > how close they were to success when they gave up.
21663 > Thomas A. Edison
21664 > ______________________________________________________
21665 >
21666 >
21667 >On Sun, 17 Aug 2003, Russell Garrett wrote:
21668 >
21669 >> Eh? This has been implemented since IRCServices 5a31.
21670 >>
21671 >> Russ
21672 >>
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)
21677 >> >
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
21680 >> > channels.
21681 >> >
21682 >> > Thanks for any help
21683 >>
21684 >> ------------------------------------------------------------------
21685 >> To unsubscribe or change your subscription options, visit:
21686 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
21687 >>
21688 >
21689 >------------------------------------------------------------------
21690 >To unsubscribe or change your subscription options, visit:
21691 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
21692
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>
21700
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.
21704
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
21713 is not complex.
21714
21715 Shaun
21716
21717
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>
21723
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..
21726
21727 or /cs levels #channels DISABLE autoop
21728
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  ****************************************/
21736
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  ****************************************/
21743
21744 /****** - Begin Original Message - ******/
21745
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.
21749 >
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
21758 >is not complex.
21759 >
21760 >Shaun
21761 >
21762 >------------------------------------------------------------------
21763 >To unsubscribe or change your subscription options, visit:
21764 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
21765 >.
21766
21767 /******* - End Original Message - *******/
21768
21769
21770
21771
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>
21779
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..
21782
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.
21785
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
21788
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
21795
21796 Same with ENFORCE set to off as well.
21797
21798 > [snipped obnoxiously long sig]
21799
21800 Shaun Guth
21801
21802
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>
21809
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
21812 >
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
21819
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.
21823
21824   --Andrew Church
21825     achurch@achurch.org
21826     http://achurch.org/
21827
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>
21834
21835 >Can we reconsider adding a Mass memo function for the next release?
21836
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.
21844
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.
21850
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.
21855
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.
21858
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........
21865
21866      This is an interesting thought; I'll think about it for a future
21867 version.
21868
21869   --Andrew Church
21870     achurch@achurch.org
21871     http://achurch.org/
21872
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>
21879
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?
21885
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.
21890
21891   --Andrew Church
21892     achurch@achurch.org
21893     http://achurch.org/
21894
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>
21901
21902 >Is there any tool (silly question) or something or guid to make a language
21903 >file.
21904 >
21905 >I have decided to make a Persian (Farsi) language file.
21906
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.
21911
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.
21914
21915   --Andrew Church
21916     achurch@achurch.org
21917     http://achurch.org/
21918
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>
21925
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
21929
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?
21932
21933   --Andrew Church
21934     achurch@achurch.org
21935     http://achurch.org/
21936
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>
21943
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.
21947
21948      This is a bug in the DROP function, and has been fixed; thanks for the
21949 report.
21950
21951   --Andrew Church
21952     achurch@achurch.org
21953     http://achurch.org/
21954
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>
21961
21962 >[Aug 30 10:56:18 2003] mail/sendmail:
21963 > /usr/sbin/sendmail exited with code 25600
21964
21965      Use the SMTP module instead (mail/smtp).
21966
21967 >[Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
21968 >registration (Simorgh)
21969 >
21970 >and how can I do so that nickserv dont show the realhost of a user in
21971 >'ns info nick all'
21972
21973      It doesn't.  However:
21974
21975 >[Aug 30 10:51:19 2003] unknown message from server
21976 >(:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
21977
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.
21981
21982   --Andrew Church
21983     achurch@achurch.org
21984     http://achurch.org/
21985
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>
21992
21993 >Or how about rather letting users decide what timezone they're in and
21994 >services outputs all timestamps in their local time?
21995
21996 /ns help set timezone (since 5.0 alpha)
21997
21998   --Andrew Church
21999     achurch@achurch.org
22000     http://achurch.org/
22001
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>
22009
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.
22017
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?
22025
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....
22032
22033 Saturn
22034 irc.jetirc.net
22035
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
22041
22042
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...
22045
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.
22049
22050   --Andrew Church
22051     achurch@achurch.org
22052     http://achurch.org/
22053
22054
22055
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>
22064
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.
22074
22075 Erm, what's the argument here?  Services stipulates its timezone in its
22076 timestamps.  As do all the other servers on the network.
22077
22078 Atleast mine do...
22079
22080
22081 Regards,
22082 Aragon
22083
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>
22092
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??
22097
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
22103 suggestion
22104
22105
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
22109 server
22110 > is in a different time zone -- How are users supposed to know what time
22111 zone
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.
22117
22118 Erm, what's the argument here?  Services stipulates its timezone in its
22119 timestamps.  As do all the other servers on the network.
22120
22121 Atleast mine do...
22122
22123
22124 Regards,
22125 Aragon
22126 ------------------------------------------------------------------
22127 To unsubscribe or change your subscription options, visit:
22128 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
22129
22130
22131
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>
22139
22140 On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
22141
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?
22146
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
22150 it back.
22151
22152 >   Why does it all have to be so complicated??
22153
22154 It isn't.  Your users can even use the handy-dandy /nickserv set
22155 timezone command to make it even easier.
22156
22157 > ----- Original Message -----
22158 > From: "Aragon Gouveia" <aragon@phat.za.net>
22159
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.
22170 >
22171 > Erm, what's the argument here?  Services stipulates its timezone in
22172 > its timestamps.  As do all the other servers on the network.
22173
22174 -- Quension
22175
22176
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>
22183
22184
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
22187 seconds ago)
22188 Time registered  : Jul 25 22:19:20 2003 GMT (** days, ** minutes and **
22189 seconds ago)
22190 wouldn't even a greater idea?
22191
22192 _________________________________________________________________
22193 Get MSN 8 and enjoy automatic e-mail virus protection.
22194 http://join.msn.com/?page=features/virus
22195
22196
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>
22204
22205 [16:41] -NickServ-   Time registered: Jul 27 13:09:08 2002 PDT
22206
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....
22215
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
22218 valid ones...
22219
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
22222 codes like PDT)...
22223
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
22230 suggestion
22231
22232
22233 On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
22234
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?
22239
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
22243 it back.
22244
22245 >   Why does it all have to be so complicated??
22246
22247 It isn't.  Your users can even use the handy-dandy /nickserv set
22248 timezone command to make it even easier.
22249
22250 > ----- Original Message -----
22251 > From: "Aragon Gouveia" <aragon@phat.za.net>
22252
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.
22263 >
22264 > Erm, what's the argument here?  Services stipulates its timezone in
22265 > its timestamps.  As do all the other servers on the network.
22266
22267 -- Quension
22268
22269 ------------------------------------------------------------------
22270 To unsubscribe or change your subscription options, visit:
22271 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
22272
22273
22274
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>
22282
22283 On Sunday, Aug 31, 2003, at 16:47 US/Pacific, Saturn wrote:
22284
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)...
22288
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.
22292
22293 -- Quension
22294
22295
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>
22303
22304      "Use /ns set timezone" is the official answer on this.  Please take
22305 all further discussion to the ircservices list.
22306
22307   --Andrew Church
22308     achurch@achurch.org
22309     http://achurch.org/
22310
22311 >[16:41] -NickServ-   Time registered: Jul 27 13:09:08 2002 PDT
22312 >
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....
22321 >
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
22324 >valid ones...
22325 >
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)...
22329 >
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
22336 >suggestion
22337 >
22338 >
22339 >On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
22340 >
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?
22345 >
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
22349 >it back.
22350 >
22351 >>   Why does it all have to be so complicated??
22352 >
22353 >It isn't.  Your users can even use the handy-dandy /nickserv set
22354 >timezone command to make it even easier.
22355 >
22356 >> ----- Original Message -----
22357 >> From: "Aragon Gouveia" <aragon@phat.za.net>
22358 >
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.
22369 >>
22370 >> Erm, what's the argument here?  Services stipulates its timezone in
22371 >> its timestamps.  As do all the other servers on the network.
22372 >
22373 >-- Quension
22374 >
22375 >------------------------------------------------------------------
22376 >To unsubscribe or change your subscription options, visit:
22377 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
22378 >
22379 >
22380 >------------------------------------------------------------------
22381 >To unsubscribe or change your subscription options, visit:
22382 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
22383
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>
22390
22391 Thanks for your help.
22392
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
22397            Is online from: %s
22398 to:
22399 NICK_INFO_ADDRESS_ONLINE
22400            Is online from: N/A ?
22401
22402
22403                            Ali "Simorgh"
22404  ______________________________________________________
22405  Many of life's failures are people who did not realize
22406  how close they were to success when they gave up.
22407  Thomas A. Edison
22408  ______________________________________________________
22409
22410
22411 On Mon, 1 Sep 2003, Andrew Church wrote:
22412
22413 > >[Aug 30 10:56:18 2003] mail/sendmail:
22414 > > /usr/sbin/sendmail exited with code 25600
22415 >
22416 >      Use the SMTP module instead (mail/smtp).
22417 >
22418 > >[Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
22419 > >registration (Simorgh)
22420 > >
22421 > >and how can I do so that nickserv dont show the realhost of a user in
22422 > >'ns info nick all'
22423 >
22424 >      It doesn't.  However:
22425 >
22426 > >[Aug 30 10:51:19 2003] unknown message from server
22427 > >(:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
22428 >
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.
22432 >
22433 >   --Andrew Church
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
22439 >
22440
22441
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>
22448
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
22451
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.
22456
22457   --Andrew Church
22458     achurch@achurch.org
22459     http://achurch.org/
22460
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>
22466
22467 Hi all,
22468
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.
22472
22473 Regards
22474
22475 alex
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>
22486
22487 Hello,
22488
22489 alex wrote:
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.
22493
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
22497 computer.
22498
22499 --
22500 Krisztian Romek
22501 r-krisztian@softhome.net
22502
22503
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>
22509
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.
22511
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.
22513
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  ****************************************/
22521
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  ****************************************/
22528
22529 /****** - Begin Original Message - ******/
22530
22531 >Hi all,
22532 >
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.
22536 >
22537 >Regards
22538 >
22539 >alex
22540 >------------------------------------------------------------------
22541 >To unsubscribe or change your subscription options, visit:
22542 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
22543
22544 /******* - End Original Message - *******/
22545
22546
22547
22548
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>
22554
22555 It wasn't an easy subject to sum up in just a few words.
22556
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
22569 send.c
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
22573 all the
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)
22585
22586 Thanks
22587
22588 Brent
22589
22590
22591
22592 ----------------------------------------------------------
22593 |               Brent DiNicola                                  |
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 -----------------------------------------------------------
22600
22601
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>
22607
22608 lol, Our help no good? :P
22609
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..
22611
22612 Dont ask me for source on this.. i'm just theorising :)
22613
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  ****************************************/
22621
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  ****************************************/
22628
22629 /****** - Begin Original Message - ******/
22630
22631 >It wasn't an easy subject to sum up in just a few words.
22632 >
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
22645 >send.c
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
22649 >all the
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)
22661 >
22662 >Thanks
22663 >
22664 >Brent
22665 >
22666 >
22667 >
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 >-----------------------------------------------------------
22676 >
22677 >------------------------------------------------------------------
22678 >To unsubscribe or change your subscription options, visit:
22679 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
22680 >.
22681
22682 /******* - End Original Message - *******/
22683
22684
22685
22686
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>
22694
22695 Hello;
22696
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.
22706
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.
22721 ...
22722
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.
22726
22727 To your case.
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.
22731
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
22734 trivial.
22735
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
22739 closed.
22740
22741 Do keep in mind that requesting support for modified services versions
22742 are subject to be ignored.
22743
22744 I hope it helps,
22745 yusuf
22746
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.
22749 >
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
22762 > send.c
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
22766 > all the
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)
22778 >
22779 > Thanks
22780 >
22781 > Brent
22782 >
22783 >
22784 >
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 > -----------------------------------------------------------
22793 >
22794 > ------------------------------------------------------------------
22795 > To unsubscribe or change your subscription options, visit:
22796 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
22797 --
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 ------------------------------------------------------------------
22804
22805
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>
22812
22813 Brent DiNicola wrote:
22814
22815 > It wasn't an easy subject to sum up in just a few words.
22816 >
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
22822 > the users
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
22825 > NOTICE
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
22828 > the best
22829 > way to go about this without causing trouble for me and anyone else
22830 > who has
22831 > to deal with this code. Is it possible or even suggested to make a
22832 > module that
22833 > would replace the notice() from send.c with it's own, leaving the code
22834 > in send.c
22835 > alone and not causing troubles down the road. Suggestions were that I
22836 > make a
22837 > module that kept the info for each nick's setting and then if I could
22838 > override
22839 > the notice() and notice_lang() and notice_help() in send.c that would
22840 > keep all the
22841 > other code clean and not cause other troubles. I want to know what the
22842 > best
22843 > way to do this would be, I know it's against RFC but I want to move to
22844 > newer
22845 > services than the 1.4.3pre4 that we are using now and add modules so
22846 > that I
22847 > can do things down the line. They are used to having PRIVMSG and I
22848 > can't just
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
22851 > this? I
22852 > know this topic has been asked before and I know your not going to
22853 > make it
22854 > part of your code, I just wanted to know from the people who know the
22855 > code
22856 > really well what the best route to take would be to do the least
22857 > amount of
22858 > damage. (And if someone has done this.. please let me know what you did,
22859 > examples would rock)
22860 >
22861 > Thanks
22862 >
22863 > Brent
22864 >
22865 >
22866 >
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
22878 >
22879 >
22880
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
22885
22886 services is the wrong thing to change
22887
22888
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>
22894
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
22896
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  ****************************************/
22904
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  ****************************************/
22911
22912 /****** - Begin Original Message - ******/
22913
22914 >Brent DiNicola wrote:
22915 >
22916 >> It wasn't an easy subject to sum up in just a few words.
22917 >>
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
22923 >> the users
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
22926 >> NOTICE
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
22929 >> the best
22930 >> way to go about this without causing trouble for me and anyone else
22931 >> who has
22932 >> to deal with this code. Is it possible or even suggested to make a
22933 >> module that
22934 >> would replace the notice() from send.c with it's own, leaving the code
22935 >> in send.c
22936 >> alone and not causing troubles down the road. Suggestions were that I
22937 >> make a
22938 >> module that kept the info for each nick's setting and then if I could
22939 >> override
22940 >> the notice() and notice_lang() and notice_help() in send.c that would
22941 >> keep all the
22942 >> other code clean and not cause other troubles. I want to know what the
22943 >> best
22944 >> way to do this would be, I know it's against RFC but I want to move to
22945 >> newer
22946 >> services than the 1.4.3pre4 that we are using now and add modules so
22947 >> that I
22948 >> can do things down the line. They are used to having PRIVMSG and I
22949 >> can't just
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
22952 >> this? I
22953 >> know this topic has been asked before and I know your not going to
22954 >> make it
22955 >> part of your code, I just wanted to know from the people who know the
22956 >> code
22957 >> really well what the best route to take would be to do the least
22958 >> amount of
22959 >> damage. (And if someone has done this.. please let me know what you did,
22960 >> examples would rock)
22961 >>
22962 >> Thanks
22963 >>
22964 >> Brent
22965 >>
22966 >>
22967 >>
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
22979 >>
22980 >>
22981 >
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
22986 >
22987 >services is the wrong thing to change
22988 >
22989 >------------------------------------------------------------------
22990 >To unsubscribe or change your subscription options, visit:
22991 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
22992 >.
22993
22994 /******* - End Original Message - *******/
22995
22996
22997
22998
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>
23005
23006 On Thursday, Sep 4, 2003, at 13:29 US/Pacific, Robert F Merrill wrote:
23007
23008 > Brent DiNicola wrote:
23009 >
23010 >> It wasn't an easy subject to sum up in just a few words.
23011
23012 [...]
23013
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
23018 >
23019 > services is the wrong thing to change
23020
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.
23024
23025 This is the coding list, not the feature request list.  He asked for
23026 code design approaches, not for political insight.
23027
23028 -- Quension
23029
23030
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>
23036
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
23042
23043 Thanks for all
23044
23045 Diego B. Contezini
23046
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..
23052
23053
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
23059 get
23060 > a core.
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
23063 break
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.
23068 >
23069 > Thanks for all
23070 >
23071 > Diego B. Contezini aka destruct_ | irc.redesul.net
23072 > (Sorry for my confuse english.)
23073 >
23074
23075
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>
23082
23083 Hello, im destruct_, im the administrator of the RedeSul Network.
23084 (irc.redesul.net).
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
23088 a core.
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.
23095
23096 Thanks for all
23097
23098 Diego B. Contezini aka destruct_ | irc.redesul.net
23099 (Sorry for my confuse english.)
23100
23101
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>
23107
23108 Hi All
23109
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
23121
23122 many thanks
23123 Engin
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>
23132
23133 make sure you are on the services administrator list, if you are not, get the root administrator to add you using the command:
23134
23135 [22:27] -OperServ- Syntax: ADMIN ADD nickname
23136 [22:27] -OperServ- ADMIN DEL nickname
23137 [22:27] -OperServ- ADMIN LIST
23138 [22:27] -OperServ-
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.
23143 [22:27] -OperServ-
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.
23146
23147
23148
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  ****************************************/
23156
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  ****************************************/
23163
23164 /****** - Begin Original Message - ******/
23165
23166 >Hi All
23167 >
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
23179 >
23180 >many thanks
23181 >Engin
23182 >------------------------------------------------------------------
23183 >To unsubscribe or change your subscription options, visit:
23184 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
23185
23186 /******* - End Original Message - *******/
23187
23188
23189
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>
23196
23197 Contact me directly... I have quite a bit of experience with unreal and these services...
23198
23199 Saturn
23200 irc.jetirc.net
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
23206
23207
23208   Hi All
23209
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
23221
23222   many thanks
23223   Engin
23224
23225
23226
23227 ------------------------------------------------------------------------------
23228
23229
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>
23242
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....
23245
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
23252
23253
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:
23256
23257 [22:27] -OperServ- Syntax: ADMIN ADD nickname
23258 [22:27] -OperServ- ADMIN DEL nickname
23259 [22:27] -OperServ- ADMIN LIST
23260 [22:27] -OperServ-
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.
23265 [22:27] -OperServ-
23266 [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
23267 command.
23268 [22:27] -OperServ- All other use limited to Services super-user.
23269
23270
23271
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  ****************************************/
23279
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  ****************************************/
23286
23287 /****** - Begin Original Message - ******/
23288
23289 >Hi All
23290 >
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
23302 >
23303 >many thanks
23304 >Engin
23305 >------------------------------------------------------------------
23306 >To unsubscribe or change your subscription options, visit:
23307 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
23308
23309 /******* - End Original Message - *******/
23310
23311
23312 ------------------------------------------------------------------
23313 To unsubscribe or change your subscription options, visit:
23314 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
23315
23316
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>
23323
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
23326 one
23327
23328 cheers
23329 Engin
23330
23331
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
23337
23338
23339 > Send IRCServices-Coding mailing list submissions to
23340 > ircservices-coding@ircservices.za.net
23341 >
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
23346 >
23347 > You can reach the person managing the list at
23348 > ircservices-coding-owner@ircservices.za.net
23349 >
23350 > When replying, please edit your Subject line so it is more specific
23351 > than "Re: Contents of IRCServices-Coding digest..."
23352 >
23353 >
23354 > Today's Topics:
23355 >
23356 >    1. operserv (engin@piratetv)
23357 >    2. Re: operserv (Craig McLure)
23358 >    3. Re: operserv (Saturn)
23359 >    4. Re: operserv (Saturn)
23360 >
23361 >
23362 > ----------------------------------------------------------------------
23363 >
23364 > Message: 1
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"
23371 >
23372 > Hi All
23373 >
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
23385 >
23386 > many thanks
23387 > Engin
23388 > -------------- next part --------------
23389 > An HTML attachment was scrubbed...
23390 > URL:
23391 http://snow.fingers.co.za/pipermail/ircservices-coding/attachments/20030921/
23392 fdc12b4e/attachment-0001.htm
23393 >
23394 > ------------------------------
23395 >
23396 > Message: 2
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"
23404 >
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:
23407 >
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
23413 nicknames
23414 > [22:27] -OperServ- to or from the Services admin list. A user whose
23415 nickname
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
23418 commands.
23419 > [22:27] -OperServ-
23420 > [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
23421 command.
23422 > [22:27] -OperServ- All other use limited to Services super-user.
23423 >
23424 >
23425 >
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 >  ****************************************/
23433 >
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 >  ****************************************/
23440 >
23441 > /****** - Begin Original Message - ******/
23442 >
23443 > >Hi All
23444 > >
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
23456 > >
23457 > >many thanks
23458 > >Engin
23459 > >------------------------------------------------------------------
23460 > >To unsubscribe or change your subscription options, visit:
23461 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
23462 >
23463 > /******* - End Original Message - *******/
23464 >
23465 >
23466 >
23467 > ------------------------------
23468 >
23469 > Message: 3
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"
23477 >
23478 > Contact me directly... I have quite a bit of experience with unreal and
23479 these services...
23480 >
23481 > Saturn
23482 > irc.jetirc.net
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
23488 >
23489 >
23490 >   Hi All
23491 >
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
23494 mailing
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
23504 >
23505 >   many thanks
23506 >   Engin
23507 >
23508 >
23509 >
23510 > --------------------------------------------------------------------------
23511 ----
23512 >
23513 >
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...
23519 > URL:
23520 http://snow.fingers.co.za/pipermail/ircservices-coding/attachments/20030921/
23521 ca188e06/attachment-0001.htm
23522 >
23523 > ------------------------------
23524 >
23525 > Message: 4
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"
23533 >
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
23536 denied....
23537 >
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
23544 >
23545 >
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:
23548 >
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
23554 nicknames
23555 > [22:27] -OperServ- to or from the Services admin list. A user whose
23556 nickname
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
23559 commands.
23560 > [22:27] -OperServ-
23561 > [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
23562 > command.
23563 > [22:27] -OperServ- All other use limited to Services super-user.
23564 >
23565 >
23566 >
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 >  ****************************************/
23574 >
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 >  ****************************************/
23581 >
23582 > /****** - Begin Original Message - ******/
23583 >
23584 > >Hi All
23585 > >
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
23597 > >
23598 > >many thanks
23599 > >Engin
23600 > >------------------------------------------------------------------
23601 > >To unsubscribe or change your subscription options, visit:
23602 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
23603 >
23604 > /******* - End Original Message - *******/
23605 >
23606 >
23607 > ------------------------------------------------------------------
23608 > To unsubscribe or change your subscription options, visit:
23609 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
23610 >
23611 >
23612 > ------------------------------
23613 >
23614 > _______________________________________________
23615 > IRCServices-Coding mailing list
23616 > IRCServices-Coding@ircservices.za.net
23617 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
23618 >
23619 >
23620 > End of IRCServices-Coding Digest, Vol 8, Issue 5
23621 > ************************************************
23622
23623
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>
23631
23632 Sometimes has occur this bug, last 1 year....
23633 on a network with 30k registers, its happening with latency of 3.. 4
23634 days....
23635
23636 someone have any idea?
23637
23638 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
23639 av=0xbfffeec8) at channels.c:278
23640 278         while (*s) {
23641 (gdb) bt'
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>
23646         add = 1
23647         modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
23648 #1  0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:680
23649         buf =
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
23661 bounds>,
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@`???"}
23665         len = 4
23666         i = 0
23667         lastc = 45 '-'
23668 #2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
23669         args = 0x0
23670         modes = 0x0
23671         modes_orig = 0x0
23672         md = (struct modedata *) 0x0
23673         which = -1
23674         add = 0
23675         i = 0
23676         c = 0 '\0'
23677 #3  0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at main.c:269
23678         now = 1065393142
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.
23684 (gdb)
23685
23686
23687
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>
23694
23695 Upgrade.
23696
23697   --Andrew Church
23698     achurch@achurch.org
23699     http://achurch.org/
23700
23701 >Sometimes has occur this bug, last 1 year....
23702 >on a network with 30k registers, its happening with latency of 3.. 4
23703 >days....
23704 >
23705 >someone have any idea?
23706 >
23707 >#0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
23708 >av=0xbfffeec8) at channels.c:278
23709 >278         while (*s) {
23710 >(gdb) bt'
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>
23715 >        add = 1
23716 >        modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
23717 >#1  0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:68
23718 >0
23719 >        buf =
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ï¿½ï¿½ï¿½ï¿
23723 >½
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\
23728 >000\000\0
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�
23734 >���\027\000\0
23735 >00\000\000\000\000\000\024\032"...
23736 >        s = 0xbfffeef0 "-isl"
23737 >        argv = {0xa97b6c0 "#young", 0x20656c62 <Address 0x20656c62 out
23738 >of
23739 >bounds>,
23740 >  0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 o
23741 >ut
23742 >of bounds>, 0x42133cec "\004", 0xbffff1fc "",
23743 >  0x4204533d "\201���\016", 0x42131a14 " \031\023
23744 >B�h\001@`�"}
23745 >        len = 4
23746 >        i = 0
23747 >        lastc = 45 '-'
23748 >#2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:32
23749 >1
23750 >        args = 0x0
23751 >        modes = 0x0
23752 >        modes_orig = 0x0
23753 >        md = (struct modedata *) 0x0
23754 >        which = -1
23755 >        add = 0
23756 >        i = 0
23757 >        c = 0 '\0'
23758 >#3  0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at ma
23759 >in.c:269
23760 >        now = 1065393142
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.
23766 >(gdb)
23767 >
23768 >
23769 >------------------------------------------------------------------
23770 >To unsubscribe or change your subscription options, visit:
23771 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
23772
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>
23779
23780 Upgrade?
23781 ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
23782 18:41:36 BRT 2003
23783 -
23784
23785 Its the last version.......
23786
23787 Diego B. Contezini
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....
23793
23794
23795 > Upgrade.
23796 >
23797 >   --Andrew Church
23798 >     achurch@achurch.org
23799 >     http://achurch.org/
23800 >
23801 > >Sometimes has occur this bug, last 1 year....
23802 > >on a network with 30k registers, its happening with latency of 3.. 4
23803 > >days....
23804 > >
23805 > >someone have any idea?
23806 > >
23807 > >#0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
23808 > >av=0xbfffeec8) at channels.c:278
23809 > >278         while (*s) {
23810 > >(gdb) bt'
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>
23815 > >        add = 1
23816 > >        modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
23817 > >#1  0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:68
23818 > >0
23819 > >        buf =
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???????????
23823 > >?
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\
23828 > >000\000\0
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
23838 > >of
23839 > >bounds>,
23840 > >  0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 o
23841 > >ut
23842 > >of bounds>, 0x42133cec "\004", 0xbffff1fc "",
23843 > >  0x4204533d "\201?????????\016", 0x42131a14 " \031\023
23844 > >B???h\001@`???"}
23845 > >        len = 4
23846 > >        i = 0
23847 > >        lastc = 45 '-'
23848 > >#2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:32
23849 > >1
23850 > >        args = 0x0
23851 > >        modes = 0x0
23852 > >        modes_orig = 0x0
23853 > >        md = (struct modedata *) 0x0
23854 > >        which = -1
23855 > >        add = 0
23856 > >        i = 0
23857 > >        c = 0 '\0'
23858 > >#3  0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at ma
23859 > >in.c:269
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.
23866 > >(gdb)
23867 > >
23868 > >
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
23875 >
23876
23877
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>
23884
23885 >Upgrade?
23886 >ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
23887 >18:41:36 BRT 2003
23888 >-
23889 >
23890 >Its the last version.......
23891
23892      Then send a full debug log (from startup to crash), or I can't help.
23893
23894   --Andrew Church
23895     achurch@achurch.org
23896     http://achurch.org/
23897
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>
23904
23905 And how should be this log? i sent a backtrace......
23906
23907 Diego B. Contezini
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....
23913
23914
23915 > >Upgrade?
23916 > >ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
23917 > >18:41:36 BRT 2003
23918 > >-
23919 > >
23920 > >Its the last version.......
23921 >
23922 >      Then send a full debug log (from startup to crash), or I can't help.
23923 >
23924 >   --Andrew Church
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
23930 >
23931
23932
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>
23939
23940 >And how should be this log? i sent a backtrace......
23941
23942 RTFM (FAQ Z.3)
23943
23944   --Andrew Church
23945     achurch@achurch.org
23946     http://achurch.org/
23947
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>
23954
23955 Read....
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
23958 nofork.....
23959
23960 Cya
23961 Diego B. Contezini
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....
23967
23968
23969 > >And how should be this log? i sent a backtrace......
23970 >
23971 > RTFM (FAQ Z.3)
23972 >
23973 >   --Andrew Church
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
23979 >
23980
23981
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>
23988
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).
23991
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...
23998
23999 First: IS that what it's supposed to do?
24000
24001 Second: If so, it's not working...
24002
24003 Saturn
24004 www.jetirc.net
24005
24006
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>
24013
24014
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.
24018
24019 I copy the sintaz of mail-auth ( it's in italian )
24020
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:
24029             /msg %s AUTH %09d
24030
24031         La registrazione del tuo nick sara' confermata e il tuo nickname
24032         sara' protetto da eventuali tentativi di abuso o furto.
24033
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.
24037
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.
24041
24042
24043         Sono inoltre disponibili i seguenti servizi:
24044
24045         - MusiChat Forum
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.
24051
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.
24057
24058
24059         Per una connessione piu' veloce e sicura e' vivamente
24060         consigliato l'utilizzo del seguente server: irc.musichat.net
24061
24062         MusiChat Net Community
24063
24064         Questo messaggio e stato inviato su richiesta di %s in risposta a %s
24065         %s@%s.
24066
24067
24068
24069
24070 I read the istruction for translate.
24071
24072 The error is:
24073
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
24077
24078
24079 Some one can help me?
24080 the email body is too long?
24081
24082 Thx
24083
24084 Alex
24085
24086
24087
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>
24094
24095      You have the wrong number of %-tokens in your message.
24096
24097   --Andrew Church
24098     achurch@achurch.org
24099     http://achurch.org/
24100
24101 >
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.
24105 >
24106 >I copy the sintaz of mail-auth ( it's in italian )
24107 >
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
24117 >
24118 >        La registrazione del tuo nick sara' confermata e il tuo nickname
24119 >        sara' protetto da eventuali tentativi di abuso o furto.
24120 >
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.
24124 >
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.
24128 >
24129 >
24130 >        Sono inoltre disponibili i seguenti servizi:
24131 >
24132 >        - MusiChat Forum
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.
24138 >
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.
24144 >
24145 >
24146 >        Per una connessione piu' veloce e sicura e' vivamente
24147 >        consigliato l'utilizzo del seguente server: irc.musichat.net
24148 >
24149 >        MusiChat Net Community
24150 >
24151 >        Questo messaggio e stato inviato su richiesta di %s in risposta a %s
24152 >        %s@%s.
24153 >
24154 >
24155 >
24156 >
24157 >I read the istruction for translate.
24158 >
24159 >The error is:
24160 >
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
24164 >
24165 >
24166 >Some one can help me?
24167 >the email body is too long?
24168 >
24169 >Thx
24170 >
24171 >Alex
24172 >
24173 >
24174 >------------------------------------------------------------------
24175 >To unsubscribe or change your subscription options, visit:
24176 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
24177
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>
24183
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 ?
24192
24193 ######################################################
24194 modules/chanserv/check.c
24195 ...
24196 void check_chan_user_modes(const char *source, struct c_userlist *u,
24197                            Channel *c, int32 oldmodes)
24198 ...
24199         if ((res & ~modes) & CUMODE_o) {
24200             ci->last_used = time(NULL);
24201             put_channelinfo(ci);
24202         }
24203 ...
24204 ######################################################
24205
24206 |SaMaN|
24207
24208
24209
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>
24215
24216 Also it does not update last_used time on +a flag.
24217
24218 Temporary fix
24219 ---------------
24220
24221 edit /modules/chanserv/check.c
24222
24223 find line
24224 -------------------------------------------------------------------------
24225         local_set_cumodes(c, '+', res & ~modes, user->nick);
24226 -------------------------------------------------------------------------
24227 add below
24228 ------------------------------------------------------------------------
24229         int16 cumode_q = mode_char_to_flag('q',MODE_CHANUSER);
24230         int16 cumode_a = mode_char_to_flag('a',MODE_CHANUSER);
24231
24232         if ((res & ~modes) & cumode_q) {
24233             ci->last_used = time(NULL);
24234             put_channelinfo(ci);
24235         }
24236
24237         if ((res & ~modes) & cumode_a) {
24238             ci->last_used = time(NULL);
24239             put_channelinfo(ci);
24240         }
24241 -------------------------------------------------------------------------
24242 save and compile and run and enjoy :)
24243 -------------------------------------------------------------------------
24244
24245 |SaMaN|
24246
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 ?
24252
24253
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
24258 mode:
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
24261 to
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 ?
24264 >
24265 > ######################################################
24266 > modules/chanserv/check.c
24267 > ...
24268 > void check_chan_user_modes(const char *source, struct c_userlist *u,
24269 >                            Channel *c, int32 oldmodes)
24270 > ...
24271 >         if ((res & ~modes) & CUMODE_o) {
24272 >             ci->last_used = time(NULL);
24273 >             put_channelinfo(ci);
24274 >         }
24275 > ...
24276 > ######################################################
24277 >
24278 > |SaMaN|
24279 >
24280 >
24281
24282
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>
24288
24289 Haven't seen a reply to this one, so thought I'd better make sure this went
24290 through....
24291
24292 ----- Original Message -----
24293 Sent: Friday, October 10, 2003 3:48 PM
24294 Subject: Akill problem in 5.0.22
24295
24296
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).
24299
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...
24306
24307 First: IS that what it's supposed to do?
24308
24309 Second: If so, it's not working...
24310
24311 Saturn
24312 www.jetirc.net
24313
24314
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>
24321
24322 RTFM
24323
24324   --Andrew Church
24325     achurch@achurch.org
24326     http://achurch.org/
24327
24328 >Haven't seen a reply to this one, so thought I'd better make sure this went
24329 >through....
24330 >
24331 >----- Original Message -----
24332 >Sent: Friday, October 10, 2003 3:48 PM
24333 >Subject: Akill problem in 5.0.22
24334 >
24335 >
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).
24338 >
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...
24345 >
24346 >First: IS that what it's supposed to do?
24347 >
24348 >Second: If so, it's not working...
24349 >
24350 >Saturn
24351 >www.jetirc.net
24352 >
24353 >------------------------------------------------------------------
24354 >To unsubscribe or change your subscription options, visit:
24355 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
24356
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>
24363
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
24366
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
24370 it first.
24371     Example: ImmediatelySendAutokill
24372
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
24378 kill them.
24379
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?
24384
24385 Thanks
24386 Saturn
24387
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
24393
24394
24395 RTFM
24396
24397   --Andrew Church
24398     achurch@achurch.org
24399     http://achurch.org/
24400
24401 >Haven't seen a reply to this one, so thought I'd better make sure this went
24402 >through....
24403 >
24404 >----- Original Message -----
24405 >Sent: Friday, October 10, 2003 3:48 PM
24406 >Subject: Akill problem in 5.0.22
24407 >
24408 >
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).
24411 >
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
24414 scanning
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...
24419 >
24420 >First: IS that what it's supposed to do?
24421 >
24422 >Second: If so, it's not working...
24423 >
24424 >Saturn
24425 >www.jetirc.net
24426 >
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
24433
24434
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>
24441
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
24446 >kill them.
24447
24448      The documentation says nothing about this.  RTFM again.
24449
24450   --Andrew Church
24451     achurch@achurch.org
24452     http://achurch.org/
24453
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>
24461
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
24467 to deal with it.
24468
24469 Ballsy
24470
24471
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
24475 >
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
24479 >it first.
24480 >     Example: ImmediatelySendAutokill
24481 >
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
24487 >kill them.
24488 >
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?
24493 >
24494 >Thanks
24495 >Saturn
24496 >
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
24502 >
24503 >
24504 >RTFM
24505 >
24506 >   --Andrew Church
24507 >     achurch@achurch.org
24508 >     http://achurch.org/
24509 >
24510 > >Haven't seen a reply to this one, so thought I'd better make sure this went
24511 > >through....
24512 > >
24513 > >----- Original Message -----
24514 > >Sent: Friday, October 10, 2003 3:48 PM
24515 > >Subject: Akill problem in 5.0.22
24516 > >
24517 > >
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).
24520 > >
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
24523 >scanning
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...
24528 > >
24529 > >First: IS that what it's supposed to do?
24530 > >
24531 > >Second: If so, it's not working...
24532 > >
24533 > >Saturn
24534 > >www.jetirc.net
24535 > >
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
24542 >
24543 >------------------------------------------------------------------
24544 >To unsubscribe or change your subscription options, visit:
24545 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
24546
24547
24548
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>
24555
24556 >From a.html in the /docs directory:
24557 ---------------
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
24562 it first.
24563     Example: ImmediatelySendAutokill
24564 --------------
24565
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 ------------------------
24580
24581 4.html#oper.akill doesn't mention it at all.
24582
24583 -----------------
24584
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!!!
24592
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?
24598
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???????
24605
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.
24615
24616 Saturn
24617
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
24623
24624
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
24629 >kill them.
24630
24631      The documentation says nothing about this.  RTFM again.
24632
24633   --Andrew Church
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
24639
24640
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>
24648
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.
24656
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
24663 programming...
24664
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
24672
24673
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
24679 to deal with it.
24680
24681 Ballsy
24682
24683
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
24687 >
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
24691 >it first.
24692 >     Example: ImmediatelySendAutokill
24693 >
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
24699 >kill them.
24700 >
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?
24705 >
24706 >Thanks
24707 >Saturn
24708 >
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
24714 >
24715 >
24716 >RTFM
24717 >
24718 >   --Andrew Church
24719 >     achurch@achurch.org
24720 >     http://achurch.org/
24721 >
24722 > >Haven't seen a reply to this one, so thought I'd better make sure this
24723 went
24724 > >through....
24725 > >
24726 > >----- Original Message -----
24727 > >Sent: Friday, October 10, 2003 3:48 PM
24728 > >Subject: Akill problem in 5.0.22
24729 > >
24730 > >
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).
24733 > >
24734 > >I just today added an akill (+0 time) .. I DO have the immediate auto
24735 kill
24736 > >option un-commented in the modules.conf, but it still didn't bother
24737 >scanning
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
24740 thought
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...
24743 > >
24744 > >First: IS that what it's supposed to do?
24745 > >
24746 > >Second: If so, it's not working...
24747 > >
24748 > >Saturn
24749 > >www.jetirc.net
24750 > >
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
24757 >
24758 >------------------------------------------------------------------
24759 >To unsubscribe or change your subscription options, visit:
24760 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
24761
24762
24763 ------------------------------------------------------------------
24764 To unsubscribe or change your subscription options, visit:
24765 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
24766
24767
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>
24773
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.
24775
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
24777
24778 Please just calm down, and talk this out rationally before you start jumping down ppls throats :p
24779
24780 /*****************************************
24781  *     Craig "FrostyCoolSlug" McLure
24782  * InspIRCd   - http://www.inspircd.org
24783  * ChatSpike  - http://www.chatspike.net
24784  ****************************************/
24785
24786
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  ****************************************/
24793
24794 /****** - Begin Original Message - ******/
24795
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.
24803 >
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
24810 >programming...
24811 >
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
24819 >
24820 >
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
24826 >to deal with it.
24827 >
24828 >Ballsy
24829 >
24830 >
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
24834 >>
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
24838 >>it first.
24839 >>     Example: ImmediatelySendAutokill
24840 >>
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
24846 >>kill them.
24847 >>
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?
24852 >>
24853 >>Thanks
24854 >>Saturn
24855 >>
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
24861 >>
24862 >>
24863 >>RTFM
24864 >>
24865 >>   --Andrew Church
24866 >>     achurch@achurch.org
24867 >>     http://achurch.org/
24868 >>
24869 >> >Haven't seen a reply to this one, so thought I'd better make sure this
24870 >went
24871 >> >through....
24872 >> >
24873 >> >----- Original Message -----
24874 >> >Sent: Friday, October 10, 2003 3:48 PM
24875 >> >Subject: Akill problem in 5.0.22
24876 >> >
24877 >> >
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).
24880 >> >
24881 >> >I just today added an akill (+0 time) .. I DO have the immediate auto
24882 >kill
24883 >> >option un-commented in the modules.conf, but it still didn't bother
24884 >>scanning
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
24887 >thought
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...
24890 >> >
24891 >> >First: IS that what it's supposed to do?
24892 >> >
24893 >> >Second: If so, it's not working...
24894 >> >
24895 >> >Saturn
24896 >> >www.jetirc.net
24897 >> >
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
24904 >>
24905 >>------------------------------------------------------------------
24906 >>To unsubscribe or change your subscription options, visit:
24907 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
24908 >
24909 >
24910 >------------------------------------------------------------------
24911 >To unsubscribe or change your subscription options, visit:
24912 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
24913 >
24914 >------------------------------------------------------------------
24915 >To unsubscribe or change your subscription options, visit:
24916 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
24917 >
24918 >.
24919
24920 /******* - End Original Message - *******/
24921
24922
24923
24924
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>
24931
24932      You know, I might have been more forgiving if this hadn't been gone
24933 over on this list (twice!) before:
24934
24935 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/002305.html
24936 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/003215.html
24937
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
24940 edification:
24941
24942 F.10. Services doesn't kill users matching a newly-added autokill mask even
24943 if ImmediatelySendAutokill is set.
24944
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.
24951
24952         Note that some IRC servers will themselves kill users matching a
24953         newly-added autokill; this is unrelated to Services.
24954
24955   --Andrew Church
24956     achurch@achurch.org
24957     http://achurch.org/
24958
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>
24968
24969 Saturn wrote:
24970
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.
24978 >
24979 >
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
24986 do this.
24987
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).
24992
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.
24996
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.
25004
25005
25006
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>
25015
25016 On Saturday 18 October 2003 07:20, Robert F Merrill wrote:
25017 > Saturn 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.
25025 >
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
25032 > do this.
25033
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.
25036
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.
25041
25042 <<V13>>
25043
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>
25050
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)
25061
25062 root@irc(/home/ircadmin/services/lib)# ls -la core.12631
25063 -rw-------    1 ircadmin ircadmin 47374336 Oct 18 16:05 core.12631
25064
25065
25066 continue on the next message......
25067
25068
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>
25075
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;
25080 (gdb) bt'
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
25084         s = 0x806aa3e ""
25085 #1  0x0804d342 in set_cmode (sender=0x81db058 "ChanServ", channel=0xa905d00)
25086 at actions.c:446
25087         parambuf =
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"...
25096         len = 10
25097         flag = 1
25098         params = 1
25099         is_chanuser = 1
25100         args = 0xbfffe6d0 "RDcoCOREcorei??i??i??i??o"
25101         modes = 0xbfffeae2 ""
25102         modes_orig = 0xbfffeae0 "+o"
25103         md = (struct modedata *) 0x806aa00
25104         which = 0
25105         add = 1
25106         i = 1
25107         c = 111 'o'
25108 #2  0x400895ff in local_set_cumodes (c=0xa905d00, plusminus=43 '+', modes=1,
25109 nick=0xab7f2e8 "balsanelli") at check.c:432
25110         buf = "+o"
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).."...
25115         s = 0xbfffe6e1 ""
25116 #3  0x40088d74 in check_chan_user_modes (source=0xbfffeed0 "|-Frango-|",
25117 u=0xab34ff0, c=0xa905d00, oldmodes=1)
25118     at check.c:214
25119         user = (User *) 0xab7f2d8
25120         ci = (ChannelInfo *) 0xa571940
25121         modes = 0
25122         is_servermode = 0
25123         res = 1
25124 #4  0x400820ed in do_channel_umode_change (source=0xbfffeed0 "|-Frango-|",
25125 c=0xa905d00, u=0xab34ff0, oldmodes=1)
25126     at main.c:354
25127 No locals.
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
25132         res = 0
25133         i = 0
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---
25137     at channels.c:409
25138         u = (struct c_userlist *) 0xab34ff0
25139         user = (User *) 0xab7f2d8
25140         oldmode = 1
25141 #7  0x0804e97e in do_cmode (source=0xbfffeed0 "|-Frango-|", ac=0,
25142 av=0xa853130) at channels.c:302
25143         modechar = 111 'o'
25144         flag = 1
25145         params = -1073746288
25146         chan = (Channel *) 0xa905d00
25147         s = 0xbfffeca5 ""
25148         add = 0
25149         modestr = 0xbfffec9e "-oooooo"
25150 #8  0x080557ff in m_mode (source=0xbfffeed0 "|-Frango-|", ac=8,
25151 av=0xa853110) at messages.c:101
25152 No locals.
25153 #9  0x0805920e in process () at process.c:133
25154         m = (Message *) 0x8067dd8
25155         source =
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
25158 5\b"
25159         cmd =
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"
25163         buf =
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"
25171         ac = 8
25172         av = (char **) 0xa853110
25173 #10 0x0805507d in readline_callback (s=0xa851ae0, param_unused=0x50) at
25174 main.c:177
25175 No locals.
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."...
25181         left = 80
25182         newleft = 80
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}
25186         i = 4
25187         res = 260
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---
25192         now = 1066500331
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.
25198 (gdb)
25199
25200
25201
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>
25208
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.
25216
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?
25230
25231 Thank you all for your time.
25232
25233 Saturn
25234
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
25240
25241
25242      You know, I might have been more forgiving if this hadn't been gone
25243 over on this list (twice!) before:
25244
25245 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/002305.html
25246 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/003215.html
25247
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
25250 edification:
25251
25252 F.10. Services doesn't kill users matching a newly-added autokill mask even
25253 if ImmediatelySendAutokill is set.
25254
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.
25261
25262 Note that some IRC servers will themselves kill users matching a
25263 newly-added autokill; this is unrelated to Services.
25264
25265   --Andrew Church
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
25271
25272
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>
25278
25279 If it helps, more lines up.. of debugging...
25280
25281
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)
25294
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>
25306
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.
25312
25313 Ballsy
25314
25315
25316 At 12:49 PM 18/10/2003, V13 wrote:
25317 >On Saturday 18 October 2003 07:20, Robert F Merrill wrote:
25318 > > Saturn 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.
25326 > >
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
25333 > > do this.
25334 >
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.
25337 >
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.
25342 >
25343 ><<V13>>
25344 >------------------------------------------------------------------
25345 >To unsubscribe or change your subscription options, visit:
25346 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
25347
25348
25349
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>
25355
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>
25363
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
25366
25367 ciao
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>
25377
25378 Andrew, have anything more of dumping/debugging that i can do/give for helps
25379 fixing this bug..?
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)....
25382 anything more?
25383
25384
25385 Thanks for all
25386
25387
25388 Diego B. Contezini
25389
25390
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>
25396
25397
25398
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>
25404
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
25407 18:41:36 BRT 2003)
25408 yes, 5.0.23 is the last.. but nothing has changed about the bug...
25409
25410  here is the debugging:
25411
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
25416 #Euevc
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
25424 +stmipl 1
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)
25436
25437
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;
25443 (gdb) bt'
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
25447         s = 0x806aa3e ""
25448 #1  0x0804d342 in set_cmode (sender=0x81db058 "ChanServ", channel=0xa905d00)
25449 at actions.c:446
25450         parambuf =
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"...
25459         len = 10
25460         flag = 1
25461         params = 1
25462         is_chanuser = 1
25463         args = 0xbfffe6d0 "RDcoCOREcorei??i??i??i??o"
25464         modes = 0xbfffeae2 ""
25465         modes_orig = 0xbfffeae0 "+o"
25466         md = (struct modedata *) 0x806aa00
25467         which = 0
25468         add = 1
25469         i = 1
25470         c = 111 'o'
25471 #2  0x400895ff in local_set_cumodes (c=0xa905d00, plusminus=43 '+', modes=1,
25472 nick=0xab7f2e8 "balsanelli") at check.c:432
25473         buf = "+o"
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).."...
25478         s = 0xbfffe6e1 ""
25479 #3  0x40088d74 in check_chan_user_modes (source=0xbfffeed0 "|-Frango-|",
25480 u=0xab34ff0, c=0xa905d00, oldmodes=1)
25481     at check.c:214
25482         user = (User *) 0xab7f2d8
25483         ci = (ChannelInfo *) 0xa571940
25484         modes = 0
25485         is_servermode = 0
25486         res = 1
25487 #4  0x400820ed in do_channel_umode_change (source=0xbfffeed0 "|-Frango-|",
25488 c=0xa905d00, u=0xab34ff0, oldmodes=1)
25489     at main.c:354
25490 No locals.
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
25495         res = 0
25496         i = 0
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---
25500     at channels.c:409
25501         u = (struct c_userlist *) 0xab34ff0
25502         user = (User *) 0xab7f2d8
25503         oldmode = 1
25504 #7  0x0804e97e in do_cmode (source=0xbfffeed0 "|-Frango-|", ac=0,
25505 av=0xa853130) at channels.c:302
25506         modechar = 111 'o'
25507         flag = 1
25508         params = -1073746288
25509         chan = (Channel *) 0xa905d00
25510         s = 0xbfffeca5 ""
25511         add = 0
25512         modestr = 0xbfffec9e "-oooooo"
25513 #8  0x080557ff in m_mode (source=0xbfffeed0 "|-Frango-|", ac=8,
25514 av=0xa853110) at messages.c:101
25515 No locals.
25516 #9  0x0805920e in process () at process.c:133
25517         m = (Message *) 0x8067dd8
25518         source =
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
25521 5\b"
25522         cmd =
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"
25526         buf =
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"
25534         ac = 8
25535         av = (char **) 0xa853110
25536 #10 0x0805507d in readline_callback (s=0xa851ae0, param_unused=0x50) at
25537 main.c:177
25538 No locals.
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."...
25544         left = 80
25545         newleft = 80
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}
25549         i = 4
25550         res = 260
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---
25555         now = 1066500331
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
25572 cs             0x23     35
25573 ss             0x2b     43
25574 ds             0x2b     43
25575 es             0x2b     43
25576 fs             0x0      0
25577 gs             0x33     51
25578 (gdb)
25579
25580
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
25593 ...
25594 model name      : Pentium III (Coppermine)
25595 stepping        : 10
25596 cpu MHz         : 999.752
25597 cache size      : 256 KB
25598 ...
25599 root@irc(/home/ircadmin/services)# free
25600              total       used       free     shared    buffers     cached
25601 Mem:        513792     482248      31544          0      69492     274980
25602
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*
25612
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
25624
25625
25626 If it helps, here is the debugging of the last two cores, on gdb:
25627 ----------------
25628 FIRST:
25629 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
25630 av=0xbfffdc38)
25631     at channels.c:278
25632 278         while (*s) {
25633 (gdb) bt'
25634 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
25635 av=0xbfffdc38)
25636     at channels.c:278
25637         chan = (Channel *) 0xa87d1e0
25638         s = 0x1f73746f <Address 0x1f73746f out of bounds>
25639         add = 1
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
25649 \006\b"...
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>}
25659         len = 5
25660 ---Type <return> to continue, or q <return> to quit---
25661         i = 0
25662         lastc = 45 '-'
25663 #2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
25664         args = 0x0
25665         modes = 0x0
25666         modes_orig = 0x0
25667         md = (struct modedata *) 0x0
25668         which = -1
25669         add = 0
25670         i = 0
25671         c = 0 '\0'
25672 #3  0x080553a3 in main (ac=1, av=0xbfffe574, envp=0xbfffe57c) at main.c:269
25673         now = 1067891066
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.
25679 -----------
25680
25681 SECOND:
25682 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
25683 av=0xbffff2b8)
25684     at channels.c:278
25685 278         while (*s) {
25686 (gdb) bt'
25687 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
25688 av=0xbffff2b8)
25689     at channels.c:278
25690         chan = (Channel *) 0xa9be840
25691         s = 0xbf000000 <Address 0xbf000000 out of bounds>
25692         add = 1
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>}
25709         len = 5
25710         i = 0
25711         lastc = 45 '-'
25712 #2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
25713 ---Type <return> to continue, or q <return> to quit---
25714         args = 0x0
25715         modes = 0x0
25716         modes_orig = 0x0
25717         md = (struct modedata *) 0x0
25718         which = -1
25719         add = 0
25720         i = 0
25721         c = 0 '\0'
25722 #3  0x080553a3 in main (ac=1, av=0xbffffbf4, envp=0xbffffbfc) at main.c:269
25723         now = 1067706795
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.
25729 (gdb)
25730 -------
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
25733 this bug...
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
25737 anything....
25738
25739 Thanks for all development, this is really a bealtifull software...
25740 (and sorry for my bad english)
25741
25742 Diego B. Contezini aka destruct_ #irc.redesul.net
25743
25744
25745
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>
25751
25752 If it helps, im using Bahamut here....
25753
25754
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>
25761
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 ?
25770
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.
25780
25781   --Andrew Church
25782     achurch@achurch.org
25783     http://achurch.org/
25784
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>
25790
25791
25792
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>
25798
25799 Hi,
25800
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:
25804
25805 ***************************
25806 -
25807 -NickServ- nick is hello world
25808 -
25809 -NickServ- Is online from: ~test@just.a.test.co.za
25810 -
25811 -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
25812 -
25813 -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
25814 -
25815 -NickServ- Last quit message: anythinggggg
25816 -
25817 -NickServ- Options: Kill protection, Security
25818 -
25819 ***************************
25820
25821 the new line I'm suggesting is something like:
25822
25823 ***************************
25824 -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
25825 ***************************
25826
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).
25832
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)
25836
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)
25839
25840 Many thanks to all of who developed IRCservices ...etc ...etc ...etc
25841
25842 sincerely,
25843 David
25844
25845 _________________________________________________________________
25846 Get MSN 8 and enjoy automatic e-mail virus protection.
25847 http://join.msn.com/?page=features/virus
25848
25849
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>
25857
25858 Or how about rather letting users decide what timezone they're in and
25859 services outputs all timestamps in their local time?
25860
25861
25862 | By us44ever . <us44ever@hotmail.com>
25863 |                                          [ 2003-08-28 18:45 +0200 ]
25864 > Hi,
25865 >
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:
25869 >
25870 > ***************************
25871 > -
25872 > -NickServ- nick is hello world
25873 > -
25874 > -NickServ- Is online from: ~test@just.a.test.co.za
25875 > -
25876 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
25877 > -
25878 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
25879 > -
25880 > -NickServ- Last quit message: anythinggggg
25881 > -
25882 > -NickServ- Options: Kill protection, Security
25883 > -
25884 > ***************************
25885 >
25886 > the new line I'm suggesting is something like:
25887 >
25888 > ***************************
25889 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
25890 > ***************************
25891 >
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).
25897 >
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)
25901 >
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)
25904 >
25905 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
25906 >
25907 > sincerely,
25908 > David
25909 >
25910 > _________________________________________________________________
25911 > Get MSN 8 and enjoy automatic e-mail virus protection.
25912 > http://join.msn.com/?page=features/virus
25913 >
25914 > ------------------------------------------------------------------
25915 > To unsubscribe or change your subscription options, visit:
25916 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
25917
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>
25925
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
25933
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
25939
25940
25941 Or how about rather letting users decide what timezone they're in and
25942 services outputs all timestamps in their local time?
25943
25944
25945 | By us44ever . <us44ever@hotmail.com>
25946 |                                          [ 2003-08-28 18:45 +0200 ]
25947 > Hi,
25948 >
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:
25952 >
25953 > ***************************
25954 > -
25955 > -NickServ- nick is hello world
25956 > -
25957 > -NickServ- Is online from: ~test@just.a.test.co.za
25958 > -
25959 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
25960 > -
25961 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
25962 > -
25963 > -NickServ- Last quit message: anythinggggg
25964 > -
25965 > -NickServ- Options: Kill protection, Security
25966 > -
25967 > ***************************
25968 >
25969 > the new line I'm suggesting is something like:
25970 >
25971 > ***************************
25972 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
25973 > ***************************
25974 >
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).
25980 >
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)
25984 >
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)
25987 >
25988 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
25989 >
25990 > sincerely,
25991 > David
25992 >
25993 > _________________________________________________________________
25994 > Get MSN 8 and enjoy automatic e-mail virus protection.
25995 > http://join.msn.com/?page=features/virus
25996 >
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
26003
26004
26005
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>
26011
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..
26013
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
26016
26017 *shock*
26018
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  ****************************************/
26026
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  ****************************************/
26033
26034 /****** - Begin Original Message - ******/
26035
26036 >Hi,
26037 >
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:
26041 >
26042 >***************************
26043 >-
26044 >-NickServ- nick is hello world
26045 >-
26046 >-NickServ- Is online from: ~test@just.a.test.co.za
26047 >-
26048 >-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
26049 >-
26050 >-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
26051 >-
26052 >-NickServ- Last quit message: anythinggggg
26053 >-
26054 >-NickServ- Options: Kill protection, Security
26055 >-
26056 >***************************
26057 >
26058 >the new line I'm suggesting is something like:
26059 >
26060 >***************************
26061 >-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
26062 >***************************
26063 >
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).
26069 >
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)
26073 >
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)
26076 >
26077 >Many thanks to all of who developed IRCservices ...etc ...etc ...etc
26078 >
26079 >sincerely,
26080 >David
26081 >
26082 >_________________________________________________________________
26083 >Get MSN 8 and enjoy automatic e-mail virus protection.
26084 >http://join.msn.com/?page=features/virus
26085 >
26086 >------------------------------------------------------------------
26087 >To unsubscribe or change your subscription options, visit:
26088 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
26089
26090 /******* - End Original Message - *******/
26091
26092
26093
26094
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>
26100
26101 We're having a small problem with suspended channel.
26102
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.
26105
26106 Also with suspended nick , when the suspencion expire, the services crash
26107 We're using:
26108
26109 ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
26110
26111
26112 Thanks
26113 Marc
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>
26122
26123 hmm.. what OS, compiler version etc are you using?
26124
26125 after a test, i got the following:
26126
26127 /cs id #abc 00376370
26128 -ChanServ- Channel #abc is suspended and may not be used or identified for.
26129
26130 /cs drop #abc
26131 [23:20] -ChanServ- Channel  is suspended and may not be used or identified for.
26132
26133 only prob i got was it missed the channel name in the second message :)
26134
26135 /cs drop #abc
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  ****************************************/
26143
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  ****************************************/
26150
26151 /****** - Begin Original Message - ******/
26152
26153 >We're having a small problem with suspended channel.
26154 >
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.
26157 >
26158 >Also with suspended nick , when the suspencion expire, the services crash
26159 >We're using:
26160 >
26161 >ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
26162 >
26163 >
26164 >Thanks
26165 >Marc
26166 >------------------------------------------------------------------
26167 >To unsubscribe or change your subscription options, visit:
26168 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
26169
26170 /******* - End Original Message - *******/
26171
26172
26173
26174
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>
26181
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...
26186
26187 Just an idea... I now await the half dozen people who will proceed to tell
26188 me how stupid my idea is....
26189
26190 Saturn
26191 irc.jetirc.net
26192
26193
26194
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>
26202
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.
26207
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..
26211 >
26212 > /time services.chatspike.net
26213 > [22:28] ??? Date / time at services.chatspike.net- Thu Aug 28 17:28:57
26214 > 2003 EDT
26215 >
26216 > *shock*
26217 >
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 >  ****************************************/
26225 >
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 >  ****************************************/
26232 >
26233 > /****** - Begin Original Message - ******/
26234 >
26235 >>Hi,
26236 >>
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:
26240 >>
26241 >>***************************
26242 >>-
26243 >>-NickServ- nick is hello world
26244 >>-
26245 >>-NickServ- Is online from: ~test@just.a.test.co.za
26246 >>-
26247 >>-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
26248 >>-
26249 >>-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
26250 >>-
26251 >>-NickServ- Last quit message: anythinggggg
26252 >>-
26253 >>-NickServ- Options: Kill protection, Security
26254 >>-
26255 >>***************************
26256 >>
26257 >>the new line I'm suggesting is something like:
26258 >>
26259 >>***************************
26260 >>-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
26261 >>***************************
26262 >>
26263 >>This will help our users to compare the time that user was last seen and
26264 >> the
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
26268 >> GMT
26269 >>(last seen time was before: 10 days, 3hours and 24 sec ago).
26270 >>
26271 >>Note that I saw both of these features, in other services I don't
26272 >> remember
26273 >>there names (but they aren't as stable as ircservices5) (it was something
26274 >>like ptlink services, and magik II)
26275 >>
26276 >>That's all, I would really like to see it on the next version (or if you
26277 >> can
26278 >>show me how to do it, as I'm not a programmer)
26279 >>
26280 >>Many thanks to all of who developed IRCservices ...etc ...etc ...etc
26281 >>
26282 >>sincerely,
26283 >>David
26284 >>
26285 >>_________________________________________________________________
26286 >>Get MSN 8 and enjoy automatic e-mail virus protection.
26287 >>http://join.msn.com/?page=features/virus
26288 >>
26289 >>------------------------------------------------------------------
26290 >>To unsubscribe or change your subscription options, visit:
26291 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
26292 >
26293 > /******* - End Original Message - *******/
26294 >
26295 >
26296 >
26297 > ------------------------------------------------------------------
26298 > To unsubscribe or change your subscription options, visit:
26299 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
26300 >
26301
26302
26303 --
26304 Best Regards,
26305 playa
26306 Network Founder/CEO
26307 DreamChat IRC Network - irc.dreamchat.org
26308 http://www.dreamchat.org
26309
26310
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>
26317
26318 On Thursday, Aug 28, 2003, at 20:46 US/Pacific, playa wrote:
26319
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.
26324
26325 That's a client thing.  Some clients might alias /time as a CTCP TIME
26326 for a specific user, or similar.
26327
26328 -- Quension
26329
26330
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>
26339
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.
26344
26345 Some clients use stupid aliases for CTCP commands, for example:
26346
26347 /version <nick> = /CTCP <nick> VERSION,
26348 /time <nick> = /CTCP <nick> TIME,
26349 /finger <nick> = /CTCP <nick> TIME
26350
26351 This is why nothing works the way you expected.
26352
26353 --
26354 Krisztian Romek
26355 r-krisztian@softhome.net
26356
26357
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>
26363
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).
26367
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
26371
26372
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>
26378
26379
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.
26385
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
26389
26390
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>
26396
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.
26398
26399 And i'll Quote Elijah:
26400
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
26403 be 'no.'"
26404
26405
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  ****************************************/
26413
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  ****************************************/
26420
26421 /****** - Begin Original Message - ******/
26422
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.
26428 >
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
26432 >
26433 >------------------------------------------------------------------
26434 >To unsubscribe or change your subscription options, visit:
26435 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
26436 >.
26437
26438 /******* - End Original Message - *******/
26439
26440
26441
26442
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>
26448
26449 its a stupid idea!!! :p
26450
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
26452
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  ****************************************/
26460
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  ****************************************/
26467
26468 /****** - Begin Original Message - ******/
26469
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...
26474 >
26475 >Just an idea... I now await the half dozen people who will proceed to tell
26476 >me how stupid my idea is....
26477 >
26478 >Saturn
26479 >irc.jetirc.net
26480 >
26481 >
26482 >------------------------------------------------------------------
26483 >To unsubscribe or change your subscription options, visit:
26484 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
26485
26486 /******* - End Original Message - *******/
26487
26488
26489
26490
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>
26497
26498 Cheers.
26499
26500 -----Original Message-----
26501 From: ircservices-coding-bounces@ircservices.za.net
26502 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of Craig
26503 McLure
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
26507
26508
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
26511 to annoy me.
26512
26513 And i'll Quote Elijah:
26514
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
26517 be 'no.'"
26518
26519
26520
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>
26526
26527 woops, ok sorry I thought the two e-mails is completely different.
26528
26529
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
26537 >
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.
26541 >
26542 >And i'll Quote Elijah:
26543 >
26544 >"Except it's already been said in the FAQ that it's not going to happen,
26545 >and
26546 >if that made it into the FAQ it would seem the answer is frequently going
26547 >to
26548 >be 'no.'"
26549 >
26550 >
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 >  ****************************************/
26558 >
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 >  ****************************************/
26565 >
26566 >/****** - Begin Original Message - ******/
26567 >
26568 > >Since most people want to see this feature(s) in the next version, it
26569 >would
26570 > >be great to implement it as an optional feature , where it can be
26571 >disabled
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
26574 >fact,
26575 > >it will add another nice feature to the features list of IRCservices5.
26576 > >
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
26580 > >
26581 > >------------------------------------------------------------------
26582 > >To unsubscribe or change your subscription options, visit:
26583 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
26584 > >.
26585 >
26586 >/******* - End Original Message - *******/
26587 >
26588 >
26589 >
26590 >------------------------------------------------------------------
26591 >To unsubscribe or change your subscription options, visit:
26592 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
26593
26594 _________________________________________________________________
26595 MSN 8: Get 6 months for $9.95/month. http://join.msn.com/?page=dept/dialup
26596
26597
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>
26604
26605 Hi
26606 I run ircservices 5.0.21 on FreeBSD 4.8-STABLE. and Ultimate 3.*
26607 I get this in logfile:
26608
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)
26621
26622 and how can I do so that nickserv dont show the realhost of a user in
26623 'ns info nick all'
26624
26625
26626 thanks for help
26627
26628                            Ali "Simorgh"
26629  ______________________________________________________
26630  Many of life's failures are people who did not realize
26631  how close they were to success when they gave up.
26632  Thomas A. Edison
26633  ______________________________________________________
26634
26635
26636
26637
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>
26644
26645 "and how can I do so that nickserv dont show the realhost of a user in
26646 'ns info nick all'"
26647
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
26651 option is set.
26652
26653
26654
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>
26661
26662      Use E-mail if you need communication of that sort.
26663
26664   --Andrew Church
26665     achurch@achurch.org
26666     http://achurch.org/
26667
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
26672 >have been denied.
26673 >
26674 >/chanserv MARK <channel> <reason>
26675 >
26676 >/chanserv info #channel would read the following.
26677 >*#channel has been MARKED by playa - <reason>
26678 >
26679 >Of course only IRCops would be able to view it.
26680 >
26681 >Just an idea i thought of :)
26682 >
26683 >--
26684 >Best Regards,
26685 >playa
26686 >Network Founder/CEO
26687 >DreamChat IRC Network - irc.dreamchat.org
26688 >http://www.dreamchat.org
26689 >
26690 >------------------------------------------------------------------
26691 >To unsubscribe or change your subscription options, visit:
26692 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
26693
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>
26700
26701      Needless complexity.  If you don't want yourself autoopped, then don't
26702 be an auto-op.  It's that simple.
26703
26704   --Andrew Church
26705     achurch@achurch.org
26706     http://achurch.org/
26707
26708 >Hi again
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.
26711 >
26712 >Like:
26713 > SET NOAUTO ON|OFF
26714 >  When NOAUTO is on, ChanServ will not
26715 >  automatically op or voice you in any channels.
26716 >
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.
26719 >
26720 >Or did I miss it?
26721 >
26722 >Thanks
26723 >
26724 >                           Ali "Simorgh"
26725 > ______________________________________________________
26726 > Many of life's failures are people who did not realize
26727 > how close they were to success when they gave up.
26728 > Thomas A. Edison
26729 > ______________________________________________________
26730 >
26731 >
26732 >On Sun, 17 Aug 2003, Russell Garrett wrote:
26733 >
26734 >> Eh? This has been implemented since IRCServices 5a31.
26735 >>
26736 >> Russ
26737 >>
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)
26742 >> >
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
26745 >> > channels.
26746 >> >
26747 >> > Thanks for any help
26748 >>
26749 >> ------------------------------------------------------------------
26750 >> To unsubscribe or change your subscription options, visit:
26751 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
26752 >>
26753 >
26754 >------------------------------------------------------------------
26755 >To unsubscribe or change your subscription options, visit:
26756 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
26757
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>
26765
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.
26769
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
26778 is not complex.
26779
26780 Shaun
26781
26782
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>
26788
26789
26790
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>
26796
26797 Hi,
26798
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:
26802
26803 ***************************
26804 -
26805 -NickServ- nick is hello world
26806 -
26807 -NickServ- Is online from: ~test@just.a.test.co.za
26808 -
26809 -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
26810 -
26811 -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
26812 -
26813 -NickServ- Last quit message: anythinggggg
26814 -
26815 -NickServ- Options: Kill protection, Security
26816 -
26817 ***************************
26818
26819 the new line I'm suggesting is something like:
26820
26821 ***************************
26822 -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
26823 ***************************
26824
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).
26830
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)
26834
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)
26837
26838 Many thanks to all of who developed IRCservices ...etc ...etc ...etc
26839
26840 sincerely,
26841 David
26842
26843 _________________________________________________________________
26844 Get MSN 8 and enjoy automatic e-mail virus protection.
26845 http://join.msn.com/?page=features/virus
26846
26847
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>
26855
26856 Or how about rather letting users decide what timezone they're in and
26857 services outputs all timestamps in their local time?
26858
26859
26860 | By us44ever . <us44ever@hotmail.com>
26861 |                                          [ 2003-08-28 18:45 +0200 ]
26862 > Hi,
26863 >
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:
26867 >
26868 > ***************************
26869 > -
26870 > -NickServ- nick is hello world
26871 > -
26872 > -NickServ- Is online from: ~test@just.a.test.co.za
26873 > -
26874 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
26875 > -
26876 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
26877 > -
26878 > -NickServ- Last quit message: anythinggggg
26879 > -
26880 > -NickServ- Options: Kill protection, Security
26881 > -
26882 > ***************************
26883 >
26884 > the new line I'm suggesting is something like:
26885 >
26886 > ***************************
26887 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
26888 > ***************************
26889 >
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).
26895 >
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)
26899 >
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)
26902 >
26903 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
26904 >
26905 > sincerely,
26906 > David
26907 >
26908 > _________________________________________________________________
26909 > Get MSN 8 and enjoy automatic e-mail virus protection.
26910 > http://join.msn.com/?page=features/virus
26911 >
26912 > ------------------------------------------------------------------
26913 > To unsubscribe or change your subscription options, visit:
26914 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
26915
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>
26923
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
26931
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
26937
26938
26939 Or how about rather letting users decide what timezone they're in and
26940 services outputs all timestamps in their local time?
26941
26942
26943 | By us44ever . <us44ever@hotmail.com>
26944 |                                          [ 2003-08-28 18:45 +0200 ]
26945 > Hi,
26946 >
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:
26950 >
26951 > ***************************
26952 > -
26953 > -NickServ- nick is hello world
26954 > -
26955 > -NickServ- Is online from: ~test@just.a.test.co.za
26956 > -
26957 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
26958 > -
26959 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
26960 > -
26961 > -NickServ- Last quit message: anythinggggg
26962 > -
26963 > -NickServ- Options: Kill protection, Security
26964 > -
26965 > ***************************
26966 >
26967 > the new line I'm suggesting is something like:
26968 >
26969 > ***************************
26970 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
26971 > ***************************
26972 >
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).
26978 >
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)
26982 >
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)
26985 >
26986 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
26987 >
26988 > sincerely,
26989 > David
26990 >
26991 > _________________________________________________________________
26992 > Get MSN 8 and enjoy automatic e-mail virus protection.
26993 > http://join.msn.com/?page=features/virus
26994 >
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
27001
27002
27003
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>
27009
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..
27011
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
27014
27015 *shock*
27016
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  ****************************************/
27024
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  ****************************************/
27031
27032 /****** - Begin Original Message - ******/
27033
27034 >Hi,
27035 >
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:
27039 >
27040 >***************************
27041 >-
27042 >-NickServ- nick is hello world
27043 >-
27044 >-NickServ- Is online from: ~test@just.a.test.co.za
27045 >-
27046 >-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
27047 >-
27048 >-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
27049 >-
27050 >-NickServ- Last quit message: anythinggggg
27051 >-
27052 >-NickServ- Options: Kill protection, Security
27053 >-
27054 >***************************
27055 >
27056 >the new line I'm suggesting is something like:
27057 >
27058 >***************************
27059 >-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
27060 >***************************
27061 >
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).
27067 >
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)
27071 >
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)
27074 >
27075 >Many thanks to all of who developed IRCservices ...etc ...etc ...etc
27076 >
27077 >sincerely,
27078 >David
27079 >
27080 >_________________________________________________________________
27081 >Get MSN 8 and enjoy automatic e-mail virus protection.
27082 >http://join.msn.com/?page=features/virus
27083 >
27084 >------------------------------------------------------------------
27085 >To unsubscribe or change your subscription options, visit:
27086 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
27087
27088 /******* - End Original Message - *******/
27089
27090
27091
27092
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>
27098
27099 We're having a small problem with suspended channel.
27100
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.
27103
27104 Also with suspended nick , when the suspencion expire, the services crash
27105 We're using:
27106
27107 ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
27108
27109
27110 Thanks
27111 Marc
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>
27120
27121 hmm.. what OS, compiler version etc are you using?
27122
27123 after a test, i got the following:
27124
27125 /cs id #abc 00376370
27126 -ChanServ- Channel #abc is suspended and may not be used or identified for.
27127
27128 /cs drop #abc
27129 [23:20] -ChanServ- Channel  is suspended and may not be used or identified for.
27130
27131 only prob i got was it missed the channel name in the second message :)
27132
27133 /cs drop #abc
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  ****************************************/
27141
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  ****************************************/
27148
27149 /****** - Begin Original Message - ******/
27150
27151 >We're having a small problem with suspended channel.
27152 >
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.
27155 >
27156 >Also with suspended nick , when the suspencion expire, the services crash
27157 >We're using:
27158 >
27159 >ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
27160 >
27161 >
27162 >Thanks
27163 >Marc
27164 >------------------------------------------------------------------
27165 >To unsubscribe or change your subscription options, visit:
27166 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
27167
27168 /******* - End Original Message - *******/
27169
27170
27171
27172
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>
27179
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...
27184
27185 Just an idea... I now await the half dozen people who will proceed to tell
27186 me how stupid my idea is....
27187
27188 Saturn
27189 irc.jetirc.net
27190
27191
27192
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>
27200
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.
27205
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..
27209 >
27210 > /time services.chatspike.net
27211 > [22:28] ??? Date / time at services.chatspike.net- Thu Aug 28 17:28:57
27212 > 2003 EDT
27213 >
27214 > *shock*
27215 >
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 >  ****************************************/
27223 >
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 >  ****************************************/
27230 >
27231 > /****** - Begin Original Message - ******/
27232 >
27233 >>Hi,
27234 >>
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:
27238 >>
27239 >>***************************
27240 >>-
27241 >>-NickServ- nick is hello world
27242 >>-
27243 >>-NickServ- Is online from: ~test@just.a.test.co.za
27244 >>-
27245 >>-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
27246 >>-
27247 >>-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
27248 >>-
27249 >>-NickServ- Last quit message: anythinggggg
27250 >>-
27251 >>-NickServ- Options: Kill protection, Security
27252 >>-
27253 >>***************************
27254 >>
27255 >>the new line I'm suggesting is something like:
27256 >>
27257 >>***************************
27258 >>-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
27259 >>***************************
27260 >>
27261 >>This will help our users to compare the time that user was last seen and
27262 >> the
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
27266 >> GMT
27267 >>(last seen time was before: 10 days, 3hours and 24 sec ago).
27268 >>
27269 >>Note that I saw both of these features, in other services I don't
27270 >> remember
27271 >>there names (but they aren't as stable as ircservices5) (it was something
27272 >>like ptlink services, and magik II)
27273 >>
27274 >>That's all, I would really like to see it on the next version (or if you
27275 >> can
27276 >>show me how to do it, as I'm not a programmer)
27277 >>
27278 >>Many thanks to all of who developed IRCservices ...etc ...etc ...etc
27279 >>
27280 >>sincerely,
27281 >>David
27282 >>
27283 >>_________________________________________________________________
27284 >>Get MSN 8 and enjoy automatic e-mail virus protection.
27285 >>http://join.msn.com/?page=features/virus
27286 >>
27287 >>------------------------------------------------------------------
27288 >>To unsubscribe or change your subscription options, visit:
27289 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
27290 >
27291 > /******* - End Original Message - *******/
27292 >
27293 >
27294 >
27295 > ------------------------------------------------------------------
27296 > To unsubscribe or change your subscription options, visit:
27297 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
27298 >
27299
27300
27301 --
27302 Best Regards,
27303 playa
27304 Network Founder/CEO
27305 DreamChat IRC Network - irc.dreamchat.org
27306 http://www.dreamchat.org
27307
27308
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>
27315
27316 On Thursday, Aug 28, 2003, at 20:46 US/Pacific, playa wrote:
27317
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.
27322
27323 That's a client thing.  Some clients might alias /time as a CTCP TIME
27324 for a specific user, or similar.
27325
27326 -- Quension
27327
27328
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>
27337
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.
27342
27343 Some clients use stupid aliases for CTCP commands, for example:
27344
27345 /version <nick> = /CTCP <nick> VERSION,
27346 /time <nick> = /CTCP <nick> TIME,
27347 /finger <nick> = /CTCP <nick> TIME
27348
27349 This is why nothing works the way you expected.
27350
27351 --
27352 Krisztian Romek
27353 r-krisztian@softhome.net
27354
27355
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>
27361
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).
27365
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
27369
27370
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>
27376
27377
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.
27383
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
27387
27388
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>
27394
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.
27396
27397 And i'll Quote Elijah:
27398
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
27401 be 'no.'"
27402
27403
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  ****************************************/
27411
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  ****************************************/
27418
27419 /****** - Begin Original Message - ******/
27420
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.
27426 >
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
27430 >
27431 >------------------------------------------------------------------
27432 >To unsubscribe or change your subscription options, visit:
27433 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
27434 >.
27435
27436 /******* - End Original Message - *******/
27437
27438
27439
27440
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>
27446
27447 its a stupid idea!!! :p
27448
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
27450
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  ****************************************/
27458
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  ****************************************/
27465
27466 /****** - Begin Original Message - ******/
27467
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...
27472 >
27473 >Just an idea... I now await the half dozen people who will proceed to tell
27474 >me how stupid my idea is....
27475 >
27476 >Saturn
27477 >irc.jetirc.net
27478 >
27479 >
27480 >------------------------------------------------------------------
27481 >To unsubscribe or change your subscription options, visit:
27482 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
27483
27484 /******* - End Original Message - *******/
27485
27486
27487
27488
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>
27494
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..
27497
27498 or /cs levels #channels DISABLE autoop
27499
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  ****************************************/
27507
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  ****************************************/
27514
27515 /****** - Begin Original Message - ******/
27516
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.
27520 >
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
27529 >is not complex.
27530 >
27531 >Shaun
27532 >
27533 >------------------------------------------------------------------
27534 >To unsubscribe or change your subscription options, visit:
27535 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
27536 >.
27537
27538 /******* - End Original Message - *******/
27539
27540
27541
27542
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>
27550
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..
27553
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.
27556
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
27559
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
27566
27567 Same with ENFORCE set to off as well.
27568
27569 > [snipped obnoxiously long sig]
27570
27571 Shaun Guth
27572
27573
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>
27580
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
27583 >
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
27590
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.
27594
27595   --Andrew Church
27596     achurch@achurch.org
27597     http://achurch.org/
27598
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>
27605
27606 >Can we reconsider adding a Mass memo function for the next release?
27607
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.
27615
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.
27621
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.
27626
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.
27629
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........
27636
27637      This is an interesting thought; I'll think about it for a future
27638 version.
27639
27640   --Andrew Church
27641     achurch@achurch.org
27642     http://achurch.org/
27643
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>
27650
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?
27656
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.
27661
27662   --Andrew Church
27663     achurch@achurch.org
27664     http://achurch.org/
27665
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>
27672
27673 >Is there any tool (silly question) or something or guid to make a language
27674 >file.
27675 >
27676 >I have decided to make a Persian (Farsi) language file.
27677
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.
27682
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.
27685
27686   --Andrew Church
27687     achurch@achurch.org
27688     http://achurch.org/
27689
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>
27696
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
27700
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?
27703
27704   --Andrew Church
27705     achurch@achurch.org
27706     http://achurch.org/
27707
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>
27714
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.
27718
27719      This is a bug in the DROP function, and has been fixed; thanks for the
27720 report.
27721
27722   --Andrew Church
27723     achurch@achurch.org
27724     http://achurch.org/
27725
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>
27732
27733 >[Aug 30 10:56:18 2003] mail/sendmail:
27734 > /usr/sbin/sendmail exited with code 25600
27735
27736      Use the SMTP module instead (mail/smtp).
27737
27738 >[Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
27739 >registration (Simorgh)
27740 >
27741 >and how can I do so that nickserv dont show the realhost of a user in
27742 >'ns info nick all'
27743
27744      It doesn't.  However:
27745
27746 >[Aug 30 10:51:19 2003] unknown message from server
27747 >(:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
27748
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.
27752
27753   --Andrew Church
27754     achurch@achurch.org
27755     http://achurch.org/
27756
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>
27763
27764 >Or how about rather letting users decide what timezone they're in and
27765 >services outputs all timestamps in their local time?
27766
27767 /ns help set timezone (since 5.0 alpha)
27768
27769   --Andrew Church
27770     achurch@achurch.org
27771     http://achurch.org/
27772
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>
27780
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.
27788
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?
27796
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....
27803
27804 Saturn
27805 irc.jetirc.net
27806
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
27812
27813
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...
27816
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.
27820
27821   --Andrew Church
27822     achurch@achurch.org
27823     http://achurch.org/
27824
27825
27826
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>
27835
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.
27845
27846 Erm, what's the argument here?  Services stipulates its timezone in its
27847 timestamps.  As do all the other servers on the network.
27848
27849 Atleast mine do...
27850
27851
27852 Regards,
27853 Aragon
27854
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>
27863
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??
27868
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
27874 suggestion
27875
27876
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
27880 server
27881 > is in a different time zone -- How are users supposed to know what time
27882 zone
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.
27888
27889 Erm, what's the argument here?  Services stipulates its timezone in its
27890 timestamps.  As do all the other servers on the network.
27891
27892 Atleast mine do...
27893
27894
27895 Regards,
27896 Aragon
27897 ------------------------------------------------------------------
27898 To unsubscribe or change your subscription options, visit:
27899 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
27900
27901
27902
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>
27910
27911 On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
27912
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?
27917
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
27921 it back.
27922
27923 >   Why does it all have to be so complicated??
27924
27925 It isn't.  Your users can even use the handy-dandy /nickserv set
27926 timezone command to make it even easier.
27927
27928 > ----- Original Message -----
27929 > From: "Aragon Gouveia" <aragon@phat.za.net>
27930
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.
27941 >
27942 > Erm, what's the argument here?  Services stipulates its timezone in
27943 > its timestamps.  As do all the other servers on the network.
27944
27945 -- Quension
27946
27947
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>
27954
27955
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
27958 seconds ago)
27959 Time registered  : Jul 25 22:19:20 2003 GMT (** days, ** minutes and **
27960 seconds ago)
27961 wouldn't even a greater idea?
27962
27963 _________________________________________________________________
27964 Get MSN 8 and enjoy automatic e-mail virus protection.
27965 http://join.msn.com/?page=features/virus
27966
27967
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>
27975
27976 [16:41] -NickServ-   Time registered: Jul 27 13:09:08 2002 PDT
27977
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....
27986
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
27989 valid ones...
27990
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
27993 codes like PDT)...
27994
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
28001 suggestion
28002
28003
28004 On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
28005
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?
28010
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
28014 it back.
28015
28016 >   Why does it all have to be so complicated??
28017
28018 It isn't.  Your users can even use the handy-dandy /nickserv set
28019 timezone command to make it even easier.
28020
28021 > ----- Original Message -----
28022 > From: "Aragon Gouveia" <aragon@phat.za.net>
28023
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.
28034 >
28035 > Erm, what's the argument here?  Services stipulates its timezone in
28036 > its timestamps.  As do all the other servers on the network.
28037
28038 -- Quension
28039
28040 ------------------------------------------------------------------
28041 To unsubscribe or change your subscription options, visit:
28042 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
28043
28044
28045
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>
28053
28054 On Sunday, Aug 31, 2003, at 16:47 US/Pacific, Saturn wrote:
28055
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)...
28059
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.
28063
28064 -- Quension
28065
28066
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>
28074
28075      "Use /ns set timezone" is the official answer on this.  Please take
28076 all further discussion to the ircservices list.
28077
28078   --Andrew Church
28079     achurch@achurch.org
28080     http://achurch.org/
28081
28082 >[16:41] -NickServ-   Time registered: Jul 27 13:09:08 2002 PDT
28083 >
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....
28092 >
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
28095 >valid ones...
28096 >
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)...
28100 >
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
28107 >suggestion
28108 >
28109 >
28110 >On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
28111 >
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?
28116 >
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
28120 >it back.
28121 >
28122 >>   Why does it all have to be so complicated??
28123 >
28124 >It isn't.  Your users can even use the handy-dandy /nickserv set
28125 >timezone command to make it even easier.
28126 >
28127 >> ----- Original Message -----
28128 >> From: "Aragon Gouveia" <aragon@phat.za.net>
28129 >
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.
28140 >>
28141 >> Erm, what's the argument here?  Services stipulates its timezone in
28142 >> its timestamps.  As do all the other servers on the network.
28143 >
28144 >-- Quension
28145 >
28146 >------------------------------------------------------------------
28147 >To unsubscribe or change your subscription options, visit:
28148 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
28149 >
28150 >
28151 >------------------------------------------------------------------
28152 >To unsubscribe or change your subscription options, visit:
28153 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
28154
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>
28161
28162 Thanks for your help.
28163
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
28168            Is online from: %s
28169 to:
28170 NICK_INFO_ADDRESS_ONLINE
28171            Is online from: N/A ?
28172
28173
28174                            Ali "Simorgh"
28175  ______________________________________________________
28176  Many of life's failures are people who did not realize
28177  how close they were to success when they gave up.
28178  Thomas A. Edison
28179  ______________________________________________________
28180
28181
28182 On Mon, 1 Sep 2003, Andrew Church wrote:
28183
28184 > >[Aug 30 10:56:18 2003] mail/sendmail:
28185 > > /usr/sbin/sendmail exited with code 25600
28186 >
28187 >      Use the SMTP module instead (mail/smtp).
28188 >
28189 > >[Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
28190 > >registration (Simorgh)
28191 > >
28192 > >and how can I do so that nickserv dont show the realhost of a user in
28193 > >'ns info nick all'
28194 >
28195 >      It doesn't.  However:
28196 >
28197 > >[Aug 30 10:51:19 2003] unknown message from server
28198 > >(:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
28199 >
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.
28203 >
28204 >   --Andrew Church
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
28210 >
28211
28212
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>
28219
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
28222
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.
28227
28228   --Andrew Church
28229     achurch@achurch.org
28230     http://achurch.org/
28231
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>
28237
28238 Hi all,
28239
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.
28243
28244 Regards
28245
28246 alex
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>
28257
28258 Hello,
28259
28260 alex wrote:
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.
28264
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
28268 computer.
28269
28270 --
28271 Krisztian Romek
28272 r-krisztian@softhome.net
28273
28274
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>
28280
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.
28282
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.
28284
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  ****************************************/
28292
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  ****************************************/
28299
28300 /****** - Begin Original Message - ******/
28301
28302 >Hi all,
28303 >
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.
28307 >
28308 >Regards
28309 >
28310 >alex
28311 >------------------------------------------------------------------
28312 >To unsubscribe or change your subscription options, visit:
28313 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
28314
28315 /******* - End Original Message - *******/
28316
28317
28318
28319
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>
28325
28326 It wasn't an easy subject to sum up in just a few words.
28327
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
28340 send.c
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
28344 all the
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)
28356
28357 Thanks
28358
28359 Brent
28360
28361
28362
28363 ----------------------------------------------------------
28364 |               Brent DiNicola                                  |
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 -----------------------------------------------------------
28371
28372
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>
28378
28379 lol, Our help no good? :P
28380
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..
28382
28383 Dont ask me for source on this.. i'm just theorising :)
28384
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  ****************************************/
28392
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  ****************************************/
28399
28400 /****** - Begin Original Message - ******/
28401
28402 >It wasn't an easy subject to sum up in just a few words.
28403 >
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
28416 >send.c
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
28420 >all the
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)
28432 >
28433 >Thanks
28434 >
28435 >Brent
28436 >
28437 >
28438 >
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 >-----------------------------------------------------------
28447 >
28448 >------------------------------------------------------------------
28449 >To unsubscribe or change your subscription options, visit:
28450 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
28451 >.
28452
28453 /******* - End Original Message - *******/
28454
28455
28456
28457
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>
28465
28466 Hello;
28467
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.
28477
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.
28492 ...
28493
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.
28497
28498 To your case.
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.
28502
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
28505 trivial.
28506
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
28510 closed.
28511
28512 Do keep in mind that requesting support for modified services versions
28513 are subject to be ignored.
28514
28515 I hope it helps,
28516 yusuf
28517
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.
28520 >
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
28533 > send.c
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
28537 > all the
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)
28549 >
28550 > Thanks
28551 >
28552 > Brent
28553 >
28554 >
28555 >
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 > -----------------------------------------------------------
28564 >
28565 > ------------------------------------------------------------------
28566 > To unsubscribe or change your subscription options, visit:
28567 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
28568 --
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 ------------------------------------------------------------------
28575
28576
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>
28583
28584 Brent DiNicola wrote:
28585
28586 > It wasn't an easy subject to sum up in just a few words.
28587 >
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
28593 > the users
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
28596 > NOTICE
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
28599 > the best
28600 > way to go about this without causing trouble for me and anyone else
28601 > who has
28602 > to deal with this code. Is it possible or even suggested to make a
28603 > module that
28604 > would replace the notice() from send.c with it's own, leaving the code
28605 > in send.c
28606 > alone and not causing troubles down the road. Suggestions were that I
28607 > make a
28608 > module that kept the info for each nick's setting and then if I could
28609 > override
28610 > the notice() and notice_lang() and notice_help() in send.c that would
28611 > keep all the
28612 > other code clean and not cause other troubles. I want to know what the
28613 > best
28614 > way to do this would be, I know it's against RFC but I want to move to
28615 > newer
28616 > services than the 1.4.3pre4 that we are using now and add modules so
28617 > that I
28618 > can do things down the line. They are used to having PRIVMSG and I
28619 > can't just
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
28622 > this? I
28623 > know this topic has been asked before and I know your not going to
28624 > make it
28625 > part of your code, I just wanted to know from the people who know the
28626 > code
28627 > really well what the best route to take would be to do the least
28628 > amount of
28629 > damage. (And if someone has done this.. please let me know what you did,
28630 > examples would rock)
28631 >
28632 > Thanks
28633 >
28634 > Brent
28635 >
28636 >
28637 >
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
28649 >
28650 >
28651
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
28656
28657 services is the wrong thing to change
28658
28659
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>
28665
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
28667
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  ****************************************/
28675
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  ****************************************/
28682
28683 /****** - Begin Original Message - ******/
28684
28685 >Brent DiNicola wrote:
28686 >
28687 >> It wasn't an easy subject to sum up in just a few words.
28688 >>
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
28694 >> the users
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
28697 >> NOTICE
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
28700 >> the best
28701 >> way to go about this without causing trouble for me and anyone else
28702 >> who has
28703 >> to deal with this code. Is it possible or even suggested to make a
28704 >> module that
28705 >> would replace the notice() from send.c with it's own, leaving the code
28706 >> in send.c
28707 >> alone and not causing troubles down the road. Suggestions were that I
28708 >> make a
28709 >> module that kept the info for each nick's setting and then if I could
28710 >> override
28711 >> the notice() and notice_lang() and notice_help() in send.c that would
28712 >> keep all the
28713 >> other code clean and not cause other troubles. I want to know what the
28714 >> best
28715 >> way to do this would be, I know it's against RFC but I want to move to
28716 >> newer
28717 >> services than the 1.4.3pre4 that we are using now and add modules so
28718 >> that I
28719 >> can do things down the line. They are used to having PRIVMSG and I
28720 >> can't just
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
28723 >> this? I
28724 >> know this topic has been asked before and I know your not going to
28725 >> make it
28726 >> part of your code, I just wanted to know from the people who know the
28727 >> code
28728 >> really well what the best route to take would be to do the least
28729 >> amount of
28730 >> damage. (And if someone has done this.. please let me know what you did,
28731 >> examples would rock)
28732 >>
28733 >> Thanks
28734 >>
28735 >> Brent
28736 >>
28737 >>
28738 >>
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
28750 >>
28751 >>
28752 >
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
28757 >
28758 >services is the wrong thing to change
28759 >
28760 >------------------------------------------------------------------
28761 >To unsubscribe or change your subscription options, visit:
28762 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
28763 >.
28764
28765 /******* - End Original Message - *******/
28766
28767
28768
28769
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>
28776
28777 On Thursday, Sep 4, 2003, at 13:29 US/Pacific, Robert F Merrill wrote:
28778
28779 > Brent DiNicola wrote:
28780 >
28781 >> It wasn't an easy subject to sum up in just a few words.
28782
28783 [...]
28784
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
28789 >
28790 > services is the wrong thing to change
28791
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.
28795
28796 This is the coding list, not the feature request list.  He asked for
28797 code design approaches, not for political insight.
28798
28799 -- Quension
28800
28801
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>
28807
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
28813
28814 Thanks for all
28815
28816 Diego B. Contezini
28817
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..
28823
28824
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
28830 get
28831 > a core.
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
28834 break
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.
28839 >
28840 > Thanks for all
28841 >
28842 > Diego B. Contezini aka destruct_ | irc.redesul.net
28843 > (Sorry for my confuse english.)
28844 >
28845
28846
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>
28853
28854 Hello, im destruct_, im the administrator of the RedeSul Network.
28855 (irc.redesul.net).
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
28859 a core.
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.
28866
28867 Thanks for all
28868
28869 Diego B. Contezini aka destruct_ | irc.redesul.net
28870 (Sorry for my confuse english.)
28871
28872
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>
28878
28879 Hi All
28880
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
28892
28893 many thanks
28894 Engin
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>
28903
28904 make sure you are on the services administrator list, if you are not, get the root administrator to add you using the command:
28905
28906 [22:27] -OperServ- Syntax: ADMIN ADD nickname
28907 [22:27] -OperServ- ADMIN DEL nickname
28908 [22:27] -OperServ- ADMIN LIST
28909 [22:27] -OperServ-
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.
28914 [22:27] -OperServ-
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.
28917
28918
28919
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  ****************************************/
28927
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  ****************************************/
28934
28935 /****** - Begin Original Message - ******/
28936
28937 >Hi All
28938 >
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
28950 >
28951 >many thanks
28952 >Engin
28953 >------------------------------------------------------------------
28954 >To unsubscribe or change your subscription options, visit:
28955 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
28956
28957 /******* - End Original Message - *******/
28958
28959
28960
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>
28967
28968 Contact me directly... I have quite a bit of experience with unreal and these services...
28969
28970 Saturn
28971 irc.jetirc.net
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
28977
28978
28979   Hi All
28980
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
28992
28993   many thanks
28994   Engin
28995
28996
28997
28998 ------------------------------------------------------------------------------
28999
29000
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>
29013
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....
29016
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
29023
29024
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:
29027
29028 [22:27] -OperServ- Syntax: ADMIN ADD nickname
29029 [22:27] -OperServ- ADMIN DEL nickname
29030 [22:27] -OperServ- ADMIN LIST
29031 [22:27] -OperServ-
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.
29036 [22:27] -OperServ-
29037 [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
29038 command.
29039 [22:27] -OperServ- All other use limited to Services super-user.
29040
29041
29042
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  ****************************************/
29050
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  ****************************************/
29057
29058 /****** - Begin Original Message - ******/
29059
29060 >Hi All
29061 >
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
29073 >
29074 >many thanks
29075 >Engin
29076 >------------------------------------------------------------------
29077 >To unsubscribe or change your subscription options, visit:
29078 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
29079
29080 /******* - End Original Message - *******/
29081
29082
29083 ------------------------------------------------------------------
29084 To unsubscribe or change your subscription options, visit:
29085 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
29086
29087
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>
29094
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
29097 one
29098
29099 cheers
29100 Engin
29101
29102
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
29108
29109
29110 > Send IRCServices-Coding mailing list submissions to
29111 > ircservices-coding@ircservices.za.net
29112 >
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
29117 >
29118 > You can reach the person managing the list at
29119 > ircservices-coding-owner@ircservices.za.net
29120 >
29121 > When replying, please edit your Subject line so it is more specific
29122 > than "Re: Contents of IRCServices-Coding digest..."
29123 >
29124 >
29125 > Today's Topics:
29126 >
29127 >    1. operserv (engin@piratetv)
29128 >    2. Re: operserv (Craig McLure)
29129 >    3. Re: operserv (Saturn)
29130 >    4. Re: operserv (Saturn)
29131 >
29132 >
29133 > ----------------------------------------------------------------------
29134 >
29135 > Message: 1
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"
29142 >
29143 > Hi All
29144 >
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
29156 >
29157 > many thanks
29158 > Engin
29159 > -------------- next part --------------
29160 > An HTML attachment was scrubbed...
29161 > URL:
29162 http://snow.fingers.co.za/pipermail/ircservices-coding/attachments/20030921/
29163 fdc12b4e/attachment-0001.htm
29164 >
29165 > ------------------------------
29166 >
29167 > Message: 2
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"
29175 >
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:
29178 >
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
29184 nicknames
29185 > [22:27] -OperServ- to or from the Services admin list. A user whose
29186 nickname
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
29189 commands.
29190 > [22:27] -OperServ-
29191 > [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
29192 command.
29193 > [22:27] -OperServ- All other use limited to Services super-user.
29194 >
29195 >
29196 >
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 >  ****************************************/
29204 >
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 >  ****************************************/
29211 >
29212 > /****** - Begin Original Message - ******/
29213 >
29214 > >Hi All
29215 > >
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
29227 > >
29228 > >many thanks
29229 > >Engin
29230 > >------------------------------------------------------------------
29231 > >To unsubscribe or change your subscription options, visit:
29232 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
29233 >
29234 > /******* - End Original Message - *******/
29235 >
29236 >
29237 >
29238 > ------------------------------
29239 >
29240 > Message: 3
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"
29248 >
29249 > Contact me directly... I have quite a bit of experience with unreal and
29250 these services...
29251 >
29252 > Saturn
29253 > irc.jetirc.net
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
29259 >
29260 >
29261 >   Hi All
29262 >
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
29265 mailing
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
29275 >
29276 >   many thanks
29277 >   Engin
29278 >
29279 >
29280 >
29281 > --------------------------------------------------------------------------
29282 ----
29283 >
29284 >
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...
29290 > URL:
29291 http://snow.fingers.co.za/pipermail/ircservices-coding/attachments/20030921/
29292 ca188e06/attachment-0001.htm
29293 >
29294 > ------------------------------
29295 >
29296 > Message: 4
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"
29304 >
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
29307 denied....
29308 >
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
29315 >
29316 >
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:
29319 >
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
29325 nicknames
29326 > [22:27] -OperServ- to or from the Services admin list. A user whose
29327 nickname
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
29330 commands.
29331 > [22:27] -OperServ-
29332 > [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
29333 > command.
29334 > [22:27] -OperServ- All other use limited to Services super-user.
29335 >
29336 >
29337 >
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 >  ****************************************/
29345 >
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 >  ****************************************/
29352 >
29353 > /****** - Begin Original Message - ******/
29354 >
29355 > >Hi All
29356 > >
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
29368 > >
29369 > >many thanks
29370 > >Engin
29371 > >------------------------------------------------------------------
29372 > >To unsubscribe or change your subscription options, visit:
29373 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
29374 >
29375 > /******* - End Original Message - *******/
29376 >
29377 >
29378 > ------------------------------------------------------------------
29379 > To unsubscribe or change your subscription options, visit:
29380 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
29381 >
29382 >
29383 > ------------------------------
29384 >
29385 > _______________________________________________
29386 > IRCServices-Coding mailing list
29387 > IRCServices-Coding@ircservices.za.net
29388 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
29389 >
29390 >
29391 > End of IRCServices-Coding Digest, Vol 8, Issue 5
29392 > ************************************************
29393
29394
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>
29402
29403 Sometimes has occur this bug, last 1 year....
29404 on a network with 30k registers, its happening with latency of 3.. 4
29405 days....
29406
29407 someone have any idea?
29408
29409 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
29410 av=0xbfffeec8) at channels.c:278
29411 278         while (*s) {
29412 (gdb) bt'
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>
29417         add = 1
29418         modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
29419 #1  0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:680
29420         buf =
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
29432 bounds>,
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@`???"}
29436         len = 4
29437         i = 0
29438         lastc = 45 '-'
29439 #2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
29440         args = 0x0
29441         modes = 0x0
29442         modes_orig = 0x0
29443         md = (struct modedata *) 0x0
29444         which = -1
29445         add = 0
29446         i = 0
29447         c = 0 '\0'
29448 #3  0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at main.c:269
29449         now = 1065393142
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.
29455 (gdb)
29456
29457
29458
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>
29465
29466 Upgrade.
29467
29468   --Andrew Church
29469     achurch@achurch.org
29470     http://achurch.org/
29471
29472 >Sometimes has occur this bug, last 1 year....
29473 >on a network with 30k registers, its happening with latency of 3.. 4
29474 >days....
29475 >
29476 >someone have any idea?
29477 >
29478 >#0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
29479 >av=0xbfffeec8) at channels.c:278
29480 >278         while (*s) {
29481 >(gdb) bt'
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>
29486 >        add = 1
29487 >        modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
29488 >#1  0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:68
29489 >0
29490 >        buf =
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ï¿½ï¿½ï¿½ï¿
29494 >½
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\
29499 >000\000\0
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�
29505 >���\027\000\0
29506 >00\000\000\000\000\000\024\032"...
29507 >        s = 0xbfffeef0 "-isl"
29508 >        argv = {0xa97b6c0 "#young", 0x20656c62 <Address 0x20656c62 out
29509 >of
29510 >bounds>,
29511 >  0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 o
29512 >ut
29513 >of bounds>, 0x42133cec "\004", 0xbffff1fc "",
29514 >  0x4204533d "\201���\016", 0x42131a14 " \031\023
29515 >B�h\001@`�"}
29516 >        len = 4
29517 >        i = 0
29518 >        lastc = 45 '-'
29519 >#2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:32
29520 >1
29521 >        args = 0x0
29522 >        modes = 0x0
29523 >        modes_orig = 0x0
29524 >        md = (struct modedata *) 0x0
29525 >        which = -1
29526 >        add = 0
29527 >        i = 0
29528 >        c = 0 '\0'
29529 >#3  0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at ma
29530 >in.c:269
29531 >        now = 1065393142
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.
29537 >(gdb)
29538 >
29539 >
29540 >------------------------------------------------------------------
29541 >To unsubscribe or change your subscription options, visit:
29542 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
29543
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>
29550
29551 Upgrade?
29552 ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
29553 18:41:36 BRT 2003
29554 -
29555
29556 Its the last version.......
29557
29558 Diego B. Contezini
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....
29564
29565
29566 > Upgrade.
29567 >
29568 >   --Andrew Church
29569 >     achurch@achurch.org
29570 >     http://achurch.org/
29571 >
29572 > >Sometimes has occur this bug, last 1 year....
29573 > >on a network with 30k registers, its happening with latency of 3.. 4
29574 > >days....
29575 > >
29576 > >someone have any idea?
29577 > >
29578 > >#0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
29579 > >av=0xbfffeec8) at channels.c:278
29580 > >278         while (*s) {
29581 > >(gdb) bt'
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>
29586 > >        add = 1
29587 > >        modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
29588 > >#1  0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:68
29589 > >0
29590 > >        buf =
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???????????
29594 > >?
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\
29599 > >000\000\0
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
29609 > >of
29610 > >bounds>,
29611 > >  0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 o
29612 > >ut
29613 > >of bounds>, 0x42133cec "\004", 0xbffff1fc "",
29614 > >  0x4204533d "\201?????????\016", 0x42131a14 " \031\023
29615 > >B???h\001@`???"}
29616 > >        len = 4
29617 > >        i = 0
29618 > >        lastc = 45 '-'
29619 > >#2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:32
29620 > >1
29621 > >        args = 0x0
29622 > >        modes = 0x0
29623 > >        modes_orig = 0x0
29624 > >        md = (struct modedata *) 0x0
29625 > >        which = -1
29626 > >        add = 0
29627 > >        i = 0
29628 > >        c = 0 '\0'
29629 > >#3  0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at ma
29630 > >in.c:269
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.
29637 > >(gdb)
29638 > >
29639 > >
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
29646 >
29647
29648
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>
29655
29656 >Upgrade?
29657 >ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
29658 >18:41:36 BRT 2003
29659 >-
29660 >
29661 >Its the last version.......
29662
29663      Then send a full debug log (from startup to crash), or I can't help.
29664
29665   --Andrew Church
29666     achurch@achurch.org
29667     http://achurch.org/
29668
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>
29675
29676 And how should be this log? i sent a backtrace......
29677
29678 Diego B. Contezini
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....
29684
29685
29686 > >Upgrade?
29687 > >ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
29688 > >18:41:36 BRT 2003
29689 > >-
29690 > >
29691 > >Its the last version.......
29692 >
29693 >      Then send a full debug log (from startup to crash), or I can't help.
29694 >
29695 >   --Andrew Church
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
29701 >
29702
29703
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>
29710
29711 >And how should be this log? i sent a backtrace......
29712
29713 RTFM (FAQ Z.3)
29714
29715   --Andrew Church
29716     achurch@achurch.org
29717     http://achurch.org/
29718
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>
29725
29726 Read....
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
29729 nofork.....
29730
29731 Cya
29732 Diego B. Contezini
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....
29738
29739
29740 > >And how should be this log? i sent a backtrace......
29741 >
29742 > RTFM (FAQ Z.3)
29743 >
29744 >   --Andrew Church
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
29750 >
29751
29752
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>
29759
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).
29762
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...
29769
29770 First: IS that what it's supposed to do?
29771
29772 Second: If so, it's not working...
29773
29774 Saturn
29775 www.jetirc.net
29776
29777
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>
29784
29785
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.
29789
29790 I copy the sintaz of mail-auth ( it's in italian )
29791
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:
29800             /msg %s AUTH %09d
29801
29802         La registrazione del tuo nick sara' confermata e il tuo nickname
29803         sara' protetto da eventuali tentativi di abuso o furto.
29804
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.
29808
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.
29812
29813
29814         Sono inoltre disponibili i seguenti servizi:
29815
29816         - MusiChat Forum
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.
29822
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.
29828
29829
29830         Per una connessione piu' veloce e sicura e' vivamente
29831         consigliato l'utilizzo del seguente server: irc.musichat.net
29832
29833         MusiChat Net Community
29834
29835         Questo messaggio e stato inviato su richiesta di %s in risposta a %s
29836         %s@%s.
29837
29838
29839
29840
29841 I read the istruction for translate.
29842
29843 The error is:
29844
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
29848
29849
29850 Some one can help me?
29851 the email body is too long?
29852
29853 Thx
29854
29855 Alex
29856
29857
29858
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>
29865
29866      You have the wrong number of %-tokens in your message.
29867
29868   --Andrew Church
29869     achurch@achurch.org
29870     http://achurch.org/
29871
29872 >
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.
29876 >
29877 >I copy the sintaz of mail-auth ( it's in italian )
29878 >
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
29888 >
29889 >        La registrazione del tuo nick sara' confermata e il tuo nickname
29890 >        sara' protetto da eventuali tentativi di abuso o furto.
29891 >
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.
29895 >
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.
29899 >
29900 >
29901 >        Sono inoltre disponibili i seguenti servizi:
29902 >
29903 >        - MusiChat Forum
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.
29909 >
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.
29915 >
29916 >
29917 >        Per una connessione piu' veloce e sicura e' vivamente
29918 >        consigliato l'utilizzo del seguente server: irc.musichat.net
29919 >
29920 >        MusiChat Net Community
29921 >
29922 >        Questo messaggio e stato inviato su richiesta di %s in risposta a %s
29923 >        %s@%s.
29924 >
29925 >
29926 >
29927 >
29928 >I read the istruction for translate.
29929 >
29930 >The error is:
29931 >
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
29935 >
29936 >
29937 >Some one can help me?
29938 >the email body is too long?
29939 >
29940 >Thx
29941 >
29942 >Alex
29943 >
29944 >
29945 >------------------------------------------------------------------
29946 >To unsubscribe or change your subscription options, visit:
29947 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
29948
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>
29954
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 ?
29963
29964 ######################################################
29965 modules/chanserv/check.c
29966 ...
29967 void check_chan_user_modes(const char *source, struct c_userlist *u,
29968                            Channel *c, int32 oldmodes)
29969 ...
29970         if ((res & ~modes) & CUMODE_o) {
29971             ci->last_used = time(NULL);
29972             put_channelinfo(ci);
29973         }
29974 ...
29975 ######################################################
29976
29977 |SaMaN|
29978
29979
29980
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>
29986
29987 Also it does not update last_used time on +a flag.
29988
29989 Temporary fix
29990 ---------------
29991
29992 edit /modules/chanserv/check.c
29993
29994 find line
29995 -------------------------------------------------------------------------
29996         local_set_cumodes(c, '+', res & ~modes, user->nick);
29997 -------------------------------------------------------------------------
29998 add below
29999 ------------------------------------------------------------------------
30000         int16 cumode_q = mode_char_to_flag('q',MODE_CHANUSER);
30001         int16 cumode_a = mode_char_to_flag('a',MODE_CHANUSER);
30002
30003         if ((res & ~modes) & cumode_q) {
30004             ci->last_used = time(NULL);
30005             put_channelinfo(ci);
30006         }
30007
30008         if ((res & ~modes) & cumode_a) {
30009             ci->last_used = time(NULL);
30010             put_channelinfo(ci);
30011         }
30012 -------------------------------------------------------------------------
30013 save and compile and run and enjoy :)
30014 -------------------------------------------------------------------------
30015
30016 |SaMaN|
30017
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 ?
30023
30024
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
30029 mode:
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
30032 to
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 ?
30035 >
30036 > ######################################################
30037 > modules/chanserv/check.c
30038 > ...
30039 > void check_chan_user_modes(const char *source, struct c_userlist *u,
30040 >                            Channel *c, int32 oldmodes)
30041 > ...
30042 >         if ((res & ~modes) & CUMODE_o) {
30043 >             ci->last_used = time(NULL);
30044 >             put_channelinfo(ci);
30045 >         }
30046 > ...
30047 > ######################################################
30048 >
30049 > |SaMaN|
30050 >
30051 >
30052
30053
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>
30059
30060 Haven't seen a reply to this one, so thought I'd better make sure this went
30061 through....
30062
30063 ----- Original Message -----
30064 Sent: Friday, October 10, 2003 3:48 PM
30065 Subject: Akill problem in 5.0.22
30066
30067
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).
30070
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...
30077
30078 First: IS that what it's supposed to do?
30079
30080 Second: If so, it's not working...
30081
30082 Saturn
30083 www.jetirc.net
30084
30085
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>
30092
30093 RTFM
30094
30095   --Andrew Church
30096     achurch@achurch.org
30097     http://achurch.org/
30098
30099 >Haven't seen a reply to this one, so thought I'd better make sure this went
30100 >through....
30101 >
30102 >----- Original Message -----
30103 >Sent: Friday, October 10, 2003 3:48 PM
30104 >Subject: Akill problem in 5.0.22
30105 >
30106 >
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).
30109 >
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...
30116 >
30117 >First: IS that what it's supposed to do?
30118 >
30119 >Second: If so, it's not working...
30120 >
30121 >Saturn
30122 >www.jetirc.net
30123 >
30124 >------------------------------------------------------------------
30125 >To unsubscribe or change your subscription options, visit:
30126 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
30127
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>
30134
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
30137
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
30141 it first.
30142     Example: ImmediatelySendAutokill
30143
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
30149 kill them.
30150
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?
30155
30156 Thanks
30157 Saturn
30158
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
30164
30165
30166 RTFM
30167
30168   --Andrew Church
30169     achurch@achurch.org
30170     http://achurch.org/
30171
30172 >Haven't seen a reply to this one, so thought I'd better make sure this went
30173 >through....
30174 >
30175 >----- Original Message -----
30176 >Sent: Friday, October 10, 2003 3:48 PM
30177 >Subject: Akill problem in 5.0.22
30178 >
30179 >
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).
30182 >
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
30185 scanning
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...
30190 >
30191 >First: IS that what it's supposed to do?
30192 >
30193 >Second: If so, it's not working...
30194 >
30195 >Saturn
30196 >www.jetirc.net
30197 >
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
30204
30205
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>
30212
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
30217 >kill them.
30218
30219      The documentation says nothing about this.  RTFM again.
30220
30221   --Andrew Church
30222     achurch@achurch.org
30223     http://achurch.org/
30224
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>
30232
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
30238 to deal with it.
30239
30240 Ballsy
30241
30242
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
30246 >
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
30250 >it first.
30251 >     Example: ImmediatelySendAutokill
30252 >
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
30258 >kill them.
30259 >
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?
30264 >
30265 >Thanks
30266 >Saturn
30267 >
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
30273 >
30274 >
30275 >RTFM
30276 >
30277 >   --Andrew Church
30278 >     achurch@achurch.org
30279 >     http://achurch.org/
30280 >
30281 > >Haven't seen a reply to this one, so thought I'd better make sure this went
30282 > >through....
30283 > >
30284 > >----- Original Message -----
30285 > >Sent: Friday, October 10, 2003 3:48 PM
30286 > >Subject: Akill problem in 5.0.22
30287 > >
30288 > >
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).
30291 > >
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
30294 >scanning
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...
30299 > >
30300 > >First: IS that what it's supposed to do?
30301 > >
30302 > >Second: If so, it's not working...
30303 > >
30304 > >Saturn
30305 > >www.jetirc.net
30306 > >
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
30313 >
30314 >------------------------------------------------------------------
30315 >To unsubscribe or change your subscription options, visit:
30316 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
30317
30318
30319
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>
30326
30327 >From a.html in the /docs directory:
30328 ---------------
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
30333 it first.
30334     Example: ImmediatelySendAutokill
30335 --------------
30336
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 ------------------------
30351
30352 4.html#oper.akill doesn't mention it at all.
30353
30354 -----------------
30355
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!!!
30363
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?
30369
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???????
30376
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.
30386
30387 Saturn
30388
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
30394
30395
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
30400 >kill them.
30401
30402      The documentation says nothing about this.  RTFM again.
30403
30404   --Andrew Church
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
30410
30411
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>
30419
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.
30427
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
30434 programming...
30435
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
30443
30444
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
30450 to deal with it.
30451
30452 Ballsy
30453
30454
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
30458 >
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
30462 >it first.
30463 >     Example: ImmediatelySendAutokill
30464 >
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
30470 >kill them.
30471 >
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?
30476 >
30477 >Thanks
30478 >Saturn
30479 >
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
30485 >
30486 >
30487 >RTFM
30488 >
30489 >   --Andrew Church
30490 >     achurch@achurch.org
30491 >     http://achurch.org/
30492 >
30493 > >Haven't seen a reply to this one, so thought I'd better make sure this
30494 went
30495 > >through....
30496 > >
30497 > >----- Original Message -----
30498 > >Sent: Friday, October 10, 2003 3:48 PM
30499 > >Subject: Akill problem in 5.0.22
30500 > >
30501 > >
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).
30504 > >
30505 > >I just today added an akill (+0 time) .. I DO have the immediate auto
30506 kill
30507 > >option un-commented in the modules.conf, but it still didn't bother
30508 >scanning
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
30511 thought
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...
30514 > >
30515 > >First: IS that what it's supposed to do?
30516 > >
30517 > >Second: If so, it's not working...
30518 > >
30519 > >Saturn
30520 > >www.jetirc.net
30521 > >
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
30528 >
30529 >------------------------------------------------------------------
30530 >To unsubscribe or change your subscription options, visit:
30531 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
30532
30533
30534 ------------------------------------------------------------------
30535 To unsubscribe or change your subscription options, visit:
30536 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
30537
30538
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>
30544
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.
30546
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
30548
30549 Please just calm down, and talk this out rationally before you start jumping down ppls throats :p
30550
30551 /*****************************************
30552  *     Craig "FrostyCoolSlug" McLure
30553  * InspIRCd   - http://www.inspircd.org
30554  * ChatSpike  - http://www.chatspike.net
30555  ****************************************/
30556
30557
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  ****************************************/
30564
30565 /****** - Begin Original Message - ******/
30566
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.
30574 >
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
30581 >programming...
30582 >
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
30590 >
30591 >
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
30597 >to deal with it.
30598 >
30599 >Ballsy
30600 >
30601 >
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
30605 >>
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
30609 >>it first.
30610 >>     Example: ImmediatelySendAutokill
30611 >>
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
30617 >>kill them.
30618 >>
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?
30623 >>
30624 >>Thanks
30625 >>Saturn
30626 >>
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
30632 >>
30633 >>
30634 >>RTFM
30635 >>
30636 >>   --Andrew Church
30637 >>     achurch@achurch.org
30638 >>     http://achurch.org/
30639 >>
30640 >> >Haven't seen a reply to this one, so thought I'd better make sure this
30641 >went
30642 >> >through....
30643 >> >
30644 >> >----- Original Message -----
30645 >> >Sent: Friday, October 10, 2003 3:48 PM
30646 >> >Subject: Akill problem in 5.0.22
30647 >> >
30648 >> >
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).
30651 >> >
30652 >> >I just today added an akill (+0 time) .. I DO have the immediate auto
30653 >kill
30654 >> >option un-commented in the modules.conf, but it still didn't bother
30655 >>scanning
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
30658 >thought
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...
30661 >> >
30662 >> >First: IS that what it's supposed to do?
30663 >> >
30664 >> >Second: If so, it's not working...
30665 >> >
30666 >> >Saturn
30667 >> >www.jetirc.net
30668 >> >
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
30675 >>
30676 >>------------------------------------------------------------------
30677 >>To unsubscribe or change your subscription options, visit:
30678 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
30679 >
30680 >
30681 >------------------------------------------------------------------
30682 >To unsubscribe or change your subscription options, visit:
30683 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
30684 >
30685 >------------------------------------------------------------------
30686 >To unsubscribe or change your subscription options, visit:
30687 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
30688 >
30689 >.
30690
30691 /******* - End Original Message - *******/
30692
30693
30694
30695
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>
30702
30703      You know, I might have been more forgiving if this hadn't been gone
30704 over on this list (twice!) before:
30705
30706 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/002305.html
30707 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/003215.html
30708
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
30711 edification:
30712
30713 F.10. Services doesn't kill users matching a newly-added autokill mask even
30714 if ImmediatelySendAutokill is set.
30715
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.
30722
30723         Note that some IRC servers will themselves kill users matching a
30724         newly-added autokill; this is unrelated to Services.
30725
30726   --Andrew Church
30727     achurch@achurch.org
30728     http://achurch.org/
30729
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>
30739
30740 Saturn wrote:
30741
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.
30749 >
30750 >
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
30757 do this.
30758
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).
30763
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.
30767
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.
30775
30776
30777
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>
30786
30787 On Saturday 18 October 2003 07:20, Robert F Merrill wrote:
30788 > Saturn 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.
30796 >
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
30803 > do this.
30804
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.
30807
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.
30812
30813 <<V13>>
30814
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>
30821
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)
30832
30833 root@irc(/home/ircadmin/services/lib)# ls -la core.12631
30834 -rw-------    1 ircadmin ircadmin 47374336 Oct 18 16:05 core.12631
30835
30836
30837 continue on the next message......
30838
30839
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>
30846
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;
30851 (gdb) bt'
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
30855         s = 0x806aa3e ""
30856 #1  0x0804d342 in set_cmode (sender=0x81db058 "ChanServ", channel=0xa905d00)
30857 at actions.c:446
30858         parambuf =
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"...
30867         len = 10
30868         flag = 1
30869         params = 1
30870         is_chanuser = 1
30871         args = 0xbfffe6d0 "RDcoCOREcorei??i??i??i??o"
30872         modes = 0xbfffeae2 ""
30873         modes_orig = 0xbfffeae0 "+o"
30874         md = (struct modedata *) 0x806aa00
30875         which = 0
30876         add = 1
30877         i = 1
30878         c = 111 'o'
30879 #2  0x400895ff in local_set_cumodes (c=0xa905d00, plusminus=43 '+', modes=1,
30880 nick=0xab7f2e8 "balsanelli") at check.c:432
30881         buf = "+o"
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).."...
30886         s = 0xbfffe6e1 ""
30887 #3  0x40088d74 in check_chan_user_modes (source=0xbfffeed0 "|-Frango-|",
30888 u=0xab34ff0, c=0xa905d00, oldmodes=1)
30889     at check.c:214
30890         user = (User *) 0xab7f2d8
30891         ci = (ChannelInfo *) 0xa571940
30892         modes = 0
30893         is_servermode = 0
30894         res = 1
30895 #4  0x400820ed in do_channel_umode_change (source=0xbfffeed0 "|-Frango-|",
30896 c=0xa905d00, u=0xab34ff0, oldmodes=1)
30897     at main.c:354
30898 No locals.
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
30903         res = 0
30904         i = 0
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---
30908     at channels.c:409
30909         u = (struct c_userlist *) 0xab34ff0
30910         user = (User *) 0xab7f2d8
30911         oldmode = 1
30912 #7  0x0804e97e in do_cmode (source=0xbfffeed0 "|-Frango-|", ac=0,
30913 av=0xa853130) at channels.c:302
30914         modechar = 111 'o'
30915         flag = 1
30916         params = -1073746288
30917         chan = (Channel *) 0xa905d00
30918         s = 0xbfffeca5 ""
30919         add = 0
30920         modestr = 0xbfffec9e "-oooooo"
30921 #8  0x080557ff in m_mode (source=0xbfffeed0 "|-Frango-|", ac=8,
30922 av=0xa853110) at messages.c:101
30923 No locals.
30924 #9  0x0805920e in process () at process.c:133
30925         m = (Message *) 0x8067dd8
30926         source =
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
30929 5\b"
30930         cmd =
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"
30934         buf =
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"
30942         ac = 8
30943         av = (char **) 0xa853110
30944 #10 0x0805507d in readline_callback (s=0xa851ae0, param_unused=0x50) at
30945 main.c:177
30946 No locals.
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."...
30952         left = 80
30953         newleft = 80
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}
30957         i = 4
30958         res = 260
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---
30963         now = 1066500331
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.
30969 (gdb)
30970
30971
30972
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>
30979
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.
30987
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?
31001
31002 Thank you all for your time.
31003
31004 Saturn
31005
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
31011
31012
31013      You know, I might have been more forgiving if this hadn't been gone
31014 over on this list (twice!) before:
31015
31016 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/002305.html
31017 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/003215.html
31018
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
31021 edification:
31022
31023 F.10. Services doesn't kill users matching a newly-added autokill mask even
31024 if ImmediatelySendAutokill is set.
31025
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.
31032
31033 Note that some IRC servers will themselves kill users matching a
31034 newly-added autokill; this is unrelated to Services.
31035
31036   --Andrew Church
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
31042
31043
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>
31049
31050 If it helps, more lines up.. of debugging...
31051
31052
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)
31065
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>
31077
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.
31083
31084 Ballsy
31085
31086
31087 At 12:49 PM 18/10/2003, V13 wrote:
31088 >On Saturday 18 October 2003 07:20, Robert F Merrill wrote:
31089 > > Saturn 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.
31097 > >
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
31104 > > do this.
31105 >
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.
31108 >
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.
31113 >
31114 ><<V13>>
31115 >------------------------------------------------------------------
31116 >To unsubscribe or change your subscription options, visit:
31117 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
31118
31119
31120
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>
31126
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>
31134
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
31137
31138 ciao
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>
31148
31149 Andrew, have anything more of dumping/debugging that i can do/give for helps
31150 fixing this bug..?
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)....
31153 anything more?
31154
31155
31156 Thanks for all
31157
31158
31159 Diego B. Contezini
31160
31161
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>
31167
31168
31169
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>
31175
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
31178 18:41:36 BRT 2003)
31179 yes, 5.0.23 is the last.. but nothing has changed about the bug...
31180
31181  here is the debugging:
31182
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
31187 #Euevc
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
31195 +stmipl 1
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)
31207
31208
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;
31214 (gdb) bt'
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
31218         s = 0x806aa3e ""
31219 #1  0x0804d342 in set_cmode (sender=0x81db058 "ChanServ", channel=0xa905d00)
31220 at actions.c:446
31221         parambuf =
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"...
31230         len = 10
31231         flag = 1
31232         params = 1
31233         is_chanuser = 1
31234         args = 0xbfffe6d0 "RDcoCOREcorei??i??i??i??o"
31235         modes = 0xbfffeae2 ""
31236         modes_orig = 0xbfffeae0 "+o"
31237         md = (struct modedata *) 0x806aa00
31238         which = 0
31239         add = 1
31240         i = 1
31241         c = 111 'o'
31242 #2  0x400895ff in local_set_cumodes (c=0xa905d00, plusminus=43 '+', modes=1,
31243 nick=0xab7f2e8 "balsanelli") at check.c:432
31244         buf = "+o"
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).."...
31249         s = 0xbfffe6e1 ""
31250 #3  0x40088d74 in check_chan_user_modes (source=0xbfffeed0 "|-Frango-|",
31251 u=0xab34ff0, c=0xa905d00, oldmodes=1)
31252     at check.c:214
31253         user = (User *) 0xab7f2d8
31254         ci = (ChannelInfo *) 0xa571940
31255         modes = 0
31256         is_servermode = 0
31257         res = 1
31258 #4  0x400820ed in do_channel_umode_change (source=0xbfffeed0 "|-Frango-|",
31259 c=0xa905d00, u=0xab34ff0, oldmodes=1)
31260     at main.c:354
31261 No locals.
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
31266         res = 0
31267         i = 0
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---
31271     at channels.c:409
31272         u = (struct c_userlist *) 0xab34ff0
31273         user = (User *) 0xab7f2d8
31274         oldmode = 1
31275 #7  0x0804e97e in do_cmode (source=0xbfffeed0 "|-Frango-|", ac=0,
31276 av=0xa853130) at channels.c:302
31277         modechar = 111 'o'
31278         flag = 1
31279         params = -1073746288
31280         chan = (Channel *) 0xa905d00
31281         s = 0xbfffeca5 ""
31282         add = 0
31283         modestr = 0xbfffec9e "-oooooo"
31284 #8  0x080557ff in m_mode (source=0xbfffeed0 "|-Frango-|", ac=8,
31285 av=0xa853110) at messages.c:101
31286 No locals.
31287 #9  0x0805920e in process () at process.c:133
31288         m = (Message *) 0x8067dd8
31289         source =
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
31292 5\b"
31293         cmd =
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"
31297         buf =
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"
31305         ac = 8
31306         av = (char **) 0xa853110
31307 #10 0x0805507d in readline_callback (s=0xa851ae0, param_unused=0x50) at
31308 main.c:177
31309 No locals.
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."...
31315         left = 80
31316         newleft = 80
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}
31320         i = 4
31321         res = 260
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---
31326         now = 1066500331
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
31343 cs             0x23     35
31344 ss             0x2b     43
31345 ds             0x2b     43
31346 es             0x2b     43
31347 fs             0x0      0
31348 gs             0x33     51
31349 (gdb)
31350
31351
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
31364 ...
31365 model name      : Pentium III (Coppermine)
31366 stepping        : 10
31367 cpu MHz         : 999.752
31368 cache size      : 256 KB
31369 ...
31370 root@irc(/home/ircadmin/services)# free
31371              total       used       free     shared    buffers     cached
31372 Mem:        513792     482248      31544          0      69492     274980
31373
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*
31383
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
31395
31396
31397 If it helps, here is the debugging of the last two cores, on gdb:
31398 ----------------
31399 FIRST:
31400 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
31401 av=0xbfffdc38)
31402     at channels.c:278
31403 278         while (*s) {
31404 (gdb) bt'
31405 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
31406 av=0xbfffdc38)
31407     at channels.c:278
31408         chan = (Channel *) 0xa87d1e0
31409         s = 0x1f73746f <Address 0x1f73746f out of bounds>
31410         add = 1
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
31420 \006\b"...
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>}
31430         len = 5
31431 ---Type <return> to continue, or q <return> to quit---
31432         i = 0
31433         lastc = 45 '-'
31434 #2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
31435         args = 0x0
31436         modes = 0x0
31437         modes_orig = 0x0
31438         md = (struct modedata *) 0x0
31439         which = -1
31440         add = 0
31441         i = 0
31442         c = 0 '\0'
31443 #3  0x080553a3 in main (ac=1, av=0xbfffe574, envp=0xbfffe57c) at main.c:269
31444         now = 1067891066
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.
31450 -----------
31451
31452 SECOND:
31453 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
31454 av=0xbffff2b8)
31455     at channels.c:278
31456 278         while (*s) {
31457 (gdb) bt'
31458 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
31459 av=0xbffff2b8)
31460     at channels.c:278
31461         chan = (Channel *) 0xa9be840
31462         s = 0xbf000000 <Address 0xbf000000 out of bounds>
31463         add = 1
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>}
31480         len = 5
31481         i = 0
31482         lastc = 45 '-'
31483 #2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
31484 ---Type <return> to continue, or q <return> to quit---
31485         args = 0x0
31486         modes = 0x0
31487         modes_orig = 0x0
31488         md = (struct modedata *) 0x0
31489         which = -1
31490         add = 0
31491         i = 0
31492         c = 0 '\0'
31493 #3  0x080553a3 in main (ac=1, av=0xbffffbf4, envp=0xbffffbfc) at main.c:269
31494         now = 1067706795
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.
31500 (gdb)
31501 -------
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
31504 this bug...
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
31508 anything....
31509
31510 Thanks for all development, this is really a bealtifull software...
31511 (and sorry for my bad english)
31512
31513 Diego B. Contezini aka destruct_ #irc.redesul.net
31514
31515
31516
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>
31522
31523 If it helps, im using Bahamut here....
31524
31525
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>
31532
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 ?
31541
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.
31551
31552   --Andrew Church
31553     achurch@achurch.org
31554     http://achurch.org/
31555
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>
31561
31562 I'm getting this too - it's just started happening in 5.0.23:
31563
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'
31568
31569 gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
31570
31571 Russ
31572
31573
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>
31579
31580 Where is the akill type used in some of AutoKill functions listed in
31581 modules/database/readme defined?
31582
31583 ________________________________________________
31584 Message sent using MHCABLE Webmail
31585
31586
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>
31592
31593
31594
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>
31600
31601 Hi,
31602
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:
31606
31607 ***************************
31608 -
31609 -NickServ- nick is hello world
31610 -
31611 -NickServ- Is online from: ~test@just.a.test.co.za
31612 -
31613 -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
31614 -
31615 -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
31616 -
31617 -NickServ- Last quit message: anythinggggg
31618 -
31619 -NickServ- Options: Kill protection, Security
31620 -
31621 ***************************
31622
31623 the new line I'm suggesting is something like:
31624
31625 ***************************
31626 -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
31627 ***************************
31628
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).
31634
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)
31638
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)
31641
31642 Many thanks to all of who developed IRCservices ...etc ...etc ...etc
31643
31644 sincerely,
31645 David
31646
31647 _________________________________________________________________
31648 Get MSN 8 and enjoy automatic e-mail virus protection.
31649 http://join.msn.com/?page=features/virus
31650
31651
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>
31659
31660 Or how about rather letting users decide what timezone they're in and
31661 services outputs all timestamps in their local time?
31662
31663
31664 | By us44ever . <us44ever@hotmail.com>
31665 |                                          [ 2003-08-28 18:45 +0200 ]
31666 > Hi,
31667 >
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:
31671 >
31672 > ***************************
31673 > -
31674 > -NickServ- nick is hello world
31675 > -
31676 > -NickServ- Is online from: ~test@just.a.test.co.za
31677 > -
31678 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
31679 > -
31680 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
31681 > -
31682 > -NickServ- Last quit message: anythinggggg
31683 > -
31684 > -NickServ- Options: Kill protection, Security
31685 > -
31686 > ***************************
31687 >
31688 > the new line I'm suggesting is something like:
31689 >
31690 > ***************************
31691 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
31692 > ***************************
31693 >
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).
31699 >
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)
31703 >
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)
31706 >
31707 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
31708 >
31709 > sincerely,
31710 > David
31711 >
31712 > _________________________________________________________________
31713 > Get MSN 8 and enjoy automatic e-mail virus protection.
31714 > http://join.msn.com/?page=features/virus
31715 >
31716 > ------------------------------------------------------------------
31717 > To unsubscribe or change your subscription options, visit:
31718 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
31719
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>
31727
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
31735
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
31741
31742
31743 Or how about rather letting users decide what timezone they're in and
31744 services outputs all timestamps in their local time?
31745
31746
31747 | By us44ever . <us44ever@hotmail.com>
31748 |                                          [ 2003-08-28 18:45 +0200 ]
31749 > Hi,
31750 >
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:
31754 >
31755 > ***************************
31756 > -
31757 > -NickServ- nick is hello world
31758 > -
31759 > -NickServ- Is online from: ~test@just.a.test.co.za
31760 > -
31761 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
31762 > -
31763 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
31764 > -
31765 > -NickServ- Last quit message: anythinggggg
31766 > -
31767 > -NickServ- Options: Kill protection, Security
31768 > -
31769 > ***************************
31770 >
31771 > the new line I'm suggesting is something like:
31772 >
31773 > ***************************
31774 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
31775 > ***************************
31776 >
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).
31782 >
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)
31786 >
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)
31789 >
31790 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
31791 >
31792 > sincerely,
31793 > David
31794 >
31795 > _________________________________________________________________
31796 > Get MSN 8 and enjoy automatic e-mail virus protection.
31797 > http://join.msn.com/?page=features/virus
31798 >
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
31805
31806
31807
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>
31813
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..
31815
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
31818
31819 *shock*
31820
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  ****************************************/
31828
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  ****************************************/
31835
31836 /****** - Begin Original Message - ******/
31837
31838 >Hi,
31839 >
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:
31843 >
31844 >***************************
31845 >-
31846 >-NickServ- nick is hello world
31847 >-
31848 >-NickServ- Is online from: ~test@just.a.test.co.za
31849 >-
31850 >-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
31851 >-
31852 >-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
31853 >-
31854 >-NickServ- Last quit message: anythinggggg
31855 >-
31856 >-NickServ- Options: Kill protection, Security
31857 >-
31858 >***************************
31859 >
31860 >the new line I'm suggesting is something like:
31861 >
31862 >***************************
31863 >-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
31864 >***************************
31865 >
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).
31871 >
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)
31875 >
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)
31878 >
31879 >Many thanks to all of who developed IRCservices ...etc ...etc ...etc
31880 >
31881 >sincerely,
31882 >David
31883 >
31884 >_________________________________________________________________
31885 >Get MSN 8 and enjoy automatic e-mail virus protection.
31886 >http://join.msn.com/?page=features/virus
31887 >
31888 >------------------------------------------------------------------
31889 >To unsubscribe or change your subscription options, visit:
31890 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
31891
31892 /******* - End Original Message - *******/
31893
31894
31895
31896
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>
31902
31903 We're having a small problem with suspended channel.
31904
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.
31907
31908 Also with suspended nick , when the suspencion expire, the services crash
31909 We're using:
31910
31911 ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
31912
31913
31914 Thanks
31915 Marc
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>
31924
31925 hmm.. what OS, compiler version etc are you using?
31926
31927 after a test, i got the following:
31928
31929 /cs id #abc 00376370
31930 -ChanServ- Channel #abc is suspended and may not be used or identified for.
31931
31932 /cs drop #abc
31933 [23:20] -ChanServ- Channel  is suspended and may not be used or identified for.
31934
31935 only prob i got was it missed the channel name in the second message :)
31936
31937 /cs drop #abc
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  ****************************************/
31945
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  ****************************************/
31952
31953 /****** - Begin Original Message - ******/
31954
31955 >We're having a small problem with suspended channel.
31956 >
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.
31959 >
31960 >Also with suspended nick , when the suspencion expire, the services crash
31961 >We're using:
31962 >
31963 >ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
31964 >
31965 >
31966 >Thanks
31967 >Marc
31968 >------------------------------------------------------------------
31969 >To unsubscribe or change your subscription options, visit:
31970 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
31971
31972 /******* - End Original Message - *******/
31973
31974
31975
31976
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>
31983
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...
31988
31989 Just an idea... I now await the half dozen people who will proceed to tell
31990 me how stupid my idea is....
31991
31992 Saturn
31993 irc.jetirc.net
31994
31995
31996
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>
32004
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.
32009
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..
32013 >
32014 > /time services.chatspike.net
32015 > [22:28] ??? Date / time at services.chatspike.net- Thu Aug 28 17:28:57
32016 > 2003 EDT
32017 >
32018 > *shock*
32019 >
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 >  ****************************************/
32027 >
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 >  ****************************************/
32034 >
32035 > /****** - Begin Original Message - ******/
32036 >
32037 >>Hi,
32038 >>
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:
32042 >>
32043 >>***************************
32044 >>-
32045 >>-NickServ- nick is hello world
32046 >>-
32047 >>-NickServ- Is online from: ~test@just.a.test.co.za
32048 >>-
32049 >>-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
32050 >>-
32051 >>-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
32052 >>-
32053 >>-NickServ- Last quit message: anythinggggg
32054 >>-
32055 >>-NickServ- Options: Kill protection, Security
32056 >>-
32057 >>***************************
32058 >>
32059 >>the new line I'm suggesting is something like:
32060 >>
32061 >>***************************
32062 >>-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
32063 >>***************************
32064 >>
32065 >>This will help our users to compare the time that user was last seen and
32066 >> the
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
32070 >> GMT
32071 >>(last seen time was before: 10 days, 3hours and 24 sec ago).
32072 >>
32073 >>Note that I saw both of these features, in other services I don't
32074 >> remember
32075 >>there names (but they aren't as stable as ircservices5) (it was something
32076 >>like ptlink services, and magik II)
32077 >>
32078 >>That's all, I would really like to see it on the next version (or if you
32079 >> can
32080 >>show me how to do it, as I'm not a programmer)
32081 >>
32082 >>Many thanks to all of who developed IRCservices ...etc ...etc ...etc
32083 >>
32084 >>sincerely,
32085 >>David
32086 >>
32087 >>_________________________________________________________________
32088 >>Get MSN 8 and enjoy automatic e-mail virus protection.
32089 >>http://join.msn.com/?page=features/virus
32090 >>
32091 >>------------------------------------------------------------------
32092 >>To unsubscribe or change your subscription options, visit:
32093 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
32094 >
32095 > /******* - End Original Message - *******/
32096 >
32097 >
32098 >
32099 > ------------------------------------------------------------------
32100 > To unsubscribe or change your subscription options, visit:
32101 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
32102 >
32103
32104
32105 --
32106 Best Regards,
32107 playa
32108 Network Founder/CEO
32109 DreamChat IRC Network - irc.dreamchat.org
32110 http://www.dreamchat.org
32111
32112
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>
32119
32120 On Thursday, Aug 28, 2003, at 20:46 US/Pacific, playa wrote:
32121
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.
32126
32127 That's a client thing.  Some clients might alias /time as a CTCP TIME
32128 for a specific user, or similar.
32129
32130 -- Quension
32131
32132
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>
32141
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.
32146
32147 Some clients use stupid aliases for CTCP commands, for example:
32148
32149 /version <nick> = /CTCP <nick> VERSION,
32150 /time <nick> = /CTCP <nick> TIME,
32151 /finger <nick> = /CTCP <nick> TIME
32152
32153 This is why nothing works the way you expected.
32154
32155 --
32156 Krisztian Romek
32157 r-krisztian@softhome.net
32158
32159
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>
32165
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).
32169
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
32173
32174
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>
32180
32181
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.
32187
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
32191
32192
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>
32198
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.
32200
32201 And i'll Quote Elijah:
32202
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
32205 be 'no.'"
32206
32207
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  ****************************************/
32215
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  ****************************************/
32222
32223 /****** - Begin Original Message - ******/
32224
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.
32230 >
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
32234 >
32235 >------------------------------------------------------------------
32236 >To unsubscribe or change your subscription options, visit:
32237 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
32238 >.
32239
32240 /******* - End Original Message - *******/
32241
32242
32243
32244
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>
32250
32251 its a stupid idea!!! :p
32252
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
32254
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  ****************************************/
32262
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  ****************************************/
32269
32270 /****** - Begin Original Message - ******/
32271
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...
32276 >
32277 >Just an idea... I now await the half dozen people who will proceed to tell
32278 >me how stupid my idea is....
32279 >
32280 >Saturn
32281 >irc.jetirc.net
32282 >
32283 >
32284 >------------------------------------------------------------------
32285 >To unsubscribe or change your subscription options, visit:
32286 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
32287
32288 /******* - End Original Message - *******/
32289
32290
32291
32292
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>
32298
32299
32300
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>
32306
32307 Hi,
32308
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:
32312
32313 ***************************
32314 -
32315 -NickServ- nick is hello world
32316 -
32317 -NickServ- Is online from: ~test@just.a.test.co.za
32318 -
32319 -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
32320 -
32321 -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
32322 -
32323 -NickServ- Last quit message: anythinggggg
32324 -
32325 -NickServ- Options: Kill protection, Security
32326 -
32327 ***************************
32328
32329 the new line I'm suggesting is something like:
32330
32331 ***************************
32332 -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
32333 ***************************
32334
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).
32340
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)
32344
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)
32347
32348 Many thanks to all of who developed IRCservices ...etc ...etc ...etc
32349
32350 sincerely,
32351 David
32352
32353 _________________________________________________________________
32354 Get MSN 8 and enjoy automatic e-mail virus protection.
32355 http://join.msn.com/?page=features/virus
32356
32357
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>
32365
32366 Or how about rather letting users decide what timezone they're in and
32367 services outputs all timestamps in their local time?
32368
32369
32370 | By us44ever . <us44ever@hotmail.com>
32371 |                                          [ 2003-08-28 18:45 +0200 ]
32372 > Hi,
32373 >
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:
32377 >
32378 > ***************************
32379 > -
32380 > -NickServ- nick is hello world
32381 > -
32382 > -NickServ- Is online from: ~test@just.a.test.co.za
32383 > -
32384 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
32385 > -
32386 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
32387 > -
32388 > -NickServ- Last quit message: anythinggggg
32389 > -
32390 > -NickServ- Options: Kill protection, Security
32391 > -
32392 > ***************************
32393 >
32394 > the new line I'm suggesting is something like:
32395 >
32396 > ***************************
32397 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
32398 > ***************************
32399 >
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).
32405 >
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)
32409 >
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)
32412 >
32413 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
32414 >
32415 > sincerely,
32416 > David
32417 >
32418 > _________________________________________________________________
32419 > Get MSN 8 and enjoy automatic e-mail virus protection.
32420 > http://join.msn.com/?page=features/virus
32421 >
32422 > ------------------------------------------------------------------
32423 > To unsubscribe or change your subscription options, visit:
32424 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
32425
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>
32433
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
32441
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
32447
32448
32449 Or how about rather letting users decide what timezone they're in and
32450 services outputs all timestamps in their local time?
32451
32452
32453 | By us44ever . <us44ever@hotmail.com>
32454 |                                          [ 2003-08-28 18:45 +0200 ]
32455 > Hi,
32456 >
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:
32460 >
32461 > ***************************
32462 > -
32463 > -NickServ- nick is hello world
32464 > -
32465 > -NickServ- Is online from: ~test@just.a.test.co.za
32466 > -
32467 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
32468 > -
32469 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
32470 > -
32471 > -NickServ- Last quit message: anythinggggg
32472 > -
32473 > -NickServ- Options: Kill protection, Security
32474 > -
32475 > ***************************
32476 >
32477 > the new line I'm suggesting is something like:
32478 >
32479 > ***************************
32480 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
32481 > ***************************
32482 >
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).
32488 >
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)
32492 >
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)
32495 >
32496 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
32497 >
32498 > sincerely,
32499 > David
32500 >
32501 > _________________________________________________________________
32502 > Get MSN 8 and enjoy automatic e-mail virus protection.
32503 > http://join.msn.com/?page=features/virus
32504 >
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
32511
32512
32513
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>
32519
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..
32521
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
32524
32525 *shock*
32526
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  ****************************************/
32534
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  ****************************************/
32541
32542 /****** - Begin Original Message - ******/
32543
32544 >Hi,
32545 >
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:
32549 >
32550 >***************************
32551 >-
32552 >-NickServ- nick is hello world
32553 >-
32554 >-NickServ- Is online from: ~test@just.a.test.co.za
32555 >-
32556 >-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
32557 >-
32558 >-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
32559 >-
32560 >-NickServ- Last quit message: anythinggggg
32561 >-
32562 >-NickServ- Options: Kill protection, Security
32563 >-
32564 >***************************
32565 >
32566 >the new line I'm suggesting is something like:
32567 >
32568 >***************************
32569 >-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
32570 >***************************
32571 >
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).
32577 >
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)
32581 >
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)
32584 >
32585 >Many thanks to all of who developed IRCservices ...etc ...etc ...etc
32586 >
32587 >sincerely,
32588 >David
32589 >
32590 >_________________________________________________________________
32591 >Get MSN 8 and enjoy automatic e-mail virus protection.
32592 >http://join.msn.com/?page=features/virus
32593 >
32594 >------------------------------------------------------------------
32595 >To unsubscribe or change your subscription options, visit:
32596 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
32597
32598 /******* - End Original Message - *******/
32599
32600
32601
32602
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>
32608
32609 We're having a small problem with suspended channel.
32610
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.
32613
32614 Also with suspended nick , when the suspencion expire, the services crash
32615 We're using:
32616
32617 ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
32618
32619
32620 Thanks
32621 Marc
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>
32630
32631 hmm.. what OS, compiler version etc are you using?
32632
32633 after a test, i got the following:
32634
32635 /cs id #abc 00376370
32636 -ChanServ- Channel #abc is suspended and may not be used or identified for.
32637
32638 /cs drop #abc
32639 [23:20] -ChanServ- Channel  is suspended and may not be used or identified for.
32640
32641 only prob i got was it missed the channel name in the second message :)
32642
32643 /cs drop #abc
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  ****************************************/
32651
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  ****************************************/
32658
32659 /****** - Begin Original Message - ******/
32660
32661 >We're having a small problem with suspended channel.
32662 >
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.
32665 >
32666 >Also with suspended nick , when the suspencion expire, the services crash
32667 >We're using:
32668 >
32669 >ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
32670 >
32671 >
32672 >Thanks
32673 >Marc
32674 >------------------------------------------------------------------
32675 >To unsubscribe or change your subscription options, visit:
32676 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
32677
32678 /******* - End Original Message - *******/
32679
32680
32681
32682
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>
32689
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...
32694
32695 Just an idea... I now await the half dozen people who will proceed to tell
32696 me how stupid my idea is....
32697
32698 Saturn
32699 irc.jetirc.net
32700
32701
32702
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>
32710
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.
32715
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..
32719 >
32720 > /time services.chatspike.net
32721 > [22:28] ??? Date / time at services.chatspike.net- Thu Aug 28 17:28:57
32722 > 2003 EDT
32723 >
32724 > *shock*
32725 >
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 >  ****************************************/
32733 >
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 >  ****************************************/
32740 >
32741 > /****** - Begin Original Message - ******/
32742 >
32743 >>Hi,
32744 >>
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:
32748 >>
32749 >>***************************
32750 >>-
32751 >>-NickServ- nick is hello world
32752 >>-
32753 >>-NickServ- Is online from: ~test@just.a.test.co.za
32754 >>-
32755 >>-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
32756 >>-
32757 >>-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
32758 >>-
32759 >>-NickServ- Last quit message: anythinggggg
32760 >>-
32761 >>-NickServ- Options: Kill protection, Security
32762 >>-
32763 >>***************************
32764 >>
32765 >>the new line I'm suggesting is something like:
32766 >>
32767 >>***************************
32768 >>-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
32769 >>***************************
32770 >>
32771 >>This will help our users to compare the time that user was last seen and
32772 >> the
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
32776 >> GMT
32777 >>(last seen time was before: 10 days, 3hours and 24 sec ago).
32778 >>
32779 >>Note that I saw both of these features, in other services I don't
32780 >> remember
32781 >>there names (but they aren't as stable as ircservices5) (it was something
32782 >>like ptlink services, and magik II)
32783 >>
32784 >>That's all, I would really like to see it on the next version (or if you
32785 >> can
32786 >>show me how to do it, as I'm not a programmer)
32787 >>
32788 >>Many thanks to all of who developed IRCservices ...etc ...etc ...etc
32789 >>
32790 >>sincerely,
32791 >>David
32792 >>
32793 >>_________________________________________________________________
32794 >>Get MSN 8 and enjoy automatic e-mail virus protection.
32795 >>http://join.msn.com/?page=features/virus
32796 >>
32797 >>------------------------------------------------------------------
32798 >>To unsubscribe or change your subscription options, visit:
32799 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
32800 >
32801 > /******* - End Original Message - *******/
32802 >
32803 >
32804 >
32805 > ------------------------------------------------------------------
32806 > To unsubscribe or change your subscription options, visit:
32807 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
32808 >
32809
32810
32811 --
32812 Best Regards,
32813 playa
32814 Network Founder/CEO
32815 DreamChat IRC Network - irc.dreamchat.org
32816 http://www.dreamchat.org
32817
32818
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>
32825
32826 On Thursday, Aug 28, 2003, at 20:46 US/Pacific, playa wrote:
32827
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.
32832
32833 That's a client thing.  Some clients might alias /time as a CTCP TIME
32834 for a specific user, or similar.
32835
32836 -- Quension
32837
32838
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>
32847
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.
32852
32853 Some clients use stupid aliases for CTCP commands, for example:
32854
32855 /version <nick> = /CTCP <nick> VERSION,
32856 /time <nick> = /CTCP <nick> TIME,
32857 /finger <nick> = /CTCP <nick> TIME
32858
32859 This is why nothing works the way you expected.
32860
32861 --
32862 Krisztian Romek
32863 r-krisztian@softhome.net
32864
32865
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>
32871
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).
32875
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
32879
32880
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>
32886
32887
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.
32893
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
32897
32898
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>
32904
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.
32906
32907 And i'll Quote Elijah:
32908
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
32911 be 'no.'"
32912
32913
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  ****************************************/
32921
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  ****************************************/
32928
32929 /****** - Begin Original Message - ******/
32930
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.
32936 >
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
32940 >
32941 >------------------------------------------------------------------
32942 >To unsubscribe or change your subscription options, visit:
32943 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
32944 >.
32945
32946 /******* - End Original Message - *******/
32947
32948
32949
32950
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>
32956
32957 its a stupid idea!!! :p
32958
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
32960
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  ****************************************/
32968
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  ****************************************/
32975
32976 /****** - Begin Original Message - ******/
32977
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...
32982 >
32983 >Just an idea... I now await the half dozen people who will proceed to tell
32984 >me how stupid my idea is....
32985 >
32986 >Saturn
32987 >irc.jetirc.net
32988 >
32989 >
32990 >------------------------------------------------------------------
32991 >To unsubscribe or change your subscription options, visit:
32992 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
32993
32994 /******* - End Original Message - *******/
32995
32996
32997
32998
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>
33005
33006 Cheers.
33007
33008 -----Original Message-----
33009 From: ircservices-coding-bounces@ircservices.za.net
33010 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of Craig
33011 McLure
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
33015
33016
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
33019 to annoy me.
33020
33021 And i'll Quote Elijah:
33022
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
33025 be 'no.'"
33026
33027
33028
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>
33034
33035 woops, ok sorry I thought the two e-mails is completely different.
33036
33037
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
33045 >
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.
33049 >
33050 >And i'll Quote Elijah:
33051 >
33052 >"Except it's already been said in the FAQ that it's not going to happen,
33053 >and
33054 >if that made it into the FAQ it would seem the answer is frequently going
33055 >to
33056 >be 'no.'"
33057 >
33058 >
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 >  ****************************************/
33066 >
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 >  ****************************************/
33073 >
33074 >/****** - Begin Original Message - ******/
33075 >
33076 > >Since most people want to see this feature(s) in the next version, it
33077 >would
33078 > >be great to implement it as an optional feature , where it can be
33079 >disabled
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
33082 >fact,
33083 > >it will add another nice feature to the features list of IRCservices5.
33084 > >
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
33088 > >
33089 > >------------------------------------------------------------------
33090 > >To unsubscribe or change your subscription options, visit:
33091 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
33092 > >.
33093 >
33094 >/******* - End Original Message - *******/
33095 >
33096 >
33097 >
33098 >------------------------------------------------------------------
33099 >To unsubscribe or change your subscription options, visit:
33100 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
33101
33102 _________________________________________________________________
33103 MSN 8: Get 6 months for $9.95/month. http://join.msn.com/?page=dept/dialup
33104
33105
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>
33112
33113 Hi
33114 I run ircservices 5.0.21 on FreeBSD 4.8-STABLE. and Ultimate 3.*
33115 I get this in logfile:
33116
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)
33129
33130 and how can I do so that nickserv dont show the realhost of a user in
33131 'ns info nick all'
33132
33133
33134 thanks for help
33135
33136                            Ali "Simorgh"
33137  ______________________________________________________
33138  Many of life's failures are people who did not realize
33139  how close they were to success when they gave up.
33140  Thomas A. Edison
33141  ______________________________________________________
33142
33143
33144
33145
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>
33152
33153 "and how can I do so that nickserv dont show the realhost of a user in
33154 'ns info nick all'"
33155
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
33159 option is set.
33160
33161
33162
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>
33169
33170      Use E-mail if you need communication of that sort.
33171
33172   --Andrew Church
33173     achurch@achurch.org
33174     http://achurch.org/
33175
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
33180 >have been denied.
33181 >
33182 >/chanserv MARK <channel> <reason>
33183 >
33184 >/chanserv info #channel would read the following.
33185 >*#channel has been MARKED by playa - <reason>
33186 >
33187 >Of course only IRCops would be able to view it.
33188 >
33189 >Just an idea i thought of :)
33190 >
33191 >--
33192 >Best Regards,
33193 >playa
33194 >Network Founder/CEO
33195 >DreamChat IRC Network - irc.dreamchat.org
33196 >http://www.dreamchat.org
33197 >
33198 >------------------------------------------------------------------
33199 >To unsubscribe or change your subscription options, visit:
33200 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
33201
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>
33208
33209      Needless complexity.  If you don't want yourself autoopped, then don't
33210 be an auto-op.  It's that simple.
33211
33212   --Andrew Church
33213     achurch@achurch.org
33214     http://achurch.org/
33215
33216 >Hi again
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.
33219 >
33220 >Like:
33221 > SET NOAUTO ON|OFF
33222 >  When NOAUTO is on, ChanServ will not
33223 >  automatically op or voice you in any channels.
33224 >
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.
33227 >
33228 >Or did I miss it?
33229 >
33230 >Thanks
33231 >
33232 >                           Ali "Simorgh"
33233 > ______________________________________________________
33234 > Many of life's failures are people who did not realize
33235 > how close they were to success when they gave up.
33236 > Thomas A. Edison
33237 > ______________________________________________________
33238 >
33239 >
33240 >On Sun, 17 Aug 2003, Russell Garrett wrote:
33241 >
33242 >> Eh? This has been implemented since IRCServices 5a31.
33243 >>
33244 >> Russ
33245 >>
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)
33250 >> >
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
33253 >> > channels.
33254 >> >
33255 >> > Thanks for any help
33256 >>
33257 >> ------------------------------------------------------------------
33258 >> To unsubscribe or change your subscription options, visit:
33259 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
33260 >>
33261 >
33262 >------------------------------------------------------------------
33263 >To unsubscribe or change your subscription options, visit:
33264 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
33265
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>
33273
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.
33277
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
33286 is not complex.
33287
33288 Shaun
33289
33290
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>
33296
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..
33299
33300 or /cs levels #channels DISABLE autoop
33301
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  ****************************************/
33309
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  ****************************************/
33316
33317 /****** - Begin Original Message - ******/
33318
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.
33322 >
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
33331 >is not complex.
33332 >
33333 >Shaun
33334 >
33335 >------------------------------------------------------------------
33336 >To unsubscribe or change your subscription options, visit:
33337 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
33338 >.
33339
33340 /******* - End Original Message - *******/
33341
33342
33343
33344
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>
33352
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..
33355
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.
33358
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
33361
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
33368
33369 Same with ENFORCE set to off as well.
33370
33371 > [snipped obnoxiously long sig]
33372
33373 Shaun Guth
33374
33375
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>
33382
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
33385 >
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
33392
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.
33396
33397   --Andrew Church
33398     achurch@achurch.org
33399     http://achurch.org/
33400
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>
33407
33408 >Can we reconsider adding a Mass memo function for the next release?
33409
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.
33417
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.
33423
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.
33428
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.
33431
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........
33438
33439      This is an interesting thought; I'll think about it for a future
33440 version.
33441
33442   --Andrew Church
33443     achurch@achurch.org
33444     http://achurch.org/
33445
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>
33452
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?
33458
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.
33463
33464   --Andrew Church
33465     achurch@achurch.org
33466     http://achurch.org/
33467
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>
33474
33475 >Is there any tool (silly question) or something or guid to make a language
33476 >file.
33477 >
33478 >I have decided to make a Persian (Farsi) language file.
33479
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.
33484
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.
33487
33488   --Andrew Church
33489     achurch@achurch.org
33490     http://achurch.org/
33491
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>
33498
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
33502
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?
33505
33506   --Andrew Church
33507     achurch@achurch.org
33508     http://achurch.org/
33509
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>
33516
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.
33520
33521      This is a bug in the DROP function, and has been fixed; thanks for the
33522 report.
33523
33524   --Andrew Church
33525     achurch@achurch.org
33526     http://achurch.org/
33527
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>
33534
33535 >[Aug 30 10:56:18 2003] mail/sendmail:
33536 > /usr/sbin/sendmail exited with code 25600
33537
33538      Use the SMTP module instead (mail/smtp).
33539
33540 >[Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
33541 >registration (Simorgh)
33542 >
33543 >and how can I do so that nickserv dont show the realhost of a user in
33544 >'ns info nick all'
33545
33546      It doesn't.  However:
33547
33548 >[Aug 30 10:51:19 2003] unknown message from server
33549 >(:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
33550
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.
33554
33555   --Andrew Church
33556     achurch@achurch.org
33557     http://achurch.org/
33558
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>
33565
33566 >Or how about rather letting users decide what timezone they're in and
33567 >services outputs all timestamps in their local time?
33568
33569 /ns help set timezone (since 5.0 alpha)
33570
33571   --Andrew Church
33572     achurch@achurch.org
33573     http://achurch.org/
33574
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>
33582
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.
33590
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?
33598
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....
33605
33606 Saturn
33607 irc.jetirc.net
33608
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
33614
33615
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...
33618
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.
33622
33623   --Andrew Church
33624     achurch@achurch.org
33625     http://achurch.org/
33626
33627
33628
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>
33637
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.
33647
33648 Erm, what's the argument here?  Services stipulates its timezone in its
33649 timestamps.  As do all the other servers on the network.
33650
33651 Atleast mine do...
33652
33653
33654 Regards,
33655 Aragon
33656
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>
33665
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??
33670
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
33676 suggestion
33677
33678
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
33682 server
33683 > is in a different time zone -- How are users supposed to know what time
33684 zone
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.
33690
33691 Erm, what's the argument here?  Services stipulates its timezone in its
33692 timestamps.  As do all the other servers on the network.
33693
33694 Atleast mine do...
33695
33696
33697 Regards,
33698 Aragon
33699 ------------------------------------------------------------------
33700 To unsubscribe or change your subscription options, visit:
33701 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
33702
33703
33704
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>
33712
33713 On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
33714
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?
33719
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
33723 it back.
33724
33725 >   Why does it all have to be so complicated??
33726
33727 It isn't.  Your users can even use the handy-dandy /nickserv set
33728 timezone command to make it even easier.
33729
33730 > ----- Original Message -----
33731 > From: "Aragon Gouveia" <aragon@phat.za.net>
33732
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.
33743 >
33744 > Erm, what's the argument here?  Services stipulates its timezone in
33745 > its timestamps.  As do all the other servers on the network.
33746
33747 -- Quension
33748
33749
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>
33756
33757
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
33760 seconds ago)
33761 Time registered  : Jul 25 22:19:20 2003 GMT (** days, ** minutes and **
33762 seconds ago)
33763 wouldn't even a greater idea?
33764
33765 _________________________________________________________________
33766 Get MSN 8 and enjoy automatic e-mail virus protection.
33767 http://join.msn.com/?page=features/virus
33768
33769
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>
33777
33778 [16:41] -NickServ-   Time registered: Jul 27 13:09:08 2002 PDT
33779
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....
33788
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
33791 valid ones...
33792
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
33795 codes like PDT)...
33796
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
33803 suggestion
33804
33805
33806 On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
33807
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?
33812
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
33816 it back.
33817
33818 >   Why does it all have to be so complicated??
33819
33820 It isn't.  Your users can even use the handy-dandy /nickserv set
33821 timezone command to make it even easier.
33822
33823 > ----- Original Message -----
33824 > From: "Aragon Gouveia" <aragon@phat.za.net>
33825
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.
33836 >
33837 > Erm, what's the argument here?  Services stipulates its timezone in
33838 > its timestamps.  As do all the other servers on the network.
33839
33840 -- Quension
33841
33842 ------------------------------------------------------------------
33843 To unsubscribe or change your subscription options, visit:
33844 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
33845
33846
33847
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>
33855
33856 On Sunday, Aug 31, 2003, at 16:47 US/Pacific, Saturn wrote:
33857
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)...
33861
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.
33865
33866 -- Quension
33867
33868
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>
33876
33877      "Use /ns set timezone" is the official answer on this.  Please take
33878 all further discussion to the ircservices list.
33879
33880   --Andrew Church
33881     achurch@achurch.org
33882     http://achurch.org/
33883
33884 >[16:41] -NickServ-   Time registered: Jul 27 13:09:08 2002 PDT
33885 >
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....
33894 >
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
33897 >valid ones...
33898 >
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)...
33902 >
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
33909 >suggestion
33910 >
33911 >
33912 >On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
33913 >
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?
33918 >
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
33922 >it back.
33923 >
33924 >>   Why does it all have to be so complicated??
33925 >
33926 >It isn't.  Your users can even use the handy-dandy /nickserv set
33927 >timezone command to make it even easier.
33928 >
33929 >> ----- Original Message -----
33930 >> From: "Aragon Gouveia" <aragon@phat.za.net>
33931 >
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.
33942 >>
33943 >> Erm, what's the argument here?  Services stipulates its timezone in
33944 >> its timestamps.  As do all the other servers on the network.
33945 >
33946 >-- Quension
33947 >
33948 >------------------------------------------------------------------
33949 >To unsubscribe or change your subscription options, visit:
33950 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
33951 >
33952 >
33953 >------------------------------------------------------------------
33954 >To unsubscribe or change your subscription options, visit:
33955 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
33956
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>
33963
33964 Thanks for your help.
33965
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
33970            Is online from: %s
33971 to:
33972 NICK_INFO_ADDRESS_ONLINE
33973            Is online from: N/A ?
33974
33975
33976                            Ali "Simorgh"
33977  ______________________________________________________
33978  Many of life's failures are people who did not realize
33979  how close they were to success when they gave up.
33980  Thomas A. Edison
33981  ______________________________________________________
33982
33983
33984 On Mon, 1 Sep 2003, Andrew Church wrote:
33985
33986 > >[Aug 30 10:56:18 2003] mail/sendmail:
33987 > > /usr/sbin/sendmail exited with code 25600
33988 >
33989 >      Use the SMTP module instead (mail/smtp).
33990 >
33991 > >[Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
33992 > >registration (Simorgh)
33993 > >
33994 > >and how can I do so that nickserv dont show the realhost of a user in
33995 > >'ns info nick all'
33996 >
33997 >      It doesn't.  However:
33998 >
33999 > >[Aug 30 10:51:19 2003] unknown message from server
34000 > >(:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
34001 >
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.
34005 >
34006 >   --Andrew Church
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
34012 >
34013
34014
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>
34021
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
34024
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.
34029
34030   --Andrew Church
34031     achurch@achurch.org
34032     http://achurch.org/
34033
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>
34039
34040 Hi all,
34041
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.
34045
34046 Regards
34047
34048 alex
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>
34059
34060 Hello,
34061
34062 alex wrote:
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.
34066
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
34070 computer.
34071
34072 --
34073 Krisztian Romek
34074 r-krisztian@softhome.net
34075
34076
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>
34082
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.
34084
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.
34086
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  ****************************************/
34094
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  ****************************************/
34101
34102 /****** - Begin Original Message - ******/
34103
34104 >Hi all,
34105 >
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.
34109 >
34110 >Regards
34111 >
34112 >alex
34113 >------------------------------------------------------------------
34114 >To unsubscribe or change your subscription options, visit:
34115 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
34116
34117 /******* - End Original Message - *******/
34118
34119
34120
34121
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>
34127
34128 It wasn't an easy subject to sum up in just a few words.
34129
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
34142 send.c
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
34146 all the
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)
34158
34159 Thanks
34160
34161 Brent
34162
34163
34164
34165 ----------------------------------------------------------
34166 |               Brent DiNicola                                  |
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 -----------------------------------------------------------
34173
34174
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>
34180
34181 lol, Our help no good? :P
34182
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..
34184
34185 Dont ask me for source on this.. i'm just theorising :)
34186
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  ****************************************/
34194
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  ****************************************/
34201
34202 /****** - Begin Original Message - ******/
34203
34204 >It wasn't an easy subject to sum up in just a few words.
34205 >
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
34218 >send.c
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
34222 >all the
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)
34234 >
34235 >Thanks
34236 >
34237 >Brent
34238 >
34239 >
34240 >
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 >-----------------------------------------------------------
34249 >
34250 >------------------------------------------------------------------
34251 >To unsubscribe or change your subscription options, visit:
34252 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
34253 >.
34254
34255 /******* - End Original Message - *******/
34256
34257
34258
34259
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>
34267
34268 Hello;
34269
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.
34279
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.
34294 ...
34295
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.
34299
34300 To your case.
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.
34304
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
34307 trivial.
34308
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
34312 closed.
34313
34314 Do keep in mind that requesting support for modified services versions
34315 are subject to be ignored.
34316
34317 I hope it helps,
34318 yusuf
34319
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.
34322 >
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
34335 > send.c
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
34339 > all the
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)
34351 >
34352 > Thanks
34353 >
34354 > Brent
34355 >
34356 >
34357 >
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 > -----------------------------------------------------------
34366 >
34367 > ------------------------------------------------------------------
34368 > To unsubscribe or change your subscription options, visit:
34369 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
34370 --
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 ------------------------------------------------------------------
34377
34378
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>
34385
34386 Brent DiNicola wrote:
34387
34388 > It wasn't an easy subject to sum up in just a few words.
34389 >
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
34395 > the users
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
34398 > NOTICE
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
34401 > the best
34402 > way to go about this without causing trouble for me and anyone else
34403 > who has
34404 > to deal with this code. Is it possible or even suggested to make a
34405 > module that
34406 > would replace the notice() from send.c with it's own, leaving the code
34407 > in send.c
34408 > alone and not causing troubles down the road. Suggestions were that I
34409 > make a
34410 > module that kept the info for each nick's setting and then if I could
34411 > override
34412 > the notice() and notice_lang() and notice_help() in send.c that would
34413 > keep all the
34414 > other code clean and not cause other troubles. I want to know what the
34415 > best
34416 > way to do this would be, I know it's against RFC but I want to move to
34417 > newer
34418 > services than the 1.4.3pre4 that we are using now and add modules so
34419 > that I
34420 > can do things down the line. They are used to having PRIVMSG and I
34421 > can't just
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
34424 > this? I
34425 > know this topic has been asked before and I know your not going to
34426 > make it
34427 > part of your code, I just wanted to know from the people who know the
34428 > code
34429 > really well what the best route to take would be to do the least
34430 > amount of
34431 > damage. (And if someone has done this.. please let me know what you did,
34432 > examples would rock)
34433 >
34434 > Thanks
34435 >
34436 > Brent
34437 >
34438 >
34439 >
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
34451 >
34452 >
34453
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
34458
34459 services is the wrong thing to change
34460
34461
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>
34467
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
34469
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  ****************************************/
34477
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  ****************************************/
34484
34485 /****** - Begin Original Message - ******/
34486
34487 >Brent DiNicola wrote:
34488 >
34489 >> It wasn't an easy subject to sum up in just a few words.
34490 >>
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
34496 >> the users
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
34499 >> NOTICE
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
34502 >> the best
34503 >> way to go about this without causing trouble for me and anyone else
34504 >> who has
34505 >> to deal with this code. Is it possible or even suggested to make a
34506 >> module that
34507 >> would replace the notice() from send.c with it's own, leaving the code
34508 >> in send.c
34509 >> alone and not causing troubles down the road. Suggestions were that I
34510 >> make a
34511 >> module that kept the info for each nick's setting and then if I could
34512 >> override
34513 >> the notice() and notice_lang() and notice_help() in send.c that would
34514 >> keep all the
34515 >> other code clean and not cause other troubles. I want to know what the
34516 >> best
34517 >> way to do this would be, I know it's against RFC but I want to move to
34518 >> newer
34519 >> services than the 1.4.3pre4 that we are using now and add modules so
34520 >> that I
34521 >> can do things down the line. They are used to having PRIVMSG and I
34522 >> can't just
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
34525 >> this? I
34526 >> know this topic has been asked before and I know your not going to
34527 >> make it
34528 >> part of your code, I just wanted to know from the people who know the
34529 >> code
34530 >> really well what the best route to take would be to do the least
34531 >> amount of
34532 >> damage. (And if someone has done this.. please let me know what you did,
34533 >> examples would rock)
34534 >>
34535 >> Thanks
34536 >>
34537 >> Brent
34538 >>
34539 >>
34540 >>
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
34552 >>
34553 >>
34554 >
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
34559 >
34560 >services is the wrong thing to change
34561 >
34562 >------------------------------------------------------------------
34563 >To unsubscribe or change your subscription options, visit:
34564 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
34565 >.
34566
34567 /******* - End Original Message - *******/
34568
34569
34570
34571
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>
34578
34579 On Thursday, Sep 4, 2003, at 13:29 US/Pacific, Robert F Merrill wrote:
34580
34581 > Brent DiNicola wrote:
34582 >
34583 >> It wasn't an easy subject to sum up in just a few words.
34584
34585 [...]
34586
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
34591 >
34592 > services is the wrong thing to change
34593
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.
34597
34598 This is the coding list, not the feature request list.  He asked for
34599 code design approaches, not for political insight.
34600
34601 -- Quension
34602
34603
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>
34609
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
34615
34616 Thanks for all
34617
34618 Diego B. Contezini
34619
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..
34625
34626
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
34632 get
34633 > a core.
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
34636 break
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.
34641 >
34642 > Thanks for all
34643 >
34644 > Diego B. Contezini aka destruct_ | irc.redesul.net
34645 > (Sorry for my confuse english.)
34646 >
34647
34648
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>
34655
34656 Hello, im destruct_, im the administrator of the RedeSul Network.
34657 (irc.redesul.net).
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
34661 a core.
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.
34668
34669 Thanks for all
34670
34671 Diego B. Contezini aka destruct_ | irc.redesul.net
34672 (Sorry for my confuse english.)
34673
34674
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>
34680
34681 Hi All
34682
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
34694
34695 many thanks
34696 Engin
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>
34705
34706 make sure you are on the services administrator list, if you are not, get the root administrator to add you using the command:
34707
34708 [22:27] -OperServ- Syntax: ADMIN ADD nickname
34709 [22:27] -OperServ- ADMIN DEL nickname
34710 [22:27] -OperServ- ADMIN LIST
34711 [22:27] -OperServ-
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.
34716 [22:27] -OperServ-
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.
34719
34720
34721
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  ****************************************/
34729
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  ****************************************/
34736
34737 /****** - Begin Original Message - ******/
34738
34739 >Hi All
34740 >
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
34752 >
34753 >many thanks
34754 >Engin
34755 >------------------------------------------------------------------
34756 >To unsubscribe or change your subscription options, visit:
34757 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
34758
34759 /******* - End Original Message - *******/
34760
34761
34762
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>
34769
34770 Contact me directly... I have quite a bit of experience with unreal and these services...
34771
34772 Saturn
34773 irc.jetirc.net
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
34779
34780
34781   Hi All
34782
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
34794
34795   many thanks
34796   Engin
34797
34798
34799
34800 ------------------------------------------------------------------------------
34801
34802
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>
34815
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....
34818
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
34825
34826
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:
34829
34830 [22:27] -OperServ- Syntax: ADMIN ADD nickname
34831 [22:27] -OperServ- ADMIN DEL nickname
34832 [22:27] -OperServ- ADMIN LIST
34833 [22:27] -OperServ-
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.
34838 [22:27] -OperServ-
34839 [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
34840 command.
34841 [22:27] -OperServ- All other use limited to Services super-user.
34842
34843
34844
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  ****************************************/
34852
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  ****************************************/
34859
34860 /****** - Begin Original Message - ******/
34861
34862 >Hi All
34863 >
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
34875 >
34876 >many thanks
34877 >Engin
34878 >------------------------------------------------------------------
34879 >To unsubscribe or change your subscription options, visit:
34880 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
34881
34882 /******* - End Original Message - *******/
34883
34884
34885 ------------------------------------------------------------------
34886 To unsubscribe or change your subscription options, visit:
34887 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
34888
34889
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>
34896
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
34899 one
34900
34901 cheers
34902 Engin
34903
34904
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
34910
34911
34912 > Send IRCServices-Coding mailing list submissions to
34913 > ircservices-coding@ircservices.za.net
34914 >
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
34919 >
34920 > You can reach the person managing the list at
34921 > ircservices-coding-owner@ircservices.za.net
34922 >
34923 > When replying, please edit your Subject line so it is more specific
34924 > than "Re: Contents of IRCServices-Coding digest..."
34925 >
34926 >
34927 > Today's Topics:
34928 >
34929 >    1. operserv (engin@piratetv)
34930 >    2. Re: operserv (Craig McLure)
34931 >    3. Re: operserv (Saturn)
34932 >    4. Re: operserv (Saturn)
34933 >
34934 >
34935 > ----------------------------------------------------------------------
34936 >
34937 > Message: 1
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"
34944 >
34945 > Hi All
34946 >
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
34958 >
34959 > many thanks
34960 > Engin
34961 > -------------- next part --------------
34962 > An HTML attachment was scrubbed...
34963 > URL:
34964 http://snow.fingers.co.za/pipermail/ircservices-coding/attachments/20030921/
34965 fdc12b4e/attachment-0001.htm
34966 >
34967 > ------------------------------
34968 >
34969 > Message: 2
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"
34977 >
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:
34980 >
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
34986 nicknames
34987 > [22:27] -OperServ- to or from the Services admin list. A user whose
34988 nickname
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
34991 commands.
34992 > [22:27] -OperServ-
34993 > [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
34994 command.
34995 > [22:27] -OperServ- All other use limited to Services super-user.
34996 >
34997 >
34998 >
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 >  ****************************************/
35006 >
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 >  ****************************************/
35013 >
35014 > /****** - Begin Original Message - ******/
35015 >
35016 > >Hi All
35017 > >
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
35029 > >
35030 > >many thanks
35031 > >Engin
35032 > >------------------------------------------------------------------
35033 > >To unsubscribe or change your subscription options, visit:
35034 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
35035 >
35036 > /******* - End Original Message - *******/
35037 >
35038 >
35039 >
35040 > ------------------------------
35041 >
35042 > Message: 3
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"
35050 >
35051 > Contact me directly... I have quite a bit of experience with unreal and
35052 these services...
35053 >
35054 > Saturn
35055 > irc.jetirc.net
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
35061 >
35062 >
35063 >   Hi All
35064 >
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
35067 mailing
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
35077 >
35078 >   many thanks
35079 >   Engin
35080 >
35081 >
35082 >
35083 > --------------------------------------------------------------------------
35084 ----
35085 >
35086 >
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...
35092 > URL:
35093 http://snow.fingers.co.za/pipermail/ircservices-coding/attachments/20030921/
35094 ca188e06/attachment-0001.htm
35095 >
35096 > ------------------------------
35097 >
35098 > Message: 4
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"
35106 >
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
35109 denied....
35110 >
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
35117 >
35118 >
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:
35121 >
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
35127 nicknames
35128 > [22:27] -OperServ- to or from the Services admin list. A user whose
35129 nickname
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
35132 commands.
35133 > [22:27] -OperServ-
35134 > [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
35135 > command.
35136 > [22:27] -OperServ- All other use limited to Services super-user.
35137 >
35138 >
35139 >
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 >  ****************************************/
35147 >
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 >  ****************************************/
35154 >
35155 > /****** - Begin Original Message - ******/
35156 >
35157 > >Hi All
35158 > >
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
35170 > >
35171 > >many thanks
35172 > >Engin
35173 > >------------------------------------------------------------------
35174 > >To unsubscribe or change your subscription options, visit:
35175 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
35176 >
35177 > /******* - End Original Message - *******/
35178 >
35179 >
35180 > ------------------------------------------------------------------
35181 > To unsubscribe or change your subscription options, visit:
35182 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
35183 >
35184 >
35185 > ------------------------------
35186 >
35187 > _______________________________________________
35188 > IRCServices-Coding mailing list
35189 > IRCServices-Coding@ircservices.za.net
35190 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
35191 >
35192 >
35193 > End of IRCServices-Coding Digest, Vol 8, Issue 5
35194 > ************************************************
35195
35196
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>
35204
35205 Sometimes has occur this bug, last 1 year....
35206 on a network with 30k registers, its happening with latency of 3.. 4
35207 days....
35208
35209 someone have any idea?
35210
35211 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
35212 av=0xbfffeec8) at channels.c:278
35213 278         while (*s) {
35214 (gdb) bt'
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>
35219         add = 1
35220         modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
35221 #1  0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:680
35222         buf =
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
35234 bounds>,
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@`???"}
35238         len = 4
35239         i = 0
35240         lastc = 45 '-'
35241 #2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
35242         args = 0x0
35243         modes = 0x0
35244         modes_orig = 0x0
35245         md = (struct modedata *) 0x0
35246         which = -1
35247         add = 0
35248         i = 0
35249         c = 0 '\0'
35250 #3  0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at main.c:269
35251         now = 1065393142
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.
35257 (gdb)
35258
35259
35260
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>
35267
35268 Upgrade.
35269
35270   --Andrew Church
35271     achurch@achurch.org
35272     http://achurch.org/
35273
35274 >Sometimes has occur this bug, last 1 year....
35275 >on a network with 30k registers, its happening with latency of 3.. 4
35276 >days....
35277 >
35278 >someone have any idea?
35279 >
35280 >#0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
35281 >av=0xbfffeec8) at channels.c:278
35282 >278         while (*s) {
35283 >(gdb) bt'
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>
35288 >        add = 1
35289 >        modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
35290 >#1  0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:68
35291 >0
35292 >        buf =
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ï¿½ï¿½ï¿½ï¿
35296 >½
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\
35301 >000\000\0
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�
35307 >���\027\000\0
35308 >00\000\000\000\000\000\024\032"...
35309 >        s = 0xbfffeef0 "-isl"
35310 >        argv = {0xa97b6c0 "#young", 0x20656c62 <Address 0x20656c62 out
35311 >of
35312 >bounds>,
35313 >  0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 o
35314 >ut
35315 >of bounds>, 0x42133cec "\004", 0xbffff1fc "",
35316 >  0x4204533d "\201���\016", 0x42131a14 " \031\023
35317 >B�h\001@`�"}
35318 >        len = 4
35319 >        i = 0
35320 >        lastc = 45 '-'
35321 >#2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:32
35322 >1
35323 >        args = 0x0
35324 >        modes = 0x0
35325 >        modes_orig = 0x0
35326 >        md = (struct modedata *) 0x0
35327 >        which = -1
35328 >        add = 0
35329 >        i = 0
35330 >        c = 0 '\0'
35331 >#3  0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at ma
35332 >in.c:269
35333 >        now = 1065393142
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.
35339 >(gdb)
35340 >
35341 >
35342 >------------------------------------------------------------------
35343 >To unsubscribe or change your subscription options, visit:
35344 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
35345
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>
35352
35353 Upgrade?
35354 ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
35355 18:41:36 BRT 2003
35356 -
35357
35358 Its the last version.......
35359
35360 Diego B. Contezini
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....
35366
35367
35368 > Upgrade.
35369 >
35370 >   --Andrew Church
35371 >     achurch@achurch.org
35372 >     http://achurch.org/
35373 >
35374 > >Sometimes has occur this bug, last 1 year....
35375 > >on a network with 30k registers, its happening with latency of 3.. 4
35376 > >days....
35377 > >
35378 > >someone have any idea?
35379 > >
35380 > >#0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
35381 > >av=0xbfffeec8) at channels.c:278
35382 > >278         while (*s) {
35383 > >(gdb) bt'
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>
35388 > >        add = 1
35389 > >        modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
35390 > >#1  0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:68
35391 > >0
35392 > >        buf =
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???????????
35396 > >?
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\
35401 > >000\000\0
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
35411 > >of
35412 > >bounds>,
35413 > >  0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 o
35414 > >ut
35415 > >of bounds>, 0x42133cec "\004", 0xbffff1fc "",
35416 > >  0x4204533d "\201?????????\016", 0x42131a14 " \031\023
35417 > >B???h\001@`???"}
35418 > >        len = 4
35419 > >        i = 0
35420 > >        lastc = 45 '-'
35421 > >#2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:32
35422 > >1
35423 > >        args = 0x0
35424 > >        modes = 0x0
35425 > >        modes_orig = 0x0
35426 > >        md = (struct modedata *) 0x0
35427 > >        which = -1
35428 > >        add = 0
35429 > >        i = 0
35430 > >        c = 0 '\0'
35431 > >#3  0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at ma
35432 > >in.c:269
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.
35439 > >(gdb)
35440 > >
35441 > >
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
35448 >
35449
35450
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>
35457
35458 >Upgrade?
35459 >ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
35460 >18:41:36 BRT 2003
35461 >-
35462 >
35463 >Its the last version.......
35464
35465      Then send a full debug log (from startup to crash), or I can't help.
35466
35467   --Andrew Church
35468     achurch@achurch.org
35469     http://achurch.org/
35470
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>
35477
35478 And how should be this log? i sent a backtrace......
35479
35480 Diego B. Contezini
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....
35486
35487
35488 > >Upgrade?
35489 > >ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
35490 > >18:41:36 BRT 2003
35491 > >-
35492 > >
35493 > >Its the last version.......
35494 >
35495 >      Then send a full debug log (from startup to crash), or I can't help.
35496 >
35497 >   --Andrew Church
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
35503 >
35504
35505
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>
35512
35513 >And how should be this log? i sent a backtrace......
35514
35515 RTFM (FAQ Z.3)
35516
35517   --Andrew Church
35518     achurch@achurch.org
35519     http://achurch.org/
35520
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>
35527
35528 Read....
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
35531 nofork.....
35532
35533 Cya
35534 Diego B. Contezini
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....
35540
35541
35542 > >And how should be this log? i sent a backtrace......
35543 >
35544 > RTFM (FAQ Z.3)
35545 >
35546 >   --Andrew Church
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
35552 >
35553
35554
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>
35561
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).
35564
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...
35571
35572 First: IS that what it's supposed to do?
35573
35574 Second: If so, it's not working...
35575
35576 Saturn
35577 www.jetirc.net
35578
35579
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>
35586
35587
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.
35591
35592 I copy the sintaz of mail-auth ( it's in italian )
35593
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:
35602             /msg %s AUTH %09d
35603
35604         La registrazione del tuo nick sara' confermata e il tuo nickname
35605         sara' protetto da eventuali tentativi di abuso o furto.
35606
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.
35610
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.
35614
35615
35616         Sono inoltre disponibili i seguenti servizi:
35617
35618         - MusiChat Forum
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.
35624
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.
35630
35631
35632         Per una connessione piu' veloce e sicura e' vivamente
35633         consigliato l'utilizzo del seguente server: irc.musichat.net
35634
35635         MusiChat Net Community
35636
35637         Questo messaggio e stato inviato su richiesta di %s in risposta a %s
35638         %s@%s.
35639
35640
35641
35642
35643 I read the istruction for translate.
35644
35645 The error is:
35646
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
35650
35651
35652 Some one can help me?
35653 the email body is too long?
35654
35655 Thx
35656
35657 Alex
35658
35659
35660
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>
35667
35668      You have the wrong number of %-tokens in your message.
35669
35670   --Andrew Church
35671     achurch@achurch.org
35672     http://achurch.org/
35673
35674 >
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.
35678 >
35679 >I copy the sintaz of mail-auth ( it's in italian )
35680 >
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
35690 >
35691 >        La registrazione del tuo nick sara' confermata e il tuo nickname
35692 >        sara' protetto da eventuali tentativi di abuso o furto.
35693 >
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.
35697 >
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.
35701 >
35702 >
35703 >        Sono inoltre disponibili i seguenti servizi:
35704 >
35705 >        - MusiChat Forum
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.
35711 >
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.
35717 >
35718 >
35719 >        Per una connessione piu' veloce e sicura e' vivamente
35720 >        consigliato l'utilizzo del seguente server: irc.musichat.net
35721 >
35722 >        MusiChat Net Community
35723 >
35724 >        Questo messaggio e stato inviato su richiesta di %s in risposta a %s
35725 >        %s@%s.
35726 >
35727 >
35728 >
35729 >
35730 >I read the istruction for translate.
35731 >
35732 >The error is:
35733 >
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
35737 >
35738 >
35739 >Some one can help me?
35740 >the email body is too long?
35741 >
35742 >Thx
35743 >
35744 >Alex
35745 >
35746 >
35747 >------------------------------------------------------------------
35748 >To unsubscribe or change your subscription options, visit:
35749 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
35750
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>
35756
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 ?
35765
35766 ######################################################
35767 modules/chanserv/check.c
35768 ...
35769 void check_chan_user_modes(const char *source, struct c_userlist *u,
35770                            Channel *c, int32 oldmodes)
35771 ...
35772         if ((res & ~modes) & CUMODE_o) {
35773             ci->last_used = time(NULL);
35774             put_channelinfo(ci);
35775         }
35776 ...
35777 ######################################################
35778
35779 |SaMaN|
35780
35781
35782
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>
35788
35789 Also it does not update last_used time on +a flag.
35790
35791 Temporary fix
35792 ---------------
35793
35794 edit /modules/chanserv/check.c
35795
35796 find line
35797 -------------------------------------------------------------------------
35798         local_set_cumodes(c, '+', res & ~modes, user->nick);
35799 -------------------------------------------------------------------------
35800 add below
35801 ------------------------------------------------------------------------
35802         int16 cumode_q = mode_char_to_flag('q',MODE_CHANUSER);
35803         int16 cumode_a = mode_char_to_flag('a',MODE_CHANUSER);
35804
35805         if ((res & ~modes) & cumode_q) {
35806             ci->last_used = time(NULL);
35807             put_channelinfo(ci);
35808         }
35809
35810         if ((res & ~modes) & cumode_a) {
35811             ci->last_used = time(NULL);
35812             put_channelinfo(ci);
35813         }
35814 -------------------------------------------------------------------------
35815 save and compile and run and enjoy :)
35816 -------------------------------------------------------------------------
35817
35818 |SaMaN|
35819
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 ?
35825
35826
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
35831 mode:
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
35834 to
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 ?
35837 >
35838 > ######################################################
35839 > modules/chanserv/check.c
35840 > ...
35841 > void check_chan_user_modes(const char *source, struct c_userlist *u,
35842 >                            Channel *c, int32 oldmodes)
35843 > ...
35844 >         if ((res & ~modes) & CUMODE_o) {
35845 >             ci->last_used = time(NULL);
35846 >             put_channelinfo(ci);
35847 >         }
35848 > ...
35849 > ######################################################
35850 >
35851 > |SaMaN|
35852 >
35853 >
35854
35855
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>
35861
35862 Haven't seen a reply to this one, so thought I'd better make sure this went
35863 through....
35864
35865 ----- Original Message -----
35866 Sent: Friday, October 10, 2003 3:48 PM
35867 Subject: Akill problem in 5.0.22
35868
35869
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).
35872
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...
35879
35880 First: IS that what it's supposed to do?
35881
35882 Second: If so, it's not working...
35883
35884 Saturn
35885 www.jetirc.net
35886
35887
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>
35894
35895 RTFM
35896
35897   --Andrew Church
35898     achurch@achurch.org
35899     http://achurch.org/
35900
35901 >Haven't seen a reply to this one, so thought I'd better make sure this went
35902 >through....
35903 >
35904 >----- Original Message -----
35905 >Sent: Friday, October 10, 2003 3:48 PM
35906 >Subject: Akill problem in 5.0.22
35907 >
35908 >
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).
35911 >
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...
35918 >
35919 >First: IS that what it's supposed to do?
35920 >
35921 >Second: If so, it's not working...
35922 >
35923 >Saturn
35924 >www.jetirc.net
35925 >
35926 >------------------------------------------------------------------
35927 >To unsubscribe or change your subscription options, visit:
35928 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
35929
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>
35936
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
35939
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
35943 it first.
35944     Example: ImmediatelySendAutokill
35945
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
35951 kill them.
35952
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?
35957
35958 Thanks
35959 Saturn
35960
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
35966
35967
35968 RTFM
35969
35970   --Andrew Church
35971     achurch@achurch.org
35972     http://achurch.org/
35973
35974 >Haven't seen a reply to this one, so thought I'd better make sure this went
35975 >through....
35976 >
35977 >----- Original Message -----
35978 >Sent: Friday, October 10, 2003 3:48 PM
35979 >Subject: Akill problem in 5.0.22
35980 >
35981 >
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).
35984 >
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
35987 scanning
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...
35992 >
35993 >First: IS that what it's supposed to do?
35994 >
35995 >Second: If so, it's not working...
35996 >
35997 >Saturn
35998 >www.jetirc.net
35999 >
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
36006
36007
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>
36014
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
36019 >kill them.
36020
36021      The documentation says nothing about this.  RTFM again.
36022
36023   --Andrew Church
36024     achurch@achurch.org
36025     http://achurch.org/
36026
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>
36034
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
36040 to deal with it.
36041
36042 Ballsy
36043
36044
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
36048 >
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
36052 >it first.
36053 >     Example: ImmediatelySendAutokill
36054 >
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
36060 >kill them.
36061 >
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?
36066 >
36067 >Thanks
36068 >Saturn
36069 >
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
36075 >
36076 >
36077 >RTFM
36078 >
36079 >   --Andrew Church
36080 >     achurch@achurch.org
36081 >     http://achurch.org/
36082 >
36083 > >Haven't seen a reply to this one, so thought I'd better make sure this went
36084 > >through....
36085 > >
36086 > >----- Original Message -----
36087 > >Sent: Friday, October 10, 2003 3:48 PM
36088 > >Subject: Akill problem in 5.0.22
36089 > >
36090 > >
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).
36093 > >
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
36096 >scanning
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...
36101 > >
36102 > >First: IS that what it's supposed to do?
36103 > >
36104 > >Second: If so, it's not working...
36105 > >
36106 > >Saturn
36107 > >www.jetirc.net
36108 > >
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
36115 >
36116 >------------------------------------------------------------------
36117 >To unsubscribe or change your subscription options, visit:
36118 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
36119
36120
36121
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>
36128
36129 >From a.html in the /docs directory:
36130 ---------------
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
36135 it first.
36136     Example: ImmediatelySendAutokill
36137 --------------
36138
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 ------------------------
36153
36154 4.html#oper.akill doesn't mention it at all.
36155
36156 -----------------
36157
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!!!
36165
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?
36171
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???????
36178
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.
36188
36189 Saturn
36190
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
36196
36197
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
36202 >kill them.
36203
36204      The documentation says nothing about this.  RTFM again.
36205
36206   --Andrew Church
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
36212
36213
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>
36221
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.
36229
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
36236 programming...
36237
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
36245
36246
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
36252 to deal with it.
36253
36254 Ballsy
36255
36256
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
36260 >
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
36264 >it first.
36265 >     Example: ImmediatelySendAutokill
36266 >
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
36272 >kill them.
36273 >
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?
36278 >
36279 >Thanks
36280 >Saturn
36281 >
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
36287 >
36288 >
36289 >RTFM
36290 >
36291 >   --Andrew Church
36292 >     achurch@achurch.org
36293 >     http://achurch.org/
36294 >
36295 > >Haven't seen a reply to this one, so thought I'd better make sure this
36296 went
36297 > >through....
36298 > >
36299 > >----- Original Message -----
36300 > >Sent: Friday, October 10, 2003 3:48 PM
36301 > >Subject: Akill problem in 5.0.22
36302 > >
36303 > >
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).
36306 > >
36307 > >I just today added an akill (+0 time) .. I DO have the immediate auto
36308 kill
36309 > >option un-commented in the modules.conf, but it still didn't bother
36310 >scanning
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
36313 thought
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...
36316 > >
36317 > >First: IS that what it's supposed to do?
36318 > >
36319 > >Second: If so, it's not working...
36320 > >
36321 > >Saturn
36322 > >www.jetirc.net
36323 > >
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
36330 >
36331 >------------------------------------------------------------------
36332 >To unsubscribe or change your subscription options, visit:
36333 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
36334
36335
36336 ------------------------------------------------------------------
36337 To unsubscribe or change your subscription options, visit:
36338 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
36339
36340
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>
36346
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.
36348
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
36350
36351 Please just calm down, and talk this out rationally before you start jumping down ppls throats :p
36352
36353 /*****************************************
36354  *     Craig "FrostyCoolSlug" McLure
36355  * InspIRCd   - http://www.inspircd.org
36356  * ChatSpike  - http://www.chatspike.net
36357  ****************************************/
36358
36359
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  ****************************************/
36366
36367 /****** - Begin Original Message - ******/
36368
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.
36376 >
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
36383 >programming...
36384 >
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
36392 >
36393 >
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
36399 >to deal with it.
36400 >
36401 >Ballsy
36402 >
36403 >
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
36407 >>
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
36411 >>it first.
36412 >>     Example: ImmediatelySendAutokill
36413 >>
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
36419 >>kill them.
36420 >>
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?
36425 >>
36426 >>Thanks
36427 >>Saturn
36428 >>
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
36434 >>
36435 >>
36436 >>RTFM
36437 >>
36438 >>   --Andrew Church
36439 >>     achurch@achurch.org
36440 >>     http://achurch.org/
36441 >>
36442 >> >Haven't seen a reply to this one, so thought I'd better make sure this
36443 >went
36444 >> >through....
36445 >> >
36446 >> >----- Original Message -----
36447 >> >Sent: Friday, October 10, 2003 3:48 PM
36448 >> >Subject: Akill problem in 5.0.22
36449 >> >
36450 >> >
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).
36453 >> >
36454 >> >I just today added an akill (+0 time) .. I DO have the immediate auto
36455 >kill
36456 >> >option un-commented in the modules.conf, but it still didn't bother
36457 >>scanning
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
36460 >thought
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...
36463 >> >
36464 >> >First: IS that what it's supposed to do?
36465 >> >
36466 >> >Second: If so, it's not working...
36467 >> >
36468 >> >Saturn
36469 >> >www.jetirc.net
36470 >> >
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
36477 >>
36478 >>------------------------------------------------------------------
36479 >>To unsubscribe or change your subscription options, visit:
36480 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
36481 >
36482 >
36483 >------------------------------------------------------------------
36484 >To unsubscribe or change your subscription options, visit:
36485 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
36486 >
36487 >------------------------------------------------------------------
36488 >To unsubscribe or change your subscription options, visit:
36489 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
36490 >
36491 >.
36492
36493 /******* - End Original Message - *******/
36494
36495
36496
36497
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>
36504
36505      You know, I might have been more forgiving if this hadn't been gone
36506 over on this list (twice!) before:
36507
36508 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/002305.html
36509 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/003215.html
36510
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
36513 edification:
36514
36515 F.10. Services doesn't kill users matching a newly-added autokill mask even
36516 if ImmediatelySendAutokill is set.
36517
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.
36524
36525         Note that some IRC servers will themselves kill users matching a
36526         newly-added autokill; this is unrelated to Services.
36527
36528   --Andrew Church
36529     achurch@achurch.org
36530     http://achurch.org/
36531
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>
36541
36542 Saturn wrote:
36543
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.
36551 >
36552 >
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
36559 do this.
36560
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).
36565
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.
36569
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.
36577
36578
36579
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>
36588
36589 On Saturday 18 October 2003 07:20, Robert F Merrill wrote:
36590 > Saturn 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.
36598 >
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
36605 > do this.
36606
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.
36609
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.
36614
36615 <<V13>>
36616
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>
36623
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)
36634
36635 root@irc(/home/ircadmin/services/lib)# ls -la core.12631
36636 -rw-------    1 ircadmin ircadmin 47374336 Oct 18 16:05 core.12631
36637
36638
36639 continue on the next message......
36640
36641
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>
36648
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;
36653 (gdb) bt'
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
36657         s = 0x806aa3e ""
36658 #1  0x0804d342 in set_cmode (sender=0x81db058 "ChanServ", channel=0xa905d00)
36659 at actions.c:446
36660         parambuf =
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"...
36669         len = 10
36670         flag = 1
36671         params = 1
36672         is_chanuser = 1
36673         args = 0xbfffe6d0 "RDcoCOREcorei??i??i??i??o"
36674         modes = 0xbfffeae2 ""
36675         modes_orig = 0xbfffeae0 "+o"
36676         md = (struct modedata *) 0x806aa00
36677         which = 0
36678         add = 1
36679         i = 1
36680         c = 111 'o'
36681 #2  0x400895ff in local_set_cumodes (c=0xa905d00, plusminus=43 '+', modes=1,
36682 nick=0xab7f2e8 "balsanelli") at check.c:432
36683         buf = "+o"
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).."...
36688         s = 0xbfffe6e1 ""
36689 #3  0x40088d74 in check_chan_user_modes (source=0xbfffeed0 "|-Frango-|",
36690 u=0xab34ff0, c=0xa905d00, oldmodes=1)
36691     at check.c:214
36692         user = (User *) 0xab7f2d8
36693         ci = (ChannelInfo *) 0xa571940
36694         modes = 0
36695         is_servermode = 0
36696         res = 1
36697 #4  0x400820ed in do_channel_umode_change (source=0xbfffeed0 "|-Frango-|",
36698 c=0xa905d00, u=0xab34ff0, oldmodes=1)
36699     at main.c:354
36700 No locals.
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
36705         res = 0
36706         i = 0
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---
36710     at channels.c:409
36711         u = (struct c_userlist *) 0xab34ff0
36712         user = (User *) 0xab7f2d8
36713         oldmode = 1
36714 #7  0x0804e97e in do_cmode (source=0xbfffeed0 "|-Frango-|", ac=0,
36715 av=0xa853130) at channels.c:302
36716         modechar = 111 'o'
36717         flag = 1
36718         params = -1073746288
36719         chan = (Channel *) 0xa905d00
36720         s = 0xbfffeca5 ""
36721         add = 0
36722         modestr = 0xbfffec9e "-oooooo"
36723 #8  0x080557ff in m_mode (source=0xbfffeed0 "|-Frango-|", ac=8,
36724 av=0xa853110) at messages.c:101
36725 No locals.
36726 #9  0x0805920e in process () at process.c:133
36727         m = (Message *) 0x8067dd8
36728         source =
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
36731 5\b"
36732         cmd =
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"
36736         buf =
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"
36744         ac = 8
36745         av = (char **) 0xa853110
36746 #10 0x0805507d in readline_callback (s=0xa851ae0, param_unused=0x50) at
36747 main.c:177
36748 No locals.
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."...
36754         left = 80
36755         newleft = 80
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}
36759         i = 4
36760         res = 260
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---
36765         now = 1066500331
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.
36771 (gdb)
36772
36773
36774
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>
36781
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.
36789
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?
36803
36804 Thank you all for your time.
36805
36806 Saturn
36807
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
36813
36814
36815      You know, I might have been more forgiving if this hadn't been gone
36816 over on this list (twice!) before:
36817
36818 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/002305.html
36819 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/003215.html
36820
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
36823 edification:
36824
36825 F.10. Services doesn't kill users matching a newly-added autokill mask even
36826 if ImmediatelySendAutokill is set.
36827
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.
36834
36835 Note that some IRC servers will themselves kill users matching a
36836 newly-added autokill; this is unrelated to Services.
36837
36838   --Andrew Church
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
36844
36845
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>
36851
36852 If it helps, more lines up.. of debugging...
36853
36854
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)
36867
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>
36879
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.
36885
36886 Ballsy
36887
36888
36889 At 12:49 PM 18/10/2003, V13 wrote:
36890 >On Saturday 18 October 2003 07:20, Robert F Merrill wrote:
36891 > > Saturn 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.
36899 > >
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
36906 > > do this.
36907 >
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.
36910 >
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.
36915 >
36916 ><<V13>>
36917 >------------------------------------------------------------------
36918 >To unsubscribe or change your subscription options, visit:
36919 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
36920
36921
36922
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>
36928
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>
36936
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
36939
36940 ciao
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>
36950
36951 Andrew, have anything more of dumping/debugging that i can do/give for helps
36952 fixing this bug..?
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)....
36955 anything more?
36956
36957
36958 Thanks for all
36959
36960
36961 Diego B. Contezini
36962
36963
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>
36969
36970
36971
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>
36977
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
36980 18:41:36 BRT 2003)
36981 yes, 5.0.23 is the last.. but nothing has changed about the bug...
36982
36983  here is the debugging:
36984
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
36989 #Euevc
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
36997 +stmipl 1
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)
37009
37010
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;
37016 (gdb) bt'
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
37020         s = 0x806aa3e ""
37021 #1  0x0804d342 in set_cmode (sender=0x81db058 "ChanServ", channel=0xa905d00)
37022 at actions.c:446
37023         parambuf =
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"...
37032         len = 10
37033         flag = 1
37034         params = 1
37035         is_chanuser = 1
37036         args = 0xbfffe6d0 "RDcoCOREcorei??i??i??i??o"
37037         modes = 0xbfffeae2 ""
37038         modes_orig = 0xbfffeae0 "+o"
37039         md = (struct modedata *) 0x806aa00
37040         which = 0
37041         add = 1
37042         i = 1
37043         c = 111 'o'
37044 #2  0x400895ff in local_set_cumodes (c=0xa905d00, plusminus=43 '+', modes=1,
37045 nick=0xab7f2e8 "balsanelli") at check.c:432
37046         buf = "+o"
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).."...
37051         s = 0xbfffe6e1 ""
37052 #3  0x40088d74 in check_chan_user_modes (source=0xbfffeed0 "|-Frango-|",
37053 u=0xab34ff0, c=0xa905d00, oldmodes=1)
37054     at check.c:214
37055         user = (User *) 0xab7f2d8
37056         ci = (ChannelInfo *) 0xa571940
37057         modes = 0
37058         is_servermode = 0
37059         res = 1
37060 #4  0x400820ed in do_channel_umode_change (source=0xbfffeed0 "|-Frango-|",
37061 c=0xa905d00, u=0xab34ff0, oldmodes=1)
37062     at main.c:354
37063 No locals.
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
37068         res = 0
37069         i = 0
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---
37073     at channels.c:409
37074         u = (struct c_userlist *) 0xab34ff0
37075         user = (User *) 0xab7f2d8
37076         oldmode = 1
37077 #7  0x0804e97e in do_cmode (source=0xbfffeed0 "|-Frango-|", ac=0,
37078 av=0xa853130) at channels.c:302
37079         modechar = 111 'o'
37080         flag = 1
37081         params = -1073746288
37082         chan = (Channel *) 0xa905d00
37083         s = 0xbfffeca5 ""
37084         add = 0
37085         modestr = 0xbfffec9e "-oooooo"
37086 #8  0x080557ff in m_mode (source=0xbfffeed0 "|-Frango-|", ac=8,
37087 av=0xa853110) at messages.c:101
37088 No locals.
37089 #9  0x0805920e in process () at process.c:133
37090         m = (Message *) 0x8067dd8
37091         source =
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
37094 5\b"
37095         cmd =
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"
37099         buf =
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"
37107         ac = 8
37108         av = (char **) 0xa853110
37109 #10 0x0805507d in readline_callback (s=0xa851ae0, param_unused=0x50) at
37110 main.c:177
37111 No locals.
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."...
37117         left = 80
37118         newleft = 80
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}
37122         i = 4
37123         res = 260
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---
37128         now = 1066500331
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
37145 cs             0x23     35
37146 ss             0x2b     43
37147 ds             0x2b     43
37148 es             0x2b     43
37149 fs             0x0      0
37150 gs             0x33     51
37151 (gdb)
37152
37153
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
37166 ...
37167 model name      : Pentium III (Coppermine)
37168 stepping        : 10
37169 cpu MHz         : 999.752
37170 cache size      : 256 KB
37171 ...
37172 root@irc(/home/ircadmin/services)# free
37173              total       used       free     shared    buffers     cached
37174 Mem:        513792     482248      31544          0      69492     274980
37175
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*
37185
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
37197
37198
37199 If it helps, here is the debugging of the last two cores, on gdb:
37200 ----------------
37201 FIRST:
37202 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
37203 av=0xbfffdc38)
37204     at channels.c:278
37205 278         while (*s) {
37206 (gdb) bt'
37207 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
37208 av=0xbfffdc38)
37209     at channels.c:278
37210         chan = (Channel *) 0xa87d1e0
37211         s = 0x1f73746f <Address 0x1f73746f out of bounds>
37212         add = 1
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
37222 \006\b"...
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>}
37232         len = 5
37233 ---Type <return> to continue, or q <return> to quit---
37234         i = 0
37235         lastc = 45 '-'
37236 #2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
37237         args = 0x0
37238         modes = 0x0
37239         modes_orig = 0x0
37240         md = (struct modedata *) 0x0
37241         which = -1
37242         add = 0
37243         i = 0
37244         c = 0 '\0'
37245 #3  0x080553a3 in main (ac=1, av=0xbfffe574, envp=0xbfffe57c) at main.c:269
37246         now = 1067891066
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.
37252 -----------
37253
37254 SECOND:
37255 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
37256 av=0xbffff2b8)
37257     at channels.c:278
37258 278         while (*s) {
37259 (gdb) bt'
37260 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
37261 av=0xbffff2b8)
37262     at channels.c:278
37263         chan = (Channel *) 0xa9be840
37264         s = 0xbf000000 <Address 0xbf000000 out of bounds>
37265         add = 1
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>}
37282         len = 5
37283         i = 0
37284         lastc = 45 '-'
37285 #2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
37286 ---Type <return> to continue, or q <return> to quit---
37287         args = 0x0
37288         modes = 0x0
37289         modes_orig = 0x0
37290         md = (struct modedata *) 0x0
37291         which = -1
37292         add = 0
37293         i = 0
37294         c = 0 '\0'
37295 #3  0x080553a3 in main (ac=1, av=0xbffffbf4, envp=0xbffffbfc) at main.c:269
37296         now = 1067706795
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.
37302 (gdb)
37303 -------
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
37306 this bug...
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
37310 anything....
37311
37312 Thanks for all development, this is really a bealtifull software...
37313 (and sorry for my bad english)
37314
37315 Diego B. Contezini aka destruct_ #irc.redesul.net
37316
37317
37318
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>
37324
37325 If it helps, im using Bahamut here....
37326
37327
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>
37334
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 ?
37343
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.
37353
37354   --Andrew Church
37355     achurch@achurch.org
37356     http://achurch.org/
37357
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>
37363
37364 I'm getting this too - it's just started happening in 5.0.23:
37365
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'
37370
37371 gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
37372
37373 Russ
37374
37375
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>
37381
37382
37383
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>
37389
37390 Hi,
37391
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:
37395
37396 ***************************
37397 -
37398 -NickServ- nick is hello world
37399 -
37400 -NickServ- Is online from: ~test@just.a.test.co.za
37401 -
37402 -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
37403 -
37404 -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
37405 -
37406 -NickServ- Last quit message: anythinggggg
37407 -
37408 -NickServ- Options: Kill protection, Security
37409 -
37410 ***************************
37411
37412 the new line I'm suggesting is something like:
37413
37414 ***************************
37415 -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
37416 ***************************
37417
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).
37423
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)
37427
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)
37430
37431 Many thanks to all of who developed IRCservices ...etc ...etc ...etc
37432
37433 sincerely,
37434 David
37435
37436 _________________________________________________________________
37437 Get MSN 8 and enjoy automatic e-mail virus protection.
37438 http://join.msn.com/?page=features/virus
37439
37440
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>
37448
37449 Or how about rather letting users decide what timezone they're in and
37450 services outputs all timestamps in their local time?
37451
37452
37453 | By us44ever . <us44ever@hotmail.com>
37454 |                                          [ 2003-08-28 18:45 +0200 ]
37455 > Hi,
37456 >
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:
37460 >
37461 > ***************************
37462 > -
37463 > -NickServ- nick is hello world
37464 > -
37465 > -NickServ- Is online from: ~test@just.a.test.co.za
37466 > -
37467 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
37468 > -
37469 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
37470 > -
37471 > -NickServ- Last quit message: anythinggggg
37472 > -
37473 > -NickServ- Options: Kill protection, Security
37474 > -
37475 > ***************************
37476 >
37477 > the new line I'm suggesting is something like:
37478 >
37479 > ***************************
37480 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
37481 > ***************************
37482 >
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).
37488 >
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)
37492 >
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)
37495 >
37496 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
37497 >
37498 > sincerely,
37499 > David
37500 >
37501 > _________________________________________________________________
37502 > Get MSN 8 and enjoy automatic e-mail virus protection.
37503 > http://join.msn.com/?page=features/virus
37504 >
37505 > ------------------------------------------------------------------
37506 > To unsubscribe or change your subscription options, visit:
37507 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
37508
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>
37516
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
37524
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
37530
37531
37532 Or how about rather letting users decide what timezone they're in and
37533 services outputs all timestamps in their local time?
37534
37535
37536 | By us44ever . <us44ever@hotmail.com>
37537 |                                          [ 2003-08-28 18:45 +0200 ]
37538 > Hi,
37539 >
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:
37543 >
37544 > ***************************
37545 > -
37546 > -NickServ- nick is hello world
37547 > -
37548 > -NickServ- Is online from: ~test@just.a.test.co.za
37549 > -
37550 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
37551 > -
37552 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
37553 > -
37554 > -NickServ- Last quit message: anythinggggg
37555 > -
37556 > -NickServ- Options: Kill protection, Security
37557 > -
37558 > ***************************
37559 >
37560 > the new line I'm suggesting is something like:
37561 >
37562 > ***************************
37563 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
37564 > ***************************
37565 >
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).
37571 >
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)
37575 >
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)
37578 >
37579 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
37580 >
37581 > sincerely,
37582 > David
37583 >
37584 > _________________________________________________________________
37585 > Get MSN 8 and enjoy automatic e-mail virus protection.
37586 > http://join.msn.com/?page=features/virus
37587 >
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
37594
37595
37596
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>
37602
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..
37604
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
37607
37608 *shock*
37609
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  ****************************************/
37617
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  ****************************************/
37624
37625 /****** - Begin Original Message - ******/
37626
37627 >Hi,
37628 >
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:
37632 >
37633 >***************************
37634 >-
37635 >-NickServ- nick is hello world
37636 >-
37637 >-NickServ- Is online from: ~test@just.a.test.co.za
37638 >-
37639 >-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
37640 >-
37641 >-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
37642 >-
37643 >-NickServ- Last quit message: anythinggggg
37644 >-
37645 >-NickServ- Options: Kill protection, Security
37646 >-
37647 >***************************
37648 >
37649 >the new line I'm suggesting is something like:
37650 >
37651 >***************************
37652 >-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
37653 >***************************
37654 >
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).
37660 >
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)
37664 >
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)
37667 >
37668 >Many thanks to all of who developed IRCservices ...etc ...etc ...etc
37669 >
37670 >sincerely,
37671 >David
37672 >
37673 >_________________________________________________________________
37674 >Get MSN 8 and enjoy automatic e-mail virus protection.
37675 >http://join.msn.com/?page=features/virus
37676 >
37677 >------------------------------------------------------------------
37678 >To unsubscribe or change your subscription options, visit:
37679 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
37680
37681 /******* - End Original Message - *******/
37682
37683
37684
37685
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>
37691
37692 We're having a small problem with suspended channel.
37693
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.
37696
37697 Also with suspended nick , when the suspencion expire, the services crash
37698 We're using:
37699
37700 ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
37701
37702
37703 Thanks
37704 Marc
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>
37713
37714 hmm.. what OS, compiler version etc are you using?
37715
37716 after a test, i got the following:
37717
37718 /cs id #abc 00376370
37719 -ChanServ- Channel #abc is suspended and may not be used or identified for.
37720
37721 /cs drop #abc
37722 [23:20] -ChanServ- Channel  is suspended and may not be used or identified for.
37723
37724 only prob i got was it missed the channel name in the second message :)
37725
37726 /cs drop #abc
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  ****************************************/
37734
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  ****************************************/
37741
37742 /****** - Begin Original Message - ******/
37743
37744 >We're having a small problem with suspended channel.
37745 >
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.
37748 >
37749 >Also with suspended nick , when the suspencion expire, the services crash
37750 >We're using:
37751 >
37752 >ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
37753 >
37754 >
37755 >Thanks
37756 >Marc
37757 >------------------------------------------------------------------
37758 >To unsubscribe or change your subscription options, visit:
37759 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
37760
37761 /******* - End Original Message - *******/
37762
37763
37764
37765
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>
37772
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...
37777
37778 Just an idea... I now await the half dozen people who will proceed to tell
37779 me how stupid my idea is....
37780
37781 Saturn
37782 irc.jetirc.net
37783
37784
37785
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>
37793
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.
37798
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..
37802 >
37803 > /time services.chatspike.net
37804 > [22:28] ??? Date / time at services.chatspike.net- Thu Aug 28 17:28:57
37805 > 2003 EDT
37806 >
37807 > *shock*
37808 >
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 >  ****************************************/
37816 >
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 >  ****************************************/
37823 >
37824 > /****** - Begin Original Message - ******/
37825 >
37826 >>Hi,
37827 >>
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:
37831 >>
37832 >>***************************
37833 >>-
37834 >>-NickServ- nick is hello world
37835 >>-
37836 >>-NickServ- Is online from: ~test@just.a.test.co.za
37837 >>-
37838 >>-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
37839 >>-
37840 >>-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
37841 >>-
37842 >>-NickServ- Last quit message: anythinggggg
37843 >>-
37844 >>-NickServ- Options: Kill protection, Security
37845 >>-
37846 >>***************************
37847 >>
37848 >>the new line I'm suggesting is something like:
37849 >>
37850 >>***************************
37851 >>-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
37852 >>***************************
37853 >>
37854 >>This will help our users to compare the time that user was last seen and
37855 >> the
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
37859 >> GMT
37860 >>(last seen time was before: 10 days, 3hours and 24 sec ago).
37861 >>
37862 >>Note that I saw both of these features, in other services I don't
37863 >> remember
37864 >>there names (but they aren't as stable as ircservices5) (it was something
37865 >>like ptlink services, and magik II)
37866 >>
37867 >>That's all, I would really like to see it on the next version (or if you
37868 >> can
37869 >>show me how to do it, as I'm not a programmer)
37870 >>
37871 >>Many thanks to all of who developed IRCservices ...etc ...etc ...etc
37872 >>
37873 >>sincerely,
37874 >>David
37875 >>
37876 >>_________________________________________________________________
37877 >>Get MSN 8 and enjoy automatic e-mail virus protection.
37878 >>http://join.msn.com/?page=features/virus
37879 >>
37880 >>------------------------------------------------------------------
37881 >>To unsubscribe or change your subscription options, visit:
37882 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
37883 >
37884 > /******* - End Original Message - *******/
37885 >
37886 >
37887 >
37888 > ------------------------------------------------------------------
37889 > To unsubscribe or change your subscription options, visit:
37890 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
37891 >
37892
37893
37894 --
37895 Best Regards,
37896 playa
37897 Network Founder/CEO
37898 DreamChat IRC Network - irc.dreamchat.org
37899 http://www.dreamchat.org
37900
37901
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>
37908
37909 On Thursday, Aug 28, 2003, at 20:46 US/Pacific, playa wrote:
37910
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.
37915
37916 That's a client thing.  Some clients might alias /time as a CTCP TIME
37917 for a specific user, or similar.
37918
37919 -- Quension
37920
37921
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>
37930
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.
37935
37936 Some clients use stupid aliases for CTCP commands, for example:
37937
37938 /version <nick> = /CTCP <nick> VERSION,
37939 /time <nick> = /CTCP <nick> TIME,
37940 /finger <nick> = /CTCP <nick> TIME
37941
37942 This is why nothing works the way you expected.
37943
37944 --
37945 Krisztian Romek
37946 r-krisztian@softhome.net
37947
37948
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>
37954
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).
37958
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
37962
37963
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>
37969
37970
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.
37976
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
37980
37981
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>
37987
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.
37989
37990 And i'll Quote Elijah:
37991
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
37994 be 'no.'"
37995
37996
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  ****************************************/
38004
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  ****************************************/
38011
38012 /****** - Begin Original Message - ******/
38013
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.
38019 >
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
38023 >
38024 >------------------------------------------------------------------
38025 >To unsubscribe or change your subscription options, visit:
38026 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
38027 >.
38028
38029 /******* - End Original Message - *******/
38030
38031
38032
38033
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>
38039
38040 its a stupid idea!!! :p
38041
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
38043
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  ****************************************/
38051
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  ****************************************/
38058
38059 /****** - Begin Original Message - ******/
38060
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...
38065 >
38066 >Just an idea... I now await the half dozen people who will proceed to tell
38067 >me how stupid my idea is....
38068 >
38069 >Saturn
38070 >irc.jetirc.net
38071 >
38072 >
38073 >------------------------------------------------------------------
38074 >To unsubscribe or change your subscription options, visit:
38075 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
38076
38077 /******* - End Original Message - *******/
38078
38079
38080
38081
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>
38088
38089 Cheers.
38090
38091 -----Original Message-----
38092 From: ircservices-coding-bounces@ircservices.za.net
38093 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of Craig
38094 McLure
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
38098
38099
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
38102 to annoy me.
38103
38104 And i'll Quote Elijah:
38105
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
38108 be 'no.'"
38109
38110
38111
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>
38117
38118 woops, ok sorry I thought the two e-mails is completely different.
38119
38120
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
38128 >
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.
38132 >
38133 >And i'll Quote Elijah:
38134 >
38135 >"Except it's already been said in the FAQ that it's not going to happen,
38136 >and
38137 >if that made it into the FAQ it would seem the answer is frequently going
38138 >to
38139 >be 'no.'"
38140 >
38141 >
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 >  ****************************************/
38149 >
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 >  ****************************************/
38156 >
38157 >/****** - Begin Original Message - ******/
38158 >
38159 > >Since most people want to see this feature(s) in the next version, it
38160 >would
38161 > >be great to implement it as an optional feature , where it can be
38162 >disabled
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
38165 >fact,
38166 > >it will add another nice feature to the features list of IRCservices5.
38167 > >
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
38171 > >
38172 > >------------------------------------------------------------------
38173 > >To unsubscribe or change your subscription options, visit:
38174 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
38175 > >.
38176 >
38177 >/******* - End Original Message - *******/
38178 >
38179 >
38180 >
38181 >------------------------------------------------------------------
38182 >To unsubscribe or change your subscription options, visit:
38183 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
38184
38185 _________________________________________________________________
38186 MSN 8: Get 6 months for $9.95/month. http://join.msn.com/?page=dept/dialup
38187
38188
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>
38195
38196 Hi
38197 I run ircservices 5.0.21 on FreeBSD 4.8-STABLE. and Ultimate 3.*
38198 I get this in logfile:
38199
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)
38212
38213 and how can I do so that nickserv dont show the realhost of a user in
38214 'ns info nick all'
38215
38216
38217 thanks for help
38218
38219                            Ali "Simorgh"
38220  ______________________________________________________
38221  Many of life's failures are people who did not realize
38222  how close they were to success when they gave up.
38223  Thomas A. Edison
38224  ______________________________________________________
38225
38226
38227
38228
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>
38235
38236 "and how can I do so that nickserv dont show the realhost of a user in
38237 'ns info nick all'"
38238
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
38242 option is set.
38243
38244
38245
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>
38252
38253      Use E-mail if you need communication of that sort.
38254
38255   --Andrew Church
38256     achurch@achurch.org
38257     http://achurch.org/
38258
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
38263 >have been denied.
38264 >
38265 >/chanserv MARK <channel> <reason>
38266 >
38267 >/chanserv info #channel would read the following.
38268 >*#channel has been MARKED by playa - <reason>
38269 >
38270 >Of course only IRCops would be able to view it.
38271 >
38272 >Just an idea i thought of :)
38273 >
38274 >--
38275 >Best Regards,
38276 >playa
38277 >Network Founder/CEO
38278 >DreamChat IRC Network - irc.dreamchat.org
38279 >http://www.dreamchat.org
38280 >
38281 >------------------------------------------------------------------
38282 >To unsubscribe or change your subscription options, visit:
38283 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
38284
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>
38291
38292      Needless complexity.  If you don't want yourself autoopped, then don't
38293 be an auto-op.  It's that simple.
38294
38295   --Andrew Church
38296     achurch@achurch.org
38297     http://achurch.org/
38298
38299 >Hi again
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.
38302 >
38303 >Like:
38304 > SET NOAUTO ON|OFF
38305 >  When NOAUTO is on, ChanServ will not
38306 >  automatically op or voice you in any channels.
38307 >
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.
38310 >
38311 >Or did I miss it?
38312 >
38313 >Thanks
38314 >
38315 >                           Ali "Simorgh"
38316 > ______________________________________________________
38317 > Many of life's failures are people who did not realize
38318 > how close they were to success when they gave up.
38319 > Thomas A. Edison
38320 > ______________________________________________________
38321 >
38322 >
38323 >On Sun, 17 Aug 2003, Russell Garrett wrote:
38324 >
38325 >> Eh? This has been implemented since IRCServices 5a31.
38326 >>
38327 >> Russ
38328 >>
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)
38333 >> >
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
38336 >> > channels.
38337 >> >
38338 >> > Thanks for any help
38339 >>
38340 >> ------------------------------------------------------------------
38341 >> To unsubscribe or change your subscription options, visit:
38342 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
38343 >>
38344 >
38345 >------------------------------------------------------------------
38346 >To unsubscribe or change your subscription options, visit:
38347 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
38348
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>
38356
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.
38360
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
38369 is not complex.
38370
38371 Shaun
38372
38373
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>
38379
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..
38382
38383 or /cs levels #channels DISABLE autoop
38384
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  ****************************************/
38392
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  ****************************************/
38399
38400 /****** - Begin Original Message - ******/
38401
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.
38405 >
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
38414 >is not complex.
38415 >
38416 >Shaun
38417 >
38418 >------------------------------------------------------------------
38419 >To unsubscribe or change your subscription options, visit:
38420 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
38421 >.
38422
38423 /******* - End Original Message - *******/
38424
38425
38426
38427
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>
38435
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..
38438
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.
38441
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
38444
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
38451
38452 Same with ENFORCE set to off as well.
38453
38454 > [snipped obnoxiously long sig]
38455
38456 Shaun Guth
38457
38458
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>
38465
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
38468 >
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
38475
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.
38479
38480   --Andrew Church
38481     achurch@achurch.org
38482     http://achurch.org/
38483
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>
38490
38491 >Can we reconsider adding a Mass memo function for the next release?
38492
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.
38500
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.
38506
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.
38511
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.
38514
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........
38521
38522      This is an interesting thought; I'll think about it for a future
38523 version.
38524
38525   --Andrew Church
38526     achurch@achurch.org
38527     http://achurch.org/
38528
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>
38535
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?
38541
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.
38546
38547   --Andrew Church
38548     achurch@achurch.org
38549     http://achurch.org/
38550
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>
38557
38558 >Is there any tool (silly question) or something or guid to make a language
38559 >file.
38560 >
38561 >I have decided to make a Persian (Farsi) language file.
38562
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.
38567
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.
38570
38571   --Andrew Church
38572     achurch@achurch.org
38573     http://achurch.org/
38574
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>
38581
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
38585
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?
38588
38589   --Andrew Church
38590     achurch@achurch.org
38591     http://achurch.org/
38592
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>
38598
38599
38600
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>
38606
38607 Hi,
38608
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:
38612
38613 ***************************
38614 -
38615 -NickServ- nick is hello world
38616 -
38617 -NickServ- Is online from: ~test@just.a.test.co.za
38618 -
38619 -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
38620 -
38621 -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
38622 -
38623 -NickServ- Last quit message: anythinggggg
38624 -
38625 -NickServ- Options: Kill protection, Security
38626 -
38627 ***************************
38628
38629 the new line I'm suggesting is something like:
38630
38631 ***************************
38632 -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
38633 ***************************
38634
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).
38640
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)
38644
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)
38647
38648 Many thanks to all of who developed IRCservices ...etc ...etc ...etc
38649
38650 sincerely,
38651 David
38652
38653 _________________________________________________________________
38654 Get MSN 8 and enjoy automatic e-mail virus protection.
38655 http://join.msn.com/?page=features/virus
38656
38657
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>
38665
38666 Or how about rather letting users decide what timezone they're in and
38667 services outputs all timestamps in their local time?
38668
38669
38670 | By us44ever . <us44ever@hotmail.com>
38671 |                                          [ 2003-08-28 18:45 +0200 ]
38672 > Hi,
38673 >
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:
38677 >
38678 > ***************************
38679 > -
38680 > -NickServ- nick is hello world
38681 > -
38682 > -NickServ- Is online from: ~test@just.a.test.co.za
38683 > -
38684 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
38685 > -
38686 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
38687 > -
38688 > -NickServ- Last quit message: anythinggggg
38689 > -
38690 > -NickServ- Options: Kill protection, Security
38691 > -
38692 > ***************************
38693 >
38694 > the new line I'm suggesting is something like:
38695 >
38696 > ***************************
38697 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
38698 > ***************************
38699 >
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).
38705 >
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)
38709 >
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)
38712 >
38713 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
38714 >
38715 > sincerely,
38716 > David
38717 >
38718 > _________________________________________________________________
38719 > Get MSN 8 and enjoy automatic e-mail virus protection.
38720 > http://join.msn.com/?page=features/virus
38721 >
38722 > ------------------------------------------------------------------
38723 > To unsubscribe or change your subscription options, visit:
38724 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
38725
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>
38733
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
38741
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
38747
38748
38749 Or how about rather letting users decide what timezone they're in and
38750 services outputs all timestamps in their local time?
38751
38752
38753 | By us44ever . <us44ever@hotmail.com>
38754 |                                          [ 2003-08-28 18:45 +0200 ]
38755 > Hi,
38756 >
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:
38760 >
38761 > ***************************
38762 > -
38763 > -NickServ- nick is hello world
38764 > -
38765 > -NickServ- Is online from: ~test@just.a.test.co.za
38766 > -
38767 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
38768 > -
38769 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
38770 > -
38771 > -NickServ- Last quit message: anythinggggg
38772 > -
38773 > -NickServ- Options: Kill protection, Security
38774 > -
38775 > ***************************
38776 >
38777 > the new line I'm suggesting is something like:
38778 >
38779 > ***************************
38780 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
38781 > ***************************
38782 >
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).
38788 >
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)
38792 >
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)
38795 >
38796 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
38797 >
38798 > sincerely,
38799 > David
38800 >
38801 > _________________________________________________________________
38802 > Get MSN 8 and enjoy automatic e-mail virus protection.
38803 > http://join.msn.com/?page=features/virus
38804 >
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
38811
38812
38813
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>
38819
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..
38821
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
38824
38825 *shock*
38826
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  ****************************************/
38834
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  ****************************************/
38841
38842 /****** - Begin Original Message - ******/
38843
38844 >Hi,
38845 >
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:
38849 >
38850 >***************************
38851 >-
38852 >-NickServ- nick is hello world
38853 >-
38854 >-NickServ- Is online from: ~test@just.a.test.co.za
38855 >-
38856 >-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
38857 >-
38858 >-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
38859 >-
38860 >-NickServ- Last quit message: anythinggggg
38861 >-
38862 >-NickServ- Options: Kill protection, Security
38863 >-
38864 >***************************
38865 >
38866 >the new line I'm suggesting is something like:
38867 >
38868 >***************************
38869 >-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
38870 >***************************
38871 >
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).
38877 >
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)
38881 >
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)
38884 >
38885 >Many thanks to all of who developed IRCservices ...etc ...etc ...etc
38886 >
38887 >sincerely,
38888 >David
38889 >
38890 >_________________________________________________________________
38891 >Get MSN 8 and enjoy automatic e-mail virus protection.
38892 >http://join.msn.com/?page=features/virus
38893 >
38894 >------------------------------------------------------------------
38895 >To unsubscribe or change your subscription options, visit:
38896 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
38897
38898 /******* - End Original Message - *******/
38899
38900
38901
38902
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>
38908
38909 We're having a small problem with suspended channel.
38910
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.
38913
38914 Also with suspended nick , when the suspencion expire, the services crash
38915 We're using:
38916
38917 ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
38918
38919
38920 Thanks
38921 Marc
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>
38930
38931 hmm.. what OS, compiler version etc are you using?
38932
38933 after a test, i got the following:
38934
38935 /cs id #abc 00376370
38936 -ChanServ- Channel #abc is suspended and may not be used or identified for.
38937
38938 /cs drop #abc
38939 [23:20] -ChanServ- Channel  is suspended and may not be used or identified for.
38940
38941 only prob i got was it missed the channel name in the second message :)
38942
38943 /cs drop #abc
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  ****************************************/
38951
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  ****************************************/
38958
38959 /****** - Begin Original Message - ******/
38960
38961 >We're having a small problem with suspended channel.
38962 >
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.
38965 >
38966 >Also with suspended nick , when the suspencion expire, the services crash
38967 >We're using:
38968 >
38969 >ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
38970 >
38971 >
38972 >Thanks
38973 >Marc
38974 >------------------------------------------------------------------
38975 >To unsubscribe or change your subscription options, visit:
38976 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
38977
38978 /******* - End Original Message - *******/
38979
38980
38981
38982
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>
38989
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...
38994
38995 Just an idea... I now await the half dozen people who will proceed to tell
38996 me how stupid my idea is....
38997
38998 Saturn
38999 irc.jetirc.net
39000
39001
39002
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>
39010
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.
39015
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..
39019 >
39020 > /time services.chatspike.net
39021 > [22:28] ??? Date / time at services.chatspike.net- Thu Aug 28 17:28:57
39022 > 2003 EDT
39023 >
39024 > *shock*
39025 >
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 >  ****************************************/
39033 >
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 >  ****************************************/
39040 >
39041 > /****** - Begin Original Message - ******/
39042 >
39043 >>Hi,
39044 >>
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:
39048 >>
39049 >>***************************
39050 >>-
39051 >>-NickServ- nick is hello world
39052 >>-
39053 >>-NickServ- Is online from: ~test@just.a.test.co.za
39054 >>-
39055 >>-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
39056 >>-
39057 >>-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
39058 >>-
39059 >>-NickServ- Last quit message: anythinggggg
39060 >>-
39061 >>-NickServ- Options: Kill protection, Security
39062 >>-
39063 >>***************************
39064 >>
39065 >>the new line I'm suggesting is something like:
39066 >>
39067 >>***************************
39068 >>-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
39069 >>***************************
39070 >>
39071 >>This will help our users to compare the time that user was last seen and
39072 >> the
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
39076 >> GMT
39077 >>(last seen time was before: 10 days, 3hours and 24 sec ago).
39078 >>
39079 >>Note that I saw both of these features, in other services I don't
39080 >> remember
39081 >>there names (but they aren't as stable as ircservices5) (it was something
39082 >>like ptlink services, and magik II)
39083 >>
39084 >>That's all, I would really like to see it on the next version (or if you
39085 >> can
39086 >>show me how to do it, as I'm not a programmer)
39087 >>
39088 >>Many thanks to all of who developed IRCservices ...etc ...etc ...etc
39089 >>
39090 >>sincerely,
39091 >>David
39092 >>
39093 >>_________________________________________________________________
39094 >>Get MSN 8 and enjoy automatic e-mail virus protection.
39095 >>http://join.msn.com/?page=features/virus
39096 >>
39097 >>------------------------------------------------------------------
39098 >>To unsubscribe or change your subscription options, visit:
39099 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
39100 >
39101 > /******* - End Original Message - *******/
39102 >
39103 >
39104 >
39105 > ------------------------------------------------------------------
39106 > To unsubscribe or change your subscription options, visit:
39107 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
39108 >
39109
39110
39111 --
39112 Best Regards,
39113 playa
39114 Network Founder/CEO
39115 DreamChat IRC Network - irc.dreamchat.org
39116 http://www.dreamchat.org
39117
39118
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>
39125
39126 On Thursday, Aug 28, 2003, at 20:46 US/Pacific, playa wrote:
39127
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.
39132
39133 That's a client thing.  Some clients might alias /time as a CTCP TIME
39134 for a specific user, or similar.
39135
39136 -- Quension
39137
39138
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>
39147
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.
39152
39153 Some clients use stupid aliases for CTCP commands, for example:
39154
39155 /version <nick> = /CTCP <nick> VERSION,
39156 /time <nick> = /CTCP <nick> TIME,
39157 /finger <nick> = /CTCP <nick> TIME
39158
39159 This is why nothing works the way you expected.
39160
39161 --
39162 Krisztian Romek
39163 r-krisztian@softhome.net
39164
39165
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>
39171
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).
39175
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
39179
39180
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>
39186
39187
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.
39193
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
39197
39198
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>
39204
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.
39206
39207 And i'll Quote Elijah:
39208
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
39211 be 'no.'"
39212
39213
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  ****************************************/
39221
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  ****************************************/
39228
39229 /****** - Begin Original Message - ******/
39230
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.
39236 >
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
39240 >
39241 >------------------------------------------------------------------
39242 >To unsubscribe or change your subscription options, visit:
39243 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
39244 >.
39245
39246 /******* - End Original Message - *******/
39247
39248
39249
39250
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>
39256
39257 its a stupid idea!!! :p
39258
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
39260
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  ****************************************/
39268
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  ****************************************/
39275
39276 /****** - Begin Original Message - ******/
39277
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...
39282 >
39283 >Just an idea... I now await the half dozen people who will proceed to tell
39284 >me how stupid my idea is....
39285 >
39286 >Saturn
39287 >irc.jetirc.net
39288 >
39289 >
39290 >------------------------------------------------------------------
39291 >To unsubscribe or change your subscription options, visit:
39292 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
39293
39294 /******* - End Original Message - *******/
39295
39296
39297
39298
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>
39305
39306 Cheers.
39307
39308 -----Original Message-----
39309 From: ircservices-coding-bounces@ircservices.za.net
39310 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of Craig
39311 McLure
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
39315
39316
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
39319 to annoy me.
39320
39321 And i'll Quote Elijah:
39322
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
39325 be 'no.'"
39326
39327
39328
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>
39334
39335 woops, ok sorry I thought the two e-mails is completely different.
39336
39337
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
39345 >
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.
39349 >
39350 >And i'll Quote Elijah:
39351 >
39352 >"Except it's already been said in the FAQ that it's not going to happen,
39353 >and
39354 >if that made it into the FAQ it would seem the answer is frequently going
39355 >to
39356 >be 'no.'"
39357 >
39358 >
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 >  ****************************************/
39366 >
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 >  ****************************************/
39373 >
39374 >/****** - Begin Original Message - ******/
39375 >
39376 > >Since most people want to see this feature(s) in the next version, it
39377 >would
39378 > >be great to implement it as an optional feature , where it can be
39379 >disabled
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
39382 >fact,
39383 > >it will add another nice feature to the features list of IRCservices5.
39384 > >
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
39388 > >
39389 > >------------------------------------------------------------------
39390 > >To unsubscribe or change your subscription options, visit:
39391 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
39392 > >.
39393 >
39394 >/******* - End Original Message - *******/
39395 >
39396 >
39397 >
39398 >------------------------------------------------------------------
39399 >To unsubscribe or change your subscription options, visit:
39400 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
39401
39402 _________________________________________________________________
39403 MSN 8: Get 6 months for $9.95/month. http://join.msn.com/?page=dept/dialup
39404
39405
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>
39412
39413 Hi
39414 I run ircservices 5.0.21 on FreeBSD 4.8-STABLE. and Ultimate 3.*
39415 I get this in logfile:
39416
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)
39429
39430 and how can I do so that nickserv dont show the realhost of a user in
39431 'ns info nick all'
39432
39433
39434 thanks for help
39435
39436                            Ali "Simorgh"
39437  ______________________________________________________
39438  Many of life's failures are people who did not realize
39439  how close they were to success when they gave up.
39440  Thomas A. Edison
39441  ______________________________________________________
39442
39443
39444
39445
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>
39452
39453 "and how can I do so that nickserv dont show the realhost of a user in
39454 'ns info nick all'"
39455
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
39459 option is set.
39460
39461
39462
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>
39469
39470      Use E-mail if you need communication of that sort.
39471
39472   --Andrew Church
39473     achurch@achurch.org
39474     http://achurch.org/
39475
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
39480 >have been denied.
39481 >
39482 >/chanserv MARK <channel> <reason>
39483 >
39484 >/chanserv info #channel would read the following.
39485 >*#channel has been MARKED by playa - <reason>
39486 >
39487 >Of course only IRCops would be able to view it.
39488 >
39489 >Just an idea i thought of :)
39490 >
39491 >--
39492 >Best Regards,
39493 >playa
39494 >Network Founder/CEO
39495 >DreamChat IRC Network - irc.dreamchat.org
39496 >http://www.dreamchat.org
39497 >
39498 >------------------------------------------------------------------
39499 >To unsubscribe or change your subscription options, visit:
39500 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
39501
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>
39509
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.
39513
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
39522 is not complex.
39523
39524 Shaun
39525
39526
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>
39532
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..
39535
39536 or /cs levels #channels DISABLE autoop
39537
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  ****************************************/
39545
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  ****************************************/
39552
39553 /****** - Begin Original Message - ******/
39554
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.
39558 >
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
39567 >is not complex.
39568 >
39569 >Shaun
39570 >
39571 >------------------------------------------------------------------
39572 >To unsubscribe or change your subscription options, visit:
39573 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
39574 >.
39575
39576 /******* - End Original Message - *******/
39577
39578
39579
39580
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>
39588
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..
39591
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.
39594
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
39597
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
39604
39605 Same with ENFORCE set to off as well.
39606
39607 > [snipped obnoxiously long sig]
39608
39609 Shaun Guth
39610
39611
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>
39618
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
39621 >
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
39628
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.
39632
39633   --Andrew Church
39634     achurch@achurch.org
39635     http://achurch.org/
39636
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>
39643
39644 >Can we reconsider adding a Mass memo function for the next release?
39645
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.
39653
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.
39659
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.
39664
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.
39667
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........
39674
39675      This is an interesting thought; I'll think about it for a future
39676 version.
39677
39678   --Andrew Church
39679     achurch@achurch.org
39680     http://achurch.org/
39681
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>
39688
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?
39694
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.
39699
39700   --Andrew Church
39701     achurch@achurch.org
39702     http://achurch.org/
39703
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>
39710
39711 >Is there any tool (silly question) or something or guid to make a language
39712 >file.
39713 >
39714 >I have decided to make a Persian (Farsi) language file.
39715
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.
39720
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.
39723
39724   --Andrew Church
39725     achurch@achurch.org
39726     http://achurch.org/
39727
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>
39734
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
39738
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?
39741
39742   --Andrew Church
39743     achurch@achurch.org
39744     http://achurch.org/
39745
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>
39752
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.
39756
39757      This is a bug in the DROP function, and has been fixed; thanks for the
39758 report.
39759
39760   --Andrew Church
39761     achurch@achurch.org
39762     http://achurch.org/
39763
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>
39770
39771 >[Aug 30 10:56:18 2003] mail/sendmail:
39772 > /usr/sbin/sendmail exited with code 25600
39773
39774      Use the SMTP module instead (mail/smtp).
39775
39776 >[Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
39777 >registration (Simorgh)
39778 >
39779 >and how can I do so that nickserv dont show the realhost of a user in
39780 >'ns info nick all'
39781
39782      It doesn't.  However:
39783
39784 >[Aug 30 10:51:19 2003] unknown message from server
39785 >(:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
39786
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.
39790
39791   --Andrew Church
39792     achurch@achurch.org
39793     http://achurch.org/
39794
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>
39801
39802 >Or how about rather letting users decide what timezone they're in and
39803 >services outputs all timestamps in their local time?
39804
39805 /ns help set timezone (since 5.0 alpha)
39806
39807   --Andrew Church
39808     achurch@achurch.org
39809     http://achurch.org/
39810
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>
39818
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.
39826
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?
39834
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....
39841
39842 Saturn
39843 irc.jetirc.net
39844
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
39850
39851
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...
39854
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.
39858
39859   --Andrew Church
39860     achurch@achurch.org
39861     http://achurch.org/
39862
39863
39864
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>
39873
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.
39883
39884 Erm, what's the argument here?  Services stipulates its timezone in its
39885 timestamps.  As do all the other servers on the network.
39886
39887 Atleast mine do...
39888
39889
39890 Regards,
39891 Aragon
39892
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>
39901
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??
39906
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
39912 suggestion
39913
39914
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
39918 server
39919 > is in a different time zone -- How are users supposed to know what time
39920 zone
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.
39926
39927 Erm, what's the argument here?  Services stipulates its timezone in its
39928 timestamps.  As do all the other servers on the network.
39929
39930 Atleast mine do...
39931
39932
39933 Regards,
39934 Aragon
39935 ------------------------------------------------------------------
39936 To unsubscribe or change your subscription options, visit:
39937 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
39938
39939
39940
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>
39948
39949 On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
39950
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?
39955
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
39959 it back.
39960
39961 >   Why does it all have to be so complicated??
39962
39963 It isn't.  Your users can even use the handy-dandy /nickserv set
39964 timezone command to make it even easier.
39965
39966 > ----- Original Message -----
39967 > From: "Aragon Gouveia" <aragon@phat.za.net>
39968
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.
39979 >
39980 > Erm, what's the argument here?  Services stipulates its timezone in
39981 > its timestamps.  As do all the other servers on the network.
39982
39983 -- Quension
39984
39985
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>
39992
39993
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
39996 seconds ago)
39997 Time registered  : Jul 25 22:19:20 2003 GMT (** days, ** minutes and **
39998 seconds ago)
39999 wouldn't even a greater idea?
40000
40001 _________________________________________________________________
40002 Get MSN 8 and enjoy automatic e-mail virus protection.
40003 http://join.msn.com/?page=features/virus
40004
40005
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>
40013
40014 [16:41] -NickServ-   Time registered: Jul 27 13:09:08 2002 PDT
40015
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....
40024
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
40027 valid ones...
40028
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
40031 codes like PDT)...
40032
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
40039 suggestion
40040
40041
40042 On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
40043
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?
40048
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
40052 it back.
40053
40054 >   Why does it all have to be so complicated??
40055
40056 It isn't.  Your users can even use the handy-dandy /nickserv set
40057 timezone command to make it even easier.
40058
40059 > ----- Original Message -----
40060 > From: "Aragon Gouveia" <aragon@phat.za.net>
40061
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.
40072 >
40073 > Erm, what's the argument here?  Services stipulates its timezone in
40074 > its timestamps.  As do all the other servers on the network.
40075
40076 -- Quension
40077
40078 ------------------------------------------------------------------
40079 To unsubscribe or change your subscription options, visit:
40080 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
40081
40082
40083
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>
40091
40092 On Sunday, Aug 31, 2003, at 16:47 US/Pacific, Saturn wrote:
40093
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)...
40097
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.
40101
40102 -- Quension
40103
40104
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>
40112
40113      "Use /ns set timezone" is the official answer on this.  Please take
40114 all further discussion to the ircservices list.
40115
40116   --Andrew Church
40117     achurch@achurch.org
40118     http://achurch.org/
40119
40120 >[16:41] -NickServ-   Time registered: Jul 27 13:09:08 2002 PDT
40121 >
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....
40130 >
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
40133 >valid ones...
40134 >
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)...
40138 >
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
40145 >suggestion
40146 >
40147 >
40148 >On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
40149 >
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?
40154 >
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
40158 >it back.
40159 >
40160 >>   Why does it all have to be so complicated??
40161 >
40162 >It isn't.  Your users can even use the handy-dandy /nickserv set
40163 >timezone command to make it even easier.
40164 >
40165 >> ----- Original Message -----
40166 >> From: "Aragon Gouveia" <aragon@phat.za.net>
40167 >
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.
40178 >>
40179 >> Erm, what's the argument here?  Services stipulates its timezone in
40180 >> its timestamps.  As do all the other servers on the network.
40181 >
40182 >-- Quension
40183 >
40184 >------------------------------------------------------------------
40185 >To unsubscribe or change your subscription options, visit:
40186 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
40187 >
40188 >
40189 >------------------------------------------------------------------
40190 >To unsubscribe or change your subscription options, visit:
40191 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
40192
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>
40199
40200 Thanks for your help.
40201
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
40206            Is online from: %s
40207 to:
40208 NICK_INFO_ADDRESS_ONLINE
40209            Is online from: N/A ?
40210
40211
40212                            Ali "Simorgh"
40213  ______________________________________________________
40214  Many of life's failures are people who did not realize
40215  how close they were to success when they gave up.
40216  Thomas A. Edison
40217  ______________________________________________________
40218
40219
40220 On Mon, 1 Sep 2003, Andrew Church wrote:
40221
40222 > >[Aug 30 10:56:18 2003] mail/sendmail:
40223 > > /usr/sbin/sendmail exited with code 25600
40224 >
40225 >      Use the SMTP module instead (mail/smtp).
40226 >
40227 > >[Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
40228 > >registration (Simorgh)
40229 > >
40230 > >and how can I do so that nickserv dont show the realhost of a user in
40231 > >'ns info nick all'
40232 >
40233 >      It doesn't.  However:
40234 >
40235 > >[Aug 30 10:51:19 2003] unknown message from server
40236 > >(:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
40237 >
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.
40241 >
40242 >   --Andrew Church
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
40248 >
40249
40250
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>
40257
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
40260
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.
40265
40266   --Andrew Church
40267     achurch@achurch.org
40268     http://achurch.org/
40269
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>
40275
40276 Hi all,
40277
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.
40281
40282 Regards
40283
40284 alex
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>
40295
40296 Hello,
40297
40298 alex wrote:
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.
40302
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
40306 computer.
40307
40308 --
40309 Krisztian Romek
40310 r-krisztian@softhome.net
40311
40312
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>
40318
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.
40320
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.
40322
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  ****************************************/
40330
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  ****************************************/
40337
40338 /****** - Begin Original Message - ******/
40339
40340 >Hi all,
40341 >
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.
40345 >
40346 >Regards
40347 >
40348 >alex
40349 >------------------------------------------------------------------
40350 >To unsubscribe or change your subscription options, visit:
40351 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
40352
40353 /******* - End Original Message - *******/
40354
40355
40356
40357
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>
40363
40364 It wasn't an easy subject to sum up in just a few words.
40365
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
40378 send.c
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
40382 all the
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)
40394
40395 Thanks
40396
40397 Brent
40398
40399
40400
40401 ----------------------------------------------------------
40402 |               Brent DiNicola                                  |
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 -----------------------------------------------------------
40409
40410
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>
40416
40417 lol, Our help no good? :P
40418
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..
40420
40421 Dont ask me for source on this.. i'm just theorising :)
40422
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  ****************************************/
40430
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  ****************************************/
40437
40438 /****** - Begin Original Message - ******/
40439
40440 >It wasn't an easy subject to sum up in just a few words.
40441 >
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
40454 >send.c
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
40458 >all the
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)
40470 >
40471 >Thanks
40472 >
40473 >Brent
40474 >
40475 >
40476 >
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 >-----------------------------------------------------------
40485 >
40486 >------------------------------------------------------------------
40487 >To unsubscribe or change your subscription options, visit:
40488 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
40489 >.
40490
40491 /******* - End Original Message - *******/
40492
40493
40494
40495
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>
40503
40504 Hello;
40505
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.
40515
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.
40530 ...
40531
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.
40535
40536 To your case.
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.
40540
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
40543 trivial.
40544
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
40548 closed.
40549
40550 Do keep in mind that requesting support for modified services versions
40551 are subject to be ignored.
40552
40553 I hope it helps,
40554 yusuf
40555
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.
40558 >
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
40571 > send.c
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
40575 > all the
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)
40587 >
40588 > Thanks
40589 >
40590 > Brent
40591 >
40592 >
40593 >
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 > -----------------------------------------------------------
40602 >
40603 > ------------------------------------------------------------------
40604 > To unsubscribe or change your subscription options, visit:
40605 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
40606 --
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 ------------------------------------------------------------------
40613
40614
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>
40621
40622 Brent DiNicola wrote:
40623
40624 > It wasn't an easy subject to sum up in just a few words.
40625 >
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
40631 > the users
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
40634 > NOTICE
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
40637 > the best
40638 > way to go about this without causing trouble for me and anyone else
40639 > who has
40640 > to deal with this code. Is it possible or even suggested to make a
40641 > module that
40642 > would replace the notice() from send.c with it's own, leaving the code
40643 > in send.c
40644 > alone and not causing troubles down the road. Suggestions were that I
40645 > make a
40646 > module that kept the info for each nick's setting and then if I could
40647 > override
40648 > the notice() and notice_lang() and notice_help() in send.c that would
40649 > keep all the
40650 > other code clean and not cause other troubles. I want to know what the
40651 > best
40652 > way to do this would be, I know it's against RFC but I want to move to
40653 > newer
40654 > services than the 1.4.3pre4 that we are using now and add modules so
40655 > that I
40656 > can do things down the line. They are used to having PRIVMSG and I
40657 > can't just
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
40660 > this? I
40661 > know this topic has been asked before and I know your not going to
40662 > make it
40663 > part of your code, I just wanted to know from the people who know the
40664 > code
40665 > really well what the best route to take would be to do the least
40666 > amount of
40667 > damage. (And if someone has done this.. please let me know what you did,
40668 > examples would rock)
40669 >
40670 > Thanks
40671 >
40672 > Brent
40673 >
40674 >
40675 >
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
40687 >
40688 >
40689
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
40694
40695 services is the wrong thing to change
40696
40697
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>
40703
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
40705
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  ****************************************/
40713
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  ****************************************/
40720
40721 /****** - Begin Original Message - ******/
40722
40723 >Brent DiNicola wrote:
40724 >
40725 >> It wasn't an easy subject to sum up in just a few words.
40726 >>
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
40732 >> the users
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
40735 >> NOTICE
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
40738 >> the best
40739 >> way to go about this without causing trouble for me and anyone else
40740 >> who has
40741 >> to deal with this code. Is it possible or even suggested to make a
40742 >> module that
40743 >> would replace the notice() from send.c with it's own, leaving the code
40744 >> in send.c
40745 >> alone and not causing troubles down the road. Suggestions were that I
40746 >> make a
40747 >> module that kept the info for each nick's setting and then if I could
40748 >> override
40749 >> the notice() and notice_lang() and notice_help() in send.c that would
40750 >> keep all the
40751 >> other code clean and not cause other troubles. I want to know what the
40752 >> best
40753 >> way to do this would be, I know it's against RFC but I want to move to
40754 >> newer
40755 >> services than the 1.4.3pre4 that we are using now and add modules so
40756 >> that I
40757 >> can do things down the line. They are used to having PRIVMSG and I
40758 >> can't just
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
40761 >> this? I
40762 >> know this topic has been asked before and I know your not going to
40763 >> make it
40764 >> part of your code, I just wanted to know from the people who know the
40765 >> code
40766 >> really well what the best route to take would be to do the least
40767 >> amount of
40768 >> damage. (And if someone has done this.. please let me know what you did,
40769 >> examples would rock)
40770 >>
40771 >> Thanks
40772 >>
40773 >> Brent
40774 >>
40775 >>
40776 >>
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
40788 >>
40789 >>
40790 >
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
40795 >
40796 >services is the wrong thing to change
40797 >
40798 >------------------------------------------------------------------
40799 >To unsubscribe or change your subscription options, visit:
40800 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
40801 >.
40802
40803 /******* - End Original Message - *******/
40804
40805
40806
40807
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>
40814
40815 On Thursday, Sep 4, 2003, at 13:29 US/Pacific, Robert F Merrill wrote:
40816
40817 > Brent DiNicola wrote:
40818 >
40819 >> It wasn't an easy subject to sum up in just a few words.
40820
40821 [...]
40822
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
40827 >
40828 > services is the wrong thing to change
40829
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.
40833
40834 This is the coding list, not the feature request list.  He asked for
40835 code design approaches, not for political insight.
40836
40837 -- Quension
40838
40839
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>
40845
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
40851
40852 Thanks for all
40853
40854 Diego B. Contezini
40855
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..
40861
40862
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
40868 get
40869 > a core.
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
40872 break
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.
40877 >
40878 > Thanks for all
40879 >
40880 > Diego B. Contezini aka destruct_ | irc.redesul.net
40881 > (Sorry for my confuse english.)
40882 >
40883
40884
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>
40891
40892 Hello, im destruct_, im the administrator of the RedeSul Network.
40893 (irc.redesul.net).
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
40897 a core.
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.
40904
40905 Thanks for all
40906
40907 Diego B. Contezini aka destruct_ | irc.redesul.net
40908 (Sorry for my confuse english.)
40909
40910
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>
40916
40917 Hi All
40918
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
40930
40931 many thanks
40932 Engin
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>
40941
40942 make sure you are on the services administrator list, if you are not, get the root administrator to add you using the command:
40943
40944 [22:27] -OperServ- Syntax: ADMIN ADD nickname
40945 [22:27] -OperServ- ADMIN DEL nickname
40946 [22:27] -OperServ- ADMIN LIST
40947 [22:27] -OperServ-
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.
40952 [22:27] -OperServ-
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.
40955
40956
40957
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  ****************************************/
40965
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  ****************************************/
40972
40973 /****** - Begin Original Message - ******/
40974
40975 >Hi All
40976 >
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
40988 >
40989 >many thanks
40990 >Engin
40991 >------------------------------------------------------------------
40992 >To unsubscribe or change your subscription options, visit:
40993 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
40994
40995 /******* - End Original Message - *******/
40996
40997
40998
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>
41005
41006 Contact me directly... I have quite a bit of experience with unreal and these services...
41007
41008 Saturn
41009 irc.jetirc.net
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
41015
41016
41017   Hi All
41018
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
41030
41031   many thanks
41032   Engin
41033
41034
41035
41036 ------------------------------------------------------------------------------
41037
41038
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>
41051
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....
41054
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
41061
41062
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:
41065
41066 [22:27] -OperServ- Syntax: ADMIN ADD nickname
41067 [22:27] -OperServ- ADMIN DEL nickname
41068 [22:27] -OperServ- ADMIN LIST
41069 [22:27] -OperServ-
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.
41074 [22:27] -OperServ-
41075 [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
41076 command.
41077 [22:27] -OperServ- All other use limited to Services super-user.
41078
41079
41080
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  ****************************************/
41088
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  ****************************************/
41095
41096 /****** - Begin Original Message - ******/
41097
41098 >Hi All
41099 >
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
41111 >
41112 >many thanks
41113 >Engin
41114 >------------------------------------------------------------------
41115 >To unsubscribe or change your subscription options, visit:
41116 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
41117
41118 /******* - End Original Message - *******/
41119
41120
41121 ------------------------------------------------------------------
41122 To unsubscribe or change your subscription options, visit:
41123 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
41124
41125
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>
41132
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
41135 one
41136
41137 cheers
41138 Engin
41139
41140
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
41146
41147
41148 > Send IRCServices-Coding mailing list submissions to
41149 > ircservices-coding@ircservices.za.net
41150 >
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
41155 >
41156 > You can reach the person managing the list at
41157 > ircservices-coding-owner@ircservices.za.net
41158 >
41159 > When replying, please edit your Subject line so it is more specific
41160 > than "Re: Contents of IRCServices-Coding digest..."
41161 >
41162 >
41163 > Today's Topics:
41164 >
41165 >    1. operserv (engin@piratetv)
41166 >    2. Re: operserv (Craig McLure)
41167 >    3. Re: operserv (Saturn)
41168 >    4. Re: operserv (Saturn)
41169 >
41170 >
41171 > ----------------------------------------------------------------------
41172 >
41173 > Message: 1
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"
41180 >
41181 > Hi All
41182 >
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
41194 >
41195 > many thanks
41196 > Engin
41197 > -------------- next part --------------
41198 > An HTML attachment was scrubbed...
41199 > URL:
41200 http://snow.fingers.co.za/pipermail/ircservices-coding/attachments/20030921/
41201 fdc12b4e/attachment-0001.htm
41202 >
41203 > ------------------------------
41204 >
41205 > Message: 2
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"
41213 >
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:
41216 >
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
41222 nicknames
41223 > [22:27] -OperServ- to or from the Services admin list. A user whose
41224 nickname
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
41227 commands.
41228 > [22:27] -OperServ-
41229 > [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
41230 command.
41231 > [22:27] -OperServ- All other use limited to Services super-user.
41232 >
41233 >
41234 >
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 >  ****************************************/
41242 >
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 >  ****************************************/
41249 >
41250 > /****** - Begin Original Message - ******/
41251 >
41252 > >Hi All
41253 > >
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
41265 > >
41266 > >many thanks
41267 > >Engin
41268 > >------------------------------------------------------------------
41269 > >To unsubscribe or change your subscription options, visit:
41270 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
41271 >
41272 > /******* - End Original Message - *******/
41273 >
41274 >
41275 >
41276 > ------------------------------
41277 >
41278 > Message: 3
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"
41286 >
41287 > Contact me directly... I have quite a bit of experience with unreal and
41288 these services...
41289 >
41290 > Saturn
41291 > irc.jetirc.net
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
41297 >
41298 >
41299 >   Hi All
41300 >
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
41303 mailing
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
41313 >
41314 >   many thanks
41315 >   Engin
41316 >
41317 >
41318 >
41319 > --------------------------------------------------------------------------
41320 ----
41321 >
41322 >
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...
41328 > URL:
41329 http://snow.fingers.co.za/pipermail/ircservices-coding/attachments/20030921/
41330 ca188e06/attachment-0001.htm
41331 >
41332 > ------------------------------
41333 >
41334 > Message: 4
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"
41342 >
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
41345 denied....
41346 >
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
41353 >
41354 >
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:
41357 >
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
41363 nicknames
41364 > [22:27] -OperServ- to or from the Services admin list. A user whose
41365 nickname
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
41368 commands.
41369 > [22:27] -OperServ-
41370 > [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
41371 > command.
41372 > [22:27] -OperServ- All other use limited to Services super-user.
41373 >
41374 >
41375 >
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 >  ****************************************/
41383 >
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 >  ****************************************/
41390 >
41391 > /****** - Begin Original Message - ******/
41392 >
41393 > >Hi All
41394 > >
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
41406 > >
41407 > >many thanks
41408 > >Engin
41409 > >------------------------------------------------------------------
41410 > >To unsubscribe or change your subscription options, visit:
41411 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
41412 >
41413 > /******* - End Original Message - *******/
41414 >
41415 >
41416 > ------------------------------------------------------------------
41417 > To unsubscribe or change your subscription options, visit:
41418 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
41419 >
41420 >
41421 > ------------------------------
41422 >
41423 > _______________________________________________
41424 > IRCServices-Coding mailing list
41425 > IRCServices-Coding@ircservices.za.net
41426 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
41427 >
41428 >
41429 > End of IRCServices-Coding Digest, Vol 8, Issue 5
41430 > ************************************************
41431
41432
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>
41440
41441 Sometimes has occur this bug, last 1 year....
41442 on a network with 30k registers, its happening with latency of 3.. 4
41443 days....
41444
41445 someone have any idea?
41446
41447 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
41448 av=0xbfffeec8) at channels.c:278
41449 278         while (*s) {
41450 (gdb) bt'
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>
41455         add = 1
41456         modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
41457 #1  0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:680
41458         buf =
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
41470 bounds>,
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@`???"}
41474         len = 4
41475         i = 0
41476         lastc = 45 '-'
41477 #2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
41478         args = 0x0
41479         modes = 0x0
41480         modes_orig = 0x0
41481         md = (struct modedata *) 0x0
41482         which = -1
41483         add = 0
41484         i = 0
41485         c = 0 '\0'
41486 #3  0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at main.c:269
41487         now = 1065393142
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.
41493 (gdb)
41494
41495
41496
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>
41503
41504 Upgrade.
41505
41506   --Andrew Church
41507     achurch@achurch.org
41508     http://achurch.org/
41509
41510 >Sometimes has occur this bug, last 1 year....
41511 >on a network with 30k registers, its happening with latency of 3.. 4
41512 >days....
41513 >
41514 >someone have any idea?
41515 >
41516 >#0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
41517 >av=0xbfffeec8) at channels.c:278
41518 >278         while (*s) {
41519 >(gdb) bt'
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>
41524 >        add = 1
41525 >        modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
41526 >#1  0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:68
41527 >0
41528 >        buf =
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ï¿½ï¿½ï¿½ï¿
41532 >½
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\
41537 >000\000\0
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�
41543 >���\027\000\0
41544 >00\000\000\000\000\000\024\032"...
41545 >        s = 0xbfffeef0 "-isl"
41546 >        argv = {0xa97b6c0 "#young", 0x20656c62 <Address 0x20656c62 out
41547 >of
41548 >bounds>,
41549 >  0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 o
41550 >ut
41551 >of bounds>, 0x42133cec "\004", 0xbffff1fc "",
41552 >  0x4204533d "\201���\016", 0x42131a14 " \031\023
41553 >B�h\001@`�"}
41554 >        len = 4
41555 >        i = 0
41556 >        lastc = 45 '-'
41557 >#2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:32
41558 >1
41559 >        args = 0x0
41560 >        modes = 0x0
41561 >        modes_orig = 0x0
41562 >        md = (struct modedata *) 0x0
41563 >        which = -1
41564 >        add = 0
41565 >        i = 0
41566 >        c = 0 '\0'
41567 >#3  0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at ma
41568 >in.c:269
41569 >        now = 1065393142
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.
41575 >(gdb)
41576 >
41577 >
41578 >------------------------------------------------------------------
41579 >To unsubscribe or change your subscription options, visit:
41580 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
41581
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>
41588
41589 Upgrade?
41590 ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
41591 18:41:36 BRT 2003
41592 -
41593
41594 Its the last version.......
41595
41596 Diego B. Contezini
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....
41602
41603
41604 > Upgrade.
41605 >
41606 >   --Andrew Church
41607 >     achurch@achurch.org
41608 >     http://achurch.org/
41609 >
41610 > >Sometimes has occur this bug, last 1 year....
41611 > >on a network with 30k registers, its happening with latency of 3.. 4
41612 > >days....
41613 > >
41614 > >someone have any idea?
41615 > >
41616 > >#0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
41617 > >av=0xbfffeec8) at channels.c:278
41618 > >278         while (*s) {
41619 > >(gdb) bt'
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>
41624 > >        add = 1
41625 > >        modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
41626 > >#1  0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:68
41627 > >0
41628 > >        buf =
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???????????
41632 > >?
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\
41637 > >000\000\0
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
41647 > >of
41648 > >bounds>,
41649 > >  0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 o
41650 > >ut
41651 > >of bounds>, 0x42133cec "\004", 0xbffff1fc "",
41652 > >  0x4204533d "\201?????????\016", 0x42131a14 " \031\023
41653 > >B???h\001@`???"}
41654 > >        len = 4
41655 > >        i = 0
41656 > >        lastc = 45 '-'
41657 > >#2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:32
41658 > >1
41659 > >        args = 0x0
41660 > >        modes = 0x0
41661 > >        modes_orig = 0x0
41662 > >        md = (struct modedata *) 0x0
41663 > >        which = -1
41664 > >        add = 0
41665 > >        i = 0
41666 > >        c = 0 '\0'
41667 > >#3  0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at ma
41668 > >in.c:269
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.
41675 > >(gdb)
41676 > >
41677 > >
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
41684 >
41685
41686
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>
41693
41694 >Upgrade?
41695 >ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
41696 >18:41:36 BRT 2003
41697 >-
41698 >
41699 >Its the last version.......
41700
41701      Then send a full debug log (from startup to crash), or I can't help.
41702
41703   --Andrew Church
41704     achurch@achurch.org
41705     http://achurch.org/
41706
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>
41713
41714 And how should be this log? i sent a backtrace......
41715
41716 Diego B. Contezini
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....
41722
41723
41724 > >Upgrade?
41725 > >ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
41726 > >18:41:36 BRT 2003
41727 > >-
41728 > >
41729 > >Its the last version.......
41730 >
41731 >      Then send a full debug log (from startup to crash), or I can't help.
41732 >
41733 >   --Andrew Church
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
41739 >
41740
41741
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>
41748
41749 >And how should be this log? i sent a backtrace......
41750
41751 RTFM (FAQ Z.3)
41752
41753   --Andrew Church
41754     achurch@achurch.org
41755     http://achurch.org/
41756
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>
41763
41764 Read....
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
41767 nofork.....
41768
41769 Cya
41770 Diego B. Contezini
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....
41776
41777
41778 > >And how should be this log? i sent a backtrace......
41779 >
41780 > RTFM (FAQ Z.3)
41781 >
41782 >   --Andrew Church
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
41788 >
41789
41790
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>
41797
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).
41800
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...
41807
41808 First: IS that what it's supposed to do?
41809
41810 Second: If so, it's not working...
41811
41812 Saturn
41813 www.jetirc.net
41814
41815
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>
41822
41823
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.
41827
41828 I copy the sintaz of mail-auth ( it's in italian )
41829
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:
41838             /msg %s AUTH %09d
41839
41840         La registrazione del tuo nick sara' confermata e il tuo nickname
41841         sara' protetto da eventuali tentativi di abuso o furto.
41842
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.
41846
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.
41850
41851
41852         Sono inoltre disponibili i seguenti servizi:
41853
41854         - MusiChat Forum
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.
41860
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.
41866
41867
41868         Per una connessione piu' veloce e sicura e' vivamente
41869         consigliato l'utilizzo del seguente server: irc.musichat.net
41870
41871         MusiChat Net Community
41872
41873         Questo messaggio e stato inviato su richiesta di %s in risposta a %s
41874         %s@%s.
41875
41876
41877
41878
41879 I read the istruction for translate.
41880
41881 The error is:
41882
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
41886
41887
41888 Some one can help me?
41889 the email body is too long?
41890
41891 Thx
41892
41893 Alex
41894
41895
41896
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>
41903
41904      You have the wrong number of %-tokens in your message.
41905
41906   --Andrew Church
41907     achurch@achurch.org
41908     http://achurch.org/
41909
41910 >
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.
41914 >
41915 >I copy the sintaz of mail-auth ( it's in italian )
41916 >
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
41926 >
41927 >        La registrazione del tuo nick sara' confermata e il tuo nickname
41928 >        sara' protetto da eventuali tentativi di abuso o furto.
41929 >
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.
41933 >
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.
41937 >
41938 >
41939 >        Sono inoltre disponibili i seguenti servizi:
41940 >
41941 >        - MusiChat Forum
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.
41947 >
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.
41953 >
41954 >
41955 >        Per una connessione piu' veloce e sicura e' vivamente
41956 >        consigliato l'utilizzo del seguente server: irc.musichat.net
41957 >
41958 >        MusiChat Net Community
41959 >
41960 >        Questo messaggio e stato inviato su richiesta di %s in risposta a %s
41961 >        %s@%s.
41962 >
41963 >
41964 >
41965 >
41966 >I read the istruction for translate.
41967 >
41968 >The error is:
41969 >
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
41973 >
41974 >
41975 >Some one can help me?
41976 >the email body is too long?
41977 >
41978 >Thx
41979 >
41980 >Alex
41981 >
41982 >
41983 >------------------------------------------------------------------
41984 >To unsubscribe or change your subscription options, visit:
41985 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
41986
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>
41992
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 ?
42001
42002 ######################################################
42003 modules/chanserv/check.c
42004 ...
42005 void check_chan_user_modes(const char *source, struct c_userlist *u,
42006                            Channel *c, int32 oldmodes)
42007 ...
42008         if ((res & ~modes) & CUMODE_o) {
42009             ci->last_used = time(NULL);
42010             put_channelinfo(ci);
42011         }
42012 ...
42013 ######################################################
42014
42015 |SaMaN|
42016
42017
42018
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>
42024
42025 Also it does not update last_used time on +a flag.
42026
42027 Temporary fix
42028 ---------------
42029
42030 edit /modules/chanserv/check.c
42031
42032 find line
42033 -------------------------------------------------------------------------
42034         local_set_cumodes(c, '+', res & ~modes, user->nick);
42035 -------------------------------------------------------------------------
42036 add below
42037 ------------------------------------------------------------------------
42038         int16 cumode_q = mode_char_to_flag('q',MODE_CHANUSER);
42039         int16 cumode_a = mode_char_to_flag('a',MODE_CHANUSER);
42040
42041         if ((res & ~modes) & cumode_q) {
42042             ci->last_used = time(NULL);
42043             put_channelinfo(ci);
42044         }
42045
42046         if ((res & ~modes) & cumode_a) {
42047             ci->last_used = time(NULL);
42048             put_channelinfo(ci);
42049         }
42050 -------------------------------------------------------------------------
42051 save and compile and run and enjoy :)
42052 -------------------------------------------------------------------------
42053
42054 |SaMaN|
42055
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 ?
42061
42062
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
42067 mode:
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
42070 to
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 ?
42073 >
42074 > ######################################################
42075 > modules/chanserv/check.c
42076 > ...
42077 > void check_chan_user_modes(const char *source, struct c_userlist *u,
42078 >                            Channel *c, int32 oldmodes)
42079 > ...
42080 >         if ((res & ~modes) & CUMODE_o) {
42081 >             ci->last_used = time(NULL);
42082 >             put_channelinfo(ci);
42083 >         }
42084 > ...
42085 > ######################################################
42086 >
42087 > |SaMaN|
42088 >
42089 >
42090
42091
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>
42097
42098 Haven't seen a reply to this one, so thought I'd better make sure this went
42099 through....
42100
42101 ----- Original Message -----
42102 Sent: Friday, October 10, 2003 3:48 PM
42103 Subject: Akill problem in 5.0.22
42104
42105
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).
42108
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...
42115
42116 First: IS that what it's supposed to do?
42117
42118 Second: If so, it's not working...
42119
42120 Saturn
42121 www.jetirc.net
42122
42123
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>
42130
42131 RTFM
42132
42133   --Andrew Church
42134     achurch@achurch.org
42135     http://achurch.org/
42136
42137 >Haven't seen a reply to this one, so thought I'd better make sure this went
42138 >through....
42139 >
42140 >----- Original Message -----
42141 >Sent: Friday, October 10, 2003 3:48 PM
42142 >Subject: Akill problem in 5.0.22
42143 >
42144 >
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).
42147 >
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...
42154 >
42155 >First: IS that what it's supposed to do?
42156 >
42157 >Second: If so, it's not working...
42158 >
42159 >Saturn
42160 >www.jetirc.net
42161 >
42162 >------------------------------------------------------------------
42163 >To unsubscribe or change your subscription options, visit:
42164 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
42165
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>
42172
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
42175
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
42179 it first.
42180     Example: ImmediatelySendAutokill
42181
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
42187 kill them.
42188
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?
42193
42194 Thanks
42195 Saturn
42196
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
42202
42203
42204 RTFM
42205
42206   --Andrew Church
42207     achurch@achurch.org
42208     http://achurch.org/
42209
42210 >Haven't seen a reply to this one, so thought I'd better make sure this went
42211 >through....
42212 >
42213 >----- Original Message -----
42214 >Sent: Friday, October 10, 2003 3:48 PM
42215 >Subject: Akill problem in 5.0.22
42216 >
42217 >
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).
42220 >
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
42223 scanning
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...
42228 >
42229 >First: IS that what it's supposed to do?
42230 >
42231 >Second: If so, it's not working...
42232 >
42233 >Saturn
42234 >www.jetirc.net
42235 >
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
42242
42243
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>
42250
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
42255 >kill them.
42256
42257      The documentation says nothing about this.  RTFM again.
42258
42259   --Andrew Church
42260     achurch@achurch.org
42261     http://achurch.org/
42262
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>
42270
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
42276 to deal with it.
42277
42278 Ballsy
42279
42280
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
42284 >
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
42288 >it first.
42289 >     Example: ImmediatelySendAutokill
42290 >
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
42296 >kill them.
42297 >
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?
42302 >
42303 >Thanks
42304 >Saturn
42305 >
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
42311 >
42312 >
42313 >RTFM
42314 >
42315 >   --Andrew Church
42316 >     achurch@achurch.org
42317 >     http://achurch.org/
42318 >
42319 > >Haven't seen a reply to this one, so thought I'd better make sure this went
42320 > >through....
42321 > >
42322 > >----- Original Message -----
42323 > >Sent: Friday, October 10, 2003 3:48 PM
42324 > >Subject: Akill problem in 5.0.22
42325 > >
42326 > >
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).
42329 > >
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
42332 >scanning
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...
42337 > >
42338 > >First: IS that what it's supposed to do?
42339 > >
42340 > >Second: If so, it's not working...
42341 > >
42342 > >Saturn
42343 > >www.jetirc.net
42344 > >
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
42351 >
42352 >------------------------------------------------------------------
42353 >To unsubscribe or change your subscription options, visit:
42354 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
42355
42356
42357
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>
42364
42365 >From a.html in the /docs directory:
42366 ---------------
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
42371 it first.
42372     Example: ImmediatelySendAutokill
42373 --------------
42374
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 ------------------------
42389
42390 4.html#oper.akill doesn't mention it at all.
42391
42392 -----------------
42393
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!!!
42401
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?
42407
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???????
42414
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.
42424
42425 Saturn
42426
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
42432
42433
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
42438 >kill them.
42439
42440      The documentation says nothing about this.  RTFM again.
42441
42442   --Andrew Church
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
42448
42449
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>
42457
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.
42465
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
42472 programming...
42473
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
42481
42482
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
42488 to deal with it.
42489
42490 Ballsy
42491
42492
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
42496 >
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
42500 >it first.
42501 >     Example: ImmediatelySendAutokill
42502 >
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
42508 >kill them.
42509 >
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?
42514 >
42515 >Thanks
42516 >Saturn
42517 >
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
42523 >
42524 >
42525 >RTFM
42526 >
42527 >   --Andrew Church
42528 >     achurch@achurch.org
42529 >     http://achurch.org/
42530 >
42531 > >Haven't seen a reply to this one, so thought I'd better make sure this
42532 went
42533 > >through....
42534 > >
42535 > >----- Original Message -----
42536 > >Sent: Friday, October 10, 2003 3:48 PM
42537 > >Subject: Akill problem in 5.0.22
42538 > >
42539 > >
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).
42542 > >
42543 > >I just today added an akill (+0 time) .. I DO have the immediate auto
42544 kill
42545 > >option un-commented in the modules.conf, but it still didn't bother
42546 >scanning
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
42549 thought
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...
42552 > >
42553 > >First: IS that what it's supposed to do?
42554 > >
42555 > >Second: If so, it's not working...
42556 > >
42557 > >Saturn
42558 > >www.jetirc.net
42559 > >
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
42566 >
42567 >------------------------------------------------------------------
42568 >To unsubscribe or change your subscription options, visit:
42569 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
42570
42571
42572 ------------------------------------------------------------------
42573 To unsubscribe or change your subscription options, visit:
42574 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
42575
42576
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>
42582
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.
42584
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
42586
42587 Please just calm down, and talk this out rationally before you start jumping down ppls throats :p
42588
42589 /*****************************************
42590  *     Craig "FrostyCoolSlug" McLure
42591  * InspIRCd   - http://www.inspircd.org
42592  * ChatSpike  - http://www.chatspike.net
42593  ****************************************/
42594
42595
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  ****************************************/
42602
42603 /****** - Begin Original Message - ******/
42604
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.
42612 >
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
42619 >programming...
42620 >
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
42628 >
42629 >
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
42635 >to deal with it.
42636 >
42637 >Ballsy
42638 >
42639 >
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
42643 >>
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
42647 >>it first.
42648 >>     Example: ImmediatelySendAutokill
42649 >>
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
42655 >>kill them.
42656 >>
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?
42661 >>
42662 >>Thanks
42663 >>Saturn
42664 >>
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
42670 >>
42671 >>
42672 >>RTFM
42673 >>
42674 >>   --Andrew Church
42675 >>     achurch@achurch.org
42676 >>     http://achurch.org/
42677 >>
42678 >> >Haven't seen a reply to this one, so thought I'd better make sure this
42679 >went
42680 >> >through....
42681 >> >
42682 >> >----- Original Message -----
42683 >> >Sent: Friday, October 10, 2003 3:48 PM
42684 >> >Subject: Akill problem in 5.0.22
42685 >> >
42686 >> >
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).
42689 >> >
42690 >> >I just today added an akill (+0 time) .. I DO have the immediate auto
42691 >kill
42692 >> >option un-commented in the modules.conf, but it still didn't bother
42693 >>scanning
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
42696 >thought
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...
42699 >> >
42700 >> >First: IS that what it's supposed to do?
42701 >> >
42702 >> >Second: If so, it's not working...
42703 >> >
42704 >> >Saturn
42705 >> >www.jetirc.net
42706 >> >
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
42713 >>
42714 >>------------------------------------------------------------------
42715 >>To unsubscribe or change your subscription options, visit:
42716 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
42717 >
42718 >
42719 >------------------------------------------------------------------
42720 >To unsubscribe or change your subscription options, visit:
42721 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
42722 >
42723 >------------------------------------------------------------------
42724 >To unsubscribe or change your subscription options, visit:
42725 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
42726 >
42727 >.
42728
42729 /******* - End Original Message - *******/
42730
42731
42732
42733
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>
42740
42741      You know, I might have been more forgiving if this hadn't been gone
42742 over on this list (twice!) before:
42743
42744 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/002305.html
42745 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/003215.html
42746
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
42749 edification:
42750
42751 F.10. Services doesn't kill users matching a newly-added autokill mask even
42752 if ImmediatelySendAutokill is set.
42753
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.
42760
42761         Note that some IRC servers will themselves kill users matching a
42762         newly-added autokill; this is unrelated to Services.
42763
42764   --Andrew Church
42765     achurch@achurch.org
42766     http://achurch.org/
42767
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>
42777
42778 Saturn wrote:
42779
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.
42787 >
42788 >
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
42795 do this.
42796
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).
42801
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.
42805
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.
42813
42814
42815
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>
42824
42825 On Saturday 18 October 2003 07:20, Robert F Merrill wrote:
42826 > Saturn 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.
42834 >
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
42841 > do this.
42842
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.
42845
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.
42850
42851 <<V13>>
42852
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>
42859
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)
42870
42871 root@irc(/home/ircadmin/services/lib)# ls -la core.12631
42872 -rw-------    1 ircadmin ircadmin 47374336 Oct 18 16:05 core.12631
42873
42874
42875 continue on the next message......
42876
42877
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>
42884
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;
42889 (gdb) bt'
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
42893         s = 0x806aa3e ""
42894 #1  0x0804d342 in set_cmode (sender=0x81db058 "ChanServ", channel=0xa905d00)
42895 at actions.c:446
42896         parambuf =
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"...
42905         len = 10
42906         flag = 1
42907         params = 1
42908         is_chanuser = 1
42909         args = 0xbfffe6d0 "RDcoCOREcorei??i??i??i??o"
42910         modes = 0xbfffeae2 ""
42911         modes_orig = 0xbfffeae0 "+o"
42912         md = (struct modedata *) 0x806aa00
42913         which = 0
42914         add = 1
42915         i = 1
42916         c = 111 'o'
42917 #2  0x400895ff in local_set_cumodes (c=0xa905d00, plusminus=43 '+', modes=1,
42918 nick=0xab7f2e8 "balsanelli") at check.c:432
42919         buf = "+o"
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).."...
42924         s = 0xbfffe6e1 ""
42925 #3  0x40088d74 in check_chan_user_modes (source=0xbfffeed0 "|-Frango-|",
42926 u=0xab34ff0, c=0xa905d00, oldmodes=1)
42927     at check.c:214
42928         user = (User *) 0xab7f2d8
42929         ci = (ChannelInfo *) 0xa571940
42930         modes = 0
42931         is_servermode = 0
42932         res = 1
42933 #4  0x400820ed in do_channel_umode_change (source=0xbfffeed0 "|-Frango-|",
42934 c=0xa905d00, u=0xab34ff0, oldmodes=1)
42935     at main.c:354
42936 No locals.
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
42941         res = 0
42942         i = 0
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---
42946     at channels.c:409
42947         u = (struct c_userlist *) 0xab34ff0
42948         user = (User *) 0xab7f2d8
42949         oldmode = 1
42950 #7  0x0804e97e in do_cmode (source=0xbfffeed0 "|-Frango-|", ac=0,
42951 av=0xa853130) at channels.c:302
42952         modechar = 111 'o'
42953         flag = 1
42954         params = -1073746288
42955         chan = (Channel *) 0xa905d00
42956         s = 0xbfffeca5 ""
42957         add = 0
42958         modestr = 0xbfffec9e "-oooooo"
42959 #8  0x080557ff in m_mode (source=0xbfffeed0 "|-Frango-|", ac=8,
42960 av=0xa853110) at messages.c:101
42961 No locals.
42962 #9  0x0805920e in process () at process.c:133
42963         m = (Message *) 0x8067dd8
42964         source =
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
42967 5\b"
42968         cmd =
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"
42972         buf =
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"
42980         ac = 8
42981         av = (char **) 0xa853110
42982 #10 0x0805507d in readline_callback (s=0xa851ae0, param_unused=0x50) at
42983 main.c:177
42984 No locals.
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."...
42990         left = 80
42991         newleft = 80
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}
42995         i = 4
42996         res = 260
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---
43001         now = 1066500331
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.
43007 (gdb)
43008
43009
43010
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>
43017
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.
43025
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?
43039
43040 Thank you all for your time.
43041
43042 Saturn
43043
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
43049
43050
43051      You know, I might have been more forgiving if this hadn't been gone
43052 over on this list (twice!) before:
43053
43054 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/002305.html
43055 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/003215.html
43056
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
43059 edification:
43060
43061 F.10. Services doesn't kill users matching a newly-added autokill mask even
43062 if ImmediatelySendAutokill is set.
43063
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.
43070
43071 Note that some IRC servers will themselves kill users matching a
43072 newly-added autokill; this is unrelated to Services.
43073
43074   --Andrew Church
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
43080
43081
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>
43087
43088 If it helps, more lines up.. of debugging...
43089
43090
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)
43103
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>
43115
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.
43121
43122 Ballsy
43123
43124
43125 At 12:49 PM 18/10/2003, V13 wrote:
43126 >On Saturday 18 October 2003 07:20, Robert F Merrill wrote:
43127 > > Saturn 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.
43135 > >
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
43142 > > do this.
43143 >
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.
43146 >
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.
43151 >
43152 ><<V13>>
43153 >------------------------------------------------------------------
43154 >To unsubscribe or change your subscription options, visit:
43155 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
43156
43157
43158
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>
43164
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>
43172
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
43175
43176 ciao
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>
43186
43187 Andrew, have anything more of dumping/debugging that i can do/give for helps
43188 fixing this bug..?
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)....
43191 anything more?
43192
43193
43194 Thanks for all
43195
43196
43197 Diego B. Contezini
43198
43199
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>
43205
43206
43207
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>
43213
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
43216 18:41:36 BRT 2003)
43217 yes, 5.0.23 is the last.. but nothing has changed about the bug...
43218
43219  here is the debugging:
43220
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
43225 #Euevc
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
43233 +stmipl 1
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)
43245
43246
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;
43252 (gdb) bt'
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
43256         s = 0x806aa3e ""
43257 #1  0x0804d342 in set_cmode (sender=0x81db058 "ChanServ", channel=0xa905d00)
43258 at actions.c:446
43259         parambuf =
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"...
43268         len = 10
43269         flag = 1
43270         params = 1
43271         is_chanuser = 1
43272         args = 0xbfffe6d0 "RDcoCOREcorei??i??i??i??o"
43273         modes = 0xbfffeae2 ""
43274         modes_orig = 0xbfffeae0 "+o"
43275         md = (struct modedata *) 0x806aa00
43276         which = 0
43277         add = 1
43278         i = 1
43279         c = 111 'o'
43280 #2  0x400895ff in local_set_cumodes (c=0xa905d00, plusminus=43 '+', modes=1,
43281 nick=0xab7f2e8 "balsanelli") at check.c:432
43282         buf = "+o"
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).."...
43287         s = 0xbfffe6e1 ""
43288 #3  0x40088d74 in check_chan_user_modes (source=0xbfffeed0 "|-Frango-|",
43289 u=0xab34ff0, c=0xa905d00, oldmodes=1)
43290     at check.c:214
43291         user = (User *) 0xab7f2d8
43292         ci = (ChannelInfo *) 0xa571940
43293         modes = 0
43294         is_servermode = 0
43295         res = 1
43296 #4  0x400820ed in do_channel_umode_change (source=0xbfffeed0 "|-Frango-|",
43297 c=0xa905d00, u=0xab34ff0, oldmodes=1)
43298     at main.c:354
43299 No locals.
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
43304         res = 0
43305         i = 0
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---
43309     at channels.c:409
43310         u = (struct c_userlist *) 0xab34ff0
43311         user = (User *) 0xab7f2d8
43312         oldmode = 1
43313 #7  0x0804e97e in do_cmode (source=0xbfffeed0 "|-Frango-|", ac=0,
43314 av=0xa853130) at channels.c:302
43315         modechar = 111 'o'
43316         flag = 1
43317         params = -1073746288
43318         chan = (Channel *) 0xa905d00
43319         s = 0xbfffeca5 ""
43320         add = 0
43321         modestr = 0xbfffec9e "-oooooo"
43322 #8  0x080557ff in m_mode (source=0xbfffeed0 "|-Frango-|", ac=8,
43323 av=0xa853110) at messages.c:101
43324 No locals.
43325 #9  0x0805920e in process () at process.c:133
43326         m = (Message *) 0x8067dd8
43327         source =
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
43330 5\b"
43331         cmd =
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"
43335         buf =
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"
43343         ac = 8
43344         av = (char **) 0xa853110
43345 #10 0x0805507d in readline_callback (s=0xa851ae0, param_unused=0x50) at
43346 main.c:177
43347 No locals.
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."...
43353         left = 80
43354         newleft = 80
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}
43358         i = 4
43359         res = 260
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---
43364         now = 1066500331
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
43381 cs             0x23     35
43382 ss             0x2b     43
43383 ds             0x2b     43
43384 es             0x2b     43
43385 fs             0x0      0
43386 gs             0x33     51
43387 (gdb)
43388
43389
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
43402 ...
43403 model name      : Pentium III (Coppermine)
43404 stepping        : 10
43405 cpu MHz         : 999.752
43406 cache size      : 256 KB
43407 ...
43408 root@irc(/home/ircadmin/services)# free
43409              total       used       free     shared    buffers     cached
43410 Mem:        513792     482248      31544          0      69492     274980
43411
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*
43421
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
43433
43434
43435 If it helps, here is the debugging of the last two cores, on gdb:
43436 ----------------
43437 FIRST:
43438 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
43439 av=0xbfffdc38)
43440     at channels.c:278
43441 278         while (*s) {
43442 (gdb) bt'
43443 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
43444 av=0xbfffdc38)
43445     at channels.c:278
43446         chan = (Channel *) 0xa87d1e0
43447         s = 0x1f73746f <Address 0x1f73746f out of bounds>
43448         add = 1
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
43458 \006\b"...
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>}
43468         len = 5
43469 ---Type <return> to continue, or q <return> to quit---
43470         i = 0
43471         lastc = 45 '-'
43472 #2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
43473         args = 0x0
43474         modes = 0x0
43475         modes_orig = 0x0
43476         md = (struct modedata *) 0x0
43477         which = -1
43478         add = 0
43479         i = 0
43480         c = 0 '\0'
43481 #3  0x080553a3 in main (ac=1, av=0xbfffe574, envp=0xbfffe57c) at main.c:269
43482         now = 1067891066
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.
43488 -----------
43489
43490 SECOND:
43491 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
43492 av=0xbffff2b8)
43493     at channels.c:278
43494 278         while (*s) {
43495 (gdb) bt'
43496 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
43497 av=0xbffff2b8)
43498     at channels.c:278
43499         chan = (Channel *) 0xa9be840
43500         s = 0xbf000000 <Address 0xbf000000 out of bounds>
43501         add = 1
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>}
43518         len = 5
43519         i = 0
43520         lastc = 45 '-'
43521 #2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
43522 ---Type <return> to continue, or q <return> to quit---
43523         args = 0x0
43524         modes = 0x0
43525         modes_orig = 0x0
43526         md = (struct modedata *) 0x0
43527         which = -1
43528         add = 0
43529         i = 0
43530         c = 0 '\0'
43531 #3  0x080553a3 in main (ac=1, av=0xbffffbf4, envp=0xbffffbfc) at main.c:269
43532         now = 1067706795
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.
43538 (gdb)
43539 -------
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
43542 this bug...
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
43546 anything....
43547
43548 Thanks for all development, this is really a bealtifull software...
43549 (and sorry for my bad english)
43550
43551 Diego B. Contezini aka destruct_ #irc.redesul.net
43552
43553
43554
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>
43560
43561 If it helps, im using Bahamut here....
43562
43563
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>
43570
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 ?
43579
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.
43589
43590   --Andrew Church
43591     achurch@achurch.org
43592     http://achurch.org/
43593
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>
43599
43600 I'm getting this too - it's just started happening in 5.0.23:
43601
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'
43606
43607 gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
43608
43609 Russ
43610
43611
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>
43617
43618
43619
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>
43625
43626 Hi,
43627
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:
43631
43632 ***************************
43633 -
43634 -NickServ- nick is hello world
43635 -
43636 -NickServ- Is online from: ~test@just.a.test.co.za
43637 -
43638 -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
43639 -
43640 -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
43641 -
43642 -NickServ- Last quit message: anythinggggg
43643 -
43644 -NickServ- Options: Kill protection, Security
43645 -
43646 ***************************
43647
43648 the new line I'm suggesting is something like:
43649
43650 ***************************
43651 -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
43652 ***************************
43653
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).
43659
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)
43663
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)
43666
43667 Many thanks to all of who developed IRCservices ...etc ...etc ...etc
43668
43669 sincerely,
43670 David
43671
43672 _________________________________________________________________
43673 Get MSN 8 and enjoy automatic e-mail virus protection.
43674 http://join.msn.com/?page=features/virus
43675
43676
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>
43684
43685 Or how about rather letting users decide what timezone they're in and
43686 services outputs all timestamps in their local time?
43687
43688
43689 | By us44ever . <us44ever@hotmail.com>
43690 |                                          [ 2003-08-28 18:45 +0200 ]
43691 > Hi,
43692 >
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:
43696 >
43697 > ***************************
43698 > -
43699 > -NickServ- nick is hello world
43700 > -
43701 > -NickServ- Is online from: ~test@just.a.test.co.za
43702 > -
43703 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
43704 > -
43705 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
43706 > -
43707 > -NickServ- Last quit message: anythinggggg
43708 > -
43709 > -NickServ- Options: Kill protection, Security
43710 > -
43711 > ***************************
43712 >
43713 > the new line I'm suggesting is something like:
43714 >
43715 > ***************************
43716 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
43717 > ***************************
43718 >
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).
43724 >
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)
43728 >
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)
43731 >
43732 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
43733 >
43734 > sincerely,
43735 > David
43736 >
43737 > _________________________________________________________________
43738 > Get MSN 8 and enjoy automatic e-mail virus protection.
43739 > http://join.msn.com/?page=features/virus
43740 >
43741 > ------------------------------------------------------------------
43742 > To unsubscribe or change your subscription options, visit:
43743 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
43744
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>
43752
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
43760
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
43766
43767
43768 Or how about rather letting users decide what timezone they're in and
43769 services outputs all timestamps in their local time?
43770
43771
43772 | By us44ever . <us44ever@hotmail.com>
43773 |                                          [ 2003-08-28 18:45 +0200 ]
43774 > Hi,
43775 >
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:
43779 >
43780 > ***************************
43781 > -
43782 > -NickServ- nick is hello world
43783 > -
43784 > -NickServ- Is online from: ~test@just.a.test.co.za
43785 > -
43786 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
43787 > -
43788 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
43789 > -
43790 > -NickServ- Last quit message: anythinggggg
43791 > -
43792 > -NickServ- Options: Kill protection, Security
43793 > -
43794 > ***************************
43795 >
43796 > the new line I'm suggesting is something like:
43797 >
43798 > ***************************
43799 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
43800 > ***************************
43801 >
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).
43807 >
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)
43811 >
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)
43814 >
43815 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
43816 >
43817 > sincerely,
43818 > David
43819 >
43820 > _________________________________________________________________
43821 > Get MSN 8 and enjoy automatic e-mail virus protection.
43822 > http://join.msn.com/?page=features/virus
43823 >
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
43830
43831
43832
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>
43838
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..
43840
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
43843
43844 *shock*
43845
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  ****************************************/
43853
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  ****************************************/
43860
43861 /****** - Begin Original Message - ******/
43862
43863 >Hi,
43864 >
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:
43868 >
43869 >***************************
43870 >-
43871 >-NickServ- nick is hello world
43872 >-
43873 >-NickServ- Is online from: ~test@just.a.test.co.za
43874 >-
43875 >-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
43876 >-
43877 >-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
43878 >-
43879 >-NickServ- Last quit message: anythinggggg
43880 >-
43881 >-NickServ- Options: Kill protection, Security
43882 >-
43883 >***************************
43884 >
43885 >the new line I'm suggesting is something like:
43886 >
43887 >***************************
43888 >-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
43889 >***************************
43890 >
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).
43896 >
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)
43900 >
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)
43903 >
43904 >Many thanks to all of who developed IRCservices ...etc ...etc ...etc
43905 >
43906 >sincerely,
43907 >David
43908 >
43909 >_________________________________________________________________
43910 >Get MSN 8 and enjoy automatic e-mail virus protection.
43911 >http://join.msn.com/?page=features/virus
43912 >
43913 >------------------------------------------------------------------
43914 >To unsubscribe or change your subscription options, visit:
43915 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
43916
43917 /******* - End Original Message - *******/
43918
43919
43920
43921
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>
43927
43928 We're having a small problem with suspended channel.
43929
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.
43932
43933 Also with suspended nick , when the suspencion expire, the services crash
43934 We're using:
43935
43936 ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
43937
43938
43939 Thanks
43940 Marc
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>
43949
43950 hmm.. what OS, compiler version etc are you using?
43951
43952 after a test, i got the following:
43953
43954 /cs id #abc 00376370
43955 -ChanServ- Channel #abc is suspended and may not be used or identified for.
43956
43957 /cs drop #abc
43958 [23:20] -ChanServ- Channel  is suspended and may not be used or identified for.
43959
43960 only prob i got was it missed the channel name in the second message :)
43961
43962 /cs drop #abc
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  ****************************************/
43970
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  ****************************************/
43977
43978 /****** - Begin Original Message - ******/
43979
43980 >We're having a small problem with suspended channel.
43981 >
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.
43984 >
43985 >Also with suspended nick , when the suspencion expire, the services crash
43986 >We're using:
43987 >
43988 >ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
43989 >
43990 >
43991 >Thanks
43992 >Marc
43993 >------------------------------------------------------------------
43994 >To unsubscribe or change your subscription options, visit:
43995 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
43996
43997 /******* - End Original Message - *******/
43998
43999
44000
44001
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>
44008
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...
44013
44014 Just an idea... I now await the half dozen people who will proceed to tell
44015 me how stupid my idea is....
44016
44017 Saturn
44018 irc.jetirc.net
44019
44020
44021
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>
44029
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.
44034
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..
44038 >
44039 > /time services.chatspike.net
44040 > [22:28] ??? Date / time at services.chatspike.net- Thu Aug 28 17:28:57
44041 > 2003 EDT
44042 >
44043 > *shock*
44044 >
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 >  ****************************************/
44052 >
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 >  ****************************************/
44059 >
44060 > /****** - Begin Original Message - ******/
44061 >
44062 >>Hi,
44063 >>
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:
44067 >>
44068 >>***************************
44069 >>-
44070 >>-NickServ- nick is hello world
44071 >>-
44072 >>-NickServ- Is online from: ~test@just.a.test.co.za
44073 >>-
44074 >>-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
44075 >>-
44076 >>-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
44077 >>-
44078 >>-NickServ- Last quit message: anythinggggg
44079 >>-
44080 >>-NickServ- Options: Kill protection, Security
44081 >>-
44082 >>***************************
44083 >>
44084 >>the new line I'm suggesting is something like:
44085 >>
44086 >>***************************
44087 >>-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
44088 >>***************************
44089 >>
44090 >>This will help our users to compare the time that user was last seen and
44091 >> the
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
44095 >> GMT
44096 >>(last seen time was before: 10 days, 3hours and 24 sec ago).
44097 >>
44098 >>Note that I saw both of these features, in other services I don't
44099 >> remember
44100 >>there names (but they aren't as stable as ircservices5) (it was something
44101 >>like ptlink services, and magik II)
44102 >>
44103 >>That's all, I would really like to see it on the next version (or if you
44104 >> can
44105 >>show me how to do it, as I'm not a programmer)
44106 >>
44107 >>Many thanks to all of who developed IRCservices ...etc ...etc ...etc
44108 >>
44109 >>sincerely,
44110 >>David
44111 >>
44112 >>_________________________________________________________________
44113 >>Get MSN 8 and enjoy automatic e-mail virus protection.
44114 >>http://join.msn.com/?page=features/virus
44115 >>
44116 >>------------------------------------------------------------------
44117 >>To unsubscribe or change your subscription options, visit:
44118 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
44119 >
44120 > /******* - End Original Message - *******/
44121 >
44122 >
44123 >
44124 > ------------------------------------------------------------------
44125 > To unsubscribe or change your subscription options, visit:
44126 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
44127 >
44128
44129
44130 --
44131 Best Regards,
44132 playa
44133 Network Founder/CEO
44134 DreamChat IRC Network - irc.dreamchat.org
44135 http://www.dreamchat.org
44136
44137
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>
44144
44145 On Thursday, Aug 28, 2003, at 20:46 US/Pacific, playa wrote:
44146
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.
44151
44152 That's a client thing.  Some clients might alias /time as a CTCP TIME
44153 for a specific user, or similar.
44154
44155 -- Quension
44156
44157
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>
44166
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.
44171
44172 Some clients use stupid aliases for CTCP commands, for example:
44173
44174 /version <nick> = /CTCP <nick> VERSION,
44175 /time <nick> = /CTCP <nick> TIME,
44176 /finger <nick> = /CTCP <nick> TIME
44177
44178 This is why nothing works the way you expected.
44179
44180 --
44181 Krisztian Romek
44182 r-krisztian@softhome.net
44183
44184
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>
44190
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).
44194
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
44198
44199
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>
44205
44206
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.
44212
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
44216
44217
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>
44223
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.
44225
44226 And i'll Quote Elijah:
44227
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
44230 be 'no.'"
44231
44232
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  ****************************************/
44240
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  ****************************************/
44247
44248 /****** - Begin Original Message - ******/
44249
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.
44255 >
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
44259 >
44260 >------------------------------------------------------------------
44261 >To unsubscribe or change your subscription options, visit:
44262 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
44263 >.
44264
44265 /******* - End Original Message - *******/
44266
44267
44268
44269
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>
44275
44276 its a stupid idea!!! :p
44277
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
44279
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  ****************************************/
44287
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  ****************************************/
44294
44295 /****** - Begin Original Message - ******/
44296
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...
44301 >
44302 >Just an idea... I now await the half dozen people who will proceed to tell
44303 >me how stupid my idea is....
44304 >
44305 >Saturn
44306 >irc.jetirc.net
44307 >
44308 >
44309 >------------------------------------------------------------------
44310 >To unsubscribe or change your subscription options, visit:
44311 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
44312
44313 /******* - End Original Message - *******/
44314
44315
44316
44317
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>
44324
44325 Cheers.
44326
44327 -----Original Message-----
44328 From: ircservices-coding-bounces@ircservices.za.net
44329 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of Craig
44330 McLure
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
44334
44335
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
44338 to annoy me.
44339
44340 And i'll Quote Elijah:
44341
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
44344 be 'no.'"
44345
44346
44347
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>
44353
44354 woops, ok sorry I thought the two e-mails is completely different.
44355
44356
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
44364 >
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.
44368 >
44369 >And i'll Quote Elijah:
44370 >
44371 >"Except it's already been said in the FAQ that it's not going to happen,
44372 >and
44373 >if that made it into the FAQ it would seem the answer is frequently going
44374 >to
44375 >be 'no.'"
44376 >
44377 >
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 >  ****************************************/
44385 >
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 >  ****************************************/
44392 >
44393 >/****** - Begin Original Message - ******/
44394 >
44395 > >Since most people want to see this feature(s) in the next version, it
44396 >would
44397 > >be great to implement it as an optional feature , where it can be
44398 >disabled
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
44401 >fact,
44402 > >it will add another nice feature to the features list of IRCservices5.
44403 > >
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
44407 > >
44408 > >------------------------------------------------------------------
44409 > >To unsubscribe or change your subscription options, visit:
44410 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
44411 > >.
44412 >
44413 >/******* - End Original Message - *******/
44414 >
44415 >
44416 >
44417 >------------------------------------------------------------------
44418 >To unsubscribe or change your subscription options, visit:
44419 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
44420
44421 _________________________________________________________________
44422 MSN 8: Get 6 months for $9.95/month. http://join.msn.com/?page=dept/dialup
44423
44424
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>
44431
44432 Hi
44433 I run ircservices 5.0.21 on FreeBSD 4.8-STABLE. and Ultimate 3.*
44434 I get this in logfile:
44435
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)
44448
44449 and how can I do so that nickserv dont show the realhost of a user in
44450 'ns info nick all'
44451
44452
44453 thanks for help
44454
44455                            Ali "Simorgh"
44456  ______________________________________________________
44457  Many of life's failures are people who did not realize
44458  how close they were to success when they gave up.
44459  Thomas A. Edison
44460  ______________________________________________________
44461
44462
44463
44464
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>
44471
44472 "and how can I do so that nickserv dont show the realhost of a user in
44473 'ns info nick all'"
44474
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
44478 option is set.
44479
44480
44481
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>
44488
44489      Needless complexity.  If you don't want yourself autoopped, then don't
44490 be an auto-op.  It's that simple.
44491
44492   --Andrew Church
44493     achurch@achurch.org
44494     http://achurch.org/
44495
44496 >Hi again
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.
44499 >
44500 >Like:
44501 > SET NOAUTO ON|OFF
44502 >  When NOAUTO is on, ChanServ will not
44503 >  automatically op or voice you in any channels.
44504 >
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.
44507 >
44508 >Or did I miss it?
44509 >
44510 >Thanks
44511 >
44512 >                           Ali "Simorgh"
44513 > ______________________________________________________
44514 > Many of life's failures are people who did not realize
44515 > how close they were to success when they gave up.
44516 > Thomas A. Edison
44517 > ______________________________________________________
44518 >
44519 >
44520 >On Sun, 17 Aug 2003, Russell Garrett wrote:
44521 >
44522 >> Eh? This has been implemented since IRCServices 5a31.
44523 >>
44524 >> Russ
44525 >>
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)
44530 >> >
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
44533 >> > channels.
44534 >> >
44535 >> > Thanks for any help
44536 >>
44537 >> ------------------------------------------------------------------
44538 >> To unsubscribe or change your subscription options, visit:
44539 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
44540 >>
44541 >
44542 >------------------------------------------------------------------
44543 >To unsubscribe or change your subscription options, visit:
44544 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
44545
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>
44551
44552 Where is the akill type used in some of the AutoKill functions listed in the
44553 modules/database/readme file defined?
44554
44555 ________________________________________________
44556 Message sent using MHCABLE Webmail
44557
44558
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>
44568
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 :)
44573
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
44579         cat <<EOT
44580
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
44586
44587
44588 ________________________________________________________________
44589 Matthew Hodgson   arathorn@theonering.net   Tel: +44 7968 722968
44590              Arathorn: Co-Sysadmin, TheOneRing.net?
44591
44592 On Wed, 12 Nov 2003, Arathorn wrote:
44593
44594 > Hi Andy,
44595 >
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
44600 > anyway).
44601 >
44602 > Here's the stderr & stdio - the configure.log is attached:
44603 >
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
44608 >
44609 > Beginning IRC Services configuration.
44610 >
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
44614 >
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
44617 >
44618 > End of interactive configuration.
44619 >
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
44624 >
44625 > WARNING: Your version of GCC was detected as Press Enter to continue:
44626 >
44627 >
44628 >
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! ***
44636 >
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.
44643 >
44644 > ________________________________________________________________
44645 > Matthew Hodgson   arathorn@theonering.net   Tel: +44 7968 722968
44646 >              Arathorn: Co-Sysadmin, TheOneRing.net?
44647 >
44648 > On Tue, 11 Nov 2003, Andrew Church wrote:
44649 >
44650 > >      Services 5.0.24 has been released, and can be downloaded from:
44651 > >
44652 > > ftp://ftp.esper.net/ircservices/               (USA, California)
44653 > >
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
44658 > >
44659 > > ftp.ircservices.za.net and the other mirrors should have it shortly.
44660 > >
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.
44666 > >
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>
44683 > >
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
44690 > >
44691 > >
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
44698         cat <<EOT
44699
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>
44711
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:
44715
44716
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
44722         cat <<EOT
44723
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
44729
44730
44731
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.)
44735
44736 ________________________________________________________________
44737 Matthew Hodgson   arathorn@theonering.net   Tel: +44 7968 722968
44738              Arathorn: Co-Sysadmin, TheOneRing.net?
44739
44740 On Wed, 12 Nov 2003, Arathorn wrote:
44741
44742 > Hi Andy,
44743 >
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
44748 > anyway).
44749 >
44750 > Here's the stderr & stdio - the configure.log is attached:
44751 >
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
44756 >
44757 > Beginning IRC Services configuration.
44758 >
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
44762 >
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
44765 >
44766 > End of interactive configuration.
44767 >
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
44772 >
44773 > WARNING: Your version of GCC was detected as Press Enter to continue:
44774 >
44775 >
44776 >
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! ***
44784 >
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.
44791 >
44792 > ________________________________________________________________
44793 > Matthew Hodgson   arathorn@theonering.net   Tel: +44 7968 722968
44794 >              Arathorn: Co-Sysadmin, TheOneRing.net?
44795 >
44796 > On Tue, 11 Nov 2003, Andrew Church wrote:
44797 >
44798 > >      Services 5.0.24 has been released, and can be downloaded from:
44799 > >
44800 > > ftp://ftp.esper.net/ircservices/               (USA, California)
44801 > >
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
44806 > >
44807 > > ftp.ircservices.za.net and the other mirrors should have it shortly.
44808 > >
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.
44814 > >
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>
44831 > >
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
44838 > >
44839 > >
44840
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>
44849
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.
44860
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
44866         cat <<EOT
44867
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 @@
44874  EOT
44875         echo2 "Press Enter to continue: "
44876         read dummy
44877 +       CC=gcc
44878 +       DEF_CC_FLAGS=`def_cc_flags $CC`
44879 +       log using \`gcc\'
44880         WARNED_OLD_GCC=1
44881      else  # version okay
44882         echo "great, found gcc!"
44883
44884
44885 ________________________________________________________________
44886 Matthew Hodgson   arathorn@theonering.net   Tel: +44 7968 722968
44887              Arathorn: Co-Sysadmin, TheOneRing.net?
44888
44889 On Sat, 15 Nov 2003, Andrew Church wrote:
44890
44891 >      Thanks, fixed.  Silly little details...
44892 >
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.)
44896 >
44897 >   --Andrew Church
44898 >     achurch@achurch.org
44899 >     http://achurch.org/
44900 >
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:
44904 > >
44905 > >
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
44911 > >     cat <<EOT
44912 > >
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
44918 > >
44919 > >
44920 > >
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.)
44924 > >
44925 > >________________________________________________________________
44926 > >Matthew Hodgson   arathorn@theonering.net   Tel: +44 7968 722968
44927 > >             Arathorn: Co-Sysadmin, TheOneRing.net??
44928 > >
44929 > >On Wed, 12 Nov 2003, Arathorn wrote:
44930 > >
44931 > >> Hi Andy,
44932 > >>
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
44937 > >> anyway).
44938 > >>
44939 > >> Here's the stderr & stdio - the configure.log is attached:
44940 > >>
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
44945 > >>
44946 > >> Beginning IRC Services configuration.
44947 > >>
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
44951 > >>
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
44954 > >>
44955 > >> End of interactive configuration.
44956 > >>
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
44961 > >>
44962 > >> WARNING: Your version of GCC was detected as Press Enter to continue:
44963 > >>
44964 > >>
44965 > >>
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! ***
44973 > >>
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.
44980 > >>
44981 > >> ________________________________________________________________
44982 > >> Matthew Hodgson   arathorn@theonering.net   Tel: +44 7968 722968
44983 > >>              Arathorn: Co-Sysadmin, TheOneRing.net??
44984 > >>
44985 > >> On Tue, 11 Nov 2003, Andrew Church wrote:
44986 > >>
44987 > >> >      Services 5.0.24 has been released, and can be downloaded from:
44988 > >> >
44989 > >> > ftp://ftp.esper.net/ircservices/               (USA, California)
44990 > >> >
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
44995 > >> >
44996 > >> > ftp.ircservices.za.net and the other mirrors should have it shortly.
44997 > >> >
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.
45003 > >> >
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>
45020 > >> >
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
45027 > >> >
45028 > >> >
45029 >
45030 >
45031
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>
45037
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.
45039
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 :)
45041
45042
45043
45044
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
45049         ./configure
45050 Message-ID: <6.0.0.22.0.20031117144131.0481a8c0@127.0.0.1>
45051
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:
45055
45056 Checking sanity of /bin/sh... high.
45057 Searching for a suitable compiler... ./configure: 29: Syntax error: EOF in
45058 backquote substitution
45059
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).
45066
45067 gmake 3.80
45068 FreeBSD 4.9-STABLE
45069
45070 David
45071
45072
45073
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
45078         ./configure
45079 Message-ID: <Pine.LNX.4.56L0.0311181144590.6789@phoenix.siarch.net>
45080
45081 David,
45082
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).
45089
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:
45096
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)
45099
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 :)
45102
45103 A.
45104
45105 ________________________________________________________________
45106 Matthew Hodgson   arathorn@theonering.net   Tel: +44 7968 722968
45107              Arathorn: Co-Sysadmin, TheOneRing.net?
45108
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
45115
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.
45126
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
45132         cat <<EOT
45133
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 @@
45140  EOT
45141         echo2 "Press Enter to continue: "
45142         read dummy
45143 +       CC=gcc
45144 +       DEF_CC_FLAGS=`def_cc_flags $CC`
45145 +       log using \`gcc\'
45146         WARNED_OLD_GCC=1
45147      else  # version okay
45148         echo "great, found gcc!"
45149
45150
45151 ________________________________________________________________
45152 Matthew Hodgson   arathorn@theonering.net   Tel: +44 7968 722968
45153              Arathorn: Co-Sysadmin, TheOneRing.net?
45154
45155 On Sat, 15 Nov 2003, Andrew Church wrote:
45156
45157 >      Thanks, fixed.  Silly little details...
45158 >
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.)
45162 >
45163 >   --Andrew Church
45164 >     achurch@achurch.org
45165 >     http://achurch.org/
45166 >
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:
45170 > >
45171 > >
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
45177 > >     cat <<EOT
45178 > >
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
45184 > >
45185 > >
45186 > >
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.)
45190 > >
45191 > >________________________________________________________________
45192 > >Matthew Hodgson   arathorn@theonering.net   Tel: +44 7968 722968
45193 > >             Arathorn: Co-Sysadmin, TheOneRing.net??
45194 > >
45195 > >On Wed, 12 Nov 2003, Arathorn wrote:
45196 > >
45197 > >> Hi Andy,
45198 > >>
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
45203 > >> anyway).
45204 > >>
45205 > >> Here's the stderr & stdio - the configure.log is attached:
45206 > >>
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
45211 > >>
45212 > >> Beginning IRC Services configuration.
45213 > >>
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
45217 > >>
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
45220 > >>
45221 > >> End of interactive configuration.
45222 > >>
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
45227 > >>
45228 > >> WARNING: Your version of GCC was detected as Press Enter to continue:
45229 > >>
45230 > >>
45231 > >>
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! ***
45239 > >>
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.
45246 > >>
45247 > >> ________________________________________________________________
45248 > >> Matthew Hodgson   arathorn@theonering.net   Tel: +44 7968 722968
45249 > >>              Arathorn: Co-Sysadmin, TheOneRing.net??
45250 > >>
45251 > >> On Tue, 11 Nov 2003, Andrew Church wrote:
45252 > >>
45253 > >> >      Services 5.0.24 has been released, and can be downloaded from:
45254 > >> >
45255 > >> > ftp://ftp.esper.net/ircservices/               (USA, California)
45256 > >> >
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
45261 > >> >
45262 > >> > ftp.ircservices.za.net and the other mirrors should have it shortly.
45263 > >> >
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.
45269 > >> >
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>
45286 > >> >
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
45293 > >> >
45294 > >> >
45295 >
45296 >
45297
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>
45303
45304
45305
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>
45311
45312 Hi,
45313
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:
45317
45318 ***************************
45319 -
45320 -NickServ- nick is hello world
45321 -
45322 -NickServ- Is online from: ~test@just.a.test.co.za
45323 -
45324 -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
45325 -
45326 -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
45327 -
45328 -NickServ- Last quit message: anythinggggg
45329 -
45330 -NickServ- Options: Kill protection, Security
45331 -
45332 ***************************
45333
45334 the new line I'm suggesting is something like:
45335
45336 ***************************
45337 -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
45338 ***************************
45339
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).
45345
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)
45349
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)
45352
45353 Many thanks to all of who developed IRCservices ...etc ...etc ...etc
45354
45355 sincerely,
45356 David
45357
45358 _________________________________________________________________
45359 Get MSN 8 and enjoy automatic e-mail virus protection.
45360 http://join.msn.com/?page=features/virus
45361
45362
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>
45370
45371 Or how about rather letting users decide what timezone they're in and
45372 services outputs all timestamps in their local time?
45373
45374
45375 | By us44ever . <us44ever@hotmail.com>
45376 |                                          [ 2003-08-28 18:45 +0200 ]
45377 > Hi,
45378 >
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:
45382 >
45383 > ***************************
45384 > -
45385 > -NickServ- nick is hello world
45386 > -
45387 > -NickServ- Is online from: ~test@just.a.test.co.za
45388 > -
45389 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
45390 > -
45391 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
45392 > -
45393 > -NickServ- Last quit message: anythinggggg
45394 > -
45395 > -NickServ- Options: Kill protection, Security
45396 > -
45397 > ***************************
45398 >
45399 > the new line I'm suggesting is something like:
45400 >
45401 > ***************************
45402 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
45403 > ***************************
45404 >
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).
45410 >
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)
45414 >
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)
45417 >
45418 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
45419 >
45420 > sincerely,
45421 > David
45422 >
45423 > _________________________________________________________________
45424 > Get MSN 8 and enjoy automatic e-mail virus protection.
45425 > http://join.msn.com/?page=features/virus
45426 >
45427 > ------------------------------------------------------------------
45428 > To unsubscribe or change your subscription options, visit:
45429 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
45430
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>
45438
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
45446
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
45452
45453
45454 Or how about rather letting users decide what timezone they're in and
45455 services outputs all timestamps in their local time?
45456
45457
45458 | By us44ever . <us44ever@hotmail.com>
45459 |                                          [ 2003-08-28 18:45 +0200 ]
45460 > Hi,
45461 >
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:
45465 >
45466 > ***************************
45467 > -
45468 > -NickServ- nick is hello world
45469 > -
45470 > -NickServ- Is online from: ~test@just.a.test.co.za
45471 > -
45472 > -NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
45473 > -
45474 > -NickServ- Time registered: Aug 28 00:13:35 2003 GMT
45475 > -
45476 > -NickServ- Last quit message: anythinggggg
45477 > -
45478 > -NickServ- Options: Kill protection, Security
45479 > -
45480 > ***************************
45481 >
45482 > the new line I'm suggesting is something like:
45483 >
45484 > ***************************
45485 > -NickServ- Time Now : Aug 28 15:54:04 2003 GMT
45486 > ***************************
45487 >
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).
45493 >
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)
45497 >
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)
45500 >
45501 > Many thanks to all of who developed IRCservices ...etc ...etc ...etc
45502 >
45503 > sincerely,
45504 > David
45505 >
45506 > _________________________________________________________________
45507 > Get MSN 8 and enjoy automatic e-mail virus protection.
45508 > http://join.msn.com/?page=features/virus
45509 >
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
45516
45517
45518
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>
45524
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..
45526
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
45529
45530 *shock*
45531
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  ****************************************/
45539
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  ****************************************/
45546
45547 /****** - Begin Original Message - ******/
45548
45549 >Hi,
45550 >
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:
45554 >
45555 >***************************
45556 >-
45557 >-NickServ- nick is hello world
45558 >-
45559 >-NickServ- Is online from: ~test@just.a.test.co.za
45560 >-
45561 >-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
45562 >-
45563 >-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
45564 >-
45565 >-NickServ- Last quit message: anythinggggg
45566 >-
45567 >-NickServ- Options: Kill protection, Security
45568 >-
45569 >***************************
45570 >
45571 >the new line I'm suggesting is something like:
45572 >
45573 >***************************
45574 >-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
45575 >***************************
45576 >
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).
45582 >
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)
45586 >
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)
45589 >
45590 >Many thanks to all of who developed IRCservices ...etc ...etc ...etc
45591 >
45592 >sincerely,
45593 >David
45594 >
45595 >_________________________________________________________________
45596 >Get MSN 8 and enjoy automatic e-mail virus protection.
45597 >http://join.msn.com/?page=features/virus
45598 >
45599 >------------------------------------------------------------------
45600 >To unsubscribe or change your subscription options, visit:
45601 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
45602
45603 /******* - End Original Message - *******/
45604
45605
45606
45607
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>
45613
45614 We're having a small problem with suspended channel.
45615
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.
45618
45619 Also with suspended nick , when the suspencion expire, the services crash
45620 We're using:
45621
45622 ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
45623
45624
45625 Thanks
45626 Marc
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>
45635
45636 hmm.. what OS, compiler version etc are you using?
45637
45638 after a test, i got the following:
45639
45640 /cs id #abc 00376370
45641 -ChanServ- Channel #abc is suspended and may not be used or identified for.
45642
45643 /cs drop #abc
45644 [23:20] -ChanServ- Channel  is suspended and may not be used or identified for.
45645
45646 only prob i got was it missed the channel name in the second message :)
45647
45648 /cs drop #abc
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  ****************************************/
45656
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  ****************************************/
45663
45664 /****** - Begin Original Message - ******/
45665
45666 >We're having a small problem with suspended channel.
45667 >
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.
45670 >
45671 >Also with suspended nick , when the suspencion expire, the services crash
45672 >We're using:
45673 >
45674 >ircservices-5.0.21 services.terra.cl build #4, compiled Sat Aug 16 20:12:30 CST 2003
45675 >
45676 >
45677 >Thanks
45678 >Marc
45679 >------------------------------------------------------------------
45680 >To unsubscribe or change your subscription options, visit:
45681 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
45682
45683 /******* - End Original Message - *******/
45684
45685
45686
45687
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>
45694
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...
45699
45700 Just an idea... I now await the half dozen people who will proceed to tell
45701 me how stupid my idea is....
45702
45703 Saturn
45704 irc.jetirc.net
45705
45706
45707
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>
45715
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.
45720
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..
45724 >
45725 > /time services.chatspike.net
45726 > [22:28] ??? Date / time at services.chatspike.net- Thu Aug 28 17:28:57
45727 > 2003 EDT
45728 >
45729 > *shock*
45730 >
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 >  ****************************************/
45738 >
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 >  ****************************************/
45745 >
45746 > /****** - Begin Original Message - ******/
45747 >
45748 >>Hi,
45749 >>
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:
45753 >>
45754 >>***************************
45755 >>-
45756 >>-NickServ- nick is hello world
45757 >>-
45758 >>-NickServ- Is online from: ~test@just.a.test.co.za
45759 >>-
45760 >>-NickServ- Last seen time: Aug 28 15:51:14 2003 GMT
45761 >>-
45762 >>-NickServ- Time registered: Aug 28 00:13:35 2003 GMT
45763 >>-
45764 >>-NickServ- Last quit message: anythinggggg
45765 >>-
45766 >>-NickServ- Options: Kill protection, Security
45767 >>-
45768 >>***************************
45769 >>
45770 >>the new line I'm suggesting is something like:
45771 >>
45772 >>***************************
45773 >>-NickServ- Time Now : Aug 28 15:54:04 2003 GMT
45774 >>***************************
45775 >>
45776 >>This will help our users to compare the time that user was last seen and
45777 >> the
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
45781 >> GMT
45782 >>(last seen time was before: 10 days, 3hours and 24 sec ago).
45783 >>
45784 >>Note that I saw both of these features, in other services I don't
45785 >> remember
45786 >>there names (but they aren't as stable as ircservices5) (it was something
45787 >>like ptlink services, and magik II)
45788 >>
45789 >>That's all, I would really like to see it on the next version (or if you
45790 >> can
45791 >>show me how to do it, as I'm not a programmer)
45792 >>
45793 >>Many thanks to all of who developed IRCservices ...etc ...etc ...etc
45794 >>
45795 >>sincerely,
45796 >>David
45797 >>
45798 >>_________________________________________________________________
45799 >>Get MSN 8 and enjoy automatic e-mail virus protection.
45800 >>http://join.msn.com/?page=features/virus
45801 >>
45802 >>------------------------------------------------------------------
45803 >>To unsubscribe or change your subscription options, visit:
45804 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
45805 >
45806 > /******* - End Original Message - *******/
45807 >
45808 >
45809 >
45810 > ------------------------------------------------------------------
45811 > To unsubscribe or change your subscription options, visit:
45812 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
45813 >
45814
45815
45816 --
45817 Best Regards,
45818 playa
45819 Network Founder/CEO
45820 DreamChat IRC Network - irc.dreamchat.org
45821 http://www.dreamchat.org
45822
45823
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>
45830
45831 On Thursday, Aug 28, 2003, at 20:46 US/Pacific, playa wrote:
45832
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.
45837
45838 That's a client thing.  Some clients might alias /time as a CTCP TIME
45839 for a specific user, or similar.
45840
45841 -- Quension
45842
45843
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>
45852
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.
45857
45858 Some clients use stupid aliases for CTCP commands, for example:
45859
45860 /version <nick> = /CTCP <nick> VERSION,
45861 /time <nick> = /CTCP <nick> TIME,
45862 /finger <nick> = /CTCP <nick> TIME
45863
45864 This is why nothing works the way you expected.
45865
45866 --
45867 Krisztian Romek
45868 r-krisztian@softhome.net
45869
45870
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>
45876
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).
45880
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
45884
45885
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>
45891
45892
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.
45898
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
45902
45903
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>
45909
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.
45911
45912 And i'll Quote Elijah:
45913
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
45916 be 'no.'"
45917
45918
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  ****************************************/
45926
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  ****************************************/
45933
45934 /****** - Begin Original Message - ******/
45935
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.
45941 >
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
45945 >
45946 >------------------------------------------------------------------
45947 >To unsubscribe or change your subscription options, visit:
45948 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
45949 >.
45950
45951 /******* - End Original Message - *******/
45952
45953
45954
45955
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>
45961
45962 its a stupid idea!!! :p
45963
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
45965
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  ****************************************/
45973
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  ****************************************/
45980
45981 /****** - Begin Original Message - ******/
45982
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...
45987 >
45988 >Just an idea... I now await the half dozen people who will proceed to tell
45989 >me how stupid my idea is....
45990 >
45991 >Saturn
45992 >irc.jetirc.net
45993 >
45994 >
45995 >------------------------------------------------------------------
45996 >To unsubscribe or change your subscription options, visit:
45997 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
45998
45999 /******* - End Original Message - *******/
46000
46001
46002
46003
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>
46010
46011 Cheers.
46012
46013 -----Original Message-----
46014 From: ircservices-coding-bounces@ircservices.za.net
46015 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of Craig
46016 McLure
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
46020
46021
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
46024 to annoy me.
46025
46026 And i'll Quote Elijah:
46027
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
46030 be 'no.'"
46031
46032
46033
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>
46039
46040 woops, ok sorry I thought the two e-mails is completely different.
46041
46042
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
46050 >
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.
46054 >
46055 >And i'll Quote Elijah:
46056 >
46057 >"Except it's already been said in the FAQ that it's not going to happen,
46058 >and
46059 >if that made it into the FAQ it would seem the answer is frequently going
46060 >to
46061 >be 'no.'"
46062 >
46063 >
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 >  ****************************************/
46071 >
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 >  ****************************************/
46078 >
46079 >/****** - Begin Original Message - ******/
46080 >
46081 > >Since most people want to see this feature(s) in the next version, it
46082 >would
46083 > >be great to implement it as an optional feature , where it can be
46084 >disabled
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
46087 >fact,
46088 > >it will add another nice feature to the features list of IRCservices5.
46089 > >
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
46093 > >
46094 > >------------------------------------------------------------------
46095 > >To unsubscribe or change your subscription options, visit:
46096 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
46097 > >.
46098 >
46099 >/******* - End Original Message - *******/
46100 >
46101 >
46102 >
46103 >------------------------------------------------------------------
46104 >To unsubscribe or change your subscription options, visit:
46105 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
46106
46107 _________________________________________________________________
46108 MSN 8: Get 6 months for $9.95/month. http://join.msn.com/?page=dept/dialup
46109
46110
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>
46117
46118 Hi
46119 I run ircservices 5.0.21 on FreeBSD 4.8-STABLE. and Ultimate 3.*
46120 I get this in logfile:
46121
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)
46134
46135 and how can I do so that nickserv dont show the realhost of a user in
46136 'ns info nick all'
46137
46138
46139 thanks for help
46140
46141                            Ali "Simorgh"
46142  ______________________________________________________
46143  Many of life's failures are people who did not realize
46144  how close they were to success when they gave up.
46145  Thomas A. Edison
46146  ______________________________________________________
46147
46148
46149
46150
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>
46157
46158 "and how can I do so that nickserv dont show the realhost of a user in
46159 'ns info nick all'"
46160
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
46164 option is set.
46165
46166
46167
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>
46174
46175      Use E-mail if you need communication of that sort.
46176
46177   --Andrew Church
46178     achurch@achurch.org
46179     http://achurch.org/
46180
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
46185 >have been denied.
46186 >
46187 >/chanserv MARK <channel> <reason>
46188 >
46189 >/chanserv info #channel would read the following.
46190 >*#channel has been MARKED by playa - <reason>
46191 >
46192 >Of course only IRCops would be able to view it.
46193 >
46194 >Just an idea i thought of :)
46195 >
46196 >--
46197 >Best Regards,
46198 >playa
46199 >Network Founder/CEO
46200 >DreamChat IRC Network - irc.dreamchat.org
46201 >http://www.dreamchat.org
46202 >
46203 >------------------------------------------------------------------
46204 >To unsubscribe or change your subscription options, visit:
46205 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
46206
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>
46213
46214      Needless complexity.  If you don't want yourself autoopped, then don't
46215 be an auto-op.  It's that simple.
46216
46217   --Andrew Church
46218     achurch@achurch.org
46219     http://achurch.org/
46220
46221 >Hi again
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.
46224 >
46225 >Like:
46226 > SET NOAUTO ON|OFF
46227 >  When NOAUTO is on, ChanServ will not
46228 >  automatically op or voice you in any channels.
46229 >
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.
46232 >
46233 >Or did I miss it?
46234 >
46235 >Thanks
46236 >
46237 >                           Ali "Simorgh"
46238 > ______________________________________________________
46239 > Many of life's failures are people who did not realize
46240 > how close they were to success when they gave up.
46241 > Thomas A. Edison
46242 > ______________________________________________________
46243 >
46244 >
46245 >On Sun, 17 Aug 2003, Russell Garrett wrote:
46246 >
46247 >> Eh? This has been implemented since IRCServices 5a31.
46248 >>
46249 >> Russ
46250 >>
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)
46255 >> >
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
46258 >> > channels.
46259 >> >
46260 >> > Thanks for any help
46261 >>
46262 >> ------------------------------------------------------------------
46263 >> To unsubscribe or change your subscription options, visit:
46264 >> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
46265 >>
46266 >
46267 >------------------------------------------------------------------
46268 >To unsubscribe or change your subscription options, visit:
46269 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
46270
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>
46278
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.
46282
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
46291 is not complex.
46292
46293 Shaun
46294
46295
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>
46301
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..
46304
46305 or /cs levels #channels DISABLE autoop
46306
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  ****************************************/
46314
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  ****************************************/
46321
46322 /****** - Begin Original Message - ******/
46323
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.
46327 >
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
46336 >is not complex.
46337 >
46338 >Shaun
46339 >
46340 >------------------------------------------------------------------
46341 >To unsubscribe or change your subscription options, visit:
46342 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
46343 >.
46344
46345 /******* - End Original Message - *******/
46346
46347
46348
46349
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>
46357
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..
46360
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.
46363
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
46366
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
46373
46374 Same with ENFORCE set to off as well.
46375
46376 > [snipped obnoxiously long sig]
46377
46378 Shaun Guth
46379
46380
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>
46387
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
46390 >
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
46397
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.
46401
46402   --Andrew Church
46403     achurch@achurch.org
46404     http://achurch.org/
46405
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>
46412
46413 >Can we reconsider adding a Mass memo function for the next release?
46414
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.
46422
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.
46428
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.
46433
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.
46436
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........
46443
46444      This is an interesting thought; I'll think about it for a future
46445 version.
46446
46447   --Andrew Church
46448     achurch@achurch.org
46449     http://achurch.org/
46450
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>
46457
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?
46463
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.
46468
46469   --Andrew Church
46470     achurch@achurch.org
46471     http://achurch.org/
46472
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>
46479
46480 >Is there any tool (silly question) or something or guid to make a language
46481 >file.
46482 >
46483 >I have decided to make a Persian (Farsi) language file.
46484
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.
46489
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.
46492
46493   --Andrew Church
46494     achurch@achurch.org
46495     http://achurch.org/
46496
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>
46503
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
46507
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?
46510
46511   --Andrew Church
46512     achurch@achurch.org
46513     http://achurch.org/
46514
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>
46521
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.
46525
46526      This is a bug in the DROP function, and has been fixed; thanks for the
46527 report.
46528
46529   --Andrew Church
46530     achurch@achurch.org
46531     http://achurch.org/
46532
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>
46539
46540 >[Aug 30 10:56:18 2003] mail/sendmail:
46541 > /usr/sbin/sendmail exited with code 25600
46542
46543      Use the SMTP module instead (mail/smtp).
46544
46545 >[Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
46546 >registration (Simorgh)
46547 >
46548 >and how can I do so that nickserv dont show the realhost of a user in
46549 >'ns info nick all'
46550
46551      It doesn't.  However:
46552
46553 >[Aug 30 10:51:19 2003] unknown message from server
46554 >(:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
46555
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.
46559
46560   --Andrew Church
46561     achurch@achurch.org
46562     http://achurch.org/
46563
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>
46570
46571 >Or how about rather letting users decide what timezone they're in and
46572 >services outputs all timestamps in their local time?
46573
46574 /ns help set timezone (since 5.0 alpha)
46575
46576   --Andrew Church
46577     achurch@achurch.org
46578     http://achurch.org/
46579
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>
46587
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.
46595
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?
46603
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....
46610
46611 Saturn
46612 irc.jetirc.net
46613
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
46619
46620
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...
46623
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.
46627
46628   --Andrew Church
46629     achurch@achurch.org
46630     http://achurch.org/
46631
46632
46633
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>
46642
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.
46652
46653 Erm, what's the argument here?  Services stipulates its timezone in its
46654 timestamps.  As do all the other servers on the network.
46655
46656 Atleast mine do...
46657
46658
46659 Regards,
46660 Aragon
46661
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>
46670
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??
46675
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
46681 suggestion
46682
46683
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
46687 server
46688 > is in a different time zone -- How are users supposed to know what time
46689 zone
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.
46695
46696 Erm, what's the argument here?  Services stipulates its timezone in its
46697 timestamps.  As do all the other servers on the network.
46698
46699 Atleast mine do...
46700
46701
46702 Regards,
46703 Aragon
46704 ------------------------------------------------------------------
46705 To unsubscribe or change your subscription options, visit:
46706 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
46707
46708
46709
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>
46717
46718 On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
46719
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?
46724
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
46728 it back.
46729
46730 >   Why does it all have to be so complicated??
46731
46732 It isn't.  Your users can even use the handy-dandy /nickserv set
46733 timezone command to make it even easier.
46734
46735 > ----- Original Message -----
46736 > From: "Aragon Gouveia" <aragon@phat.za.net>
46737
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.
46748 >
46749 > Erm, what's the argument here?  Services stipulates its timezone in
46750 > its timestamps.  As do all the other servers on the network.
46751
46752 -- Quension
46753
46754
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>
46761
46762
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
46765 seconds ago)
46766 Time registered  : Jul 25 22:19:20 2003 GMT (** days, ** minutes and **
46767 seconds ago)
46768 wouldn't even a greater idea?
46769
46770 _________________________________________________________________
46771 Get MSN 8 and enjoy automatic e-mail virus protection.
46772 http://join.msn.com/?page=features/virus
46773
46774
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>
46782
46783 [16:41] -NickServ-   Time registered: Jul 27 13:09:08 2002 PDT
46784
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....
46793
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
46796 valid ones...
46797
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
46800 codes like PDT)...
46801
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
46808 suggestion
46809
46810
46811 On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
46812
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?
46817
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
46821 it back.
46822
46823 >   Why does it all have to be so complicated??
46824
46825 It isn't.  Your users can even use the handy-dandy /nickserv set
46826 timezone command to make it even easier.
46827
46828 > ----- Original Message -----
46829 > From: "Aragon Gouveia" <aragon@phat.za.net>
46830
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.
46841 >
46842 > Erm, what's the argument here?  Services stipulates its timezone in
46843 > its timestamps.  As do all the other servers on the network.
46844
46845 -- Quension
46846
46847 ------------------------------------------------------------------
46848 To unsubscribe or change your subscription options, visit:
46849 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
46850
46851
46852
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>
46860
46861 On Sunday, Aug 31, 2003, at 16:47 US/Pacific, Saturn wrote:
46862
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)...
46866
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.
46870
46871 -- Quension
46872
46873
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>
46881
46882      "Use /ns set timezone" is the official answer on this.  Please take
46883 all further discussion to the ircservices list.
46884
46885   --Andrew Church
46886     achurch@achurch.org
46887     http://achurch.org/
46888
46889 >[16:41] -NickServ-   Time registered: Jul 27 13:09:08 2002 PDT
46890 >
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....
46899 >
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
46902 >valid ones...
46903 >
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)...
46907 >
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
46914 >suggestion
46915 >
46916 >
46917 >On Sunday, Aug 31, 2003, at 13:47 US/Pacific, Saturn wrote:
46918 >
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?
46923 >
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
46927 >it back.
46928 >
46929 >>   Why does it all have to be so complicated??
46930 >
46931 >It isn't.  Your users can even use the handy-dandy /nickserv set
46932 >timezone command to make it even easier.
46933 >
46934 >> ----- Original Message -----
46935 >> From: "Aragon Gouveia" <aragon@phat.za.net>
46936 >
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.
46947 >>
46948 >> Erm, what's the argument here?  Services stipulates its timezone in
46949 >> its timestamps.  As do all the other servers on the network.
46950 >
46951 >-- Quension
46952 >
46953 >------------------------------------------------------------------
46954 >To unsubscribe or change your subscription options, visit:
46955 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
46956 >
46957 >
46958 >------------------------------------------------------------------
46959 >To unsubscribe or change your subscription options, visit:
46960 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
46961
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>
46968
46969 Thanks for your help.
46970
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
46975            Is online from: %s
46976 to:
46977 NICK_INFO_ADDRESS_ONLINE
46978            Is online from: N/A ?
46979
46980
46981                            Ali "Simorgh"
46982  ______________________________________________________
46983  Many of life's failures are people who did not realize
46984  how close they were to success when they gave up.
46985  Thomas A. Edison
46986  ______________________________________________________
46987
46988
46989 On Mon, 1 Sep 2003, Andrew Church wrote:
46990
46991 > >[Aug 30 10:56:18 2003] mail/sendmail:
46992 > > /usr/sbin/sendmail exited with code 25600
46993 >
46994 >      Use the SMTP module instead (mail/smtp).
46995 >
46996 > >[Aug 30 10:56:18 2003] nickserv/mail-auth: send_auth() failed for
46997 > >registration (Simorgh)
46998 > >
46999 > >and how can I do so that nickserv dont show the realhost of a user in
47000 > >'ns info nick all'
47001 >
47002 >      It doesn't.  However:
47003 >
47004 > >[Aug 30 10:51:19 2003] unknown message from server
47005 > >(:irc.MyNet.Net SETHOST Simorgh MyvhostNetwork.Net)
47006 >
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.
47010 >
47011 >   --Andrew Church
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
47017 >
47018
47019
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>
47026
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
47029
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.
47034
47035   --Andrew Church
47036     achurch@achurch.org
47037     http://achurch.org/
47038
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>
47044
47045 Hi all,
47046
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.
47050
47051 Regards
47052
47053 alex
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>
47064
47065 Hello,
47066
47067 alex wrote:
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.
47071
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
47075 computer.
47076
47077 --
47078 Krisztian Romek
47079 r-krisztian@softhome.net
47080
47081
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>
47087
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.
47089
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.
47091
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  ****************************************/
47099
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  ****************************************/
47106
47107 /****** - Begin Original Message - ******/
47108
47109 >Hi all,
47110 >
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.
47114 >
47115 >Regards
47116 >
47117 >alex
47118 >------------------------------------------------------------------
47119 >To unsubscribe or change your subscription options, visit:
47120 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
47121
47122 /******* - End Original Message - *******/
47123
47124
47125
47126
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>
47132
47133 It wasn't an easy subject to sum up in just a few words.
47134
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
47147 send.c
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
47151 all the
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)
47163
47164 Thanks
47165
47166 Brent
47167
47168
47169
47170 ----------------------------------------------------------
47171 |               Brent DiNicola                                  |
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 -----------------------------------------------------------
47178
47179
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>
47185
47186 lol, Our help no good? :P
47187
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..
47189
47190 Dont ask me for source on this.. i'm just theorising :)
47191
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  ****************************************/
47199
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  ****************************************/
47206
47207 /****** - Begin Original Message - ******/
47208
47209 >It wasn't an easy subject to sum up in just a few words.
47210 >
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
47223 >send.c
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
47227 >all the
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)
47239 >
47240 >Thanks
47241 >
47242 >Brent
47243 >
47244 >
47245 >
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 >-----------------------------------------------------------
47254 >
47255 >------------------------------------------------------------------
47256 >To unsubscribe or change your subscription options, visit:
47257 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
47258 >.
47259
47260 /******* - End Original Message - *******/
47261
47262
47263
47264
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>
47272
47273 Hello;
47274
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.
47284
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.
47299 ...
47300
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.
47304
47305 To your case.
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.
47309
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
47312 trivial.
47313
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
47317 closed.
47318
47319 Do keep in mind that requesting support for modified services versions
47320 are subject to be ignored.
47321
47322 I hope it helps,
47323 yusuf
47324
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.
47327 >
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
47340 > send.c
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
47344 > all the
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)
47356 >
47357 > Thanks
47358 >
47359 > Brent
47360 >
47361 >
47362 >
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 > -----------------------------------------------------------
47371 >
47372 > ------------------------------------------------------------------
47373 > To unsubscribe or change your subscription options, visit:
47374 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
47375 --
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 ------------------------------------------------------------------
47382
47383
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>
47390
47391 Brent DiNicola wrote:
47392
47393 > It wasn't an easy subject to sum up in just a few words.
47394 >
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
47400 > the users
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
47403 > NOTICE
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
47406 > the best
47407 > way to go about this without causing trouble for me and anyone else
47408 > who has
47409 > to deal with this code. Is it possible or even suggested to make a
47410 > module that
47411 > would replace the notice() from send.c with it's own, leaving the code
47412 > in send.c
47413 > alone and not causing troubles down the road. Suggestions were that I
47414 > make a
47415 > module that kept the info for each nick's setting and then if I could
47416 > override
47417 > the notice() and notice_lang() and notice_help() in send.c that would
47418 > keep all the
47419 > other code clean and not cause other troubles. I want to know what the
47420 > best
47421 > way to do this would be, I know it's against RFC but I want to move to
47422 > newer
47423 > services than the 1.4.3pre4 that we are using now and add modules so
47424 > that I
47425 > can do things down the line. They are used to having PRIVMSG and I
47426 > can't just
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
47429 > this? I
47430 > know this topic has been asked before and I know your not going to
47431 > make it
47432 > part of your code, I just wanted to know from the people who know the
47433 > code
47434 > really well what the best route to take would be to do the least
47435 > amount of
47436 > damage. (And if someone has done this.. please let me know what you did,
47437 > examples would rock)
47438 >
47439 > Thanks
47440 >
47441 > Brent
47442 >
47443 >
47444 >
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
47456 >
47457 >
47458
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
47463
47464 services is the wrong thing to change
47465
47466
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>
47472
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
47474
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  ****************************************/
47482
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  ****************************************/
47489
47490 /****** - Begin Original Message - ******/
47491
47492 >Brent DiNicola wrote:
47493 >
47494 >> It wasn't an easy subject to sum up in just a few words.
47495 >>
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
47501 >> the users
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
47504 >> NOTICE
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
47507 >> the best
47508 >> way to go about this without causing trouble for me and anyone else
47509 >> who has
47510 >> to deal with this code. Is it possible or even suggested to make a
47511 >> module that
47512 >> would replace the notice() from send.c with it's own, leaving the code
47513 >> in send.c
47514 >> alone and not causing troubles down the road. Suggestions were that I
47515 >> make a
47516 >> module that kept the info for each nick's setting and then if I could
47517 >> override
47518 >> the notice() and notice_lang() and notice_help() in send.c that would
47519 >> keep all the
47520 >> other code clean and not cause other troubles. I want to know what the
47521 >> best
47522 >> way to do this would be, I know it's against RFC but I want to move to
47523 >> newer
47524 >> services than the 1.4.3pre4 that we are using now and add modules so
47525 >> that I
47526 >> can do things down the line. They are used to having PRIVMSG and I
47527 >> can't just
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
47530 >> this? I
47531 >> know this topic has been asked before and I know your not going to
47532 >> make it
47533 >> part of your code, I just wanted to know from the people who know the
47534 >> code
47535 >> really well what the best route to take would be to do the least
47536 >> amount of
47537 >> damage. (And if someone has done this.. please let me know what you did,
47538 >> examples would rock)
47539 >>
47540 >> Thanks
47541 >>
47542 >> Brent
47543 >>
47544 >>
47545 >>
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
47557 >>
47558 >>
47559 >
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
47564 >
47565 >services is the wrong thing to change
47566 >
47567 >------------------------------------------------------------------
47568 >To unsubscribe or change your subscription options, visit:
47569 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
47570 >.
47571
47572 /******* - End Original Message - *******/
47573
47574
47575
47576
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>
47583
47584 On Thursday, Sep 4, 2003, at 13:29 US/Pacific, Robert F Merrill wrote:
47585
47586 > Brent DiNicola wrote:
47587 >
47588 >> It wasn't an easy subject to sum up in just a few words.
47589
47590 [...]
47591
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
47596 >
47597 > services is the wrong thing to change
47598
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.
47602
47603 This is the coding list, not the feature request list.  He asked for
47604 code design approaches, not for political insight.
47605
47606 -- Quension
47607
47608
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>
47614
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
47620
47621 Thanks for all
47622
47623 Diego B. Contezini
47624
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..
47630
47631
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
47637 get
47638 > a core.
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
47641 break
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.
47646 >
47647 > Thanks for all
47648 >
47649 > Diego B. Contezini aka destruct_ | irc.redesul.net
47650 > (Sorry for my confuse english.)
47651 >
47652
47653
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>
47660
47661 Hello, im destruct_, im the administrator of the RedeSul Network.
47662 (irc.redesul.net).
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
47666 a core.
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.
47673
47674 Thanks for all
47675
47676 Diego B. Contezini aka destruct_ | irc.redesul.net
47677 (Sorry for my confuse english.)
47678
47679
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>
47685
47686 Hi All
47687
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
47699
47700 many thanks
47701 Engin
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>
47710
47711 make sure you are on the services administrator list, if you are not, get the root administrator to add you using the command:
47712
47713 [22:27] -OperServ- Syntax: ADMIN ADD nickname
47714 [22:27] -OperServ- ADMIN DEL nickname
47715 [22:27] -OperServ- ADMIN LIST
47716 [22:27] -OperServ-
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.
47721 [22:27] -OperServ-
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.
47724
47725
47726
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  ****************************************/
47734
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  ****************************************/
47741
47742 /****** - Begin Original Message - ******/
47743
47744 >Hi All
47745 >
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
47757 >
47758 >many thanks
47759 >Engin
47760 >------------------------------------------------------------------
47761 >To unsubscribe or change your subscription options, visit:
47762 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
47763
47764 /******* - End Original Message - *******/
47765
47766
47767
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>
47774
47775 Contact me directly... I have quite a bit of experience with unreal and these services...
47776
47777 Saturn
47778 irc.jetirc.net
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
47784
47785
47786   Hi All
47787
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
47799
47800   many thanks
47801   Engin
47802
47803
47804
47805 ------------------------------------------------------------------------------
47806
47807
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>
47820
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....
47823
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
47830
47831
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:
47834
47835 [22:27] -OperServ- Syntax: ADMIN ADD nickname
47836 [22:27] -OperServ- ADMIN DEL nickname
47837 [22:27] -OperServ- ADMIN LIST
47838 [22:27] -OperServ-
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.
47843 [22:27] -OperServ-
47844 [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
47845 command.
47846 [22:27] -OperServ- All other use limited to Services super-user.
47847
47848
47849
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  ****************************************/
47857
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  ****************************************/
47864
47865 /****** - Begin Original Message - ******/
47866
47867 >Hi All
47868 >
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
47880 >
47881 >many thanks
47882 >Engin
47883 >------------------------------------------------------------------
47884 >To unsubscribe or change your subscription options, visit:
47885 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
47886
47887 /******* - End Original Message - *******/
47888
47889
47890 ------------------------------------------------------------------
47891 To unsubscribe or change your subscription options, visit:
47892 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
47893
47894
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>
47901
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
47904 one
47905
47906 cheers
47907 Engin
47908
47909
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
47915
47916
47917 > Send IRCServices-Coding mailing list submissions to
47918 > ircservices-coding@ircservices.za.net
47919 >
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
47924 >
47925 > You can reach the person managing the list at
47926 > ircservices-coding-owner@ircservices.za.net
47927 >
47928 > When replying, please edit your Subject line so it is more specific
47929 > than "Re: Contents of IRCServices-Coding digest..."
47930 >
47931 >
47932 > Today's Topics:
47933 >
47934 >    1. operserv (engin@piratetv)
47935 >    2. Re: operserv (Craig McLure)
47936 >    3. Re: operserv (Saturn)
47937 >    4. Re: operserv (Saturn)
47938 >
47939 >
47940 > ----------------------------------------------------------------------
47941 >
47942 > Message: 1
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"
47949 >
47950 > Hi All
47951 >
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
47963 >
47964 > many thanks
47965 > Engin
47966 > -------------- next part --------------
47967 > An HTML attachment was scrubbed...
47968 > URL:
47969 http://snow.fingers.co.za/pipermail/ircservices-coding/attachments/20030921/
47970 fdc12b4e/attachment-0001.htm
47971 >
47972 > ------------------------------
47973 >
47974 > Message: 2
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"
47982 >
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:
47985 >
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
47991 nicknames
47992 > [22:27] -OperServ- to or from the Services admin list. A user whose
47993 nickname
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
47996 commands.
47997 > [22:27] -OperServ-
47998 > [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
47999 command.
48000 > [22:27] -OperServ- All other use limited to Services super-user.
48001 >
48002 >
48003 >
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 >  ****************************************/
48011 >
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 >  ****************************************/
48018 >
48019 > /****** - Begin Original Message - ******/
48020 >
48021 > >Hi All
48022 > >
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
48034 > >
48035 > >many thanks
48036 > >Engin
48037 > >------------------------------------------------------------------
48038 > >To unsubscribe or change your subscription options, visit:
48039 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
48040 >
48041 > /******* - End Original Message - *******/
48042 >
48043 >
48044 >
48045 > ------------------------------
48046 >
48047 > Message: 3
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"
48055 >
48056 > Contact me directly... I have quite a bit of experience with unreal and
48057 these services...
48058 >
48059 > Saturn
48060 > irc.jetirc.net
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
48066 >
48067 >
48068 >   Hi All
48069 >
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
48072 mailing
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
48082 >
48083 >   many thanks
48084 >   Engin
48085 >
48086 >
48087 >
48088 > --------------------------------------------------------------------------
48089 ----
48090 >
48091 >
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...
48097 > URL:
48098 http://snow.fingers.co.za/pipermail/ircservices-coding/attachments/20030921/
48099 ca188e06/attachment-0001.htm
48100 >
48101 > ------------------------------
48102 >
48103 > Message: 4
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"
48111 >
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
48114 denied....
48115 >
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
48122 >
48123 >
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:
48126 >
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
48132 nicknames
48133 > [22:27] -OperServ- to or from the Services admin list. A user whose
48134 nickname
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
48137 commands.
48138 > [22:27] -OperServ-
48139 > [22:27] -OperServ- Any IRC operator may use the ADMIN LIST form of the
48140 > command.
48141 > [22:27] -OperServ- All other use limited to Services super-user.
48142 >
48143 >
48144 >
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 >  ****************************************/
48152 >
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 >  ****************************************/
48159 >
48160 > /****** - Begin Original Message - ******/
48161 >
48162 > >Hi All
48163 > >
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
48175 > >
48176 > >many thanks
48177 > >Engin
48178 > >------------------------------------------------------------------
48179 > >To unsubscribe or change your subscription options, visit:
48180 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
48181 >
48182 > /******* - End Original Message - *******/
48183 >
48184 >
48185 > ------------------------------------------------------------------
48186 > To unsubscribe or change your subscription options, visit:
48187 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
48188 >
48189 >
48190 > ------------------------------
48191 >
48192 > _______________________________________________
48193 > IRCServices-Coding mailing list
48194 > IRCServices-Coding@ircservices.za.net
48195 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
48196 >
48197 >
48198 > End of IRCServices-Coding Digest, Vol 8, Issue 5
48199 > ************************************************
48200
48201
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>
48209
48210 Sometimes has occur this bug, last 1 year....
48211 on a network with 30k registers, its happening with latency of 3.. 4
48212 days....
48213
48214 someone have any idea?
48215
48216 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
48217 av=0xbfffeec8) at channels.c:278
48218 278         while (*s) {
48219 (gdb) bt'
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>
48224         add = 1
48225         modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
48226 #1  0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:680
48227         buf =
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
48239 bounds>,
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@`???"}
48243         len = 4
48244         i = 0
48245         lastc = 45 '-'
48246 #2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
48247         args = 0x0
48248         modes = 0x0
48249         modes_orig = 0x0
48250         md = (struct modedata *) 0x0
48251         which = -1
48252         add = 0
48253         i = 0
48254         c = 0 '\0'
48255 #3  0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at main.c:269
48256         now = 1065393142
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.
48262 (gdb)
48263
48264
48265
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>
48272
48273 Upgrade.
48274
48275   --Andrew Church
48276     achurch@achurch.org
48277     http://achurch.org/
48278
48279 >Sometimes has occur this bug, last 1 year....
48280 >on a network with 30k registers, its happening with latency of 3.. 4
48281 >days....
48282 >
48283 >someone have any idea?
48284 >
48285 >#0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
48286 >av=0xbfffeec8) at channels.c:278
48287 >278         while (*s) {
48288 >(gdb) bt'
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>
48293 >        add = 1
48294 >        modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
48295 >#1  0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:68
48296 >0
48297 >        buf =
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ï¿½ï¿½ï¿½ï¿
48301 >½
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\
48306 >000\000\0
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�
48312 >���\027\000\0
48313 >00\000\000\000\000\000\024\032"...
48314 >        s = 0xbfffeef0 "-isl"
48315 >        argv = {0xa97b6c0 "#young", 0x20656c62 <Address 0x20656c62 out
48316 >of
48317 >bounds>,
48318 >  0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 o
48319 >ut
48320 >of bounds>, 0x42133cec "\004", 0xbffff1fc "",
48321 >  0x4204533d "\201���\016", 0x42131a14 " \031\023
48322 >B�h\001@`�"}
48323 >        len = 4
48324 >        i = 0
48325 >        lastc = 45 '-'
48326 >#2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:32
48327 >1
48328 >        args = 0x0
48329 >        modes = 0x0
48330 >        modes_orig = 0x0
48331 >        md = (struct modedata *) 0x0
48332 >        which = -1
48333 >        add = 0
48334 >        i = 0
48335 >        c = 0 '\0'
48336 >#3  0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at ma
48337 >in.c:269
48338 >        now = 1065393142
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.
48344 >(gdb)
48345 >
48346 >
48347 >------------------------------------------------------------------
48348 >To unsubscribe or change your subscription options, visit:
48349 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
48350
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>
48357
48358 Upgrade?
48359 ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
48360 18:41:36 BRT 2003
48361 -
48362
48363 Its the last version.......
48364
48365 Diego B. Contezini
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....
48371
48372
48373 > Upgrade.
48374 >
48375 >   --Andrew Church
48376 >     achurch@achurch.org
48377 >     http://achurch.org/
48378 >
48379 > >Sometimes has occur this bug, last 1 year....
48380 > >on a network with 30k registers, its happening with latency of 3.. 4
48381 > >days....
48382 > >
48383 > >someone have any idea?
48384 > >
48385 > >#0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
48386 > >av=0xbfffeec8) at channels.c:278
48387 > >278         while (*s) {
48388 > >(gdb) bt'
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>
48393 > >        add = 1
48394 > >        modestr = 0x20656c62 <Address 0x20656c62 out of bounds>
48395 > >#1  0x0804dc8e in flush_cmode (md=0x806aa00, clear=1) at actions.c:68
48396 > >0
48397 > >        buf =
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???????????
48401 > >?
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\
48406 > >000\000\0
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
48416 > >of
48417 > >bounds>,
48418 > >  0x292a6f3a <Address 0x292a6f3a out of bounds>, 0x5d20 <Address 0x5d20 o
48419 > >ut
48420 > >of bounds>, 0x42133cec "\004", 0xbffff1fc "",
48421 > >  0x4204533d "\201?????????\016", 0x42131a14 " \031\023
48422 > >B???h\001@`???"}
48423 > >        len = 4
48424 > >        i = 0
48425 > >        lastc = 45 '-'
48426 > >#2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:32
48427 > >1
48428 > >        args = 0x0
48429 > >        modes = 0x0
48430 > >        modes_orig = 0x0
48431 > >        md = (struct modedata *) 0x0
48432 > >        which = -1
48433 > >        add = 0
48434 > >        i = 0
48435 > >        c = 0 '\0'
48436 > >#3  0x080553a3 in main (ac=1, av=0xbffff804, envp=0xbffff80c) at ma
48437 > >in.c:269
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.
48444 > >(gdb)
48445 > >
48446 > >
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
48453 >
48454
48455
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>
48462
48463 >Upgrade?
48464 >ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
48465 >18:41:36 BRT 2003
48466 >-
48467 >
48468 >Its the last version.......
48469
48470      Then send a full debug log (from startup to crash), or I can't help.
48471
48472   --Andrew Church
48473     achurch@achurch.org
48474     http://achurch.org/
48475
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>
48482
48483 And how should be this log? i sent a backtrace......
48484
48485 Diego B. Contezini
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....
48491
48492
48493 > >Upgrade?
48494 > >ircservices-5.0.22 services.redesul.net build #2, compiled Thu Sep 18
48495 > >18:41:36 BRT 2003
48496 > >-
48497 > >
48498 > >Its the last version.......
48499 >
48500 >      Then send a full debug log (from startup to crash), or I can't help.
48501 >
48502 >   --Andrew Church
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
48508 >
48509
48510
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>
48517
48518 >And how should be this log? i sent a backtrace......
48519
48520 RTFM (FAQ Z.3)
48521
48522   --Andrew Church
48523     achurch@achurch.org
48524     http://achurch.org/
48525
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>
48532
48533 Read....
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
48536 nofork.....
48537
48538 Cya
48539 Diego B. Contezini
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....
48545
48546
48547 > >And how should be this log? i sent a backtrace......
48548 >
48549 > RTFM (FAQ Z.3)
48550 >
48551 >   --Andrew Church
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
48557 >
48558
48559
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>
48566
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).
48569
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...
48576
48577 First: IS that what it's supposed to do?
48578
48579 Second: If so, it's not working...
48580
48581 Saturn
48582 www.jetirc.net
48583
48584
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>
48591
48592
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.
48596
48597 I copy the sintaz of mail-auth ( it's in italian )
48598
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:
48607             /msg %s AUTH %09d
48608
48609         La registrazione del tuo nick sara' confermata e il tuo nickname
48610         sara' protetto da eventuali tentativi di abuso o furto.
48611
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.
48615
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.
48619
48620
48621         Sono inoltre disponibili i seguenti servizi:
48622
48623         - MusiChat Forum
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.
48629
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.
48635
48636
48637         Per una connessione piu' veloce e sicura e' vivamente
48638         consigliato l'utilizzo del seguente server: irc.musichat.net
48639
48640         MusiChat Net Community
48641
48642         Questo messaggio e stato inviato su richiesta di %s in risposta a %s
48643         %s@%s.
48644
48645
48646
48647
48648 I read the istruction for translate.
48649
48650 The error is:
48651
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
48655
48656
48657 Some one can help me?
48658 the email body is too long?
48659
48660 Thx
48661
48662 Alex
48663
48664
48665
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>
48672
48673      You have the wrong number of %-tokens in your message.
48674
48675   --Andrew Church
48676     achurch@achurch.org
48677     http://achurch.org/
48678
48679 >
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.
48683 >
48684 >I copy the sintaz of mail-auth ( it's in italian )
48685 >
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
48695 >
48696 >        La registrazione del tuo nick sara' confermata e il tuo nickname
48697 >        sara' protetto da eventuali tentativi di abuso o furto.
48698 >
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.
48702 >
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.
48706 >
48707 >
48708 >        Sono inoltre disponibili i seguenti servizi:
48709 >
48710 >        - MusiChat Forum
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.
48716 >
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.
48722 >
48723 >
48724 >        Per una connessione piu' veloce e sicura e' vivamente
48725 >        consigliato l'utilizzo del seguente server: irc.musichat.net
48726 >
48727 >        MusiChat Net Community
48728 >
48729 >        Questo messaggio e stato inviato su richiesta di %s in risposta a %s
48730 >        %s@%s.
48731 >
48732 >
48733 >
48734 >
48735 >I read the istruction for translate.
48736 >
48737 >The error is:
48738 >
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
48742 >
48743 >
48744 >Some one can help me?
48745 >the email body is too long?
48746 >
48747 >Thx
48748 >
48749 >Alex
48750 >
48751 >
48752 >------------------------------------------------------------------
48753 >To unsubscribe or change your subscription options, visit:
48754 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
48755
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>
48761
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 ?
48770
48771 ######################################################
48772 modules/chanserv/check.c
48773 ...
48774 void check_chan_user_modes(const char *source, struct c_userlist *u,
48775                            Channel *c, int32 oldmodes)
48776 ...
48777         if ((res & ~modes) & CUMODE_o) {
48778             ci->last_used = time(NULL);
48779             put_channelinfo(ci);
48780         }
48781 ...
48782 ######################################################
48783
48784 |SaMaN|
48785
48786
48787
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>
48793
48794 Also it does not update last_used time on +a flag.
48795
48796 Temporary fix
48797 ---------------
48798
48799 edit /modules/chanserv/check.c
48800
48801 find line
48802 -------------------------------------------------------------------------
48803         local_set_cumodes(c, '+', res & ~modes, user->nick);
48804 -------------------------------------------------------------------------
48805 add below
48806 ------------------------------------------------------------------------
48807         int16 cumode_q = mode_char_to_flag('q',MODE_CHANUSER);
48808         int16 cumode_a = mode_char_to_flag('a',MODE_CHANUSER);
48809
48810         if ((res & ~modes) & cumode_q) {
48811             ci->last_used = time(NULL);
48812             put_channelinfo(ci);
48813         }
48814
48815         if ((res & ~modes) & cumode_a) {
48816             ci->last_used = time(NULL);
48817             put_channelinfo(ci);
48818         }
48819 -------------------------------------------------------------------------
48820 save and compile and run and enjoy :)
48821 -------------------------------------------------------------------------
48822
48823 |SaMaN|
48824
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 ?
48830
48831
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
48836 mode:
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
48839 to
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 ?
48842 >
48843 > ######################################################
48844 > modules/chanserv/check.c
48845 > ...
48846 > void check_chan_user_modes(const char *source, struct c_userlist *u,
48847 >                            Channel *c, int32 oldmodes)
48848 > ...
48849 >         if ((res & ~modes) & CUMODE_o) {
48850 >             ci->last_used = time(NULL);
48851 >             put_channelinfo(ci);
48852 >         }
48853 > ...
48854 > ######################################################
48855 >
48856 > |SaMaN|
48857 >
48858 >
48859
48860
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>
48866
48867 Haven't seen a reply to this one, so thought I'd better make sure this went
48868 through....
48869
48870 ----- Original Message -----
48871 Sent: Friday, October 10, 2003 3:48 PM
48872 Subject: Akill problem in 5.0.22
48873
48874
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).
48877
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...
48884
48885 First: IS that what it's supposed to do?
48886
48887 Second: If so, it's not working...
48888
48889 Saturn
48890 www.jetirc.net
48891
48892
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>
48899
48900 RTFM
48901
48902   --Andrew Church
48903     achurch@achurch.org
48904     http://achurch.org/
48905
48906 >Haven't seen a reply to this one, so thought I'd better make sure this went
48907 >through....
48908 >
48909 >----- Original Message -----
48910 >Sent: Friday, October 10, 2003 3:48 PM
48911 >Subject: Akill problem in 5.0.22
48912 >
48913 >
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).
48916 >
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...
48923 >
48924 >First: IS that what it's supposed to do?
48925 >
48926 >Second: If so, it's not working...
48927 >
48928 >Saturn
48929 >www.jetirc.net
48930 >
48931 >------------------------------------------------------------------
48932 >To unsubscribe or change your subscription options, visit:
48933 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
48934
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>
48941
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
48944
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
48948 it first.
48949     Example: ImmediatelySendAutokill
48950
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
48956 kill them.
48957
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?
48962
48963 Thanks
48964 Saturn
48965
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
48971
48972
48973 RTFM
48974
48975   --Andrew Church
48976     achurch@achurch.org
48977     http://achurch.org/
48978
48979 >Haven't seen a reply to this one, so thought I'd better make sure this went
48980 >through....
48981 >
48982 >----- Original Message -----
48983 >Sent: Friday, October 10, 2003 3:48 PM
48984 >Subject: Akill problem in 5.0.22
48985 >
48986 >
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).
48989 >
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
48992 scanning
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...
48997 >
48998 >First: IS that what it's supposed to do?
48999 >
49000 >Second: If so, it's not working...
49001 >
49002 >Saturn
49003 >www.jetirc.net
49004 >
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
49011
49012
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>
49019
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
49024 >kill them.
49025
49026      The documentation says nothing about this.  RTFM again.
49027
49028   --Andrew Church
49029     achurch@achurch.org
49030     http://achurch.org/
49031
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>
49039
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
49045 to deal with it.
49046
49047 Ballsy
49048
49049
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
49053 >
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
49057 >it first.
49058 >     Example: ImmediatelySendAutokill
49059 >
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
49065 >kill them.
49066 >
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?
49071 >
49072 >Thanks
49073 >Saturn
49074 >
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
49080 >
49081 >
49082 >RTFM
49083 >
49084 >   --Andrew Church
49085 >     achurch@achurch.org
49086 >     http://achurch.org/
49087 >
49088 > >Haven't seen a reply to this one, so thought I'd better make sure this went
49089 > >through....
49090 > >
49091 > >----- Original Message -----
49092 > >Sent: Friday, October 10, 2003 3:48 PM
49093 > >Subject: Akill problem in 5.0.22
49094 > >
49095 > >
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).
49098 > >
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
49101 >scanning
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...
49106 > >
49107 > >First: IS that what it's supposed to do?
49108 > >
49109 > >Second: If so, it's not working...
49110 > >
49111 > >Saturn
49112 > >www.jetirc.net
49113 > >
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
49120 >
49121 >------------------------------------------------------------------
49122 >To unsubscribe or change your subscription options, visit:
49123 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
49124
49125
49126
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>
49133
49134 >From a.html in the /docs directory:
49135 ---------------
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
49140 it first.
49141     Example: ImmediatelySendAutokill
49142 --------------
49143
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 ------------------------
49158
49159 4.html#oper.akill doesn't mention it at all.
49160
49161 -----------------
49162
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!!!
49170
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?
49176
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???????
49183
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.
49193
49194 Saturn
49195
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
49201
49202
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
49207 >kill them.
49208
49209      The documentation says nothing about this.  RTFM again.
49210
49211   --Andrew Church
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
49217
49218
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>
49226
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.
49234
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
49241 programming...
49242
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
49250
49251
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
49257 to deal with it.
49258
49259 Ballsy
49260
49261
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
49265 >
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
49269 >it first.
49270 >     Example: ImmediatelySendAutokill
49271 >
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
49277 >kill them.
49278 >
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?
49283 >
49284 >Thanks
49285 >Saturn
49286 >
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
49292 >
49293 >
49294 >RTFM
49295 >
49296 >   --Andrew Church
49297 >     achurch@achurch.org
49298 >     http://achurch.org/
49299 >
49300 > >Haven't seen a reply to this one, so thought I'd better make sure this
49301 went
49302 > >through....
49303 > >
49304 > >----- Original Message -----
49305 > >Sent: Friday, October 10, 2003 3:48 PM
49306 > >Subject: Akill problem in 5.0.22
49307 > >
49308 > >
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).
49311 > >
49312 > >I just today added an akill (+0 time) .. I DO have the immediate auto
49313 kill
49314 > >option un-commented in the modules.conf, but it still didn't bother
49315 >scanning
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
49318 thought
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...
49321 > >
49322 > >First: IS that what it's supposed to do?
49323 > >
49324 > >Second: If so, it's not working...
49325 > >
49326 > >Saturn
49327 > >www.jetirc.net
49328 > >
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
49335 >
49336 >------------------------------------------------------------------
49337 >To unsubscribe or change your subscription options, visit:
49338 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
49339
49340
49341 ------------------------------------------------------------------
49342 To unsubscribe or change your subscription options, visit:
49343 http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
49344
49345
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>
49351
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.
49353
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
49355
49356 Please just calm down, and talk this out rationally before you start jumping down ppls throats :p
49357
49358 /*****************************************
49359  *     Craig "FrostyCoolSlug" McLure
49360  * InspIRCd   - http://www.inspircd.org
49361  * ChatSpike  - http://www.chatspike.net
49362  ****************************************/
49363
49364
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  ****************************************/
49371
49372 /****** - Begin Original Message - ******/
49373
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.
49381 >
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
49388 >programming...
49389 >
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
49397 >
49398 >
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
49404 >to deal with it.
49405 >
49406 >Ballsy
49407 >
49408 >
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
49412 >>
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
49416 >>it first.
49417 >>     Example: ImmediatelySendAutokill
49418 >>
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
49424 >>kill them.
49425 >>
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?
49430 >>
49431 >>Thanks
49432 >>Saturn
49433 >>
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
49439 >>
49440 >>
49441 >>RTFM
49442 >>
49443 >>   --Andrew Church
49444 >>     achurch@achurch.org
49445 >>     http://achurch.org/
49446 >>
49447 >> >Haven't seen a reply to this one, so thought I'd better make sure this
49448 >went
49449 >> >through....
49450 >> >
49451 >> >----- Original Message -----
49452 >> >Sent: Friday, October 10, 2003 3:48 PM
49453 >> >Subject: Akill problem in 5.0.22
49454 >> >
49455 >> >
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).
49458 >> >
49459 >> >I just today added an akill (+0 time) .. I DO have the immediate auto
49460 >kill
49461 >> >option un-commented in the modules.conf, but it still didn't bother
49462 >>scanning
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
49465 >thought
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...
49468 >> >
49469 >> >First: IS that what it's supposed to do?
49470 >> >
49471 >> >Second: If so, it's not working...
49472 >> >
49473 >> >Saturn
49474 >> >www.jetirc.net
49475 >> >
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
49482 >>
49483 >>------------------------------------------------------------------
49484 >>To unsubscribe or change your subscription options, visit:
49485 >>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
49486 >
49487 >
49488 >------------------------------------------------------------------
49489 >To unsubscribe or change your subscription options, visit:
49490 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
49491 >
49492 >------------------------------------------------------------------
49493 >To unsubscribe or change your subscription options, visit:
49494 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
49495 >
49496 >.
49497
49498 /******* - End Original Message - *******/
49499
49500
49501
49502
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>
49509
49510      You know, I might have been more forgiving if this hadn't been gone
49511 over on this list (twice!) before:
49512
49513 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/002305.html
49514 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/003215.html
49515
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
49518 edification:
49519
49520 F.10. Services doesn't kill users matching a newly-added autokill mask even
49521 if ImmediatelySendAutokill is set.
49522
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.
49529
49530         Note that some IRC servers will themselves kill users matching a
49531         newly-added autokill; this is unrelated to Services.
49532
49533   --Andrew Church
49534     achurch@achurch.org
49535     http://achurch.org/
49536
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>
49546
49547 Saturn wrote:
49548
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.
49556 >
49557 >
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
49564 do this.
49565
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).
49570
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.
49574
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.
49582
49583
49584
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>
49593
49594 On Saturday 18 October 2003 07:20, Robert F Merrill wrote:
49595 > Saturn 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.
49603 >
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
49610 > do this.
49611
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.
49614
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.
49619
49620 <<V13>>
49621
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>
49628
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)
49639
49640 root@irc(/home/ircadmin/services/lib)# ls -la core.12631
49641 -rw-------    1 ircadmin ircadmin 47374336 Oct 18 16:05 core.12631
49642
49643
49644 continue on the next message......
49645
49646
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>
49653
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;
49658 (gdb) bt'
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
49662         s = 0x806aa3e ""
49663 #1  0x0804d342 in set_cmode (sender=0x81db058 "ChanServ", channel=0xa905d00)
49664 at actions.c:446
49665         parambuf =
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"...
49674         len = 10
49675         flag = 1
49676         params = 1
49677         is_chanuser = 1
49678         args = 0xbfffe6d0 "RDcoCOREcorei??i??i??i??o"
49679         modes = 0xbfffeae2 ""
49680         modes_orig = 0xbfffeae0 "+o"
49681         md = (struct modedata *) 0x806aa00
49682         which = 0
49683         add = 1
49684         i = 1
49685         c = 111 'o'
49686 #2  0x400895ff in local_set_cumodes (c=0xa905d00, plusminus=43 '+', modes=1,
49687 nick=0xab7f2e8 "balsanelli") at check.c:432
49688         buf = "+o"
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).."...
49693         s = 0xbfffe6e1 ""
49694 #3  0x40088d74 in check_chan_user_modes (source=0xbfffeed0 "|-Frango-|",
49695 u=0xab34ff0, c=0xa905d00, oldmodes=1)
49696     at check.c:214
49697         user = (User *) 0xab7f2d8
49698         ci = (ChannelInfo *) 0xa571940
49699         modes = 0
49700         is_servermode = 0
49701         res = 1
49702 #4  0x400820ed in do_channel_umode_change (source=0xbfffeed0 "|-Frango-|",
49703 c=0xa905d00, u=0xab34ff0, oldmodes=1)
49704     at main.c:354
49705 No locals.
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
49710         res = 0
49711         i = 0
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---
49715     at channels.c:409
49716         u = (struct c_userlist *) 0xab34ff0
49717         user = (User *) 0xab7f2d8
49718         oldmode = 1
49719 #7  0x0804e97e in do_cmode (source=0xbfffeed0 "|-Frango-|", ac=0,
49720 av=0xa853130) at channels.c:302
49721         modechar = 111 'o'
49722         flag = 1
49723         params = -1073746288
49724         chan = (Channel *) 0xa905d00
49725         s = 0xbfffeca5 ""
49726         add = 0
49727         modestr = 0xbfffec9e "-oooooo"
49728 #8  0x080557ff in m_mode (source=0xbfffeed0 "|-Frango-|", ac=8,
49729 av=0xa853110) at messages.c:101
49730 No locals.
49731 #9  0x0805920e in process () at process.c:133
49732         m = (Message *) 0x8067dd8
49733         source =
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
49736 5\b"
49737         cmd =
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"
49741         buf =
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"
49749         ac = 8
49750         av = (char **) 0xa853110
49751 #10 0x0805507d in readline_callback (s=0xa851ae0, param_unused=0x50) at
49752 main.c:177
49753 No locals.
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."...
49759         left = 80
49760         newleft = 80
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}
49764         i = 4
49765         res = 260
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---
49770         now = 1066500331
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.
49776 (gdb)
49777
49778
49779
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>
49786
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.
49794
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?
49808
49809 Thank you all for your time.
49810
49811 Saturn
49812
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
49818
49819
49820      You know, I might have been more forgiving if this hadn't been gone
49821 over on this list (twice!) before:
49822
49823 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/002305.html
49824 http://www.ircservices.za.net/pipermail/ircservices-coding/2002/003215.html
49825
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
49828 edification:
49829
49830 F.10. Services doesn't kill users matching a newly-added autokill mask even
49831 if ImmediatelySendAutokill is set.
49832
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.
49839
49840 Note that some IRC servers will themselves kill users matching a
49841 newly-added autokill; this is unrelated to Services.
49842
49843   --Andrew Church
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
49849
49850
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>
49856
49857 If it helps, more lines up.. of debugging...
49858
49859
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)
49872
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>
49884
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.
49890
49891 Ballsy
49892
49893
49894 At 12:49 PM 18/10/2003, V13 wrote:
49895 >On Saturday 18 October 2003 07:20, Robert F Merrill wrote:
49896 > > Saturn 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.
49904 > >
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
49911 > > do this.
49912 >
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.
49915 >
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.
49920 >
49921 ><<V13>>
49922 >------------------------------------------------------------------
49923 >To unsubscribe or change your subscription options, visit:
49924 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
49925
49926
49927
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>
49933
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>
49941
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
49944
49945 ciao
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>
49955
49956 Andrew, have anything more of dumping/debugging that i can do/give for helps
49957 fixing this bug..?
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)....
49960 anything more?
49961
49962
49963 Thanks for all
49964
49965
49966 Diego B. Contezini
49967
49968
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>
49974
49975
49976
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>
49982
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
49985 18:41:36 BRT 2003)
49986 yes, 5.0.23 is the last.. but nothing has changed about the bug...
49987
49988  here is the debugging:
49989
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
49994 #Euevc
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
50002 +stmipl 1
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)
50014
50015
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;
50021 (gdb) bt'
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
50025         s = 0x806aa3e ""
50026 #1  0x0804d342 in set_cmode (sender=0x81db058 "ChanServ", channel=0xa905d00)
50027 at actions.c:446
50028         parambuf =
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"...
50037         len = 10
50038         flag = 1
50039         params = 1
50040         is_chanuser = 1
50041         args = 0xbfffe6d0 "RDcoCOREcorei??i??i??i??o"
50042         modes = 0xbfffeae2 ""
50043         modes_orig = 0xbfffeae0 "+o"
50044         md = (struct modedata *) 0x806aa00
50045         which = 0
50046         add = 1
50047         i = 1
50048         c = 111 'o'
50049 #2  0x400895ff in local_set_cumodes (c=0xa905d00, plusminus=43 '+', modes=1,
50050 nick=0xab7f2e8 "balsanelli") at check.c:432
50051         buf = "+o"
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).."...
50056         s = 0xbfffe6e1 ""
50057 #3  0x40088d74 in check_chan_user_modes (source=0xbfffeed0 "|-Frango-|",
50058 u=0xab34ff0, c=0xa905d00, oldmodes=1)
50059     at check.c:214
50060         user = (User *) 0xab7f2d8
50061         ci = (ChannelInfo *) 0xa571940
50062         modes = 0
50063         is_servermode = 0
50064         res = 1
50065 #4  0x400820ed in do_channel_umode_change (source=0xbfffeed0 "|-Frango-|",
50066 c=0xa905d00, u=0xab34ff0, oldmodes=1)
50067     at main.c:354
50068 No locals.
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
50073         res = 0
50074         i = 0
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---
50078     at channels.c:409
50079         u = (struct c_userlist *) 0xab34ff0
50080         user = (User *) 0xab7f2d8
50081         oldmode = 1
50082 #7  0x0804e97e in do_cmode (source=0xbfffeed0 "|-Frango-|", ac=0,
50083 av=0xa853130) at channels.c:302
50084         modechar = 111 'o'
50085         flag = 1
50086         params = -1073746288
50087         chan = (Channel *) 0xa905d00
50088         s = 0xbfffeca5 ""
50089         add = 0
50090         modestr = 0xbfffec9e "-oooooo"
50091 #8  0x080557ff in m_mode (source=0xbfffeed0 "|-Frango-|", ac=8,
50092 av=0xa853110) at messages.c:101
50093 No locals.
50094 #9  0x0805920e in process () at process.c:133
50095         m = (Message *) 0x8067dd8
50096         source =
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
50099 5\b"
50100         cmd =
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"
50104         buf =
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"
50112         ac = 8
50113         av = (char **) 0xa853110
50114 #10 0x0805507d in readline_callback (s=0xa851ae0, param_unused=0x50) at
50115 main.c:177
50116 No locals.
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."...
50122         left = 80
50123         newleft = 80
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}
50127         i = 4
50128         res = 260
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---
50133         now = 1066500331
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
50150 cs             0x23     35
50151 ss             0x2b     43
50152 ds             0x2b     43
50153 es             0x2b     43
50154 fs             0x0      0
50155 gs             0x33     51
50156 (gdb)
50157
50158
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
50171 ...
50172 model name      : Pentium III (Coppermine)
50173 stepping        : 10
50174 cpu MHz         : 999.752
50175 cache size      : 256 KB
50176 ...
50177 root@irc(/home/ircadmin/services)# free
50178              total       used       free     shared    buffers     cached
50179 Mem:        513792     482248      31544          0      69492     274980
50180
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*
50190
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
50202
50203
50204 If it helps, here is the debugging of the last two cores, on gdb:
50205 ----------------
50206 FIRST:
50207 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
50208 av=0xbfffdc38)
50209     at channels.c:278
50210 278         while (*s) {
50211 (gdb) bt'
50212 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
50213 av=0xbfffdc38)
50214     at channels.c:278
50215         chan = (Channel *) 0xa87d1e0
50216         s = 0x1f73746f <Address 0x1f73746f out of bounds>
50217         add = 1
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
50227 \006\b"...
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>}
50237         len = 5
50238 ---Type <return> to continue, or q <return> to quit---
50239         i = 0
50240         lastc = 45 '-'
50241 #2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
50242         args = 0x0
50243         modes = 0x0
50244         modes_orig = 0x0
50245         md = (struct modedata *) 0x0
50246         which = -1
50247         add = 0
50248         i = 0
50249         c = 0 '\0'
50250 #3  0x080553a3 in main (ac=1, av=0xbfffe574, envp=0xbfffe57c) at main.c:269
50251         now = 1067891066
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.
50257 -----------
50258
50259 SECOND:
50260 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
50261 av=0xbffff2b8)
50262     at channels.c:278
50263 278         while (*s) {
50264 (gdb) bt'
50265 #0  0x0804e8bf in do_cmode (source=0x806aa08 "ChanServ", ac=-1,
50266 av=0xbffff2b8)
50267     at channels.c:278
50268         chan = (Channel *) 0xa9be840
50269         s = 0xbf000000 <Address 0xbf000000 out of bounds>
50270         add = 1
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>}
50287         len = 5
50288         i = 0
50289         lastc = 45 '-'
50290 #2  0x0804cebd in set_cmode (sender=0x0, channel=0x0) at actions.c:321
50291 ---Type <return> to continue, or q <return> to quit---
50292         args = 0x0
50293         modes = 0x0
50294         modes_orig = 0x0
50295         md = (struct modedata *) 0x0
50296         which = -1
50297         add = 0
50298         i = 0
50299         c = 0 '\0'
50300 #3  0x080553a3 in main (ac=1, av=0xbffffbf4, envp=0xbffffbfc) at main.c:269
50301         now = 1067706795
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.
50307 (gdb)
50308 -------
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
50311 this bug...
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
50315 anything....
50316
50317 Thanks for all development, this is really a bealtifull software...
50318 (and sorry for my bad english)
50319
50320 Diego B. Contezini aka destruct_ #irc.redesul.net
50321
50322
50323
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>
50329
50330 If it helps, im using Bahamut here....
50331
50332
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>
50339
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 ?
50348
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.
50358
50359   --Andrew Church
50360     achurch@achurch.org
50361     http://achurch.org/
50362
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>
50368
50369 I'm getting this too - it's just started happening in 5.0.23:
50370
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'
50375
50376 gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
50377
50378 Russ
50379
50380
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>
50386
50387 Where is the akill type used in some of the AutoKill functions listed in the
50388 modules/database/readme file defined?
50389
50390 ________________________________________________
50391 Message sent using MHCABLE Webmail
50392
50393
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>
50403
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 :)
50408
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
50414         cat <<EOT
50415
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
50421
50422
50423 ________________________________________________________________
50424 Matthew Hodgson   arathorn@theonering.net   Tel: +44 7968 722968
50425              Arathorn: Co-Sysadmin, TheOneRing.net?
50426
50427 On Wed, 12 Nov 2003, Arathorn wrote:
50428
50429 > Hi Andy,
50430 >
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
50435 > anyway).
50436 >
50437 > Here's the stderr & stdio - the configure.log is attached:
50438 >
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
50443 >
50444 > Beginning IRC Services configuration.
50445 >
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
50449 >
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
50452 >
50453 > End of interactive configuration.
50454 >
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
50459 >
50460 > WARNING: Your version of GCC was detected as Press Enter to continue:
50461 >
50462 >
50463 >
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! ***
50471 >
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.
50478 >
50479 > ________________________________________________________________
50480 > Matthew Hodgson   arathorn@theonering.net   Tel: +44 7968 722968
50481 >              Arathorn: Co-Sysadmin, TheOneRing.net?
50482 >
50483 > On Tue, 11 Nov 2003, Andrew Church wrote:
50484 >
50485 > >      Services 5.0.24 has been released, and can be downloaded from:
50486 > >
50487 > > ftp://ftp.esper.net/ircservices/               (USA, California)
50488 > >
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
50493 > >
50494 > > ftp.ircservices.za.net and the other mirrors should have it shortly.
50495 > >
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.
50501 > >
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>
50518 > >
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
50525 > >
50526 > >
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
50533         cat <<EOT
50534
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>
50546
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:
50550
50551
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
50557         cat <<EOT
50558
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
50564
50565
50566
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.)
50570
50571 ________________________________________________________________
50572 Matthew Hodgson   arathorn@theonering.net   Tel: +44 7968 722968
50573              Arathorn: Co-Sysadmin, TheOneRing.net?
50574
50575 On Wed, 12 Nov 2003, Arathorn wrote:
50576
50577 > Hi Andy,
50578 >
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
50583 > anyway).
50584 >
50585 > Here's the stderr & stdio - the configure.log is attached:
50586 >
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
50591 >
50592 > Beginning IRC Services configuration.
50593 >
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
50597 >
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
50600 >
50601 > End of interactive configuration.
50602 >
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
50607 >
50608 > WARNING: Your version of GCC was detected as Press Enter to continue:
50609 >
50610 >
50611 >
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! ***
50619 >
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.
50626 >
50627 > ________________________________________________________________
50628 > Matthew Hodgson   arathorn@theonering.net   Tel: +44 7968 722968
50629 >              Arathorn: Co-Sysadmin, TheOneRing.net?
50630 >
50631 > On Tue, 11 Nov 2003, Andrew Church wrote:
50632 >
50633 > >      Services 5.0.24 has been released, and can be downloaded from:
50634 > >
50635 > > ftp://ftp.esper.net/ircservices/               (USA, California)
50636 > >
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
50641 > >
50642 > > ftp.ircservices.za.net and the other mirrors should have it shortly.
50643 > >
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.
50649 > >
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>
50666 > >
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
50673 > >
50674 > >
50675
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>
50684
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.
50695
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
50701         cat <<EOT
50702
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 @@
50709  EOT
50710         echo2 "Press Enter to continue: "
50711         read dummy
50712 +       CC=gcc
50713 +       DEF_CC_FLAGS=`def_cc_flags $CC`
50714 +       log using \`gcc\'
50715         WARNED_OLD_GCC=1
50716      else  # version okay
50717         echo "great, found gcc!"
50718
50719
50720 ________________________________________________________________
50721 Matthew Hodgson   arathorn@theonering.net   Tel: +44 7968 722968
50722              Arathorn: Co-Sysadmin, TheOneRing.net?
50723
50724 On Sat, 15 Nov 2003, Andrew Church wrote:
50725
50726 >      Thanks, fixed.  Silly little details...
50727 >
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.)
50731 >
50732 >   --Andrew Church
50733 >     achurch@achurch.org
50734 >     http://achurch.org/
50735 >
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:
50739 > >
50740 > >
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
50746 > >     cat <<EOT
50747 > >
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
50753 > >
50754 > >
50755 > >
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.)
50759 > >
50760 > >________________________________________________________________
50761 > >Matthew Hodgson   arathorn@theonering.net   Tel: +44 7968 722968
50762 > >             Arathorn: Co-Sysadmin, TheOneRing.net??
50763 > >
50764 > >On Wed, 12 Nov 2003, Arathorn wrote:
50765 > >
50766 > >> Hi Andy,
50767 > >>
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
50772 > >> anyway).
50773 > >>
50774 > >> Here's the stderr & stdio - the configure.log is attached:
50775 > >>
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
50780 > >>
50781 > >> Beginning IRC Services configuration.
50782 > >>
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
50786 > >>
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
50789 > >>
50790 > >> End of interactive configuration.
50791 > >>
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
50796 > >>
50797 > >> WARNING: Your version of GCC was detected as Press Enter to continue:
50798 > >>
50799 > >>
50800 > >>
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! ***
50808 > >>
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.
50815 > >>
50816 > >> ________________________________________________________________
50817 > >> Matthew Hodgson   arathorn@theonering.net   Tel: +44 7968 722968
50818 > >>              Arathorn: Co-Sysadmin, TheOneRing.net??
50819 > >>
50820 > >> On Tue, 11 Nov 2003, Andrew Church wrote:
50821 > >>
50822 > >> >      Services 5.0.24 has been released, and can be downloaded from:
50823 > >> >
50824 > >> > ftp://ftp.esper.net/ircservices/               (USA, California)
50825 > >> >
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
50830 > >> >
50831 > >> > ftp.ircservices.za.net and the other mirrors should have it shortly.
50832 > >> >
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.
50838 > >> >
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>
50855 > >> >
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
50862 > >> >
50863 > >> >
50864 >
50865 >
50866
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>
50872
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.
50874
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 :)
50876
50877
50878
50879
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
50884         ./configure
50885 Message-ID: <6.0.0.22.0.20031117144131.0481a8c0@127.0.0.1>
50886
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:
50890
50891 Checking sanity of /bin/sh... high.
50892 Searching for a suitable compiler... ./configure: 29: Syntax error: EOF in
50893 backquote substitution
50894
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).
50901
50902 gmake 3.80
50903 FreeBSD 4.9-STABLE
50904
50905 David
50906
50907
50908
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
50913         ./configure
50914 Message-ID: <Pine.LNX.4.56L0.0311181144590.6789@phoenix.siarch.net>
50915
50916 David,
50917
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).
50924
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:
50931
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)
50934
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 :)
50937
50938 A.
50939
50940 ________________________________________________________________
50941 Matthew Hodgson   arathorn@theonering.net   Tel: +44 7968 722968
50942              Arathorn: Co-Sysadmin, TheOneRing.net?
50943
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
50950
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.
50961
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
50967         cat <<EOT
50968
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 @@
50975  EOT
50976         echo2 "Press Enter to continue: "
50977         read dummy
50978 +       CC=gcc
50979 +       DEF_CC_FLAGS=`def_cc_flags $CC`
50980 +       log using \`gcc\'
50981         WARNED_OLD_GCC=1
50982      else  # version okay
50983         echo "great, found gcc!"
50984
50985
50986 ________________________________________________________________
50987 Matthew Hodgson   arathorn@theonering.net   Tel: +44 7968 722968
50988              Arathorn: Co-Sysadmin, TheOneRing.net?
50989
50990 On Sat, 15 Nov 2003, Andrew Church wrote:
50991
50992 >      Thanks, fixed.  Silly little details...
50993 >
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.)
50997 >
50998 >   --Andrew Church
50999 >     achurch@achurch.org
51000 >     http://achurch.org/
51001 >
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:
51005 > >
51006 > >
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
51012 > >     cat <<EOT
51013 > >
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
51019 > >
51020 > >
51021 > >
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.)
51025 > >
51026 > >________________________________________________________________
51027 > >Matthew Hodgson   arathorn@theonering.net   Tel: +44 7968 722968
51028 > >             Arathorn: Co-Sysadmin, TheOneRing.net??
51029 > >
51030 > >On Wed, 12 Nov 2003, Arathorn wrote:
51031 > >
51032 > >> Hi Andy,
51033 > >>
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
51038 > >> anyway).
51039 > >>
51040 > >> Here's the stderr & stdio - the configure.log is attached:
51041 > >>
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
51046 > >>
51047 > >> Beginning IRC Services configuration.
51048 > >>
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
51052 > >>
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
51055 > >>
51056 > >> End of interactive configuration.
51057 > >>
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
51062 > >>
51063 > >> WARNING: Your version of GCC was detected as Press Enter to continue:
51064 > >>
51065 > >>
51066 > >>
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! ***
51074 > >>
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.
51081 > >>
51082 > >> ________________________________________________________________
51083 > >> Matthew Hodgson   arathorn@theonering.net   Tel: +44 7968 722968
51084 > >>              Arathorn: Co-Sysadmin, TheOneRing.net??
51085 > >>
51086 > >> On Tue, 11 Nov 2003, Andrew Church wrote:
51087 > >>
51088 > >> >      Services 5.0.24 has been released, and can be downloaded from:
51089 > >> >
51090 > >> > ftp://ftp.esper.net/ircservices/               (USA, California)
51091 > >> >
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
51096 > >> >
51097 > >> > ftp.ircservices.za.net and the other mirrors should have it shortly.
51098 > >> >
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.
51104 > >> >
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>
51121 > >> >
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
51128 > >> >
51129 > >> >
51130 >
51131 >
51132
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>
51138
51139         Perhaps I don't have a complete understanding of its functionality, so
51140 correct me if I'm wrong.
51141
51142 ircservices-5.0.25
51143 bahamut-1.4.30
51144 FreeBSD 4.9-STABLE
51145
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...
51155
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
51159 `ExpireTimeout
51160 ' used
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
51164
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.
51170
51171 David
51172
51173
51174
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>
51180
51181 Greetings!
51182
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.
51185
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
51193 stuck)
51194
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 :-/)
51198
51199 Thanks, :D
51200 FC
51201
51202
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
51207         registered channel
51208 References: <000d01c3b0d7$ba5648e0$0100a8c0@blauwhome>
51209 Message-ID: <001101c3b0dc$7cc22da0$a37faec3@coder>
51210
51211 Hello,
51212
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
51216 comments?
51217
51218 |SaMaN|
51219
51220 ----------------
51221     [#geyik]
51222      . [total users 1] [ops 1(100%)] [halfops 0(0%)] [voice 0(0%)] [regular
51223 0(0%)]
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
51230      . synched in 1sec
51231     [end]
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
51237 * Timer 1 halted
51238     [#geyik]
51239      . [total users 1] [ops 1(100%)] [halfops 0(0%)] [voice 0(0%)] [regular
51240 0(0%)]
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
51248      . synched in 1sec
51249     [end]
51250 -------------------
51251
51252
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
51257         registered channel
51258 In-Reply-To: <001101c3b0dc$7cc22da0$a37faec3@coder>
51259 Message-ID: <3fc1c44f.13432@achurch.org>
51260
51261      This is an artifact of the way IRC works.  If this is a problem, turn
51262 topic lock on.
51263
51264   --Andrew Church
51265     achurch@achurch.org
51266     http://achurch.org/
51267
51268 >Hello,
51269 >
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
51273 >comments?
51274 >
51275 >|SaMaN|
51276 >
51277 >----------------
51278 >    [#geyik]
51279 >     . [total users 1] [ops 1(100%)] [halfops 0(0%)] [voice 0(0%)] [regular
51280 >0(0%)]
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
51288 >    [end]
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
51294 >* Timer 1 halted
51295 >    [#geyik]
51296 >     . [total users 1] [ops 1(100%)] [halfops 0(0%)] [voice 0(0%)] [regular
51297 >0(0%)]
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
51306 >    [end]
51307 >-------------------
51308 >
51309 >------------------------------------------------------------------
51310 >To unsubscribe or change your subscription options, visit:
51311 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
51312
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
51317         ./configure
51318 In-Reply-To: <6.0.0.22.0.20031117144131.0481a8c0@127.0.0.1>
51319 Message-ID: <200311250831.hAP8VaMi012034@ariadni.forthnet.gr>
51320
51321 Sen
51322 Message-ID: <3fb9930b.03510@achurch.org>
51323
51324 (private CC because the mailing list seems to be broken)
51325
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.
51328
51329   --Andrew Church
51330     achurch@achurch.org
51331     http://achurch.org/
51332
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:
51336 >
51337 >Checking sanity of /bin/sh... high.
51338 >Searching for a suitable compiler... ./configure: 29: Syntax error: EOF in
51339 >backquote substitution
51340 >
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).
51347 >
51348 >gmake 3.80
51349 >FreeBSD 4.9-STABLE
51350 >
51351 >David
51352 >
51353 >
51354 >------------------------------------------------------------------
51355 >To unsubscribe or change your subscription options, visit:
51356 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
51357
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>
51364
51365 Sen
51366 Message-ID: <3fb8311e.60353@achurch.org>
51367
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.
51372
51373   --Andrew Church
51374     achurch@achurch.org
51375     http://achurch.org/
51376
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.
51379 >
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 :)
51381 >
51382 >
51383 >
51384 >------------------------------------------------------------------
51385 >To unsubscribe or change your subscription options, visit:
51386
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>
51393
51394 Sen
51395 Message-ID: <3fbcbd0d.72522@achurch.org>
51396
51397 (CC'd privately because my mail doesn't seem to be going through to the
51398 list)
51399
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.
51408
51409      That's a bug, not a feature! ...oh, wait...
51410
51411      Fixed for 5.0.26, thanks for the report.
51412
51413   --Andrew Church
51414     achurch@achurch.org
51415     http://achurch.org/
51416
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>
51422
51423 Hi,
51424
51425 I would like to recommend a change in /modules/protocol/unreal.c
51426
51427 module_log("m_sethost: user record for %s not found", source);
51428
51429 This line generates useless log lines and since this situations is handled well I recommend it?s removal.
51430
51431 This is tested and services run more then fine without it.
51432
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>
51442
51443      This is a bug in Unreal, and I'm not going to work around it.  And
51444 don't send HTML mail.
51445
51446   --Andrew Church
51447     achurch@achurch.org
51448     http://achurch.org/
51449
51450 >This is a multi-part message in MIME format.
51451 >
51452 >--===============1880783837==
51453 >Content-Type: multipart/alternative;
51454 >       boundary="----=_NextPart_000_0016_01C3B355.0FC92B60"
51455 >
51456 >This is a multi-part message in MIME format.
51457 >
51458 >------=_NextPart_000_0016_01C3B355.0FC92B60
51459 >Content-Type: text/plain;
51460 >       charset="utf-8"
51461 >Content-Transfer-Encoding: quoted-printable
51462 >
51463 >Hi,
51464 >
51465 >I would like to recommend a change in /modules/protocol/unreal.c
51466 >
51467 >module_log("m_sethost: user record for %s not found", source);
51468 >
51469 >This line generates useless log lines and since this situations is =
51470 >handled well I recommend it=E2=80=99s removal.
51471 >
51472 >This is tested and services run more then fine without it.
51473 >
51474 >
51475 >------=_NextPart_000_0016_01C3B355.0FC92B60
51476 >Content-Type: text/html;
51477 >       charset="utf-8"
51478 >Content-Transfer-Encoding: quoted-printable
51479 >
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">
51483 >
51484 ><head>
51485 ><meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8">
51486 ><meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
51487 ><style>
51488 ><!--
51489 > /* Font Definitions */
51490 > @font-face
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
51495 >       {margin:0cm;
51496 >       margin-bottom:.0001pt;
51497 >       font-size:12.0pt;
51498 >       font-family:"Times New Roman";}
51499 >a:link, span.MsoHyperlink
51500 >       {color:blue;
51501 >       text-decoration:underline;}
51502 >a:visited, span.MsoHyperlinkFollowed
51503 >       {color:purple;
51504 >       text-decoration:underline;}
51505 >span.EmailStyle17
51506 >       {mso-style-type:personal-compose;
51507 >       font-family:Arial;
51508 >       color:windowtext;}
51509 >@page Section1
51510 >       {size:612.0pt 792.0pt;
51511 >       margin:72.0pt 90.0pt 72.0pt 90.0pt;}
51512 >div.Section1
51513 >       {page:Section1;}
51514 >-->
51515 ></style>
51516 >
51517 ></head>
51518 >
51519 ><body lang=3DEN-US link=3Dblue vlink=3Dpurple>
51520 >
51521 ><div class=3DSection1>
51522 >
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>
51526 >
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>
51531 >
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(&quot;m_sethost: user record for %s =
51535 >not
51536 >found&quot;, source);<o:p></o:p></span></font></p>
51537 >
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>
51543 >
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>
51548 >
51549 ></div>
51550 >
51551 ></body>
51552 >
51553 ></html>
51554 >
51555 >------=_NextPart_000_0016_01C3B355.0FC92B60--
51556 >
51557 >
51558 >--===============1880783837==
51559 >Content-Type: text/plain; charset="us-ascii"
51560 >MIME-Version: 1.0
51561 >Content-Transfer-Encoding: 7bit
51562 >Content-Disposition: inline
51563 >
51564 >------------------------------------------------------------------
51565 >To unsubscribe or change your subscription options, visit:
51566 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
51567 >
51568 >--===============1880783837==--
51569 >
51570
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>
51576
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.
51581
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.
51583
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.
51585
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:
51587
51588 For info on and solutions to login problems visit:
51589
51590 http://www.chatfirst.com/login.html
51591
51592 For info on how to stop flooders and get rid of trouble makers:
51593
51594 http://www.chatfirst.com/control.html
51595
51596 For info regarding a ban that is preventing you from connecting to ChatFIRST.COM servers please visit:
51597
51598 http://www.chatfirst.com/passport.html
51599
51600 For help related to commands sent to NickServ, ChanServ, MemoServ etc:
51601
51602 http://www.chatfirst.com/services.html
51603
51604 For WebTV commands visit:
51605 http://www.chatfirst.com/services.html#TVcommands
51606 and also:
51607 http://www.chatfirst.com/users/chatfirst/webtv/index.html
51608
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.
51611 Regards
51612 ChatFIRST.COM INC
51613 Support Team
51614
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>
51621
51622 Confusion is setting in and I am hoping to get clarification so I have a few questions.
51623
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?
51625
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:
51627
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
51631
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?
51633
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?
51635
51636
51637 Thanks In Advance.
51638 Chris Riley
51639
51640
51641
51642
51643
51644 ---
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>
51654
51655 Went ahead and created a core file and did a backtrace on it here is the
51656 output:
51657
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 ()
51673
51674
51675 Ideas?
51676
51677
51678
51679
51680
51681 ---
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
51685
51686
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>
51692
51693 5.0.26
51694 bahamut-1.4.30
51695
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...
51699
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)
51702
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.
51707
51708 David
51709
51710
51711
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
51716         Unreal
51717 Message-ID: <00bf01c3b5ad$b0a15a80$0500a8c0@cyberchatnet.com>
51718
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?
51720
51721 Thank you
51722 Phil
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
51730         withUnreal
51731 References: <00bf01c3b5ad$b0a15a80$0500a8c0@cyberchatnet.com>
51732 Message-ID: <001c01c3b660$44e6adf0$f4a6ef9b@dylan>
51733
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.
51738
51739     ImmediatelySendAutokill
51740
51741
51742 Dylan.
51743   ----- Original Message -----
51744   From: Phil
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
51748
51749
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?
51751
51752   Thank you
51753   Phil
51754
51755
51756 ------------------------------------------------------------------------------
51757
51758
51759   ------------------------------------------------------------------
51760   To unsubscribe or change your subscription options, visit:
51761   http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
51762
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>
51772
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...
51776 >
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)
51779
51780      Fixed, thanks for the report.
51781
51782   --Andrew Church
51783     achurch@achurch.org
51784     http://achurch.org/
51785
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>
51791
51792 As I understand to set the timestamp of a chanserv registered channel unreal needs a mode too,
51793
51794 If I understood right this is done by doing ?o and +o to the joining user which might be a bit annoying,
51795
51796 Is it possible to let?s say set +r to the channel instead?
51797
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>
51806
51807 Greetings :)
51808
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
51812 IRCServices.
51813
51814 This HostServ module doesn't have to be complicated. Just the basic Add,
51815 remove, list and login commands.
51816
51817 Thanks
51818 FC
51819
51820
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>
51826
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
51828
51829 /****************************************
51830  *     Craig "FrostyCoolSlug" McLure
51831  * InspIRCd   - http://www.inspircd.org
51832  * ChatSpike  - http://www.chatspike.net
51833  ****************************************/
51834
51835
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  ****************************************/
51842
51843 /****** - Begin Original Message - ******/
51844
51845 >Greetings :)
51846 >
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
51850 >IRCServices.
51851 >
51852 >This HostServ module doesn't have to be complicated. Just the basic Add,
51853 >remove, list and login commands.
51854 >
51855 >Thanks
51856 >FC
51857 >
51858 >------------------------------------------------------------------
51859 >To unsubscribe or change your subscription options, visit:
51860 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
51861 >.
51862
51863 /******* - End Original Message - *******/
51864
51865
51866
51867
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>
51874
51875 You may possibly want to look at NeoStats's HostServ module. Running
51876 NeoStats would require an additional bg process though.
51877
51878 ~Ganja51
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
51884
51885
51886 > Greetings :)
51887 >
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
51891 > IRCServices.
51892 >
51893 > This HostServ module doesn't have to be complicated. Just the basic Add,
51894 > remove, list and login commands.
51895 >
51896 > Thanks
51897 > FC
51898 >
51899 > ------------------------------------------------------------------
51900 > To unsubscribe or change your subscription options, visit:
51901 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
51902 >
51903 >
51904
51905
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>
51911
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?
51915
51916 thanks in advance :)
51917
51918
51919 /****************************************
51920  *     Craig "FrostyCoolSlug" McLure
51921  * InspIRCd   - http://www.inspircd.org
51922  * ChatSpike  - http://www.chatspike.net
51923  ****************************************/
51924
51925
51926
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>
51933
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?
51937
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
51940 pointer return.
51941
51942   --Andrew Church
51943     achurch@achurch.org
51944     http://achurch.org/
51945
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>
51951
51952 Hi...
51953
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 :-)
51956
51957 Thanks,
51958 Brain
51959
51960 ---
51961 http://www.chatspike.net
51962
51963
51964
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>
51971
51972 RTFM (6-1-4) and use add_callback_pri().
51973
51974   --Andrew Church
51975     achurch@achurch.org
51976     http://achurch.org/
51977
51978 >Hi...
51979 >
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 :-)
51983 >
51984 >Thanks,
51985 >Brain
51986 >
51987 >---
51988 >http://www.chatspike.net
51989 >
51990 >
51991 >------------------------------------------------------------------
51992 >To unsubscribe or change your subscription options, visit:
51993
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>
51999
52000 Hiya, it's me again!
52001
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
52005 etc.
52006
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.
52013
52014 Thanks for any help,
52015 FC
52016
52017
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>
52024
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
52028 >etc.
52029 >
52030 >I was wondering, how does IRCServices cope with these new prefixes? Is there
52031 >something I drastically need change in the protocol setup.
52032
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.
52038
52039 >Also, does
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.
52044
52045      No, there isn't.
52046
52047   --Andrew Church
52048     achurch@achurch.org
52049     http://achurch.org/
52050
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>
52057
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"
52071 applies.
52072
52073 Thanks for the prompt replies thusfar :D
52074 FC
52075
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
52081
52082
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
52086 Kicking
52087 > >etc.
52088 > >
52089 > >I was wondering, how does IRCServices cope with these new prefixes? Is
52090 there
52091 > >something I drastically need change in the protocol setup.
52092 >
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
52096 they
52097 > will lose privileges on the channel (which could potentially result in
52098 mode
52099 > change loops).  I have no plans to add specific support for such prefixes.
52100 >
52101 > >Also, does
52102 > >IRCServices still set +ao when a user's got AUTOPROTECT and also +qo when
52103 a
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.
52107 >
52108 >      No, there isn't.
52109 >
52110 >   --Andrew Church
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
52116 >
52117
52118
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>
52124
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.
52127
52128
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>
52134
52135 (Sorry this went to the wrong list..)
52136
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.
52138
52139 /****************************************
52140  *     Craig "FrostyCoolSlug" McLure
52141  * InspIRCd   - http://www.inspircd.org
52142  * ChatSpike  - http://www.chatspike.net
52143  ****************************************/
52144
52145
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  ****************************************/
52152
52153 /****** - Begin Original Message - ******/
52154
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.
52157 >
52158 >------------------------------------------------------------------
52159 >To unsubscribe or change your subscription options, visit:
52160 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
52161 >.
52162
52163 /******* - End Original Message - *******/
52164
52165
52166
52167
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>
52174
52175
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.
52178
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
52184
52185 (Sorry this went to the wrong list..)
52186
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.
52188
52189
52190
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>
52196
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.
52198
52199 /****************************************
52200  *     Craig "FrostyCoolSlug" McLure
52201  * InspIRCd   - http://www.inspircd.org
52202  * ChatSpike  - http://www.chatspike.net
52203  ****************************************/
52204
52205
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  ****************************************/
52212
52213 /****** - Begin Original Message - ******/
52214
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.
52217 >
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
52223 >
52224 >(Sorry this went to the wrong list..)
52225 >
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.
52227 >
52228 >
52229 >------------------------------------------------------------------
52230 >To unsubscribe or change your subscription options, visit:
52231 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
52232 >.
52233
52234 /******* - End Original Message - *******/
52235
52236
52237
52238
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>
52245
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.
52251
52252 ~Ganja51
52253
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
52259 fields
52260
52261
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.
52271 >
52272 > /****************************************
52273 >  *     Craig "FrostyCoolSlug" McLure
52274 >  * InspIRCd   - http://www.inspircd.org
52275 >  * ChatSpike  - http://www.chatspike.net
52276 >  ****************************************/
52277 >
52278 >
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
52285 fields
52286 >  ****************************************/
52287 >
52288 > /****** - Begin Original Message - ******/
52289 >
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.
52294 > >
52295 > >-----Original Message-----
52296 > >From: ircservices-coding-bounces@ircservices.za.net
52297 [mailto:ircservices-coding-bounces@ircservices.za.net] On Behalf Of Craig
52298 McLure
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
52302 fields
52303 > >
52304 > >(Sorry this went to the wrong list..)
52305 > >
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
52309 pointless.
52310 > >
52311 > >
52312 > >------------------------------------------------------------------
52313 > >To unsubscribe or change your subscription options, visit:
52314 > >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
52315 > >.
52316 >
52317 > /******* - End Original Message - *******/
52318 >
52319 >
52320 >
52321 > ------------------------------------------------------------------
52322 > To unsubscribe or change your subscription options, visit:
52323 > http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
52324 >
52325 >
52326
52327
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>
52334
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).
52336
52337
52338
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>
52344
52345 so register your nickname with one of those email addresses? :/
52346
52347 /****************************************
52348  *     Craig "FrostyCoolSlug" McLure
52349  * InspIRCd   - http://www.inspircd.org
52350  * ChatSpike  - http://www.chatspike.net
52351  ****************************************/
52352
52353
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  ****************************************/
52360
52361 /****** - Begin Original Message - ******/
52362
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).
52364 >
52365 >
52366 >------------------------------------------------------------------
52367 >To unsubscribe or change your subscription options, visit:
52368 >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
52369 >.
52370
52371 /******* - End Original Message - *******/
52372
52373
52374
52375
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>
52382
52383 Thanks for that genius, now be quiet.
52384
52385 /*************************************
52386  * I SPAM MY CRAPPY STUPID WEBSITE TOO
52387  * AND SEND IT IN MY SHITTY MAIL
52388  *************************************/
52389
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
52395
52396 so register your nickname with one of those email addresses? :/
52397
52398 /****************************************
52399  *     Craig "FrostyCoolSlug" McLure
52400  * InspIRCd   - http://www.inspircd.org
52401  * ChatSpike  - http://www.chatspike.net
52402  ****************************************/
52403
52404
52405
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>
52412
52413 On Tuesday, Dec 30, 2003, at 12:49 US/Pacific, PHANTOm wrote:
52414
52415 > Thanks for that genius, now be quiet.
52416 >
52417 > /*************************************
52418 >  * I SPAM MY CRAPPY STUPID WEBSITE TOO
52419 >  * AND SEND IT IN MY SHITTY MAIL
52420 >  *************************************/
52421
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.
52425
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.
52430
52431 -- Quension
52432
52433
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>
52441
52442 On Tue, 2003-12-30 at 20:49, PHANTOm wrote:
52443 > Thanks for that genius, now be quiet.
52444 >
52445 > /*************************************
52446 >  * I SPAM MY CRAPPY STUPID WEBSITE TOO
52447 >  * AND SEND IT IN MY SHITTY MAIL
52448 >  *************************************/
52449 <snip>
52450
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
52453 yours.
52454
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.
52458
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.
52462
52463 -jps
52464
52465 --
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
52474 Size: 189 bytes
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>
52483
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.
52487
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
52493
52494
52495 <snip>
52496
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
52499 yours.
52500
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.
52504
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.
52508
52509 -jps
52510
52511 --
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
52516
52517
52518