date:20170213

Gordon Messmer wrote:
> On 02/13/2017 10:35 AM, m.r...@5-cent.us wrote:
>>> What's in /etc/sysconfig/network-scripts/ifcfg-? Does it say
>>> NM_CONTROLLED=no?
>>>
>> Good catch. No, it doesn't say no... because the line was commented out.
>> I've just uncommented it, and set it to yes.
>
> Commented out should be the same as =yes.  Only =no will cause it to be
> managed by the old sysconfig scripts, unless I'm mistaken. As Johnny
> suggested, ONBOOT=no is another option that could be problematic.
>
> Your log was a little too edited.  Some of the early lines were
> incomplete, so it's hard to determine what's going on.  Maybe just send
> ifcfg-em1?

NAME="em1"
DEVICE="em1"
ONBOOT=yes
NETBOOT=yes
NM_CONTROLLED="yes"
UUID="c432eaa1-023b-4f1f-a7b5-4605ec07195b"
BOOTPROTO=dhcp
TYPE=Ethernet
SEARCH="nih.gov"

IPV6INIT="yes"
DHCPV6C="yes"

DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=no
IPV6_AUTOCONF=no
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no

  mark

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

[CentOS-announce] CESA-2017:0269 Critical CentOS 7 java-1.7.0-openjdk Security Update


CentOS Errata and Security Advisory 2017:0269 Critical

Upstream details at : https://rhn.redhat.com/errata/RHSA-2017-0269.html

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

x86_64:
afcc43329737c25752cc4e38a34c8ea0430ab0be696d4cfd2c50f9ac82184984  
java-1.7.0-openjdk-1.7.0.131-2.6.9.0.el7_3.x86_64.rpm
57c42d32708e71c1778811b6201f189f0d9682ef1ee64ac4f5ca221725ecf41f  
java-1.7.0-openjdk-accessibility-1.7.0.131-2.6.9.0.el7_3.x86_64.rpm
962b228787c68649003f8a1e5df6875958fdda37866a9d55dc451643ebf1b865  
java-1.7.0-openjdk-demo-1.7.0.131-2.6.9.0.el7_3.x86_64.rpm
c68e9ed21e04c0ab6d86cbb445f692eb277346a3a51ffc735ba0893d295a109a  
java-1.7.0-openjdk-devel-1.7.0.131-2.6.9.0.el7_3.x86_64.rpm
629a4dc16c4fb283a3be2b19070cc97ea864018f3b2a18f7a5383eb483154bee  
java-1.7.0-openjdk-headless-1.7.0.131-2.6.9.0.el7_3.x86_64.rpm
087c956bb48670bd96f861a5996b8535c89b3c83b7f1472af81fbacd7946d754  
java-1.7.0-openjdk-javadoc-1.7.0.131-2.6.9.0.el7_3.noarch.rpm
a8237710facd516d1d6eda6d749a5fb724746172d866b93168c261933569192f  
java-1.7.0-openjdk-src-1.7.0.131-2.6.9.0.el7_3.x86_64.rpm

Source:
1edbdfcdfacb9daec6390aed4fdad4fe38dbf36023f1a095fff518d29e585594  
java-1.7.0-openjdk-1.7.0.131-2.6.9.0.el7_3.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS

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

[CentOS-announce] CESA-2017:0269 Critical CentOS 5 java-1.7.0-openjdk Security Update


CentOS Errata and Security Advisory 2017:0269 Critical

Upstream details at : https://rhn.redhat.com/errata/RHSA-2017-0269.html

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

i386:
f2fb7e8343760a6cc3535a6124bd71411b20795da0ac056b8361c8826ce9a69e  
java-1.7.0-openjdk-1.7.0.131-2.6.9.0.el5_11.i386.rpm
72c2fee994a496787fe7a8080b0871b0d015c63fc57cf5f2457107620bbb9ac1  
java-1.7.0-openjdk-demo-1.7.0.131-2.6.9.0.el5_11.i386.rpm
2563c40d3b9b9d9ce7787284a8f8808491d4adb7af5ee3a6f9a1daeba47e8012  
java-1.7.0-openjdk-devel-1.7.0.131-2.6.9.0.el5_11.i386.rpm
d4ca35c4e689c276e1f746664e9d9f7fd46a44df643bc7e42a87183473870530  
java-1.7.0-openjdk-javadoc-1.7.0.131-2.6.9.0.el5_11.i386.rpm
c9e4741823aec2cfc8674f0c0bf52d87eca0fb31c5ea682a7d4208d1d2f29928  
java-1.7.0-openjdk-src-1.7.0.131-2.6.9.0.el5_11.i386.rpm

