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

Критично: срочно, сегодня обновите платформу "1С:Предприятие 8"!
https://1c.ru/news/info.jsp?id=29958

У 1С что-то случилось. Подробности не говорят, скорее всего будет понятно завтра. Меня тоже зацепило. Сам лично так и не смог скачать последнюю версию платформы с сайта 1С. Похоже, там всё перегружено. Поделился знакомый в итоге.

Фирма "1С" доводит до сведения пользователей и партнеров, что в версиях платформы "1С:Предприятие" 8.3.22.1672, 8.3.22.1603, 8.3.21.1607, 8.3.21.1508, 8.3.21.1484, 8.3.20.2076, 8.3.20.2039, 8.3.19.1665, 8.3.19.1659, 8.3.18.1902, 8.3.18.1894, 8.3.17.2733, 8.3.17.2665 обнаружена критическая проблема, которая может привести к закрытию приложения в начале работы с программой.

Изменение внешних условий 15.11.2022 может существенно повысить вероятность проявления данной проблемы – предполагается, что многие пользователи перечисленных версий завтра не смогут работать.

Проблема не приводит к потере данных пользователей.

Положил платформу windows64full_8_3_22_1704.rar к себе на Яндекс.Диск для тех, кто тоже не сможет сам скачать:
https://disk.yandex.ru/d/f5rJTFMavNWwJQ

#1С

1С последнее время стала часто менять установщик сервера под Linux. Сначала с переходом на единый дистрибутив поменялся процесс обновления и установки сервера. А теперь по мере изменения версий в рамках единого установщика тоже происходят заметные изменения. То gnome на сервер автоматом ставит, а не так давно вместо скрипта запуска для init.d, появился unit для systemd.

Во время очередного обновления я немного затупил и решил записать актуальную пошаговую инструкцию по обновлению сервера 1С на Linux, чтобы просто на неё посмотреть и всё сделать, а не вспоминать, что делал в прошлый раз.

1️⃣ Останавливаем сервер 1С. В зависимости от установленной версии, команда будет выглядеть по-разному. До 8.3.21 вот так:
# systemctl stop srv1cv83
После 8.3.21 примерно так:
# systemctl stop srv1cv8-8.3.21.1484@default

2️⃣ Я рекомендую сохранить настройки кластера из домашней директории /home/usr1cv8/.1cv8/1C/1cv8. Только текстовые файлы с настройками, больше ничего. У меня разок была ситуация, когда обновлял тестовый сервер, где .1cv8 была символьной ссылкой на другой том. По какой-то причине она была заменена на новую пустую директорию. Когда запустил сервер, очень удивился, что в списке баз пусто. А их там было штук 30. Сервер хоть и тестовый, я всегда сначала на нём проверял обновления, но всё равно перспектива добавления заново всех баз не радовала. Решил детальнее разобраться, что случилось и заметил, что символьная ссылка пропала. Вернул её на место и все базы восстановились.

Тем не менее, у меня были ситуации, когда я терял настройки сервера. Хоть и некритично, но всё равно неприятно. Лишняя работа. Рекомендую параметры сохранять перед обновлением.

3️⃣ Качаем дистрибутив единого установщика и копируем на сервер. Имя файла имеет примерно такой формат: server64_8_3_22_1709.tar.gz. Распаковываем:
# tar xzvf server64_8_3_22_1709.tar.gz
Можно сразу запустить установщик ./setup-full-8.3.22.1709-x86_64.run и интерактивно выбрать все настройки, либо запустить в пакетном режиме, указав необходимые настройки. Например:
# ./setup-full-8.3.22.1709-x86_64.run --mode unattended \
--enable-components server,ws,client_full
Установили компоненты: Сервер 1С, модуль расширения веб сервера, толстый клиент.

4️⃣ Если раньше был скрипт запуска в /etc/init.d/srv1cv83, удаляем его. Вместо него устанавливаем юнит systemd:
# systemctl link /opt/1cv8/x86_64/8.3.22.1709/srv1cv8-8.3.22.1709@.service
Добавляем в автозагрузку и запускаем:
# systemctl enable srv1cv8-8.3.22.1709@.service
# systemctl start srv1cv8-8.3.22.1709@.default
Обращаю внимание, что команда на запуск изменилась. Нужно добавлять имя экземпляра сервера. По умолчанию - default. Так сделано для того, чтобы было удобно запускать несколько разных экземпляров сервера с разными настройками на одном хосте, повесив их на разные порты.

5️⃣ Напомню, что управлять кластером 1С можно с помощью бесплатной панели управления ПУСК. Если у вас оснастки администрирования установлены на Windows машине, не забудьте там обновить платформу и зарегистрировать утилиту администрирования новой версии, иначе не получится подключиться к обновлённому серверу. Я частенько забываю это сделать.

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

#1с

​​Хочу поделиться информацией по поводу публикации баз 1С по HTTP. Регулярно получаю вопросы по этой теме, очень актуальная. Да и статьи писал не раз по этому поводу. У меня есть довольно большой практический опыт настройки и поддержки работы таких баз.

Работа с 1С через браузер выглядит очень заманчивой, так как сильно упрощает сопровождение пользователей. Им достаточно дать ссылку на сайт и пусть работают. На деле, к сожалению, не всё так просто.

Начну с того, что некоторый функционал по управлению базой в принципе не работает через веб клиент. Например, обновление конфигурации или создание резервной копии. Это актуально для небольших файловых баз, которые обновлять или бэкапить могут сами пользователи. Так как работа в браузере осуществляется через веб клиент, а клиент это не конфигуратор, то работа в нём через браузер тоже невозможна.

Ограничения это ладно, с ними можно разобраться, так как они известны. Но, к сожалению, через браузер иногда возникают проблемы с работой основного функционала. Это бывает не часто, но бывает. Я сталкивался не раз и не два. Например, обновляется Chrome и какой-то запрос при работе с базой начинает зацикливаться и блокироваться браузером. При этом в том же Firefox продолжает нормально работать. В следующем обновлении платформы или конфигурации это может быть исправлено, а может и нет. Также сталкивался с тем, что какие-то то ли формы, то ли отчёты или другой функционал не открывался через браузер. Ошибка появлялась тоже после очередного обновления. Решения тупо нет, надо сидеть и ждать, либо откатываться назад. Ситуация очень неприятная.

При этом, если использовать стандартную платформу и подключать в ней базу по HTTP, этих ошибок нет. Они возникают только при работе через браузер. Получается, что обслуживать машины пользователей всё равно придётся, обновляя им платформу и подключая базы.

💡 При всех этих минусах, публикация в веб решает другую важную задачу - доступ к базе без настройки доступа к самой инфраструктуре. Не нужны ни VPN, ни терминальный доступ, ни пробросы портов. Достаточно опубликовать базу в веб, закрыть её дополнительным паролем на уровне веб сервера и безопасно предоставить доступ внешним клиентам. Кого-то может и устроит работа в браузере, если он выполняет очень простые операции. Всем остальным можно поставить платформу и нормально работать, не забывая её обновлять вместе с сервером.

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

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

#1С

Я обновил и актуализировал популярную на сайте статью по настройке сервера 1С:

Установка и настройка 1С на Debian с PostgreSQL
⇨ https://serveradmin.ru/ustanovka-i-nastrojka-1s-na-debian-s-postgresql/

Статья подробная. Позволяет простым копированием и ставкой настроить указанную связку. В ней показаны:

✅ Установка и настройка свежей версии сервера 1С и PosgtreSQL 15 на Debian 11.
✅ Пример создания баз данных на этом сервере и подключение к ним.
✅ Бэкап и обслуживание postgresql баз утилитами сервера бд. Рассказываю про свой подход к этому процессу и привожу скрипты автоматизации. 
✅ Как я тестирую восстановление из sql дампов и делаю контрольную проверку в виде выгрузки баз в .dt файлы в консоли Linux. Всё это автоматизируется скриптами. 
✅ Рассказываю про свои подходы к мониторингу этих бэкапов и выгрузок, чтобы всегда быть уверенным в том, что у тебя есть гарантированно рабочие бэкапы.

