Блог

Google Apps FTW! (Блог переехал)

Отправлено 17 мар. 2014 г., 04:46 пользователем Константин Ханкин

Всем привет!

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

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

Чем это хорошо для всех вас:
  1. каждый возжелавший студент получает гугло-аккаунт, к которому подключена почта, диск, календарь, сайты (вы же всегда хотели создавать сайты просто и быстро? ;) ) и так далее. Первые записавшиеся уже могут получить учётные данные у Ирины Марковны в 806/3б;
  2. всё это хостится гуглом и не стоит кафедре ни копейки, при этом обслуживание остаётся за гуглом, а не за намивами;
  3. можно грабить корованышарить календари и файлы - короче, всё, как во "взрослых" гуглосервисах. А теперь придумайте, как это использовать (это же не очень сложно, правда?).
К чему это приведёт:
  1. почта без спама, больше фишек и надёжности;
  2. так как университет пытается своими недоделкамисервисами заменять то, что на кафедрах создавалось и развивалось годами, кафедральная инфраструктура будет неизбежно урезаться и сокращаться (уже под нож пошли почта и старый сервер репозиториев). Google Apps позволят заменить conf.comp.susu.ac.ru на Hangouts, //share/ на Drive (хотя бы частично), www.comp.susu.ac.ru и прочий хостинг на Sites и AppEngine. Ну а календаря вменяемого у нас и не было никогда;
  3. больше возможностей для эффективного образования (при вашем желании, как обычно).
Как пользоваться:
  1. comp.susu-ссылки - mail.comp.susu.ac.ru, sites.comp.susu.ac.ru, drive.comp.susu.ac.ru, cal.comp.susu.ac.ru, groups.comp.susu.ac.ru, только аутентифицироваться надо под своей гугло-учёткой;
  2. все обычные гугло-URL работают, только жмякните на свою фотографию, а дальше - кнопку "Другой аккаунт".
До сих пор не понимаю, почему я эту вкусноту получил больше года назад, а начал разворачивать только сейчас. Пользуйтесь на здоровье и для пользы дела!

О вреде STP, приложенного к кривым рукам

Отправлено 17 мар. 2014 г., 04:27 пользователем Константин Ханкин   [ обновлено 17 мар. 2014 г., 05:01 ]

Небольшое творчество студенческое в качестве заглавия:
STP vs RSTP


Итак, представим себе такую сеть: есть есть несколько компьютеров, подключенных к одному коммутатору. К этому же коммутатору подлючен ещё один, существенно более старый (каталист с 12.0). Компьютеры загружаются с сети (если быть точным, тянут /home с сети по GlusterFS, что в нашем случае несущественно). Помимо компьютеров подключены и другие устройства, получающие адреса с DHCP. Всё замечательно, пользователи довольны.

В один прекрасный день в приступе паранойи я решаю включить STP. Никаких особых предпосылок к этому нет, все розетки контролируются, пользователи лишнего не делают, но ведь правильно же с STP! Начинаю делать и обнаруживаю, что в IOS 12.0 нет поддержки RSTP и portfast. Пофиг, включаю STP, приоритетом задаю корневой коммутатор - красота, завелось. Тестирую, что всё работает (ничего не перезагружая, это важно!). И довольный ухожу.

На следующий день получаю жалобу - компьютеры загружаются с 10 раза, а где-то не загружаются вообще. Сетевые принтеры не печатают. Начинаю копать. Выясняется, что DHCP-клиент получает адрес сильно позже момента, когда надо монтировать /home. При этом, хотя сетевая ФС замечательно переживает разрывы сетевого соединения длительностью даже в несколько десятков минут, она абсолютно не терпит отсутствия подключения в момент монтирования.

Первое желание какое? Правильно, увеличить таймауты, ведь руками-то сделанное всё работает! Другое желание - делать монтирование в rc.local вместо fstab, проверяя наличие адреса и подключения. Но некрасиво же, работало! Хватит искать воркэраунды, думать надо! Минута на раздумия - и простой вывод: STP не успевает перевести порт в Forwarding до истечения таймаута.

В моём случае поднимать таймауты до минуты и более было плохо. Так что был просто отключен STP. Всё снова заработало, как раньше.

Выводы:
  1. Прежде, чем что-то сделать - подумайте, спланируйте. Plan->Do->Check->Act, а никак не (Fuck Off Planning)->Do->(Fuck Off Checking).
  2. Если что-то сделали - тестируйте всесторонне. Для этого нужен предварительно подготовленный план тестирования. Предварительно подготовленный!
  3. Не всегда надо сразу кидаться клепать воркэраунды. Иногда докопаться до сути проблемы и вернуть всё взад как было не так уж и долго, как может показаться.