x86_64:
b20918246adb9966adbdcc06306e0863392d4cbf327bdfb570d4ade8bf73  
java-1.7.0-openjdk-1.7.0.131-2.6.9.0.el5_11.x86_64.rpm
e0ce4d7487d50528ea6fffb32c47f5e2405f3863a91b7ca85025b5b86e07ae99  
java-1.7.0-openjdk-demo-1.7.0.131-2.6.9.0.el5_11.x86_64.rpm
f18a46c869e0fe0bda885e6876f117e3a35604ef23a3c7cdc6c71df754d59ab1  
java-1.7.0-openjdk-devel-1.7.0.131-2.6.9.0.el5_11.x86_64.rpm
4a16817c9069a4f5f7d176df443a30e6309bb3551244bfe057054c058b329b70  
java-1.7.0-openjdk-javadoc-1.7.0.131-2.6.9.0.el5_11.x86_64.rpm
1d7b5898fd46ae5a447d7b8116919e8e7e16179b40ea3551c0f2ed62b5d1e22f  
java-1.7.0-openjdk-src-1.7.0.131-2.6.9.0.el5_11.x86_64.rpm

Source:
41d3efcc5b6cccbb9ea0af1bde1b2fc4aab16274d55d26db3e64924068128bc8  
java-1.7.0-openjdk-1.7.0.131-2.6.9.0.el5_11.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: JohnnyCentOS

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

[CentOS-announce] CESA-2017:0269 Critical CentOS 6 java-1.7.0-openjdk Security Update


CentOS Errata and Security Advisory 2017:0269 Critical

Upstream details at : https://rhn.redhat.com/errata/RHSA-2017-0269.html

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

i386:
5e812e4583b71107b72779cfc77f78c7fdc1a147a56126136f87d14cc3b4efb8  
java-1.7.0-openjdk-1.7.0.131-2.6.9.0.el6_8.i686.rpm
ce382ede1a4eac4ffdba9aa870cc9c06a083749fb40b4d9ca342b17354836553  
java-1.7.0-openjdk-demo-1.7.0.131-2.6.9.0.el6_8.i686.rpm
4ad8906f9df3db8a1812a2b3b326762a9c2a694d6a494eb0e5220b9596d0718c  
java-1.7.0-openjdk-devel-1.7.0.131-2.6.9.0.el6_8.i686.rpm
191ff23c7449d819ca45243beb432c700c66476597fd08c57c39ae8ceda8ffd2  
java-1.7.0-openjdk-javadoc-1.7.0.131-2.6.9.0.el6_8.noarch.rpm
800b7ed498f4b4fd6d0e024652ad05eef8682237fe2349f82a69106a4ca09d54  
java-1.7.0-openjdk-src-1.7.0.131-2.6.9.0.el6_8.i686.rpm

x86_64:
d9381ac7f354a3d066efe9ef1160264309f46c9373c5b28e26365ca3d81dad1a  
java-1.7.0-openjdk-1.7.0.131-2.6.9.0.el6_8.x86_64.rpm
0057a0bbfe965f73222b4806b7be62f4b79507a1c9903ccc5c4daeb65cd1addf  
java-1.7.0-openjdk-demo-1.7.0.131-2.6.9.0.el6_8.x86_64.rpm
7872f4fef9d877d2e9de8d9e1c11cd64e6afaf3620266997706fcdad9d9b196d  
java-1.7.0-openjdk-devel-1.7.0.131-2.6.9.0.el6_8.x86_64.rpm
191ff23c7449d819ca45243beb432c700c66476597fd08c57c39ae8ceda8ffd2  
java-1.7.0-openjdk-javadoc-1.7.0.131-2.6.9.0.el6_8.noarch.rpm
3c2b900af1a17e21b63aab28f034e6026d983cf96e1ffd7231a677e1ada30623  
java-1.7.0-openjdk-src-1.7.0.131-2.6.9.0.el6_8.x86_64.rpm

Source:
bf4fbc5136e1640ade4a455baa073d802fc25f099af1075fd636d3d1484ee9cb  
java-1.7.0-openjdk-1.7.0.131-2.6.9.0.el6_8.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS

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

Re: [CentOS] CentOS 7, systemd, NetworkMangler, oh, my

2017-02-13 Thread Gordon Messmer


On 02/13/2017 10:35 AM, m.r...@5-cent.us wrote:

What's in /etc/sysconfig/network-scripts/ifcfg-? Does it say
NM_CONTROLLED=no?


Good catch. No, it doesn't say no... because the line was commented out.
I've just uncommented it, and set it to yes.



Commented out should be the same as =yes.  Only =no will cause it to be 
managed by the old sysconfig scripts, unless I'm mistaken. As Johnny 
suggested, ONBOOT=no is another option that could be problematic.


Your log was a little too edited.  Some of the early lines were 
incomplete, so it's hard to determine what's going on.  Maybe just send 
ifcfg-em1?


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

Re: [CentOS] A question on networking (CentOS 6)

