> From: Chris Weiss [mailto:cwe...@gmail.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 > <pdero...@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.
Obviously, there's a lot I don't understand about the guts of Samba. But it seems a shame that if we want simple file sharing, we need to add nearly a hundred megabytes of code. Your comment about using FTP or HTTP is true, but it's sometimes it's more useful to be able to open files directly on a remote server, rather than having to copy them in and out. -- Ciao, Paul D. DeRocco Paul mailto:pdero...@ix.netcom.com -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
