пятница, 29 августа 2008 г.

Очередное странствие

Переехал наконец-то на домен второго уровня.
WWW.STRANGEMAN.RU
Читать дальше.

четверг, 26 июня 2008 г.

Ubuntu Mobile Internet Device Edition

Компания Canonical, коммерческий спонсор проекта Ubuntu, представила первую публичную версию операционной системы Ubuntu Mobile Internet Device Edition (Ubuntu MID), получившую индекс 8.04.


Программная платформа Ubuntu MID, как следует из названия, предназначена для
использования на мобильных интернет-устройствах. Новая ОС базируется на коде
Ubuntu Desktop Edition и содержит ряд приложений, специально адаптированных под
небольшие экраны гаджетов. В состав Ubuntu MID 8.04, в частности, входят
веб-браузер, построенный на основе движка Mozilla Gecko, клиент электронной
почты, книга контактов, календарь и медиаплеер. Кроме того, в Ubuntu MID 8.04
включена поддержка средств управления через сенсорные дисплеи.


Несмотря на то, что желающие уже могут загрузить операционную систему Ubuntu MID 8.04, ориентирована она, прежде
всего, на разработчиков и изготовителей комплектного оборудования. Первые
устройства на базе Ubuntu Mobile Internet Device Edition, как ожидается,
появятся на рынке ближе к концу текущего года.


Источник новости

Читать дальше.

четверг, 19 июня 2008 г.

Парад багов в популярных браузерах

Немножко ретро. Статья Криса Касперски из февральского номера ][акера о уязвимостях в популярных браузерах.

Кто-то верит в Деда Мороза, а кто-то в браузеры без дыр. Попытка оспорить постулат веры приводит как минимум к гигабайтам флейма. Провокация? Нет, всего лишь статья, в которой мы объективно сравниваем различные типы браузеров на предмет безопасности по куче критериев сразу, подтверждая сказанное не только всем весом своего авторитета, но и обширным фактическим материалом.


Стремительный рост уязвимостей в пятой (и особенно шестой) версии IE вынудил продвинутых пользователей перейти на альтернативные браузеры, на которые хакеры уже давно перешли (ну, хакеры - они всегда в авангарде :)). Конкуренты четко просекли ситуацию, сделав ставку на безопасность: «С Firefox Вы повысите свою безопасность и удобство серфинга», «Opera предоставляет самый быстрый, безопасный и простой в использовании браузер». Не отстает от них и Microsoft, но при всей агрессивности маркетинга последней ее рекламе больше никто не верит, и ошибки в IE обнаруживаются чуть ли не ежедневно, а каждая шестая среди них критическая. Не браузер, а сплошное решето. Работать с ним и шарахаться от каждого шороха способны либо экстремалы, либо чайники. Остальные уже давно забили и мигрировали в иные миры, откуда уже не возвращаются. Действительно, посидев на Горящем Лисе или Опере недельку-другую, работать под IE больше не хочется.


Что-то у конкурентов реализовано получше, что-то - похуже, но дело ведь не в качестве кода и удобстве использования, а в безопасности! Ругая IE, поклонники альтернативных браузеров совершенно наплевательски относятся к собственной security, не следят за новостями, не скачивают обновлений и вообще ведут себя так, как будто ни дыр, ни хакеров, ни прочих угроз в природе не существует. Между тем дыры есть везде, в том числе и в текстовых браузерах типа Рыся, просто о них непринято говорить. Почему? Очень просто. Microsoft первая попадает под перекрестный огонь специалистов по безопасности и сетевых обозревателей, а продукция сторонних фирм традиционно остается в стороне, к тому же журнальный бизнес придерживается правила «бей сильных и не ввязывайся в священные войны». Писать о дырах в Лисе зачастую просто небезопасно. Тут же закидают гнилыми помидорами и тухлыми яйцами. А вот дыры в IE – это почетно!


Ладно, оставляем лирику и переходим к статистике.


Горячий Лис


Firefox, собранный на обломках заживо похороненного (а затем эксгумированного и реанимированного) Netscape, просто не может быть надежным браузером по определению. Фирма Netscape была первой, кому пришла в голову мысль внедрить в браузер поддержку Java-скриптов, и дыры в Netscape водились уже тогда, когда Билл Гейтс еще не вкурил в интернет, и не помышляя, что интернет — это тема.


