Unable to get any httprequests: Unable toretreive netstg2.imgfile

[Shabazian, Chip]

> Then it wouldn't matter much what the timeout is, if eth1 comes up and
we can get the ks file from it
>(Or later, can get the install source) and eth0 is still dithering
around, well we're on the way with
> eth1 and who cares?

This doesn't work in environments such as a DMZ environment where you
have to make sure that the one NIC (out of 3, 4, or more) that is on the
only subnet that allows this traffic, is the one that is used.

Also, this particular problem isn't whether or not you are accessing the
right NIC, but the problem that pump times out before portfast turns the
port up.  It shouldn't matter if you have one or 20 NIC's, they should
all have the same portfast problem.

Dialog is good though, if we keep discussing the core issue and come up
with a good resolution, we can get this incorporated into the process
somewhere to make sure the problem is worked around.

-----Original Message-----
From: kickstart-list-bounces at redhat.com
[mailto:kickstart-list-bounces at redhat.com] On Behalf Of John Summerfield
Sent: Thursday, May 17, 2007 3:45 PM
To: Discussion list about Kickstart
Subject: Re: Unable to get any httprequests: Unable toretreive
netstg2.imgfile

Shabazian, Chip wrote:

> Now, *I* sure would like to see the timeout for pump increased from 30

> seconds to 60 seconds, but that would probably piss off even MORE 
> people since I'm sure there are a lot more people who get frustrated 
> waiting 30 seconds for pump to timeout during boot if their dhcp 
> server is down, or if they have more than one interface and don't know

> how to turn off dhcp on the unused interfaces, etc.


If my dhcp server's down, I got problems regardless of the timeout.

>  
> I guess the ideal solution would be an option for pump that does 
> increase the timeout that could be passed from anaconda, or an option 
> in anaconda such as dhcpretry=X where you could set the system to 
> retry dhcp X number of times without recycling the NIC and starting 
> the negotiation dance again.
>  
> But at the end of the day, please keep in mind that these are all work

> arounds for the Cisco STP feature, that while valuable, is the actual 
> root cause.

What _I_ would like to see is an attempt to use them all, configure all
the network interfaces in parallel.

Use the first one that comes up and allows access to the ks files.

Then it wouldn't matter much what the timeout is, if eth1 comes up and
we can get the ks file from it (Or later, can get the install source)
and eth0 is still dithering around, well we're on the way with eth1 and
who cares?




-- 

Cheers
John

-- spambait
1aaaaaaa at coco.merseine.nu  Z1aaaaaaa at coco.merseine.nu

Please do not reply off-list

_______________________________________________
Kickstart-list mailing list
Kickstart-list at redhat.com
https://www.redhat.com/mailman/listinfo/kickstart-list