On Sat, 2010-08-21 at 15:40 -0700, ottomeister wrote:
Hi Otto,
Thanks for your time, seems every 6 months or so I am "almost there"
and keep getting issues different from my previous ones... anyway, as
always thanks for your help.
Lets work through your pointers....
> That might be caused by the hostname address definition in /etc/hosts. Make
> sure that the entry for the hostname points to one of the machine's external
> addresses, not to the loopback address. Do 'getent hosts `hostname`' to
> verify. If this isn't already correct, fix it and then do a 'utrestart -c'.
Already sorted this one during the install.... from your previous
advice..
getent hosts `hostname`
172.16.0.6 vader.xxxxxx.co.uk vader
ifconfig -a
eth0 Link encap:Ethernet HWaddr e0:cb:4e:a1:fe:e0
inet addr:172.16.0.6 Bcast:172.16.0.255 Mask:255.255.255.0
inet6 addr: fe80::e2cb:4eff:fea1:fee0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:372044 errors:0 dropped:0 overruns:0 frame:0
TX packets:24384 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:24343350 (24.3 MB) TX bytes:2520207 (2.5 MB)
Interrupt:36 Base address:0x2000
> >From your process listing it doesn't look like authd is running. That would
> >be
> consistent with the 22D status. After you've verified the hostname
> address, try
> this:
>
> echo amstatus | /opt/SUNWut/lib/utnetpipe `hostname` 7010
This gives a connection refused:
echo amstatus | /opt/SUNWut/lib/utnetpipe `hostname` 7010
connect() failed: Connection refused
> If that doesn't succeed then look in /var/opt/SUNWut/auth_log for clues on why
> authd won't run.
auth_log has 0 bytes (all the auth_log's do)
> If it does succeed then authd is up and the problem might be
> that authd is just not willing to talk to your DTU. Check the output
> of 'utadm -l'
sudo /opt/SUNWut/sbin/utadm -l
LAN connections: On
Use IPv4 multicast
Sun Ray interconnect framework is not configured
> and make sure that the interconnect is defined or that authd is "LAN enabled'
> (willing to accept connections from anywhere). In that's the problem then you
> should see reports in /var/opt/SUWNut/log/messages but perhaps syslog is
> not configured correctly (or is not running) and so isn't delivering those
> messages to that file.
>
> After authd is happy you'll probably need to do a 'utconfig -u ; utconfig' to
> bring the data store into a known-good condition, and then another
> 'utrestart -c' to get all of SRSS into a consistent state.
Did an unconfigure and reconfigure "just to see' and got this error (and
other like it):
Executing '/usr/bin/ldapadd -h vader -x -p 7012 -D
cn=admin,o=utdata' ...
ldapadd: attributeDescription "dn": (possible missing newline after line
4, entry "utname=multihead,utname=vader,o=v1,o=utdata"?)
ldap_add: Undefined attribute type (17)
additional info: Bad attribute type
adding new entry "utname=multihead,utname=vader,o=v1,o=utdata"
ldap_add: No such object (32)
adding new entry "o=v1,o=utdata"
> If the DTU still doesn't get past 22D after all of this, check the
> server address
> on the DTU's progress icon and make sure that it is the right address. If
> not,
> you can use 'utquery' from the server to try to figure out why the DTU is
> trying
> to talk to the wrong server. In fact you might try 'utquery' anyway,
> just to verify
> that the DTU can succesfully send traffic to the server. That would
> fail if, for
> instance, it's been given a bogus router address.
I am even cheating a bit using the GUI firmware to point at the server
direct.....
--
Regards
Sean Clarke
---------------------------------------------
SEC Consulting Limited
Phone: +44 (0)23 8040 5599
Website: http://www.sec-consulting.co.uk
Email: [email protected]
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