Войну между Microsoft и Netscape мы оставим на растерзание историкам (им же тоже нужно чем-то питаться), а сами сосредоточимся на достигнутых результатах. Netscape раскрыла исходные тексты своего продукта и начала привлекать к разработке всех желающих, но желающих не было, и кворума собрать не удалось. Кому из опытных программистов интересно тратить время и силы на мертвый проект, не получая ни прибыли, ни отдачи, в смысле — ни удовлетворения, ни денег? Чтобы собрать команду, понадобилось несколько лет, и мало-помалу новый продукт (окрещенный Горящим Лисом, или по-английски Firefox'ом) стал завоевывать рынок.


Первые версии Лиса были ужасны. Часть сайтов вообще не открывалась или отображалась неправильно, оперативная память стремительно утекала, производительность (а точнее, полное отсутствие таковой) настойчиво напоминала о себе с первой до последней минуты работы с Горящим Лисом, требуя его периодического перезапуска (чтобы вернуть системе утекшую память).


А чему удивляться? Код Лиса написан на смеси приплюснутого Си и жабы, а жаба — это уже тормоза. Причем если IE разбит на множество динамических библиотек, загружаемых в память по мере необходимости (и даже базовые библиотеки грузятся одновременно с отображением пользовательского интерфейса, создавая иллюзию быстрого старта), то у Горящего Лиса все свалено в огромный исполняемый файл. Ну разве можно так делать?! Но это еще что. Настройки браузера разбросаны по сотням файлов, эти файлы представлены в текстовом формате, и при каждом своем запуске браузер вынужден парсить их заново. Вот, такая, значит, у них оптимизация.


С низкой скоростью работы можно было бы и смириться (зачем торопиться на кладбище?), но только не с катастрофической ситуацией с безопасностью. Компоненты браузера, написанные на жабе, освобождают его от ряда «врожденных болезней» языка Си типа переполняющихся буферов, которыми так знаменит IE, но в Лисе довольно много приплюснутого кода, и ошибки переполнения (ведущие к удаленному захвату управления компьютером) в нем все-таки имеются, пускай в меньших количествах, чем в IE. Плюс общие ошибки дизайна и кривой (изначально) HTML-движок, добавление новых фич в который ломает всю систему безопасности, образуя многочисленные дыры по всему охраняемому периметру.


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


Впрочем, мы вновь углубились в лирику, а обещали статистику. ОК, открываем www.securityfocus.com (можно прямо в Лисе), вбиваем в строку поиска Mozilla Firefox и получаем 6 страниц уязвимостей по 30 штук в каждой, причем целый ряд уязвимостей носит множественный характер. На самом деле в Горящем Лисе за всю его историю найдено не ~180 дыр, а намного больше. Тот факт, что большинство уязвимостей обнаруживают сами же разработчики, оперативно затыкая их, ничего не меняет. Другой вопрос, что сообщение о дыре - это всего лишь текст, а не исполняемый файл, и вовсе не очевидно, что эта уязвимость действительно представляет реальную угрозу. Атакующему предстоит не только разобраться в технических аспектах (которые обычно не разглашаются), но и решить многие другие проблемы.


Короче говоря, не каждая дыра - это нора. Угроза исходит главным образом от публичных эксплойтов, которыми может воспользоваться любой желающий. Ему и хакером быть необязательно. Навыков продвинутого пользователя обычно оказывается вполне достаточно. А раз так, идем на www.milw0rm.com, вбиваем в строку поиска Firefox и пожинаем урожай – свыше 20 эксплойтов, большинство из которых работает чисто на отказ в обслуживании. Но имеется также достаточно много дыр, допускающих засылку shell-кода с последующим захватом управления. А вот это уже не хухры-мухры! Это реальная опасность попасть под артобстрел или запустить червя на свой компьютер!


Правда, реальных случаев атак на Горящего Лиса зарегистрировано немного, и нет (или практически нет) ни одного червя, который правильно было бы назвать глистом, поскольку червей ловят и едят, а глисты заводятся сами, и попробуй потом от них избавиться! Самое неприятное, что если пользователи IE в своей массе уже привыкли к его дырам и довольно активно качают обновления (чайников и ламеров мы в расчет не берем), то поклонники Горячего Лиса, уверенные в его непогрешимости, не видят в обновлениях никакой необходимости, тем более что механизм обновлений должным образом не отлажен. Новые билды выходят нечасто, а качать мегабайты исходных текстов и геморроиться с их компиляцией — это, извините, каким же мазохистом быть надо?


Наибольшую опасность представляют уже опубликованные, но еще незалатанные дыры. Для Оперы написан симпатичный виджет, торчащий на рабочем столе и отображающий в реальном времени количество критических незаткнутых дыр для всех популярных браузеров. «Незаткнутых» - это таких дыр, лекарства против которых еще нет, и неизвестно, когда оно будет. Первое место по дырам традиционно занимает IE (на момент публикации содержащий 7 незаткнутых дыр), за ним с небольшим отрывом идет Лис (5 дыр). Опера находится в самом конце хвоста, пропуская вперед себя UNIX-браузеры, о которых мы говорить все равно не будем.


Но все же IE атакуют порядка на два, а то и на три чаще, чем Горящего Лиса! Почему? Ответ прост, как бумеранг: популярность Горящего Лиса существенно ниже, чем IE, и написание червей под него просто не окупается. К тому же Горящего Лиса устанавливают технически продвинутые люди, пользующиеся целым комплексом защитных средств и распознающие присутствие постороннего кода даже без помощи антивируса — им достаточно бросить беглый взгляд на диспетчер задач или Process Explorer Руссиновича.


Растущая популярность Лиса не идет ему на пользу. Код кривой, дырявый, практически ничем не уступающий IE. Стоит только ему существенно потеснить IE, как тысячи хакеров бросятся на поиски дыр (благо исходные тексты доступны) и начнут писать червей одного за другим. Выдержит ли Горячий Лис их натиск? С таким подходом к разработке навряд ли. Впрочем, не будем строить прогнозов, а предоставим событиям возможность развиваться собственным путем.


Опера


Браузер с закрытыми исходными текстами, но, в отличие от Лиса (основанного на кодах Netscape) и IE (построенного на базе Mosaic), разработанный с чистого листа и спроектированный сплоченной командой весьма неглупых людей. По быстродействию, надежности и удобству пользования Опера рвет конкурентов как тузик грелку, причем большинство новых фичей сначала появляется именно в Опере и только потом у конкурентов.


Единственный недостаток Оперы (по сравнению с Лисом) — крайне куцая коллекция расширений. Если для Лиса можно найти любое расширение, какое только нужно (или на худой конец написать его самостоятельно), то в Опере расширения (виджеты) появились лишь недавно. Число их невелико, а функциональность жестко ограничена архитектурой, и в основном все программисты пишут гаджеты типа трехмерных часов, календарей, органайзеров, индикаторов погоды и прочей фигни. А вот научить YouTube сохранять потоковое видео в формате mpeg4 – слабо? А ведь для Лиса таких расширений намного больше одного. Лично я написал пару расширений для www.collarme.com, чтобы с ним можно было работать без помощи мыши — одной лишь клавиатурой. Для Оперы в силу ограничений, наложенных на виджеты, такую штуку написать уже не получается (или я просто не разобрался, как это сделать).


Ошибок в Опере не то чтобы совсем нет, но явно меньше, чем в Горящем Лисе. Security Focus выдает четыре страницы ошибок (против шести в Firefox), правда многие из них критические, то есть допускают возможность удаленного выполнения shell-кода, ведущего к захвату системы, а это очень нехорошо.


На www.milw0rm.com валяется около 15 боевых эксплойтов, работающих главным образом на отказ в обслуживании, но есть среди них и парочка таких, которые забрасывают shell-код, причем как для старых версий Оперы, так и для новых. На сайте компании нет ни одного ресурса, хотя бы косвенно относящегося к безопасности (есть только рекламный логотип, типа Опера самая безопасная). Какие там упоминая о дырах или история исправлений! Даже у ненавистной всем Microsoft все это есть, не говоря уже о Лисе. В любую минуту зашел, полистал список новых багов, почитал, чем они чреваты, и вздохнув принялся скачивать обновления или всю версию браузера целиком.


Маленький секрет. На FTP-сайте компании можно найти намного больше, чем в web'е, в том числе и версии с залатанными дырами, еще не выложенные в web. Что за странная политика такая — не знаю. От атак Оперу спасает лишь относительно невысокая распространенность последней. Мне не известен ни один хакерский сайт, сконструированный специально для обстрела Оперы (Лис под удары несколько раз уже попадал, правда все заканчивалось благополучно и зараза благодаря Process Explorer'у Руссиновича подбивалась еще на излете). Закрытость исходных кодов и относительно частый выход новых версий также существенно повышает цену атаки.


