Может ли "cap deploy: setup" уничтожить BASH? - PullRequest
1 голос
/ 07 февраля 2011

Сегодня утром у меня возникла проблема с развертыванием приложения на capistrano.

# git push
# cap deploy:setup

Произошло что-то странное, и я больше не смог подключиться к ssh.

Технический персонал говорит(на итальянском языке): «команды, которые вы выполнили, перезаписали двоичные файлы оболочки, из-за чего система перестала работать».Два варианта: я тупой или они не правы.Вот вывод оболочки на cap: deploy и затем ошибка на ssh.Как только система (VPS) была перезагружена, я больше не мог ssh.

Есть идеи?

mattia@desktop:/var/www/rails/my_application$ git push
Counting objects: 239, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (191/191), done.
Writing objects: 100% (202/202), 379.77 KiB, done.
Total 202 (delta 44), reused 0 (delta 0)
To ssh://mattia@my_application.it/~/git/my_application.git
   96c1f19..3cc9e1c  master -> master
mattia@desktop:/var/www/rails/my_application$ cap deploy:setup
  * executing `deploy:setup'
  * executing "mkdir -p /var/www/rails/my_application /var/www/rails/my_application/releases /var/www/rails/my_application/shared /var/www/rails/my_application/shared/system /var/www/rails/my_application/shared/log /var/www/rails/my_application/shared/pids &&  chmod g+w /var/www/rails/my_application /var/www/rails/my_application/releases /var/www/rails/my_application/shared /var/www/rails/my_application/shared/system /var/www/rails/my_application/shared/log /var/www/rails/my_application/shared/pids"
    servers: ["beta.my_application.it"]
    [beta.my_application.it] executing command
 ** [out :: beta.my_application.it]
 ** [out :: beta.my_application.it] malloc: ../bash/parse.y:2823: assertion botched
 ** [out :: beta.my_application.it] nunits < 30
 ** [out :: beta.my_application.it] Aborting...
    command finished
failed: "env PATH=/usr/local/bin:/usr/bin:/bin GEM_PATH=/var/lib/gems/1.9.1 sh -c 'mkdir -p /var/www/rails/my_application /var/www/rails/my_application/releases /var/www/rails/my_application/shared /var/www/rails/my_application/shared/system /var/www/rails/my_application/shared/log /var/www/rails/my_application/shared/pids &&  chmod g+w /var/www/rails/my_application /var/www/rails/my_application/releases /var/www/rails/my_application/shared /var/www/rails/my_application/shared/system /var/www/rails/my_application/shared/log /var/www/rails/my_application/shared/pids'" on beta.my_application.it
mattia@desktop:/var/www/rails/my_application$ ssh beta.my_application.it
Linux my_application 2.6.18-194.26.1.el5.028stab079.2ent #1 SMP Fri Dec 17 19:44:51 MSK 2010 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Feb  7 12:00:53 2011 from dynamic-adsl-xx-xx-xx-xx.------.------.it

malloc: ../bash/subst.c:4494: assertion botched
realloc: called with unallocated block argument
Aborting...Connection to beta.my_application.it closed.

1 Ответ

2 голосов
/ 08 февраля 2011

Короткий ответ - нет, если у вас нет других нестандартных плагинов или кто-то дал вам испорченный Gem.(Практически никто не утруждает себя проверять подписи гемов.) Стандартное развертывание: установка создает только пару символических ссылок и каталогов.

Он работает как root, и теоретически, если бы вы устанавливали свои переменныедля значений (не проверенных), таких как set :deploy_to, '/bin/bash', он может повредить двоичный файл, но если вы этого не сделаете, я бы сказал, что это не проблема.

Вы можете отладить это,не полагаясь на оболочку - используя SSH в командном режиме:

# ssh myuser@myserver -c 'history'

, который будет выгружать файл истории (bash) этого пользователя, чтобы вы могли проверить, не было ли какого-либо вмешательства на сервере, вытакже можете проверить его как root и / или запустить команды, такие как who, last и другие однострочные, которые возвращают вам журналы (вы также можете cat /var/log/messages и искать подозрительные действия.

Я бы сказал, что вероятность того, что Capistrano будет нести ответственность за это, равна 0 (Источник: я сопровождающий.) - но вы, вероятно, можете вернуть свою систему в рабочее состояние, используя командный режим SHS, как я упоминал выше (ssh myuser@myserver -c 'aptitude install bash --force' например)

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

Это также очень поможетваши администраторы, если они могут дать вам /bin/bash - содержимое файла, чтобы вы могли видеть, является ли он текстом, мусором, поврежденным двоичным файлом или чем-то из вашего развертывания.

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