rename -> *.git

[irc.git] / software / RELEASES / ircservices / achurch.org / services / lists / ircservices-coding / 2001.txt

From dropper at softhome.net  Fri Jan 26 06:57:28 2001
From: dropper at softhome.net (Levent OZVEREN)
Date: Sat Oct 23 23:09:11 2004
Subject: [Ircservices-coding] subscribe dropper@softhome.net
Message-ID: <001c01c087a8$52a870c0$a591bad5@m4l7l9>




From andy at strugglers.net  Sat Jan 27 04:18:06 2001
From: andy at strugglers.net (Andy Smith)
Date: Sat Oct 23 23:09:11 2004
Subject: [Ircservices-coding] akill sanity checking
Message-ID: <q7657tofm70rnp7cehtj2nll68anr1ebb0@4ax.com>

Hi,

There's a FIXME in the ADD section of do_akill from akill.c regarding
wanting a better way to check for an insane akill mask.  I've found the
following idea useful:

                        for (i = strlen(mask) - 1;
                             i > 0 && mask[i] != '@'; i--) {
                                if (! strchr("*?.", mask[i])) {
                                        nonwild++;
                                }
                        }

                        if (AkillWildThresh && nonwild < AkillWildThresh) {
                                notice_lang(s_OperServ, u,
                                            OPER_AKILL_MASK_TOO_GENERAL);
                                return;
                        }

i.e. it counts from right to left in the mask checking how many characters
there are which don't match '?', '*' or '.'.  AkillWildThresh would be a
config option, an example setting of 4 would prevent the following akills:

*@*
*@?*
*@*?com
*@*.com

but would allow akills such as:

*@*a.com
*@foobar*

Works for me, and is nicely configurable.

-- 
Andy Smith <andy@strugglers.net>


From andy at strugglers.net  Mon Jan 29 15:01:34 2001
From: andy at strugglers.net (Andy Smith)
Date: Sat Oct 23 23:09:11 2004
Subject: [Ircservices-coding] Re: [IRCServices] Services 4.5pre0 released
In-Reply-To: <3a74b222.15614@prima-lan.net>
References: <3a74b222.15614@prima-lan.net>
Message-ID: <u7ja7t8g3p9g2neuhf51d6cs4poc7ks8bu@4ax.com>

On Mon, 29 Jan 2001 08:57:09 JST, achurch@achurch.org (Andrew Church) wrote:

>     Services 4.5pre0 has been released, and can be downloaded from:
>
>ftp://ftp.esper.net/ircservices/ircservices-4.5pre0.tar.gz

>  * Support for the DALnet Bahamut server has been improved.  Note that
>	only versions 1.4.1 and later are supported (support for earlier
>	versions has been dropped).

Please note that if you are using Bahamut and ircservices-4.5 then the
ChanServ UNBAN command may not work correctly, due to this bug in Bahamut:

http://ircd-devel.dal.net/jitterbug/jitterbug.cgi/incoming?id=806;expression=del_banid;user=guest

Bahamut's support for SVSMODE -b only works by chance on FreeBSD, and fails
on Linux and probably other platforms.  The result is that you see the ban
being lifted but in reality it is still there.

If you don't mind editing the code of your ircd then a quick fix is very
simple, just read the above bug report.

That also explains why Dalnet's own ChanServ UNBAN command has stopped
working for users of twisted.* and tsunami.*.

-- 
Andy Smith <andy@strugglers.net>


From andrewk at icon.co.za  Thu Feb  1 00:22:09 2001
From: andrewk at icon.co.za (Andrew Kempe)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices-Coding] test
Message-ID: <075e01c08c28$11d0c910$9c011ac4@africa.didata.local>




From andrewk at icon.co.za  Thu Feb  1 00:27:45 2001
From: andrewk at icon.co.za (Andrew Kempe)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices-Coding] New Mailing List Software
Message-ID: <076601c08c28$da429130$9c011ac4@africa.didata.local>

The ircservices-coding mailing list has been upgraded to mailman too.

Please post to this list using ircservices-coding@ircservices.za.net from
now on. You can get support for the mailing list from:
http://www.ircservices.za.net/mailman/listinfo/ircservices-coding

To unsubscribe mail ircservices-coding-request@ircservices.za.net with
UNSUBSCRIBE in the subject of the email.

Later, Andrew



From ctackett at pirchplace.com  Thu Mar 29 20:47:35 2001
From: ctackett at pirchplace.com (C. Tackett)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] ChanServ Question
Message-ID: <5.0.2.1.0.20010329234619.00a43dd0@scican.net>

Heya Folks!

I have a question :-)

How do you I get the ChanServ to join the channel when an IRCop asks to 
bring it in?
I just want the IRCops to have that power no one else..

If this can be done I would love to know!


Regards,

Chris Tackett - ctackett@pirchplace.com
The Pirch Place - http://www.PirchPlace.com
The Internet's Leading Pirch Community

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20010329/feff835d/attachment.html
From jpinto17 at visteon.com  Thu Mar 29 22:58:03 2001
From: jpinto17 at visteon.com (Pinto, Joao luis (J.M.))
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] ChanServ Question
Message-ID: <200103300658.f2U6wLX17595@dymwsm09.mailwatch.com>

Just
/OperServ raw :ChanServ JOIN #Chan
anyway you should not play with raw command, unless you know what you are
doing.

Lamego@PTlink.net
PTlink Tech Admin
http://www.ptlink.net

-----Original Message-----
From: C. Tackett [mailto:ctackett@pirchplace.com]
Sent: 30 March 2001 05:48
To: ircservices-coding@ircservices.za.net
Subject: [IRCServices Coding] ChanServ Question


Heya Folks!

I have a question :-)

How do you I get the ChanServ to join the channel when an IRCop asks to
bring it in?
I just want the IRCops to have that power no one else..

If this can be done I would love to know!


Regards,

Chris Tackett - ctackett@pirchplace.com
The Pirch Place - http://www.PirchPlace.com
The Internet's Leading Pirch Community



From achurch at achurch.org  Thu Dec 13 23:22:05 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Version 5.0 alpha release available
Message-ID: <3c18b9d4.67533@achurch.org>

     Well, it's taken a while, but Services 5.0 has finally begun to take a
reasonable shape (other than "completely jumbled and in little teensy bits")
and I've decided to release a public alpha test version.

     Before you all start jumping for joy, bear in mind that this is an
ALPHA TEST VERSION--this means that it is known to have bugs, and quite a
few of them, and is absolutely NOT for use on a production network.  About
the only thing that should work is compiling, and I won't even guarantee
that.  DO NOT DOWNLOAD THIS VERSION unless you intend to help find (and
fix!) bugs, or translate the new language files.  If I get any complaints
about an alpha release being broken, causing problems on someone's network,
or anything like that, I won't release any more alpha versions, and you'll
just have to wait longer.

     Furthermore, all discussion on the 5.0 alpha release should go to this
list, ircservices-coding.  Discussion (except possibly feature requests, if
I'm in a good mood) about the alpha release on this list will NOT be
tolerated, and offenders may be forcibly removed from the list.

     If you still want to download the alpha version, visit the Services
home page (http://www.ircservices.za.net/) for information.  (I won't post
a download link here because (1) it will change as versions go up, or if I
take it down entirely, and (2) I want people to see the warnings I put up
before downloading it.)

     Also, I'll be busy or out of town with year-end activities for most of
the rest of the year, so I may not be able to respond quickly to mail;
please be patient, as always.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

From mark at mhetherington.demon.co.uk  Thu Dec 13 14:42:45 2001
From: mark at mhetherington.demon.co.uk (Mark Hetherington)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Services 5
Message-ID: <NFBBKFAFGLNBHGEDBKDMMEGACHAA.mark@mhetherington.demon.co.uk>

Firstly, thanks to Andrew for releasing the alpha version. Hopefully he will
not feel that he has to later remove this opportunity.

A few early questions that maybe Andrew or the Alpha team might be able to
comment on.

1) Do we have any idea on time scale for development beyond alpha? I
understand that it is a difficult question to answer given RL committments
but based on work so far and this extended open test hopefully highlighting
major issues quite quickly, might make it easier to provide an estimate.

2) Despite the warning not to run the alpha on a production network, it does
seem to be the best place to run it since it will give a much more realistic
test of the code. It is also very tempting to upgrade :) To this end, are
there specific known issues at this time with the current build that would
make it completely impractical to run on a small production network? The
"knownbugs" file does not seem to have anything specific to Services 5 and
nothing serious mentioned either way but those who have already had chance
to play with Services 5 may have a good idea of things that would make it
unsuitable for risking in a production environment.

3) At present we seem to be restricted to the mailing list for bug reporting
and discussion which makes the process qyute closed. Has there been any
thought given to providing some kind of online tracking system which would
both show what bugs are currently known and their status? Maybe something on
sourceforge or similar system would suffice.

4) I was wondering about the reasons for AJOIN being included in Services 5.
It seems to place an overhead on NickServ that has been handled by many IRC
clients for a number of years. Even clients which do not specifically
support it, but that implement perform can easily provide AJOIN
functionality. Any client supporting scripting could easily manage an AJOIN
list. A number of clients support dynamic AJOIN lists by offering to
remember hannels that a user uses on a regular basis.

Since part of the ethos behind IRC Services development is not to perform
tasks that really belong in IRCd or in clients or could be scripted, it
seems odd that firstly this system has been implemented and secondly it is
enabled in a default configuration.

Is there something specific that I am missing about this services managed
auto join list which makes it preferable to the existing client code which
already performs this task?


Anyway, back to play around with the source some more.

Mark.


From beng at nc.rr.com  Thu Dec 13 15:04:37 2001
From: beng at nc.rr.com (Ben Goldstein)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Alpha compile error
Message-ID: <005a01c1842a$8a36e1f0$0300a8c0@asi200>

gcc -DCLEAN_COMPILE -O2 -Wall -Wmissing-prototypes -g -I../.. -c set.c -o
set.o
set.c: In function `do_set_timezone':
set.c:487: wrong type argument to unary minus
set.c:447: warning: `j' might be used uninitialized in this function

487:        j = ngi->timezone*60 - (-timezone);

I'm not sure what this is even doing, I havn't dug into the code.  But it
doesn't seem that "timezone" alone is the correct var you meant to use here.

-- Ben Goldstein (beng@nc.rr.com)

bash-2.05$ uname -a
FreeBSD raider 4.4-20010827-RC2 FreeBSD 4.4-20010827-RC2 #4: Fri Nov 16
14:57:04 EST 2001     root@raider:/usr/obj/usr/src/sys/BG1  i386
bash-2.05$ gmake -ver
GNU Make version 3.79, by Richard Stallman and Roland McGrath.
Built for i386-unknown-freebsdelf4.4
Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99
        Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

Report bugs to <bug-make@gnu.org>.



From griever at t2n.org  Thu Dec 13 17:53:11 2001
From: griever at t2n.org (Finny Merrill)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] REHASH help
Message-ID: <Pine.LNX.4.33.0112131952340.28410-100000@linux.ircd-net.org>

the restricted to services admins line has a tab char at the end.



From zogg at pcisys.net  Thu Dec 13 18:36:16 2001
From: zogg at pcisys.net (Ryan Riley)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] v5.0a7 - sline module
Message-ID: <3C1965A0.3000409@pcisys.net>

I just grabbed a copy of Alpha7 for a night of fun testing, but I've run 
into an issue.  I did the standard install, modified the 2 example 
configs to fit my needs, and I get this on startup:
[irc@zogg bin]$ ./services -nofork
[Dec 13 21:30:09 2001] Services 5.0a7 starting up
[Dec 13 21:30:09 2001] modules.conf:180: Unknown directive `LogMaxUsers'
[Dec 13 21:30:09 2001] modules.conf:226: Unknown directive `WallGetpass'
[Dec 13 21:30:09 2001] modules.conf:233: Unknown directive `WallSetpass'
[Dec 13 21:30:09 2001] modules: Unable to load module `operserv/sline': 
/home/irc/devel/services/bin/lib/modules/operserv/sline.so: undefined 
symbol: protocol_features
[Dec 13 21:30:09 2001] FATAL: Error loading modules, aborting

That undefined symbol error doesn't pass by me as being a good thing, so 
I figured I'd mention it here.  
I've tried commenting out all of the operserv/sline references in 
modules.conf, but it attempts to load it anyway.  (I haven't taken a 
dive into the source yet to figure out how the new module system works, 
so this could very well be normal.)
I'm on a RedHat 7.1 machine if that makes a difference.

Thanks
Ryan Riley



From grenday288 at geocities.com  Thu Dec 13 20:36:09 2001
From: grenday288 at geocities.com (Josh)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Alpha compile error
In-Reply-To: <005a01c1842a$8a36e1f0$0300a8c0@asi200>
Message-ID: <3C192D59.13694.1989660C@localhost>

On 13 Dec 2001, at 18:04, Ben Goldstein wrote:

change like 487 in set.c to
  j = (ngi->timezone*60 - u->ngi->timezone);
Im pretty sure thats not what its suppose to be but its only for 
timestamp stuff and still compiles (didnt try running it yet).

> gcc -DCLEAN_COMPILE -O2 -Wall -Wmissing-prototypes -g -I../.. -c set.c -o
> set.o
> set.c: In function `do_set_timezone':
> set.c:487: wrong type argument to unary minus
> set.c:447: warning: `j' might be used uninitialized in this function
> 
> 487:        j = ngi->timezone*60 - (-timezone);
> 
> I'm not sure what this is even doing, I havn't dug into the code.  But it
> doesn't seem that "timezone" alone is the correct var you meant to use here.
> 
> -- Ben Goldstein (beng@nc.rr.com)
> 
> bash-2.05$ uname -a
> FreeBSD raider 4.4-20010827-RC2 FreeBSD 4.4-20010827-RC2 #4: Fri Nov 16
> 14:57:04 EST 2001     root@raider:/usr/obj/usr/src/sys/BG1  i386
> bash-2.05$ gmake -ver
> GNU Make version 3.79, by Richard Stallman and Roland McGrath.
> Built for i386-unknown-freebsdelf4.4
> Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99
>         Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
> 
> Report bugs to <bug-make@gnu.org>.
> 
> 
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding


-------------------------------------
-- Josh Kirkorian [aka Poison-X]
-- Administrator - irc.insiderz.net

C Code. C code run. Run, code, run... 
Segmentation fault (core dumped).. aww shit

From andrewk at isdial.net  Thu Dec 13 22:41:19 2001
From: andrewk at isdial.net (Andrew Kempe)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Services 5
References: <NFBBKFAFGLNBHGEDBKDMMEGACHAA.mark@mhetherington.demon.co.uk>
Message-ID: <004901c1846a$56734800$9c011ac4@africa.didata.local>

> 3) At present we seem to be restricted to the mailing list for bug
reporting
> and discussion which makes the process qyute closed. Has there been any
> thought given to providing some kind of online tracking system which would
> both show what bugs are currently known and their status? Maybe something
on
> sourceforge or similar system would suffice.

I setup a very basic source forge project for services a while back, but
have not been maintaining it. If Andrew is willing to use SF for bug
tracking, I'm more than willing to start maintaining the project there. But
it's up to Andrew, as he's the one who will be updating what has been
changed/fixed.

Andrew


From rg at tcslon.com  Fri Dec 14 01:07:59 2001
From: rg at tcslon.com (Russell Garrett)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Services 5
In-Reply-To: <004901c1846a$56734800$9c011ac4@africa.didata.local>
Message-ID: <NDBBLDHKLKMANPGMACIGCEKLCMAA.rg@tcslon.com>