Всё описанное основано на личном опыте настройки и эксплуатации подобных систем. Ни у кого ничего не смотрел, лучших практик не знаю. Придумал всё сам и сделал, как посчитал нужным. Так что не нужно это воспринимать как оптимальное решение.

#1с #postgresql

Недавно планово обновлял один из серверов 1С в связке с PostgreSQL, работающий на Debian. Сервер настроен примерно так же, как описано в моей статье:
⇨ Установка и настройка 1С на Debian с PostgreSQL
А обновление делал по этой статье:
⇨ Обновление Сервера 1С под Linux

Статьи в целом актуальны. Обновление сделал сначала на тестовом сервере клоне. Обновил, проверил работу сервера, баз. Всё нормально. Потом перешёл к рабочему. Обновил штатно, но начались проблемы.

Выражалось это в том, что раза в 2-3 возросла нагрузка по CPU. В целом, всё работало, но очень медленно. Через панель администрирования было видно большое количество фоновых задач. При этом они не висели, но выполнялись явно медленно, поэтому их было в списке аномально много. Больше обычного в несколько раз.

Какое-то время разбирался в проблеме, пытаясь понять, с чем это связано. Полный дублёр этого сервера не имел таких проблем. В итоге заглянул в лог postgresql и заметил, что там куча сообщений об исчерпании лимита доступных подключений, хотя в обычное время их достаточно. Судя по всему по какой-то причине на боевом сервере зависли соединения.

Остановил сервер 1С, перезапустил postgresql и запустил заново 1С сервер. Работа нормализовалась. Контроль соединений к базе данных — один из ключевых параметров, которые надо мониторить. Здесь это не было сделано. Пришло время настроить.

На что ещё обратить внимание при обновлении:
1️⃣ Периодически установщик 1С ставит дополнительные пакеты. Например, в этот раз заметил, что он установил Apache. Мне он был не нужен, удалил.
2️⃣ Проверьте, что вы точно удалили из автозапуска службу со старой версией 1С. Я в одном месте ошибся и удалил неправильно. Там немного отличаются команды. Например, остановка сервиса выполняется командой:
# systemctl stop srv1cv8-8.3.22.1709@.default
А удаление из автозапуска:
# systemctl disable srv1cv8-8.3.22.1709@.service
Окончания в названиях службы разные. Я в одном месте ошибся и после перезагрузки получил две запущенные службы 1С сервера. Старая запустилась в качестве сервера, а новая версия валилась в ошибки постоянно. Самое удивительное, что заметили это только через 3 дня, так как платформа 1С у клиентов автоматически использовала старую версию и никто не обратил на это внимание.

#1С

​​У меня на днях будет задача по переносу баз 1С с MSSQL на PostgreSQL. Переезжаем полностью с Windows Server на Debian. По этому поводу у меня есть относительно свежая ссылка (2022 год):
⇨ Частые вопросы по миграции базы данных 1С с MS SQL на PostgreSQL
Пришло время с ней поработать. Делаю для вас краткую выжимку, чтобы можно было использовать как шпаргалку. А когда сделаю перенос, напишу, как всё организовал. У меня есть свой подход к организации сервера для 1С.

1️⃣ Тюним PostgreSQL под ресурсы системы. Особое внимание на параметры shared_buffers, work_mem, temp_buffers, huge_pages. Если будете использовать сборку от PostgreSQL Pro, то там все важные параметры настраиваются автоматически после установки пакета.

Отдельно обратите внимание на autovacuum_max_workers. Параметр вычисляют так: кол-во vCPU / 2. И так же по этой теме настраиваем autovacuum_vacuum_scale_factor, autovacuum_analyze_scale_factor, autovacuum_vacuum_cost_limit.

2️⃣ Тюним систему под максимальную производительность СУБД:
sysctl -w vm.swappines=2
sysctl -w vm.overcommit_memory=2

3️⃣ Сам перенос проще всего выполнить через выгрузку в dt и последующую загрузку. Если база очень большая и недопустим простой, то перенос можно выполнять с помощью планов обмена.

