Thawte и Verisign какбэ ушибленные.

Equifax чуть лучше.

Российская сторона получила перечень потребностей ливанских вооруженных сил и готова рассмотреть его в ближайшее время.

Я удивляюсь, дорогая редакция. Скоро жрать будет нечего, а российская сторона думает об одном: как бы насрать Западу.

Привет Оруэллу.

Белоангличане написали бы так:

Bii ðai sliip
Kaam ænd diip.
Laik ðəuz huu fel,
Not auəz huu wiip.

Дано:

• квартирная сеть: linux-роутер на базе старого PC и несколько рабочих станций;
• безлимитный интернет с ограничением полосы пропускания;
• файлы круглосуточно качает роутер; для серфинга используются рабочие станции.

Проблема.
Роутер занимает весь канал, NAT-трафик не может пробиться к потребителям. Останавливать закачки на время серфинга — простое, но слишком хлопотное решение.

Непредвиденные обстоятельства.
Разумеется, нужно привлекать iproute2 для приоритезации трафика и перенаправлять входящий трафик на псевдоустройство ifb. Однако возникает неожиданное препятствие: трафик, пришедший на ifb успевает классифицироваться до того, как пройдет через правила iptables. Таким образом, с помощью iptables невозможно выделить NAT-трафик и пометить пакеты до классификации на ifb. Средствами же iproute нельзя задать фильтр, который может узнать по ip_conntrack, является ли роутер окончательным адресатом пакета или он будет обработан NAT-ом и передан в локальную сеть.

Решение.
При маскарадинге пакетов можно явно задать диапазон портов, которыми будут заменяться оригинальные dport. Этим можно воспользоваться для отличения NATed-пакетов от обычных, попадающих в INPUT. Так, можно задать достаточно высокий диапазон портов для NAT:

$IPTABLES -t nat -A POSTROUTING -o $PPP_IFACE -p TCP -j MASQUERADE \
--to-ports 16384-65535
$IPTABLES -t nat -A POSTROUTING -o $PPP_IFACE -p UDP -j MASQUERADE \
--to-ports 16384-65535
$IPTABLES -t nat -A POSTROUTING -o $PPP_IFACE -j MASQUERADE

Обычные (не NAT) пакеты с большой вероятностью будут иметь порт назначения ниже отметки 16384.
Классифицировать входящие пакеты по dport не составляет труда (классификатор u32).

P.S. Полные скрипты из работающей конфигурации могут быть выложены при наличии интереса к теме.

Луч поноса быдлоадминам, у которых одно лишь правило в антиспам-фильтре способно завернуть письмо. В особенности, если это правило всего-то пробивает адрес отправителя по PBL Спамхауса. IT-сталинизм в действии.

Пляжный сезон не за горами. А некоторые приступили уже сейчас:

Умер? Никак нет. Тот же экспонат через 20 минут:

Задача: покрутить AOP на как можно более простом примере.

Для этого возьмем:

1) Файл AspectTest.java с подопытным классом

package ajtest;

class AspectTest {
    public void printKrivetko() {
        System.out.println("Я криветко :)");
    }

    public void printMedved() {
        System.out.println("Я медвед 8]");
    }

    public static void main(String[] args) {
        AspectTest app = new AspectTest();
        app.printKrivetko();
        app.printMedved();
    }
}

2) Файл PrintLogging.aj с простым аспектом

package ajtest;

// наш простой аспект
public aspect PrintLogging {

    // наш простой адвайс
    after() returning:
        call(void AspectTest.print*()) {
        System.out.println("^^^ вызыван какой-то метод print*");
    }
}

3) Файл build.xml с несложным проектом

<project name="ajtest" default="ajx" basedir=".">
    <!-- определяем директории для исходников и скомпилированных классов -->
<property name="src" location="src"/>
<property name="build" location="build"/>

    <!-- определяем таск iajc -->
    <taskdef
        resource="org/aspectj/tools/ant/taskdefs/aspectjTaskdefs.properties">
        <classpath>
<pathelement location="lib/aspectjtools.jar"/>
        </classpath>
    </taskdef>

    <!-- цель для компиляции основных классов -->
    <target name="compile">
        <javac srcdir="${src}" destdir="${build}"/>
    </target>

    <!-- цель для добавления AOP-функциональности -->
    <target name="ajx" depends="compile">
        <iajc sourceroots="${src}"
              destdir="${build}"
              classpath="lib/aspectjrt.jar"
        />
    </target>
</project>

4) Библиотеки aspectjrt.jar и aspectjtools.jar из последнего стабильного билда.

Все это разложим по директориям:

+ build
+ src
|- + ajtest
   |- AspectTest.java
   |- PrintLogging.aj
+ lib
|- aspectjrt.jar
|- aspectjtools.jar
build.xml

И соберем ant-ом:
ant

Запускаем (сообщения, создаваемые внутри аспекта, отправляются в стандартный вывод):
java -cp build;lib/aspectjrt.jar ajtest.AspectTest

В консоли должно появиться следующее:
Я криветко :)
^^^ вызыван какой-то метод print*
Я медвед 8]
^^^ вызыван какой-то метод print*

It’s working.

Привязка сервлета к URL только двумя убогими способами («строка начинается с …» и «строка заканчивается на…») — это по нынешним временам совершеннейшая дичь. Благо, неравнодушные люди озаботились ситуацией и написали rewrite-filter.

Намедни захотелось мне почитать что-нибудь из психологии. Пошел, как водится, в ближайший книжный магазин и ну искать по авторам. И что же? Фестингер — шиш. Левин — шиш. Фромм — и тот шиш.

То, что компьютерную литературу книготорговцы подбирают по дизайну обложки, мне было давно известно. Но если механизм справедлив и для книжек по психологии, и если так формируется вообще весь ассортимент, то это повод как минимум принять к сведению тревожный сигнал, почесать репу и начать шевелиться. Найти 3-4-5 человек, сведущих в своей области. Дать им определенные бонусы: безобразно большую скидку, любую бесплатную книгу раз в сколько-нибудь времени. И выяснить у них, наконец, какую литературу нужно возить вместо макулатуры, что собирает пыль на полках магазина.

А можно еще радикальнее — начать самим читать.

В конторе накопилось много ценной информации, которая пока лежит кучами и не приносит отдачи. Перенос ее в базу данных и разработка бизнес-логики — вопрос времени. Рано или поздно придется это делать.

Но уже ясно, что легковесными казуальными решениями не обойтись: во-первых, еще никто не может четко представить задачи и сформулировать детальные требования к проектам, во-вторых, как следствие, настанет момент, когда все эти разнородные костыли будет сложно собрать в систему. Отсюда явно следует, что энтерпрайзу нужно предложить энтерпрайзовое решение. В нашем случае, реализацию бизнес-логики в виде бинов внутри Java EE-контейнера.

Чрезмерную сложность Java EE можно отчасти нивелировать внедрением фреймворка, который позволяет программировать бины, не захламляя код формальными конструкциями. На эту роль идеально подходит Spring Framework.

Кроме того, Spring Framework обещает элегантное решение проблем сквозной функциональности (например, журналирования), готовое MVC для веб-компонентов, аутентификацию / авторизацию и многое другое. Поверхностное чтение документации показало, что в центре внимания находятся как раз-таки насущные проблемы, которые много раз возникали в моих проектах. Это подтверждает (надеюсь) правильность выбора. Остается в который раз запастись терпением и глазными каплями — и в бой.