Samba Success in the Enterprise?
gunnk asks: "We've deployed a Samba server here to replace some aging Novell Netware boxes. It works great: fast, secure, stable. However, we have one VIP that feels that Samba is 'amateur' software and that we should be buying Windows servers. I've been searching with little success for large Samba deployments in Enterprise environments. Anyone out there care to share stories of places that are happily running large Samba installations for their file servers? Or not so happy, for that matter — better to be informed!"
I've been using samba for the last 12 years in various guises, if there ever was a problem then
it usually was that I did not upgrade the software often enough because *it just works*.
That in my eyes is the best feature any software package can have, that it is so reliable
you forget you have it.
As for it being 'amateur' software, amateur to me spells motivation and the quality level
of the samba software reflects that dedication quite well.
Better than the 9-5 code monkeys products by a long shot most of the time.
OSS is the future, better believe it.
MP3 Search Engine
We use it on my site. In fact we have about 2000+ users who use it every day.
We were all warned a long time ago that MS products sucked, remember the Magic 8 Ball said, "Outlook not so good"
I'm servicing 3 computer labs consisting of roughly 100 workstations here, all with a Samba/Linux backend. I have nothing but praise for Samba and would highly recommend it to anyone. I have some native clients and some that are housed in a vmware image. I have cross platform printing, cross platform credentials (thanks to password sync) and cross platform ~/. What's not to like?
The only downside is that until v4 hits the streets, we can't do full AD. We could of course get around this by dropping in a single 2k3 box to be the DC, but we'd like to avoid that if possible. I'm really looking forward to v4, as AD is one of the good things MS has done, imo (standards adherence aside)!
-Ben
And there is a host of companies out there getting paid to do Samba support:
http://us1.samba.org/samba/support/us.html
I've used Samba at home for about eight years with a Linux file / print server. The server uses RAID1. The only time it's been down is:
1) Changing hardware (including replacing drives with bigger drives).
2) Changing entire server (replacing with faster box and previous drives).
3) Power failure & UPS battery had died.
Right now it's serving files to four Windows boxes including storing video for a PVR.
Not that a home installation will mean anything to your VP.
[Insert pithy quote here]
We support about 6500 engineers here at the rocket ranch. Back at the turn of the century, we wanted to migrate everybody from expensive-to-maintain *nix workstations to vastly cheaper Windows PCs, but we had a problem: all our data was on several dozen HP N-class data servers. We do serious 3D CAD and FEA, with engineering data sets measured in dozens of terabytes. We wanted to leverage the performance and economy of fast, cheap X86 boxen while not losing our investment in our storage management infrastructure. My IT masters had never heard of samba, and were amazed when I demonstrated how easy it was to serve out a Pro/E drawing to an engineer working at one of our brand new 1 GHz NT4 PCs (I told you it was at the turn of the century.) We deployed it sitewide in 2000, and even now, seven years later, my users still thank me for making it possible for them to use fast PCs to access their Unix-based data sets. We ran samba on SunOS boxes, because we never could get it to play nice with HPUX. Samba is ridiculously easy to install, manage, and maintain, especially with one of the GUI frontends that are readily available. We used SWAT, and it rocked. Samba was a great intermediate enabler, allowing us to continue to use our N class servers while we were moving our user base to PCs.
In 2003, however, we acquired a bunch of Network Appliance servers, and migrated off our HPUX and Sun data servers. NetApp filers are platform agnostic; if the client is a *nix box, the filer presents the data as an NFS mount. If the client is Windows, it looks like NTFS. NetApps aren't cheap, but they were worth the major investment. If your company doesn't want to shell out for a filer, then samba is very viable and I recommend it highly.
Samba may have been met with trepidation like 8 years ago. The rest of the world has gotten with the program. It works. It works well. It works extremely well.
I've implemented it at a number of Fortune 100 companies. I cannot name names due to NDA but you would recognize the names. I am contracting at one of them right now.
For enterprise scale use, I would even contend that Samba makes a better file server to large numbers of Windows clients than running Windows on the server. Can you run Windows on an IBM pSeries 570 (16 POWER5+ processors, 128GB RAM) to serve files to ~20,000 users? I can tell you that RHEL 4 does that just fine.
Funny you should ask.
I've just finished deploying a brand new CentOS/Samba solution to replace some ageing NT4 servers.
We got a shiny new Dell Poweredge 2900 with 16GB Memory, twin quad-core Xeons and 8x300GB hot-swap SAS drives.
I configured up CentOS 4.4, using Samba/OpenLDAP/Postfix/Dovecot and MySQL to provide domain, database, roaming profile and file sharing services to a workgroup of around 100 workstations running XP.
Now we have ironed out the smaller issues with the deployment, it's absolutely rock-solid. Current uptime is 18 days, without a glitch at all. Utilisation hasn't peaked over about 20%, giving us plenty of spare capacity for expansion.
We did consider deploying Windows Server 2003, but were put off by the price tag of the cluster of machines that was recommended to provide us with the capacity to service 100 workstations. Suffice to say that the £6k we paid was a mere fraction of the Windows alternative.
Beer Coat: The invisible but warm coat worn when walking home after a booze cruise at 3 in the morning.
Vista seems to work with Samba fine, at least for what I used it for. I went to a LAN party Wednesday, and had my Linux laptop's network shares accessed by a Vista machine on the network, with no issues.
Yeah, yeah, not exactly "Enterprise" activity, but still...
tasks(723) drafts(105) languages(484) examples(29106)
It's me you're complaining about here, as I wrote (and maintain)
:-).
:-) :-).
:-).
the POSIX ACL code in Samba.
I understand your problem, but you've got to realize there's
nowhere on a UNIX filesystem to store that meta-data and have
the kernel understand it.
Sure, we can push the NT ACLs into an EA, but nothing in
the kernel will look at that EA or even be able to make sense
of the SIDs stored within it.
We can do the interpretation inside Samba but this doesn't
prevent other POSIX processes from completely ignoring
whatever ACLs you thought you'd securely set on that file.
NetApp can do this as they have their own kernel (based
on FreeBSD originally) which they've hacked to understand
these ACLs. Samba isn't a kernel, and so can't do this
NFSv4 ACLs, whilst having their own problems, are much closer
to what we need to store full NT ACLs. Unfortunately they (a)
break POSIX, (b) aren't yet finished on the most popular
platorm (Linux) and (c) have no userspace API standard for
getting to them.
This is one of the reasons my world sucks (Microsoft DFS is
another at the moment
Your complaint is like a child screaming "I want a pony,
I want a pony...". We *all* want a pony. Where is it going
to live.....
Jeremy.
Something else you might want to consider are the things Windows will do that Samba does not (or, at least, does not do without lots of hacking around).
Two of these are DFS Replication (DFSR) and Volume SnapShots (VSS).
We are currently in the process of evaluation a replacement for our aging fileserver plus some sort of centralised, SAN-like storage. Two of the leading candidates are Sun's 5320 and IBM's N5200 which offer access for clients via both network (CIFS, NFS, etc) and block-level (iSCSI, FC). Several branch offices are also in the same situation, although they lack the need for block-level, centralised disk.
However, neither of them support DFSR (nor does any other non-Windows based NAS device from what I can gather). They do both have replication technologies of their own, but those are just as expensive (additional US$8k-ish) - if not more so - than just buying a dedicated Windows fileserver to connect to the SAN/NAS device via iSCSI.
Then there's the snapshotting, which Samba doesn't do on its own (but you can hack together something, depending on the host OS). VSS in Windows is trivial to enable, very simple to use and works quite well. It's primary benefit is to reduce the overheads on support staff from users "accidentally" deleting things and needing them restored - something they are now able to do themselves, rather than weighing down support staff with those requests. It can also be used for simplifying backup procedures. (Any decent NAS device will also have some sort of snapshotting functionality).
With regards to Samba in general, we use it fairly extensively on a per-host basis to allow easy access to certain parts of the filesystem for certain staff. I've experimented with it in the past on an AD level and successfully gotten it working, but the overhead for setup is non-trivial, especially if you want things like UIDs to match up across different machines.
Simple setups in Samba and Windows are simple. More complex (Active Directory integration, especially with multiple servers) are also fairly simple in Windows, but relatively much more difficult with Samba. If you're looking at the latter - *especially if you're not already an expert* - you'll probably need almost a complete person full-time to work with it during the implementation phase.
The simple version is this: software and hardware are cheap, people-time is expensive (this is a concept a *lot* of technically oriented people - myself included - have significant difficulty a) grasping and b) remembering). In all likelihood, you will use substantially more people-time - especially in the earlier phases - with Samba than you will with Windows. That's where the "value" of Windows (or NAS appliances) comes in - saving people-time $$$. If you're already a Samba expert, OTOH, the people-time aspect of the equation will be substantially different and you can compare largely on features. However, banging out a good, manageable, sustainable, reliable AD-integrated Samba infrastructure is something that will take on the order of weeks unless you already know what you're doing and have done it before. Your boss has a very poor argument against Samba, but do not kid yourself that good arguments against Samba do not exist.