Восстановите сервер Linux после случайного `rm` в /etc
У меня установлен сервер Linux (Debian squeeze). Его основной задачей является запуск лампы. Я также использую его для таких вещей, как бормотание (голосовой чат) и майнкрафт-серверы.
В начале все было нормально. Тогда вещи начали происходить. Такие вещи, как java, не запускаются без режима заголовка и полностью теряют способность разрешать имена хостов. Я исправил разрешение имени хоста с помощью перезагрузки - что, как я слышал, не является желаемым исправлением в системах Linux.
У меня есть физический доступ к серверу компьютера (я сам его создал), но он не находится у меня дома. Поэтому я использую SSH для взаимодействия с ним. Вчера я заметил, что он не показывает путь в ssh-клиенте, а только "-bash-4.1#".
Кроме того, после перезагрузки, когда я пытался запустить сервер mumble, он просто говорит, что отсутствует файл: "/etc/mumble-server.ini"
Этот сервер содержит важную (и конфиденциальную) информацию о компании. Должен ли я волноваться, что какой-то хакер проник в это? Я установил на него какое-то вредоносное ПО (сомневаюсь)
РЕДАКТИРОВАТЬ: я не могу получить доступ к сайту, который он должен быть хостингом. Это важная часть веб-сервисов компании. Это очень плохо.
Я также помню, что пару недель назад я по ошибке запустил что-то вроде rm. * В / etc с рутом. Тогда все работало нормально, поэтому я проигнорировал это. Что я могу сделать, чтобы это исправить? Я действительно облажался?
ОБНОВЛЕНИЕ: Кажется, что apache не запускается из-за отсутствия файла mime.types. Он должен быть расположен в / etc. Есть ли команда, чтобы восстановить его?
ОБНОВЛЕНИЕ: Поскольку все остальное не удалось, я переустанавливаю ОС и программное обеспечение сервера. Хорошо, что у меня регулярно хранится вся важная и конфиденциальная информация.
3 ответа
Скорее всего, причиной ваших проблем является rm
команда, в которой вы бежали /etc
, Я бы предложил переустановить ОС.
Лучше всего выяснить, что именно вы сделали и где, это проверить ваши журналы sudo. Вот пример записи:
Jul 24 22:38:08 node1 sudo: scott : TTY=pts/0 ; PWD=/home/scott ; USER=root ; COMMAND=/bin/rm marker_file
Итак, мы видим, что я дал команду /bin/rm marker_file
без дополнительных аргументов из каталога /home/scott
, Так что это говорит нам о том, что я удалил файл /home/scott/marker_file
,
Экстраполируя это, мы можем точно определить, чего не хватает, так что у вас есть лучшее представление о том, какие файлы выбрать из резервной копии. Например, если мы увидели сообщение журнала
Jul 12 08:38:08 node1 sudo: scott : TTY=pts/0 ; PWD=/etc/httpd/modules ; USER=root ; COMMAND=/bin/rm -rf tmpfile *
тогда мы можем выяснить, что вы рекурсивно удалили все, начиная с каталога /etc/httpd/modules
, Поскольку это дает нам как временную метку события, так и список затронутых файлов, мы можем довольно легко выяснить, что необходимо восстановить.
Кроме того, я бы предположил, что вы пытаетесь завершить вкладку группы файлов, которые начинались с tmpfile
не понимая, что существует только один. Я пришел к такому выводу, основываясь на том факте, что, как правило, bash добавляет пробел в конец полностью совпадающего файла при завершении табуляции. Однако это будет полная догадка, и ее стоит упомянуть только в качестве возможного объяснения инцидента.
Отмена (большинство ваших) ошибок в Debian, например удаление жизненно важных файлов конфигурации из /etc, может быть отменена путем переустановки всех пакетов. Это можно сделать с помощью следующей команды:
aptitude reinstall '~i'