locked
SCEP 2012 System Center Monitoring Pack for Linux v4.5.10.1 Problem RRS feed

  • Question

  • Hi Everyone!

    We are having a problem with OpsMgr 2012 R2 and the System Center Monitoring Pack for SCEP 2012 for Linux v4.5.10.1.  We have successfully deployed the Linux OpsMgr 2012 R2 agent to our test CentOS 6.5 VM as well as SCEP 2012 v4.5.10.1.  We have imported the System Center Monitoring Pack for SCEP 2012 for Linux management packs into OpsMgr 2012 R2 which is successfully discovering SCEP on our Linux VM, but when looking at the details for the monitor, it indicates that SCEP is "not found" as seen in the following screen shot...

    As seen in the following screen shots, everything else seems to be installed, configured, and working properly...

    Any assistance or guidance would be greatly appreciated!

    Regards,

    JJ

    Wednesday, February 5, 2014 1:51 AM

All replies

  • Additional screen shots...

    Wednesday, February 5, 2014 1:53 AM
  • More screen shots...

    Ad(Thanks)vance for any assistance!

    Regards,

    JJ

    Wednesday, February 5, 2014 1:54 AM
  • Hi,

    Were you able to find a fix?  We are having the same problem with our SCEP for Linux and SCOM 2012 R2 monitoring.  The discovery process is either not working or not finding SCEP on the Linux server (we are running SLES 11).

    Thanks,

    Thursday, December 4, 2014 5:03 PM
  • Sorry, no and don't hold your breath if you are expecting anyone from Microsoft to chime in and help with this.  I'd suggest looking at another solution like we did.

    Regards,

    JJ

    Thursday, December 4, 2014 10:12 PM
  • Magnus_001 (big ups) and I were able to get discovery to stop failing on the Linux side of things, but the SCOM MP is still highly problematic.  Their pdf guides for SCEP implementation on Linux has a bunch of typos and errors -- for example, listing '/bin/sh' instead of '/bin/bash', and one of the lines (the one that includes "export LANG=C" won't run no matter what.  When we disassembled the SCOM MP, we found that there's an extraneous space at the end of the command, current thought is that that's causing a regex to fail within sudo.  All of their commands, from what I can tell, need to be specified as NOPASSWD within sudo; if you see errors about ssh-askpass with that you can confirm that there are likely typos in their guide sourced from the pdf.  We eventually allowed '/bin/bash' to get the programs to run since we couldn't get a regex match to catch their command (which should be in a script).  We are out of failures that we can discover with logging on the Linux side; it's likely to be an error within the MP at this point.

    When we look at the powershell script in the MP library, the "not found" error is the default state, set immediately after stdout is captured from the discovery script.  I'm guessing that there's some problem interaction between that script and the parsing thereof, as when we run the script locally as root we see the output that we'd expect. For all I know that's a line ending or locale problem.

    Troubleshooting on the linux end is problematic, as instead of distributing a script to check on the linux side (which makes the sudo part of things much easier), the script is hard-coded within the MP.  From what I understand it would need to be disassembled and recompiled to change.

    The snippet below may be of use to someone for use in their sudoers file, it will make the checks work on the linux side at least.  I wouldn't recommend this for anything beyond testing, as specifying that an account can run a full bash shell as root without a password is a terrible idea.

    ---------------

    #replace scomactionaccount with whatever your scom action account is called

    User_Alias SCOM = scomactionaccount
    Runas_Alias SCOM = root
    SCOM ALL = (SCOM) NOPASSWD: /opt/microsoft/scx/bin/scxlogfilereader -p
    SCOM ALL = (SCOM) NOPASSWD: /bin/bash

    ---------------

    Monday, March 9, 2015 9:49 PM