| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1001.1 | | DECWET::MARTIN | | Thu Feb 13 1997 14:02 | 15 |
| What does the advfsd log file show? All that dtadvfs can know is that it failed
the security check, advfsd should tell you why the security check failed.
What does gethostbyaddr() tell you about your IP address? Does it return
"gila.tmp.com"?
You don't have the dtadvfs or advfsd source code at CSC/AT, as it is not (nor
can it be) checked in with the Digital UNIX ODE pools.
If they are not suffering any other network problems, then you should file a
QAR/CLD/IPMT against advfs_gui, and include the last few lines of both the
advfsd and the dtadvfs log files, and probably the contents of the
/var/opt/advfsd/socket/hosts.allow as well.
--Ken
|
| 1001.2 | thanks | NETRIX::"johnson@alf.dec.com" | decatl::johnson | Fri Feb 14 1997 09:45 | 21 |
| thanks for reply, will follow suggestions. if not solved by network folks
(checking the domain lookups).
We found that
# nslookup gila
indicates gila.tmp.com
** but the servier is <server>.TMP.COM
server is SUN, so he is going back to networks to see is uppercase
is significant in resolution. Or, if they should of used TMP.COM
on initial bind setup (yek)...
tryed adding a alias 'gila.TMP.COM'
and didnt seem to help, but maybe the network folks knows another
hint or 2.
sid johnson
[Posted by WWW Notes gateway]
|
| 1001.3 | | DECWET::MARTIN | | Fri Feb 14 1997 14:17 | 13 |
| I don't know if it would be helpful or not, but advfsd compares the incoming
client address from accept(2), which it then uses
inet_ntoa(3),
gethostbyaddr(3)->h_name, and
gethostbyaddr(3)->h_aliases
to compare these possibilities to all the entries in the hosts.allow file.
I've seen instances where hostname(1) reports something that is different from
anything that the two functions above return.
--Ken
|
| 1001.4 | Possible display issues that haven't been checked | LEXSS1::MACOMBER | UNIX Software Consultant | Tue Feb 18 1997 13:06 | 12 |
| Sid, et al,
I happened to read note 991 talking about dtadvfs not appearing which got
me thinking about my scenario. It's possible, and I have calls into my peers
to double check this, that the machine in question may have had it's prior
life as an NT machine. Which, if logica follows, may mean that I may have a
display problem as well. I know that the graphics adapter on the machine was
changed prior to installing UNIX 4.0a, but I can't honestly say that ECU was
run afterwards "or" that the machine used to be an NT box. I shall check this
out.
/robb.gui.challenged
|
| 1001.5 | In addition to .-1 | LEXSS1::MACOMBER | UNIX Software Consultant | Tue Feb 18 1997 13:16 | 1 |
| A couple more things:
|
| 1001.6 | Some more input | ASABET::nqsrv113.nqo.dec.com::Workbench | | Tue Feb 18 1997 15:24 | 15 |
| One of my collegues gave me the following input:
>That 1000 at Monster board was a NT system before I loaded unix. When I did
>the install, the gui never came up due to a graphics compatability issue with
>the inbedded graphics adapter. Don installed a PCI graphics card and got X to
>start.
>The next time I saw the system is when I walked in with you. The 1000 has the
>firmware from the 3.7 or 3.8 CD and the ECU is rev 1.10, which is current.
>
>The system itself is a very old 1000, so there maybe some issues with the rev
>of the motherboard.
For what it's worth.
/robb.still.notfixed
|
| 1001.7 | Presto! (wha happened?) | ASABET::nqsrv217.nqo.dec.com::Workbench | | Wed Feb 19 1997 22:14 | 23 |
| Well,
A solution has been found. The problem with the solution is I can't figure
out what is was that I did that fixed the problem. (drat!)
Here's what I "thought" I did. When I visited the customer today, the first
thing I did was look, once again, at the gui log file. Then I did an nslookup
to verify that, in fact, gila.tmp.com was returned. Then I pinged both
gila.tmp.com and gila's IP address, both sucessfully. I did and arp -a and saw
appropriate entries. I then looked at the /etc/hosts file and, noticing a few
oddities - like two entries for localhost and two entries for gila: one saying
just gila and the other additionally specifying gila.tmp.com - I decided to
review the entire hosts file. Just for clarity's sake I sorted the hosts file
to get a resonable look at the numerical IP addressing. After closing the
hosts file, I ran dtadvfs& again and guess what: it worked. I then put the
original hosts file back in place and ran dtadvfs& again and it worked. I have
no idea what changed.
I was able to manipulate the /var/opt/advfsd/socket/hosts.allow file to
manage the other host in the environment so I knew that hosts.allow was O.K.
but I still have no idea what solved the problem. Ghost in the machine!?
/robb.glad.curious
|