О пользе обходов

Не так давно, во время ремонта помещений офиса, мы развернули в здании дополнительную электропроводку, предназначенную для подключения критичного оборудования (компьютеры, мониторы) к централизованному ИБП. Были установлены короба с розетками красного цвета, на каждую розетку помещена наклейка "резерв 220V", проведена разъяснительная работа среди персонала.

Спустя некоторое время я обратил внимание, что нагрузка на ИБП скачет с 40% на 100% и обратно в течение нескольких минут. Был проведён обход кабинетов с целью обнаружения несанкционированных подключений. Вот результат:

  • Три чайника;
  • Кондиционер;
  • Холодильник;
  • Четыре лазерных принтера.

Но в одном кабинете я обнаружил торчащим из розетки вот такой шедевр:

Первая мысль была - теракт. Потом пошарил вокруг и вот что обнаружил:

Подробнее:

Локальный IM-сервер - OpenFire

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

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

  • Систему нельзя администрировать централизованно. Нет центрального административного узла, соответственно нельзя сформировать и поддерживать единое адресное пространство.
  • Сервис ICQ подвержен сбоям. Причин может быть много, от глобальных экспериментов AOL до хакерских атак.
  • ICQ часто используется для рассылки спама.
  • Через ICQ может быть произведена атака на сеть организации извне.
  • Сообщения (и файлы!) передаются по открытым сетям.

А что если переместить ICQ-сервер из глобальной сети в локальную? По этому пути пошли разработчики системы SIQ. Но что если пойти ещё дальше и отказаться от протокола ICQ? Ведь AOL в любой момент может изменить протокол, и с локальным сервером будут работать только определённые - старые - версии клиентов. Оптимальным выбором в этом случае представляется открытый протокол, поддерживаемый максимально обширным рядом клиентов. Это Jabber.

Jabber имеет ряд преимуществ по сравнению с коммерческими системами IM (информация из Википедии):

  • Открытость: протокол Jabber открыт, общедоступен и достаточно лёгок для понимания; существует множество реализаций серверов и клиентов, а также библиотек с открытым исходным кодом.
  • Расширяемость: с помощью пространств имён в XML можно расширить протокол Jabber для выполнения требуемых задач и для обеспечения поддержки взаимодействия между различными системами. Общие расширения разрабатываются под контролем Jabber Software Foundation.
  • Децентрализованность: кто угодно может запустить свой собственный сервер Jabber, что позволяет организациям и частным лицам заниматься любыми экспериментами с IM.
  • Безопасность: любой сервер Jabber может быть изолирован от общедоступной сети Jabber, многие из вариантов реализации сервера используют SSL при обмене между клиентом и сервером, и немало клиентов поддерживают шифрование с помощью PGP/GPG внутри протокола.

Итак, для реализации внутренней Jabber-службы по обмену сообщения необходимо определиться с серверной частью. Основных (достаточно мощных и в то же время бесплатных) претендентов два: OpenFire и ejabberd. OpenFire обыгрывает оппонента по функциональности, а также по динамике развития. И несмотря на недостатки OpenFire (например, более высокие требования к вычислительным ресурсам), я остановил свой выбор именно на этом продукте.

Процесс развёртывания OpenFire состоит из следующих шагов:

Подробнее:

Личная база знаний - TikiWiki

Количество проблем, с которыми может столкнуться системный администратор, очень велико. А объём знаний, необходимых для их решений, давно превышает возможности человеческой памяти. Каждый день появляются новые продукты и направления деятельности, за которые приходится отвечать. Иногда уже завидуешь рабочему с мануфактуры 19 века, который десятилетиями мог выполнять одну и ту же простую операцию...

Особенно обидно, когда столкнувшись с проблемой во второй и третий раз, не можешь навскидку вспомнить способы её решения. Начинаешь записывать, но количество записей быстро растёт, и на поиск уходит слишком много времени. Можно также использовать программы для управления заметками, коих существует в избытке, и некоторые так и поступают. Для себя же я решил проблему так: личные заметки хранить в MS OneNote 2007, а рабочую информацию - в личной базе знаний, организованной по вики-технологии.