seems to be a driver issue or something, according to some co-workers.  Thanks 
for the help, but I guess I need to upgrade the OS or use another card.
ThxKM

  From: KM 
 To: KM ; CentOS mailing list  
 Sent: Monday, February 13, 2017 1:31 PM
 Subject: Re: [CentOS] A question on networking (CentOS 6)

Like I said, wishful thinking. The light is still out, so it could be the HW. 
I ran those commands (ip addr show, ip route show) on the 2 servers.  The 
output is identical except for the IP addresses and the MAC addresses, except 
on the server with the new card, it is missing the following IPV6 info for the 
interface name p2p1 which is the interface in question.
inet6 fe80::6a05:caff:fe06:9122/64 scope link
   valid_lft forever preferred_lft forever

Somehow I doubt we are using IPV6 but does it need to be there for some reason? 
  and if so , what do I do about it.
I apologize if these questions make no sense.  Other than the original setup, 
and sometimes editing the ifcfg files I usually don't have to do much else to 
get my network connections going.
KM

  From: KM 
 To: CentOS mailing list  
 Sent: Monday, February 13, 2017 12:49 PM
 Subject: Re: [CentOS] A question on networking (CentOS 6)

I will get back to the mailing list.   But to answer your questions, yes the IP 
addresses and interface names are as expected (as before) with the new MAC/HW 
addresses.  I have someone else looking into it because when we plugged in the 
cable the light on the card did not light up.   when we connect the pair server 
to another separate server it did.  Once the server is back up I will try these 
things that you suggest, and compare them to the pair server we are trying to 
connect to.  We are hoping that reseating the card will work.  Probably wishful 
thinking.
Thx.KM

  From: Gordon Messmer 
 To: CentOS mailing list  
 Sent: Monday, February 13, 2017 12:08 PM
 Subject: Re: [CentOS] A question on networking (CentOS 6)

On 02/13/2017 06:55 AM, KM wrote:
> The NIC went bad and it has been replaced.  I knew enough to update the HW 
> address in the ifcfg-* files.  The network service restarts successfully 
> without errors.  However I cannot connect via ping or ssh with the pt2pt 
> network setup on 192.168.x.*.  When I use our internal network ip addresses 
> it is fine.

That's not much to go on.  The output of "ip addr show" and "ip route 
show" might help you figure out what's going on.  Do your interfaces 
have the expected names?  Do they have the expected IP addresses?

One thing that might be problematic is that there are multiple systems 
that attempt to maintain consistent interface names.  If your interface 
names are not what you expect, you might need to look at 
/etc/udev/rules.d/70-persistent-net.rules where there may be additional 
rules mapping specific MAC addresses to an interface name.

___
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] A question on networking (CentOS 6)

Like I said, wishful thinking. The light is still out, so it could be the HW. 
I ran those commands (ip addr show, ip route show) on the 2 servers.  The 
output is identical except for the IP addresses and the MAC addresses, except 
on the server with the new card, it is missing the following IPV6 info for the 
interface name p2p1 which is the interface in question.
inet6 fe80::6a05:caff:fe06:9122/64 scope link
   valid_lft forever preferred_lft forever

Somehow I doubt we are using IPV6 but does it need to be there for some reason? 
  and if so , what do I do about it.
I apologize if these questions make no sense.  Other than the original setup, 
and sometimes editing the ifcfg files I usually don't have to do much else to 
get my network connections going.
KM

  From: KM 
 To: CentOS mailing list  
 Sent: Monday, February 13, 2017 12:49 PM
 Subject: Re: [CentOS] A question on networking (CentOS 6)

I will get back to the mailing list.   But to answer your questions, yes the IP 
addresses and interface names are as expected (as before) with the new MAC/HW 
addresses.  I have someone else looking into it because when we plugged in the 
cable the light on the card did not light up.   when we connect the pair server 
to another separate server it did.  Once the server is back up I will try these 
things that you suggest, and compare them to the pair server we are trying to 
connect to.  We are hoping that reseating the card will work.  Probably wishful 
thinking.
Thx.KM

  From: Gordon Messmer 
 To: CentOS mailing list  
 Sent: Monday, February 13, 2017 12:08 PM
 Subject: Re: [CentOS] A question on networking (CentOS 6)

On 02/13/2017 06:55 AM, KM wrote:
> The NIC went bad and it has been replaced.  I knew enough to update the HW 
> address in the ifcfg-* files.  The network service restarts successfully 
> without errors.  However I cannot connect via ping or ssh with the pt2pt 
> network setup on 192.168.x.*.  When I use our internal network ip addresses 
> it is fine.

That's not much to go on.  The output of "ip addr show" and "ip route 
show" might help you figure out what's going on.  Do your interfaces 
have the expected names?  Do they have the expected IP addresses?

