Записки IT специалиста

Подписка на Лента Записки IT специалиста Записки IT специалиста
Технический блог специалистов ООО"Интерфейс"
Обновлено: 9 часов 30 минут назад

Настройка двух и более OpenVPN-серверов на одном сервере

вс, 10/13/2019 - 22:54

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

Начнем с постановки задачи. В прошлой статье мы рассказали о настройке OpenVPN сервера в Oracle Cloud для доступа в интернет. Сервер работает, клиенты подключаются, но возникла необходимость подключения к нему роутеров Mikrotik, у которых, как известно, особые требования к настройкам OpenVPN. Как быть? Перенастроить сервер для совместимости с Mikrotik в ущерб остальным клиентам? Или поднять второй экземпляр сервера со своими настройками? Естественно, второй способ выглядит более предпочтительно.

Напомним, что все настройки мы производим на сервере с Ubuntu 18.04 в облаке от Oracle, настройка которого описана в статье по ссылке выше, рекомендуем ознакомиться с ней перед прочтением данного руководства. Однако все описанные ниже действия, с соответствующими поправками, применимы к любому Linux-дистрибутиву.

Настройка второго экземпляра сервера

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

cd /etc/openvpn/easy-rsa
source ./vars

После чего создадим новый серверный сертификат:

./build-key-server server-tcp

Где server-tcp имя нашего экземпляра сервера. Мы советуем давать осмысленные имена, чтобы вам потом было понятно, что делает тот или иной экземпляр.

Скопируем ключ и сертификат в папку с ключами OpenVPN:

cd /etc/openvpn/easy-rsa/keys
cp server-tcp.crt server-tcp.key /etc/openvpn/keys

Затем скопируем шаблон конфигурации и назовем его server-tcp.conf:

cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf /etc/openvpn/server-tcp.conf

После чего откроем файл и приступим к его редактированию. Какие важные особенности нам нужно учесть? RouterOS работает с OpenVPN только по протоколу TCP и не использует сжатие, также есть и некоторые иные особенности, которых мы коснемся позже. Все опции указаны в порядке их следования в файле, если опции нет - ее нужно добавить.

port 1194
proto tcp
dev tun

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

Укажем топологию сети:

topology subnet

И пути к ключам и сертификатам:

ca keys/ca.crt
cert keys/server-tcp.crt
key keys/server-tcp.key
dh keys/dh2048.pem

Диапазон адресов внутри VPN-сети также должен отличаться от остальных экземпляров, поэтому укажем:

server 10.89.0.0 255.255.255.0

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

ifconfig-pool-persist /var/log/openvpn/ipp-tcp.txt

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

push "redirect-gateway def1 bypass-dhcp"

Передадим собственные DNS:

push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"

Параметры проверки активности:

keepalive 10 120

Обязательно выключим дополнительную TLS-аутентификацию:

#tls-auth ta.key 0

И укажем параметры шифра, выключив его согласование, RouterOS поддерживает только AES128/192/256 и Blowfish 128:

ncp-disable
cipher AES-128-CBC

Обязательно отключаем все опции сжатия:

#compress lz4-v2
#push "compress lz4-v2"
#comp-lzo

Убеждаемся в наличии опций понижения прав:

user nobody
group nogroup

И за сохранение доступа к ключам и адаптерам:

persist-key
persist-tun

Укажем свой комплект файлов лога:

status /var/log/openvpn/openvpn-status-tcp.log
log /var/log/openvpn/openvpn-tcp.log

и его подробность:

verb 3

При использовании протокола TCP обязательно закомментируем опцию:

explicit-exit-notify 1

А также добавим:

tcp-nodelay

Сохраним файл конфигурации.

Чтобы обеспечить автоматический запуск всех серверных конфигураций OpenVPN откроем в /etc/default/openvpn и раскомментируем в нем строку:

AUTOSTART="all"

Затем перечитаем конфигурацию юнитов systemd:

systemctl daemon-reload

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

Настройка брандмауэра и маршрутизации

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

#!/bin/sh

# Включаем форвардинг пакетов
echo 1 > /proc/sys/net/ipv4/ip_forward

# Сбрасываем настройки брандмауэра
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X

# Разрешаем инициированные нами подключения извне
iptables -A INPUT -i ens3 -m state --state ESTABLISHED,RELATED -j ACCEPT

# Разрешаем подключения по SSH
iptables -A INPUT -i ens3 -p tcp --dport 22 -j ACCEPT

# Разрешаем подключения к OpenVPN
iptables -A INPUT -i ens3 -p udp --dport 1194 -j ACCEPT
iptables -A INPUT -i ens3 -p tcp --dport 1194 -j ACCEPT

#Запрещаем входящие извне
iptables -A INPUT -i ens3 -j DROP

# Разрешаем инициированные нами транзитные подключения извне
iptables -A FORWARD -i ens3 -o tun+ -m state --state ESTABLISHED,RELATED -j ACCEPT

# Запрещаем транзитный трафик извне
iptables -A FORWARD -i ens3 -o tun+ -j DROP

# Включаем маскарадинг для локальной сети
iptables -t nat -A POSTROUTING -o ens3 -s 10.88.0.0/24 -j MASQUERADE
iptables -t nat -A POSTROUTING -o ens3 -s 10.89.0.0/24 -j MASQUERADE

На что следует обратить внимание? Для каждого сервера нужно разрешающее правило в цепочке INPUT, в нашем случае в секции Разрешаем подключения к OpenVPN добавлено два правила для входящих UDP 1194 и TCP 1194. Аналогично следует создать для каждой VPN-сети свое правило маскарадинга в секции Включаем маскарадинг для локальной сети.

В правилах цепочки FORWARD мы заменили tun0 на tun+, что теперь распространяет действие правил на все туннельные интерфейсы.

Если вы используете Oracle Cloud, то не забудьте создать разрешающее правило для входящих TCP 1194 в настройках вашей виртуальной сети:

Теперь можно перезапустить службу OpenVPN и убедиться, что поднялись два туннельных интерфейса:

systemctl restart openvpn

Настройка клиентов OpenVPN

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

cd /etc/openvpn/easy-rsa
source ./vars

Затем выпустите сертификат клиента:

./build-key mikrotik

Полученные файлы и сертификат CA скопируем в домашнюю директорию:

cd /etc/openvpn/easy-rsa/keys
cp ca.crt mikrotik.crt mikrotik.key ~

И сменим их владельца на вашего основного пользователя, чтобы он мог спокойно скопировать их через FTP или SFTP (по умолчанию владелец файлов root). В нашем случае это пользователь ubuntu.

cd ~
chown ubuntu:ubuntu ca.crt mikrotik.crt mikrotik.key

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

proto tcp

и выключить сжатие:

#comp-lzo

Теперь что касается производительности. OpenVPN через TCP имеет гораздо более высокие накладные расходы, особенно на плохих каналах. На хороших разница обычно невелика, и вы скорее упретесь в иные ограничения. Мы выполнили два замера для нашего сервера в Oracle Cloud, первый для UDP:

Второй для TCP:

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

Настройка OpenVPN-сервера для доступа в интернет

вс, 10/13/2019 - 02:16

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

Кроме общественных сетей в последние годы стала приобретать повышенную актуальность проблема ограничения доступа к некоторым ресурсам исходя из географического расположения клиента. Это могут быть как ограничения регионального характера, например, популярный поставщик видеоконтента Netflix, так и блокировки со стороны органов власти, как яркий пример которых "ковровые блокировки" РКН в его борьбе с Телеграм, когда под ограничения попало большое количество совершенно легальных ресурсов.

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

Что нужно для создания собственного VPN-сервиса? Прежде всего потребуется VPS (виртуальный выделенный сервер) расположенный в регионе, из которого возможен неограниченный доступ к требуемым ресурсам. В большинстве случаев можно выбирать Европу или Штаты, но во втором случае задержки будут выше. На наш взгляд, выбирать Штаты имеет смысл, если вам требуется доступ к американским ресурсам, тому же Netflix или покупкам у американских продавцов на Amazon и Ebay.

Для поиска недорогих VPS можно воспользоваться специальными сайтами, такими как Low End Box или бесплатными предложениями от облачных провайдеров. Так у Amazon и Microsoft можно бесплатно получить виртуальную машину на год, а Oracle предлагает две VPS бесплатно и навсегда.

В нашем примере мы будем использовать бесплатный VPS от Oracle с Ubuntu 18.04, но данная инструкция подойдет для любых deb-based систем и с некоторыми поправками для любого другого Linux-дистрибутива.

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

Прежде всего установим OpenVPN и Easy-RSA для управления ключами:

apt install openvpn easy-rsa

Скопируем файлы easy-rsa в конфигурационную директорию OpenVPN и создадим символическую ссылку на файл настроек OpenSSL:

cp -r /usr/share/easy-rsa /etc/openvpn
ln -s /etc/openvpn/easy-rsa/openssl-1.0.0.cnf /etc/openvpn/easy-rsa/openssl.cnf

Затем откроем файл /etc/openvpn/easy-rsa/vars и изменим в нем следующие строки, указав собственные данные для сертификатов, например, так:

export KEY_COUNTRY="US"
export KEY_PROVINCE="Wild West"
export KEY_CITY="Uncle Tom's Cabins"
export KEY_ORG="Uncle Tom"
export KEY_EMAIL="tom@example.com"
export KEY_OU="Cabin"

Сохраним файл и перейдем к созданию собственного центра сертификации (CA). Для этого перейдем в директорию нашего CA и загрузим переменные:

cd /etc/openvpn/easy-rsa
source ./vars

Очистим любые имеющиеся данные и инициализируем центр сертификации:

./clean-all
./build-ca

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

После чего в директории /etc/openvpn/easy-rsa/keys появится сертификат CA, содержащий публичный ключ, ca.crt, который должен присутствовать на каждом VPN-клиенте, и закрытый ключ центра сертификации ca.key, этот файл является секретным и не должен покидать пределы сервера.

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

./build-dh

Данная операция, в зависимости от производительности вашего VPS, может занять достаточно много времени.

И, наконец, создадим ключевую пару для сервера:

./build-key-server server

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

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

mkdir /etc/openvpn/keys

Теперь скопируем туда необходимые серверу ключи и сертификаты:

cd /etc/openvpn/easy-rsa/keys
cp ca.crt dh2048.pem server.crt server.key /etc/openvpn/keys

Распакуем и скопируем в директорию /etc/openvpn шаблон серверной конфигурации:

gzip -d /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz
cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf /etc/openvpn

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

port 1194
proto udp
dev tun

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

Затем зададим топологию сети:

topology subnet

Укажем пути к ключам и сертификатам, допускаются относительные пути, в этом случае корнем будет считаться директория /etc/openvpn:

ca keys/ca.crt
cert keys/server.crt
key keys/server.key
dh keys/dh2048.pem

Зададим диапазон OpenVPN-сети:

server 10.88.0.0 255.255.255.0

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

ifconfig-pool-persist /var/log/openvpn/ipp.txt

Автоматически сконфигурируем клиентов на доступ в интернет через OpenVPN-подключение:

push "redirect-gateway def1 bypass-dhcp"

И передадим им собственные DNS-сервера:

push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"

Укажем параметры проверки активности:

keepalive 10 120

Сервер будет проверять клиента каждые 10 секунд и при отсутствии ответа через 120 секунд клиент будет считаться неактивным.

Обязательно закомментируйте строку:

#tls-auth ta.key 0

Для сценария доступа в интернет дополнительная TLS-аутентификация будет излишней.

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

ncp-disable
cipher AES-128-CBC

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

compress lz4-v2
push "compress lz4-v2"

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

Если у вас есть старые версии клиентов (ниже 2.4), то можно использовать простое lzo-сжатие, для этого закомментируйте вышеприведенные строки и добавьте:

comp-lzo

Эту опцию также потребуется добавить в конфигурационные файлы клиентов.

В целях безопасности понизим права запущенного сервера:

user nobody
group nogroup

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

persist-key
persist-tun

Укажем путь к файлам логов:

status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log

И укажем его подробность:

verb 3

Во время отладки можно поднять уровень логов до 5-6.

Настройка брандмауэра и маршрутизации

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

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

touch /etc/nat

и внесем в него следующие строки, обратите внимание на имя сетевого интерфейса вашего VPS, в нашем случае это ens3:

#!/bin/sh

# Включаем форвардинг пакетов
echo 1 > /proc/sys/net/ipv4/ip_forward

# Сбрасываем настройки брандмауэра
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X

# Разрешаем инициированные нами подключения извне
iptables -A INPUT -i ens3 -m state --state ESTABLISHED,RELATED -j ACCEPT

# Разрешаем подключения по SSH
iptables -A INPUT -i ens3 -p tcp --dport 22 -j ACCEPT

# Разрешаем подключения к OpenVPN
iptables -A INPUT -i ens3 -p udp --dport 1194 -j ACCEPT

#Запрещаем входящие извне
iptables -A INPUT -i ens3 -j DROP

# Разрешаем инициированные нами транзитные подключения извне
iptables -A FORWARD -i ens3 -o tun0 -m state --state ESTABLISHED,RELATED -j ACCEPT

# Запрещаем транзитный трафик извне
iptables -A FORWARD -i ens3 -o tun0 -j DROP

# Включаем маскарадинг для локальной сети
iptables -t nat -A POSTROUTING -o ens3 -s 10.88.0.0/24 -j MASQUERADE

Не забудем сделать файл исполняемым:

chmod +x /etc/nat

Данный файл требуется запускать после создания туннельного интерфейса tun0, поэтому откроем конфигурационный файл сервера OpenVPN /etc/openvpn/server.conf и в его конце добавим опцию:

up /etc/nat

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

ip a

Также проверим применение правил брандмауэра:

iptables -L -vn

Следующий шаг касается только виртуальных машин в облаке Oracle Cloud, вам потребуется дополнительно разрешить входящий трафик на порт OpenVPN. Для этого перейдите в Сети » Виртуальные облачные сети » VirtualCloudNetwork-20191008-0144 » Сведения о списках безопасности, где вместо VirtualCloudNetwork-20191008-0144 будет имя вашей виртуальной сети. Затем добавьте новое правило для входящего трафика:

Укажите: Тип источника - CIDR, Исходный CIDR - 0.0.0.0/0, IP-протокол - UDP, Диапазон исходных портов - Все, Диапазон конечных портов - 1194.

Настройка клиентов OpenVPN

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

cd /etc/openvpn/easy-rsa
source ./vars

Затем создадим ключевую пару клиента командой:

./build-key client

где client -имя клиента, мы также рекомендуем давать им осмысленные имена.

Теперь скопируем файлы, которые необходимо передать на компьютер клиента в домашнюю директорию и изменим их владельца (по умолчанию владелец - root), чтобы вы смогли их скопировать с помощью любого FTP или SFTP клиента. В нашем случае имя пользователя ubuntu:

cd /etc/openvpn/easy-rsa/keys
cp ca.crt client.crt client.key ~

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

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

cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf ~/client.ovpn

После чего скопируйте все эти файлы на клиент и установите на нем OpenVPN, в Windows системах советуем изменить путь установки OpenVPN на более короткий и без пробелов, скажем, C:\OpenVPN.

Затем откроем файл client.ovpn, который в Windows системах должен быть расположен в C:\OpenVPN\config, а в Linux в /etc/openvpn, и внесем в него следующие изменения:

client
dev tun
proto udp

Данные опции задают клиентский режим работы, тип туннеля и используемый протокол UDP.

Затем укажем адрес сервера:

remote 111.222.333.444 1194

Следующая опция предписывает клиенту постоянно разрешать имя OpenVPN-сервера, имеет смысл если мы указываем сервер по FQDN-имени, а не IP-адресу.

resolv-retry infinite

Для Linux систем обязательно укажите:

user nobody
group nogroup

В Windows данные опции следует обязательно закомментировать.

Проконтролируем наличие следующих опций:

persist-key
persist-tun

Укажем пути к ключам и сертификатам, для Linux систем подразумеваем их нахождение в /etc/openvpn/keys:

ca keys/ca.crt
cert keys/client.crt
key keys/client.key

Для Windows систем предположим их нахождение в C:\OpenVPN\keys:

ca C:\\OpenVPN\\keys\\ca.crt
cert C:\\OpenVPN\\keys\\client.crt
key C:\\OpenVPN\\keys\\client.key

Также обязательно закомментируем опцию:

#tls-auth ta.key 1

Включим защиту от атак типа "человек посередине":

remote-cert-tls server

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

cipher AES-128-CBC

Остальные опции можно оставить без изменений. Сохраним файл и запустим OpenVPN-клиент.

Убедиться, что вы выходите в интернет через VPN-канал можно при помощи любого сервиса, показывающего ваш IP-адрес, например, 2ip.ru:

Обращаем внимание на национальную принадлежность адреса, в данном случае мы выходим в интернет из Штатов.

Самое время провести замер скорости доступа, мы будем использовать для этого популярный сервис SpeedTest. Первый замер без VPN:

Второй через OpenVPN-канал:

Сразу обращаем внимание на выросший пинг - это последствия размещения сервера в Штатах, а также скорость скачивания не выше 10 Мбит/с - ограничение бесплатного тарифа Oracle, хотя в большинстве случаев этого вполне достаточно для комфортного серфинга.

Напоследок затронем еще один момент. Мы настроили сервер таким образом, что он автоматически конфигурирует клиента на доступ в интернет через OpenVPN-подключение, но бывают случаи, когда это не нужно. Допустим вы хотите пустить через VPN только некоторые ресурсы, а остальной доступ должен осуществляться через локального провайдера. В таком случае добавьте в конфигурационный файл клиента опцию:

route-nopull

После чего клиент будет игнорировать передаваемые с сервера опции маршрутизации и DHCP-опции, такие как DNS-сервера и т.п.

Oracle раздает бесплатные VPS навсегда

ср, 10/09/2019 - 11:19

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

В чем состоит суть данного предложения? Компания Oracle в рамках своего облачного сервиса предоставляет на условиях "бесплатно навсегда" ряд услуг, а именно:

  • 2 базы данных Oracle Autonomous Database, каждая с 1 OCPU (Oracle Cloud Processor Unit) и 20 ГБ хранилища;
  • 2 виртуальные машины (VPS) Compute VM, каждой выделено с 1/8 OCPU и 1 Гбайт оперативной памяти;
  • 2 блочных тома общей ёмкостью до 100 Гбайт, до 5 бесплатных резервных копий.

А также ряд дополнительных сервисов, таких как:

  • 10 Гбайт объектного облачного хранилища;
  • 10 Гбайт архивного хранилища;
  • 50 000 запросов API в месяц;
  • 1 балансировщик нагрузки с пропускной способностью 10 Мбит/с;
  • 10 Тбайт/месяц на передачу исходящих данных.

Данное предложение выглядит достаточно интересно. Для его получения следует просто зарегистрировать учетную запись в облачном сервисе Oracle по адресу: https://www.oracle.com/cloud/free/#always-free

Для успешной регистрации вам потребуется номер телефона и действующая банковская карта, с которой будет списан и сразу возвращен 1$ или 1€, если нужной суммы на карте не окажется, то регистрация будет невозможна. Виртуальные карты не принимаются, во всяком случае у нас не получилось зарегистрироваться, используя виртуальные карты ЯндексДеньги и Киви.

Также коллеги сообщают, что не на всех операторов приходят СМС, указывая на проблемы с Мегафоном, со своей стороны мы использовали МТС и ТЕЛЕ2 без каких-либо проблем.

Все регистрации проверяются вручную, это может занять от 3 дней до недели. Кроме того, следует соблюдать ряд условий:

  • IP-адрес должен соответствовать указанной при регистрации стране;
  • Телефон и банковская карта также должны быть этой страны.

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

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

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

А на страницах с отдельными услугами будут размещены дополнительные пояснения, например, для Блочных томов:

Вы можете бесплатно использовать в своем домене доступности 100 ГБ хранилища блочных томов. Сейчас вы используете 47 ГБ. Если вы будете использовать более 100 ГБ и не перейдете на платный тариф до окончания бесплатного пробного периода, ваши данные будут удалены.

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

Перейдем к наиболее интересной части предложения - виртуальным машинам. В настоящий момент 1/8 OCPU представляет два ядра от AMD EPYC 7551 32-Core Processor, что вместе с 1 ГБ оперативной памяти составляет, на первый взгляд, достаточно неплохую для бесплатного VPS конфигурацию.

Но тесты показывают, что чудес не бывает:

Processor: AMD EPYC 7551 32-Core Processor
CPU cores: 2
Frequency: 1996.242 MHz
RAM: 982M
Swap: -
Kernel: Linux 4.15.0-1025-oracle x86_64

CPU: SHA256-hashing 500 MB
10.869 seconds
CPU: bzip2-compressing 500 MB
19.393 seconds
CPU: AES-encrypting 500 MB
4.822 seconds

Для сравнения ниже приведен результат недорого VPS от европейского хостера HostEurope по тарифу Starter за 9,99 € в месяц:

Processor: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
CPU cores: 2
Frequency: 2596.785 MHz
RAM: 2,0G
Swap: 1,0G
Kernel: Linux 3.16.0-042stab134.8 x86_64

CPU: SHA256-hashing 500 MB
3.321 seconds
CPU: bzip2-compressing 500 MB
5.659 seconds
CPU: AES-encrypting 500 MB
1.612 seconds

Разница по производительности CPU примерно в три раза, т.е. от идеи поставить туда что-то ресурсоемкое, тот же Bitrix, можно сразу отказаться. Хотя производительность вполне достаточна для простых задач и примерно соответствует совсем бюджетным VPS за 2-3$ в месяц.

Но есть еще один момент, который вносит существенные ограничения по применению бесплатных серверов, это скорость доступа к дисковой подсистеме:

ioping: seek rate
min/avg/max/mdev = 418.0 us / 601.2 us / 3.94 ms / 151.8 us
ioping: sequential read speed
generated 1.18 k requests in 5.00 s, 294 MiB, 235 iops, 58.8 MiB/s

dd: sequential write speed
1st run: 48.83 MiB/s
2nd run: 49.02 MiB/s
3rd run: 49.11 MiB/s
average: 48.99 MiB/s

50 МБ/с - это скорость даже не захудалого ноутбучного HDD, а скорее неплохой флешки. Любая сколь-нибудь серьезная нагрузка на сервер упрется в первую очередь в диски. Ну и "вишенка на торте" - пропускная способность сети:

IPv4 speedtests

Cachefly CDN: 5.79 MiB/s
Leaseweb (NL): 3.14 MiB/s
Softlayer DAL (US): 4.28 MiB/s
Online.net (FR): 5.71 MiB/s
OVH BHS (CA): 5.05 MiB/s

Да, всего лишь 5 МБ/с или примерно 42 Мбит/с. В общем Oracle сделало все, чтобы затруднить использование своих VPS в качестве хостинга.

Но неужели все так плохо? Ну как сказать... Для бесплатного предложения сервера достаточно неплохие, просто следует понимать, что Oracle не Дед Мороз и преследует вполне коммерческие цели, а данное предложение - возможность бесплатно ознакомиться с услугами и протестировать в облаке свои приложения.

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

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

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

Админу на заметку - 26. Как просматривать лог-файл в режиме реального времени в Windows и Linux

пн, 10/07/2019 - 01:30

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

Linux

В Linux подавляющее большинство логов являются обычным текстом, что делает работу с ними возможной при помощи широкого спектра утилит. Одна из них - это tail (англ. хвост), по умолчанию она выводит 10 последних строк указанного текстового файла. А еще она умеет выводить на экран последние строки по мере их добавления. Это как раз то, что нам нужно. Допустим мы хотим видеть в реальном времени лог доступа к сайту:

tail -f /var/log/apache2/access.log

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

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

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

А тем временем сделать правильно очень просто. Достаточно использовать приведенную выше команду и направить ее вывод в файл:

tail -f /var/log/apache2/access.log > ~/my_log.log

На экране теперь строки лога появляться не будут, они будут записаны в файл my_log.log в домашней директории. После чего выполните с системой необходимые действия, результат которых должен попасть в лог, прервите действие команды по Ctrl+C и можете смело описывать проблему коллегам, не забыв приложить полученный файл.

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

tail -f /var/log/apache2/access.log | grep 192.168.16.187 > ~/my_log.log

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

Windows

Системные логи Windows хранятся в Журналах событий, которые имеют специализированный формат и хранятся в файлах .evt и .evtx, которые просмотреть подобным образом не удастся, но логи многих системных служб и приложений используют простой текстовый формат, а следовательно дают возможность работать с ними интерактивно.

В качестве аналога команды tail используем один из командлетов PowerShell:

Get-Content C:\OpenVPN\log\openvpn.log -Wait

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

Get-Content C:\OpenVPN\log\openvpn.log -Wait -Tail 5

Точно также мы можем перенаправить вывод команды в файл:

Get-Content C:\OpenVPN\log\openvpn.log -Wait -Tail 5 > S:\my_log.log

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

Get-Content C:\OpenVPN\log\openvpn.log -Wait -Tail 100 | where { $_ -match "AUTH_FAILED"}

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

Настройка черного и белого списков в роутерах Mikrotik

вс, 10/06/2019 - 01:31

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

Прежде всего поговорим об особенностях фильтрации в условиях современного интернета. Основной тенденцией последних лет является массовый переход на протокол HTTPS. Что это означает? В отличие от HTTP, который передает данные открытым текстом, HTTPS использует SSL-шифрование и все, что мы можем увидеть для такого соединения - это домен назначения. Какие именно страницы посещает пользователь на указанном домене и какие данные оттуда передаются мы видеть не можем.

Из этого следует, что мы не можем блокировать отдельные страницы, но можем заблокировать домен целиком. Для большинства сценариев этого вполне достаточно. Но здесь нас подстерегает другая неприятность, многие сайты используют CDN (Content Delivery Network, сеть доставки контента), такие как CloudFlare и заблокировав нужный вам сайт вы можете также ограничить доступ к большому количеству сторонних ресурсов. Что из этого может выйти все мы видели во время ковровых блокировок РКН против Телеграм.

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

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

Создаем списки

Для настройки фильтрации нам понадобятся минимум два списка: список доменов и список пользователей. С доменами понятно, это те сайты, к которым мы хотим запретить доступ или, наоборот, разрешить. Создаются такие списки просто: IP - Firewall - Address Lists где добавляем новый адрес, в поле Name вписываем имя листа, если это первая запись, либо выбираем его из выпадающего списка. В поле Address указываем IP-адрес или доменное имя ресурса, при указании доменного имени в список будут внесены все IP-адреса сайта, и они будут обновляться с периодичностью указанной в TTL домена.

В нашем случае мы добавили домен yandex.ru в список WL (whitelist, белый список). Обратите внимание, что адреса www.example.com и example.com - это разные доменные имена, которые могут иметь разные IP-адреса (в целях балансировки нагрузки) и поэтому следует добавлять оба варианта (или проверять что между ними нет расхождений).

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

/ip firewall address-list
add address=yandex.ru list=WL

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

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

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

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

Но на практике адреса раздаются сервером DHCP, это не проблема, создаем резервирование IP-адреса, для чего следует перейти в IP - DHCP-Server - Leases и открыв запись нужного адреса нажать Make Static.

После чего закрываем и снова открываем запись и в поле Address List вводим, если это первая запись, или выбираем имя списка, куда будет добавлен IP-адрес данного компьютера, в нашем случае это список USER.

Либо через командную строку:

/ip dhcp-server lease
add address=192.168.186.199 address-lists=USER mac-address=00:0C:29:B4:D0:05 server=dhcp1

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

Черный список

Начнем с самого простого сценария - черного списка. Сначала настроим вариант, когда такой список применяется ко всем пользователям, кроме членов списка USER. Для этого перейдем в IP - Firewall - Filter Rules и создадим новое правило. На закладке General укажем Chain - forward и In. Interface - bridge1:

На закладке Advanced указываем Src. Address List - USER и ставим перед ним восклицательный знак (символ инверсии правила), что будет означать кроме входящих в группу. В поле Dst. Address List указываем BL - т.е. наш черный список доменов.

И наконец на закладке Action указываем действие, обычно везде в интернете указывают drop, хорошо, укажем и мы.

Данное правило должно располагаться самым первым в цепочке FORWARD, выше FastTrack.

Теперь попробуем посетить запрещенный сайт:

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

После замены действия при повторной попытке посетить ресурс мы сразу увидим сообщение о его недоступности:

Быстро добавить правило через командную строку можно так:

/ip firewall filter
add action=reject chain=forward dst-address-list=BL in-interface=bridge1 reject-with=icmp-network-unreachable src-address-list=!USER

Теперь немного изменим задачу, применим черный список только к группе USER. Для этого немного изменим условия на закладке Advanced, а именно укажем Src. Address List - USER без восклицательного знака, в итоге условие будет читаться как: если источник в группе USER и назначение в группе BL.

Или в командной строке:

/ip firewall filter
add action=reject chain=forward dst-address-list=BL in-interface=bridge1 reject-with=icmp-network-unreachable src-address-list=USER

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

Белые списки

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

Снова перейдем в IP - Firewall - Filter Rules и создадим новое правило. На закладке General также укажем Chain - forward и In. Interface - bridge1 , на Advanced указываем Src. Address List - !USER и Dst. Address List - !WL:

И на закладке Action указываем действие reject. Таким образом данное правило будет блокировать все соединения, если адрес отправителя не входит в группу USER и адрес назначения не входит в белый список WL.

Аналогичное действие через консоль:

/ip firewall filter
add action=reject chain=forward dst-address-list=!WL in-interface=bridge1 reject-with=icmp-network-unreachable src-address-list=!USER

Данное правило также следует располагать первым в цепочке FORWARD.

Добавим к разрешенным несколько адресов, в нашем случае yandex.ru и interface31.ru и попробуем открыть один их них. Яндекс открывается, но выглядит довольно непривычно.

Многие картинки, которые располагаются на иных серверах, включая сервера самого Яндекса, но имеющего другие IP-адреса просто не подгружаются. Хотя никаких фатальных последствий это не несет, как поисковик Яндекс работает. А вот в почту войти уже не получится, для этого придется разрешить как минимум mail.yandex.ru и passport.yandex.ru.

Теперь попробуем открыть наш сайт. А вот тут первый неприятный сюрприз:

Что это значит? Браузер не может проверить подлинность сертификата, а так как наш сайт использует HSTS, то доступ к нему будет невозможен, потому как подобные действия могут указывать на атаку с понижением степени защиты, чему HSTS должен препятствовать.

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

В нашем случае оказалось достаточно добавить узел ocsp.int-x3.letsencrypt.org, сайт загрузился, но без комментариев, так как они реализованы на стороннем ресурсе и разрешение доступа к нему не решило проблемы. В этом случае вам придется либо заниматься долгим и кропотливым выяснением необходимых для работы ресурсов и занесением их в белый список, либо отказываться от части функционала сайтов.

Чтобы применить белый список только к участникам группы немного изменим правило: в Adwanced указываем Src. Address List - USER, т.е. без восклицательного знака. Теперь логика правила изменится и будут блокироваться все соединения для группы USER, кроме тех, которые разрешены белым списком.

Либо в командной строке:

/ip firewall filter
add action=reject chain=forward dst-address-list=!WL in-interface=bridge1 reject-with=icmp-network-unreachable src-address-list=USER

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

Layer 7 protocol

Layer 7 protocol - это методика поиска определенных вхождений в ICMP/TCP/UDP потоках при помощи регулярных выражений. На первый взгляд достаточно интересная возможность, существенно расширяющая степень контроля над проходящим трафиком, но есть один существенный недостаток. Как уже понятно из названия, данный вид фильтрации работает на прикладном (L7) уровне, т.е. полностью обрабатывается CPU и даже при небольшом количестве правил способен создать сильную нагрузку на оборудование, особенно старые (не ARM) модели.

Использовать L7 для блокировки сайтов не рекомендуют сами разработчики Mikrotik, справедливо замечая, что в большинстве случаев это не будет работать так, как задумано, но при этом вы будете впустую растрачивать вычислительные ресурсы роутера. На наш взгляд использовать L7 для задач, связанных с доступом к сайтам вообще бессмысленно. Современный трафик в подавляющем большинстве шифрованный и различного рода конструкции для анализа URL просто не будут работать, а управлять доступом на основе доменного имени вполне можно и на L3 (чем мы занимались выше).

По этой же самой причине не будут работать многие размещенные в интернете инструкции, где трафик фильтровался по содержимому, типам файлов или потоков, использовал параметры запросов и т.д. и т.п. Хотя мы до сих пор встречаем статьи, в которых по L7 пытаются блокировать соцсети или Youtube, мотивируя это большим числом адресов, использованием CDN, поддоменов и т.д. и т.п. Однако все это не выдерживает никакой критики, соцсети и видеохостинги прекрасно блокируются по доменному имени.

Мы не рекомендуем использовать L7 во всех тех случаях, когда задачу можно решить иным образом, применяя его только для решения специфичных задач. Например, выявления и блокировки какого-либо вида трафика.

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

Где брать паттерны? Опытные пользователи могут запустить сетевой сканер (tcpdump, Wireshark) и проанализировать доступное содержимое пакетов и на основании полученной информации составить регулярное выражение. Либо воспользоваться сайтом l7-filter.sourceforge.net, однако большая часть паттернов оттуда работать не будет. Во-первых, сайт достаточно старый, последний раз обновлялся в 2009 году, во-вторых, очень многие протоколы перестали использоваться в открытом виде, а используют SSL-шифрование. В этом случае вы просто увидите SSL-поток, блокировать который бессмысленно, так как вы заблокируете практически весь интернет.

Для решения нашей задачи сначала перейдем в IP - Firewall - Layer 7 protocol и создадим новый фильтр: в поле Name напишем произвольное имя, в нашем случае SSH, а в поле Regexp внесем регулярное выражение паттерна:

^ssh-[12]\.[0-9]

Также можно выполнить команду в терминале:

/ip firewall layer7-protocol
add name=SSH regexp="^ssh-[12]\\.[0-9]"

Что делать дальше? Самое очевидное решение - использовать данный фильтр в правилах брандмауэра является примером того, как делать не надо. В этом случае через L7 фильтр будет проходить каждый пакет, что вызовет сильную нагрузку на CPU роутера.

Поэтому мы пойдем другим путем и на основании L7 фильтра будем маркировать соединения, которых гораздо меньше, чем пакетов. Перейдем в IP - Firewall - Mangle и создадим новое правило: на закладке General выставляем Chain - prerouting, Protocol - tcp и Сonnection Mark - no mark:

На закладке Advanced указываем использование созданного нами фильтра Layer 7 Protocol - SSH:

В Action указываем действие mark-connection, задаем марку соединения New Connection Mark - SSH-CONN и обязательно ставим флаг Passthrough для прохождения пакета далее по цепочке:

Затем добавим еще одно правило: General - Chain - prerouting, Protocol - tcp и Connection Mark - SSH-CONN:

А в действиях добавим mark packet, New Packet Mark - SSH-PCK и снимем флаг Passthrough:

Все тоже самое быстро делается в командной строке:

/ip firewall mangle
add action=mark-connection chain=prerouting connection-mark=no-mark layer7-protocol=SSH new-connection-mark=SSH-CONN passthrough=yes protocol=tcp
add action=mark-packet chain=prerouting connection-mark=SSH-CONN new-packet-mark=SSH-PCK passthrough=no protocol=tcp

Многие читатели не работают с брандмауэром дальше таблицы Filter, поэтому что, что мы сейчас сделали в Mangle может показаться им какой-то особой магией. Коротко поясним наши действия. Первое правило проверяет все немаркированные соединения и те из них, которые сосуществуют фильтру L7, т.е. SSH-соединения получают метку SSH-CONN и продолжают движение по цепочке. Следующее правило проверяет соединения и все пакеты соединений, промаркированных как SSH-CONN снабжает меткой SSH-PCK.

Таким образом мы пометили все пакеты, относящиеся к SSH-соединениям, но L7 фильтр мы используем только для соединений, не нагружая роутер проверкой каждого пакета. Теперь запретим транзит таких пакетов, для этого вернемся в IP - Firewall - Filter Rules и создадим правило, на закладке General которого укажем: Chain - forward, Рrotocol - tcp, In Interface - bridge1 и Packet Mark - SSH-PCK:

На закладке Action ставим действие drop. То же самое в консоли:

/ip firewall filter
add action=drop chain=forward in-interface=bridge1 packet-mark=SSH-PCK protocol=tcp

Ставим это правило также в начало цепочки FORWARD и если вы все сделали правильно, то установить SSH-соединение из вашей сети больше никому не удастся.

Следует понимать, что выше был лишь пример того, как можно использовать Layer 7 protocol на Mikrotik, в реальной ситуации следует несколько раз подумать и прибегать к возможностям L7 только тогда, когда все остальные варианты исчерпаны. Также старайтесь как можно более подробно описывать условия, для правил использующих L7 фильтры, чтобы максимально уменьшить нагрузку на процессор роутера.

Фильтрация по MAC-адресам

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

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

В тоже время MAC-адрес нам нужен для одной единственной цели - идентифицировать пользователя, что мы также можем сделать и по IP-адресу, для этого нам нужно будет преобразовать MAC в IP, который уже можно добавить в один из списков и использовать представленные нами выше правила. В этом нам снова поможет таблица Mangle.

Откроем IP - Firewall - Mangle и добавим правило, на закладке General укажем Chain - prerouting, In Interface - bridge1, на Advanced в поле Src. MAC Address укажем MAC-адрес нужного устройства.

И на закладке Action добавим действие add src to address list, где в поле Address List укажем требуемый список пользователей, в нашем случае USER, а в поле Timeout укажите требуемое время жизни записи, это нужно для того, чтобы запись обновилась при смене обладателем MAC IP-адреса. На скриншоте мы, в тестовых целях, использовали 5 секунд, в реальной жизни руководствуйтесь здравым смыслом и выбирайте более высокие значения.

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

/ip firewall mangle
add action=add-src-to-address-list address-list=USER address-list-timeout=5s chain=prerouting in-interface=bridge1 src-mac-address=00:0C:29:B9:FF:2E

Теперь первый пришедший с данного устройства пакет добавит его IP-адрес в указанный нами список, тем самым связав его с текущим MAC на время указанное в Timeout. Для каждого следующего устройства необходимо создать подобное правило, также не забывайте снабжать каждое из них комментарием, чтобы впоследствии вам и вашим коллегам было понятно о каком именно устройстве идет речь.

Заключение

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

Настраиваем сеть в Proxmox Virtual Environment

чт, 10/03/2019 - 02:01

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

Если обратиться к официальной документации, то там будет рассказано о двух основных сетевых конфигурациях: с использованием моста и маршрутизации. Приведенные примеры покрывают основные сценарии использования и не углубляются в подробности, но различные комбинации настроек для этих вариантов позволяют реализовывать самые разнообразные сетевые конфигурации. В данном материале мы рассмотрим базовые возможности Proxmox, не касаясь объединения сетевых адаптеров или использования Open vSwitch, потому как это отдельные темы, лежащие за рамками базовой настройки.

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

Внешняя сеть

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

В основе всех виртуальных сетей в Proxmoх лежит сетевой мост (Linux Bridge) - vmbr, допускается создание до 4095 таких устройств. Сетевой мост может включать в себя как физические, так и виртуальные адаптеры, выполняя для них роль неуправляемого коммутатора. Физическая сетевая карта, подключенная к мосту, не имеет настроек и используется как физический Ehternet-интерфейс для данного виртуального коммутатора. Все сетевые настройки производятся внутри виртуальных машин, которые через мост и физический адаптер прозрачно попадают во внешнюю сеть.

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

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

Фактически это сетевые настройки самого гипервизора. Обратите внимание, что сервера DNS указываются отдельно, в Система - DNS:

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

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

Внешняя изолированная сеть

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

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

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

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

Внутренняя сеть с NAT

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

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

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

Откроем именно interfaces.new и внесем в конец следующие строки:

post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up iptables -t nat -A POSTROUTING -s '192.168.34.0/24' -o ens33 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s '192.168.34.0/24' -o ens33 -j MASQUERADE

В качестве сети, в нашем случае 192.168.34.0/24, укажите выбранную вами сеть, а вместо интерфейса ens33 укажите тот сетевой интерфейс, который смотрит во внешнюю сеть с доступом в интернет. Если вы используете сетевую конфигурацию по умолчанию, то это будет не физический адаптер, а первый созданный мост vmbr0, как на скриншоте ниже:

Перезагрузим узел и назначим виртуальной машине или контейнеру созданную сеть (vmbr1), также выдадим ей адрес из этой сети, а шлюзом укажем адрес моста.

Не забудьте указать доступный адрес DNS-сервера и убедитесь, что виртуальная машина имеет выход в интернет через NAT.

Внутренняя сеть

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

Чтобы получить такую сеть, просто создайте еще один мост без привязки к адаптеру и назначьте ему IP-адрес из любой отличной от используемых сети.

Частная сеть

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

Для такой сети просто создайте еще один сетевой мост без каких-либо настроек:

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

Организуем службы DNS и DHCP для внутренних сетей

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

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

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

apt install dnsmasq

Затем перейдем в конфигурационный файл /etc/dnsmasq.conf и найдем и приведем к следующему виду параметры:

interface= vmbrl, vmbr2
listen-address= 127.0.0.1, 192.168.34.2, 192.168.35.2

Здесь мы явно указали интерфейсы и адреса, на которых будет работать наш сервер. С одной стороны, присутствует некоторая избыточность, но лучше так, чем потом, при изменении сетевых настроек в вашей сети неожиданно появится неавторизованный DHCP-сервер.

Затем укажем выдаваемые клиентам диапазоны адресов:

dhcp-range=interface:vmbr1,192.168.34.101,192.168.34.199,255.255.255.0,12h
dhcp-range=interface:vmbr2,192.168.35.101,192.168.35.199,255.255.255.0,12h

Обратите внимание на формат записи, перед каждой настройкой мы указываем сетевой интерфейс к которой она применяется.

Аналогичным образом зададим нужные DHCP-опции, в нашем случае это Option 3 и 6 (шлюз и DNS-сервер).

dhcp-option=interface:vmbr1,3,192.168.34.2
dhcp-option=interface:vmbr1,6,192.168.34.2
dhcp-option=interface:vmbr2,3
dhcp-option=interface:vmbr2,6

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

Сохраняем конфигурационный файл и перезапускаем службу

service dnsmasq restart

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

Настройка VPN-подключения в роутерах Mikrotik

пн, 09/30/2019 - 00:57

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

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

В рамках данной статьи мы будем рассматривать варианты настройки Mikrotik именно в качестве клиента для поддерживаемых типов VPN-серверов, оставив за кадром туннельные подключения (GRE, IP-IP, EoIP и т.д.). Для работы с этим типом соединений используется специальный раздел PPP, на закладке Interfaces которого можно добавить сетевой интерфейс для нужного типа VPN-клиента. Поддерживаются PPTP, L2TP, SSTP и OpenVPN подключения. Также в списке присутствуют устаревший PPP и PPPoE, который используется для организации доступа в интернет, в данном контексте эти протоколы интереса не представляют.

Также аналогичные действия можно выполнить и в разделе Interfaces, никакой разницы откуда вы будете добавлять сетевой интерфейс нет. Но не будем спешить и перейдем на закладку Profiles, где находятся профили используемые при коммутируемых подключениях. По умолчанию созданы два профиля: default и default-encryption, в которых содержатся некоторые настройки для подключения. Почему некоторые? Потому что большинство опций подключения задаются сервером и клиент должен применять именно их, иначе подключение будет невозможным. Поэтому если вы заглянете в эти профили, то увидите, что большинство настроек там не активно.

Единственным различием двух профилей является опция Use Encryption, которая в default-encryption установлена в положение yes и требует обязательного шифрования подключения. Данная опция игнорируется протоколами SSTP и OpenVPN, которые всегда используют шифрованные подключения.

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

Мы не советуем менять настройки в стандартных профилях, если вам нужно явно задать иные настройки подключения, то создайте собственный профиль. Также учтите, что опция Use Compression игнорируется для OpenVPN соединений, которые в реализации от Mikrotik не могут использовать сжатие трафика.

PPTP-клиент

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

Для настройки PPTP клиента добавьте интерфейс типа PPTP Client и перейдите на закладку Dial Out, где расположены сетевые настройки.

Настроек немного, и они просты. В поле Connect To укажите FQDN или IP-адрес VPN-сервера, в поля User и Password - имя пользователя и пароль. В Profile выбирается в зависимости от необходимости шифрования нужный профиль. В самом низу рядом с опцией Allow (разрешить) указаны допустимые к использованию протоколы аутентификации, на сегодня безопасным считается только MS-CHAP v2 и следует использовать по возможности только его. Однако помните, что используемый протокол аутентификации должен поддерживаться сервером, в противном случае установить связь вы не сможете.

Опция Keepalive Timeout указывает время переподключения соединения в случае обрыва связи. Бытует мнение, что лучше делать это значение поменьше, мол быстрее будет переподключаться туннель. Но это не так, во-первых, при неполадках на сервере вы будете активно забивать канал и нагружать сервер служебным трафиком, а во-вторых, при кратковременных перебоях связи короткое время будет вызывать переподключение с обрывом всех соединений в канале, а большее значение позволит сохранить туннель. Особенно это актуально для мобильного интернета или беспроводных каналов.

Опция Add Default Route создаст маршрут по умолчанию через туннель, т.е. направит туда весь исходящий трафик, указывайте ее только в том случае, если данный туннель основной способ доступа в интернет.

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

L2TP-клиент

Говоря про L2TP, обычно подразумевают L2TP/IPsec, потому как без шифрования данный протокол в корпоративной среде не используется. Но есть и исключения, некоторые провайдеры, например, Билайн, используют чистый L2TP без шифрования. В этом случае настройки подключения будут выглядеть так:

Обратите внимание на используемый профиль - default, так как соединение не зашифрованное, с профилем default-encryption вы не сможете подключиться к серверу провайдера. Add Default Route ставим только если это основное соединение с интернет. Также имеет смысл использовать опцию Allow Fast Path, для разгрузки CPU, особенно на младших моделях, но учтите, что с данной опцией соединение может работать неустойчиво, в таком случае ее придется отключить.

Для работы с L2TP/IPsec настройки будут немного иные, во-первых, используем профиль default-encryption и включаем использование IPsec установкой флага Use IPsec, при этом становится активным поле IPsec Secret, куда вводим предварительный ключ.

Опция Allow Fast Path при использовании IPsec игнорируется и в ее установке нет никакого смысла, так же не забывайте про опцию Add Default Route, в большинстве корпоративных сценариев устанавливать ее не следует.

Вроде бы тоже ничего сложного в настройках L2TP/IPsec нет, но если вы попытаетесь подключиться к Windows Server, то у вас ничего не получится. В чем же дело? А дело в настройках IPsес, перейдем в IP - IPsec - Proposal и откроем настройку по умолчанию. Proposal или предложение IPsec содержит список алгоритмов защиты канала, которые устройство предлагает для установления соединения. Понятно, что для успешного установления канала поддерживаемые методы защиты должны совпадать.

В предложении IPsec по умолчанию обращаем внимание на опцию PFS Group, она отвечает за применение технологии совершенной прямой секретности (Perfect forward secrecy, PFS), которая предусматривает создание уникальных сессионных ключей по алгоритму Диффи-Хеллмана, что делает невозможным расшифровку перехваченного IPsec трафика даже при наличии долговременных ключей (в данном случае предварительного ключа).

Windows Server по умолчанию не поддерживает совершенную прямую секретность, поэтому PFS Group нужно выставить в состояние none, после чего соединение успешно установится.

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

Хотя более правильным является создание своего предложения (Proposal) и политики (Police) для каждого соединения, но эта тема далеко выходит за рамки статьи.

SSTP-клиент

Мы не будем останавливаться на уже описанных нами опциях, которые общие для всех видов коммутируемых подключений, а сосредоточимся на новых, свойственных именно этому типу VPN. SSTP относится к отдельной подгруппе SSL VPN, которые используют трафик практически не отличимый от HTTPS, что серьезно затрудняет выявление и блокирование таких туннелей.

На что следует обратить внимание при настройке? Давайте сначала посмотрим на окно настроек:

Как видим, появилась опция Port, где мы можем указать порт подключения, по умолчанию это 443, но можно использовать и любой иной, если 443 порт занят, например, веб-сервером. Также SSTP может прекрасно работать через прокси, в этом случае вам потребуется указать адрес прокси-сервера и используемый им порт в опциях Proxy и Proxy Port.

Также вспоминаем, что SSTP всегда использует шифрование канала, поэтому оно будет работать вне зависимости от выбранного профиля, в данном случае default и default-encryption будут работать одинаково.

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

TLS Version указывает на допустимые к использованию версии TLS, однако это определяется сервером, но следует стараться использовать только протокол TLS 1.2, что позволяет исключить атаки с понижением протокола.

Опция Verify Server Certificate не является обязательной, но позволяет проверить подлинность сервера, исключая атаки типа человек посередине, для этого потребуется импортировать на Mikrotik сертификат центра сертификации (СА) выдавшего сертификат серверу.

Опция Verify Server Address From Certificate позволяет убедиться, что IP-адрес подключения соответствует адресу для имени, указанного в сертификате. Также не является обязательной, но позволяет дополнительно убедиться, что подключаетесь вы именно к тому серверу.

Установка флага в поле PFS включает совершенную прямую секретность, но эта опция должна поддерживаться со стороны сервера.

OpenVPN-клиент

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

Обычно комплект для подключения OpenVPN клиента составляют сертификат СA, сертификат и закрытый ключ клиента, конфигурационный файл. Нам понадобятся только сертификат и ключ клиента, а если мы хотим проверять подлинность сервера, то еще и сертификат CA, но он не является обязательным для настройки подключения.

Прежде всего загрузим сертификаты и ключи на Mikrotik, затем перейдем в System - Certificates и импортируем сертификат клиента. Он появится в списке сертификатов и напротив него будет буква T, что обозначает trusted, т.е. устройство доверяет этому сертификату. Затем импортируем ключ, здесь важно соблюдать именно эту последовательность, сначала сертификат, потом ключ.

После успешного импорта ключа флаги сменятся на KT, где буква K обозначает наличие закрытого ключа для сертификата. Затем аналогичным образом импортируем сертификат CA сервера, импорт ключа для данного сертификата не нужен. Закрытый ключ CA является самой большой тайной и должен хранится с соблюдением всех мер предосторожности и не при каких обстоятельствах не должен покидать узел СA (центра сертификации).

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

Но сначала коснемся опций User и Profile. Первая используется только в случае аутентификации на сервере по имени и паролю, большинство OpenVPN серверов такой тип аутентификации не используют и в этом поле вы можете написать все что угодно, просто оно должно быть заполнено. Профиль также не имеет значения, так как OpenVPN всегда шифрует канал, а опцию сжатия игнорирует.

Mode задает режим работы канала, в терминах OpenVPN ip - это tun (L3), а ethernet - это tap (L2), следует помнить, что режим работы определяется сервером. В поле Certificate укажите импортированный сертификат клиента. Опции Auth и Cipher указывают на используемые сервером криптографические алгоритмы для аутентификации и шифрования, если вы укажете отличные от указанных в конфигурации сервера - то соединение установить не удастся. Если алгоритм аутентификации явно не указан в конфигурации сервера, то по умолчанию используется SHA1.

При настройке OpenVPN клиента на Mikrotik следует помнить, что сервер должен поддерживать соединения по протоколу TCP, без сжатия и TLS-аутентификации, в противном случае подключиться к серверу не удастся.

Опция Verify Server Certificate позволяет проверить подлинность сертификата сервера, что защищает от атак типа человек посередине, но требует импорта сертификата CA сервера.

Маршрутизация

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

В данном примере мы отправляем все пакеты к сети 192.168.200.0/24 через L2TP-подключение l2tp-out1. Если вы понимаете основы маршрутизации, то указание правильных маршрутов для вас не составит труда.

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

Производительность моноблоков АТОЛ для работы с 1С:Предприятие

вс, 09/29/2019 - 00:41

Когда заходит речь об автоматизации торговых точек, то возникает вопрос выбора оборудования. Специфика области применения диктует свои требования, в которые обычные ПК вписываются довольно слабо и многие начинают обращать внимание на специализированные устройства - POS-терминалы. Достаточно привлекательно как по цене, так и по возможностям выглядит линейка POS-моноблоков от АТОЛ, в данной статье мы хотим обобщить свой опыт использования данного оборудования в связке с конфигурациями на платформе 1С:Предприятие.

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

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

Исходя из всего этого возникает потребность в чем-то компактном и защищенном, причем не только в плане внешних воздействий, но и доступа к разъемам. И такое оборудование есть - это POS-моноблоки, да, они стоят несколько дороже, чем ПК на аналогичном железе, но их стоимость полностью окупается их возможностями.

В линейку моноблоков от АТОЛ входят несколько моделей: компактная 11" Optima, полноценные 15" Jazz и Smart и топовая ViVA II Turbo. Все они построены на платформах Bay Trail/Apollo Lake, которые мы уже рассматривали некоторое время назад и остались ей довольны.

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

АТОЛ Optima

Самое компактное устройство с экраном FullHD и диагональю 11", по размерам ненамного больше того же Эвотора, но с гораздо более широкими возможностями. Цена тоже достаточно демократична, на момент написания статьи в розницу данный терминал можно было приобрести начиная от 24 000 руб. Скажем честно, за такую цену аналоги ему подобрать трудно и этот моноблок стал одним из самых популярных устройств для небольшой розницы и летом 2019 года на них был серьезный дефицит.

Внешний вид устройства достаточно лаконичен: сенсорный 11" дисплей на всю переднюю панель, кнопка включения и два разъема USB 3.0 справа. А больше в принципе ничего и не надо. На задней панели присутствуют два закрытых крышками отсека, в первом из которых (№ 1 на рисунке) расположены коммуникационные разъемы. Их набор вполне соответствует современным реалиям, а именно к уменьшению количества RS-232 в пользу USB, левый ряд разъемов на рисунке поддерживает ток до 2А, что дает возможность подключать туда требовательные к питанию устройства.

После того, как вы присоединили все разъемы просто закройте отсек крышкой, что надежно защитит их от случайного отключения. Под номером 2 на рисунке скрывается отсек для внешнего жесткого диска или SSD, в него, если снять пластиковое дно отсека, можно установить батарею на 2 или 4 аккумулятора, что дает заявленную возможность автономной работы до 2 или 4 часов. И наконец возможность монтажа на кронштейн VESA 75, для чего предназначены три металлизированных точки крепежа (№3 на рисунке).

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

Вычислительную основу моноблока составляет двухъядерный процессор Intel Celeron N3350 из семейства Apollo Lake, с базовой частотой 1,1 ГГц и максимальной 2,4 ГГц. По сравнению с Celeron J1900, который мы обозревали и на котором построены старшие модели моноблоков, N3550 обладает несколько меньшей производительностью, но при этом имеет тепловой пакет всего в 6 Вт, что позволяет создавать подобные Оптиме безвентиляторные решения.

АТОЛ Jazz 15

Полноценный сенсорный моноблок среднего уровня. Существует в разновидностях с классическим 4:3 экраном в 15" и широким 15.6" (модель Jazz Wide 15.6). Корпус и подставка выполнены из металла и пластика, обладают неплохой устойчивостью и допускают незначительное попадание жидкостей, особенно на лицевую сторону, в комплект поставки входит ридер магнитных карт.

Устройство выполнено также достаточно технологично. В верхней части корпуса под пластиковой крышкой располагается панель разъемов (№ 1 рисунке), мы также можем закрепить все провода и закрыть крышку, исключив их случайное отключение. Там же можно быстро вытащить и заменить жесткий диск или SSD, он просто вставляется снаружи через специальные "салазки" (№2 на рисунке), это очень удобно, теперь чтобы заменить диск не нужно разбирать весь моноблок.

Провода убираются в ножку, которая закрывается пластиковой крышкой (№3 на рисунке), там же находится второй COM-порт на шлейфе. Все это позволяет красиво и надежно спрятать все подходящие провода, что обеспечит опрятный внешний вид и исключит возможность несанкционированного доступа к ним. К недостаткам можно отнести только небольшое количество USB-разъемов, но этот вопрос можно решить при помощи USB-хаба, отдельные модели которых вполне можно спрятать в ножку моноблока.

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

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

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

Внутри все тоже достаточно просто и понятно, система безвентиляторная, теплоотводом служит задняя металлическая крышка, которая прижимается к радиатору через теплопроводящую прокладку. Диск подключен через переходник mSATA-SATA, что позволяет заменить его твердотельным накопителем нужного формата, а сам диск подключить к SATA-разъему платы через угловой коннектор. Также есть слот под карту памяти и mini-PCIe разъем, что позволяет дополнить систему, скажем, Wi-Fi адаптером.

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

Под капотом у АТОЛ Jazz находится четырехъядерный Intel Celeron J1900 семейства Bay Trail с базовой частотой 2 ГГц и максимальной 2,4 ГГц. Это очень удачное решение от Intel, сочетающее достаточные вычислительные ресурсы и низкое энергопотреблением - 10 Вт.

АТОЛ ViVA II Turbo

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

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

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

Внутри устройства все тот-же Intel Celeron J1900, основное отличие данного устройства - тяжелый металлический корпус, за что он особо любим предприятиями общепита, где подобные устройства эксплуатируются в достаточно тяжелых условиях.

Тестирование производительности

Все устройства можно приобрести в двух вариантах: с Windows 10 LTSB 2016 или без операционной системы, но можно без проблем установить и использовать Ubuntu, родные решения АТОЛ поставляются на базе этой ОС и имеется полная ее поддержка.

В нашем тестировании приняли участие Optima 4 ГБ RAM и 64 ГБ EMMC, Jazz 4 ГБ RAM и 64 ГБ SSD и ViVA II Turbo 2 ГБ RAM и 64 ГБ SSD. ViVA II Turbo относится к самым первым партиям, которые поставлялись еще с HDD и Windows 7 Embedded, которые в последствии были заменены на SSD и Windows 10. Также мы добавили в тестирование результаты для платы ASRock Q1900B - ITX с 2 ГБ RAM и 60 ГБ SSD, которую мы тестировали в нашем обзоре.

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

Двухъядерный Celeron N3350 вполне ожидаемо уступил четырехъядерному Celeron J1900 примерно вдвое. А Jazz немного вырвался вперед, может быть из-за наличия 4 ГБ оперативной памяти на борту, потому как железо у них с ViVA II Turbo одинаковое. Ну и появилась возможность еще раз убедиться в преимуществах большего числа ядер для современных приложений.

Но нас больше интересует 1С:Предприятие, которое в силу многих особенностей представляет преимущественно однопоточное приложение. Общепринятой системой оценки производительности здесь является Тест Гилева, который достаточно адекватно соотносится с реальными ощущениями от использования 1С.

Как известно, производительность клиентской части 1С зависит от частоты процессора, хотя при большинстве повседневных задач нагрузка на CPU будет достаточно невелика. Также на производительность влияют количество ОЗУ и скорость дисковой подсистемы, но ни один из этих показателей не является ключевым, все должно быть сбалансировано в комплексе.

В свое время система на ASRock Q1900B - ITX показала весьма неплохой результат, около 20 "попугаев":

Результат для данной платформы неплохой, что подтверждалось субъективными ощущениями, работа с 1С не доставляла дискомфорта, как в режиме РМК, так и в обычном режиме, что позволяло использовать этот же ПК для ввода поступления товаров или оформления инвентаризации.

При этом ViVA II Turbo показал более скромный результат, всего 15 "попугаев", что находится на нижнем уровне "удовлетворительно":

Аналогичные результаты мы получили для Jazz:

Что не удивительно, так как внутри у них стоит одинаковое железо. А вот Optima неожиданно приятно удивила:

Хотя с учетом однопоточности 1С:Предприятия и одинаковой максимальной частоты процессоров никакой неожиданности тут нет.

Но почему системы на Celeron J1900 в моноблоках показали худшую производительность по сравнению с материнской платой? На наш взгляд все достаточно просто и связано с режимами работы и энергосбережения процессора. Материнские платы предназначены для работы в настольных системах, предусматривающих нормальную систему вентиляции и охлаждения, в отличие от POS-моноблоков, которые могут работать в достаточно тяжелых условиях.

Вместе с тем все представленные моноблоки обеспечивают комфортную работу с 1С:Предприятие в режиме РМК, но при работе с Optima может появляться некоторая задумчивость на тяжелых операциях, скажем при переходе в режим подбора номенклатуры, что связано с ее невысокой базовой частотой процессора. Но с учетом небольшого размера диагонали иного использования, кроме как под РМК, для данной модели не предполагается.

В тоже время Jazz и ViVA II Turbo позволяют использовать себя как универсальные ПК, обеспечивающие комфортный уровень производительности для работы не только с 1С, но и с офисным пакетом или интернет-приложениями.

Кто-то может заметить, что мы не затронули в обзоре модели АТОЛ Smart, действительно это так, потому что у нас нет практического опыта работы с ними, но учитывая одинаковое аппаратное обеспечение внутри, для них будет справедливо все, что говорилось про Jazz и ViVA II Turbo.

Заключение

Из собственного опыта можем сказать, что нам нравятся моноблоки АТОЛ, как нравится линейка процессоров Bay Trail/Apollo Lake. Системы на их базе зарекомендовали себя надежными рабочими лошадками, обеспечивая достаточный уровень производительности при невысокой потребляемой мощности и низком тепловыделении.

Что же выбрать из линейки АТОЛ? Если вам нужна компактная касса и нет особых требований, то можно однозначно посоветовать Optima, тем более что аналогов ей на настоящий момент нет. Попытки использовать в качестве аналогов китайские модели типа PiPo X8 Pro столкнулись с низким качеством последних и просто огромным количеством отказов, в основном сводившимся к "отваливанию" USB-портов, на которые для кассовых ПК приходится значительная нагрузка.

