The problem is that the same uttsc binary that fails with wts1 has no problem with any other wts.
I looked at snoop output, filtering the DNS server. My resolv.conf search path has 3 entries. Lookup of wts1 fails in domain1, fails in domain2, and then succeeds in domain3. I thought, "aha! That must be why uttsc is failing. It's failing on domain1 and then not trying domains 2 or 3." The problem is two-fold: my other SRS has the same search path order and the problem doesn't exist there. The other is that I rearranged the search path to put the domain of wts1 first and uttsc still fails. The problem is that I can't dig deeper into /opt/SUNWuttsc/lib/uttsc-bin to see how it's doing name resolution. I also can't alter how it does name res. So I think I know why it's failing but I'm not sure what I can do about it. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jim Klimov Sent: Thursday, December 20, 2012 12:41 PM To: [email protected] Subject: EXT :Re: [SunRay-Users] riddle me this: interesting uttsc failure problem Just in case: are the name resolution set up the same, after all? /etc/nsswitch.conf (hosts line), /etc/hosts and /etc/ipnodes maybe, /etc/resolv.conf (for DNS) or LDAP/NIS backends come to mind. Make sure they are all the same, and if DNS is used - especially ISC BIND - that it is not configured with split views (when replies depend on requesting client's address or other authorization). This per se is not bad and is useful and convenient, except that both your SRS servers (all IP addresses thereof) should be treated as the same DNS-view zone for "wts" and "wts.fqdn" requests. HTH, //Jim Klimov _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users Possibly important correction about snoop: forget what I wrote below. If I snoop the destination WTS IP and do "uttsc WTS1" or "uttsc WTS1 FQDN", I get zilcho. Even in verbose mode. If I do "uttsc IP", I get back what you'd expect: a conversation between the SRS and the WTS. It doesn't appear to be a firewall or the WTS blocking a connection from my SRS because I can get to the WTS via the IP. It doesn't appear to be my SRS because I can get to other WTSs. It doesn't appear to be a name resolution problem because even using the FQDN doesn't work. Also, non-fully qualified names of other WTSs work. It doesn't appear to be patching as another T2000 was patched with the same patchset and the problem doesn't occur there. The fact that snoop doesn't pick up *any* traffic between the SRS and WTS is telling...but I don't know what it's telling me. -----Original Message----- From: Nishimura, Scott L (ESS) Sent: Thursday, December 20, 2012 7:51 AM To: [email protected] Subject: riddle me this: interesting uttsc failure problem I have an interesting uttsc problem [I used a slightly different word than "interesting" yesterday]: 2 SRSs in a FOG serverA [T1000] and serverB [T2000] have been patched with the latest cluster. When I run /opt/SUNWuttsc/bin/uttsc to connect to a particular WTS [call it WTS1], I get inconsistent results SRS WTS result B WTS1 Failed to connect B WTS1 [FQDN] Failed B WTS1 IP success A WTS1 success A WTS1 [FQDN] success A WTS1 IP success So my fails occur when using SRS B and using a name [FQDN or not]. I tried connecting, from B, to other machines in the domain: no problem. The WTS is in another state. So I tried connecting to a WTS in another state [not the same state as the problematic one as I don't have another one there]: no problem. I ran a snoop trace: if I try to connect to the name, the trace contains only the IP. If I try to connect to the IP, the trace only contains the name. But in neither case do I see anything that stands out as a cause. I used the soft client with the extended menus to get an xterm and ran my tests from there since that most closely mimics what the TC is doing [similar environment variables]. Any ideas? This is a weird one. So close after patching I want to say that's the culprit but that doesn't explain why 03 doesn't have the problem nor why connections to other WTSs are fine. I did notice that A is a T1000 and B is a T2000. Also, 08 has IPv6 enabled on the same interface as IPv4; 03 has no IPv6. But it's been this way for a long time, not just recently. At first glance it seems to be a name lookup problem but if so 1) the FQDN should work and 2) that doesn't explain why no other WTS in the same domain has that problem. Ping and nslookup work on the unqualified name. Traceroute fails to complete but it fails on both A & B. It's almost as if that one particular server's name is on a "deny" list of some sort. I compared the size and date of uttsc-bin between A & B: same. I compared the ldd output of uttsc-bin between A & B: same. TIA Scott _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
