Горячее
Лучшее
Свежее
Подписки
Сообщества
Блоги
Эксперты

Жду новый пост
Серия «ИТ»

Ansible без излишеств⁠⁠

Ansible без излишеств Программирование, Разработка, IT, Github

Ansible - мощный инструмент управления ИТ-инфраструктурой. И, как любой другой долгожитель, давно обзавёлся множеством рекомендаций (или Best Practices).


Увы, лучшие практики не только лучшие, но и довольно сложные в понимании для новичков или тех, для кого сей замечательный инструмент не является основным (но эпизодически возникает потребность), поэтому решил в рамках репозитория "ansible_helpers" предельно упростить лучшие практики (надеюсь, матёрые пользователи Ansible не станут сильно ругаться) до 4-х простых шагов:

1) заполнение списка хостов, где необходимо внести изменения;

2) правка файла конфигурации (если речь про установку сервиса);

3) внесение изменений в yml-файл, если это необходимо;

4) запуск bash-скрипта.


P.S. Репозиторий на данный момент содержит только 2 условных "приложения" ("install_chrony_client" и "install_chrony_server"), но это временно.

Ссылка на GitHub-репозиторий

Показать полностью
[моё] Программирование Разработка IT Github
23

OpenVPN. Инструкция по применению (копия с Хабра)⁠⁠

OpenVPN. Инструкция по применению (копия с Хабра) IT, Программирование, Разработка, VPN, Openvpn, Open Source, Linux, Системное администрирование, Длиннопост

1. Введение

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

Не смотря на обилие технологий, предлагаю остановиться на старом добром OpenVPN (в связке с EASY-RSA). Решение от Джеймса Йонана отличается гибкостью, функциональностью, надёжностью и непрерывностью разработки на протяжении приличного временного периода. Так сказать, мастодонт от мира VPN-решений.

Спойлер — ссылка на довольно функциональное решение (ничего особенного, чистый бэкэнд), написанное на bash некоторое время назад, ждёт вас в конце публикации (в виде github-репозитория под именем «openvpn_helper»), а здесь же уделю внимание общей структуре и некоторым аспектам использования набора скриптов и OpenVPN.

***

Список необходимых компонентов (используемая ОС — AlmaLinux 8):

1) OpenVPN 2.4.12;

2) EASY-RSA 3.0.8.
=================


2. Описание общей структуры репозитория

2.1. Директория «ovpn-server»

Директория содержит файлы и поддиректории двух типов: статичные (входящие в репозитория непосредственно) и генерируемые автоматически.

Статичные:

* «main.sh» - файл, содержащий основную кодовую базу репозитория.

* «vpn.env» - основной файл конфигурации.

* «full_setup_vpn_server.sh» - скрипт полной установки VPN-сервера. После запуска исполняет следующие действия:

1) инициация структуры файлов/директорий для управления ключами easyrsa («./easyrsa init-pki»);

2) создание корневого сертификата («./easyrsa build-ca»);

3) генерация ключа Диффи-Хелмана («./easyrsa gen-dh»);

4) создание запроса на выпуск сертификата VPN-сервера («./easyrsa gen-req vpn-server»);

5) импорт и подписание сертификата VPN-сервера («./easyrsa sign-req server vpn-server»);

6) генерация списка отозванных сертификатов («./easyrsa gen-crl»);

7) генерация секретного ключа ta.key («/usr/sbin/openvpn --genkey --secret "$PKI_DIR/ta.key"»), используемого как на стороне сервера, так и на стороне клиента. Необходим для обеспечения дополнительного уровня безопасности (защищает от сканирования прослушиваемых VPN-сервером портов, переполнения буфера SSL/TLS, DoS-атак и flood-атак, а также вводит дополнительный механизм аутентификации между сервером и клиентом);

8) генерация файла конфигурации для VPN-сервера, вспомогательных скриптов и файлов со справочной информацией;

9) копирование всех необходимых сертификатов и файлов конфигурации, необходимы для работы VPN-сервера, в директорию «/etc/openvpn/server».

* «create_cli_cert_and_conf.sh» - скрипт генерации клиентского набора сертификатов и файла конфигурации.

* «revoke_client_cert.sh» - скрипт отзыва клиентских сертификатов.

