Posts – Page 13

DCOM client support

DCOM client support finally works! TODO things left for DCOM now are:

  • Server side support
  • Supporting base interfaces outside current file
  • Fix annoying bug in pidl WRT to IStream_Read
  • Implement IUnknown
  • Implement pinging

comments.

My Samba 4 TODO-list

It seems the list is getting longer rather then shorter…

  • finish gepdump (MGMT support)
  • finish DCOM - generate <code>dcerpc_pipes</code> table dynamically - allow binding strings to contain no transport name
  • client_credentials struct
  • more extensive support for expressions in pidl
  • build system in 100% perl

comments.

Samba 4 milestones reached

  • SPNEGO over HTTP works (abartlet)
  • Samba 4 has its first user (tridge)

comments.

MS RPC flaws

Now that I’ve been working with MSRPC extensively for some time, I’m actually starting to like it ! Although things could’ve been less complex (NDR alignment, for example) the protocol itself is actually quite clean and nicely set up.

Some of the major flaws in MSRPC are (imho):

  • Overly complex. A couple percents of performance boost (if at all) by doing alignment of data types is not worth the trouble.
  • Once you have a certain interface the only way to change an existing method’s parameters is adding a new method with the new parameters.
  • Not everybody who works with MSRPC completely understands what it’s doing and how it works. This has been the cause of quite a few flawed interfaces (the winreg interface for example), causing security flaws and inefficiency.

One of the nice things about RPC (and perhaps also one of it’s problems) is it’s flexibility. The encoding can be changed as well as the transport that’s being used.

comments.

Interview with BitlBee developers

LinuxReviews has interviewed my fellow BitlBee developers and me. Interview available here.

(Update 16:55) Slashdot has a post about the interview as well.

comments.

Rewrite progressing

Finally, the rewrite of the registry subsystem in Samba 4 is starting to finish off. I changed some major things after the initial version:

  • Changed from typedefs back to structs, like we do in the rest of Samba 4 (e.g. struct registry_key instead of REG_KEY.
  • Pass TALLOC_CTX‘s around for memory allocation. No longer give every key or value it’s own TALLOC_CTX.
  • A registry context is nothing but a collection of hives that all have their own root key. In the previous version, there was one registry context with multiple roots. (this makes the backend code much, much simpler)

comments.

Win32 Testing server running

Now that the last few bugs in the win32 version of Bitlbee have been fixed, I have brought up a public test server. Point your IRC client at win32.bitlbee.org:6667 and try it!

The test server is running the 9 Sept snapshot on NT4 inside of VMware.

comments.

samba-docs build system used for AMANDA

Stefan Weichinger has used the samba-docs build system for the documentation of AMANDA, The Advanced Maryland Automatic Network Disk Archiver.

Preview is available here. Very neat stuff!

comments.

CtrlProxy in IRC book

Ctrlproxy is discussed in two hacks in the upcoming O’Reilly title IRC Hacks, edited by Paul Mutton. Both articles were written by Wilmer van der Gaast.

comments.

Version Control Systems

I have been using CVS to store my source code and documents for the past couple of years. CVS works quite well, because it makes synching data between various computers easier, doesn’t require you to make a backup of your files every time they change and makes it easier to work on a project together with others.

However, CVS has its glitches. Renaming/moving files isn’t really handled - there is no notion that a file once had a different name or that its reincarnation is a different file. Secure access to a repository is a pain, especially if you’re using windows. Commits are per-file instead of per-changeset. It is a pretty poor tool for code management, but it’s well known, and it works.

Now that Subversion and GNU arch are becoming more and more widely used, I’ve been checking out some of the newly available VCSes.

After reading a couple of webpages, I have decided to go with Subversion. The two important reasons for this are the fact that Subversion runs much better on Microsoft Windows (a couple of my projects are in MSVC), and that migration from CVS to Subversion is quite easy.

Other than that, arch is a nice project and I’d really like to switch to using arch once it is stabler and has improved win32 support (if it ever will..).

Reasons to use subversion instead of arch

  • Quite similar to CVS
  • Good Windows Support, even a GUI
  • Easy migration
  • Stabler
  • Easier for outsiders to check-out (e.g. only a svn co http:// and you’re done)

Reasons to use arch instead of subversion

  • Flexible, neat design
  • Easier to set-up repository
  • No need for a central repository, easy for people outside of a project to make changes, fork, etc.
  • Hard to learn
  • Fewer dependencies. I know Subversion doesn’t require apache2, but it certainly does require BDB and some XML libraries.

comments.