25 Sep
2002
25 Sep
'02
1:06 p.m.
Am Mit, 2002-09-25 um 00.55 schrieb Andrew Bartlett:
Firstly, it's good to see that winbind is starting
to get some interest
:-)
I have been ignoring it so far, but in the context of the current
inquiries I tried it out and was impressed :-)
Secondly, don't fall into the trap squid (with my
encouragement I might
add...) fell into - don't use the winbind pipe directly. The winbind
API is an internal Samba API, and can change without warning.
Hmm - what other APIs are there?
The only libraries that are accessible are nss_winbind and pam_winbind.
Those two already carry us a long way, BUT ...
I started thinking about other options when I found the "wbinfo -n"
call. AFAIK there is no way to obtain equivalent info through PAM/NSS,
simply because these APIs have no concept of a SID. Obviously apart from
the SID there is a lot more information to gather from a PDC. I have not
digged deeply enough into this to be able to enumerate everything, but
think of the different GetUserInfo() calls on NT.
libsmbclient can't be used by wine because it's GPL. And even if we
could use it, it's headers only define calls related to shares and
printing, which is not what I'm currently aiming at.
As to unicode, I
have designated one call as being in utf8, to cope with external
interaction, so it's possible things can happen here.
What matters to wine is that if a call goes like this:
Windows app <-> wine <-> PAM or other API <-> winbind <-> RPC
<-> Windows server,
we must ensure that the Unicode string wine receives from the app
reaches the server ungarbled.
Martin
--
Martin Wilck Phone: +49 5251 8 15113
Fujitsu Siemens Computers Fax: +49 5251 8 20409
Heinz-Nixdorf-Ring 1 mailto:[email protected]
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
25 Sep
25 Sep
3:17 p.m.
New subject: Using winbind with Wine
On Wed, Sep 25, 2002 at 03:06:05PM +0200, Martin Wilck wrote:
Am Mit, 2002-09-25 um 00.55 schrieb Andrew Bartlett:
Seems like you'd like to see one more library as winbind's companion.
However, if libsmbclient is licensing stumbling block, then similar
situation may happen with such winbind's library :(
Besides, I'm not sure whether designing another library is ``the good
way out''.
--
cheers,
+------------------------------------------------------------+
|Rafal 'Mimir' Szczesniak <mimir(a)diament.ists.pwr.wroc.pl> |
|*BSD, GNU/Linux and Samba /
|__________________________________________________________/
As to unicode, I
have designated one call as being in utf8, to cope with external
interaction, so it's possible things can happen here.
What matters to wine is that if a call goes like this:
Windows app <-> wine <-> PAM or other API <-> winbind <-> RPC
<-> Windows server,
we must ensure that the Unicode string wine receives from the app
reaches the server ungarbled. 
5:38 p.m.
New subject: Using winbind with Wine
On Wed, 25 Sep 2002, Rafal Szczesniak wrote:
On Wed, Sep 25, 2002 at 03:06:05PM +0200, Martin Wilck
wrote:
I do not think that libsmbclient is the right way to do this. I think that
the correct way is to make the various Samba client RPC libaries available
as separate DSOs so that clients can make dirrect use of what they need.
Then the wine group can possibly build a thing DLL wrapper around the
underlying RPC libraries.
Regards
-----
Richard Sharpe, rsharpe(a)ns.aus.com, rsharpe(a)samba.org,
sharpe(a)ethereal.com
Am Mit, 2002-09-25 um 00.55 schrieb Andrew
Bartlett:
Seems like you'd like to see one more library as winbind's companion.
However, if libsmbclient is licensing stumbling block, then similar
situation may happen with such winbind's library :(
Besides, I'm not sure whether designing another library is ``the good
way out''. As to unicode, I
have designated one call as being in utf8, to cope with external
interaction, so it's possible things can happen here.
What matters to wine is that if a call goes like this:
Windows app <-> wine <-> PAM or other API <-> winbind <-> RPC
<-> Windows server,
we must ensure that the Unicode string wine receives from the app
reaches the server ungarbled.
4:30 p.m.
New subject: Using winbind with Wine
On Thu, Sep 26, 2002 at 03:08:29AM +0930, Richard Sharpe wrote:
On Wed, 25 Sep 2002, Rafal Szczesniak wrote:
AFAIK, that's where we go ie. separate ms-rpc layer. It won't happen
tomorrow, anyway.
--
cheers,
+------------------------------------------------------------+
|Rafal 'Mimir' Szczesniak <mimir(a)diament.ists.pwr.wroc.pl> |
|*BSD, GNU/Linux and Samba /
|__________________________________________________________/
Seems like you'd like to see one more library
as winbind's companion.
However, if libsmbclient is licensing stumbling block, then similar
situation may happen with such winbind's library :(
Besides, I'm not sure whether designing another library is ``the good
way out''.
I do not think that libsmbclient is the right way to do this. I think that
the correct way is to make the various Samba client RPC libaries available
as separate DSOs so that clients can make dirrect use of what they need.
Then the wine group can possibly build a thing DLL wrapper around the
underlying RPC libraries.
26 Sep
26 Sep
11:47 a.m.
New subject: Using winbind with Wine
Am Mit, 2002-09-25 um 19.38 schrieb Richard Sharpe:
I do not think that libsmbclient is the right way to
do this. I think that
the correct way is to make the various Samba client RPC libaries available
as separate DSOs so that clients can make dirrect use of what they need.
Then the wine group can possibly build a thing DLL wrapper around the
underlying RPC libraries.
Licensing is an important issue.
I future Samba RPC libraries come with GPL, they won't be usable for
Wine (as you probably know, Wine is LGPL and ReWind X11). I don't want
to start a licensing debate here. I expect the Samba team to release
their stuff GPL'd in the future, thus I accept is as a fact that Wine
cannot be linked to Samba libraries, present or future.
For that reason I find the winbind concept of socket communication
attractive. To my understanding this would not raise license issues. We
are not currently worried about performance, we just need access to a
few RPC calls.
To initiate this process we'd "only" need a standardized protocol for
the socket communication. Andrew said that doesn't exist and won't with
regard to winbind. I'd like to focus the discussion in this direction.
- is the winbind team willing to standardize the protocol, or at least
ensure backward compatibility in future versions?
- is the winbind team willing to add more RPC calls to the interface?
If not, Wine might do best by creating a "winebind" that meets these
requirements. That might be the best way after all, because
incorporating the functionality needed by Windows clients into winbind
would make no sense in environments where Wine is not running, just
increase winbind's size unnecessarily.
"winebind" would be linked against Samba libraries, and therefore be GPL
from the start.
Martin
--
Martin Wilck Phone: +49 5251 8 15113
Fujitsu Siemens Computers Fax: +49 5251 8 20409
Heinz-Nixdorf-Ring 1 mailto:[email protected]
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
12:18 p.m.
New subject: Using winbind with Wine
Imho the best way to go, is to wait until we will be able to provide an
interface for loadable modules in samba that couples with the MS-RPC
subsystem.
At that point you will only need to make the .so library as GPL and
build your socket mechanism to speak to the other LGPLed end integrated
into wine.
Simo.
On Thu, 2002-09-26 at 13:47, Martin Wilck wrote:
Am Mit, 2002-09-25 um 19.38 schrieb Richard Sharpe:
--
Simo Sorce - simo.sorce(a)xsec.it
Xsec s.r.l.
via Durando 10 Ed. G - 20158 - Milano
tel. +39 02 2399 7130 - fax: +39 02 700 442 399
I do not think that libsmbclient is the right way
to do this. I think that
the correct way is to make the various Samba client RPC libaries available
as separate DSOs so that clients can make dirrect use of what they need.
Then the wine group can possibly build a thing DLL wrapper around the
underlying RPC libraries.
Licensing is an important issue.
I future Samba RPC libraries come with GPL, they won't be usable for
Wine (as you probably know, Wine is LGPL and ReWind X11). I don't want
to start a licensing debate here. I expect the Samba team to release
their stuff GPL'd in the future, thus I accept is as a fact that Wine
cannot be linked to Samba libraries, present or future.
For that reason I find the winbind concept of socket communication
attractive. To my understanding this would not raise license issues. We
are not currently worried about performance, we just need access to a
few RPC calls.
To initiate this process we'd "only" need a standardized protocol for
the socket communication. Andrew said that doesn't exist and won't with
regard to winbind. I'd like to focus the discussion in this direction.
- is the winbind team willing to standardize the protocol, or at least
ensure backward compatibility in future versions?
- is the winbind team willing to add more RPC calls to the interface?
If not, Wine might do best by creating a "winebind" that meets these
requirements. That might be the best way after all, because
incorporating the functionality needed by Windows clients into winbind
would make no sense in environments where Wine is not running, just
increase winbind's size unnecessarily.
"winebind" would be linked against Samba libraries, and therefore be GPL
from the start.
Martin
--
Martin Wilck Phone: +49 5251 8 15113
Fujitsu Siemens Computers Fax: +49 5251 8 20409
Heinz-Nixdorf-Ring 1 mailto:[email protected]
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
2:50 p.m.
New subject: Using winbind with Wine
- is the winbind team willing to standardize the
protocol, or at least
ensure backward compatibility in future versions?
Rather than inventing new protocols, why not just use DCE RPC over domain
sockets or TCP/IP?
The only catch is that you need a DCE RPC client library. We're using the
OSF DCE runtime (actually, FreeDCE), which is BSD-licensed.
We are doing a similar thing, except in reverse, so that SAMBA can act as
a named pipe front-end to our proprietary DCE RPC services. More
information is at http://www.padl.com/Research/XAD.html.
-- Luke
--
Luke Howard | PADL Software Pty Ltd | www.padl.com
3:38 p.m.
New subject: Using winbind with Wine
On Fri, Sep 27, 2002 at 12:50:57AM +1000, Luke Howard wrote:
Because DCE/RPC is *horrible* ? :-) :-). If you need a new
RPC protocol please use ONC/RPC/NDR not DCE :-).
Jeremy.
- is the winbind team willing to standardize the
protocol, or at least
ensure backward compatibility in future versions?
Rather than inventing new protocols, why not just use DCE RPC over domain
sockets or TCP/IP?
The only catch is that you need a DCE RPC client library. We're using the
OSF DCE runtime (actually, FreeDCE), which is BSD-licensed.
3:42 p.m.
New subject: Using winbind with Wine
Because DCE/RPC is *horrible* ? :-) :-). If you need a
new
RPC protocol please use ONC/RPC/NDR not DCE :-).
I agree, I think I've grown a few gray hairs from DCE. I guess
the argument in favour of it depends on how similar the kinds
of lookups WINE needs to make are to existing, implemented,
RPCs. If there isn't much overlap then yes, choosing DCE RPC
doesn't buy you much in terms of reduced amounts of code on
the server.
-- Luke
--
Luke Howard | PADL Software Pty Ltd | www.padl.com
10:16 p.m.
New subject: Using winbind with Wine
On Thu, Sep 26, 2002 at 01:47:38PM +0200, Martin Wilck wrote:
To initiate this process we'd "only"
need a standardized protocol for
the socket communication. Andrew said that doesn't exist and won't with
regard to winbind. I'd like to focus the discussion in this direction.
- is the winbind team willing to standardize the protocol, or at least
ensure backward compatibility in future versions?
There is a LGPL client library (well library is probably doing it more
justice than it deserves) called wb_client.c which is used in the
NSS modules that talk to winbindd. I would think that would be a
preferable way of talking to winbindd rather then rewriting code
to talk the winbindd protocol.
- is the winbind team willing to add more RPC calls
to the interface?
Not unless they are related to authentication or user/group enumeration.
"winebind" would be linked against Samba
libraries, and therefore be GPL
from the start.
Heh - cute name. (-:
Tim.
27 Sep
27 Sep
12:34 a.m.
New subject: Using winbind with Wine
Tim Potter wrote:
Agreed. (However I am thinking of moving nss_wins in there soon too, to
match the IRIX code).
Andrew Bartlett
--
Andrew Bartlett abartlet(a)pcug.org.au
Manager, Authentication Subsystems, Samba Team abartlet(a)samba.org
Student Network Administrator, Hawker College abartlet(a)hawkerc.net
http://samba.org http://build.samba.org http://hawkerc.net
On Thu, Sep 26, 2002 at 01:47:38PM +0200, Martin Wilck wrote:
The problem is that we don't ship it as a shared lib, and it still
expects the client program to fill in the winbind struct. This is the
problem, becouse that struct changes shape regularly.
To initiate this process we'd
"only" need a standardized protocol for
the socket communication. Andrew said that doesn't exist and won't with
regard to winbind. I'd like to focus the discussion in this direction.
- is the winbind team willing to standardize the protocol, or at least
ensure backward compatibility in future versions?
There is a LGPL client library (well library is probably doing it more
justice than it deserves) called wb_client.c which is used in the
NSS modules that talk to winbindd. I would think that would be a
preferable way of talking to winbindd rather then rewriting code
to talk the winbindd protocol. - is the
winbind team willing to add more RPC calls to the interface?
Not unless they are related to authentication or user/group enumeration.
23 Oct
23 Oct
11:45 a.m.
New subject: What I need (was Re: Using winbind with Wine)
First of all thanks everybody for the feedback.
It seems that Wine/Samba integration will not be a solution for general
Wine RPC, at least not in the short term.
However I have determined the functionality I need and I think most of
it can be implemented on top of existing winbind functionality as I
originally intended.
These are the functions I need:
LogonUser(ADVAPI32) - can be done through pam_winbind to authenticate
against PDC
NetGroupGetUsers - Can be implemented with nss_winbind's getgrent()
NetGroupGetInfo - Also getgrent() (?)
NetLocalGroupGetMembers - Hmm - I don't think Windows' local/global
group distinction makes sense on Unix -
windbind looks for global groups, I suppose?
NetGetDCName - Get name of primary domain controller -
seems to be the most difficult part.
Could be solved by simply looking it up in the
Samba config file.
This approach means that the respective functions are not really carried
out as Windows RPCs - for example the "servername" argument to these
functions will be ignored because I cannot tell winbind on which server
to execute its RPC.
Even if wine had a fully-fledged RPC implementation I doubt that would
be reasonable to implement these functions on top of that, because
groups and users really need to be mapped to their Unix equivalents.
Comments welcome!
Martin
Martin Wilck Phone: +49 5251 8 15113
Fujitsu Siemens Computers Fax: +49 5251 8 20409
Heinz-Nixdorf-Ring 1 mailto:[email protected]
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
25 Sep
25 Sep
3:34 p.m.
New subject: Using winbind with Wine
I started thinking about other options when I found the
"wbinfo -n"
call. AFAIK there is no way to obtain equivalent info through PAM/NSS,
simply because these APIs have no concept of a SID. Obviously apart from
the SID there is a lot more information to gather from a PDC. I have not
digged deeply enough into this to be able to enumerate everything, but
think of the different GetUserInfo() calls on NT.
I suspect those calls on NT ultimately call into the LSA. Sounds like it
would be good if you could make RPCs to SAMBA without having to wrap them
in SMB, ie. over something equivalent to ncalrpc (aka LPC on NT).
What matters to wine is that if a call goes like this:
Windows app <-> wine <-> PAM or other API <-> winbind <-> RPC
<-> Windows server,
we must ensure that the Unicode string wine receives from the app
reaches the server ungarbled.
You could use UTF-8 if you are forced through C string API.
-- Luke
--
Luke Howard | PADL Software Pty Ltd | www.padl.com
7866
days inactive
7894
days old
12 comments
8 participants
participants (8)
-
Andrew Bartlett -
jra＠dp.samba.org -
Luke Howard -
Martin Wilck -
Rafal Szczesniak -
Richard Sharpe -
Simo Sorce -
Tim Potter