Подготовка дисков, очистка от старых метаданных:
mdadm --zero-superblock --force /dev/sdX wipefs --all --force /dev/sdX
Для сборки зеркала RAID1 применяем следующую команду:
mdadm --create --verbose /dev/md0 -l 1 -n 2 /dev/sd{X,Y}
Создаем файл подкачки размера 4Гб:
fallocate -l 4G /swapfile
Для обеспечения безопасности файла устанавливаем права:
sudo chmod 600 /swapfile
Создаем файловую систему swap на этом файле:
mkswap /swapfile
Объединение нескольких физических сетевых интерфейсов в виртуальный LACP Bond-интерфейс с поддержкой VLAN в Debian.
Устанавливаем пакеты, которые потребуются для работы bond-интерфейса:
apt-get install ifenslave ethtool
Пример уже настроенного конфигурационного файла /etc/network/interfaces:
Continue reading »
Установить пакеты:
— postgrespro-1c-XX-dev
— make
— gcc
— pgxnclient
Выполнить команду:
pgxn install pg_repack
Установить расширение в нужную базу:
su - postgres psql -c "CREATE EXTENSION pg_repack" -d your_database;
Шаги по восстановлению базы из бекапа с логами на определенный момент времени:
— Останавливаем службу postgres.
— Копируем архив последнего полного бекапа необходимые wal файлы с бекап-сервера, со времени полного бекапа в папку pg_wal.
— Удаляем все из папки /var/lib/pgpro/1c-16/data и распаковываем самый свежий бэкап.
— Меняем владельца папоки data рекурсивно на postgres:postgres
— В postgresql.conf требуется раскоментировать строки restore_command и recovery_target_time:
Continue reading »
В интернете достаточно легко находится способ переноса контейнеров закрытых ключей КриптоПро через копирование нужной ветки реестра, где это все хранится. Я воспользуюсь именно этим способом. А вот с массовым переносом самих сертификатов у меня возникли затруднения и я не сразу нашел рабочий способ. Расскажу о нем тоже.
Для дальнейшей работы нам надо узнать SID текущего пользователя, у которого мы будем копировать или переносить сертификаты с ключами. Для этого в командной строке выполните команду:
wmic useraccount where name='zerox' get sid
Как узнать SID пользователя
Continue reading »
Распаковать архив в «сырой» img-образ командой:
cat nvme0n1p1.ext4-ptcl-img.gz | gzip -d -c | partclone.ext4 -r -C --restore_raw_file -s - -o backup.img
Смонтировать образ:
mount -o loop backup.img /mnt/
Изменить значения в файле sysctl.conf на самом сервере Proxmox:
kernel.sem=250 32000 32 262 kernel.shmall=4194304 kernel.shmmax=17179869184 net.core.somaxconn=1024
Применить эти значения:
systemctl -p
Исправить параметр modify_kernel_parameters в конфигурации gitlab на false:
package['modify_kernel_parameters'] = false
Запустить переконфигурирование gitlab:
gitlab-ctl reconfigure
Пробросить папку на хостовом сервере в контейнер Proxmox:
pct set 103 --mp0 /host/dir,mp=/container/mount/point
где 103 — ID контейнера
Одним вариантом может быть описанный ниже способ, который позволит не заменить URL сайта на новый, а в целом «отключить» привязку CMS к конкретному домену. За счет этого WordPress перестанет выполнять редирект на какой-то определенный URL, прописанный в настройках.
Для этого в конфигурационный файл wp-config.php необходимо добавить следующий код:
if(isset($_SERVER['HTTPS'])) {
$schema = 'https://';
} else {
$schema = 'http://';
}
define('WP_HOME', $schema.$_SERVER['SERVER_NAME']);
define('WP_SITEURL', $schema.$_SERVER['SERVER_NAME']);
Этот способ может быть полезен не только при переносе сайта на новый домен, но и при возникновении каких-либо неполадок в работе сайта, связанных с его URL (например, при невозможности устранить редирект на https, и др.)