Arch Linux на VPS

Немного статистики

Сразу же начинаем анализировать:

[root@334009 ~]# df -H
Filesystem      Size  Used Avail Use% Mounted on
dev             501M     0  501M   0% /dev
run             509M  578k  509M   1% /run
/dev/sda1        22G  1.3G   19G   6% /
tmpfs           509M     0  509M   0% /dev/shm
tmpfs           509M     0  509M   0% /tmp
tmpfs           102M     0  102M   0% /run/user/0

Занято всего чуть больше гигабайта - неплохо (хотя, конечно, куда там до Alpine).

[root@334009 ~]# free -m
               total        used        free      shared  buff/cache   available
Mem:             970          74         795           1         100         774
Swap:              0           0           0

Тоже, наверное, относительно пристойно. Хотя то, что и в Arch "проник" systemd (оказывается, аж в 2012-13 годах), свободной оперативной памяти не добавляет.

Обновляемся

pacman -Syu

Или нет - посыпались ошибки signature from … is in unknown trust и, как следствие, File /var/cache/pacman/pkg/…pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).

Хотя частичное обновление как бы под запретом, обновляем только archlinux-keyring (предварительно на всякий случай еще раз обновим базу пакетов):

pacman -Syy
pacman -S archlinux-keyring

К счастью после этого обновление сработало. Перезагружаемся… И отвалился SSH с ошибкой Start request repeated too quickly. Но на самом деле в логах сервис ругается на ключи - +ssh-rsa,ssh-dss. Точнее сказать, на последний. Так что установил мой любимый (ну как…) Midnight Commander (благо была VNC-консоль):

pacman -S mc

И отредактировал /etc/ssh/sshd_config (убрал этот самый ssh-dss). Это была то ли самодеятельность хостера, то ли образ очень старый.

systemctl restart sshd

Заработало.

Fail2ban

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

pacman -S fail2ban

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

Создаем файл /etc/fail2ban/jail.d/sshd.local:

[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
mode      = aggressive
enabled   = true
maxretry  = 3
bantime   = 12h

Включаем и запускаем сервис:

systemctl enable --now fail2ban

Смотрим состояние:

[root@334009 ~]# fail2ban-client status
Status
|- Number of jail:      1
`- Jail list:   sshd
[root@334009 ~]# fail2ban-client status sshd
Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     3
|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned: 1
   |- Total banned:     1
   `- Banned IP list:   ...

Как обычно, сразу же кого-то забанил.

Docker

Раз у нас "мощный" VPS, то можно подумать и о Докере, который есть в пакетах.

pacman -S docker docker-compose docker-buildx

Дальше возникает вопрос, что активировать - сокет или сервис. Наверное все-таки включу сокет, поскольку дальше мы развернем веб-сервер "непосредственно".

systemctl enable --now docker.socket

Можно смотреть docker info и/или запустить docker run hello-world.

В конце вывода первой команды были выданы предупреждения:

WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

Теоретически можно было бы это дело включить…

sysctl net.bridge.bridge-nf-call-iptables=1
sysctl net.bridge.bridge-nf-call-ip6tables=1

Да вот только надо еще включать модуль ядра…

modprobe br_netfilter

Короче - проще забить.

PHP

Как я и обещал, попробуем что-нибудь развернуть по старинке. Начнем с PHP FPM, composer и некоего набора расширений. В Arch Linux он довольно скромный, поскольку большинство расширений входит в основной пакет.

pacman -S composer php php-fpm php-gd php-pgsql

Особенность PHP в Arch Linux в том, что расширения, установленные в пакетах, нужно включать (раскомментировать) вручную в /etc/php/php.ini:

extension=gd
zend_extension=opcache
extension=pdo_pgsql
extension=pgsql

Внезапно FPM (/etc/php/php-fpm.d/www.conf) уже настроен на прослушивание сокета. В принципе можно включать:

systemctl enable --now php-fpm

PostgreSQL

Похоже есть тенденция отказа от MySQL в пользу PostgreSQL, так что его и установим (версия 16.3 на момент написания).

pacman -S postgresql

В руководстве предлагается перейти в пользователя postgres и выполнить инициализацию.

[root@334009 ~]# su postgres
[postgres@334009 root]$ initdb -D /var/lib/postgres/data
[postgres@334009 root]$ exit

initdb: warning: enabling "trust" authentication for local connections
initdb: hint: You can change this by editing pg_hba.conf or using the option -A, or --auth-local and --auth-host, the next time you run initdb.

Не очень мне это понравилось, если честно, ну да ладно. В следующий раз обязательно с параметром инициализируюсь! С другой стороны, чтобы подключиться извне, все равно нужен SSH-туннель, так что при определенных обстоятельствах (скажем если база всего одна и/или только вы пользуетесь сервером) даже такая схема имеет право на существование. Запускаемся:

systemctl enable --now postgresql

Переключаемся обратно в postgres и либо создаем пользователя и базу соответствующими командами, либо запросами SQL через командный интерфейс (psql). Для определенности - командами.

[root@334009 ~]# su postgres
[postgres@334009 root]$ createuser --interactive
Enter name of role to add: drupal
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) n
Shall the new role be allowed to create more new roles? (y/n) n
[postgres@334009 root]$ createdb drupal -O drupal
[postgres@334009 root]$ exit

Apache

Исходя из имени пользователя и БД внимательный читатель догадался, что мы установим данную CMS (или даже CMF, как они сами себя определяют). Что же касается веб-сервера, то "у нас нет другого выбора" клише. А все из-за того, что разработчики Drupal имеют весьма своеобразные представления о прекрасном, что, в свою очередь, ведет к умопомрачительному .htaccess, адаптировать который под другие веб-сервера нет абсолютно никакого желания (впрочем я как-то все же попытался адаптировать правила от 7-го Drupal к Caddy).

pacman -S apache

Подправим конфигурацию /etc/httpd/conf/httpd.conf. Включаем нужные модули (в частности mod_proxy_fcgi, раз уж установили php-fpm), и отключаем ненужные (скажем директории пользователей). Автоиндекс наверное тоже.

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_fcgi_module modules/mod_proxy_fcgi.so
#LoadModule autoindex_module modules/mod_autoindex.so
#LoadModule userdir_module modules/mod_userdir.so
LoadModule rewrite_module modules/mod_rewrite.so
#Include conf/extra/httpd-autoindex.conf
#Include conf/extra/httpd-userdir.conf

В этом же файле, забегая вперед, настроим document root и соответствующую директорию:

DocumentRoot "/srv/http/drupal/web"
<Directory "/srv/http/drupal/web">
    #
    # Possible values for the Options directive are "None", "All",
    # or any combination of:
    #   Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
    #
    # Note that "MultiViews" must be named *explicitly* --- "Options All"
    # doesn't give it to you.
    #
    # The Options directive is both complicated and important.  Please see
    # http://httpd.apache.org/docs/2.4/mod/core.html#options
    # for more information.
    #
    Options FollowSymLinks

    #
    # AllowOverride controls what directives may be placed in .htaccess files.
    # It can be "All", "None", or any combination of the keywords:
    #   AllowOverride FileInfo AuthConfig Limit
    #
    AllowOverride All

    #
    # Controls who can get stuff from this server.
    #
    Require all granted
</Directory>

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

<FilesMatch \.php$>
    SetHandler "proxy:unix:/run/php-fpm/php-fpm.sock|fcgi://localhost/"
</FilesMatch>

Неочевидным образом часть |fcgi://localhost/ нужна, иначе не работает, а путь к сокету на всякий случай перепроверьте по настройкам PHP FPM.

Стартуем:

systemctl enable --now httpd

Drupal

Поехали:

cd /srv/http
composer create-project drupal/recommended-project drupal
chown -R http:http /srv/http/drupal

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

Стало ясно, что за demo_umami такой (из инструкции). Оказывается, это "Демо: журнал еды Umami". Почему бы и нет.

База данных и имя пользователя - drupal, без пароля (в соответствии с настройками PostgreSQL).

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

Заработало (а впрочем, почему не должно было? )

Заключение

Про FTP, наверное, особого смысла рассказывать нет - с актуальным Drupal (да и вообще) положено работать через git (pacman -S git) и composer. Хотя, конечно же, "большая тройка" (ProFTPD, Pure-FTPd и vsftpd) есть. Советую выбрать одного из первых двух из-за поддержки виртуальных пользователей.

Понятно, что за счет Докера можно установить что угодно и как угодно, но если говорить о "классическом" развертывании, то специфика Arch Linux в настройке PHP мне почему-то не очень понравилась. Возможно потому, что она оказалась излишне специфической. Но зато "rolling release" и относительная компактность (по крайней мере на старте). Есть о чем подумать, особенно если от операционной системы вам по сути нужен только Docker.