Just first comments on this:

For an alpha, it looks great, I would put it on my (small) production
network would it be for a rather annoying bug:

IRCServices 5 seems to have a few problems shutting down... on one of
my servers, it dumped 16Mb of "Server Segfaulting" messages to the
log before dying, and on the second attempt dumped a similar amount
to SNotices (granted it gave my test network a good load test ;) On
my other server, it sapped up all the CPU, and required a reboot. (I
was stopping services both by /squitting and by SIGTERM).

Other than that, I love it :) The mailing features look pretty swish,
and although I haven't looked at the modules much, it looks good.

Keep up the good work,


Russ Garrett (russ@garrett.co.uk)


From achurch at achurch.org  Fri Dec 14 18:43:37 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Services 5
Message-ID: <3c19ca25.04274@achurch.org>

     Looks like this didn't get through the first time, so:

1) No, because I have no clue how many bugs will turn up ;)  At this point
I'm tempted to say beta in February and stable release in April or so, but
I have absolutely no basis for saying that, so don't quote me on it.

2) The notice is intended more for lamers who say "ooh it's version 5!" and
rush to download it.  Feel free to use it on your production network, as
long as you take responsibility for any problems it causes.  There aren't
too many major issues right now that I can think of, but it's the ones I
haven't found yet that worry me more.  (One major issue I do know of is
that rehashing modules.conf doesn't work yet and could easily break
things.)

3) Not really, mostly because it would be a pain to set up and manage.
I may set something up once 5.0 has gone stable, but until then it's just
too much to deal with.  And I want absolutely nothing to do with the
piece-of-shit-formerly-known-as-Sourceforge.

4) For autojoin in particular, it was pointed out to me that not everyone
always accesses IRC from the same computer, which would make client
settings irrelevant.  In general, though, with the module system, I'm a bit
more lenient in terms of what I'll let in, since you can just disable
modules you don't need.  (And the reason for almost everything being
enabled in the default config is so you'll all test them for me. ;)  Some
will probably be disabled in beta/final releases.)

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

>Firstly, thanks to Andrew for releasing the alpha version. Hopefully he will
>not feel that he has to later remove this opportunity.
>
>A few early questions that maybe Andrew or the Alpha team might be able to
>comment on.
>
>1) Do we have any idea on time scale for development beyond alpha? I
>understand that it is a difficult question to answer given RL committments
>but based on work so far and this extended open test hopefully highlighting
>major issues quite quickly, might make it easier to provide an estimate.
>
>2) Despite the warning not to run the alpha on a production network, it does
>seem to be the best place to run it since it will give a much more realistic
>test of the code. It is also very tempting to upgrade :) To this end, are
>there specific known issues at this time with the current build that would
>make it completely impractical to run on a small production network? The
>"knownbugs" file does not seem to have anything specific to Services 5 and
>nothing serious mentioned either way but those who have already had chance
>to play with Services 5 may have a good idea of things that would make it
>unsuitable for risking in a production environment.
>
>3) At present we seem to be restricted to the mailing list for bug reporting
>and discussion which makes the process qyute closed. Has there been any
>thought given to providing some kind of online tracking system which would
>both show what bugs are currently known and their status? Maybe something on
>sourceforge or similar system would suffice.
>
>4) I was wondering about the reasons for AJOIN being included in Services 5.
>It seems to place an overhead on NickServ that has been handled by many IRC
>clients for a number of years. Even clients which do not specifically
>support it, but that implement perform can easily provide AJOIN
>functionality. Any client supporting scripting could easily manage an AJOIN
>list. A number of clients support dynamic AJOIN lists by offering to
>remember hannels that a user uses on a regular basis.
>
>Since part of the ethos behind IRC Services development is not to perform
>tasks that really belong in IRCd or in clients or could be scripted, it
>seems odd that firstly this system has been implemented and secondly it is
>enabled in a default configuration.
>
>Is there something specific that I am missing about this services managed
>auto join list which makes it preferable to the existing client code which
>already performs this task?
>
>
>Anyway, back to play around with the source some more.
>
>Mark.
>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding

From jpinto17 at visteon.com  Fri Dec 14 03:57:50 2001
From: jpinto17 at visteon.com (Pinto, Joao luis (J.M.))
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Services 5
Message-ID: <200112141157.fBEBvrn13721@dymwsm11.mailwatch.com>

I hope other people don't know so much about ircservices as you know about
sourceforge. You probably wouldn't like to see your project  named as
piece-of-shit-formerly-known-as-irc-services.

>3) Not really, mostly because it would be a pain to set up and manage.
>I may set something up once 5.0 has gone stable, but until then it's just
>too much to deal with.  And I want absolutely nothing to do with the
>piece-of-shit-formerly-known-as-Sourceforge.

Joao Pinto
Lamego@PTlink.net


-----Original Message-----
From: achurch@achurch.org [mailto:achurch@achurch.org]
Sent: 14 December 2001 09:44
To: ircservices-coding@ircservices.za.net
Subject: Re: [IRCServices Coding] Services 5


     Looks like this didn't get through the first time, so:

1) No, because I have no clue how many bugs will turn up ;)  At this point
I'm tempted to say beta in February and stable release in April or so, but
I have absolutely no basis for saying that, so don't quote me on it.

2) The notice is intended more for lamers who say "ooh it's version 5!" and
rush to download it.  Feel free to use it on your production network, as
long as you take responsibility for any problems it causes.  There aren't
too many major issues right now that I can think of, but it's the ones I
haven't found yet that worry me more.  (One major issue I do know of is
that rehashing modules.conf doesn't work yet and could easily break
things.)

3) Not really, mostly because it would be a pain to set up and manage.
I may set something up once 5.0 has gone stable, but until then it's just
too much to deal with.  And I want absolutely nothing to do with the
piece-of-shit-formerly-known-as-Sourceforge.

4) For autojoin in particular, it was pointed out to me that not everyone
always accesses IRC from the same computer, which would make client
settings irrelevant.  In general, though, with the module system, I'm a bit
more lenient in terms of what I'll let in, since you can just disable
modules you don't need.  (And the reason for almost everything being
enabled in the default config is so you'll all test them for me. ;)  Some
will probably be disabled in beta/final releases.)

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

>Firstly, thanks to Andrew for releasing the alpha version. Hopefully he
will
>not feel that he has to later remove this opportunity.
>
>A few early questions that maybe Andrew or the Alpha team might be able to
>comment on.
>
>1) Do we have any idea on time scale for development beyond alpha? I
>understand that it is a difficult question to answer given RL committments
>but based on work so far and this extended open test hopefully highlighting
>major issues quite quickly, might make it easier to provide an estimate.
>
>2) Despite the warning not to run the alpha on a production network, it
does
>seem to be the best place to run it since it will give a much more
realistic
>test of the code. It is also very tempting to upgrade :) To this end, are
>there specific known issues at this time with the current build that would
>make it completely impractical to run on a small production network? The
>"knownbugs" file does not seem to have anything specific to Services 5 and
>nothing serious mentioned either way but those who have already had chance
>to play with Services 5 may have a good idea of things that would make it
>unsuitable for risking in a production environment.
>
>3) At present we seem to be restricted to the mailing list for bug
reporting
>and discussion which makes the process qyute closed. Has there been any
>thought given to providing some kind of online tracking system which would
>both show what bugs are currently known and their status? Maybe something
on
>sourceforge or similar system would suffice.
>
>4) I was wondering about the reasons for AJOIN being included in Services
5.
>It seems to place an overhead on NickServ that has been handled by many IRC
>clients for a number of years. Even clients which do not specifically
>support it, but that implement perform can easily provide AJOIN
>functionality. Any client supporting scripting could easily manage an AJOIN
>list. A number of clients support dynamic AJOIN lists by offering to
>remember hannels that a user uses on a regular basis.
>
>Since part of the ethos behind IRC Services development is not to perform
>tasks that really belong in IRCd or in clients or could be scripted, it
>seems odd that firstly this system has been implemented and secondly it is
>enabled in a default configuration.
>
>Is there something specific that I am missing about this services managed
>auto join list which makes it preferable to the existing client code which
>already performs this task?
>
>
>Anyway, back to play around with the source some more.
>
>Mark.
>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
------------------------------------------------------------------
To unsubscribe or change your subscription options, visit:
http://www.ircservices.za.net/mailman/listinfo/ircservices-coding

From Georges at Berscheid.lu  Fri Dec 14 05:06:05 2001
From: Georges at Berscheid.lu (Georges Berscheid)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Version 5 (feature request)
Message-ID: <3C19F93D.D937F198@Berscheid.lu>

Hi,

1. what about adding a command to dynamically load/unload modules
without having to restart/rehash services (e.g. /operserv
loadmod|unloadmod <modulename>) ?
2. would it be possible to add an include function for modules.conf so
each module (evt. coming in a package) could have its own config file.
3. a dynamic way to include language files for modules would also be
great, instead of having to insert your module-specific strings to a .l
file and recompiling the whole stuff.

Greetings

Georges


From achurch at achurch.org  Sat Dec 15 00:02:16 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Services 5
Message-ID: <3c1a14fb.04335@achurch.org>

>I hope other people don't know so much about ircservices as you know about
>sourceforge. You probably wouldn't like to see your project  named as
>piece-of-shit-formerly-known-as-irc-services.

     Everyone's entitled to their opinions, and I suspect someone with that
opinion wouldn't be using it in the first place so I'd never have to deal
with them anyway.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

>>3) Not really, mostly because it would be a pain to set up and manage.
>>I may set something up once 5.0 has gone stable, but until then it's just
>>too much to deal with.  And I want absolutely nothing to do with the
>>piece-of-shit-formerly-known-as-Sourceforge.
>
>Joao Pinto
>Lamego@PTlink.net
>
>
>-----Original Message-----
>From: achurch@achurch.org [mailto:achurch@achurch.org]
>Sent: 14 December 2001 09:44
>To: ircservices-coding@ircservices.za.net
>Subject: Re: [IRCServices Coding] Services 5
>
>
>     Looks like this didn't get through the first time, so:
>
>1) No, because I have no clue how many bugs will turn up ;)  At this point
>I'm tempted to say beta in February and stable release in April or so, but
>I have absolutely no basis for saying that, so don't quote me on it.
>
>2) The notice is intended more for lamers who say "ooh it's version 5!" and
>rush to download it.  Feel free to use it on your production network, as
>long as you take responsibility for any problems it causes.  There aren't
>too many major issues right now that I can think of, but it's the ones I
>haven't found yet that worry me more.  (One major issue I do know of is
>that rehashing modules.conf doesn't work yet and could easily break
>things.)
>
>3) Not really, mostly because it would be a pain to set up and manage.
>I may set something up once 5.0 has gone stable, but until then it's just
>too much to deal with.  And I want absolutely nothing to do with the
>piece-of-shit-formerly-known-as-Sourceforge.
>
>4) For autojoin in particular, it was pointed out to me that not everyone
>always accesses IRC from the same computer, which would make client
>settings irrelevant.  In general, though, with the module system, I'm a bit
>more lenient in terms of what I'll let in, since you can just disable
>modules you don't need.  (And the reason for almost everything being
>enabled in the default config is so you'll all test them for me. ;)  Some
>will probably be disabled in beta/final releases.)
>
>  --Andrew Church
>    achurch@achurch.org
>    http://achurch.org/
>
>>Firstly, thanks to Andrew for releasing the alpha version. Hopefully he
>will
>>not feel that he has to later remove this opportunity.
>>
>>A few early questions that maybe Andrew or the Alpha team might be able to
>>comment on.
>>
>>1) Do we have any idea on time scale for development beyond alpha? I
>>understand that it is a difficult question to answer given RL committments
>>but based on work so far and this extended open test hopefully highlighting
>>major issues quite quickly, might make it easier to provide an estimate.
>>
>>2) Despite the warning not to run the alpha on a production network, it
>does
>>seem to be the best place to run it since it will give a much more
>realistic
>>test of the code. It is also very tempting to upgrade :) To this end, are
>>there specific known issues at this time with the current build that would
>>make it completely impractical to run on a small production network? The
>>"knownbugs" file does not seem to have anything specific to Services 5 and
>>nothing serious mentioned either way but those who have already had chance
>>to play with Services 5 may have a good idea of things that would make it
>>unsuitable for risking in a production environment.
>>
>>3) At present we seem to be restricted to the mailing list for bug
>reporting
>>and discussion which makes the process qyute closed. Has there been any
>>thought given to providing some kind of online tracking system which would
>>both show what bugs are currently known and their status? Maybe something
>on
>>sourceforge or similar system would suffice.
>>
>>4) I was wondering about the reasons for AJOIN being included in Services
>5.
>>It seems to place an overhead on NickServ that has been handled by many IRC
>>clients for a number of years. Even clients which do not specifically
>>support it, but that implement perform can easily provide AJOIN
>>functionality. Any client supporting scripting could easily manage an AJOIN
>>list. A number of clients support dynamic AJOIN lists by offering to
>>remember hannels that a user uses on a regular basis.
>>
>>Since part of the ethos behind IRC Services development is not to perform
>>tasks that really belong in IRCd or in clients or could be scripted, it
>>seems odd that firstly this system has been implemented and secondly it is
>>enabled in a default configuration.
>>
>>Is there something specific that I am missing about this services managed
>>auto join list which makes it preferable to the existing client code which
>>already performs this task?
>>
>>
>>Anyway, back to play around with the source some more.
>>
>>Mark.
>>
>>------------------------------------------------------------------
>>To unsubscribe or change your subscription options, visit:
>>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding

From achurch at achurch.org  Sat Dec 15 00:04:56 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Version 5 (feature request)
Message-ID: <3c1a15c3.04346@achurch.org>

     All of these are things I've been thinking about, but either haven't
gotten around to implementing yet or have decided to hold off on for the
next version.  With regard to language files in particular, I haven't come
up with a good implementation yet for per-module language strings, but I
figure that at least initially, people who contribute modules will do so
with one language only (their own) so it's not that big of a deal.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

>Hi,
>
>1. what about adding a command to dynamically load/unload modules
>without having to restart/rehash services (e.g. /operserv
>loadmod|unloadmod <modulename>) ?
>2. would it be possible to add an include function for modules.conf so
>each module (evt. coming in a package) could have its own config file.
>3. a dynamic way to include language files for modules would also be
>great, instead of having to insert your module-specific strings to a .l
>file and recompiling the whole stuff.
>
>Greetings
>
>Georges
>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding

From mark at mhetherington.demon.co.uk  Fri Dec 14 07:51:22 2001
From: mark at mhetherington.demon.co.uk (Mark Hetherington)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] v5.0a7 - sline module
In-Reply-To: <3C1965A0.3000409@pcisys.net>
Message-ID: <NFBBKFAFGLNBHGEDBKDMOEGNCHAA.mark@mhetherington.demon.co.uk>

Had similar problems myself. After some digging, it seems the reason for the
'unknown directives' is that they are stored in the table for the main
configuration (services.conf parser init.c) rather than the module
configuration (modules.conf parser operserv/main.c) so when parsing the
operserv directives, the configuration parser has no access to their
definitions. The configuration reoutine seems to ignore errors such as this
so ultimately it should not stop services coming online, but I will result
in those directives being ignored.

Maybe the message should be altered to 'Ignored unknown directive %s' or
'Unknown directive %s ignored'

It may be a rather trivial cut/paste to address the issue but I have not
investigated this any further at this time.

