Re: quota group
On Thu, 6 Mar 2003, Stefan (metze) Metzmacher wrote: > At 13:13 05.03.2003 +0000, David Lee wrote: > >In the devel/TODO there is a suggested "coding project": > > > >Rewriting Samba's current filesystem quota support as a VFS module. > > I'm currently working on this > > > > >There has also just been another thread from someone requesting some sort > >of directory-dependent result from "df"-like functionality. > > > >Is now the time to extract the handling of "df" (default), "quota", "dfree > >command" into a generalised VFS structure, reimplementing those mechanisms > >in such a framework? > > the disk_free function is allready in the vfs framework > and I'll add the vfs_get_quota vfs_set_quota functions Sounds good. Thanks. In which CVS branches should I look for this? SAMBA_3_0 would be ideal because we are about to start some serious testing of other 3.0 aspects, and I could easily test some of this df/quota functionality at the same time. But HEAD would be OK. -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. :
Re: quota group
On Wed, 5 Mar 2003, Andrew Bartlett wrote: > [...] > If you can repatch this against HEAD, and check with metze (Stefan > (metze) Metzmacher <[EMAIL PROTECTED]>) on how this might conflict with > his work in this area. In particular, it might work out best that metze > picks this up into his patch. (He is working on being able to modify > the quota from an Windows client!). > > Either way, this certainly is a very nice idea! Is this the time to bite the bullet or take the bull by the horns? (Substitute other metaphors to taste...) In the devel/TODO there is a suggested "coding project": Rewriting Samba's current filesystem quota support as a VFS module. There has also just been another thread from someone requesting some sort of directory-dependent result from "df"-like functionality. Is now the time to extract the handling of "df" (default), "quota", "dfree command" into a generalised VFS structure, reimplementing those mechanisms in such a framework? Or maybe this is already being addressed? We can probably assist with testing and coding Solaris/quota, although we can no longer help with Solaris/Veritas/quota, as we no longer have such a server. -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. :
RE: mount points / free disk space / dfree command
On Tue, 4 Mar 2003, Panko, Kevin wrote: > I went and read some of the CIFS spec[1], and it seems to me that the > QUERY_FS_INFO trans2 request only includes an identifier for the current > connection. Given this information, samba can only attempt to determine the > amount of space on the root of the share. This explains why using the dfree > command did not give me any different numbers than not using it. I'm not sure I understand exactly what you want. But there is the potential, at least in the future, for doing more than simply a "df". Did you see my reply of Feb 24th, which mentioned what samba can already do if quotas are present (and, implicitly, applicable to a filesystem)? And how this might be generalised? (By coincidence, another thread has just started about "group quota".) > If I really understand what is going on here, then what we would have to do > is create a new share for each mounted device. That would be hard because > the root that is exported happens to be an automounter directory, which > changes. Want simple "df"-like functionality? Present, as the default. Want to use user quotas? Present, with appropriate compilation and UN*X-host quota configuration. Want to use group quotas? Not yet present; but a recent thread discusses a possibility. Want to call an external program? Present as "dfree command". I have never used it. I suspect it cannot do quota-like per-user stuff, nor per-subdirectory stuff. I could well envisage something conceptually similar to "dfree command", but more flexible, to allow use of username and current-directory: 1. yet another "smb.conf" option. Like "dfree command" (calling external program). This could be hacked up reasonably quickly, but is a "dirty" solution, expecially in view of current herculean efforts to clean the Samba code. 2. Generalise (and re-implement) the existing stuff (df, "dfree command", quota) as VFS modules, allowing sites to write their own modules. This would take longer to do, but would be much cleaner, and aligns well with future development. Summary: What you want may not be there right now. But I think it could be added if designed reasonably carefully, and in context of the "bigger picture". Hope that helps (a little, at least!). -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. :
Re: mount points / free disk space / dfree command
On Thu, 20 Feb 2003, Panko, Kevin wrote: > We have a share with mount points beneath it. Free disk space is incorrect > because samba always returns the free space in the top level directory of > the share. It is the same problem discussed before in this thread: > > http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&th=4c04c4aeb2405 > d4d&seekm=9q2iee%242s7r%241%40FreeBSD.csie.NCTU.edu.tw&frame=off > > I was hoping to use the dfree command smb.conf option, as the "df" command > reports the correct amount of free space for each subdirectory. I found > that my dfree command was always given the directory name of the top level > of the share, regardless of the current directory on the Win2k client, so > the answer I get with dfree is the same as the internal samba routines. > > Why does that happen? Does the QUERY_FS_INFO trans2 call have knowledge of > the current directory of the client, or is that not included in the client's > request? If not, then I must admit that this may be impossible. If it > does, and if that > directory were passed to the df command, then what I need can be done via > samba. This raises a slightly wider question, of which yours is one case. Another case, already handled, is when the samba server (typically UNIX) has user quotas. Samba's behaviour is to let any individual user-quota override its normal "df-for-whole-volume" behaviour. Also the "smb.conf" file does allow an alternative command to be specified and run. (This might be an immediate way for you to address your particular issue, although I get the feeling, possibly wrongly, that this option might be regarded in the as "try to avoid if reasonably possible" or "at your own risk" etc.) Now pulling all that together and looking at the wider question... I wonder whether there is a case for reshaping this functionality into VFS modules in the VFS stack? The default would still be "df" behaviour, but there might be a VFS/quota module, which could act as a model for other free-space modules. -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. :
Re: A Union of two directories
On Tue, 4 Feb 2003, Stefan (metze) Metzmacher wrote: > It would be fine to have config options for match witch files should be > taken from with > directory. > > something like this: > dir1 path = /home/samba > dir1 mode = readonly > dir1 files = *.c,*.h,configure,Makefile > dir1 exclude files = *.o > dir2 path = /home/%m/samba > dir2 mode = write > dir2 files = *.o > dir2 exclude files = *.c,*.h > > and something simular for directories But what about cases where a ".c" file is not readonly source but rather the result of a write, such as from yacc/bison? Similarly where Makefile is written from a source Makefile.in ? And so on. Way, way back in the days of SunOS 4.1.x, Sun had their "translucent" file service: "tfs". (We never used this; I simply recall its existence.) Might this model be the sort of thing you are looking for? I see that the "man" pages for Sun's tfs are still around (I found a copy on the FreeBSD WWW site). See: http://www.freebsd.org/ select "SunOS 4.1.3" as the OS, and search for 'tfs'. Hope that helps. -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. :
Re: --with-cracklib for Samba
On Wed, 15 Jan 2003, Pierre Belanger wrote: > Last night I did a "grep -i todo" in the source code, to see > if I could contribute a little bit more ;-) I found the > following: > > smbd/chgpasswd.c: /* TODO: Add cracklib support here */ > > I started working on this last night (using SAMBA_3_0 > branch) and do have something working (the "configure.in", > documentation, etc is not done yet). I had to make my own > "API" to cracklib to make this work because the original API > uses getuid() and getpwuid() to get the username and fullname > (gecos). I also found a lot of places in the cracklib code > that is really not "full-proof". So... in the search for > a better solution: > > Tonight, I checked the "cracklib" included in "npasswd". > (I found a bug, it's also in the original cracklib!!!) > There isn't a better "API", still uses getuid()/getpwuid(). I am now a couple of years out of touch with "cracklib" stuff, so check what I say, don't necessarily believe it! There is some actively maintained "cracklib" material in the "Linux-PAM" project: http://sourceforge.net/projects/pam My understanding is that "Linux-PAM" is used widely on various Linux distributions (I have very little first-hand knowledge of Linux). It also (notwithstanding the name) aims to be compatible with other PAM-enabled OSes (Solaris, HP, ...). Indeed we have been running Linux-PAM's cracklib in our Solaris PAM structure for a couple of years. (It's so neat, it doesn't require any maintenance attention, so I have now forgotten its detail!) So I would suggest exploring the possibilities that might be provided by Linux-PAM. Bear in mind, too, that Andrew Bartlett is doing much work within Samba to rationalise and add modular flexibility to its authentication subsystem, including cooperating with PAM (for those systems that have it). If I recall correctly it does require an external "cracklib" library. But exploring this route might help with constructing a suitable, mutually sympathetic API for Samba/crack (and possible PAM) interactions. > Do I continue working on this or not? Your ideas sound promising. I'm simply suggesting exploring what possibilities (if any) may exist with Linux-PAM's cracklib module and its related things, and coordinating this work with Andrew Bartlett's work withing Samba to achieve maximum mutual benefit to both projects (Linux-PAM and Samba) and minimal risk of code-forking and fragmentation. Hope that helps. -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. :
Re: Problem with utmp under Solaris
On Tue, 3 Dec 2002, Pierre Belanger wrote: > I found the following message (June 2002). > > http://lists.samba.org/pipermail/samba-technical/2002-June/037434.html > > I read the whole thread. Any new comments? I will try to find > a solution from what I read unless there are new ideas? > > Thanx to google and sorry not to search on google before posting here. I don't think there is anything new to add yet. As I recall there was a general consensus that a solution is highly desirable, but also that it must be "clean". Our proposed solution would also add functionality such as letting UNIX commands "write(1)", "wall(1)" etc. work fully. We agreed on what the possible components of this might be. But this is to be a combination of a few things, which were not yet in existence, such as "session exec" and/or PAM hooks. (The write/wall would then extend to Samba's control/event loop, which has some sensitive interactions.) In the meantime, Andrew Bartlett suggested a workaround. (And I think both he and I would say "AT YOUR OWN RISK" in capital letters.) This was in the middle of his follow-up message on the thread: http://lists.samba.org/pipermail/samba-technical/2002-June/037435.html (There is a minor typo in his suggestion there: "/dev/smbd/1" should read "/dev/smb/1".) Disclaimer: I have not tried this! Hope that helps. -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. :
Re: SMBClient - Messenger service
On Tue, 22 Oct 2002, Nuno Cardoso wrote: > When I use "net send ..." command in windows to send a Winpopup message > to other host, the SMB Command associate to this message is single block > message (0xD0). To do this, it is only necessary sends one SMB "frame" > to the other host. > > When I use SMBClient (samba), the SMB Command associate is multi-block > message (fist it is necessary sends the start comand 0xD5, then a text > comand 0xD7 and finally the end 0xD6). To do this, It is necessary sends > 3 SMB "frames". > > Why SMBClient sends winpopup messages with multi-block message, and not > single block message Where I use multi and where I use single > message block??? The single-frame version can only send a short message (less than 128 bytes), whereas the multi-frame version allows up to 1600 bytes total. See the description of the "File Sharing Protocol". (Use Google to search for "INTEL Part Number 138446".) Over the last couple of years I have looked at generalising this code in Samba, and made some progress. (In a test implementation, I was able to use UNIX commands such as "wall" and "write" to produce WinPopup messages on the client PCs.) This required extracting, and altering, some code from smbclient, but this can be done in a re-useable way. If someone of the Samba Team is willing to facilitate this, I'll willingly submit the changes I made as a possible starting-point. -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. :
Re: Custom named pipes
On Sun, 15 Sep 2002, Andrew Bartlett wrote: > David Lee wrote: > > > > On Fri, 13 Sep 2002 [EMAIL PROTECTED] wrote: > > > > > [...] > > > am I moving too fast and is there already somewhere in the samba code an > > > api which can be called from an external program to create a (server) > > > named pipe? > > > > This sounds related to an idea which we have discussed a couple of times > > this year, but in a different context. Namely, an smbd could have an > > associated named-pipe on UNIX, so that writes to that named-pipe would be > > translated into WinPopup messages for the client PC . > > This is rather a different issue - while it's interesting to note the > comparisons, I don't see there being much in common between these two > issues. Thanks, Andrew. I had merely seen a possible overlap, and was wishing to ensure coordination of effort (and thereby reduce risk of duplication and possible incompatibility). Best wishes. -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. :
Re: Solaris fcntl bug 4700402 at the University of Queensland
On Wed, 11 Sep 2002, David Collier-Brown wrote: > [EMAIL PROTECTED] wrote: > > Oh thank goodness for that, I was worried when I saw the > > other message about the fix being --with-spinlocks as > > that's not a good solution. > > > > We can't hold back 2.2.6 for this unfortunately, we'll > > have to put something in the release notes about it - > > any chance of getting the patchid pre-allocated so we > > know what it will be ? > > I don't know if that's doable, but I'll try: > with your permission I'll quote your last paragraph > in the request. Knowing patch numbers now might actually be counter-productive. Let me explain. Rather than: " Known Sun patches at time or writing will be (or are): 888000-01 for Solaris 8 888001-01 for Solaris 8_x86 999000-01 for Solaris 9 999001-01 for Solaris 9_x86 something like: " You are encouraged to monitor http://www.samba.org/ for developments. The former looks un-future-proof. By contrast the latter could be set up at 2.2.6 code-freeze (now?), and would remain accurate for the lifetime of whatever versions of Solaris are affected and addressed. Remember, too, that Sun sometimes make one patch obsolete and roll its functionality into another. Or, conversely, break out part of a patch into a separate patch. Things like this would invalidate the "frozen" Samba release notes. My suggestion would simply need a suitable Sun-related volunteer (are we thinking Dave C-B here?!) to provide occasional updates behind that URL. -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. :
RE: Draft of branch maintainence and release plans....
On Mon, 8 Jul 2002, Green, Paul wrote:
> I would be willing to work (off-list) with a small number of OS experts to
> agree on an API for producing a back-trace of the stack. I know how we do
> this for VOS, I know some of the issues involved, and I believe that such an
> API definition should be independent of Samba. The challenge is to produce
> an OS-independent API that is flexible enough to accommodate the rather wide
> variety of operating systems, while hiding the guts of the mechanism from
> the callers. (The code to actually traverse the stack and produce output
> that can be interpreted by mortals or even by code is almost certainly going
> to be OS-specific, but I think we can probably produce an API that we can
> all then implement). If anyone else considers themselves qualified &
> interested, please contact me off-list.
Thanks for the note. (I'm keeping the reply on-list for the present, as
it discusses a fundamental general principle, rather than detail.)
What you propose sounds interesting, but very ambitious!
When we originally discussed this back in April, we were proposing a much
simpler model that used existing tools.
In essence, the "./configure" script would look for a debugging program
from a known list ("gdb" etc.). Associated with each such program would
be a list of its sub-commands that would extract the relevant information,
such as a backtrace. That information would then be used to build the
default "panic action" for this particular installation.
Remember, that the sole purpose of this is simply to set a decent default
behaviour for the vast number of Samba admins (such as me!) who don't
dabble any more deeply than is necessary. If a particular sys.admin. at a
particular site wishes to do more, they can still set their own "panic
action".
So I understood it, one of the key aims was to use as simple as possible a
method to get a default behaviour that would extract something useful. It
wasn't (originally, at least) intended to be any more complicated than
that.
The key message from Andrew Bartlett is in the samba-technical archives:
http://lists.samba.org/pipermail/samba-technical/2002-April/035873.html
I'm quite happy to help on some example Sun/Solaris detail in such a
structure. We have various Solaris versions, Sun's C compiler; Sun's
debugging tools (and also gcc/gdb). The ONLY major thing (apart from the
ubiquitous time constraints!) that stops me proceeding is the possible
issue with file descriptors onto the log file, mentioned in that archived
message. If someone else can look after that aspect then I'll try to help
on some example (Sun-related) detail.
Hope that helps.
--
: David LeeI.T. Service :
: Systems Programmer Computer Centre :
: University of Durham :
: http://www.dur.ac.uk/t.d.lee/South Road:
: Durham:
: Phone: +44 191 374 2882 U.K. :
Re: Draft of branch maintainence and release plans....
On Mon, 8 Jul 2002, Gerald Carter wrote: > Someone is doing to need to own these. They sound like > solid ideas. I've not followed the threads on them > due to lack of time (but i do have a vague recollection). > > However, they all seem like icing to me. In other words, > they would be great to have, but we have lived without them. > This said, if someone donates their time to do it, > then great. But I'm not sure if they are features which should > be placed on the "3.0 will not ship until these are done" > list. Thanks for the reply, Gerald. Appreciated! In those items (reminder: "panic action", "session exec", event mechanism) I was, like you, attempting just such discrimination. Each has a vital "core" (or "foundational") component, then each has its "layer of icing". So I was suggesting that the Samba Team could concentrate their efforts on those core aspects, and leave the icing to those of us who then need to develop our own "applications" on top of this. "panic action": the core aspect was simply that someone (I think on the Samba Team) had mentioned an issue with appropriately opening the logfile. "session exec": Andrew B. had mentioned his plan to provide this hook, so presumably has his ideas of what he would do and where (and that it is realistic for him to do it). event mechanism: Jeremy had mentioned the desirability of doing this, and identified the rather intricate problems that would need to be considered, requiring someone with deep knowledge of that area. Once each of those is in place, then the rest of us can "ice the cake". But we can't ice a cake which isn't there. To me (am I alone?), the great advantage of 3.0 seems to be not so much your list's added functionality in itself (though that would and will be great!), but the modularisation which allows a much wider group of people to contribute into such functionality. [ Note the parallels both to the VFS work, and also to Andrew B's passdb restructuring: the core Samba Team have provided the core structure, others can provide the plug-in modules. ] Keep up the good work, and thanks for a great product. -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. :
Re: archive bit in xattr possible/exist?
On Tue, 2 Jul 2002, David Orman wrote: > I know it is possible to use "map archive" to keep track of archive > bits, but this is not very useful if you have real UNIX users. I.e. I > can't have samba arbitrarily playing with the execute bits. It might be worth pausing at this point... I agree that mapping those DOS bits onto UNIX-x bits is not ideal. But, pragmatically, who does it harm and how? The assessment of this question will vary from site to site, so one site's pragmatic answer may not be sufficient for another's more purist technical requirements. But the question is still worth considering. In our environment (15,000-20,000 registered users; 1,000+ simultaneous connections; university staff and students) this odd-looking mapping has not, in practice, been an issue. Most folk sit at Windows PCs, and simply see what appears to be a Windows fileserver: they never get anywhere close to diddling with UNIX permission bits on the storage of their Windows files. A few folk do also use UNIX directly, but they, as part of natural working practice, rarely, if ever, use any particular file both from UNIX and from a Windows box. So, at our site, pragmatically, that mapping is not an issue. (Now if _your_ users at _your_ site really are often using the same file from both environments, and if they find this mapping to be troublesome, then, I agree, you do have an issue that needs addressing.) > Does anyone know of any attempted implementation of archive bits through > extended attributes? This would probably need a VFS layer, to get and > set them appropriately. Speaking as someone totally unqualified who has never yet used Samba's VFS, that to me sounds a reasonable plan. It just needs to get consensus and then needs someone with an interest (who could I mean?!) to volunteer to develop the module. (Possible portability issue: some UNIX machines (samba servers) don't have ACLs; those that do may have different ideas and implementation details.) But first of all, ask the pragmatic question of how significant this issue really is for your users at your site. Hope that helps. -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. :
Re: Draft of branch maintainence and release plans....
On Tue, 2 Jul 2002, Gerald (Jerry) Carter wrote: > Here are the plans for getting 3.0 ready for release and the > maintainence plans for SAMBA_2_2. Comments welcome. Thanks for the news: it is useful to know this sort of thing. > Roadmap to 3.0 > -- > > The following features are planned for inclusion in 3.0. > This list was compiled based on previous promises during 2.2 > development and believed future directions of Samba > [...] Could I add a few things for consideration? Note the word "foundation" in what follows. Most items have such a structural foundation aspect as a pre-requisite to building the actual functionality. To a first approximation, I'm assuming that the foundation work can only be done by the Samba Team. (Is this a fair assumption in the items listed?) Once that is done, then the rest of us can then contribute the further building work. panic action Some months ago we had a discussion about "panic action", and agreed on the desirability of improving the default behaviour, so that, if reasonably possible, it would automatically attempt to invoke a debugging program to dump a backtrace into that smbd's own log file. And in the last few days, this list has seen another example of a sys.admin. who (like me and many others of us) would have been able to benefit if a default debug/backtrace had been in place. I think Andrew Bartlett had identified an issue to do with diverting the output into the log file, which would need attention. It would be useful if that foundation aspect could be put in place by the Team (Andrew B?). Then others of us could look at detecting (autoconf?) and scripting for various debugging tools. event mechanism --- Around 17th June we had a discussion about generalising the central loop of "smbd" to that other devices (e.g. "/dev/smb/") could be read etc. One example would be so that write(1) and wall(1) could be used and the data translated into WinPopup. This example has been proven in demonstration, but Jeremy, understandably, wants this foundational event mechanism to be tightened before we build anything on it. session exec In various contexts, including a "make home directory" discussion in recent days, and earlier discussions about write(1) (see above), Andrew B. has mentioned the possibility of a "session exec" as a foundation for such work. Such a foundation would, I understand, also allow the "finger" problem to be fixed (e.g. the exec script invoking some external agency to be built to create/delete/mange/whatever "/dev/smb/"). OK? -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. :
Re: smbd
On Fri, 28 Jun 2002, Lupscha, Franc (AU - Sydney) wrote: > I am running Samba 2.2.2 on SUN SPARC Solaris 8 (feb 2002) with all the > latest patches. > Samba appears to be running fine except that I get the following appearing > in the "log.smbd" file . > > " yield_connection: tdb_delete for name failed with error Record does not > exist. " > > Is this normal or is this a bug ? I, too have seen that. I don't recall whether it is normal or a bug. But I do know that the early Samba 2.2.x (including 2.2.2) and Solaris were not the happiest of companions, and I would strongly urge you to migrate to a later release of Samba. (My direct experience was that 2.2.3a was much better than 2.2.2; I have heard that even this and 2.2.4 still had occasional problems under Solaris. Not heard anything bad about 2.2.5/Solaris.) So I'd suggest that you investigate 2.2.5 . Hope that helps. -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. :
Re: Some additional questions about benchmarking CIFS servers
On Sat, 22 Jun 2002, Richard Sharpe wrote: > During some discussions yesterday with some folks, I realized that a > couple of additional deficiencies that NetBench has are: > > 1. All the clients connect at the beginning of the benchmark, and do not > disconnect until the end of the benchmark. Connection handling is an > important aspect of a CIFS benchmark, and while you do not expect every > client to be disconnecting and reconnecting every five seconds, you do > expect a certain connection load, perhaps 5% of the overall clients would > connect and disconnect from the server twice during the benchmark. I'll second that! One of the main problems we had a year ago on our main fileserver (Solaris, Sun 450, up to 1,000 simultaneous "smbd" connections) when we tried moving from Samba 2.0.x to 2.2.x (and then through the 2.2.x series) was the avalanching of "smbds". Contention on "connections.tdb" seemed to be a contributory factor. I understand that this was compounded by oplock-related issues, but nevertheless, we were typically averaging one operation per second on the database. (Student classrooms spread across campus; "burst" activity as lectures finished; etc.) The machine was already loaded with the routine activity of established smbds. So in our experience and environment, the connect/disconnect activity seems to be a significant factor in loading a Samba server. Hope that helps. -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. :
Re: [Fwd: Finger problem on Solaris with 2.2.4 (PR#24659)]
On Mon, 17 Jun 2002, Jeremy Allison wrote: > On Mon, Jun 17, 2002 at 12:24:34PM +0100, David Lee wrote: > > > > So my trial implementation was: > > 1. "smbd" to create/delete "/dev/smb/n" as a "named pipe"; > > > > 2. "smbd" then to include this in its "select()"; > > > > 3. anything appearing on "/dev/smb/n" to be sent to the client PC as a > >WinPopup, using code very similar (and potentially common) to > >"smbclient -M". > > > > As a proof of concept it solved the "who" problem, and added this extra > > wall/write functionality. > > Unfortunately this is harder to do right than it appears. Even tridge > created a bug when this was done for the select/kernel oplock code > (it's finally fixed for 2.2.5). I can believe that... Being a Solaris site, I had noticed during the last year of 2.2.x evolution that this area was relevant to those pernicious oplock and avalanching problems whilst marvelling at the abilities of the Samba Team to understand subtleties of the problems. So my trials were only ever intended to be "proof of concept", and I realised that this area in particular (events, select()) would need the eagle-eyes and experience of the Samba Team. > To do this easily requires a proper "event" mechanism. I know how > to do this, but currently lack the time to code it up. Indeed. In my tentative dabbling around that select(), I, too, thought "this ideally needs a rationalised event handler". > IMHO we need the even[t] mechanism in smbd before we can start > adding stuff like this. Agreed. But it would be nice to see the event mechanism in place! Then the rest of us could begin to code up our ideas. This principle seems roughly analogous to, and sympathetic with, other Samba developments, such as the [cascading] VFS structure, and Andrew B's authentication work. I know that Andrew B. (and others?) have doubts about implementing various aspects of this (create/delete "/dev/smb/n"; reading "/dev/smb/n") inside "smbd". I respect their concerns and their experience, and their responsibilities as Samba-maintainers. Could such an event mechanism be somehow linked to a plugin-like mechanism (as with, for example: VFS and authentication)? This would clearly partition the responsibilities (core smbd v. plugin) while maintaining relative ease of implementation, and maximising flexibility. Best wishes. -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. :
Whose kerb and LDAP? [Was: Re: Samba as BDC in windows domain?]
On Tue, 11 Jun 2002, Steve Langasek wrote:
> On Tue, Jun 11, 2002 at 05:05:35PM +0100, David Lee wrote:
> [...]
> > Now... we are contemplating a migration to Active Directory ("AD") of
> > these accounts: some 20,000 or them. (Gives me, as a UNIX person, the
> > shudders, but that's another story...!) One reason is so that the id/pw
> > pair can be a real Windows authentication, so they can do real Windozy
> > things. We are very keen to preserve the "single authentication" model.
>
> > Our plan is to set up accounts for all users in AD. We would then use
> > UNIX password-aging mechanisms to "persuade" all users to change their
> > password "at leisure, in their own time". But behind the scenes we would
> > be using the UNIX PAM module from Microsoft's SFU to copy (synchronise)
> > these password changes out from UNIX into AD. (We'll also be using SFU's
> > corresponding "ssod" daemon for a small number of real-AD folk who might
> > want to maintain synchronisation from AD towards UNIX.)
>
> FWIW, what I'm hearing from the Kerberos world is that it's possible to
> store all of your actual accounts in a traditional Unix KDC, creating a
> trust relationship with your AD server, and still get most of the
> "Windozy" things out of the mix. There's also a PAM module called
> pam_krb5_migrate that can help with this as well, though I've never
> tested it in a Solaris environment. It does at least require an
> MIT-like KDC (Solaris probably qualifies) with matching client libraries
> (kadm5clnt).
>
> Synchronizing passwords via PAM has always been hairy. Migrating to a
> single unified backend such as Kerberos and using that for /all/
> systems, Windows and Unix, is a much more promising long-term solution.
Thanks, Steve.
One thing that didn't come across in my message is that the "synchronising
password" thing is being envisaged only as a temporary (about a year)
thing, not a permanent feature. Currently, authentication is solely UNIX
(NIS). Ultimately it will be solely AD. But we have some 20,000 to
migrate from NIS-authentication to AD-authentication. Naturally we want
this to be as seamless as reasonably possible, both from their user
viewpoint, and our own administrative viewpoint, especially as we'll be
having real AD users very, very soon. Hence our exploring the SFU PAM
module (and "ssod") to synch up the passwords as much as possible during
this interim period.
We also gave much thought to trying to provide an independent solution
(e.g. OpenLDAP and something kerberos-y) for authenticating (etc.) from
both our existing 20,000 NIS environment and the imminent, emerging and
growing AD environment.
But the Windows/PC folk were worried (and I think I share this) about the
ability of AD to interwork (be implemented by?) third party LDAP/Kerberos.
In *theory*, AD is supposed to be compliant with LDAP and Kerberos, isn't
it? But we had nagging doubts about the Microsoft *reality* of this, and
were very concerned that we could end up spending vast amounts of time,
energy and worry, including user frustration etc., chasing the "well it
depends what you mean by compliant" grey areas. (Yes, we been sucked into
the pragmatic realities of selling our soul to Seattle.)
Am I digressing from Samba here? At first sight, yes. But we'll need
Samba to interoperate with this (although concurrent with all this is a
phasing out of the majority of, not all, Samba file-serving as we migrate
to NetApp).
--
: David LeeI.T. Service :
: Systems Programmer Computer Centre :
: University of Durham :
: http://www.dur.ac.uk/t.d.lee/South Road:
: Durham:
: Phone: +44 191 374 2882 U.K. :
Re: Samba as BDC in windows domain?
On Tue, 11 Jun 2002, Paul Reilly wrote:
> I've been reading about setting up Samba as a PDC with LDAP storage.
> However if I am to do this it needs to co-exist with the exisitng windows
> NT domain using windows NT PDC's. Everything I've read so far says you
> can't have a Samba BDC unless it's in a Samba PDC controlled domain. Is this
> correct? Is there *any_possible_way* of having a Samba BDC get SAM updates
> from a windows NT PDC ?
>
> If not, is there any other way to sync an OpenLDAP server against a NT PDC ?
Might be possible, but first the disclaimer...
Disclaimer: I have absolutely zero knowledge of PDC/BDC/NT internals.
Zero, zilch, rein, nothing, nil, nowt, ...
OK...
At our site, we have just started dabbling with a thing called "Microsoft
Services for UNIX" (hereinafter called "SFU") that our PC folk obtained.
Until now, our service has been basically UNIX. Although most of the
user-visible front-end (i.e. desktop machines) is a variant of W2K, the
"real work" has hitherto been UNIX: the identifier and password the user
gives is actually a UNIX pair, used to authenticate their Samba drive from
UNIX. (Behind the scenes on W2K, there was simply a blanket guest-type
login just before this.)
Now... we are contemplating a migration to Active Directory ("AD") of
these accounts: some 20,000 or them. (Gives me, as a UNIX person, the
shudders, but that's another story...!) One reason is so that the id/pw
pair can be a real Windows authentication, so they can do real Windozy
things. We are very keen to preserve the "single authentication" model.
Our plan is to set up accounts for all users in AD. We would then use
UNIX password-aging mechanisms to "persuade" all users to change their
password "at leisure, in their own time". But behind the scenes we would
be using the UNIX PAM module from Microsoft's SFU to copy (synchronise)
these password changes out from UNIX into AD. (We'll also be using SFU's
corresponding "ssod" daemon for a small number of real-AD folk who might
want to maintain synchronisation from AD towards UNIX.)
Our initial, very small, tests look promising.
I've no real idea whether that can map to your environment, but it might
be worth looking at.
Hope that helps.
--
: David LeeI.T. Service :
: Systems Programmer Computer Centre :
: University of Durham :
: http://www.dur.ac.uk/t.d.lee/South Road:
: Durham:
: Phone: +44 191 374 2882 U.K. :
Re: problem samba and overflow root process
On Mon, 10 Jun 2002, Alain Defrance wrote: > i'm using samba Version 2.2.1a with solaris 5.8 > > sometime i have a lot of smbd process own by root (more than 200 !) and > they grow about one by second ! > > i don't understand why !!! > > smbd is lauching by inetd... > have you some ideas ? The earlier versions of Samba 2.2.x had several problems under Solaris. In particular, processes gobbling all available CPU, and the number of processes multiplying to many times what would normally be expected. What you describe is a "well-known problem", experienced at several Solaris sites (ourselves included). These problems have gradually been eliminated in later versions of samba. I would _strongly_ recommend you to move to at least 2.2.3a. Almost certainly you should go further, to 2.2.4 . Hope that helps. -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. :
Re: samba 2.2.5-pre and solaris 9
On Fri, 7 Jun 2002, Gerald Carter wrote: > On Fri, 7 Jun 2002, Toomas Soome wrote: > > > [112] tsoome@muhv:samba/source> gcc --version > > 3.0.2 > > > > [113] tsoome@muhv:samba/source> uname -a > > SunOS muhv 5.9 Generic sun4u sparc SUNW,Ultra-5_10 > > > > ld: Software Generation Utilities - Solaris Link Editors: 5.9-1.343 > > /usr/ccs/bin/ld: illegal option -- E > > usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VY:?] > > file(s) > > > > I added -v to get ld information. > > > > somehow configure set DYNEXP=-Wl,-E in Makefile and this is the source > > of this problem of course. > > Ahh...so its a problem of using gcc with the solaris linker. > I don't know of any way to determine the linker other than some > gross hacks and scripts. Is this really that popular of a > combination? Is it an issue, perhaps, with Solaris *9*'s ld? (This version, 9, of Solaris has just been released within the last week or so.) Toomas: can you do the equivalent with Solaris 8 (and/or 7 and/or 2.6) and contrast with Solaris 9? Gerald: I also have this vague recollection, going back into the dim, hazy and distant past when I used to look after our "gcc" installation, that gcc had a preference for being installed with native as/ld etc. on Solaris. (I may, of course, be entirely wrong here: indeed, I have just done a "gcc -v..." on our current installation (maintained by someone else) and it seems to invoke the GNU ones! Ah well...) Can Dave-CB shed any light on Solaris "ld", including any possible changes in the new Solaris 9? -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. :
smbclient -M : big delays (fwd)
Are we alone with this problem of 15-second "smbclient -M"? Has anyone else seen it? Can anyone confirm it? (Or confirm that it is lightning fast for them, so it must be our problem?) Our clients are W2K. The "About Windows" says: Version 5.0 (Build 2195: Service Pack 1) Our Samba servers (from which we run "smbclient -M") are Solaris 2.7 and 2.8, running a variety of Samba versions (both 2.0.x and 2.2.x). But all consistently give this delay (a 5-second delay at PC-client-end responding to each of the three "SMBsend*" packets from the Solaris/samba server). We're at a complete loss on this one... -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. : -- Forwarded message -- Date: Tue, 2 Apr 2002 12:49:37 +0100 (BST) From: David Lee <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: smbclient -M : big delays Back in the days of 2.2.1a, I noticed a problem using "smbclient -M" to send WinPopup messages from a server (Solaris 2.x) to a client (W2K). But I was unable to pursue it at the time. I have just started looking at this area again, using Samba 2.2.3a, and the problem still seems to be present. Briefly, the symptom is a long delay (pushing 15 seconds) before the message is displayed on the client. Looking more deeply (using "snoop" on the UNIX box to capture the network traffic), what is seen is: 1. rapid exchange of about 6 packets as the session is established (fine). 2. UNIX (smbclient) sends "SMBsendstrt" quickly. -- total elapsed time so far about 0.3 seconds (fine) 3. big delay (~ 5 seconds) before client (W2k) returns the SMBsendstrt acknowledgement (problem). 4. rapid UNIX turnaround to send "SMBsendtxt" (fine). 5. big delay before client (W2K) acknowledges "SMBsendtxt" (problem) 6. rapid UNIX turnaround to send "SMBsendend" (fine) 7. big delay before client (W2K) acknowledges "SMBsendend" (problem). At first sight, the problem appears to lie at the PC/client end, waiting nearly five seconds before acknowledging each of the "SMBsend*" that had come from the UNIX/server. Might this be this a known PC/client/W2K problem? (Testing with non-W2K client-types would be trickly, but possibly do-able if necessary.) Or is it actually a Samba problem? (For instance, are the "SMBsend*" packets improperly constructed (e.g. (speculative) not pushed), leading the PC/client to believe that the packet is, for instance, incomplete.) I've got no experience of programming at the SMB level, so am somewhat lost. But if anyone can reproduce it, and if anyone can help pursue it, I can provide the UNIX "snoop" output. -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. :
Re: Samba 2.2.3a on Solaris 8
On Thu, 18 Apr 2002, Jeremy Allison wrote: > [...] > Ok - discussed this with Andrew last night. It seems that this is only > a problem on Solaris. Solaris seems to have *serious* issues with fcntl > locks with multiple processes contending for locks. No other system we > run on seems to have this problem (they have their own problems :-). Disclaimer: I'm not a Sun sales-droid. Absolutely not. The following is not intended to be Sun "sales-speak" (even if, at initial glance, it might appear to be so). But I wonder whether at least part of the reason this tends only to be seen on Solaris just might be because Solaris is robust and _good_ enough to be pushed so far that it exposes these problems (whereas perhaps other OSes have other problems that kick in before this sort of loading ever arises in the first place). In other words, perverse though it may at first seem, might Solaris sites be seeing this problem because Solaris is a _good_ OS, capable of being pushed to such limits? (Have other OSes stumbled on the lower slopes of the load mountain?) Mere speculation, of course, as our only significant Samba is on Solaris. Straw poll: how many non-Solaris sites exist at all, handling, say, 300+ simultaneous connections, including high smbd turnover? (We are around the 1,000 mark; a typical hour-long "pacct" record contains some 2600 "smbd" processes: in excess of one "smbd" every two seconds *sustained*. That would be quite a load on "connections.tdb", even if it were non-bursty. We had to backtrack to 2.0.x. some months ago: prudence and politics prevent us risking moving forwards again.) > Dave CB - can you investigate this within Sun please. This is a *critical* > part of Samba, we may have to look into a solaris-specific workaround and > this would be bad. Any thoughts, Dave (CB), with your inside knowledge of Sun? (Technics and politics!) If there is a Sun bug, it would be good to get this at least recognised, and preferably fixed. And if there were a patch, then we could quickly knock up some "configure.in" stuff to detect the presence/absence of the relevant patch and perhaps issue suitable warning messages. (Or even a run-time detection, with a warning in "log.smbd"?) -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. :
Re: [PATCH] Cascaded VFS for HEAD [v0.1]
On Thu, 11 Apr 2002, Alexander Bokovoy wrote: > Attached you'll find first part of cascaded VFS interface for Samba 3.0 > which I'll present and discuss more deeply at SambaXP. > > Prime intention for this release is to provide other developers with > reference implementation for better testing and interface stabilisation. > > I'll provide more documentation later, for beginning, look into > examples/VFS/ and source/include/vfs.h for comments. > > What works: > > - module stacking; > - VFS operation overloading with different levels of visibility > of underlying functions; > - module initialization/shutdown tracking; > - interface expansion with backward compatibility. This all sounds most promising. Thanks for your work on this. > Modules are specified in smb.conf using following syntax: > > vfs object = module1 module2 ... modulen > > Modules are loaded from left to right, making 'modulen' the topmost of > stack and module1 at bottom, just above standard Samba POSIX VFS module > which is built in. Can you clarify about order please? If I'm configuring a Samba server for our users, I envisage a data path starting at their PC/client and ending at the filesystem on the Samba/UNIX (or similar) machine. So I would naturally envisage that the data would arrive from the PC/client at module_1, then battle its way through the remaining modules towards module_n and (if all modules have succeeded) be passed into the UNIX servers filesystem. In other words, I would expect the datapath from PC/client to samba/filesystem to traverse "vfs object = ..." in the same order that we humans read that line. But you seem to suggest the reverse: that the data path goes backwards along that line as we read it (PC/client data arrives first at module_n). Have I mis-understood? Perhaps a distinction is needed between "loaded" and "data processed"? It may be (I don't know) that VFS, as an internal detail, needs to load the modules in the reverse order to that which the PC-to-server datapath flows. But my gut feeling is that the line "vfs object = ..." ought to mean PC/client at left-hand end, Samba/UNIX/filesystem at right-hand end. Hope that helps. -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. :
