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

Using curl bash to install local repo is probably not a great idea #102

Closed
WesWWagner opened this issue Jan 10, 2023 · 5 comments
Closed

Comments

@WesWWagner
Copy link
Contributor

Currently we are downloading and setting up a local repo on the servers using a curl script and then doing a rpk yum etc from local repo.

This should likely be changed to use our public repos appropriately with the correct tool with an explicit version flag, and related variable.

Current code:

- name: add the redpanda repo
  shell: |
    curl -1sLf {{ redpanda_repo_script }} | sudo -E bash
  args:
    warn: no
@patrickangeles
Copy link
Contributor

What's the drawback? It's pretty common in large orgs, esp. in air gapped environments, to rely on a local repo...

@hcoyote
Copy link
Contributor

hcoyote commented Jan 26, 2023

First, curl | sudo bash is a devops antipattern. It's not really considered idempotent and you can't rely upon it to converge to a known good state that's easily tested for. It's more of a hack to get developers up and running and not really meant to be used in automation.

I looked through the repo setup script that we provide and it really only does a handful of things that we could stuff into the ansible directly. It's not actually downloading and building a repo, it's only configuring the package handler to be aware of our repos.

For rpm-based installs it basically does:

  1. setup the repo location: curl -1sLf 'https://dl.redpanda.com/nzc4ZYQK3WRGd9sy/redpanda/config.rpm.txt?distro=centos&codename=Core&version=7&arch=x86_64' > redpanda-centos-el7-x86_64.repo
  2. add our gpg key to trust the packages: rpm --import https://dl.redpanda.com/nzc4ZYQK3WRGd9sy/redpanda/gpg.988A7B0A4918BC85.key

It does something similar for deb-based ones.

@gene-redpanda
Copy link
Contributor

This is largely resolved. The sole exception is the download and dearmoring of a key

- name: Download and import Redpanda GPG Key
  shell: |
    curl -1sLf "{{ rp_key_deb_actual }}" | gpg --dearmor > "{{ rp_key_path_deb_actual }}"
  when: ansible_os_family == 'Debian'

I haven't found a good workaround to this method yet.

@hcoyote
Copy link
Contributor

hcoyote commented Jun 13, 2023

This is largely resolved. The sole exception is the download and dearmoring of a key

- name: Download and import Redpanda GPG Key
  shell: |
    curl -1sLf "{{ rp_key_deb_actual }}" | gpg --dearmor > "{{ rp_key_path_deb_actual }}"
  when: ansible_os_family == 'Debian'

I haven't found a good workaround to this method yet.

you can try to predicate this on the existence of the file at rp_key_path_deb_actual. If that path exists, there's probably no reason for this task to re-run on subsequent runs. We're highly unlikely to ever change the GPG key.

@gene-redpanda
Copy link
Contributor

Resolved with the recent updates to redpanda-ansible-collection

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

No branches or pull requests

4 participants