Если же выбирать между Jazz, Smart и ViVA II Turbo, то следует понимать, что это полностью одинаковые устройства в разных корпусах и с разными уровнями защиты от факторов внешней среды. Для нас основной моделью на сегодняшнее время является Jazz, который стал основой автоматизации многих небольших магазинов, а ViVA II Turbo приобретаются в основном предприятиями общепита, где на первый план выходит именно ее защищенность от факторов внешней среды.

Куда пропали бесплатные сборки Postgres Professional для 1С?

пт, 09/27/2019 - 13:37

Сборки PostgreSQL для 1С от команды Postgres Professional пользовались заслуженной популярностью. И это вполне понятно, разработчики являются видными участниками международной команды Postgres и авторами патча для 1С. Но некоторое время назад все бесплатные сборки пропали с их официального сайта и для работы с 1С:Предприятие стали предлагаться коммерческие версии Postgres Pro Standard и Enterprise. Раздача синих слонов закончилась и все перешли на коммерческие рельсы? Но не все так просто и если вы хотите получить бесплатную сборку от Postgres Professional - то это статья для вас.

Действительно, если мы сейчас посетим сайт Postgres Professional, то в разделе для 1С увидим только предложения коммерческих сборок, которые бесплатно можно использовать только в очень ограниченных сценариях:

Представленная на сайте версия СУБД предназначена только для тестирования, изучения возможностей СУБД и разработки прикладного программного обеспечения.

Одновременно пошла волна слухов и домыслов, что Postgres Professional сделали сборку для 1С платной и поэтому неясно как быть дальше всем, кто успел ее скачать и поставить. Поспешим развеять туман и внести ясность. Следует понимать, что PostgreSQL открытое программное обеспечение под свободной лицензией The PostgreSQL Licence. Лицензия очень простая и весь ее смысл можно передать одним абзацем:

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

Ниже идут два параграфа об отказе от ответственности. В общем все достаточно стандартно.

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

Скажем больше, компания Postgres Professional никогда не выкладывала в свободном доступе сборки Standard и Enterprise, она просто убрала бесплатную сборку. Поэтому никаких нарушений лицензии со стороны ее пользователей нет и не может быть.

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

Нет. Не будете. Бесплатные сборки Postgres Professional для 1С никуда не делись, просто их перенесли на другой сайт. Почему на него нет ссылок с сайта Postgres Pro - вопрос отдельный, но мы не располагаем достоверной информацией и, поэтому, воздержимся от выводов.

Искомый адрес мы обнаружили при внимательном просмотре доклада Олега Бартунова (ведущий разработчик PostgreSQL и глава Postgres Professional) на конференции Infostart Event 2019:

На данном сайте представлен интерактивный скрипт, который поможет выбрать вам нужную сборку и пришлет параметры доступа к ней на почту, примерно в таком виде:

Для тех, кто с Linux на "ты" - этого достаточно, остальные могут следовать нашей статье: Установка Postgres Pro 10 для 1С:Предприятие на Debian / Ubuntu. В ней мы подробно описали алгоритм действий, а все необходимые данные вы получите в письме в сайта 1c.postgres.ru.

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

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

Очистка корзины Яндекс.Диска через API в Windows

ср, 09/25/2019 - 19:05

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

Мы не будем заново описывать как получить токен авторизации Яндекс, для этих целей воспользуйтесь статьей Очистка корзины Яндекс.Диска через API в Debian и Ubuntu. Будем считать, что токен у вас уже есть, поэтому сразу пойдем дальше.

Вариант №1 - с использованием сURL

Для работы нам понадобится curl для Windows, скачаем его с официального сайта. Из всего скачанного архива нам потребуется только папка bin, разместите ее в удобном месте, желательно с коротким путем без пробелов и только с латинскими символами, например, C:\curl\bin.

Чтобы не указывать полный путь к утилите, добавим ее расположение в системную переменную PATH, для этого перейдем в Панель управления - Система - Дополнительные параметры системы - Переменные среды:

В открывшемся окне в нижней части Системные переменные найдите переменную Path и нажмите Изменить:

Затем создайте новую строку и внесите в нее путь к папке с curl:

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

curl interface31.ru

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

curl -s -H "Authorization: OAuth TOKEN" -X "DELETE" https://cloud-api.yandex.net/v1/disk/trash/resources/?path=

где TOKEN - 40 символьная строка полученного вами токена.

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

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

Сохраните задание и запустите его вручную, корзина также должна очиститься.

Вариант №2 - с использованием PowerShell

Если вы не хотите использовать curl, то можно воспользоваться возможностями PowerShell, нам потребуется версия 3.0 или старше, из коробки данным требованиям удовлетворяют Windows 8/2012 и 10/2016/2019. Пользователям более ранних выпусков Windows потребуется скачать и установить PowerShell 3.0 отдельно.

Строка для очистки корзины через API Яндекс.Диска будет выглядеть следующим образом:

Invoke-WebRequest -Uri https://cloud-api.yandex.net/v1/disk/trash/resources/?path= -Headers @{Authorization = "OAuth TOKEN"} -Method DELETE

где TOKEN - строка полученного вами токена.

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

Для выполнения по расписанию создайте новое задание в Планировщике и заполните поля Действия следующим образом: в поле Программа или сценарий напишите powershell, а в поле Добавить аргументы укажите -command путь_к_файлу.ps1, например:

-command C:\ADM\yandex_trash.ps1

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

Установка PostgreSQL 10 для 1С:Предприятие на Debian / Ubuntu (сборка от 1С)

пн, 09/23/2019 - 17:46

Еще сравнительно недавно пользователи связки 1С:Предприятие и PostgreSQL имели достаточно неплохой выбор сборок СУБД: сборка от 1С, сборки Ethersoft и Postgres Professional. Но Ethersoft прекратил выпуск PostgreSQL для 1С, а Postgres Professional последнее время движется в сторону коммерциализации. Поэтому в настоящий момент практически не осталось альтернатив сборке от 1С, которая не пользовалась особой популярностью ввиду более сложного процесса установки. Однако не все так плохо и если вы будете следовать нашим инструкциям, то затруднений у вас возникнуть не должно.

Получить сборку от 1С можно на портале https://releases.1c.ru/, где она доступна без ограничений всем пользователям лицензионной версии любой конфигурации 1С с активной подпиской ИТС. Мы будем устанавливать последнюю на текущий момент версию PostgreSQL 10.9-5.1C, но алгоритм установки будет общим для всех сборок 10-й версии.

Из всего обилия ссылок на странице продукта нам потребуется только Дистрибутив СУБД PostgreSQL для Linux x86 (64-bit) одним архивом (DEB), сразу оговоримся, мы не видим никакого практического смысла использовать 32-битные версии сервера СУБД, поэтому будем производить установку 64-битной версии на 64-битную систему.

В качестве целевых систем будут использоваться Debian 10 и Ubuntu 18.04 LTS, в случае использования иных целевых ОС вам потребуется правильно установить необходимые зависимости, как это сделать мы расскажем ниже.

После скачивания архива мы тщательным образом проверили зависимости с целью найти проблемные версии пакетов. 1С, как всегда, оказалась в своем репертуаре, собрав пакеты для среды Ubuntu 16.04 и "прибившись гвоздями" к определенным версиям библиотек. Проблемных пакетов ровно два:

  • libssl1.0.0 - разделяемые библиотеки для реализации протоколов шифрования SSL и TLS
  • libicu55 - компоненты интернационализации для Unicode

После чего идем на https://packages.debian.org или https://packages.ubuntu.com и выясняем наличие данных пакетов для используемой вами версии дистрибутива. В репозиториях Debian 10 оба пакета отсутствуют, для Ubuntu 18.04 нет только пакета libicu55.

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

С libicu55 особого выбора у нас нет и мы скачали пакет для Ubuntu 16.04: https://packages.ubuntu.com/xenial/libicu55; libssl1.0.0 для Debian 10 мы скачали из репозитория Ubuntu 18.04: https://packages.ubuntu.com/bionic/libssl1.0.0. Для более старых выпусков Debian или иных базирующихся на его пакетной базе дистрибутивов следует качать пакеты из наиболее близкого аналога, так для Debian 9 следует качать пакеты от Ubuntu 16.04 или Debian 8.

Таким образом комплект для установки PostgreSQL должен состоять у вас из скачанных с сайта 1С пакетов (их три) и полученных по ссылкам выше libicu55 и libssl1.0.0 (только для Debain).

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

Перед тем как приступать к установке проверим настройку локалей сервера, они должны быть установлены в ru_RU.UTF-8, проверить это можно командой:

locale

После чего вы должны получить следующий вывод:

Если вы получили отличный результат, то вам нужно русифицировать систему, как это сделать описано в нашей статье: Настройка языка и региональных стандартов в Ubuntu Server/Debian. После чего не забудьте перезагрузить систему.

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

cd ~

Затем начинаем устанавливать зависимости, для Debian 10 выполните следующие команды:

apt install libxslt1.1
dpkg -i libssl1.0.0*.deb
dpkg -i libicu55*.deb

Для Ubuntu 18.04:

apt install libssl1.0.0
dpkg -i libicu55*.deb

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

apt install postgresql-common
dpkg -i libpq5*.deb
dpkg -i postgresql-client-10*.deb
dpkg -i postgresql-10*.deb

В Debian 10 вы можете получить следующее предупреждение, которое можно смело проигнорировать:

Также обратите внимание, что мы везде, где это возможно, использовали подстановочные символы в именах пакетов, это позволяет успешно использовать эту инструкцию вне зависимости от версии PostgreSQL 10 и пакетов libssl1.0.0 и libicu55 , однако будьте внимательны, в директории не должно находиться иных пакетов, чьи имена могут попасть под маску, иначе это может привести к непредсказуемым последствиям.

В пакетах от 1С уже настроены все необходимые параметры доступа и все что нам остается - это задать пароль для суперпользователя PostgreSQL - postgres. Перед тем как выполнять следующие действия, убедитесь, что вы находитесь в консоли с правами суперпользователя, если это не так, то выполните:

sudo -s

Теперь войдем в систему от имени пользователя postgres:

su postgres

Откроем консоль PostgreSQL:

psql

И установим пароль:

ALTER USER postgres WITH PASSWORD 'MyPa$$word';

Для выхода из консоли введите:

\q

После чего можно создать новую базу через оснастку Администрирование серверов 1С Предприятия или стартер 1С.

Как видим, если вдумчиво подойти к процессу, то установка сборки PostgreSQL 10 от 1С не таит в себе каких-либо сложностей и может быть осуществлена даже начинающим пользователем Linux, достаточно следовать данной инструкции и хотя бы в общих чертах понимать смысл выполняемых действий.

Linux - начинающим. Часть 5. Управление пакетами в Debian и Ubuntu

вс, 09/22/2019 - 00:55

Умение устанавливать, обновлять и удалять программное обеспечение относится к важнейшим навыкам работы с любой операционной системой. Поэтому изучение данного вопроса первостепенная задача для любого начинающего пользователя Linux, сразу после того, как он немного осмотрелся в системе. К сожалению, нет единого способа управления ПО, подходящего для всех дистрибутивов, разные семейства предполагают различные подходы, хотя общие принципы во многом совпадают. В данном материале мы будем разбирать вопрос применительно к системам основанным на Debian и Ubuntu.

Пакеты и репозитории

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

Существуют различные форматы пакетов, наиболее распространенными из которых являются RPM (рекурсивный акроним RPM Package Manager, ранее Red Hat Package Manager) и DEB (сокращение от Debian). Первый используется в основанных на Red Hat/Fedora дистрибутивах, а также некоторых иных, например, OpenSUSE, второй - во всем многочисленном семействе систем на базе Debian и его производных, включая один из самых популярных дистрибутивов - Ubuntu.

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

Еще одна особенность пакетов Linux вытекает из следования некоторым постулатам философии Unix, а именно каждый пакет содержит только необходимый минимум файлов и библиотек, все остальные необходимые ему компоненты указываются в качестве зависимостей. Причем разделение на небольшие пакеты присутствует даже у одного продукта: в один пакет могут быть включены бинарные файлы, во второй - общие библиотеки, в третий - документация и т.д. и т.п. Это позволяет достаточно гибко управлять процессом разработки и поддержки, если разработчики внесли изменения в какую-то библиотеку, то вам не нужно снова скачивать продукт целиком, достаточно обновить только пакет с библиотекой.

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

Все это хорошо, скажет иной читатель, только как мне узнать какие именно пакеты мне нужно установить, чтобы получить на выходе полноценный продукт, как разобраться во всем этом обилии непривычных названий? Для этой цели существуют метапакеты. По сути - это пакет пустышка, который в своих зависимостях имеет нужный перечень пакетов для установки готового продукта. Например, если нужен офисный пакет, то достаточно просто установить libreoffice, этот метапакет по зависимостям подтянет и установит все необходимые компоненты для полного набора офиса, каким вы его привыкли видеть. Хотя никто не мешает установить самому только нужные компоненты, скажем только LibreOffice Calc.

Следующий вопрос - где брать пакеты? Windows опыт подсказывает - на сайте разработчика или производителя ПО. Но этот подход в Linux не работает, точнее работает частично. Почему? Ну вот скачали мы нужный пакет и выясняется, что у него еще 10 пакетов в зависимостях, где их брать? На сайтах их разработчиков, а у них окажутся свои зависимости... Поэтому в Linux были созданы и поддерживаются централизованные хранилища пакетов - репозитории. Каждый крупный дистрибутив имеет собственные репозитории для всех поддерживаемых выпусков и архитектур, которые содержат огромное количество ПО и поэтому вам не следует волноваться о том, где искать пакеты.

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

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

Как правило типичный дистрибутив на базе Debian имеет четыре основных репозитория:

  • Base repository - основное хранилище, содержит все пакеты, но обновляется достаточно редко, обычно одновременно с выходом минорной версии дистрибутива, например, Debian 9.6, Debian 9.7 и т.д.
  • Security updates - обновления безопасности, являются критически важными для функционирования системы и крайне желательны к установке.
  • Stable updates - стабильные обновления, не являющиеся обновлениями безопасности, могут исправлять некритические ошибки в ПО или незначительно расширять его функционал в рамках текущей версии.
  • Stable backports - стабильное ПО с обратной совместимостью, содержит прекомпилированные для текущего дистрибутива самые свежие версии ПО, которые разрабатываются в рамках новой версии, позволяет использовать более новые версии программ, не подвергая стабильность дистрибутива угрозам при использовании пакетов тестируемой или нестабильной ветки.

Каждый репозиторий состоит из нескольких разделов, в Debian это:

  • main - содержит пакеты, которые полностью совместимы с "Критериями Debian по определению Свободного ПО"
  • non-free - распространяемое без ограничений ПО, которое не соответствует или не полностью соответствует принципам свободного ПО по версии FSF (Free Software Foundation, Фонд свободного ПО)
  • contrib - свободное ПО, которое требует для работы несвободные компоненты, например, бинарные модули драйверов, прошивок ROM и т.д., либо требует ПО, имеющее собственника, скажем несвободную версию Java от Oracle.

В Ubuntu разделы немного иные:

  • main - также, как и в Debian содержит свободные пакеты, поддерживаемые компанией Canonical
  • restricted - несвободное ПО, поддерживаемое Canonical
  • universe - свободное ПО, поддерживаемое сообществом
  • multiverse - несвободное ПО, поддерживаемое сообществом.

Список подключенных репозиториев хранится в /etc/apt/sources.list, ниже показано содержимое этих файлов в Debian 10 (слева) и Ubuntu 18.04 (справа).

В Debian все достаточно лаконично, подключен только раздел main трех репозиториев Base, Security updates и Stable updates, если вам нужны иные разделы, то их следует подключить самостоятельно, добавив через пробел в нужную строку.

В Ubuntu более развернутый список репозиториев, он полностью не уместился на скриншот, но для понимания структуры записей приведенного фрагмента хватает. Сверху вниз подключены Base и Security updates для поддерживаемых компанией разделов, затем они же вместе для свободного и несвободного ПО поддерживаемого сообществом, а вот Stable backports прописан для всех веток одновременно, еще ниже (за пределами экрана на скриншоте) подключены Security updates и специальный партнерский репозиторий для пакетов партнеров компании Canonical.

Типичная запись репозитория выглядит как строка со следующей структурой:

deb http://deb.debian.org/debian buster main contrib non-free

Строка начинается с deb, который обозначает репозиторий и двоичными пакетами или deb-src для репозиториев с исходным кодом, если вы не собираетесь самостоятельно собирать пакеты, то вам они не нужны. Далее идет адрес репозитория и имя выпуска, для Debian это buster, для Ubuntu - bionic, затем следует перечисление подключенных разделов, в указанном примере подключены все три.

Адреса репозиториев сохраняются постоянными, отличаясь только именами выпуска, поэтому если вам нужно обновить выпуск, скажем с Debian 9 на Debian 10, то вам просто потребуется заменить везде stretch (имя девятого выпуска) на buster.

Также в Debian можно использовать вместо имен классы выпусков:

  • stable - текущий выпуск дистрибутива,
  • oldstable - предыдущий выпуск,
  • testing - разрабатываемый выпуск,
  • unstable - нестабильный выпуск, он же имеет собственное имя sid.

Но на практике это не используется, так как при выходе нового релиза вы получите его автоматическое обновление, что в большинстве случаев неприемлемо. Хотя если вы энтузиаст и хотите всегда быть на переднем крае прогресса, то можете везде прописать testing, получив аналог популярных ныне rolling release дистрибутивов, которые не имеют закрепленной версии и всегда предоставляют наиболее свежий срез пакетов, зачастую ценой стабильности.

Для добавления собственных источников пакетов предназначена директория /etc/apt/sources.list.d/ в которой следует располагать файлы с адресами источников и обязательным расширением .list. Хотя их можно прописать и в основной файл, но это считается дурным тоном.

Низкоуровневый менеджер пакетов Dpkg

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

Основой системы управления пакетами в Debian является dpkg - достаточно низкоуровневая утилита, предназначенная для получения информации, установки и удаления пакетов. Назвать ее менеджером пакетов в современном смысле этого слова достаточно затруднительно, dpkg не умеет работать с репозиториями и разрешать зависимости. Но тем не менее этот инструмент достаточно широко используется по сей день и навыки работы с ним необходимо иметь каждому администратору.

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

dpkg -I имя_файла_пакета.deb

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

dpkg -i имя_файла_пакета.deb

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

dpkg -i *.deb

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

Чтобы получить сведения о всех доступных и установленных пакетах используется ключ -l, но он выведет список всех пакетов, поэтому следует использовать его с маской, например, так:

dpkg -l gimp

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

dpkg -l gimp*

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

dpkg -l | grep gimp

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

Для удаления пакета используйте:

dpkg -r имя_пакета

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

dpkg -P имя_пакета

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

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

Улучшенный инструмент для работы с пакетами APT и команды apt и apt-get

Настоящим пакетным менеджером в Debain является APT (Advanced Package Tool, Улучшенный инструмент для работы с пакетами), который умеет работать с репозиториями, разрешать зависимости и взаимодействовать с dpkg, которая, собственно, и занимается установкой пакетов.

APT имеет два интерфейса командной строки: apt-get и более новый apt. Их синтаксис и возможности во многом схожи, и мы будем практически всегда использовать последний, кроме отдельных случаев, когда требуемые возможности поддерживает только apt-get.

Как мы уже говорили, списки репозиториев хранятся в /etc/apt/sources.list, но они не содержат сведений о пакетах, чтобы их получить нужно скачать из репозитория список находящихся в нем пакетов. Понятно, что каждый раз скачивать списки - плохая идея, поэтому APT хранит локальный кеш пакетов в /var/lib/apt/lists, также копии всех скачанных пакетов сохраняются в /var/cache/apt/archives, что позволяет предотвратить их скачивание в случае повторной установки.

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

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

apt update

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

apt list --upgradable

Установить обновления можно командой:

apt upgrade

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

apt dist-upgrade

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

Обычные обновления следует выполнять командой upgrade, тогда как dist-upgrade следует использовать для обновления дистрибутива, в том числе и на минорные версии в составе текущего выпуска.

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

apt install имя_пакета

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

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

Для удаления пакета используйте:

apt remove имя_пакета

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

apt purge имя_пакета

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

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

Удалить их можно командой:

apt autoremove

Как можно заметить, APT достаточно дружелюбен к пользователю, постоянно подсказывая ему необходимые команды, что в очередной раз развеивает миф о сложности администрирования Linux, особенно в режиме командной строки.

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

apt clean

Эта команда полностью очистит кеш, также можно использовать более мягкую очистку с помощью apt-get, который дает возможность удалить из кеша только те пакеты, которые на текущий момент отсутствуют в репозитории (были заменены новыми версиями или удалены):

apt-get autoclean

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

apt --reinstall install имя_пакета

Еще одна важная возможность APT - это восстановление нарушенных зависимостей и автоматическое исправление ошибок при установке пакетов, например, когда процесс обновления или установки был аварийно прерван. Либо когда вы установили некоторый пакет при помощи dpkg и при этом у него оказались неудовлетворенные зависимости. Все это в большинстве случаев отлично исправляется одной простой командой:

apt install -f

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

apt install имя_пакета -s

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

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

apt search строка_поиска

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

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

apt show имя_пакета

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

apt-mark hold имя_пакета

Чтобы отменить фиксацию выполните:

apt-mark unhold имя_пакета

Объем данной статьи не позволяет рассмотреть все возможности apt, поэтому мы ограничились наиболее необходимыми в повседневной деятельности, ну и в завершение небольшая порция юмора. Если запустить команду apt без параметров, то вы увидите краткую справку в самом конце которой будет строка: В APT есть коровья СУПЕРСИЛА. Что это значит? Просто наберите:

apt moo

И вы увидите старую пасхалку от разработчиков, которая была еще в apt-get, а затем ее заботливо перенесли в apt.

Графические оболочки Aptitude и Synaptic

Кроме родных для APT консольных интерфейсов apt-get и apt существуют и более высокоуровневые оболочки. Одна из них aptitude, которая может работать как в псевдографическом режиме, так и в режиме командной строки, имея синтаксис во многом повторяющий синтаксис apt. Благодаря этому многие воспринимают эту утилиту как еще один интерфейс к APT, хотя основной задачей разработчиков было именно создание псевдографической интерактивной оболочки.

В современных дистрибутивах Debian и Ubuntu aptitude отсутствует в основной поставке и вам потребуется установить этот пакет отдельно.

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

Однако не смотря на то, что Aptitude и Synaptic являются зрелыми и эффективными инструментами, мы бы не рекомендовали их использование по крайней мере до тех пор, пока вы не освоите работу с базовым интерфейсом apt.

Магазины приложений

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

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

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

Ниже показан магазин для актуальной версии Debian

или Ubuntu

Заключение

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

Обновляем Proxmox Virtual Environment с версии 5.x до 6.0

чт, 09/19/2019 - 23:58

В нашем прошлом материале мы достаточно подробно рассмотрели установки и базовые навыки использования Proxmox Virtual Environment последней актуальной версии 6.0, тем не менее остается достаточно много инсталляций этой системы виртуализации прошлых версий 5.х. К счастью, их не сложно обновить до последней версии, что мы уже успешно успели проделать с находящимися на нашем обслуживании системами. Данный материал представляет перевод официальной документации с нашими дополнениями и пояснениями.

Сразу сделаем предостережение: обновление ОС - потенциально опасный процесс и прерывание его на определенных этапах способно доставить многочисленные сложности. Поэтому все описанные ниже действия следует производить либо в консоли (непосредственно подключившись к серверу), либо через SSH-клиент, в последнем случае, чтобы избежать проблем при потере связи, используйте команду screen.

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

apt update
apt dist-upgrade

В данном случае мы продразумеваем, что вы обновляете одиночный сервер, если вам требуется обновить кластер, то потребуются некоторые дополнительные действия, за подробностями обратитесь к официальной инструкции: https://pve.proxmox.com/wiki/Upgrade_from_5.x_to_6.0.

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

pve5to6

В нашем случае мы получили следующий вывод:

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

Запущенные виртуальные машины следует либо выключить, либо передать на другую доступную ноду. Обратите внимание, что требуется именно выключение VM, а не приостановка (пауза) ее состояния. Если виртуальных машин много, то сразу все их можно выключить через Массовые операции на уровне ноды.

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

Изменим репозитории для новой версии ОС, в данном случае это Debian 10:

sed -i 's/stretch/buster/g' /etc/apt/sources.list

После чего обязательно загляните в /etc/ apt/sources.list.d и замените версию ОС в дополнительных подключенных репозиториях. В нашем случае это оказались репозиторий Proxmox без подписки (в нашем случае был изменен адрес в файле репозитория по подписке) и репозиторий Ceph.

Можно вручную заменить в них stretch на buster, либо выполнить для каждого из них команду:

sed -i 's/stretch/buster/g' /etc/apt/sources.list.d/имя_файла.list

После чего снова обновляем список источников пакетов и запускаем обновление системы:

apt update
apt dist-upgrade

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

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

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

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

Как видим, обновить Proxmox Virtual Environment до версии 6.0 несложно. Достаточно внимательно следовать инструкции и проблем возникнуть не должно.

Проверка связи по протоколу SMTP с помощью Telnet

вс, 09/15/2019 - 20:30

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

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

Поставим себе некую задачу. Допустим мы хотим проверить доставку почты c некого ящика example@interface31.ru на ящик test@host31.ru, а также проверить работу сервера в некоторых иных ситуациях.

Прежде всего сразу следует выяснить какой узел в указанном домене отвечает за прием почты, это следует сделать даже если вы знаете точный адрес этого сервера, так как позволит выявить возможные ошибки при настройке DNS. Для этого мы будем использовать утилиту nslookup, в Windows она входит в штатный комплект поставки, а в Linux вам возможно потребуется установить пакет dnsutils.

Для получения записей MX-хостов узла (т.е. серверов, принимающих почту) выполним:

nslookup -type=mx host31.ru

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

В нашем случае почта обслуживается серверами Яндекса, а именно mx.yandex.net, с которым мы и будем работать. Для дальнейших действий нам потребуется telnet-клиент, в Linux он есть из коробки, в Windows его следует установить в дополнительных компонентах или использовать любой сторонний клиент, поддерживающий этот протокол, например, PuTTY. В нашем примере будет использоваться telnet-клиент в Debian 10.

Прежде всего запустим самого клиента:

telnet

в ответ мы увидим строку приглашения, куда введем строку соединения с сервером:

OPEN mx.yandex.net 25

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

Обратите внимание, что оно отличается от адреса, к которому мы подключались. Это связано с тем, что почту могут обслуживать несколько серверов и при обращении к домену mx.yandex.net каждый раз будет выдаваться разный адрес, для распределения нагрузки между серверами. В этом несложно убедиться, выполнив еще раз команду nslookup, без аргументов она сообщит нам А-записи, которые соответствуют адресам серверов.

nslookup mx.yandex.net

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

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

EHLO interface31.ru

На приветствие сервер отвечает кодом 250 OK и сообщает поддерживаемые SMTP-расширения, это означает что сервер готов к получению почты.

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

MAIL FROM:<example@interface31.ru>

Она означает, что мы хотим передать сообщение от отправителя example@interface31.ru, на что сервер должен ответить нам кодом 250 2.1.0 ok.

Теперь укажем получателя:

RCPT TO:<test@host31.ru>

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

RCPT TO:<test@host31.ru> NOTIFY=success,failure

Если все хорошо, то сервер должен ответить нам с кодом 250 2.1.5 recipient ok, после чего мы можем перейти к передаче письма.

Для этого введем команду:

DATA

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

В первую очередь следует указать тему:

Subject: TEST

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

TEST TEST TEST
.

После чего сервер выполнит попытку отправки нашего письма и сообщит нам результат.

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

С какими ошибками доставки мы можем столкнуться? Одна из самых распространенных - неверный получатель. Попробуем указать в качестве получателя несуществующий ящик test@mail.ru, здесь мы также указали необслуживаемый данным сервером домен, что позволят дополнительно проверить сервер на открытый релей. В подавляющем большинстве случаев нормально работающий сервер не должен пересылать не предназначенную ему почту из публичных сетей.

В данном случае все закончилось быстро, сервер сообщил нам с кодом 550 5.7.1 No such user! , что такого пользователя не существует, а когда мы попытались упорствовать, сообщил с кодом 503 5.5.4 Bad sequence of commands о неверной последовательности команд.

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

Для проверки мы отправили сообщение с подделанным отправителем и сразу же получили ошибку 451 4.7.1 Sorry, the service is currently unavailable. Please come back later.

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

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

QUIT

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

Установка и настройка Proxmox VE 6.0

вс, 09/15/2019 - 01:48

Proxmox Virtual Environment (Proxmox VE) - система виртуализации с открытым исходным кодом на базе Debian, использующая в качестве гипервизора KVM для виртуальных машин и LXC для контейнеров. Это позволяет запускать в виртуальной среде Linux-системы без потери производительности и остальные, поддерживаемые KVM ОС с минимальными потерями. Кроме того, Proxmox VE позволяет создавать высокодоступные конфигурации с несколькими серверами и распределенными системами хранения.

Получить Proxmox VE можно на официальном сайте, сейчас доступна новая версия 6.0, которую мы и будем устанавливать. Да, это действительно open-source и это бесплатно, корпоративная подписка предоставляет доступ к закрытому репозиторию Proxmox VE Enterprise, который содержит стабильные обновления ПО и обновления безопасности, а также техническую помощь и поддержку. Никаких ограничений функциональности, если вы откажетесь от подписки, нет.

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

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

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

rm -f /etc/apt/sources.list.d/pve-enterprise.list

Затем создадим свой список:

touch /etc/apt/sources.list.d/pve-no-subscription.list

В который внесем следующие строки:

deb http://download.proxmox.com/debian/pve buster pve-no-subscription

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

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

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

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

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

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

Перед тем, как создавать виртуальные машины и контейнеры, обратимся к Хранилищам, по умолчанию создается два хранилища: local и local-lvm.

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

Для получения шаблонов следует нажать кнопку Шаблоны и мы попадем в официальное хранилище шаблонов, здесь мы может сразу загрузить шаблон другого продукта Proxmox - Mail Gateway или шаблоны стандартных Linux-систем.

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

Чтобы загрузить выбранный шаблон достаточно нажать кнопку Загрузка внизу окна.

Для создания виртуальной машины нажмем Создать VM. На первом экране укажем имя виртуальной машины:

Затем укажем тип и версию гостевой ОС и подключим нужный образ из хранилища.

После чего, последовательно перемещаясь по пунктам следует настроить все остальные параметры виртуалки, особых сложностей это составить не должно. Но создав виртуальную машину не спешите ее запускать. Прежде всего перейдем в раздел Оборудование. Здесь можно не только настроить уже подключенное оборудование, но и добавить новое. В отличие от Hyper-V, Proxmoх позволяет пробрасывать внутрь виртуальных машин USB-устройства, что может быть полезным, если вам нужно работать с ключами защиты или USB-токенами.

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

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

Пока идет установка системы создадим еще новый контейнер, для этого следует нажать кнопку Создать CT в правом верхнем углу консоли управления. В качестве контейнеров могут быть только Linux-системы, на первом экране укажите имя контейнера и задайте пароль root или загрузите публичный SSH-ключ.

Затем укажите шаблон и следующими шагами сконфигурируйте виртуальное железо.

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

Обратите внимание, что запущенный контейнер с Debian 10 потребляет всего лишь 55,46 МБ оперативной памяти.

Тем временем, пока мы создавали контейнер, должна была установиться наша виртуальная машина. После установки ВМ потребуется установить в нее QEMU-агента для полноценного взаимодействия с гипервизором. Для Linux систем все просто, на deb-based системах достаточно выполнить:

apt install qemu-guest-agent

Для других дистрибутивов следует установить пакет qemu-guest-agent штатным пакетным менеджером.

С Windows все несколько сложнее, прежде всего скачаем и поместим в хранилище Proxmox ISO-образ с virtIO драйверами. Получить его можно со страницы Fedora Project. Затем подключим скачанный образ к виртуальной машине.

При включенном QEMU-агенте мы увидим три неустановленных устройства.

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

Для двух оставшихся выполним поиск драйверов на смонтированном диске и устанавливаем драйвер VirtIO Serial Driver, который отвечает за работу QEMU-агента:

И VirtIO Balloon Driver, который отвечает за динамическое управление памятью. При работающем QEMU-агенте внизу окошка со сведениями о виртуальной машине вы увидите ее IP-адрес, в противном случае там будет сообщение, что QEMU-агент не установлен.

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

Но придерживайтесь при этом разумных пределов, так вы можете столкнуться с невозможностью запустить современные версии Windows если укажете минимальный размер памяти менее 1 ГБ.

Еще одна важная функция, которая доступна в Proxmox VE - это резервное копирование. Существует хорошая практика - хранить резервные копии за пределами хоста. Поэтому подключим к Proxmox сетевое хранилище, для этого перейдем в Датацентр - Хранилище. Выбор здесь достаточно богатый: iSCSI, NFS, CIFS и прочее.

В нашем случае мы подключим CIFS (SMB) хранилище.

Укажите имя хранилища, в нашем случае backup, его IP-адрес или FQDN-имя, доступные ресурсы будут просканированы автоматически и вам останется только выбрать их из списка, в поле Содержимое укажите Резервная копия , а также не забудьте указать максимальное количество резервных копий в хранилище.

Затем перейдем в раздел Резервная копия и создадим новый сценарий резервного копирования:

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

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

Настройки сервера 1С:Предприятие 8 "по умолчанию" для работы с лицензиями уровня ПРОФ

ср, 09/11/2019 - 00:46

10 сентября 2019 года вступило в силу анонсированное ранее программное разделение пользовательских лицензий 1С:Предприятие 8 по уровням ПРОФ и КОРП. Нельзя сказать что это произошло неожиданно, данная информация появилась в конце февраля и доводилась до сведения пользователей в том числе и средствами платформы, которая выводила предупреждения при запуске информационной базы, но многие оказались не готовы к изменениям. Данная статья призвана помочь в этой ситуации и расскажет, как правильно выставить настройки, чтобы снова все заработало.

Прежде всего давайте разберемся, что такое лицензии уровня КОРП. Это новый тип лицензий на платформу, введенный еще в 2014 году и предусматривающий предоставление пользователю дополнительных возможностей, а именно:

  • фоновое обновление конфигурации базы данных;
  • дополнительное управление распределением по рабочим серверам кластера в разрезе информационных баз, видов клиентских приложений и фоновых заданий:
    • сервисов кластера;
    • соединений с информационными базами;
  • гибкое управление нагрузкой в кластере:
    • безопасный расход памяти за один вызов;
    • количество ИБ на процесс;
    • объем памяти рабочих процессов, до которого сервер считается производительным;
    • максимальный объем памяти рабочих процессов;
    • стратегия балансировки (по памяти, по производительности);
  • внешнее управление сеансами;
  • механизм управления потреблением ресурсов;
  • профили безопасности;
  • возможность обновления тонкого клиента с сервера;
  • возможность публикации списка баз и обновлений тонкого клиента через http;
  • возможность использования "1С:Сервера взаимодействия".

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

Операция не может быть выполнена с текущим составом лицензий.
Свойства кластера 'Допустимое отклонение количества ошибок сервера', 'Режим распределения нагрузки' или свойства рабочего сервера 'Максимальный объем памяти рабочих процессов', 'Безопасный расход памяти за один вызов', 'Объем памяти рабочих процессов, до которого сервер считается производительным', 'Количество ИБ на процесс' содержат значения, отличные от значений по умолчанию. Использование этих функций возможно только для лицензий на платформу уровня КОРП. Обратитесь к администратору для решения вопросов приобретения и установки лицензий уровня КОРП.

Мы, в рамках этой статьи, не будем обсуждать обоснованность такого разделения, хотя, на наш взгляд, лицензии ПРОФ получились очень сильно ограниченными. Но выразим свое недоумение тем, что фирма 1С не предусмотрела легкой возможности перехода. Достаточно одной кнопки или пакетного файла в составе поставки конфигурации, которые бы возвращали настройки сервера 1С в состояние, соответствующее ограничениям лицензии ПРОФ, сколько неприятных моментов и простоев удалось бы избежать, не говоря о негативе в адрес фирмы. На худой конец можно было бы автоматически сбросить настройки на нужное состояние.

Но это еще не все. В ряде случаев данный переход способен оказаться бомбой замедленного действия. Это обусловлено двумя особенностями:

  • защита реализована начиная с версий 8.3.12.1852, 8.3.13.1791 и 8.3.14.1592 платформы;
  • до 10 сеансов включительно доступен полный функционал уровня КОРП;

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

Далее везде представлены настройки для платформы 8.3.13.1926, внешний вид и состав настроек других версий платформы, в частности 8.3.15 может отличаться, но настройки разделения функционала КОРП - ПРОФ это не затрагивает.

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

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

Ограничениями лицензии ПРОФ являются:

  • Допустимое отклонение количества ошибок сервера, значение по умолчанию 0;
  • Режим распределения нагрузки, значение по умолчанию Приоритет по производительности.
Настройки сервера

А вот здесь все гораздо хуже, практически все возможности настройки сервера у пользователей ПРОФ забрали.

Под ограничения попали:

  • Максимальный объем памяти рабочих процессов, значение по умолчанию 0;
  • Безопасный расход памяти за один вызов, значение по умолчанию 0;
  • Объем памяти рабочих процессов, до которого сервер считается производительным, значение по умолчанию 0;
  • Количество ИБ на процесс, значение по умолчанию 8.

Любые значения, отличные от значений по умолчанию, являются недопустимыми.

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

Настройки информационной базы

Мы не думаем, что кто-то реально столкнется с этим ограничением, но приведем его на всякий случай.

Во всех информационных базах должны быть установлены следующие значения:

  • Внешнее управление сеансами - пустая строка;
  • Обязательное использование внешнего управления - флаг снят.

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

Настройки публикации на веб-сервере

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

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

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

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

Нормативное регулирование Wi-Fi в Российской Федерации

вс, 09/08/2019 - 00:20

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

Диапазон 2,4 ГГц

Начнем с наиболее популярного и широко используемого диапазона 2,4 ГГц, сегодня это основной диапазон, поддерживаемый всеми Wi-Fi устройствами, он же наиболее загружен, особенно в районах многоэтажной застройки.

Основным регламентирующим документом в России является Постановление Правительства РФ от 12.10.2004 N 539 (ред. от 22.12.2018) "О порядке регистрации радиоэлектронных средств и высокочастотных устройств", а именно пункт 24, который гласит, что не подлежат регистрации:

Устройства малого радиуса действия, используемые в сетях беспроводной передачи данных, и другие устройства с функцией передачи данных в полосе радиочастот 2400 - 2483,5 МГц, с прямым расширением спектра и другими видами модуляции с максимальной эквивалентной изотропно-излучаемой мощностью не более 100 мВт

Данный диапазон частот соответствует международному диапазону ISM (Industrial, Scientific, Medical - Промышленный, Научный, Медицинский), который также разрешен к использованию без получения лицензии, а именно его "научной" части 2400-2500 МГц. Разрешенный в России диапазон включает в себя 13 каналов шириной в 20 МГц и частотным шагом в 5 МГц.

Канал 1 2 3 4 5 6 7 8 9 10 11 12 13 Центральная частота,МГц 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 Полоса ISM

Из них независимыми или непересекающимися являются только три канала: 1-й, 6-й и 11-й. Формально в России можно отнести к непересекающися и наборы 2-7-12 и 3-8-13, но практически это не имеет никакого смысла. В большинстве стран Европы и Америки в данном диапазоне доступны только 11 каналов, которые не оставляют иных вариантов, кроме как 1-6-11.

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

При этом нет никаких ограничений или общепринятых соглашений по использованию частотного диапазона и, по сути, сегодня в нем творится полный хаос. Масла в огонь добавило разрешение на использование в данном диапазоне широких (40 МГц) каналов, хотя первоначально разрешать их к использованию не планировалось. Таким образом говорить о непересекающихся каналах в данном диапазоне можно сугубо условно, например, широкие каналы 5+9 или 4+8 эффективно будут ставить помехи по всей ширине диапазона.

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

Выше показана типичная картина в многоэтажном доме. Как видно две широкие сети 7+3 и 8+12 практически полностью перекрывают диапазон и в такой радиообстановке единственным вариантом остается уйти в начало диапазона, который все равно приходится делить с достаточно сильной соседской точкой. В таких условиях соблюдение не только нормативных предписаний, но и рекомендаций по использованию диапазона выходит на первый план, но, к сожалению, следовать им не спешат не только пользователи, но и производители оборудования.

А рекомендации в общем то просты: использовать только непересекающиеся каналы 1-6-11 и не использовать широкий канал в 40 МГц. Мы уже промолчим о том, что мощность точки доступа должна быть минимально достаточной для обеспечения необходимой зоны покрытия. Как вы думаете, сколько точек из нашего окружения было осознанно настроено пользователями? Зная своих соседей, могу твердо сказать - ни одной и то, что вы видите - это результат работы оборудования "из коробки".

Если трезво смотреть на вещи, то широкий канал в диапазоне 2,4 ГГц не дает никаких преимуществ. Теоретически он может обеспечить скорости до 150 Мбит/с, против 75 Мбит/с на канале шириной 20 МГц, но по факту даже такая скорость остается недостижимой. С другой стороны, основные потребители W-Fi - мобильные устройства, которые, кроме топовых моделей, не умеют работать с широким каналом, да и при скоростях доступа в интернет до 100 Мбит/с смысл его использования теряется.

Отдельно стоит отметить использование каналов 12 и 13, если вы думаете с их помощью уйти в более свободную часть диапазона, то это не самая лучшая идея, тот же 11-й канал перекрывает большую часть 12-го и половину 13-го. При этом техника западного производства, даже сертифицированная к ввозу в РФ, может не уметь работать с каналами выше 11-го, яркий пример - устройства Apple. Это же касается международных версий многих популярных китайских смартфонов.

Диапазон 5 ГГц

Для решения проблемы загруженности диапазона 2,4 ГГц для Wi-Fi устройств был дополнительно выделен диапазон 5 ГГц, точнее ряд диапазонов в полосе частот 5-6 ГГц. При этом были учтены ошибки, допущенные при регулировании диапазона 2,4 ГГц, но насколько эффективными окажутся принятые меры мы узнаем, когда устройства, работающие в данном диапазоне, будут распространены также широко, как устройства, работающие на 2,4 ГГц.

В России данный диапазон регулируется пунктом 23 указанного выше Постановления, который выводит из под регистрации:

Устройства малого радиуса действия в сетях беспроводной передачи данных и другие устройства с функцией передачи данных с прямым расширением спектра и другими видами модуляции:

используемые внутри закрытых помещений в полосах радиочастот 5150 - 5350 МГц, 5650 - 5850 МГц с максимальной эквивалентной изотропно-излучаемой мощностью не более 200 мВт и максимальной спектральной плотностью эквивалентной изотропно-излучаемой мощности не более 10 мВт/МГц.

Как мы уже говорили, 5 ГГц - это не единый диапазон, а целый ряд диапазонов, порядок использования которых в различных странах может отличаться. Ниже представлена схема распределения каналов в этих диапазонах, картинка увеличивается. Выделяемые для нелицензируемой работы полосы частот называются UNII (Unlicensed National Information Infrastructure, Нелицензируемая национальная информационная инфраструктура).

Частотная сетка диапазона предусматривает использования для Wi-Fi только непересекающихся каналов шириной 20 МГц и с шагом 20 МГц, от начала и конца полосы частотный отступ составляет 30 МГц. Первоначально были разрешены к использованию полосы UNII-1 (Европа, Россия) и дополнительно к ней UNII-3 и один канал из "медицинского" ISM (США), позднее к ним добавили полосу UNII-2.

Канал 36 40 44 48 52 56 60 64 149 153 157 161 165 Центральная частота, МГц 5180 5200 5220 5240 5260 5280 5300 5320 5745 5765 5785 5805 5825 Полоса UNII-1 UNII-2 UNII-3 ISM

В дальнейшем, учитывая возросшие требования к ширине каналов была также добавлена расширенная полоса UNII-2 Extended

Канал 100 104 108 112 116 120 124 128 132 136 140 144 Центральная частота, МГц 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5720 Полоса UNII-2 Extended

Таким образом диапазон содержит 25 непересекающихся каналов. Но не все так просто, частотные полосы UNII-2 и UNII-2 Extended выделенные для Wi-Fi пересекаются с частотами, на которых работают авиационные, судовые и военные радары, а также погодные радары аэродромов. Поэтому использование данных диапазонов возможно только при использовании технологии DFS (Dynamic Frequency Selection), которая заключается в том, что точка постоянно мониторит частоту на наличие импульсов от радара и при наличии таковых обязана изменить рабочий канал.

В России на текущий момент времени из диапазона UNII-2 Extended разрешено использование только четырех каналов 132-144, таким образом у нас доступно всего 17 непересекающихся каналов, по четыре в каждой из полос UNII и один в ISM.

Кроме стандартной ширины канала в 20 МГц стандартами Wi-Fi предусмотрено использование каналов шириной в 40 МГц, 80 МГц и 160 МГц. Широкие полосы могут использоваться только в полосах UNII. Таким образом каждая из доступных в России полос может содержать по 4 канала 20 МГц, 2 канала 40 МГц и по одному каналу 80 МГц. Канал шириной в 160 МГц может использоваться только один, получаемый при объединении полос UNII-1 и UNII-2 - занимая всю их ширину.

С учетом того, что проницаемость радиоволн на частоте 5 ГГц ниже, чем на 2,4 ГГц, разрешена более высокая мощность передатчика - 200 мВт или 23 dBm, но злоупотреблять ей не стоит, межканальные помехи на данной частоте более сильные, чем в 2,4 ГГц. С другой стороны, существенно более высокое затухание волн частотой 5 ГГц в условиях городской застройки должно уменьшить взаимные помехи от клиентского оборудования.

Теоретически все выглядит неплохо, но на практике не все так гладко. Достаточно большое число клиентского оборудования поддерживает работу только в полосе UNII-1 (европейское и старое российское). Также нет единого соглашения среди производителей роутеров. Например, популярные роутеры TP-Link в старых прошивках поддерживали полосы UNII-1 и UNII-3:

В новых остался только UNII-1 (скорее всего в целях совместимости):

А у оборудования D-Link доступны UNII-1 и UNII-2:

Zyxel Keenetic обещает использование всех 17 каналов, но все опять-таки упирается в клиентские устройства, если хоть одно из них ограничено использованием только UNII-1, то всю беспроводную сеть вам придется строить в этой полосе. Пока это не представляет проблемы, так как диапазон фактически свободен, но в дальнейшем может привести к перегрузке определенных полос, что особенно актуально в свете использования каналов в 80 МГц и 160 МГц.

Создание инкрементальных и дифференциальных архивов при помощи tar в Linux

ср, 09/04/2019 - 03:28

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

Возможности tar

Утилита tar является штатным архиватором в Unix-подобных системах и полностью соответствует философии Unix - делать только одну вещь, но делать ее хорошо. Многие, возможно, удивятся, но tar не умеет сжимать архивы, потому что архивация данных и их сжатие - это разные операции. Архивация предусматривает помещение файлов в единый контейнер, целостность которого легко контролировать, особенно при передаче по каналам связи. Сжатие - это дополнительная операция, выполняемая над архивом, которая позволяет уменьшить его размер, но не является обязательной.

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

Как и многие утилиты командной строки tar имеет два варианта записи опций: полную и краткую. Краткая удобна при интерактивной работе в консоли, зато полная более наглядна и удобочитаема. Сравните:

tar -czf archive.tgz ~/my_folder

или

tar --create --gzip --file=archive.tgz ~/my_folder

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

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

Создать такой архив можно командой:

tar --create --gzip --file=archive.tgz --listed-incremental=my_folder.snar ~/my_folder

К стандартной команде добавилась новая опция --listed-incremental, которая указывает на файл метаданных. Если он отсутствует, то создается полная копия, иначе состояние файлов сверяется с метаданными и создается инкрементальный архив.

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

  • --ignore-failed-read - игнорирует файлы, которые невозможно прочитать, например, заблокированные другими процессами или на которые нет прав.
  • --one-file-system - не выходить за пределы файловой системы, используется при нахождении в целевом каталоге точек монтирования на другие разделы.
  • -p или --preserve-permissions - восстанавливает владельца и разрешения для объектов. Используется только при извлечении.
  • -s или --preserve-order - предписывает использовать порядок файлов из архива при извлечении, может быть полезна на компьютерах с малым объемом оперативной памяти, в ином случае не имеет смысла. Используется только при извлечении.
  • --sparse - используется при архивации разреженных файлов, т.е. тех, которые имеют в своем составе незаписанные области, позволяет не копировать пустые участки файлов. Может существенно замедлить процесс архивации, так как перед архивированием файл будет дополнительно прочитан.

Практический смысл из указанных опций имеет только --ignore-failed-read, особенно если вы выполняете бэкап с правами обычного пользователя. Остальные опции следует применять исключительно при наличии такой необходимости. Скажем --preserve-permissions имеет смысл, если вы восстанавливаете архив со сложной структурой прав на объекты, например, копию веб-сайта, для обычного архива личных файлов ее использование обычно бессмысленно.

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

Если нужно копировать не всё, то следует указать исключения, для этого используются две опции: --exclude и --exclude-from. Первая позволяет просто указать файл, папку или паттерн для исключения. Например:

--exclude=*.tmp

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

--exclude=dir1/tmp

А такая конструкция предписывает не копировать директорию dir1/tmp. Обратите внимание, что все пути указываются относительно директории архивируемой директории, т.е. в нашем случае полный путь к папке будет ~/my_folder/dir1/tmp.

Если нужно исключить сразу несколько объектов, то опцию следует использовать нужное число раз:

--exclude=*.tmp --exclude=dir1/tmp

Это может быть неудобно, поэтому можно поместить исключаемые объекты в отдельный файл, по одной записи на строку и использовать его совместно с другой опцией:

--exclude-from=exclude.list

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

Мы рассмотрели только самые часто используемые опции, для полной информации обратитесь к официальной документации.

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

Инкрементальным называется архив, который содержит только новые или измененные с момента предыдущего копирования файлы.

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

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

#!/bin/sh

#Указываем путь к директории с бэкапами
BACKUP=/home/andrey/backup

#Получаем номер дня недели
DAY=$(date +%u)

#Если воскресенье - удаляем файл метаданных и архивы
if [ "$DAY" = "7" ]; then
NUM="0"
rm -rf $BACKUP/example.snar
rm -rf $BACKUP/*.tgz
else
NUM="$DAY"
fi

#Создаем архив
tar --create \
--gzip \
--file=$BACKUP/example.$NUM.tgz \
--ignore-failed-read \
--listed-incremental=$BACKUP/example.snar \
/home/andrey/example

На что следует обратить внимание? Прежде всего на указание пути, в данном случае мы используем полный путь /home/andrey/backup, вместо относительного ~/backup, потому что относительный путь зависит от контекста исполнения. Так если мы запустим скрипт от имени суперпользователя, то ~/backup будет обозначать /root/backup, что может привести к самым неожиданным последствиям.

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

tar --create --gzip --file=$BACKUP/example.$NUM.tgz --ignore-failed-read --listed-incremental=$BACKUP/example.snar /home/andrey/example

Такой скрипт можно поместить в cron с исполнением один раз в сутки, и мы получим в папке с бэкапами архивы с номерами от 0 до 6, где 0 - будет полный архив, а 1-6 - инкрементальные к нему.

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

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

Создание дифференциальных архивов

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

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

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

Вот пример такого скрипта, все условия аналогичные скрипту выше:

#!/bin/sh

#Указываем путь к директории с бэкапами
BACKUP=/home/andrey/backup

#Получаем номер дня недели
DAY=$(date +%u)

#Удаляем текущие метаданные
rm -rf $BACKUP/example.snar

#Если воскресенье - удаляем файл начальных метаданных и архивы
if [ "$DAY" = "7" ]; then
NUM="0"
rm -rf $BACKUP/example.snar0
rm -rf $BACKUP/*.tgz
else
NUM="$DAY"
fi

#Если есть начальные метаданные - копируем их
if [ -f "$BACKUP/example.snar0" ]; then
cp $BACKUP/example.snar0 $BACKUP/example.snar
fi

#Создаем архив
tar --create \
--gzip \
--file=$BACKUP/example.$NUM.tgz \
--ignore-failed-read \
--listed-incremental=$BACKUP/example.snar \
/home/andrey/example

#Если воскресенье - создаем начальную копию метаданных
if [ "$DAY" = "7" ]; then
cp $BACKUP/example.snar $BACKUP/example.snar0
fi

Логика скрипта довольно проста. В обычный день мы удаляем перед архивированием текущий файл метаданных example.snar и копируем на его место начальную копию файла example.snar0 . В итоге каждый создаваемый архив будет содержать все новые или измененные файлы начиная с воскресенья, в которое мы создали полный архив.

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

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

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

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

Обновляем Proxmox Mail Gateway с версии 5.x до 6.0

пт, 08/30/2019 - 23:07

Это лето порадовало нас не только выходом нового релиза Debian, но и обновлением специализированных дистрибутивов, созданных на его основе. Буквально на днях, во вторник последней недели августа, компания Proxmox сообщила о выходе новой версии своего решения для защиты электронной почты Proxmox Mail Gateway 6.0. При этом вы можете выполнить как новую установку, так и обновить предыдущую версию. Несмотря на то, что документации по обновлению доступна на официальном сайте, мы решили выпустить собственный материал, который кроме перевода инструкции на русский язык, будет содержать наши пояснения для выполняемых действий.

Прежде всего предупредим вас - обновление на новую версию ОС - потенциально опасный процесс и потеря контроля на некоторых этапах может привести к самым нежелательным последствиям. Поэтому обновление следует выполнять либо в консоли (т.е. непосредственно подключившись к серверу), либо через SSH-терминал. В последнем случае имейте ввиду, что обрыв связи может привести к невозможности загрузить ОС в нормальном режиме и потере удаленного доступа к ней, чтобы избежать подобной ситуации воспользуйтесь командой screen.

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

apt update
apt dist-upgrade

После завершения данной операции создадим резервную копию текущей конфигурации Proxmox Mail Gateway:

pmgbackup backup

Копия создается в каталоге /var/lib/pmg/backup, советуем скопировать ее оттуда в надежное место за пределами сервера.

Изменим репозитории для работы с новой версией ОС, так как новый PMG основан на Debian 10, то выполним:

sed -i 's/stretch/buster/g' /etc/apt/sources.list

Также заменим источник в репозитории Proxmox, который доступен без подписки, если вы устанавливали продукт по нашей статье, то будет достаточно команды:

sed -i 's/stretch/buster/g' /etc/apt/sources.list.d/pmg-no-subscription.list

В ином случае потребуется уточнить имя файла, либо заменить в нем stretch на buster вручную.

Остановим следующие службы:

systemctl stop postfix pmg-smtp-filter pmgpolicy pmgdaemon pmgproxy pmgmirror pmgtunnel

и замаскируем их:

systemctl mask postfix pmg-smtp-filter pmgpolicy pmgdaemon pmgproxy pmgmirror pmgtunnel

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

Еще раз обновим источники пакетов и выполним апгрейд системы:

apt update
apt dist-upgrade

Но не спешите перезагружать систему по окончании этого процесса, нам потребуется выполнить некоторые дополнительные действия. Proxmox Mail Gateway хранит данные в базе PostgreSQL, которая была обновлена с версии 9.6 до 11, поэтому нам потребуется выполнить конвертацию данных.

Прежде всего удалим новый кластер PostgreSQL, который был создан автоматически:

pg_dropcluster --stop 11 main

И выполним конвертацию существующего кластера с данными:

pg_upgradecluster -v 11 9.6 main

Затем снимем маскировку для части служб:

systemctl unmask postfix pmg-smtp-filter pmgpolicy pmgdaemon pmgproxy

И перезагрузим сервер:

reboot

После перезагрузки снимем маскировку с оставшихся служб:

systemctl unmask pmgmirror pmgtunnel

и запустим их:

systemctl start pmgmirror pmgtunnel

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

В завершение удалим старые пакеты PostgreSQL:

apt purge postgresql-9.6 postgresql-client-9.6 postgresql-contrib-9.6

Следует отметить, что в нашем случае пакета postgresql-contrib-9.6 не оказалось, но это не является ошибкой.

Как видим, обновить Proxmox Mail Gateway достаточно просто и если вы будете следовать инструкции, то проблем возникнуть не должно. Но все равно не забывайте про резервные копии.

Q4OS - интересный и необычный Linux-дистрибутив

вс, 08/25/2019 - 01:18

Обозревать дистрибутивы Linux - дело во многом неблагодарное, во-первых - их много, во-вторых - многие из них отличаются друг от друга и от родительского дистрибутива только "нескучными" обоями. Но иногда встречается нечто действительно интересное. Одним из таких дистрибутивов является Q4OS, основанный на пакетной базе Debian и использующий в качестве рабочего окружения среду Trinity Desktop Environment (TDE). Сами разработчики позиционируют систему как быструю и мощную современную ОС с очень низкими системными требованиями, которая хорошо подходит для устаревших ПК.

Как вы уже, наверное, догадались, основной интерес в данном дистрибутиве представляет окружение рабочего стола Trinity - это форк KDE 3.5, который бережно сохраняет все особенности исходной среды с опорой на современные технологии. Однако, в отличии от другого форка не менее известной среды Mate (форк Gnome 2), широкой известности Trinity не получила, поэтому посмотреть на нее будет тем более интересно.

Q4OS - это один из немногих дистрибутивов использующих TDE и пожалуй единственный, который использует эту среду как основную. Получить ОС можно на официальном сайте, но будьте внимательны при скачивании. Существуют два типа образов: live и install-cd, установить систему при использовании live-образа вам не удастся. Текущая версия ОС - Q4OS 3.8 Centaurus, которую мы и будем рассматривать.

Инсталлятор только текстовый, стандартный для Debain и останавливаться на нем не имеет никакого смысла.

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

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

Следующий шаг - выбор профиля рабочего стола, конечно же мы выбрали полный. Кстати, всплывающая подсказка вверху ничего вам не напоминает?

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

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

Сама рабочая оболочка выглядит приятно, не скажешь, что это потомок KDE 3, общее оформление более напоминает современную KDE Plasma. Работает все это достаточно быстро, интерфейс обладает хорошей отзывчивостью.

Сам же стиль оформления очень и очень сильно напоминает Windows-системы. Да, KDE всегда использовал общие с Windows концепции построения интерфейса, в то время как Gnome тяготеет к MacOS, но в данном случае сходство уж очень явное, достаточно посмотреть на стартовое меню.

Такая мимикрия под Windows еще одна особенность Q4OS, когда-то это было довольно популярно, но и десктопный Linux тогда был еще молодой системой с большим набором "детских болезней". Сегодня же это смотрится достаточно странно, соверменный Linux - это самодостаточная система и нет никакой необходимости походить на кого-то еще.

А мы пока заглянем в прошлое, что нам позволят сделать темы оформления Q4OS. Итак, встречаем - классическая схема оформления, для тех, кто ностальгирует по Windows 2000. Хотя не менее ярко видны характерные признаки KDE3.

С выходом Windows XP стало модно походить на него.

А вот эта тема больше уже, наверное, походит на Windows 7, хотя уже столь явного подражания не просматривается, Linux стал более взрослым и начал вырабатывать собственную идентичность.

Еще один пережиток прошлого - Центр установки программ. Нет, сама идея подобного магазина не плоха, но вот реализация. Начнем с того, что представлено всего 19 программ, учитывая обилие софта в Linux это даже не смешно.

Ладно, попробуем что-нибудь установить, скажем Skype. А вот это уже смешно, только смех выходит какой-то грустный.

Ну может кто-нибудь пояснить зачем в 2019 году пытаться подражать Windows-установщику? Ладно там лет 15 назад, когда вокруг безраздельно царил Windows и процесс установки программ четко ассоциировался с подобного рода установщиками. Но сейчас, при обилии систем и магазинов неопытному пользователю такое наоборот может выйти в диковинку, он привык к нажатию единственной кнопки Установить, которая затем превращается в Открыть.

Теперь небольшое количество пакетов в этом Центре становится понятно, обернуть каждое в такой "инсталлятор" тоже нужно время, только вот это сейчас никому не нужно и выглядит как-то жалко и смешно. А что, если нам потребуется что-то еще? А тут все плохо, вот вам Synaptic и крутитесь как хотите.

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

Однако не будем увлекаться критикой, недостатки у дистрибутива есть, но есть и достоинства. Прежде всего действительно небольшие системные требования. Мы специально уменьшили объем оперативной памяти до 512 МБ и оставили виртуалке единственное ядро от Core i5-4670. Система загрузилась достаточно бодро, мы открыли в ней несколько офисных документов, пару вкладок в браузере и решили посмотреть IPTV в HD-качестве.

Да, ресурсов системе определенно не хватает, она достаточно активно свопит, но тем не менее работа все это время оставалась достаточно комфортной, а интерфейс отзывчивым. Понятно, что 512 MБ памяти для современных ПК, даже старых, это мало, но даже на такой конфигурации Q4OS c Trinity позволяет достаточно комфортно использовать систему, не отказывая себе во всех прелестях современных технологий (включая HD-видео).

Выводы

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

Скажем тот-же XFCE сегодня переходит в разряд "тяжеловесов" в семействе легких оболочек, а действительно легкие Mate и LXDE/LXQt не закрывают всех пользовательских запросов. Первая представляет собой достаточно специфичную организацию рабочего пространства, которое будет ближе пользователям MacOS, а вторая недостаточно привлекательна графически, в то время как Trinity с используемой в Q4OS темой Debonaire выглядит просто великолепно.

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

Страницы