mnagel

Members
  • Content Count

    484
  • Joined

  • Last visited

  • Days Won

    81

Everything posted by mnagel

  1. If there are integrations to get arguments, properties, etc. I agree. Embedded Powershell with token references is acceptable (sometimes very awkward). Passing values to scripts with the current argument specification methods is not great. It might be overkill to wrap everything up into JSON for external scripts, but something along those lines might work.
  2. I have been working on a module to pull Cisco PSIRT Advisories per device. It is not complete yet, but thought it might be interesting to post since it does work, just not properly for production use (see below). It is also an example of how lack of library support forces cut-and-paste programming even within a single DS Please note that due to the way LM works, this cannot be deployed on more than a few devices as it stands!!!! Cisco has strict limits on the API and there is no reason to call more than daily for any platform/version pair, but you have no choice by default. I have some
  3. May have to do the same as I realized the data is entirely inaccessible for clear alerts (MESSAGE token is not provided to integrations). As a result, the clear alert subject is always generic even if the alert subject is customized. Seems more like a bug to me, but probably will have to be treated as a missing feature.
  4. Any movement on this? I have another use case where caching within LM would be very helpful -- API result caching. Cisco has an API to lookup vulnerabilities based on platform and version. They also have daily call limits. There is no reason to call on the same platform/version more than once per day, but the "LM way" would be to setup something akin to the MS Patch DS @Mike Suding wrote, so this needs to be bound to AD per host. I can hack around the issue by writing files, but it already bugs me that module scripts can even write files to begin with. Actually doing it makes me remember
  5. LMConfig does not send changes. It can alert that "something changed", which is about as useful as a red light in your car console saying "something is wrong". As far as the rest -- the issue is there is currently no viable way to solve this without bolting on an API method entirely outside of LM. I can do this, but I hate being forced to do it all the time. There are some simple fixes, like allow tables to display properties and allow setting properties without cutting and pasting 50+ lines of API code repeatedly (glad you are on that one!), that would make things much better. I have
  6. As far as a general table of results, that would also be awesome. Unfortunately, the only option for that is reports since dynamic tables cannot present properties, only numeric datapoints. Reports cannot be embedded in anything, including email, so they can't work for that. It would be super cool to have stuff like that in a widget with a bonus if there was a "changed recently" colorization option or even just a sort by change date.
  7. LMConfig is wrong for several reasons (which I thought I addressed earlier): * it is a premium feature that may not be subscribed to and if the only option here, a very large mallet for a simple problem * LMConfig does not report changes (we workaround this via API grabs with git email-on-push integration, but this is not a general solution for folks) Again, this is the example that caused me to think of how to best solve the problem -- another client uses SolarWinds and they get a notice when the firmware version changes. With strings and everything. I thought of a way to so
  8. Sure, that would work, but would be super maintenance intensive. I am just trying to do something SolarWinds can do out of the box, but as I often find, there are walls up all over the place :(.
  9. Perhaps, but not everything in version strings can easily be converted into a number. It might be a good enough workaround in this particular example (will see if I can make it work). We still need to be able to manipulate actual strings sometimes so this facility is still desirable.
  10. I actually received a module from support a ways back that does this, or at least part of it. It works, but due to the limited communication channel, results are similarly limited. Input is a property, which is scanned via AD to build the instances, then those are checked using the server the property is defined upon. I just published the version I have now, but since it is code, it could be available soon or in months -- there is no way to know :). WEW632
  11. I actually received a module from support a ways back that does this, or at least part of it. It works, but due to the limited communication channel, results are similarly limited. Input is a property, which is scanned via AD to build the instances, then those are checked using the server the property is defined upon. I just published the version I have now, but since it is code, it could be available soon or in months -- there is no way to know :). WEW632
  12. If this F/R was done, we could use properties to communicate non-numeric results. So many benefits.... )
  13. The last is needed as a primitive in LM. Going to "the API" is a PITA without library support.
  14. The MESSAGE token as it stands is a concatenation of the alert subject and alert message (custom or otherwise). Please add those elements separately, for example. MESSAGESUBJ and MESSAGEBODY. I have added code to split it out on our end, but this may not always be easy to do.
  15. We have concluded after some time that using groups to manage SDT for clients is the only real option (compared to repetitive manual effort by our clients) and realized we can grant manager access to "SDT groups" to allow clients to add/remove devices on their own. Except.... this also means they could remove the group itself. We need to be able to apply RBAC controls to group members only with the parent group protected from change or deletion.
  16. Due to lack of partitioning for MSP setups, we MUST use FQDNs for all devices, but when scans run, they put in the discovered barenames. Please allow scans to include an FQDN, either via the scan definition or a property. FQDNs break things like Windows Cluster checks, but it has to be done.
  17. There are gobs of reasons to be able to transform the raw tokens into meaningful rather than vanilla output. Most times, the output is just shy of "Something is wrong, good luck." We created a real template system for Nagios that provided very rich conditional information with callbacks to be able to collect additional data from impacted systems and this is one thing I really miss. LM has no apparent interest in doing anything like that, or at least has been silent in every F/R thread it has been mentioned within. My best option so far has been to send all tokens to our ticket system (whic
  18. In addition to enum management within modules, the right fix is to replace the simple token single-pass token substitution functionality with an actual templating engine. See https://docs.groovy-lang.org/docs/next/html/documentation/template-engines.html for a list -- LM needs to pick one and provide some sort of library function to enable management of template fragments.
  19. On a test run with some enum properties defined, no joy. Maybe it can be done via an undocumented method, like braces or something, or more likely there is just no support for constructing tokens this way. Help, I see a value of ##AUTO.ENUM.FAKEDS.FAKEDP.##VALUE####! Waaaah! I did create the enum mappings as a property source (could also just be manually defined at the root, but using a PS is a lot faster for many items). This will pollute the property list pretty badly when used extensively unless there is an option to keep them hidden in the UI. Enum support really needs to be add
  20. When we have portal upgrades, our API scripts fail hard with a long stream of 500 errors. I am generally aware and let it go, but I would be happy to check a status endpoint prior toi API activity and bounce out if an upgrade is in progress.
  21. I just thought of a hack that might work. In the AD section, generate a bunch of auto properties that look like auto.enum.DSName.DPName.enumValue = enumName (substituting your DS name, DP name and enum value/name pairs, of course). Then in your alert message you may be able to reference ##AUTO.ENUM.DSNAME.DPNAME.##VALUE####. I have not tested whether nested token references work, but if they do, this could take away some of the pain. It might work as well with or without AD to put the definitions into a propertysource. Complete conjecture at this point, but I will probably whip something
  22. You can reference properties (including automatic properties) as tokens, but there is no facility to send arbitrary text (e.g., enum to text lookup). Unfortunately, since the alert system is simple token substitution and has no programmatic capability, you cannot do any sort of conditional display or substitution. I have railed on this one virtually since we started with the product, but no joy, not even a hint of a plan to fix alerting. Our only option has been to use custom integrations with actual templating (like ERB, Template::Toolkit, etc.), but we have found various bugs (like custom
  23. Right, you must use IP. I just thought it might be nice to specify a hostname and have the DS resolve that for submission to the API.
  24. I cannot attach it here, but please copy from the link below (will need to setup keybase, but if you haven't, you should :)). keybase://public/ciscoqid/LogicMonitor/RBLCheckMulti-.xml It is still entirely done, but it is working. I need to add some documentation and tune it a bit. For this, I set applies to on all collectors, then you use the "Add Monitored Instance" on whichever collectors you want. The instances should have the hostname and IP as name and wildvalue, respectively. I did not code support (yet) for using a FQDN as the wildvalue, just IP.
  25. That works, just means you know "yes I am included, or no I am not included" and then you send folks to the URL in the alert. Not the end of the world, but would be nice to know what is wrong directly. May be possible to use this API (sparingly, I assume they would be less happy if you hit it too often so for any given IP) to discover the RBLs as instances, but then you would have to define the IP to check as a device with the DS applied. I suppose the count of hits might have to be enough, then the instances are the target IPs, arbitrarily tied to a device, probably a collector (like Ping