[Sysadmins] если предлагают поставить glibc.32bit
Michael Shigorin
=?iso-8859-1?q?mike_=CE=C1_osdn=2Eorg=2Eua?=
Чт Авг 7 15:33:43 MSD 2008
On Thu, Aug 07, 2008 at 12:53:24PM +0400, Aleksey E. Birukov wrote:
> Нужно было временно установить MySQL4 на удаленный сервер.
> 64bit-ную версию я не нашел -- пришлось поставить 32bit-ную.
Почему ж было не спросить здесь?
> Get:4 ftp://ftp.altlinux.org i586/classic libMySQL41.32bit 4.1.21-alt5.1
Там же рядышком с заменой i586 на x86_64 -- нужная...
Интересно, возможно ли каким-либо способом понадёжней
заблокировать такой сценарий? Например, объявить важной
не просто glibc, а для архитектуры, под которую собран apt.
> Можно ли починить сервер удалённо?
Это было практически невозможно.
> Если нельзя, то какие действия оптимально нужно сделать для
> исправления ситуации?
Организовать добирание туда кого-то с rescue/livecd и сливание
/etc и прочих данных с последующим reinstall...
On Thu, Aug 07, 2008 at 01:23:08PM +0400, Aleksey E. Birukov wrote:
> Что, вообще, с системой случилось?
Вы её угробили. Это ценный опыт, но лучше в будущем при таких
"нужно временно" и столкновении с необычным выводом apt:
- чтоб что-то начинало чесаться
- заодно можно спросить на #altlinux или в community@
- если совсем некогда, проверить на стенде
- если совсем-совсем некогда, то подумать, важнее ли результат
возможной необходимости восстановления системы с нуля
PS: ещё из той же оперы -- засунуть бинарно-несовместимую glibc
с --nodeps (мой второй убитый линукс). А этот же самый фокус
тоже проходил, только в процессе формирования системы -- взял
не тот sources.list из уже готовых и проигнорировал необычность
вывода apt. Правда, система строилась всё равно заново и там
этот опыт стоил всего часа или двух на повторение процесса...
On Thu, Aug 07, 2008 at 02:12:58PM +0400, Nikolay A. Fetisov wrote:
> > Может бинарные версии файлов загрузить?
> Можно _попробовать_ загрузиться с установочного диска в режиме
> восстановления, смонтировать убитую систему и переписать в неё
> файлы из пакетов со снесёнными библиотеками. Перейти через
> chroot в систему, запустить ldconfig. По-идее, должно помочь.
> Затем, после перезагрузки, восстановить конфигурацию APT и
> переустановить библиотеки.
Это требует довольно заметной квалификации и наличия возможности
загрузиться с 64-битного livecd/rescue _на том конце_.
> Далее изучать литературу в области OpenVZ, который позволяет
> держать 32-битные контейнеры в 64-битной системе и избегать
> подобных стрессов.
+1
On Thu, Aug 07, 2008 at 02:31:17PM +0400, Pavlov Konstantin wrote:
> > нужно завести привычку: держать ash-static и rpm-static на
> > "ответственной" сситеме.
Записал в todo.
> Да ну, просто надо понимать что делаешь и если не очень, то тестировать.
Ой да.
On Thu, Aug 07, 2008 at 01:01:33PM +0300, Dmitriy Kruglikov wrote:
> > Все... к ssh больше не коннектится. Вопрос об удалённом
> > восстановлении снят. Можете ли что-нибудь посоветовать
> > по оптимальному восстановлению системы?
> Ваши настройки сохранились однозначно ...
> Стало быть, нужно добраться до диска и бережно его скопировать ...
> Установить систему начисто, а настройки потом перелить поверх.
Только стоит по возможности аккуратнее проверить, где ещё могут
быть нужные данные.
Навскидку стоит заархивировать и унести:
/etc
/home
/var
/usr/local
PS: ещё когда-то завёл привычку время от времени делать рутом
rpm -qa | sort > ~/BAK/rpm-qa.YYYYMMDD
или
rpm -qa --qf='%{NAME}\n' | sort > ~/BAK/rpm-qa.YYYYMMDD
-- тогда на корневой ФС остаются в виде текстовых данных списки,
пригодные для скармливания apt (во втором случае -- вообще без
дополнительной обработки).
Ещё хорошо делать fdisk -l, только это лучше держать на других
системах.
--
---- WBR, Michael Shigorin <mike на altlinux.ru>
------ Linux.Kiev http://www.linux.kiev.ua/
Подробная информация о списке рассылки Sysadmins