The sline problem you have experienced suggests you have not loaded a
protocol for services. Check services.conf and add in an appropriate
LoadModule protocol/protocolname. See the comments in that section for
information.


Mark.

> -----Original Message-----
> From: ircservices-coding-admin@ircservices.za.net
> [mailto:ircservices-coding-admin@ircservices.za.net]On Behalf Of Ryan
> Riley
> Sent: 14 December 2001 02:36
> To: IRCServices-Coding@ircservices.za.net
> Subject: [IRCServices Coding] v5.0a7 - sline module
>
>
> I just grabbed a copy of Alpha7 for a night of fun testing, but I've run
> into an issue.  I did the standard install, modified the 2 example
> configs to fit my needs, and I get this on startup:
> [irc@zogg bin]$ ./services -nofork
> [Dec 13 21:30:09 2001] Services 5.0a7 starting up
> [Dec 13 21:30:09 2001] modules.conf:180: Unknown directive `LogMaxUsers'
> [Dec 13 21:30:09 2001] modules.conf:226: Unknown directive `WallGetpass'
> [Dec 13 21:30:09 2001] modules.conf:233: Unknown directive `WallSetpass'
> [Dec 13 21:30:09 2001] modules: Unable to load module `operserv/sline':
> /home/irc/devel/services/bin/lib/modules/operserv/sline.so: undefined
> symbol: protocol_features
> [Dec 13 21:30:09 2001] FATAL: Error loading modules, aborting
>
> That undefined symbol error doesn't pass by me as being a good thing, so
> I figured I'd mention it here.
> I've tried commenting out all of the operserv/sline references in
> modules.conf, but it attempts to load it anyway.  (I haven't taken a
> dive into the source yet to figure out how the new module system works,
> so this could very well be normal.)
> I'm on a RedHat 7.1 machine if that makes a difference.
>
> Thanks
> Ryan Riley
>
>
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding


From griever at t2n.org  Fri Dec 14 11:55:40 2001
From: griever at t2n.org (Finny Merrill)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Services 5
In-Reply-To: <NDBBLDHKLKMANPGMACIGCEKLCMAA.rg@tcslon.com>
Message-ID: <Pine.LNX.4.33.0112141355220.31857-100000@linux.ircd-net.org>

On Fri, 14 Dec 2001, Russell Garrett wrote:

> Just first comments on this:
> 
> For an alpha, it looks great, I would put it on my (small) production
> network would it be for a rather annoying bug:
> 
> IRCServices 5 seems to have a few problems shutting down... on one of
> my servers, it dumped 16Mb of "Server Segfaulting" messages to the
> log before dying, and on the second attempt dumped a similar amount
> to SNotices (granted it gave my test network a good load test ;) On
> my other server, it sapped up all the CPU, and required a reboot. (I
> was stopping services both by /squitting and by SIGTERM).
-dumpcore (may be to dashes) to ./configure
> 
> Other than that, I love it :) The mailing features look pretty swish,
> and although I haven't looked at the modules much, it looks good.
> 
> Keep up the good work,
> 
> 
> Russ Garrett (russ@garrett.co.uk)
> 
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
> 


From zogg at pcisys.net  Fri Dec 14 12:21:59 2001
From: zogg at pcisys.net (Ryan Riley)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Services 5
References: <Pine.LNX.4.33.0112141355220.31857-100000@linux.ircd-net.org>
Message-ID: <3C1A5F67.6080806@pcisys.net>

Here's a backtrace from that particuliar problem.

(gdb) bt
#0  0x4015ccbc in ?? ()
#1  0x080535fb in unload_module (module=0x812a0c8) at modules.c:406
#2  0x08053135 in modules_exit () at modules.c:109
#3  0x08051b90 in main (ac=1, av=0xbffffadc, envp=0xbffffae4) at main.c:406
#4  0x4003ce5e in __libc_start_main (main=0x805177c <main>, argc=1,
    ubp_av=0xbffffadc, init=0x804b9a4 <_init>, fini=0x8057bc0 <_fini>,
    rtld_fini=0x4000d3c4 <_dl_fini>, stack_end=0xbffffacc)
    at ../sysdeps/generic/libc-start.c:129

Thanks
Ryan

Finny Merrill wrote:

>On Fri, 14 Dec 2001, Russell Garrett wrote:
>
>>Just first comments on this:
>>
>>For an alpha, it looks great, I would put it on my (small) production
>>network would it be for a rather annoying bug:
>>
>>IRCServices 5 seems to have a few problems shutting down... on one of
>>my servers, it dumped 16Mb of "Server Segfaulting" messages to the
>>log before dying, and on the second attempt dumped a similar amount
>>to SNotices (granted it gave my test network a good load test ;) On
>>my other server, it sapped up all the CPU, and required a reboot. (I
>>was stopping services both by /squitting and by SIGTERM).
>>
>-dumpcore (may be to dashes) to ./configure
>
>>Other than that, I love it :) The mailing features look pretty swish,
>>and although I haven't looked at the modules much, it looks good.
>>
>>Keep up the good work,
>>
>>
>>Russ Garrett (russ@garrett.co.uk)
>>
>>------------------------------------------------------------------
>>To unsubscribe or change your subscription options, visit:
>>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
>>
>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
>
>




From v13 at priest.com  Fri Dec 14 12:12:44 2001
From: v13 at priest.com (v13@priest.com)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] coding... (svcs 5)
Message-ID: <200112142012.WAA03993@ppp0.the.forthnet.gr>

For services 5:

I believe code like this (from operserv/main.c: do_killclones() )

            if (match_usermask(clonemask, user) != 0) {
                char killreason[32];
                count++;
                snprintf(killreason, sizeof(killreason),
                         "Cloning [%d]", count);
                kill_user(NULL, user->nick, killreason);
            }

should exist in seperate functions like:

int kill_mask(const char *mask, const char *reason)
{
	int	count=0;
	User	*user;

        for (user = first_user(); user; user = next_user())
	{
		if (match_usermask(mask, user) != 0)
		{
			char	killreason[512];

			count++;
			snprintf(killreason, sizeof(killreason),
				(reason == NULL ? "Cloning [%d]" : reason),
				count);
			kill_user(NULL, user->nick, killreason);
		}
	}

	return(count);
}

3rd party modules should not use their own code for things like this, since
it exists allready.

<<V13>>

From beng at nc.rr.com  Fri Dec 14 14:37:40 2001
From: beng at nc.rr.com (Ben Goldstein)
Date: Sat Oct 23 23:09:11 2004
Subject: Fw: [IRCServices Coding] Alpha compile error
Message-ID: <008501c184ef$f0e600a0$0300a8c0@asi200>

I don't know if Andrew meant to send this here, but it might be helpful for
others.  When I compiled I omitted the line completely to supress the error.

-- Ben Goldstein (beng@nc.rr.com)

----- Original Message -----
From: "Andrew Church" <achurch@achurch.org>
To: <beng@nc.rr.com>
Sent: Thursday, December 13, 2001 9:04 PM
Subject: Re: [IRCServices Coding] Alpha compile error


> >gcc -DCLEAN_COMPILE -O2 -Wall -Wmissing-prototypes -g -I../.. -c set.c -o
> >set.o
> >set.c: In function `do_set_timezone':
> >set.c:487: wrong type argument to unary minus
> >set.c:447: warning: `j' might be used uninitialized in this function
> >
> >487:        j = ngi->timezone*60 - (-timezone);
> >
> >I'm not sure what this is even doing, I havn't dug into the code.  But it
> >doesn't seem that "timezone" alone is the correct var you meant to use
here.
>
>      Actually, it is, but it looks like it's not portable; I'll make a
> workaround for the next release.  In the meantime, either use Linux or
just
> remove the "- (-timezone)" (it's code for a case that should never happen
> anyway, so it shouldn't matter too much).
>
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/
>
> >-- Ben Goldstein (beng@nc.rr.com)




From achurch at achurch.org  Sat Dec 15 10:45:50 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] coding... (svcs 5)
Message-ID: <3c1aab53.04477@achurch.org>

     Not worth it.

>For services 5:
>
>I believe code like this (from operserv/main.c: do_killclones() )
>
>            if (match_usermask(clonemask, user) != 0) {
>                char killreason[32];
>                count++;
>                snprintf(killreason, sizeof(killreason),
>                         "Cloning [%d]", count);
>                kill_user(NULL, user->nick, killreason);
>            }
>
>should exist in seperate functions like:
>
>int kill_mask(const char *mask, const char *reason)
>{
>	int	count=0;
>	User	*user;
>
>        for (user = first_user(); user; user = next_user())
>	{
>		if (match_usermask(mask, user) != 0)
>		{
>			char	killreason[512];
>
>			count++;
>			snprintf(killreason, sizeof(killreason),
>				(reason == NULL ? "Cloning [%d]" : reason),
>				count);
>			kill_user(NULL, user->nick, killreason);
>		}
>	}
>
>	return(count);
>}
>
>3rd party modules should not use their own code for things like this, sin
>ce
>it exists allready.
>
><<V13>>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

From stsimb at irc.gr  Sat Dec 15 11:23:02 2001
From: stsimb at irc.gr (Sotiris Tsimbonis)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] coding... (svcs 5)
In-Reply-To: <3c1aab53.04477@achurch.org>
Message-ID: <Pine.LNX.4.43.0112152119540.14976-100000@nana.forthnet.gr>

On Sat, 15 Dec 2001, Andrew Church wrote:
> >For services 5:
> >I believe code like this (from operserv/main.c: do_killclones() )
[...]
> >should exist in seperate functions like:
> >int kill_mask(const char *mask, const char *reason)
[...]
> >}
>
>      Not worth it.

Why not? Wouldn't this help code re-use in 3rd party modules? One wouldn't
have to re-invent the wheel, and if there was an error, it would only have
to be fixed in one place..

Sotiris.


From v13 at priest.com  Sat Dec 15 11:45:47 2001
From: v13 at priest.com (v13@priest.com)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] srvcs 5
Message-ID: <200112151945.VAA04508@ppp0.the.forthnet.gr>

 A note about callbacks:

Callbacks are nice when someone wants to add another function to services, 
but are no good, when someone wants to extend an existing one. 

I was trying to make nickserv to send one more line for the INFO command.
It is possible to return the line at the begining but not at the end.
I bypassed the strtok() problem, by duplicating the buffer to something like: 
"A INFO nick" and then calling strtok once, for this one. 
This way successive calls to strtok whould return the "INFO nick" part.
But it is not possible to call my function *AFTER* do_info. I tried to 
register my function with a higher priority and then call do_info from my 
function, but it was no good. get_module_symbol() cannot find do_info() 
(neither nickserv() ). I believe this is because of the static decleration of 
the functions.

Using "nm -g" it seems that those functions are not exported from the 
nickserv module. 

Is this going to change, or we should prepare for patching the main services 
code ?

<<V13>>

From griever at t2n.org  Sat Dec 15 12:12:48 2001
From: griever at t2n.org (Finny Merrill)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] srvcs 5
In-Reply-To: <200112151945.VAA04508@ppp0.the.forthnet.gr>
Message-ID: <Pine.LNX.4.33.0112151357060.4482-100000@linux.ircd-net.org>

On Sat, 15 Dec 2001 v13@priest.com wrote:

>  A note about callbacks:
> 
> Callbacks are nice when someone wants to add another function to services, 
> but are no good, when someone wants to extend an existing one. 
> 
> I was trying to make nickserv to send one more line for the INFO command.
*snip*


Command* lookup_cmd(Module* id, char* name)
will return the current Command* stucture for command name
which can then be removed and replaced, and you can call the function.
> 
> Using "nm -g" it seems that those functions are not exported from the 
> nickserv module. 
> 
> Is this going to change, or we should prepare for patching the main services 
> code ?

No need 
> <<V13>>
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
> 


From v13 at priest.com  Sat Dec 15 12:34:44 2001
From: v13 at priest.com (v13@priest.com)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] srvcs 5
In-Reply-To: <Pine.LNX.4.33.0112151357060.4482-100000@linux.ircd-net.org>
References: <Pine.LNX.4.33.0112151357060.4482-100000@linux.ircd-net.org>
Message-ID: <200112152034.WAA04723@ppp0.the.forthnet.gr>

On Saturday 15 December 2001 22:12, Finny Merrill wrote:
> Command* lookup_cmd(Module* id, char* name)
> will return the current Command* stucture for command name
> which can then be removed and replaced, and you can call the function.

Thanx. I got do_info() from 

(*(lookup_cmd(module_nickserv, "INFO")))->routine

and put my function there, which calls the old one before sending
anything to the user and it worked.

<<V13>>

From griever at t2n.org  Sat Dec 15 12:39:16 2001
From: griever at t2n.org (Finny Merrill)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] srvcs 5
In-Reply-To: <200112152034.WAA04723@ppp0.the.forthnet.gr>
Message-ID: <Pine.LNX.4.33.0112151438340.4879-100000@linux.ircd-net.org>

On Sat, 15 Dec 2001 v13@priest.com wrote:

> On Saturday 15 December 2001 22:12, Finny Merrill wrote:
> > Command* lookup_cmd(Module* id, char* name)
> > will return the current Command* stucture for command name
> > which can then be removed and replaced, and you can call the function.
> 
> Thanx. I got do_info() from 
> 
> (*(lookup_cmd(module_nickserv, "INFO")))->routine

personally I think this would be a safer way:

Command *temp;
temp = lookup_cmd(module_nickserv, "INFO);
temp->routine(...);


> 
> and put my function there, which calls the old one before sending
> anything to the user and it worked.
> 
> <<V13>>
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
> 


From v13 at priest.com  Sun Dec 16 12:50:03 2001
From: v13 at priest.com (v13@priest.com)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] svcs 5
Message-ID: <200112162050.WAA04418@ppp0.the.forthnet.gr>

The definition of "receive message" callback is wrong in the documentation
It says:

Parameters: char *source, int ac, char **av 

It should be:
Parameters: char *source, char *cmd, int ac, char **av 

in the protocol sources, the functions for this callback are declared as:
static int do_receive_message(char *source, char *cmd, int ac, char **av)

<<V13>>

From v13 at priest.com  Sun Dec 16 14:20:32 2001
From: v13 at priest.com (v13@priest.com)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] svcs5
Message-ID: <200112162220.AAA04668@ppp0.the.forthnet.gr>

in messages.c:

static void m_time(char *source, int ac, char **av)
{
    time_t t;
    struct tm *tm;
    char buf[64];

    time(&t);
    tm = localtime(&t);
    strftime(buf, sizeof(buf), "%a %b %d %H:%M:%S %Y %Z", tm);
    send_cmd(NULL, "391 :%s", buf);
}

This should be: 

send_cmd(NULL, "391 %s %s :%s", source, ServerName, buf);

or something like that...

<<V13>>

From achurch at achurch.org  Mon Dec 17 07:17:25 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] coding... (svcs 5)
Message-ID: <3c1d2138.07054@achurch.org>

>On Sat, 15 Dec 2001, Andrew Church wrote:
>> >For services 5:
>> >I believe code like this (from operserv/main.c: do_killclones() )
>[...]
>> >should exist in seperate functions like:
>> >int kill_mask(const char *mask, const char *reason)
>[...]
>> >}
>>
>>      Not worth it.
>
>Why not? Wouldn't this help code re-use in 3rd party modules? One wouldn't
>have to re-invent the wheel, and if there was an error, it would only have
>to be fixed in one place..

     If it was actually being used in multiple places, I'd agree with you,
