Slashdot Mirror
Jeremy Allison Answers Samba Questions
Kerberos
by Claude Debussy
Microsoft has apparently molested Kerberos in their latest W2K upgrade, can you clear up some of the confusion about how this will effect samba server- NT.
I've heard their exploitation of the protocol won't affect samba, some say it wreaks havoc, what's the scoop ?
Jeremy:
A: Short answer - it won't affect Samba.
Long (*very* long :-) answer - it's a *very* subtle monopoly play by Microsoft to try and entend their desktop monopoly into the server space.
Kerberos is an authentication protocol (ie. it tells a server *who* you are). It is not an authorization protocol (ie. it doesn't tell a server what you can do). Authentication is all well and good, but in order to have useful network security you also need authorization as well. In UNIX (and NT) this is provided by your user id and a list of group id's to which you belong (on NT both user and group lists are SID's - security ID's - globally unique 128 bit ID's).
Kerberos allows a user to get tokens called 'tickets' that allow them access to services on the network. The initial ticket a user must obtain is called a Ticket-granting -ticket, or TGT. On standard UNIX implementations of kerberos, a users *name* (called a "principal") is used to get a TGT and then this name is looked up using the standard UNIX password database mechanisms (ie. /etc/passwd, NIS, NIS+, LDAP etc.) into a uid and a list of associated gid's that represent the authorization of that individual. When this user wants access to files or SYSV shared objects (the only securable things in standard UNIX) then the uid/gid list is checked against the access control of the object (usually user/group/world triple) and access is allowed or denied. Custom servers that use Kerberos tickets (eg. an Oracle database) use their own authentication mechanisms based on the name of the ticket owner (kerberos tickets contain proof of the ticket owner in the ticket). All well and good.
Note that in the above, Kerberos has *nothing* to do with the mapping between name and uid/gid list.
Now lets go back into history. Back when the Open Software Foundation ("a greater hive of scum and villainy has yet to be seen, we must be careful" :-) developed DCE (distributed computing envionment, which didn't work) to compete with SUN ONC/RPC (which *did* work :-) they decided to use kerberos authentication. However, they needed an authorization mechanism. Now kerberos 5 has a field in the TGT market "application specific data". But trying to be at least good citizens, and knowing that they wouldn't get the whole world to adopt their version of this field, they developed a secondary ticket format, called a PAC (privillage authorization certificate) that contained everything that a Kerberos 5 TGT did, but in addition had a list of DCE UUID's (which coincidently are also 128 bits :-) to represent the main userid and list of groups to which the user belongs. Now the great thing about this method was that it allowed a competely generic MIT code Kerberos 5 server to act as the KDC (Key Distribution Center) and have a *separate* database containing the authorization data (the name - uid/gid list mapping) contained in a separate server process. Ah..... security :-).
Now enter the 800lb gorilla..... :-).
In the grand tradition of "embrace and extend", Microsoft decided that as no one else was using this field they might as well just appropriate it for their own use, and so created the *exact equivalent* of the DCE PAC tickets, but added the additional data directly into the standard Kerberos 5 TGT (something the OSF for all their sins decided not to do). This is bad enough, but they have yet to document the format of the (cryptographically signed) data they have placed in this field. Now certain people I trust greatly at Microsoft have told me that they do intend to document this data format, but I have been asking publically now for over 2 years (one of my proudest moments was being publicly called a "troublemaker" over this point by a Microsoft VP at a Microsoft professional developers conference :-) and have yet to see any documentation on this field.
What does this mean ?
Well, for Samba as a file and print server, nothing at all. Currently we don't support the Win2k kerberos authentication (no user demand right now) and when we do we will be able to use the ordinary kerberos principal information to map directly into a UNIX uid and gid list, just like we do now (remember, we won't need to decode this extra info). However, if we ever wanted to get into the Win2K domain controller business (using kerberos authentication, not MS lanman backward compatible authentication, as Luke already has this working in the TNG Samba branch) then we would be stuffed...
Don't be fooled by the hype.
by Anonymous Coward
Samba? Samba? That word says one thing to me, and one thing only: Some slinky disreputable Latin American gigolo character, skulking around the suburbs and worming his way into the hearts of virtuous women, destroying their lives and moving on. The word "samba" says nothing to me of quality or reliability. Nothing.
So Jeremy, I ask you: Why do you choose to be associated with such a grossly disreputable and frankly immoral product? Why do you choose to spend your days lazing around the Beverly Wilshire, oiling your pencil-thin mustache, langorously sipping mai-tai's and attempting to seduce other men's wives? Aren't you disgusted with yourself and the low state to which you've fallen?
Have you no shame?
Jeremy:
A: No, I have *no* shame at all. And I'm not *ashamed* of having no shame either :-). Anyone who knows me knows I will drop my trousers at the *slightest* pretext, and parade around naked, for all the world to see! And I'm *PROUD* of it dammit ! Remember, for all you gits who for some reason think I'm an Australian (pah!) I'm a Brit - and my home town is Sheffield (in the Independent Socialist Republic of South Yorkshire). That's right - "THE FULL MONTY"! I've never even *been* to Australia, and have *never* eaten koala or emu (although I must confess to eating kangaroo once, but that was in New York, so I can be excused. They said on the menu it was cat :-).
As for "worming my way into the hearts of virtuous women", I personally think that virtue is *very* overrated. I didn't get onto the 100 most eligable men in silicon valley list for nothing you know (in fact I didn't get on it at all :-).
Besides, I think my pencil-thin mustache looks rather good.... :-).
For the Challenge or Outcome
by Col. Klink (retired)
Do you work on SAMBA for the thrill of the challenge of reverse engineering SMB or just for the practical uses? If MicroSoft were to open their protocols (perhaps as part of a DoJ settlement), would you still find it as much fun?
Jeremy:
A: Well, I work on Samba for the fun of it. I've been doing Open Source work now for over 8 years (back before there *was* Open Source, you young whippersnapper, we used to call it "Free Software" back then, when I had to lick t'road clean w'tongue... :-) and it's *always* been fun. I'd do it even if I didn't get paid to do it (DONT TELL VA ! :-).
As for Microsoft opening their protocols, they have tried to document what their clients do and do you know something, it doesn't make *any* difference. They have 100-200 Million clients out there, all with weird bugs (trust me on this :-). SMB is such a *horrible* protocol it can't be properly documented, as the real spec for SMB is "what Windows clients do on the wire". This is one of the reasons that Samba is becoming so popular as an OEM SMB solution, as writing your own SMB server from scratch is *hard*. People look at the published specs, think, well this can't be so bad :-), and start coding. Then they find the way the clients deviate from the spec and they're in a world of pain :-). Many of them end up licensing Microsoft server code, or start using Samba. SGI, Veritas, HP, Cobalt, Whistle (now IBM) and too many others to count are all shipping Samba based products now.
Replacing NT
by Pheros_7f4
I am continually amazed each time a major release of Samba comes out how well it works. My question is, I know that the Samba group has been working towards make Samba a suitable replacement for NT. How far do you expect that to go. I know you're in a continual battle with MS changing things with every minor release, but do you expect to someday get to the point where I can completely replace my NT PDC machine with a Unix/Linux box that has the same functionality? Perhaps the same question stated differently is what are the long term goals for the project in relation to NT PDC Server compatibility? Any estimates on how long such compatibility will take?
Jeremy:
A: Well, there are two goals really here. This question actually brings out some of the tension in the developers in the Samba project.
There are those of us (Andrew, myself), who see Samba as a UNIX file/print server with PDC-like features. And there are others (Luke mainly) who want to completely replicate all features of NT, whether they fit into the UNIX model or not. My question to you is - why do you want Samba to "save" you from NT? If you want the features of a PDC you know where to get them - www.microsoft.com (and they're not very stable). The Microsoft domain model is a *very* poor fit into the UNIX world, and it's a constant battle to mangle the NT semantics to fit them into a UNIX world. I *like* the UNIX model. I think it's a better, more stable, more proven model than NT. I guess our (Andrew & I) motto is "as close to NT as neccessary, but no closer".
Having said all that, Luke has made remarkable progress in the Samba-TNG branch (The Next Generation, for all you Star Trek fans out there :-) in getting NT PDC support working. However, this is not yet production code. The current plan is to mine the TNG branch and bring back as much of the working and *secure* PDC stuff to the HEAD branch (which will become Samba 3.0) as possible, and provisinally ship this by October this year (expect this to slip - no - *depend* on that date slipping :-).
But being totally honest, as Samba is having to reverse engineer *hundreds* of undocumented MS-RPC calls, there will always be some areas where we don't have the exact functionality that they do as a PDC/BDC. I'm not too unhappy with that - like I say, I consider that model an inferior one anyway (and *definately* a less secure model - you can trust me on that :-). If you need NT - you know where it lives....... just don't complain when it crashes on you.
ACLs
by Anonymous Coward
What are the plans for ACL support? I mean the stuff that comes up when you do (in NT) Properties, that second tab, then the Permissions button and get the list of users and groups. Right now we can mess with the existing user and group, but adding people fails.
Will this tie in with the Linux patch to add POSIX ACLs, or will it happen above that layer in a file Samba maintains?
The possibility exists for me to subvert W2K at my place of business if Samba can do this for my users. I hope this happens soon.
Jeremy:
A: Good news for you :-). HP has contributed a large chunk of code to do exactly this. The target is to get this code into the 2.0.8 release (sometime before August). I already have code that allows a UNIX user and group list to be displayed at the NT dialog box (I checked it in this morning), but it will need to be heavilly re-written before it goes into the production release. Currently it enumerates the *entire* passwd/group database each time (imangine *that* CPU load on a busy NIS server :-). As for the ACL work - we are adding a layer such that Samba will send NT style ACLs into that layer on set, and get NT style ACLs back from the layer on get. This layer will be replaceable so that the ACLs can be mapped into the native ACLs that the filesystem supports, IRIX ACLs on XFS, HP ACLs on HPUX, Solaris ACLs on Sun (you get the idea).
The default mapping will be the current user/group/world mapping we have now. Unfortunately, until Linux gets support for POSIX ACLs then we will only be able to use the default mapping on Linux. We have always been against using a non-OS layer (ie. dot files containing ACLs) in Samba to control access as this is just a *home* for security race conditions (just ask the AT&T "Advanced Server for UNIX" vendors :-). Samba will always map the native filesystem permissions into NT ACLs and vice versa, and allow the underlying OS to perform the real access control. That's the only secure way. The challenge is to provide a mapping between NT ACLs and native filesystem ACLs that doesn't violate the principal of least suprises for the admin.
Report Comments
by brunes69
I am currently in the process of writing a university-level report for a course I am taking. The topic of the report will be SMB vs. NFS. I am not trying to identify a clearly "surperior" protocol, I am seeking rather to simply present as much detailed facts/benefits of each and have the reader decide for themselves.
Obviously you would be an ideal person to ask about this topic. What are your feelings as to the advantages SMB has over NFS, if any, and how could the benefits of NFS, if any, be carried over into SMB?
Jeremy:
A: SMB sucks! *Really* *really* sucks :-). The complexity of SMB is one of the main reasons that NT is so unstable (Win2K isn't much better here) as it is not possible to do a safe and clean kernel implementation of the entire protocol. They even process DCE/RPC calls in kernel space for heavens sake!
Please don't ask for Samba to become part of the Linux kernel for speed purposes (as some have done). Both Linus and the Samba Team don't want this. I'd rather be slightly slower but running on a robust system, than have kernel speed and NT stability :-).
As part of their CIFS/9000 product HP have added some UNIX to UNIX SMB calls - allowing SMB to have UNIX-like semantics. However, the SMB locking semantics are very crude compared to POSIX locking semantics (no overlapping lock ranges, no spits/merges, no lock upgrades/downgrades) so it makes a poor fit for a UNIX to UNIX protocol (unless POSIX compatible locking calls are added).
SMB wasn't designed remember, it grew like a particularly ugly wart - with layers and layers of glop added onto a simple DOS filesharing interface, so it has no consistency at all. It has a basic header size of *39* bytes for heavens sake !
NFS also sucks but for different reasons :-). Seriously, the only nice feature of SMB is server-terminated leases (aka Oplocks). Andrew and I have been talking with Peter Braam (he of Coda fame) about a new filesystem he is developing called "Intermezzo" - I have much higher hopes of that as a distributed filesystem solution.
This is *much* too long a question to answer fully here I'm afraid. It's a research paper topic (oh wait - that's what you're writing :-).
Samba and Active Directory
by dee^lOts
With the release of Windows2000 we saw the introduction of a new computer, user, group managment system. Microsoft included some ability to be backwards compatible with WindowsNT Servers, Microsoft also included the ability to run Windows2000 in "native mode." which effectivly disallows any NT client/server from participating in it's user management. How will this affect Samba? Will Samba include Windows2000 "native mode" support, also will the AD tools used to administer a Windows2000 Server be able to administer a Samba server?
Jeremy:
A: Not initially. AD is just an LDAPv3 server. Samba doesn't serve LDAP. However, Gerald Carter (one of the Samba Team) is getting ready to start working on Samba/LDAP integration, so that a Samba server will get all the user/group authentication info from an LDAP server. You really need to ask this question of the OpenLDAP team, as it's important that OpenLDAP get to LDAPv3 as soon as possible to work with AD.
This is another one of those "Samba won't become a version of NT on UNIX" questions. We will just co-operate with other services running on UNIX to provide the same functionality.
Right now Win2k client compatibility is being addressed (Samba 2.0.7) but to be honest so few of our users are actually using it in anything more than test servers right now it's too early to say what effect (if any) Win2k will have.
Running Win2k in "native mode" will, as you point out, prevent any current NT server from participating. Hands up how many companies are going to convert *all* their NT servers to Win2k immediately..... you there at the back, you're not fooling anyone... you know Microsoft, put your hand down - you know that NT 4.x will be on your network for several years at least.
Reverse Engineering SMB
by Anonymous Coward
Jeremy, first, a BIG thank you for your work, I am sure you could lay a pizza-track from Earth to Jupiter by now with the money you saved people who would have had to buy Windows NT-Server. The issue of reverse-engineering has become a very *hot* issue recently with the advent of CSS source-code to authenticate DVD-ROMs and also descramble the content. My questions:
- How much reverse engineering went into the SMB and WINS protocols, in contrast to real coding, say up to the first usable share exported from a Unix machine?
- Did you peek under Microsoft's hood and examine some VXDs or NT kernel drivers to get to those last and hardest 10% of insight?
- How important do you think is the roll-out of working PDC-code?
- Finally, on the law side of things, there is a German law that explicitly allows reverse engineering for the purpose of interworkability. What has been YOUR legal situation (being "down under"), has Microsoft ever asked you to stop your work (BEFORE they needed it in their DOJ case), or even threaten you with legal action or a life-time supply of pizza?
Jeremy:
A: I am *not* "down under". I have never been there :-).
Ok, now I've go that off my chest :-), reverse engineering by looking into Microsoft disassembled code has never been a big part of how we make Samba work. We use the published docs (which are enough to get you started) and do wire sniffs almost exclusively.
To get a first usable share took no reverse engineering at all. Andrew did that with all on his own with a packet sniffer and a *lot* of coffee :-). Most of the other protocol levels were done using the X/Open spec document and a lot *more* packet sniffing (and some help from a second hand bookshop local to me in Mountain View, California :-).
The initial NT Domain protocol work was done in the EU, where such reverse engineering is explicitly permitted. I also believe that Australia now has a similar law, so Andrew will be fine (I may have to go visit him if there is certain "sensitive" reverse engineering work that I need to do :-) but currently this has not been a real problem. Luke now has reached the point where he can look at an MS-DCE/RPC network trace and just *know* what the fields are (you think I'm kidding - I've seen him do it. It's spooky. He did write a book on this you know :-).
However, I am concerned with the insanity of laws like UCITA and the Digital Millenium Copyright act that the USA is becominng a very poor place to do technical work. I'd better hang onto that UK passport.... :-) :-).
VFS
by Quicker
At one time (when I actually had free time) I was getting into the VFS system that is in SAMBA. For those that don't know, a gentleman named Tim Potter had started the VFS code because he wanted to use SAMBA to mount his tape drive. I was interested in extending SAMBA with VFS to mount relational databases as a file system so I could just copy objects into the tables of a database using normal file manipulation tools like cp and mv.
I have been out of the loop for a very long time, but was wondering how things a going with the VFS stuff and if anybody else has picked up on it. The possibilities are endless. One could "share" FTP sites, databases, tape drives, archives (tar, gz, zip) to the masses who use Windows clients while keeping them in the familiar surroundings of the Windows Explorer filemanager.
What are the plans for VFS in SAMBA?
Keep up the good work.
Jeremy:
A: The VFS layer has been integrated into the HEAD branch, it will be a part of Samba 3.0 (along with the MS-DFS work done by Shirish at Veritas). It is *amazingly* cool, and will allow us to duplicate the functionality of Oracle8i (ie. the Windows client direct access via the filesystem into a database) using *any* database for which the POSIX bridge library is written (Informix, Sybase, Interbase, PostgreSQ, MySQL etc.).
This is something for which people will still be finding uses for long after Windows clients are dead and buried :-).
Someone has even written a Perl interface to it. God knows why :-). Man - hackers are *scary* people sometimes :-).
samba and grander networking
schemes
by Matthew Weigel
With MacOS X coming out soon, it's possible that for the first time since OS/2 was popular there will be another consumer PC operating system able to work along with or replace NT, but it's also UNIX that supports storing the information samba uses in network databases (NetInfo, NIS), and it also supports providing access to older Macs through Appletalk.
My understanding of, for instance, Mac Services for Windows NT and UNIX Services for Windows NT is that it provides services from the same databases, just with different protocols.
So if you can see where this is going, is there any work on making samba able to make use of network-wide databases for user authentication, share specification (I know it can already use the autohome map, but more than that!), etc.?
In particular, I'm interested in things like:
Being able to authenticate netatalk, samba, and UNIX users all the same way (i.e., not having smbpasswd, NIS, and /etc/passwd all need to be updated every time a user changes his password or is added)
Being able to specify at the same time what my file server serve up, via netatalk, samba, and NFS (so I don't edit three configuration files every time I add a share, or move a share) Being able to specify from one system what each and every file server serves up, without having to connect to the machine in question and edit the smb.conf by hand (or by web)
Clearly this depends on more than just the samba team, but are there plans to add NIS authentication (i.e., instead of or in addition to smbpasswd), NetInfo authentication, and/or smb.conf NetInfo or NIS databases?
Jeremy:
A: Apple are very interested in shipping Samba with MacOS X (c'mon Sun - you're the last holdout :-). But the authentication problem cannot be solved without the co-operation of Microsoft. Remeber, it is the authentication mechanisms that their clients use that dictate what password hashes can be used on the server side. It is not in Microsoft's interest (being a monopoly on the desktop) to allow authentication integration with any other systems. They came close with the Kerberos 5 in Win2k, but then pulled back of full interoperability by that nasty TGT stunt they pulled (described above).
Of course is the clients are using plaintext authentication then Samba can already use whatever the server requires on the backend (NIS+, Kerberos, PAM, you name it), but this is not a good idea (and all Microsoft clients default to disallowing this by default).
As for alternate config methods - be my guest ! If you add the code, I'll integrate it....... But this is one area where interested parties need to work on the Samba code to add the features they want. I have a lot on my plate at the moment (NT printer driver downloads, ACL code, UNICODE work, back-porting TNG features) that I simply won't get to this myself in what you'd consider a resonable time.
But then again this is Open Source - it's *your* code as much as mine. If you want this stuff - add it! Or persuade one of the Samba vendors (SGI/HP/Veritas/*all* of the Linux vendors etc.) to add it. Vote with your code or your dollars....
Active Directory vs.
LDAP
by wilkinsm
Now that Windows 2000 can use a basterized version of LDAP vs. the undecriptable SAM, does it become any more feasible to have Access Control Lists (ACL) work from Unix? What are your feelings on the "extenstions" that Microsoft made to the LDAP spec - are they insurmountable to decode?
Jeremy:
A: LDAP isn't my area of expertise. Ask the OpenLDAP team. AD doesn't have any effect on Samba providing ACL support one way or another, it's simply a different area of the code. As far as I know Microsoft haven't added any extensions to the LDAP spec - they just use either NTLM and Kerberos authentication in order to control access to the AD server. Sorry for the brief answer but as I said, LDAP isn't my specialist subject.
-------------
Phew ! That was a *lot* of typing. I think I'll relax now by waxing my pencil thin mustache, sipping a mai-tai and dropping by the Beverly Wilshire. I hear there's a Silicon Valley black and white ball going on in Palo Alto, and I need to practice my ooouuutrraaaageeeous acceeentttt. "HHHHHaaalo, my name is Jeremy Allison, your Weendows server eees dead, preeeepare to Samba...." :-) :-).
Cheers,
Jeremy Allison,
Samba Team.
I wonder why people are always confusing Jeremy Allison with Andrew Tridgell?
Andrew is the one in Australia, Jeremy is from England.
In person a lot of people mess them up because of the accents but in print, why does this happen? Not to knock the people who asked Jeremy about 'down under,' I just think it's funny that it happens so often.
Ha, you've found us out.
~ ~^~
My friend, klthekiten and I are actualy starting a company in about a year based almost entirely on this product. Some of the options have been mentioned, voice mail, email, etc... Different attributes would show up in different folders (directories) in the filesystem. There would be a voice mail directory, with checked and unchecked directories.
Also a revision control system much like Clear Case, and document tracking. The perl extentions would make these things easy and fun, and customizable to a companies basic information flow needs. The beauty of the scheme, and hopefully there will be room in the design for this, is that managers can be given a database app to help them handle the manipulation of data also.
So in three different areas of useability, the same information looks like three different things. To the programer, they see API, a manager sees an application and a user sees a very caged and secure filesystem.
This is the stuff.... Sorry if I typed it to fast to be legible. It makes me giddy as a bubble maker...
^~~^~^^~~^~^~^~^^~^^~^~^~~^^^~^^~~^~~~^
I think many people are confusing Jeremy Allison with Andrew Tridgell; the latter _is_ from Australia, and no doubt eats koala and emu twice daily.
Their mailing list is regularly snapshotted. This one is # 17.
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
Charming, witty, can't spell worth a damb... it's people like Jeremy that make the world love the Open Source phenomenon.
One more to add to my Hall of Heroes.
--
Sheesh, evil *and* a jerk. -- Jade
This is one of the reasons that Samba is becoming so popular as an OEM SMB solution, as writing your own SMB server from scratch is *hard*. People look at the published specs, think, well this can't be so bad :-), and start coding. Then they find the way the clients deviate from the spec and they're in a world of pain :-). Many of them end up licensing Microsoft server code, or start using Samba. SGI, Veritas, HP, Cobalt, Whistle (now IBM) and too many others to count are all shipping Samba based products now.
With examples like this of GPL code moving into main stream products we will see corporations being forced to publish software under the GPL.
If you don't want to release your software under the GPL then you have to get into bed with Microsoft to get a license for SAMBA.
Just one more example of Microsoft beaten by "amatures"
If at first you don't succeed, skydiving is not for you.
The Folks down under and the Brits don't like to be confused with each other. A story I like to relate is of an Ausie manager presented with a Brit who has applied for a programming job at a US Company. The HR people are explaining to the Ausie all the goofy stuff you have to fill out and post on the company board when you give a high paying job to an alien. When they are done explaining the problems he says "That's not the problem...I'll tell you what the problem is...he's a f*cking Brit! They're lazy and if I see him slacking off I want him out the door!"
You can get samba pre-packaged for Solaris 8
at the Sun freeware site. The site is actually sponsored by Sun.
Solaris 8 includes Perl & Apache, and the media
kit contains a CD-ROM with lots of their freeware
packages.
Well, as for "Someone has even written a Perl interface to it. God knows why", all packages grow until they have the ability to
a) read mail, and
b) be interfaced to perl!
Good interview. I especially liked the "not trying to be *too* like 'doze" attitude. It's important to interact (at the moment), but you certainly don't want to sacrifice your OS's good points just to pander to the Windows types. Many people have perfectly legitimate reasons for using SMB (over NFS) in a Unix-based environment (NFS does, truly, suck in some situations), and until something better comes along...
In response to the question to Jeremy about work on making Samba authenticate against a network database, I'd like to put in a plug for Ganymede, the GPL'ed metadirectory we've been working on for the last four years.
With Ganymede, all network directory information is held in the Ganymede server's object database. When anyone creates a new user account or changes a password, or whatever, Ganymede writes out the appropriate data into the appropriate network directory services.
Here at ARL, when an admin creates a new user, that user's vital information gets set up in NIS, tacacs, Samba, and on a real live NT PDC via rsh and a Win32 Perl script.
Ganymede is extremely customizable and expandable, and includes password logic designed explicitly to support an NT PDC and Samba server as best as can be done, given the difference in password formats, and the difficulty in keeping things synced without keeping plaintext passwords around on disk.
We're working on preparing a 1.0pre1 release which will change a lot of things in the Ganymede system, including support for XML data import/export, but people interested can take a look right now at http://www.arlut.utexas.edu/gash2.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
VFS sounds interesting.. I hadn't heard of it before. Any chance it'll be ported to NT? I've often thought it would be useful to walk the registry from a command prompt as if it were a filesystem.
I have not personally played with Samba, but I think this interview was very informative. It's good to know that the stable of legitimate alternatives to expensive, proprietary software is growing into niches that even PHB's can appreciate. I got sick of using warez for "educational" purposes...
--
--
E2 IN2 IE?
What is going on? I'm not alone because there are a number of people who consider me to be their expert and ask me to set it up for them. And, not everybody knows me. It's a shame to see all of your good work go to waste in so many instances. Does Microsoft work around their own bugs by trying lots of combinations till something works? Whatever it is, can Samba be made to get to work as effortlessly as does the buggier Microsoft version?
Once Samba is working, I like it a lot better. I suggested once, and they all laughed, but I'll suggest it again: it would be very cool to run Samba from a Windows machine instead of the native SMB. It's a much more powerful and flexible implementation: but, more than a little cranky.
It appears that VFS will allow Samba to mount a database and give transparent usage of that database to a regular Windows/Samba client. I thought it would be cool to brainstorm different things that you could do with this option. It sounds so cool, but I don't know why. Anybody have any ideas?
What could you do with VFS and Samba?
Got HTML? Want LaTeX? Try html2latex