Отключение IPv6 в CentOS 8

 Есть несколько способов по отключению ipv6 в linux, через ядро, через настройки сетевого интерфейса, я же предпочитаю отключать в загрузчике GRUB.

Открываем  /etc/default/grub и добавляем новой строкой следующее:

GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX ipv6.disable=1"

Сохраняем и закрываем файл.

Теперь следует обновить конфиг grub.cfg, выполняем команду

ls -la /etc/grub*.cfg

 и видим пути до 2х файлов

/boot/grub2/grub.cfg
/boot/efi/EFI/centos/grub.cfg

Следующие 2 команды перегенерируют новые конфиги с учетом наших изменений

grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg

Теперь остается перезагрузить наш сервер и проверить, что поддержка ipv6 действительно отключена для интерфейсов.

P.S. 

На этапе перегенерации конфигов я столкнулся с такой ошибкой:

Для решения было достаточно пересоздать grubenv командой

 grub2-editenv create

Отмечу, что все действия производились на свежеустановленной ОС.

OpenVPN. Не подключаются клиенты, ошибка certificate verify failed

Столкнулся с проблемой, удаленные клиенты не могут подключиться по OpenVPN.

В логе openvpn.log обнаружил следующее:

WARNING: Failed to stat CRL file, not (re)loading CRL.
VERIFY ERROR: depth=0, error=CRL has expired: CN=client, serial=292462498369187844598607062130070224235
OpenSSL: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
TLS_ERROR: BIO read tls_read_plaintext error
TLS Error: TLS object -> incoming plaintext read error
TLS Error: TLS handshake failed
Fatal TLS error (check_tls_errors_co), restarting

Ключевое, на что нужно обратить внимание, это WARNING: Failed to stat CRL file, not (re)loading CRL.

Заходим в директорию с easyrsa и там выполняем команду:

openssl crl -inform PEM -in pki/crl.pem -text -noout

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

Last Update: Jul 28 21:28:59 2020 GMT

                Next Update: Jan 24 21:28:59 2021 GMT

Это значит, что прошло 180 дней с момента последнего запуска по генерации списка отозванных сертификатов и срок действия его - как раз 180 дней.

Чтобы исправить ситуацию, необходимо выполнить команду 

./easyrsa gen-crl

и скопировать новый crl.pem по пути, который указан в Вашем опенвпн сервер конфиге.

Но я решил также и увеличить срок действия списка до 720 дней, для этого нужно открыть файл vars и увеличить значение для EASYRSA_CRL_DAYS.

Проверяем:

openssl crl -inform PEM -in pki/crl.pem -text -noout

Last Update: Jan 25 10:30:58 2021 GMT

                Next Update: Jan 15 10:30:58 2023 GMT

Обновление Redmine и миграция между двумя серверами

Пришла пора обновить redmine с 3.4* версии до последней стабильной 4.1.1, при этом с переносом на другой сервер. 

Старый сервер с Redmine 

• CentOS 7
• mysql 5.5
• ruby 2.0 / rail 4.2
• thin (gem сервер приложения)

Новый сервер с Redmine

• CentOS 8
• mariadb 10
• ruby 2.6.5 / rails 5.2
• thin (gem сервер приложения)

Ниже опишу шаги, которые необходимо произвести, чтобы миграция прошла без проблем (в моем случае отработало без ошибок). 

1. Установка нужной версии Redmine по инструкциям с сайта https://redmine.org
2. На старом redmine я отключаю все задачи cron для сервиса, в том числе и для получения почты (Подробнее о настройке по ссылке)
3. Останавливаю сервис thin systemctl stop thin
4. Удаляю установленные плагины, точнее чистим записи в базе, если для установки плагина требуется миграция (Подробнее про удаление по ссылке)
5. Далее снимаем дамп с БД mysqldump -u root -p redmine > redmine.sql (В моем случае используется mysql)
6. Переносим на новый сервер scp redmine.sql root@192.168.1.1:/tmp Теперь выполняем команды на новом сервер
7. cp /tmp/redmine.sql /path/to/redmine/
8. Восстанавливаем дамп mysql -u root -p redmine < redmine.sql
9. Теперь обязательный пункт, это совершить миграцию базы, чтобы применились изменения, иначе будет ошибка 500 при переходе в проекты rake db:migrate RAILS_ENV=production
10. Дополнительно перезапускаем сервис thin
11. Устанавливаем плагины
12. Перенастраиваем адреса для проксирования, если есть пограничный сервер (в моем случае в роли обратного прокси выступает nginx)

Acronis ломает загрузчик

Столкнулся с проблемой, подготовил систему с debian на борту и снял образ средствами Acronis True Image Home ( live usb)

https://kb.acronis.com/content/4974

https://kb.acronis.com/content/1686

sudo mount /dev/sd*** /mnt
sudo mount /dev/sd** /mnt/boot/efi
for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
sudo chroot /mnt
grub-install /dev/sd*
update-grub  

Обращаю внимание, что sd* = диск | sd** = efi партиция | sd*** = системная партиция
Для определения партиций можно воспользоваться утилитой GParted (я грузился с GParted liveusb)

P.S. Заметка с 2017 валялась в черновиках и наконец-то увидела свет, возможно еще актуальна :)

Переименовываем vmdk диск виртуальной машины на VMware ESXi

Занялся аудитом инфраструктуры и столкнулся с плохими названиями виртуальных машин, из которых неясна ее роль, либо назначение.

Есть 2 способа (их больше, но эти самые простые на мой взгляд).

1) Переименовать vm путем клонирования, удалив затем оригинальную vm

Минус этого способа - время простоя зависит от размера *-flat.vmdk файла (сам диск с данными).

2) Переименовать vm путем правки *.vmx конфигурационного файла и использование утилиты vmkfstools

Необходимо зайти по ssh на нужный ESXi, перейти в директорию с vm и найти строку в .vmx scsi0:0.fileName = "name.vmdk"  чтобы заменить значение на новое name_new.vmdk.

Переименовываем name.vmx в name_new.vmx

Запускаем vmkfstools -E name.vmdk name_new.vmdk

После выполнения нужно:

- переименовать папку в datastore Browser

- удалить файлы со старым названием

- добавить виртуалку в Инвентарь и включить ее.