1С

Обновление серверной платформы 1С на Linux

Скачиваем дистрибутив c сервером и закидываем на тачку с линуксом. В моем случае версия будет server64_8_3_27_1859.

Прежде чем продолжить, я бы отключил сеансы пользователей от самой 1С-ки.

Переходим в каталог с текущей версией 1С, запускаем службу ras и смотрим идентификатор кластера утилитой rac

cd /opt/1cv8/x86_64/8.3.25.1560/
./ras --daemon cluster
./rac cluster list

Смотрим активные сессии, подставив свой идентификатор


./rac session --cluster="Здесь вставить идентификатор кластера" list | grep session

И далее выгоняем все сессии

./rac session --cluster="Здесь вставить идентификатор кластера" terminate --session="Здесь вставить ID сессии"

Останавливаем службу сервера

systemctl stop srv1cv8-8.3.25.1560.service
systemctl stop ras-8.3.25.1560.service

Отключаем службу

systemctl disable srv1cv8-8.3.25.1560.service
systemctl disable ras-8.3.25.1560.service

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

cd /home/user/server64_8_3_27_1859
chmod +x setup-full-8.3.27.1859-x86_64.run
./setup-full-8.3.27.1859-x86_64.run --mode unattended --enable-components server,ws,server_admin

Далее регистрируем службу и автозапуск 

systemctl link /opt/1cv8/x86_64/8.3.27.1859/srv1cv8-8.3.27.1859\@.service
systemctl link /opt/1cv8/x86_64/8.3.27.1859/ras-8.3.27.1859.service

systemctl start srv1cv8-8.3.27.1859@default.service
systemctl start ras-8.3.27.1859.service

systemctl enable srv1cv8-8.3.27.1859@default.service
systemctl enable ras-8.3.27.1859.service

systemctl status srv1cv8-8.3.27.1859@default.service
systemctl status ras-8.3.27.1859.service

После этого у нас должно все заработать!

Т.к. у меня единственный кластер, и место на нем ограничено, я удаляю старые версии 1С-ок

Переходим в каталог со старой версией 1С и запускаем деинсталляцию

cd /opt/1cv8/x86_64/8.3.25.1560/
./uninstaller-full

ВАЖНО! Если у вас есть файл usr1cv8.keytab, то его необходимо сохранить и подключить в новой версии…

Бэкап и восстановление баз 1С на PostgreSQL

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

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

sudo pg_dump -Fc -h localhost -p 5432 -U postgres -d  buhgalteriya -f /home/ivan/buhgalteriya.custom

-Fc — Указывает что формат вывода custom
-h — Имя или ip сервера
-p — Порт сервера
-U — Имя пользователя для доступа в БД
-d — Имя БД которой надо сделать бэкап
-f — Путь и название БД

Треть пути пройдено! После того как мы сделали бэкап боевой базы, нам необходимо убедиться что она не битая. Для этого необходимо создать тестовую базу в PostgreSQL и зарегистрировать в кластере 1С.

Можно все это по отдельности через консоль, но мы пойдем легким путем через консоль администрирования 1С.

Далее заполняем данные. Желательно поля «Имя» и «База данных» совпадали — что бы потом не запутаться. Потому что имя базы в 1с и в postgres — это разные вещи. Не забываем поставить галочку «Создать базу данных в случае ее отуствия»

База должна появиться в списке. Можно сразу попробовать зайти в 1С и подключиться к базе. Но т.к. она пустая — смысла нет. Поэтому переходим к этапу восстановления.

Возвращаемся на сервер с БД и вводим команду:

sudo pg_restore -h localhost -p 5432 -U postgres -e -W -d test -v /home/ivan/buhgalteriya.custom

-h — Имя или ip сервера
-p — Порт сервера
-U — Имя пользователя для доступа в БД
-e — Прерывает процесс восстановления при возникновении ошибки
-W — Запрос пароля для пользователя
-d — Указывает в какую БД необходимо восстановить
-v — Показывает подробный вывод процесса восстановления

На данном этапе возможна ошибка восстановления. Происходит эт из за того что БД в postgres создана через 1С с какой-то кривой кодировкой. Особо вникать не стал, но решается это удалением БД через postgres и созданием ее снова.

sudo dropdb -h localhost -U postgres test
sudo createdb -h localhost -E UTF8 -U postgres test
sudo pg_restore -h localhost -p 5432 -U postgres -e -W -d test -v /home/ivan/buhgalteriya.custom

После этого у нас все должно восстановиться без ошибок. Можно запустить 1С и попытаться войти в базу. Важно! Было замечено, что если дропнуть БД, потом создать, потом попытаться войти в 1С, то команда восстановления уже не сработает. Т.е. необходимо что бы удаление, создание и восстановление — шло друг за другом, и никто в это время не пытался влезть в базу!

Бинго!

Публикация базы 1С на Linux

Предположим что у вас уже установлена Клиент-Серверная платформа 1С… В моем случае это Debian 12 и 1С 8.3.25.1560. Первым делом необходимо обновить пакеты:

apt update && apt upgrade

Устанавливаем сервер Apache и добавляем его в автозагрузку. Так же сразу узнаем его версию:

apt install apache2
systemctl enable apache2
systemctl status apache2
apache2 -v

Создадим папки с публикациями наших баз:

mkdir /var/www/1c
mkdir /var/www/1c/buhtest

Переходим в папку с платформой 1С и публикуем базу:

cd /opt/1cv8/x86_64/8.3.25.1560/
./webinst -publish -apache24 -wsdir buhtest -dir /var/www/1c/buhtest -connstr "Srvr=db;Ref=buhtest" -confpath /etc/apache2/apache2.conf

Перезапустим Apache:

systemctl restart apache2

Пробуем открыть нашу базу через браузер… И если все хорошо, то увидим заветную картину:

Если хотим что бы работало по HTTPS, то необходимо изменить конфигу Apache:

nano /etc/apache2/sites-available/000-default.conf

<VirtualHost *:443>
		SSLEngine on
		SSLCertificateFile /etc/ssl/certs/server1.crt
		SSLCertificateKeyFile /etc/ssl/certs/server1.key
</VirtualHost>

Включаем модуль SSL для Apache и перезапускаем:

sudo a2enmod ssl
systemctl restart apache2

После этого базы будут доступны по протоколу HTTPS!