Мой сотрудник по моему заданию настраивает сервер на платформе FreeBSD (8.0)Задачи совершенно типовые - на сервере будет 2 интерфейса, один глобальный от ISP, один частная сеть 192.168.x.x. Надо - давать (для избранных приложений) NAT, PAT для проброски запросов к внутренним портам, web/FTP прокси и почтовый сервер (это что касается чисто сетевых задач) (возможно плюс OpenVPN)
вопрос - можно ли все это сделать БЕЗ пересборки ядра (и если можно, то как именно, хотя бы примерно)
я вот полностью уверен что на FreeBSD 6.2 еще три года назад решал аналогичные задачи и все работало без всяких перекомпиляций ядра, чисто опциями дистрибутива и затем редактированием конф. файлов все эти задачи решались
прошу прокомментировать, какой из подходов более (или единственно) правильный .. нужно так установить ОС, чтобы переустановка на голый ПК по инструкции происходила как можно быстрее.
заранее спасибо !
> прошу прокомментировать, какой из подходов более (или единственно) правильный .. нужно
> так установить ОС, чтобы переустановка на голый ПК по инструкции происходила
> как можно быстрее.Я думаю, вам стоит или сменить место работы или не вмешиваться в работу подчиненных.
Без пересборки ядра включить ipfw ой как будет непросто и нестабильно.
>> прошу прокомментировать, какой из подходов более (или единственно) правильный .. нужно
>> так установить ОС, чтобы переустановка на голый ПК по инструкции происходила
>> как можно быстрее.
> Я думаю, вам стоит или сменить место работы или не вмешиваться в
> работу подчиненных.
> Без пересборки ядра включить ipfw ой как будет непросто и нестабильно.видимо Вы как раз "подчиненный" ;)) вмешиваться никто и не собирался, а вот если про контроль забывать - это точно, впору место работы менять.
Вы можете (если не трудно) привести ссылку на какую-нибудь статью, HOWTO, FAQ, ответ на форуме, где Ваше высказывание было бы аргументировано ?
заранее спасибо
> видимо Вы как раз "подчиненный" ;)) вмешиваться никто и не собирался, а
> вот если про контроль забывать - это точно, впору место работы
> менять.Вы ошибаетесь.
Как правильно заметили ниже, если знаете как правильно - то пишите инструкцию.> Вы можете (если не трудно) привести ссылку на какую-нибудь статью, HOWTO, FAQ,
> ответ на форуме, где Ваше высказывание было бы аргументировано ?Вдумчиво читаем про подгружаемые модули
> Мой сотрудник по моему заданию настраивает сервер на платформе FreeBSD (8.0)
> вопрос - можно ли все это сделать БЕЗ пересборки ядра (и если
> можно, то как именно, хотя бы примерно)Все зависит от ньюансов поставленной Вами задачи.
В общем случае, это сделать нельзя.> я вот полностью уверен что на FreeBSD 6.2 еще три года назад
> решал аналогичные задачи и все работало без всяких перекомпиляций ядра, чисто
> опциями дистрибутива и затем редактированием конф. файлов все эти задачи решалисьЕсли "полностью уверены", то покажите Вашему сотруднику, как это делается и
напишите инструкцию на будущее.> прошу прокомментировать, какой из подходов более (или единственно) правильный .. нужно
> так установить ОС, чтобы переустановка на голый ПК по инструкции происходила
> как можно быстрее.Правильный подход тот, который обеспечивает нужный результат.
решать-то я решал, но там использовался не IPFW (как я сейчас увидел, заглянув в свои записи) а связка ipfilter/ipnat.не особо-то знаю в чем разница между этими средствами (ipfilter и ipfw), если кто-то пояснит, буду признателен (интересует не теоретическая разница, а разница с точки зрения потребителя этих продуктов, т.е. админа - что можно сделать с помощью одного из этих продуктов такого, что нельзя сделать с помощью другого).
>> Мой сотрудник по моему заданию настраивает сервер на платформе FreeBSD (8.0)
>> вопрос - можно ли все это сделать БЕЗ пересборки ядра (и если
>> можно, то как именно, хотя бы примерно)
> Все зависит от ньюансов поставленной Вами задачи.
> В общем случае, это сделать нельзя.я конечно не оспариваю данное утверждение..
но вот сейчас интереса ради страницу IPFW на wikipedia открыл - там английским по белому написано что
"IPFW можно использовать как в виде загружаемого модуля ядра, так и встроенным в ядро. при этом использование в виде загружаемого модуля всячески рекомендуется". т.е. якобы сами разработчики пакета (или ОС) не рекомендуют его встраивать в ядро.вы же утверждаете ровно противоположное. интересно понять, почему.
>> я вот полностью уверен что на FreeBSD 6.2 еще три года назад
>> решал аналогичные задачи и все работало без всяких перекомпиляций ядра, чисто
>> опциями дистрибутива и затем редактированием конф. файлов все эти задачи решались
> Если "полностью уверены", то покажите Вашему сотруднику, как это делается и
> напишите инструкцию на будущее.
>> прошу прокомментировать, какой из подходов более (или единственно) правильный .. нужно
>> так установить ОС, чтобы переустановка на голый ПК по инструкции происходила
>> как можно быстрее.
> Правильный подход тот, который обеспечивает нужный результат.
>> Все зависит от ньюансов поставленной Вами задачи.
>> В общем случае, это сделать нельзя.
> я конечно не оспариваю данное утверждение..
> но вот сейчас интереса ради страницу IPFW на wikipedia открыл - там
> английским по белому написано что
> "IPFW можно использовать как в виде загружаемого модуля ядра, так и встроенным
> в ядро. при этом использование в виде загружаемого модуля всячески рекомендуется".
> т.е. якобы сами разработчики пакета (или ОС) не рекомендуют его встраивать
> в ядро.
> вы же утверждаете ровно противоположное. интересно понять, почему.Еще раз повторяю, все зависит от ньюансов задачи, которую Вы поставили Вашему сотруднику.
Не все опции kernel могу добавлятся с помощью загружаемых модулей или изменятся
с помощью sysctl .Резон в пересборке kernel очень часто имеет место быть, и не только из-за IPFW.
Спросите у Вашего сотрудника, с какой целью он это делает?
Или дождитесь результата, когда Ваш сотрудник выполнит ваше задание.
Не надо ему мешать. :-)
я вот и пытаюсь от него добиться, с какой целью он это делает... и пока не могу внятного ответа услышать, увы.а что касается "решить задачу" - одно из требований как раз состоит в том что создать массив инструкций по настройке ОС под конкретные нужды, таких, чтобы оная (в случае чего) могла быть установлена с нуля за как можно более короткое время. пересборка ядра в этом смысле все портит. если бы не это, мне возможно было бы все равно.
лично для меня более чем странно, что официальный дистрибутив ОС, специально созданной для решения серверных задач, в т.ч. по пропуску трафика из частной сети в глобальную и навстречу, вдруг бы да и не позволял "из коробки" добиться нужного поведения.
никаких "нюансов" в моих требованиях нет абсолютно. нужно чтобы на данном ПК могли работать Squid и Postfix (причем это и без всяких файрволов решается легко), плюс некоторым экзотическим приложениям типа Oracle-клиента нужно дать возможность подключаться к определенным серверам в глобальном нете на определенные диапазоны портов и
устанавливать сессии (иными словами NAT+правила разрешения доступа).
все что здесь описано у меня уже работает причем на ipchains и на стандартном ядре.в принципе это все. PAT (проброска порта во внутреннюю сеть) это уже так до кучи, в нем я тоже проблем никаких не вижу, хотя могу и ошибаться конечно.
>[оверквотинг удален]
>> вы же утверждаете ровно противоположное. интересно понять, почему.
> Еще раз повторяю, все зависит от ньюансов задачи, которую Вы поставили Вашему
> сотруднику.
> Не все опции kernel могу добавлятся с помощью загружаемых модулей или изменятся
> с помощью sysctl .
> Резон в пересборке kernel очень часто имеет место быть, и не только
> из-за IPFW.
> Спросите у Вашего сотрудника, с какой целью он это делает?
> Или дождитесь результата, когда Ваш сотрудник выполнит ваше задание.
> Не надо ему мешать. :-)
> лично для меня более чем странно, что официальный дистрибутив ОС, специально созданной
> для решения серверных задач, в т.ч. по пропуску трафика из частной
> сети в глобальную и навстречу, вдруг бы да и не позволял
> "из коробки" добиться нужного поведения.Дистрибутив FreeBSD - это универсальный конструктор, из которого можно смастерить
все что угодно, а не "коробочное решение", как Вы думаете."Из коробки" сервера от MS быстро заводяться, но потом долго доводятся "до ума".
Сервер на FreeBSD, который делается под конкретные нужды и сервисы,
ставится довольно долго, но если настройка сделана правильно и все оттестировано,
то дальше можно "спать спокойно.
Если же сервер на FreeBSD просто "клонируется", то время адаптации сильно
сокращается.> никаких "нюансов" в моих требованиях нет абсолютно. нужно чтобы на данном ПК
> могли работать Squid и Postfix (причем это и без всяких файрволов
> решается легко)Transparent proxy (squid) заказывали?
> я вот и пытаюсь от него добиться, с какой целью он это
> делает... и пока не могу внятного ответа услышать, увы.Для пересборки ядра есть необходимость, потому что исо был создан хз когда, поэтому при каждой новой установке обязательно обновляю исходники , ну и пересборка ядра и мира.
>> я вот и пытаюсь от него добиться, с какой целью он это
>> делает... и пока не могу внятного ответа услышать, увы.
> Для пересборки ядра есть необходимость, потому что исо был создан хз
> когда, поэтому при каждой новой установке обязательно обновляю исходники , ну
> и пересборка ядра и мира.не обязательно. если использовать GENERIC ядро, то можно пользоваться freebsd-update
> не обязательно. если использовать GENERIC ядро, то можно пользоваться freebsd-updateСовмещаю полезное с приятным, ядро - под задачи... А обновляться надо, вспоминаю как прыгал вокруг mpd5 и неявными глюками netgraph и dummynet и кривоватым драйвером em..
да, возможно
kldload ipfwтем более, что в 8ке для ipfw появился ядерный нат, использовать natd больше необходимости нет и вставлять опцию divert в ядро, соотвественно, тоже.
kldload ipfw
kldload ipfw_nat
или kldload ipdivert
kldload dummynet
ipfw_enable="YES"
firewall_nat_enable="YES"
или natd_enable="YES"
dummynet_enable="YES"лучше или хуже модулем не знаю, в ядре привычней.
> kldload ipfw
> kldload ipfw_nat
> или kldload ipdivert
> kldload dummynet
> ipfw_enable="YES"
> firewall_nat_enable="YES"
> или natd_enable="YES"
> dummynet_enable="YES"стоп,стоп, стоп. при чем здесь dammynet? или Вы про divert?
согласен, что забыл указать, что ядерный нат тоже необходимо подгружать
dummynet не при чем. можно и без него, так к слову.
> kldload ipfw
> kldload ipfw_nat
> или kldload ipdivert
> kldload dummynet
> ipfw_enable="YES"
> firewall_nat_enable="YES"
> или natd_enable="YES"
> dummynet_enable="YES"
> лучше или хуже модулем не знаю, в ядре привычней.у модуля свои будут ограничения, но раз руководитель спешит, то пусть сам потом отгребывает последствия.
>> лучше или хуже модулем не знаю, в ядре привычней.
> у модуля свои будут ограничения, но раз руководитель спешит, то пусть сам
> потом отгребывает последствия.какие ограничения и что придется отгребывать?
>>> лучше или хуже модулем не знаю, в ядре привычней.
>> у модуля свои будут ограничения, но раз руководитель спешит, то пусть сам
>> потом отгребывает последствия.
> какие ограничения и что придется отгребывать?например MAXUSERS и ессно лимит на максимальное количество открытых файлов.
>>>> лучше или хуже модулем не знаю, в ядре привычней.
>>> у модуля свои будут ограничения, но раз руководитель спешит, то пусть сам
>>> потом отгребывает последствия.
>> какие ограничения и что придется отгребывать?
> например MAXUSERS и ессно лимит на максимальное количество открытых файлов.ну вообще-то мне хотелось услышать именно про модули.
назовите, плз, ситуацию, когда maxusers необходимо менять вручную. просто ни разу его изменять не доводилось.
максимальное количество открытых файлов не требуется определять через ядро - оно замечательно изменяется в любое время через sysctl
>>>>> лучше или хуже модулем не знаю, в ядре привычней.
>>>> у модуля свои будут ограничения, но раз руководитель спешит, то пусть сам
>>>> потом отгребывает последствия.
>>> какие ограничения и что придется отгребывать?
>> например MAXUSERS и ессно лимит на максимальное количество открытых файлов.
> ну вообще-то мне хотелось услышать именно про модули.
> назовите, плз, ситуацию, когда maxusers необходимо менять вручную. просто ни разу его
> изменять не доводилось.значит у вас сервера не нагружены
> максимальное количество открытых файлов не требуется определять через ядро - оно замечательно
> изменяется в любое время через sysctlмногие программы игнорируют эти опции
приходится патчить сорсы системы, чтобы увеличить лимиты.
> значит у вас сервера не нагруженыугу. но вряд ли топикстартеру потребуется настолько настраивать сервера. да и пограничные сервера не требуют таких тонких настроек
>> максимальное количество открытых файлов не требуется определять через ядро - оно замечательно
>> изменяется в любое время через sysctl
> многие программы игнорируют эти опции
> приходится патчить сорсы системы, чтобы увеличить лимиты.какие, если не секрет?
и все таки, какие есть ограничения для модулей по сравнению с вкомпиленым в ядро? кроме того, что в последнем случае не тратится времени на переключение контекста
Большинство мануалов в инете относятся к версии 4-ой, в которой монолитное ядро и плавно перетекают в мануалы для старшие версии, которые уже имеют модульное ядро,повторяя пересборку ядра, в то же время для этих версий модуль можно загрузить различными способами от kldload до соответствующих опций в /boot/loader.conf, /etc/rc.conf, включая и опции ядра с его перекомпиляцией, все это приводит к одному и тому же необходимый модуль оказывается в памяти ... Что касается нагруженного сервера и его тьюнинга, то это совсем другая история...
> Большинство мануалов в инете относятся к версии 4-ой, в которой монолитное
> ядро и плавно перетекают в мануалы для старшие версии, которые
> уже имеют модульное ядро,повторяя пересборку ядра, в то же время для
> этих версий модуль можно загрузить различными способами от kldload до соответствующих
> опций в /boot/loader.conf, /etc/rc.conf, включая и опции ядра с его перекомпиляцией,
> все это приводит к одному и тому же необходимый модуль оказывается
> в памяти ... Что касается нагруженного сервера и его тьюнинга, то
> это совсем другая история...спасибо, кэп,но я в курсе :)
может что-то Lavr скажет по этому поводу?
> может что-то Lavr скажет по этому поводу?в смысле?
Есть определенные(теоретические) за и против модульности и монолитности ядра,
технологически - модульное ядро существенно удобней и гибче, функциональность не теряется.
Не случайно современные OS давно переключились с монолитного ядра на модульное, в том
числе и FreeBSD.
Все что можно делать без пересборки ядра, логичней делать без пересборки, экономия
времени и сил, но системы не идеальны, даже рекомендуемые продакшн релизы.Есть задача: ее нужно сделать, остальное зависит от условий и требований, от того
какие они и следует плясать, на мой взгляд.
Если в требованиях есть баллы и время, то следовать им. Если задача выполнена, то
она ВЫПОЛНЕНА, остальное зависит от граничных условий, требований и баллов.
Понятно что есть изменяемые ядерные переменные и неизменяемые:
- неизменяемые только через loader.conf во время загрузки
- изменяемые в процессе работы
это известно, патчи потребуют пересборки и перезагрузки, тут нечего объяснять.прим: чтобы быть в курсе тонкостей той или иной OS, нужно следить за ее разработкой,
это тоже следует учитывать, если работник реализовал задачу в соответствии с требованиями,
он ее выполнил, хоть на базе MS, хоть на базе Linux, Solaris, xBSD, задача - решена,
в срок уложились, требования выполнили. Остальное как уже было сказано, зависит от
условий и требований, imho.