OpenSolaris HomeNAS part 2. Настройка сети.

Теперь подразумеваем, что Opensolaris у нас установлен, терминал успешно запущен. Следующий логичный шаг – настройки! В частности, сети – бо я благополучно опускаю возможные проблемы с запуском X-сервера, например. Мы ставим сервер, поэтому у него, как и у всякой серьезного сервера, как то ни банально, должен быть IP-адрес. В моем случае – это адрес 192.168.56.254/24, роутер 192.168.56.1, DNS-сервер – 192.168.56.1. Нам нужно:

  1. отключить dhcp-клиента, который по умолчанию работает на каждом установленном в системе адаптере
  2. прописать статический адрес

Я сам использую редактор VI (вот шпаргалка по его использованию – рекомендовано к ознакомлению) – фактически, он есть на (почти?) любой unix-like системе, прост и относительно удобен. Вы же можете редактировать файлы любым удобным для себя образом.

Итак, определяемся, какие сетевые интерфейсы есть в системе, дедовским методом:

ifconfig -a

 e1000g0: flags=1004843 mtu 1500 index 2
        inet 192.168.56.101 netmask ffffff00 broadcast 192.168.56.255
        ether 8:0:27:8e:75:6a 

Останавливем NWAM (Network Auto-Magic), средство для автоматического конфигурирования сетевых устройств в Opensolaris:

svcadm disable network/physical:nwam

Правим файл /etc/nwam/llp, было:

e1000g0 dhcp

стало:

e1000g0 static 192.168.56.254/24

… где e1000g0 – наш сетевой интерфейс, найденный старым дедовским методом 😉
Не забываем прописать роутер по умолчанию:

echo "192.168.56.1" > /etc/defaultrouter

И наш DNS-сервер:

echo "nameserver 192.168.56.1" > /etc/resolv.conf
cp -p /etc/nsswitch.dns /etc/nsswitch.conf

Применяем наши настройки сети и проверяем результат наших манипуляций:

svcadm enable network/physical:nwam
ifconfig -a

 e1000g0: flags=1004843 mtu 1500 index 2
        inet 192.168.56.254 netmask ffffff00 broadcast 192.168.56.255
        ether 8:0:27:8e:75:6a 

На сладкое оставляем перезапуск – не вдаваясь в детали, даем команду reboot.

Детально на русском языке про изменение настроек NWAM/сети можно почитать здесь.

С сетью закончили.

5 thoughts on “OpenSolaris HomeNAS part 2. Настройка сети.”

  1. Тот самый Дмитрий says:

    Продолжайте, умоляю! Я удивлен, почему нет комментариев? У меня появилось желание построить домашний NAS на OpenSolaris с ее ZFS как только она появилась в свободном доступе. Конечно было-б здорово, чтоб это было не просто хранилище с расшаренными папками для windows и linux пользователей, а полноценный NAS с прикрученным веб интерфейсом, кучей протоколов и !медиа сервером! для разных устройств. Btw, я из Таганрога 🙂

    1. Нда, с web-интерфейсом – засада. Умолять не надо – щас с ремонтом малость устаканиться – буду доступен для комментариев 😉

  2. Евгений says:

    Прочел с удовольствием, спасибо.

    Чего не хватает, так это описание 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.

  3. Всецело согласен! Я как-то не задумывался, что “пою” с точки зрения человека, который уже довольно долго работает с solaris – тем самым Ваше мнение особо ценное!

  4. Евгений says:

    Продолжаем вынос мозга про nix системы и ZFS.
    Стратегию организации данных можно понять, прочитав это.
    http://citkit.ru/articles/1341/
    Вы еще не поняли, что ZFS forever? Если нет, то читаем комментарии.

    В Винде есть вируса. Наверно стоит определиться с понятием вирус. Вирусом считается программа способная к самокопированию. Что эта программа делает – уже другой вопрос. Например, файл 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. Или каталоги «Как мы пили на рыбалке» и «Фото Ленки в ванной» особой важности и конфиденциальности.

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

Leave a Reply