воскресенье, 28 ноября 2010 г.

Зоны Solaris III: Устройства и безопасность

Зоны Solaris имеют ряд ограничений, как связанных с реализацией, так и с безопасностью.

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

Кроме того, вы не можете управлять физическими устройствами внутри зоны, так же, как и использовать службу volfs (VOLD), сервис которой в неглобальных зонах отключен по умолчанию. Иначе говоря, в неглобальной зоне вы не можете монтировать или размонтировать съемные устройства, подключенные к серверу.

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

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

Отдельно хочу подчеркнуть особенности использования IPFilter. Сервис IPF внутри неглобальных зон существует, однако запустить его нельзя, вне зависимости от наличия или отсутствия конфигурационного файла. Сервис переходит в состояние maintenance сразу после старта. Недостаточно прав.

Дело вот в чем. IPF в Солярис выполняется как модуль режима ядра. И, помимо доступа к логическиму устройству /dev/ip необходима еще целая серия прав на связанные ресурсы ядра глобальной зоны, чего в неглобальной зоне нет и быть не может.

Соответственно, IPFilter в неглобальной зоне использовать не получится, необходимо конфигурировать его в глобальной зоне и открывать порты для доступа в неглобальную зону.

Строго говоря, это хорошо и правильно. Администратор глобальной зоны обеспечивает покровительство и защиту файрволом неглобальных зон. :)

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

Что касается файловых прав, то, как было показано в предыдущей статье, зоны по определению имеют доступ к системным файлам и компонентам read only, что снижает возможность по установке руткитов до некоторого минимума (во всяком случае, если говорить о подмене системных бинарников). Так что, в случае компрометации неглобальной зоны, доступ к ней можно немедленно прекратить (либо заблокировав доступ при помощи IPF или просто выполнив немедленную остановку неглобальной зоны командой zoneadm halt) и разбираться с остановленной зоной вручную через файловый доступ к датасету.

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

среда, 24 ноября 2010 г.

Зоны Solaris II: Sparse root VS whole root

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

Поэтому постараюсь объяснить на пальцах принципиальную разницу между sparse root и whole root моделями зон.

1. Sparse root - режим установки native-зон по умолчанию. Иначе говоря, если не сказано обратное, зоны Solaris устанавливаются именно в этом режиме. При этом копируется минимальное количество файлов, необходимых для запуска, большинство необходимых системных директорий монтируется через lofs в режиме read only. Директорий с возможностью записи в этом случае минимальное количество - обычно это /export, /tmp, /var, /etc. Ни в одну из системных директорий записывать нельзя - /lib, /usr, /platform итп. Что означает, например, что вы не можете в установленной неглобальной зоне создавать собственные SMF-сервисы без необходимости помещения в /lib/svc/method глобальной зоны управляющего скрипта. Однако вы можете запускать в установленной неглобальной зоне сервисы посредством старого механизма rcX.d, так как директория /etc в зоне собственная, что позволяет вам создавать в /etc/init.d скрипты и линки в директориях rcX.d. Это не слишком удобно, если нет доступа в глобальную зону, однако такова цена реализации данной модели.

Данный режим установки обладает двумя важными особенностями:

- Установленная неглобальная зона занимает минимум пространства на диске - 300-350 Мб, в зависимости от состава установленных в глобальной зоне пакетов.

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

2. Whole root - режим установки, при котором в зону копируется почти весь operating environment родительской системы. В этом случае /lib полностью копируется в неглобальную зону, независим от глобальной и в нее можно писать. Что означает, что в подобной конфигурации вы можете создавать SMF-сервисы в неглобальной зоне. Что касается /usr, то ситуация в этом случае несколько иная. Все, что создается в /usr неглобальной зоны, копируется в глобальную, однако при удалении созданных файлов из глобальной зоны, они остаются в /usr неглобальной зоны. Это поведение очень легко проверяется, именно так все и происходит. Кроме того, в таком режиме установки не происходит разделения исполняемого кода и библиотек, что увеличивает потребность в оперативной памяти глобальной зоны и несколько снижает быстродействие неглобальных зон.

Основное отличие whole root от sparse root в том, что установленная зона имеет гораздо больший размер (почти на порядок) - 3-6 Гб (в зависимости от установленных пакетов).

вторник, 23 ноября 2010 г.

Зоны Solaris I: Установка

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

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

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

Установка зон очень сильно завязана на файл /var/sadm/install/contents, это всем известно. При повреждениях любого рода данного файла установка зон становится невозможной.

