View Issue Details

IDProjectCategoryView StatusLast Update
0001613unrealircdpublic2015-08-09 16:22
ReporterCnils Assigned Tosyzop  
Status resolvedResolutionfixed 
Platform*OS*OS Version*
Product Version3.2.1 
Fixed in Version3.4-beta3 
Summary0001613: Send rehash notices to the server requesting the rehash
DescriptionI'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.
TagsNo tags attached.
3rd party modules


has duplicate 0002369 closed Get the result back on a remote rehash 
has duplicate 0002641 resolvedstskeeps Rehashing a remote server 
has duplicate 0004178 resolvedsyzop Remote Rehashing Should Report Rehash Status to Remote User 
has duplicate 0004357 resolvedsyzop Remote /REHASH error messages 



2004-03-10 19:11

reporter   ~0005400

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...?


2004-03-11 02:09

reporter   ~0005409

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.


2004-03-11 17:51

reporter   ~0005433

Yes, I fully agree with this. Sounds a nice idea, and would make life a lot easier.


2004-04-09 06:16

reporter   ~0005803

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"


2005-09-16 09:53

reporter   ~0010476

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..


2005-09-16 11:46

reporter   ~0010478

[quote]The retrieval of the stats could be protected using the can_rehash flags also..[/quote]

Which every ircop gets no matter what.


2005-09-18 19:03

reporter   ~0010488

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*


2005-09-20 01:46

reporter   ~0010493

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?


2005-09-20 07:46

reporter   ~0010494

[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.


2005-09-22 01:36

reporter   ~0010503

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)


2005-09-22 01:51

reporter   ~0010504

>if you didn't have shell access or whatever

then why are you even rehashing let alone worrying about the results of such?!


2005-09-22 11:24

reporter   ~0010505

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


2005-09-23 05:55

reporter   ~0010507

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.


2005-09-27 19:35

reporter   ~0010522

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?


2005-11-11 03:07

reporter   ~0010696

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


2007-04-22 12:03

reporter   ~0013631



2007-04-22 12:17

reporter   ~0013632

ehm yes... what about the rehash notify feauture? *g*
three years old? really?
... but anyway ... is on my wishlist today! :)


2007-04-26 21:45

reporter   ~0013748

I would like to see this in 3.3. I'll see what I can do.


2015-08-08 09:37

administrator   ~0018589

not a release critical, but would be nice.


2015-08-09 16:22

administrator   ~0018647


Issue History

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 stskeeps 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 stskeeps 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