chroot: failed to run command /bin/zsh

Дата: 04.02.2017

Для авторизации по ssh привык использовать ключи. И вот в один прекрасный день пришлось сбросить пароль root. Доступа по ssh к серверу не было, а под рукой был только загрузочный образ SystemRescueCd. После команды монтирования получил следующую ошибку:

chroot /mnt
chroot: failed to run command '/bin/zsh'  no such file or directory

В данном случае проблема связана с тем, что chroot пытается использовать zch качестве командной оболочки. На установленной у меня системе zch не используется. Поэтому необходимо указать расположение bash. Для решения проблемы достаточно просто выполнить:

chroot /mnt /bin/bash

Access denied for user ‘debian-sys-maint’@’localhost’

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

mysql_upgrade: Got error: 1045: Access denied for user 'debian-sys-maint'@'localhost' (using password: YES) while connecting to the MySQL server

Суть проблемы состоит в том, что mysql_upgrade не может получить доступ к нашей базе под указанным в файле debian.cnf паролем. Если выполнить команду:

cat /etc/mysql/debian.cnf

Мы получить результат следующего вида:

# Automatically generated for Debian scripts. DO NOT TOUCH!
[client]
host     = localhost
user     = debian-sys-maint
password = n4aSHUP04s1J32X5
socket   = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
user     = debian-sys-maint
password = n4aSHUP04s1J32X5
socket   = /var/run/mysqld/mysqld.sock
basedir  = /usr

Нас интересует параметр password. Копируем это пароль, после чего в MySQL необходимо выполнить запрос:

mysql> GRANT ALL PRIVILEGES ON *.* TO 'debian-sys-maint'@'localhost' IDENTIFIED BY 'n4aSHUP04s1J32X5';

С первого раза не сработало, MySQL ругался на то, что пароль не соответствует правилам безопасности. Тогда просто можно добавить к паролю любой символ и повторить команду. При этом не забудьте указать новый пароль в фале debian.cnf.

Для того чтобы имения вступили в силу, необходимо перезапустить MySQL.

Сброс пароля MySQL

В интернете достаточно много материалов про сброс пароля root в MySQL 5.7. Процесс достаточно простой и уже много раз описывался в сети, но связи с тем, что метод опробован на практике, решил записать последовательность своих действий. Все действия выполнялись в Ubuntu 16.04 и MySQL 5.7.

Проверим версию MySQL:

mysql --version
mysql  Ver 14.14 Distrib 5.7.16, for Linux (x86_64) using  EditLine wrapper

От версии пакета MySQL будет зависть SQL-запрос, который необходимо выполнить для изменения пароля. Далее останавливаем MySQL:

service mysql stop

Создаем каталог, устанавливаем на него права:

mkdir -p /var/run/mysqld
chown -R mysql /var/run/mysqld

Запускаем MySQL без загрузки grant tables, в целях безопасности отключаем сеть:

mysqld_safe --skip-grant-tables --skip-networking &

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

mysql -u root

Перезагрузим таблицы привилегий:

mysql> FLUSH PRIVILEGES;

Теперь осталось только изменить пароль root. Если у вас MySQL 5.7.6 или новее, MariaDB 10.1.20 или новее, используем следующую команду:

ALTER USER 'root'@'localhost' IDENTIFIED BY 'new_password';

Для версий MySQL 5.7.5 или старее, MariaDB 10.1.20 или старее, используем команду:

SET PASSWORD FOR 'root'@'localhost' = PASSWORD('new_password');

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

Output
Query OK, 0 rows affected (0.00 sec)

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

mysql -u root -p

Таким образом, мы спросили пароль root и получили доступ к MySQL с правами администратора.

Включаем поддержку Brotli в Nginx

Этот алгоритм сжатия появился совсем недавно, связи с чем о использовании Brotli еще мало упоминаний в сети. Для начала необходимо упомянуть о том, что этот Brotli из себя представляет. Если кратко, Brotli — алгоритм сжатия данных основанный на современном варианте алгоритма LZ77. Brotli был разработан и представлен компанией Google в 2015 году как специализированный алгоритм для сжатия веб-шрифтов. В дальнейшем была представлена версия Brotli, которая содержала улучшения направленные на сжатие всего интернет-трафика (HTML, CSS, JS).

Сейчас момент Brotli используют для ускорения загрузки веб-страниц, его поддержка включена по умолчанию в Chrome 51+, Firefox 47+ и мобильным Chrome. По сравнению с gzip, алгоритм Brotli показывает сравнимую скорость, но при этом имеет лучшие показатели сжатия данных. Следует отметить, что Brotli несовместим с gzip и работает только для HTTPS-ресурсов.

На данный момент нет официального модуля для поддержки Brotli в Nginx. Зато мы имеем возможность использовать сторонние модули, которые параллельно развиваются Google и Cloudflare. В данном посте я расскажу о сборке Nginx с включенным модулем Brotli от Cloudflare. Если интересно, то исчерпывающую информацию по работе алгоритма Brotli можно найти в блоге Cloudflare.

Процесс аналогичен сборке Nginx с любыми другими модулями. Для начала необходимо скачать исходники Nginx. Добавим в файл /etc/apt/sources.list официальный репозиторий для mainline-ветки Nginx:

deb http://nginx.org/packages/mainline/debian/ codename nginx
deb-src http://nginx.org/packages/mainline/debian/ codename nginx

Скачиваем и устанавливаем PGP-ключ, после чего не забудьте обновить индекс пакетов apt:

cd /tmp/ && wget http://nginx.org/keys/nginx_signing.key && apt-key add nginx_signing.key
apt-get update

Устанавливаем пакет dpkg-dev и все необходимые для сборки Nginx зависимости:

apt-get install dpkg-dev
apt-get build-dep nginx
apt-get install git autoconf libtool

Скачиваем исходники Nginx:

cd /usr/src
apt-get source nginx

Получаем код модуля ngx_brotli_module:

git clone https://github.com/cloudflare/ngx_brotli_module.git

В каталог с модулем ngx_brotli_module необходимо загрузит исходники библиотеки libbrotli:

cd /usr/src/ngx_brotli_module
git clone https://github.com/google/brotli.git

Перед началом сборки и компиляции необходимо внести изменения в конфигурационный файл:

nano /usr/src/nginx-1.11.5/debian/rules

Необходимо добавить путь к исходникам ngx_brotli_module в содержимое переменно CFLAGS:

config.status.nginx: config.env.nginx
        cd $(BUILDDIR_nginx) && \
        CFLAGS="" ./configure --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --add-module=/usr/src/ngx_brotli_module --with-cc-opt="$(CFLAGS)" --with-ld-opt="$(LDFLAGS)"
        touch $@

Дополнительно рекомендую собрать Nginx c поддержкой APLN. Переходим к компиляции и сборке deb-пакета Nginx:

cd /usr/src/nginx-1.11.5
dpkg-buildpackage -rfakeroot -uc -b

Если в процессе не было ошибок, то в рабочем каталоге мы увидим собранные deb-пакета Nginx.

Для активации режима сжатия Brotli указываем следующие параметры:

brotli on;
# уровень компрессии от 1 до 11
brotli_comp_level 6;
# минимальный размер файла для использования сжатия
brotli_min_length Num;

Когда Brotli включен, он получает приоритет наl gzip, если браузер не поддерживает Brotli, данные сжимаются при помощи gzip. Теперь остается только проверить поддерживает ли наш сайт сжатие Brotli с помощью онлайн сервиса Brotli Test.

Очистить журнал systemd

Дата: 10.11.2016Метки:

На сегодняшний день systemd стал де-факто стандартом для современных Linux-систем. Его компонент journal cобирает все системные сообщения: сообщения ядра, служб и приложений. После чего происходит их запись в виде бинарных файлов. Для просмотра и управления файлами логов используется утилита journalctl.

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

Однако ситуация требует внимания и нуждается в периодическом мониторинге. Чтобы посмотреть общий размер файлов журнала systemd, достаточно выполнить команду:

journalctl --disk-usage

Что бы ограничить бесконтрольное хранение журнала, нам необходимо выполнить настройку ротации логов. С помощью опций −−vacuum-size и −−vacuum-time мы можем соответственно установить предельно допустимый размер и срок хранения для хранимых на диске логов.

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

journalctl --vacuum-size=1G

Подобным образом образом работает опция −−vacuum-time. Команда установит для логов срок хранения, по истечении которого они будут удалены автоматически:

journalctl --vacuum-time=1years

Дополнительно нужно прописать настройки ротации логов в конфигурационный файл:

vi /etc/systemd/journald.conf

Настройки ротации логов включают следующие параметры:

# Максимальный объём логов на диске
SystemMaxUse=
# Объём свободного места на диске после сохранения логов
SystemKeepFree=
# Объём файла лога, по достижении которого он должен быть удален
SystemMaxFileSize=
# Максимальный объём, который логи могут занимать в /run
RuntimeMaxUse=
# Объём свободного места, которое должно оставаться в /run после сохранения логов
RuntimeKeepFree=
# Объём файла лога, по достижении которого он должен быть удален из /run.
RuntimeMaxFileSize=

Применяем настройки без перезапуска системы:

systemctl restart systemd-journald

Автоматическая установка Debian

Установку Debian можно полностью автоматизировать путем использования специального файла с заранее указанным сценарием ответов на все вопросы инсталлятора. Данный способ автоматической установки называется Debian Preseed. Далее созданный файл-сценарий ответов preseed.cfg запаковывается в initrd установочного iso-образа Debian.

Информацию с описанием параметров сценария Preseed можно можно найти на официальном сайте. И я не вижу смысла дублировать эту информацию в своем блоге. Вместо этого я сразу размещу содержимое используемого мной файла preseed.cfg, а если у вас возникнут вопросы, то описание параметров вы всегда сможете найти по указанной выше ссылке.

В файле сценариев для своих нужд я использовал такие переменные параметры, как: ($IP), ($NETMASK), ($GATEWAY). Ниже привожу пример моего файла сценария Debian Preseed. Внимание! Особенно обратите внимание на блок ### Partitioning, вначале которого я полностью забиваю нулями содержимое диска. Данные будут полностью стерты со всех дисков в системе, будьте крайне осторожны.

### Localization
d-i debian-installer/locale string en_US
d-i console-setup/ask_detect boolean false
d-i keyboard-configuration/xkb-keymap select us

### Network configuration
d-i netcfg/choose_interface select auto
d-i netcfg/disable_autoconfig boolean true
# IPv4
d-i netcfg/get_ipaddress string ($IP)
d-i netcfg/get_netmask string ($NETMASK)
d-i netcfg/get_gateway string ($GATEWAY)
d-i netcfg/get_nameservers string ($NAMESERVER)
d-i netcfg/confirm_static boolean true
# Hostname
d-i netcfg/get_hostname string ($HOSTNAME)

### Mirrors
d-i mirror/country string manual
d-i mirror/http/hostname string ($MIRROR)
d-i mirror/http/directory string /debian
d-i mirror/http/proxy string ($HTTPPROXYv4)
d-i mirror/suite string stable

### Account setup
d-i passwd/root-login boolean true
d-i passwd/make-user boolean false
d-i passwd/root-password-crypted password ($PASS_CRYPT)
d-i user-setup/allow-password-weak boolean true
d-i user-setup/encrypt-home boolean false

### Clock
d-i clock-setup/utc boolean true
d-i time/zone string ($TIMEZONE)
d-i clock-setup/ntp boolean false

### Partitioning
d-i partman/early_command string \
for DISK in $(list-devices disk); do \
    parted -s ${DISK} mklabel gpt; \
    parted -s ${DISK} mklabel msdos; \
        dd if=/dev/zero of=${DISK} bs=512 count=1; \
done;

d-i partman-auto/method string regular
d-i partman-basicfilesystems/no_swap boolean false
d-i partman-auto/expert_recipe string                         \
      root ::                                                 \
              5000 5000 -1 ext4                               \
                      method{ format } format{ }              \
                      use_filesystem{ } filesystem{ ext4 }    \
                      mountpoint{ / }                         \
              .                                               \
d-i partman-partitioning/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true
d-i partman/mount_style select uuid

### Apt setup
d-i apt-setup/contrib boolean true
d-i apt-setup/services-select multiselect security, volatile
tasksel tasksel/first multiselect minimal
d-i pkgsel/include string openssh-server
popularity-contest popularity-contest/participate boolean false

### Grub
d-i grub-installer/only_debian boolean true
d-i grub-installer/with_other_os boolean true
d-i grub-installer/bootdev string default

### Finish install
d-i finish-install/keep-consoles boolean true
d-i finish-install/reboot_in_progress note

d-i preseed/late_command string \
        sed -i '/^PermitRootLogin/c PermitRootLogin yes' /target/etc/ssh/sshd_config ;\
        if [ -n "($SSHPUBKEYS)" ]; then \
                mkdir -p /target/root/.ssh ;\
                chmod 700 /target/root/.ssh ;\
                echo "($SSHPUBKEYS)" > /target/tmp/keyfile ;\
                cat /target/tmp/keyfile | /target/usr/bin/base64 -d > /target/root/.ssh/authorized_keys ;\
                in-target rm -f /tmp/keyfile ;\
        fi ;\
        sed -i '/^GRUB_CMDLINE_LINUX_DEFAULT/c GRUB_CMDLINE_LINUX_DEFAULT="quiet"' /target/etc/default/grub ;\
        sed -i '/^GRUB_TIMEOUT/c GRUB_TIMEOUT=0' /target/etc/default/grub && in-target update-grub

Сборка rpm пакета Nginx в Centos 7

На данный момент в официальном репозитории Nginx размещены пакеты без поддержки технологии APLN. Возможно, вы успели заметить, что в актуальной версии Chrome ваши сайты перестали работать по протоколу HTTP/2. Связано это с тем, что для сборки Nginx используется старая версия OpenSSL. Хочешь HTTP/2, значит придется собирать Nginx из исходников вручную.

Основной недостаток установки программ при помощи make install — это неудобное управление. Вместо этого мы рассмотрим сборку rpm пакетов из исходников. Все действия я буду производить в дистрибутиве CentOS 7, а в качестве примера буду использовать Nginx 1.11.3.

Устанавливаем все необходимое для сборки и компиляции:

yum groupinstall -y "Development Tools" && yum install rpmdevtools nano yum-utils

Собирать пакеты можно из-под любого пользователя, но делать это из-под root не рекомендуется. Создадим для сборки пакета пользователя builder:

useradd builder
usermod -a -G builder builder

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

rpmdev-setuptree

Для настройки репозитория yum необходимо создать файл:

nano /etc/yum.repos.d/nginx.repo

Копируем в файл следующие строки:

[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/mainline/centos/7/$basearch/
gpgcheck=0
enabled=1

[nginx-source]
name=nginx source repo
baseurl=http://nginx.org/packages/mainline/centos/7/SRPMS/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

Загружаем пакет с исходниками и запускаем установку rmp:

cd /tmp
yumdownloader --source nginx
rpm -Uvh nginx*.src.rpm

Установим все необходимые для сборки Nginx зависимости:

yum-builddep nginx

Скачиваем и распаковываем исходники OpenSSL:

cd /usr/src/
wget https://www.openssl.org/source/openssl-1.0.2h.tar.gz
tar -xvzf openssl-1.0.2h.tar.gz

В параметрах сборки необходимо указать путь к исходникам OpenSSL:

nano ~/rpmbuild/SPECS/nginx.spec

Для примера привожу фрагмент моего файла:

--with-http_slice_module \
--with-mail \
--with-mail_ssl_module \
--with-file-aio \
--with-ipv6 \
--with-openssl=/usr/src/openssl-1.0.2h \

Запускаем сборку пакета:

cd ~/rpmbuild/SPECS/
rpmbuild -ba nginx.spec

После завершения сборки переносим rpm из папки:

cd ~/rpmbuild/RPM/
ls
nginx-1.11.3-1.el7.centos.ngx.x86_64.rpm
nginx-debuginfo-1.11.3-1.el7.centos.ngx.x86_64.rpm
nginx-module-geoip-1.11.3-1.el7.centos.ngx.x86_64.rpm
nginx-module-image-filter-1.11.3-1.el7.centos.ngx.x86_64.rpm
nginx-module-njs-1.11.3.0.1.0-1.el7.centos.ngx.x86_64.rpm
nginx-module-perl-1.11.3-1.el7.centos.ngx.x86_64.rpm
nginx-module-xslt-1.11.3-1.el7.centos.ngx.x86_64.rpm

И запускаем установку командой:

rpm -Uvh nginx*.rpm

Failed to execute ban jail ‘sshd’ action ‘iptables-multiport’

Связи с тем, что для выхода в интернет я использую статический IP, мне достаточно редко приходится использовать fail2ban на своих серверах. Я предпочитаю просто закрыть доступ к SSH в iptables. После настройки VMmanager, был автоматически установлен пакет fail2ban. После чего в логах стали регулярно появляться ошибки следующего содержания:

2016-08-13 05:43:23,463 fail2ban.actions        [1011]: NOTICE  [sshd] Ban 91.224.160.106
2016-08-13 05:43:23,565 fail2ban.action         [1011]: ERROR   iptables -w -n -L INPUT | grep -q 'f2b-sshd[ \t]' -- stdout: ''
2016-08-13 05:43:23,565 fail2ban.action         [1011]: ERROR   iptables -w -n -L INPUT | grep -q 'f2b-sshd[ \t]' -- stderr: ''
2016-08-13 05:43:23,565 fail2ban.action         [1011]: ERROR   iptables -w -n -L INPUT | grep -q 'f2b-sshd[ \t]' -- returned 1
2016-08-13 05:43:23,565 fail2ban.CommandAction  [1011]: ERROR   Invariant check failed. Trying to restore a sane environment
2016-08-13 05:43:23,667 fail2ban.action         [1011]: ERROR   iptables -w -D INPUT -p tcp -m multiport --dports ssh -j f2b-sshd
iptables -w -F f2b-sshd
iptables -w -X f2b-sshd -- stdout: ''
2016-08-13 05:43:23,667 fail2ban.action         [1011]: ERROR   iptables -w -D INPUT -p tcp -m multiport --dports ssh -j f2b-sshd
iptables -w -F f2b-sshd
iptables -w -X f2b-sshd -- stderr: "iptables v1.4.21: Couldn't load target `f2b-sshd':No such file or directory\n\nTry `iptables -h' or 'iptables --help' for more information.\niptables: No chain/target/match by that name.\niptables: No chain/target/match by that name.\n"
2016-08-13 05:43:23,667 fail2ban.action         [1011]: ERROR   iptables -w -D INPUT -p tcp -m multiport --dports ssh -j f2b-sshd
iptables -w -F f2b-sshd
iptables -w -X f2b-sshd -- returned 1
2016-08-13 05:43:23,667 fail2ban.actions        [1011]: ERROR   Failed to execute ban jail 'sshd' action 'iptables-multiport' info 'CallingMap({'ipjailmatches':  at 0x182b050>, 'matches': u'2016-08-13T05:43:07.237432 skvm1.powervps.ru sshd[850]: Invalid user admin from 91.224.160.106\n2016-08-13T05:43:09.504130 skvm1.powervps.ru sshd[852]: Invalid user admin from 91.224.160.106\n2016-08-13T05:43:11.811482 skvm1.powervps.ru sshd[856]: Invalid user admin from 91.224.160.106\n2016-08-13T05:43:14.043115 skvm1.powervps.ru sshd[858]: Invalid user admin from 91.224.160.106\n2016-08-13T05:43:22.962543 skvm1.powervps.ru sshd[878]: Invalid user support from 91.224.160.106', 'ip': '91.224.160.106', 'ipmatches':  at 0x181ded8>, 'ipfailures':  at 0x182b0c8>, 'time': 1471056203.463139, 'failures': 5, 'ipjailfailures':  at 0x182b140>})': Error stopping action

Сначала я грешил на использования ключа iptables -w в добавляемых правилах.

nano /etc/fail2ban/action.d/iptables-common.conf

В конце файла вы увидите параметр lockingopt и комментарий к нему:

# Option:  lockingopt
# Notes.:  Option was introduced to iptables to prevent multiple instances from
#          running concurrently and causing irratic behavior.  -w was introduced
#          in iptables 1.4.20, so might be absent on older systems
#          See https://github.com/fail2ban/fail2ban/issues/1122
# Values:  STRING
lockingopt = -w

Тогда я решил проверить версию установленного пакета:

# iptables --version
iptables v1.4.21

Но причина была не в этом. После продолжительного гугления, проблема оказалась связана с конфигом jail.local, в который вносит изменения VMmanager в процессе установки. Чтобы починить fail2ban, откройте файл:

nano /etc/fail2ban/jail.local

Закомментируйте содержимое файла, и добавьте строки как в примере ниже:

# ISPsystem start
#[sshd]
#maxretry = 5
#enabled = true
# ISPsystem end

[DEFAULT]
bantime = 3600
banaction = iptables-multiport

[sshd]
maxretry = 5
enabled = true

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

2016-08-14 10:36:01,828 fail2ban.jail           [23203]: INFO    Jail 'sshd' started
2016-08-14 10:36:01,947 fail2ban.actions        [23203]: NOTICE  [sshd] Ban 78.47.79.193

Failed to get D-Bus connection: Connection refused

Дата: 02.08.2016Метки:

С данной проблемой столкнулся в Debian 8, когда мне понадобилось создать новый сервис для запуска rtorrent в режиме демона. При попытке запуска нового сервиса я получил ошибку:

$ systemctl --user enable rtorrent
Failed to get D-Bus connection: Connection refused

Как оказалась проблема кроется зависимостях для systemd:

$ apt-cache depends systemd
systemd
  Depends: libacl1
  Depends: libaudit1
  Depends: libblkid1
  Depends: libcap2
  Depends: libcryptsetup4
  Depends: libkmod2
  Depends: libpam0g
  Depends: libselinux1
  Depends: libsystemd0
  Depends: util-linux
  Depends: mount
  Depends: initscripts
  Depends: sysv-rc
    openrc
  Depends: udev
  Depends: acl
  Depends: adduser
  Depends: libcap2-bin
  PreDepends: libc6
  PreDepends: libgcrypt20
  PreDepends: liblzma5
  PreDepends: libselinux1
  Suggests: systemd-ui
  Recommends: libpam-systemd
  Recommends: dbus
  Conflicts: 
  Breaks: lsb-base
  Breaks: lvm2
  Breaks: systemd-shim

Из рекомендованных зависимостей для systemd в Debian 8 был установлен только пакет dbus. Выполните установку пакета libpam-systemd, после чего необходимо перезагрузить систему. После чего проблема с запуском systemd должна быть решена.

Создаем ECDSA сертификаты Let’s Encrypt

Дата: 21.07.2016

Как показывает практика, использование ECDSA сертификатов позволяет добиться примерно в два раз большего количества соединений на одной аппаратной платформе. К недостаткам использования ECDSA сертификатов следует отнести проблему с поддержкой браузерами. Но данная проблема легко решается если мы будем использовать ECDSA и RSA сертификаты одновременно.

Перед тем как начать проверьте, что в системе установлен git, в противном случае необходимо запустить установку командой:

apt-get install git

Выберите каталог, в который будут загружены файлы клиента Let’s Encrypt. В этой статье я буду использовать каталог /usr/local. Переходим в указанный каталог, а затем загружаем и запускаем клиент Let’s Encrypt:

cd /usr/local
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
./letsencrypt-auto --help

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

mkdir -p /usr/local/letsencrypt/live-ecdsa/codebeer.ru/letmp

Перед тем как создать файл ключа, важно правильно выбрать тип кривой. Большинство современных браузеров поддерживает кривые secp256r1, secp384r1, secp521r1. Я буду использовать 256-битная кривую prime256v1, которая по современным меркам обеспечивает достаточной секретности. Список кривых OpenSSL можно вывести командой:

openssl ecparam -list_curves

Создаем приватный ключ:

cd /usr/local/letsencrypt/live-ecdsa/codebeer.ru
openssl ecparam -genkey -name secp256r1 > key-256r1.pem

Теперь создаем свой CSR:

openssl req -new -sha256 -key key-256r1.pem -subj "/CN=codebeer.ru" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:codebeer.ru,DNS:www.codebeer.ru")) -outform der -out csr-256r1.der

Переходим в каталог letmp и создаем ECDSA Let’s Encrypt сертификат:

cd letmp
/usr/local/letsencrypt/letsencrypt-auto certonly -a webroot --email webmaster@codebeer.ru --webroot-path /www/codebeer.ru/ --csr /usr/local/letsencrypt/live-ecdsa/codebeer.ru/csr-256r1.der --renew-by-default --agree-tos

Если вы используете веб-сервер Nginx, то во время создания сертификата клиент Let’s Encrypt вы можете получить такую ошибку:

 Failed authorization procedure. www.codebeer.ru (http-01): urn:acme:error:unauth orized :: The client lacks sufficient authorization :: Invalid response from htt p://www.codebeer.ru/.well-known/acme-challenge/oVRUfF1DISR8zRpq1Vju4C7XrYm2YULSe 5TVRfmGy64: "<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>", codebeer.ru (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://codebeer.ru/.well -known/acme-challenge/yKovcd-Eemc6ezWUWNKiL3MKgs6htk06lfuQmYeBwdA: "<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>"

IMPORTANT NOTES:
 - The following errors were reported by the server:

 Domain: www.codebeer.ru
 Type: unauthorized
 Detail: Invalid response from
 http://www.codebeer.ru/.well-known/acme-challenge/oVRUfF1DISR8zRpq1Vju4C7XrYm 2YULSe5TVRfmGy64:
 "<html>
 <head><title>403 Forbidden</title></head>
 <body bgcolor="white">
 <center><h1>403 Forbidden</h1></center>
 <hr><center>"

 Domain: codebeer.ru
 Type: unauthorized
 Detail: Invalid response from
 http://codebeer.ru/.well-known/acme-challenge/yKovcd-Eemc6ezWUWNKiL3MKgs6htk0 6lfuQmYeBwdA:
 "<html>
 <head><title>403 Forbidden</title></head>
 <body bgcolor="white">
 <center><h1>403 Forbidden</h1></center>
 <hr><center>"

 To fix these errors, please make sure that your domain name was
 entered correctly and the DNS A record(s) for that domain
 contain(s) the right IP address.

В этом случае вам нужно добавить в конфиг виртуального следующие строки:

location ~ /.well-known {
    allow all;
}

Если все прошло успешно, в каталоге letmp появятся следующие файлы:

0000_cert.pem  0000_chain.pem  0001_chain.pem

Копируем их содержимое в один файл:

cat 0001* > /usr/local/letsencrypt/live-ecdsa/codebeer.ru/chain.pem

Теперь необходимо указать путь к сертификату и ключу в конфиге nginx:

ssl_certificate /usr/local/letsencrypt/live-ecdsa/codebeer.ru/chain.pem;
ssl_certificate_key /usr/local/letsencrypt/live-ecdsa/codebeer.ru/key-256r1.pem;