5

Я написал это задание для запуска процесса на удаленном бродячем блоке. (На самом деле сам ANSIBLE файл намного длиннее, но это средство воспроизведения, которое запускает только стартовый скрипт.)

---
- hosts: myappname_server
  vars_files:
    - install_myappname_vars.yaml
  gather_facts: false
  sudo: true
  sudo_user: "{{ project_name }}"

  tasks:
  - name: Restart application
    command: "{{ project_target_dir_env }}/run"
    args:
      chdir: "{{ project_target_dir_env }}"

Он работает с этими переменными во включенном файле:

---
project_name: myappname
project_source_dir_files: files/myappname
project_source_dir_env: "{{ project_source_dir_files }}/environment_files"
project_target_root: /home/myappname
project_target_dir_env: "{{ project_target_root }}/bin"

Идея состоит в том, чтобы использовать пользователя "myappname" в удаленном окне (с псевдонимом "myappname_server", другие игры, с которыми я работаю, работает нормально) для запуска «/home/myappname/bin/run» после изменения каталога на «/ главная /myappname/ бен». Если я делаю это вручную, все работает нормально, то есть каталоги существуют, файлы читаются, скрипт работает и т.д., Все отлично. Но если я выполню сценарий, что-то не так с генерацией ответного кода выполнения. Это я и мой конфиг на это надеемся)? Это ответственно?

Я запустил его с -vvvv, чтобы получить много информации:

monsterkill@monsterkill-ub-dt:~/playbooks$ ansible-playbook install_myappname_restart.yaml -vvvv

PLAY [myappname_server] ********************************************************** 

TASK: [Restart application] *************************************************** 
<vagrant1> ESTABLISH CONNECTION FOR USER: vagrant
<vagrant1> REMOTE_MODULE command chdir=/home/myappname/bin /home/myappname/bin/run
<vagrant1> EXEC ['ssh', '-C', '-tt', '-vvv', '-o', 'ControlMaster=auto', '-o', 'ControlPersist=60s', '-o', 'ControlPath=/home/monsterkill/.ansible/cp/ansible-ssh-%h-%p-%r', '-o', 'Port=22', '-o', 'IdentityFile=/home/monsterkill/insecure_private_key', '-o', 'KbdInteractiveAuthentication=no', '-o', 'PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey', '-o', 'PasswordAuthentication=no', '-o', 'User=vagrant', '-o', 'ConnectTimeout=10', 'vagrant1', "/bin/sh -c 'mkdir -p /tmp/ansible-tmp-1422343063.07-259463565013754 && chmod a+rx /tmp/ansible-tmp-1422343063.07-259463565013754 && echo /tmp/ansible-tmp-1422343063.07-259463565013754'"]
<vagrant1> PUT /tmp/tmpBduhE7 TO /tmp/ansible-tmp-1422343063.07-259463565013754/command
<vagrant1> EXEC ['ssh', '-C', '-tt', '-vvv', '-o', 'ControlMaster=auto', '-o', 'ControlPersist=60s', '-o', 'ControlPath=/home/monsterkill/.ansible/cp/ansible-ssh-%h-%p-%r', '-o', 'Port=22', '-o', 'IdentityFile=/home/monsterkill/insecure_private_key', '-o', 'KbdInteractiveAuthentication=no', '-o', 'PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey', '-o', 'PasswordAuthentication=no', '-o', 'User=vagrant', '-o', 'ConnectTimeout=10', 'vagrant1', "/bin/sh -c 'chmod a+r /tmp/ansible-tmp-1422343063.07-259463565013754/command'"]
<vagrant1> EXEC ['ssh', '-C', '-tt', '-vvv', '-o', 'ControlMaster=auto', '-o', 'ControlPersist=60s', '-o', 'ControlPath=/home/monsterkill/.ansible/cp/ansible-ssh-%h-%p-%r', '-o', 'Port=22', '-o', 'IdentityFile=/home/monsterkill/insecure_private_key', '-o', 'KbdInteractiveAuthentication=no', '-o', 'PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey', '-o', 'PasswordAuthentication=no', '-o', 'User=vagrant', '-o', 'ConnectTimeout=10', 'vagrant1', u'/bin/sh -c \'sudo -k && sudo -H -S -p "[sudo via ansible, key=ucmsbsauynfzeeyxwdmgfduwovdneeqg] password: " -u myappname /bin/sh -c \'"\'"\'echo SUDO-SUCCESS-ucmsbsauynfzeeyxwdmgfduwovdneeqg; /usr/bin/python /tmp/ansible-tmp-1422343063.07-259463565013754/command\'"\'"\'\'']
<vagrant1> EXEC ['ssh', '-C', '-tt', '-vvv', '-o', 'ControlMaster=auto', '-o', 'ControlPersist=60s', '-o', 'ControlPath=/home/monsterkill/.ansible/cp/ansible-ssh-%h-%p-%r', '-o', 'Port=22', '-o', 'IdentityFile=/home/monsterkill/insecure_private_key', '-o', 'KbdInteractiveAuthentication=no', '-o', 'PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey', '-o', 'PasswordAuthentication=no', '-o', 'User=vagrant', '-o', 'ConnectTimeout=10', 'vagrant1', "/bin/sh -c 'rm -rf /tmp/ansible-tmp-1422343063.07-259463565013754/ >/dev/null 2>&1'"]
failed: [vagrant1] => {"cmd": ["/home/myappname/bin/run"], "failed": true, "rc": 8}
msg: [Errno 8] Exec format error

