Tips or Tweaks for controlling when a daily ConfigSource runs?
I have a config source, that really under the hood is doing some other task, a coding task, and it used to conveniently run every day at 22:47 or something like that, but because of reasons, now it runs at 10:05 every morning. This is some ancient script someone else wrote in python and it runs on a collector. I’ll probably convert it to be groovy, and have it run hourly, but only act when the hour digit on the time is 22 or something wacky. But short of that, it did have me wonder, are there any tricky ways to change when a daily config source runs? Because from what I can tell, they run at the time they were made, or I guess at the last time the collector went down because of a domain password problem :) *cough*. I could just try a meaningless edit on the ConfigSource and see if that does it. I dont think bouncing the collector service will do it because on rare occasion the service restarts at a time other than its normal time and that doesnt change CS run times. Just wondering if anyone has any tips or tricks? I’ll probably just rewrite this to run hourly but act only on a specific hour of the day. But just fishing for ideas. I really wish we could schedule ConfigSources like we can reports. Thanks!
Tesla Motors LogicModule Suite
I previously published a datasource for Tesla Motors Battery Statistics - which presents compelling vehicle battery and charging information that is fetched from the Tesla REST API. To complement those efforts, I've written a few other Tesla Motors LogicModules that return a variety of different, but still interesting, datapoints - including a ConfigSource that displays configuration information about the vehicle itself (are the doors locked? Is the sunroof open?) The following is a list of all the Tesla Motors LogicModules now available (see the above-linked post for additional info on how this all works.) DataSource 'Battery Statistics' tracks battery and charger performance and health metrics Tesla Motors Battery Statisticspreviously posted to the Exchange but included here for sake of keeping everything together.) The datasource name isTeslaMotors_BatteryStatisticsand has lmLocatorDXLLKY. DataSource 'Climate Statistics' tracks inside and outside temperatures, as well as driver and passenger temperature settings. The datasource name isTeslaMotors_ClimateStatisticsand has lmLocatorYZRWXC. ConfigSource 'Car Configuration' collects textual configuration data, cleans it up and makes it easily readable (screenshot attached.) The configsource name isTeslaMotors_Configurationand has lmLocatorGRY9AE. DataSource 'Location Data' tracks compass heading, latitude and longitude, and power. The datasource name isTeslaMotors_LocationDataand has lmLocatorAYWYWA. DataSource 'Odometer Reading' does exactly what you might expect. The datasource name isTeslaMotors_BatteryStatisticsand has lmLocatorHHJRDWorkarounds for long ConfigSources?
I have a couple of devices where the Configis so long that the FortiOS Config shows “...Data Truncated...” in both the UI and the download. I looked in the code and so I know the limit and see that the ConfigSource is checking for a specific max size and displaying as much as it can (carving out room for the truncation message). Anyway, I’m assuming this is some UI limit, or else LM’s code would have just printed sections back to back, until done. So I’m wondering if anyone in the community has had the issue, and if anyone has a workaround? Thanks!Need help on PaloAlto_FW_RunningConfigXML API configsource
Currently, the sole option is to collect/view the configuration xml when a change occurs. So,IsthereawayinLMtogenerateareportusingthePaloAlto_FW_RunningConfigXMLAPIconfigsource? or Is it possible to collect the configuration backup at any specific time interval? Thanks in advance :)ConfigSource checks by Value regex quirks?
I made a ConfigSource which applies just to our LogicMonitor Account resource object, and it tracks changes to folders, in case anyone moves things they shouldnt. It runs once an hour. I’ve got it working (with some false error in it too to test the config check) but my Arbitrary Text checks by Value which use Regex just aren’t working, but they work on regex101 and I can see the capture groups work fine. But no matter what, I could never get an error to trigger when my output started with anything other than “OK” so I was forced to just switch to a groovy script check for the presence of “ERROR CHANGE:”. But again, I’m certain my regex is correct, and I verified it on Regex 101. So I’m just wondering if there are any known “quirks” about LogicMonitor’s regex or input stream from the config source that would be “Tricky” in any sense. For example, I already consider it weird that in AppliesTo checks with =~, which supposedly use Regex, are somehow case insensitive by default in LM, but arent in regex generally. Because I cannot for the life of me get the Value option with a capture group being not equal to OK to work in any sense. But my regex groups things fine in regex101. So I almost wonder if maybe ^ and $ dont apply, maybe the whole output is considered one line or something strange under the hood. I’m grasping at straws. ^([^:]+?):.*?$ ^([^:]+):.*$ All my output lines from my ConfigSource either start with OK: or they start with ERROR: …. and I’m throwing an error when the capture group has a value that is not equal to OK. So logically, if my regex value matches at all, it should throw an error now for sure, since I have lines with both in my output (I wont bore anyone with sample output). Anyway, I got my alerts working by using the groovy script check for a hard coded value, just wondering generally if there are any known quirks with Value checks. I know its possible somehow that I’ve just done something dumb too. But more broadly I’m wondering if there are any other known weird things? Thanks!Common Config Sources vs Legacy LM Config Sources
We use LM Config and have since day 1. I’m wondering if any of you have migrated off the legacy LM Config sources and onto the “Common Config” method? What sort of gaps in data did you have? I’m sort of stuck on the idea of having to dump one for another or potentially have some that work only with legacy vs Common methods? Seems like it could be hard to manage. Do you have any challenges today using the new way?
Finding Cisco IOS XE CVE-2023-20198 With ConfigSources
On October 16, 2023, Cisco published a vulnerability that affects IOS XE machines running the built-in web server:https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxe-webui-privesc-j22SaA4z This is tracked ashttps://nvd.nist.gov/vuln/detail/CVE-2023-20198 By adding a simple Config Check to an existing Cisco IOS ConfigSource, LogicMonitor can help people quickly identify which resources have the web server enabled. Here is an example: Name: Cisco-CSCwh87343-Check Check type: "Use Groovy Script" Groovy script: /* The built-in string variable 'config' contains the entire contents of the configuration file. The following example will trigger an alert when the configuration file contains the string "blue". if (config.contains("blue")) { return 1; } else { return 0; } */ if (config.contains("ip http")) { return 1; } else { return 0; } Then trigger this type of alert: Warning Description: "Search for presence of Cisco CSCwh87343 vulnerability" Caveats: -This will apply to all devices where the ConfigSource is used, even though all devices may not be affected by the vulnerability -This assumes usage of ConfigSources and specifically the Cisco_iOS ConfigSource Thanks to Todd Ritter for finding this CVE and Creating the ConfigSource
Common ConfigSource Documentation
Hello LogicMonitor community, I wanted to drop this here as it’s been something in the works for a long time. As I am sure many of your are all awareour development team has been working on and has actually released a new set of ConfigSources called “Common Configs”. These have been released into our core repository since late 2021 with support for more manufacturers and more features being added into these LogicModules throughout the last 2 years. The time has come that we have been able to get a support document around these Common Configs released with the requirements for them, optional parameters you can add to help them be successful, and thelist of all currently released modules related to this suite. https://www.logicmonitor.com/support/common-config-monitoring