В сборках FreeBSD 7.1-RELEASE-p4 и 7.0-RELEASE-p11 исправлены две уязвимости:- Проблема безопасности (http://security.freebsd.org/advisories/FreeBSD-SA-09:06.ktim...), вызванная ненадлежащей проверкой величины передаваемого функции ktimer целочисленного аргумента, может быть использована для организации непривилегированным пользователем атаки, которая позволяет изменить содержимое произвольной области памяти ядра, что может быть использовано для выхода из изолированного jail-окружения, обхода системных ограничений или для замены идентификатора пользователя у определенного процесса и его выполнения с правами администратора (root).
- Уязвимость (http://security.freebsd.org/advisories/FreeBSD-EN-09:01.kenv...) в коде системного вызова kenv(2), связанная с отсутствием проверки размера выводимых данных при создании буфера для вывода содержимого всех переменных окружения ядра. Позволяет непривилегированному пользователю инициировать выделение ядром буфера слишком большого...URL: http://security.freebsd.org/advisories.html
Новость: http://www.opennet.me/opennews/art.shtml?num=20881
хорошо :)
двумя багами меньше
> и пересборкой ядрае мае.. это в обязательном порядке? а попроще никак? что пофиксенное ядро слить и поставить в качестве апдейта регигия не позволяет?
>> и пересборкой ядра
>
>е мае.. это в обязательном порядке? а попроще никак? что пофиксенное
>ядро слить и поставить в качестве апдейта регигия не позволяет?Собрать ядро-то что не позволяет? Религия или то, что и плохому танцору?
>Собрать ядро-то что не позволяет? Религия или то, что и плохому танцору?Воистину продакшн решение, да - ядра руками компилячить.И пусть весь мир подождет :)
>>Собрать ядро-то что не позволяет? Религия или то, что и плохому танцору?
>
>Воистину продакшн решение, да - ядра руками компилячить.И пусть весь мир подождет
>:)15 минут...
Это чистого времени. А реально простоя - времени на ребут. Как и при бинарном обновлении что линукса, что винды. При этом получаешь максимально свежий вариант системы прямо тепленьким из репозитория разработчиков с оптимизацией под твою систему. Не нужно ждать пока кто-то соберет тебе бинарник и соизволит оформить патч.Не нравится ? Есть вожможность сделать бинарное обновление. Выбирайте кому что. Удобно.
> Это чистого времени. А реально простоя - времени на ребут.Уговорил - 17 минут.
>Это чистого времени. А реально простоя - времени на ребут.Ага.А некислая нагрузка на боевую систему 15 минут - это так и надо?Или билдить на другой системе?И потом копировать?Тогда не 15 минут будет с добавочной возней пожалуй.И уж конечно прикольно когда админ выступает дрессированым бабуином.Вместо того чтобы спихать машинную работу машине вместо этого сам педалит устранение уязвимостей вместо майнтайнеров :)
>При этом получаешь максимально свежий вариант системы прямо тепленьким из репозитория
Готов поспорить, энтерпрайзники всю жизнь мечтают как самые камикадзы тестировать распоследнее свежезачекиненое добрецо из цвса прям вот на своих боевых серверах.Ага.А ынтерпрайз где так можно - "колхоз имени В. Пупкина" поди называется?
>разработчиков с оптимизацией под твою систему.
Ага, выиграем полпроцента убив массу времени на майнтенанс.Круто.Воистину, мы долго запрягаем а потом быстро ездим.На 0.5% быстрее чем другие :)
>Не нужно ждать пока кто-то соберет тебе бинарник и соизволит оформить патч.
Нормальные майнтайнеры дистров в такой ситуации отдупляются быстро (обычно контрольное время - несколько суток).И уж во всяком случае если что-то не заработает, одно дело если настучат по мозгам *мне* за всякий левак с авангардным супер-дупер-свежаком не оформленным как релиз авторами системы, а другое - если предъва вендору за конкретный релиз конкретной версии некоего софта.Хотя да, если контора называется колхоз имени В.Пупкина, там даунтайм 1 фиг никто не заметит и стоит это $0 примерно :)
>[оверквотинг удален]
>
>>Не нужно ждать пока кто-то соберет тебе бинарник и соизволит оформить патч.
>
>Нормальные майнтайнеры дистров в такой ситуации отдупляются быстро (обычно контрольное время -
>несколько суток).И уж во всяком случае если что-то не заработает, одно
>дело если настучат по мозгам *мне* за всякий левак с авангардным
>супер-дупер-свежаком не оформленным как релиз авторами системы, а другое - если
>предъва вендору за конкретный релиз конкретной версии некоего софта.Хотя да, если
>контора называется колхоз имени В.Пупкина, там даунтайм 1 фиг никто не
>заметит и стоит это $0 примерно :)Хоть раз ядро на FreeBSD пересобирали? Или это чисто поскандалить зашли?
Это известный тролль.
Господа, не кормим тролля, он даже в жизни ядер не собирал.
15 минут на то, 15 на се, да еще чтоб нигде не облажаться и чтоб всегда все идеально вышло или 15 минут превратятся в часы... зашибись, ага.
>15 минут на то, 15 на се, да еще чтоб нигде не
>облажаться и чтоб всегда все идеально вышло или 15 минут превратятся
>в часы... зашибись, ага.Ты о чём говоришь-то, вообще-то? GENERIC от кастомного ядра не можешь отличить?
man diff
тяжелое децтво деревянные игрушки?прекрасно известно что user294 это аноним который сильно ненавидит все операционки на которых не стоит лэйбл GLP, ну и к чему тогда эти высказывания тут? развести флейм с теми кто не в курсе кто такой user294 ?
>тяжелое децтво деревянные игрушки?Не деревянные а 8-битные :P
>прекрасно известно что user294 это аноним
Аноним - это тот у кого в нике написано что он - аноним, имхо :)
>которых не стоит лэйбл GLP,
Какой-то странный у вас лэйбл.
>развести флейм с теми кто не в курсе кто такой user294 ?
Да на самом деле - просто поржать с "продакшн" технологий у некоторых и методов исправлений уязвимостей.И уже ессно побежал чекаутить git ванилы чтобы блин потом при удобном случае получить пиз... ой, простите, ощутить всю прелесть свежака в продакшне.
юзер 294, новость специально для тебя:http://www.opennet.me/opennews/art.shtml?num=20901
То есть фря - это дело рук криворуких программеров, а баги линужа - это дело рук криворуких программеров фри, решивших отомстить?
ну шо, побежал пересобирать ядра? Или пусть вендоры сами найдут твои мегопродакшен серваки и исправят? Или может это лучше сделают красноглазые бздишники, или хакеры.
>>Собрать ядро-то что не позволяет? Религия или то, что и плохому танцору?
>
>Воистину продакшн решение, да - ядра руками компилячить.И пусть весь мир подождет
>:)Ядро компилится фоновым процессом.
он этого не знает. Для него похоже это что-то из серии "переставить Виндоуз"
>он этого не знает. Для него похоже это что-то из серии "переставить
>Виндоуз"Не.
Скорее, он машинально проецирует сложности с пересборкой ядра Linux на пересборку ядра FreeBSD. :))
В Ослинукс: куча флагов; куча заголовочных файлов (нужных приложениям); нестабильный ABI, из-за которого не знаешь, что отвалится после установки нового ядра. :)
давно ли некоторые про солярку так пели? :-D
а в чём собственно сложность в пересборке ядра в линух? или Вы просто не в курсе?
apt-build если что даже в ubuntu есть. (это так,.. для информации. :-DDDDDDD)
к тому же, кто регулярно собирает ядро под линух, время пересборки намного меньше 15-17 минут как правило.... мне вот из xen'а и перегружаться то не надо. вот парадокс!!!:-DDD
>В Ослинукс: куча флагов;высказывание по любому достойноое воспитанного человека!
>куча заголовочных файлов (нужных приложениям);не слышал, чтобы бзд на java перешла... заголовочные файлы говорите? ха! 3-и раза!
>нестабильный ABI, из-за которого не знаешь, что отвалится после установки нового ядра. :)а Вы уверены вообще, что знаете о чём говорите? Вы на чём программируете?... баги, уязвимости, регресии и пр. в бзд появляются в новостях как минимум не реже линуховых... зато они стабильны. что да, то да!:-D как там usb поживает? неужто уже прикрутили? :-D
и о каких ABI Вы вообще говорите? их много знаете ли...
или как всегда - слышал звон, но не музыкант, да и слуха отродясь нет! :-DDDDDDDDDDDDDDDDD
>а Вы уверены вообще, что знаете о чём говорите? Вы на чём
>программируете?...Он на джабе программирует:
http://izen.dev.juga.ru/
>к тому же, кто регулярно собирает ядро под линух, время пересборки намного
>меньше 15-17 минут как правило.... мне вот из xen'а и перегружатьсяЭто как? Ради образования так сказать. Не расскажите способ загрузить новое ядро системы без перезагрузки самой OS?
У ляликса есть такая штука kexec вызовы, там это вполне проворачивается. Смею заявить, юзер264 перестраховщик-лентяй, тот же izen хоть и тяготеет к жабофильству и бздунству, но крайне адекватные посты оставил в этой новости
>Скорее, он машинально проецирует сложности с пересборкой ядра Linux на пересборку ядра
>FreeBSD. :))А у меня нет сложностей - я не пересобираю в продакшне ядра.А зачем мне на себя брать вендоровскую ответственность?Одно дело если предъявы к вендору а другое - если ко мне.И я даже если в лепешку расшибусь, за разумное время не оттестирую пересобранное хотя-бы так же как это могут сделать серьезные конторы-майнтайнеры за тот же срок.У них тупо больше рук, есть инфраструктура для автоматических тестов и прочая.Они могут себе эту роскошь позволить.В отличие от меня.А мне не понятно нафиг мне геморрой с компилом если это можно сбагрить на вендора.
>В Ослинукс: куча флагов; куча заголовочных файлов (нужных приложениям);
>нестабильный ABI,У развития есть и обратная сторона медали.
>из-за которого не знаешь, что отвалится после установки нового ядра. :)
Объясняю для тупых: если вам *хочется* с этим заморочиться - вы можете.При том на практике не так уж оно и сложно и ума даже особо много не надо.А в противном случае - этим занимаются майнтайнеры дистрибутива, а вы получаете готовую систему где ничего не отвалится и как оно работает - худо-бедно протестировано, не на полутора машинах за 15 минут красноглазым дрочером который страдает фигней с тестированием на продакшне свежатины за конторский счет а нормально, как это должно быть сделано - хотя-бы пара дней минимум с нормальным прогоном тестов и т.п..А ваш подход к продакшну годится только для файлопомоек в локалках да роутеров для студенческих общаг.Где если оно подохнет или будет сколько-то там времени тормозить - да и хрен бы с ним.
Воистину, решения для бизнеса от iZEN - это круто! :D
P.S. как максимум могу понять пересбор ядер под свои нужды большой конторой типа яхи у которой есть достаточно ресурсов чтобы адекватно протестировать полученное и прицельно позаниматься тюнингом, выделить некоторое число машин под все это, etc сэкономив на парке серверов потом.А желание взвалить на себя гемор по майнтайнингу таких монстрил на ровном месте я не понимаю.Операционки нынче - достаточно большие и сложные системы.Отвечать головой вместо майнтайнеров лишний раз - неохота.Особенно за всякий свежак.Который с пылу с жару вывален и ... никем не протестирован.Быть первым хорошо, но только не когда ты первый кто отхватил со всей дури граблями в лоб да еще не в тестлабе а в продакшне.При том - некоторые типы дефектов подлые и заметны не сразу.А когда будут заметны - может быть и поздновато уже.Вон тот же ext4 сколько делали и ... оказалось что данные теряет в определенном случае.И не надо втирать про то что бзди пишут какие-то особые боги которые не ошибаются.Пишут их обычные люди.И багов там на мег кода наверняка столько же сколько и у других, плюс-минус погрешности.Люди - это люди.И даже будь они хоть трижды регенты небезызвестного университета, баги это не отменяет, чему подтверждением данная новость.И как-то не больно охота быть в случае продакшна в первых рядах тех кто проверяет не лежат ли на вон том поле грабли :).В тестлабах, тестовых окружениях и прочая - всегда пожалста, если на это дают время и ресурсы.А в продакшне - наф-наф-наф!
Ох сколько написал. По всей видимости у тебя куча свободного времени и сил. Почему так экономишь тогда - не понятно.
>[оверквотинг удален]
>и поздновато уже.Вон тот же ext4 сколько делали и ... оказалось
>что данные теряет в определенном случае.И не надо втирать про то
>что бзди пишут какие-то особые боги которые не ошибаются.Пишут их обычные
>люди.И багов там на мег кода наверняка столько же сколько и
>у других, плюс-минус погрешности.Люди - это люди.И даже будь они хоть
>трижды регенты небезызвестного университета, баги это не отменяет, чему подтверждением данная
>новость.И как-то не больно охота быть в случае продакшна в первых
>рядах тех кто проверяет не лежат ли на вон том поле
>грабли :).В тестлабах, тестовых окружениях и прочая - всегда пожалста, если
>на это дают время и ресурсы.А в продакшне - наф-наф-наф!Нет, ну кто говорит что нужно на курент на продакшен совать? Ето ж обычний плановый патч по секюрити, да и бекпортов с курента на стейбл мало делают и обычно они безопасны. Да, если хочеш екстрима (где не 100% можно еще собрать свежак), то курент самое то =), но не нужно боятся апгрейта стабильной ветки.
>А у меня нет сложностей - я не пересобираю в продакшне ядра. ... А мне не понятно нафиг
>мне геморрой с компилом если это можно сбагрить на вендора.ответственность всё равно на тебе, что ставишь глюкавый линух.
>>В Ослинукс: куча флагов; куча заголовочных файлов (нужных приложениям);
>>нестабильный ABI,
>
>У развития есть и обратная сторона медали.
>
>>из-за которого не знаешь, что отвалится после установки нового ядра. :)
>
>этим занимаются майнтайнеры дистрибутива, а вы получаете готовую систему ...ос виндовс
>и как оно работает - худо-бедно протестировано, не на полутора машинах
>за 15 минут красноглазым дрочером который страдает фигней с тестированием на
>продакшне свежатины за конторский счет а нормально, как это должно быть
>сделано - хотя-бы пара дней минимум с нормальным прогоном тестов и
>т.п..А ваш подход к продакшнуваш подход к продакшену - заплатил в два раза больше и пусть вся ответственность на вендоре? =) а напуркуа твоим же языком тогда нужен ты?
>Вон тот же ext4 сколько делали и ... оказалось
>что данные теряет в определенном случае.неужели признал, что линуж тоже имеет баги?
>И не надо втирать про то
>что бзди пишут какие-то особые боги которые не ошибаются.увы, линуж тоже не боги пишут. и ты не бог, потому что тоже ошибаешься.
>И багов там на мег кода наверняка столько же сколько и
>у других, плюс-минус погрешности.ну и хрен ли бессовестно хаять-то тогда бздю?
>Люди - это люди. И даже будь они хоть
>трижды регенты небезызвестного университета, баги это не отменяет, чему подтверждением данная
>новость.странно - ты вроде такой мудрый, но иногда порешь откровенную чушь. :)
Хотя ещё более странно, что ты не защищаешь венду только потому, что "люди есть люди, и посему венде тоже можно простить баги". Тем более что уж где-где, а поставка "из коробки" с минимальной необходимостью (и возможностью) настроек, и всего за 2К$ для "продвинутого" сервера - т.е. меньше месячной з/п юниксового одмина....
>ответственность всё равно на тебе, что ставишь глюкавый линух.Гнилые отмазки.За выбор системы я готов ответить.А за чужие ляпы и их исправление отвечать ломливо.Пускай дистроклепатели пыжатся, у них ресурсов и времени для тестирования их сборки больше чем у меня.
>ос виндовс
А что - виндовс?Виндовс в энтерпрайзах зачастую юзают, потому что она в конечном итоге может предоставить именно то что нужно в таком как было нужно виде (собственно централизованное руление зоопарком там получше чем у многих других в ряде аспектов).Можно ее сколько влезет ненавидеть но факты от этого не изменятся.У виндовса есть свой ряд проблем, long-standing и не только.Главной является крайне недружественный и жадный вендор выворачивающий руки.Потом - архитектурные решения способствующие модели фиксов "раз в месяц" и ребутам, странные\спорные дефолты по части секурити, несовместимость ни с чем кроме себя толком, зверские цены и нужда лицензировать каждый пук и прочая.И сколько б вы тут не пиндели а энтерпрайзники скорее поюзают винду чем будут ядра перекомпиливать.Нахрен бы им лишний геморрой?На него могут распереться только те кого реально приперло и иначе никак а ресурсы позволяют такую блажь.Таких в общем то не так уж много.Есть 2 типа таких энтерпрайзников: красноглазые придурки не понимающие разницу между тестлабом и дрочерством в ней для своего удовольствия и продакшном и серьезные конторы которые обладают достаточными ресурсами чтобы проверять что там у них накомпилировалось со всеми патчами, ничего ли не отвалилось и так далее - т.е. по сути заниматься майнтайнерством системы самолично.
>ваш подход к продакшену - заплатил в два раза больше и пусть
>вся ответственность на вендоре? =)Не всегда и не везде.Но данный подход тоже имеет право на жизнь.Потому что если взваливать на себя весь геморрой по майнтенансу системы, пупок может и развязаться ненароком.
>а напуркуа твоим же языком тогда нужен ты?
Ну а это не вам решать, имхо, ага?Вот дрочерство с перекомпилом ядер и самопальными тестами за 15 минут опосля этого что "вроде работает" - энтерпрайзникам и правда обычно не нужно :)
>неужели признал, что линуж тоже имеет баги?
Вы наверное удивитесь но любой софт имеет баги и недоработки.В линухе их тоже есть, как и в любом другом софте.Если вы этого не знали - розовые очки это круто, да.
>увы, линуж тоже не боги пишут. и ты не бог, потому что тоже ошибаешься.
А еще 2*2 == 4, прикиньте?И в моем понимании если фикс протестит сперва вендор а потом я - вероятность отхватить проблем много меньше чем если его буду тестить по сути только я.
>ну и хрен ли бессовестно хаять-то тогда бздю?
Да я не хаю бздю строго говоря.Я ржу с энтерпрайзного подхода г-на iZEN и подобных красноглазиков которые в своем фанатизме заходят довольно далеко :)
>странно - ты вроде такой мудрый, но иногда порешь откровенную чушь. :)
На самом деле я просто иногда прикалываюсь над излишне красноглазыми.Хоть это и нехорошо.
>Хотя ещё более странно, что ты не защищаешь венду только потому, что
>"люди есть люди, и посему венде тоже можно простить баги".Защищать неохота - меня соотношение цены и качества там не улыбает последние эн лет а в затяжке гаек вендор зашел слишком далеко.И собственно одна их проблема - в том что вендор на баги реагирует тормозно и неохотно, устраивая регулярные кидки "а вот это мы чинить не будем, купите новую версию - там починим!".
>Тем более что уж где-где, а поставка "из коробки" с минимальной необходимостью
>(и возможностью) настроек, и всего за 2К$ для "продвинутого" сервера -
>т.е. меньше месячной з/п юниксового одмина....Кроме этого еще клиентские лицензии и прочая муть с ограничиловами.А проблем там своих хватает.Тем не менее, заметьте, при моей несимпатии к продукции MS, в энтерпрайзах сия продукция используется и тупо отрицать этот очевидный факт.Насчет минимальной возможноти - а это смотря что.Скажем групповые политики фору тому что есть в *никсах дадут.Правда *никсы тоже в долгу не останутся - платить за воздух и снятие специально впиханых ограничений там не надо а если уж все-таки заплатить вендору, качество саппорта от оного оправдает затраты, чего о MSовском саппорте не скажешь(MS дерет деньги чисто за пластиковые блинчики и какие-то эфемерные права взять в аренду их супер-дупер софт что выглядит слегка нае..ловом).
>>он этого не знает. Для него похоже это что-то из серии "переставить
>>Виндоуз"
>
>Не.
>Скорее, он машинально проецирует сложности с пересборкой ядра Linux на пересборку ядра
>FreeBSD. :))
>В Ослинукс: куча флагов; куча заголовочных файлов (нужных приложениям); нестабильный ABI, из-за
>которого не знаешь, что отвалится после установки нового ядра. :)Великий холиварщик iZEN снова с нами :-)И вновь воюить с Линюхами и User294 :-D
Когда увидел новость, подумал - ну усё. Будет БЗДИ-срач. Зашел. Пусто.
Возрадовался. Но, видимо iZEN-оиды спали в тот момент... Или ядра пересобирали фоновым процессом.
Но, к несчатью проснулись, пересобрались и взыграла уязвлённая гордость в беднягах.
Друг мой. Прекрати фантазировать, пожалуйста. Где ты в пересборке ядра на Линюхах сложности нашел-то?
>>Воистину продакшн решениепофлудить охота? Сегодня с утра на веб-сервере и собрал, и поставил и заребутил. Делов на три копейки. Юзера джаббера даже не заметили перегрузки сервера :)
Если кто-то не в курсе, то сообщаю: для пересборки ядра совсем не обязательно все выключать. Сервер продолжает работать и выполнять свои функции.
Разницу между "собрать ядро + ребут" и "скачать ядро + ребут" я как-то слабо наблюдаю ...
Немного есть - сервер чуть медленнее отвечает на запросы. Но это если нагрузка дикая.
>Немного есть - сервер чуть медленнее отвечает на запросы. Но это если
>нагрузка дикая.Ага, конечно, все ставят сервера с пятикратном запасом по моще.Вот спецом чтоб крЮтым парням было удобно ядра там компилить :D
>>Немного есть - сервер чуть медленнее отвечает на запросы. Но это если
>>нагрузка дикая.
>
>Ага, конечно, все ставят сервера с пятикратном запасом по моще.Вот спецом чтоб
>крЮтым парням было удобно ядра там компилить :DВы собираете ядра на продакшен-сервере? Во время его работы? O_o
Что, разве трудно поднять выделенную станцию централизованного обновления и раздавать готовые/оттестирвоанные бинарники всем продакшен-сервакам с неё, а не мучить каждый сервер пересборкой из исходников? :D
>Вы собираете ядра на продакшен-сервере? Во время его работы? O_oЯ что, псих?У меня все дома.Я просто не пользуюсь в продакшне системами где надо самому компилить ядро.Нахрен мне на *себя* взваливать *вендорскую* ответственность?Я не поклонник Мазоха.
>Что, разве трудно поднять выделенную станцию централизованного обновления
Ага, осталось всех убедить что на это надо вбухать бабло.А нафиг оно надо если в нормальных дистрах бинарные обновления сами приедут а для экономии трафа достаточно кэширующего прокся, который еще и для WWW пригодится?Вот нужду в кэширующей проксе объяснить людям можно.А в компил-станции чисто для компилов... лол :)
>оттестирвоанные бинарники
И насколько вы оттестируете функционал оных за обещаные 15 минут? :)
> в нормальных дистрах бинарные обновления сами приедут# freebsd-update fetch install
привезет бинарные обновления. Если надо, чтобы сами приехали - можно и в cron добавить. Короче, хватить говорить о том, что не знаете.
>>Вы собираете ядра на продакшен-сервере? Во время его работы? O_o
>
>Я что, псих?У меня все дома.Я просто не пользуюсь в продакшне системами
>где надо самому компилить ядро.Нахрен мне на *себя* взваливать *вендорскую* ответственность?Я
>не поклонник Мазоха.вы пользуетесь ядрами по умолчанию - я вас поздравляю! а для меня это не позволительная роскошь.
> что пофиксенное ядро слить и поставить в качестве апдейта регигия не позволяет?Вы что, сливаете и ставите бинарные ядра? :-)))
>> что пофиксенное ядро слить и поставить в качестве апдейта регигия не позволяет?
>
>Вы что, сливаете и ставите бинарные ядра? :-)))man freebsd-update
>>> что пофиксенное ядро слить и поставить в качестве апдейта регигия не позволяет?
>>
>>Вы что, сливаете и ставите бинарные ядра? :-)))
>
>man freebsd-updateэт только обновления в бинарном виде скачать можно, ядро все равно пересобирать нужно
man freebsd-update
>man freebsd-updateдо обновления:
FreeBSD radius.pcb 7.1-RELEASE-p3 FreeBSD 7.1-RELEASE-p3после обновления:
FreeBSD radius.pcb 7.1-RELEASE-p3 FreeBSD 7.1-RELEASE-p3после пересборки ядра:
FreeBSD radius.pcb 7.1-RELEASE-p4 FreeBSD 7.1-RELEASE-p4
>>man freebsd-update
>
>до обновления:
>FreeBSD radius.pcb 7.1-RELEASE-p3 FreeBSD 7.1-RELEASE-p3
>
>после обновления:
>FreeBSD radius.pcb 7.1-RELEASE-p3 FreeBSD 7.1-RELEASE-p3
>
>после пересборки ядра:
>FreeBSD radius.pcb 7.1-RELEASE-p4 FreeBSD 7.1-RELEASE-p4freebsd-update обновляет только ядро GENERIC
>freebsd-update обновляет только ядро GENERICа кто им пользуется в продакшене?
ну например я и что? если там не нужен ipsec например то в GENERIC есть все что нужно, времена когда делали кучу строк с nodevice давно прошли, уже это не актуально
p.s. user294 - ответь на вопрос http://www.opennet.me/openforum/vsluhforumID3/50562.html#148 мне чисто так, поржать чтобы ;)
чтото я тебя не пойму то СуперКонтора то денег не хватает на lo-end сервер для сборки всякой херни.
>ну например я и что? если там не нужен ipsec например то
>в GENERIC есть все что нужно, времена когда делали кучу строк
>с nodevice давно прошли, уже это не актуальнода хотя бы:
options IPFIREWALL
options IPFIREWALL_FORWARD
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=10
options IPFIREWALL_DEFAULT_TO_ACCEPToptions DUMMYNET
options MROUTING
options IPDIVERToptions INCLUDE_CONFIG_FILE
options QUOTA
>[оверквотинг удален]
>options IPFIREWALL_VERBOSE_LIMIT=10
>options IPFIREWALL_DEFAULT_TO_ACCEPT
>
>options DUMMYNET
>options MROUTING
>options IPDIVERT
>
>options INCLUDE_CONFIG_FILE
>
>options QUOTAipfw.ko (при желании собирается с forward не меняя конфига GENERIC, т.е. можно будет обновляться через freebsd-update, остальное настраивается через sysctl)
dummynet.ko
ipdivert.ko
ip_mroute.ko
Т.е. из перечисленного GENERIC нужно менять только для включения квот.
Бывают, конечно, случаи когда необходимо пересобирать ядро, но в большинстве случаев на сервере достаточно GENERIC. Времена когда из ядра выкидывали все ненужные драйвера чтобы сэкономить пару мегабайт памяти действительно давно в прошлом.
это я выдернул из конфига что под руку попалось. MROUTING с IPDIVERT редко где нужно, а так, да, нехватает QUOTA, в 7.0, к примеру, нужен SCHED_ULE, фаирвол предпочитаю ACCEPT именно в ядре, а то, мало ли, сервера удаленные. опять же, порой: PAE, где-то DEVICE_POLLING, ZERO_COPY_SOCKETS...
Note that updates are only available
if they are being built for the FreeBSD release and architecture being
used; in particular, the FreeBSD Security Team only builds updates for
releases shipped in binary form by the FreeBSD Release Engineering Team,
e.g., FreeBSD 6.1-RELEASE and FreeBSD 6.2-RC1, but not FreeBSD 6.2-STABLE
or FreeBSD 7.0-CURRENT.а у меня, к примеру, 7-STABLE ...
я не знаю как у некоторых ядро собирается по 15 минут, а у меня за 15 минут мир например собирается, а ядро собирается меньше 5 минут. Нашли что с чем сравнивать, сравните количество дыр в линуксе с количеством дыр во фре. Просто количественно за месяц например.
>а ядро собирается меньше 5 минут.А если Cray подогнать - тогда и за 2 минуты соберется.И даже сервить непозорно сможет.Одна незадача - дофига бабла стоит.
>в линуксе с количеством дыр во фре.
Количество не количество а новость - о дырах.Во фре.Посему вопить про супер-секурность будет достаточно неубедительно.
>>в линуксе с количеством дыр во фре.
>
>Количество не количество а новость - о дырах.Во фре.Посему вопить про супер-секурность
>будет достаточно неубедительно.ну пока только 1 троль тут вопит. на его сообщение я и отвечаю;) кстати, сплойт уже есть чтобы вылезти из jail например? вот под лайнакскернел с ползапроса в поисковике найдется то что поможет непривилигированному юзеру стать рутом ;)
юзер 294, новость специально для тебя:http://www.opennet.me/opennews/art.shtml?num=20901
45 дыр в ядре линужа. Рекорд? =) Или секурность по-линусовски?
То есть фря - это дело рук криворуких программеров, а баги линужа - это дело рук криворуких программеров фри, решивших отомстить?
ну шо, побежал пересобирать ядра? Или пусть вендоры сами найдут твои мегопродакшен серваки и исправят? Или может это лучше сделают красноглазые бздишники, или хакеры.
>ну шо, побежал пересобирать ядра? Или пусть вендоры сами найдут твои мегопродакшен
>серваки и исправят? Или может это лучше сделают красноглазые бздишники, или
>хакеры.Ага, ломанулся пересобирать. Откройте для себя Ksplice. http://ksplice.com/
P.S: Кстати, а во FreeBSD существует механизм обновлений работающего ядра без перезагрузки?
Только не надо говорить, что во Фришном ядре меньше багов, поэтому такой софт там не нужен.
>>ну шо, побежал пересобирать ядра? Или пусть вендоры сами найдут твои мегопродакшен
>>серваки и исправят? Или может это лучше сделают красноглазые бздишники, или
>>хакеры.
>
>Ага, ломанулся пересобирать. Откройте для себя Ksplice. http://ksplice.com/
>P.S: Кстати, а во FreeBSD существует механизм обновлений работающего ядра без перезагрузки?
>
>Только не надо говорить, что во Фришном ядре меньше багов, поэтому такой
>софт там не нужен.а в линухе есть portaudit?
В линуксе нет системы портов.
>В линуксе нет системы портов.генту посмотрите. и смысла это не меняет, в portaudit ключевое слово совсем даже не port.
Эксплоит для эскалации привелегий есть уже.
Что касается обновления ядра, даже с пересборкой - проблема надумана.
man nice
man renice
>Эксплоит для эскалации привелегий есть уже.если тот что на милворме то он у меня вместо рута дает вот этовот:)
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x20001036
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc09668c7
stack pointer = 0x28:0xe9cf4bf0
frame pointer = 0x28:0xe9cf4c14
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 56970 (a.out)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 12h20m36s
Я вижу, тут собралось много умных фряшников.
Посему хотелось бы задать вот такой вопрос.В ведении нашего отдела состоит порядка 50 серверов. По масштабам хостинга это средний ближе к мелкому.
На 16 машинах дебиян, на остальных центос. Системы пакетные и спокойно обновляются по крону. Узрев в логах обновления что-нибудь глобальное типа linux-kernel или glibc, мы устраиваем машинкам внеплановое техобслуживание (проще говоря, пылесосинг) с выключением. За два года ни одной проблемы при включении.А вот теперь представьте, что у вас 50 машин с фряхой. И на всех надо срочно обновить ядро. Что бы вы сделали в этой ситуации?
(Как я понял из комментов выше, freebsd-update не катит.)И вообще, существуют ли во фряхе _надежные_ методы _автоматизированного_ накатывания security updates?
Доброго дня.Признаюсь, с таким количеством машин я не работал и пока не задумывался над этим вопросом.
Предполагаю, что все Ваши сервера однотипные и софт на них скорей всего стоит одинаковый.
Я бы скорей всего смотрел в сторону синхронизацией файлов (rsync) или загрузки нод по сети.
Но тут конечно спорить не могу, задачи такой не стояло и оптимального решения я для себя не нашел.С уважением, Анатолий.
> А вот теперь представьте, что у вас 50 машин с фряхой. И на всех надо срочно обновить ядро. Что бы вы сделали в этой ситуации?Мастер-сервер дистрибутивов надо держать в такой ситуации. Или загружать все сервера с одного сервера (сетевая загрузка для ферм).
> (Как я понял из комментов выше, freebsd-update не катит.)
Почему?
> И вообще, существуют ли во фряхе _надежные_ методы _автоматизированного_ накатывания security updates?
freebsd-update по крону или в автозагрузке, если используются только -RELEASE-версии FreeBSD.
Обновление ПО (как бы из портов, но без локальной компиляции, насколько возможно) == автомонтирование по NFS каталога $PACKAGES мастер-сервера и бинарное обновление установленных пакетов — фактически со скоростью передачи файлов по сети.
>Мастер-сервер дистрибутивов надо держать в такой ситуации. Или загружать все сервера с одного сервера (сетевая загрузка для ферм).У нас все-таки не совсем ферма. Сервера отличаются по назначению и, соответственно, по набору и версиям установленного софта. В свое время было предложение перевести на сетевую загрузку, но от него отказались как от негибкого и премногогеморройного.
>> (Как я понял из комментов выше, freebsd-update не катит.)
>Почему?Ну там было написано, что оно обновляет только GENERIC-сборку ядра, которая в продакшне практически не используется.
Предложенная в конце идея в целом звучит неплохо. Сейчас, к сожалению, протестить не могу.
Как я понимаю, это костылевый аналог локального репозитария?
>Я вижу, тут собралось много умных фряшников.Нет. :)
>В ведении нашего отдела состоит порядка 50 серверов. По масштабам хостинга это
>средний ближе к мелкому.
>На 16 машинах дебиян, на остальных центос. Системы пакетные и спокойно обновляются
>по крону. Узрев в логах обновления что-нибудь глобальное типа linux-kernel или
>glibc, мы устраиваем машинкам внеплановое техобслуживание (проще говоря, пылесосинг) с выключением.У меня тож центось обновляется кроном, а вот фришные сервера я не трогаю и патчи накладываю исключительно руками. Благо делать это нужно раза два в год и даже на 50 машинах делается легко и быстро.
>За два года ни одной проблемы при включении.
>
>А вот теперь представьте, что у вас 50 машин с фряхой. И
>на всех надо срочно обновить ядро. Что бы вы сделали в
>этой ситуации?Весь вопрос в железе. Если оно однотипно, то просто компилишь на тестовом серваке ядро и разливаешь по серверам, делов то на полчаса. Да, сразу хочется уточнить, что полчаса не простоя, а работы. Простой исключительно на ребут.
Опять же, чтобы подчеркнуть, я все лишнее в ядро не пихаю, только железо. Собственно, санки используют ту же идеалогию, одно железо на всех и нет проблем с ядрами. :)>(Как я понял из комментов выше, freebsd-update не катит.)
>
>И вообще, существуют ли во фряхе _надежные_ методы _автоматизированного_ накатывания security updates?Написали выше, но я предпочитаю все-таки руками, по стариковски. Порты обновляются по крону, а ядра собираются и разливаются исключительно после тестирования. А то бы прецеденты.
Боже, я думал User294 мозгов понабрался и затух со своим бредом про FreeBSD, ан нет, ситуация все хуже и хуже.