К сожалению, никакой конструктивной критики предложить не могу. Могу только описывать с печальными примерами из своего и окружающего опыта, почему данное ненужно действительно не нужно.

1. Для тех, кто знает iptables ещё со времён ipchains, никакие надстройки над ним не нужны. Лучше однообразный и примитивный скрипт с кучей повторений, чем этот ужасный самопально-велосипедный синтаксический сахар. Возьмите у любого админа настройки чего-то сложного на сети из тысяч компов. Там обычное перечисление правил с коментами. И всё понятно любому его коллеге. За свой метаязык админа поубивали бы. Т.е. длинными списками iptables вполне можно обойтись.
2. Самопальный метаязык над iptables не нужен. Лучше мучаться до тех пор, пока в iptables не поменяют синтаксис или не прикрутят к нему штатный метаязык из коробки, но лишь бы не самопал. Например, над TeX есть стандартный штатный метаязык LaTeX. LaTeX — нужен. А над LaTeX некоторые пытались внедрить LyX. LyX — не нужен. Если при первом взгляде на LyX человек этого не понимает, то объяснять бесполезно. Пусть пройдёт через все шишки сам: одним набором через графинтерфейс не отделаться, нужно изучать вставки LyX, под ним лезть вставками в LaTeX, пока не закончится тем, что проще выучить LaTeX и всё.
3. Метаязыки и метасинтаксис на шелле особенно не нужны. Он не для этого.
4. Выжимать из шелла что-то слишком сложное не нужно. Это может дойти до того, что в нём пытаются городить хитрые парсеры, сложные функции, эмулированные объекты, подгружаемые библиотеки, а в итоге переходят на питон, перл, руби или что-то подобное, в чём можно поддерживать большой сложный проект. Шелл — для простого, метаязык и велосипедный синтаксис на нём сложно поддерживать, как и любые большие сложные проекты. После очередного обновления системы вам придётся перепроверять все скрипты, параметры и пр., что было проще сделать в «тупом» скрипте без хитрой логики внутри. Любой sed, awk, grep и пр. вас могут подставить, хуже того, если это будет незаметно. Шелл — это простой склеиватель утилит, не надо из него пытаться сделать полноценный скриптовый язык программирования.

Т.е. иногда более высокие абстракции и автоматизация — полезны. Но в случаях, подобных вашему, на поддержание «упрощающего» синтаксиса в перспективе будет потрачено больше усилий, чем на использование стандартного. Это как эмуляция экскаватора с помощью лопаты, колеса, верёвки и прочих подручных средств: и котлован не выроете, и нормальный экскаватор не создадите. Только время потратите впустую.

Смиритесь с этим. Или напишите полную альтернативу iptables на уровне утилиты и ядра. Только не скриптовые костыли.

Сколько пришлось видеть такого пионерства, которое себя не оправдало, даже сам когда-то таким страдал :)

Тоже симптоматично. С какого-то предела, проще выучить чуть более длинные команды, чем поддерживать массу самопальных алиасов.

Жесть какая. Если бы я перешёл на систему с pf, то выучил бы именно его синтаксис, а не писал бы метаязык для работы с ним (да ещё и на шелле!), эмулирующий более привычный мне iptables. Это всё равно, что к офисному пакету придумывать эмулятор LaTeX и наоборот. Выучите оба, если нужно, но не скрещивайте в самопального монстра.

Хотя, возможно, хорошо, что вы со своей упоротостью только скриптоманией страдаете, но не пишите коммиты в утилиты и в ядро, а то вот узнает Леннарт Поттеринг про ваши идеи и запихает iptables в systemd. Тогда всё, приехали. Судя по описанию поставленных целей, начальная стадия синдрома Поттеринга у вас уже заметна. Хотя это не буквально всё про вас. Просто приходилось сталкиваться с такими улучшателями, которые вредные улучшения красочно и якобы убедительно расписывают как полезные и с большим энтузиазмом пропихивают.

allow_out(){
    # This function allows outgoing traffic and the corresponding replies
    # The network myIP/24 is blocked
    local intf=$1
    local our_proto=$2
    local srcIP=$3    # local IP
    local dstIP=$4    # remote IP
    local dstPORT=$5    # remote port
    local our_user=$6
    if [ $dstIP = all ]; then
        if [ $our_proto = tcp ]; then
            iptables  -A OUTPUT -j ACCEPT -o $intf -p tcp -s $srcIP \
                ! -d $srcIP/24 -m tcp --dport $dstPORT -m owner \
                --uid-owner $our_user
            iptables  -A INPUT  -j ACCEPT -i $intf -p tcp ! -s $srcIP/24 \
                -m tcp --sport $dstPORT -d $srcIP -m state --state ESTABLISHED
        elif [ $our_proto = udp ]; then
            iptables  -A OUTPUT -j ACCEPT -o $intf -p udp -s $srcIP \
                ! -d $srcIP/24 -m udp --dport $dstPORT -m owner \
                --uid-owner $our_user
            iptables  -A INPUT  -j ACCEPT -i $intf -p udp ! -s $srcIP/24 \
                -m udp --sport $dstPORT -d $srcIP -m state --state ESTABLISHED
        fi
    else
        if [ $our_proto = tcp ]; then
            iptables  -A OUTPUT -j ACCEPT -o $intf -p tcp -s $srcIP \
                -d $dstIP -m tcp --dport $dstPORT -m owner \
                --uid-owner $our_user
            iptables  -A INPUT  -j ACCEPT -i $intf -p tcp -s $dstIP \
                -m tcp --sport $dstPORT -d $srcIP -m state --state ESTABLISHED
        elif [ $our_proto = udp ]; then
            iptables  -A OUTPUT -j ACCEPT -o $intf -p udp -s $srcIP \
                -d $dstIP -m udp --dport $dstPORT -m owner \
                --uid-owner $our_user
            iptables  -A INPUT  -j ACCEPT -i $intf -p udp -s $dstIP \
                -m udp --sport $dstPORT -d $srcIP -m state --state ESTABLISHED
        fi
    fi
}

allow_out lo tcp 127.0.0.1 127.0.0.1 8118 user

allow_out lo tcp 127.0.0.1 127.0.0.1 9050 user

allow_out lo tcp 127.0.0.1 127.0.0.1 6600 user

Меньше времени тратить на женщин и людей глупее себя.

Так. Это я говорю, после того как эти функции писал (и даже сам предлагал ровно с той же логикой, что и вы) и частично поддерживал скриптовые проекты на десятки тысяч строк кода.

Я знаю когда их изобрели, знаю, что консоль — это телетайп с перфолентами, знаю, что dd — это диск-дупликатор, tar — это tape archiver и т.д. И сколько лет этому всему, и что оно стабильно и якобы не меняется, что на бумаге и в книгах это так. А на практике — нет. У меня реально разваливались скрипты из-за этого.

Вы меня совсем за непонимающего идиота держите. Естественно, вы его понимаете, иначе не написали бы скрипт, но iptables вам не нравится на уровне подхода. Так вот, я бы выучил на уровне не просто понимания, а принятия подхода (пусть и плюясь от необходимости его использования). Или бы коммитил в проект. Но костыли для самопального перевода одной системы понятий в другую — не нужны. Их поддержка отнимает массу времени.

Ну как ещё вам объяснить. У меня была куча скриптов для GnuPG, с кучей общих функций, псевдобиблиотек, менюшек, проверяльщиков ошибок и пр. — типа пусть машина всё делает за меня, особенно сложные операции. Оказалось проще выучить GnuPG, вместо скриптов и алиасов оставить подсказки для наиболее часто используемых команд (персональный tipsheet, из которого копировать в строку нужные куски). Но обязательно находится кто-то, кто снова хочет начать с такого костылестроения. И красивый подход применить, и свой ЯП запилить и пр.

На десятки и десятки тысяч строк используется. Для тысяч хостов пишут одно и то же правило копированием строчки, даже не циклом (а вам в одно локалхосте не разобраться). Зато напротив каждой строчки стоит свой комент. Всё это элементарно редактируется через vim по ssh. И если для какой-то машины нужно вкорячить нестандартное правило, то не надо в спешке програмить скрипт и отлаживать.