4️⃣ Выгружать и загружать dt файлы быстрее и удобнее через автономный сервер ibcmd. В этот момент базу лучше отключить от сервера приложений, либо просто остановить его на время, если есть возможность.

Подробно всё это описано в статье по ссылке. Там же есть и сравнение производительности. В среднем по всем тестам MSSQL немного быстрее PostgreSQL, но не критично. Есть тесты, где одна база быстрее другой и наоборот. Среднее, как я уже сказал, выходит немного в пользу MSSQL.

#1С

Свежая информация на тему настройки сервера 1С + PostgreSQL 15 на Debian. Я буквально на днях её выполнял. Моя статья по этой теме на текущий день полностью актуальна:

⇨ Установка и настройка 1С на Debian с PostgreSQL

Уточню только, что если будете настраивать выгрузку баз в dt, используйте сразу автономный сервер, если у вас нет желания и необходимости иметь полноценный клиент на сервере без установки графического окружения. Я этой теме много внимания уделил в статье, но необходимость в этом возникает редко и почти никому не нужно. А времени можно потратить много, так как настройка работы графических приложений через xvfb без установки полноценного рабочего стола нетривиальна и замороченна.

❗️ Важное дополнение, которое возможно сэкономит кому-то время. Сборка PostgreSQL 15 с патчами для 1С от Postgres Professional не поддерживает установку на Debian 12. Нету репозитория для этой системы. Мне хотелось всё развернуть на 12-й версии. Обманул установщик, подключил репы на Debian 12, но всё равно СУБД не установилась. Возникают проблемы с зависимостями.

Для получения этой версии PostgreSQL, необходимо сделать запрос на сайте https://1c.postgres.ru/ и вам придёт инструкция на почту. Кому не хочется этим заниматься, сразу даю ссылку на скрипт подключения репозиториев для всех поддерживаемых систем:

# wget https://repo.postgrespro.ru/1c-15/keys/pgpro-repo-add.sh
# sh pgpro-repo-add.sh

Или вот готовый репозиторий под Debian 11:

deb http://repo.postgrespro.ru/1c-15/debian bullseye main

Соответственно, если у вас 1С сервера на Debian 11, не торопитесь обновлять систему. А я уже кое-где собирался обновляться. Надо подождать, пока не появятся репозитории Postgres Professional под 12-ю версию.

#1С

У меня печальные новости для тех, кто использует сервер 1С под Linux. До недавнего времени он для запуска не требовал серверную лицензию, если использовалось не больше 12-ти клиентских соединений.

Я эту возможность всегда использовал для дублирования основного сервера. Копию использовал для тестирования обновлений, для восстановления бэкапов, для проверки восстановленных баз, для выгрузки dt, для тестирования баз и т.д. В общем, для служебных нужд. Пользователей туда не пускал.

Сначала я увидел комментарий к своей статье на сайте, где автор говорит, что версия 8.3.23.1865 без серверной лицензии не запускается. Подумал, что автор что-то делает не так. Но на днях я один из серверов тоже обновил на новую платформу 8.3.23.1865. Сделал всё как обычно. Сначала проверил обновление на тестовом сервере. Запускаю его, пытаюсь подключиться клиентом и вижу отказ, так как не найдена серверная лицензия.

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

Кто-то сталкивался уже с этим? Будет очень жаль, если работу Linux сервера без лицензии уберут совсем. Для тестовых целей это было очень удобно.

#1С

Попереживал тут на днях из-за своей неаккуратности. Настроил сервер 1С примерно так же, как описано у меня в статье:
⇨ Установка и настройка 1С на Debian с PostgreSQL

Сразу настроил бэкапы в виде обычных дампов sql, сделанных с помощью pg_dump. Положил их в два разных места. Сделал проверки. Всё, как описано в статье. Потом случилось то, что 1С убрали возможность запускать сервер на Linux без серверной лицензии. И вся моя схема проверки бэкапов сломалась, когда я восстанавливал дампы на копии сервера и там делал выгрузку в dt. И считал, что всё в порядке, если дамп восстановился, dt выгрузился и нигде не было ошибок. На основном сервере я не хочу делать такие проверочные восстановления.

