Hello Everyone, 
I had similar case and we built proxies closes proximity and use mix of nfs and 
rsync to mount and delivery rpm. Then use spacewalk pre cache proxy feature. 
I mounted /var/spool/rhn-proxy/rhn NFSv4 TCP with adjustment of MSS through 
iptables. 
For configuration files delivery osad help a lot and using through same 
proxies. 

Slava. 


From: "Waldirio Manhães Pinheiro" <[email protected]> 
To: "spacewalk-list" <[email protected]> 
Sent: Wednesday, November 19, 2014 11:24:57 AM 
Subject: Re: [Spacewalk-list] Low bandwidth locations 

Ok 
Should be necessary more info to create a sample project, like bandwidth and 
other infos, although one point could be use ISS (Inter Satellite Sync) and 
bellow them proxies. At the end of the day, I believe your main problem be a 
link and not a server / servers infra structure. 

Let's wait for a gurus/experts answers about it! ;-) 

Take Care 


______________ 
Atenciosamente 
Waldirio 
msn: [email protected] 
Skype: waldirio 
Site: www.waldirio.com.br 
Blog: blog.waldirio.com.br 
LinkedIn: http://br.linkedin.com/pub/waldirio-pinheiro/22/b21/646 
PGP: www.waldirio.com.br/public.html 

On Wed, Nov 19, 2014 at 1:34 PM, Matthew Madey < [email protected] > wrote: 



We currently have 4 Spacewalk Proxies, geographically positioned to support the 
clients. Problem is, we have 8000+ clients, and they are split up between 
hundreds of locations. It's a huge environment, but we've made it work pretty 
well so far. To work around the issue of bandwidth, we've been pre-staging 
patch bundles by delivering the metadata and packages to the /var/cache/yum 
directory on all the clients, and setting the metadata expire in yum.conf to 
about 7 days. We run into trouble though when someone runs a yum clean all on a 
client, and it has to download the metadata over the slow connection. Or when 
we have to do zero day patching, which luckily the most recent one's (SSL and 
BASH) have been very small updates. We created a separate channel for that sort 
of thing, so the amount of metadata downloaded is very small. 
The traffic shaping we've done on the network layer seems to have helped a bit, 
but I'm not sure what other settings we can tune in Spacewalk to better 
throttle client requests. We've thought about turning off rhnsd on the clients 
during peak business hours, but I'd rather not go that route. 

On Tue, Nov 18, 2014 at 12:18 PM, Waldirio Manhães Pinheiro < 
[email protected] > wrote: 

BQ_BEGIN

Matthew, 
I believe be interesting know better your environment, btw, you can work with 
proxy (between your company and filial/client) or really use Spacewalk Proxy. 
With this you will probably work better, you have to check the necessity 
according the quantity of clients or the problem caused by latency. 

Do a test with one proxy in your problematic environment and enjoy! 

Let me know if works for you. 

B'Regards 

______________ 
Atenciosamente 
Waldirio 
msn: [email protected] 
Skype: waldirio 
Site: www.waldirio.com.br 
Blog: blog.waldirio.com.br 
LinkedIn: http://br.linkedin.com/pub/waldirio-pinheiro/22/b21/646 
PGP: www.waldirio.com.br/public.html 

On Tue, Nov 18, 2014 at 2:20 PM, Matthew Madey < [email protected] > wrote: 

BQ_BEGIN

All, 
I've run into a situation where my total metadata for channels has grown quite 
large (about 200MB). I've done all I can as far as channel\package management 
to reduce the size of the metadata.. 
We have a number of locations where the bandwidth to the clients is extremely 
small.. So downloading new metadata causes severe network latency on these 
clients.. We've done some traffic shaping on the network layer to reduce the 
impact, but I'm looking for other alternatives focused more around Spacewalk. 
Looking for anyone who may have a similar situation and what steps they've 
taken to mitigate the issue. Are there any sort of throttling settings 
available in Spacewalk, or does this all have to be done at the OS\Network 
layers? 



_______________________________________________ 
Spacewalk-list mailing list 
[email protected] 
https://www.redhat.com/mailman/listinfo/spacewalk-list 





_______________________________________________ 
Spacewalk-list mailing list 
[email protected] 
https://www.redhat.com/mailman/listinfo/spacewalk-list 

BQ_END



_______________________________________________ 
Spacewalk-list mailing list 
[email protected] 
https://www.redhat.com/mailman/listinfo/spacewalk-list 

BQ_END



_______________________________________________ 
Spacewalk-list mailing list 
[email protected] 
https://www.redhat.com/mailman/listinfo/spacewalk-list 
_______________________________________________
Spacewalk-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-list

Reply via email to