View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001692 | unreal | ircd | public | 2004-03-31 01:10 | 2004-03-31 18:44 |
| Reporter | blotter45 | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | open | ||
| Summary | 0001692: request: real ident/username and gecos in whois and userhost for opers? | ||||
| Description | right now, when setident or chgident is used on a user, its not possible to see what their original ident/username was before the change (not without looking through logfiles to see what the user connected as).. but something like this added to whois and userhost might be helpful: somedude is [email protected] * my_fake_gecos somedude is using modes +ix somedude is connecting from [email protected] * real_gecos somedude on &#somechan somedude using SomeServer.SomeNet.net somedude End of /WHOIS list. userhost: [email protected] but of course when a non-oper does a whois or userhost on another user, then they would only be able to see the fake id/username and gecos.. There are lots of reasons why this would be useful, but one obvious reason is when you are trying to ban a specific bnc/vhost range that a problematic user has access to, but you dont want to ban everybody in the ip range - just the one user.. Having support for the real gecos field in whois would be very useful too, that way its much easier to set n:lines (and svsnlines via a u:line). This is perhaps the most important request here, because any user can use setname and mask his real gecos at any time he wants. good idea or bad? ;) | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Doesn't seem useful to me... Or at least not worth it. Why would you CHGIDENT/CHGNAME someone if he's a bad guy (or even mass CHGIDENT/CHGNAME'ing)??... doesn't make much sense to me. |
|
|
Well you are right about chgident and setident, usages of those can be controlled. Our hostserv supports using vhosts like [email protected], but I try to discourage opers from giving vidents away to users that ask for them (because they are a pain to track).. So yes, those can be controlled. But usages of setname can't be controlled, and any user can change their gecos as often as they like, which makes it difficult to track what their real gecos is, without looking through large logfiles to find the answer. |
|
|
But usages of setname can't be controlled, and any user can change their gecos as often as they like, which makes it difficult to track what their real gecos is, without looking through large logfiles to find the answer. --- Why would you ever want to track what their "real" gecos is? Additionally, I don't see the need to store an extra field for each user when very few people use /setname. |
|
|
/whowas <user> That should return all the information you want, right? |
|
|
There are some situations (not many, but there are some) where using n:lines are a very effective way to get rid of large floodnets (don't laugh, it has worked with floodnets of 2000+ in the past - some of the botmasters out there aren't the brightest kids on the block I guess). Using whowas isn't really a viable option on a large and busy network. Even with a nick history length of 5,000 the whowas array gets recycled too quickly anyway (and I dont want to increase the history length any more, as it directly affects memory usage on the boxes). But anyway, I kinda expected that you guys wouldn't want to add extra fields to whois and userhost. Nevertheless, I just wanted to give my 2 cents on the issue :) |
|
|
Also if someone uses /SETNAME then there's no reason to think they wouldn't change their own realname they use for connecting to try to get in again... Bit what codemastr said/ment.. the main purpose for those ban realname stuff is for things that are quite 'static' such as bots etc, if they just change it.. then they can usually also change it for conenct.ds fdshdfsd [etcetc, *in a hurry*] I'll just close the bug now.. I'm indeed not even considering this, it would involve quite some coding, require quite some memory for field that would be rarely used, etc etc etc. ;). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-03-31 01:10 | blotter45 | New Issue | |
| 2004-03-31 09:24 | syzop | Note Added: 0005693 | |
| 2004-03-31 10:13 | blotter45 | Note Added: 0005695 | |
| 2004-03-31 17:44 |
|
Note Added: 0005696 | |
| 2004-03-31 18:08 | aquanight | Note Added: 0005699 | |
| 2004-03-31 18:32 | blotter45 | Note Added: 0005700 | |
| 2004-03-31 18:44 | syzop | Status | new => closed |
| 2004-03-31 18:44 | syzop | Note Added: 0005702 |
