Pull to refresh

Домашний сервер на платформе Intel Atom и ОС Centos 7

Reading time 20 min
Views 62K
В своей статье я хочу представить уважаемому хаброобществу практическое руководство по сборке, настройке и вводу в эксплуатацию недорогого и экономичного сервера на платформе Intel Atom и ОС Centos 7. Сей труд не претендует на полноценный и исчерпывающий учебник и рассчитан, скорее, на начинающих, чем на профессионалов. Если человек, до этого в глаза линукс не видевший, сможет при помощи этой статьи сконфигурировать свой первый сервер, я буду считать свою задачу выполненной.

Первая часть статьи (небольшая по объёму) посвящена аппаратной составляющей, а вторая, основная часть — подробному описанию процесса настройки на этой аппаратуре системы 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». Исследование форумов показало, что я не один такой криворукий. Поэтому флешку я в результате подготовил из под линукса:
  1. вставляем пустую флешку объема большего, чем файл ISO. Тип файловой системы на ней не важен. главное, она не должна быть разбита на тома.
  2. смотрим, как она смонтирована и какому устройству соответствует:
    # cat /proc/mounts
  3. размонтируем это устройство, иначе в требуемом нам режиме оно будет недоступно:
    # umount /dev/NNN
  4. переходим в режим root и переходим в каталог, где сохранен файл ISO.
  5. используем стандартную утилиту блочного копирования данных:
    # 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 ватт, что вполне приемлемо для домашнего аппарата, который постоянно включён. Первый месяц своей жизни он отработал без единой проблемы.


Если у возникли вопросы, замечания, или идеи по улучшению и дальнейшему развитию, то буду рад комментариям. Спасибо!
Tags:
Hubs:
+8
Comments 38
Comments Comments 38

Articles