Сейчас наличие нескольких подключений к интернет на одном, в том числе и домашнем сервере — не редкость. Городские локалки, ADSL, 3G модемы… Добавим к этому сети домашние локальные и внешние виртуальные (VPN), и получим ядрёную смесь интерфейсов, между которыми необходимо роутить трафик, балансировать трафик между разными каналами в интернет (когда они есть), и переключаться с нерабочих каналов на рабочие (когда они отваливаются).

Судя по постам в инете, большинство людей, столкнувшихся с этой ситуацией, очень плохо представляет себе, как это настраивается. Надо отметить, что в линухе действительно управление роутингом весьма сложное и запутанное — следствие эволюционного развития и поддержки (частичной) совместимости. Я хочу описать принципы настройки роутинга multihomed серверов на конкретном, достаточно сложном, примере: на сервере три физических сетевых интерфейса (один в домашнюю локалку и два к ADSL-модемам), два ADSL-подключения (ADSL-модемы в режиме bridge, так что pppd поднимает этот же сервер) к разным провайдерам (одно со статическим IP, второе с динамическим), плюс VPN на сервер компании — итого шесть интерфейсов.

Тема достаточно сложная, поэтому для понимания материала потребуется хотя бы минимальное понимание работы роутинга (что такое default route и gateway), файрвола (маркировка пакетов, отслеживание соединений, связь между разными таблицами и цепочками файрвола и роутингом), pppd (скрипты ip-up/ip-down) и протоколов IP и TCP.

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

Посвящается B_dot, пост которого заставил заинтересоваться возможностями консоли плотнее.

Краткое вступление

В этом посте будет рассказано о некоторых сочетания клавиш, которые могут упросить жизнь администраторам, работающим в консоли. Все они работают в bash'e. Сочетания клавиш я дополнительно проверял на циске (Cisco IOS Software, s72033_rp Software (s72033_rp-ADVIPSERVICESK9_WAN-M), Version 12.2(33)SXH4), csh и zsh. Рассмотренное в других записях повторять особо не буду. Сочетания сгруппированы по использованной функциональной клавише.
Особенно полезен этот текст будет людям, которые любят использовать клавиши Home, End и Delete (которые в цисковой консоли «не работают»).

Опен-сорс веб-панелька phpVirtualBox поможет вам управлять вашими VirtualBox виртуальными машинами через ваш браузер. После установки веб-сервера запущенного с vboxwebsrv utility, вы сможете пользоваться веб-интерфейсом который мало чем отличается от программного.

phpVirtualBox может быть запущен на любой платформе.

Команда Jupiter IT выпустила Syn, библиотеку, которая позволяет вам создавать синтетические события для использования при тестировании. Эта отдельная библиотека предназначена для оказания помощи в тестировании сложного поведения пользовательского интерфейса, имитируя действия пользователя, такие как печать с помощью клавиатуры, нажатие кнопок мыши и перетаскивание с её помощью.

Мне достаточно часто приходится использовать различные онлайн-сервисы для проверки доступности сайтов и их поверхностных тестов и проверок.
Как показал краткий опрос коллег — почти у всех эти наборы сервисов отличаются. Я хочу показать вам свой, прошу в

CoffeeScript — это, если так можно выразиться, язык высокого уровня, преобразуемый в JavaScript.

Основан простым парнем по имени Jeremy Ashkenas при поддержке его корешей, которые упомянуты на github'е. Вдохновленный Ruby, паренёк решил упростить всем нам жизнь и создал его! CoffeeScript!

Многим разработчикам знакома ситуация когда кешировать страницы сайта, скажем, на 5-10 минут нельзя всего из-за одного небольшого блочка, актуальность которого нужно поддерживать если не в реальном времени, то с временем «старения» не больше 5-10 секунд. При этом посещаемость сайта продолжает расти, растет время генерации страниц и c этим надо что-то делать…

• Вариант решения 1: Подкрутить то, до чего не доходили руки последнее полгода. Все Вас поймут и передвинут сроки на другие задачи. Вы будете в роли «Супермена» один спасать сайт от непомерной нагрузки, решая проблему «бесплатно» (без доп. вливаний в оборудование). Вам может пригодиться статья «Тюнинг nginx».
   
