View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002322 | unreal | ircd | public | 2005-02-06 03:39 | 2007-04-27 12:56 |
| Reporter | Stealth | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | no change required | ||
| Summary | 0002322: More info in connect logs | ||||
| Description | I think Unreal should include the clients class in the line that gets logged for connects. The class will also be useful in the line for oper attempts. | ||||
| 3rd party modules | |||||
|
|
classes into connect-log are a good idea imo. So you can go through the stuff (or an automato) and look if there is some glitch in your allow-conf - or a provider has new IP-Ranges without rDNS which you may put in another class then the default-class etc...) but I can't sea a reason logging the class on /oper? if the first is implemented you can go look in connect-log for the user on the one hand - on the other hand - what does the class help you, why this might be important? nick and host may be important in case of abuse, since those figures are pointing at the person who actually did it. It doesn't bother if they are in class "mickymouse" "donaldduck" or whatever you call them... |
|
|
The reason for logging classes in opers logs: Lets say you have a class specificly for opers, and all your oper blocks use that class. You have just set up Unreal, and for some reason it is refusing to let you oper. You have checked the username and password dozens of times, and you are sure it is correct. How do you know the class is correct? Unfortunaly, there is no way of checking what clients class an oper is attempting to login from unless you go and reference the connects log. For me, that would be a bigger task than it seems. I have separate logs for oper actions and connects, so I would need to open 2 files in SSH, and switch between the 2. If Unreal logged clases with oper attempts, this would eliminate the need to open the connects log and see what class the oper attempted to log in from. |
|
|
as far as i understood the classes-directive within the oper-block, this is the class where the opered-up-client will be MOVED after successful oper. So you have an oper-class for all opers - or special classes for each oper - to set different class-configuration than for normal users. This means along my understanding: if I connect to my server from "host1.myisp.tld" and I've some specific allow-blocks, I'm put into "myisp"-class and after opering I'm moved in my designated oper-class. maybe the coders could clearify this one? |
|
|
medice is correct. I don't know what Bugz is referring to. There is no way "having an incorrect class" (what does that even mean?) can prevent you from opering up. I have no idea how being able to see the oper class somehow prevents abuse. Why would you ever need this information? |
|
|
Bump. Still an issue? |
|
|
I don't see an issue with this anymore |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-02-06 03:39 | Stealth | New Issue | |
| 2005-02-07 07:23 | medice | Note Added: 0009045 | |
| 2005-02-07 12:38 | Stealth | Note Added: 0009046 | |
| 2005-02-07 20:46 | medice | Note Added: 0009050 | |
| 2005-02-08 13:24 |
|
Note Added: 0009051 | |
| 2007-04-27 06:24 |
|
Note Added: 0013869 | |
| 2007-04-27 06:24 |
|
Status | new => feedback |
| 2007-04-27 11:55 | Stealth | Note Added: 0013890 | |
| 2007-04-27 12:56 |
|
Status | feedback => closed |
| 2007-04-27 12:56 |
|
Resolution | open => no change required |
