White Russ.. English lullaby
Белоангличане написали бы так:
Bii ðai sliip
Kaam ænd diip.
Laik ðəuz huu fel,
Not auəz huu wiip.
[RESOLVED] Серфинг на забитом канале
Дано:
- квартирная сеть: 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 минут:
AspectJ для журналирования
Задача: покрутить 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-pattern
Привязка сервлета к URL только двумя убогими способами («строка начинается с …» и «строка заканчивается на…») — это по нынешним временам совершеннейшая дичь. Благо, неравнодушные люди озаботились ситуацией и написали rewrite-filter.
Перехожу на Spring Framework
В конторе накопилось много ценной информации, которая пока лежит кучами и не приносит отдачи. Перенос ее в базу данных и разработка бизнес-логики — вопрос времени. Рано или поздно придется это делать.
Но уже ясно, что легковесными казуальными решениями не обойтись: во-первых, еще никто не может четко представить задачи и сформулировать детальные требования к проектам, во-вторых, как следствие, настанет момент, когда все эти разнородные костыли будет сложно собрать в систему. Отсюда явно следует, что энтерпрайзу нужно предложить энтерпрайзовое решение. В нашем случае, реализацию бизнес-логики в виде бинов внутри Java EE-контейнера.
Чрезмерную сложность Java EE можно отчасти нивелировать внедрением фреймворка, который позволяет программировать бины, не захламляя код формальными конструкциями. На эту роль идеально подходит Spring Framework.
Кроме того, Spring Framework обещает элегантное решение проблем сквозной функциональности (например, журналирования), готовое MVC для веб-компонентов, аутентификацию / авторизацию и многое другое. Поверхностное чтение документации показало, что в центре внимания находятся как раз-таки насущные проблемы, которые много раз возникали в моих проектах. Это подтверждает (надеюсь) правильность выбора. Остается в который раз запастись терпением и глазными каплями — и в бой.
