Внезапно выяснилось, что самый хороший CentOS это 5ый. И клиенту нужен был именно он. Появилась дилемма — как его поставить из Linux Rescue mode, чтобы не тратить на это много времени? Конечно же существовала возможность сделать это через виртуальный KVM, чем мы мгновенно воспользовались, попутно размышляя о том, как упростить решение задачи..

Конечно же, решение нашлось не сразу. Следовало хорошенько все обмозговать. Как всегда, все решается с помощью пары команд.. Итак, находясь в режиме Rescue mode (Ubuntu 20.04 LiveCD) следует вначале установить пакет старого GRUB

# apt install grub-legacy-ec2

Далее — ставим все как обычно через скрипт hetz.sh , выбирая дистрибутив CentOS 5.8 minimal

После установки, загрузившись в рабочий режим свежеустановленной ОСи прописать работающие до сих пор репозитории CentOS 5.11 и обновить OS

rm -fr /etc/yum.repos.d/*
nano /etc/yum.repos.d/CentOS-Base.repo 

Вставляем код ниже, обновляемся и выдаем сервер клиенту

[base]
name=CentOS-$releasever - Base
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
baseurl=http://vault.centos.org/5.11/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

#released updates 
[updates]
name=CentOS-$releasever - Updates
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
baseurl=http://vault.centos.org/5.11/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

#additional packages that may be useful
[extras]
name=CentOS-$releasever - Extras
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras
#baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/
baseurl=http://vault.centos.org/5.11/extras/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

#additional packages that extend functionality of existing packages
[centosplus]
name=CentOS-$releasever - Plus
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus
#baseurl=http://mirror.centos.org/centos/$releasever/centosplus/$basearch/
baseurl=http://vault.centos.org/5.11/centosplus/$basearch/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

#contrib - packages by Centos Users
[contrib]
name=CentOS-$releasever - Contrib
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=contrib
#baseurl=http://mirror.centos.org/centos/$releasever/contrib/$basearch/
baseurl=http://vault.centos.org/5.11/contrib/$basearch/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

Важное замечание. В некоторых случаях возникает ошибка при подключении к установленной ОСи CentOS 5:

Unable to negotiate with 217.172.XXX.XX port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

В этом случае подключаемся к серверу по ssh с ключом

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 root@217.172.XXX.XX

Если таких серверов много, то следует добавить в конфиг локального клиента следующие команды:

#Legacy
KexAlgorithms +diffie-hellman-group1-sha1
Ciphers +aes128-cbc

При небольших атаках зачастую достаточно добавить ограничение по количеству подключений с одного ip адреса. Школьники попыхтят еще пару часов и их интерес к ресурсу пропадает. Конечно, такое случается нечасто, но тем не менее. Решил записать способ ограничений, прекрасно описанный коллегами, ссылку на статью с картинками добавлю в конце заметки.

Итак, чтобы не разводить пустую болтовню — решение от коллег

# Добавляем следующие правила в iptables
iptables --flush
iptables --new-chain RATE-LIMIT
iptables --append RATE-LIMIT \
    --match hashlimit \
    --hashlimit-mode srcip \
    --hashlimit-upto 50/sec \
    --hashlimit-burst 20 \
    --hashlimit-name conn_rate_limit \
    --jump ACCEPT
iptables --append RATE-LIMIT --jump DROP

И теперь можно посмотреть результат:

netstat -plan | grep -oE ":443|:80" | wc -l                                     
24                                                                       

Количество запросов на web порты сервера упало с тысячи с небольшим до двухзначной величины. Похоже на правду. Всем огромных успехов и удачи в борьбе с ddos атаками.

На всякий случай напомню — выделенные серверы в России, ЕС и США по скромным ценам можно взять в аренду здесь

Если установить панель HesitaCP, то с настройками по-умолчанию отчего то не получалась почта, отправляемая с google (и не только оттуда). Почта возвращалась с ошибкой 454 TLS currently unavailable

Пришлось покурить логи Exim, которые находятся тут: /var/log/exim4/mainlog . Было обнаружено, что у exim нет прав на чтение файла сертификата TLS:

TLS error on connection from mail-pg1-f170.google.com [209.85.215.170] (cert/key setup: cert=/usr/local/hestia/ssl/certificate.crt key=/usr/local/hestia/ssl/certificate.key): Error while reading file.

Мгновенно даем права на чтение командами:

chmod 664 /etc/exim4/domains/*/aliases
chmod 664 /usr/local/hestia/ssl/certificate.crt
chmod 664 /usr/local/hestia/ssl/certificate.key

И для порядка можно перезагрузить exim4

Потребовалось сделать перенос виртуальной машины c OS CentOS 6 (OpenVZ CT) на ноду с KVM. Ранее переносили виртуалку с Ubuntu 16 — сложности возникли, но справились довольно быстро. А вот с CentOS 6 появились проблемы…

Все знают — хорошее быстро заканчивается. В том числе и поддержка ОС CentOS 6 истекла в ноябре 2020. Соответственно, репозитории mirror.centos.org переехали на vault.centos.org. Для нас эта информация очень важна, так как нам нужно будет установить ядро для виртуалки.

По сути переезд с одного типа виртуализации на KVM или выделенный сервер, по сути, сводится всего к нескольким пунктам:

• перенос файлов виртуальной машины
• установка ядра гостевой системы
• установка загрузчика
• исправление fstab
• изменение настроек сети

Первый пункт плана проблем не вызывает: создается новая машина на ноде с KVM, на ноде с OpenVZ выключаем виртуалку, затем монтируем ее и переносим файлы:

# На источнике - ноде с OpenVZ
prlctl stop CT1
prlctl mount CT1
# Смотрим, что получилось:
mount | grep vz
/dev/md2 on /vz type ext4 (rw,noatime,lazytime,data=ordered)
/dev/ploop13775p1 on /vz/root/89e81c92-2ca6-4321-9869-6aa1c2fc895d type ext4 (rw,relatime,data=ordered,balloon_ino=12)

Видим путь и ID исходной машины —

ID: 89e81c92-2ca6-4321-9869-6aa1c2fc895d
SOURCE PATH: /vz/root/89e81c92-2ca6-4321-9869-6aa1c2fc895d

Забегая вперед скажу: на созданной в KVM машине грузимся в LiveCD CentOS 6 или другой ОС со старым ядром. Иначе нельзя будет сделать chroot в перенесенную ОС CentOS 6. Будет появляться сообщение:

 segmentation fault  chroot /mnt /bin/bash

В LiveCD создаем раздел, форматируем и монтируем диск:

fdisk /dev/sda
mkfs.ext3 /dev/sda1
mount /dev/sda1 /mnt

Копируем файлы на новую машину одной командой:

rsync -aAXv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} IP_OpenVZ:/vz/root/89e81c92-2ca6-4321-9869-6aa1c2fc895d/ /mnt

Первый пункт завершен успешно. Но самое веселое еще впереди. Пункт 2: для установки ядра в гостевую ОС нам потребуется сделать chroot и накатить ядро. Но здесь нас ждет неудача — репозитории не хотят скачиваться — их не существует уже. И curl к тому же валится сс сообщением:

PYCURL ERROR 77 - "Problem with the SSL CA cert (path? access rights?)

Поэтому, если у вас, как и у меня LiveCD CentOS 6, можно накатить ядро так:

# Меняем репозитории base и epel на vault в LiveCD
curl https://www.getpagespeed.com/files/centos6-eol.repo --output /etc/yum.repos.d/CentOS-Base.repo
curl https://www.getpagespeed.com/files/centos6-epel-eol.repo --output /etc/yum.repos.d/epel.repo

# Устанавливаем ядро и заголовки
yum install kernel.x86_64  -c /etc/yum.repos.d/CentOS-Base.repo --installroot=/mnt
yum install kernel-headers.x86_64  -c /etc/yum.repos.d/CentOS-Base.repo --installroot=/mnt

Другой способ установки гостевого ядра, который тоже работает. Можно сделать chroot после монтирования /proc /sys и /dev:

mount /dev/sda1 /mnt
mount --bind /proc /mnt/proc
mount --bind /dev /mnt/dev
mount --bind /sys /mnt/sys
chroot /mnt 
# В таком случае все работает прямо на гостевой ОСи без проблем:
yum install kernel.x86_64
yum install kernel-headers.x86_64
yum install dracut

Не забываем про генерацию initramfs:

# У меня в  гостевой ОС установилось ядро 2.6.32-754.35.1
# Поэтому ставим именно его:
dracut -f /boot/initramfs-2.6.32-754.35.1.el6.x86_64.img 2.6.32-754.35.1.el6.x86_64

Переходим к пункту 3. Здесь было много всего сделано, в частности — безуспешные попытки завести grub 0.какой то версии. Поэтому было принято решение его удалить и собрать из сырцов grub 2. Для этого в гостевой ОСи устанавливаем компилятор, удаляем grub и злодействуем:

# Установка компилятора
yum -y install gcc bison flex make
# Качаем исходники отсюда:
# http://ftp.gnu.org/gnu/grub/
wget http://ftp.gnu.org/gnu/grub/grub-2.04.tar.gz
tar xf grub-2.04.tar.gz
cd grub-2.04
# Компилируем и ставим:
./configure
make
make install
# Создаем конфиг grub2 для CentOS
/usr/local/sbin/grub-mkconfig -o /boot/grub/grub.cfg
/usr/local/sbin/grub-install /dev/sda
# Жестоко удаляем  grub
yum -y remove grub

У нас еще пара пунктов:

# Исправляем fstab: vim /etc/fstab

/dev/sda1 /  ext3 errors=remount-ro 0       1

# Исправляем конфиг сети - у нас виртуалки получают IP по dhcp
# vim /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
TYPE=Ethernet
ONBOOT=yes
BOOTPROTO=dhcp
NAME="System eth0"

На этом, по сути — все. Можно все отмонтировать в новой виртуалке и попробовать загрузиться. По идее, если все сделано без ошибок, должно взлететь и работать.. Но это не точно..

И в заключении: действительно отличная новость! Беспрецедентный тариф на виртуалки — от 90 рублей предлагает компания vps-server.ru. При необходимости поможем с переездом на наши серверы от других провайдеров.

Давеча потребовалось мне раздавать IP адреса по dhcp в локальной сети ДЦ OVH. А адреса с маской 255.255.255.255. И, как водится, шлюз у них один на всех (чтобы масками не добавлять, перерасход же получается — из 8 адресов только 5 используется). Так еще из локалки выпускают только под определенным маком, иначе на шлюзе блочат так, что не видно интернета.

В дата центре OVH шлюз (GATEWAY_IP) у всех IP адресов выделенного сервера начинается так же, как основной IP сервера, а заканчивается на .254. Например для сервера с IP 198.27.92.15 у всех IP будет шлюзом 198.27.92.254 Это очень хороший ход, к слову. Удобно конфигурировать.

После того, как был установлен Proxmox 6 из коробки OVH, я накатил isc-dhcpd server:

apt install -y isc-dhcp-server
cp /etc/dhcp/dhcpd.conf{,.backup} 
echo '' > /etc/dhcp/dhcpd.conf
touch /var/lib/misc/dhcp.leases
nano /etc/dhcp/dhcpd.conf

Теперь нужно написать конфиг серверу, чтобы он раздавал IP адреса для виртуальных машин в сети. Пример я напишу ниже. Сразу оговорюсь — конфиг не идеален, так как работает не со всеми ОС. В частности, на FreeBSD сеть не взлетает, так как Фря не принимает маршрут на такой шлюз. Попытки подсунуть ей маршруты через dhcp не помогли. Адрес IP получает, а настройки сети нет. Если кто то знает, как пропихнуть все-таки маршрут — напишите, пожалуйста, в комментарии.

# мой конфиг isc-dhcpd
# Здесь 192.168.246.xxx - адреса для виртуалок (FAILOVER_IP в терминах OVH)
# 10.10.10.254 - шлюз основного IP сервера (GATEWAY_IP )
option classless-routes code 121 = array of unsigned integer 8;
option classless-routes 24, 192,168,246,	10,10,10,254,
                        0,                      10,10,10,254;
subnet 0.0.0.0 netmask 0.0.0.0 {
        range 192.168.246.170 192.168.246.175;
        option subnet-mask 255.255.255.255; 
        option broadcast-address 192.168.246.255;
        option domain-name-servers 8.8.8.8, 1.1.1.1, 208.67.222.222;
        option domain-name "srv22.vps-server.ru";
        option routers 10.10.10.254;
        default-lease-time 120;
        max-lease-time 600;
}
host VM0 {hardware ethernet 02:00:00:01:01:5b; fixed-address 192.168.246.170; }
host VM1 {hardware ethernet 02:00:00:01:01:ef; fixed-address 192.168.246.171; }
# 

Обращаю пристальное внимание, на то, что для каждого дополнительного IP address нужно указать MAC. Конечно же, именно этот MAC нужно присвоить виртуалке при её создании. Для примера в конце конфига добавлены две строки виртуальных машин VM0 и VM1.

Необходимо заметить, что ISC-dhcp-server довольно капризная в настройке вещь. И понять по выхлопу лога ненавистного systemd почему оно не взлетает не представляется возможным. Поэтому приходится прибегать при отладке к использованию костылей.

# Запуск isc-dhcpd для отладки конфига:
# Для отладки помогает отлично !
/usr/sbin/dhcpd -lf /var/lib/misc/dhcp.leases -cf /etc/dhcp/dhcpd.conf

После того, как конфиг отлажен и работает, можно убить процесс dhcpd и запустить его в режиме демона:

# Убиваем процессы dhcpd 
killall dhcpd -9
/etc/init.d/isc-dhcp-server restart
[ ok ] Restarting isc-dhcp-server (via systemctl): isc-dhcp-server.service.

Отмечу также, что MAC адреса необходимо получить в клиентской панели управления OVH.

Для работы сети с виртуалкой на FreeBSD следует в ней добавить два маршрута:

route add -host GATEWAY_IP/32 -interface em0
route add default GATEWAY_IP

Или добавить в /etc/rc.conf следующие строки:

ifconfig_em0="inet FAILOVER_IP netmask 255.255.255.255 broadcast FAILOVER_IP"
static_routes="net1 net2"
route_net1="-net GATEWAY_IP/32 -interface em0"
route_net2="default GATEWAY_IP"

На этом всё. Напоминаю, выделенные серверы в России с безлимитным трафиком и виртуальные серверы с честной виртуализацией KVM в различных локациях лучше всего приобретать в компании vps-server.ru. Эти ребята работают более 15 лет на рынке хостинга, имеют огромный опыт администрирования и эксплуатации серверов.

Внимательным читателям :o) сообщаю промокод со скидкой 30% на весь срок аренды некоторых выделенных серверов этой компании в России — diman-rulit2021

В настоящее время свирепствует дезинформация, связанная с так называемой пандемией — заражением вирусом covid-19. Я не являюсь специалистом по распространению вирусов, не эпидемиолог и не врач. Я обычный человек, который закончил школу в СССР и имел твердую четверку по математике. Для того, чтобы понять, что пандемия это фейк, нужно обратиться к цифрам.

А цифры на сайте ВОЗ нам сообщают следующее: «каждый год от респираторных заболеваний, вызванных сезонным гриппом, умирает до 650 000 человек.» При этом смертность от обычного гриппа составляет 4%. Несложно подсчитать, что количество заболевших гриппом в допандемийном мире в год было 16 миллионов с четвертью. Эти люди спокойно болели дома, чихали, кашляли(иногда в маски и платки), наматывали сопли на рукав, но оставались в социуме.

Никто никаких эпидемий, пандемий не объявлял! В числе прочего, сообщалось, что: «Большинство людей выздоравливает от нее в течение недели без какой-либо медицинской помощи. Распространенные респираторные заболевания, которые связаны с сезонным гриппом и могут привести к смерти, включают в себя пневмонию и бронхит. » Сухие цифры статистики. Ни воплей, ни криков. Спокойно сообщали: «650 тысяч трупов в год».

Что мы имеем сейчас?

На момент написания этой статьи с момента возникновения заражения в Ухане прошло круглым счетом 3 месяца. То есть — четверть года. Смертность от гриппа covid-19 4.6 % в среднем в мире и менее 0.7 % в Германии (где медицина просто в шесть с половиной раз в среднем лучше, чем везде). Количество заболевших в мире — менее 670 000 человек.

При этом, даже исключая сезонность заболевания (считаю среднее арифметическое!), ВОЗ вполне допускал ранее за такой же период времени более 4 000 000 (четырех миллионов!) заболевших и 162 500 умерших, пандемию не объявляли! Конечно, смертность среди пожилых выше, но так было всегда, посмотрите статистику!

Что предлагаем мы в сложившейся ситуации? Готовы предложить вам аренду выделенного сервера в дата-центре Москвы. Аренда выделенного сервера (дедика) в дата-центре в России, Москва. Выделенные серверы Intel Xeon в аренду.

Собственно, чтобы два раза не вставать: у нас есть надежные серверы для вашего бизнеса. Арендуйте физический сервер для проектов с любой посещаемостью. Физические выделенные серверы. Мощные серверы Asus и Supermicro для сложных проектов с большой нагрузкой и особыми требованиями к надежности. Все серверы имеют доступ в IPMI и безлимитный трафик.

Всем рекомендую сохранять спокойствие, не поддаваться паническим атакам, меньше читать и смотреть новости. Не следует отменять вклады, покупать валюту и скупать продукты в прок. Не стоит вступать в конфликт с представителями власти — они на работе (а работа у них собачья) и могут не проявить сдержанность.

По-возможности нужно следовать старым советским догмам: проветривать помещение, больше находиться на свежем воздухе и на солнце — ультрафиолет губит любые вирусы, в том числе фейковые!

Всё будет хорошо, это обычный вирус гриппа, таких в год бывают десятки!

Довольно часто для установки различных операционных систем используем загрузку выделенного сервера в режим rescue, используя диcтрибутив grml. При этом в отечественных датацентрах отчего то не предоставляется услуга загрузки из сети и даже получение сетевых настроек по DHCP. Поэтому приходится действовать так:

# Сразу после загрузки GRML, даем
ifconfig eth0 45.156.200.66/27
# или, через ip:
ip a add 45.156.200.66/27 dev eth0
ip route add default via 45.156.200.65
# и следом настраиваем resolv.conf
echo "nameserver 8.8.8.8" >> /etc/resolv.conf

После этих манипуляций появляется сеть, остается только скачать скрипт grml.sh и начинать установку ОС. Конечно же, можно воспользоваться штатной утилитой grml-network, которая в диалоговом режиме позволяет настроить сеть.

Оказывается, что формат PDF не всегда верно интерпретируют старинные принтеры типа Canon LBP-810, LBP-1120 и аналогичных. При попытке печатать страница «расползается» и текст становится не читаемым. Проблема решается конвертированием PDF в TIFF

На Fedore моментально используем Ghostscript и действуем так:

gs -r300 -o page-tiffg4.tif -sDEVICE=tiff24nc source.pdf

где:

-r — разрешение в DPI,

-sDEVICE=tiff24nc — глубина цвета, может быть tiff32nc или tiff4

-o новый файл

source.pdf исходный файл

Потребовалось установить бесплатный SSL-сертификат от Let’s Encrypt на сервер с CentOS 7 и с Apache в качестве веб-сервера. Проще всего сделать это с помощью Certbot — написанного на python плагина, который позволяет получить и регулярно обновлять SSL сертификат для домена, поскольку выданные Let’s Encrypt сертификаты действительны только 90 дней с момента генерации.

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

Впрочем, не будем растягивать инструкцию, мне за символы тут никто не платит… Приступаем!

Если у вас в CentOS уже установлен репозиторий от epel, то этот пункт можно пропустить. Проверить, установлен ли у вас epel можно так:

# установлен ли у вас epel ?
yum repolist | grep epel
 * epel: mirror.freethought-internet.co.uk
epel/x86_64               Extra Packages for Enterprise Linux 7 - x86 

Иначе действуем так:

# Подключаем epel release:
yum install -y epel-release

Следующий ход — устанавливаем плагин certbot для apache:

# устанавливаем плагин certbot для apache:
yum install -y certbot python2-certbot-apache 

Генерируем (выпускаем) сертификат:

# Сначала останавливаем на время генерации наш web-сервер:
service httpd stop
# Генерируем (выпускаем) сертификат.
certbot certonly --standalone --agree-tos --email NAME@YOURMAIL.ru -d YOUR_DOMAIN.ru
# Стартуем web-сервер:
service httpd start

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

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/YOUR_DOMAIN.ru/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/YOUR_DOMAIN.ru/privkey.pem
   Your cert will expire on 2019-11-10. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"

Видим наш сертификат, который нужно еще добавить в конфиг вашего домена YOUR_DOMAIN.ru. Создаем файл с конфигом в директории /etc/httpd/conf.d/. Пример конфига ниже:

SSLStaplingCache shmcb:/tmp/stapling_cache(128000)

#SSL
SSLEngine On
SSLCertificateFile      /etc/letsencrypt/live/YOUR_DOMAIN.ru/fullchain.pem
SSLCertificateKeyFile   /etc/letsencrypt/live/YOUR_DOMAIN.ru/privkey.pem
# SSL stapling
SSLUseStapling on
# Intermediate configuration, tweak to your needs
SSLProtocol             all -SSLv2 -SSLv3
SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
SSLHonorCipherOrder     on
SSLCompression          off
SSLOptions +StrictRequire

ServerAdmin support@YOUR_DOMAIN.ru
ServerName YOUR_DOMAIN.ru
DocumentRoot /home/diman/YOUR_DOMAIN.ru/public
RewriteEngine off

        RewriteEngine On
        RewriteCond %{REQUEST_FILENAME} -s [OR]
        RewriteCond %{REQUEST_FILENAME} -l [OR]
        RewriteCond %{REQUEST_FILENAME} -d
        RewriteRule ^.*$ - [NC,L]
        RewriteRule ^.*$ index.php [NC,L]
        Options -Indexes +FollowSymLinks +MultiViews
        AllowOverride All
        Require ip 9.9.9.9

        Require all granted

ErrorLog /var/log/httpd/YOUR_DOMAIN.ru.error.log
CustomLog /var/log/httpd/YOUR_DOMAIN.ru.access.log combined

Конечно же, нужно не забыть и разрешить 443 порт в firewall.

Теперь перезапускаем apache и, если все нормально, то делаем редирект из http в https:

# Останавливаем web-сервер:
service httpd stop
# Стартуем web-сервер:
service httpd start
# Для редиректа из http -> https ддобавляем в конфиг http:
 
    Redirect permanent / https://YOUR_DOMAIN.ru/
  
# И снова рестартим web-сервер..

Для продления SSL сертификата требуется регулярно, не менее 1 раза в 90 суток выполнять скрипт, который будет обновлять все сертификаты. Мы будем пытаться обновить его каждое воскресенье в 3:55. Для этого добавим в крон задание:

crontab -e 
55 03 * 1,3,5,7,9,11 6 /usr/sbin/service httpd stop;  /usr/bin/certbot renew; /usr/sbin/service httpd start