Comments 27
Не совсем понятно как Вы запустили telnet если он хранится как раз в /usr/bin, который был удален:
$ whereis telnet
telnet: /usr/bin/telnet
Ситуация — частный случай, telnet, busybox и еще пару утилит работали (проверяли методом перебора, rsync удаляет не сразу все). В основном были удалены библиотеки, что приводило к ошибке вида:
XXX: error while loading shared libraries: libXXXX.so: cannot open shared object file: No such file or directory
Так у вас же busybox был. Наверняка в busybox был wget, даже если ваш busybox был неполноценным. Далее качаем полноценный статический busybox с сайта и делаем все в нем.
подсказка коллеги — тоже тем же способом был передан. т.е. сконвертировали в txt, но копировали через буфер обмена и терминал. Всего-то 140кб.
UFO just landed and posted this here
Возможно, побуду К.О., но если всё так трепетно 100500 раз проверялось перед запуском, то почему не использовался ключ --dry-run для rsync перед реальным выполнением?
Но за метод — отдельное «спасибо», отправил в копилку.
Мало ли как оно в будущем сложится ;)
Но за метод — отдельное «спасибо», отправил в копилку.
Мало ли как оно в будущем сложится ;)
Прогон rsync -n не всегда уместен с т.з. результата ибо данные могут меняться во время синхронизации рабочей систему, а могут и нет.
Человеческий фактор не всегда предугадаешь. После того случая — только копипаст уже отработанного.
Человеческий фактор не всегда предугадаешь. После того случая — только копипаст уже отработанного.
бекапы сделали сами
дак и достали бы весь */*/bin (ну или ldd rsync и тока их), НО
Проверяем заработал ли rsync, если нет — смотрим чего не хватает, если да — запускаем rsync,
Почему было просто не взять static-linked rsync ?:)
т.е. каждый администратор помимо сертификации RHCE должен уметь её решать + интересно давать её на собеседовании linux-админам
А зачем сертификация? Чтобы еще раз доказать, что она бесполезна? :)
Бекапы приклада. ОС можно восстановить в любом случае и довольно быстро.
Да, думали на эту тему, решили, что быстрее и надёжнее будет восстановить все как было + на static-linked пришлось потратить время на поиск/закачку и пр. Но как вариант это сработает.
Сертификация как результат не важна. А вот подготовка — другое дело. Опыт не всегда перекрывает все темы разом и, как правило, без системный.
Да, думали на эту тему, решили, что быстрее и надёжнее будет восстановить все как было + на static-linked пришлось потратить время на поиск/закачку и пр. Но как вариант это сработает.
Сертификация как результат не важна. А вот подготовка — другое дело. Опыт не всегда перекрывает все темы разом и, как правило, без системный.
dry-run в rsync для проверки никто не отменял.
влезли в жопу, а потом героически ее победили
влезли в жопу, а потом героически ее победили
Про dry-run — см. выше, он не всегда уместен. Попробуйте проанализировать результат на часто меняющихся данных с множеством файлов (например, кеш с много млрд файлов или огромный массив изменяемых данных (бд)).
Про геройство — кто бы спорил :) Но факт остаётся фактом, ни кто не застрахован от ошибок. Главное из любой ситуации важно выйти и сделать выводы, чтобы в будущем подобные ситуации не повторялись.
Про геройство — кто бы спорил :) Но факт остаётся фактом, ни кто не застрахован от ошибок. Главное из любой ситуации важно выйти и сделать выводы, чтобы в будущем подобные ситуации не повторялись.
А вы, простите, БД файлами копируете? :)
А как же родной grep?
rsync --dry-run | grep
Есть еще PCREgrep и много-много другого софта, упрощяющего анализ простыней отчетов.
grep — это инструмент, по-сути, фильтр. А вот выбор критерия фильтрации и анализ результатов — это другое дело. Тоже самое с --dry-run. Например, если из 1 млдр. файлов после нескольких итераций/фильтров будет получен 1 млн., то человеку все равно тяжело проанализировать.
Это я к тому, что все надо с умом применять. Где-то конкретный инструмент покажет потенциальную проблему, а где-то нет. Тут надо думать про «защиты от дурака»/человеческого фактора на другом уровне.
Это я к тому, что все надо с умом применять. Где-то конкретный инструмент покажет потенциальную проблему, а где-то нет. Тут надо думать про «защиты от дурака»/человеческого фактора на другом уровне.
В том-то и дело, что grep — фильтр и ничто вам не мешало сохранить прогон с --verbose --dry-run в файл и читать его до просветления.
Это нормальная практика и я бы даже сказал правильный подход.
На тестовом прогоне так и было. В данном случае проблема возникла когда дежурный специалист решил не копипастить команду, а просто изменить параметры предыдущей.
Также при большом кол-ве операций и сжатых сроках (например, dry-run только 1 операции проходит часа за 3-4), выполнять каждый раз перед выполнением проверку — не дозволенная роскошь при окне на все работы в пару часов. Для этого есть тестовый стенд/прогон и пр.
Также при большом кол-ве операций и сжатых сроках (например, dry-run только 1 операции проходит часа за 3-4), выполнять каждый раз перед выполнением проверку — не дозволенная роскошь при окне на все работы в пару часов. Для этого есть тестовый стенд/прогон и пр.
При живом баше можно было обойтись без nc на принимающем сервере.
На доноре:
nc -l -p 8080 < test.tgzНа принимающем:
cat - > test.tgz < /dev/tcp/donor.server/8080
Можно попробовать запустить на сервере, на котором происходят работы:
1. sshfs смонтировать директорию с другого сервера.
2. открыть ssh соединение на тот сервер, откуда смонтирована директория.
3. запустить mc.
Если на текущем сервере что-то повреждается, то по ssh можно сразу сделать исправление на удаленном сервере. потом при помощи mc и sshfs скопировать на сервер с повреждением.
Можно заменить mc на busybox или еще что-то. но с mc сложнее еще раз ошибиться.
1. sshfs смонтировать директорию с другого сервера.
2. открыть ssh соединение на тот сервер, откуда смонтирована директория.
3. запустить mc.
Если на текущем сервере что-то повреждается, то по ssh можно сразу сделать исправление на удаленном сервере. потом при помощи mc и sshfs скопировать на сервер с повреждением.
Можно заменить mc на busybox или еще что-то. но с mc сложнее еще раз ошибиться.
В данному случае даже новую сессию открыть не получалось (дубликат текущей, из-за отсутствие библиотек) + для sshfs требуется fuse, который не входит в минимальную установку. Если же работает запуск отдельных сессий, то проще scp/rsync использовать.
Вариантов решения много, но главная проблема — транспорт.
Вариантов решения много, но главная проблема — транспорт.
это не инструкция как исправить уже случившуюся проблему, а инструкция для предварительных действий.
В такой конфигурации я удалил libc, но все нормально восстановилось. скопировал через sshfs и mc распакованный пакет.
В такой конфигурации я удалил libc, но все нормально восстановилось. скопировал через sshfs и mc распакованный пакет.
«Правильное решение» в данном случае должно было быть на административном уровне, а не техническом ибо все мы люди и человеки, но любой косяк технаря должен быть предусмотрен заранее.
На техническом можно было развернуть резервную систему в ОЗУ и при необходимости переключиться на нее. Вот только там могли быть другие косяки и другие ветви развития событий…
На техническом можно было развернуть резервную систему в ОЗУ и при необходимости переключиться на нее. Вот только там могли быть другие косяки и другие ветви развития событий…
Only those users with full accounts are able to leave comments. Log in, please.
Восстановление remote сервера после удаления части ОС