https://opennet.me/openforum/vsluhforumID1/88808.html Привет, всем!<br><br>На данный момент FreeBSD поддерживает механизм обновления через freebsd-update. <br>Как я понимаю такой механизм работает только для систем работающих с ядром GENERIС, т.е. подразумевается, что при необходимости наращивания функционала, необходимо использовать подгружаемые модули.<br>В связи с этим вопрос, существует на данный момент подгружаемый модуль обеспечивающий работу IPSEC?<br><br>P.S. Собственно если такого модуля нет и не предвидится, то может я не правильно понимаю саму идею бинарных обновлений??? <br> https://opennet.me/openforum/vsluhforumID1/88808.html#7 Thu, 06 May 2010 11:39:27 GMT &gt;Ну, как бы, были прецеденты. Пусть лучше бинарно обновится все, включая дженерик-ядро, <br>&gt;и потом загрузится нормально, а кастом-ядро я уже гарантированно откомпилирую. Чем <br>&gt;иметь новый юзерленд на старом ядре, и под этим всем компилировать <br>&gt;новое ядро, надеясь на лучшее. <br><br>Чтож, вполне резонно :). С модульностью в FreeBSD пока не очень гладко, очень многие обыденные вещи требуют пересборки ядра :(.<br> https://opennet.me/openforum/vsluhforumID1/88808.html#6 Thu, 06 May 2010 08:56:08 GMT &gt;&gt;Впрочем, все неудобство сводится к тому, что в /boot надо держать два <br>&gt;&gt;ядра - свое и дженерик. В случае апдейта откатываться на дженерик, <br>&gt;&gt;а после апдейта пересобирать свое ядро и переползать на него. <br>&gt;А зачем откатываться то ? Ядро просто пересобрать после бинарного обновления всего <br>&gt;остального. <br><br>Ну, как бы, были прецеденты. Пусть лучше бинарно обновится все, включая дженерик-ядро, и потом загрузится нормально, а кастом-ядро я уже гарантированно откомпилирую. Чем иметь новый юзерленд на старом ядре, и под этим всем компилировать новое ядро, надеясь на лучшее. <br> https://opennet.me/openforum/vsluhforumID1/88808.html#5 Wed, 05 May 2010 22:45:53 GMT &gt;[оверквотинг удален]<br>&gt;&gt;В противном случаи, каковы преимущества данного метода перед обычным обновлением исходных кодов? <br>&gt;<br>&gt;К сожалению, есть вещи, которые невозможно задействовать через КО, и прописать в <br>&gt;сисцтл или в лоадер. Например, только статически вкомпилированный IPFW c опцией <br>&gt;ядра IPFIREWALL_DEFAULT_TO_ACCEPT способен работать фильтром прозрачного бриджа, и пропускать через себя <br>&gt;ARP-пакеты. На дженерик-ядре этого не сделать никак. <br>&gt;<br>&gt;Впрочем, все неудобство сводится к тому, что в /boot надо держать два <br>&gt;ядра - свое и дженерик. В случае апдейта откатываться на дженерик, <br>&gt;а после апдейта пересобирать свое ядро и переползать на него. <br><br>А зачем откатываться то ? Ядро просто пересобрать после бинарного обновления всего остального.<br> https://opennet.me/openforum/vsluhforumID1/88808.html#4 Wed, 28 Apr 2010 20:36:02 GMT &gt;Т.е. мы проводим бинарное обновление стандартного ядра GENERIC + всех подгружаемых модулей, <br>&gt;которые в стандартное ядро не включены (IPFW, IPSEC и т.д.) и <br>&gt;вуаля - у нас модернизированная система. <br>&gt;<br>&gt;В противном случаи, каковы преимущества данного метода перед обычным обновлением исходных кодов? <br><br>К сожалению, есть вещи, которые невозможно задействовать через КО, и прописать в сисцтл или в лоадер. Например, только статически вкомпилированный IPFW c опцией ядра IPFIREWALL_DEFAULT_TO_ACCEPT способен работать фильтром прозрачного бриджа, и пропускать через себя ARP-пакеты. На дженерик-ядре этого не сделать никак.<br><br>Впрочем, все неудобство сводится к тому, что в /boot надо держать два ядра - свое и дженерик. В случае апдейта откатываться на дженерик, а после апдейта пересобирать свое ядро и переползать на него. <br><br> https://opennet.me/openforum/vsluhforumID1/88808.html#3 Wed, 28 Apr 2010 14:54:15 GMT &gt;Собственно я предполагал, что имея механизм бинарного обновления, можно вообще перестать пересобирать <br>&gt;ядро. <br>&gt;Т.е. мы проводим бинарное обновление стандартного ядра GENERIC + всех подгружаемых модулей, <br>&gt;которые в стандартное ядро не включены (IPFW, IPSEC и т.д.) и <br>&gt;вуаля - у нас модернизированная система. <br>&gt;<br>&gt;В противном случаи, каковы преимущества данного метода перед обычным обновлением исходных кодов? <br>&gt;<br><br>freebsd-update выполнен так, что производит апгрейд между официальными релизами,<br>понятно что за точку отсчета берется ядро GENERIC, понятно что обновляются как ядро<br>с модулями, так и бинарники системы.<br> Преимущества в том что можно за один проход обновиться с 6.2-RELEASE до 8.0-RELEASE.<br>Нельзя обновиться, ну скажем, с 6.3-RELEASE до 7.2-STABLE или 8.0-STABLE и тд и тп.<br> Реакция у администраторов разная, одним важно чтобы система была как можно дольше<br>работоспособной в течение обновления - тут пока больше оправдывает себя<br>традиционная технология постепенного накатывания системы с релиза https://opennet.me/openforum/vsluhforumID1/88808.html#2 Wed, 28 Apr 2010 12:47:27 GMT Собственно я предполагал, что имея механизм бинарного обновления, можно вообще перестать пересобирать ядро.<br>Т.е. мы проводим бинарное обновление стандартного ядра GENERIC + всех подгружаемых модулей, которые в стандартное ядро не включены (IPFW, IPSEC и т.д.) и вуаля - у нас модернизированная система.<br><br>В противном случаи, каковы преимущества данного метода перед обычным обновлением исходных кодов?<br><br><br> https://opennet.me/openforum/vsluhforumID1/88808.html#1 Tue, 27 Apr 2010 04:46:30 GMT &gt;Как я понимаю такой механизм работает только для систем работающих с ядром GENERIС<br><br>Это не так. <br><br>freebsd-update состоит из:<br>- бинарного обновления ядра<br>- бинарного обновления юзерленда<br>- обновления исходников системы<br><br>Если апдейт обнаруживает, что текущее ядро не есть GENERIC, он пишет, что после бинарного обновления юзерленда и исходников нужно ручками заново пересобрать текущее ядро. Ну, или любое другое, по вкусу. <br>