srvx-devel Mailing List for srvx IRC Services

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Call out Gouranga be happy!!!
Gouranga Gouranga Gouranga ....
That which brings the highest happiness!!

By popular demand..

srvx changes, 1.2rc3 to 1.2rc4:

  Non-service-specific changes
  ----------------------------
  Slightly revised license.
  NetBSD before 1.6 do not work with srvx-1.2.  Document this in INSTALL.
  No longer recommend that users run "make install".
  Check that "src" is a directory during configure script.
  Allow searching for accounts by email address; see "email_search_level" in srvx.conf.example.
  New and improved logging subsystem (see srvx.conf.example).
  Update channel membership lists when a server issues the kick.
  Update MAXBANS to 45 to match ircu defaults circa 2.10.11.04.
  Do not log invocations to "help" or "command" by default.
  Honor channel suspensions by prohibiting most commands for them.
  Fix elapsed time display when saving a database takes N.0...N.1 seconds.
  Close the unused ends of sendmail children.
  Use IRC case comparisons when matching globs.

  ChanServ
  --------
  Send a response to "opchan", in case issuer is not in-channel and not +s.
  Do not allow normal users to unregister a suspended channel.
  Kick pre-banned users on !addban, !addtimedban.
  Only show suspension history to coowners and owners of the channel.
  Ignore autoinvite flag for suspended channel users.
  Re-instate "set pubcmd" option checking.
  Require users to have owner or above access in the target channel of a "merge".
  Do not protect a user from being kicked if the kicker is authed to the same account.
  Do not invite users while we are still bursting (to prevent a 443 error).
  Put spaces in the output of !names.
  Hide nodelete channels from output of "/msg chanserv access SomeOper" to helpers.
  Set default command flags for !down to include +regchan.
  Make !unregister, !cunsuspend, !info work for suspended channels.
  "!noregister *account" searches the account DNR list now.

  NickServ
  --------
  Require users to be authed to use email or password change cookies.
  Destroy cookies when an oper uses "oset email" on an account.
  Support usermode +r (user's nick is registered to them) under Bahamut.
  Fix a bug where setting an email address would suppress nick registration.
  Fix a bug where searching with accountmask would crash (or behave badly).
  Do not allow staff to oregister an account for someone who outranks them.
  Default to *@*.users.isp for generated hostmasks.

  Global
  ------
  Fix slight memory leak in the "list" command.

  HelpServ
  --------
  Increase tracking period to 4 weeks.
  Always show helper time as "x hours, y minutes".
  List total requests waiting when whining for attention.
  Document the "trial" access level, and properly document *PageType.

  OpServ
  ------
  Do not let an oper demote himself.
  Use correct "part" reason.
  Properly handle trusts with unlimited clients (where limit is 0).

  mod-snoop
  ---------
  Do not show AUTH messages during burst.
  Do not show QUIT messages while exiting.

We have released srvx-1.2rc4 (CVS tag rel-1_2rc4).  This isn't so much
a real "release candidate" as a new snapshot -- we are still seeing
crashes on GamesNET due to unknown problems -- but a sufficient number
of bugs have been fixed that we want to provide a new release to
non-CVS users.

If you provide a distribution mirror of srvx, we ask that you remove
older releases from your download page(s).  If you follow
srvx-commits, you can probably guess why.  We are not happy about
having to ask this, but feel it is only appropriate.  (In addition,
some users download 1.1.3 thinking it is the best release to use; we
believe 1.2rc4 is more polished overall.)

Entrope

Hi,=20

This patch adds user_mode and channel_mode hooks.

It attaches much cleaner and should work just great on bahamuth as well
(although the extra check for numeric nicks might be stupid =3D))

Other than that it also checks for clients about to quit so it skips the
part messages.

There is however one small thing:
 if (!mode_change[1]) return; in snoop_user_mode (mod-snoop.c)

It will crash heavily if there is *nothing* in mode_change. I haven't
seen anything like that on ircu and i assume that bahamuth works the
same way. IF you get problems, change it to a strlen immediately.

patch avail from http://pomac.netswarm.net/
(direct link: http://pomac.netswarm.net/misc/srvx.snoopv2.diff.gz)

--=20
Ian Kumlien <po...@va...>

Hi,=20

This is a patch for mod-snoop.c it changes some other things.
Among those are:
part_func_t
del_user_func_t

And then it adds itself to proto-p10.c to get modes.

Unfortunately i have no access to Bahamauth and i have no clue about it
so there is no "mode" support for Bahamauth.

The patch is avail from http://pomac.netswarm.net
(direct link: http://pomac.netswarm.net/misc/srvx.snoop.diff.gz)

--=20
Ian Kumlien <po...@va...>

Entrope <en...@us...> wrote:

> What would we use a signed integer for?  (Where would we use negative
> numbers?)  Bit vector would be a good idea to do portably across
> databases, given how often we use it.  How would you implement loading
> and storing types in SQL or BDB without the backend knowing how to do
> the serialization in advance?  (I think having it all handled by the
> front end is a poor idea, in case we allow a web site to look at the
> data -- regardless of whether the web site can write to it.)

Leaving out negative integers may make sense, since we really don't use
them. However, it would probably require a negligible amount of work to
support them, so there's no reason not to support them.

Backends that don't natively support a custom data type would probably
take the same approach the text database would -- serialize the data as
text. If we don't support custom data types (nothing wrong with that;
they're not essential), at least making new data types easy to add would
be helpful.

If we allow a web site to look at the data, it probably still needs to
go through srvx -- encapsulating "business logic" and all that (plus I'd
like to avoid duplicating code to deal with text databases).

> I was thinking "not null" could be handled at the application layer,
> since that part of the schema has changed for columns between releases
> (for example, some of the fields for gags) and only makes sense for
> SQL.  How would we (gracefully) handle the case where a "not null"
> field were missing from an insert or update?

When data absolutely has to be present in a column (which is not the
primary key), such as in the case of account passwords, it should be
enforced by the database layer. If a not null field is missing from an
insert or update, that row is completely invalid. An account without a
password is just as broken as an account without an account name.

# Zoot

Again, comments.  This only discusses the lower levels, and doesn't
specify how services interact with each other.

(This could probably be rolled into doxygen-compatible docs, but I
haven't looked up how to import a graph file like framework.dot.)

Entrope

======================
= srvx 2.x Framework =
======================

This document describes the general architecture and details the lower
levels of the srvx 2.x framework.  It is intended as both a design
spec and a "getting started" guide for new developers.

A rough diagram of the layering is available in framework.dot. (To
convert it to GIF, run "dot -Tgif -o framework.gif framework.dot".)
Each node in that graph has its own section in this file.

=================
= framework.dot =
=================

digraph srvx {
    label="srvx component framework";

    svc_mods    [label="service modules"];
    svc_core    [label="services core"];
    irc_core    [label="IRC core"];
    logging     [label="logging"];
    db_virt     [label="DB virtualizer"];
    ioset       [label="ioset I/O code"];
    formatters  [label="string formatters"];
    db_libs     [label="database libs"];
    os_apis     [label="C++ standard library,\nBerkeley sockets,\nother system APIs"];

    svc_mods -> { svc_core irc_core logging ioset db_virt };
    svc_core -> { irc_core formatters };
    irc_core -> { ioset };
    logging -> { formatters db_libs os_apis };
    db_virt -> { db_libs os_apis };
    ioset -> { os_apis };
    db_libs -> { os_apis };
}

========================
= HIGH LEVEL OVERVIEWS =
========================

C++ standard library, Berkeley sockets, other system APIs
---------------------------------------------------------

These are system APIs that srvx does not implement, but merely runs on
top of.

ioset I/O code
--------------

An "ioset" is a managed set of sockets.  The manager can: initiate new
outbound connections, set up new listening sockets, close sockets
(whether connected or listening), and check for read and/or write
activity on registered sockets (with a specified inactivity timeout).

The operations on an ioset are high level, so that it may be
implemented with either a polling API or completion port API, without
overly impacting its users.

See: srvx::ioset, srvx::socket, srvx::iobuf classes

string formatters
-----------------

Utilities to format strings and provide internationalization support.

See: srvx::format class (will be heavily revised for I18N)

database libs
-------------

This represents supported third-party (or recdb) database libraries;
for example, libpqxx or the C++ bindings for the Sleepycat Berkeley
DB.

See: third party documentation for them

DB virtualizer
--------------

This component acts as an adapter between internal database
representation and the external APIs.  It also provides helper
utilities such as a dirty object cache.

See: (not yet written; probably srvx::database class)

logging
-------

Directs log events to appropriate consumers.  Depending on
configuration, it might send command logs to a SQL database, error
notices to an IRC channel, and other messages to a text file.

See: srvx::logger, srvx::log class, srvx::log_store classes

IRC core
--------

This provides the API and core of IRC support in a protocol-agnostic
way.  It interfaces between the per-protocol support code and the
individual services and service modules.

See: srvx::irc::protocol class

services core
-------------

Provides helper utilities and code common to many service modules.

See: (not yet written; probably srvx::service class)

service modules
---------------

Each module implements a family of commands; for example, userlist
maintenance, channel control, proxy checking, etc.

See: (not yet written)

"Zoot" <zo...@ga...> writes:

> A signed integer type as well as the ability to implement loading and
> storing of new types (for example, bit vectors) would be nice, but not
> essential.

What would we use a signed integer for?  (Where would we use negative
numbers?)  Bit vector would be a good idea to do portably across
databases, given how often we use it.  How would you implement loading
and storing types in SQL or BDB without the backend knowing how to do
the serialization in advance?  (I think having it all handled by the
front end is a poor idea, in case we allow a web site to look at the
data -- regardless of whether the web site can write to it.)

> It may be useful to allow schemas to specify that a column is 'not
> null,' as in SQL.

I was thinking "not null" could be handled at the application layer,
since that part of the schema has changed for columns between releases
(for example, some of the fields for gags) and only makes sense for
SQL.  How would we (gracefully) handle the case where a "not null"
field were missing from an insert or update?

> I don't see anything wrong with the database abstraction interface,
> though there are a number of smaller problems that need to be solved.

I discovered one: some objects have two logical parents (user entries
in channels belong to both the channel and the account).  To get
proper behavior for renames of the parent objects, the backend needs
to know this and support multi-column primary keys.

> For example, there's no way to query both the hierarchial text databases
> and relational databases with just a procedural interface. This implies
> we'll need a query language or something roughly approximating one; this
> means we need to implement one for text databases.

You're probably right, although I was more concerned with the basic
functionality than how to do efficient searches.

> The relational database backend also needs to maintain referential
> integrity, as well as handle changes to the schema gracefully, of
> course.

Yes.  I tried to keep the schema simple enough to use easily but keep
enough information to tell let the SQL backend implement referential
integrity rules natively in SQL.

> What if I hold a handle to an object and it gets deleted, then attempt
> to use that handle?

Deleted from where?  If the C++ object exists after it was dropped
from the database, either the database manager knows it was dropped
(and will not write it back), or a third party dropped it (and the
UPDATE writeback command will fail in SQL; BDB would probably have to
make sure the row still exists before writeback).

Entrope

> Feedback, if you have any :)
Just the thing I like to dispense on a Saturday night!

> Database Model
> --------------
> 
> The top level of the database consists of tables.  These are named
> mappings of keys to rows.  Each row has one primary key column, other
> columns, and child tables.  A column has a name, and data of one of
> several types:
>   - unsigned integer
>   - datetime
>   - string
>   - string list
>   - child table (of a specific type)
A signed integer type as well as the ability to implement loading and
storing of new types (for example, bit vectors) would be nice, but not
essential.

> Within a given table, each column contains the same type of data in
> all rows (the special value 'null' may exist in any column except the
> primary key column; whether it occurs, and the meaning if it does, is
> table-specific).
It may be useful to allow schemas to specify that a column is 'not
null,' as in SQL.

> A child table is distinguished by having a parent row in another
> table; rows in top-level tables do not have parents.  For relational
> databases, this usually means the child table has additional columns
> in the primary key to identify the parent row.
> Child objects cannot look up their parents directly, although if they
> do not have a parent object pointer, they must have a list of parent
> keys (to know where their children are and to write themselves out).
I don't see anything wrong with the database abstraction interface,
though there are a number of smaller problems that need to be solved.
For example, there's no way to query both the hierarchial text databases
and relational databases with just a procedural interface. This implies
we'll need a query language or something roughly approximating one; this
means we need to implement one for text databases. The relational
database backend also needs to maintain referential integrity, as well
as handle changes to the schema gracefully, of course.

> Each table type is represented by a descriptor and control object in
> srvx.  These are created by specifying the table name, column names
> and types, primary key column name, and factory to load objects from
> the database store.  These type descriptors are created by a factory
> method on the database backend object.
What if I hold a handle to an object and it gets deleted, then attempt
to use that handle?

# Zoot

Feedback, if you have any :)

I do not know how clear this will be to people besides me; if it is
not clear, or if you have concerns about what it can do, let me know
where.

Assuming nobody finds serious problems in it, I'll start implementing
it this weekend.

-- Entrope

Database Abstraction
--------------------

srvx-2.0 uses (will use) a database abstraction layer to hide the
structural and representation differences between different supported
database backends, and to make it easier to manage the database
behavior at a high level.  This document describes the behavior and
interfaces of that layer -- both what it exposes to the higher levels
of srvx, and what it expects from the database backends.

Database Model
--------------

The top level of the database consists of tables.  These are named
mappings of keys to rows.  Each row has one primary key column, other
columns, and child tables.  A column has a name, and data of one of
several types:
  - unsigned integer
  - datetime
  - string
  - string list
  - child table (of a specific type)
Within a given table, each column contains the same type of data in
all rows (the special value 'null' may exist in any column except the
primary key column; whether it occurs, and the meaning if it does, is
table-specific).
A child table is distinguished by having a parent row in another
table; rows in top-level tables do not have parents.  For relational
databases, this usually means the child table has additional columns
in the primary key to identify the parent row.
Child objects cannot look up their parents directly, although if they
do not have a parent object pointer, they must have a list of parent
keys (to know where their children are and to write themselves out).

Schema Representation
---------------------

Each table type is represented by a descriptor and control object in
srvx.  These are created by specifying the table name, column names
and types, primary key column name, and factory to load objects from
the database store.  These type descriptors are created by a factory
method on the database backend object.

Object Loading
--------------

The table type descriptor object can load a database object, given the
child primary key and either parent object or full list of parent
keys.

When a row is loaded from the database, all its child rows may be
loaded in the same query (whether or not is specified in the load
call, and defaults to loading children), but its parent (if one
exists) is not loaded.  The object is entered into a per-table and
database-wide cache.  The representation passed to the object loading
factory should be similar to the "struct record_data" in srvx-1.x.

Object Storing
--------------

A database object can be marked dirty (and probably should be marked
dirty by mutator methods) and moved to the dirty list in the database.
The base database object class has a (virtual) method to write the
object out, using an interface similar to the saxdb write interface in
srvx-1.x.

The database backend must also support transaction levels, and not
permanently write dirty objects until the transaction is committed.
If the transaction (or a parent transaction) is rolled back, the
object must be reverted to its pre-transaction state.

[Q: how will rollback interact with adding or dropping rows?  Probably
just reference the added/dropped rows in the transaction record.]

Caching
-------

Each table type contains a map of loaded objects.  The whole database
contains LRU lists of clean and dirty objects.  The desired size of
these lists can be tuned at runtime.  The database can be told to
reload its cache (for example, if a third party updates the data
store).

Backends
--------

This abstraction layer is designed to efficiently support three
specific backends:
 - a plain text backend that can read srvx-1.x format recdb files (and
   write similarly formatted files -- just without "" for strings that
   are clearly tokens),
 - Berkeley/Sleepycat DB databases,
 - a SQL backend (that knows how to do RFC1459 casemapping).

The major provisos for the backends are:
 - the plain text backend must load and store the entire database at
   once, and thus caches the entire thing,
 - plain text and Sleepycat DBs are vulnerable to in-process corruption,
 - SQL backend is susceptible to high IPC traffic and serialization cost.

Due to popular request (and not many bugs being found lately :), the
srvx development team has released srvx-1.1.3.  It's available now
from SourceForge or as tag rel-1_1_3 in CVS.  It's mostly a lot of
minor bug fixes relative to 1.1.2, but has a few feature changes:

  - !topic X acts like /topic X, not like !set topic X
  - OpServ has a join_flood_moderate option that makes it join and
    moderate channels when it detects a join flood in them.

This should work with ircu2.10.10, lain, and ircu2.10.09.

Entrope

If the account databases of both srvx instances are kept synchronized,
it is perfectly possible to link them to the same network and
authenticate once. Your scheme is unnecessary and requires a much higher
account length limit than should be considered.

# Zoot

> -----Original Message-----
> From: srv...@li... 
> [mailto:srv...@li...] On Behalf Of Byte
> Sent: Thursday, August 08, 2002 8:58 AM
> To: srv...@li...
> Subject: [srvx-devel] P10 ACCOUNT
> 
> 
> I think this should support multiple srvx in some way, what 
> does everyone 
> else think?
> 
> i.e. set account to use the form "<srvx id>=<id>;<srvx id>=<id>;"?
> (where "srvx id" could be srvx numeric?)
> 
> Otherwise, it's not possible to be authenticated to both srvx 
> over a split :/
> 
> --
> by...@zl...
> http://byte.zlined.org/
> http://pgp.zlined.org/Byte.asc
> 19-May-2002 16:21:15
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Personal Privacy 6.5.8
> 
> iQA/AwUAPOa6jUCsucq83bnYEQK0ggCggDUPkEwQfdVoszNw/YiuSkDVG1QAniOB
> +EoAWEhBXIpuNQuG9fIug2rv
> =T2wY
> -----END PGP SIGNATURE-----
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> srvx-devel mailing list
> srv...@li...
> https://lists.sourceforge.net/lists/listinfo/srvx-devel
> 

Byte <by...@zl...> writes:

> I think this should support multiple srvx in some way, what does
> everyone else think?
> 
> 
> i.e. set account to use the form "<srvx id>=<id>;<srvx id>=<id>;"?
> (where "srvx id" could be srvx numeric?)
> 
> Otherwise, it's not possible to be authenticated to both srvx over a split :/

ACCOUNT was never designed to support authentication to more than one
user database.  Among other things, it's illegal (in IRCu) to change
an account for a user once the account stamp is set.

Entrope

I think this should support multiple srvx in some way, what does everyone 
else think?

i.e. set account to use the form "<srvx id>=<id>;<srvx id>=<id>;"?
(where "srvx id" could be srvx numeric?)

Otherwise, it's not possible to be authenticated to both srvx over a split :/

--
by...@zl...
http://byte.zlined.org/
http://pgp.zlined.org/Byte.asc
19-May-2002 16:21:15
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.8

iQA/AwUAPOa6jUCsucq83bnYEQK0ggCggDUPkEwQfdVoszNw/YiuSkDVG1QAniOB
+EoAWEhBXIpuNQuG9fIug2rv
=T2wY
-----END PGP SIGNATURE-----

I just committed a rather huge patch.  It does three things:

 - #include all ANSI C headers from compat.h
 - minimize #includes in other files
 - implement a generic command handler framework, including
   "free-form" aliases

The #include changes are pretty boring, and I should have split them
out, but they helped pretty up the doxygen graphs and made the modcmd
code easier, so they're lumped in.

The guts of the command framework is in modcmd.c and modcmd.h (modcmd
is short for "modularized commands").  It mostly works, but a few
things are known to not work yet:

 - There's no command to tweak the settings for existing commands.
   This is a thin wrapper around svccmd_configure(). I'll add that
   soon.
 - Commands that use unsplit_line() with freeform aliases break.
   There are a few ways to fix this this; the easy way is to make it
   fill in a fixed buffer, and change argv[0] to point to that buffer
   instead.  The "cleaner" way is to replace it with something else.
 - Some commands don't work 100% right (for example, ?join to an
   existing does not op OpServ).  These are easy enough to fix once
   they are found, but we need to test enough to find them.
 - Help indexes ("!help", "?help" without any arguments) do not show
   the right contents.  This is also a simple enough fix; I just got
   sick of having this huge diff on my disk and haven't fixed it yet.
 - Help output is not as clean as it could be, either.  There should
   be some line that works like the "${command/ADDBAN/access}" in
   chanserv.help, but automatically inserted by modcmd.  modcmd should
   probably also automatically put the "$bADDBAN$b" line at the top.
 - Needs a replacement for !command.
 - Permissions checks need to be fixed.  It currently does a
   require-all for "staff" privileges; as discussed on IRC, it should
   do a require-any instead.  This really requires permissions to be
   flattened rather than recursively checked.  Easy enough to fix.
 - Related to the above, policer weights are never checked.

