FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 06-04-2011, 05:33 PM
"John A. Sullivan III"
 
Default Samba or NFS

On Fri, 2011-06-03 at 23:08 -0400, Nico Kadel-Garcia wrote:
> On Fri, Jun 3, 2011 at 11:08 AM, Dan <ganchya@gmail.com> wrote:
> > Hi,
> >
> > I have two linux servers. One file server (debian) that is running
> > samba and one application server (redhat). I would like to mount the
> > shares of the file server in the application server. The problem is
> > that the usernames are very different. Samba is already running and
> > easier to set-up. NFS seems to be more difficult to set-up and also
> > there are more security issues.
> >
> > Which are the advantages of NFS over Samba (cifs) other than the
> > symbolic links. I read that even some people prefer samba over NFS to
> > connect Unix to Unix.
> >
> > Thanks,
> > Dan
>
> CIFS clients mishandle mixed case filenames, such as 'file.txt",
> "FILE.txt", and "FILE.TXT". They also have a massively different idea
> of how file ownership and privileges work than the POSIX standards
> built into most UNIX and Linux native filesystems. And while I very
> much applaud the work of the Samba team for providing this
> cross-compatibility tool, it performs like a *dog* compared to NFS,
> AFS, ZFS, or the other more powerful network based fileysstems.
>
> NFS needs some attention to security: so does CIFS. But most of the
> complexities CIFS does more trivilally, such as mixed group ownership,
> can be resolved with tools built into NFS such as "netgroups" suport.
> And holy moley, but the speed of simple network operations like
> Subversion checkouts is *grotesquely* faster under NFS.
>
>
Interesting and helpful. I was always under the impression that NFS was
oodles faster than CIFS after one adjusted rsize and wsize to something
much larger than the defaults. However, one of our engineers recently
tweaked SAMBA to use similarly large block sizes and it seems to have
narrowed the gap. I did not take the time to actually measure so this
is only anecdotal. Has anyone had any similar or contrary experiences?
- John


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1307208780.20855.8.camel@denise.theartistscloset.c om">http://lists.debian.org/1307208780.20855.8.camel@denise.theartistscloset.c om
 
Old 06-04-2011, 07:27 PM
Nico Kadel-Garcia
 
Default Samba or NFS

On Sat, Jun 4, 2011 at 1:33 PM, John A. Sullivan III
<jsullivan@opensourcedevel.com> wrote:
> On Fri, 2011-06-03 at 23:08 -0400, Nico Kadel-Garcia wrote:
>> On Fri, Jun 3, 2011 at 11:08 AM, Dan <ganchya@gmail.com> wrote:
>> > Hi,
>> >
>> > I have two linux servers. One file server (debian) that is running
>> > samba and one application server (redhat). I would like to mount the
>> > shares of the file server in the application server. The problem is
>> > that the usernames are very different. Samba is already running and
>> > easier to set-up. NFS seems to be more difficult to set-up and also
>> > there are more security issues.
>> >
>> > Which are the advantages of NFS over Samba (cifs) other than the
>> > symbolic links. I read that even some people prefer samba over NFS to
>> > connect Unix to Unix.
>> >
>> > Thanks,
>> > Dan
>>
>> CIFS clients mishandle mixed case filenames, such as 'file.txt",
>> "FILE.txt", and "FILE.TXT". They also have a massively different idea
>> of how file ownership and privileges work than the POSIX standards
>> built into most UNIX and Linux native filesystems. And while I very
>> much applaud the work of the Samba team for providing this
>> cross-compatibility tool, it performs like a *dog* compared to NFS,
>> AFS, ZFS, or the other more powerful network based fileysstems.
>>
>> NFS needs some attention to security: so does CIFS. But most of the
>> complexities CIFS does more trivilally, such as mixed group ownership,
>> can be resolved with tools built into NFS such as "netgroups" suport.
>> And holy moley, but the speed of simple network operations like
>> Subversion checkouts is *grotesquely* faster under NFS.
>>
>>
> Interesting and helpful. *I was always under the impression that NFS was
> oodles faster than CIFS after one adjusted rsize and wsize to something
> much larger than the defaults. *However, one of our engineers recently
> tweaked SAMBA to use similarly large block sizes and it seems to have
> narrowed the gap. *I did not take the time to actually measure so this
> is only anecdotal. *Has anyone had any similar or contrary experiences?
> - John

These are general Linux issues, not Debian specific. That said, It's
very usage sensitive. Subversion checkouts on CIFS are ghods-awful
slow compared to doing it on NFS. The latest release of subversion
allegedly helps with the slow, but not *THAT* slow, performance on
local NTFS checkouts, and may help with this issue.

