View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001694 | unreal | ircd | public | 2004-03-31 03:57 | 2004-05-14 15:54 |
| Reporter | w00t | Assigned To | |||
| Priority | normal | Severity | trivial | Reproducibility | always |
| Status | closed | Resolution | open | ||
| Summary | 0001694: +O channels and locops | ||||
| Description | I don't know if this is by design or not, but local operators cannot join +O channels. Our staff channel is +O... our locops are staff... They cant join. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Yes i agree. This is a problem. If i want only opers (local and global ) to join #opers i can't set mode +O because local opers can't join. |
|
|
Reminder sent to codemastr |
|
|
(wb w00t) My guess is that it's designed. Think about it - locops can only do things _locally_. Globops can do things globally. +O channels is a global thing (unless you're a single server net). Therefore, globops can join +O and locops can't. However, if it's not by design, it should be changed... but my guess is that we'll probably only see it in 3.3 if this is the case. |
|
|
ty Ron2k, Yes, I still hang around... I like to keep abrest of the news, as I am still running Unreal at the moment (damn my host's outdated syslibs, etc..) I do agree that this may be designed, but perhaps then a new mode should be considered, or at the least, the description of this changed (O = opers only) |
|
|
Well if local chans come back (yeah right)... then locops could join +O... |
|
|
aquanight, if you read the posts properly, you would know that my query related to +O had nothing to do with local channels (which, by the way arent coming back (I asked a few months back.)) but just at the least to explain this odd behaviour, and perhaps to remedy it, or the introduction of a new channelmode for staff only (all opered users) as we DO need that kind of thing without having to activly be "there" on that channel to patrol, and make sure that only people who are supposed to be there, are there. |
|
|
/me pokes syzop\codemastr Any thoughts guys? |
|
|
The +O usermode is not sent to remote servers. As a result, it makes something like this difficult. |
|
|
hm, that makes sense... remote servers dont need to know about local operators. So what oh what do we do :/ |
|
|
new idea: I think we'll just set a channel key and leave it at that. Seems a pity though. |
|
|
as an idea: If the local user is on the local server with umode +O and umode +O is sufficient to join chanmode +O channels - all the other servers have to accept this joining (believing the remote server's working correct) nevertheless this user is nothing special concernung umodes... or is there something more complicated? |
|
|
Another IDEA Is this: When a Local operator try to join on +O channel, server will automatically SAJOIN the operator to the specific channel (over ride +O) Is this useful or not? |
|
|
>When a Local operator try to join on +O channel, server will automatically >SAJOIN the operator to the specific channel (over ride +O) A server sending SAJOIN? Uh.... (Hint: SAJOIN != SVSJOIN) Services could probably implement this. Too bad /invite doesn't bypass +O... All I can suggest is maybe just tell your locops to /KNOCK and the SAs can SAJOIN him. (Just don't put +K ;) .) |
|
|
Yes, I had already thought of the services idea! Hoorah for parallel thinking. As I _have_ a services project (writing my own w32 services from scratch) this is going in. Especially easy since services tracks mode changes. |
|
|
(i.e if a user gets +O, then SVSJOIN them straight away... and aquanight, its an easy mistake to make ;)) |
|
|
Other servers do not know about local opers iirc. So no usermode O will be sent. only a little o is ever sent. Of course, if I am wrong, ignore me. [edit spelling] edited on: 2004-05-03 23:28 |
|
|
Yes, Praetorian is correct. That's what I meant when I said +O is not sent to remote servers. So you can't make your services detect +O because the services are not notified of +O! |
|
|
Yes, yes yes... Just realised this myself around 2 minutes ago whilest checking the mode string in the user structure... ah well. back to the passworded channel idea. |
|
|
Well my first thought is what medice already said, which is mainly what we do with every mode: Check for access locally (+O in this case) and let them in if ok... then remote servers just allow those "remote users" in too. Only trouble such things could cause is operoverride fun, but in this particular case I don't think that applies / is relevant. |
|
|
So, send the join round... and see if one server accepts?? but then, how do the others know to let them join or not..? and also, ...... hold everything The client sends JOIN to the server. The server sees umode +O and chanmode +O. It checks, sees the +O umode and allows entry, then propegates the join. Is that what you mean? |
|
|
code knows exactly what I mean ;) |
|
|
Would it cause any oper override problems? Afaik, all the oper override stuff requires +o, not +O. So it wouldn't cause problems, would it? |
|
|
I don't think there's any problem. So this would just be a simple replace of IsOper() -> IsAnOper() for +O + a quick check that remote joins are permitted regardless of channel/usermodes.. even though I presume that's the case by now ;p |
|
|
At the end... Nice then:P |
|
|
I take it means that this is doable then? Coolness. I was thinking about making a quick and dirty thing in my services :P Guess it isnt needed now. |
|
|
i've changed it on my ircd. It working.. |
|
|
Well, I've had the leisure time of modifying my Win32. I've had several solutions to this problem: 1: Make Usermode +O Global (yuck, this shouldnt happen -- scratched) 2: Modify the IsOper to IsAnOper like described above 3: SVSJOIN. >When a Local operator try to join on +O channel, server will automatically >SAJOIN the operator to the specific channel (over ride +O) SAJOIN wont override +O but SVSJOIN will. |
|
|
Fixed in .2234.2.13 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-03-31 03:57 | w00t | New Issue | |
| 2004-04-23 06:04 | vonitsanet | Note Added: 0005911 | |
| 2004-04-23 06:06 | vonitsanet | Note Added: 0005912 | |
| 2004-04-23 11:01 | Ron2K | Note Added: 0005913 | |
| 2004-04-28 21:58 | w00t | Note Added: 0005939 | |
| 2004-04-29 09:43 | aquanight | Note Added: 0005952 | |
| 2004-04-29 19:16 | w00t | Note Added: 0005954 | |
| 2004-05-02 20:24 | w00t | Note Added: 0005980 | |
| 2004-05-02 21:57 |
|
Note Added: 0005986 | |
| 2004-05-02 22:17 | w00t | Note Added: 0005987 | |
| 2004-05-03 01:17 | w00t | Note Added: 0005994 | |
| 2004-05-03 06:15 | medice | Note Added: 0005997 | |
| 2004-05-03 11:15 | vonitsanet | Note Added: 0006000 | |
| 2004-05-03 21:25 | aquanight | Note Added: 0006014 | |
| 2004-05-03 21:54 | w00t | Note Added: 0006015 | |
| 2004-05-03 21:55 | w00t | Note Added: 0006016 | |
| 2004-05-03 23:27 | Praetorian_ | Note Added: 0006021 | |
| 2004-05-03 23:28 | Praetorian_ | Note Edited: 0006021 | |
| 2004-05-03 23:38 |
|
Note Added: 0006024 | |
| 2004-05-04 00:33 | w00t | Note Added: 0006027 | |
| 2004-05-04 00:44 | syzop | Note Added: 0006029 | |
| 2004-05-04 18:34 | w00t | Note Added: 0006067 | |
| 2004-05-04 20:56 | syzop | Note Added: 0006075 | |
| 2004-05-04 21:05 |
|
Note Added: 0006080 | |
| 2004-05-04 21:21 | syzop | Note Added: 0006084 | |
| 2004-05-07 06:33 | vonitsanet | Note Added: 0006117 | |
| 2004-05-10 00:08 | w00t | Note Added: 0006149 | |
| 2004-05-14 12:44 | vonitsanet | Note Added: 0006250 | |
| 2004-05-14 15:21 | Zell | Note Added: 0006258 | |
| 2004-05-14 15:54 | syzop | Status | new => closed |
| 2004-05-14 15:54 | syzop | Note Added: 0006259 |
