[nflug] NFS isn't (all) bad.
Justin Bennett
justin.bennett at dynabrade.com
Thu Apr 27 21:31:15 EDT 2006
I understand your security concerns, NFS is not a protocol I would use
over public networks. I would only use it on a trusted LAN, if you catch
someone hacking your NFS on your local LAN, it's a violation of our HR
policies, and you fire them. Any protocols over your LAN have the
potential be insecure, even passing encrypted passwords over the wire,
if your not running switched can be an issue. Do we really think CIFS is
secure?
In practice NFS over a LAN works well, I understand the UDP could be a
concern on paper, but if your loosing UDP packets then you have more
important problems with your LAN. I haven't experienced any locking
issues and/or corruption in the 4-5 years we've been running NFS in a
production environment on a daily basis.
I think your third point is getting into what Mark was talking about,
file sharing vs mounting volumes. For transfering files (as in
downloading) sftp will work fine I use it a lot even over my LAN to grab
a file on another machine, but if your looking to remote mount a home
directory it's a different story (all though you can get kernel modules
to do this via ftp/sftp, It's not a out of the box option, and I'm not
sure It's production quality).
Just my opinion
Justin
Justin Bennett
Network Administrator
Dynabrade Inc.
Clarence, NY
716-631-0100
Dennis Ruzeski wrote:
> No, it isn't all bad, but neither is M$ Windoze.
>
> Here's my issues with nfs and why I avoid it whenever possible.
>
> 1- Security. If you take a look at CERT or SANS advisories pertaining
> to *nix systems, NFS and it's dependencies (portmap and rpc) have
> almost as many advisories as Bind and Sendmail..
>
> 2- UDP. That means connectionless protocol. If I'm moving critical
> data, I want to make sure it gets there and I don't want to deal with
> file and mount point locking wierdness and corrupted data.
>
> I want a secure, reliable transport for my files.. I'll hold out to
> try nfs4. In the meantime, if the server has ssh and you have
> Konqueror on your desktop, try fish. It gives you drag and drop
> capabilities and uses ssh as a transport mechanism. If you want to do
> something out of cron or on a command line, I use tar and ssh to move
> data
> ( tar cf - /source/data | ssh name at hostname.com
> <mailto:name at hostname.com> tar xf - -C /destination/data )
>
> That said, if you want to use NFS make sure you bump up your tx and rx
> buffers and some of the other ip parameters in /etc/sysctl.conf and
> increase your tx queue length. That'll help performance.
>
>
> Thanks and let's not let this turn into a flame war.
>
> --Dennis
>
>
>
>
>
>
> On 4/27/06, *James Wenzel* <jmwenzel at yahoo.com
> <mailto:jmwenzel at yahoo.com>> wrote:
>
>
> Hello,
>
> > If anyone knows a
> > better way that's more efficient, uses less CPU and
> > is easier to do,
> > please respond.
>
> Use Window$
>
> :)
>
> Jamie
>
> --- "David J. Andruczyk" < djandruczyk at yahoo.com
> <mailto:djandruczyk at yahoo.com>>
> wrote:
>
> > Date: Thu, 27 Apr 2006 14:47:43 -0700 (PDT)
> > From: "David J. Andruczyk" < djandruczyk at yahoo.com
> <mailto:djandruczyk at yahoo.com>>
> > To: nflug at nflug.org <mailto:nflug at nflug.org>
> > Subject: [nflug] NFS isn't (all) bad.
> >
> > There's been a statement put up by an individual
> > "That NFS is bad, I
> > won't use it, it's so out-dated and so full or
> > problems" and so on.
> > The thread started because someone was having some
> > NFS issues and it
> > related to a mail server and mail spools or homedirs
> > residing on an NFS
> > mount and some difficulty arrived. I presented a
> > tiny bit of evidence
> > about NFS performance as did some others about it's
> > merits. The
> > response I got seemed completely off topic, so I
> > wanted to show some
> > examples where NFS is used in the corporate world,
> > and if it's not
> > considered optimal, I'd like to see a "better way"
> > to do it. AS I'm
> > always looking to learn new stuff.
> >
> > Example 1. NFS for remote bootable clients.
> > Lets say you have a school. Schools are notoriously
> > low budget , thanks
> > to many things these days, so some places are
> > turning to using thin
> > clients in their computer labs, and Linux is ideally
> > suited for the
> > task (free, easy to configure, very flexible, wide
> > variety of
> > choices/applications). You have a stack of old PC's
> > (let's day
> > PII-400's), you have next to no budget for any
> > replacement parts like
> > disks and half your machiens are in the 5-8 year old
> > range and have
> > dead drives, what to do? Remote boot them, either
> > via a etherboot
> > floppy, or via a PXE Nic to a central cerver, using
> > software like
> > PXE's, LTSP (Linux Term Server Project), or Knoppix
> > Terminal server.
> > It's simple, but all of them rely on NFS as shared
> > filesystem, why?
> > because it's
> > 1. Clean (simple to setup)
> > 2. Easy
> > 3. Built into the OS distribution,
> > 4. (optional, not always used) The kernel can
> > directly use a NFS
> > filesystem for it's root FS, it cannot do this with
> > ANY other network
> > filesystem without patching of the kernel (which is
> > hard for someone
> > who hasn't done it before)
> >
> > Without using NFS these projects would be stunted
> > and held back. NFS
> > (as far as I can see it) is the optimal tool for the
> > job in the above
> > case.
> >
> > 2. Corporate home dirs (unix shop).
> > One of the places I worked (Valeo, Rochester, 4+
> > years) was a mixed bag
> > shop, windows AD, Unix, Linux etc. They had a
> > large number of unix
> > users, about 130 spread across two locations across
> > a WAN link (SGI's
> > mostly, though some HP and linux) All of the Unix
> > hosts made use of
> > shared storage locations available via NFS from a
> > Network Appliance
> > Filer (big fileserver appliance that was used fot
> > NFS and samba). The
> > users used it for homedirs, application dirs,etc and
> > even mounted
> > locations from over 250miles away (detroit area) via
> > NFS over the WAN
> > link, and it worked flawlessly.
> >
> > 3. Small business backup server
> > Another place I've doen a little helping out from
> > time to time, is
> > asuccessfull computer business, They have a server
> > with a bunch of
> > disk tucked away in some hidden part of their
> > office, and a full
> > netwrok throughout. All servers backup to it via a
> > cron job dump based
> > system (using "dump" to dump to files stored on the
> > NFS server). It
> > work great, is fast, allows easy recovery anyplace
> > on the LAN and keeps
> > things centralized. NFS in this case makes the
> > filesystem essentially
> > transparent. They have a large pool of diskspace
> > that can be mounted
> > anywhere anytime on the LAN.
> >
> > 4. Remote server installation
> > I had to do an install of 9 mid-High end Linux
> > servers (4-16CPU, up to
> > 64GB ram boxes) as part of my current job earlier
> > this month. They're
> > a Redhat Enterprise shop, and I was limited by them
> > to using an older
> > version (EL3) Their constraints were simple. Get it
> > done fast, and get
> > it done right. IT helped that they required minimal
> > customization. The
> > fastest way I know to get a RH Box built is by using
> > Kickstart, and a
> > remote boot. Remote boot wasn't possible for their
> > datacenter, as
> > DHCP/Bootp was not allowed, so I used the floppy
> > method (faster than
> > burning up custom CD's) Also note that these servers
> > were located north
> > of Boston Mass, and I was still in buffalo and
> > everything needed to be
> > done via remote. (had a guy onsite to insert
> > floppies for initial
> > bootup). A NFS server was setup (super EASY), as
> > every linux box that
> > had it installed via default as it was IN USE there.
> > The ISO images for
> > RHEL3 was put in place as well as kickstart config
> > files tailored to
> > each machine. I had a tech boot the machines off of
> > floppy, while I
> > watched them through a remote IP KVM (two disks were
> > needed to do the
> > NFS boot (the drive disk was necessary for gigabit
> > ethernet support).
> > From the point where the second floppy was read and
> > the install started
> > to the time it finished and the machine was ready to
> > reboot took 13
> > minutes installing via NFS. It installed about 3GB
> > worth of data, so it
> > wasn't an "everything" install. Yes I could have
> > done an FTP or HTTP
> > install, but those require significant more setup
> > time, as there were
> > not FTP servers or http servers available for use
> > for that task, but
> > nearly ever unix/linux box in the datacenter (and
> > there's about 185
> > systems in there) could have been used for NFS.
> >
> > Hope you all enjoyed my long winded uses of NFS. If
> > anyone knows a
> > better way that's more efficient, uses less CPU and
> > is easier to do,
> > please respond.
> >
> > So NFS is used in the real world, even though it's
> > been around a long
> > time (which is a GOOD thing), it's alive and well,
> > and has more uses
> > than you might think.
> >
> > Apologies for all the spelling and gramatical
> > errors.
> >
> > -- David Andruczyk
> > Unix/Linux Systems Administrator
> > IBM Global Services
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam
> > protection around
> > http://mail.yahoo.com
> > _______________________________________________
> > nflug mailing list
> > nflug at nflug.org <mailto:nflug at nflug.org>
> > http://www.nflug.org/mailman/listinfo/nflug
> >
>
> _______________________________________________
> nflug mailing list
> nflug at nflug.org <mailto:nflug at nflug.org>
> http://www.nflug.org/mailman/listinfo/nflug
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> nflug mailing list
> nflug at nflug.org
> http://www.nflug.org/mailman/listinfo/nflug
>
_______________________________________________
nflug mailing list
nflug at nflug.org
http://www.nflug.org/mailman/listinfo/nflug
More information about the nflug
mailing list