Samba Beats Windows IT Week Labs Test Results

jmhowitt writes "Tests by IT Week Labs show the latest version of the open-source Samba file and print server software is 2.5 times faster than Windows Server 2003 in the same role. The news comes as many firms are grappling with the consequences of Microsoft ending support for NT4, coupled with uncertainty about when Microsoft will next update Windows. The performance difference between Windows Server 2003 and Samba 3 has increased dramatically compared with Samba 2 and Windows 2000 Server."

Comments

Best choice for the job?

[Sheetrock]

I've been using Samba for awhile, and despite some config difficulties it performed as advertised.

However, even if it's quicker than Windows Server 2003, NFS still seems to do a great deal better on my home network for the same things. For example, I typically get 10%-20% of the transfer with SMB as I do with NFS.

So I don't recommend using Samba at all unless you're looking for Windows compatibility.

Re:Best choice for the job?

[Libor Vanek]

I get 10%-20% of the transfer with SMB as I do with NFS.

You are kidding, aren't you? Did you mean 10-20% LESS THEN NFS? (e.g. 10 MB/s NFS vs 9 MB/s SMB)

Re:Best choice for the job?

[Gwala]

Hell' if your not looking for Windows compatibility, FTP can work wonders. It's got minimal overhead, has been expanded several times (eg SFTP), has a secure base and run's on any system with minimal problems. Window's is a little less compatible (ie it's not as point and click, as the network neighborhood, but still, it's only typing a url)...

-Gwala

Re:Best choice for the job?

[Anonymous Coward]

NFS has extremely bad security. It is practically unusable if you must allow "decentrally administered" systems on your network.

Re:Best choice for the job?

[curious.corn]

NFS lives in the kernel, Samba in user space. So you're right but remember NFS is utterly insecurable, Samba not. For home NFS is the system of choice but in a larger environment... you want to run Samba (at least until NFSv4 becomes available)

Re:Best choice for the job?

[Make]

you mean, there is a kernel implementation of the NFS daemon. There is also one which runs purley in userspace, but on Linux, it is not used very much anymore nowadays.

There is smbclient in userspace (which is similar to an FTP client), but if you want to mount an SMB share into the linux VFS, you need the kernel module - like you need the NFS kernel module if you want to mount an NFS filesystem.

Re:Best choice for the job?

[Rich0]

Samba on FAT? Are you sure about that?

Sure, I guess it is possible - since linux can mount FAT, but why? FAT is by far not an ideal filesystem.

I'd just put your scratchpad on ext3/JFS/reiserfs/xfs/whatever and use the appropriate umask in your samba config file to make all files world writable.

Re:Best choice for the job?

[smagruder]

IMHO, web-based applications suck.

Yes, they do. By their very nature (at this time, anyway), the web user interface can never nearly be as potentially rich as a native client. Consider heavy-duty data collection applications as an example. And you're right that the performance is an issue as well.

However, managers all over (from what I can tell) are clamoring for getting their apps to be web-based. Why? Less administration (esp. at the client workstations), or at least the perception of this. This is what they see.

Meanwhile, "weblication" development technologies are moving forward. While they may never really catch up to what's possible with native clients, it will increasingly make sense to consider such technologies for more and more projects.

Re:Best choice for the job?

[__past__]

Excuse me?! FTP is an absolutely braindead protocol from todays point of view - even if you find an interoperable solution to get rid of the plain-text passwords, the multiple-tcp-connections design is a fucking pain for people who have to configure packet filters to make it work. The most popular FTP servers, like WU-FTP or ProFTPD are about as secure a code base as BIND or sendmail. If it were for me, FTP should take its friend telnet and get the fuck off the net, joining finger and rlogin in the nirvana of net services.

SFTP is a different matter however, but it's less an extension of FTP as an add-on to SSH to implement similar functionality in a completly different way. Not bad as a protocol, but it suffers from the lack of a robust SSH implementation.

Re:Best choice for the job?

[Paul Jakma]

remember NFS is utterly insecurable

sigh... not so, incorrect and misleading statement.

at least until NFSv4 becomes available

sigh.... the "security features" of "NFSv4" are:

• Not NFSv4 specific. NFSv3 can use them too. Indeed, many other apps can use them. because:
  
• Not even related to NFS, they're related to RPC, upon which NFS is built.
  
