Slashdot Mirror
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!"
no thanks.
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.
Pathman, Free (as in GPL) 3D Pac Man
Yay Dustin!!! He is a member of our lug, SBLUG.
www.sblug.org
Join our mailing list and feel free to ask for help. Answers are provided in a short amount of time.
When this can mimic my NT PDC in a stable manner, NT is gone... this feature was a long time coming, and will be nice to see it pushed, rather than the standard "samba makes a great file/print server".
For *nix to succeed in the enterprise, it needs to do *all* the enterprise level things, without resorting to one vendor solutions such as Enterprise Server.
If I had mod points, I'd move this up, but the best I can do is agree.
One of the things I've wondered, however, is what does Microsoft have to lose by opening up SMB? It seems strange to me that nobody can see that most open operating systems can do it the correct way and the Microsoft way (at least limitedly), while Microsoft has self-imposed limitations that prevent them from being part of a much larger machine. Another example of these self-imposed limitations is the extremely limited selection of filesystems available to Windows (NTFS, FAT, FAT32), yet, in Linux, I probably have close to, if not over, 100 options that I can choose from including the Windows offerings.
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.
How is Samba TNG doing? This fork was announced with much fanfair a few years ago. It was supposed to add Active Directory to Samba. It seems to have disappeared. It's mailing list archives seem to stop around Jun 2002:
http://www.samba-tng.org/mailinglists.html
Has that work been merged into Samba? Has it been converted to Samba plugins? Is it still going on? If so, what's the progress?
Anyone know if this gets rid of the (dot) .files created by window clients? very annoying.
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
Hi, this article seems a bit 'stale' to me. It states that samba is at 2.2.4 at the time of writing and according to my latest Freshmeat notification:
This email is to inform you of release '2.2.7' of 'Samba' through freshmeat.net.
The changes in this release are as follows:
A security hole has been discovered in versions 2.2.2 through 2.2.6 of Samba that could potentially allow an attacker to gain root access on the target machine. The word "potentially" is used because there is no known exploit of this bug, and the Samba Team itself has not been able to craft one. In addition to addressing this security issue, this release also includes thirteen unrelated improvements.
sig not found
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:
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.
sig not found