Возможно, вы ещё помните, что я порой здесь что-то, похожее на техническое, публикую :)

Так вот - блог переехал на Google Sites, которые усправляются из Google Apps, которые кафедра получила бесплатно как образовательное учреждение.

Чем это хорошо для всех вас:

За 2 года борьбы с устройствами АТ выявил несколько милых особенностей

Сразу надо сказать, что все описываемые устройства - EOL, то есть End of Life. То есть претензии вроде как не по адресу. Но тем не менее, думаю, что описать стоит - потомкам в назидание. Баги могут встретиться даже в оборудовании достаточно именитого бренда.

Итак, первый номер программы - коммутатор 3 уровня Allied Telesis AT-9424Ts/XP:

Второй номер - коммутатор доступа AT-GS950/n, где n - количество портов. Не путать с GS900/n. Итак:

Ну и последний экземпляр - это AT-GS900/n. Если кратко, то основные претензии - это отсутствие 802.1х в чистом виде (есть какой-то мутный 802.1x Redirection) и отсутствие SNMP от слова "совсем". Ну и консоли нет: нахимичил с настройками - дави на сброс, настраивай снова. Ну и телнета/ssh тоже нет. Ну и интерфейс похож (прям ну вот с точностью до логотипа) на D-Link'и старые. Зато в нём нет вентилятора!

Подвожу итог: не гоняйся, поп, за дешевизной. Хотя фирма и именитая, некоторыми детскими болезнями ряд её устройств вполне себе страдает. Хотя ещё раз повторюсь, устройства уже EoL, про новые линейки сказать ничего не могу. Да и в целом работает, 95% времени не принося особой головной боли. Cisco, конечно, лучше, но там и ценник другой. Решать в конечном итоге вам.

Привет, мои маленькие любители электронной почты. Сегодня я расскажу вам о том, что такое BCC-спам и как я его заборол (Осторожно! Имеются побочные эффекты!).

BCC-спам - это письмо, которое вы получаете только потому, что ваш адрес оказался в списке Blind Carbon Copy (скрытая копия). А письмо на самом деле от Ивана Ивановича к Ивану Никифоровичу, и вы недоумеваете, почему оно попало вам. Случаются вещи и поинтереснее - письмо от некоего Х самому этому Х. Но приходит вам. И можно до слепоты смотреть в заголовки - своего адреса электронной почты вы там не увидите, потому что заголовок BCC вырезается почтовым сервером отправителя (ну, почти всегда). Соответственно, ваш адрес будет фигурировать только в строке RCPT TO в SMTP-диалоге вашего принимающего MTA со спамерским отправляющим.

С BCC-спамом я столкнулся достаточно давно, когда-то даже вопрошал об этом на LOR.

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

Условие усложняется: надо проверять комбинацию заголовков From и To. Круто, в любимом мною postfix есть замечательная вещь header_checks. Но и тут не всё просто: фильтр, указанный в header_checks, проверяет заголовки строчку за строчкой! То есть сохранить состояние мы не можем, а значит, и проверить комбинацию заголовков тоже.

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

В postfix есть ещё одна чудесная вещь - After-Queue Content Filter. Есть, конечно, один нюанс: пользование этим фильтром вызывает (может вызывать) создание временной копии письма на диске, а это лишние тормоза. В документации написано - снижение производительности в 4 раза. Сервер у меня ненагруженный, поток корреспонденции небольшой - отчего бы не попробовать!

Реализация на bash даже заработала. Но код приводить не хочу, честное слово. Начал делать реализацию на python, но вовремя решил почитать ещё и вспомнил про другую замечательную вещь - Before-Queue Content Filter, а точнее сказать, Before-Queue Milter (mail filter). Решил писать милтер на python, но задумался снова - а не решена ли эта проблема уже в каких-то милтерах? И нашёл просто восхитительную штуку - milter-regex. Позволяет фильтровать письма, применяя произвольный набор условий, задаваемых в том числе регшулярными выражениями. В общем, чудо, а не штука. Демон легковесный, много памяти и процессора в работе не кушает, набор правил ограничивается только вашими потребностями. Не SpamAssassin, конечно, но свою работу делает и делает отменно.

Чтобы milter-regex заработал в CentOS 6 с включенным SELinux, пришлось немного модифицировать политику. При наличии audit2allow это дело 5 минут :) Простая строчка конфигурации:

творит чудеса:

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

А теперь обещанный побочный эффект: к вам больше не дойдут никакие письма, отправленные вам как BCC. В самом деле, ну нет способа отличить, письмо пришло к вам с благородными целями (например, вы взломали почтовик микрософта и перенаправили с помощью always_bcc - у них на границе postfix! - всю почту Баллмера себе) или это лютый спам. Есть, конечно, белые списки, но давать пользователям редактировать белые списки - это смертоубийство, а администрировать чёрно-белые списки самому - глупо. В общем, нет BCC - ну и фиг с ним, пусть люди видят, кому ещё было отправлено это письмо, кроме них.

В жизни каждого пользователя (и тем более администратора) однажды случается ОНО - разваливается RAID и "перетрахивается" (с) файловая система. Не миновала сия чаша и меня.

Собственно, суть. Из-за старательной поддержки жары в серверной и нестабильной работы одного из пары дисков в сервере развалилось зеркало. Rebuild интегрированными средствами не помог, а только усугубил ситуацию - все файлы, которые были открыты, которые открывались, с которыми велась работа, повредились: что-то превратилось из файла в каталог, что-то наоборот, где-то посеклись или превратились в кашу данные, что-то ВНЕЗАПНО стало симлинком, ну и так далее. В общем, праздник в сумасшедшем доме. Во итоге имеем:

Больной скорее мёртв, чем жив. Но нас таким не напугаешь :)

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

Первым делом, была предпринята попытка восстановить работоспособность yum, дабы путём yum reinstall повосстанавливать бинарники. Загружаемся с компашки (ни одно из имевшихся на узле ядер не грузится), чрутимся, вооружаемся wget'ом (благо, сеть поднималась) и вперёд, качаем python, python-libs и yum. И тут ждала первая засада - rpm не возжелал ставить пакеты. Ничего, rpm --rebuilddb спас. Устанавливаем пакеты и... видим фигу, потому как покорёжился glibc. Ладно, начнём с glibc. Обновление glibc привело к глобальной неработоспособности всего, что завязано на библиотеки из пакета glibc и зависимые от него. Почесал репу, так как по идее версия glibc при стабильном API влиять ни на что не должна. Отмонтировал файловые системы, на всякий случай запустил fsck... мама, роди меня обратно. Стало только хуже.

Я совсем забыл про то, что вместе с данными покорёжились и структуры ext4. Ну что ж, будет уроком. Восстанавливаем файловую систему путём удержания кнопки y на клавиатуре, попутно офигеваем с количества побитого. И это только корень! В /boot та же фигня, в /var тоже, в /tmp тоже, но его-то как раз не жалко. Своп не проверял :) После восстановления ФС пакеты наконец-то начали устанавливаться. Но только после rpm --rebuilddb, так как при любой ошибке при установке некорректно закрывалась база rpm. А ошибок было предостаточно: пакет, пытаясь установиться поверх уже имеющихся "файлов", яростно матерился. Приходилось удалять объект (как вам превратившаяся в каталог библиотека? :) ), ребилдить базу rpm, устанавливать пакет.

На 10 пакете я откровенно задолбался и вспомнил про то, что у меня есть второй идентичный сервер и scp. Решил скопировать /bin, /sbin, /usr, /boot, /lib, /lib64 с копии и даже начал это делать, но вовремя вспомнил, что scp не сохраняет права и метки SELinux. tar со всеми опциями --preserve спас отца русской демократии. Даже заработал yum :) Последовала переустановка ядра, но тут отмер grub. Сервер перестал загружаться сам по себе даже хотя бы до kernel panic. Пришлось переустанавливать и grub, а на fakeraid-зеркало он ставится не вполне тривиально. Побороли, запустились, но grub не перечитывал автоматически свой конфиг. Ладно, не великое зло, хотя бы загрузка работает.

Ещё через несколько итераций переустановки пакетов и выявления померших конфигов и rc-скриптов (половина из которых оказались заполненными ошмётками политики SELinux) удалось загрузиться до незапускающегося dbus. Ещё одна перезагрузка - и dbus выкинут из автозапуска. Ииииии... мы загрузились до работоспособного ssh! Урра! Теперь можно сидеть в удобном кресле и, попивая кофе с молоком, любоваться на гору Фудзи в цветках сакуры... На самом деле, я не люблю ни кофе, ни молоко, да и японская культура мне тоже не близка, ну да ладно :) Хотя бы мониторинг успокоится - агент запустился, пинг есть, ssh пускает. Половина сервисов не работает и vt не запускается, но это же мелочи, у нас есть ssh :)

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

