From rfunk Sun Sep 27 21:42:31 1998 Date: Sun, 27 Sep 1998 21:42:31 -0400 To: colug@bopper.wcbe.org Subject: Re: [COLUG] File Ownerships References: <Pine.3.07.9809272152.A7052-9100000@login> In-Reply-To: <Pine.3.07.9809272152.A7052-9100000@login>; from Ryan Bagueros on Sun, Sep 27, 1998 at 09:13:52PM -0400 Ryan Bagueros wrote: >Hi... I was wondering if someone could explain to me the ins and outs and >whys of assigning ownership of a file to 'nobody'? The way you do it is >create a user called nobody (what group?) and assign them a uid of 65354 >or -2 ... but what utility does this serve? I saw this done somewhere but >cannot figure why. Perhaps a referral to somewhere else that could explain >this in more detail. Simple: Don't do it. The nobody user (which should already exist on your system) is intended for processes that shouldn't have any privileges. Giving nobody files to own gives privileges to nobody, since the file owner can do things to that file. (BTW, there's usually also a special group (probably "nogroup" or "nobody") that only nobody belongs to.) Sometimes files will exist owned by nobody because they were created via NFS by root on the NFS client; by default, NFS maps root on the client to nobody on the server so that the client doesn't have root power on the server. This is the main use of nobody, and arguably the only valid one on an NFS server. Of course, when you have more than one thing using nobody to own processes, nobody gains power over all those things, so many daemons use their own userid, rather than climbing on the nobody bandwagon. This is where you get users like lp, mail, news, uucp, ftp, http, postgres, and sybase. The best place to go on this topic (and related issues) is probably "Practical Unix & Internet Security", 2nd ed., by (I think) Simson (or Spafford?) and Garfinkel, published by O'Reilly. Highly recommended reading for all Unix sysadmins (which includes anyone running their own Linux machine).
From rfunk Mon Dec 28 11:47:38 1998 Subject: Re: [COLUG] Comments on the best Network File System? In-Reply-To: <36879E80.D7742C75@osu.edu> from Jeremy Kuhnash at "Dec 28, 98 11:06:40 am" To: colug@bopper.wcbe.org Date: Mon, 28 Dec 1998 11:47:38 -0500 (EST) Jeremy Kuhnash wrote: >What is the best overall Network File System for use with Linux and the >rest of the world. Or maybe even just Unix Variants and the rest >(supposing that there are clients for any given OS like Nt,95,Os/2) Personally, I'd use NFS to share with local Unix machines under the same administration. I'd use SMB to share with Windows machines (maybe OS/2?). I'd block both at the closest router practical. Rationale: if you have your choice at the server, use the native protocol of the client. I'd use NCP if there were already netware clients or servers around, but otherwise I don't touch it. >1) SMB > Cons -- Who wants to use SMB for real networks? > Gossip of security/speed issues. Speed is good (compared to NFS at least). Security depends on the configuration, but can be made reasonably secure. Not many Unices work well as an SMB client; Linux does though. >The first thing to remember is that NFS is a slow protocol. It has > high overhead. Using NFS is almost like using kermit to transfer > files. It's slow. Almost anything is faster than NFS. FTP is > faster. HTTP is faster. rcp is faster. ssh is faster. > >Agreed he is talking over slow lines. Is it better over a Lan?? It's fine over ethernet. It's best if you can do NFS3 (Linux can't). It's very slow and/or unreliable at some forms of file locking (but that's something you have to look at with the other options too). Linux doesn't make a good NFS server compared to other Unices; it is supposed to be better in 2.1/2.2, but I hear they've given up on NFS3 until 2.3. >-- How much does increased bandwidth help?? (Compare 10/100) The more bandwidth you have, the less network efficiency matters. At 100Mb, you can concentrate entirely on compatibility issues. >-- If you had a specific instance like only WinNT machines talking to >Unix whats best. SMB. >-- What about many different OS's? I use the native protocol of the client, so that only the server needs special configuration, not each desktop. If I have both Unix and Windows clients, I run both NFS and SMB on the server.
From owner-colug@bopper.wcbe.org Sat Jan 23 11:46:42 1999 From: rfunk@wks.uts.ohio-state.edu (Rob Funk) Subject: Re: [COLUG] NFS -- whoa, it is slow... In-Reply-To: <36A5990D.89957613@osu.edu> from Jeremy Kuhnash at "Jan 20, 99 03:51:25 am" To: colug@bopper.wcbe.org Date: Wed, 20 Jan 1999 10:27:58 -0500 (EST) Jeremy Kuhnash wrote: >As an after thought -- do any of the BSD's to your knowledge offer better NFS >performance on the server side?? or is it actually a lack of performance with >server AND client?? (Yes, Id be willing to fire up NetBSD or FreeBSD jsut for the >NFS server) BSD would definitely be better for the NFS server. If it can do NFS3, it *might* be better for the client too, but that's less clear. Linux's NFS problem is really the server. I used to have a Sun Sparc 2 (compare with a fast 386 or slow 486 for processor speed, but faster I/O) running SunOS 4.1.3_U1, serving half a dozen or so NFS clients. Its load average was routinely 4-12, and performance was noticeably bad at the client. I upgraded it to a Sun UltraSparc 1 (compare with maybe a PPro for proc speed) running Solaris 2.6 (which can do NFS3, unlike SunOS 4). Now it barely notices all the NFS clients, only a couple of which are using NFS2. >> Linux doesn't make a very good NFS server, though 2.1/2.2 is supposed >> to improve things. If you can run 2.1/2.2 on both ends, you should be >> able to get NFS version 3, which is faster. I found this link at Sun about NFS performance, including improvements in NFS v3. Somewhere around there I thought I saw a white paper just on NFS3, but I can't find it now. http://www.sun.com/software/white-papers/wp-nfs/nfs_12.html Also, this was in an article talking about improvements from Solaris 2.4 to 2.5 ([2.]7 is current): |The default NFS read and write transfer size for NFS V2 has been 8KB |since it was introduced. NFS V3 defaults to 32KB, and defaults to |TCP/IP to make reliable delivery of this long train of Ethernet |packets more efficient. The NFS operation mix measured by the LADDIS |NFS V2 benchmark is also now about 10% faster than before.