Но тот факт, что она еще и очень сильно завязана на директории /var/sadm/pkg/*/save был для меня полной неожиданностью.

Достаточно часто в административной практике с целью экономии пространства  после установки и тестирования патчей директории save просто удаляются. Сюрприз! После их удаления  успешная установка зон также становится невозможной.

Иначе говоря, удаление бэкаутов для патчей нужно выполнять не командой:

# find /var/sadm/pkg -name save -exec rm -Rf {} \;

а командой

# find /var/sadm/pkg -name -name obsolete.Z -o -name undo.Z -exec rm -f {} \;

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

Еще один сюрприз касается создания датасетов файловых систем ZFS в зонах.

В общем-то логично использовать с зонами ZFS.

Однако не все так гладко и, тем более, не все хорошо задокументировано. Некоторые вопросы не документированы в принципе.

Простой эксперимент показывает, что, если формировать zonepath от уровня пула хранения (stprage pool) ZFS, то датасеты зон создаются автоматически в процессе инсталляции зоны. После чего можно на эти датасеты установить квоты, которые будут видны внутри зон как максимальный объем системы хранения:

root @ pegasus /stage # zfs get quota data/zone1
NAME        PROPERTY  VALUE  SOURCE
data/zone1  quota     2G     local
root @ pegasus /stage # zlogin -C zone1
[Connected to zone 'zone1' console]

# df -h
Filesystem             size   used  avail capacity  Mounted on
/                      2.0G   313M   1.7G    16%    /
/data/stage            8.7G    61K   8.7G     1%    /data/stage
/dev                   2.0G   313M   1.7G    16%    /dev
/lib                    13G   3.6G   9.0G    29%    /lib
/opt                    13G   3.6G   9.0G    29%    /opt
/platform               13G   3.6G   9.0G    29%    /platform
/sbin                   13G   3.6G   9.0G    29%    /sbin
/usr                    13G   3.6G   9.0G    29%    /usr
proc                     0K     0K     0K     0%    /proc
ctfs                     0K     0K     0K     0%    /system/contract
mnttab                   0K     0K     0K     0%    /etc/mnttab
objfs                    0K     0K     0K     0%    /system/object
swap                   1.9G   244K   1.9G     1%    /etc/svc/volatile
/usr/lib/libc/libc_hwcap1.so.1
                        13G   3.6G   9.0G    29%    /lib/libc.so.1
fd                       0K     0K     0K     0%    /dev/fd
swap                   1.9G     0K   1.9G     0%    /tmp
swap                   1.9G    12K   1.9G     1%    /var/run


Вот здесь подстерегает сюрприз номер два.

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

Сказать, что это неудобно - не то слово.

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

PS. Мне не нравится подход оставлять значения параметров хранения ZFS по умолчанию. В большинстве случаев recordsize по умолчанию слишком велико, если только мы не строим хранилище под огромные объемы и для хранения действительно больших файлов.  Соответственно, под зоны действительно лучше выделить отдельный пул хранения и определить на нем необходимые значения параметров хранения, которые будут наследоваться зонами.

понедельник, 22 ноября 2010 г.

CRON в Solaris

Вы-таки будете смеяться, но демон cron в Solaris устроен несколько не так, как он устроен в подавляющем большинстве UNIX-like систем. 

Прикол в следующем. Если вам нужно указать интервальное выполнение задания с периодичностью, скажем, 5 минут, то написать:

*/5 * * * * ваше_задание.sh


или

5 * * * * ваше_задание.sh

нифига недостаточно. В первом случае задание просто игнорируется, а во втором случае оно будет срабатывать в каждые 5 минут начала каждого часа. Опаньки.

Чтобы указать периодичность выполнения в 5 минут нужно прямо перечислить:

0,5,10,15,20,25,30,35,40,45,50,55 * * * * /usr/local/bin/script.sh

Только в этом случае скрипт будет выполняться каждые 5 минут, что нетрудно проверить через /var/cron/log:

CMD: /usr/local/bin/script.sh
root 2827 c Sun Nov 21 05:30:00 2010
root 2826 c Sun Nov 21 05:30:01 2010
root 2827 c Sun Nov 21 05:30:01 2010
CMD: /usr/local/bin/script.sh
root 2879 c Sun Nov 21 05:35:00 2010
root 2879 c Sun Nov 21 05:35:01 2010
CMD: /usr/local/bin/script.sh
root 2930 c Sun Nov 21 05:40:00 2010
root 2930 c Sun Nov 21 05:40:01 2010
CMD: /usr/local/bin/script.sh
root 2982 c Sun Nov 21 05:45:00 2010
root 2982 c Sun Nov 21 05:45:01 2010
CMD: /usr/local/bin/script.sh
root 3033 c Sun Nov 21 05:50:00 2010
root 3033 c Sun Nov 21 05:50:01 2010
CMD: /usr/local/bin/script.sh
root 3084 c Sun Nov 21 05:55:00 2010
root 3084 c Sun Nov 21 05:55:01 2010
CMD: /usr/local/bin/script.sh
root 3136 c Sun Nov 21 06:00:00 2010
root 3136 c Sun Nov 21 06:00:00 2010
CMD: /usr/local/bin/script.sh
root 4669 c Sun Nov 21 06:05:00 2010
root 4669 c Sun Nov 21 06:05:01 2010
CMD: /usr/local/bin/script.sh
root 4991 c Sun Nov 21 06:10:00 2010
root 4991 c Sun Nov 21 06:10:01 2010
CMD: /usr/local/bin/script.sh
root 5100 c Sun Nov 21 06:15:00 2010
root 5100 c Sun Nov 21 06:15:01 2010
CMD: /usr/local/bin/script.sh
root 5217 c Sun Nov 21 06:20:00 2010
root 5217 c Sun Nov 21 06:20:01 2010
CMD: /usr/local/bin/script.sh
root 5300 c Sun Nov 21 06:25:00 2010
root 5300 c Sun Nov 21 06:25:01 2010 



