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

  • Tutorial

У багатьох компаніях як основна платформа автоматизації використовується 1С. Так повелося й у нас. Однак процес становлення платформи був зроблений без належного підходу, у зв'язку з чим спочатку у нас було 5 ключів захисту на 95 ліцензій, потім з'явилося ще 3 фізичні ключі на надання ще 50 клієнтських ліцензій для 3-х юридичних осіб. Ситуація безглузда, тому що кожен ключ по нормальному вимагає окремих хост, а підходящих для цього серверів ставало все менше, а збільшення кількості користувачів, що маячить, і, отже, покупки нових ключів, змусило мене задуматися над альтернативним рішенням, що дозволяє уникнути зайвого інформаційного навантаження на наші сервери і взагалі зробити систему з ключами гнучкішою і, бажано, стійкішою.

Вибір системи

Система віртуалізації
Як система візуалізації був вибраний esxi 5.1. Вибраний за непогану підтримку перекидання USB пристроїв і тому що крім ESX я розуміюся тільки на Hyper-V, перекидання пристроїв який не підтримує.

Для перекидання USB пристроїв в ESX, залізо гостьової системи має бути не нижче версії 7. ​​Тоді з'явиться можливість додати USB контролері примапити USB пристрійу гостьову систему. Ще є момент щодо підтримки. Офіційно VMware підтримує лише певний перелік пристроїв. І він не дуже великий. Проте рядові ключі захисту Aladdin, схоже, підтримуватимуться. Список підтримуваних пристроїв є на офіційному сайті. А опис вимог і положень з береки USB в гостьову систему є також на офіційному сайті, в базі знань.

Є та альтернативні способипрокидання USB ключів у віртуальне середовище, та й у фізичне теж. Це пристрої та програмне забезпечення так зване USB over IP. Програмні продуктиу разі не дуже цікаво розглядати, тоді як залізні у разі непогано себе показують. Найяскравіший представник, всім відомий AnywhereUSB з 14 портами. Встановлюється у стійку, має два інтерфейси та два входи живлення (чи має реально два блоки живлення, я не знаю:)). Пристрій усім добре, але коштує в середньому 60 тисяч рублів, що погано вкладалося до нашого бюджету.

Отже, після тестів та проб, платформу віртуалізації вибрали та відмовилися від використання інших продуктів.

Операційна система та драйвера HASP

Як ОС я вибрав Debian. Чому? Та просто так. По суті, у цій конфігурації можна взяти будь-який улюблений дистрибутив. Але Debian мені завжди подобається стабільністю та хорошим репозиторієм.

Як драйвери береться досить популярний пакет від компанії Etersoft. Взяти скомпільований пакет для свого дистрибутива можна на FTP серверікомпанії: ftp.etersoft.ru/pub/Etersoft/HASP/stable.
Після інсталяції пакета з'являється служба haspd , яка керує роботою ключа.

Налаштування та перевірка

Якийсь додаткового налаштуваннявсе це не потребує. Ключ починає працювати практично із коробки.
Перевіряємо. Для перевірки працездатності в комплекті є програма haspdemo. При успішній ідентифікації ключа та початку роботи програма виведе щось подібне до консолі:

LOCALHASP_ISHASP: Result: 1

Using Passwords 15213 - 28875
LOCALHASP_HASPSTATUS: API version number is 8.0
port number 201
Key type: HASP4 M4
LOCALHASP_HASPGENERATION: OK, HASP4 is connected.
LOCALHASP_HASPNETSTATUS: connected key is HASP4 Net 20
MEMOHASP_HASPID: 436444258 (decimal), 0x1a039c62 (hex)

