Unable to Deauthorize Host - Package(s) Fail to be Erased (Apt)

Problem

• Deauthorizing a host or hypervisor fails (such as via the UI).

• In /var/log/pf9/hostagent.log on the host which fails to be deauthorized, it is observed that one or more PF9 packages fail to be removed or erased.

None

209 - pf9_app.py INFO - Removing pf9-neutron-base.3.6.0-1092304 - pf9_app.py INFO - Setting the desired service state353 - pf9_app_db.py ERROR - Erase command failed : sudo /opt/pf9/hostagent/bin/pf9-apt erase pf9-neutron-base. Return code: 1, stdout: , stderr: Traceback (most recent call last)

• Additionally, connection failures such as the following are also observed – indicating one or more repositories are unreachable.

None

apt.cache.FetchFailedException: W:Failed to fetch http://platform9-neutron.s3-website-us-west-1.amazonaws.com/ubuntu/Release.gpg Connection failed , W:Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/trusty/Release.gpg Connection failed [IP: 91.189.91.23 80] , W:Failed to fetch http://platform9-neutron.s3-website-us-west-1.amazonaws.com/ubuntu/en Connection failed , W:Failed to fetch http://platform9-neutron.s3-website-us-west-1.amazonaws.com/ubuntu/Packages Connection failed , W:Failed to fetch http://security.ubuntu.com/ubuntu/dists/trusty-security/Release.gpg Connection failed [IP: 91.189.88.162 80]

Environment

• Platform9 Managed OpenStack - All Versions

• Ubuntu

• Apt

Cause

As part of the package erasure process, the apt-cache is updated prior to marking a package for removal – to be purged from the system. As such, this requires that the configured Apt repositories be reachable via TCP port(s) 80/443. A firewall or network misconfiguration may be preventing communication to these external repositories.

Resolution

1. Allow communication to either or both of the aforementioned ports – 80 and 443 – dependent on which protocol is used by the configured repositories. This may be accomplished in many different ways, including leveraging an HTTP(s) proxy or apt-proxy host within your internal infrastructure (especially if the hosts do not normally have outside connectivity, except to the Platform9 management plane via 443).

2. Attempt the host de-authorization once more.