Re: [CentOS] NetworkManager on servers

[Simon Matter via CentOS]

> On 09/02/2020 23:55, Nicolas Kovacs wrote:
>
> Hi Nicolas,
>
> [snip]
>
>> Maybe there's a reason to make NetworkManager more or less mandatory
>> from now on, but I don't see it. So I thought I'd rather ask on this
>> list.
>
> Like you, I read about NetworkManager becoming the default tool for
> CentOS 8. So I sat down with a colleague to figure out how we could use
> NetworkManager, and convert our existing network configs (on CentOS 6
> and 7) to work with NetworkManager.
>
> I'm sad to report that we ran into at least 3 issues (listed below). We
> found solutions to the first two, but the last one was a show-stopper,
> and we came to the conclusion that for servers, NetworkManager is still
> overkill, and for us, actually unusable. So even on CentOS 8, we will
> keep using the legacy scripts.
>
> 1. When NetworkManager activates interfaces, it does not wait for IPv6
> DAD to complete. This makes systemd reach the "network-online" target
> before IPv6 is fully initialised, and some daemons fail to start. We
> eventually found a work-around, but not before I'd lost some of my hair.
>
> 2. NetworkManager doesn't know how to activate dummy interfaces from
> ifcfg-dummy* files. You have to create dummy interfaces directly in
> NetworkManager. This is not a problem on CentOS 8, but on CentOS 7,
> there is a subtle issue with loading the dummy module that makes things
> fail at boot. We again found the solution, but it's annoying that none
> of it was documented.
>
> 3. Some of our servers run full routing daemons (BIRD), and have
> multiple route tables. On these, when we start NetworkManager, it
> attempts to read the entire route tables into memory using the netlink
> API. This makes it log lots of errors. Then, NetworkManager's RAM usage
> goes up and up, going to over 3 GB!! Finally, it barfs and dies. And
> then systemd starts it again, and it goes and does the same.
>
> We have NOT been able to find any solution to this stupidity of
> NetworkManager. And so we have made the choice to abandon it, and remain
> with legacy network scripts.

Thanks for confirming that NetworkManager is not the solution for
everyone. To me it seems that NetworkManager was developed by laptop users
for laptop users and that's why it is what it is today. Useful for
laptops/desktops and simple server setups.

Unfortunately, instead of fixing/refactoring the whole bash networking
script mess, another new project was started instead, called
systemd-networkd :-)

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 7 : network interface renamed from eth0 to eth1 after reboot

[Nicolas Kovacs]

Le 10/02/2020 à 16:12, Leroy Tennison a écrit :

There may be ways to force NIC naming, I've done so but only on Ubuntu so
you'll need to do the research if it's important to you.  Things to look for
based on my experience: 70-persistent-net.rules, net.ifnames=0,
biosdevname=0.


That's exactly the solution I described in detail in my blog article.

:o)

--
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Site : https://www.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
Mob. : 06 51 80 12 12
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 7 : network interface renamed from eth0 to eth1 after reboot

[Brian Reichert]

On Mon, Feb 10, 2020 at 03:12:11PM +, Leroy Tennison wrote:
> There may be ways to force NIC naming, I've done so but only on Ubuntu so 
> you'll need to do the research if it's important to you.  Things to look for 
> based on my experience: 70-persistent-net.rules, net.ifnames=0, biosdevname=0.

I cheated; I use NIC teaming, and before starting networking, run a
script that iterates over NICs, picking up their current device
names, and scripting the if-cfg* files.

I had to do this when a few years ago, Dell was getting clever about
renaming NICs aggressively, and nothing could trust 'eth0' anymore.
Now, I always get a 'bond0'.

(Oh, and I also disabled NetworkManager, because, like systemd, it
tries to be Too Clever for it's own good.)

Overkill for most, I admit, but it make my installation media much
more portable.

-- 
Brian Reichert  
BSD admin/developer at large
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] NetworkManager on servers

[Anand Buddhdev]

On 09/02/2020 23:55, Nicolas Kovacs wrote:

Hi Nicolas,

[snip]

> Maybe there's a reason to make NetworkManager more or less mandatory
> from now on, but I don't see it. So I thought I'd rather ask on this list.

Like you, I read about NetworkManager becoming the default tool for
CentOS 8. So I sat down with a colleague to figure out how we could use
NetworkManager, and convert our existing network configs (on CentOS 6
and 7) to work with NetworkManager.

I'm sad to report that we ran into at least 3 issues (listed below). We
found solutions to the first two, but the last one was a show-stopper,
and we came to the conclusion that for servers, NetworkManager is still
overkill, and for us, actually unusable. So even on CentOS 8, we will
keep using the legacy scripts.

1. When NetworkManager activates interfaces, it does not wait for IPv6
DAD to complete. This makes systemd reach the "network-online" target
before IPv6 is fully initialised, and some daemons fail to start. We
eventually found a work-around, but not before I'd lost some of my hair.

2. NetworkManager doesn't know how to activate dummy interfaces from
ifcfg-dummy* files. You have to create dummy interfaces directly in
NetworkManager. This is not a problem on CentOS 8, but on CentOS 7,
there is a subtle issue with loading the dummy module that makes things
fail at boot. We again found the solution, but it's annoying that none
of it was documented.

3. Some of our servers run full routing daemons (BIRD), and have
multiple route tables. On these, when we start NetworkManager, it
attempts to read the entire route tables into memory using the netlink
API. This makes it log lots of errors. Then, NetworkManager's RAM usage
goes up and up, going to over 3 GB!! Finally, it barfs and dies. And
then systemd starts it again, and it goes and does the same.

We have NOT been able to find any solution to this stupidity of
NetworkManager. And so we have made the choice to abandon it, and remain
with legacy network scripts.

Regards,
Anand
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] KVM clone

[Leroy Tennison]

Since you asked, the circumstance warranting registry editing is cloning a 
running system to create a new instance for a different purpose while bringing 
it up on the same subnet.  Yes, it's a little messy but it works.  And thanks 
for the pointer about virt-sysprep.


From: CentOS  on behalf of Charles Polisher via 
CentOS 
Sent: Saturday, February 8, 2020 11:58 AM
To: Leon Fauster ; CentOS mailing list 


Harriscomputer

Leroy Tennison
Network Information/Cyber Security Specialist
E: le...@datavoiceint.com


[cid:Data-Voice-International-LOGO_aa3d1c6e-5cfb-451f-ba2c-af8059e69609.PNG]


2220 Bush Dr
McKinney, Texas
75070
www.datavoiceint.com


This message has been sent on behalf of a company that is part of the Harris 
Operating Group of Constellation Software Inc.

If you prefer not to be contacted by Harris Operating Group please notify 
us.



This message is intended exclusively for the individual or entity to which it 
is addressed. This communication may contain information that is proprietary, 
privileged or confidential or otherwise legally exempt from disclosure. If you 
are not the named addressee, you are not authorized to read, print, retain, 
copy or disseminate this message or any part of it. If you have received this 
message in error, please notify the sender immediately by e-mail and delete all 
copies of the message.





Subject: [EXTERNAL] Re: [CentOS] KVM clone

On 2020-02-07 20:14, Leon Fauster via CentOS wrote:
> Am 07.02.20 um 17:43 schrieb Leroy Tennison:
> > Yes, have done it a few times.  If you need it to have a different IP 
> > address/name/license then bring up a new definition without a NIC, login 
> > via virt-manager.  For the IP address, search the registry for the current 
> > IP address and change the appropriate entries.  Use standard Windows 
> > utilities to change the description/name.  For the license, search for 
> > "Product" and select "View your Product ID", in that dialog there should be 
> > an option to change the product key.  Once done add the same NIC as the 
> > other definition had and restart.  This has worked all but once for me.  
> > The one time it didn't, Windows discerned a network problem (IP address) 
> > and provided a way to fix it.
> I remember that for a cloned win system the SID should be also changed.
> https://en.wikipedia.org/wiki/Security_Identifier

I have successfully cloned many versions of Windows OS, then
booted the clone and changed static IP using Network Connections
widget -> Change Adaptor Settings, without incident, where my
intent is never to run both systems at the same time. Not clear
to me what circumstance would warrent editing the registry to
obtain this result, but everything has a good use case I
suppose?

For completeness, as OP might know, Microsoft provides the
'sysprep' utility to prepare a system for cloning. In RHEL6 / C6
and more recent, Linux guests can be similarly prepared with
'virt-sysprep'.

--
Charles Polisher
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 7 : network interface renamed from eth0 to eth1 after reboot

[Leroy Tennison]

There may be ways to force NIC naming, I've done so but only on Ubuntu so 
you'll need to do the research if it's important to you.  Things to look for 
based on my experience: 70-persistent-net.rules, net.ifnames=0, biosdevname=0.


From: CentOS  on behalf of Nicolas Kovacs 

Sent: Sunday, February 9, 2020 12:51 PM
To: centos@centos.org 
Subject: [EXTERNAL] Re: [CentOS] CentOS 7 : network interface renamed from eth0 
to eth1 after reboot

Le 09/02/2020 à 16:54, Alexander Dalloz a écrit :
> "Kernel always uses the ethX naming convention at boot when it enumerates
> network devices. Due to parallelization, the order of the kernel interface
> enumeration is expected to vary across reboots."

Thanks for the heads up.

I experimented quite a bit, and found some surprising behavior. So I documented
everything in a little blog article.

   * 