File ownership is a constant confusion between the two basic systems.
*DO NOT* try to manage the same file server and accessing its material
with the two different protocols. I've been this route, the claims of
"just set this" are generally complete handwaving, and cleaning up
when they break down can be a nightmare. I've been down this route
with Linux and UNIX and Windows file servers and NetApps, and I don't
recommend doing multiple access for *any* of them.

And don't get me *started* on the iSCSI pain, sorrow, and blood in the streets..


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTi=mSkYzhKHv=GGPBj-zOqoREjT-cQ@mail.gmail.com">http://lists.debian.org/BANLkTi=mSkYzhKHv=GGPBj-zOqoREjT-cQ@mail.gmail.com
 
Old 06-04-2011, 08:55 PM
"John A. Sullivan III"
 
Default Samba or NFS

On Sat, 2011-06-04 at 15:27 -0400, Nico Kadel-Garcia wrote:
> On Sat, Jun 4, 2011 at 1:33 PM, John A. Sullivan III
<snip>
> File ownership is a constant confusion between the two basic systems.
> *DO NOT* try to manage the same file server and accessing its material
> with the two different protocols. I've been this route, the claims of
> "just set this" are generally complete handwaving, and cleaning up
> when they break down can be a nightmare. I've been down this route
> with Linux and UNIX and Windows file servers and NetApps, and I don't
> recommend doing multiple access for *any* of them.
>
> And don't get me *started* on the iSCSI pain, sorrow, and blood in the streets..
>
>
Boy have we really digressed on this thread! If anyone objects, please
say so and I'll spawn another one.

I'm glad you mentioned trying to run both protocols against the same
file system. IF we go the NAS (presenting a remote file system as a
remote file system - to define terms) rather than the SAN (presenting a
remote file system as a block device) route, being able to access the
same data on the NAS via both protocols would solve a big headache for
us (Windows and Linux users both needing read/write access to the same
data). Has anyone been able to successfully do this?

Otherwise, we will probably use SAMBA rather than have to license NFS
services on Windows (not sure if that's still a separate license).

I'm also curious to see how others have dealt with iSCSI. That set back
our entire company launch by five months as we fought ISCSI / Linux file
system issues until we realized the problem was the 4KB block size
limitation in Linux. Because each iSCSI block needs to be acknowledged,
with only 4KB blocks, latency becomes the bottleneck rather than
bandwidth, i.e., 4KB of data comes nowhere close to saturating the
network. Thus, the maximum iSCSI throughput becomes 4KB/(round trip
latency), e.g., 100 microsecond round trip latency limits throughput to
4KB/.0001 = 40MBps.

To make matters worse for us, we are using Nexenta as a SAN. It's a
brilliant idea of using ZFS for a back end but it runs on OpenSolaris
and the network stack is much slower than Linux. We are eagerly waiting
for BTRFS to mature as we suspect we will see a 30% to 80% increase in
throughput by moving to Linux based SANs.

In any event, has anyone found a way around this iSCSI 4KB problem for
Linux file I/O?

And to restate the earlier question, has anyone truly resolved the
issues of running SAMBA and NFS against the same back end Linux file
system?

Thanks. Very helpful thread - John


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1307220947.20855.29.camel@denise.theartistscloset. com">http://lists.debian.org/1307220947.20855.29.camel@denise.theartistscloset. com
 
Old 06-05-2011, 09:38 AM
Simon Brandmair
 
Default Samba or NFS

Hi,

On 3/6/2011 19:50 Axel Freyn wrote:
[...]
> For NFSv4 this has changed. You can use NFSv4 in different modes. The
> easy one has the same problem.
> However, you can switch on strong authentification (based on Kerberos),
> then it's safe (the server verifies that the client has the correct
> Kerberos-token of this user -- UID is not sufficient), and even ask to
> sign all transfers (to block man-in-the-middle-attacks which could
> change the commands sent to the server) and encryption (to protect data
> privacy).
>
> However, it's much more work to install, as you also need a full
> Kerberos-setup....

I haven't looked at all into Kerberos, but sort of considering it. So I
was wondering, if it is worth (or even just work) when I just have a
server client network and no extra kerberos server? Or is Kerberos
rendered useless if I let it run on the same server that hosts the nfs
server?

Cheers,
Simon


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: isfiqp$hsn$1@news.albasani.net">http://lists.debian.org/isfiqp$hsn$1@news.albasani.net
 
Old 06-05-2011, 12:54 PM
Pier Paolo
 
