В своей статье я хочу представить уважаемому хаброобществу практическое руководство по сборке, настройке и вводу в эксплуатацию недорогого и экономичного сервера на платформе Intel Atom и ОС Centos 7. Сей труд не претендует на полноценный и исчерпывающий учебник и рассчитан, скорее, на начинающих, чем на профессионалов. Если человек, до этого в глаза линукс не видевший, сможет при помощи этой статьи сконфигурировать свой первый сервер, я буду считать свою задачу выполненной.
Первая часть статьи (небольшая по объёму) посвящена аппаратной составляющей, а вторая, основная часть — подробному описанию процесса настройки на этой аппаратуре системы Centos 7. Кому интересно, прошу под кат.
Седьмое поколение систем семейства Red Hat (RHEL7, Centos 7, Sceintific Linux 7, Fedora 20) является пока ещё довольно новым, и, несмотря на очень подробную документацию на официальном сайте Red Hat, далеко не все удалось завести вполоборота. Поэтому я и решил написать подробное how-to на тему настройки сервера общего назначения с использованием последнего дистрибутива Centos.
Что мне хотелось получить с точки зрения железа:
Программный функционал на первом будет таким:
В туда же встанут SVN сервер с броузерной оболочкой (прошу не винить за устаревшие технологии), пакетный репозиторий (типа Nexus), сервер релизов (скорее всего, Hudson, хотя тут я ещё не определился). Хотя эти последние компоненты я уже описывать не буду.
Корпус я отыскал достаточно быстро: По высоте всего 1U, по глубине — 25 см. Отсюда сразу же возникли ограничения на материнскую плату — Mini-ITX, и на блок питания — 1U FlexATX.
С материнской платой все оказалось не так просто. Формат Mini-ITX, два гигабитных порта и пассивное охлаждение оказались серьёзными ограничениями. Сначала рассматривал вариант от GIGABYTE и уже почти смирился с 10 ваттами рассеиваемой мощности процессора и, судя по форумам, возможными проблемами с линуксом. Однако в самый последний момент буквально случайно наткнулся на плату от SUPERMICRO с процессором Intel Atom и уже через пару дней держал её в руках. Основным фактором помимо низкого энергопотребления явилась то, что производитель заявил полную и безоговорочную поддержку этой платой Red Hat, хоть и не самой последней версии. Забегая вперёд скажу, что это оправдалось — при настройке линукса со стороны железа проблем не было никаких, от слова совсем.
Плата имеет один разъем памяти, максимум 8GB DDR3-1333 ECC SO-DIMM. Список сертифицированной памяти на сайте производителя достаточно скудный, пришлось зайти с другой стороны. Стал искать, кто из производителей памяти поддерживает эту плату. Нашёл. Выбор пал на Crucial, так как на ихнем сайте есть не только возможность поиска по наименованию материнской платы, но и возможность непосредственного заказа. У них же заказал SSD на 250 Гб, с почти одинаковой скоростью чтения/записи около 500 Мб/сек.
Последняя деталька — блок питания. К сожалению, БП с пассивным охлаждением пока ещё экзотика, нашёл только один вариант, его и заказал. Им оказался FSP150-50TNF. Сайт производителя отыскать так и не смог, купить же его можно в огромном количестве онлайн магазинов.
Со сборкой никаких проблем не было. Втыкать, как говорится, не паять. В корпусе имеются два вентилятора, подключать я их не стал. Итого, получилась такая конструкция:
Общая стоимость всех компонент с доставкой получилась 745 евро. Забегая вперёд скажу, что потребляемая мощность собранного и полностью настроенного сервера около 14-15 ватт.
О программной настройке этого сервера речь дальше и пойдёт. Дистрибутив линукса я выбрал, исходя из меркантильных соображений. В компании, где я работаю (оффтопик: я математик-инженер, разрабатываю прикладное ПО в области систем управления воздушным движением), мы используем Red Hat или Centos как для разработки, так и как платформу для установки клиентам.
Дистрибутив в виде ISO, оптимизированный для сетевой установки (CentOS-7-x86_64-NetInstall-1503.iso), можно взять отсюда. После чего из него нужно сделать загрузочную флешку.
Моей первой ошибкой было использовать для этой цели утилиту Unetbootin для Windows. Флешку эта утилита конечно записала, она даже опознавалась как загрузочна, но вот ядро инсталлятора с неё категорически отказывалось грузиться, постоянно вылетая с какими-то левыми сообщениями типа «kernel panic». Исследование форумов показало, что я не один такой криворукий. Поэтому флешку я в результате подготовил из под линукса:
Все, флешка готова. Для следующего шага нужен любой монитор с возможностью подключения к VGA разъёму, так как плата не имеет ни DVI, ни HDMI, только старый добрый VGA. Также на плате всего два внешних USB3 порта, внутренних портов нет. Один порт нужен для загрузочной флешки, во второй через USB-хаб воткнём клавиатуру и мышь.
Подключаем монитор, клавиатуру, мышь, сетевой кабель с доступом в интернет, кабель питания. Устройство включается само. На плате мигает зелёный светодиод, насколько я понял, он связан с тактированием. Входим в BIOS. Цель и конечный результат — разрешить загрузку с USB. Все остальные настройки я оставил без изменений.
Вставляем флешку в свободный разъем, перезагружаемся. На мой взгляд, графический инсталлятор интуитивно понятен, поэтому пока обойдусь без картинок. Уже в процессе написания статьи я обнаружил красочное руководство по установке, там все очень подробно сфотографировано. Опишу только, что необходимо сделать на данном этапе, чтобы потом сберечь время и нервы:
После этого нажимам на «Начать установку». Пока идёт скачивание и установка пакетов, имеется возможность задать пароль рута, а также добавить пользователей в систему. После завершения установки перезагружаемся и с другого компьютера проверяем доступ по ssh. Так как он по умолчанию сконфигурирован, то все должно работать. Самое время отцепить монитор и клавиатуру и установить сервер на место постоянной дислокации в стойку, подключить к сети и запустить. Дальнейшая настройка будет производиться удалённо через консоль.
Итак, логируемся с другого компьютера по SSH. Если другой компьютер работает под управлением Windows, то в качестве ssh-клиента можно взять старый добрый putty. Естественно, все дальнейшие операции делаются из под рута. Банальность, но отмечу, что переход в режим рута осуществляется командой:
1. Первое, что необходимо сделать на свежеустановленной системе — обновить её. В системе уже присутствует пакетный менеджер yum. Он доступен из консоли (команда yum). Пакетные репозитории уже настроены по умолчанию, поэтому для обновления всей системы достаточно команды:
2. Ещё с досовских времён я не могу жить без файлового менеджера, желательно в синих тонах, поэтому сразу ставлю себе линуксовый аналог нортон-коммандера. Хотя это вопрос личных предпочтений. Подтягивается около 30 дополнительных пакетов, в основном perl:
3. Затем мне нужны средства мониторинга для сенсоров, расположенных на материнской плате. Ставится один дополнительный пакет:
4. Сенсоры нужно инициализировать:
5. Просматривать значения сенсоров можно так:
Напомню, что вентиляторы отключены. Температура в трёх точках несколько завышена, но всё же далека от критичной.
Не могу сказать ничего конкретного про те или иные решения, я выбрал VNC и GNOME просто потому, что уже использовал их ранее. На сервере ставятся следующие компоненты:
Подтягивается около 650 дополнительных пакетов (объём загрузки около 660 Мб, объём установки около 2 Гб).
Сетевой экран мы будем настраивать позже, но так как он из коробки уже есть и активен, нужно добавить вновь установленный сервис в его правила.
Так как удалённый рабочий стол мне нужен эпизодически, я не стал настраивать его автоматическую загрузку. Если он нужен, то необходимо сначала войти на сервер по ssh (не как рут, а как пользователь, от лица которого будет запускаться сессия), и запустить его вручную командой:
При первом запуске будет предложено задать пароль сессии и будет выдан номер терминала, под которым сессия доступна. При всех последующих запусках номер сессии будет показываться ещё раз:
Этот номер и пароль потребуются на клиенте для подключения к рабочему столу с использованием любого VNC-клиетна.
Многие вещи можно настраивать через удалённый рабочий стол в графическом интерфейсе, а не в консоли. Например, имеются приложения gpk-application для установки/удаления и gpk-update-view для обновления пакетов:
Чтобы облегчить настройку рабочего стола под свои привычки, дополнительно можно установить утилиты настройки и модуль, позволяющий устанавливать из броузера (только из Firefox) расширения для оболочки GNOME:
Для установки расширений оболочки можно посетить официальный репозиторий, используя Firefox.
Одна из сетевых плат уже настроена в момент установки системы. Эта плата (интерфейс) с адресом 192.168.178.2 будет использоваться для доступа в мир, к ней напрямую будет подключёно внешнее интернет-соединение. Вторая плата с адресом 192.168.1.1 будет шлюзовой для внутренней сети, кабель от неё пойдёт в сетевой хаб локальной сети. Именно этот интерфейс и нужно сейчас настроить.
Сеть обслуживается модулем NetworkManager, который конфигурируется как из консоли, так и с помощью графического конфигуратора. Так как модуль уже запущен, то команда проверки его статуса вполне ожидаемо выдаёт следующее:
Воспользуемся графическим конфигуратором, для чего из консоли запустим:
Далее выберем иконку сети:
Задаём нужные параметры для обоих сетевых адаптеров. Важно, чтобы для каждого адаптера был обязательно включён флаг «Connect automatically», иначе после перезагрузки сетевой интерфейс останется выключенным:
Чтобы новые параметры вступили в силу, необходимо перезагрузить сетевой сервис с помощью команды:
Конфигурация адаптеров хранится в текстовых файлах /etc/sysconfig/network-scripts/ifcfg-enp5s0f0 и /etc/sysconfig/network-scripts/ifcfg-enp5s0f1, которые можно редактировать вручную. К сожалению, это придётся сделать позже, так как из графического интерфейса нет возможности привязать адаптер к нужной зоне межсетевого экрана, но об этом ниже. На данном же этапе статус сетевых интерфейсов такой:
Linux позволяет разрешить или запретить пересылку пакетов между интерфейсами (forwarding). На рабочих станциях и серверах приложений её можно запретить. Наш же сервер играет роль маршрутизатора и межсетевого экрана. Поэтому маршрутизация, очевидно, должна быть разрешена.
Маршрутизация управляется параметром net.ipv4.ip_forward из файла /etc/sysctl.conf. Для её включения параметр нужно установить в единицу:
Теперь нужно обновить конфигурацию, чтобы настройки маршрутизации вступили в силу:
Для проверки, включена ли IP маршрутизация, можно выполнить следующую команду, которая должна вернуть единицу:
Межсетевой экран нужен для контроля и фильтрации проходящих через сервер сетевых пакетов. Цель — запрет доступа ко всем сервисам снаружи сети. Межсетевой экран обслуживается модулем Firewalld, который конфигурируется как из консоли (команда #firewall-cmd), так и с помощью графического интерфейса (команда #firewall-config). Служба FirewallD использует инструментарий iptables (iptables tool) для взаимодействия с фильтром пакетов ядра.
На официальном сайте Red Hat можно найти подробную документацию по этому модулю. Также в сети есть подробные руководства по его настройке, например это.
Проверка статуса службы вполне ожидаемо сообщает, что служба запущена:
FirewallD использует сетевые зоны для определения уровня доверия сетевого соединения, соединение может являться частью только одной зоны, но одна зона может определять несколько сетевых подключений.
Какие зоны есть по умолчанию?
Зона является активной, если к ней привязана хотя бы одна сетевая плата. Правила фильтрации задаются именно для активных зон. Какие же зоны у нас активны изначально?
Оба сетевых интерфейса привязаны к одной плате, это значит, задать свои правила фильтрации для каждого интерфейса не получится. Ситуацию нужно в корне менять.
Интерфейс enp5s0f0 с адресом 192.168.1.1 будет доступен из внутренней сети, поэтому все установленные на сервере сервисы должны быть по этому интерфейсу доступны. Доступ же по наружному интерфейсу enp5s0f1 должен быть максимально урезан. Для внутренней сети волевым решением выберем зону internal. В неё нужно перекинуть интерфейс enp5s0f0.
Нюанс, однако: есть две таблицы фильтрации — активная в данный момент и постоянная. При перезагрузке сервера активная таблица восстанавливается из постоянной. Поэтому нужно либо стазу работать с постоянной таблицей (параметр --permanent в командах), либо потом не забыть скопировать активную таблицу в постоянную, когда все изменения сделаны. Изменения в активной таблице применяются мгновенно: сохранять или применять изменения не требуется. Изменения же в постоянной таблице вступят в силу только после перезагрузки таблицы (команда firewall-cmd --reload), сервиса (команда systemctl restart firewalld) или сервера.
Я буду сразу править постоянную таблицу. Удаляю интерфейс из зоны public:
Добавляю его в зону internal:
Проверяю результат:
Вот здесь нас поджидает засада, а именно известный и до сих пор не закрытый баг в Centos 7. Суть: зона интерфейса при перезагрузке берётся из настроек самого интерфейса (файл /etc/sysconfig/network-scripts/ifcfg-enp5s0f0), а вот там она и не изменилась. Это придётся сделать вручную: правим файл /etc/sysconfig/network-scripts/ifcfg-enp5s0f0 и добавляем туда строку ZONE=internal:
После этого чисто для проверки сервер лучше перезагрузить. После перезагрузки привязка интерфейсов к зонам не должна потеряться:
Сервисы добавляются к зоне командой типа
Я же предпочитаю это делать из графической оболочки:
К сожалению, это ещё не все. Есть нюанс, связанный с маскировкой IP адреса (IP masquerading). В пакетах, исходящих из внутренней сети, адрес отправителя должен быть заменён на адрес самого сервера. Если эта функция выключена, то компьютер из внутренней сети никогда не дождётся ответа снаружи, так как его адрес там неизвестен.
Не знаю, с чем это связано, но изменения флага маскировки для адаптера enp5s0f1 как из графической оболочки, так через firewall-cmd не дали никакого эффекта. Рабочее решение нашлось в этой статье. Его суть: задать дополнительное прямое правило POSTROUTING в таблицу iptables, надстройкой на которой FirewallD является:
Перезагрузим таблицу и проверим изменения:
На этом межсетевой экран настроен. Текущую конфигурацию брандмауэра можно проверить такой полезной командой:
Для синхронизации времени по сети (как времени самого сервера, так и времени на клиентских машинах с сервером) настрою NTP сервер. В Centos 7 вместо старого доброго ntpd предустановлен и активирован новый сервис — chrony.
Так как во время установки системы была выбрана опция синхронизации времени по сети, то сервис уже есть и запущен:
Если же команда статуса показывает, что сервис либо не установлен, либо не запущен, то процедура стандартная:
Автоматическая синхронизация времени с удалённым сервером разрешается командой:
Для доступа к сервису из внутренней сети нужно разрешить сервис в брандмауэре:
После чего можно подправить настройки сервиса, которые хранятся в файле /etc/chrony.conf. В этом файле мне было достаточно сделать только две корректировки:
Перезапустим сервис:
Проверим состояние и синхронизацию:
После замены адреса NTP сервера на клиентских устройствах (Windows, Linux, Zyxel) все они дружно подхватили время с сервера.
Единственная цель, с которой я решил поднять службу DNS на сервере — блокировка баннерных сетей, сайтов статистики и всевозможных серверов телеметрии (например, Microsoft) на всех устройствах в локальной сети. Идея не моя, взята отсюда. Поискав в паутине, нашёл несколько сайтов, которые на регулярной основе публикуют чёрные списки доменов в формате hosts-файлов.
Например это и это. Особенностью второго списка является то, что сервера телеметрии Microsoft там уже есть.
В качестве службы DNS я выбрал dnsmasq просто потому, что нашёл простою и понятную инструкцию по его установке и настройке. Dnsmasq реализует одновременно как DNS, так и DHCP сервер, но второй мне пока без надобности, поэтому я буду конфигурировать только DNS.
Начало стандартное:
Далее в конфигурационном файле внутреннего сетевого интерфейса (в моём случае /etc/sysconfig/network-scripts/ifcfg-enp5s0f0) нужно указать, что DNS сервером является локальный хост, т.е. добавить строку:
После включения или перезагрузки сервера служба NetworkManager на основе настроек из этого файла обновляет файл /etc/resolv.conf, который содержит адреса как внешнего DNS сервера (в моём случае это DSL/FritzBox), так и нашего:
Скачав отсюда исходники установленной версии, можно выдернуть оттуда пример конфигурационного файла, подправить его и сохранить как /etc/dnsmasq.d/main.conf. Я его сконфигурировал по-минимому:
Главное здесть — параметр addn-hosts=/etc/black_list_hosts.txt, где black_list_hosts.txt — это и есть чёрный список доменов. В моём случае, я пока просто скачал его отсюда. Как результат — баннерной рекламы на всех устройствах локальной сети (как настольных, так и мобильных) практически не стало. В будущем я собираюсь автоматизировать процесс обновления этого списка.
Это последняя компонента, о которой я немного напишу. Samba — файловый сервер для совместного доступа к файлам со всех устройств локальной сети. Устанавливается он просто:
Я выдам в совместный доступ только одну папку: /work/nas. Для этого нужно отредактировать файл /etc/samba/smb.conf и указать там параметры доступа к этой папке:
По умолчанию папка сконфигурирована «только для чтения», но пользователь с именем family имеет доступ на запись. Запускаем сервис и проверяем его настройки:
Далее нужно создать папку и обеспечить доступ к ней. Доступ получит группа пользователей fileshare:
Далее есть особенность. Дело в том, что в Centos установлена дополнительная подсистема безопасности, которая регулирует доступ к ресурсам не только для пользователей, но и для модулей (компонентов) системы. Она называется SELinux. Чтобы сервер Samba сам мог долучить доступ к папке /work/nas, у неё должен быть задан дополнительный аттрибут samba_share_t помимо обычных прав чтения-записи:
Для манипуляции флагами есть стандартная команда chcon. Флаг samba_share_t с её помощью устанавливается так:
Для того чтобы Windows-машины в локальной сети видели наш сервер и общую папку, необходимо также разрешить сервис NetBIOS. Он не требует дополнительной конфигурации, его нужно только запустить:
Часто бывает нужно подмонтировать к этой папке внешний накопитель (диск или флешку), отформатированные под NTFS. Драйвера NTFS в системе по умолчанию нет. Также его нет и в стандартных репозиториях. Если есть потребность подключать диски с NTFS к системе, то нужно установить 3rd-party репозиторий EPEL из проекта Федоры и уже оттуда установить драйвер:
После чего внешние диски диски NTFS будут автоматически опознаваться системой.
Финальный аккорд — создать пользователя, который будет иметь права записи в общую папку. Как видно из конфигурации выше, это пользователь family:
На этом, пожалуй, завершусь. В целом, получилась экономичная и многофункциональная машинка с большим потенциалом. Как я уже отмечал, потребляемая мощность находится в пределах 14-15 ватт, что вполне приемлемо для домашнего аппарата, который постоянно включён. Первый месяц своей жизни он отработал без единой проблемы.
Если у возникли вопросы, замечания, или идеи по улучшению и дальнейшему развитию, то буду рад комментариям. Спасибо!
Первая часть статьи (небольшая по объёму) посвящена аппаратной составляющей, а вторая, основная часть — подробному описанию процесса настройки на этой аппаратуре системы Centos 7. Кому интересно, прошу под кат.
Седьмое поколение систем семейства Red Hat (RHEL7, Centos 7, Sceintific Linux 7, Fedora 20) является пока ещё довольно новым, и, несмотря на очень подробную документацию на официальном сайте Red Hat, далеко не все удалось завести вполоборота. Поэтому я и решил написать подробное how-to на тему настройки сервера общего назначения с использованием последнего дистрибутива Centos.
Что мне хотелось получить с точки зрения железа:
- Энергоэффективность
- 19-дюймовый корпус для монтажа в стойку, высотой не более 1.5U и глубиной не более 30 см,
- Доступ к дискам спереди,
- Минимум два гигабитных сетевых порта,
- Полностью пассивное охлаждение, то есть отсутствие вентиляторов как на процессоре, так и на блоке питания. Это требование чисто эстетическое, так как изделие будет использоваться в домашних условиях.
Программный функционал на первом будет таким:
- Маршрутизатор (IP router) и межсетевой экран (firewall),
- X-сервер с современной оболочкой, лично мне очень нравится третий Gnome. Будет использоваться как для администрирования, так и для нечастого запуска прикладных программ, с которыми я имею дело по роду своей профессиональной деятельности,
- Сервер точного времени (NTP),
- DNS для внутренней сети с блокировкой баннерных сетей (идея позаимствована отсюда),
- Высокопроизводительный файловый сервер.
В туда же встанут SVN сервер с броузерной оболочкой (прошу не винить за устаревшие технологии), пакетный репозиторий (типа Nexus), сервер релизов (скорее всего, Hudson, хотя тут я ещё не определился). Хотя эти последние компоненты я уже описывать не буду.
Немного про аппаратную составляющую
Корпус я отыскал достаточно быстро: По высоте всего 1U, по глубине — 25 см. Отсюда сразу же возникли ограничения на материнскую плату — Mini-ITX, и на блок питания — 1U FlexATX.
С материнской платой все оказалось не так просто. Формат Mini-ITX, два гигабитных порта и пассивное охлаждение оказались серьёзными ограничениями. Сначала рассматривал вариант от GIGABYTE и уже почти смирился с 10 ваттами рассеиваемой мощности процессора и, судя по форумам, возможными проблемами с линуксом. Однако в самый последний момент буквально случайно наткнулся на плату от SUPERMICRO с процессором Intel Atom и уже через пару дней держал её в руках. Основным фактором помимо низкого энергопотребления явилась то, что производитель заявил полную и безоговорочную поддержку этой платой Red Hat, хоть и не самой последней версии. Забегая вперёд скажу, что это оправдалось — при настройке линукса со стороны железа проблем не было никаких, от слова совсем.
Плата имеет один разъем памяти, максимум 8GB DDR3-1333 ECC SO-DIMM. Список сертифицированной памяти на сайте производителя достаточно скудный, пришлось зайти с другой стороны. Стал искать, кто из производителей памяти поддерживает эту плату. Нашёл. Выбор пал на Crucial, так как на ихнем сайте есть не только возможность поиска по наименованию материнской платы, но и возможность непосредственного заказа. У них же заказал SSD на 250 Гб, с почти одинаковой скоростью чтения/записи около 500 Мб/сек.
Последняя деталька — блок питания. К сожалению, БП с пассивным охлаждением пока ещё экзотика, нашёл только один вариант, его и заказал. Им оказался FSP150-50TNF. Сайт производителя отыскать так и не смог, купить же его можно в огромном количестве онлайн магазинов.
Со сборкой никаких проблем не было. Втыкать, как говорится, не паять. В корпусе имеются два вентилятора, подключать я их не стал. Итого, получилась такая конструкция:
Общая стоимость всех компонент с доставкой получилась 745 евро. Забегая вперёд скажу, что потребляемая мощность собранного и полностью настроенного сервера около 14-15 ватт.
Много про программную составляющую
О программной настройке этого сервера речь дальше и пойдёт. Дистрибутив линукса я выбрал, исходя из меркантильных соображений. В компании, где я работаю (оффтопик: я математик-инженер, разрабатываю прикладное ПО в области систем управления воздушным движением), мы используем Red Hat или Centos как для разработки, так и как платформу для установки клиентам.
Шаг первый: подготовка установочной флешки.
Дистрибутив в виде ISO, оптимизированный для сетевой установки (CentOS-7-x86_64-NetInstall-1503.iso), можно взять отсюда. После чего из него нужно сделать загрузочную флешку.
Моей первой ошибкой было использовать для этой цели утилиту Unetbootin для Windows. Флешку эта утилита конечно записала, она даже опознавалась как загрузочна, но вот ядро инсталлятора с неё категорически отказывалось грузиться, постоянно вылетая с какими-то левыми сообщениями типа «kernel panic». Исследование форумов показало, что я не один такой криворукий. Поэтому флешку я в результате подготовил из под линукса:
- вставляем пустую флешку объема большего, чем файл ISO. Тип файловой системы на ней не важен. главное, она не должна быть разбита на тома.
- смотрим, как она смонтирована и какому устройству соответствует:
# cat /proc/mounts
- размонтируем это устройство, иначе в требуемом нам режиме оно будет недоступно:
# umount /dev/NNN
- переходим в режим root и переходим в каталог, где сохранен файл ISO.
- используем стандартную утилиту блочного копирования данных:
# dd bs=4M if=CentOS-7-x86_64-NetInstall-1503.iso of=/dev/NNN
Все, флешка готова. Для следующего шага нужен любой монитор с возможностью подключения к VGA разъёму, так как плата не имеет ни DVI, ни HDMI, только старый добрый VGA. Также на плате всего два внешних USB3 порта, внутренних портов нет. Один порт нужен для загрузочной флешки, во второй через USB-хаб воткнём клавиатуру и мышь.
Шаг второй: подготовка изделия к загрузке.
Подключаем монитор, клавиатуру, мышь, сетевой кабель с доступом в интернет, кабель питания. Устройство включается само. На плате мигает зелёный светодиод, насколько я понял, он связан с тактированием. Входим в BIOS. Цель и конечный результат — разрешить загрузку с USB. Все остальные настройки я оставил без изменений.
Шаг третий: сетевая инсталляция.
Вставляем флешку в свободный разъем, перезагружаемся. На мой взгляд, графический инсталлятор интуитивно понятен, поэтому пока обойдусь без картинок. Уже в процессе написания статьи я обнаружил красочное руководство по установке, там все очень подробно сфотографировано. Опишу только, что необходимо сделать на данном этапе, чтобы потом сберечь время и нервы:
- Задать все параметры сетевой карты, к которой подключён кабель, чтобы работал доступ в интернет: ip, шлюз, dns, и активировать адаптер.
- В окне настроек времени выбрать правильный часовой пояс и настроить время. Я лично всегда использую синхронизацию времени по сети.
- Разбить диск на разделы. Обычно я использую схему разбивки по умолчанию. В ней папка home располагается на своём разделе. Так как пользователь у меня один (я сам), не считая рута, то home мне особо не нужен. Поэтому я переименовываю в этой схеме том home в work, чтобы в будущем система создавала домашние директории пользователей в корневом разделе /home.
- Задать адрес сервера, откуда будут вытягиваться пакеты в процессе инсталляции.
- Выбирать компоненты, которые точно понадобятся. В моем случае это файловый сервер, средства разработки, утилиты мониторинга железа, http-сервер. Все остальное можно добавить потом.
После этого нажимам на «Начать установку». Пока идёт скачивание и установка пакетов, имеется возможность задать пароль рута, а также добавить пользователей в систему. После завершения установки перезагружаемся и с другого компьютера проверяем доступ по ssh. Так как он по умолчанию сконфигурирован, то все должно работать. Самое время отцепить монитор и клавиатуру и установить сервер на место постоянной дислокации в стойку, подключить к сети и запустить. Дальнейшая настройка будет производиться удалённо через консоль.
Шаг четвёртый: настройка базового функционала.
Итак, логируемся с другого компьютера по SSH. Если другой компьютер работает под управлением Windows, то в качестве ssh-клиента можно взять старый добрый putty. Естественно, все дальнейшие операции делаются из под рута. Банальность, но отмечу, что переход в режим рута осуществляется командой:
[user@supermicro]# su
1. Первое, что необходимо сделать на свежеустановленной системе — обновить её. В системе уже присутствует пакетный менеджер yum. Он доступен из консоли (команда yum). Пакетные репозитории уже настроены по умолчанию, поэтому для обновления всей системы достаточно команды:
[root@supermicro]# yum update
2. Ещё с досовских времён я не могу жить без файлового менеджера, желательно в синих тонах, поэтому сразу ставлю себе линуксовый аналог нортон-коммандера. Хотя это вопрос личных предпочтений. Подтягивается около 30 дополнительных пакетов, в основном perl:
[root@supermicro]# yum install mc
3. Затем мне нужны средства мониторинга для сенсоров, расположенных на материнской плате. Ставится один дополнительный пакет:
[root@supermicro]# yum install lm_sensors
4. Сенсоры нужно инициализировать:
[root@supermicro]# sensors-detect
5. Просматривать значения сенсоров можно так:
[root@supermicro]# sensors
Выдача команды sensors
acpitz-virtual-0 Adapter: Virtual device temp1: +26.8°C (crit = +127.0°C) temp2: +26.8°C (crit = +175.0°C) coretemp-isa-0000 Adapter: ISA adapter Core 0: +48.0°C (crit = +100.0°C) Core 1: +49.0°C (crit = +100.0°C) w83795adg-i2c-3-2f Adapter: SMBus iSMT adapter at fe482000 in0: +0.99 V (min = +0.54 V, max = +1.49 V) in3: +1.28 V (min = +1.13 V, max = +1.38 V) in4: +1.83 V (min = +1.63 V, max = +2.00 V) in5: +1.28 V (min = +1.13 V, max = +1.38 V) in6: +1.56 V (min = +1.20 V, max = +1.65 V) in11: +1.07 V (min = +0.94 V, max = +1.17 V) +3.3V: +3.26 V (min = +2.96 V, max = +3.63 V) 3VSB: +3.26 V (min = +2.96 V, max = +3.63 V) Vbat: +3.13 V (min = +2.70 V, max = +3.63 V) fan1: 0 RPM (min = 709 RPM) ALARM fan2: 0 RPM (min = 709 RPM) ALARM fan3: 0 RPM (min = 709 RPM) ALARM temp1: +82.2°C (high = +105.0°C, hyst = +100.0°C) (crit = +105.0°C, hyst = +100.0°C) sensor = thermistor temp2: +82.5°C (high = +105.0°C, hyst = +100.0°C) (crit = +105.0°C, hyst = +100.0°C) sensor = thermistor temp3: +80.8°C (high = +85.0°C, hyst = +105.0°C) (crit = +105.0°C, hyst = +100.0°C) sensor = thermistor temp5: +33.8°C (high = +85.0°C, hyst = +80.0°C) (crit = +100.0°C, hyst = +95.0°C) sensor = thermistor temp6: +37.5°C (high = +85.0°C, hyst = +80.0°C) (crit = +100.0°C, hyst = +95.0°C) sensor = thermistor intrusion0: OK
Напомню, что вентиляторы отключены. Температура в трёх точках несколько завышена, но всё же далека от критичной.
Шаг пятый: удалённый рабочий стол.
Не могу сказать ничего конкретного про те или иные решения, я выбрал VNC и GNOME просто потому, что уже использовал их ранее. На сервере ставятся следующие компоненты:
[root@supermicro]# yum install vnc-server [root@supermicro]# yum groupinstall "GNOME Desktop" [root@supermicro]# yum install tigervnc-server
Подтягивается около 650 дополнительных пакетов (объём загрузки около 660 Мб, объём установки около 2 Гб).
Сетевой экран мы будем настраивать позже, но так как он из коробки уже есть и активен, нужно добавить вновь установленный сервис в его правила.
[root@supermicro]# firewall-cmd --permanent --zone=public --add-service vnc-server [root@supermicro]# firewall-cmd --reload
Так как удалённый рабочий стол мне нужен эпизодически, я не стал настраивать его автоматическую загрузку. Если он нужен, то необходимо сначала войти на сервер по ssh (не как рут, а как пользователь, от лица которого будет запускаться сессия), и запустить его вручную командой:
[user@supermicro]# vnc-server
При первом запуске будет предложено задать пароль сессии и будет выдан номер терминала, под которым сессия доступна. При всех последующих запусках номер сессии будет показываться ещё раз:
[family@supermicro]# vnc-server New 'supermicro:1 (family)' desktop is supermicro:1 Starting applications specified in /home/family/.vnc/xstartup Log file is /home/family/.vnc/supermicro:1.log
Этот номер и пароль потребуются на клиенте для подключения к рабочему столу с использованием любого VNC-клиетна.
Многие вещи можно настраивать через удалённый рабочий стол в графическом интерфейсе, а не в консоли. Например, имеются приложения gpk-application для установки/удаления и gpk-update-view для обновления пакетов:
Чтобы облегчить настройку рабочего стола под свои привычки, дополнительно можно установить утилиты настройки и модуль, позволяющий устанавливать из броузера (только из Firefox) расширения для оболочки GNOME:
[root@supermicro]# yum install dconf-editor gnome-shell-browser-plugin alacarte gnome-tweak-tool
Для установки расширений оболочки можно посетить официальный репозиторий, используя Firefox.
Шаг шестой: Настройка сетевых интерфейсов и маршрутизация.
Одна из сетевых плат уже настроена в момент установки системы. Эта плата (интерфейс) с адресом 192.168.178.2 будет использоваться для доступа в мир, к ней напрямую будет подключёно внешнее интернет-соединение. Вторая плата с адресом 192.168.1.1 будет шлюзовой для внутренней сети, кабель от неё пойдёт в сетевой хаб локальной сети. Именно этот интерфейс и нужно сейчас настроить.
Сеть обслуживается модулем NetworkManager, который конфигурируется как из консоли, так и с помощью графического конфигуратора. Так как модуль уже запущен, то команда проверки его статуса вполне ожидаемо выдаёт следующее:
[root@supermicro]# systemctl status NetworkManager NetworkManager.service - Network Manager Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled) Active: active (running) since Wed 2015-09-30 20:33:01 CEST; 2h 2min ago
Воспользуемся графическим конфигуратором, для чего из консоли запустим:
[root@supermicro]# gnome-control-center
Далее выберем иконку сети:
Задаём нужные параметры для обоих сетевых адаптеров. Важно, чтобы для каждого адаптера был обязательно включён флаг «Connect automatically», иначе после перезагрузки сетевой интерфейс останется выключенным:
Чтобы новые параметры вступили в силу, необходимо перезагрузить сетевой сервис с помощью команды:
[root@supermicro]# service network restart Restarting network (via systemctl): [ OK ]
Конфигурация адаптеров хранится в текстовых файлах /etc/sysconfig/network-scripts/ifcfg-enp5s0f0 и /etc/sysconfig/network-scripts/ifcfg-enp5s0f1, которые можно редактировать вручную. К сожалению, это придётся сделать позже, так как из графического интерфейса нет возможности привязать адаптер к нужной зоне межсетевого экрана, но об этом ниже. На данном же этапе статус сетевых интерфейсов такой:
[root@supermicro]# ifconfig
Выдача команды ifconfig
enp5s0f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::ec4:7aff:fe52:ea84 prefixlen 64 scopeid 0x20<link> ether 0c:c4:7a:52:ea:84 txqueuelen 1000 (Ethernet) RX packets 154172 bytes 27984732 (26.6 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 211719 bytes 187981730 (179.2 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device memory 0xfe120000-fe13ffff enp5s0f1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.178.2 netmask 255.255.255.0 broadcast 192.168.178.255 inet6 fe80::ec4:7aff:fe52:ea85 prefixlen 64 scopeid 0x20<link> ether 0c:c4:7a:52:ea:85 txqueuelen 1000 (Ethernet) RX packets 97054 bytes 130894810 (124.8 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 72249 bytes 6523040 (6.2 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device memory 0xfe100000-fe11ffff
Linux позволяет разрешить или запретить пересылку пакетов между интерфейсами (forwarding). На рабочих станциях и серверах приложений её можно запретить. Наш же сервер играет роль маршрутизатора и межсетевого экрана. Поэтому маршрутизация, очевидно, должна быть разрешена.
Маршрутизация управляется параметром net.ipv4.ip_forward из файла /etc/sysctl.conf. Для её включения параметр нужно установить в единицу:
[root@supermicro]# cat /etc/sysctl.conf net.ipv4.ip_forward=1
Теперь нужно обновить конфигурацию, чтобы настройки маршрутизации вступили в силу:
[root@supermicro]# sysctl -p net.ipv4.ip_forward = 1
Для проверки, включена ли IP маршрутизация, можно выполнить следующую команду, которая должна вернуть единицу:
[root@supermicro]# cat /proc/sys/net/ipv4/ip_forward 1
Шаг седьмой: Настраиваем межсетевой экран.
Межсетевой экран нужен для контроля и фильтрации проходящих через сервер сетевых пакетов. Цель — запрет доступа ко всем сервисам снаружи сети. Межсетевой экран обслуживается модулем Firewalld, который конфигурируется как из консоли (команда #firewall-cmd), так и с помощью графического интерфейса (команда #firewall-config). Служба FirewallD использует инструментарий iptables (iptables tool) для взаимодействия с фильтром пакетов ядра.
На официальном сайте Red Hat можно найти подробную документацию по этому модулю. Также в сети есть подробные руководства по его настройке, например это.
Проверка статуса службы вполне ожидаемо сообщает, что служба запущена:
[root@supermicro]# firewall-cmd --state running
FirewallD использует сетевые зоны для определения уровня доверия сетевого соединения, соединение может являться частью только одной зоны, но одна зона может определять несколько сетевых подключений.
Какие зоны есть по умолчанию?
[root@supermicro]# firewall-cmd --get-zones block dmz drop external home internal public trusted work
Зона является активной, если к ней привязана хотя бы одна сетевая плата. Правила фильтрации задаются именно для активных зон. Какие же зоны у нас активны изначально?
[root@supermicro]# firewall-cmd --get-active-zones public interfaces: enp5s0f0 enp5s0f1
Оба сетевых интерфейса привязаны к одной плате, это значит, задать свои правила фильтрации для каждого интерфейса не получится. Ситуацию нужно в корне менять.
Интерфейс enp5s0f0 с адресом 192.168.1.1 будет доступен из внутренней сети, поэтому все установленные на сервере сервисы должны быть по этому интерфейсу доступны. Доступ же по наружному интерфейсу enp5s0f1 должен быть максимально урезан. Для внутренней сети волевым решением выберем зону internal. В неё нужно перекинуть интерфейс enp5s0f0.
Нюанс, однако: есть две таблицы фильтрации — активная в данный момент и постоянная. При перезагрузке сервера активная таблица восстанавливается из постоянной. Поэтому нужно либо стазу работать с постоянной таблицей (параметр --permanent в командах), либо потом не забыть скопировать активную таблицу в постоянную, когда все изменения сделаны. Изменения в активной таблице применяются мгновенно: сохранять или применять изменения не требуется. Изменения же в постоянной таблице вступят в силу только после перезагрузки таблицы (команда firewall-cmd --reload), сервиса (команда systemctl restart firewalld) или сервера.
Я буду сразу править постоянную таблицу. Удаляю интерфейс из зоны public:
[root@supermicro]# firewall-cmd --permanent --zone=public --remove-interface=enp5s0f0 success
Добавляю его в зону internal:
[root@supermicro]# firewall-cmd --permanent --zone=internal --add-interface=enp5s0f0 success
Проверяю результат:
[root@supermicro]# firewall-cmd --get-active-zones internal interfaces: enp5s0f0 public interfaces: enp5s0f1
Вот здесь нас поджидает засада, а именно известный и до сих пор не закрытый баг в Centos 7. Суть: зона интерфейса при перезагрузке берётся из настроек самого интерфейса (файл /etc/sysconfig/network-scripts/ifcfg-enp5s0f0), а вот там она и не изменилась. Это придётся сделать вручную: правим файл /etc/sysconfig/network-scripts/ifcfg-enp5s0f0 и добавляем туда строку ZONE=internal:
[root@supermicro]# cat /etc/sysconfig/network-scripts/ifcfg-enp5s0f0
Выдача команды cat
TYPE=Ethernet DEVICE=enp5s0f0 NAME=ifInternal BOOTPROTO=none NETWORK=192.168.1.0 ONBOOT=yes DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=no IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no UUID=61c21319-6b66-4e4e-adef-4fae7fc3f12b IPV6_PEERDNS=yes IPV6_PEERROUTES=yes IPADDR=192.168.1.1 PREFIX=24 ZONE=internal
После этого чисто для проверки сервер лучше перезагрузить. После перезагрузки привязка интерфейсов к зонам не должна потеряться:
[root@supermicro]# firewall-cmd --get-active-zones internal interfaces: enp5s0f0 public interfaces: enp5s0f1
Сервисы добавляются к зоне командой типа
[root@supermicro]# firewall-cmd --permanent --zone=internal --add-service vnc-server
Я же предпочитаю это делать из графической оболочки:
К сожалению, это ещё не все. Есть нюанс, связанный с маскировкой IP адреса (IP masquerading). В пакетах, исходящих из внутренней сети, адрес отправителя должен быть заменён на адрес самого сервера. Если эта функция выключена, то компьютер из внутренней сети никогда не дождётся ответа снаружи, так как его адрес там неизвестен.
Не знаю, с чем это связано, но изменения флага маскировки для адаптера enp5s0f1 как из графической оболочки, так через firewall-cmd не дали никакого эффекта. Рабочее решение нашлось в этой статье. Его суть: задать дополнительное прямое правило POSTROUTING в таблицу iptables, надстройкой на которой FirewallD является:
[root@supermicro]# firewall-cmd --permanent --direct --passthrough ipv4 -t nat -I POSTROUTING -o enp5s0f1 -j MASQUERADE -s 192.168.1.0/24
Перезагрузим таблицу и проверим изменения:
[root@supermicro] # firewall-cmd --reload [root@supermicro]# firewall-cmd --direct --get-all-passthroughs ipv4 -t nat -I POSTROUTING -o enp5s0f1 -j MASQUERADE -s 192.168.1.0/24
На этом межсетевой экран настроен. Текущую конфигурацию брандмауэра можно проверить такой полезной командой:
[root@supermicro family]# firewall-cmd --list-all-zones
Фрагмент выдачи команды firewall-cmd
internal (active) interfaces: enp5s0f0 sources: services: dns http https ntp samba samba-client ssh vnc-server ports: masquerade: no forward-ports: icmp-blocks: rich rules: public (default, active) interfaces: enp5s0f1 sources: services: ports: masquerade: yes forward-ports: icmp-blocks: rich rules:
Шаг восьмой: Сервер точного времени (NTP).
Для синхронизации времени по сети (как времени самого сервера, так и времени на клиентских машинах с сервером) настрою NTP сервер. В Centos 7 вместо старого доброго ntpd предустановлен и активирован новый сервис — chrony.
Так как во время установки системы была выбрана опция синхронизации времени по сети, то сервис уже есть и запущен:
[root@supermicro]# systemctl status chronyd
Выдача команды systemctl, если сервис работает в штатном режиме
chronyd.service - NTP client/server Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled) Active: active (running) since Fri 2015-10-02 23:01:57 CEST; 12min ago Process: 2949 ExecStartPost=/usr/libexec/chrony-helper add-dhclient-servers (code=exited, status=0/SUCCESS) Process: 2946 ExecStart=/usr/sbin/chronyd -u chrony $OPTIONS (code=exited, status=0/SUCCESS) Main PID: 2948 (chronyd) CGroup: /system.slice/chronyd.service └─2948 /usr/sbin/chronyd -u chrony Oct 02 23:01:57 supermicro chronyd[2948]: chronyd version 1.29.1 starting Oct 02 23:01:57 supermicro chronyd[2948]: Linux kernel major=3 minor=10 patch=0 Oct 02 23:01:57 supermicro chronyd[2948]: hz=100 shift_hz=7 freq_scale=1.00000000 nominal_tick=10000 slew_delta_tick=833 max_tick_bias=1000 shift_pll=2 Oct 02 23:01:57 supermicro chronyd[2948]: Frequency -6.239 +/- 1.721 ppm read from /var/lib/chrony/drift Oct 02 23:01:57 supermicro systemd[1]: Started NTP client/server. Oct 02 23:02:02 supermicro chronyd[2948]: Selected source 129.70.132.32
Если же команда статуса показывает, что сервис либо не установлен, либо не запущен, то процедура стандартная:
[root@supermicro]# yum install chrony [root@supermicro]# systemctl start chronyd [root@supermicro]# systemctl enable chronyd [root@supermicro]# systemctl is-enabled chronyd enabled
Автоматическая синхронизация времени с удалённым сервером разрешается командой:
[root@supermicro]# timedatectl set-ntp yes
Для доступа к сервису из внутренней сети нужно разрешить сервис в брандмауэре:
[root@supermicro]# firewall-cmd --permanent --zone=internal --add-service ntp [root@supermicro]# firewall-cmd --reload
После чего можно подправить настройки сервиса, которые хранятся в файле /etc/chrony.conf. В этом файле мне было достаточно сделать только две корректировки:
# Add custom pool servers instead those defined in the installation: server 0.de.pool.ntp.org iburst server 1.de.pool.ntp.org iburst server 2.de.pool.ntp.org iburst server 3.de.pool.ntp.org iburst # Allow NTP client access from local network. allow 192.168.1.0/24
Перезапустим сервис:
[root@supermicro]# systemctl restart chronyd
Проверим состояние и синхронизацию:
[root@supermicro]# chronyc sources
Выдача команды chronyc sources
210 Number of sources = 4 MS Name/IP address Stratum Poll Reach LastRx Last sample ^+ mizar.pmsf.net 2 8 377 479 +688us[ +729us] +/- 54ms ^* stratum2-3.NTP.TechFak.Un 2 8 377 217 -1261us[-1241us] +/- 26ms ^+ dns2.teleport-iabg.de 2 9 377 87 +1102us[+1102us] +/- 86ms ^+ server2.as2.ch 2 8 377 218 +631us[ +651us] +/- 56ms
[root@supermicro]# chronyc tracking
Выдача команды chronyc tracking
Reference ID : 129.70.132.32 (stratum2-3.NTP.TechFak.Uni-Bielefeld.DE) Stratum : 3 Ref time (UTC) : Fri Oct 2 21:29:03 2015 System time : 0.000020543 seconds slow of NTP time Last offset : 0.000020316 seconds RMS offset : 0.001376700 seconds Frequency : 5.580 ppm slow Residual freq : 0.011 ppm Skew : 0.203 ppm Root delay : 0.045198 seconds Root dispersion : 0.003463 seconds Update interval : 261.1 seconds Leap status : Normal
После замены адреса NTP сервера на клиентских устройствах (Windows, Linux, Zyxel) все они дружно подхватили время с сервера.
Шаг предпоследний: служба DNS.
Единственная цель, с которой я решил поднять службу DNS на сервере — блокировка баннерных сетей, сайтов статистики и всевозможных серверов телеметрии (например, Microsoft) на всех устройствах в локальной сети. Идея не моя, взята отсюда. Поискав в паутине, нашёл несколько сайтов, которые на регулярной основе публикуют чёрные списки доменов в формате hosts-файлов.
Например это и это. Особенностью второго списка является то, что сервера телеметрии Microsoft там уже есть.
В качестве службы DNS я выбрал dnsmasq просто потому, что нашёл простою и понятную инструкцию по его установке и настройке. Dnsmasq реализует одновременно как DNS, так и DHCP сервер, но второй мне пока без надобности, поэтому я буду конфигурировать только DNS.
Начало стандартное:
[root@supermicro]# yum install dnsmasq dnsmasq-utils [root@supermicro]# systemctl start dnsmasq [root@supermicro]# systemctl enable dnsmasq [root@supermicro]# firewall-cmd --permanent --zone=internal --add-service=dns [root@supermicro]# firewall-cmd --reload
Далее в конфигурационном файле внутреннего сетевого интерфейса (в моём случае /etc/sysconfig/network-scripts/ifcfg-enp5s0f0) нужно указать, что DNS сервером является локальный хост, т.е. добавить строку:
DNS1=127.0.0.1
[root@supermicro]# cat /etc/sysconfig/network-scripts/ifcfg-enp5s0f0
Выдача команды cat
TYPE=Ethernet DEVICE=enp5s0f0 NAME=ifInternal BOOTPROTO=none NETWORK=192.168.1.0 ONBOOT=yes DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=no IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no UUID=61c21319-6b66-4e4e-adef-4fae7fc3f12b IPV6_PEERDNS=yes IPV6_PEERROUTES=yes IPADDR=192.168.1.1 PREFIX=24 ZONE=internal DNS1=127.0.0.1
После включения или перезагрузки сервера служба NetworkManager на основе настроек из этого файла обновляет файл /etc/resolv.conf, который содержит адреса как внешнего DNS сервера (в моём случае это DSL/FritzBox), так и нашего:
[root@supermicro]# cat /etc/resolv.conf # Generated by NetworkManager nameserver 192.168.178.1 nameserver 127.0.0.1
Скачав отсюда исходники установленной версии, можно выдернуть оттуда пример конфигурационного файла, подправить его и сохранить как /etc/dnsmasq.d/main.conf. Я его сконфигурировал по-минимому:
Фрагмент (активные параметры) файла /etc/dnsmasq.d/main.conf
bogus-priv server=/kama/192.168.1.1 local=/kama/ interface=enp5s0f0 no-dhcp-interface=enp5s0f0 addn-hosts=/etc/black_list_hosts.txt expand-hosts domain=kama
Главное здесть — параметр addn-hosts=/etc/black_list_hosts.txt, где black_list_hosts.txt — это и есть чёрный список доменов. В моём случае, я пока просто скачал его отсюда. Как результат — баннерной рекламы на всех устройствах локальной сети (как настольных, так и мобильных) практически не стало. В будущем я собираюсь автоматизировать процесс обновления этого списка.
Последний шаг: файловый сервер (Samba).
Это последняя компонента, о которой я немного напишу. Samba — файловый сервер для совместного доступа к файлам со всех устройств локальной сети. Устанавливается он просто:
yum install samba* -y
Я выдам в совместный доступ только одну папку: /work/nas. Для этого нужно отредактировать файл /etc/samba/smb.conf и указать там параметры доступа к этой папке:
Фрагмент (активные параметры) файла /etc/samba/smb.conf
workgroup = KAMA server string = Samba Server Version %v netbios name = SUPERMICRO interfaces = lo enp5s0f0 hosts allow = 127. 192.168.1. max protocol = SMB2 log file = /var/log/samba/log.%m max log size = 50 [nas] comment = NAS Working directory path = /work/nas public = no read only = yes printable = no write list = family create mode = 660 directory mode = 770
По умолчанию папка сконфигурирована «только для чтения», но пользователь с именем family имеет доступ на запись. Запускаем сервис и проверяем его настройки:
[root@supermicro]# systemctl start smb [root@supermicro]# systemctl enable smb [root@supermicro]# firewall-cmd --permanent --zone=internal --add-service=samba [root@supermicro]# firewall-cmd --reload [root@supermicro]# testparm
Выдача команды testparm
Load smb config files from /etc/samba/smb.conf rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384) Processing section "[nas]" Loaded services file OK. Server role: ROLE_STANDALONE [global] workgroup = KAMA server string = Samba Server Version %v interfaces = lo, enp5s0f0 log file = /var/log/samba/log.%m max log size = 50 server max protocol = SMB2 idmap config * : backend = tdb hosts allow = 127., 192.168.1. cups options = raw [nas] comment = NAS Working directory path = /work/nas write list = family create mask = 0660 directory mask = 0770
Далее нужно создать папку и обеспечить доступ к ней. Доступ получит группа пользователей fileshare:
[root@supermicro]# cd /work/ [root@supermicro]# mkdir nas [root@supermicro]# groupadd -g 10000 fileshare [root@supermicro]# chgrp fileshare /work/nas [root@supermicro]# chmod g+w /work/nas
Далее есть особенность. Дело в том, что в Centos установлена дополнительная подсистема безопасности, которая регулирует доступ к ресурсам не только для пользователей, но и для модулей (компонентов) системы. Она называется SELinux. Чтобы сервер Samba сам мог долучить доступ к папке /work/nas, у неё должен быть задан дополнительный аттрибут samba_share_t помимо обычных прав чтения-записи:
[root@supermicro]# ls -Z drwxrwxr-x. family fileshare unconfined_u:object_r:samba_share_t:s0 nas drwxr-xr-x. apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0 svn drwxr-xr-x. apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0 www
Для манипуляции флагами есть стандартная команда chcon. Флаг samba_share_t с её помощью устанавливается так:
[root@supermicro]# chcon -t samba_share_t /work/nas
Для того чтобы Windows-машины в локальной сети видели наш сервер и общую папку, необходимо также разрешить сервис NetBIOS. Он не требует дополнительной конфигурации, его нужно только запустить:
[root@supermicro]# systemctl start nmb [root@supermicro]# systemctl enable nmb
Часто бывает нужно подмонтировать к этой папке внешний накопитель (диск или флешку), отформатированные под NTFS. Драйвера NTFS в системе по умолчанию нет. Также его нет и в стандартных репозиториях. Если есть потребность подключать диски с NTFS к системе, то нужно установить 3rd-party репозиторий EPEL из проекта Федоры и уже оттуда установить драйвер:
[root@supermicro]# yum install epel-release [root@supermicro]# yum install ntfs-3g
После чего внешние диски диски NTFS будут автоматически опознаваться системой.
Финальный аккорд — создать пользователя, который будет иметь права записи в общую папку. Как видно из конфигурации выше, это пользователь family:
[root@supermicro]# usermod -a -G fileshare family [root@supermicro]# id family uid=1000(family) gid=1000(family) groups=1000(family),10000(fileshare) [root@supermicro]# smbpasswd -a family New SMB password: Retype new SMB password: Added user family.
На этом, пожалуй, завершусь. В целом, получилась экономичная и многофункциональная машинка с большим потенциалом. Как я уже отмечал, потребляемая мощность находится в пределах 14-15 ватт, что вполне приемлемо для домашнего аппарата, который постоянно включён. Первый месяц своей жизни он отработал без единой проблемы.
Если у возникли вопросы, замечания, или идеи по улучшению и дальнейшему развитию, то буду рад комментариям. Спасибо!