>> The problem is performance. While Samba is not terribly slow it's still >> too slow. Copying large files takes about half a minute/meg on an > >i find that samba running on FreeBSD is also pathetically slow: 10 to 20 >k per second. adding "socket options = TCP_NODELAY" speeds this up by a >factor of ten to twenty, on a 10mb/s LAN with NE2000 cards. it hammers >the server, because it too only has an NE2000, but who cares :-)Hmmm, I hadn't had any problem's w/ my FreeBSD 2.2.2-RELEASE Samba, running on 100Mhz pentium, EZ2000 nic's thru xover cable to NT4SP3, also EZ2000 - copying a 7.4Mb .gz file from FreeBSD share to NT, using dos box 'copy' takes 30 seconds ( 15mb/min, 250Kb/sec) timed w/ stopwatch. Using smbclient to copy back to FreeBSD got 814Kb/sec (48 Mb/min) as reported by smbclient. --------------------------------- Why did the chicken cross the road? To show the o'possum it could be done. Chuck cswiger@widomaker.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 1941 bytes Desc: not available Url : http://lists.samba.org/archive/samba/attachments/19971209/5d896edd/attachment.bin
On Wed, 10 Dec 1997, Chuck Swiger wrote:> > >> The problem is performance. While Samba is not terribly slow it's still > >> too slow. Copying large files takes about half a minute/meg on an > > > >i find that samba running on FreeBSD is also pathetically slow: 10 to 20 > >k per second. adding "socket options = TCP_NODELAY" speeds this up by a > >factor of ten to twenty, on a 10mb/s LAN with NE2000 cards. it hammers > >the server, because it too only has an NE2000, but who cares :-) > > Hmmm, I hadn't had any problem's w/ my FreeBSD 2.2.2-RELEASE Samba, running on 100Mhz > pentium, EZ2000 nic's thru xover cable to NT4SP3, also EZ2000 - copying a 7.4Mb .gz file from > FreeBSD share to NT, using dos box 'copy' takes 30 seconds ( 15mb/min, 250Kb/sec) timed > w/ stopwatch. Using smbclient to copy back to FreeBSD got 814Kb/sec (48 Mb/min) as reported > by smbclient.we're using FreeBSD-2.1-STABLE. don't ask me why: i have no idea: it fell off the back of a sunsite, four months ago. do you think it's time to upgrade again (previous version was one from two and a half years ago...) luke <a href="mailto:lkcl@switchboard.net" > Luke Kenneth Casson Leighton </a> <a href="http://mailhost.cb1.com/~lkcl"> Samba Consultancy and Support </a>
On 8 Dec 1997, Luke Kenneth Casson Leighton wrote:> On 8 Dec 1997, Stefan Nehlsen wrote:> > 1. Making "nis homedir (G)" work with NIS+. > > if you explain to me how it works, i will look at it.This should be pretty easy and shouldn't take too long to implement.> > 2. Mapping the smbpasswd file to a NIS+ table. (Does this really > > make sense?)I've actually done this. The code is currently in what you could call beta state and i plan to do a few cleanups, especially in the code for the smbpasswd command. The logic for accessing NIS+ tables and files isn't quite the same. I've been running it on a few testservers for a month or so with no problems. You can find a patch to 1.9.17p4 at ftp://ftp.hgs.se/pub/unix/sun/nis+/samba-nis+_smbpasswd.tar.Z> yes it does, except remember that the stupid microsoft idiots (who caused > us to have to create the smbpasswd file by using 16 byte password hashes) > forgot to make their password algorithm a one-way comparison system. > > in other words, the 16 byte hashes are clear-text equivalent. storing > them in a NIS+ table is therefore not a particularly good idea, unless > you add a level of obfuscation (oh dear, i've done it now: mentioning > obfuscation. i hate obfuscation. i can't even pronounce it). > distribution).NIS+ is not like NISv2 in the way that anyone can read anything so the crucial issue here is to keep the table permissions strict. I'm sure there are ways to bypass security in NIS+ as well but it's probably just as easy/hard to hack root access on a machine in which case you can read the smbpasswd file anyway. What I did was to create a table called smbpasswd. I also created a special NIS+ group which I populated with the Samba servers. The 16 bytes hash values in that table can only be read by it's owner and the group. Every row is then owned by the user it refers to and the group is the special samba group. This means only the owner of the row and the group members (the samba servers) can access the hash fields. Anyone else will see *NP* instead. The result is as long as you keep the permissions strict this NIS+ approach should be as secure as NIS+ itself. If you don't trust NIS+ enough for your site you shouldn't use this patch (and probably not any MS products either). If you feel I missed something out securitywise, please tell me. Cheers, Benny -- Benny Holmgren email: benny@hgs.se University College of Gavle/Sandviken. phone: +46-(0)26-648887 Sweden mobile: +46-(0)70-6338298