SoC/Ideas: Difference between revisions

From SambaWiki
Line 109: Line 109:


===Improved async/vectored i/o support (improves performance)===
===Improved async/vectored i/o support (improves performance)===
* add ability for cifs to issue calls in parallel and handle read/write responses asynchronously. Here's how JLayton envisions this, but there may be other ways to do it:
* add ability for cifs to issue calls in parallel and handle read/write responses asynchronously. Here's how JLayton envisions this, but there may be other ways to do it, there ar some other concerns to consider as well:
** generalize callback mechanism for cifsd when it receives a response. Instead of just waking up a process, it could do more to handle a SMB response.
** generalize callback mechanism for cifsd when it receives a response. Instead of just waking up a process, it could do more to handle a SMB response.
** cifs_writepages sends write requests serially now. It should instead issue the requests rapid-fire. Don't wait for the response from the previous request before sending another.
** cifs_writepages sends write requests serially now. It should instead issue the requests rapid-fire. Don't wait for the response from the previous request before sending another.

Revision as of 14:47, 20 March 2010

Google Summer of Code: Suggested Project ideas

The following are the Samba project ideas for Summer of Code. Of course you are free to come up with ideas not listed here. Please discuss the your planned project by either joining us on irc://irc.freenode.net/#samba-technical or by sending email to samba-technical@samba.org

Most of our projects will require C programming skills, but the Samba4 section has a couple of Python projects.

Samba 3

Add remote (RPC) support for Samba configuration

Since recently, Samba has a registry based configuration backend: Configuration data is stored inside the registry key HKEY_LOCAL_MACHINE\Software\Samba\smbconf. Access to this configuration is available through a module that makes use of the "reg_api" interface which is similar to the winreg API. This project would at first develop a common api for registry access local through reg_api and remote through the winreg rpc client code. This new module could be abstraced from the code of the utility "net rpc registry". With this new module, the registry configuration code could be enhanced to allow for remote configuration.

  • Difficulty: Medium
  • Language(s): C
  • Possible Mentors: Michael Adam


Remove use of unexpected.tdb

Current Samba 3 contains the unexpected.tdb as a mechanism to pass UDP packets coming in on ports 137 and 138 to interested client applications. This mechanism needs to be replaced by a unix domain socket on which nmbd offers a lightweight RPC interface to send and receive nmb name service packets and send and receive mailslot requests.

  • Difficulty: Hard
  • Language(s): C
  • Possible mentors: Volker Lendecke


Make SWAT for Samba3 pretty

SWAT is the Samba Web Administration Tool, written in 1998. It still looks very 1998 as well. SWAT should get a complete redesign to match what people expect from a web application these days. The code running the web front-end will certainly need to be adapted as well. It might be viable to completely reimplement SWAT as a standalone web-app, if the current code cannot be adapted to support all features needed with a reasonable effort.

  • Difficulty: Medium
  • Language(s): JavaScript, C / possibly other language.
  • Possible mentors: Kai Blin

Samba 4

Admin Utilities

We still need a few more Samba4-specific administration utilities to make Samba4 useful in real life. A Summer of Code student would be expected to do a number of these (identifying new needs from deployments), but here are some suggestions:


Extension of the GTK+ frontends

There are a couple of GTK+ frontends for Samba4 (see SambaGtk). These are very limited at the moment but you could work on expanding them and further integrating them with GNOME. Language: C or Python

  • Difficulty: Easy
  • Language(s): Python, perhaps C
  • Possible mentors: JelmerVernooij

Setup / provision GUI for Samba (and OpenChange)

Setting up Samba and OpenChange currently requires running quite a lot of command line utilities. It should be easy for even a junior system administrator to set up Samba as a Domain Controller, RODC and general server.

The windows equivalent tool is dcpromo.exe, and while you may not want/need to copy it directly, it does provide a reasonable basis for establishing what this tool should be able to provide (in terms of outcomes).

Some initial work (using PyQt4) is available at http://gitorious.org/samba-openchange-gui-tools/samba-openchange-gui-setup but working with that is not essential to this task.

  • Difficulty: Easy
  • Language(s): Python
  • Possible mentors: Brad Hards, probably others.


Windows Search Protocol WSP client library and torture tests

The Windows Search Protocol WSP is used to implement remote full filesystem indexing (indexed search) between windows machines. We would like to support this functionality in Samba, interfacing with existing indexing tools on Unix systems (such as beagle).

This is a new protocol based on SMB named pipes \pipe\ci_skads or \pipe\MSFTEWDS. See http://msdn2.microsoft.com/en-us/library/cc216195.aspx.

The student should write a (un)marshalling library to push and pull PDUs and an async client library on top of the samba4 raw smb client library.

The student should write sub tests for smbtorture which should demostrate how the protocol works against a windows server.

The student doesn't have to implement the samba4 server code.

  • Difficulty: Hard
  • Language(s): C, (Python?)
  • Possible Mentors: Tridge

Browsing support in Samba 4

Samba 4 still needs support for mailslots in general and in particular for the BROWSE mailslot. Should come with tests. Documentation of the BROWSER protocol is available here: http://msdn.microsoft.com/en-us/library/cc201609(PROT.10).aspx http://ubiqx.org/cifs/Browsing.html

  • Difficulty: Hard
  • Language(s): C
  • Possible mentors: JelmerVernooij, Stefan Metzmacher

Linux Kernel CIFS/SMB2 client improvements

Interested students should contact Steve French or Jeff Layton and discuss possible improvements to the Linux Kernel CIFS VFS client. Here are some ideas to get you started:

Improved async/vectored i/o support (improves performance)

  • add ability for cifs to issue calls in parallel and handle read/write responses asynchronously. Here's how JLayton envisions this, but there may be other ways to do it, there ar some other concerns to consider as well:
    • generalize callback mechanism for cifsd when it receives a response. Instead of just waking up a process, it could do more to handle a SMB response.
    • cifs_writepages sends write requests serially now. It should instead issue the requests rapid-fire. Don't wait for the response from the previous request before sending another.
    • when sending these requests, set it up so that cifsd will handle the response itself. As long as it doesn't block, it should be ok to have cifsd mark the pages clean, etc. Alternately, the write response handling could be offloaded to a workqueue or something.
    • this will allow cifs_writepages to return w/o waiting for a response when we're writing in the background (WB_SYNC_NONE case).
    • consider how to handle reconnection events, canceling requests, lack of server response, etc.
    • readpages could probably also use similar handling.
    • You might also consider merging write requests, etc. (similar to how NFS handles this)
    • should we move to an unstable pages model (like NFS)?
  • Language: C
  • Difficulty: Hard
  • Possible Mentors: Jeff Layton or Steve French

Create GUI or command-line tools for displaying /proc/fs/cifs statistics and and mount/session status

  • might also involve some cleanup of the in-kernel stats / status output
  • Language: some C (for kernel code), something else for GUI?
  • Difficulty: Easy
  • Possible Mentors: Steve French

Create a common uid mapping mechanism for Linux nfs and cifs vfs clients

  • or maybe just figure out a way to hook cifs up to rpc.idmapd
  • add a way for the client to remap the uids returned by the server to uids which would be valid on the client (or to a default if such uid does not exist).
  • This is helpful especially when the server supports the CIFS Unix Extensions and has different uids and gids mapping than the client
  • Difficulty: Hard
  • Possible Mentors: Jeff Layton or Steve French

VFS change notification support

  • add VFS support for calling into the filesystem when setting up notifications
  • add code to cifs/smb2 to set up and deal with notifications from the server in response to inotify/dnotify calls
  • Difficulty: Hard
  • Possible Mentors: Jeff Layton or Steve French

Integration of CIFS/SMB2 client with fscache

  • allows offline caching of files on the client
  • maybe also consider some disconnected operation
  • Difficulty: Hard
  • Possible Mentors: Jeff Layton or Steve French

Overhaul reconnection behavior

  • based on "serial numbers" rather than the complex flags that we have today
  • maybe also use sk_state_change callback from socket layer
  • Difficulty: Medium/Hard
  • Possible Mentors: Jeff Layton

Support for retrieving snapshots, encrypted files, or compressed files from Windows

  • Difficulty: Hard?
  • Possible Mentors: Steve French

cifs->Samba automated test facility

  • Do build verification similar to what we can now do with the Samba server and tools in the Samba build farm
  • Difficulty: Hard
  • Possible Mentors: Jeff Layton or Steve French

build infrastructure for storing NTLM creds in kernel keyring

  • so that the kernel can establish sessions on the fly without needing to prompt for passwords
  • Difficulty: Medium
  • Possible Mentors: Jeff Layton

Other Random Ideas

  • Ideas aren't limited to these, feel free to propose something else:
    • Prototype SMB2 client -- seems unfeasible for GSoC project
    • Create a GUI for creating and managing Linux cifs mounts, and more easily configuring the many complex cifs mount options -- doesn't seem very useful since it'll have to run as root. Will also quickly go out of date
    • Support for alternate transport protocols (other than TCP sockets) -- is there server support for this?
    • Support for features (such as directory delegations) which NFS version 4.1 has but which current CIFS even with the most current CIFS->Samba protocol extensions (CIFS Unix Extensions) do not have -- will probably need server support too.
  • Difficulty: Varies
  • Language(s): C
  • Possible mentors: Steve French