Вот такая забавная особенность.


Да, забыл написать версию Solaris:


root @ blade / # uname -a
SunOS blade 5.10 Generic_144488-03 sun4u sparc SUNW,Sun-Blade-100

среда, 17 ноября 2010 г.

Легко ли написать операционную систему?

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

Давайте попробуем расставить точки над Ё. Не претендуя на историческую точность, попробуем рассмотреть аспекты подобных поползновений.

Существует три возможности написать собственную операционную систему.

Первая - самая трудоемкая. Сколотить команду выдающихся системных программистов во главе толкового тим-лидера, дать им миллиард долларов и подождать 3-5 лет до готовности версии альфа. Хороший и правильный подход, большинство ключевых операционных (не мониторных!) систем были созданы именно таким путем.

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

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

Потугам третьего способа буквально несть числа. Помимо трехсот с лишним линуксов с блэкджеком и шлюхами, что ни день появляются полупроприетарные и проприетарные дистрибутивы и дистрибутивчики различного назначения и названия. С гордыми именами. Один Андроид чего стоит. 

Помимо того, каждый анонимус, едва научившись писать на Си Hello, world! кидается ваять свой собственный дистрибутив. Зачем - нормальному человеку не понять никогда.

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

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

В общем-то, ежу ясно, что для написания действительно оригинальной и полной ОС нужны огромные усилия, идеи и ресурсы. В том числе человеческие.

Просто смеха для - не точности ради - давайте взглянем, какие компоненты ОС нужны по минимуму:

1. Ядро. От нескольких миллионов до десятков миллионов строк кода.
2. Драйверы устройств. Для поддержки даже минимального количества оборудования драйверы должны быть написаны или позаимствованы у вендоров в виде блобов. Количество кода исчисляется примерно такими же порядками, что и у ядра.
3. Юзерспейс, или, как часто говорят, мир. В зависимости от того, какого масштаба среду мы представляем конечным пользователям, объем кодирования не лимитируется.

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

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

А как же Линус?

А Линус не писал систему с нуля. Если уж быть совсем точным. Он видел ядро миникс и отталкивался уже от написанного кода. Им самим было написано лишь ядро. Все барахло, которым потом облепили это ядро и гордо обозвали GNU/Linux суть лишь коллекция объедков со стола промышленных UNIX разнородных утилит, функционал которых позаимствован сообществом GNU и воспроизведен в меру своих скромных способностей.Ах да, еще X11 и гуй. Точнее, гуи, количество которых зашкаливает за все разумные пределы.

Ничего подлинно революционного Линукс не содержит физически. Если уж руководствоваться критериями оригинальности.

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

Все без исключения форки BSD - позаимствовали кодовую базу Университета Беркли.
Solaris - построен на кодовой базе AT&T (System V). Справедливости для заметим, что Солярис прошел большой путь и был переписан процентов на сто. Практически, сейчас это самостоятельная ОС.
HP/UX - построен на кодовой базе AT&T.
IRIX - кодовая база AT&T. Благополучно померла в пользу RHEL.
AIX - построен на кодовой базе AT&T System V.
Windows (NT) - частично оригинальная разработка от создателей VMS. Что и позволило ей стать настоящим хитом на фоне тогдашнего десктопного бардака.

Следует заметить, что самых последовательных, логичных, непротиворечивых и внятных результатов достигают те команды (даже пользующиеся не собственной кодовой базой), которые имеют авторитарное управление, в стиле Тео де Раадта. Это, кстати говоря, является причиной, по которой OpenBSD имеет архитектурную стройность, целостность и завершенность, в противовес FreeBSD, которая монструозно разрастается, постепенно воспроизводя путь Линукс (про сообщество Линукс лучше не говорить ничего, потому что ежу ясно - не самому сообществу - что сто миллионов обезъян "Сон в летнюю ночь" не напишут ни случайно, ни целенаправленно. Лучший способ угробить неплохую, в общем-то, операционку - отдать ее полные исходники в лапы сообщества. По моему скромному ИМХО. После чего будет наклепано несколько сотен версий и версиек, отличающиеся иногда только логотипом - например, пингвином в бронежилете. Как говаривал еще В.И. Ленин, "Лучше меньше да лучше". Потому что лично мне культ компьютинга глубоко чужд. Я хочу выбрать одну ОС и пользоваться ей очень долго. Установки и перустановки ОС с целью занять себя - да и с любой другой целью - не являются моим национальным видом спорта).

