Open Group Releases DCE 1.2.2 as Free Software

lkcl writes "The Open Group announced 12th January 2005 that they are releasing DCE/RPC 1.2.2 as a Free Software Project - under the LGPL. This is a major coup for Free Software: the Distributed Computing Environment is known to be involved in some major projects. There is a mirror at opendce.hands.com which runs rsync, ftp, and there is also a dce122.tar.bz2.torrent bittorrent running as well."

Comments

open group still matters?

[Anonymous Coward]

This isn't nearly as important as claimed here; other technologies supercede it.

Open the code, but charge for documentation?

[drmike0099]

This is a disturbing trend I've seen cropping up a few times lately, but it seems like all of their useful introductory documentation (at least what they refer to on their website) is available in book format that you have to pay money for. Is the code really open and free if you have to pay money to learn how to use it?

My, how times have changed

[loose canons]

In '93, I was making the big bucks at a defense contractor because I could tell them how/where to use DCE.
It is interesting to see the difference between the openess of the OSF and the openess of the open source movement [all that gnu software!] begin to blur.
I hope that exposure of the security code buried in DCE, especially where it uses kerberos, will help polinate other open source projects with improved security features.

Re:WTF?

[finkployd]

Quick description. It is a couple of things.

Importantly, it is an extension of KerberosV to store group information in the ePac (like MS Kerb only not digitally signed by a private key that only they can use to lock everyone else out).

It is a secure, authenticated RPC with authorization support.

Built on top of this is a distributed filesystem that is basically 10 years or so ahead of OpenAFS (DFS was the sucessor to AFS way back when, AFS has not nearly caught up in features yet)

It also is a directory system (CDS) which is largly irrelevent now since we have LDAP (both are decended from x.500 and LDAP is heading back towards that more every day)

Finkployd

DCE, Microsoft and DCOM

[Earlybird]

Microsoft's RPC framework, which is built into Windows, is actually an implementation of DCE. While it's a long time since Microsoft used it directly, it's a nice platform for remote communication; it's a mature API that supports a wide variety of protocols (eg., TCP, UDP, local pipes), authentication mechanisms, marshaling mechanisms etc.

Microsoft's COM (also known as DCOM) sits on top of this RPC layer to implement a distributed component object model -- one of Microsoft's finest and most underrated inventions. It's also one of their most copied technologies -- KDE, GNOME, OpenOffice (UNO) and Mozilla (XPCOM) all implement very similar object models.

Of course, DCE RPC is also famous for the UUID (aka GUID) algorithm -- 128-bit identifiers whose uniqueness is mathematically guaranteed as long as the generator can access a network card with a unique MAC address.

Re:DCE, Microsoft and DCOM

[mihalis]

Microsoft's COM (also known as DCOM)

No, DCOM is distributed COM, not identical to COM, but a superset. COM itself is a component-object model that is a nice piece of work in my opinion.

COM is a binary, language independent standard for using services provided by objects without depending on the implementation.

Instead of direct linkage to functions, for example, clients must request access to interfaces, and only use the services if the request succeeds.

Interfaces amount to a C-Cstyle struct with function pointers, with the first three methods being QueryInterface(), AddRef() and Release(). The latter two functions are merely ref-counting for tidiness, so the primary way to use services depends on driving QueryInterface to discover other Interfaces and then call them.

There is a nifty mapping of this struct definition into C++ pure virtual base classes so that COM programming in C++ can be quite nice (especially with smart pointers).

It's really other stuff layered on top of COM in the standard Windows way that makes the whole programming experience less pleasant (e.g. MFC message maps, ATL thunking - thinks that just puzzle me when I bump into the code).

By the way, this all works pretty nicely on Unix (especially modern ones like Solaris or Linux). You just need a certain maturity in the C++ compiler so that static_cast works nicely to have all of this goodness available, and you need to link your "DLL"s (aka shared objects) properly (reduce the scope of the functions you aren't making available to clients of the library e.g. with linker mapfiles).

Unfortunately Eric S. Raymond's "The Art of Unix Programming" is hopelessly weak when it dismisses these aspects of Windows programming which for me somewhat undermined the entire book. Then again, I don't think ESR is very fond of C++, which was one of the big problems that COM solved (e.g. the unstable C++ ABI for many, many years).

Re:Nice software, but......

[lkcl]

ah - that's the beauty: GSS-API has been added to FreeDCE already, by Luke Howard of www.ldap.com.

and if it's added to FreeDCE, then DCE 1.2.2 gets it too - once DCE 1.2.2 has been autoconf'd and brought up-to-date like FreeDCE already is.

Re:WTF?

[finkployd]

the lock-out you describe was done by _microsoft_ as part of their use of kerberos in "active directory": they used the "application specific" field in order to save on round-trips (and then extended their bloody SMB protocol in order to _add_ a couple. bastards).

And now that it is open sourced, perhaps someone (or me, whatever :) can get around to fixing the screwy case issue with dce cell naming that prevents us from making a one way trust setup between active directory and dce (having the ms kdc being a slave to the dce kdc)

AFS, OpenAFS, DFS - it's a long long story for another day, methinks :)

We (PSU) being to my knowledge the largest and most active DCE shop still around (130,000+ active principals, custom designed DCE-RCP apps everywhere and I KNOW I am the only person to port a custom full featured DCE-RPC server to OS/390, lots of stuff built on top of DFS, etc), are unfortunately really aware of this. NFSv4, while supporting K5 is a joke for what we need, OpenAFS I believe still uses some kludgy K5->K4 conversion internally and is missing byte level locking, some of the replication, and file level ACL features we use and love, and SANS are kind of a joke too.

*sigh* I'm glad this happened, but we REALLY could have used it a year or two ago. There is a lot of work ahead for the community to make this useful.

Finkployd

Re:Didn't M$ steal this?

[lkcl]

... mr fink, i'm sorry but i do have to correct you on a couple of points.

namely, that microsoft got hold of the BSD-like-licensed DCE 1.1 "reference" implementation so the "stripping of all security" was done by TOG not by microsoft.

MS, who had and still have someone from Apollo working for them, knew and knows how DCE/RPC works _in_side out, and so was able to sort stuff out for them.

MS _did_ have to add some stuff like "implicit handles" and MSRPC _does_ have the ability to do Unicode Strings (and between Wez Furlong, Luke Howard and myself, that's all now been added to FreeDCE).

i'm still working on adding NTLMSSP and NT Named Pipes to FreeDCE - something that luke howard has already done for his proprietary XAD server (www.ldap.com).

the differences are not _that_ significant, is the bottom line.

Re:Didn't M$ steal this?

[lkcl]

none - the reference implementation was available almost right from the start - i _think_ - otherwise microsoft wouldn't have been able to get hold of it and use it for Windows NT 3.1.

FreeDCE, however, has _two_ security plugins: GSS-API (thanks to luke howard), and NTLMSSP (code from samba tng which i wrote, based on my and paul ashton's "welcome to the samba domain" work in august 1997)