Некоторые особенности коммутаторов Allied Telesis

Отправлено 17 мар. 2014 г., 04:25 пользователем Константин Ханкин

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

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

Итак, первый номер программы - коммутатор 3 уровня Allied Telesis AT-9424Ts/XP:
  1. Оно не умеет отправлять ICMP Time Exceeded! Это просто я даже не знаю, как описать. Перевожу на русский язык: вы никогда не увидите этот коммутатор в выводе traceroute. Да он умеет 6 видов DoS-атак определять, а вот ICMP Time Exceeded отправить - нет! Прежде, чем сообщить мне эту рабостную новость и посоветовать переход на серию х600, инженер поддержки попросил установить патч, поплясать с бубном, принести жертву и так далее. Как в советском анекдоте про перчатки.,
  2. Оно умеет BOOTP Relay (который одновременно и DHCP Relay), но не умеет опцию 82! Ну как так... Благо, хоть как релей работает нормально (в смысле, gi_addr вставляет корректно). Wait, OH SHI--
  3. BOOTP relay в сочетании с другим коммутатором, подключенным через транк, ведёт себя не так, как ожидается. Топология такая: к 9424 подключен DHCP-сервер, 2 порта 9424 объединены в статический транк, поверх этого транка прокинуты несколько виланов, транком зацеплен коммутатор, к которому подключены абоненты. И теперь внимание, вопрос: будет ли нормально работать BOOTP/DHCP Relay? Конечно, нет! Он будет работать так: при запросе адреса 9424 начинает искать владельца запрашиваемого адреса с помощью ARP Query (ну вроде как логично, хотя это запота DHCP-сервера вообще-то), а если ответа не получит, то... продолжит спрашивать! И так до бесконечности. Избавление от транка и заведение абонентов напрямую на 9424 излечило проблему. Да только вот 9424 - не коммутатор доступа так-то. Иногда было забавно: клиент долбится-долбится, пытается в муках получить адрес, в конечном итоге плюёт и выбирает себе LL-адрес (169.254/16). И вот теперь DHCP отрабатывает корректно! Ещё веселее загрузка по PXE: сетевая карта успешно (с 5 таймаута) таки получает адрес и получает по TFTP загрузчик. А в процессе загрузки станция получить адрес уже не может - некому на ARP ответить.
  4. Процедура настройки SSH, гм, нетривиальная, ну да ладно. Сам коммутатор ключ сгенерировать не в состоянии. Да D-Link DGS-3024 при всём при том, что по SSH отчаянно тормозил, ибо мощи процессора не хватало, а всё же мог сгенерировать ключ. Да точка доступа D-Link DWL-2100AP при всей своей глючности умеет генерировать ключ (или использовать вшитый). А вот стекируемый коммутатор уровня 3+ с защитой от DoS и всесторонней поддержкой IPv6 - нет. Стыдоба.
  5. Глючит веб-интерфейс. Нет, не так. ГЛЮЧИТ. ГЛЮЮЮЮЮЮЮЮЧИТ. Мало того, что не всё можно через него настроить, так ещё и картинки прыгают с места на места. Я не смог найти браузера, в котором веб-интерфейс стабильно бы НЕ ГЛЮЮЧИЛ. Пример: лого АТ, обычно занимающее место в левом верхнем углу, внезапно оказывается там, где была кнопка Accept. И вот иди угадывай.
  6. AWPlus. Этот непонятный внебрачный сын АТ и Cisco. Если АТ хотели так облегчить переход цискоадминов на АТ - они ошиблись. Извращено почти всё. Плюс, традиционно, не всё можно настроить.
  7. Сработка Link Flap Protection и отправка порта в даун - не повод отправить snmp trap или хотя бы выделить событие как warning/error. Это Informational-событие. Вот так вот. Автоматического, по прошествии некоего времени, вывода порта из дауна нет. Шансов узнать о сработке минимум.
При всём при этом нельзя сказать, что железка - шлак. Свою работу, за исключением мелких неприятностей выше, выполняет на отлично. Несёт на борту 24 гигабитных порта и 2х10G, действительно умеет стек, LACP на весь стек, богатые фишки в плане IPv6, без мороки с лицензиями, как в циске. Однако 9924T, хотя и более старый, но более фичастый и стабильный. И неясно позиционирование этого устройства: судя по уровню 3+, возможностям классификации трафика и богатому QoS, стекированию, 10G - это, как минимум, уровень распределения. Но ряд проблем делает невозможым полноценное испольнование этой железки на распределении - только на доступе (см. проблему с DHCP Relay). А так как оно EoL - обновлений больше не будет.

