1 2 Previous Next 27 Replies Latest reply on Feb 19, 2018 10:59 AM by Andrew Waters Go to original post
      • 15. Re: discovery.run commands & connection timeouts
        Mark Lemar

        As opposed to logging on to the target directly and running /opt/Tivoli/itm/bin/cinfo -d 2>/dev/null, I updated the pattern and re-scanned the host:

         

        Interestingly, the overall host scan time reduced from a typical 45 mins with multiple session logs, down to under 5 mins & a single session log.  We have version info and the session log looks like this:

         

        1 of 1 people found this helpful
        • 16. Re: discovery.run commands & connection timeouts
          Andrew Waters

          Yes - it would be much faster. In the case where the system cannot find the prompt has to wait for timeouts. This does not happen with the redirection, it knows quickly that the command has finished.

          3 of 3 people found this helpful
          • 17. Re: discovery.run commands & connection timeouts
            Mark Lemar

            Thanks for your assistance Andrew, extremely helpful as always.  I'll point the people working this case in the direction of this thread, to see if a redirect to stderr can be added to the TKU pattern.

            • 18. Re: discovery.run commands & connection timeouts
              Andrew Waters

              I have created a specific defect for adding the redirection DRDC1-9834

              1 of 1 people found this helpful
              • 19. Re: discovery.run commands & connection timeouts
                Mark Lemar

                Thanks Andrew.  I assume that defect relates specifically to the ITM pattern(s) & cinfo command?

                 

                I've since had a quick search of the patterns and can see that many others are coded to redirect to stdErr, for their respective commands.  As good practice, should this be done for each and every command?

                • 20. Re: discovery.run commands & connection timeouts
                  Mark Lemar

                  Hi Andrew,

                   

                  Just wondering if you can give me an update on defect DRDC1-9834 & a little bit more info as to how a fix for is actually going to be implemented?  I noticed that Sept'17 TKU has just been released, but don't believe any fix has been included in that?  On my support case, I asked if it would be a pattern update to the IBM Tivoli Monitoring pattern(s), which I believe it will be?  If so, will it be simply adding re-directs to StdError after the 'cinfo -d' command or will other code changes be made to ensure that SI versions are retained if the command fails from one scan to the next?  For example, will the pattern be updated to run the command elevated if it fails un-elevated?

                   

                  I deployed a custom pattern update to further test the redirect to StdErr, but this appears to have caused more occurrences of blank versions on other hosts, compared to running the command without the redirect in place.  Although we don't see the "Connection Timeout" errors with the redirect in place, we're seeing "Script ran but nothing was output" messages.

                   

                  I'm wondering if we're just best to run the 'cinfo -d' command elevated only, to ensure the version info is obtained consistently?

                  • 21. Re: discovery.run commands & connection timeouts
                    Andrew Waters

                    The defect has been committed for TKU October which will also try to rerun privileged command if it fails.

                    • 22. Re: discovery.run commands & connection timeouts
                      Mark Lemar

                      Thanks for the update.

                       

                      I'm going to test what results we get by just running the command elevated only.

                       

                      I believe the root cause of this issue is how my pattern handles failures/shell timeouts/script errors associated with the un-elevated command attempt.  On some occasions, the pattern is not able to process a failure & therefore doesn't attempt to run the command elevated, so no version info as a result.  On other scans of the same host, the un-elevated command will fail cleanly, which the pattern can interpret & will then attempt the elevated command & subsequently get the version info.

                      • 23. Re: discovery.run commands & connection timeouts
                        Mark Lemar

                        Whilst looking at a different pattern for another product, I've just noticed the DiscoveryFunctions.runActiveCommand function - (runs the command and then re-runs it with privileged permissions if needed).

                         

                        I assume that that defect fix will be creating a dependency between the ITM pattern(s) with the DiscoveryFunctions pattern & updating it if necessary?

                        • 24. Re: discovery.run commands & connection timeouts
                          Andrew Waters

                          At the time of writing there is already a dependency between them. But yes - there will be s specific version dependency requiring this DiscoveryFunctions.runActiveCommand.

                          1 of 1 people found this helpful
                          • 25. Re: discovery.run commands & connection timeouts
                            Mark Lemar

                            + an update to the cinfo command itself, to redirect to stdErr?

                             

                            Sorry for all the questions, it's just that I'm looking to enhance our custom pattern before this is fixed in the Oct TKU.

                            • 26. Re: discovery.run commands & connection timeouts
                              Mark Lemar

                              Although we've adopted the new TKU pattern for ITM & have seen an overall reduction in the number of discovered SIs with version number info missing, we still see intermittent occurrences of this issue from one day to next.

                               

                              We see this issue with ITM, as the respective discovery pattern attempts to get version info using a command, which generally works but may not on a given host from one day to the next.  Some of the root causes of the command failures may be fixable i.e. with the Unix security product we use, but others seem to be intermittent and perhaps may be something that can't be resolved for some products.

                               

                              I believe that this concept really goes beyond a particular product/pattern & wonder if this is something that Discovery could handle better in general?  I'm thinking along the lines of how SIs are maintained even if they're not seen on subsequent scans (based on model maintenance settings).  Would it be possible to force Discovery to retain a previously discovered version number for an SI, should one not be found on a subsequent scan, perhaps moving the previously discovered version number to a 'candidate/previous version number' attribute or something?  Tactically, I'd like to do something for ITM discovery as we have a hygiene policy which relies upon consistent ITM version data , but ultimately would like to see something like this adopted by Discovery for all products.

                               

                              Failing that & short of fixing all command failure nuances, the only other solution seems to be maintaining SI version number history data outside of Discovery, which would be far from ideal.

                              • 27. Re: discovery.run commands & connection timeouts
                                Andrew Waters

                                Realistically this would have to be pattern driven, i.e. skipping the attribute if no command runs successfully.

                                1 2 Previous Next