Bug 456249
Summary: | ypserv init scripts false dependency on domainname | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Kevin Graham <kgraham> | ||||
Component: | ypserv | Assignee: | Matej Mužila <mmuzila> | ||||
Status: | CLOSED ERRATA | QA Contact: | Tomas Dolezal <todoleza> | ||||
Severity: | low | Docs Contact: | Jiri Herrmann <jherrman> | ||||
Priority: | low | ||||||
Version: | 6.4 | CC: | hhorak, jherrman, ovasik, psklenar, todoleza | ||||
Target Milestone: | rc | Keywords: | Patch | ||||
Target Release: | 6.5 | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | ypserv-2.19-31.el6 | Doc Type: | Bug Fix | ||||
Doc Text: |
*ypserv* no longer fails if the `domainname` parameter is unset
Previously, the *ypserv* service failed to start when the `domainname` parameter was not set in the `/etc/init.d/ypserv` file. This update moves the check for `domainname` to the *yppasswdd* service, and in the described circumstances, *ypserv* now starts as expected.
|
Story Points: | --- | ||||
Clone Of: | Environment: | ||||||
Last Closed: | 2016-05-10 20:33:48 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 947782, 1159825 | ||||||
Attachments: |
|
Description
Kevin Graham
2008-07-22 14:16:07 UTC
Well, I think you're right. Although possibly in every NIS HOWTO/FAQ/tutorial I have ever read is statement, that NIS server must be also NIS client. But this is true IMHO only in case of slave server. Domainname is used during database update and /var/yp/Makefile will check its value when is used. So there's no need to check it in init script. > but this is true IMHO only in case of slave server. Domainname is used during > database update and /var/yp/Makefile will check its value when is used. So > there's no need to check it in init script. The ypserv daemon doesn't require the system to be a client in any circumstances; the RPC calls all identify the domain the client is interested in (going back to the fact that a ypserv can serve an arbitrary number of domains, none of which it is required to be a member of). The Makefile also doesn't present this requirement (though it will fallback to using the local domainname). I was going to open a bug similar to comment 0 for 'ypinit', as the script itself is the only part that requires the local domain to be set (replace `domainname` with any domain and it will operate as expected). This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?". As RHEL-4.9 is the last update for RHEL-4 and it should address only security, performance and critical issues, I'm moving the bugzilla to RHEL-5. I also changed behaviour of ypserv service in Fedora Rawhide, so it doesn't fail anymore in case domainname is not set. However, domainname is needed for updating maps properly after password change, so I added this check to yppasswdd service instead. Created attachment 584347 [details]
patch moving domainname checking from ypserv to yppasswdd
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. There is no chance to fix this in RHEL-5 any more, since RHEL 5.10 is going to include only serious fixes. Re-assigning to RHEL-6. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-0793.html |