And there are probably a lot of bugs that slipped by my (scanty)
testing.  For folks that don't have commit access, please try to get
backtraces of crashes and/or simple instructions on how to reproduce a
problem.

-- Entrope

Whatever we decide on, the policy on the Global notices should be
encoded in srvx's configuration file, not the source.

My feeling is that the advertisements (I prefer the term "community
announcement") should be opt-out on GamesNET. The announcements would
essentially start out with no audience if they were opt-in; only a small
number of users would ever bother opting in. I don't see a problem with
opt-out if we make the policy clear and screen messages carefully.

# Zoot

[snip]

> Another option that I really want is a user mode or a account flag
> that indicates willingness to receive (or desire to not receive)
> oper-sent advertisements.  A lot of people would want to know about
> big events, but some vocal people would not, and it does no good to
> annoy them.  This may be best as a protocol-level command
> (irc_advertise(), with the same signature as irc_privmsg()) that
> either invokes the "smart" ircd-known command or iterates over all
> users and sends to those who opted in or who did not opt out.
> 
> Hm...  I am not sure whether it is "better" on the whole to make such
> advertisements opt-in or opt-out.  Any opinions?  (Anyone can answer,
> even if they've never looked at the srvx code: the policy aspect is
> much more important than the technical feasibility.)
> 
> -- Entrope

Sorry, I sent that email with the wrong From: address.  Please use
this one (en...@us...) if you want to send me
srvx-development-related email.

-- Entrope

Here is the TODO list of things that I think we really should have in
srvx-1.2, from easy to hard:

  [BUG] ?modlog missing helpfile entry
  [BUG] "!help note types" doesn't show privileged note types to privileged users
  [FEATREQ] OpServ command to add/change an oper's access level
  [FEATREQ] Make the bad-word excepted channels global, not per-bad-word.
  [FEATREQ] ?csearch channel search command
  [FEATREQ] "Persistent auth" (servicestamp/ACCOUNT) support
  [FEATREQ] Cross-bot aliasing/command binding
  [FEATREQ] ServerSpy.net support

(The ServerSpy.net support code may or may not be put into the public
CVS branch.  I need to talk with the site's owner to figure that out.
It should probably be done after the cross-bot command binding,
anyway, to make it more modular.)

The following things are possibilities to add, depending on how hard they are:

  [FEATREQ] MemoServ (perhaps using a SQL backend?)
  [FEATREQ] make "/msg ChanServ access" show your infolines for all channels
  [FEATREQ] /msg AuthServ ghost my-old-nick
    - KILLs my-old-nick (but only if they are authed to your account)
  [FEATREQ] !set greet {0,1,2,3} where 0 is no greeting, 1 is only on userlist, 2 is all users except on userlist, 3 is all users
    - can probably fix or re-use !set greet/!set greetusers to do this
  [FEATREQ] Keep channel suspension history until unreg, so staff can see it
  [FEATREQ] Confirmation Of Channel Registration - Example Below
    <ChanServ> #Rowdy is now registered to account Rowdy
    <ChanServ> Please note, If you do not actively use this channel for 14 days, it will be
      unregistered.  Also note: This message can be customized in srvx.conf.
    <ChanServ> To acknowledge you understand and accept these things, and complete your registration, type "/msg ChanServ CONFIRM #Rowdy".  If you do NOT accept these things, type "/msg ChanServ REJECT #Rowdy".  If you do nothing, this registration will be cancelled in 10 minutes.
    - basically to make sure people know the AUP and channel guidelines in advance

If anybody wants to volunteer to do one of these, or has questions or
feedback or more things they'd like to see (in srvx 1.2 or 2.0),
please find one of the developers in #srvx on GamesNET.

Another option that I really want is a user mode or a account flag
that indicates willingness to receive (or desire to not receive)
oper-sent advertisements.  A lot of people would want to know about
big events, but some vocal people would not, and it does no good to
annoy them.  This may be best as a protocol-level command
(irc_advertise(), with the same signature as irc_privmsg()) that
either invokes the "smart" ircd-known command or iterates over all
users and sends to those who opted in or who did not opt out.

Hm...  I am not sure whether it is "better" on the whole to make such
advertisements opt-in or opt-out.  Any opinions?  (Anyone can answer,
even if they've never looked at the srvx code: the policy aspect is
much more important than the technical feasibility.)

-- Entrope

I think the 1.1 code is pretty much stable now, so I have re-branched
it.  CVS HEAD is about to become the srvx-1.2 code, and will be
unstable for a while.  If you are using srvx from CVS on a production
network, until 1.2 is ready, you will probably want to "cvs update -r
rel-1_1-branch" to stay with the 1.1.x code.

The main features that we plan for 1.2:
- Bahamut support
- Cross-bot aliasing/command invocation
- OpServ ?csearch (channel search) function
- Various cleanups

-- Entrope

Hi,

	?clone add <long nickname> ...
	?collide <long nickname> ...
	?reserve <long nickname> ...

	This stops nicknames which are too long from squitting srvx before its 
started,
	the previous behaviour did no checking of the nick length,
	which meant that it was only checked in hash.c,
	from AddClone/etc. calling AddUser, and adduser squits srvx if the nick is 
too long.

	I've emailed entrope about this before, and he is insistent that its not a 
bug,
	saying he doesnt want irc protocol in opserv, (this change makes opserv 
check 'nicklen' :/)

	I think its a potential problem, if a clone is added, and the nickname is 
accidentally too long,
	it would squit srvx, which isn't good on a real network, is it?

	Here is the diff/patch:

(~/services/src)
$ diff -c1 opserv.c-old opserv.c
*** opserv.c-old        Wed May 22 16:36:31 2002
--- opserv.c    Wed May 22 16:51:10 2002
***************
*** 198,200 ****
--- 198,202 ----
   #define OSMSG_COLLIDED_NICK   "Now temporarily holding nick `%s'"
+ #define OSMSG_COLLIDED_NICKTOOLONG    "Not temporarily holding nick `%s': 
nickname too long"
   #define OSMSG_RESERVED_NICK   "Now reserving nick `%s'"
+ #define OSMSG_RESERVED_NICKTOOLONG    "Not reserving nick `%s': nickname 
too long"
   #define OSMSG_NICK_RESERVED   "Nick is reserved."
***************
*** 210,211 ****
--- 212,214 ----
   #define OSMSG_CLONE_ADDED     "Added clone `%s'."
+ #define OSMSG_CLONE_NICKTOOLONG       "Clone `%s' not added: nickname is 
too long."
   #define OSMSG_NOT_A_CLONE     "Har har.  `%s' isn't a clone."
***************
*** 2032,2039 ****
       unsplit_string(argv+4, argc-4);
!     resv = opserv_add_reserve(user, argv[1], argv[2], argv[3], argv[4]);
!     if (resv) {
!       opserv_notice(user, OSMSG_COLLIDED_NICK, resv->nick);
!       return 1;
       } else {
!       return 0;
       }
--- 2035,2047 ----
       unsplit_string(argv+4, argc-4);
!     if (strlen(argv[1]) > nicklen) {
!       opserv_notice(user, OSMSG_COLLIDED_NICKTOOLONG, argv[1]);
!         return 0;
       } else {
!         resv = opserv_add_reserve(user, argv[1], argv[2], argv[3], argv[4]);
!         if (resv) {
!           opserv_notice(user, OSMSG_COLLIDED_NICK, resv->nick);
!           return 1;
!         } else {
!             return 0;
!         }
       }
***************
*** 2048,2056 ****
       unsplit_string(argv+4, argc-4);
!     resv = opserv_add_reserve(user, argv[1], argv[2], argv[3], argv[4]);
!     if (resv) {
!       resv->modes |= FLAGS_PERSISTENT;
!       opserv_notice(user, OSMSG_RESERVED_NICK, resv->nick);
!       return 1;
       } else {
!       return 0;
       }
--- 2056,2069 ----
       unsplit_string(argv+4, argc-4);
!     if (strlen(argv[1]) > nicklen) {
!         opserv_notice(user, OSMSG_RESERVED_NICKTOOLONG, argv[1]);
!         return 0;
       } else {
!         resv = opserv_add_reserve(user, argv[1], argv[2], argv[3], argv[4]);
!         if (resv) {
!           resv->modes |= FLAGS_PERSISTENT;
!           opserv_notice(user, OSMSG_RESERVED_NICK, resv->nick);
!           return 1;
!         } else {
!           return 0;
!         }
       }
***************
*** 2455,2458 ****
         }