Почему вики? Вики-системы не навязывают пользователю излишней упорядоченности, вместе с тем предлагая гибкие инструменты для отбора и поиска во множестве материалов. Из книг отечественного гуру тайм-менеджмента Глеба Архангельского я вынес такую мысль: не нужно стремиться упорядочить всё и вся. Излишние усилия на наведение порядка не только не окупятся, но и задушат возможности нестандартной интерпретации и творческой работы. Говоря иначе, должны быть "мусорки", или "места хаоса", и нужно в конечном итоге находить баланс между порядком и ленью.

Исследовав множество вики-движков, среди котрых был и mediawiki, на котором работает википедия, я остановил свой выбор на TikiWiki как на системе с наибольшим набором функций.

При том что версия продукта доросла до почётной двойки, поражает его некоторая "сыроватость". Но если вы готовы терпеть некоторые "причуды" ради функциональности, то несомненно TikiWiki - ваш выбор.

 

Подробнее:

Корпоративные пакеты ПО - Инструменты для сборки

Как сделать жизнь админа проще? С ростом парка машин в организации этот вопрос становится всё острее. Мне очень нравится аналогия из одной книги по тайм-менеджменту. Представьте, что вы находитесь в подвале, и кружкой вычерпываете прибывающую воду. Повышение эффективности в этом случае - взять кружку побольше. Но так ли нужна такая эффективность? Ведь если бросить кружку и поразмыслить - можно или взять насос, или перекрыть вентиль, если проблема в трубе!

Представьте себе несколько сотен компьютеров, на которые вы должны установить определённую программу, а затем произвести её настройку. Теперь представьте, что таких программ - множество. Кстати, человек - не машина, и повторяющиеся многократно действия - это не лучшее применение для его возможностей. Представьте, что необходимо произвести массовую установку, например, почтовой программы Mozilla Thunderbird. Программа вполне надёжна и очень функциональна, но только после установки и настройки плагинов (в моей сборке, к примеру, их 12). Каждый плагин имеет множество настроек. Если делать всё вручную - непременно будут допущен ряд ошибок на различных машинах. И в результате мы получим разношёрстный парк машин, на каждой из которой могут появиться свои глюки.

В противоположность "варианту с кружкой": а что если создать собственный дистрибутивный пакет программы, максимально адаптированный к нуждам организации? Установка программ исключительно из таких пакетов служит очень благой цели: единообразию конфигураций на всём множестве машин. Таким образом, столкнувшись с проблемой на одной машине мы уже будем знать, при каких условиях все остальные машины будут подвержены той же проблеме. Наиболее оптимальный вариант - создать пакет в виде msi-файла, что позволит распространять программы через политики домена Windows.

Итак, у нас есть дистрибутив программы. Как собрать msi-пакет? Процедура эта относительно несложная и состоит из следующих шагов:

Подробнее:

Двухфакторная аутентификация пользователей - eToken

Чем выше ценность информации, к которой есть доступ у пользователя, тем лучше эта информация защищена. По крайней мере, так должно быть. На практике же сплошь и рядом в сфере разграничения прав пользователей - полный бардак. Первый шаг по наведению порядка назначение каждому пользователю уникальной учётной записи в системе, и устранение возможности входа в систему под чужим именем. Сначала говорим пользователям убрать пустые пароли (если на этот момент они ещё не запрещены политикой), и пользователи с честными лицами выставляют пароли типа "1234" или "год рождения". Затем назначаем политикой требования к сложности паролей (скажем, шесть символов, обязательно наличие разных регистров - скажем, aB1234) - пользователи как по команде пишут пароли на листочках и лепят на мониторы. Этим исчерпываются возможности метода "что я знаю" для аутентификации пользователей. Другой вариант - использовать метод "что у меня есть" - отпечаток пальца, сетчатка глаза (что пока слишком экзотично), или некоторое устройство. Примером такого устройства являются продукты семейства eToken российской компании Aladdin.

Подробнее:

Вы здесь: Home Администратору