[CentOS] dhcpcd.conf

[Alice Wonder]

Hi,

ran into a problem w/ linode hosted VM where IPv6 address changed after 
they migrated it to a different host.


They claim I can fix it with

sed -i 's/slaac private/slaac hwaddr/' /etc/dhcpcd.conf

However there appears to be no dhcpcd.conf on any of my CentOS 7 systems.

What is the CentOS 7 equivalent?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

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

[m . roth]

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

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

[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)

[KM]

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)

[KM]

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

[m . roth]

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

[m . roth]

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

[m . roth]

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): Activation: starti

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

[KM]

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

[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

[Johnny Hughes]

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

[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)

[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

[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

[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

[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

[m . roth]

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)

[KM]

 Hi AllThis is NOT specifically related to CentOS per se.  I have 2 servers 
that are on two networks.  I did NOT set this up.  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.
I am not sure how to troubleshoot this separate connection.   What can I 
provide here that will allow someone to help?  Thanks in advance.  I tried 
searching a bit but didn't find anything of use so far.
KM
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Wich web browser on CentOS6 ?

[James B. Byrne]

On Fri, February 10, 2017 15:44, Alice Wonder wrote:
> On 02/10/2017 12:34 PM, James B. Byrne wrote:
>>
>> On Fri, February 10, 2017 06:26, Patrick Begou wrote:
>>> Hello
>>>
>>> I have more and more troubles using firefox in professional
>>> environment with
>>> CentOS6. The latest version is 45.7.0 But I can't use it anymore to
>>> access some
>>> old server hardware (IDRAC7 of DELL C6100) because of
>>> "/SSL_ERROR_WEAK_SERVER_CERT_KEY/".  I had to install an old
>>> Firefox32
>>> version
>>> to administrate these servers.
>>>
>>> Today I upgrade the firmware of 2 DELL switch and now Firefox
>>> cannot
>>> connect to them anymore saying: /An error occurred during a
>>> connection to xxx.xxx.xxx.xxx. The server rejected
>>> the handshake because the client downgraded to a lower TLS version
>>> than the server supports// //SSL_ERROR_INAPPROPRIATE_FALLBACK_ALERT
>>>
>>> /Is there a CentOS6 recommended web browser allowing continuous
>>> connections to olds and new base level (and local) system
>>> administration services ?
>>>
>>
>> This situation arises because older, dare I say old, equipment
>> released with embedded software and using http/https as the
>> administrative front end were shipped with minimally compliant x-509
>> certificates.  Often self-signed with 1kb keys and md5 signature
>> hashes. Not to mention many are past their expiry dates.
>>
>> However, given the revelations of state sanctioned snooping on
>> network
>> traffic browsers are being pushed to implement increased compliance
>> checking for the overall security of users. Firefox is simply
>> implementing what various 'authorities' are recommending as secure
>> practices with respect to authentication using pki and x-509
>> certificates.
>>
>> The present situation is a PIA.  It could be a lot more
>> user-friendly
>> if FF so chose. They could have easily allowed one to turn off these
>> advanced compliance checks for specific IP and DNS addresses so that
>> the intended benefit remained but the interference with existing
>> infrastructure was minimised.
>>
>> But, FF is on its own chosen path to oblivion and the idea of
>> compromise is totally absent from their project plan.
>>
>>
>
> IMHO FireFox is doing the right thing. Compromises in policy is how
> system compromises often happen.
>
> If you can change the setting to be more forgiving of certain bad
> vendors, then so can malware.
>
> What we really need to do is demand better from the manufacturers of
> products we use in a "professional environment" - and it is extremely
> important we demand better from them now, during the dawn of IoT.
>
>

It is a bit difficult for an end user to insist that a vendor improve
a ten year old piece of equipment.  Sure, that might be as simple as a
firmware update. But why not insist that people buy new product
instead and thereby add to the bottom line?  Which way do see most
commercial firms going?

FF is a consumer item that is being shipped with a supposedly
Enterprise Linux distribution.  This leads to problems that are
created by the divergence between the target audience and Enterprise
users.  Enterprises tend to have a much more robustly secured gateware
to the wider Internet than consumers.  Which for that audience makes a
lot of the more esoteric security enhancements rather useless.  If an
intruder can carry out a MTM attack on your internal LAN then nothing
FF can do is going to have much of an effect.

A professional organisation would not simply cut administrators off
from the devices that they are required to manage. Nor would it
dictate how a company spends its money on hardware.  A bunch of
self-righteous zealots might.  Which may account for the fact that FF
(all versions) market share is now less than 10%.[1]

[1]
https://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0&qptimeframe=M&qpsp=216&qpfilter=ColumnName%09LK%09Fire*


-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

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

[CentOS] Alsa pulseaudio & procmail

[Adrian van Bloois]

Hi,
I'm using a program called morse to generate morse code signals when mail
is received. This is done by calling this program depending on de subject
or from of the incoming mail.
THis worked fine on CentOS 6 but since I'm using CentOS 7 it does nt work
anymore.
In my procmail logging I get:
ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection 
refused

Can't access speaker.


Normal listening to streams on the Internet works fine, the program morse
itself works fine, but runningit from procmail fails.
Any ideas?

Adrian



-- 
Adri P. van Bloois
Antonlaan 104   email:  adr...@pa0rda.nl
3701 VG Zeist   voice:  +31-(0)-30-6912741
The Netherlands fax:NONE

52 05'15.77"N 5 4'44.56"E
QTH-locater  JO 22 OC


"Elegance is not a dispensable luxury but a factor that decides between 
 success and failure."
Edsger W. Dijkstra
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Manual Install fail in first steps

[Andreas Benzler]

Hello everyone,

while I wanne try out very special partition, i walk through

https://wiki.centos.org/HowTos/ManualInstall

but fail allready at 

"INSTALL setup basesystem filesystem"

This is very clear  to me, because rpm don't know the full path (real
version) or is there some thing wrong ??

Anaconda it self works with groups like @base etc...

Very wired. Doesn't looks like up to date.

Sincerely

Andy

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

Re: [CentOS] Automounting a USB drive

[TE Dukes]

> -Original Message-
> From: CentOS [mailto:centos-boun...@centos.org] On Behalf Of fred roller
> Sent: Monday, February 13, 2017 12:10 AM
> To: CentOS mailing list
> Subject: Re: [CentOS] Automounting a USB drive
> 
> On Sun, Feb 12, 2017 at 10:11 PM,  wrote:
> 
> > If i manually mount it from a terminal, I have read/write access.
> >
> 
> Seems a permission issue.  su to root after the "auto" mount and take a
look.
> If you can see your file or can write a touch file then your user may not
be in
> the necessary owner/group to view/write to the structure.
> Seen similar problems in upgrades... same user but the UID changed in the
> upgrade and blinded the current user to older files that were preserved.
A
> simple chmod command from root fixed the issue to restore proper
> ownership.  Just a wag, but sometimes it's the little things.
> 
> -- Fred

Let me add this which I failed to mention.

This was a fresh install as a "Server with Desktop". I have been adding
packages as needed.

Week before last when working on this, I was looking through the logs and
found REAR need syslinux which wasn't installed. I may not have all the
packages installed I need. I run REAR as a cron job around 2AM. If I did a
reboot/restart and forgot to manually mount the USB drive or forgot to click
on it gnom, which is usually the case, I don't get a backup.

It ran last night and I was OK, but I'd still need to find out why its not
mounting by itself.

Thanks

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