Я всё откладывал проработку этого вопроса, так как надо разобраться с получением лицензии для разработчиков 1С, изучить нюансы, проработать новую схему и т.д. Всё никак время не находил.

И тут меня попросили восстановить одну базу, откатившись на несколько дней назад. Я понимаю, что дампы я не проверяю и на самом деле хз, реально ли они рабочие. По идее да, так как дампы делались и ошибок не было. Но если ты не восстанавливался из них, то не факт, что всё пройдёт успешно, тем более с 1С, где есть свои нюансы.

В итоге всё прошло успешно. Восстановиться из бэкапов в виде дампов довольно просто. За это их люблю и если размер позволяет, то использую именно их. Последовательность такая:

1️⃣ Находим и распаковываем нужный дамп.

2️⃣ Создаём новую базу в PostgreSQL. Я всегда в новую восстанавливаю, а не в текущую. Если всё ОК и старая база не нужна, то просто удаляю её, а новую делаю основной.
# sudo -u postgres /usr/bin/createdb -U postgres -T template0 base1C-restored

3️⃣ Проверяю, создалась ли база:
# sudo -u postgres /usr/bin/psql -U postgres -l

4️⃣ Восстанавливаю базу из дампа в только что созданную. ❗️Не ошибитесь с именем базы.
# sudo -u postgres /usr/bin/psql -U postgres base1C-restored < /tmp/backup.sql

5️⃣ Иду в консоль 1С и добавляю восстановленную базу base1C-restored.

Если сначала создать базу через консоль 1С и восстановить в неё бэкап, будут какие-то проблемы. Не помню точно, какие, но у меня так не работало. Сначала создаём и восстанавливаем базу, потом подключаем её к 1С.

Мораль какая. Бэкапы надо восстанавливать и проверять, чтобы лишний раз не дёргаться. Я без этого немного переживаю. Поэтому люблю бэкапы в виде сырых файлов или дампов. По ним сразу видно, что всё в порядке, всё на месте. А если у тебя бинарные бэкапы, сделанные каким-то софтом, то проверяешь ты их тоже каким-то софтом и надеешься, что он нормально всё проверил. Либо делать полное восстановление, на что не всегда есть ресурсы и возможности, если речь идёт о больших виртуалках.

#1С #postgresql

Для тех, кто работает с 1С, могу порекомендовать сайт Кухара Богдана. Я давно его знаю, подписан на его ютуб канал, смотрю выпуски. Не могу сказать, что там прям что-то очень нужное и полезное. Обычная базовая информация для системного администратора. Много рекламы его курса, куда он выносит наиболее интересные моменты из своих материалов.

Привлекло моё внимание его небольшой bat скрипт для бэкапа файловых баз в Windows, который он недавно анонсировал. Я много раз настраивал различным заказчикам файловые базы где-то на выделенном сервере. Это хорошее и экономное решение для работы 2-3 человек с базой. Актуально для аутсорсеров, где каждый бухгалтер ведёт кучу баз клиентов, и при этом работает там в основной один или с помощником.

- Описание скрипта
- Видео обзор

Файловая база представляет из себя обычный файл на диске, но при этом внутри там полноценная база данных. Не всегда простым копированием можно получить рабочий бэкап. Если во время копирования с базой работали пользователи, база может оказаться битой. То же самое с выгрузкой в dt. Она не является полноценным бэкапом, так как нет 100% гарантии, что из неё получится развернуть базу.

Самым надёжным способом сделать бэкап файловой базы - выгнать всех пользователей, запретить им вход и базу и после этого скопировать файл 1Cv8.1CD. Именно это и делает указанный скрипт, и не только. Он умеет:

▪️ Выгонять всех пользователей из базы и завершать работу платформы.
▪️ Если платформа зависла и штатно не завершила работу, завершает её принудительно.
▪️ Если база опубликована через Apache 2.4 на этом же сервере, то завершает сеансы 1С в веб сервере.
▪️ Жать бэкап базы с помощью 7zip.
▪️ Вести лог файл своей работы.
▪️ Запускаться через планировщик Windows.
▪️ Автоматически удалять старые копии.

