[Spacewalk-list] Spacewalk Failover?

[Stuart Green]

I was wrong.  It does not work.   The systemid is regenerated each
registration, so whenever you register one client with one server, you lose
registration to the other as the systemid its expecting no longer matches.

On 8 March 2016 at 10:54, Stuart Green <stuart.green at doccentrics.com> wrote:

> I have this working now.
>
> The machine's are registered on both sides and pulling updates.  The
> default config was http which has been shutdown so an erroneous result was
> being received.   I also had some configuration management files causing a
> problem, so I've created a new configuration channel on each server for
> these machines which just contains the dual up2date config file.
>
> Looks good!
>
> Cheers.
>
> On 7 March 2016 at 16:10, Stuart Green <stuart.green at doccentrics.com>
> wrote:
>
>> So I've spent a bit of time getting my 2 spacewalk servers 'connected'.
>> I have ISS mode configured so the channels are syncing between the two
>> servers, the next thing I moved to was 'failover'
>>
>> There's not much information on the web or on this list pertaining to
>> quite whether it works but documentation here suggests it can with the
>> correct version of up2date.
>>
>>
>> https://access.redhat.com/documentation/en-US/Red_Hat_Network/5.0.0/html/Client_Configuration_Guide/s2-client-config-failover.html
>>
>> The problem is the 2 url setting never sticks, the client  machine needs
>> to be registered with both spacewalk servers to receive the updates, and in
>> the process of registration the altered /etc/sysconfig/rhn/up2date file is
>> reverted.  If I put the urls back again, then shutdown the primary
>> spacewalk server and try to update from the secondary it goes back to
>> saying I'm not registered.
>>
>>
>> Does this method actually work any more or has it been superseeded?
>>
>> Cheers,
>> Stu
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20160308/dfc9f551/attachment.htm>