* «gen_crl_and_restart_ovpn.sh» - скрипт генерации CRL-сертификата (Certificate Revocation List или список отозванных сертификатов), содержащего сведения о всех отозванных клиентских сертификатах (отозванных посредством «revoke_client_cert.sh»). Скрипт необходимо запускать каждый раз после отзыва клиентского сертификата.

* «get_client_cert_expire_info.sh» - скрипт проверки клиентских сертификатов на предмет устаревания.

* «get_server_cert_expire_info.sh» - скрипт проверки серверных сертификатов на предмет устаревания.

Файлы и директории, формируемые на этапе полной установки VPN-сервера (full_setup_vpn_server.sh):

* директория «pki_root/pki» - содержит развёрнутую структуру файлов/директорий для управления ключами easyrsa. Краткое описание файлов/директорий структуры:

1) certs_by_serial — директория хранения выпущенных сертификатов (в рамках данной структуры pki), ранжированных по серийным номерам;

2) issued — директория хранения выпущенных сертификатов, ранжированных по имени (CN);

3) private — директория хранения закрытых ключей (в т.ч. и закрытого ключа корневого сертификата) к соответствующим сертификатам;

4) renewed — директория хранения обновлённых сертификатов. В рамках «openvpn_helper» не используется.

5) reqs — директория хранения запросов на выпуск сертификатов.

6) revoked — директория хранения отозванных запросов/сертификатов/закрытых ключей;

7) ca.crt — корневой сертификат;

8) crl.pem — список отозванных сертификатов;

9) dh.pem — ключ Диффи-Хеллмана;

10) index.txt — актуальная база данных всех сертификатов в рамках данной структуры управления ключами/сертификатами;

11) index.txt.attr — содержит параметр «unique_subject = yes», запрещающий создание сертификатов с одинаковыми именами до процедуры отзыва;

12) index.txt.attr.old — предыдущее значение параметра index.txt.attr;

13) index.txt.old — предыдущее содержание базы данных сертификатов index.txt. Изменяется, например, после отзыва клиентского сертификата);

14) openssl-easyrsa.cnf — стандартные для данной структуры параметры с указанием имён переменных, которые возможно переопределить через переменные окружения;

15) safessl-easyrsa.cnf — содержание аналогично файлу openssl-easyrsa.cnf, но с указанием конкретных значений;

16) serial — используется для промежуточного хранения серийного номера генерируемого сертификата до момента его подписания. После подписания серийный номер перемещается в файл “serial.old”;

17) serial.old — содержит серийный номер последнего сгенерированного (и подписанного) сертификата;

18) ta.key — секретный ключ для реализации tls-аутентификации.

* «RESTART_OVPN-$VPN_SERVER_NAME_S.sh» (где VPN_SERVER_NAME_S - параметр из vpn.env) - скрипт перезапуска экземпляра OpenVPN, основанного на конфигах и сертификатах, сгенерированных посредством «full_setup_vpn_server.sh» (на основе файла конфигурации «vpn.env», расположенного в текущей директории).

* «SET-STATIC-IP-FOR-CLIENTS.txt» - заполняется в формате «username,ip-address», если требуется, чтобы клиентам VPN-сервера выдавались статичных ip-адреса. После внесения изменений необходимо запустить скрипт «RESTART»

* «STOP_OVPN-$VPN_SERVER_NAME_S.sh» (где VPN_SERVER_NAME_S — параметр из vpn.env) — полный останов VPN-сервера.

* «README_MAIN.txt» - краткая инструкция об использовании VPN-сервера.

* «README-user-management.txt» - памятка об управлении пользователями. Возможность коннекта к VPN (помимо сертификатов) ограничивается локальными УЗ, созданными на хосте и состоящими в определённой группе пользователей.

* «readme-firewalld-rules.txt» - памятка о настройке файервола (firewalld).

* «readme-selinux-rules.txt» - памятка о конфигурации selinux.

* «SAVED_CERT_PASSWORDS.txt» - сохранённые пароли (от корневого сертификата и сертификата VPN-сервера).

Файлы и директории, формируемые на этапе генерации клиентских сертификатов (create_cli_cert_and_conf.sh):

* директория «cli_certs» - содержит поддиректории вида «CLIENT_CERT_NAME-files», где расположен набор клиентских конфигов и сертификатов, а также архив для передачи пользователю.
=================


2.2. Директория «run_if_dnsmasq_is_not_installed»

Скрипт «run.sh». Простой скрипт, осуществляющий установку сервиса dnsmasq.

Файл конфигурации «dnsmasq.conf». Содержит пример конфигурации сервиса без вышестоящих dns-серверов.


Для использования DNS-сервера, установленного на хосте с OpenVPN, необходимо подкорректировать правила firewalld. Рекомендации по настройке смотреть в файле «readme-firewalld-rules.txt» (после развёртывания VPN-сервера).

=================


2.3. Директория «run_if_openvpn_is_not_installed»

Скрипт «run.sh» устанавливает необходимый для работы VPN набор софта: dnf-репозиторий «epel-release», openvpn, easy-rsa.

=================


2.4. Директория «run_if_selinux_enabled»

Директория содержит 2 файла:

* selinux-модуль «ovpn_mod0.te»;

* скрипт «run.sh», устанавливающий пакет «selinux-policy» и применяющий selinux-модуль «ovpn_mod0».

=================


2.5. Директория «run_if_zip_is_not_installed»

Скрипт «run.sh» устанавливает zip-архиватор, используемый при создании архивов для передачи конечному пользователю.

=================


2.6. Файл-инструкция «if_need_another_vpnserver_on_this_host.txt»

Документ, кратко описывающий алгоритм развёртывания второго (и последующих) VPN-сервисов на одном и том же хосте.

Алгоритм таков (для примера):

1) создаём директорию, например, «ovpn-server0»;

2) переносим в неё содержание директории «ovpn-server» (исключения: cli_certs, pki_root);

3) редактируем в директории «ovpn-server0» файл «vpn.env», уделяя особое внимание параметрам: VPN_SERVER_NAME_S,

VPN_PORT_S,

VPN_NETWORK_S,

VPN_DHCP_IP_S,

VPN_INTERNAL_NETWORK_ROUTE_S,

VPN_NETWORK_MASQUERADE_SRC_S,

VPN_INTERNAL_NETWORK_MASQUERADE_DST_S,

VPN_INTERNAL_IP_DEV_NAME_S,

VPN_SERVER_INT_FIREWALLD_ZONE_S,

VPN_PORT_CL;

4) из директории «ovpn-server0» запускаем скрипт «full_setup_vpn_server.sh».
=================

2.7. Скрипт «run_first.sh»

Разрешает форвардинг (перенаправление) трафика ipv4, что важно для осуществления доступа из VPN-сети в интранет.

=================


3. Описание основного файла конфигурации vpn.env


Параметры, относящиеся только к генерации сертификатов и конфига (например, «/etc/openvpn/server/server.conf») VPN-сервера (full_setup_vpn_server.sh):

* VPN_CONF_DIR_S — директория хранения файлов конфигурации OpenVPN. Дефолтное значение - «/etc/openvpn/server».

* VPN_SERVER_NAME_S — имя VPN-сервера в контексте возможности запуска нескольких экземпляров VPN в зависимости от имени файла конфигурации. Желательно, чтобы этот параметр совпадал с частью (ovpn-XXX) имени директории, где расположен файл «vpn.env»).

* IP_VPN_SERVER_S — ip-адрес интерфейса, смотрящего в Интернет.

* VPN_PORT_S — порт интерфейса, смотрящего в Интернет. Должен быть уникален, если в рамках одного хоста настроено более одного VPN-сервера.

* VPN_SERV_LOG_DIR_S — директория размещения логов VPN-сервера. Значение по умолчанию - /var/log/openvpn.

* VPN_MAX_CLIENTS_S — максимальное количество клиентов VPN-сервера. В топологии «subnet» при использовании подсети для VPN с маской 24 (или 255.255.255.0) максимально возможное кол-во клиентов равно 83. Значение по умолчанию — 32.

* VPN_NETWORK_S — описание VPN-сети в формате «SUBNET SUBNET-mask». Значение по умолчанию - «172.16.10.0 255.255.255.0». Должно быть уникальным в случае, если в рамках одного хоста настроено более одного VPN-сервера.

* VPN_DHCP_IP_S — адрес встроенного DHCP. Значение по умолчанию — 172.16.10.1. Должен быть уникальным в случае, если в рамках одного хоста настроено более одного VPN-сервера.

* VPN_INTERNAL_NETWORK_ROUTE_S — маршрут до интранета (параметр передаётся клиентам VPN-сервера при подключении), к которой необходим доступ из VPN-сети. Заполнять в соответствии с конкретными параметрами вашей сети.

* VPN_SERVER_LOG_LEVEL_S — уровень логирования VPN-сервера. Значение по умолчанию — 0.

* VPN_NETWORK_MASQUERADE_SRC_S — описание подсети VPN-сервера, необходимое при отправке директив фаерволу (firewalld). Должно быть уникальным в случае, если в рамках одного хоста настроено более одного VPN-сервера.

* VPN_INTERNAL_NETWORK_MASQUERADE_DST_S — описание внутренней подсети, необходимое при отправке директив фаерволу (firewalld).

* VPN_INTERNAL_IP_DEV_NAME_S — имя интерфейса, смотрящего во внутреннюю сеть.

* VPN_TUN_DEV_NAME_S — имя интерфейса, используемого при старте VPN-сервера. Должен быть уникальным в случае, если в рамках одного хоста настроено более одного VPN-сервера.

* VPN_SERVER_INT_FIREWALLD_ZONE_S — зона фаервола, к которой должны принадлежать интерфейсы:

а) VPN_TUN_DEV_NAME_S;

б) VPN_INTERNAL_IP_DEV_NAME_S;

в) интерфейс, являющийся дефолтовым гейтвэем для VPN-сервера.

Пункт (в) необходим только в том случае, если VPN-сервер предполагается использовать как шлюз по умолчанию для VPN-клиентов.

Параметры, относящиеся только к генерации клиентских сертификатов и конфига (create_cli_cert_and_conf.sh):

* IP_VPN_SERVER_CL — белый (и статичный) ip-адрес (или доменное имя), к которому необходимо обратиться VPN-клиенту для доступа к интрасети.

* VPN_PORT_CL — соответствующий порт для параметра IP_VPN_SERVER_CL.

* VPN_CLI_LOG_DIR_LINUX_CL — директория хранения лог-файлов, если клиент VPN-сервера — это хост с ОС Linux.

* VPN_CLI_LOG_LEVEL_CL — уровень логирования VPN-клиента.

Параметры EASY-RSA (используются как при генерации сертификатов как для VPN-сервера, так и для клиента):

* EASY_RSA_DIR_C — место расположения исполняемого файла easyrsa. Дефолтовое значение - /usr/share/easy-rsa/3.

* EASYRSA_CERT_EXPIRE_EV — время устаревания (в днях) выпущенных сертификатов (в т.ч. и корневого). Дефолтовое значение — 3654 дней (10 лет).

* EASYRSA_CRL_DAYS_EV – время устаревания (в днях) списка отзыва сертификатов (CRL). Дефолтовое значение — 3654 дней (10 лет).

* EASYRSA_KEY_SIZE_EV – размер ключа шифрования.

* EASYRSA_REQ_COUNTRY_EV – страна.

* EASYRSA_REQ_PROVINCE_EV – область.

* EASYRSA_REQ_CITY_EV – город.

* EASYRSA_REQ_ORG_EV – организация.

* EASYRSA_REQ_OU_EV – подразделение организации.

* EASYRSA_REQ_CN_EV – имя сервера.

* EASYRSA_REQ_EMAIL_EV – email-адрес администратора.

=================


4. Заключение

Не смотря на функциональность и гибкость (особенно при наличии оснастки, описанной, например, выше), у OpenVPN есть недостаток (присутствует и у аналогичных решений) — механизм списка отозванных сертификатов (который CRL).

Если удалить клиентский сертификат из директории «issued» (структура управления ключами easyrsa), то его отзыв (посредством команды revoke) при компрометации окажется недоступным, что создаёт вероятность использования такого сертификата злоумышленниками. И в этом случае единственным вариантом обезопасить интранет от посторонних глаз — перевыпуск корневого сертификата, что влечёт за собой необходимость перевыпуска остальных сертификатов.

Логично было бы генерировать не список отозванных сертификатов (CRL), а список актуальных сертификатов (например, Cert Actual List), но, видимо, разработчики OpenVPN (а также Easy-RSA), когда-то решили иначе, что создаёт необходимость очень тщательно следить за всеми выпущенными/отозванными сертификатами.


Ссылка на репозиторий "openvpn_helper"