FATAL: all hosts have already failed -- aborting

PLAY RECAP ******************************************************************** 
           to retry, use: --limit @/home/monsterkill/install_myappname_restart.yaml.retry

vagrant1                   : ok=0    changed=0    unreachable=0    failed=1   

Я пробовал такие вещи, как:

  • играть с косой чертой после каталога
  • использование с относительными и абсолютными путями на удаленной машине
  • работать с и без sudo и sudo_user в моих задачах

Я знаю, что все другие ANSI-модули, которые я использую с той же кучей переменных из некоторых соседних сборников, работают нормально. Также встроенные вещи, такие как группа, пользователь, файл, apt, unarchive, copy. Обратите внимание, что некоторые из них также требуют корректной работы группы / пользователя, так что я знаю, что это тоже хорошо.

/edit: Я также знаю, что путь к сценарию запуска указан правильно, потому что, если я переименую сценарий запуска и запусту книгу воспроизведения, я получу еще одну ошибку («msg: [Errno 2] Нет такого файла или каталога», как и ожидалось), Так что на самом деле он пытается запустить существующий скрипт запуска, но не удается.

Но ничего не работает. Что происходит, что не так с этим последним сгенерированным материалом EXEC? Спасибо за ваше время.

3 ответа3

7

Если вы пытаетесь запустить скрипт оболочки, проверьте:

  • То, что это не пропускает линию Шебанга наверху как:

    #!/usr/bin/env bash
    
  • То, что пользователь ansible будет работать, поскольку имеет для него разрешения на выполнение (например, режим 0755)
0

В общем, «ошибка формата exec» в ansible может означать:

  • программа, которую вы дали выполнить, буквально не является исполняемой.
  • ansible нашел файл, помеченный как исполняемый файл, который на самом деле не является исполняемым, и попытался выполнить его.

Другими словами: это почти всегда означает, что права доступа являются неверными, но это может происходить в обоих направлениях (файлы с недостаточным или избыточным доступом могут по-разному вызывать ошибки exec).

Лично я обнаружил, что я получаю такую ошибку, когда я делаю что-то вроде "chmod 777 /etc /ansible /fact /.." в определенных каталогах и так далее.

0

"Ошибка формата exec" означает просто, что вы пытались выполнить файл, который ядро не распознает как допустимую программу - он находится в неподходящем формате. В этом случае это относится к rm на целевом сервере.

Ssh прямо на сервер и убедитесь, что rm работает; используйте file $(which rm) чтобы проверить его формат (сравните с другими инструментами, такими как mkdir). Сделайте то же самое с /usr/bin/python всякий случай. Возможно, оно было скопировано из другой системы архитектуры, или из другой ОС, или полностью заполнено мусором.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .