Synchronizing a failover group
I recentl;y upgraded my primary server to version 4. I then upgraded a backup server and tried to synchronize it to the primary but for some reason it keeps telling me that I need to upgrade the secondary. I have removed the sunray software and re-installed it several times now but always with the same result.
When I execute the "utdssync" command I see the following...
# ./utdssync
... server sunray-primary.domain.edu is already using the new SRDS default port.
Error: SunRay software on server sunray-secondary.domain.edu has not been upgraded.
You must upgrade all the servers within the failover group to
2.0 or later and have the secondary servers configured properly before
you can transition to the new SRDS port.
I have checked each log and see nothing with the appropriate time stamps so I don't have a clue...
Any advice would be appreciated...I have googled and see nothing so far.
Jon
Message was edited by:
Jon_Oliver
# 2
The message is caused by a bug in utdssync. It's looking for a very specific string in a response from the remote server, and that string has been changed (by accident, I bet) in SRSS 4.0. So utdssync does not interpret the response correctly.
However, it's unlikely that you need to run utdssync anyway. All it does is to make sure
that the Sun Ray DS instance on each of the servers in the group is listening on port 7012 rather than on the default LDAP port (389) that the Sun Ray DS used to use in releases prior to 2.0. You can check that the DS is using 7012 by grep'ing for 'admin.server.port' in /etc/opt/SUNWut/utadmin.conf on each server. The result should be:
% grep admin.server.port /etc/opt/SUNWut/utadmin.conf
admin.server.port= 7012
# 4
> I look at the sunray web gui and it still says that
> my secondary server is disabled and when I run the
> utreplica, it fails each time with a message that it
> can't syncronize (sic).
That message means that the initial attempt to populate
the DS replica on the new secondary by pulling a copy
from the primary server failed. The easiest way to get
more detail about why it failed is to re-run what 'utreplica'
tried to do under the hood, which is
/opt/SUNWut/srds/sbin/utpulld -o
The result of running that should give some clues about
where to look next.
