PAYG system is reported as NOT PAYG when added for PAYG connection in SUSE Manager Server

This document (000021348) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Manager 4.3 Server

Situation

Adding a PAYG connection to the SUSE Manager Server failed with a message:

Error getting instance data: instance is not PAYG

Running the `instance-flavor-check` script manually on top of the cloud system using SUDO resulted in following error:

user@hostname:/> sudo /usr/bin/instance-flavor-check
Traceback (most recent call last):
  File "/usr/bin/instance-flavor-check", line 30, in <module>
    check_payg_byos()
  File "/usr/lib/python3.6/site-packages/instance_billing_flavor_check/utils.py", line 192, in check_payg_byos
    metadata = get_metadata()
  File "/usr/lib/python3.6/site-packages/instance_billing_flavor_check/utils.py", line 69, in get_metadata
    result = Command.run(command)
  File "/usr/lib/python3.6/site-packages/instance_billing_flavor_check/command.py", line 67, in run
    command[0], error.decode(), output.decode()
Exception: /usr/bin/ec2metadata: stderr: Unable to retrieve metadata token
, stdout: (no output on stdout)

Running the `instance-flavor-check` script as root worked correctly and the cloud system was then reported as PAYG. `strace` of the ec2metadata showed that the cloud system could not reach the following IP address when the ec2metadata was ran using sudo:

sendto(3, "PUT http://169.254.169.254/lates"..., 220, 0, NULL, 0) = 220
recvfrom(3, "HTTP/1.1 503 Service Unavailable"..., 8192, 0, NULL, NULL) = 1227
write(2, "Unable to retrieve metadata toke"..., 34) = 34

Resolution

Either disable the http_proxy and https_proxy environment variables on the cloud machine or add the IP address of the metadata server which can not be reached to the no_proxy variable.

Cause

Proxy environment variables were set on the cloud machine which, in this case, disabled proper communication with the metadata server when used with sudo.

Additional Information

In this particular case it was not obvious that the proxy variables were set on the cloud system as the proxy was not been enabled in `/etc/sysconfig/proxy`. Running a curl command against the IP of the metadata server:

sudo curl 169.254.169.254/latest

showed a connection timeout:

A communication error occurred: "Operation timed out"

and debug sudo logs displayed that the proxy is used when the cloud machine communicates to the "outside" world:

Jan 31 11:33:11 sudo[24529] exec /usr/bin/curl [curl whatever-ip] [LANG=POSIX COLORTERM=1 LC_CTYPE=C.UTF-8 TERM=xterm MAIL=/var/mail/root PATH=/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/bin:/usr/local/sbin LOGNAME=root USER=root HOME=/root SHELL=/bin/bash SUDO_COMMAND=/usr/bin/curl whatever-ip SUDO_USER=root SUDO_UID=0 SUDO_GID=0 http_proxy=http://someproxyhostname.com:8080 https_proxy=http://someproxyhostname:8080 no_proxy=some.address]

It was determined that the proxy variables were set in the `/etc/environment` file on the cloud machine.

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.