NIS client setup on Solaris 10?
Dragan Cvetkovic
I am having a problem seting up a NIS client on Solaris 10 machines in our
NIS environment here:
I do the standard stuff: set domainname; ypinit -c; copy
/etc/nsswitch.nis to /etc/nsswitch.conf
and then svcadm enable nis/client and svcadm restart name-service-cache
So, ypwhich returns the name of a NIS master (or slave), getent passwd myid
works, but e.g. ypcat passwd doesn't work (it just hangs). If I reboot the
machine, it, sort of, stays in a single user mode and svcs -xv shows that
rpc/gss service is not started since it is not initialised.
I have seen the issue note 5084183
(http://docs.sun.com/app/docs/doc/817-0552/6mgbi4fgt?a=view), but doing
that doesn't help. Besides, I do want to run NIS client here.
That happened twice to me so far: once on a zone and once in a freshly
installed Solaris 10 SPARC machine.
What am I doing wrong?
TIA, Dragan
--
Dragan Cvetkovic,
To be or not to be is true. G. Boole No it isn't. L. E. J. Brouwer
!!! Sender/From address is bogus. Use reply-to one !!!
Darren Dunham
> Hi,
> I am having a problem seting up a NIS client on Solaris 10 machines in our
> NIS environment here:
> I do the standard stuff: set domainname; ypinit -c; copy
> /etc/nsswitch.nis to /etc/nsswitch.conf
> and then svcadm enable nis/client and svcadm restart name-service-cache
On sol10 GA, I couldn't reproduce the problem. I did what you did in a
zone and both getent and ypcat/ypmatch worked fine for me, both before
and after restarting name-service-cache.
I rebooted just to check SMF. No issue with services (other than the
line printer dependencies whining). Just about the only thing I'd done
in the zone prior to this is configure the DNS resolver.
--
Darren Dunham ddu...@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
Dragan Cvetkovic
> Dragan Cvetkovic <m...@privacy.net> wrote:
>> Hi,
>
>> I am having a problem seting up a NIS client on Solaris 10 machines in our
>> NIS environment here:
>
>> I do the standard stuff: set domainname; ypinit -c; copy
>> /etc/nsswitch.nis to /etc/nsswitch.conf
>
>> and then svcadm enable nis/client and svcadm restart name-service-cache
>
> On sol10 GA, I couldn't reproduce the problem. I did what you did in a
> zone and both getent and ypcat/ypmatch worked fine for me, both before
> and after restarting name-service-cache.
>
> I rebooted just to check SMF. No issue with services (other than the
> line printer dependencies whining). Just about the only thing I'd done
> in the zone prior to this is configure the DNS resolver.
>
Hmm, that's wierd. Do you have e.g. IPv6 and/or Kerberos enabled? I have
none.
Bye, Dragan
Darren Dunham
> Hmm, that's wierd. Do you have e.g. IPv6 and/or Kerberos enabled? I have
> none.
Neither of those...
Since it's only the ypmatch/ypcat hanging on you, can you 'truss' it on a
lookup? Where does it stall?
Dragan Cvetkovic
> Dragan Cvetkovic <m...@privacy.net> wrote:
>> Hmm, that's wierd. Do you have e.g. IPv6 and/or Kerberos enabled? I have
>> none.
>
> Neither of those...
>
> Since it's only the ypmatch/ypcat hanging on you, can you 'truss' it on a
> lookup? Where does it stall?
Well, it seems that eventually I did get my results back, but it was some
10-15 minutes wait.
It was hanging on
821: open64("/var/run/name_service_door", O_RDONLY) = 6
821: fcntl(6, F_SETFD, 0x00000001) = 0
821: door_info(6, 0xFF26B7E8) = 0
821: door_call(6, 0xFFBFD370) (sleeping...)
821: Stopped by signal #24, SIGTSTP, in door_call()
821: Received signal #25, SIGCONT, in door_call() [default]
821: siginfo: SIGCONT pid=706 uid=0
821: door_call(6, 0xFFBFD370) (sleeping...)
821: door_call(6, 0xFFBFD370) = 0
821: door_info(6, 0xFFBFD388) = 0
821: door_call(6, 0xFFBFD370) = 0
i.e. on door_call() for a very long time before continuing (this
SIGTSTP/SIGCONT was me puting the process in the background).
Dragan Cvetkovic
> Darren Dunham <ddu...@redwood.taos.com> writes:
>
>> Dragan Cvetkovic <m...@privacy.net> wrote:
>>> Hmm, that's wierd. Do you have e.g. IPv6 and/or Kerberos enabled? I have
>>> none.
>>
>> Neither of those...
>>
>> Since it's only the ypmatch/ypcat hanging on you, can you 'truss' it on a
>> lookup? Where does it stall?
>
> Well, it seems that eventually I did get my results back, but it was some
> 10-15 minutes wait.
>
> It was hanging on
>
> 821: open64("/var/run/name_service_door", O_RDONLY) = 6
> 821: fcntl(6, F_SETFD, 0x00000001) = 0
> 821: door_info(6, 0xFF26B7E8) = 0
> 821: door_call(6, 0xFFBFD370) (sleeping...)
> 821: Stopped by signal #24, SIGTSTP, in door_call()
> 821: Received signal #25, SIGCONT, in door_call() [default]
> 821: siginfo: SIGCONT pid=706 uid=0
> 821: door_call(6, 0xFFBFD370) (sleeping...)
> 821: door_call(6, 0xFFBFD370) = 0
> 821: door_info(6, 0xFFBFD388) = 0
> 821: door_call(6, 0xFFBFD370) = 0
>
> i.e. on door_call() for a very long time before continuing (this
> SIGTSTP/SIGCONT was me puting the process in the background).
>
And this is what happens when I reboot the machine:
bash-3.00# svcs -xv
svc:/network/rpc/gss:default (Generic Security Service)
State: uninitialized since Tue Mar 29 11:54:53 2005
Reason: Restarter svc:/network/inetd:default has not initialized service state.
See: http://sun.com/msg/SMF-8000-4D
See: man -M /usr/share/man -s 1M gssd
Impact: 9 dependent services are not running:
svc:/network/nfs/client:default
svc:/system/filesystem/autofs:default
svc:/system/system-log:default
svc:/milestone/multi-user:default
svc:/milestone/multi-user-server:default
svc:/application/print/server:default
svc:/application/print/ipp-listener:default
svc:/network/smtp:sendmail
svc:/network/ssh:default
I have to disable rpc/gss and nfs/client to let the other services run,
then I can reenable nfs/client.
As I mentioned before ypcat passwd (or any other map) takes some 5-10
minutes to succeed the first time, every other NIS service is after that
almost instant (since I am asking for different maps, I don't think that I
see the effect of name-service-cache).
If I try to use gsscred(1M) to add some certificates (as if I know what am
I doing), it sees all NIS users instantly even before the first ypcat
passwd returns. E.g.
gsscert -m diffie_hellman_640_0 -a
takes just a few seconds for all NIS users. However, even after that
enabling rpc/gss still returns "uninitalised" state.
WTH is going on here?
What do I need to do to have this bl##!y machine as a Solaris 10 NIS
client?
It doesn't even want to install Solaris 9, as the console freezes after
entering timezeone -- the same one as reported in
http://groups.google.ca/groups?selm=lmvfcpl9ak.fsf%40privacy.net
Help!!
Darren Dunham
>> 821: door_call(6, 0xFFBFD370) (sleeping...)
>> 821: Stopped by signal #24, SIGTSTP, in door_call()
>> 821: Received signal #25, SIGCONT, in door_call() [default]
>> 821: siginfo: SIGCONT pid=706 uid=0
>> 821: door_call(6, 0xFFBFD370) (sleeping...)
>> 821: door_call(6, 0xFFBFD370) = 0
Okay. Generic, hard-to-debug stuff. Maybe someone with more knowledge
of dtrace could suggest how to know what's making the door call..
> bash-3.00# svcs -xv
> svc:/network/rpc/gss:default (Generic Security Service)
> State: uninitialized since Tue Mar 29 11:54:53 2005
> Reason: Restarter svc:/network/inetd:default has not initialized service state.
> See: http://sun.com/msg/SMF-8000-4D
> See: man -M /usr/share/man -s 1M gssd
> Impact: 9 dependent services are not running:
> svc:/network/nfs/client:default
> svc:/system/filesystem/autofs:default
> svc:/system/system-log:default
> svc:/milestone/multi-user:default
> svc:/milestone/multi-user-server:default
> svc:/application/print/server:default
> svc:/application/print/ipp-listener:default
> svc:/network/smtp:sendmail
> svc:/network/ssh:default
> I have to disable rpc/gss and nfs/client to let the other services run,
> then I can reenable nfs/client.
Ugh. I know nothing of gss. And it's an inetd service? Anything in
the messages file?
I'll create another zone and see what it looks like before becoming an
NIS client.
Dragan Cvetkovic
> Dragan Cvetkovic <m...@privacy.net> wrote:
>>> 821: door_call(6, 0xFFBFD370) (sleeping...)
>>> 821: Stopped by signal #24, SIGTSTP, in door_call()
>>> 821: Received signal #25, SIGCONT, in door_call() [default]
>>> 821: siginfo: SIGCONT pid=706 uid=0
>>> 821: door_call(6, 0xFFBFD370) (sleeping...)
>>> 821: door_call(6, 0xFFBFD370) = 0
>
> Okay. Generic, hard-to-debug stuff. Maybe someone with more knowledge
> of dtrace could suggest how to know what's making the door call..
[snip]
>
> I'll create another zone and see what it looks like before becoming an
> NIS client.
Thanks Darren, I finally managed to figure out what was the problem:
ipnodes entry in nsswitch.conf. Since we don't maintain hosts via NIS, we
usually replace nsswitch.conf line for hosts with
hosts: files dns
Once I replaced the original line
ipnodes: nis [NOTFOUND=return] files
with
ipnodes files dns
things suddenly started to work. Apparently the ipnodes entry didn't matter
for Solaris 9 and below, but for some reasons is important for Solaris 10
...
I am happy again :-)
Coy Hile
under 10, i believe hostname lookups query ipnodes before hosts. I
ran into this when I changed loghost in /etc/hosts, but not in
/etc/inet/ipnodes.
Somebody mentioned in here before why this is more standards compliant
or something (eg, the rationale behind the change), but I fail to
recall what it is.
--
Coy Hile
hi...@cse.psu.edu
Dan Foster
>
> under 10, i believe hostname lookups query ipnodes before hosts. I
> ran into this when I changed loghost in /etc/hosts, but not in
> /etc/inet/ipnodes.
>
> Somebody mentioned in here before why this is more standards compliant
> or something (eg, the rationale behind the change), but I fail to
> recall what it is.
IIRC, ipnodes can handle IP v4 and v6 hosts; hosts can only do v4 hosts?
-Dan
Dragan Cvetkovic
But that raises the question why would it matter to us since we don't have
any IPv6 enabled machines here ...