Enable/disable by class
list Galen Johnson
Hey, Pretty sure this isn't currently possible but what would it take to have the enable/disable script to allow en/disabling by class? Or even just being able to select the set of hosts based on class? =G=
list Jeremy Laidman
▸
On 5 February 2014 08:49, Galen Johnson <user-87f955643e3d@xymon.invalid> wrote:
Pretty sure this isn't currently possible but what would it take to have the enable/disable script to allow en/disabling by class? Or even just being able to select the set of hosts based on class?
Interesting idea. You could enhance maint_form to include the option, possibly in the "Filter hostlist" section, and adjust enadis.c to process it. The host list is populated from a xymondboard search, so you could use anything that that returns, such as XMH_NET, XMH_OS, XMH_DGNAME (group name) or XMH_PAGENAME, and filter based on that. What you're looking for is XMH_CLASS. The data for matching is retrieved by a call to fetch_board() (in lib/headfoot.c), which uses this xymondboard search: "xymondboard fields=hostname,testname,disabletime,dismsg". You'd have to add on "XMH_CLASS" to that, and then adjust the parsing code to handle and store the class string to be matched against. The actual filtering is also done in lib/headfoot.c, in the function wanted_host(), so you'd need to add a bit of code to compare the host class against the filter string. Cheers Jeremy
list Galen Johnson
Thanks, Jeremy...I took a stab at it but I'm no developer (just a lowly sys admin). I have to be missing something. The attached patch is what I attempted. It doesn't appear to break existing functionality but if you actually attempt to use the class filter, it fails. I can't get any useful output to figure out what I've missed. I suspect it has to do with your comment about fetch_board since I really don't understand what you're saying and the code itself doesn't seem to be anything obvious for how it's handling the other XMH types. Note, the patch was made against 4.3.15. It does compile cleanly. Any assistance here would be appreciated. =G=
▸
From: Jeremy Laidman <user-71895fb2e44c@xymon.invalid>
Sent: Tuesday, February 4, 2014 6:51 PM
To: Galen Johnson
Cc: xymon at xymon.com
Subject: Re: [Xymon] Enable/disable by class
On 5 February 2014 08:49, Galen Johnson <user-87f955643e3d@xymon.invalid<mailto:user-87f955643e3d@xymon.invalid>> wrote:
Pretty sure this isn't currently possible but what would it take to have the enable/disable script to allow en/disabling by class? Or even just being able to select the set of hosts based on class?
Interesting idea. You could enhance maint_form to include the option, possibly in the "Filter hostlist" section, and adjust enadis.c to process it. The host list is populated from a xymondboard search, so you could use anything that that returns, such as XMH_NET, XMH_OS, XMH_DGNAME (group name) or XMH_PAGENAME, and filter based on that. What you're looking for is XMH_CLASS.
The data for matching is retrieved by a call to fetch_board() (in lib/headfoot.c), which uses this xymondboard search: "xymondboard fields=hostname,testname,disabletime,dismsg". You'd have to add on "XMH_CLASS" to that, and then adjust the parsing code to handle and store the class string to be matched against. The actual filtering is also done in lib/headfoot.c, in the function wanted_host(), so you'd need to add a bit of code to compare the host class against the filter string.
Cheers
Jeremy
Attachments (1)
list Galen Johnson
here's a unified diff that will actually apply...it's late... =G=
▸
From: Galen Johnson
Sent: Wednesday, February 5, 2014 1:14 AM
To: Jeremy Laidman
Cc: xymon at xymon.com
Subject: RE: [Xymon] Enable/disable by class
Thanks, Jeremy...I took a stab at it but I'm no developer (just a lowly sys admin). I have to be missing something. The attached patch is what I attempted. It doesn't appear to break existing functionality but if you actually attempt to use the class filter, it fails. I can't get any useful output to figure out what I've missed. I suspect it has to do with your comment about fetch_board since I really don't understand what you're saying and the code itself doesn't seem to be anything obvious for how it's handling the other XMH types. Note, the patch was made against 4.3.15. It does compile cleanly.
Any assistance here would be appreciated.
=G=
From: Jeremy Laidman <user-71895fb2e44c@xymon.invalid>
Sent: Tuesday, February 4, 2014 6:51 PM
To: Galen Johnson
Cc: xymon at xymon.com
Subject: Re: [Xymon] Enable/disable by class
On 5 February 2014 08:49, Galen Johnson <user-87f955643e3d@xymon.invalid<mailto:user-87f955643e3d@xymon.invalid>> wrote:
Pretty sure this isn't currently possible but what would it take to have the enable/disable script to allow en/disabling by class? Or even just being able to select the set of hosts based on class?
Interesting idea. You could enhance maint_form to include the option, possibly in the "Filter hostlist" section, and adjust enadis.c to process it. The host list is populated from a xymondboard search, so you could use anything that that returns, such as XMH_NET, XMH_OS, XMH_DGNAME (group name) or XMH_PAGENAME, and filter based on that. What you're looking for is XMH_CLASS.
The data for matching is retrieved by a call to fetch_board() (in lib/headfoot.c), which uses this xymondboard search: "xymondboard fields=hostname,testname,disabletime,dismsg". You'd have to add on "XMH_CLASS" to that, and then adjust the parsing code to handle and store the class string to be matched against. The actual filtering is also done in lib/headfoot.c, in the function wanted_host(), so you'd need to add a bit of code to compare the host class against the filter string.
Cheers
Jeremy
Attachments (1)
list Galen Johnson
Even with fresher eyes, I'm not seeing anything obvious...I'm fairly certain the issue is in the headfoot.c code...possibly in the fetch_board or wanted function.
▸
On Wed, Feb 5, 2014 at 1:34 AM, Galen Johnson <user-87f955643e3d@xymon.invalid> wrote:
here's a unified diff that will actually apply...it's late... =G= *From:* Galen Johnson *Sent:* Wednesday, February 5, 2014 1:14 AM *To:* Jeremy Laidman *Cc:* xymon at xymon.com *Subject:* RE: [Xymon] Enable/disable by class Thanks, Jeremy...I took a stab at it but I'm no developer (just a lowly sys admin). I have to be missing something. The attached patch is what I attempted. It doesn't appear to break existing functionality but if you actually attempt to use the class filter, it fails. I can't get any useful output to figure out what I've missed. I suspect it has to do with your comment about fetch_board since I really don't understand what you're saying and the code itself doesn't seem to be anything obvious for how it's handling the other XMH types. Note, the patch was made against 4.3.15. It does compile cleanly. Any assistance here would be appreciated. =G= *From:* Jeremy Laidman <user-71895fb2e44c@xymon.invalid> *Sent:* Tuesday, February 4, 2014 6:51 PM *To:* Galen Johnson *Cc:* xymon at xymon.com *Subject:* Re: [Xymon] Enable/disable by class On 5 February 2014 08:49, Galen Johnson <user-87f955643e3d@xymon.invalid> wrote:Pretty sure this isn't currently possible but what would it take to have the enable/disable script to allow en/disabling by class? Or even just being able to select the set of hosts based on class?Interesting idea. You could enhance maint_form to include the option, possibly in the "Filter hostlist" section, and adjust enadis.c to process it. The host list is populated from a xymondboard search, so you could use anything that that returns, such as XMH_NET, XMH_OS, XMH_DGNAME (group name) or XMH_PAGENAME, and filter based on that. What you're looking for is XMH_CLASS. The data for matching is retrieved by a call to fetch_board() (in lib/headfoot.c), which uses this xymondboard search: "xymondboard fields=hostname,testname,disabletime,dismsg". You'd have to add on "XMH_CLASS" to that, and then adjust the parsing code to handle and store the class string to be matched against. The actual filtering is also done in lib/headfoot.c, in the function wanted_host(), so you'd need to add a bit of code to compare the host class against the filter string. Cheers Jeremy
list Jeremy Laidman
Galen
▸
On 6 February 2014 04:49, Galen Johnson <user-fc632e705d24@xymon.invalid> wrote:
Even with fresher eyes, I'm not seeing anything obvious...I'm fairly certain the issue is in the headfoot.c code...possibly in the fetch_board or wanted function.
I'm not a coder either - I just dabble. But let's see what the patch looks like. Ah, this might be the problem: - if (hostpattern || pagepattern || ippattern) - sethostenv_filter(hostpattern, pagepattern, ippattern); + if (hostpattern || pagepattern || ippattern, classpattern) + sethostenv_filter(hostpattern, pagepattern, ippattern, classpattern); In the third line above, you have a comma instead of a double-pipe "||". Everything else looks just fine. Cheers Jeremy
list Galen Johnson
Oh my god...I didn't even see that. Glad you caught it. Unfortunately, that didn't fix it...grrr....
▸
=G=
From: Jeremy Laidman <user-71895fb2e44c@xymon.invalid>
Sent: Thursday, February 6, 2014 11:36 PM
To: Galen Johnson
Cc: Galen Johnson; xymon at xymon.com
Subject: Re: [Xymon] Enable/disable by class
Galen
On 6 February 2014 04:49, Galen Johnson <user-fc632e705d24@xymon.invalid<mailto:user-fc632e705d24@xymon.invalid>> wrote:
Even with fresher eyes, I'm not seeing anything obvious...I'm fairly certain the issue is in the headfoot.c code...possibly in the fetch_board or wanted function.
I'm not a coder either - I just dabble. But let's see what the patch looks like.
Ah, this might be the problem:
- if (hostpattern || pagepattern || ippattern)
- sethostenv_filter(hostpattern, pagepattern, ippattern);
+ if (hostpattern || pagepattern || ippattern, classpattern)
+ sethostenv_filter(hostpattern, pagepattern, ippattern, classpattern);
In the third line above, you have a comma instead of a double-pipe "||".
Everything else looks just fine.
Cheers
Jeremy