I have just released the third 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-alpha2.tar.gz If people could test this snapshot out and provide feedback about what is broken and let the lists know that would help. I know about the problem acting as a PDC for Win2k clients - this is being worked on (by JF and myself). The Team will be monitoring the feedback and this will help for the next alpha. The POSIX ACL mapping feature has been implemented on Linux only at the moment and many bugs in the point and print code have been fixed. The documentation is not currently up to date, but 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 (yet - although it's closer now.... :-). I know there are still some patches missing, I will try and get to these as soon as I return from the Linuxworld conferences and the Brussels Open Source conference (Feb 8th). Please kick the tires again and let us know what you think ! The release notes follow :

=====================================================================

WHATS NEW IN Samba 2.2.0alpha2

This is the third 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 and some defaults have changed. This will be corrected in a later alpha release. A known problem is this version of Samba will not act as a PDC for Win2k clients (although it works as a member server in a Win2k hosted domain). This is being actively worked on and it is intended this be fixed before 2.2.0 release. Several significant bugs have been fixed between alpha2 and alpha2, these include :

Inclusion of mapping of NT ACLs to Linux ACLs, using the patch found at http://acl.bestbits.at.

This is being done via an abstract interface that needs porting to the following UNIXes - IRIX, Solaris, HPUX, AIX - as many as can be done will be supported at 2.2.0 release. Please look at the code in lib/sysacls.c for the needed work.

Addition of tdb spinlock code for tdb speed. Addition of user list lookup from Win2k (thanks to the Samba TNG branch code for this). Addition of generic to specific mapping of security descriptors in printer code. Addition of code page 857 (Turkish). Addition of "%D" substitution for incoming Domain of user. getpwnam/getpwuid cache. Many codepage fixes when dealing with printers with extended characters (thanks to HP for this fix). Inherited security descriptors for printing. Creation of internal NT "token" for smbd access checks. Addition of NT trans code for client. Fix for inheritance of blocked signals (thanks to HP). Addition of "total print jobs" parameter. Fix for NT not being able to save properties changes on PCL drivers. Fixes to speed up enumeration of print jobs. Cleanup printer spool files on client disconnect. Byteswap fixes for printing code (thanks JF). New parameter "dos filemode" to allow a user who can write to a file to change permissions on it. Subtle statcache bugfix. Fix for Office2000 print to file bug. Fix for MS Access multi-user open problem. Valid users now in linked list rather than array. SMB lookup now table driven rather than linear search (doh!). TDB locking fixes for multiple openers.

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. It is currently believed this functionality is working in alpha2.

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

From a DOS prompt "dir" shows all files and directories, but "dir *.*" only shows directories and files with a dot in their names. This does not match the behavior of a NT share from the same client.

Interesting - the problem seems to have been triggered by my selecting "nt smb support = No" in my smb.conf file. I guess the answer is "don't do that" (tm).

no, that patch does not look correct. masktest shows that *.* does _not_ match with trans2 queries. Note that *.* on the dos command line does not translate to *.* in the SMB query. So any testing you do from WinXX tools or the prompt is completely bogus.

I'm not completely convinced that the change in get_dir_entry() is necessary. How exactly do you reproduce a case where that is necessary? What goes over the wire?

ok. Here is what I have found. DOS implements a different wilcard matching algorithm than Win98/NT. I believe that WfWg also falls in line with the DOS client, but I do not have a 16-bit windows box to test this right now.

In nutshell, the difference is between how the ? and . characters in the pattern should be handled. Under DOS, ???????.?? will match a file with 1-7 or less characters in the name and 0-2 characters in the file extension. On Win98/NT, this same pattern would only match files with exactly 7 characters in name and 2 characters in the extension.

We were implemting Win98/NT semantics (even for DOS clients) and hence all the problems from WfWg/DOS clients being reported. The new ms_fnmatch() code I'm including here works under my tests of DOS, Win98 & NT4. The '?' code contains an ugly hack using get_remote_arch() to determine what semantics to implement. If anyone can think of a cleaner way to implement this, please let me know.

With regards to the problem reported by Richard Bollinger ...With nt smb support = no, when a win98 client types 'dir *.*', only filenames with a '.' in them are returned by Samba.

The problem here is that when 'nt smb support' is disabled, the Win98 client attempts to match *.* in the TRANS2FindFirst command (as opposed to sending * when 'nt smb support = yes'). This is also fixed by the new matching code.

The problem with this code right now is that the test

if (*n == 0) ...

when dealing with .'s in the wilcard breaks bin/masktest. However, this code works is needed by DOS clients and Win98.

..............

If you remove the '.' case entirely, DOS clients break. If however, you exlude the test for all but DOS clients, then the problem reported by Richard B. is still present on win98.

According to section 3.4 of the expired CIFS spec...

If the client is using 8.3 names, each part of the name ( base (8) or extension (3) ) is treated separately. For long filenames the . in the name is significant even though there is no longer a restriction on the size of each of the components.

which seems to imply that the test is neccessary. Like I say, it appers to work for real clients, but breaks masktest.

I'd be far more comfortable with changing Samba behaviour based on whether "nt smb support" is set. When it is not set then we are supposed to be masquerading as a non-NT server and it may be that clients expect different results in that case.

Any test where we used the guessed client type I think pretty much must be wrong, and will allsmot certainly lead us back into the old spiral of fixing the behaviour of individual test cases (which always ends up breaking other test cases).

One big advantage of a test based on whether "nt smb support" is set is that we will know for certain that we are not screwing up something else if that setting is not made. Any change to the wildcard code based on client type will not give us that guarantee.

The CIFS spec is a complete fantasy when it comes to wildcard matching. It was some writers idea of how things are supposed to work and it is easy to show that the person who wrote it didn't have a clue.

My principal comment is that the trick to solving these issues is to determine whether the difference in behaviour is caused by differing client expectations depending on something we are returning (ie. whether we set the nt smb support bit) or whether it is caused by the client calling different SMB calls and us failing to properly implement those different calls.

well, if we want to emulate NT then this is in fact the correct behaviour. I just tried using smbfilter to connect win98 to NT4server and did a "dir *.*" at a win98 dos prompt with smbfilter set to remove the "CAP_NT_SMBS" bit from the servers capability field. The NT server returned only files with a '.' in the name.

What this means is that the behaviour on NT is definately not determined by the server looking at the client type.

The next question is what sort of server are we trying to emulate when we have "nt smb support = no". To determine that I would first like to know *why* people use the "nt smb support" option. Is there some other critical behaviour in Samba which needs that setting set to no? Can we fix that and remove the option completely?

Finally, are there any known wildcard behaviours in Samba that differ from NT server when "nt smb support" is left at its default value (ie. true). If there are (even for some obscure client) then we need to fix them, but we need to know what they are first.

My current thought is that if it turns out we do really need the "nt smb support" option for some important purpose that we will need to go through the whole fnmatch() development process again for a Win9X compatible fnmatch() function and we will have to make it policy that we try to emulate the Win9X server behaviour when "nt smb support" is false. That option would then select a range of different function implementations to try to emulate win9x.

I don't rate this as a top priority though, unless someone can tell me why "nt smb support = no" is critical.

I've now proven that NT does select wildcard behaviour based on the protocol dialect that is negotiated. What is more interesting is that the behaviour of all the wildcard functions (including the NT specific findfirst requests) changes, not just the functions that are legal with the lower protocol level.

To demonstrate this I modified smbclient to use SMBsearch and to not negotiate above LANMAN1 protocol level. When connecting to NT the mask ?.??? matched the filename "x". Changing to LANMAN1 with NT_FINDFIRST gave the same result. Changing to SMBsearch or NT_FINDFIRST with the NT1 protocol level changes the result so that "x" does not match "?.???".

This means that NT must select a different set of internal wildcard matching routines when a client negotiates a lower protocol level. I think we will need to do the same thing to be compatible.

The hard bit will be writing the new fnmatch() function to cover this case. Luckily masktest will make it easy to test.

Yup. That's what I found. I think the only main difference is how to handle the '?' wildcard. At least as far as I can tell.

samba 2.2alpha2 (and current CVS) is crashing when writing the user's profile to the server from a W2K box as reported by others already.

It's coredumping in unpack_nt_owners():

exactly in the sid_copy() call.

now the why: easy there is not owner_sid in the ACL and there is no group_sid neither !

Thanks JF - I changed that code recently to allow it to be called from the NTtrans create with SD call - and I forgot to add the checks on the validity of that bitfield.

It's a stupid bitfield, as the SD is self describing anyway :-) :-). Sorry - thanks for the fix.

.... once it wouldn't build, and another time a large bug was introduced, known about, and the fix added in the following day.

Having some weekly snapshot of known stable stuff would be better than waiting the 3-4 months between alpa1 and alpha2.

Here's the current buglist I have to work on before Samba 2.2 looks "feature complete" and we can ship. I thought people might appreciate an update as we've been at this a while :-) :-).

