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
On Wed, Sep 25, 2002 at 03:06:05PM +0200, Martin Wilck wrote:
Am Mit, 2002-09-25 um 00.55 schrieb Andrew Bartlett:
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.
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''.
On Wed, 25 Sep 2002, Rafal Szczesniak wrote:
On Wed, Sep 25, 2002 at 03:06:05PM +0200, Martin Wilck wrote:
Am Mit, 2002-09-25 um 00.55 schrieb Andrew Bartlett:
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.
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.
Regards ----- Richard Sharpe, rsharpe@ns.aus.com, rsharpe@samba.org, sharpe@ethereal.com
On Thu, Sep 26, 2002 at 03:08:29AM +0930, Richard Sharpe wrote:
On Wed, 25 Sep 2002, Rafal Szczesniak wrote:
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.
AFAIK, that's where we go ie. separate ms-rpc layer. It won't happen tomorrow, anyway.
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
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:
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:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
- 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
On Fri, Sep 27, 2002 at 12:50:57AM +1000, Luke Howard wrote:
- 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.
Because DCE/RPC is *horrible* ? :-) :-). If you need a new RPC protocol please use ONC/RPC/NDR not DCE :-).
Jeremy.
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
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.
Tim Potter wrote:
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.
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.
- is the winbind team willing to add more RPC calls to the interface?
Not unless they are related to authentication or user/group enumeration.
Agreed. (However I am thinking of moving nss_wins in there soon too, to match the IRIX code).
Andrew Bartlett
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:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
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
-
Andrew Bartlett -
jra＠dp.samba.org -
Luke Howard -
Martin Wilck -
Rafal Szczesniak -
Richard Sharpe -
Simo Sorce -
Tim Potter