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

[Patrick_Boyd at Dell.com]

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