Показать полностью
[моё] IT Программирование Разработка VPN Openvpn Open Source Linux Системное администрирование Длиннопост
22

Проброс видеокарты в виртуальную машину (копия с Хабра)⁠⁠

1. Вступление

Две разные системы (win + linux) на одной аппаратной базе - реальность. В этом нет ничего нового или инновационного (на данный момент времени), но если требуется максимальная производительность гостевой системы, то не обойтись без проброса реальных устройств в виртуальную машину. Проброс сетевых карт, usb-контроллеров (etc) экстраординарных особенностей не несёт, а вот попытка "шаринга" ресурсов видеокарты и процессора вполне может принести некоторое количество проблем.


Итак, а для чего, собственного говоря, городить системы с полнофункциональным использованием ресурсов GPU и CPU? Самый простой и очевидный ответ - игры (широко известный факт - если не большинство, то очень многие, написаны под ОС Windows). Другой вариант - полноценное рабочее место с возможностью запуска требовательных приложений (например, CAD-софта), быстрым бэкапом (скопировать файл ВМ куда проще, чем создавать полную копию HDD/SSD) и опцией полного контроля сетевого трафика гостевой системы.


2. Аппаратная часть

Процессор: Intel(R) Core(TM) i5-9400F CPU @ 2.90GHz

Материнская плата: ASRock Z390 Phantom Gaming 4S

Видеокарта 0 (для проброса в ВМ): Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X]

Видеокарта 1 (для хост-системы): Park [Mobility Radeon HD 5430]

USB-контроллер (для проброса в ВМ и последующего подключения периферийных устройств, например, клавиатуры): VIA Technologies, Inc. VL805 USB 3.0 Host Controller


3. Настройки ОС

В качестве хост-системы выбрана ОС AlmaLinux 8 (вариант установки«Server with GUI»). Долгое время пользовался CentOS 7/8, поэтому, думаю, выбор тут очевиден.


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

1) с помощью команды «lspci -nn | grep RX» получаем уникальные идентификаторы видеокарты. Т. к. видеокарта RX-серии, то, соответственно, ищем в выводе lspci (утилита устанавливается посредством команды «dnf install pciutils») по этим двум символам. Вывод получим примерно такой (выделенные подстроки — это и есть искомые идентификаторы устройств) -

«02:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X] [1002:699f] (rev c7)

02:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Baffin HDMI/DP Audio [Radeon RX 550 640SP / RX 560/560X] [1002:aae0]», где 1002:699f — идентификатор VGA-контроллера, а 1002:aae0 — встроенной аудиокарты. Также запоминаем идентификаторы «02:00.0» и «02:00.1»;


2) добавив к команде «lspci -nn» ключ «k» («lspci -nnk») находим в выводе устройство «1002:699f» и запоминаем значение «Kernel driver in use». В моём случае — это «amdgpu»;


3) в файле «/etc/default/grub» находим строку, начинающуюся с «GRUB_CMDLINE_LINUX», и добавляем после «quiet» значения «intel_iommu=on iommu=on rd.driver.pre=pci-stub pci-stub.ids=1002:67ff,1002:aae0», где «intel_iommu / iommu» – параметры, отвечающие за поддержку технологии IOMMU (технология взаимодействия виртуальных машин с реальным оборудованием), «rd.driver.pre=pci-stub» - указание на принудительную первоочередную загрузку фиктивного драйвера pci-sub, «pci-stub.ids» - перечисление устройств, для которых при загрузке ядра необходимо использовать фиктивный драйвер (т.е. происходит изоляция устройств для дальнейшего использования в виртуальных машинах). Если на хост-машине используется CPU от AMD, то «intel_iommu» меняем на «amd_iommu»;


4) в файл «/etc/modprobe.d/local.conf» добавляем строки «blacklist amdgpu» и «options pci-stub ids=1002:699f,1002:aae0», где «blacklist amdgpu» - явное указание на запрет использования драйвера AMD для графических устройств, а «options pci-stub ids=1002:699f,1002:aae0» - явное указание на использование фиктивного драйвера для соответствующих идентификаторов устройств;


5) выполняем команду «grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg» (т.е. пересоздаём конфигурационный файл загрузчика GRUB). Если речь не про EFI-загрузку, то команда выглядит так - «grub2-mkconfig -o /boot/grub2/grub.cfg»;


6) выполняем команду «dracut --regenerate-all --force» для пересоздания образа initramfs (initial RAM disk image, загружаемый в оперативную память файл с образом файловой системы), используемого при загрузке Linux в качестве первоначальной корневой файловой системы;


7) перезагружаем хост виртуализации.


Смысл этих настроек в том, чтобы ограничить использование определённых устройств при загрузке. Например, до прописания параметров в выводе команды «lspci -v» для VGA-контроллера будет присутствовать подстрока «Kernel driver in use: amdgpu», а после перезагрузки – «Kernel driver in use: pci-stub». При старте же ВМ с Windows (и после проброса устройств) – “Kernel driver in use: vfio-pci” (в чём можно убедиться после запуска созданной ВМ). Важный момент — используемая для хост-системы видеокарта должна использовать драйвера, отличные от используемых для пробрасываемой видеокарты, например, в моём случае используется «Radeon HD 5430», драйвер для которой — это «radeon» (в выводе «lspci -v» – «Kernel driver in use: radeon»).


4. Установка софта для виртуализации

1) «dnf install epel-release».

2) «dnf install qemu-kvm qemu-img libvirt virt-install libvirt-client virt-viewer virt-manager seabios numactl perf cockpit cockpit-machines xauth virt-top libguestfs-tools».

3) «dnf install @virt».

4) Optional. «dnf install perl» (Perl – one love).


5. Настройки ВМ QEMU-KVM via virt-manager

Предварительно скачиваем iso-образ Windows 10 и драйвера Virtio от RedHat (тоже в виде iso-образа).

При первоначальной установке всегда ставим галочку «Customize configuration before install».

1) Указываем iso-образ устанавливаемой операционной системы (например, Windows 10). Также добавляем дополнительное устройство вида «CD-ROM» и монтируем в доп. устройство iso-образ с драйверами Virtio.

2) Для виртуального HDD (куда планируется установка ОС) выставляем: «Bus type = Virtio». Тип виртуального диска — qcow2 или raw.

3) Для более эффективной работы размещаем основной виртуальный диск для ВМ на SSD.

4) Модель сетевой карты - virtio.

5) Overview: chipset = “Q35”, firmware = “UEFI x86_64: /usr/share/OVMF/OVMF_CODE.secboot.fd”.

6) OS Information: Operation System = “Microsoft Windows 10”.

7) CPU (соответствующие блоки в XML должны выглядеть именно так, если речь про аналогичную аппаратную конфигурацию):


<cpu mode="host-passthrough" check="none">
<topology sockets="1" dies="1" cores="4" threads="1"/>
<cache mode="passthrough"/>
<feature policy="disable" name="hypervisor"/>
</cpu>
<features>
<acpi/>
<apic/>
<hyperv>
<relaxed state="off"/>
<vapic state="off"/>
<spinlocks state="off"/>
<vendor_id state="on" value="1234567890"/>
</hyperv>
<kvm>
<hidden state="on"/>
</kvm>
<smm state="on"/>
</features>

8) Удаляем из конфигурации ВМ: «Tablet», «Display VNC», «Channel qemu-ga», «Video VGA».

9) Добавляем (через «Add Hardware → PCI Host Device») нужные устройства (VGA-контроллер, встроенный в видеокарту аудиконтроллер и отдельный USB-контроллер), ориентируясь на выделенный идентификатор «02:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X] (rev c7)» (пример вывода «lspci»).

10) Подключаем монитор к проброшенной видеокарте, а «мышь» с клавиатурой — к проброшенному USB-контроллеру.

11) Запускаем процесс установки («Begin installation»). В процессе установки указываем инсталлятору на образ Virtio в качестве драйвер-источника для HDD.

12) После установки заходим в диспетчер задач и для неизвестных устройств указываем в качестве драйвер-источника диск с Virtio. Также инсталлируем драйвера видеокарты.

Если всё сделано правильно, то в диспетчере задач Windows вы увидите реальную видеокарту и 4 ядра CPU с расшаренными ресурсами процессора (Кэш L1 + L2 + L3).

Показать полностью
[моё] IT Linux Windows 10 Windows Длиннопост Текст
25

Legacy⁠⁠