Возвращаясь к нашему первоначальному тезису.

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

Даже обладая ресурсами государства, на такой подвиг мало кто практически никто способен. Это ж надо мгновенно результат дать, а то откаты и попилы должны быть оправданы - и шустро. Ждать три-четыре года (даже при условии, что команда с нужной квалификацией и имеется - что, как показывает практика, бывает далеко не в каждом государстве и даже не каждое десятилетие, а еще ведь средства нужны!) - да вы сбрендили! Давайте-ка возьмем Линукс - благо, исходники у нас легко доступны - да и наваяем МарсОС скоренько! Дешево, сердито и проблема решена!

Ага, щаз. Нам еще национальных дистров линуксовых до кучи не хватает. Уже есть дистры медицинских работников, на очереди сборки работников образования, ну и далее пошло поехало.

Это называется экстенсивное развитие. Говоря простым языком, развитие в ширину. Линуксы превращаются в несуразную, архитектурно неоднородную коллекцию портов и пакетов, до которой становится далеко всеми оплеванной Windows! "И эти люди запрещают мне ковырять в носу!"

На фоне всего этого циклопического зоопарка, Windows выглядит настоящим ангелочком. С крылышками. По-крайней мере, в нее не вносят "улучшения" все, кому не лень. И слава богу.

Каким чудом сотни дистрибутивов хотя бы частично работают относительно стабильно - мне непонятно.

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

PS. Последней действительно прорывной системой последнего десятилетия, по моему личному мнению, стала Solaris 10. Этому способствовало и частичное (Не полное!) раскрытие кода, и достаточно четкий и жесткий процесс внесения инноваций из опенсурса в основное дерево исходников, и желание ведущих разработчиков действительно внести ряд кардинальных изменений. Все другие системы если и развивались - то никак не революционно. Некоторые так и остались в двадцатом веке.

четверг, 11 ноября 2010 г.

Закат солнца вручную

Ну что ж, последние события в области Sun/Oracle выглядят настолько неприятно, что вызывают здоровое желание сказать, что Оракл просто кинул большинство пользователей Sun. Вопреки своему собственному заявлению о том, что поддержка-де будет, не беспокойтесь, дорогие пользователи, вас не оставят, более того, все будет в шоколаде и все такое:

Oracle is as committed as ever to Linux and other open platforms, and will continue to support and enhance our strong industry partnerships.

Особенно умилила фраза о Linux и other open platforms в свете закрытия OpenSolaris (фактически уже произошедшего), выставления стоимости поддержки MySQL (с учетом порядков цен, стоимость хостинга с использованием MySQL будет астрономической, можете мне поверить). Эй, кто-нибудь в глаза видел полный набор исходников Oracle Enterprise Linux?

Что произошло вместо прекраснодушных обещаний - нам всем уже известно. Новое лицензионное соглашение. Которое, говоря простым языком, явно запрещает использование Солярис свыше 30 дней за некоторыми несущественными исключениями, без заключения контракта. Который, к тому же, предполагает лишь один вид поддержки - Premium Support. Не только для получения рекомендованных патчей и патчей security. Но и firmware (что просто физически не лезет ни в какие ворота - так почти никто из производителей харда не делает, кроме особо жирных, типа IBM) и - внимание, какая прелесть! - драйверов. Причем - что особенно характерно - для систем, которые на гарантии, вы можете (пока еще) получить обновления firmware и драйверы по серийному номеру. Для систем, гарантия на которых закончилась, такой политики нет. 

Фактически это означает, что Оракл кинул владельцев систем выпуска до 2008-2009 года. Все, ребята. "Халява кончилась" (конец цитаты сотрудника Oracle). "Эти клиенты для Оракла не интересны" (конец цитаты его же). 

О пользователях Солярис не на платформе Sun вообще речи нет. Их как бы не существует. Вас нет, коллеги. И пользователей OpenSolaris нет. Вы попали, ребята, и это Большому Ораклу, вообще говоря, до лампочки. Иными словами, вас банально кинули.

Самое забавное, что узнать ДО покупки хотя бы порядки этого самого Premium Support нереально. Дескать, свяжитесь с нами - мы вам насчитаем (сорок да сорок рубль сорок). Попытки узнать у региональных представителей хотя бы порядок стоимости этого самого саппорта на процессор не увенчались успехом. Узнаю, сколько - скажу.

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

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

По моему личному мнению, все это означает только одно. Конец Solaris как ОС общего назначения. Так, подкладка под Oracle. 

Это еще не все. Из Oracle начали уходить ключевые разработчики Solaris. Фактически это может означать то, что Solaris 11 будет совсем не продолжением Solaris 10 - "самой продвинутой ОС на планете" (без всяких преувеличений). А будет индусской редакцией оригинальной кодовой базы. Чем это пахнет, можете сами догадаться. Проприетарным и заточенным под свои приложения UNIX средней паршивости. Подобно AIX, HP/UX и иже с ними. И хорошо еще, если средней.

И вот что - новая лицензионная политика распространяется на два последних релиза Солярис. 10/09 и 9/10. Неслабо, правда? Хотя под брендом Оракла ходит лишь последний.

Средства разработки Sun пока еще доступны свободно, но это, как мне кажется, лишь вопрос времени. Вряд ли такую ценную - можно сказать, ключевую - вещь Оракл обойдет своим монетизирующим вниманием.

Продуктовая линейка серверов Sun была сокращена более, чем вдвое, особенно это касается систем x86 (беру назад свои слова о том, что этому классу систем будет оказано внимание). Это тоже достаточно показательно - "больше не будет систем начального уровня. Аста ла виста, бэйби! Ставьте Солярис на самосбор или на синолоджик - только не забудьте отслюнить премиум саппорт за ось, а не то!". И, похоже, серверов 1RU больше не будет тоже. Во всяком случае, мне не удалось найти ни одного на сайте Oracle. Боюсь, хостинг обломался. Впрочем, при стоимости лицензий порядка 22% от стоимости новой машины только за ОС он обломался в любом случае. "Пусть платит 1,85. Боливару не вынести двоих."

Повторю цитату - "Эти клиенты для Оракла не интересны".

Но и это еще не все. Получив в свое полное распоряжение MySQL, Оракл первым делом установил на поддержку хор-рошую цену. Взгляните.

От 5 до 15 тысяч долларов на сервер от 1 до 4 сокетов. И от 10 до 30 тысяч долларов на сервер свыше 5 сокетов.

Эй, господа вебхостеры, предлагающие стек MySQL+Apache+PHP за смешные деньги! Предлагаем вам заплатить! Платите, а не то! Мы и Гугл-то не постеснялись засудить за использование нашей Java в Andriod

Оставим Гугл в покое. Он, скорей всего,  выкрутится даже не поцарапавшись. Договорятся о взаимном лицензировании, как считает один из обозревателей. А вот куда пойдут наши грошовые хостеры "5000 тенге в год за хостинг корпоративного сайта с MySQL" и пользователи Solaris, кинутые Ораклом - вопрос отдельный.

Я повторяю. Иначе, чем кидаловом, подобные действия назвать нельзя.

Беспрецедентный отказ от собственных публичных заявлений - это, по любым меркам, повод для обращения в суд. От кинутых пользователей в качестве истца. И лицемерная копирастия в отношении кода, который Оракл не написал - но унаследовал от купленной компании. Очень взаимно увязываются и формируют добрый и порядочный образ человекообразной IT-компании-мирового лидера. Которая готова для вас на все - за ваши деньги.

PS. Запасаемся попкорном и ждем крестового похода на хостеров. Ибо MariaSQL еще в сыром состоянии, да и затруднительно в одночасье поменять пользовательскую базу с данными одну на другую. Особенно когда этих баз миллионы.

PPS. Дорогой Оракл! Негарантийные и устаревшие системы можно было бы поддерживать по прежним правилам, не выгоняя неудобных клиентов силовым образом к конкурентам! Это просто в высшей степени непорядочно - заявить одно, а поступать по-другому.  Отговорка "Ничего личного, это просто бизнес" здесь не прокатывает.

PPPS. Как я говорил раньше, периметральные и инфраструктурные машины можно крутить и под BSD. BSD-форки не настолько продвинутые, как Solaris 10, но это не смертельно при существующем раскладе. Всего лишь технологический шаг назад, если не в сторону. При крайней необходимости можно и 10/08 поставить, благо, весь нужный функционал есть уже там. Очень жаль, что Оракл посчитал возможным потерять ОС общего назначения в угоду подкладки под свою БД.

Обновление от 17.11.2010
______________________


Передо мной сейчас лежит письмо за подписью официального лица Oracle, уведомляющее о том, что сервис BigAdmin тоже закрывается и отныне весь контент, относящийся к администрированию Солярис, будет на серверах Oracle в форумах и сэмпл-кодах. Если я правильно понимаю, вся накопленная база знаний и скриптов BigAdmin просто будет выброшена. Что очень хорошо согласуется с вышесказанным. Что ж, господа чайники, теперь индийские специалисты Oracle будут давать вам на форумах "умные советы" в области системного администрирования. Как только что попавшийся мне на глаза совет при неработающем дуалбуте поставить Солярис в виртуальную машину. Ни больше ни меньше.

Кстати, для сведения. Джефф Бонвик тоже покинул Оракл в сентябре. Мне дьявольски интересно, как Оракл намеревается "развивать" систему в отсутствие ключевых разработчиков. Вероятно, по индийской модели. Не иначе.

вторник, 9 ноября 2010 г.

Подземные сети

Чаще всего применение цензуры в Интернет более затратно, чем её преодоление.

Заинтересоваться сабжем, вынесенным в заголовок, меня побудило вот это явление. Которое является причиной того, почему я не могу попасть на собственный блог уже достаточно долгое время без использования вот этой вещи.

Честно говоря, меня, как IT-специалиста глубоко забавляют потуги на указанное явление, так как я согласен с автором статьи в Википедии в утверждении, вынесенном в эпиграф.

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

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

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

Никакой CP. То, что там лежит, даже с большими натяжками квалифицировать как CP невозможно. По большей части это даже на эротику не тянет. Пара -тройка книг, которые без особого труда находятся в обычной библиотеке или интернете. Зеркала нескольких популярных сайтов. Немного контрафакта. Немного заурядной политики. Никаких волшебных дверок папы Карло, по меткому выражению одного моего знакомого. То есть ничего такого, что оправдывало бы какие либо запретительные действия, ну кроме, разве что, перерасхода интернет-трафика.

Системы анонимизирующих прокси-серверов среди незнающей публики (даже приближенной к IT) почему-то вызывают несравненно больший священный трепет.

Как мне однажды довелось услышать от одного "руководителя" IT-компании (!): Тор перебирает IP-адреса, это троян, нельзя его использовать! (Стыдно, барышни! У Тор открытый код и любой, считающий себя специалистом, способен его прочитать, проанализировать и убедиться лично, что в коде есть а чего нет и не было).

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

Кстати говоря, заблокировать доступ через сеть Тор достаточно просто на уровне файрвола, при желании - как я писал здесь. Я бы даже сказал - тривиально.

Заблокировать доступ в саму сеть тор (точки входа) значительно трудней (хотя, как уверяют, всемогущий Китай заблокировал 80% сети Тор - настоящий подвиг, я считаю, состояние сети и ее состав меняется каждые 5 минут), хотя и не абсолютно невозможно.

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

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

Итак, возвращаясь к нашим баранам. По моему личному мнению, подземные сети не содержат предосудительного контента. Так что причина такой нелюбви к анонимусам - вовсе не та, что декларируется желающими профильтровать контент. Отставить политику, религию и мораль. Кому не нравится контент - тот его игнорирует. По моему же скромному ИМХО цитата старшего поколения - "У наших детей уши золотом завешены" и "Свинья грязи найдет". Если это вдруг не так - это проблемы исключительно детей и их родителей, никак не их учителей, наставников и начальников.

Как замечательно сказано на сайте Freenet:

The true test of someone who claims to believe in Freedom of Speech is whether they tolerate speech which they disagree with, or even find disgusting. If this is not acceptable to you, you should not run a Freenet node.

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

Итак, технические возможности. 

Можно ли блокировать использование сабжа?

Теоретически - да. Если выключить весь интернет :).

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

Блокирование веб-прокси - одна из самых простых задач. Настраиваем наш корпоративный прокси на блокирование списка, да не забываем обновлять его почаще.Можно автоматизировать задачу скриптами.

Касательно анонимизирующих прокси - тут похуже. Для некоторых сетей можно заблокировать выходные ноды. Точки входа заблокировать практически нереально - их миллионы. Один плюс - как правило, все они требуют установки клиента на локальные машины.

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

Говоря простым языком, предприятия могут определять какую угодно политику безопасности (с оговорками, касающимися конституционных норм, здравого смысла и регулирующего законодательства). И реализовывать ее техническими средствами.

На более высоком уровне подобные действия бессмысленны. Хотя бы с точки зрения здравого смысла.

Меч всегда побеждает щит.

суббота, 6 ноября 2010 г.

Фрагментация ZFS - мифы и реальность

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

Давайте расставим точки над Ё.

Прежде всего, определимся со спецификой предмета.

Да, существует такое явление, как фрагментация файловых систем.

На UFS фрагментация диагностируется средствами fsck - которая сразу показывает степень фрагментированности файловой системы. На ZFS инструмента, который бы показывал фрагментированность файловых систем и (опционально) позволял бы выполнять дефрагментацию, не существует.

Соответственно, отсутствие такого инструмента сразу ставит под вопрос большинство заявлений о фрагментации ZFS. 


Ах, ничем... А на основании чего тогда делаются подобные заявления?