One thing that might be problematic is that there are multiple systems 
that attempt to maintain consistent interface names.  If your interface 
names are not what you expect, you might need to look at 
/etc/udev/rules.d/70-persistent-net.rules where there may be additional 
rules mapping specific MAC addresses to an interface name.

___
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, systemd, NetworkMangler, oh, my

Gordon Messmer wrote:
> On 02/13/2017 07:35 AM, m.r...@5-cent.us wrote:
>> Finally, I do an ifdown, followed by an ifup, and everything's
>> wonderful.
>
> What's in /etc/sysconfig/network-scripts/ifcfg-? Does it say
> NM_CONTROLLED=no?
>
Good catch. No, it doesn't say no... because the line was commented out.
I've just uncommented it, and set it to yes.

mark


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

Re: [CentOS] CentOS 7, systemd, NetworkMangler, oh, my

peter.winterflood wrote:
> On 13/02/17 15:35, m.roth wrote:
>> My manager tells me a system in the datacenter is down. I go down there,
>> and plug in a monitor-on-a-stick and keyboard. It's up, but no network.
>> I try systemctl restart NetworkManager several times, and ip a shows *no*
>> change.
>>
>> Finally, I do an ifdown, followed by an ifup, and everything's
>> wonderful.
>>
>> My manager thinks that the NM daemon thinks everything's fine, and
>> there've been no changes, so it does nothing. He suggests that it might
>> have to be stopped, then started, rather than restarted.
>>
>> This is completely unacceptable behavior, since it leave the system with
>> no network connection. Pre-systemd, as we all know, restart *RESTARTED*
>> the damn thing.
>>
>> Is there some Magic (#insert "pixie-dust-sparkles") incantation, either
>> restarting NetworkManager, or using nm-cli, to force it to perform the
>> expected actions?
>>
>> Btw, if this is supposed to be part of the "hide stuff, desktop Linux
>> users don't need to know this stuff", this is a *much* worse result.
>>
>>  mark (and yes, my manager's truly aggravated about this, also)
>
> there's a really good solution to this.
>
> yum remove NetworkManager*
>
> chkconfig network on
>
> service network start
>
> and yes thats all under fedora 25, and centos 7.
>
> works like a charm.
>
> sometimes removing NM leaves resolv.conf pointing to the networkmanager
> directory, and its best to check this, and replace your resolv.conf link
> with a file with the correct settings.
>
> sorry if this upsets the people who maintain network mangler, but its
> inappropriate on a server.
>
That't'd be a 100% agreement, good buddy We may have done it on some
systems, but in general, we appear to be stuck with the damn thing.

And why the *hell* would a server want wifi enabled, or avahi-daemon
running by default?

mark

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

Re: [CentOS] CentOS 7, systemd, NetworkMangler, oh, my

James Hogarth wrote:
> On 13 February 2017 at 15:35,   wrote:
>> My manager tells me a system in the datacenter is down. I go down there,
>> and plug in a monitor-on-a-stick and keyboard. It's up, but no network.
>> I
>> try systemctl restart NetworkManager several times, and ip a shows *no*
>> change.
>>
>> Finally, I do an ifdown, followed by an ifup, and everything's
>> wonderful.
>>
>> My manager thinks that the NM daemon thinks everything's fine, and
>> there've been no changes, so it does nothing. He suggests that it might
>> have to be stopped, then started, rather than restarted.
>>
>> This is completely unacceptable behavior, since it leave the system with
>> no network connection. Pre-systemd, as we all know, restart *RESTARTED*
>> the damn thing.
>>
>> Is there some Magic (#insert "pixie-dust-sparkles") incantation, either
>> restarting NetworkManager, or using nm-cli, to force it to perform the
>> expected actions?
>>
>
>
> I'd be interested in the journal from the NetworkManager restart as
> that's not the way it behaves ... it uses the netlink API to get state
> and not it's own internal tracker of state (ie doing an ip link down
> will reflect in nmcli output) ... a restart of NetworkManager should
> not ignore interfaces but rather bring the system to the on disk
> configured state ... and a quick check it doesn't override ExecRestart
> in the unit file to do a reload or similar instead ...
>
> And indeed a quick test in a VM shows nmcli device status correctly
> changing between connected and unavailable when doing ip link set eth0
> down/up
>
> Do note that on a NM based system ifup and ifdown are effectively
> aliases to nmcli conn down and nmcli conn up
>
> nmcli conn down "connection name" will make it disconnected
> nmcli conn up "connection mame" will bring it back to connected
>
> there is a slight interesting difference between using nmcli and ip
> link set though ...
>
> with ip link set down  the interface is marked
> administratively down (as if you've pulled the cable) but nmcli conn
> down "connection name" will unconfigure the interface but leave it in
> an UP state ... just without an IP address etc
>
> anyway that's just an interesting diversion on behavioural differences
>
> NM won't change an interface state without some sort of event though
> (manual or virtual cable pulled etc), and if you have a case where it
> *has* done that then you have found a bug that would be great to get
> reported
>
> TL;DR: cannot reproduce, need logs to determine what happened without
> a working crystal ball

>From journalctl, I see this happening when I do systemctl restart
NetworkManager (much edited)
Feb 13 09:47:52  NetworkManager[67312]:  
[1486997272.7755] manager: (em1): new Ethernet device
(/org/freedesktop/NetworkManager/Devi
Feb 13 09:47:52  NetworkManager[67312]:  
[1486997272.7791] ifcfg-rh: add connection in-memory
(79d3ed9d-cc41-498c-9169-44320e332f68,
Feb 13 09:47:52  systemd[1]: Started Hostname Service.
Feb 13 09:47:52  NetworkManager[67312]:  
[1486997272.7797] device (em1): state change: unmanaged -> unavailable
(reason 'connection-
Feb 13 09:47:52  NetworkManager[67312]:  
[1486997272.7805] device (em1): state change: unavailable -> disconnected
(reason 'connecti
<...>
eb 13 09:47:52  NetworkManager[67312]:  
[1486997272.7986] device (em1): state change: disconnected -> prepare
(reason 'none') [30 4
Feb 13 09:47:52  NetworkManager[67312]:  
[1486997272.7999] policy: set 'em1' (em1) as default for IPv6 routing and
DNS
Feb 13 09:47:52  NetworkManager[67312]:  
[1486997272.8027] device (em1): state change: prepare -> config (reason
'none') [40 50 0]
Feb 13 09:47:52  NetworkManager[67312]:  
[1486997272.8034] device (em1): state change: config -> ip-config (reason
'none') [50 70 0]
Feb 13 09:47:53  NetworkManager[67312]:  
[1486997273.3594] device (em1): state change: ip-config -> ip-check
(reason 'none') [70 80
Feb 13 09:47:53  NetworkManager[67312]:  
[1486997273.3661] device (em1): state change: ip-check -> secondaries
(reason 'none') [80 9
Feb 13 09:47:53  NetworkManager[67312]:  
[1486997273.3666] device (em1): state change: secondaries -> activated
(reason 'none') [90
Feb 13 09:47:53  NetworkManager[67312]:  
[1486997273.3667] manager: NetworkManager state is now CONNECTED_GLOBAL
Feb 13 09:47:53  NetworkManager[67312]:  
[1486997273.3670] manager: NetworkManager state is now CONNECTED_SITE
Feb 13 09:47:53  NetworkManager[67312]:  
[1486997273.3670] manager: NetworkManager state is now CONNECTED_GLOBAL
Feb 13 09:47:53  nm-dispatcher[67317]: req:2
'connectivity-change': new request (6 scripts)
Feb 13 09:47:53  nm-dispatcher[67317]: req:2
'connectivity-change': start running ordered scripts...
Feb 13 09:47:53  NetworkManager[67312]:  
[1486997273.3697] device (em1): Activation: successful, device activated.

Note there is no IP address being obtained. Now, when I run ifdown/ifup:

Feb 13 09:48:17  NetworkManager[67312]:  
[1486997297.6804] device (em1):

Re: [CentOS-virt] NIC Stability Problems Under Xen 4.4 / CentOS 6 / Linux 3.18

2017-02-13 Thread Kevin Stange

On 02/12/2017 05:07 PM, Adi Pircalabu wrote:
> On 11/02/17 06:29, Kevin Stange wrote:
>> On 01/30/2017 06:41 PM, Kevin Stange wrote:
>>> On 01/30/2017 06:12 PM, Adi Pircalabu wrote:
 On 31/01/17 10:49, Kevin Stange wrote:
> You said 3.x kernels specifically. The kernel on Xen Made Easy now
> is a
> 4.4 kernel.  Any chance you have tested with that one?

 Not yet, however the future Xen nodes we'll deploy will run CentOS 7
 and
 Xen with kernel 4.4.
>>>
>>> I'll keep you (and others here) posted on my own experiences with that
>>> 4.4 build over the next few weeks to report on any issues.  I'm hoping
>>> something happened between 3.18 and 4.4 that fixed underlying problems.
>>>
> Did you ever try without MTU=9000 (default 1500 instead)?

 Yes, also with all sorts of configuration combinations like LACP rate
 slow/fast, "options ixgbe LRO=0,0" and so on. No improvement.
>>>
>>> Alright, I'll assume that probably won't help then.  I tried it on one
>>> box which hasn't had the issue again yet, but that doesn't guarantee
>>> anything.
>>
>> I was able to discover something new, which might not conclusively prove
>> anything, but it at least seems to rule out the pci=nomsi kernel option
>> from being effective.
>>
>> I had one server booted with that option as well as MTU 1500.  It was
>> stable for quite a long time, so I decided to try turning the MTU back
>> to 9000 and within 12 hours, the interface on the expansion NIC with the
>> jumbo MTU failed.
>>
>> The other NIC in the LACP bundle is onboard and didn't fail.  The other
>> NIC on the dual-port expansion card also didn't fail.  This leads me to
>> believe that ONE of the bugs I'm experiencing is related to 82575EB +
>> jumbo frames.
>>
>> I still think I'm also having a PCI-e issue that is separate and
>> additional on top of that, and which has not reared its head recently,
>> making it difficult for me to gather any new data.
>>
>> One of the things I've done that seemed to help a lot with stability was
>> balance the LACP so that one NIC from onboard and one NIC from expansion
>> card is in each LAG.  Previously we just had the first LAG onboard and
>> the second on the expansion card.  This way, at least, given the
>> expansion NIC's propensity toward failing first, I don't have to crash
>> the server and all running VMs to recover.
>>
>> I've seen absolutely no issues yet with the 4.4 kernel either, but I am
>> not willing to call that a win because of the quiet from even the
>> servers on which no tweaks have been applied yet.
> 
> Thanks for the heads-up Kevin, appreciated. One thing I need to clarify,
> though: what kernel was this machine running at the time?

Kernel running at the time was the Virt SIG's 3.18.44-20 kernel.

As a further note, within an additional 24 hours, the onboard Intel
82576 that was switched to enable jumbo frames also failed and we had to
reboot the server.  The expansion and onboard ports without jumbo frames
did not fail.  Since reboot, it's on the 4.4.47 kernel from Xen Made
Easy now with jumbo frames and has not exhibited issues since Friday.

-- 
Kevin Stange
Chief Technology Officer
Steadfast | Managed Infrastructure, Datacenter and Cloud Services
800 S Wells, Suite 190 | Chicago, IL 60607
312.602.2689 X203 | Fax: 312.602.2688
ke...@steadfast.net | www.steadfast.net
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS] A question on networking (CentOS 6)

I will get back to the mailing list.   But to answer your questions, yes the IP 
addresses and interface names are as expected (as before) with the new MAC/HW 
addresses.  I have someone else looking into it because when we plugged in the 
cable the light on the card did not light up.   when we connect the pair server 
to another separate server it did.  Once the server is back up I will try these 
things that you suggest, and compare them to the pair server we are trying to 
connect to.  We are hoping that reseating the card will work.  Probably wishful 
thinking.
Thx.KM

  From: Gordon Messmer 
 To: CentOS mailing list  
 Sent: Monday, February 13, 2017 12:08 PM
 Subject: Re: [CentOS] A question on networking (CentOS 6)

On 02/13/2017 06:55 AM, KM wrote:
> The NIC went bad and it has been replaced.  I knew enough to update the HW 
> address in the ifcfg-* files.  The network service restarts successfully 
> without errors.  However I cannot connect via ping or ssh with the pt2pt 
> network setup on 192.168.x.*.  When I use our internal network ip addresses 
> it is fine.

That's not much to go on.  The output of "ip addr show" and "ip route 
show" might help you figure out what's going on.  Do your interfaces 
have the expected names?  Do they have the expected IP addresses?

One thing that might be problematic is that there are multiple systems 
that attempt to maintain consistent interface names.  If your interface 
names are not what you expect, you might need to look at 
/etc/udev/rules.d/70-persistent-net.rules where there may be additional 
rules mapping specific MAC addresses to an interface name.

___
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, systemd, NetworkMangler, oh, my

2017-02-13 Thread peter.winterflood

On 13/02/17 16:49, James Hogarth wrote:

On 13 February 2017 at 16:17, peter.winterflood
wrote:

there's a really good solution to this.

yum remove NetworkManager*

chkconfig network on

service network start

and yes thats all under fedora 25, and centos 7.

works like a charm.

sometimes removing NM leaves resolv.conf pointing to the networkmanager
directory, and its best to check this, and replace your resolv.conf link
with a file with the correct settings.

sorry if this upsets the people who maintain network mangler, but its
inappropriate on a server.

This is terribly bad advice I'm afraid ...

https://access.redhat.com/solutions/783533

The legacy network service is a fragile compilation of shell scripts
(which is why certain changes like some bonding or tagging alterations
require a full system restart or very careful unpicking manually with
ip) and is effectively deprecated in RHEL at this time due to major
bug fixes only but no feature work.

You really should have a read through this as well:

https://www.hogarthuk.com/?q=node/8

On EL6 yes NM should be removed on anything but a wifi system but on
EL7 unless you fall into a specific edge case as per the network docs:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Networking_Guide/index.html

you really should be using NM for a variety of reasons.

Incidentally Mark, this had nothing to do with systemd ... I wish you
would pick your topics a little more appropriately rather than
tempting the usual flames.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

James

This was not A flame at all, but another voice of frustration at the
ongoing

adoption of workstation like features of the Redhat OS.

heres one of the reasons not to use NM in a server

we use bonding on all our systems

from that article you posted

Certain interface bonding configuration options as defined by the
BONDING_OPTS parameter in the interface's ifcfg file may not be
compatible with NetworkManager. ( Solution 1249593
)

in fact anyone who has tried to use bonding with NM will know why I
dislike it.

thanks for that, article, this next bug had caught me, on an older build
, now its fixed, but the fix did not go and backfix a broken config.

When transitioning from NetworkManager to using the network initscript,
the default gateway parameter in the interface's ifcfg file will be
depicted as 'GATEWAY0'. In order for the ifcfg file to be compatible
with the network initscript, this parameter must be renamed to
'GATEWAY'. This limitation will be addressed in an upcoming release of
RHEL7.

one to watch out for on the removing NM, plus the resolv.conf one.

Anyway, for anyone else, make you own mind up whether this is good or
bad advise, test it, and see how your mileage varies, Ive had more
problems with NM than ive had with initscripts.

regards peter

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

Re: [CentOS] CentOS 7, systemd, NetworkMangler, oh, my

On 02/13/2017 11:15 AM, Gordon Messmer wrote:
> On 02/13/2017 07:35 AM, m.r...@5-cent.us wrote:
>> Finally, I do an ifdown, followed by an ifup, and everything's wonderful.
> 
> What's in /etc/sysconfig/network-scripts/ifcfg-? Does it say
> NM_CONTROLLED=no?

or

onboot=no






signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 7, systemd, NetworkMangler, oh, my

2017-02-13 Thread Gordon Messmer


On 02/13/2017 07:35 AM, m.r...@5-cent.us wrote:

Finally, I do an ifdown, followed by an ifup, and everything's wonderful.


What's in /etc/sysconfig/network-scripts/ifcfg-? Does it say 
NM_CONTROLLED=no?



My manager thinks that the NM daemon thinks everything's fine, and
there've been no changes, so it does nothing. He suggests that it might
have to be stopped, then started, rather than restarted.


"systemctl restart NetworkManager" completely stops the service and 
starts it again.



This is completely unacceptable behavior, since it leave the system with
no network connection. Pre-systemd, as we all know, restart *RESTARTED*
the damn thing.


Still does.

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

Re: [CentOS] A question on networking (CentOS 6)

2017-02-13 Thread Gordon Messmer


On 02/13/2017 06:55 AM, KM wrote:

The NIC went bad and it has been replaced.  I knew enough to update the HW 
address in the ifcfg-* files.  The network service restarts successfully 
without errors.  However I cannot connect via ping or ssh with the pt2pt 
network setup on 192.168.x.*.  When I use our internal network ip addresses it 
is fine.


That's not much to go on.  The output of "ip addr show" and "ip route 
show" might help you figure out what's going on.  Do your interfaces 
have the expected names?  Do they have the expected IP addresses?


One thing that might be problematic is that there are multiple systems 
that attempt to maintain consistent interface names.  If your interface 
names are not what you expect, you might need to look at 
/etc/udev/rules.d/70-persistent-net.rules where there may be additional 
rules mapping specific MAC addresses to an interface name.


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

Re: [CentOS] CentOS 7, systemd, NetworkMangler, oh, my

2017-02-13 Thread James Hogarth

On 13 February 2017 at 16:17, peter.winterflood
 wrote:
>
>
>
> there's a really good solution to this.
>
> yum remove NetworkManager*
>
> chkconfig network on
>
> service network start
>
> and yes thats all under fedora 25, and centos 7.
>
> works like a charm.
>
> sometimes removing NM leaves resolv.conf pointing to the networkmanager
> directory, and its best to check this, and replace your resolv.conf link
> with a file with the correct settings.
>
> sorry if this upsets the people who maintain network mangler, but its
> inappropriate on a server.
>
>

This is terribly bad advice I'm afraid ...

https://access.redhat.com/solutions/783533

The legacy network service is a fragile compilation of shell scripts
(which is why certain changes like some bonding or tagging alterations
require a full system restart or very careful unpicking manually with
ip) and is effectively deprecated in RHEL at this time due to major
bug fixes only but no feature work.

You really should have a read through this as well:

https://www.hogarthuk.com/?q=node/8

On EL6 yes NM should be removed on anything but a wifi system but on
EL7 unless you fall into a specific edge case as per the network docs:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Networking_Guide/index.html

you really should be using NM for a variety of reasons.

Incidentally Mark, this had nothing to do with systemd ... I wish you
would pick your topics a little more appropriately rather than
tempting the usual flames.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 7, systemd, NetworkMangler, oh, my

2017-02-13 Thread peter.winterflood



On 13/02/17 15:35, m.roth wrote:

My manager tells me a system in the datacenter is down. I go down there,
and plug in a monitor-on-a-stick and keyboard. It's up, but no network. I
try systemctl restart NetworkManager several times, and ip a shows *no*
change.

Finally, I do an ifdown, followed by an ifup, and everything's wonderful.

My manager thinks that the NM daemon thinks everything's fine, and
there've been no changes, so it does nothing. He suggests that it might
have to be stopped, then started, rather than restarted.

This is completely unacceptable behavior, since it leave the system with
no network connection. Pre-systemd, as we all know, restart *RESTARTED*
the damn thing.

Is there some Magic (#insert "pixie-dust-sparkles") incantation, either
restarting NetworkManager, or using nm-cli, to force it to perform the
expected actions?

Btw, if this is supposed to be part of the "hide stuff, desktop Linux
users don't need to know this stuff", this is a *much* worse result.

 mark (and yes, my manager's truly aggravated about this, also)



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


there's a really good solution to this.

yum remove NetworkManager*

chkconfig network on

service network start

and yes thats all under fedora 25, and centos 7.

works like a charm.

sometimes removing NM leaves resolv.conf pointing to the networkmanager 
directory, and its best to check this, and replace your resolv.conf link 
with a file with the correct settings.


sorry if this upsets the people who maintain network mangler, but its 
inappropriate on a server.


regards peter

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

Re: [CentOS] CentOS 7, systemd, NetworkMangler, oh, my

2017-02-13 Thread James Hogarth

On 13 February 2017 at 15:35,   wrote:
> My manager tells me a system in the datacenter is down. I go down there,
> and plug in a monitor-on-a-stick and keyboard. It's up, but no network. I
> try systemctl restart NetworkManager several times, and ip a shows *no*
> change.
>
> Finally, I do an ifdown, followed by an ifup, and everything's wonderful.
>
> My manager thinks that the NM daemon thinks everything's fine, and
> there've been no changes, so it does nothing. He suggests that it might
> have to be stopped, then started, rather than restarted.
>
> This is completely unacceptable behavior, since it leave the system with
> no network connection. Pre-systemd, as we all know, restart *RESTARTED*
> the damn thing.
>
> Is there some Magic (#insert "pixie-dust-sparkles") incantation, either
> restarting NetworkManager, or using nm-cli, to force it to perform the
> expected actions?
>

I'd be interested in the journal from the NetworkManager restart as
that's not the way it behaves ... it uses the netlink API to get state
and not it's own internal tracker of state (ie doing an ip link down
will reflect in nmcli output) ... a restart of NetworkManager should
not ignore interfaces but rather bring the system to the on disk
configured state ... and a quick check it doesn't override ExecRestart
in the unit file to do a reload or similar instead ...

And indeed a quick test in a VM shows nmcli device status correctly
changing between connected and unavailable when doing ip link set eth0
down/up

Do note that on a NM based system ifup and ifdown are effectively
aliases to nmcli conn down and nmcli conn up

nmcli conn down "connection name" will make it disconnected
nmcli conn up "connection mame" will bring it back to connected

there is a slight interesting difference between using nmcli and ip
link set though ...

with ip link set down  the interface is marked
administratively down (as if you've pulled the cable) but nmcli conn
down "connection name" will unconfigure the interface but leave it in
an UP state ... just without an IP address etc

anyway that's just an interesting diversion on behavioural differences

NM won't change an interface state without some sort of event though
(manual or virtual cable pulled etc), and if you have a case where it
*has* done that then you have found a bug that would be great to get
reported

TL;DR: cannot reproduce, need logs to determine what happened without
a working crystal ball
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] CentOS 7, systemd, NetworkMangler, oh, my

My manager tells me a system in the datacenter is down. I go down there,
and plug in a monitor-on-a-stick and keyboard. It's up, but no network. I
try systemctl restart NetworkManager several times, and ip a shows *no*
change.

Finally, I do an ifdown, followed by an ifup, and everything's wonderful.

My manager thinks that the NM daemon thinks everything's fine, and
there've been no changes, so it does nothing. He suggests that it might
have to be stopped, then started, rather than restarted.

This is completely unacceptable behavior, since it leave the system with
no network connection. Pre-systemd, as we all know, restart *RESTARTED*
the damn thing.

Is there some Magic (#insert "pixie-dust-sparkles") incantation, either
restarting NetworkManager, or using nm-cli, to force it to perform the
expected actions?

Btw, if this is supposed to be part of the "hide stuff, desktop Linux
users don't need to know this stuff", this is a *much* worse result.

mark (and yes, my manager's truly aggravated about this, also)



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

[CentOS] A question on networking (CentOS 6)