RE: [NeoStats-Devel] [Commits] r174 - branches/3.0

Justin Hammond wrote:
> > Justin Hammond wrote:
> > > > +/*  TODO:
> > > > + *  - Akill support.
> > > > + *  - remove akill must check whether an akill was added by
> > > > opsb before
> > > > + *    removing it otherwise blsb becomes a way for opers to 
> > > > remove any
> > > > + *    akill on the network including those they may not 
> > > > normally have
> > > > + *    access to.
> > > > + */
> > > > +
> > > 
> > > 
> > > I'm looking at the existing ban support in NeoStats, and 
> this seems
> > > troublesome:
> > > 1) if NeoStats restarts, bans are lost and only resent from the 
> > > IRCd. How does NeoStats then know what Bot placed the ban?
> > 
> > opsb/neostats ought to maintain a list of bans it has 
> placed as with 
> > any services package. Given that there are potentially 3 separate 
> > modules which could place bans, this is likely better 
> provided in the 
> > core.
> > In addition to
> > providing a remove function for bans placed by NeoStats modules, it 
> > could provide a list mechanism without the need to tell 
> uers to use an 
> > IRCd side command to determine the bans placed.
> > 
> > However, correctly formatted ban messages would allow us to not 
> > maintain a local list yet still determine that neostats or a bot 
> > placed a ban. Most ircds maintain the name of the operator 
> who set a 
> > given ban but those that don't merely need to encode the 
> name of the 
> > bot into the ban reason and we can extract this when required.
> > 
> 
> Maybe getting NeoStats to maintain the ban list and a new 
> module, to handle management of bans? Then this could handle 
> all bans, regardless if NeoStats set it or not? My experience 
> with other service packages is that they don't really support 
> bans not set by themselves, so this might come in usefull?

The only reason we store the bans provided from the IRCd was in response to
a request by Trystan for statistical purposes. I do not think that providing
a list for statistical reasons is a good reason to also provide a management
console for them. It also seems pretty pointless to provide such a system
since it is already provided at the IRCd level or through services if they
manage the bans.

> > Completed ban support would also be likely the best way to 
> determine 
> > the method used by NeoStats in determining ownership of a 
> given ban. 
> > Given that every ircd provides a way to remove bans placed by any 
> > operator, a remove command in NeoStats is just nice to have 
> so there 
> > is no need to provide one at all. As mentioned in the TODO comment, 
> > allowing the removal of any ban from NeoStats is likely to provide 
> > opers an ability to remove bans they may not usually be 
> authorised to 
> > remove so IMO, if we cannot restrict it to removing bans we own, we 
> > should not provide the functionality at all.
> 
> Configurable maybe? Service roots can remove any, where 
> standard opers can only remove a subset of bans?

Since services already handles appropriate access for their bans and the
IRCd handles removal of IRCd issues bans, this system already exists without
us supporting it at all. I see no benefit in NeoStats being able to remove
bans it did not set. The only benefit in being able to remove bans it did
set is if as with services packages it offered a view of only bans set by
it. 

Why reinvent the wheel?

Mark.