https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.microlinux.fr%2finterfaces-reseau-persistantes%2f=E,1,apWInXfONKIS7FI-2r96hzoROBMB28lpEncRGtBCvS-yWk5DU4roROpidqfC06FNDn2rlEYO-xJjHn2B0klz4_h1y7kiuBvlSjCMer8MBCuMgAcKUg,,=1

Cheers,

Niki

--
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Site : 
https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.microlinux.fr=E,1,egz8jO853imKX3mT5r9bs5vOCANcassZ0dea14ELcSZMwyZ5fJhfqPU6G1SltXyA8jjCrUwRU-k0Hj5oXsh2RioeNQj-7HsnfPYs1pYwHt6Vnp0cvNSVHpBAPA,,=1
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
Mob. : 06 51 80 12 12
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Harriscomputer

Leroy Tennison
Network Information/Cyber Security Specialist
E: le...@datavoiceint.com


[cid:Data-Voice-International-LOGO_aa3d1c6e-5cfb-451f-ba2c-af8059e69609.PNG]


2220 Bush Dr
McKinney, Texas
75070
www.datavoiceint.com


This message has been sent on behalf of a company that is part of the Harris 
Operating Group of Constellation Software Inc.

If you prefer not to be contacted by Harris Operating Group please notify 
us.



This message is intended exclusively for the individual or entity to which it 
is addressed. This communication may contain information that is proprietary, 
privileged or confidential or otherwise legally exempt from disclosure. If you 
are not the named addressee, you are not authorized to read, print, retain, 
copy or disseminate this message or any part of it. If you have received this 
message in error, please notify the sender immediately by e-mail and delete all 
copies of the message.




___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] NetworkManager on servers

[Chris Adams]

Once upon a time, Stephen John Smoogen  said:
> The reason is that having 1 way to configure networks makes it so the
> developer and tech support only have to diagnose issues from 1 set of tools
> versus two different ones (and occasionally 2 competing ones if both are
> trying to do their job at the same time).

Not only that - the hodge-podge bash network scripts are kind of a mess.
It is impressive that they do what they do so reliably after so long,
but every new feature appears to have been hacked in by a different
developer, leaving parts of them almost indecipherable.

That's not intended as a criticism of the scripts or the people who
wrote that code - it's just that IMHO they managed to go beyond what is
reasonable in bash scripting, which makes for a difficult to read (and
I'm sure fix/extend) set of scripts.

And even on servers now, there are often dynamic network changes that
work much better with NetworkManager than the old-style static scripts.
Containers, VMs, and VPNs all come and go, and work better with a single
system configuring their networks (rather than each layer implementing
their own setup).
-- 
Chris Adams 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] NetworkManager on servers

[Stephen John Smoogen]

On Mon, 10 Feb 2020 at 02:55, Nicolas Kovacs  wrote:

> Hi,
>
> I'm currently reading the upstream "Considerations in adopting RHEL 8"
> document. The chapter about networking states that traditional networking
> scripts (shipped with the network-scripts package) are considered obsolete.
>
> I bluntly admit I don't see the point in this. As far as I'm concerned,
> I've
> been a happy user of NetworkManager since the early days (when folks used
> to
> call it NotworkManager :oD). It's one of those nifty pieces of software
> that
> brought the Linux desktop to the masses - or at least a bit nearer to them
> -
> since it allows managing wireless and wired interfaces transparently and
> easily
> on a laptop or any computer with a wireless card.
>
> On servers though, one of the first post-installation steps I performed
> was to
> get rid of Network-Manager and all its components. The servers I'm working
> on
> are relatively small-scale and have from one to four network interfaces.
> Each
> interface has a corresponding configuration in
> /etc/sysconfig/network-scripts,
> and that's it. From there, I rarely - if ever - touch it. In all my
> setups,
> NetworkManager is merely a useless layer of abstraction, and I like
> sticking to
> the KISS principle and shave off useless layers.
>
> Maybe there's a reason to make NetworkManager more or less mandatory from
> now
> on, but I don't see it. So I thought I'd rather ask on this list.
>
>
The reason is that having 1 way to configure networks makes it so the
developer and tech support only have to diagnose issues from 1 set of tools
versus two different ones (and occasionally 2 competing ones if both are
trying to do their job at the same time). Basically network-scripts has
been on the backburner for 10+ years and has to be dusted off every now and
then to add a new networking corner case or some other item. For the
developer it usually means context swapping back from python (or whatever
language they prefer) to bash and then figure out what the problem is..
cause a couple of new ones they then have to fix and then get it right. Or
they could do that work in 1 language they know and get it done.

Does it makes sense to us as sysadmins who are happy with a working set of
scripts and configs we have to know possibly rewrite? No it doesn't.. but
unless one of us takes over the network-scripts and puts in the work to
make it work in all the different layers (or pay someone to do so).. we get
what the soup kitchen serves :).



-- 
Stephen J Smoogen.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos