View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004037 | unreal | ircd | public | 2011-08-06 01:51 | 2019-09-11 22:21 |
| Reporter | katsklaw | Assigned To | Gottem | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | duplicate | ||
| Summary | 0004037: [feature] require|deny module block | ||||
| Description | This block will require a linking server to have a specific list of modules loaded to successfully connect to the network. This is helpful to enforce modules that must be loaded on all servers on the network. This block should have the ability to require certain modules as well as deny modules. To support this block a list of modules will need to be sent during burst. module { type require|deny; name "m_stinkyfeet"; reason "no stinky feet allowed!"; }; | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
I'm not sure how this could be added and still maintain backward-compatible linking capabilities. This is mainly because s2s communication is not sanity checked (reasons are explained in other notes), so introducing an unknown command to earlier versions may cause crashing. |
|
|
well if I'm not mistaken, unreal ignores unknown s2s data as-is. if a server sends a list of modules in a raw 005 or CAPAB manner I'm fairly certain that it'll be ignored. There really isn't any way to desync a server with it. Obviously, a change like this to the protocol will warrant a bump in UnrealProtocol, thus allowing the use of a deny version block to prevent a hybrid network. Additionally, if I am incorrect about unknown s2s data being ignored. A question in the Config script can ask if older versions are going to be used(default to 'yes' for sanity) and if so, disable this feature. |
|
|
Or simply have the feature disabled if there are no blocks present, as well as a big fat warning about compatibility. |
|
|
Idea looks fine, though.. hmmm.. maybe it could be made more generic like not only requiring modules but channel/user modes? Then again, you can use the require module for that I suppose... we could stick with that. I'm presuming this would work for directly-connected servers only, then it's fine. Something more along the lines of other blocks though, like deny/allow channel, deny/allow dcc, so... deny/allow module? hmm.. ok.. deny/require module then :D Also support multiple module names in one block? Or not? I don't have plans to work on this (at this point anyway), but the idea is fine, I think. There's a 'features' sub-struct in the server struct for things like this. Put a linked list in there.. free it at the right place... parser code... etc... |
|
|
See related new feature request 0005369 to do it in modules. Still this one is nice too. And still probably use "require module" and "deny module" rather than module::type. |
|
|
Both this feature and the one Syzop linked above can (and prolly should) be done from the same module, so I'll close this one and continue in the other. Just seems silly to have 2 issues for the same module. :D |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-08-06 01:51 | katsklaw | New Issue | |
| 2011-08-06 18:58 | Stealth | Note Added: 0016737 | |
| 2011-08-06 19:14 | katsklaw | Note Added: 0016738 | |
| 2011-08-06 19:18 | Stealth | Note Added: 0016739 | |
| 2015-07-19 18:40 | syzop | Note Added: 0018524 | |
| 2015-07-19 18:43 | syzop | Status | new => confirmed |
| 2015-07-19 18:44 | syzop | Status | confirmed => acknowledged |
| 2019-08-27 13:39 | syzop | Relationship added | related to 0005369 |
| 2019-08-27 14:19 | syzop | Note Added: 0020858 | |
| 2019-09-10 22:29 | Gottem | Assigned To | => Gottem |
| 2019-09-10 22:29 | Gottem | Status | acknowledged => assigned |
| 2019-09-10 22:30 | Gottem | Relationship added | child of 0005282 |
| 2019-09-11 22:21 | Gottem | Status | assigned => closed |
| 2019-09-11 22:21 | Gottem | Resolution | open => duplicate |
| 2019-09-11 22:21 | Gottem | Note Added: 0020882 | |
| 2019-09-11 22:21 | Gottem | Relationship replaced | duplicate of 0005369 |
