mikhailnk Apr 5 2017 at 16:55

Восстановление remote сервера после удаления части ОС

4 min

9.9K

System administration*Server Administration*

From sandbox

+15

Comments 27

PinGniX Apr 5 2017 at 18:26

Не совсем понятно как Вы запустили telnet если он хранится как раз в /usr/bin, который был удален:

$ whereis telnet
telnet: /usr/bin/telnet

mikhailnk Apr 5 2017 at 21:13

Ситуация — частный случай, telnet, busybox и еще пару утилит работали (проверяли методом перебора, rsync удаляет не сразу все). В основном были удалены библиотеки, что приводило к ошибке вида:

XXX: error while loading shared libraries: libXXXX.so: cannot open shared object file: No such file or directory

ValdikSS Apr 8 2017 at 13:56

Так у вас же busybox был. Наверняка в busybox был wget, даже если ваш busybox был неполноценным. Далее качаем полноценный статический busybox с сайта и делаем все в нем.

mikhailnk Apr 8 2017 at 18:14

да, busybox был зависимостью от kexec/kdump, что было работоспособно внутри сейчас сказать не могу, но думаю, что тоже вариант.

mikhailnk Apr 5 2017 at 21:58

подсказка коллеги — тоже тем же способом был передан. т.е. сконвертировали в txt, но копировали через буфер обмена и терминал. Всего-то 140кб.

UFO just landed and posted this here

Evengard Apr 5 2017 at 19:46

netcat мог быть не установлен. Например, в debian это отдельный пакет, по умолчанию не устанавливаемый.

mikhailnk Apr 5 2017 at 21:17

совершенно верно, nc в rhel-подобных ОС пакет есть, но в минимальную установку не входит.

Tallanvor Apr 5 2017 at 21:59

Возможно, побуду К.О., но если всё так трепетно 100500 раз проверялось перед запуском, то почему не использовался ключ --dry-run для rsync перед реальным выполнением?

Но за метод — отдельное «спасибо», отправил в копилку.
Мало ли как оно в будущем сложится ;)

mikhailnk Apr 5 2017 at 22:04

Прогон rsync -n не всегда уместен с т.з. результата ибо данные могут меняться во время синхронизации рабочей систему, а могут и нет.
Человеческий фактор не всегда предугадаешь. После того случая — только копипаст уже отработанного.

Gendalph May 12 2017 at 23:58

Он дает общее понятие о том что произойдет и часто позволяет отловить проблемы на начальном этапе.

А вот ремаунт в RO — хорошая идея, но требует отпределенной подготовки.

Merkat0r Apr 5 2017 at 22:56

бекапы сделали сами

