Глобальное изменение $ PATH в Ansible не работает должным образом от обычной оболочки Linux - PullRequest
1 голос
/ 16 марта 2019

Я хочу загрузить некоторые двоичные файлы, такие как Helm и сделать их доступными для всех, используя $PATH.Чтобы избежать загрузки с правами суперпользователя или, в качестве альтернативы, выполнять шаги (скачать с обычным пользователем и перейти в какую-либо папку bin в $PATH, например /usr/local/bin), моя идея состояла в том, чтобы создать $HOME/bin и добавить его в $PATH. * 1008.*

Эта статья блога была использована для добавления пользовательского пути к /etc/environment.Затем я перезагружаю его как , описанное здесь .Это моя POC playbook, где я пытаюсь добавить exa :

- name: Test
  hosts: all

  vars:
    - bin: /home/vagrant/bin

  tasks:
  - name: Test task
    file:
      path: "{{bin}}"
      state: directory

  - name: Add {{bin}} to path
    become: yes
    lineinfile: >
        dest=/etc/environment
        state=present
        backrefs=yes
        regexp='PATH=(["]*)((?!.*?{{bin}}).*?)(["]*)$'
        line="PATH=\1\2:{{bin}}\3"

  - name: Check path1
    shell: echo $PATH

  - name: Download exa
    unarchive:
      src: https://github.com/ogham/exa/releases/download/v0.8.0/exa-linux-x86_64-0.8.0.zip
      dest: "{{bin}}"
      remote_src: yes

  - name: reload env file
    shell: for env in $( cat /etc/environment ); do export $(echo $env | sed -e 's/"//g'); done

  - name: Check path after reload env file
    shell: echo $PATH

  - name: Test exa from PATH
    shell: exa-linux-x86_64 --version

В последнем таше Test exa from PATH выдает ошибку:

"stderr":" / bin / sh: 1: exa-linux-x86_64: не найдено "

Команды echo $PATH остаются обе на

" stdout ":"/ usr / local / sbin: / usr / local / bin: / usr / sbin: / usr / bin: / sbin: / bin: / usr / games: / usr / local / games "

Но модифицированный /etc/environment работает.Когда я захожу на ssh на машине без ansible, $PATH в порядке, а также exa-linux-x86_64 --version работает:

~$ echo $PATH
/home/vagrant/bin:/home/vagrant/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/vagrant/bin:/snap/bin

Environment

Хост-система Ubuntu 18.04, на которой работает Vagrant с Ubuntu 16.04 box,Ansible был казнен Вагрантом в Ubuntu 16.04.

Возможные обходные пути

Использование отдельной переменной env

При установке такой переменной среды

  - name: Test exa from PATH
    shell: exa-linux-x86_64 --version
    environment:
      PATH: "{{ ansible_env.PATH }}:{{bin}}"

это работает.Но я должен применить эти линии по крайней мере на игровом уровне.Я хотел бы установить его глобально, как /etc/environment в обычных оболочках. Этот вопрос , похоже, имеет ту же цель, но на Solaris.Автоответчик, кажется, только устанавливает $PATH с хоста, что для меня бесполезно, поскольку там нет пользовательского каталога bin.

Использовать только абсолютные пути

  - name: Test exa from PATH
    shell: "{{bin}}/exa-linux-x86_64 --version"

Это приводит к меньшим накладным расходам, но вы должны помнить, что перед командами всегда следует указывать переменную пути.Кажется также подверженным ошибкам

Понимание проблемы

Я хочу найти реальное решение и понять, что является причиной проблемы.Мне непонятно, почему модификация $PATH так сложна для Ansible, где это можно сделать довольно просто в лежащей в основе системе linux. В этом вопросе говорится, что у нас нет интерактивного сеанса в ansible.Кажется, нет $PATH доступных.Согласно документации , мы можем заархивировать это, передав -l bash.Поэтому я обнаружил, что работает следующее:

  - name: Test exa from PATH
    shell: bash -l -c "exa-linux-x86_64 --version"

Но следующий результат приводит к ошибке:

  - name: Test exa from PATH
    shell: exa-linux-x86_64 --version
    args:
      executable: /bin/bash -l

Здесь Ansible прерывает команду с неверным цитированием аргументов:

"'/ bin / bash -l' -c 'exa-linux-x86_64 --version'"

Этот билет рекомендует команде Ansible это исправить, так что мы получаем оболочку входа с $PATH.С 2014 года никакого реального решения не было предоставлено вообще.

Вопросы

  1. Для чего предназначены разные типы оболочек, которые получают доступ к измененному $PATH или нет?
  2. Почему Ansible все усложняет?Разве не было бы проще обеспечить оболочку входа в систему, которая решит эту проблему?Есть ли причины, по которым они сделали то, что сделали?
  3. Как мы можем справиться с возникающими проблемами?Что такое лучшая практика?

1 Ответ

0 голосов
/ 16 марта 2019

Чтобы ответить на ваши вопросы

1) Для чего предназначены разные типы оболочек, которые получают доступ к измененному $ PATH или нет?

Не стоит прилагать усилия для его унификации во всех операционных системах, поддерживаемых Ansible. Это также объясняет: «Мне непонятно, почему модификация $ PATH так трудна для Ansible, где это можно сделать довольно просто в лежащей в основе системе linux».

2) Почему Ansible все усложняет? Разве не было бы проще обеспечить оболочку входа в систему, которая решит эту проблему? Есть ли причины, по которым они сделали то, что сделали?

Наоборот, легче не заботиться об этом. Проще говоря, глупая причина.

3) Как мы можем справиться с возникающими проблемами? Что такое лучшая практика?

Лучшие практики за десятилетия были Инструменты, без политики

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...