Ранее я уже неоднократно рассматривал вопрос резервного копирования данных или целых серверов linux. Конкретно в этих статьях:

• Бэкап сервера с помощью Duplicity.
• Создание резервной копии на Яндекс.Диске.
• Настройка Rsync для бэкапа данных.

Забэкапить сразу весь сервер можно, например, с помощью Duplicity. Но вот восстановить его на другом железе будет не так просто. Помимо данных нужно будет, как минимум, позаботиться о разметке диска, установке загрузчика. На это необходимо затратить некоторые усилия и немного разбираться в теме initramfs и grub. Сам я не очень разбираюсь в нюансах работы этих инструментов и очень не люблю с ними возиться.

Некоторое время назад появился отличный бесплатный продукт для бэкапа всего сервера целиком. Речь идет о Veeam Agent for Linux FREE. С его помощью можно сделать полный backup сервера, положить его куда-нибудь по smb или nfs, потом загрузиться с live cd и восстановить из бэкапа на другом железе.

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

1. Бэкап можно сделать либо всего сервера сразу, либо отдельного диска, либо отдельных папок и файлов. При выборе бэкапа всего диска или сервера, нельзя задать исключения для отдельных папок или файлов. Это очень неудобно, но увы и ах, таков функционал. Исключения можно сделать только если вы делаете бэкап на уровне папок.
2. Бэкап можно положить локально на соседний раздел, если делаете резервную копию раздела, локально в папку — если делаете бэкап файлов и папок. Если бэкапите всю систему целиком, то удаленно по smb и nfs. К сожалению, по ftp или sftp программа не работает.

В качестве хранилища для архивов может выступать репозиторий Veeam Backup & Replication. Но я не рассматриваю этот вариант, так как в данном случае использую только бесплатное решение.

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

Думаю вы уже поняли, в чем проблема сделать полный backup сервера с помощью Veeam Agent for Linux на Яндекс.Диск по webdav. Вы не сможете добавить в исключения папку с кэшом от webdav. В итоге, во время бэкапа с помощью veeam будет расти папка с кэшом webdav, которая, в свою очередь, будет бэкапиться. В итоге, свободное место на диске закончится, бэкап прервется.

Я подробно описал ситуацию с Яндекс.Диском, потому что пространство на нем не дорого стоит. Я часто его использую в повседневной жизни, настраиваю бэкапы, храню данные и т.д. В общем, мне он нравится по ряду причин. Для того, чтобы бэкапить весь сервер целиком, вам придется найти место для архивных копий с доступом по smb или nfs. Таких предложений не очень много на рынке. Практически не из чего выбирать, я специально искал.

Остановился вот на этом варианте — KeyDisk. После оплаты, вам дают адрес сервера, логин и пароль. Вы можете сразу же подключаться по smb к хранилищу. Можно прям в windows через два обратных слеша зайти или подмонтировать хранилище к linux серверу.

KeyDisk стоит примерно 350р. в месяц за 100 гигов. Не очень дешево, конечно, в сравнении с облачными сервисами, но все равно не дорого. Похожих предложений с доступом по smb я лично вообще не нашел в принципе. Этот объем позволит вам забэкапить небольшой веб сервер с глубиной архива в несколько недель или месяцев, в зависимости от того, сколько данных у вас на нем хранится.

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

Установка Veeam Agent for Linux

Для установки Veeam Agent for Linux необходимо подключить репозиторий veeam под нужную вам систему. Это можно сделать либо руками, либо скачать файл с репозиторием в виде rpm или deb пакета. Сделать это можно на странице с описанием продукта.

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

Чуть ниже рекомендую сразу же скачать Veeam Linux Recovery Media. Он нам понадобится, когда мы будем переносить сервер на другое железо или восстанавливать из бэкапа.

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

# cd /root
# wget https://download2.veeam.com/veeam-release-el7-1.0-1.x86_64.rpm
# rpm -Uhv veeam-release-el7-1.0-1.x86_64.rpm

Обновляем репозитории и устанавливаем veeam.

# yum update
# yum install veeam

Все, Veeam Agent for Linux установлен и готов к работе.

Настройка полного бэкапа сервера

Сделать бэкап с помощью Veeam Agent for Linux очень просто. Вариантов настроек не так много, можете сами все проверить и посмотреть. Я для примера рассмотрю вариант с созданием полного бэкапа всей системы и перенос ее на другое железо. Создаем задачу для резервного копирования сервера на наше хранилище по smb.

# veeam

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

Нажимаем C (configure) для настройки задания на backup. Задаем любое имя задания, затем указываем, что будем делать полный бэкап сервера.

В качестве приемника для архива системы, указываем Shared Folder.

Далее нужно ввести параметры доступа к хранилищу бэкапов. Я использую свои от системы KeyDisk.

В пункте Restore Points указывается глубина архива. Это число копий, которые будут храниться на сервере. Если делать бэкап каждый день и указать число 14, то будут храниться резервные копии системы за последние 14 дней. Если делать будете через день, то за 28 дней и т.д.

Можно создавать несколько заданий с различной глубиной архива. Например, каждый день с глубиной 7 копий, раз в неделю с глубиной 4, и раз в месяц с глубиной в 12. Таким образом у вас всегда будут последние 7 бэкапов системы на этой неделе. Потом по одному бэкапу в неделю за последний месяц и 12 бэкапов по месяцам в течении последнего года.

Если получите ошибку:

Current system does not support cifs. Please install cifs client package.

Установите пакет cifs. В CentOS вот так:

# yum install cifs-utils

И так в Debian/Ubuntu:

# apt install cifs-utils

Запускайте заново veeam и продолжайте. После настройки Destination, предлагается указать скрипты для выполнения перед и после бэкапа. Нам сейчас это не надо. Далее настраиваем расписание и запускаем задание на архивацию в конце настройки.

Запустилась архивация. Можно следить за ее прогрессом.

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

На этом настройку полного бэкапа сервера мы завершили. Резервная копия системы лежит в надежном месте. Попробуем теперь с нее восстановиться.

Перенос или восстановление linux сервера

Представим теперь ситуацию, что наш веб, или какой-нибудь другой сервер умер, и нам надо восстановить систему в другом месте. Выполним полное восстановление всего сервера с помощью созданной ранее резервной копии. Для этого нам понадобится Veeam Linux Recovery Media, который мы скачали ранее.

Для восстановления системы нужно соблюсти два обязательных условия:

1. Готовим новый сервер с диском, который должен быть не меньше диска исходного сервера. Это обязательное условие, иначе восстановление системы даже не начнется. Veeam скажет, что размер диска недостаточный и не предложит больше никаких вариантов восстановления.
2. Оперативной памяти для системы должно быть не меньше 1024 Мб. Если меньше, то загрузка с диска не будет выполнена. Система скажет, что она не может развернуть корневой раздел.

Загружаемся с диска. В разделе Configure network убеждаемся, что сеть настроена, получен ip адрес, который имеет доступ к интернету. Далее выбираем Restore volumes -> Add shared folder. Заполняем параметры доступа к хранилищу архивов.

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

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

У меня слева чистый диск, справа тоже один диск, на который установлен загрузчик и есть один раздел с корнем системы. Выбираем справа наш диск (не раздел с корнем!!!) и жмем Restore whole disk to.

В качестве приемника выбираем пустой диск на новом сервере.

Нажимаем S ( Start restore ). Визард покажет список действий, которые будут выполнены и попросит их подтвердить, нажатием на Enter.

Делаем это и наблюдаем за процессом восстановления сервера centos из бэкапа.

Дожидаемся окончания переноса сервера, выбираем перезагрузку и извлекаем загрузочный CD. Грузимся с жесткого диска.

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

Перенос виртуальной машины с KVM на Hyper-V

В моем случае я переношу сервер с KVM на Hyper-V. После загрузки системы я получаю такую картину.

Сервер начинает бесконечно висеть в подобном состоянии с такими характерными ошибками:

Warning: dracut-initqueue timeout starting timeout scripts

a start job is running for dev-disk-by ......

Начинаю разбираться в чем может быть дело. Конечно, тут решение проблемы будет зависеть от конкретной ситуации. А успешность решения от квалификации сисадмина. Я уже немного повозился с подобными переносами и примерно представляю, в чем тут может быть проблема. Частично я эту тему затрагивал, когда делал перенос виртуальных машин с XenServer на Hyper-V. Но там была другая проблема, связанная с кастомным ядром от Xen.

В нашей ситуации с переносом виртуальной машины с KVM на Hyper-V проблема в другом. У нас поменялось имя диска. Нам нужно изменить это имя в fstab и в конфиге grub. До кучи я еще собрал заново initramfs, но не уверен на 100%, что в данном случае это нужно было делать. Я сделал на всякий случай сразу все за один заход.

Итак, загружаемся с установочного диска CentOS 7 и выбираем режим Rescue a CentOS system. Подробно об этом рассказывал в упомянутой ранее статье с переносом от xen. Выбираем первый режим запуска.

Дальше работаем в консоли. Смотрим, как называется наш диск.

# fdisk -l

У меня это sda, а на прошлом сервере он назывался vda. Нам нужно внести эти изменения в 2 файла:

1. /etc/fstab
2. /boot/grub2/grub.cfg

Диск восстановления в самом начале мог сам смонтировать системный раздел в директорию/mnt/sysimage. Если он этого не сделает по какой-то причине, то сделайте это сами:

# mount /dev/sda1 /mnt/sysimage

Теперь нам надо сделать chroot в систему, предварительно смонтировав туда информацию о текущей системе. Выполняем команды:

# mount --bind /proc /mnt/sysimage/proc
# mount --bind /dev /mnt/sysimage/dev 
# mount --bind /sys /mnt/sysimage/sys 
# mount --bind /run /mnt/sysimage/run 
# chroot /mnt/sysimage

Мы загрузились в окружение нашего сервера. Тут можете использовать установленный у вас на сервере текстовый редактор. С его помощью изменяете имена дисков в файлах /etc/fstab и /boot/grub2/grub.cfg. Можете просто автозаменой поменять имена.

Теперь соберем новый initramfs. Идем в директорию /boot и смотрим там последнюю версию ядра.

# cd /boot
# ls -l | grep initramfs

В данном случае просто смотрим самые высокие цифры. Соберем новый initramfs в соответствии с версией ядра.

# dracut initramfs-3.10.0-514.26.2.el7.x86_64.img 3.10.0-514.26.2.el7.x86_64

В завершении установим измененный загрузчик на наш диск:

# grub2-install /dev/sda

Перезагружаем сервер. После этих изменений, у меня благополучно все загрузилось. Перенос виртуальной машины с KVM на Hyper-V выполнен полностью. Причем, у нас не было доступа к образу системы. Хотя подобная ошибка скорее всего все равно возникла бы, даже если бы мы конвертировали и переносили готовый образ.

Заключение

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

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

1. Неподходящие версии ядер. После переноса нужно будет переустановить или обновить ядро.
2. Разные имена дисков или меток разделов. Нужно будет их привести в соответствие с новым железом.

Это наиболее популярные проблемы. С другими мне не приходилось сталкиваться. Хотя не сказать, что мне часто приходилось переносить сервера, но некоторый опыт есть. Думаю, эта статья будем многим полезна, так как подобный перенос не очень раскрыт в статьях в интернете. По крайней мере мне не попадались хорошие гайды на эту тему. Разбираюсь обычно сам с помощью гугления по англоязычному сегменту.

Сообщение Бэкап и перенос linux (centos, debian, ubuntu) сервера с помощью Veeam Agent for Linux появились сначала на Clip-Clap.

Я буду работать со следующим сервером:

# uname -a
Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) x86_64 GNU/Linux
# cat /etc/debian_version
8.3

Если у вас еще нет готового сервера, то рекомендую статью на тему установки debian. Там подробно описан весь процесс от и до.

На сервере имеются 2 сетевых интерфейса:

Файл конфигурации сетевых интерфейсов выглядит следующим образом:

# cat /etc/network/interfaces

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet dhcp

allow-hotplug eth1
iface eth1 inet static
address 10.0.15.1
netmask 255.255.255.0

Как настроить сеть в debian я подробно рассказал отдельно. Если вы еще не сделали это и не выполнили предварительную настройку debian, то рекомендую ознакомиться с материалами.

Если у вас недостаточно опыта и вы не чувствуете в себе сил разобраться с настройкой шлюза самому с помощью консоли сервера — попробуйте дистрибутив на основе centos для организации шлюза и прокси сервера в локальной сети — clearos. С его помощью можно через браузер настроить весь необходимый функционал. В отдельной статье я подробно рассказал об установке clearos.

Подготовка шлюза

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

Сеть на будущем программном роутере настроили, доступ в интернет на сервере есть. Обновим его:

# apt-get update
# apt-get upgrade

Установим MC, мне в нем удобнее всего работать, в том числе в редакторе mcedit:

# apt-get -y install mc

Настроим часовой пояс, если раньше не сделали это:

# dpkg-reconfigure tzdata

Устанавливаем сервис ntp для автоматического обновления времени:

# apt-get -y install ntp

На этом основные подготовительные действия закончены. Приступаем к настройке шлюза.

Настройка маршрутизации, firewall и nat

Первым делом включим маршрутизацию пакетов между сетевыми интерфейсами. Для этого редактируем конфиг /etc/sysctl.conf:

# mcedit /etc/sysctl.conf

net.ipv4.ip_forward=1

Либо раскомментируйте эту строку, либо добавьте, если ее нет. Но она по-умолчанию быть должна, закомментированная со значением 1. Применяем эту настройку:

# sysctl -p

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

Теперь приступаем к самому главному — настройке фаервола iptables и nat в нем для обеспечения выхода в интернет из локальной сети. Я очень подробно рассмотрел эту тему в отдельной статье. Хотя там речь идет о другом дистрибутиве, сами правила iptables абсолютно одинаковые с точностью до строчки, за исключением маленького нюанса, связанного с тем, что правила нужно сохранять в другой файл для применения их после перезагрузки.

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

Копируем содержимое файла и создаем скрипт с правилами на сервере:

# mcedit /etc/iptables.sh

Вставляем в редактор правила. Редактируем их под свои нужды, обязательно заменяя переменные WAN и LAN на свои. Сохраняем файл.Прежде чем двигаться дальше предупреждаю, что все работы по настройке фаервола должны производиться только если у вас есть доступ к консоли сервера, чтобы в случае ошибки и потери удаленного доступа вы смогли откатить изменения. Даже если вы абсолютно уверены в своих знаниях, вас может подвести банальная ошибка или опечатка. Я сам, к сожалению, сталкивался с такими ситуациями, поэтому считаю необходимым предупредить об этом вас.

Делаем файл с правилами исполняемым:

# chmod 0740 /etc/iptables.sh

Прежде чем применить новые правила, посмотрим на текущие:

# iptables -L -v -n

Видим, что на настраиваемом роутере firewall полностью открыт. Теперь применим новые правила и посмотрим на результат:

# /etc/iptables.sh

Все в порядке, правила применились, доступ к серверу я не потерял. Теперь сделаем так, чтобы новые правила применялись после перезагрузки. В последней строчке скрипта есть команда:

/sbin/iptables-save  > /etc/iptables.rules

С ее помощью готовый набор правил iptables выгружаются в файл. Нам нужно сделать так, чтобы эти правила применялись при включении сетевого интерфейса во время загрузки сервера. Для этого открываем файл interfaces на редактирование и добавляем в самый конец строчку:

# mcedit /etc/network/interfaces

post-up iptables-restore < /etc/iptables.rules

Для проверки перезагружаем шлюз и проверяем, все ли в порядке. По сути основная настройка программного роутера на debian завершена. Осталось сделать небольшое дополнение и настроить dhcp и dns сервер в локальной сети. Я для этих целей использую простой и легкий в настройке dnsmasq.

Установка и настройка dnsmasq в Debian

Выполним установку dnsmasq на дебиан:

# apt-get install -y dnsmasq

Сделаем минимальную настройку программы. Нам нужно просто выдавать сетевые настройки пользователям. Для этого приводим конфигурационный файл dnsmasq к следующему виду:

# mcedit /etc/dnsmasq.conf

domain-needed
bogus-priv
interface=eth1
dhcp-range=eth1,10.0.15.50,10.0.15.150,24h

В данном случае мы будем выдавать пользователям ip адреса в диапазоне от 10.0.15.50 до 150. Сохраняем конфиг, добавляем программу в автозагрузку и запускаем.

# insserv dnsmasq
# /etc/init.d/dnsmasq start

Теперь можно запускать компьютер пользователя локальной сети, получать сетевые настройки по dhcp и проверять работу интернет шлюза.

Посмотреть выданные leases можно в файле /var/lib/misc/dnsmasq.leases. На этом настройка интернет шлюза на debian 8 закончена. Все что нужно для обеспечения доступа в интернет из локальной сети сделано. Получился программный роутер с широкими возможностями по наращиванию функционала.

Просмотр загрузки сети с помощью iftop

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

Устанавливаем iftop на debian:

# apt-get install -y iftop

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

# iftop -i eth1

Чтобы увидеть порты, по которым идет трафик, добавляем ключ -P:

# iftop -i eth1 -P

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

Заключение

Вот так легко и быстро можно настроить роутер, маршрутизатор или шлюз в интернет. Названия разные, а суть одна. В данном случае я использовал операционную систему Debian, но схожий функционал легко организовать на Freebsd или CentOS. Для решения текущей задачи разница в работе не будет заметна. Каждый выбирает то, что больше нравится и к чему привык.

Пройдемся быстренько по этапам того, что сделали:

1. Подготовили сервер Debian к настройке шлюза.
2. Настроили маршрутизацию, iptables, нат. Проверили, что весь функционал восстанавливается после перезагрузки.
3. Установили и настроили простой dhcp сервер и кэширующий dns сервер — dnsmasq. С его помощью автоматизировали поучение сетевых настроек пользователями.
4. Установили простое средство мониторинга сетевой активности в консоли в режиме реального времени с помощью утилиты iftop.

Сообщение Пошаговая настройка роутера на Debian появились сначала на Clip-Clap.

Сама по себе настройка pptp сервера на Debian очень проста не представляет никакой сложности. Все настраивается за 10 минут. Проблема здесь в другом. По-умолчанию, windows при подключении по pptp использует удаленный vpn сервер в качестве шлюза по умолчанию. За это отвечает галка в настройках vpn соединения «Использовать основной шлюз в удаленной сети». При такой конфигурации весь трафик компьютера пользователя идет через vpn сервер. Это очень неудобно, да и не нужно. Эту настройку обычно отключают.

Когда ее отключаешь, pptp клиент ничего не знает о маршрутах в удаленный офис. Чтобы туда попасть, маршруты нужно прописывать вручную, например так:

route add 192.168.0.0 mask 255.255.255.0 192.168.10.1

Этот маршрут нужно либо в командной строке прописывать, либо bat файл сделать и запускать. И то и другое неудобно, так как пользователю нужно выполнять дополнительные действия. В openvpn этот вопрос решается очень просто. Там можно на уровне сервера задать любые настройки пользователя, в том числе и маршруты. Они будут передаваться после подключения openvpn клиента. В pptp так сделать нельзя, он это не умеет. Вместо него передать маршруты может dhcp сервер, его для этого нужно специальным образом настроить. Этим мы и займемся.

Установка pptp сервера

Подразумеваю, что у вас установлен и настроен сервер.

Сначала установим pptp сервер:

# apt-get install pptpd

Рисуем следующий конфиг /etc/pptpd.conf:

# mcedit /etc/pptpd.conf

option /etc/ppp/pptpd-options
logwtmp
bcrelay eth1:1
localip 192.168.10.1
remoteip 192.168.10.30-50

Редактируем файл с дополнительными параметрами /etc/ppp/options:

# mcedit /etc/ppp/options

ms-dns 77.88.8.1
ms-dns 8.8.4.4
require-mschap-v2
asyncmap 0
auth
crtscts
lock
hide-password
modem
debug
name l2tpd
proxyarp
lcp-echo-interval 10
lcp-echo-failure 100
noipx
nodefaultroute

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

Дальше создаем учетки для подключения в файле /etc/ppp/chap-secrets:

# mcedit /etc/ppp/chap-secrets

user-01 pptpd passw51 192.168.10.41
user-02 pptpd passw88 192.168.10.42
user-03 pptpd passw59 192.168.10.43
user-04 pptpd passw27 192.168.10.44

Первый столбец — имя пользователя, второй — тип сервера, он всегда один и тот же, третий — пароль, четвертый — ip адрес в vpn сети, который будет назначен клиенту. Если его явно не указать, то ему будет назначен первый свободный из диапазона remoteip в pptpd.conf.

На этом настройка непосредственно pptp сервера закончена. Им можно пользоваться, но маршруты пользователям передаваться не будут.

Настраиваем dhcp сервер для раздачи маршрутов

У меня на сервере уже был настроен isc-dhcp-server, поэтому я использовал именно его. Но можно воспользоваться и dnsmasq. Я приведу пример с dhcpd. Если у вас его еще нет, то устанавливайте командой:

# apt-get install isc-dhcp-server

Рисуем следующий конфиг /etc/dhcp/dhcpd.conf:

# mcedit /etc/dhcp/dhcpd.conf

deny unknown-clients;
ddns-update-style none;

option domain-name "office";
option domain-name-servers 77.88.8.8, 8.8.4.4;
default-lease-time 604800;
max-lease-time 864001;

log-facility local7;

local-address 192.168.0.1;
subnet 192.168.0.0 netmask 255.255.255.0 {
        option routers 192.168.0.1;
        authoritative;
        allow unknown-clients;
        option netbios-name-servers 192.168.0.1;
        option domain-name-servers 77.88.8.8, 8.8.4.4;
        option domain-name "debian.office";
        option broadcast-address 192.168.0.255;
        range 192.168.0.150 192.168.0.199;
        }

option ms-classless-static-routes code 249 = array of unsigned integer 8;
option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;

subnet 192.168.10.0 netmask 255.255.255.0 {
        option dhcp-server-identifier 192.168.10.1;
        authoritative;
        range 192.168.10.51 192.168.10.99;
        option ms-classless-static-routes 24, 192,168,0, 192, 168, 10, 1;
        option rfc3442-classless-static-routes 24, 192,168,0, 192, 168, 10, 1;
        option routers 192.168.10.1;
        }

Я тут не разбирался, что и зачем настроено именно так. Сервер настраивал не я, он мне достался в наследство. Мне нужно было только грамотно настроить pptpd с раздачей маршрутов. Поэтому я не расписываю все от и до, а просто делюсь рабочим конфигом, который сейчас у меня работает.

Подсеть 192.168.10.0 и 2 строчки с options перед ней это то, что я добавил для раздачи маршрутов pptp клиентам в vpn подсеть.

Теперь создадим виртуальный интерфейс, добавив в самый конец конфигурационного файла сети:

# mcedit /etc/network/interfaces

auto eth1:1
iface eth1:1 inet static
address 192.168.10.1
netmask 255.255.255.0

О настройке 2-х ip адресов на одном интерфейсе можно подробно прочитать в статье — настройка сети в debian. В моем случае eth1 это интерфейс, который смотрит в локальную сеть, доступ к которой мы организуем с помощью vpn.

[sc5]

Перезапускаем сеть для применения настроек:

# service networking restart

По сути все готово. Запускаем pptpd и dhcpd и проверяем.

# service isc-dhcp-server restart
# service pptpd restart

У меня почему-то команда pptpd restart отрабатывает с ошибкой и не перезапускает демон. Приходится запускать вручную:

# service pptpd start

Проверяем работу клиента windows. Список маршрутов до vpn подключения:

После:

Вот пример такой же конфигурации для dnsmasq:

listen-address=192.168.10.1
dhcp-range=vpn,192.168.10.50,192.168.10.99,255.255.255.0,1h
dhcp-option=tag:vpn,vendor:MSFT,2,1i
dhcp-option=tag:vpn,249,192.168.0.0/24,192.168.10.1
dhcp-option=tag:vpn,121,192.168.0.0/24,192.168.10.1

[sc6]

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

Заключение

Немного сложно реализуется функционал, который доступен в openvpn из коробки без дополнительных настроек. Я поэтому и не очень люблю с pptp возиться, после openvp он мне кажется не таким удобным. Но иногда приходится и его настраивать. К примеру, микротики, к сожалению, так и не научились работать с openvpn по udp, приходится использовать pptp. Да и встроенный в windows клиент тоже добавляет удобство.

Я немного повозился, поразбирался, прежде чем у меня получилось настроить рабочий вариант. Ключевым моментом оказался виртуальный интерфейс eth1:1, который я создал для pptp подсети. Без него у меня не работала передача маршрута.

Сообщение Настройка pptp сервера на Debian появились сначала на Clip-Clap.

Установка rsync на CentOS 6

Устанавливаем xinetd для автоматического запуска rsync:

# yum install -y xinetd

Устанавливаем непосредственно rsync:

# yum install -y rsync

Редактируем конфиг rsync для xinetd:

# mcedit /etc/xinetd.d/rsync

В конфиге находим строку disable = yesи меняем на no:

disable = no

Запускаем xinetd:

# /etc/init.d/xinetd start

И добавляем его в автозапуск:

# chkconfig xinetd on

Проверяем, слушает ли xinetd 873 порт rsync:

# netstat -lnpt | grep 873

tcp 0 0 0.0.0.0:873 0.0.0.0:* LISTEN 1431/xinetd

Все в порядке, можно приступать к настройке rsync.

Установка rsync на CentOS 7

Ставим rsync:

# yum install -y rsync

Добавляем в автозагрузку:

# systemctl enable rsyncd

ln -s '/usr/lib/systemd/system/rsyncd.service' '/etc/systemd/system/multi-user.target.wants/rsyncd.service'

Проверяем автозагрузку:

# systemctl list-unit-files --type service | grep rsyncd

rsyncd.service enabled

Запускаем rsync:

# systemctl start rsyncd

Проверяем, как запустился:

# netstat -tulpn | grep rsync

tcp        0      0 0.0.0.0:873             0.0.0.0:*               LISTEN      2782/rsync

Все в порядке, можно приступать к настройке rsync.

Установка rsync на Debian/Ubuntu

Устанавливаем rsync:

# apt-get install -y rsync

Правим конфиг:

# mcedit /etc/default/rsync

Находим строку RSYNC_ENABLE=falseи меняем на true:

RSYNC_ENABLE=true

Запускаем rsync:

# /etc/init.d/rsync start

[ ok ] Starting rsync daemon: rsync.

Проверяем, что работает:

# netstat -tulpn | grep rsync

tcp 0 0 0.0.0.0:873 0.0.0.0:* LISTEN 1767/rsync

Все в порядке, можно приступать к настройке rsync.

Настройка rsync

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

Получается у нас такая картинка:

Приступаем к реализации. В первую очередь настраиваем rsync на серверах источниках информации, с которых мы будем забирать данные для backup.

Создаем файл конфигурации rsync:

# mcedit /etc/rsyncd.conf

pid file = /var/run/rsyncd.pid
log file = /var/log/rsyncd.log
transfer logging = true
munge symlinks = yes

# папка источник для бэкапа
[data]
path = /data
uid = root
read only = yes
list = yes
comment = Data backup Dir
auth users = backup
secrets file = /etc/rsyncd.scrt

Создаем файл с учетными данными для подключения:

# mcedit /etc/rsyncd.scrt

backup:12345

где backup — имя пользователя, 12345 — пароль.
Делаем права на чтение только root, иначе rsync не запустится:

# chmod 0600 /etc/rsyncd.scrt

После настройки перезапускаем rsync.
На Centos 6:

# /etc/init.d/xinetd restart

На Centos 7:

systemctl restart rsyncd

На Debian/Ubuntu:

# /etc/init.d/rsync restart

Теперь идем на сервер приемник, в котором будут храниться архивные копии с серверов источников. Там создаем скрипт инкрементного бэкапа c использованием rsync:

# mcedit /root/bin/backup-server1.sh

#!/bin/bash
date
# Папка, куда будем складывать архивы
syst_dir=/backup/
# Имя сервера, который архивируем
srv_name=server1
# Адрес сервера, который архивируем
srv_ip=10.10.1.55
# Пользователь rsync на сервере, который архивируем
srv_user=backup
# Ресурс на сервере для бэкапа
srv_dir=data
echo "Start backup ${srv_name}"
# Создаем папку для инкрементных бэкапов
mkdir -p ${syst_dir}${srv_name}/increment/
# Запускаем непосредственно бэкап с параметрами
/usr/bin/rsync -a --delete --password-file=/etc/rsyncd.scrt ${srv_user}@${srv_ip}::${srv_dir} ${syst_dir}${srv_name}/current/ --backup --backup-dir=${syst_dir}${srv_name}/increment/`date +%Y-%m-%d`/
# Чистим папки с инкрементными архивами старше 30-ти дней
/usr/bin/find ${syst_dir}${srv_name}/increment/ -maxdepth 1 -type d -mtime +30 -exec rm -rf {} \;
date
echo "Finish backup ${srv_name}"

Делаем скрипт исполняемым:

# chmod 0744 /root/bin/backup-server1.sh

Создаем файл с паролем для авторизации на сервере источнике:

# mcedit /etc/rsyncd.scrt

12345

Делаем права на чтение только root, иначе rsync выдаст ошибку:
ERROR: password file must not be other-accessible
Исправляем это:

# chmod 0600 /etc/rsyncd.scrt

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

# mcedit /etc/crontab

30 23 * * * root /root/bin/backup-server1.sh

Я обычно создаю несколько скриптов для каждого сервера отдельно. Потом объединяю их запуск в одном общем скрипте и уже его добавляю в cron. А потом по мере необходимости редактирую уже его, добавляю или удаляю сервера.

Ротация логов rsync

Мы указали в настройках ведение лога в файл /var/log/rsyncd.log. Необходимо настроить ротацию этого лога, чтобы он не рос до бесконечности. На больших файловых серверах он очень быстро вырастет до сотен мегабайт и более.

Для этого создаем в папке /etc/logrotate.d файл с конфигурацией ротации:

# mcedit /etc/logrotate.d/rsyncd

/var/log/rsyncd.log {
size=500k
compress
rotate 4
missingok
notifempty
}

С такими настройками ротация будет происходить каждый раз, когда файл лога превысит размер в 500 кб. Храниться будут 4 версии лог файла. Эти настройки вы можете сами поменять по своему усмотрению.

Пример бэкапа windows сервера с помощью rsync

Еще один пример из моей практики. Допустим, у нас есть windows сервер с некоторой информацией, которую мы хотим так же бэкапить. Никаких проблем, это делается достаточно просто.

Создаем на windows сервере сетевую шару с информацией. Создаем пользователя и добавляем его в доступ к этой папке. Этого пользователя мы будем использовать для подключения виндовой шары к linux серверу.

Монтируем шару с информацией, которую будем бэкапить:

# mount -t cifs //192.168.0.16/docs /mnt/docs -o user=backup,password=12345,iocharset=utf8,codepage=cp866

192.168.0.16 — адрес виндовой шары
backup и 12345 — пользователь и пароль виндовой машины с доступом к шаре docs.

Все, теперь папку /mnt/docs можно использовать в качестве приемника в нашем скрипте бэкапа с rsync. Если папка примонтирована непосредственно к серверу с бэкапами, то нужно на нем самом настроить конфиг rsyncd на примере серверов источников, запустить на нем rsyncd и в скрипте в качестве ip адреса сервера указывать 127.0.0.1.

Я в таких случаях создаю несколько скриптов: на монтирование шары, бэкап и размонтирование, объединяю их в один и запускаю последовательно. В итоге получается, что подключаем диск, делаем бэкап и отключаем его.

Сообщение Rsync настройка бэкапа на CentOS/Debian/Ubuntu появились сначала на Clip-Clap.

Некоторое время назад я узнал про систему виртуализации proxmox на базе KVM. Ранее с этим гипервизором я был знаком, но он мне не понравился из-за отсутствия удобных инструментов управления под windows. Это было давно, лет 5 назад. Мне пришлось администрировать уже настроенный гипервизор и мне это не понравилось, слишком много действий приходилось делать в консоли. Не скажу, что мне это прям не нравится, но я не вижу смысла в консоли делать то, что в других гипервизорах мышкой ты делаешь в 5 раз быстрее в gui. Свое время стараюсь экономить и использовать рационально.

Все изменилось, когда я решил посмотреть на Proxmox. Простая установка и удобная панель управления через браузер привлекли сразу. Попробовал, потестировал, вроде все неплохо работает, управление удобное и понятное. Особенно понравились бэкапы из коробки. Не решался использовать в реальной работе, потому что не имею опыта работы c zfs, а ставить гипервизор на одиночные диски плохая идея. Раньше я использовал XenServer, установленный на mdadm raid1, пока он не перестал поддерживать такой режим работы. Proxmox почему-то не поддерживает установку на простой и понятный mdadm, но при этом есть zfs. Этот момент мне искренне не понятен, если учитывать, что proxmox работает на базе системы Debian, которая без проблем устанавливается на программный рейд.

В итоге я решил установить, настроить и протестировать proxmox, установленный на программный raid 1 mdadm. Диски отключал, вынимал, вставлял обратно. Все прекрасно работает. Отказоустойчивость на уровне дисков обеспечена, значит можно использовать в реальной работе. Я и использую последние пару лет. Отдельно упомяну, что меня сразу привлекло в KVM — возможность пробрасывать USB. До сих пор Hyper-V и XenServer не умеют это делать. Первый совсем не умеет, второй вроде как-то пробрасывает, но без гарантий и не все устройства работают. А в KVM без проблем получилось пробросить USB в виртуалку и воткнуть туда HASP ключ от 1С. Для малых и средних офисов это актуальная потребность.

Для того, чтобы установить proxmox на raid 1 пойдем окольным путем. Стандартный инсталлятор не дает нам необходимой возможности установки на рейд. У нас есть 2 варианта решения проблемы:

1. Установка сначала голой системы Debian 10 на raid1, а затем на нее устанавливается proxmox. Конечный результат не будет отличаться от инсталляции со стандартного диска.
2. Установить систему proxmox на одиночный диск, а потом перенести ее на raid1.

Я пробовал оба способа, первый мне показался более простым и понятным, поэтому займемся его реализацией.

Установка proxmox на mdadm raid 1 в debian 10

Первым делом нам нужно установить чистую систему Debian. На данный момент это версия 10 Buster. У меня есть отдельная статья по установке Debian. Там подробно описан процесс установки системы на софтовый рейд mdadm. В конце я на примере показал, что делать, когда диск выходит из строя, как его менять. Я на практическом примере продемонстрировал отказоустойчивость такого решения, поэтому не буду здесь подробно на этом останавливаться.

Скачивайте дистрибутив последней версии Debian. Взять его можно, к примеру, на Yandex.Mirror, конкретно здесь. Для установки подойдет образ CD-1 либо netinst. Начинайте стандартную установку и доходите до пункта настройки жесткого диска. Я буду использовать консольное отображение, не графическое. Мне так удобнее. Принципиальных отличий нет, можете делать по аналогии, если начали установку в графическом режиме. Когда дело дойдет до настройки диска, выбирайте вариант ручной разметки.

Если вы делаете установку на чистые диски, то вас должна встретить такая картина состояния дисков:

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

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

Параметры первого раздела на 500 Мб:

Параметры второго раздела на 10 Гб:

Оба раздела должны быть Primary.

Теперь создадим 2 отдельных raid массива на 500 мб и 10 гб. Выбираем раздел Configure Software RAID, дальше Create MD device, потом RAID1, 2 диска в массиве, и в завершении выбираем 2 наших раздела по 500 мб:

То же самое делаем с разделами по 10гб — объединяем их в рейд:

Как закончите, жмете Finish. У вас должна получиться такая картина:

Теперь нужно создать файловую систему на рейд массивах. Сделаем на первом раздел /boot ext2, а на втором корень системы — / и файловую систему ext4. В итоге должно получиться вот так:

Применяем изменения и продолжаем стандартную установку. У вас будет предупреждение о том, что не указан раздел для swap.

Игнорируйте его, потом подключим swap отдельно в виде файла. В процессе установки вам будет предложено выбрать набор пакетов. Не ставьте ничего лишнего, только ssh сервер и системные утилиты.

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

После установки рекомендую выполнить базовую настройку Debian. Это не обязательно, посмотрите на мои рекомендации и делайте то, что посчитаете нужным. Если гипервизор будет внутри локальной сети, то фаервол можно выключить, порт ssh не трогать, а логин под root разрешить. Обновиться, настроить сеть, время и полезные утилиты. Так же на всякий случай создайте swap раздел хотя бы на 2-4 гигабайта.

Теперь установим grub на оба жестких диска. Подключаемся к серверу по ssh и выполняем команду:

# dpkg-reconfigure grub-pc

На все вопросы оставляете дефолтные значения, в конце выбираете оба жестких диска для установки загрузчика:

На всякий случай проверим как встала система на жесткие диски:

# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            3.9G     0  3.9G   0% /dev
tmpfs           798M   17M  782M   3% /run
/dev/md1        9.1G 1020M  7.7G  12% /
tmpfs           3.9G     0  3.9G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/md0        460M   47M  390M  11% /boot
tmpfs           798M     0  798M   0% /run/user/0

# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] 
md0 : active raid1 sdb1[1] sda1[0]
      486400 blocks super 1.2 [2/2] [UU]
      
md1 : active raid1 sda2[0] sdb2[1]
      9756672 blocks super 1.2 [2/2] [UU]

Все в порядке, получилось так, как и задумывали. На данном этапе можно повынимать жесткие диски и проверить как система работает без одного из них, научиться заменять сбойный диск. Команды и рекомендации не буду приводить, чтобы не раздувать статью. Мануалов по работе с mdadm в интернете полно. К тому же, я об этом рассказываю в статье про установку debian, ссылку на которую уже давал ранее. Рекомендую сразу настроить мониторинг mdadm в zabbix.

Переходим непосредственно к установке proxmox. Для этого редактируем файл /etc/hosts и приводим его строго к следующему виду. Если что-то будет не так, как указано у меня, получите ошибку установки с очень большой долей вероятности. Я на этом моменте прилично застрял, когда разбирался.

# mcedit /etc/hosts

127.0.0.1 localhost.localdomain localhost
192.168.155.104 proxmox6.local proxmox6 pvelocalhost

Проверить правильность настроек можно командой:

# hostname – ip-address
192.168.155.104

В ответ должны получить свой ip адрес.

Добавляем в список репозиториев репу proxmox и стандартные репозитории debian. Я буду использовать зеркало яндекса, все остальное можно закомментировать:

# mcedit /etc/apt/sources.list

deb http://mirror.yandex.ru/debian/ buster main non-free contrib
deb-src http://mirror.yandex.ru/debian/ buster main non-free contrib
deb http://download.proxmox.com/debian/pve buster pve-no-subscription

Если не подходит репозиторий яндекса (заблокирован), можно воспользоваться любым другим, например http://mirror.corbina.net/debian/

Добавляем цифровую подпись proxmox репозитория:

# wget http://download.proxmox.com/debian/proxmox-ve-release-6.x.gpg -O /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg

Если раньше не обновили систему, то обновитесь и на всякий случай перезагрузите сервер после этого:

# apt update && apt full-upgrade
# reboot

Теперь устанавливаем саму систему виртуализации proxmox:

# apt install proxmox-ve postfix open-iscsi

Если получите ошибку во время установки:

dpkg: error processing package proxmox-ve (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 pve-cluster
 libpve-access-control
 librados2-perl
 pve-firewall
 pve-ha-manager
 qemu-server
 pve-container
 pve-manager
 proxmox-ve

Проверяйте файл hosts. У меня там лишние строки были, кроме тех, что я указал ранее. Когда исправил, установка прошла без ошибок. После окончания установки перезагрузите сервер, чтобы загрузилось новое ядро. Если все в порядке, то увидите окно приветствия на мониторе сервера:

Открывайте браузер по указанному адресу и заходите в web интерфейс. Напоминаю, что web порт proxmox по-умолчанию — 8006. Не забывайте его указывать в строке адреса в браузере. Вы должны увидеть предупреждение браузера насчет сертификата. Так и должно быть, по-умолчанию используется самоподписанный сертификат.

Базовая настройка proxmox

Заходим через браузер по указанному адресу. В окне логина вводите системный root и пароль от него. Нас сразу же встречает предупреждение:

You do not have a valid subscription for this server. Please visit www.proxmox.com to get a list of available options.

У нас нет платной подписки, поэтому нужно удалить из списка репозиториев платный. Для этого открываем консоль сервера и закомментируем репозиторий:

# mcedit /etc/apt/sources.list.d/pve-enterprise.list

#deb https://enterprise.proxmox.com/debian/pve buster pve-enterprise

Дальше видим главную страницу управления гипервизором proxmox 6.

Настройка сети

Обычно для виртуальных машин достаточно 3 режима работы сети:

1. Режим Bridge. В этом режиме виртуальные машины получают ip адрес из одной подсети с гипервизором и имеют в нее прямой доступ.
2. Режим NAT. Виртуальные машины получают ip адреса в своей виртуальной подсети, во внешнюю сеть выходят через гипервизор и настроенный на нем NAT.
3. Routed режим, когда шлюзом в интернет является одна из виртуальных машин.

Я использую все три режима работы сети, в зависимости от ситуации. Покажу это на примерах.

Как создать bridge в proxmox

Для создания сетевого интерфейса типа bridge в proxmox, в web интерфейсе перейдите в раздел Network и нажмите Create -> Linux Bridge.

Заполняете необходимые поля. Обязательными являются поле IP address, Gateway, Bridge Ports.

С такими настройками вы сможете в качестве локального интерфейса оставить только vmbr0, а eth0 отключить. Это на ваше усмотрение. Если оставить оба интерфейса, то ваш proxmox будет доступен по двум разным ip адресам. Если получите ошибку:

Удалите настройку шлюза на eth0, добавьте его на vmbr0.

Сразу обращаю внимание, что после создания бриджа, в системе создается новый файл с сетевыми настройками — /etc/network/interfaces.new. Там отражены сделанные нами изменения. Информация из него будет добавлена в основной файл interfaces после перезагрузки. Перезагрузите сервер и проверьте. Если все в порядке, то вы сможете подключаться и по ssh и по web доступу к обоим ip адресам — eth0 и vmbr0.

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

У меня были ситуации, когда выполняешь описанные выше действия, перезагружаешь сервер — он недоступен. Захожу локально, открываю файл /etc/network/interfaces, и удаляю какую-то лишнюю закомментированную строку, из-за которой не поднималась сеть. Подробностей уже не помню, что именно было не так, но пару раз ловил такие ошибки.

Расскажу про еще один нюанс. Во время создания бриджа вас обязательно просят указать статические сетевые настройки. А иногда нужно использовать dhcp сервер. Через web интерфейс это сделать не получится, либо я не понял как. Поступаю другим образом. Пишу произвольные настройки через gui, а потом исправляю файл /etc/network/interfaces. Вот пример настройки сети, когда bridge получает сетевые настройки по dhcp.

source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
allow-hotplug eth0
#iface eth0 inet dhcp
auto vmbr0
iface vmbr0 inet dhcp
	bridge-ports eth0
	bridge-stp off
	bridge-fd 0

Перезагружаю сервер и убеждаюсь, что все работает как надо.

При этом в web интерфейсе будет вот так.

Настройка NAT для виртуальных машин

Для того, чтобы настроить удобный способ сетевого подключения виртуальных машин с использованием NAT, когда все виртуалки вместе с гипервизором будут в единой виртуальной сети видеть друг друга, потребуется создать еще один bridge и настроить трансляцию адресов с помощью iptables на самом гипервизоре. Сделаем это.

Заходим по ssh на гипервизор и добавляем в файл с новыми сетевыми настройками несколько строк:

# mcedit /etc/network/interfaces.new

auto vmbr1
iface vmbr1 inet static
address 10.10.10.1
netmask 255.255.255.0
bridge_ports none
bridge_stp off
bridge_fd 0
post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -o vmbr0 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s '10.10.10.0/24' -o vmbr0 -j MASQUERADE

Объясняю, что мы сделали:

1. Разрешили форвард пакетов между сетевыми интерфейсами. Без этого гипервизор не сможет работать в роли шлюза.
2. Добавили правила iptables для настройки NAT.

Сохраняем файл и перезагружаем сервер. В настройках сети виртуальных машин указываете интерфейс vmbr1, а в самой системе виртуалки вручную прописываете сетевые настройки, где адрес шлюза равен адресу интерфейса vmbr1 — 10.10.10.1, а ip адрес самой машины будет в подсети 10.10.10.0/24. Все виртуальные машины, у которых установлен бридж vmbr1 будут видеть друг друга.

Если вам не хочется на каждой ВМ вручную прописывать IP, можно настроить dhcp сервер либо на одной из виртуалок, либо на самом гипервизоре. Главное назначить ему нужный интерфейс — vmbr1. Настройка dhcp сервера выходит за рамки этой статьи, не буду на этом останавливаться. Для общего использования достаточно того, что я уже указал.

Routed режим сети

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

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

В обоих случаях есть еще варианты настройки в зависимости от количества ip адресов, которые вам выдает провайдер. Если у вас только 1 внешний IP адрес, вы должны его пробросить в виртуальный шлюз. Только он будет иметь доступ в интернет. Для этого вы должны создать бридж вместе с сетевой картой, в которую приходит интернет, но при этом сам бридж не должен иметь IP адреса. Вот пример, как это должно выглядеть в первом варианте:

iface eth0 inet manual

auto vmbr0
iface vmbr0 inet manual
bridge_ports eth0
bridge_stp off
bridge_fd 0

auto vmbr1
iface vmbr1 inet static
address 10.0.0.1
netmask 255.255.255.0
gateway 10.0.0.2
bridge_ports none
bridge_stp off
bridge_fd 0

В eth0 входит провод от провайдера. Этот интерфейс включен в vmbr0 и ему не назначен ip адрес. Второй бридж vmbr1 имеет виртуальный ip адрес и создан для локальной сети виртуальных машин. Дальше вы создаете виртуальную машину для шлюза и добавляете ему оба бриджа — vmbr0 и vmbr1. На первом настраиваете ip в соответствии с настройками провайдера, на втором в данном случае указываете статический ip адрес 10.0.0.2, который будет являться шлюзом для всех виртуальных машин и самого гипервизора в том числе. Это отражено в параметре gateway в свойствах vmbr1. Потом настраиваете виртуальный шлюз и все будет работать.

Виртуальному шлюзу нужно не забыть поставить автозапуск при старте гипервизора, чтобы можно было перезагружать гипервизор удаленно и не терять доступ. Схема кажется немного запутанной, надо просто вникнуть и разобраться. На самом деле это удобно в том случае, если у вас один единственный сервер и на нем надо развернуть всю инфраструктуру. Шлюз замечательно живет на виртуальной машине, легко бэкапится и переносится. Настроить можно любой функционал. Единственный нюанс — настраивать нужно локально, тщательно проверить и только убедившись, что все корректно работает и перезагружается, ставить на постоянную работу.

Таким образом, у вас будет гипервизор, на нем шлюз в виде виртуальной машины. Все настройки сети выполняются на шлюзе, гипервизор трогать вообще не надо. Если у вас несколько гипервизоров в разных местах, вы их объединяете в единую сеть с помощью, к примеру, openvpn, который настраивается на самих шлюза. Виртуальные машины отдельно настраивать не надо. Они замечательно будут видеть друг друга через свои шлюзы на гипервизорах.

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

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

Пример организации сети для виртуальных машин

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

Итак, вот настройки сети на гипервизоре.

eth0 смотрит в интернет, vmbr0 бридж, в который включен интерфейс eth0. На обоих интерфейсах настроены внешние ip адреса провайдера, но это не обязательно. Их может и не быть. Тут просто у сервера 8 внешних ip, хватает для всех. vmbr1 полностью виртуальный бридж для организации сети виртуальных машин.

Далее создаем виртуальную машину под шлюз. Добавляем ей оба бриджа.

Диска, как видите, хватит и 10 гб для шлюза. Он уже пару лет так работает. Теперь смотрим на настройки сети у этой виртуалки.

auto ens18
iface ens18 inet static
	address 5.79.111.222
	netmask 255.255.255.224
	gateway 5.79.111.1
	dns-nameservers 1.1.1.1 8.8.4.4
	post-up iptables-restore < /etc/iptables.rules

auto ens19
iface ens19 inet static
	address 10.10.11.1
	netmask 255.255.255.0

Ens18 соответствует vmbr0, а ens19 — vmbr1. На ens18 настроен внешний ip и шлюз провайдера, который выделил этот ip адрес и выдал сетевые настройки. Настраиваем на этой виртуальной машине шлюз так, как нам надо — iptables, dns, dhcp и т.д. Далее этот шлюз указываем в качестве default gateway для остальных виртуальных машин гипервизора.

Вот пример настроек сети с одной из виртуальных машин этого гипервизора.

auto eth0
iface eth0 inet static
	address 10.10.11.17
	netmask 255.255.255.0
	gateway 10.10.11.1

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

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

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

Хранилище для виртуальных машин

После чистой установки proxmox на debian, автоматически создается хранилище local, которое располагается на одном разделе с самой операционной системой по адресу /var/lib/vz. Оно уже предназначено для хранения образов дисков, виртуальных машин и контейнеров.

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

Мы создадим еще один raid 1 mdadm из незанятого места на дисках. Для этого нам нужно будет там создать разделы и объединить их в программный рейд с помощью mdadm.Обращаю сразу внимание, что это тестовая среда, в реальности так диски разбивать не надо. Оптимально сделать raid 1 из двух отдельных под систему, заняв 30-50 гигов, остальное место на этом рейде отдать под iso образы и возможно бэкапы. Для виртуальных машин подключить отдельные диски и собрать из них рейд. Его уровень будет зависеть от количества дисков. Оптимально 4 штуки для raid 10

Смотрим имена дисков в нашей системе:

# ls -l /dev | grep sd

brw-rw-- –  1 root disk      8,   0 Aug  9 15:26 sda
brw-rw-- –  1 root disk      8,   1 Aug  9 15:26 sda1
brw-rw-- –  1 root disk      8,   2 Aug  9 15:26 sda2
brw-rw-- –  1 root disk      8,  16 Aug  9 15:26 sdb
brw-rw-- –  1 root disk      8,  17 Aug  9 15:26 sdb1
brw-rw-- –  1 root disk      8,  18 Aug  9 15:26 sdb2

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

# cfdisk /dev/sda

Выбираем свободное пространство, создаем на нем раздел и указываем тип — Linux raid autodetect.

То же самое делаем со вторым диском. После этих действий у вас должны появиться новые разделы /dev/sda3 и /dev/sdb3. Чтобы это произошло, нужно либо перезагрузить сервер, либо перечитать таблицу разделов командой:

# partprobe -s

Если команда не найдена, установите parted:

# apt install parted

Проверим новые разделы:

# ls -l /dev | grep sd

brw-rw-- –  1 root disk      8,   0 Aug  9 15:40 sda
brw-rw-- –  1 root disk      8,   1 Aug  9 15:40 sda1
brw-rw-- –  1 root disk      8,   2 Aug  9 15:40 sda2
brw-rw-- –  1 root disk      8,   3 Aug  9 15:40 sda3
brw-rw-- –  1 root disk      8,  16 Aug  9 15:40 sdb
brw-rw-- –  1 root disk      8,  17 Aug  9 15:40 sdb1
brw-rw-- –  1 root disk      8,  18 Aug  9 15:40 sdb2
brw-rw-- –  1 root disk      8,  19 Aug  9 15:40 sdb3

Теперь объединим только что созданные разделы в raid1:

# mdadm – create /dev/md2 – level=1 – raid-disks=2 /dev/sda3 /dev/sdb3

mdadm: Note: this array has metadata at the start and
may not be suitable as a boot device. If you plan to
store '/boot' on this device please ensure that
your boot-loader understands md/v1.x metadata, or use
--metadata=0.90
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md2 started.

Проверим информацию о mdadm:

# cat /proc/mdstat

Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] 
md2 : active raid1 sdb3[1] sda3[0]
      42140672 blocks super 1.2 [2/2] [UU]
      [=>...................]  resync =  9.4% (4001792/42140672) finish=3.0min speed=210620K/sec
      
md0 : active raid1 sdb1[1] sda1[0]
      486400 blocks super 1.2 [2/2] [UU]
      
md1 : active raid1 sdb2[1] sda2[0]
      9756672 blocks super 1.2 [2/2] [UU]

Все в порядке, массив синхронизируется. Дождитесь окончания синхронизации и продолжайте. Хотя это не обязательно, массив и сейчас уже готов к работе, он он будет сильно тормозить во время ребилда. Добавим информацию о новом массиве в конфигурационный файл /etc/mdadm/mdadm.conf, иначе после перезагрузки массив не будет виден в системе:

# mdadm – examine – scan | grep 'md/2' >> /etc/mdadm/mdadm.conf

Конфигурационный файл примет такой вид:

# cat /etc/mdadm/mdadm.conf

# mdadm.conf
# mdadm.conf
#
# !NB! Run update-initramfs -u after updating this file.
# !NB! This will ensure that initramfs has an uptodate copy.
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
#DEVICE partitions containers

# automatically tag new arrays as belonging to the local system
HOMEHOST 

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays
ARRAY /dev/md/0  metadata=1.2 UUID=a214eb8b:c3ff0ab2:13197140:25a25924 name=proxmox6:0
ARRAY /dev/md/1  metadata=1.2 UUID=1d5a52f3:7caa923c:b8f13836:8a7bcf54 name=proxmox6:1

# This configuration was auto-generated on Fri, 09 Aug 2019 13:59:40 +0300 by mkconf
ARRAY /dev/md/2  metadata=1.2 UUID=30be9c4e:6a351eca:6d66228d:ee695c19 name=proxmox6:2

Дальше у нас 2 пути:

1. Создать файловую систему на md2, смонтировать раздел в систему и создать storage в виде обычной директории, такой же, как по-умолчанию.
2. Создать том LVM и на его основе storage.

Традиционно используют второй способ, так как он позволяет потом использовать в качестве дисков виртуальных машин lvm разделы. С ними удобно работать, плюс, теоретически, блочное устройство типа lvm должно работать чуть быстрее. Так что пойдем по второму пути. Выполним инициализацию раздела для работы с LVM:

# pvcreate /dev/md2
File descriptor 7 (pipe:[31619]) leaked on pvcreate invocation. Parent PID 2856: bash
  Physical volume "/dev/md2" successfully created.

Создадим группу томов:

# vgcreate raid1-md2 /dev/md2
File descriptor 7 (pipe:[31619]) leaked on vgcreate invocation. Parent PID 2856: bash
  Volume group "raid1-md2" successfully created

Теперь идем в web интерфейс, выбираем Datacenter, вкладку Storage, жмем Add и выбираем LVM:

Указываем параметры только что созданной группы томов.

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

Добавление и подключение диска

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

Я подключил новый жесткий диск, проверим его имя в системе:

# ls -l /dev | grep sd

brw-rw-- – 1 root disk 8, 0 Aug  9 15:40 sda
brw-rw-- – 1 root disk 8, 1 Aug  9 15:40 sda1
brw-rw-- – 1 root disk 8, 2 Aug  9 15:40 sda2
brw-rw-- – 1 root disk 8, 3 Aug  9 15:40 sda3
brw-rw-- – 1 root disk 8, 16 Aug  9 15:40 sdb
brw-rw-- – 1 root disk 8, 17 Aug  9 15:40 sdb1
brw-rw-- – 1 root disk 8, 18 Aug  9 15:40 sdb2
brw-rw-- – 1 root disk 8, 19 Aug  9 15:40 sdb3
brw-rw-- – 1 root disk 8, 32 Aug  9 15:40 sdc

Можно не создавать на диске раздел, а сразу его инициализировать для работы в lvm и создать группу томов:

# pvcreate /dev/sdc
# vgcreate disk-sdc /dev/sdc

Идем в веб интерфейс и создаем новый storage:

Если у вас будет не одиночный диск, а несколько, то перед этим создайте рейд массив из них и так же поверх накатывайте lvm и добавляйте новый storage. На этом настройку локальных хранилищ завершаем. Все основные действия мы выполнили, можно начинать работать с системой — создавать виртуальные машины.

 Хранилище по NFS

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

Я это хранилище буду использовать только для iso образов и backup’ов, поэтому выставляю соответствующие настройки.

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

Создание и настройка виртуальных машин

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

Чтобы установить виртуальную машину, нужно использовать iso образ. Его надо как-то загрузить на proxmox. Сделать это не сложно, нужно только понимать, что загрузить образ можно только на тот storage, который поддерживает такую возможность. Сторейджи LVM не позволяют загружать образы, для этого нужно использовать, например, storage в виде локальной директории. По умолчанию, один такой есть в системе. В него и загрузим образ виртуальной машины. Для этого открываем нужный storage и выбираем вкладку Content. Жмем на Upload и выбираем нужный образ.

На этапе загрузки iso образа я иногда сталкиваюсь с проблемой. Образ больше 4Гб не загружается. Проверял несколько раз, в том числе в различных инсталляциях на разное железо. Ошибка время от времени проявляется. Если у вас образы больше, чем 4 Гб, ищите альтернативные способы загрузки в хранилище, благо это не составляет большого труда.

Альтернативный способ загрузки iso образа в proxmox — использовать scp или напрямую через wget качать образ из интернета. Положить его нужно в директорию /var/lib/vz/template/iso, если используете дефолтный storage, добавленный по-умолчанию после установки.

Дожидаемся окончания загрузки. Теперь этот образ можно использовать для установки ОС на виртуальную машину. Создание виртуальной машины выглядит следующим образом. Нажимаем на кнопку Create VM

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

Выбирайте только что созданную машину и запускайте ее. Для того, чтобы попасть в консоль виртуальной машины, выбери соответствующий раздел:

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

Автозапуск виртуальной машины

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

Рассмотрим простой пример. У нас есть виртуальная машина, к примеру Windows Server с ролью Active Directory на борту. Все остальные серверы завязаны на корректную работу службы каталогов. Нам надо сначала запустить контроллер домена, а затем все остальные серверы за ним. Установите параметр Start at boot в положение Yes для всех виртуальных машин, которые хотите запускать автоматически. Укажите Start/Shutdown order на контроллере домена 1, Startup delay 240, Shutdown timeout 120. С такими настройками при запуске гипервизора первой стартует виртуальная машина с КД, через 240 секунд все остальные в соответствии с их настройками.

Backup виртуальных машин

Подошли к очень важному этапу настройки proxmox — организация бэкапа виртуальных машин. На этот момент нужно обратить особенное внимание, и все хорошенько проверить. Настраивается backup так же просто, как и все остальное в proxmox. Идем в раздел Backup и создаем задание:

Выставляем необходимые параметры, например такие:

Ждем назначенного часа и проверяем исполнение задания.

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

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

Тут сразу встает следующий вопрос — как автоматически удалять старые бэкапы? Однозначно ответить не получится, все будет зависеть от того, где будут храниться бэкапы. Если это обычный linux сервер с доступом к консоли, то можно воспользоваться программой find:

# /usr/bin/find /mnt/backups-vm -type f -mtime +30 -exec rm {} \;

После выполнения этой команды, все файлы в папке /mnt/backups-vm старше 30 дней будут удалены. Для автоматизации процесса команду можно поместить в cron. С помощью zabbix вы можете мониторить актуальность бэкапов и следить за их размерами.

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

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

Часто задаваемые вопросы по теме статьи (FAQ)

Как можно делать инкрементные бэкапы виртуальных машин в Proxmox?

Проблема инкрементных бэкапов в proxmox очень актуальна. Универсального решения, к сожалению, нет. На текущий момент инкрементные бэкапы возможны только на уровне хранилища для виртуальных машин, если оно это поддерживает. К примеру, с помощью zfs это можно организовать через механизм снепшотов. Какого-то аналога для бэкапов, типа Veeam, для Proxmox не существует.Есть ли разница, разворачивать Proxmox на Debian либо через официальный ISO образ?

Принципиальной разницы нет. На выходе будет одна и та же система. Другое дело, что установив сначала Debian, у вас возникает больше возможностей для преднастройки дисковой подсистемы. К примеру, вы можете установить все на массив mdadm. Штатный установщик из ISO образа не дает такой возможности.Чтло лучше использовать — виртуальные машины или контейнеры?

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

Принципиальной разницы нет. По сути Proxmox — это система управления гипервизором на базе KVM. Виртуальные машины, как настройки, так и сами диски с данными, без проблем переносятся на любой другой гипервизор на базе KVM. Для этого не нужна ни конвертация данных, ни преобразование настроек.Можно ли в виртуальные машины Proxmox пробрасывать внешние IP адреса?

Да, в этом нет никаких проблем. Просто делаете бридж с интерфейсом гипервизора, на который приходят эти ip адреса и добавляете интерфейсы из этого бриджа в виртуальные машины. А на них настраиваете внешние IP адреса.Можно ли в Proxmox пробросить USB в виртуальную машину? Например, для подключения токена или лицензионного ключа.

Да, то можно сделать. Гипервизор KVM, на базе которого построен Proxmox, давно поддерживает возможность проброса USB портов в виртуальные машины.

Заключение

Подведем итог тому, что сделали:

• Установили гипервизор proxmox на сервер под управлением Debian на программный raid1, обеспечив отказоустойчивость системы на уровне дисков.
• Настроили виртуальную сеть для виртуальных машин.
• Подключили различные storage для выполнения задач размещения и бэкапа виртуальных машин.
• Добавили и настроили виртуальные машины.
• Организовали автоматический бэкап всех ВМ.

Я постарался выбрать наиболее востребованные функции и описать их, чтобы систему можно было использовать в реальной работе и не бояться за надежность решения. Собрал необходимый минимум, но статься все равно получилась очень большая, объемная. Я не стал ее разделять на части, чтобы была целостная картина всего того, что сделали. Тут есть еще над чем поработать, особенно актуален вопрос бэкапа. Без инкрементного бэкапа неудобно хранить резервные копии на удаленном сервере, очень большой объем передаваемых данных получается. Мне не известен способ инкрементного бэкапа виртуальных машин в proxmox, буду рад, если кто-то посоветует хорошее решение для KVM. Снэпшоты zfs не в счет.

Сообщение Установка Proxmox в Debian на raid 1 появились сначала на Clip-Clap.

Сетевые настройки на сервере Debian

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

Первоначальная настройка сети начинается во время установки сервера. Если у вас есть сетевой интерфейс и dhcp сервер в сети, то сеть сконфигурируется автоматически на основе полученных настроек и будет готова к работе. В последствии вы можете выполнить настройку сети в Debian через консоль с помощью программ ip или ifconfig. Наиболее популярным и современным средством на текущий момент является ip, поэтому в дальнейшем рассмотрим вопрос конфигурации сетевых интерфейсов с ее помощью. Про ifconfig тоже не забудем. Рассмотрим ее позже отдельно.

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

Есть 2 различные возможности изменить сеть в Debian:

1. Настройка сети из консоли с помощью указанных ранее консольных программ.
2. С помощью редактирования конфигурационного файла сетевых интерфейсов /etc/network/interfaces.

Мы рассмотрим оба этих варианта. Вводная теоретическая часть окончена, приступаем к практике.

Настройка статического IP

Вы установили сервер и во время установки указали какие-то сетевые параметры, или не указали, не важно. Но сейчас вы решили, что вам нужно назначить статический ip (static ip) адрес. Воспользуемся для этого утилитой ip. Сначала посмотрим список всех сетевых интерфейсов:

# ip a

У меня в системе 1 сетевой интерфейс eth0 и он каким-то образом уже сконфигурирован. Назначим ему еще один статический адрес:

# ip addr add 192.168.1.35/24 dev eth0

Этот адрес будет добавлен к уже существующему адресу. Проверим это:

# ip a

Теперь сервер будет доступен по обоим адресам. Текущая настройка сохранится только до перезагрузки сервера. Чтобы она применялась во время загрузки, нужно либо каким-то образом добавить команду на изменение настроек в автозагрузку, например в /etc/rc.local, но это будет костыль. Правильнее отредактировать файл, который отвечает за сетевые настройки в debian — /etc/network/interfaces. Для того, чтобы назначить постоянный статический ip адрес, его нужно привести к следующему виду:

# mcedit /etc/network/interfaces

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.1.35
gateway 192.168.1.1
netmask 255.255.255.0

Для проверки перезагружаем сервер и смотрим, все ли в порядке с настройкой статического ip адреса. Если вам нужно сменить ip адрес в debian, то вы можете временно изменить его с помощью команды ip, либо постоянно, отредактировав параметр address в файле сетевых настроек interfaces.

Получение сетевых настроек по DHCP

Теперь рассмотри вариант, когда вам необходимо получить динамический ip адрес в Debian. Здесь по аналогии с предыдущими настройками можно пойди двумя путями:

1. Получить ip адрес по dhcp в консоли с помощью программы dhclient, который будет работать до перезагрузки.
2. Отредактировать файл конфигурации сетевых интерфейсов.

Смотрим снова на текущую конфигурацию сети:

# ip a

Выполним команду на получение ip адреса по dhcp и проверим сеть:

# dhclient
# ip a

В качестве второго ip мы получили адрес от dhcp сервера. Если у вас несколько сетевых интерфейсов, то необходимо добавлять название после команды, например вот так:

# dhclient eth0

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

# dhclient -r

Обращаю внимание, что эта команда сбросит все ip адреса интерфейса, в том числе и статические. Чтобы снова запросить адрес, нужно выполнить предыдущую команду на получение ip с указанием сетевого интерфейса eth0.

Все изменения, сделанные в консоли после перезагрузки, исчезнут. Чтобы их сохранить, приведем файл /etc/network/interfaces к следующему виду:

# mcedit /etc/network/interfaces

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

Установка шлюза по-умолчанию (default gateway)

Теперь разберемся со шлюзом по-умолчанию. В предыдущих примерах со статическим ip адресом и настройками по dhcp у нас не было необходимости указывать отдельно default gateway. Мы его устанавливали вместе с остальными настройками. Чтобы посмотреть установленный по-умолчанию шлюз в debian, можно воспользоваться следующей командой в консоли:

# ip r sh

default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.24

Это шлюз по-умолчанию (default gateway). Можно воспользоваться другими, более популярными и привычными командами:

# route
# netstat -nr

Если получите ошибки:

-bash: route: command not found
-bash: netstat: command not found

Значит у вас не установлен пакет net-tools. Установить его можно следующей командой.

# apt install net-tools

Сетевые инструменты из пакета net-tools объявлены устаревшими и не включены в состав базовой системы. Я ими продолжаю пользоваться, потому что мне нравится их вывод больше, чем у команды ip. Netstat мне видится более информативным, хотя по сути, они все показывают одно и то же. Отказ в пользу утилиты ip идет по той причине, что она объединяет в себе все основные сетевые инструменты. Удобнее пользоваться только ей одной для настройки сети, нежели разными утилитами для разных целей.

Если нам нужно сменить default gateway, то сначала надо удалить текущий шлюз, а потом назначить новый.

# route del default gw 192.168.1.1
# route add default gw 192.168.1.50

То же самое, только с помощью ip:

# ip route del default
# ip route add default via 192.168.1.50

Проверяем, что получилось:

# ip r sh

default via 192.168.1.50 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.24

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

Как указать DNS сервер

Остался последний из основных сетевых параметров — dns сервер. С ним в debian и ubuntu есть определенная путаница. Традиционно в linux для установки dns серверов используется файл /etc/resolv.conf. Но в какой-то момент в этих дистрибутивах появилась программа resolvconf, которая стала управлять настройками dns в системе. В итоге, файл resolv.conf постоянно перезаписывается этой программой. Нужна она в первую очередь для систем, где dns сервера постоянно меняются. Она следит за их изменением и корректно передает информацию об изменении программам, для которых это важно. Я лично не знаю таких программ и мне не приходилось сталкиваться с ситуацией, когда это было необходимо.

Если я не ошибаюсь, то в минимальной конфигурации debian программа resolvconf не устанавливается, а вот в ubuntu она стоит. Проверить наличие программы очень просто:

# dpkg -l | grep resolvconf

Если в выводе пусто, значит ее нет. Тогда все очень просто. Для того, чтобы указать dns сервер, достаточно его записать в файл /etc/resolv.conf в следующем виде:

# mcedit /etc/resolv.conf

nameserver 192.168.1.1
nameserver 77.88.8.1
nameserver 8.8.8.8
nameserver 1.1.1.1

Я на всякий случай указал локальный сервер и 3 внешних. Если у вас стоит resolvconf, то в случае ненадобности, удалите его командой:

# apt-get remove resolvconf

После этого сервер надо перезагрузить и удалить сломавшуюся символьную ссылку /etc/resolv.conf, а вместо нее создать файл с нужным содержанием, которое я привел выше.

Если же вам по какой-то причине необходима указанная выше программа, она у вас стоит и вы не хотите ее удалять, то адрес dns сервера необходимо указать в файле /etc/network/interfaces, добавив к параметрам интерфейса еще один:

dns-nameservers 192.168.1.1 77.88.8.1 8.8.8.8 1.1.1.1

Этот параметр нужно установить сразу после указания шлюза gateway. Несколько адресов разделяются пробелом.

Изменить hostname (имя хоста)

Во время установки debian вы указывали имя хоста. Посмотреть его текущее значение можно в консоли:

# hostname
debian

Это значение записано в файле /etc/hostname. Есть 2 способа изменить hostname в debian:

1. Простой и быстрый с помощью консольной команды. Результат работает только до перезагрузки компьютера. Потом вернется старое имя.
2. С помощью изменения конфигурационного файла результат сохраняется и после перезагрузки. Чтобы сразу применить изменение, потребуется выполнить системный скрипт.

Для первого способа достаточно в консоли ввести команду:

# hostname debian10

Теперь проверим, что получилось:

# hostname
debian10

Имя хоста изменилось, но в файле /etc/hostname по-прежнему указано прошлое значение. После перезагрузки hostname снова примет старое значение debian. Чтобы сделать постоянное изменение, необходимо ввести новое значение в файл вручную:

# mcedit /etc/hostname
debian10

Изменение вступит в силу после перезагрузки. Если воспользоваться командой:

# hostnamectl set-hostname debian10

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

2 и более IP на одном интерфейсе

Достаточно часто возникают ситуации, когда необходимо назначить несколько ip на одном интерфейсе. Сделать это очень просто. В самом начале я показал, как быстро через консоль в Debian можно назначить несколько ip c помощью программы. Теперь сделаем так, чтобы эти настройки сохранялись после перезагрузки. Для этого редактируем наш любимый и ненаглядный /etc/network/interfaces:

# mcedit /etc/network/interfaces

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

auto eth0:1
iface eth0:1 inet static
address 192.168.1.35
netmask 255.255.255.0

С такими настройками я получу 2 ip адреса на сетевом интерфейсе:

1. Первый от dhcp сервера.
2. Второй адрес на этой же сетевой карте будет указан статически.

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

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

Как быстро узнать ip адрес сервера в Debian

Часто возникает вопрос, как в debian быстро узнать или проверить ip адреса, назначенные серверу. Выше я уже приводил пример простой команды, которая показывает все сетевые параметры интерфейса. Сейчас рассмотрим несколько вариантов, которые наглядно покажут только ip адреса, без лишней информации. Для начала воспользуемся уже известной командой ip, немного подрезав ее вывод:

# ip a | grep inet | awk '{print $2}'

Вы узнаете все ip адреса сервера, в том числе и ipv6. То же самое, только без ipv6 можно увидеть другой командой:

# ifconfig | grep 'inet addr:'

Если получите ошибку:

-bash: ifconfig: command not found

Значит у вас не установлен пакет net-tools. Установить его можно следующей командой:

# apt install net-tools

Если совсем заморочиться и обрезать все лишнее в выводе команды ifconfig, то можно вывести только список ip адресов:

# ifconfig | grep 'inet addr:' | cut -d: -f2 | awk '{ print $1}'

Аналогичный вывод будет и в таком случае:

# ifconfig | awk '/inet addr:/ {print substr($2, 6)}'

Можно убрать локальный интерфейс, чтобы глаза не мозолил, тогда вообще все наглядно:

# ifconfig | awk '/inet addr:/ {print substr($2, 6)}' | grep -v 127.0.0.1

Думаю, этих вариантов достаточно, чтобы проверить все ip адреса, отрезав лишнее.

Static routes (статические маршруты)

Следующим важным элементом настройки сети является управление статическими маршрутами (static routes): добавление (route add) и удаление (route del). Вновь воспользуемся консольной командой ip. Для того, чтобы добавить маршрут в debian, достаточно ввести в консоли:

# ip route add 10.0.0.0/24 via 192.168.1.50

Проверяем таблицу маршрутов:

# route

Чтобы удалить маршрут, выполняем команду:

# ip route delete 10.0.0.0/24

После перезагрузки все маршруты, добавленные таким способом, исчезнут. Чтобы статический маршрут в Debian сохранялся после перезагрузки, опять редактируем interfaces, добавляя в описание того интерфейса, к которому будут относиться маршруты, следующие строки:

post-up route add -net 10.0.0.0 netmask 255.255.255.0 gw 192.168.1.50
post-up route add -net 10.1.0.0 netmask 255.255.255.0 gw 192.168.1.60
pre-down route del -net 10.0.0.0 netmask 255.255.255.0 gw 192.168.1.50
pre-down route del -net 10.1.0.0 netmask 255.255.255.0 gw 192.168.1.60

Мы добавили 2 статических маршрута. Перезагружаемся и проверяем.

Мой конфиг целиком стал выглядеть вот так:

source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
post-up route add -net 10.0.0.0 netmask 255.255.255.0 gw 192.168.1.50
post-up route add -net 10.1.0.0 netmask 255.255.255.0 gw 192.168.1.60
pre-down route del -net 10.0.0.0 netmask 255.255.255.0 gw 192.168.1.50
pre-down route del -net 10.1.0.0 netmask 255.255.255.0 gw 192.168.1.60

auto eth0:1
iface eth0:1 inet static
address 192.168.1.35
netmask 255.255.255.0
gateway 192.168.1.35

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

Как выполнить перезапуск сети

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

# service networking restart

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

# /etc/init.d/networking restart
[ ok ] Restarting networking (via systemctl): networking.service.

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

Настройка vlan в Debian

Для настройки vlan в Debian первым делом необходимо установить пакет vlan:

# apt install vlan

Теперь нужно разобраться с необходимым модулем ядра для vlan — 8021q. Проверим, загружено ли оно в системе:

# lsmod | grep 8021q

Если в выводе пусто, а по-умолчанию там будет пусто, модуль не загружен. Загрузим его и проверим:

# modprobe 8021q
# lsmod | grep 8021q
8021q                  27844  0
garp                   13117  1 8021q
mrp                    17343  1 8021q

Все в порядке, vlan модуль загрузился. Добавим его в автозагрузку:

# echo 8021q >> /etc/modules

Теперь этот модуль будет загружаться при старте сервера. Создадим виртуальный интерфейс с vlan с id 1500:

# vconfig add eth0 1500

Назначим адрес новому интерфейсу и запустим его:

# ip addr add 192.168.10.100/24 dev eth0.1500
# ip link set eth0.1500 up

Можно в одну команду, с помощью ifconfig:

ifconfig eth0.1500 192.168.10.100 netmask 255.255.255.0 up

Смотрим, что получилось:

Мы выполнили настройку vlan интерфейса в Debian. Теперь сделаем так, чтобы после перезагрузки настройки сохранились. Для этого добавляем свойства vlan интерфейса в файл конфигурации сети, оставляя и не трогая то, что там уже есть:

# mcedit /etc/network/interfaces

auto eth0.1500
iface eth0.1500 inet static
address 192.168.10.100
netmask 255.255.255.0
vlan_raw_device eth0

Перезагрузите сервер и проверьте, что получилось. Можно выполнить перезапуск сети, но если вы до этого все вручную через консоль сделали, то не поймете, сработали настройки из файла или нет. Таким образом очень просто и быстро настроить vlan на сервере с Debian.

Как отключить ipv6 в Debian

Пока еще новая версия протокола ip не получила широкого распространения, если он вам специально не нужен, ipv6 можно отключить. Прежде чем отключать, необходимо узнать, какие сервисы в настоящее время его используют и перенастроить их, отключив у них ipv6. Если этого не сделать, то в работе этих программ могут возникнуть ошибки. Скорее всего не критичные, но все равно, сделаем все аккуратно и правильно. Сначала проверим, что у нас работает на ipv6:

# netstat -tulnp | grep :::

На свежеустановленном сервере debian программы ssh, exim, dhclient и rpcbind используют ipv6. Отключим это. Начнем с ssh. Открываем файл /etc/ssh/sshd_config и раскомментируем параметр ListenAddress:

# mcedit /etc/ssh/sshd_config

ListenAddress 0.0.0.0

Перезапускаем ssh:

# service sshd restart

Сделаем то же самое с exim4. Открываем файл конфигурации /etc/exim4/exim4.conf.template и в самом начале, после вступительных комментариев пишем:

# mcedit /etc/exim4/exim4.conf.template

disable_ipv6 = true

Перезапускаем exim:

# service exim4 restart

В dhclient для отключения ipv6 в конфиге убираем все параметры в запросе request, начинающиеся с dhcp6. Должно получиться вот так:

# mcedit /etc/dhcp/dhclient.conf

request subnet-mask, broadcast-address, time-offset, routers,
        domain-name, domain-name-servers, domain-search, host-name,
        netbios-name-servers, netbios-scope, interface-mtu,
        rfc3442-classless-static-routes, ntp-servers;

Перезапускаем сеть:

# service networking restart

Отключаем ipv6 в rpcbind. Открываем конфигурацию /etc/netconfig и комментируем 2 строки с udp6 и tcp6:

# mcedit /etc/netconfig

#udp6       tpi_clts      v     inet6    udp     -       -
#tcp6       tpi_cots_ord  v     inet6    tcp     -       -

Перезапускаем службу rpcbind и nfs-common, которая от него зависит:

# service rpcbind restart
# service nfs-common restart

Проверяем, что у нас осталось:

# netstat -tulnp | grep :::
udp6       0      0 :::6909                 :::*                                1166/dhclient

dhclient почему-то остался висеть на ipv6 порту, но ладно, это не страшно, запрашивать по ipv6 он все равно ничего не будет. Теперь полностью отключаем ipv6 в Debian:

# mcedit /etc/sysctl.conf

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Добавьте эти строки в любое место конфига, например, в самый конец. Перезапустим sysctl для применения настроек:

# sysctl -p

Проверяем свойства сетевых интерфейсов командами ifconfig и ip. Информации об ipv6 быть не должно, мы его полностью отключили.

Работа с файлом hosts

В папке /etc любого linux дистрибутива, в том числе debian есть файл hosts. Разберемся немного что это за файл и для чего он нужен. По-умолчанию он выглядит следующим образом:

# cat /etc/hosts

Представим, что у нас в локальной сети есть некий сервер с именем server  и ip 192.168.1.50 Мы хотим к нему обращаться по имени. Тогда добавляем запись в файл hosts:

192.168.1.50 server

Теперь мы можем обращаться к серверу просто по имени server.

Сервер будет в первую очередь смотреть информацию в файле hosts, только потом в dns сервере. Например, если вы добавите в файл строку:

127.0.0.1 ya.ru

То обращаясь к адресу ya.ru будете попадать на локалхост:

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

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

Настройка сетевой карты

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

# lspci | grep Eth
01:00.0 Ethernet controller: Qualcomm Atheros AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0)

В моем случае это единственная сетевая карта фирмы Qualcomm. Теперь установим утилиту ethtool для настройки сетевой карты:

# apt install ethtool

Посмотрим информацию о сетевой карте:

# ethtool eth0

Указана текущая скорость, на которой работает карточка. Ее можно сменить в случае необходимости:

# ethtool -s eth0 speed 100 duplex full

Этой командой можно изменить скорость сетевой карточки до 100Mb/s в случае, если там стояла другая скорость. Смотрим, что получилось:

Показал просто для примера, вряд ли кому-то понадобится уменьшать скорость. Чаще нужно выполнить обратное преобразование. У меня была ситуация, когда сетевая карта упорно не хотела работать на скорость 1Gb, хотя поддерживала такую работу, и свитч был гигабитный. Долго бился и пробовал различные утилиты для изменения скорости. Оказалось, что патч корд был 4-х жильный из комплекта какого-то роутера. Им воспользовались для подключения и даже не обратили внимание на то, что он не поддерживает работу по гигабиту.

У утилиты ethtool много параметров, с помощью которых можно настроить сетевую карту. Пример этих параметров можно посмотреть на сайте redhat.

Работа с утилитой ifconfig

В завершении сетевых настроек хотел немного поговорить об ifconfig. Ранее я упомянул, что более современным средством для настройки сети является утилита ip. В последних релизеах Debian и CentOS ifconfig вообще исключили из базовой установки, ее приходится устанавливать отдельно. IP объединяет в себе два функционала — настройка сетевых интерфейсов и маршрутизации. То есть по сути она заменяет ifconfig + route. В ней реализован функционал обоих программ.

Сам я привык к ifconfig, так как она есть не только в linux, но и в freebsd. Удобно использовать одно и то же средство во всех дистрибутивах. Но последнее время переучиваюсь на ip, так как надо идти в ногу со временем. Тенденция такова, что ip будут продвигать все сильнее и сильнее в силу его большей новизны и, наверное, удобства. Что касается удобства, лично я ничего не могу сказать, мне совершенно все равно, какую команду использовать:

ip addr add 192.168.1.35/24 dev eth0

или

ifconfig eth0 192.168.1.35 netmask 255.255.255.0

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

ip route add 192.168.100.0/24 dev eth2

или

route add -net 192.168.100.0/24 dev eth2

В случае с ip мы работаем с одной командой, а не двумя. Чем пользоваться вам, выбирайте сами. Если не привыкли к чему-то конкретному, рекомендую использовать ip. Мне было бы любопытно узнать, кто, что использует. Оставьте свой комментарий на эту тему.

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

Часто задаваемые вопросы по теме статьи (FAQ)

Есть ли принципиальное отличие в том, как задать hostname сервера?

В целом, нет. Вы можете как отредактировать файл hostname, так и воспользоваться утилитой hostnamectl. Единственное, напомню, что нужно не забыть проверить файл hosts и изменить имя сервера в том числе и там.Зачем отключать ipv6 в на сервере Debian?

Отключать ipv6 или нет, решать вам. Я придерживаюсь следующего принципа в настройке серверов — отключать или удалять все то, что не используется. Это уменьшает вероятность получить баг или уязвимость в компоненте.Почему команда ifconfig во многих дистрибутивах объявлена deprecated и отсутствует в системе?

В этом статусе она находится последние лет 10 и тем не менее продолжает использоваться. Насколько я понимаю, заменившая ifconfig команда ip является более функциональная и заменяет сразу несколько старых сетевых утилит, таких как ifconfig, netstat, route и т.д. Отказ от ifconfig в пользу ip — попытка внедрить универсальную и самодостаточную утилиту для работы с сетью.Как настроить proxy в Debian?

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

Сообщение Как настроить сетевые параметры в Debian появились сначала на Clip-Clap.

Введение

Любая работа с сервером после установки чаще всего начинается со стандартных обязательных действий, без которых либо не получится продвинуться дальше, либо будет неудобно работать. Например, вам в любом случае необходимо выполнить сетевые настройки, желательно обновить систему и установить часовой пояс. Рекомендуется сразу настроить автообновление времени, подрихтовать параметры sshd, установить midnight commander и выполнить другие настройки.

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

Указываем сетевые параметры

Итак, у нас в наличии только что установленная система. Узнать или проверить ее версию можно командами:

# uname -a
Linux debian10 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64 GNU/Linux

# lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 10 (buster)
Release:	10
Codename:	buster

Для настройки сети, необходимо отредактировать файл /etc/network/interfaces. Сделаем это:

# nano /etc/network/interfaces

Для получения IP адреса по dhcp достаточно будет следующего содержания:

allow-hotplug eth0
iface eth0 inet dhcp

Если у вас статический адрес, то его настроить можно следующими параметрами в файле:

allow-hotplug eth0
iface eth0 inet static
address 192.168.1.24
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 192.168.1.1

Сохраняем файл. Теперь нужно выполнить перезапуск сети. В Debian это делается командой:

# systemctl restart networking.service

В системном логе /var/log/syslog при этом будут записи:

debian10 systemd[1]: Stopping Raise network interfaces...
debian10 systemd[1]: networking.service: Succeeded.
debian10 systemd[1]: Stopped Raise network interfaces.
debian10 systemd[1]: Starting Raise network interfaces...
debian10 systemd[1]: Started Raise network interfaces.

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

К сетевым настройкам я отношу установку пакета net-tools, в состав которого входят старые и привычные утилиты для работы с сетью — ifconfig, netstat, route и другие. В современных дистрибутивах их заменили одной командой ip, но лично мне вывод некоторых старых команд, конкретно, netstat, нравится больше, поэтому я иногда ими тоже пользуюсь.

# apt install net-tools

На этом настройка сети закончена.

Обновление системы, отличие apt upgrade от dist-upgrade и full-upgrade

Сеть настроили, теперь можно обновить систему и пакеты. В Debian это делается достаточно просто. Воспользуемся несколькими командами. Сначала обновим локальный индекс пакетов до последних изменений в репозиториях:

# apt update

Посмотреть список пакетов, готовых к обновлению, можно с помощью команды:

# apt list – upgradable

Теперь выполним простое обновление всех пакетов системы:

# apt upgrade

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

Ключ dist-upgrade или full-upgrade (это одно и то же) в дополнение к upgrade обрабатывает все изменения зависимостей для новых пакетов и во время работы может удалять ненужные и ставить необходимые пакеты для обновления. Вот выдержка из документации по поводу этих двух ключей.

Так что после обычного обновления, делаем еще full-upgrade.

# apt full-upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  dh-python guile-2.0-libs libbind9-140 libdns162 libicu57 libisc160 libisccc140 libisccfg140 liblvm2app2.2 liblvm2cmd2.02 liblwres141 libperl5.24
  libpython3.5-minimal libpython3.5-stdlib linux-image-4.9.0-3-amd64 python3-distutils python3-lib2to3 python3.5 python3.5-minimal rename sgml-base tcpd
  xml-core
Use 'apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

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

# apt autoremove

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

На этом обновление системы закончено. Если вы хотите обновить версию релиза, например Debian 9 обновить до Debian 10 Buster

Настройка ssh

Теперь внесем некоторые изменения в настройки сервера ssh. Я рекомендую его запускать на нестандартном порту для исключения лишних общений с ботами, которые регулярно сканируют интернет и подбирают пароли пользователей по словарям.

Существует расхожее мнение, что менять порт ssh это наивность, а не защита. Надо просто настроить сертификаты, fail2ban или еще каким-то образом защитить ssh порт, к примеру, с помощью ограничений iptables, и т.д. Тем не менее, я все же рекомендую порт сменить на нестандартный. Даже если у вас все защищено от подбора паролей, так как вы используете сертификаты, лишние запросы к ssh порту тратят ресурсы сервера, хоть и не очень большие. Идет установка соединения, обмен рукопожатиями и т.д. Зачем вам это нужно?

По-умолчанию в Debian, впрочем как и в любом другом дистрибутиве Linux, ssh сервер работает на 22 порту. Изменим этот порт, к примеру, на 23331. Так же я еще изменяю конфигурацию для разрешения подключения по ssh пользователя root с использованием пароля. В Debian из коробки пользователь root по ssh паролем авторизовываться не может. Изменим и это. Открываем файл настроек:

# nano /etc/ssh/sshd_config

И изменяем там следующие строки. Приводим их к виду:

Port 23331
PermitRootLogin yes

Сохраняем изменения и перезапускаем сервер ssh следующей командой:

# service sshd restart

Проверяем изменения:

# netstat -tulnp | grep ssh

tcp 0 0 0.0.0.0:23331 0.0.0.0:* LISTEN 925/sshd
tcp6 0 0 :::23331 :::* LISTEN 925/sshd

Все в порядке, сервер слушает 23331 порт. Теперь новое подключение будет осуществлено только по порту 23331. При этом, после перезапуска ssh, старое подключение не будет разорвано.

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

Отдельно тему подключения к серверу под root я рассмотрел в статье про sudo. Кому интересно, переходите в нее и делитесь своим мнением на этот счет.

Установка утилит mc, htop, iftop

Следующим шагом я настраиваю некоторые полезные утилиты, которыми регулярно пользуюсь в повседневной работе. Первая из них это всем известный двухпанельный файловый менеджер Midnight Commander. Установим mc на наш сервер:

# apt install mc

И сразу же для него включаю подсветку синтаксиса всех файлов, которые не обозначены явно в файле /usr/share/mc/syntax/Syntax синтаксисом для sh и bash скриптов. Этот универсальный синтаксис нормально подходит для конфигурационных файлов, с которыми чаще всего приходится работать на сервере. Перезаписываем файл unknown.syntax. Именно этот шаблон будет применяться к .conf и .cf файлам, так как к ним явно не привязано никакого синтаксиса.

# cp /usr/share/mc/syntax/sh.syntax /usr/share/mc/syntax/unknown.syntax

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

# select-editor

Select an editor. To change later, run 'select-editor'.
 1. /bin/nano <-- – easiest
 2. /usr/bin/mcedit
 3. /usr/bin/vim.tiny

Choose 1-3 [1]: 2

Так же я рекомендую очень удобный диспетчер задач — htop. Мне он помог, к примеру, решить проблему Взлома сервера CentOS. Ставим его на сервер:

# apt install htop

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

# apt install iftop

Настройка и обновление времени в Debian 

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

Узнать дату, время, часовой пояс можно командой date:

# date

Mon 12 Aug 2019 02:29:03 PM MSK

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

# apt install tzdata

Теперь выберем правильный часовой пояс с помощью команды:

# dpkg-reconfigure tzdata

Выбирая соответствующие пункты визарда, указываете свой часовой пояс.

Дальше синхронизируем время с сервером времени в интернете. Для разовой или ручной синхронизации понадобится отдельная утилита. Установим ntpdate на сервер:

# apt install ntpdate

И синхронизируем время:

# ntpdate-debian

12 Aug 14:30:21 ntpdate[8688]: adjust time server 89.109.251.21 offset 0.004529 sec

Если получаете ошибку:

12 Aug 14:30:21 ntpdate[8688]: the NTP socket is in use, exiting

Значит у вас уже работает служба ntp. Ее нужно остановить и обновить время вручную. Хотя если она работает, то у вас и так должно быть все в порядке.

Для того, чтобы время автоматически синхронизировалось без вашего участия с определенной периодичностью, используется инструмент ntp. Установим его:

# apt install ntp

После установки он сам запустится и будет автоматически синхронизировать часы сервера. Проверим, запустился ли сервис ntpd:

# netstat -tulnp | grep ntp

udp        0      0 10.20.1.16:123          0.0.0.0:*                           8855/ntpd           
udp        0      0 127.0.0.1:123           0.0.0.0:*                           8855/ntpd           
udp        0      0 0.0.0.0:123             0.0.0.0:*                           8855/ntpd           
udp6       0      0 fe80::cce1:23ff:fe4:123 :::*                                8855/ntpd           
udp6       0      0 ::1:123                 :::*                                8855/ntpd           
udp6       0      0 :::123                  :::*                                8855/ntpd

Настройка firewall (iptables) в Debian

В качестве firewall в Debian по-умолчанию используется iptables, его и будем настраивать. Изначально фаервол полностью открыт и пропускает весь трафик. Проверить список правил iptables можно следующей командой:

# iptables -L -v -n

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Обращаю пристальное внимание на то, что настраивать firewall без прямого доступа к консоли сервера не следует. Особенно, если вы не очень разбираетесь в этом и копируете команды с сайта. Шанс ошибиться очень высок. Вы просто потеряете удаленный доступ к серверу.

Создадим файл с правилами iptables:

# mcedit /etc/iptables.sh

Очень подробно вопрос настройки iptables я рассмотрел отдельно, рекомендую ознакомиться. Хотя в примере другая ОС linux, принципиальной разницы нет, настройки iptables абсолютно одинаковые, так как правила одни и те же.

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

#!/bin/bash
#
# Объявление переменных
export IPT="iptables"

# Активный сетевой интерфейс
export WAN=ens18
export WAN_IP=10.20.1.16

# Очистка всех цепочек iptables
$IPT -F
$IPT -F -t nat
$IPT -F -t mangle
$IPT -X
$IPT -t nat -X
$IPT -t mangle -X

# Установим политики по умолчанию для трафика, не соответствующего ни одному из правил
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP

# разрешаем локальный траффик для loopback
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT

# разрешаем пинги
$IPT -A INPUT -p icmp – icmp-type echo-reply -j ACCEPT
$IPT -A INPUT -p icmp – icmp-type destination-unreachable -j ACCEPT
$IPT -A INPUT -p icmp – icmp-type time-exceeded -j ACCEPT
$IPT -A INPUT -p icmp – icmp-type echo-request -j ACCEPT

# Разрешаем исходящие соединения самого сервера
$IPT -A OUTPUT -o $WAN -j ACCEPT

# Состояние ESTABLISHED говорит о том, что это не первый пакет в соединении.
# Пропускать все уже инициированные соединения, а также дочерние от них
$IPT -A INPUT -p all -m state – state ESTABLISHED,RELATED -j ACCEPT
# Пропускать новые, а так же уже инициированные и их дочерние соединения
$IPT -A OUTPUT -p all -m state – state ESTABLISHED,RELATED -j ACCEPT
# Разрешить форвардинг для уже инициированных и их дочерних соединений
$IPT -A FORWARD -p all -m state – state ESTABLISHED,RELATED -j ACCEPT

# Включаем фрагментацию пакетов. Необходимо из-за разных значений MTU
$IPT -I FORWARD -p tcp – tcp-flags SYN,RST SYN -j TCPMSS – clamp-mss-to-pmtu

# Отбрасывать все пакеты, которые не могут быть идентифицированы
# и поэтому не могут иметь определенного статуса.
$IPT -A INPUT -m state – state INVALID -j DROP
$IPT -A FORWARD -m state – state INVALID -j DROP

# Приводит к связыванию системных ресурсов, так что реальный
# обмен данными становится не возможным, обрубаем
$IPT -A INPUT -p tcp ! – syn -m state – state NEW -j DROP
$IPT -A OUTPUT -p tcp ! – syn -m state – state NEW -j DROP

# Открываем порт для ssh (!!!не забудьте указать свой порт, который вы изменили ранее!!!)
$IPT -A INPUT -i $WAN -p tcp – dport 22 -j ACCEPT
# Открываем порт для web сервера
$IPT -A INPUT -i $WAN -p tcp – dport 80 -j ACCEPT
$IPT -A INPUT -i $WAN -p tcp – dport 443 -j ACCEPT

# Записываем правила в файл
/sbin/iptables-save > /etc/iptables_rules

Даем файлу права на запуск:

# chmod 0740 /etc/iptables.sh

Запускаем скрипт:

sh /etc/iptables.sh

Проверяем правила:

# iptables -L -v -n

Проверяем, что правила записались в файл /etc/iptables_rules. Если их там нет, то записываем их вручную.

# /sbin/iptables-save > /etc/iptables_rules

Правила применились и произошла их запись в файл /etc/iptables_rules. Теперь нужно сделать так, чтобы они применялись при загрузке сервера. Для этого делаем следующее. Открываем файл /etc/network/interfaces и добавляем в него строку pre-up iptables-restore < /etc/iptables_rules Должно получиться вот так:

# cat /etc/network/interfaces

allow-hotplug eth0
iface eth0 inet dhcp
pre-up iptables-restore < /etc/iptables_rules

Для проверки перезагрузите сервер и посмотрите правила iptables. Должен загрузиться настроенный набор правил из файла /etc/iptables_rules.

Настройка логов cron

По-умолчанию, в Debian нет отдельного лог файла для событий cron, они все сыпятся в общий лог /var/log/syslog. Лично мне это не очень нравится, я предпочитаю выводить эти события в отдельный файл. Об этом я написал отдельно — вывести логи cron в отдельный файл.

Установка и настройка screen

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

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

Позже я решил подробнее ознакомиться с этим инструментом и обнаружил, что там есть несколько удобных моментов, которые можно использовать в ежедневной работе. Вот как использую утилиту screen я. При подключении к серверу у меня запускается screen с тремя окнами 1, 2, 3. Первое окно автоматически переходит в каталог /, второе в /etc, третье в /var/log. Я осмысленно назвал эти окна: Main, etc, logs соответственно. Внизу находится строка состояния, в которой отображен список всех открытых окон и подсвечено активное окно.

С помощью горячих клавиш я очень быстро переключаюсь между окнами в случае необходимости. Вот как выглядит мое рабочее окно ssh подключения:

Переключаюсь между окнами с помощью стандартных горячих клавиш screen: ctrl+a 1,  ctrl+a 2, ctrl+a 3. Я специально изменил нумерацию, чтобы она начиналась не с 0 по-дефолту, а с 1. Так удобнее на клавиатуре переключать окна. Кнопка 0 находится слишком далеко от 1 и 2.

Чтобы настроить такую же работу screen, как у меня, достаточно выполнить несколько простых действий. Сначала устанавливаем screen:

# apt install screen

Создаем в каталоге /root конфигурационный файл .screenrc следующего содержания:

# mcedit /root/.screenrc

#Выводим строку состояния
hardstatus alwayslastline "%-Lw%{= BW}%50>%n%f* %t%{-}%+Lw%<"

# Добавляем некоторые настройки
startup_message off
defscrollback 1000
defutf8 on
shell -$SHELL

# Создаем несколько окон
chdir
screen -t Main 1
chdir /etc
screen -t etc 2
chdir /var/log
screen -t logs 3

# Активное первое окно после запуска
select 1

Для знакомства с настройками, горячими клавишами и вариантами применения утилиты screen можно по адресу http://itman.in/ssh-screen/ Мне помог этот материал. Написано кратко, по делу и доходчиво.

Заключение

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

Сообщение Базовая настройка сервера Debian после установки появились сначала на Clip-Clap.

Цели статьи

1. Показать, как смотреть и настраивать системное время в Debian.
2. Рассказать, как управлять часовыми поясами.
3. Настроить автоматическую синхронизацию времени через интернет.
4. Показать настройку своего ntp сервера в информационной системе.

Введение

Во время установки Debian, сервер автоматически настраивает системное время на основе информации из bios. Инсталлятор предлагает вам выбрать только часовой пояс. При этом, если вы не правильно указали часовой пояс (timezone), его без проблем можно изменить после установки.

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

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

• Точное время на сервере необходимо для корректного логирования всех событий и последующего расследования инцидентов. Более того, одинаковое время должно быть на всех серверах, которые участвуют в работе информационной системы. Если это не так, то расследование инцидентов становится затруднительным.
• В доменной середе Windows для корректной работы протокола аутентификации Kerberos требуется примерно одинаковое время на всех участниках домена. Если ваш сервер Debian является членом домена, важно, чтобы его время не сильно отличалось от времени контроллера домена. Его нужно обязательно синхронизировать с ним.
• На сервере может располагаться какой-то сервис, который взаимодействует с пользователями. Например, новостной сайт, где в статьях указано точное время публикации. Если неправильно настроить часы или timezone, может возникнуть ситуация, когда для некоторых пользователей опубликованные материалы будут отображаться со временем из будущего.
• Планировщик cron в своей работе использует системные часы. Если вы хотите предсказуемое поведение запланированных задач, время и часовой пояс должны быть настроены правильно.

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

Как посмотреть и узнать системное время

Начнем с самого простого — подключимся к серверу по ssh и посмотрим в консоли на текущее время. Сделать это можно с помощью простой команды date.

# date
Wed 21 Aug 2019 03:38:12 PM MSK

Как вы видите, у нас установлен часовой пояс MSK, текущая дата и время в 12-ти часовом формате. Это не очень удобно. Если вам нужно посмотреть время в 24-х часовом формате, добавьте отображение +%R к date.

# date +%R
16:04

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

# date +%Y-%m-%d
2019-08-21
# date +%H-%M-%S
16-09-47
# date +%Y-%m-%d_%H-%M-%S
2019-08-21_16-09-50

Также есть еще один способ получить полную информацию о времени сервера Debian — воспользоваться командой timedatectl.

# timedatectl status

Установка и настройка времени в Debian

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

# date 08211555

Здесь 08 — месяц, 21 — число, 15 — час, 55 — минуты. Таким образом, формат команды получился вот такой — date MMDDhhmm.

То же самое, только через timedatectl.

# timedatectl set-time "2019-08-21 15:55:00"

Если вы получили ошибку — Failed to set time: Automatic time synchronization is enabled, значит у вас уже настроено автоматическое обновление времени. Об этом подробнее мы поговорим ниже. В таком случае timedatectl, в отличие от date, время менять не будет.

С помощью команды date так же можно посмотреть текущее время системы без учета часового пояса, то есть время по UTC.

# date – utc
Wed 21 Aug 2019 12:56:57 PM UTC

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

Установка, настройка и изменение часового пояса

Выше я рассказал, как узнать, в каком часовом поясе находятся системные часы сервера debian. В моем случае timezone установлена как MSK, то есть московский часовой пояс. Если у вас указан другой часовой пояс, а вы, к примеру, хотите установить московский, то делается это просто. Смена часового пояса выполняется через timedatectl:

# timedatectl set-timezone Europe/Moscow

Посмотреть список всех timezоne, доступных для установки на сервере, можно командой:

# timedatectl list-timezones

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

# apt update && apt upgrade tzdata

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

Timedatectl для настройки времени в Debian

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

Тут важно понимать, что systemd-timesyncd не может работать в качестве сервера времени, который мы настроим ниже. Так что, если у вас одиночный сервер, вам вполне подойдет timesyncd. Если же вы хотите использовать свой сервер времени, то надо настраивать ntp.

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

# timedatectl

Синхронизация времени уже включена и работает через timesyncd. Посмотрим ее статус.

# timedatectl timesync-status
       Server: 195.3.254.2 (2.debian.pool.ntp.org)
Poll interval: 17min 4s (min: 32s; max 34min 8s)
         Leap: normal
      Version: 4
      Stratum: 2
    Reference: C23ACA94
    Precision: 2us (-19)
Root distance: 42.113ms (max: 5s)
       Offset: -8.977ms
        Delay: 63.598ms
       Jitter: 9.582937s
 Packet count: 19
    Frequency: +7.550ppm

В принципе, больше ничего делать не нужно. Синхронизация времени через интернет уже настроена и работает. Время обновляется с сервера 2.debian.pool.ntp.org. Для надежности, можно убедиться, что служба работает, плюс, добавим ее сразу в автозагрузку, если ее там нет.

# systemctl status systemd-timesyncd
# systemctl enable systemd-timesyncd

Список серверов для синхронизации времени в timedatectl настраивается в конфигурационном файле /etc/systemd/timesyncd.conf.

Синхронизация времени с помощью ntp и ntpdate

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

# systemctl stop systemd-timesyncd
# systemctl disable systemd-timesyncd

Проверяем.

# timedatectl

Покажу теперь простую утилиту ntpdate, с помощью которой можно разово синхронизировать время, не автоматически. Для начала ее нужно установить в систему.

# apt install ntpdate

Дальше запускаем для разовой синхронизации.

# ntpdate pool.ntp.org
ntpdate[5621]: adjust time server 85.21.78.91 offset -0.020548 sec

В данном случае pool.ntp.org — адрес сервера времени. Можно использовать любой. Все, время синхронизировано и никаких автоматических служб не запущено.

Если у вас ntpdate выдает ошибку — the NTP socket is in use, exiting, значит у вас уже установлена и запущена служба ntp, которая заняла udp порт 123, необходимый для работы ntpdate. Установкой и настройкой этой службы мы и займемся далее.

Для обновления времени сервера можно воспользоваться службой ntp. Ее так же надо установить отдельно.

# apt install ntp

Это старая проверенная служба времени, которую использовали еще задолго до появления systemd и его юнитов. Запустим ее и добавим в автозагрузку.

# systemctl start ntp
# systemctl enable ntp

После запуска она сразу же автоматически синхронизирует время. Проверим статус службы ntp в Debian.

# systemctl status ntp

Синхронизация времени через ntp заработала сразу же. Дополнительная настройка не нужна, если вас не интересует свой сервер времени, который мы настроим ниже.

При этом, для проверки статуса службы времени ntp можно использовать утилиту ntpq. Посмотрим статус синхронизации.

# ntpq -p

Поясню значения каждого столбца.

Настройка сервера ntp в Debian

Теперь настроим свой сервер времени, с которого другие наши сервера смогут синхронизировать свои часы. Сервер времени ntp использует отдельный одноименный протокол — Network Time Protocol, который для работы использует UDP порт 123. Перед установкой и настройкой службы времени убедитесь, что на фаерволе открыт этот порт.

Файл конфигурации ntp — /etc/ntp.conf. Привожу минимальную достаточную конфигурацию для своего сервера времени.

driftfile /var/lib/ntp/ntp.drift
restrict -4 default kod notrap nomodify nopeer noquery limited
restrict 127.0.0.1
restrict 192.168.155.0 mask 255.255.255.0 nomodify notrap

pool 0.debian.pool.ntp.org iburst
pool 1.debian.pool.ntp.org iburst
pool 2.debian.pool.ntp.org iburst
pool 3.debian.pool.ntp.org iburst

logfile /var/log/ntp.log

Так же я обычно отключаю ipv6 протокол, если он не используется. Для этого в файле /etc/default/ntp заменяем параметр на

NTPD_OPTS='-4 -g'

После изменения конфигурации, перезапустим ntp и проверим статус службы.

# systemctl restart ntp
# systemctl status ntp

Теперь убедимся, что она запущена.

# ss -tulnp | grep ntp
udp    UNCONN   0        0          192.168.155.102:123           0.0.0.0:*      users:(("ntpd",pid=6185,fd=18))                                                
udp    UNCONN   0        0                127.0.0.1:123           0.0.0.0:*      users:(("ntpd",pid=6185,fd=17))                                                
udp    UNCONN   0        0                  0.0.0.0:123           0.0.0.0:*      users:(("ntpd",pid=6185,fd=16))                                             

Все в порядке, служба ntp запущена и готова принимать подключения. Для примера синхронизирую время одной из windows машин с нашим сервером времени.

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

Если в логе /var/log/ntp.log увидите сообщение — kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized, не обращайте внимание. Это не ошибка, а информационное сообщение, говорящее о том, что в момент запуска ntp ядро еще не синхронизировало свое время.

Заключение

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

Я показал как устанавливать время, изменять часовой пояс, разово синхронизировать время с помощью ntpdate и настраивать сервер времени ntpd в локальной сети.

Сообщение Как установить, изменить время и часовой пояс (timezone) в Debian появились сначала на Clip-Clap.