LOCALHASP_ENCODEDATA: Добре.
53 C1 F1 AF | EC 16 C3 15 | 35 31 E4 7F | 9B D0 90 9F
AA BA 8C 80 | 1E 22 29 E2 | 92 7E 04 56 | DA 70 7B 63 [.....")..~.V.p(c]
23 B4 9B E6 | 2F 17 | | [#.../.]

NETHASP_READBLOCK: Поточний: Відновлення: 10


Головне поле: LOCALHASP_ISHASP: Result: 1 . Повідомляє, що все гаразд. Далі написано про те, який ключ вставлений.

Однак якщо є якась проблема, то повідомлення виводиться коротше:

Цей простий demo program для HASP4 key
Copyright Aladdin Knowledge Systems Ltd.

LOCALHASP_ISHASP: Failed: status = -100


При тому по суті все одно, що відбувається з ключем, він може бути не вставлений, служба може бути не запущена або ще щось. Я поки що бачив лише два значення LOCALHASP_ISHASP. Це або: Result: 1 або: Failed: status = -100 . І останнє завжди відповідало непрацездатності, а перше завжди означало, що це ОК. Документації до цього пакету я не знайшов, тому дізнатися які ще є статуси не вийшло.

Із ключем розібралися. Треба пам'ятати, що в моніторі ключів ваш новий ключ з'явиться тільки тоді, коли з нього буде взята хоча б одна ліцензія. Тоді aladdin monitorпокаже ту інформацію, яку він зазвичай показує: це типу ключа, кількість взятих ліцензій, всього ліцензій, хто саме забрав ліцензію та тайм-аут.
Форсувати це досить просто, достатньо вказати в клієнтській nethasp.ini руками новий менеджер ліцензій. Але про налаштування клієнта трохи пізніше.

З цього моменту вважатимуться початкову завдання виконаною. Тепер ми можемо створити паралельно кілька віртуалок, у кількості, що відповідає кількості наявних фізичних ключів. Ресурси такі віртуалки споживають, звісно, ​​копійчані.

Проблеми та рішення

Єдина точка відмови
Перша проблема, яка створюється і у всіх на очах, це створення точки відмови. Якщо раніше ключі були розподілені по різних серверах і відмова більше одного ключа практично виключено, то в даному випадку відмова роботи фізичного сервера може спричинити відмову від роботи всієї системи 1С, т.к. клієнти будуть відвалюватися протягом, на мою думку, 600 секунд і через нетривалий час відваляться всі і не зможуть повернутися до системи. Що буде за таким інцидентом можна не розповідати. Варіантів рішення два і направлені у різному напрямку. Перше рішення - це використання відмовостійкої конфігурації ESX. Однак це доцільно, якщо у вашій компанії ця система вже розгорнута і вже виконано низку вимог для підтримки працездатності при відмові будь-якого компонента. Інше рішення більш тривіальне:
Ми створюємо групу A записів у DNS нашої компанії. Наприклад, key1, key2, key3 тощо. Вносимо DNS імена в nethasp.ini клієнтів, розповсюджуємо файл за допомогою групової політики. Таким чином, ми отримуємо досить гнучку структуру доступу. У цьому випадку після виявлення суттєвої проблеми з віртуальним сервером esx можна оперативно перемістити ключі на будь-які інші сервери, в т.ч. на робочі станції будь-яких працівників. Паралельно замінюємо записи A на нові. Протягом деякого часу кеш на клієнтах закінчиться, і вони знову зможуть взяти собі нову ліцензію та продовжити роботу.
Рекомендую прописати зворотні записи DNS для ключів, інакше aladdin monitor не буде показувати ім'я хоста, а покаже тільки ID менеджера ліцензій, що не дуже зручно.
Якщо у вашій компанії і все використовується широкомовний метод доставки ключів, то все спрощується і при переміщенні ключа на інший хост в межах широкомовного домену ні як не позначиться на роботі.
Відвалюються ключі
Є така досить поширена проблема. Ключі відвалюються. При цьому жодного особливого зв'язку не було помічено. Це відбувається на різні контролери, навіть на різних хостових системах. Коли я переносив ключі та тимчасово розмістив їх в іншому місці під керуванням VMware Player, відвалення ключів відбувалося часто. Виражається це досить очевидно. При запиті haspdemo з'являється рядок LOCALHASP_ISHASP: Failed: status = -100 . Хоча ключ вставлено та виявляється. dmseg показує не до кінця зрозумілі рядки: usb 2-2.1: usbfs: USBDEVFS_CONTROL failed cmd aksusbd rqt 192 rq 139 len 8 ret -110
Вирішується проблема також тривіально, як і виглядає – рестартом сервісу. Але осад залишається і поки це не виконати, сервер роздавати ключі не буде. Так як хочеться, щоб система працювала безвідмовно, було вирішено написати скрипт, який би сам відновлював роботу менеджера ліцензій. Так, за допомогою друга, був написаний скрипт, який запускає haspdemo і намагається зрозуміти, чи нормальний статус повертається чи ні:
[ "`haspdemo | sed -n "s/^LOCALHASP_ISHASP.* \(\-\?*\)$/\1/p"`" == "-100" ] && service haspd restart
Далі цей скрипт вставляється в запуск CRON кожну хвилину і все. Навіть якщо у вашій системі не буде спостерігатися проблема портів, що відвалюються, даний скрипт, думаю, не завадить.
Проблема виявлення ключа клієнтом
І така проблема. Полягає вона в тому, що клієнт після втрати ключа може не захотіти взяти новий ключ. Також ця проблема може виражатися і в інших проявах. Наприклад, якщо ви замінили шляхи до ключів у файлі nethasp.ini, то клієнтська програма може цілком бадьоро продовжувати повідомляти про те, що ключів жодних немає і не бачив ніколи. Якщо до такої реакції бути не готовим, то проблема стає дуже неприємною і починаєш судомно перевіряти роботу всієї системи і крити матом 1С-ників, бо все працює, але ГоловБух або, як на зло, Генеральний, увійти в 1Ску зараз не може з незрозумілої причини і ти почуваєшся ідіотом, замість того, щоб швидко вирішити проблему. Однак поки що допомагало досить просте рішення. Необхідно очистити кеш 1С із профілю користувача. Свого часу я знаходив окремий файл, який відповідає за цю інформацію, не забув який:(
Ключі можуть просто перестати працювати
Проти відмови обладнання ніхто не застрахований. І ці жалюгідні ключі також можуть перестати працювати. І найважливіше в цьому випадку дізнатися про це якомога раніше. Для цього ми будемо використовувати систему моніторингу Zabbix. Безумовно, розгортати її тільки для моніторингу за ключами безглуздо, проте якщо заббікс уже стоїть, то чому б не прикрутити до нього моніторинг за станом ключів.
Для цього нам потрібно прописати власний скрипт у файлі налаштувань агента. Шукаємо файл конфігурації встановленого zabbix_agent, називається він zabbix_agentd.conf. Відкриваємо його та додаємо рядок
UserParameter=hasp.status,haspdemo | grep "^LOCALHASP_ISHASP" | sed "s/^.* \(\-\?*\)$/\1/g"

Це дозволить по команді зібрати цифрове значення у полі LOCALHASP_ISHASP. У самому заббікс все додається вже примітивно, створюємо Itemдля потрібного хоста або шаблону, як Typeвказуємо Zabbix agent,як параметр key вказуємо hasp.status. Тип значення - float. При бажанні створюємо тригер, за яким вам надсилатиметься лист або смска про те, що ключ не працює. Тригер цей краще налаштувати таким чином, щоб вимагав як мінімум 2х спрацьовувань і покривав час, який потрібно скрипту автовідновлення, який описувався вище, інакше будуть з'являтися помилкові повідомлення про проблеми з ключем.
При правильному налаштуванні тільки при повній непрацездатності ключа вам надходитиме повідомлення про проблеми.

Бонус

Для мене виявилося сюрпризом, але багато хто дійсно не знає, що можна змусити клієнтські частини 1С шукати ключі за вказаними IP адресами, використовуючи TCP або UDP з'єднання. Справді, багато хто налаштовує інфраструктуру так, щоб у кожному широкомовному домені була достатня кількість ключів. Це дикість. Для тих, хто ще не в курсі ось коротка інструкція:
Для управління доступом до ключа hasp, на клієнті є файл nethasp.ini. Знаходиться він у папці \conf каталогу 1С. Нас цікавить секція. У цьому розділі нам потрібно розкоментувати або створити такі параметри:
  • NH_SERVER_ADDR. Тут ми вказуємо список DNS імет або IP адрес серверів з менеджером ліцензій через кому.
  • NH_USE_BROADCAST. Ставимо значення у Disabled.
  • NH_TCPIP_METHOD. За промовчанням використовується метод UDP. Можна змінити на TCP, але загалом у цьому немає серйозної потреби.

Ще момент з приводу відображення ключів в aladdin monitor. Всупереч поширеній думці, вільними ліцензіями є не лише ті ліцензії, які відсутні у вигляді зайнятих в aladdin monitor, але й ті, у яких у полі Timeout стоїть 0. Значення зазвичай пропадають протягом 36 годин, але все одно ліцензії вважаються вільними.

На завершення
Довго думав, чи є сенс у подібній статті, все-таки все це можна знайти в інтернеті, проте порахувавши час, який я сам витратив, щоб зібрати всю інформацію, то подумав, що буде дуже добре, якщо хоча б комусь ця стаття виявиться корисною та заощадить час.
  • Tutorial

У багатьох компаніях як основна платформа автоматизації використовується 1С. Так повелося й у нас. Однак процес становлення платформи був зроблений без належного підходу, у зв'язку з чим спочатку ми мали 5 ключів захисту на 95 ліцензій, потім з'явилося ще 3 фізичні ключі на надання ще 50 клієнтських ліцензій для 3-х юридичних осіб. Ситуація безглузда, тому що кожен ключ по нормальному вимагає окремих хост, а підходящих для цього серверів ставало все менше, а збільшення кількості користувачів, що маячить, і, отже, покупки нових ключів, змусило мене задуматися над альтернативним рішенням, що дозволяє уникнути зайвого інформаційного навантаження на наші сервери і взагалі зробити систему з ключами гнучкішою і, бажано, стійкішою.

Вибір системи

Система віртуалізації
Як система візуалізації був вибраний esxi 5.1. Вибраний за непогану підтримку перекидання USB пристроїв і тому що крім ESX я розуміюся тільки на Hyper-V, перекидання пристроїв який не підтримує.

Для перекидання USB пристроїв в ESX, залізо гостьової системи має бути не нижче версії 7. ​​Тоді з'явиться можливість додати USB контролер і примапит USB пристрій в гостьову систему. Ще є момент щодо підтримки. Офіційно VMware підтримує лише певний перелік пристроїв. І він не дуже великий. Проте рядові ключі захисту Aladdin, схоже, підтримуватимуться. Список підтримуваних пристроїв є на офіційному сайті. А опис вимог і положень з береки USB в гостьову систему є також на офіційному сайті, в базі знань.

Є й альтернативні способи прокидання USB ключів у віртуальне середовище, та й у фізичне теж. Це пристрої та програмне забезпечення так зване USB over IP. Програмні продукти в даному випадку не дуже цікаво розглядати, а от залізні в цьому випадку непогано показують себе. Найяскравіший представник, всім відомий AnywhereUSB з 14 портами. Встановлюється у стійку, має два інтерфейси та два входи живлення (чи має реально два блоки живлення, я не знаю:)). Пристрій усім добре, але коштує в середньому 60 тисяч рублів, що погано вкладалося до нашого бюджету.

Отже, після тестів та проб, платформу віртуалізації вибрали та відмовилися від використання інших продуктів.

Операційна система та драйвера HASP

Як ОС я вибрав Debian. Чому? Та просто так. По суті, у цій конфігурації можна взяти будь-який улюблений дистрибутив. Але Debian мені завжди подобається стабільністю та хорошим репозиторієм.

Як драйвери береться досить популярний пакет від компанії Etersoft. Взяти скомпільований пакет для свого дистрибутива можна на FTP сервері компанії: ftp.etersoft.ru/pub/Etersoft/HASP/stable.
Після інсталяції пакета з'являється служба haspd , яка керує роботою ключа.

Налаштування та перевірка

Якогось додаткового налаштування все це не вимагає. Ключ починає працювати практично із коробки.
Перевіряємо. Для перевірки працездатності в комплекті є програма haspdemo. При успішній ідентифікації ключа та початку роботи програма виведе щось подібне до консолі:

LOCALHASP_ISHASP: Result: 1

Using Passwords 15213 - 28875
LOCALHASP_HASPSTATUS: API version number is 8.0
port number 201
Key type: HASP4 M4
LOCALHASP_HASPGENERATION: OK, HASP4 is connected.
LOCALHASP_HASPNETSTATUS: connected key is HASP4 Net 20
MEMOHASP_HASPID: 436444258 (decimal), 0x1a039c62 (hex)

LOCALHASP_ENCODEDATA: Добре.
53 C1 F1 AF | EC 16 C3 15 | 35 31 E4 7F | 9B D0 90 9F
AA BA 8C 80 | 1E 22 29 E2 | 92 7E 04 56 | DA 70 7B 63 [.....")..~.V.p(c]
23 B4 9B E6 | 2F 17 | | [#.../.]

NETHASP_READBLOCK: Поточний: Відновлення: 10


Головне поле: LOCALHASP_ISHASP: Result: 1 . Повідомляє, що все гаразд. Далі написано про те, який ключ вставлений.

Однак якщо є якась проблема, то повідомлення виводиться коротше:

Цей простий demo program для HASP4 key
Copyright Aladdin Knowledge Systems Ltd.

LOCALHASP_ISHASP: Failed: status = -100


При тому по суті все одно, що відбувається з ключем, він може бути не вставлений, служба може бути не запущена або ще щось. Я поки що бачив лише два значення LOCALHASP_ISHASP. Це або: Result: 1 або: Failed: status = -100 . І останнє завжди відповідало непрацездатності, а перше завжди означало, що це ОК. Документації до цього пакету я не знайшов, тому дізнатися які ще є статуси не вийшло.

Із ключем розібралися. Треба пам'ятати, що в моніторі ключів ваш новий ключ з'явиться тільки тоді, коли з нього буде взята хоча б одна ліцензія. Тоді aladdin monitor покаже ту інформацію, яку він зазвичай показує: це типу ключа, кількість взятих ліцензій, всього ліцензій, хто саме забрав ліцензію та таймують.
Форсувати це досить просто, достатньо вказати в клієнтській nethasp.ini руками новий менеджер ліцензій. Але про налаштування клієнта трохи пізніше.

З цього моменту вважатимуться початкову завдання виконаною. Тепер ми можемо створити паралельно кілька віртуалок, у кількості, що відповідає кількості наявних фізичних ключів. Ресурси такі віртуалки споживають, звісно, ​​копійчані.

Проблеми та рішення

Єдина точка відмови
Перша проблема, яка створюється і у всіх на очах, це створення точки відмови. Якщо раніше ключі були розподілені по різних серверах і відмова більше одного ключа практично виключено, то в даному випадку відмова роботи фізичного сервера може спричинити відмову від роботи всієї системи 1С, т.к. клієнти будуть відвалюватися протягом, на мою думку, 600 секунд і через нетривалий час відваляться всі і не зможуть повернутися до системи. Що буде за таким інцидентом можна не розповідати. Варіантів рішення два і направлені у різному напрямку. Перше рішення - це використання відмовостійкої конфігурації ESX. Однак це доцільно, якщо у вашій компанії ця система вже розгорнута і вже виконано низку вимог для підтримки працездатності при відмові будь-якого компонента. Інше рішення більш тривіальне:
Ми створюємо групу A записів у DNS нашої компанії. Наприклад, key1, key2, key3 тощо. Вносимо DNS імена в nethasp.ini клієнтів, розповсюджуємо файл за допомогою групової політики. Таким чином, ми отримуємо досить гнучку структуру доступу. У цьому випадку після виявлення суттєвої проблеми з віртуальним сервером esx можна оперативно перемістити ключі на будь-які інші сервери, в т.ч. на робочі станції будь-яких працівників. Паралельно замінюємо записи A на нові. Протягом деякого часу кеш на клієнтах закінчиться, і вони знову зможуть взяти собі нову ліцензію та продовжити роботу.
Рекомендую прописати зворотні записи DNS для ключів, інакше aladdin monitor не буде показувати ім'я хоста, а покаже тільки ID менеджера ліцензій, що не дуже зручно.
Якщо у вашій компанії і все використовується широкомовний метод доставки ключів, то все спрощується і при переміщенні ключа на інший хост в межах широкомовного домену ні як не позначиться на роботі.
Відвалюються ключі
Є така досить поширена проблема. Ключі відвалюються. При цьому жодного особливого зв'язку не було помічено. Це відбувається на різні контролери, навіть на різних хостових системах. Коли я переносив ключі та тимчасово розмістив їх в іншому місці під керуванням VMware Player, відвалення ключів відбувалося часто. Виражається це досить очевидно. При запиті haspdemo з'являється рядок LOCALHASP_ISHASP: Failed: status = -100 . Хоча ключ вставлено та виявляється. dmseg показує не до кінця зрозумілі рядки: usb 2-2.1: usbfs: USBDEVFS_CONTROL failed cmd aksusbd rqt 192 rq 139 len 8 ret -110
Вирішується проблема також тривіально, як і виглядає – рестартом сервісу. Але осад залишається і поки це не виконати, сервер роздавати ключі не буде. Так як хочеться, щоб система працювала безвідмовно, було вирішено написати скрипт, який би сам відновлював роботу менеджера ліцензій. Так, за допомогою друга, був написаний скрипт, який запускає haspdemo і намагається зрозуміти, чи нормальний статус повертається чи ні:
[ "`haspdemo | sed -n "s/^LOCALHASP_ISHASP.* \(\-\?*\)$/\1/p"`" == "-100" ] && service haspd restart
Далі цей скрипт вставляється в запуск CRON кожну хвилину і все. Навіть якщо у вашій системі не буде спостерігатися проблема портів, що відвалюються, даний скрипт, думаю, не завадить.
Проблема виявлення ключа клієнтом
І така проблема. Полягає вона в тому, що клієнт після втрати ключа може не захотіти взяти новий ключ. Також ця проблема може виражатися і в інших проявах. Наприклад, якщо ви замінили шляхи до ключів у файлі nethasp.ini, то клієнтська програма може цілком бадьоро продовжувати повідомляти про те, що ключів жодних немає і не бачив ніколи. Якщо до такої реакції бути не готовим, то проблема стає дуже неприємною і починаєш судомно перевіряти роботу всієї системи і крити матом 1С-ників, бо все працює, але ГоловБух або, як на зло, Генеральний, увійти в 1Ску зараз не може з незрозумілої причини і ти почуваєшся ідіотом, замість того, щоб швидко вирішити проблему. Однак поки що допомагало досить просте рішення. Необхідно очистити кеш 1С із профілю користувача. Свого часу я знаходив окремий файл, який відповідає за цю інформацію, на яку забув:(
Ключі можуть просто перестати працювати
Проти відмови обладнання ніхто не застрахований. І ці жалюгідні ключі також можуть перестати працювати. І найважливіше в цьому випадку дізнатися про це якомога раніше. Для цього ми будемо використовувати систему моніторингу Zabbix. Безумовно, розгортати її тільки для моніторингу за ключами безглуздо, проте якщо заббікс уже стоїть, то чому б не прикрутити до нього моніторинг за станом ключів.
Для цього нам потрібно прописати власний скрипт у файлі налаштувань агента. Шукаємо файл конфігурації встановленого zabbix_agent, називається він zabbix_agentd.conf. Відкриваємо його та додаємо рядок
UserParameter=hasp.status,haspdemo | grep "^LOCALHASP_ISHASP" | sed "s/^.* \(\-\?*\)$/\1/g"

Це дозволить по команді зібрати цифрове значення у полі LOCALHASP_ISHASP. У самому заббікс все додається вже примітивно, створюємо Itemдля потрібного хоста або шаблону, як Typeвказуємо Zabbix agent,як параметр key вказуємо hasp.status. Тип значення - float. При бажанні створюємо тригер, за яким вам надсилатиметься лист або смска про те, що ключ не працює. Тригер цей краще налаштувати таким чином, щоб вимагав як мінімум 2х спрацьовувань і покривав час, який потрібно скрипту автовідновлення, який описувався вище, інакше будуть з'являтися помилкові повідомлення про проблеми з ключем.
При правильному налаштуванні тільки при повній непрацездатності ключа вам надходитиме повідомлення про проблеми.

Бонус

Для мене виявилося сюрпризом, але багато хто дійсно не знає, що можна змусити клієнтські частини 1С шукати ключі за вказаними IP адресами, використовуючи TCP або UDP з'єднання. Справді, багато хто налаштовує інфраструктуру так, щоб у кожному широкомовному домені була достатня кількість ключів. Це дикість. Для тих, хто ще не в курсі ось коротка інструкція:
Для управління доступом до ключа hasp, на клієнті є файл nethasp.ini. Знаходиться він у папці \conf каталогу 1С. Нас цікавить секція. У цьому розділі нам потрібно розкоментувати або створити такі параметри:
  • NH_SERVER_ADDR. Тут ми вказуємо список DNS імет або IP адрес серверів з менеджером ліцензій через кому.
  • NH_USE_BROADCAST. Ставимо значення у Disabled.
  • NH_TCPIP_METHOD. За промовчанням використовується метод UDP. Можна змінити на TCP, але загалом у цьому немає серйозної потреби.

Ще момент з приводу відображення ключів в aladdin monitor. Всупереч поширеній думці, вільними ліцензіями є не лише ті ліцензії, які відсутні у вигляді зайнятих в aladdin monitor, але й ті, у яких у полі Timeout стоїть 0. Значення зазвичай пропадають протягом 36 годин, але все одно ліцензії вважаються вільними.

На завершення
Довго думав, чи є сенс у подібній статті, все-таки все це можна знайти в інтернеті, проте порахувавши час, який я сам витратив, щоб зібрати всю інформацію, то подумав, що буде дуже добре, якщо хоча б комусь ця стаття виявиться корисною та заощадить час.

Запитання: Моніторинг програмних ліцензій


Добридень.
Windows Server 2008 + SQL server+ Сервер 1С 8.2.
На сервері встановлені програмні ліцензії 10 шт. + 5 шт. = 15 шт.
Максимальна кількість одночасно працюючих користувачів - 13 шт.
База одна. Відповідно користувачі запускають лише один екземпляр програми.
Іноді деякі користувачі не можуть зайти в 1с (не виявлено ключ захисту програми). Випадково з'ясувалося, що користувачі знову можуть зайти, якщо 1с-ку перезапустить один конкретний користувач. Відповідно, як я розумію, цей користувач під час своєї роботи витрачає більше однієї ліцензії.
Питання: як відстежити якісь ліцензії куди пішли і як боротися з такими ліцензіями, що зависли?

Відповідь:

Хороша обробка, потрібна! Але не працює)
(Зовнішня Обробка. Моніторинг Ліцензій. Модуль Об'єкта (53)): (Зовнішня Обробка. Моніторинг Ліцензій. Модуль Об'єкта (23)): Помилка при виклику конструктора (COM Об'єкт): -2147221005 (0x300
ВикликатиВиняток ОписПомилки();

Чи може хтось зміг вилікувати?

Питання: Проблема із програмними ліцензіями на сервері 1с


Здрастуйте шановні форумчани! Підкажіть будь ласка, якщо хтось стикався, як бути в такій ситуації.
Спочатку була база 1с КА 1.1, 1с 8.2, платформа 8.2.19.130, файлова на термінальному сервері. На самому сервері було встановлено ключ на 10 ліцензій користувача та 5 програмних ліцензій (файл ліцензії лежав у C:\ProgramData\1C\1Cv82\conf). Користувачі працювали через термінальні сесії.
Стало: переклали на клієнт-серверний варіант(1с сервер х64, платформа 8.3.8.2054), субд Postgres, користувачі працюють безпосередньо зі своїх робочих місць. Комп'ютери отримують ліцензію мережі з сервера.
Проблема полягає в тому, що сервер 1с не бачить програмні ліцензії. Файл ліцензії копіював у папку conf сервера (C:Program Files1cv8conf), в папку ліцензій (C:Program Files1cv88.3.8.2054licenses - хоча і розумію, що тут ліцензія зберігатися не повинна), а також в папку платформи за такими ж шляхами (C: Program Files (x86) \ 1cv8 \ conf, C: Program Files (x86) \ 1cv8 \ 8.3.8.2054 \ licenses).
Наскільки я почитав в інтернетах, то програмні ключі шукаються та підхоплюються в першу чергу, тому має працювати.
Але відвідують мене сумні думки, що при встановленні програмної ліцензії на 5 користувачів, щось "вошилося" в регістр, що пов'язує її з початковою схемою, на 1с 8.2, і що не бачить сервер 8.3. Оскільки на програмній ліцензії доведеться новий пін-код активувати, прошу допомоги, підкажіть, чи справді справа в цьому?

Відповідь:

У разі активації програмних ліцензій файл створюється не один. Найкраще написати за адресою, мені відповіли протягом півгодини з питання деактивації ліцензії. Запропонували знайти та видалити всі файли 2*.lic та всі файли conn8211.pfl (або 1Сv8conn.pfl, якщо версія 8.3). Відповідно Вам як мінімум всі ці файли потрібно перемістити, але ніхто не скаже чи допоможе, тому я написав би їм лист. Через неправильні дії пакет ліцензій може потрапити до чорного списку.

Питання: Програмна ліцензія та COM-з'єднання


Встановлено програмну ліцензію.
При спробі запуску 1С Com-з'єднання пише:
-----------
Не виявлено вільну ліцензію!
Пошук ліцензій на клієнта:
Помилка програмного ліцензування
Перевищено максимальна кількістькористувачів, дозволений файлом програмної ліцензії.
Джерело: V82.COMConnector.1
-----------
В чому проблема?

Відповідь:Перевищено максимальну кількість користувачів, дозволену файлом програмної ліцензії.

Питання: Як дізнатися який файл (.lic) відповідає якійсь програмній ліцензії?


Вітаю. На сервері встановлено дві програмні ліцензії (мають бути встановлені). Але я бачу що лунає тільки одна. У C:\Users\1C_admin.1C8\AppData\Local\1C\1cv82\conf знаходиться 3 файли:2014*****.lic в одному з них якщо через текстовий просмоторник відкрити написано нагорі (самі програмні ліцензії номера 8100** ***):

На комп'ютері server1 використовуються дві копії одного і того ж файлу програмної ліцензії: file://C:/ProgramData/1C/1Cv82/conf/2014*****.lic та file://C:/Users/1C_admin.1C8 /AppData/Local/1C/1Cv82/conf/2014*****.lic

Хоча ця папка порожня.
Папка C:\Users\All Users\1C\1Cv82\conf також порожня.
Чи може цей напис видалити тоді почне все лунати?

І найголовніше дивлюся через консоль адміністрування ключ сервер 8100 – це програмний ключ. А що за ключ ORGL8 Сет 20 – що це за ключ? Програмний чи апаратний? Я думаю програмний але чому тоді Сервер та не замовник?

Відповідь:

Невже ніхто не знає як по файлу.lic дізнатися, яка це ліцензія (відповідність ліцензії.lic номеру з реєстраційної картки)?

Запитання: Хитрощі видачі програмних ліцензій сервером 1С


Всім привіт!
Друзі, будь ласка, підкажіть за ліцензіями, є деякі не зрозумілі моменти для мене.
На сервері активовано програмну ліцензію на 10 користувачів. На сервері стоїть сервер 1С, база SQL і термінальний сервер.
Видача ліцензій відбувається наступним чином (може це не точно, якщо не прав виправте).
1. Якщо у користувача на своєму локальному комп'ютерістоїть платформа і він по мережі з'єднується з базою 1с на сервері, то кожен запущений екземпляр програми, сервер йому віддає одну ліцензію. Тобто, якщо користувач у себе запустить 10 баз, то ліцензій на сервері не залишиться.
2. Якщо користувач підключається по RDP, то сервер віддає йому одну клієнтську ліцензію і користувач зможе запускати необмежену кількість екземплярів програми (баз).
Головне питання, чи спрацює другий пункт, якщо користувач підключатиметься до термінальному серверуза RDP, там будуть активовані програмні ліцензії, але сервера 1с не буде? У терміналі у нього стоятиме платформа, але без сервера 1с. Чи обов'язково, щоб спрацьовував пункт два, на сервері терміналів повинен бути сервер 1с?

Відповідь:

така видача ліцензій працює за будь-якого локального запуску 1С (RDP це локальний запуск) якщо ліцензії не роздає сервер 1С

Питання: Не лунають клієнтські програмні ліцензії


Доброго дня.

Створив кластер 1С (8.3.7.1759) та сервер ліцензування. Діяв за цією інструкцією. (). На сервер ліцензування активував розраховану на багато користувачів програмну ліцензію. Якщо запускаю клієнта 1С прямо на сервері ліцензування - він нормально отримує програмну ліцензію. З будь-яких інших місць, якщо підключаємося до бази на цьому кластері, видається апаратна ліцензія. Файл ліцензії лежить тут C:\ProgramData\1C\licenses

Відповідь:

Доступ до читання є. Призначення функціональності додав до сервера ліцензування. Галочка використовувати апаратний ключ не варто. І все одно отримує залізну ліцензію.
--- Об'єднанняповідомлень, 28 Гру 2015 ---

OKarlov сказав(а):

Перевірте ще зареєстровану помилку

Якщо у властивостях робочого сервера кластера встановлено обмеження кількості інформаційних базна робочий процес, то цей сервер може почати розподілятися функціональність, яка заборонена вимогами призначення функціональності.

Натисніть, щоб розкрити...

Кластер новий- на ньому поки що тільки 1 база. Ніхто не працює. Налаштування зараз 8 баз, 128 з'єднань на процес.

Запитання: Проблема з перенесенням програмної ліцензії 1С 8.3 на новий сервер


Добридень.

У компанії був один фізичний сервер 1С 8.3 із файловими базами бухгалтерії. На ньому стояли програмні ліцензії.

Закупили ліцензії на 1с ERP:

1.на платформу для 20 осіб
2.на конфігурацію 3 .на сервер 1 з Також купили новий стійковий сервер, встановили нею платформу 1С 8.3, розгорнули тестову базу ERP, встановили програмні ліцензії - все ок.

Виникла проблема з перенесенням файлових баз, вірніше самі бази я скопіював, але при запуску 1С не пропонує ввести ліцензію, а каже, що ліцензія не знайдена і пропонує використовувати апаратний ключ захисту.

Підкажіть, як зробити так, щоб 1С запропонував запровадити програмну ліцензію для файлових баз бухгалтерії на новому сервері?

Відповідь:Супер дякую!

Запитання: v7: 1С 7.7 ТіС – чи могла бути програмна ліцензія?


Зіткнувся з ТіС 7.7 локальної без апаратного захисту ключа. Наскільки пам'ятаю ТіС 7.7 не мав поставок з програмною ліцензією? Пам'ятаю на 7-ці були якісь продукти з активацією за словами з книги - потрібно було знайти слово на такій сторінці і тоді відбувалася активація, тобто без ключа захисту. Але начебто це були якісь галузеві рішення, наскільки пам'ятаю. Коробка з анкетою, дискетами та книгами є, а ось ключа ніде немає. Правда на ПК немає порту LPT, можливо тому його свого часу не поставили і кудись загубили. Але все-таки хотілося б переконатися, що ТіС з програмною активацією не було, тільки з апаратною? Раптом я просто завжди раніше з апаратними стикався.

Відповідь:

Добридень!
На сервері встановлено 2 програмні ліцензії на 20 підключень кожна. Закінчилися ліцензії не з того ні з сього, хоча через монітор підключених користувачів дивлюся - лише 19 з'єднань.
Як дізнатися скільки ліцензій використовується. Від алладіна програма гарна але працює тільки з USB ключами.
Дякую.

Відповідь:

"через монітор підключених користувачів дивлюся - всього 19 з'єднань" - це через який монітор ви бачите видані програмні ліцензії?


Завантаження...
Top