Для корректной работы скрипта путь до файловой базы должен быть только латинскими буквами. Получилось готовое рабочее решение, которое можно сразу поставить в планировщик и настроить мониторинг лог файла, чтобы понимать, как прошёл очередной бэкап.

Отдельно советую на сайте посмотреть раздел Администратору 1С. Там много полезных материалов, в том числе свежая инструкция:

⇨ PostgreSQL 16 + Cервер 1С x64 и 1С 8.3.23 на Ubuntu 22.04

#1С

Давно уже посмотрел очень интересное видео про производительность сервера 1С, но всё откладывал заметку, потому что сразу не законспектировал. Автор очень хорошо подал материал и прошёлся по основным заблуждениям по этой теме. 1С в нашей стране - популярная тема, так что, думаю, многим будет интересно и полезно:

▶️ Из чего складывается производительность 1С и с чего начать расследование тормозов

Сделаю краткую выжимку основных моментов, чтобы вы понимали о чём там речь и стоит ли смотреть.

◽Если на сервере СУБД настроены все необходимые регламентные операции (обновление статистики, перестройка индексов, автокавкуум хорошо отлажен) и параметры адекватны железу, то это самое последнее место, куда следует лезть за поиском тормозов. Чаще всего тормозит что-то другое.

◽В большом количестве случаев причина тормозов 1С - клиентские компьютеры. Нехватка ресурсов, вирусы, антивирусы и т.д. Особенно, если работа идёт в терминальном сервере. Сами эти терминальники очень часто тормозят под пользовательской нагрузкой.

◽Скорость открытия конфигурации у разработчика вообще не показатель производительности сервера 1С. Конфигуратор может долго открываться по разным причинам.

◽Никакие настройки сервера 1С не увеличивают его производительность. Он всегда работает с максимальной производительностью. Он может зависать по разным причинам, но ускорить его работу какой-то настройкой невозможно. Таких настроек нет.

◽Никакой разницы производительности сервера 1С в редакциях ПРОФ и КОРП нет. Там полностью одинаковые экзешники сервера.

◽RAGENT и RMNGR - это чёрные ящики. Полностью закрытый код, на работу которого вы никак влиять не можете. Весь код 1С выполняется в RPHOST. И тормозит именно ваш код.

◽Главный грех программиста - поиск по журналу регистраций на продуктовой базе. Это вешает RMNGR от большой нагрузки. Любую базу можно положить через поиск в журнале по неиндексированному полю.

🔥 Полнотекстовый поиск нужно обязательно отключать на базах более 2 Гб.

◽Очень часто на сервере 1С тормозит диск из-за каталога сеансовых данных. Он хранится на диске. Постоянно перезаписывается огромный объём данных. Его надо вынести куда-то на быстрый диск. То же самое для временных файлов пользователя, под которым работает 1С. Их тоже надо куда-то на быстрый диск поместить. Всё это делается средствами операционной системы. В самой 1С настроек на этот счёт нет.

◽В dt можно выгрузить базу любого объёма. Никаких ограничений нет. Если не получается выгрузить базу, скорее всего у вас не хватает места на диске на сервере 1С для этого.

◽Очень часто тормоза дают фоновые задания. Их надо аккуратно настраивать.

В видео, соответственно, всё это подробно, с примерами разобрано. Мне очень понравилось, рекомендую. Конкретное с наглядными примерами повествование.

#1С

Пришлось не так давно переносить виртуальный сервер Windows с установленными программными клиентскими лицензиями 1C. Мне не так часто приходится с ними взаимодействовать, так что технических нюансов их работы я не знаю, как и не имею большой практики использования. Знаю только, что они жёстко привязаны к железу и очень чувствительны к изменениям. Расскажу, как у меня прошёл перенос.

На гипервизоре Proxmox стало не хватать ресурсов. Было принято решение взять в аренду идентичный сервер, чтобы разгрузить существующий и добавить ресурсов виртуалке. Как минимум процессор там был точно такой же. Изменилась версия гипервизора с 7-й на 8-ю. Воссоздал на новом сервере виртуалку с идентичными настройками и перенёс вручную диск виртуальной машины.

