View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006225 | unreal | ircd | public | 2023-02-08 07:26 | 2023-02-08 15:01 |
| Reporter | RDP | Assigned To | syzop | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 6.0.6 | ||||
| Summary | 0006225: SASL issues | ||||
| Description | Hello, I recently upgraded from version 5.2.3 to version 6.0.4, after the upgrade I found the following errors... 1. The services sqline lists (Anope) had no effect on the blocked nick. 2. Services were not able to change a user's nick, even if the user returned the message "your nick is being changed to..." Due to these failures, I chose to update to the latest available version 6.0.6 which did solve the problems mentioned above but... another problem arose SASL does not work in this version but it did in 5.2.3 and 6.0.4 In the services registry it tells me that the user did identify himself with SASL with the following msg... 02:31 @NickServ ¦ M_SASL: 181.160.254.171 (181.160.254.171) identified to account RDP using SASL But at the moment of entering the user nickserv requests the password again and if it is not entered, the services change the nick and for example if I apply the gline %*@ip SASL it doesn't work to avoid it either | ||||
| Tags | sasl | ||||
| 3rd party modules | |||||
|
|
1. Can you check your ulines { } blocks on all your servers? Your services server (anope) must be listed there. And if you change anything in the ulines { }, then the services server needs to disconnect and re-link. 2. On anope (version 2.0.7 or higher) be sure to use the "unreal4" module and not "unreal" I actually think it is issue nr 1, because what you describe is exactly what would happen on 6.0.4 if ulines are wrong, and due to a change in 6.0.6 the effects of wrong ulines changed a bit with 6.0.6. |
|
|
I think this is a case of user copied over modules.default.conf on the upgrade. As of 6.0.6 the command "SVSLOGIN" has its own file and you need to have this line in your modules.default.conf: loadmodule "svslogin"; Note, you should NOT copy over your old modules.default.conf when upgrading. |
|
|
Thank you very much for the quick answer. Indeed the problem was due to what was mentioned by Valware, add svslogin to the list, then a rehash and everything works normally again. Thanks Valware and Syzop. |
|
|
Ok, thanks for letting us know. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2023-02-08 07:26 | RDP | New Issue | |
| 2023-02-08 07:27 | RDP | Tag Attached: sasl | |
| 2023-02-08 08:04 | syzop | Note Added: 0022726 | |
| 2023-02-08 08:04 | syzop | Assigned To | => syzop |
| 2023-02-08 08:04 | syzop | Status | new => feedback |
| 2023-02-08 12:07 | syzop | Priority | high => normal |
| 2023-02-08 12:55 | Valware | Note Added: 0022729 | |
| 2023-02-08 14:16 | RDP | Note Added: 0022730 | |
| 2023-02-08 15:01 | syzop | Status | feedback => closed |
| 2023-02-08 15:01 | syzop | Resolution | open => no change required |
| 2023-02-08 15:01 | syzop | Note Added: 0022731 |
