Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 1067629

Summary: Snapshot 4 - NIS not functional. Configured NIS with emulex domain via authconfig-tui, disabled selinux, and allowed all public services in firewall
Product: Red Hat Enterprise Linux 7 Reporter: Brian Muldoon <brian.muldoon>
Component: ypbindAssignee: Honza Horak <hhorak>
Status: CLOSED INSUFFICIENT_DATA QA Contact: qe-baseos-daemons
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0CC: brian.muldoon, dbavedb, kschneid
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-09-22 06:53:46 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
.bash_profile none

Description Brian Muldoon 2014-02-20 18:47:43 UTC
Description of problem:
Snapshot 4 - NIS not functional. Configured NIS with emulex domain via authconfig-tui, disabled selinux, and allowed all public services in firewall.

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


How reproducible:
Configure an NIS client. Attempt connecting to NIS server. Cannot access remote share - /nfs/links/share on our site.

Steps to Reproduce:
1. rpm -i --nodeps yp-tools and ypbind packages.
2. chkconfig ypbind on to enable service
3. source attached .bash_profile to connect to NIS share.

Actual results:
Not able to connect to our Emulex /nfs/links/share.

Expected results:
Should be able to configure NIS. It works on all previous OS distros

Additional info:
See attached .bash_profile for auto-connection at login time.

Comment 2 Honza Horak 2014-02-24 15:47:28 UTC
Thanks for reporting, but I'm not able to reproduce. First I thought it could be because of you have SELinux disabled, but I tested it and it works fine, except the warning "getsebool:  SELinux is disabled". So I'll need some more information.

Which particular build (`rpm -q ypserv ypbind`) do you use on server and client?

I understand you run ypbind on another machine than ypserv. What happens if you configure ypbind on the same machine as ypserv -- does either work?

