Базы данных

Обновление серверной платформы 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, то его необходимо сохранить и подключить в новой версии…

Редактирование ссылок в Nextcloud

Возможно, кому-то, когда-то требовалось изменить ссылку общего доступа в Nextcloud. В моем случае, мне необходимо было раскатить пользователям VPN клиенты. Закинул все в облако. А ссылка сформировалась в виде:

Естественно неудобно куда-то заходить, что-то искать, копировать вставлять и тд. Но вообще причин может быть множество. Но перейдем к сути, как изменить ссылку на свою?

Описывать весь процесс не буду, но первое что нам надо, это зайти в базу nextcloud

               sudo mysql -u root

Смотрим БД — Заходим в БД nextcloud — Смотрим список таблиц в БД — Смотрим какие колонки есть в таблице oc_share

               show databases;
               use nextcloud;
               show tables;
               SHOW COLUMNS FROM oc_share;

Далее ищем нашу ссылку. Если сделали недавно или только что, то можно просто отсортировать по ID, если давно, то лучше искать по token (как раз это наша ссылка)

               SELECT id, item_type, file_target, token FROM oc_share ORDER BY id DESC LIMIT 10;
               UPDATE oc_share SET token = "vpn" WHERE id=2049;

Что бы выйти:

\q

После этого у нас ссылка будет выглядеть так:

Подключение Grafana к БД PostgreSQL

В данной статье будем забирать данные из базы PostgreSQL в дашборд Grafana. Переходим к делу:

Первым делом нам необходима развернутая БД и естественно Grafana. В моем случае будет данная среда будет развернута с помощью docker-compose

version: '3.9'

services:
  postgres:
    container_name: postgres
    image: postgres:15
    networks:
      default:
        ipv4_address: 172.20.0.101
    restart: always        
    environment:
      POSTGRES_DB: name_db
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: your_secure_password
    ports:
      - "5432:5432"
    volumes:
      - ./postgres:/var/lib/postgresql/data

  grafana:
    container_name: grafana
    image: grafana/grafana
    networks:
      default:
        ipv4_address: 172.20.0.103
    links:
      - postgres
    restart: always
    ports:
      - '3000:3000'
    depends_on:
      - postgres
    volumes:
      - ./grafana-storage/_data:/var/lib/grafana

networks:
  default:
    ipam:
      driver: default
      config:
        - subnet: 172.20.0.0/16

В базе данных необходимо создать таблицы и наполнить их данными, которые мы будем извлекать… Если прям вручную, то можно с помощью программы DBeaver(бобер). Описывать данный процесс не буду.

Заходим в нашу графану по ip и порту 3000: http://localhost:3000 со стандартным логином и паролем admin:admin

Далее нам необходимо придумать новый пароль или нажать skip, если хотим оставить стандартные.

После этого попадаем в главное окно.

Далее нам необходимо настроить источники. Заходим в Connections — Data sources — PostgreSQL

Заполняем данные для подключения к БД.

Вводим имя источника. Host-URL — нам необходимо указать ip адрес контейнера, тк. они ж у нас в одной виртуальной сети. Имя БД, пользователя и пароль вводим свои, какие задали. Т.к. у нас нет SSL , поэтом упроверку ставим в DISABLE.

Остальные параметры оставляем по умолчанию. Листаем вниз и жмем Save & test

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

Переходим в Dashboards — Create dashboard

Жмем Add visualization

Выбираем наш источник

Далее мы попадаем сразу в создание новой панели и в конструктор запросов. Либо можно создавать запросы с помощью SQL синтаксиса

Мне больше нравится использовать SQL запросы для выборки данных

Построим на основе этого простой график.

Сохраняем панельку и любуемся результатом

Бэкап и восстановление баз 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!