Скрипты для управления виртуальными хостами на веб-сервере Debian

Хочу поделиться небольшой наработкой, которая упрощает администрирование веб-севера, работающего под управлением Debian-подобной операционной системы. Сразу оговорюсь, я далеко не гуру в этой области, просто в какой-то момент мне понадобилось поднять vsftpd, nginx, PHP-FPM и PostgreSQL. Ни для кого не секрет, что при добавлении виртуальных хостов, настройке пулов PHP-FPM и создании баз данных, приходится выполнять одни и те же действия. Удаление виртуальных хостов со всем, что с ними связано, а также создание резервных копий тоже весьма однообразны. Поэтому было бы неплохо обзавестись скриптами, которые автоматизируют все эти вещи.

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

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

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

К делу


Итак, имеется несколько скриптов:
  • siteadd.sh — для создания виртуального хоста;
  • passwd.sh — для смены пароля;
  • backup.sh — для создания резервной копии;
  • sitedel.sh — для удаления виртуального хоста.

Как с ними работать, описано на вики, но общая идея такова, что, например, при создании виртуального хоста test.ru скрипт спрашивает, какой пароль нужно назначить пользователю test.ru, создает этого пользователя в системе, затем создает папку /var/www/data/test.ru/public_html с файлом-заглушкой index.html и дает все необходимые права пользователю test.ru.

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

Если при вызове скрипта указан параметр --no-php, то пул PHP-FPM не настраивается, а при создании файла конфигурации nginx используется шаблон без поддержки PHP. При наличии параметра --no-pgsql, в PostgreSQL не создается база данных и пользователь.

При изменении пароля для виртуального хоста test.ru скрипт спрашивает новый пароль и назначает его как для пользователя test.ru в системе, так и для пользователя test_ru в PostgreSQL.

При создании резервной копии для виртуального хоста test.ru скрипт создает:
  • архив файлов /var/www/backup/test.ru/YY-mm-dd_HH:ii:ss.tar.gz;
  • дамп базы /var/www/backup/test.ru/YY-mm-dd_HH:ii:ss.sql.

При удалении виртуального хоста test.ru скрипт удаляет базу данных и пользователя test_ru из PostgreSQL, удаляет папку /var/www/data/test.ru и пользователя test.ru из системы. Резервные копии не удаляются.

Следует отметить, что есть две версии скриптов:
  • обычная версия, которая лежит в ветке default;
  • версия с поддержкой передачи параметров в формате JSON, которая лежит в ветке json.

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

Что дальше?


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

На этом пока все. Напоминаю, что скрипты можно скачать тут. Буду рад замечаниям и пожеланиям. Спасибо за внимание!
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 10

    0
    Конфиги nginx не пойдут вообще
    во первых один сайт на юзера — неа, не пойдет
    во вторых строго забит путь, причем под него не подойдет почти ни один фреймворк — ни одного реврайта

    такое можно было нарисовать на одних конфигах

    server {
    listen 80 default;

    server_name _;
    root /srv/www/$host/current/web/;

    fastcgi_buffer_size 256k;
    fastcgi_buffers 8 256k;
    client_max_body_size 200m;

    error_log /srv/www/logs/error.log;
    access_log /srv/www/logs/access.log;

    # strip app.php/ prefix if it is present
    rewrite ^/app\.php/?(.*)$ /$1 permanent;

    location / {
    index app.php;
    try_files $uri @rewriteapp;
    }

    location @rewriteapp {
    rewrite ^(.*)$ /app.php/$1 last;
    }

    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    location ~ ^/(app|app_dev)\.php(/|$) {
    fastcgi_pass unix:/srv/www/php-fpm.socket;
    fastcgi_split_path_info ^(.+\.php)(/.*)$;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_param SERVER_NAME $host;
    }
    }

    Это пример конфига симфони2 + капифони на кучу сайтов — нужно создать только папку в директории
      0
      Конфиги и общая схема будут усовершенствованы по мере моего развития в области администрирования. Спасибо за замечания — обязательно поработаю над этим.
      0
      Хе, вчера только подобное писал.

      У вас добавляет/удаляет БД Postgree, но чаще используется mySql.
      У меня так добавляется база:
      sqllogin=«root»
      sqlpass=«xxxxx»
      passdb=«yyyyy»

      # Создаем базу и пользователя
      echo «CREATE USER '$nd'@'localhost' IDENTIFIED BY '$passdb'» | mysql -u$sqllogin -p$sqlpass

      echo «CREATE DATABASE IF NOT EXISTS $nd» | mysql -u$sqllogin -p$sqlpass
      # либо так — utf8
      echo «CREATE DATABASE IF NOT EXISTS $nd CHARACTER SET utf8 COLLATE utf8_unicode_ci» | mysql -u$sqllogin -p$sqlpass

      # Привелегии пользователя только на базу
      echo «GRANT ALL PRIVILEGES ON $nd. * TO '$nd'@'localhost' IDENTIFIED BY '$passdb'» | mysql -u$sqllogin -p$sqlpass

      Может и коряво, но работает

        0
        Согласен, что MySQL используется чаще. Через какое-то время доработаю скрипты и для него.
        0
        Писал нечто подобное когда-то. Может пригодиться кому-нибудь ahc. Оно для PHP, Python, Ruby and etc.
          0
          Для парсинга параметров передаваемых скрипту лучше использовать getopts, или для поддержки long parameters (--param-name) и если не критична переносимость — setopt
            0
            Поясните, пожалуйста, в чем именно getopts лучше getopt?
              0
              я, кстати, опечатался — getopt.

              Вы неверно поняли моё сообщение. Имеется ввиду, что лучше использовать getopt или getopts для парсинга параметров, чем парсить их самостоятельно.

              А вообще из плюсов getopts — это то, что это встроенная команда bash'а, а getopt GNU'тая внешняя утилита, которая входит в пакет util-linux (Deb-based systems). Т.е. getopt насколько я знаю в *BSD системах нет.
                0
                Используется именно getopt, просто вынесено отдельно. Вручную параметры не парсятся.
                  0
                  Видимо, невнимательно посмотрел. Извиняюсь в таком случае. :)

          Only users with full accounts can post comments. Log in, please.