В Винде есть вируса. Наверно стоит определиться с понятием вирус. Вирусом считается программа способная к самокопированию. Что эта программа делает – уже другой вопрос. Например, файл autorun.inf использует служба автоматического запуска приложений или программ, находящихся на сменном носителе. Это когда появляется табличка с вопросом какое действие выполнять. При втыкании флешки в комп эта служба считывает файл autorun.inf на флешке и запускает программу, например, с вирусом. Что бы вирус выполнял свои функции ему (программе) нужны права доступа, например, для обращения к папке с адресами электронной почты, к данным номеров кредитных карт, к порту 110 и протоколу POP3 (эта вся фигня нужна для сбора информации о банковских счетах, номеров кредиток и отправки этой информации на почту). Так вот, еще раз повторюсь, что для каких либо действий нужны права доступа или права на изменение права доступа, хотя бы в первый момент, что бы эти права установить, если этих прав нет. И вот тут появляется просто принципиальное отличие в двух разных подходах.
В nix системах есть super user – root (даже команда есть sudo – сокращение от сделать от имени super user), он один единственный является админом системы, от имени которого можно делегировать права другим пользователям, но полноценными админами системы они не станут (наверное). В винде же этих пользователей можно сделать сколько угодно, просто добавив в группу «администраторы системы» или установив доверительные отношения, это так называемая ролевая система управления, которая есть и в Солярисе. Эти два подхода имеют свои преимущество и недостатки. Важно же и в том и в другом случае не отрицать, что во всех системах есть уязвимости. И, часто, эти уязвимости дорастают до эксплойта (читай вируса) через программы или службы и сервисы. Это значит, что если какая то программа, например торренты или какая то другая служба (сервис), работает от админа (читай зашли в систему под админом и шаримся в инете), то кто-нибудь сможет получить админские права к системе через дыру в сервисе. Это я говорю к тому, что сидение под админом в Винде является скорее правилом, чем исключением. В подтверждении моих слов можно прочитать интервью
http://www.thg.ru/network/dino_dai_zovi/print.html
о взломе (и организации безопасности) «самой невзламываемой и безвирусной MacOS», ее спасает только то, что пользователей этой ОС наверное 1%.
Далее, в nix системах есть очень большая засада – все пользователи имеют идентификаторы. Идентификатор пользователя root всегда во всех nix системах имеет значение 0. Например, вы разрешаете в экспортируемой файловой системе на сервере запускать некие приложения. Пользователь root на сервере и клиенте, фактически, разные люди. Получается, что процесс запущенный на сервере будет иметь овнера с идентификатором 0 – root, таким образом, кто то сможет запустить на сервере непонятно какое приложение от имени root сервера. А может вообще оказаться так, что записаный файл на сервак будет иметь идентификатор, который на сервере не присвоен не одному пользователю, файл получится бесхозным. Это является рудиментом от того, когда у «больших по грандиозности компов» были только терминалы. Серваки Виндовс же развивались как совокупность рабочих станций объединенных в единую сеть. Как правильно разрулить данную ситуацию в Солярисе мне писать лень.
Следующим шагом (для конкретных параноиков) к усилению безопасности является модель песочниц – когда некий процесс или данные являются изолированными от остальной системы. Даже если получить полный контроль над процессом или данными, то это никак не должно повлиять на безопасность остальной системы. И вот тут ZFS опять forever. В Солярисе есть понятие зон. Весь корневой каталог / представляет из себя глобальную зону. В это глобальной зоне можно создать отдельные зоны. Сами зоны изолированы друг от друга, приложение, запущенное в одной зоне никак не влияет на другую зону. По сути, в каждой созданной зоне можно установить отдельную систему и не обязательно Солярис. Получается своего рода набор виртуальных машин с глобальным управлением. В одной зоне можно поднять веб сервер, а в другой зоне файл сервер. Если слетит по каким то причинам веб сервер, то файл сервер будет работать. Кажется, причем тут ZFS? А ZFS тут как раз является тем инструментом, с помощью которого происходит конфигурация зон «на лету» простыми командами. Более того, можно создать снимок зоны, для последующего восстановления. И даже если слетела ОС в зоне, то создать реплику на ZFS займет совсем немного времени. При этом совсем необязательно переустанавливать систему. А также увеличение квот на размер дискового пространства под определенные каталоги делается «на коленке». Вот только надо ли все это для домашнего NAS. Или каталоги «Как мы пили на рыбалке» и «Фото Ленки в ванной» особой важности и конфиденциальности.

