Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Alan McKinnon]

On 30/09/2013 12:32, Joost Roeleveld wrote:
> On Monday 30 September 2013 10:01:32 Alan McKinnon wrote:
>> On 30/09/2013 06:14, Walter Dnes wrote:
>>>   If the udev people had made "net ifnames=0" the default, and allowed
>>>
>>> the small percentage of multi-nic machine admins to set "net.ifnames=1",
>>> this would not have been an issue.  Some corner case exotic setups
>>> require complex solutions... no ifs/ands/ors/buts.  All the complaining
>>> you hear is from the other 99% who's setup worked just fine with the
>>> simple solution, suddenly finding the complex solution rammed down their
>>> throats.
>>
>> No, that is just plain wrong.
>>
>> Having interfaces on a multi-nic host come up as ethX where X is a
>> mostly random number is just so broken it beggars belief. Trust me, it
>> is zero fun when it happens and what makes it even worse if you have no
>> warning at all beforehand.
>
> I trust you, but on my multi-nic systems, I found a better solution :)
> As I use Xen to virtualize my systems and as I don't want to have multiple
> network cables running side-by-side, I started using VLANs.
>
> I know have all the NICs names eth1,eth2,...ethn.
> I throw them all as a bonded network device: bond0 (the other ends go into a
> switch supporting bonding network ports)
> then on top of that, I have VLANs with distinctive names (lan, dmz, guest,
> vm,...) and link these as required to different Xen-domains.
>
> When the network names get renamed suddenly to the "non-predictive" scheme, my
> system refuses to boot.
> Before that, I would use mac-addresses to link ethx devices to names that make
> sense to me. (see above for the names)


The worst case that comes to mind was a three zone netflow collector
plus the first nic on our management range.

If you're familiar with old netflow versions you'll know it is UDP from
the router and is touchy about addresses. So we had incoming netflow
from three ranges each hitting a dedicated nic and this all worked
marvellously for years and years.

One day after a routine maintenance window the box came up with all 4
nics scrambled and who knows what was now assigned to what. Forget ssh
to log in and fix it - nothing was listening. That took very senior
sysadmins on site to deal with, the regular maintenance guy was in way
over his head.

Business were OK with losing 15 minutes billing and stats data in a
maintenance window. They were definitely not OK with losing several
hours of it because someone thought assigning names on a
non-deterministic discovery order was a good idea.

One thing about Dell hardware - you always know exactly what each nic is
connected to on the motherboard so with that info the new names are
predictable (consistent is actually the better term). Using MAC
addresses for the same purposes is clunky and unwieldy, the MACs have to
be recorded somewhere and you still don't know which MAC goes with which
physical socket. With bus numbers you do know.


-- 
Alan McKinnon
alan.mckinnon@×××××.com