Issue with updating NNA...again

[snapon_admin]

For some reason I have issues updating my NNA server every single time I do it. The first time I had an issue, all I did was enable and disable proxy settings. This essentially made no change since the proxy was originally disabled and the upgrade worked when the proxy was enabled and then re-disabled. The second time I had this issue I tried a plethora of fixes (linked in the thread below) and one random command allowed this to work. This time, I have tried everything from the previous thread, as well as tried running this with and without a proxy and I am still getting the same errors.

Previous thread: https://support.nagios.com/forum/viewto ... ilit=proxy

Current issue:

Code: Select all

[root@lisl-ngna-01-pv nagiosna]# ./upgrade
Loaded plugins: fastestmirror
Setting up Install Process
Loading mirror speeds from cached hostfile
Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=os error was
14: PYCURL ERROR 7 - "Failed to connect to 2607:f8f8:700:12::10: Network is unreachable"
Error: Cannot find a valid baseurl for repo: base

Notable changes to environment since last thread:
CentOS is version 6.7
NNA current version is 2.2.0
Proxy server was changed from McAfee to Webroot
NNA server is currently NOT configured to traverse our proxy (in the previous thread there was a change made where this server was routed through the proxy, that change was undone some time ago and this server no longer requires a proxy server to connect to the internet)

[tgriep]

Can you post the following files from the NNA server you are trying to upgrade?

Code: Select all

/etc/yum.conf
/etc/yum.repos.d/CentOS-Base.repo

Then run the following as root to check network connectivity to the Centos mirrorlist server. Post the output here.

Code: Select all

ping mirrorlist.centos.org -c 5
nslookup mirrorlist.centos.org

Since the requirements of the proxy server are no longer needed, make sure the settings were removed from this file /etc/yum.conf.
Also, clear the yum cache by running the following command. After running this, try the upgrade.

Code: Select all

yum clean all

[snapon_admin]

/etc/yum.conf

Code: Select all

[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=5
bugtracker_url=http://bugs.centos.org/set_project.php?project_id=16&ref=http://bugs.centos.org/bug_report_page.php?category=yum
distroverpkg=centos-release
#proxy=http://iproxy.snapon.com:8080
#proxy=http://snapon.com.web01.mxlogic.net:8080
#proxy=http://iproxyweb03.snapon.com:8080
#  This is the default, if you make this bigger yum won't see if the metadata
# is newer on the remote and so you'll "gain" the bandwidth of not having to
# download the new metadata and "pay" for it by yum not having correct
# information.
#  It is esp. important, to have correct metadata, for distributions like
# Fedora which don't keep old packages around. If you don't like this checking
# interupting your command line usage, it's much better to have something
# manually check the metadata once an hour (yum-updatesd will do this).
# metadata_expire=90m

# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d

/etc/yum.repos.d/CentOS-Base.repo

Code: Select all

# CentOS-Base.repo
#
# The mirror system uses the connecting IP address of the client and the
# update status of each mirror to pick mirrors that are updated to and
# geographically close to the client.  You should use this for CentOS updates
# unless you are manually picking other mirrors.
#
# If the mirrorlist= does not work for you, as a fall back you can try the
# remarked out baseurl= line instead.
#
#

[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

#released updates
[updates]
name=CentOS-$releasever - Updates
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6

#additional packages that may be useful
[extras]
name=CentOS-$releasever - Extras
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras
#baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6

#additional packages that extend functionality of existing packages
[centosplus]
name=CentOS-$releasever - Plus
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus
#baseurl=http://mirror.centos.org/centos/$releasever/centosplus/$basearch/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6

#contrib - packages by Centos Users
[contrib]
name=CentOS-$releasever - Contrib
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=contrib
#baseurl=http://mirror.centos.org/centos/$releasever/contrib/$basearch/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6

Cannot ping the mirrorlist site, and the IP its resolving to seems to be different than the one I get when I ping from my PC.

Code: Select all

[root@lisl-ngna-01-pv nagiosna]# ping mirrorlist.centos.org -c 5
PING mirrorlist.centos.org (67.219.148.138) 56(84) bytes of data.

--- mirrorlist.centos.org ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 13999ms

From my PC the IP I get is 85.236.43.108. Already tried 'yum clean all' with no luck.

[tgriep]

I would check the DNS settings in the /etc/resolv.conf file is setup correctly.
Try checking to see if the system can access Google's DNS server by running the following.

Code: Select all

ping 8.8.8.8 -c 5
traceroute 8.8.8.8

[eloyd]

I'm guessing that the whole point of having a proxy_server requirement is that there's no direct connection to the Internet? Which means /etc/resolv.conf won't matter. Nor will ping checks.

[snapon_admin]

/etc/resolv settings are correct and I can't ping the google DNS server, but I have never been able to ping any external site from this server so that's nothing new.

/etc/resolv.conf:

Code: Select all

; generated by /sbin/dhclient-script
search localdomain
domain SSG5-Serial
search SSG5-Serial
nameserver 10.245.70.12
nameserver 10.245.128.4
nameserver 10.245.128.38
nameserver 68.87.77.130

[tgriep]

Well, if you cannot connect to an external site, then the upgrade will never work as the NNA upgrade needs a connection to the internet for the updates it needs.

[snapon_admin]

I didn't say couldn't connect, I said couldn't ping. Even when updates have worked on this server, which they have before, I still cannot ping those IPs.

[eloyd]

I'll bet a lambic that it's proxy-related, maybe transparent proxy on your network?

[snapon_admin]

The last 2 times I've run updates on the NNA server I have not used a proxy. Our firewalls are configured in such a way that this server bypasses the proxy and goes straight out to the internet. There is an ACL in place to prevent unwanted traffic from hitting it, but I have added several IPs to that ACL so that this server can connect to the addresses it needs to. Digging through our ASA logs, I don't see any mentions of the NNA server and this ACL. It certainly looks like it'd be a proxy issue, but if it is then I cannot explain why this doesn't work with a proxy nor without one. Also, the errors are completely different when a proxy is used than when a proxy is not used.

Without proxy:

Code: Select all

14: PYCURL ERROR 7 - "Failed to connect to 2001:4178:5:200::10: Network is unreachable"

With proxy:

Code: Select all

14: PYCURL ERROR 7 - "couldn't connect to host"

Without proxy looks like a resolution issue, possibly related to IPv6 (which is disabled in every way I know how to disable it so that makes even less sense), and the with proxy error looks like it can't connect at all, which is to be expected if this connection isn't meant to traverse the proxy.