Напишите плагины для Shorewall в целях локального использования. Не, ну если хотите, то делайте для себя, что угодно. Я такое делал и для себя, и практически в продакшн и нервы себе уже попортил спорами на эту тему, больше не хочу, спасибо.

Это глубокая формула, в которую укладывается множество всего. Если выясняется, что собеседник не понимает чего-то совсем концептуального, и ему надо объяснять, то можно извести тонны бумаги и написать сотню простыней, но это всё равно окажется «не в коня корм», потому что это требует некого переосмысления, взятия барьера абстракций и т.д. Короче, процесс сложный, небыстрый и часто очень неблагодарный, поэтому лучше с ним не связываться, и просто ничего не объяснять, оставив своё мнение при себе. Вот и получается, что «если не надо объяснять, то ОК, не обсуждаем, и так друг друга понимаем, а если надо объяснять, то это [всё равно] не надо объяснять, потому что бесполезно».

Вот! Я многие темы, поднимаемые на форуме, не обсуждаю или сворачиваю с обсуждения, когда понимаю, что куча времени — впустую. Иногда сразу понятно, что обойти стороной, иногда с какого-то момента. Не в смысле даже, что я прав, а кто-то неправ, просто — не моё, неинтересно, дальше без меня.

У меня тоже есть куча своих программных костылей, которые я бы никому не предложил и не вынес в паблик. Т.к. это изврат, составленный под свои узкие личные предпочтения, не более. А в целом он не нужен. Как в своё время делал проверяльщик подписей для apt, когда подписи пакетов были, а штатной их поддержки в самом apt — не было. Оно даже работало и даже правильно. Так же как и аналог LUKS, до появления собственно LUKS и ещё кучу всякого бреда. Но поддерживать этот изврат самому для себя — сомнительное удовольствие. Хорошо, что сейчас это есть штатно. Даже этот^[link7] изврат я готов бросить моментально по двум противоположным причинам: сделают штатное решение лучше моего или наоборот — сделают так, что поддерживать это всё будет слишком сложно и проще сидеть вообще без тора.

Так можно про любую задачу сказать: раз ещё не решили, значит, бьются и решают. А если приглядеться внимательней, то есть, в лучшем случае, 2-3 научных коллектива, а то и вообще всего несколько человек, которым эта задача интересна. Другие занимаются другими задачами. Лишь очень небольшое число проблем удостаивается официального статуса трудных. Это проблемы, к которым, например, сводится решение множества других важных проблем. В криптографии можно легко придумать тысячу проблем-вопросов, ответа на которых наука не знает. Это не значит, что все они трудные (нахождение и постановка действительно трудной проблемы — само по себе уже открытие, но трудность надо доказать чем-то помимо «я пробовал, и у меня не получилось решить»; например — сведением к другим трудным задачам). Это значит (обычно) только то, что никто из квалифицированной публики серьёзно за них не брался.

unknown, ты комментом ошибся) Там я Гегелю спасибо говорю)

промахнулся^[link14].

Здесь немного более общие разногласия в плане подходов. Скорее разногласия с поисками оптимума. Просто, это странное нечто нечто странное внезапно всплыло в другой теме^[link15] и там же ранее^[link16], здесь хоть удалось выяснить, что это, для чего, зачем и почему (не)нужно и на каких принципах основано.

OK. Тогда проще согласиться с концом вот этого коментария^[link17]:

Как всегда, это вопрос личного компромисса между затратами, отдачей и приоритетами.

Шелл — это простой склеиватель утилит, не надо из него пытаться сделать полноценный скриптовый язык программирования.

Да им тысячи хостов разруливают и тупо пишут скрипт

Я^[link19] вообще в последнее время подумываю об интеллектуальном дауншифтинге.

М^[link20]ожно впадать в маразм.

При нажатии Ctrl-Alt-Del более семи раз за интервал в две секунды теперь выполняется немедленная перезагрузка, но с корректным отмонтированием всех разделов

Копипастну сюда весь список из вики:
Domain-specific language: Advantages and disadvantages^[link23].

Some of the advantages:[1][2]

• Domain-specific languages allow solutions to be expressed in the idiom and at the level of abstraction of the problem domain. The idea is domain experts themselves may understand, validate, modify, and often even develop domain-specific language programs. However, this is seldom the case.[6]

