В статье (http://ww.inf-sys.ru/index.php/it-operating/144) рассказано как быстро и эффективно произвести перестановку ОС FreeBSD со сменой архитектуры с i386 на amd64, при условии, что имеется только удаленный доступ. Для решения поставленной задачи к статье приложены 2 скрипта, которые пакуют и обновляют систему. Данные скрипты также удобно применять для установки идентичной FreeBSD на несколько компьютеров без остановки клонируемой системы.URL: http://ww.inf-sys.ru/index.php/it-operating/144
Новость: http://www.opennet.me/opennews/art.shtml?num=24058
кстати, а есть официальный путь обновления архитектуры?
Не статья, а бред какой-то.
Нигде не увидел обновление мира, ядра.
Там обновеление путем замены.
порты фигня. Вот это круче:
>Проверка пригодности. Настраиваем на виртуальном сервере ip адрес, шлюз по умолчанию идентичные реальному серверу, не забываем настроить ssh сервер. Проверяем: возможность входа по sshлибо понимание слова "идентичные" у нас с автором разные, либо ...
> достиг результат за 2 часа 34 минуты. Изложенный в данной статье способ безусловно может быть подвержен критике, т.к. многие специалисты посоветую многоэтапное обновление, с выкачиванием последних исходников по cvs, пересборкой их под другую архитектуру и т.д, мотивируя что «так будет правильно». Мое личное мнение — правильно то, что эффективно, быстро и надежно, а усовершенствовать систему путем пересборки спокойно можно после смены архитектуры.Тогда зачем критиковать? Он это сделал не так, как другие. Сломал ваши стереотипы. Debian GNU/kFreeBSD этим тоже занимается. :-)
Т.е. вырезание гланд через ж**у вы предлагаете поощрять? А Debian GNU/kFreeBSD сюда вообще никаким боком.
Автор занимается клонированием системы, и назвать статью надо было,
"Клонирование системы на удаленный комп"
И "удаленный" комп стоял на соседнем столе, делать такое на реальном железе,
это надо быть комикадзе.
Знаю людей которые и при классическом обновлении катались в командировку.
То что сделал автор, реально, но через задницу.
Если мне не изменяет память, удалённый апгрейд с i386 на amd64 был описан около полутора лет назад у Лисяры
Интересное решение. Спасибо.
Удалённое удаление аппендицита и попутная смена пола у пациента :-)
Против FreeBSD ничего не имею, хоть и использую его с графикой.
Почитал коменты, т.к. не первый раз пишу статьи ничему не удивился, поэтому отвечу на сообщения людей, которым было что-то неясно:1)
> И "удаленный" комп стоял на соседнем столе, делать такое на реальном железе,
> это надо быть комикадзе.На практике 8 раз уже использовалась, менялась FreeBSD i386 на группе серверов + просто клонили 1 нормально настроенный сервер на другие. Ни одной неудачной попытки. Делайте всё четко по доке и всё получится.
2)
> Если мне не изменяет память, удалённый апгрейд с i386 на amd64 был описан
> около полутора лет назад у ЛисярыПортал Лисяры - отличный источник, которым мы и сами постоянно пользуемся, но единственное схожее в наших статьях - это ситуации. Прочтите статью на Лиссяре и эту, сравните сложность и количество операций, и учтите одну мелочь, что сам автор той статьи пишет что уронил систему и заказывал KVM... стоит задуматься...
3)
> В том то и дело, что хоть потом, хоть вообще не ставь. Указывать это в
> заметке - верх дебилизма.Дерево портов состоит из множества мелких файлов, если его поставить сразу то операция паковки растянется, поэтому в статье специально написано что пока можно не ставить.
Подведу итог.
Автор уверяет, что он уже 8 раз прыгал с третьего этажа, по статье которую
он написал и с ним нечего не случилось, вот счастливчик!
И предлагает попробывать всем, кому не повезёт, тот сам виноват.
Судя по всему вы при необходимости произвести идентичную установку на десяток машин бегаете к каждой с стандартным установочным диском и как обезьянка повторяете однотипные действия по инсталляции базовой системы, дополнительного софта и его настройке. А умные люди еще в прошлом веке освоили разворачивание готового образа. Так что куда уместней была бы аналогия с лифтом и беганьем по ступенькам.
Вы не поняли, как статья называется?
Если это делается на сервере который ещё не запустили в работу,то нет проблем.
Я бы посмотрел на афтора, когда это, он устроил бы на рабочем сервере,
где простой 1 минута и все на ушах, со сменой архитектуры, да ещё и удаленно.
Статья имеет только академический интерес и всё, типа "Вот как я могу"
Клонирование, это другой вопрос.
Вы знаете более быстрый метод решения данной задачи, чем развертка образа? Делитесь. Если не знаете, то хотя бы послушайте что говорят опытные люди, может пригодится.
Кстати, при правильном построении крупной системы выход из строя одного сервера остается незамеченным, а подобные(я не сказал такие же) перезаписи вообще в порядке вещей.
А в чём, собственно, проблема с таким способом обновления? "Вырезать гланды, прыгать с этажа" - аргументируйте. А то собрались болтуны.
Пока единственный возможный point of failure - это разрыв сетевого соединения в процессе обновления. И то - если всё в фоне c nohup запустить, это можно обойти. (сами скрипты я не изучал.)
А если кому-то требуется ещё и обновление ядра и мира, то
cd /usr/ports/misc/freebsd-doc-ru
make install clean
>А в чём, собственно, проблема с таким способом обновления? "Вырезать гланды, прыгать
>с этажа" - аргументируйте. А то собрались болтуны.
>Пока единственный возможный point of failure - это разрыв сетевого соединения в
>процессе обновления. И то - если всё в фоне c nohup
>запустить, это можно обойти. (сами скрипты я не изучал.)
>А если кому-то требуется ещё и обновление ядра и мира, то
>cd /usr/ports/misc/freebsd-doc-ru
>make install cleanscreen решает.
Для удаленного переноса вполне прилично. Однажды так менял линух на фрибсд, права на ошибку нет, находимся в разных концах света. Единственное не стал заморачиваться с эмуляторами, вполне достаточно chroot. Автор молодец, как один из вариантов апгрейда. В каких-то вариантах очень даже нужно.