aacraid style monitoring for megaraid2, use DELL_megaraid2.monitoring.tar.gz

[David Hubbard]

This is what happens when I try to run dellmgr on
a linux system as a regular user:

rm: cannot unlink `/dev/megadev0': Permission denied
mknod: `/dev/megadev0': Operation not permitted


        Error: Permission Denied
        Only superuser is allowed to run this utility

So it tries to remove something before checking who I
am.  And that's just a simple raid controller management
executable, not something huge like OMSA.

David 

> -----Original Message-----
> From: linux-poweredge-bounces at dell.com 
> [mailto:linux-poweredge-bounces at dell.com] On Behalf Of 
> Patrick_Boyd at dell.com
> Sent: Thursday, July 06, 2006 1:29 PM
> To: rmunsch at solutionsforprogress.com; 
> linux-poweredge at lists.us.dell.com
> Subject: RE: aacraid style monitoring for megaraid2,use 
> DELL_megaraid2.monitoring.tar.gz
> 
> Ok a couple of clarifications. I went back to a doc we had on 
> the security of the vendor libraries. This evaluation was 
> done on RedHat 7 and NT 4. There was one issue (now fixed) on 
> RedHat and there we OS issues in NT 4. The way that the NT 
> operating systems were sturctured would have allowed for some 
> attacks from non priviledged users if they knew how to 
> structure some IOCTLs.
> 
> So sorry I should have said non-priviledged users on NT 
> systems, since I believe Windows 2000 and greater had much 
> better IOCTL security checks.
> 
> So sorry I just remembered the non-privileged part and not 
> the fact that this was an NT 4 issue. And I'm pretty sure 
> that issue was fixed in one of the NT 4 service packs. So 
> sorry for freaking everybody out.
> 
> As for the 64-bit vs 32-bit debate. It's Dell's strategy to 
> only produce a 32-bit software package since 32-bit will run 
> on the 64-bit Oses and it reduces our testing and development cycles.
> 
> As for "we like redhat" we do also suport Suse starting with 
> SLES 9 SP3 and we have opened our drivers so that you should 
> be able to install just about an OS that you like.
> 
> -----Original Message-----
> From: linux-poweredge-bounces at dell.com
> [mailto:linux-poweredge-bounces at dell.com] On Behalf Of Rob Munsch
> Sent: Thursday, July 06, 2006 12:00 PM
> To: linux-poweredge-Lists
> Subject: Re: aacraid style monitoring for megaraid2,use 
> DELL_megaraid2.monitoring.tar.gz
> 
> David Hubbard wrote:
> 
> >From: Sean Dilda
> >  
> >
> >>Patrick_Boyd at dell.com wrote:
> >>    
> >>
> >>>That's a correct assesment of our support for 64-bit Oses. 
> >>>      
> >>>
> Sooo, instead of 'we support 64 bit OSes,' why not state 
> plainly 'we like redhat.' 
> "Arbitrary" linuxes..? come on...
> 
> >>
> >>>And there really are some bad things that non-root level 
> users could
> do if they had access to some of the source code in the RAID 
> management libraries.
> >>>      
> >>>
> woah woah woah hey what??!
> 
> >>If a non-root user can do bad things, then shouldn't the driver be 
> >>fixed to prevent that?  Along those same lines, wouldn't malicious 
> >>users be able to figure out how to do the 'bad things' if they just 
> >>read through the driver code?
> >>
> How is it that we can cycle through dell's "embracing" the 
> opensource community and redhat's growing "prominence(tm)", 
> and have to come full circle back to explaining first 
> principles of open source?
> 
> This is deeply disappointing, and one large eyeroll.  It's 
> really terrible when we have to boggle over the same stuff 
> Microsoft pretends not to get.  A sign saying "door should be 
> locked, please don't come in"
> 
> is no replacement for a deadbolt.
> 
> Now there is no oversight and no incentive for these closed 
> drivers to be fixed, and no way for us to tell if they are.
> hence, they are not trustable.
> hence, i cannot use them.
> 
> Ironically, if these secretive coders of your vendors had 
> thought to join FOSS properly.. they'd have had a great many 
> such issues fixed for them by now, for free, by people who'd 
> do it just because they believe it should be done.
> And the code would be trustable.  And it would be usable.
> 
> >That's the same reason we've never installed the management tools on 
> >any of our servers;
> >
> and i can certainly see why.  Very disappointing; with OMSA 
> 5.0 i was hoping to make use of these tools on our servers, 
> but i can safely abandon that project now and will be 
> pursuing a completely open-source hardware monitoring solution.
> 
> I hope sincerely that these vendors abandon their fear of the 
> light and understand how much it's in their own interests to 
> stop concealing flaws.  "You can't see this because it might 
> be broken horribly" is not the ideal selling point  o_O
> 
> --
> Rob Munsch
> Solutions For Progress IT
> www.solutionsforprogress.com
> 
> _______________________________________________
> Linux-PowerEdge mailing list
> Linux-PowerEdge at dell.com
> http://lists.us.dell.com/mailman/listinfo/linux-poweredge
> Please read the FAQ at http://lists.us.dell.com/faq
> 
> _______________________________________________
> Linux-PowerEdge mailing list
> Linux-PowerEdge at dell.com
> http://lists.us.dell.com/mailman/listinfo/linux-poweredge
> Please read the FAQ at http://lists.us.dell.com/faq
> 
>