Search the Community

Showing results for tags 'lmconfig'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • From LogicMonitor
    • General Announcements
    • LM Staff Contributions
    • Community Events
  • LogicMonitor Product Discussion
    • Feature Requests
    • LM Exchange
    • Ask the Community

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



About Me

Found 8 results

  1. Update: A ConfigSource, for use with LM Config, to monitor and alert on changes of route from the collector to any of a list of destinations. This is now combined a single ConfigSource that will run for both Windows and Linux collectors: v1.1.0: JGZ7GK If you really want to have a different ConfigSource per OS, the original two OS-specific ConfigSources are at: EK4HEG (Windows v1.5.0); HCPCXA (Linux v1.2.0). To use, you'll need to add a property 'traceroute.list' to the Windows or Linux collector device* you want to use to check the route from, with the value being a comma separated list of destinations, e.g. ',' *You can modify the AppliesTo such that this datasource could apply to any device, however it will always be the collector running the script and doing the traceroute / tracert. The ConfigSource will run the trace and print a summary of the results in a way that can easily be alerted on (if you really want to) in the event of a route change, plus a full dump of the route information including hop timings for information, in a way that is excluded from alerting. Credit to @Jake Cohen for the basis of the script these are built from.
  2. I have raised this numerous times with my CSM, account manager, etc. but it does not seem to be getting traction. It is a lawsuit waiting to happen, so it really deserves attention. Right now, the trigger for LMConfig is entirely arbitrary depending on who wrote which code. Most often it is based on ssh.user and ssh.pass being defined in a device. The problem with this is there are other reasons to have those properties (e.g., Err-Disabled port detection), so you can enable LMConfig across many devices and incur a large cost (especially with the new contract terms) without intent. It should be required to check off an "Enable LMConfig" option at the device or group level, and similarly for any other premium feature. Minimally, all the configsources should be changed to have a"enable_lmconfig" or similar property required in the Applies To logic.
  3. LM Config is awesome - but until now you've not been able to compare a config to a "known good" template. Now you can... Edit for v1.4.0+: Now gives a MUCH cleaner output (in my humble opinion) - see comments below for details. v1.4.0: 2GTW7W If you really want the earlier version with its more expansive output, v1.3.0 as detailed in this first post is at XHDDP4 Edit for v1.3.0+: The groovy check that picks up on the change-from-template flags is now more flexible, in that it looks at each line in turn (rather than the entire config object) so you can more carefully identify matches to be alerted on. This is very much only a proof-of-concept, which will show the method to use. As written it will do nothing in your account as it looks for a couple of test files I created specifically for this in my account. Suppose you have this template file (configTestTemplate.txt) for a config: # Config test file: # Here's a config test file Setting1=1 Setting2=2 Setting3=3 # The above must never be changed Now, suppose the actual config (in configTestConfig.txt) is like this: # Config test file: # Here's a config test file Setting1=1 Setting2=2 Setting3=4 # The above must never be changed If you can't see it, 'Setting3' has been changed... This ConfigSource will read in both the config (from file in this example, but it could be from SSH, etc) and the template from file, then run through the template and compare each line to the equivalent line in the config. Where it finds a discrepancy between the two, these are listed in the output after the actual config, marked with 'DISCREPANCY', as in the screenshot below. The template used for comparison is also returned: Config Checks then pick up on changes as you'd normally expect, and also if the output contains 'DISCREPANCY'. Notes: You must have LM Config to use this The template file must contain the EXACT same text in the EXACT same format as the config will be produced, because this PoC only checks line 1 against line 1, line 2 against line 2, etc. If your template contains 'DISCREPANCY' you'll have to come up with some other keyword to print and alert on, obviously.
  4. Hi Guys, We just implemented LMConfig and I'm trying to run a report to see what devices do not have the IOS configuration successfully downloaded. We have some legacy equipment still not Configured for SSH and TACACS accounts. so I'm trying to get out of having to manually hunting through all our devices to determine what ones need SSH configured and what ones need the TACACS account added. Even just being able to pull a report on all devices and what ones have the ConfigSources - IOS Configs field would be a big help. See attached pic for a visual Cheers and Thanks in advance Joel
  5. Currently, users need Manage rights to access the Config view. We need our junior sys admins to be able to view configurations without having the Manage rights. Please add a View only right for Config. The View Config right should only allow viewing of already collected configurations, but not permit Collect Now.
  6. Please add LMConfig collection tasks to Task Queue graph, see attached. We experience config retrieval failures a lot but we are unable to see if this is due to queuing or too many other tasks at the same time.
  7. Currently the only option available is to alert each time a config retrieval fails. I would like to be able to say "only alert if config retrieval fails n number of times in a row". For some of my devices, I'm not so concerned if daily config retrieval fails, but I'd like to know about it if it was failing for 3 or more days in a row.
  8. Currently, a ConfigSource only provides a limited choice of options for when to collect a device configuration (1 hour, 4 hours, 8 hours, 1 day). There is not control over when the collection occurs and it appears to automatically happen at or around midnight of each day. We have 1,000+ network devices and we are seeing frequent config retrieval failures, and we suspect it is because the Collector is trying to do too much at once. We are distributing the load to a second Collector, but with a couple of hundred, some collections fail. Sometimes it's just one of the four Cisco configs, other times all four fail. The request is to be able to somehow tell the Collectors to stagger their config collections.