Пару дней сервер проработал нормально, а потом ругнулся на программную лицензию из-за изменения железа. Меня удивило, что случилось это не сразу. В информационном сообщении было указано, что изменилась цифра в версии биоса и mac адрес сетевого интерфейса. Его я забыл скопировать со старого сервера. Это был мой недосмотр. Хоть я наверняка и не знал, что есть привязка по маку, но надо было в любом случае таким же его оставить.

Интересное произошло дальше. Я изменил mac адрес сетевого интерфейса на старый и перезагрузил сервер. Он всё равно ругнулся на изменившийся mac адрес адаптера, показывая в качестве нового адреса тот, что я уже успел поменять на старый. Думаю, ладно, ничего не поделать. Пошёл добывать документы, пинкоды и т.д. Когда всё нашёл, решил перезагрузиться ещё раз. И, о чудо, всё заработало.

Несмотря на то, что версия bios всё же изменилась, лицензия не слетела. Изменив mac адрес обратно на старый, я вернул программным лицензиям жизнь без необходимости их обновления. Версия bios в моём случае выглядела примерно так:

SeaBIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org, 01.04.2014

Соответственно, на старом сервере цифры были немного другие. Вот для примера версия bios с другого гипервизора:

SeaBIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org, 01.04.2014

❗️Решил написать эту заметку, потому что везде в интернете видел информацию о том, что лицензия привязывается к версии bios. При переезде с гипервизора на гипервизор, да и просто при обновлении на новый релиз, информация о биосе меняется. Но лично в моём случае необходимости в обновлении лицензии в связи с этим не возникло. Также я не знал, что если вернуть конфигурацию обратно, то лицензии восстанавливаются. Думал, что они слетает безвозвратно.

#1С

На неделе возникла небольшая задача по публикации баз 1С через веб сервер. Сделал всё быстро, так как выполнял эту задачу не раз и не два. Там всё относительно просто, если понимаешь, что к чему и как работает. Да и статей ни одну написал по этой теме. Но всё это было давно ещё на базе Centos. А сейчас у меня всё на Debian, так что решил сразу написать статью по этой теме.

⇨ Публикация баз 1С на веб севере Apache в Debian

Хотел по-быстрому всё сделать, чтобы потом, если придётся настраивать, просто копипастом всё сделать. Но как обычно разошёлся, написал и про лицензии, и про сеансы, и про обратное проксирование через второй веб сервер, и про распределение функциональности по виртуалкам. В общем, написал всё, что вспомнил по ходу дела. Хотел ещё и про логи, мониторинг, файрвол написать, но не стал. Времени не осталось, да и не захотелось всё в кучу мешать. Надо разделять на темы и объединять ссылками.

Давно не писал новые статьи. А мне это нравится. Прям натуральное удовольствие получаю от их написания. Есть какое-то призвание и способности к этому. Мечтаю, когда дети подрастут и снизится финансовая нагрузка, потратить часть времени на создание какой-то связанной информационной библиотеки или обучающих курсов на отдельные изолированные темы, типа мониторинга или сбора логов. Жаль, что современные технологии напрочь убили монетизацию обычных статейных сайтов. Уже по-всякому прикидывал и тестировал монетизацию, но увы, дохода там почти нет. На это не прожить и даже как дополнительный заработок не тянет, поэтому остаётся только как хобби.

Это я на всякий случай предупреждаю тех, кто может строить планы по созданию сайта и получению какого-то прямого дохода с него. Я по всем своим делам строго веду бухгалтерию и точно знаю, где и как я получаю доход. В лучшие годы баннеры от рекламных сетей приносили по 20-30 т.р. ещё в то время, когда их покупательская способность была выше. Это примерно 2019-2020 год. Потом в 22-м заблокировали Adsense и доход упал где-то до 5 т.р. Я сетевые баннеры вообще снял. Оставил ровно один от Яндекса в середине статей, чтобы он ранжирование не понижал. Яндекс отдаёт больше предпочтения тем сайтам, где есть его реклама.

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

#1С #webserver