Tridgell Taking Samba Beyond POSIX 137
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."
Maybe this will kick MS.. (Score:2, Insightful)
Re:Maybe this will kick MS.. (Score:3, Insightful)
Re:Maybe this will kick MS.. (Score:1)
ext3? (Score:2)
Re:ext3? (Score:2)
Rus
I think he means in the other direction (Score:4, Informative)
Or maybe it's because the user level file systems on plan9 have made too much of a mark on me.
open, close, read, write & walk baby, s'all you need
Re:I think he means in the other direction (Score:1)
Re:ext3? (Score:5, Informative)
What he's talking about is taking advantage of "exotic" filesystems. Currently Samba just assumes it has a plain-old Posix filesystem like ext2 behind it, and does things less efficiently than might be possible
I'm not sure ext3 is a good example, but let's imagine it has a concept of transactions. Samba might be able to take advantage of that to provide a better implementation of CIFS, but to do that it has to know about ext3, more than that it's compatible with Posix.
Other examples: ACLs, case-sensitivity, multiple streams in files (like Macintosh resource forks), stuff like that.
Re:ext3? (Score:2)
Rus
Re:ext3? (Score:2)
Re:ext3? (Score:2, Informative)
Re:ext3? (Score:2)
let's imagine it has a concept of transactions.
1 - ext3 doesn't expose a transaction interface
2 - CIFS doesn't need it
3 - Let's imagine moderators are on crack
Re:ext3? (Score:2)
There's more to information than facts you can use to answer multiple-choice questions.
Extended Data Types (Score:5, Interesting)
Rus
Re:Extended Data Types (Score:2, Informative)
Re:Extended Data Types (Score:2)
Rus
Re:Extended Data Types (Score:5, Informative)
Hmm... it seems you didn't fully understand the article, and the problem currently being solved. First, let's create an example. We have a Win2k server serving files to a Win98 box. The Win2k server supports ACLs (in NTFS) and there's a bunch of access controls on the file. The user copies said file to their local box. Guess what, Windows must handle this somehow...
My point? This isn't Samba's problem! In fact, it's not even the same problem domain. Samba runs on the server side. What you mention is a *client side issue*.
The article is describing a method of emulating (or, more accurately, mapping) SMB (actually, probably NTFS) ACLs to ACLs in the native filesystem format. This is something Samba never did before because POSIX simply doesn't have the capabilities necessary to do this, and Samba was always targetted specifically at POSIX-compatible systems. BUT, filesystems like XFS, ext3, and others, have more advanced functionality in this area. So the work being done is to simply make the Samba backend more backing-store-agnostic, allowing it to take advantage of the advanced features in some of the more exotic filesystems out there.
On the bright side, (Score:1)
fine so I'm cool.
license to change (Score:5, Interesting)
With this established managerial behavior in mind, isn't it interesting that IBM would have hired Samba's creator outright, to work on a project which furthers Samba's ability to communicate with additional operating systems? Samba in many ways is a 'license to change' computers in a datacenter for IT staff. IBM has positioned itself to pump funding directly into the Samba project, as well as to have a say in which file systems it supports; this gives IBM the ability to write its own ticket in terms of promoting its disparate filesystem architectures' usage in the datacenter, alongside their Windows brethren.
Re:license to change (Score:4, Interesting)
Rus
Re:license to change (Score:2)
Re:license to change (Score:1)
Re:license to change (Score:2)
Samba's existence is vastly important to the adoption by corporate management of perceived 'alternate' computing systems
Tridge is doing a good thing, but I really would like to see additional work on single-signon without converting my Unix datacenter to use NT servers as DCs (;-))
--dave (unix bigot) c-bAaaaah (Score:5, Interesting)
It's neat that he's extending the SMB protocol to support some more of the native features of the underlying filesystems.
But I'd wager the lions share of it's user base want samba to replace/supplement Win2k Server, and soon Win2003.
This always happens in open source. Projects get pulled in a new direction before they're completed. Developers always want to work on neat stuff and get bogged down in the academics, and it doesnt produce a truly functional result.
There's nothing that can be done about it, it's his time, his decision. Still, it sure would be nice for samba to be a full member of a Windows 2000 domain.
File locking (Score:5, Interesting)
Actually, no- I'd rather have cross-platform file locking. Correct me if things have changed since 2000 when samba and netatalk developers were "thinking" about this problem, but...
It is a HUGE problem that netatalk, Samba, NFS, and the system itself don't share common file-locking, and some file-based applications like Visual Source Safe(still used by many shops) -require- file locks be across all the shares; if you don't have it, you run a serious chance of screwing things up.
WinNT/Win2k with Services for Macintosh is the only server I know of capable of cross-platform locking, and that is pathetic...
Re:Aaaaah (Score:5, Informative)
Aren't people reading this article? The work this fellow is doing is exactly along the lines of what you describe. The problem is that Win2k, et al, have a variety of features (like filestreams) which Samba simply can't implement because the underlying filesystem isn't capable of supporting these features.
So, this work involves modifying Samba (actually, re-architecting it) to allow it to take advantage of the advanced capabilities of some of the new filesystems out there. This will allow Samba to implement *more* of the SMB protocol, such as filestreams, advanced ACLs, etc. BUT, this is a lot of work because Samba is really inherently tied to POSIX, and all the limitations that implies. So, the work he's doing right now is to remove these dependencies and allow Samba to be more backing-store-agnostic.
Re:Aaaaah (Score:1)
We fit this bill at my company. We have an ldap instance that stores all pertinent employee info. It is our authoritative data source. We sync the data from ldap into our NT domain. We want to get rid of the middleman here and do straight ldap authentication to ldap, and then authorization to our file systems, w/out NT.
There is nothing to do this at this point, thus NT lives on.
Re:Aaaaah (Score:3, Informative)
A goodly number of us actually (myself included).
"There's nothing that can be done about it, it's his time, his decision. Still, it sure would be nice for samba to be a full member of a Windows 2000 domain."
Tridge has already implemented AD member support (and yes, a samba server can be a full member of a Win2k domain). The things holding us up from Win2k DC support have nothing
Make smore sense... (Score:5, Funny)
Re:Make smore sense... (Score:1)
Re:Make smore sense... (Score:2, Funny)
Burninating the network
The Samba comes in the niiiiiight!
Re:Make smore sense... (Score:2)
Most people wouldn't know majesty if it came up and bit them in the face...
--
Was it the sheep climbing onto the altar, or the cattle lowing to be slain,
or the Son of God hanging dead and bloodied on a cross that told me this was a world condemned, but loved and bought with blood.
Re:Make smore sense... (Score:1)
linux.conf.au talk (Score:4, Informative)
The article was similar to Tridge's talk on the same subject at linux.conf.au in January - "towards full NTFS semantics in Samba."
The talk (in Ogg Speex audio format) and accompanying paper are on the linux.conf.au CD. There's a list of mirrors on their web site [linux.org.au], both to mounted copies of the CD so you can download individual talks, and ISO images of the whole thing.
Some real information (Score:4, Informative)
Re:Some real information (Score:2)
Re:Some real information (Score:1)
Eh? No XFS + ACLS? (Score:4, Insightful)
Re:Eh? No XFS + ACLS? (Score:3, Informative)
Re:Eh? No XFS + ACLS? (Score:2)
Re:Eh? No XFS + ACLS? (Score:5, Informative)
READ_DATA Permission to read the data of the file
LIST_DIRECTORY Permission to list the contents of a
directory
WRITE_DATA Permission to modify the file's data
ADD_FILE Permission to add a new file to a
directory
APPEND_DATA Permission to append data to a file
ADD_SUBDIRECTORY Permission to create a subdirectory to a
directory
READ_NAMED_ATTRS Permission to read the named attributes
of a file
WRITE_NAMED_ATTRS Permission to write the named attributes
of a file
EXECUTE Permission to execute a file
DELETE_CHILD Permission to delete a file or directory
within a directory
READ_ATTRIBUTES The ability to read basic attributes
(non-acls) of a file
WRITE_ATTRIBUTES Permission to change basic attributes
(non-acls) of a file
DELETE Permission to Delete the file
READ_ACL Permission to Read the ACL
WRITE_ACL Permission to Write the ACL
WRITE_OWNER Permission to change the owner
SYNCHRONIZE Permission to access file locally at the
server with synchronous reads and writes
Re:Eh? No XFS + ACLS? (Score:2, Informative)
Re:Eh? No XFS + ACLS? (Score:2)
For example, on a log file, Root should have the ability to read, but not write, append, take ownership, and so on. The daemon user, however, *should* have the ability to append, but not to write/modify, or read.
Re:Eh? No XFS + ACLS? (Score:1)
Re:Eh? No XFS + ACLS? (Score:3, Insightful)
'jfb
Having root is not the great failure (Score:2)
No, having a root account is not a great failure of POSIX. The great failure is in irresponsibly using the root account like most Linux systems do.
There are far too many things on a Linux system that require root access. Adding ACLs is only have the battle, the other battle is using them responsibly.
However, even without ACLs you can use tools like sudo to avoid passing out the one true root password, or even avoid having a usable root account at all, except through sudo.
Basically, there's a number of
Re:Having root is not the great failure (Score:2)
Blaming the sysadmin for Unix security holes when the entire security infrastructure is what's b0rken is blaming the victim. Shamingly, this is a situation where NT is radically more advanced than most (all?)
Re:Having root is not the great failure (Score:2)
Right, 'cause you know how NT doesn't have an all powerful superuser account. Oh wait, it does. And you know how UNIX systems simply must require the root account to be used. Oh wait, they don't.
NT is more advanced in the sense that it is more complex. If you know UNIX there is hardly anything you can do with Windows NT that is any more secure than UNIX.
UNIX merely exposes the truth about security. Windows NT exposes a model that makes things appear secure when often times there is at least a back do
Re:Having root is not the great failure (Score:2)
Oh, really? Tell me, then, how do I revoke root's ability to even open a file? How about allowing root to read only, and allowing all members of a given set of users the ability to do nothing but append? I'd get into file records, but according to Unix dogma, nobody ever needs those.
Security is complicated because computers are complicated. Sweeping issues under a "not our problem" carpet doesn't ad
Re:Eh? No XFS + ACLS? (Score:2)
Re:Eh? No XFS + ACLS? (Score:2, Informative)
File Streams? (Score:2)
I hated the concept of resource forks on Macs, and I hate this.
Re:File Streams? (Score:1, Informative)
http://www.codeproject.com/csharp/NTFSStreams.a
Re:File Streams? (Score:1)
Re:File Streams? (Score:2)
Eh? What does case-sensitivity (NTFS is case-preserving, in that if an application makes a call to create a file named "FooBar", it'll be named "FooBar", not "foobar" or "FOOBAR", but not case-sensitive, as an application could try to open "foobar" or "FooBar" or "FoOBaR" or "FOOBAR" and all of those would match "FooBar") have to do with multiple data streams (the pathname syntax for which, in Win32 APIs, is "{filename}:{streamn
Re:File Streams? (Score:2)
The concept of supporting at the filesystem level data and metadata together is awesome. It's much cleaner than trying to stash metadata at the beginning or end of the data stream using a myriad of formats. It's only a problem when dealing with other filesystems
Re:File Streams? (Score:1)
...and when using a network transfter protocol that doesn't understand the metadata in question (which is virtually all of them).
Re:File Streams? (Score:2)
I think that's more the fault of the transfer servers and clients rather than the protocols (the protocols shouldn't have to care) but it's still another important case. I guess my point was that while the environment or implementation makes file streams problematic, the concept of file streams, at least for use by metadata, is a good one. For multiple data streams I think something like OS X's bundling (which i
Just one? (Score:3, Insightful)
There can be only one perhaps?
Re:Just one? (Score:1)
Re:Just one? (Score:1)
But did anyone else notice in the article that MS are involed in *yet another* Standards Committee - NFSv4. Whoops, there goes another neighbourhood.
Hachete
trolling since 2001.
I wonder about the samba team... (Score:5, Funny)
These guys look at some of the uglyest packets in the world. And they keep doing it. And they keep coming back for more. Ever hear Tridge talk about whats going on inside the SMB packets? Hes not too hard on MS in the large public forums but see what happens when you hand him a VB or 5 before a talk... then he will give it to you without the sugar coating... Were talking odd sized data structures that may or may not be little endian. Most of the time the structures are hiding inside other structures and the inner and outer structures will have different bitness and different world alignments. Nest a few levels for even more pain. And then repeat. This is what these guys do for FUN! This is why I'm concerned about them.
Now they want to tackle other stuff as well? Maybe they could just throw in Novell's stuff for grins. Once they have done that, they will win the all time award for being the most saito masicistic coders ever. No one will ever be able to beat them. Ever. Its not even worth attempting to compete with them.
Re:I wonder about the samba team... (Score:1)
So's your spelling teacher, apparently.
:)
Re:I wonder about the samba team... (Score:2)
No one will ever be able to beat them. Ever. Its not even worth attempting to compete with them.
Quick, somebody tell the Wine developers!
Rewrites suck (Score:4, Insightful)
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 (Score:2, Insightful)
Re:Rewrites suck (Score:1)
Re:Rewrites suck (Score:1)
Re:Rewrites suck (Score:1)
Read the article.
He speaks at length about the reasons for the rewrite, and how extensive it is.
Re:Rewrites suck (Score:2)
Don't forget the part in the article where Andrew Tridgell says:
"I've spent probably a month or so on the core rewrite so far. It doesn't compile yet. It's a long way from compiling. I'm hoping that by the time the Samba XP conference comes around in Germany, that these core changes will, in fact, be compiling and I'll be able to start getting other developers to look at them."
How can he go a month without compiling? Either his code will be perfect or very buggy. How is he verifying that he has not a
Re:Rewrites suck (Score:1)
You may very well write a more correct version of the original functionality, but any new functionality is just as likely to be correct as the original code. This means some or all your new stuff may be incorrect when you're done rewriting. So then do you rewrite again to fix that? And then rewrite to fix the new stuff in that rewrite? Rinse, repeat... Not a good cycle.
Re:Rewrites suck (Score:3, Insightful)
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
going in the wrong direction? (Score:2, Insightful)
Don't convert the ENTIRE samba to kernelspace; that would be poin
Re:going in the wrong direction? (Score:2)
Samba is found in many different commercial products on many unix-like and non-unix-like OS's. My first exposure to it was on HP-UX, followed by IRIX (on XFS, the best damn NT server I ever ran). Later, I had Samba running on OpenVMS, then Linux, and finally Mac OS X.
Your solution would be great for Linux, but would leave a large portion of commercial users out in the cold. How much benefit would this give Linux, and how much extra c
Re:going in the wrong direction? (Score:2)
The biggest gain Samba could get from kernel-level stuff would be by an NT-like filesystem that supported proper NT ACLs, was case insensitive, and support unicode natively. Unfortunately, the samba right now only likes to be on top of Posix like filesystems. We need a bit of an overhaul before we can begin to take advantage of kernel-level improvements.
From followers to leaders (Score:4, Interesting)
Many opensource projects started out trying to emulate some other protocol, then overtook it and grabbed the lead.. then the proprietary protocol had to follow.
Samba is in a similar position. I think there are improvements to be made, efficiency, authentication, virutualhosts?(multiple domains/workgroups/subnets with the same daemon), better filesystem support, changes in the protocol making it faster, more efficient and unbreakable etc.
If Andrew can release improvements to samba for say win9x, 2000 and xp, replacing some networking DLLS,or just replacing microsoft network client, samba can be in a real leader position. MS SMB code is deinitely buggy or just inefficient, even on one subnet with 8 hosts. Improve that, release the improvement as GPL, and people will flock to it. Best form of marketing of Linux I can think of. OSSphobics will have no way out.
Re:From followers to leaders (Score:2)
Dont be, it IS more reliable and I can attest to it. I'm using FreeBSD + Samba in three different office networks for various reasons including stability, security and features not available in MS SMB. This has been a proven fact for a few years now... whats needed is improvements to speed and efficiency, and Microsoft obviously hasnt led the way there, from Win95 to Win2003. Andrew and the team are going forwa
Can they PLEASE ditch the use of C at this point? (Score:1, Insightful)
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.
Re:Can they PLEASE ditch the use of C at this poin (Score:1)
Re:Can they PLEASE ditch the use of C at this poin (Score:1)
Let The Specification Pick The Technology (Score:2)
Samba is supposed to be a cross platform networking technology. C is perfect for that because it is supported on nearly every system out there. Writing a program in C conforming to POSIX standards means that it will work 99.99997% of the platforms out there n
tell it to DJB and TdR! (Score:2)
And yes, bounds-checking and GC are nice for a lot of things. And they do make it much easier for a mediocre or average (or even a good) programmer to write safe, reasonably secure code. The problem is the overhead. For a lot of things, that doesn't matter, and for a lot of t
can we fix it first??? (Score:1)
Re:I use Samba... (Score:2)
Really? Which OSs don't support AFS? (Score:3, Funny)
So, by "majority of OSes"... Did you mean DOS?
Re:Really? Which OSs don't support AFS? (Score:1)
Re:Really? Which OSs don't support AFS? (Score:2)
The only problem I've ever had with OpenAFS was upgrading from OS X 10.0 to 10.1 with it running (which caused me a kernel panic).
At my last job, we relied on an AFS installation that was a combination of transarc and OpenAFS systems. At home, I've still only got one server (IRIX 6.5 with transarc AFS),
Re:I use Samba... (Score:4, Interesting)
Rus
Re:I use Samba... (Score:1, Insightful)
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
Re:I use Samba... (Score:3, Insightful)
Hmm, not so sure. All that portmap baggage is annoying. And there is no username level security.
Re:I use Samba... (Score:2)
Re:I use Samba... (Score:5, Interesting)
The parent poster writes:
else I'll be using NFS which is a much better protocol in every area.
Er, yes... like how NFS relies on the hostname for security, while SMB/CIFS relies on a password.
NFS is as (in)secure as the r* commands (rlogin, rcp, rsh). It relies on the client to authenticate the user, and the server only trusts certain clients (or anything pretending to be certain clients).
Now I'll admit, a good firewall should keep NFS safe. Under certain setups, even a good router should be enough. However, I prefer to think of a firewall as one layer of security - not my first, last, and only line of defense.
Although I'm not currently using it, AFS/Code seems to be a cross platform (win, mac, unix) secure replacement to NFS.
NFS might be a better protocol then SMB/CIFS in certain areas, but for security, SMB/CIFS wins (even the old versions of SMB that rely on plaintext passwords).
Re:I use Samba... (Score:2, Interesting)
AFS, or OpenAFS is not -only- a replacement for NFS it is way over NFS in terms of security and scalability. If you aren't using a global namespace filesystem, then you can't actually call yourself knowledgeable of system administration. The only replacement for AFS that is even close is Microsoft's "Win2k AD'd dfs", and even it is missing a large number of features that AFS has.
I'm
Re:I use Samba... (Score:2)
'jfb
Re:I use Samba... (Score:2)
Most notably the ability to build a distributed filesystem that doesn't have a single point of failure, as was required by the MS DFS the last time I checked, since all the name re-mapping happens on a singel server. Ugh - what were they thinking? This has got to be one of the most egregious examples of Microsoft not thinking through the problem before writing t
nfs isnt responsible for authentication (Score:2)
It does not rely on hostnames for security, it does not rely on trusting the client to authenticate the user. NFS in fact relies solely on
Sun RPC in fact can be quite secure. There are various security mechanisms it can employ, and the problems you're just describing are all with one specific mechanism: auth_unix. It just
Re:nfs isnt responsible for authentication (Score:2)
Re:why is re-writing software so often glorified? (Score:2)
"Rewrite" is rhetoric here. He is making large changes to the existing codebase, which he says will involve modifying about 30% of the code. He's not throwing it all away and starting again. Calm down, or RTFA.
Re:why is re-writing software so often glorified? (Score:1)
Re:why is re-writing software so often glorified? (Score:1)