[Spacewalk-list] Spacewalk 2.1 - Redundancy and multi-DC kickstarts

Vamegh Hedayati vamegh at gmail.com
Fri May 16 04:23:41 UTC 2014


Hi,

I have since got kickstart via the proxy servers working, I am very
surprised that the spacewalk proxy servers are not given an option to
kickstart straight on build. The process to get it working is fairly
straightforward.

For anyone else looking for a similar solution, it turns out the proxy
server has nearly everything you need already linked to it including the
cobbler directory from the main spacewalk server and the proxy server has
re-write rules which rewrites most things to point to itself.

To get the spacewalk proxy server able to build a few simple steps are
necessary:

Build the server as per the guide here:
https://fedorahosted.org/spacewalk/wiki/HowToInstallProxy Once built do the
following

On the Spacewalk Server:
1. edit /etc/cobbler/rsync.template add the following:

[spacewalk-tftp]
    path    = /var/lib/tftpboot
    comment = PXE TFTPBOOT Directory

2. edit /etc/cobbler/settings change
manage_rsync: 1

3. check /etc/xinet.d/rsync make sure disable is no. Restart xinetd if
necessary

4. cobbler sync - will make live rsync changes.

On the proxy Server (centos in this case)

1. Install the following packages:
yum install yum-utils xinetd tftp-server rsync dhcp dhcp-common

2. edit /etc/xinet.d/tftp set disable to no and start/restart xinetd

Once these basic steps are done I have just written 2 very simple scripts
for managing dhcp and rsync, which I have made available here:

https://github.com/vamegh/spacewalk-proxy-kickstart


On every update of the main spacewalk server (new profiles etc) just run
the proxy-rsync script to synchronise the boot entries with the proxy
server.

The scripts are very basic and I just wrote them as a proof of concept /
initial test. I have written a complete hands off automated build system
which requires the dhcp server to be reset on each run to keep things clean
- hence why I reset dhcp for example (cobbler sync also does this if
cobbler is configured to manage dhcp)

1 issue I have seen is that the server will build but does not register
itself with the proxy server - after it is built running rhn_register will
register the server with the proxy server, but this should be easy to
automate / keep build completely hands off. (I havent as yet had the time
to look into the cause)

Also I do not currently have dns configuration for the proxy instance the
rsync script requires both hostname and ip and the scripts are reliant on
ip for this reason (this will probably need adjustment if you plan to use
the scripts) - I will be running dns and ntp on the proxy servers, this is
not reflected in the scripts (they are just extremely basic tests please
keep this in mind)

Considering it is this easy to actually get the proxy to kickstart servers,
I am really surprised this is not done automatically on proxy installation
- or the option provided at least, probably in a future version - for
anyone that is running spacewalk 2.1  - the above is a simple solution that
will work.

I have still not looked at ISS - if any of you have or are using it and
have any further information to share about Redundancy I would really
appreciate it.

Kind Regards,

Vamegh



On 14 May 2014 11:38, Vamegh Hedayati <vamegh at gmail.com> wrote:

> Hi All,
>
> I have read through quite a bit of documentation with regards to the two
> things we are trying to achieve with spacewalk.
>
> 1. The main thing we require is the ability to build servers from another
> DC (lets say dc2) but to still have the profiles registered with the
> original spacewalk server in DC1.  It is just not possible to kickstart
> from the original DC as layer 2 transport between the 2 dc's does not exist
> but layer 3 does, that is to say dc1 cannot respond to dhcp requests from a
> server in dc2 as it does not see the mac address sent, but dc1 does see dc2
> and vice-versa when an ip address has been assigned to the server.
>
> 2. We also need redundancy even if it is a failover pair.
>
> Before I go into detail, some background information:  The spacewalk
> installation is updated to 2.1 and uses PostgreSQL, its a default build
> using the instructions provided on the spacewalk wiki, but all of the
> server builds are automated and use the spacewalk api where necessary to
> kickstart (using snippets) and to de-register a server being removed.
> Practically all of the client servers are Centos 6 and the spacewalk server
> itself is on centos 6.5. Spacewalk Proxy servers are not currently deployed
> - but are being actively tested for deployment to Separate DC's.
>
> There are a few ways to achieve what I need, from what I can tell but what
> I really need is more information.
>
> 1. Kickstart across multiple DC's:
> Has anyone got Spacewalk Proxy to kickstart servers using its own
> tftp/dhcp and can provide any guidance for this ?
> Has anyone setup spacewalk proxy and used cobbler replication ?
> Another possible solution is to use the api : Namespace: kickstart.profile
> -> Method: downloadRenderedKickstart (although this should not be necessary
> as the proxy should see the profiles from the master spacewalk instance)
> Has anyone used ISS in master to master replication method and use
> different masters to kickstart servers but shared the client information
> across all of the spacewalk instances ?
>
> I guess most importantly what would be your recommended method ? What
> method should I use that will be easiest to maintain and known to work.
>
> 2. Redundancy
> There is not much information out there about ISS and either Master to
> Master replication or Master to Slave replication. In fact there is very
> little information about ISS and its state. I have read a few comments that
> say it is virtually impossible to set up master to master replication for
> spacewalk - is this true still for spacewalk 2.1 ?  I have so far come
> across the following bits of information:
>
> http://www.redhat.com/pdf/ISS_Best_Practices_Whitepaper.pdf
> https://fedorahosted.org/spacewalk/wiki/InterSpacewalkServerSync
>
> The redhat whitepaper briefly touches on master to master replication
> (Bi-directional Sync) - but not in any great depth.
>
> I have as yet  not configured ISS, will it also do DB replication across
> the spacewalk server instances ?
>
> Are there any other methods to achieve spacewalk redundancy (a failover
> pair is fine) ?
>
> Thank you in advance,
>
> Kind Regards,
>
> Vamegh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20140516/0a518223/attachment.htm>


More information about the Spacewalk-list mailing list