Настройка ssl сертификата Lets Encrypt в apache
Теперь настроим работу web сервера apache с ssl сертификатом. Хотя если быть точным, то tls сертификатом. Устанавливаем пакет certbot для получения бесплатного ssl сертификата от let’s encrypt. Для этого нам сначала надо подключить репозиторий epel.
# dnf install epel-release # dnf install certbot
После установки пакетов certbot, если его запустить, напишет ошибку, что не может сам настроить apache.
Настроим все сами. Для начала создадим самоподписанный дефолтный сертификат, чтобы apache не ругался на отсутствие файла и смог запуститься.
# openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/pki/tls/private/localhost.key -out /etc/ssl/certs/localhost.crt
Все параметры оставляйте дефолтные, не принципиально. Мы этот сертификат использовать не будет. Перезапустите apache.
# apachectl restart
Теперь выпустим сертификат для нашего домена. Имейте ввиду, чтобы получить сертификат у вас должно быть действующее доменное имя, ссылающееся на web сервер, который настраиваете. Let’s Encrypt будет по доменному имени обращаться к серверу, на котором настраиваете сертификат, чтобы проверить домен. В тестовой лаборатории с вымышленным доменным именем получить настоящий ssl сертификат не получится.
# certbot certonly
В качестве способа аутентификации выбирайте
1: Apache Web Server plugin (apache)
Дальше заполняйте в соответствии с вашими названиями. После получения сертификата, укажем его в конфигурации виртуального хоста. В моем случае в файле z.serveradmin.ru.conf. Добавляем туда параметры ssl.
<VirtualHost *:80 *:443>
ServerName z.serveradmin.ru
ServerAlias www.z.serveradmin.ru
DocumentRoot /web/sites/z.serveradmin.ru/www
ErrorLog /web/sites/z.serveradmin.ru/log/error.log
CustomLog /web/sites/z.serveradmin.ru/log/access.log common
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/z.serveradmin.ru/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/z.serveradmin.ru/privkey.pem
<Directory /web/sites/z.serveradmin.ru/www>
Options FollowSymLinks
AllowOverride All
Require all granted
</Directory>
php_admin_value date.timezone 'Europe/Moscow'
php_admin_value max_execution_time 60
php_admin_value upload_max_filesize 30M
</VirtualHost>
Перезапускайте apache и проверяйте работу сайта по https, зайдя по соответствующему протоколу.
По аналогии делаете с остальными виртуальными хостами, для которых используете бесплатные сертификаты let’s encrypt. Осталось дело за малым — настроить автоматический выпуск новых ssl сертификатов, взамен просроченным. Для этого добавляем в /etc/crontab следующую строку:
# Cert Renewal 30 4 * * * root /usr/bin/certbot renew --post-hook "/usr/sbin/apachectl restart" >> /var/log/le-renew.log
Переадресация с http на https в apache
В настроенном ранее примере https отлично работает, но неудобно, что нет автоматической переадресации с http на https. Чтобы использовать безопасную версию сайта, необходимо вручную в браузере набирать https. Хотя все современные браузеры уже сами умеют проверять версии сайта и если есть защищенная, то они автоматически сами ее выбирают.
Тем не менее, лучше все же добавить редирект с http на https. Его можно сделать двумя различными способами:
- Через файл .htaccess
- С помощью настройки виртуального хоста.
Мне нравится больше второй вариант, поэтому приводим конфиг виртуального хоста к следующему виду.
<VirtualHost *:80>
ServerName z.serveradmin.ru
ServerAlias www.z.serveradmin.ru
Redirect permanent / https://z.serveradmin.ru
</VirtualHost>
<VirtualHost *:443>
ServerName z.serveradmin.ru
ServerAlias www.z.serveradmin.ru
DocumentRoot /web/sites/z.serveradmin.ru/www
ErrorLog /web/sites/z.serveradmin.ru/log/error.log
CustomLog /web/sites/z.serveradmin.ru/log/access.log common
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/z.serveradmin.ru/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/z.serveradmin.ru/privkey.pem
<Directory /web/sites/z.serveradmin.ru/www>
Options FollowSymLinks
AllowOverride All
Require all granted
</Directory>
php_admin_value date.timezone 'Europe/Moscow'
php_admin_value max_execution_time 60
php_admin_value upload_max_filesize 30M
</VirtualHost>
Перечитывайте конфиг httpd и проверяйте. Должно работать автоматическое перенаправление на https версию.
Проверяем запустился ли веб сервер
Для этого открываем любой броузер и указываем адрес страницы http://localhost
Мы должны увидеть страничку с надписью It Works !
Выясним IP адрес нашего компьютера в локальной сети. Для этого в нижнем правом углу (рядом с часами) находим иконку локальной сети, кликаем на ней правой кнопкой и открываем «Центр управления сетями и общим доступом»
Выбираем нашу сеть
И нажимаем кнопку «Сведения»
В моем случае адрес компьютера в локальной сети 192.168.0.189
Теперь возвращаемся в броузер и проверяем доступность страницы It Works по IP адресу http://192.168.0.189 (в вашем случае цифры будут отличаться)
Если снова увидели знакомую страницу It Works — все хорошо,
Handling Signals
While the operating system defines a set list of signals, the way in which a process responds to a particular signal is application-specific.
For example, if you want to initiate a graceful shutdown of an nginx server, you should send a SIGQUIT. None of the Docker commands issue a SIGQUIT by default so you’d need use the command as follows:
The nginx log output upon receiving the SIGQUIT would look something like this:
In contrast, Apache uses SIGWINCH to trigger a :
According to the Apache documentation a SIGTERM will cause the server to immediately exit and terminate any in-progress requests, so you may not want to use on an Apache container.
If you’re running a third-party application in a container you may want to review the app’s documentation to understand how it responds to different signals. Simply running a may not give you the result you want.
When running your own application in a container, you must decide how the different signals will be interpreted by your app. You will need to make sure you are trapping the relevant signals in your application code and taking the necessary actions to cleanly shutdown the process.
If you know that you’re going to package your application in a Docker image you might consider using SIGTERM as your graceful shutdown signal since this is what the command sends.
No matter which language you’re using, there is a good chance that it supports some form of signal handling. I’ve collected links to the relevant package/module/library for a handful of languages in the list below:
- Bash
- Ruby
- Python
- Go
If you’re using Go for your application, take a look at the tylerb/graceful package which automatically enables the graceful shutdown of http.Handler servers in response to SIGINT or SIGTERM signals.
Introduction
In order to stop or restart the Apache HTTP Server, you must send a signal to
the running processes. There are two ways to
send the signals. First, you can use the unix
command to directly send signals to the processes. You will
notice many executables running on your system,
but you should not send signals to any of them except the parent,
whose pid is in the . That is to say you
shouldn’t ever need to send signals to any process except the
parent. There are four signals that you can send the parent:
,
,
, and
, which
will be described in a moment.
To send a signal to the parent you should issue a command
such as:
The second method of signaling the processes
is to use the command line options: ,
, and ,
as described below. These are arguments to the binary, but we recommend that
you send them using the control script, which
will pass them through to .
After you have signaled , you can read about
its progress by issuing:
Контрольная точка
При выполнении контрольной точки (CHECKPOINT) – принудительно сбрасываются на диск все грязные страницы, которые есть в буферном кэше. Это гарантирует что на момент контрольной точки все данные сбросились на диск и при восстановлении данных нужно читать не весь журнал WAL, а только ту часть которая была сделана после последней контрольной точки.
Сброс данных при контрольной точке не проходит моментально, это бы сильно нагрузило наш сервер. Чтобы не было пиковых нагрузок сброс идет примерно 50% времени от времени между контрольными точками. Например, контрольные точки делаются каждую минуту, тогда сброс осуществляют плавно в течении 30 секунд. Это регулируется и вы можете установить например 90% времени.
Контрольная точка также уменьшает размер необходимого дискового пространства. Так как весь журнал WAL не нужен, его можно периодически подрезать.
Отдельный серверный процесс контрольных точек автоматически выполняет контрольные точки с заданной частотой. Эту частоту можно настроить следующими параметрами:
- checkpoint_timeout – период выполнения контрольных точек в секундах;
- max_wal_size – максимальный размер, до которого может вырастать WAL во время автоматических контрольных точек;
- checkpoint_completion_target – время для завершения процедуры контрольной точки, как коэффициент для общего времени между контрольными точками. По умолчанию это значение равно 0.5.
Значения по умолчанию: 5 минут и 1 Гбайт, соответственно. Если после предыдущей контрольной точки новые записи WAL не добавились, следующие контрольные точки будут пропущены, даже если проходит время checkpoint_timeout. Также можно выполнить контрольную точку принудительно, воспользовавшись SQL-командой CHECKPOINT.
Уменьшение значений checkpoint_timeout и max_wal_size приводит к учащению контрольных точек. Но появляется дополнительная нагрузка на сервер.
Настройка SELinux для web сервера apache
Раздел для тех, кто хочет настроить SELinux на своем web сервере. Сначала ставим пакет policycoreutils-python-utils если он еще не установлен. Он нам нужен для утилиты semanage.
# dnf install policycoreutils-python-utils
Теперь автоматически сформируем модуль для selinux на основе событий аудита, которые накопились, пока мы настраивали сайт. Посмотреть их можно командой.
# grep httpd /var/log/audit/audit.log | audit2why
Создаем модуль selinux.
# grep httpd /var/log/audit/audit.log | audit2allow -M my-httpd
Загружаем его.
# semodule -i my-httpd.pp
То же самое делаем для php.
# grep php /var/log/audit/audit.log | audit2allow -M my-php # semodule -i my-php.pp
Добавим нашу директорию /web/sites в соответствующие таблицы selinux для контента и логов.
# semanage fcontext -a -t httpd_sys_content_t "/web/sites(/.*)?" # semanage fcontext -a -t httpd_log_t "/web/sites(/.*)?/log(/.*)?"
И отдельно добавим каталог, куда web сервер сможет писать данные. Я покажу на примере правила для сайтов wordpress, где web сервер должен уметь писать в директорию wp-content для загрузки медиафайлов, установки тем и плагинов, а так же изменять файл wp-config.php.
# semanage fcontext -a -t httpd_sys_rw_content_t "/web/sites/\*/www/wp-content(/.\*)?" # semanage fcontext -a -t httpd_sys_rw_content_t "/web/sites/\*/www/wp-config.php"
Обновляем атрибуты файлов новым контекстом SELinux.
# restorecon -Rv /web/sites
В завершении настройки selinux для apache, добавим еще один параметр, без которого httpd не сможет писать файлы в указанные каталоги.
# setsebool -P httpd_unified 1
Теперь активируем защиту selinux и проверяем, что она работает.
# setenforce 1 # getenforce Enforcing
Режим работы Enforcing означает, что selinux работает. Убедиться, что модули загружены, можно командой.
# semodule -l | grep my-
В целом, по selinux все. Мы просто разрешили все, что веб сервер просил. По идее, надо вдумчиво во всех правилах разбираться и разрешать только то, что считаешь нужным. Я честно скажу, что selinux знаю не очень хорошо. Дальше загрузки готовых модулей и автоматического создания модулей с помощью audit2allow я не двигался. Руками модули никогда не писал. Если есть какой-то более осмысленный и правильный способ настройки selinux на кастомной конфигурации веб сервера, буду рад полезной информации.
Хорошая практическая статья по ручной настройке selinux для web сервера — https://habr.com/ru/post/322904/. Там же есть ссылки на другие статьи автора на тему selinux. Написано содержательно и наглядно, рекомендую для тех, кто будет знакомиться с технологией.
Копирование числовых ячеек из 1С в Excel Промо
Решение проблемы, когда значения скопированных ячеек из табличных документов 1С в Excel воспринимаются последним как текст, т.е. без дополнительного форматирования значений невозможно применить арифметические операции. Поводом для публикации послужило понимание того, что целое предприятие с более сотней активных пользователей уже на протяжении года мучилось с такой, казалось бы на первый взгляд, тривиальной проблемой. Варианты решения, предложенные специалистами helpdesk, обслуживающими данное предприятие, а так же многочисленные обсуждения на форумах, только подтвердили убеждение в необходимости описания способа, который позволил мне качественно и быстро справиться с ситуацией.
Сервер 1С:Предприятие на Ubuntu 16.04 и PostgreSQL 9.6, для тех, кто хочет узнать его вкус. Рецепт от Капитана
Если кратко описать мое отношение к Postgres: Использовал до того, как это стало мейнстримом.
Конкретнее: Собирал на нем сервера для компаний среднего размера (до 50 активных пользователей 1С).
На настоящий момент их набирается уже больше, чем пальцев рук пары человек (нормальных, а не фрезеровщиков).
Следуя этой статье вы сможете себе собрать такой же и начать спокойную легальную жизнь, максимально легко сделать первый шаг в мир Linux и Postgres.
А я побороться за 1. Лучший бизнес-кейс (лучший опыт автоматизации предприятия на базе PostgreSQL).
Если, конечно, статья придется вам по вкусу.
А если несколько информационных баз?
Вариант А.
Значит нам понадобится подготовить несколько .vrd файлов, добавить инструкции по их копированию в Dockerfile и описать пути для веб-сервера в httpd.conf: на каждую базу свой путь, своя директория, свой .vrd файл.
Закидываем изменённый Dockerfile, httpd.conf и новые vrd файлы на сервер, останавливаем контейнер и запускаем заново с флагом —build:
Вариант Б.
На каждую информационную базу можно поднять свой отдельный контейнер. Это значит что директорию проекта нужно будет размножить по числу баз, внутри каждой сделать свои настройки в .vrd файле. Но при таком подходе не получится все контейнеры запустить одновременно на одному порту, придётся в каждом docker-compose.yml прописать свои порты, например, 8001:80 для первой базы, 8002:80 для второй базы и т.д.
У этого подхода, кстати, есть другое полезное свойство — внутри этих контейнеров могут быть различные версии модуля 1С (это нужно если у вас и серверов 1С несколько с разными версиями платформы).
Конфигурации виртуальных хостов
Стандартный виртуальный хост находится в файле default в каталоге sites-available.
Чтобы ознакомиться с общим форматом виртуального хоста, откройте этот файл:
По умолчанию виртуальный хост обрабатывает запросы на порте 80.
Это не означает, что веб-сервер обязательно будет обрабатывать каждый запрос через этот порт. Apache может переопределять конфигурации.
Настройки виртуального хоста высшего уровня
Эти параметры устанавливаются в разделе Virtual Host и применяются ко всему виртуальному хосту.
Директива ServerName задаёт доменное имя или IP-адрес сервера. Это индивидуальный параметр каждого виртуального хоста, который может переопределить настройки по умолчанию, если он совпадает со значением ServerName.
Параметр ServerAlias позволяет добавить алиасы сайта – альтернативные имена и пути, ведущие к одному контенту. Так, например, часто устанавливается алиас домена с www.
DocumentRoot задаёт каталог, в котором веб-сервер хранит контент данного виртуального хоста. В Ubuntu для этого по умолчанию используется /var/www.
В конфигурации виртуального хоста есть специальный раздел для настройки обработки отдельных каталогов файловой системы. Эти настройки также можно переопределять.
Сначала виртуальный хост предлагает набор правил для каталога / (root-каталог). Этот раздел обеспечит базовую конфигурацию виртуального хоста, поскольку он относится ко всем файлам, которые обслуживаются в файловой системе.
По умолчанию Ubuntu не накладывает никаких ограничений на файловую систему. Apache рекомендует добавить несколько стандартных ограничений доступа, например:
Это заблокирует доступ ко всему контенту, если в последующих определениях каталогов не указано иное.
Далее идут настройки каталога document root, в которых параметр allow from all переопределяет параметры каталога /.
Параметр AllowOverride позволяет настроить переопределение конфигураций с помощью файлов .htaccess. Чтобы переопределить настройки, файл .htaccess должен находиться в каталоге с контентом. По умолчанию эта функция отключена.
Настройки Alias и ScriptAlias
Иногда перед разделом Directory идут параметры Alias и ScriptAlias.
Директива Alias позволяет добавлять к обслуживаемому контенту каталоги вне DocumentRoot.
ScriptAlias работает аналогичным образом, но содержит путь к каталогам с исполняемыми файлами.
К примеру, такая строка в виртуальном хосте для сайта example.com откроет доступ к контенту в каталоге /path/to/content/ при запросе example.com/content/.
Помните, что открывая доступ к дополнительным каталогам, нужно устанавливать ограниченные привилегии на них.
Включение сайтов и модулей в Apache
Создав файл виртуального хоста, вы можете включить его. Для этого нужно создать символическую ссылку на файл в каталоге sites-enabled:
Включив сайт, перезапустите Apache, чтобы веб-сервер перечитал конфигурации:
Чтобы отключить виртуальный хост, нужно удалить символьную ссылку из sites-enabled:
После этого нужно снова перезапустить веб-сервер:
Включить и отключить модуль Apache можно с помощью следующих команд (соответственно):
Они работают так же, как и ранее упомянутые команды a2ensite иa2dissite. После включения или отключения модуля нужно перезапускать веб-сервер.
Сетевые службы в Kali Linux
Особенностью Kali Linux является то, что многие популярные пакеты сетевых служб установлены в систему, но не запускаются автоматически. Для их использования нужно самостоятельно сделать запуск или добавить их в автозапуск вместе с включением компьютера.
Это сделано в целях безопасности – к службам вашей системы невозможно подключиться, если вы не предприняли явных действий для их включения. В целом это позволяет минимизировать воздействие во время теста на проникновение, когда вредно объявлять о вашем присутствии и имеется риск обнаружения из-за неожиданных сетевых взаимодействий.
Очевидно, что по умолчанию отключены SSH и Apache, которые в основе своей деятельности подразумевают сетевую активность. Может показаться неочевидным, почему по умолчанию отключена служба MySQL, которая является системой управления базами данных? MySQL также позволяет удалённое подключение, по этой причине MySQL и некоторые другие службы, которые не являются сетевыми по своему основному назначению, отключены.
Но на самом деле, сделано одно исключение, а именно NetworkManager запускается при включении компьютера. Если вы действительно хотите оставаться незаметным даже если вы подключены к компьютерным сетям, вам нужно выключить автоматический запуск NetworkManager.
Управление службой Apache
Для управления запуском и остановкой сервиса Apache можно использовать «ApacheMonitor». Откройте директорию веб-сервера bin («C:\Apache24\bin») и запустите файл: ApacheMonitor.exe. В системном трее появится значок Apache, с помощью которого можно быстро запускать/останавливать службу Apache.
А также, так как сервис Apache устанавливается как служба, после его установки, управлять его запуском/остановкой можно в окне списка служб («Пуск» → пункт «Панель управления» → «Администрирование» → «Службы»)
При установки Apache, служба, по умолчанию получает имя «Apache» или «Apache24». Если, в силу каких либо причин, имя службы нас не устраивает, есть возможность задать собственное имя, используя в командной строке параметр «-n» c указанием имени службы через пробел. (Если в имени службы содержится пробел необходимо обернуть его в кавычки, т. е. «name service»). Рассмотрим дополнительно команды для управления сервисом Apache:
устанавливаем службу
C:\Apache24\bin\httpd.exe -k install или C:\Apache24\bin\httpd.exe -k install -n name_service C:\Apache24\bin\httpd.exe -k install -n "name service"
запускаем службу
C:\Apache24\bin\httpd.exe -k start или C:\Apache24\bin\httpd.exe -k start -n name_service C:\Apache24\bin\httpd.exe -k start -n "name service"
останавливаем службу
C:\Apache24\bin\httpd.exe -k stop или C:\Apache24\bin\httpd.exe -k stop -n name_service C:\Apache24\bin\httpd.exe -k stop -n "name service"
удаляем службу
C:\Apache24\bin\httpd.exe -k uninstall или C:\Apache24\bin\httpd.exe -k uninstall -n name_service C:\Apache24\bin\httpd.exe -k uninstall -n "name service"
получаем информации о версии службы
C:\Apache24\bin\httpd.exe -V
получаем конфигурацию службы
C:\Apache24\bin\httpd.exe -k config или C:\Apache24\bin\httpd.exe -k config -n name_service C:\Apache24\bin\httpd.exe -k config -n "name service"
Данная команда тестирует конфигурационный файл httpd.conf и отображает ошибки
Управлять службами также можно, используя в командной строке команду «net». Рассмотрим несколько примеров.
получаем список служб
C:\Windows\system32>net start
запускаем службу
C:\Windows\system32>net start Apache2.4 или C:\Windows\system32>net start "name service"
останавливаем службу
C:\Windows\system32>net stop Apache2.4 или C:\Windows\system32>net stop "name service"
Проблема установки Apache под Windows
Основная проблема установки Web-сервера Apache под Windows заключается в том, что после первичной установки дистрибутива весь пакет (исполняемые программы, конфигурационные файлы, файлы журналов работы сервера и файловая область для размещения Web-страниц) размещается в одном месте. Это мешает нормальной эксплуатации продукта по следующим причинам:
- Разграничение прав доступа. Исполняемые файлы должны оставаться неизменными, конфигурационными файлами управляет администратор Web-сервера, а доступ к файловой области Web-страниц должны иметь разработчики и администраторы сайта. Права доступа к папке «Program Files» настроены в предположении, что в ней хранятся исполняемые модули программных пакетов, модификация которых не требуется.
- Захламление системных папок. Папка «Program Files» операционной системы Windows изначально предназначена для размещения только исполняемых файлов. Она может находиться на отдельном томе, размер которого выбирается системным администратором в предположении о его относительном постоянстве. Уж точно никто не ожидает, что в этой папке будут храниться пользовательские данные, галереи рисунков и файловый архив сайта.
Поэтому установка Apache под Windows должна проводиться в два этапа:
- Первичная установка программного пакета в выбранную папку.
- Оптимизация размещения файловых областей web-сервера и соответствующее изменение его конфигурации.
При модификации конфигурационных файлов Apache нужно постоянно помнить, что в качестве разделителя путей к файлам и папкам должен использоваться символ «прямой слеш», как в операционных системах Unix и Linux, а не «обратный слеш», как в Windows.
Graceful Restart
- Signal: USR1
The or signal causes
the parent process to advise the children to exit after
their current request (or to exit immediately if they’re not
serving anything). The parent re-reads its configuration files and
re-opens its log files. As each child dies off the parent replaces
it with a child from the new generation of the
configuration, which begins serving new requests immediately.
This code is designed to always respect the process control
directive of the MPMs, so the number of processes and threads
available to serve clients will be maintained at the appropriate
values throughout the restart process. Furthermore, it respects
in the
following manner: if after one second at least new children have not
been created, then create enough to pick up the slack. Hence the
code tries to maintain both the number of children appropriate for
the current load on the server, and respect your wishes with the
parameter.
Users of
will notice that the server statistics are not
set to zero when a is sent. The code was
written to both minimize the time in which the server is unable
to serve new requests (they will be queued up by the operating
system, so they’re not lost in any event) and to respect your
tuning parameters. In order to do this it has to keep the
scoreboard used to keep track of all children across
generations.
The status module will also use a to indicate
those children which are still serving requests started before
the graceful restart was given.
At present there is no way for a log rotation script using
to know for certain that all children writing
the pre-restart log have finished. We suggest that you use a
suitable delay after sending the signal
before you do anything with the old log. For example if most of
your hits take less than 10 minutes to complete for users on
low bandwidth links then you could wait 15 minutes before doing
anything with the old log.
