View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002984 | unreal | ircd | public | 2006-06-25 22:36 | 2020-12-07 10:32 |
Reporter | aquanight | Assigned To | syzop | ||
Priority | normal | Severity | feature | Reproducibility | N/A |
Status | resolved | Resolution | fixed | ||
Platform | x86 | OS | Linux Gentoo | OS Version | 2.6.12 |
Product Version | 3.2.5 | ||||
Fixed in Version | 5.0.8-rc1 | ||||
Summary | 0002984: Some /stats features. | ||||
Description | For /stats G: a flag to limit the listing to either only glines or only gzlines (since currently both appear in /stats G). Yes one could /gline or /gzline with no params for this, but one can't use the +mrs flags with that. Also, possibly a flag to filter g(z)lines by their expiration time (ie search for permanents or ones about to expire within X minutes or something). For /stats K, flags support, like what /stats G and s has. For just about all /stats (mainly those that can become big lists, like G, K, or s), possibly a flag to limit the number of entries returned. It's always annoying to have an X00-item-long *line list (like because of some spamfilter hitting hundreds of proxies) and even with a beefy sendq it takes upwards of 10 minutes to finish outputting (yes, proper filters can prevent this, but...). | ||||
Tags | No tags attached. | ||||
3rd party modules | |||||
|
On a side note, while I agree to modifying /stats like this, we should also take note: * /gline with no parameters returns both glines and gzlines * /gzline with no parameters returns both gzlines and glines I say we should limit: * /gline to only output glines * /gzline to only output gzlines And: * /stats G works like Aquanight posted in this bugnote. |
|
... So it does. I suppose that ought to be fixed as well. |
|
Might be nice to have a more flexible filter system too. I implemented one, tho not in the ircd itself. It a) allows filters to be globs or regexes, and b) allows the same flag/filter to be specified multiple times. I'll paste the help file in a separate comment. |
|
%BSecurityBot TKL%B is a series of functions to make TKL handling easier. Specifically it will help in handling G:lines and GZ:lines. Syntax is as follows: TKL LIST [(+/- filters) [params]] TKL DEL <(+/- filters) <params>> Filters are case-sensitive. Filter-parameters may be delimited by // (for regexps) or "" (for regexps or strings). Otherwise space delimiters are assumed. if there is a mismatch in the filter vs param count, the command WILL fail. Filters may be any of: Globbing filters r %BReason%B m %BMask%B (ident@host only) s %BSetter%B Regular Expression filters R %BReason%B M %BMask%B (ident@host only) S %BSetter%B Miscellaneous Filters O/o %BOrder by%B (Sort by) - case insensitive. negative is Descending, positive is Ascending. You can specify multiple of these, but the resulting sort order is not always intuitive. Default is type,time,host Ascending. Legal, but not necessarily meaningful for delete. Available sort fields: %Btype%B, %Bident%B, %Bhost%B, %Bsetter%B, %Bexpire%B, %Btime%B, %Breason%B. Example: TKL LIST -r+s *warez* *netadmin* would list all bans that do not include the word 'warez' and set by an oper with 'netadmin' in their vhost. |
|
I wouldn't necessarily expect all of it to be implemented... But I found it useful. |
|
Bump. Still a desired feature? |
|
Since, I have to usually resort to grep'ing my logfile, since my buffer isn't large enough for my gzline/gline list for me to use my client's "Find Function" |
|
I think the current +mrs searching is quite sufficient, but yeah it can be improved if someone really insists or submits a PR. I've implemented the limiting of output now and the user gets a nice notice with an example to use the +m searching. https://github.com/unrealircd/unrealircd/commit/4b53b022994ce5b2abca9aceda5e2ca02551fee0 Add set::max-stats-matches which limits output such as '/STATS gline' to the specified number of lines. This defaults to 1000. This will prevent IRCOps from being flooded off ("Max SendQ exceeded") if they list all *LINES and there are thousands. In the newly introduced error message, after too many matches, we also kindly point out to use filters like '/STATS gline +m *.nl' |
Date Modified | Username | Field | Change |
---|---|---|---|
2006-06-25 22:36 | aquanight | New Issue | |
2006-06-25 23:13 | Zell | Note Added: 0012016 | |
2006-06-25 23:15 | aquanight | Note Added: 0012017 | |
2006-06-26 16:28 | tabrisnet | Note Added: 0012024 | |
2006-06-26 16:28 | tabrisnet | Note Added: 0012025 | |
2006-06-26 16:29 | tabrisnet | Note Added: 0012026 | |
2007-04-27 02:59 |
|
Note Added: 0013759 | |
2007-04-27 02:59 |
|
Status | new => feedback |
2010-04-15 09:32 | driew | Note Added: 0016070 | |
2020-12-07 10:32 | syzop | Assigned To | => syzop |
2020-12-07 10:32 | syzop | Status | feedback => resolved |
2020-12-07 10:32 | syzop | Resolution | open => fixed |
2020-12-07 10:32 | syzop | Fixed in Version | => 5.0.8-rc1 |
2020-12-07 10:32 | syzop | Note Added: 0021845 |