Default Samba or NFS

2011/6/4 John A. Sullivan III <jsullivan@opensourcedevel.com>


On Sat, 2011-06-04 at 15:27 -0400, Nico Kadel-Garcia wrote:


Boy have we really digressed on this thread! If anyone objects, please

say so and I'll spawn another one.


To digress a little more...

I'm planning a network share for unison backup, some other discrete backup and media share, maybe with some virtualization to come, and found the pNFS project (NFS 4.1): this seems experimental, exp. on the client side (http://wiki.linux-nfs.org/wiki/index.php/PNFS_prototype_design), is that true? on the debian side?



And found 2 that i sould go for openAFS... nobody experienced that on debian? Particularly on a encrypted dm-luks/LVM system?

Thanks, Pier Paolo.
 
Old 06-06-2011, 01:30 AM
Nico Kadel-Garcia
 
Default Samba or NFS

On Sun, Jun 5, 2011 at 5:38 AM, Simon Brandmair <sbrandmair@gmx.net> wrote:
> Hi,
>
> On 3/6/2011 19:50 Axel Freyn wrote:
> [...]
>> For NFSv4 this has changed. You can use NFSv4 in different modes. The
>> easy one has the same problem.

NFSv4 is a giant pain in the keister, not worth the headaches. The
NFSv4 access published from an actual Linux or other NFSv4 capable
service can be published, it can be passed along via Samba to CIFS
clients, but the CIFS clients cannot *see* or manipulate the NFSv4
permissions due to incompatibilities between thee two ownership
models, and due to the Samba code for this being "spaghetti code".
(http://samba.2283325.n4.nabble.com/viewing-if-not-editing-NFSv4-ACL-s-from-Samba-shares-td2417666.html).

Overall, NFSv4 has proven itself destabilizing and useless in small
and large environments. It takes a significant investment in complex
infrastructure, and the security benefits have proven to be illusory
in the face of clients who *insist* on making their home directories
publicly accessible, clients who use password free SSH keys, or
clients who store passwords in source controlled software with no
access control. (I've run into all of these in environments that spent
useless years pursuing the "security" of NFSv4 and ignoring gaping
holes in infrastructure security.)

>> However, you can switch on strong authentification (based on Kerberos),
>> then it's safe (the server verifies that the client has the correct
>> Kerberos-token of this user -- UID is not sufficient), and even ask to
>> sign all transfers (to block man-in-the-middle-attacks which could
>> change the commands sent to the server) and encryption (to protect data
>> privacy).
>>
>> However, it's much more work to install, as you also need a full
>> Kerberos-setup....
>
> I haven't looked at all into Kerberos, but sort of considering it. So I
> was wondering, if it is worth (or even just work) when I just have a
> server client network and no extra kerberos server? Or is Kerberos
> rendered useless if I let it run on the same server that hosts the nfs
> server?
>
> Cheers,
> Simon

The problem isn't getting it up and running. It's getting people to
actually use it. It's sensitive to time drift on the servers and
clients, and getting people configured with NTP correctly is only a
tiny part of the battle. For a hundred accounts? I can see it. For
half a dozen people in a small office? Unlikely to be worth it.

>From another part of the thread: I've used openAFS, including porting
it and Kerberos to SunOS way the heck back in antiquity. (Whose bright
flipping idea was it to make Kerberos require a fully qualified
hostname as the first entry in /etc/hosts for your IP address rather
than the short name, to make compilation fail if it wasn't, and to set
a timestamp so that the compilation had to *start over from the
beginning? Actually, I think I know, and I've gotten private vengeance
for this.)

Debian's leading edge packaging and integration testing should make
them both vastly easier. You're stuck with policy decisions in setup
that can be.... subtle and awkward.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTimiGeuBaQf-L09PcED7k72ThQWHCA@mail.gmail.com">http://lists.debian.org/BANLkTimiGeuBaQf-L09PcED7k72ThQWHCA@mail.gmail.com
 
Old 06-06-2011, 06:51 PM
Dan
 
Default Samba or NFS

