Pete Orrall wrote:>> So, at which stage are you in w/ regards to adopting systemd? Are you >> still >> ridiculing it, violently opposed to it, or have you mellowed to it? > > I've never had to write my own init scripts before so I'm not feeling > the pain of others, but having professionally managed machines running > SystemD for a while now honestly I don't mind it. While the language > used (units, targets) is confusing and documentation could be better, > there are some things I like about it more than SysVInit. >Don't look at me - I still *loathe* systemd. Change for no other reason than to put it on your resume, and write papers about. Examples: is it service, or target, and where of many places do I have to look to find a given service name? Why change names, such as rpc-idmapd to nfs-idmapd? And I've just been fighting today, because I have to munge the MAC address for a workstation, because they have old software that is very usefull, and there's no budget to pay the company that bought the software $15k (no kidding) so that they can shift the license to the new workstation, and that's tied to eth0 and the MAC. And *why* random NIC names? Quick, you've got servers from 5 manufacturers, of different ages... what's the NIC going to be called? Do names like enp5s0 offer any convenience to *anyone* not a hardware engineer? And the binary message log.... At home, I'm staying on CentOS 6 until it EoLs. mark
I know this is systemd-punching day, but at least get your information straight. On Mon, Apr 10, 2017 at 03:38:03PM -0400, m.roth at 5-cent.us wrote:>Why change names, such as rpc-idmapd to > nfs-idmapd?Unrelated to systemd, as far as I can tell. Fedora adopted new names that made more sense, and it was incorporated into RHEL7.>And I've just been fighting today, because I have to munge the > MAC address for a workstation, because they have old software that is very > usefull, and there's no budget to pay the company that bought the software > $15k (no kidding) so that they can shift the license to the new > workstation, and that's tied to eth0 and the MAC. > > And *why* random NIC names? Quick, you've got servers from 5 > manufacturers, of different ages... what's the NIC going to be called? Do > names like enp5s0 offer any convenience to *anyone* not a hardware > engineer?Unrelated to systemd. This actually started happening in RHEL6 with the biosdevname feature. systemd can handle the NIC naming stuff, but it started happening well before systemd appeared in RHEL. Having consistent device names is helpful when you've got more than one NIC and you don't want to rely on the order in which the network driver is loaded to define the interface name. -- Jonathan Billings <billings at negate.org>
Le 10/04/2017 ? 21:57, Jonathan Billings a ?crit :> Having consistent device names is helpful when you've got more than > one NIC and you don't want to rely on the order in which the network > driver is loaded to define the interface name.On my Slackware servers (no systemd, no funny network interface names), I just edit /etc/udev/rules.d/70-persistent-net.rules and switch eth0 and eth1 (and eth2 etc.) if needed. Keep It Simple. -- Microlinux - Solutions informatiques durables 7, place de l'?glise - 30730 Montpezat Web : http://www.microlinux.fr Mail : info at microlinux.fr T?l. : 04 66 63 10 32
Jonathan Billings wrote: <snip>>> And *why* random NIC names? Quick, you've got servers from 5 >> manufacturers, of different ages... what's the NIC going to be called? >> Do names like enp5s0 offer any convenience to *anyone* not a hardware >> engineer? > > Unrelated to systemd. This actually started happening in RHEL6 with > the biosdevname feature. systemd can handle the NIC naming stuff, but > it started happening well before systemd appeared in RHEL. > > Having consistent device names is helpful when you've got more than > one NIC and you don't want to rely on the order in which the network > driver is loaded to define the interface name.In what universe are those "consistant" device names, as opposed to eth[0...]? And how could it help automated scripts that you can run on *any* system you're administering? mark
> And *why* random NIC names? Quick, you've got servers from 5 > manufacturers, of different ages... what's the NIC going to be called? Do > names like enp5s0 offer any convenience to *anyone* not a hardware > engineer?As someone else had stated, it's not related to SystemD but Fedora/RHEL has changed the way they handle some things. NICs, for instance, are no longer named after the device number (eth0, eth1, eth2, etc.) but after the *driver* name. Yes, it's a change but it also makes sense. IIRC this is how FreeBSD handles NIC names. -- Pete Orrall pete at cs1x.com www.peteorrall.com "If there isn't a way, I'll make one."
On Tue, Apr 11, 2017 at 08:09:01AM -0400, Pete Orrall wrote:> > And *why* random NIC names? Quick, you've got servers from 5 > > manufacturers, of different ages... what's the NIC going to be called? Do > > names like enp5s0 offer any convenience to *anyone* not a hardware > > engineer? > > As someone else had stated, it's not related to SystemD but > Fedora/RHEL has changed the way they handle some things. NICs, for > instance, are no longer named after the device number (eth0, eth1, > eth2, etc.) but after the *driver* name. Yes, it's a change but it > also makes sense. IIRC this is how FreeBSD handles NIC names.FreeBSD uses the driver in the name, such as bge0, em0, and so on, as opposed to bge0 or em0, depending upon the make of the card. -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
On Tue, Apr 11, 2017 at 08:09:01AM -0400, Pete Orrall wrote:> > And *why* random NIC names? Quick, you've got servers from 5 > > manufacturers, of different ages... what's the NIC going to be called? Do > > names like enp5s0 offer any convenience to *anyone* not a hardware > > engineer? > > As someone else had stated, it's not related to SystemD but > Fedora/RHEL has changed the way they handle some things. NICs, for > instance, are no longer named after the device number (eth0, eth1, > eth2, etc.) but after the *driver* name. Yes, it's a change but it > also makes sense. IIRC this is how FreeBSD handles NIC names.It's true that FreeBSD names their network interfaces after the driver. But the consistent device naming in Linux comes from slot index numbers, physical location and even the MAC (if so configured), and not what driver it uses. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html#sec-Naming_Schemes_Hierarchy -- Jonathan Billings <billings at negate.org>
On Mon, 2017-04-10 at 15:38 -0400, m.roth at 5-cent.us wrote:> At home, I'm staying on CentOS 6 until it EoLs.Production and development +1 Then FreeBSD ? -- Regards, Paul. England, EU. England's place is in the European Union.