View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004362 | unreal | ircd | public | 2015-06-15 14:43 | 2023-05-22 12:26 |
| Reporter | katsklaw | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | no change required | ||
| Platform | x86_64 | OS | Debian | OS Version | 6/7 |
| Product Version | 3.4-alpha3 | ||||
| Summary | 0004362: [feature] Add vhost::class | ||||
| Description | Simply put, add vhost::class. It works the same as allow::class or oper::class | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Could you tell us where it's for? Like an example case when you would use this? First reaction: It sounds odd to do class modifying in a vhost block. I mean.. it's for vhosts... later on it was extended to also add an swhois but that's still more or less in the same area of things (namely: appearance). A class, however, is something different. |
|
|
If you know a person well enough to give them a vhost, you can reasonably trust them with more resources. ie, a higher sendQ or a higher maxclients. the easiest way to do this is likely to just add vhost::class, then control it via a class block. |
|
|
as a side note, the severity should be "feature" not "minor". this is a feature request, not a bug. At present I lack the access to change it myself. |
|
|
In my usecase, clients from Tor may need a higher maxclients because they all appear from the same IP, whereas for I2P clients they have individual anonymous addresses via CGI. This would be great to help minimize the need for separate servers. |
|
|
At this point, my honest suggestion would be to use an oper block for this kind of thing. Oper permissions refactor has made it so oper doesn't really give you _any_ permissions without an associated class, but can be used to set things like this. Thoughts? |
|
|
Firstly, I think assigning vhost to allow block makes more sense. I think the idea here is to assign vhost to a group of clients categorized under the allow block. A good example here is clients connecting from Tor as mentioned by dg. Once hence receive their vhost as such: "Tor.gateway.unrealircd.org". Another example would be WebIRC: "irccloud.gateway.unrealircd.org". 0004370 has a similar feature request |
|
|
I don't think the vhost block would be suitable for this. Though I recognize the occasional need for making users special without giving them oper rights. Sadly what tmcarthur wrote earlier is not really the case, the current oper system even after the rewrite from back then still has lots of IsOper() checks that give at least "reading rights" for various things like IP addresses and such (me also being to blame for that :p). You could nowadays with security groups do quite some neat stuff. I use this approach on *.unrealircd.org by the way: security-group staff { // Select staff by services account name: account { One; Two; Three; Four; } // Or by certificate fingerprint: certfp { aaaaabbbbbccccetc; } } /* Put people in security-group staff in the class block staff */ allow { match { security-group staff; } class staff; } And then you also create a set::anti-flood::staff block in which you have higher flood limits, lower lag, more maxchannelsperuser and such. Whatever you like. NOTE: For the staff security group users being put in the staff class, they would either need certfp (always works) or for account they would need to use SASL (does not work when services are down). This because users are put in a class on-connect and not afterwards so NS IDENTIFY afterwards would then match them for security group 'staff' but would not put them in the 'staff' class. It would use set::anti-flood::staff settings for them though. So I think this issue can be closed. We should tell users more about this great functionality, though, like by best practices or examples :) |
|
|
Related feature is now this: https://www.unrealircd.org/docs/Set_block#Set_block_for_a_security_group |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-06-15 14:43 | katsklaw | New Issue | |
| 2015-06-15 17:16 | syzop | Note Added: 0018397 | |
| 2015-06-15 19:19 | katsklaw | Note Added: 0018399 | |
| 2015-06-15 19:32 | katsklaw | Note Added: 0018402 | |
| 2015-06-24 00:26 | dg | Note Added: 0018415 | |
| 2015-07-09 18:57 | syzop | Relationship added | duplicate of 0004216 |
| 2015-07-26 04:55 | tmcarthur | Note Added: 0018567 | |
| 2015-07-26 05:34 | dboyz | Note Added: 0018568 | |
| 2015-08-08 17:49 | syzop | Severity | minor => feature |
| 2023-05-20 15:50 | syzop | Note Added: 0022874 | |
| 2023-05-20 15:50 | syzop | Assigned To | => syzop |
| 2023-05-20 15:50 | syzop | Status | new => closed |
| 2023-05-20 15:50 | syzop | Resolution | open => no change required |
| 2023-05-20 15:52 | syzop | Note Edited: 0022874 | |
| 2023-05-20 15:52 | syzop | Note Edited: 0022874 | |
| 2023-05-22 12:26 | syzop | Note Added: 0022877 |