but (unless I'm forgetting somewhere) it's not, and splitting the code up
anyway would be a waste of time.  If this actually becomes an issue later
I'll reconsider it then.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

From achurch at achurch.org  Mon Dec 17 07:33:50 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Services 5
Message-ID: <3c1d216e.07065@achurch.org>

>Here's a backtrace from that particuliar problem.
>
>(gdb) bt
>#0  0x4015ccbc in ?? ()
>#1  0x080535fb in unload_module (module=0x812a0c8) at modules.c:406
>#2  0x08053135 in modules_exit () at modules.c:109
>#3  0x08051b90 in main (ac=1, av=0xbffffadc, envp=0xbffffae4) at main.c:406
>#4  0x4003ce5e in __libc_start_main (main=0x805177c <main>, argc=1,
>    ubp_av=0xbffffadc, init=0x804b9a4 <_init>, fini=0x8057bc0 <_fini>,
>    rtld_fini=0x4000d3c4 <_dl_fini>, stack_end=0xbffffacc)
>    at ../sysdeps/generic/libc-start.c:129

     Looks like some module is forgetting to remove its callbacks.  Can you
play around with commenting/uncommenting your LoadModule directives in
services.conf until you find the module that causes the problem?

>Thanks
>Ryan
>
>Finny Merrill wrote:
>
>>On Fri, 14 Dec 2001, Russell Garrett wrote:
>>
>>>Just first comments on this:
>>>
>>>For an alpha, it looks great, I would put it on my (small) production
>>>network would it be for a rather annoying bug:
>>>
>>>IRCServices 5 seems to have a few problems shutting down... on one of
>>>my servers, it dumped 16Mb of "Server Segfaulting" messages to the
>>>log before dying, and on the second attempt dumped a similar amount
>>>to SNotices (granted it gave my test network a good load test ;) On
>>>my other server, it sapped up all the CPU, and required a reboot. (I
>>>was stopping services both by /squitting and by SIGTERM).
>>>
>>-dumpcore (may be to dashes) to ./configure
>>
>>>Other than that, I love it :) The mailing features look pretty swish,
>>>and although I haven't looked at the modules much, it looks good.
>>>
>>>Keep up the good work,
>>>
>>>
>>>Russ Garrett (russ@garrett.co.uk)
>>>
>>>------------------------------------------------------------------
>>>To unsubscribe or change your subscription options, visit:
>>>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
>>>
>>
>>------------------------------------------------------------------
>>To unsubscribe or change your subscription options, visit:
>>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
>>
>>
>
>
>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

From achurch at achurch.org  Mon Dec 17 07:34:29 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] srvcs 5
Message-ID: <3c1d21e1.07076@achurch.org>

> A note about callbacks:
>
>Callbacks are nice when someone wants to add another function to services, 
>but are no good, when someone wants to extend an existing one. 

     Don't use callbacks for this, use the command system (commands.[ch]).
The next alpha will have a `next' pointer in the command record which gets
filled in when you call register_commands(), so you can call the original
command's function directly.

>I was trying to make nickserv to send one more line for the INFO command.
>It is possible to return the line at the begining but not at the end.
>I bypassed the strtok() problem, by duplicating the buffer to something l
>ike: 
>"A INFO nick" and then calling strtok once, for this one. 
>This way successive calls to strtok whould return the "INFO nick" part.
>But it is not possible to call my function *AFTER* do_info. I tried to 
>register my function with a higher priority and then call do_info from my
> 
>function, but it was no good. get_module_symbol() cannot find do_info() 
>(neither nickserv() ). I believe this is because of the static decleratio
>n of 
>the functions.
>
>Using "nm -g" it seems that those functions are not exported from the 
>nickserv module. 
>
>Is this going to change, or we should prepare for patching the main servi
>ces 
>code ?
>
><<V13>>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

From v13 at priest.com  Sun Dec 16 14:49:58 2001
From: v13 at priest.com (v13@priest.com)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Services 5
In-Reply-To: <3c1d216e.07065@achurch.org>
References: <3c1d216e.07065@achurch.org>
Message-ID: <200112162249.AAA05350@ppp0.the.forthnet.gr>

On Monday 17 December 2001 09:33, Andrew Church wrote:
> >Here's a backtrace from that particuliar problem.
> >
> >(gdb) bt
> >#0  0x4015ccbc in ?? ()
> >#1  0x080535fb in unload_module (module=0x812a0c8) at modules.c:406
> >#2  0x08053135 in modules_exit () at modules.c:109
> >#3  0x08051b90 in main (ac=1, av=0xbffffadc, envp=0xbffffae4) at main.c:406
> >#4  0x4003ce5e in __libc_start_main (main=0x805177c <main>, argc=1,
> >    ubp_av=0xbffffadc, init=0x804b9a4 <_init>, fini=0x8057bc0 <_fini>,
> >    rtld_fini=0x4000d3c4 <_dl_fini>, stack_end=0xbffffacc)
> >    at ../sysdeps/generic/libc-start.c:129
> 
>      Looks like some module is forgetting to remove its callbacks.  Can you
> play around with commenting/uncommenting your LoadModule directives in
> services.conf until you find the module that causes the problem?

Trying an:

(gdb) up
(gdb) p module->name

whould show the module name

<<V13>>

From achurch at achurch.org  Mon Dec 17 07:55:16 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] svcs 5
Message-ID: <3c1d265c.07147@achurch.org>

>The definition of "receive message" callback is wrong in the documentatio
>n
>It says:
>
>Parameters: char *source, int ac, char **av 
>
>It should be:
>Parameters: char *source, char *cmd, int ac, char **av 

     Thanks, fixed.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

From achurch at achurch.org  Mon Dec 17 07:57:24 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Services 5
Message-ID: <3c1d2730.07170@achurch.org>

>On Monday 17 December 2001 09:33, Andrew Church wrote:
>> >Here's a backtrace from that particuliar problem.
>> >
>> >(gdb) bt
>> >#0  0x4015ccbc in ?? ()
>> >#1  0x080535fb in unload_module (module=0x812a0c8) at modules.c:406
>> >#2  0x08053135 in modules_exit () at modules.c:109
>> >#3  0x08051b90 in main (ac=1, av=0xbffffadc, envp=0xbffffae4) at
> main.c:406
>> >#4  0x4003ce5e in __libc_start_main (main=0x805177c <main>, argc=1
>,
>> >    ubp_av=0xbffffadc, init=0x804b9a4 <_init>, fini=0x8057bc0 <_
>fini>,
>> >    rtld_fini=0x4000d3c4 <_dl_fini>, stack_end=0xbffffacc)
>> >    at ../sysdeps/generic/libc-start.c:129
>> 
>>      Looks like some module is forgetting to remove its callbacks.  Can
> you
>> play around with commenting/uncommenting your LoadModule directives in
>> services.conf until you find the module that causes the problem?
>
>Trying an:
>
>(gdb) up
>(gdb) p module->name
>
>whould show the module name

     No, that would show the name of the module being unloaded, not the one
whose callback was being called.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

From v13 at priest.com  Sun Dec 16 17:09:35 2001
From: v13 at priest.com (v13@priest.com)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] svcs5
Message-ID: <200112170109.DAA07729@ppp0.the.forthnet.gr>

I don't understand this completely, but i get coredumps when
doing /msg chanserv levels #chan set ignore 6

it seems that there is something wrong...

in chanserv/util.c:

ChannelInfo *makechan(const char *chan)
{
    ChannelInfo *ci;

    ci = scalloc(sizeof(ChannelInfo), 1);
    strscpy(ci->name, chan, CHANMAX);
    ci->time_registered = time(NULL);
>>>>>    reset_levels(ci, 0);  <<<<<<
    return add_channelinfo(ci);
}

i bellieve this should be:
reset_levels(ci,1);


also in chanserv/access.c:

EXPORT_FUNC(reset_levels)
void reset_levels(ChannelInfo *ci, int set)
{
    int i;

>>>>>    free(ci->levels); <<<<<
    if (set) {
        ci->levels = scalloc(CA_SIZE, sizeof(*ci->levels));
        for (i = 0; i < CA_SIZE; i++)
            ci->levels[i] = def_levels[i];
    } else {
        ci->levels = NULL;
    }
}

this may try to free something that is not malloced (if i get this right)
when it is called from makechan() (free(NULL) works under glibc, but i don't
know how portable/standard it is)


finaly in chanserv/access-levels.c, in do_levels():

        for (i = 0; levelinfo[i].what >= 0; i++) {
            if (stricmp(levelinfo[i].name, what) == 0) {
                if (ci->levels)
                    reset_levels(ci, 1);
>>>>>                ci->levels[levelinfo[i].what] = level;  <<<<<<
                notice_lang(s_ChanServ, u, CHAN_LEVELS_CHANGED,
                        levelinfo[i].name, chan, level);
                put_channelinfo(ci);
                return;
            }
        }

the marked line is where i get the coredump...
it doesn't make any sense.. 
if ci->levels is NULL, then reset_levels is not called...
so it remains NULL and then ci->levels[] is used

(from gdb) (not wrapped)

(gdb) bt
#0  do_levels (u=0x814cf0c) at access-levels.c:324
#1  0x0804df4c in run_cmd (service=0x8144bd4 "ChanServ", u=0x814cf0c, id=0x81449c4, cmd=0xbffff5f2 "levels") at commands.c:158
#2  0x401a0070 in chanserv (source=0xbffff820 "V13", target=0xbffff5e8 "chanserv", buf=0xbffff5f2 "levels") at main.c:226
#3  0x08054cba in call_callback_5 (module=0x0, id=25, arg1=0xbffff820, arg2=0xbffff5e8, arg3=0xbffff5f2, arg4=0x0, arg5=0x0) at modules.c:605
#4  0x08052f3f in m_privmsg (source=0xbffff820 "V13", ac=2, av=0x814cd8c) at messages.c:169
#5  0x08055260 in process () at process.c:131
#6  0x08056395 in check_sockets () at sockets.c:362
#7  0x080526cc in main (ac=3, av=0xbffffa54, envp=0xbffffa64) at main.c:377
#8  0x4004d823 in __libc_start_main () from /lib/libc.so.6
(gdb) l access-levels.c:324
319             }
320             for (i = 0; levelinfo[i].what >= 0; i++) {
321                 if (stricmp(levelinfo[i].name, what) == 0) {
322                     if (ci->levels)
323                         reset_levels(ci, 1);
324                     ci->levels[levelinfo[i].what] = level;
325                     notice_lang(s_ChanServ, u, CHAN_LEVELS_CHANGED,
326                             levelinfo[i].name, chan, level);
327                     put_channelinfo(ci);
328                     return;
(gdb) p i
$1 = 224


<<V13>>

From achurch at achurch.org  Mon Dec 17 16:47:05 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] svcs5
Message-ID: <3c1da32d.07437@achurch.org>

>in messages.c:
>
>static void m_time(char *source, int ac, char **av)
>{
>    time_t t;
>    struct tm *tm;
>    char buf[64];
>
>    time(&t);
>    tm = localtime(&t);
>    strftime(buf, sizeof(buf), "%a %b %d %H:%M:%S %Y %Z", tm);
>    send_cmd(NULL, "391 :%s", buf);
>}
>
>This should be: 
>
>send_cmd(NULL, "391 %s %s :%s", source, ServerName, buf);
>
>or something like that...

     I could have sworn I fixed this at least once before... oh well.
Fixed (in the 4.5 branch as well), thanks.

><<V13>>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

From Georges at Berscheid.lu  Mon Dec 17 00:43:35 2001
From: Georges at Berscheid.lu (Georges Berscheid)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Services 5 having problems to shut down
Message-ID: <EMEAJDMIHJFMOHONHAEDMELPCDAA.Georges@Berscheid.lu>

Hi,

when I started services with a little error in my config file this happened:

[Dec 16 22:38:27 2001] Read error from server: Success
[Dec 16 22:38:27 2001] Services terminating: Segmentation fault
[Dec 16 22:38:27 2001] Services terminating: Segmentation fault
[Dec 16 22:38:27 2001] Services terminating: Segmentation fault

First, I didn't see that something was wrong, but suddenly many other
processes on the server crashed due to 'Out of memory'. That's what services
said 10 minutes later in the .log file as well. (At this point the .log file
had 290MB)

[Dec 16 22:48:15 2001] Out of memory!
[Dec 16 22:48:15 2001] Out of memory!
[Dec 16 22:48:15 2001] Out of memory!
[Dec 16 22:48:15 2001] Out of memory!

Seems like the get into an endless malloc-loop somewhere. Unfortunately
there is no core dump, because they were still alive after 10 minutes, and I
had to kill them through the console.

Georges


From rg at tcslon.com  Mon Dec 17 01:18:02 2001
From: rg at tcslon.com (Russell Garrett)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Services 5 having problems to shut down
In-Reply-To: <EMEAJDMIHJFMOHONHAEDMELPCDAA.Georges@Berscheid.lu>
Message-ID: <NDBBLDHKLKMANPGMACIGIEGBCNAA.rg@tcslon.com>

> when I started services with a little error in my config
> file this happened:
>
> [Dec 16 22:38:27 2001] Read error from server: Success
> [Dec 16 22:38:27 2001] Services terminating: Segmentation fault
> [Dec 16 22:38:27 2001] Services terminating: Segmentation fault
> [Dec 16 22:38:27 2001] Services terminating: Segmentation fault

I saw this too, I think, but I caught it before it ran out of
memory...

I'm still trying to find a computer to debug it on - I was previously
using a colocated server which I had no physical access to - a bad
move :)

Russ Garrett (russ@garrett.co.uk)


From achurch at achurch.org  Mon Dec 17 18:28:16 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Services 5 having problems to shut down
Message-ID: <3c1dbaf6.12326@achurch.org>

     The endless loop is fixed, thanks.  I'll look into the seg-fault later
(I suspect it's the same problem as was reported earlier).

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

>Hi,
>
>when I started services with a little error in my config file this happened:
>
>[Dec 16 22:38:27 2001] Read error from server: Success
>[Dec 16 22:38:27 2001] Services terminating: Segmentation fault
>[Dec 16 22:38:27 2001] Services terminating: Segmentation fault
>[Dec 16 22:38:27 2001] Services terminating: Segmentation fault
>
>First, I didn't see that something was wrong, but suddenly many other
>processes on the server crashed due to 'Out of memory'. That's what services
>said 10 minutes later in the .log file as well. (At this point the .log file
>had 290MB)
>
>[Dec 16 22:48:15 2001] Out of memory!
>[Dec 16 22:48:15 2001] Out of memory!
>[Dec 16 22:48:15 2001] Out of memory!
>[Dec 16 22:48:15 2001] Out of memory!
>
>Seems like the get into an endless malloc-loop somewhere. Unfortunately
>there is no core dump, because they were still alive after 10 minutes, and I
>had to kill them through the console.
>
>Georges
>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding

From v13 at priest.com  Mon Dec 17 05:47:22 2001
From: v13 at priest.com (v13@priest.com)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] akills
Message-ID: <200112171348.PAA02940@ppp0.the.forthnet.gr>

As of bahamut 1.4.29, s_serv.c -> m_akill() (in bahamut ircd sources)
has:

    /* whether or not we have a length, this is still a temporary akill */
    /* if the length is over a day, or nonexistant, we call this a 'forever'
     * akill and set ->hold to 0xFFFFFFFF to indicate such
     * this is a hack to prevent
     * forever akills from being removed unless by an explicit /rehash */
    if(length>86400 || !length)
        aconf->hold=0xFFFFFFFF;  
    else
        aconf->hold=timeset+length;

which means that akills whith expire time greater than a day, will never
expire, unless explicity removed. This way, netsplits may prevent akills
to be removed from servers, when services send the RAKILL. 

This can be bypassed, by forcing services to send AKILLs, with expire
time less than 86400 by 
changing (in operserv/akill.c send_akill() ):

call_callback_5(module, cb_send_akill,
		username, host, 
		akill->expires,
		akill->who,
		make_reason(AkillReason, akill));

to:

call_callback_5(module, cb_send_akill,
		username, host, 
		( (akill->expires - now) > 86399 ? now + 86399 : akill->expires),
		akill->who,
		make_reason(AkillReason, akill));

or better, change the callback in the bahamut protocol module:

static int do_send_akill(const char *username, const char *host,
                         time_t expires, const char *who, const char *reason)
{
    time_t now = time(NULL);

    send_cmd(ServerName, "AKILL %s %s %ld %s %ld :%s", host, username,
             (expires && expires > now) ? expires - now : 0,
             who ? who : "<unknown>", now, reason);
    return 1;
}

to:

static int do_send_akill(const char *username, const char *host,
                         time_t expires, const char *who, const char *reason)
{
	time_t now = time(NULL);

	if (expires>now)
	{
		expires-=now;
		if (expires>=86400)
			expires=86399;
	}

	send_cmd(ServerName, "AKILL %s %s %ld %s %ld :%s", host, username,
		expires, who ? who : "<unknown>", now, reason);
	return 1;
}

This way akills for 5 days, will be send up to 5 times on each server 
(Removed after 86399 seconds and send again when a matching user tries ti use 
the server). This should not add much overhead and non-expiring akills will 
not be affected.

<<V13>>

From achurch at achurch.org  Mon Dec 17 23:29:46 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] akills
Message-ID: <3c1e020e.15231@achurch.org>

>	if (expires>now)
>	{
>		expires-=now;
>		if (expires>=86400)
>			expires=86399;
>	}

     I see someone hasn't read the coding guidelines...

>This way akills for 5 days, will be send up to 5 times on each server 
>(Removed after 86399 seconds and send again when a matching user tries ti
> use 
>the server). This should not add much overhead and non-expiring akills wi
>ll 
>not be affected.

     I don't see why this is needed.  The autokills-don't-disappear-if-
server-is-split problem existed before the AKILL message got an expiry
time, and it was always solved by rehashing; I don't see why the same
approach can't be used with Bahamut as well.  IMNSHO, I think the current
(if that's current) behavior of Bahamut is buggy; since when does "one day
or more" equal "forever"?

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

From dooley at risanet.com  Mon Dec 17 11:01:26 2001
From: dooley at risanet.com (Dooley)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Services 5 having problems to shut down
References: <3c1dbaf6.12326@achurch.org>
Message-ID: <006501c1872d$40e593b0$dd91a8c0@criley>

Anyone know what the fix is for this as it would be nice to not have to
console kill it while playing.


Dooley

----- Original Message -----
From: "Andrew Church" <achurch@achurch.org>
To: <ircservices-coding@ircservices.za.net>
Sent: Monday, December 17, 2001 3:28 AM
Subject: Re: [IRCServices Coding] Services 5 having problems to shut down


>      The endless loop is fixed, thanks.  I'll look into the seg-fault
later
> (I suspect it's the same problem as was reported earlier).
>
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/
>
> >Hi,
> >
> >when I started services with a little error in my config file this
happened:
> >
> >[Dec 16 22:38:27 2001] Read error from server: Success
> >[Dec 16 22:38:27 2001] Services terminating: Segmentation fault
> >[Dec 16 22:38:27 2001] Services terminating: Segmentation fault
> >[Dec 16 22:38:27 2001] Services terminating: Segmentation fault
> >
> >First, I didn't see that something was wrong, but suddenly many other
> >processes on the server crashed due to 'Out of memory'. That's what
services
> >said 10 minutes later in the .log file as well. (At this point the .log
file
> >had 290MB)
> >
> >[Dec 16 22:48:15 2001] Out of memory!
> >[Dec 16 22:48:15 2001] Out of memory!
> >[Dec 16 22:48:15 2001] Out of memory!
> >[Dec 16 22:48:15 2001] Out of memory!
> >
> >Seems like the get into an endless malloc-loop somewhere. Unfortunately
> >there is no core dump, because they were still alive after 10 minutes,
and I
> >had to kill them through the console.
> >
> >Georges
> >
> >------------------------------------------------------------------
> >To unsubscribe or change your subscription options, visit:
> >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
>


From achurch at achurch.org  Thu Dec 20 14:21:43 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Services 5.0 alpha 8 released
Message-ID: <3c2175d6.46663@achurch.org>

     I've put up a new alpha tarball, alpha 8; it can be downloaded from
the same place as the last one (http://achurch.org/services/5.0-alpha/).
The crashing and infinite loop bugs reported before should be fixed, and
rehashing has now been added.  The change log is as follows:

2001/12/20 a8	SIGHUP now re-reads the configuration files instead of
		    restarting.
2001/12/20	SIGUSR2 no longer opens log file if it was closed before.
2001/12/20	Added reconfiguration support for modules.
2001/12/20	Renamed AkillReason config directive to AutokillReason.
2001/12/19	Fixed crash when unloading modules on exit.
2001/12/17	Fixed infinite loop on signal.  Reported by Georges
		    Berscheid <Georges@Berscheid.lu>
2001/12/14	Fixed various problems caused by signal timing.
2001/12/14	Fixed compile error on FreeBSD.  Reported by Ben Goldstein
		    <beng@nc.rr.com>

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

From Georges at Berscheid.lu  Thu Dec 20 03:10:23 2001
From: Georges at Berscheid.lu (Georges Berscheid)
Date: Sat Oct 23 23:09:11 2004
Subject: AW: [IRCServices Coding] Services 5.0 alpha 8 released
In-Reply-To: <3c2175d6.46663@achurch.org>
Message-ID: <EMEAJDMIHJFMOHONHAEDOEMJCDAA.Georges@Berscheid.lu>

Hi,

I just installed alpha8 and tried the new /operserv rehash function. But
unfortunately it segfaults every time.
gdb says:

#0  chunk_free (ar_ptr=0x464c457f, p=0x4007b9f8) at malloc.c:3049
#1  0x40076fba in __libc_free (mem=0x4007ba00) at malloc.c:3023
#2  0x804e84c in read_config_file (modulename=0x812e888 "statserv/main",
directives=0x4018444c) at conffile.c:380
#3  0x804ecbc in configure (modulename=0x812e888 "statserv/main",
directives=0x4018444c, action=1) at conffile.c:523
#4  0x80536b5 in reconfigure_modules () at modules.c:507
#5  0x80500aa in reconfigure () at init.c:802
#6  0x40134445 in do_rehash (u=0x8132128) at main.c:1071
#7  0x804dcaa in run_cmd (service=0x8129f40 "OperServ", u=0x8132128,
id=0x812aec0, cmd=0xbffff759 "rehash") at commands.c:175
#8  0x40132999 in operserv (source=0xbffff96c "Peiter", target=0xbffff734
"operserv", buf=0xbffff759 "rehash") at main.c:256
#9  0x80538bd in call_callback_5 (module=0x0, id=25, arg1=0xbffff96c,
arg2=0xbffff734, arg3=0xbffff759, arg4=0x0, arg5=0x0)
    at modules.c:612
#10 0x8051d35 in m_privmsg (source=0xbffff96c "Peiter", ac=2, av=0x8132050)
at messages.c:169
#11 0x8053e31 in process () at process.c:131
#12 0x8051581 in readline_callback (s=0x812f298, param_unused=0x3d) at
main.c:158
#13 0x805511f in check_sockets () at sockets.c:364
#14 0x805180d in main (ac=1, av=0xbffffb64, envp=0xbffffb6c) at main.c:260

Greetings

Georges

-----Ursprungliche Nachricht-----
Von: ircservices-coding-admin@ircservices.za.net
[mailto:ircservices-coding-admin@ircservices.za.net]Im Auftrag von Andrew
Church
Gesendet: Donnerstag, 20. Dezember 2001 06:22
An: ircservices-coding@ircservices.za.net
Betreff: [IRCServices Coding] Services 5.0 alpha 8 released


     I've put up a new alpha tarball, alpha 8; it can be downloaded from
the same place as the last one (http://achurch.org/services/5.0-alpha/).
The crashing and infinite loop bugs reported before should be fixed, and
rehashing has now been added.  The change log is as follows:

2001/12/20 a8	SIGHUP now re-reads the configuration files instead of
		    restarting.
2001/12/20	SIGUSR2 no longer opens log file if it was closed before.
2001/12/20	Added reconfiguration support for modules.
2001/12/20	Renamed AkillReason config directive to AutokillReason.
2001/12/19	Fixed crash when unloading modules on exit.
2001/12/17	Fixed infinite loop on signal.  Reported by Georges
		    Berscheid <Georges@Berscheid.lu>
2001/12/14	Fixed various problems caused by signal timing.
2001/12/14	Fixed compile error on FreeBSD.  Reported by Ben Goldstein
		    <beng@nc.rr.com>

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
------------------------------------------------------------------
To unsubscribe or change your subscription options, visit:
http://www.ircservices.za.net/mailman/listinfo/ircservices-coding


From achurch at achurch.org  Fri Dec 21 17:07:27 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:09:11 2004
Subject: AW: [IRCServices Coding] Services 5.0 alpha 8 released
Message-ID: <3c22edd9.01433@achurch.org>

>Hi,
>
>I just installed alpha8 and tried the new /operserv rehash function. But
>unfortunately it segfaults every time.

     Can you send me a copy of your services.conf and modules.conf?

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

>gdb says:
>
>#0  chunk_free (ar_ptr=0x464c457f, p=0x4007b9f8) at malloc.c:3049
>#1  0x40076fba in __libc_free (mem=0x4007ba00) at malloc.c:3023
>#2  0x804e84c in read_config_file (modulename=0x812e888 "statserv/main",
>directives=0x4018444c) at conffile.c:380
>#3  0x804ecbc in configure (modulename=0x812e888 "statserv/main",
>directives=0x4018444c, action=1) at conffile.c:523
>#4  0x80536b5 in reconfigure_modules () at modules.c:507
>#5  0x80500aa in reconfigure () at init.c:802
>#6  0x40134445 in do_rehash (u=0x8132128) at main.c:1071
>#7  0x804dcaa in run_cmd (service=0x8129f40 "OperServ", u=0x8132128,
>id=0x812aec0, cmd=0xbffff759 "rehash") at commands.c:175
>#8  0x40132999 in operserv (source=0xbffff96c "Peiter", target=0xbffff734
>"operserv", buf=0xbffff759 "rehash") at main.c:256
>#9  0x80538bd in call_callback_5 (module=0x0, id=25, arg1=0xbffff96c,
>arg2=0xbffff734, arg3=0xbffff759, arg4=0x0, arg5=0x0)
>    at modules.c:612
>#10 0x8051d35 in m_privmsg (source=0xbffff96c "Peiter", ac=2, av=0x8132050)
>at messages.c:169
>#11 0x8053e31 in process () at process.c:131
>#12 0x8051581 in readline_callback (s=0x812f298, param_unused=0x3d) at
>main.c:158
>#13 0x805511f in check_sockets () at sockets.c:364
>#14 0x805180d in main (ac=1, av=0xbffffb64, envp=0xbffffb6c) at main.c:260
>
>Greetings
>
>Georges
>
>-----Ursprungliche Nachricht-----
>Von: ircservices-coding-admin@ircservices.za.net
>[mailto:ircservices-coding-admin@ircservices.za.net]Im Auftrag von Andrew
>Church
>Gesendet: Donnerstag, 20. Dezember 2001 06:22
>An: ircservices-coding@ircservices.za.net
>Betreff: [IRCServices Coding] Services 5.0 alpha 8 released
>
>
>     I've put up a new alpha tarball, alpha 8; it can be downloaded from
>the same place as the last one (http://achurch.org/services/5.0-alpha/).
>The crashing and infinite loop bugs reported before should be fixed, and
>rehashing has now been added.  The change log is as follows:
>
>2001/12/20 a8	SIGHUP now re-reads the configuration files instead of
>		    restarting.
>2001/12/20	SIGUSR2 no longer opens log file if it was closed before.
>2001/12/20	Added reconfiguration support for modules.
>2001/12/20	Renamed AkillReason config directive to AutokillReason.
>2001/12/19	Fixed crash when unloading modules on exit.
>2001/12/17	Fixed infinite loop on signal.  Reported by Georges
>		    Berscheid <Georges@Berscheid.lu>
>2001/12/14	Fixed various problems caused by signal timing.
>2001/12/14	Fixed compile error on FreeBSD.  Reported by Ben Goldstein
>		    <beng@nc.rr.com>
>
>  --Andrew Church
>    achurch@achurch.org
>    http://achurch.org/
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding

From achurch at achurch.org  Sat Dec 22 00:40:23 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] svcs5
Message-ID: <3c235838.11277@achurch.org>

>this may try to free something that is not malloced (if i get this right)
>when it is called from makechan() (free(NULL) works under glibc, but i do
>n't
>know how portable/standard it is)

     I'm pretty sure that's standard, and if it turns out not to be I'll
just write my own free() because the rest of the code assumes it works
that way.

>finaly in chanserv/access-levels.c, in do_levels():
[snip]
>the marked line is where i get the coredump...
>it doesn't make any sense.. 
>if ci->levels is NULL, then reset_levels is not called...
>so it remains NULL and then ci->levels[] is used

     The test on ci->levels was backwards in sense.  Fixed, thanks.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

From griever at t2n.org  Fri Dec 21 11:51:00 2001
From: griever at t2n.org (Finny Merrill)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] svcs5
In-Reply-To: <3c235838.11277@achurch.org>
Message-ID: <Pine.LNX.4.33.0112211350500.20852-100000@linux.ircd-net.org>

On Sat, 22 Dec 2001, Andrew Church wrote:

> >this may try to free something that is not malloced (if i get this right)
> >when it is called from makechan() (free(NULL) works under glibc, but i do
> >n't
> >know how portable/standard it is)
> 
>      I'm pretty sure that's standard, and if it turns out not to be I'll
> just write my own free() because the rest of the code assumes it works
> that way.

ISO C guarantees free(NULL) is safe
> 
> >finaly in chanserv/access-levels.c, in do_levels():
> [snip]
> >the marked line is where i get the coredump...
> >it doesn't make any sense.. 
> >if ci->levels is NULL, then reset_levels is not called...
> >so it remains NULL and then ci->levels[] is used
> 
>      The test on ci->levels was backwards in sense.  Fixed, thanks.
> 
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
> 


From v13 at priest.com  Sat Dec 22 10:42:29 2001
From: v13 at priest.com (v13@priest.com)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] svc5 exception move
Message-ID: <200112221842.UAA04340@ppp0.the.forthnet.gr>

in operserv/sessions.c, do_exception_move():

    char *n1str = strtok(NULL, " ");    /* From index */
    char *n2str = strtok(NULL, " ");    /* To index */
    int n1, n2;

    if (!n2str) {
        syntax_error(s_OperServ, u, "EXCEPTION", OPER_EXCEPTION_MOVE_SYNTAX);
        return;
    }
    n1 = atoi(n1str) - 1;
    n2 = atoi(n2str) - 1;

>>>    if (n1 == n2 || n1 <= 0 || n2 <= 0) { <<< HERE <<<<<<<<<<<<<<<<<<<<

        syntax_error(s_OperServ, u, "EXCEPTION", OPER_EXCEPTION_MOVE_SYNTAX);
        return;
    }

I believe the noted line should not have <=
When trying to move exception #1 it fails and, when there are 3 exceptions:

/os exception move 4 3

gives:

-OperServ- Exception for *.hell.gr (#3) moved to number 2.

exception move also doesn't seem to work at all.

(tested under alpha7, but alpha8 hasn't change this)

<<V13>>

From griever at t2n.org  Sat Dec 22 17:27:28 2001
From: griever at t2n.org (Finny Merrill)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] unknown things
Message-ID: <Pine.LNX.4.33.0112221926580.31115-100000@linux.ircd-net.org>

[Dec 22 19:25:41.487805 2001] debug: Loading module `operserv/main'
[Dec 22 19:25:41.491171 2001] modules.conf:178: Unknown directive 
`LogMaxUsers'
[Dec 22 19:25:41.491643 2001] modules.conf:220: Unknown directive 
`WallGetpass'
[Dec 22 19:25:41.491805 2001] modules.conf:227: Unknown directive 
`WallSetpass'

have those been moved?


From mark at mhetherington.demon.co.uk  Sat Dec 22 17:37:15 2001
From: mark at mhetherington.demon.co.uk (Mark Hetherington)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] unknown things
In-Reply-To: <Pine.LNX.4.33.0112221926580.31115-100000@linux.ircd-net.org>
Message-ID: <NFBBKFAFGLNBHGEDBKDMCECECIAA.mark@mhetherington.demon.co.uk>

I mentioned this in another email. There are checked in the wrong place
(module load which does no know what they are rather than services load
which does know). I meant to move the directives from one to the other but
have not tried it yet.

Mark.

> -----Original Message-----
> From: ircservices-coding-admin@ircservices.za.net
> [mailto:ircservices-coding-admin@ircservices.za.net]On Behalf Of Finny
> Merrill
> Sent: 23 December 2001 01:27
> To: ircservices-coding@ircservices.za.net
> Subject: [IRCServices Coding] unknown things
>
>
> [Dec 22 19:25:41.487805 2001] debug: Loading module `operserv/main'
> [Dec 22 19:25:41.491171 2001] modules.conf:178: Unknown directive
> `LogMaxUsers'
> [Dec 22 19:25:41.491643 2001] modules.conf:220: Unknown directive
> `WallGetpass'
> [Dec 22 19:25:41.491805 2001] modules.conf:227: Unknown directive
> `WallSetpass'
>
> have those been moved?
>
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
>


From achurch at achurch.org  Sun Dec 23 16:14:05 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] unknown things
Message-ID: <3c258453.02003@achurch.org>

>[Dec 22 19:25:41.487805 2001] debug: Loading module `operserv/main'
>[Dec 22 19:25:41.491171 2001] modules.conf:178: Unknown directive 
>`LogMaxUsers'
>[Dec 22 19:25:41.491643 2001] modules.conf:220: Unknown directive 
>`WallGetpass'
>[Dec 22 19:25:41.491805 2001] modules.conf:227: Unknown directive 
>`WallSetpass'

     I've been meaning to do something about these for a LONG time, but
there's been too much else going on.  I'll take care of them eventually.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

From admin at insiderZ.de  Sun Dec 23 09:06:15 2001
From: admin at insiderZ.de (Christian 'HERZ' Makowski)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Hello !
Message-ID: <HHEJLNAKMCNBHNPFAEAMKEOACCAA.admin@insiderZ.de>

Hello Together,

I am new here and i have a Question / Compilerproblem.
We work at the Momentan in our Network with Epona Services
but we have many problems with stability.
We want to Change to Ircservices, Coder from Unrealircd
says , this is the best for Unreal.

I just downloaded ircservices-5.0a8.tar.gz because we want to support
ircservices with Unreal3.2 / ipv6  but i have the first error:

I have tried make & gmake , what the problem here ?!?
ircservices4.5.35 compiles fine.

[insiderz@ns ircservices-5.0a8]$ gmake
sh version.sh
gcc -DCLEAN_COMPILE -O2 -Wall -Wmissing-prototypes -g -c version.c -o
version.o
gmake[1]: Entering directory `/home/insiderz/ircservices-5.0a8/modules'
gmake[2]: Entering directory
`/home/insiderz/ircservices-5.0a8/modules/chanserv'
gmake[2]: *** No rule to make target `main.so', needed by `all-dynamic'.
Stop.
gmake[2]: Leaving directory
`/home/insiderz/ircservices-5.0a8/modules/chanserv'
gmake[1]: *** [all-dynamic] Error 2
gmake[1]: Leaving directory `/home/insiderz/ircservices-5.0a8/modules'
gmake: *** [modules] Error 2

