Slashdot Mirror

No problem. Samba is still a really fun and interesting program to work on ! I'm going to be up in Redmond next week working with Microsoft engineers on adding POSIX compatibility to SMB3+ and then at the SNIA Conference in Santa Clara, CA the week after giving a couple of talks, and attending the SMB3 plugfest (where we get to work out all the interoperability bugs with other engineers working on SMB).

https://www.snia.org/events/st...

See you there ! :-).

Most of the time - if not all these days - should adhere to the Common RAID Disk Data Format (DDF). That means you can migrate an entire member set of RAID5 from one controller to another and important the foreign volume to be mounted.

http://www.snia.org/tech_activ...

Unfortunately, many of my users work at sites that block BT, forcing them to revert to a horrible HTTP option.

And no, rsync isn't a solution for our situation.

As to what is needed, the primary thing is better tracker and seeder daemons. I use opentracker, which is OK but hardly perfect. I seed with deluge because it's one of the few seeders that can be run as a daemon (almost all BT clients expect you to dedicate a GUI window to them or they stop running--imagine what running a Web service would be like if you had to have a GUI for every instance of Apache).

to being able to implement this at home and at work to word towards replacing Windows Server 2003.

For home or small office use, this might be an interesting read. It's the slideshow from Kai Blin's Samba ARMed and Ready: Running an Active Directory DC on 2 Watts talk on an embedded Samba4 DC.

reference links

TwistedStorage

XTreemFS

Tahoe

XAM

GPFS

http://www.snia.org/tech_activities/standards/curr_standards/ddf/SNIA-DDFv1.2.pdf

DDF is a standard for this stuff, and you might be able to migrate within a brand - I 'm not quite sure how much DDF is used but i've seen it specified for some Arcea and Adaptec.

Anyhow, Id go with backing up to more HD's, and moving them to safe places (fireproof safe) with periodic testing.

Also, I'd put multiple copies of the most important data to say optical media or what not, and move some stuff offsite, and maybe grab some space online for some more backups.

JBOD is a fucking standard.

The closest thing to a standards body I'm aware of for RAID would be SNIA.

http://www.snia.org/education/dictionary/j/

They say:

Originally used to mean a collection of disks without the coordinated control provided by control software; today the term JBOD most often refers to a cabinet of disks whether or not RAID functionality is present. See disk array.

Note that this actually does *not* match my definition, insofar as it includes shelves with RAID -- but it doesn't even mention spanning!

There just aren't any good long term options today for either consumers or businesses. Yes, CDs and DVDs can fail, but there's another problem - in twenty years are there going to be working devices that can reliably read that media? Maybe, maybe not. Earlier this year, the Storage Networking Industry Association (SNIA) started up a Long Term Data Retention group to address this very problem. Perhaps they'll be able to come up with something.

Until then the only "solution" is to migrate data from medium to medium every few years.

There just aren't any good long term options today for either consumers or businesses. Yes, CDs and DVDs can fail, but there's another problem - in twenty years are there going to be working devices that can reliably read that media? Maybe, maybe not. Earlier this year, the Storage Networking Industry Association (SNIA) started up a Long Term Data Retention group to address this very problem. Perhaps they'll be able to come up with something.

Until then the only "solution" is to migrate data from medium to medium every few years.

Quite the contrary! SMB and CIFS are industry-accepted standards. It just turns out Microsoft doesn't follow their own specs.

We have this already..it's called the SNIA SMI... have you not heard of it?

http://www.snia.org/smi/home ..no thanks IBM.

I know the author of a similar book that hasn't quite finished up yet. He was concentrating on the SAN's aspect of it since NAS security is pretty much the same FAQ as 'how to setup a file server'.

Secure SANs was slated to come out last year but hasn't ever been more then a link on Amazon. It dealt with the ugliness of iSCSI and how the 'air gap' security that protected this data for so long is now gone and storage administrators are struggling to learn how the real world works.

Not to bash storage admins but they've relegated most of their 'security efforts' to LUN masking and other such techniques. Now that SCSI drive commands are traversing networks huge security vulnerabilities are opened up. I read an advanced chapter of the Secure SAN title and the best part was an executive from a prominent NAS company stating that he wasn't worried about the security of the products since "only a handful of ppl in the world could have this conversation".

Check out the recent efforts at Storage Networking Industry Association who have come as close to working miracles as I've personally seen. They have managed to create some various technial frameworks and security processes that make vendors work together.

One interesting note about the book featured here is that it also deals with NAS and DAS. NAS and SANS have been fighting it out as IDE and SCSI have. One is cheap and easy the other pricey and very difficult. DAS on the other hand is a joke to me. The ability for one computer to change bits in another's memory DIRECTLY does not sound like a good idea. Hackers have worked for decades to write shell code that allows the ability to change bits in memory and now the storage industry has created a way to get directly in there bypassing all OS security.... yea great idea

After reading the CNet article, I still couldn't figure out why this was necessarily a great thing. So I went over to SNIA's website and read the white paper.

Anyway, it makes more sense now, and I can definitely see benefits. What we're talking about here is network-accessible storage with a very low barrier to entry, both in cost and in expertise to set up. In a way it reminds me of the Filer (1Tb filespace machine that we used via mounting NFS shares onto it) I had at my last job, but much, much less expensive and much, much easier to run.

Interesting stuff, at any rate.

With regards to CIFS it's controlled by SNIA. You can find the spec at http://www.snia.org/English/Work_Groups/NAS/CIFS/i ndex.html.

It's Microsoft's extensions that make it a problem. Someone more knowledgeable might want to clear this up a little better than I can.

With regards to CIFS it's controlled by SNIA. You can find the spec at http://www.snia.org/English/Work_Groups/NAS/CIFS/i ndex.html.

