View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001613 | unreal | ircd | public | 2004-03-02 04:42 | 2015-08-09 16:22 |
| Reporter | Cnils | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Platform | * | OS | * | OS Version | * |
| Product Version | 3.2.1 | ||||
| Fixed in Version | 3.4-beta3 | ||||
| Summary | 0001613: Send rehash notices to the server requesting the rehash | ||||
| Description | I'd like the rehash notices sent to the server/user requesting the rehash. When you rehash now and there is an error in the configuration, you won't know about it. | ||||
| Additional Information | [Syzop] would need some thought on how to implement... It's easy to just send stuff to someone from config_error/config_status but you would also have to deal with 'what if the remote user that started the rehash quits half-way during the rehash' [which is very real especially with remote includes], but... it sounds useful... if not too ugly I'll probably implement it. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
I take it you mean for a network with multiple servers...? If so, this is a good idea [remote rehashing and all] but how would it work...? |
|
|
Yes, when I rehash a remote server and there's an error in the config, there's no easy way of telling as it is. You could use stats or whatever appropriate to look for evidense of the change beeing made. But if the messages the rehashed server is generating was available you could see if/what/where there's an error. |
|
|
Yes, I fully agree with this. Sounds a nice idea, and would make life a lot easier. |
|
|
Yes there is only the one message that the server tells he is rehashing but if there are errors the are not displayed.... i think thats a nice "feauture" |
|
|
Yep, having a /stats something (R ?) which displays the last errors that occured on rehash could be useful I guess. Could be used locally also ... so that everyone could retrieve the last rehash problems, even if someone else did rehash the conf, while not having to rehash again to see the problem. The retrieval of the stats could be protected using the can_rehash flags also.. |
|
|
[quote]The retrieval of the stats could be protected using the can_rehash flags also..[/quote] Which every ircop gets no matter what. |
|
|
instead of sending all the info back over the network how about.. - on a remote rehash it writes to a log file?, if an error occured, it writes it to the log, and sends out a message saying an error was occured blah, otherwise if no errors, it says rehash`d with no errors however a draw bak is, if the oper rehashing it remotely doesnt have shell access they couldnt call the log file *mind u in saying that in 3.3* the web config will make it possibly for them to view the log without needing all the info* |
|
|
I'm kind of lost as to why a normal, routed notice can't be sent to a user, as far as I'm aware that would have no drawbacks (the notice about errors or whatever would just get dropped on the next hop if they logged off, right?) - or am I missing something here? |
|
|
[quote] [Syzop] would need some thought on how to implement... It's easy to just send stuff to someone from config_error/config_status but you would also have to deal with 'what if the remote user that started the rehash quits half-way during the rehash' [/quote] well ur not missing something, a notice would be sent out to the user, simply stating if the there was an error or not. however rather than sent the whole report, i think it would be better to be logged, incase as syzop says " the user disconnects half way thru ". It would also allow the server admin to see who issued the remote rehash if it was logged as well. |
|
|
Ideally, it'd do both log, and send a notice, so that if you didn't have shell access or whatever, you'd still know what happened (that is the whole point of this report :p) |
|
|
>if you didn't have shell access or whatever then why are you even rehashing let alone worrying about the results of such?! |
|
|
i use remote includes with nine ircds and i dont want to ssh at nine different servers to see in nine different logs "ahh the rehas is complete without failures" ;) so it would be nice to see the status of the rehas... a simple ok or nok is sufficient |
|
|
aquanight: let me correct myself then, to let ones self know if you need to login and check it..! let's just drop the scenario anyway. |
|
|
Eugh, on second thoughts.. I RTFS'd, and it's not looking as easy as I imagined. I imagine you'd pass an aClient to the function after m_rehash (can't remember the name now, did it like 2 days ago :P) of who's requesting a rehash and just send a notice to them or something? |
|
|
the way rehashes are done, it's a bitch to do this correctly, since we might have information escaping, since we don't have privmsg-to-user-identifier facilities.. a log facility / remote logging facility would be much better |
|
|
*bump* |
|
|
ehm yes... what about the rehash notify feauture? *g* three years old? really? ... but anyway ... is on my wishlist today! :) |
|
|
I would like to see this in 3.3. I'll see what I can do. |
|
|
not a release critical, but would be nice. |
|
|
Done. https://github.com/unrealircd/unrealircd/commit/fb157899dcd72cd0444bf676b5881e92b44a8664 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-03-02 04:42 | Cnils | New Issue | |
| 2004-03-10 19:11 | w00t | Note Added: 0005400 | |
| 2004-03-11 02:09 | Cnils | Note Added: 0005409 | |
| 2004-03-11 17:51 | w00t | Note Added: 0005433 | |
| 2004-03-23 16:54 | syzop | ETA | none => > 1 month |
| 2004-04-09 06:16 | diskman1 | Note Added: 0005803 | |
| 2004-07-08 11:44 | syzop | Status | new => acknowledged |
| 2004-07-08 11:46 | syzop | Product Version | 3.2-RC1 => 3.2.1 |
| 2004-07-08 11:46 | syzop | Additional Information Updated | |
| 2005-02-23 17:33 | syzop | Relationship added | has duplicate 0002369 |
| 2005-09-16 09:53 | Gilou | Note Added: 0010476 | |
| 2005-09-16 11:46 | aquanight | Note Added: 0010478 | |
| 2005-09-18 19:03 | White_Magic | Note Added: 0010488 | |
| 2005-09-20 01:46 | w00t | Note Added: 0010493 | |
| 2005-09-20 07:46 | White_Magic | Note Added: 0010494 | |
| 2005-09-22 01:36 | w00t | Note Added: 0010503 | |
| 2005-09-22 01:51 | aquanight | Note Added: 0010504 | |
| 2005-09-22 11:24 | diskman1 | Note Added: 0010505 | |
| 2005-09-23 05:55 | w00t | Note Added: 0010507 | |
| 2005-09-27 19:35 | w00t | Note Added: 0010522 | |
| 2005-11-11 03:07 |
|
Note Added: 0010696 | |
| 2007-04-22 12:03 | vonitsanet | Note Added: 0013631 | |
| 2007-04-22 12:17 | diskman1 | Note Added: 0013632 | |
| 2007-04-26 21:45 | WolfSage | Note Added: 0013748 | |
| 2007-04-27 04:25 |
|
Relationship added | has duplicate 0002641 |
| 2015-08-08 09:35 | syzop | Relationship added | has duplicate 0004178 |
| 2015-08-08 09:36 | syzop | Relationship added | has duplicate 0004357 |
| 2015-08-08 09:37 | syzop | Note Added: 0018589 | |
| 2015-08-09 16:22 | syzop | Note Added: 0018647 | |
| 2015-08-09 16:22 | syzop | Status | acknowledged => resolved |
| 2015-08-09 16:22 | syzop | Fixed in Version | => 3.4-beta3 |
| 2015-08-09 16:22 | syzop | Resolution | open => fixed |
| 2015-08-09 16:22 | syzop | Assigned To | => syzop |
