Прикладная дебианавтика

19.08.2008

Писал скрипт развёртывания web-проекта на сервер, работающий под управлением FreeBSD. Наткнулся на одну фишку, сначала даже не понял в чём дело. BSD tar и GNU tar оказывается по ключу verbose выводят информацию по-разному. Пример. Одна и та же команда:

tar -cvf /dev/null / >/dev/null

Даёт разный эффект. На GNU-системе (в моём случае Debian, но думаю, что на любом Linux будет так же) вывода нет, всё уходит в /dev/null. На BSD список файлов всё равно выводится. А всё потому, что BSD tar валит информацию по verbose в stderr. Ни объяснений, ни упоминаний по этому поводу в манах не нашел.

01.08.2008

Некоторое время назад поднимал на Debian Etch подключение через Корбину. Столкнулся с тем, что вроде информации на тему l2tp много, но так чтобы всё было debian way и одним куском - нигде. Решил написать свой мануал.

17.02.2008

Когда количество серверов на поддержке переваливает за второй десяток, поневоле начинаешь думать как бы так сделать, чтобы удобные, но очень скучные aptitude update && aptitude upgrade происходили без вмешательства со стороны занятого более творческой работой администратора. В бытность свою молодым джедаем, меня посещала гениальная мысль засунуть эти команды в шедулер. Ничего хорошего из этого, разумеется, не вышло. При желании, конечно, можно написать скрипт автоматизирующий эту задачу, но это уже будет велосипедостроение.

Пакет cron-apt представляет собой утилиту, с помощью которой автоматизируется скачивание, а при желании и установка обновлений. Расскажу как я обычно настраиваю его и apt sources.

09.02.2008

Неожиданно остро встала проблема спама. 500 и более писем в день, из которых фильтром отсеивается большая часть, но с десяток всё равно прорывается. А иногда, видимо когда спамеры придумывают как обходить фильтры, прорывается сразу 3-4 десятка в течение получаса. В общем напрягает. Такое количество сыплется потому, что на меня стоят редиректы системных почтовых ящиков (webmaster, hostmaster, postmaster, abuse) примерно с сотни доменов. Я бы уже и рад перенаправить их в /dev/null, но не привык отступать от RFC. По моему глубокому убеждению, интернет стал таким какой он есть (интероперабельным и глобальным) только потому, что соблюдались RFC. В случае с электронной почтой RFC 2142 явно требует существования в каждом домене как минимум адресов postmaster и abuse. Для нежелающих соблюдать это требование, даже придуман специальный чёрный список.

И вообще, отказаться от получения почты только потому, что туда сыплется спам - это не наш путь. Мне, например, гордость не позволяет. В войне со спамерами я не намерен капитулировать.

Один из самых эффективных методов борьбы со спамом, которые я когда-либо видел - это greylisting. Но у него есть неприятный побочный эффект - задержка первой доставки по триплету хост-отправитель-получатель.

19.10.2007

Есть vpn-сервер. К vpn подключается несколько клиентов. Подключения в течение рабочего времени висят практически постоянно. На том же самом канале, к которому подцеплен vpn-сервер висит десяток пользователей. Всё бы ничего, но один из этих пользователей иногда делает рассылки на несколько сотен адресов (он не спамер, адреса получены вполне легально из опросников клиентов). Мзт-сервер так же является маршрутизатором (что логично) и почтовым сервером (что не очень логично, но так уж получилось). Для пользователя отправка происходит в один момент. Но после этого вся ширина канала забивается smtp-соединениями. Это почтовый сервер спешит доставить почту. Разумеется, по vpn пользователи работать какое-то время не могут.