Anope IRC Services
Anope Support => 1.8.x/1.7.x Support (Read Only) => Topic started by: Jan Milants on June 25, 2009, 03:06:02 PM
-
This module is now DEPRICATED.
For inspircd 1.2 support use Anope-SVN (stable/)
This module is now considered stable.
Latest version: 1.0.
Release info: http://forum.anope.org/index.php?topic=2793.msg15622#msg15622
I am looking for volunteers to test an experimental InspIRCd 1.2 protocol module for Anope 1.8. I am currently abroad and lack the resources to do extensive testing myself, therefore I am looking for some volunteers with a test network to try the protocol module out and give me some feedback.
Be aware that this is an experimental protocol module and is definitely not suited for use on a production network.
Volunteers can reply here or contact me on IRC..
Also know that this does not necessarily mean that anope 1.8 will have InspIRCd 1.2 support. The protocol module is experimental and should for now be considered 3rd party. The feedback results will determine whether the modules future..
-
I have both on my vps suitable for testing as my main server has gone back to unreal.
-
My laptop is running Linux Mint, but it works good enough to test stuff on, so I'd be happy to help beta test the module. I've been thinking of updating to 1.2 due to how well its getting reviews so far, so this would help with my network.
-
A first version has been released privately for testing purposes.. more testers are still welcome to volunteer.. :)
-
So far from testing, and reporting a couple things, the module hasn't really caused any real problems. Anope connects to Inspircd 1.2 just fine, I see no real faults, used some old backups of my live server databases to use, loaded up some extra modules and all seems to be going pretty well for an alpha.
-
Since no more obvious bugs have been reported I will make the 0.4 version of the InspIRCd 1.2 protocol module public... TwinShadow guarantees he couldn't find any more bugs, so here you go... ::)
Download: http://vips.hopto.org/~viper/inspircd12-0.4.zip
READ THE README !!! it also contains the installation instructions.
Anope 1.8.0-SVN rev 2337 is required to load the module!
Note: The protocol module requires following InspIRCd modules to be loaded:
- m_globops
- m_services_account
- m_hidechans
-
Well, its kinda like I said, I haven't been able to find anything else so far. I'm waiting a bit since my initial testing hasn't come up with anything else that might trigger some odd behavior. But from using some of the normal functions, all is pretty stable. But, as usual, if I find something odd, or not working, I'll make a post about it.
-
For now this will continue to be a third party module and it will not be included in anope 1.8.1 untill more and longer term testing is complete.
I am leaving for a roadtrip for 10 days so don't expect a quick reply or quick bug fixes should they turn up. If it is critical maybe if you ask one of the devs nicely.. :)
I haven't had time to finish the next version, that will have to wait till after I return.. ::)
If anyone uses the module on their network, please give feedback, also if it s positive..
-
I'm keen on testing this too, as I'm already running 2 networks:
1) UnrealIRCd with Anope 1.8.2 (livenet)
2) InspIRCd 1.2rc3 with Anope 1.9.0+p1 (devnet)
I'm VERY keen on switching to InspIRCd, but I'd prefer to stay with Anope 1.8.2. Will give this a test on my end too, and let you know if I run into any problems.
-
The only thing I can find wrong so far, is that if services is shutdown from the shell, and restarted again, when it relinks to the network it asks all users that have identified previously to identify again.
-
Awesome work on this module though - works very well. :)
In other news (for those of you that make use of it), if I modify the NickServ AJOIN module (ns_ajoin (db)) so that it recognizes this protocol module (inspircd12), it seems to work too. Jan, I think this is another one of your awesome modules too.
-
Something else to notice (it doesn't affect the functionality of the module though), is that services' uplink normally complains about "has not responded to PING for xx seconds, high latency.".
I'm assuming this is because of the way that services responds to PING. Perhaps the response needs a change?
-
The only thing I can find wrong so far, is that if services is shutdown from the shell, and restarted again, when it relinks to the network it asks all users that have identified previously to identify again.
I believe the services are suppose to do that, but I'm not sure entirely.
Something else to notice (it doesn't affect the functionality of the module though), is that services' uplink normally complains about "has not responded to PING for xx seconds, high latency.".
I'm assuming this is because of the way that services responds to PING. Perhaps the response needs a change?
This in particular I hadn't noticed, so who knows. o.o
-
I will look into these once I get home.. none of them seem particularly critical so no need to rush things.. :)
As for the ping issue, what inspircd snomasks do you need to be able to see this message as I've tested the basic functionality of the module myself and never noticed this issue..
-
Hello, I've recently found a serious bug, when you forbid, or suspend a nickname, services crash
(05:11:48AM) * Dawson is now known as test123
(05:11:57AM) * test123 is now known as Guest47440
(05:11:57AM) * &Phail (emo@I.dont.know.how.to.run.communities) Quit (irc.gamingsync.com services.gamingsync.com)
(05:12:01AM) <~Keith> Hmm.
(05:12:04AM) <~Keith> Just as a though.
(05:12:20AM) <Guest47440> Bye bye services.
What services notice me:
(05:20:09AM) -irc.gamingsync.com- *** NICK: User Dawson changed their nickname to Guest47081
-
(05:20:09AM) -irc.gamingsync.com- *** GLOBOPS: From NickServ: Keith used SUSPEND on DAwson
-
(05:20:09AM) -NickServ- Nick DAwson is now suspended.
-
(05:20:09AM) -irc.gamingsync.com- *** LINK: Sent ERROR to services.gamingsync.com: Invalid client introduction (wanted 10 or more parameters, got 8!)
-
(05:20:09AM) -irc.gamingsync.com- *** LINK: Server services.gamingsync.com split: Remote host closed the connection
-
(05:20:09AM) -irc.gamingsync.com- *** REMOTEOPER: User OperServ de-opered (by OperServ)
-
(05:20:10AM) -irc.gamingsync.com- *** REMOTEOPER: User ChanServ de-opered (by ChanServ)
-
(05:20:10AM) -irc.gamingsync.com- *** REMOTEOPER: User Global de-opered (by Global)
-
(05:20:10AM) -irc.gamingsync.com- *** REMOTEOPER: User NickServ de-opered (by NickServ)
-
(05:20:10AM) -irc.gamingsync.com- *** REMOTEOPER: User ProjectX de-opered (by ProjectX)
-
(05:20:10AM) -irc.gamingsync.com- *** REMOTEOPER: User HostServ de-opered (by HostServ)
-
(05:20:10AM) -irc.gamingsync.com- *** REMOTEOPER: User MemoServ de-opered (by MemoServ)
-
(05:20:10AM) -irc.gamingsync.com- *** REMOTEOPER: User Delta de-opered (by Delta)
-
(05:20:10AM) -irc.gamingsync.com- *** REMOTEOPER: User HelpServ de-opered (by HelpServ)
-
(05:20:10AM) -irc.gamingsync.com- *** REMOTEOPER: User Phail de-opered (by Phail)
-
(05:20:10AM) -irc.gamingsync.com- *** REMOTEOPER: User BotServ de-opered (by BotServ)
-
(05:20:10AM) -irc.gamingsync.com- *** LINK: Netsplit complete, lost 11 users on 1 servers.
-
(05:20:10AM) -irc.gamingsync.com- *** LINK: Connection to 'services.gamingsync.com' failed.
-
(05:20:10AM) -irc.gamingsync.com- *** LINK: Connection to 'services.gamingsync.com' was established for 7m25s
-
Logs: (I hope this is the right place in the logs
[Jul 21 04:12:44 2009] trying to load [bs_fantasy_ext]
[Jul 21 04:12:44 2009] bs_fantasy_ext loaded... [Author: Viper] [Version: 1.2.0]
[Jul 21 04:12:44 2009] status: - [Module, Okay - No Error]
[Jul 21 04:12:44 2009] Databases loaded
[Jul 21 04:12:44 2009] Info: Reflecting database records.
[Jul 21 04:12:44 2009] Connected to Server 1 (208.68.18.199:7001)
[Jul 21 04:12:44 2009] trying to load
[cs_appendtopic]
[Jul 21 04:12:44 2009] [cs_appendtopic] Loaded successfully
[Jul 21 04:12:44 2009] status: - [Module, Okay - No Error]
[Jul 21 04:12:44 2009] trying to load
[cs_enforce]
[Jul 21 04:12:44 2009] status: - [Module, Okay - No Error]
[Jul 21 04:12:44 2009] trying to load
[ns_maxemail]
[Jul 21 04:12:44 2009] status: - [Module, Okay - No Error]
[Jul 21 04:12:44 2009] trying to load
[os_info]
[Jul 21 04:12:44 2009] os_info: Loading configuration directives...
[Jul 21 04:12:44 2009] os_info: OSInfoDBName is not defined in Services configuration file, using default os_info.db
[Jul 21 04:12:44 2009] os_info: Directive OSInfoDBName loaded (os_info.db)...
[Jul 21 04:12:44 2009] status: - [Module, Okay - No Error]
[Jul 21 04:12:44 2009] trying to load
[hs_request]
[Jul 21 04:12:44 2009] hs_request loaded
[Jul 21 04:12:44 2009] status: - [Module, Okay - No Error]
[Jul 21 04:12:44 2009] Support for channelmode +K enabled.
[Jul 21 04:12:44 2009] NickServ: SSLink!mirror@gamingsync.com identified for nick SSLink
[Jul 21 04:13:06 2009] NickServ: Gunner!A.N@77.126.148.151 identified for nick Gunner
[Jul 21 04:13:30 2009] NickServ: Nick Dawson has been requested
[Jul 21 04:13:30 2009] NickServ: group Dawson has been created
[Jul 21 04:13:30 2009] NickServ: 'Dawson' registered by Dawson@S010600045ae8eeb0.ca.shawcable.net (e-mail: itzdawson@live.com)
[Jul 21 04:15:15 2009] NickServ: Keith!Keith@c-98-213-0-35.hsd1.il.comcast.net identified for nick Keith
[Jul 21 04:17:03 2009] NickServ: Darkness!Darkness@pool-173-75-244-242.phlapa.fios.verizon.net identified for nick Darkness
[Jul 21 04:20:09 2009] NickServ: Keith set SUSPEND for nick DAwson
[Jul 21 04:20:09 2009] Read error from server: No such file or directory (error num: 2)
[Jul 21 04:20:09 2009]
[bs_fantasy_ext] Loaded Core Module: bs_fantasy
[Jul 21 04:20:09 2009] [bs_fantasy_ext] Loaded Core Module: bs_fantasy_kickban
[Jul 21 04:20:09 2009] [bs_fantasy_ext]: Module Unloaded
[Jul 21 04:20:09 2009] [cs_appendtopic] Unloaded successfully
[Jul 21 04:20:09 2009] hs_request un-loaded
[Jul 21 04:20:15 2009] Loading IRCD Protocol Module: [inspircd12]
[Jul 21 04:20:15 2009] status: - [Module, Okay - No Error]
[Jul 21 04:20:15 2009] Loading Encryption Module:
[enc_sha1]
[Jul 21 04:20:15 2009] status: - [Module, Okay - No Error]
Thanks for the module, really good one..glad it works..other than that.. I haven't had a problem (yet)
-
Released version 0.5 of the protocol module.
Download it here: http://vips.hopto.org/~viper/inspircd12-0.5.zip
Tries to fix all above mentioned bugs, but because I could not reproduce the PING issue, I am uncertain whether it will actually be gone or not...
I consider this to be more of a beta version now instead of an experimental release.. other then a few minor problems, no major issues have arisen so far. ;D
-
Nicely done!
Confirmed - bugs squashed.
1) Services no longer removes +r from users that were previously identified (prior to a services restart).
2) Looks like you fixed that PING issue too (services now also displays a latency result in /MAP). Excellent work!
I've spotted another strange one though:
If I connect with a registered nickname, and fail to identify, services changes my nickname to a guest one. This is all good, but .. I can change back to it immediately, even with the 'UseSVSHOLD' option enabled.
If I check the services logs, there is mention of "user: NICK from nonexistent nick " followed by the UID assigned to my nickname.
Hope this helps.
If you need a live demo, give me a shout - my test network is at your disposal.
-
Wesley, I can only partially confirm what you reported...
There is indeed a problem with the normal system for holding a nickname: the SVSNICK syntax was incorrect causing the nick not to be changed. When I switch it to use SVSHOLD however it works fine for me. Note that for this to work, the inspircd module m_svshold must be loaded! If it isn't it will fall back to the old way of doing it.. and this one was broken :)
so note that with and without SVSHOLD enabled are 2 completely different ways of achieving the same goal.. I can only find a bug in the one that doesn't use SVSHOLD..
A version containing the fix can be downloaded here: http://vips.hopto.org/~viper/inspircd12-0.6.zip
-
Hi Jan,
I've confirmed that I'm using the m_svshold module in /MODULES:
0x0884df78 m_svshold.so -v-c :$Id$
I'm still able to change back to my original nickname after services changes it to a guest one, for both the 'UseSVSHOLD' option enabled in the Anope config, and disabled.
-OperServ- Module: inspircd12 [0.6] [Protocol]
Let me know if there is anything else you need from my end.
-
a services debug log would be nice..
-
* gives you both cookies.
-
I'm not getting anymore issues with suspending nicks or forbidding anymore.
(06:19:06AM) -irc.gamingsync.com- *** NICK: User Keith changed their nickname to Guest3523
-
(06:19:06AM) -irc.gamingsync.com- *** GLOBOPS: From NickServ: Keith used SUSPEND on Keith
-
(06:19:06AM) -NickServ- Nick Keith is now suspended.
-
(06:19:06AM) * NickServ sets mode: -r
-
Keith Nickname is already in use.
-
Keith Nickname is already in use.
-
Keith is enforcer@localhost.net * Services Enforcer
Keith is connecting from enforcer@localhost.net 0.0.0.0
Keith using services.gamingsync.com Services for GamingSync Network
Keith is using modes +
Keith End of /WHOIS list.
Forbid:
(06:31:32AM) -> *nickserv* forbid Aaron test
-
(06:31:32AM) -irc.gamingsync.com- *** NICK: User Aaron changed their nickname to Guest60924
-
(06:31:32AM) -irc.gamingsync.com- *** XLINE: services.gamingsync.com added permanent QLINE on Aaron (test).
-
(06:31:32AM) -irc.gamingsync.com- *** GLOBOPS: From NickServ: Keith used FORBID on Aaron
-
(06:31:32AM) -NickServ- Nick Aaron is now forbidden.
-
Aaron is enforcer@localhost.net * Services Enforcer
Aaron is connecting from enforcer@localhost.net 0.0.0.0
Aaron using services.gamingsync.com Services for GamingSync Network
Aaron is using modes +
Aaron End of /WHOIS list.
(06:33:34AM) -> *NickServ* drop Aaron
-
(06:33:35AM) -irc.gamingsync.com- *** XLINE: services.gamingsync.com removed QLINE on Aaron.
-
(06:33:35AM) -irc.gamingsync.com- *** GLOBOPS: From NickServ: Keith used DROP on Aaron
-
(06:33:35AM) -NickServ- Nickname Aaron has been dropped.
-
Aaron No such nick/channel
-
* End of /WHOIS list.
-
(06:33:48AM) -irc.gamingsync.com- *** NICK: User Guest60924 changed their nickname to Aaron
-
(06:37:47AM) -OperServ- Module: inspircd12 [0.6] [Protocol]
So I'm not sure but Im not getting the problem you are getting, unless it's completely different.
-
Services debug logs as requested. I've commented out public IP addresses for security reasons.
[Jul 28 15:50:47.152065 2009] debug: Received: :1EU UID 1EUAAAAAD 1248792638 mynick xxx.xxx.xxx.xxx BF38EF.981CE5.4F859A.2B4034 edge xxx.xxx.xxx.xxx 1248792643 +ix :my test nick
[Jul 28 15:50:47.152100 2009] debug: new user: mynick
[Jul 28 15:50:47.152117 2009] LOGUSERS: mynick (edge@xxx.xxx.xxx.xxx => BF38EF.981CE5.4F859A.2B4034) (my test nick) connected to the network (aurora.uk.eu.zairc.net).
[Jul 28 15:50:47.152267 2009] debug: common_svsmode(0)
[Jul 28 15:50:47.152281 2009] debug: Emitting event "newnick" (1 args)
[Jul 28 15:50:47.152318 2009] debug: Sent: :1SVAAAAAC NOTICE 1EUAAAAAD :This nickname is registered and protected. If it is your
[Jul 28 15:50:47.152348 2009] debug: Sent: :1SVAAAAAC NOTICE 1EUAAAAAD :nick, type /msg NickServ IDENTIFY password . Otherwise,
[Jul 28 15:50:47.152378 2009] debug: Sent: :1SVAAAAAC NOTICE 1EUAAAAAD :please choose a different nick.
[Jul 28 15:50:47.152409 2009] debug: Sent: :1SVAAAAAC NOTICE 1EUAAAAAD :If you do not change within one minute, I will change your nick.
[Jul 28 15:50:47.152425 2009] debug: Changing mode for mynick to +ix
[Jul 28 15:50:47.152439 2009] debug: mynick changes its host to BF38EF.981CE5.4F859A.2B4034
[Jul 28 15:50:47.153214 2009] debug: Received: :1EU METADATA 1EUAAAAAD ssl :on
[Jul 28 15:51:47.193903 2009] debug: Sent: :1SVAAAAAC NOTICE 1EUAAAAAD :Your nickname is now being changed to Guest24783
[Jul 28 15:51:47.193992 2009] debug: Sent: :1SV SVSNICK mynick Guest24783 1248792707
[Jul 28 15:51:47.234515 2009] debug: Received: :1EUAAAAAD NICK Guest24783 1248792707
[Jul 28 15:51:47.234542 2009] user: NICK from nonexistent nick 1EUAAAAAD
[Jul 28 15:52:45.172209 2009] debug: Received: :1EUAAAAAD NICK mynick 1248792765
[Jul 28 15:52:45.172232 2009] user: NICK from nonexistent nick 1EUAAAAAD
-
Hi Jan,
Think I've found my problem ..
If I enable Anope's config option "UseTS6" it seems to fix things completely. Maybe something you might want to put as a prerequisite for your module.
My bad ;D
-
The only other (mainly cosmetic) issue I can find, is that the /LUSERS output indicates that I've now got a ton of additional IRC operators.
Is there anyway this can be adjusted somehow, as not to include services clients (it includes BotServ bots too)?
-
If I enable Anope's config option "UseTS6" it seems to fix things completely. Maybe something you might want to put as a prerequisite for your module.
this already is a prerequisite, check the install instructions...
The only other (mainly cosmetic) issue I can find, is that the /LUSERS output indicates that I've now got a ton of additional IRC operators.
Is there anyway this can be adjusted somehow, as not to include services clients (it includes BotServ bots too)?
hmmm, I guess I can remove their IRCop status, but they are clients, so they cannot be hidden form the /lusers output...
and botserv bots should not be listed as opers..
-
Version 0.7 can be downloaded here: http://vips.hopto.org/~viper/inspircd12-0.7.zip
Removes unneeded ircop status from most pseudoclients and fixes an issue with registered users not being recognized as such by inspircds +R and +M modes..
-
Hi Jan,
This doesn't seem to affect the /LUSERS count for IRC operators - services clients still are included in the value.
I've found that if I comment out the "OPERTYPE" lines for both the services and BotServ clients in this module, it seems to work - must be specifically related to InspIRCd, as this adds +o regardless of the modes you set initially to any pseudo clients. A workaround would probably be removal of this mode after the OPERTYPE is sent. Not a huge issue, as its only a cosmetic one.
Otherwise, this module is looking like a winner - excellent work. Will it remain a third-party module, or do you reckon it'll eventually be included in the official distribution?
-
We discussed this feasibility some time ago and it was decided at that time that keeping it as a third party module was wise because we don't actively add 'features' to our stable releases and something this new needs to be tried and tested by a much larger userbase before it would be considered for inclusion.
Fortunately given the ease of installation this shouldn't be a problem to provide separately.
-
I'm currently using it on a public network with about 1000 á 1500 users.
For now (since latest patch) it seems to stable. However I'll keep my eyes on it.
-
I've found another bug with session limits;
[12:42:59] [roman.travian.org] *** X:Line: *@xx545348.cable.nl by OperServ [Removed]
[12:42:59] [services.travian.org] OperServ: *@xx545348.cable.nl deleted from the AKILL list.
[12:43:05] [natar.travian.org] *** Connect: Nick1!Nick1@xx545348.cable.nl
[12:43:06] [natar.travian.org] *** Connect: Nick2!Nick2@xx545348.cable.nl
[12:43:06] [roman.travian.org] *** Kill: Nick2!Blabla@xx545348.cable.nl by OperServ :(OperServ (Session limit exceeded))
[12:43:06] *** XLINE: services.traviangames.org added GLINE on *@xx545348.cable.nl to expire on Thu Jul 30 13:13:19 2009 (Session limit exceeded).
[12:43:06] [natar.travian.org] *** Quit: Nick2!Nick2@xx545348.cable.nl [OperServ (Session limit exceeded)]
[12:43:07] [natar.travian.org] *** Quit: Nick1!Nick1@xx545348.cable.nl [G-Lined: Session limit exceeded]
[12:44:20] [services.travian.org] OperServ: The host 53545348.cable.nl currently has 2 sessions with a limit of 3.
(which is not possible because they aren't connected at all (glined))
-
Version 0.8 has been released and can be downloaded here: http://vips.hopto.org/~viper/inspircd12-0.8.zip
Fixed a segfault that occured when using OS KICK on a services pseudoclient, added a check to make sure TS6 is active and it should complain less about inspircd s2s messages anope doesn't care about..
I did NOT fix the issue above reported by Sm0ke0ut as I have been unable to reproduce this or find anything wrong with it. If someone else has experienced the same issue or finds a way to reproduce, let me know.
-
Another bug found with SecureOps:
[11:33:07] * Sm0ke0ut sets mode: -qo Fuzzy Fuzzy
[11:33:21] * Notice from ChanServ: Secure ops option for #スモークアウト is now ON.
[11:33:47] * Notice from ChanServ: Access list for #スモークアウト:
[11:33:47] * Notice from ChanServ: Num Lev Nick
[11:33:47] * Notice from ChanServ: 1 SOP Sm0ke0ut
[11:33:47] * Notice from ChanServ: End of access list.
By user:
[11:34:32] * Sm0ke0ut sets mode: +o Fuzzy
(no deop)
By ChanServ:
[11:35:15] * ChanServ sets mode: +o Fuzzy
[11:35:15] * ChanServ sets mode: -o Fuzzy
(works)
-
That was actually a bug in anopes TS6 support... I fixed this in SVN so recommend all people running this module to update to latest SVN.. The next version of the protocol module will require it anyways!
-
Hi Jan,
Looks like I've found another bug. Seems to trigger when I delink an additional server.
To reproduce the error, you need to link an additional server to your network, then remove it by terminating its process. Services will SQUIT after the delink of the additional server. I've noticed that in some occasions, you need to SQUIT the additional server more than once (a second time should do the trick) to trigger this bug.
I'm using the latest SVN of Anope 1.8.* and version 0.8 of your module.
Services doesn't give any reason why it stops - it just stops dead in the water. Normally I would be able to give you logs, but even in debug mode there isn't anything other than the other server leaving the network.
[Aug 01 18:17:44.728023 2009] debug: Received: :0EU SERVER server2.mynetwork.net * 1 4SV :Second Server
[Aug 01 18:17:44.728063 2009] debug: Server introduced (server2.mynetwork.net) from 0EU
[Aug 01 18:17:44.728080 2009] debug: Emitting event "server_connect" (1 args)
[Aug 01 18:17:44.766437 2009] debug: Received: :4SV BURST 1249147064
[Aug 01 18:17:45.075169 2009] debug: Received: :4SV ENDBURST
[Aug 01 18:17:53.746639 2009] debug: Received: :server1.mynetwork.net SQUIT server2.mynetwork.net :Remote host closed the connection
[Aug 01 18:17:53.746676 2009] debug: Emitting event "server_squit" (1 args)
[Aug 01 18:17:53.746692 2009] debug: delete_server() called for server2.mynetwork.net
[Aug 01 18:17:53.746706 2009] debug: firstuser() returning MyNick
[Aug 01 18:17:53.746720 2009] debug: nextuser() returning NULL (end of list)
[Aug 01 18:17:53.746732 2009] debug: delete_server() cleared all users
[Aug 01 18:17:53.746744 2009] debug: delete_server() cleared all servers
Hope this helps.
-
This was a TS6 issue in the core.. update to the latest SVN...
-
Hi Jan,
Confirmed. Latest SVN does fix this.
I had already updated my version .. didn't realize there was another TS6 fix.
Thanks!
-
[19:11:07] * Notice from NickServ: Your nick has been logged out.
[19:11:46] <@flying_fortress> so, Sm0ke0ut try messaging Okeanos
[19:12:01] -> *Okeanos* ofc I can PM you. I'm an allmighty IRCop
[19:12:01] * Cannot join channel (+R) (trying to auto-invite)
[19:12:01] * Notice from ChanServ: Channel Okeanos doesn't exist.
[19:14:26] <@Sm0ke0ut> the message should be more like
[19:14:37] <@Sm0ke0ut> 'This user doesn't not accept messages from unregistrered users'
However you can talk to them when you're identified, I do think that message should be more like:
"This user doesn't not accept messages from unregistrered users"
I've no debug log, however I think this should be enough =)
-
What client do you use? I know some get thrown off by +R.
My plain mirc shows it correctly "You need to be identified to a registered account to message this user"
-
Actually this has nothing to do with anope... :)
The IRCd handles the user and channelmodes +R.. Anope simply marks a user a registered by setting +r and setting the metadata for the account name. After that everything is handled by InspIRCd. And this particular message - though I d have to look this up - might not even be send by InspIRCd, but is likely send as a numeric, which the users' client then translates into a message in the users set language.
Anope isn't even informed of this kind of stuff.. :)
-
Haven't had a issue as of yet :)
Thanks for this great mod!
-
Version 0.9 has been released and can be downloaded here: http://vips.hopto.org/~viper/inspircd12-0.9.zip
This fixes a number of issues of which the most important are:
- session tracking: when killing clients on servers other then the uplink the user was not deleted.
- fixed KILL syntax
- fixed issue where people would be able to take over other nicks while services are down. the protocol module now uses the metadata to auto-ID users instead of the +r usermode.
Upgrading is recommended, but keep in mind because some changes are quite big it s possible some new bugs might have slipped in...
Also, for now, you will need to modify the anope core before you can install the protocol module. In the archive is a users.patch which must be applied to svn (2452 or newer), or simply replace the src/users.c in anopes source with the one in the archive (this is for svn 2452). If the core changes are stable, I will commit these to SVN so you won't have to patch the core again in the future..
-
Might I suggest adding usermode +k to each of the pseudo clients. It'll protect them from being killed from the network (like UnrealIRCd's +S) - also seems to add a 'is a <network> Service' to WHOIS output.
-
With the release of InspIRCd 1.2.0 I think the time is right to release version 1.0 of my protocol module. I now consider the module to be stable and suitable for use on any production network.
I dare even say this module is more flexible then the one that ships with Anope-1.9 :) though more exotic setups are much less tested and may still be prone to a few bugs. The module *should* detect the presence of InspIRCd modules such as m_chanprotect or the disabling of halfop, but this is still largely untested.
This release fixes a minor bug in SVSNICK and in the BURST syntax.
Download: http://vips.hopto.org/~viper/inspircd12-1.0.zip
Might I suggest adding usermode +k to each of the pseudo clients....
I looked into this, but I can't do this (without making the module a requirement) for the version I release for Anope without more changes to the core. The module can be easily edited to include the +k user mode though for those that wish to use it.
I do have a slightly improved version of the InspIRCd protocol module which dynamically detects m_servprotect and adds the +k usermode, however it requires you run a more modified version of Anope. If you want to try it, you can find my modified version of anope, incl the protocol module and core changes in my git repository's master: http://vips.hopto.org/git/?p=anope/.git;a=shortlog;h=refs/heads/master
Note though that it does include other patches, such as the -1 access level for unregged users, and more (ex nefarious support) may be added later on depending on my needs...
If you just want the changes required to anope and the "regular" protocol module look here (http://vips.hopto.org/git/?p=anope/.git;a=commitdiff;h=d0c6f97dae9e1021a07168e86fe8ef596ea210e8;hp=de52365b2b9b22ed7bbc28eda3eb720cc04a4690).
-
Further to my news post acknowledging Inspircd's release of 1.2 as stable we've made the following available for download.
A copy of the latest stable 1.8.2 svn (as at 1st of September 2009) with Viper's changes and inspircd 1.2 support.
Please can you all test this out and put it through its paces before we can consider building it into 1.8.3.
http://www.anope.org/downloads/anope-1.8.2-svn-insp12-support.tar.gz
http://www.anope.org/downloads/anope-1.8.2-svn-insp12-support.md5sum.txt
-
Any windows pre complied versions? the latest 1.8 svn doesent even complile under win.
edit: 1.9 svn doesent either.
edit: 1.8 does under vs 2005 not 2008.
-
My laptop with my windows build env is currently rma so I can't help you with that atm... maybe chaz can do it on the windows build env he uses for regular anope releases?
-
the above anope-1.8.2-svn-insp12-support.tar.gz compiles fine under vs 2005 just needs one edit in the file...
src\protocol\Makefile.win32
make sure inside it reads
SRCS=bahamut.c charybdis.c dreamforge.c hybrid.c inspircd11.c inspircd12.c plexus2.c plexus3.c ptlink.c rageircd.c \
ratbox.c shadowircd.c solidircd.c ultimate2.c ultimate3.c unreal31.c unreal32.c viagra.c
compile and it works with inspircd 1.2 :D
-
Hi,
With pleasure.
MySQL Disabled (default) http://www.anope.org/downloads/Anope-1.8.2-with-insp12.exe
MySQL Enabled: http://www.anope.org/downloads/Anope-1.8.2-with-insp12-MySQL.exe
-
Any windows pre complied versions? the latest 1.8 svn doesent even complile under win.
edit: 1.9 svn doesent either.
edit: 1.8 does under vs 2005 not 2008.
Since I've been building Anope releases (mid 1.7.x) I've always built them with VS 2005 and have no plans to change this as it would mean everyone having to update their VC++ runtimes if they hadn't already.
Several module authors though have compiled their modules with VS 2008 which has already forced the above but I see no reason to change the default build.
For 1.9, I will check this and see what is happening.
-
Since the InspIRCd module has reached 1.0, to avoid confusion, could we released it under Anope 1.8.3? That will reduce confusion where to download the right version where the person could accidentally download a beta version of the module from the Main Page.
-
1.8.3 will be released when we're ready; there's more to it than *just* InspIRCd 1.2 support.
The advice is clear enough on the home page of the site for the use of InspIRCd 1.2, if people can't read to click a link there's little else we can do.
-
Got a new problem (I think.)
When trying to jupe a server (a non-existent server, but I don't think that should matter), I get an error back from InspIRCD, and then disconnected.
[Jan 09 20:41:10.529218 2010] OperServ: jeian: jupe o.hai.there
[Jan 09 20:41:10.530703 2010] debug: Sent: SERVER o.hai.there <servicespassword> 1 7CA :Juped by jeian
[Jan 09 20:41:10.531219 2010] debug: Creating o.hai.there(7CB) uplinked to services.cairc.dev
[Jan 09 20:41:10.532796 2010] debug: Sent: :7CAAAAAAB SNONOTICE g :jeian used JUPE on o.hai.there
[Jan 09 20:41:10.532961 2010] debug: Received: ERROR :Server ID 7CA already exists! You may want to specify the server ID for the server manually with <server:id> so they do not conflict.
After this, InspIRCD closes the connection, and Anope quits. I had a look at the code myself, and I noticed that in inspircd_cmd_server(), there appears:
send_cmd(NULL, "SERVER %s %s %d %s :%s", servname, currentpass, hop, TS6SID, descript);
So it appears to me that whenever Anope introduces a JUPEd pseudo-server to the rest of the network, it always tells the network that the pseudoserver has the same SID as Anope itself. Then in the line after inspircd_cmd_server(), I see:
new_server(me_server, jserver, rbuf, SERVER_JUPED, ts6_sid_retrieve());
Which creates a new SID to be put into the new struct for the juped server?
It's 3AM and my knowledge of the InspIRCD protocol is somewhat lacking, so I could be way off, but that seems a little odd. "_" Any help would be appreciated.
-
Problem got cleared up since the first release of the protocol module.
I dont get the problem on my testnet.
InspIRCd-1.2 Anope-1.8.2-svn (2731)
NEW
send_cmd(NULL, "SERVER %s %s %d %s :%s", servname, currentpass, hop,
sid ? sid : TS6SID, descript);
ORIGINAL
send_cmd(NULL, "SERVER %s %s %d %s :%s", servname, currentpass, hop, TS6SID, descript);
-
Problem got cleared up since the first release of the protocol module.
I dont get the problem on my testnet.
InspIRCd-1.2 Anope-1.8.2-svn (2731)
NEW
send_cmd(NULL, "SERVER %s %s %d %s :%s", servname, currentpass, hop,
sid ? sid : TS6SID, descript);
ORIGINAL
send_cmd(NULL, "SERVER %s %s %d %s :%s", servname, currentpass, hop, TS6SID, descript);
Interesting, the code in both the Anope 1.8.2 with InspIRCd 1.2 Support 1.0 Stable and the stand alone module 1.0 have the Original code, not the new code as you have stated.
-
Check out the latest 1.8-svn.
-
most likely because i'm using anope from svn, although I do wonder how it wasn't noticed before if it is an issue in the supposedly "stable" version, i guess thats a result of people not actually testing the module properly when it was first released as experimental, if people don't test properly before it is considered stable, it'll happen.
-
Yep, the svn is different than the "stable" and stand alone releases. Thanks for the info guys, we'll have to update it via the svn.
-
Just for the record, nor the anope 1.8 release with insp 1.2 support, nor the original 3rd party inspircd1.2 protocol module are maintained...
Once the module was included into anope svn, both became depricated and several important fixes for inspircd 1.2 support have been applied to svn since.
Maintaining 3 seperate (and different) versions is a bit too much of a good thing...
-
Good to know, I'll rebuild from SVN later today. Thanks all!