1 <!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 3.2//EN">
4 <TITLE> [IRCServices Coding] Services
5 - Suggestions/Queries
6 <LINK REL=
"Index" HREF=
"index.html" >
7 <LINK REL=
"made" HREF=
"mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20Services%205%20-%20Suggestions/Queries&In-Reply-To=">
8 <META NAME=
"robots" CONTENT=
"index,nofollow">
9 <META http-equiv=
"Content-Type" content=
"text/html; charset=us-ascii">
10 <LINK REL=
"Previous" HREF=
"000261.html">
11 <LINK REL=
"Next" HREF=
"000253.html">
13 <BODY BGCOLOR=
"#ffffff">
14 <H1>[IRCServices Coding] Services
5 - Suggestions/Queries
</H1>
16 <A HREF=
"mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20Services%205%20-%20Suggestions/Queries&In-Reply-To="
17 TITLE=
"[IRCServices Coding] Services 5 - Suggestions/Queries">achurch at achurch.org
19 <I>Sun Feb
10 23:
26:
55 PST
2002</I>
21 <LI>Previous message:
<A HREF=
"000261.html">[IRCServices Coding] ChanServ suggestion
23 <LI>Next message:
<A HREF=
"000253.html">[IRCServices Coding] Services
5 - AKILL expiry
25 <LI> <B>Messages sorted by:
</B>
26 <a href=
"date.html#252">[ date ]
</a>
27 <a href=
"thread.html#252">[ thread ]
</a>
28 <a href=
"subject.html#252">[ subject ]
</a>
29 <a href=
"author.html#252">[ author ]
</a>
34 <PRE>1) SQlineReason
"%s
" (and your point about the examples being incosistent
35 is a valid one, I'll look into it).
37 2) This is an ircd issue (Unreal, at least, propogates all S-lines so this
38 does not occur). If you want S-lines propogated immediately rather than
39 waiting for Services to detect a violation, use ImmediatelySendSline.
41 3) If the protocol module provides an IP address to users.c:do_nick(), then
42 IP addresses are deemed available, else they're deemed unavailable.
43 Unreal doesn't send IP addresses, so you get the warning.
46 <A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">achurch at achurch.org
</A>
47 <A HREF=
"http://achurch.org/">http://achurch.org/
</A>
49 ><i>1) Suggestion: When a qline is set on the ircd, the error reported to the
50 </I>><i>user is formatted as follows:
52 </I>><i>Guest781361765 Erroneous Nickname: Reserved for Services
54 </I>><i>However, sqlines set in services merely report:
56 </I>><i>testsqline Erroneous Nickname: Reserved nickname
58 </I>><i>A better response would be:
60 </I>><i>testsqline Erroneous Nickname: (reason set in services)
62 </I>><i>2) Suggestion/Query: The sline modules provides a very useful central
63 </I>><i>repository for qlines/zlines etc that remove the need for individual
64 </I>><i>ircd.conf changes when a new sline is required. However, in the qline
65 </I>><i>example above, services does not seem to have added the qline to the list
66 </I>><i>used by the ircd. In the event of any downtime, this would mean that the
67 </I>><i>qlines would no longer remain in operation even though some services set
68 </I>><i>options (e.g. akills) would likely survive the downtime. I appreciate that
69 </I>><i>this maybe be largely an IRCd issue but if services were to provide a
70 </I>><i>framework for interaction with the IRCd, I am sure it should be possible to
71 </I>><i>add IRCd level support so identifying the appropriate area would be a good
72 </I>><i>first step.
74 </I>><i>3) Suggestion/Query: With the s(z)line support, I am not sure of the exact
75 </I>><i>manner in which Services determines what level of support is available in
76 </I>><i>the ircd (i.e. whether it is the appropriate protocol module or the sline
77 </I>><i>module which makes the decision and how).
79 </I>><i>I notice for Unreal, services reports in the log a lack of IP information as
80 </I>><i>being of relevance to the szline support. If this is determined by say the
81 </I>><i>protocol module, then I guess the operation is fixed by that module, but if
82 </I>><i>it is down to some sort of real time startup test, I would assume that the
83 </I>><i>Unreal
"connection message
" which is lacking in IP is the cause. Since this
84 </I>><i>is a relatively trivial issue to address on the IRCd, it would be useful to
85 </I>><i>have some way to have services recognise the support.
87 </I>><i>This largely depends on the method(s) services uses to determine the level
88 </I>><i>of support. If the protocol module does fix this operation, the suggestion
89 </I>><i>would be to have some type of configuration directive to override this
90 </I>><i>operation for a server modified to be more
"services friendly
".
92 </I>><i>If it does check the connection message format, I can safely update that
93 </I>><i>portion of code and services have access to IP addresses in the manner it
94 </I>><i>desires. A number of
"tools
" cite Unreal's connection message as a bug so it
95 </I>><i>may ultimately be addressed in the new version as it progresses through
98 </I>><i>However, if neither of these options is in force, then I guess I am loooking
99 </I>><i>for some long term solution to this based on how the current operation
100 </I>><i>determines support.
105 </I>><i>------------------------------------------------------------------
106 </I>><i>To unsubscribe or change your subscription options, visit:
107 </I>><i><A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
</A>
115 <LI>Previous message:
<A HREF=
"000261.html">[IRCServices Coding] ChanServ suggestion
117 <LI>Next message:
<A HREF=
"000253.html">[IRCServices Coding] Services
5 - AKILL expiry
119 <LI> <B>Messages sorted by:
</B>
120 <a href=
"date.html#252">[ date ]
</a>
121 <a href=
"thread.html#252">[ thread ]
</a>
122 <a href=
"subject.html#252">[ subject ]
</a>
123 <a href=
"author.html#252">[ author ]
</a>
projects / irc.git / blob