Недокументированный (или плохо документированный) код всегда превращается в legacy. И он остаётся legacy даже тогда, когда тонкости кода/платформы знает/понимает не только один человек. Без внятной документации любая платформа медленно умирает, хоть и может приносить материальную выгоду какое-то время.
===
Проблема "наследия" (на мой взгляд) - проблема о длинах сторон треугольника (программирование/разработка = 0, поддержка/внедрение = 1, управление = 2), где поле условной свободы (возможность доработки/поддержки/планирования) при развитии ПО/продукта равна вписанной в треугольник окружности (на мой скромный взгляд, довольно хорошая аналогия).

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

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

[моё] Разработка Программирование IT Текст
7

Эффективный приём (на мой взгляд)⁠⁠

Один из любимых приёмов в программировании - использование ассоциативного массива вида "ключ = ссылка на подпрограмму", что позволяет формировать необходимую функциональность (в т.ч. и отключать то, что не требуется при определённой конфигурации) на этапе чтения/перечитывания файла конфигурации (или при старте скрипта/программы).
===
P.S. Для кого-то (из числа наиболее опытных программистов) тезис/приём может показаться очевидной очевидностью, но, как говорится, не каждый программист не является новичком.
===
UPD. Ассоциативный массив в рамках публикации = ассоциативный массив ЯП Perl 5.

[моё] Разработка Программирование IT Текст Perl
8

С чего стоит начать? (backend-app)⁠⁠

Создание backend-приложения стоит начинать с файла конфигурации (или набора файлов конфигурации).

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

===
Лично мне по душе именно этот подход.
Файл конфигурации сродни логич. блок-схеме, хотя одно другого не исключает (а скорее дополняет).
===
В качестве примера - блок конфигурации услуги "Простой чат/simple_chat" софта/ПО собственной разработки.

P.S. Подразумевается, что ТЗ определено и не вызывает нареканий.
С чего стоит начать? (backend-app) Разработка, Программирование, IT, Конфигурация
[моё] Разработка Программирование IT Конфигурация
15

Первая публикация⁠⁠

Доброго времени суток!
(Доброго утра! Доброго дня! Доброго вечера! Доброй Ночи!)

Зарегистрировался на Пикабу для поиска потенциальных покупателей узкоспециализированного ПО собственной разработки (на Perl 5).

Подробнее тут:
1) https://vk.com/wall-171156115_117
2) https://t.me/server_soft_pro/8

Основные преимущества (ПО для осуществления SMS-рассылок) обозначены ниже.

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

2) Максимальная скорость рассылки ~ 2500 смс в секунду (на один экземпляр рассыльщика с одним smpp-коннектом).

3) Настраиваемая скорость отправки для каждого конкретного smpp-соединения.

4) Динамическое понижение скорости отправки при получении от целевого smpp-коннекта (SMS-центра) заранее определённых (в файле конфигурации) кодов ошибок.

5) Отправка SMS с использованием функций выбора целевого smpp-коннекта (любой доступный, по номеру отправителя, по номеру получателя);

6) Отложенная отправка (с указанием конкретной даты начала рассылки);

7) Настраиваемая совместная обработка очередей сообщений различными приложениями-рассыльщиками;

8) Настраиваемый контроль smpp-соединений (отправка / приём enquire_link / enquire_link_resp).

9) Настраиваемая скорость приёма входящего трафика (отчёты о доставке и проч.) для каждого smpp-соединения.

10) Возможность скрывать содержание входящих и исходящих сообщений в лог-файлах для определённого smpp-коннекта.

11) Настраиваемые условия (по коду ошибки в resp-ах) автоматического переподключения к smpp-соединению.

12) Возможность автоматической транслитерации содержания отправляемых сообщений.

13) Встроенный функционал вида "перезвони мне / заплати за меня".

14) Концепция приложения - максимальная независимость от сторонних модулей, т.к. ПО представляет собой монолитное решение, для работы которого требуется минимальный набор компонентов (в рамках целевой операционной системы).
15) Функционал "SMS-чат / simple_chat".

Ссылка на ПО и документацию: https://github.com/vladimir-chursin000/sms_sender


На данный момент софт работает под CentOS7 (RHEL7-based) и AlmaLinux8 (RHEL8-based).

===
P.S. Также планирую публиковать небольшие заметки (мысли, идеи) на тему программирования.
Показать полностью
[моё] Программирование IT Разработка Perl Linux Текст
14
Отличная работа, все прочитано!