RSS
 

Archive for мая, 2010

ДЦ. Одинокие шпильки

31 мая

На днях ожидаем стойки и кабельросты, будем монтировать. Максимальная расчетная нагрузка на каждый ряд кабельроста – около полутора тонн, то есть к каждой стойке можно подвести более 200 кг кабелей.

 

Хозяйке на заметку: Postfix SMTP Auth и соответствие envelope-from

28 мая

Для пользователей, которые успешно авторизовались с помощью SMTP Auth (логин типа vasya@domain), мы разрешаем отсылать письма через наш почтовый сервер с любого IP-адреса (то есть поддерживаем roaming users). В определенный момент мы натолкнулись на неприятный случай – у одного клиента был украден/заснифлен его логин-пароль и с нескольких IP-адресов была массированная рассылка спама. При этом, так как клиент “представился”, ему было позволено указывать любой envelope-from, чем и воспользовались спаммеры. Ситуация расстроила, адреса зафильтровали, клиентский логин/пароль заблокировали, но нужно было что-то решать в комплексе – для авторизованных клиентов разрешать использование envelope-from, соответствующий их логину.

В postfix есть возможность указать ограничение reject_sender_login_mismatch, при использовании которого производится проверка в таблице smtpd_sender_login_maps соответствия логина и MAIL FROM. Но тут возникает другой момент – для тысяч почтовых ящиков генерировать такую таблицу можно, но это потребует напильника в postfixadmin, который используется для управления аккаунтами клиентов. Немного посоображав, была реализована следующая грубая, но работающая схема с помощью mysql maps: описываем таблицу в main.cf:

smtpd_sender_login_maps         = mysql:/usr/local/etc/postfix/sql/mysql_authentificated_users.cf

Сам mysql_authentificated_users.cf прост до безобразия:

user = mysql_username
password = mysql_password
hosts = database_host
dbname = database_name
query          = SELECT '%s'

Не забываем в main.cf указать, чтобы те, кто используют несовпадающий envelope-from, получали reject:

smtpd_sender_restrictions =
reject_authenticated_sender_login_mismatch
permit

Вот такая история из цикла “неэлегантно, но практично” :)

 

Хозяйке на заметку: FreeBSD и большие массивы

27 мая

Если вам придется поднимать под FreeBSD большой дисковый массив (более 2Тб – созданный, например, с помощью RAID-контроллера), случится несколько неприятный момент. fdisk и disklabel не умеют корректно работать с подобным объемом и вместо, скажем, 3Тб (2 диска по 1.5Тб в STRIPE) вы получите несколько поменьше:

iptvts2# df -g /mnt
Filesystem    1G-blocks Used Avail Capacity  Mounted on
/dev/aacd0s1d       718    0   661     0%    /mnt

Если такое случилось, паниковать не нужно. Во-первых, жестоко уничтожаем информацию о разделах на диске с помощью универсального способа – dd(1):


iptvts2# dd if=/dev/zero of=/dev/aacd0 bs=1k count=500
500+0 records in
500+0 records out
512000 bytes transferred in 0.026223 secs (19524886 bytes/sec)

Затем используем glabel(8) для создания метки:


iptvts2# glabel label timeshift1 /dev/aacd0
iptvts2# glabel list
Geom name: aacd0
Providers:
1. Name: label/timeshift1
Mediasize: 2995729202688 (2.7T)
Sectorsize: 512
Mode: r0w0e0
secoffset: 0
offset: 0
seclength: 5851033599
length: 2995729202688
index: 0
Consumers:
1. Name: aacd0
Mediasize: 2995729203200 (2.7T)
Sectorsize: 512
Mode: r0w0e0

Вот и все. Теперь можно делать newfs(8) на /dev/label/timeshift1 и пользоваться массивом.

 

Google TV: IPTV умрет, чтобы стать лучше

22 мая

Если кто еще не в курсе, “ось зла” объявила о новом продукте – Google TV. На странице проекта есть небольшая видеопрезентация, но в двух словах попробую описать и я, что нас ожидает ближе к концу года. Итак, вкупе с широкой поддержкой HTML5 и анонсе о широкой поддержке видеокодека VP6 (и о переводе VP6 в open-source) браузер Chrome, Chorome OS и Android практически готовы к тому, чтобы быть ближе к телевидению. Chrome OS или Android поселятся в самих телевизорах (уже есть анонс Sony), будут выпущены приставки (анонс Logitech, остальные подтянутся очень быстро, причем китайцы будут впереди всех, как обычно). Представьте, что все популярные медиаплееры (типа Dune, WD и прочие) поддерживают эту технологию – что мы имеем в результате?

Во-первых, и я это категорически приветствую – IPTV в существующем виде сделает то, что должно сделать. Оно умрет, трансформировашись в высококачественный web-tv с поддержкой всех необходимых фишек (HD, многоканальный звук, много аудиодорожек, субтитры и т.п.).

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

В третьих, будет очень широкий выбор клиентского оборудования по удобным, доступным ценам. И самое главное – будет совместимость, т.е. один и тот-же код будет работать в телевизоре Sony, приставке BBK, коммуникаторе (да-да!) HTC и на неттопе под ubuntu.

Минусы, конечно, тоже есть :) – влияние google на нашу жизнь будет еще больше. Но нам не привыкать – мы просто будем внимательны :)

p.s. Boxee, похоже, не успеет оказать значительного влияния на этот рынок. Задел был хороший, но так и не появилось широкодоступных аппаратные проигрывателей, а жаль.

 

Juniper J-Series Inside Look

21 мая

А знаете, как выглядит Juniper J-series роутер изнутри ? Дело в том, что мы сразу после покупки роутера добавляем до максимума память, так что первый подход к железке производится, как правило, с отверткой в руках :) Итак, J4350 на столе у нашего инженера, уже со снятой крышкой:

Общий вид (извините, ракурс не очень удачный). Воздуховоды, батарея вентиляторов, виден слот под дополнительный модуль аппаратного ускорения шифрования:

Операционная система JunOS выглятит не как нибудь, а вот так:

Маркировка материнской платы:

p.s. Вследствие сборки/разборки ни один роутер не пострадал. Живет и трудится в поте лица:

axl@не_скажу> show version
Hostname: не_скажу
Model: j4350
JUNOS Software Release [9.0-20100109.0]

axl@не_скажу> show chassis forwarding
FWDD status:
  State                                 Online
  Microkernel CPU utilization         1 percent
  Real-time threads CPU utilization  36 percent
  Heap utilization                   35 percent
  Buffer utilization                  2 percent
  Uptime:                               79 days, 23 hours, 24 minutes, 14 seconds

axl@не_скажу>