Один из наиболее корректных материалов на данную тему был найден здесь.

Вкратце суть этого документа можно пересказать так.

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

Да, небольшие файлы могут не заполнять экстент целиком, а идеология COW может привести к появлению некоторого количества мертвого пространства на уровне частично заполненных экстентов. Однако внутренняя структура данных ZFS такова, что данное явление может проявляться лишь кратковременно. Даже UFS умеет использовать частично заполненные блоки для минимизации фрагментации.

Метаданные в ZFS организованы таким образом, что фрагментации на уровне экстентов как таковой нет и быть не может. Читайте исходники.

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

Говоря простым языком, всего лишь выберите подходящий размер recordsize для вашей файловой системы и проблемы как таковой не будет.

Есть другая сторона медали и она была хорошо документирована.

При высокой степени заполнения пулов идеология COW начинает запинаться, поскольку некуда писать измененные копии данных. Что вызывает резкое падение производительности и увеличение нагрузки на процессор. Данная поведенческая особенность, в общем, совершенно естественна и вытекает из достоинств системы. Собственно, нетрудно было догадаться, что COW будет в подобном случае вести себя именно так. Вовремя расширяйте пулы, добавляя новые vdev, устанавливайте квоты и резервации файловых систем и все будет в порядке. Ах, вы ждали чуда, что система сама за вас все сделает... Ну так это не так. Правильное администрирование никто не отменял. Повторяю для тех, кто на бронепоезде. Квоты и резервации, поддерживаемые ZFS с самых первых релизов. Не допускайте чрезмерного заполнения ФС и все будет в порядке.

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

Если говорить о практической стороне дела, то автор больше трех лет круглосуточно эксплуатировал нагруженный прокси-сервер на ZFS под Solaris 10 с использованием зеркального пула с размером recordsize по умолчанию. Никакого заметного снижения производительности по мере роста аптайма не наблюдалось (это если говорить о гипотетической фрагментации, которая могла бы быть таком образом косвенно измерена), степень заполнения пула составляла около 40%, никаких эффектов и отклонений в худшую сторону по отношению к UFS (на которой первоначально был развернут сервер) не наблюдалось. Был лишь немного лимитирован размер кэша ZFS с целью освободить память под кэш прокси и уменьшить реальную конкуренцию за оперативную память между приложением и файловой системой.

В то же самое время свыше двух лет эксплуатировался сервер с БД Oracle 10 на ZFS. Были выполнены большинство рекомендаций Oracle по ZFS. Пул данных базы был структурирован на несколько файловых систем с разным значением recordsize. Время отклика БД после миграции с UFS на ZFS улучшилось с 0,1с до 0,02с и более не менялось. Степень заполнения пулов составила в среднем 55%.

Что я делаю не так?

1. Я не включаю компрессию пулов. Компрессирование данных на лету может сильно понизить производительность обменных операций. Это самоочевидно и не требует пояснений.
2. Во многих случаях имеет смысл ограничить кэш ZFS. Хотя она освобождает память по первому требованию, существует достаточное количество приложений, агрессивно использующих оперативную память.
3. Я не использую RAID-Z. Я считаю, что большинство RAID-5-подобных организаций недостаточно производительны.
4. При создании зеркальных пулов я высаживаю разные шпиндели на разные контроллеры (каналы ввода вывода).
5. Я выбираю размер recordsize адекватно среднему и ожидаемому размеру файлов, которые предполагаю хранить на ФС.
6. Я никогда не ставлю ZFS поверх аппаратного или софтверного RAID. Это глупо, иррационально и снижает производительнось. А также напоминает известный анекдот про монашку, свечку и презерватив.

В общем-то, это все, коллеги. Никаких волшебных средств и серебряных пуль. 

четверг, 4 ноября 2010 г.

Фатальный недостаток

Написать данную статью меня побудила ситуация, сложившаяся вокруг OpenSolaris в связи с его поминками. Хотя, в общем-то, ситуация не новая во всех отношения.

Начать, конечно, следует вообще с обстановки в мире open source. Исключая отдельные устоявшиеся программы и утилиты, UNIX-подобные операционные системы почему-то всегда являлись лакомым кусочком для деятелей от IT, желающих создать свою ОС (не иначе, как под влиянием комплекса неполноценности перед лицом Майкрософт) с блэкджеком и шлюхами.

