Linux MP Update for SCOM 2016 UR1


 

image

 

An update was recently released.  This can be considered the “UR1” update for the SCOM 2016 Linux MP’s.  Note – these are for SCOM 2016 ONLY.  Do not attempt to import SCOM 2016 Linux MP’s into SCOM 2012. 

 

https://www.microsoft.com/en-us/download/details.aspx?id=29696

 

Make sure you get the correct version:

 

image

 

Download, extract, and import the MP’s that are relevant to what you monitor:

 

image

 

This will take a considerable amount of time to import, and consume a lot of CPU on the management servers and SQL server until complete.

 

Once it has completed, you will need to restart the Healthservice (Microsoft Monitoring Agent) on each management server, in order to get them to update their agent files at \Program Files\Microsoft System Center 2016\Operations Manager\Server\AgentManagement\UnixAgents

You should see the new files dropped with new timestamps:

image

 

Now you can deploy the agent updates:

 

image

 

image

 

Next – you decide if you want to input credentials for the SSH connection and upgrade, or if you have existing RunAs accounts that are set up to do the job (Agent Maintenance/SSH Account)

image

 

image

 

FAILED!!!

I am using an account as the agent maintenance account, and this is using SUDO elevation.  The error I got back was that ASKPASS and TTY unknown or unspecified.

This wasn’t correct, however, there command to run in the SUDOERS file is very specific – and this is probably my problem.

With the assistance of Tim Helton we looked for the error in /VAR/log/auth.log, where we found:

 

Jan  9 10:54:11 ubuntu sshd[35292]: pam_unix(sshd:session): session opened for user scxmaint by (uid=0)
Jan  9 10:54:11 ubuntu sudo: pam_unix(sudo:auth): conversation failed
Jan  9 10:54:11 ubuntu sudo: pam_unix(sudo:auth): auth could not identify password for [scxmaint]
Jan  9 10:54:11 ubuntu sudo: pam_unix(sudo:auth): conversation failed
Jan  9 10:54:11 ubuntu sudo: pam_unix(sudo:auth): auth could not identify password for [scxmaint]
Jan  9 10:54:11 ubuntu sudo: pam_unix(sudo:auth): conversation failed
Jan  9 10:54:11 ubuntu sudo: pam_unix(sudo:auth): auth could not identify password for [scxmaint]
Jan  9 10:54:11 ubuntu sudo: scxmaint : 3 incorrect password attempts ; TTY=unknown ; PWD=/home/scxmaint ; USER=root ; COMMAND=/bin/sh -c sh /tmp/scx-scxmaint/scx-1.6.2-337.universald.1.x64.sh --upgrade --force; EC=$?; cd /tmp; rm -rf /tmp/scx-scxmaint; exit $EC

 

When I compared this to my sample SUDOERS file from:  https://blogs.technet.microsoft.com/kevinholman/2016/11/11/monitoring-unixlinux-with-opsmgr-2016/  I can see the issue.

Example SUDOERS file:

#Linux

scxmaint ALL=(root) NOPASSWD: /bin/sh -c sh /tmp/scx-scxmaint/scx-1.[5-9].[0-9]-[0-9][0-9][0-9].universal[[\:alpha\:]].[[\:digit\:]].x[6-8][4-6].sh --install; EC=$?; cd /tmp; rm -rf /tmp/scx-scxmaint; exit $EC

scxmaint ALL=(root) NOPASSWD: /bin/sh -c sh /tmp/scx-scxmaint/scx-1.[5-9].[0-9]-[0-9][0-9][0-9].universal[[\:alpha\:]].[[\:digit\:]].x[6-8][4-6].sh --upgrade

 

The upgrade command we are trying to run (from the auth.log) doesn’t match the command in sudoers.  So I update the sudoers file line for upgrade to this:

scxmaint ALL=(root) NOPASSWD: /bin/sh -c sh /tmp/scx-scxmaint/scx-1.[5-9].[0-9]-[0-9][0-9][0-9].universal[[\:alpha\:]].[[\:digit\:]].x[6-8][4-6].sh --upgrade --force; EC=$?; cd /tmp; rm -rf /tmp/scx-scxmaint; exit $EC

 

Now:

 

image

 

So if you are getting a rights error from a sudo elevated account, always look in /var/log/messages or /var/log/auth and see if you can find a discrepancy in what you are attempting to run, versus what you have rights to run.

I will update the sample SUDOERS file to contain this change at https://blogs.technet.microsoft.com/kevinholman/2016/11/11/monitoring-unixlinux-with-opsmgr-2016/


Comments (6)

  1. Giulio Astori says:

    In my environment the .sh files inside the ../useragent/downloadedkit are not created .. actually the entire folder DownloadedKit is missing ... even after restarting the health service ..

    1. Kevin Holman says:

      Each version specific Linux/UNIX MP has a rule workflow targeting the Management Server class, and is run once per day, that calls a write action from Microsoft.Unix.Library.mp, that runs a powershell script on each MS to create that folder if it doesn't exist, then copy the files.

      If you are missing these after restarting the healthservice on your management servers, it is likely you have some other issues going on. It is also possible you erroneously configured the "Certificate Signing Write Action" runas profile - which can lead to this breaking.

      1. Giulio Astori says:

        Got it to work .. I was getting access denied to the root store, so i granted OM Action Account local admin rights and they were create right after

        1. Kevin Holman says:

          The OM Action account *requires* local admin rights for MANY reasons. On all management servers.

  2. Marcio Ota says:

    Errors since 2012 version...

    Microsoft.Linux.RHEL.7.NetworkAdapter.BytesSentPerSec.Collection
    O módulo não pôde converter o parâmetro em um valor duplo
    Parâmetro original: '$Data/Value$'
    Parâmetro após a substituição de $Data: '1.#QNAN'
    Erro: 0x80020005

    2017-03-14T17:05:04,528Z Trace [scx.core.common.pal.system.networkinterface:1328:434:140047943014528] for net device bond0 can not get supported speed, the supported value got by ioctl(,SIOCETHTOOL,) is : 0
    2017-03-14T17:05:04,528Z Trace [scx.core.common.pal.system.networkinterface:2041:434:140047943014528] NetworkInterfaceInfo::FindAll working on interface eno49
    2017-03-14T17:05:04,528Z Trace [scx.core.common.pal.system.networkinterface:2043:434:140047943014528] NetworkInterfaceInfo::FindAll Attribute SIOCGIFADDR
    2017-03-14T17:05:04,528Z Trace [scx.core.common.pal.system.networkinterface:2048:434:140047943014528] NetworkInterfaceInfo::FindAll Attribute SIOCGIFNETMASK
    2017-03-14T17:05:04,528Z Trace [scx.core.common.pal.system.networkinterface:2053:434:140047943014528] NetworkInterfaceInfo::FindAll Attribute SIOCGIFBRDADDR
    2017-03-14T17:05:04,528Z Trace [scx.core.common.pal.system.networkinterface:2058:434:140047943014528] NetworkInterfaceInfo::FindAll Attribute SIOCGIFMTU
    2017-03-14T17:05:04,528Z Trace [scx.core.common.pal.system.networkinterface:2069:434:140047943014528] NetworkInterfaceInfo::FindAll Attribute SIOCGIFFLAGS
    2017-03-14T17:05:04,528Z Trace [scx.core.common.pal.system.networkinterface:2093:434:140047943014528] NetworkInterfaceInfo::FindAll ParseIPv6Addr
    2017-03-14T17:05:04,528Z Trace [scx.core.common.pal.system.networkinterface:1328:434:140047943014528] for net device eno49 can not get supported speed, the supported value got by ioctl(,SIOCETHTOOL,) is : 681024
    2017-03-14T17:05:04,528Z Trace [scx.core.common.pal.system.networkinterface:2041:434:140047943014528] NetworkInterfaceInfo::FindAll working on interface eno51
    2017-03-14T17:05:04,528Z Trace [scx.core.common.pal.system.networkinterface:2043:434:140047943014528] NetworkInterfaceInfo::FindAll Attribute SIOCGIFADDR
    2017-03-14T17:05:04,528Z Trace [scx.core.common.pal.system.networkinterface:2048:434:140047943014528] NetworkInterfaceInfo::FindAll Attribute SIOCGIFNETMASK
    2017-03-14T17:05:04,528Z Trace [scx.core.common.pal.system.networkinterface:2053:434:140047943014528] NetworkInterfaceInfo::FindAll Attribute SIOCGIFBRDADDR
    2017-03-14T17:05:04,528Z Trace [scx.core.common.pal.system.networkinterface:2058:434:140047943014528] NetworkInterfaceInfo::FindAll Attribute SIOCGIFMTU
    2017-03-14T17:05:04,528Z Trace [scx.core.common.pal.system.networkinterface:2069:434:140047943014528] NetworkInterfaceInfo::FindAll Attribute SIOCGIFFLAGS
    2017-03-14T17:05:04,528Z Trace [scx.core.common.pal.system.networkinterface:2093:434:140047943014528] NetworkInterfaceInfo::FindAll ParseIPv6Addr

    1. Kevin Holman says:

      Was there a question in there somewhere?

Skip to main content