На данный момент сервер не проявляет никаких признаков сбоя или нарушений в работе. Будем надеяться, что восстановлено действительно всё. Время восстановления - 4 вечера и суммарно часа 4 через ssh.

Выводы:

Предыстория: MySQL после обновления на 5.5.х падает с ошибкой от запроса count(distinct), из-за этого нормально не работают микроблоги. История бага - http://bugs.mysql.com/61101

О баге я сообщал почти год назад. Он получил критический уровень важности ("D1 (Critical)") и опасности ("S1 (Critical)"), имел дубликаты, был определён как регрессия (после покупки Сана Ораклом, хехе). И исправлен был только к релизу 5.6.4 24 февраля. Вот вам и Оракл, вот вам и "непревзойдённое качество" и "бескомпромиссная производительность". Продавайтесь Ораклу дальше, губите свои продукты.

Думаю, в процесса изучения курса "Операционные системы" порой возникает ощущение ненужности всех этих алгоритмов, стратегий и прочих архитектур, потому что зачем это прикладному программисту, который ниже int i не спускается. На деле это не так, и в данной статье я хочу это показать.

Начну с обзора того, о чём уже писал в микроблогах (http://microblog.comp.susu.ac.ru/notice/448, http://microblog.comp.susu.ac.ru/notice/475). Вспомните, что такое процесс, зачем их планировать и как это можно сделать. Вспомнили? А теперь представьте электронную очередь со многими параметрами: тип обслуживания, требуемая степень конфиденциальности, срочность обслуживания и т.д. От того, что процессы заменили людьми, суть не поменялась: есть ряд задач и их надо выполнить в какой-то очерёдности. Вот и думайте, что тут применить: FCFS ли или что-то более интеллектуальное. Давайте попробуем поразмыслить:

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

Второй пример хорошо освещён в статье на хабре. Кеш - по сути тоже память ограниченного размера. А раз размер участка памяти меньше размера данных, которые надо в нём хранить, то нужна стратегия замещения. Ну тут уж явно прослеживается связь с тем, что изучается на "Операционных системах". Выберите подходящий алгоритм либо руководствуясь полученными знаниями разработайте свой - и вперёд, к кешированию.

Третий пример пришёл мне в голову сегодня утром. Вот возьмём любой сервис, выдающий пользователю предположения о том, что ему может понравиться, на основании действий других пользователей (например, тот же Last.fm). Как это можно реализовать? Один из вариантов - хранить взвешенный граф связей между сущностями, которыми оперирует сервис, при этом вес ребра показывает, какое количество (или процент) пользователей имеет эту связь. Дальнейший механизм очевиден: если пользователю что-то нравится, мы выбираем несколько наиболее весомых рёбер, исходящих из этой вершины, и предлагаем пользователю соответствующие сущности. Если пользователь согласен с предложением, то увеличиваем вес ребра, иначе уменьшаем. Можно хранить копию графа для каждого отдельного пользователя, тогда можно начать с полносвязного невзвешенного графа, постепенно отсеивая лишние рёбра и узлы. Подумав ещё, я вспомнил алгоритм замещения дальней страницы, хотя и имеющий противоположный механизм механизм действия, но эксплуатирующий ту же идею - построение рёбер между узлами на основании обращений одной сущности к другой. Вот и ещё один пример вполне себе прикладного применения системных алгоритмов (хотя, конечно, в операциях над графами нет ничего системного - это общематематические знания).

Раздел "Файловые системы", пожалуй, один из самых близких к прикладной стороне - там рассматриваются вопросы сохранности данных, а это, пожалуй, важно и для не имеющих отношения к ИТ людей.

Если посидеть и подумать, то можно найти ещё много примеров применения знаний, полученных на системных дисциплинах, в прикладной деятельности и даже в деятельности, далёкой от ИТ.

Выводы:

Итак, сегодня на столе хирурга Cisco ASA 5505 с возможностью работы в качестве центра сертификации (Certification Authority, CA). Вы включаете эту возможность, создаёте пару пользователей, выписываете одному сертификат, а второму сертификат не выписывается. Вместо сертификата вас выкидывает на окно логина по адресу /+CSCOE+/login.html. Что делать?

В моём случае я включил debug crypto ca server 255 и получил строки, из которых следовала невозможность создания файла в формате PKSC#12. Поиск по коду ошибки дал ровным счётом ничего.

Помог случай - я, в очередной раз начав сначала, выставил длину ключей в сертификатах CA и клиентов в 1024 бита вместо 2048. Внезапно заработало. Может, и у вас заработает :)