(In reply to Brian Muldoon from comment #0)
> allowed all public services in firewall.

This is now the most suspicious piece of information -- ypserv asks rpcbind for a port it runs on, unless you specify -p in /etc/sysconfig/network.

> How reproducible:
> Configure an NIS client. Attempt connecting to NIS server. Cannot access
> remote share - /nfs/links/share on our site.

Does pure logging functionality work?

> Steps to Reproduce:
> 1. rpm -i --nodeps yp-tools and ypbind packages.
> 2. chkconfig ypbind on to enable service
> 3. source attached .bash_profile to connect to NIS share.

There is no .bash_profile file attached.

Comment 3 Brian Muldoon 2014-02-28 15:26:25 UTC
Created attachment 869098 [details]
.bash_profile

Comment 4 Brian Muldoon 2014-02-28 18:20:11 UTC
I'm running with Snapshot 4:

ypbind-1.37.1-6.el7.x86_64
ypserv-2.31-7.el7.x86_64

I've also attached my .bash_profile.

You wrote:
This is now the most suspicious piece of information -- ypserv asks rpcbind for a port it runs on, unless you specify -p in /etc/sysconfig/network.

Can you elaborate on this comment. There is no /etc/sysconfig/network file or directory.

I'm still experimenting to see if I can get NIS operational.

-dmz

Comment 5 Honza Horak 2014-03-03 09:46:44 UTC
(In reply to Brian Muldoon from comment #4)
> You wrote:
> This is now the most suspicious piece of information -- ypserv asks rpcbind
> for a port it runs on, unless you specify -p in /etc/sysconfig/network.
> 
> Can you elaborate on this comment. There is no /etc/sysconfig/network file
> or directory.

From ypserv(8) man page:
"It is also possible to pass OPTIONS to ypserv using the environment variable YPSERV_ARGS and this variable can be set in /etc/sysconfig/network."

That means, if you want to force ypserv to run on a specific port, so you are able to set up firewall properly, you should do it like this:

  root> touch /etc/sysconfig/network
  root> echo 'YPSERV_ARGS="-p 800"'>>/etc/sysconfig/network
  root> systemctl restart ypserv

After that you can check using:
  root> rpcinfo -p localhost|grep ypserv
    100004    2   udp    800  ypserv
    100004    1   udp    800  ypserv
    100004    2   tcp    800  ypserv
    100004    1   tcp    800  ypserv

After that you need to allow the port you used in your firewall settings. Does this work?

Comment 6 Brian Muldoon 2014-03-04 16:23:02 UTC
Hello;

It appears that I'm having problems starting the ypserv service:

systemctl status ypserv.service -l
ypserv.service - NIS/YP (Network Information Service) Server
   Loaded: loaded (/usr/lib/systemd/system/ypserv.service; enabled)
   Active: failed (Result: exit-code) since Tue 2014-03-04 10:46:39 EST; 15min ago
  Process: 3008 ExecStart=/usr/sbin/ypserv -f $YPSERV_ARGS (code=exited, status=127)
 Main PID: 3008 (code=exited, status=127)
   CGroup: /system.slice/ypserv.service

Mar 04 10:46:39 dhcp-10-192-100-250 ypserv[3008]: /usr/sbin/ypserv: error while loading shared libraries: libtokyocabinet.so.9: cannot open shared object file: No such file or directory
Mar 04 10:46:39 dhcp-10-192-100-250 systemd[1]: ypserv.service: main process exited, code=exited, status=127/n/a
Mar 04 10:46:39 dhcp-10-192-100-250 systemd[1]: Failed to start NIS/YP (Network Information Service) Server.
Mar 04 10:46:39 dhcp-10-192-100-250 systemd[1]: Unit ypserv.service entered failed state.
[root@dhcp-10-192-100-250 dzbink]# 


I'm puzzled though. My issue is with my NIS client not connecting to our NIS server (a different machine). Why do I need to configure ypserv?

-dmz

Comment 7 Honza Horak 2014-03-05 08:50:14 UTC
(In reply to Brian Muldoon from comment #6)
> It appears that I'm having problems starting the ypserv service:
> 
> systemctl status ypserv.service -l
> ypserv.service - NIS/YP (Network Information Service) Server
>    Loaded: loaded (/usr/lib/systemd/system/ypserv.service; enabled)
>    Active: failed (Result: exit-code) since Tue 2014-03-04 10:46:39 EST;
> 15min ago
>   Process: 3008 ExecStart=/usr/sbin/ypserv -f $YPSERV_ARGS (code=exited,
> status=127)
>  Main PID: 3008 (code=exited, status=127)
>    CGroup: /system.slice/ypserv.service
> 
> Mar 04 10:46:39 dhcp-10-192-100-250 ypserv[3008]: /usr/sbin/ypserv: error
> while loading shared libraries: libtokyocabinet.so.9: cannot open shared
> object file: No such file or directory

This seems like you don't have the tokyocabinet package installed, but it is irrelevant in case you don't need ypserv on localhost, so, please, scratch the ypserv part, in case other clients from other similar computers are able to connect (I understand that you excluded problems on server side, right?)

However, I'm wondering why you install packages like "rpm -i --nodeps ..." (comment #0) -- this is quite dangerous and can be a cause of your problems with ypbind as well. Could you try to install the packages using yum?

> I'm puzzled though. My issue is with my NIS client not connecting to our NIS
> server (a different machine). Why do I need to configure ypserv?

OK, I understand now. So, please, first try to reinstall the ypbind and yp-tools packages using yum, so all dependencies are satisfied. Then, you can try to run `ypbind -debug`, so you can see some debugging information, that can tell you more, and you can attach it here.

Comment 8 Brian Muldoon 2014-03-05 14:42:21 UTC
Hello;

I have to install using rpm -i --nodeps yp-tools and ypbind packages because they would not install otherwise. yp-tools complained about a dependency on ypbind and vice versa. 

I understand that Snapshot 8 is available now. Let me install this newer version and re-attempt to install yp-tools and ypbind.

Also, I'm not able to perform yum updates. My system is registered using the account emulex and password elxrht, but I apparently don't have any valid subscriptions.

Will post the results on Thursday.

-dmz

Comment 9 RHEL Program Management 2014-03-22 05:58:52 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 10 Honza Horak 2014-03-24 15:28:11 UTC
Re-setting needinfo flag as per comment #8.

Comment 11 Honza Horak 2014-06-12 08:25:00 UTC
Brian, any updates on this? Is it still issue in your environment? I'm still not able to reproduce.

Comment 12 Honza Horak 2014-09-22 06:53:46 UTC
Since there are no updates since March, it does not seem like the issue is relevant any more. Closing this bug for now. Feel free to re-open if you see the issue again.

Comment 13 David Klassen 2014-11-28 17:19:05 UTC
Given this was the thread that came up in my search. I thought I should say I successfully worked around this issue for ypserv by adding:

  rpcbind: 127.0.0.1 

into 

  /etc/hosts.allow