Продолжаю переписываться с поддержкой 1С по поводу того, что сервер не выдает клиенту комьюнити-лицензию, если клиент расположен на другой машине. Выясняю все методично и дотошно, спасибо им большое за терпение 🙏
А сегодня с утра в рассылке OpenYellow обнаружил занятный проект onec-community-docker. В нем максимально автоматизировано получение и продление комьюнити-лицензий на сервере и на клиенте 1С внутри докер-контейнеров.
Связался с автором. Оказалось, что Александр вообще только осваивает разработку в 1С и сделал этот проект для погружения в предметную область. Мое почтение! 💪 Накидайте ему, пожалуйста, звездюлей звезд на гитхабе!
Конечно, я сразу захотел портировать эти наработки в onec-docker.
Александр мне скинул ссылки на публикации и обсуждения на Infostart, где утверждается, что сервер 1С с активированной комьюнити-лицензией не раздает эти лицензии клиентам, даже если флажок "Разрешать выдачу лицензий сервером 1С:Предприятия" установлен (см. также --license-distribution=allow).
Обидно. Досадно. Но ладно ничего не поделаешь: придется активировать две лицензии - одну на сервере, одну на клиенте.
Кстати, это тот самый "способ обхода", про который я говорил в прошлом посте. Получается, что никакой это не обход, а штатное поведение.
А теперь про другой интересный нюанс. Когда моя лаборатория переехала на новый абсолютно чистый VPS-сервер, то при подключении с этого хоста к серверу 1С в поде Kubernetes я внезапно стал получать такую ошибку:
Сервер 1С:Предприятия использует лицензию для разработчиков. Запуск клиентского приложения Конфигуратор с лицензией ПРОФ и КОРП запрещен. Обратитесь ...
WTF???
Оказалось, что с этого сервера мне стали доступны чьи-то чужие клиентские лицензии, аж 300 штук. Клиент 1С использовал их, а потом выдавал ошибку, потому что комьюнити-лицензии нельзя смешивать с обычными лицензиями (кроме строго одного случая).
Кстати, поддержка 1C сообщила, что до 8.3.24 это ограничение было только на бумаге, а в последующих версиях оно уже реализовано на уровне платформы.
А проблема решилась запретом на использование аппаратных лицензий.
Такие дела!
В следующий раз буду ручками собирать настоящий кластер 1С из двух серверов. Ожидаю, что после этого будет более-менее понятно, что должен уметь делать minimum viable оператор для 1С и какими ресурсами он должен управлять. О том, что такое операторы в Kubernetes я писал тут.
🏆 Мини-викторина: в каком случае разрешено совместное использование обычных лицензий и комьюнити-лицензий?
Пишите ваши варианты в комментариях, победителю поставлю красивую звездочку ⭐️
Только чур никуда не подглядывать!
А сегодня с утра в рассылке OpenYellow обнаружил занятный проект onec-community-docker. В нем максимально автоматизировано получение и продление комьюнити-лицензий на сервере и на клиенте 1С внутри докер-контейнеров.
Связался с автором. Оказалось, что Александр вообще только осваивает разработку в 1С и сделал этот проект для погружения в предметную область. Мое почтение! 💪 Накидайте ему, пожалуйста, звездюлей звезд на гитхабе!
Конечно, я сразу захотел портировать эти наработки в onec-docker.
Александр мне скинул ссылки на публикации и обсуждения на Infostart, где утверждается, что сервер 1С с активированной комьюнити-лицензией не раздает эти лицензии клиентам, даже если флажок "Разрешать выдачу лицензий сервером 1С:Предприятия" установлен (см. также --license-distribution=allow).
Обидно. Досадно. Но ладно ничего не поделаешь: придется активировать две лицензии - одну на сервере, одну на клиенте.
Кстати, это тот самый "способ обхода", про который я говорил в прошлом посте. Получается, что никакой это не обход, а штатное поведение.
А теперь про другой интересный нюанс. Когда моя лаборатория переехала на новый абсолютно чистый VPS-сервер, то при подключении с этого хоста к серверу 1С в поде Kubernetes я внезапно стал получать такую ошибку:
Сервер 1С:Предприятия использует лицензию для разработчиков. Запуск клиентского приложения Конфигуратор с лицензией ПРОФ и КОРП запрещен. Обратитесь ...
WTF???
Оказалось, что с этого сервера мне стали доступны чьи-то чужие клиентские лицензии, аж 300 штук. Клиент 1С использовал их, а потом выдавал ошибку, потому что комьюнити-лицензии нельзя смешивать с обычными лицензиями (кроме строго одного случая).
Кстати, поддержка 1C сообщила, что до 8.3.24 это ограничение было только на бумаге, а в последующих версиях оно уже реализовано на уровне платформы.
А проблема решилась запретом на использование аппаратных лицензий.
Такие дела!
В следующий раз буду ручками собирать настоящий кластер 1С из двух серверов. Ожидаю, что после этого будет более-менее понятно, что должен уметь делать minimum viable оператор для 1С и какими ресурсами он должен управлять. О том, что такое операторы в Kubernetes я писал тут.
🏆 Мини-викторина: в каком случае разрешено совместное использование обычных лицензий и комьюнити-лицензий?
Пишите ваши варианты в комментариях, победителю поставлю красивую звездочку ⭐️
Только чур никуда не подглядывать!