Re: [Puppet Users] How to handle predictable network interface names

On Thu, Aug 25, 2016 at 09:00:46AM -0700, Luke Bigum wrote: > On Thursday, 25 August 2016 13:31:17 UTC+1, Marc Haber wrote: > > So the "database" machine wouldn't have an entry in > > networking::interfaces at all, or could one define, for example, the > > management interface in

Re: [Puppet Users] How to handle predictable network interface names

On Thursday, 25 August 2016 13:31:17 UTC+1, Marc Haber wrote: > > On Wed, Aug 24, 2016 at 09:03:16AM -0700, Luke Bigum wrote: > > The template will create udev rules from two sources. The first is > > @interfaces, which is the giant multi-level hash of network interfaces > that > > our old

Re: [Puppet Users] How to handle predictable network interface names

We are provisioning everything with vmxnet3 drivers, only weird old OVAs from vendors have non-vmxnet3, and we don't manage those with puppet. We are cloning from template and getting the same results on different vSphere/vCenter versions and instances. Not sure why they would come out different

Re: [Puppet Users] How to handle predictable network interface names

On Wed, Aug 24, 2016 at 09:03:16AM -0700, Luke Bigum wrote: > The template will create udev rules from two sources. The first is > @interfaces, which is the giant multi-level hash of network interfaces that > our old designs use. A VM might look like this in Hiera: > > networking::interfaces: >

Re: [Puppet Users] How to handle predictable network interface names

Hi Rob, On Wed, Aug 24, 2016 at 10:30:20AM -0400, Rob Nelson wrote: > We use VMware's vSphere, which still results in "random" but predictable > interface names - eth0 is now eno16780032, eth1 is now eno3359296, etc. In my experience, the numbers are rather random, different on each VM. > We've

Re: [Puppet Users] How to handle predictable network interface names

On Wed, Aug 24, 2016 at 09:20:56AM -0700, Luke Bigum wrote: > Now that I think about it, I might be able to post a sanitised version of > the module online with most of the internal stuff stripped out. It might > prove useful for educating our own staff in the concepts, as well as other >

Re: [Puppet Users] How to handle predictable network interface names

Just tell them you wanted to make sure you were satisfying the external pen testing requirements of PCI ;) On Wednesday, August 24, 2016, Luke Bigum wrote: > if I gave out the module the Security team would throttle me for > releasing what is part of a map of internal

Re: [Puppet Users] How to handle predictable network interface names

Now that I think about it, I might be able to post a sanitised version of the module online with most of the internal stuff stripped out. It might prove useful for educating our own staff in the concepts, as well as other people. It's not a 5 minute job though so if/when it's done, I'll write a

Re: [Puppet Users] How to handle predictable network interface names

It is a starting point. Many thanks for sharing what you can. Dan White | d_e_wh...@icloud.com “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” (Bill Waterson:

Re: [Puppet Users] How to handle predictable network interface names

No, not really :-( It's a very "internal" module that I forked from someone's Google Summer of Code project over 5 years ago (way before voxpupuli/puppet-network). You know all those Hiera keys about vlan tags I mentioned? The defaults are in this module and are the default VLAN interfaces for

Re: [Puppet Users] How to handle predictable network interface names

Very nice, Luke. Does the code that lets you custom-name your interfaces live in github or puppet-forge anywhere ? If not, would you be willing to share ?  I can bring brownies and/or beer to the collaboration :) Dan White | d_e_wh...@icloud.com

Re: [Puppet Users] How to handle predictable network interface names

Marc, We use VMware's vSphere, which still results in "random" but predictable interface names - eth0 is now eno16780032, eth1 is now eno3359296, etc. We've stuck with that because while it's somewhat painful (eth# is soo much easier to comprehend), it's far less painful to memorize that than

[Puppet Users] How to handle predictable network interface names

Hi, I would like to discuss how to handle systemd's new feature of predictable network interface names. This is a rather hot topic in the team I'm currently working in, and I'd like to solicit your opinions about that. On systems with more than one interface, the canonical way to handle this