Рысь


Рысем зовут текстовой браузер (он же Lynx), весьма популярный в некоторых кругах и горячо любимый мной. Графику не поддерживает, картинки не грузит, управляется с клавиатуры и серфит с такой скоростью, что только ветер в ушах свистит. Переваривает только базовые тэги HTML (да и то не все), скрипты не видит в упор, не говоря уже о всяких там плавающих фреймах. Казалось бы, ну какие ошибки при такой простоте? Тем более что новые версии практически не выходят. Да и зачем новые, когда есть неплохо работающие старые?


Тем не менее Security Focus показывает целых восемь ошибок, а на www.milw0rm.com находятся два эксплойта, захватывающие управление компьютером без всяких там отказов в обслуживании, что буквально шокировало меня, до этого верящего, что в Рысе ошибок нет и не будет. А оно вон как оказалось. Теперь я не верю ни браузерам, ни женщинам и, прежде чем вновь начать серфить Рысем не внушающие доверия сайты, тщательно изучаю его исходный код — вдруг там какой баг, о котором еще никто не знает? То есть это я не знаю, а тот, кому нужно, знает о багах все.


Вот и думай, как не стать параноиком при таком положении дел! Но все же вероятность попасть под атаку, сидя на Рысе, настолько близка к абсолютному нулю, что совершенно несущественна и ей можно на 99% пренебречь, но потенциально небезопасные сайты все-таки лучше просматривать из-под виртуальной машины. Мало ли...


Заключение


Все мы небезгрешны. И браузеры в том числе. Дыры — явление стихийное и неизбежное. Против стихии не попрешь. Самое лучше, что можно только сделать, - это прекратить верить и начать активно действовать. Следить за новостями безопасности, оперативно скачивать и устанавливать обновления/свежие версии/заплатки. Использовать многоуровневые системы защиты: брандмауэры, антивирусы... Ну и, наконец, не щелкать по подозрительным ссылкам. Кстати, существует мнение, что опаснее всего блуждать по порносайтам, но это мнение глубоко ошибочно. На нормальных порносайтах с нормальными доменами (а не на отстойниках типа xxxxx.narod.ru) зловредного контента практически не встречается :).


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


Плагины


Все браузеры (за исключением, пожалуй, одного лишь Рыся и его текстового собрата Links'а) позволяют устанавливать плагины сторонних производителей: Abobe PDF Reader, Flash Player (названия верно написаны? Думаю, Player и PDF Reader) и много еще чего. А в этих плагинах ошибки, между прочим, тоже встречаются. Причем, если плагин портирован сразу под несколько браузеров, уязвимость приобретает масштабный характер.


Так, например, в конце 2007 года была обнаружена серьезная дыра в Apple QuickTime Player, допускающая удаленный захват управления и ставящая под угрозу и IE, и Горящего Лиса, и Оперу, Сафари и некоторые другие десктопные и мобильные браузеры. При условии, конечно, что этот плагин на них установлен, а установлен он там достаточно часто.


Ладно, если без встроенного просмотра PDF еще как-то можно и обойтись (хотя какая разница? все равно, дыра выскочит при открытии сохраненного документа с локального диска), то без Flash'а живется хреново. То есть поначалу очень даже хорошо живется: реклама не грузиться и не досаждает, а развлекательные ролики можно посмотреть и под IE. Но вот начинают попадаться сайты, где часть картинок выполнена при помощи Flash-технологий (например, так поступает www.iXBT.com), и браузер начинает неизбежно обрастать все новыми плагинами.


Расширения


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


Наткнувшись на пару расширений для Горящего Лиса, незаметно ворующих пароли с кукисов, я ради эксперимента создал «троянское» расширение (в кавычках, потому что зловредность его заключалась в грозного вида диалоговом окне с надписью: «Сейчас вам будет нехорошо, а потом еще хуже»). Я был просто ошеломлен, насколько проста оказалась процедура регистрации и каких усилий стояло закачать «троянское» расширение в общий доступ. Никаких. В смысле усилий. Просто берешь и закачиваешь. И прежде чем разъяренные пользователи успели написать абузу, «троянца» скачало и установило нехилое количество человек. И ведь это был явный «троян», а если бы он действовал тихо, скрытно и незаметно, что тогда?


Сразу же возникает вопрос: какими полномочиями обладают расширения? Ответ: разработчики браузера приложили определенные усилия, чтобы эти самые полномочия не выходили за рамки приличий, ограничиваясь действиями, совершаемыми над текущей страницей браузера. А у Лиса еще и над его настройками (что дает возможность незаметно прописать хакерский прокси-сервер для кражи трафика, а потом быстро все вернуть обратно, и никто ничего не заметит). Отформатировать диск или внедрить вирус в исполняемые файлы расширения не могут. Теоретически. Практически же они написаны на жабе, и для ускорения их выполнения браузеры автоматически компилируют их код в память, а ошибок в этих компиляторах очень много. Передать управление на заранее подготовленный машинный код после такой компиляции плевое дело, а машинный код может практически все. Имеются и другие просчеты, как в механизме взаимодействия расширений с браузером, так и в жаба-машинах.


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



Оригинал статьи.
Читать дальше.

среда, 18 июня 2008 г.

Wine 1.0!

Автор: Д. Шурупов

После 15 лет усиленной разработки проект по созданию свободной (лицензия GNU LGPL) реализации WinAPI объявил о выпуске первой стабильной версии — Wine (Wine Is Not an Emulator) 1.0.
Релиз Wine 1.0 является по большей частью формальностью, поскольку принципиальных отличий от версий 0.9.x нет. Это лишь отображение того факта, что проект наконец-то «созрел» до определенного уровня и теперь по праву считает свой программный продукт стабильным. Разработчики так представили выпуск Wine 1.0: «Хотя совместимость [с Windows] до сих пор нельзя назвать совершенной, есть подтвержденная информация о тысячах приложениях, которые работают очень хорошо» (речь идет о том, что уже сейчас благодаря Wine очень многие Windows-приложения могут нормально функционировать в таких операционных системах, как GNU/Linux, FreeBSD, Solaris, Mac OS X).
Стоит также напомнить, что критерий для Wine 1.0 был определен уже давно и заключался в том, что в этом релизе должны безупречно работать такие программы, как Adobe Photoshop CS2, Microsoft PowerPoint Viewer 97/2003, Microsoft Word Viewer 97/2003, Microsoft Excel Viewer 97/2003.
Перечень Windows-приложений с информацией о том, насколько хорошо они функционируют в Wine, доступна в Wine AppDB.

Читать дальше.

Контроллер домена на SAMBA за семь шагов

Нашел тут весьма интересную статью Сергея Воронцова о настройке контроллера домена под линуксом с помощью пакета samba.

На время начала работ по установке PDC Samba+OpenLDAP мой опыт работы с LINUX-системами был относительно невелик. Одна из причин, вызвавших затруднения в дальнейшем освоении – особенности источников сведений по этой тематике. Пишут их настоящие знатоки, поэтому некоторые аспекты, предельно простые для гуру и неясные для новичка в литературе найти не всегда легко. По многим причинам начальный этап в освоении POSIX-серверов нужно каким-то образом преодолевать.
Так или иначе это удалось, мой не самый маленький домен работает, и теперь могу предположить, что полученный опыт поможет кому-то еще.


Исходный рубеж – знания и практика работы с сетевыми службами в различных операционных средах, так же как и знания, позволяющие начать работать с POSIX-системами. Так как развертывать сервер в среде LINUX полностью из командной строки первый раз нелегко (и отпугивает многих – эта статья как раз для них), выбирается дистрибутив, имеющий графические инструменты основных настроек. В моем случае это OpenSUSE 10.3. С учетом возможностей оборудования использовал версию i386. Поскольку в дальнейшем нам нужно будет развертывать резервный контроллер, а также службы, требующие защищенного соединения, в том числе и за пределами локальной сети, предусмотрим возможность шифрования клиентских подключений на основе сертификатов, подписанных собственным СА.
Варианты с максимальным упрощением настроек не рассматриваем, чтобы избежать в дальнейшем существенных переделок и остановок сетевых служб в действующем домене. Возможности Samba по использованию перемещаемых профилей, логон-скриптов и т.п. пока не задействуем. Впрочем, можно эти опции настраивать заданным группам пользователей позднее. Следует отметить, что отказаться от перемещаемого профиля получается пока только правкой настроек на Windows-клиенте.




Подготовка рабочей станции к подключению в домен


В этом поможет оснастка MMC «Политика «Локальный компьютер» - Административные шаблоны – система – профили пользователей».


Не могу гарантировать абсолютной повторяемости результата, так как итог зависит от неопределенного множества факторов для каждой конкретной реализации. Ничто не мешает инициативному и знающему администратору выбрать свой набор инструментов, схему каталога и т.д. Гипотетические альтернативные методы/способы/решения не рассматриваем – это только личный опыт для возможного повторения теми, кому нужен действующий результат и нет возможности теоретизировать, натыкаясь на многие и многие неясности.


Выражаю благодарность авторам использованных программных пакетов, а также авторам публикаций по рассматриваемому вопросу.


По тексту далее. Группы и пользователей, создаваемых нами в linux, будем называть «Posix-группы или пользователи», встроенные бюджеты (учетные записи служб и т.д.) определим как «системные», учетные записи, создаваемые в samba (в форме базы данных OpenLDAP) – samba-пользователи (группы).


Шаг1. Развертывание серверной платформы.


Сервер назовем asles.bgiki.local. Начальный метод регистрации пользователя – локальный, и кроме root никаких учетных записей не создаем. При установке выбираем KDE, файловый сервер, DNS, DHCP, LDAP, в разделе «разработка – базовая разработка» - Perl. Необходимо установить пакеты из состава дистрибутива: openldap2-devel, openssl-certs, pam_cifs, pam_smb, pam-config, pam-modules, pam_ldap, perl-Authen-SASL, Perl-BerkeleyDB, perl-OpenCA-CRL, OpenCA-REQ, perl-OpenCA-X509, perl-Unicode-String, все perl-Crypt, perl-IO-String, perl-ldap, perl-ldap-ssl, Perl-IO-Socket-SSL, perl-Net_SSLeay, perl-Unicode-Map8, libgcrypt, libxcrypt, libnscd, libacl, libmsrpc, libsmbsharemodes, libmspack, компоненты cyrus-sasl, tls, и по желанию - mc, kdeaddons3-kate, gvim. Дополнительные пакеты из репозитория SUSE: openldap2-back-perl, ldapsmb, samba-doc. Вероятно, этот перечень может быть скорректирован путем проб и ошибок.


Примечание: Учитывая README к пакету smbldap-tools версии 0.9.2, а именно фразу: «In the future, some other function may come (like … compliance to RFC2307...)…» нам предстоит сделать выбор схемы каталога – nis.shema – либо более прогрессивная rfc2703bis.schema, но без использования smbldap-tools. Для простоты был выбран вариант с использованием smbldap-tools.


При установленном samba-doc элементы пакета smbldap-tools находим в папке /usr/share/doc/packages/samba/examples/LDAP/smbldap-tools-0.9.2, вероятно, их можно использовать, но по ряду причин мне показалось целесообразным использовать свежую версию пакета, которую можно найти на http://opensuse.org.


Версии smbldap-tools могут несколько отличаться, в том числе по порядку установки. В варианте 0.9.4-3.2 имеются зависимости - 3 компоненты Perl, это rpm-пакет perl-Jcode-2.06-5.1.noarch.rpm и пакеты в исходных текстах Unicode-Map-0.112.tar.gz и Unicode-MapUTF8-1.11.tar.gz.


RPM-пакет найден поиском в Google, тарболы нашлись с помощью http://search.cpan.org.


Конфигурируем сетевую карту для внутренней зоны, IP-адрес статический. Открываем в брэндмауэре серверы LDAP, samba, dns, а также те порты, что могут быть необходимы в нашей конфигурации. Настроим сервер DNS.


Шаг2. Установка smbldap-tools.


Устанавливаем perl-Jcode:


#rpm -Uvh perl-Jcode-2.06-5.1.noarch.rpm


Распаковываем вышеуказанные пакеты Unicode-*.tar.gz в /usr/src/packages/sources, в раздельные каталоги и далее поступаем согласно документу INSTALL, где указано, что сборка и установка заключается в последовательном выполнении четырех команд:


#perl Makefile.PL

#make

#make test ;-соответственно проследим, нет ли ошибок,

#make install


При установке из исходных текстов в базе RPM сведений о пакетах не будет, поэтому при


#rpm -Uvi smbldap-tools-0.9.4-3.2.noarch.rpm


получим ответ:


error: Failed dependencies:

perl(Unicode::Map) is needed by smbldap-tools

perl(Unicode::MapUTF8) is needed by smbldap-tools


Важно убедиться, что RPM не затребовал еще каких-нибудь зависимостей. Если
нет, то повторяем установку с опцией --nodeps:


#rpm -Uvi --nodeps smbldap-tools-0.9.4-3.2.noarch.rpm


Чистим каталог …/sources/… по завершении установки пакетов.


Шаг3. Настройка SSL.


Корректируем /etc/ssl/openssl.conf – сведения о организации – чтобы меньше заполнять впоследствии при формировании подчиненных сертификатов. Правда, при создании корневого сертификата (СА) придется их все же один раз набрать. В YaST «пользователи и безопасность - управление СА» создадим корневой сертификат. Указываем необходимые опции - страну, город, срок действия сертификата. В том числе нужно определить общее имя (common name) как имя машины, на которой и в дальнейшем будет запускаться Центр сертификации. В закладке «дополнительные параметры – Key Usage» отметим опцию «digital Signature»:




Готовим сертификат для сети учебного учреждения


Указываем пароль, и отрабатываем «далее» - до закрытия вкладки. Корневой сертификат будет сформирован. При повторном открытии того же инструмента требуется выделить CA в дереве CA tree, и нажать клавишу «Enter CA», после чего будет предложено набрать пароль корневого сертификата. В открывшейся форме, перейдя во вкладку «Сертификаты» формируем сертификат для компьютера, на котором развернем PDC («добавить – добавить сертификат сервера»). Общее имя сертификата должно соответствовать полному имени сервера, переименовывать потом машину – обладатель сертификата будет нежелательно. Сертификат сохраняем в файл, выбрав клавишу «Экспорт» например, /root/docs/security/asles.p12, причем в формате «как PKCS12 и включая СА цепочку» (и закрыт паролем). На будущем PDC используя вкладку YaST «пользователи и безопасность - общий сертификат сервера» импортируем asles.p12 из файла.


Примечания:



  1. Те же результаты могут быть достигнуты средствами командной строки.

  2. Возможности получения CA, подписанного авторитетным центром сертификации рассмотрены в работе Ивана Максимова [8].


Шаг4 . Запуск LDAP.


Открываем вкладку YaST «сетевые службы - сервер LDAP - настройка - общие настройки - файлы схем». Установим опцию автозапуска сервера при загрузке. Добавляем или проверяем наличие схем - core.schema, cosine.schema, nis.schema, inetorgperson.schema, misc.schema, samba3.schema, yast.schema, ppolicy.schema. Последняя – только по причине того, что она есть в данном дистрибутиве, - отчего бы не использовать.


Перейдем на вкладку «базы данных - добавить базу данных», создаем базу, dn базы, например, dc=bgiki,dc=edu, dc=ru, далее dn корневого объекта - dn=Administrator,dc=bgiki,dc=edu,dc=ru, строкой ниже задаем ему пароль. Выбрав клавишу «Принять» сохраним созданную корневую конфигурацию LDAP. Снова включаем YaST «сетевые службы- сервер LDAP - конфигурирование – общие настройки - TLS настройки - TLS Активация» - выбираем «Да» в ее настройках. Для TLS-шифрования нужен ключ и сертификат к нему, поэтому выбираем в той же вкладке опцию «Выбрать сертификат» - настраиваем на использование общего сертификата сервера. YaST сформирует эти файлы и поместит их:



  • корневой сертификат: /etc/ssl/certs/YaST-CA.pem

  • сертификат сервера LDAP: /etc/ssl/servercerts/servercert.pem

  • ключ сервера LDAP: /etc/ssl/servercerts/serverkey.pem


Запустим демон LDAP:


#rcldap start


и по выводу сообщения «done» убедимся, что он запущен.


Открываем вкладкуYaST «сетевые службы - клиент LDAP» и устанавливаем подключение к нашему серверу:




Настройка клиента LDAP в графической форме


В закладке «дополнительная настройка - настройки администратора» впишем (или проверим наличие) DN администратора LDAP. В этой же закладке указываем опцию «Создать конфигурационные объекты по умолчанию», в результате будет создан контейнер LDAP «ou=ldapconfig,dc=…». В закладке «настройки клиента» проверим контекст именования:



  • отражение пользователя(user map) ou=people,…

  • отражение пароля (password map) ou=people,…

  • отражение группы (group map) ou=group,…


Клавишей «принять» сохраняем конфигурацию клиента. При открытии инструмента «сервер LDAP» настраиваем политику паролей (добавить политику – место хранения – в контейнере ou=ldapconfig…) и определяем срок действия пароля в днях, таймаут блокировки при заданном количестве ошибок набора пароля и другие. Скажу сразу, что объект политики в каталоге не виден, но соответствующая строка в slapd.conf появится.


Открываем вкладкуYaST «сетевые серверы - Обозреватель LDAP», проверяем открытие каталога.


Создаем файл /etc/ldap.secret, и вносим в него пароль корневой учетной записи базы cn=Administrator,dc=bgiki,dc=edu,dc=ru:


#echo "пароль" > /etc/ldap.secret


Тестируем созданное:


#rcldap restart ;-перезапуск ldap

#ps aux | grep slapd ;-вернет сведения о запущенном демоне

#netstat -nap | grep slapd ;-вернет информацию о готовности к соединению демона slapd, нас интересует факт открытия tcp-порта 389 из источников 0.0.0.0 и 127.0.0.1 с докладом «LISTEN».


Наличие графических инструментов не отменяет необходимости чтения системных руководств, например:


#man slapd.conf


Вышеуказанные конфигурации текстуально отображены в скриптах /etc/openldap/slapd.conf – сервера LDAP и /etc/ldap.conf – клиента LDAP. Приведем наиболее существенные строки из их содержания.


slapd.conf:


pidfile /var/run/slapd/slapd.pid

argsfile /var/run/slapd/slapd.args

# ссылка на динамические модули:

modulepath /usr/lib/openldap/modules

#Начальные настройки доступа к каталогу

access to attrs=SambaLMPassword,SambaNTPassword

by dn="cn=Administrator,dc=bgiki,dc=edu,dc=ru" write

#; by dn="cn=root,ou=People,dc=bgiki,dc=edu,dc=ru" write

#; by dn="cn=proxyuser,ou=People,dc=bgiki,dc=edu,dc=ru" read

by * none

## Yast2 samba hack ACL done

access to dn.base=""

by * read



access to dn.base="cn=Subschema"

by * read



access to attrs=userPassword,userPKCS12

by self write

by * auth



access to attrs=shadowLastChange

by self write

by * read



access to *

by * read

###########################################################

# BDB database definitions – определения базы данных

###########################################################

loglevel 0 #может быть до 10, если нужно

TLSCipherSuite :SSLv3

#переименовал YaST-CA.pem, это необязательное действие

TLSCACertificateFile /etc/ssl/certs/CA.pem

TLSCertificateFile /etc/ssl/servercerts/servercert.pem

TLSCertificateKeyFile /etc/ssl/servercerts/serverkey.pem

database bdb

suffix "dc=bgiki,dc=edu,dc=ru"

rootdn "cn=Administrator,dc=bgiki,dc=edu,dc=ru"

#;rootdn "cn=root,ou=People,dc=bgiki,dc=edu,dc=ru"

rootpw "{ssha}хеш сгенерируется автоматически при настройке сервера"

directory /var/lib/ldap/

checkpoint 1024 5

cachesize 10000

#параметры поиска объектов в какталоге

index objectClass,uidNumber,gidNumber eq

index member,mail eq,pres

index cn,displayname,uid,sn,givenname sub,eq,pres

index sambaSID eq

index sambaPrimaryGroupSID eq

index sambaDomainName eq

#

overlay ppolicy

ppolicy_default "cn=Default Policy,ou=ldapconfig,dc=bgiki,dc=edu,dc=ru"



ldap.conf:

#URL хоста,-не IP-адрес, потому что работает с сертификатом

host asles.bgiki.local

base dc=bgiki,dc=edu,dc=ru

uri ldap://127.0.0.1/

#uri ldaps://127.0.0.1/ #сможем включить позднее

#uri ldapi://%2fvar%2frun%2fldapi_sock/

ldap_version 3

#;binddn cn=proxyuser,ou=People,dc=bgiki,dc=edu,dc=ru

#;bindpw пароль проксиюзера открытым текстом наберем позднее



# Password is stored in /etc/ldap.secret

rootbinddn cn=Administrator,dc=bgiki,dc=edu,dc=ru

#;rootbinddn cn=root,ou=People,dc=bgiki,dc=edu,dc=ru

port 389

#без этих таймлимитов возникают ошибки nss_ldap, с ними тоже, но реже

timelimit 30

bind_timelimit 30



# Reconnect policy и прочие policy,

bind_policy soft

nss_connect_policy persist

idle_timelimit 3600

nss_paged_results yes

pagesize 1000



# Filter to AND with uid=%s

pam_filter objectclass=account

pam_login_attribute uid



# диапазон разрешенных UID

pam_min_uid 1000

pam_max_uid 60000



pam_password exop



nss_initgroups_ignoreusers root,ldap



# Enable support for RFC2307bis (distinguished . . .

#nss_schema rfc2307bis – и все же когда-нибудь мы это включим...



# NDS mappings

nss_map_attribute uniqueMember member



# OpenLDAP SSL mechanism – пока это главное

ssl start_tls

pam_filter objectclass=posixAccount

#следующие три строки сгенерируются при соответствующей настройке

#клиента LDAP, а в конечном варианте ?one ограничивает глубину запроса:

nss_base_passwd ou=People,dc=bgiki,dc=edu,dc=ru?one

nss_base_shadow ou=People,dc=bgiki,dc=edu,dc=ru?one

nss_base_group ou=Group,dc=bgiki,dc=edu,dc=ru?one

#позволяет работать с самоподписанным сертификатом:

tls_checkpeer no

#ssl on

# OpenLDAP SSL options

# Пока нас устраивает только start_tls, SSL в чистом виде не включаем,

# следовательно ниже закомментировано

#tls_checkpeer yes

# CA certificates for server certificate verification

# At least one of these are required if tls_checkpeer is "yes"

#tls_cacertfile /etc/ssl/CA.pem

#tls_cacertdir /etc/ssl/certs



# Seed the PRNG if /dev/urandom is not provided

#tls_randfile /var/run/egd-pool



# Client certificate and key. Пока задействуем уже созданную

# ключевую пару, скопировав ее в папку /etc/ssl/ldap/:

tls_cert /etc/ssl/ldap/servercert.pem

tls_key /etc/ssl/ldap/serverkey.pem


Конфигурационный файл, где указан порядок поиска учетных записей - nsswitch.conf:


passwd: compat #в соответствии с определением passwd_compat

shadow: files #теневые пароли – см. [4]

group: files ldap

hosts: files mdns4_minimal [NOTFOUND=return] dns

networks: files dns

services: files ldap

protocols: files

rpc: files

ethers: files

netmasks: files

netgroup: files ldap

publickey: files

bootparams: files

automount: files nis

aliases: files ldap

passwd_compat: ldap


Шаг5. Запуск Samba - сервера.


Открываем вкладку YaST «сетевые службы - сервер Samba», во вкладке «загрузка» установим опцию автозапуска сервера, во вкладке «общие ресурсы» проверим наличие netlogon, во вкладке «идентификация» установим имя домена и роль контроллера – PDC. Там же перейдем в «дополнительные настройки-способ идентификации пользователя» и выставим параметр LDAP и значение – ldap://127.0.0.1. Настройки сохранятся при закрытии инструмента, при этом будет предложено набрать пароль администратора samba-сервера.


После завершения работы в графической утилите используем текстовый редактор для правки секции глобальных настроек файла smb.conf:


[global]

workgroup = BGIKI

server string = BGIKI_PDC

map to guest = Bad User

security = user

domain logons = Yes

domain master = Yes

logon path = ""

logon home = ""

os level = 255

preferred master = Yes

# пока разрешаем заходить только из нашей сетки

hosts allow = 10.31.99. 127.0.0.

# так как нет другого wins, включим свой:

wins support = yes

log level = 1

log file = /var/log/samba/log.%m

max log size = 100000

socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192



# опции для LDAP

passdb backend = ldapsam:ldap://127.0.0.1/

ldap admin dn = cn=Administrator,dc=bgiki,dc=edu,dc=ru

#;ldap admin dn = cn=root,ou=People,dc=bgiki,dc=edu,dc=ru

ldap suffix = dc=bgiki,dc=edu,dc=ru

ldap group suffix = ou=Group

ldap idmap suffix = ou=Idmap

ldap machine suffix = ou=Computers

ldap user suffix = ou=People

ldap passwd sync = Yes

ldap ssl = Start_tls

ldap timeout = 15

ldap delete dn = No

#manage users from Win tools

add machine script = /usr/sbin/smbldap-useradd -a -w "%u"

add user script = /usr/sbin/smbldap-useradd -a -m "%u"

delete user script = /usr/sbin/smbldap-userdel "%u"

add group script = /usr/sbin/smbldap-groupadd -p "%g"

delete group script = /usr/sbin/smbldap-groupdel "%g"

add user to group script = /usr/sbin/smbldap-groupmod -m "%u" "%g"

delete user from group script = /usr/sbin/smbldap-groupmod -x "%u" "%g"

set primary group script = /usr/sbin/smbldap-usermod -g '%g' '%u'


Добавим пароль корневой записи администратора ldap в samba:


#smbpasswd -wЕгоПароль


Проверяем конфигурационный файл smb.conf с помощью команды testparm и
перезапустим демон:


#rcsmb restart


проверим, какие порты прослушивает smbd:


#netstat -nap | grep smbd


проверим доступность ресурсов samba:


#smbclient -L localhost –U administrator


вернет информацию о доступных ресурсах samba (если ошибка – ставим log level
= 2 и читаем сообщения из /var/logs/).


Шаг 6. Подготовка конфигурационных файлов smbldap-tools.


Сертификаты, сформированные для LDAP-TLS временно используем и для
smbldap-tools. Для этого из папки /etc/ssl/servercerts файлы servercert.pem и
serverkey.pem копируем в /etc/smbldap-tools. Попытки использовать указанные
server*.pem из общего каталога совместно smbldap-tools и slapd к успеху не
привели, поэтому и используются те же сертификаты, но для smbldap-tools они
будут использоваться из отдельного каталога.


Получим SID домена:


#net getlocalsid – вернет SID домена


Используем файл configure.pl. Для этого его из /usr/share/doc/packages/smbldap-tools
копируем в /usr/sbin - и запускаем. На консоль будут выводиться вопросы и в
большинстве пунктов значение параметра по умолчанию - если мы согласны с этим
значением, то просто нажимаем "Enter". В результате сформируются
конфигурационные файлы в каталоге /etc/smbldap-tools. Проверяем текст
smbldap.conf и smbldap_bind.conf, при этом:



  • SID домена должен соответствовать выводу команды net getlocalsid

  • Slave и Master LDAP server - это один и тот же наш сервер, его IP- адрес
    127.0.0.1


ldapTLS="1" -потому что мы TLS уже включили,

cafile="/etc/ssl/certs/CA.pem",

clientcert="/etc/smbldap-tools/servercert.pem"

clientkey="/etc/smbldap-tools/serverkey.pem"

suffix="dc=bgiki,dc=edu,dc=ru"

#dn, где мы собираемся учитывать компьютеры, группы, пользователей:

usersdn="ou=People,${suffix}"

computersdn="ou=Computers,${suffix}"

groupsdn="ou=Group,${suffix}"

idmapdn="ou=Idmap,${suffix}",

#Размещение счетчика UID/GID:

sambaUnixIdPooldn="sambaDomainName=BGIKI,${suffix}"

# Алгоритм шифрования:

hash_encrypt="SSHA"

#Опция, повышающая криптостойкость хеша – в просторечии «соль»

crypt_salt_format="%s"



#Настройки шаблонов – например, простейшие:

userSmbHome="".""

userProfile="".""

userHomeDrive="''"

userScript=""


И последнее – в файле smbldap-bind.conf будет текущий пароль администратора каталога для ведомого и ведущего сервера, и так как у нас это один и тот же сервер – то и повторится он дважды, в формате plain-text.


Теперь используя YaST нужно создать Posix-группы для домена, с корректировкой GID - ntadmins gid=512, mashines gid=515, ntguests gid=514, ntusers gid=513.


Примечание: posix-группы «nt*» и «mashines» будут «привязываться» (mapping) к созданным в каталоге LDAP объектам домена. Известно, что у Windows – группы имеется SID (идентификатор Microsoft), этот SID в целях эмуляции контроллера Windows “привязывается” к posix-группе командой net groupmap add. При определении gid posix-группам со значением по умолчанию у меня как раз и не получалось исполнить этот mapping – пока не вписал posix gid равным последним трем цифрам windows- классификатора, как и указано выше, в результате привязка упростилась.


Шаг7. Заполнение каталога openldap.


Выполняем команду из комплекта smbldap-tools:


#smbldap-populate


Далее увидим список созданных объектов, в завершение утилита предложит сформировать пароль нового администратора домена (его dn: cn=root,ou=People.. и т.д.).


Примечание: Если что-либо не выходит, чаще всего ошибка заключается в настройках TLS.


Проверив привязку групп, убедимся, что mapping получился автоматически:


#net groupmap list

Domain Admins (S-1-5-21-. . .111-512) -> ntadmins


и т.д.


Даём группе Domain Admins необходимые права:


#net rpc rights grant

"Domain Admins"

SeMachineAccountPrivilege

SeTakeOwnershipPrivilege

SeBackupPrivilege

SeRestorePrivilege

SeRemoteShutdownPrivilege

SePrintOperatorPrivilege

SeAddUsersPrivilege

SeDiskOperatorPrivilege -Uroot


Используя YaST, создаем posix-пользователя с именем - для примера - adminchik, проверяем, что ему присвоен uidNumber 1000 , включаем его в posix-группу ntadmins и в командной строке создаем для него учетную запись samba:


#smbldap-useradd -m "adminchik"


С этой учетной записью сможем выполнять административный вход на клиентские машины. Cоздадим posix – запись контроллера домена, имя заканчивается знаком $.


#adduser -n -g machines -d /dev/null -s /bin/false asles$


Добавим контроллер в домен:


#net join


запросит пароль администратора.


Производим конфигурирование модулей pam последовательно двумя вызовами команды pam-config:


#pam-config -a --unix2

#pam-config -a --ldap


после чего утилитой YaST "система - управление службами" включим amsmbd.
Перезапустим ldap и smbd, проверим:


#getent passwd


вернет список пользователей.


Сформируем хеш для пользователя proxyuser:


# slappasswd -v -s ParolProxyUzera -h {SSHA} –c %s


используем его для параметра userPassword при создании файла proxy.ldif, вот его текст:


dn: cn=proxyuser,ou=people,dc=bgiki,dc=edu,dc=ru

cn: proxyuser

sn: proxyuser

objectclass: top

objectclass: person

userPassword: {SSHA}U0k4II20PybууUwAlDxRееhGW4diAI5+


Модифицируем каталог:


#ldapmodify -a –v -f proxy.ldif -D "cn=administrator,dc=bgiki,dc=edu,dc=ru"
-x –W


В соответствующей ветке каталога появится запись, с помощью которой схема авторизации будет читать пароли. У нас появится возможность не указывать пароль администратора каталога простым текстом в файле ldap.secret при повседневной работе сервера. К сожалению, эта уязвимость еще остается в smbldap_bind.conf.


Произведем смену администратора LDAP в конфигурации, для этого:


а) Используя YaST «сетевые службы - сервер LDAP - настройка – база данных –…», изменим dn администратора на имя cn=root,ou=People…и введем новый пароль.