Thanks in advance for help and merry merry Xmas to All !

Christian -HERZ- Makowski
Networkadmin InsiderZ



From jbinder at kgazd.bme.hu  Sun Dec 23 09:51:52 2001
From: jbinder at kgazd.bme.hu (John Binder)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Hello !
References: <HHEJLNAKMCNBHNPFAEAMKEOACCAA.admin@insiderZ.de>
Message-ID: <000701c18bda$80e61be0$0d624298@kgazd.bme.hu>

Hi,

> I have tried make & gmake , what the problem here ?!?
> ircservices4.5.35 compiles fine.
> 
> [insiderz@ns ircservices-5.0a8]$ gmake
> sh version.sh
> gcc -DCLEAN_COMPILE -O2 -Wall -Wmissing-prototypes -g -c version.c -o
> version.o
> gmake[1]: Entering directory `/home/insiderz/ircservices-5.0a8/modules'
> gmake[2]: Entering directory
> `/home/insiderz/ircservices-5.0a8/modules/chanserv'
> gmake[2]: *** No rule to make target `main.so', needed by `all-dynamic'.
> Stop.
> gmake[2]: Leaving directory
> `/home/insiderz/ircservices-5.0a8/modules/chanserv'
> gmake[1]: *** [all-dynamic] Error 2
> gmake[1]: Leaving directory `/home/insiderz/ircservices-5.0a8/modules'
> gmake: *** [modules] Error 2

IMHO configure was forgotten, try to ./configure before it

John Binder

> Thanks in advance for help and merry merry Xmas to All !
> 
> Christian -HERZ- Makowski
> Networkadmin InsiderZ
> 
> 
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
> 
> 


From achurch at achurch.org  Mon Dec 24 10:56:31 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Hello !
Message-ID: <3c268d42.02117@achurch.org>

>Hello Together,
>
>I am new here and i have a Question / Compilerproblem.
>We work at the Momentan in our Network with Epona Services
>but we have many problems with stability.
>We want to Change to Ircservices, Coder from Unrealircd
>says , this is the best for Unreal.
>
>I just downloaded ircservices-5.0a8.tar.gz because we want to support
>ircservices with Unreal3.2 / ipv6  but i have the first error:

     DO NOT use the alpha version of Services on a live network!  Alpha
versions are for testing ONLY.  DO NOT contact either me or the mailing
lists with questions about an alpha version unless you intend to help test
and find bugs yourself.  If you ignore this warning, I will either ban you
from downloading the alpha version, or remove the alpha version from public
access entirely and publicly give your name and E-mail address as the
reason the alpha was removed.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

>I have tried make & gmake , what the problem here ?!?
>ircservices4.5.35 compiles fine.
>
>[insiderz@ns ircservices-5.0a8]$ gmake
>sh version.sh
>gcc -DCLEAN_COMPILE -O2 -Wall -Wmissing-prototypes -g -c version.c -o
>version.o
>gmake[1]: Entering directory `/home/insiderz/ircservices-5.0a8/modules'
>gmake[2]: Entering directory
>`/home/insiderz/ircservices-5.0a8/modules/chanserv'
>gmake[2]: *** No rule to make target `main.so', needed by `all-dynamic'.
>Stop.
>gmake[2]: Leaving directory
>`/home/insiderz/ircservices-5.0a8/modules/chanserv'
>gmake[1]: *** [all-dynamic] Error 2
>gmake[1]: Leaving directory `/home/insiderz/ircservices-5.0a8/modules'
>gmake: *** [modules] Error 2
>
>Thanks in advance for help and merry merry Xmas to All !
>
>Christian -HERZ- Makowski
>Networkadmin InsiderZ
>
>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding

From casper at wbss.com  Sun Dec 23 20:03:37 2001
From: casper at wbss.com (CaSPeR)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] raw commands
Message-ID: <017601c18c2f$f7c503c0$ace4fea9@casper>

just wanted to know if there is a list of commands and their discriptions somewhere?
also want to know what command to use to bring in a fake user.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20011223/56c54ad1/attachment.html
From smkelly at zombie.org  Sun Dec 23 20:35:49 2001
From: smkelly at zombie.org (Sean Kelly)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] raw commands
In-Reply-To: <017601c18c2f$f7c503c0$ace4fea9@casper>; from casper@wbss.com on Sun, Dec 23, 2001 at 11:03:37PM -0500
References: <017601c18c2f$f7c503c0$ace4fea9@casper>
Message-ID: <20011223223549.A2427@edgemaster.zombie.org>

On Sun, Dec 23, 2001 at 11:03:37PM -0500, CaSPeR wrote:
> just wanted to know if there is a list of commands and their discriptions somewhere?
> also want to know what command to use to bring in a fake user.

RAW merely passes the string on to services' uplink server.  Any valid IRC
command, as issued by a server, is valid.  I suggest you read RFC1459 and
also become familiar with the workings of ircd before you play with RAW.
It isn't a toy.

-- 
Sean Kelly         | PGP KeyID: 77042C7B
smkelly@zombie.org | http://www.zombie.org

For PGP key, send e-mail with subject "send pgp key"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20011223/3486e5a6/attachment.pgp
From chromi at cyberspace.org  Sun Dec 23 20:22:16 2001
From: chromi at cyberspace.org (Jonathan Morton)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] raw commands
In-Reply-To: <017601c18c2f$f7c503c0$ace4fea9@casper>
References: <017601c18c2f$f7c503c0$ace4fea9@casper>
Message-ID: <a05101002b84c5dbdea5f@[10.0.1.2]>

>just wanted to know if there is a list of commands and their 
>discriptions somewhere?
>also want to know what command to use to bring in a fake user.

Consult your IRCd's documentation.  Commands available via RAW are 
not under Services' control and can cause major problems.

-- 
--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
website:  http://www.chromatix.uklinux.net/vnc/
geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$
           V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
tagline:  The key to knowledge is not to rely on people to teach you it.

From achurch at achurch.org  Mon Dec 24 22:21:35 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] svc5 exception move
Message-ID: <3c272c21.02247@achurch.org>

>When trying to move exception #1 it fails and, when there are 3 exception
>s:
>
>/os exception move 4 3
>
>gives:
>
>-OperServ- Exception for *.hell.gr (#3) moved to number 2.

     Thanks, fixed (the problem is the -1's, which shouldn't be there).

>exception move also doesn't seem to work at all.

     That's because the code that actually does it (in database/ver4.c)
is still broken (#ifdef'd out) and I haven't had a chance to fix it yet.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

From lamego at ptlink.net  Tue Dec 25 12:38:28 2001
From: lamego at ptlink.net (lamego@ptlink.net)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Hello !
Message-ID: <20011225124018.3C86B1742B@snow.fingers.co.za>

Is the Alpha distributed with some kind of "not public" license ?
I do know the term "use it at your own risk", but this "forbidden to use on a live network" is a new one.

Just a thought,
Joao Pinto

Andrew Church <achurch@achurch.org> wrote :

> >Hello Together,
> >
> >I am new here and i have a Question / Compilerproblem.
> >We work at the Momentan in our Network with Epona Services
> >but we have many problems with stability.
> >We want to Change to Ircservices, Coder from Unrealircd
> >says , this is the best for Unreal.
> >
> >I just downloaded ircservices-5.0a8.tar.gz because we want to support
> >ircservices with Unreal3.2 / ipv6  but i have the first error:
> 
>      DO NOT use the alpha version of Services on a live network!  Alpha
> versions are for testing ONLY.  DO NOT contact either me or the mailing
> lists with questions about an alpha version unless you intend to help test
> and find bugs yourself.  If you ignore this warning, I will either ban you
> from downloading the alpha version, or remove the alpha version from public
> access entirely and publicly give your name and E-mail address as the
> reason the alpha was removed.
> 
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/
> 
> >I have tried make & gmake , what the problem here ?!?
> >ircservices4.5.35 compiles fine.
> >
> >[insiderz@ns ircservices-5.0a8]$ gmake
> >sh version.sh
> >gcc -DCLEAN_COMPILE -O2 -Wall -Wmissing-prototypes -g -c version.c -o
> >version.o
> >gmake[1]: Entering directory `/home/insiderz/ircservices-5.0a8/modules'
> >gmake[2]: Entering directory
> >`/home/insiderz/ircservices-5.0a8/modules/chanserv'
> >gmake[2]: *** No rule to make target `main.so', needed by `all-dynamic'.
> >Stop.
> >gmake[2]: Leaving directory
> >`/home/insiderz/ircservices-5.0a8/modules/chanserv'
> >gmake[1]: *** [all-dynamic] Error 2
> >gmake[1]: Leaving directory `/home/insiderz/ircservices-5.0a8/modules'
> >gmake: *** [modules] Error 2
> >
> >Thanks in advance for help and merry merry Xmas to All !
> >
> >Christian -HERZ- Makowski
> >Networkadmin InsiderZ
> >
> >
> >------------------------------------------------------------------
> >To unsubscribe or change your subscription options, visit:
> >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding








From christian.makowski at t-online.de  Tue Dec 25 04:44:51 2001
From: christian.makowski at t-online.de (Christian Makowski)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Hello !
Message-ID: <1009284150.3c287436d2282@webmail.t-online.de>

lamego@ptlink.net schrieb:
> Is the Alpha distributed with some kind of "not public" 
> license ? 
> I do know the term "use it at your own risk", but this 
> "forbidden to use on a live network" is a new one. 
> 
> Just a thought,
> Joao Pinto
> 

So i think too
Then i ask me, why a Alpha is Released to download from a Mainsite
with a BIG Advertising link.
It would be better on a CVS Server for internal Use.

From achurch at achurch.org  Tue Dec 25 22:11:53 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Hello !
Message-ID: <3c287df1.12075@achurch.org>

>> Is the Alpha distributed with some kind of "not public" 
>> license ? 
>> I do know the term "use it at your own risk", but this 
>> "forbidden to use on a live network" is a new one. 

     The license is the GPL, the same as it has always been, but the only
reason I'm making it publicly available at all while it's still in alpha is
to get help from _experienced_ users in fixing the remaining major problems
before I take it to beta status and do a full-fledged release.  (From the
response I've seen so far I'm half inclined to take it down again.)

>So i think too
>Then i ask me, why a Alpha is Released to download from a Mainsite
>with a BIG Advertising link.

     Because that's the only way to let people know who might want to help
with an alpha test.  You might also note that there's a fairly large and
obvious warning--on two consecutive pages, no less!--before you can
actually download the alpha version.

     Please remember that I have NO obligation whatsoever to provide any
sort of "service" to you or even to publish IRC Services at all.  The only
thing I get out of Services is appreciation from users, which includes the
recognition that I do this on my own free time without any sort of
compensation other than the thanks of users for creating it.  (Frankly, I
would probably be a much happier person if I hadn't devoted many thousands
of hours over six years to Services, but oh well.)  Thus, I do NOT
appreciate people ignoring warnings I put up explicitly to prevent these
kinds of questions/complaints.

     Please try to act more responsibly in the future.  (That applies to
everyone.)

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

From achurch at achurch.org  Tue Dec 25 22:24:20 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Services 5.0 alpha 9 released
Message-ID: <3c2880d1.12116@achurch.org>

     Alpha 9 is up in the usual place; this is mainly a release to get
accumulated changes uploaded before I leave on vacation (tomorrow).  I'll
be back late on 1 January, if things go according to plan, so mail will go
unanswered until then.

     Also, happy holidays to all.  This is meant seriously, for those who
may be unsure: I'm not the fascist bastard I may seem in mail sometimes--
I just play one on the Internet, so to speak. (:  I don't intend to let my
holiday season get overwhelmed by this or any other minor matter, and I
hope none of you do either.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

From rg at tcslon.com  Tue Dec 25 09:53:27 2001
From: rg at tcslon.com (Russell Garrett)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Services 5.0 alpha 9 released
In-Reply-To: <3c2880d1.12116@achurch.org>
Message-ID: <NDBBLDHKLKMANPGMACIGGEHOCNAA.rg@tcslon.com>

OK, a few comments from me. I haven't managed to crash it yet, which
is always a good sign ;).

I was playing with the httpd/dbaccess/xml-export module, and IE6's
usually annoying XML syntax checking pointed something out. Where
there's an ampersand in a last_quit field, it replaces it with
"&amp-" as opposed to the correct "&amp;", which causes IE to choke
:). The context is as follows:

<nickinfo>
<nick>[nick]</nick>
...
<last_quit>Quit: Peace &amp- Protection 4.06</last_quit>
...
<nickinfo>

Also, it seems to pad every <supass> or <pass> field with lots of
"&#0;" null chars:
<supass>mysupass&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&
#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;</supass>
<pass>&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0
;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;</pa
ss>

Note: I am working with a copy of my live v4 database.

Also, on my #chat channel on the v4 installation, Voice is set to
level 0, so everyone is voiced when they join. However, when my AOPs
join #chat on the v5 net, they get set +hq, and normal users don't
get anything, which is rather odd (possibly to do with me not running
the xOP module or something...). I'm continuing to investigate this
one.


Cheers,


Russ Garrett (russ@garrett.co.uk)



From achurch at achurch.org  Wed Dec 26 03:08:51 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Services 5.0 alpha 9 released
Message-ID: <3c28c329.41041@achurch.org>

>I was playing with the httpd/dbaccess/xml-export module, and IE6's
>usually annoying XML syntax checking pointed something out. Where
>there's an ampersand in a last_quit field, it replaces it with
>"&amp-" as opposed to the correct "&amp;", which causes IE to choke
>:). The context is as follows:
>
><nickinfo>
><nick>[nick]</nick>
>...
><last_quit>Quit: Peace &amp- Protection 4.06</last_quit>
>...
><nickinfo>

     Okay, that was a stupid one... an off-by-one error in a memcpy() size
