Slashdot Mirror


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."

13 of 137 comments (clear)

  1. Extended Data Types by rf0 · · Score: 4, Interesting

    They way I'm reading this support for things like XFS/ext3 etc is that samba will implment things such as native ACL's and such like. However I can help but wonder how these will be preserved if say the server is XFS and the Client FAT. The only think I can think of is some sort of file which stores it as Metadata. Of course if it was XFS -> ext3 then you might be able to convert to the native setup but it might be buggy and subject to the filesystem formats changing

    Rus

    1. Re:Extended Data Types by Abcd1234 · · Score: 4, Informative

      However I can help but wonder how these will be preserved if say the server is XFS and the Client FAT.

      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.

  2. license to change by drgroove · · Score: 5, Interesting

    Samba's existence is vastly important to the adoption by corporate management of perceived 'alternate' computing systems (i.e., Linux, Mac, sometimes Unix, as opposed to Windows) in the datacenter. The simple fact that there exists an easy-to-use, open source method of interconnecting disparate file systems, allowing multiple OS co-existance, is often the lynchpin in convincing managers to permit non-Windows systems to be deployed in a company. I have worked in several situations where employees have wanted to use Mac OSX desktops or Linux/Unix servers (etc.) in an all-Windows shop, and managers balked at the idea until they were convinced that data could still be exchanged, and that the 'alternative' OS'es could still 'talk' to the Windows machines.

    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.

  3. Aaaaah by stratjakt · · Score: 5, Interesting

    Who's working on polishing up that ActiveDirectory and Kerberos stuff so I can continue to use my samba based PDC with WinXP.

    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.

    --
    I don't need no instructions to know how to rock!!!!
    1. Re:Aaaaah by Abcd1234 · · Score: 4, Informative

      But I'd wager the lions share of it's user base want samba to replace/supplement Win2k Server, and soon Win2003.

      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.

  4. Make smore sense... by forau · · Score: 5, Funny

    When I first read the headline, I thought that it said "Trogdor Taking Samba Beyond POSIX." I thought "Why would the burninator bother with this? Doesn't he have villages to burninate?" Yeah. I'll go ahead and read the article now...

  5. Re:ext3? by amcguinn · · 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.

  6. Some real information by Libor+Vanek · · Score: 4, Informative

    I was on Monday and Tuesday on SambaXP where Tridge had talk about Samba 4. Also we discussed possibility of having completely Windows-compatible (and NFS v4) compatible ACLs on standard fs like XFS and ext3. Result was that Samba team needs a kernel interface for this so I'm going to hire some summer students for this and I expect some working code on autumn.

  7. Re:Eh? No XFS + ACLS? by Libor+Vanek · · Score: 5, Informative

    No exactly. For example see NFS v4 ACLs:

    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

  8. I wonder about the samba team... by thogard · · Score: 5, Funny

    I don't think the Samba team is well. At least not in the head anyways.

    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.

  9. Re:I use Samba... by dasunt · · 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).

  10. Rewrites suck by Cthefuture · · Score: 4, Insightful

    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.

    --
    The ratio of people to cake is too big
  11. File locking by SuperBanana · · Score: 4, Interesting
    But I'd wager the lions share of it's user base want samba to replace/supplement Win2k Server, and soon Win2003.

    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...