On Sat, Aug 21, 2010 at 4:28 AM, Sean Clarke
<[email protected]> wrote:
> 22D points me towards something fundamental with the services (26D I think
> would be the gdm config) - I'd be happier if it was gdm!! :o)
>
> I get errors like:
>
> ./utpolicy
> ERROR: Could not retrieve policy.
>
> /utxconfig
> Error: could not connect to admin server
>
> and I just noticed when I run utconfig it has trouble:
>
> Unique "/etc/opt/SUNWut/gmSignature" has been generated.
>
> Restarting Sun Ray Data Store ...
> Stopping Sun Ray Data Store daemon
> Sun Ray Data Store daemon stopped
> Starting Sun Ray Data Store daemon .
> Sat Aug 21 11:58 : utdsd starting
> Adding user admin ...
> Failed to add user(s) to the list
> ERROR: Could not retrieve policy.
> ERROR: Could not retrieve policy.
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'.
>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
If that doesn't succeed then look in /var/opt/SUNWut/auth_log for clues on why
authd won't run. 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'
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.
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.
OttoM.
__
Disclaimer: I am employed by Oracle. The statements and opinions
expressed here are my own and do not necessarily represent those
of Oracle Corporation.
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
