samba - Dec 1999 - Comments request to refute arguments about Samba...

I can't answer any of this, but the following was taken from a thread on
the "Novell Technology Transfer Partners List
<NOVTTP@LISTSERV.SYR.EDU>" and passed over to me by my boss...

Any comments/refutations/etc most definitely accepted...

Please note that *I'm* the Senior Unix Systems Administrator at the
University I work at, and have been moving us towards Samba since I
started here 2 years ago, with very successful results...but, I have a
Novell/Netware department to fight against that uses whatever ammo *they*
can come up with to dispute it...:(

Pointers to web pages would help, as well as comments about what is said
below, especially that first one...

Thanks....

=====================
        Samba is an implementation of old Lan Manager stuff. For a listing
of what real Lan Man did/does a reference is "Microsoft Lan Manager,
Programmer's Reference", MS Press, was $40.

        With Lan Man one has groups, and groups, and uncounted more
groups.

	They use the word "shares" these days. And the wire is cheerfully
busy with NetBIOS vintage traffic, making bridging a must. Management is
equally delightful, especially security.

        So if 1980 technology is good enough then use Samba. Think small,
don't interact, that's the stuff.

        An oh by the way on Solaris. Unless those machines are fully
patched and carefully sealed off then the bad guys will feast on them and
all machines they can reach via packet snoop programs. We have had a very
bad time with that part of things and the problems are not over.

======================
I understand, Joe. That's why I am asking for ammo.

Our UNIX Sysadmin does a good job with Solaris. Does SAMBA open up other
security holes ?

"Think small" is an unlikely reason that I can present to a VP. (not
if I
want to keep my job)

======================
There has been serious exploration of SAMBA as replacement for Netware by
the Systems Group here at UK. Right now, they are testing a "Student
Locker" system using SAMBA. It isn't widely in use yet, but results
have
been promising (I guess). One concern has been the amount of RAM needed
for each SAMBA connection. On the test machine, SMB connections are using
~3MB/connection. At that rate, we'd need about 3GB of RAM to accomodate
our ~1000 machines.


Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org

|Samba is an implementation of old Lan Manager stuff. For a listing
| of what real Lan Man did/does a reference is "Microsoft Lan Manager,
| Programmer's Reference", MS Press, was $40.

	Very much obsolete... known as "CORE" protocol, and
	no longer used.

| With Lan Man one has groups, and groups, and uncounted more groups.
| They use the word "shares" these days.

| And the wire is cheerfully busy with NetBIOS vintage traffic, making
| bridging a must. Management is equally delightful, especially
security.

	Not with Samba, which is TCP/IP and a bit of UDP.
	There are fewer broadcasts, too, notably when you're
	using a WINS (windows name service) server.

	Security is marginally better than ftp: passwords
	may be encrypted, but data flows in the clear.

| So if 1980 technology is good enough then use Samba. Think small,
| don't interact, that's the stuff.

	Interworks between PC/MT, Mac (dave) and Unix (samba).
	Works reasonably across subnets (TCP is routable), but
	not as aware of the network as AFS ("a nation-wide remote
	file system")

| An oh by the way on Solaris. Unless those machines are fully
| patched and carefully sealed off then the bad guys will feast on
them and
| all machines they can reach via packet snoop programs. We have had a
very
| bad time with that part of things and the problems are not over.

	True of all servers, with the possible exception of one of
	the BSDs.  I'm running Trusted Solaris, in part because of
	that, on a test system.  It's a military-grade os...

| Our UNIX Sysadmin does a good job with Solaris. Does SAMBA open up
other
| security holes ?  

	Not on the server, but running smb clients on PCs makes
	them attackable, as does running NFS clients, AFS clients, 
	etc ad infinitum.


| There has been serious exploration of SAMBA as replacement for
Netware by
| the Systems Group here at UK. Right now, they are testing a "Student
| Locker" system using SAMBA. It isn't widely in use yet, but results
have
| been promising (I guess).

	That's very sane: students tend to stress systems to the limit (;-))

|  One concern has been the amount of RAM needed for each SAMBA
connection.
| On the test machine, SMB connections are using ~3MB/connection. At
that
| rate, we'd need about 3GB of RAM to accommodate our ~1000 machines.

	That's a semi-famous misnomer: the shared libraries and
	executables are counted once for each child process.

	You really need 
		1 * binary
		1 * shared library code
		n * data
		n * stack
	and filesystem data buffers.

	The latter are both dynamic and large: I usually recommend
	1/2 MB per active child process, where active means "currently
	reading or writing".  Inactive processes end up paging their
	data and stack out, so they require 0 MB (;-))

	It's important to be running "priority paging" on Solaris for
	loads of more than 300 active clients: it's stock on Solaris
	7 and an option for  2.5.1 and 2.6.


	For 1000 (hyper?) active PCS, all logging on at the same time, 
	you'd  probably need on the order of .5 GB of memory and
	1000 MB/S throughput.  That's 160 100baseT ethernets, 47 CPUS
	and 1,785 disks. This may be a bit more load than you really
	need to support!  I suspect it might be larger than the competing
	system...

	A more credible approach is to measure a system and see
	what your user base requires. If you know the number of active
	users and their approximate throughput demands on the current
	system, start doing your sizing from that.

	Similarly, if you have access to the  student locker system, you 
	can  collect some real numbers with a few scripts: send me mail!

--dave
[The calculations above are from

http://www.oreilly.com/catalog/samba/chapter/book/appb_03.html#appb-98866
]
-- 
David Collier-Brown,  | Always do right. This will gratify some people
185 Ellerslie Ave.,   | and astonish the rest.        -- Mark Twain
Willowdale, Ontario   | //www.oreilly.com/catalog/samba/author.html
Work: (905) 415-2849 Home: (416) 223-8968 Email: davecb@canada.sun.com

The Hermit Hacker said:
>         Samba is an implementation of old Lan Manager stuff. For a 
> listing of what real Lan Man did/does a reference is "Microsoft Lan 
> Manager, Programmer's Reference", MS Press, was $40.
>
>         With Lan Man one has groups, and groups, and uncounted more 
> groups.
Well we have 20,000 users, 40+ active Samba servers and 1 workgroup
(and of course no browsing).  NBT alluded to below means workgroups can span 
subnets.
> 	They use the word "shares" these days. And the wire is
cheerfully
> busy with NetBIOS vintage traffic, making bridging a must. Management 
> is equally delightful, especially security.
Samba does not work with vanilla unroutable NetBEUI, but with NBT (ie NetBIOS 
encapsulated over TCP - thus routable).  Using WINS (which Samba can provide) 
broadcast traffic can be reduced.
>         So if 1980 technology is good enough then use Samba. Think 
> small, don't interact, that's the stuff.
Well we are not a small site and use Samba successfully for home directories 
and applications servicing of NT machines (3,000+).
Also SMB is what is out there on PCs right now and while it has 80's origins
(as does Netware) it is evolving!
>         An oh by the way on Solaris. Unless those machines are fully 
> patched and carefully sealed off then the bad guys will feast on them 
> and all machines they can reach via packet snoop programs. We have 
> had a very bad time with that part of things and the problems are not 
> over.
Well these days Solaris is reasonably well secured - all OS makers have woken 
up to varying extents to security needs - even Microsoft.
> There has been serious exploration of SAMBA as replacement for 
> Netware by the Systems Group here at UK. Right now, they are testing 
> a "Student Locker" system using SAMBA. It isn't widely in use
yet,
> but results have been promising (I guess). One concern has been the 
> amount of RAM needed for each SAMBA connection. On the test machine, 
> SMB connections are using ~3MB/connection. At that rate, we'd need 
> about 3GB of RAM to accomodate our ~1000 machines.
We have found that by trimming the smb.conf file we can get down to .75Mb for 
each connection - but this depends on what you are doing.

Finally a little ref for what we have done:

http://www.brunel.ac.uk/~peter/samba/

I hope to update when we have upgraded to 2.0.6 (from 1.9.18p10), as we have 
taken various measures to improve performance eg avoid AMD!
-- 
-----------------------------------------------------------------------------
| Peter Polkinghorne, Computer Centre, Brunel University, Uxbridge, UB8 3PH,|
| Peter.Polkinghorne@brunel.ac.uk   +44 1895 274000 x2561       UK          |
-----------------------------------------------------------------------------

Hermit,

recompile with no CFLAGS -g options.  do a strip bin/smbd.  you will find
that exexcutable reduces to about 600 / 800k.

you are probably currently compilng with -g or even -g -g, which results
quite frequently in a 3mb to 5mb executable.

luke (samba team)