software/RELEASES/ircservices/achurch.org/services/lists/ircservices-coding/2002/000278.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
   2 <HTML>
   3  <HEAD>
   4    <TITLE> [IRCServices Coding] Making Services 5 friendly external pseudo clients
   5    </TITLE>
   6    <LINK REL="Index" HREF="index.html" >
   7    <LINK REL="made" HREF="mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20Making%20Services%205%20friendly%20external%20pseudo%20clients&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="000297.html">
  11    <LINK REL="Next"  HREF="000280.html">
  12  </HEAD>
  13  <BODY BGCOLOR="#ffffff">
  14    <H1>[IRCServices Coding] Making Services 5 friendly external pseudo clients</H1>
  15     <B>Andrew Church</B>
  16     <A HREF="mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20Making%20Services%205%20friendly%20external%20pseudo%20clients&In-Reply-To="
  17        TITLE="[IRCServices Coding] Making Services 5 friendly external pseudo clients">achurch at achurch.org
  18        </A><BR>
  19     <I>Fri Feb 15 22:20:20 PST 2002</I>
  20     <P><UL>
  21         <LI>Previous message: <A HREF="000297.html">[IRCServices Coding] Services 5.0 Odd enforcer bug
  22 </A></li>
  23         <LI>Next message: <A HREF="000280.html">[IRCServices Coding] Services 5.0a20 httpd bugs
  24 </A></li>
  25          <LI> <B>Messages sorted by:</B>
  26               <a href="date.html#278">[ date ]</a>
  27               <a href="thread.html#278">[ thread ]</a>
  28               <a href="subject.html#278">[ subject ]</a>
  29               <a href="author.html#278">[ author ]</a>
  30          </LI>
  31        </UL>
  32     <HR>
  33 <!--beginarticle-->
  34 <PRE>     Is +S essentially treated as an oper, admin, or what, and on what ircd?
  35
  36   --Andrew Church
  37     <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">achurch at achurch.org</A>
  38     <A HREF="http://achurch.org/">http://achurch.org/</A>
  39
  40 &gt;<i>Currently on our network we have a couple of psuedo clients which are not
  41 </I>&gt;<i>part of IRC Services but have similar &quot;powers&quot; as +S psudeo clients on
  42 </I>&gt;<i>ulined servers. This includes a StatServ client that we had been running for
  43 </I>&gt;<i>some time prior to the first StatServ appearing in IRC Services and an open
  44 </I>&gt;<i>proxy monitor.
  45 </I>&gt;<i>
  46 </I>&gt;<i>Although they generally live happily together, since Services does not
  47 </I>&gt;<i>recognise these external psuedo clients, occasionally they tend to &quot;fight&quot;.
  48 </I>&gt;<i>
  49 </I>&gt;<i>Using our StatServ as an example, this basically sits in a channel
  50 </I>&gt;<i>announcing various information about the network for the use of IRCops.
  51 </I>&gt;<i>Ideally we would like this channel locked to be an oper only channel but
  52 </I>&gt;<i>currently have to rely on an eggdrop bot to enforce this rather than
  53 </I>&gt;<i>ChanServ.
  54 </I>&gt;<i>
  55 </I>&gt;<i>The problems are twofold. Firstly, since Services has no way of recognising
  56 </I>&gt;<i>an external psuedo client, when StatServ ops itself, Chanserv will
  57 </I>&gt;<i>immediately deop it. Secondly, if the channel mode is set to mode +O,
  58 </I>&gt;<i>StatServ can happily join the channel (as a +S user), but services will
  59 </I>&gt;<i>enforce the mode and kick StatServ as a non-oper. This results in a vicious
  60 </I>&gt;<i>flood of join/kicks as they both fight for their rights :)
  61 </I>&gt;<i>
  62 </I>&gt;<i>Hopefully, the built-in StatServ will eventually provide most if not all of
  63 </I>&gt;<i>the functionality of our existing StatServ and anything it doesn't provide
  64 </I>&gt;<i>we can develop into a custom module of services. But, until that time, we
  65 </I>&gt;<i>need to maintain StatServ as an external pseudo client.
  66 </I>&gt;<i>
  67 </I>&gt;<i>The simplest way seems to be some recognition within services for other
  68 </I>&gt;<i>ulined servers possibly by detecting the +S user mode in a similar way that
  69 </I>&gt;<i>our StatServ will recognise each Services pseudo client as such. Is there
  70 </I>&gt;<i>anything in current versions of services that would allow the two servers to
  71 </I>&gt;<i>live together or anything we could set in our external pseudo clients which
  72 </I>&gt;<i>would cause services to ignore their actions?
  73 </I>&gt;<i>
  74 </I>&gt;<i>
  75 </I>&gt;<i>Mark.
  76 </I>&gt;<i>
  77 </I>&gt;<i>------------------------------------------------------------------
  78 </I>&gt;<i>To unsubscribe or change your subscription options, visit:
  79 </I>&gt;<i><A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">http://www.ircservices.za.net/mailman/listinfo/ircservices-coding</A>
  80 </I>
  81 </PRE>
  82
  83 <!--endarticle-->
  84     <HR>
  85     <P><UL>
  86         <!--threads-->
  87         <LI>Previous message: <A HREF="000297.html">[IRCServices Coding] Services 5.0 Odd enforcer bug
  88 </A></li>
  89         <LI>Next message: <A HREF="000280.html">[IRCServices Coding] Services 5.0a20 httpd bugs
  90 </A></li>
  91          <LI> <B>Messages sorted by:</B>
  92               <a href="date.html#278">[ date ]</a>
  93               <a href="thread.html#278">[ thread ]</a>
  94               <a href="subject.html#278">[ subject ]</a>
  95               <a href="author.html#278">[ author ]</a>
  96          </LI>
  97        </UL>
  98
  99 </body></html>