• "security features" only in so far that NFSv4 makes secure RPC mechanisms (eg RPCSEC_GSS) /mandatory/, as opposed to optional (NFSv3), hence the reason why finally Linux is getting support for something more secure than plain old not-too-secure AUTH_UNIX.
  

See OpenBSD or Solaris (and probably a other commercial Nixen) for NFSv3 (maybe V2 as well) with strong RPC authentication methods - (ie RPCSEC_GSS) - they've had them a while.

Just because Linux does not support strong RPC auth mechanisms (upon which security of NFS, etc.. depend), does not mean NFS is insecure. Stop tarring NFS with the Linux brush. And yes, it will be good to get strong RPC security support in Linux at last.

Re:Best choice for the job?

[Paul Jakma]

"Stop tarring NFS with the Linux brush." Ahem... chill out.

Well, that is effectively what you did :)

but to the avg linux user NFSv3 is insecure

No... Linux's kernel RPC does not support any strong security mechanisms. Neither does glibc really, but I think it might now support AUTH_DES (shared key DES, not terribly secure, but better than AUTH_UNIX) to some extent. I dont think its really used anywhere.

Is the v3 spec abiguous

Nope. Again, RPC != NFS. NFS /uses/ RPC, RPC is the mechanism by which NFS clients and servers communicate. Just as how HTTP operates over SSL (if you want security) and you would not blame HTTP for problems or lack of support for strong security/auth mechs in SSL, you can not blame NFS too much for problems in security, as it relies on RPC to establish credentials (just as HTTP would with SSL). The major difference between v3 and v4 in terms of security is that v4 specifies that RPCSEC_GSS /will/ be available, whereas the lowest common denominator with v3 is plain AUTH_UNIX. So there is no choice but to implement secure RPC if you wish to support NFSv4. Hence the secure RPC mechanism will be guaranteed to be interoperable (Eg, only Sun supported AUTH_DSA iirc), eg these mech's presumably will have been tested at the NFS bake-athon's.

Was it hampered by export restrictions?

Probably, RPCSEC_GSS tends to be Kerberos v5 at the backend. Which was restricted. Sun's AUTH_DSA was similarly restricted as "ammunitions" for quite a while.

Anyway, go google for rpc_secure, RPCSEC, RPCSEC_GSS, AUTH_DSA, AUTH_DES and AUTH_UNIX! :)

Re:Best choice for the job?

[GOD_ALMIGHTY]

If it were for me, FTP should take its friend telnet and get the fuck off the net, joining finger and rlogin in the nirvana of net services.

Somehow I don't think these protocols were enlightened enough to reach Nirvana. I'd say that they are being reincarnated as bloated SOAP specifications, which will cause us to lose an entire CPU generations' gain in power to transform XML cause some developers were too lazy to learn CORBA.

Panther has it in Apple's Open Directory !

[mirko]

See article...

The best thing about Samba...

[_Hellfire_]

Apart from how bloody quick it is is the fact that you can log every transaction. This is immensely useful in a mission critical environment when you have to figure our exactly why one person in particular out of the entire network is having trouble. Check your Samba logs and 99.9% of the time your answer will be there.

As a system administrator I appreciate having that level of scrutiny on any network I take care of.

Re:The best thing about Samba...

[Lumpy]

also it makes for easy detection of worms or virus spreading. I detect the latest spreading on my samba servers at least 20 hours before the knuckleheads in corperate have the first clue that something is up. and using simple, existing log tools for linux make it happen.

Re:The best thing about Samba...

[jschrod]

OK, flamebait, and not funny.

I have worked with several large organizations that use Samba to serve files to 10,000s of workstations. It works much better than W2K servers, not to speak of NT servers. Samba on a Sun HA cluster (e.g., F15K systems) is an appropriate choice for file sharing that is considered critical.

