smbsh/smbwrapper/winbind linux help

[David Collier-Brown]

"Stieglitz, Eric J. (DCSA)" wrote:
>   Thanks for your offer of assistance.
>   Basically, smbsh fails with error EINVAL after it tries to exec
> my shell using the shared library functions in smbwrapper.so. The
> details to this can be found in a previous message here:
> 
> http://lists.samba.org/pipermail/samba-technical/2002-June/037344.html
> > http://lists.samba.org/pipermail/samba-technical/2002-June/037683.html

	Two-part discussion: fcntl64 and library linking.
	Let's do fcntl first.
> 
> I've also noticed that the file include/includes.h may define all
> instances of "fcntl" as "fcntl64". Despite this, an strace while running
> smbsh shows that sometimes fcntl is executed as "fcntl" and othertimes
> it executes as "fcntl64". Neither of us are experienced systems programmers,
> so we're not sure if this is normal behavior or not. The defines in the
> include file are:
> 
>         #ifdef GLIBC_HACK_FCNTL64
>         /* this is a gross hack. 64 bit locking is completely screwed up on
>            i386 Linux in glibc 2.1.95 (which ships with RedHat 7.0). This hack
>            "fixes" the problem with the current 2.4.0test kernels
>         */
>         #define fcntl fcntl64
>         #undef F_SETLKW
>         #undef F_SETLK
>         #define F_SETLK 13
>         #define F_SETLKW 14
>         #endif

	That's a likely culprit: if you have both fcntl; and fcntl64
	showing up in strace, you may need to check this is turned
	on in each of the smbwrapper files.

> 
> According to Redhat,
> 
> " It's the back door symbols _open, _read, _write which allows smbsh to wrap around the normal file calls, possibly redirect them to smb, and then call the actual C library function using the
> underscore functions.
> The GNU C library maintainers have decided to remove support for these symbols in glibc 2.1and forward."


	This is a different issue: it should not affect
	you unless you call dlsym on them, which is not
	how smbwrapper works.

> 
> At this point, we're basically trying to figure out whether or not it's actually
> possible to get smbsh to work reliably on Linux the same way it does on Solaris.
> Chris and I have pretty much hit the limits of what we know how to do and debug
> on this (in fact, I can say that I've certainly learned more about the internals
> of samba while trying to read the code :-) and would appreciate any assistance
> from somebody more knowledgable about smbsh and the OS.

	Lets see if we can get fcntl64 to show up
	everywhere in smbsh's strace,
	then look at the code in lockit to see
	why the operations on fd 8191 fail...
	it is open at that point, isn't it???

--dave
	

	

	
> 
> /EJS
> 
> -----Original Message-----
> From: David Collier-Brown [mailto:davecb at canada.sun.com]
> Sent: Wednesday, June 26, 2002 9:43 AM
> To: Johnston, Christopher (DCSA)
> Cc: 'samba-technical at samba.org'
> Subject: Re: smbsh/smbwrapper/winbind linux help
> 
> > "Johnston, Christopher (DCSA)" wrote:
> > Was curious.. does smbsh work in Linux.. I am having all sort of
> > compilation issues with file locking.. I understand there was a bug in
> > glibc 2.1 which caused havok with 64 bit locking.. I assume that has
> > been fixed by now since I am running the latest and greatest glibc..
> >
> > Redhat 7.3
> > Glibc 2.2.5
> > Samba 2.2.5
> 
>         It did run once, but subsequently had problems
>         with the glibc folks: at one point they actually
>         seemed to think smbsh was a bad idea (;-))
> 
>         In principle, there is nothing in Linux that
>         should stop smbsh: I use exactly the same calls
>         in my Linux as my Solaris interceptors[1].
>         And I'd love to see smbsh universally available[2]!
> 
>         What's the symptoms? How can  we help?
> 
> --dave
> [1. I'm a former member of the ABI team at Sun, write lots
>    of interceptors, and have given Linux talks on the
>    technology
>  2. I think HP may have had a related problem, but I haven't
>     looked lately: anyone tried it???]
> --
> David Collier-Brown,           | Always do right. This will gratify
> Performance & Engineering      | some people and astonish the rest.
> Americas Customer Engineering, |                      -- Mark Twain
> (905) 415-2849                 | davecb at canada.sun.com

-- 
David Collier-Brown,           | Always do right. This will gratify 
Performance & Engineering      | some people and astonish the rest.
Americas Customer Engineering, |                      -- Mark Twain
(905) 415-2849                 | davecb at canada.sun.com