• Вариант решения 2: Улучшить техническую базу (докупить мозгов на сервер, улучшить дисковую систему, поставить под БД отдельный сервер). В принципе проблема не решена, а скорее отложена. Теперь у Вас есть время «окопаться» и подготовиться ко второй волне наплыва нагрузки, она будет больше и накроет сильнее.
   
• Вариант решения 3: Ваш вариант, о котором я, вероятно, узнаю из комментариев.
   

Позвольте предложить и мне проверенное и относительно простое решение на базе одной из старейших технологий в Web-разработке.

Проблема создания скриншотов web-страниц прямо на сервере встает достаточно редко, но, как говорится, метко. Хватишься иной раз, так гугль дает ссылки на какой-нибудь парсер уже существующего сервиса. Но, господа, это же не наш метод!

Покопавшись, можно найти что-нибудь типа связки xvfb (виртуальный фреймбуффер) с каким-нибудь браузером, например xvfb+opera, или khtml2png, который тянет за собой фигову тучу kde'шных либ. А ведь так хочется какого-нибудь легкого standalone скриптика...

Решив посвятить немного времени изучению вопроса, обстоятельно исследовал имеющийся инструментарий.

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

Я хочу уделить внимание нескольким приемам, которые, к моему сожалению, еще не являются повсеместными привычками. Очень хочу оказаться банальным и неуместным.

Количество элементов на одной странице

Разбиваете список на страницы? Как будет выглядеть вторая страница для списка из 101 элемента, если ваше волшебное число 100?

Представьте, что вы пишете блогохостинг и хотите позволить авторам блогов менять свой дизайн. Картиночки там вставлять, цвета менять, пропорции регулировать… Представили? Если хорошо представили, то уже поняли, что без констант и формул в CSS тут не обойтись.

При блуждании по блогам не хотелось бы грузить все стили заново, что неизбежно при серверном вычислении значений, а хотелось бы грузить лишь минимальную разницу — так называемый скин.

Итого, нам нужно грузить в дополнение к данным страницы: скин с константами и стили с формулами. Только две клиентские технологии позволяют сделать это: JS и XSLT. Однако первую очень любят отключать, а вторую отключать просто нет смысла. Поэтому вынесем CSS в XSLT контейнер, а заодно и не забудем про технологию XHTML-инклудов.

Пусть мы хотим написать свой хабрахабр с блекджеком и прочими прелестями. Страница статьи у нас стостоит из 3 объёмных блоков:
1. собственно текст статьи. меняется очень редко.
2. дерево комментариев. меняется относительно часто, но со временем всё реже и реже.
3. прямой эфир. небольшой, но меняется очень часто.

Допустим, что страница с этой статьёй доступна по адресу ?article:right.cache
Но внутрь неё мы не будем помещать никакого контента, а вынесем его в отдельные ресурсы, как это обычно делается со скриптами и стилями. Внутри ?article:right.cache будет лишь индекс подключаемых ресурсов с версиями.

?article:right.cache/content/version:123
?article:right.cache/comments/time:2010-12-01
?live/time:2010-12-01
?style:article/version:666
?script:article/version:333

Указание версии позволяет задать для ресурсов жёсткое кэширование. А для индексного файла, наоборот, зададим необходимость проверять при каждом запросе изменился ли он.

Такая организация гарантирует нам, что при появлении новых комментариев не придётся грузить статью заново. И наоборот, при изменении статьи не надо будет перегружать всё дерево комментариев. А уж про то, что из-за часто меняющегося прямого эфира нам не надо по новой грузить весь контент, и заикаться не стоит ;-)

Важно, чтобы поисковики видели ссылки на ресурсы и могли их проиндексировать. Однако, из поиска люди будут приходить на конкретный ресурс и даже на конкретную его версию. Соответственно, ресурс должен определять загружен ли он по прямой ссылке и если это так, то после загрузки клиентскими средствами редиректить на индекс. Если актуальная версия ресурса не изменилась, то он потом будет взят из кэша. Если же изменилась — будет загружена новая версия. Не такая уж страшная беда, на самом деле ;-)

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

Обзор кода является одной из самых ценных инженерных практик.

   1. Обзоры кода улучшают качество кода: одна голово хорошо, а две — лучше.
   2. Обзоры кода — это прекрасный инструмент для изучения разработчиками тех частей приложения, которые они в дальнейшем могут сопровождать.
   3. Обзоры кода помогают узнавать лучшие практики от других разработчиков.
   4. Обзоры кода могут использоваться для проверки понятности и простоты всего приложения в целом.

Как вы могли заметить, в этом списке я не упомянул, что проведение обзоров кода помогает находить ошибки и соблюдать стандарты кодирования, и вот почему:

   1. Обзоры кода НЕ ДОЛЖНЫ проводиться с целью поиска ошибок.
   2. Обзоры кода НЕ ДОЛЖНЫ проводиться с целью проверки соблюдения стандартов кодирования.

10 лет назад эти два пункта имели бы смысл в обзорах кода. Однако сейчас вы должны использовать автоматические средства тестирования и инструменты, следящие за оформлением кода. Это не значит, что во время проведения обзора вы не должны замечать ошибок кодирования и оформления, это значит, что их нахождение не является целью проведения обзора кода.

Исходя из этой точки зрения, позвольте вам дать 5 советов по проведению хорошего обзора кода.

В этом топике расскажу как можно в пару скриптов наладить простой сбор статистики по аномальной активности в сети.

Аномальным для нас будет на момент снятия статистики:

1. Более 20 исходящих коннектов по 25 порту с 1 IP.
2. Более 100 исходящих коннектов по 80 порту с 1 IP.
3. Более 100 исходящих коннектов по 53 порту с 1 IP.
4. Придумывайте сами, всё гибко.

Статистику будем вынимать из кэша netflow маршрутизаторов. Будет ли это Cisco или FreeBSD — не важно. О настройке netflow на FreeBSD я рассказывал в предыдущих своих статьях.

Принесли мне намедни винчестер прямо в упаковке и озадачили оперативным клонированием системного диска одного из серверов. Задача, в целом довольно тривиальная, и легко выполнимая. У каждого наверняка есть методика подобного рода действиям, не знаю лучше или хуже мой подход, но поделиться, думаю, им стоит.
Вводная:
* сервер с linux
* все разделы на XFS
* загрузчик GRUB 0.97
* оригинальный диск /dev/sda, клонируем на /dev/sdb
* разделы /dev/sda[1,5-7] (общая полезная информация ~1GB)

Под катом описано как шейпировать трафик в Linux и что для этого нужно знать.

Вторая часть статьи об управлении трафиком в Linux. В статье приведены примеры приоретизации трафика (QoS) и рассказано об использовании hash таблиц при фильтрации трафика (fast hash tables), использование которых позволяет существенно увеличить производительность.

Итак, родилась у меня как-то давным давно идея сделать свой собственный мониторинг с б/ж и ш.

Необходимо было мониторить успешные входы по ssh(и использование sudo) и сообщать мне об этом. Для оповещений был выбран мессенджер centerim (в дебиан и подобных пакет называется centericq-utf8). Так же понадобится пакет screen.
aptitude install screen centericq-utf8

Нередко перед системными администраторами встает задача оповещения себя и коллег о каких-либо событиях на сервере, будь то отчет об успешных входах по ssh, резко возросшая нагрузка, падение сервиса, сообщение о переключении на резервное питание или вскипевшем чайнике.
Чаще всего такая задача решается, например, отправкой почтового сообщения. Но нельзя гарантировать, что сообщение, во-первых, прийдет вовремя, а во-вторых, что его сразу прочтут. Тогда, подумает администратор, будем использовать IM. Но как? Держать, например, centerim постоянно открытым в screen? Согласитесь, не самый радужный вариант.
На выручку к нам спешит чип и дейл открытый протокол XMPP. Написано множество расширений к популярным языкам и примеров кода, позволяющих отослать сообщение кому требуется, и отослать его быстро.
Пример такого кода я и приведу.

Хочу поделиться своим опытом в проектировании архитектуры программы. Архитектура — весьма важная вещь для проектов со сложной внутренней структурой и многочисленными внутренними связями. Ошибка в выборе способа решения может сильно аукнуться при дальнейшем развитии проекта, привести к лавинообразному росту сложностей и ошибок. Возможен даже момент, когда проще написать все с нуля, чем распутывать клубок взаимосвязей.

Для примера, возьму относительно простую архитектуру однопользовательского приложения. Например, коммуникатор — программу для сетевого общения, которая поддерживает множество разных протоколов, умеет менять внешний вид и должна обладать открытостью для добавления новых возможностей и дальнейшего развития.