I have an issue that is not all that unique, so I'm hoping someone has done it before.
On the client end I have some very old RedHat based systems. On the server end is a Windows 2008 system running NFS server software. The clients mount the server resource as an NFS2 mount but some compliance issues were discovered with the setup. For various reasons, updating the client is not an option at this time. The fix the issue, the server needs to export NFS3 mounts but the clients do not support that version. As a workaround, I considered adding a third system running CentOS that would mount the server and re-export it to the clients. This will mitigate the current issue related to visibility of the share from certain groups.
It does not appear possible, using the current kernel-based NFS server, to export an NFS-mounted filesystem. However, it appears that there is a FUSE NFS project that might work. Does anyone have any experience with such a setup?
re-exporting a nfs mount with the kernel nfs server works for me.
On 07/13/2010 04:01 PM, Kwan Lowe wrote:
I have an issue that is not all that unique, so I'm hoping someone has done it before.
On the client end I have some very old RedHat based systems. On the server end is a Windows 2008 system running NFS server software. The clients mount the server resource as an NFS2 mount but some compliance issues were discovered with the setup. For various reasons, updating the client is not an option at this time. The fix the issue, the server needs to export NFS3 mounts but the clients do not support that version. As a workaround, I considered adding a third system running CentOS that would mount the server and re-export it to the clients. This will mitigate the current issue related to visibility of the share from certain groups.
It does not appear possible, using the current kernel-based NFS server, to export an NFS-mounted filesystem. However, it appears that there is a FUSE NFS project that might work. Does anyone have any experience with such a setup? _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Tue, Jul 13, 2010 at 10:22 AM, Juergen Gotteswinter jg@internetx.de wrote:
re-exporting a nfs mount with the kernel nfs server works for me.
Did you need to do anything special to get it to work? I am mounting an NFS3 share and exporting that same filesystem as NFS2. These are the types of errors I get:
Jul 12 18:07:28 mrmbc01v04 mountd[12194]: authenticated mount request from 10.201.54.113:906 for /mnt/nfs_test (/mnt/nfs_test) Jul 12 18:07:28 mrmbc01v04 mountd[12194]: Cannot export /mnt/nfs_test, possibly unsupported filesystem or fsid= required
Kwan Lowe wrote:
I have an issue that is not all that unique, so I'm hoping someone has done it before.
On the client end I have some very old RedHat based systems. On the server end is a Windows 2008 system running NFS server software. The clients mount the server resource as an NFS2 mount but some compliance issues were discovered with the setup. For various reasons, updating the client is not an option at this time. The fix the issue, the server needs to export NFS3 mounts but the clients do not support that version. As a workaround, I considered adding a third system running CentOS that would mount the server and re-export it to the clients. This will mitigate the current issue related to visibility of the share from certain groups.
<snip> You might look at unfs, which can re-export. I used it with glusterfs, so as to have a head node.
mark
On Jul 13, 2010, at 10:01 AM, Kwan Lowe kwan.lowe@gmail.com wrote:
I have an issue that is not all that unique, so I'm hoping someone has done it before.
On the client end I have some very old RedHat based systems. On the server end is a Windows 2008 system running NFS server software. The clients mount the server resource as an NFS2 mount but some compliance issues were discovered with the setup. For various reasons, updating the client is not an option at this time. The fix the issue, the server needs to export NFS3 mounts but the clients do not support that version. As a workaround, I considered adding a third system running CentOS that would mount the server and re-export it to the clients. This will mitigate the current issue related to visibility of the share from certain groups.
It does not appear possible, using the current kernel-based NFS server, to export an NFS-mounted filesystem. However, it appears that there is a FUSE NFS project that might work. Does anyone have any experience with such a setup?
Can the clients do CIFS mounts of the Windows share?
-Ross
At Tue, 13 Jul 2010 10:01:18 -0400 CentOS mailing list centos@centos.org wrote:
I have an issue that is not all that unique, so I'm hoping someone has done it before.
On the client end I have some very old RedHat based systems. On the server end is a Windows 2008 system running NFS server software. The clients mount the server resource as an NFS2 mount but some compliance issues were discovered with the setup. For various reasons, updating the client is not an option at this time. The fix the issue, the server needs to export NFS3 mounts but the clients do not support that version. As a workaround, I considered adding a third system running CentOS that would mount the server and re-export it to the clients. This will mitigate the current issue related to visibility of the share from certain groups.
It does not appear possible, using the current kernel-based NFS server, to export an NFS-mounted filesystem. However, it appears that there is a FUSE NFS project that might work. Does anyone have any experience with such a setup?
It really is NOT a good idea to re-export a network-mounted file system. Is there some reason you cannot simply migrate the data on the Windows 2008 server to a new CentOS system? Note that you can also install Samba on the new CentOS system, which will support any MS-Windows clients served by the Windows 2008 server.
One possibity would be to install a virtual CentOS server on the Windows 2008 server and have it *replace* the NFS server running on the Windows 2008 server. You would need to map the file systems to be exported as local/virtual file systems on the virtual CentOS server.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Tue, Jul 13, 2010 at 12:48 PM, Robert Heller heller@deepsoft.com wrote:
It really is NOT a good idea to re-export a network-mounted file system. Is there some reason you cannot simply migrate the data on the Windows 2008 server to a new CentOS system? Note that you can also install Samba on the new CentOS system, which will support any MS-Windows clients served by the Windows 2008 server.
One possibity would be to install a virtual CentOS server on the Windows 2008 server and have it *replace* the NFS server running on the Windows 2008 server. You would need to map the file systems to be exported as local/virtual file systems on the virtual CentOS server.
Thanks Robert...Unfortunately, changes to the server and client require a large effort. The systems are only accessible remotely, are in use 24 hours a day for two to three weeks at a time, and making any change, even adding a script, requires re-certification.
Mark - thanks.. I will look at unfs..
Ross - We considered that option and may consider it if re-exporting a share is possible with CIFS.
On Jul 13, 2010, at 1:17 PM, Kwan Lowe kwan.lowe@gmail.com wrote:
On Tue, Jul 13, 2010 at 12:48 PM, Robert Heller heller@deepsoft.com wrote:
It really is NOT a good idea to re-export a network-mounted file system. Is there some reason you cannot simply migrate the data on the Windows 2008 server to a new CentOS system? Note that you can also install Samba on the new CentOS system, which will support any MS-Windows clients served by the Windows 2008 server.
One possibity would be to install a virtual CentOS server on the Windows 2008 server and have it *replace* the NFS server running on the Windows 2008 server. You would need to map the file systems to be exported as local/virtual file systems on the virtual CentOS server.
Thanks Robert...Unfortunately, changes to the server and client require a large effort. The systems are only accessible remotely, are in use 24 hours a day for two to three weeks at a time, and making any change, even adding a script, requires re-certification.
Mark - thanks.. I will look at unfs..
Ross - We considered that option and may consider it if re-exporting a share is possible with CIFS.
Well on the 2008 box you can have a share available by NFSv3 AND CIFS and on the old Redhat boxes you might be able to mount the CIFS share since they don't support NFSv3, though if they don't support NFSv3 I have my doubts they support mounting CIFS as well.
Is it that NFSv2 itself is insecure, or only the Windows implementation of NFSv2? Is NFSv2 on CentOS an acceptable substitute? Can you relocate the data?
You might be painted into a corner here, being forced to upgrade under duress.
-Ross
On Tue, Jul 13, 2010 at 6:40 PM, Ross Walker rswwalker@gmail.com wrote:
Well on the 2008 box you can have a share available by NFSv3 AND CIFS and on the old Redhat boxes you might be able to mount the CIFS share since they don't support NFSv3, though if they don't support NFSv3 I have my doubts they support mounting CIFS as well.
Is it that NFSv2 itself is insecure, or only the Windows implementation of NFSv2? Is NFSv2 on CentOS an acceptable substitute? Can you relocate the data?
You might be painted into a corner here, being forced to upgrade under duress.
It's not specifically NFS, but more related to how the application stack was designed. We are essentially working around some 6 year old design decisions. When they were built, little thought was placed on allowing full access as the systems are on an isolated network. Over the years, other systems began to interface to the original application. Because one of those systems fall is a compliance target system, the original box needs to be compliant also.
On Jul 13, 2010, at 8:23 PM, Kwan Lowe kwan.lowe@gmail.com wrote:
On Tue, Jul 13, 2010 at 6:40 PM, Ross Walker rswwalker@gmail.com wrote:
Well on the 2008 box you can have a share available by NFSv3 AND CIFS and on the old Redhat boxes you might be able to mount the CIFS share since they don't support NFSv3, though if they don't support NFSv3 I have my doubts they support mounting CIFS as well.
Is it that NFSv2 itself is insecure, or only the Windows implementation of NFSv2? Is NFSv2 on CentOS an acceptable substitute? Can you relocate the data?
You might be painted into a corner here, being forced to upgrade under duress.
It's not specifically NFS, but more related to how the application stack was designed. We are essentially working around some 6 year old design decisions. When they were built, little thought was placed on allowing full access as the systems are on an isolated network. Over the years, other systems began to interface to the original application. Because one of those systems fall is a compliance target system, the original box needs to be compliant also.
Hmmm, maybe the problem isn't necessarily the NFS setup but the interface of the lower trusted systems.
Maybe developing a bastion host between the trusted and non-trusted networks would solve the compliance issue?
Separate VLANs, firewall host that uses forward and reverse NAT or possibly application proxy to limit the protocols and the hosts that use them across the trusted network. Detailed logging to a central log host for auditing.
If done with care it could be done with minimal interruption.
-Ross
On 07/13/2010 07:01 AM, Kwan Lowe wrote:
On the client end I have some very old RedHat based systems. On the server end is a Windows 2008 system running NFS server software. The clients mount the server resource as an NFS2 mount but some compliance issues were discovered with the setup.
I'm not sure I can help, but I'm very curious. How old are these systems, that they don't support NFSv3? And what kind of compliance issues? I don't know of any security enhancements that were introduced in NFSv3.
On Tue, Jul 13, 2010 at 7:44 PM, Gordon Messmer yinyang@eburg.com wrote:
On 07/13/2010 07:01 AM, Kwan Lowe wrote:
On the client end I have some very old RedHat based systems. On the server end is a Windows 2008 system running NFS server software. The clients mount the server resource as an NFS2 mount but some compliance issues were discovered with the setup.
I'm not sure I can help, but I'm very curious. How old are these systems, that they don't support NFSv3? And what kind of compliance issues? I don't know of any security enhancements that were introduced in NFSv3.
It's a combination of some very old (RH2.1) systems and a rigid certification process. In short, once the machines are built it's very, very difficult to modify the setup. Not only are they only available by a satellite link on only certain days, but the systems are critical and don't have maintenance windows. Every few years they may get updated
On 07/13/2010 05:19 PM, Kwan Lowe wrote:
On Tue, Jul 13, 2010 at 7:44 PM, Gordon Messmeryinyang@eburg.com wrote:
I'm not sure I can help, but I'm very curious. How old are these systems, that they don't support NFSv3?
It's a combination of some very old (RH2.1) systems and a rigid certification process.
Red Hat Linux 2.1, from 1995?
You mentioned "compliance", but not how NFSv3 will help you mean a specific need. How will moving the NFSv2 export from Windows 2008 to CentOS help you become more "compliant"?
On Wed, Jul 14, 2010 at 7:12 PM, Gordon Messmer yinyang@eburg.com wrote:
On 07/13/2010 05:19 PM, Kwan Lowe wrote:
On Tue, Jul 13, 2010 at 7:44 PM, Gordon Messmeryinyang@eburg.com wrote:
I'm not sure I can help, but I'm very curious. How old are these systems, that they don't support NFSv3?
It's a combination of some very old (RH2.1) systems and a rigid certification process.
Red Hat Linux 2.1, from 1995?
You mentioned "compliance", but not how NFSv3 will help you mean a specific need. How will moving the NFSv2 export from Windows 2008 to CentOS help you become more "compliant"?
:) I know... believe me...
The clients cannot be upgraded for several more months, possibly over a year from now. They do not support NFS3. The Windows server does support NFS2, but per the guidelines, this version is not allowed. It's not the NFS protocol itself, but some decisions that were made several years ago on how files were placed on the server. They are essentially open to the world (i.e., to guest access), but this was acceptable at the time because it was on an isolated network and there were no other users defined on the system.
Since we cannot modify the client at this time (i.e., install an NFS3 capable client), and the underlying issue cannot be solved by changing permissions on the server, we considered adding a third server that would mount the Windows server then re-export it to the clients. We could then lock down the new server to comply with the guidelines.
I think I'm more confused than before.
On 07/14/2010 06:59 PM, Kwan Lowe wrote:
The clients cannot be upgraded for several more months, possibly over a year from now. They do not support NFS3.
Is that to say that they are Red Hat 2.1, from 1995? (not RHEL 2.1)?
The Windows server does support NFS2, but per the guidelines, this version is not allowed.
So NFS2 is *not* allowed on Windows 2008, but it *is* allowed on CentOS?
Since we cannot modify the client at this time (i.e., install an NFS3 capable client), and the underlying issue cannot be solved by changing permissions on the server, we considered adding a third server that would mount the Windows server then re-export it to the clients.
So you can't configure the Windows server to export data only to the client PCs, but you can configure to export data only to the CentOS host?
Either userspace NFS daemon should be able to re-export an NFS mount:
http://sourceforge.net/projects/unfs/ http://sourceforge.net/tracker/index.php?func=detail&aid=632786&grou...
-
Gordon Messmer -
Juergen Gotteswinter -
Kwan Lowe -
m.roth＠5-cent.us -
Robert Heller -
Ross Walker