0

Problem

After installing SCOM Linux Agent, the SCOM is properly monitoring Linux server, but detects no instance of Apache or MySQL, ie. no entry appears in SCOM either at following views:

  • Apache HTTP Server/Apache HTTP Servers
  • MySQL/MySQL Servers

According to all guides, docs and step-by-steps, above entries should be filled with those Linux servers, in which the Apache and MySQL instances were detected. These entries should be available before any further configuration steps and should provide simple configuration tasks for configuring most default scenarios.

Linux instances themselves are monitored properly.

I have listed below all the relevant information and logs as well as list of steps performed.

Any idea, what did I miss?

Environment

  • SCOM 2016 UR4 with most recent Management Packs of appropriate UNIX/Linux monitoring family (initial MP's from media upgraded with latest UR) and OSS (Apache, MySQL and common OSS MP)
  • CentOS Linux release 7.4.1708 (Core) with default Apache and MariaDB installation (no changes in config files)
  • Default SCOM Linux agent installed with following package versions:
    • scx-1.6.2-339.x86_64
    • mysql-cimprov-1.0.1-5.x86_64
    • apache-cimprov-1.0.1-9.x86_64
    • omi-1.2.0-35.x86_64 (this one manually upgraded from SCX-bundled 1.0.8 version that was not compatible with bundled ApacheHttpdProvider, bug filed)

Installation history

  • Configured users: scom-maint and scom-monit, along with appropriate RunAs accounts and profiles on the SCOM side
  • Configured /etc/sudoers.d/scom
  • SCX successfully installed via SCOM along with apache-cimprov and mysql-cimprov
  • Apache and MySQL monitoring in vanilla state, not configured (eg. Apache module not loaded, MySQL credentials not configured), as all configuration tasks should be available via the appropriate SCOM tasks that should be available within Apache/MySQL Servers views.

Logs and files

  • /var/opt/omi/log/omiagent.root.root.log
    Empty, excluding errors related to ApacheHttpdProvider to omi version compatibility, which ceased to appear after upgrading omi to 1.2.0
  • /var/opt/omi/log/omiserver.log
    Empty, excluding errors related to errors Failed to execute PREEXEC program that were related to this bug and ceased to appear after commenting out the default !includedir in /etc/my.cnf
  • /var/opt/microsoft/mysql-cimprov/log/mysqllog.log
    Logs few errors related to the unconfigured MySQL monitoring
  • /var/opt/microsoft/mysql-cimprov/log/scom-monit/mysqllog.log
    Quite similar to the previous file
  • /var/opt/microsoft/apache-cimprov directory contains no logs or files, there is only an empty run directory
  • /var/opt/scx/scx.log generated with verbose option does not contain apache/mysql keywords (checked with grep -i)
  • /var/opt/scx/scom-monit/scx.log contains no errors (just SCX Provider Module loaded)

Update 1

Found and investigating following entry repeating along each discovery cycle (every 4 hours) at /var/log/secure:

sudo: pam_unix(sudo:auth): conversation failed
sudo: pam_unix(sudo:auth): auth could not identify password for [scom-monit]
sudo: scom-monit : command not allowed ; TTY=unknown ; PWD=/var/opt/microsoft/scx/tmp ; USER=root ; COMMAND=/etc/opt/microsoft/scx/conf/tmpdir/scxuFPgv1

Last 6 characters of the COMMAND file are random.

Michał Sacharewicz
  • 569
  • 8
  • 25

1 Answers1

1

The problem was caused by incorrect RunAs account configuration. The profile assigned for monitoring was configured with sudo elevation enabled.

SCOM uses two profiles to monitor UNIX/Linux hosts:

  • UNIX/Linux Action Account
  • UNIX/Linux Privileged Account

Most guides advise you to use a single account for both purposes, but do not clearly state, that this single account must be defined in SCOM as two separate UNIX/Linux Accounts instances:

  • First instance should be configured with Elevate this account using sudo for privileged access and then assigned to the UNIX/Linux Privileged Account profile
  • Second instance should be configured with Do not use elevation with this account and then assigned to the UNIX/Linux Action Account profile

Now it seems that when SCX agent performs a task or a command, there is no attribute that directly specifies whether to use sudo or not, but whether to use a privileged account or not. And the elevation, as configured with the specific UNIX/Linux Action Account, is used regardless of whether it is required or not.

Michał Sacharewicz
  • 569
  • 8
  • 25