[Sysadmins] если предлагают поставить glibc.32bit

[Michael Shigorin]

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/