Точка входа DWT написана на языке C — это небольшая программа, исполняющая другие скрипты. Изначально у меня была идея сделать систему открытой, поэтому я старался делать её по всем best-practice правилам Open Source с интерактивными диалогами и подсказками. Исходный код тоже составлялся красиво и упорядоченно, насколько это возможно.

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

Основной вопрос, который, наверное, мог бы возникнуть: зачем? Зачем я написал консольный интерфейс, если существует куча открытых и коммерческих панелей с графическим UI?

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

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

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

Ну и в четвёртых, как показала недавняя история, при возникновении на открытых системах критических уязвимостей безопасности, таких как, например, в прошлом году с Exim4 и PHP-fpm, — всё накрывается медным тазом. Хакеры тупо получают рутовый доступ ко всему серваку. Следовательно, проблем по переустановке всей системы потом не оберёшься.

И моя практика это подтвердила. Но приятно то, что 90% серверов, которые я обслуживал, не пострадало, потому что администрировались они не при помощи панелей управления, а при помощи моих консольных скриптов и конфигов, составленных лично мной с учётом множества потенциально негативных вариантов.

Так, например, о потенциальной дыре PHP-fpm я знал уже за несколько лет до её возникновения, вернее, снаряд в эту воронку уже попадал при определённой конфигурации PHP, и на это тогда обращали внимание администраторы.

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

Таким образом, в безопасности моей системы я убедился за несколько лет её применения на практике. Главное преимущество закрытых систем — высокий уровень стабильности и безопасности. А по функционалу она может практически всё, что могут панели. И даже больше:

✔ Cоздание, удаление пользователей;
✔ Cоздание почтовых ящиков;
✔ Cоздание хостов сайтов вместе с базами данных;
✔ Формирование самоподписных и LetsEncrypt SSL сертификатов;
✔ Расширение сертификатов новыми доменами, их автоматическое продление;
✔ Двухуровневое резервное копирование: бэкап сайта и пользователя целиком;
✔ Создание FTP аккаунтов;
✔ Автоматическая загрузка и установка популярных CMS;
✔ Копирование сайтов для разработки, слияние сайтов после внесения изменений;
✔ Очень гибкая настройка шаблонов различных конфигов серверов и сервисов;
✔ Бесконечная расширяемость системы при необходимости введения нового функционала;
✔ Борьба со спамом и брутфорсом;
✔ Обслуживание логов, системных ссылок, и различных сервисов и многое-многое другое, о чём я не упомянул.

Производительность:

✔ Чистый NGINX + PHP-fpm актуальной версии и других версий при необходимости.
✔ Любая СУБД. Я использую MariaDB.
✔ Нет никаких сторонних программ. Абсолютно все они, кроме NGINX, берутся из родных доверенных репозиториев.
✔ Нет никаких лишних программ и зависимостей. Установщик очень компактный и не превышает размер данного поста.

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