2015-03-01 Удалённое изнасилование: миграция сервера с 32 на 64 бита
Материал из YourcmcWiki
(Новая страница: «Только что удалённо смутировал сервачок с 32-х на 64 бита. Нюансы: * в целом, за исключением …») |
м |
||
Строка 1: | Строка 1: | ||
− | + | О, я крут. Вчера удалённо сменил систему (Debian Wheezy) на сервачке с 32-х на 64-х битную. | |
− | + | Применил для этого свою [[Блог:Виталий Филиппов/2015-03-02 Аварийная система для Debian - краткая инструкция|«аварийную систему»]], состоящую из dropbear и busybox в initramfs (очень рекомендую, удобная штука). | |
− | + | ||
− | * | + | Общая схема действий у меня была такая — почистить систему от устаревших пакетов, перейти на 64-битное ядро, создать 64-битную копию системы из тех же пакетов и потом через аварийную систему (dropbear) заменить содержимое / и /usr на 64-битное, оставив старые /etc и /var. |
− | * | + | |
− | * MySQL (InnoDB) отлично | + | В целом, за исключением некоторых нюансов, после такой операции система стартует без особых проблем. Какие конкретно есть нюансы: |
− | * /var/lib/dpkg | + | * Чтобы поставить все те же пакеты в 64-битном виде, сначала нужно почистить систему от устаревших пакетов. Для этого удобно использовать Aptitude — оно умеет показывать «локальные/устаревшие» пакеты — то есть установленные, но которых при этом нет в репозиториях. Все такие пакеты надо прибить или на что-то заменить — собственно, это вообще полезно, система чище будет. |
− | + | * Модули perl/python/ruby/php, установленные через cpan/pip/gem/pear, естественно, в 64-битной системе нужно установить заново. | |
− | * | + | * Данные MySQL (InnoDB) трогать не надо — они отлично переносятся, формат хранения архитектурно-независим. |
− | * /etc/ld.so.conf.d | + | * Базы данных dpkg и debconf (/var/lib/dpkg и /var/cache/debconf) нужно обязательно скопировать из chroot’а от новой 64-битной системы в свой /var, в целом остающийся от старой системы без изменений). |
− | * | + | * Некоторые alternatives — конкретно, java’шные — могут поломаться, их нужно починить (update-alternatives --all). |
+ | * /etc/ld.so.conf.d/* нужно тоже взять от 64-битной системы. | ||
+ | * Базы данных rrdtool архитектурно-зависимы! Их нужно сделать dump/restore. Актуально для систем мониторинга — nagios, munin и подобные, как правило, именно RRD и используют. | ||
+ | {{wl-publish: 2015-03-02 13:49:11 +0300 | VitaliyFilippov }} |
Версия 13:49, 2 марта 2015
О, я крут. Вчера удалённо сменил систему (Debian Wheezy) на сервачке с 32-х на 64-х битную.
Применил для этого свою «аварийную систему», состоящую из dropbear и busybox в initramfs (очень рекомендую, удобная штука).
Общая схема действий у меня была такая — почистить систему от устаревших пакетов, перейти на 64-битное ядро, создать 64-битную копию системы из тех же пакетов и потом через аварийную систему (dropbear) заменить содержимое / и /usr на 64-битное, оставив старые /etc и /var.
В целом, за исключением некоторых нюансов, после такой операции система стартует без особых проблем. Какие конкретно есть нюансы:
- Чтобы поставить все те же пакеты в 64-битном виде, сначала нужно почистить систему от устаревших пакетов. Для этого удобно использовать Aptitude — оно умеет показывать «локальные/устаревшие» пакеты — то есть установленные, но которых при этом нет в репозиториях. Все такие пакеты надо прибить или на что-то заменить — собственно, это вообще полезно, система чище будет.
- Модули perl/python/ruby/php, установленные через cpan/pip/gem/pear, естественно, в 64-битной системе нужно установить заново.
- Данные MySQL (InnoDB) трогать не надо — они отлично переносятся, формат хранения архитектурно-независим.
- Базы данных dpkg и debconf (/var/lib/dpkg и /var/cache/debconf) нужно обязательно скопировать из chroot’а от новой 64-битной системы в свой /var, в целом остающийся от старой системы без изменений).
- Некоторые alternatives — конкретно, java’шные — могут поломаться, их нужно починить (update-alternatives --all).
- /etc/ld.so.conf.d/* нужно тоже взять от 64-битной системы.
- Базы данных rrdtool архитектурно-зависимы! Их нужно сделать dump/restore. Актуально для систем мониторинга — nagios, munin и подобные, как правило, именно RRD и используют.