New Features In Samba 2.2 And 3.0

chromatic writes "Dustin Puryear has written a nice article summarizing the new and upcoming features of Samba. He's included a nice overview of what will be available when version 3.0 escapes. Let's hear it for interoperability!"

Comments

Interoperability

[Xner]

Let's hear it for being only one step behind Microsoft! Yay!

This is one of the most commonly heard objections to interoperability software of any kind. It is usually formulated in terms of the specification being a "moving target" and that "MS can break it any time they want".
This is rubbish.

What gives Microsoft leverage over the desktop market is their present installed population. They can't go around breaking compatibility with existing products, as they cannot expect everyone to upgrade everything immidiately. The CIFS specification itself might be a "moving target", but the actual implementations in the field that it needs to be able to interoperate with are not.

As amazing as it sounds, vendor lock-in works both ways.

Re:Interoperability

[Atzanteol]

While MS may maintain backwards compatibility, it only goes so far. Try using Win98 on a Win2k network. Not gonna work.

And remember: The spec is not only changing, it is also *hidden from sight*! The SAMBA team does *not* have access to it at all. I don't know about you, but packet sniffing for a few hours just to figure out how a simple login works doesn't sound like an easy task to me.

There are many reasons why SAMBA should fail, the fact that it is kept as close to the current CIFS implementation (as dictated by MS) as it is, is nothing short of amazing.

Windows Interoperability

[MrWa]

What about the anti-trust decision? How did that affect the Samba team: will they have better access to interoperability specifications? What about security protocols and API - can they get these? Do they need them?

As more and more of Microsoft's efforts start going towards Palladium, how will this affect Samba?

Not trying to create FUD but I'm just curious where things are heading. As it is now, anyone could setup a Samba server - which is great - and anything that makes interoperability between these operating systems is good, good for users of both OS's.

Re:Windows Interoperability

[680x0]

As I understand it, the Microsoft decision said they had to offer access to most protocols (and there was an exception for protocols which affected "security", as I recall). However, Microsoft attached a number of conditions on the agreement one must sign to have access to the documents (no GPL, etc.) made it worse than useless to the Samba team. And the judge did nothing about those conditions, so it seems like it didn't help Samba one bit. Somehow I wasn't suprised.

Re:So true

[dead_penguin]

Microsoft has no reason to open *anything* up. They're big enough that in most situations they can do whatever they want without worrying about interoperability with any third party.

This (unfortunately) makes sense from a business perspective; they're much larger than the "critical mass" needed for them to set their own standards. Any extensive form of interoperability would make it much easier for people to install a mixed network instead of moving to all-Microsoft, or even moving away from MS technologies for certain machines.

This doesn't imply a monopoly situation, but rather it's their way of trying to force us to build homogenous networks instead of making it easier to sneak in a few other machines.

Re:Question: How is Samba TNG doing?

[Vlad_the_Inhaler]

I asked one of the Samba team that question at a Linux fair in late October. It seems that the TNG team is down to it's one original (and allegedly rather cantankerous) member.
TNG has apparently ground to a halt and has been overtaken by the main Samba branch.

Ease of Use, How to do it?

[synq]

I've been using samba for over 5 years now in a large company with a mixed flavour unix and windows network environment.

When implementing samba I've always come across the same problems:

• Unsufficient documentation available
• E-mails for help to samba team members seem to get lost somewhere in /dev/null
• Features that are reported to work don't and ones that are reported broken work perfectly
• In the end it was always down to debug=999 in smb.conf and tcpdump. (But: I've implemented it on a solaris 2.6 sun cluster 2 machine supporting full failover capabilities and all.)
• Once you find out what works and what doesn't you can use one version for years!

The article says:
It's very easy to use Samba as a PDC. Simply enable a few options in the Samba configuration file, add users to the local Samba password database, and build machine accounts for each Windows NT machine on the network.

I find this at least peculiar.

When you have 500 users you are not simply going to 'add users to the local samba password database', especially not when you need to run samba on more that 4 machines simultaniously. One of the things I had to do to get this working was sniff all the passwords from the network (wasn't too hard, since we use unencrypted NIS, so all passwords travel the LAN in plain text) and then add them to the smbpasswd file with a specially manufactured perl script.

Also the 'simply enable a few options' isn't as simple as it seems, since even man smb.conf doesn't seem to have consequent answers for every switch you can set (and there are dozens of them).

Most of the features that this article is about have been around for a few years now and still haven't improved much.

I hope to see the day that installing and configuring samba for a medium to large corporation is really easy and clear. For now I'll just live with the kwirks.

Just for the record: I'm not saying samba is a bad product, it just needs a lot of better documentation and ease of use and installation for larger userbases.