Выводы:

Настраивается отправка корреспонденции из Trac заинтересованным людям. Используется связка postfix+dovecot+Active Directory. И вылазит эта ошибка. Что делать?

Так как Trac использует собственную реализацию SMTP-клиента, а разрешать узлу в DMZ выполнять отправку почты без проверки учётных данных плохо, для него была создана учётная запись trac в Active Directory. В процессе решения проблемы перво-наперво был изменён пароль, так как предыдущий содержал символ '\', а у RDP-клиента rdesktop известна проблема с передачей этого символа. Это ключевой момент, мы к нему ещё вернёмся.

Итак, пароль изменён, а всё равно почта не уходит. Отлично, ldapsearch нам в руки:

Вводим пароль и - опачки - работает. Отлично, гуглим. Встречаем упоминания о записи имени входа в разных нотациях: user@fqdn, user@DOMAIN, DOMAIN\user. Все эти нотации задаются в /etc/dovecot.conf и 

/etc/dovecot-ldap.conf последовательно, но каждый раз ldapsearch результат даёт, а отправка почты усердно не работает. Что делать?

Тут нам поможет Wireshark, запущенный между Trac и Active Directory. Wireshark показал, что в двух случаях (ldapsearch и trac) передаётся разный пароль. А теперь вспомним, что пароль мы меняли. Но есть большое НО: пароль я заключил в кавычки. И эти кавычки успешно схавались как часть пароля. После удаления кавычек всё заработало. Правда, письма гуглом оцениваются как спам, но над этим можно поработать :)

Выводы:

Представьте, что у вас в руках оказалась неизвестная (или известная, но забытая) железка, которой вы очень хотите поуправлять, но для управления требуется знать её IP-адрес (например, для входа через web-интерфейс или telnet). А железка 100 лет провалялась на складе / вам её подарили / вы другим образом забыли настройки IP. Как быть?

Лучший вариант решения этой проблемы - чтение документации. Там обычно есть и настройки IP по умолчанию, и описываются способы сброса до заводстких настроек. Возможно, устройство имеет порт для подключения последовательного терминала. В этом случае ваши шансы на успех равны 95%, 5% остаются на неисправность консольного порта и кривоту документации.

Но что делать, если документация писана криворукими индокитайцами или отсутствует вовсе, а железка относится к той категории, в которой и говорить о консольном порту неприлично?

Как везде, тут есть 2 способа: активный и пассивный. Начнём с пассивного, он проще и быстрее.

Нам поможет tcpdump. Подключаетесь напрямую к сетевому порту устройства и натравливаете tcpdump -vn на соответствующий интерфейс. Варианты могут быть следующими:

Могут быть и другие варианты, но все они сводятся к предыдущим: либо мультикаст, либо броадкаст, другого не дано, уникасты вы не перехватите, потому что им взяться неоткуда.

Если пассивный метод не помогает, приходится переходить к активному. В случае IPv4 активный метод может дать гарантированный результат за приемлемое время (а чего вы хотели? Не помогает анализ - остаётся только полный перебор). В случае IPv6 множество вариантов существенно мощнее, поэтому предлагаемый метод не сработает.

Предлагаемый метод будет более эффективным, если можно сделать какие-то предположения об IP-адресе. Так, например, для популярного частного диапазона 192.168.0.0/16 можно использовать следующий сценарий:

В данном сценарии используется протокол ARP для поиска соседей по локальной сети.

Естественно, чем менее точно вы можете сделать предположение об адресе, тем большее множество адресов придётся перебирать. В худшем случае придётся делать полный перебор. Не забывайте, что в этом случае перед сканированием вам надо будет сменить IP-адрес устройства так, чтобы этот адрес принадлежал опрашиваемому на данной итерации диапазону..