!       clone = AddClone(argv[2], argv[3], argv[3]+i, argv[4]);
!       opserv_notice(user, OSMSG_CLONE_ADDED, clone->nick);
         return 1;
--- 2468,2476 ----
         }
!       if (strlen(argv[2]) > nicklen) {
!           opserv_notice(user, OSMSG_CLONE_NICKTOOLONG, argv[2]);
!             return 0;
!       } else {
!           clone = AddClone(argv[2], argv[3], argv[3]+i, argv[4]);
!           opserv_notice(user, OSMSG_CLONE_ADDED, clone->nick);
!       }
         return 1;

_______________________________________________
Byte
by...@zl...
http://byte.zlined.org/
_______________________________________________
http://pgp.zlined.org/Byte.asc
19-May-2002 16:21:15
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.8

iQA/AwUAPOa6jUCsucq83bnYEQK0ggCggDUPkEwQfdVoszNw/YiuSkDVG1QAniOB
+EoAWEhBXIpuNQuG9fIug2rv
=T2wY
-----END PGP SIGNATURE-----

Oh, almost forgot:

- Proxy checking rules should be moved into srvx.conf.  While we're
  doing this, a new syntax for variables and matching could be added.
  (This actually doesn't need that many changes to do.)
  Bonus points for the long-desired variable-length-match pattern.

Current syntax:
  "1080:050100" {
    "0500" "reject:Unsecured socks5";
  };
  "3128:=C=O=N=N=E=C=T= $c=:=3=1=2=8= =H=T=T=P=/=1=.=00d0a0d0a" {
    "=H=T=T=P=/=1=.=0= =2=0=0" "reject:Unsecured proxy";
  };

Possible new syntax:
  "1080:\x05\x01\x00" {
    "\.\x5b\." "reject:Unsecured socks";
  };
  "3128:CONNECT \c:3128 HTTP/1.0\x0d\x0a\x0d\x0a" {
    "HTTP/1.0 200" "reject:Unsecured proxy";
  };
(With this new syntax, the variable length matcher might be \*.)

-- Entrope

This is just a short list things I think we should fix for the 1.2
release.  The main point of the release is to port to Bahamut, but
there should be time to fix these issues (some from 1.0, some only
in 1.1).

- !users should use table_send() .. this requires some flag (or a new
  function) to expand $-variables in the fields.

- Sort of related, it would be nice to get rid of the formatting
  glitch that lets users use $-variables.  We can do this by expanding
  them out before calling vsnprintf (although we'd need to make sure
  to double any % characters in the variables' values).  This should
  also make the line-breaking code simpler.

- OpServ should track users by IP, not hostname, when determining
  whether or not they have too many clones online.  I started to do
  this in 1.1, then realized it would be a fair chunk of code.

- Sort of related, trusted hosts should be able to take a IP wildcard
  (not necessarily a hostname wildcard, though, if the above is done).
  This helps some of the bigger LAN parties; they *require* multiple
  outgoing IPs for the number of users they support.  Bonus points for
  letting the counting be done either per-IP or across all IPs that
  match the mask (so you could say "let any number of users on from
  each IP in 10.0.0.*, but no more than 500 for the whole range"),
  for those same LAN parties.

- HelpServ logging of closed requests to a file.

There are probably some more things that I have overlooked.  What do
you folks think should be fixed in 1.2?

-- Entrope

Entrope <en...@us...> writes:

> So if you commit spam in the next bit, that's why :)

Er, if you *get* commit spam, that's why.  Sorry for the confusing typo.

-- Entrope

Well, we continue to find bugs in the 1.1 code base.  Fortunately not
as many as when we released 1.0, but it's still quite inconvenient for
everyone when things crash.

We'll be fixing those bugs as they're discovered; in the mean time,
I'm going to open up the 1.2 code for development.  But instead of
putting it on yet another branch, I'm scrapping the code at CVS HEAD
of the services module and copying the current 1.1 code there.  This
will be the basis for 1.2 development.

We will still be working on srvx 2.0 (in the srvx module) as time
permits, but the main feature of 1.2 -- support for Bahamut -- is
currently higher priority than srvx-2.0.

So if you commit spam in the next bit, that's why :)

-- Entrope

srvx 1.1 is now beginning deployment on RealmNET. I'll keep you informed
of our progress/findings.

Regards,

--
John McGarrigle
IC5 Networks

email: jo...@ic...
DDI: +44 (0)845 129 7202
Fax: +44 (0)845 129 7201

-----Original Message-----
From: srv...@li...
[mailto:srv...@li...] On Behalf Of Entrope
Sent: 04 May 2002 5:49 PM
To: srv...@li...
Subject: [srvx-devel] srvx 1.1 released

All the juicy details are in the email to srvx-announce and in
changes.php.  The tag in CVS for the released files is rel-1_1.  I'll
probably let it sit for a few days to see what bugs crop up, then make
a branch for 1.2 development.  (And boy is that going to have ugly
revision numbers. :)

The main goal of 1.2 is going to be support for talking to Bahamut
servers.  It will also end up with some tweaks to HelpServ and
probably how the email stuff works, depending on how things go for
GamesNET and other networks that deploy 1.1.

-- Entrope

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We
supply
the hardware. You get the recognition. Email Us:
ban...@so...
_______________________________________________
srvx-devel mailing list
srv...@li...
https://lists.sourceforge.net/lists/listinfo/srvx-devel

2001	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (4)	Sep (2)	Oct	Nov	Dec
2002	Jan (15)	Feb (2)	Mar (6)	Apr (3)	May (7)	Jun (4)	Jul (1)	Aug (4)	Sep	Oct (5)	Nov (2)	Dec
2003	Jan	Feb	Mar	Apr	May	Jun	Jul (2)	Aug	Sep	Oct	Nov	Dec
2005	Jan	Feb	Mar	Apr	May	Jun (1)	Jul	Aug	Sep	Oct	Nov	Dec

srvx-devel Mailing List for srvx IRC Services

srvx-devel — srvx development discussion