Slashdot Mirror
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'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
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.
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.