On Sun, Jun 5, 2011 at 9:30 PM, Nico Kadel-Garcia <nkadel@gmail.com> wrote:
> On Sun, Jun 5, 2011 at 5:38 AM, Simon Brandmair <sbrandmair@gmx.net> wrote:
>> Hi,
>>
>> On 3/6/2011 19:50 Axel Freyn wrote:
>> [...]
>>> For NFSv4 this has changed. You can use NFSv4 in different modes. The
>>> easy one has the same problem.
>
> NFSv4 is a giant pain in the keister, not worth the headaches. The
> NFSv4 access published from an actual Linux or other NFSv4 capable
> service can be published, it can be passed along via Samba to CIFS
> clients, but the CIFS clients cannot *see* or manipulate the NFSv4
> permissions due to incompatibilities between thee two ownership
> models, and due to the Samba code for this being "spaghetti code".
> (http://samba.2283325.n4.nabble.com/viewing-if-not-editing-NFSv4-ACL-s-from-Samba-shares-td2417666.html).
>
> Overall, NFSv4 has proven itself destabilizing and useless in small
> and large environments. It takes a significant investment in complex
> infrastructure, and the security benefits have proven to be illusory
> in the face of clients who *insist* on making their home directories
> publicly accessible, clients who use password free SSH keys, or
> clients who store passwords in source controlled software with no
> access control. (I've run into all of these in environments that spent
> useless years pursuing the "security" of NFSv4 and ignoring gaping
> holes in infrastructure security.)

Yes, I read the documentation for Kerberos and it seems to be too
complicated. I think that it is an overkill to connect to computers.
In my case the LAN is the whole University and it is very easy to
spoof an IP, I checked that. So NFSv3 might not be such a good idea.

How about NFSv3 over a ssh tunnel? That should be easy to implement. I
compared the transfer of a file of 700Mb between scp (encrypted) and
samba not encrypted, and the result is:
-scp: 38 seconds, and 25% of overhead in one of the 4 cores of the computer
-samba: 18 seconds and no overhead

So in my case I think it can be acceptable to do a ssh tunnel as most
of the times most of the cores of the computer are not used and there
is not a big traffic of data. Are there other disadvantages of using a
ssh tunnel?

Thanks,
Dan


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTi=wi6WNaxAwuWGzsvWP6BqxgiD_4w@mail.gmail.com ">http://lists.debian.org/BANLkTi=wi6WNaxAwuWGzsvWP6BqxgiD_4w@mail.gmail.com
 
Old 06-06-2011, 07:32 PM
"John A. Sullivan III"
 
Default Samba or NFS

On Mon, 2011-06-06 at 14:51 -0400, Dan wrote:
> On Sun, Jun 5, 2011 at 9:30 PM, Nico Kadel-Garcia <nkadel@gmail.com> wrote:
> > On Sun, Jun 5, 2011 at 5:38 AM, Simon Brandmair <sbrandmair@gmx.net> wrote:
> >> Hi,
> >>
> >> On 3/6/2011 19:50 Axel Freyn wrote:
> >> [...]
> >>> For NFSv4 this has changed. You can use NFSv4 in different modes. The
> >>> easy one has the same problem.
> >
> > NFSv4 is a giant pain in the keister, not worth the headaches. The
> > NFSv4 access published from an actual Linux or other NFSv4 capable
> > service can be published, it can be passed along via Samba to CIFS
> > clients, but the CIFS clients cannot *see* or manipulate the NFSv4
> > permissions due to incompatibilities between thee two ownership
> > models, and due to the Samba code for this being "spaghetti code".
> > (http://samba.2283325.n4.nabble.com/viewing-if-not-editing-NFSv4-ACL-s-from-Samba-shares-td2417666.html).
> >
> > Overall, NFSv4 has proven itself destabilizing and useless in small
> > and large environments. It takes a significant investment in complex
> > infrastructure, and the security benefits have proven to be illusory
> > in the face of clients who *insist* on making their home directories
> > publicly accessible, clients who use password free SSH keys, or
> > clients who store passwords in source controlled software with no
> > access control. (I've run into all of these in environments that spent
> > useless years pursuing the "security" of NFSv4 and ignoring gaping
> > holes in infrastructure security.)
>
> Yes, I read the documentation for Kerberos and it seems to be too
> complicated. I think that it is an overkill to connect to computers.
> In my case the LAN is the whole University and it is very easy to
> spoof an IP, I checked that. So NFSv3 might not be such a good idea.
>
> How about NFSv3 over a ssh tunnel? That should be easy to implement. I
> compared the transfer of a file of 700Mb between scp (encrypted) and
> samba not encrypted, and the result is:
> -scp: 38 seconds, and 25% of overhead in one of the 4 cores of the computer
> -samba: 18 seconds and no overhead
>
> So in my case I think it can be acceptable to do a ssh tunnel as most
> of the times most of the cores of the computer are not used and there
> is not a big traffic of data. Are there other disadvantages of using a
> ssh tunnel?
<snip>
Hmm . . . if you are going to go that route, how about sshfs? Again, I
don't know a great deal about it but that is how we transfer files
securely in the X2Go remote desktop project (www.x2go.org) - John


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1307388748.6630.36.camel@denise.theartistscloset.c om">http://lists.debian.org/1307388748.6630.36.camel@denise.theartistscloset.c om
 
Old 06-06-2011, 08:03 PM
Dan
 
Default Samba or NFS

On Mon, Jun 6, 2011 at 3:32 PM, John A. Sullivan III
<jsullivan@opensourcedevel.com> wrote:
> On Mon, 2011-06-06 at 14:51 -0400, Dan wrote:
>> On Sun, Jun 5, 2011 at 9:30 PM, Nico Kadel-Garcia <nkadel@gmail.com> wrote:
>> > On Sun, Jun 5, 2011 at 5:38 AM, Simon Brandmair <sbrandmair@gmx.net> wrote:
>> >> Hi,
>> >>
>> >> On 3/6/2011 19:50 Axel Freyn wrote:
>> >> [...]
>> >>> For NFSv4 this has changed. You can use NFSv4 in different modes. The
>> >>> easy one has the same problem.
>> >
>> > NFSv4 is a giant pain in the keister, not worth the headaches. The
>> > NFSv4 access published from an actual Linux or other NFSv4 capable
>> > service can be published, it can be passed along via Samba to CIFS
>> > clients, but the CIFS clients cannot *see* or manipulate the NFSv4
>> > permissions due to incompatibilities between thee two ownership
>> > models, and due to the Samba code for this being "spaghetti code".
>> > (http://samba.2283325.n4.nabble.com/viewing-if-not-editing-NFSv4-ACL-s-from-Samba-shares-td2417666.html).
>> >
>> > Overall, NFSv4 has proven itself destabilizing and useless in small
>> > and large environments. It takes a significant investment in complex
>> > infrastructure, and the security benefits have proven to be illusory
>> > in the face of clients who *insist* on making their home directories
>> > publicly accessible, clients who use password free SSH keys, or
>> > clients who store passwords in source controlled software with no
>> > access control. (I've run into all of these in environments that spent
>> > useless years pursuing the "security" of NFSv4 and ignoring gaping
>> > holes in infrastructure security.)
>>
>> Yes, I read the documentation for Kerberos and it seems to be too
>> complicated. I think that it is an overkill to connect to computers.
>> In my case the LAN is the whole University and it is very easy to
>> spoof an IP, I checked that. So NFSv3 might not be such a good idea.
>>
>> How about NFSv3 over a ssh tunnel? That should be easy to implement. I
>> compared the transfer of a file of 700Mb between scp (encrypted) and
>> samba not encrypted, and the result is:
>> -scp: 38 seconds, and 25% of overhead in one of the 4 cores of the computer
>> -samba: 18 seconds and no overhead
>>
>> So in my case I think it can be acceptable to do a ssh tunnel as most
>> of the times most of the cores of the computer are not used and there
>> is not a big traffic of data. Are there other disadvantages of using a
>> ssh tunnel?
> <snip>
> Hmm . . . if you are going to go that route, how about sshfs? Again, I
> don't know a great deal about it but that is how we transfer files
> securely in the X2Go remote desktop project (www.x2go.org) - John
>
>

I think that sshfs is a file system oriented to the user, and NFS can
be used for many users. NFS should be more robust if there are many
users connected.

Moreover, with sshfs each user will have to mount his folder and enter
his password. With nfs you can establish a permanent link that can be
used by all the users.

Dan


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTing3sc8kpYF9TypZrYmxAgk+p7K4g@mail.gmail.com ">http://lists.debian.org/BANLkTing3sc8kpYF9TypZrYmxAgk+p7K4g@mail.gmail.com
 
Old 06-06-2011, 08:42 PM
"John A. Sullivan III"
 
Default Samba or NFS

On Mon, 2011-06-06 at 16:03 -0400, Dan wrote:
> <snip>

> I think that sshfs is a file system oriented to the user, and NFS can
> be used for many users. NFS should be more robust if there are many
> users connected.
>
> Moreover, with sshfs each user will have to mount his folder and enter
> his password. With nfs you can establish a permanent link that can be
> used by all the users.
<snip>
Duh! Sorry for the brain cramp and thanks for catching me on it. Of
course, the whole question is about multi-user access. And I'm not a
coffee drinker so I don't even have that excuse! - John


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1307392952.6630.39.camel@denise.theartistscloset.c om">http://lists.debian.org/1307392952.6630.39.camel@denise.theartistscloset.c om
 

Thread Tools




All times are GMT. The time now is 02:22 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org