Once upon a time, Ljubomir Ljubojevic <centos at plnet.rs> said:> Bridge for VM's is main reason I hate NM. I now mess with both NM and > br0 controled by network because I use Windows VM on my laptop. As soon > as you disconnect LAN cable your eth and bridge connection are gone and > stupid KVM can not recover and reconnect to newly activated bridge when > you return LAN cable, even only a second later...See the NetworkManager-config-server package. -- Chris Adams <linux at cmadams.net>
On 10/4/19 3:03 PM, Chris Adams wrote:> Once upon a time, Ljubomir Ljubojevic <centos at plnet.rs> said: >> Bridge for VM's is main reason I hate NM. I now mess with both NM and >> br0 controled by network because I use Windows VM on my laptop. As soon >> as you disconnect LAN cable your eth and bridge connection are gone and >> stupid KVM can not recover and reconnect to newly activated bridge when >> you return LAN cable, even only a second later... > > See the NetworkManager-config-server package. >Ahh, thanks. I was wondering about it but never investigated. -- Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe StarOS, Mikrotik and CentOS/RHEL/Linux consultant
On 2019-10-04 08:03, Chris Adams wrote:> Once upon a time, Ljubomir Ljubojevic <centos at plnet.rs> said: >> Bridge for VM's is main reason I hate NM.+1 My impression is younger generation doesn't value rules that programmers were following 2-3 decades ago. One of which is: Do not make any changes [in the program] unless they are absolutely necessary. This rule was helping to not introduce new bugs. Debugging is really expensive process (that is why it often gets abridged in favor of spending effort on yet more "new features" - see, e.g. firefox and friends). Yet one more thing is: building superstructure on top of what actually works. NM is one of examples. Printer configuration tool is another (whereas CUPS web interface - http://localhost:631 - is same simple, and is even better). I understand potential goal: to give newcomers the way to handle thing (by pointing, clicking and "it works" ;-). But there is a limit to the extent Linux can steal Microsoft's userbase. At some point having your machine behave as iPad gets so annoying that some Linux folks flee either their DE (Desktop Environment) to something "more traditional", e.g. mate; or some go lengths, and flee their workstations and laptops to one of BSD descendents (my main system on laptop is FreeBSD, though it also boots to MS Windows and Ubuntu Linux). I know it sounds like a rant, but I decided against putting rant tags on this one. Valeri>> I now mess with both NM and >> br0 controled by network because I use Windows VM on my laptop. As soon >> as you disconnect LAN cable your eth and bridge connection are gone and >> stupid KVM can not recover and reconnect to newly activated bridge when >> you return LAN cable, even only a second later... > > See the NetworkManager-config-server package. >-- ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On 10/4/19 10:00 AM, Ljubomir Ljubojevic wrote:> On 10/4/19 3:03 PM, Chris Adams wrote: >> ... >> See the NetworkManager-config-server package. > Ahh, thanks. I was wondering about it but never investigated.Hmmmm..... Description : This adds a NetworkManager configuration file to make it behave more like the old "network" service. In particular, it stops NetworkManager from automatically running DHCP on unconfigured ethernet devices, and allows connections with static IP addresses to be brought up even on ethernet devices with no carrier. This package is intended to be installed by default for server deployments. ++++++++++ Well, learn something new every day.... nice.? Time to learn a bit more about what it will do, and see about deploying to our KVM hosts.....? I've not had the bridged network issues some seem to have been plagued with, and I have several KVM hosts with bridged networking (with multiple VLANs) using NetworkManager (using nmtui to configure a bridge isn't hard). I decided to configure it that way just ot see how easy or hard it was to do with NM, and to test its stability, and after passing testing under load I popped it into production, running a few Windows 7 guests and a couple of CentOS 7 guests.
On Fri, 4 Oct 2019 at 10:41, Valeri Galtsev <galtsev at kicp.uchicago.edu> wrote:> > > > On 2019-10-04 08:03, Chris Adams wrote: > > Once upon a time, Ljubomir Ljubojevic <centos at plnet.rs> said: > >> Bridge for VM's is main reason I hate NM. > > +1 > > My impression is younger generation doesn't value rules that programmers > were following 2-3 decades ago. One of which is: >It is the same evolution you see in other industries. Auto mechanics constantly complain about how the newer generation is 'dumber' for not knowing the beauty of a vehicle that the mechanic had when they were in their teens. [Of course they also rail on the fact that their grandparents car was a complete junk that was too simple to work.] Most of the tools we had 30 years ago in computers are like working on a Model T era vehicle. They allowed for a lot of configuration choices and fine tuning but they also were limited vastly in other ways. You can't run a fleet of 1000 Model TT trucks made in 1923 as well as you could 1000 1933 trucks. You ended up losing some of the knowledge of hand-crafting your own gears but you got the ability to go faster, carry heavier loads and better gas mileage without working as hard at getting a mile out of a quart. The transmissions of the 1933 were considered 'automatic' compared to some 1912 vehicles.. even if you had a clutch because you no longer had to get out and turn something to make it go in reverse. The 'truly' automatic transmissions of the 1950's were horrible and it wasn't until the 1970's where they became 'liveable'. Today trying to find a real stick shift is almost impossible as you find out that the most are really talking to a computer which does the shifting when it decides is optimal. As that happens the place where a programmer makes changes goes higher and higher. They no longer see a system by itself but see 10,000 nodes sitting in some cloud. They really could care less if 10% of them drop off because there is a tool which is going ot bring 1000 back online when that happens. However they may still be worrying about making a change 'low' level to them. It is just light years above where those of us with only 10 or a 100 systems can dream about. -- Stephen J Smoogen.
On 10/4/19 10:40 AM, Valeri Galtsev wrote:> My impression is younger generation doesn't value rules that > programmers were following 2-3 decades ago. One of which is: > > Do not make any changes [in the program] unless they are absolutely > necessary. >I have in the past agreed with this assessment more than once.? And I _am_ somewhat of an old hand at this, having run Unix and Unix-like systems for a bit over 30 years. The fact of the matter is that, even though some of the old ways work just fine and don't need to be changed, many more times I've seen that, if the old way was a kludge to begin with, maybe there really is a better way to do it.? Take the transition from horse and buggy to automobile for instance.? Iron rim tires work just great for the buggy, not so great for the automobile; a change had to be made in an old technology (the wheel) to meet the needs of the new automobile.? Lots of wheelwrights probably fought that change, too. I've seen the old ways, and there are more kludges out there than some would like to admit.? (obOldWayRef: article on 'the kluge' from the 1966 Datamation book 'Faith, Hope, and Parity.')? Just remember: the old ways back then was punch card and batch; what do you mean you want more than one person to use such an expensive thing as a computer live, wasting its valuable time?? Many seem to forget just how subversive Unix was back in the day relative the the old ways.> ... > Yet one more thing is: building superstructure on top of what actually > works.The definition of what works can and does change over time.? Sure, an iron rim wheel can work for the new automobile, but the basic change in what the wheel needed to do (with buggy the wheel doesn't need to provide good traction, that's what hooves are for, and narrow and smooth work best; with the automobile all of a sudden the drive wheels need to provide traction, and even though the iron-rim wheel still works after a fashion on smooth ground, there is a better way to do it).? I can just hear the old-school wheelwrights saying "well, if it gets stuck in the mud then just don't go in the mud!"? or "why would anyone want to go faster than the horse-drawn buggy could?" or "why would you need to turn that quickly and at that speed?" or "why in the world would you want brakes to stop you that quickly?" and the list goes on..... I _am_ old-school in thought, but I do consciously make the effort to understand the newer reasoning, rather than be the greybeard that constantly talks about how I did it in the old days.? Heh, in the old days I made it work with K&R C, 1MB of RAM, and an 8MHz CPU.... and I griped about the misfeatures then!..... Today, I'm doing things with containers, virtualization, dynamic load balancing, software-defined infrastructure/IaaS, etc that the old ways simply cannot handle.? NetworkManager/systemd/etc in CentOS are far from perfect, but at least they're trying to solve the newer problems that the old ways in many cases simply cannot.