б) Правим файл slapd.conf, текстовым редактором в подразделе # Yast2 samba hack ACL — изменим на dn нового администратора, и добавим права proxyuser:


access to attrs=SambaLMPassword,SambaNTPassword

by dn="cn=root,ou=people,dc=bgiki,dc=ru" write

by dn="cn=proxyuser,ou=people,dc=bgiki,dc=ru" read

by * none


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


в) Правим файл ldap.conf:



  • изменим запись rootbinddn

  • раскомментируем строку binddn, где указан proxyuser, не забываем указать
    его пароль строкой ниже.


г) Правим файл smb.conf, где изменим значение ldap admin dn.


Бюджет нового администратора нужно учесть в базе учетных записей samba:


#smbpasswd –wЕго_Пароль


после чего перезапустим smbd и slapd.


д) Правим файл smbldap_bind.conf путем редактирования dn администратора и его пароля.


Создадим posix- учетную запись клиентского компьютера, подключаем его в домен – если операционная система Windows, то так же, как в домене Microsoft, с учетной записью «root». И для компьютеров и для пользователей требуется создавать posix-учетные записи, после чего можно заполнять данные в samba. С клиентской машины посредством утилиты Usrmgr.exe производства Microsoft (из дистрибутива NT4.0 –сервера – на сайте производителя тоже есть) администрируем учетные записи samba.


