Hi, I'm debating purchasing a NetAppliance fileserver that does native CIFS. Below is a URL to a NetAppliance authored paper regarding performance. One of the sections compares NFS to CIFS and talks about Samba. Can anyone dispute any of this? Is there any reason besides price that I should stick with Samba? -Ed Ed Sanborn (978) 691-6496 Northchurch Communications Inc. 5 Corporate Drive Andover, MA. 01810 Fax (978) 691-6300 http://www.northchurch.net
In a message dated: Tue, 22 Jun 1999 03:36:07 +1000 "Sanborn, Ed" said:>Is there any reason besides price that I should stick with Samba?Pro-Samba Argument: PDC capability Much better control over who accesses what filesystems. Access to source code. A great mailing list to support you with very good response time Tons of documentations The ability to set up as many or as few Samba servers as you want/need for the same price Thousands of people using/testing/beating on/improving the software A much better price then NetApp Pro-NetApp Argument: A corporate-backed piece of software An expensive price tag on a per-server basis Quite slow tech support response time Someone for management to blame/sue when it doesn't work as well. I love NetApps. I have 3 of them. I won't buy the CIFS license because: 1. To expensive 2. Not enough flexibility 3. No PDC support 4. Tech support isn't that great with NFS, why would CIFS support be any better? By the way, you can configure Samba to map filesystems based on automount points coming from a NetApp box. That's how I do it here. I hope that helps. -- Seeya, Paul ---- plussier@baynetworks.com Broadband Technology Division - Bay Networks (now a Nortel Company, Eh? :) If you're not having fun, you're not doing it right!
Greetings: I just wanted to comment on some of this (hopefully without starting a religious war)....> Pro-Samba Argument: > PDC capabilityYup, the "experimental" PDC capability is pretty cool. Since NetApp filers are "file service appliances" this might be better considered an advantage over an NT server or Advanced Server for UNIX.> Much better control over who accesses what filesystems.Sorry if I seem ignorant of a particular Samba or UNIX functionality but I'm not sure what you mean here. It might be argued that the reverse is true since NetApp natively supports both UNIX style file permissions and NTFS style permissions (ACLs). Based on my limited experience, the new ACL functionality introduced with Samba 2.0.4 (which BTW I think is a very nifty addition)is merely a way for an NT savvy admin to manipulate the underlying UNIX file permissions via Windows Explorer. Oh and don't forget that DOS attributes, such as the "archive bit," are mapped to the UNIX "x" bits which may present problems in multiprotocol environments. Here's a quote from John D. Blair's book "Samba Integrating UNIX and Windows" copyright 1998, page 239: "The unusual changes in execute permissions may disrupt use of files from UNIX users.> Access to source code.Can't argue with that.> A great mailing list to support you with very good response timeThere's also a NetApp filer mailing list (which we _don't_ host but our engineers _do_ participate in) with good response time. Just send an email to majordomo@mathworks.com with (no quotes) "subscribe toasters" in the body of the message.> Tons of documentationsYes, there are a few books out there and decent on-line documentation. NetApp also provides decent on-line documentation in addition to the manuals. Additionally, we have quite a number of white papers posted at: http://www.netapp.com/technology/ Perhaps you were unaware of it but there's also an online knowledge base at now.netapp.com> The ability to set up as many or as few Samba servers as you want/need > for the same priceThis is true if you don't factor in hardware costs.> Thousands of people using/testing/beating on/improving the softwareNetApp also has many thousands of people using/testing/beating on filers (the next web site you hit may have a filer back ending it). It is true, though, that the number of our engineers "improving" the software is considerably lower than the number of people contributing to the Samba code. Wouldn't the "improving" point be the same thing as "Access to source code" above (essentially ye olde "open source vs. closed source" argument)?> A much better price then NetAppIsn't this the same point you make above?> Pro-NetApp Argument: > A corporate-backed piece of software...and hardware with native NTFS/UNIX file permissions, a really cool snapshot feature (which saved many users from ruin when the worm virus hit), RAID protection built into file system, on-line volume expansion (with a single command and no down time), quotas, a warranty and telephone support.> An expensive price tag on a per-server basisSamba is indeed free but what happens when you factor in the cost an enterprise-class UNIX server?> Quite slow tech support response timePerhaps when compared to the always-someone-reading-it-around-the-world-at-any-given-time Samba digest. But then again, you seem not to be counting the "toasters" mailing list which can provide equally fast response times. You only have to wait on your internet connection and query speed when using the NetApp knowledge base. I know things are changing but who are you going to _call_ when you have a Samba issue and you don't own an SGI box (and even then how long will the response times be)? I've never been on the customer side of NetApp but I have been in IT organizations of large companies so I know what it can be like trying to get support. Even the best company in the world (who ever it may be) will have customers that are dissatisfied with the support. To my knowledge, our support isn't as notoriously slow as you seem to imply. What about our Auto Support feature? Customers frequently receive new hard drives in the mail before they even know that is has gone bad.> Someone for management to blame/sue when it doesn't work as well.Yikes!> I love NetApps. I have 3 of them. I won't buy the CIFS license because: > > 1. To expensiveSure the CIFS license is more expensive than $FREE but we feel that NetApp offers a better CIFS implementation as well as better Windows/UNIX integration. I don't want to go any further off topic than I already have so if anyone wants to take a look at a good white paper on the subject, check out: http://www.netapp.com/technology/level3/3014.html> 2. Not enough flexibilityA filer is a file service appliance that is designed to do one thing extremely well, serve files. It's not a general purpose server, designed to do a decent job at many things. Within the scope of being a file service appliance, filers are indeed very flexible.> 3. No PDC supportI'm just as excited as everyone else is about the PDC support but the limited (no trust relationships, no BDC, etc.) implementation isn't officially supported (yet) either.> 4. Tech support isn't that great with NFS, why would CIFS support be > any better?Not everyone shares the same opinion. I'm sorry if you've had a bad experience and would be more than happy to take this up with you off-line and see that you get a resolution to your problem. Best regards, Paul Benn Network Appliance paul@netapp.com
Paul Benn wrote :> > Much better control over who accesses what filesystems. > > Sorry if I seem ignorant of a particular Samba or UNIX functionality but I'm not > sure what you mean here. It might be argued that the reverse is true since > NetApp natively supports both UNIX style file permissions and NTFS style > permissions (ACLs).This is true. But it doesn't provide a very understandable mapping from a complex ACL when accessed from an NT client to a UNIX permission when accessed from an NFS client. My problem with your design (which I know quite a bit about, funnily enough :-), is that it violates the principle of least suprises for the nfs user. ie. They may get access denied when the UNIX perms say they should be granted access.> Based on my limited experience, the new ACL functionality > introduced with Samba 2.0.4 (which BTW I think is a very nifty addition)is > merely a way for an NT savvy admin to manipulate the underlying UNIX file > permissions via Windows Explorer.No arguement there, as this is exactly what it is designed to do. I'm still awaiting judgement on the user requests for true ACLs (which we can do by mapping into POSIX ACLs, when enough UNIX's support them). Most NT software simply doesn't use the NT ACL design. Nice though it is from a security point of view, for most users it is just unimaginably complex. There's something to be said for just providing UNIX permissions :-).> Oh and don't forget that DOS attributes, such > as the "archive bit," are mapped to the UNIX "x" bits which may present problems > in multiprotocol environments. Here's a quote from John D. Blair's book "Samba > Integrating UNIX and Windows" copyright 1998, page 239: "The unusual changes in > execute permissions may disrupt use of files from UNIX users.Yep, very true and without kernel access not something that's easy to fix.> > Thousands of people using/testing/beating on/improving the software > > NetApp also has many thousands of people using/testing/beating on filers (the > next web site you hit may have a filer back ending it).Not on the same order of magnitude though. Trust me on this (by the volume of email I get :-).> > Quite slow tech support response time > > Perhaps when compared to the > always-someone-reading-it-around-the-world-at-any-given-time Samba digest. But > then again, you seem not to be counting the "toasters" mailing list which can > provide equally fast response times. You only have to wait on your internet > connection and query speed when using the NetApp knowledge base. I know things > are changing but who are you going to _call_ when you have a Samba issue and you > don't own an SGI box (and even then how long will the response times be)?This is a straw man. Have you looked at the Samba consultants list ? This is also not even mentioning such companies as IBM & HP who are now supporting Linux (all versions of which include Samba), LinuxCare, RedHat, Caldera and a host of other companies (I can't even remember them all). Remember - every "Linux Certified Engineer" will also be able to support Samba :-). I recently came back from Linux Expo Paris where there were many consulting companies exhibiting on the show floor who were offering commercial Samba and Linux support. Contrast this with NetApp where support is only available from one company.> Sure the CIFS license is more expensive than $FREE but we feel that NetApp > offers a better CIFS implementation as well as better Windows/UNIX integration.Well this is one of those "the market will decide" things :-) :-). And the customers always win those :-). Cheers, Jeremy Allison, Samba Team. -- -------------------------------------------------------- Buying an operating system without source is like buying a self-assembly Space Shuttle with no instructions. --------------------------------------------------------
> -----Original Message----- > From: Jeremy Allison [mailto:jallison@cthulhu.engr.sgi.com] > Sent: Wednesday, June 23, 1999 1:19 PM> My problem with your design (which I know quite a bit about, > funnily enough :-), is that it violates the principle of > least suprises for the nfs user. ie. They may get access > denied when the UNIX perms say they should be granted access.But wouldn't it also be a "surprise" when an NFS user finds that she can't execute a file because one of the DOS bits was flipped on by a Windows user? Isn't it true that NFS clients don't always check for locks? So wouldn't it then be a "surprise" to a Windows user when an NFS user deletes or possibly corrupts a file that was supposed to be locked by the Windows user (non-Irix versions assumed - a majority of Samba versions according to the Samba survey)?> I'm still awaiting judgement on the user requests for true ACLs > (which we can do by mapping into POSIX ACLs, when enough UNIX's > support them). Most NT software simply doesn't use the NT ACL > design. Nice though it is from a security point of view, for > most users it is just unimaginably complex.Again, pardon my lack of UNIX knowledge but wouldn't POSIX ACLs hinder performance and don't some flavours of UNIX (e.g. Solaris) have their own incompatible-with-other-flavours ACLs? Why would you even bother with it until there was some sort of a standard (and who knows when that might be)? True, most NT software doesn't use the ACL design and most Windows users don't need to bother with ACLs. The NT administrators who set everything up need to though and they may have reason to setup complex ACLs, something that can't be done with UNIX file permissions.> This is a straw man. Have you looked at the Samba consultants list ? > This is also not even mentioning such companies as IBM & HP > who are now > supporting Linux (all versions of which include Samba), LinuxCare, > RedHat, Caldera and a host of other companies (I can't even remember > them all). Remember - every "Linux Certified Engineer" will also be > able to support Samba :-).True but many of the settings can be done via a web browser by almost any network administrator that has little NetApp knowledge. Contrast that with an NT admin who would might be faced with learning Linux and Samba from scratch or hiring one of those new "Linux Certified Engineers." Combine the fact that a filer comes pretty much optimized right out of the box with the fact that it looks and feels like an NT4 member server to Windows clients and the fact that it can be administered with standard Windows NT tools (like server manager for setting up shares and share level ACLs, user manager for group membership and Explorer for ACLs and file access auditing). A large support infrastructure already exists in the form of Microsoft Certified Professionals for filers from this perspective (yes, there are a lot of paper-MCSEs out there will be paper-LCEs soon enough too). Existing UNIX savvy admins should have little trouble administering a filer via telnet (for commands such as ifconfig, ping or dump) or via an NFS mount to use chown, chmod or vi (to edit files such as hosts, passwd or exports). I'd be tempted to argue that every "Linux Certified Engineer" will also be able to support filers to some extent. Cheers, Paul
> -----Original Message----- > From: Jeremy Allison [mailto:jallison@cthulhu.engr.sgi.com] > Sent: Wednesday, June 23, 1999 1:19 PM> commercial Samba and Linux support. Contrast this with NetApp where > support is only available from one company.Au contraire.... There are a number of VARs out there. I don't know who they are by name but they're there. Let's not forget Dell and Fujitsu. http://www.netapp.com/partners/byproduct.html#oem Cheers, Paul
Sorry for answering so late, but there have been very much to do lately.> Existing UNIX savvy admins should have little trouble administering a > filer via telnet (for commands such as ifconfig, ping or dump) or via an > NFS mount to use chown, chmod or vi (to edit files such as hosts, passwd > or exports).The current NetApp implementation just have one password/account. When authenticating a user through a telnet session it has three criterias: connecting host, username and password. All these are very easy to compromise and I won't even bother to describe how. Just the thought of sending a server root password in cleartext... *shrug* The point I want to make is that the security concerning logins is so bad today that telnet isn't an option for any serious user. When you have implemented the promised ssh functionality you're back in business on the UNIX-admin side again. Until then the only realistic administration is from NT. //Daniel Petz?n --------------------------------------------------------------- The opinions are mine and not those of my employer.