Мне кажется, такие проекты сейчас нужны. Потому что импортозамещение — это не просто "купить российский софт". Это про то, чтобы сделать так, чтобы люди могли с ним работать. А для этого нужны инструменты, которые снижают порог входа. Мой проект, который назвал Focus.it - один из таких инструментов. Не революционный, не идеальный, но вполне рабочий. И если вы сейчас мучаетесь с переводом инфраструктуры на Linux — возможно, стоит посмотреть в его сторону. Этой системой и решил поделиться.. А вдруг кто-то захочет и у себя внедрить ее, или что еще более интересно - захочет что-то доработать в ней и внести туда какой-то новый функционал? Было бы здорово ) Мое свободное для таких проектов время, знания и навыки крайне ограничены.

Далее опишу немного подробнее данный проект..

Что это за зверь такой?

"Focus.it" — это веб-панель для системных администраторов, которые переходят на Linux и чувствуют себя неуверенно. Она не пытается заменить FreeIPA или Puppet. Нет. Она надстраивается поверх уже настроенной инфраструктуры и дает понятный веб-интерфейс для рутинных задач, которые раньше требовали консоли и знания десятка команд

Установил, настроил — и вуаля: все управление DHCP, пользователями, оборудованием и Puppet-нодами в одном месте.

Мониторинг рабочих станций

Первое, что бросается в глаза — это дашборд с активными сессиями. Ты видишь, кто сейчас сидит за каким компьютером, с какого IP и как давно залогинился. Причем данные приходят от простого bash-скрипта, который крутится на каждой рабочей станции и раз в полчаса скидывает JSON-шку в общую папку. А еще там есть история входов, графики активности за 30 дней, топ компьютеров по использованию. Можно фильтровать по кабинету, отделу, статусу. И да, интеграция с FreeIPA — пользователи синхронизируются автоматически

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

И есть одна крутая фича: система генерирует файл подключения для Remmina — SSH или VNC — прямо по кнопке. То есть вам не нужно вспоминать IP-адрес компьютера, чтобы подключиться к нему удаленно. Все уже готово.

Управление DHCP (модуль FocusDHCP)

ISC-DHCP — это зверь, который любит, когда к нему прикасаются с умом. А тут — веб-интерфейс для создания подсетей, резерваций, просмотра аренд.

Вы добавляете подсеть через браузер, указываете диапазон, шлюз, DNS — и система сама генерирует конфиг, проверяет синтаксис, делает бэкап старого и перезагружает сервер. Без SSH. Без риска опечататься в конфиге. Без страха что-то сломать.

Синхронизация аренд — каждые две минуты данные с DHCP-сервера забираются в базу. Всегда актуальная картина по IP-адресам.

Управление Puppet (модуль Focus.run)

Честно скажу, я сам не большой фанат Puppet. Но когда видишь список всех нод с их статусами, ОС, IP, версией агента и все это в таблице с сортировкой и поиском — становится как-то спокойнее.

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

И самое вкусное — модалка с фактами по ноде. Там и сетевые интерфейсы, и CPU, и ОЗУ с прогресс-барами, и диски с заполнением. Это реально удобно, когда нужно быстро понять, что за железо у машины.

Учет оборудования (CMDB)

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

У каждого — инвентарный номер, статус, местоположение, дата покупки, гарантия, поставщик. Можно формировать АРМ (автоматизированные рабочие места) из разных устройств, назначать их сотрудникам, вести историю возвратов.

Как это все работает?

Архитектура, на мой взгляд, простая:

Серверная часть — PHP + PostgreSQL. Все библиотеки (jQuery, Bootstrap, Chart.js, DataTables) лежат локально. Интернет для работы не нужен. Это важно для госучреждений, где доступ в сеть часто ограничен.

Клиентский агент — bash-скрипт, который собирает данные о системе, определяет залогиненных пользователей, формирует JSON и сохраняет его в сетевую папку. Запускается через systemd-таймер.

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

Все это работает по расписанию через cron и systemd. Никаких сложных очередей, никаких микросервисов. Просто и надежно.

Установка

Создан простой web-установщик, он работает пошагово: проверка требований, настройка БД, интеграция с FreeIPA, настройка папки для импорта (куда будут складываться данные с пользовательских машин), подключение к DHCP.

Ссылка на GitHub: https://github.com/kir7177/focus-it/

В планах близких и далеких:

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

• Активы: подружить с модулем puppet и получать информацию о железе из puppet