Создадим группу для последующего допуска к некоторому ограниченному ресурсу. Для этого сначала создадим posix-группу:


#groupadd konsplususers


Или выполним ту же процедуру инструментом YaST.


Создадим группу в samba:


#smbldap-groupadd -p konsplususers


используя YaST убедимся, что gid в перечне ldap и posix совпадают, если нужно, поправим.


Другой способ – создадим группу в каталоге ldap, запросит пароль администратора


#net rpc group add konsplususers

Password:


и свяжем ее с заранее созданной posix-группой


#net groupmap add rid=1003 ntgroup="konsplususers" unixgroup=konsplususers

Unix group konsplususers already mapped

to SID S-1-5-21-147838798-37688190-2313965735-1097


Добавим posix-пользователя в созданную posix-группу, создадим его бюджет в сервере samba, и уже в файл-сервере он получит права на предоставленный группе ресурс – чего и добивались.


Если это получилось, значит, еще один боец IT-фронта готов к выходу из под пресса монополистов проприетарного ПО.


Теперь самым насущным делом становится укрепление защищенности сервера, резервное копирование, развертывание на POSIX-платформе файл-сервера и почтового сервера, конечная цель - система управления учреждением на базе Open Source.


Литература:


1. Григорьев Михаил Настраиваем OpenLDAP сервер и клиент с поддержкой SSL.

