| |||||||||||||
Domsch: Consistent Network Device Naming coming to Fedora 15Domsch: Consistent Network Device Naming coming to Fedora 15Posted Jan 27, 2011 11:22 UTC (Thu) by djzort (guest, #57189)In reply to: Domsch: Consistent Network Device Naming coming to Fedora 15 by tetromino Parent article: Domsch: Consistent Network Device Naming coming to Fedora 15
"Sure, that works if you are talking about one machine. Now imagine that you have 100 identical servers, each with 4 network ports. Think of the administrative overhead (every single one of those 100 machines will require a different 70-persistent-net-rules.net) and the chance of making silly mistakes.
With Fedora's approach, you will only need to write one config per hardware platform, which is vastly more manageable for large organizations."
Youve heard of scripts right? Tools like puppet or cfengine? Why are you managing 100 hand and custom built servers?
(Log in to post comments)
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 27, 2011 17:39 UTC (Thu) by jeremiah (subscriber, #1221) [Link]
My understanding of this issue, is that exists BEFORE you have the chance to get puppet or cfengine up and running. If you're doing a new image of 100 machines, your image doesn't necessarily have access to the cfengine or puppet server. Esp if the ethX might have different names. After things are up and running and you know which net dev to connect through then you can apply cfengine or whatnot to the problem, and get the 'details' of the system setup. In a lot of ways this problem probably has more to do with initrd, BusyBox, and nash more than anything else. As someone who has to do this, building complex initrd scripts is a pain in the butt, esp when it's figuring out which fracking net dev is the right one to connect through. It's not the script that's hard, it's the image->cpio->take a guess at fix->cpio->image->boot->rinse repeat that's a pain. And the less guess work taken out of that the better.
</rant></ramble>
|
|||||||||||||