Bug 10935 - ypbind fails unless 'domainname' for local host is set
ypbind fails unless 'domainname' for local host is set
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: pump (Show other bugs)
6.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Erik Troan
:
Depends On: 11574
Blocks:
  Show dependency treegraph
 
Reported: 2000-04-20 02:55 EDT by George Karabin
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-08-05 09:23:00 EDT
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 George Karabin 2000-04-20 02:55:01 EDT
On our network, we use both DHCP and NIS to configure Red Hat boxes. We
currently have RH 6.1 boxes in use.

Under RH 6.1, the only step needed to get ypbind to work was to set the
domain name under linuxconf's NIS section.

Under RH 6.2, ypbind does not work on our network. It exits, with an error
message in /var/log/messages stating that it doesn't know what domain to
use. On our RH 6.1 boxes, DHCP appears to set the domain name. On our RH
6.2 boxes, running 'domainname' at the command line shows that the domain
name hasn't been set.

As a workaround, I've added the 'domainname' command to /etc/rc.d/rc.local,
to hard code our domain name for our network. If I don't do this, ypbind
fails, claiming that it doesn't know what the domain is.

I'm at home right now, and don't have access to my network at work, but if
I look in /etc/rc.d/rc.sysinit, I can see that domainname is only set to
NISDOMAIN if it is defined in /etc/sysconfig/network. I'm guessing that
NISDOMAIN isn't being written into /etc/sysconfig/network in the same way
that it was under RH 6.1
Comment 1 Erik Troan 2000-08-05 09:58:20 EDT
pump-0.8 ses the NIS domain name ftp://people.redhat.com/ewt

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