[CentOS] CentOS 6 update issues
Hello all, I manage a few servers overseas that are running CentOS 6. When performing a yum update, it fails because it's trying to download from: mirror.centos.org/centos/*6.6*/extras/x86_64/repodata/repomd.xml Which fails due to the fact that the entire 6.6 directory is empty on all of the mirrors I have checked. From what I can tell it should be using: mirror.centos.org/centos/*6*/extras/x86_64/repodata/repomd.xml Does anyone have any idea why this would be happening? Obviously changing the CentOS-Base file to use 'baseurl' rather than 'mirrorlist' is a workaround, but I would prefer a more permanent solution, and would like to know why this is happening. Thanks in advance. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 6 update issues
Hello Clint, Our Centos-base.repo file looks like this: [base] name=CentOS-$releasever - Base mirrorlist= http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os #baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 I also tried yours, however I experienced the same issue. It seems like it's replacing the "releaserver" variable with 6.6, rather than 6, I'm not sure why though. On 19 October 2015 at 14:59, John R Pierce wrote: > On 10/18/2015 8:21 PM, John Cenile wrote: > >> Which fails due to the fact that the entire 6.6 directory is empty on all >> of the mirrors I have checked. >> > > isn't 6.7 out ? why would there be anything left in 6.6 ? > > -- > john r pierce, recycling bits in santa cruz > > > ___ > 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 6 update issues
I have tried yum clean all multiple times, no luck. :( Any other ideas? On 19 October 2015 at 18:01, James Pearson wrote: > > > > On 19 Oct 2015, at 04:22, "John Cenile" wrote: > > > > When performing a yum update, it fails because it's trying to download > from: > > > > mirror.centos.org/centos/*6.6*/extras/x86_64/repodata/repomd.xml > > > > Which fails due to the fact that the entire 6.6 directory is empty on all > > of the mirrors I have checked > > I had something similar happen recently when upgrading a box from 6.6 to > 6.7 > > I 'fixed' it by running 'yum clean all' first > > I did think it odd at the time - but didn't get round to trying to find > out why ... > > James Pearson > ___ > 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 6 update issues
Thanks for the suggestions, unfortunately that file doesn't exist. I'm very confused as to why it's trying to download from /6.6/. The output of rpm -qi centos-release-6-4.el6.centos.10.x86_64 is: Name: centos-release Relocations: (not relocatable) Version : 6 Vendor: CentOS Release : 4.el6.centos.10 Build Date: Mon 25 Feb 2013 07:57:43 PM EST Install Date: Fri 05 Jul 2013 09:32:33 AM EST Build Host: c6b8.bsys.dev.centos.org Group : System Environment/Base Source RPM: centos-release-6-4.el6.centos.10.src.rpm Size: 32670License: GPLv2 Signature : RSA/SHA1, Sat 02 Mar 2013 01:01:26 AM EST, Key ID 0946fca2c105b9de Packager: CentOS BuildSystem <http://bugs.centos.org> Summary : CentOS release file Description : CentOS release files On 19 October 2015 at 19:59, James Pearson wrote: > John Cenile wrote: > >> I have tried yum clean all multiple times, no luck. :( >> > > Also check you don't have the file /etc/yum/vars/releasever - the contents > of this will override the value of $releasever in the repo files > > > James Pearson > > ___ > 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 6 update issues
Sorry, I just copied any line from the repo file. :) On 19 October 2015 at 22:39, Nicolas Thierry-Mieg < nicolas.thierry-m...@imag.fr> wrote: > On 10/19/2015 07:20 AM, John Cenile wrote: > >> Hello Clint, >> >> Our Centos-base.repo file looks like this: >> >> [base] >> name=CentOS-$releasever - Base >> mirrorlist= >> http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os >> #baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/ >> gpgcheck=1 >> gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 >> >> >> I also tried yours, however I experienced the same issue. It seems like >> it's replacing the "releaserver" variable with 6.6, rather than 6, I'm not >> sure why though. >> > > > In your initial post you mentioned problems with extras. Here you are > changing the stanza of base. > What is your stanza for "extras"? > > > > On 19 October 2015 at 14:59, John R Pierce wrote: >> >> On 10/18/2015 8:21 PM, John Cenile wrote: >>> >>> Which fails due to the fact that the entire 6.6 directory is empty on all >>>> of the mirrors I have checked. >>>> >>>> >>> isn't 6.7 out ? why would there be anything left in 6.6 ? >>> >>> > ___ > 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 6 update issues
I'm actually not able to connect to that host: # curl "http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=extras"; curl: (7) couldn't connect to host Which lead me to discover that our entire network is picking up " mirrorlist.centos.org" as 204.15.73.243, which I'm not able to ping from any host in a few different countries I tried. However, if I ping mirrorlist.centos.org from Europe, it resolves to 84.22.180.89, or from USA it resolves to 88.150.173.218, or from Asia it resolves to 108.61.16.227. Could there be an issue with this specific mirrorlist server (204.15.73.243)? On 20 October 2015 at 01:56, Johnny Hughes wrote: > On 10/19/2015 06:49 AM, John Cenile wrote: > > Thanks for the suggestions, unfortunately that file doesn't exist. > > > > I'm very confused as to why it's trying to download from /6.6/. > > > > The output of rpm -qi centos-release-6-4.el6.centos.10.x86_64 is: > > > > Name: centos-release Relocations: (not relocatable) > > Version : 6 Vendor: CentOS > > Release : 4.el6.centos.10 Build Date: Mon 25 Feb 2013 > > 07:57:43 PM EST > > Install Date: Fri 05 Jul 2013 09:32:33 AM EST Build Host: > > c6b8.bsys.dev.centos.org > > Group : System Environment/Base Source RPM: > > centos-release-6-4.el6.centos.10.src.rpm > > Size: 32670License: GPLv2 > > Signature : RSA/SHA1, Sat 02 Mar 2013 01:01:26 AM EST, Key ID > > 0946fca2c105b9de > > Packager: CentOS BuildSystem <http://bugs.centos.org> > > Summary : CentOS release file > > Description : > > CentOS release files > > > > > > On 19 October 2015 at 19:59, James Pearson > > wrote: > > > >> John Cenile wrote: > >> > >>> I have tried yum clean all multiple times, no luck. :( > >>> > >> > >> Also check you don't have the file /etc/yum/vars/releasever - the > contents > >> of this will override the value of $releasever in the repo files > >> > >> > >> James Pearson > >> > >> ___ > >> 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 > > > > What does this command give you from that machine: > > curl "http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=extras"; > > Are you using ipv4 or ipv6? > > > ___ > 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 6 update issues
Hello Johnny, That appears to be it, our network DNS resolvers were caching an old record from the looks of it. I've cleared the cache, and everything is now working perfectly. Thank you (all) for the help, I wasn't even aware that the 204.15.73.243 address was no longer valid. On 21 October 2015 at 05:35, Johnny Hughes wrote: > On 10/20/2015 01:28 PM, Jonathan Billings wrote: > > On Tue, Oct 20, 2015 at 12:29:06PM -0500, Johnny Hughes wrote: > >> Those 3 addresses are good, the 204.15.73.243 is incorrect. > > > > 204.15.73.243 reverse resolves to centos.at.multacom.com. > > multacom is a CentOS Sponsor according to: > > https://www.centos.org/sponsors/ > > > > An outdated config somewhere? > > > I don't think so on our end, but that was at one time a good address. > > Maybe the site in question has a static address added in a hosts file, etc. > > > ___ > 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
[CentOS] OpenSwan Drop Out Issue
Hello,
I'm cross posting this from the OpenSwan mailing list, in case someone here
can help.
We have two sites connected via OpenSwan 2.6.32-9 on CentOS 5, sharing 6
/24 subnets each (so 12 in total).
The problem we're having is completely randomly, be it in the middle of the
day, or in the middle of the night (so I don't believe it's traffic
related), certain (and sometimes all) routes will drop. They usually
recover after a few minutes, but it's still long enough for our monitoring
to detect downtime.
The configuration we have on each device is:
conn site-a
keyingtries=0
keylife=1h
ikelifetime=8h
left=1.1.1.1
right=2.2.2.2
leftsubnets={x.x.x.x/24,x.x.x.x/24,x.x.x.x/24,x.x.x.x/24,x.x.x.x/24,x.x.x.x/24}
rightsubnets={x.x.x.x/24,x.x.x.x/24,x.x.x.x/24,x.x.x.x/24,x.x.x.x/24,x.x.x.x/24}
pfs=yes
auto=start
authby=secret
dpddelay=30
dpdtimeout=120
dpdaction=hold
phase2alg=aes256-sha1;modp1536
phase2=esp
ike=aes256-sha1;modp1536
It's mirrored exactly the same on the other side.
I have tried changing the dead peer detection timeout to something high (5
minutes), and removing it completely (which I believe defaults it to 30
seconds), neither of which made any difference.
I can't see any very obvious errors in the logs, however the most recent
drop out produced the following message around the same time:
Feb 10 00:53:09 site-b-vpn pluto[30584]: "site-a/5x5" #39: max number of
retransmissions (2) reached STATE_QUICK_I1
Feb 10 00:53:09 site-b-vpn pluto[30584]: "site-a/5x5" #39: starting keying
attempt 2 of an unlimited number
Feb 10 00:53:09 site-b-vpn pluto[30584]: "site-a/5x5" #95: initiating Quick
Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW+SAREFTRACK to replace #39 {using
isakmp#52 msgid:119495de proposal=AES(12)_256-SHA1(2)_160
pfsgroup=OAKLEY_GROUP_MODP1536}
and also
Feb 10 00:52:25 site-a-vpn pluto[2414]: "site-b/6x6" #1: ignoring Delete SA
payload: PROTO_IPSEC_ESP SA(0xde58eea3) not found (maybe expired)
Feb 10 00:52:25 site-a-vpn pluto[2414]: "site-b/6x6" #1: received and
ignored informational message
Feb 10 00:52:25 site-a-vpn pluto[2414]: "site-b/6x6" #1: ignoring Delete SA
payload: PROTO_IPSEC_ESP SA(0xa5298d7d) not found (maybe expired)
Feb 10 00:52:25 site-a-vpn pluto[2414]: "site-b/6x6" #1: received and
ignored informational message
Before we move to another solution, does anyone have any suggestions on
what the problem might be? Running a constant ping between the two hosts
doesn't drop *any* packets (even when the IPSec connection itself drops
out).
Thanks in advance.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OpenSwan Drop Out Issue
Thanks, I've updated the config with the following:
keylife=20m
ikelifetime=2h
I'll see how that goes.
In the mean time, any other suggestions would be greatly appreciated.
On 10 February 2016 at 02:14, Eero Volotinen wrote:
> Try setting lower keyexpiry time on other endpoint.
>
> --
> Eero
>
> 2016-02-09 17:04 GMT+02:00 John Cenile :
>
>> Hello,
>>
>> I'm cross posting this from the OpenSwan mailing list, in case someone
>> here
>> can help.
>>
>> We have two sites connected via OpenSwan 2.6.32-9 on CentOS 5, sharing 6
>> /24 subnets each (so 12 in total).
>>
>> The problem we're having is completely randomly, be it in the middle of
>> the
>> day, or in the middle of the night (so I don't believe it's traffic
>> related), certain (and sometimes all) routes will drop. They usually
>> recover after a few minutes, but it's still long enough for our monitoring
>> to detect downtime.
>>
>> The configuration we have on each device is:
>>
>> conn site-a
>> keyingtries=0
>> keylife=1h
>> ikelifetime=8h
>> left=1.1.1.1
>> right=2.2.2.2
>>
>>
>> leftsubnets={x.x.x.x/24,x.x.x.x/24,x.x.x.x/24,x.x.x.x/24,x.x.x.x/24,x.x.x.x/24}
>>
>>
>> rightsubnets={x.x.x.x/24,x.x.x.x/24,x.x.x.x/24,x.x.x.x/24,x.x.x.x/24,x.x.x.x/24}
>> pfs=yes
>> auto=start
>> authby=secret
>> dpddelay=30
>> dpdtimeout=120
>> dpdaction=hold
>> phase2alg=aes256-sha1;modp1536
>> phase2=esp
>> ike=aes256-sha1;modp1536
>>
>> It's mirrored exactly the same on the other side.
>>
>> I have tried changing the dead peer detection timeout to something high (5
>> minutes), and removing it completely (which I believe defaults it to 30
>> seconds), neither of which made any difference.
>>
>> I can't see any very obvious errors in the logs, however the most recent
>> drop out produced the following message around the same time:
>>
>> Feb 10 00:53:09 site-b-vpn pluto[30584]: "site-a/5x5" #39: max number of
>> retransmissions (2) reached STATE_QUICK_I1
>> Feb 10 00:53:09 site-b-vpn pluto[30584]: "site-a/5x5" #39: starting keying
>> attempt 2 of an unlimited number
>> Feb 10 00:53:09 site-b-vpn pluto[30584]: "site-a/5x5" #95: initiating
>> Quick
>> Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW+SAREFTRACK to replace #39 {using
>> isakmp#52 msgid:119495de proposal=AES(12)_256-SHA1(2)_160
>> pfsgroup=OAKLEY_GROUP_MODP1536}
>>
>> and also
>>
>> Feb 10 00:52:25 site-a-vpn pluto[2414]: "site-b/6x6" #1: ignoring Delete
>> SA
>> payload: PROTO_IPSEC_ESP SA(0xde58eea3) not found (maybe expired)
>> Feb 10 00:52:25 site-a-vpn pluto[2414]: "site-b/6x6" #1: received and
>> ignored informational message
>> Feb 10 00:52:25 site-a-vpn pluto[2414]: "site-b/6x6" #1: ignoring Delete
>> SA
>> payload: PROTO_IPSEC_ESP SA(0xa5298d7d) not found (maybe expired)
>> Feb 10 00:52:25 site-a-vpn pluto[2414]: "site-b/6x6" #1: received and
>> ignored informational message
>>
>> Before we move to another solution, does anyone have any suggestions on
>> what the problem might be? Running a constant ping between the two hosts
>> doesn't drop *any* packets (even when the IPSec connection itself drops
>> out).
>>
>> Thanks in advance.
>> ___
>> 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] OpenSwan Drop Out Issue
So lowering the keylife / ikelifetime didn't solve the problem. I've enabled debugging and I'll see what it says. Unfortunately we can't (easily) upgrade CentOS, do you believe that would make a huge difference though? Are the newer versions of OpenSwan *that *much more reliable? On 10 February 2016 at 04:58, Eero Volotinen wrote: > Centos 5 is also a bit old os. Is it possible to use newer version? (like > centos 7 or centos 6?) > > Eero > > 2016-02-09 19:52 GMT+02:00 Gordon Messmer : > > > On 02/09/2016 07:04 AM, John Cenile wrote: > > > >> does anyone have any suggestions on what the problem might be? > >> > > > > Not off the top of my head, but if I were you, I'd enable debugging of > > "control" and "dpd". See man ipsec.conf (/plutodebug) and man > ipsec_pluto. > > > > ___ > > 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 > ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OpenSwan Drop Out Issue
As I said though, there's no lost ICMP packets, even when the IPSec tunnel drops out. I do notice a lot of these errors in the secure log though, would this be any indication of a problem? (I'm grepping for this specific error, they're not the only messages in there). Feb 11 14:18:10 site-a pluto[10450]: "site-b/1x1" #803: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0x01f90e1d) not found (maybe expired) Feb 11 14:18:14 site-a pluto[10450]: "site-b/1x1" #803: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0xb3681486) not found (maybe expired) Feb 11 14:18:14 site-a pluto[10450]: "site-b/1x1" #803: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0x6ad588f5) not found (maybe expired) Feb 11 14:19:07 site-a pluto[10450]: "site-b/1x1" #803: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0xe05ced4d) not found (maybe expired) Feb 11 14:19:08 site-a pluto[10450]: "site-b/1x1" #803: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0x7cd46e9e) not found (maybe expired) Feb 11 14:19:38 site-a pluto[10450]: "site-b/1x1" #803: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0x07164936) not found (maybe expired) Feb 11 14:19:55 site-a pluto[10450]: "site-b/1x1" #803: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0x9e68c142) not found (maybe expired) Feb 11 14:19:58 site-a pluto[10450]: "site-b/1x1" #803: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0xcbb10063) not found (maybe expired) Feb 11 14:20:16 site-a pluto[10450]: "site-b/1x1" #803: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0x7a160d48) not found (maybe expired) Feb 11 14:20:26 site-a pluto[10450]: "site-b/1x1" #803: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0x18a63776) not found (maybe expired) Feb 11 14:21:11 site-a pluto[10450]: "site-b/1x1" #803: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0x09eb87c4) not found (maybe expired) Feb 11 14:21:11 site-a pluto[10450]: "site-b/1x1" #803: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0xb2438c9b) not found (maybe expired) Feb 11 14:21:15 site-a pluto[10450]: "site-b/1x1" #803: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0x04236e6a) not found (maybe expired) Feb 11 14:21:52 site-a pluto[10450]: "site-b/1x1" #803: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0x456f7468) not found (maybe expired) Feb 11 14:21:57 site-a pluto[10450]: "site-b/1x1" #803: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0x8ee90acd) not found (maybe expired) Feb 11 14:22:04 site-a pluto[10450]: "site-b/1x1" #803: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0xc6676973) not found (maybe expired) Feb 11 14:22:04 site-a pluto[10450]: "site-b/1x1" #803: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0xc3b43142) not found (maybe expired) Feb 11 14:22:30 site-a pluto[10450]: "site-b/1x1" #803: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0x37111e62) not found (maybe expired) Feb 11 14:22:35 site-a pluto[10450]: "site-b/1x1" #803: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0xb6e63098) not found (maybe expired) Feb 11 14:23:24 site-a pluto[10450]: "site-b/1x1" #803: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0xbd94fd66) not found (maybe expired) Feb 11 14:24:05 site-a pluto[10450]: "site-b/1x1" #803: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0x36f47642) not found (maybe expired) Feb 11 14:24:18 site-a pluto[10450]: "site-b/1x1" #803: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0xababea68) not found (maybe expired) Feb 11 14:24:33 site-a pluto[10450]: "site-b/1x1" #803: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0x9088954e) not found (maybe expired) Feb 11 14:24:46 site-a pluto[10450]: "site-b/1x1" #803: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0x5f1ba8d3) not found (maybe expired) On 10 February 2016 at 17:48, Eero Volotinen wrote: > Well. Centos 5 is really near of it's end of life. There is not much > updates to kernel or openswan. You should at least try latest openswan > version. > > Your issue looks like a bit network problem. > > -- > Eero > > 2016-02-10 8:34 GMT+02:00 John Cenile : > > > So lowering the keylife / ikelifetime didn't solve the problem. I've > > enabled debugging and I'll see what it says. > > > > Unfortunately we can't (easily) upgrade CentOS, do you believe that would > > make a huge difference though? Are the newer versions of OpenSwan *that > > *much > > more reliable? > > > > On 10 February 2016 at 04:58, Eero Volotinen > > wrote: > > > > > Centos 5 is also a bit old os. Is it possible to use newer version? > (like > > > centos 7 or centos 6?) > > > > > > Eero > > > > > > 2016-02-09 19:52 GMT+02:00 Gordon Messmer : > > > >
[CentOS] Openswan <-> VyOS
Hello,
I'm having a bit of trouble connecting our current CentOS Openswan server
with a Vyos server via IPSec.
I've posted this on the VyOS forums, but haven't had many helpful
responses, so I thought I would ask here.
http://forum.vyos.net/showthread.php?tid=26504&pid=29703#pid29703
Basically our Openswan configuration is as follows:
conn VYOS
keyingtries=0
keylife=20m
ikelifetime=2h
left=
right=
leftsubnets={
10.1.1.0/24,10.1.2.0/24,10.1.3.0/24,10.1.4.0/24,10.1.5.0/24}
rightsubnets={10.2.1.0/24,10.2.2.0/24,10.2.3.0/24,10.2.4.0/24}
auto=start
authby=secret
dpddelay=30
dpdtimeout=120
dpdaction=hold
phase2alg=aes256-sha1;modp1536
phase2=esp
ike=aes256-sha1;modp1536
Our VyOS configuration is posted in the above forum post, except now I have
followed their advice and created 20 tunnels (each subnet to each subnet,
if that makes sense).
However, when I enabled this, I got the following errors on the Openswan
server:
Feb 18 01:24:27 OPENSWAN pluto[8010]: "VYOS/3x3" #70: next payload type of
ISAKMP Hash Payload has an unknown value: 243
Feb 18 01:24:27 OPENSWAN pluto[8010]: "VYOS/3x3" #70: malformed payload in
packet
Feb 18 01:24:27 OPENSWAN pluto[8010]: "VYOS/3x3" #70: sending notification
PAYLOAD_MALFORMED to :500
Feb 18 01:24:27 OPENSWAN pluto[8010]: "VYOS/4x4" #69: next payload type of
ISAKMP Hash Payload has an unknown value: 170
Feb 18 01:24:27 OPENSWAN pluto[8010]: "VYOS/4x4" #69: malformed payload in
packet
Feb 18 01:24:27 OPENSWAN pluto[8010]: "VYOS/5x4" #68: next payload type of
ISAKMP Hash Payload has an unknown value: 63
Feb 18 01:24:27 OPENSWAN pluto[8010]: "VYOS/5x4" #68: malformed payload in
packet
And on our VyOS server we got the following errors:
Feb 18 01:17:19 VYOS pluto[20807]: "peer--tunnel-20" #381:
sending encrypted notification INVALID_ID_INFORMATION to :500
Feb 18 01:17:19 VYOS pluto[20807]: "peer--tunnel-20" #381:
cannot respond to IPsec SA request because no connection is known for
10.1.1.0/24===[]...[]===
10.2.3.0/24
Feb 18 01:17:19 VYOS pluto[20807]: "peer--tunnel-20" #381:
sending encrypted notification INVALID_ID_INFORMATION to :500
Feb 18 01:17:23 VYOS pluto[20807]: "peer--tunnel-11" #422:
cannot install eroute -- it is in use for "peer--tunnel-3" #403
Feb 18 01:17:23 VYOS pluto[20807]: "peer--tunnel-16" #421:
cannot install eroute -- it is in use for "peer--tunnel-4" #395
Feb 18 01:17:23 VYOS pluto[20807]: "peer--tunnel-20" #420:
cannot install eroute -- it is in use for "peer--tunnel-5" #417
Feb 18 01:17:23 VYOS pluto[20807]: "peer--tunnel-20" #381:
Informational Exchange message must be encrypted
Feb 18 01:17:24 VYOS pluto[20807]: "peer--tunnel-20" #381:
Quick Mode I1 message is unacceptable because it uses a previously used
Message ID 0x14702d90 (perhaps this is a duplicated packet)
Feb 18 01:17:24 VYOS pluto[20807]: "peer--tunnel-20" #381:
sending encrypted notification INVALID_MESSAGE_ID to :500
Does anyone have any idea what I might be doing wrong? I've tried doing
only 5 tunnels, however then some subnets couldn't reach certain subnets
(as I said in the VyOS forum thread), and now I've tried each subnet to
each subnet.
I can't find much (any) information on it, but does Openswan support VTI
interfaces? Would that solve my problem?
Thanks in advance.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
[CentOS] IPtables block user from outbound ICMP
Hello, Is it possible at all to block all users other than root from sending outbound ICMP packets on an interface? At the moment we have the following two rules in our IPtables config: iptables -A OUTPUT -o eth1 -m owner --uid-owner 0 -j ACCEPT iptables -A OUTPUT -o eth1 -j DROP But this still allows ICMP for some reason (but *does* block other TCP/UDP packets, which is what we want, as well as ICMP). Thanks. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] IPtables block user from outbound ICMP
Thanks all, that seemed to be the problem (the suid bit). :) On 25 February 2016 at 06:03, Valeri Galtsev wrote: > On Wed, February 24, 2016 12:25 pm, Alexander Dalloz wrote: > > Am 24.02.2016 um 16:07 schrieb Sylvain CANOINE: > >> Hello, > >> - Mail original - > >>> De: "John Cenile" > >>> À: "centos" > >>> Envoyé: Mercredi 24 Février 2016 15:42:36 > >>> Objet: [CentOS] IPtables block user from outbound ICMP > >>> Is it possible at all to block all users other than root from sending > outbound ICMP packets on an interface? > >>> At the moment we have the following two rules in our IPtables config: > iptables -A OUTPUT -o eth1 -m owner --uid-owner 0 -j ACCEPT > >>> iptables -A OUTPUT -o eth1 -j DROP > >>> But this still allows ICMP for some reason (but *does* block other > TCP/UDP > >>> packets, which is what we want, as well as ICMP). > >> According to the iptables documentation > >> (http://ipset.netfilter.org/iptables.man.html), not specifying "-p" is > equivalent to specifying "-p all", which matches with all protocols, > icmp included. So these rules are good. BUT... I suppose /bin/ping has > a > >> suid bit set, no ? > >> Sylvain. > >> Pensez ENVIRONNEMENT : n'imprimer que si ncessaire > > > > Blocking the complete ICMP protocol is stupid and should not be > > recommended. > > > > ICMP echo request and echo reply are just 2 types of a bigger set of > necessary ICMP types. It is safe to block those 2 while that does not > really serve a purpose. A system not replying on ICMP echo request does > not hide it from others. > > Indeed. Not replying ping is rather Windows-ish behavior (still standard > Windows behavior out of box. They still must have rather low opinion about > their own programmers I guess and still are scared of [in]famous "ping of > death"). > > If one doesn't trust local users to the extent one doesn't allow them to > send outbound pings, then one has rather large restriction imposing on > users work to do IMHO. I do have some boxes like that, and on these boxes > I indeed have rather restricted set of tools/commands accessible for > users. In addition, users though can build or download stuff, they can not > execute anything of their own. In other words, all places users can write > to are mounted with "nosuid, nosgid, noexec" options, the last one is the > one I mean here (do your own thinking why other two are also there). Once > that is done, you can remove "others" read and execute bits from ping > command (and other commands you don't want the to be able to use). Sending > ping in particular requires opening raw socket, which only root (and group > wheel) can do, that's why ping command has SGID set. But again, with that > level of trust to local users, outbound ping is tiny small thing out of > big list one has to do. I found this too tiresome to maintain this as a > real host, for this reason when I need something like that (awfully > restricted users, still having local access to the system), I just - hm, > somebody hopefully will chime in how to do similar thing on Linux; I'm > doing this on FreeBSD, and I just start separate jail, specifically > configured for users logins and local access to the system (which is not a > system, and which contains only tools I want to give users, the services > of this same host run in different jails, mostly one service per jail). > Hopefully, someone will tell how he/she does similar thing in CentOS. > > Just my $0.02. > > Valeri > > > Valeri Galtsev > Sr System Administrator > Department of Astronomy and Astrophysics > Kavli Institute for Cosmological Physics > University of Chicago > Phone: 773-702-4247 > > > > > > ___ > 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
[CentOS] Yum update issues
Hello all, When running yum update on a few of our servers, we get the following errors: Running Transaction Updating : openssl-1.0.1e-42.el6_7.4.x86_64 1/327 Updating : postgresql-libs-8.4.20-5.el6_7.cloudlinux.x86_64 2/327 Updating : kernel-firmware-2.6.32-673.8.1.lve1.4.3.el6.noarch 3/327 Updating : kmod-lve-1.4-3.1.el6.x86_64 4/327 Installing : kmod-lve-2.6.32-673.8.1.lve1.4.3.el6.x86_64-1.4-3.1.el6.x86_64 5/327 Installing : e1000e-3.3.3-2.el6.noarch 6/327 Installing : kmod-e1000e-2.6.32-673.8.1.lve1.4.3.el6.x86_64.debug-3.3.3-2.el6.x86_64 7/327 Installing : kmod-lve-2.6.32-673.8.1.lve1.4.3.el6.x86_64.debug-1.4-3.1.el6.x86_64 8/327 Installing : kernel-debug-2.6.32-673.8.1.lve1.4.3.el6.x86_64 9/327 Updating : liblve-1.4-1.3.el6.cloudlinux.x86_64 10/327 Updating : lve-1.4-1.3.el6.cloudlinux.x86_64 11/327 Installing : kmod-e1000e-2.6.32-673.8.1.lve1.4.3.el6.x86_64-3.3.3-2.el6.x86_64 12/327 Installing : kernel-2.6.32-673.8.1.lve1.4.3.el6.x86_64 13/327 Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/yum/rpmtrans.py", line 470, in callback self._scriptStop(bytes, total, h); File "/usr/lib/python2.6/site-packages/yum/rpmtrans.py", line 636, in _scriptStop name, txmbr = self._getTxmbr(h) File "/usr/lib/python2.6/site-packages/yum/rpmtrans.py", line 331, in _getTxmbr assert len(txmbrs) == 1 AssertionError error: python callback > failed, aborting! And if I try and run yum update again, I get the following: --> Finished Dependency Resolution Error: cagefs conflicts with liblve-1.3-1.10.el6.cloudlinux.x86_64 You could try using --skip-broken to work around the problem ** Found 8 pre-existing rpmdb problem(s), 'yum check' output follows: kernel-2.6.32-673.8.1.lve1.4.3.el6.x86_64 has missing requires of kmod-ixgbe-2.6.32-673.8.1.lve1.4.3.el6.x86_64 kernel-debug-2.6.32-673.8.1.lve1.4.3.el6.x86_64 has missing requires of kmod-ixgbe-2.6.32-673.8.1.lve1.4.3.el6.x86_64.debug kernel-firmware-2.6.32-673.8.1.lve1.4.3.el6.noarch is a duplicate with kernel-firmware-2.6.32-604.30.3.lve1.3.63.el6.noarch kmod-lve-1.4-3.1.el6.x86_64 is a duplicate with kmod-lve-1.3-11.1.el6.x86_64 liblve-1.4-1.3.el6.cloudlinux.x86_64 is a duplicate with liblve-1.3-1.10.el6.cloudlinux.x86_64 lve-1.4-1.3.el6.cloudlinux.x86_64 is a duplicate with lve-1.3-1.10.el6.cloudlinux.x86_64 openssl-1.0.1e-42.el6_7.4.x86_64 is a duplicate with openssl-1.0.1e-42.el6_7.2.x86_64 postgresql-libs-8.4.20-5.el6_7.cloudlinux.x86_64 is a duplicate with postgresql-libs-8.4.20-4.el6_7.cloudlinux.x86_64 When I check for duplicate packages: *# package-cleanup --dupes* Loaded plugins: fastestmirror, rhnplugin lve-1.4-1.3.el6.cloudlinux.x86_64 lve-1.3-1.10.el6.cloudlinux.x86_64 postgresql-libs-8.4.20-5.el6_7.cloudlinux.x86_64 postgresql-libs-8.4.20-4.el6_7.cloudlinux.x86_64 kmod-lve-1.4-3.1.el6.x86_64 kmod-lve-1.3-11.1.el6.x86_64 liblve-1.4-1.3.el6.cloudlinux.x86_64 liblve-1.3-1.10.el6.cloudlinux.x86_64 openssl-1.0.1e-42.el6_7.4.x86_64 openssl-1.0.1e-42.el6_7.2.x86_64 I then run package-cleanup --cleandupes and get the following: Running Transaction ** Found 3 pre-existing rpmdb problem(s), 'yum check' output follows: kernel-2.6.32-673.8.1.lve1.4.3.el6.x86_64 has missing requires of kmod-ixgbe-2.6.32-673.8.1.lve1.4.3.el6.x86_64 kernel-debug-2.6.32-673.8.1.lve1.4.3.el6.x86_64 has missing requires of kmod-ixgbe-2.6.32-673.8.1.lve1.4.3.el6.x86_64.debug kernel-firmware-2.6.32-673.8.1.lve1.4.3.el6.noarch is a duplicate with kernel-firmware-2.6.32-604.30.3.lve1.3.63.el6.noarch So I then run: yum install kmod-ixgbe-2.6.32-673.8.1.lve1.4.3.el6.x86_64 Only after cleaning the duplicates, and installing kmod-ixgbe, can I *then* run yum update -y, and it succeeds. It's extremely annoying because the above error is preventing cPanel updates from completing nightly (until I do the above), and I would love to know why this is suddenly happening on so many servers, for seemingly no reason. Thanks in advance. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Unable to boot CentOS 6 - Segmentation Erorr
Hi all, I had an issue this morning with one of my virtual machines. It wouldn't boot (into any runlevel), nor could I chroot into the root partition using a rescue disk. Unfortunately I didn't grab a screenshot, however the error(s) when booting were: /pre-pivot/50selinux-loadpolicy.sh: 14 init: readahead main process (425) killed by SEGV signal init: readahead-col lector main process (421) killed by SEGV signal init: rcS pre-start process (425) killed by SEGV signal init: Error while reading from descriptor: Bad file descriptor init: readahead-col lector post-stop process (424) killed by SEGV signal init: rcS post-stop process (427) killed by SEGV signal init: readahead-disable-services main process (428) killed by SEGV signal When using a rescue CD and chrooting into the root partition, I would get : Segmentation Fault: Core Dumped In the end, the fix was to boot into a rescue CD with networking, and SCP the entire contents of /bin and /sbin from another (working) server to the broken installation. This finally allowed CentOS 6 to boot correctly. So I'm left to assume some of the files in /bin *or */sbin were corrupt. My question is, does anyone have any ideas on how this might have happened? I did do a quick memory test using the rescue CD (it didn't complete) and there weren't any errors. The virtual machine is running on VMWare with 3 other VMs, which all seem fine. There wasn't any unexpected power loss either. Thanks. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Unable to boot CentOS 6 - Segmentation Erorr
Also, the last message in /var/log/messages before the crash was: ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@May 29 07:30:10 *hostname* kernel: imklog 5.8.10, log source = /proc/kmsg started Which seems very concerning. On 29 May 2016 at 10:27, John Cenile wrote: > Hi all, > I had an issue this morning with one of my virtual machines. It wouldn't > boot (into any runlevel), nor could I chroot into the root partition using > a rescue disk. > > Unfortunately I didn't grab a screenshot, however the error(s) when > booting were: > > > /pre-pivot/50selinux-loadpolicy.sh: 14 > > > > init: readahead main process (425) killed by SEGV signal > init: readahead-col lector main process (421) killed by SEGV signal > init: rcS pre-start process (425) killed by SEGV signal > init: Error while reading from descriptor: Bad file descriptor > init: readahead-col lector post-stop process (424) killed by SEGV signal > init: rcS post-stop process (427) killed by SEGV signal > init: readahead-disable-services main process (428) killed by SEGV signal > > > When using a rescue CD and chrooting into the root partition, I would get : > > Segmentation Fault: Core Dumped > > > In the end, the fix was to boot into a rescue CD with networking, and SCP > the entire contents of /bin and /sbin from another (working) server to the > broken installation. This finally allowed CentOS 6 to boot correctly. > > So I'm left to assume some of the files in /bin *or */sbin were corrupt. > > My question is, does anyone have any ideas on how this might have > happened? I did do a quick memory test using the rescue CD (it didn't > complete) and there weren't any errors. The virtual machine is running on > VMWare with 3 other VMs, wh
[CentOS] yum --security check-update
Hi all, Does anyone know why when I run the following command, I get thousands of packages in the output, saying they've been excluded? [root@server yum.repos.d]# yum --security check-update | less Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: mirror.removed.com * epel: mirror.removed.com * extras: mirror.removed.com * updates: mirror.removed.com --> libdb-5.3.21-19.el7.i686 from base excluded (updateinfo) --> libcxgb4-static-1.3.5-3.el7.i686 from base excluded (updateinfo) --> libcxgb4-static-1.3.5-3.el7.x86_64 from base excluded (updateinfo) --> libcxgb3-static-1.3.1-8.el7.x86_64 from base excluded (updateinfo) --> libcxgb4-1.3.5-3.el7.x86_64 from base excluded (updateinfo) --> libdaemon-devel-0.14-7.el7.i686 from base excluded (updateinfo) --> libdaemon-devel-0.14-7.el7.x86_64 from base excluded (updateinfo) --> libdaemon-0.14-7.el7.i686 from base excluded (updateinfo) --> telepathy-logger-devel-0.8.0-5.el7.x86_64 from base excluded (updateinfo) --> 1:telepathy-mission-control-5.16.3-3.el7.i686 from base excluded (updateinfo) --> qt5-qtxmlpatterns-5.6.1-10.el7.x86_64 from base excluded (updateinfo) --> qt5-qtxmlpatterns-5.6.1-10.el7.i686 from base excluded (updateinfo) Any other server I run this on *only* outputs the packages that need to be updated? This is a CentOS 7 VM. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