And please note that I don't say this because I'm anti-Microsoft. In fact, I'm the CEO of a company that is a MS partner, and I am very satisfied with MS' support for our company. (It's much better than that of most other proprietary vendors, though not in the league of Oracle and their ilk.) I regularily plan and deploy heterogenous infrastructures for very large installations (i.e., > 50,000 users) and can back up my opinion with real-world experience from several places. What are your credentials?

Nice advertising

[BiggerIsBetter]

Now where are the numbers to back it up?

Re:Nice advertising

[Stonent1]

Now where are the numbers to back it up?

I was thinking the same thing. The article added nothing to what we already read in the Slashdot summary. The basis of the article "Someone (who is not us) says that Samba is 2.5 times faster than Windows server 2003!"

Score!!!!!!!!!!

Re:Nice advertising

[AstroDrabb]

Sadly the MS Empire does not allow you to release benchmark stats for their products. You agree to this when you use their products through their EULA. I am sure IT Labs doesn't want to get crap over it. Then agian, maybe they will find a way to post the numbers.

Knowledge of the protocol

[MadX]

I read a while ago about some of the SAMBA developers having a better grasp of how the services / protocol all tie together, than the M$ employees doing the development. Most of the current M$ team inherited code from the older versions of the OS, and they are merely building on top of this codebase. The SAMBA team have had to reverse engineer the protocol. So it seems to make sense therefore, that should you understand it better, you can sqeeze more out of the service on the whole. It therefore appears that it can only get better and better as they develop ..
I also don't know how many developers are on the samba team in total (contributors / developers), but I would almost start assuming more than the manpower assigned by M$ to this area of code for Windows .. And with it being opensource, bugs are easier to find ...

Re:Knowledge of the protocol

[NewbieProgrammerMan]

Good points. Here's an additional one: the Samba team doesn't have PHBs to get in the way. In my limited experience, if you're given an existing codebase and told to improve on it, that's exactly what you're expected to do - and it's all you're expected to do. You can't discover that "wow, this legacy code is crap," throw the offending chunks away and write something that works correctly and is more stable and/or secure.

The Samba team has complete freedom with their code, while the Microsoft developers do not.

Re:Knowledge of the protocol

[LinuxGeek8]

Yup, now we'll just have to wait untill microsoft switches from their own implementation to Samba :-)
I suspect thta it will be a few years in the future untill that happens though.

Re:Knowledge of the protocol

[Zathrus]

You can't discover that "wow, this legacy code is crap," throw the offending chunks away and write something that works correctly and is more stable and/or secure.

That's because there are tradeoffs in everything... if you've been told to "clean up the codebase", take a bit to look at the codebase, and tell your manager that it's going to take X amount of time to do that the manager has to decide whether or not it's worth the time to do so -- since otherwise your time could be spent doing other things. And odds are the cleaning up isn't going to show an immediate return to the company. Of course, there are other plusses to cleaning up code -- like doing it right may mean that you can implement future features in less time -- but those are harder to quantify.

Any large project -- be it OSS or closed source -- has to deal with these issues in one way or another. Sure... in OSS anyone (in theory) can decide to go off and clean up the code base. But unless it's done with the input from the team then that effort may be for naught -- unless you're communicating structural changes then merging the two code bases may prove impossible (since new features/bugfixes will have diverged the codebase), the rest of the team may not feel comfortable with the new structure as they are with the old (which is part of a larger issue -- if anyone feels like they "own" parts of the code then they may get offended if you say it's crap and rewrite it entirely -- which is one reason why code ownership is bad), or other issues. If you do do it with the blessing of the team, it still has to be done in a reasonable amount of time for it to be worthwhile -- otherwise the code will either diverge too far or the project will stagnate while waiting on the rewrite.

And, of course, any time you rewrite you run the risk (read: certainty) that you'll introduce new bugs in known, working code.

Open source projects are freed from the time == money constraint if they have no commercial interests whatsoever, but that isn't to say that time becomes free. It's just that it's not necessarily an overriding factor. (Oh, and it's not one at all companies either -- that's entirely up to your manager and the structure of project management; but the more rigorous the framework of management the more likely it is be one).

Uh, where are the benchmarks?

[Fefe]

Where are the numbers?

Where are the graphs?

The article basically quotes some guy (who is actually selling Samba and thus has a vested interest) saying that Samba is 2.5 times faster than Windows 2003.

Now I have no reason not to believe him, but I was expecting a little more. And I'd wager the suits considering switching to Samba also expect more.

Re:Uh, where are the benchmarks?

[the_mad_poster]

And I'd wager the suits considering switching to Samba also expect more.

What, you mean the suits who get all of their "technical" information by clicking the ads that come up in articles like this? AHHHH AHAHAHAHAHAH! *sniff* Sorry... you're funny!

Alright, I'm just pulling your leg - that's the first thing that hit me too. What good does it do me to hear some guy saying "Nyah nyah, we're better!" without seeing both the data AND the complete configurations that each system was tested under. I want to (and do) believe Samba whooped Microsoft that bad, but I also want to know how... if there's one thing you need to learn quickly in IT, it's to never trust benchmarks until you've confirmed them on your own.

Re:Uh, where are the benchmarks?

[sootman]

I heard before (in the w2k days) that on a given piece of hardware, Samba ran twice as fast as w2k file sharing. When 2003 was first being touted a few months ago, MS said that they improved file serving so it was "faster than the competition", which means it's as fast as Samba (if not faster.) And now Samba is 2.5x faster again? That's more than a little unbelievable.

What I'd like to see would be an open, month-long contest, with 3 boxes--say, a single P4 with a couple drives, a dual-xeon+RAID, and some huge mother connected to a fiberchannel SAN. Make two identical copies of each box, then let MS tweak one set as far as it will go and let the Samba team tweak another. Make it a month long and open so each team can publish their results, get more opinions, etc etc etc., until everyone on both sides is convinced that the whole contest is as fair as can be and that neither side had an advantage. Then, see who won. Otherwise, we'll just keep seeing what we saw today and every other test--people come out of the woodwork claiming MS fixed this, or the Linux/Samba-biased testers didn't know how to tweak that, etc etc etc. Once it's this open and agreed upon, it wouldn't matter if the contest were funded by Bill Gates or Jeremy Allison. Until then, I'll just keep ignoring these tests.

I just love the per client license fees

[hughk]

that Samba/Linux charge. The performance boost is just a nice plus.

A frequent rule in the Windows business is to split systems up over many machines. Which is great for Microsoft because essentially, you pay per client connection. With Linux/Samba, you pay according to the support that you want.

The really good thing in 3.0 was allowing the participation in ADS networks (Win 2K) as well as NT4.0. Domain controller support could be better for ADS, but otherwise it is fine.

Re:I just love the per client license fees

[davidstrauss]

A frequent rule in the Windows business is to split systems up over many machines. Which is great for Microsoft because essentially, you pay per client connection. With Linux/Samba, you pay according to the support that you want.

If you license properly, Microsoft gains little with additional servers. The client access licences (CALs) apply to any Windows server, so CAL costs only scale with the number of clients, not servers. The marginal cost of adding another server, once CALs are in place, is only the cost of the basic Windows license for that server with no CALs. Unless you mean splitting systems up over many clients, which is not what Microsoft says in any way, the cost of splitting systems over many servers is quite minimal.

If, however, you mean licensing each server by connections, not CALs, with several servers that tend to not have their own exclusive clients, you are using non-optimal licensing, and you need to research your criticism further.

Re:Security

[Kegetys]

Since when would it be a more secure choice to use a Windows based fileserver instead of a Linux one?

Yay! Our side can do FUD too!

[Ratface]

Read the original poster's text again. Amazing how if this text were written comparing MS to Samba in the *other* direction everyone would be up in arms about the FUD value!

We need to be careful that we don't end up tarred with our own brush!

Re:Yay! Our side can do FUD too!

[iceT]

Well, Mr. Doubting Thomas, if you look at the #1 highest modded reply, it says "Great, now where are the numbers".

That's is this groups way of calling "FUD".

Kinda strange, but impressive...

[CoolVibe]

...for a project that started out as a hack to tranfer some files between a SunOS box and some Messy DOS box running LANMAN.

I appreciate Samba, especially with the PDC stuff that obviates the need for costly NT server licenses here at the $workplace. Great to see that a hack that was born out of need is running circles around the cream of the Borg's crop.

Also, I agree with the rest that I'd love to see the numbers to back up the claims. Not that it really matters though. With samba you get a real good solution for an infintessimal fraction of the price of the Microsoft malware :)

Lie, Damn Lies, and Benchmarks

[m00nun1t]

We all know anytime someone publishes a benchmark favouring Windows (and there have been quite a few - tpc.org being a great example), it is instantly ripped to shreds, so why is this different?

We all know that it's impossible to do a benchmark that all parties think is fair and accurate.

Easy Way of Handling Printers

[fuzzybunny]

I serve printers from samba boxes to WinXP and W2k clients. I do not like dealing with setting up print queues on unix (unix printing and modem handling are evil, created by spawns of satan to make systems administrators miserable for all eternity), and I don't like Samba's way of dealing with them. It's still a bit too black-magic-swing-a-cat-over-your-head-at-midnight -y for my tastes when I need it to work in a hurry.

I've found CUPS to be a magnificent way of dealing with this; the combination of Samba, Unix, and WinXP/2k actually deals with printers very nicely over IPP.

Re:Easy Way of Handling Printers

[Cat_Byte]

CUPS rules in my opinion simply because I can share certain HP printers that their own MS drivers can't...heh. I have an HP 710 and in their how-to's it says to share it you need to load a generic HP Laserjet driver (which disables the color, fax, scanner, etc). I still can't use the scanner/fax but I can print in color over the network. Very cool for free software.

Sneaky popunder

[jsmyth]

Dunno if anyone else noticed, but when I clicked on the article, a "VNUNet Special" opened in the background, which was an advertisement or promotion under another name. It was formatted just like all other VNUNet articles, but was clearly a Microsoft sales pitch for W2003, complete with a flash advert on the right, and one at the top, both for W2003.

Interestingly unbiased, when clicking on a Samba article...

Re:Where's the results?

[grub]

I mean, they could've at least made a little graph

Here you go:

OS__________________Speed (more == better)
Windows Server 2003 ##
Linux running Samba #####

As you can see, Linux running Samba is 2.5x faster than Windows Server 2003.

The numbers....

[Bill_Mische]

There are a lot of people asking about the numbers.

Well, I get the print edition of IT Week and the numbers are there on page 19, in the form of a lovely little graph. The (print) article says they used a HP ProLiant BL10 eCLass Server (900MHz PIII, 40Gb ATA, 512Mb Ram) and goes in to a little detail about the benchmarking software used.

I couldn't see a copy of the article on their website but you can download an electronic copy, in some god-forsaken windows only ebook format, from www.itweek.co.uk/ebook.

Re:The numbers....

[sheldon]

That doesn't make much sense. A Blade isn't a cost justifiable solution for a small business, as you don't just buy one of them... you've got to buy the whole rack and supporting hardware to plug them in. A small Proliant ML would be far far cheaper.

And why would you bother benchmarking a file server for 15-20 seats? We used to server 500 users off a 486DX33 running Novell back in the day. 15-20 seats doesn't constitute a need for benchmarking, you could use anything.

I guess my point is, this hardware seems odd, like it was chosen because Linux would look better on it for some reason. I want to see further details and try to reproduce this benchmark myself.

Samba starter question?

[WuphonsReach]

I know this is more of a AskSlashdot question...

My impression of Linux/Unix systems has always been that each host has it's own set of user accounts and if I have 3 hosts it means that I have to maintain 3 sets of passwords. With NT4/Win2000, my servers share a common userspace so that you only have to maintain a single user account. Is there something under Linux/Unix that does this?

How easy is it to drop a Samba server into an existing Win2000 network? Our Novell 5 server is starting to show it's age (file/printing only) and I'm starting to wonder whether to move to a later version of Novell, switch to Linux/Samba, use a NAS device, or just load up another Win2000 server.

(With the security issues this year with Windows, however, I'm not sure I want to make Windows our main file server.)

Re:Samba starter question?

[Bombcar]

As Steve Jobs would want, here are the 'Lickable Links':

To centralize auth you can use:

NIS/NIS+ + PAM

OpenLDAP + PAM and More

SAMBA + PAM

Advanced LDAP/Samba

PAM is the way to go

Excuse me...

[dnaumov]

I am a big fan of OSS, *BSD, Linux, Samba, you name it, but I have to call bulllshit on this one. A 2.5 x speed advantage can only mean one thing: misconfigured Windows machines. In my own experience (running a FreeBSD box with Samba 2.2.8 on a LAN full of Win2000/XP boxes), the Samba speed advantage has been about 30-40%.

Where are the system specs, charts, graphs, actual numbers ?

Re:Excuse me...

[Frobnicator]

A 2.5 x speed advantage can only mean one thing: misconfigured Windows machines.

You might be interested in this article describing the implementations of SMB and Samba, as well as the documentation list at samba.org. Additionally, Microsoft has had many issues with the LMB, DMB, and backup browser implementations, partly due to historical network decisions and old networking bugs and highly visible on volitle networks. Some of the difficulties with SMB include methods of caching the data and cache consistancy, the inconsistant rate of refereshes done within the network, (on windows) the auto-detection and auto-creation of LMB and LMB-backup nodes, and the presumption of the underlying network.

I'll focus on the network cache consistancy problem since that's the one I've had problems with. I don't know about the general speed issue (what speed are you referring to? throughput? Resource availablility? Master Browser updates? connection speed and concurrency under a heavy user load? ) I have experienced all kinds of problems with a highly volitile network, with programmers running multiple OS's inside of virtual machines. These virtual OS's need to be frequently restarted, meaning the network is constantly gaining and droping objects.

A prime example of Microsoft's bad cache coherency problem is that if an object is deleted or removed from the network, the information can take over an hour to propogate through the entire network. The worst case isn't nearly as bad in the pure-Samba implementation, but the difficulty remains. This failure means that newly added resources aren't immediately visible on the network, or recently removed resources take a long time to be removed, and show up as errors when you try to access them. Or the object can be visible on some machines, but not available on others.

When there is a high level of volitility on the network (machines being frequently rebooted or shut down, network re-wiring, etc.) this can really plague any SMB or CIFS network, but is especially hard on Windows boxes, and more so the older your Windows implementation. Problems are exacerbated if either the LMB or LMB-backup system is the one going back up and down, because the Windows boxes will respond less-quickly to the problem; this results in further instability for the SMB network, since critical nodes are not available, propogate incorrect data, and take longer to reconfigure.

As you mentioned, the Samba boxes are faster than the Windows boxes, but not as big of a difference as you experience. You said you have "a LAN full of Win2000/XP boxes", which probably means they are on most or all of the time. Is it unreasonable to assume that the author has a more volitle network, or is otherwise more prone to speed impairment issues?

frob

Re:Interesting

[Zathrus]

Finally I have some hard evidence for clients who keep wasting my time asking me to support SMB on my network

Wow, that's certainly damning evidence. A post from some random /.'er who makes a statement without any data to back it up. I'd print that post out and hand it to everyone who asks you to support SMB. With proof like that they won't ever think of questioning you again.

What are the differences between Samba and NFS security-wise? I need one more argument to my arsenal.

Ok. If you like having a largely insecure network that is extremely difficult to administer and has questionable reliability then your best bet is NFS.

On the other hand, if you'd like a wide selection of permissions on directories, users, and files, along with relatively easy and logical administration as well as high reliability (at least as far as networked file systems are concerned) then you should go with SMB.

Frankly, if I was a "client" and had to deal with you I'd either go to your boss to have your ass canned (if your "clients" are in fact coworkers) or simply move by business to someone who actually wanted to give me service for my money (if your clients are actually clients).

Oh, and before you even think of saying how I'm a MS lackey, I'm a Unix coder. There's SMB running around our network at work, but I pretty much never use it.

We just decided to use Samba

[SailFly]

I'm a networking, sysadmin, programmer (mostly programmer) consultant for small businesses in Sarasota, Florida. Most of my customers are small businesses (less than 12 people) and are looking for ways to keep costs down.

After proposing a new 2.4GHz server with Win2k3, they were sticker shocked and decided to not hire me for the job. Then one of THEM mentioned Linux (which I love and hav used for 5 years). I told them that I use Linux in my software development practice, and we could consider this as an alternative for File Server (Samba), centralized security (ldap) and backups (Mandrake backup utility). We're also using VNC (realvnc.org) for remote desktop. I can also easily SSH and do remote X session from my office, or use VNC.

It's been up for a week now, and they LOVE IT! It's fast, flexible, and you cant beat the price. And I've learned my Lesson to be mention Linux even when they specifically ask for Windows (I'm not a pushy sales person, but I do believe an presenting choices to my customers)

They wanted to outsource their IT department (the owner doesn't ever want to worry or think about their IT issues), so we made a deal that allows me to keep their systems updated, but doesn't force him to hire an on-site IT person.

Speed was NOT an issue for the Samba server, since they mostly use MS Office (win xp pro workstations) documents. However, this was a great step for them to embrace and support open source software (I donate to several projects in turn).

I hope this story might help somebody who is considering doing something similar. I'm happy to answer any questions about our experiences.

-Scott James

Re:We just decided to use Samba

[FyRE666]

Samba is a great tool for promoting Linux, I've found. When I began working at my current job they had a rack of (remarkably unstable) NT4 machines, with a couple of Linux servers doing nothing particularly worthwhile. I mentioned maybe installing some apps to make them more useful to everyone, and was given free reign (though I'm actually employed as a software developer rather than an admin).

Anyway, it's fair to say the NT admins, and other IT staff were pretty impressed once I'd integrated the Linux boxes into the domains, migrated a lot of Access reports (spreadsheets)across to perl+MySQL - making them execute in some cases hundreds of times faster, plus various other utilities. We have a nice development intranet, web tools for monitoring and handling problems with the Windows/HPUX servers and more all running on Linux now. We have DHCP+Dynamic DNS updates on Linux instead of the manual-settings they were using on clients before, traffic shaping via iptables etc etc...

Our latest subnet's first server was linux, and I can't see an NT box getting into that rack any time soon ;-)

It took some of my spare time, and patience to get the company to give Linux a real chance to prove itself, and I think without Samba it wouldn't have happened anywhere near as fast! I'm currently pushing to move our commercial system from HPUX to Linux (yes, a version of our in-house system exists for Linux), since a replacement HP box will cost over 50,000 with no more power or disk capacity than an x86 box with a couple of P3 1ghz in it (we were astonished when we asked about a pair of 750MHZ CPUS to upgrade the 400MHZ parts in the current HP box, and told they'd cost 7,500... EACH!)

So, well done to the Samba team!! Pity you're still allowing the scumbags at SCO to profit from your work though...

Apples and oranges, Moriarty.

[Medievalist]

Samba 3 is a very different beast from 2.2, your remark is equivalent to basing an opinion of Windows 2K on your experiences with DOS 5.0.

The numbers are in the dead-tree edition, I'm told. I don't know if they actually show any real information, because I haven't seen them.

Samba had a 2x speed advantage over Windows NT 3.51 when that was the current MS offering, though, so I don't find this completely unbelievable.

Re:Heh, hows that for a whack at MS?

[UnknowingFool]

The article that you read stated how much faster Windows 2003 was vs. Samba was at transferring very large files. It mentioned nothing of testing performance under large user loads which is more indicative of actual corporate networks. Also, the Windows team was allowed to tweak their installation of Windows 2003 to get maximum performance. Their installation of Samba was a basic installation with no optimizations. Their reasoning for that was that they didn't know Linux and Samba well enough to tweak it.

Re:Okay, but who cares?

[Apparition29]

Absolutely. Talk to anyone in a CAD environment. We have servers with over 4GB of RAM and have 1Gig Network cards (both client and server side). We realized speed increases on the client end every upgrade of the server, increased RAM and higher speed network cards. Then again we may be 'different' we have 100's of thousands of parts that are opened in each assembly.

Re:nuts.

[nolife]

Samba, as good as it is, implements M$ holes, so that M$ transmitted diseases from your client boxes can fill up or wipe out your shares after calling home and giving away everything you care to keep to yourself.

WTF are you talking about? The permissions you have on a mapped drive has nothing to do with what you mapped the drive with. Samba, NFS, Novell, FTP, HTTP or logging in locally all depend on permissions you are given to the file system.

Re:nuts.

[Erris]

I said:

Samba, as good as it is, implements M$ holes, so that M$ transmitted diseases from your client boxes can fill up or wipe out your shares after calling home and giving away everything you care to keep to yourself.

You seem confused and ask, rudely: WTF are you talking about? The permissions you have on a mapped drive has nothing to do with what you mapped the drive with. Samba, NFS, Novell, FTP, HTTP or logging in locally all depend on permissions you are given to the file system.

Well sure, samba is better than Windoze servers for this reason, but that does not keep Windoze clients from mucking up your security. Server side permisions do you no good when a client with all the required permisions is comprimised. Microsoft clients are so easy to own that they wreck any attempt at keeping information secure. If, as in the case of the Half Life source code leak, someone uses a LookOut hole to install a keylogger, all the permisions of your LookOut user are now in the hands of someone you don't know. The worst security nightmare is someone back orificing a windoze box on your network. From there, they can go just about anwhere. This is why no one who's worried about security should use Microsoft anywhere.

Does that clear things up for you?

Until M$ breaks compatibility.. then start over

[HighOrbit]

MicroSoft has a history of maintaining its monopoly by breaking compatibility with competitor's products by subtily changing (or they claim its extending and enhancing) the protocol. The most famous example were DrDOS and Java. If Samba gets too close, I wouldn't be suprised if MS didn't come up with an "enchancement" to Active Directory or SMB/CIFS or the NT-authentication protocols that will break Samba. The up-coming service pack will be the perfect oportunity for a "security fix" that will wall out Samba for a while.

(Related but slightly off-topic) A few days ago, there was an article about IE having broken support for standards, especailly CSS. I don't think that is an acident. I strongly suspect that MS won't fix IE because the "problem" helps them maintain a monopoly in browsers. If you want to get your stuff to render properly in 95% of people's browsers, you have to code to IE, not the "standard". This means your stuff won't render properly in the other 5% of browsers unless you go through lots of trouble to do browser dectection, alternate pages, or take lots of care for cross-browser compatibility.

Re:nuts.

[Cat_Byte]

I use both linux and several flavors of MS daily. What is the difference in using samba for shares if a *nix box is compromised? None! If a username/pw has access to a share and it is compromised, you have access to the share. This is not a samba/NFS vs MS/*nix problem. This seems to be based on *nix not being hackable and the fact someone can't walk up to a *nix machine logged on and start typing.

I've been a security admin for almost 10 yrs and keyloggers, machine hijacks, etc DO exist for *nix too. If using a *nix client and a samba share makes you feel like you're secure, watch out. It's going to bite you where the sun doesn't shine.

Also, how many people do you know that use anti-virus on their *nix servers for samba shares? I don't know very many at all. They are usually hosting tons of windows viruses that can compromise the network when a client gets infected.

I love samba and use it myself. It's just scary to see people who still believe a non-MS product == always secure.

Try this link

[NeoNormal]

This link looks like the info you are referring to.

Re:Okay, but who cares?

[laird]

You're right that for a typical workgroup raw performance doesn't much matter -- either NT or Linux+SAMBA would be "fast enough."

Where this does matter is to someone:

1) Making a decision between NT and Linux+SAMBA. It's great for the OSS alternative to not only be better strategically, but faster and cheaper. You'd have to work pretty hard to justify why you'd pay more (forever) for a slower fileserver that's less secure and requires you to do more paperwork and maintenance.

2) Trying to save money. A 2.5x performance advantage on the same hardware can also mean perfectly good performance on 1/2.5th of the hardware. So instead of buying a NT and a "2Ghz fileserver with fast ethernet and half-a-gig of RAM" you can get the same performance out of Linux+SAMBA on an old 800 MHz PC with 128 MB RAM that you have lying around, or which can be bought for almost nothing compared to the macho server required to get the same performance out of NT.

Re:"reverse engineer"?

[AstroDrabb]

The base SMB or Server Message Block protocol is not the problem. It is as usual, all the MS extensions and divergences from this that are NOT documented publicly or published that make reverse engineering needed.

It's not

[Xtifr]

...benchmark[s] favouring Windows [...] [are] instantly ripped to shreads, so why is this different?

It's not different: the thread is FULL of people (including you) asking "where's the numbers" and calling this study FUD. Some of the highest moderated comments, in fact.

Unfortunately, the response seems to be: MS doesn't allow anyone to publish their numbers. IIRC, they added this clause to their licenses after Oracle published some unfavorable-to-MS benchmarks.

The real difference is that when OSS loses a benchmark test, the general reaction* is that the results are studied, and if they're legitimate (which they often are), then work begins trying to fix the problem, and the eventual result is (usually) a better system. When MS loses a benchmark test, they react by forbidding any more benchmark tests, and nothing else (usually) ever changes.

* At least, the reaction amongst people who count, which is to say, the developers, not the pro-linux trolls on slashdot.

Re:Okay, but who cares?

[Halo-]

Try working as a developer on a large corporate software product. An average build in around a gig a pop, and you either have people "backing" to them, or copying them wholesale. Add in the fact that these patterns are also really bursty (based on build publications) and you are talking serious overhead.

We don't use Samba as the primary fileserver, but the majority of the windows developers use a Samba mirror (or gateway) to the backing tree.

If copying a build goes from 20 minutes to 10 minutes, and then you multiply this across the number of users, you get a signifigant time savings. (Especially for things like build publications, because the temptation to waste time "while the build copies" is pretty high. :) )