It's Microsoft's extensions that make it a problem. Someone more knowledgeable might want to clear this up a little better than I can.

IANAL. AYAL? Apparently, you're not, otherwise you'd have filled half your post with legalese saying that it did not constitute legal advice.

I think you're wrong. If you write an independent work that just happens to rely on a previous work for a great deal of its information, it isn't automatically a "derivative work." It would be nice if you cited the original as a source, but that's a separate issue.

If I were creating a new work that covered the same information, I would make sure that as little information as possible came from the Microsoft CIFS document. Find alternate sources of information wherever possible, and list the alternates as sources as well.

However, such an endeavor probably isn't necessary. The Samba team itself claims that a more complete and accurate document exists: The SNIA CIFS document (pdf).

How about translating the whole thing into "Yoda-speak," and then claiming original rights as a parody? That would lead to an interesting legal battle, if nothing else. "Read this document into the court record, I will."

Don't forget to rate the license!

The Microsoft document is a license agreement attached to a technical document which provides information regarding the CIFS protocol and gives legal control of the protocol to Samba.org. The CIFS protocol (also known as the SMB protocol) is the core protocol that Samba implements to provide seamless mind sharing interoperability with Microsoft networking products.

The key concerns that have been raised over this document are:

• Whether the Samba Team needs write access to this document for future developments in Samba
• Whether the patents mentioned in the Microsoft license agreement have any impact on current or future usage and development of Samba
• Whether the anti-GPL components of the Microsoft license will change the use of the GNU General Public License for Samba

For people interested in a more accurate and complete description of the CIFS/SMB protocol the Samba Team recommends the recently released SNIA CIFS document, which has been developed through a process of industry collaboration. CIFS and PatentsIn the text of the license agreement Microsoft mentions two specific patents that relate to the CIFS/SMB protocol. The license grants a royalty free license to these patents, but specifically excludes free software distributed under the GNU General Public License from this royalty free patent license.

Some people have incorrectly assumed that Samba must implement the methods described in these patents. In fact, the methods described in these patents are quite inappropriate for a Unix/POSIX CIFS implementation such as Samba. It would not even be possible to implement the methods described in these patents in a portable POSIX application. Instead, Samba treats the SMBreadbraw and SMBwritebraw protocol elements in the same way as all other elements of the CIFS/SMB protocol. This means that as far as we are aware Samba is completely unaffected by the existance of these patents.

We would like to also point out that these patents cover an obsolete section of the CIFS/SMB protocol that Microsoft themselves have abandoned in their own products long ago. Microsoft abandoned these "raw" protocol operations in CIFS because their basic design is fatally flawed. Samba and the GNU General Public LicenseThe GNU General Public License has proved to be a very successful model for the development of Samba. While Microsoft labels the GPL as "Intellectual Property Impairing" in their license document, it has in fact proved to be a very successful vehicle for encouraging the development of a high quality CIFS/SMB implementation. Far from "impairing" intellectual property the Samba Team believes that the distribution terms of the GNU GPL has provided an environment which has encouraged a high degree of industry collaboration to the benefit of both Samba users and the many successful companies that have built a wide range of products on top of Samba technology.

The Samba Team fully intends to continue in the use of the GNU GPL to foster innovation and the development of enterprise class file and print serving solutions that seamlessly interoperate with Microsoft networking products.

I have not heard anything about Patents. I think that Advogato post is exaggerated that bit a little. The documentation on CIFS that has this Royalty Free License associated with it is just a dumb Windows Help File:

www.microsoft.com/downloads/release.asp?ReleaseID= 37530

It's derived from the same old documention that was released as an IETF draft several years ago. The SNIA took over that doc and reformatted and added a little bit to it. It is freely available here:

CIFS Protocol Document Version 0.9

I think MS is just going to release whatever they have on this sort of stuff under this "Royalty Free" license to appease the DOJ and this silly .chm file wound up in the out-bin. Don't read into this too much folks. There is no way MS could use this as an angle on revoking previously released information about these protocols.

If they release something that we actually need like the IDL to their DCE/RCP calls under this "Royalty Free" license, is that bad or good? I think it's good. It's certainly better than nothing at all. I think new products with great interoperabilty with Windows would emerge. Viable companies would be formed around this stuff. There's no reason why a company couldn't release binaries for free. And this information will eventually trikle down into the Open Source community anyway. It's unavoidable regardless of any fandangled licenses.

According to this post on Samba Technical, the Storage Network Industry Association will soon release version 1.0 of their SMB/CIFS documentation. Version 0.9 has been available for some time.

The SNIA doc was based on the earlier Leach/Naik IETF draft, but was updated based on input from many sources, including IBM, HP, the jCIFS Team, Microsoft, NetApp, the Samba Team, and others. The new SNIA doc does not have the licensing restrictions of the Microsoft release.

-- JLM

1. Cost, That's a lot of machines to buy for a single storage array
2. Admin time. Upgrading the OS for a bug fix is a much bigger pain when you have 8 machines instead of 1
3. Space. You're building a rack for these machines and they're eating up at least 8U of space, probably more if you want to keep the cost down to Earth
4. Software. All SAN solutions I know about are proprietary. Nobody builds RAID code that runs over a network.

Humm, I wonder if the samba crowd did a bit of slashPR for the MaY 22 conference

The samba crowd has a few speaking slots in the Conference Agenda. With topics like "SMB Interoperability Validation Issues" and "NT Domain Interoperability " Do you think that this will be worked out next week.

Humm, I wonder if the samba crowd did a bit of slashPR for the MaY 22 conference

The samba crowd has a few speaking slots in the Conference Agenda. With topics like "SMB Interoperability Validation Issues" and "NT Domain Interoperability " Do you think that this will be worked out next week.