Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
|Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic|
Table Of Contents
|1.||15 Aug 2000 - 16 Aug 2000||(10 posts)||Luke decides to cease active development of TNG|
|2.||2 Sep 2000 - 19 Sep 2000||(5 posts)||Memory leaks in 2.07|
|3.||19 Sep 2000 - 21 Sep 2000||(6 posts)||Samba And ACLs|
|4.||25 Sep 2000 - 26 Sep 2000||(3 posts)||64 Bit Support for Linux|
|5.||21 Sep 2000 - 28 Sep 2000||(58 posts)||Flame War Over Direction Of Development|
Welcome back to KC Samba! This Cousin now follows the new group-authored approach initiated by KC Debian. More authors are needed! If you follow the Samba lists and would like to help out, check out the KC Samba home page.
Mailing List Stats For This Week
We looked at 611 posts in 2333K.
There were 204 different contributors. 96 posted more than once. 0 posted last week too.
The top posters of the week were:
1. Luke decides to cease active development of TNG
15 Aug 2000 - 16 Aug 2000 (10 posts) Subject: "samba development"
Summary By John Quirk
People: Luke Kenneth Casson Leighton, Timothy D. Cole, Gerald Carter, Sander Striker, , John Quirk, Timothy Cole
Here is a copy of Luke Kenneth Casson Leighton's annoucement on the samba list
i started on the nt domains for unix project on the basis of paul ashton's enthusiastic and "this can't be too hard" attitude, back in august 97.
since then, with the encouragement of a number of people over the last three years, and with the discouragement of others, the nt domains protocols are now pretty well understood.
due to that constant discouragement, i no longer find it as enjoyable to work on samba as i did. the enjoyment from discovering new ground is no longer offset by the constant dismissal of the ideas and solutions that i come up with.
those solutions come from a far-sighted understanding of what is involved, and what can be achieved. i never intend to just "solve the problem at hand", i intend to think ahead of what can be achieved both now _and_ in the future.
to that end, the constant dismissal of my development approach, the constant dismissal of coding solutions, the constant dismissal of designs, is just too much.
if anyone can think of a solution to this, please let me know. in the mean-time, i shall find other projects to work on.
to which there where several replies acknowledgling Luke's contribution to Samba Timothy Cole summed up with, " Dude, I'm sorry to hear this. You'll be sorely missed."
Luke's post also spawned a discussion between Gerald Carter and Sander Striker
Gerald started first with ...
As a member of the Samba Team, I want to add a few quick comments and I'll follow up later with more details.
1) The Samba code has not forked. Don't believe any rumors people posted to the mailing lists. Rest easy.
2) There is no dissension among members of the Samba Team. Luke's letter was his own and as all members of the team he is free to move on to other projects as he wishes and to continue to work on Samba under the same development guidelines we all respect.
to which Sander replied, "True. TNG has somehow become, like a few team members said, reference code. This is what causes me, and some others, to jump." [...] " I have to agree and I have to disagree. Those among you who have been following the cvs list the last year might have noticed that there has been a lot of discussion about minor things that are totally blown up. "
Gerald continued his list with:
3) PDC development will continue. While Luke undoubtedly does understand the Windows NT domain control protocol the most, his code provides the documentation that was previously absent for the rest of us.
Luke replied to several posts but this comment seemed to sum up his position, "the decision was not mine to be made, and it was decided a long time ago, it just took me a long time to realise that the people i have been working with were attempting to be polite. "
(ed. [John Quirk] I personally also find sad that some one with Luke's drive and knowledge felt he had to leave the TNG project. But I see from later post to the various list Luke is still about. )
Not long after this post the thread stopped.
2. Memory leaks in 2.07
2 Sep 2000 - 19 Sep 2000 (5 posts) Subject: "RE: Samba 2.0.7 mem leaks, continued"
Summary By John Quirk
People: Andrew Cherry, Neil Hoggarth, Jeremy Allison,
Andrew Cherry reported:
I've done a bit more investigation regarding our memory problems with Samba 2.0.7 under Solaris 2.6. Going through some process accounting logs I've been keeping, it looks pretty clear that there is some memory leakage going on. Some things to note:
Going through the logs, I see the size of ALL smbd processes gradually increasing, which implies that the parent process is the one that is growing. Moreover, the growth happened over the weekend, when not many people were working -- however, I *was* tweaking some of the smb configs and sending HUP signals to the parent smbd process to re-read the smb.conf files.
He posted some output from the memory checking functions, and Neil Hoggarth replied:
One small observation: Based on Andrew's description, it sounds like both affected sites might be able to temporarily work around their problem by running smbd out of inetd, rather than as a standalone daemon, on their production servers? That way you get a fresh smbd process, which only ever parses the config file once, for each new connection.
I use Samba 2.0.7 on Solaris 2.6 without problems, and it so happens that I'm using inetd style, which might explain why I've not seen the memory leak symptoms here.
Andrew said in reply:
That makes sense given the behavior I've been seeing -- the parent smbd daemon process grows over time, and newly spawned children inherit the size.
Our workaround right now is to use 2.0.6, which so far hasn't shown any evidence of leakage.
He went on, "Since the dbx leak checking I did seemed to point to the hash_table_init() function in lib/hash.c, I did some poking around to see what the problem was. At least one problem is that there's a hash_clear() function to free up the memory used by a table, but it never gets referenced anywhere. :-) ." He concluded, "I've gotten around this by running hash_table_clear(&tat_cache) in smbd/filename.c just before running hash_table_init(). But even after doing that, the smbd daemon process still seemes to be gaining about 8K per hour (though an improvement over before)"
Jeremy Allison posted some code and suggested "can you try this patch for 2.0.7 which is what we have added to 2.2.0 to fix the statcache problems. Let me know if it fixes things." Teemu Junnila replied that he had to back out the patch because of profile problems; but this left Jeremy puzzled, and he said "that patch shouldn't have had any effect on profiles. Are you sure it was the patch that caused the problem ? " to this Teemu replied that he'd done some tests and it did seem to be the patch that caused the problem.
There have been no further post on this thread.
3. Samba And ACLs
19 Sep 2000 - 21 Sep 2000 (6 posts) Subject: "2.2 split has taken place."
Summary By Zack Brown
People: Jeremy Allison, Tim Potter, Marc Jacobsen, , David Lee
Jeremy Allison announced:
Ok - now the NT P& is (finally) working reliably, I have branched the HEAD code to get ready for the Samba 2.2.0 alpha releases.
For people wishing to track the alphas the new branch is called (imaginatively enough :-)
I'll probably create a "release" branch at some stage nearer the actual time.
On with the ACL code.....and to *release* !!!!!!
Somone gave a pointer to Extended Attributes And Access Control Lists For Linux and asked what it would take for Samba to support Linux ACLs, or maybe to develop its own ACL API. Tim Potter replied, "I believe the Samba ACL support will be based around POSIX ACLs so it should work with the above project as well as any other operating system that implements POSIX ACLs." David Lee replied that as far as he knew, different OSes had quite different approachs to ACLs, so maybe a Samba API would be the best thing after all. Someone suggested having different functions to handle ACLs on the different OSes, and Marc Jacobsen summed up the situation:
The ACL support submitted to the Samba team that Jeremy is integrating is modular, as Jeremy has stated, and similar to what you have proposed. When submitted there were modules for translating NT ACL data to UNIX filesystem permissions, and for translating NT ACL data to Veritas VxFS 3.3 POSIX ACLs on HPUX.
If POSIX ACLs are exactly the same on all UNIXes (which I doubt) that module could be used basically as is by all UNIXes. If there are differences, people will have to take the HPUX-POSIX ACL module, make the changes to get it to work with their POSIX ACL implementation, and thus create a new module for that UNIX/ACL variant.
All the ACL modules can be used at once, or in any combination, on a per-share basis. Each module is basically just a source file where a few functions must be defined to implement the ACL translations and some checking.
End Of Thread.
4. 64 Bit Support for Linux
25 Sep 2000 - 26 Sep 2000 (3 posts) Subject: "64 bit support"
Summary By John Quirk
People: Andrew Tridgell, Jeremy Allison, John E. Malmberg,
Andrew Tridgell announced on the Samab Technical list:
I've been playing with 64 bit support on Linux i386. As usual the problems are primarily with locking, the glibc headers and code are really bad, making it just about impossible to make 64 bit off_t work.
Anyway, I have got it to work with some gross hacks involving bypassing the C library for fcntl() and I'll be putting that in as a compile time option for those people who really need 64 bit support in Samba on Intel Linux.
Meanwhile, I propose that we drop the explicit calls to open64() and friends in Samba and instead use the LFS way of doing things where compiler flags are used to select a 64 bit interface by default. This seems to be widely supported now and makes the application code much cleaner.
Jeremy, you've dealt with this issue before, what do you think of removing the explicit 64 bit calls and instead use something like the AC_SYS_LARGEFILE autoconf macro (or something equivalent) to set the right compiler flags to get a 64 bit default interface.
We would need some more extensive autoconf tests of the 64 bit interface (particularly with locking) but the advantage would be simpler and more maintainable code.
oh btw, if you use the 64 bit off_t flags with the C library from RedHat 7.0 (glibc 2.1.95) and a 2.4.0test kernel then you get full support for 64 bit files except the locking is _completely_ broken. The effect is that the l_len parameter in struct flock gets seen by the kernel as 0 for all locks (it gets interpreted as a struct flock whereas glibc is giving it a struct flock64), which means all locks/unlocks apply from lock start to EOF. This completely breaks tdb and can easily cause data corruption with Samba. This is going to make for some interesting bug reports in some packages I expect.
To the need for more extensive 'autoconf' tests, Jeremy Allison replied:
That's why I'm loath to change this code so close to a 2.2.0 release - this code was tested carefully on IRIX, HPUX and Solaris and is correct w.r.t several versions of these platforms.
Making a quick hack just because RedHat 7.0 shipped as completely broken stands to break all the carefully tested code on all these other platforms - if we were to do this we'd have to get all the vendors to re-test on their platforms - this seems a little unfair for a linux bug.
Jeremy's response to Tridge's comment on the RedHat libraries was, " Oh god - how did they ship this.......... "
John E. Malmberg suggested avoiding the 'long long' type, which might have seemed useful for working with 64 bit code. He said:
"please consider that the type of "long long" is an extension to the C language, and that it may be represented by the standard as a different type." He went on, "I am not sure if there is a standard type name for a 64 bit long, but if you use a typedef to represent it, instead of coding "long long" in your source, it may add to the number of compilers that can build with 64 bit long support."
5. Flame War Over Direction Of Development
21 Sep 2000 - 28 Sep 2000 (58 posts) Subject: "TNG-stable"
Summary By Zack Brown
People: Luke Kenneth Casson Leighton, Jeremy Allison, Greg Dickie, Gerald Carter, Karl Denninger,
Inadvertantly continuing from Issue #26, Section #1 (15 Aug 2000: Luke decides to cease active development of TNG) , Anatoly Ivanov asked what was up with the TNG branch. TNG-2.6 had some bugs, and he was hesitant to just check out the bleeding edge CVS snapshot. He asked where the 'TNG-STABLE' could be found. Rafal Szczesniak replied that there was no official 'TNG-STABLE', although 2.5 was known to be less problematical. This wasn't such good news for Anatoly, who preferred to upgrade rather than downgrade. Gerald Carter added that a couple people had done some work on the TNG branch, but that it was basically stagnant for the moment. But Luke Kenneth Casson Leighton replied, "it's not stagnant: the project is terminated." Anatoly didn't know what to make of this, and Luke elaborated, "due to what i consider to be incredible arrogance on the part of the primary samba developers, whose opinion of TNG and the people i have been encouraging to help with TNG's development - including yourself, if you use TNG - is, by association, extremely low, you will have to ask that question of them, not of me." Jeremy Allison criticized, "Deciding not to work on Samba is your choice, and everyone is fine with that. What is not good is your continuous criticism of the people who *are* still working on Samba and attempting to forward the project as fast as possible." He said Luke shouldn't say anything at all if he didn't have anything nice to say, but Greg Dickie replied, "I'm sorry Jeremy, I don't agree. Should I not post to the samba mailing list anymore because of that?" Jeremy replied that that wasn't what he'd meant, and that "Disagreements are always welcome, I'm just trying to keep this on a higher level and cut down on the personal comments." Greg replied, "okayyy fine. but your mother wears army boots ;-)"
Others also started arguing back and forth on the issue, until Gerald Carter piped up, with his take on the history behind the situation:
Apparently you have have either not been aware or have ignored the background with this and therefore I will boil it down for you.
I promised myself I was not going to be drug back into the again, but here goes.
Luke, please listen to what I have to say. You are a very good friend, but I am going to state the obvious. This is my personal official stance.
Luke decided he could not work within the boundaries of the main samba code branch. Therefore he was offered a development branch for the sole purpose of continuing his work and that would would be evaluated (as everyone's is) before bringing it back into the HEAD branch code.
However, Luke admits to basically forking the code, starting a community, and the dropping it. It you are upset with anyone, talk to Luke. IMO, it was irresponsible to fork the code and the drop it. That's what Luke did. period. Now no one is able to support the community he developed. Is that our fault? No. It was Luke's decision.
But perhaps you think I'm being to harsh? Let's look at Luke's position on the pam_ntdom code he released as well. Or maybe other branches that resulted in the same thing
Now to the question of whether or not Samba will ever be able to act as a PDC, the answer is yes. We are working on it. If you would like to help, please jump in. We're really not a proud bunch and will gladly accept help. Really. :-)
The reason that Luke's comments are innapropriate is that you are only seeing the person who is yelling the loudest.
Karl Denninger pointed out that Luke didn't have to be "offered" a branch, since the code was publically CVSable. Karl likewise didn't see much merit to any of the other characterizations of Luke's actions. But he said the Samba developers could expect people to carp and complain when their requests for a PDC timeline were ignored. And he concluded, "I, like Luke, have both the right to an opinion and to express it."
Jeremy replied, "PDC will ship when the code is ready and working. That's the only valid timeline possible to commit to." There was a lot of back-and-forth, with various tempers flaring up, and various other folks telling everyone else that the discussion was pointless and they should get back to coding.
Eventually it died down.
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.