Привет, всем!На данный момент FreeBSD поддерживает механизм обновления через freebsd-update.
Как я понимаю такой механизм работает только для систем работающих с ядром GENERIС, т.е. подразумевается, что при необходимости наращивания функционала, необходимо использовать подгружаемые модули.
В связи с этим вопрос, существует на данный момент подгружаемый модуль обеспечивающий работу IPSEC?P.S. Собственно если такого модуля нет и не предвидится, то может я не правильно понимаю саму идею бинарных обновлений???
>Как я понимаю такой механизм работает только для систем работающих с ядром GENERIСЭто не так.
freebsd-update состоит из:
- бинарного обновления ядра
- бинарного обновления юзерленда
- обновления исходников системыЕсли апдейт обнаруживает, что текущее ядро не есть GENERIC, он пишет, что после бинарного обновления юзерленда и исходников нужно ручками заново пересобрать текущее ядро. Ну, или любое другое, по вкусу.
Собственно я предполагал, что имея механизм бинарного обновления, можно вообще перестать пересобирать ядро.
Т.е. мы проводим бинарное обновление стандартного ядра GENERIC + всех подгружаемых модулей, которые в стандартное ядро не включены (IPFW, IPSEC и т.д.) и вуаля - у нас модернизированная система.В противном случаи, каковы преимущества данного метода перед обычным обновлением исходных кодов?
>Собственно я предполагал, что имея механизм бинарного обновления, можно вообще перестать пересобирать
>ядро.
>Т.е. мы проводим бинарное обновление стандартного ядра GENERIC + всех подгружаемых модулей,
>которые в стандартное ядро не включены (IPFW, IPSEC и т.д.) и
>вуаля - у нас модернизированная система.
>
>В противном случаи, каковы преимущества данного метода перед обычным обновлением исходных кодов?
>freebsd-update выполнен так, что производит апгрейд между официальными релизами,
понятно что за точку отсчета берется ядро GENERIC, понятно что обновляются как ядро
с модулями, так и бинарники системы.
Преимущества в том что можно за один проход обновиться с 6.2-RELEASE до 8.0-RELEASE.
Нельзя обновиться, ну скажем, с 6.3-RELEASE до 7.2-STABLE или 8.0-STABLE и тд и тп.
Реакция у администраторов разная, одним важно чтобы система была как можно дольше
работоспособной в течение обновления - тут пока больше оправдывает себя
традиционная технология постепенного накатывания системы с релиза на релиз и с ветки
на ветку. Опыт показывает что чем дальше, тем затратней апгрейдить с ветки на ветку.
Те кто хотят быстрей - переходят на freebsd-update, особенно когда надо апгрейдить
с ветки на ветку или даже через ветку.
Пока, традиционный метод апгрейда через csup/svn + пересборка, самый стабильный
и надежный.Так как freebsd-update включен в дерево системы, то принято считать эту технологию
надежной и стабильной. Если сравнить с бинарными обновлениями в Linux, то freebsd-update
до нее далеко, но это объяснимо архитектурой, ибо во FreeBSD обновление ядра взаимосвязано
с обновлением системы, что отличается от Linux.
>Т.е. мы проводим бинарное обновление стандартного ядра GENERIC + всех подгружаемых модулей,
>которые в стандартное ядро не включены (IPFW, IPSEC и т.д.) и
>вуаля - у нас модернизированная система.
>
>В противном случаи, каковы преимущества данного метода перед обычным обновлением исходных кодов?К сожалению, есть вещи, которые невозможно задействовать через КО, и прописать в сисцтл или в лоадер. Например, только статически вкомпилированный IPFW c опцией ядра IPFIREWALL_DEFAULT_TO_ACCEPT способен работать фильтром прозрачного бриджа, и пропускать через себя ARP-пакеты. На дженерик-ядре этого не сделать никак.
Впрочем, все неудобство сводится к тому, что в /boot надо держать два ядра - свое и дженерик. В случае апдейта откатываться на дженерик, а после апдейта пересобирать свое ядро и переползать на него.
>[оверквотинг удален]
>>В противном случаи, каковы преимущества данного метода перед обычным обновлением исходных кодов?
>
>К сожалению, есть вещи, которые невозможно задействовать через КО, и прописать в
>сисцтл или в лоадер. Например, только статически вкомпилированный IPFW c опцией
>ядра IPFIREWALL_DEFAULT_TO_ACCEPT способен работать фильтром прозрачного бриджа, и пропускать через себя
>ARP-пакеты. На дженерик-ядре этого не сделать никак.
>
>Впрочем, все неудобство сводится к тому, что в /boot надо держать два
>ядра - свое и дженерик. В случае апдейта откатываться на дженерик,
>а после апдейта пересобирать свое ядро и переползать на него.А зачем откатываться то ? Ядро просто пересобрать после бинарного обновления всего остального.
>>Впрочем, все неудобство сводится к тому, что в /boot надо держать два
>>ядра - свое и дженерик. В случае апдейта откатываться на дженерик,
>>а после апдейта пересобирать свое ядро и переползать на него.
>А зачем откатываться то ? Ядро просто пересобрать после бинарного обновления всего
>остального.Ну, как бы, были прецеденты. Пусть лучше бинарно обновится все, включая дженерик-ядро, и потом загрузится нормально, а кастом-ядро я уже гарантированно откомпилирую. Чем иметь новый юзерленд на старом ядре, и под этим всем компилировать новое ядро, надеясь на лучшее.
>Ну, как бы, были прецеденты. Пусть лучше бинарно обновится все, включая дженерик-ядро,
>и потом загрузится нормально, а кастом-ядро я уже гарантированно откомпилирую. Чем
>иметь новый юзерленд на старом ядре, и под этим всем компилировать
>новое ядро, надеясь на лучшее.Чтож, вполне резонно :). С модульностью в FreeBSD пока не очень гладко, очень многие обыденные вещи требуют пересборки ядра :(.