Date: Tue, 19 Apr 2005

http://www.unixdoc.ru/print.php?print_id=123


2. Vsevolod Stakhov <cebka[at]jet[dot]msk[dot]su>

Настройка OpenLDAP и его взаимодействиия с сетевыми сервисами. Date: Mon, 5 Dec
2005 Оригинал:
http://cebka.pp.ru/my/openldap.txt
. Статья впервые опубликована в журнале "Системный Администратор".


3. From: CoderInside <coder@linuxportal.vrn.ru.>Date: Mon, 24 Apr 2007
Subject: SAMBA PDC - установка, настройка, управление (Slackware) Оригинал: Воронежский Linux портал.


4. Алексей Барабанов <alekseybb at mail dot ru>. Размещение пользовательских бюджетов в LDAP. Москва, октябрь-декабрь 2006.


5. Настройка OpenLDAP и его клиентов.

http://www.freesource.info/wiki/ALTLinux/Dokumentacija/OpenLDAP


6. Настройка Samba 3 (PDC) с пользователями в LDAP каталоге.

From: Crux Date: Mon, 20 Sep 2004 Оригинал:

http://www.unix.nordcomp.ru/articles.html?page=2&id=17


7. OpenLDAP и TLS/SSL,

http://www.freesource.info/wiki/ALTLinux/Dokumentacija/OpenLDAP/TLS