Растащив исходники Solaris, начали клепать свои сборки (деривативы, или, что более правильно на мой взгляд, девиации):

  • Illumos, a full-opensource fork of the project, started in 2010 by a community of Sun OpenSolaris engineers and the NexentaOS support - Note that OpenSolaris was not 100% opensource, some drivers and some libraries were property of other companies that Sun (now Oracle) licensed and was not able to release.
  • OpenIndiana, a project under the Illumos umbrella aiming "... to become the defacto OpenSolaris distribution installed on production servers where security and bug fixes are required free of charge."[25]
  • Belenix, Live CD[55]
  • EON ZFS Storage,[56] a NAS implementation targeted at embedded systems
  • Jaris OS, Live DVD and also installable.[57] Pronounced according to the IPA but in English as Yah-Rees. This distribution has been heavily modified to fully support a version of Wine called Madoris that can install and run Windows programs at native speed. Jaris stands for "Japanese Solaris". Madoris is a combination of the Japanese word for Windows "mado" and Solaris
  • marTux, Live CD/DVD,[58] first distribution for SPARC
  • MilaX, small Live CD/Live USB[59]
  • napp-it,[60] free Browser managed internet/ san/ nas/ project, based on nexenta3 or eon/opensolaris
  • Nexenta OS, Ubuntu-based with ZFS[61]
  • NexentaStor, optimized for storage workloads, based on Nexenta
  • SchilliX, Live CD
  • StormOS, a lightweight desktop OS based on Nexenta and Xfce.
  • OSUNIX


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

Я клоню в ту сторону, что даже Индиана (один из самых ортодоксальных деривативов) имел только ядро Соляриса. Уже такой вещи, как совместимости на уровне пакетов, в нем не было (команда pkgadd отсутствовала, пакеты устанавливались совершенно иначе).

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

Единственная по-настоящему полноценная монолитная ОС от начала и до конца, BSD, тоже не избежала печальной участи большинства религий - раскольничества.


Все лучше и лучше. Ладно бы разница была чисто косметической, как в большинстве линуксовых деривативов. Так ведь доходит до различий в ABI, управлении конфигурацией и других не менее критичных вещах.

Смотришь на систему. Вроде бы тот же самый Солярис с перекрашенной мордой - ан, нет! Той команды нет, этой команды нет, здесь дерево директорий другое, тут конфиг не там лежит, а здесь вообще нет конфига.

Линуксы (во множественном числе) это вообще отдельная тема. Больше 300 известных деривативов, из которых 17 (!) наиболее известны. Вам не кажется, что это слишком? Мне - кажется. Разница между некоторыми настолько велика, что по-сути можно говорить о разных системах.

Стоять, я знаю, что по большей части ядро одно и то же. Просто у ядра есть конфигурационное окружение, а еще есть юзерленд, который не только из гуя состоит.

Забавный факт. Столлман настаивает на названии GNU/Linux и переругивается с Тео на тему того, чья лицензия свободней. Тео де Раадт чхал на Столлмана и продолжает клепать свою OpenBSD (не самый плохой дериватив, кстати говоря).

Линукс вообще, по большому счету, полноценной операционной системой не является. По сути своей, это ядро Minix и некоторое количество разнородного софта, собранного вокруг этого ядра. Архитектурной целостностью там и не пахнет.

Но речь не об этом, опять таки. А о фатальном недостатке open source. А конкретно, об операционных системах.

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

Например, мне категорически не нравится исчезновение канонических ссылок rc.X. Да, SMF круче и лучше. И рефлекторно набираешь не те команды. Но когда, для включения сервиса надо редактировать /etc/rc.conf, и, в большинстве случаев, перезагружаться. Когда провозглашается монолитное ядро, но тем не менее возможность динамической загрузки модулей-таки присутствует... Как-то становится несколько не по себе. Про несовпадение структуры основных директорий я просто молчу. Здесь сюрприз может оказаться ошеломляющим. Ах, да, и не забудьте, что шеллы по умолчанию практически везде выбраны по желанию разработчика. Сюрприз, правда? 

А желание разработчика - это, в общем, зависимость от фаз луны, ПМС и тому подобных радостей жизни. Прямо и открыто это сказано здесь:

Another major consideration is the wishes of the developers. The OpenBSD developers are the ultimate judges of what does and doesn't go into the project. Just because an application is "good" doesn't mean the OpenBSD project wishes to devote the resources needed to maintaining it, or that they will share other's enthusiasm about its place in OpenBSD. 

Там же:

Of course, If you wish to use one of these packages and your use is compatible with the license of the products, no one will stop you (that wouldn't be very free if we tried, would it?). However, your needs may change -- you may not want to develop a "Killer Application" that you can't sell, distribute, or get rich from because you incorporated non-free software into it. 

Я обхожу стороной вопросы поддержки, своевременных обновлений, бинарной и пакетной совместимости, наконец. Жаль, что OpenSolaris не избежал общей участи.

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

Линукс популярен не потому, что хорош. А потому, что в него вовремя вложили очень много денег.

Windows повсюду не потому, что хороша. А все по той же самой причине. "Вы не представляете, как много можно сделать, имея миллиард долларов" (фраза, приписываемая не то Биллу, не то Стиву).

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

А теперь и OpenSolaris присоединился к компании.