Xymon PowerShell Windows client
Hi Zak,
I want to be able to see the network traffic in/out on each NIC on my windows machines running the new PowerShell client, I have never really looked into how this worked in bbwin but if I look at a few example machines I see the following:
On a Linux machine I get Network Traffic and TCP/IP Statics graphs on the trends page
a. Raw data contains [ifstat] and [netstat] information
On a windows machine running BBWin 0.13 I only get a TCP/IP Statics graph on the trends page
a. [ifstat] is blank
b. [netstat] contains data e.g
[netstat]
ipPacketsReceived=53513930 ipReceivedHeaderErrors=0 ipReceivedAddressErrors=355513 ipDatagramsForwarded=0 ipUnknownProtocolsReceived=2158 ipReceivedPacketsDiscarded=1266110 ipReceivedPacketsDelivered=52167159 ipOutputRequests=31961136 ipRoutingDiscards=0 ipDiscardedOutputPackets=5221 ipOutputPacketNoRoute=0 ipReassemblyRequired=730696 ipReassemblySuccessful=199056 ipReassemblyFailures=0 ipDatagramsSuccessfullyFragmented=0 ipDatagramsFailingFragmentation=0 ipFragmentsCreated=0
ipv6PacketsReceived=7895 ipv6ReceivedHeaderErrors=0 ipv6ReceivedAddressErrors=0 ipv6DatagramsForwarded=0 ipv6UnknownProtocolsReceived=0 ipv6ReceivedPacketsDiscarded=5199 ipv6ReceivedPacketsDelivered=7908 ipv6OutputRequests=2596918 ipv6RoutingDiscards=0 ipv6DiscardedOutputPackets=0 ipv6OutputPacketNoRoute=2 ipv6ReassemblyRequired=0 ipv6ReassemblySuccessful=0 ipv6ReassemblyFailures=0 ipv6DatagramsSuccessfullyFragmented=0 ipv6DatagramsFailingFragmentation=0 ipv6FragmentsCreated=0
On a windows machine running PowerShell client v1.98 I don't get any network related graphs however I seem to have data available:
a. [ifstat] contains data e.g
[ifstat]
fe80::25a5:b99d:55cd:951f%12 2655878237 519887923
10.250.100.163 2655878237 519887923
a. [netstat] contains data e.g
[netstat]
PacketsReceived=3387463
ReceivedHeaderErrors=0
ReceivedAddressErrors=51034
DatagramsForwarded=0
UnknownProtocolsReceived=0
ReceivedPacketsDiscarded=146872
ReceivedPacketsDelivered=3219450
OutputRequests=950747
RoutingDiscards=0
DiscardedOutputPackets=102
OutputPacketNoRoute=0
ReassemblyRequired=83643
ReassemblySuccessful=27881
ReassemblyFailures=0
DatagramsSuccessfullyFragmented=0
DatagramsFailingFragmentation=0
FragmentsCreated=0
PacketsReceived=1266
ReceivedHeaderErrors=0
ReceivedAddressErrors=0
DatagramsForwarded=0
UnknownProtocolsReceived=0
ReceivedPacketsDiscarded=618
ReceivedPacketsDelivered=1264
OutputRequests=11680
RoutingDiscards=0
DiscardedOutputPackets=0
OutputPacketNoRoute=2
ReassemblyRequired=0
ReassemblySuccessful=0
ReassemblyFailures=0
DatagramsSuccessfullyFragmented=0
DatagramsFailingFragmentation=0
FragmentsCreated=0
The netstat data in the PowerShell client doesn't seem to have the ip / ipv6 infront of the values so they are listed twice in the example above. So I'm not sure what graphs should I be expecting to get under trends with the PowerShell client for network traffic?
At the moment I'm guessing the ifstat data isn't in a format xymon will automatically graph and add to the trends page and the same for the netstat data possibly just because it has duplicate values for ipv4 and ipv6.
Regards,
Brandon
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of zak.beck at accenture.com Sent: Friday, 13 February 2015 8:53 PM To: xymon-developer at lists.sourceforge.net; xymon at xymon.com Subject: [Xymon] Xymon Powershell Windows client
Hi all,
Today I have uploaded a new version of the Xymon Powershell client to SVN (in sandbox/WinPSClient). We (Accenture) are very pleased to be contributing these changes to the open source community. I've been working on this now for around 8 months on and off and hopefully the changes made will be of benefit to everyone!
Whilst making changes, we have focussed mainly on making it work, improving reliability and most importantly improving performance.
In most cases, on our 64 bit OS virtual machines, a data collection now takes around 5 seconds. On heavily loaded (CPU load or event log load) servers, the script is now considerably faster than originally. Key to this has been reducing the amount of WMI usage as this was a major culprit.
We have also implemented some new features, largely based on our in-house requirements but hopefully useful to others:
Showing the process owner and command line in [procs]. This has been implemented using c# code, compiled at runtime.Adding Active Directory replication test, Terminal Services sessions testAbility to restart any stopped Windows serviceClient self-updateDirsize and dirtime checks (which were originally external scripts)
Some things have changed slightly; for example, the local configuration which was registry-based is now XML-based (you can still use registry settings if you prefer). In the SVN repository I have also uploaded a Word document which describes how to install and the configuration options.
I have uploaded all the revisions we have made to SVN so there is a history of development. Whilst we will endeavour to continue contributing changes and improvements in coming months, this is an open source project and as such we are not offering any formal support. If anyone wishes to bugfix, branch or whatever, please do so! Zak Beck Accenture
On 4 March 2015 at 13:26, Brandon Dale <BDale at kitchengroup.com.au> wrote:
On a windows machine running PowerShell client v1.98 I don’ta. [ifstat] contains data e.g
[ifstat]
fe80::25a5:b99d:55cd:951f%12 2655878237 519887923
10.250.100.163 2655878237 519887923
Yep, this should be parseable by Xymon. In principle.
At the moment I’m guessing the ifstat data isn’t in a format xymon will automatically graph and add to the trends page
Xymon will parse the [ifstat] data from a Windows machine, if it's in a suitable format. From the source code, the regexp for this is:
^([a-zA-Z0-9.:]+)\s+([0-9]+)\s+([0-9]+)I note that in the first [ifstat] line above, there's a percentage sign in the first token, which doesn't match the regexp. I don't know of Xymon continues on looking for other lines to match, or if it rejects the whole [ifstat] section as corrupt. But I wonder what would happen if the IPv6 address wasn't in the [ifstat] client data. Any chance you can unbind IPv6 for testing?
Another thing to note is that some of the "powershell" processing in Xymon just re-uses the "bbwin" processing. But there are some bits of parsing code, including for "ifstat" it seems, that only look for the bbwin OS string, and I can't see any place in the powershell handling code that tries to fake the bbwin OS for ifstat. In other words, could be that the code simply isn't there to do what you want. But it might also be the case that adjusting the powershell client to report itself as the bbwin client might do the trick.
J
Hi
Unfortunately, you can't fake the BBWin identifier for just one section – you have to change the client to report in as BBwin. It was changed so that we could experimentally use separate configuration options for BBWin clients and Powershell clients.
To change how the client reports itself, change line 2746 in the current commit:
2745 WriteLog "Performing main and optional tests and building output..."
2746 $clout = "client " + $clientname + ".powershell powershell XymonPS" | Out-String
2747 $clsecs = XymonClientSections | Out-String
In the original Powershell client, this line was:
$clout = "client " + $clientname + ".bbwin win32" | Out-StringSo you can see we've changed '.bbwin' to '.powershell' and 'win32' to 'powershell'.
I appreciate this isn't very good and should probably be a configuration item.
[netstat] uses the output from netstat -s, but it appears the parsing is not very clever. [ifstat] uses a .Net object to pull out interface information. I haven't changed the code that generates either of these sections – quite likely it needs some work! I'll add it to the list.
Zak
From: Jeremy Laidman [mailto:jlaidman at rebel-it.com.au] Sent: 04 March 2015 06:24 To: Brandon Dale Cc: Beck, Zak; xymon at xymon.com Subject: Re: [Xymon] Xymon PowerShell Windows client
On 4 March 2015 at 13:26, Brandon Dale <BDale at kitchengroup.com.au <mailto:BDale at kitchengroup.com.au> > wrote:
On a windows machine running PowerShell client v1.98 I don’t get any network related graphs however I seem to have data available:
a. [ifstat] contains data e.g
[ifstat] fe80::25a5:b99d:55cd:951f%12 2655878237 519887923 10.250.100.163 2655878237 519887923
Yep, this should be parseable by Xymon. In principle.
At the moment I’m guessing the ifstat data isn’t in a format xymon will automatically graph and add to the trends page
Xymon will parse the [ifstat] data from a Windows machine, if it's in a suitable format. From the source code, the regexp for this is:
^([a-zA-Z0-9.:]+)\s+([0-9]+)\s+([0-9]+)I note that in the first [ifstat] line above, there's a percentage sign in the first token, which doesn't match the regexp. I don't know of Xymon continues on looking for other lines to match, or if it rejects the whole [ifstat] section as corrupt. But I wonder what would happen if the IPv6 address wasn't in the [ifstat] client data. Any chance you can unbind IPv6 for testing?
Another thing to note is that some of the "powershell" processing in Xymon just re-uses the "bbwin" processing. But there are some bits of parsing code, including for "ifstat" it seems, that only look for the bbwin OS string, and I can't see any place in the powershell handling code that tries to fake the bbwin OS for ifstat. In other words, could be that the code simply isn't there to do what you want. But it might also be the case that adjusting the powershell client to report itself as the bbwin client might do the trick.
J
I added in bbwin identifier and those two graphs started to appear.
This is what I have under ifstat with ipv6 enabled.
[ifstat] fe80::25a5:b99d:55cd:951f%12 2677339075 541438677 10.250.100.163 2677339075 541438677 ::1 0 0 127.0.0.1 0 0
This is what ends up on the graph, , the ipv6 address with the % symbol doesn’t display which might be a problem for some.
[cid:image001.png at 01D056B7.8B4B5BC0]
I also changed the xymonifstat function on line 1895 in the ps client to get rid of the loop back addresses.
function XymonIfstat { WriteLog "XymonIfstat start" "[ifstat]" [System.Net.NetworkInformation.NetworkInterface]::GetAllNetworkInterfaces() | ?{($_.OperationalStatus -eq "Up") -and ($_.NetworkInterfaceType -ne "loopback")} | %{ $ad = $_.GetIPv4Statistics() | select BytesSent, BytesReceived $ip = $_.GetIPProperties().UnicastAddresses | select Address # some interfaces have multiple IPs, so iterate over them reporting same stats $ip | %{ "{0} {1} {2}" -f $_.Address.IPAddressToString,$ad.BytesReceived,$ad.BytesSent } } WriteLog "XymonIfstat finished." }
Output is:
[ifstat] fe80::25a5:b99d:55cd:951f%12 2678370580 543079717 10.250.100.163 2678370580 543079717
And now I don’t see the loopback addresses on the graph which “looks” better.
[cid:image002.png at 01D056BD.14C7A3E0]
Regards,
Brandon
From: zak.beck at accenture.com [mailto:zak.beck at accenture.com] Sent: Wednesday, 4 March 2015 7:48 PM To: jlaidman at rebel-it.com.au; Brandon Dale Cc: xymon at xymon.com Subject: RE: [Xymon] Xymon PowerShell Windows client
Hi
Unfortunately, you can't fake the BBWin identifier for just one section – you have to change the client to report in as BBwin. It was changed so that we could experimentally use separate configuration options for BBWin clients and Powershell clients.
To change how the client reports itself, change line 2746 in the current commit:
2745 WriteLog "Performing main and optional tests and building output..." 2746 $clout = "client " + $clientname + ".powershell powershell XymonPS" | Out-String 2747 $clsecs = XymonClientSections | Out-String
In the original Powershell client, this line was:
$clout = "client " + $clientname + ".bbwin win32" | Out-StringSo you can see we've changed '.bbwin' to '.powershell' and 'win32' to 'powershell'.
I appreciate this isn't very good and should probably be a configuration item.
[netstat] uses the output from netstat -s, but it appears the parsing is not very clever. [ifstat] uses a .Net object to pull out interface information. I haven't changed the code that generates either of these sections – quite likely it needs some work! I'll add it to the list. Zak
From: Jeremy Laidman [mailto:jlaidman at rebel-it.com.au] Sent: 04 March 2015 06:24 To: Brandon Dale Cc: Beck, Zak; xymon at xymon.com<mailto:xymon at xymon.com> Subject: Re: [Xymon] Xymon PowerShell Windows client
On 4 March 2015 at 13:26, Brandon Dale <BDale at kitchengroup.com.au<mailto:BDale at kitchengroup.com.au>> wrote: 3. On a windows machine running PowerShell client v1.98 I don’t get any network related graphs however I seem to have data available:
a. [ifstat] contains data e.g
[ifstat]
fe80::25a5:b99d:55cd:951f%12 2655878237 519887923
10.250.100.163 2655878237 519887923
Yep, this should be parseable by Xymon. In principle.
At the moment I’m guessing the ifstat data isn’t in a format xymon will automatically graph and add to the trends page
Xymon will parse the [ifstat] data from a Windows machine, if it's in a suitable format. From the source code, the regexp for this is:
^([a-zA-Z0-9.:]+)\s+([0-9]+)\s+([0-9]+)I note that in the first [ifstat] line above, there's a percentage sign in the first token, which doesn't match the regexp. I don't know of Xymon continues on looking for other lines to match, or if it rejects the whole [ifstat] section as corrupt. But I wonder what would happen if the IPv6 address wasn't in the [ifstat] client data. Any chance you can unbind IPv6 for testing?
Another thing to note is that some of the "powershell" processing in Xymon just re-uses the "bbwin" processing. But there are some bits of parsing code, including for "ifstat" it seems, that only look for the bbwin OS string, and I can't see any place in the powershell handling code that tries to fake the bbwin OS for ifstat. In other words, could be that the code simply isn't there to do what you want. But it might also be the case that adjusting the powershell client to report itself as the bbwin client might do the trick.
J
Hi
Thanks for the patch.
Regarding the BBwin / powershell identifier, my proposal is to default to bbwin but to allow this to be overridden using the local client XML config – does this sound reasonable?
The %<number> stuff is the zone index (https://en.wikipedia.org/wiki/IPv6_address#Link-local_addresses_and_zone_ind...) – i.e. the adaptor number.
I'm not sure how useful this is to Xymon and could probably be removed with a slight amendment to your patch like the following:
function XymonIfstat
{
WriteLog "XymonIfstat start"
"[ifstat]"
[System.Net.NetworkInformation.NetworkInterface]::GetAllNetworkInterfaces() | ?{($_.OperationalStatus -eq "Up") -and ($_.NetworkInterfaceType -ne "loopback")} | %{
$ad = $_.GetIPv4Statistics() | select BytesSent, BytesReceived
$ip = $_.GetIPProperties().UnicastAddresses | select Address
# some interfaces have multiple IPs, so iterate over them reporting same stats
$ip | %{ "{0} {1} {2}" -f ($_.Address.IPAddressToString –replace '%\d+'), $ad.BytesReceived,$ad.BytesSent }
}
WriteLog "XymonIfstat finished."}
I have not tested this but I think it should work.
Thanks
Zak Beck Infrastructure Tech Support Specialist Accenture Tel: +44 (0) 1785 764609 Email: zak.beck at accenture.com <mailto:zak.beck at accenture.com>
Upcoming PTO (leave): Feb 20th, April 7th-10th, Jul 3rd, Jul 24th-Aug 10th
Our core values: Stewardship - Best People - Client Value Creation - One Global Network - Respect for the Individual - Integrity
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.
Accenture means Accenture (UK) Limited (registered number 4757301), registered in England and Wales with registered address at 30 Fenchurch Street, London EC3M 3BD.
From: Brandon Dale [mailto:BDale at kitchengroup.com.au] Sent: 04 March 2015 09:58 To: Beck, Zak; jlaidman at rebel-it.com.au Cc: xymon at xymon.com Subject: RE: [Xymon] Xymon PowerShell Windows client
I added in bbwin identifier and those two graphs started to appear.
This is what I have under ifstat with ipv6 enabled.
[ifstat]
fe80::25a5:b99d:55cd:951f%12 2677339075 541438677
10.250.100.163 2677339075 541438677
::1 0 0
127.0.0.1 0 0
This is what ends up on the graph, , the ipv6 address with the % symbol doesn’t display which might be a problem for some.
I also changed the xymonifstat function on line 1895 in the ps client to get rid of the loop back addresses.
function XymonIfstat
{
WriteLog "XymonIfstat start"
"[ifstat]"
[System.Net.NetworkInformation.NetworkInterface]::GetAllNetworkInterfaces() | ?{($_.OperationalStatus -eq "Up") -and ($_.NetworkInterfaceType -ne "loopback")} | %{
$ad = $_.GetIPv4Statistics() | select BytesSent, BytesReceived
$ip = $_.GetIPProperties().UnicastAddresses | select Address
# some interfaces have multiple IPs, so iterate over them reporting same stats
$ip | %{ "{0} {1} {2}" -f $_.Address.IPAddressToString,$ad.BytesReceived,$ad.BytesSent }
}
WriteLog "XymonIfstat finished."}
Output is:
[ifstat]
fe80::25a5:b99d:55cd:951f%12 2678370580 543079717
10.250.100.163 2678370580 543079717
And now I don’t see the loopback addresses on the graph which “looks” better.
Regards,
Brandon
From: zak.beck at accenture.com <mailto:zak.beck at accenture.com> [mailto:zak.beck at accenture.com] Sent: Wednesday, 4 March 2015 7:48 PM To: jlaidman at rebel-it.com.au <mailto:jlaidman at rebel-it.com.au> ; Brandon Dale Cc: xymon at xymon.com <mailto:xymon at xymon.com> Subject: RE: [Xymon] Xymon PowerShell Windows client
Hi
Unfortunately, you can't fake the BBWin identifier for just one section – you have to change the client to report in as BBwin. It was changed so that we could experimentally use separate configuration options for BBWin clients and Powershell clients.
To change how the client reports itself, change line 2746 in the current commit:
2745 WriteLog "Performing main and optional tests and building output..."
2746 $clout = "client " + $clientname + ".powershell powershell XymonPS" | Out-String
2747 $clsecs = XymonClientSections | Out-String
In the original Powershell client, this line was:
$clout = "client " + $clientname + ".bbwin win32" | Out-StringSo you can see we've changed '.bbwin' to '.powershell' and 'win32' to 'powershell'.
I appreciate this isn't very good and should probably be a configuration item.
[netstat] uses the output from netstat -s, but it appears the parsing is not very clever. [ifstat] uses a .Net object to pull out interface information. I haven't changed the code that generates either of these sections – quite likely it needs some work! I'll add it to the list.
Zak
From: Jeremy Laidman [mailto:jlaidman at rebel-it.com.au] Sent: 04 March 2015 06:24 To: Brandon Dale Cc: Beck, Zak; xymon at xymon.com <mailto:xymon at xymon.com> Subject: Re: [Xymon] Xymon PowerShell Windows client
On 4 March 2015 at 13:26, Brandon Dale <BDale at kitchengroup.com.au <mailto:BDale at kitchengroup.com.au> > wrote:
On a windows machine running PowerShell client v1.98 I don’t get any network related graphs however I seem to have data available:
a. [ifstat] contains data e.g
[ifstat] fe80::25a5:b99d:55cd:951f%12 2655878237 519887923 10.250.100.163 2655878237 519887923
Yep, this should be parseable by Xymon. In principle.
At the moment I’m guessing the ifstat data isn’t in a format xymon will automatically graph and add to the trends page
Xymon will parse the [ifstat] data from a Windows machine, if it's in a suitable format. From the source code, the regexp for this is:
^([a-zA-Z0-9.:]+)\s+([0-9]+)\s+([0-9]+)I note that in the first [ifstat] line above, there's a percentage sign in the first token, which doesn't match the regexp. I don't know of Xymon continues on looking for other lines to match, or if it rejects the whole [ifstat] section as corrupt. But I wonder what would happen if the IPv6 address wasn't in the [ifstat] client data. Any chance you can unbind IPv6 for testing?
Another thing to note is that some of the "powershell" processing in Xymon just re-uses the "bbwin" processing. But there are some bits of parsing code, including for "ifstat" it seems, that only look for the bbwin OS string, and I can't see any place in the powershell handling code that tries to fake the bbwin OS for ifstat. In other words, could be that the code simply isn't there to do what you want. But it might also be the case that adjusting the powershell client to report itself as the bbwin client might do the trick.
J
That works
[ifstat] fe80::25a5:b99d:55cd:951f 2725199676 586864638 10.250.100.163 2725199676 586864638
And it displays on the trends page. Still not perfect however as in most cases you don’t want to see both graphed as the traffic is going to be exactly the same. Ideally some logic to choose which to display would work best.
Regards,
Brandon
From: zak.beck at accenture.com<mailto:zak.beck at accenture.com> [mailto:zak.beck at accenture.com] Sent: Thursday, 5 March 2015 2:16 AM To: Brandon Dale; jlaidman at rebel-it.com.au<mailto:jlaidman at rebel-it.com.au> Cc: xymon at xymon.com<mailto:xymon at xymon.com> Subject: RE: [Xymon] Xymon PowerShell Windows client
Hi
Thanks for the patch.
Regarding the BBwin / powershell identifier, my proposal is to default to bbwin but to allow this to be overridden using the local client XML config – does this sound reasonable?
The %<number> stuff is the zone index (https://en.wikipedia.org/wiki/IPv6_address#Link-local_addresses_and_zone_ind...) – i.e. the adaptor number.
I'm not sure how useful this is to Xymon and could probably be removed with a slight amendment to your patch like the following:
function XymonIfstat { WriteLog "XymonIfstat start" "[ifstat]" [System.Net.NetworkInformation.NetworkInterface]::GetAllNetworkInterfaces() | ?{($_.OperationalStatus -eq "Up") -and ($_.NetworkInterfaceType -ne "loopback")} | %{ $ad = $_.GetIPv4Statistics() | select BytesSent, BytesReceived $ip = $_.GetIPProperties().UnicastAddresses | select Address # some interfaces have multiple IPs, so iterate over them reporting same stats $ip | %{ "{0} {1} {2}" -f ($_.Address.IPAddressToString –replace '%\d+'), $ad.BytesReceived,$ad.BytesSent } } WriteLog "XymonIfstat finished." }
I have not tested this but I think it should work.
Thanks Zak Beck Infrastructure Tech Support Specialist Accenture Tel: +44 (0) 1785 764609 Email: zak.beck at accenture.com<mailto:zak.beck at accenture.com> Upcoming PTO (leave): Feb 20th, April 7th-10th, Jul 3rd, Jul 24th-Aug 10th Our core values: Stewardship - Best People - Client Value Creation - One Global Network - Respect for the Individual - Integrity This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.
Accenture means Accenture (UK) Limited (registered number 4757301), registered in England and Wales with registered address at 30 Fenchurch Street, London EC3M 3BD.
Zak,
Unfortunately, you can't fake the BBWin identifier for just one section – you have to change the client to report in as BBwin. It was changed so that we could experimentally use separate configuration options for BBWin clients and Powershell clients.
To change how the client reports itself, change line 2746 in the current commit:
2745 WriteLog "Performing main and optional tests and building output..." 2746 $clout = "client " + $clientname + ".powershell powershell XymonPS" | Out-String 2747 $clsecs = XymonClientSections | Out-String
In the original Powershell client, this line was:
$clout = "client " + $clientname + ".bbwin win32" | Out-String
So you can see we've changed '.bbwin' to '.powershell' and 'win32' to 'powershell'.
I appreciate this isn't very good and should probably be a configuration item.
Changing the client from bbwin to something else is less harmful. Changing class from win32 to powershell will probably break LOTS of stuff. I suspect many users migrating from BBWin use "class=win32" in analysis.cfg (hobbit-clients.cfg) file extensively. The class is probably also used in the section parsing -> status reports/RRD data extraction. It will also break the config segment returned from client-local.cfg - e.g.
[win32] dir:C:\Windows\Temp log:c:\WINDOWS\WindowsUpdate.log:20480
David.
-- David Baldwin - Senior Systems Administrator (Datacentres + Networks) Information and Communication Technology Services Australian Sports Commission http://ausport.gov.au Tel 02 62147830 Fax 02 62141830 PO Box 176 Belconnen ACT 2616 david.baldwin at ausport.gov.au 1 Leverrier Street Bruce ACT 2617 Our Values: RESPECT + INTEGRITY + TEAMWORK + EXCELLENCE
Keep up to date with what's happening in Australian sport visit http://www.ausport.gov.au
This message is intended for the addressee named and may contain confidential and privileged information. If you are not the intended recipient please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you receive this message in error, please delete it and notify the sender.
The problem is if you are running both bbwin and the powershell client you need a way to be able to setup separate commands in the client-local.cfg for each type of client.
Regards,
Brandon
From: David Baldwin [mailto:david.baldwin at ausport.gov.au] Sent: Thursday, 5 March 2015 8:57 AM To: zak.beck at accenture.com; jlaidman at rebel-it.com.au; Brandon Dale Cc: xymon at xymon.com Subject: Re: [Xymon] Xymon PowerShell Windows client
Zak, Unfortunately, you can't fake the BBWin identifier for just one section – you have to change the client to report in as BBwin. It was changed so that we could experimentally use separate configuration options for BBWin clients and Powershell clients. To change how the client reports itself, change line 2746 in the current commit: 2745 WriteLog "Performing main and optional tests and building output..." 2746 $clout = "client " + $clientname + ".powershell powershell XymonPS" | Out-String 2747 $clsecs = XymonClientSections | Out-String
In the original Powershell client, this line was: $clout = "client " + $clientname + ".bbwin win32" | Out-String So you can see we've changed '.bbwin' to '.powershell' and 'win32' to 'powershell'. I appreciate this isn't very good and should probably be a configuration item. Changing the client from bbwin to something else is less harmful. Changing class from win32 to powershell will probably break LOTS of stuff. I suspect many users migrating from BBWin use "class=win32" in analysis.cfg (hobbit-clients.cfg) file extensively. The class is probably also used in the section parsing -> status reports/RRD data extraction. It will also break the config segment returned from client-local.cfg - e.g.
[win32] dir:C:\Windows\Temp log:c:\WINDOWS\WindowsUpdate.log:20480
David.
--
David Baldwin - Senior Systems Administrator (Datacentres + Networks)
Information and Communication Technology Services
Australian Sports Commission http://ausport.gov.au
Tel 02 62147830 Fax 02 62141830 PO Box 176 Belconnen ACT 2616
david.baldwin at ausport.gov.au<mailto:david.baldwin at ausport.gov.au> 1 Leverrier Street Bruce ACT 2617
Our Values: RESPECT + INTEGRITY + TEAMWORK + EXCELLENCE
Keep up to date with what's happening in Australian sport visit www.ausport.gov.au<http://www.ausport.gov.au>
This message is intended for the addressee named and may contain confidential and privileged information. If you are not the intended recipient please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you receive this message in error, please delete it and notify the sender.
On 5/03/15 10:07 AM, Brandon Dale wrote:
The problem is if you are running both bbwin and the powershell client you need a way to be able to setup separate commands in the client-local.cfg for each type of client.
If BBWin will just ignore (or at least be unaffected by) the ones it doesn't understand then that shouldn't be a problem, it's only if there are mutual incompatibilities that should be an issue.
David.
Regards,
*Brandon *
*From:*David Baldwin [mailto:david.baldwin at ausport.gov.au] *Sent:* Thursday, 5 March 2015 8:57 AM *To:* zak.beck at accenture.com; jlaidman at rebel-it.com.au; Brandon Dale *Cc:* xymon at xymon.com *Subject:* Re: [Xymon] Xymon PowerShell Windows client
Zak,
Unfortunately, you can't fake the BBWin identifier for just one section – you have to change the client to report in as BBwin. It was changed so that we could experimentally use separate configuration options for BBWin clients and Powershell clients. To change how the client reports itself, change line 2746 in the current commit: 2745 WriteLog "Performing main and optional tests and building output..." 2746 $clout = "client " + $clientname + ".powershell powershell XymonPS" | Out-String 2747 $clsecs = XymonClientSections | Out-String In the original Powershell client, this line was: $clout = "client " + $clientname + ".bbwin win32" | Out-String So you can see we've changed '.bbwin' to '.powershell' and 'win32' to 'powershell'. I appreciate this isn't very good and should probably be a configuration item.Changing the client from bbwin to something else is less harmful. Changing class from win32 to powershell will probably break LOTS of stuff. I suspect many users migrating from BBWin use "class=win32" in analysis.cfg (hobbit-clients.cfg) file extensively. The class is probably also used in the section parsing -> status reports/RRD data extraction. It will also break the config segment returned from client-local.cfg - e.g.
[win32] dir:C:\Windows\Temp log:c:\WINDOWS\WindowsUpdate.log:20480
David.
-- David Baldwin - Senior Systems Administrator (Datacentres + Networks) Information and Communication Technology Services Australian Sports Commissionhttp://ausport.gov.au Tel 02 62147830 Fax 02 62141830 PO Box 176 Belconnen ACT 2616 david.baldwin at ausport.gov.au <mailto:david.baldwin at ausport.gov.au> 1 Leverrier Street Bruce ACT 2617 Our Values: RESPECT + INTEGRITY + TEAMWORK + EXCELLENCE
Keep up to date with what's happening in Australian sport visit www.ausport.gov.au <http://www.ausport.gov.au>
This message is intended for the addressee named and may contain confidential and privileged information. If you are not the intended recipient please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you receive this message in error, please delete it and notify the sender.
-- David Baldwin - Senior Systems Administrator (Datacentres + Networks) Information and Communication Technology Services Australian Sports Commission http://ausport.gov.au Tel 02 62147830 Fax 02 62141830 PO Box 176 Belconnen ACT 2616 david.baldwin at ausport.gov.au 1 Leverrier Street Bruce ACT 2617 Our Values: RESPECT + INTEGRITY + TEAMWORK + EXCELLENCE
Say I was mixing the commands and had this in client-local.cfg and it applied to both bbwin and powershell clients I might end up with something like:
eventlogswanted:*:250000:warning,critical,error
clientversion:1.98:\\testserver01\test
eventlog:security:10240
ignore “insert some noisy informational event you are ignoring for bbwin but isn’t relevant for PowerShell as it’s not retrieving informational events”
It looks confusing, the eventlog:log_name:max_size command would work for both clients just the powershell client won’t read the size. And Just in general it’s hard to tell which client is doing what. Maybe a solution is to have all the powershell commands start with something unique to the client so the commands can never overlap with bbwin.
Regards,
Brandon
From: David Baldwin [mailto:david.baldwin at ausport.gov.au] Sent: Thursday, 5 March 2015 10:46 AM To: Brandon Dale; zak.beck at accenture.com; jlaidman at rebel-it.com.au Cc: xymon at xymon.com Subject: Re: [Xymon] Xymon PowerShell Windows client
On 5/03/15 10:07 AM, Brandon Dale wrote: The problem is if you are running both bbwin and the powershell client you need a way to be able to setup separate commands in the client-local.cfg for each type of client. If BBWin will just ignore (or at least be unaffected by) the ones it doesn't understand then that shouldn't be a problem, it's only if there are mutual incompatibilities that should be an issue.
David.
Regards,
Brandon
On 04/03/2015 7:49 PM, <zak.beck at accenture.com> wrote:
Unfortunately, you can't fake the BBWin identifier for just one section – you have to change the client to report in as BBwin. It was changed so that we could experimentally use separate configuration options for BBWin clients and Powershell clients.
Of course the best option is to extend the server to match the features of the client. It wouldn't take much (like one line) to add the powershell OS into the ifstat handler, running the same code as for bbwin.
J
participants (4)
-
BDale＠kitchengroup.com.au
-
david.baldwin＠ausport.gov.au
-
jlaidman＠rebel-it.com.au
-
zak.beck＠accenture.com