Re: Конфигуратор файрволла
13.05.2012 20:15, Victor Wagner пишет:
> On 2012.05.13 at 19:10:53 +0400, "Артём Н." wrote:
>
>> 13.05.2012 18:34, Victor Wagner пишет:
>>> On 2012.05.13 at 16:45:37 +0400, "Артём Н." wrote:
>>>
>>>> 13.05.2012 15:18, Victor Wagner пишет:
>>>>> Кто что посоветует?
>>>> FWBuilder.
>>>> Плюсы:
>>>> 1. Симпатичный ГУИ. Всё достаточно ясно и понятно.
>>> Однозначный минус. Машина позволяет доступ извне, а значит будет
>>> конфигурироваться извне, в том числе и по GPRS.
>> Конфигурировать вы будете тоже на этой машине?
>
> Да, естественно. Потому что то что в руках, может быть телефоном,
> андроидным планшетом, корпоративной рабочей станцией, где ssh-клиент
> есть, а никакого стороннего софта ставить нельзя или вообще машиной из
> интернет-кафе.
Вы будете конфигурировать файрвол на машине из интернет-кафе?
Корпоративные рабочие станции, я так думаю, конфигурируются централизованно.
Конфигурировать планшет - неудобно, в плане того, что неудобно вводить длинные
команды (ну, мне удобно на обычной клавиатуре).
В любом случае, думаю, намного проще сделать скрипт на локальной машине и
скопировать его, куда нужно. Через ssh клиент, например, с целевой машины.
Частности.
В случаях, когда нет под рукой локальной машины...
А так часто приходится конфигурировать файрвол?
> Я и почтовый клиент-то запускаю обычно именно на этой машине. Потому что
> как ни странно работа с почтовым ящиком по imap тормозит сильнее, чем
> работа с интерфейсом mutt-а по ssh.
Опять же, почтовым клиентом вы пользуетесь постоянно.
А файрвол конфигурируете часто?
>> Это интерфейс, прежде всего. Он позволяет создать скрипт.
> Интерфес для создания скриптов называется текстовый редактор.
> Любой другой интерфейс для этой цели по определению хуже.
Мда? Так тогда и dpkg-reconfigure не нужен, например. :-)
Зачем делать вручную то, что возможно автоматизировать?
И зачем использовать универсальный инструмент, там, где его использование не
оправдано?
>>> Большего извращения чем компиляция неудобочитаемого языка в
>>> удобочитаемый представить себе не могу.
>> Не сказал бы, что это извращение. XML - формат хранения.
>
>> Он удобен для описания данных и, следовательно, обработки парсером.
>
> XML неудобен ни для чего.
XML рекомендован W3C. Но я не специалист. Вероятно, вам знать лучше, а разводить
холивор не хочется.
> В качестве формата хранения удобене txt.lzma.
> XML-ем пользуются те, кто не осилил контекстно-свободные грамматики и
> yacc (я уж не говорю про рекурсивно-нисходящие парсеры. Не осиливший
> yacc их тем боллее не осилит).
Это к разработчикам программы. XML - унифицированный формат. Создавать свою
грамматику и парсер под неё или использовать готовые библиотеки или генераторы
парсеров для специфичного языка, - дело разработчиков.
Вероятно, выбор XML был для них чем-то оправдан.
>
>> Целевой формат значения не имеет. Он предназначен, прежде всего, не для чтения,
>
> Если человек использует где-либо формат, предназначенный не для чтения,
> за исключением формата зашифрованных сообщений, его из архитекторов надо
> гнать поганой метлой. Интерпретаторы, умеющие интерпретировать
> человекопонятные языки, научились писать за несколько десятилетий до
> того, как изобрели XML. За прошедшее время в теорию парсеров языков
> программирования вложено столько человеко-лет труда, что написать с
> использованием имеющихся инструментальных средств парсер
> человекочитаемого языка, который бы работал медленнее интерпретатора
> байткода способны только отдельные гениии, вроде Страуструпа.
Ну да, Страуструп, гений, блин. :-|
Но, насчёт байт-кода вы, пожалуй, переборщили. Если в интерпретаторе не
используется компиляция в тот же байт-код, наверное, разбор текста будет
работать, в любом случае медленнее, чем исполнение "шитого кода" например, в
интерпретаторе?
Ну это вопрос и лирическое отступление.
Там-то целевой язык - sh. И скрипт вполне читаем.
>> И так, между прочим, часто делают. Не считая, что тут какие-то извращения есть.
>
> Я знаю. Некоторые, подобно авторам D-Bus, еще и хвалятся тем, что
> используют никому непонятные бинарные форматы, маршаллинг которых
> работает медленнее типичных интерпретаторов скриптовых языков.
Возможно, кое-где и есть переборы.
>> а для обработки интерпретатором. Удобочитаемость, в данном случае, просто
>> дополнительный плюс.
>> По-моему, большим извращением является ещё один язык над CLI iptables.
>>
>>>> 3. Библиотека служб, подсетей, времени и прочего.
>>> Если для такой простой задачи нужны библиотеки, значит имеется
>>> gross misdesign.
>> Я не совсем правильно выразился.
> Я вас правильно понял. Когда человек использует библиотечную функцию, он
> как правило, не понимает что под этим кроется.
o.O Так это получается, что glibc не нужен. И qt? И Boost, и STL (вот в данных
случаях, кажется, мало кто понимает, что под ними кроется).
> Поэтому в столь примитивных случаях библиотеки - зло.
Если серьёзно, там нет зла. Это просто удобство. Читайте не библиотека, а "база
данных" (грубо).
Например, для того, чтобы расшарить каталог для win, мне надо открыть три порта.
Я сейчас не помню какие порты использует NetBIOS, Wins и SMB.
Зачем вбивать порты, когда есть предустановленные профили?
>> Вас смущает GUI?
>> По-моему, визуальное представление гораздо проще воспринимается, чем строки
>> языка (да и есть множество серьёзных графических языков).
> А по-моему нет. Но это уже особенности восприятия.
Не скажите. Схема всегда понятнее кода. Хотя бы потому, что больше возможно
охватить в целом.
> К тому же в Linux
> сейчас нет удобных gui-тулкитов, поскольку XView помер, а ничего
> сравнимого по удоству с openlook-ом никогда не было создано. Авторы всех
> прочих тулкитов начиная с моего любимого Tk и Моtif-а ориентируются на
> копирование интерфейсных решений, придуманых в графических средах с
> кастрированной мышью - либо двухнопочных виндах, либо вообще
> однокнопочной Apple. Хотя для X-ов надо писать так, чтобы без средней
> кнопки работать было неудобно. Потому что только тогда при ее наличии
> будет работать эффективно.
>
>> А ошибки в архитектуре, вряд ли там присутствуют.
> Если они до сих пор присутсвтуюуют в ядре Linux...
Ядро неизмеримо сложнее.
>> Развивается эта штука около 12 лет, работает на множестве ОС, поддерживает
>
> Переносимость - это плохо.
o.O
> Разные ОС имеют разную идеологию ядерных
> файрволов. Потому попытка унифицировать работу с ними приведет к тому,
> что будет использоваться только небольшое общее подмножество
> возможностей. То есть самые вкусные вкусности конкретного файрволла
> окажутся недоступными.
Почему? Достаточно вынести платформозависимую функциональность в библиотеку.
> Да, GUI это тоже касается. Программы с
> "перенсимым GUI" смотрятся чужеродно во всех средах, в которых они
> работают.
Хм... Не всегда.
GUI, конечно, ограничивает возможности.
Но так ли часто требуется что-то специфическое? К тому же, это возможно самому
дописать.
Это просто удобный инструмент. Генератор rc.firewall. Удобство в наглядности,
простоте настройки, переносимости.
Мне нравится.
Reply to: