RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 456249 - ypserv init scripts false dependency on domainname
Summary: ypserv init scripts false dependency on domainname
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ypserv
Version: 6.4
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: 6.5
Assignee: Matej Mužila
QA Contact: Tomas Dolezal
Jiri Herrmann
URL:
Whiteboard:
Depends On:
Blocks: 947782 1159825
TreeView+ depends on / blocked
 
Reported: 2008-07-22 14:16 UTC by Kevin Graham
Modified: 2016-05-31 11:05 UTC (History)
5 users (show)

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.
Clone Of:
Environment:
Last Closed: 2016-05-10 20:33:48 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
patch moving domainname checking from ypserv to yppasswdd (1012 bytes, patch)
2012-05-14 11:55 UTC, Honza Horak
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:0793 0 normal SHIPPED_LIVE ypserv bug fix update 2016-05-10 22:37:06 UTC

Description Kevin Graham 2008-07-22 14:16:07 UTC
Description of problem:

Presently, ypserv's init script attempts to check if a domainname is set,
exiting if it hasn't. This is based on the false assumption that a machine
running ypserv is also a client, or that the domainname has some relevance to
the operation of ypserv. Neither of these is true, and the local domainname is
never used by ypserv (clients always provide the domainname for which they wish
to query).

Version-Release number of selected component (if applicable):

ypserv-2.13-18

How reproducible:

Steps to Reproduce:
1. Do not configure a machine as a YP client.
2. Start ypserv via init script.
  
Actual results:

Init script will exit.

Expected results:

ypserv should start.

Additional info:

All that is required is:

$ diff /etc/init.d/ypserv.orig /etc/init.d/ypserv
31,32d30
<           else
<               exit 1
$

...resulting in no changes to the daemon's actual operation.

Comment 1 Vitezslav Crhonek 2008-08-26 10:13:39 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.

Comment 2 Kevin Graham 2008-08-29 21:37:07 UTC
> 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).

Comment 3 RHEL Program Management 2008-10-31 16:36:09 UTC
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 "?".

Comment 4 Honza Horak 2012-05-14 11:48:38 UTC
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.

Comment 5 Honza Horak 2012-05-14 11:55:28 UTC
Created attachment 584347 [details]
patch moving domainname checking from ypserv to yppasswdd

Comment 6 RHEL Program Management 2012-06-12 01:05:49 UTC
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.

Comment 7 Honza Horak 2013-03-13 17:42:14 UTC
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.

Comment 21 errata-xmlrpc 2016-05-10 20:33:48 UTC
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


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