New Proxy Unix CAP

[James Peach]

On 18/04/2008, at 7:44 PM, Sam Liddicott wrote:

> * Steve French wrote, On 18/04/08 23:26:
>>
>> Sam Liddicott who I think is the guy who gave the WAFS talk at  
>> SambaXP
>> could give more details.
>>
>
> Hi James,
>
> The historic thread is here:
> http://lists.samba.org/archive/samba-technical/2008-January/ 
> 057155.html
>
> - where we discussed the need to provide a means whereby two Samba  
> proxies could support additional operations in support of caching/ 
> proxying/read-ahead and other beneficial WAN-optimising operations.

Is this intended to be an open protocol extension that other SMB  
vendors would implement? If so, could you please add documentation to <http://wiki.samba.org/index.php/UNIX_Extensions 
 >, or a page that is linked from there.

> The conclusion was that ntioctl was the cleanest way to provide that  
> channel (allowing windows server based implementations through  
> pluggable ioctl handlers), and all that remained was to find a way  
> to advertise the capability.
>
> A conversation at SambaXP with Metze, Steve, Tridge concluded that  
> the new "who am I" and the "extattr" operations set a good precedent  
> for using the unix capabilities bit and a new info level in the unix  
> capabilities to advertise the proxy capabilities (I think I got that  
> mostly right). (And a different advertisment method would be needed  
> for a windows implementation but Tridge knew what that was, I forget).
>
> The actual operations and their definitions are quite fluid at the  
> moment but the current definitions can be had at:
> http://repo.or.cz/w/Samba/vfs_proxy.git?a=blob;f=source/librpc/idl/proxy.idl;h=f54c5ac8ecd24d01c01de64db6e5502218b0598c;hb=v4-0-vfs-proxy

So each proxy operation maps to an ioctl operation? Or does the ioctl  
interface simple do transact/read/write?

> You will see that currently there is defined is an extended read and  
> extended write operation that make use of cache and compression  
> between proxies to avoid sending the full read response where  
> possible.
>
> There are no stricter definitions or specifications and that  
> interface will change in the near future to include different cache- 
> based compression techniques;

I'm guessing that the ioctl interface you define is a multiplexor? In  
that case, you should add an operation that allows capability  
negotiation or versioning so that you don't need to burn an more UNIX  
capability bits when your feature set changes.

> but a review of the irc comments by samjam and the mailing list  
> posts of Amin Azez will reveal a lot more on the subject. The  
> SambaXP slides ought to be up text week sometime I suppose.

Any idea whether there will be audio or video available?