Как с веб интерфейсом, или настройкой Х-сервера?

Чего не хватает, так это описание ZFS, чем именно и ценна Солярис.
Пользователю MS Windows не привычна организация файловой системы. Сразу бросается в глаза создание файловых систем внутри корневой файловой системы.
Пишу со своей точки зрения, как пользователь (не администратор) ОС от MS.

При установке у вас был единственный HDD. Но, как правило, устанавливается система на сервер с несколькими дисками. При установке Солярис, приходится выбирать на какой из дисков будет поставлена система. И здесь кроется очень большая трудность, которая прямо ставит в тупик – какой из дисков выбрать, и почему только один?

Все пространство для хранения данных в ZFS объединяется в pool – по русски пул или множество пулов. В пуле может быть от одного до нескольких дисков. По рекомендациям Sun в один пул объединять лучше не более 9 дисков. А пулы потом объединять в тома. Представление файлов и каталогов в Unix-подобных системах отличается от Виндовс. Это значит, что в этих системах нет дисков C: и D: или съемного диска F:. Вся файловая система представляется в виде дерева. Корень файловой системы всегда начинается со знака /.

Например, путь к файлу в Виндовс C:\windows\system32\gpedit.msc (каталоги в винде разделяются обратным слешем, наверное, что бы не так как в nix) в Солярис будет выглядеть /etc/dfs/dfstab. В nix системах нет понятия расширения файла как в винде. Это значит, что имя файла Terminator ничем особо не отличается от Terminator.avi или Терминатор2.СудныйДень.Шварц_в_главной_роли. Прописные и строчные буквы различаются, Index.html и index.html – это два разных файла.

Если вставить CD, то файлы с диска появятся не в disk (E:), а в каталоге /cdrom. В данном случае каталог /cdrom является точкой монтирования для файлов CD диска. Точку монтирования можно задать любую, за некоторым исключением. Например, сверхглупостью будет что то расшаривать и копировать в папку с:\windows для общего доступа. Так и в Солярисе есть обособленные каталоги. В сетях CIFS (винда) расшаренные папки подключаются в виде сетевых дисков. В nix расшареные файлы и каталоги монтируются в отдельный каталог с файловой системой NFS. Кстати, в винде тоже можно подключить диск к отдельной папке.

Все пулы HDD (не обязательно HDD, в Солярисе могут быть гибридные пулы) должны иметь точку монтирования в файловой системе. Самый первый пул с файловой системой ZFS создается на тот диск, который выбран в начале при установке Солярис. Посмотреть пулы можно набрав команду zpool list в терминале. Загружаемый корневой пул имеет имя rpool с точкой монтирования /rpool. В этом пуле создается файловая система ZFS с каталогом /rpool/export/ в котором создаются каталоги с файловыми системами пользователей. Посмотреть созданные файловые системы ZFS можно командой zfs list.

В загрузочный rpool можно добавить диски командой zpool add rpool [имя_диска]. Имена SATA дисков в Солярисе для архитектуры Intel без каких либо SCSI контроллеров имеют вид, например, c1d0s2. Где с1 – номер контроллера, d2 – номер диска на контроллере, s2 – номер раздела (slice) на диске. В данном случае s2 – обозначает весь диск.

Что бы узнать имя диска в пуле rpool надо набрать команду zpool status. Она выведет информацию о пулах в системе, в том числе и об используемых в них дисках. Таким образом мы узнаем имя загрузочного диска.

Самым простым способом узнать имя остальных дисков – это набрать команду /usr/sbin/format или просто format. И вот тут кроется засада. Что делать с остальными дисками? Согласно Сановскому букварю в Солярисе – к загружаемому корневому пулу rpool нельзя добавлять диски более 1Т… Не знаю как это характеризовать, или это для старой версии ZFS. У меня загрузочный диск оказался размером 150G. Поэтому остальные диски я просто объединил в новый пул zpool create [имя_пула] [диск1] [диск2] [диск3] [диск4] [диск5]. Таким образом получилось дисковое пространство данных с отдельной файловой системой отделенных от загрузочной файловой системы ОС. Осталось только перенести точку монтирования создать каталоги под данные и установить права доступа. Не забыть о CIFS.