Samba Traffic #34 For 3 Dec 2000

Editor: Zack Brown

By John Quirk  and  Zack Brown

Samba Homepage ( | Samba List Archives ( | "Using Samba" ( | Samba Tips ( | A Samba Doc Page ( | Samba Meta-FAQ ( | Samba For IRIX FAQ (

Table Of Contents


Want to help write KC Samba? See the KC Authorship page (../author.html) , the KC Samba homepage (index.html) , and the Thread Summary FAQ (../summaryfaq.html) . Send any questions to the KCDevel mailing list. (

Mailing List Stats For This Week

We looked at 313 posts in 1517K.

There were 117 different contributors. 50 posted more than once. 0 posted last week too.

The top posters of the week were:

1. A Better Way To Release Patches?

11 Nov 2000 - 12 Nov 2000 (8 posts) Archive Link: " PATCHES: Release Suggestion"

Summary By John Quirk

People: Joe DoranKenichi OkuyamaJeremy AllisonAndrew Tridgell

Joe Doran offered a sugestion on how to make patches readly avaiable:

My suggestion is to make the patch testing public. A coder could classify his patch bug or system fix, on what system, version, functionality etc. Joe Public can use this patch if badly needed and provide feed back on web page. Did it work?, Did it break anything? How badly did they need the patch 1to5. This info could then be used to compile a top ten patch/bug requests to be considered. These could then be scrutinized by the team for integration.

Kenichi Okuyama replied:

What you're saying is to create extreame number of branches. This itself is possible. We well have many branches that work. But how do we put them togather? Who manages differences between each branches? And how will it be merged? I'm sure that speed of having newer patch is always faster than merging, especially when Samba is at quality right now.

So I think what we need is three things.

1) more who can directly make change against cvs.

2) test groups

3) people who can manage 1 and 2.

Kenichi went on to expand these points Jeremy Allison replied:

Well we're giving more people write access to the CVS trees, we just added someone from HP last week.


Yes I know you feel this way. I'm not disagreeing that some of the code needs cleaning up, it's just that I disagree about "stoping new development" whilst we do this. We don't have the luxury of ignoring new features, not now we're needing to integrate better with Win2k. The pressure for new features was what the TNG fork was about.

Now if you want to do this simplification in HEAD, not 2.2, then I'm all for it. In fact I need to send you some email about some of the suggestions you made earlier this week, as they point out perfectly some design flaws that Andrew and I talked about a year or so ago now, but were not able to get time to address. I'm hoping you can help us do that :-).

Kenichi Okuyama went on to presented his views on the code base of SAMBA and the need to pause and fix these issues. Kenichi has expressed these views before . Andrew Tridgell replied to the example issuse Kenichi raised and went on to say:

We are certainly happy to consider very large changes, but large changes have to be very well thought out, then prototyped and shown to actually be worthwhile. Right now Jeremy is trying to get 2.2 ready and so he is aiming for small changes. I'm interested in hearing about large proposed changes for 3.0 and beyond, but they have to be well thought out.

You're comments on us having a bad structure that we are standing on are to a large degree correct. The problem we face is that we want to make these big structural changes smoothly, so that we can keep doing stable releases from a code base that is fairly close to our development code base. That doesn't preclude large changes (witness the wholesale change to an internal database api in Samba 2.2) but it does mean we have to think carefully about big changes. Big changes imply a long time between stable releases, and that is something we want to minimise if we can.

This ended the thread

2. Creating a Libary of SMB functions

16 Nov 2000 - 17 Nov 2000 (6 posts) Archive Link: "SMB libray suitable for use in non-Samba projects"

Summary By John Quirk

People: Matt PetersonJeremy Allison

Matt Peterson called for comments on the following:

Can anyone give me some information / background / anything on the use of Samba code from a non-Samba application? I was expecting to find something as simple as a smb.h and that could be used like any other utility library... I've found the library, now I'm looking for a header file (includes.h won't do the trick - it includes everything in the Samba universe not just what would be needed to use libsmb). I believe I can make a header file that would work with libsmb code, but before I spend time doing it, I though I'd see if anyone has a simpler solution to the problem.

It looks like several attempts have been made to write a client samba library, but always as a project external to Samba. Rather than progressing along with Samba, most of these projects have died when the original maintainer lost interest. No one wants to write to an unmaintained library. The only way to get a gathering of developers large enough to ensure continued maintenance of the library would be to make it part of Samba.

What we would be looking to contribute would be a, a samba.h and online html documentation. Caldera (and other distros) could build 3 rpms from the samba tarball:

samba-x.x.x.rpm (current Samba stuff)

libsamba-x.x.x.rpm (

libsamba-devel-x.x.x (samba.h and developer docs)

Assuming that I have not missed a viable samba library solution is there interest in an offer from Caldera to work on a libsamba and what are the chances that the library would be an "official" Samba build target?

Jeremy Allison replied:

The code in libsmb is what you need to look at. It's nearly there as a library - the problem is it depends on other parts of Samba.

If you can give the changes to make it a build target I'd be happy to integrate them.

Matt agreed with Jeremy assesment and went on:

-- most obvious is the absence of an externally useable header file. The changes we will submit, as previously mentioned, can be summarized as a new Samba build target "libsamba". We expect that the majority of the changes will be to the Makefiles with code changes limited to the header files.

He went to say they would start work this next week

Jeremy Allison asked the code be targeted at the HEAD branch and he would look at a merge into 2.2

Alain Barbet was pleased at this because it is what he was looking for to create a Perl module for smb functions.

See (

3. automake And libtool For Samba

20 Nov 2000 - 21 Nov 2000 (13 posts) Archive Link: "Automake and libtool for Samba"

Summary By Zack Brown

People: Matt PetersonJeremy AllisonJohn E. MalmbergAlexandre Oliva

On samba-technical, Matt Peterson of Caldera asked why Samba did not use libtool and automake to ease compilation. He added, "It has become very obvious that the patch we are making for Samba header and make files will need to use automake (for convenience) and libtool (to maintain portability)." [...] "If there are no objections, our patch will also include full a automake/autoconf and libtool build system for all Samba binaries." Jeremy Allison explained, "We looked at moving to libtool and automake, but we run on many more platforms than these are available for." He added that for the HEAD tree, it would probably be OK to add the patch, although for 2.2 there would most likely be problems. Matt replied:

Understood. We're currently working off of HEAD and will continue with plans to change the makes to use automake and libtool. Hopefully, the new clean makes (with automake and libtool) will be attractive enough that it would be interesting to users and developers on the 2.2 branch. It will be fairly easy to apply the makefile patches as we build RPMS so our work will not be lost if the Samba Team feels like it would not be a good idea to merge the changes into 2.2.

We've tentatively scheduled development to submitting the following 4 patches:

  1. makefile changes to use automake and autoconf (Next week)
  2. header file changes to separate out what is needed for an externally usable "smb.h" with out breaking builds of existing /bin binaries (first or second week of December)
  3. makefile changes to build as well as possibly link changes so that appropriate Samba /bin binaries also use the external libslp (second week of December)
  4. HTML documentation (second week of December)

Elsewhere, John E. Malmberg spoke out against autoconf, saying, "autoconf may be cross-UNIX but is definitely not cross platform. It is dependent on a UNIX like shell and usually a whole suite of UNIX specific tools. These tools are either not available on all platforms, or are of too ancient of a revision to be of use on some platforms." [...] "What is needed for a cross platform autoconf would be something that is more table driven and not script driven, so that platform specific configure scripts could be written to execute the tests indicated on the tables and compare the results." While close by, Alexandre Oliva spoke in favor of libtool, saying, "The main problem I've seen in my experience with adopters of libtool is when they want to do non-portable things, and complain that the portability tools get in their way. Nobody said portability was easy, but development versions of libtool have made it easier for maintainers to bend portability rules and pass whatever system-specific flags they want to the compiler and linker."

No decisive conclusion came out of the discussion.

4. Large File Support In Samba And Linux

20 Nov 2000 (5 posts) Archive Link: "Large Files and Samba on Linux"

Summary By Zack Brown

People: Anders KnudsenJeremy Allison

On samba-technical, Anders Knudsen about large file support under Samba, under Linux. It seemed that Samba 2.0.7 did have LFS support, but "when compiling on linux, the "configure" script does not have provisions for LFS on linux platform, in that it "disables" LFS for a uname of "linux"." He added that he knew glibc 2.1 had LFS support, and asked what else he'd have to do to get it working.. Jeremy Allison explained that the 2.2 kernel didn't have LFS support, but that when the 2.4 kernel came out, it would have LFS support. Later, Anders answered his own question by giving a pointer to the LFS Support For Linux 2.2 ( page. And Jeremy added that, if Anders was able to patch the 2.2 kernel properly, he should also have no trouble removing the LFS "fail-on-Linux" from the Samba build scripts.

5. Stop I want to get off

21 Nov 2000 - 22 Nov 2000 (3 posts) Archive Link: "How to Unsubscribe"

Summary By John Quirk

People: Kenichi OkuyamaSimo Sorce

When you are regularly reading the lists you see posts with the words UNSUBCRIBE in them often from users who have never posted before then Kenichi Okuyama posted:

Could someone please tell me the way to unsbuscribe this ML? I want to move myself from address of my office to address of where I can access from home.

List-Unsubscribe says that I should access to ( and so, I did. Now Webpage tells me that I no longer exists in their list, but still, Mail is coming to this address.

Then I request for unsubscribe using mail to It says that I don't exist in list.

Now, could someone tell me what to do?

Simo Sorce replied with:

Are you sure the address you are using is the one you subscribed with?

Maybe you used an alias or another mailbox that is forwarding to you?

See user lists on the same server, try: ( here I found okuyama at and okuyamak at click on "okuyama at" and try to unsubscribe.

This seemed to have fixed Kenichi problems.

6. Samba 2.2.0alpha1 released

22 Nov 2000 - 27 Nov 2000 (32 posts) Archive Link: "Samba 2.2.0alpha1 snapshot released"

Summary By John Quirk

People: Jeremy AllisonAlexander LobodzinskiRichard BollingerJason HaarJohn QuirkTim PotterGerald Carter

Jeremy Allison posted this annoucement on the lists:

I have just released the second alpha snapshot of what will become Samba 2.2.0.

It's available from the usual ftp sites, in the alpha directory as :

"ftp mirror":/pub/samba/alpha/samba-2.2.0-alpha1.tar.gz (

If people could test this snapshot out and provide feedback about what is broken (probably lots at the moment :-) and let the lists know that would help.

The Team will be monitoring the feedback and this will help for the next alpha.

Please note that the documentation is not currently up to date, and the POSIX ACL mapping feature is still missing, but most of the other improvements are all there, and this code has been running under memory overrun/leak detectors for weeks now without problems.

Having said that - *please* don't use this on a production system :-) :-).

I believe that most of the patches people requested have been added to this release, and that the NT point and print code is much more robust than alpha0. Jean-Francois patches for Win2K PDC support have also been included.

Please kick the tires and let us know what you think ! The release notes follow :

WHATS NEW IN Samba 2.2.0alpha1

This is the second alpha release of the new 2.2.0 codebase for Samba. This version must not be run in production.

This code will almost certainly have some bugs and is intended to help the Samba Team prepare an official 2.2.0 release.

The documentation in this alpha snapshot is not up to date, there are many new parameters since 2.0.7. This will be corrected in a later alpha release.

Several significant bugs have been fixed between alpha0 and alpha1, these include :

Fix for level II oplock bug.

Support for detecting version 2/3 printer drivers (from HP).

Samba profiling support (from SGI).

Winbind integration fixes.

Preliminary Win2K PDC support in compatibility mode for Win2K clients (from JF).

VFS interface updates.

Failover finding of BDC's now works again.

lpq race condition fixes.

utmp fixes.

SWAT username detection fix.

Bugfix for WinNT and Win2K point and print feature.

The upcoming 2.2.0 Samba release will include the following new features:

Integration with the winbind daemon that provides a single sign on facility for UNIX servers in Windows NT4/2000 networks driven by a Windows NT4/2000 PDC.

Support for native Windows NT4/2000 printing RPCs. This includes support for automatic printer driver download. This functionality should be complete in alpha1.

Rewritten internal locking semantics for more robustness. This alpha supports full 64 bit locking semantics on all (even 32 bit) platforms. SMB locks are mapped onto POSIX locks (32 bit or 64 bit) as the underlying system allows.

Conversion of various internal flat data structures to use database records for increased performance and flexibility.

Support for acting as a MS-DFS server

Compile time option for enabling a VFS layer

Support for server supported Access Control Lists (ACLs). This support will require a specific pluggable backend to be written for each filesystem ACL implementation to be supported. The stable 2.2.0 release should contain support for the following filesystems:

Solaris 2.6+


SGI Irix

Linux Kernel 2.2 with German ACL patch

Currently in this alpha snapshot (alpha1) this feature is not enabled - the VFS layer has been modified to allow it, but the code is still under development and should be in a later alpha snapshot.

Other platforms will be supported as resources are available to test and implement the encessary modules. If you are interested in writing the support for a particular ACL filesystem, please join the samba-technical mailing list and coordinate your efforts.

Support for collection of profile information. A shared memory area has been created which contains counters for the number of calls to and the amount of time spent in various system calls and smb transactions. See the file profile.h for a complete listing of the information collected. Sample code for a samba pmda (collection agent for Performance Co-Pilot) has been included in the pcp directory.

To enable the profile data collection code in samba, you must compile samba with profile support (run configure with the --with-profile option). On startup, collection of data is disabled. To begin collecting data use the smbcontrol program to turn on profiling (see the smbcontrol man page). Profile information collection can be enabled for all smbd processes or one or more selected processes. The profiling data collected is the aggragate for all processes that have profiling enabled.

With samba compiled for profile data collection, you may see a very slight degradation in performance even with profiling collection turned off. On initial tests with NetBench on an SGI Origin 200 server, this degradation was not measureable with profile collection off compared to no profile collection compiled into samba.

With count profile collection enabled on all clients, the degradation was less than 2%. With full profile collection enabled on all clients, the degradation was about 8.5%.

Gerald Carter commented on the size of gzipped file and noted that the a bzipped2 was about 1meg smaller

(ed. [John Quirk] Gerald went on to say maybe they should offer users a choice, This has been done on the SAMBA web pages)

Alexander Lobodzinski found some errors in the compile for a DEC Unix 4.0x and fixed it with the following:

cc: Error: ../rpc_server/srv_samr.c, line 806: Invalid statement. (badstmt)




adding a semicolon after the "done:" label above fixed that. If you are interested in compiler warnings about uninitialized variables and stuff just let me know.

Herbert Lewis posted the IRIX 6.x inst packages to Samba Site

Jason Haar run into a problem with his 2.2 not talking to his windows PDC. This generated much dicussions he even sent in a level 9 debug report. Finally Richard Bollinger posted:

You might want to try re-joining the NT domain. Although I can't explain it, I found the same behaviour when attempting to test 2.2.0-alpha0 on a machine which had been running 2.0.7 with DOMAIN authentication. I think the smbpassword authentication is just a fall-back in case the other method fails. It's probably possible to compile or configure that method out of consideration.

This fixed Jason problem he also noted:

I couldn't find anything about rejoining the domain being required documented anywhere, so perhaps that fact should be emphasized so that others (besides me) don't make the same mistake?

Jeremy Allison replied:

Oh that sucks. I need to fix that. The intent is that it will read the DOMAIN.mac file and use it in preference if it exists.

Tim Potter noted that 2.2 does use the .MAC files any more and that it would not be too hard to write a conversion program. To which Jeremy Allison replied:

That code (the auto-conversion from flat file) was actually *in* the 2.2 codebase, just not being called :-(.

I just fixed this and checked the change in so it shouldn't happen again.

The thread ended

7. Replacing Pathworks 4.3 With Samba

25 Nov 2000 (2 posts) Archive Link: "Using Samba to replace PW 4.3"

Summary By Zack Brown

People: Barry Treahy, Jr.John E. Malmberg

On samba-VMS, Barry Treahy, Jr. asked:

I have a couple really old systems (one is running OS/2 2.0 and three that are DOS with maybe W31). I could do something about the DOS pieces of junk, but the OS/2 system, my hands are tied because the company is gone and OS/2 was the last platform they supported. The OS/2 is a configuration nightmare and I really do not want to screw with it, its pretty fragile.

Can anyone tell me if I can get these working with Samba, I've lost access to the old PW systems. I realize that there would not be a virtual disks, that's fine. I need the basic printer and file sharing that Samba brings to the table, hopefully without messing a lot with each systems basic configuration. Any pointers?

John E. Malmberg explained:

Pathworks 5.x and higher uses NetBEUI and Netbios over TCP/IP. As long as the server is licensed in a concurrent licensing mode, they can be connected to from the standard DOS networking software from Microsoft. This should include OS/2 2.0.

SAMBA only implements Netbios over TCP/IP. The older DOS and OS/2 systems may not have enough memory or other resources to support TCP/IP.

The client licenses for Pathworks V6 and higher can be set to either per server mode or per client mode.

Per server mode allows a fixed number of clients to access a single server. Per server mode does not require any software on the client computer. This makes it useful for older clients such as what you have.

Per client mode allows a single client per license to access an unlimited number of Pathworks server. Per client mode requires that a client has a special license requester agent running. It also means that only client operating systems that have license requestor software available can use Per Client mode.

If you can run NetBios over TCP/IP on these old systems, you can use either Pathworks or SAMBA.

If you need NetBEUI, then you must use Pathworks V5 or higher. Pathworks V6 is far easier to use than V5, and the licensing options more flexable.

8. Samba PDC Under Red Hat

27 Nov 2000 - 28 Nov 2000 (5 posts) Archive Link: "Redhat 7.0 and Samba 2.2"

Summary By Zack Brown

People: Phillip C RobertsMichael GlaucheDavid BannonAnders C. Thorsen

On samba-ntdom, Phillip C Roberts was very excited to make his first attempt at a Samba PDC. He asked, "Is Redhat 7.0 a workable base or is 6.2 a better option?" Anders C. Thorsen recommended 6.2, though Michael Glauche felt that 7.0 should also be fine, and recommended, "If you run into trouble when compiling use: export CC=kgcc" . David Bannon was also skeptical of 7.0, saying, "I believe that RedHat jumped the gun a bit with gcc on 7.0 and included a 'alpha release' that does a few things differently. See the gcc site for details. I would stick to 6.2 and stick all the (appropriate) patches on including the kernel one. The standard 6.2 kernel has some security bug and further does not allow the current ssh to work." Jon Doyle of Suse took the opportunity to say that Suse was good.







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.