samba instead of nfs
in [Setup]
|
Prev: Now, my Debian thinks I have SCSI for my old IDE/ATA drives after installing Kernel 2.6.32-4?
Next: Got it working! First post from inside Damn Small Linux! Needmore help pls
From: Doug Freyburger on 2 Jul 2010 15:54 Aragorn wrote: > > That said, reiserfs wasn't all that bad, but if it did ever go wrong, > then it went wrong very badly, and it lacked a decent toolchain like > ext2/3/4 or XFS Lacking such tools puts ReiserFS out of the quesiton for me. EXT3 works and it works fine for any of my production database boxes. I will point out that a part of the core tool chain is a working dump and restore for the filesystem format. That is something lacking across Linux in general. I get that Linus doesn't like dump and prefers tar. To me that is a significant feature missing and a point against using Linux in production at all. But it's only one point in a long list. Still, it is as ridiculous that those tools are missing as it is that I am not on SourceForge contributing to them. Such is how Linux works after all. If I think it's broken I can fix it myself. > I have no real experience with JFS, but I presume it > also has a similarly elaborate toolchain, since it is the default > filesystem in AIX. AIX JFS2 has a complete tool set. It works great. Extremely stable in the face of basically everything. I've had disks fail to spin up after a power cycle where I shook them, reinserted them, and started them up again. A bunch of resync work later hello big Oracle database on them. > Personally, I have however never heard of reiserfs > making files disappear, but I did read somewhere that it's rather prone > to damaging its own internal trees in the event of an unclean shutdown. Regular UNIX filesystems have not been that bad since 1982. On a VAX-11-750. That's a long time ago.
From: Aragorn on 2 Jul 2010 16:12 On Friday 02 July 2010 21:54 in comp.os.linux.setup, somebody identifying as Doug Freyburger wrote... > Aragorn wrote: >> >> That said, reiserfs wasn't all that bad, but if it did ever go wrong, >> then it went wrong very badly, and it lacked a decent toolchain like >> ext2/3/4 or XFS > > Lacking such tools puts ReiserFS out of the quesiton for me. EXT3 > works and it works fine for any of my production database boxes. Except that ext3 is rather slow "out of the box" because it has the B-tree indexing disabled by default. > I will point out that a part of the core tool chain is a working dump > and restore for the filesystem format. That is something lacking > across Linux in general. Such utilities do exist for the ext? family of filesystems, and if a distribution does not provide for them, then I imagine one could still download and install them. The "xfsprogs" package however contains the XFS equivalent of these tools. > I get that Linus doesn't like dump and prefers tar. That is correct, yes. > To me that is a significant feature missing and a point against using > Linux in production at all. Well, like I said, if you have an ext? filesystem and you need those tools, then I'm sure they can still be found. Linus may not like "dump" and "restore", but "/etc/fstab" still has the required field for it. And XFS has those tools "out of the box". That said, I personally also believe that there are far better tools for making backups than "dump" and "restore". >> Personally, I have however never heard of reiserfs making files >> disappear, but I did read somewhere that it's rather prone to >> damaging its own internal trees in the event of an unclean >> shutdown. > > Regular UNIX filesystems have not been that bad since 1982. On a > VAX-11-750. That's a long time ago. Well, I never said reiserfs was the best filesystem. In fact, my personal preference goes out to XFS, which is mature, fast, highly advanced - albeit that the Linux port does not have all the features of the IRIX version - it and comes with a complete toolchain. -- *Aragorn* (registered GNU/Linux user #223157)
From: Chris Cox on 3 Jul 2010 06:34 Vitus Jensen wrote: > Hej! > > As I have to open my server to windows users anyway I would like switch > linux clients to cifs from nfs, too. Problem is that on each linux > client there are several users who create files on the server and I need > the owner of the file kept together with the file. With nfs it's > "simple" by keeping uids insync between server and all clients. With > cifs the file always gets the login name of client as owner :-( I have worked with NFS and Samba for many, many years. The closest thing that will work is: 1. Use NFS 2. Use Samba on the NFS Server 3. Join that server to the Windows domain 4. Allow Unix/Linux client hosts access via NFS 5. Windows clients will use normal Windows SMB/CIFS to reach the share There is NO direct POSIX or POSIX with draft ACLs mapping to Windows NTFS style permissions. However, some things DO work ok, others will not. So, if any of this is interesting, you will need a filesystem with draft POSIX ACLs enabled under Linux (which nowadays is pretty much all of the major filesystem). What will NOT work well: Mounting Windows shares to a Linux/Unix box. So... architecturally, I've learned the following for a mixed environment: 1. Linux should own DHCP and DNS for a Windows domain 2. Linux should own all file shares that are need across Unix/Linux + Windows 3. Linux file shares that are needed by Windows should be joined to the Windows AD domain. If you do these things, you'll be the closest you can get to a livable problem free environment. What does Windows get to own? Active Directory What does Windows NOT get to own: 1. DHCP 2. DNS 3. Windows file shares where Unix/Linux NFS + SMB/CIFS is desired. Why? Windows DHCP ONLY works well for Windows clients. And with that said, ditto for dynamic DNS registrations as a part of that. The good news is that ISC BIND and DHCP easily replace those Windows elements and it can be made to work with AD. NFS works well across Unix/Linux clients (NFS4 less so just because it is newer and not supported across all *ix variants well). NFS + Samba where the file server is a AD Domain Member Server (i.e. joined to the domain) allows for NFS and Samba to work in concert with regards to locking (read up on this as there are variables to consider... and realize that commercial solutions usually end up disabling locking). By using Samba on a Linux host, you also get to smash the usernames with their AD names either by name or using a Samba smbusers file to map them together. Alternatively, you can use winbind to dynamically create the Linux accounts. Samba has the hooks to allow you to plug your own routine in for local account creation as well if you do not want automatic winbind account creation. What dosen't work well with Linux owned Samba + NFS? Areas where full NTFS permissions HAVE to be used. Again, there just isn't a direct mapping... so NOT everything works. Thus, if a Windows share HAS to have full NTFS permissions, IMHO, that share CANNOT be heterogeneous and needs to be Windows ONLY. But for all other shares, use the Linux NFS + Samba technique. You'll at least get a level of user and group level permissions that do work. What REALLY REALLY does NOT work? Letting Windows own heterogeneous shares. This tends to be what everyone WANTS to do (as if Windows somehow cares about other OS's using their shares). It's a BIG mistake and will only cause you massive frustration in the end. You'll get next to NO permission mappings, you'll probably end up with a plethora of locked out accounts over time, etc. AVOID. Likewise with letting Windows own DHCP and DNS. It's just NOT compatible. In truth, Windows really can't manage DHCP + DNS integration for its own dynamic clients. It REALLY can't do it for non-Windows clients. A well designed network CAN have both Windows AD and Unix/Linux clients all working seamlessly together.. but you have to be willing to architect things properly. What also doesn't work well? Windows NON domain based networking. Again, people seemed to be most interested in a simple "home" style of network.... but even so, it's bad. Microsoft will tell you that. So all the prior advice above assumes a Windows AD network. If you're talking about a "home" (throwaway, don't care) network... then IMHO, all bets are off anyhow. Whatever you create there will be a hodge podge mess anyhow.
From: The Natural Philosopher on 3 Jul 2010 07:24 Chris Cox wrote: > Vitus Jensen wrote: >> Hej! >> >> As I have to open my server to windows users anyway I would like switch >> linux clients to cifs from nfs, too. Problem is that on each linux >> client there are several users who create files on the server and I need >> the owner of the file kept together with the file. With nfs it's >> "simple" by keeping uids insync between server and all clients. With >> cifs the file always gets the login name of client as owner :-( > > I have worked with NFS and Samba for many, many years. > > The closest thing that will work is: > > 1. Use NFS > 2. Use Samba on the NFS Server > 3. Join that server to the Windows domain > 4. Allow Unix/Linux client hosts access via NFS > 5. Windows clients will use normal Windows SMB/CIFS to reach the share > > There is NO direct POSIX or POSIX with draft ACLs mapping to > Windows NTFS style permissions. However, some things DO work ok, others will > not. So, if any of this is interesting, you will need a filesystem with draft > POSIX ACLs enabled under Linux (which nowadays is pretty much all of the major > filesystem). > > What will NOT work well: > Mounting Windows shares to a Linux/Unix box. > > So... architecturally, I've learned the following for a mixed environment: > > 1. Linux should own DHCP and DNS for a Windows domain > 2. Linux should own all file shares that are need across Unix/Linux + Windows > 3. Linux file shares that are needed by Windows should be joined to the Windows > AD domain. > > If you do these things, you'll be the closest you can get to a livable problem > free environment. > > What does Windows get to own? > Active Directory > > What does Windows NOT get to own: > 1. DHCP > 2. DNS > 3. Windows file shares where Unix/Linux NFS + SMB/CIFS is desired. > > Why? > > Windows DHCP ONLY works well for Windows clients. And with that said, ditto for > dynamic DNS registrations as a part of that. The good news is that ISC BIND and > DHCP easily replace those Windows elements and it can be made to work with AD. > > NFS works well across Unix/Linux clients (NFS4 less so just because it is newer > and not supported across all *ix variants well). NFS + Samba where the file > server is a AD Domain Member Server (i.e. joined to the domain) allows for NFS > and Samba to work in concert with regards to locking (read up on this as there > are variables to consider... and realize that commercial solutions usually end > up disabling locking). By using Samba on a Linux host, you also get to smash > the usernames with their AD names either by name or using a Samba smbusers file > to map them together. Alternatively, you can use winbind to dynamically create > the Linux accounts. Samba has the hooks to allow you to plug your own routine > in for local account creation as well if you do not want automatic winbind > account creation. > > What dosen't work well with Linux owned Samba + NFS? > > Areas where full NTFS permissions HAVE to be used. Again, there just isn't a > direct mapping... so NOT everything works. Thus, if a Windows share HAS to have > full NTFS permissions, IMHO, that share CANNOT be heterogeneous and needs to be > Windows ONLY. But for all other shares, use the Linux NFS + Samba technique. > You'll at least get a level of user and group level permissions that do work. > > What REALLY REALLY does NOT work? > > Letting Windows own heterogeneous shares. This tends to be what everyone WANTS > to do (as if Windows somehow cares about other OS's using their shares). It's a > BIG mistake and will only cause you massive frustration in the end. You'll get > next to NO permission mappings, you'll probably end up with a plethora of locked > out accounts over time, etc. AVOID. > > Likewise with letting Windows own DHCP and DNS. It's just NOT compatible. In > truth, Windows really can't manage DHCP + DNS integration for its own dynamic > clients. It REALLY can't do it for non-Windows clients. > > A well designed network CAN have both Windows AD and Unix/Linux clients all > working seamlessly together.. but you have to be willing to architect things > properly. > > What also doesn't work well? > > Windows NON domain based networking. Again, people seemed to be most interested > in a simple "home" style of network.... but even so, it's bad. Microsoft will > tell you that. So all the prior advice above assumes a Windows AD network. If > you're talking about a "home" (throwaway, don't care) network... then IMHO, all > bets are off anyhow. Whatever you create there will be a hodge podge mess anyhow. Id agree with all of that except I dont use a windows domain and it works fine. But my requirements are not for shared data between many users on a seamless prioritised and locked basis: the server merely acts as a central repository for user data, that gets backed up..
From: phazr beam on 3 Jul 2010 13:26
On Wed, 30 Jun 2010 07:34:00 +0200, Vitus Jensen came out of hiding to write: > Hej! > > As I have to open my server to windows users anyway I would like switch > linux clients to cifs from nfs, too. Problem is that on each linux > client there are several users who create files on the server and I need > the owner of the file kept together with the file. With nfs it's > "simple" by keeping uids insync between server and all clients. With > cifs the file always gets the login name of client as owner :-( > > vitus(a)client$ touch as-vitus > oe(a)client$ touch as-oe > nobody(a)client$ touch as-nobody > root(a)client# touch as-root > > ls -l > -rw-r--r-- 1 vitus users 0 30. Jun 07:20 as-root > > Client: linux 2.6.27, mount.cifs 1.10 Server: reiserfs user_xattr, smbd > Version 3.2.8 > > Is this possible at all? Which part is responsible? xattr, acls? On > client mounts or should the server filesystem support something special? > acl is currently not enabled on reiserfs mounts. > > Vitus Nope, leave your Linux NFS clients alone. NFS works much better than CIFs clients, You can always mount a CIFS folder to a Linux client if you think its necessary which I don't if it there as a NFS folder. The only time you need to mount CIFs folders is when Windows is the server, ie, MS SQL Server 2008, ??? Most of us want to get rid of the CIFs clients for NFS clients. IIRC, Samba CIFs clogs the network with its broadcast packages. -- phazr(a)beam.eternalseptember.net |