Tridgell Taking Samba Beyond POSIX

dW writes "The Australian hacker has been working on pushing Samba beyond the POSIX world and figuring out what work needs to be done to get Samba to support new filesystems such as XFS, ext3, and Storage Tank. The answer is nothing less than a complete rewrite of Samba's smbd code, which has become his latest pet project. Here's an interview with Andrew Tridgell on his latest Samba rewrite."

Comments

Maybe this will kick MS..

[Angry White Guy]

Out of the datacenter market!

Re:Maybe this will kick MS..

[xanadu-xtroot.com]

Where they ever really "in it"?

Re:I use Samba...

[Anonymous Coward]

> Yeah NFS is a better system. However in defense of MS they have document SMB (aka CIFS) so people can understand it. However virtually every other recent OS has support for NFS so it would be nice if MS included native support rather than just in their UNIX Tools which are cost extras

And NFS support helps Microsoft's business case how, exactly? I can't think of *any* reason for them to support a competing networked filesharing system, and plenty of reasons for them not to - including their historical distaste for all things Not Invented There, unless they've been suitably embraced and extended.

Eh? No XFS + ACLS?

[caluml]

I don't know what they're talking about, but if you compile XFS in, all the acls libs, and then compile Samba, you get something that you couldn't tell from Windows. Apart from the uptime, the speed, the security....

Re:Eh? No XFS + ACLS?

[nosferatu-man]

... which is the great failure of the POSIX security metaphor.

'jfb

Just one?

[MrMickS]

The Australian Hacker

There can be only one perhaps?

Re:I use Samba...

[caluml]

Yeah NFS is a better system

Hmm, not so sure. All that portmap baggage is annoying. And there is no username level security.

Rewrites suck

[Cthefuture]

A complete rewrite? WTF? I thought smart developers learned a long time ago that rewrites are almost always a waste of time.

There are many issues to be overcome when doing a complete rewrite. As a developer, I understand the desire to rewrite something from scratch to make it feel better. You feel like you are doing something to improve the system. However, this hardly ever happens. Most developers face serious burn-out issues when they rewrite something. It's fun at first but as you realize the magnitude of what you're trying to do, you quickly start to burn out before you are even close to finishing.

The thing is, even if you do manage to rewrite everything, there will STILL be issues. Hacks, special conditions, etc. All the same types of issues that made you feel bad about the original version will be present in the new version. They may take a different form, but they will still be there.

Successful systems tend to just continue off the old code. Rewrite the problem areas, add things that are needed, etc. That's how you make forward progress. In the end, the only thing that matters is that it works. It doesn't matter how crappy you feel about the code, if it works then people can and will use it.

It's not an impossible task, I just think it's not the smartest thing to do.

Re:Rewrites suck

[DarkBlack]

Obviously, you did not read the article. You just read the posters comments. Tridge is only working on 30% or so of the code. User and group mappings for example will not be touched. Just the things that interact with the posix layer of the system in question. It is still a significant portion of the code, but not a complete rewrite.

Re:Rewrites suck

[Webmonger]

It's not usually about "correct". It's generally about being maintainable and extensible.

And the more experience you have with a problem domain, the better-prepared you are to create an architecture that solves the right set of problems.

Yes, each army prepares to fight the last war, and there is the "second system" effect. Myself, I try to avoid rewrites-- usually you can evolve existing code towards the right architecture, but first you need an idea of what the right architecture is. Looks like Tridge is starting with some exploration.

going in the wrong direction?

[Anonymous Coward]

Instead of trying to simply take advantage of extended attributes of various filesystems, what about taking Samba the same route as NFS and implement some kernel-level support? Replace the existing kerne smb code with samba-based client/server bits, similar to NFS; a mix of knfsd and usreland bits like portmap. This could eliminate the many layers that could crop up simply by trying to make the daemon-only version use various filesystem bits.

Don't convert the ENTIRE samba to kernelspace; that would be pointless for samba on other platforms. But development of a 'kernel plugin' allowing Samba lower-level access to filesystem bits might be beneficial.

(yes, I'm ignoring the potential security foo at the moment and realize it's another portal of potential exploit.. but instead of adding more abstraction layers to the system it might be nice to simply access those wanted features directly).

'fester

Can they PLEASE ditch the use of C at this point?

[emil]

I am so tired of applying security patches for system software... the latest double-double vulnerability of samba and sendmail were quite trying.

We keep hearing that the use of a language with bounds checking and a GC would solve a great many security problems. Is there any push towards such a platform?

I don't know much about Objective C, but it seems to be tight with gcc, g++, and g77. Does it have the needed security features?

At this point, I'd almost prefer that Samba was written in Java.