a). W2K clients joining a Samba 2.2 PDC. I fixed a bug on this yesterday, w.r.t. odd/even domain name lengths. This needs more testing.

b). Wildcard fix with DOS clients. Andrew and Gerald have been looking at this - it's a high priority problem but it may just be with "nt smb support" set to no - in which case we could remove this option.

c). NT profile directories being created with zero-length permissions (I mean zero permissions :-). I have traces of this, it's a NT security descriptor bitmask wrangling problem. Should get fixed this week.

d). Allowing Win9x clients to get a user list from a Samba PDC. Feature add - "must fix" before 2.2 ships. VMware helps a lit here :-).

e). POSIX ACL code ports to Solaris/IRIX/AIX/HPUX etc.

Vendors could help a lot here. Currently the only supported platform is Linux with the "bestbits" patch. This probably hasn't had enough testing - once the vendor ports are done it will get a lot more shakeout. Currently I have volounteers for IRIX and AIX. No one looking at Solaris at the moment (helloooo Sun - anyone there.... ? :-) :-).

d). Documentation updates to match code. Big job - I'll start working on this full time when the code i s complete....

g). Patch integration. Yes I'm sure there are lots I've missed. Don't let me forget any !

h). Various printer driver specific problems (usually PCL drivers). Getting fixed slowly on a one-by-one basic (usually in conjunction with HP - good on them !), we owe a big debt of thanks to John Reilly (our new man on printing :-) :-).

Ok - that's the state of things for now.... let me know what you think !

I'm working on Linux XFS acls integration. Anyone else out there doing the same?

Help me complete WINS failover. It's just that little bit surrounding the UNICAST_SUBNET

I've been working at better PAM support, including session support. It would be VERY neat to get this into 2.2, particularly as its easier to justify the extra requirements (changes in /etc/pam.d, changes in behavior) for a major release.

http://samba.org/samba-patches?findid=231

I've also been working on a better RPM spec file (posted to this list, but I've got a better one anyway).

http://samba.org/samba-patches?findid=229