June, 2010

  • musc@> $daniele.work.ToString()

    OpsMgr Event IDs Spreadsheet

    • 4 Comments

    I work in support (mostly with System Center Operations Manager, as you know), and I work with event logs every day. The following are typical situations:

    1. I get a colleague or a customer telling me “I am having a problem and the SCOM agent is showing 21037 events and 20002 events.  What’s wrong with it?”   
    2. I want to tune an OpsMgr environment and reduce load on the database by turning off a few event collections, as my friend Kevin Holman suggests here http://blogs.technet.com/kevinholman/archive/2009/11/25/tuning-tip-turning-off-some-over-collection-of-events.aspx .
    3. I am analyzing, sorting and grouping Events with Powershell like I have written on my blog lately http://www.muscetta.com/2009/12/16/opsmgr-eventlog-analysis-with-powershell/ but I can’t read those long descriptions properly.
    4. I exported an EVT from a customer environment and I load it on a machine that does not have OpsMgr message DLLs installed – all I see are EventIDs and type (Warning, Error) – but no real description – and I still want to figure out what those events are trying to tell me.

    Getting to the point: I, like everyone – don’t have every OpsMgr event memorized.

    This is why I thought of building this spreadsheet, and I hope it might come in handy to more people.

    The spreadsheet contains an “AllEvents” list – and then the same events are broken down by event source as well:

    clip_image002

    When you want to search for an events (in one of the situations described above) just open up the spreadsheet, go to the “AllEvents” tab, hit CTRL+F (“Find”) and type in the Event ID you are searching for:

    clip_image004

    And this will take you to the row containing the event, so you can look up its description:

    clip_image006

    The description shows the event standard text (which is in the message DLL, therefore is the part you will not see if opening an EVT on another machine that does not have OpsMgr installed), and where the event parameters are (%1, %2, etc – which will be the strings you see in the EVT anyway).

    That way you can get an understanding of what the original message would have looked like on the original machine.

    This is just one possible usage pattern of this reference. It can also be useful to just read/study the events, learning about new ones you have never encountered, or remembering those you HAVE seen in the past but did not quite remember. And of course you can also find other creative ways to use it.

    You can get it from here.

     

    A few last words to give due credit: this spreadsheet has been compiled by using Eventlog Explorer (http://blogs.technet.com/momteam/archive/2008/04/02/eventlog-explorer.aspx ) to extract the event information out of the message DLLs on a OpsMgr2007 R2 installation. That info has been then copied and pasted in Excel in order to have an “offline” reference. Also I would like to thank Kevin Holman for pointing me to Eventlog Explorer first, and then for insisting I should not keep this spreadsheet in my drawer, as it could be useful to more people!

  • musc@> $daniele.work.ToString()

    How to convert (and fixup) the RedHat RPM to run on Debian/Ubuntu

    • 0 Comments

    In an earlier post I had shown how I got the Xplat agent running on Ubuntu. I perfected the technique over time, and what follows is a step-by-step process on how to convert and change the RedHat package to run on Debian/Ubuntu. Of course this is still a hack… but some people asked me to detail it a bit more. At the same time, the cross platform team is working to update the the source code on codeplex with extra bits that will make more straightforward to grab it, modify it and re-compile it than it is today. Until then, here is how I got it to work.

    I assume you have already copied the right .RPM package off the OpsMgr server’s /AgentManagement directory to the Linux box here. The examples below refer to the 32bit package, but of course the same identical technique would work for the 64bit version.

    We start by converting the RPM package to DEB format:

    root# alien -k scx-1.0.4-258.rhel.5.x86.rpm --scripts

    scx_1.0.4-258_i386.deb generated

     

    Then we need to create a folder where we will extract the content of the package, modify stuff, and repackage it:

    root# mkdir scx_1.0.4-258_i386

    root# cd scx_1.0.4-258_i386

    root# ar -x ../scx_1.0.4-258_i386.deb

    root# mkdir debian

    root# cd debian

    root# mkdir DEBIAN

    root# cd DEBIAN

    root# cd ../..

    root# rm debian-binary

    root# mv control.tar.gz debian/DEBIAN/

    root# mv data.tar.gz debian/

    root# cd debian

    root# tar -xvzf data.tar.gz

    root# rm data.tar.gz

    root# cd DEBIAN/

    root# tar -xvzf control.tar.gz

    root# rm control.tar.gz

    Now we have the “skeleton” of the package easily laid out on the filesystem and we are ready to modify the package and add/change stuff to and in it.

     

    First, we need to add some stuff to it, which is expected to be found on a redhat distro, but is not present in debian. In particular:

    1. You should copy the file “functions” (that you can get from a redhat/centos box under /etc/init.d) under the debian/etc/init.d folder in our package folder. This file is required/included by our startup scripts, so it needs to be deployed too.

    Then we need to chang some of the packacge behavior by editing files under debian/DEBIAN:

    2. edit the “control” file (a file describing what the package is, and does):

    'control' file

    3. edit the “preinst” file (pre-installation instructions): we need to add instructions to copy the “issue” file onto “redhat-release” (as the SCX_OperatingSystem class will look into that file, and this is hard-coded in the binary, we need to let it find it):

    'preinst' file

    these are the actual command lines to add for both packages (DEBIAN or UBUNTU):

    # symbolic links for libaries called differently on Ubuntu and Debian vs. RedHat

    ln -s /usr/lib/libcrypto.so.0.9.8 /usr/lib/libcrypto.so.6

    ln -s /usr/lib/libssl.so.0.9.8 /usr/lib/libssl.so.6

    the following bit would be Ubuntu-specific:

    #we need this file for the OS provider relies on it, so we convert what we have in /etc/issue

    #this is ok for Ubuntu (“Ubuntu 9.0.4 \n \l” becomes “Ubuntu 9.0.4”)

    cat /etc/issue | awk '/\\n/ {print $1, $2}' > /etc/redhat-release

    while the following bit is Debian-specific:

    #this is ok for Debian (“Debian GNU/Linux 5.0 \n \l” becomes “Debian GNU/Linux 5.0”)

    cat /etc/issue | awk '/\\n/ {print $1, $2, $3}' > /etc/redhat-release

     

    4. Then we edit/modify the “postinst” file (post-installation instructions) as follows:

    a. remove the 2nd and 3rd lines which look like the following

    RPM_INSTALL_PREFIX=

    export RPM_INSTALL_PREFIX

    as they are only useful for the RPM system, not DEB/APT, so we don’t need them.

    b. change the following 2 functions which contain RedHat-specific commands:

    configure_pegasus_service() {

               /usr/lib/lsb/install_initd /etc/init.d/scx-cimd

    }

    start_pegasus_service() {

               service scx-cimd start

    }

    c. We need to change in the Debian equivalents for registering a service in INIT and starting it:

    configure_pegasus_service() {

                   update-rc.d scx-cimd defaults

    }

    start_pegasus_service() {

                  /etc/init.d/scx-cimd start

    }

    5. Modify the “prerm” file (pre-removal instructions):

    a. Just like “postinst”, remove the lines

    RPM_INSTALL_PREFIX=

    export RPM_INSTALL_PREFIX

    b. Locate the two functions stopping and un-installing the service

    stop_pegasus_service() {

             service scx-cimd stop

    }

    unregister_pegasus_service() {

              /usr/lib/lsb/remove_initd /etc/init.d/scx-cimd

    }

    c. Change those two functions with the Debian-equivalent command lines

    stop_pegasus_service() {

               /etc/init.d/scx-cimd stop

    }

    unregister_pegasus_service() {

               update-rc.d -f scx-cimd remove

    }

    At this point the change we needed have been put in place, and we can re-build the DEB package.

    Move yourself in the main folder of the application (the scx_1.0.4-258_i386 folder):

    root# cd ../..

    Create the package starting from the folders

    root# dpkg-deb --build debian

    dpkg-deb: building package `scx' in `debian.deb'.

    Rename the package (for Ubuntu)

    root# mv debian.deb scx_1.0.4-258_Ubuntu_9_i386.deb

    Rename the package (for Debian)

    root# mv debian.deb scx_1.0.4-258_Debian_5_i386.deb

    Install it

    root# dpkg -i scx_1.0.4-258_Platform_Version_i386.deb

    All done! It should install and work!

     

    Next step would be creating a Management Pack to monitor Debian and Ubuntu. It is pretty similar to what Robert Hearn has described step by step for CentOS, but with some different replacements of strings, as you can imagine. I have done this but have not written down the procedure yet, so I will post another article on how to do this as soon as I manage to get it standardized and reliable. There is a bit more work involved for Ubuntu/Debian… as some of the daemons/services have different names, and certain files too… but nothing terribly difficult to change so you might want to try it already and have a go at it!

    In the meantime, as a teaser, here’s my server’s (http://www.muscetta.com) performance, being monitored with this “hack”:

    OpsMgr monitoring Debian

     

    Disclaimer

    The information in this weblog is provided "AS IS" with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my own personal opinion. All code samples are provided "AS IS" without warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.
    THIS WORK IS NOT ENDORSED AND NOT EVEN CHECKED, AUTHORIZED, SCRUTINIZED NOR APPROVED BY MY EMPLOYER, AND IT ONLY REPRESENT SOMETHING WHICH I'VE DONE IN MY FREE TIME. NO GUARANTEE WHATSOEVER IS GIVEN ON THIS. THE AUTHOR SHALL NOT BE MADE RESPONSIBLE FOR ANY DAMAGE YOU MIGHT INCUR WHEN USING THIS INFORMATION. The solution presented here IS NOT SUPPORTED by Microsoft.

Page 1 of 1 (2 items)