Hi Jeff, We have dual direction monitoring. 1) OME does regular status polling of all devices. This is just a dumb "hey are you there" check.
2) We have all DRACs configured to send snmp alerts to OME and we have all alert options enabled. We have OME configured to send critical alert notifications it receives to our NOC. For 12 and 13 gen servers, this set up allows us to receive notification if a hard drive has failed or if a virtual disk is in a degraded state, if a DIMM, CPU, FAN etc needs to be replaced, voltage errors etc. We do the same for 11Gen but their level of reports is severely limited. I have to install MegaCli on all our 11Gen with custom bash scripts in a cron to alert our NOC of storage health issues. I manage hardware health of about 450 Dell servers this way. I use OME to upgrade the firmware on any server being reprovisioned but I prefer to do firmware upgrades on production machines manually uploading the updates through the DRAC GUI. OME is great for knowing what firmware versions are installed on your servers and knowing what the latest version available is and being able to easily access that file. Cameron On Tue, Apr 4, 2017 at 8:40 AM, Jeff Palmer <j...@palmerit.net> wrote: > Cameron, > > I'd be interested in hearing how you monitor hardware conditions via > the OOB/drac. > > We currently use nagios to query the omsa tools via the > check_openmanage plugin. But if there is a sane way to do the > equivalent via drac, I'd be all for it. > I tried a plugin once a while back that promised such functionality, > but we'd get alerts from OMSA, and the drac plugin would hum along > like everything was fine. Really frustrating for failed > disks/degraded arrays. So, I never got to where I trusted it (and > eventually gave up on it) > > > > > > On Tue, Apr 4, 2017 at 11:14 AM, Cameron Smith <came...@networkredux.com> > wrote: > > Dells OOB options work quite well. > > > > Either OME to fully update firmware remotely over DRAC connection or just > > use OME for firmware version awareness and manually update firmware > through > > DRAC. > > > > I left Dell OS level tools years ago due to memory leaks and > incompatibility > > issues. > > > > Cameron > > > > On Tue, Apr 4, 2017 at 2:42 AM, Diego Santa Cruz > > <diego.santac...@spinetix.com> wrote: > >> > >> Hi Dell, > >> > >> I had already removed OMSA from my servers due to issues like this. But > I > >> kept DSU on the assumption that as it was much simpler there was much > less > >> room for it to break things and I have now been proved wrong. I will > now be > >> removing DSU as well, so much for an easy way to update firmware... > Sigh! > >> > >> It is really sad to see that Dell does not take proper enterprise > >> seriously and allows for such problems to go on and on. Dell should > really > >> consider assigning someone with systems administration experience to > counsel > >> the DSU dev team and review their decisions. > >> > >> Next time I need to purchase more servers I'll take a good look at other > >> manufacturers..., I like Dell but this kind of problems really make my > life > >> more difficult. > >> > >> Best, > >> > >> -- > >> Diego Santa Cruz, PhD > >> IT Administrator > >> T +41 21 341 15 50 > >> diego.santac...@spinetix.com > >> spinetix.com > >> > >> -----Original Message----- > >> From: linux-poweredge-boun...@dell.com > >> [mailto:linux-poweredge-boun...@dell.com] On Behalf Of Tim Mooney > >> Sent: 03 April 2017 21:52 > >> To: linux-poweredge@dell.com > >> Subject: Re: [Linux-PowerEdge] dell-system-update package 1.4.0-17.02.00 > >> > >> In regard to: Re: [Linux-PowerEdge] dell-system-update package...: > >> > >> > I will say as a sysadmin that many project devs seem to just use > >> > newest versions of libs in their apps just "because they can" with out > >> > an real need and thus agrevate sysadmins supporting older OSes like > >> > RHEL6 for no good reason. Very much a pet peeve of mine. > >> > >> +1, and that's really crucial for developers to understand. They should > >> be depending on system libraries (and system commands) provided by the > OS > >> vendor if at all possible, and there should be an extremely good reason > (not > >> just "I want to", or "it's new and shiny") provided (and it should be > >> clearly communicated to the customer!) when they deviate from that. > >> > >> Even if Dell had carefully insulated their shadow copies of various > >> libraries from the rest of the OS, I still have a problem with > needlessly > >> shipping their own variants -- security updates. OS vendors are > typically > >> quick and coordinated when it comes to releasing updates for security > flaws. > >> If Dell's software depended on system libraries and commands only, then > >> DSU and other tools would get the security updates when the rest of the > OS > >> does. Dell's response to nearly every issue I've seen reported via this > >> list is "we'll fix it in 3-6 months in the next feature release", which > >> wouldn't cut it if there were a security issue with their local copy of > some > >> command or library. > >> > >> Tim > >> -- > >> Tim Mooney > tim.moo...@ndsu.edu > >> Enterprise Computing & Infrastructure 701-231-1076 > >> (Voice) > >> Room 242-J6, Quentin Burdick Building 701-231-8541 > (Fax) > >> North Dakota State University, Fargo, ND 58105-5164 > >> > >> _______________________________________________ > >> Linux-PowerEdge mailing list > >> Linux-PowerEdge@dell.com > >> https://lists.us.dell.com/mailman/listinfo/linux-poweredge > >> > >> _______________________________________________ > >> Linux-PowerEdge mailing list > >> Linux-PowerEdge@dell.com > >> https://lists.us.dell.com/mailman/listinfo/linux-poweredge > > > > > > > > _______________________________________________ > > Linux-PowerEdge mailing list > > Linux-PowerEdge@dell.com > > https://lists.us.dell.com/mailman/listinfo/linux-poweredge > > > > > > -- > Jeff Palmer > https://PalmerIT.net >
_______________________________________________ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
