On Wed, Apr 30, 2014 at 1:28 PM, Steve Clark sclark@netwolves.com wrote:
So, have you ever had to deal with a CentOS box and multiple NICs. Especially one where you've cloned it or moved a disk to a new chassis? Apparently there is just not a good way to identify interfaces.
Yep, do it all the time - first two thing I do are: rm -f /etc/udev/rules.d/70-persistent-net.rules rm -r /etc/sysconfig/network-scripts/ifcfg-eth* and then reboot.
So, now you've got 6 NICs connected to 6 different switches. Which name is which? This is a really fun exercise when the box is remote and you are trying to tell someone used to configuring windows systems how to get it to a point where you can ssh in.
On 04/30/2014 02:41 PM, Les Mikesell wrote:
On Wed, Apr 30, 2014 at 1:28 PM, Steve Clark sclark@netwolves.com wrote:
So, have you ever had to deal with a CentOS box and multiple NICs. Especially one where you've cloned it or moved a disk to a new chassis? Apparently there is just not a good way to identify interfaces.
Yep, do it all the time - first two thing I do are: rm -f /etc/udev/rules.d/70-persistent-net.rules rm -r /etc/sysconfig/network-scripts/ifcfg-eth* and then reboot.
So, now you've got 6 NICs connected to 6 different switches. Which name is which? This is a really fun exercise when the box is remote and you are trying to tell someone used to configuring windows systems how to get it to a point where you can ssh in.
I guess I am confused, you haven't ever worked with the hardware you are installing the cloned drive in? If that is true then I guess you have a problem.
On Thu, May 01, 2014 at 06:54:18AM -0400, Steve Clark wrote:
On 04/30/2014 02:41 PM, Les Mikesell wrote:
On Wed, Apr 30, 2014 at 1:28 PM, Steve Clark sclark@netwolves.com wrote:
So, have you ever had to deal with a CentOS box and multiple NICs. Especially one where you've cloned it or moved a disk to a new chassis? Apparently there is just not a good way to identify interfaces.
I haven't followed this thread too closely, so if this has already been stated, please forgive me. Judging from both recent editions of Fedora and the free beta RH7, you don't HAVE to use NetworkManager. You will have to manually turn it off and turn network on, and judging by later versions of Fedora (though not at all deeply researched by me) you may need to use the system-config-network-tui tool rather than just editing /etc/sysocnfig/network/network-scripts/ifcfg-*.
Unfortunately, (and freely admitting much of this may be old person's get of my lawn attitude), it does seem that the Fedora developers are working for the single user laptop, and have little concept of system administration--or, to be fair, have little interest in things for the system administrator, and unfortunately, RedHat just throws these things into their next enterprise version without checking.
NM is not going to go away. However, at least for RHEl7, it should be fairly easy to remove it and use /etc/init.d/network.
On 2014-05-01, Scott Robbins scottro@nyc.rr.com wrote:
I haven't followed this thread too closely, so if this has already been stated, please forgive me.
It was not explicitly stated, so I appreciate the succinct summary. Thanks!
Judging from both recent editions of Fedora and the free beta RH7, you don't HAVE to use NetworkManager. You will have to manually turn it off and turn network on, and judging by later versions of Fedora (though not at all deeply researched by me) you may need to use the system-config-network-tui tool rather than just editing /etc/sysocnfig/network/network-scripts/ifcfg-*.
Can you recall what gave you this impression? It'd be frustrating to me to have to keep my hands off of the config files directly. (If not, I understand; if I really want to know that badly I should just check it myself.)
Unfortunately, (and freely admitting much of this may be old person's get of my lawn attitude), it does seem that the Fedora developers are working for the single user laptop, and have little concept of system administration--or, to be fair, have little interest in things for the system administrator, and unfortunately, RedHat just throws these things into their next enterprise version without checking.
Could this be a SIG in the future? "CentOS NM-Haters SIG" ;-)
Does RH really "just throw these things in"? It seems like they would annoy many of their more tech-savvy customers with moves like this one (if it were to happen).
--keith
Keith Keller wrote: <snip>
Could this be a SIG in the future? "CentOS NM-Haters SIG" ;-)
Does RH really "just throw these things in"? It seems like they would annoy many of their more tech-savvy customers with moves like this one (if it were to happen).
I think I need to check with my manager - we do have a few RH licenses - and maybe I, or several of us, should put in an enhancement request for 7: DO NOT INSTALL NM by default *EXCEPT* for either a desktop, or, better, a laptop install. DO set network up by default in all other cases.
Yes?
mark
On 05/01/2014 10:56 AM, m.roth@5-cent.us wrote:
I think I need to check with my manager - we do have a few RH licenses
- and maybe I, or several of us, should put in an enhancement request
for 7: DO NOT INSTALL NM by default *EXCEPT* for either a desktop, or, better, a laptop install. DO set network up by default in all other cases. Yes?
Maybe.
The wired use case that is most compelling for NetworkManager is that of per-user 802.1x, and enforcing that at login. I could use that myself; coupled with something like Packetfence on the backend (with supported switches) you could get attached to any of a number of different VLANs based on who you are rather than what machine you happen to be using.
At an educational institution (or really anywhere that you might have guests who need certain access and users who need other access or accesses) being able to partition things like this is highly desirable, and that is the great promise of 802.1x authentication. You log in to the desktop, and you get your desktop and only those LAN resources for which you are authorized, and it's tied to your user ID and not to the machine.
This sort of thing is ideal for labs or any other public access machine.
And, yes, this is a desktop use case, not a server one.
Lamar Owen wrote:
On 05/01/2014 10:56 AM, m.roth@5-cent.us wrote:
I think I need to check with my manager - we do have a few RH licenses
- and maybe I, or several of us, should put in an enhancement request
for 7: DO NOT INSTALL NM by default *EXCEPT* for either a desktop, or, better, a laptop install. DO set network up by default in all other cases. Yes?
Maybe.
The wired use case that is most compelling for NetworkManager is that of per-user 802.1x, and enforcing that at login. I could use that myself; coupled with something like Packetfence on the backend (with supported switches) you could get attached to any of a number of different VLANs based on who you are rather than what machine you happen to be using.
<snip> Just looked up 802.1x. Having not read the entire wikipedia article, is this an alternative to kerberizing it all?
mark
On 05/01/2014 02:34 PM, m.roth@5-cent.us wrote:
<snip> Just looked up 802.1x. Having not read the entire wikipedia article, is this an alternative to kerberizing it all?
Well, it's at a different layer. 802.1x requires the client to authenticate to the network, and the backend can then make decisions like which layer 2 VLAN and which layer 3 subnet to put you in, based on your authentication. Kerberos and ilk can be integrated.
Look at packetfence.org to see one use of 802.1x (and other means of using VLANs to isolate, especially when things go south on the workstation security side).
So, if I have a public workstation, say, set up in a lobby, and I need to quickly do some admin tasks, I can log in to the public machine as myself, authenticate properly, and get put (by the switch) on the admin VLAN and do admin things with that access. I then log off, and the network connection I had goes away (the machine gets 'parked' onto a isolated VLAN). Now, J. Random User comes by and logs in as guest. JRU will get put (again, by the switch) on an isolated VLAN that is firewalled from the rest of the network, and will only have layer 2 and 3 access to what JRU needs. Guest would have a 'timed inactivity automatic logoff' of course. Now, an intern comes by, and needs to get the todo list I've prepared for tomorrow's work. Intern doesn't need to even see the admin VLAN or any machines there, but if I have an intern VLAN, then authentication with the intern credentials can pop the machine on the intern VLAN.
One machine, three different users needing three different and mutually exclusive network connections. The mechanics aren't too different from using Wi Fi connections, really, just on a wired interface. In this case, NetworkManager makes the implementation very easy; you add a connection for each user, and set up the 802.1x stuff in the NM interface (and it can be cryptographically strong authentication; look in the NM dialogs) for each user in that user's account. When that user logs in, that connection for that user comes up.
On 2014-05-01, m.roth@5-cent.us m.roth@5-cent.us wrote:
I think I need to check with my manager - we do have a few RH licenses - and maybe I, or several of us, should put in an enhancement request for 7: DO NOT INSTALL NM by default *EXCEPT* for either a desktop, or, better, a laptop install. DO set network up by default in all other cases.
I would suggest that it be installed and used by default for a ''beginner'' install, and specifically asked about in an ''expert'' install. I don't see the point in making a distinction between server, desktop, or laptop, because an expert setting up a laptop might prefer not to use NM, and a beginner setting up a server might need NM, or might not even know how to configure a network without it. (I know, beginners probably shouldn't be installing servers, but they're going to do it anyway.)
--keith
When I started this thread a week ago, I certainly did not expect this many replies. Without a doubt it seems Network Manager is a controversial topic. I still haven't worked out my Network Manager woes and just lost an hour troubleshooting a Golang webserver which wouldn't start.
Apparently in Golang's net package, there is a DNS resolver function that's called whenever a server is started. That function depends on a working /etc/resolv.conf - As per usual, the /etc/resolv.conf file turned out to be the blank template NetworkManager always creates. The webserver starts now, but this /etc/resolv.conf will certainly be blown away by NetworkManager the next time the network service restarts.
I have one idea as to why this problem persists. This file:
ll /etc/sysconfig/network-scripts/ifcfg-eth0 ...
-rw-r--r--. 1 root root 44 Apr 26 22:21 ifcfg-eth0
Is it meant to be executable? Being a configuration file, I'm assuming it doesn't need to be. Am I wrong?
On Thu, May 1, 2014 at 9:49 PM, Keith Keller < kkeller@wombat.san-francisco.ca.us> wrote:
On 2014-05-01, m.roth@5-cent.us m.roth@5-cent.us wrote:
I think I need to check with my manager - we do have a few RH licenses - and maybe I, or several of us, should put in an enhancement request for
7:
DO NOT INSTALL NM by default *EXCEPT* for either a desktop, or, better, a laptop install. DO set network up by default in all other cases.
I would suggest that it be installed and used by default for a ''beginner'' install, and specifically asked about in an ''expert'' install. I don't see the point in making a distinction between server, desktop, or laptop, because an expert setting up a laptop might prefer not to use NM, and a beginner setting up a server might need NM, or might not even know how to configure a network without it. (I know, beginners probably shouldn't be installing servers, but they're going to do it anyway.)
--keith
-- kkeller@wombat.san-francisco.ca.us
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sun, May 04, 2014 at 07:22:52PM -0400, Evan Rowley wrote:
Apparently in Golang's net package, there is a DNS resolver function that's called whenever a server is started. That function depends on a working /etc/resolv.conf - As per usual, the /etc/resolv.conf file turned out to be the blank template NetworkManager always creates. The webserver starts now, but this /etc/resolv.conf will certainly be blown away by NetworkManager the next time the network service restarts.
Are you not getting a _correct_ resolv.conf from NetworkManager? Why not?
This doesn't seem like it is Go related at all -- if you want any DNS to be working at all, pretty much all resolvers need that file.
I have one idea as to why this problem persists. This file: ll /etc/sysconfig/network-scripts/ifcfg-eth0 Is it meant to be executable? Being a configuration file, I'm assuming it doesn't need to be. Am I wrong?
You're not wrong. This is not your problem.
That file is 'sourced' by other network scripts so doesn't have to be executable, but the contents set environment variables for other scripts. Or so I believe. No doubt someone will correct me if I am wrong. 8-)
Cheers,
Cliff
On Mon, May 5, 2014 at 11:27 AM, Matthew Miller mattdm@mattdm.org wrote:
On Sun, May 04, 2014 at 07:22:52PM -0400, Evan Rowley wrote:
Apparently in Golang's net package, there is a DNS resolver function
that's
called whenever a server is started. That function depends on a working /etc/resolv.conf - As per usual, the /etc/resolv.conf file turned out to
be
the blank template NetworkManager always creates. The webserver starts
now,
but this /etc/resolv.conf will certainly be blown away by NetworkManager the next time the network service restarts.
Are you not getting a _correct_ resolv.conf from NetworkManager? Why not?
This doesn't seem like it is Go related at all -- if you want any DNS to be working at all, pretty much all resolvers need that file.
I have one idea as to why this problem persists. This file: ll /etc/sysconfig/network-scripts/ifcfg-eth0 Is it meant to be executable? Being a configuration file, I'm assuming it doesn't need to be. Am I wrong?
You're not wrong. This is not your problem.
-- Matthew Miller mattdm@mattdm.org http://mattdm.org/ _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Monday 05 May 2014 00:22:52 Evan Rowley wrote:
When I started this thread a week ago, I certainly did not expect this many replies. Without a doubt it seems Network Manager is a controversial topic. I still haven't worked out my Network Manager woes and just lost an hour troubleshooting a Golang webserver which wouldn't start.
Apparently in Golang's net package, there is a DNS resolver function that's called whenever a server is started. That function depends on a working /etc/resolv.conf - As per usual, the /etc/resolv.conf file turned out to be the blank template NetworkManager always creates. The webserver starts now, but this /etc/resolv.conf will certainly be blown away by NetworkManager the next time the network service restarts.
I have one idea as to why this problem persists. This file:
ll /etc/sysconfig/network-scripts/ifcfg-eth0 ...
-rw-r--r--. 1 root root 44 Apr 26 22:21 ifcfg-eth0
Is it meant to be executable? Being a configuration file, I'm assuming it doesn't need to be. Am I wrong?
A hack. Set up your resolv.conf as you need it.
Then as root chattr +i /etc/resolv.conf
Now NM can configure the interfaces but can't change /etc/resolv.conf
Linux nogs.tonyshome.ie 2.6.32-431.11.2.el6.x86_64 #1 SMP Tue Mar 25 19:59:55 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
On 05/05/2014 10:55 AM, Tony Molloy wrote:
On Monday 05 May 2014 00:22:52 Evan Rowley wrote:
When I started this thread a week ago, I certainly did not expect this many replies. Without a doubt it seems Network Manager is a controversial topic. I still haven't worked out my Network Manager woes and just lost an hour troubleshooting a Golang webserver which wouldn't start.
Apparently in Golang's net package, there is a DNS resolver function that's called whenever a server is started. That function depends on a working /etc/resolv.conf - As per usual, the /etc/resolv.conf file turned out to be the blank template NetworkManager always creates. The webserver starts now, but this /etc/resolv.conf will certainly be blown away by NetworkManager the next time the network service restarts.
I have one idea as to why this problem persists. This file:
ll /etc/sysconfig/network-scripts/ifcfg-eth0 ...
-rw-r--r--. 1 root root 44 Apr 26 22:21 ifcfg-eth0
Is it meant to be executable? Being a configuration file, I'm assuming it doesn't need to be. Am I wrong?
A hack. Set up your resolv.conf as you need it.
Then as root chattr +i /etc/resolv.conf
Now NM can configure the interfaces but can't change /etc/resolv.conf
indeed that's an ugly hack.
you should rather set PERRDNS=no DNS1=<bar> DNS2=<foo> in /etc/sysconfig/network-scripts/ifcfg-eth0
The options in this file are documented in: /usr/share/doc/initscripts-*/sysconfig.txt
On 05/05/2014 06:55 AM, Nicolas Thierry-Mieg wrote:
you should rather set PERRDNS=no DNS1=<bar> DNS2=<foo> in /etc/sysconfig/network-scripts/ifcfg-eth0
The options in this file are documented in: /usr/share/doc/initscripts-*/sysconfig.txt
A great answer, but with a minor typo. The option is: PEERDNS=no
On Thu, May 1, 2014 at 9:45 AM, Keith Keller kkeller@wombat.san-francisco.ca.us wrote:
Could this be a SIG in the future? "CentOS NM-Haters SIG" ;-)
Does RH really "just throw these things in"? It seems like they would annoy many of their more tech-savvy customers with moves like this one (if it were to happen).
I think it is really a side effect of splitting the RH enterprise version and Fedora development into two different things. New development now all comes from the Fedora side where they just want change and don't care about stability. That's probably a good thing for desktop users since the desktop environment hasn't historically been that great, but the server side has been relatively complete for ages and businesses really don't want to have to rewrite all their applications and deployment processes for every new release. Back in the old days it would have been the same group contributing new development and consuming the final product so the direction might have been better aligned.
On Thu, May 01, 2014 at 07:45:02AM -0700, Keith Keller wrote:
On 2014-05-01, Scott Robbins scottro@nyc.rr.com wrote: Thanks!
Judging from both recent editions of Fedora and the free beta RH7, you don't HAVE to use NetworkManager. You will have to manually turn it off and turn network on, and judging by later versions of Fedora (though not at all deeply researched by me) you may need to use the system-config-network-tui tool rather than just editing /etc/sysocnfig/network/network-scripts/ifcfg-*.
Can you recall what gave you this impression? It'd be frustrating to me to have to keep my hands off of the config files directly. (If not, I understand; if I really want to know that badly I should just check it myself.)
Two things. One, comments from an extremely knowledgeable person on the Fedora forums, has said that there are now various scripts buried in various places. The person has, time and time again, shown themself to be extremely knowledgeable.
The second is from an install where I manually edited the files, and the network would not start. I've been manually editing for years, and I am almost positive that it was not a syntax error on my part. Each time, after the machine booted, I could manually run ifconfig or ip, or dhclient and it would then come up. Finally, I used system-config-network-tui and it came up As I said, not a deep investigation--for example, I didn't do a diff of ifconfig-eth0 before and after using system-config-network-tui.
On most other installs of F20 prior to that, I, due to the aforementioned posting on Fedora forums, just used system-config-network-tui without trying manual configuration--hence, not deeply tested.
Unfortunately, (and freely admitting much of this may be old person's get of my lawn attitude), it does seem that the Fedora developers are working for the single user laptop, and have little concept of system administration--or, to be fair, have little interest in things for the system administrator, and unfortunately, RedHat just throws these things into their next enterprise version without checking.
Does RH really "just throw these things in"? It seems like they would annoy many of their more tech-savvy customers with moves like this one (if it were to happen).
Well, the ones I can think of off the top of my head are allowing any user to update a signed rpm without authorization. The other one is showing all user names at login screen. Those are two household laptop or desktop features that make sense for a single user (or in a household) but not in business--to the point that not even Windows does it with their business class systems.
Other things, such as NM, are debatable. To me, and apparently many others, they are a home user or workstation at best, feature that shouldn't be on a server.
I suspect many people feel the same about systemd as well. It makes things boot faster, but also seems more likely to choke if something doesn't come up. A recent job change has put me more in the BSD world than Linux these days, so I haven't been following recent developments as closely as I used to do.
-
Cliff Pratt -
Evan Rowley -
Keith Keller -
Lamar Owen -
Les Mikesell -
m.roth＠5-cent.us -
Matthew Miller -
Nicolas Thierry-Mieg -
Scott Robbins -
Steve Clark -
Tony Molloy