Samba Traffic #25 For 21 Jul 2000

The mailing lists are being overhauled, the Samba-TNG code base lurches ever closer to feature-completion (it compiles again!), printing in the HEAD branch is being completely reworked, the three projects cliffs, sidlc and aparser/vluke are promising to take Samba development in an entirely new direction, Real Soon Now. Chaos? Mostly business as usual.

There were 408 different contributors. 147 posted more than once. posted last week too.

There have been many complaints over the past few months about the Samba list archive server. Since the beginning of the year it has had some broken links, and the search function has been largely missing in action. More recently the whole archive disappeared from the face of the Web, and Tim Potter stepped in to explain:

There are currently some problems with the mailing list archives on samba.org and mirrors. These are mainly due to a failing disk on the current samba.org machine. A new machine has been donated by SGI and will be located at their offices in San Hose.

We are just in the process of migrating various bits of the old samba.org to the new machine. Hopefully new and improved functionality will be available in a while. Please be patient.

Big thanks go to SGI from the Samba Team for donating the new machine and housing it on the right end of a fast network connection.

Two days later, I announced an alternate site, http://samba.cadcamlab.org/lists/, put in place for basically unrelated reasons: "One thing I don't like is its list archive feature. The archives are hard to navigate, and the threading is atrocious. I'm accustomed to MHonArc-generated archives, like they use at debian.org and kernelnotes.org. Call me a bigot but I can't figure out why the rest of the world hasn't switched to MHonArc yet. (:" I also noted that I had not yet set up searching due to horsepower limitations on the host server. Tim reminded me, "I'm in the process of setting up GNU mailman to provide better mailing list access and archiving. Listproc is really starting to show its age as you already know. (-:"

Another user complained about my archiving his posts, clearly labeled "do-not-publicly-archive". This turned out to be a technical problem with the list server, which was resolved easily enough.

Nico Williams had a request: "Please include all the relevant headers in any mailing list archives you set up. Specifically:

Meanwhile, the current status of the new SGI-hosted machine, us4.samba.org, is that it is now the list server for the samba-cvs and samba-technical, and Tim is working on converting the others. So far it seems to be working fine.

Jerry Carter, apparently looking for something to do, asked samba-technical: "What is the status of rpcclient in HEAD? Doesn't link in my CVS checkout currently. Is anyone working on this right now? In other words, should I fix it or wait?"

Luke Leighton replied, with characteristic brevity: "disabled. the only reason i have not removed rpcclient/*.c is because i was told not to." Tim added, "You might want to fix it linking at least, although there is a serious amount of functionality that just doesn't work, or is only present in TNG. It's not really a useful tool in HEAD." Then Luke added, for good measure, "please remove the code (starting with rpcclient/*.c) and start from there. thanks jerry." And replying to himself, as he is wont to do, he explained further by way of listing the contents of the rpcclient directory in each branch: SAMBA_TNG had over three times as much code in it.

Jerry decided to go ahead and fix the linking problem right away, then later focus on porting the real code over. And so he has been doing.

Andre Naehring put it to samba-ntdom: "Are there any known problems using Windows NT 4.0 Workstation with installed Client for Novell Netware v 4.71? If I try the login into my domain, NT crashes with a bluescreen, while another NT Installation without the Client works well."

Ondrej Hanak replied, "To solve this problem, uninstall novell client and use one from M$. Or don't use NOVELL:)" Paul Collins disagreed: "Microsoft's Novell client is horrible." Darren Hammond speculated that some serious problems he had been having were probably related to the Novell Client as well. But Simo Sorce countered: "I'm using M$ Client for novell in a samba controlled environment and all works fine. Check that the binding preference is on tcp/ip as binding preference for novell may disrupt more the election system of Windows machines as the samba server cannot see elections or messages sent through IPX."

Darren objected that he still needed the Novell client, and I explained that Simo was only suggesting that he remove the IPX bindings for certain services. Darren replied, "I finally got around to trying this today. It has cleared up a few anomolies in MS browsing - thanks, but sadly I still get STOP errors and a blue screen when logging in with the Novell Client. If I uninstall the Novell Client or use the MS one, it works fine. I can even log in as a domain administrator, run scripts, etc."

Paul had another idea: "I presume that you have reapplied your service pack after each of these network configuration changes (including client installs/reinstalls)? Tedious, I know, but vital." Darren had apparently already tried this.

What eventually worked was Samba-TNG. "I wish I did this ages ago. The thought of CVS downloads & compiling things usually makes a beginner like me feel queasy. No problems compiling and now both my Terminal Servers and Workstations can log into the domain with the Novell Client installed. I'm one helluva happy man. : - ))))))))"

Claus Färber mused, on samba-technical: "I wonder if it's a good idea to add calls to the samba servers that would export unix file permission read and write functions to clients. These could for example be used by Win32 shell extensions to handle the native unix permissions directly, thus avoiding any strange effects (for the average user) introduced by the permission bit <-> acl mapping."

Jeremy Allison came up with an answer sometime in the next sixteen minutes: "HP have already done this for the CIFS/9000 product. It was done via new trans2 calls in the base SMB protocol as specified by the UNIX-Extentions to CIFS document. We should be integrating that code (thanks HP) shortly (once we're out of printing hell :-) :-)." "Printing Hell" has been the term of choice, of late, for the recent effort to integrate the Windows NT printing code into the next stable release (see Issue #24, Section #4 (18 May 2000: 2.0.8 Release Plans Cancelled) ).

Shirish Kalele noted that exposing an API for Unix permissions would require client support as well. Luke remembered, "microsoft indicated, three years ago, that if extensions like this were added, they'd consider adding support for them in their clients."

Meanwhile, Elrond remembered a post from Gunnar Degnbol last March (see BROKEN KCREF): "Some time ago, someone posted some announcement for a shell extension here. It was named uae or the like. The *.zip even contained a *.idl-file for his stuff. (*bing* A real-world simple idl-file... going to feed it into sidlc and if the license is GPL, going to put it into the examples-dir)" He rummaged around, found the URL, and announced that it didn't work anymore. Gunnar promptly resurfaced: "Sorry it disappeared. It's back now. I started designing a new interface, but wasn't sure about what it should look like and where to hook it into Samba. The cifs-unix spec talks about a new protocol level, which only works between Unix machines. As I understand it, HP's implementation works whatever SMB dialect is used, and I just have to try and call it to see if it is there?"

Shirish posted a pointer to a paper on HP's server-side implementation. By request, Jeremy summed up: "Samba will send mapped ACLs always if the nttrans GetSecDesc call is made, and UNIX perms always if the modified trans2 call is made, it's how the client asks that's important."

The discussion then wandered off into implementation details for presenting the Unix permission data in a human-readable form at the client end.

Tim Potter announced on samba-technical: " I've created a mailing list for the sidlc project. Everyone interested in sidlc stuff should subscribe to sidlc@samba.org."

Tim's announcement was fairly self-explanatory and there was little discussion, except from Chris Hertel who asked exactly how to subscribe. Phil Mayers reminded him that the subscription info was actually contained in Tim's announcement (see http://us4.samba.org/mailman/listinfo/sidlc), to which Chris just had to reply:

Yes, thanks, I've been told.
Just being a clod today.
A sorry haiku.

Klaus Zieger wondered aloud on samba-ntdom: "Has anybody experience with Samba (2.0.7.) set up on a fast server (2 CPU's and 512 MB RAM, 100Mbit/s network) as primary domain controller for Win9x clients. Is the performance still acceptable if there are about 45 clients (45 PC's and a maximum of 90 users, on the average there are about 30 logons but there frequent logoffs and logons simultaneously) ?"

Mike Westkamper had a similar load but on very modest hardware: "I am running SAMBA 2.0.6 on an Intel P5/90 with 64kb memory. I have 30+ users (95/98/Nt4/Win2k/OS2/Linux), 170gb SCSI, 100mb network. I am also using IP chains on this box and have had no incidence of slowdown. The system runs peak at 55% during long builds."

David Bannon had more hardware, but still less than was asked about: "I have some 130 users here hanging mostly NT4ws (sp4) but a few win95 (and no win98 ) and a couple of macs using Dave. At any one time there are typically 80 active logins. The PDC is a RH 5.2 running samba on a PII-350 with 256meg ram. Load based performance does not seem to be a problem, that is things don't slow down significantly at full load compared to early morning when there are less people on."

Jerry Carter reported on a larger installation: "I've run 2.0.6 of a Sun E3000 (4x250Mhz) with 1.5Gb RAM. Included 5 100Mb ports and 250Gb of disk space. Number of clients supports was ~700."

While Luke is excited about generating Samba interface code directly from preexisting IDL files, he is currently using Tridge's evolving awk-based parser, also known as Virtual Luke, instead of Sander's sidlc. It seems aparser/vluke is a bit further developed at the moment. He reports to samba-technical on his prototype, known as cliffs, from time to time.

findfirst / next / close - the latest ops now working! so that makes:

negprot (LM 0.12 only)
sesssetupX (parses, no auth so all ops are root)
tconX
openX, readX, writeX, close
trans
trans - lanman:
- DosNetShareEnum
- DosNetServerGetInfo
trans2
trans2 - fileops:
- FindFirst2 (info 0x104)
- FindNext2 (info 0x104)
- QueryFSInfo (info 0x105)
findclose2
getattrE (only one info level)

this is a fairly radical, "clean" approach i'm taking. aside from the auto-generated code, the largest .c file, aside from those borrowed from samba source, is 204 lines long, in each of which, the GPL license takes up 20!

so, aside from there being lots of files, it's really obvious what's going on as the auto-generated code dealing with the over-the-wire stuff is completely separated from the actual job of being a "server".

despite the obvious complexity and mess of dealing with the SMB protocol, this stuff is actually quite a pleasure to work with.

maybe i will do locking next, although i would like to have notepad opening / saving a file, first: it does weird stuff like trans2-query-fs-info requests and getattrs that i don't support yet.

interesting to see what i can "get away with" not supporting, and see what breaks and what works. e.g i don't return 8.3 mangled file names in the findfirst/findnext lists tee hee :)

authentication hasn't been added yet, The Plan Is to use TNG code on loop-back for both authentication and any DCE/RPC requests just get passed straight through, no questions asked (like they are in TNG at the moment).

so, i do not link in the SMB client library into conifersd at the moment, and i plan to make sure it stays that way unless there is a really compelling reason to do otherwise. and at the moment, there isn't one.

things i am definitely not going to consider supporting:

security = share

things i am going to consider supporting under duress or will be happy to accept patches for:

win95 - plaintext passwords

things to support if they are needed:

SMBsearch (8-bit, DOS-variant of Trans2FindFirst needed even, as andrew mentioned, for DOS-apps running on NT)

quite a lot achieved in a short space of time. hindsight and most of the work done through using a spec is a great benefit.

ok! interesting progress with cliffs. am chewing through the smbtorture tests, i have all the lock tests done, and passing. i have the deny-mode tests going, except i don't really know how to interpret the output and there's no confirmation of its results.

i definitely pass fdpass, lock1-5, tcon and unlink, which is kinda cool.

building is still a bit of a pain: please read the README instructions, you have to "prep" beforehand to get the auto-gen compiler to create [ch] files.

no authentication yet, still, as i said i'm going to just call domain_client_validate() and nothing else, relying on the TNG daemon architecture to do the actual work.

the smbvfs layer is worth mentioning. i'm abstracting / simplifying the SMB calls in a similar fashion to the vfs layer [which is intended to do a per-share SMB redirector]. the smbvfs layer is intended to be able to entirely redirect all SMB operations.

for example, writing an smbvfs layer that redirects, using smbclient, to another SMB server, will be trivial!

compared to smbd, from whence the locking, open and close code is taken, cliffs is a lot simpler. i've taken out the write cache and the stat cache, for example. if these are later deemed necessary, then they can be added as a vfs redirector module.

printing can be done in the same way: add a vfs module for the LPT: device. heck, could even do a special one depending on the filesystem type (NTFS, CDFS, FAT), now that i think of it.

two steps forward, one step back. or is it the other way round?

ok, just fixed up silly linked-list bug.

i now have, i believe, the semantics for files-closing, correct, namely [and if anyone know therwise please let me know!] that when you cloe a treecon, you close al files in that tid but _also, when you close a session (SMBulogoff disconnects a vuid), you _also_ close the files opened by that user.

so what i do is i maintain a separate single-linked-list on a per-session basis _as well_ as a list of files in a tcon.

.. i just realised that this list is not updated if you do a tree disconnect. oops. will fix that next.

am still thinking about oplocks.

will move on to auth, soon, and will start on DCE/RPC code for net_r_samlogon auto-generation then.

Alex West reported success, on samba-ntdom, in creating a domain trust relationship: " I have been able to create a trust relationship between my tng samba pdc box and my nt pdc box, with samba as the trusted and nt as the trusting. I did this by creating a machine account in samba using the -i option, with the name of the trusting domain, and a machine account in samba with the name of the nt pdc machine. I then used user manager for domains on the nt pdc to create the trust using the password I gave to the trust account on the samba pdc. This seems to have worked." Unfortunately, he continued, he could not create a trust relationship the other direction, i.e. the Samba domain trusting the NT domain.

Elrond had one note of caution on the first part: "The nt pdc will change the pw every some weeks and it will only change the pw for the account with the domain-name, so you have to copy the pw over to the account for the pdc-name. I'm thinking of fixing this by using the trusting domain variable, but I currently want to get CVS TNG more stable... before starting to play again." As for the part Alex hadn't gotten yet, he said:

You've to do the following too:

add the domain to the trusted domains-list:

  trusted domains = "domain=pdc,bdc"

Then you have to do something like

  smbpasswd -j NTDOMAIN

(hope, I remember that correctly...)

The other way is to find out the domain sid of the nt domain (rpcclient -S ntpdc -U % -c 'lsaq') and create a NTDOMAIN.SID next to your SAMBADOMAIN.SID file, with the SID as contents.

The next problem is, that samba needs a unix-user for each nt-user... you might want to investigate winbind, or create them all by hand...

At this point Alex reported increasing success, but both he and Kevin Colby thought the "trusted domains" syntax a little bizarre. Elrond suggested using ":" instead of "=", and this made sense to Kevin.

Matt Ellis asked the samba list about sharing removable media with Samba: "Has anyone been able to get a zip drive working with samba? I want to set up a systsem where the drive gets mounted, in a letter like F: and students can pop in and out zip disks without having to deal with any unix interfaces."

Robert had a quick answer for that one, too. "The trick is to unmount the share. Give them an icon with something like

Jayne Gilmour posted in frustration to samba-ntdom, asking for clarification on password encryption: "As I understand things, you must have 'encrypt passwords' set to yes in order for NT clients to sucessfully join a domain, etc. But to authenticate NT users from the Unix password file, 'encrypt passwords' needs to be set to no. In other words, am I right in thinking I can't have a Samba server as PDC and use the Unix password file?"

Simo Sorce replied, "If you have no problems to have clear text password floating on your lan, than after SP3 you have to change a registry in NT 4 to let him accept plain text password again. Doing this you may set encrypt passwords to no and unix password sync to yes" Jayne replied, "Yes, but once you set 'encrypt passwords' to no, the Samba server can't be a PDC." Buchan Milne agreed.

Simo also mentioned in passing, "Instead I have set up an HTTPS server and I'm using PHP plus some setuid root executables to update both nis and samba password databases." Seth Vidal and Mike Westkamper were both quite interested in those scripts, so Simo made them available: "Ok, there's something i put on my home page in a hurry. The 'thing' is really rough and messy and I consider it a starting point. Again the tgz is not up to date (I have not on hand just now the last modifications we made) but should work. See: http://www.geocities.com/SiliconValley/9757/samba.html"

I decided to take a shot at writing the enhancement request to allow samba to access more than one WINS servers. The code base I wrote this on is 2.0.6. The enhancement involves changes to 5 files:

  source/libsmb/namequery.c
  source/nmbd/nmbd_subnetdb.c
  source/param/loadparm.c
  source/utils/testparm.c
  source/include/proto.h

The design goals I tried to adhere to in this enhancement were:

Minimal amount of change to code and smb.conf file
The primary WINS server stuff is exactly as it was. I didn't rename any of the existing variables, I merely added the ones needed for the secondary server.
Only allow a single secondary server, rather than a list
Microsoft only allows a primary and secondary server to be specified so I used this model
The behavior is to query the primary first and only fail over to the secondary if the primary does not respond, rather than use a round-robin method of load balancing the servers.

Again, I believe this is how NT works so this is the model I used.

Chris Young and Chris Tooley both thought support for multiple WINS servers was quite useful. Chris Young said, "For many shops, Samba is being integrating into an existing Windows NT domain. With that in mind, it is important that Samba be able to use more than one WINS server (especially when you consider how often a Windows NT server can go down or have WINS corruption that makes WINS unavailable on the system)." Chris Hertel was a bit more reserved: "How is it "absolutely necessary"? The WINS service is not a critical service, per. se. The network can run without it. The only case in which it would work involves having two MS WINS servers running in replication mode. In that case, should one fail, you can make a quick change to smb.conf and signal the Samba daemons to restart. Don't get me wrong. It's a good patch, I'm just looking for input. Sometimes there are real reasons for our behavior." He added, "If the WINS database is corrupted, what happens to the secondary WINS server? Hmmm..."

Chris Young was adamant. "Have you ever managed an enterprise-level (if there is such a thing ;) Windows NT network? I'm certain that anyone who dealt with this will understand my point. Relying upon a single WINS server for an enterprise is NOT a good idea. No matter how poor WINS is, it becomes very neccessary in large multi-network, routed environments (at least as far as Microsoft network clients go). Obviously, you can use DNS to make certain that name resolution happens for the key servers. This alleviates alot of the problem, but not all. Windows client depend upon NetBIOS name resolution as well as other services. For instance, there are many products that use NetBIOS name resolution to associate a logged in user with a workstation (hostname). I'm not saying that this is the best way to do this. I'm saying that it happens."

Hertel was adamant too. "I manage a network of over 50,000 systems in over 200 subdomains (real domains, not NT domains). In an organization this size, WINS simply does not work. We do have a central WINS server which has, in the past three years, gone down two or three times--typically due to the failure of some other service or device. Of course, it's running Samba. On the other hand, very few people use it since it represents an invalid NetBIOS namespace." As for WINS being "necessary", he said, "It is a worth-while convenience and I'm not at all trying to say that it isn't important. I'm being pedantic regarding the use of the term "necessary". The system will work without it. It's just not pretty." As for why WINS replication exists at all: "Microsoft added WINS replication and the secondary fail-over to add a little robustness. As you've discovered, another way to do the same thing is to run Samba. :) :) :)"

Jerry Carter and Jeremy Allison both wanted to expand the config file syntax to include a whole list of WINS servers, rather than just two. That led off into a long discussion about the assumptions of WINS replication and failover: should Samba assume that all the WINS servers are auto-replicated, or not? Then there was the replication support issue: should Samba be enhanced to support replication with NT WINS servers? That one is not an easy call, because it requires no little reverse-engineering, and because in the past, apparently there has never been much of a clamor for this feature.

As an aside, Peter Polkinghorne mentioned a patch he had written for nmbd to prevent machines from registering in the WINS database unless they were already in DNS. "This enhancement basicly says when a name is registered with a WINS server (Samba based) the IP address has to correspond to a DNS name with same IP addresses. This is to achieve 2 things for us:

The discussion seemed to draw to the conclusion that Chris Hertel would indeed be integrating Dave's patch, with a few modifications. Other issues were still in the air. The thread died but the discussion didn't, really: stay tuned for more next issue.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	22 Jun 2000 - 26 Jun 2000	(11 posts)	Mailing Lists and Archives
2.	23 Jun 2000	(7 posts)	RPC Client Code Merge Started
3.	23 Jun 2000 - 7 Jul 2000	(13 posts)	Problems with Novell Client for NT
4.	24 Jun 2000 - 3 Jul 2000	(18 posts)	Exposing Unix Permissions Directly To SMB
5.	26 Jun 2000 - 27 Jun 2000	(5 posts)	New Samba-Related List
6.	26 Jun 2000 - 27 Jun 2000	(5 posts)	Samba Performance Numbers
7.	26 Jun 2000 - 11 Jul 2000	(3 posts)	CLIFFS Updates
8.	28 Jun 2000 - 5 Jul 2000	(7 posts)	How To Do Trust Relationships
9.	3 Jul 2000	(5 posts)	Sharing Removable Media
10.	6 Jul 2000 - 7 Jul 2000	(9 posts)	Plaintext Passwords on a PDC?
11.	7 Jul 2000 - 12 Jul 2000	(29 posts)	Client Code for Multiple WINS Servers

Samba Traffic #25 For 21 Jul 2000

By Peter Samuelson