argument.  Fixed, thanks; the patch is as follows:

---------------------------------------------------------------------------
--- modules/misc/xml-export.c	19 Dec 2001 16:35:13 -0000	2.2
+++ modules/misc/xml-export.c	25 Dec 2001 18:12:42 -0000	2.3
@@ -94,7 +94,7 @@
 	    d += 4;
 	    break;
 	  case '&':
-	    memcpy(d, "&amp;", 4);
+	    memcpy(d, "&amp;", 5);
 	    d += 5;
 	    break;
 	  default:
---------------------------------------------------------------------------

>Also, it seems to pad every <supass> or <pass> field with lots of
>"&#0;" null chars:
><supass>mysupass&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&
>#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;</supass>
><pass>&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0
>;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;</pa
>ss>

     This is because the export-xml module can't know that the encryption
module (if one is in use) uses a null character as a string terminator.
In point of fact, the MD5 encryption module stores the passwords as 16 raw
bytes rather than 32 hex characters, so null characters can very possibly
appear in the middle of a password.  Thus, passwords are stored as raw
buffers of data (properly XML-encoded).

>Also, on my #chat channel on the v4 installation, Voice is set to
>level 0, so everyone is voiced when they join. However, when my AOPs
>join #chat on the v5 net, they get set +hq, and normal users don't
>get anything, which is rather odd (possibly to do with me not running
>the xOP module or something...). I'm continuing to investigate this
>one.

     You should probably look into what check_access_cumode()
(modules/chanserv/access.c) is doing; that part of the code has been
thoroughly redone and gotten almost no testing.  I'm not sure what would
cause the autovoice level to get set to 0.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

From rg at tcslon.com  Tue Dec 25 11:14:58 2001
From: rg at tcslon.com (Russell Garrett)
Date: Sat Oct 23 23:09:11 2004
Subject: [IRCServices Coding] Services 5.0 alpha 9 released
In-Reply-To: <3c28c329.41041@achurch.org>
Message-ID: <NDBBLDHKLKMANPGMACIGMEHPCNAA.rg@tcslon.com>

>      Okay, that was a stupid one... an off-by-one error in
> a memcpy() size
> argument.  Fixed, thanks; the patch is as follows:

Thanks

> ...
> appear in the middle of a password.  Thus, passwords are
> stored as raw
> buffers of data (properly XML-encoded).

Fair enough, just wondering what they were doing :)

>      You should probably look into what check_access_cumode()
> (modules/chanserv/access.c) is doing; that part of the
> code has been
> thoroughly redone and gotten almost no testing.  I'm not
> sure what would
> cause the autovoice level to get set to 0.

Ahh, I wasn't very clear there - the autovoice level was set to 0 on
the version 4 services by my chanops to make it easier to silence
certain users :). On the v5 net, with both the xOP and Levels modules
loaded, nothing happens to level 0 users, and users previously
autoopped (levels 5+) are all set mode +hq (insofar as that there is
more than one +q user in the room...).

Just a few more things that I've noticed:

- The news.db database (imported from version 4) corrupted rather
easily the first time I sent services a SIGTERM. Now I get [Oper
News - Jan 01 1970] (null).

- The /os rehash command doesn't seem to rehash very many
configuration options. I could be wrong, but I don't think I've seen
any of the modules.conf options updated using this command.

- httpd/auth-password doesn't seem to work at all for me:
Module httpd/auth-password
    AuthName            "PhaseNet Test IRC Services"
    Protect     /debug          "quack:quack"
    Protect     /dbaccess       "quack:quack"
EndModule

No auth box is presented

- The httpd/dbaccess module is very useful for debugging
access/levels problems such as the above, but it would be quite handy
to have a http://serviceshost/dbaccess/chanserv/chan/levels page,
showing the xOP levels sometimes.



That's about all for the moment ;),

Russ Garrett (russ@garrett.co.uk)


From lamego at ptlink.net  Tue Dec 25 20:46:30 2001
From: lamego at ptlink.net (lamego@ptlink.net)
Date: Sat Oct 23 23:09:12 2004
Subject: [IRCServices Coding] Hello !
Message-ID: <20011225204816.7C6DA17444@snow.fingers.co.za>

Andrew Church <achurch@achurch.org> wrote :

> >> Is the Alpha distributed with some kind of "not public" 
> >> license ? 
> >> I do know the term "use it at your own risk", but this 
> >> "forbidden to use on a live network" is a new one. 
> 
>      The license is the GPL, the same as it has always been, but the only
> reason I'm making it publicly available at all while it's still in alpha is
> to get help from _experienced_ users in fixing the remaining major problems
> before I take it to beta status and do a full-fledged release.  (From the
> response I've seen so far I'm half inclined to take it down again.)
You are getting help from _experienced_ users however making it public you should be also prepared to get *NOT* help from general users.
> 
> >So i think too
> >Then i ask me, why a Alpha is Released to download from a Mainsite
> >with a BIG Advertising link.
> 
>      Because that's the only way to let people know who might want to help
> with an alpha test.  
The guy was trying to help, but first he just needed some help :P
>You might also note that there's a fairly large and
> obvious warning--on two consecutive pages, no less!--before you can
> actually download the alpha version.
One more reason that it is user's responsability so you should not be worried with someone running it on a live network.
> 
>      Please remember that I have NO obligation whatsoever to provide any
> sort of "service" to you or even to publish IRC Services at all.  The only
> thing I get out of Services is appreciation from users, which includes the
> recognition that I do this on my own free time without any sort of
> compensation other than the thanks of users for creating it.  (Frankly, I
> would probably be a much happier person if I hadn't devoted many thousands
> of hours over six years to Services, but oh well.)  You and all the guys who work on linux, gcc, gmake etc most of the software you need to compile and run ircservices. I don't remember none of them forbidding their alpha from beeing tested on "live servers".

Thus, I do NOT
> appreciate people ignoring warnings I put up explicitly to prevent these
> kinds of questions/complaints.
Sometimes the delete key is helpfull and not so stressing.
> 
>      Please try to act more responsibly in the future.  (That applies to
> everyone.)
Doing it now, I hope :)
> 
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding








From rg at tcslon.com  Tue Dec 25 13:11:22 2001
From: rg at tcslon.com (Russell Garrett)
Date: Sat Oct 23 23:09:12 2004
Subject: [IRCServices Coding] More bugs... :)
In-Reply-To: <3c2880d1.12116@achurch.org>
Message-ID: <NDBBLDHKLKMANPGMACIGKEIACNAA.rg@tcslon.com>

Another small XML bug, courtesy of IE6's XML parser :)

Line 243 of modules/misc/xml-export.c is:
        writefunc(data, "\t<nickinfo>\n");
and should be:
        writefunc(data, "\t</nickinfo>\n");
with the forwardslash.

After that's changed the XML checks out fine in IE.

I spotted that repeated segfault-on-squit problem again, but couldn't
repeat it, and coredumping wasn't on. I've turned it on, so I should
be able to catch it next time :)

Cheers,

Russ Garrett (russ@garrett.co.uk)


From ron885 at linuxfreemail.com  Tue Dec 25 15:35:45 2001
From: ron885 at linuxfreemail.com (Ron )
Date: Sat Oct 23 23:09:12 2004
Subject: [IRCServices Coding] A bug i think...
Message-ID: <200112252335.fBPNZjb27708@superglide.netfx-2000.net>

I was playing with alpha8 last night, and discovered this and wasn't 
quite sure if it is whats supposed to happen.  The session limit was 
set two 3 and i had one client loaded, Ron885, and the other one 
connecting, Ron885_...

[01:28:20] Global: OperServ - Ron885 added an SGLINE for ron (expires 
in 1 minute)
[01:28:34] Connect: Ron885_ (ron885@ron.linux) on port 6667
[01:28:34] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ 
(Invalid Real Name)
[01:28:34] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ 
(Invalid Real Name))]
[01:28:37] Connect: Ron885_ (ron885@ron.linux) on port 6667
[01:28:37] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ 
(Invalid Real Name)
[01:28:37] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ 
(Invalid Real Name))]
[01:28:38] Connect: Ron885_ (ron885@ron.linux) on port 6667
[01:28:38] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ 
(Session limit exceeded)
[01:28:38] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ 
(Session limit exceeded))]
[01:28:43] Connect: Ron885_ (ron885@ron.linux) on port 6667
[01:28:43] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ 
(Session limit exceeded)
[01:28:43] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ 
(Session limit exceeded))]
[01:28:48] Connect: Ron885_ (ron885@ron.linux) on port 6667
[01:28:48] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ 
(Session limit exceeded)
[01:28:48] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ 
(Session limit exceeded))]
[01:28:52] Connect: Ron885_ (ron885@ron.linux) on port 6667
[01:28:52] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ 
(Session limit exceeded)
[01:28:52] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ 
(Session limit exceeded))]
[01:28:53] Connect: Ron885_ (ron885@ron.linux) on port 6667
[01:28:53] GLINE: added for *@ron.linux on Mon Dec 24 20:28:53 2001 GMT 
(from OperServ to expire at Mon Dec 24 20:58:53 2001 GMT: Autokilled: 
Exceeding session limit)
[01:28:53] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ 
(Session limit exceeded)
[01:28:53] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ 
(Session limit exceeded))]
[01:28:53] -1.axenet.org- *** You are banned from Axenet (Autokilled: 
Exceeding session limit)
[01:28:53] Disconnect: Ron885 (ron885@ron.linux) [User has been banned 
from Axenet (Autokilled: Exceeding session limit)]
[01:28:53] --- Closing Link: Ron885[ron.linux] (User has been banned 
from Axenet (Autokilled: Exceeding session limit))
[01:28:53] --- Disconnected (Remote host closed socket).

it seems as if the session list gets messed up... because afterwards i 
had one client connected and did /os session view and it said 3 of 3 
when there was only one connected...

--
Ron885
TechAdmin @ irc.axenet.org

Get your own FREE E-mail address at http://www.linuxfreemail.com
Linux FREE Mail is 100% FREE, 100% Linux, 100% better, and 100% yours!



From griever at t2n.org  Tue Dec 25 16:43:52 2001
From: griever at t2n.org (Finny Merrill)
Date: Sat Oct 23 23:09:12 2004
Subject: [IRCServices Coding] A bug i think...
In-Reply-To: <200112252335.fBPNZjb27708@superglide.netfx-2000.net>
Message-ID: <Pine.LNX.4.33.0112251843280.3861-100000@linux.ircd-net.org>

I noticed this too, I think it has something to do with +x
On Tue, 25 Dec 2001, Ron  wrote:

> I was playing with alpha8 last night, and discovered this and wasn't 
> quite sure if it is whats supposed to happen.  The session limit was 
> set two 3 and i had one client loaded, Ron885, and the other one 
> connecting, Ron885_...
> 
> [01:28:20] Global: OperServ - Ron885 added an SGLINE for ron (expires 
> in 1 minute)
> [01:28:34] Connect: Ron885_ (ron885@ron.linux) on port 6667
> [01:28:34] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ 
> (Invalid Real Name)
> [01:28:34] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ 
> (Invalid Real Name))]
> [01:28:37] Connect: Ron885_ (ron885@ron.linux) on port 6667
> [01:28:37] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ 
> (Invalid Real Name)
> [01:28:37] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ 
> (Invalid Real Name))]
> [01:28:38] Connect: Ron885_ (ron885@ron.linux) on port 6667
> [01:28:38] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ 
> (Session limit exceeded)
> [01:28:38] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ 
> (Session limit exceeded))]
> [01:28:43] Connect: Ron885_ (ron885@ron.linux) on port 6667
> [01:28:43] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ 
> (Session limit exceeded)
> [01:28:43] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ 
> (Session limit exceeded))]
> [01:28:48] Connect: Ron885_ (ron885@ron.linux) on port 6667
> [01:28:48] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ 
> (Session limit exceeded)
> [01:28:48] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ 
> (Session limit exceeded))]
> [01:28:52] Connect: Ron885_ (ron885@ron.linux) on port 6667
> [01:28:52] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ 
> (Session limit exceeded)
> [01:28:52] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ 
> (Session limit exceeded))]
> [01:28:53] Connect: Ron885_ (ron885@ron.linux) on port 6667
> [01:28:53] GLINE: added for *@ron.linux on Mon Dec 24 20:28:53 2001 GMT 
> (from OperServ to expire at Mon Dec 24 20:58:53 2001 GMT: Autokilled: 
> Exceeding session limit)
> [01:28:53] KILL: Ron885_!ron885@axe-32362.ron.linux from OperServ 
> (Session limit exceeded)
> [01:28:53] Disconnect: Ron885_ (ron885@ron.linux) [Killed (OperServ 
> (Session limit exceeded))]
> [01:28:53] -1.axenet.org- *** You are banned from Axenet (Autokilled: 
> Exceeding session limit)
> [01:28:53] Disconnect: Ron885 (ron885@ron.linux) [User has been banned 
> from Axenet (Autokilled: Exceeding session limit)]
> [01:28:53] --- Closing Link: Ron885[ron.linux] (User has been banned 
> from Axenet (Autokilled: Exceeding session limit))
> [01:28:53] --- Disconnected (Remote host closed socket).
> 
> it seems as if the session list gets messed up... because afterwards i 
> had one client connected and did /os session view and it said 3 of 3 
> when there was only one connected...
> 
> --
> Ron885
> TechAdmin @ irc.axenet.org
> 
> Get your own FREE E-mail address at http://www.linuxfreemail.com
> Linux FREE Mail is 100% FREE, 100% Linux, 100% better, and 100% yours!
> 
> 
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
> 


