First I found out that under Linux I can alias one network adaptor to two addresses - so in theory my servers can exist in the 192.168.0.0 and 192.168.1.0 spaces at the same time, with only one adaptor - nice Means nearly no movement of machines for the next TPR meet - which has to be a good thing :nod:
Next I decide to move my dual MP1800 server to Fedora and stuff some more disks in it. Now call me lazy if you like, but since under Linux I have no licensing / code key implications, do I really need to carry CDs and put them in drives?
OF COURSE NOT!
I can just put the ISO images on an NFS share, export the share, and the machine dutifully finds and loads them - as quick as it would from CD. Easy? Oh Yeah Baby! Less hassle? :nod:
So I pose this question to the rest of you because it eludes even me.
First, the physical architecture…
My PCs (AMDs running FC2)
– local Netgear FW / router
---- building switches and router… All the latest DLINK and all at 100/1000 FDX.
------ Out to ISP
I’m running into DNS timeout/resolution errors randomly.
For example, running ‘up2date’ and getting only a couple updates from Redhat at a time works well. Big updates time out or fail to resolve and python just croaks.
I have put the the IP addresses (in order) down the chain from me to the ISP’s ‘slave DNS’, named 'cache… blah…blah.uu.net (which may be the problem).
Any suggestions with either DNS timeout or resolution order… OR… should I just go to Redhat and pull down the RPMS directly and run a shell script to do the update by hand.
This had been a bit of a nag… I want the latest updates to guarantee the code I’m working on is good to go for all FC2 core and FC2 released updates.
Suggestions??
Thanks.
Chuck
/edit/ PS: Posting the DVD iso works GREAT too! /end edit/
I get this too on large updates. I think its up2date which is the problem. 20 updates or so seems ok, larger updates things seem to grind to a halt - sometimes
I attack the problem by downloading the initial updates in smaller bites 10 or so at a time which seems to work, thereafter there aren’t that many updates coming out (unlike Micro$oft) so the problem is more manageable.
Thanks, that was something I thought of, but was worried about interdependencies, unless all the rpm interdependency resolution is/was the problem in the first place. If you have proven it works, then I shall do a fast reload to have a good clean slate and get to it (I can load the box from cold, set in the DNS’s and be running within an hour… LOL)
Anyway, here’s my solution for my network of Fedora machines:
I use ftp (fast) to pull down all the updates to a samba share (yes, I have the odd windows box too).
Then, I just cd to the updates dir and use rpm from the command line to update each box on the network using the -F freshen switch:
rpm -Fvh *.rpm
Fast, simple and efficient way of updating multiple boxes from one central repository. Of course you could also point up2date to a local rpm repository on your HD (see the commented out entry at the end of the config file). Either way, The trick is not to use up2date to actually pull the RPMs from the remote server.
Thanks, will do first chance I get… biggest problem I have is getting the kernel source to ‘install’… it says it’s installed, but not located anywhere… Fvh will fix that… i am slowly remembering RPM now.
Means nearly no movement of machines for the next TPR meet - which has to be a good thing :nod:
