Bug 234543 - RFE: Set static ports for NFS
RFE: Set static ports for NFS
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: nfs-utils (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-29 18:02 EDT by Forrest Taylor
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2007-0651
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-07 12:15:21 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Forrest Taylor 2007-03-29 18:02:04 EDT
Description of problem:  Ports for NFS are set dynamically by portmapper.  They
should be set statically.  Then we could easily use the firewall (iptables and
system-config-securitylevel) to allow those ports.


Version-Release number of selected component (if applicable):
nfs-utils-1.0.9-16.el5


Additional info:
Add this entry to /etc/sysconfig/nfs:

MOUNTD_PORT=4002
STATD_PORT=4003
LOCKD_TCPPORT=4004
LOCKD_UDPPORT=4004
Comment 1 Steve Dickson 2007-04-21 08:26:34 EDT
Is there any log message in /var/log/messages as to why
all these daemons are failing to use the given ports?
Comment 2 Forrest Taylor 2007-05-07 23:00:30 EDT
They all work when I have the entries above.  I am requesting that we do this by
default.  Even creating the file with the entries commented out would be useful.
Comment 3 Steve Dickson 2007-05-08 06:53:45 EDT
Understood...
Comment 4 RHEL Product and Program Management 2007-05-08 07:03:50 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 6 Steve Dickson 2007-05-12 08:52:40 EDT
Fixed in nfs-utils-1.0.9-18
Comment 7 Ville Skyttä 2007-05-16 13:33:44 EDT
Just a note, in nfs-utils-1.0.10-10.fc6, if one sets all the MOUNTD_NFS_V{1,2,3}
options to "no", mountd fails to start.  I tried that because I have no need for
< v4 NFS.

# /etc/init.d/nfs start
Starting NFS services:                                     [  OK  ]
Starting NFS daemon:                                       [  OK  ]
Starting NFS mountd: Usage: rpc.mountd [-F|--foreground] [-h|--help]
[-v|--version] [-d kind|--debug kind]
        [-o num|--descriptors num] [-f exports-file|--exports-file=file]
        [-p|--port port] [-V version|--nfs-version version]
        [-N version|--no-nfs-version version] [-n|--no-tcp]
        [-H ha-callout-prog] [-s|--state-directory-path path]
        [-t num|--num-threads=num]
                                                           [FAILED]
Comment 8 Steve Dickson 2007-05-16 14:14:28 EDT
hmmm... interesting... I do see your point wrt to not wanting to 
starti mountd when only v4 is needed... I would suspect lockd and statd are
in the same boat... and its not clear setting all version of mountd to
to no is the best way to deal with this... 

I would say this is a different problem so would you mind 
opening another bug about this? 
Comment 9 Kostas Georgiou 2007-05-16 19:57:56 EDT
The fedora6 update added /etc/sysconfig/nfs but without the noreplace option, I
suspect the rhel version does the same as well.

This means that if you have setup /etc/sysconfig/nfs already the changes are
lost, the server now listens to different ports which might be blocked by the
firewall, rpcgssd doesn't start since SECURE_NFS isn't defined and the sysadmin
has to lock the door to keep the angry crowds away.
Comment 10 Steve Dickson 2007-05-18 12:02:22 EDT
I made /etc/sysconfig/nfs a %config which will save the
file if and only if it changed. I did this so if I updated
the file with more variables, the file would actually
be installed, again, saving the old version.. 

I do see your point wrt to breaking an existing configuration
I'm not sure, at this point, what would be a better thing
to do... 
Comment 11 Kostas Georgiou 2007-05-18 12:28:51 EDT
This means that every time you update the file with new variables all the
changes that the sysadmin made are lost!. It is best to use noreplace which will
install the new file as /etc/sysconfig/nfs.rpmnew if the admin has made any
changes to the configuration.

Dropping all the changes every time there is an update is a very bad idea,
especially since the nfs server does restart after the update.
Comment 12 Forrest Taylor 2007-05-18 22:33:35 EDT
I think that the problem in this case was that the file did not exist previously
in the RPM.  Even though it was set as a %config it apparently overwrote the
file that didn't belong to any RPM.  In RHEL, we should probably use noreplace
for at least the initial push.
Comment 13 Forrest Taylor 2007-05-18 22:41:28 EDT
I just tested this on FC6.  It did move aside my current setting, but it did
save the file as nfs.rpmorig.  Now the NFS server is running on different ports
than it did previous to the update.

By the way, nice work on config file!  It is very well documented now.
Comment 14 Steve Dickson 2007-05-22 09:50:51 EDT
Agreed.... breaking configurations on updates is never a good
thing... plus it turns out an updated file will be installed
as a .rpmnew file (i.e. /etc/sysconfig/nfs.rpmnew) 

So I've updated the Fedora Core and RHEL nfs-utils.. 
(nfs-utils-1.0.9-19.el5 and nfs-utils-1.0.10-12.fc6)
Comment 18 errata-xmlrpc 2007-11-07 12:15:21 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0651.html

Note You need to log in before you can comment on or make changes to this bug.