Если кто учился в универе (особенно там, где учат чему-то вроде системного администрирования), то вы знаете, что цикл жизни информационной системы состоит из чего-то в духе «подготовка, разработка, развертывание, эксплуатация, окончание эксплуатации». Как там научно, я не помню, но в общих чертах не ошибся.
Сервер — та же информационная система (набор программного, аппаратного обеспечения и информации). Ну так вот, если с первыми четырьмя стадиями жизни сервера все админы худо-бедно справляются, то про последнюю частенько забывают.
Вообще из старых дисков у хостеров всегда можно достать много всего интересного =)
Можно, конечно, надеяться, что хостер диски всегда чистит, но практика показывает, что далеко не все этим занимаются.
Как обычно, всё сами, всё сами.
С чисткой дисков есть вполне себе основательная проблема — качественно почистить диски из запущенной системы сложно. Большинство админов ограничиваются тем, что делают rm -fr /*. Часть файлов действительно удаляются, но другая часть остаётся. К тому же, по диску всегда можно пройтись каким-нибудь extundelete. Выход один — пройтись shred’ом. Но shred’ом пройтись по дискам из работающей системы… хм. Да и он может доработать не до конца, и файлы все равно можно будет восстановить.
У части хостеров для решения таких задач есть загрузка системы по PXE. Но не у всех. А нам нужен универсальный способ, который подойдет везде.
Выход есть, очень простой. Развернуть нагорячую вторую систему в памяти, запустить shred из неё. Нам понадобится примерно 3G свободной памяти (ну можно уложиться в 2). Так что перед началом чистки вырубаем в системе всё, что вырубается (ну там apache, nginx, mysql, etc).
Поехали.
Готовом систему в памяти:
Ставим нужный софт в новой системе:
Запускаем ssh:
Задаём пароль рута во второй системе:
Дальше заходим на свой сервер по ssh по порту 2222
Запускаем screen:
Запускаем чистку дисков:
Можно отключаться от ssh (выйти из скрина — ctrl-a, d, из ssh — ctrl-d). Когда захочется посмотреть на результат, можно туда вернуться и посмотреть в screen снова:
Обычный ssh умрет достаточно скоро, а вот та система, которая запущена из оперативной памяти проживет достаточно долго. Главное, не ребутить сервер.
И да, я настоятельно советую делать тоже самое с виртуалками, если они на KVM или Xen. Только там диски, скорее всего, называются /dev/vd*:
В общем-то всё. Удачи)
зачем такая конструкция: for i in `ls /dev/sd* | grep -v «[0-9]»`? не проще написать for i in /dev/sd?, мм?
Потому что дисков бывает больше двадцати шести.
Меня shred из живой системы никогда не подводил. Везло, наверное :)
Угу, везло. Из памяти бинарников не выносило и ssh не отваливался ;)
А если отваливался — то ты не знаешь, подводил или нет.
А зачем чистить все диски, если можно просто важную инфу удалить, не трогая при этом систему?
http://extundelete.sourceforge.net/ примерно за этим.
К тому же, вряд ли кто-то наизусть знает, какие файлики нужно удалять, а какие можно оставить.
Если инфа настолько важная, что надо чистить диски, то есть смысл держать ее на шифрованном разделе, отдельно от системы, чтоб так не извращаться с удалением.
А обычный бложек никто восстанавливать у хостера не будет :)
Где тут извращения то? Вполне себе штатный способ, его лет 15 уже используют.
Повторюсь — никто точно наизусть не запомнит, где лежат важные файлы, а где нет. Например, можно забыть про /var/lib/php5/sess_.
Или про бинлоги.
Или про файло в каком-нибудь /run, если он не смонтирован как tmpfs.
Обычный бложек тоже вполне себе ценен, хотя бы базкой с паролями и возможностью потом на этом бложеке положить что нужно, поломав его на новом сервере.
надо заменить
sed ‘s/Port .*/Port 2222/’ /chroot/etc/ssh/sshd_config
на
sed -i ‘s/Port .*/Port 2222/’ /chroot/etc/ssh/sshd_config
иначе файл не будет изменён
Спс, заменил.
Забыл добавить после того, как в консоли всё проверял)
Интересный способ.
При установке в chroot openssh-server он пытается запустится сразу, если я не ошибаюсь. Чтобы лишних попыток не было, пакеты проще доставить при выполнении debootstrap через параметр —include, тогда он сразу не запустится и после правки скрипта можно будет просто запустить ssh на нужном порту. ХОтя для данного случая это не существенно…
Ну бог с ним, пусть пытается )
Порт то занят
Дистрибутив переехал в архив:
http://cdn.debian.net/debian -> http://archive.debian.org/debian-archive/debian