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:
Download, extract, and import the MP’s that are relevant to what you monitor:
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:
Now you can deploy the agent updates:
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)
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:
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/