Второй номер - коммутатор доступа AT-GS950/n, где n - количество портов. Не путать с GS900/n. Итак:
  1. Нет доступа к МАС-таблице. Совсем. Никак. Ни в веб-интерфейсе, ни через SNMP, ни через консоль. Happy Debugging!
  2. Нет доступа через SSH или хотя бы Telnet. Или веб-интерфейс, или СОМ-консоль.
  3. Есть фича Management VLAN, запрещающая доступ к управлению из любого VLAN, кроме VLAN 1 (VID Management VLAN сменить нельзя). Только она не работает.
  4. Для работы 802.1х необходимо, чтобы порт,  которому подключен RADIUS-сервер, был включен нетегированным в VLAN 1 (VID сменить нельзя). Кстати, тот же 802.1х работает нестабильно. То есть может сработать, а может и не сработать. 802.1х с аутентификацией по МАС-адресам работает с Guest VLAN почти никак - то есть шансов попасть в Guest VLAN у неаутентифицированной станции минимум.
  5. Веб-интерфейс любит плеваться ошибками 400 Bad Gateway, ничего не объясняя. Особенно забавна такая комбинация: через консольный интерфейс вы настраиваете VLAN неправильно (например, добавляете порт как untagging более, чем в один VLAN), после этого пытаетесь сделать какие-то настройки VLAN через веб-интерфейс и - правильно! - 400 Bad Gateway. Берёте консольный кабель и лезете в пыльную подсобку перенастраивать коммутатор.
  6. Шизанутый терминальный интерфейс - в виде меню. Тыкаешь букву - получаешь активацию пункта. Вроде некритично, но через 5 минут задалбывает до колик. Особенно навигация по этим многоэтажным менюшным конструкциям.
  7. При настройке Port VLAN ID нельзя задать диапазон портов. Вообще нельзя. Несёт комутатор на борту 24 порта - настраивай все 24 порта отдельно.
  8. Удалив VLAN 1, нельзя восстановить его обратно никак, кроме полного сброса. А VLAN удаляется, если в нём не осталось ни одного порта. Мило.
Зато это вполне себе бюджетный гигабитный коммутатор 2 уровня с физической консолью и 802.1х. Даже транки поддерживает.

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

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

Как я с BCC-спамом боролся

Отправлено 17 мар. 2014 г., 04:24 пользователем Константин Ханкин

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

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

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

Казалось бы, решение очевидно: проверять адрес получателя в заголовке To, и если такового получателя нет в базе получателей, отклонять письмо. Но, как обычно есть нюансы:
  1. база получателей может быть просто недоступна - не у всех получатели являются реальными пользователями (то есть есть в passwd) или хранятся в БД, напрямую доступной с почтового сервера;
  2. в письмах, отправляемых вашими пользователями, в заголовке 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 Spam
reject "BCC Spam detected"
header /^From$/i /comp.susu.ac.ru/in and (not header /^To$/i /comp.susu.ac.ru/i) and (not header /^Cc$/i /comp.susu.ac.ru/i)
творит чудеса:
germaseriosd.ru[193.105.174.36]: 5.7.1 BCC Spam detected;
germaseriosd.ru[193.105.174.36]: 5.7.1 BCC Spam detected;
germaseriosd.ru[193.105.174.36]: 5.7.1 BCC Spam detected;
germaseriosd.ru[193.105.174.36]: 5.7.1 BCC Spam detected;
fep-mail-smtpout-l2e.virgilio.net[212.48.21.155]: 5.7.1 BCC Spam detected;
mailout09.t-online.de[194.25.134.84]: 5.7.1 BCC Spam detected;
eastrmfepi202.cox.net[68.230.241.206]: 5.7.1 BCC Spam detected;
ask.lipowa.net[83.19.180.34]: 5.7.1 BCC Spam detected;
spamfilter2.starnet.md[178.168.2.134]: 5.7.1 BCC Spam detected;
vps3390.inmotionhosting.com[69.174.115.191]: 5.7.1 BCC Spam detected;
out06.smtpout.orange.fr[193.252.22.215]: 5.7.1 BCC Spam detected;
smtprelay0215.hostedemail.com[216.40.44.215]: 5.7.1 BCC Spam detected;
germaseriosd.ru[193.105.174.36]: 5.7.1 BCC Spam detected;
germaseriosd.ru[193.105.174.36]: 5.7.1 BCC Spam detected;
germaseriosd.ru[193.105.174.36]: 5.7.1 BCC Spam detected;
germaseriosd.ru[193.105.174.36]: 5.7.1 BCC Spam detected;
germaseriosd.ru[193.105.174.36]: 5.7.1 BCC Spam detected;
germaseriosd.ru[193.105.174.36]: 5.7.1 BCC Spam detected;

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

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

