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.

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.

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 :-).

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.

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 libsmb.so 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 libsamba.so, 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.so)

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?

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.

-- 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.

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 libsmb.so 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)

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 http://lists.samba.org/mailman/listinfo/samba-technical 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 samba-technical-request@lists.samba.org It says that I don't exist in list.

Now, could someone tell me what to do?

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:

http://lists.samba.org/mailman/roster/samba-technical here I found okuyama at trl.ibm.co.jp and okuyamak at dd.iij4u.or.jp click on "okuyama at trl.ibm.co.jp" and try to unsubscribe.

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+

HPUX

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%.

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.

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.

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?

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.

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.

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?

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.