Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XO deploy script with http proxy #7528

Closed
kevemueller opened this issue Apr 2, 2024 · 6 comments
Closed

XO deploy script with http proxy #7528

kevemueller opened this issue Apr 2, 2024 · 6 comments
Assignees

Comments

@kevemueller
Copy link

Are you using XOA or XO from the sources?

XOA

Which release channel?

stable

Provide your commit number

No response

Describe the bug

In an environment with no direct http access (only via proxy), after a fresh installation of xcp-ng, the xoa deployment fails.
The XCP-ng environment is minimally altered:

  • added proxy environment variables to /etc/environment
  • added EnvironmentFile=/etc/environment in /usr/lib/systemd/system/xapi.service
  • restarted everything.
  • verified that environment is properly set-up on the xapi process

Command line tools yum, wget, curl work well with the proxy.

  • "Quick Deploy" from xapi dashboard, fails with "INTERNAL_ERROR", Unix.ECONNREFUSED

  • bash -c "$(wget -qO- https://xoa.io/deploy)" fails with

Importing XOA VM...
The server failed to handle your request, due to an internal error. The given message may give details useful for debugging the problem.
message: Unix.Unix_error(Unix.ECONNREFUSED, "connect", "")

I have not found the script source to post a patch against.

Error message

No response

To reproduce

Connect to the XCP-ng host and run
bash -c "$(wget -qO- https://xoa.io/deploy)
The process fails after downloading the deployment script.

Expected behavior

The deployment script should import the appliance.

There is a coding logic error in the script. It is run with set -e (fail after first error), which is good practice, but it is not prepared to gracefully catch the xe vm-import. The subsequent fallback code is never executed, as set -e bails the execution.

a possible workaround is

# Downloading and importing the VM

printf "Importing XOA VM...\n"
uuid=$(xe vm-import url="$XOA_URL" || echo failed)

# If it fails (it means XS < 7.0)
# We'll use the curl
if [ $uuid = "failed" ]
then
  uuid=$(curl "$XOA_URL" | xe vm-import filename=/dev/stdin 2>&1 || echo failed)
fi

# If it fails again (for any reason), we stop the script
if [ $uuid = "failed" ]
then
  printf "\n\nAuto deploy failed. Please contact us on xen-orchestra.com live chat for assistance.\nError:\n\n %s\n\n" "$uuid"
  exit 1
fi

With this script XO can be sucessfully deployed behind a http proxy.

Screenshots

No response

Node

?

Hypervisor

XCP-ng 8.2.1

Additional context

No response

@olivierlambert
Copy link
Member

First, ping @stormi because I'm not even sure about the proxy modification in XCP-ng in the first place.

@olivierlambert
Copy link
Member

And ping @julien-f about the import script

@olivierlambert
Copy link
Member

And finally thank you @kevemueller for the report 😉

@julien-f julien-f self-assigned this Apr 3, 2024
@kevemueller
Copy link
Author

Short update on the change for xapi.service. Looking at the OCaml code, the standard proxy environment variables are not honoured, the code is not prepared to fetch via a proxy. This change is hence ineffective and not required.

There is no need to restart anything, changes to the enviroment are effective after re-logon or sourcing of /etc/environment.
For the purpose of replication of the bug, permanently changing the environment is also not necessary, just setting http_proxy/https_proxy in the current shell suffices.

What remains is the bug in https://xoa.io/deploy:

# Downloading and importing the VM

printf "Importing XOA VM...\n"
uuid=$(xe vm-import url="$XOA_URL")

As the URL cannot be reached by xapi the xe vm-import fails, and the script terminates. As described above the error handling in the code is not efficient, there is no point in looking at $? if set -e is effective.
A fix like above is necessary for the intended behaviour of deploying via cURL.

I have not found a repository with the deploy script, so @julien-f I suggest this is only you who can change it. If you are not happy with the suggested fix above, anything that catches the error condition of xe vm-import gracefully will be just fine, as the code below it will work.
Attached a patch that is verified to work.
deploy-error.patch

@olivierlambert
Copy link
Member

Re-ping @julien-f

@julien-f
Copy link
Member

@kevemueller I have deployed a new version of the script that should correctly handle the fallback.

That would be great if you could test it :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants