На днях ожидаем стойки и кабельросты, будем монтировать. Максимальная расчетная нагрузка на каждый ряд кабельроста – около полутора тонн, то есть к каждой стойке можно подвести более 200 кг кабелей.
Archive for мая, 2010
ДЦ. Одинокие шпильки
Хозяйке на заметку: Postfix SMTP Auth и соответствие envelope-from
Для пользователей, которые успешно авторизовались с помощью 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 и большие массивы
Если вам придется поднимать под 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 умрет, чтобы стать лучше
Если кто еще не в курсе, “ось зла” объявила о новом продукте – 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
А знаете, как выглядит 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@не_скажу>