дак и достали бы весь */*/bin (ну или ldd rsync и тока их), НО

Проверяем заработал ли rsync, если нет — смотрим чего не хватает, если да — запускаем rsync,

Почему было просто не взять static-linked rsync ?:)

т.е. каждый администратор помимо сертификации RHCE должен уметь её решать + интересно давать её на собеседовании linux-админам

А зачем сертификация? Чтобы еще раз доказать, что она бесполезна? :)

mikhailnk Apr 5 2017 at 23:28

Бекапы приклада. ОС можно восстановить в любом случае и довольно быстро.

Да, думали на эту тему, решили, что быстрее и надёжнее будет восстановить все как было + на static-linked пришлось потратить время на поиск/закачку и пр. Но как вариант это сработает.

Сертификация как результат не важна. А вот подготовка — другое дело. Опыт не всегда перекрывает все темы разом и, как правило, без системный.

AlexeySaff Apr 6 2017 at 10:21

dry-run в rsync для проверки никто не отменял.

влезли в жопу, а потом героически ее победили

mikhailnk Apr 6 2017 at 10:27

Про dry-run — см. выше, он не всегда уместен. Попробуйте проанализировать результат на часто меняющихся данных с множеством файлов (например, кеш с много млрд файлов или огромный массив изменяемых данных (бд)).

Про геройство — кто бы спорил :) Но факт остаётся фактом, ни кто не застрахован от ошибок. Главное из любой ситуации важно выйти и сделать выводы, чтобы в будущем подобные ситуации не повторялись.

darken99 Apr 6 2017 at 14:13

А вы, простите, БД файлами копируете? :)

mikhailnk Apr 6 2017 at 14:29

Зависит от задачи. Частенько бывало и такое (например, когда репликация не возможна, а объём десятки-сотни Гб). Естественно, финальный прогон когда база остановлена.

Сейчас есть другие средства миграции/конвертеры и пр., которые позволяют более-менее мигрировать без головной боли.

Gendalph May 13 2017 at 00:01

А как же родной grep?

rsync --dry-run | grep

Есть еще PCREgrep и много-много другого софта, упрощяющего анализ простыней отчетов.

mikhailnk May 14 2017 at 02:09

grep — это инструмент, по-сути, фильтр. А вот выбор критерия фильтрации и анализ результатов — это другое дело. Тоже самое с --dry-run. Например, если из 1 млдр. файлов после нескольких итераций/фильтров будет получен 1 млн., то человеку все равно тяжело проанализировать.
Это я к тому, что все надо с умом применять. Где-то конкретный инструмент покажет потенциальную проблему, а где-то нет. Тут надо думать про «защиты от дурака»/человеческого фактора на другом уровне.

Gendalph May 14 2017 at 02:25

В том-то и дело, что grep — фильтр и ничто вам не мешало сохранить прогон с --verbose --dry-run в файл и читать его до просветления.

Это нормальная практика и я бы даже сказал правильный подход.

mikhailnk May 14 2017 at 02:48

На тестовом прогоне так и было. В данном случае проблема возникла когда дежурный специалист решил не копипастить команду, а просто изменить параметры предыдущей.

Также при большом кол-ве операций и сжатых сроках (например, dry-run только 1 операции проходит часа за 3-4), выполнять каждый раз перед выполнением проверку — не дозволенная роскошь при окне на все работы в пару часов. Для этого есть тестовый стенд/прогон и пр.

BcTpe4HbIu Apr 6 2017 at 12:40

При живом баше можно было обойтись без nc на принимающем сервере.

На доноре:

nc -l -p 8080 < test.tgz

На принимающем:

cat - > test.tgz < /dev/tcp/donor.server/8080

mikhailnk Apr 6 2017 at 12:47

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

4144 Apr 6 2017 at 19:24

Можно попробовать запустить на сервере, на котором происходят работы:
1. sshfs смонтировать директорию с другого сервера.
2. открыть ssh соединение на тот сервер, откуда смонтирована директория.
3. запустить mc.

Если на текущем сервере что-то повреждается, то по ssh можно сразу сделать исправление на удаленном сервере. потом при помощи mc и sshfs скопировать на сервер с повреждением.

Можно заменить mc на busybox или еще что-то. но с mc сложнее еще раз ошибиться.

mikhailnk Apr 6 2017 at 21:56

В данному случае даже новую сессию открыть не получалось (дубликат текущей, из-за отсутствие библиотек) + для sshfs требуется fuse, который не входит в минимальную установку. Если же работает запуск отдельных сессий, то проще scp/rsync использовать.

Вариантов решения много, но главная проблема — транспорт.

4144 Apr 7 2017 at 00:22

это не инструкция как исправить уже случившуюся проблему, а инструкция для предварительных действий.
В такой конфигурации я удалил libc, но все нормально восстановилось. скопировал через sshfs и mc распакованный пакет.

mikhailnk Apr 7 2017 at 01:15

«Правильное решение» в данном случае должно было быть на административном уровне, а не техническом ибо все мы люди и человеки, но любой косяк технаря должен быть предусмотрен заранее.
На техническом можно было развернуть резервную систему в ОЗУ и при необходимости переключиться на нее. Вот только там могли быть другие косяки и другие ветви развития событий…

Show the best of all time