samba - Jul 2013 - Does anyone think a mini-Samba server would be useful?

I'm working on a couple of Yocto Project based embedded projects, one using
a Gumstix Overo board and the other using an Intel Atom motherboard. Both
need a simple Samba server, which isn't included in the standard build. The
only existing Yocto-compatible recipe for Samba is an OpenEmbedded one for
version 3.6.8. I was quite surprised to find that adding Samba almost
tripled the size of my Atom build. I understand that version 4 is quite a
bit smaller, but we're still talking many tens of megabytes of stuff.

I would think there would be lots of people in my boat, who are doing
embedded systems and who would like to include a really simple SMB file
server. For instance, a data acquisition system needs to record large
amounts of data to a local disk, and then provide access to it over a
network so people can bring it into Matlab or other tools. A CNC machine
tool system needs a way to have Gerber or other files loaded into them. A
media server needs to be able to serve up video or audio files. Any embedded
device needs to have a way of being fed configuration data, or having its
firmware upgraded.

The requirements for such a system are much smaller than what Samba
provides:

* It only needs to serve files, not printers or other resources.

* It doesn't need a client, or any of the functionality related to a client.

* It doesn't need to deal with domains, let alone be a domain controller.

* It doesn't need to provide separate user accounts.

* The only security it needs is perhaps a password for reading, and maybe a
different password for writing.

* Since these devices are generally closed boxes with no general-purpose
command line interface, there's no need to encrypt passwords internally.

* It can assume it's being connected to a fully functional network, so
doesn't need to be a master browser.

* It doesn't need to support multiple interfaces.

* Its only configuration parameters would be a machine name, workgroup name,
list of shared folders, and one or two passwords per shared folder.

* It doesn't need most of the command line tools currently used to
configure, monitor and debug the system.

Sounds to me like the sort of thing that could be done in under a megabyte.

I wonder if there's a way to build such a mini-Samba out of the existing
Samba code base. It's certainly way above my abilities, but it may be
something that someone on the Samba team could do without mounting a major
development effort. How many other people would find such a system useful?

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco at ix.netcom.com

I'll bite...

smb/cifs is not a simple protocol suite, see my comments in-line

On Wed, Jul 24, 2013 at 1:19 PM, Paul D. DeRocco <pderocco at
ix.netcom.com> wrote:
> The requirements for such a system are much smaller than what Samba
> provides:
>
> * It only needs to serve files, not printers or other resources.
smb without an AD domain needs rpc and for network browsing nmb.
> * It doesn't need to deal with domains, let alone be a domain
controller.
smb namespacing (for lack a better word) effectively treats a single
standalone PC as a domain.  I know this is
over-simplification/generalization...
>
> * It doesn't need to provide separate user accounts.
I guess you could compile it so that it only anon connections are
used, but cifs still has to deal with users
>
> * The only security it needs is perhaps a password for reading, and maybe a
> different password for writing.
cifs doesn't do this.  the old smb version that win95 used can, but
modern OS's don't like talking to them.
>
> * Since these devices are generally closed boxes with no general-purpose
> command line interface, there's no need to encrypt passwords
internally.
smb/cifs expect a challenge/response hash system.  if you store only
plain text on the server, you'd have to generate the hash every time
to want to have auth.
>
> * It can assume it's being connected to a fully functional network, so
> doesn't need to be a master browser.
>
it still has to participate or you won't be able to browse to it.
> I wonder if there's a way to build such a mini-Samba out of the
existing
> Samba code base. It's certainly way above my abilities, but it may be
> something that someone on the Samba team could do without mounting a major
> development effort. How many other people would find such a system useful?
what you want as an end product is totally possible, and practical.
It may even be feasible to make a bare cifs server that can't be
browsed and you have to connect to by IP, but I don't think most
people expect this.  Basing it off the existing samba codebase is
probably going to be a lot more work than just writing it from
scratch.  Maybe a few methods or classes can be pulled from samba as a
start.  maybe.

however, all the use cases you've mentioned can be accomplished via
ftp or http, for which there are a few light weight server options
already and all OS's already include clients for.

On Wed, Jul 24, 2013 at 1:19 PM, Paul D. DeRocco <pderocco at
ix.netcom.com> wrote:
> I wonder if there's a way to build such a mini-Samba out of the
existing
this is interesting...
https://code.google.com/p/impacket/source/browse/#svn%2Ftags%2Fimpacket_0_9_10%2Fexamples%2Fsmbserver

> From: Ben Metcalfe [mailto:bwmetcalfe at gmail.com] 
> 
> How about Webdav? Yocto supports Java:
> 
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-oracle-java/tree/README
> 
> so Miltion.io java webdav may work?
> 
> 40-70 Mb for the JRE but only a couple of Mb more for the 
> milton IO Webdav server: 
> 
> http://milton.io/downloads/index.html
Well, that would be nice if I already needed Java. Interesting.

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco at ix.netcom.com

On Wed, 2013-07-24 at 11:19 -0700, Paul D. DeRocco
wrote:
> I'm working on a couple of Yocto Project based embedded projects, one
using
> a Gumstix Overo board and the other using an Intel Atom motherboard. Both
> need a simple Samba server, which isn't included in the standard build.
The
> only existing Yocto-compatible recipe for Samba is an OpenEmbedded one for
> version 3.6.8. I was quite surprised to find that adding Samba almost
> tripled the size of my Atom build. I understand that version 4 is quite a
> bit smaller, but we're still talking many tens of megabytes of stuff.
> 
> I would think there would be lots of people in my boat, who are doing
> embedded systems and who would like to include a really simple SMB file
> server. For instance, a data acquisition system needs to record large
> amounts of data to a local disk, and then provide access to it over a
> network so people can bring it into Matlab or other tools. A CNC machine
> tool system needs a way to have Gerber or other files loaded into them. A
> media server needs to be able to serve up video or audio files. Any
embedded
> device needs to have a way of being fed configuration data, or having its
> firmware upgraded.
> 
> The requirements for such a system are much smaller than what Samba
> provides:
> 
> * It only needs to serve files, not printers or other resources.
> I wonder if there's a way to build such a mini-Samba out of the
existing
> Samba code base. It's certainly way above my abilities, but it may be
> something that someone on the Samba team could do without mounting a major
> development effort. How many other people would find such a system useful?
One thing we have found when developing Samba is that very quickly we
find that one thing depends on another.  It isn't easy to 'just do the
basics'.  Indeed, the AD DC isn't actually that large, compared with so
much else that we need.

That isn't to say that for example printing comes free - and I think
there even is an option to disable that code - but a 'cut down samba'
isn't free either.  Much of the bulk comes from library code we have
come to depend on across the whole sever.

Andrew Bartlett
-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Catalyst IT                   http://catalyst.net.nz