• Бюджет: параллельно разрабатывается система для контрактной службы в которой подразделения подают заявки на закупку, экономист утверждает их и формирует бюджет с указанием ответственных подразделений по строкам бюджета. Хочется в будущем подружить их, чтобы focus.it получал статьи бюджета и заключенные договора по указанному ИТ-подразделению. Бюджет связать с Активами для отслеживания истории по оборудованию (когда, как и где было приобретено)

The Witchcraft Compiler Collection

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

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

WCC is a collection of compilation tools to perform binary black magic on the GNU/Linux and other POSIX platforms.

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

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

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

Так что материал получился весьма редким.

Сборка и инвольтация эгрегора

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

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

capstone, glibc, libbfd, libdl, zlib, libelf, libreadline, libgsl, make

Однако libbfd ныне стал частью пакета binutils и отдельно более не поставляется, а binutils скорее всего уже установлен по-умолчанию.

Забираем исходники и запускаем сборку:

git clone https://github.com/endrazine/wcc.git
git submodule init && git submodule update && make

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

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

undefined reference to `sframe_encoder_write'

привел наконец к вот такому багрепорту из трекера Debian. Там же был обнаружен и этот адский патч для WCC:

diff -Nru wcc-0.0.2+dfsg/debian/patches/binutils_shared.patch wcc-0.0.2+dfsg/debian/patches/binutils_shared.patch
--- wcc-0.0.2+dfsg/debian/patches/binutils_shared.patch 2020-03-21 19:02:12.000000000 +0200
+++ wcc-0.0.2+dfsg/debian/patches/binutils_shared.patch 2023-01-18 16:09:29.000000000 +0200
@@ -12,7 +12,7 @@
-all::
- $(CC) $(CFLAGS) wcc.c -o wcc -lbfd -lelf -lcapstone
+all:
-+ $(CC) $(CFLAGS) wcc.c -o wcc -l:libbfd.a -lz -ldl -liberty -lelf -lcapstone
++ $(CC) $(CFLAGS) wcc.c -o wcc -l:libbfd.a -l:libsframe.a -lz -ldl -liberty -lzstd -lelf -lcapstone
# $(CC) $(CFLAGS) -m32 -Wl,-rpath /home/jonathan/solution-exp/unlinking/awareness/self/wcc/src/wcc/lib32/ wcc.c -o wcc32 -lelf ./lib32/libbfd-2.24-system.so ./lib32/libcapstone.so.3

cp wcc ../../bin/

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

-+ $(CC) $(CFLAGS) wcc.c -o wcc -l:libbfd.a -lz -ldl -liberty -lelf -lcapstone
++ $(CC) $(CFLAGS) wcc.c -o wcc -l:libbfd.a -l:libsframe.a -lz -ldl -liberty -lzstd -lelf -lcapstone

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

Что я и проделал в файле src/wcc/Makefile:

После исправления, сборка заканчивается успешно и в каталоге bin появляются готовые к использованию "колдунские" приложения:

Теперь можно начинать плести заклинания.

Колдунство первое: превращаем приложение в библиотеку

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

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

Transforming an ELF executable binary into an ELF shared library.

Последовательность заклинаний шагов выглядит так:

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

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

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

Хотя назначение этого поля не является секретом и присутствует даже в Википедии, помимо официального руководства, до столь затейливого его применения никто на моей памяти не доходил. Кроме авторов WCC.

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

The primary use of wcc is to "unlink" (undo the work of a linker) ELF binaries, either executables or shared libraries, back into relocatable shared objects. The following command line attempts to unlink the binary /bin/ls (from GNU binutils) into a relocatable file named /tmp/ls.o

Пример вызова:

wcc -c /bin/ls -o /tmp/ls.o

По идее уже на этой стадии должен быть получен «relocable file», с которым может работать обычный gcc. Например должна отрабатывать команда:

gcc /tmp/ls.o -o /tmp/ls.so -shared

К сожалению в моей Mageia это не сработало, поэтому был использован альтернативный вариант "очищения":

cp /bin/ls /tmp/ls.o
wld --libify /tmp/ls.o

Результат выполнения команды wld теперь спокойно распознается обычным компилятором gcc:

gcc /tmp/ls.o -o /tmp/ls.so -shared

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

file /tmp/ls.so
/tmp/ls.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=68d93a1d888eb560b8842
55a59c37cd6be0adddd, not stripped

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

Но едем дальше.

Колдунство второе: рефлексия для.. чистого С

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

The witchcraft shell accepts ELF shared libraries, ELF ET_DYN executables and Witchcraft Shell Scripts written in Punk-C as an input. It loads all the executables in its own address space and makes their API available for programming in its embedded interpreter.

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

Хотя авторы WCC на голубом глазу заявляют:

This provides for binaries functionalities similar to those provided via reflection on languages like Java.

до рефлексии уровня Java/.NET тут все же очень далеко и вызывать столь интересным образом методы в чужих библиотеках получается далеко не всегда.

Теперь рассказываю, как можно попробовать сие темное колдунство в действии. Интерпретатору wsh из состава WCC скармливается разделяемая библиотека или ELF-приложение:

wsh /usr/sbin/apache2

К сожалению стабильность работы вызывает вопросы, поэтому тут 50/50 — колдунство может сработать, а может выпасть segmentation fault. Если был передан бинарник — автоматически произойдет его «библификация», описанная выше.

Если сработало, появится сообщение зелеными буквами на черном фоне:

loading of libified binary succeeded

И можно будет пытаться вызывать:

a = ap_get_server_banner()
print(a)

Код выше — отдельный язык, такая своеобразная помесь С и Lua, с весьма поэтическим названием:

The resulting API, a powerful combination of lua and C API is called Punk-C

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

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

#!/usr/bin/wsh

-- Computing a MD5 sum using cryptographic functions from foreign binaries
-- (eg: sshd/OpenSSL)

function str2md5(input)

out = calloc(33, 1)
ctx = calloc(1024, 1)

MD5_Init(ctx)
MD5_Update(ctx, input, strlen(input))
MD5_Final(out, ctx)

free(ctx)
return out
end

input = "Message needing hashing\n"
hash = str2md5(input)
hexdump(hash,16)

exit(0)

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

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

Без исходников и без линковки.

Но это далеко не все колдовские приколы, которые позволяет творить WCC.

Колдунство третье: восстановление флагов сборки

Хотя авторы WCC опять несколько преувеличивают, рассказывая про возможность восстановления абсолютно всех флагов сборки:

When compiling C code, it is often required to pass extra arguments to the compiler to signify which shared libraries should be explicitly linked against the compile code. Figuring out those compilation parameters can be cumbersome. The wldd commands displays the shared libraries compilation flags given at compile time for any given ELF binary.

На практике же речь идет только о библиотеках:

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

Колдунство четвертое: генератор заголовков

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

The wcch command takes an ELF binary path as a command line, and outputs a minimal C header file declaring all the exported global variables and functions from the input binary. This automates prototypes declaration when writing C code and linking with a binary for which C header files are not available.

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

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

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

cat /tmp/sshd.h |head -c 500

/**
* Automatically generated by the Witchcraft Compiler Collection 0.0.9
**/
extern void *optind;
extern void *obstack_alloc_failed_handler;
extern void *error_message_count;
extern void *argp_err_exit_status;
extern void *_IO_2_1_stderr_;
extern void *stdin;
extern void *program_invocation_short_name;
[alex@illuminati wcc]$

Думаю очевидно, что артефакты вроде:

extern void *_IO_2_1_stderr_;
extern void *stdin;

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

Резюмируя

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

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

Если вы занимаетесь серьезной разработкой на C/C++ под Linux и ненавидите человескую расу, думаю стоит ознакомиться с этой штукой поближе, чтобы включить WCC в свои темные планы и нечестивые эксперименты.

P.S.

Оригинал статьи в нашем блоге, статья была опубликована на Хабре.

[myproject.local]

web_engine = Nginx # или Apache

php_engine = PHP-8.2

public_dir = {base_dir}\public

В 5 версии было все более нативной , настраивалось через графическое дерево в меню open server , новый же подход позволяет задать более гибкие настройки.

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

Глобально через меню open server модули =>http=> выбираем нужный веб движок apache или nginx

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

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

4) Что касается файла project.ini , и настройки корневой папка .Если файл лежит именно в корне проекта , оставляем настройку

[myproject.local]

public_dir = {base_dir}

если же присутствуют подпапки,как в laravel к примеру :

home/

└── myproject.local/

├── app/

├── config/

├── public/ ← вот она, папка с точкой входа

│ ├── index.php

│ └── style.css

├── storage/

└── vendor/

То добавляем через / название папки где находится наша точка входа в приложение

[myproject.local]

public_dir = {base_dir}/public

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

Что будет, если не указать public_dir?

Без public_dir в project.ini домен появится, но сервер не будет знать, откуда отдавать файлы, и вы увидите ошибку 404 или пустую страницу.

5)Как теперь работают домены (Прощай, файл hosts!)

В 5-й версии мы были обязаны вручную править системный файл C:\Windows\System32\drivers\etc\hosts, прописывая туда строки вида 127.0.0.1 myproject.local.

В Open Server 6 всё работает иначе:

В программу встроен собственный DNS-сервер.

При запуске OSP 6 автоматически перехватывает DNS-запросы на вашем компьютере.

Как только вы прописали имя проекта в скобках [myproject.local] внутри project.ini, программа сама связывает этот домен с нужным внутренним IP-адресом.

Вам больше не нужно трогать файл hosts — Windows мгновенно увидит ваш сайт по его DNS-имени. Если вам всё же нужен доступ по IP, проект по умолчанию доступен на локальном адресе http://127.0.0.1 (или с указанием конкретного порта, если вы изменили его в глобальных конфигах)

6)Важное изменение при подключении к БД (MySQL)

Раньше в конфигурационных файлах ваших сайтов (например, в .env файле Laravel или wp-config.phpв WordPress) в строке подключения к базе данных (DB_HOST) мы всегда писали localhost или 127.0.0.1.

В OSP 6 из-за изолированной архитектуры модулей localhost больше не работает!

Теперь для подключения к MySQL нужно использовать:

DNS-имя модуля: Например, MySQL-8.2 (указывайте ровно то имя, которое запущено у вас в системе).

Или конкретный IP-адрес: По умолчанию OSP 6 выделяет модулям баз данных адреса в локальной подсети. Чаще всего это 127.0.0.1, но с уникальным портом, либо выделенный IP из диапазона 127.x.x.x (смотрите точный IP/порт в консоли OSP при старте модуля).

Пример настройки файла .env ,в проекте

DB_CONNECTION=mysql

DB_HOST=MySQL-8.2 # Вместо localhost пишем имя модуля DNS

DB_PORT=3306

DB_DATABASE=my_db

DB_USERNAME=root

DB_PASSWORD=

Вот и все основные нюансы для запуска проекта в open server v6.

А если вы не знаете какой веб-сервер выбрать apache или nginx .Об этом я тоже расскажу в след. посте.

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

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

Формально бэкапы существовали. За них отвечала команда администрирования виртуальной инфраструктуры. Доступа к гипервизорам, их настройкам и самим резервным копиям у меня не было. Проверить консистентность я не мог, сколько займёт восстановление — не знал, и вообще не был уверен, что в случае аварии сервер реально поднимется. Поэтому для себя вывел простое правило: пока не проверил восстановление — бэкапа не существует.

Первый эксперимент

Из локальных средств резервного копирования нашлась интересная практика: раз в неделю снималась SquashFS-копия файловой системы и складывалась на NAS. С неё и начал.

После нескольких итераций получилось поднять сервер вручную: загрузка с Live-CD, разворачивание файловой системы, переустановка GRUB — и система стартовала уже с восстановленного диска.

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

Чёрный ящик

Схема бэкапа была простой: Puppet раскладывал скрипт резервного копирования на сервер, cron запускал его по расписанию. На этом контроль заканчивался. Есть ли свежий бэкап? Не пустой ли он? Можно ли на него рассчитывать? Ответа на эти вопросы не было.

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

• существует ли текущий бэкап;

• существует ли предыдущий;

• не слишком ли маленький получившийся архив;

• не отличается ли его размер от предыдущего больше допустимого порога.

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

Новая проблема

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

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

Оркестратор

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

Привязки к конкретным машинам нет. Через Puppet любому серверу можно назначить роль клиента резервного копирования, роль оркестратора или обе сразу. Пользователи, права, ключи, скрипты, расписание — всё поднимается автоматически. Благодаря этому оркестратор можно перенести на другую машину без ручной перенастройки инфраструктуры.

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

Скрипт бэкапа

Заодно доработал сам скрипт резервного копирования. Теперь он:

• автоматически удаляет собственные копии старше четырёх недель, не трогая данные других серверов;

• проверяет размер созданного архива и сравнивает его с предыдущим;

• кроме самого архива рядом сохраняется информация, необходимая для восстановления сервера;

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

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

Итог

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

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

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