• Domain-specific languages allow validation at the domain level. As long as the language constructs are safe any sentence written with them can be considered safe.[citation needed]

Some of the disadvantages:

• Cost of learning a new language vs. its limited applicability

• Cost of designing, implementing, and maintaining a domain-specific language as well as the tools required to develop with it (IDE)

• Finding, setting, and maintaining proper scope.

• Difficulty of balancing trade-offs between domain-specificity and general-purpose programming language constructs.

• Potential loss of processor efficiency compared with hand-coded software.

• Proliferation of similar non-standard domain-specific languages, i.e. a DSL used within insurance company A versus a DSL used within insurance company B.[7]

• Non-technical domain experts can find it hard to write or modify DSL programs by themselves.[6]

• Increased difficulty of integrating the DSL with other components of the IT system (as compared to integrating with a general-purpose language).

• Low supply of experts in a particular DSL tends to raise labor costs.

• Harder to find code examples.

Согласен практически со всеми пунктами. Вопрос лишь в балансе достоинств/недостатков. Считаю, что DSL особенно для iptables и особенно на шелле сильно перевешивает по недостаткам. Тема началась именно с iptables, но это касается многих других случаев попыток нагородить самопальный метаязык/DSL для поддержания ИБ в системе.

Про скрипты^[link24]:

Unix shell scripts give a good example of a domain-specific language for data organization.

In practice, scripting languages are used to weave together small Unix tools such as AWK (e.g., gawk), ls, sort or wc.

Набор мнений на вики — конечно не истина в последней инстанции, но как-то отражает общую практику, что шелл — просто склейка между утилитами, как-то внутри него метаязык со своими абстракциями стараются особо не городить. Хотя в статье про метапрограмминг^[link25] такой пример есть и для iptables он бы выглядел более практично, чем то, что там приведено.

As far as I understand, this tab is redundant or mostly redundant. One of the UX test users was confused by it

$ xbacklight -set 70

$ [культ вуду]
echo "какая-то хрень с непонятными параметрами" > \
/proc/путь/куда/макар/телят/не/гонял/болото
$ [ещё культ вуду]

1. Зачем писать echo "" > file.txt и т.п.? Это принудительный перевод строки в файле? А проще никак без таких костылей?

2. sha256sum -c sha256sums.txt 2>&1 | grep OK >> file.txt ← скажу сразу, что не знаю опцию -c. Мне придётся открывать man, чтобы узнать.

3. С редиректами потоков тоже много своих приколов. Вашей команды «gpg --verify tor-browser-linux64*.asc >> file.txt 2>&1» это тоже касается. По человеческой логике вначале обрабатываем поток (2>&1), а только потом его перенаправляем в файл через >> или >. Но реально надо делать в обратной последовательности. Почему — это, как мне давно объясняли, следует из внутренней логики сей, и, чтобы это понять, нужно знать, как на сях это реализовано.
   
   Кроме того, бывают дополнительные дескрипторы потоков кроме первого и второго. Например, я недавно сталкивался с тем, что какая-то программа упорно писала нечто на терминал, что я никаким образом не мог автоматически запихать в файл так, чтобы там было ровно то, что выводится на терминал (и ровно в той же последовательности).

This script (or program) generates a new 993-line program that prints out the numbers 1–992. This is only an illustration of how to use code to write more code; it is not the most efficient way to print out a list of numbers. Nonetheless, a programmer can write and execute this metaprogram in less than a minute, and will have generated exactly 1000 lines of code in that amount of time.

Н^[link30]е сообщайте в них больше, чем готовы сказать прокурору.

I^[link32]ndeed, modern cryptography is strongly coupled with Complexity Theory (in contrast to "classical" cryptography, which is strongly related to information theory).

Любителям и профессионалам скриптомесева: ShellCheck^[link40].

ShellCheck is a static analysis and linting tool for sh/bash scripts. It's mainly focused on handling typical beginner and intermediate level syntax errors and pitfalls where the shell just gives a cryptic error message or strange behavior, but it also reports on a few more advanced issues where corner cases can cause delayed failures.

local our_user=$(eval echo "\$$#")

D^[link41]eclare and assign separately to avoid masking return values.