View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1738 [Anope Stable (2.0.x series)] General major always 2020-06-07 01:12 2020-06-07 01:12
Reporter: westor Platform:  
Assigned To: OS:  
Priority: urgent OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: BotServ: DONTKICKOPS and DONTKICKVOICES doesn't added on db_flatfile
Description: Hello,

I using 2.0.8-git , when i am trying to set DONTKICKOPS and DONTKICKVOICES on a channel it doesn't adding the following values on database, when i shutdown the services and adding them manually it seems to work.

DATA BS_DONTKICKOPS 1
DATA BS_DONTKICKVOICES 1

- Thanks!
Tags:
Steps To Reproduce: /cs register #channel
/bs set dontkickops #channel on
/bs set dontkickvoices #channel on
/bs info #channel
There are not listed under Options:
Then
/os restart
/bs info #channel
There are not even saved on db_flatfile database
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1737 [Anope Development (1.9.x series)] Other major always 2020-05-02 03:29 2020-05-02 03:29
Reporter: therock247uk Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: building under windows
Description: goes fine here but this warning appears on running Config.exe: The OLD behavior for policy CMP0026 will be removed from a future version
of CMake.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1722 [Anope Stable (2.0.x series)] General minor always 2019-05-01 13:56 2020-05-01 00:36
Reporter: Koragg Platform: Linux/Unix  
Assigned To: OS: Debian  
Priority: normal OS Version: Debian 9/Stretch  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: cs set persist off does not always unset chanmode +P on the first time setting it off
Description: It appears that if someone does /cs set persist #chan off for the first time, +P is unset as normal, but every subsequent time if persist is set on, then persist must be set off TWICE to unset +P. This issue occurs on InspIRCd and UnrealIRCd confirmed. InspIRCd 2.0.17 and UnrealIRCd 4.2.3-rc1

Tags:
Steps To Reproduce: 1) Register a channel and run /cs set persist #chan on (or have persist in the default options for newly registered channels, it occurs in both cases).

2) /cs set persist #chan off (unsets +P as intended)

3) /cs set persist #chan on (sets +P as intended)

4) /cs set persist #chan off (from now on, one must run this command TWICE for +P to be unset on #chan and this is a multi IRCd issue, occuring on InspIRCd and UnrealIRCd for sure, likely on others as well).

Only solution to +P not being unset on /cs set persist #chan off on the first try is running the command twice.
Additional Information: This requires a persistent/permanent channel mode on the IRCd, often (always?) channel mode +P thus it might be that ALL IRCd's employing such a channel mode are effected by this bug.
Attached Files:
Notes
(0006872)
Lord255   
2020-02-15 13:35   
hello.
this issue affects unreal v5.0.1 and 5.0.3.1 as well with anope v2.0.7.

so the issue is: have to do persist off twice to remove +P and the persist option from info.



--> joined the chan
* Now talking in #test123
* xxxxxxxxx sets mode: +nt


--> registered the channel, persist default set in chanserv.conf
* ChanServ (services@services.xxx) has joined #test123
* ChanServ sets mode: +rPaoq ChanServ ChanServ Lord255

--> cs info
-ChanServ- Information for channel #test123:
-ChanServ- Founder: Lord255
-ChanServ- Registered: Feb 15 05:14:53 2020 CST (17 seconds ago)
-ChanServ- Last used: Feb 15 05:15:10 2020 CST (now)
-ChanServ- Ban type: 2
-ChanServ- Mode lock: +ntP
-ChanServ- Options: Peace, Security, Secure founder, Signed kicks, Persistent, Topic retention

--> had to do cs set persist # off twice to remove +P
-ChanServ- Channel #test123 is no longer persistent.
-ChanServ- Channel #test123 is no longer persistent.
* ChanServ sets mode: -P

--> testing again, setting persist on
-ChanServ- Channel #test123 is now persistent.
* ChanServ sets mode: +P

--> disable persist; between options its still there, +P still set.
-ChanServ- Channel #test123 is no longer persistent.
-ChanServ- Information for channel #test123:
-ChanServ- Founder: Lord255
-ChanServ- Registered: Feb 15 05:14:53 2020 CST (1 minute ago)
-ChanServ- Last used: Feb 15 05:16:14 2020 CST (now)
-ChanServ- Ban type: 2
-ChanServ- Mode lock: +nt
-ChanServ- Options: Peace, Security, Secure founder, Signed kicks, Persistent, Topic retention

--> hitting disable again; CS removes +P and the option is gone
-ChanServ- Channel #test123 is no longer persistent.
* ChanServ sets mode: -P
-ChanServ- Information for channel #test123:
-ChanServ- Founder: Lord255
-ChanServ- Registered: Feb 15 05:14:53 2020 CST (1 minute ago)
-ChanServ- Last used: Feb 15 05:16:31 2020 CST (now)
-ChanServ- Ban type: 2
-ChanServ- Mode lock: +nt
-ChanServ- Options: Peace, Security, Secure founder, Signed kicks, Topic retention

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1736 [Anope Stable (2.0.x series)] General minor always 2020-02-13 17:18 2020-02-13 17:18
Reporter: Digerati Platform: Linux  
Assigned To: OS: Debian  
Priority: normal OS Version: 9  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Email Registration Confirmation Not Sent for Nicks Ending in \ Character
Description: With registration = mail set in the ns_register module, when attempting to register a nick ending with the \ character, Anope reports that the registration confirmation email was successfully delivered, but it doesn't get delivered.

Note, this bug might occur with other characters, and at positions in the nick other than at the end. I've only tested this one scenario, with a nick ending with the \ character.
Tags:
Steps To Reproduce: 1. /nick Digerati\
2. /msg nickserv register testpass email@example.com

This shows, "Your email address is not confirmed. To confirm it, follow the instructions that were emailed to you." to the user attempting to register, and the #services output shows, "Successfully delivered mail for Digerati\ (email@example.com)", but no email is delivered.
Additional Information: Following the Steps to Reproduce, but starting with /nick Digerati (without the \ character at the end), results in the confirmation email being delivered as expected.

This is 100% reproducible with Unreal 4.2.4.1 and Anope 2.0.7.
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1221 [Anope Development (1.9.x series)] MemoServ feature N/A 2010-12-26 20:41 2020-02-13 17:04
Reporter: CereaL Platform:  
Assigned To: DukePyrolator OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: /memoserv read all
Description: What's chances of having a "read all" command for MemoServ ?

There's a "del all" command .. so yeah can this be swapped around?

Thanks :D
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006871)
DukePyrolator   
2020-02-13 17:04   
fixed in 2015.
https://github.com/anope/anope/pull/135

(0006747)
AlphaTech   
2015-07-17 17:17   
Since this was requested, I added Pull request 0000130 on GitHub.

https://github.com/anope/anope/pull/130
(0006555)
Yoerger   
2013-12-16 17:21   
This is an interesting idea. I suppose it's possible, but the concept already exists in a different feature. (See Above). Not that my opinion matters at all.
(0006005)
Robby   
2011-11-04 12:08   
As someone above already pointed out, you already can do this in another way:
Lets say you have for example 16 memos, then you do this: /MS READ 1-16
and it will show you all the memos from 1 to 16 at once.
Also, MemoServ will show you all new memos at once if you do: /MS READ NEW

See /MS HELP READ for full details.

So, in a way, this already exists anyway.
(0005989)
someone   
2011-10-30 14:36   
i liked that idea too, BUT read all should definitely be default disabled and config enableable.

Why: if you have a limit of 100 memos/user they wont type /quote ms read 1-100 very often, but i fear they would type read all.

So if you have a more relaxed memo limit (we have a limit of 500 and me and some other users have ~400 memos), it would generate quite a lot traffic, if you had like 20 users that would "read all" every x mins... (services reaching ircd sendq limit and getting disconnected ;)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1713 [Anope Stable (2.0.x series)] General crash have not tried 2018-02-23 11:08 2020-02-11 19:37
Reporter: simos Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Anope 2.0.5 Crash
Description: anope@Hub:~/services$ gdb bin/services core
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/anope/services/bin/services...(no debugging symbols found)...done.
[New LWP 15525]
[New LWP 15526]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/home/anope/services/bin/services'.
Program terminated with signal 11, Segmentation fault.
#0 __strlen_sse42 () at ../sysdeps/x86_64/multiarch/strlen-sse4.S:32
32 ../sysdeps/x86_64/multiarch/strlen-sse4.S: No such file or directory.
(gdb) bt full
#0 __strlen_sse42 () at ../sysdeps/x86_64/multiarch/strlen-sse4.S:32
No locals.
0000001 0x000000000047e42f in ci::less::operator()(Anope::string const&, Anope::string const&) const ()
No symbol table info available.
0000002 0x00007f588d1d439c in CommandNSAList::ChannelSort(ChannelInfo*, ChannelInfo*) () from lib/modules/ns_alist.so
No symbol table info available.
0000003 0x00007f588d1d8ec5 in void std::__insertion_sort<std::_Deque_iterator<ChannelInfo*, ChannelInfo*&, ChannelInfo**>, bool (*)(ChannelInfo*, ChannelInfo*)>(std::_Deque_iterator<ChannelInfo*, ChannelInfo*&, ChannelInfo**>, std::_Deque_iterator<ChannelInfo*, ChannelInfo*&, ChannelInfo**>, bool (*)(ChannelInfo*, ChannelInfo*)) () from lib/modules/ns_alist.so
No symbol table info available.
0000004 0x00007f588d1d9449 in void std::__final_insertion_sort<std::_Deque_iterator<ChannelInfo*, ChannelInfo*&, ChannelInfo**>, bool (*)(ChannelInfo*, ChannelInfo*)>(std::_Deque_iterator<ChannelInfo*, ChannelInfo*&, ChannelInfo**>, std::_Deque_iterator<ChannelInfo*, ChannelInfo*&, ChannelInfo**>, bool (*)(ChannelInfo*, ChannelInfo*)) () from lib/modules/ns_alist.so
No symbol table info available.
0000005 0x00007f588d1dc097 in void std::sort<std::_Deque_iterator<ChannelInfo*, ChannelInfo*&, ChannelInfo**>, bool (*)(ChannelInfo*, ChannelInfo*)>(std::_Deque_iterator<ChannelInfo*, ChannelInfo*&, ChannelInfo**>, std::_Deque_iterator<ChannelInfo*, ChannelInfo*&, ChannelInfo**>, bool (*)(ChannelInfo*, ChannelInfo*)) () from lib/modules/ns_alist.so
No symbol table info available.
0000006 0x00007f588d1dc464 in CommandNSAList::Execute(CommandSource&, std::vector<Anope::string, std::allocator<Anope::string> > const&) () from lib/modules/ns_alist.so
No symbol table info available.
0000007 0x0000000000464d0b in Command::Run(CommandSource&, Anope::string const&, CommandInfo const&, std::vector<Anope::string, std::allocator<Anope::string> >&) ()
No symbol table info available.
0000008 0x0000000000465af4 in Command::Run(CommandSource&, Anope::string const&) ()
No symbol table info available.
0000009 0x0000000000450b9a in BotInfo::OnMessage(User*, Anope::string const&) ()
No symbol table info available.
0000010 0x0000000000494d70 in Message::Privmsg::Run(MessageSource&, std::vector<Anope::string, std::allocator<Anope::string> > const&) ()
No symbol table info available.
0000011 0x00000000004c337f in Anope::Process(Anope::string const&) ()
No symbol table info available.
0000012 0x00000000004e584a in UplinkSocket::ProcessRead() ()
No symbol table info available.
0000013 0x00000000004e16ca in SocketEngine::Process() ()
No symbol table info available.
0000014 0x000000000044380d in main ()
No symbol table info available.
(gdb) quit
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006870)
Lord255   
2020-02-11 19:37   
thx simos. i have noticed that after the update.. updated a few cases, didn't see the date first.. nvm what i thought..
this ticket should be closed by now. :)
(0006869)
simos   
2020-02-11 18:38   
It’s a 2018 report ...
(0006867)
Lord255   
2020-02-10 23:39   
since v2.0.7 is out, i would recommend to just update.. and btw random cores ? :o
haven't had any with v2.0.7

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1705 [Anope Stable (2.0.x series)] General major always 2017-05-30 07:12 2020-02-10 23:41
Reporter: Kaj Platform: Anope 2.0.4  
Assigned To: OS: Ubuntu  
Priority: normal OS Version: 16.04.2 LTS  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: m_irc2sql module not compatible with MySQL 5.7
Description: When using a MySQL database version 5.7, the m_irc2sql module will not work.
The services boot and operate successfully but the corresponding tables anope_chan and anope_user will stay empty.
Tags:
Steps To Reproduce: 1. Configure m_mysql to use a MySQL database of version 5.7
2. Enable the m_irc2sql module
3. Start the services and pass on the --debug flag

After booting the services, the anope_chan and anope_user tables will remain empty and in the logfiles a lot of errors like the following are being logged:

[May 29 09:10:35.933274 2017] m_irc2sql: Error executing query INSERT INTO `anope_chan` (channel, topic, topicauthor, topictime, modes) VALUES ('#Chan','','','0','') ON DUPLICATE KEY UPDATE channel=VALUES(channel), topic=VALUES(topic),topicauthor=VALUES(topicauthor), topictime=VALUES(topictime), modes=VALUES(modes): Incorrect datetime value: '0' for column 'topictime' at row
Additional Information: Works perfectly with MySQL 5.6 OR when disable sqlmode STRICT_TRANS_TABLES on MySQL 5.7

Since mysql version 5.7 - sqlmodes were introduced, including the mode STRICT_TRANS_TABLES which is enabled by default:

From MySQL 5.7.4 through 5.7.7, STRICT_TRANS_TABLES includes the effect of the ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, and NO_ZERO_IN_DATE modes


Anope forum post related to this issue: https://forum.anope.org/index.php?topic=4374.0
Attached Files:
Notes
(0006868)
Lord255   
2020-02-10 23:41   
i'm pretty sure that this was fixed already.

i have v2.0.7, mysql v5.7 and irc2sql works fine.

ii mysql-server-5.7 5.7.29

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1729 [Anope Stable (2.0.x series)] General major always 2019-12-14 18:18 2020-02-10 23:36
Reporter: ivp Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: geoipupdate.sh not working
Description: geoipupdate.sh is trying to fetch MaxMind GeoIP data from non-existing URLs:
https://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip
https://geolite.maxmind.com/download/geoip/database/GeoLiteCity_CSV/GeoLiteCity-latest.zip

Those are GeoIP Legacy CSV Databases:
https://dev.maxmind.com/geoip/legacy/csv/

The latest one are here:
https://dev.maxmind.com/geoip/geoip2/geoip2-city-country-csv-databases/
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006866)
Lord255   
2020-02-10 23:36   
as ivp said, however the script still can be used if you tweek it a little and dl the right csv for yourself.
(0006863)
ivp   
2019-12-14 19:14   
(Last edited: 2019-12-14 19:16)
GeoLite Legacy databases are already discontinued on January 2, 2019.

We should use GeoLite2 Free Downloadable Databases:
https://dev.maxmind.com/geoip/geoip2/geolite2/

And probably GeoIP2 CSV Format Converter:
https://github.com/maxmind/geoip2-csv-converter

(0006862)
jobe   
2019-12-14 19:08   
Its also worth noting that simply changing the URL's won't be sufficient as the new CSV format is different from the old.

Not to mention this should be dealt with sooner rather then later as the legacy databases are no longer being updated anyway.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1735 [Anope Stable (2.0.x series)] General minor always 2020-01-25 05:01 2020-02-10 23:33
Reporter: jerrylynn Platform: Linux  
Assigned To: OS: CentOS  
Priority: normal OS Version: 7  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: SVSHOLD
Description: When services sets a nickname to Guest???? because the user failed to identify it sets a svshold on the unrealircd 4.x . I know this is what is supposed to happen but we have the releasetimeout set to 1 minute and services does that fine except it doesn't remove the svshold from the ircd. It takes the ircd around 25 minutes to release the svshold unless you manually set a sqline for the nick and immediately remove it. Our uline servers are set properly with the correct case sensitivity.
anope-2.0.7
unrealircd 4.0.3.1
Tags:
Steps To Reproduce: Login with a registered nickname but do not identify. After the nick gets guested wait until releasetimeout has released the nick then try and change back to the registered nick. WIll reproduce the error.
Additional Information: After the time out occurs in services you can check the ircd /stats Q and see the nickname still listed.
Attached Files:
Notes
(0006865)
Lord255   
2020-02-10 23:33   
with unreal v5.0.1 i couldn't reproduce this.
after the release, qline was gone.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1734 [Anope Stable (2.0.x series)] General major always 2020-01-10 00:53 2020-01-10 00:53
Reporter: barghain Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: NS CONFIRM token from NS RESETPASS confirms a user
Description: This issue is related to nickserv/confirm. When an unconfirmed user use a CONFIRM command given by RESETPASS in email (i.e. CONFIRM [nick] [securitytoken]), his nick is automatically confirmed as would have confirmed by an operator.

I think this behavior is not usual and password recovery should not confirm an unconfirmed user, thus I consider it a bug. I have found it in all earlier versions including the latest 2.0.7.
Tags:
Steps To Reproduce: 1. Enable "ns_register" module with `registration = "admin"` option in order to manually approve nicks.

2. Register as a new user normally e.g. /ns register password email
   Right now the nick status is unconfirmed and only should be approved by an administrator

3. Now a user could easily bypass the restriction and become confirmed by sending himself a /ns resetpass token and using it. The /ns confirm command crafted by resetpass makes him a confirmed user.
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1732 [Anope Stable (2.0.x series)] General major always 2019-12-15 02:34 2019-12-15 14:47
Reporter: simos Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Bad Italian translation
Description: I please you back to old 2.0.6 italian translation, it was not complete but it wasn't full of error like now (grammar and syntax)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1731 [Anope Stable (2.0.x series)] General feature always 2019-12-14 20:17 2019-12-14 20:17
Reporter: ivp Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Translate webcpanel
Description: It would be nice to separate language phrases from webcpanel templates, to be able to translate it easily without messing with HTML.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1730 [Anope Stable (2.0.x series)] General minor always 2019-12-14 18:35 2019-12-14 18:35
Reporter: ivp Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Always use display for memo source
Description: What is the reason for reverting commit "Always use display for memo source":
https://github.com/anope/anope/commit/d8a945b1a6f4e500bcb9162cf388f6984ad38328
https://github.com/anope/anope/commit/1c82697ccbf85359e86ec815bd66a74803c7ac3f
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1726 [Anope Stable (2.0.x series)] General tweak have not tried 2019-10-13 23:59 2019-10-13 23:59
Reporter: Mrmot Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: OperServ umode command add mode +P
Description: We added module for "user white list" same as +D in unrealircd (deaf) no private from other users.

+P mode allows you to block all privates for you but allow people on white list so they can write to you.

At this moment os umode command is not working (not setting mode on user).

3:49:14 -OperServ- Changed usermodes of xxxx to +P.

° ------ Whois xxxx ------
°     ime Kiwi
°   email ~Kiwi1
°   modovi +iwxzDGT
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1724 [Anope Stable (2.0.x series)] General minor always 2019-07-22 23:01 2019-07-24 08:33
Reporter: simos Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: NS SET KILL doesn't update fields on mysql table
Description: Running /NS SET KILL have some problem updating data on mysql.

NS SET KILL on work fine and set 1 on KILLPROTECT sql field
NS SET KILL quick work fine and set 1 on KILL_QUICK sql field
NS SET KILL immed work fine and set 1 on KILL_IMMED sql field

everything look work fine until you have set KILL QUICK or KILL IMMED , than sql data are no more correctly updated, ns set kill off, ns set kill immed and ns set kill quick set right value for your account but not on mysql table, this until you run NS SET KILL ON again wich update mysql table settings KILLPROTECT to 1 and NULL on the other.

Not tested on mysq live.
Tags:
Steps To Reproduce: trying the steps in description.
Additional Information:
Attached Files:
Notes
(0006857)
genius3000   
2019-07-24 08:33   
I can reproduce this using m_sqlite and both db_sql and db_sql_live.
In exact order:
NS SET KILL on: updates the DB
NS SET KILL quick: updates the DB
NS SET KILL immed: does not update the DB
NS SET KILL off: does not update the DB
NS SET KILL on: updates the DB
NS SET KILL off: updates the DB

It seems like "on" helps reset the issue and the next command works, but then they stop working.
(0006856)
simos   
2019-07-24 00:54   
I've set debug on and look for query, it seems that anope don't execute query if immed or quick is set until you run again ns set kill on .

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1723 [Anope Stable (2.0.x series)] General minor always 2019-06-04 17:18 2019-06-05 21:01
Reporter: linuxdaemon Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: SSL HTTP listeners are not reloaded when certificates are updated and a config reload is triggered
Description: When updating SSL certificates (for instance, let's encrypt certs which have to be updated every 3 months), HTTP listeners using SSL will not receive the new SSL certs on a config reload. In order for the certs to take effect, the m_httpd module must be completely reloaded or the HTTP listener ip/port must be changed.
Tags: m_httpd, ssl
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1721 [Anope Stable (2.0.x series)] General feature N/A 2019-04-02 12:58 2019-04-02 12:58
Reporter: pegasus Platform: Linux  
Assigned To: OS: Ubuntu  
Priority: normal OS Version: 18.04.2 LTS  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: GDPR compliance - a flag (probably by default) to allow users to opt-out from the !seen command
Description: Right now, when a user execute the !seen command, we always get an answer.
For more privacy of the users, we should be able to opt-out from that feature.

Cheers
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1720 [Anope Stable (2.0.x series)] General minor always 2019-03-29 12:09 2019-03-29 12:09
Reporter: Koragg Platform: Linux/Unix  
Assigned To: OS: Debian  
Priority: normal OS Version: Debian 9  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: /cs mode does not check if the person executing it has permission to set a +L channel as redirect
Description: When using /cs mode to set modes, the channel mode +L on InspIRCd and UnrealIRCd can be used to redirect people to a channel once a channel limit has been reached.
The issue is, that /cs mode does not check whether the person using /cs mode to set +L has permission to set said redirect channel (the IRCd would check for ops on InspIRCd and owner on UnrealIRCd).
This could be abused to set a very low channel limit and redirect join everyone to another channel (it respects join restrictive modes, but this is an issue for channels that want to in general allow everyone in).

Tags:
Steps To Reproduce: 1. Have a user be identified to his NickServ account and have his own channel # OR one where he has access to /cs mode hereby reffered to as #A

2. Have the user from 1. execute /cs mode #A set +L #B OR /cs mode #A lock add +L #B whereby this user has NO access in #B whatsoever

3. Observe how Anope (through the respective BotServ bot or, if non present, through ChanServ) sets +L #B even though this user has no ChanServ access in #B whatsoever (and also no (half)ops or higher status prefix)
Additional Information: This bug effects all IRCd's that have a +L channel mode for redirects on reachec channel limits and could possibly effect IRCd's with other forms of redirects as well, for example CharybdisIRCd with chanmode +f (this is untested though a distinct possibility unfortunately).
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1358 [Anope Stable (2.0.x series)] General feature N/A 2011-11-03 20:09 2019-01-08 05:42
Reporter: Robby Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: A notify/flag system that notifies opers that a client matching a pattern has connected to the network
Description: This is maybe a rather big and complex feature request, but since 1.9 is in dev and new features are being added I can only try.

So, it's for notifying IRCops when a client matching a pattern in the form of nick!ident@address (where address is a hostname or IP/CIDR, even if their IP resolves to a hostname), perhaps even match against the gecos field of the connecting client.

Currently I have an opered bot running that provides this functionality and outputs to a specific IRCop-only channel (and thus not the log channel as else it would be easily missed as things scroll by). We currently use this to find abusive and malicious clients more easily. Of course there's always some false positives depending on the pattern used but that's not something services should care about. The bot does the following:
- pattern matching against connecting clients and say if a matching connecting client was found and add it to memory/list in case they change nicks
  it outputs like this: NOTIFY: Connected: nick (~ident@address) (gecos)
- take into account nickchanges (explained further below)
  outputs like this: NOTIFY: Nickchange: oldnick -> newnick
- say when they quit (including quit message) and remove user from memory/list
  outputs like this: NOTIFY: Quit: nick (~ident@address) [quitreason]

It would be nice if Anope had something like this aswell.

This system should however also keep track of nickchanges that the client could possibly do and output those to the notifychannel aswell, especially when using patterns in the form of *abuser*!*@* because if the user changes his nick from Abuser44 to EvilUser for example, the pattern wouldn't match anymore. Also, link the pattern matched to the user, for example for use in /OS NOTIFY CLIENTS (explained below).

If this were to get approved, I'm thinking a command syntax like AKILL should be used:
NOTIFY ADD [+expiry] mask reason
^- maybe add a switch for when mask should match against the gecos and not a hostmask
NOTIFY DEL {mask | entry-num | list | id}
^- also this command should remove/cleanup any clients in CLIENTS when the pattern they were matched by gets removed unless they still match another pattern, in which case the entry in CLIENTS should be updated
NOTIFY LIST [mask | list | id]
NOTIFY VIEW [mask | list | id]
NOTIFY CLEAR
And the addition of a CLIENTS subcommand:
NOTIFY CLIENTS -> This one lists clients online found after a match, with their current nickname including their ident@address, and the pattern against which they matched, like this:
-OperServ- Current notify-matched clients online:
-OperServ- 1 nick (~ident@address) - realname
-OperServ- Matched against: pattern
-OperServ- Reason: reason
For example:
<Robby> NOTIFY CLIENTS
-OperServ- Current notify-matched clients online:
-OperServ- 1 Abuser44 (~abuser@blah-874864.isp.com) - Bleh Blah
-OperServ- Matched against: *abuser*!*@*
-OperServ- Reason: Abusive user
-OperServ- 2 EvilUser (~abuser@blah-874864.isp.com) - All Your Base
-OperServ- Matched against: *abuser*!*@*
-OperServ- Reason: Abusive user
Maybe also have CLIENTS take a pattern as parameter, like LIST and VIEW already do.

And a configurable notifychannel (an IRCop-only channel for example) in the OperServ configuration file.

Output to the notifychannel should ideally be similar to my current bot but with some slight changes:
Connecting (if matching against hostmask):
<OperServ> NOTIFY: Connected: nick (~ident@address) [Matched against <pattern>]
Connecting (if matching against gecos):
<OperServ> NOTIFY: Connected: nick (~ident@address) (gecos) [Matched against <pattern>]
Changing nick:
<OperServ> NOTIFY: Nickchange: oldnick -> newnick
Quit:
<OperServ> NOTIFY: Quit: nick (~ident@address) [quitreason]


Maybe also add a switch to the ADD command to flag the matched client for extra "surveillance", so that it also shows what the client does on the network. For example: the channels it joins, parts, gets kicked from, or what modes or topics it sets on those channels (can help in finding a botnet(-master)), or if it kicks someone from a channel or when it changes it's own umodes (in short: everything :P). Output to the notifychannel something like this:
<OperServ> FLAGGED: nick joined #channel
<OperServ> FLAGGED: nick left #channel
<OperServ> FLAGGED: nick was kicked from #channel
<OperServ> FLAGGED: nick has kicked othernick from #channel --> should be disableable
<OperServ> FLAGGED: nick sets mode on #channel: <mode> --> should be disableable
<OperServ> FLAGGED: nick sets topic on #channel: <topic> --> should be disableable
<OperServ> FLAGGED: nick sets umode: <umode> --> should be disableable
Note that I left out part and kick messages, as this is not really needed here, it's just to get an idea of what the client does on the network.



I'll leave it at this for now as this is getting fairly long.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006854)
genius3000   
2019-01-08 05:42   
Would love to see this implemented in 2.1/3.0 yet. For 2.0, I've wrote a 3rd party module: https://modules.anope.org/index.php?page=view&id=283
(0006556)
Yoerger   
2013-12-19 06:35   
I like this idea.
(0006129)
cronus   
2012-03-29 22:30   
I'm all for it, Possibly even expand it further somehow.
(0006128)
MathK1LL   
2012-03-29 16:19   
I love this idea.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1719 [Anope Stable (2.0.x series)] General major always 2018-12-21 20:46 2018-12-21 20:46
Reporter: daemhan Platform:  
Assigned To: OS: Ubuntu  
Priority: normal OS Version: 16.04.5 LTS  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: sql_live not reflecting database updates/new entries client-side
Description: Module: sql_live
SQL: sqlite
Anope Version: 2.0.5

Conf annotations state: "This module reads and writes to SQL in real time. Changes to the SQL tables will be immediately reflected into Anope."

I am finding that this is not the case. Changes or insertions to the NickCore table are not reflecting services-side when requesting information client-side.
Tags:
Steps To Reproduce: Used:
UPDATE
INSERT INTO

UPDATE successfully changes any given value in the database, but it is not reflected when calling /ns info via IRC client.
* tried updating email on previously registered nickname
* tried changing display name on previously registered nickname

INSERT INTO the NickCore table successfully inserts values for new nicknames, but issuing /ns info [nickname] returns [nickname] is not registered. Example:
sqlite> select * from anope_db_NickCore where display = 'testnick01';
18251|2018-12-21 00:14:40|1|1|1|1|1|1|1||testnick01|tester@redacted.email||20|bcrypt:$2a$10$hashpass|1|||||||1||||||

* -NickServ- Nick testnick01 isn't registered.
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1718 [Anope Stable (2.0.x series)] General minor always 2018-12-17 15:32 2018-12-17 15:32
Reporter: Koragg Platform: Linux  
Assigned To: OS: Debian  
Priority: normal OS Version: Debian 9  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ChanServ keepmodes does not restore InspIRCd +w listmode (autoop) on channel recreation
Description: When a channel has /cs set keepmodes #channel on set and any number of +w list mode entries (autoop module/mode) are set (InspIRCd specific mode), once the channel is destroyed and recreated, the +w list modes are NOT restored.
Tags:
Steps To Reproduce: 1. Register a channel
2. /cs set keepmodes #channel on
3. set any valid +w mode (e.g. +v on all users authed: /mode #channel +w v:R:*)
4. Have the channel be destroyed by everyone /PART'ing it (if persist is on, also /cs set persist #channel off)
5. /JOIN the channel and use /mode #channel +w to view the +w list. It will only reply with "#channel End of channel access list" meaning the list is empty.
Additional Information: This is an InspIRCd specific issue/mode. This was confirmed to occur on InspIRCd 2.0.27 and Anope 2.0.6
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1716 [Anope Stable (2.0.x series)] General minor always 2018-08-08 13:42 2018-08-08 13:42
Reporter: capitaine Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: List for unregistered users
Description: Unregistered users can't list channels nor registered nicks.
I thought it was configurable and tried to change the permission attribute of commands, but it seems hardcoded.
Tags:
Steps To Reproduce: /NickServ LIST *
/ChanServ LIST *
Answer : Access denied for unregistered user
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1712 [Anope Stable (2.0.x series)] General minor always 2018-02-13 23:48 2018-06-12 16:17
Reporter: Koragg Platform: Linux  
Assigned To: Adam OS: debian  
Priority: normal OS Version: debian 9  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: /os umode cannot set/unset inspircd-extras user modes while /os mode can set/unset channel modes
Description: In Anope 2.0.6 when user modes are added from the inspircd-extras repository on github for InspIRCd 2.0.25 then /os umode states it sets/unsets those user modes from a user but the user does not actually get them set (as can be seen if an oper or the user performs a /whois).
Oddly channel modes added in from the same inspircd-extra respository can be set/unset from channels via /os mode
This behaviour is confirmed to occur on InspIRCd 2.0.25 and Anope 2.0.6
Tags:
Steps To Reproduce: 1. use /os umode to set/unset inspircd-extras user modes on a user
2. perform a /whois and see that the mode was not set/unset through OperServ
   despite the notice it sent out.
Additional Information:
Attached Files:
Notes
(0006853)
Adam   
2018-06-12 16:17   
Fixed in https://github.com/anope/anope/pull/214
(0006850)
genius3000   
2018-02-14 05:59   
To add to this issue, currently SNOMASK 's' cannot be set/unset using OS UMODE. With the proposed fix, it can be set/unset but you cannot add/remove parameters. I haven't looked into why that is, maybe Adam (or others) can find that cause easier.
(0006849)
genius3000   
2018-02-14 05:57   
Proposed fix: https://github.com/anope/anope/pull/214

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1715 [Anope Stable (2.0.x series)] General minor sometimes 2018-03-04 01:09 2018-03-27 03:19
Reporter: linuxdaemon Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Header parsing in webcpanel is not case-insensitive
Description: If a browser sends a cookie header as 'cookie: data' instead of 'Cookie: data', the web panel does not parse it as a cookie. Header names should be parsed case-insensitively. If a browser sends a cookie in this fashion, the user is unable to log in at all.
Tags: webcpanel
Steps To Reproduce: 1. Get your cookie data from a valid login to the anope web panel
2. curl 'anope.my.website/nickserv/info' -H 'cookie: data' --location
3. You will be redirected to 'anope.my.website' due to not being logged in.
Additional Information: Google Chrome (Version 64.0.3282.186 (Official Build) (64-bit)) appears to send the cookie header in this fashion, causing a user to be unable to log in to the web panel.
Attached Files:
Notes
(0006852)
Adam   
2018-03-27 03:19   
Fixed in d25722ddd0766cba2c33614e326d241d3f1f7eeb
(0006851)
linuxdaemon   
2018-03-04 01:13   
See: https://github.com/elm-lang/http/issues/31
It appears this is planned for more browsers and will become standard.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1714 [Anope Stable (2.0.x series)] General minor always 2018-02-28 19:35 2018-02-28 19:35
Reporter: Takkun Platform: Linux  
Assigned To: OS: Centos  
Priority: normal OS Version: 7  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Compiling with MySQL
Description: I'm running the test in this OS and environments

Centos7, kernel 3.10.0-693.17.1.el7.x86_64
Mariadb101u(server,devel,libs)
Mariadb-5.5.56-2.el7(server,devel,libs)
cmake version 2.8.12.2
git-2.9.5
Anope 2.0-git(1baf77464)

Compile Log: http://pastebin.anope.org/index.php?page=viewpaste&id=267cf30e80
Tags:
Steps To Reproduce: 1. Run ./Config with:
   - /usr/include/mysql and /usr/lib64/mysql as include and library paths
2. Run ./Extras with:
   - m_mysql.cpp enabled
3. cd build && make
Additional Information:
System Description Kernel 3.10.0-693.17.1.el7.x86_64
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1711 [Anope Stable (2.0.x series)] General major have not tried 2018-01-07 15:57 2018-01-07 16:01
Reporter: albus Platform: anope-2.0.6  
Assigned To: OS: Linux  
Priority: high OS Version: Debian amd64  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ChanServ set restricted #channel on do not work correctly
Description: I'm using anope-2.0.6 with m_mysql extra module, then when i set restricted mode for any channel it doesn't work i do not why do that, and anybody can access to opers channel even users unregistered.
Tags: ChanServ
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006848)
albus   
2018-01-07 16:01   
I'm using anope-2.0.6 with m_mysql extra module, then when i set restricted mode for any channel it doesn't work i do not why, and anybody can access to opers channel even if i have a unregistered user.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1710 [Anope Development (1.9.x series)] Operserv feature N/A 2017-12-22 06:18 2017-12-22 06:18
Reporter: Techman Platform: Linux  
Assigned To: OS: Ubuntu  
Priority: low OS Version: 16.04 x86_64  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: 2.0: Optionally disable the 2-day XLine cap behavior
Description: I noticed that in anope/anope:master, the 2-day XLine cap was removed. I would love if this was optionally backported to 2.0, either as a permanent thing or an optional feature to preserve existing behavior.

I believe others would appreciate this as much as I would because I currently use Anope to manage all of my network bans outside of the automated stuff like HOPM.

Reference commit: https://github.com/anope/anope/commit/2cb0d9057bf1968d36168a76e25f4cf4d3b33fbf
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1709 [Anope Stable (2.0.x series)] General minor have not tried 2017-11-02 02:10 2017-11-03 03:35
Reporter: MuffinMedic Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Removing temporary ban retains scheduled ban removal
Description: If a temporary ban is set through ChanServ and then removed through ChanServ using the BAN or UNBAN commands, and then reapplied manually by an operator, the ban is still removed at the originally scheduled time.
Tags:
Steps To Reproduce: (1) Set temporary ban through ChanServ on user
(2) Remove ban on user through ChanServ
(3) Manually set identical ban in same channel
(4) Wait for ChanServ ban to expire - will still be removed
Additional Information: October 29, 2017
[17:12:15] <MuffinMedic> !kb +3d SuperThirstyUser Too much thirst.
[17:12:15] *** SuperThirstyUser was kicked by ChanServ (Too much thirst. (MuffinMedic))
[17:12:15] *** ChanServ sets mode: +b *!*@user/SuperThirstyUser
[17:12:15] -ChanServ- Ban on *!*@user/SuperThirstyUser expires in 3 days.
[17:27:11] -MuffinMedic- Unban SuperThirstyUser #channel
[17:27:11] *** ChanServ sets mode: -b *!*@user/SuperThirstyUser
[17:27:11] -ChanServ- SuperThirstyUser has been unbanned from #channel.
[17:27:17] *** MuffinMedic sets mode: +b *!*@user/SuperThirstyUser

November 1, 2017
[17:12:07] *** ChanServ sets mode: -b *!*@user/SuperThirstyUser
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1703 [Anope Stable (2.0.x series)] General crash always 2017-04-14 11:38 2017-07-25 01:38
Reporter: Absolver Platform: Anope 2.0.5  
Assigned To: Adam OS: Ubuntu 14.04 LTS  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Malformed XML crashes XMLRPC
Description: Sending malformed XML to the XMLRPC handler crashes Anope.
Tags:
Steps To Reproduce: 1) Set up Anope 2.0.5 with XMLRPC enabled
2) Verify that XMLRPC is up and running
3) Send the following XML to XMLRPC:
<?xml version="1.0" encoding="iso-8859-1"?>
<methodCall>
    <methodName>checkAuthentication</methodName>
    <params>
        <param>
            <value>
                <string>randomuser</string>
                <string>randompassword</string>
            </value>
        </param>
    </params>
</methodCall

(Note the missing closing > in the methodCall end tag)
Additional Information: Debug log information from sending the malformed XML:
Apr 14 12:33:04.147078 2017] Accepted connection 10 from 84.202.160.14
[Apr 14 12:33:04.335267 2017] m_httpd: Serving page /xmlrpc to 84.202.160.14
[Apr 14 12:33:04.335323 2017] m_xmlrpc: Tag name: ?xml version="1.0" encoding="iso-8859-1"?, data:

[Apr 14 12:33:04.335368 2017] m_xmlrpc: Tag name: methodCall, data:

[Apr 14 12:33:04.335415 2017] m_xmlrpc: Tag name: methodName, data: checkAuthentication
[Apr 14 12:33:04.335460 2017] m_xmlrpc: Tag name: /methodName, data:

[Apr 14 12:33:04.335504 2017] m_xmlrpc: Tag name: params, data:

[Apr 14 12:33:04.335548 2017] m_xmlrpc: Tag name: param, data:

[Apr 14 12:33:04.335594 2017] m_xmlrpc: Tag name: value, data:

[Apr 14 12:33:04.335647 2017] m_xmlrpc: Tag name: string, data: xlexious
[Apr 14 12:33:04.335685 2017] m_xmlrpc: Tag name: /string, data:

[Apr 14 12:33:04.335725 2017] m_xmlrpc: Tag name: string, data: <removed>
[Apr 14 12:33:04.335763 2017] m_xmlrpc: Tag name: /string, data:

[Apr 14 12:33:04.335801 2017] m_xmlrpc: Tag name: /value, data:

[Apr 14 12:33:04.335838 2017] m_xmlrpc: Tag name: /param, data:

[Apr 14 12:33:04.335875 2017] m_xmlrpc: Tag name: /params, data:

Attached Files:
Notes
(0006845)
Adam   
2017-07-25 01:38   
Fixed in 3cb9e0b97c15e2d997d519b4bfc1821252c2384d

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1704 [Anope Stable (2.0.x series)] General minor always 2017-04-14 11:57 2017-07-24 23:50
Reporter: Absolver Platform: Anope 2.0.5  
Assigned To: Adam OS: Ubuntu 14.04 LTS  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: NICKSERV GROUP through XMLRPC still does not group nicks
Description: Although fixed in 2.0.5, XMLRPC calls to group nicks still does not actually group nicks.
Tags:
Steps To Reproduce: 1) Register a main nick testnick with password test1234
2) Attempt to group testnick2 with testnick through XMLRPC with NICKSERV GROUP testnick test1234
3) XMLRPC reports SUCCESS, but grouping does not happen.

Happens both with testnick2 being unregistered when grouping is attempted, and with testnick2 registered in nickserv before attempting to group.
Additional Information:
Attached Files:
Notes
(0006844)
Adam   
2017-07-24 23:50   
Fixed in https://github.com/anope/anope/commit/0b7b6d9d6d55fc0398fb330e95c43e1c34c6ae2d

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1702 [Anope Stable (2.0.x series)] General minor always 2017-03-18 03:08 2017-03-18 21:30
Reporter: pegasus Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: NS KeepModes not set upon nick registration even with ns_keepmodes on NS defults
Description: Since i've started using Anope v2.x series, i have ns_keepmodes enabled on the NS defaults, on nickserv.config.
Recently i've found that upon nick registration, the keepmodes option is not being set to the registered user.
Tags:
Steps To Reproduce: Enable ns_keepmodes on NS defaults.
Register a new nick.
Do /ns info nick
Check NS options enabled (keepmodes isn't there).
Additional Information: Here's what i have on NS defaults on nickserv.conf:

defaults = "ns_secure ns_private hide_email hide_mask memo_signon memo_receive autoop ns_keepmodes killprotect"


After registering a new nick, i've done /ns info to myself (as shown below, keepmodes isn't present even after being enable on NS defaults)

[01:30] -NickServ-: Registered: Mar 18 00:27:06 2017 WET (2 minutes ago)
[01:30] -NickServ-: Options: Private, Protection, Security, Auto-op, Chanstats
Attached Files:
Notes
(0006838)
Adam   
2017-03-18 21:30   
Fixed in 3545e8e3836df214db4ec8c7b4e57843a1971d37
(0006837)
Adam   
2017-03-18 21:18   
This looks like the documentation is wrong, should be ns_keep_modes.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1697 [Anope Stable (2.0.x series)] General minor always 2017-02-20 15:38 2017-02-21 22:57
Reporter: NoMiaus Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Deleting extended bans with OperServ
Description: Anope can't delete extended bans (UnrealIRCd) such as ~q with OperServ MODE.
Tags:
Steps To Reproduce: 1. /mode #Channel +b ~q:whatever!*@*
2. /msg OperServ MODE #Channel -b ~q:whatever!*@*
Additional Information:
Attached Files:
Notes
(0006835)
Adam   
2017-02-21 22:57   
Fixed in a1d7d42d6aa1e9cb7546fdd689854b0a654901a9

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1698 [Anope Stable (2.0.x series)] General minor always 2017-02-20 15:44 2017-02-21 22:57
Reporter: NoMiaus Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: FORBID DEL deletes a simular rule because of wildcards
Description: FORBID DEL doesn't delete choosen rule because there's a similar rule using wildcards.
Tags:
Steps To Reproduce: 1. /msg OperServ FORBID ADD NICK +0 Whatever Reason
2. /msg OperServ FORBID ADD NICK +0 *Whatever* Reason
3. /msg OperServ FORBID DEL NICK Whatever
4. *Whatever* is deleted instead of Whatever
Additional Information:
Attached Files:
Notes
(0006834)
Adam   
2017-02-21 22:57   
Fixed in 3f7c0829efb1d3af8f7a0e8092c6dadb2ed041e8
(0006827)
NoMiaus   
2017-02-20 15:47   
Maybe Anope should delete Whatever when adding *Whatever* or should warn about rules matching the same.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1700 [Anope Stable (2.0.x series)] General minor always 2017-02-20 17:13 2017-02-20 17:28
Reporter: NoMiaus Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Access denied on adding XOP levels
Description: ACCESS_LEVEL 10
PROTECT (founder only)

SECUREFOUNDER is off

Users with level 10 can't add VOP, HOP and AOP.
Users with level 10000 can add VOP and HOP but can't add AOP, SOP and QOP.
'Real' founder can add all of them.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006833)
Adam   
2017-02-20 17:28   
XOP doesn't let you add someone with a privilege that you don't have. The xop privileges are all configurable, so saying "VOP" etc doesn't mean anything. It works if you use a default configuration.

The issue tracker isn't for support, use irc.anope.org #anope for that.
(0006832)
NoMiaus   
2017-02-20 17:16   
Sorry, I meant ACCESS_CHANGE instead of ACCESS_LEVEL.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1699 [Anope Stable (2.0.x series)] General minor always 2017-02-20 15:52 2017-02-20 16:39
Reporter: NoMiaus Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: FOUNDER level can change and use 'founder only' LEVELS
Description: Users are level 10000 (FOUNDER) on ACCESS can change and use 'founder only' LEVELS. Only the real founder should be able to do it.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006831)
NoMiaus   
2017-02-20 16:36   
(Last edited: 2017-02-20 16:39)
Ah, I understand now. Maybe text on HELP LEVELS should be rewriten to make any reference to SECUREFOUNDER and 'founder only' option deleted from the LIST. Using the number (10000) only seems clearer on that case. I think it can be confusing.

(0006830)
Adam   
2017-02-20 16:25   
"founder" in the help refers to users with the privilege "founder" on the channel. The only difference between having the founder privilege and being the /cs set founder, is the /cs set founder can do things through securefounder (mostly /cs set other founders and drop the channel). With securefounder off, there is no difference.

I guess that the existence of a founder-only level doesn't really need to exist because you could (in the case of access) just set its level to the level you assign the founder privilege to. I think it is a 1.8isim we never really removed.
(0006829)
NoMiaus   
2017-02-20 16:11   
(Last edited: 2017-02-20 16:15)
Then I don't understand why 'founder only' level exists if 'FOUNDER' and 'founder only' have the same access and can do the same. It's writen on /msg ChanServ HELP LEVELS.

(0006828)
Adam   
2017-02-20 15:57   
It is the intended behavior that users with founder-level access can use founder-level levels. Why should only the "real founder" be able to do it?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1696 [Anope Stable (2.0.x series)] General major have not tried 2017-01-28 04:15 2017-01-29 23:11
Reporter: Mecmec51 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Anope 2.0.4 (and 2.0.5) with Unrealircd 3.2.10 and channels in "+s" mode do not insert/update in sql
Description: Conversation of January 28, 2017 for a bug with sql and only the mode "+s"

[01:35:03] <Mi_92> Hi, In Anope 2.0.4 with Unrealircd 3.2.10 and channels in "+s" mode do not register in sql, is this repaired in Anope 2.0.5?
[01:37:35] <@Adam> "do not register"?
[01:37:57] <Mi_92> Adam yes "update" or "insert"
[01:39:21] <@Adam> are you talking about irc2sql?
[01:39:30] <@Adam> anope doesnt store +s channels otherwise because that doesnt make any sense
[01:39:38] <@Adam> i mean, it does, but it doesnt store the fact that it is
[01:40:45] <Mi_92> Adams, yes irc2sql and StatsServ from Anope. It does not accept, we have to put all the caux secret in "-s" and then we must put the "+s" and there it works but it is temporary until another (re)start of anope
[01:40:57] <Mi_92> canaux*
[01:41:15] <Mi_92> channels*
[01:43:32] <Mi_92> Adam At the moment all the channels in mode "+s" have not been updated in sql but the other modes-channels have been taken into.
[01:43:38] <Mi_92> There is only the "+s" and "-s" that bug
[01:48:38] <@Adam> i dont know if it was fixed in 2.0.5 or not
[01:48:46] <@Adam> you could always try it and if it isnt then open a bug, then someone will look at it
[01:54:26] <Mi_92> Adam, ok ,I specify for the bug:: All the channels since January 10 they have : " /cs mode #carla LOCK add +CinrstTVé - There is only the "+s" that does not register in "sql" unless you make a "/cs mode #carla LOCK del +s" very forced several times and after you retype" /cs mode #carla LOCK add +CinrstTV " and it works again but not forever if we restart Anope
[01:54:34] <Mi_92> Adam i test Anope 2.0.5
[01:55:02] <@Adam> bugs.anope.org is where the bugtracker is, register for it on login.anope.org
[01:55:48] <Mi_92> Adam Ok I will do this if needed, thank, salutations
[01:55:51] * Disconnected
Session Close: Sat Jan 28 01:55:56 2017

I installed Anope 2.0.5 and the bug still exists.


Excuse me for my English, I'm French.

Salutations
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006826)
Mecmec51   
2017-01-29 23:11   
I posted a message a few days ago here, on http://bugs.anope.org/view.php?id=1696 it is possible to remove this subject because the problem does not come from Anope but only from DenoraIRC 1.5, I will reinstall the 1.4.

Salutations.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1695 [Anope Stable (2.0.x series)] General minor always 2017-01-11 12:03 2017-01-12 03:49
Reporter: knux Platform: Linux  
Assigned To: Adam OS: Ubuntu  
Priority: normal OS Version: 14.04  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: UnrealIRCd4 says "SENDUMODE is a server only command" on OperServ's GLOBOPS
Description: When OperServ sends a GLOBOPS for example when adding an AKILL, only opers connected to the ircd to which anope are linked will see the notice.

Using strace to anope's pid, I always see this log:
write(13, "[d\303\251c. 22 15:52:58 2016] ADMIN: Boo!Boo@ircservicesdev01.prodin.orbus.fr (SkyBoo) used AKILL on *test@test.fr (Plouf), expires in 300 jours [affects 0 user(s) (0%)]\n", 165) = 165
epoll_wait(6, {{EPOLLOUT, {u32=8, u64=8}}}, 4, 5000) = 1
sendto(8, ":services.skyrock.net TKL + G *test test.fr Boo 1482591178 1482418378 :Plouf (ID: 5ATSY3XCCS)\r\n:OperServ NOTICE Boo :\2*test@test.fr\2 added to the AKILL list.\r\n:OperServ GLOBOPS :ADMIN: Boo!Boo@ircservicesdev01.prodin.orbus.fr (SkyBoo) used AKILL on *test@test.fr (Plouf), expires in 300 jours [affects 0 user(s) (0%)]\r\n", 319, 0, NULL, 0) = 319
epoll_ctl(6, EPOLL_CTL_MOD, 8, {EPOLLIN, {u32=8, u64=8}}) = 0
epoll_wait(6, {{EPOLLIN, {u32=8, u64=8}}}, 4, 5000) = 1
recvfrom(8, ":ircdev01.prodin.orbus.fr 487 OperServ :SENDUMODE is a server only command\r\n", 65534, 0, NULL, NULL) = 76

Same situation using "/msg Global GLOBAL test" command:
sendto(4, ":00BAAAAAD GLOBOPS :ADMIN: KnuX!KnuX@fw01.prodin.orbus.fr (KnuX) used GLOBAL \r\n:00BAAAAAD NOTICE $ircdev01.prodin.orbus.fr :[KnuX] test\r\n:00BAAAAAD NOTICE $ircdev02.prodin.orbus.fr :[KnuX] test\r\n:00BAAAAAD NOTICE $channels.skyrock.net :[KnuX] test\r\n:00BAAAAAD NOTICE $boo.skyrock.net :[KnuX] test\r\n", 298, 0, NULL, 0) = 298
epoll_ctl(3, EPOLL_CTL_MOD, 4, {EPOLLIN, {u32=4, u64=4}}) = 0
epoll_wait(3, {{EPOLLIN, {u32=4, u64=4}}}, 4, 5000) = 1
recvfrom(4, ":ircdev02.prodin.orbus.fr 487 Global :SENDUMODE is a server only command\r\n", 65534, 0, NULL, NULL) = 74

Tags:
Steps To Reproduce: Assuming this situation:
ircdev01.prodin.orbus.fr (5) 201
|-services.skyrock.net (6) 00B
`-ircdev02.prodin.orbus.fr (2) 202
End of /MAP

When adding an AKILL (or else), opers on ircdev01 will receive the globops but not opers on ircdev02.
Additional Information: ircdev01.prodin.orbus.fr (5) 201
|-services.skyrock.net (6) 00B
`-ircdev02.prodin.orbus.fr (2) 202
End of /MAP
Attached Files:
Notes
(0006825)
Adam   
2017-01-12 03:49   
Thanks, fixed in a4f7d847abdde8f070a201417a456067d3beb4a1
(0006824)
jobe   
2017-01-12 01:09   
For reference the associated UnrealIRCd bug can be found at https://bugs.unrealircd.org/view.php?id=4836
(0006823)
jobe   
2017-01-12 00:30   
(Last edited: 2017-01-12 00:30)
Ok, so having looked into the code in depth regarding this issue, this bug is the result of 2 factors.

Factor 1 is that Anope's use of GLOBOPS for UnrealIRCd 4 when it has been deprecated in favour of SENDUMODE
Factor 2 is UnrealIRCd's compatibility handling of the old GLOBOPS command by simply converting it to SENDUMODE without taking into account the fact that GLOBOPS can be sent from a user when SENDUMODE cannot

So suggested fix in this case is 2 fold, for Anope's side the suggestion is to use SENDUMODE for UnrealIRCd 4 (note this requires using a server as the source and typically involves prefixing the message with "from <nick>: " in the same way UnrealIRCd 4 does when it receives a GLOBOPS from a directly connected user) and the second part is that I will report this bug to UnrealIRCd too.

(0006822)
Adam   
2017-01-12 00:01   
Thanks for the report. If you could reproduce this with ./services -support that would be most helpful. Thanks.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1694 [Anope Stable (2.0.x series)] General minor have not tried 2017-01-03 14:05 2017-01-03 23:54
Reporter: ivp Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Nickname registration via webcpanel doesn't report 'registration' type to the user
Description: When users registers nickname using webcpanel it always writes "Nickname ... registered."

Depending on "registration" setting for ns_register module, webcpanel should display more details.

E.g. if having registration = "mail", there should be information that user should check his mailbox as the next step.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006821)
Adam   
2017-01-03 23:54   
The log message from users registering with webcpanel was already fixed in https://github.com/anope/anope/commit/b3010c3c6b2a938c28ff10ab67f09528f0c91896. I think that registration = "mail" already works.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1693 [Anope Stable (2.0.x series)] General minor always 2016-11-30 12:00 2016-11-30 23:55
Reporter: Gavin Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: duplicate  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Adding user to cs access list -1 cause cs to voice
Description: Adding a user to the access list of chanserv with a value "-1" or "-2" makes chanserv voice the user in the channel

[11:48:29] <+ChanServ> COMMAND: Gavin used ACCESS on #zairc to add ManlyMan!*@* with level -1

[11:48:29] * ChannelBot sets mode: +v ManlyMan
Tags:
Steps To Reproduce:
Additional Information: Version - Anope-2.0.4
Attached Files:
Notes
(0006818)
Adam   
2016-11-30 23:55   
I believe this was already fixed in https://github.com/anope/anope/commit/dba19d839af717a697ed54ed5da9c27aef76052a.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1691 [Anope Stable (2.0.x series)] General minor always 2016-11-05 16:57 2016-11-05 17:17
Reporter: Robby Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: SECUREOPS applies to services operators with the chanserv/administration privilege
Description: When a channel has SECUREOPS enabled, a services operator with the chanserv/administration privilege can not op themselves through ChanServ on that channel, but an OVERRIDE message is logged, as if it had been successfully executed.
Tags:
Steps To Reproduce: Have an opertype with the chanserv/administration privilege.

/CS SET SECUREOPS #chan ON
/CS OP #chan
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1688 [Anope Stable (2.0.x series)] General minor always 2016-09-16 18:28 2016-11-05 17:07
Reporter: capitaine Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: XMLRPC NickServ GROUP does not group
Description: When running NickServ Group by XMLRPC, it replies with Success but group fails.
Tags:
Steps To Reproduce: Run the following command :
php -r "include 'xmlrpc.php'; var_dump(\$anope->command('NickServ', 'foo', 'REGISTER nothing test@example.com')); var_dump(\$anope->command('NickServ', 'foofoo', 'GROUP foo nothing'));"


replies with :

array(2) {
  ["result"]=>
  string(7) "Success"
  ["return"]=>
  string(126) "Le pseudo foo est maintenant enregistré.&#xA;Votre mot de passe est nothing - notez-le pour une utilisation ultérieure.&#xA;"
}
array(1) {
  ["result"]=>
  string(7) "Success"
}


It should also returns "You are now in the group of foo", or an error message.
Additional Information:
Attached Files:
Notes
(0006815)
Adam   
2016-11-05 17:07   
Added in 8be331618c4a49a8cb77624056c88a03fa847571
(0006810)
Adam   
2016-09-16 23:20   
This is intentional behavior in 2.0.4, I'll see if I can fix it in 2.0.5.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1679 [Anope Stable (2.0.x series)] General minor always 2016-05-28 21:53 2016-11-05 16:37
Reporter: capitaine Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: IRC2SQL does not update status modes
Description: From IRC2SQL, users status modes like +vho are updated only on join, but not when staying in a channel.
Tags:
Steps To Reproduce: /MODE #Foo +vho John

mysql> SELECT i.modes FROM irc_user AS u, irc_ison AS i, irc_chan AS c WHERE u.nick = "John" AND c.channel = "#Foo" AND u.nickid = i.nickid AND c.chanid = i.chanid;

+-------+
| modes |
+-------+
| |
+-------+
Additional Information: Suggested fix attached
Attached Files: 0001-IRC2SQL-update-status-modes.patch (1,712 bytes) 2016-05-28 21:53
https://bugs.anope.org/file_download.php?file_id=360&type=bug
Notes
(0006814)
Adam   
2016-11-05 16:37   
Thanks, fixed in a5fdf7c546ccb0f70a70543ea8afb54d155a13cc
(0006795)
cronus   
2016-05-29 02:54   
Didn't notice you used another table, Im use to JOINs on other tables :P
(0006794)
capitaine   
2016-05-28 22:07   
I know, my report is about ison.modes, not tables channels.modes nor user.modes
(0006793)
cronus   
2016-05-28 21:58   
That table has modes for user modes, not channel modes. The Channel modes you seek are in the "ison" table.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1689 [Anope Stable (2.0.x series)] General crash always 2016-10-11 21:12 2016-11-04 05:04
Reporter: Absolver Platform:  
Assigned To: Adam OS: Linux  
Priority: normal OS Version: Ubuntu 14.04 LTS  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: XMLRPC call to NickServ SET EMAIL causes immediate crash
Description: Calling NickServ to perform a SET EMAIL on a user causes Services to immediately crash, with no useful output to debug log.
Tags:
Steps To Reproduce: 1) Register a nick with NickServ
2) Enable XMLRPC and send the command SET EMAIL foo@bar.com as the registered nick.
3) Anope crashes.
Additional Information: services.log for when the crash occurs:
[Oct 11 20:47:05.228552 2016] Accepted connection 12 from xxxx
[Oct 11 20:47:05.561847 2016] m_httpd: Serving page /xmlrpc to xxxxx
[Oct 11 20:47:05.561894 2016] m_xmlrpc: Tag name: ?xml version="1.0" encoding="iso-8859-1"?, data:

[Oct 11 20:47:05.561926 2016] m_xmlrpc: Tag name: methodCall, data:

[Oct 11 20:47:05.561938 2016] m_xmlrpc: Tag name: methodName, data: command
[Oct 11 20:47:05.561949 2016] m_xmlrpc: Tag name: /methodName, data:

[Oct 11 20:47:05.561959 2016] m_xmlrpc: Tag name: params, data:

[Oct 11 20:47:05.561969 2016] m_xmlrpc: Tag name: param, data:

[Oct 11 20:47:05.561979 2016] m_xmlrpc: Tag name: value, data:

[Oct 11 20:47:05.561989 2016] m_xmlrpc: Tag name: string, data: NickServ
[Oct 11 20:47:05.561999 2016] m_xmlrpc: Tag name: /string, data:

[Oct 11 20:47:05.562009 2016] m_xmlrpc: Tag name: string, data: Rid[XB][US]
[Oct 11 20:47:05.562019 2016] m_xmlrpc: Tag name: /string, data:

[Oct 11 20:47:05.562029 2016] m_xmlrpc: Tag name: string, data: SET email xxxxx@gmail.com
[Oct 11 20:47:05.562039 2016] m_xmlrpc: Tag name: /string, data:

[Oct 11 20:47:05.562049 2016] m_xmlrpc: Tag name: /value, data:

[Oct 11 20:47:05.562058 2016] m_xmlrpc: Tag name: /param, data:

[Oct 11 20:47:05.562068 2016] m_xmlrpc: Tag name: /params, data:

(Crash)

[Oct 11 20:47:47 2016] SERVER: services.fuelrats.com (Services for Fuel Rats IRC) has connected to the network (uplinked to no uplink)
Attached Files:
Notes
(0006811)
Adam   
2016-11-04 05:04   
Thanks, fixed in 9e510cd0d992836793cfa99db31f05c041bd91df

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1690 [Anope Stable (2.0.x series)] General minor have not tried 2016-10-22 23:32 2016-10-22 23:32
Reporter: webczat Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: unrealircd-4 supports channel qlines
Description: It seems that unrealircd version 4.0 up supports placing qlines on channels, but unreal4 protocol module does not have a flag set
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1684 [Anope Development (1.9.x series)] IRCD Support crash always 2016-07-20 01:55 2016-07-23 20:48
Reporter: Techman Platform: Linux  
Assigned To: Adam OS: Ubuntu  
Priority: high OS Version: 16.04 x64  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Anope crashes when attempting to connect to an uplink server that has a user using one of the service bot nicks
Description: Anope segfaults when trying to connect to a Charybdis uplink that has a user on the network whose nick is one of the service bot nicks, such as NickServ. I used NickServ in my testing.
Tags:
Steps To Reproduce: 1. Have a user on your Charybdis server named "NickServ"
2. Start Anope
3. Segmentation fault occurs
Additional Information: bt full: https://pastebin.anope.org/index.php?page=viewpaste&id=ecfaa78cc5
Last few lines of debug logs: https://pastebin.anope.org/index.php?page=viewpaste&id=d4cf36c193
^ The above occurs when you have third party modules loaded, but it doesn't seem to make a difference.

bt full w/ --support: https://pastebin.anope.org/index.php?page=viewpaste&id=89629c4df6
Last few lines of debug logs w/ --support: https://pastebin.anope.org/index.php?page=viewpaste&id=fccfaf7280
Attached Files:
Notes
(0006807)
Adam   
2016-07-23 20:48   
Fixed in 647f8cd4e639e230d80046ee5967f88a72bdee4a
(0006806)
Techman   
2016-07-22 00:34   
Upon further inspection, this issue might be occurring because RESVs aren't being applied properly for TS6-compliant IRCds. I'm filing a separate issue about this. I hope that fixing that issue fixes this one.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1683 [Anope Stable (2.0.x series)] General minor always 2016-07-18 21:23 2016-07-18 21:23
Reporter: albus Platform: Unix  
Assigned To: OS: Linux  
Priority: normal OS Version: Debian 8  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: limit superadmin to modify access lists
Description: how to denied access ircop to modify lists if non set permision on services configuration. i want to allow the ircop set superadmin and have +qo auto but no modify access list.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1682 [Anope Stable (2.0.x series)] General minor always 2016-07-02 21:40 2016-07-03 18:44
Reporter: Robby Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ChanServ's MODE SET +b/BAN command strips the CIDR part away when a CIDR block is specified.
Description: ChanServ's MODE SET +b command strips the "/32" part away in "*!*@2001:DB8::/32".
The same happens for +e and +I.

ChanServ's BAN command also has the same issue.
Tags:
Steps To Reproduce: For CS MODE:
/CS MODE #Test SET +b *!*@2001:DB8::/32
On channel: ChanServ sets mode: +b *!*@2001:DB8::

For CS BAN:
/CS BAN #Test *!*@2001:DB8::/32
-ChanServ- No users on #Test match *!*@2001:DB8::.
On channel: ChanServ sets mode: +b *!*@2001:DB8::
Additional Information: Manually setting a ban on *!*@2001:DB8::/32 and then doing:
/CS MODE #Test SET -b *!*@2001:DB8::/32
does work as expected.
Attached Files:
Notes
(0006805)
Adam   
2016-07-03 18:44   
Thanks, fixed in 8dc687b657205abefeb1a779ea42070721252e14

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1681 [Anope Stable (2.0.x series)] General minor always 2016-07-02 16:17 2016-07-03 18:44
Reporter: Robby Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Logging in via SASL does not cause the stored realname to get updated in the database.
Description: When using SASL to login, Anope will not update the realname in the database when the user logs on to the network.
Tags:
Steps To Reproduce: 1. Have a registered nickname.
2. Log onto IRC and identify via a regular /NS IDENTIFY.
3. Disconnect, and change your realname to something else.
4. Reconnect to the network by using SASL.
5. The realname will not get updated to the new value (check using /NS INFO).
Additional Information:
Attached Files:
Notes
(0006804)
Adam   
2016-07-03 18:44   
Thanks, fixed in 18fc11398435a84a77219dc7332bed6e38c850d7

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1680 [Anope Stable (2.0.x series)] General minor always 2016-07-02 16:12 2016-07-03 18:44
Reporter: Robby Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: OperServ ignore duration of 1 year results in the returned notice saying 0 seconds
Description: When you /OS IGNORE a mask with a duration of 1y/365d the notice returned by OperServ will say that the mask will be ignored for 0 seconds.
Tags:
Steps To Reproduce: <Robby> IGNORE ADD 365d *!testtest@* test
-OperServ- *!testtest@* will now be ignored for 0 seconds.
Additional Information: Only happens with 1y/365d. Specifying 364d, 366d, etc, will result in the correct duration being displayed in the notice.
Attached Files:
Notes
(0006803)
Adam   
2016-07-03 18:44   
Thanks, fixed in 20c1a5d63892deab16af85db85aaac3fcb30de7a

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1675 [Anope Stable (2.0.x series)] General minor always 2016-04-22 15:52 2016-07-03 18:43
Reporter: Gavin Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: "/ns saset display" Cosmetic Issues
Description: When changing a users display as Services Admin, your whois is shown that you are login in as the <NewNick>

Status Window -
[16:41:10] Gavin!gavin@staff.zairc.net Hyperion You are now logged in as Hyperion

Whois -
[16:41:15] Gavin is logged in as Hyperion
[16:41:15] Gavin is a registered nick
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006802)
Adam   
2016-07-03 18:43   
Thanks, fixed in 284d95bfe2e076aadf1c6a4cb17cab06b3b2e876

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1674 [Anope Stable (2.0.x series)] General major always 2016-04-20 15:40 2016-07-03 18:43
Reporter: Anikwa Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: XMLRPC "Notice" sends the notice but returns a 404.
Description: When sending a NOTICE via XMLRPC, the notice sends to the user
(-MemoServ- Anikwa sent you a message. To view: https://***/messages/Anikwa)

but PHP gets this back despite it being successful.

file_get_contents(https://irc.***:8080/xmlrpc): failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found
Tags: webcpanel
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006801)
Adam   
2016-07-03 18:43   
Fixed in 4c4cc0ded7889cc65ee7faafd0e8b9c33421fd8d
(0006790)
Anikwa   
2016-04-23 21:07   
I have supplied a fix for this on GitHub.

https://github.com/anope/anope/pull/167
(0006789)
Anikwa   
2016-04-20 15:42   
(Last edited: 2016-04-23 20:37)
I should probably state that my version is:
Anope-2.0.3 services.* UnrealIRCd 3.2.x (and Unreal4.x) -(enc_bcrypt) -- build 0000004, compiled 20:26:43 Apr 13 2016


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1580 [Anope Development (1.9.x series)] Operserv feature always 2014-02-27 15:18 2016-06-09 10:05
Reporter: NoMiaus Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: UMODE doesn't set snomasks
Description: I can't set snomasks using umode (unreal + anope).

[19:09:22] <Global> OperServ: Moot: umode Moot +s +F
[19:09:22] OperServ Moot changed your usermodes.

It hasn't effect.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006797)
Anikwa   
2016-06-09 10:05   
Technically, yes, it did.

+s was set.

[10:05:00am] -OperServ- Changed usermodes of Sketch to -s.
[10:05:00am] -OperServ- Sketch changed your usermodes to -s.
[10:05:01am] * OperServ sets mode: -s
[10:05:03am] -OperServ- Changed usermodes of Sketch to +s.
[10:05:03am] -OperServ- Sketch changed your usermodes to +s.
[10:05:03am] * OperServ sets mode: +s
(0006796)
NoMiaus   
2016-06-07 02:06   
Then, Anope shouldn't send a reply saying usermodes were changed if they weren't set or if modes were invalid.
(0006602)
jobe   
2014-02-27 16:40   
The reason is in fact not because of a bug, but actually because of a technical limitation of UnrealIRCd's server protocol. Anope uses UnrealIRCd's SVS(2)MODE commands to change user modes however they do not allow changing of server notice masks. To change server notice masks Anope would have to make use of the accompanying SVS(2)SNO command to adjust a users server notice mask. See http://www.unrealircd.com/files/docs/technical/serverprotocol.html#S6_3 for more info on SVS(2)SNO

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1673 [Anope Stable (2.0.x series)] General crash always 2016-04-16 06:47 2016-04-16 22:58
Reporter: DukePyrolator Platform:  
Assigned To: Adam OS:  
Priority: high OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: crash on channel drop
Description: [Apr 16 07:29:46.293104 2016] Debug: Received: :971 SNONOTICE J :Channel #test created by DukePyrolator!DukeP@jens.anope.org
[Apr 16 07:29:46.293158 2016] Debug: unknown message from server (:971 SNONOTICE J :Channel #test created by DukePyrolator!DukeP@jens.anope.org)
[Apr 16 07:29:46.293172 2016] Debug: Received: :971 FJOIN #test 1460784586 +nt o,971AAAAFM
[Apr 16 07:29:46.293212 2016] CHANNEL: create #test
[Apr 16 07:29:46.293300 2016] Debug: dev.anope.de is setting #test to +nt
[Apr 16 07:29:46.293320 2016] CHANNEL: DukePyrolator!DukeP@jens.anope.org join #test
[Apr 16 07:29:51.558094 2016] Debug: Received: :971AAAAFM PRIVMSG 00AAAAAAC :register #test test
[Apr 16 07:29:51.559212 2016] COMMAND: DukePyrolator!DukeP@jens.anope.org (DukePyrolator) used REGISTER on #test
[Apr 16 07:29:51.559275 2016] Debug: Sent: :00AAAAAAC NOTICE 971AAAAFM :Channel #test registered under your account: DukePyrolator
[Apr 16 07:29:51.559508 2016] Debug: Sent: :00A METADATA #test mlock :n
[Apr 16 07:29:51.559808 2016] Debug: Sent: :00A METADATA #test mlock :nt
[Apr 16 07:29:51.560184 2016] Debug: Setting correct user modes for DukePyrolator on #test (giving modes)
[Apr 16 07:29:51.560219 2016] Debug: Unknown privilege AUTOOFFICIAL-JOIN
[Apr 16 07:29:51.560243 2016] Debug: Setting +q on #test for DukePyrolator
[Apr 16 07:29:51.560661 2016] Debug: Sent: :00AAAAAAC FMODE #test 1460784586 +rq 971AAAAFM
[Apr 16 07:30:21.122643 2016] Debug: Received: :971AAAAFM PRIVMSG 00AAAAAAB :assign #test chanserv
[Apr 16 07:30:21.122775 2016] COMMAND: DukePyrolator!DukeP@jens.anope.org (DukePyrolator) used ASSIGN on #test for ChanServ
[Apr 16 07:30:21.122824 2016] CHANNEL: ChanServ!services@services.anope.de join #test
[Apr 16 07:30:21.122847 2016] Debug: Sent: :00A FJOIN #test 1460784586 +nrt :,00AAAAAAC
[Apr 16 07:30:21.122874 2016] Debug: Setting +a on #test for ChanServ
[Apr 16 07:30:21.122924 2016] Debug: Setting +o on #test for ChanServ
[Apr 16 07:30:21.123024 2016] Debug: Sent: :00AAAAAAB NOTICE 971AAAAFM :Bot ChanServ has been assigned to #test.
[Apr 16 07:30:21.123072 2016] Debug: Sent: :00AAAAAAC FMODE #test 1460784586 +ao 00AAAAAAC 00AAAAAAC
[Apr 16 07:30:35.534700 2016] Debug: Received: :971AAAAFM PRIVMSG 00AAAAAAC :set persist #test on
[Apr 16 07:30:35.535177 2016] COMMAND: DukePyrolator!DukeP@jens.anope.org (DukePyrolator) used SET PERSIST on #test to enable persist
[Apr 16 07:30:35.535240 2016] Debug: Sent: :00AAAAAAC NOTICE 971AAAAFM :Channel #test is now persistent.
[Apr 16 07:30:45.254133 2016] Debug: Received: :971 PING 971 00A
[Apr 16 07:30:45.254196 2016] Debug: Sent: :00A PONG 00A 971
[Apr 16 07:30:45.423006 2016] Debug: Received: :971AAAAFM PART #test
[Apr 16 07:30:45.423068 2016] CHANNEL: DukePyrolator!DukeP@jens.anope.org part #test Reason: No reason
[Apr 16 07:30:45.423098 2016] CHANNEL: DukePyrolator!DukeP@jens.anope.org leave #test
[Apr 16 07:30:53.729033 2016] Debug: Received: :971AAAAFM PRIVMSG 00AAAAAAC :drop #test #test
[Apr 16 07:30:53.729822 2016] COMMAND: DukePyrolator!DukeP@jens.anope.org (DukePyrolator) used DROP on #test (founder was: DukePyrolator)
[Apr 16 07:30:53.730000 2016] Debug: Sent: :00A METADATA #test mlock :
[Apr 16 07:30:53.730024 2016] Debug: Sent: :00A METADATA #test topiclock :
[Apr 16 07:30:53.731439 2016] Debug: Deleting channel #test
[Apr 16 07:30:53.731486 2016] Debug: Sent: :00AAAAAAC PART #test
[Apr 16 07:30:53.731500 2016] CHANNEL: ChanServ!services@services.anope.de leave #test
[Apr 16 07:30:53.732109 2016] Debug: Sent: :00AAAAAAC FMODE #test 1460784586 -r
[Apr 16 07:30:53.732130 2016] CHANNEL: destroy #test
[Apr 16 07:30:53.732219 2016] Debug: Sent: :00AAAAAAC NOTICE 971AAAAFM :Channel #test has been dropped.

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000141 in ?? ()
(gdb) bt full
#0 0x0000000000000141 in ?? ()
No symbol table info available.
0000001 0x000000000051d99f in Channel::DeleteChannels () at /home/anope/anope/src/channels.cpp:953
        c = 0x9dba20
        i = 0
0000002 0x00000000005c36f8 in UplinkSocket::ProcessRead (this=0x96df20) at /home/anope/anope/src/uplink.cpp:138
        buf = {_string = ":971AAAAFM PRIVMSG 00AAAAAAC :drop #test #test", static npos = 18446744073709551615}
        b = true
0000003 0x00000000005bbd16 in SocketEngine::Process () at /home/anope/anope/src/socketengines/socketengine_epoll.cpp:112
        ev = @0xabc110: {events = 1, data = {ptr = 0xd, fd = 13, u32 = 13, u64 = 13}}
        it = {first = 13, second = }
        s = 0x96df68
        i = 0
        total = 1
0000004 0x000000000055398a in main (ac=3, av=0x7fffffffe688, envp=0x7fffffffe6a8) at /home/anope/anope/src/main.cpp:175
        n = 20
        last_check = 1460784650
        updateTimer = {<Timer> = {_vptr.Timer = 0x5dac10 <vtable for UpdateTimer+16>, owner = 0x0, settime = 1460784580, trigger = 1460784880, secs = 300,
            repeat = true}, <No data fields>}
        expireTimer = {<Timer> = {_vptr.Timer = 0x5dabd0 <vtable for ExpireTimer+16>, owner = 0x0, settime = 1460784580, trigger = 1460784700, secs = 120,
            repeat = true}, <No data fields>}
(gdb)



Tags:
Steps To Reproduce: 1. if on inspircd, make sure m_permchannels is not loaded
2. join and register a new #channel
3. assign a botserv bot to #channel
4. set persist #channel on
5. part #channel
6. drop #channel
Additional Information: I think the error is in
https://github.com/anope/anope/blob/2.0/modules/commands/cs_drop.cpp#L65

we save a pointer to the channel before we delete the channel.
the channel gets destroyed when the botserv bot parts the channel
and then we use the pointer to the now unassigned memory.

proposed solution:
 instead of saving the pointer to the channel, we can
    Channel *c = channel::Find(chan)
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1603 [Anope Stable (2.0.x series)] General minor have not tried 2014-06-01 17:02 2016-02-13 21:43
Reporter: azander Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Chanserv access list behavior and Chanserv secure help text not the same
Description: Help text and reality do not match.

Chanserv help text:
<ChanServ> Enables or disables security features for a
<ChanServ> channel. When chanserv/set/secure is set, only users who have
<ChanServ> registered their nicknames and IDENTIFY'd
<ChanServ> with their password will be given access to the channel
<ChanServ> as controlled by the access list.

Reality:
Set channel to Secure On

add hostmask *!*@localhost to access list level 5

Join user with mask Nick!ident@localhost (I used this exact one during testing on my network)

User gets opped. No registration, no identify.

Tags:
Steps To Reproduce: see above
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1648 [Anope Stable (2.0.x series)] General text always 2015-04-12 15:00 2016-02-13 20:51
Reporter: capitaine Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Placeholder left in french translation
Description: in "anope.fr_FR.po"
line 6923

#: modules/commands/bs_info.cpp:57
msgid "Real name"
msgstr "Vrai nom : %s"

translation has to be :
msgstr "Vrai nom"
Tags:
Steps To Reproduce:
Additional Information: Anope 2.0.2
Attached Files:
Notes
(0006746)
AlphaTech   
2015-07-17 17:15   
Thanks, I've added this in pull request 0000129

https://github.com/anope/anope/pull/129

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1615 [Anope Stable (2.0.x series)] General minor always 2014-09-13 10:36 2016-02-13 20:50
Reporter: capitaine Platform: Linux  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: /BS Info report 0 channels
Description: I checked several bots, and they always report :
-BotServ- Used on: 0 channel(s)

But they are actually affected and used.
Tags:
Steps To Reproduce: /BS info foo
Additional Information:
Attached Files:
Notes
(0006728)
capitaine   
2015-04-12 14:26   
It seems to only occur after importing with module db_old.
I missed the proper count after disabling the module and restart. So I guess it's ok, just an expected temporary behaviour.
(0006668)
Adam   
2014-11-04 07:13   
I'm not able reproduce this on a clean install, are you? Are there any more specifics you can give, such as "this only happens when...", eg, after a DB import or something?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1634 [Anope Stable (2.0.x series)] General crash have not tried 2015-02-10 11:04 2016-02-13 20:47
Reporter: simos Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Anope 2.0.1 sql_live Segfault
Description: This s the Backtrace:

anope@Hub:~/services$ gdb bin/services core
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/anope/services/bin/services...done.
[New LWP 17626]
[New LWP 17627]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/home/anope/services/bin/services'.
Program terminated with signal 11, Segmentation fault.
#0 0x00007fec398dcf40 in std::string::find(std::string const&, unsigned long) const () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt full
#0 0x00007fec398dcf40 in std::string::find(std::string const&, unsigned long) const () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
0000001 0x0000000000502d73 in Anope::string::find (this=0x7fff6e2dfc80, _str=..., pos=0) at /home/anope/anope/include/anope.h:192
No locals.
0000002 0x00007fec3580704d in Fantasy::OnPrivmsg (this=0x1fcde20, u=0x21a64d0, c=0x23d10d0, msg=...) at /home/anope/anope/modules/fantasy.cpp:106
        params = {<std::_Vector_base<Anope::string, std::allocator<Anope::string> >> = {
            _M_impl = {<std::allocator<Anope::string>> = {<__gnu_cxx::new_allocator<Anope::string>> = {<No data fields>}, <No data fields>}, _M_start = 0x23d10d0,
              _M_finish = 0x23d1178, _M_end_of_storage = 0x23d11d0}}, <No data fields>}
        cmd = {<Reference<Command>> = {<ReferenceBase> = {_vptr.ReferenceBase = 0x0, invalid = false}, ref = 0x0}, type = {_string = {static npos = <optimized out>,
              _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x0}},
            static npos = 18446744073709551615}, name = {_string = {static npos = <optimized out>,
              _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x0}},
            static npos = 18446744073709551615}}
        source = {nick = {_string = {static npos = <optimized out>,
              _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x0}},
            static npos = 18446744073709551615}, u = {<ReferenceBase> = {_vptr.ReferenceBase = 0x0, invalid = false}, ref = 0x0}, nc = {<ReferenceBase> = {
              _vptr.ReferenceBase = 0x0, invalid = false}, ref = 0x0}, reply = 0x0, c = {<ReferenceBase> = {_vptr.ReferenceBase = 0x0, invalid = false}, ref = 0x0},
          service = {<ReferenceBase> = {_vptr.ReferenceBase = 0x0, invalid = false}, ref = 0x0}, command = {_string = {static npos = <optimized out>,
              _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x0}},
            static npos = 18446744073709551615}, permission = {_string = {static npos = <optimized out>,
              _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x0}},
            static npos = 18446744073709551615}}
        count = 0
        info = @0x84cea8: {name = {_string = {static npos = <optimized out>,
              _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x1fe7d30 "p\261\005\002"}},
            static npos = 18446744073709551615}, permission = {_string = {static npos = <optimized out>,
              _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>},
                _M_p = 0x1fe8120 "\240\376\377\001"}}, static npos = 18446744073709551615}, group = {_string = {static npos = <optimized out>,
              _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x1fdf3e0 "P\351\374\001"}},
            static npos = 18446744073709551615}, hide = 248, prepend_channel = 243}
        it = {_M_node = 0x0}
        ag = {<std::vector<ChanAccess*, std::allocator<ChanAccess*> >> = {<std::_Vector_base<ChanAccess*, std::allocator<ChanAccess*> >> = {
              _M_impl = {<std::allocator<ChanAccess*>> = {<__gnu_cxx::new_allocator<ChanAccess*>> = {<No data fields>}, <No data fields>}, _M_start = 0x0,
                _M_finish = 0x0, _M_end_of_storage = 0x0}}, <No data fields>}, ci = 0x0, path = {first = {_M_t = {
                _M_impl = {<std::allocator<std::_Rb_tree_node<std::pair<ChanAccess const* const, ChanAccess const*> > >> = {<__gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<ChanAccess const* const, ChanAccess const*> > >> = {<No data fields>}, <No data fields>},
                  _M_key_compare = {<std::binary_function<ChanAccess const*, ChanAccess const*, bool>> = {<No data fields>}, <No data fields>}, _M_header = {
                    _M_color = std::_S_red, _M_parent = 0x0, _M_left = 0x0, _M_right = 0x0}, _M_node_count = 0}}}, second = {_M_t = {
                _M_impl = {<std::allocator<std::_Rb_tree_node<std::pair<ChanAccess const* const, ChanAccess const*> > >> = {<__gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<ChanAccess const* const, ChanAccess const*> > >> = {<No data fields>}, <No data fields>},
                  _M_key_compare = {<std::binary_function<ChanAccess const*, ChanAccess const*, bool>> = {<No data fields>}, <No data fields>}, _M_header = {
                    _M_color = std::_S_red, _M_parent = 0x0, _M_left = 0x0, _M_right = 0x0}, _M_node_count = 0}}}}, nc = 0x0, super_admin = false, founder = false}
        has_fantasia = 2
---Type <return> to continue, or q <return> to quit---
        MOD_RESULT = 32767
        nc_reference = {<ReferenceBase> = {_vptr.ReferenceBase = 0x0, invalid = false}, ref = 0x0}
0000003 0x00000000005616e5 in Message::Privmsg::Run (this=0x1fb77a8, source=..., params=...) at /home/anope/anope/src/messages.cpp:317
        _i = {_M_current = 0x1fe7d28}
        _modules = @0x84cea0: {<std::_Vector_base<Module*, std::allocator<Module*> >> = {
            _M_impl = {<std::allocator<Module*>> = {<__gnu_cxx::new_allocator<Module*>> = {<No data fields>}, <No data fields>}, _M_start = 0x1fe7d20,
              _M_finish = 0x1fe7d30, _M_end_of_storage = 0x1fe8120}}, <No data fields>}
        c = 0x23d10d0
        receiver = @0x93387c0: {_string = {static npos = <optimized out>,
            _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0xfdaec68 "#Friend's_Time"}},
          static npos = 18446744073709551615}
        message = {_string = {static npos = <optimized out>,
            _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>},
              _M_p = 0x11208db8 "[17:02] <Alessia> intercettazione di comunicazioni informatiche e ... illecita di comunicazioni informatiche o telematiche), quinquies (Installazione di ... 617 quater c.p.)"}}, static npos = 18446744073709551615}
        u = 0x21a64d0
0000004 0x000000000059bdee in Anope::Process (buffer=...) at /home/anope/anope/src/process.cpp:73
        command = {_string = {static npos = <optimized out>,
            _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x25119898 "PRIVMSG"}},
          static npos = 18446744073709551615}
        params = {<std::_Vector_base<Anope::string, std::allocator<Anope::string> >> = {
            _M_impl = {<std::allocator<Anope::string>> = {<__gnu_cxx::new_allocator<Anope::string>> = {<No data fields>}, <No data fields>}, _M_start = 0x93387c0,
              _M_finish = 0x93387d0, _M_end_of_storage = 0x93387d0}}, <No data fields>}
        proto_name = {_string = {static npos = <optimized out>,
            _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x1f1f288 "inspircd20"}},
          static npos = 18446744073709551615}
        MOD_RESULT = EVENT_CONTINUE
        m = {<Reference<IRCDMessage>> = {<ReferenceBase> = {_vptr.ReferenceBase = 0x5e6450, invalid = false}, ref = 0x1fb77a8}, type = {_string = {
              static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>},
                _M_p = 0x14540f68 "IRCDMessage"}}, static npos = 18446744073709551615}, name = {_string = {static npos = <optimized out>,
              _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>},
                _M_p = 0x358bae8 "inspircd20/privmsg"}}, static npos = 18446744073709551615}}
        source = {_string = {static npos = <optimized out>,
            _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x15b7edf8 "018AAAAKZ"}},
          static npos = 18446744073709551615}
        src = {source = {_string = {static npos = <optimized out>,
              _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x15b7edf8 "018AAAAKZ"}},
            static npos = 18446744073709551615}, u = 0x21a64d0, s = 0x0}
0000005 0x00000000005cab1a in UplinkSocket::ProcessRead (this=0x8126cc0) at /home/anope/anope/src/uplink.cpp:137
        buf = {_string = {static npos = <optimized out>,
            _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>},
              _M_p = 0xc5210c8 ":018AAAAKZ PRIVMSG #Friend's_Time :[17:02] <Alessia> intercettazione di comunicazioni informatiche e ... illecita di comunicazioni informatiche o telematiche), quinquies (Installazione di ... 617 quat"...}}, static npos = 18446744073709551615}
---Type <return> to continue, or q <return> to quit---
        b = true
0000006 0x00000000005c3123 in SocketEngine::Process () at /home/anope/anope/src/socketengines/socketengine_epoll.cpp:112
        ev = @0xeefb710: {events = 1, data = {ptr = 0xe, fd = 14, u32 = 14, u64 = 14}}
        it = {_M_node = 0x2217d50}
        s = 0x8126d08
        i = 0
        total = 1
0000007 0x000000000055b229 in main (ac=1, av=0x7fff6e2e2de8, envp=0x7fff6e2e2df8) at /home/anope/anope/src/main.cpp:176
        n = 20
        last_check = 1423532174
        updateTimer = {<Timer> = {_vptr.Timer = 0x5e1a30, owner = 0x0, settime = 1422513081, trigger = 1423532455, secs = 300, repeat = true}, <No data fields>}
        expireTimer = {<Timer> = {_vptr.Timer = 0x5e19f0, owner = 0x0, settime = 1422513081, trigger = 1423532404, secs = 1800, repeat = true}, <No data fields>}

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006782)
Adam   
2016-02-13 20:47   
I believe this has been fixed in 2.0.3
(0006725)
simos   
2015-03-26 09:24   
a new crash, bt and bt full :

anope@Hub:~/services$ gdb bin/services core
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/anope/services/bin/services...done.
[New LWP 17733]
 
warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/home/anope/services/bin/services'.
Program terminated with signal 11, Segmentation fault.
#0 0x00000000005d7b11 in XLine::~XLine (this=0x11aa080, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at /home/anope/anope/src/xline.cpp:110
110 delete regex;
(gdb) bt
#0 0x00000000005d7b11 in XLine::~XLine (this=0x11aa080, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at /home/anope/anope/src/xline.cpp:110
0000001 0x00000000005d7d32 in XLine::~XLine (this=0x11aa080, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at /home/anope/anope/src/xline.cpp:112
0000002 0x00000000005d9683 in XLineManager::Clear (this=0x96fa88) at /home/anope/anope/src/xline.cpp:339
0000003 0x00007fddda87a40b in OperServCore::~OperServCore (this=0x96f8f0, __in_chrg=<optimized out>) at /home/anope/anope/modules/pseudoclients/operserv.cpp:199
0000004 0x00007fddda87a544 in OperServCore::~OperServCore (this=0x96f8f0, __in_chrg=<optimized out>) at /home/anope/anope/modules/pseudoclients/operserv.cpp:204
0000005 0x00007fddda8748f1 in AnopeFini (m=0x96f8f0) at /home/anope/anope/modules/pseudoclients/operserv.cpp:290
0000006 0x0000000000587e32 in ModuleManager::DeleteModule (m=0x96f8f0) at /home/anope/anope/src/modulemanager.cpp:384
0000007 0x0000000000587575 in ModuleManager::UnloadModule (m=0x96f8f0, u=0x0) at /home/anope/anope/src/modulemanager.cpp:312
0000008 0x00000000005886b9 in ModuleManager::UnloadAll () at /home/anope/anope/src/modulemanager.cpp:525
0000009 0x000000000055b573 in main (ac=1, av=0x7fff0da0f488, envp=0x7fff0da0f498) at /home/anope/anope/src/main.cpp:197
(gdb) bt full
#0 0x00000000005d7b11 in XLine::~XLine (this=0x11aa080, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at /home/anope/anope/src/xline.cpp:110
No locals.
0000001 0x00000000005d7d32 in XLine::~XLine (this=0x11aa080, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at /home/anope/anope/src/xline.cpp:112
No locals.
0000002 0x00000000005d9683 in XLineManager::Clear (this=0x96fa88) at /home/anope/anope/src/xline.cpp:339
        x = 0x11aa080
        i = 0
0000003 0x00007fddda87a40b in OperServCore::~OperServCore (this=0x96f8f0, __in_chrg=<optimized out>) at /home/anope/anope/modules/pseudoclients/operserv.cpp:199
No locals.
0000004 0x00007fddda87a544 in OperServCore::~OperServCore (this=0x96f8f0, __in_chrg=<optimized out>) at /home/anope/anope/modules/pseudoclients/operserv.cpp:204
No locals.
0000005 0x00007fddda8748f1 in AnopeFini (m=0x96f8f0) at /home/anope/anope/modules/pseudoclients/operserv.cpp:290
No locals.
0000006 0x0000000000587e32 in ModuleManager::DeleteModule (m=0x96f8f0) at /home/anope/anope/src/modulemanager.cpp:384
        handle = 0x96f330
        filename = {_string = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x96f1f8 "lib/modules/operserv.so"}}, static npos = 18446744073709551615}
        destroy_func = 0x7fddda8748c7 <AnopeFini(OperServCore*)>
        err = 0x0
0000007 0x0000000000587575 in ModuleManager::UnloadModule (m=0x96f8f0, u=0x0) at /home/anope/anope/src/modulemanager.cpp:312
No locals.
0000008 0x00000000005886b9 in ModuleManager::UnloadAll () at /home/anope/anope/src/modulemanager.cpp:525
        m = 0x96f8f0
        i = 500
        modules = {<std::_Vector_base<Anope::string, std::allocator<Anope::string> >> = {_M_impl = {<std::allocator<Anope::string>> = {<__gnu_cxx::new_allocator<Anope::string>> = {<No data fields>}, <No data fields>}, _M_start = 0x55a6670, _M_finish = 0x55a7740,
              _M_end_of_storage = 0x55a8670}}, <No data fields>}
0000009 0x000000000055b573 in main (ac=1, av=0x7fff0da0f488, envp=0x7fff0da0f498) at /home/anope/anope/src/main.cpp:197
        n = 20
        last_check = 1427354164
        updateTimer = {<Timer> = {_vptr.Timer = 0x5e1a30, owner = 0x0, settime = 1427353669, trigger = 1427354271, secs = 300, repeat = true}, <No data fields>}
        expireTimer = {<Timer> = {_vptr.Timer = 0x5e19f0, owner = 0x0, settime = 1427353669, trigger = 1427355469, secs = 1800, repeat = true}, <No data fields>}
(gdb) quit
(0006699)
Elephantman   
2015-02-20 21:14   
I have this issue too, it's critical, happens once every day or two.
(0006696)
simos   
2015-02-10 11:06   
Sorry Anope version is 2.0.2 and not 2.0.1

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1669 [Anope Stable (2.0.x series)] General crash always 2015-12-06 14:27 2016-01-23 17:16
Reporter: invi Platform: Linux  
Assigned To: Adam OS: Centos  
Priority: high OS Version: 5.11  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: webcpanel crash
Description: When somebody in webcpanel trying to delete his/her own nick on the channel acc list services are gone. Only doing when u are trying to delete yourself.
Tags:
Steps To Reproduce:
Additional Information: https://pastebin.anope.org/index.php?page=viewpaste&id=aff96322c5
Attached Files:
Notes
(0006781)
Adam   
2016-01-23 17:16   
Was able to reproduce this due to a different bug report, fixed in 7953274a8805fadb2e1b2381343f8bd0d687a364.
(0006778)
Adam   
2015-12-29 22:17   
Unable to reproduce. Would need debug logs/gdb stack trace.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1650 [Anope Stable (2.0.x series)] General minor have not tried 2015-04-29 08:09 2015-12-29 20:55
Reporter: Apocalypse Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ChanServ mode has problems with InspIRCd extbans
Description: ChanServ appears to have problems handling mode +b extbans on InspIRCd. It is able to set them, yet is unable to remove/clear them properly. It appears to work fine when used with mode +eI extbans.

ChanServ is NOT able to set mode +beI Redirect properly, as it strips out the channel to redirect (Format: /mode #channel +beI Redirect:nick!user@host#channel). It is however to able remove mode +beI Redirect, with/without the channel being stripped.

ChanServ is NOT able to remove/clear mode +b extbans j, r, s, z, R, c, m, A, B, C, N, Q, S, T, and U, despite being able to set them properly.

ChanServ appears to be able to set/remove/clear mode +eI extbans properly (except with Redirect as previously mentioned).

Note, I used InspIRCd 2.0.19, and it had all relevant modules loaded for the extbans in question. I am also able to set and remove all of these modes manually with no issues.
Tags:
Steps To Reproduce: 1) Set the extbans using
/cs mode #channel set +b extban:<string>
or
!mode set +b extban:<string>

2) Attempt to remove extbans using
/cs mode #channel set -b extban:<string>
or
!mode set -b extban:<string>

Will fail to remove extbans except for O, p, and M. Strips out the channel for extban Redirect when setting, is able to remove however.

I am also guessing it will also have
Additional Information: Some examples of unexpected results from ChanServ, it receives the command yet does nothing with it when attempting to remove.

Test channel:
[04/29/15][00:20:45] »» StaffBot sets modes (#Staff +b j:#test)
[04/29/15][00:23:03] »» StaffBot sets modes (#Staff +b r:Test)
[04/29/15][00:23:20] »» StaffBot sets modes (#Staff +b s:test.server.net)
[04/29/15][00:23:40] »» StaffBot sets modes (#Staff +b z:ccaaadddd)
[04/29/15][00:23:58] »» StaffBot sets modes (#Staff +b O:GlobalOperator)
[04/29/15][00:24:01] »» StaffBot sets modes (#Staff -b O:GlobalOperator)
[04/29/15][00:24:37] »» StaffBot sets modes (#Staff +b R:fractal)
[04/29/15][00:25:11] »» StaffBot sets modes (#Staff +b c:*!*@DarkVoltage.net)
[04/29/15][00:25:22] »» StaffBot sets modes (#Staff +b m:*!*@DarkVoltage.net)
[04/29/15][00:25:33] »» StaffBot sets modes (#Staff +b p:*!*@DarkVoltage.net)
[04/29/15][00:25:36] »» StaffBot sets modes (#Staff -b p:*!*@DarkVoltage.net)
[04/29/15][00:25:57] »» StaffBot sets modes (#Staff +b A:*!*@DarkVoltage.net)
[04/29/15][00:26:11] »» StaffBot sets modes (#Staff +b B:*!*@DarkVoltage.net)
[04/29/15][00:26:23] »» StaffBot sets modes (#Staff +b C:*!*@DarkVoltage.net)
[04/29/15][00:26:37] »» StaffBot sets modes (#Staff +b M:fractal)
[04/29/15][00:26:39] »» StaffBot sets modes (#Staff -b M:fractal)
[04/29/15][00:26:50] »» StaffBot sets modes (#Staff +b N:*!*@DarkVoltage.net)
[04/29/15][00:27:06] »» StaffBot sets modes (#Staff +b Q:*!*@DarkVoltage.net)
[04/29/15][00:27:16] »» StaffBot sets modes (#Staff +b S:*!*@DarkVoltage.net)
[04/29/15][00:27:30] »» StaffBot sets modes (#Staff +b T:*!*@DarkVoltage.net)
[04/29/15][00:27:39] »» StaffBot sets modes (#Staff +b U:*!*@DarkVoltage.net)
[04/29/15][00:34:36] »» StaffBot sets modes (#Staff +b Redirect:*!*@*)

Services log channel:
[04/29/15][00:20:45] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set +b j:#test
[04/29/15][00:21:04] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set -b j:#test
[04/29/15][00:23:03] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set +b r:Test
[04/29/15][00:23:05] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set -b r:Test
[04/29/15][00:23:19] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set +b s:test.server.net
[04/29/15][00:23:22] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set -b s:test.server.net
[04/29/15][00:23:39] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set +b z:ccaaadddd
[04/29/15][00:23:42] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set -b z:ccaaadddd
[04/29/15][00:23:58] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set +b O:GlobalOperator
[04/29/15][00:24:01] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set -b O:GlobalOperator
[04/29/15][00:24:37] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set +b R:fractal
[04/29/15][00:24:39] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set -b R:fractal
[04/29/15][00:25:11] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set +b c:*!*@DarkVoltage.net
[04/29/15][00:25:14] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set -b c:*!*@DarkVoltage.net
[04/29/15][00:25:22] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set +b m:*!*@DarkVoltage.net
[04/29/15][00:25:25] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set -b m:*!*@DarkVoltage.net
[04/29/15][00:25:33] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set +b p:*!*@DarkVoltage.net
[04/29/15][00:25:36] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set -b p:*!*@DarkVoltage.net
[04/29/15][00:25:57] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set +b A:*!*@DarkVoltage.net
[04/29/15][00:26:01] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set -b A:*!*@DarkVoltage.net
[04/29/15][00:26:11] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set +b B:*!*@DarkVoltage.net
[04/29/15][00:26:15] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set -b B:*!*@DarkVoltage.net
[04/29/15][00:26:23] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set +b C:*!*@DarkVoltage.net
[04/29/15][00:26:25] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set -b C:*!*@DarkVoltage.net
[04/29/15][00:26:37] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set +b M:fractal
[04/29/15][00:26:39] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set -b M:fractal
[04/29/15][00:26:50] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set +b N:*!*@DarkVoltage.net
[04/29/15][00:26:53] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set -b N:*!*@DarkVoltage.net
[04/29/15][00:27:06] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set +b Q:*!*@DarkVoltage.net
[04/29/15][00:27:09] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set -b Q:*!*@DarkVoltage.net
[04/29/15][00:27:16] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set +b S:*!*@DarkVoltage.net
[04/29/15][00:27:18] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set -b S:*!*@DarkVoltage.net
[04/29/15][00:27:30] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set +b T:*!*@DarkVoltage.net
[04/29/15][00:27:33] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set -b T:*!*@DarkVoltage.net
[04/29/15][00:27:39] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set +b U:*!*@DarkVoltage.net
[04/29/15][00:27:42] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set -b U:*!*@DarkVoltage.net
[04/29/15][00:34:36] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set +b Redirect:*!*@*#DarkVoltage
[04/29/15][00:34:39] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set -b Redirect:*!*@*#DarkVoltage
Attached Files:
Notes
(0006777)
Adam   
2015-12-29 20:55   
Fixed in ba805e30b83c4bf2c583279f9e939fb05f566b14
(0006730)
Apocalypse   
2015-04-29 22:43   
You're right, I see that now after looking at it again. InspIRCd gave an error message when prefixed with Redirect: when used on a channel that didn't exist, so I assumed initially it was properly formatted. However, even when using n!u@h#redirect, the same problem still persists where the #redirect is stripped when using cs_mode.

[04/29/15][16:39:13] »» StaffBot sets modes (#Staff +b *!*@*)

[04/29/15][16:39:13] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set +b *!*@*#DarkVoltage
[04/29/15][16:39:15] .:ChanServ:. COMMAND: Apocalypse!Apocalypse@apocalypse.darkvoltage.net (Apocalypse) used MODE on #Staff to set -b *!*@*#DarkVoltage
(0006729)
Adam   
2015-04-29 22:09   
The format to redirect on inspircd is just n!u@h#redirect, not prefixed with Redirect:. Not sure what that would do.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1662 [Anope Stable (2.0.x series)] General minor always 2015-09-23 16:55 2015-12-14 02:43
Reporter: capitaine Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Accesses zero or negative are allowed
Description: Anope previous version used levels NOJOIN and AUTODEOP which were negative by default.

Now they're gone, but negative accesses add confusion, because Chanserv acts like if they're actually zero, and it's a change of behaviour.

So I guess command Chanserv ACCESS shoud not allow adding an access of 0 nor negative, and maybe module db_old should delete negative accesses, or print a warning.
Tags:
Steps To Reproduce: /Chanserv LEVELS #channel SET AUTOHALFOP -5
ChanServ - Level for GREET on channel #channel changed to -10.
/Chanserv ACCESS #channel ADD foo -10
ChanServ - foo added to #channel access list at level -5.

When foo joins #channel,
he was not granted anything on Anope 1.8, but is +h on 2.0
Additional Information:
Attached Files:
Notes
(0006775)
Adam   
2015-12-14 02:43   
fixed in 3da2cdb49604f6814e0357e3372389326b1a9152
(0006762)
Adam   
2015-09-24 23:21   
This is because a negative level matches anyone. I'm not sure why, it used to be only -1 matched everyone.
(0006761)
azander   
2015-09-24 14:01   
They are not meaningless. I still use negative access levels to control non-registered users in my help channels.

They are useful for dealing with game channels where many, if not most, of the users never register their nicks but keep their host mask.
(0006759)
capitaine   
2015-09-24 11:55   
Ok you're right for 0, sorry. I was mistaken by that message, when do :

/Chanserv ACCESS #channel ADD foo -10000
ChanServ - Access level must be between -9999 and 10000 inclusive.

However negative accesses don't make sense, because the ACCESS help says :
"any unregistered user has a user level -1"
So, even if negative levels are actually useful, adding a neg access is not needed actually, as it must be done for a registered user and it's quite confusing.

For the reproducing steps, you're also right. I've done too many tests and just mixed the replies.
My bad... but here they are :

Anope 1.8

/Chanserv LEVELS #channel SET NOJOIN -100
ChanServ - Level for NOJOIN on channel #channel changed to -100.
/Chanserv LEVELS #channel SET AUTOHALFOP -5
ChanServ - Level for AUTOHALFOP on channel #channel changed to -5.
/Chanserv ACCESS #channel ADD foo -10
ChanServ - foo added to #channel access list at level -10.

:foo!user@---97EFBFD9 JOIN :#channel
:ChanServ!services@example.com MODE #channel -o :foo


Then Anope 2.0

/Chanserv LEVELS #channel SET AUTOHALFOP -5
ChanServ - Level for AUTOHALFOP on channel #channel changed to -5.
/Chanserv ACCESS #channel ADD foo -10
ChanServ - foo added to #channel access list at level -10.

:foo!user@---97EFBFD9 JOIN :#channel
:ChanServ!services@example.com MODE #channel +rh-o foo :foo


Finally, that -1 to -9999 access range has been inherited from the previous Anope, and is meaningless now.
(0006758)
Adam   
2015-09-24 00:38   
Also your steps to reproduce makes no sense because:

(18:37:17) <@Adam> for example he sets autohalfop to -5, and the reply from chanserv is greet set to -10
(18:37:22) <@Adam> and then he sets access add foo -10
(18:37:25) <@Adam> and it replies added at level -5
(18:37:36) <@Adam> so.. what
(18:37:41) <@Adam> I cant tell at all what is what
(0006756)
Adam   
2015-09-23 23:26   
ACCESS has never allowed adding an access of 0, if it does now that is a bug. I think it does not because of

                if (!level)
                {
                        source.Reply(_("Access level must be non-zero."));
                        return;
                }

Negative access can be useful with negative levels, so I don't think it should be removed.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1661 [Anope Stable (2.0.x series)] General minor always 2015-09-23 14:40 2015-09-24 23:23
Reporter: capitaine Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Channel old levels are still converted
Description:
It seems the following chan levels are not supported anymore on Anope 2 :

- AUTODEOP
- BANME
- CLEAR
- KICKME
- NOJOIN

But they are still converted by the module db_old, so they should be discarded.
Tags:
Steps To Reproduce: Import an old database
Additional Information:
Attached Files:
Notes
(0006763)
Adam   
2015-09-24 23:23   
fixed in 830361e
(0006760)
capitaine   
2015-09-24 12:31   
Maybe not a big issue, but I suggested to remove useless infos.
They're kept stored for nothing :

SELECT levels FROM anope_ChannelInfo WHERE name = "#channel";

 ACCESS_CHANGE 10 ACCESS_LIST 1 AKICK 10 ASSIGN 10001 AUTODEOP -1 AUTOHALFOP 4 AUTOOP 5 AUTOOWNER 9999 AUTOPROTECT 10 AUTOVOICE 3 BADWORDS 10 BAN 5 BANME 5 CLEAR 10001 FANTASIA 3 FOUNDER 10000 GETKEY 5 GREET 5 HALFOP 5 HALFOPME 4 INFO 10001 INVITE 5 KICK 5 KICKME 5 MEMO 10 MODE 9999 NOJOIN -2 NOKICK 1 OP 5 OPME 5 OWNER 10001 OWNERME 9999 PROTECT 10001 PROTECTME 10 SAY 5 SET 10001 SIGNKICK 10001 TOPIC 10001 UNBAN 5 VOICE 5 VOICEME 3
(0006757)
Adam   
2015-09-23 23:29   
I guess they are technically converted, but because 2.0 has no privilege block for them, it ends up not doing anything. I don't think that's any reason to discard them though.
(0006755)
Adam   
2015-09-23 23:23   
Why do you think they are converted by db_old?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1655 [Anope Stable (2.0.x series)] General minor always 2015-06-13 17:33 2015-09-18 02:37
Reporter: KnopeX Platform:  
Assigned To: Adam OS:  
Priority: high OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Channel modes will be not checked if bot gets deleted on persist mode
Description: I tried that with Anope-2.0.2 (ga762391) with UnrealIRCd 3.2.10.4+SSL (Windows)
Tags:
Steps To Reproduce: 1. Create a bot / Assign a bot to a channel
2. Set persist mode ON
3. Delete bot
4. Channel have no more channel modes on rejoin, when no one is in there (Services don't check that)
5. ChanServ will not join automatically when bot gets deleted (Only when services gets restarted)
Additional Information:
Attached Files:
Notes
(0006754)
Adam   
2015-09-18 02:36   
Fixed in 5692abb316647e4780e91c82bfe09007efd50243
(0006741)
KnopeX   
2015-06-14 11:33   
(Last edited: 2015-06-14 11:37)
If a random user joins a channel with PERSIST on and a deleted bot, user can get op and will not be removed from the services, even with KEEPMODES on (+r will not be set and other locked modes) and SECUREOPS on (When it's a empty channel)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1656 [Anope Stable (2.0.x series)] General major always 2015-06-24 20:57 2015-09-14 19:43
Reporter: alefburzmali Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Expired or dropped NickServ accounts keep their opertype when registered back
Description: When all the aliases of a services oper are dropped or expire, the former oper is no longer listed in "/os oper list". But when the nick is registered again (even hours later), OperServ remembers it and ties their former opertype to the new nick, potentially granting them access to OperServ.

It is the expected behavior for an oper nick configured in the config file. However, it is unexpected when the oper was not set in the file.

The opertype association with the nick should be forgotten when the nick expires or is dropped.
Tags:
Steps To Reproduce:
Additional Information: Logs:
Expiring nickname OperNick (group: OperNick) (e-mail: OperNick@example.net)
Deleting nickname group OperNick
...
Tied oper OperNick to type Services Operator
COMMAND: OperNick!user@example.net used REGISTER to register OperNick (email: OperNick@example.net)

Mitigations:
* "secureadmins" does not prevent expiration and does not help;
* "restrictopernicks" certainly helps, but the wildcard matching may be unwanted;
* "opersonly" definitely helps;
* restarting the services makes operserv to forget the nick.
Attached Files:
Notes
(0006753)
Adam   
2015-09-14 19:43   
fixed in 8d13a35

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1658 [Anope Stable (2.0.x series)] General minor always 2015-07-23 16:37 2015-09-14 18:40
Reporter: azander Platform: Anope 2.0.2  
Assigned To: Adam OS: Ununtu, OpenSuse, Fedora  
Priority: normal OS Version: current  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Chanserv /cs topic lock text does not match real world
Description: in the chanserv help for topic lock it reads:


LOCK and UNLOCK may be used to enable and disable topic lock. When topic lock is set, the channel topic will be unchangeable except via this command.

If a user is on the access list with proper rights to change the topic. services will allow the use of the standard /topic command in direct contradiction to this text.
Tags:
Steps To Reproduce: Register channel
set topic lock on
add user as aop or higher
once user identifies, they can use /topic
Additional Information: Minor issue, just text changes, but the code should be reviewed if the text is the proper method to be implemented.
Attached Files:
Notes
(0006752)
Adam   
2015-09-14 18:40   
Help output has been adjusted.
(0006748)
Adam   
2015-07-23 21:44   
This is intentional behavior, text is wrong.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1660 [Anope Stable (2.0.x series)] General major always 2015-08-31 18:19 2015-09-14 18:37
Reporter: Zoddo Platform:  
Assigned To: Adam OS:  
Priority: high OS Version: 2.0.2  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Login through webcpanel allowed on suspended accounts
Description: Hi!

I think that suspended (and eventually unconfirmed) accounts shouldn't able to login through cpanel.
Tags: webcpanel
Steps To Reproduce: Suspend an account and try to access to cpanel with this account.
Additional Information: In the same way, we shouldn't allow that IPs that are affected by an akill to access cpanel.
Attached Files:
Notes
(0006751)
Adam   
2015-09-14 18:37   
Thanks, fixed in 776207b.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1643 [Anope Stable (2.0.x series)] General minor always 2015-03-27 16:23 2015-06-30 00:37
Reporter: NoMiaus Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Anope keeps +I mode
Description: Anope keeps +I when using NickServ SET KEEPMODES because it doesn't recognise it like a mode for IRC operators only on unreal.cpp.

ModeManager::AddUserMode(new UserMode("HIDEIDLE", 'I'));

I think it should be:

ModeManager::AddUserMode(new UserModeOperOnly("HIDEIDLE", 'I'));

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006744)
Adam   
2015-06-30 00:37   
thanks, fixed in 074f1637508d76e2c21e9d698f265a0b4291f3b0

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1649 [Anope Stable (2.0.x series)] General minor always 2015-04-12 17:13 2015-06-30 00:37
Reporter: capitaine Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Channel KEEPMODES last modes are unexpectedly cleared
Description: The last modes of a channel with KEEPMODES on, are cleared when a user join in, and must be kicked.
Tags:
Steps To Reproduce: 1. set some modes on a registered chan, like /MODE #example +ms, and /CS SET KEEPMODES #example on
At this stage, when leaving/rejoining #example modes are kept, so it works well.

2. set an akick, like /CS AKICK #example ADD foo

3. everybody leaves #example, and foo join in, Chanserv kicks and stays on channel

4. after Chanserv has left, and new users can join, previous modes +ms are not back.
Additional Information: Anope 2.0.2
Attached Files:
Notes
(0006743)
Adam   
2015-06-30 00:37   
thanks, fixed in 02ed9a9725c40b57df965c4a13579bafebef2af3

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1640 [Anope Stable (2.0.x series)] General major always 2015-03-04 04:03 2015-03-23 14:00
Reporter: azander Platform: Linux  
Assigned To: Adam OS: Unbuntu  
Priority: normal OS Version: 13.10 LTS  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Channel giving ops when it shouldn't
Description: Set up a new channel, assign a bot, leave, then another user joins.
Similar issue, but without bot.

Did a /cs info #channel all which is in the log
Tags:
Steps To Reproduce: Steps:
 * Register nick (tester1 in attached logs)
 * Register Channel (#test5 in attached logs)
 * Assign bot (Bot in attached logs)
 * Leave channel
 * have another user join (tester2 in attached logs)
 -- Expected: Bot deops second user (tester2)
 -- Actual: Bot doesn't deop user (tester2)

Similar without bot, except ChanServ does not deop user.


Additional Information: This has been tested with secureops on, and it works as expected when secureops is on.

Attached Files: services.log.20150308 (39,544 bytes) 2015-03-08 18:31
https://bugs.anope.org/file_download.php?file_id=358&type=bug
configs.tar.bz2 (35,809 bytes) 2015-03-12 02:20
https://bugs.anope.org/file_download.php?file_id=359&type=bug
Notes
(0006724)
Adam   
2015-03-23 14:00   
fixed in 303e652a3563c50d8836996851341840b1ad4277
(0006722)
Adam   
2015-03-12 19:00   
This is from the keepmodes setting setting REGISTERED and conflicting with chanserv.cpp's take_modes registered check.
(0006712)
azander   
2015-03-12 02:23   
Configs from test server uploaded as requested. Only change to them is to remove passwords, except throw-away link password that doesn't matter.
(0006710)
Adam   
2015-03-11 16:26   
I cannot reproduce this on a stock install of Unreal 3.2 latest and 2.0 git. Upload all of your configuration files.
(0006709)
azander   
2015-03-11 03:42   
For whatever reason, it is not deoping the user at all. It should.

Same results on another network using anope-2.0.x as well. IRCD & Services on the same machine. Both running Unreal, current version. Do you need any additional info?
(0006708)
Adam   
2015-03-11 03:11   
The intended behavior is that services (or maybe the server due to the TS lowering) will deop the first user who joins the channel if they do not have access, regardless of secure or secureops.
(0006707)
NoMiaus   
2015-03-11 03:01   
I tested it, I followed your steps and ChanServ/BotServ deops the user...
(0006706)
azander   
2015-03-10 18:46   
This is not expected results.

Anope 1.8 would deop the person. Other services also deop that person.

This is new behaviour in 2.0.x.
(0006705)
Robby   
2015-03-10 18:35   
From what I can see in that log file, there is nothing wrong and seems to be all intended behavior. You actually need SECUREOPS to be ON at all times if you do not wish to have any unauthorized persons have operator status in the channel.
(0006704)
azander   
2015-03-08 18:32   
New file uploaded, passwords in the log are throw-away. Any real passwords were removed.
(0006702)
chaz   
2015-03-08 14:13   
Hello,

I removed the file that was attached here as it contained a working password for your nick.

Can you upload it again with your password removed :>

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1625 [Anope Stable (2.0.x series)] General major always 2014-12-01 21:02 2015-03-12 23:53
Reporter: webczat Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Problems with persistent channels
Description: I have my services set to deny mlocking +P by users using option nomlock, and to set the persist option when channel gets registered.
Here are the problems I see:
When channel is registered, +r mode is set, mlock modes are also set, but +P is not set, I believe it should be added to mlock but is not.
It seems that trying to leave and rejoin a persistent channel without +P results in no chanserv taking any actions like resetting +r, channel should be persistent but it is not.
Also, restarting services makes chanserv join all channels set persistent no matter if +P is set or not, even though it should not join any channels.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006723)
Adam   
2015-03-12 23:53   
fixed in 303e652a3563c50d8836996851341840b1ad4277
(0006720)
Adam   
2015-03-12 14:19   
(Last edited: 2015-03-12 19:37)
Part of this was fixed in f36915790674275627cf8eb68024e17539ee04fa (setting +P on register). The restarting part is annoying, I'd maybe rather wait and fix it in 2.1, I already have some changesets for that somewhere that inadvertently fix this.

EDIT: was the rest of this fixed in d9c9f2a4077e695598f17961da64b8d50225e2f0?

(0006683)
webczat   
2014-12-07 14:32   
Actually it seems that the problem is not just ChanServ joining all persistent channels on services restart, but chanserv being assigned to the channel. Not sure what would be a fix for this especially that chanserv could be really assigned to the channel too, not as a result of services being restarted.
(0006680)
webczat   
2014-12-02 00:45   
1. ChanServ does not set +P on newly registered channels when the persist option is set as default, it sets +P when persist option is enabled after registration though.
2. When services are restarted, ChanServ seems to join all persistent channels and stay there, no matter if +P is set on them or not.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1623 [Anope Stable (2.0.x series)] General crash random 2014-11-28 03:01 2015-03-12 14:43
Reporter: webczat Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: random crash on ldap authentication
Description: Hello.

I am using anope's ldap authentication module to integrate services with ldap user accounts.
However, I see the following problems:
Sometimes when giving an incorrect password the log says "protocol error" although that may be some configuration problem,
And also there is a more serious problem that if I try to quickly identify/logout/identify, although it usually works, it will completely crash anope after 2 or 3 tries, not sure if doing it slower changes things.
Tags:
Steps To Reproduce: 1. Configure anope to use ldap authentication.
2. Login to your account, see it succeeded.
3. Try to quickly log out and back in, after few successful logins there will be a crash without anything interesting in logs.
Additional Information: It is anope-2.0.1 compiled without debug info, debug logging is also disabled at the moment.
Attached Files:
Notes
(0006721)
Adam   
2015-03-12 14:43   
Reopen if still an issue post fb17bc85ead8c1be6ebe1561f77865f083fdc000
(0006681)
webczat   
2014-12-02 01:24   
I believe that linking with ldap_r solves the problem, at least when testing logout/login I didn't crash services as before.
(0006679)
Adam   
2014-11-30 19:20   
Try changing m_ldap to link to ldap_r not ldap.
(0006678)
webczat   
2014-11-29 09:24   
I attach valgrind and gdb's bt full output, I don't have them in any other form so giving links to pastebin:
bt full: http://pastebin.anope.org/index.php?page=viewpaste&id=761b3f51d4
valgrind: http://pastebin.anope.org/index.php?page=viewpaste&id=d15fd255df
(0006676)
webczat   
2014-11-28 14:33   
Honestly, unless I am wrong, I am using openldap 2.4.40 manually compiled and put to /usr/local, ldd says m_ldap links to this one.
(0006675)
DukePyrolator   
2014-11-28 07:54   
(Last edited: 2014-11-28 07:56)
Are you using debian? I had the same bug on my debian box.
The debugger said its a bug in the ldap library.
After installing the library from www.openldap.org the bug was gone.

I think this also fixed the protocol error log message.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1632 [Anope Stable (2.0.x series)] General text always 2015-02-01 15:52 2015-03-12 14:16
Reporter: ptseng Platform:  
Assigned To: Adam OS:  
Priority: low OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Email change confirmation lists old email rather than new.
Description: The default data/example.conf has emailchange_message with "You have requested to change your email address to %e".

Then in SendConfirmMail in modules/commands/ns_set.cpp, we replace %e with the account's current email.

This results in a message being sent to the user claiming "You have requested to change your email address to (OLD EMAIL)", when instead that should be the new email. (The email is, however, correctly sent to the new email)

One possible fix is to replace %e with the new_email var instead. However, some users of Anope may have already assumed %e is the old email and written their emailchange_message accordingly. I think for compatibility it would be wiser to leave %e as is, and introduce a new variable, perhaps named %E, that contains the new email address.

I attached a patch (exported with `git format-patch`, so should be ready to `git am`) to that effect, or open to discussion on the matter. I can submit a PR on github too if that is preferred.
Tags:
Steps To Reproduce: /ns set email newemail@provider.com then check your email.
Additional Information:
Attached Files: 0001-SendConfirmMail-Replace-E-with-new-email.patch (2,124 bytes) 2015-02-01 15:52
https://bugs.anope.org/file_download.php?file_id=353&type=bug
Notes
(0006719)
Adam   
2015-03-12 14:16   
Applied in bf727285bcf7c7c95c2b2b43faa3d1fa13bad6fb, thanks.
(0006694)
ptseng   
2015-02-01 16:14   
I believe the change in behavior was introduced in 1a3d9a016d3adc49788bbff73aac9b3b5ea85b17

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1633 [Anope Stable (2.0.x series)] General minor always 2015-02-09 22:47 2015-03-12 14:16
Reporter: Elephantman Platform: x64  
Assigned To: Adam OS: Linux  
Priority: normal OS Version: Debian Wheezy  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Sqlines apply to channels
Description: An sqline with a wildcard applies to a channel.
For example, add an sqline for *admin* and all channels containing "admin" will act as if there was an akick *@* on them.
Tags:
Steps To Reproduce: /os sqline add *admin*
Open a non identified connection
/join #test-admin
Get banned
Additional Information:
Attached Files:
Notes
(0006718)
Adam   
2015-03-12 14:16   
Fixed in 92920f5a1c8866c8e26e1608f0feb3e3e54c8dd2 for non regex sqlines.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1635 [Anope Development (1.9.x series)] Chanserv major always 2015-02-16 02:51 2015-03-12 14:16
Reporter: Techman Platform: Linux  
Assigned To: Adam OS: Ubuntu  
Priority: high OS Version: 14.04 LTS 64 bit  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Anope bans user's real hostname/IP instead of their displayed host (vHost)
Description: This appears to specifically apply to when vHosts are set on users. When a user has a +x hashed host, Anope will ban the hashed hostname as it normally will. However, with a vHost activated (-x, basically) Anope bans the user's real hostname instead. Something internally in Anope isn't updated, it seems.

Tested with latest Anope git stable, and InspIRCd git stable
Tags:
Steps To Reproduce: 1. User join a channel that has a vHost set and enabled
2. !ban user
3. Anope will +b the user's real hostmask
Additional Information: Debug logs (for Anope project members only): https://pastebin.anope.org/index.php?page=viewpaste&id=10bdcc1067

Also tested on Teranova, and the same things happens. With a user with just +x and no vHost on their account, this issue doesn't happen. When you /hs on, and try to ban, the issue immediately happens.


Some IRC logs, if anyone's interested in that.

2:49:37 PM <Techman> Alright, I have the debug stuff
2:50:16 PM <Techman> Cronus: Can you get adam to unignore me so I can PM him the debug logs (contains sensitive data ofc)
2:56:06 PM <@LEthaLity> there's a protected paste option... although how you think no one else running Anope and Inspircd (including myself) would have noticed your alleged problem eludes me
3:02:22 PM <%Cronus> use the protected paste and paste in here
3:04:38 PM — %chaz waits
3:05:25 PM — ~DukePyrolator waits too
3:06:07 PM ↔ @Rob (was Rob_; opped) nipped out
3:12:10 PM <Techman> Oh whoops I forgot that Anope had a pastebin thing
3:12:15 PM <Techman> Yeah let me use that instead then
3:13:07 PM <Techman> https://pastebin.anope.org/index.php?page=viewpaste&id=10bdcc1067
3:14:53 PM — +SaberUK leaks Techmans sensitive data to the NSA
3:14:54 PM <%Cronus> what are we looking for again
3:15:39 PM <@LEthaLity> unmasked hostnames being banned/unbanned iirc
3:16:09 PM <Techman> Yeah
3:16:14 PM <@LEthaLity> I'm quite sure that tester doesn't have +x
3:16:26 PM <Techman> He has +x but then it's unset because he has a vhost
3:16:41 PM <Techman> I said displayed host wasn't being used, a vhost being shown counts as the displayed host right?
3:19:07 PM <%Cronus> can i get a line number when this happens
3:19:09 PM <%Cronus> so far i dont see shit
3:19:51 PM <Techman> I logged into my Anope account and now I'm locked out of the paste :/
3:20:19 PM <%Cronus> well you posted it as a guest
3:20:20 PM <Techman> You'll see at one point Anope bans the staff vhost, but then after a reconnect and despite the vhost being reapplied, Anope will ban the real hostname of the client
3:20:35 PM <Techman> I thought the site would respect a session cookie or something, my fault though
3:22:15 PM <%Cronus> around line 100
3:22:18 PM <%Cronus> for anyone else looking
3:22:27 PM <%Cronus> Adam if you cant see it https://pastebin.anope.org/index.php?page=viewpaste&id=10bdcc1067
3:22:42 PM <Techman> Do you guys believe me now?
3:23:24 PM <%Cronus> no
3:23:41 PM <%Cronus> really though you have a few modules, never heard of some
3:23:47 PM <%Cronus> how about you make the same thing happen on here?
3:24:00 PM <%Cronus> im kinda lazy atm, it is my day off, dont care too much to do stuff like this
3:25:23 PM <Techman> If I had to suspect, I think that teleport mod is doing this
3:25:33 PM <Techman> because I don't remember Anope ever doing this kind of stuff before
3:25:34 PM <@Adam> it is supposed to unban your real ip if you are the one requesting the unban
3:25:37 PM <@Adam> otherwise it will not
3:26:14 PM <%Cronus> unban?
3:26:17 PM <%Cronus> dont you mean ban
3:26:34 PM <Techman> I was the one that typed the !ban
3:26:40 PM <@Adam> not sure didnt look at the paste but this came up yesterday
3:26:44 PM <%Cronus> line 109 and 110 shows techman banning the user tester
3:26:51 PM <%Cronus> but their real ip/hsotname is banned
3:26:54 PM <%Cronus> not their cloaked/vhost
3:27:03 PM <@Adam> then thats a bug
3:27:14 PM <winterchillz> Guys, may I ask a question when you have a couple of spare minutes, not anope related but the guys over at eggdrop are not replying :(
3:27:18 PM <%Cronus> Techman can you get me a /ns info Tester
3:27:24 PM <Techman> sure
3:27:35 PM <Techman> from who's perspective Cronus ?
3:27:43 PM <Techman> Oper, user itself, or 3rd person?
3:27:53 PM <%Cronus> oper
3:27:57 PM <%Cronus> i wanna know its settings really
3:28:01 PM <%Cronus> so you can just paste that one line here
3:28:07 PM <Techman> k
3:28:08 PM <&Botox> anope: miwob opened PR 0000105 on 2.0: - Change SendForceNickChange() to use UIDs - Link: https://github.com/anope/anope/pull/105
3:28:09 PM <@Adam> winterchillz sure
3:28:38 PM <Techman> 3:28:16 PM <NickServ> Options: Private, Security, Auto-op, No expire
3:28:53 PM <%Cronus> k

7:12:12 PM <Techman> Did it
7:12:19 PM <Techman> It happened here too
7:12:51 PM <Techman> Typed /hs on on the test client, then went to !ban using my nick, and Anope banned the real hostname again
7:14:09 PM → Fudster joined (sid4817@teranova-rsnj81.charlton.irccloud.com)
7:14:13 PM <%Cronus> was that in your paste? i guess i didnt read the part where if you /hs on then it happens
7:14:34 PM <Fudster> Can anyone explain how I could add a !mute command to botserv.conf?
7:14:51 PM <Techman> Cronus: On my network, vhosts are automatically activated if they are set
7:15:00 PM <Fudster> oh it's Techman lol
7:15:12 PM — Fudster is Yofun
7:15:21 PM <Techman> There's a !mute thing in cs_ban now
7:15:24 PM <%Cronus> Techman so its only to do with vhosts
7:15:29 PM <Fudster> Techman: hm?
7:15:38 PM <Techman> I think it's safe to say that vhosts are a trigger to this, yes
Attached Files:
Notes
(0006717)
Adam   
2015-03-12 14:16   
This is not in the release and was introduced in d45cb5451eedd213862abeab5da9a30d96a494b2. It has been fixed in dc58239c8a4222cfc97d06f91574417446fe8e55.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1636 [Anope Stable (2.0.x series)] General minor always 2015-02-16 06:20 2015-03-12 14:16
Reporter: Mikaela Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: When grouping is disabled, NickServ only says grouping is disabled and links to login.anope.org
Description: If you run `/ns group` on Teranova, NickServ will tell you that " Registration has been disabled, please register at https://login.anope.org".

It should also mention that "Grouping is disabled on this network" as login.anope.org says nothing about grouping.
Tags:
Steps To Reproduce: Connect to irc.teranova.net
Run /ns group
Additional Information:
Attached Files:
Notes
(0006716)
Adam   
2015-03-12 14:16   
Fixed in 32c4908c8ce33a0b0c23fa05249db9aa5c47635c
(0006698)
Mikaela   
2015-02-17 08:04   
Config file from around that appears to only talk about registration and it says nothing about grouping. I don't know if anyone else understands it as "grouping also happens on login.anope.org", but that is how I understood it. I think maybe there should also be separate message.
(0006697)
Adam   
2015-02-16 23:50   
This is actually just the preconfigured message https://github.com/anope/anope/blob/2.0/data/modules.example.conf#L305, so it can easily be changed.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1642 [Anope Stable (2.0.x series)] General feature always 2015-03-08 00:54 2015-03-12 14:16
Reporter: NoMiaus Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Expiry option of BAN command doesn't work with the nick syntax
Description: The expiry option of BAN command doesn't work when a nick is used instead of a mask.
/msg BAN #Channel +10s Nick Reason: Nick is banned but the ban isn't removed after 10 seconds.
/msg BAN #Channel +10s Nick!*@* Reason: Nick is banned and the ban is removed after 10 seconds.
Tags:
Steps To Reproduce: /msg BAN #Channel +10s Nick Reason
Additional Information:
Attached Files:
Notes
(0006715)
Adam   
2015-03-12 14:16   
Fixed in c3cc5804c32f423d4017a825300d926895ef64ed
(0006703)
NoMiaus   
2015-03-08 15:03   
(Last edited: 2015-03-08 15:21)
I'm using UnrealIRCd 3.2.10.4. I checked it again: it happens when the nick isn't online so ChanServ sets a permanent ban to the nick. When the nick is connect on the network ChanServ sets a ban to the host, kicks and then removes the ban correctly. Anyway services answer: Ban on Nick1 expires in 10 seconds. Is it that how it should work?

Debug: Sent: :ChanServ PRIVMSG #services :COMMAND: NoMiaus!Me@xxxxxxxxx (NoMiaus) used BAN on #Test for Nick1
Debug: Sent: :ChanServ NOTICE NoMiaus :Ban on Nick1 expires in 10 seconds.
Debug: Sent: :ChanServ NOTICE NoMiaus :No users on #Test match Nick1.
Debug: Sent: :[DarkSide] MODE #Test +b Nick1!*@*

PS: When I ran the debug mode I noticed Anope shows 100 messages like this: [Mar 08 13:50:33.314106 2015] Extend for nonexistent type BS_DONTKICKOPS on 0x5084ec8.

(0006701)
chaz   
2015-03-08 14:09   
Hello,

I attempted to reproduce this and it seemed to work fine for me. (tested on InspIRCd)

Can you confirm that when you did try and use it against 'nick' that it infact resolved this down to the host?

What IRCd are you using?

Can you provide debug logs?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1639 [Anope Stable (2.0.x series)] General feature always 2015-03-01 16:25 2015-03-12 14:16
Reporter: Mikaela Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Too long password when registering, but the maximum password length is not told anywhere
Description: I connected to network using Anope and attempted registering at first. First I read the help text, then failed in registering twice as 100 and 50 characters are too long for Anope.

I think that the maximum password length should be said in the help text or the error message should say something like "Your password is too long. Please try again with a shorter password. The maximum password length for this network is XXX".
Tags:
Steps To Reproduce: "/msg NickServ help register", you see nothing on password length

"/msg nickserv register <put random password with like 100 characters here>" ==> "Your password is too long. Please try again with a shorter password."
Additional Information:
Attached Files:
Notes
(0006714)
Adam   
2015-03-12 14:16   
Fixed in c5ff7c686837afbb854aa6546ade3aa8c86a1cd1

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1641 [Anope Stable (2.0.x series)] General minor always 2015-03-08 00:25 2015-03-12 14:16
Reporter: NoMiaus Platform:  
Assigned To: Adam OS:  
Priority: high OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: CLONE resets some settings instead of copy them
Description: Hello, I'm have been testing the CLONE command and there is a big bug... Most of settings aren't copied, they are just reset. For example, all options that are showed in CS INFO such as persist, keep modes, restricted... aren't copied, CLONE sets the default options that are set in ChanServ.conf. It also happens with the ban type, mode lock or levels. In addition, email, url and badwords aren't copied too.
Tags:
Steps To Reproduce: /msg ChanServ CLONE #Channel1 #Channel2
Additional Information:
Attached Files:
Notes
(0006713)
Adam   
2015-03-12 14:16   
This actually was intentional for some resaon, though the help said otherwise, so I've adjusted the behavior in 78bff86dab32dc484164e5da8a535b3ec24c5c03.
(0006711)
Yoerger   
2015-03-11 17:10   
(Last edited: 2015-03-11 17:11)
Just tested this on my test network. I can confirm this. Using the ChanServ CLONE command does copy some settings as it did copy the channel description. However it did not copy other settings such as the channel SET options or the locked channel modes. Standard ChanServ configuration file.

As a side note, using the COPY command did change the registered field of the channel so that it appears as though it was registered on the first channel's registration date. I'm not sure if that's intentional.

First Test Channel with various settings:

[10:58] -ChanServ- Information for channel #test:
[10:58] -ChanServ- Founder: Yoerger
[10:58] -ChanServ- Description: Test Channel
[10:58] -ChanServ- Registered: Mar 04 21:26:41 2015 MST (6 days, 10 hours, 32 minutes ago)
[10:58] -ChanServ- Last used: Mar 11 07:58:43 2015 MST (now)
[10:58] -ChanServ- Ban type: 2
[10:58] -ChanServ- Options: Private, Peace, Restricted access, Security, Secure founder, Signed kicks, No expire, Topic retention
[10:58] -ChanServ- Mode lock: +smnt

New test channel before using CLONE.

[10:58] -ChanServ- Information for channel #test2:
[10:58] -ChanServ- Founder: Yoerger
[10:58] -ChanServ- Registered: Mar 11 07:58:39 2015 MST (39 seconds ago)
[10:58] -ChanServ- Last used: Mar 11 07:59:18 2015 MST (now)
[10:58] -ChanServ- Ban type: 2
[10:58] -ChanServ- Mode lock: +nt
[10:58] -ChanServ- Options: Peace, Security, Secure founder, Signed kicks, Topic retention

* -> /msg ChanServ CLONE #test #test2

#test2 After using /cs CLONE

[11:01] -ChanServ- Information for channel #test2:
[11:01] -ChanServ- Founder: Yoerger
[11:01] -ChanServ- Description: Test Channel
[11:01] -ChanServ- Registered: Mar 04 21:26:41 2015 MST (6 days, 10 hours, 35 minutes ago)
[11:01] -ChanServ- Last used: Mar 11 08:01:53 2015 MST (now)
[11:01] -ChanServ- Ban type: 2
[11:01] -ChanServ- Mode lock: +nt
[11:01] -ChanServ- Options: Peace, Security, Secure founder, Signed kicks, Topic retention


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1638 [Anope Stable (2.0.x series)] General minor N/A 2015-02-27 22:38 2015-02-27 22:38
Reporter: ChrisL1024 Platform: All  
Assigned To: OS: All  
Priority: normal OS Version: All  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: AnopeSMTP.exe Authentication
Description: anopesmtp.exe only provides for a mail host IP address and sender email address.

Please extend to provide for port, username, and password for remote mail services and update documentation in service.conf accordingly.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1637 [Anope Stable (2.0.x series)] General minor N/A 2015-02-22 21:11 2015-02-24 16:59
Reporter: ChrisL1024 Platform: Windows  
Assigned To: OS: Windows / Windows Server  
Priority: low OS Version: 7+ / 2012+  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Anope As Windows Service
Description: Anope doesn't support running as a windows service.
Tags:
Steps To Reproduce:
Additional Information: Please find attached a Visual Studio 2013 project for an Anope service wrapper. One needs Community Edition (free) or higher to build (Express not sufficient).

The code is all in one file, heavily commented, including instructions on how to install and use it with either InspIRCD and UnrealIRCD.

Find me on Teranova #anope if you have questions / need assistance.
Attached Files: AnopeService.zip (7,801 bytes) 2015-02-22 21:11
https://bugs.anope.org/file_download.php?file_id=354&type=bug
AnopeService2.zip (8,282 bytes) 2015-02-24 16:57
https://bugs.anope.org/file_download.php?file_id=355&type=bug
Notes
(0006700)
ChrisL1024   
2015-02-24 16:59   
Please discard the originally uploaded zip in favor of the more recent AnopeService2.zip, which is written a bit better and eliminates a small memory leak.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1629 [Anope Stable (2.0.x series)] General major always 2014-12-19 16:45 2014-12-20 18:47
Reporter: webczat Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: services sometimes do not finish bursting and fork when certificate fingerprints are used
Description: Hello.

I am using anope-2.0 from git and inspircd-2.0 and I am using ssl certificate fingerprint to identify to my account, with sasl mechanism EXTERNAL.
Here is the problem that I've encountered:
1. I start services when not being connected, I do it from a terminal and they successfully finish linking and fork.
2. I connect to the irc server and log in using sasl EXTERNAL, services correctly identify me, I am logged as ircop too.
3. I kill/shutdown services and start them up again, they successfully connect but do not fork.
4. My irc client shows that services do link and identify me again with my certificate fingerprint, but they do not finish bursting to the server and for that reason they stay in the foreground and do not fork.
5. When I try to disconnect, services suddenly fork as they should do it before.

This problem also happens when not using sasl external.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: debuglog (172,058 bytes) 2014-12-20 13:50
https://bugs.anope.org/file_download.php?file_id=352&type=bug
Notes
(0006693)
Adam   
2014-12-20 18:47   
What happens if you use the poll or select SE with inspircd?
(0006692)
webczat   
2014-12-20 13:52   
as you see, some things happen after a minute, not sure why. like it all starts to move when server sends ping.
(0006688)
Adam   
2014-12-20 04:53   
Need debug logs.
(0006686)
webczat   
2014-12-19 17:21   
Correction: if I am correct this happens when services join to a network where at least one user is already logged in and it doesn't matter what login method was used.
Services never finish bursting unless something happens on the network, for example someone issues a command to one of the services, joins a channel etc, then services will immediately finish bursting.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1627 [Anope Stable (2.0.x series)] General minor always 2014-12-06 14:11 2014-12-11 21:40
Reporter: webczat Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: +x usermode sometimes set on services restart when it should not be set
Description: When ns_keep_modes option on an account is set, then services give me +x when I restart them, although it does not happen on identify.
Tags:
Steps To Reproduce: 1. The server should set usermode +x for each connecting user.
2. The user account should have keepmodes turned on, in my case, after doing it, I set modes +iIwW on myself.
3. I didn't test this in every possible scenario, in my case I had a ssl certificate fingerprint added to the account for login, and my client didn't use any form of SASL authentication.
4. I connect to the IRC server using ssl and my client certificate. when user registration finishes, I get usermode +x set on myself.
5. Because I have an irc operator account with ssl cert fingerprint set and autologin set to true, I am then logged in to the ircop account and subsequently get +o then +hs with appropriate snomask. Also, because my opertype has a vhost "sadmin.webczatnet.pl" set, server changes my displayed host to it and unsets +x mode as it should.
6. I see the server notice about me connecting, I believe that it is the time services see me. Services identify me using my fingerprint, and set +iIrwW, so everything seems correct.
7. I restart services. when they return to the network, I get usermode +x set again on me, that in turn unsets the vhost from my opertype, I don't think it should happen as usermode +x was never set on login.
Additional Information: I use server inspircd-2.0.18, anope version 2.0 from git.
Attached Files:
Notes
(0006685)
webczat   
2014-12-11 21:40   
I tried to fix this issue, probably succeeded. this is the link to the pull request:
https://github.com/anope/anope/pull/94
(0006684)
webczat   
2014-12-11 19:41   
Hello!

I have discovered what actually causes the bug.

When I connect and get +x on connection, my host is cloaked.
When I oper up and my vhost changes, inspircd unsets +x on me, but the mode change is not broadcast to other servers, only vhost change is.
So servers see the vhost change and then reflect this by unsetting +x in their view of the user, but anope does not and thinks the user still has +x, that is a small desync.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1628 [Anope Stable (2.0.x series)] General crash unable to reproduce 2014-12-07 22:47 2014-12-07 22:47
Reporter: cman Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Kill loop detected
Description: [23:02] -Global- Services are restarting, they will be back shortly - please be good while we're gone
[23:02] <@Global> Kill loop detected. Are Services U:Lined?

even though the services are ulined on all my servers why did it do that
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1621 [Anope Stable (2.0.x series)] General minor always 2014-11-15 18:54 2014-12-06 03:08
Reporter: azander Platform: Linux  
Assigned To: Adam OS: Ubuntu  
Priority: normal OS Version: 14.10  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Logging has a discrepency
Description: When logging /ns Identify .... you get 2 different kinds of entries in the log files. Examples below.

[Nov 14 19:52:20 2014] A user identified to account Gemini using SASL
[Nov 14 21:45:25 2014] USERS: Magma!~Joshua@<hostmask> is no longer identified as Clay
[Nov 14 21:45:36 2014] Cross!~KEPLER@<hostmask> automatically identified for group Cross
[Nov 14 21:49:01 2014] USERS: Plushiemancer!~laskaris@<hostmask> is now identified as Plushiemancer


The difference from the user's side is that the entries with "USERS:" are from when the user actually identied using the /ns Identify command, while the ones without "USERS:" are auto-identifies based on hostmask or SASL. They all should have the USERS prefix.



Tags:
Steps To Reproduce: Logging block from services.conf:

log
{
        target = "services.log #services"
        bot = "Global"
        logage = 3
        admin = "*"
        override = "chanserv/* nickserv/* memoserv/set ~botserv/set botserv/*"
        commands = "~operserv/* chanserv/topic chanserv/register chanserv/drop nickserv/register nickserv/drop"
        servers = "*"
        channels = "join"
        users = "~mode ~disconnect *"
        other = "*"
        rawio = no
        debug = no
}
Additional Information:
Attached Files:
Notes
(0006682)
Adam   
2014-12-06 03:08   
fixed in 4f33b17f96257b0ad4b87339509e8a5a8ea5ed77

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1626 [Anope Stable (2.0.x series)] General feature N/A 2014-12-04 02:25 2014-12-04 02:25
Reporter: alefburzmali Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: nickserv/alist should show accesses granted by channels on access lists.
Description: Currently, alist shows only the channels when you are directly on their access list. If you have access to a channel #a because you are on the access list of #b, and #b is on the access list of #a, it does not shows #a.

chanserv/status correctly indicates your level on #a. nickserv/alist should have the same behavior and list both #a and #b with their respective level.
Tags:
Steps To Reproduce: * /cs access #b add nick 10
* /cs access #a add #b 5
* /cs status #a nick
     Access for nick on #a:
     nick matches access entry #b, which has privilege 5.

* /ns alist nick
     #b 10

It should indicate:
     #a 5
     #b 10
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1624 [Anope Stable (2.0.x series)] General minor N/A 2014-11-29 01:05 2014-11-29 01:45
Reporter: webczat Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: chanserv help should take privileges into account
Description: Many commands in chanserv have help that, in it's contents, tells the user what level is by default required to access a given command.
However, it does not take account that those defaults can be changed not only per channel, but also on the whole network, and in this case help output can be wrong in some cases in this respect.
Also, not all access systems have to be loaded.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006677)
webczat   
2014-11-29 01:45   
Example: this is help output of chanserv command "KICK" taken from terranova:
 00:38 -- ChanServ (services@services.teranova.net): Syntax: kick channel nick [r
 eason]
 00:38 -- ChanServ (services@services.teranova.net): kick channel mask [r
 eason]
 00:38 -- ChanServ (services@services.teranova.net):
 00:38 -- ChanServ (services@services.teranova.net): Kicks a specified nick from a channel.
 00:38 -- ChanServ (services@services.teranova.net):
 00:38 -- ChanServ (services@services.teranova.net): By default, limited to AOPs
 or those with level 5 access
 00:38 -- ChanServ (services@services.teranova.net): and above on the channel. Channel founders can also specify masks.

In the code, the fact that this command is restricted by default to AOPS or access level 5 is given statically, but network defaults can be changed using privilege blocks in the config, so this info may become invalid.
In addition, someone may want to use chanserv with no xop module at all, for example, so it could possibly confuse users.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1622 [Anope Stable (2.0.x series)] General feature N/A 2014-11-15 19:18 2014-11-15 19:18
Reporter: azander Platform: all  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add Color code capabilites to channel log files
Description: Feature reqest from one of my services ops.

I am not entirely sure this can be done.

What they would like to see is a way to pass a color code (mirc/xchat/etc) from the logging function to the channel output for logging. Even if it has to be by group (USERS:,CHANNEL:,etc) that would be fine.

The logging system would either need to add it when sending to channel, or strip it when sending to file, sql, or ldap. It would probably be easiest to add rather than to strip.

example using forum-style BBCode:

[Red]USERS:{/red] message
[Blue]CHANNEL:[/blue] message

--or--

[Red]Users: message... [/red]
[Blue]CHANNEL: message ...[/blue]

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1619 [Anope Stable (2.0.x series)] General feature always 2014-10-12 01:06 2014-11-04 22:39
Reporter: alefburzmali Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Command privilege chanserv/access/list is inconsistent
Description: cs_xop uses the chanserv/access/list command access to grant read-only access to the LIST subcommands of QOP, AOP... but cs_access and cs_flags ignore it and requires the chanserv/access/modify privilege.
Tags:
Steps To Reproduce:
Additional Information: As discussed on IRC, a solution could be to replace the command by a privilege and implement it in cs_access, cs_flags for the LIST/VIEW subcommands. For consistency with the chanserv/access/modify privilege, it could be added in cs_akick too.
Attached Files:
Notes
(0006674)
Adam   
2014-11-04 22:39   
Fixed in 96583892c6a0bc48029348ddcf86b1afc5a9915d
(0006662)
alefburzmali   
2014-10-12 01:12   
See https://github.com/anope/anope/pull/89

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1620 [Anope Stable (2.0.x series)] General minor always 2014-10-12 04:53 2014-11-04 08:38
Reporter: rfrederick Platform: Unreal 3.2.10.4  
Assigned To: Adam OS: FreeBSD  
Priority: normal OS Version: 9.3-RELEASE  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Default Modes for MLOCK Not Set on Initial Channel Registration
Description: When registering a channel the default modes for MLOCK as configured in chanserv.conf are not set by ChanServ at registration time. It takes either manually changing a channel mode not under MLOCK or a parting and rejoining by all users for the MLOCKed modes to be properly set by ChanServ.
Tags:
Steps To Reproduce:
Additional Information: Anope Version: 2.0.1
IRCd: Unreal 3.2.10.4
Attached Files:
Notes
(0006673)
Adam   
2014-11-04 08:38   
Thanks, fixed in 408ec02406f115583229216f9b7d9a2c327dfb0a
(0006663)
rfrederick   
2014-10-12 19:15   
To clarify, the actual server-side MLOCK looks to be successfully set on the modes. The issue is that the modes themselves (other than +r) are not set on the channel upon registration with ChanServ.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1598 [Anope Stable (2.0.x series)] General feature always 2014-05-07 20:23 2014-11-04 08:38
Reporter: elskwi Platform: ALL  
Assigned To: Adam OS: ALL  
Priority: low OS Version: ALL  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Change of behaviour of the defcon
Description: The defcon changes modes and doesn't keep mode before the defcon :

#mychan is +i
something not fun appears, admin set defcon : all chanmodes +i
something not fun disappears, admin set defcon 5
#mychan has lost the +i

Tags:
Steps To Reproduce: Set a +i mode on a channel
Change a defcon level with chanmodes +i
Set this defcon level
Set the default defcon level
Channel is now without +i
Additional Information: This wasn't the default behaviour in Anope 1.8.8
The defcon restores channel modes in their previous states

The documentation says :
/*
     * The channel modes to set on all channels when the DefCon channel mode system is in use.
     *
     * Note 1: Choose these modes carefully, because when DefCon switches to a level which does NOT have
     * the mode setting selected, Services will set the reverse on all channels, e.g. if this setting
     * is +RN when DefCon is used, all channels will be set to +RN, when DefCon is removed, all
     * channels will be set to -RN. You don't want to set this to +k for example, because when DefCon
     * is removed, all channels are set -k, removing the key from previously keyed channels.
     *
     * Note 2: MLOCKed modes will not be lost.
     */
    chanmodes = "+m"

I totally understand what the defcon do now !

But, it's not possible to ask every channel owner to put mlock, someone would just want to put a mode for some hours and want to retrieve the channel in its original state even if defcon is used before he come back.
For example, I put a +i mode on a channel for some reasons. I come back and want to have my room with the same state before I left.

Anyway, the mode command for channel modes become useless with the current behaviour.
Attached Files:
Notes
(0006672)
Adam   
2014-11-04 08:38   
I've checked the old 1.8 behavior and it did not remember modes and then only unset he ones that weren't set before, as the comment says that you pasted (even though you seem to think it says that it did?). Having defcon override mlock when defcon is being turned off is a bug though, so I've fixed that in c4460784c2b3695b9f3a8073fc61712e9f804573.
(0006642)
Yoerger   
2014-05-08 00:24   
I also disagree about the change, per our discussion in IRC. If users want modes to stay, they would MLOCK them. Also per discussion, DEAFCON should only be used in emergencies and debugging. So the frequency of this occouring should be rare.
(0006641)
elskwi   
2014-05-07 23:15   
(Last edited: 2014-05-07 23:41)
On a network, users haven't to register a channel and it is not an obligation.
Someone just want to create a channel without register it and then he lost all settings because of the defcon.

This is an other reason that make me think this is a bad behaviour and this feature doesn't cover all pragmatical use cases.

Something buggin me a lot :

[00:03] <¤ChanServ> COMMAND: elskwi used MODE on #solarproject to lock +nti
[00:08] <¤OperServ> ADMIN: elskwi used DEFCON to change defcon level to 4
[00:08] <¤OperServ> DEFCON: setting +RNnmsTt on all channels
... on channel #solarproject
[00:08] * OperServ sets mode: +smRNT
...
[00:08] <¤OperServ> ADMIN: elskwi used DEFCON to change defcon level to 5
[00:08] <¤OperServ> DEFCON: setting -RNnmsTt on all channels
... on channel #solarproject
[00:08] * OperServ sets mode: -smntRNT

I have set the mlock
#solarproject t rnt MODE cannot be set due to channel having an active MLOCK restriction policy

result of info command
-ChanServ- Information for channel #solarproject:
...
   Mode lock: +rnti

And the documentation says : Note 2: MLOCKed modes will not be lost

(0006640)
azander   
2014-05-07 22:43   
I don't think this behavior should be changed. Channel owners need to take responsibility to managing their channels. This includes using chanserv and mlock.

--Az

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1611 [Anope Stable (2.0.x series)] General minor always 2014-09-10 17:57 2014-11-04 08:15
Reporter: alefburzmali Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Defcon operonly and silentoperonly actions are not implemented
Description: If a Defcon level with the operonly or the silentoperonly action is activated, Services don't ignore the normal, non-oper users and will continue to execute their commands.

The only limited commands are the ones blocked by the nonewchannels / nonewnicks / nomlockchanges / nonewmemos action, which are working as intended.

Tags:
Steps To Reproduce: * activate os_defcon and add the operonly / silentoperonly to a level
* reload
* /msg operserv defcon 2
* as a normal user, send commands to NickServ, ChanServ, etc
Additional Information:
Attached Files:
Notes
(0006660)
alefburzmali   
2014-10-12 00:38   
This was fixed by DukePyrolator in commit 8e7b742ec73a0a0c5a9ae1dc4ce246ebbe37c737. I've tested it, and it works as expected. Thanks!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1612 [Anope Stable (2.0.x series)] General feature N/A 2014-09-10 18:04 2014-11-04 07:20
Reporter: alefburzmali Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Make separate privileges for the operserv/oper subcommands
Description: Currently the operserv/oper privilege allows an oper to add/del opers with the same privileges as himself.

It would be nice to have different privileges for the operserv/oper subcommands, to allow some oper type to use LIST / INFO and some other to use ADD / DEL.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006671)
Adam   
2014-11-04 07:20   
Done in 1c1297695894fd543554b1a063b1dee990594885, thanks
(0006661)
alefburzmali   
2014-10-12 01:12   
See https://github.com/anope/anope/pull/88 which add a operserv/oper/modify privilege which is required to use ADD or DEL.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1614 [Anope Stable (2.0.x series)] General minor always 2014-09-13 10:01 2014-11-04 07:15
Reporter: capitaine Platform: Linux  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Some data missing after migration
Description: I migrated an Anope 1.8 database to 2.0, but both NickServ/ChanServ e-mails and URLs were missing in the export.

Tags:
Steps To Reproduce: After migration, I couldn't find them with :
/NS info foo, or /CS info #foo
nor a Mysql SELECT * on NSMiscData / CSMiscData

However, if I set an email or URL manually, it works well.
Additional Information:
Attached Files:
Notes
(0006669)
Adam   
2014-11-04 07:15   
(Last edited: 2014-11-04 07:15)
I doubt NickServ emails are actually lost. ChanServ mails and URLs as well as NickServ URL/ICQ are intentionally lost currently since they are now a part of the misc stuff as you stated, and its difficult to do properly the way the code is currently.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1605 [Anope Stable (2.0.x series)] General crash always 2014-06-19 16:01 2014-11-04 04:38
Reporter: azander Platform: Linux  
Assigned To: Adam OS: OpenSuse  
Priority: normal OS Version: 13.1  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Services crashes when os_info has data stored and you try to issue a moduload
Description: Once you set data in a module, such as os_info, you cannot use operserv to modunload it. It causes services to crash.

Tags:
Steps To Reproduce: 1) add info to a nick or channel using /os info add <target> <message>

2) issue a modunload os_info

3) See crash
Additional Information: I found this while trying to debug an issues with os_swhois. Already reported to Adam in #anope. Documenting here to completeness.
Attached Files:
Notes
(0006667)
Adam   
2014-11-04 04:38   
This was fixed, in ff93355af851541e21218811eb46190a3eb070a3
(0006666)
azander   
2014-11-03 18:25   
I thought this was fixed already. Why is it still in the bug tracker?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1618 [Anope Stable (2.0.x series)] General major always 2014-10-10 01:21 2014-10-15 01:01
Reporter: alefburzmali Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: DEFCON_REDUCED_SESSION breaks the session counts
Description: When DEFCON_REDUCED_SESSION is in action, the session count is no longer correctly recorded. It allows to completely bypass both the DEFCON reduced session limit and the default session limit.

With the default setting "sessionlimit = 2":
- 3 users can connect from the same IP without being killed, the SESSION VIEW command reports 3 users from that IP
- the 4th to connect is killed, the SESSION VIEW command reports only 2 users from that IP (3 are still connected)
- the 4th user can reconnect without being killed, the SESSION VIEW command reports only 3 users from that IP (4 are connected)
- can be repeated with as many users as wanted

Ater that, if DEFCON is disabled, the session count for that IP is still messed up until all the users from that IP have disconnected.
Tags:
Steps To Reproduce: Have 4 users connect from the same IP while DEFCON_REDUCED_SESSION with sessionlimit = 2 is in action. Only one user is killed, SESSION VIEW reports only 2 sessions from that IP and the fourth user can reconnect without being killed.

Have a 5th user to connect from the same IP, he is killed but he can reconnect without being killed. Repeat as much as you want.
Additional Information: With the following (default) settings:
- os_session defaultsessionlimit = 3
- os_defcon sessionlimit = 2
- os_defcon level3 has reducedsessions


Without defcon:
- user AA connects from 192.0.2.1
- user BB connects from 192.0.2.1
- user CC connects from 192.0.2.1
- /os session view 192.0.2.1 -> 3 sessions
- user DD connects from 192.0.2.1, he is killed by OperServ (Session limit exceeded)
- /os session view 192.0.2.1 -> 3 sessions


With defcon:
- /os defcon 3
  ...
  * Use the reduced session limit of 2
- user AA connects from 192.0.2.1
- user BB connects from 192.0.2.1
- user CC connects from 192.0.2.1. CC is not killed even though he should be
- /os session view 192.0.2.1 -> 3 sessions
- user DD connects from 192.0.2.1. DD is killed by OperServ (Defcon session limit exceeded)
- /os session view 192.0.2.1 -> **2** sessions instead of 3 (AA, BB and CC)
- user DD reconnects from 192.0.2.1. He is not killed.
- /os session view 192.0.2.1 -> **3** sessions instead of 4 (AA, BB, CC and DD)
- user EE connects from 192.0.2.1, is killed by OperServ (Defcon session limit exceeded)
- user EE reconnects from 192.0.2.1. He is not killed.
- /os session view 192.0.2.1 -> **3** sessions instead of 5
- /os defcon 5
- /os session view 192.0.2.1 -> still 3 sessions instead of 5
- DD quits
- /os session view 192.0.2.1 -> 2 sessions instead of 4
Attached Files:
Notes
(0006665)
Adam   
2014-10-15 01:01   
This was due to module event prioritization being fubard. os_defcon relies on accessing os_sessions's session data after it has already processed.
(0006664)
alefburzmali   
2014-10-13 17:46   
DEFCON_NO_NEW_CLIENTS (which kills the new clients) has the same effect. Session count is one less than what it should be after the client is killed.

DEFCON_AKILL_NEW_CLIENTS glines the host, so the session count for that IP is set to 0 as all the clients are disconnected.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1617 [Anope Stable (2.0.x series)] General major sometimes 2014-10-09 16:17 2014-10-09 23:46
Reporter: alefburzmali Platform:  
Assigned To: Robby OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Default DEFCON settings do not require any permission
Description: In operserv.example.conf, the operserv/defcon command is the only command definition to not require a corresponding permission to be executed. If the command is enabled without paying careful attention, anyone who can access OperServ can use the defcon command.

The default configuration should set a "operserv/defcon" permission like every other OperServ commands.
Tags:
Steps To Reproduce:
Additional Information: The command is disabled by default, so it must be enabled to be abused. Moreover, the "opersonly = yes" default setting restrict its access to opers only.

However, anyone with an o:line and a registered nick can execute defcon, even if he is not a services oper. If opersonly is set to "no", any registered user can access it.
Attached Files:
Notes
(0006659)
Robby   
2014-10-09 23:40   
Thanks for reporting. Fixed in commit 0991d4e1998c5a87c8deb3f9460685eed0212160.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1613 [Anope Stable (2.0.x series)] General feature N/A 2014-09-11 03:51 2014-09-22 04:47
Reporter: MathK1LL Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add custom name (or the username used) when adding a hostmask to ChanServ access list
Description: Examples:

While I know *now* that whom these hosts belong, I may not in the future. I'd like a way to add a custom name to them so I know who they are.

[18:39:48] ChanServ [services@services.nite-serv.com]: 8 3 *!*@cloaked-o08h3o
[18:39:48] ChanServ [services@services.nite-serv.com]: 9 3 *!*@cloaked-3ag.ilf.0.127.IP

Proposed output:

[18:39:48] ChanServ [services@services.nite-serv.com]: 8 3 *!*@cloaked-o08h3o (UptimeBot)
[18:39:48] ChanServ [services@services.nite-serv.com]: 9 3 *!*@cloaked-3ag.ilf.0.127.IP (Uptime)

or another column called "description" that we can modify as needed. :)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006658)
cronus   
2014-09-22 04:47   
I have found myself with the same issue. Others have added hosts that I end up having no clue who it was...

+1

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1609 [Anope Stable (2.0.x series)] General minor always 2014-07-26 16:44 2014-07-26 17:01
Reporter: marquim Platform: InspIRCd 2.0.16 (stable)  
Assigned To: OS: Ubuntu Server  
Priority: normal OS Version: 14.04 LTS amd64  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Weird random nickname when using SVSNICK on an enforced nickname
Description: Weird random nickname when issuing OperServ SVSNICK on an enforced nickname, while the original nickname is reserved.
Tags:
Steps To Reproduce: Client 0 (C0) - Regular user
Client 1 (C1) - Services Root

C0: /nick <registered_nickname>
C0: don't identify and get an enforced nickname *or* identify, issue NickServ LOGOUT and wait for the random nickname enforcement

C1: /os svsnick <enforced_nickname> <registered_nickname> (during the period when the original nickname is reserved, 1m in my case)
Additional Information: Those strange nicknames are aways starting with digits.
Attached Files: Regular_user.png (276,078 bytes) 2014-07-26 16:44
https://bugs.anope.org/file_download.php?file_id=351&type=bug
Notes
(0006654)
Adam   
2014-07-26 17:01   
I think this is because you are SVSNICKing the user to a resv'd nickname which InspIRCd will resolve by switching the user to their UID. Assuming you have m_svshold set?

I don't think this is a bug really. Perhaps services shouldn't allow svsnick to known resv'd nicks.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1604 [Anope Stable (1.8.x series)] Other crash always 2014-06-02 13:19 2014-06-02 15:06
Reporter: KaitoDaumoto Platform: Windows  
Assigned To: OS: Windows Server 2008 R2  
Priority: urgent OS Version: 64 bit  
Status: new Product Version: 1.8.8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: About this error
Description: 148:15pm | -irc.omegairc.org- *** Global -- from hub.omegairc.com: PANIC! buffer = :Derp PRIVMSG #Omega :!help
148:15pm | -irc.omegairc.org- *** LocOps -- Received SQUIT hub.omegairc.com from hub.omegairc.com[127.0.0.1] (Services terminating on signal 11)
148:15pm | * &Maya (Bot@Bot.at.OmegaIRC) Quit (irc.omegairc.org hub.omegairc.com)
Tags:
Steps To Reproduce:
Additional Information: how do i fix that?
Attached Files:
Notes
(0006652)
LEthaLity   
2014-06-02 15:06   
This wont be a bug within Anope, probably best joining irc.anope.org #anope.
You'll need to provide more information, such as modules loaded (I assume bs_fantasy_ext). Run anope with anope.exe -support and show us the log once you've made it crash.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1602 [Anope Stable (2.0.x series)] General crash always 2014-06-01 11:49 2014-06-02 00:16
Reporter: roadrunner Platform: Anope 2.0.1  
Assigned To: Adam OS: Windows 7 Professional  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Services crash during start up
Description: After successful installing anope-2.0.1.exe and try to start from commandline by

anope.exe --nofork

services chrash immediately.

I have copied config files, anope.db and backup files from 2.0.0 to 2.0.1 directories and make all of them "chmod rwx" for the apporpriate user.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1601 [Anope Stable (2.0.x series)] General crash sometimes 2014-05-28 17:23 2014-05-28 17:39
Reporter: elskwi Platform: x86_64  
Assigned To: OS: Linux Debian  
Priority: normal OS Version: 6.0.9  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Command chanserv mode lock makes services crash
Description: commands :
msg chanserv mode #operators lock add +t
msg chanserv mode #operators lock add +tTzs

Services crach and start again with a crontab

Tags:
Steps To Reproduce: Sometimes, the command makes services crash and works after reboot
Additional Information: No log

Use MySQL module
Attached Files:
Notes
(0006651)
Adam   
2014-05-28 17:39   
I am not able to reproduce this using db_sql, this is my debug log:

[May 28 12:35:42.818004 2014] Debug: Received: :869AAAAAA PRIVMSG 00BAAAAAC :mode #moo lock add +t
[May 28 12:35:42.820421 2014] Debug: Sent: :00BAAAAAC NOTICE 869AAAAAA :+t locked on #moo.
[May 28 12:35:42.820476 2014] COMMAND: Adam!Adam@192.168.1.123 (Adam) used MODE on #moo to lock +t
[May 28 12:35:46.602158 2014] Debug: Received: :869AAAAAA PRIVMSG 00BAAAAAC :mode #moo lock add +tTzs
[May 28 12:35:46.632091 2014] Debug: Sent: :00BAAAAAC NOTICE 869AAAAAA :+tTzs locked on #moo.
[May 28 12:35:46.632146 2014] COMMAND: Adam!Adam@192.168.1.123 (Adam) used MODE on #moo to lock +tTzs
[May 28 12:35:46.632424 2014] Debug: Sent: :00BAAAAAC FMODE #moo 1401294931 +Tzs

Can you provide a debug log?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1364 [Anope Development (1.9.x series)] Chanserv crash always 2011-12-05 18:19 2014-05-16 17:35
Reporter: RaMiRoSaMoLo Platform: Unreal3.2.9  
Assigned To: Adam OS: FreeBSD  
Priority: high OS Version: 6.3-RELEASE-p1  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash using /cs kick nick reason [Anope 1.9.5]
Description: <ChanServ> COMMAND: NAVAC!daniel.nc@antisocial.hack3r.us used kick on #isengard for SebaaS
Kick ElOjoQueTodoLoVe kick [SebaaS] of [#isengard] with reason [ABCD (NAVAC)]

Quit OperServ [services@services.host] Quit: [irc.cibercms.info services.cibercms.info]
Quit NickServ [services@services.host] Quit: [irc.cibercms.info services.cibercms.info]
Quit MemoServ [services@services.host] Quit: [irc.cibercms.info services.cibercms.info]
Quit HostServ [services@services.host] Quit: [irc.cibercms.info services.cibercms.info]
Quit Global [services@services.host] Quit: [irc.cibercms.info services.cibercms.info]
Quit ElOjoQueTodoLoVe [Bot@services.cibercms.info] Quit: [irc.cibercms.info services.cibercms.info]
Tags:
Steps To Reproduce: 1º /cs kick NICK ABCD
2º Crash of Services
Additional Information: Only happens if the reason is: "ABCD"
Attached Files:
Notes
(0006038)
Adam   
2011-12-05 18:52   
Fixed in aeefe1650e29e5905cfe212958622663a4ceb6c4

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1600 [Anope Stable (2.0.x series)] General major always 2014-05-11 23:19 2014-05-15 00:19
Reporter: simos Platform:  
Assigned To: Adam OS: debian  
Priority: high OS Version: 7  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Expired account are not removed from channel access list
Description: When an account expire if it was present in some channels access list is nick is not removed from access list. It he was founder of some channels the channels are not dropped and in cs info show the expired nick as founder.

Tags:
Steps To Reproduce:
Additional Information: Tested with sql_live and flatfile.
Source updated to the last git.
Attached Files: anope.tiff (164,298 bytes) 2014-05-13 21:44
https://bugs.anope.org/file_download.php?file_id=350&type=bug
tiff
Notes
(0006649)
Adam   
2014-05-15 00:19   
fixed as part of 0001585
(0006646)
simos   
2014-05-13 21:49   
In the attached image the query on sql to discover the nick , below the grep of the anope.db for crissy :

END
OBJECT ChanAccess
ID 76
DATA provider access/xop
DATA ci #AlBarDiPipps
DATA mask crissy
DATA creator Unknown
DATA last_seen 1295462941
DATA created 1398291096
DATA data VOP
END
--
END
OBJECT ChanAccess
ID 723
DATA provider access/xop
DATA ci #elite
DATA mask crissy
DATA creator Unknown
DATA last_seen 1275216367
DATA created 1398291096
DATA data VOP
END
--
END
OBJECT ChanAccess
ID 2490
DATA provider access/access
DATA ci #RadioWj
DATA mask crissy
DATA creator Unknown
DATA last_seen 1332010157
DATA created 1398291096
DATA data 5
END
--
DATA unread 0
DATA receipt 0
END
OBJECT Memo
ID 151
DATA owner crissy
DATA time 1298800521
DATA sender Fantasmina
DATA text ciaoo cara prova finita
DATA unread 0
DATA receipt 0
END
OBJECT Memo
ID 152
DATA owner crissy
DATA time 1298800574
DATA sender lucrezia
DATA text ammora ti voglio bene *
DATA unread 0
DATA receipt 0
END
OBJECT Memo
ID 153
DATA owner crissy
DATA time 1304585162
DATA sender Elisabetta
DATA text scusa ma ero al telefono e m hanno tenuto 2 ore s - t mando un bacio , appena t vedo t kiamo :-*
DATA unread 0
DATA receipt 0
END
OBJECT Memo
ID 154
DATA owner crissy
DATA time 1309339017
DATA sender Elisabetta
DATA text nn t becco mai (, tesora mi manchi tanto.. per un po' nn entro la', ho visto cose ke nn volevo vedere.. e m hanno fatto male, poi t dico .. cercami se entri. Ah Pipps m'ha mezzo proposto la @ su italy ma ho rifiutato perke' nn me la sento. T mando un bacio stella. Kisssssssss!
DATA unread 0
DATA receipt 0
END
OBJECT Memo
ID 155
DATA owner crissy
DATA time 1313794775
DATA sender Max75
DATA text ciao, scusami ma non c'ero, anche se non ci sono lascia scritto.... poi leggo e ti rispondo... ciauz
DATA unread 0
DATA receipt 0
END
OBJECT Memo
ID 156
DATA owner crissy
DATA time 1351450007
DATA sender gus
DATA text grazie di tutto silviè, ti voglio bene sappilo.... -*
DATA unread 0
DATA receipt 0
END
OBJECT Memo
ID 157
DATA owner crissy
DATA time 1367602955
DATA sender Nala
DATA text che dici te arriva sto messaggio
DATA unread 0
DATA receipt 0
END
OBJECT Memo
ID 158
DATA owner crissy
DATA time 1368654470
DATA sender Max`
DATA text kisssssss :-*
DATA unread 0
DATA receipt 0
END
OBJECT Memo
ID 159
DATA owner crissy
DATA time 1369928447
DATA sender Max`
DATA text ciao tesò, ci si becca sabato, un bacione grosso kisss
DATA unread 0
DATA receipt 0
END
OBJECT Memo
ID 160
DATA owner crissy
DATA time 1380891398
DATA sender Max`
DATA text 14:01 ?                 BarBone ¦ ciao max volevo solo salutarti e scusamis e sono sparito hoa vuto un po' di problemini...... ( non ho fatto in tempo a rispondere )
DATA unread 0
DATA receipt 0
END
OBJECT Memo
ID 161
DATA owner crissy
DATA time 1370985154
DATA sender Max`
DATA text non era lei ciao tesò :-*
DATA unread 0
DATA receipt 0
END
OBJECT Memo
ID 162
DATA owner crissy
DATA time 1372718174
DATA sender Max`
DATA text Picco utenti: 760 il 01.07.2013 22:46:06
DATA unread 0
DATA receipt 0
END
OBJECT Memo
ID 163
DATA owner crissy
DATA time 1373330646
DATA sender Max`
DATA text elenoire pesciolina tarallina eliminate dallo staff
DATA unread 0
DATA receipt 0
END
OBJECT Memo
ID 164
DATA owner crissy
DATA time 1376116652
DATA sender Max`
DATA text ciao tesò , se uno entra con nick papa_giovanni etc etc e non dice cagate offensive .... lasciamolo , se è simpatico e non offende la chiesa, se entra e dice, vi benedico ..etc etc..... va bene lo fa per gioco, cosa diversa invece se fa lo stupido... zam ... fart
DATA unread 0
DATA receipt 0
END
OBJECT Memo
ID 165
DATA owner crissy
DATA time 1376686766
DATA sender Max`
DATA text Ho fatto Chica` mod , manca spiegarle 4 cosine e addarla al forum, ciao kis
DATA unread 0
DATA receipt 0
END
OBJECT Memo
ID 166
DATA owner crissy
DATA time 1377461487
DATA sender Max`
DATA text se il server splitta mandatemi un mess , chiamatemi al volo, meglio se fai squillà kiss
DATA unread 0
DATA receipt 0
END
OBJECT Memo
ID 167
DATA owner crissy
DATA time 1377907727
DATA sender Max`
DATA text ho aggiunto questi nick alla lista akick perchè altrimenti non ne veniamo fuori *voglios*!*@* *dotato*!*@* *pompinara*!*@* *bocchinara*!*@* *cam*hot*!*@* *hot*cam*!*@*
DATA unread 0
DATA receipt 0
END
OBJECT Memo
ID 168
DATA owner crissy
DATA time 1377917307
DATA sender Max`
DATA text Ho aggiornato 4 post troverai aggiornato al 31.08.2013
DATA unread 0
DATA receipt 0
END
OBJECT Memo
ID 169
DATA owner crissy
DATA time 1387796293
DATA sender _AsSeNzIo_
DATA text ciaoooooooo amoreeeeeeee tanti auguriiiiiiii ti voglio bene ci sentiamo via maillllllllllllllllllllll ti adoro
DATA unread 0
DATA receipt 0


From anope log crissy nick expiration :

services.log.20140511:[May 11 17:43:22 2014] Expiring nickname crissy (group: crissy) (e-mail: kikkella@hotmail.it)
services.log.20140511:[May 11 17:43:22 2014] Changing crissy nickname group display to Frida

/cs access for #elite

[22:48:57] -ChanServ- Lista di accesso di #elite:
[22:48:57] -ChanServ- Numero Level Mask
[22:48:57] -ChanServ- 1 VOP Altair
[22:48:57] -ChanServ- 2 AOP angelobiondo
[22:48:57] -ChanServ- 3 VOP AnGeL|AwAy
[22:48:57] -ChanServ- 4 VOP Aquila_
[22:48:57] -ChanServ- 5 SOP BrAvEhEaRt
[22:48:57] -ChanServ- 6 VOP crissy
[22:48:57] -ChanServ- 7 HOP feddik
[22:48:57] -ChanServ- 8 VOP MarekIaro
[22:48:57] -ChanServ- 9 VOP miraggio
[22:48:57] -ChanServ- 10 VOP NoctiS
[22:48:57] -ChanServ- 11 VOP paprika
[22:48:57] -ChanServ- 12 AOP Pipps
[22:48:57] -ChanServ- 13 HOP santa
[22:48:57] -ChanServ- 14 SOP Simos
[22:48:57] -ChanServ- 15 VOP sky
[22:48:57] -ChanServ- 16 VOP UaN
[22:48:57] -ChanServ- 17 VOP Vania
[22:48:57] -ChanServ- Fine della lista di accesso.


/ns info for crissy

[22:49:36] -NickServ- il nickname crissy non è registrato.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1585 [Anope Development (1.9.x series)] Nickserv major N/A 2014-04-12 03:22 2014-05-15 00:19
Reporter: waser Platform:  
Assigned To: Adam OS:  
Priority: high OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: When nick in a group expired, did not change access masks to display nickname.
Description: When a nick expires in a group, the access mask on channels which that nick had access to do not change to the main display nick.
Tags:
Steps To Reproduce: 1-Register a nick (0000001)
2-Group it to another nick (0000002)
3-Give access to nick 0000002 to a channel
4-Let nick 0000002 expire

Result: Channel access is still existing, but as nick 0000002 (which is not registered anymore), it does not change all access masks of nick 0000002 on all channels to nick 0000001
Additional Information: I assume that someone can register nick 0000002 again and gain access to the channels nick 0000002 used to have access to.
Attached Files:
Notes
(0006648)
Adam   
2014-05-15 00:18   
Fixed in df321a118e7dd44dcd3a389f8ee75e9ff915b55e
(0006617)
Adam   
2014-04-12 09:22   
It sounds to me like you are adding the nick by mask and not by account (eg Adam!*@* and not Adam). This is the intentional behavior.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1594 [Anope Stable (2.0.x series)] General minor always 2014-05-01 05:35 2014-05-14 04:10
Reporter: Humanoid Platform:  
Assigned To: Adam OS: Debian  
Priority: normal OS Version: 6  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Web Panel accepts invalid syntax for setting channel mode, then fails to remove
Description: Mask input was "+T" without the special characters !*@
Mode +b +T!*@* was set, but it is now unable to be removed from the web panel.

<%ChanServ> OVERRIDE: Humanoid used chanserv/mode on #staff to set +b +T
* FearlessLeader sets mode: +b +T!*@*
<%ChanServ> OVERRIDE: Humanoid used chanserv/mode on #staff to set -b T

After removing the ban manually, the mask remains in the web panel ban list and still cannot be deleted.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006647)
Adam   
2014-05-14 04:10   
Thanks, should be fixed in 63b02b8c97e73d5a1fc7005e9693a954179ded0d
(0006635)
Humanoid   
2014-05-01 19:34   
Logged out and back in, and the ban no longer shows in the web panel.
Perhaps you could still take a look at resolving input syntax and deletion.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1595 [Anope Development (1.9.x series)] Nickserv feature N/A 2014-05-01 20:34 2014-05-02 02:05
Reporter: Aubrey Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Hide SUSPEND reason from non-opers
Description: NickServ/ChanServ should have a config option to allow the hiding of the suspension reason, or at the least the hiding of the expiry date and the suspending oper's name from non-opers.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006637)
Adam   
2014-05-02 02:05   
Added in 1f2c385bb9b7a78094024d226440a2ec4cfb6b80

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1586 [Anope Development (1.9.x series)] Other major always 2014-04-20 14:31 2014-05-01 23:39
Reporter: ObiWan Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: m_ldap_authentication - Password not stored correctly in directory
Description: When using the m_ldap_authentication and allowing registration via this module the password doesn't seem to be stored correctly inside the directory.

Afaik na->nc->pass contains the already encrypted password. When storing it into the directory it is necessary to tell it which hashing has been used otherwise the directory server uses his default encryption.

In addition to this you can't just store any md5 hash into the directory. You have to encode it base64 and pack it with H*. (At least in PHP). Here is an example from PHP:

$LDAPPassword = '{md5}' . base64_encode(pack('H*', md5($Password)));

Currently if I register an account with nickserv I won't be able to authenticate against it using the information stored on the directory server.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006636)
Adam   
2014-05-01 23:39   
Merged
(0006634)
ObiWan   
2014-04-27 14:16   
Works. Thanks very much :)
(0006633)
ObiWan   
2014-04-27 14:03   
Yes. LDAP an take an unencrypted password and encrypt it by its self.

I'll try the patch today.
(0006628)
Adam   
2014-04-26 23:06   
Try https://github.com/Adam-/anope/compare/2.0%2Bldapassword.diff
(0006627)
Adam   
2014-04-26 22:59   
I can make this send the password to LDAP unencrypted. Can LDAP take that and then encrypt it?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1593 [Anope Stable (2.0.x series)] General minor always 2014-04-26 23:13 2014-04-27 03:07
Reporter: CMF2000 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Module database (module_<modname>.db) won't loaded
Description: I'm using db_flatfile and I want to save the data of my module in a extra db (module_<modname>.db). This works very well till you restart the services. As far I can see there is nothing in the source of db_flatfile that loads a module database. Is this a bug or is it generally on my own to load the module db?

At the moment I use anope.db to save and load the module data.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006632)
CMF2000   
2014-04-27 03:07   
Sure. I don't know every piece of anope source code and without a documentation it's not so easy.
(0006630)
Adam   
2014-04-26 23:35   
You're probably doing it wrong. You shouldn't generally file bugs against us for your code not working unless you can prove there is something incorrect with db_flatfile. Instead you should come to #anope-devel and ask for help with your module.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1584 [Anope Development (1.9.x series)] Botserv minor always 2014-04-06 01:08 2014-04-26 22:45
Reporter: CMF2000 Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: When we are destroying a bot, OnUserQuit is never called
Description: But many modules like irc2sql are only using OnUserQuit to detect disconnects.
In this case, if you unassign a bot then irc2sql won't delete the user entry in the sql database.

I know, the other option is to use OnPreUserLogoff instead of OnUserQuit.
Tags:
Steps To Reproduce:
Additional Information: A possible fix:

*** bots.cpp.old 2014-04-06 00:01:20.000000000 +0200
--- bots.cpp 2014-04-06 00:01:56.000000000 +0200
***************
*** 56,59 ****
--- 56,60 ----
        {
                IRCD->SendQuit(this, "");
+ FOREACH_MOD(OnUserQuit, (this, ""));
                this->introduced = false;
                XLine x(this->nick);
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1589 [Anope Stable (2.0.x series)] General minor always 2014-04-26 21:14 2014-04-26 22:32
Reporter: CMF2000 Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Juped server won't be deleted on squit
Description: Debug log:

Received: :CMF2000 SQUIT test.example.net :CMF2000
unexpected non-server source CMF2000 for SQUIT


IRCd is unrealircd and without the flag IRCDMESSAGE_REQUIRE_SERVER for squit in messages.h it works fine.
Tags:
Steps To Reproduce: 1. Jupe a server
2. Use squit on the juped server
3. Jupe the same server again and operserv says that the server already exists
Additional Information:
Attached Files:
Notes
(0006623)
Adam   
2014-04-26 22:32   
fixed

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1590 [Anope Stable (2.0.x series)] General minor always 2014-04-26 21:25 2014-04-26 22:32
Reporter: CMF2000 Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Missing translation in ns_group
Description: --- ns_group.cpp.old 2014-04-12 19:03:10.000000000 +0200
+++ ns_group.cpp 2014-04-12 19:36:55.000000000 +0200
@@ -321,7 +321,7 @@

                        Anope::string expires;
                        if (na2->HasExt("NS_NO_EXPIRE"))
- expires = "Does not expire";
+ expires = Language::Translate(source.GetAccount(), NO_EXPIRE);
                        else if (!nickserv_expire || Anope::NoExpire)
                                ;
                        else if (na2->nc->HasExt("UNCONFIRMED") && unconfirmed_expire)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006622)
Adam   
2014-04-26 22:32   
fixed

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1592 [Anope Stable (2.0.x series)] General feature N/A 2014-04-26 22:27 2014-04-26 22:27
Reporter: CMF2000 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add MIME to email header
Description: Emails including non-US-ASCII characters (8-bit) are displayed with wrong encoding when your email client has set a different default encoding. Using MIME with quoted-printable helps to send 8-bit characters in a 7-bit encoded email.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: mail.cpp.patch (483 bytes) 2014-04-26 22:27
https://bugs.anope.org/file_download.php?file_id=348&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1587 [Anope Stable (2.0.x series)] General minor have not tried 2014-04-22 00:12 2014-04-24 06:26
Reporter: xClone84 Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Changing a BotServ bot causes it to not come back
Description: Changing a BotServ bot via "/msg BotServ BOT CHANGE" will cause the bot to leave the channel, say it is in that channel but not come back on reload. Only a restart.
Tags:
Steps To Reproduce: Add a BotServ bot, change a setting on it. It will then quit with the message "Quit: Be right back" and not come back unless services restart.
Additional Information:
Attached Files: bs_bot.patch (703 bytes) 2014-04-23 16:14
https://bugs.anope.org/file_download.php?file_id=346&type=bug
Notes
(0006619)
Adam   
2014-04-24 06:26   
Thanks, fixed in d52cc7bcbcf9b99a58eedc823418a91f85e8cab9
(0006618)
CMF2000   
2014-04-23 16:13   
(Last edited: 2014-04-23 16:54)
I can confirm this bug. The bot stays internally on the channel and thats the reason why he doesn't join the channel again.
I've made a patch for this issue.

Maybe it's not necessary to use Channel::DeleteUser() and better to join the bot with IRCDProto::SendJoin() instead of BotInfo::Join(). But I think to delete the bot from the channel is more safer.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1583 [Anope Development (1.9.x series)] Botserv major random 2014-03-11 00:52 2014-03-15 04:17
Reporter: Techman Platform: Linux  
Assigned To: Yoerger OS: Ubuntu Server  
Priority: normal OS Version: 12.04 LTS x86_64  
Status: resolved Product Version:  
Product Build: Resolution: suspended  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: After latest hs_group sync git update, some BotServ bots in some channels are not getting their configured prefix modes
Description: This is rather weird, but for some reason when some BotServ bots rejoined channels after an /os restart without getting their channel operator status (this is what I configured them to get).
Tags:
Steps To Reproduce: 1) Update to git commit ca6b3723a9 ( http://git.io/97Ebsg )
2) Restart services
3) For some reason botserv bots in some channels didn't get their channel op status
Additional Information: Besides not getting their +o, the bots function just fine. They can still kick, ban, etc and give modes like normal. They are not opped though. I restarted services twice and this happened, so I am not sure if this is solid or just randomly happening.

Tested on InspIRCd 2.0.15 (with m_servprotect loaded)

https://www.irccloud.com/pastebin/D4DH5xgv

Paste will expire in a few days.
Attached Files:
Notes
(0006616)
Adam   
2014-03-15 04:17   
Fixed in ef9729fb02dd3e44f59b447b567cdeb450690344
(0006615)
Yoerger   
2014-03-14 08:41   
I'll just suspend it for now. Techman, The last thing we need is banter on the bug tracker. (Alliteration intended).
(0006614)
Techman   
2014-03-14 04:03   
1) I will not flatly link debug logs because of the nature of them being very sensitive, even with user hosts and IPs stripped out. Doesn't matter anyways, because reversing that commit worked.

2) If you really think I made all of this up, please go ask ANY of my users about the hell I had trying to figure what the hell happened. The very reason why I was a bit impatient was because my users were freaking out about "Why is ChanServ not op???". In the mean time, I manually opped bots in affected channels myself.

You are welcome to close this issue now, because I don't see a close button anywhere. That commit you pointed to above is the one that broke it :).

Glad to hear that a "final" is coming out soon. Time for Anope to shine.
(0006613)
Adam   
2014-03-13 00:12   
Since you seem incapable of providing logs this really is not a priority for me at the moment. No you may not "PM me them", put them here like normal people do.

Robby picked out a commit he thought was related, which is 59693624250eb411265844e42322c05d1825acf1.

I am still aware this bug exists, you do not have to "To Adam" me, it just makes you look impatient and childish. This is one of the reasons you remain banned most everywhere.

I already asked you once for debug logs of this bug, which you have yet to provide, so it seems I am actually waiting for you.

I am also aware of your history of reporting "issues" (most of which are not real) and then flatly refuse to provide any sort of debug information when asked, simply stating it is wrong. This is why this low priority to me, as I feel I should not have to waste my time trying to reproduce a problem because you are too stubborn to provide logs. I'll try and get it in this week before the final.
(0006612)
Yoerger   
2014-03-12 23:48   
..
(0006611)
Techman   
2014-03-12 23:12   
Okay, wanted to add some notes to this issue:

1) I downloaded the official rc4 build on my local testnet and ported a fresh updated copy of my services db to it and started it. Results: BotServ bots were opping themselves like normal in the affected channels. This confirms that some update AFTER the rc4 build broke it.

2) The channels affected seem to be "old" ones -- ones that were imported from my old Anope 1.8 setup. Newly registered channels are not affected by this bug. While I don't think this is relevant, I am just dropping things I have noticed.

----

I honestly think something with how channel modes are set is the root of this issue. I have always-lower-ts turned on if this helps. I would point fingers specifically at commits that changed chanserv or how channel modes are handled.

To Adam: Still waiting for your reply.
(0006609)
Techman   
2014-03-11 12:10   
Is there a way I can PM you logs?

I ran services with -support before, but there was so many lines that it exceeded my set scrollback limit. Does running services from start in debug mode and collecting the log data sufficient enough?

I also did strip out user hosts and IP addresses and replaced them with <host> and <IP>, respectively.
(0006608)
Adam   
2014-03-11 04:22   
Run with ./services -support and pastebin evreything when reproducing this behavior

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1581 [Anope Development (1.9.x series)] Nickserv trivial always 2014-03-05 04:56 2014-03-10 13:33
Reporter: Techman Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: NickServ's noticeunregister still sends the message even after a successful SASL auth
Description: (read title)
Tags:
Steps To Reproduce: 1) Register a nick (make sure noticeunregister is on ofc)
2) Reconnect and identify to your account
3) Notice you don't get the notification because you logged in via SASL and you owned the nick and got +r
4) Reconnect as a different nick and auth as yourself
5) Get logged in
6) See the unregistered notification
Additional Information: Although technically when you use SASL to identify to a nick you don't own, I don't think this notice is necessary because a user would be logged in at this point....
Attached Files:
Notes
(0006607)
Adam   
2014-03-10 13:33   
Fixed in 860deb14ce6b6ccda12d8d842004c8b93d843711

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1565 [Anope Development (1.9.x series)] Ext DB Support minor sometimes 2014-01-30 00:16 2014-03-09 06:34
Reporter: waser Platform:  
Assigned To: DukePyrolator OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 1.9.x-GIT  
    Target Version:  
Summary: SQL table chan gives negative number of users
Description: In some cases, the stattistics on channels gives a negative number of users.
Tags:
Steps To Reproduce: It seemed to happen after an attack over a network, so I assume it was the massive join/part to be the problem.
Additional Information: using anope 2 rc1
Attached Files:
Notes
(0006605)
DukePyrolator   
2014-03-09 06:34   
bug confirmed, but I was unable to debug it.

whilst looking at it I decided to remove the currentusers field.
keeping this field updated eats too many resources.
On a big network this field has to be updated several thousand times a day,
but you need it only a few times when someone want to see the stats on a website.

if you need the currentusers of a channel you can always use:

SELECT count(i.chanid) AS currentusers
   FROM anope_chan AS c, anope_ison AS i
   WHERE i.chanid=c.chanid and c.channel="#name";

or for the top10 channels:

SELECT c.channel, count(i.chanid) AS currentusers
   FROM anope_chan AS c, anope_ison AS i
   WHERE i.chanid=c.chanid
   GROUP BY c.chanid
   ORDER BY currentusers DESC
   LIMIT 10;

"fixed" in https://github.com/anope/anope/commit/4b5ce8a9728db477b75766a60aec48981eff0750

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1572 [Anope Development (1.9.x series)] Modules System feature always 2014-02-17 01:26 2014-02-28 04:27
Reporter: NoMiaus Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: db_old doesn't load os_info.db
Description: Oper information from os_info.db isn't loaded using db_old.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006593)
NoMiaus   
2014-02-17 15:01   
Well, I just wouldn't like lose the os_info saved with 1.8 when using Anope 2.
(0006592)
Adam   
2014-02-17 02:14   
I'm not sure if we want to do this. os_info isn't actually "core" on 1.8, it's extras. Also, the 2.0 os_info does not have a public API to add info, the thinking was if you wanted to add "oper info" (as a module), you would simply hook to the OnNick/ChanInfo events and simply display it there.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1579 [Anope Development (1.9.x series)] Nickserv feature N/A 2014-02-27 09:14 2014-02-27 11:50
Reporter: static Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Have an option to require authentication of emails when providing an email to register is not required.
Description: You can turn on requiring email authentication when an email is required to register, but it's not currently possible to require an email to be authenticated if an email is optional to register.

I see this as semi-necessary to prevent people from registering with an email they don't own, and having services inadvertently send spam. While requiring an email to register can prevent this, it does restrict the options available to a network operator to a degree.

If possible, I think this would be a good feature to implement.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006601)
Adam   
2014-02-27 11:50   
Done in d24fb039172786e0fb3e3164140b337c85cdeeca

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1578 [Anope Development (1.9.x series)] Other major always 2014-02-26 16:45 2014-02-27 02:28
Reporter: static Platform: Linux  
Assigned To: Adam OS: Debian  
Priority: normal OS Version: Stable (wheezy)  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Root privileges being dropped before binding to privileged port with DNS module
Description: Having anope bind to a privileged port (53) with the DNS module in conjunction with running as root and using 'user'/'group' doesn't allow anope to correctly bind to the privileged port. It seems to drop privileges before binding.

Log file reports:
Unable to bind dns to [ADDRESS]:53: Unable to bind to address: Permission denied
Tags:
Steps To Reproduce: Set anope to bind to a privileged port in the DNS module.
Set anope to change to an unprivileged user using 'user'/'group'.
Run anope as root.
Additional Information:
Attached Files:
Notes
(0006600)
Adam   
2014-02-27 02:28   
Fixed in e2d456d4ce69a9f2d942f5f3c736827c32421960

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1577 [Anope Development (1.9.x series)] Other major always 2014-02-26 14:54 2014-02-27 02:28
Reporter: static Platform: Linux  
Assigned To: Adam OS: Debian  
Priority: normal OS Version: stable (wheezy)  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Config parser chokes on c-style comments at the end of lines containing values
Description: Adding a c-style comment to the end of a config line containing a value will cause anope to choke on the line, and fail to start, with the message "unexpected word", the provided line in the error being the next line containing a config value.

Examples provided in reproduction steps.
Tags:
Steps To Reproduce: Add a c-style comment to the end of any config line that has a value:

add_to_akill = no /* this will break anope */
refresh = 600 /* this too will break anope */
anope_is = "very unhappy with this" /* anope won't start with this */

add_to_akill = no # this will not break anope

section /* this won't break anope */
{
    this = "value"
    stuff = yes
    five = 5
}

foo = "i am the line that's breaking things" /* this comment right here is trouble */
bar = "but i'm the line anope will report an error on" # should've used this style of comment!
Additional Information:
Attached Files:
Notes
(0006599)
Adam   
2014-02-27 02:28   
Fixed in 8f3bd314ed3ce371d2f40687920246e6944376f6

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1574 [Anope Development (1.9.x series)] Other minor sometimes 2014-02-18 00:54 2014-02-24 07:09
Reporter: NoMiaus Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: 'Anope is not currently running' on Anope Remote Control (command line)
Description: When Anope is running..
ircd@NoMiaus:~/services/bin$ ./anoperc restart
Restarting Anope
Anope 2.0.0-rc3, build 0000002, compiled 17:03:14 Feb 17 2014
Using configuration file conf/services.conf
Attempting to connect to uplink 0000001 127.0.0.1 (127.0.0.1), port 59999
Successfully connected to uplink 0000001 127.0.0.1:59999
Successfully linked, launching into background...
ircd@NoMiaus:~/services/bin$ ./anoperc restart
Warning: Anope is not currently running
ircd@NoMiaus:~/services/bin$ ./anoperc stop
Warning: Anope is not currently running
ircd@NoMiaus:~/services/bin$ ./anoperc rehash
Warning: Anope is not currently running
ircd@NoMiaus:~/services/bin$ ./anoperc start
Starting Anope
Anope 2.0.0-rc3, build 0000002, compiled 17:03:14 Feb 17 2014
Using configuration file conf/services.conf
Attempting to connect to uplink 0000001 127.0.0.1 (127.0.0.1), port 59999
Successfully connected to uplink 0000001 127.0.0.1:59999
ERROR: Server services.server.net already exists from services.server.net
ERROR: Closing Link: [127.0.0.1] (Server Exists)

It says it's not running when it's running and services are linked to the server. I can't rehash, restart or stop using the command line controls. It happens only sometimes.. I don't know if someone will be able to reproduce it..
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006598)
Adam   
2014-02-24 07:09   
Noone here can reproduce this, but it might be fixed in 4ac3ade126728e4a4c448c7a14b5f19f90f18805.
(0006597)
JadennH   
2014-02-24 03:04   
I can confirm this issue. Anope 2.0.0-rc3 running on Debian 7. This happens 100% of the time, I have to SIGKILL the process whenever I need to restart.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1576 [Anope Development (1.9.x series)] Modules System minor always 2014-02-18 18:13 2014-02-18 20:03
Reporter: NoMiaus Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Channel is 'Forbidden' on CS INFO command using db_old
Description: After convert the databases to the new format using db_old there are some channels that appear as forbidden on /cs info #channel when they shouldn't be forbidden. Anyway users can join and configs are saved.

## Before ##
ChanServ Information for channel #eMule-Italian:
ChanServ Founder: emulechans2
ChanServ Description: eMule-Support-Channel
ChanServ Registered: Oct 04 11:55:02 2008 CEST
ChanServ Last used: Feb 18 17:11:07 2014 CET

## After ##
ChanServ Channel #eMule-Italian is forbidden by crazy: repeated takeovers
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006596)
Adam   
2014-02-18 20:03   
This works okay, but the old system could treat channels with wildcards in them (like #*) as non-wildcard, when the new system always does, which was the issue here. I've made db_old not import forbids that contain wildcard characters.
(0006595)
Adam   
2014-02-18 19:20   
Get /os forbid list and remove the one matching this channel.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1575 [Anope Development (1.9.x series)] Other minor always 2014-02-18 17:52 2014-02-18 20:02
Reporter: CMF2000 Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Typo in db_old: CS_NO_EXPIRE isn't set correctly
Description: --- db_old.cpp.old 2014-02-18 16:22:40.000000000 +0100
+++ db_old.cpp 2014-02-18 16:23:12.000000000 +0100
@@ -785,3 +785,3 @@
                        if (tmpu32 & OLD_CI_NO_EXPIRE)
- ci->Extend<bool>("CI_NO_EXPIRE");
+ ci->Extend<bool>("CS_NO_EXPIRE");
                        if (tmpu32 & OLD_CI_MEMO_HARDMAX)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1573 [Anope Development (1.9.x series)] Operserv minor always 2014-02-17 16:44 2014-02-17 20:54
Reporter: CMF2000 Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: OperServ (os_session) doesn't find sessions if session_(ipv4|ipv6)_cidr is set in config
Description: Sessions aren't found when session_ipv4_cidr < 32 or session_ipv6_cidr < 128 is set.
The old sessions won't be deleted and you get killed by operserv because of reaching the sessionlimit.
Tags:
Steps To Reproduce: 1. set session_ipv4_cidr = 24
2. connect to your ircd
3. /msg operserv session view [your ip] <= it says not found
4. reconnect to ircd
5. /msg operserv session list 2 <= the old session is still there


It's also related to IPv6 clients: step 1. session_ipv6_cidr = 64
Additional Information: Maybe there is something wrong with cidr::hash in sockets.cpp that sessions aren't found in the SessionMap (unordered_map)?
Attached Files:
Notes
(0006594)
Adam   
2014-02-17 20:54   
Good find, fixed in 707494481046d330ee5b2eb641b67cb4fc96f6ca

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1571 [Anope Development (1.9.x series)] Modules System feature always 2014-02-16 19:25 2014-02-16 23:07
Reporter: NoMiaus Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Incorrect format with 'Forbidden' nicknames/channels using db_old
Description: ## Old format ##
NickServ  Nick Yum has been forbidden by TamOShanter:
NickServ  Network

## New format ##
NickServ Yum is Network
NickServ Last seen address: TamOShanter
NickServ Registered: Dec 31 19:00:00 1969 EST (44 years, 57 days, 11 hours, 36 minutes ago)
NickServ Last seen: Dec 31 19:00:00 1969 EST (44 years, 57 days, 11 hours, 36 minutes ago)
NickServ Expires: Jan 30 19:00:00 1970 EST (44 years, 27 days, 11 hours, 36 minutes ago)

## Old format ##
ChanServ Channel #fuck has been forbidden by kayfam:
ChanServ no reason needed

## New format ##
ChanServ Information for channel #fuck:
ChanServ Registered: Sep 04 14:07:31 2007 EDT (6 years, 166 days, 23 hours, 15 minutes ago)
ChanServ Last used: Dec 31 19:00:00 1969 EST (44 years, 57 days, 17 hours, 23 minutes ago)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006591)
Adam   
2014-02-16 23:07   
Fixed in ab1e0ebfb3ae7bb66c30fb10dc993ab1b5175664

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1564 [Anope Development (1.9.x series)] Other feature N/A 2014-01-27 13:37 2014-02-15 02:55
Reporter: Techman Platform: Linux  
Assigned To: Adam OS: Ubuntu Server  
Priority: normal OS Version: 12.04 LTS x86_64  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add support for DH-AES and DH-BLOWFISH mechanisms (documentation included)
Description: Now that grawity has graciously documented both of these mechanisms, I hope that Anope will move to support them eventually.

https://github.com/atheme/ircv3-specifications/pull/37

I know that this won't make it into the 2.0.0 release but I hope it makes it into the next one.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1562 [Anope Development (1.9.x series)] Chanserv feature N/A 2014-01-18 00:16 2014-02-08 03:32
Reporter: Techman Platform: Linux  
Assigned To: OS: Ubuntu Server  
Priority: normal OS Version: 12.04 LTS x86_64  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add numeric 328 (RPL_CHANNEL_URL) support to ChanServ
Description: Numeric 328, channel URLs, have been sent via Atheme for a long time now, and I'd like to see Anope send channel URLs as well.

The way numeric 328 in relation to services is pretty simple. If a channel has a URL set via ChanServ, when a user joins, send the numeric to the client. On InspIRCd, you must PUSH the numeric.

Some optional configuration/defaults/wanted extras for this module is this:
1) Do not send channel urls to all clients on netbursts (ircd_chanurl does this and it is very annoying)
2) Do not send channel urls to all clients when the module is (re)loaded.
3) Perhaps have a way to track netsplits or something? If a user has joined the channel already and then a netsplit occurs, keep track of that so when the servers re-link, do not push the numeric to those clients. I don't know how to make this work, but if you can do so, I would at least add some kind of setting for it.
4) (if anyone has other suggestions on features put them in the comments)
Tags:
Steps To Reproduce: N/A
Additional Information: This is a feature I want in Anope 2.0 because of the ircd_chanurl module: https://modules.anope.org/index.php?page=view&id=125

I run a patched version for use on InspIRCd-2.0
Attached Files:
Notes
(0006589)
Techman   
2014-02-08 03:32   
No longer needed for 2.0 b/c of this: https://modules.anope.org/index.php?page=view&id=263

If such a module would ever make it to the set of bundled in modules, that would be nice. For now, I'll just close this.
(0006581)
Techman   
2014-01-18 22:33   
(Last edited: 2014-01-20 07:11)
Thanks Adam. When is the next RC coming out btw?

(0006580)
Adam   
2014-01-18 01:45   
This could be in 2.0.1. No new features are going into 2.0.0 as we are in the RC stages.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1569 [Anope Development (1.9.x series)] Botserv feature N/A 2014-02-01 22:15 2014-02-01 22:15
Reporter: Techman Platform: Linux  
Assigned To: OS: Ubuntu Server  
Priority: normal OS Version: 12.04 LTS x86_64  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add !set fantasy command to Anope 2.0
Description: Add a sane (working) !set fantasy command for Anope 2.0
Tags:
Steps To Reproduce:
Additional Information: Sticking this in Anope 2.0.1 is fine.
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1566 [Anope Development (1.9.x series)] Nickserv minor always 2014-01-30 18:46 2014-02-01 21:42
Reporter: Aubrey Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: NickServ list SUSPENDED does not work
Description: Sending NickServ LIST * SUSPENDED or LIST *!*@* SUSPENDED does not return the list of suspended nicknames. Using wildcards with literals works (if I suspend Aubrey I can list Aub* suspended and still get the name back) but if it is solely wildcards it does not work as intended, seemingly returning all registered nicknames.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006588)
Adam   
2014-02-01 21:42   
Fixed in f94cb7fb113d716257c6361a4eff8268fa111d98
(0006585)
Aubrey   
2014-01-30 18:47   
This is using rc3 by the way.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1568 [Anope Development (1.9.x series)] Nickserv minor always 2014-01-31 06:06 2014-02-01 21:14
Reporter: KindOne Platform:  
Assigned To: Adam OS:  
Priority: low OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Can ddd invalid entried into nickserv/ajoin 2.0.0-rc3
Description: NickServ allows people to add invalid entries into ajoin.
Tags:
Steps To Reproduce: <KindOne> ajoin add #cake,#asdf
<NickServ> #cake,#asdf added to KindOne's auto join list.
<KindOne> ajoin add #cake,#asdf,what
<NickServ> #cake,#asdf,what added to KindOne's auto join list.
<KindOne> ajoin add #cake,#asdf,what,\r\n ,cake-password,asdf-password
<NickServ> #cake,#asdf,what,\r\n added to KindOne's auto join list.
<KindOne> ajoin add #Foobar
<NickServ> #Foobar added to KindOne's auto join list.
<KindOne> ajoin list
<NickServ> KindOne's auto join list:
<NickServ> Number Channel Key
<NickServ> 1 #cake,#asdf
<NickServ> 2 #cake,#asdf,what
<NickServ> 3 #cake,#asdf,what,\r\n ,cake-password,asdf-password
<NickServ> 4 #Foobar
Additional Information:
Attached Files:
Notes
(0006587)
Adam   
2014-02-01 21:14   
This has been fixed in 211a94421052bdb0ea09a146d6153ceb092b7424

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1567 [Anope Development (1.9.x series)] Nickserv tweak always 2014-01-31 05:12 2014-01-31 12:44
Reporter: Techman Platform: Linux  
Assigned To: Adam OS: Ubuntu Server  
Priority: high OS Version: 12.04 LTS x86_64  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: SASL auth allows you to use a GROUPED nick as your account name
Description: Anope 2.0 allows you to authenticate as a grouped nickname in your account. While this by itself isn't much of an issue (I think this does break SASL spec though), the issue here is that you are logged in as your grouped nick, not your account name like you should.

This, of course, opens a big door for ban evasion based on account names, as well as breaking bots that would accept logged in WHOIS fields instead of having its own username+password system.
Tags:
Steps To Reproduce: 1) Install InspIRCd 2.0.15 and Anope 2.0-rc3
2) Set it up
3) Register an account & make sure you can authenticate to it via SASL
4) Group a nick into your account
5) Reconnect with your client. MAKE SURE you change the account name for SASL from your account name, to your grouped nick
6) If your passwords match, you will be logged in as your grouped nick
7) As long as you don't /nick to your account name, you can ban evade R: bans (or other account name based bans on other IRCds), as well as break bots that rely on account names.
Additional Information: Tested on:
InspIRCd 2.0.15 + Anope 2.0-rc3
Attached Files:
Notes
(0006586)
Adam   
2014-01-31 12:44   
Fixed in 405b41ec87d5068821ce065f1d3def307184051e

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1563 [Anope Development (1.9.x series)] Other crash have not tried 2014-01-25 14:05 2014-01-26 01:37
Reporter: Myster Platform:  
Assigned To: Adam OS:  
Priority: immediate OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash setname
Description: When we use the command /setname services disconnects
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006584)
Adam   
2014-01-26 01:37   
Thanks, fixed in 01780c9e7a92c6fc3c9c3a4733fad1808a3e462f
(0006583)
DukePyrolator   
2014-01-25 14:21   
what ircd are you using?

can you provide a backtrace?
(1) From the services install directory use gdb ./bin/services
(2) Do: r -support
(3) Upon crash, do: bt full
(4) Pastebin everything from step 1 to step 3.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1561 [Anope Development (1.9.x series)] Nickserv feature N/A 2014-01-16 21:56 2014-01-16 21:56
Reporter: Rylee Platform: n/a  
Assigned To: OS: n/a  
Priority: normal OS Version: n/a  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add a unique identifier to NS ACC
Description: Relevant logs from irc.anope.org/#anope:

12:34:47 Rylai | I was looking for opinions on adding EUID to /NS ACC output.
12:34:50 sp4rd0se | or go to the forum :)
12:35:12 Rylai | As EUID is a more accurate/precise indicator of ownership of an account than accountname itself.
/* ... */
12:57:05 grawity | I don't think Anope even has entity IDs, Rylai
13:03:12 %Jobe | it does not
13:03:19 %Jobe | as far as I know
13:06:14 grawity | my anope.db agrees
13:07:48 --> | Demon (Demon@teranova-vtaqiv.de) has joined #anope
13:11:04 %Attila | Rylai: can you elaborate on what difference would that make?
13:11:36 %Attila | accounts are unique, so i dont see how can there be a more unique indicator to something than an
                          | already unique string
13:12:06 %Attila | is it about an account getting dropped and then re-registered?
13:14:13 Rylai | yes, precisely that
13:14:56 %Attila | would be easy to add such a thing
13:15:21 %Jobe | Rylai's clearly been reading my mind
13:15:53 %Jobe | I've been thinking about a feature like that for that purpose in another services package I work with
13:18:46 Rylai | heh, nope, i'm just a bot dev in my spare time
13:19:23 Rylai | so something like this, to allow users to use their services account instead of registering for yet
                          | another account in my bot, would be greatly preferable
13:20:32 %Jobe | ultimately an account name should be analogous to a DNS host name
13:20:38 %Jobe | an alias to a unique ID
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1560 [Anope Development (1.9.x series)] Other trivial always 2014-01-15 04:17 2014-01-16 00:00
Reporter: bush Platform: Linux  
Assigned To: Adam OS: Debian  
Priority: low OS Version: 7  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: webcpanel modes
Description: webcpanel modes shows no modes and cannot set modes on inspircd 2.0
Tags:
Steps To Reproduce: 1. logon to webcpanel
2. select chanserv
3. select channel
4. select modes
5. mode list is empty / cannot set modes
Additional Information: using latest git code as of 15.01.14
Attached Files: Screenshot from 2014-01-15 13:16:47.png (117,040 bytes) 2014-01-15 04:17
https://bugs.anope.org/file_download.php?file_id=345&type=bug
png
Notes
(0006579)
Adam   
2014-01-16 00:00   
fixed in d27594f8a61a7a3eae74a56983b2957233a0b64d

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1557 [Anope Development (1.9.x series)] Chanserv minor have not tried 2013-12-28 10:53 2013-12-28 16:39
Reporter: Mike9383 Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ChanServ Mode Lock Does Not Correctly Handle +G
Description: On InspIRCd-2.0 with Anope 2.0rc1 ChanServ MODE LOCK does not correctly handle +G. When it's added as a mode, services does not apply that mode to the channel. MODE LIST shows +g instead of +G as well.

Here is output from the console: http://pastebin.anope.org/index.php?page=viewpaste&id=88c3270c4b

Tags:
Steps To Reproduce: /cs MODE #channel LOCK ADD +G

(notice #channel does not have +G forced onto it)

/cs MODE #channel LOCK LIST

(notice +G is not listed, and instead +g is)
Additional Information: InspIRCd-2.0 with Anope 2.0rc1
Attached Files:
Notes
(0006567)
Adam   
2013-12-28 16:39   
fixed in 3d12752655405ae75265622cbec565f9efa23be3

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1556 [Anope Development (1.9.x series)] Other minor always 2013-12-27 22:39 2013-12-28 00:21
Reporter: Humanoid Platform:  
Assigned To: Adam OS: Debian  
Priority: normal OS Version: 6  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Exceptions (~) and wildcards (*) for oper types in services.conf. Also, OperServ FORBID notice misprint.
Description: First, sorry for posting to 1.9. I didn't see a 2.0 selection. This report is in regard to 2.0.0-rc1.

I see that exceptions (~) are allowed in the logging configuration for services.conf. "
For example, "~operserv/akill operserv/*" would log all operserv messages except for operserv/akill."
This would be a great feature to have for opertypes as well. Some of our opers have access to everything except restart/shutdown/quit etc., so it is a bit tedious to enter all but those commands for their opertype block.

Regarding the FORBID misprint, which may already be known, this is the output after sending a forbid command:
"*** Global -- from OperServ: ADMIN: Humanoid!Humanoid@IP used FORBID to add a forbid on f-your-mom of type NICK
-OperServ- Added a forbid on f-your-mom of type Command to expire on never."
I am sure 'Command' should be "NICK|CHAN|EMAIL|REGISTER," respectively, as it is shown in the global notice.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006566)
Adam   
2013-12-28 00:21   
fixed & done

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1555 [Anope Development (1.9.x series)] Other minor have not tried 2013-12-26 12:26 2013-12-26 15:05
Reporter: Myster Platform: Anope-2.0  
Assigned To: OS: Debian  
Priority: high OS Version: 7  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Mémo
Description: When we send a memo about a show from the panel, one person can read the memo, the others will have a message saying that there is no memo
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006565)
Adam   
2013-12-26 15:05   
I sent a memo to a channel and confirmed that more than one person can read it... provide debug logs or more information.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1554 [Anope Development (1.9.x series)] Other minor always 2013-12-26 07:59 2013-12-26 15:02
Reporter: stmeter Platform:  
Assigned To: Adam OS: Ubuntu  
Priority: normal OS Version: 12.04  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Can't drop channel using web panel
Description: When attempting to drop a channel I'm a founder of using the web-panel, the page returns "You must enter the channel name twice as a confirmation that you wish to drop #channel."

There is only one text field so I assumed I would type "#channel#channel" or with a space in between. Both resulted in, "Invalid Confirmation."
Tags:
Steps To Reproduce: Self-explanatory.
Additional Information:
Attached Files:
Notes
(0006564)
Adam   
2013-12-26 15:02   
fixed in fc0e8264c0391edca9db85af64c33b6787b05c03

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1553 [Anope Development (1.9.x series)] Anope Languages block N/A 2013-12-25 13:19 2013-12-25 22:31
Reporter: chaz Platform:  
Assigned To: Adam OS:  
Priority: urgent OS Version:  
Status: resolved Product Version: 1.9.x-GIT  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Anope does not default to english on non english system locale
Description: An interesting issue arose in #anope today where a user who has a system using fr_FR.UTF-8 system locale in combination with our defaultlanguage commented out has a system in French contrary to the notes in example.conf suggesting this would be english.

Setting /ns set language en provides 'some' more english but not complete.

It seems unique to only impact systems using a non english locale (and probably systems which do not include any english locale alongside)

Clearly a serious issue that should be fixed prior to 2.0 release.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006563)
chaz   
2013-12-25 22:31   
Hi,

Thanks.

When the guy tested using "en" it still didn't work, it still used French for the majority of the text, of course we can't entirely be sure the testing was accurate.

Has this problem been reproduced on a non english locale and the fix of setting 'en' tested thoroughly? I offered on #anope to test this myself if necessary.

Thanks.
(0006562)
Adam   
2013-12-25 22:18   
I've updated the documents explaining what this directive does.
(0006561)
Myster   
2013-12-25 20:24   
Good evening

I am having the same problem. I cannot apply the French language.
(0006560)
Adam   
2013-12-25 15:22   
set options:defaultlanguage = "fr_FR.UTF-8" ?
(0006559)
chaz   
2013-12-25 13:21   
(Last edited: 2013-12-25 13:25)
[Dec 25 11:58:13.202341 2013] Debug: Anope 2.0.0-rc1 starting up (options: debug)
[Dec 25 11:58:13.202380 2013] Debug: Initializing Languages...
[Dec 25 11:58:13.202420 2013] Debug: Successfully bound anope to locale
[déc. 25 11:58:13.202794 2013] Debug: Found language ca_ES.UTF-8
[déc. 25 11:58:13.202950 2013] Debug: Found language de_DE.UTF-8



LANG=fr_FR.UTF-8
LANGUAGE=
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=fr_FR.UTF-8

Linux gecos.hifive.fr 2.6.32-5-xen-amd64 0000001 SMP Sun May 6 08:57:29 UTC 2012 x86_64 GNU/Linux


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1552 [Anope Development (1.9.x series)] MemoServ minor always 2013-12-19 21:43 2013-12-20 04:36
Reporter: romeo5k Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: memoserv not sending to all opers
Description:  * If set, Services will send a memo to all Services staff when a new vHost is requested.
     */
    memooper = yes
}
 But when someone request a new host "/hs request blah.blah.blah" its supposed to memo all opers. But only Services Root is getting the memo.
 i would think, anyone in /os oper list would get it
Tags:
Steps To Reproduce:  activate memooper = yes in hostserv.conf.
 request new host.
Additional Information:
Attached Files:
Notes
(0006558)
Adam   
2013-12-20 04:36   
fixed in ab6cd3b26caf127d1052e58e9f906d8ed5c3d986
(0006557)
Yoerger   
2013-12-19 22:48   
Tested this today. It does appear to be a bug.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1546 [Anope Stable (1.8.x series)] MemoServ crash always 2013-09-16 06:34 2013-09-19 02:10
Reporter: cards Platform: Linux  
Assigned To: Adam OS: CET 2012 i686 GNU/Linux  
Priority: normal OS Version: 2.6.32-11-pve  
Status: resolved Product Version: 1.8.8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MemoServ Delete Memos
Description: We have run into an issue on our Network where every time a user deletes their third Memo, Services Crash with the following.

[22:20] *** Global -- from services.420-hightimes.com: PANIC! buffer = :cards PRIVMSG memoserv@services.420-hightimes.com :del 1
 [22:20] *** LocOps -- Received SQUIT services.420-hightimes.com from services.420-hightimes.com[217.146.93.137] (Services terminating: Segmentation fault)

Steps to Reproduce:
Tags:
Steps To Reproduce: /ms del 1 (3 Times)
Additional Information: I'm told this started happening after a user used /hs request 3 times for the same host. Because of the nature of the issue, we have disabled MemoServ and HS_Request, but will enable if someone would like to test on our network irc.420-hightimes.com
Attached Files:
Notes
(0006522)
Adam   
2013-09-19 02:10   
This was due to not properly recompiling Anope after changing USE_MYSQL.
Padding has been added to the memo struct to fix this in the furture in 7a741b467c1e178ba721550ec62fecd2d4afbf90.
(0006521)
cards   
2013-09-18 23:40   
if you would like, log onto irc.420-hightimes.com and find me in #hightimes-lounge
(0006519)
Adam   
2013-09-18 23:36   
Is there any way I could get access to this machine to look at it closer?
(0006518)
cards   
2013-09-18 23:28   
New User CrashMe3
https://pastebin.anope.org/index.php?page=viewpaste&id=30b74dcb95
(0006517)
Adam   
2013-09-18 22:42   
Can you show the full log from when you register Crashme2?
(0006516)
cards   
2013-09-18 22:01   
(Last edited: 2013-09-18 22:02)
OS MODLIST (Note: We have used the same modules for over 2 years and this problem just started happening)
-[15:50] -OperServ- Module: cs_regonly [1.0.0] [3rd]
-[15:50] -OperServ- Module: cs_accessfounder [4.1] [3rd]
-[15:50] -OperServ- Module: cs_appendtopic [1.8.8 (3112)] [Supported]
-[15:50] -OperServ- Module: cs_enforce [1.8.8 (3112)] [Supported]
-[15:50] -OperServ- Module: enc_none [1.8.8 (3112)] [Encryption]
-[15:50] -OperServ- Module: ircd_tssync [1.0] [3rd]
-[15:50] -OperServ- Module: ns_maxemail [1.8.8 (3112)] [Supported]
-[15:50] -OperServ- Module: os_notinchanlist [2.4] [3rd]
-[15:50] -OperServ- Module: os_superadmin_pass [2.0.1] [3rd]
-[15:50] -OperServ- Module: os_info [1.8.8 (3112)] [Supported]
-[15:50] -OperServ- Module: unreal32 [1.8.8 (3112)] [Protocol]


Newly registered Nick CrashMe2 and sent 5 memos. On the second /ms del 1 under valgrind
https://pastebin.anope.org/index.php?page=viewpaste&id=9409cb91cd

(0006515)
Adam   
2013-09-17 07:27   
Can you run services under valgrind and reproduce the issue?

valgrind ./services -support

If you are able to reproduce it on a nickname that is newly registered that would be more helpful.
(0006514)
DukePyrolator   
2013-09-17 07:23   
I tried very hard but I can't reproduce this on my testnet.

Do you use any third party modules?
(if yes, please post the output of /operserv modlist)
(0006513)
cards   
2013-09-16 23:37   
We have MYSQL compiled in, but we do not use it (It is commented out).

I made it happen twice. First time I Sent myself 4 memo's from a nick grouped to the one I deleted them from.

https://pastebin.anope.org/index.php?page=viewpaste&id=9604061400
This one someone else sent me 4 memos and it crashed on /ms del 1 for the second time.
https://pastebin.anope.org/index.php?page=viewpaste&id=77974b82ca
(0006512)
DukePyrolator   
2013-09-16 08:07   
1. are you using a mysql database?

2. can you provide a backtrace?
(1) From the directory that you would do ./services from, do the following instead: gdb ./services
(2) Do: r -support
(3) Upon crash, do: bt full
(4) Pastebin everything from step 1 to step 3. (Alternatively, if that output is too long, just pastebin everything from when Anope crashed to the end of the output of bt full.)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1545 [Anope Stable (1.8.x series)] Modules tweak always 2013-08-16 06:12 2013-08-16 19:54
Reporter: meadows Platform: *NIX  
Assigned To: Adam OS: FreeBSD  
Priority: normal OS Version: 8.3  
Status: resolved Product Version: 1.8.8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Minor issue with HS REQUEST
Description: When HS REQUEST is used and the module is configured to send a memo to opers/host setters, that memo only contains the host portion of the request, not the vIdent. This means people have to use HS WAITING before approving a request if they want to be sure vIdents are in compliance with network rules as well. It would be very practical (and logical) to have the vIdent displayed in the memo; saves people an additional step.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006509)
Adam   
2013-08-16 19:54   
thanks, fixed in eab5abb351dd3372953bd9059e2b56fde245bf05

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1544 [Anope Stable (1.8.x series)] ChanServ minor always 2013-08-16 05:49 2013-08-16 19:53
Reporter: meadows Platform: *NIX  
Assigned To: Adam OS: FreeBSD  
Priority: normal OS Version: 8.3  
Status: resolved Product Version: 1.8.8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Bug in CS SUSPEND and CS FORBID
Description: When using CS SUSPEND or CS FORBID without giving a custom reason, the default reason "This channel may not be used." should appear when ChanServ kicks users. This works fine when people join a channel *after* it was suspended/forbidden; however, if users are in the channel at the time the command is issued, the kicks look like this:

* Guest17 was kicked by ChanServ (CHAN_SUSPEND_REASON)

* Guest17 was kicked by ChanServ (CHAN_FORBID_REASON)
Tags:
Steps To Reproduce:
Additional Information: anope 1.8.x with UnrealIRCd
Attached Files:
Notes
(0006508)
Adam   
2013-08-16 19:53   
thanks, fixed in d24ae1f961a70e8f3edff8816eaaff7cf5705e5b

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1542 [Anope Stable (1.8.x series)] Other minor always 2013-08-01 16:10 2013-08-12 19:38
Reporter: anha26 Platform: Unknown  
Assigned To: Adam OS: Ubuntu  
Priority: normal OS Version: 13.04 LTS  
Status: resolved Product Version: 1.8.8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Forbidden underscore in idents
Description: BotServ as well as HostServ doesn't allow underscore ( _ ) in idents.
E.g.: Chat_Bot@bot.domain.tld
Tags: botserv, hostserv, ident, rfc, vhost
Steps To Reproduce: /msg hostserv setall <nick> Chat_Bot@bot.domain.us
/msg botserv bot add Chat_Bot Chat_Bot bot.domain.us Chatty
Allows nick "Chat_Bot", but not ident/user "Chat_Bot"
Additional Information: None really. RFC says underscore is a valid character.

Is this an Anope or UnrealIRCd error?

NB: Tested on network: chat.gecero.net:6667

UnrealIRCd version 3.2.10.1
Anope: 1.8.8 source
OS: Ubuntu 13.04 LTS
Attached Files: Chat_Bot.png (261,924 bytes) 2013-08-01 16:10
https://bugs.anope.org/file_download.php?file_id=344&type=bug
png
Notes
(0006507)
Adam   
2013-08-12 19:38   
fixed in f15a9749f9afc23e32e029ac495a53d24ac281b8
(0006504)
anha26   
2013-08-02 11:30   
Well, after seeing other reports:
Platform = *nix

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1541 [Anope Development (1.9.x series)] Chanserv minor always 2013-07-29 06:53 2013-08-11 21:04
Reporter: Eyecu Platform: Anope-1.9.9 (gfde83f6)  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Using latest git. Set chanserv to opers only, none opers can still register a channel.
Description: Setting ChanServ to opersonly doesn't appear to work. None Opers can register a channel.
Tags:
Steps To Reproduce: Registered a new nick not attached to an oper account.
joined a new channel
/cs register channel description

Channel Registered even though in the chanserv.conf it's set to opers only.
Additional Information:
Attached Files:
Notes
(0006506)
Adam   
2013-08-11 21:04   
fixed in 53d5b7c29ea2f0164b562549cef579fe2b276abf
(0006503)
Eyecu   
2013-08-01 05:31   
This is both on FreeBsd 8.3-RELEASE-pX and Debian6.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1540 [Anope Development (1.9.x series)] Other minor always 2013-07-21 02:13 2013-07-21 09:01
Reporter: fgsch Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Issues with 1.9
Description: Issues:

- pid has no default and is not validated. if left empty anope won't start
- timeoutcheck is now required but data/examples.conf says otherwise. not sure which one is wrong, example or code
- motd has no default but data/example.conf says otherwise
- if uplink is not present anope will crash

Changes from 1.9.8:

- name is not validated (could be empty)
- description is not validated (could be empty)
- motd is not validated (could be empty)
- networkname is not validated (could be empty)
Tags:
Steps To Reproduce: run services without pid/timeoutcheck/uplink
Additional Information:
Attached Files:
Notes
(0006502)
Adam   
2013-07-21 09:01   
fixed in 604da898136b9299f555336df633e30a09f44ddd
(0006500)
fgsch   
2013-07-21 02:46   
- nicklen, userlen, hostlen, chanlen, passlen have no defaults
(0006499)
fgsch   
2013-07-21 02:33   
- forceemail defaults to yes now but data/nickserv.conf says otherwise
(0006498)
fgsch   
2013-07-21 02:21   
More:

- uplink port's is not validated (will default to 0)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1533 [Anope Development (1.9.x series)] Nickserv minor always 2013-06-25 20:03 2013-07-21 05:38
Reporter: ObiWan Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ldap not being searched on identify
Description: I've just noticed today that the ldap module doesn't seem to be queried anymore when an "identify" to Nickserv is issued.

I can't see any request inside of my debug log and new users can't authenticate even if they are definitively there.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006501)
Adam   
2013-07-21 05:38   
fixed in e11abdc4f00b19feae7830d4de6098e282e7eb39
(0006490)
DukePyrolator   
2013-06-29 19:13   
confirmed, I can reproduce it.

m_ldap says it binds to the ldap server, but there is no outgoing tcp connection.
m_ldap_authentication aborts in OnCheckAuthentication() on the "this->ldap" check.
(0006489)
ObiWan   
2013-06-29 17:34   
Do you have any idea what the problem could be?
(0006482)
ObiWan   
2013-06-25 21:06   
I've already tried to restart several times however it didn't make a difference. That was my first idea that the module just crashed for some reason.


Version:
commit 7d0e0633009d38c0daff4969cf0928581a35bcaf
Author: DukePyrolator <DukePyrolator@anope.org>
Date: Sat Jun 22 17:06:48 2013 +0200
(0006481)
chaz   
2013-06-25 20:13   
Hi,

I've seen this happen on 1.9.x where for no reason it stops working until the module is unloaded (which used to crash but that's fixed) and re-loaded.

Have you tried that, or restarting anope?

Which version exactly are you using please?

Thanks,

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1537 [Anope Development (1.9.x series)] Chanserv major always 2013-07-07 12:47 2013-07-21 00:46
Reporter: ObiWan Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: SOP cannot modify AOP list
Description: Just noticed that a SOP cannot modify the AOP list even if the order is correct:

command { service = "ChanServ"; name = "QOP"; command = "chanserv/xop"; group = "chanserv/access"; }
command { service = "ChanServ"; name = "SOP"; command = "chanserv/xop"; group = "chanserv/access"; }
command { service = "ChanServ"; name = "AOP"; command = "chanserv/xop"; group = "chanserv/access"; }
command { service = "ChanServ"; name = "HOP"; command = "chanserv/xop"; group = "chanserv/access"; }
command { service = "ChanServ"; name = "VOP"; command = "chanserv/xop"; group = "chanserv/access"; }
Tags:
Steps To Reproduce: 1. Register a new channel.
2. Add a user to the SOP list
3. The SOP can try to add another user to the AOP list -> access denied
4. The SOP can try to add the user to the HOP list -> works
Additional Information: commit 9a4f27e0a3649c5fe37e1704f7f90cc87e4d02f7
Author: Adam <Adam@anope.org>
Date: Fri Jul 5 02:19:06 2013 -0400

------------

13:46:09] ChanServ [services@services.st-city.net]: Access list for #test:
[13:46:09] ChanServ [services@services.st-city.net]: Number Level Mask
[13:46:09] ChanServ [services@services.st-city.net]: 1 4 Tioz
[13:46:09] ChanServ [services@services.st-city.net]: 2 10 newbie
[13:46:09] ChanServ [services@services.st-city.net]: End of access list


[13:46:35] ChanServ [services@services.st-city.net]: Access level settings for channel #test:
[13:46:35] ChanServ [services@services.st-city.net]: Name Level
[13:46:35] ChanServ [services@services.st-city.net]: ACCESS_CHANGE 10
[13:46:35] ChanServ [services@services.st-city.net]: ACCESS_LIST 3
[13:46:35] ChanServ [services@services.st-city.net]: NOKICK 1
[13:46:35] ChanServ [services@services.st-city.net]: FANTASIA 3
[13:46:35] ChanServ [services@services.st-city.net]: GREET 5
[13:46:35] ChanServ [services@services.st-city.net]: AUTOVOICE 3
[13:46:35] ChanServ [services@services.st-city.net]: VOICEME 3
[13:46:35] ChanServ [services@services.st-city.net]: VOICE 4
[13:46:35] ChanServ [services@services.st-city.net]: INFO 9999
[13:46:35] ChanServ [services@services.st-city.net]: SAY 5
[13:46:35] ChanServ [services@services.st-city.net]: AUTOHALFOP 4
[13:46:35] ChanServ [services@services.st-city.net]: HALFOPME 4
[13:46:35] ChanServ [services@services.st-city.net]: HALFOP 5
[13:46:35] ChanServ [services@services.st-city.net]: KICK 4
[13:46:35] ChanServ [services@services.st-city.net]: SIGNKICK 9999
[13:46:35] ChanServ [services@services.st-city.net]: BAN 4
[13:46:35] ChanServ [services@services.st-city.net]: TOPIC 5
[13:46:35] ChanServ [services@services.st-city.net]: MODE 9999
[13:46:35] ChanServ [services@services.st-city.net]: GETKEY 5
[13:46:35] ChanServ [services@services.st-city.net]: INVITE 5
[13:46:35] ChanServ [services@services.st-city.net]: UNBAN 4
[13:46:35] ChanServ [services@services.st-city.net]: AUTOOP 5
[13:46:35] ChanServ [services@services.st-city.net]: OPME 5
[13:46:35] ChanServ [services@services.st-city.net]: OP 5
[13:46:35] ChanServ [services@services.st-city.net]: AUTOPROTECT 10
[13:46:35] ChanServ [services@services.st-city.net]: AKICK 10
[13:46:35] ChanServ [services@services.st-city.net]: BADWORDS 10
[13:46:35] ChanServ [services@services.st-city.net]: ASSIGN (founder only)
[13:46:35] ChanServ [services@services.st-city.net]: MEMO 10
[13:46:35] ChanServ [services@services.st-city.net]: PROTECTME 10
[13:46:35] ChanServ [services@services.st-city.net]: PROTECT 9999
[13:46:35] ChanServ [services@services.st-city.net]: SET 9999
[13:46:35] ChanServ [services@services.st-city.net]: AUTOOWNER 9999
[13:46:35] ChanServ [services@services.st-city.net]: OWNERME 9999
[13:46:35] ChanServ [services@services.st-city.net]: OWNER (founder only)
[13:46:35] ChanServ [services@services.st-city.net]: FOUNDER (founder only)
Attached Files:
Notes
(0006497)
Adam   
2013-07-21 00:46   
fixed in cb70d976ba3b500418264a0d1b891bae6e8216a2

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1538 [Anope Development (1.9.x series)] Chanserv minor always 2013-07-19 09:00 2013-07-20 08:07
Reporter: ObiWan Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Topics not being restored when network comes up again
Description: Another issue from me :)

I've got several channels with the "keeptopic" option enabled. However when the network comes up again Chanserv won't restore the channel topics.

Tags:
Steps To Reproduce:
Additional Information: Version 1.9
Attached Files:
Notes
(0006496)
Adam   
2013-07-20 08:07   
fixed in 492eac20a8e2dfdbdbd5a83e41ed880af76cff79

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1246 [Anope Stable (1.8.x series)] Other minor sometimes 2011-02-17 12:15 2013-07-09 08:26
Reporter: DjSlash Platform:  
Assigned To: Viper OS:  
Priority: low OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: services.chk check is not always accurate
Description: Once in while the services get started twice because the check in services.chk doesnt have the correct outcome. Because it removes the services.pid too, it starts over and over. This gets annoying, since you'll see several connection attempts.
Tags:
Steps To Reproduce: Put the services.chk in your crontab and wait. It's bound to happen sooner or later.
Additional Information: I changed the check as followed (changed the obsolete usage of backticks too):

< ANOPID=`cat $ANOPIDF`
< if [ `ps auwx | grep $ANOPROG | grep $ANOPID | grep -v -c grep` = 1 ]
---
> ANOPID=$(cat $ANOPIDF)
> if [ $(pgrep -u $(id -u) $ANOPROG | grep -c $ANOPID) = 1 ]
Attached Files: crontab.patch (436 bytes) 2012-06-08 10:32
https://bugs.anope.org/file_download.php?file_id=331&type=bug
Notes
(0006491)
j883376   
2013-07-09 08:26   
I've had this patch applied for a couple of weeks now and it failed on me a few days ago.

UnrealIRCd does their check by sending a SIGCHLD and comparing the return value, which might be a good way of doing it since I've never seen it fail on me.

Example from their ircdchk file:
  if `kill -CHLD $ircdpid >/dev/null 2>&1`; then
    # it's still going
    # back out quietly
    exit 0
  fi
(0006479)
DukePyrolator   
2013-06-18 16:09   
is the fix working? can we commit it to the stable and the devel branch?
(0006232)
cronus   
2012-07-24 08:54   
I've gotten hit by this odd bug randomly on and off for a few years. I'm now trying the patch on *nix Debian Squeeze 64bit to be exact. Will report any issues I find.
(0006155)
Viper   
2012-06-08 10:31   
Got hit by this again out of the blue recently..

I'm attaching a patch by Jeremy which I am testing now on BSD. If anyone is up to it testing it on *nix.. :)

I will try this for a bit to make sure it doesn't blow up and if no one has any remarks, it will be committed..
(0006058)
chaz   
2012-01-07 08:29   
I wouldn't do it this way, pidof will return by default all processes by that name owned by any user.

eg.

chaz@scooby:~$ ps aux | grep bash
chaz 27748 0.0 0.0 28248 5688 pts/1 Ss Jan03 0:00 /bin/bash
chaz 7189 0.0 0.0 28220 5656 pts/0 Ss 05:49 0:00 bash
chaz 7244 0.0 0.0 28256 5740 pts/2 Ss 05:49 0:00 bash
chaz 7960 0.5 0.0 28220 5660 pts/3 Ss 06:27 0:00 bash
root 7939 0.0 0.0 25032 2420 pts/2 S 06:27 0:00 bash
root 7949 0.0 0.0 25028 2200 pts/2 S+ 06:27 0:00 bash

chaz@scooby:~$ pidof bash
27748 7960 7949 7939 7244 7189


I think using the full path for the services binary would be better place first of all.

From the manpage

       When pidof is invoked with a full pathname to the program it should find the pid of, it is reasonably safe. Otherwise it is possible that it returns pids of running programs that happen to have
       the same name as the program you're after but are actually other programs. Note that that the executable name of running processes is calculated with readlink(2), so symbolic links to executables
       will also match.
(0006057)
DukePyrolator   
2012-01-07 08:22   
Phantomal suggests to use following script:

#! /bin/bash
while true
do
PID1=$(pidof services)
if (( PID1 < 1 ))
then
./services
fi
sleep 20
done

(used by orion services)

is "pidof" available in all *NIX and *BSD distributions?
(0005836)
DjSlash   
2011-06-05 15:40   
What I meant, it isn't possible with a normal usercase. In the case of root being the one who is running de services or when someone uses the configure script to have special permissions, it would require the user to adjust the script accordingly. In that case the user is responsible, since it is his choice to make a different approach using the services.

The example.chk file should be a good example for usage in a normal case. The current example.chk file has some flaws and I think it should be fixed.
(0005787)
katsklaw   
2011-04-10 22:42   
DJSlash said: "it isn't possible to run the services as a different user, so we don't need to consider it"

This isn't true. UID 0 (root) can run any program set as executable. Additionally during ./Config, octal permissions can be altered to allow other users to execute Anope. I can only imagine this useful on a dedicated box where SRA's have separate logins and exec Anope. Regardless, it's possible and Anope supports it.
(0005773)
DjSlash   
2011-03-21 23:05   
Regarding the uid check: it isn't possible to run the services as a different user, so we don't need to consider it. Checking for the uid gives us a better result when the script is run on a shared shell server.

Here's the diff between my version and the shipped one:

< ANOPID=$(cat $ANOPIDF)
< if [ $(pgrep -u $(id -u) -f "$ANOPROG $ANOARGS" | grep -cx $ANOPID) = 1 ]
---
> ANOPID=`cat $ANOPIDF`
> if [ `ps auwx | grep $ANOPROG | grep $ANOPID | grep -v -c grep` = 1 ]

I also found out that if the services are started directly without arguments, it starts and when it finds out that it can't link, it dies and removes the pidfile. When this occurs and the check script is run by cron, it can't find the pidfile and chaos begins. So I recon it would better to have the services require at least one argument or have a check on the pidfile itself.
(0005763)
DjSlash   
2011-03-14 14:46   
I think it requires further investigation, because couple of days ago the services.pid was suddenly lost and I'm not sure if it was due the services.chk cronjob. Guess I need to make it verbose for a while. I've checked the script again at that time and figured that if you have the crontab running as an other user (not a common way, but still), it can't find the process. So you might want to remove the "-u $(id -u)" part (searches for processes with matching uid).

Adding "-x" to the grep command could be another improvement:

djslash@echoes:~$ cat bla
01234
1234
12345
djslash@echoes:~$ grep -c 1234 bla
3
djslash@echoes:~$ grep -cx 1234 bla
1

With pgrep you could add "-f" to check for the commandline (which in our case is: "./services -logchan"):
drlnet@miriel:~/services$ pgrep -f 'services -logchan'
1436
drlnet@miriel:~/services$ cat services.pid
1436

You can ask me on #anope too, I'm there as slush
(0005762)
chaz   
2011-03-13 09:22   
Hello,

I'm reviewing this bug.

Are you saying with the change you made all is well or does this require further investigation?

Regards,

Charles

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1531 [Anope Development (1.9.x series)] Other minor always 2013-06-17 18:16 2013-06-20 00:06
Reporter: KindOne Platform: Windows  
Assigned To: Adam OS: XP  
Priority: normal OS Version: SP3  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: SASL plain does not apply vHost - NickServ also tells me to identify to a nick I just sasl'ed in with.
Description: <- :irc.kindone.net NOTICE AUTH :*** Looking up your hostname...
<- :irc.kindone.net NOTICE AUTH :*** Couldn't resolve your hostname; using your IP address instead
-> 127.0.0.1 CAP LS
-> 127.0.0.1 NICK KindOne
-> 127.0.0.1 USER KindOne 0 127.0.0.1 :...
<- :irc.kindone.net CAP * LS :account-notify away-notify multi-prefix sasl userhost-in-names
-> 127.0.0.1 CAP REQ :multi-prefix sasl
<- PING :7499B8B6
-> 127.0.0.1 PONG :7499B8B6
<- :irc.kindone.net CAP KindOne ACK :multi-prefix sasl
-> 127.0.0.1 AUTHENTICATE PLAIN
<- AUTHENTICATE +
-> 127.0.0.1 AUTHENTICATE S2luZE9uZQBLaW5kT25lAGZvb2Jhcg==

// I think it should say "KindOne.vHost" instead of "192.168.254.100" -- since that's my vHost tied to my account.

<- :irc.kindone.net 900 KindOne KindOne!KindOne@192.168.254.100 KindOne :You are now logged in as KindOne.
<- :irc.kindone.net 903 KindOne :SASL authentication successful
-> 127.0.0.1 CAP END
<- :irc.kindone.net 001 KindOne :Welcome to the KindOne IRC Network KindOne!KindOne@192.168.254.100
<- :irc.kindone.net 002 KindOne :Your host is irc.kindone.net, running version Unreal3.2.10.1
<- :irc.kindone.net 003 KindOne :This server was created Fri Apr 5 16:26:49 2013
<- :irc.kindone.net 004 KindOne irc.kindone.net Unreal3.2.10.1 iowghraAsORTVSxNCWqBzvdHtGpI lvhopsmntikrRcaqOALQbSeIKVfMCuzNTGjZ
<- :irc.kindone.net 005 KindOne CMDS=KNOCK,MAP,DCCALLOW,USERIP,STARTTLS UHNAMES NAMESX SAFELIST HCN MAXCHANNELS=120 CHANLIMIT=#:120 MAXLIST=b:60,e:60,I:60 NICKLEN=30 CHANNELLEN=32 TOPICLEN=307 KICKLEN=307 AWAYLEN=307 :are supported by this server
<- :irc.kindone.net 005 KindOne MAXTARGETS=20 WALLCHOPS WATCH=128 WATCHOPTS=A SILENCE=15 MODES=12 CHANTYPES=# PREFIX=(qaohv)~&@%+ CHANMODES=beI,kfL,lj,psmntirRcOAQKVCuzNSMTGZ NETWORK=KindOne CASEMAPPING=ascii EXTBAN=~,qjncrRa ELIST=MNUCT :are supported by this server
<- :irc.kindone.net 005 KindOne STATUSMSG=~&@%+ EXCEPTS INVEX :are supported by this server
<- :irc.kindone.net 251 KindOne :There are 1 users and 9 invisible on 2 servers
<- :irc.kindone.net 252 KindOne 9 :operator(s) online
<- :irc.kindone.net 254 KindOne 2 :channels formed
<- :irc.kindone.net 255 KindOne :I have 3 clients and 1 servers
<- :irc.kindone.net 265 KindOne 3 4 :Current local users 3, max 4
<- :irc.kindone.net 266 KindOne 10 10 :Current global users 10, max 10
<- :irc.kindone.net 422 KindOne :MOTD File is missing
<- :KindOne MODE KindOne :+i

// Erm What? I just did sasl plain, why are you telling me to identify to a nick I just identified to it?

<- :NickServ!services@services.kindone.net NOTICE KindOne :This nickname is registered and protected. If it is your
<- :NickServ!services@services.kindone.net NOTICE KindOne :nick, type /msg NickServ IDENTIFY password. Otherwise,
<- :NickServ!services@services.kindone.net NOTICE KindOne :please choose a different nick.
<- :NickServ MODE KindOne :+r
-> irc.kindone.net PROTOCTL NAMESX
-> irc.kindone.net PROTOCTL UHNAMES
-> irc.kindone.net OPER kindone f00
<- :KindOne MODE KindOne :+owghaAsN
<- :irc.kindone.net 008 KindOne :Server notice mask (+kcfvGqso)
<- :irc.kindone.net 381 KindOne :You are now an IRC Operator
<- :irc.kindone.net NOTICE KindOne :*** Global -- from OperServ: USERS: KindOne!KindOne@192.168.254.100 is now an IRC operator.

// So.. I got a vhost "KindOne.vHost"

-> irc.kindone.net NS info KindOne
<- :NickServ!services@services.kindone.net PRIVMSG KindOne :KindOne is ...
<- :NickServ!services@services.kindone.net PRIVMSG KindOne :KindOne is a Services Operator of type Services Administrator.
<- :NickServ!services@services.kindone.net PRIVMSG KindOne : Online from: KindOne@192.168.254.100
<- :NickServ!services@services.kindone.net PRIVMSG KindOne : Online from: KindOne@192.168.254.100
<- :NickServ!services@services.kindone.net PRIVMSG KindOne : Time registered: Jun 12 02:34:17 2013 Eastern Daylight Time (5 days, 9 hours, 58 minutes ago)
<- :NickServ!services@services.kindone.net PRIVMSG KindOne :Last quit message: Quit:
<- :NickServ!services@services.kindone.net PRIVMSG KindOne : Email address: lol@lol.com
<- :NickServ!services@services.kindone.net PRIVMSG KindOne : VHost: KindOne.vHost
<- :NickServ!services@services.kindone.net PRIVMSG KindOne : Options: Protection, Security, Private, Message mode, Auto-op
<- :NickServ!services@services.kindone.net PRIVMSG KindOne : Expires: Jul 06 05:05:52 2013 Eastern Daylight Time (18 days, 16 hours, 32 minutes from now)

// Odd.. vHost was not applied when I do sasl plain. (Its applied if I do /ns id.. instead of sasl)

-> irc.kindone.net WHOIS KindOne KindOne

// Suppose to show "KindOne.vHost", not "192.168.254.100"
 
<- :irc.kindone.net 311 KindOne KindOne KindOne 192.168.254.100 * :...
<- :irc.kindone.net 379 KindOne KindOne :is using modes +iowghraAsN +kcfvGqso
<- :irc.kindone.net 378 KindOne KindOne :is connecting from *@192.168.254.100 192.168.254.100
<- :irc.kindone.net 307 KindOne KindOne :is identified for this nick
<- :irc.kindone.net 312 KindOne KindOne irc.kindone.net :KindOne
<- :irc.kindone.net 313 KindOne KindOne :is a Network Administrator
<- :irc.kindone.net 310 KindOne KindOne :is available for help.
<- :irc.kindone.net 330 KindOne KindOne KindOne :is logged in as
<- :irc.kindone.net 317 KindOne KindOne 55 1371486780 :seconds idle, signon time
<- :irc.kindone.net 318 KindOne KindOne :End of /WHOIS list.



-> irc.kindone.net version services.*
<- :services.kindone.net 351 KindOne Anope-1.9.8 (gce094f4) services.kindone.net :UnrealIRCd 3.2.x -(enc_sha256) -- build 0000002, compiled 23:57:38 Mar 2 2013, flags GW

// Services are ULined.

-> irc.kindone.net STATS U
<- :irc.kindone.net 248 KindOne U services.kindone.net
<- :irc.kindone.net 219 KindOne U :End of /STATS report

(All passwords in this are only used for my 127.0.0.1)
Tags:
Steps To Reproduce: Start UnrealIRCd 3.2.10.1
Start Anope 1.9.8
Register a nick
Set a vHost on yourself.
Set client to do sasl plain.
Reconnect.

Additional Information:
Attached Files:
Notes
(0006480)
Adam   
2013-06-20 00:06   
fixed in 5ac1e9175d90fad5feaf235dfe225ddffc47f257

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1466 [Anope Development (1.9.x series)] Nickserv minor always 2013-01-04 22:47 2013-06-18 06:49
Reporter: Robby Platform:  
Assigned To: DukePyrolator OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ns_ajoin, non-SSL users and SSL channels on InspIRCd
Description: On InspIRCd, which does not have a umode for SSL users but instead uses metadata for this, the ns_ajoin module's SSL check cannot correctly determine if a user is on SSL or not and erroneously attempts to join the user to the SSL channel.
InspIRCd (tested with 2.0.10) luckily prevents this join and spits out an error to the user.

Anope should use this metadata to determine if a user is using SSL or not for IRCds with no umode for SSL. ratbox for example also seems to have no umode for this.
Tags:
Steps To Reproduce:
Additional Information: From the moment InspIRCd sends "ssl_cert" (even if the user does not have a cert) it can be used to safely say the user is on an SSL connection.
Attached Files:
Notes
(0006478)
DukePyrolator   
2013-06-18 06:49   
fixed in https://github.com/anope/anope/commit/fc527b464a45c35126028fbf48ebe6edc0744405

thanks for reporting :)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1530 [Anope Development (1.9.x series)] Other major always 2013-06-16 03:14 2013-06-16 03:25
Reporter: Rottman3D Platform: Intel  
Assigned To: Adam OS: Solaris  
Priority: normal OS Version: 10 and 11  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Anope will not build on Solaris 10 or 11
Description: Any time I try to build Anope on Solaris I receive symbol reference errors. This is the same issue reported in Bug 1227. When cmake gets to anopesmtp the build fails on undefined symbols __xnet_connect, __xnet_socket, gethostbyname, and inet_addr. I have tried additional include directories. Other applications build perfectly well on my setup. I specify /usr/include which contains the headers that contain these symbols.
Tags:
Steps To Reproduce: Attempt a build on Solaris 10 or 11. Fails on both 32 and 64 bit.
Additional Information:
Attached Files:
Notes
(0006475)
Adam   
2013-06-16 03:25   
This was fixed 2 months ago in https://github.com/anope/anope/commit/81483ae5e7e8032f7f4899f4b24b32b750d68ff3

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1527 [Anope Stable (1.8.x series)] Modules major always 2013-06-04 18:27 2013-06-05 18:11
Reporter: max Platform: x64  
Assigned To: Viper OS: Windows  
Priority: urgent OS Version: Win7  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Lock option "DisableRaw" does not work
Description: In the configuration file services.conf option "DisableRaw" uncommented.
When the Root Service run the commands "/OperServ ModLoad os_raw", returns the result:
"-OperServ-Module os_raw loaded".
At the same time, the log-channel receive the following message:
<Global> [Os_raw] Unloading because DisableRaw is enabled
<Global> Module loading status: 0 (Module, Okay - No Error).

There is a question, why os_raw module is still loaded, despite the lock?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006464)
Viper   
2013-06-05 16:52   
Fixed in f1c3f0d820caedfd7667c09bd06f60b9c23283d9.
(0006463)
Viper   
2013-06-05 09:23   
This bug is much more severe then it would seem at first glance.. check following output:
 «Global» Trying to load module [svc_test]
 «Global» aborting load..
 «Global» Module loading status: 0 (Module, Okay - No Error)

All modules that issue a MOD_STOP in AnopeInit because the conditions for their load are not fulfilled and issue a MOD_STOP to abort loading are actually loaded.. some of these modules may not perform any further sanity checks in their code and assume that all modes or conditions they depend upon are fulfilled.. this could lead to dangerous conditions, possibly causing crashes or invalid commands being send to the IRCd. If not by the core modules, probably by 3rd party ones - I'm pretty sure some of my modules will be affected..
(0006462)
max   
2013-06-04 20:45   
Thank's.
(0006461)
chaz   
2013-06-04 20:22   
Thanks, I've just confirmed this on 1.8.8 with the same IRCd.

Marking the bug as confirmed.
(0006460)
max   
2013-06-04 20:20   
I use UnrealIRCd 3.2.10.1 + Anope 1.8.8
(0006459)
chaz   
2013-06-04 20:16   
Thanks, that's cool I'll try and reproduce it in a moment.

Can you confirm which version of Anope you're using, together with ircd+version?

Thanks.
(0006458)
max   
2013-06-04 20:10   
Yes, that's right.
Despite the fact that there is a message that the module can not be loaded (<Global> [Os_raw] Unloading because DisableRaw is enabled), the next message indicates that the module is loaded successfully (<Global> Module loading status: 0 (Module, Okay - No Error)).
And the command "/OperServ Raw" executed, despite the lockout.
(0006457)
chaz   
2013-06-04 19:25   
Hello,

I do not understand what the issue is here.

Having DisableRaw uncommented implies that you want raw to be disabled.

Attempting to load the module os_raw passes because you're asking it to load, it is then unloaded again because of DisableRaw being in place.

This is expected behaviour.

Or are you saying that despite the message from global saying "unloading because DisableRaw is enabled" that it infact does not unload?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1525 [Anope Development (1.9.x series)] HostServ minor always 2013-05-30 14:45 2013-05-31 07:02
Reporter: Takkun Platform:  
Assigned To: Adam OS: CentOS  
Priority: normal OS Version: 6.4  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Host Request Doesn't Show up on waiting list
Description: Well a friend of mine in my IRC server requested a Host using "/hs request".
In my IRC Server, i've set a configuration when someone request for vhost it will send memo. After a minute, I received the memo and quickly checked the host request list using "/hs waiting" and I saw nothing. I told my friend to request again using same command. Then again I received the memo and still nothing in the waiting list. And then I tried to activate it using "/hs activate friend_nick". And then this showed up. <HostServ> COMMAND: Takkun!Takkun@112.207.83.145 used activate for friend_nick for vhost 127.0.0.1.

I just activated my friend's host without seeing it on the waiting list...
~_~
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006455)
Adam   
2013-05-31 07:02   
fixed in f5c01bf617bc2d140d19ab9a927e4976d20d0c5f

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1521 [Anope Development (1.9.x series)] IRCD Support major always 2013-05-13 17:31 2013-05-15 02:26
Reporter: localpoison Platform: x86_64  
Assigned To: DukePyrolator OS: Debian GNU/Linux 7.0  
Priority: normal OS Version: 7.0  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 1.9.x-GIT  
    Target Version:  
Summary: Enforcer won't release nicks
Description: This issue has already been reported and fixed for several other IRC daemons, but we're still seeing this behaviour for ngIRCd.

The enforcer won't release a nick that is registered but not identified for within the set time limit. Instead you'll see it reconnecting the server in a loop. When recovering that nick, NickServ will tell you the nick has been released, but when a user tries to use that nick it'll tell you that the nick is already in use.

The only thing that seems to help is restarting services.

Daemon Name: ngIRCd
Version: 20.1-IPv6+IRCPLUS+SSL+SYSLOG+ZLIB-x86_64/pc/linux-gnu

Anope Version: Anope-1.9.8-may-cause-insanity -- build 0000002, compiled 20:51:49 Jan 31 2013

Regards,
local.
Tags:
Steps To Reproduce: - join Server
- /nick a nick that is registered
- don't identify
- nickserv takes away nick
- it's not possible to recover nick
Additional Information: everything else works great. Thank you!
Attached Files:
Notes
(0006450)
DukePyrolator   
2013-05-15 02:26   
fixed in https://github.com/anope/anope/commit/934b5843744e586ce9a3c7725a19c7ddffe14ee8

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1519 [Anope Development (1.9.x series)] Nickserv crash always 2013-05-07 10:13 2013-05-08 23:26
Reporter: CuttingEdge Platform: x86_64  
Assigned To: Adam OS: Ubuntu Linux  
Priority: high OS Version: 13.04  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Services crashes on NickServ RECOVER.(GHOST)
Description: Anope appears to crash as soon as the RECOVER (GHOST) command it used on another logged in nickname.

User2 (issuer) becomes the original User1 (ghost) via SVSNICK, and services crashes.
Tags:
Steps To Reproduce: Use NickServ's RECOVER (GHOST) command on another nickname.
Additional Information: Using latest Anope 1.9.x GIT.
Using InspIRCd 2.0.12.

The two nicknames are both registered, and in the same group.

I've added a paste of the 'gdb' output to:
http://pastebin.anope.org/index.php?page=viewpaste&id=16b16b1de4
System Description
Attached Files:
Notes
(0006445)
Adam   
2013-05-08 23:26   
fixed in 735f0ba6cf5602396bc2cabd6ceca0e92a0edd00

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1497 [Anope Development (1.9.x series)] Other minor always 2013-04-03 08:50 2013-05-08 23:16
Reporter: CuttingEdge Platform: x86_64  
Assigned To: Adam OS: Ubuntu Linux  
Priority: normal OS Version: 12.10  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Emails being stripped of new (blank) lines.
Description: Anope appears to be trimming/stripping/removing new (blank) lines within email messages sent from any of the pre-configured email templates (new memo, new registration, etc).

Its impossible to separate new paragraphs in emails.

Also, adding only a space in the new (blank) line (without any other text) causes processing of the template to halt (any subsequent text is dropped from the email).
Tags:
Steps To Reproduce: 1) Trigger any email related function from within Anope that uses an email template with blank/empty lines that separates paragraphs.
Additional Information: Using latest Anope 1.9.x GIT.
Using Postfix MTA.
System Description
Attached Files:
Notes
(0006444)
Adam   
2013-05-08 23:16   
fixed in 5e7085130eb245e6ab9d44c04816ad62a324cd43
(0006442)
CuttingEdge   
2013-05-07 07:39   
Notice the gap between the "You have requested to register ..." and "Please type ..." lines. Its not present in the default Anope config.

The two lines are not separated by an additional new line in the config, yet they are, in the email output.
(0006439)
Adam   
2013-05-07 02:50   
I am unable to reproduce any of these problems using the default config on Ubuntu 12.04.2 LTS with postfix 2.9.6 and viewing the email using gmail.

When the config is being parsed, registration_message is set like so:

[May 06 21:50:15.800637 2013] Debug: ln 1006 EOL: s='mail' 'registration_message' set to 'Hi,

You have requested to register the nickname %n on %N.

Please type " /msg NickServ CONFIRM %c " to complete registration.

If you don't know why this mail was sent to you, please ignore it silently.

%N administrators.'

Which is correct.
(0006433)
CuttingEdge   
2013-05-06 08:40   
I've just updated to the latest GIT version, and have noticed that now all the emails have a blank line between each line defined in the config file, regardless of there being a blank line or not between the lines.

Example:

Config:
this
is
a
test

Email:
this

is

a

test
(0006430)
Adam   
2013-05-05 07:04   
This is fixed in 1d0bb9b26b7ad58ab0bf979ac046f4511b3bf12b

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1512 [Anope Development (1.9.x series)] Chanserv minor have not tried 2013-04-12 12:30 2013-05-08 23:16
Reporter: webczat Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: cs_mode does not check peace settings
Description: Hello.

I didn't try to reproduce that, but I've read the code and i've discovered that the cs_mode module does not check for peace settings when checking the access levels of the users it tries to change status of.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006443)
Adam   
2013-05-08 23:16   
fixed in 9ee7c825e120a56aa5c8b270ab7304354cad93c5

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1515 [Anope Development (1.9.x series)] Operserv major always 2013-05-04 08:12 2013-05-07 03:21
Reporter: CuttingEdge Platform: x86_64  
Assigned To: Adam OS: Ubuntu Linux  
Priority: normal OS Version: 13.04  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: OperServ session limits triggering on incorrect numbers after netsplit (InspIRCd).
Description: I don't think Anope is decrementing the session variable counter for the affected users/hosts when a server they're connected to splits from the network.

This appears to be specific to just InspIRCd.
Tags:
Steps To Reproduce: 1) Have a user connect to a server that is not directly linked to services.
2) Split (and reconnect) the same server from the network.
3) Check session limits for set user (you'll notice its incremented by 1).
4) If user reconnects, the variable is still in place (and increments), and will trigger a session limit (if applicable), if the said server has split numerous times over the test period.
Additional Information: Using InspIRCd 2.0.12.
Using Anope 1.9.x GIT.
System Description
Attached Files:
Notes
(0006441)
Adam   
2013-05-07 03:21   
fixed in 6578829fa6d278cae0307676f29ab4e76d2d2518
(0006435)
Adam   
2013-05-06 09:19   
Is it even seeing the server split?

Get /os stats uplink before and after (mostly the server count)

Can you get debug logs of the split?
(0006434)
CuttingEdge   
2013-05-06 08:50   
Updated to latest GIT.

Just checked; still duplicating sessions within OperServ.
(0006431)
Adam   
2013-05-05 07:04   
This is probably fixed from 10b5b00db4f6f38f33b122f1a2cbcb788fc7c0eb, can you check that it really is?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1518 [Anope Development (1.9.x series)] IRCD Support crash always 2013-05-06 14:21 2013-05-07 03:21
Reporter: CuttingEdge Platform: x86_64  
Assigned To: Adam OS: Ubuntu Linux  
Priority: high OS Version: 13.04  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Services crashes when InspIRCd 2.0.x module is loaded with the 'use_server_side_mlock' setting enabled.
Description: If I set the 'use_server_side_mlock' setting within the 'inspircd20' module to 'yes', services will crash when a user creates a new channel.
Tags:
Steps To Reproduce: 1) Set 'use_server_side_mlock' to 'yes' when using the 'inspircd20' protocol module within the 'services.conf' file.
2) Join a channel that is not created yet.
Additional Information: I've ran the issue through gdb. See: http://pastebin.anope.org/index.php?page=viewpaste&id=acd9a753bc

Using latest Anope 1.9.x GIT.
Using InspIRCd 2.0.12.
System Description
Attached Files:
Notes
(0006440)
Adam   
2013-05-07 03:21   
fixed in 6578829fa6d278cae0307676f29ab4e76d2d2518

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1517 [Anope Development (1.9.x series)] Other major always 2013-05-06 09:09 2013-05-06 12:41
Reporter: CuttingEdge Platform: x86_64  
Assigned To: Adam OS: Ubuntu Linux  
Priority: high OS Version: 13.04  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Services using 100% CPU.
Description: Just upgraded to latest GIT. After starting services, I noticed that it is now using 100% CPU.

The configuration files were redone completely from scratch using examples provided.
Tags:
Steps To Reproduce: Upgrade to latest GIT.
Run Services.
Additional Information: Using the following modules:

-OperServ- Module: inspircd20 [1.9.9-gremlins-inside (g4c669b9)] [Protocol, Vendor]
-OperServ- Module: db_flatfile [1.9.9-gremlins-inside (g4c669b9)] [Database, Vendor]
-OperServ- Module: db_sql [1.9.9-gremlins-inside (g4c669b9)] [Database, Vendor]
-OperServ- Module: enc_none [1.9.9-gremlins-inside (g4c669b9)] [Encryption, Vendor]
-OperServ- Module: os_dns [1.9.9-gremlins-inside (g4c669b9)] [Vendor, Extra]
-OperServ- Module: m_dns [1.9.9-gremlins-inside (g4c669b9)] [Vendor, Extra]
-OperServ- Module: m_mysql [1.9.9-gremlins-inside (g4c669b9)] [Vendor, Extra]
-OperServ- Module: m_regex_pcre [1.9.9-gremlins-inside (g4c669b9)] [Vendor, Extra]
System Description
Attached Files:
Notes
(0006437)
Adam   
2013-05-06 12:41   
fixed in ef06226521d27de88a49a84d8224568fec7624c3
(0006436)
Adam   
2013-05-06 09:20   
Get --debug=3 and what OS/version?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1513 [Anope Development (1.9.x series)] Anope Languages minor always 2013-04-13 12:12 2013-05-05 07:04
Reporter: nikk Platform: x86_64  
Assigned To: Adam OS: Gentoo  
Priority: normal OS Version: 2.2  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Bug in language file (de_DE)
Description: Services shutting down if user does /cs help set or /os help kick for example
Tags:
Steps To Reproduce:
Additional Information: Parts of debug logfile
[Apr 12 19:05:01.556707 2013] Anope 1.9.9-gremlins-inside (gaa2844a) starting up (options: debug)

[...]

[Apr 12 19:05:34.923205 2013] Received: :644AAAAAB PRIVMSG 07KAAAAAB :help set
[Apr 12 19:05:34.923380 2013] Sent: :07KAAAAAB NOTICE 644AAAAAB :Syntax: ^Bset ^_option^_ ^_channel^_ ^_parameters^_^B
[Apr 12 19:05:34.923424 2013] Sent: :07KAAAAAB NOTICE 644AAAAAB :
[Apr 12 19:05:34.923474 2013] Sent: :07KAAAAAB NOTICE 644AAAAAB :Erlaubt es dem Raum-Gründer bestimmte Optionen
[Apr 12 19:05:34.923504 2013] Sent: :07KAAAAAB NOTICE 644AAAAAB :und Informationen des Channels zu ändern.
[Apr 12 19:05:34.923544 2013] Sent: :07KAAAAAB NOTICE 644AAAAAB :
Verfügbare Optionen:
[Apr 12 19:05:34.923617 2013] Sent: :07KAAAAAB NOTICE 644AAAAAB : SET AUTOOP Should services automatically give status to users
[Apr 12 19:05:34.923701 2013] Sent: :07KAAAAAB NOTICE 644AAAAAB : SET BANTYPE Set how Services make bans on the channel
[Apr 12 19:05:34.923754 2013] Sent: :07KAAAAAB NOTICE 644AAAAAB : SET DESC Set the channel description
[Apr 12 19:05:34.923817 2013] Sent: :07KAAAAAB NOTICE 644AAAAAB : SET DESCRIPTION Set the channel description
[Apr 12 19:05:34.923875 2013] Sent: :07KAAAAAB NOTICE 644AAAAAB : SET EMAIL Associate an E-mail address with the channel
[Apr 12 19:05:34.923929 2013] Sent: :07KAAAAAB NOTICE 644AAAAAB : SET FOUNDER Set the founder of a channel
[Apr 12 19:05:34.923981 2013] Sent: :07KAAAAAB NOTICE 644AAAAAB : SET KEEPTOPIC Retain topic when channel is not in use
[Apr 12 19:05:34.924030 2013] Sent: :07KAAAAAB NOTICE 644AAAAAB : SET PEACE Regulate the use of critical commands
[Apr 12 19:05:34.924081 2013] Sent: :07KAAAAAB NOTICE 644AAAAAB : SET PERSIST Set the channel as permanent
[Apr 12 19:05:34.924131 2013] Sent: :07KAAAAAB NOTICE 644AAAAAB : SET PRIVATE Hide channel from the LIST command
[Apr 12 19:05:34.924185 2013] Sent: :07KAAAAAB NOTICE 644AAAAAB : SET RESTRICTED Restrict access to the channel
[Apr 12 19:05:34.924239 2013] Sent: :07KAAAAAB NOTICE 644AAAAAB : SET SECURE Aktiviert Sicherheits-funktionen
[Apr 12 19:05:34.924293 2013] Sent: :07KAAAAAB NOTICE 644AAAAAB : SET SECUREFOUNDER Stricter control of channel founder status
[Apr 12 19:05:34.924344 2013] Sent: :07KAAAAAB NOTICE 644AAAAAB : SET SECUREOPS Stricter control of chanop status
[Apr 12 19:05:34.924395 2013] Sent: :07KAAAAAB NOTICE 644AAAAAB : SET SIGNKICK Sign kicks that are done with the KICK command
[Apr 12 19:05:34.924445 2013] Sent: :07KAAAAAB NOTICE 644AAAAAB : SET SUCCESSOR Set the successor for a channel
[Apr 12 19:05:34.924495 2013] Sent: :07KAAAAAB NOTICE 644AAAAAB : SET URL Associate a URL with the channel
[Apr 12 19:05:34.924543 2013] Sent: :07KAAAAAB NOTICE 644AAAAAB :Type ^B/msg ChanServ HELP set ^_option^_^B for more information on a
[Apr 12 19:05:34.924573 2013] Sent: :07KAAAAAB NOTICE 644AAAAAB :particular option.
[Apr 12 19:05:34.924915 2013] Received: :644 ERROR :Unrecognised command 'Verfügbare' -- possibly loaded mismatched modules
[Apr 12 19:05:34.924955 2013] ERROR: Unrecognised command 'Verfügbare' -- possibly loaded mismatched modules
[Apr 12 19:05:34.924999 2013] Received ERROR from uplink: Unrecognised command 'Verfügbare' -- possibly loaded mismatched modules
[Apr 12 19:05:34.925023 2013] Sent: :07KAAAAAD QUIT :Shutting down
Attached Files:
Notes
(0006432)
Adam   
2013-05-05 07:04   
This is fixed in e91de41278ff5993973999e4e5095360612ec056

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1511 [Anope Development (1.9.x series)] Chanserv tweak N/A 2013-04-12 12:26 2013-05-05 07:02
Reporter: webczat Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: chanserv/administration oper privilege description not clear
Description: Hello.
I've discovered that the description of chanserv/administration in the example config file still says that it allows using set, as I was told this is not true anymore.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006429)
Adam   
2013-05-05 07:02   
This is true once again

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1506 [Anope Development (1.9.x series)] MemoServ minor always 2013-04-11 19:35 2013-04-11 22:03
Reporter: CuttingEdge Platform: x86_64  
Assigned To: Adam OS: Ubuntu Linux  
Priority: normal OS Version: 12.10  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MemoServ RSEND confirmation message not showing target nickname.
Description: When using the MemoServ RSEND command, MemoServ does not return the target nickname in the confirmation message:

-MemoServ- Memo sent to memoserv/rsend.
Tags:
Steps To Reproduce: Send a memo to a user using MemoServ with a read-receipt (RSEND).
Additional Information: Using latest Anope 1.9.x GIT.
Using latest InspIRCd 2.2.x GIT.
System Description
Attached Files:
Notes
(0006426)
Adam   
2013-04-11 22:03   
https://github.com/anope/anope/commit/ac19a5c24bb11af3ef55292946ab25cc250aaeea

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1509 [Anope Development (1.9.x series)] Chanserv tweak N/A 2013-04-11 19:48 2013-04-11 22:03
Reporter: webczat Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: description for op/opme privilege
Description: Hello.
I've discovered that that when the opdeop and opdeoopme privilege names have changed to op/deop, the descriptions in access.cpp are not changed.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006425)
Adam   
2013-04-11 22:03   
https://github.com/anope/anope/commit/c56d72ba84f5524174582f4b71ff8d1e9c208471

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1510 [Anope Development (1.9.x series)] Chanserv minor N/A 2013-04-11 19:54 2013-04-11 22:02
Reporter: webczat Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: clarify custom prefixes
Description: Hello.

Could you please clarify in the example config the use of non-standard prefixes, like +qah in unreal/etc and inspircd, and inspircd custom prefixes?
It may seem confusing at times, like you have AUTOOWNER privilege and AUTOPROTECT privilege that work on all servers having +qa modes available, and they work on inspircd too, but if you will create custom prefixes then you must name them "founder" and "admin".
If you don't do it then you need to create custom privileges, the fun thing is that if you will create privileges named protect and owner, both names will also work.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006424)
Adam   
2013-04-11 22:02   
https://github.com/anope/anope/commit/416eaa1e667186e0f935b3d08e98090753114d34

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1503 [Anope Development (1.9.x series)] Other minor N/A 2013-04-07 01:01 2013-04-08 07:07
Reporter: webczat Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: logging
Description: Hello.

Not sure how this is to be done, but I think more things should be logged, like foundership transfers, set/saset, etc...
It may be important for opers wanting to track down something...
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006422)
Adam   
2013-04-08 07:07   
fixed in 7a2e6aa5c2703247008ddc0bfd67c8e678d08068

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1502 [Anope Development (1.9.x series)] Operserv minor always 2013-04-07 00:59 2013-04-08 07:06
Reporter: webczat Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: oper type info displayed incorrectly
Description: Hello.

I think that the opertype info incorrectly displays commands and privileges for the opertype in question.
I mean the command /os oper info <type>
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006421)
Adam   
2013-04-08 07:06   
fixed in bcd85ca68281b8f10d4357d6f7daeced4b79a9b4
(0006420)
webczat   
2013-04-07 10:24   
I've actually meant that the output of /os oper info <type> displays the oper commands and oper privileges.
Oper privileges are displayed correctly, but commands are not, they display commands coming from the opertype, and suddenly privileges that are also displayed in the privileges section.
Note that my opertype inherits from other opertypes.
An example:

[11:23] Powiadomienie od OperServ: Available commands for network_owner:
[11:23] Powiadomienie od OperServ: operserv/config operserv/ignore operserv/module operserv/reload operserv/shutdown operserv/oper chanserv/no-register-limit memoserv/set-limit nickserv/drop chanserv/access/modify chanserv/set nickserv/access chanserv/kick memoserv/no-limit nickserv/alist nickserv/confirm nickserv/auspex memoserv/info chanserv/auspex botserv/administration
[11:23] Powiadomienie od OperServ: Available privileges for network_owner:
[11:23] Powiadomienie od OperServ: chanserv/no-register-limit memoserv/set-limit nickserv/drop chanserv/access/modify chanserv/set nickserv/access chanserv/kick memoserv/no-limit nickserv/alist nickserv/confirm nickserv/auspex memoserv/info chanserv/auspex botserv/administration

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1504 [Anope Development (1.9.x series)] Chanserv minor always 2013-04-07 13:43 2013-04-07 13:43
Reporter: webczat Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: problems with the FOUNDER privilege
Description: Hello.

I'm not sure how the FOUNDER privilege is supposed to work, but:
the documentation says that users with the FOUNDER privilege are treated as founders and can execute founder commands.
It also says that if I'll set the level attribute of a privilege definition to founder, it will be applied to users with the FOUNDER privilege.
It seems, however, that privileges that have level set to founder are applied only to the real founder, I tested that with autoowner privilege.
My default configuration assigns the FOUNDER privilege to the access level 1000.
If all founder-only privileges are set to founder and the FOUNDER privilege is set to 1000, then the user with level 1000 has access to commands like drop and set founder and levels, but doesn't get other privileges that have level set to founder.
The only thing that works is assigning those founder privileges to level 1000.
I don't know if the example config is wrong about this, or if privilege checks don't take the FOUNDER privilege into account.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1501 [Anope Development (1.9.x series)] Chanserv major always 2013-04-06 19:58 2013-04-06 22:45
Reporter: webczat Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: set securefounder security
Description: Hello.
There is a security bug that does not check for founder access while doing /chanserv set securefounder, it only checks for set priv
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006419)
Adam   
2013-04-06 22:45   
fixed

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1500 [Anope Development (1.9.x series)] IRCD Support minor always 2013-04-06 19:51 2013-04-06 22:45
Reporter: webczat Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: not all modes are recognized by anope
Description: Hello.

Some modes in inspircd 2.0 cannot be used in anope like mlocked.
Those are some usermodes and channel modes +dDHX
The related log messages are attached in additional info.
Note that I didn't load all possible modules so there may be more modes
Tags:
Steps To Reproduce:
Additional Information: [kwi 06 19:49:10 2013] Unrecognized mode string in CAPAB CHANMODES: delaymsg=d
[kwi 06 19:49:10 2013] Unrecognized mode string in CAPAB CHANMODES: exemptchanops=X
[kwi 06 19:49:10 2013] Unrecognized mode string in CAPAB CHANMODES: history=H
[kwi 06 19:49:10 2013] Unrecognized mode string in CAPAB CHANMODES: namebase=Z
[kwi 06 19:49:10 2013] Unrecognized mode string in CAPAB USERMODES: antiredirect=L
[kwi 06 19:49:10 2013] Unrecognized mode string in CAPAB USERMODES: snomask=s
Attached Files:
Notes
(0006418)
Adam   
2013-04-06 22:45   
fixed

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1499 [Anope Development (1.9.x series)] IRCD Support minor always 2013-04-06 19:44 2013-04-06 22:45
Reporter: webczat Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: topiclock in inspircd doesn't work
Description: Hello.

serverside Topiclock in inspircd-2.0 does not work.
I've verified that the m_topiclock module is loaded and I'm sure that use_server_side_topiclock is set to yes, unless I've made a misspelling.
Setting a topic lock still allows topic to be changed, services revert the change as they should.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006417)
Adam   
2013-04-06 22:45   
fixed

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1498 [Anope Development (1.9.x series)] Chanserv minor always 2013-04-06 19:40 2013-04-06 22:45
Reporter: webczat Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: channel drop does not unset permanent mode +P
Description: I have a anope-1.9.8 running on my test network.
Chanserv is set to persist all channels by default by setting persist to on on registration.
I've verified that registering a channel sets +rP, but dropping it does not unset +P.
Clearing a persist option without channel drop properly -P's a channel.
I'm using inspircd.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006416)
Adam   
2013-04-06 22:45   
fixed

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1495 [Anope Development (1.9.x series)] Botserv minor always 2013-03-23 20:45 2013-03-30 06:53
Reporter: CuttingEdge Platform: x86_64  
Assigned To: Adam OS: Ubuntu Linux  
Priority: normal OS Version: 12.10  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: BotServ 'private' option not being saved (or applied) to database.
Description: When setting the 'private' option to any BotServ bot (including ChanServ, NickServ, etc), the setting is not being saved to the database (or made 'live').
Tags:
Steps To Reproduce: 1) Use: /msg BotServ set private ChanServ on
2) BotServ confirms that setting has been applied.
3) Use: /msg BotServ info ChanServ
4) No private option is displayed or set.
5) The 'oper_only' field in MySQL 'BotInfo' table remains '0' instead of '1'.
Additional Information: Using latest Anope 1.9.9 GIT.
Using 'flatfile' database with 'db_sql' as secondary.
System Description
Attached Files:
Notes
(0006414)
Adam   
2013-03-30 06:53   
fixed in f24e17f8b4a579666bae050d81585d42059e7513

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1494 [Anope Development (1.9.x series)] IRCD Support major always 2013-03-18 06:59 2013-03-18 19:19
Reporter: CuttingEdge Platform: x86_64  
Assigned To: Adam OS: Ubuntu Linux  
Priority: normal OS Version: 12.10  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Upstream timeout when using MySQL with flatfile database on boot.
Description: If I enable both the 'db_flatfile' and 'db_sql' modules on boot, Anope takes too long to run through its database tables, resulting in a timeout when trying to connect to its upstream server.

From what I can tell, it starts the connection to the upstream server first (it opens the socket, but doesn't send anything), then starts to generate tables, etc, and because it takes quite a while, the upstream server considers the incoming connection as not one being registered within the stipulated time frame, and disconnects the connection from Anope before it is able to complete the handshake.

It could just be the size of my database.

I'd suggest changing the sequence within Anope, so that only once all the tables are generated (and data propagated) in MySQL, that it attempt to connect to the upstream server.
Tags:
Steps To Reproduce: 1) Enable both 'db_flatfile' and 'db_sql' database modules.
2) Start Anope.
Additional Information: The disks on the machine are SSD drives, so it can't be a disk IO issue.

Using latest Anope 1.9.9 GIT.
Using InspIRCd 2.0.10.
System Description
Attached Files:
Notes
(0006406)
Adam   
2013-03-18 19:19   
The upstream timeout is actually intentional on large databases (it is trickier than waiting and opening the socket later). However, db_sql wasn't supposed to re-import everything on load if it is already imported. Because this should only possibly happen on the first import I don't think it's that big of a deal.

Your setup however makes it impossible to tell if things are already imported, so I've added a configuration option to tell db_sql whether or not to import stuff. If you keep imported at false now it will no longer re-import things on startup, and start much faster.

Fixed in 731912f01eb14d811575c492dc64b60084bd412c.

If you're going to keep reporting bugs like this you should really idle in irc.anope.org/#anope-devel, it can help.

Thanks

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1493 [Anope Development (1.9.x series)] Nickserv minor always 2013-03-16 12:15 2013-03-17 03:13
Reporter: CuttingEdge Platform: x86_64  
Assigned To: Adam OS: Ubuntu Linux  
Priority: normal OS Version: 12.10  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MySQL NickAlias duplicates
Description: Not too sure if this is a bug or not, but I'm seeing duplicate rows (besides the 'id', 'timestamp' and 'last_seen' fields) in the NickAlias table within MySQL. All the other data is identical. Am I not right in saying there should only be one unique 'nick' in the table?

The 'timestamp' offset between duplicate rows is approximately 30 minutes, so it may take a while to become apparent.
Tags:
Steps To Reproduce: 1) Load 'db_sql' while Anope is running concurrently to primary (flatfile) database module.
2) Allow time for duplicates to be created (seems to spawn every 30 minutes).
3) Use: select * from NickAlias where nc = 'nickname';
Additional Information: Using flatfile database as default. Loaded 'db_sql' concurrently to transfer data to MySQL for external (web) queries.

Using latest Anope 1.9.9 GIT.
System Description
Attached Files:
Notes
(0006405)
Adam   
2013-03-17 03:13   
The main issue here is the fact db_flatfile is what is loading objects on startup. It does not associate ids with objects, so when db_sql sees the id-less objects created it interprets them as being new objects.

This should be fixed in 810685cb739dc32690bd571492629293b4a0e1fd.

You will likely have to mass drop SQL and reimport.
(0006404)
CuttingEdge   
2013-03-16 13:52   
Tested NickServ AJOIN too. Looks like an entry is added to AJoinEntry when I add one via NickServ, but it isn't removed should I delete it almost afterwards.
(0006403)
CuttingEdge   
2013-03-16 13:24   
Seeing duplicates in ChannelInfo too. Only fields changed are the 'id' and 'timestamp' fields. Rest of the data is identical.

Surely the unique key should be the 'name' field? This will prevent such duplicates. Perhaps update the table instead of inserting a new row where the key (add 'name') is a duplicate?
(0006402)
CuttingEdge   
2013-03-16 13:03   
Seeing duplicates within ChanAccess too. Only fields changing are the 'timestamp' and 'last_seen' fields. Rest of the data is identical.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1492 [Anope Development (1.9.x series)] Nickserv minor always 2013-03-14 09:14 2013-03-15 19:33
Reporter: CuttingEdge Platform: x86_64  
Assigned To: Adam OS: Ubuntu Linux  
Priority: normal OS Version: 12.10  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: NickServ kill default not applied to new registrations
Description: The default 'kill' setting for new NickServ registrations is not applied to the database/user.
Tags:
Steps To Reproduce: 1) Register a new nickname using NickServ when the 'defaults' setting includes the 'kill' option.
2) Confirm NickServ registration where applicable.
3) Check: /msg NickServ info <nickname>
4) The 'kill' option is not present, even though its set as a default option in the configuration.
Additional Information: Using latest Anope 1.9.9 GIT with unencrypted 'flatfile' database.

In nickserv.conf (under 'nickserv'):

defaults="kill secure private hideemail hideusermask memo_signon memo_receive autoop"
System Description
Attached Files:
Notes
(0006401)
Adam   
2013-03-15 19:33   
thanks, fixed in 01620e849aece8ac8c2a8282788d7ea26a96b476
(0006400)
CuttingEdge   
2013-03-15 07:43   
Changing it to 'killprotect' seems to have done the trick. You may want to adjust the configuration examples to match, as they indicate that one needs to use 'kill'.

Thank you kindly!
(0006399)
Adam   
2013-03-14 14:28   
Change it to killprotect and it should work.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1490 [Anope Development (1.9.x series)] Chanserv minor always 2013-02-24 20:56 2013-02-25 03:22
Reporter: Anikwa Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: !down <nickname> doesnt work
Description: Using a fantasy command to remove +qo from a user who has access to the channel doesn't work.

Bug
=============================================
<Anikwa> !down Aletheia
-Hades- Channel #babble Aletheia doesn't exist.
Tags:
Steps To Reproduce: !down <nickname> if you're access is more or the same
Additional Information:
Attached Files:
Notes
(0006393)
Adam   
2013-02-25 03:22   
added in 5d4db2b85408202086ae35f38306e81f9216959e

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1489 [Anope Development (1.9.x series)] Chanserv major always 2013-02-21 18:05 2013-02-23 11:36
Reporter: ivan Platform: Linux  
Assigned To: Adam OS: Debian  
Priority: normal OS Version: 6  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Akick list does not show masks (blank)
Description: -ChanServ- Ackick list for #channel:
-ChanServ- Number Mask Reason
-ChanServ- 1
-ChanServ- 2
-ChanServ- 3
-ChanServ- 4
-ChanServ- End of Akick list
Tags:
Steps To Reproduce: /cs akick #channel list
Additional Information: Anope-1.9.8-may-cause-insanity services.mynetwork.org :InspIRCd 2.0 - (enc_md5) -- build 0000002, compiled 02:47:40 Feb 21 2013, flags D
Attached Files:
Notes
(0006388)
Adam   
2013-02-23 11:36   
fixed in c67087d750ad712779f7615ca0274a01ce475193

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1485 [Anope Development (1.9.x series)] Modules System minor always 2013-02-18 16:29 2013-02-19 08:27
Reporter: fgsch Platform:  
Assigned To: Adam OS: OpenBSD  
Priority: normal OS Version: 5.3  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: m_ssl cannot be built
Description: extra/m_ssl.cpp can not be built due to missing dependencies.




Tags:
Steps To Reproduce: Just try building it on OpenBSD
Additional Information: Fixed by removing crypt from /* RequiredLibraries: ssl,crypt */.
libcrypt does not exist on OpenBSD.
Attached Files:
Notes
(0006387)
Adam   
2013-02-19 08:27   
fixed in 7d50818ee1da97dcac0037d415047955c889d307

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1486 [Anope Development (1.9.x series)] Other minor always 2013-02-18 16:38 2013-02-19 08:27
Reporter: fgsch Platform:  
Assigned To: Adam OS: OpenBSD  
Priority: normal OS Version: 5.3  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Cannot build anope
Description: /usr/local/lib/libintl.so.6.0: undefined reference to `libiconv_set_relocation_prefix'
/usr/local/lib/libintl.so.6.0: undefined reference to `libiconv_open'
/usr/local/lib/libintl.so.6.0: undefined reference to `libiconv'
Tags:
Steps To Reproduce: Try to build it in OpenBSD
Additional Information: gettext requires iconv. I've modified cmake/FindGettext.cmake to also find/include iconv but I'm afraid this might be too intrusive for other OS.
Attached Files:
Notes
(0006386)
Adam   
2013-02-19 08:27   
fixed in 7d50818ee1da97dcac0037d415047955c889d307

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1487 [Anope Development (1.9.x series)] Other tweak N/A 2013-02-18 16:44 2013-02-19 08:27
Reporter: fgsch Platform:  
Assigned To: Adam OS:  
Priority: low OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Drop unneeded MAKE_DIRECTORY
Description: In language/CMakeLists.txt you could remove

install(CODE "FILE(MAKE_DIRECTORY \"${LOCALE_DIR}/${LANG_LANG}/LC_MESSAGES/\")")

as the install() below will create the destination and the above contructor does not support cmake's DESTDIR.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006385)
Adam   
2013-02-19 08:27   
fixed in 7d50818ee1da97dcac0037d415047955c889d307

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1482 [Anope Development (1.9.x series)] Other minor always 2013-02-16 09:32 2013-02-19 06:22
Reporter: nenolod Platform:  
Assigned To: DukePyrolator OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 1.9.x-GIT  
    Target Version:  
Summary: SASL support should authfail if the requested mechanism isn't implemented
Description: Requesting mechanisms like DH-BLOWFISH or ECDSA-NIST256P-CHALLENGE which are unsupported presently in Anope are instead interpreted to be the same as PLAIN.

They should, instead, authfail so that the client may properly fallback to PLAIN.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: anope-sasl-authfail.patch (1,710 bytes) 2013-02-16 23:42
https://bugs.anope.org/file_download.php?file_id=342&type=bug
Notes
(0006384)
DukePyrolator   
2013-02-19 06:22   
fixed in https://github.com/anope/anope/commit/d0e1f3b66a9bbee91bade0b57c3335908704c2e5
(0006383)
nenolod   
2013-02-18 02:29   
hello,

i typoed the patch, and it worked simply as a side effect of most SASL stacks not understanding the input given back by services.

the "C F" should be changed to "D F" to indicate "done" verb instead of "continue" verb. this will trigger a server-side abort instead of client-side abort.
(0006379)
DukePyrolator   
2013-02-17 13:30   
thanks for reporting :)

fixed in https://github.com/anope/anope/commit/bcf99d599862d8a7a6741b5f805c593fe7bf4aea0
(0006378)
nenolod   
2013-02-16 23:43   
Attached patch adds a check to ensure that the requested mechanism is PLAIN and fails the authentication request if it is not.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1479 [Anope Development (1.9.x series)] Chanserv minor always 2013-02-15 11:01 2013-02-17 22:19
Reporter: CuttingEdge Platform: x86_64  
Assigned To: Adam OS: Ubuntu Linux  
Priority: normal OS Version: 12.10  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Reboot of Issue 0001477
Description: Services reverts ChanServ access list after shutdown, even prior to running an /operserv update.
Tags:
Steps To Reproduce: Delete a user from channel access list.
Shutdown services via /operserv shutdown.
Start services.
View access list - the deleted user is back on the access list.
Additional Information: Using latest Anope 1.9.x GIT.
Using flatfile database without encryption.
System Description
Attached Files:
Notes
(0006381)
Adam   
2013-02-17 22:19   
This was fixed recently as cirinho said... going to close as resolved and assume you weren't really on the latest git head. Reopen if you can still reproduce on git HEAD.
(0006380)
cirinho   
2013-02-17 19:06   
This issue has been solved
25cec015e8276ea6e1de3e290696071fa5c0b66f
(0006367)
Adam   
2013-02-16 02:08   
I'm not able to reproduce this.
(0006365)
CuttingEdge   
2013-02-15 13:12   
In ~/services/conf/services.conf within the 'options' block:
user = "atrum"
group = "atrum"

~/services/data$ ps auwx | grep 'services'
atrum 23973 0.0 1.6 389296 33212 ? S 04:45 0:16 /home/atrum/services/bin/services
atrum 25819 0.0 0.0 9388 888 pts/0 R+ 11:10 0:00 grep --color=auto services

~/services/data$ ls -la
total 5700
drwxrwxr-x 5 atrum atrum 4096 Feb 15 11:09 .
drwxrwxr-x 8 atrum atrum 4096 Feb 14 11:08 ..
-rw------- 1 atrum atrum 5812855 Feb 15 11:09 anope.db
drwxrwxr-x 2 atrum atrum 4096 Feb 15 04:50 backups
drwxrwxr-x 3 atrum atrum 4096 Feb 14 11:08 modules
drwxrwxr-x 2 atrum atrum 4096 Feb 15 05:05 runtime

Using 'atrum' throughout.
(0006364)
jobe   
2013-02-15 12:44   
Well for this issue I'm going to ask:

1) what user are you running Anope as?
2) what does ls -la in Anope's data dir show?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1462 [Anope Development (1.9.x series)] MemoServ minor always 2012-12-22 08:24 2013-02-16 16:39
Reporter: CuttingEdge Platform:  
Assigned To: Adam OS:  
Priority: low OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Memo number variable not propagated in email message for new memo.
Description: In the mail message for new memo's, in example.conf/services.conf, the 'memo_message' variable within the 'mail' section has the following text:

"You've just received a new memo from %s. This is memo number %d."

The %d variable is empty within the mail received.
Tags:
Steps To Reproduce: Send a new memo to a nickname that has email notifications.
Additional Information: Using latest Anope 1.9.x from GIT.
Attached Files:
Notes
(0006309)
Adam   
2012-12-22 16:17   
Thanks, fixed in 0cde0aee34a658e8059106ee51641cac2f48d92a
(0006308)
CuttingEdge   
2012-12-22 08:30   
New (blank) lines (between paragraphs) aren't properly evaluated either. They're being trimmed/dropped from the output.
(0006307)
CuttingEdge   
2012-12-22 08:29   
The same can be said about the %N tag (network name). Its ignored completely (no text is replaced).

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1481 [Anope Development (1.9.x series)] Operserv minor random 2013-02-15 11:19 2013-02-16 11:01
Reporter: CuttingEdge Platform: x86_64  
Assigned To: Adam OS: Ubuntu Linux  
Priority: normal OS Version: 12.10  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: OperServ session limits triggered on incorrect concurrent connection numbers.
Description: OperServ's sessions are not always accurately triggering on concurrent connections for the same host.

Suspect there may be a callback or event thats not decrementing the counter for some hosts.
Tags:
Steps To Reproduce: Hard to reproduce. Does not always happen each time.
Additional Information: Using latest GIT version of Anope 1.9.x.
Using a flatfile database.
Session limits are currently set to 3.
System Description
Attached Files:
Notes
(0006373)
Adam   
2013-02-16 11:01   
Nevermind I've figured it out, fixed in 3ab6706993a50b7c65b9007ead7d13a9ce3010e6.
(0006372)
Adam   
2013-02-16 10:35   
What IRCd and version is this? Guessing InspIRCd, but my InspIRCd 2.0 sends back a QUIT when we send a KILL, it looks like you aren't getting a QUIT at all.
(0006371)
CuttingEdge   
2013-02-16 07:57   
I think it may be the KILL event/trigger not cleaning up behind itself:

[Feb 15 08:29:29 2013] Received: :1ZA UID 1ZAAAFBLL 1360916968 CTH 196-210-100-237.dynamic.isadsl.co.za atrum-bc41g4.isadsl.co.za chat27.co.za 196.210.100.237 1360916973 +ix :chat27.co.za
[Feb 15 08:29:29 2013] Sent: :1SVAAAAAG NOTICE 1ZAAAFBLL :The session limit for your host 196-210-100-237.dynamic.isadsl.co.za has been exceeded.
[Feb 15 08:29:29 2013] Sent: :1SVAAAAAG NOTICE 1ZAAAFBLL :Please contact us via support[at]atrum[dot]org for more information regarding session limits.
[Feb 15 08:29:29 2013] Sent: :1SVAAAAAG KILL 1ZAAAFBLL :OperServ (Session limit exceeded)
[Feb 15 08:29:38 2013] Received: :1ZA UID 1ZAAAFBLO 1360916977 CTH 196-210-100-237.dynamic.isadsl.co.za atrum-bc41g4.isadsl.co.za chat27.co.za 196.210.100.237 1360916982 +ix :chat27.co.za
[Feb 15 08:29:38 2013] Duplicate user CTH in user table?
(0006368)
Adam   
2013-02-16 02:08   
I'm not able to reproduce this.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1478 [Anope Development (1.9.x series)] Botserv feature always 2013-02-11 00:56 2013-02-16 07:43
Reporter: ivan Platform: Linux  
Assigned To: Adam OS: Debian  
Priority: normal OS Version: 6 x64  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Botservs don't get +ao modes on channels that already have Service Bots
Description: Botservs don't get +ao modes on channels that already have Service Bots
Tags:
Steps To Reproduce: Assuming OtherBotserv is a botserv created and assign to a certain channel and Global is a Global Message service bot

* Disconnected: OtherBotserv (services@vircio.org) (Shutting down)
* Disconnected: ~Global (services@vircio.org) (Shutting down)
* Joined: Global (services@vircio.org)
* Joined: OtherBotserv (services@vircio.org)
* OtherBotserv sets mode: +q Global

At this time, OtherBotserv works fine giving modes to othes bots or users, but don't get +ao modes.
Additional Information:
Attached Files:
Notes
(0006370)
Adam   
2013-02-16 07:43   
fixed in 7be23b7e374d343f60c4b698365719a3aba7f8f2
(0006369)
cirinho   
2013-02-16 02:41   
Anope-1.9.8-may-cause-insanity services.vircio.org :InspIRCd 2.0 - (enc_md5) -- build 0000002, compiled 21:34:08 Feb 15 2013, flags D

last commit from git
(0006363)
cronus   
2013-02-12 00:11   
I tried it two different ways. Giving the services config bot ~ and without. here are the results

[16:05:38] [RAW]: os restart
[16:05:38] <Global> [>> $hub.kratos.nite-serv.com] Services are restarting, they will be back shortly - please be good while we're gone
[16:05:38] Global [services@services.nite-serv.com] has quit IRC: Shutting down
[16:05:38] Keeper [Channel@Guard.Kamuix] has quit IRC: Shutting down
[16:05:39] Global [services@services.nite-serv.com] has joined #hangout
[16:05:39] Keeper [Channel@Guard.Kamuix] has joined #hangout
[16:05:39] <Global> [>> $hub.kratos.nite-serv.com] Services are now back online - have a nice day
[16:05:39] Keeper [Channel@Guard.Kamuix] has set mode +oa Keeper Keeper
[16:06:05] [RAW]: os restart
[16:06:05] <Global> [>> $hub.kratos.nite-serv.com] Services are restarting, they will be back shortly - please be good while we're gone
[16:06:05] Global [services@services.nite-serv.com] has quit IRC: Shutting down
[16:06:05] Keeper [Channel@Guard.Kamuix] has quit IRC: Shutting down
[16:06:06] Global [services@services.nite-serv.com] has joined #hangout
[16:06:06] Keeper [Channel@Guard.Kamuix] has joined #hangout
[16:06:06] <Global> [>> $hub.kratos.nite-serv.com] Services are now back online - have a nice day
[16:06:06] Keeper [Channel@Guard.Kamuix] has set mode +aoa Global Keeper Keeper
[16:06:06] Keeper [Channel@Guard.Kamuix] has set mode +aoa Global Keeper Keeper

As you see it works fine for me, I am using git from a week or so ago.

Please post the output of /version services.*

your config settings for Global Bot.

And what IRCd
(0006360)
Adam   
2013-02-11 05:01   
Not much, though it should always +ao (or whatever you set in the config) the bot assigned by BotServ.
(0006359)
ivan   
2013-02-11 03:26   
(Last edited: 2013-02-11 03:32)
I don't know what is wrong with my english.
I know we can't have more than one botserv bot in a channel at same time.
The thing is, Global is a Service bot configured on .conf files.
OtherBotserv bot is a regular botserv.

Anope doesn't make difference between them?

(0006358)
Adam   
2013-02-11 02:32   
Do you know anyone who speaks English who can explain this? You can't have more than one botserv bot in a channel at one time.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1480 [Anope Development (1.9.x series)] Operserv minor always 2013-02-15 11:06 2013-02-16 02:07
Reporter: CuttingEdge Platform: x86_64  
Assigned To: Adam OS: Ubuntu Linux  
Priority: normal OS Version: 12.10  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: OperServ DNS zone data disappearing after restart.
Description: The OperServ DNS zone information changes after restarting services. One server from each zone disappears.
Tags:
Steps To Reproduce: Add three (or more) servers to a DNS zone using: /operserv dns addserver servername zonename
View DNS information: /operserv dns
Restart services.
View DNS information: /operserv dns
You'll notice that one server from each zone is missing.

Additional Information: Using latest Anope 1.9.x.
Using flatfile database without encryption.
System Description
Attached Files:
Notes
(0006366)
Adam   
2013-02-16 02:07   
fixed in 73099b82e8619a87f894a0f787a582ee973bd177

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1475 [Anope Development (1.9.x series)] Nickserv minor always 2013-02-06 16:36 2013-02-10 05:48
Reporter: zysfryar Platform: *nix  
Assigned To: Adam OS: Ubuntu & BSD  
Priority: normal OS Version: multiple  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Nickserve List # does not work
Description: when doing /msg nickserv list #aa-ff comes back with error:
Incorrect range specified. The correct syntax is #from-to.


Tags:
Steps To Reproduce: /msg nickserv list 0000001-10

/msg nickserv list 0000005-10

/msg nickserv list 0000001-100

/msg nickserv list #0-10

/msg nickserv list 0000001-1000



Additional Information:
have tried many ranges (below my List max, and above, from 1-10, etc).

This was functioning in 1.9.7
Attached Files:
Notes
(0006357)
Adam   
2013-02-10 05:48   
fixed in 9b3ecfe777d38fffb50396350ec6f37fdfcfacd7. the range is supposed to be a number (like 0000050-100, not letters)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1474 [Anope Stable (1.8.x series)] IRCD support minor have not tried 2013-01-29 05:27 2013-01-29 12:15
Reporter: Magiobiwan Platform: Linux x86-64  
Assigned To: Adam OS: CentOS  
Priority: normal OS Version: 6.3 x86-64  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Anope 1.8.7 and Unreal IRCd 3.2.10 Link Issue
Description: It appears that something new in Unreal IRCd 3.2.10 has broken part of the link functionality in the Unreal 3.2 protocol in 1.8.7. More specifically relating to BotServ Bots. On Unreal 3.2.9, BotServ bots received usermodes +Sq, which they're supposed to. However, on Unreal 3.2.10, a /whois comes back with * [Bot] is using modes + . No modes. An Anope debug log shows the modes being sent (log in Additional information), but they don't show up in Unreal. Nickserv, Chanserv, etc. still receive their user modes, but BotServ bots do not.
Tags:
Steps To Reproduce: Link Anope 1.8.7 to Unreal 3.2.9, and observe the usermodes shown in a /whois. Then link to 3.2.10 and do a /whois again.
Additional Information: Mode being sent on link.
[Jan 29 04:46:31.172015 2013] debug: Sent: NICK Bot 1 1359423991 Bot services.unovarpgnet.net services.unovarpgnet.net 0 +qS services.unovarpgnet.net * :I'm a BOT! NOT A REAL PERSON!
Resulting /whois:
* [Bot] is using modes +
Attached Files:
Notes
(0006337)
Adam   
2013-01-29 12:15   
Fixed in 9650a3ffa578469bf1fa96c1cd7e6fe08d1a980f

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1473 [Anope Development (1.9.x series)] Operserv major always 2013-01-25 17:15 2013-01-27 07:51
Reporter: Nita Platform: x64  
Assigned To: Adam OS: Debian  
Priority: high OS Version: Squeeze  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Exception list does not added to the SQL database (GIT-devel)
Description: I would like to add a session exception to services via OperServ. It looks like that exception is added but it is gone when I restart services.

Version: current devel, 1.9, origin/1.9, ed7c4dc2e17a4616b0242d79ad80466970889fa0
Using: SQL Live
Tags:
Steps To Reproduce: /msg OperServ EXCEPTION LIST

/msg OperServ EXCEPTION ADD +0 0::1 8 Services
/msg OperServ EXCEPTION ADD +0 127.0.0.1 8 Services

/msg OperServ Update

Stop services process and restart it.

/msg OperServ EXCEPTION LIST
Additional Information: [Jan 25 15:00:04.777926 2013] Debug: Received: :001AAAAAQ PRIVMSG 002AAAAAG :exception list
[Jan 25 15:00:04.778467 2013] Debug: SQL-live got 0 rows for SELECT * FROM `svs_BotInfo` WHERE (`timestamp` > FROM_UNIXTIME(1359125996) OR `timestamp` IS NULL)
[Jan 25 15:00:04.778818 2013] Debug: SQL-live got 0 rows for SELECT * FROM `svs_NickCore` WHERE (`timestamp` > FROM_UNIXTIME(1359125996) OR `timestamp` IS NULL)
[Jan 25 15:00:04.779048 2013] Debug: Sent: :002AAAAAG NOTICE 001AAAAAQ :The session exception list is empty.
[Jan 25 15:00:46.832710 2013] Debug: Received: :001AAAAAQ PRIVMSG 002AAAAAG :EXCEPTION ADD +0 0::1 10 Services
[Jan 25 15:00:46.833242 2013] Debug: SQL-live got 0 rows for SELECT * FROM `svs_BotInfo` WHERE (`timestamp` > FROM_UNIXTIME(1359126004) OR `timestamp` IS NULL)
[Jan 25 15:00:46.833561 2013] Debug: SQL-live got 0 rows for SELECT * FROM `svs_NickCore` WHERE (`timestamp` > FROM_UNIXTIME(1359126004) OR `timestamp` IS NULL)
[Jan 25 15:00:46.833835 2013] Debug: Sent: :002AAAAAG NOTICE 001AAAAAQ :Session limit for 0::1 set to 10.
[Jan 25 15:00:46.834018 2013] Debug: m_mysql: Fetching columns for svs_Exception
[Jan 25 15:00:46.834683 2013] Debug: m_mysql: Column #0 for svs_Exception: id
[Jan 25 15:00:46.834722 2013] Debug: m_mysql: Column 0000001 for svs_Exception: timestamp
[Jan 25 15:00:46.834752 2013] Debug: m_mysql: Column 0000002 for svs_Exception: expires
[Jan 25 15:00:46.834779 2013] Debug: m_mysql: Column 0000003 for svs_Exception: limit
[Jan 25 15:00:46.834807 2013] Debug: m_mysql: Column 0000004 for svs_Exception: mask
[Jan 25 15:00:46.834835 2013] Debug: m_mysql: Column 0000005 for svs_Exception: reason
[Jan 25 15:00:46.834862 2013] Debug: m_mysql: Column 0000006 for svs_Exception: time
[Jan 25 15:00:46.834889 2013] Debug: m_mysql: Column 0000007 for svs_Exception: who
[Jan 25 15:00:46.841599 2013] Debug: SQL-live got 0 rows for INSERT INTO `svs_Exception` (`id`,`expires`,`limit`,`mask`,`reason`,`time`,`who`) VALUES (0,'0','10','0::1','Services','1359126046','Anita') ON DUPLICATE KEY UPDATE `expires`=VALUES(`expires`),`limit`=VALUES(`limit`),`mask`=VALUES(`mask`),`reason`=VALUES(`reason`),`time`=VALUES(`time`),`who`=VALUES(`who`)
[Jan 25 15:00:46.857724 2013] Debug: Received: :001AAAAAQ PRIVMSG 002AAAAAG :EXCEPTION ADD +0 127.0.0.1 10 Services
[Jan 25 15:00:46.858275 2013] Debug: Sent: :002AAAAAG NOTICE 001AAAAAQ :Session limit for 127.0.0.1 set to 10.
[Jan 25 15:00:46.858925 2013] Debug: SQL-live got 0 rows for INSERT INTO `svs_Exception` (`id`,`expires`,`limit`,`mask`,`reason`,`time`,`who`) VALUES (0,'0','10','127.0.0.1','Services','1359126046','Anita') ON DUPLICATE KEY UPDATE `expires`=VALUES(`expires`),`limit`=VALUES(`limit`),`mask`=VALUES(`mask`),`reason`=VALUES(`reason`),`time`=VALUES(`time`),`who`=VALUES(`who`)

RESTARTING SERVICES...

[Jan 25 15:02:27.851483 2013] Debug: Sent: :002AAAAAG NOTICE 001AAAAAQ :Password accepted.
[Jan 25 15:02:41.175975 2013] Debug: Received: :001AAAAAQ PRIVMSG 002AAAAAG :exception list
[Jan 25 15:02:41.176719 2013] Debug: SQL-live got 0 rows for SELECT * FROM `svs_BotInfo` WHERE (`timestamp` > FROM_UNIXTIME(1359126147) OR `timestamp` IS NULL)
[Jan 25 15:02:41.177182 2013] Debug: SQL-live got 0 rows for SELECT * FROM `svs_NickCore` WHERE (`timestamp` > FROM_UNIXTIME(1359126147) OR `timestamp` IS NULL)
[Jan 25 15:02:41.177535 2013] Debug: Sent: :002AAAAAG NOTICE 001AAAAAQ :The session exception list is empty.
Attached Files:
Notes
(0006336)
Adam   
2013-01-27 07:51   
fixed in 50a42d2cbf2ff00ecab6bd432e88c8ca17a47219

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1472 [Anope Development (1.9.x series)] Other major always 2013-01-25 17:11 2013-01-27 07:51
Reporter: Nita Platform: x64  
Assigned To: Adam OS: Debian  
Priority: immediate OS Version: Squeeze  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Services akick-ing every user when joining a channel (GIT-devel)
Description: Servces AKick-ing every user when joining a channel. Version: current devel, 1.9, origin/1.9, ed7c4dc2e17a4616b0242d79ad80466970889fa0
Using: SQL Live
Tags:
Steps To Reproduce: /join #Test
(Have a bot, called robot in Test channel)
Additional Information: [Jan 25 14:52:39.744020 2013] Debug: Received: :001 FJOIN #Test 1359116501 +nrt ,001AAAAAA
[Jan 25 14:52:39.745038 2013] Debug: SQL-live got 0 rows for SELECT * FROM `svs_ChannelInfo` WHERE (`timestamp` > FROM_UNIXTIME(1359125541) OR `timestamp` IS NULL)
[Jan 25 14:52:39.745103 2013] Debug: o1.irc is setting #Test to +nrt
[Jan 25 14:52:39.745427 2013] Debug: SQL-live got 0 rows for SELECT * FROM `svs_ModeLock` WHERE (`timestamp` > FROM_UNIXTIME(1359125541) OR `timestamp` IS NULL)
[Jan 25 14:52:39.745507 2013] CHANNEL: Anita!~Anita@0::1 join #Test
[Jan 25 14:52:39.745530 2013] Debug: Setting correct user modes for Anita on #Test (giving modes)
[Jan 25 14:52:39.745850 2013] Debug: SQL-live got 0 rows for SELECT * FROM `svs_NickAlias` WHERE (`timestamp` > FROM_UNIXTIME(1359125541) OR `timestamp` IS NULL)
[Jan 25 14:52:39.746608 2013] Debug: SQL-live got 0 rows for SELECT * FROM `svs_NickCore` WHERE (`timestamp` > FROM_UNIXTIME(1359125541) OR `timestamp` IS NULL)
[Jan 25 14:52:39.746947 2013] Debug: SQL-live got 0 rows for SELECT * FROM `svs_ChanAccess` WHERE (`timestamp` > FROM_UNIXTIME(1359125541) OR `timestamp` IS NULL)
[Jan 25 14:52:39.747716 2013] Debug: SQL-live got 0 rows for SELECT * FROM `svs_AutoKick` WHERE (`timestamp` > FROM_UNIXTIME(1359125541) OR `timestamp` IS NULL)
[Jan 25 14:52:39.748348 2013] Debug: Autokicking Anita1 (*!*@nita-e2vn61.j5lv.76hk.mfvttn.IP) from #Test
[Jan 25 14:52:39.748642 2013] Debug: SQL-live got 0 rows for SELECT * FROM `svs_BotInfo` WHERE (`timestamp` > FROM_UNIXTIME(1359125541) OR `timestamp` IS NULL)
[Jan 25 14:52:39.748732 2013] Debug: Sent: :002AAAAAH KICK #Test 001AAAAAA :You are not permitted to be on this channel.
[Jan 25 14:52:39.748774 2013] CHANNEL: robot!services@services.hu kick #Test kicked Anita (You are not permitted to be on this channel.)
[Jan 25 14:52:39.748849 2013] CHANNEL: Anita!~Anita@0::1 leaves #Test
[Jan 25 14:52:39.749783 2013] Debug: Sent: :002AAAAAH FMODE #Test 1359116501 +b *!*@nita-e2vn61.j5lv.76hk.mfvttn.IP
[Jan 25 14:52:39.749914 2013] Debug: Chanstats: Error executing query CALL stat_chanstats_proc_update('#Test', '', 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0);: Table 'services.stat_chanstats' doesn't exist
[Jan 25 14:52:39.749959 2013] Debug: Chanstats: Error executing query CALL stat_chanstats_proc_update('#Test', '', 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0);: Table 'services.stat_chanstats' doesn't exist
Attached Files:
Notes
(0006335)
Adam   
2013-01-27 07:51   
fixed in 49cb6a07a2637925da01fb4e68c1c70c59912193
(0006334)
Nita   
2013-01-25 21:05   
It seems that channels are always RESTRICTED after service restart. See below:

/msg ChanServ SET RESTRICTED #Test OFF

After that channel is not restricted, everything looks good, but when I restart services process, it seems that everything is messed up and I have to type it again:

/msg ChanServ SET RESTRICTED #Test OFF
(0006332)
Nita   
2013-01-25 17:15   
Channel is not restricted.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1465 [Anope Development (1.9.x series)] Operserv minor always 2012-12-31 12:34 2013-01-25 11:07
Reporter: chaz Platform: x86_64  
Assigned To: Adam OS: CentOS  
Priority: high OS Version: 6.3  
Status: resolved Product Version: 1.9.x-GIT  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.9.x-GIT  
Summary: Akill not defaulting to days
Description: Akills set with eg. +10 are interpretted as +0 not 10 days.




Tags:
Steps To Reproduce: /os akill add +10 test@test.com test

GLOBOPS: From OperServ: ADMIN: chaz!chaz@x used akill on test@Test.com (test) expires in never [affects 0 user(s) (0%)]

                             11 test@Test.com chaz Dec 31 11:31:16 2012 CET does not expire test
Additional Information:
Attached Files:
Notes
(0006330)
Adam   
2013-01-25 11:07   
fixed in ed7c4dc2e17a4616b0242d79ad80466970889fa0

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1468 [Anope Development (1.9.x series)] MemoServ minor always 2013-01-13 08:13 2013-01-25 10:33
Reporter: CuttingEdge Platform:  
Assigned To: Adam OS: Ubuntu Linux  
Priority: normal OS Version: 12.10  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MemoServ displays 'new memo' notification twice when using MySQL database.
Description: If one sends a memo, when services is configured to use a MySQL database (no flatfile), the notification about a new memo is sent twice to the recepient:

-MemoServ- You have a new memo from CuttingEdge.
-MemoServ- Type /msg MemoServ READ 4 to read it.
-MemoServ- You have a new memo from CuttingEdge.
-MemoServ- Type /msg MemoServ READ 4 to read it.
Tags:
Steps To Reproduce: 1) Use MySQL database (instead of flatfile).
2) Send a new memo.
Additional Information: Using MySQL database backend on latest Anope 1.9.x.

This may be related to this forum post:
http://forum.anope.org/index.php?topic=3898.0
Attached Files:
Notes
(0006329)
Adam   
2013-01-25 10:33   
I believe this is fixed in 76d9e58ae59ca99452ebaeedef661d0f82fc7104. Repoen if you can still reproduce.
(0006328)
Adam   
2013-01-24 15:45   
Oh, actually the documentation is right, I wasn't remembering correctly.

Try loading *just* db_flatfile and db_sql to do the initial import, then shutting down and going to *just* db_sql_live.

I'm trying to reproduce this now using the steps you gave and it appears okay.

If you could come to irc.anope.org/#anope sometime I could assist you in debugging this.
(0006327)
CuttingEdge   
2013-01-24 15:15   
In the documentation (in services.conf) it says:

"This module should not be loaded in conjunction with db_sql, except during the initial import of existing databases to SQL."

Thats the only time I use them both. Once everything is imported over, I only run the db_sql_live module (not even the db_flatfile one).

If I only use the db_sql_live with db_flatfile initially, it doesn't create any tables in the database whatsoever. Is this correct? Is the order or sequence I'm loading them in, affecting this? The db_flatfile module is loaded before the db_sql_live one.
(0006326)
Adam   
2013-01-24 13:09   
Your step 5:

5) Enabled the db_flatfile, db_sql and db_sql_live modules in services.conf.

You aren't supposed to load both db_sql and db_sql_live at one time. I'm not sure what happens when you do (I should probably make them fail to load if the other is loaded).

Can you reproduce it by only loading db_sql_live and not db_sql?
(0006325)
CuttingEdge   
2013-01-24 11:35   
(Last edited: 2013-01-24 11:36)
Some logs that I think are relative:

[Jan 24 11:21:21 2013] m_mysql: Fetching columns for Memo
[Jan 24 11:21:21 2013] m_mysql: Column #0 for Memo: id
[Jan 24 11:21:21 2013] m_mysql: Column 0000001 for Memo: timestamp
[Jan 24 11:21:21 2013] m_mysql: Column 0000002 for Memo: flags
[Jan 24 11:21:21 2013] m_mysql: Column 0000003 for Memo: owner
[Jan 24 11:21:21 2013] m_mysql: Column 0000004 for Memo: sender
[Jan 24 11:21:21 2013] m_mysql: Column 0000005 for Memo: text
[Jan 24 11:21:21 2013] m_mysql: Column 0000006 for Memo: time
[Jan 24 11:21:21 2013] SQL-live got 0 rows for INSERT INTO `Memo` (`id`,`flags`,`owner`,`sender`,`text`,`time`) VALUES (5958,'MF_UNREAD','','CuttingEdge','moo','1359018859') ON DUPLICATE KEY UPDATE `flags`=VALUES(`flags`),`owner`=VALUES(`owner`),`sender`=VALUES(`sender`),`text`=VALUES(`text`),`time`=VALUES(`time`)
[Jan 24 11:21:21 2013] Sent: :1SVAAAAAB FMODE #atrum-services 1359019279 +vvvvvvvr 1SVAAAAAA 1SVAAAAAB 1SVAAAAAC 1SVAAAAAD 1SVAAAAAE 1SVAAAAAF 1SVAAAAAG
[Jan 24 11:24:28 2013] Received: :9ZAAAAAFV PRIVMSG 1SVAAAAAE :list
[Jan 24 11:24:28 2013] SQL-live got 3 rows for SELECT * FROM `BotInfo` WHERE (`timestamp` > FROM_UNIXTIME(1359019280) OR `timestamp` IS NULL)
[Jan 24 11:24:28 2013] SQL-live got 0 rows for SELECT * FROM `NickCore` WHERE (`timestamp` > FROM_UNIXTIME(1359019280) OR `timestamp` IS NULL)
[Jan 24 11:24:28 2013] SQL-live got 1 rows for SELECT * FROM `Memo` WHERE (`timestamp` > FROM_UNIXTIME(1359019280) OR `timestamp` IS NULL)
[Jan 24 11:24:28 2013] SQL-live got 0 rows for SELECT * FROM `NickAlias` WHERE (`timestamp` > FROM_UNIXTIME(1359019280) OR `timestamp` IS NULL)
[Jan 24 11:24:29 2013] SQL-live got 0 rows for DELETE FROM `Memo` WHERE `id` = 5958

After this point, services splits and the process dies. Bare in mind, that my nickname still shows twice in '/nickserv glist'.

EDIT: To successfully reproduce this crash (every time), I have to send myself a memo, stop services, restart it and do a '/memoserv list'.

(0006324)
CuttingEdge   
2013-01-24 10:34   
Something else to note, is that after restarting services a second time (after the memo's were cleared, and services crashed), given enough time, the same set of events occur (services clears out the memos), but this time round, doesn't crash and becomes completely unresponsive instead.

Services eventually splits, with a timeout. The actual process is still running - I have to terminate it by hand in order to restart it.
(0006323)
CuttingEdge   
2013-01-24 09:50   
Redid the database from scratch, from a copy of the LIVE database, and ran into the same issue.

Followed the following procedure:

1) Shutdown the TEST set of services.
2) Dropped the database completely from MySQL.
3) Recreated a blank database.
4) Copied the anope.db file from the LIVE network.
5) Enabled the db_flatfile, db_sql and db_sql_live modules in services.conf.
6) Restarted the TEST set of services.
7) Gave Anope time to completely finish creating tables and copying the data over to MySQL.
8) Shutdown the TEST set of services.
9) Commented out the db_flatfile and db_sql modules from services.conf.
10) Restarted the TEST set of services.
11) Noticed that services runs through all the memos, then proceeds to delete them all.
12) Services crashes with no error after the last memo is deleted.
13) Confirmed that the Memo table is now empty.
14) Restarted the TEST set of services.
15) Confirmed that there were no memo's available for my user (/memoserv list).
16) Sent myself a memo - received the confirmation twice (as before).
17) Confirmed my nickname as being listed twice in /nickserv glist.

Hope this helps. The database on every occation hasn't been altered or manipulated externally.
(0006322)
Adam   
2013-01-24 08:46   
I think it is more likely you edited the database externally and messed up something.

If you can reproduce it using Anope and nothing external that would be the real bug.
(0006321)
CuttingEdge   
2013-01-24 08:27   
(Last edited: 2013-01-24 08:29)
I think you hit the nail on the head.

It looks like CuttingEdge is listed twice in the GLIST output from NickServ. Not too sure how that happened. May have been from the initial MySQL importation perhaps?

EDIT: On the non-MySQL version of Anope, there only appears one. (I have two concurrent versions running - one for the live network, the other (MySQL) for test).

(0006320)
Adam   
2013-01-23 10:00   
Can you get the output of /ns glist on the target nick?
(0006319)
CuttingEdge   
2013-01-23 07:56   
[Jan 23 07:55:13 2013] Received: :9ZAAAAAFR PRIVMSG 1SVAAAAAE :send CuttingEdge moo
[Jan 23 07:55:13 2013] SQL-live got 0 rows for SELECT * FROM `BotInfo` WHERE (`timestamp` > FROM_UNIXTIME(1358920461) OR `timestamp` IS NULL)
[Jan 23 07:55:13 2013] SQL-live got 0 rows for SELECT * FROM `NickCore` WHERE (`timestamp` > FROM_UNIXTIME(1358920481) OR `timestamp` IS NULL)
[Jan 23 07:55:13 2013] SQL-live got 0 rows for SELECT * FROM `NickAlias` WHERE (`timestamp` > FROM_UNIXTIME(1358920481) OR `timestamp` IS NULL)
[Jan 23 07:55:13 2013] SQL-live got 0 rows for SELECT * FROM `Memo` WHERE (`timestamp` > FROM_UNIXTIME(1358920460) OR `timestamp` IS NULL)
[Jan 23 07:55:13 2013] Sent: :1SVAAAAAE NOTICE 9ZAAAAAFR :You have a new memo from CuttingEdge.
[Jan 23 07:55:13 2013] Sent: :1SVAAAAAE NOTICE 9ZAAAAAFR :Type /msg MemoServ READ 5 to read it.
[Jan 23 07:55:13 2013] Sent: :1SVAAAAAE NOTICE 9ZAAAAAFR :You have a new memo from CuttingEdge.
[Jan 23 07:55:13 2013] Sent: :1SVAAAAAE NOTICE 9ZAAAAAFR :Type /msg MemoServ READ 5 to read it.
[Jan 23 07:55:13 2013] Sent: :1SVAAAAAE NOTICE 9ZAAAAAFR :Memo sent to CuttingEdge.
[Jan 23 07:55:13 2013] SQL-live got 0 rows for INSERT INTO `Memo` (`id`,`flags`,`owner`,`sender`,`text`,`time`) VALUES (0,'MF_UNREAD','CuttingEdge','CuttingEdge','moo','1358920513') ON DUPLICATE KEY UPDATE `flags`=VALUES(`flags`),`owner`=VALUES(`owner`),`sender`=VALUES(`sender`),`text`=VALUES(`text`),`time`=VALUES(`time`)
[Jan 23 07:55:13 2013] Successfully delivered mail for CuttingEdge (cuttingedge@atrum.org)
[Jan 23 07:55:13 2013] Sent: :1SVAAAAAC PRIVMSG #atrum-services :Successfully delivered mail for CuttingEdge (cuttingedge@atrum.org)
(0006318)
Adam   
2013-01-22 04:36   
Can you get debug logs of this? I'm unable to reproduce:

[Jan 21 21:35:31.499936 2013] Debug: Received: :Adam PRIVMSG MemoServ@services.rizon.net :send adam- moo
[Jan 21 21:35:31.500576 2013] Debug: SQL-live got 0 rows for SELECT * FROM `anope_db_BotInfo` WHERE (`timestamp` > FROM_UNIXTIME(1358822127) OR `timestamp` IS NULL)
[Jan 21 21:35:31.501032 2013] Debug: SQL-live got 0 rows for SELECT * FROM `anope_db_NickCore` WHERE (`timestamp` > FROM_UNIXTIME(1358822127) OR `timestamp` IS NULL)
[Jan 21 21:35:31.501513 2013] Debug: SQL-live got 0 rows for SELECT * FROM `anope_db_NickAlias` WHERE (`timestamp` > FROM_UNIXTIME(1358822127) OR `timestamp` IS NULL)
[Jan 21 21:35:31.501943 2013] Debug: SQL-live got 0 rows for SELECT * FROM `anope_db_Memo` WHERE (`timestamp` > FROM_UNIXTIME(1358821567) OR `timestamp` IS NULL)
[Jan 21 21:35:31.502140 2013] Debug: Sent: :00AAAAAAE NOTICE 00CAAAAAB :You have a new memo from Adam.
[Jan 21 21:35:31.502206 2013] Debug: Sent: :00AAAAAAE NOTICE 00CAAAAAB :Type /msg MemoServ READ 1 to read it.
[Jan 21 21:35:31.502360 2013] Debug: Sent: :00AAAAAAE NOTICE 00CAAAAAA :Memo sent to adam-.
[Jan 21 21:35:31.503257 2013] Debug: SQL-live got 0 rows for INSERT INTO `anope_db_Memo` (`id`,`flags`,`owner`,`sender`,`text`,`time`) VALUES (0,'MF_UNREAD','adam-','Adam','moo','1358822131') ON DUPLICATE KEY UPDATE `flags`=VALUES(`flags`),`owner`=VALUES(`owner`),`sender`=VALUES(`sender`),`text`=VALUES(`text`),`time`=VALUES(`time`)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1469 [Anope Development (1.9.x series)] Other minor have not tried 2013-01-25 01:08 2013-01-25 10:32
Reporter: DrStein Platform:  
Assigned To: Adam OS: BSD  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: kqueue issue in 1.9
Description: An user (fgsch) reported this issue on the #anope channel:

<fgsch> git code doesn't compile for me
<fgsch> the kqueue engine calls HasFlags and UnsetFlags that I take are leftovers from
              the past

<fgsch> https://github.com/anope/anope/commit/a634c7be65113c74736be0fb98f31b0c83ec2882
<fgsch> basically that's missing in the kqueue engine
Tags:
Steps To Reproduce: Compile Anope 1.9 on BSD (kqueue found by ./Config)
Additional Information: A patch (sort of) has been provided:

<fgsch> http://www.pastebin.ca/2306997
<fgsch> it compiles, untested otherwise yet
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1463 [Anope Development (1.9.x series)] Modules System crash have not tried 2012-12-25 18:10 2012-12-25 23:47
Reporter: CuttingEdge Platform:  
Assigned To: Adam OS:  
Priority: high OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash on unload and reload of OperServ DNS module.
Description: Services crashes/disconnects after module reload and commands sent to add zones/servers/IP addresses to OperServ DNS module.
Tags:
Steps To Reproduce: 1) Unload os_dns.
2) Reload os_dns.
3) Readd servers to configuration (they are not displayed, or shown after the reload).
4) Anope crashes, disconnects from network during a database save:

[Dec 25 17:50:00 2012] Saving databases
[Dec 25 17:50:00 2012] bs_main: Running bandata purger
[Dec 25 17:50:00 2012] DB_FLATFILE: Error saving databases: Unable to write database data/anope.db
[Dec 25 17:50:00 2012] Terminating, reason unknown
Additional Information: I have a sneaky suspicion that the settings are not reloaded (from the database) on module reload. The module is probably trying to write settings that exist?

Using latest Anope 1.9.x GIT.
Attached Files:
Notes
(0006311)
Adam   
2012-12-25 23:47   
fixed in 556a4375e226760169150179b5bcaa659aaf055e and 392b591d09509ae788f59b1b63a947ed7d8ad562
(0006310)
CuttingEdge   
2012-12-25 18:11   
Something else to note, is that the OperServ DNS module does not write to MySQL databases if the database type is of MySQL (everything else does).

The above crash was done on a flatfile database though.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1444 [Anope Stable (1.8.x series)] Modules major N/A 2012-09-16 17:07 2012-11-30 10:58
Reporter: KnopeX Platform:  
Assigned To: Adam OS: Windows 7  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: cs_accessfounder.dll for Anope 1.8.7 and 1.8.6 filesize are 0 bytes
Description: Self explained.

Next to this stands (Unsupported Auto Build) but why is it there when the filesize are 0 bytes?
Tags:
Steps To Reproduce:
Additional Information: http://modules.anope.org/index.php?page=view&id=32

Section v4.1
Attached Files:
Notes
(0006306)
Adam   
2012-11-30 10:58   
This was fixed (by us manually uploading a fixed build).

This module actually doesn't build correctly under Windows which is why the autobuilder choked on it.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1461 [Anope Development (1.9.x series)] Nickserv minor always 2012-11-11 22:38 2012-11-30 10:55
Reporter: ObiWan Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ldap_authentication: More than one password possible
Description: I've just noticed that when using the ldap authentication module it is possible to use the "old" password from the nickserv database and to use the "new" password from the ldap directory as you wish.

I think when enabling ldap authentication all tasks such as password change, registration, authentication etc. should just stick to the ldap module.
Tags:
Steps To Reproduce: 1. Have a database with existing users such as "tester" and a password "Start123".
2. Have a ldap directory with the user "tester" and the password "test123".
3. Both passwords would work on /msg nickserv identify...
Additional Information:
Attached Files:
Notes
(0006304)
Adam   
2012-11-30 10:55   
thanks, fixed in a4468dd56e96ea915d40627f3cb067084238e34a
(0006303)
ObiWan   
2012-11-11 23:01   
Ah ok. I understand. Well actually it sounds sensible. Would be some kind of a fallback password if the ldap server is offline.
(0006302)
Adam   
2012-11-11 22:52   
This was intentional. Instead, I need to make it so if you don't want the "old" nickserv password to work you should unload the encryption modules.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1459 [Anope Development (1.9.x series)] Chanserv minor always 2012-11-02 20:08 2012-11-10 02:24
Reporter: Raphael Platform: 64x  
Assigned To: Adam OS: Linux  
Priority: normal OS Version: Ubuntu 12.10  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ChanServ Access ADD/LIST/DEL adding hostname
Description: To add:
/chanserv access #xatneorotico add maay_lock 3
Show:
(13:53:21) -ChanServ- *!*@7fa4k5.telesp.net.br adicionado r lista de acesso do #xatneorotico com o nível 3.



To list:
(13:52:31) -ChanServ- Access list for #xatneorotico:
(13:52:31) -ChanServ- Number Level Mask
(13:52:31) -ChanServ- 1 9999 mc-alex
(13:52:31) -ChanServ- 2 3 *!*@38t.8j5.102.177.IP
(13:52:31) -ChanServ- 3 3 *!*@4u0daj.veloxzone.com.br
(13:52:31) -ChanServ- 4 3 *!*@lq7.l3a.166.200.IP
(13:52:31) -ChanServ- 5 3 *!*@56k.iju.113.177.IP
(13:52:31) -ChanServ- 6 3 gustavo
(13:52:31) -ChanServ- 7 3 gustavo^^
(13:52:31) -ChanServ- 8 3 *!*@n8s3dt.veloxzone.com.br
(13:52:31) -ChanServ- 9 3 *!*@cqorc6.telesp.net.br
(13:52:31) -ChanServ- 10 3 *!*@ceq.4b7.10.201.IP
(13:52:31) -ChanServ- 11 3 *!*@7fa4k5.telesp.net.br



To remove:
/chanserv access #xatneorotico del Maay_Lock
Show:
(13:53:56) -ChanServ- maay_lock nao foi encontrado na lista de acesso do #xatneorotico. (not found)



To remove:
/chanserv access #xatneorotico del *!*@7fa4k5.telesp.net.br
Show:
(13:54:05) -ChanServ- *!*@7fa4k5.telesp.net.br removido da lista de acesso do #xatneorotico. (removed successfuly)
Tags:
Steps To Reproduce: To add:
/chanserv access #xatneorotico add maay_lock 3
Show:
(13:53:21) -ChanServ- *!*@7fa4k5.telesp.net.br adicionado r lista de acesso do #xatneorotico com o nível 3.



To list:
(13:52:31) -ChanServ- Access list for #xatneorotico:
(13:52:31) -ChanServ- Number Level Mask
(13:52:31) -ChanServ- 1 9999 mc-alex
(13:52:31) -ChanServ- 2 3 *!*@38t.8j5.102.177.IP
(13:52:31) -ChanServ- 3 3 *!*@4u0daj.veloxzone.com.br
(13:52:31) -ChanServ- 4 3 *!*@lq7.l3a.166.200.IP
(13:52:31) -ChanServ- 5 3 *!*@56k.iju.113.177.IP
(13:52:31) -ChanServ- 6 3 gustavo
(13:52:31) -ChanServ- 7 3 gustavo^^
(13:52:31) -ChanServ- 8 3 *!*@n8s3dt.veloxzone.com.br
(13:52:31) -ChanServ- 9 3 *!*@cqorc6.telesp.net.br
(13:52:31) -ChanServ- 10 3 *!*@ceq.4b7.10.201.IP
(13:52:31) -ChanServ- 11 3 *!*@7fa4k5.telesp.net.br



To remove:
/chanserv access #xatneorotico del Maay_Lock
Show:
(13:53:56) -ChanServ- maay_lock nao foi encontrado na lista de acesso do #xatneorotico. (not found)



To remove:
/chanserv access #xatneorotico del *!*@7fa4k5.telesp.net.br
Show:
(13:54:05) -ChanServ- *!*@7fa4k5.telesp.net.br removido da lista de acesso do #xatneorotico. (removed successfuly)
Additional Information: Whois of Maay_Lock:
Maay_Lock is Webd95d@7fa4k5.telesp.net.br * WebChat xatneorotico.falai.org
Maay_Lock is connecting from Webd95d@201-43-xx-xx.dsl.telesp.net.br 201.43.xx.xx
Maay_Lock on +#xatneorotico
Maay_Lock using br.falai.org Powered by Falai
Maay_Lock is using modes +x
Maay_Lock End of /WHOIS list.

(13:52:56) <ChanServ> OVERRIDE: raphael!ph@189.72.230.144 used access on #xatneorotico to delete *!*@7fa4k5.telesp.net.br

(13:53:21) <ChanServ> OVERRIDE: raphael!ph@189.72.230.144 used access on #xatneorotico to add *!*@7fa4k5.telesp.net.br with level 3

(13:54:05) <ChanServ> OVERRIDE: raphael!ph@189.72.230.144 used access on #xatneorotico to delete *!*@7fa4k5.telesp.net.br
Attached Files:
Notes
(0006301)
Adam   
2012-11-10 02:24   
I have changed access del and xop del to behave like access add/xop add now, so it will use the users hostmask.

Fixed in 8f36f65f39c6ea843c388af398ed0bbfe84d1207
(0006297)
LEthaLity   
2012-11-06 17:31   
The reason it adds a hostname is because the user isn't registered with NickServ, this is a new intentional thing that differs from 1.8. The hostmask is added to the access list as it's more secure then a nickname that anyone could /nick to.

I do think though that services could check if an online unregistered users hostmask matches one in the access list.
(0006296)
Raphael   
2012-11-02 20:11   
Description:

Sometimes using the command /chanserv access to add an user on userlist channel but the registered data is the hostname. Then when we will remove some user from the list the services don't find the user and we need to remove the user by hostname.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1410 [Anope Development (1.9.x series)] Nickserv feature N/A 2012-04-11 18:20 2012-11-01 22:59
Reporter: someone Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: /os forbid should take hosts and deny service usage from clients using them. Also add /ns dropforbidden to drop offending nicks
Description: It would be awesome, if one could /os forbid hosts so that matching clients would not be allowed to use services from those.

It would be even more awesome to have a command (/ns dropforbidden {NICK|EMAIL|HOST|HOSTLASTUSED|ALL}(?)) to drop all nicks offending the current /os forbid rulesets.

eg: drop all nicks that are/were last used from a forbidden host/domain.
eg: drop all nicks that were registered with a forbidden email-address/domain.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006294)
Adam   
2012-11-01 22:59   
Sorry, I sort of forgot this was here and had some time to glance at the tracker and saw it.

So what I was thinking:

/os forbid drop nick/chan/email/possibly some of the other things you said
/os forbid host add/list/del to forbid usage of a specific host

However I am wondering how useful this host ignore is with os_ignore, they would be pretty much doing the same thing... perhaps a config option on whether or not host forbids should tell the user they were forbidden or not?

I wouldn't want to keep both os_ignore and os_forbid if both were doing nearly the same functionality.
(0006140)
someone   
2012-04-11 21:24   
Partially.

/os ignore makes services ignore the user completely and it looks to the ignored client that there are no services at all/are down/hanging/netsplit not yet detected by ircd/...
/os ignore would be totally fine, if one could decide (via config option (?)) to either ignore the matching clients OR make services respond with a "permission denied" and possibly the reason notice.

I was thinking of/hoping for a "you are not permitted ..." notice, like people get when using a forbidden email address.


Also the "drop offending nicks" feature is missing which would be awesome, as it would enable admins to actually excecute the forbidden (and ignored) rulesets.

eg: why should some nick grabbers that are now being permanently ignored/got their email addresses permanently forbidden/... be able to keep the legitime nicks they grabbed, whey they are not able to use them anymore anyway.
(0006139)
Adam   
2012-04-11 19:01   
Doesn't /os ignore do this?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1446 [Anope Development (1.9.x series)] Nickserv tweak always 2012-09-25 18:13 2012-11-01 22:18
Reporter: ZacK Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: hideprivilegedcommands is not working for nickserv
Description: Users get all commands in the help output despite setting "hideprivilegedcommands" to yes
Tags:
Steps To Reproduce: Unregistered user makes /ns help:

NickServ allows you to "register" a nickname and
prevent others from using it. The following
commands allow for registration and maintenance of
nicknames; to use them, type /msg NickServ command.
For more information on a specific command, type
/msg NickServ HELP command.

    ACCESS Modify the list of authorized addresses
    AJOIN Manage your auto join list
    (.....)

    RESETPASS Helps you reset lost passwords
    SASET Set SET-options on another nickname
 
    (.....)


Note: RESETPASS is supposed to be restricted to IRC operators (directive "restricted" is set to yes in services.conf)
Additional Information: "/botserv help" shows the command BOT
Attached Files:
Notes
(0006293)
Adam   
2012-11-01 22:18   
This was actually never the intent of hideprivilegedcommands, it was used to hide operator only commands from non-operators, however I have extended it to also hide commands that require authentication from unidentified users.

Fixed in a0a54fdfe058026f028dc0930e3ba982bce5b6dc.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1457 [Anope Stable (1.8.x series)] Other crash have not tried 2012-10-31 17:23 2012-10-31 20:35
Reporter: TheVirus Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: UserKey starting with 0 throws error
Description: Seen in forum post: http://forum.anope.org/index.php?topic=3864.msg20626#new

UserKeys:
UserKey1 9980014
UserKey2 0233658
UserKey3 5785004

Error Message:
[Oct 28 15:13:59 2012] services.conf:392: UserKey2: Expected a positive integer for parameter 1
[Oct 28 15:28:03 2012] services.conf:392: UserKey2: Expected a positive integer for parameter 1
[Oct 28 15:29:00 2012] services.conf:392: UserKey2: Expected a positive integer for parameter 1
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006291)
Adam   
2012-10-31 20:35   
fixed in 3e6d8382853d3dd6ca371220a4a2891d5a56acc5

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1415 [Anope Development (1.9.x series)] Operserv minor always 2012-05-03 15:35 2012-10-31 04:08
Reporter: Robby Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Forbid does not disallow setting forbids on services opers nicknames
Description: Since forbid was moved to an OperServ module this does not disallow setting forbids on services opers nicknames anymore, according to nickserv.conf.example this behavior should still work when secureadmins = yes but it does not.

If there was no specific reason for this change then this should either be reimplemented to work again or FORBID should be removed from the secureadmins description if there is a reason that this feature should not come back.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006290)
Adam   
2012-10-31 04:08   
fixed in a39947cd3c6c76cb708de7d328aabde62e39be0b

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1421 [Anope Development (1.9.x series)] Operserv minor always 2012-06-26 13:14 2012-10-31 02:42
Reporter: KindOne Platform:  
Assigned To: Adam OS:  
Priority: low OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: os_mode: prevent setting modes on non-existant-user.
Description: The os_mode module allows a user with access to set modes on channels/users.
If I was to give +o status to a non-existent-user, then services would report that I did it, even though the user does not exist.
This can cause confusion for other /oper's when they see the snotice.

I am suggesting adding code to prevent this false snotices/#services log.
Tags:
Steps To Reproduce: /msg OperServ mode #services +o non-existant-user
Additional Information:
Attached Files:
Notes
(0006289)
Adam   
2012-10-31 02:42   
fixed/added in 26a4a13cdff2933b77da986ccc38f3538beaaea7

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1450 [Anope Development (1.9.x series)] Chanserv major random 2012-10-23 10:58 2012-10-24 05:16
Reporter: ScrAm Platform: BSD  
Assigned To: DukePyrolator OS: FreeBSD  
Priority: normal OS Version: 9.0  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 1.9.x-GIT  
    Target Version:  
Summary: ChanServ limit for number of channels doesn't always work correctly
Description: Someone on my network was attempting to register a channel but ChanServ was giving him an error saying that he had already exceeded the 20 channel limit. I did a /ns alist on him and saw that he only owned one channel, and had access in another. After that, I raised the limit to 25 channels and he still couldn't register it. I raised it to 250, and it still failed. I raised it to 250000 channels just to test it, and he was able to register it.

After he was able to register the channel, I dropped the limit back to 25. He registered another channel successfully with the 25 channel limit.
Tags: channel limit, ChanServ
Steps To Reproduce: I had someone else on my network attempt to register channels while the limit was at 20. He was able to register three channels with no problem, but he had no previously owned channels or access in any channels.
Additional Information: When at 20 channel limit:
-NickServ- Channels that case has access on:
-NickServ- Number Channel Access
-NickServ- 1 #******* Founder
-NickServ- 2 !#************ 5
-ChanServ- Sorry, you have already exceeded your limit of 20 channels.
Raised to 25:
-ChanServ- Sorry, you have already exceeded your limit of 25 channels.
Raised to 250:
-ChanServ- Sorry, you have already exceeded your limit of 250 channels.
Attached Files:
Notes
(0006275)
DukePyrolator   
2012-10-24 05:16   
thanks for reporting
fixed in e0438e3a7ee3b7737f5138e7f43157b07479c824

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1414 [Anope Development (1.9.x series)] Nickserv feature N/A 2012-05-02 15:18 2012-10-13 12:24
Reporter: Robby Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Allow services operators to modify other users ns_ajoin list
Description: It would be handy if like '/NS ACCESS', '/NS AJOIN' would take a user parameter so operators with nickserv/ajoin privilege can view and modify the auto join list of other users.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006266)
Adam   
2012-10-13 12:24   
1232018332bf8c51ea1d09fb4d8bd430163117a0

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1445 [Anope Development (1.9.x series)] Botserv minor always 2012-09-25 05:32 2012-10-01 02:35
Reporter: ZacK Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Unassigned bot returns to channel after restart
Description: The bots that have been unassigned return to the channel when the services start again.
Tags:
Steps To Reproduce: /botserv assign #mychan botname
/botserv unassign #mychan

Then I restart or shutdown services
When the services start again, the bot rejoins #mychan
Additional Information: I use my_sql_live but the problem can be reproduced with my_sql too.
I have noted that the field "bi" in "anope_db_ChannelInfo" table contains the name of the bot even after using unassign command.
Attached Files:
Notes
(0006261)
Adam   
2012-10-01 02:35   
Thanks, fixed in ad37bc9639304f78247d03e6a27fbc2c798926da

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1439 [Anope Stable (1.8.x series)] IRCD support crash always 2012-08-04 09:37 2012-08-06 04:30
Reporter: allentovar4 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: /samode crash on inspircd
Description: Anope crashes when you use /samode to set a user mode on a services client on InspIRCd.
Tags:
Steps To Reproduce: Use /samode to set a mode on any services client.
/samode ChanServ +B (Or any other user mode or service)
Additional Information: <Global> PANIC! buffer = :483AAAAAP MODE 3AXAAAAAL +B
<Global> Backtrace: Segmentation fault detected
<Global> Backtrace: report the following lines
<Global> Backtrace: Anope version 1.8.7 (3089) build 0000001, compiled Aug 3 2012 23:55:53 QM
<Global> Backtrace(0): ./services(do_backtrace+0x64) [0x807a734]
<Global> Backtrace(1): ./services(sighandler+0x19b) [0x807a95b]
<Global> Backtrace(2): linux-gate.so.1(__kernel_sigreturn+0) [0xb7769400]
<Global> Backtrace(3): ./services(finduser+0x1a) [0x8094c7a]
<Global> Backtrace(4): ./services(do_umode+0x24) [0x80952b4]
<Global> Backtrace(5): /home/allen/services/modules/runtime/inspircd20.so.zMYGnF(anope_event_mode+0x6c) [0xb775ecac]
<Global> Backtrace(6): ./services(process+0x1c0) [0x808eac0]
<Global> Backtrace(7): ./services(main+0x20d) [0x805754d]
<Global> Backtrace(8): /lib/libc.so.6(__libc_start_main+0xf5) [0xb7023605]
<Global> Backtrace(9): ./services() [0x8057869]
<Global> Backtrace: complete
<Global> Services terminating: Segmentation fault
Attached Files:
Notes
(0006240)
Adam   
2012-08-04 23:36   
This should have been fixed 5 days ago in http://anope.git.sourceforge.net/git/gitweb.cgi?p=anope/anope;a=commitdiff;h=d0e5a188489c8e760bd0997a9fbcdfd64907eda8
(0006239)
chaz   
2012-08-04 10:47   
Thx for that, their wiki is showing it incorrectly ;)

Thanks for the above also, I'll get around to testing this.
(0006237)
allentovar4   
2012-08-04 10:04   
(Last edited: 2012-08-04 10:05)
Running InspIRCd 2.0.8. As of this version the target can be a channel or a user according to the helpop system:

* /SAMODE [target] +/-[modes] {[parameters for modes]}

-OperServ- Current Module list:
-OperServ- Module: cs_appendtopic [1.8.7 (3089)] [Supported]
-OperServ- Module: cs_enforce [1.8.7 (3089)] [Supported]
-OperServ- Module: enc_sha1 [1.8.7 (3089)] [Encryption]
-OperServ- Module: hs_request [1.8.7 (3089)] [Supported]
-OperServ- Module: inspircd20 [1.8.7 (3089)] [Protocol]
-OperServ- Module: ns_maxemail [1.8.7 (3089)] [Supported]
-OperServ- Module: os_info [1.8.7 (3089)] [Supported]
-OperServ- 7 Modules loaded.

The target can be ANY services client such as NickServ or ChanServ and includes bots created by BotServ also any user mode that is set to that target for example umode +B or +x I have not tested removing any user modes however.

Example Syntax: /samode NickServ +B

(0006236)
chaz   
2012-08-04 09:51   
Hello,

My understanding from the InspIRCd documentation is that SAMODE is performed against users on a channel, your syntax doesn't show a channel parameter, please can you confirm your syntax just to confirm how to reproduce.

Additionally, please can you confirm any modules you're using on the Anope side?

I'll put together a test network shortly to reproduce, which version of InspIRCd 2.0 are you using?

Thanks,

Charles.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1198 [Anope Development (1.9.x series)] Anope Languages minor always 2010-10-13 13:56 2012-07-05 20:55
Reporter: tsb Platform:  
Assigned To: Adam OS:  
Priority: low OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ChanServ Bans, Kick not displayed at wrong-case cyrillic-named channel.
Description: When the first user joins at channel with different registered channelname case (channel name "blabla" instead registered "BlaBla"), kick and bans messages by ChanServ NOT displayed and not processed with irc-client.
Tags:
Steps To Reproduce: 1. Register cyrillic channel. ("?????" for example);
2. Join to this chan at different case wich was registered. ("?????" for example);
3. Try to ban any user uses chanserv;
4. Profit.
Additional Information: There i attached pic of trouble.
Sorry for my english.
Attached Files: bug_report.jpg (461,118 bytes) 2010-10-13 13:56
https://bugs.anope.org/file_download.php?file_id=304&type=bug
Notes
(0006173)
Adam   
2012-07-05 20:55   
This should be fixed now in 62818abbf4a39b7641ad2b84d1888ed03b653819 with options:casemap
(0005802)
chaz   
2011-04-23 08:35   
Won't fix in 1.8, open for 1.9
(0005638)
tsb   
2010-10-13 13:58   
/version irc.services
Anope-1.8.5 (3037) irc.services UnrealIRCd 3.2.x - QM (enc_old) -- build 0000001, compiled Oct 7 2010 10:36:20

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1417 [Anope Development (1.9.x series)] Chanserv crash always 2012-05-09 21:10 2012-05-10 22:55
Reporter: MathK1LL Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash on removing all flags from a user
Description: Upon removing all flags with "-*", a segfault occurs.

A note though is that it appears to remove them from the user, but crashes shortly after.

See attached backtrace.
Tags:
Steps To Reproduce: do !flags modify <nick> +*
then do !flags modify <nick> -*

Crash.
Additional Information:
Attached Files: gdb.output (32,768 bytes) 2012-05-09 21:10
https://bugs.anope.org/file_download.php?file_id=330&type=bug
Notes
(0006149)
Adam   
2012-05-10 22:55   
fixed in 9370b063d0d8ecdd479370ee8c1d7946fbcad4be

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1416 [Anope Development (1.9.x series)] Nickserv feature N/A 2012-05-08 04:54 2012-05-08 07:04
Reporter: Robby Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Allow services opers to '/ns release' other people's nicks aswell as allow '/ns access list' on other services opers again
Description: Attached is a small patch for a feature request for ns_release, a small revert in behavior because of a change to ns_access and the addition of SUSPEND to the description of secureadmins in nickserv.example.conf.

ns_release: I made a change to it to allow services operators to manually release nicknames from other people. Useful for smoother help/support. Also corrected Log() messages text.

ns_access: In older versions, up to revision 781ed11b, it was possible to view the access list of other services operators, even when secureadmins was enabled. Since 781ed11b not even viewing that list is possible anymore, this reverts that behavior. I found this most handy to assist fellow operators in setting up their NickServ access list.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: ns.patch (3,587 bytes) 2012-05-08 04:54
https://bugs.anope.org/file_download.php?file_id=329&type=bug
Notes
(0006148)
Adam   
2012-05-08 07:04   
25586f32467334f0366ce0b8bfe16e2d5e005851

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1383 [Anope Development (1.9.x series)] Other minor always 2012-03-06 01:00 2012-05-07 03:11
Reporter: cbiedl Platform: Linux  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Database file backup fails for DatabaseFile with path
Description: Hello,

I'm not very happy with

    Anope::string newname = "backups/" + DatabaseFile + "." + stringify(tm->tm_year) + stringify(tm->tm_mon) + stringify(tm->tm_mday);

(both in modules/database/db_flatfile.cpp and modules/database/db_plain.cpp).

At first, if the DatabaseFile is configured to an absolute path like

    database = "/var/lib/anope/anope.db"

the code above will try to backup a database file to

    backups/var/lib/anope/anope.db.NNNN (number depends on date)

which will very likely fail. Please consider using the base name of
DatabaseFile only.

A second thing, the filename created has a small risk for collisions.
Please consider padding (preferred as this keeps backup files sorted)
or insert separators between the date components.

Regards,

    Christoph
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006147)
Adam   
2012-05-07 03:11   
I've added the ability for the directory databases are stored in to be changed at runtime in 675b113c3e03cf1917b2a731c21fe82b5f1f2b2b by command line options. I've also added options to cmake to allow installing binaries/libs/configs/whatever in directories other than the default, if you want to use those you define one or more of BIN_DIR, DB_DIR, DOC_DOC, LIB_DIR, CONF_DIR, LOCALE_DIR, or LOGS_DIR in ./Config for cmake.
(0006094)
Adam   
2012-03-07 10:13   
For now I have pushed a fix for the backup database name collision.
(0006093)
Adam   
2012-03-06 03:04   
The database configuration option actually is supposed to just be a name. I'm not sure if we want to support saving and loading databases from outside of the services data directory.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1412 [Anope Development (1.9.x series)] Operserv crash always 2012-04-28 00:52 2012-04-28 02:09
Reporter: Nita Platform: Intel x64  
Assigned To: Adam OS: Debian  
Priority: high OS Version: 6.0  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Anope 1.9 current: Crash on: /msg OperServ EXCEPTION ADD
Description: /msg OperServ EXCEPTION ADD +0 127.0.0.1 12 Services

*** LINK: Connection to services.irc.local.net failed with error: A TLS packet with unexpected length was received.
*** LINK: Server services.irc.local.net split: A TLS packet with unexpected length was received.
*** LINK: Netsplit complete, lost 8 users on 1 server.
*** LINK: Connection to 'services.irc.local.net' failed.

Crash
Tags:
Steps To Reproduce: /msg OperServ EXCEPTION ADD +0 127.0.0.1 12 Services
Additional Information: Inspircd 2.0
Attached Files:
Notes
(0006146)
Adam   
2012-04-28 02:09   
Yea, 1.9.6's SQL live modules have several known problems. They have been reworked quite a bit in git and should work OK now.
(0006145)
Nita   
2012-04-28 01:08   
sql_live enabled in devel version

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1411 [Anope Development (1.9.x series)] Nickserv major always 2012-04-23 17:59 2012-04-26 00:03
Reporter: Phantomal Platform:  
Assigned To: Adam OS: Debian Linux  
Priority: normal OS Version: Squeeze  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: SASET EMAIL and SASET PASSWORD Access Denied even for Services root with all privileges
Description: Most SASET options working perfect. Only SASET EMAIL and SASET Password not.

Even as Services Root you get: *NickServ* Access denied.
Tags:
Steps To Reproduce: msg nickserv saset username email new@mail.com

msg nickserv saset username password newpass
Additional Information: Anope 1.9.6 Release Version
Attached Files:
Notes
(0006144)
Adam   
2012-04-26 00:03   
Ok I've changed the message to be more informative
(0006141)
Phantomal   
2012-04-23 18:33   
After deeper testing i found out, that the only "Bug" in this case is, that the errormessage should give feedback, that an email or password couldn't set because SECUREADMINS is set to ON.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1404 [Anope Stable (1.8.x series)] Other text N/A 2012-04-04 03:26 2012-04-04 07:00
Reporter: Saurios Platform:  
Assigned To: Adam OS:  
Priority: low OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Missing mentioning of SASET in online documentation
Description: As the summary states... the SASET command isn't availeble in online documentation (http://anope.org/docgen/1.8/en_us/NickServ.html)
(and therefore setting the noexpire function isn't explained)
(also docs for 1.9 are missing but this is already something you know but may have to be reminded of)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006135)
Adam   
2012-04-04 07:00   
Its been added now. There is no concern for the 1.9s docgen now, it's under too much development.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1401 [Anope Development (1.9.x series)] Modules System minor always 2012-03-19 19:43 2012-03-22 08:31
Reporter: MathK1LL Platform:  
Assigned To: DukePyrolator OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 1.9.x-GIT  
    Target Version:  
Summary: No "Failure to Load" messages
Description: Had an issue with m_mysql not reporting it wouldn't load, just that it was attempting to load. No error messages.

Fixed by re-running ./Config and noting that it couldn't find the devel files thus wasn't compiling. However, it took me a day to figure this out... A simple "Unable to load <error number>" might've helped :)
Tags:
Steps To Reproduce: Load a module that doesn't exist
Additional Information:
Attached Files:
Notes
(0006127)
DukePyrolator   
2012-03-22 08:31   
fixed in commit 8d0b4a1bf53788494fe0531dd62b4dd2ee655e9b

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1399 [Anope Development (1.9.x series)] Operserv crash always 2012-03-19 15:26 2012-03-21 23:21
Reporter: Alpha2011 Platform: Linux  
Assigned To: DukePyrolator OS: Ubuntu  
Priority: high OS Version: 11.10  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 1.9.x-GIT  
    Target Version:  
Summary: Services Crash Operserv session limit exceeded
Description: When restarting, Anope-1.9.7-avoid-direct-visual-contact (ga069347), and the session limit is exceeded by a user; services segfaults.
Tags:
Steps To Reproduce: Have a user with over 3 connections, and restart services.
Additional Information:
Attached Files:
Notes
(0006126)
DukePyrolator   
2012-03-21 23:21   
fixed in 1b0ebcadfa1003b8e2d873a572633e4d1c0286de

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1389 [Anope Development (1.9.x series)] Other minor have not tried 2012-03-13 20:40 2012-03-15 03:06
Reporter: nenolod Platform:  
Assigned To: Adam OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: DNS query IDs are no longer random allowing predictability for hostile DNSBL replies
Description: hi,

in commit 086790d6331357022f4da17c76b26b9fc6e2ad90, you made DNS queries sequential:

dns.cpp, lines 54-59:

do
{
    static unsigned short cur_id = 0;
    this->id = cur_id++;
}
while (DNSEngine->requests.count(this->id));

this needs to be reverted, because an attacker who knows the IP that Anope's DNS resolver is listening for replies on can spam the box with hostile replies for the purpose of getting specific IPs akilled.

to ensure DNS query hijacking is difficult, random 16-bit query IDs must always be used. with this change, once one query ID is learned successfully, all other subsequent query IDs are known forever.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006117)
Adam   
2012-03-14 08:08   
Thanks but no thanks... I believe what we have now is secure enough.