From achurch at achurch.org  Wed Dec 26 10:30:20 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:09:12 2004
Subject: [IRCServices Coding] A bug i think...
Message-ID: <3c29288e.06571@achurch.org>

>I was playing with alpha8 last night, and discovered this and wasn't 
>quite sure if it is whats supposed to happen.  The session limit was 
>set two 3 and i had one client loaded, Ron885, and the other one 
>connecting, Ron885_...
[...]
>it seems as if the session list gets messed up... because afterwards i 
>had one client connected and did /os session view and it said 3 of 3 
>when there was only one connected...

     This is because the session/exception callback gets called before the
S-line one, leaving "ghost" users in the session count.  Fixed, thanks.
Patch is as follows (not tested):

--- modules/operserv/sessions.c	24 Dec 2001 13:20:09 -0000	2.30
+++ modules/operserv/sessions.c	26 Dec 2001 01:27:15 -0000
@@ -728,7 +728,13 @@
 	return 0;
     }
 
-    if (!add_callback(NULL, "user check", check_sessions)
+    /* Add user check callback at priority -10 so it runs after all the
+     * autokill/S-line/whatever checks (otherwise we get users added to
+     * sessions and then killed by S-lines, leaving the session count
+     * jacked up).  FIXME: we really really need to document places where
+     * we use callback priorities.
+     */
+    if (!add_callback_pri(NULL, "user check", check_sessions, -10)
      || !add_callback(NULL, "user delete", remove_session)
      || !add_callback(NULL, "save data", do_save_data)
      || !add_callback(NULL, "expire", expire_exceptions)

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

From achurch at achurch.org  Wed Dec 26 11:30:02 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:09:12 2004
Subject: [IRCServices Coding] Services 5.0 alpha 9 released
Message-ID: <3c2939c5.10626@achurch.org>

>>      You should probably look into what check_access_cumode()
>> (modules/chanserv/access.c) is doing; that part of the
>> code has been
>> thoroughly redone and gotten almost no testing.  I'm not
>> sure what would
>> cause the autovoice level to get set to 0.
>
>Ahh, I wasn't very clear there - the autovoice level was set to 0 on
>the version 4 services by my chanops to make it easier to silence
>certain users :). On the v5 net, with both the xOP and Levels modules
>loaded, nothing happens to level 0 users, and users previously
>autoopped (levels 5+) are all set mode +hq (insofar as that there is
>more than one +q user in the room...).

     Hm, I'll have to take a look into that... but it will have to be after
I get back from vacation, I think. (:  If you want to look into it yourself,
check_access_cumode() is a good place to start, as mentioned above.

>- The news.db database (imported from version 4) corrupted rather
>easily the first time I sent services a SIGTERM. Now I get [Oper
>News - Jan 01 1970] (null).

     I, uh, fixed that.  Really.  The gremlins must have backed out my
commit, or something.

>- The /os rehash command doesn't seem to rehash very many
>configuration options. I could be wrong, but I don't think I've seen
>any of the modules.conf options updated using this command.

     It should get most of them, and you should get log messages for ones
that can't be dynamically updated.  (However, this is only since alpha 8;
alpha 7 didn't have support for reconfiguration in the modules.)  At the
least I've been able to make OperServ dynamically change nicks here.

>- httpd/auth-password doesn't seem to work at all for me:
>Module httpd/auth-password
>    AuthName            "PhaseNet Test IRC Services"
>    Protect     /debug          "quack:quack"
>    Protect     /dbaccess       "quack:quack"
>EndModule
>
>No auth box is presented

     Hm, it seems to have broken somewhere.  I'll look into this as well.

>- The httpd/dbaccess module is very useful for debugging
>access/levels problems such as the above, but it would be quite handy
>to have a http://serviceshost/dbaccess/chanserv/chan/levels page,
>showing the xOP levels sometimes.

     Added to TODO.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

From achurch at achurch.org  Wed Dec 26 11:45:30 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:09:12 2004
Subject: [IRCServices Coding] More bugs... :)
Message-ID: <3c2939f1.10637@achurch.org>

>Another small XML bug, courtesy of IE6's XML parser :)
>
>Line 243 of modules/misc/xml-export.c is:
>        writefunc(data, "\t<nickinfo>\n");
>and should be:
>        writefunc(data, "\t</nickinfo>\n");
>with the forwardslash.

     Thanks, fixed.

>After that's changed the XML checks out fine in IE.

     That's good to know... especially as it's my first attempt in doing
anything at all with XML. (:

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

From griever at t2n.org  Tue Dec 25 19:30:49 2001
From: griever at t2n.org (Finny Merrill)
Date: Sat Oct 23 23:09:12 2004
Subject: [IRCServices Coding] Services 5.0 alpha 9 released
In-Reply-To: <3c2939c5.10626@achurch.org>
Message-ID: <Pine.LNX.4.33.0112252130300.4244-100000@linux.ircd-net.org>

On Wed, 26 Dec 2001, Andrew Church wrote:

> >>      You should probably look into what check_access_cumode()
> >> (modules/chanserv/access.c) is doing; that part of the
> >> code has been
> >> thoroughly redone and gotten almost no testing.  I'm not
> >> sure what would
> >> cause the autovoice level to get set to 0.
> >
> >Ahh, I wasn't very clear there - the autovoice level was set to 0 on
> >the version 4 services by my chanops to make it easier to silence
> >certain users :). On the v5 net, with both the xOP and Levels modules
> >loaded, nothing happens to level 0 users, and users previously
> >autoopped (levels 5+) are all set mode +hq (insofar as that there is
> >more than one +q user in the room...).
> 
>      Hm, I'll have to take a look into that... but it will have to be after
> I get back from vacation, I think. (:  If you want to look into it yourself,
> check_access_cumode() is a good place to start, as mentioned above.
> 
> >- The news.db database (imported from version 4) corrupted rather
> >easily the first time I sent services a SIGTERM. Now I get [Oper
> >News - Jan 01 1970] (null).
> 
>      I, uh, fixed that.  Really.  The gremlins must have backed out my
> commit, or something.
> 
> >- The /os rehash command doesn't seem to rehash very many
> >configuration options. I could be wrong, but I don't think I've seen
> >any of the modules.conf options updated using this command.
> 
>      It should get most of them, and you should get log messages for ones
> that can't be dynamically updated.  (However, this is only since alpha 8;
> alpha 7 didn't have support for reconfiguration in the modules.)  At the
> least I've been able to make OperServ dynamically change nicks here.
> 
> >- httpd/auth-password doesn't seem to work at all for me:
> >Module httpd/auth-password
> >    AuthName            "PhaseNet Test IRC Services"
> >    Protect     /debug          "quack:quack"
> >    Protect     /dbaccess       "quack:quack"
> >EndModule
> >
> >No auth box is presented

You *DO* have the LoadModule line in services.conf, right?

> 
>      Hm, it seems to have broken somewhere.  I'll look into this as well.
> 
> >- The httpd/dbaccess module is very useful for debugging
> >access/levels problems such as the above, but it would be quite handy
> >to have a http://serviceshost/dbaccess/chanserv/chan/levels page,
> >showing the xOP levels sometimes.
> 
>      Added to TODO.
> 
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
> 


From achurch at achurch.org  Wed Dec 26 14:23:28 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:09:12 2004
Subject: [IRCServices Coding] Services 5.0 alpha 9 released
Message-ID: <3c295f7a.25341@achurch.org>

>Ahh, I wasn't very clear there - the autovoice level was set to 0 on
>the version 4 services by my chanops to make it easier to silence
>certain users :). On the v5 net, with both the xOP and Levels modules
>loaded, nothing happens to level 0 users, and users previously
>autoopped (levels 5+) are all set mode +hq (insofar as that there is
>more than one +q user in the room...).
[...]
>- The news.db database (imported from version 4) corrupted rather
>easily the first time I sent services a SIGTERM. Now I get [Oper
>News - Jan 01 1970] (null).
[...]
>- httpd/auth-password doesn't seem to work at all for me:
>Module httpd/auth-password
>    AuthName            "PhaseNet Test IRC Services"
>    Protect     /debug          "quack:quack"
>    Protect     /dbaccess       "quack:quack"
>EndModule
>
>No auth box is presented
>
>- The httpd/dbaccess module is very useful for debugging
>access/levels problems such as the above, but it would be quite handy
>to have a http://serviceshost/dbaccess/chanserv/chan/levels page,
>showing the xOP levels sometimes.

     Okay, these are all fixed, and I'll put out another alpha release
with the fixes in a moment.  Ironically, the +hq bug, which I thought
would be tricky to track down, turned out to be a simple one-line fix,
while the dbaccess levels addition, which seemed pretty simple at first
glance, took a bit of reorganizing things.  Just goes to show something
or other, I guess...

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

From achurch at achurch.org  Wed Dec 26 14:45:03 2001
From: achurch at achurch.org (Andrew Church)
Date: Sat Oct 23 23:09:12 2004
Subject: [IRCServices Coding] Services 5.0 alpha 10 released
Message-ID: <3c2963d3.41711@achurch.org>

     Okay, this will _really_ be the last release before I leave on
vacation, because I leave in about 15 minutes. (:  Patches for the recently
mentioned bugs are included.  Change list is below:

Version 5.0
-----------
2001/12/26 a10	Fixed bug causing strange channel user modes to be auto-set.
		    Reported by Russ Garrett <russ@garrett.co.uk>
2001/12/26	Added access levels link to ChanServ information page
		    (httpd/dbaccess).  Suggested by Russ Garrett
		    <russ@garrett.co.uk>
2001/12/26	Fixed bug in auth-password module causing Protect lines to be
		    ignored.  Reported by Russ Garrett <russ@garrett.co.uk>
2001/12/26	Fixed bug in news database writing causing corruption.
2001/12/26	Fixed missing slash on closing <nickinfo> tag in XML export
		    module.  Reported by Russ Garrett <russ@garrett.co.uk>
2001/12/26	Fixed callback ordering bug causing S-line kills to leave
		    "ghost" users in the session count.  Reported by
		    <ron885@linuxfreemail.com>
2001/12/26	Fixed off-by-one bug causing corrupted output in XML export
		    module.  Reported by Russ Garrett <russ@garrett.co.uk>

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

From chromi at cyberspace.org  Tue Dec 25 07:16:06 2001
From: chromi at cyberspace.org (Jonathan Morton)
Date: Sat Oct 23 23:09:12 2004
Subject: [IRCServices Coding] Hello !
In-Reply-To: <20011225124018.3C86B1742B@snow.fingers.co.za>
References: <20011225124018.3C86B1742B@snow.fingers.co.za>
Message-ID: <a05101000b84e485d9bcc@[10.0.1.2]>

>Is the Alpha distributed with some kind of "not public" license ?
>I do know the term "use it at your own risk", but this "forbidden to 
>use on a live network" is a new one.

You're not forbidden to use it on a live network.  You are, however, 
forbidden from making a fuss when your p***ed-off users break down 
your front door.  :)  You're also forbidden from whining about how 
buggy it is - it'a an ALPHA release for crying out loud.

-- 
--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
website:  http://www.chromatix.uklinux.net/vnc/
geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$
           V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
tagline:  The key to knowledge is not to rely on people to teach you it.

From rg at tcslon.com  Wed Dec 26 06:48:22 2001
From: rg at tcslon.com (Russell Garrett)
Date: Sat Oct 23 23:09:12 2004
Subject: [IRCServices Coding] Services 5.0 alpha 10 released
In-Reply-To: <3c2963d3.41711@achurch.org>
Message-ID: <NDBBLDHKLKMANPGMACIGOEIDCNAA.rg@tcslon.com>

>      Okay, this will _really_ be the last release before I leave on
> vacation, because I leave in about 15 minutes. (:  Patches

Ok, I'll queue some more bugs up in your inbox for when you return ;)

memoserv/forward: /ms SET FORWARD [ON|OFF|COPY] doesn't work. Patch
follows:
modules/memoserv/forward.c:
On line 152:
    } else if (stricmp(option, "ON") == 0) {
should read:
    } else if (stricmp(param, "ON") == 0) {
On line 156:
    } else if (stricmp(option, "COPY") == 0) {
should read:
    } else if (stricmp(param, "COPY") == 0) {
and on line 159:
    } else if (stricmp(option, "OFF") == 0) {
should read:
    } else if (stricmp(param, "OFF") == 0) {

memoserv/forward: After applying the above fix, /ms SET FORWARD
[ON|COPY] returns the following:
  [14:11:26] Your memos will now be forwarded to your E-mail address:
(null)
regardless of which or whether an e-mail was set, although the actual
forwarding works. Looks pretty simple to fix. Something to do with
notice_lang not being told the e-mail I think.

memoserv/forward: After applying the set forward fix, forwarded memo
e-mails contain:
  Memo from  (Dec 26 13:58:10 2001 GMT)
without any name. Probably a similar problem to the above.

nickserv/autojoin: Although the AJOIN command works a treat, it
doesn't seem to appear on the /ns HELP COMMANDS list.


Cheers,

Russ Garrett (russ@garrett.co.uk)


From rg at tcslon.com  Wed Dec 26 09:20:54 2001
From: rg at tcslon.com (Russell Garrett)
Date: Sat Oct 23 23:09:12 2004
Subject: [IRCServices Coding] Yet more bugs
In-Reply-To: <3c2963d3.41711@achurch.org>
Message-ID: <NDBBLDHKLKMANPGMACIGMEIECNAA.rg@tcslon.com>

memoserv/main: The memo send confirmation messages appear when
sending to some users, but not others. I'm not sure what determines
this though. Every time, however, the memo is sent, just sometimes it
isn't confirmed.

Here is the fix for the missing e-mail address in the memoserv set
forward message bug I reported earlier, if anyone wants it:
/modules/memoserv/forward.c
Line 155:
        notice_lang(s_MemoServ, u, MEMO_SET_FORWARD_ON);
Change to:
        notice_lang(s_MemoServ, u, MEMO_SET_FORWARD_ON,
u->ngi->email);
Line 158:
        notice_lang(s_MemoServ, u, MEMO_SET_FORWARD_COPY);
Change to:
        notice_lang(s_MemoServ, u, MEMO_SET_FORWARD_COPY,
u->ngi->email);


Russ Garrett (russ@garrett.co.uk)


From dwd at buli.net  Sat Dec 29 06:36:48 2001
From: dwd at buli.net (dwd@buli.net)
Date: Sat Oct 23 23:09:12 2004
Subject: [IRCServices Coding] errors.log?
Message-ID: <DPG.WIN.300.0112291536483020582672@drotposta.hu>

Hi!

errors.log:
[Fri Dec 28 23:16:22 2001] - num - 1

What's this?

Thanks:
-- 
dwd
ICQ#108548590
chat@dwdworld.net
http://chat.dwdworld.net