Как я сервер из небытия восстанавливал

Отправлено 17 мар. 2014 г., 04:06 пользователем Константин Ханкин

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

Собственно, суть. Из-за старательной поддержки жары в серверной и нестабильной работы одного из пары дисков в сервере развалилось зеркало. Rebuild интегрированными средствами не помог, а только усугубил ситуацию - все файлы, которые были открыты, которые открывались, с которыми велась работа, повредились: что-то превратилось из файла в каталог, что-то наоборот, где-то посеклись или превратились в кашу данные, что-то ВНЕЗАПНО стало симлинком, ну и так далее. В общем, праздник в сумасшедшем доме. Во итоге имеем:
  • повреждённое ядро;
  • перекособоченная политика SELinux;
  • мешанина из файлов, каталогов, симлинков и прочей фигни, бинарники и библиотеки незначительно, но задеты;
  • неработающий yum;
  • повреждённая база rpm;
  • половину конфигов открываешь - а там кровища и холодильник стоит! снесло дедушке начисто, половину перемешало;
  • ??????
  • PROFIT!!!!
Больной скорее мёртв, чем жив. Но нас таким не напугаешь :)

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

Первым делом, была предпринята попытка восстановить работоспособность 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.

Выводы:
  1. Делайте бэкапы. Делайте, говорю. Бэкапьте всё, что представляет хоть малейшую ценность.
  2. Создавайте сценарии автоматического развёртывания систем, даже если парк этих самых систем у вас невелик. Бэкапы с kickstart'ом позволили бы сократить время простоя с полутора недель до пары часов и избежать неприятных случайностей.
  3. Используйте средства управления конфигурациями - это позволит вам меньше трепетать за целостность своих конфигов.

#61101 [Com,Ver->Csd]

Отправлено 17 мар. 2014 г., 03:57 пользователем Константин Ханкин

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

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

О практическом применении знаний курса "Операционные системы"

Отправлено 17 мар. 2014 г., 03:56 пользователем Константин Ханкин   [ обновлено 17 мар. 2014 г., 03:58 ]

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

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

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

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

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

Выводы:
  1. Преподаваемые предметы могут содержать в себе больше, чем кажется на первый взгляд.
  2. Знания, получаемые на дисциплинах системного курса, могут пригодиться в практической деятельности прикладного программиста.
  3. Думайте, размышляйте, анализируйте и синтезируйте, понимайте суть.

Проблема с генерацией сертификатов в Local CA в Cisco ASA

Отправлено 17 мар. 2014 г., 03:54 пользователем Константин Ханкин

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

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

Выводы:
  1. Не всегда вся имеющаяся функциональность работает
  2. Даже если вам кажется, что с используемым набором параметров всё должно работать - попробуйте другое сочетание, просто на всякий случай

80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece

Отправлено 17 мар. 2014 г., 03:53 пользователем Константин Ханкин

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

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

Итак, пароль изменён, а всё равно почта не уходит. Отлично, ldapsearch нам в руки:
ldapsearch -b "ou=People,dc=comp,dc=susu,dc=ac,dc=ru" -x -W -h dc1.local -D 'trac@comp.susu.ac.ru'

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

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

Выводы:
  1. Читайте документацию: вероятнее всего, в ней написано о формате написания параметров
  2. Если что-то упорно не работает, попробуйте убрать разделители там, где это не является явной глупостью :)

Полезные мелочи 1: как определить IP-адрес сетевого устройства

Отправлено 17 мар. 2014 г., 03:52 пользователем Константин Ханкин

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

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

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

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

Нам поможет tcpdump. Подключаетесь напрямую к сетевому порту устройства и натравливаете tcpdump -vn на соответствующий интерфейс. Варианты могут быть следующими:
  • устройство настроено на получение адреса по DHCP, тогда после перезагрузки его вы увидите пакеты DHCP Discovery;
  • устройство настроено на участие в multicast-группе (например, используется протокол OSPF). Периодически в эфире будут появляться пакеты IGMP;
  • устройство настроено на участие в широковещательном протоколе (например, NetBIOS или IAPP).
Могут быть и другие варианты, но все они сводятся к предыдущим: либо мультикаст, либо броадкаст, другого не дано, уникасты вы не перехватите, потому что им взяться неоткуда.

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

Предлагаемый метод будет более эффективным, если можно сделать какие-то предположения об IP-адресе. Так, например, для популярного частного диапазона 192.168.0.0/16 можно использовать следующий сценарий:
#!/bin/sh
ifconfig eth0 192.168.0.1 netmask 255.255.0.0
nmap -sP 192.168.0-255.2-254 | grep up

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

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

1-10 of 18