8. Иван Максимов. Организуем сетевой календарь в корпоративной среде. Журнал "Системный Администратор" №2- 2008 год.


Читать дальше.

суббота, 7 июня 2008 г.

Акция "Эксклюзивные RSS-иконки для всех и каждого!"

Эксклюзивные RSS-иконки!

Наткнулся тут в сети на очень любопытную акцию: дизайнер Миша 'Designfreak' Квакин сделает эксклюзивную иконку для RSS-ленты совершенно бесплатно.

Подробности под катом.


Для этого всего лишь надо:
1) Отписать о желании получить иконку у него в комментах
2) Разместить ссылку на его статью у себя в блоге или на сайте.

Для перехода на его пост, посвященный этой акции, кликните на заголовок моей статьи или сюда.

Вот еще пара картинок:
Эксклюзивные RSS-иконки!
Эксклюзивные RSS-иконки!
Все права на изображения, естественно, принадлежат автору.


Читать дальше.

четверг, 5 июня 2008 г.

Доля Линукс на европейских десктопах достигла 1%!

В исследовании, регулярно проводимом компанией xitimonitor, учитывающей посещаемость 170 тысяч веб-сайтов (по-видимому, западноевропейских), доля Linux составила в среднем 1% за февраль-апрель 2008 (год назад было около 0.75%).

В то же время, согласно другим источникам, доля Linux ниже в России (0.6%) и в США (0.7%); w3counter.com показывает для Linux 2%.

Европа: http://www.xitimonitor.com/en-us/inte...
Европа год назад: http://www.xitimonitor.com/en-us/inte...
Россия: http://gs.spylog.ru/r/?reportId=13&am...
в основном США: http://marketshare.hitslink.com/repor...
http://www.w3counter.com/globalstats.php


Доля Mac - 7.8% ~США, 4% Европа, 0.86% Россия.
Доля BSD (десктоп) - 0.00% ~США, 0.01% Европа, 0.02% Россия.

За последний год доля Windows снизилась на 1.1% (Европа) и на 1.8% (~США).

Автор новости: Linux.org.ru

Читать дальше.