Samba (re Monday's meeting)
One thing I forgot to mention when Greig asked me to talk about Samba in general, is that I am completely and utterly sick of samba playing catchup. Samba will always chase behind Microsoft's implementation. If Samba ever fully catches up and can play the AD game perfectly, and has zero problems, MS only has to move to another structure. It's a futile game to play at. Current Samba implementations fall foul of many of the problems Greig talked about. It's almost the same, but it is subtly different in many ways, and this causes problems. There aren't really any decent unified configuration systems yet, so running an LDAP backed samba system which *works* is not a trivial task to set up. The entire domain model of samba is tedious to work with unless you're running MS gear. That said, it's the only option right now. There are ways around it which have been implemented on large university networks, however support is tedious. I'm looking at using a custom GINA (the login part of windows) which will auth via Kerberos or LDAP, and having an AFS based network (Andrew File System), a distributed file system). It's not all doom and gloom, I guess. I get fairly frustrated with the attitude that seems to dominate overall major linux development which says that we have to mimic Windows. GNOME and KDE have done this, Samba is perpetually doing this. If Linux actually *is* better than Windows, why do we have to mimic them? We could at least be mimicing Mac OS X. I'd like that. Daniel
On Wednesday 30 June 2004 09:03, Daniel Lawson wrote:
One thing I forgot to mention when Greig asked me to talk about Samba in general, is that I am completely and utterly sick of samba playing catchup. Samba will always chase behind Microsoft's implementation. If Samba ever fully catches up and can play the AD game perfectly, and has zero problems, MS only has to move to another structure. It's a futile game to play at. ...
Thank you for mentioning this. Some of us don't learn, witness Mono. Cheers, Sid.
On Wednesday 30 June 2004 09:03, Daniel Lawson wrote:
One thing I forgot to mention when Greig asked me to talk about Samba in general, is that I am completely and utterly sick of samba playing catchup. Samba will always chase behind Microsoft's implementation. If Samba ever fully catches up and can play the AD game perfectly, and has zero problems, MS only has to move to another structure. It's a futile game to play at. ...
Thank you for mentioning this. Some of us don't learn, witness Mono.
Mono sounds like an excellent idea, and a better option for "write once, publish on Windows and Linux" which could well mean we can migrate software away from depending on a Windows platform. It was always Microsoft's "stated goal" to let other people build .NET VM's, and the specs are published. I realise that the major complaint is that Microsoft could take it all away at any time, but to someone who hasn't looked in detail, it sounds that "C# is more open than Java". I believe that what they've implemented of the Mono class libraries are from the published spec; what Samba have implemented is largely reverse engineered. Craig
Mono sounds like an excellent idea, and a better option for "write once, publish on Windows and Linux" which could well mean we can migrate software away from depending on a Windows platform.
You have a problem: what software would you like to move from Windows to non-Windows that is currently written in C#. On the other hand, Java is a mature platform supported on most operating systems.
It was always Microsoft's "stated goal" to let other people build .NET VM's, and the specs are published.
Same for Sun and the JVM. There is no shortage of high-quality JVMs.
I realise that the major complaint is that Microsoft could take it all away at any time, but to someone who hasn't looked in detail, it sounds that "C# is more open than Java".
They don't have to take it all away, they just have to add proprietory extensions. What's Miguel gonna do then? Reverse engineer? I comment on CIFS below. How is "C# more open than Java"?
I believe that what they've implemented of the Mono class libraries are from the published spec; what Samba have implemented is largely reverse engineered.
IIRC, MS published the CIFS and then added their propriety extensions. Catchup time. They will do the same with .NET. And I don't blame them -- their reason for being is to make money. So if they succeed in making Java software less pervasive, good on them. By the way, can we export Word documents to XML yet? More than 5 years since MS said that feature would be available. To MS: thanks for coming, but I prefer my freedoms. To Craig: I think you've bought it buddy :-) Cheers, Sid.
* Daniel Lawson <daniel(a)meta.net.nz> [2004-06-30 06:46]:
I get fairly frustrated with the attitude that seems to dominate overall major linux development which says that we have to mimic Windows. GNOME and KDE have done this, Samba is perpetually doing this.
I don't think you can compare these at all: KDE and GNOME are willingly doing so; noone is forcing them. Samba is the same thing as WINE: intended to shoehorn Linux into places where Windows rules. Yes, I find it frustrating that everyone is just aping the Microsoft interface. Aping Apple would certainly be better -- but it's not going to be easy, considering how viciously Apple are guarding their assets (just try to find an accurate Aqua theme for one of the desktops..). Regards, -- Aristotle "If you can't laugh at yourself, you don't take life seriously enough."
* Daniel Lawson <daniel(a)meta.net.nz> [2004-06-30 06:46]:
I get fairly frustrated with the attitude that seems to dominate overall major linux development which says that we have to mimic Windows. GNOME and KDE have done this, Samba is perpetually doing this.
I don't think you can compare these at all: KDE and GNOME are willingly doing so; noone is forcing them.
That makes it *worse* in my opinion.
Samba is the same thing as WINE: intended to shoehorn Linux into places where Windows rules.
And for situations where you want to run a heterogenous network, that's fine and dandy. I don't consider the client OS to count however. There is no real reason we shouldn't have windows boxes authing via NIS or LDAP or whatever we want, and whatever distributed file system running to serve them network content. Why is the standard approach to this "Run samba, put up with the inconsistencies, and just hope the samba dev team can play catchup quicker than their opposition can cheat them". Don't get me wrong here, I think the samba team are doing a great job. I just wish they were directing their efforts on something *new* for linux.
Yes, I find it frustrating that everyone is just aping the Microsoft interface. Aping Apple would certainly be better -- but it's not going to be easy, considering how viciously Apple are guarding their assets (just try to find an accurate Aqua theme for one of the desktops..).
Yeah well. I'm saving for a G5. Or a powerbook. Not sure which. Daniel
* Daniel Lawson <daniel(a)meta.net.nz> [2004-06-30 22:27]:
I don't think you can compare these at all: KDE and GNOME are willingly doing so; noone is forcing them.
That makes it *worse* in my opinion.
Well, that was my point, too.
Samba is the same thing as WINE: intended to shoehorn Linux into places where Windows rules.
And for situations where you want to run a heterogenous network, that's fine and dandy. I don't consider the client OS to count however. There is no real reason we shouldn't have windows boxes authing via NIS or LDAP or whatever we want, and whatever distributed file system running to serve them network content. Why is the standard approach to this "Run samba, put up with the inconsistencies, and just hope the samba dev team can play catchup quicker than their opposition can cheat them".
In the beginning, there was a large Windows network, with many clients and several servers. Into this world, the fresh new Linux server was born. What would you do -- shoehorn a new technology onto 100 machines so they can talk to the new kid, or shoehorn the client technology onto the new kid so it can talk to the 100 old machines? Ideally, you'd deploy a double file serving protocol setup, with the clients being replaced by ones talking the new protocol as they get phased out. Maybe once you have 60% of the clients talking the new protocol, you will think about an interoperability solution to let the old clients talk the new protocol also. Or maybe you'll wait until the penetration is more like 80% and you can afford to sweep out the rest of the old clients at once. Another problem: I've never heard of any reasonably usable networked FS for Windows besides SMB/CIFS. Do you know more than me? If you do, can you name a few large sites that have been successfully running it so my (ficticious) PHB would feel safe to give the go-ahead to implement it? Regards, -- Aristotle "If you can't laugh at yourself, you don't take life seriously enough."
Another problem: I've never heard of any reasonably usable networked FS for Windows besides SMB/CIFS. Do you know more than me? If you do, can you name a few large sites that have been successfully running it so my (ficticious) PHB would feel safe to give the go-ahead to implement it?
American Universities run Kerberos, LDAP and AFS for their authentication/user directory/file storage. It supports load balancing, high availability, ACL's and multiple other buzzwords. There are clients for various OS's including Windows. It's faster than your average network file system, because it uses the local file system as a disk cache. (On the flipside, I've personally never managed to get it working, but you don't need to tell the PHB that :)
* Perry Lorier <perry(a)coders.net> [2004-06-30 23:27]:
American Universities run Kerberos, LDAP and AFS for their authentication/user directory/file storage.
This does seem interesting: http://www.openafs.org/frameless/success.html
(On the flipside, I've personally never managed to get it working, but you don't need to tell the PHB that :)
That was my impression about AFS; some of it hearsay, of which I wasn't sure how much of it is true. However, I do know that even though my own local Uni uses AFS for the file servers in the data centre, I've yet to encounter a single stray Windows machine that's hooked up to the AFS, while a lot of the Unix machines have been. Admittedly, I don't know what things look like in the computer pools. Maybe this is an area that needs more advocacy (and possibly effort to make it work smoother?). Regards, -- Aristotle "If you can't laugh at yourself, you don't take life seriously enough."
(On the flipside, I've personally never managed to get it working, but you don't need to tell the PHB that :)
That was my impression about AFS; some of it hearsay, of which I wasn't sure how much of it is true. However, I do know that even
I've had AFS working off a Linux server to a Linux desktop and a Windows desktop. One problem I hit was that there seemed to be a fairly major bug in the kernel modules for 2.4.21, which was the kernel in use at the time I was playing. I think I ended up sticking with a 2.4.18 kernel. I've not had the time or the machines to try further. I notice there are AFS modules in the 2.6 kernel tree - I plan on looking at this in the future.
though my own local Uni uses AFS for the file servers in the data centre, I've yet to encounter a single stray Windows machine that's hooked up to the AFS, while a lot of the Unix machines have been. Admittedly, I don't know what things look like in the computer pools.
The problem here is probably the lack of SSO. You log into your windows domain, then you'll need to log in *again* to your AFS. Unless a Windows login can return a kerberos ticket which you can use for AFS, I'm not sure. The solution to this is to have a custom GINA which does the login auth against your AFS for you. I've had the windows client working just fine tho (log into windows, then log into AFS), it works well.
Maybe this is an area that needs more advocacy (and possibly effort to make it work smoother?).
Definitely needs work to make it smoother :). It's a year or more since I've played with this, I need to find the time to look into it again. Daniel
I notice there are AFS modules in the 2.6 kernel tree - I plan on looking at this in the future.
AFS is in 2.6, however patching your kernel apparently still works better. :/
The problem here is probably the lack of SSO. You log into your windows domain, then you'll need to log in *again* to your AFS. Unless a Windows login can return a kerberos ticket which you can use for AFS, I'm not sure. The solution to this is to have a custom GINA which does the login auth against your AFS for you. I've had the windows client working just fine tho (log into windows, then log into AFS), it works well.
From the URL Aristotle posted: We're still working on completing our integration work with Windows 2000 and XP -- we've established cross-realm trust between our nascent Active Directory and our existing K5 realm, and we've been working on trying to arrange to have AFS tokens derived locally from the K5 tickets granted to users on our Windows systems at login time. So it sounds at least possible.
Maybe this is an area that needs more advocacy (and possibly effort to make it work smoother?).
Definitely needs work to make it smoother :). It's a year or more since I've played with this, I need to find the time to look into it again.
Yeah, perhaps we should start an AFS trend in the lug and get some wiki pages sorted out. :)
From the URL Aristotle posted:
We're still working on completing our integration work with Windows 2000 and XP -- we've established cross-realm trust between our nascent Active Directory and our existing K5 realm, and we've been working on trying to arrange to have AFS tokens derived locally from the K5 tickets granted to users on our Windows systems at login time.
So it sounds at least possible.
Well, they say they are trying to get it working, which means they've thought of it too. They don't say it's possible :P
Definitely needs work to make it smoother :). It's a year or more since I've played with this, I need to find the time to look into it again.
Yeah, perhaps we should start an AFS trend in the lug and get some wiki pages sorted out. :)
Nah, I'm over trends. Trends are so last-century. Daniel
In the beginning, there was a large Windows network, with many clients and several servers. Into this world, the fresh new Linux
<snip> I know why it's here now. I don't see why we perpetuate it.
Another problem: I've never heard of any reasonably usable networked FS for Windows besides SMB/CIFS. Do you know more than me? If you do, can you name a few large sites that have been successfully running it so my (ficticious) PHB would feel safe to give the go-ahead to implement it?
NFS ;). Perry mentioned AFS, and that's the one I'm thinking of for the most part. It's a well designed distributed file system, and it works well. It's running on several large university networks - which in itself is probably sufficient to "prove" that it works in large environments, as I suspect a typical university network is larger that most corporate offices.
* Daniel Lawson <daniel(a)meta.net.nz> [2004-07-01 00:46]:
In the beginning, there was a large Windows network, with many clients and several servers. Into this world, the fresh new Linux
<snip>
I know why it's here now. I don't see why we perpetuate it.
Because this "here now" is not here and not now for a lot of people -- when it eventually happens, they will have the same needs. To me, Samba, along with its continuing existence, accompanied by continuing catching up, is inevitable. I'm not saying I like this; but I don't see how it could be avoided.
Another problem: I've never heard of any reasonably usable networked FS for Windows besides SMB/CIFS.
NFS ;).
The Nightmare File System? :-)
Perry mentioned AFS,
Yeah, and see ensuing discussion. I guess this is an area for interested people to pour in work. Regards, -- Aristotle "If you can't laugh at yourself, you don't take life seriously enough."
participants (5)
-
A. Pagaltzis -
Craig Box -
Daniel Lawson -
Perry Lorier -
s swami